Chris Ellis @intrbiz@bergamot.social

@amcasari @l_avrot 2 speakers, 5 mins pro, 5 mons cons, 5 mins audience decide the winner. And these will be propper pgconf.eu style 5 mins.

@nixCraft Create HTML file, add script tag........ profit.

@amcasari @l_avrot what about a 'Wargames' track. Covering topics like:
Spaces vs Tabs
Copyleft vs Permissive
Containers vs Jails
....

@neil I tend to find the length of the print doesn't significantly increase the failure rate. Especially with a filament run out sensors, were on big prints running out of filament can be the biggest issue.

Tend to find most failures on my 3D printer are caused by bed adhesion, which is usually best tuned with print orientation and if needed brims. Or by extrusion issues which tends to be related to different filament and tuning a little for it.

@tig @dick_turpin my pipeline is far from perfect, but build container and then run it, catches a lot of issues.

I saw a talk the other year of a team who put a CI/CD pipeline around an ancient VMS app which they ran in openVMS. It was pretty crazy but showed what can be done. Getting that done let them actually develope and evolve the ancient code, rather than just be scared of touching it.

@tig @dick_turpin sure, but it would only cause an issue inside the container and thus be caught in your CI pipeline.

@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.