Chris Ellis @intrbiz@bergamot.social

@tig @dick_turpin if those in the trenches don't fight for other options, it won't ever change.

Staggering updates and actually using test environments should help spot kernel issues before it's too much of an issue.

Shell issues, would be part of a container build.

@tig @dick_turpin but upgrade small and often is usually far less error prone, since people understand what is changing more.

@tig @dick_turpin in a world of immutable containers the left-pad problem happens in your CI build pipeline. Great thing with openSUSE MicroOS is it will automatically reboot into the previous snapshot on healthcheck fails.

The biggest issue I had was a bootloader fuckup, which was not fun, but only an issue on my Raspberry Pis and not any of my VMs.

Problems will happen, which is why approaches like canary and staggered deployments are needed.

@tig @dick_turpin companies change control boards will eventually have to come into the 21st century. I've never seen change control actually help. Far better is to build real feedback loops and a focus on quality, rather than gating things based on bullshit.

@tig @dick_turpin but having my prod servers auto-update themselves with security fixes every few days, in a totally automated way is game changing in many ways.

@tig @dick_turpin can often be better packaged than some of the shit RPMs or bonkers PHP / Python deployments I've seen over the years. The technology is not a limiter of the quality, just like it never was before.

@tig @dick_turpin rolling releases on servers is the future. The need for RHEL to be a stable target for ISV vendors is gone with the advent of containers and flatpack. RHEL doesn't need to be a standard any more.

@dick_turpin @tig except that Centos Stream is not moving fast, nothing like Fedora. It's still ABI stable and compatible with RHEL.

For the usecases you really really need the same as RHEL, use a developer license.

@dick_turpin @tig they didn't dump Centos, its more important than it ever was. Just upstream rather than downstream. Which can be better for a lot of situations.

@tig @dick_turpin they could just run Centos Stream. RedHat has invested alot in the effort it takes to make RHEL so stable. If you need that, pay for it. Otherwise use Centos or whatever other distro. They are still abiding by licences and in many cases going beyond requirements.

@dick_turpin haha, an opposition leader with a personality would help too.

@dick_turpin they're going to ban the Tory party?

@fuzzychef honestly so much of HashiCorps ideas are so overblown, maybe this is a good thing. Never worked with such an unforgiving product set.

@fuzzychef @l_avrot ahh, in which case pgBackrest with compression or a dark fibre.

@l_avrot @fuzzychef also, strange question: is put a bigger NIC in an option? Compression is cool, but consumes alot of CPU relative to a bigger pipe.

@l_avrot @fuzzychef we did exactly this with pgBackrest. Roughly 20% changeset per day. Used pgBackrest to rebuild the test servers routinely as part of our regular processes. pgBackrest was really the only tool capable. We did use pgbasebackup for realtime replica rebuilds, but that has different tradeoffs.

@alpinegreg @pwramsey IMHO the really cool thing about PostgreSQL is it's a project and not a product. This has meant lots of people contributing in different directions. Competitors collaborating together to yeild something which is better than the sum of its parts. That nature of the community has meant extensibility has always had quite high significance and enabled fast innovation.

@dick_turpin Approximately 220mm by 50mm.