The killing of CentOS Linux: 'The CentOS board doesn't get to decide what Red Hat engineering teams do' Brian Exelbierd, responsible for Red Hat liaison with the CentOS project and a board member of that project, has told The Register that CentOS Linux is ending because Red Hat simply refused to invest in it. Early last month Red Hat shocked users of CentOS, a free community build of the same sources that make up the commercial …
"If business model includes non-revenue"
Talk about dinosaur outlooks. Of course non-revenue contributes to the business model. Being perceived as trustworthly, reliable, or just plain Not-IBM, is important to anyone's business model. To say nothing of social factors of the "high tide floats every boat" type.
Not that it matters at this point; RedHat was doomed the moment IBM touched it; it's just a question of how long the life support will be left on now.
The number of companies that I have consulted for that used CentOS in all of their non-mission critical systems but still paid for RHEL for all front-facing mission critical systems is currently at 100%. Getting rid of the backend does not mean they will sell more, it means they will lose these customers. So short sighted.
My employer uses CentOS for development and testing, and for running in-house code.
We buy RHEL for anything where we might need support (or where IT wants to spread liability for outages.) That's basically all the Production and customer-facing servers. And for expensive software that specifies RHEL like large databases.
There's really only a small group of people promoting Linux here. We just had to slam the brakes on deploying CentOS 8, had to defer some server upgrades, and have to reconsider budget for some Linux-hosted Expensive Software. The hardware is coming. We have a Windows roadmap. We're scrambling to make a new Linux roadmap and to restore confidence that it has a future here.
As someone who much prefers to run Linux than Windows on servers, this sucks.
I have an open source project which I test on about a dozen different distros, including a couple of BSD variants. I have a fully automated test system which cycles through all the supported platforms. When I make a new release I then give a list of platforms which it was tested on, including which version.
One of those distros is Centos. If Centos Stream is just a rolling release then there's not much point in testing on it, as I can't then say that a specific version is tested and supported.
I have no intention of signing up for a developer account as I have no desire to jump through their hoops and become one of their minions just so I can do free work for them.
I'll keep the current Centos VM in the test system so long as it remains relevant, but once it gets too old compared to their current Red Hat release however, then I'll just drop it. As someone running an open source project, It's really not worth the effort to support a distro that anyone puts hurdles in front of.
It too is an RHEL rebuild which is 100% compatible with upstream just like CentOS Linux. Oracle even has a script you can use to switch from CentOS and the distro is free to use for all purposes with no special licensing changes. It has also been quicker to release patches than CentOS for quite a while.
Of course, if you’re looking for something that isn’t RHEL and want an enterprise-grade solution with full community support, openSUSE Leap is looking like a pretty sweet option now, as it’s downstream from SUSE Linux Enterprise except with community supplied goodies on top. It might not get quite the amount of battle testing that Fedora gives to RHEL but bugs you file against it will be looked at as if they’re bugs affecting SLE too in a lot of cases, so there is that,
Containers don't care if you're running Slackware. Or anything else. I can tear out YYY Linux and replace it with ZZZ Linux and docker will never know or care.
Heck, docker on windows works. I don't exactly recommend it, but it makes a cool party trick. At least at the kind of parties I go to these days, which tend to be held via zoom and that isn't making them any worse...
Yeah, OK, there are gotchas if the container has to reach down into /dev and do - unsanitary - things. Granted.
I'm curious. How many instances of RedHat are running worldwide, compared to Amazon Linux? I can't say I've ever missed not having pre-built CentOS AMIs. They probably exist but they don't show up in the first few screenfuls of options.
Icon: let me grab my coat and I'll run out to the car and get a different distro for you.
kind of, unless you want a container with (just) apache, imagemagik perl python and bash, you are likely better off having a distro put those together with a compatible libc. If all you run is your own code you are not really a classic linux/opensource user.
What's true is that redhat have not done much in the container space as they desperately try to hang on to os licence sales and are becoming increasingly irrelevant, while debian/devuan and Ubuntu do that job well, as part of providing a full server/desktop.
If you're working in healthcare, or a number of other areas, then you may need to "validate" your environment according to ICH-GxP or a similar standard. You really, really, *really* do not want to have to go through this more often than you have to. You have to revalidate *every time you change anything about the system*. Generally, this means re-testing everything you care about, with test scripts, with each step on each test script initialled to say it has been run and each script signed and dated and run by someone who has demonstrated the knowledge, skills, and experience to run that script and understand what they're doing. This can easily take a couple of months. Then there are days of paperwork to release onto the production systems.
Monthly security patch cadences are far too fast for validated systems. Annual... maybe, but only if you can make them coincide with other updates and test the whole lot in one go.
Oh, indeed - there's a reason anything "healthcare" costs 10x more than non-healthcare, and the validation and consequential license fees are one part of that. That said, we chose CentOS over RHEL because a) we knew what we'd be paying for features like virtualisation, and b) we could bring support in-house if absolutely necessary. We chose Linux over VMware for our virtualisation layer because of VMware's complete lack of LTS; having to upgrade your virt layer every couple of years to retain support sucks.
Given RedHat's history in the HEP world (circa 2003) I noticed that exact quote. The history is out on the Web but basically RH wanted to charge *per core* in those days.
I think we can say that fermilabs and CERN will be restarting their own builds quite soon. Unless that drive by throwaway about 'not wanting to stop cancer research' actually results in a concrete low friction offer to large scale non-commercial users. Which would be sensible.
By low friction I mean none of that special phone home audit server bullshit.
Quite. Furthermore, phone home is simply not possible in some environments -- completely isolated from the internet. It can be a challenging (and irritating) environment to work in sometimes, but I get it.
It can be an adventure sometimes trying to track down what the OS vendor slipped into their config, assuming that internet connectivity was a given.
Does this sort of compare with Microsoft's Insider Program? - Fedora = Dev Channel, Stream = Beta or Release Preview Channels, Red Hat = Release.
Noting that MS requires you to own a copy of Windows to access the Dev options whereas Stream/Fedora are free. And yes the MS Beta Channel is usable as a daily driver.
If so it seems a muddled way of labeling it all? Any rather implies that Stream and Fedora are not production level OSes?
They are not. Production requires repeatability so you can repeat the build exactly as you did on test, so you can guarantee that what you're releasing your product on is exactly what you tested on and the customer approved. RHEL and Centos do that but not stream as it changes every day.
Also I don't know anybody who runs yum update every day, that's madness in a production environment.
Not sure what we'll be doing yet, we won't be paying RedHat. Centos has been rock solid for us, now need to find and test and alternative.
Yeah, we were in the early throes of a centOS 8 upgrade programme when this was announced. We've now retooled and are going Ubuntu and becoming a paid customer of Canonical instead of red hat. Noone appreciated the EOL rug being pulled out from under us, and the response of everyone from engineers to directors was 'screw redhat' except not as polite as that.
We are still in the "Decide where to go" process where I work.
We are a large education place, and have a lot of dual-boot systems sitting around for students to use as they see fit. We use Scientific Linux for this, and were going to use CentOS right up until RedHat decided to drop that particular bombshell. Now we have to decide which way to go, and Ubuntu LTS is looking bloody good as an option right now.
After all, past behaviour is known to be a good predictor of future behaviour, and RedHat have just gone back on their word big-time. They've done it once, they'll do it again in future. How many times do we want to have the "Which way now" discussion?
We decided to migrate our existing CentOS and RHEL systems to SUSE (SEL/openSUSE). Mostly because we already have most of our machines on SUSE, which is also the 2nd largest enterprise Linux vendor after RH (and SEL is the default supported platform for SAP HANA and other large software).
We looked at Ubuntu a few times but it's not even close to RHEL, CentOS and SUSE when it comes to stability, and Canonical's enterprise offerings are a far cry from what you get from RH and SUSE. There's also a reason why Ubuntu is known as "Windows amongst Linuxes".
We've been on SUSE for more than 10 years and it served us very well. And SUSE has made repeated commitments towards openSUSE so it's not going to go away in the foreseeable future.
It depends largely on who is trying to do the installation. There is a class of people who are blissfully ignorant of release notes, hardware compatibility lists, installation guides etc. Maybe it's because Microsoft never bothered to provide this for more than two decades.
Or alternatively - it does exist for windows but rarely needs consulting. A well-designed installation process should not need so much documentation, it should provide the user (installer) with a good experience that meets their needs - sort out any problems that can be automatically sorted out, recommend solutions to others and be on the users side. It should not, as debian attempts to do, just sit by and watch the user try and do the install, then regularly beat them with a stick and tell them they did it wrong and to start again, but with no additional guidance.
That comment about Ubuntu stability and enterprise offerings is just pure FUD. I've experience of Ubuntu, CentOS and RHEL and they're much of a muchness these days. A solid enterprise experience which ever one you choose. Ubuntu LTS is a sensible and safe alternative to CentOS.
We're in "wait and see" mode for our existing systems. CentOS 7 (unless RH changes their mind) is supported until 2024, so we're going to stay on that horse while the dust settles for the next 12-18 months to see which alternatives are looking good at that point.
But for new projects, I don't know what to suggest. I worry that things on whiteboards now need to be built over the next 6 months, and I don't know what we want to be supporting for the next 4-5 years.
A lot of our developers are keen on Ubuntu, but most of our new projects are containers.
Beware of the "Snap" applications in Ubuntu 20.04 desktop. I don't know if they are in the server version of Ubuntu, but I had to switch from Ubuntu with the 20.04 release because of system stability issues and the snap applications, in some cases, just don't work at all. The transition to Debian was quite painless and involved much less time to implement than the time I wasted trying to get a working Ubuntu 20.04 system. I tried on several systems (old and new) with similar results. Still running Ubuntu 18.04 on a new Lenovo laptop, however, as I can't get Debian to complete the boot process. Your mileage may vary.
Used Centos Small scale for a while, we were about to bump to 8 and have a much larger setup we had planned to Initially deploy and launch in a month after much documentation and testing with a view to moving to RHEL later. So now I have wasted a good few months work and nothing is as portable as intended. I won't be giving them any money at all now. For a stable production environment stream is utter madness
Speaking of rocks... wonder what this means for Rocks? Current version is based on Centos 7.
We did Ubuntu for a while, it's always been a little odd in how it approaches some things (dash, no-root etc.) and I usually find RH more comfortable in terms of how things are configured generally. But these are mostly quirks when you compare to things like dropping Mate.
This post has been deleted by its author
The Register - Independent news and views for the tech community. Part of Situation Publishing
Biting the hand that feeds IT © 1998–2022
