I'm not sure Red Hat sees it as a drama. It all seems perfectly simple to me. If you want to use RHEL, pay up. If you don't want to pay, go and use something else.
All this posturing and frothing at the mouth is not going to change anything. Red Hat is on a different course now. It's up to the community to decide if they're left behind or if this is just a new chapter unfolding?
I wonder if OpenELA will be around longer than UnitedLinux?
https://www.theregister.com/2023/08/14/oracle_suse_ciq_openela/
@dick_turpin I think the thing is that lots of places that ARE big RedHat shops run production on RedHat but dev and non-production is all community EL distros so they are using the same tools and standards as prod but without the faff and licencing which in a big organisation can be a nightmare. The whole thing stinks of IBM accountants trying to extract as much cash out of RHEL without understanding Linux or the community around it.
@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.
@intrbiz Yeah, I don't understand why they dumped CentOS? The only answer I can see is IBM saw it as a direct competitor for RHEL, which they were planning to make a "Paid For" service. You can't exactly charge for RHEL and have effectively the same product running around the marketplace for free.
@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.
@dick_turpin @intrbiz but if you wanted a fast moving distro in the RH world then Fedora is literally there... not sure of how taking out Centos was better. As ignoring dev machines etc you are knackering an upgrade path from centos to RHEL
@dick_turpin @intrbiz "oh fedora does desktop stuff" "no problem let's run a rolling release centos on the prod server"... So back up this rather biased and rude version of a conversation that never happened. If you were testing centos stream with your application how do you know exactly what RHEL build release will match that?
@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.
@intrbiz @dick_turpin I agree in a way and don't know if I should be euphoric or depressed about it. Everything is now containers, I am now trying to not to go off on a rant as to the shit quality of containers...
@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 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.
@intrbiz @dick_turpin I completely agree and I usually have complete trust in my upstream but it isn't going to wash with the change control board :P Also I know what you are saying it just can't be used in every deployment :) and this is kinda the centos problem, they really fucked up a lot of people's environment that are working in the redhat world with redhat standards for paths etc if the dev licence was a sensible or practical thing then they would have used it but centos was less hassle
@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 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 but upgrade small and often is usually far less error prone, since people understand what is changing more.
@intrbiz @dick_turpin which is kinda what you do if you have to go through change control. I am not saying one side is better as I have spent hours trying to get simple stuff through CAB but what I was getting at that for those of us in the trenches we can't always dictate what we are going to use, also yes left-pad should have been picked up by CI but what about a fishy kernel update? or a change to shells or default behavior those would have been standard updates
@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.
@intrbiz @dick_turpin up until recently those test environments could be spun up using centos vms which would have been etc... but if you are staggering upgrades the you are no longer having your rolling server updates automagically happening. I believe it can be done just don't have the time here but would love a demo :)
@intrbiz @dick_turpin the shell issue was the ubuntu bash/dash change I was thinking of :)
@tig @dick_turpin sure, but it would only cause an issue inside the container and thus be caught in your CI pipeline.
@intrbiz @dick_turpin I am in awe of your perfect CI pipeline that catches everything. :) Any jobs going? :)
Some of us are having to take care of somewhat older software :)
@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.
@intrbiz @tig @dick_turpin openSUSE Aeon is working great for me. Updates do come in large amounts sometimes like today's 1014 packages.
My ArchlinuxARM server running its systemd-nspawn containers for services has now clocked-up over two years of hassle-free service.
Coming from staged-release distributions and VMs to rolling distributions and containers has been a positive experience for me.
@intrbiz @dick_turpin there is that but if I am called out in the middle of the night I want to know the platform is where I left it... A classic example is the famous left-pad npm issue