johnmaguire

> People can indeed form cooperatives to handle the protection, but this is hard to manage globally as an entity.

This is a fascinating idea. Is this something anyone is working on?

> Right, it already is that, and adding shared trash bins won't make it not that.

But it will change participant behavior. Most attendees work very hard to reduce the amount of trash they generate at a burn, period. This is why people bring reusable cups and plates and silverware, etc. If you provide trash services, people will be more willing to bring trash - after all, it's easy to dispose of. And this violates the LNT principle.

Can't wait to use it as a mouse for my Windows-based couch gaming PC.

That sounds incredibly frustrating, I'm sorry. Good luck.

I remember one of these shops all the way back in the late 2000s. At the time I was confused about whether it was operated by eBay or a third party. It did not last long.

> i am guessing they found early in training that an agreeable LLM is better received than one which is constantly truthful and considers you to be pretty dumb

My sense is that this is sort of accurate, but more likely it's a result of two things:

1. LLMs are still next-token predictors, and they are trained on texts of humans, which mostly collaborate. Staying on topic is more likely than diverging into a new idea.

2. LLMs are trained via RLHF which involves human feedback. Humans probably do prefer agreeable LLMs, which causes reinforcement at this stage.

So yes, kinda. But I'm not sure it's as clear-cut as "the researchers found humans prefer agreeableness and programmed it in."

> They involve a grill-me session with 20-60 sometimes more questions for tasks to get alignment which produces the design and the plan in one window.

My experience with this has been that it front-loads a lot of the LLM interactions, which can be exhausting without a reward (i.e. output.) And then, when I get the output, it's so large as to be hard to review/grok.

In other words, it feels a bit like when my coworker delivers me a month's worth of work in a single PR.

I have never had this happen, but I don't buy from first-time eBay sellers. There are definitely scams on there, but they seem to be "too good to be true" prices with 0 reviews on the seller.

Surely you're not getting scammed by sellers with lots of reputational history?

I actually am more nervous as a seller, as their buyer protection almost always sides with buyers, at least in the US (and the fee is astronomical.)

What would make it better? My only complaint as a seller is fees. I have no complaints as a buyer.

The best part is eBay works exactly the same as 10 years ago, as far as I can tell.

Interesting how none of these are around anymore

If you're interested in the program, you can find more details here: https://hrf.org/program/ai-for-individual-rights/ai-for-indi...

They offer grants for "Using AI tools and platforms to more efficiently build movements and resist oppression" in addition to many other things.

Yeah, my whole life. That's weird, not what I've experienced.

Rain is warm, and a sign of spring. It's not snow or ice which is typical to see a bit for at least the first half of April. In southeast Michigan we've had unseasonably warm weather, the trees and flowers all bloomed early, and people are talking about mowing since weeks ago. Typically you wouldn't plant anything until at least Mother's Day.

A few years ago we did "no mow May." The grass is taller now than it was at the end of May then. A quick Google says average L/H for Detroit is 40/50 in April. It's been significantly warmer than that with many days in the 60s and 70s.

Are you from Michigan or did you move here recently? Or perhaps you live further North?

It's been a very warm and early spring here in Michigan.

#8634 is specifically about a breaking change that occurred in v12. It's literally the first line of what you linked:

> In the v12 release of Forgejo (fixed in v12.0.1) there have been breaking changes that impact third-party authentication sources that use Forgejo as a provider. If you have been affected, please help us assessing the impact ...

I'm really confused by this interpretation. I see a single comment by the maintainer, saying:

> That mistake was made in the past (#8634), where there was still a lot of usages of a old and announced deprecated method (and even with quite some effort there is).

It was a related, but separate issue, which is perhaps best-described in this upstream issue: https://github.com/python-social-auth/social-core/issues/121...

The "plain" setting jvoison wants to remove is described here: https://security.stackexchange.com/a/218554

I do agree with the maintainer that a discussion is warranted before removing this setting. But I also wouldn't personally have closed the PR while waiting for said discussion to occur - and the maintainer could have created a discussion themselves. They are signaling they don't want this change, full stop.

... if you have 800 GB of VRAM free.

Many cloud providers offer bare-metal servers: https://en.wikipedia.org/wiki/Bare-metal_server#Bare-metal_c...

Yes, but for many users, CC is the product. Especially since I'm not allowed(?) to use my own harness with my sub.

For many shops, even Docker Compose is not necessary. It is still possible to deploy software directly on a VM/LXC container.

I agree that Kubernetes can help simplify the deployment model for large organizations with a mature DevOps team. It is also a model that many organizations share, and so you can hire for talent already familiar with it. But it's not the only viable deployment model, and it's very possible to build a deployment system that behaves similarly without bringing in Kubernetes. Yes, including automatic preview deployments. This doesn't mean I'm provided a VM and told to figure it out. There are still paved-path deployment patterns.

As a developer, I do need to understand the environment my code runs in, whether it is bare-metal, Kubernetes, Docker Swarm, or a single-node Docker host. It impacts how config is deployed and how services communicate with each other. The fact that developers wrote Dockerfiles is proof that they needed to understand the environment. This is purely a tradeoff (abstracting one system, but now you need to learn a new one.)

Running a Kubernetes deployment requires running many additional orchestration services that bare-metal deployments (whether running on-prem or in the cloud) do not.

I did, thanks for the correction.

There also seems to be confusion about what I meant by "bare-metal." I wasn't intending to refer to the server ownership model, but rather the deployment model where you deploy software directly onto an operating system.

There is a fairly straightforward feature in Forgejo to sync your repos to Github, if that's what you want to do. It's not perfect, of course, but should help to advertise your projects and keep your activity heatmap green.

I mostly use Forgejo for my private repos, which are free at Github, but with many limitations. One month I burned all my private CI tokens on the 1st due to a hung Mac runner. Love not having to worry about this now!

I recently did this as well and one of the things that has struck me is just how fast Actions are compared to Github!

That said, I've got Linux and macOS setup with a Mac Mini (using a Claude-generated Ansible task file), but configuring a Windows VM seemed a bit painful. You didn't happen to find anything to simplify the deployment process here, did you?

Cosmos Cloud looks neat! At a first glance from looking at the web page, it looks more focused on delivering a "personal cloud" or "1-click deploy apps."

Dokploy is more Heroku-styled: while you can deploy third-party apps (it's just Docker after all), it seems really geared towards and intended for you to be deploying your own apps that you developed, alongside a "managed" database (meaning, the DB is exposed in the UI, includes backup functionality, and can even be temporarily exposed publicly on the internet for debugging.)

Coolify feels a bit like a mix of the two deployment models, while Dockge is "bring your own deployment" and Komodo offers to replace Terraform/Ansible/docker-compose through its own declarative GitOps-style file-based config but lacks features like managed databases, or built-in subdomain provisioning.

Just as a quick aside, I tried Coolify, Dokploy, Dockge, and Komodo, and if you're trying to do a Heroku-style PaaS, Dokploy is really good. Hands down the best UX for delivering apps & databases. It's too bad about the licensing. (e.g. OIDC + audit logs behind a paid enterprise license.)

Coolify is full of features, but the UX suffers and they had a nasty breaking bug at one point (related to Traefik if you want to search it.) Dockge is just a simple interface into your running Docker containers and Komodo is a bit harder to understand/come up with a viable deployment model, and has no built-in support for things like databases.

There are many organizations which still ship software without Kubernetes. Perhaps even the vast majority.

The complaints I see about Kubernetes are typically more about one of two things: (a) this looks complex to learn, and I don't have a need for it - existing deployment patterns solve my use case, or (b) Kubernetes is much less inefficient than running software on bare-metal (energy or cost.)

Usually they go hand in hand.