chiisana

I scream test myself… kidding aside, I try to pin to major versions where possible — Postgres:16-alpine for example will generally not break between updates and things should just chip along. It’s when indie devs not tagging anything other than latest or adhere to semantic versioning best practices where I keep watchtower off and update once in a blue moon manually as a result.

Multiple compose file, each in their own directory for a stack of services. Running Lemmy? It goes to ~/compose_home/lemmy, with binds for image resized and database as folders inside that directory. Running website? It goes to ~/compose_home/example.com, with its static files, api, and database binds all as folders inside that. Etc etc. Use gateway reverse proxy (I prefer Traefik but each to their own) and have each stack join the network to expose only what you’d need.

Back up is easy, snapshot the volume bind (stop any service individually as needed); moving server for specific stack is easy, just move the directory over to a new system (update gateway info if required); upgrading is easy, just upgrade individual stack and off to the races.

Pulling all stacks into a single compose for the system as a whole is nuts. You lose all the flexibility and gain… nothing?

As with a lot of things in the crypto adjacent space, they’re offering a solution looking for problems. Some problems (such as storing and distributing files) are essentially solved (many cheap providers for both storage, distribution, and/or both to choose from), while others (such cryptographically secured immutable ledger for provenance tracking in specific use-cases) might benefit from the technology. Knowing which is which and where to adopt what tech is the challenging part.

How big is the volume/partition for that target? What filesystem are you using? I ran into an issue earlier this year/late last year where my volume exceeded 18TB which EXT4 doesn’t support on my setup.

If cost is a reason for concern, then the 5c/GB storage and 8c/GB egress on Pinata isn’t exactly cheaper than S3’s 2.7c/GB storage and 9c/GB egress. You can get much better mileage with something like Backblaze B2 0.6c/GB storage free egress, and couple with CloudFlare or other CDN for much lower egress (often free).

The average 1 bedroom apartment rent in Vancouver is allegedly $3000/mn ( recent article ). At 36K per year for just rent, 30% would be around 120K per year, which is not a simple feat.

“Too complicated” feels like a cop out… there’s no question as to whether or not clients can send both, from best practice point of view, the party instilling the change should bore the burden of supporting both for some time. I cannot and do not want to change the current release train, but I hope you can take this into consideration into the future, for future breaking changes.

I’m not asking about whether or not clients can do it, there’s no doubt a dual outbound header method is possible, but rather more about general development best practices. When instilling a change, isn’t it usually best to support both states to ensure least amount of users are immediately affected, and gradually bleed those stragglers out?

With the authentication header update, isn’t usual best practice to support both on the server side simultaneously, and set a deprecation window such that clients can update over time?

True. I’m looking for an extra headless system so it doesn’t directly affect me, but that could certainly be a concern if you’re in need for 4K.

At $80 a pop, might get more oomph from an older optiplex if electricity cost isn’t too big of a concern?

If you remove that link, wouldn’t you therefore have modified the code?

Philosophy aside, I mean, who cares about an extra outbound link? Lemmy is a social link aggregator whose entire purpose is to have outbound links. That one link isn’t going to shift the needle on your instance’s SEO…