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 …
These are people who, the CentOS team said, "never called, never write, they don't interact with us."
I would have thought that these are the people that Red Hat/CentOS would have wanted to attract. They give no trouble, do not take up time and resources and generally have no impact on the bigger picture. Or is that why these people are so unattractive to Red Hat? There is no way of influencing them, there is no data to be mined and maybe Red Hat just sees them as freeloaders. If so, why bother claiming that the ethos of Red Hat/CentOS is that of "free software"?
This group may be evangelising others or otherwise spreading the word about how good Red Hat/CentOS is. They may be small non-profit concerns or small businesses with someone capable of running their systems without the paid for hand-holding that constitutes the main source of income for Red Hat.
It seems to me that Red Hat is getting a little too large for their boots and seems to forget that in the FOSS world people have a choice and that antagonising their users is probably not the way to make friends and influence people.
In any sane software organisation the level of quiet contentment CentOS users had for the product would produce a warm feeling in management, knowing that these users had a pain free transition into the paid-for product should they so decide. Instead they decide to take a model that’s been working for years and drop kick it over the nearest cliff.
The CentOS forum currently has 78% (ok, only from 81 votes) of respondents looking to leave before maintenance support dies, v8 users are not happy bunnies. There'd have been a lot less upset caused if they'd announced v8 support was now following the v7 timeline with its 2024 EOL.
"The CentOS forum currently has 78% (ok, only from 81 votes) of respondents looking to leave before maintenance support dies, v8 users are not happy bunnies. There'd have been a lot less upset caused if they'd announced v8 support was now following the v7 timeline with its 2024 EOL."
The irony being that those 81 votes are the people who DO call, write and interact!
These are people who, the CentOS team said, "never called, never write, they don't interact with us."
That's because most of the time it just works. Why talk to them if it just works.
I used to work in support for a large Unix vendor, in support you only ever see the problems. I never had a customer ring me up and say "Hey Dazed, you know everything is just fine today, nothing wrong, no problems".
After I moved on I did some work with a company who used the systems I used to support, I ended up taking the manager out for a drink with my old support colleagues just so they could meet a happy customer say "the only time I login as root is when some joins or leaves and I need to add/remove accounts..."
If people aren't bitching is might be because they've not got anything to bitch about.
Because there were no Engineers working on CentOS, since it was just a very small "community" of rebuilders.
But now you can submit patches against Stream against a version RHEL engineers built. Still on a gratis basis, so no SLA (like on any other gratis distro), but much closer to the source.
Because there were no Engineers working on CentOS
That's fine, but it's disingenuous to then claim: "they don't interact with us." when the primary way users *would* interact with upstream is getting no attention/support/etc.
now you can submit patches against Stream
Yes, the theory is that this will be more valuable to RHEL, but that remains to be proven. Red Hat already has much of that from Fedora, so it's not certain at all they will be very interested / responsive. Until recently, the theory was that Red Hat knew CentOS provided a lot of value...
If there's a problem with a fresh RHEL package, users who hit the bugs have a support contract and will see it quickly fixed by the source. With Streams, that "no SLA" issue might leave you in a very bad state for a long time.
At most ‘at scale commercial Cloud Hosters’, ‘free’ CentOS is a default Linux option. They even have packed up ‘ready to go’ images to deploy.
Perhaps a few shekels from their likes into the CentOS project would not have been a bad idea. They are making money off the hosting... even if it’s used to just house v Infra appliances like vRouters/LoadBalancers.
Then RedHat acquired it (the decided to sponsor it). This meant that Centos did not need to worry about funding and so lost the ability, and memory of, how to fund itself. Now that that is lost: RedHat has changed the rules and Centos has to follow them as it is no longer able to be independent. This is rather like a corporate buying its competitor.
The discussion about streams is a red herring.
Not caused by us. We migrated our Centos servers to Debian in 2013 and never looked back. Mainly to maximise compatibility with our Kubuntu workstations. Not so much software as wetware - remembering when to type apt instead of yum.
Looks like a good decision. I'm afraid we find Ubuntu Server a bit too 'racy'. Servers are meant to be boringly stable for the maximum time possible. It's not like the old days when progress was steeper and worth breaking stuff occasionally. Nowadays progress is slower and incremental and the greater complexity gives even more opportunity to break things.
Hence the Debian EOL cycle means we can leave 'em be for 4 years by which time a hardware change is usually desirable. So today Stretch & Buster - and towards the end of the year the remaining Stretch stuff will probably move to Bullseye and so on till Debian's funders get itchy.
Not sure who they are. But, at least, it ain't IBM and hopefully not another of the gobblers.
ZFS is probably missing bits in every Linux except Oracle's : the licensing is such that there are arguments that it can't be incorporated out of the box into any distribution. If you - as a user - choose to do that for yourself - that's different. You can get ZFS on Debian - you can even get root partition on ZFS on Linux - but it's not officially supported.
To me, ZFS is a non-issue because if you need ZFS, then you need some kind of data store/retention that should be dedicated on BSD (most likely). That said, not only can ZFS work under Linux, it's actually maturing faster than BSD's and some claim it currently outperforms BSD's. If the Linux dev's ironed out BtrFS (not sure they have), that would work just as well as ZFS. There's nothing magical about ZFS, someone just essentially threw Reed Solomn at a TOC during a time when non-super computers were finally feasibly fast enough to use the matrix (PAR2 is another notable example).
Rubbish.
apt install zfs works on Ubuntu, as they tolerate the license. On Debian, you have to enable the non-free repos, and it is supported via DKMS, so you get to recompile from source for each kernel upgrade.
So, like I said. A missing bit.
Much of the point for RedHat, and by extension, old CentOS was that it was a stable development target. Centos streams objectives are, as far as I can tell, little different to Fedora to be a testing ground for new.
Without a cost effective way to develop/test stuff on RedHat without licensing it a) costs for those that use RedHat will go up, and b) centos users will go elsewhere. An unintended consequence of both is that if there is justice, a new "standard" distribution could emerge outside the claws of IBM. Suse perhaps the most obvious choice, what being freely usable and licensable if you want the latter.
Truth of the matter is I only keep centos around at all to run drivers for an LTO tape drive that I haven't yet got working on alternatives.
Why doesn't Red Hat simply say, you can use RHEL in production for free if you do not require support?
Red Hat would surely be much better off simply saying you can use RHEL in production for free if you can provide all necessary support?
"The core of the programme is still focused on developers, but there is going to be a use case here for hobbyists, system administrators and others who don't self-identify as developers. Remember that a component of the announcement that we made is around development teams in enterprises. So I don't want people to think we bolted this on."
Quite so. Regarding those others who don't self-identify as developers ...... would particular interest and enterprise be afforded to project creators with accompanying dedicated programming drivers? Blue Sky Thinkers and Deep and Dark Web Tinkerers with Practically Viable Utilities in Command and Control of Virtually Real Abilities via Remotely Accessed Facilities?
It's certainly a fine destination/starting point/launch pad/project for programming projects and programs not entertaining pogroms.
[Definitely something wrong with the comments UI, El Reg. A lot of dead space suddenly appearing which never happened before unless decidedly intentional]
No. That's not how it works. One subscription per server, thanks, as far as Red Hat is concerned if you're using it in production. Sorry to see that they regard the provision of software updates and security fixes as being paid for support - that's just standard running for a security conscious Linux distribution: you have to pay extra for it and people won't do it. Charge for support for problem solving / corner cases, yes, but not for security updates.
>Sorry to see that they regard the provision of software updates and security fixes as being paid for support -
And presumably recognise that you redistributing those changes to yourself for the other servers is covered by the GPL
Really!? I'm behind a pi hole so just see the dead space. Up until last year I'd have considered a subscription to fund el reg, but it's been downhill since the move to .com
BTW did I miss the coverage of the Sonicwall hack on here?
BTW did I miss the coverage of the Sonicwall hack on here?
The one in this week's security roundup article or This one from October? They could have made a full article about this week's, but they do have a section.
Used CentOS at a previous role, and they were migrating away to Debian 10+ years ago.
I've only installed Debian servers since. Don't honestly see any benefit now unless you're stuck with Orable.
CentOS is a massive loss. RHEL wax lyrical about support including the patches etc, but forget all the FREE work they get out of the community.
Guess that gate doesn't swing both ways, eh RHEL?
" When somebody says it's not about money...
... it is about money."
Hey, we are talking about IBM here: *Everything is always about money*. No matter how much they lie about, it's about *profit*.
Them MBAs having no clue how to make profit is another thing, but they don't *ever* think anything else. Shooting customers is totally OK to them as long there's profit in it.
I switched my ~ 100 servers from CentOS 8 to CentOS 8 Stream on the day of the announcement in less than 10 minutes (looking at you Ansible). And I am running nightly yum update on all of them.
I just don't get what all the fuzz is about? You want free RHEL? Take CentOS Stream, it even comes without the 2 month delay of security patches as old CentOS. Or are you saying you want to stay on something that always struggled to keep up?
You go from free CentOS to *paid* Ubuntu, because Red Hat keeps investing in a free copy of their paid RHEL - you were never willing to buy - that is not months behind? But somehow they are now evil and you rather put your money into a company, that depend on their (benevolent) dictator, was never profitable and layed off tons of folks recently?
You rather go to Oracle - which still has to wait on RHEL to be released - or to one of the other - hopefully (keeps fingercrossed) soon released - RHEL rebuilds, that still need to wait on RHEL and will struggle to keep up? All because screw Red Hat, but each one of your alternatives still fully depends on Red Hat and so are you...
I don't get it...
I'm glad you have found CentOS Stream useful. Many don't.
Some common use cases need the ability to define the environment unambiguously and require an environment that does not change rapidly.
Eg a software company can guarantee that Version 97 of frobulator enterprise edition works on RHEL 8.x. Something that is *significantly* different to RHEL 8.x isn't going to be any use to them. Developer licence might be OK for them depending on the size of the operation.
Eg. Large academic users (multiple clusters with 10^5 cores, computations/simulations lasting months, online data processing at petabyte rates) don't really want a random stream of weekly updates. The throwaway sarcastic comment by the corporate type quoted in the OA about 'not wanting to stop cancer research' was aimed at this use case I suppose. Probably not going to earn any PR points for RH there, but we shall see what appears. For this use case farting about with subscription servers, phone home auditing &c will go down like a bowl of sick.
> Something that is *significantly* different to RHEL 8.x isn't going to be any use to them.
I think you have a basic misunderstanding here. CentOS Stream 8 will never be significantly different from RHEL 8; CentOS Stream 9 will never be significantly different from RHEL 9. All updates headed for CentOS Stream are already approved to land in that major release of RHEL, with the same general rules about stability that RHEL holds to.
More about this on the CentOS blog here: https://blog.centos.org/2020/12/centos-stream-is-continuous-delivery/
Missing a point here when it comes to many of the use cases mentioned have a factor called reproducibility tied to them. Whether it's nuclear weapons simulations or anything to do with sciences and medicine, no updates are allowed either during or between runs of the software. That's why there's been a hard push for both code and the datasets, along with which updates were in place, for all research these days. Without it, you aren't doing science.
I have the same issue in AI/ML as with my engineering projects which is why I'm quite meticulous about my configurations. Stability and reproducibility are absolute. For this, Centos Stream is right out. [And yes, none of these machines are connected to anything except each other on an isolated network due to non-existent security patches.]
How exactly is stream here any different than CentOS?
If you truly want a reproducible repo, you snapshot CentOS - whether it is Stream or not - into a dedicated on-site repo. So how is Stream any different than regular CentOS? Will the packages in your air-gapped mirror magically be updated?
Mlupo asked: "If you truly want a reproducible repo, you snapshot CentOS - whether it is Stream or not - into a dedicated on-site repo. So how is Stream any different than regular CentOS?"
I'm guessing that they want it to be easy for someone else, long after the event, to be able to easily use exactly the exact same version of the OS.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
