CentOS Project shifts focus to CentOS Stream(lists.centos.org)
lists.centos.org
CentOS Project shifts focus to CentOS Stream
https://lists.centos.org/pipermail/centos-announce/2020-December/048208.html
632 comments
This is awful. It's proof of the downsides to the IBM acquisition, which I think we all knew was coming.
Imagine if you were running a business, and deployed CentOS 8 based on the 10 year lifespan promise. You're totally screwed now, and Red Hat knows it. Why on earth didn't they make this switch starting with CentOS 9???? Let's not sugar coat this. They've betrayed their users.
I personally run a CentOS 7 server (as do members of my family), and was planning on upgrading them all to 8. Luckily, I didn't get round to it yet. I guess I'll have to consider an alternative. For my server I want a boring, stable OS, so I'm definitely not using Streams. This is going to ripple throughout the whole industry, as CentOS is used all over the place, from regular home users to businesses (and things like CloudLinux).
It's very disappointing that Red Hat can't see the damage they'll do not only to the community, but to themselves too. Someone will come along and take the CentOS user base, and it won't be Red Hat :(.
I personally run a CentOS 7 server (as do members of my family), and was planning on upgrading them all to 8. Luckily, I didn't get round to it yet. I guess I'll have to consider an alternative. For my server I want a boring, stable OS, so I'm definitely not using Streams. This is going to ripple throughout the whole industry, as CentOS is used all over the place, from regular home users to businesses (and things like CloudLinux).
It's very disappointing that Red Hat can't see the damage they'll do not only to the community, but to themselves too. Someone will come along and take the CentOS user base, and it won't be Red Hat :(.
>> Imagine if you were running a business, and deployed CentOS 8 based on the 10 year lifespan promise. You're totally screwed now, and Red Hat knows it.
The hypothetical you posed is the actual situation, I am now learning, I have apparently forced on my team. We've ramped up labor 3x revenue preparing product launch in 90 - 180 days. We created an image containing centos 8 , Java , postgres and tomcat a year ago and that what is deployed to beta clients and what we've been testing.
What's ironic is that I sort of went out on a limb with my team by forcing us to go with Linux over Windows and the way I allayed concerns was to ask them to just "wait and see" in hopes that the performance differential would make it a moot point.
edit: after a little thought it seems that moving to RHEL might cost us the least amount of money and downtime. Still sucks and not what we need to be working on right now.
The hypothetical you posed is the actual situation, I am now learning, I have apparently forced on my team. We've ramped up labor 3x revenue preparing product launch in 90 - 180 days. We created an image containing centos 8 , Java , postgres and tomcat a year ago and that what is deployed to beta clients and what we've been testing.
What's ironic is that I sort of went out on a limb with my team by forcing us to go with Linux over Windows and the way I allayed concerns was to ask them to just "wait and see" in hopes that the performance differential would make it a moot point.
edit: after a little thought it seems that moving to RHEL might cost us the least amount of money and downtime. Still sucks and not what we need to be working on right now.
What I don't get is this:
You build software, you ship it on an OS so it works, cool, this makes sense (I assume you need hardware and VM support, not just VM).
Why would you accept additional risk on the OS if you can easily reduce the risk, and ultimate cost, by going with an OS that has vendor support written into the actual contract? RHEL is 11-13 years total, Windows is... I'm guessing my grandkids will be using some form of Windows 10. CentOS is, and always was a community "best effort", with some serious delays occasionally (not often, but it happened).
A RHEL server license starts at $349, I have to assume that's at least an order of magnitude (or two or three) less than the cost of your software based on the technologies involved (sounds enterprise-solutiony). In other words a rounding error overall.
You build software, you ship it on an OS so it works, cool, this makes sense (I assume you need hardware and VM support, not just VM).
Why would you accept additional risk on the OS if you can easily reduce the risk, and ultimate cost, by going with an OS that has vendor support written into the actual contract? RHEL is 11-13 years total, Windows is... I'm guessing my grandkids will be using some form of Windows 10. CentOS is, and always was a community "best effort", with some serious delays occasionally (not often, but it happened).
A RHEL server license starts at $349, I have to assume that's at least an order of magnitude (or two or three) less than the cost of your software based on the technologies involved (sounds enterprise-solutiony). In other words a rounding error overall.
As a sysadmin in academia, this is not so straightforward. Since number of servers/VMs are in ballpark of over one hundred, RedHat license costs will be over 30,000$/year. This is not insignificant amount of money and not easy to get the money suddenly.
$30k is a significant amount, especially in academic environment, I don't deny it. But it's not much for > 100 servers. In my previous job, I had licenses which were about 15k€ for one server (thanks Oracle...) and the Windows Server licenses were also pretty expensive.
$300-500 per server/year is not much more than a Photoshop license for one designer. And if we talk big business (1000's of servers and even more), you will get very special pricing anyway.
Not just price, but ability to function without constant access to the satellite portal. It's darn near impossible to upgrade a RHEL box from a work at home VPN environment.
[deleted]
> edit: after a little thought it seems that moving to RHEL might cost us the least amount of money and downtime. Still sucks and not what we need to be working on right now.
And that is exactly what IBM is counting on. Vendor lock in.
We are switching to Debian-based distros because, frankly, we don't trust IBM not to knife us in the back even on RHEL for more money. Of course we have the advantage of being able to take the time to convert.
And that is exactly what IBM is counting on. Vendor lock in.
We are switching to Debian-based distros because, frankly, we don't trust IBM not to knife us in the back even on RHEL for more money. Of course we have the advantage of being able to take the time to convert.
This is not about IBM. It may not be a pleasant change for everyone, but it's a change that has strictly technical motives.
CentOS was acqui-hired because Red Hat's upstream for layered products (at the time mostly RDO/OpenStack and oVirt/RHEV) could not use Fedora because it was too far from RHEL a year of two after RHEL was released, could not use RHEL because upstream contributors would have to pay, and could not use CentOS because its releases had too large delays. The solution was to make CentOS releases happen timely by paying people to make them.
These days a RHEL downstream is not enough for the layered products. Some of them require the kind of bleeding edge feature that is backported every six months to the RHEL kernel, and corresponding userspace changes (BPF, virtualization, etc.) and cannot afford waiting for the CentOS release because development must be done in parallel with RHEL. So the solution was to move CentOS from happening after RHEL to before RHEL which is what CentOS Stream is.
I can confidently say that the reasons are technical because other CentOS downstream have the same needs (e.g. Facebook's) and they also want to send patches to CentOS for bugfixes or features themselves, instead of waiting for Red Hat to find out about that bug, or decide they need the same feature. Plus there's no reason for rebuilds to disappear. The SRPMs will still be released by Red Hat.
CentOS was acqui-hired because Red Hat's upstream for layered products (at the time mostly RDO/OpenStack and oVirt/RHEV) could not use Fedora because it was too far from RHEL a year of two after RHEL was released, could not use RHEL because upstream contributors would have to pay, and could not use CentOS because its releases had too large delays. The solution was to make CentOS releases happen timely by paying people to make them.
These days a RHEL downstream is not enough for the layered products. Some of them require the kind of bleeding edge feature that is backported every six months to the RHEL kernel, and corresponding userspace changes (BPF, virtualization, etc.) and cannot afford waiting for the CentOS release because development must be done in parallel with RHEL. So the solution was to move CentOS from happening after RHEL to before RHEL which is what CentOS Stream is.
I can confidently say that the reasons are technical because other CentOS downstream have the same needs (e.g. Facebook's) and they also want to send patches to CentOS for bugfixes or features themselves, instead of waiting for Red Hat to find out about that bug, or decide they need the same feature. Plus there's no reason for rebuilds to disappear. The SRPMs will still be released by Red Hat.
That in no way explains why they don't continue to have both. They indeed will have both for another year. There was no requirement the Stream product even use the CentOS name.
CentOS was a community project whose leadership and control was taken over (acqui-hired as you say) by Red Hat and then it's core use case for the majority of people actually using it was discontinued. That is a statement of facts that happened as I understand them, not some spin on my part.
If Red Hat had not stepped in, perhaps some of CentOS problems (trouble getting releases out on time) would have been worse, or perhaps some other companies would have stepped in. We don't know, but we do know that CentOS has not been changed to be something different than it was before. It used to be a free re-spin of RHEL. Going forward it's something entirely different.
Red Hat always had the option to stop funding/providing resources to CentOS and name their new thing something else, but they didn't, and now they've effectively co-opted CentOS to be something different than it was originally intended to be.
CentOS was a community project whose leadership and control was taken over (acqui-hired as you say) by Red Hat and then it's core use case for the majority of people actually using it was discontinued. That is a statement of facts that happened as I understand them, not some spin on my part.
If Red Hat had not stepped in, perhaps some of CentOS problems (trouble getting releases out on time) would have been worse, or perhaps some other companies would have stepped in. We don't know, but we do know that CentOS has not been changed to be something different than it was before. It used to be a free re-spin of RHEL. Going forward it's something entirely different.
Red Hat always had the option to stop funding/providing resources to CentOS and name their new thing something else, but they didn't, and now they've effectively co-opted CentOS to be something different than it was originally intended to be.
> That in no way explains why they don't continue to have both
Because they don't need it anymore. CentOS Linux or other rebuilds can still exist (just not using the name; I disagree with that but I can understand Red Hat doesn't want its name attached to something that might have large delays in security fixes in the future) if somebody funds it or volunteers to do it, just like CentOS still supports Xen but RHEL does not.
Also for what is worth there have been lots of engineering changes to RHEL in the past couple of years that make nightlies (and CentOS Stream) much more stable than they used to be, especially with respect to regressions. Running CentOS Stream is not going to be like Fedora Rawhide or Debian sid.
Because they don't need it anymore. CentOS Linux or other rebuilds can still exist (just not using the name; I disagree with that but I can understand Red Hat doesn't want its name attached to something that might have large delays in security fixes in the future) if somebody funds it or volunteers to do it, just like CentOS still supports Xen but RHEL does not.
Also for what is worth there have been lots of engineering changes to RHEL in the past couple of years that make nightlies (and CentOS Stream) much more stable than they used to be, especially with respect to regressions. Running CentOS Stream is not going to be like Fedora Rawhide or Debian sid.
>>> it's a change that has strictly technical motives.
I understand the business reasons for doing so. I don't agree with anyone branding this as done for purely technical reasons. Having CentOS Stream may be needed for technical reasons. Stopping CentOS 8 is in no way a technical decision. They are unrelated in any technical sense.
If Red Hat just doesn't want to put resources towards CentOS as it traditionally existed anymore, that's their option, but they deserve any flak they get for taking over an open source project just to extinguish it, since CentOS is in no way really needs to be linked to their Stream product. They could just as easily called it RHEL Stream and said it's free, and it would be a less confusing and more direct funnel of people that want RHEL stability into RHEL subscriptions. Using the CentOS name is just a mind-share grab and screwing over an open source community. They control it so can do it, but that doesn't mean I'm not going to call them out for doing so.
I understand the business reasons for doing so. I don't agree with anyone branding this as done for purely technical reasons. Having CentOS Stream may be needed for technical reasons. Stopping CentOS 8 is in no way a technical decision. They are unrelated in any technical sense.
If Red Hat just doesn't want to put resources towards CentOS as it traditionally existed anymore, that's their option, but they deserve any flak they get for taking over an open source project just to extinguish it, since CentOS is in no way really needs to be linked to their Stream product. They could just as easily called it RHEL Stream and said it's free, and it would be a less confusing and more direct funnel of people that want RHEL stability into RHEL subscriptions. Using the CentOS name is just a mind-share grab and screwing over an open source community. They control it so can do it, but that doesn't mean I'm not going to call them out for doing so.
The thing is, Red Hat never considered the distro more than a side effect of providing a base for developing "things" that will run on RHEL. It's even written on the centos.org home page, the distro is not why CentOS existed in 2020. So the fact that users (including myself!!) enjoyed a free distro as a result was not a part of Red Hat's RHEL strategy in any way.
That only makes sense if Red Hat started CentOS. They didn't. The fact that they took control of it then changed it, even the web page, and then are not effectively killed the reason people are using it, is the thing I'm upset about.
If I effectively took control of the EFF and then a couple years later changed the website copy to say that the EFF is a vehicle for litigating cases that kbenson thinks are important, and then actually changed its actions to do so, would you argue the same points? How is this any different? Something that was a net good for many people has been taken over and eventually killed. I think we're all worse off for that.
If I effectively took control of the EFF and then a couple years later changed the website copy to say that the EFF is a vehicle for litigating cases that kbenson thinks are important, and then actually changed its actions to do so, would you argue the same points? How is this any different? Something that was a net good for many people has been taken over and eventually killed. I think we're all worse off for that.
> I think we're all worse off for that.
I don't disagree.
I don't disagree.
IBM is all about expensive support contracts. We cannot afford RHEL. So we went with CentOS 7 and recently CentOS 8. I migrated some machines from 7 to 8. Turns out I did that for one year. My boss wasted precious money there, and it isn't getting us closer to RHEL. My take is its getting us closer to Debian Stable instead. Which is RedHat's loss because a migration to RHEL is then more out of the picture. They know this. They thought of the above. And they are fine with it. That is not a technical decision, as you said. It is a business decision.
> Because they don't need it anymore.
Isn’t that the crux of the problem? CentOS used to be about “us” (the users), not “them.”
Isn’t that the crux of the problem? CentOS used to be about “us” (the users), not “them.”
Fire up the wayback machine and find when the centos.org home page changed the mission statement. At this point it started to be about a different "us" than you think, an "us" that doesn't include you and me and presumably doesn't mind CentOS Stream at all.
In particular I started doing that and I got to the Sep 2019-Dec 2019 range, around the time CentOS Stream was launched. At that time this:
> For users, we offer a consistent manageable platform that suits a wide variety of deployments. For open source communities, we offer a solid, predictable base to build upon
was changed to this:
> CentOS Linux is a consistent, manageable platform that suits a wide variety of deployments. For some open source communities, it is a solid, predictable base to build upon.
In particular I started doing that and I got to the Sep 2019-Dec 2019 range, around the time CentOS Stream was launched. At that time this:
> For users, we offer a consistent manageable platform that suits a wide variety of deployments. For open source communities, we offer a solid, predictable base to build upon
was changed to this:
> CentOS Linux is a consistent, manageable platform that suits a wide variety of deployments. For some open source communities, it is a solid, predictable base to build upon.
> That in no way explains why they don't continue to have both.
They're a business ... are you honestly and in good-faith actually confused about this outcome?
They're a business ... are you honestly and in good-faith actually confused about this outcome?
Oh come now, this is Red Hat, a company based on Open Source software. We're not wrong for wanting to hold it to a higher standard. They have benefited from the OSS community just as they have contributed to it.
Red Hat didn't make CentOS they acquired it. This is very similar to a large corporation acquiring a smaller competitor, promising to continue supporting it, creating a new, different product using the brand, then dropping the original product.
Centos was always a free alternative to Redhat. I and many other people used it because it was a way to get the benefits of Redhat without paying for it.
This is a really smart more on their part to get people to stop doing precisely this, and getting them to pay money for RH. Pepople who are not willing to pay (me included) are now rightly annoyed, but we were never their customers in the first place, so we don't really matter.
This is a really smart more on their part to get people to stop doing precisely this, and getting them to pay money for RH. Pepople who are not willing to pay (me included) are now rightly annoyed, but we were never their customers in the first place, so we don't really matter.
I’m in the same situation, and I recently had started to plan on upgrading a small HPC cluster from CentOS 7. Before today, I had planned on CentOS 8.
Now? “¯\_(ツ)_/¯“ Probably Debian.
I’ve always used CentOS for clusters, but part of the reason for that is that there are some research packages that support RPM installation, but not deb. At least this gas historically been the case.
If a large amount (maybe even a majority) of users have to switch away from CentOS and RPM packaging, I think we’ll see an acceleration away from RPM as a default option.
So, in that way, I think we do matter, but just not on the balance sheet.
Now? “¯\_(ツ)_/¯“ Probably Debian.
I’ve always used CentOS for clusters, but part of the reason for that is that there are some research packages that support RPM installation, but not deb. At least this gas historically been the case.
If a large amount (maybe even a majority) of users have to switch away from CentOS and RPM packaging, I think we’ll see an acceleration away from RPM as a default option.
So, in that way, I think we do matter, but just not on the balance sheet.
I disagree. Having a pool of sysadmins / developers who know how to manage CentOS makes RHEL a more appealing alternative than Debian for many companies. The three companies I've worked at have primary used CentOS for development boxes. Shifting to an alternative will change who is familiar with CentOS / RHEL significantly for the worse.
We do matter. We are part of the OSS community that RedHat and IBM benefit from.
I'm not confused at all about that. I was responding to the point that said "it's a change that has strictly technical motives." It's a business decision that's based on profit and positioning and name mind-share, so let's not hide that.
Yes i am, redhat had a really good ride being the trustfully and good guy.
I'm wondering, what ties you so strongly to a single OS? Nay, to a single Linux distribution?
I have a hard time imagining, and the only scenarios that come to mind are those where things have gone awfully haywire.
I'm sure I'm missing something. Enlighten me?
I have a hard time imagining, and the only scenarios that come to mind are those where things have gone awfully haywire.
I'm sure I'm missing something. Enlighten me?
Software doesn’t run on its own. They rely on bunch of other software that is typically provided by distributions. So unless there’s some magic piece of technology that can take CentOS RPMs and make it work flawlessly on any Linux distro, the entire software industry is suddenly going to have to spend significant amounts of time on repackaging work.
There is alien[1], but I'm not sure if it is flawless, because of slightly different ways of doing things across distros like /etc/default vs /etc/sysconfig for example.
Depending on how good is the source, its usefulness and dependencies, packaging it to Debian is pretty straight forward. The dh_* helpers[2] does the job automatically most of the time. There is also tools for helping with specific languages, like dh-make-golang, dh-python, etc...
[1] https://packages.debian.org/buster/alien
[2] https://manpages.debian.org/testing/debhelper/debhelper.7.en...
Depending on how good is the source, its usefulness and dependencies, packaging it to Debian is pretty straight forward. The dh_* helpers[2] does the job automatically most of the time. There is also tools for helping with specific languages, like dh-make-golang, dh-python, etc...
[1] https://packages.debian.org/buster/alien
[2] https://manpages.debian.org/testing/debhelper/debhelper.7.en...
From the looks of it, alien is just a tool to convert between different package formats and is not a replacement for proper packaging work. Very much like how you can’t take a deb package from different releases of the same distro and expect things to work properly, you can’t just take RPMs from CentOS to a whole different distro and expect things to work.
It’s not only the differences in the packaging format that you have to take care of. There’s also version differences, path differences, dependency handling, and many other stuff to take care of. These are the kind of tasks which can’t be automated away and require non-trivial amount of work.
For organizations that maintain tens, hundreds, or thousands of CentOS packages that spans multiple teams, moving to other distros would be time-consuming and costly. It would certainly pay off if it was driven by technical reasons, but for organizations that are forced to switch by this announcement, this is just pure overhead.
It’s not only the differences in the packaging format that you have to take care of. There’s also version differences, path differences, dependency handling, and many other stuff to take care of. These are the kind of tasks which can’t be automated away and require non-trivial amount of work.
For organizations that maintain tens, hundreds, or thousands of CentOS packages that spans multiple teams, moving to other distros would be time-consuming and costly. It would certainly pay off if it was driven by technical reasons, but for organizations that are forced to switch by this announcement, this is just pure overhead.
>Java , postgres and tomcat
That's his stack...
>So unless there’s some magic piece of technology that can take CentOS RPMs and make it work flawlessly on any Linux distro,
It's not magic, just alien.
That's his stack...
>So unless there’s some magic piece of technology that can take CentOS RPMs and make it work flawlessly on any Linux distro,
It's not magic, just alien.
> >Java , postgres and tomcat
> That's his stack...
What’s your point and when did I ever mention Java?
> It's not magic, just alien.
Dumping the contents of an RPM archive on random distros is never going to work except for the most simple of cases.
> That's his stack...
What’s your point and when did I ever mention Java?
> It's not magic, just alien.
Dumping the contents of an RPM archive on random distros is never going to work except for the most simple of cases.
Took me a minute to figure out where that came from, it was in the GGP comment.
>Dumping the contents of an RPM archive on random distros is never going to work except for the most simple of cases.
That says allot about you packing hygiene, and you don't dump it..that you can do with tar alone. You convert it to a deb.
That says allot about you packing hygiene, and you don't dump it..that you can do with tar alone. You convert it to a deb.
That says a lot about your packaging hygine. With alien, you're essentially dumping the contents of an RPM on hosts it wasn't meant for. It doen't matter that you converted it to deb format along the way, it's the same if you actually install it.
MyMy, you have no clue how packages and a package-manager works right?
Did you ever read a single line of alien source code? It extracts the metadata and files from a package, and re-archives it. That’s about it. It doesn’t handle package version differences, path differences, distro-specific rules, nothing. If your package has dependencies, forget about it because alien won’t retain dependency information it all. In other words, it only “works” for the most simple of cases.
I suggest you read the source code too, because otherwise you can cause real damage if you use it without understanding how it works.
https://sources.debian.org/src/alien/8.95/alien.pl/
I suggest you read the source code too, because otherwise you can cause real damage if you use it without understanding how it works.
https://sources.debian.org/src/alien/8.95/alien.pl/
But surely if you depend on those packages, you can maybe track (or just collect) their versions, then get the same versions in another package manager (possibly via pinning).
Though my experience with package manager is that dependency management is hell (rife with potential conflicts), so I do see the problem a bit better.
Still, it shouldn't take that long to fix? Like a few days of sprint to setup Nix or something like that?
Though my experience with package manager is that dependency management is hell (rife with potential conflicts), so I do see the problem a bit better.
Still, it shouldn't take that long to fix? Like a few days of sprint to setup Nix or something like that?
I think it depends on the number of packages that you maintain. If it’s only a handful of packages, the entire process of repackaging, testing, and deployment might be doable in a matter of days. If it’s tens or hundreds of packages that depend on each other, I think that’s a whole different story. If those packages are maintained by different teams, it could take more than an year to complete the transition.
As for pinning packages, that’s only practical if you’re using Nix. As much as I prefer Nix over RPMs, not all of us have the pleasure of using Nix at work. It’s kind of a bummer because Nix packages are so much easier to work with and maintain compared to the competition.
As for pinning packages, that’s only practical if you’re using Nix. As much as I prefer Nix over RPMs, not all of us have the pleasure of using Nix at work. It’s kind of a bummer because Nix packages are so much easier to work with and maintain compared to the competition.
An existing support contract?
If you run a for-profit operation, and downtime is costly, you (or your VP of eng) want a way to pay for immediate assistance from the OS's maker / distributor, when (not if) things go wrong.
If you run a for-profit operation, and downtime is costly, you (or your VP of eng) want a way to pay for immediate assistance from the OS's maker / distributor, when (not if) things go wrong.
> If you run a for-profit operation, and downtime is costly, you (or your VP of eng) want a way to pay for immediate assistance from the OS's maker / distributor, when (not if) things go wrong.
There is a difference between asking "how do I ensure there is one throat to choke when things go wrong?", and "how do I minimize the potential for things to go wrong?"
RHEL is a decent solution if you are trying to answer the former question (or both), but many budget conscious orgs focused on the latter and chose CentOS. Red Hat has now pulled the rug out from under them by trimming eight years off the EOL previously committed to with little notice.
EOL in this case means "no security updates" so even if your org was prepared, technically, to deal with a zero-day for example by rolling out an update in a timely manner without relying on paying a vendor for hand-holding, that option has now been eliminated.
Essentially, you now only get the stability and problem-minimization if you also pay the vendor for support. Otherwise you're stuck with a (relatively) unstable rolling release that will keep your internal teams very busy with a constant stream of minor issues, or potentially trying to roll-your-own updates or backports after the EOL for anything serious.
It's difficult to see this as anything other than a naked, money-grabbing betrayal of users.
There is a difference between asking "how do I ensure there is one throat to choke when things go wrong?", and "how do I minimize the potential for things to go wrong?"
RHEL is a decent solution if you are trying to answer the former question (or both), but many budget conscious orgs focused on the latter and chose CentOS. Red Hat has now pulled the rug out from under them by trimming eight years off the EOL previously committed to with little notice.
EOL in this case means "no security updates" so even if your org was prepared, technically, to deal with a zero-day for example by rolling out an update in a timely manner without relying on paying a vendor for hand-holding, that option has now been eliminated.
Essentially, you now only get the stability and problem-minimization if you also pay the vendor for support. Otherwise you're stuck with a (relatively) unstable rolling release that will keep your internal teams very busy with a constant stream of minor issues, or potentially trying to roll-your-own updates or backports after the EOL for anything serious.
It's difficult to see this as anything other than a naked, money-grabbing betrayal of users.
I’d recommend using Oracle Linux 8 if you still need 1 to 1 compatibility. At my company I’m recommending Amazon Linux 2.
Not sure why I got downvoted. I’m trying to offer the poster a viable alternative to CentOS 8 with a minimum of changes needed. I get that a lot of people don’t like Oracle (and for good reasons) but really they are the best alternative (and free) EL8 disto now.
Consider downgrading to CentOS 7. It should work for 4 more years.
Can we take RedHat's word for it, though? CentOS 8 was supposed to be supported until 2029 before this bombshell announcement.
https://web.archive.org/web/20201101131417/https://wiki.cent...
https://web.archive.org/web/20201101131417/https://wiki.cent...
The dates on that page were always dependent on Red Hat. In retrospect, obviously we should have made that clearer, and we will endeavor to do so in the future.
Running modern versions of software on CentOS 7 can be a giant pain due to the old version of glibc that’s baked in.
I was supporting CentOS 6 until about a couple weeks ago.
Then surely you understand what a pain it is.
[deleted]
[deleted]
[deleted]
Out of curiosity why did you decide to deploy your application as a VM image? Is there a reason you didn't go with a Helm chart or other container native deployment?
You're asking why someone who uses CentOS hasn't gone with Helm charts?
That's like polar opposites of stability and bleeding edge.
That's like polar opposites of stability and bleeding edge.
I was curious what drove the decision to deploy that way. I was under the impression most new applications being developed today would choose a more modern deployment method. There’s a lot to maintain in a VM image like that, containers just seem easier to me. Helm chart or otherwise
The amount of maintainance with virtual machines images or container images are mostly the same nowadays.
I will argue that there is less maintenance when handling virtual machines images, because it uses less bandwidth and need less tooling around it comparing with container image based infrastructure.
But in general both are nothing more than the golden image concept.
I will argue that there is less maintenance when handling virtual machines images, because it uses less bandwidth and need less tooling around it comparing with container image based infrastructure.
But in general both are nothing more than the golden image concept.
>a Helm chart
As a sysadmin i have never heard of this and es tun 800 VMs.
As a sysadmin i have never heard of this and es tun 800 VMs.
It's a bundle of jinja2 templates for YAML files defining Kubernetes API resources. There's an accompanying application, Helm, which applies values to the templates and handles the interaction with the Kubernetes API.
Wonder if the web hosting industry will rebel and build another RHEL clone project that just gets the 10-year supported patches. Red Hat still has to release the patches, right?
A really big chunk of the world's traditionally shared hosted websites run on CentOS, because most commercial control panel packages and hosting automation systems are built for that. A rebadged CentOS is also AWS's default distro.
Wonder of the hosting industry, AWS included, will build a new stable clone of RHEL 8's upstream security patches. There are some big companies, like GoDaddy in there, whose business models are unlikely to accommodate for RHEL support subscriptions.
This is truly a bummer, and if someone doesn't pick up the pieces and continue offer RHEL rebranded, there's no(?) open sauce operating system with a decade-long support lifecycle. I wonder if this might cause an increase in unpatched servers and appliances when the alternatives offer five years at best.
A really big chunk of the world's traditionally shared hosted websites run on CentOS, because most commercial control panel packages and hosting automation systems are built for that. A rebadged CentOS is also AWS's default distro.
Wonder of the hosting industry, AWS included, will build a new stable clone of RHEL 8's upstream security patches. There are some big companies, like GoDaddy in there, whose business models are unlikely to accommodate for RHEL support subscriptions.
This is truly a bummer, and if someone doesn't pick up the pieces and continue offer RHEL rebranded, there's no(?) open sauce operating system with a decade-long support lifecycle. I wonder if this might cause an increase in unpatched servers and appliances when the alternatives offer five years at best.
There's a silent but relatively big user base of CentOS in HPC and scientific computing.
ScientificLinux and CentOS rules all HPC clusters. Clusters are like enterprise servers. Big, monolithic, rarely upgraded. They're upgraded in one big-fell swoop and left to run.
There'll be another clone of RHEL since HPC can't accept CentOS Stream as the alternative. The whole infra is too big to move to Debian too.
So with today's announcement, a new distro is born. Also Greg (CentOS' founder's) domain (HPCng) is very telling...
We'll see. We're in for a hell of a ride. If you excuse me, I need to dust-off my XCAT servers...
ScientificLinux and CentOS rules all HPC clusters. Clusters are like enterprise servers. Big, monolithic, rarely upgraded. They're upgraded in one big-fell swoop and left to run.
There'll be another clone of RHEL since HPC can't accept CentOS Stream as the alternative. The whole infra is too big to move to Debian too.
So with today's announcement, a new distro is born. Also Greg (CentOS' founder's) domain (HPCng) is very telling...
We'll see. We're in for a hell of a ride. If you excuse me, I need to dust-off my XCAT servers...
Okay, this is a serious question. For me, not an official RH position. In my time in HPC, nodes were baked with a specific image and then that basically never ever got updates. As I came to that as a sysadmin from other areas, I found that somewhat horrifying, but it seemed pretty universal. Have things changed such that applying patches regularly (like, more often than once a month or so except in emergencies) is a thing?
Not much, but in our setup the image is not something which can evolve or change over time. This practice has some very practical reasons though.
Scientific applications can be very picky about the libraries they use or need, down to minor version since the results they produce are very, very precise. Even if not very accurate, you need to know the inaccuracy. An optimization in a math library can change this and, it's not something we want. Also program verification and certification generally includes versions of the libraries used.
Piecewise upgrades are a no go too. Your cluster generally can't work well in heterogeneous configurations (due to library mismatches) and draining a node is not a straightforward task (due to length of the jobs). If your cluster has a steady stream of incoming jobs, reducing resources also means queue bloat and recovering it is not easy sometimes. If you want to drain the whole cluster, it takes almost 2-3 weeks so, you lose ~1 month of productivity. When you start an empty cluster to churn its queues, its saturation takes time so, it doesn't go to 11 directly.
Also, worker nodes are highly isolated from the user's point of view. No users can log-in, only known people submit jobs, etc. Unless there's a rogue academic trying to do nefarious things, the place is pretty safe and worry-free. In past 15 years, we got two rootkit infections due to a server which can be world-accessible by design. Other than that, nothing ever got infected.
At the end of the day, this approach has some valid reasons to be alive. It's not that we're a bunch of lazy academics who refrain from applying good system administration practices. :D
Addendum: The images generally get updated when new hardware is added, since new processors tend to work better with newer kernels. Also sometimes we bit the bullet and update all the cluster at once. XCAT helps a lot in this space. If your image is sane, you can install batches of 150+ servers in 15 minutes while sipping your coffee.
Scientific applications can be very picky about the libraries they use or need, down to minor version since the results they produce are very, very precise. Even if not very accurate, you need to know the inaccuracy. An optimization in a math library can change this and, it's not something we want. Also program verification and certification generally includes versions of the libraries used.
Piecewise upgrades are a no go too. Your cluster generally can't work well in heterogeneous configurations (due to library mismatches) and draining a node is not a straightforward task (due to length of the jobs). If your cluster has a steady stream of incoming jobs, reducing resources also means queue bloat and recovering it is not easy sometimes. If you want to drain the whole cluster, it takes almost 2-3 weeks so, you lose ~1 month of productivity. When you start an empty cluster to churn its queues, its saturation takes time so, it doesn't go to 11 directly.
Also, worker nodes are highly isolated from the user's point of view. No users can log-in, only known people submit jobs, etc. Unless there's a rogue academic trying to do nefarious things, the place is pretty safe and worry-free. In past 15 years, we got two rootkit infections due to a server which can be world-accessible by design. Other than that, nothing ever got infected.
At the end of the day, this approach has some valid reasons to be alive. It's not that we're a bunch of lazy academics who refrain from applying good system administration practices. :D
Addendum: The images generally get updated when new hardware is added, since new processors tend to work better with newer kernels. Also sometimes we bit the bullet and update all the cluster at once. XCAT helps a lot in this space. If your image is sane, you can install batches of 150+ servers in 15 minutes while sipping your coffee.
Right, so: for this case, CentOS Stream will be virtually identical to the CentOS Linux RHEL rebuild.
We will certainly try. Need to mirror a repo, freeze it and update our installation infra so it looks to the local repo rather than the national mirror.
All repo settings will look to local repo so we'd have no dependency problem or version creep if we need to install an additional package.
Didn't completely think how to handle the occasional emergency update though.
Also, we need to compile in some packages. Hope they won't break. High performance stuff needs optimized/customized compilations.
I just want to add: Hope that the packages in CentOS stream won't end up too cutting edge for the scientific software community. These communities move slow due to stability requirements. We'll certainly see but it might be another potential problem.
All repo settings will look to local repo so we'd have no dependency problem or version creep if we need to install an additional package.
Didn't completely think how to handle the occasional emergency update though.
Also, we need to compile in some packages. Hope they won't break. High performance stuff needs optimized/customized compilations.
I just want to add: Hope that the packages in CentOS stream won't end up too cutting edge for the scientific software community. These communities move slow due to stability requirements. We'll certainly see but it might be another potential problem.
I can totally reassure you on your last concern: everything that goes into Stream is approved for a minor release in RHEL. That's not changing at all. Cutting edge is still Fedora's turf. :)
Thanks, because that last point would be actually breaking in some cases.
I think HN is the only place where you can casually provide feedback and get answers about an OS project from one of the core people in it. Fun!
Glad to meet you, BTW.
I think HN is the only place where you can casually provide feedback and get answers about an OS project from one of the core people in it. Fun!
Glad to meet you, BTW.
To be clear, I'm RHEL and CentOS _adjacent_, rather than actively _in_ them. But I think (rough launch and more than a few communication issues) aside this is generally gonna be positive.
I think that's because HPC users are largely non-technical developers. We changed a DHCP schema at one point and had a bunch of angry academics in the IT office because their Matlab scripts were broken. Many of them had been hard coding IP addresses into the code itself.
The login nodes on our cluster (UChicago) can reach uptimes over a hundred days (which my tmux sessions love).
Seems like the kernel was last updated in May.
Seems like the kernel was last updated in May.
$ uname -r -v
3.10.0-1127.8.2.el7.x86_64 #1 SMP Wed May 13 10:45:47 CDTNo, they haven't changed in my experience.
We used SLES like that on our HPC. SLES and RH will run just fine without subscriptions if you don't plan to update them.
The license for RH precludes you from running unlicensed RH, if you have any licensed RH. I don't believe SuSE does the same.
The license for RH precludes you from running unlicensed RH, if you have any licensed RH. I don't believe SuSE does the same.
Oracle already has a clone that performs an in-place conversion of an installed CentOS 7 system.
There is a page describing the conversion: https://linux.oracle.com/switch/centos/
They have a shell script to convert a CentOS install to Oracle Linux, so you can buy support if you want.
The converter only works with versions 5, 6, and 7.
It does not work with CentOS 8. It would be nice if that could get updated.
There is a page describing the conversion: https://linux.oracle.com/switch/centos/
They have a shell script to convert a CentOS install to Oracle Linux, so you can buy support if you want.
The converter only works with versions 5, 6, and 7.
It does not work with CentOS 8. It would be nice if that could get updated.
>0racle already has a clone that performs an in-place conversion of an installed CentOS 7 system.
"Out of the frying pan into the fire"
"Out of the frying pan into the fire"
There are two types of people: People who haven't used Oracle yet, and people who will never use it again.
And I'll forever hate them for what they did to Java (and in setting the precedent that APIs can be copyrighted).
And I'll forever hate them for what they did to Java (and in setting the precedent that APIs can be copyrighted).
What have they done, lets see:
- Brought MaximeVM of research and creating GraalVM
- In the process of adding value types to Java
- In the process of adding support for explicit SIMD in Java
- In the process of adding co-routines to Java
- Added type inference support
- Added pattern matching
- Added record types
- Integrated J/Rockit support for JIT caches
- Made Flight Recorder available in OpenJDK
- In the process of making AOT compilation work, instead of requiring you to fork money for a JDK with AOT compiler like Sun used to do
- Integrated almost pauseless GC with support for TB sized heaps
- Long term roadmap to replace C++ with Java on the JDK, as yet another proof of Java capabilities
- In the process of having a JNI replacement
And plenty more, https://openjdk.java.net/jeps/0
I hope they squash Android Java, Google had the opportunity to buy Sun after screwing them up.
- Brought MaximeVM of research and creating GraalVM
- In the process of adding value types to Java
- In the process of adding support for explicit SIMD in Java
- In the process of adding co-routines to Java
- Added type inference support
- Added pattern matching
- Added record types
- Integrated J/Rockit support for JIT caches
- Made Flight Recorder available in OpenJDK
- In the process of making AOT compilation work, instead of requiring you to fork money for a JDK with AOT compiler like Sun used to do
- Integrated almost pauseless GC with support for TB sized heaps
- Long term roadmap to replace C++ with Java on the JDK, as yet another proof of Java capabilities
- In the process of having a JNI replacement
And plenty more, https://openjdk.java.net/jeps/0
I hope they squash Android Java, Google had the opportunity to buy Sun after screwing them up.
When your company software stack is turned inside-out by Oracle reps to look for unlicensed JVM's on penalty of really big fines (sorry, opportunities to buy more Oracle software) all those nice-to-have features don't seem to matter that much.
Java is like C and C++, plenty of implementations to choose from, including the free beer OpenJDK.
Anything else is just FUD.
Anything else is just FUD.
> I hope they squash Android Java, Google had the opportunity to buy Sun after screwing them up.
Do you really think that would be a reasonable thing to happen, and good for technology and the world in general? It seems disproportionately punitive, and the "right" thing to happen only if all you care about is watching things burn.
And you haven't addressed the precedent that's been set that APIs are now copyrightable. Do you like that precedent? Do you ever use anyone else's APIs in your daily development, and do you like how that now opens you to huge potential liability? Is all of this worth it just because Google didn't acquire Sun??
Do you really think that would be a reasonable thing to happen, and good for technology and the world in general? It seems disproportionately punitive, and the "right" thing to happen only if all you care about is watching things burn.
And you haven't addressed the precedent that's been set that APIs are now copyrightable. Do you like that precedent? Do you ever use anyone else's APIs in your daily development, and do you like how that now opens you to huge potential liability? Is all of this worth it just because Google didn't acquire Sun??
They've done all of them because they think it'll allow them to earn more money with less effort on the long run, not because of the sheer love of computer science and research.
Oracle creates cool tech in the legacy of Sun because it impresses the right people who can influence the decision makers.
To recap: "Hey, Oracle's these new toys are capable and fun to use. We can do much more with them. Can you buy these for us, engineers so we can be happy like children again?"
Oracle creates cool tech in the legacy of Sun because it impresses the right people who can influence the decision makers.
To recap: "Hey, Oracle's these new toys are capable and fun to use. We can do much more with them. Can you buy these for us, engineers so we can be happy like children again?"
I don't think that's really true. My understanding from talking to people there is that Java funding was increased for so many years despite losing money because Larry Ellison just thought it was cool tech and they use it a lot. Likewise, GraalVM is so well funded largely because it's cool and Oracle doesn't have many cool R&D projects. It's not clear it's all that commercially driven when you observe that so much of it is open source.
That said, their supported versions of Java and Graal are expensive. Some things never change.
That said, their supported versions of Java and Graal are expensive. Some things never change.
Oracle has been in the bed with IBM and Sun regarding Java since version 1.0.
The supported versions of Java and Graal are the same price as any other enterprise product.
They put the effort, someone has to pay for it.
Where are the free beer JIT, AOT and GC implementations for free beer languages that outperform Java?
The supported versions of Java and Graal are the same price as any other enterprise product.
They put the effort, someone has to pay for it.
Where are the free beer JIT, AOT and GC implementations for free beer languages that outperform Java?
Do we need to have free beer JIT, AOT and GC implementations for every language?
If I understood it correctly, a programming language has some foundational design decisions (including its memory and execution model) to attack a particular set of problems?
If I understood it correctly, a programming language has some foundational design decisions (including its memory and execution model) to attack a particular set of problems?
What we need are top level JIT, AOT and GC implementations, anything else is just going backwards.
The people capable of achieving that, naturally have bills to pay.
The people capable of achieving that, naturally have bills to pay.
> What we need are top level JIT, AOT and GC implementations, anything else is just going backwards.
Not always. As I aforementioned in another thread, we also need C/C++, Python, Perl, etc. as is since they fill different roles and attack different problems.
I've written Java, C, C++, Python, Perl, PHP. Had to abuse some of them to fit roles which they're not designed to do. At the end of the day, these languages satisfy different needs and solve different problems in different scenarios. Java wouldn't be able to do all of them. Neither C++, nor Python.
As I said, you may like Java but, it's not the king of every programming language. No programming language is king of everything BTW.
Not always. As I aforementioned in another thread, we also need C/C++, Python, Perl, etc. as is since they fill different roles and attack different problems.
I've written Java, C, C++, Python, Perl, PHP. Had to abuse some of them to fit roles which they're not designed to do. At the end of the day, these languages satisfy different needs and solve different problems in different scenarios. Java wouldn't be able to do all of them. Neither C++, nor Python.
As I said, you may like Java but, it's not the king of every programming language. No programming language is king of everything BTW.
> I don't think that's really true. My understanding from talking to people there is that Java funding was increased for so many years despite losing money because Larry Ellison just thought it was cool tech and they use it a lot. Likewise, GraalVM is so well funded largely because it's cool and Oracle doesn't have many cool R&D projects. It's not clear it's all that commercially driven when you observe that so much of it is open source.
I just hope that it's true. We really need that.
I just hope that it's true. We really need that.
Good on them, they stepped in for Sun when no one else bothered to [0], including Google after screwing them up.
I guess the "community" would love to keep using Java frozen in version 6.
[0] - Only IBM considered it, which from these threads people here wouldn't be happy anyway.
I guess the "community" would love to keep using Java frozen in version 6.
[0] - Only IBM considered it, which from these threads people here wouldn't be happy anyway.
Development of programming languages by corporations is not something I object but, all of the stuff told about Oracle here is correct.
They're not a nice entity unless you pay money to them and they're greedy. They always want more. Also, their hardware can fail in strange ways and they'd shrug it off.
I've met with some nice people who migrated from Sun but they all say that the terms they work are draconian.
I like Java too but, developing a nice language doesn't make Oracle good. Don't get distracted [0].
> I guess the "community" would love to keep using Java frozen in version 6.
Python doesn't stop. C++ doesn't drop. Even brainfuck doesn't stop. It'd have prevailed. OpenJDK is one fruit of the project. After removing patent encumbered image processing stuff, OpenJDK just took off. Yes, it's still part of Oracle in a sense but, OracleJDK is compiled from OpenJDK, not vice versa. Again, don't get distracted [0].
[0]: https://calebhearth.com/talks/dont-get-distracted
They're not a nice entity unless you pay money to them and they're greedy. They always want more. Also, their hardware can fail in strange ways and they'd shrug it off.
I've met with some nice people who migrated from Sun but they all say that the terms they work are draconian.
I like Java too but, developing a nice language doesn't make Oracle good. Don't get distracted [0].
> I guess the "community" would love to keep using Java frozen in version 6.
Python doesn't stop. C++ doesn't drop. Even brainfuck doesn't stop. It'd have prevailed. OpenJDK is one fruit of the project. After removing patent encumbered image processing stuff, OpenJDK just took off. Yes, it's still part of Oracle in a sense but, OracleJDK is compiled from OpenJDK, not vice versa. Again, don't get distracted [0].
[0]: https://calebhearth.com/talks/dont-get-distracted
Here some news for you, check the names of the companies that put money on the table for Python and C++.
IBM, Microsoft, Google, Apple, Oracle, Amazon, Sony, Nintendo
So much better.
IBM, Microsoft, Google, Apple, Oracle, Amazon, Sony, Nintendo
So much better.
However, the governing bodies of these programming languages are independent from the companies themselves, which is different than Java's position.
These companies employ people who contribute to these programming languages. So the model is somewhat different.
I'm not that oblivious about the real/programming world.
These companies employ people who contribute to these programming languages. So the model is somewhat different.
I'm not that oblivious about the real/programming world.
It is naïve to think that the employees of the companies aren't driving their employers agenda, regardless how "independent" those governing bodies are.
I don't think many people who want to use something stable like CentOS, but don't want to pay for a RHEL support contract would want to pay Oracle for RHEL-but-with-Oracle-sprinkles-on-top
Not to mention Oracle is not known to leave money on the table, and if they see they can start charging for Oracle Linux because there's no large well known free version, I wouldn't put it past them.
Put another way, if you jump ship from CentOS because IBM caused Red Hat to change it into a funnel to pay them money, if you landed on Oracle, you might be setting yourself up to do it all over again fairly soon.
Put another way, if you jump ship from CentOS because IBM caused Red Hat to change it into a funnel to pay them money, if you landed on Oracle, you might be setting yourself up to do it all over again fairly soon.
> Not to mention Oracle is not known to leave money on the table
You're underselling it: Oracle grab money in a way that I would describe as "aplomb ruthlessness". They've managed to fuck no less than 3 orgs I've worked for.
If they ask you for a license count or how many cores are in use, ignore them. Larry Ellison doesn't need another boat.
You're underselling it: Oracle grab money in a way that I would describe as "aplomb ruthlessness". They've managed to fuck no less than 3 orgs I've worked for.
If they ask you for a license count or how many cores are in use, ignore them. Larry Ellison doesn't need another boat.
Oracle Linux is free with optional paid support.
"Unlike many other commercial Linux distributions, Oracle Linux is easy to download and completely free to use, distribute, and update. Oracle Linux is available under the GNU General Public License (GPLv2). Support contracts are available from Oracle. "
https://www.oracle.com/a/ocom/docs/027617.pdf [PDF]
"Unlike many other commercial Linux distributions, Oracle Linux is easy to download and completely free to use, distribute, and update. Oracle Linux is available under the GNU General Public License (GPLv2). Support contracts are available from Oracle. "
https://www.oracle.com/a/ocom/docs/027617.pdf [PDF]
never, Ever, EVER trust Oracle. Especially with something as important as an open source product. Evidence: Oracle's Sen. VP Glueck statement that "There is no math that can justify open source from a cost perspective." No chance you'll ever see me running OEL.
> never, Ever, EVER trust Oracle.
Been burned by them before. Not at liberty to give details, but the outcome is that I never choose Oracle for anything for the rest of my career. Even if it would save time and money.
Been burned by them before. Not at liberty to give details, but the outcome is that I never choose Oracle for anything for the rest of my career. Even if it would save time and money.
The fact that you aren't comfortable discussing the details of how you were screwed by Oracle, even anonymously on the internet, is really all anyone needs to know about Oracle.
HN is one breach away from lost anonymity.
Are there any license traps in Oracle Linux?
Writing like this makes me very wary of putting Oracle Linux anywhere near my employer's systems
https://www.computerworld.com/article/2992597/law-firm-warns...
https://blog.dbwatch.com/how-to-avoid-oracles-licensing-trap...
Then there's the famous lawn mover quote from Bryan Cantrill https://news.ycombinator.com/item?id=5170246
Writing like this makes me very wary of putting Oracle Linux anywhere near my employer's systems
https://www.computerworld.com/article/2992597/law-firm-warns...
https://blog.dbwatch.com/how-to-avoid-oracles-licensing-trap...
Then there's the famous lawn mover quote from Bryan Cantrill https://news.ycombinator.com/item?id=5170246
Can you imagine if they had successfully purchased TikTok?
match made not in heaven but on Oracle Cloud
From their page, does this even read professional? Sounds like some startup wrote it trying to make them look bigger than they're.
Community based sounds better to me.
> But if you're here, you're a CentOS user. Which means that you don't pay for a distribution at all, for at least some of your systems. So even if we made the best paid distribution in the world (and we think we do), we can't actually get it to you... or can we?
Community based sounds better to me.
> But if you're here, you're a CentOS user. Which means that you don't pay for a distribution at all, for at least some of your systems. So even if we made the best paid distribution in the world (and we think we do), we can't actually get it to you... or can we?
In our setup we don't need any add-ons that Oracle brings to the table. We also don't need their greed too.
We only need RH equal of Debian, since the software we use generally have explicit CentOS/RHEL support.
We only need RH equal of Debian, since the software we use generally have explicit CentOS/RHEL support.
My thoughts exactly. All our workstations and small-ish clusters run CentOS (we don’t maintain ourselves the large clusters so these are not our problem). It’s going to be a huge pain.
> Red Hat still has to release the patches, right?
I think that's a gray area. For example RHEL has some support branches where they'll produce security updates for minor updates. For example you can pay a lot of money and you'll get RHEL 7.2 with security updates. They won't release sources for those packages unless you'll ask for those packages (you, as a paid client, not you as nobody in the Internet). But if you'll ask sources and then publish those sources in the internet again and again, so other entity like CentOS or whatever could pick them up and build CentOS 7.2 LTS, they will terminate your contract.
So that's a weakness in GPL. You won't break any law, but they'll just terminate contracts with those who publish those sources. So those sources are effectively unavailable for a large public.
Currently they publish their mainstream branch sources to the public. But they could stop doing that any time and only provide those sources to their clients on request.
I think that's a gray area. For example RHEL has some support branches where they'll produce security updates for minor updates. For example you can pay a lot of money and you'll get RHEL 7.2 with security updates. They won't release sources for those packages unless you'll ask for those packages (you, as a paid client, not you as nobody in the Internet). But if you'll ask sources and then publish those sources in the internet again and again, so other entity like CentOS or whatever could pick them up and build CentOS 7.2 LTS, they will terminate your contract.
So that's a weakness in GPL. You won't break any law, but they'll just terminate contracts with those who publish those sources. So those sources are effectively unavailable for a large public.
Currently they publish their mainstream branch sources to the public. But they could stop doing that any time and only provide those sources to their clients on request.
This is what grsecurity has done as well and I don't understand with people that against the current grsecurity way of licensing.
> They won't release sources for those packages unless you'll ask for those packages (you, as a paid client, not you as nobody in the Internet).
If the code in question is licensed under the GPL and Red Hat isn't the owner of the code, then I as a rando on the Internet can ask them for the source and if they don't provide it, the person who does own the code can sue them and revoke their license to distribute said code. And I'd say that the majority of code in RHEL is not owned by Red Hat.
If the code in question is licensed under the GPL and Red Hat isn't the owner of the code, then I as a rando on the Internet can ask them for the source and if they don't provide it, the person who does own the code can sue them and revoke their license to distribute said code. And I'd say that the majority of code in RHEL is not owned by Red Hat.
That is not how the GPL works. The GPL only entitles you to the source code of software for which you have been provided binaries. If the software has not been provided to you in binary form, you have no claim to the source.
This is why the cloud providers can get away with custom in-house patches to the Linux kernel.
This is why the cloud providers can get away with custom in-house patches to the Linux kernel.
Yep, this is actually one of those things Stallman has been saying for decades and people like to ignore: the GPL doesn’t mean all code must be in the public domain, only that users of a given program should be able to modify it. There are a number of ways to allow for that while still keeping distribution restricted.
You can only ask them for the source if you already have the binaries and you've gotten them from Red Hat. If you got the binaries from someone else, you can ask that someone else.
Can you help me understand why GPL v2 3(b) doesn't obligate Red Hat to provide source code for the kernel, as an example, to anyone who asks?
>3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
> b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
>3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
> b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
Because Red Hat offers source code following section 3(a) instead. Thus, section 3(b) does not apply.
Really? When I do a yum update on my rhel systems to get the latest updates from rhn, they never download the source code. Now that I think about it, I don't think RH has even sent me any kind of medium which is commonly used for interchange.
GPLv2 was written in 1991. GPLv3 changes the wording in Section 3(a) to "durable physical medium", but at the same time it gives other possibility including "Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge".
Everyone was doing network distribution of GPL software long before GPLv3 came out, effectively treating a download as a medium customarily used for software interchange. Not a physical one, but GPLv2 does not say anything about that.
Everyone was doing network distribution of GPL software long before GPLv3 came out, effectively treating a download as a medium customarily used for software interchange. Not a physical one, but GPLv2 does not say anything about that.
I think that access to the private repository is considered a distribution. You have access to the sources with `dnf download --source` or something like that. The fact that those sources originally are on the remote server probably is not significant in 2020.
[deleted]
I'll be uninstalling my fedora laptop if they do this!
Why?
because everything red hat is pissing me off right know maybe get better in the future.
Amazon Linux 2 could be a viable alternative. In addition to being available to run on AWS, it's also available as a container image and in various machine image formats:
https://aws.amazon.com/amazon-linux-2/#Resources
AL has had enough work put into it over the years that, while it may have been inspired by CentOS/RHEL originally, calling it a rebadged CentOS is not accurate these days. A full and competent team maintains it. While it's clearly made similar architectural choices, those are also for compatibility reasons.
However I doubt that support is available for anyone not running it on AWS, at least not from AWS -- but then again folks running CentOS weren't paying for support from RHEL either.
I also wonder if the announcement is as bad as people make it sound. I'm not an expert in Linux distros, but my understanding is that AL2 also uses a streams-like model, in that it provides long term support (patches for existing software) while also making new software available. My understanding was that, while it is inevitably versioned by making artifacts like VMs and containers available over CDNs ( https://cdn.amazonlinux.com/os-images/2.0.20201111.0/ ), the expectation is that most users will always launch the latest version, relying on its backward compatibility. Perhaps someone who knows more about the specifics of its release model could comment.
https://aws.amazon.com/amazon-linux-2/#Resources
AL has had enough work put into it over the years that, while it may have been inspired by CentOS/RHEL originally, calling it a rebadged CentOS is not accurate these days. A full and competent team maintains it. While it's clearly made similar architectural choices, those are also for compatibility reasons.
However I doubt that support is available for anyone not running it on AWS, at least not from AWS -- but then again folks running CentOS weren't paying for support from RHEL either.
I also wonder if the announcement is as bad as people make it sound. I'm not an expert in Linux distros, but my understanding is that AL2 also uses a streams-like model, in that it provides long term support (patches for existing software) while also making new software available. My understanding was that, while it is inevitably versioned by making artifacts like VMs and containers available over CDNs ( https://cdn.amazonlinux.com/os-images/2.0.20201111.0/ ), the expectation is that most users will always launch the latest version, relying on its backward compatibility. Perhaps someone who knows more about the specifics of its release model could comment.
I’d like to use Amazon Linux but it doesn’t seem like they provide ISOs. Seems like it’s intended to be used largely on EC2.
We had some folks try installing Amazon Linux images in our network. They spammed the network looking for a nonexistent link local metadata service, which is how we found out about them.
Don't forget that AL also runs on Amazon's A1 ARM instances.
There's a CentOS ARM variant, I believe it's semi-official.
Works ok on a RPi.
Works ok on a RPi.
I tried to find official information about Amazon Linux but I can't find. Is it based on what distro? (maybe RHEL7 but not mentioned) How it's compatible to EPEL and other software for RHEL even though they are different from RHEL? (at least they uses different glibc version)
I'm really curious whether Amazon Linux is accepted by Linux guru or not. It seems that there are very little docs for a distribution.
I'm really curious whether Amazon Linux is accepted by Linux guru or not. It seems that there are very little docs for a distribution.
FAQ: CentOS Stream Updates @ Red Hat[0]
Q: What does this mean for users of CentOS Linux?
The creation of CentOS Stream provides a new mechanism for partners and community members to add innovation to the next version of RHEL as it’s being built instead of after it’s built. We also recognize that there are different kinds of CentOS Linux users, and we are working with the CentOS Project Governing Board to tailor programs that meet the needs of different user groups.
In the first half of 2021, we will be introducing low- or no-cost programs for a variety of use cases, including options for open source projects and communities, partner ecosystems and an expansion of the use cases of the Red Hat Enterprise Linux Developer subscription to better serve the needs of systems administrators and partner developers. We’ll share more details on these initiatives as they become available. For those converting to RHEL, there is guidance available today for converting from CentOS Linux to RHEL.
[0] https://www.redhat.com/en/blog/faq-centos-stream-updates#Q10
Q: What does this mean for users of CentOS Linux?
The creation of CentOS Stream provides a new mechanism for partners and community members to add innovation to the next version of RHEL as it’s being built instead of after it’s built. We also recognize that there are different kinds of CentOS Linux users, and we are working with the CentOS Project Governing Board to tailor programs that meet the needs of different user groups.
In the first half of 2021, we will be introducing low- or no-cost programs for a variety of use cases, including options for open source projects and communities, partner ecosystems and an expansion of the use cases of the Red Hat Enterprise Linux Developer subscription to better serve the needs of systems administrators and partner developers. We’ll share more details on these initiatives as they become available. For those converting to RHEL, there is guidance available today for converting from CentOS Linux to RHEL.
[0] https://www.redhat.com/en/blog/faq-centos-stream-updates#Q10
LOL at the corporate guff. The primary use case of CentOS is "I want to run RHEL without paying anyone anything". The best way to "serve that need"? Don't kill off CentOS 8.3+.
Actually the best way is to allow free use of RHEL for those who don't want to pay for it.
I mean, that's de-facto what CentOS was; RHEL but non-paid and with different branding. But I mean... they were built from the (exact) same sources, so similar that you could convert between them by un/installing a few packages.
The difference is that CentOS is really free. RHEL free will be whatever RedHat wants. Of course it won't be as free as CentOS. But if it'll be free enough to satisfy most CentOS users, that might be good enough.
I've heard the idea being mentioned from several sources. My guess is that unless Oracle does some kind of magic an manages to get anyone to trust them, then we'll see a new community project to replace CentOS very soon.
Either that, or Debian's user-base will grow a lot within the next few months. :)
Either that, or Debian's user-base will grow a lot within the next few months. :)
> Red Hat still has to release the patches, right?
Whether or not Red Hat "has to", Red Hat is an all open source company and does and will.
Whether or not Red Hat "has to", Red Hat is an all open source company and does and will.
That already exists and is called CloudLinux. It is very cheap but not free.
Other RHEL-clones: Oracle Linux (best one), Springdale Linux.
Other alternatives: openSUSE Leap and Debian. I am not even listing Ubuntu because I hate it since snaps.
Other RHEL-clones: Oracle Linux (best one), Springdale Linux.
Other alternatives: openSUSE Leap and Debian. I am not even listing Ubuntu because I hate it since snaps.
Oh cool. As for CloudLinux, "not free" probably scale for some hosting environments, including non-managed cloud instances.
But something like Springdale, given resources, might be able to provide. They're still tracking RHEL 7, though.
Debian and Ubuntu, which offer five years of Long Term Support are the next best thing available, and that's already kind of tight for long-term deployments of self-hosted, old-fashioned business software.
Debian is particularly impressive, since they, on paper, aim to support all packages with security fixes, whereas Ubuntu's main repo is a lot more limited.
OpenSUSE Leap versions seem to get three years, which really isn't enough software that needs to just work for a long while.
But something like Springdale, given resources, might be able to provide. They're still tracking RHEL 7, though.
Debian and Ubuntu, which offer five years of Long Term Support are the next best thing available, and that's already kind of tight for long-term deployments of self-hosted, old-fashioned business software.
Debian is particularly impressive, since they, on paper, aim to support all packages with security fixes, whereas Ubuntu's main repo is a lot more limited.
OpenSUSE Leap versions seem to get three years, which really isn't enough software that needs to just work for a long while.
Springdale Linux is on RHEL 8.3 but their homepage is awfully out of date.
Here's the full ISO for 8.1: http://puias.princeton.edu/data/puias/8.1/x86_64/iso/
And then you can add the repos to update to 8.3: http://puias.princeton.edu/data/puias/8.3/
Or you can take the small ("boot") ISO and install 8.3 directy: http://puias.princeton.edu/data/puias/8.3/x86_64/os/images/
In fact, they are even building Springdale Linux 8 for i386, which RHEL and CentOS never did.
If you need more than three years on openSUSE Leap, then you need to upgrade to SUSE Linux Enterprise Server.
Here's the full ISO for 8.1: http://puias.princeton.edu/data/puias/8.1/x86_64/iso/
And then you can add the repos to update to 8.3: http://puias.princeton.edu/data/puias/8.3/
Or you can take the small ("boot") ISO and install 8.3 directy: http://puias.princeton.edu/data/puias/8.3/x86_64/os/images/
In fact, they are even building Springdale Linux 8 for i386, which RHEL and CentOS never did.
If you need more than three years on openSUSE Leap, then you need to upgrade to SUSE Linux Enterprise Server.
> Debian and Ubuntu, which offer five years of Long Term Support are the next best thing available, and that's already kind of tight for long-term deployments of self-hosted, old-fashioned business software.
Remember that, in Ubuntu, the majority of packages are actually ONLY supported for nine (9) months -- not the full 5 years!
Remember that, in Ubuntu, the majority of packages are actually ONLY supported for nine (9) months -- not the full 5 years!
> Debian is particularly impressive, since they, on paper, aim to support all packages with security fixes, whereas Ubuntu's main repo is a lot more limited.
What are the track records of the claim?
I'm sure Ubuntu will patch stuff up if some vulnerability shows up outside of main that gets patched upstream or elsewhere.
What are the track records of the claim?
I'm sure Ubuntu will patch stuff up if some vulnerability shows up outside of main that gets patched upstream or elsewhere.
> What are the track records of the claim?
I claim no deep expertise on this, but for a distribution of 56k packages, this looks quite good https://security-tracker.debian.org/tracker/status/release/s...
To anyone here who's worked secops and has to track these things, I'm really interested to hear opinions about how well Debian follows up on this
I claim no deep expertise on this, but for a distribution of 56k packages, this looks quite good https://security-tracker.debian.org/tracker/status/release/s...
To anyone here who's worked secops and has to track these things, I'm really interested to hear opinions about how well Debian follows up on this
I trust Canonical more than Debian for security fixes. Canonical has a dedicated security team.
So does Debian https://security-team.debian.org
I claim no deep expertise on this, and I assume Canonical has more money to throw at this. Or are there contributions to Debian security in the form of paid personnel?
This is actually quite interesting to me, anyone with real knowledge of the subject is welcome to interject.
I claim no deep expertise on this, and I assume Canonical has more money to throw at this. Or are there contributions to Debian security in the form of paid personnel?
This is actually quite interesting to me, anyone with real knowledge of the subject is welcome to interject.
TIL Scientific Linux was discontinued in favor of CentOS :(
I guess it'll make a comeback.
CloudLinux is based on CentOS as an upstream it is unclear on how this announcement will impact CloudLinux
I dislike Ubuntu since it started adding advertisements in the motd :P
That would be cool "stick it to the man" trick, but how do we organize?
Well, GoDaddy, or heh, AWS are The Man.
My best hope is that the major hosting vendors, or maybe some industry consortium might offer resources for this.
My best hope is that the major hosting vendors, or maybe some industry consortium might offer resources for this.
@syshum, yes, but it's not exacly RHEL, and it's not distributed outside AWS https://news.ycombinator.com/item?id=25347232
But the point is indeed that there are resources and infrastructure, so one might be hopeful that there will be a good outcome.
One possible outcome would be increased demand and resources for Debian and/or Ubuntu and I definitely wouldn't mind that (five years of support isn't all that much in IT). Realistically though, a lot of people need RHEL for free and I suspect there will be a way.
But the point is indeed that there are resources and infrastructure, so one might be hopeful that there will be a good outcome.
One possible outcome would be increased demand and resources for Debian and/or Ubuntu and I definitely wouldn't mind that (five years of support isn't all that much in IT). Realistically though, a lot of people need RHEL for free and I suspect there will be a way.
> @syshum, yes, but it's not exacly RHEL, and it's not distributed outside AWS
On the first point you are correct. It's not exactly RHEL7.
On the second point, Amazon provides images for running on prem[0]. We run a lot of dev AmazonLinux2 VMs on prem so that the local computing environment matches the deployed EC2 environment.
0: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-l...
On the first point you are correct. It's not exactly RHEL7.
On the second point, Amazon provides images for running on prem[0]. We run a lot of dev AmazonLinux2 VMs on prem so that the local computing environment matches the deployed EC2 environment.
0: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-l...
@invaderFizz: oh, this is useful to me, thanks!
Yeah, resources and infrastrucure are not some magic that only Redhat can provide. If sources will be released on https://git.centos.org/ or somewhere else, then it may work. Just like the old times [1]
[1] https://lwn.net/Articles/128952/
[1] https://lwn.net/Articles/128952/
AWS already has their on RHEL Clone, Amazon Linux, for use on AWS
Yes this hurts. My use case is specific: I'm a dev but since we're 2 in the IT service with barely any budget I'm also a (modest) sysadmin and they also call me when the printer or the TV doesn't work.
So a few years ago when Debian decided to have faster release cycles I migrated all my VM to CentOS: once the OS is installed I don't want to think about it for the next 10 years.
I still didn't finish my Windows 7 to 10 on all my desktops, I'm swamped with users wanting to do Zoom / Teams / Skype / Whatever visio conferences, I have 3 new dev projects for 2021 and now I have to migrate all my CentOS VM...
Yeah, thank you RedHat I won't forget / forgive that.
So a few years ago when Debian decided to have faster release cycles I migrated all my VM to CentOS: once the OS is installed I don't want to think about it for the next 10 years.
I still didn't finish my Windows 7 to 10 on all my desktops, I'm swamped with users wanting to do Zoom / Teams / Skype / Whatever visio conferences, I have 3 new dev projects for 2021 and now I have to migrate all my CentOS VM...
Yeah, thank you RedHat I won't forget / forgive that.
So let's recap, you don't have budget to spend on Linux but pay Microsoft for Windows and probably Office... And now you are angry for allegedly not having a 10 year support for your OS, so you can avoid some work on upgrading or migrating the VMs. I suspect you should be running VMware as well (and paying for it), instead of KVM or some other open source hypervisor. If the VMs are on a public cloud, you are paying for it indirectly as well. You may have some additional work indeed, but you saved a lot on not spending on a paid Linux distro, being Red Hat's or any other distro, therefore it should be worth it... take that into account
Nice try IBM
Debian now has LTS releases:
https://wiki.debian.org/LTS
https://wiki.debian.org/LTS
[deleted]
[deleted]
Before giving up on us just yet, I'd encourage you to check out our developer program for proper RHEL that's free. And I'd stay tuned for announcements that are coming in the first half of 2021 (as mentioned in our FAQ). You might find we've got a program for you:
https://www.redhat.com/en/blog/faq-centos-stream-updates#Q10
https://www.redhat.com/en/blog/faq-centos-stream-updates#Q10
If there truly is a free RHEL release for certain use cases being announced in H1 2021, there's absolutely no excuse not to announce it now. You've terrified a LOT of people. Giving a 'well maybe next year we'll announce a solution' is not a response.
You've burned people. Don't expect to then sell them Aloe Vera.
You've burned people. Don't expect to then sell them Aloe Vera.
You don't get it: I have no budget, if it's not free it doesn't happen. And I'm certainly not going to trust Red Hat now that they pulled support 8 years earlier than promised.
I have nothing against you in particular, but if you know the guys that made this decision tell them the same words that Linus Torvalds said to Nvidia.
I will never touch anything Red hat ever again because I will remember how after a quite sucky 2020, Red Hat made sure my 2021 would not disappoint either.
I have nothing against you in particular, but if you know the guys that made this decision tell them the same words that Linus Torvalds said to Nvidia.
I will never touch anything Red hat ever again because I will remember how after a quite sucky 2020, Red Hat made sure my 2021 would not disappoint either.
T&C for your developer program doesn't allow for running it in production; which is exactly what many CentOS users do.
No, they won't migrate to paid RHEL. This is massive goodwill burn for RH.
No, they won't migrate to paid RHEL. This is massive goodwill burn for RH.
> in the first half of 2021
Well, you've panicked people who are/were moving forward with CentOS 6/7 to 8, and not on RHEL because no budget. "Don't worry, sometime in the next 6 months there might be useful info for you, or there might not".
People aren't going to stick around waiting for that information. You've pulled the rug out from under us and we need to plan sooner rather than later. RHEL isn't do-able due to cost, CentOS isn't do-able because you've just killed it, so away we have to go.
Well, you've panicked people who are/were moving forward with CentOS 6/7 to 8, and not on RHEL because no budget. "Don't worry, sometime in the next 6 months there might be useful info for you, or there might not".
People aren't going to stick around waiting for that information. You've pulled the rug out from under us and we need to plan sooner rather than later. RHEL isn't do-able due to cost, CentOS isn't do-able because you've just killed it, so away we have to go.
Are you saying we should (mis)use a program designed to give free RHEL for development/testing only, and use it in production as well?
I appreciate you commenting.
I think people would panic less if the CentOS Linux cancellation were announced at the same time as these upcoming announcements. Without them, there's a lot of uncertainty and it's hard for anyone depending on CentOS 8 to plan.
I think people would panic less if the CentOS Linux cancellation were announced at the same time as these upcoming announcements. Without them, there's a lot of uncertainty and it's hard for anyone depending on CentOS 8 to plan.
RHEL licensing is really disappointing for the low end. I use CentOS for my home lab / self-hosted development setup and there's no way I would switch to RHEL. It doesn't matter because I don't spend any money, but I'll probably swap to Ubuntu next time I re-build my server.
Here [1] is an example of what I dislike. That page doesn't explain if a subscription is for 1 host or all my hosts and it doesn't explain if it needs to be renewed annually or if I get a perpetual license after the first year of support.
I currently have 11 (extremely light usage) CentOS VMs running, but almost everything is Docker containers. I could likely consolidate it onto a single, bare-metal host if I wanted. It would be worse for me, but I could get a single $800 license instead of $8800 for 11 licenses. It's a moot point though. $800 is already too much for the value I'm getting out of it.
I could use the developer program, but I use an issue tracker to track work I do and I back up the whole system nightly. Technically that's production (to me), and I've seen IBM bait and eviscerate someone for licensing using extremely unethical tactics, so I'll never use something that isn't very explicitly free for production.
I think RHEL is technically superior to Ubuntu, but Ubuntu is a far better product when it comes to support lifecycle, licensing, and support. I can spin up an Ubuntu server and unlimited VMs with the promise of a reasonable lifecycle and the option to click a button and buy support.
Where is that in the RedHat world? If RedHat would have released a product like CentOS Stream, but with RHEL branding and a dead simple way to go from a free, community supported version to a paid, commercially supported version then for people like me it makes sense to be the "beta" tester. I think it's a fair trade. Downtime doesn't have a huge impact on me and I'm willing to spend time bug hunting / reporting bugs.
TLDR; The licensing is a massive hassle and is a terrible value proposition for small users. You're not winning any mindshare unless it's as simple as Ubuntu makes it.
1. https://www.redhat.com/en/store/red-hat-enterprise-linux-ser...
Here [1] is an example of what I dislike. That page doesn't explain if a subscription is for 1 host or all my hosts and it doesn't explain if it needs to be renewed annually or if I get a perpetual license after the first year of support.
I currently have 11 (extremely light usage) CentOS VMs running, but almost everything is Docker containers. I could likely consolidate it onto a single, bare-metal host if I wanted. It would be worse for me, but I could get a single $800 license instead of $8800 for 11 licenses. It's a moot point though. $800 is already too much for the value I'm getting out of it.
I could use the developer program, but I use an issue tracker to track work I do and I back up the whole system nightly. Technically that's production (to me), and I've seen IBM bait and eviscerate someone for licensing using extremely unethical tactics, so I'll never use something that isn't very explicitly free for production.
I think RHEL is technically superior to Ubuntu, but Ubuntu is a far better product when it comes to support lifecycle, licensing, and support. I can spin up an Ubuntu server and unlimited VMs with the promise of a reasonable lifecycle and the option to click a button and buy support.
Where is that in the RedHat world? If RedHat would have released a product like CentOS Stream, but with RHEL branding and a dead simple way to go from a free, community supported version to a paid, commercially supported version then for people like me it makes sense to be the "beta" tester. I think it's a fair trade. Downtime doesn't have a huge impact on me and I'm willing to spend time bug hunting / reporting bugs.
TLDR; The licensing is a massive hassle and is a terrible value proposition for small users. You're not winning any mindshare unless it's as simple as Ubuntu makes it.
1. https://www.redhat.com/en/store/red-hat-enterprise-linux-ser...
> It doesn't matter because I don't spend any money, but I'll probably swap to Ubuntu next time I re-build my server.
It kind of does matter, though, because at least for me, I am much more familiar with my home systems than what I use at work.
I started out using Redhat at work, so I migrated my home lab to CentOS to gain more familiarity, which meant that when new projects started, I advocated for Red Hat. But if I'm forced to migrate to a different production grade distro at home and develop expertise with it, the next time there's a question about what OS to use for a new project, I can imagine myself pushing for the one I will have spent the last few years tinkering with at home by that point instead.
It kind of does matter, though, because at least for me, I am much more familiar with my home systems than what I use at work.
I started out using Redhat at work, so I migrated my home lab to CentOS to gain more familiarity, which meant that when new projects started, I advocated for Red Hat. But if I'm forced to migrate to a different production grade distro at home and develop expertise with it, the next time there's a question about what OS to use for a new project, I can imagine myself pushing for the one I will have spent the last few years tinkering with at home by that point instead.
nothing is really free in this word! I think rollling your own distro is the only way to truly be free!
> It's proof of the downsides to the IBM acquisition, [...]
I think the movement to this outcome already started in January 2014 with this event:
https://www.zdnet.com/article/red-hat-incorporates-free-red-...
I think the movement to this outcome already started in January 2014 with this event:
https://www.zdnet.com/article/red-hat-incorporates-free-red-...
> For my server I want a boring, stable OS, so I'm definitely not using Streams.
Have you considered Ubuntu Server? "Being boring" and "having no vision" are frequent critiques of Ubuntu, which(as we probably all know) can be the highest possible compliment in some scenarios, like servers. They also have pretty decent LTS.
Have you considered Ubuntu Server? "Being boring" and "having no vision" are frequent critiques of Ubuntu, which(as we probably all know) can be the highest possible compliment in some scenarios, like servers. They also have pretty decent LTS.
Dunno. I just spent an hour trying to figure out how to set the DNS server on an interface on Ubuntu Server 20.04. There's no ifconfig, /etc/resolv.conf is out, no nslookup, /etc/network/interfaces is completely out.
It is like a completely new OS to me, and I've been hacking on UNIXes for 25 years now.
It is like a completely new OS to me, and I've been hacking on UNIXes for 25 years now.
I'm not sure the things you find missing are Ubuntu's fault. For example, while it's true that there is no ifconfig by default in Ubuntu (it's provided by a package called net-tools), one can read this:
> In 2009, Red Hat decided to deprecate ifconfig as the default command line network interface management utility, because the “net-tools” package (which provides ifconfig) did not support InfiniBand addresses (commonly used interconnect in high-performance computing applications).
So, many of the things that make Ubuntu look like a new OS to you, were actually decisions made by RedHat years ago, and they will also be present in newer RHEL versions.
> In 2009, Red Hat decided to deprecate ifconfig as the default command line network interface management utility, because the “net-tools” package (which provides ifconfig) did not support InfiniBand addresses (commonly used interconnect in high-performance computing applications).
So, many of the things that make Ubuntu look like a new OS to you, were actually decisions made by RedHat years ago, and they will also be present in newer RHEL versions.
That is a great opportunity to switch to Debian, which can be upgraded in place between major versions and, by being completely community driven, does not suffer from this kind of surprises.
If only it had comprehensive SELinux support...
There is AppArmor (enabled by default) which is another Linux Security Module.
I find it easier to configure than SELinux.
I find it easier to configure than SELinux.
Last time I checked, nothing was actually confined by AppArmor out of the box (IIRC I was looking at the output of ps -eZ and found that AppArmor wasn't actaully protecting anything...)
Specifically in RHEL/CentOS/Fedora I like that everything in the base system is reasonably well confined out of the box - including random container images that users insist on downloading/running. I don't know if AppArmor is even capable of doing this:
https://access.redhat.com/documentation/en-us/red_hat_enterp...
i.e., if I 'docker run --rm -it debian:unstable sleep 300' twice, then:
$ pgrep sleep | xargs ps -Z LABEL PID TTY STAT TIME COMMAND system_u:system_r:svirt_lxc_net_t:s0:c563,c603 1595289 pts/0 S+ 0:00 sleep 123 system_u:system_r:svirt_lxc_net_t:s0:c25,c163 1595325 pts/0 S+ 0:00 sleep 345
Both containers are confined by the svirt_lxc_net_t domain, but since they have different labels, they aren't able to interfere with each other, or the host system, even if the process inside the container is running as uid 0.
Specifically in RHEL/CentOS/Fedora I like that everything in the base system is reasonably well confined out of the box - including random container images that users insist on downloading/running. I don't know if AppArmor is even capable of doing this:
https://access.redhat.com/documentation/en-us/red_hat_enterp...
i.e., if I 'docker run --rm -it debian:unstable sleep 300' twice, then:
$ pgrep sleep | xargs ps -Z LABEL PID TTY STAT TIME COMMAND system_u:system_r:svirt_lxc_net_t:s0:c563,c603 1595289 pts/0 S+ 0:00 sleep 123 system_u:system_r:svirt_lxc_net_t:s0:c25,c163 1595325 pts/0 S+ 0:00 sleep 345
Both containers are confined by the svirt_lxc_net_t domain, but since they have different labels, they aren't able to interfere with each other, or the host system, even if the process inside the container is running as uid 0.
An interesting take on the impact of this change:
https://threadreaderapp.com/thread/1336603153341550592.html
https://threadreaderapp.com/thread/1336603153341550592.html
>> Imagine if you were running a business, and deployed CentOS 8
Sadly, the danger of running on free software.
Even more sadly, this puts a bad taste in peoples mouths, making them hesitant to start new projects on free software.
Sadly, the danger of running on free software.
Even more sadly, this puts a bad taste in peoples mouths, making them hesitant to start new projects on free software.
... as opposed to paid/proprietary software, that never breaks compatibility, hikes prices, or screws over their customers?
At least they don't advertise a support period then cut it 8 years short.
Companies do this all the time especially when there's an acquisition or change in management. In some cases they may technically still support it but with ever growing bugs, security issues and so on.
You’re conflating “free software” with “community support”. It’s possible to run free software with a paid support contract backed by a corporation - thats what RHEL offers, and Ubuntu with their Ubuntu Advantage program.
CentOS offered free software, but with unpaid community support, which isn’t guaranteed at all as there’s no contract.
This is an unpopular opinion but this is why I prefer Ubuntu over Debian - there’s a corporation on the other end that’s being paid to update software, and if you choose, you can always upgrade to paid support that is backed by a legally binding contract.
CentOS offered free software, but with unpaid community support, which isn’t guaranteed at all as there’s no contract.
This is an unpopular opinion but this is why I prefer Ubuntu over Debian - there’s a corporation on the other end that’s being paid to update software, and if you choose, you can always upgrade to paid support that is backed by a legally binding contract.
If you're using open source software and not paying anyone, sometimes shit happens and you will be surprised or disappointed and have no recourse. Even if everyone starts off with the best of intentions.
We could debate forever about whether fault lies with projects overpromising, or users having unrealistic expectations, or whatever else, but I don't think that changes the situation.
If you have are paying someone for the software/support, shit still happens, but you have a relationship and ways to get recourse.
We could debate forever about whether fault lies with projects overpromising, or users having unrealistic expectations, or whatever else, but I don't think that changes the situation.
If you have are paying someone for the software/support, shit still happens, but you have a relationship and ways to get recourse.
Yeah we have some now ageing CentOS 7 crap to clear up. The obvious choice was CentOS 8 but that is now uncertain. I’m glad I was too busy to take this on earlier in the year.
I did try to deploy CentOS 8 on several occasions during 2020 but mostly found it was not ready for what I needed to do.
So I defaulted back to CentOS 7. Which I now realize was lucky.
So I defaulted back to CentOS 7. Which I now realize was lucky.
You're absolutely right. You should definitely demand a full refund on all the money you've paid for CentOS!
Try Rocky Linux. Its the new Fork of Redhat from all of this.
did you pay for a support contract for centOS ? or is this something free you expected to be some contractual thing?
Running a business on a free product. That you knew RedHat acqui-hired. That you knew they had a history of using products such as to wedge people into a paying bracket.
Cry me a river.
Cry me a river.
There's lots of negative reaction going on, but this has happened before. CentOS grew out of RedHat Linux going away and Fedora being the feeder for RHEL. At the time there were a bunch of competitors that were building the RHEL source. CentOS ended up "winning".
I fully expect this to happen again. CentOS will wither and die because no one actually needs the cutting edge repo -- Ubuntu has a way better process for this. RHEL is build on open source. They publish their SPRM packages. A bunch of people will grab these and start bootstrapping DentOS and everyone will move to this. IBM will be sliced up by PE and RedHat will be owned by someone else. 10 years will go by and RHEL will acquire the leading "DentOS" and today's DevOps will be tomorrow's greybeards and will patiently wait for EentOS to emerge.
I fully expect this to happen again. CentOS will wither and die because no one actually needs the cutting edge repo -- Ubuntu has a way better process for this. RHEL is build on open source. They publish their SPRM packages. A bunch of people will grab these and start bootstrapping DentOS and everyone will move to this. IBM will be sliced up by PE and RedHat will be owned by someone else. 10 years will go by and RHEL will acquire the leading "DentOS" and today's DevOps will be tomorrow's greybeards and will patiently wait for EentOS to emerge.
i don't think in 10 years we will be installing distro on servers as we know it, watch this space!
What will change...? A lot of F500 companies have a lot of infrastructure and changes are not fast.. HPC industry is another one of those. Unless you mean startups?
The software industry as a whole has been moving away from major releases for commoditized products like web browsers for a long time. The OS has become one such product. Windows has been planning this for some time now: where is Windows 11? OSX has catchy release names but has reverted to macOS - no number. You’re right, change is slow, but I don’t think it’s an unreasonable statement. Large organizations will eventually catch up and/or roll their own solutions with internal devops teams. HPCs are already so highly specialized I’m not sure what the difference would be, and as virtualization performance continues to improve I think we will see a gradual, but not complete, shift from aggressive compiler optimization for niche architectures and configurations.
This isn't true for internal software tho, user facing, sure, but, chrome dependencies have a version pinned to them.
We will be starting hosts with preloaded images, write my words! :D
Are you thinking about RedHat Atomic Linux Server?
^this.
I believe Red Hat is anticipating this movement and betting on other things. Playing the long game.
It's sad, the community is sad, the employees are sad. But company-wise it makes sense.
I believe Red Hat is anticipating this movement and betting on other things. Playing the long game.
It's sad, the community is sad, the employees are sad. But company-wise it makes sense.
No it doesn't. Support your stuff until you have a replacement.
To me this news is at once shocking, and blindingly obvious in hindsight.
Shocking, because I'd never imagined they'd kill off CentOS 8 so early. CentOS 8.0 dates from Sept 2019, so it's killed in just the 3rd year of its presumed 10 year lifespan. I could read the tea leaves when they announced this Stream thingy recently, but I'd thought they would at least hold off till RHEL9 to pull the lever.
Blindingly obvious, of course, because Red Hat bought CentOS, presumably with real $$$, and IBM bought Red Hat for $34bln.
What's going to happen next? Microsoft buying Canonical and all businesses running either IBM Linux or Microsoft Linux? Crazier things have happened...
Shocking, because I'd never imagined they'd kill off CentOS 8 so early. CentOS 8.0 dates from Sept 2019, so it's killed in just the 3rd year of its presumed 10 year lifespan. I could read the tea leaves when they announced this Stream thingy recently, but I'd thought they would at least hold off till RHEL9 to pull the lever.
Blindingly obvious, of course, because Red Hat bought CentOS, presumably with real $$$, and IBM bought Red Hat for $34bln.
What's going to happen next? Microsoft buying Canonical and all businesses running either IBM Linux or Microsoft Linux? Crazier things have happened...
Its time for a new internet rule. If Oracle or IBM buys your vendor, you should be migrating.
That's almost true for any project getting acquired. The big EvilCorp will always have it's overbearing corporatey corporateness crush the things that made the project so cool it attracted their attention to it. There are very few projects that actually improved from being acquired.
Should probably add Salesforce to that list too. They’re basically the new Oracle.
Serious question: are they? I know they've made a lot of acquisitions over the years, but I don't recall any widely-circulated stories of "Salesforce takes beloved thing and destroys it". The major open-source-friendly company I know of that Salesforce bought was Heroku, and a lot of people seem to use Heroku without even knowing that they are owned by Salesforce (and have been since 2010). It seems like it's too early to say anything definitive about what their purchase of Slack is going to change, although Slack has been making itself quite enterprise-focused all on its own.
And CA, where software goes to die.
Sad, but accurate.
This isn't a new rule. This has been the standard for a long time.
[deleted]
It's a money grab, pure and simple. They've (Redhat, let alone IBM) done it before (see below).
What happens in practice with this sort of "rolling release" is users end up patching endlessly in production, which no sane person or organization would ever want to do. This was the exact situation for another Redhat acquisition for years now. JBoss EAP and community editions (wildfly now I suppose), everyone who could moved off of JBoss long ago.
What happens in practice with this sort of "rolling release" is users end up patching endlessly in production, which no sane person or organization would ever want to do. This was the exact situation for another Redhat acquisition for years now. JBoss EAP and community editions (wildfly now I suppose), everyone who could moved off of JBoss long ago.
Except IBM thinks that this will convert everyone to RHEL licenses and I'm positive that is not what's going to happen.
Ubuntu is already the default for people with ML pipelines and more and more vendors are targeting Ubuntu first for their software.
CentOS will be effectively dead for a lot of companies starting next year (or 2024). (At least we aren't planning on licensing 10^5 systems on RHEL...). I imagine for those same companies, RHEL isn't far behind it.
What's even worse here is that at least for us there are some things that we pay for RHEL for. If we switch all of our other servers, those RHEL licenses won't be continuing either.
Obvious, but stupid.
Ubuntu is already the default for people with ML pipelines and more and more vendors are targeting Ubuntu first for their software.
CentOS will be effectively dead for a lot of companies starting next year (or 2024). (At least we aren't planning on licensing 10^5 systems on RHEL...). I imagine for those same companies, RHEL isn't far behind it.
What's even worse here is that at least for us there are some things that we pay for RHEL for. If we switch all of our other servers, those RHEL licenses won't be continuing either.
Obvious, but stupid.
This. We run CentOS for non-critical stuff and RHEL for stuff that really needs support. If we need to switch off CentOS we certainly won't be using RHEL either. Doesn't make sense to be running a Debian flavour mixed with RHEL since the two a significantly different.
Yes clearly: we use CentOS at work because it's free (as in beer). If I go to my boss to ask money for a RedHat license he would laugh me out of his office.
Just wait when Mark Shuttleworth decides not to sponsor the project any longer.
Ubuntu followed Red-Hat's footsteps away from desktop into the server room, as there is no money to be done there, and it will follow it still, if there is still not enough money on the server.
Ubuntu followed Red-Hat's footsteps away from desktop into the server room, as there is no money to be done there, and it will follow it still, if there is still not enough money on the server.
Why wouldn't they switch to Debian instead? Their emphasis on stability matches that of CentOS more than Ubuntu, or at least did.
Because some important vendors don't target Debian whereas they do target Ubuntu.
Canonical and RedHat are paying the salaries of the people steering the direction of Linux as a whole. They're forcing you to choose between the two.
Canonical and RedHat are paying the salaries of the people steering the direction of Linux as a whole. They're forcing you to choose between the two.
Your forgetting Suse, I'll bet they take a big chunk of the customer base. OpenSuse LEAP is now identical to SLES and it can be converted easily if you want support.
But LEAP is only supported for 36 months? https://en.opensuse.org/Lifetime
That's pretty weak sauce even compared to the five years Debian and Ubuntu offer. And Debian actually supports all their packages, unlike Ubuntu which tricks people into installing unpatched garbage from 'universe'
That's pretty weak sauce even compared to the five years Debian and Ubuntu offer. And Debian actually supports all their packages, unlike Ubuntu which tricks people into installing unpatched garbage from 'universe'
Ubuntu has more predictable long term support.
Just so we're clear, you don't want updates ?
FreeBSD is starting to look really good.
I would agree that BSD systems are nicer to look at, and FreeBSD supporting major releases for five years, with forcing people to install point releases once a year is really quite nice.
But I don't see BSD becoming practical as a platform to run (commercial enterprise) Linux software, when it's already a pain to get packages and support for anything that's not RHEL/CentOS.
But I don't see BSD becoming practical as a platform to run (commercial enterprise) Linux software, when it's already a pain to get packages and support for anything that's not RHEL/CentOS.
It's not ideal, but you can run Linux software on FreeBSD. Commercial enterprise tends to be conservative and not need bleeding edge Linux interfaces that may not be available through the linux emulation layer yet.
I agree. I've been seeing more and more about the BSD's online recently, and to be quite honest, I'm happy about that.
Just installed OpenBSD for the first time the other day, and am loving it.
Just installed OpenBSD for the first time the other day, and am loving it.
This might help you on your start:
https://github.com/liv-io/ansible-roles-bsd
https://github.com/liv-io/ansible-roles-bsd
Looks like a nice resource, many thanks!
What are the usual roadblocks for people?
Needing VMs to perform well, comparably to KVM/Xen, would be a blocker for going BSD.
Jails are awesome but not containers you're blocked there as well (if you need containers and the tooling around them).
Jails are awesome but not containers you're blocked there as well (if you need containers and the tooling around them).
>VMs to perform well, comparably to KVM/Xen
Bhyve performs very well.
>Jails are awesome but not containers you're blocked there as well
What are containers? Ansible with OS-Virtualisation right? So with Jails and Salt/Ansible/puppet or Templates you have your Containers.
OR just take that:
https://bastillebsd.org/
Bhyve performs very well.
>Jails are awesome but not containers you're blocked there as well
What are containers? Ansible with OS-Virtualisation right? So with Jails and Salt/Ansible/puppet or Templates you have your Containers.
OR just take that:
https://bastillebsd.org/
> Red Hat bought CentOS, presumably with real $$$,
if I remember right technically centos didn't really exist as an entity that could be bought, Red Hat just hired all the developers (there were only ever 3-4 people working on centos). I would guess they are now working on Centos Streams, or have moved on to other things entirely. Its not like Centos has been killed off either, so it didn't cost a lot and this wont really save anything, it's "just" a change of focus.
Microsoft buying ubuntu would be an interesting (and not impossible) move though.
if I remember right technically centos didn't really exist as an entity that could be bought, Red Hat just hired all the developers (there were only ever 3-4 people working on centos). I would guess they are now working on Centos Streams, or have moved on to other things entirely. Its not like Centos has been killed off either, so it didn't cost a lot and this wont really save anything, it's "just" a change of focus.
Microsoft buying ubuntu would be an interesting (and not impossible) move though.
From their FAQ [0]:
[0]: https://centos.org/distro-faq/
Q4: How will CVEs be handled in CentOS Stream?
A: Security issues will be updated in CentOS Stream after they are solved in the current RHEL release.
[0]: https://centos.org/distro-faq/
It's essentially no different from how things currently are. RedHat releases updates, CentOS group picks those up and builds CentOS packages from them. They usually lag a day or two.
They really lagged on the PLATYPUS CPU vulnerability for CentOS 7, because they were dealing with a backlog from the 7.9 bump. Took them several days to get the patches out.
They really lagged on the PLATYPUS CPU vulnerability for CentOS 7, because they were dealing with a backlog from the 7.9 bump. Took them several days to get the patches out.
Which was expected since CentOS was a free (beer)rebuild of RHEL
CentOS Stream however is not a Free (beer) rebuild of RHEL anymore, it is an "upstream" for RHEL, so it would not be expected that this flow would work like described for an upstream product
CentOS Stream however is not a Free (beer) rebuild of RHEL anymore, it is an "upstream" for RHEL, so it would not be expected that this flow would work like described for an upstream product
Not true, because the current CO is not a rolling update.
RHEL security fixes for version X.Y may or may not fix security issues for version Z.A on CO, if the are not in sync.
RHEL security fixes for version X.Y may or may not fix security issues for version Z.A on CO, if the are not in sync.
> Not true, because the current CO is not a rolling update.
I'm not sure where I claimed it was?
I'm not sure where I claimed it was?
They're saying that Stream will be getting the normal package updates first as a kind of testbed, which is different than before.
So you're getting some instability by being first in line for updates, but you're still second fiddle for security fixes.
So you're getting some instability by being first in line for updates, but you're still second fiddle for security fixes.
Ahh okay, I can see how I didn't communicate myself clearly in initial message in the thread.
I was trying to point out this isn't different from a security perspective. Yes the rest of the distro is going to almost reach a rolling state which is definitely not something I want in production.
I was trying to point out this isn't different from a security perspective. Yes the rest of the distro is going to almost reach a rolling state which is definitely not something I want in production.
I guess the question will be how fast CentOS Stream releases fixes compared to Debian Stable/Testing and Ubuntu LTS.
It will almost certainly be slower than Ubuntu just because of the extra layer of work mentioned above.
Canonical are also fairly actively involved in security fixes and among those brought in to the various security embargoes. They usually ship packages the same day embargoes drop.
If by "involved" you mean "take patches that someone else developed and shared on the distros predisclosure list", then they are.
Interesting, who else are involved in the embargoes? Anywhere I could read more about this?
It depends on where the vulnerability is. Everything is all ad-hoc, each piece of open source software decides how they want to handle it, attempting to juggle the chances of a leak. The fewer you tell, the more likely the secret is to be kept, and you want to keep these things secret until a patch is done.
The linux kernel maintainers have a private list where they co-ordinate some of this stuff, and every major Linux distribution will have engineers on it.
That's partly why you see things like OpenBSD etc. being left on the margins. Certain maintainers have been quite vocal about not adhering to embargoes, which really doesn't help them. It's an idealist vs pragmatist thing going on there.
The linux kernel maintainers have a private list where they co-ordinate some of this stuff, and every major Linux distribution will have engineers on it.
That's partly why you see things like OpenBSD etc. being left on the margins. Certain maintainers have been quite vocal about not adhering to embargoes, which really doesn't help them. It's an idealist vs pragmatist thing going on there.
Embargos are coordinated on the "linux-distros" mailing list:
https://oss-security.openwall.org/wiki/mailing-lists/distros
https://oss-security.openwall.org/wiki/mailing-lists/distros
How is "everything a little after" the same as "some things prior, other things after"?
When I got started in business in the late 2000s, I was constantly fighting for Debian vs. CentOS, and eventually was forced to concede -- 95% of my customers wanted to run CentOS, all the more so given the exceptional conservatism of the telecom industry. They were attracted to its promise of long-term support and longevity, and, perhaps more vitally, it's what all the other organisations who sought an "enterprise-friendly" distribution were running.
Over time, much of my tooling and deployment processes has come to presume CentOS. If the customer base overwhelmingly runs CentOS, you build process for CentOS.
Thankfully, though, Systemd--for all its faults--has narrowed the painful deltas between Linux distributions enough that a switch back to a Debian target won't be too painful.
Where's your God now, "CentOS is something we can depend on, it's not just a rag-tag band of open-source hippies"?
Over time, much of my tooling and deployment processes has come to presume CentOS. If the customer base overwhelmingly runs CentOS, you build process for CentOS.
Thankfully, though, Systemd--for all its faults--has narrowed the painful deltas between Linux distributions enough that a switch back to a Debian target won't be too painful.
Where's your God now, "CentOS is something we can depend on, it's not just a rag-tag band of open-source hippies"?
Why don't the telecoms just pay for RHEL?
The December 31 2021 deadline is brutal for high-reliability infrastructure, but it principle the migration path is super simple, right?
The December 31 2021 deadline is brutal for high-reliability infrastructure, but it principle the migration path is super simple, right?
Some of them do. I've mainly got smaller companies and startup-type companies in mind.
Further, Debian gives a clean and normally very well working upgrade path, which I take anytime over Frankenstein backport updates keeping a distro release on life support until X years later one needs to redo everything.
Wow. I kind of new this day was coming. I work in engineering / science (not comp. sci or developing) and all our software vendors are Windows or RHEL support only. Although if you know your way around linux any flavor will do, but RHEL is the "standard" for support. It's kind of like "insurance." We expect this to compile / work for RHEL and NOTHING else, because RHEL is stable, predictable, and boring.
I've run most all the flavors of linux and am on the Ubuntu train. Actually, I flirted with the RHEL / Fedora / CentOS workflows as current as last year for a few months. I love the predictability and stability of RHEL on workstations and the thought of something new on a laptop or what not. While I respect the hell out of RH and their products, it just didn't work for me. Fedora is WAY too experimental, lacks supports, and is prone to your system breaking. I know, I know, it is pretty stable and has a lot of support behind it. But after updating via yum and having my WIFI stop working on my 6 year old Thinkpad, that is a deal breaker. I think there is way too much disconnect between their projects. RHEL is super stable, but the packages are severely outdated. Fedora is too experimental, and is pretty much a home operating system and a playground. I know CentOS is free, but depending on your business is paying $300 / year / machine for legitimate support and ticketing really an issue? That's for everyone to decide on their own. I think Ubuntu LTS is the best middle ground for stability and new packages. And if you need paid support and professional help, you can pay Canonical as well.
I could see this coming. CentOS didn't really show a value proposition for RH picking up the tab and supporting it. CentOS was recompiling RHEL and shipping it off; RH needs to keep their PR and image inline and HAD to help, since the whole point of CentOS was "this is RHEL without RH graphics and copyrighted material." IMO, RH felt like they were doing the same thing twice; producing RHEL, then removing RHEL branding and helping package up and compiling CentOS. Due to this, I think the biz folks scratched their on why they needed money, and now we have Centos Stream. I have no doubt another project will spin up taking up the slack of just recompiling RHEL.
Different tools for different jobs. Maybe Centos Stream will be awesome! Maybe it can fill the gap between Fedora and RHEL.
I've run most all the flavors of linux and am on the Ubuntu train. Actually, I flirted with the RHEL / Fedora / CentOS workflows as current as last year for a few months. I love the predictability and stability of RHEL on workstations and the thought of something new on a laptop or what not. While I respect the hell out of RH and their products, it just didn't work for me. Fedora is WAY too experimental, lacks supports, and is prone to your system breaking. I know, I know, it is pretty stable and has a lot of support behind it. But after updating via yum and having my WIFI stop working on my 6 year old Thinkpad, that is a deal breaker. I think there is way too much disconnect between their projects. RHEL is super stable, but the packages are severely outdated. Fedora is too experimental, and is pretty much a home operating system and a playground. I know CentOS is free, but depending on your business is paying $300 / year / machine for legitimate support and ticketing really an issue? That's for everyone to decide on their own. I think Ubuntu LTS is the best middle ground for stability and new packages. And if you need paid support and professional help, you can pay Canonical as well.
I could see this coming. CentOS didn't really show a value proposition for RH picking up the tab and supporting it. CentOS was recompiling RHEL and shipping it off; RH needs to keep their PR and image inline and HAD to help, since the whole point of CentOS was "this is RHEL without RH graphics and copyrighted material." IMO, RH felt like they were doing the same thing twice; producing RHEL, then removing RHEL branding and helping package up and compiling CentOS. Due to this, I think the biz folks scratched their on why they needed money, and now we have Centos Stream. I have no doubt another project will spin up taking up the slack of just recompiling RHEL.
Different tools for different jobs. Maybe Centos Stream will be awesome! Maybe it can fill the gap between Fedora and RHEL.
> I could see this coming. CentOS didn't really show a value proposition for RH picking up the tab and supporting it. CentOS was recompiling RHEL and shipping it off; RH needs to keep their PR and image inline and HAD to help, since the whole point of CentOS was "this is RHEL without RH graphics and copyrighted material."
Bear in mind that CentOS was originally an independent project until Red Hat acquired it.
Bear in mind that CentOS was originally an independent project until Red Hat acquired it.
You are correct! I think my point is that when your independent project grows so large that is has effect on the other, the main operator (RH) has to acknowledge it and do something about ti.
I have been using openSUSE. It's been pretty stable on the laptop. On laptop, I use the Tumbleweed (rolling release) and 15.1 or 15.2 on servers. Give it a try.
If you’re going to use Tumbleweed you might as well use CentOS stream, no?
I'm also a big fan of opensuse lately especially their tumbleweed microos. it's such a breeze to use transactional-update (automatically) and reboot a fleet with some looking mechanism (even with k8s kured).
suse cured my containerlinux wound. (if suse gets bought by ibm than I will be furious or if they kill microos)
suse cured my containerlinux wound. (if suse gets bought by ibm than I will be furious or if they kill microos)
What's the package management like? Does it support flatpaks? And what about LTS?
Packages are RPMS, managed with zypper. You may also use dnf but you will miss some of the advanced features provided by dnf (e. g. the concept of patches vs updates), there was a zypper vs dnf thread recently in the openSUSE mailing lists.
It does support flatpaks.
There is no free openSUSE LTS. The LTS is called SUSE Linux Enterprise Server, costs some money (unless you are a developer, in that case you get free subscriptions) and the LTS lasts for a minimum of 13 years.
It does support flatpaks.
There is no free openSUSE LTS. The LTS is called SUSE Linux Enterprise Server, costs some money (unless you are a developer, in that case you get free subscriptions) and the LTS lasts for a minimum of 13 years.
Ooops, I meant "you will miss some of the advanced features provided by zypper". It's dnf what's lacking the concept of patch, and many more.
On the other hand, dnf/yum downloads repos and packages in parallel while zypper still does everything one at a time, which means every kilobyte-sized package takes a second or two each to download, from setting up and tearing down a new TCP connection each time. It's especially annoying in Tumbleweed because rolling distro == lots of tiny packages updates all the time.
I have always wanted to try SUSE!
Zypper is awesome. The newest version of LEAP is identical to Suse Enterprise, you can convert with a simple script if you decide you want extended support.
The root filesystem uses btrfs, so it's easy to roll back update problems. There is also a newer version that uses a read-only root filesystem and updates are applied to a new snapshot that takes over when you reboot. It's pretty cool.
The root filesystem uses btrfs, so it's easy to roll back update problems. There is also a newer version that uses a read-only root filesystem and updates are applied to a new snapshot that takes over when you reboot. It's pretty cool.
Ubuntu phones home a lot.
Don't know if that applies to rhel
Don't know if that applies to rhel
not the server.
my biggest complaint about ubuntu server is that docker is packaged as a snap. But that takes 30s to fix (includding googling for a fix :) )
my biggest complaint about ubuntu server is that docker is packaged as a snap. But that takes 30s to fix (includding googling for a fix :) )
Is that ubuntu 20.04? I've used 18.04 extensively and it's just:
apt-get install docker.ioIndeed, typing in “docker” at the Ubuntu 20.04 command line tells you the above “apt-get install docker.io” command; one does not even need to waste time with a 30 second Google/DuckDuckGo search.
(Learning Ubuntu since CentOS went broke their pinky promise to supply security updates until 2029)
(Learning Ubuntu since CentOS went broke their pinky promise to supply security updates until 2029)
What was the point of Red Hat taking over CentOS then?
If they're just transparently killing of the "free version of RHEL", that surely won't work in anything but name? There's an obvious need for a 1:1 RHEL clone, and due to the license of all software that RHEL builds on, there's no way IBM or Red Hat can stop people from actually building their own "new CentOS" and many companies and communities have done so in the past.
All we have now is Red Hat taking the CentOS branding and running with it. And even that point I don't get - they could have done this with plain RHEL or Fedora branding too.
I get why Red Hat or IBM doesn't like CentOS' existence, but I am fully expecting this won't kill "CentOS the concept". This sequence of events boggles my mind really.
If they're just transparently killing of the "free version of RHEL", that surely won't work in anything but name? There's an obvious need for a 1:1 RHEL clone, and due to the license of all software that RHEL builds on, there's no way IBM or Red Hat can stop people from actually building their own "new CentOS" and many companies and communities have done so in the past.
All we have now is Red Hat taking the CentOS branding and running with it. And even that point I don't get - they could have done this with plain RHEL or Fedora branding too.
I get why Red Hat or IBM doesn't like CentOS' existence, but I am fully expecting this won't kill "CentOS the concept". This sequence of events boggles my mind really.
> All we have now is Red Hat taking the CentOS branding and running with it. And even that point I don't get - they could have done this with plain RHEL or Fedora branding too.
Yeah, it's all very confusing. The only thing I can think of at the moment is that CentOS has so much mind-share that RHEL wants to tap into that and funnel it back to themselves more effectively. It used to be people knew what Red Hat was and you had to tell them about CentOS, now so many people use and know CentOS I think there's probably a good chance a lot of them don't even know that it's a respin of RHEL.
All of this only makes sense to me if the whole point is to leverage the popularity of CentOS into more RHEL subscriptions by providing a product that's more annoying for most people that care about a stable server (because it's backing their business) to use because it's less static.
Personally, I think it doesn't matter why Red Hat bought CentOS, what matters is what they just did, and as I think that's purely self serving (and to the detriment of the public and community) and if there are apologist engineers here that work for RH, perhaps they should look closely at how management is managing them, because of course management is going to present it in a way that tries not to alienate their staff and community. The results speak for themselves though, CentOS in the form that so many people relied on is effectively dead in a year.
Yeah, it's all very confusing. The only thing I can think of at the moment is that CentOS has so much mind-share that RHEL wants to tap into that and funnel it back to themselves more effectively. It used to be people knew what Red Hat was and you had to tell them about CentOS, now so many people use and know CentOS I think there's probably a good chance a lot of them don't even know that it's a respin of RHEL.
All of this only makes sense to me if the whole point is to leverage the popularity of CentOS into more RHEL subscriptions by providing a product that's more annoying for most people that care about a stable server (because it's backing their business) to use because it's less static.
Personally, I think it doesn't matter why Red Hat bought CentOS, what matters is what they just did, and as I think that's purely self serving (and to the detriment of the public and community) and if there are apologist engineers here that work for RH, perhaps they should look closely at how management is managing them, because of course management is going to present it in a way that tries not to alienate their staff and community. The results speak for themselves though, CentOS in the form that so many people relied on is effectively dead in a year.
That's a good explanation, but I'm sad they're committed to just wasting everybody's time.
They took it over to kill it, that seems rather obvious. This definitely seems to be an IBM thing even though they said they'd basically leave Redhat alone for the most part and just enjoy pulling it into their sphere of software. So much for that.
> What was the point of Red Hat taking over CentOS then?
Embrace, Extend, Extinguish.
They're probably banking on it taking a few years for a standard centos replacement to be established.
Embrace, Extend, Extinguish.
They're probably banking on it taking a few years for a standard centos replacement to be established.
What I'm wondering is how open the CentOS build tooling is at this point, and to a lesser degree how open it was in the past and when it changed if it did.
Companies’ strategies change with time. RH took over CentOS in 2014, but then was itself bought by IBM last year. So what was the plan (and the leadership) in 2014 is not necessarily the plan (and the leadership) in 2020.
Also, conditions change. RH might have decided that Centos had become a bit too successful and was cannibalizing actual RHEL sales (covid year, everyone is hurting, people try to skimp on licenses...).
Also, conditions change. RH might have decided that Centos had become a bit too successful and was cannibalizing actual RHEL sales (covid year, everyone is hurting, people try to skimp on licenses...).
> CentOS Linux 8, as a rebuild of RHEL 8, will end at the end of 2021
Does this mean that CentOS 8 is EOL come 2021? Weren't maintenance updates meant to go to 2029? What about everybody who built their product on the assumption that there would be a stable CentOS until then?
Does this mean that CentOS 8 is EOL come 2021? Weren't maintenance updates meant to go to 2029? What about everybody who built their product on the assumption that there would be a stable CentOS until then?
Yes. https://wiki.centos.org/About/Product
It used to be this. https://web.archive.org/web/20201101131417/https://wiki.cent...
It used to be this. https://web.archive.org/web/20201101131417/https://wiki.cent...
Yup. Edited today. Why even publish the EOL dates, at this point? They're meaningless.
That page is a Wiki and here is the diff between the current version and the previous: https://wiki.centos.org/action/info/About/Product?action=dif...
That page is a Wiki and here is the diff between the current version and the previous: https://wiki.centos.org/action/info/About/Product?action=dif...
Wow.. I literally just migrated my main production mail server to centos8 hoping to let it run for another 10 years...
I guess it is time to study alternatives..
Wow. Violently disingenuous.
> Does this mean that CentOS 8 is EOL come 2021?
They've just eradicated almost all mentions of CentOS 8 from their main website. So: yes.
> What about everybody who built their product on the assumption that there would be a stable CentOS until then?
They just got what they paid for?
They've just eradicated almost all mentions of CentOS 8 from their main website. So: yes.
> What about everybody who built their product on the assumption that there would be a stable CentOS until then?
They just got what they paid for?
> They just got what they paid for?
Funny, but isn't this totally reasonable grounds for an adverse possession claim against RHEL?
If a business claims they're going to keep doing something, and you build your business on that claim, and then they change their mind, you can have grounds to sue. Or, at least, that's what I vaguely remember from reading about AP law.
Funny, but isn't this totally reasonable grounds for an adverse possession claim against RHEL?
If a business claims they're going to keep doing something, and you build your business on that claim, and then they change their mind, you can have grounds to sue. Or, at least, that's what I vaguely remember from reading about AP law.
That's not adverse possession. I think you are referring to promissory estoppel: https://www.law.cornell.edu/wex/promissory_estoppel#
I think the problem is that it’s not like red hat has a contractual obligation with other businesses since Centos is essentially “free” and likely there isnt an agreement.
That is not at all what adverse possession is.
> They just got what they paid for?
Not really. If you depend on CentOS it is reasonable you would contribute to it. There has to be a nonzero number of CentOS users that contributed to the project ("paid") that are now left holding the bag.
Not really. If you depend on CentOS it is reasonable you would contribute to it. There has to be a nonzero number of CentOS users that contributed to the project ("paid") that are now left holding the bag.
> There has to be a nonzero number of CentOS users that contributed to the project ...
Not really.
Just TRY to "contribute" to CentOS. You can't.
CentOS hasn't been a "community" enterprise operating system for years.
Not really.
Just TRY to "contribute" to CentOS. You can't.
CentOS hasn't been a "community" enterprise operating system for years.
> They just got what they paid for?
Haha, fair. To be honest, I'm surprised it took this long for it to happen after CentOS joined Red Hat. I wonder if the IBM acquisition had any influence on this.
Haha, fair. To be honest, I'm surprised it took this long for it to happen after CentOS joined Red Hat. I wonder if the IBM acquisition had any influence on this.
Seems like some folks are considering to create an alternative:
https://blog.centos.org/2020/12/future-is-centos-stream/#com...
https://join.slack.com/t/hpcng/shared_invite/zt-gy0st6mt-ijg...
https://blog.centos.org/2020/12/future-is-centos-stream/#com...
https://join.slack.com/t/hpcng/shared_invite/zt-gy0st6mt-ijg...
Having a more "front runner" distro for RHEL (RedHat Enterprise) is great for RedHat. Since bugs will probably be caught in CentOS and don't end up in RHEL. This front runner role was actually intended for Fedora however Fedora contains way too much experimental changes for anyone to seriously try to run it on servers.
I don't want to sound too "tin-foil headed" but I guess now that RedHat has hired the main CentOS dev(s?) this change comes from RedHat. I can't imagine the CentOS user base wants this direction for the CentOS project (or maybe thats just my lack of imagination...). People who use CentOS want a boring Linux distro like RHEL. They just don't want to pay for RHEL subscriptions.
I don't want to sound too "tin-foil headed" but I guess now that RedHat has hired the main CentOS dev(s?) this change comes from RedHat. I can't imagine the CentOS user base wants this direction for the CentOS project (or maybe thats just my lack of imagination...). People who use CentOS want a boring Linux distro like RHEL. They just don't want to pay for RHEL subscriptions.
> People who use CentOS want a boring Linux distro like RHEL. They just don't want to pay for RHEL subscriptions.
I use CentOS a lot for prototyping projects destined to be put on RHEL servers. I like it as a try-before-you-buy version of RHEL, and this change makes that use case a lot less useful.
I use CentOS a lot for prototyping projects destined to be put on RHEL servers. I like it as a try-before-you-buy version of RHEL, and this change makes that use case a lot less useful.
I think that your use-case matches perfectly with RHEL free developer license.
The free RHEL development license doesn't allow for even a whim of something that could be considered production usage.
So you can't make a proof of concept with the RHEL developer license in which you let "the business", customers, etc. toy around for a while.
So you can't make a proof of concept with the RHEL developer license in which you let "the business", customers, etc. toy around for a while.
A group of us was sent to Red Hat for a kernel class (week long, excellent) over 10 years ago. We were moving off HP-UX which offered really excellent real time extensions (disabling interups on a per cpu basis...processor sets, and other fun)
The instructor told us if we wanted to try some of the things we were doing in class to experiment more, we could try it on CentOS. it was the practically the same. This was before Red Hat “ acquired” them.
The instructor told us if we wanted to try some of the things we were doing in class to experiment more, we could try it on CentOS. it was the practically the same. This was before Red Hat “ acquired” them.
>>Since bugs will probably be caught in CentOS
That is only true if CentOS continues to be widely adopted, with this move by RedHat i do not see that continuing, I am sure many org's right now are looking for options to move off CentOS / RHEL stacks.
That is only true if CentOS continues to be widely adopted, with this move by RedHat i do not see that continuing, I am sure many org's right now are looking for options to move off CentOS / RHEL stacks.
RHEL bought CentOS 6 years ago.
Note that the announcement blog post points folks to using RedHat instead.
Embrace, Extend, Extinguish succeeded?
Note that the announcement blog post points folks to using RedHat instead.
Embrace, Extend, Extinguish succeeded?
If they just want a free (beer) RHEL clone, the best choice might turn out to be ... Oracle Linux. Who would have thought?
> might turn out to be ... Oracle Linux
Is CentOS the upstream for Oracle Linux? Instead of which comes CentOS Stream and then the question is what will Oracle do? Would they even try to keep the old CentOS concept alive?
Is CentOS the upstream for Oracle Linux? Instead of which comes CentOS Stream and then the question is what will Oracle do? Would they even try to keep the old CentOS concept alive?
I'm pretty sure that OEL is derived directly from RHEL, particularly because OEL 8 shipped while CentOS was still figuring out how to deal with streams.
EDIT: This may be inaccurate; see https://news.ycombinator.com/item?id=25348496
EDIT: This may be inaccurate; see https://news.ycombinator.com/item?id=25348496
Isn't Amazon Linux basically the same? Or is that a fork of CentOS in the first place?
CentOS is how RedHat releases their sources in compliance with open source licenses (Presumably they're going back to releasing them as a consequence for this).
My familiarity with Amazon Linux is about 4 years out-of-date these days, but it was a RHEL/CentOS clone with a number of the core libraries like glibc being updated and maintained by Amazon on an independent life cycle.
My familiarity with Amazon Linux is about 4 years out-of-date these days, but it was a RHEL/CentOS clone with a number of the core libraries like glibc being updated and maintained by Amazon on an independent life cycle.
Can I download and run Amazon Linux at home (non-vm)?
[deleted]
Not really. You can use Alibaba Cloud Linux 2 like that if you want but why would you do that? Oracle Linux, CloudLinux, Debian or openSUSE Leap are better choices.
> People who use CentOS want a boring Linux distro like RHEL. They just don't want to pay for RHEL subscriptions.
There's a lot of people using CentOS indirectly, through CloudLinux. Whatever happens there, a lot of people will be affected.
There's a lot of people using CentOS indirectly, through CloudLinux. Whatever happens there, a lot of people will be affected.
And Scientific Linux, and Amazon Linux, etc.
SL never released version 8 (they switched to CentOS8). Amazon (correct me if I'm wrong) does not release installer ISOs. AFAIK, closest to a plain free RHEL8 clone is Oracle Linux.
There's also Springdale Linux.
Wow I forgot it existed. I must've erased it from my mind along with Scientific Linux. Nice to see they've kept it up-to-date so far.
> People who use CentOS want a boring Linux distro like RHEL. They just don't want to pay for RHEL subscriptions.
How dare they want a free operating system?
How dare they want a free operating system?
How dare tens of thousands of developers produce a free operating system, and it gets sold by one business who added graphics of a trademarked hat?
You do realize that a non-trivial number of contributions to Linux come from professional developers working at companies like Google, IBM, and RH?
Agreed, a significant part of Linux's graphical stack (GNOME, mesa, pipewire, etc.) is maintained by people whose email end in @redhat.com
For now. As with all acquisitions it's only a matter of when.
Except acquisitions work out just as often as they don't.
Sounds straightforward to maintain your own fork in that case.
> Having a more "front runner" distro for RHEL (RedHat Enterprise) is great for RedHat. Since bugs will probably be caught in CentOS and don't end up in RHEL.
I thought that Fedora was already serving this role
I thought that Fedora was already serving this role
Not really. RHEL / CentOS is basically a hardened snapshot of Fedora taken every few years, with a few bespoke changes on top. So in that sense you could argue that Fedora is a front-runner for "the next RHEL" but at any point in time it is too far ahead of the current RHEL to be a useful testbed in any respect for those users. Although I guess you could argue that it helps knock down bugs in packages like GNOME that do get updated regularly in RHEL.
CentOS Stream is basically "the next x.y release of RHEL". Some updates, like GNOME updates and new hardware enablement, will be present in CentOS Stream a few months before they are released to RHEL and CentOS as part of a new x.y-release.
CentOS Stream is basically "the next x.y release of RHEL". Some updates, like GNOME updates and new hardware enablement, will be present in CentOS Stream a few months before they are released to RHEL and CentOS as part of a new x.y-release.
Yes, this is exactly it. The conspiracy theories about buying-CentOS-to-kill it are understandable but totally off-base. Red Hat brought CentOS in-house at a time when the company was trying to grow from being a single-product company to a portfolio one, and it became clear that Fedora wasn't working for what at the time RH called "layered products". The hope was that CentOS would provide a more-RHEL-like community place for work like RDO to happen. That was partially successful, but the plan wasn't really realized — and speaking from a Fedora point of view, that "Fedora is failing at a thing we need so we'll turn to CentOS" wasn't a healthy dynamic for either project. CentOS Stream serves the initial purpose better, and now RH's distro ecosystem story is actually linear rather than a crazy MC Escher contortion.
To be honest, I think this is bs. The CentOS community is huge and RH benefits a lot from the discoveries made by the community.
However, doing this will effectively make CentOS as a server OS useless for the most of us. "But Facebook uses it" - well, yes, with thousands of engineers Facebook could run their own distro and still have success if they wanted. Most useless argument ever.
Time to move on and find something else. Maybe good old Debian.
However, doing this will effectively make CentOS as a server OS useless for the most of us. "But Facebook uses it" - well, yes, with thousands of engineers Facebook could run their own distro and still have success if they wanted. Most useless argument ever.
Time to move on and find something else. Maybe good old Debian.
"But Facebook uses it"
Since Facebook actually uses kernels from Fedora Rawhide (necessary for btrfs support I guess), their systems are nowhere near the CentOS you and I would use.
Since Facebook actually uses kernels from Fedora Rawhide (necessary for btrfs support I guess), their systems are nowhere near the CentOS you and I would use.
Facebook have their own kernel developers. It was a selling point one of their teams used to try to lure me there.
It must be a classic selling point... a French company (pretty big) told me the same thing to lure me (even if my hypothetical job was not directly related to that fact)
"We spend company resources on work that gets released as open-source software" is always preferable to a company never contributing back to OSS.
Correct me if I'm wrong, but the way I read this, CentOS Stream will still serve as a stable clone of RHEL just as it always has. The rolling distro will be tagged at a certain point in time for a RHEL release, and you can still choose to use that state as your production base, and be locked at that tag. Presumably there will be a CentOS Stream 9 tag that you can use for production. The difference will be that CentOS will lead rather than follow the RHEL release.
I think the doom and gloom is a misunderstanding.
I think the doom and gloom is a misunderstanding.
From https://www.centos.org/centos-stream/
CentOS Stream
Continuously delivered distro that tracks just ahead of Red Hat Enterprise Linux (RHEL) development, positioned as a midstream between Fedora Linux and RHEL. For anyone interested in participating and collaborating in the RHEL ecosystem, CentOS Stream is your reliable platform for innovation.
That doesn't seem to be what you think it is, at least in my eyes. I'm definitely not looking to run something positioned between Fedora and RHEL. There's already enough updates every month (including multiple kernel updates a month sometimes) that it's hard to keep the fleet updated. I definitely don't need stuff ahead of RHEL where I can assume I'm a bit of a guinea pig to test out the coming RHEL update.
CentOS Stream
Continuously delivered distro that tracks just ahead of Red Hat Enterprise Linux (RHEL) development, positioned as a midstream between Fedora Linux and RHEL. For anyone interested in participating and collaborating in the RHEL ecosystem, CentOS Stream is your reliable platform for innovation.
That doesn't seem to be what you think it is, at least in my eyes. I'm definitely not looking to run something positioned between Fedora and RHEL. There's already enough updates every month (including multiple kernel updates a month sometimes) that it's hard to keep the fleet updated. I definitely don't need stuff ahead of RHEL where I can assume I'm a bit of a guinea pig to test out the coming RHEL update.
From the FAQ https://centos.org/distro-faq/ :
"Q6: Will there be separate/parallel/simultaneous streams for 8, 9, 10, etc?
"A: Each major release will have a branch, similar to how CentOS Linux is currently structured; however, CentOS Stream is designed to focus on RHEL development, so only the latest Stream will have the marketing focus of the CentOS Project.
"Because RHEL development cycles overlap, there will be times when there are multiple code branches in development at the same time.This allows users time to plan migrations and development work without being surprised by sudden changes.
"Specifically, since the RHEL release cadence is every 3 years, and the full support window is 5 years, this gives an overlap of approximately 2 years between one stream and the next."
Also from Q2:
"We will not be producing a CentOS Linux 9, as a rebuild of RHEL 9. Instead CentOS Stream 9 fulfills this role. (See Q6 below regarding the overlap between concurrent streams.)"
So it sounds to me like my assumption is correct: There will be separate streams reflecting each RHEL release.
Read the whole FAQ. This is not what people think it is.
"Q6: Will there be separate/parallel/simultaneous streams for 8, 9, 10, etc?
"A: Each major release will have a branch, similar to how CentOS Linux is currently structured; however, CentOS Stream is designed to focus on RHEL development, so only the latest Stream will have the marketing focus of the CentOS Project.
"Because RHEL development cycles overlap, there will be times when there are multiple code branches in development at the same time.This allows users time to plan migrations and development work without being surprised by sudden changes.
"Specifically, since the RHEL release cadence is every 3 years, and the full support window is 5 years, this gives an overlap of approximately 2 years between one stream and the next."
Also from Q2:
"We will not be producing a CentOS Linux 9, as a rebuild of RHEL 9. Instead CentOS Stream 9 fulfills this role. (See Q6 below regarding the overlap between concurrent streams.)"
So it sounds to me like my assumption is correct: There will be separate streams reflecting each RHEL release.
Read the whole FAQ. This is not what people think it is.
I'm not sure if you don't understand how RHEL/CentOS point releases and bugfixes work, or if you're reading something in the FAQ I'm not.
Right now, in RHEL 8.2, if a package needs a bug fix, it will be back-ported so that you get the fix in the existing running version of that package that was shipped in 8.2. On point releases, RHEL (and thus CentOS) may choose to back-port a feature, functionality, or choose to update the version of the package that is running to a newer version that has those features or functionality (or to bring it in-line with back-patches, I assume). When you update to a new point release, this gives you a single large update set that you can test to make sure functions well in your infrastructure. There have been points in the past where changes in point releases have required us to make changes to our configs or setup to deal with the RHEL/CentOS's point release changes (even though it's supposed to be rare, it happens, but it's mostly contained to these big testable update sets).
CentOS mirrored this exactly, because it mirrored RHEL.
Now CentOS is going to do something different, and these updates that would be relegated to point releases look like they are going to come down continuously. While not as problematic as something like Fedora, this is still something that groups specifically chose CentOS to avoid.
It's nice that Red Hat is offering something to allow people to get fixes and features sooner than at point release times, but to switch CentOS to only providing that is extremely problematic to the very large community that expects otherwise, supported CentOS, and has done both since prior to Red Hat hiring some of the main CentOS developers and effectively controlling the project, and is notably different than what CentOS has always traditionally attempted to provide.
Right now, in RHEL 8.2, if a package needs a bug fix, it will be back-ported so that you get the fix in the existing running version of that package that was shipped in 8.2. On point releases, RHEL (and thus CentOS) may choose to back-port a feature, functionality, or choose to update the version of the package that is running to a newer version that has those features or functionality (or to bring it in-line with back-patches, I assume). When you update to a new point release, this gives you a single large update set that you can test to make sure functions well in your infrastructure. There have been points in the past where changes in point releases have required us to make changes to our configs or setup to deal with the RHEL/CentOS's point release changes (even though it's supposed to be rare, it happens, but it's mostly contained to these big testable update sets).
CentOS mirrored this exactly, because it mirrored RHEL.
Now CentOS is going to do something different, and these updates that would be relegated to point releases look like they are going to come down continuously. While not as problematic as something like Fedora, this is still something that groups specifically chose CentOS to avoid.
It's nice that Red Hat is offering something to allow people to get fixes and features sooner than at point release times, but to switch CentOS to only providing that is extremely problematic to the very large community that expects otherwise, supported CentOS, and has done both since prior to Red Hat hiring some of the main CentOS developers and effectively controlling the project, and is notably different than what CentOS has always traditionally attempted to provide.
It used to be
Fedora -> RHEL -> CentOS
with the addition of CentOS stream it was becoming
Fedora -> CentOS Stream -> RHEL -> CentOS
now what it is
Fedora -> CentOS Stream -> RHEL
Fedora -> RHEL -> CentOS
with the addition of CentOS stream it was becoming
Fedora -> CentOS Stream -> RHEL -> CentOS
now what it is
Fedora -> CentOS Stream -> RHEL
Absolutly not, it's going to be the Fedora version of RHEL. Pretty clear:
"If you are using CentOS Linux 8 in a production environment, and are concerned that CentOS Stream will not meet your needs, we encourage you to contact Red Hat about options."
Of course no one want to run CentOS Stream because it's going to be broken / unstable, completely the opposite of what CentOS is.
"If you are using CentOS Linux 8 in a production environment, and are concerned that CentOS Stream will not meet your needs, we encourage you to contact Red Hat about options."
Of course no one want to run CentOS Stream because it's going to be broken / unstable, completely the opposite of what CentOS is.
Fedora is the Fedora version of RHEL. Are you saying that CentOS Stream is going to be directly equivalent to Fedora?
That's what it sounds. Maybe Fedora/CentOS/RHEL :: Dev/Test/Prod
It seems that if you do that, you will not get any updates, including security updates?
Yah, it sounds that way.
Rolling forward to the head is required to get the most recent security updates. Which isn't that far away from how centos works today. With rhel you get security updates for the point releases (8.1,8.2,etc) for a while after the new point release comes out. With centos, the day that the newer version drops, they don't tend to roll security updates into the older ones.
Rolling forward to the head is required to get the most recent security updates. Which isn't that far away from how centos works today. With rhel you get security updates for the point releases (8.1,8.2,etc) for a while after the new point release comes out. With centos, the day that the newer version drops, they don't tend to roll security updates into the older ones.
These are not frozen releases. They are parallel streams that each get their own CVE updates from the corresponding RHEL release.
Not true.
Q4: How will CVEs be handled in CentOS Stream? A: Security issues will be updated in CentOS Stream after they are solved in the current RHEL release. Obviously, embargoed security releases can not be publicly released until after the embargo is lifted. While there will not be any SLA for timing, Red Hat Engineers will be building and testing other packages against these releases. If they do not roll in the updates, the other software they build could be impacted and therefore need to be redone. There is therefore a vested interest for them to get these updates in so as not to impact their other builds and there should be no issues getting security updates.
Q4: How will CVEs be handled in CentOS Stream? A: Security issues will be updated in CentOS Stream after they are solved in the current RHEL release. Obviously, embargoed security releases can not be publicly released until after the embargo is lifted. While there will not be any SLA for timing, Red Hat Engineers will be building and testing other packages against these releases. If they do not roll in the updates, the other software they build could be impacted and therefore need to be redone. There is therefore a vested interest for them to get these updates in so as not to impact their other builds and there should be no issues getting security updates.
So basically, instead of CentOS being as stable as RHEL, they're positioning it in between Fedora and RHEL stability. Basically the Debian Testing branch for RHEL.
This is just a rebranding move to push businesses that were using CentOS to actually buy a RHEL license, lol.
This is just a rebranding move to push businesses that were using CentOS to actually buy a RHEL license, lol.
Wait, RedHat owns CentOS?
I always considered CentOS to be (roughly) RHEL without the support.
RHEL is nearly identical in practical use because they use the same libraries and tooling for the most part. I guess I've always just assumed CentOS was "Free RedHat".
RHEL is nearly identical in practical use because they use the same libraries and tooling for the most part. I guess I've always just assumed CentOS was "Free RedHat".
> Generally speaking, we expect CentOS Stream to have fewer bugs and more runtime features than RHEL until those packages make it into the RHEL release
So basically not what your comment is trying to imply here. Also, what is "lol" about it?
So basically not what your comment is trying to imply here. Also, what is "lol" about it?
Not what stability means in this context - naively, CentOS Stream is considerably more likely to lead to broken development builds, inscrutable library inconsistencies, driver weirdness, etc, than the previous distribution model. It also poses ugly questions for teams who need certified processes or strict security requirements.
I could be missing something and I don’t think the motivations are strictly mercantile, but this does make CentOS Stream much less appealing (compared to RHEL) than CentOS 7/8. I am personally not that affected by all this (my org uses RHEL) but it’s a huge hassle for a good number of serious CentOS users.
I could be missing something and I don’t think the motivations are strictly mercantile, but this does make CentOS Stream much less appealing (compared to RHEL) than CentOS 7/8. I am personally not that affected by all this (my org uses RHEL) but it’s a huge hassle for a good number of serious CentOS users.
So CentOS is no longer relevant for production use. I wonder who stands to benefit. I really don't see it driving more sales to RHEL like the execs probably predict.
> If you are using CentOS Linux 8 in a production environment, and are concerned that CentOS Stream will not meet your needs, we encourage you to contact Red Hat about options.
...sounds like what they expect
> it removes confusion around what “CentOS” means in the Linux distribution ecosystem
This justification for the change seems like a solution to a problem that doesn't yet exist but probably will soon!
...sounds like what they expect
> it removes confusion around what “CentOS” means in the Linux distribution ecosystem
This justification for the change seems like a solution to a problem that doesn't yet exist but probably will soon!
Agreed. I never thought there was any confusion about what CentOS meant. This feels like B.S.
To me it was literally the most straightforward Linux distro: RHEL without the license & trademarked material
I've been leaning on Debian-based distros for my own servers for a while now, but I still use CentOS in the lab. Hopefully RedHat provides an easy way to legally develop on RHEL without messing with a license.
I've been leaning on Debian-based distros for my own servers for a while now, but I still use CentOS in the lab. Hopefully RedHat provides an easy way to legally develop on RHEL without messing with a license.
RedHat provides developer subscriptions to their products: https://developers.redhat.com/articles/getting-red-hat-devel...
And this will be expanding to cover more use cases. See https://www.redhat.com/en/blog/faq-centos-stream-updates#Q10:
_In the first half of 2021, we will be introducing low- or no-cost programs for a variety of use cases, including options for open source projects and communities, partner ecosystems and an expansion of the use cases of the Red Hat Enterprise Linux Developer subscription to better serve the needs of systems administrators and partner developers._
_In the first half of 2021, we will be introducing low- or no-cost programs for a variety of use cases, including options for open source projects and communities, partner ecosystems and an expansion of the use cases of the Red Hat Enterprise Linux Developer subscription to better serve the needs of systems administrators and partner developers._
However, if you're in the SMB space and run CentOS as production because money is tight but you wanted a stable LTS distro and have never needed any technical support, this move has just yanked the rug out from under you and there appear to be no provisions in the pipeline to change that.
Your only option is to migrate away from RHEL/CentOS, period. It's likely that Red Hat doesn't care much about us smaller orgs with only 100-200 servers/VMs though. Sad day.
Your only option is to migrate away from RHEL/CentOS, period. It's likely that Red Hat doesn't care much about us smaller orgs with only 100-200 servers/VMs though. Sad day.
How about discounts for universities? They could take a page from Microsoft, which introduces students and teachers to its ecosystem with low-cost versions of Windows and Office.
The .edu I used to work at had a site license for RHEL (and Satellite servers) 15+ years or so ago.
I believe we were one of the first 10 or so, but I don't remember exactly when it started.
I believe we were one of the first 10 or so, but I don't remember exactly when it started.
I don't know the specifics but I would be surprised if this isn't one of the areas under consideration.
And these licenses and subscriptions come and go at the whim of the corporations that own them. Nobody informed would base their open source project/community/ecosystem on something like this, unless they want to be left out in the cold when the plug gets pulled in the future.
Thanks for the link! Seems like an oversight that it was left out of the CentOS Stream announcement.
Summarizing the FAQ:
Summarizing the FAQ:
- the bits are the same, the differences are the terms of use and the self-support level
- one subscription per user
- allowed to use on 1 physical system (up to 2 processor sockets, 16 VMs)Well said. The "confusion" was probably only in Redhat, when developers were confronted with explaining to executives why they provide RHEL for free.
RedHat will probably get a one time boost in RHEL sales at the expense that the void created by the CentOS project will be filled by some CentOS-fork they have no control over.
Maybe they have some grand scheme I'm not seeing but it feels short sighted.
Maybe they have some grand scheme I'm not seeing but it feels short sighted.
Arguably, IBM has done a lot of short-term things in recent decades.
Until IBM / Red Hat acquires that fork just like they did CentOS
A community-controlled organization could just opt to not be acquired (and indeed should, given this precedent).
This sort of cloning effort tend to live in contractual grey areas. Would that community (of people who got together to avoid paying for licenses) be ready to pay to defend developers from expensive lawsuits filed by one of the wealthiest corporates on the planet? Or rather, would developers in charge of such projects believe that? An acqui-hire with fuck-you money on one side, vs years of pain and likely bankruptcy - it’s not really a choice, is it?
...the contractual grey area of assembling a software distribution of open-source software in keeping with the license of that software? What exactly are they going to have a lawsuit over?
There is always something, like Samba and whatnot - some build system you claim copyright to, or some utility with a different license etc etc. It doesn’t need to be a slam dunk, it doesn’t need to win at all, it just has to be enough to keep a lawsuit running for a year or so. The legal system can be used as a DDOS in many, many situations, even when the defendant is spotless.
I bet lots of users will migrate to Oracle Linux and some of them will become paid users in the future.
This definitely seems like a bean counter move to me.
I m torn about this move. My gut reaction was that this was a bean-counter move. Thinking more about it the key issues I see with this move are:
- CENTOS fills a need, that many users have and superficially it looks like Red Hat (IBM) is now abandoning addressing it. On the other hand Red Hat does offer RHEL for free (gratis) [0] and that should fill the needs of CENTOS users (right?). However it would have been much better if that option was mentioned in the announcement.
- I thought Fedora was upstream of RHEL. However after thinking more about it I realised that RHEL has a significant delta over Fedora. I 'm guessing CENTOS stream will be partway between Fedora and RHEL. It makes sense from Red Hats open development approach to have the delta between Fedora and RHEL happen in the open. Done right that should strengthen RHEL.
- Why the rush to drop support for CENTOS 8? I m sure some people are using it in production and they are unlikely to to want to move to this new CENTOS stream. It's a new OS distribution with a philosophy different to the one that was right for them!
Overall I 'd prefer if the new thing was called RHEL stream and provided for free (gratis) as CENTOS stream is. Also making more explicit the RHEL availability for free instead of having competing brands would be good. Now that there are competing vendors (Amazon Linux, Oracle Linux) trying to entice users it'd be better to strengthen RHEL brand rather than dilute it with multiple offerings. Unless RedHat/IBM plans to pull the plug on option [0].
[0]: https://developers.redhat.com/blog/2016/03/31/no-cost-rhel-d...
- CENTOS fills a need, that many users have and superficially it looks like Red Hat (IBM) is now abandoning addressing it. On the other hand Red Hat does offer RHEL for free (gratis) [0] and that should fill the needs of CENTOS users (right?). However it would have been much better if that option was mentioned in the announcement.
- I thought Fedora was upstream of RHEL. However after thinking more about it I realised that RHEL has a significant delta over Fedora. I 'm guessing CENTOS stream will be partway between Fedora and RHEL. It makes sense from Red Hats open development approach to have the delta between Fedora and RHEL happen in the open. Done right that should strengthen RHEL.
- Why the rush to drop support for CENTOS 8? I m sure some people are using it in production and they are unlikely to to want to move to this new CENTOS stream. It's a new OS distribution with a philosophy different to the one that was right for them!
Overall I 'd prefer if the new thing was called RHEL stream and provided for free (gratis) as CENTOS stream is. Also making more explicit the RHEL availability for free instead of having competing brands would be good. Now that there are competing vendors (Amazon Linux, Oracle Linux) trying to entice users it'd be better to strengthen RHEL brand rather than dilute it with multiple offerings. Unless RedHat/IBM plans to pull the plug on option [0].
[0]: https://developers.redhat.com/blog/2016/03/31/no-cost-rhel-d...
The free developer license seems pretty useless for larger organizations and OS licenses aren't managed by developers in general anyway.
>Yes, but only one no-cost Red Hat Developer Subscription can be added to a user account. While it is possible to have each developer register for their own account, this is not ideal from a management or efficiency standpoint. For example, if a company wanted no-cost Red Hat Developer Subscriptions to cover 100 developers, each developer would need to individually register and independently create 100 accounts that need to be tracked and maintained. For enterprises that use Red Hat Satellite to manage multiple systems, all 100 accounts would need to be added individually. Accepting the terms and conditions and renewing the subscription annually would need to be done individually and manually for all 100 accounts. Staff turnover in the development team would create additional management challenges with individual accounts. Therefore in terms of lost productivity, managing individual no-cost subscriptions will not be cost-effective for many groups.
Many development organizations benefit from having Red Hat Developer Support. Cost effective bundles are available that include support with a pack of 25 Developer Suite subscriptions that can be managed from a single account. Each of these subscriptions is based on systems, rather that users.
>Yes, but only one no-cost Red Hat Developer Subscription can be added to a user account. While it is possible to have each developer register for their own account, this is not ideal from a management or efficiency standpoint. For example, if a company wanted no-cost Red Hat Developer Subscriptions to cover 100 developers, each developer would need to individually register and independently create 100 accounts that need to be tracked and maintained. For enterprises that use Red Hat Satellite to manage multiple systems, all 100 accounts would need to be added individually. Accepting the terms and conditions and renewing the subscription annually would need to be done individually and manually for all 100 accounts. Staff turnover in the development team would create additional management challenges with individual accounts. Therefore in terms of lost productivity, managing individual no-cost subscriptions will not be cost-effective for many groups.
Many development organizations benefit from having Red Hat Developer Support. Cost effective bundles are available that include support with a pack of 25 Developer Suite subscriptions that can be managed from a single account. Each of these subscriptions is based on systems, rather that users.
Stay tuned.
Yea sure, that's the way to handle this kind of announcement. 'We're killing CentOS 8 and you need to wait several months to see the 'supposed' good things this move brings.'
Yea right.... All this '1H/1Q 2021' does is let IBM/RedHat determine how bad the fallout is before trying to cover their backsides.
Exactly. It boggles the mind the RH would make the announcement without having the new plans in place.
> On the other hand Red Hat does offer RHEL for free (gratis) [0] and that should fill the needs of CENTOS users (right?)
They offer a no-cost "developer subscription" of RHEL, but I'd wager the majority of users are running CentOS on servers.
They offer a no-cost "developer subscription" of RHEL, but I'd wager the majority of users are running CentOS on servers.
Is there a free non-developer, i.e. home version of RHEL without any subscription/registration?
http://yum.oracle.com/oracle-linux-isos.html
Disclaimer: not affiliated with Oracle in any way. This is just the closest thing to a plain RHEL8 clone I know of, other than CentOS8.
Disclaimer: not affiliated with Oracle in any way. This is just the closest thing to a plain RHEL8 clone I know of, other than CentOS8.
I work for Oracle on their cloud platform (including reasonably closely with the Oracle Linux team, as my team is responsible for the main platform images).
Speaking entirely for myself, opinions my own, may not reflect my employer etc. etc:
I came in to this job expecting OL to just be a CentOS clone, and not really expecting much from the kernel they ship with it.
It is both a CentOS clone, and a bunch more. Oracle takes the CentOS packages and applies bug fixes etc. that upstream RedHat has failed or refused to apply, so I've actually found OL to suffer from fewer problems than CentOS, and we've even had to apply mitigations for CentOS 6 for stuff we haven't had to do to any other OS we distribute. For entirely selfish reasons, I was really glad to see CentOS 6 go end of life last month.
On top of that the OL team hires a significant number of upstream kernel developers, including the core maintainers for a number of components, like XFS, Xen, and so on, and produces the Unbreakable Enterprise Kernel (a really curious choice of marketing terminology), that incorporates mainstream bug and security patches, while being closer to mainstream than RHEL/CentOS, and the kernel patches submitted upstream by OL devs.
Speaking entirely for myself, opinions my own, may not reflect my employer etc. etc:
I came in to this job expecting OL to just be a CentOS clone, and not really expecting much from the kernel they ship with it.
It is both a CentOS clone, and a bunch more. Oracle takes the CentOS packages and applies bug fixes etc. that upstream RedHat has failed or refused to apply, so I've actually found OL to suffer from fewer problems than CentOS, and we've even had to apply mitigations for CentOS 6 for stuff we haven't had to do to any other OS we distribute. For entirely selfish reasons, I was really glad to see CentOS 6 go end of life last month.
On top of that the OL team hires a significant number of upstream kernel developers, including the core maintainers for a number of components, like XFS, Xen, and so on, and produces the Unbreakable Enterprise Kernel (a really curious choice of marketing terminology), that incorporates mainstream bug and security patches, while being closer to mainstream than RHEL/CentOS, and the kernel patches submitted upstream by OL devs.
So is it a drop-in replacement for CentOS 8.x without any nonsense? I.e. same packages, compatibility with upstream, etc.
Should be. It's CentOS packages with rebranding and maybe some custom fixes on top. There are two kernels that ship with it, either the RedHat Compatibility Kernel (RHCK), or the Unbreakable Enterprise Kernel (UEK).
I would point out, I'm not in the OL org, I have absolutely no idea what this change means for Oracle Linux. Oracle Linux is based off the CentOS sources as that's the only way that RedHat was making the source code to their distribution available (there way of meeting the terms of the GPL). RedHat has to make their source code available in one form or another so I can't imagine that this would have any impact on OL, but that's entirely guess work.
I would point out, I'm not in the OL org, I have absolutely no idea what this change means for Oracle Linux. Oracle Linux is based off the CentOS sources as that's the only way that RedHat was making the source code to their distribution available (there way of meeting the terms of the GPL). RedHat has to make their source code available in one form or another so I can't imagine that this would have any impact on OL, but that's entirely guess work.
I didn't know Oracle builds from CentOS rather than RHEL sources. Nor that RHEL doesn't release sources anymore?
If that's true, I wonder how Oracle got some of their 8.x releases out much earlier than CentOS. (Oracle Linux 8.3 2020-11-13 vs CentOS 8.3 2020-12-08, Oracle Linux 8.0 2019-07-19 vs CentOS 8.0 2019-09-24.) I'm assuming here without verification that both track the RHEL 8 point releases.
If that's true, I wonder how Oracle got some of their 8.x releases out much earlier than CentOS. (Oracle Linux 8.3 2020-11-13 vs CentOS 8.3 2020-12-08, Oracle Linux 8.0 2019-07-19 vs CentOS 8.0 2019-09-24.) I'm assuming here without verification that both track the RHEL 8 point releases.
if i remember correctly, RHEL source dumps always lacked some machinery to actually produce a working release; that’s where CentOS were doing actual work, painstakingly replicating all the compilation quirks to end up with RPM builds that matched RHEL. That’s likely why another clone might want to start from CentOS rather than RHEL sources.
That doesn't answer my question how Oracle got some 8.x builds released weeks/months earlier than CentOS.
I can't speak to that. I'm not in the OL team and don't know what they do / did. Oracle can/does throw a lot more engineers at development and build than CentOS does (I believe they only have a few engineers). I believe the stuff for building the RPMs lands in the CentOS git repo early on.
It may take a hard sell for people looking for something more open than RHEL after this to use anything from Oracle.
Sounds like CentOS Stream will bring the pain to users and admins. Going forward, the answer to every stability question will be "maybe you should go buy Redhat".
I had a bad feeling about the CentOS project when Redhat became involved as more than an upstream RPM source. I hope CentOS isn't turned into another Fedora.
I'm sure many of you will be happy to tell me that I'm wrong. Please do.
I had a bad feeling about the CentOS project when Redhat became involved as more than an upstream RPM source. I hope CentOS isn't turned into another Fedora.
I'm sure many of you will be happy to tell me that I'm wrong. Please do.
IBM needs to grow revenue and they don't innovate. They didn't buy Redhat as a charity. So... you are right...
I'd like to, but I think this is correct. This is 100% IBM beginning to actually bed in their take-over of Red Hat.
I don't like those news. CentOS was my "go to" distribution which I used by default if RAM was enough (it has surprisingly high requirements to install). I know it well. I'm using RHEL on my home server with developer license, but that allows only for a single instance, and I have more hosts.
My ideal outcome would be if they would allow using real RHEL for any hobby projects and for commercial projects with income below some threshold, so I can start and grow with RHEL and then switch to paid option when I'd have enough income to warrant it.
But it's IBM, so probably I'll have to switch to Debian which is good enough, but I'd miss SELinux, better systemd integration and more polished packages.
My ideal outcome would be if they would allow using real RHEL for any hobby projects and for commercial projects with income below some threshold, so I can start and grow with RHEL and then switch to paid option when I'd have enough income to warrant it.
But it's IBM, so probably I'll have to switch to Debian which is good enough, but I'd miss SELinux, better systemd integration and more polished packages.
> If you are using CentOS Linux 8 in a production environment, and are concerned that CentOS Stream will not meet your needs, we encourage you to contact Red Hat about options.
Not exactly unexpected, but disappointing: if you want to continue using something like CentOS, pay for RHEL. Lots of web hosting providers will be quite concerned.
Not exactly unexpected, but disappointing: if you want to continue using something like CentOS, pay for RHEL. Lots of web hosting providers will be quite concerned.
Why exactly is that disappointing? Isn't it more disappointing that some companies expect to be able to run the same OS for 13 years and get security patches backported for free?
I don't think this will hurt RedHat at all. How many RHEL customers are actually generated as a result of providing CentOS for free? Not many I suspect.
Those who want to learn about RHEL can still get Fedora, or CentOS Stream, or a RedHat developer license.
I don't think this will hurt RedHat at all. How many RHEL customers are actually generated as a result of providing CentOS for free? Not many I suspect.
Those who want to learn about RHEL can still get Fedora, or CentOS Stream, or a RedHat developer license.
Because CentOS was once an independent project and Redhat promissed to keep Centos 8 alive till 2029.
Security patches are not backports, they are security patches that obviously should be for free, Redhat is making loads of money off free software already.
Security patches are not backports, they are security patches that obviously should be for free, Redhat is making loads of money off free software already.
Something like RHEL 6 is running on a 2.6 Linux kernel, all security patches has to be backported. That is an EOL kernel. Almost all versions of the software bundled with RHEL 6 have been EOL from upstream providers during it's ten year lifetime. Of cause you're free to try to attempt to applied any patches yourself, you don't have to pay.
If RedHat promised to keep CentOS 8 around for 9 more years, then yes, that is very disappointing. It was a stupid promise to make in the first place, but still disappointing.
If RedHat promised to keep CentOS 8 around for 9 more years, then yes, that is very disappointing. It was a stupid promise to make in the first place, but still disappointing.
I mean, yes? Backporting fixes and security patches is the entire point of RHEL/CentOS/OEL. And indeed it's upsetting precisely because CentOS was supposed to be supported into 2029 - https://web.archive.org/web/20201101131417/https://wiki.cent...
Agree, "customers" who use CentOS are not paying for Linux and won't pay for any other distro. Somebody has to work to provide a stable distro and supported on many hardwares, hypervisors/clouds and softwares running on top of OS. But the funny things is that usually there is a huge contradiction on people who uses CentOS on production, they are the same people who pays for proprietary software like Windows, Office, Oracle DB, VMware, etc... sometimes spend millions of dollars on these softwares, but save some bucks using a free Linux distro!! But I do respect the ones who are entirely open source, just don't think any big company besides Google for example, would have a huge IT teams to support everything
I disagree I think RHEL and CentOS go/went hand in hand. With RHEL being used and licensed depending on the project or the environment. Binary compatibility and the uniformity of managing both being the big selling point.
Now the closest alternative is Canonical with Ubuntu Server which can be installed wherever with no strings and support purchased as required.
Now the closest alternative is Canonical with Ubuntu Server which can be installed wherever with no strings and support purchased as required.
Yeah but how long before Canonical pull the same move as RedHat? The way i see it, Canonical is trying to build a moat (lastly with Snap).
I think I'm going back to Debian for my servers. i wish they add 10 years lts though.
I think I'm going back to Debian for my servers. i wish they add 10 years lts though.
>i wish they add 10 years lts though
I really don't get this fascination with 10 year LTS. Why is it so hard to upgrade in half a decade ? I mean this is such an arbitrary number. If RHEL started offering 50 year support, people will complain that Debian is 1/10th of RHEL.
I really don't get this fascination with 10 year LTS. Why is it so hard to upgrade in half a decade ? I mean this is such an arbitrary number. If RHEL started offering 50 year support, people will complain that Debian is 1/10th of RHEL.
I'd take 50 years in a heartbeat. I'm barely Linux literate and I have many many more pressing things to do than upgrade servers.
If you want to know more I wrote about it in another comment: https://news.ycombinator.com/item?id=25348914
If you want to know more I wrote about it in another comment: https://news.ycombinator.com/item?id=25348914
> I really don't get this fascination with 10 year LTS. Why is it so hard to upgrade in half a decade ?
The ideal situation is never having to upgrade: you buy your computer, install the operating system, and it works the same until you retire it. If your computer has a 5 year warranty, you expect to use it for at least 5 years before retiring it.
A 5 year LTS is only 5 years if you install the moment it's released, but that's not usually the case; for instance, there's a new Ubuntu LTS release every 2 years, so in the worst case your LTS installation will last only 3 years. Now consider the "10 year" RHEL LTS: in the worst case (you installed RHEL 7 just before RHEL 8 was released), your LTS installation will last 5 years, perfectly matching the warranty period.
The ideal situation is never having to upgrade: you buy your computer, install the operating system, and it works the same until you retire it. If your computer has a 5 year warranty, you expect to use it for at least 5 years before retiring it.
A 5 year LTS is only 5 years if you install the moment it's released, but that's not usually the case; for instance, there's a new Ubuntu LTS release every 2 years, so in the worst case your LTS installation will last only 3 years. Now consider the "10 year" RHEL LTS: in the worst case (you installed RHEL 7 just before RHEL 8 was released), your LTS installation will last 5 years, perfectly matching the warranty period.
Imagine you're a web hosting provider who builds their business around automation tools and control panels and whatnot tailored for CentOS 8. You really don't want to have to rewrite it all every couple of years because that's not where your business's value comes from. Also, updating will break a huge number of your customers' sites and apps, which will piss them off and bury your already slender profit margins in support costs.
Most of those hosting customers are not tech companies building fractionally "innovative" CRUD SaaS apps. They're SMEs who use their apps and databases to do real work: organizing their employees, procurement, running payroll, managing delivery routes, order and stock management — boring stuff like that. They very much do not want to have to significantly rewrite the back-office systems their businesses rely on because the OS changed under them. They want it to keep working for decades with as little redevelopment as possible.
Most of those hosting customers are not tech companies building fractionally "innovative" CRUD SaaS apps. They're SMEs who use their apps and databases to do real work: organizing their employees, procurement, running payroll, managing delivery routes, order and stock management — boring stuff like that. They very much do not want to have to significantly rewrite the back-office systems their businesses rely on because the OS changed under them. They want it to keep working for decades with as little redevelopment as possible.
It will hurt indirectly, because a lot of developers/devops/sys admins get skills working on CentOS which are then portable to RHEL. Now they won't. Network effects of being popular are significant.
It's a network effect. If you are always around EL machines, you're going to know, want to work with, and recommend EL machines.
From Red Hat's release:
```There are different kinds of CentOS users, and we are working with the CentOS Project Governing Board to tailor programs that meet the needs of these different user groups. In the first half of 2021, we plan to introduce low- or no-cost programs for a variety of use cases, including options for open source projects and communities and expansion of the Red Hat Enterprise Linux Developer subscription use cases to better serve the needs of systems administrators. We’ll share more details as these initiatives coalesce.```
Probably should have had their ducks in a row there to announce both things at once, I think.
```There are different kinds of CentOS users, and we are working with the CentOS Project Governing Board to tailor programs that meet the needs of these different user groups. In the first half of 2021, we plan to introduce low- or no-cost programs for a variety of use cases, including options for open source projects and communities and expansion of the Red Hat Enterprise Linux Developer subscription use cases to better serve the needs of systems administrators. We’ll share more details as these initiatives coalesce.```
Probably should have had their ducks in a row there to announce both things at once, I think.
But then you would have nothing to announce when saying “we listened to the community and blablabla”.
This way they can keep up the illusion that they do everything with good intentions and did not expect people would get angry. “We are not the baddies, here’s some sweetener to prove it!”
This way they can keep up the illusion that they do everything with good intentions and did not expect people would get angry. “We are not the baddies, here’s some sweetener to prove it!”
Q5: Does this mean that CentOS Stream is the RHEL BETA test platform now?
A: No. CentOS Stream will be getting fixes and features ahead of RHEL. Generally speaking, we expect CentOS Stream to have fewer bugs and more runtime features than RHEL until those packages make it into the RHEL release.
Q: is the sky blue? A: no. it's blue.
Q: is the sky blue? A: no. it's blue.
> CentOS Stream to have fewer bugs and more runtime features than RHEL
more bugs, surely....
more bugs, surely....
I used to work for a hosting firm who had large numbers of customers making use of CentOS for their pre-production environments, running RHEL for their production.
This announcement is a kick in the teeth to those customers, as the transition to RHEL 8 for these pre-production environments will feel very much like a shakedown.
I feel this is tremendously damaging for Red Hat's reputation and the goodwill developers had towards them.
This announcement is a kick in the teeth to those customers, as the transition to RHEL 8 for these pre-production environments will feel very much like a shakedown.
I feel this is tremendously damaging for Red Hat's reputation and the goodwill developers had towards them.
Is this change really so dramatic for pre-prod use? It sounds like centos will still be around although as the upstream of RHEL, which I interpret to mean less tested or stable. But as far as compatibility between it and RHEL, shouldn't that improve? Why isn't this good enough?
Red Hat has developer licenses. It might not end up being a shakedown, depending.
The writing's been on this wall since at least 2014, when RedHat took over CentOS. Having a free gateway to your paid product is fine, but at some point you need to give potential customers a nudge they can't refuse.
Pre-2014 it was fairly obvious that a full clone of a commercially supported product, with the proverbial 'just a search-and-replace of the product name', was going to attract interest & action from upstream.
OTOH in the ~25 years I've been using Debian, I've never been (rudely) surprised by one of their announcements. Their social contract [0] is clear on every point that's relevant to users of an OS, especially users looking to commit long term to a platform.
[0] https://www.debian.org/social_contract
Pre-2014 it was fairly obvious that a full clone of a commercially supported product, with the proverbial 'just a search-and-replace of the product name', was going to attract interest & action from upstream.
OTOH in the ~25 years I've been using Debian, I've never been (rudely) surprised by one of their announcements. Their social contract [0] is clear on every point that's relevant to users of an OS, especially users looking to commit long term to a platform.
[0] https://www.debian.org/social_contract
I wouldn't be surprised if this means that another project will crop up soon-ish which does what CentOS did before, rebuild RHEL so there is a stable, boring distribution for people who want RHEL without wanting or being able to pay RH.
There's already Oracle Linux. (Not and endorsement, not affiliated, just surprised that there seems very little awareness about it.)
I think people who want a non-commercial RHEL will stay well away from any project with "Oracle" in the name.
Even some who don't mind commercial will. Oracle has a well-earned reputation of being difficult in licensing negotiations (there was even a Gartner piece on it at some point)... And what they did with the JDK just underscored that.
Maybe Scientific Linux can get revived.
Wasn't CentOS "adopted" by RedHat because no one else really wanted to do the work?
A revived Scientific Linux could easy suffer the same fate. No one truly want to maintain a RedHat clone for little to no pay, while at the same time dealing request and complaints from companies who wants the benefits of RHEL, but no pay for the development and maintenance works done by RedHat.
Realistically it's some bean counter at IBM who asked why RedHat is giving away the very same thing they're trying to sell. Said bean counter do have a point in my opinion.
A revived Scientific Linux could easy suffer the same fate. No one truly want to maintain a RedHat clone for little to no pay, while at the same time dealing request and complaints from companies who wants the benefits of RHEL, but no pay for the development and maintenance works done by RedHat.
Realistically it's some bean counter at IBM who asked why RedHat is giving away the very same thing they're trying to sell. Said bean counter do have a point in my opinion.
> why RedHat is giving away the very same thing they're trying to sell
Goodwill. I use CentOS and until now if I had a project were Linux support had been important I would have gone with Redhat. They can rot in hell now.
Goodwill. I use CentOS and until now if I had a project were Linux support had been important I would have gone with Redhat. They can rot in hell now.
CERN pays?
I wonder what Cern Linux [1] are going to do. They're basically CentOS' CentOS.
[1] https://linux.web.cern.ch/
[1] https://linux.web.cern.ch/
Oh, wow. My whole extended family has CentOS on their machines for years because of LTS. Not sure what I'm going to replace it with now and how. Perhaps there's going to be Fedora LTS at some point soon. I sure hope Fedora is not the next casualty.
IBM strikes again.
IBM strikes again.
I'm a little confused by this. Well, first, I'd encourage you to try Fedora Workstation for your family -- we've worked on making upgrades painless, so that they're basically an automated thing that happens while you go for coffee once or twice a year (at your option). But second, if a "Fedora LTS" would fit your needs, why not give CentOS Stream a look? It's not actually going to be that different from CentOS Linux, and almost certainly will have less constant change than a theoretical Fedora LTS would.
Also, I am not one of the highest upptity-ups in the company or anything, but from the inside: I see no evidence whatsoever that this is the result of IBM anything.
Also, I am not one of the highest upptity-ups in the company or anything, but from the inside: I see no evidence whatsoever that this is the result of IBM anything.
Thank you for the reply. While I personally never had a single issue with upgrading between Fedora releases, I also have the skills the resolve any potential ones if I would. I don't want to deal with somebody's computer suddenly being borked halfway across the world with no way to assist. So far CentOS fit that niche beautifully, with seldom major clean reinstalls (i.e. wipe root) when I'm there (7.x > 8.x). I'm going to evaluate CentOS Stream and perhaps you are right and it's a viable replacement.
(Disclaimer: I am capable of fixing upgrade issues myself.) I've not done a wipe-root reinstall of Fedora since 2013. I've in place upgraded every two versions or so - basically as soon as the version I'm using goes EOL.
I don't want to deal with somebody's computer suddenly being borked halfway across the world with no way to assist.
Fedora Silverblue could be interesting alternative to regular Fedora then, since you can boot into or roll back to a previous release. You can also pin a known-good OSTree commit, so that one could always boot that version.
Fedora Silverblue could be interesting alternative to regular Fedora then, since you can boot into or roll back to a previous release. You can also pin a known-good OSTree commit, so that one could always boot that version.
This. Although I 'd suggest running Silverblue in a VM first to learn about package layering and flatpaks. (This was my migration path. Made sure all my use cases were working within the VM before I installed on bare metal.)
> we've worked on making upgrades painless, so that they're basically an automated thing that happens while you go for coffee once or twice a year (at your option)
In my experience (just went through that, F32 -> F33), it's painless but definitely not "an automated thing that happens while you go for coffee"; each machine took a whole day, it's a huge download (many gigabytes) and the install itself seems to be severely fsync-limited (several hours while the progress bar slowly fills and the disk light is lit all the time; after the fact, "journalctl -b -1" shows it was installing/cleaning package by package all that time).
In my experience (just went through that, F32 -> F33), it's painless but definitely not "an automated thing that happens while you go for coffee"; each machine took a whole day, it's a huge download (many gigabytes) and the install itself seems to be severely fsync-limited (several hours while the progress bar slowly fills and the disk light is lit all the time; after the fact, "journalctl -b -1" shows it was installing/cleaning package by package all that time).
Fedora Silverblue can be an option then - the roots is an immutable snapshots tracked by OSTree It can build an updated OSTree snapshot in the background & only the difference from what you have are downloaded. Then you reboot into that new snapshot, while still having the old one (and ony other you care to keep) available, in case something is not right with the new one.
That should address most of the issues you mention. :)
That should address most of the issues you mention. :)
Silverblue, in my experience, is not really there. I like the idea. As of my latest try at it in August, I wouldn't recommend anybody recommend it unless they're going to be physically standing in front of the machine on a regular basis.
Yeah, it's true that the people I know that use it do so on workstations. Still IMHO the technology (OSTree) is solid & perfect match for various server & mobile use cases. Once mature enough of course. :)
Redhat just reneged on its commitments regarding CentOS 8. When has this happened before?
Your whole family runs CentOS as their desktop operating system?
Extended yes. And has been for years without a single issue. Immediate family all on Fedora. Very little maintenance, automated updates. Desktop software installed through flatpaks. Easy remote management. Users don't care about the OS as long as they know how to open the browser, email, word processor, Skype, Zoom, etc.
Fair enough, was just confirming. It didn't occur to me that flatpaks would probably assist in bridging the gap between a "Workstation" OS and a conventional end-user OS where yum repos and EPEL might be lacking.
> Easy remote management.
Just out of curiousity, are you SSHing in directly, or installing the Teamviewer RPM on all of them?
> Easy remote management.
Just out of curiousity, are you SSHing in directly, or installing the Teamviewer RPM on all of them?
Each house has an single always-on VPN client (RPi) to the central server so I ssh in case something is up. Pretty much never happens, but it's good to know the option is there. Most issues are with a specific software and not the OS, so I need to have a visual to help resolve, e.g. "Where is my contact list in Viber?" or "Why do I see this page?".
Plus, I'm running Pi-Hole in docker and I ssh to upgrade it from time to time, (docker pull, docker-compose down/up, etc.). I haven't bothered automating this because some things change between releases and I still end up doing manual configuration changes.
Plus, I'm running Pi-Hole in docker and I ssh to upgrade it from time to time, (docker pull, docker-compose down/up, etc.). I haven't bothered automating this because some things change between releases and I still end up doing manual configuration changes.
Having been a Debian/Ubuntu person for a long time, and being somewhat dissatisfied with that ecosystem, I recently started evaluating CentOS for my use cases instead. I want something with a non-rolling update model, so I don't have to deal with my environment changing out from under me.
CentOS 8 had been mostly working well for me, barring a few missing packages that were easy to port over myself, and I was really thinking of moving all my boxes to CentOS. I'm glad this news came out before I did; I don't know what I'll use instead, but it definitely won't be CentOS/RHEL.
CentOS 8 had been mostly working well for me, barring a few missing packages that were easy to port over myself, and I was really thinking of moving all my boxes to CentOS. I'm glad this news came out before I did; I don't know what I'll use instead, but it definitely won't be CentOS/RHEL.
I think there might be some confusion about "rolling" in the context of CentOS Stream. The updates are continuous and there's not released minor versions, but all changes are changes that are intended to _very shortly_ land in the next every-six-months minor release of RHEL. So you aren't going to suddenly see more "environment changing out from under me" than you would on RHEL or CentOS Linux.
Minor version updates in CentOS usually mean a new kernel ABI and things like ZFS break. I always have to wait to do minor version updates until a new ZFS version lands. Any idea how that’ll work?
Yeah, to me this whole thing sounds like a failure of communication.
Most people (including me) never looked closely at "CentOS Streams"; from what you said, it seems like it's "a preview of the next RHEL 8.x". The announcement today made it appear as if it were "a preview of RHEL 9.0", which is a much bigger change for those who (like me) expect to install a CentOS 8 box somewhere and keep it mostly untouched (just applying the updates) for ten years.
Most people (including me) never looked closely at "CentOS Streams"; from what you said, it seems like it's "a preview of the next RHEL 8.x". The announcement today made it appear as if it were "a preview of RHEL 9.0", which is a much bigger change for those who (like me) expect to install a CentOS 8 box somewhere and keep it mostly untouched (just applying the updates) for ten years.
OpenSuse, and Suse give you more control over minor release version changes. You have to manually change your repos with some scripts before you patch. The RH way of just rolling you from minor release to minor release invisibly has always kind of irritated me.
Thank you for the answers in this thread.
I haven't tried CentOS Stream, but out of curiosity: if it's similar to the RHEL patch releases, how will major (like from RHEL 8 to 9) changes be handled?
I haven't tried CentOS Stream, but out of curiosity: if it's similar to the RHEL patch releases, how will major (like from RHEL 8 to 9) changes be handled?
Checkout openSUSE; I've been running it for the past year or so for my personal projects (and their rolling-release version for longer) and I've been pretty happy with it. It's not quite the same position as CentOS but still very stable and nice to work with.
I don't know what your use case is, but one of the flavors of BSD might be an option for you.
I am a big fan of OpenBSD, but unfortunately I still need some Linux only software. I do try out freeBSD’s Linux emulation layer every couple years, but it isn’t quite there yet for the stuff I need to run.
OpenSuse Leap, with XFS or BTRF sounds right for you.
> If you are using CentOS Linux 8 in a production environment, and are
concerned that CentOS Stream will not meet your needs, we encourage you
to contact Red Hat about options.
I'm guessing the MBAs at IBM believe that they can covert a chunk of CentOS enterprise users into paying IBM customers. Ooof! CentOS had a good run.
> CentOS Linux 8, as a rebuild of RHEL 8, will end at the end of 2021
Does this mean that CentOS 8 is EOL come 2021? Weren't maintenance updates meant to go to 2029? What about everybody who built their product on the assumption that there would be a stable CentOS until then?
Does this mean that CentOS 8 is EOL come 2021? Weren't maintenance updates meant to go to 2029? What about everybody who built their product on the assumption that there would be a stable CentOS until then?
> What about everybody who built their product on the assumption that there would be a stable CentOS until then?
1. They can start paying RedHat
2. They can hire/delegate someone to maintain patches for them
3. They can migrate to something else ;)
1. They can start paying RedHat
2. They can hire/delegate someone to maintain patches for them
3. They can migrate to something else ;)
Oracle already has a clone that performs an in-place conversion of an installed CentOS 7 system.
There is a page describing the conversion: https://linux.oracle.com/switch/centos/
They have a shell script to convert a CentOS install to Oracle Linux, so you can buy support if you want.
The converter only works with versions 5, 6, and 7.
It does not work with CentOS 8. It would be nice if that could get updated.
They have a shell script to convert a CentOS install to Oracle Linux, so you can buy support if you want.
The converter only works with versions 5, 6, and 7.
It does not work with CentOS 8. It would be nice if that could get updated.
My god. If it gets to the point that your best option is to migrate to Oracle, I think you need to really question reality itself.
(My opinions are my own, and do not necessarily reflect those of my employer; I'm in support at the moment, so foresee myself having to deal with the aftermath of this CentOS decision a year from now)
(My opinions are my own, and do not necessarily reflect those of my employer; I'm in support at the moment, so foresee myself having to deal with the aftermath of this CentOS decision a year from now)
There is no reason for them to have taken the CentOS name for this role. There is no defense of this, other than to purloin resources or to make it harder to run RHEL-like distros.
Not really the first time Red Hat leaves users high and dry - also happened when they made Red Hat non-free with Fedora (then very unstable) as an alternative. I moved to Debian, never looked back, and today I regret it less than ever :)
Time to EOL all our CentOS platforms and migrate them to Debian.
Every time a corporation takes over an open source project it absolutely ruins it. We need some kind of "enterprise open source cabal" of people who can work on open source projects without any IP or copyright going to the company so the companies can't unilaterally screw the project.
Every time a corporation takes over an open source project it absolutely ruins it. We need some kind of "enterprise open source cabal" of people who can work on open source projects without any IP or copyright going to the company so the companies can't unilaterally screw the project.
Hahahaha. That's a lesson learnt from me. Giving the benefit of the doubt to IBM? What a naive fool I was. I'm glad my personal server is running Debian at least, even if I chose it for other reasons.
At risk of angering the beehive, I will pre-emptively remove my benefit of the doubt to Microsoft as well before I become too dependent on VS Code and its proprietary extensions. I had been ignoring that red flag and with these news my gut instinct has turned to a fight or flight response.
At risk of angering the beehive, I will pre-emptively remove my benefit of the doubt to Microsoft as well before I become too dependent on VS Code and its proprietary extensions. I had been ignoring that red flag and with these news my gut instinct has turned to a fight or flight response.
The value of CentOS is that it's provides a free and stable RedHat build.
Nobody needs or wants another Fedora.
This seems like a round-a-bout way of killing the only RedHat alternative to the expensive commercial version of RedHat.
If there is no Centos9, I'll probably move over to a Debian alternative. Just because of the principle of the thing. Better that than validate the "acquire and destroy" strategy that seems to be used by every big tech company like IBM, Microsoft, Facebook and Google.
Nobody needs or wants another Fedora.
This seems like a round-a-bout way of killing the only RedHat alternative to the expensive commercial version of RedHat.
If there is no Centos9, I'll probably move over to a Debian alternative. Just because of the principle of the thing. Better that than validate the "acquire and destroy" strategy that seems to be used by every big tech company like IBM, Microsoft, Facebook and Google.
Very disappointing, since I based my OS decision on their support cycle, which has now been thrown out the window. Guess that I will be going back to Debian again
And to top it off, today was the day when a CentOS 8 kernel update broke ZFS. Again.
And to top it off, today was the day when a CentOS 8 kernel update broke ZFS. Again.
> today was the day when a CentOS 8 kernel update broke ZFS
This issue? https://github.com/openzfs/zfs/issues/11307
This issue? https://github.com/openzfs/zfs/issues/11307
Yes, I believe that's the one, and this isn't the first time a CentOS specific issue has been discovered.
For comparison, I have a Debian 10 box running since February. Also runs ZFS, updates and restarts every day, and absolutely 0 issues with that setup.
For comparison, I have a Debian 10 box running since February. Also runs ZFS, updates and restarts every day, and absolutely 0 issues with that setup.
The real message is that if you want stability now, you have to pay for it with RHEL.
I was out of the loop when IBM acquired RHEL. IBM strikes again.
I've been experimenting with openSUSE lately. So far so good. Only if zypper can download packages in parallel, I don't have to wait for eons to build images.
I've been experimenting with openSUSE lately. So far so good. Only if zypper can download packages in parallel, I don't have to wait for eons to build images.
Curious why people on here seem so abrasive to this so far. Have had a few work loads on Stream, and updates are just as "boring" as expected from CentOS.
I seam to have more issue at work dealing with older versions of packages on CentOS that lag behind up to date packages on "unstable" distros.
As a fan of rolling release (btw I use arch), I will love not having to deal with EOL CentOS upgrades at work.
I seam to have more issue at work dealing with older versions of packages on CentOS that lag behind up to date packages on "unstable" distros.
As a fan of rolling release (btw I use arch), I will love not having to deal with EOL CentOS upgrades at work.
TL;DR: CentOS Linux 8.x will end in 2021, CentOS Stream 8 will be RHEL 8.x plus whatever updates are in the pipeline for it. CentOS 7.x will remain as today until RHEL 7.x reaches EOL.
I'm very pessimistic on what this means for the RHEL ecosystem as a whole...
If I understand correctly, CentOS Stream 8 should be relatively stable just after a RHEL 8.x release, because the pipeline will contain just minor updates. But as the next "x+1" release approaches, the pipeline will contain whatever is being tested for inclusion in it. This makes CentOS Stream unsuitable for the vast majority of people that currently use CentOS in production (i.e. the people that choose CentOS over something else like Debian Stable or Ubuntu LTS).
One can argue that these people can go buy RHEL licenses, but they most likely don't do that already because they see support as the value added by RHEL-proper and they can support themselves just fine. Many will also have RHEL instances along CentOS on systems that need vendor support, but pushing them to license everything may also push them into another direction altogether. Suddenly, standardizing on Ubuntu LTS (with paid support for a subset of instances) starts to make sense.
I think Red Hat (or maybe IBM) is vastly underestimating the value of CentOS in keeping the whole RHEL ecosystem competitive. They may be setting themselves up to be another SUSE.
I'm very pessimistic on what this means for the RHEL ecosystem as a whole...
If I understand correctly, CentOS Stream 8 should be relatively stable just after a RHEL 8.x release, because the pipeline will contain just minor updates. But as the next "x+1" release approaches, the pipeline will contain whatever is being tested for inclusion in it. This makes CentOS Stream unsuitable for the vast majority of people that currently use CentOS in production (i.e. the people that choose CentOS over something else like Debian Stable or Ubuntu LTS).
One can argue that these people can go buy RHEL licenses, but they most likely don't do that already because they see support as the value added by RHEL-proper and they can support themselves just fine. Many will also have RHEL instances along CentOS on systems that need vendor support, but pushing them to license everything may also push them into another direction altogether. Suddenly, standardizing on Ubuntu LTS (with paid support for a subset of instances) starts to make sense.
I think Red Hat (or maybe IBM) is vastly underestimating the value of CentOS in keeping the whole RHEL ecosystem competitive. They may be setting themselves up to be another SUSE.
Yea. I think this is an extremely short-sighted move. Many RHEL customers utilize CentOS. I know CentOS is a community but it is led by Red Hat developers. Suddenly pulling 8 years of support from their community project is not going to be looked at favorably by any IT team.
I share your pessimism about RHEL. I think Canonical could be a big beneficiary, if they can stop shooting themselves in the foot with stuff like upsells for live kernel patches, and snaps for non-desktop apps.
They've basically ceded the entire ecosystem to Canonical with this move and haven't realized it yet.
And we're all worse off for it.
And we're all worse off for it.
What about Debian? SUSE?
If all of your vendors are targeting Debian and/or SUSE for their software, consider yourself blessed.
This is quite logical and expected from RH's standpoint. The aberration was them acquiring CentOS in the first place. In the long run, I expect everyone to migrate to Ubuntu or Debain slowly. This has been happening anyway. I don't think people will trust a new CentOS-like project easily should one pop up.
Thanks, for all the fish, CentOS. The city of Tuttle, Oklahoma is grateful.
Thanks, for all the fish, CentOS. The city of Tuttle, Oklahoma is grateful.
> Thanks, for all the fish, CentOS. The city of Tuttle, Oklahoma is grateful.
Oh man, I had completely forgotten about that (although I suspect most people have by now)... since reading your comment, though, I have been sitting here giggling like a little kid just thinking about it. Thank you!
--
For anyone who reads this and doesn't understand the reference to Tuttle, Oklahoma, well, go seek out the answer and prepare to be entertained, my friend!
--
UPDATE: Actually, I'll save you some trouble, since I decided to go re-read all the details again myself:
Start here, with a story from The Register that summarizes what happened: https://www.theregister.com/2006/03/24/tuttle_centos/
Afterwards, you'll almost certainly want to read the entire e-mail thread yourself. Fortunately, the Internet Archive has us covered: https://web.archive.org/web/20060326091856/https://www.cento...
Finally, thank bubblethink (with an extra Internet point, of course) for reminding us all of this incident!
Oh man, I had completely forgotten about that (although I suspect most people have by now)... since reading your comment, though, I have been sitting here giggling like a little kid just thinking about it. Thank you!
--
For anyone who reads this and doesn't understand the reference to Tuttle, Oklahoma, well, go seek out the answer and prepare to be entertained, my friend!
--
UPDATE: Actually, I'll save you some trouble, since I decided to go re-read all the details again myself:
Start here, with a story from The Register that summarizes what happened: https://www.theregister.com/2006/03/24/tuttle_centos/
Afterwards, you'll almost certainly want to read the entire e-mail thread yourself. Fortunately, the Internet Archive has us covered: https://web.archive.org/web/20060326091856/https://www.cento...
Finally, thank bubblethink (with an extra Internet point, of course) for reminding us all of this incident!
I don't think this has anything to do with the IBM acquisition of Red Hat, but this is something that's driven by Red Hat's management itself. They did a similar thing with JBoss application server (the community edition) which was extremely popular and used within the community and even in production. Red Hat offered (and still offers) an enteprise version of it (JBoss EAP). Few years back they slowly started diminishing the prominence of the community version. They first renamed it (to WildFly) since the "JBoss" name confuses users with their enterprise edition offering. Then they started adding confusion around usage of the community edition of the server (now named WildFly) and started sending out messages (which never were clarified) that WildFly "cannot" be used in production environments (no explanation of what production environment was). Answers to these questions typically directed users to JBoss EAP (the enterprise edition) where they could enroll in developer programs and use the JBoss EAP for free for development use and then pay for the same when they use that or deploy that in production. This effectively killed the entire JBoss (now WildFly) community (external contributions, user discussions and any such interactions). WildFly these days is just there as a community project for the sake of it. There's no real external involvement in it and it's mostly driven by Red Hat employees and only rarely see any discussion happening in the open in their mailing lists anymore (can't blame them when no one external to their own employed team participates anymore).
The thing though is, developers actually involved in this project had strong opposition to the way this was handled, but none of it was heard and the "decision was already done" by people who hardly had any role to play on the day to day community involvement with the project. I am pretty sure it was the same with this CentOS decision.
The thing though is, developers actually involved in this project had strong opposition to the way this was handled, but none of it was heard and the "decision was already done" by people who hardly had any role to play on the day to day community involvement with the project. I am pretty sure it was the same with this CentOS decision.
There was even a restriction on the community edition to not release bug fix releases (just one was allowed). So if X.0.0 was released then X.0.1, X.0.2 and so on were not allowed. Without these bug fix releases the community versions started seeing X.1.0, X.2.0 and so on which included additional enhancements/features and weren't merely bug fix releases. As a result, the stability that the community edition of the server was known to provide (previously), no longer existed.
This all boiled down to one thing - the sales team couldn't convince customers that paying hundreds of thousands of dollars for the enterprise edition was a good thing when the community edition was equally good and well maintained, even if by volunteer community members.
It does not matter if nightlies are more stable than they used to be. It does not matter if nightlies never crash.
If you work in an industry or corporation that is highly security conscious, i.e. that prizes risk mitigation over using the cutting edge or getting to market first above all else, then you won't be able to use nightlies.
Security policy will dictate that you use use a stable versioned release, that the release be vetted through scripts/STIGs, and that the release be installed by Security+ certified and blessed admins.
I just successfully pitched we go with Centos 8 at work. Tomorrow I have to go in and explain why we need to choose Centos 7, or Ubuntu. In my industry this kills Centos, it's as dead as Mr. Praline's Norwegian Blue [1]. I suspect that was IBM's intent all along, though it's only suspicion.
[1] https://en.wikipedia.org/wiki/Dead_Parrot_sketch
If you work in an industry or corporation that is highly security conscious, i.e. that prizes risk mitigation over using the cutting edge or getting to market first above all else, then you won't be able to use nightlies.
Security policy will dictate that you use use a stable versioned release, that the release be vetted through scripts/STIGs, and that the release be installed by Security+ certified and blessed admins.
I just successfully pitched we go with Centos 8 at work. Tomorrow I have to go in and explain why we need to choose Centos 7, or Ubuntu. In my industry this kills Centos, it's as dead as Mr. Praline's Norwegian Blue [1]. I suspect that was IBM's intent all along, though it's only suspicion.
[1] https://en.wikipedia.org/wiki/Dead_Parrot_sketch
> If you work in an industry or corporation that is highly security conscious, i.e. that prizes risk mitigation over using the cutting edge or getting to market first above all else, then you won't be able to use nightlies.
> Security policy will dictate that you use use a stable versioned release, that the release be vetted through scripts/STIGs, and that the release be installed by Security+ certified and blessed admins.
I'd be quite surprised if your "security policy" has all of that and yet doesn't have a requirement for "commercial support" (i.e., Red Hat Enterprise Linux).
Besides, if $employer "is highly security conscious", your machines are almost certainly airgapped and getting their updates from a Satellite server that you're already paying Red Hat for.
AFAIK, CentOS is not now -- nor has it ever been -- "certified" for anything. Did that change at some point without me noticing?
> Security policy will dictate that you use use a stable versioned release, that the release be vetted through scripts/STIGs, and that the release be installed by Security+ certified and blessed admins.
I'd be quite surprised if your "security policy" has all of that and yet doesn't have a requirement for "commercial support" (i.e., Red Hat Enterprise Linux).
Besides, if $employer "is highly security conscious", your machines are almost certainly airgapped and getting their updates from a Satellite server that you're already paying Red Hat for.
AFAIK, CentOS is not now -- nor has it ever been -- "certified" for anything. Did that change at some point without me noticing?
It is (or was) definitely possible to be security conscious and use an Open Source OS:
* You can use reposync to update a copy of EPEL, PowerTools, etc.
* You can use yum -q deplist PACKAGENAME to list dependencies
* You can copy the necessary RPMs to a DMZ and apply security scans/tests, then take them to your boxes and install them
Also, any corporation or organization like I'm talking about has internal approval/certification of software as usable on their networks. The Army formalized this as the CoN, Certificate of Networthiness.
* You can use reposync to update a copy of EPEL, PowerTools, etc.
* You can use yum -q deplist PACKAGENAME to list dependencies
* You can copy the necessary RPMs to a DMZ and apply security scans/tests, then take them to your boxes and install them
Also, any corporation or organization like I'm talking about has internal approval/certification of software as usable on their networks. The Army formalized this as the CoN, Certificate of Networthiness.
Pretty sure it did. CentOS is used by the government for classified areas. Though it might be phased out now after this change.
So Centos 8 will be a beta test stream for features and fixes, but for CVEs it will lag behind RH. That's an interesting twist.
Isn't that how things already work wrt security updates on RHEL/CentOS? CentOS AFAIK doesn't get any advance warning, only once RHEL pushes out a security update they rebuild and release.
Of course, with this it might be even slower, in that first RHEL pushes out the security update, and then people will start looking whether that change needs to be forward-ported to CentOS stream, or whether it can be used as-is etc.
Of course, with this it might be even slower, in that first RHEL pushes out the security update, and then people will start looking whether that change needs to be forward-ported to CentOS stream, or whether it can be used as-is etc.
Seems a push for companies to move to RedHat licenses.
It does make sense from RH's perspective that when Fedora is a testing environment for the next major version and RH wants to use CentOS for minor version test environment, so that they can release a new RHEL minor version more confidently to paying customers.
I assume CentOS Stream will be based on the previous RHEL minor version release which would be stable and puts improvements for the next minor version release before RHEL releases it which doesn't sound like the end of the world like some people seem to think.
You actually get improvements earlier than later and you also get to throw feedbacks in before the next minor version gets released which feels more community oriented.
Unless your server needs absolute stability like RHEL (in which case you might as well just pay for RHEL), then it seems ok to use Stream.
For those that need absolute stability but have no decent flow of income, then you might be burned but I suppose a new community supported RHEL clone would come out sooner or later.
I assume CentOS Stream will be based on the previous RHEL minor version release which would be stable and puts improvements for the next minor version release before RHEL releases it which doesn't sound like the end of the world like some people seem to think.
You actually get improvements earlier than later and you also get to throw feedbacks in before the next minor version gets released which feels more community oriented.
Unless your server needs absolute stability like RHEL (in which case you might as well just pay for RHEL), then it seems ok to use Stream.
For those that need absolute stability but have no decent flow of income, then you might be burned but I suppose a new community supported RHEL clone would come out sooner or later.
Wow, saw it coming at the IBM aquisition but this caught me off guard. I've run them all in production, so getting to brass tacks I say this will push people into either SLE or Ubuntu's arms for the fact that these are the two main alternatives that offer both a support model and have high deployment numbers and great teams behind them. I prefer SLE but to each their own. The fact that I have advocated for rolling release as the distro model of the future doesnt negate the many cases where tracking with RHEL for stability is required.
That said, I think a lot of issues I've seen would be helped by people not being so afraid of rolling release , so maybe reconsider the fundamentals before being too chicken little. Also, I suspect this could be the kick we all need to start pushing nix and guix more seriously.
I like stream. A handful of my side projects are running it now, but IBM done fucked up with this move.
ps: please, dont go trusting oracle
That said, I think a lot of issues I've seen would be helped by people not being so afraid of rolling release , so maybe reconsider the fundamentals before being too chicken little. Also, I suspect this could be the kick we all need to start pushing nix and guix more seriously.
I like stream. A handful of my side projects are running it now, but IBM done fucked up with this move.
ps: please, dont go trusting oracle
I remember setting up and building a 16node cent OS cluster in my undergrad for a special big data paper back in 2012,
so sad to see this...long live forks
Well this sucks... IBM/RedHat is really shooting themselves in the foot here. Stable CentOS versions have always been my go-to for VPS services. Install it once and you're good -- plus no Ubuntu snap stuff... I have 5+ CentOS 8 installs and I was really banking on the LTS timeline. I wish they would have kept that going alongside their CentOS 7 support.
I'm debating whether or not to downgrade to CentOS 7 to at least keep going until 2024, instead of 2021 with CentOS 8.
Hopefully, some other player steps up and creates a similar offering.
Also, I've been irked lately about them deprecating virt-manager and pushing podman. I don't mind alternatives, just keep the feature parity when you switch. Cockpit is fairly limited compared to virt-manager.
I'm debating whether or not to downgrade to CentOS 7 to at least keep going until 2024, instead of 2021 with CentOS 8.
Hopefully, some other player steps up and creates a similar offering.
Also, I've been irked lately about them deprecating virt-manager and pushing podman. I don't mind alternatives, just keep the feature parity when you switch. Cockpit is fairly limited compared to virt-manager.
How does this affect FermiLAB? They stopped development on Scientific Linux to rebase on CentOS and now CentOS might not be useful for their purposes.
Hello, Oracle Linux.
http://linux.oracle.com
http://linux.oracle.com
They specifically made Scientific Linux as a royalty free alternative to RHEL so I can’t imagine they’d jump to a royalty-encumbered value loss Oracle Linux distro.
isn't Oracle Linux just CentOS wtih an oracle sticker and a contract?
Oracle has a page describing the difference:
https://linux.oracle.com/switch/centos/
They have a shell script to convert a CentOS install to Oracle Linux, so you can buy support if you want.
The converter only works with versions 5, 6, and 7.
It does not work with CentOS 8. It would be nice if that could get updated.
https://linux.oracle.com/switch/centos/
They have a shell script to convert a CentOS install to Oracle Linux, so you can buy support if you want.
The converter only works with versions 5, 6, and 7.
It does not work with CentOS 8. It would be nice if that could get updated.
Oh, FUCK.
I liked them because I could have a rock solid environment at work and play with technologies with centos at home.
Fuck all that I guess. If this is the game then I'm not renewing my RHCSA certification and I'll be considering definitively switching to Ubuntu.
I liked them because I could have a rock solid environment at work and play with technologies with centos at home.
Fuck all that I guess. If this is the game then I'm not renewing my RHCSA certification and I'll be considering definitively switching to Ubuntu.
Somewhat off topic: Are there any kind of stateless, managed-for-me server images?
I recently set up a digital ocean droplet with the default Ubuntu 20.04 Server image to host my web app. I don't like how I'm in charge of installing security updates and rebooting it (I don't really care about downtime), and I really don't like how I don't really remember what packages and commands I ran to install everything.
Presumably, this is what digital ocean app platform is for, where I could just provide a docker container. But the specs of the 5$ app platform container were half as good as the 5$ droplet, and I can run multiple things on the droplet in the future.
I recently set up a digital ocean droplet with the default Ubuntu 20.04 Server image to host my web app. I don't like how I'm in charge of installing security updates and rebooting it (I don't really care about downtime), and I really don't like how I don't really remember what packages and commands I ran to install everything.
Presumably, this is what digital ocean app platform is for, where I could just provide a docker container. But the specs of the 5$ app platform container were half as good as the 5$ droplet, and I can run multiple things on the droplet in the future.
This is sad. Our research group runs based on RHEL + CentOS. RHEL for all the important stuff, and CentOS for all the compute nodes. Now, if CentOS 8 dies, there is no way we are running say Debain on compute nodes and RHEL on other servers. RedHat sadly has to go away. It's their own way of losing our business, and losing goodwill. Now, the people at university will treat RedHat the same as Oracle and IBM for being greedy and evil.
Too bad Scientific Linux was dropped in favour of CentOS. Perhaps scientific community will revive Scientific Linux or something like that. Cant wait for what comes out of this.
Too bad Scientific Linux was dropped in favour of CentOS. Perhaps scientific community will revive Scientific Linux or something like that. Cant wait for what comes out of this.
CentOS is to be essentially the beta release for the next minor release of RHEL whereas Fedora ELN is targeting the next major release.
Makes sense commercially from RH's point of view. Boring and stable is now chargeable.
Makes sense commercially from RH's point of view. Boring and stable is now chargeable.
They did say this:
"In the first half of 2021, we will be introducing low- or no-cost programs for a variety of use cases, including options for open source projects and communities, partner ecosystems and an expansion of the use cases of the Red Hat Enterprise Linux Developer subscription to better serve the needs of systems administrators and partner developers. We’ll share more details on these initiatives as they become available."
So maybe if this pans out, a lot of projects will now be able to use RedHat EL proper.
So maybe if this pans out, a lot of projects will now be able to use RedHat EL proper.
I'll love to use proper RHEL everywhere on my personal non-commercial projects. I'm using it on my NAS, but I'd love to use it on VPS as well.
Thanks IBM. Now I'll have to revisit what OS to deploy at various remote experiments. I suppose this might be the kick needed to revive SL though.
They also conveniently waited until right after EL6 EOL...
They also conveniently waited until right after EL6 EOL...
Oh true what happens with Cern now? Debian? FreeBSD ;)
There is a long legacy of EL integration and know-how in various particle physics experiments (and research computing clusters, for that matter...).
If RH doesn't release some "Academic Version" (but who would even trust that at this point?), then I suspect revival of Scientific Linux or adoption of shudders Oracle Linux is more likely than a switch to Debian. FreeBSD is probably a non-starter.
If RH doesn't release some "Academic Version" (but who would even trust that at this point?), then I suspect revival of Scientific Linux or adoption of shudders Oracle Linux is more likely than a switch to Debian. FreeBSD is probably a non-starter.
>long legacy of EL integration and know-how in various particle physics experiments
That has nothing todo with a Distribution, maybe with linux but Redhat...pff....Looong-LTS that was the plus.
Oracle Linux...no one and especially cern would ever risk that.
That has nothing todo with a Distribution, maybe with linux but Redhat...pff....Looong-LTS that was the plus.
Oracle Linux...no one and especially cern would ever risk that.
CentOS Stream is RHEL Testing (like Debian Testing).
As stated in https://www.redhat.com/en/blog/centos-stream-building-innova...
"CentOS Stream now sits between the Fedora Project’s operating system innovation and RHEL’s production stability"
So if we compare to Debian, this means:
Fedora <=> Debian unstable (Sid)
CentOS Stream <=> Debian testing (currently Bullseye)
RHEL <=> Debian stable (currently Buster)
As stated in https://www.redhat.com/en/blog/centos-stream-building-innova...
"CentOS Stream now sits between the Fedora Project’s operating system innovation and RHEL’s production stability"
So if we compare to Debian, this means:
Fedora <=> Debian unstable (Sid)
CentOS Stream <=> Debian testing (currently Bullseye)
RHEL <=> Debian stable (currently Buster)
Almost, I'd say it's more like:
Rawhide <=> Sid
Fedora <=> Semi-stable-ish but short-lived and moves fast.
CentOS Stream <=> Bullseye but possibly less stable than Fedora in parts.
RHEL <=> Buster
Rawhide <=> Sid
Fedora <=> Semi-stable-ish but short-lived and moves fast.
CentOS Stream <=> Bullseye but possibly less stable than Fedora in parts.
RHEL <=> Buster
CentOS does not have anything equivalent in Debian.. The closest i can find for it is in FreeBSD.
FreeBSD 13-Current - Fedora Rawhide/Fedora
FreeBSD 12-Stable - CentOS Stream
FreeBSD 12.2-Release - RHEL
CentOS Stream will be the testing for the next minor release of RHEL, i think the closest in debian would be stable with the proposed repo fully enabled.
Between Debian and RH i see the following equivalency.
unstable (sid) - Fedora Rawhide
testing (bullseye) - Fedora, although not 100% equivalent as not all fedora releases became an RHEL, but fedora does act as testing for RHEL.
stable (buster) - RHEL
CentOS Stream is between testing and stable.
FreeBSD 13-Current - Fedora Rawhide/Fedora
FreeBSD 12-Stable - CentOS Stream
FreeBSD 12.2-Release - RHEL
CentOS Stream will be the testing for the next minor release of RHEL, i think the closest in debian would be stable with the proposed repo fully enabled.
Between Debian and RH i see the following equivalency.
unstable (sid) - Fedora Rawhide
testing (bullseye) - Fedora, although not 100% equivalent as not all fedora releases became an RHEL, but fedora does act as testing for RHEL.
stable (buster) - RHEL
CentOS Stream is between testing and stable.
When RH bought CentOS, it was clear they would kill it eventually, the question was when. Well, it looks like it's happening just now. Time for a CentOS replacement.
We use CantOS in production. Our servers are typically replaced once in 3 years. But we update our software stack on bare metal only once in 5 years or so. We however spin up VMs all the time on these servers, and having a single standard operating system base that was extremely stable did not have licensing issues was a positive. This changes the calculus for using RedHat based OSes. So we initiated a migration to Debian.
It actually provides transparency on the development of RHEL and provides one of the oft requested things they couldn't; that missing features for a package or a slightly newer version of something.
Jim Perrin explains it also here: https://jperrin.org/blog/thoughts-on-stream/
Jim Perrin explains it also here: https://jperrin.org/blog/thoughts-on-stream/
Is this just a ploy to get RHEL licensing $$$ while another project emerges to provide what CentOS used to? The whole point of CentOS was to be a carbon copy of RHEL. Then RedHat bought them and now this...
If you successfully fill that void, maybe you too can be acquired by IBM/RH in a few years as they repeat the cycle.
If you successfully fill that void, maybe you too can be acquired by IBM/RH in a few years as they repeat the cycle.
> while another project emerges to provide what CentOS used to?
This is an opportunity. Imagine Amazon stepping in and funding the CentOS replacement. They'd capture a huge chunk of the SME market within two years.
Amazon already has its own distribution in the form of Amazon Linux, a derivative of RHEL. Seems like a short walk to provide an unsupported, Amazon branded, bare metal RHEL-based distribution that also happens to align its users with AWS. The really smart thing would be to start there but then fork slowly and eventually diverge from RHEL in fundamental ways.
This is an opportunity. Imagine Amazon stepping in and funding the CentOS replacement. They'd capture a huge chunk of the SME market within two years.
Amazon already has its own distribution in the form of Amazon Linux, a derivative of RHEL. Seems like a short walk to provide an unsupported, Amazon branded, bare metal RHEL-based distribution that also happens to align its users with AWS. The really smart thing would be to start there but then fork slowly and eventually diverge from RHEL in fundamental ways.
Like many my first reaction was shock, but at the same time not surprised. Have even emailed the address provided with feedback as I work for a University which like many use a mix of RHEL and CentOS.
As per the FAQ though I suspect there is more to this than meets the eye. Two things strike me: 1. The suggestion that low or no cost options for RHEL are coming for certain categories of user. 2. As much as Stream will be a rolling and "beta" channel, Fedora/CentOS/RHEL already have testing repos within their release process so Stream may not be as unstable as this might first suggest.
With local staged repository mirrors Steam may end up being less volatile than the existing point releases which were notorious for breaking things at times.
As per the FAQ though I suspect there is more to this than meets the eye. Two things strike me: 1. The suggestion that low or no cost options for RHEL are coming for certain categories of user. 2. As much as Stream will be a rolling and "beta" channel, Fedora/CentOS/RHEL already have testing repos within their release process so Stream may not be as unstable as this might first suggest.
With local staged repository mirrors Steam may end up being less volatile than the existing point releases which were notorious for breaking things at times.
I think people are missing something here... this isn't going to make a typical CentOS deployment less stable than before. The intended result is to make RHEL even more stable than before, but leaving CentOS in the position where RHEL was until now.
Seriously, think about it. Yes, users of CentOS Stream will be essentially be doing beta-testing for RedHat, but it's a type of beta testing that until now didn't even exist; any instability, conflict, or vulnerability that enters into CentOS Stream is one that would have entered into production RHEL systems otherwise. So the net effect is fewer of those for RHEL, but the same number as before for CentOS. CentOS users lose nothing they ever had.
Seriously, think about it. Yes, users of CentOS Stream will be essentially be doing beta-testing for RedHat, but it's a type of beta testing that until now didn't even exist; any instability, conflict, or vulnerability that enters into CentOS Stream is one that would have entered into production RHEL systems otherwise. So the net effect is fewer of those for RHEL, but the same number as before for CentOS. CentOS users lose nothing they ever had.
At the risk of getting hit with downvotes... because its oracle..
Oracle Linux actually seems to be the best way out (at least for now)
/me shudders.
Actually just installing it on a new 5900x now after aborting CentOS due to it becoming abandonware and having its name stolen by IBM.
Oracle Linux actually seems to be the best way out (at least for now)
/me shudders.
Actually just installing it on a new 5900x now after aborting CentOS due to it becoming abandonware and having its name stolen by IBM.
I've had a feeling, at least since the IBM purchase of Redhat, that the days of using Centos as a free replacement of RHEL with all the security updates and patches for absolutely free, are coming to an end.
You'll either be forced to buy licenses or use a far less stable and secure version of stream. Or, of course, you can rent VMs with maintained distros from Amazon, Microsoft, Google, etc. on their cloud platforms.
IBM bought Redhat for a reason, and if history is any guide, they'll begin aggressively pursuing large companies, governmental, educational, etc. users of Centos and push them to buy support licenses of Redhat.
You'll either be forced to buy licenses or use a far less stable and secure version of stream. Or, of course, you can rent VMs with maintained distros from Amazon, Microsoft, Google, etc. on their cloud platforms.
IBM bought Redhat for a reason, and if history is any guide, they'll begin aggressively pursuing large companies, governmental, educational, etc. users of Centos and push them to buy support licenses of Redhat.
[deleted]
This marks the end of my willingness to run anything on a redhat product ever again now that they've demonstrated that their commitments are worth nothing in the face of where they want their business to go.
This is bad, but the way things were going for the last few years with Red Hat gaining more and more importance in the general linux ecosystem something like that happening was just inevitable.
>> CentOS Stream now sits between the Fedora Project’s operating system innovation and RHEL’s production stability
So if we compare to Debian, this means:
Fedora <=> Debian unstable (Sid)
CentOS Stream <=> Debian testing (currently Bullseye)
RHEL <=> Debian stable (currently Buster)
quote source: https://www.redhat.com/en/blog/centos-stream-building-innova... (linked from the article)
So if we compare to Debian, this means:
Fedora <=> Debian unstable (Sid)
CentOS Stream <=> Debian testing (currently Bullseye)
RHEL <=> Debian stable (currently Buster)
quote source: https://www.redhat.com/en/blog/centos-stream-building-innova... (linked from the article)
i dont agree with this..
in debian testing is the next major version, while centos stream is testing for the next minor release.
It is fedora that is testing for next major release.
sid would be similar to fedora rawhide..
sid <=> fedora rawhide
testing (bullseye) <=> fedora, altough not every fedora became a rhel
stable (buster) <=> rhel
centos stream would be likely similar to having stable with the proposed repo fully enabled.
in debian testing is the next major version, while centos stream is testing for the next minor release.
It is fedora that is testing for next major release.
sid would be similar to fedora rawhide..
sid <=> fedora rawhide
testing (bullseye) <=> fedora, altough not every fedora became a rhel
stable (buster) <=> rhel
centos stream would be likely similar to having stable with the proposed repo fully enabled.
Seems like that is accurate. I am struck by how cleaner and simpler Debian's naming scheme is. If you don't follow the Red Hat world closely, those names are going to be very confusing.
> I am struck by how cleaner and simpler Debian's naming scheme is
It's just a simple common-sense scheme, it's not the result of deep thought. What you're struck by is how marketing-oriented the RedHat repository naming scheme seems to be...
It's just a simple common-sense scheme, it's not the result of deep thought. What you're struck by is how marketing-oriented the RedHat repository naming scheme seems to be...
So, where does that make Fedora Rawhide fit?
I am not sure how CentOS Stream makes any sense. CentOS stands for Community Enterprise Operating System, how on earth can CentOS Stream be called an Enterprise operating System?
It is also not community-based anymore anyway.
So now it is just "Operating System", maybe they should rename it IBMBetaOS or something like that.
So now it is just "Operating System", maybe they should rename it IBMBetaOS or something like that.
Would it make sense to regard CentOS Stream as essentially CentOS/RHEL Beta?
It's basically the beta of the next RHEL minor release, not a beta of a next major release.
Yes.
I mean they say "no", but it's definitely something less than the full production release.
Hmm.. In terms of alternatives, how can we be sure that Ubuntu sponsor Canonical will not get acquired and change the rules of how freely Ubuntu stable versions are available? This whole thing is making me rethink if it makes sense to rely on free unsupported software at the operating system level. I don't trust oracle and cloud linux also seems like a commercial company wanting to profit from Linux like Red Hat. Hmmm...
Just move to Ubuntu / Debian it's the logical choice here. Ubuntu is already the #1 distro on server, it will consolidate that poistion even more.
Can you back that number up?
In my corner of the world Ubuntu plays no role at all on servers. It's all CentOS/RHEL here.
In my corner of the world Ubuntu plays no role at all on servers. It's all CentOS/RHEL here.
Ubuntu is by far the most used Linux distro on server, the problem with CentOS / RHEL is they did not support recent kernel for a long time, so you see very few cloud servers with those distro, especially since Docker / Kubernetes took off. Also RHEL is not free so there is no way it's "popular" outside of very enterprise needs ( HPC ect ... ).
At previous work they moved away from CentOS to use Ubuntu because libc was just to old, actually everything was old.
At previous work they moved away from CentOS to use Ubuntu because libc was just to old, actually everything was old.
I'd actually be interested to see those numbers. Do you have any evidence to support that claim?
It'd be very interesting for us in terms of priorising supported distros. A bit of googling didn't lead to much.
You could be biased by your own job/experience. Most IT doesn't run on the Cloud or in Kubernetes (yet).
It'd be very interesting for us in terms of priorising supported distros. A bit of googling didn't lead to much.
You could be biased by your own job/experience. Most IT doesn't run on the Cloud or in Kubernetes (yet).
https://thecloudmarket.com/stats#/by_platform_definition
Those are numbers for EC2 so a fairly accurate measurement.
Those are numbers for EC2 so a fairly accurate measurement.
Those are the number of images, not the number of instances.
[deleted]
I’m on the fence.
I work in higher ed and happily pay the premium for red hat.
We only have about 500 systems in our top 10 research/health based institution.
I’m really tempted to spin up an in-house replacement for CentOS. Not strictly to defer adoption of RHT, but instead to fill the necessary gap for those who have gone “all-in” with CentOS.
Those in higher ed have access to all the necessary components required to produce CentOS. All they need is leadership.
I work in higher ed and happily pay the premium for red hat.
We only have about 500 systems in our top 10 research/health based institution.
I’m really tempted to spin up an in-house replacement for CentOS. Not strictly to defer adoption of RHT, but instead to fill the necessary gap for those who have gone “all-in” with CentOS.
Those in higher ed have access to all the necessary components required to produce CentOS. All they need is leadership.
Putting aside what Red Hat wants, it's still open source. Why couldn't a new project replace centOS as the free alternative to RHEL?
It's hard to replace all the people who were paid to maintain CentOS without another corporation stepping in. Large software projects like this unfortunately don't happen in a vacuum.
Wow. Disappointing! Wonder if we should trust other Red Hat projects? Like I think podman is cool if I were building my own PaaS type system.
We are creating the next RHEL based Enterprise Linux - same as CentOS used to be. Targeted first release is January 31, 2021.
Looking for both volunteers or people who want to be paid for their efforts. Join us to secure Enterprise Linux as a free (as in beer and freedom) for the foreseeable future.
https://monkos.org
Looking for both volunteers or people who want to be paid for their efforts. Join us to secure Enterprise Linux as a free (as in beer and freedom) for the foreseeable future.
https://monkos.org
This is why I immediately switched our long term plans to Ubuntu after the IBM acquisition was announced.
The end of the era of the most stable Linux distributive for servers. Why it happened. I love Centos so much, but for now I have to decide which distributive I'll use in my production and I don't want to use neither Oracle or Debian like. IBM made my life harder.
[deleted]
[deleted]
I have a feeling they are going to switch RHEL to the same model that Ubuntu follows, where it’s free to download and use, with no license to worry about or anything, and then there’s an optional support contract you can add to it if you want paid support.
If that was the case they should have announced that now so people don't jump ship off CentOS prior to the announcement.
Is there anything beyond that feeling that might indicate this might be to the case?
Is this meant to make RHEL more attractive than CentOS because now it will be more stable?
A lot of justified complaints here but the Oracle build of RHEL is 100% free and always up to date (I.e. while CentOS still doesn’t have 8.3 out, Oracle had it out 9 days after RH).
Yes, Oracle sucks but it’s a better RHEL build than CentOS was.
Yes, Oracle sucks but it’s a better RHEL build than CentOS was.
So was Java. Until it wasn’t.
Well, wasn't this the original worry when centos was "acquired" by redhat many years ago? I suppose a new distro that did what the pre-redhat centos did (source rebuilds of RHEL) is what will happen.
What are the chances that someone starts another community project like CentOS where they remove the licenses and stuff from upstream RHEL and distribute it under a new name
Already happening. The guy who started CentOS is coordinating the new project. You can view the progress on Slack.
https://join.slack.com/t/hpcng/shared_invite/zt-gy0st6mt-ijg...
https://join.slack.com/t/hpcng/shared_invite/zt-gy0st6mt-ijg...
If I were running an open source software business, I would simply provide long-term support updates for free and also have lots of money to fund ongoing development.
Among existing alternatives such as Ubuntu LTS, Debian, openSUSE, etc. which is the least likely to meet the CentOS fate (I mean acquired by a large corporation)?
I'm not too familiar with the openSUSE team, but I think it's a pretty safe bet that Debian will remain independent.
Ubuntu is already owned by a large corportation.
Ubuntu is already owned by a large corportation.
Debian, by a large margin. Ubuntu is already "owned" by Canonical and openSUSE is just a free counterpart to SUSE Linux Enterprise by SUSE software solutions GmbH in very much the same way CentOS was to RHEL in the recent years.
It's really sad to see this. I really hope some people take up a mantle and start a continuation of CentOS 8 / 9.
No mention of OpenMandriva as a alternative RPM distro.
No mention of OpenMandriva as a alternative RPM distro.
So, I suppose CentOS is dead. As others have stated, another group will have to step up and create another CentOS, or just switch to Debian Testing.
Official CentOS/RHEL is more like Debian Stable.
The new CentOS "Stream" sounds like it will be more like Debian Testing.
The new CentOS "Stream" sounds like it will be more like Debian Testing.
Debian Stable might be more analogous to CentOS, but they don't do major feature backports like RHEL does, so I find stable is often much too old by the time it's actually released.
There's always a backports repository for the stable release in Debian:
deb http://deb.debian.org/debian buster-backports main contrib non-free
deb-src http://deb.debian.org/debian buster-backports main contrib non-freeOn the other hand, CentOS systems tend to last much longer due to the 10-year support cycle. So I often encounter wild specimens that are even older than Debian oldstable.
Right now, I've got a bunch of CentOS 6 servers with 2.6.32 kernels that are freshly out of support this month. I was hoping to replace them with 8, but now I'll probably have to settle for 7. At least I can take consolation in the fact that I haven't been called in to troubleshoot any CentOS 5 servers lately.
Right now, I've got a bunch of CentOS 6 servers with 2.6.32 kernels that are freshly out of support this month. I was hoping to replace them with 8, but now I'll probably have to settle for 7. At least I can take consolation in the fact that I haven't been called in to troubleshoot any CentOS 5 servers lately.
Take a look in buster-updates (or any X-updates for older ones).
I guess there are only so many ways to organize a distro.
I guess there are only so many ways to organize a distro.
Exactly.
As stated in https://www.redhat.com/en/blog/centos-stream-building-innova... (linked from the article):
"CentOS Stream now sits between the Fedora Project’s operating system innovation and RHEL’s production stability"
So if we compare to Debian, this means:
Fedora <=> Debian unstable (Sid)
CentOS Stream <=> Debian testing (currently Bullseye)
RHEL <=> Debian stable (currently Buster)
As stated in https://www.redhat.com/en/blog/centos-stream-building-innova... (linked from the article):
"CentOS Stream now sits between the Fedora Project’s operating system innovation and RHEL’s production stability"
So if we compare to Debian, this means:
Fedora <=> Debian unstable (Sid)
CentOS Stream <=> Debian testing (currently Bullseye)
RHEL <=> Debian stable (currently Buster)
There is no real equivalent to CentOS Stream in Debian's release model.
Perhaps the closest is "the DAK upload queue for Debian stable", but that tends to contain mostly security updates, and according to other posts in this thread that is the one case where CentOS Stream is not an upstream of RHEL.
CentOS Stream contains feature backports, which generally don't happen in Debian stable, but it's only very specific backports, not every package gets updated like in Debian testing.
I'd put it like:
Fedora rawhide <=> Debian unstable
Fedora <=> Debian testing
CentOS Stream <=> DAK upload queue for Debian stable
RHEL <=> Debian stable
Perhaps the closest is "the DAK upload queue for Debian stable", but that tends to contain mostly security updates, and according to other posts in this thread that is the one case where CentOS Stream is not an upstream of RHEL.
CentOS Stream contains feature backports, which generally don't happen in Debian stable, but it's only very specific backports, not every package gets updated like in Debian testing.
I'd put it like:
Fedora rawhide <=> Debian unstable
Fedora <=> Debian testing
CentOS Stream <=> DAK upload queue for Debian stable
RHEL <=> Debian stable
I wonder if it would it be possible to 'dnf downgrade' a CentOS Stream host to the same package version as a RHEL8 host?
I'd love to have the original Centos project people doing an AMA and what they (really) think about this decision!
Is CentOS Stream totally unacceptable for traditional CentOS users who don't need compatibility for RHEL?
Not obvious who would use CentOS Stream.
How viable is CentOS Stream on the desktop? Fedora moves a bit too fast sometimes, but CentOS too slow.
CentOS Stream is going to move at the same pace as RHEL, just ahead of it.
What does that mean? That it is more up to date than RHEL? How far behind Fedora is that?
Fedora releases every six months. RHEL has a major release every three years, with minor releases every six months.
The major release of RHEL is usually forked from a Fedora version about a year before the major release, so with some exceptions software versions tend to be about a year behind those in a Fedora release initially, and then as RH backports patches rather than revving versions, drifts further.
It's the patches and smaller updates — and new hardware enablement in the full-support phase — that will be landing in CentOS Stream. Previously, this stuff was developed internally and only released to the world at the minor-release drop every six months. Now, it'll be developed in a shared space. So what you'll have in CentOS Stream is whatever is intended to ship in a RHEL minor update within six months.
There may occasionally be a situation where an update introduces bugs into Stream that would have been caught by QA before a public minor RHEL release and subsequent CentOS Linux rebuild. But I don't actually expect that to happen enough to worry about in any case where you can justify not paying for actual supported RHEL in the first place.
The major release of RHEL is usually forked from a Fedora version about a year before the major release, so with some exceptions software versions tend to be about a year behind those in a Fedora release initially, and then as RH backports patches rather than revving versions, drifts further.
It's the patches and smaller updates — and new hardware enablement in the full-support phase — that will be landing in CentOS Stream. Previously, this stuff was developed internally and only released to the world at the minor-release drop every six months. Now, it'll be developed in a shared space. So what you'll have in CentOS Stream is whatever is intended to ship in a RHEL minor update within six months.
There may occasionally be a situation where an update introduces bugs into Stream that would have been caught by QA before a public minor RHEL release and subsequent CentOS Linux rebuild. But I don't actually expect that to happen enough to worry about in any case where you can justify not paying for actual supported RHEL in the first place.
What will this mean for Fedora? Doesn’t Fedora already occupy the niche of “Redhat-unstable”?
Fedora doesn't like to be put in that particular niche anyway. Yes, Fedora is fast moving and it is what Red Hat uses as the base for major releases, but we're more than "Redhat-unstable" in so many ways.
CentOS Stream will be the upstream for RHEL minor branch development. This is actually a huge thing that I think people are missing: previously, once branched from Fedora, RHEL development did not happen in the public eye. With Stream, it will. This is huge and awesome good news. However, that development will still be entirely Red Hat curated. This is different from Fedora, where we make community decisions with Red Hat's engineering input as a stakeholder but not the decider. (See for example btrfs as the default filesystem.)
CentOS Stream will be the upstream for RHEL minor branch development. This is actually a huge thing that I think people are missing: previously, once branched from Fedora, RHEL development did not happen in the public eye. With Stream, it will. This is huge and awesome good news. However, that development will still be entirely Red Hat curated. This is different from Fedora, where we make community decisions with Red Hat's engineering input as a stakeholder but not the decider. (See for example btrfs as the default filesystem.)
It might be "huge and awesome good news" if they keep both CentOS 8.x and CentOS Stream. But they're forcing Stream as a replacement, hence all the pushback. Let's be honest, most people just want to run a gratis released RHEL, not run their betas.
My guess is that Stream turned out way less popular than their sponsored hoped (who cares if it's developed in the public eye if it's entirely RH curated anyway). So CentOS 8.x had to die.
My guess is that Stream turned out way less popular than their sponsored hoped (who cares if it's developed in the public eye if it's entirely RH curated anyway). So CentOS 8.x had to die.
>This is huge and awesome good news.
So why the negativity at this "huge and awesome good news"?
So why the negativity at this "huge and awesome good news"?
Change is scary.
Come on, be serious. You think people who standardized their infrastructure on CentOS 8 under the assumption that they will have 10 years of stable support, are negative about this because they are afraid of change?
And you know that's not the reason for the negativity, so I don't know why you're being so flippant about this. Nobody has a problem with the idea of 'CentOS 8 Stream'. They have a problem with this being the replacement to CentOS 8 Linux because it doesn't fulfill the same use-cases.
And you know that's not the reason for the negativity, so I don't know why you're being so flippant about this. Nobody has a problem with the idea of 'CentOS 8 Stream'. They have a problem with this being the replacement to CentOS 8 Linux because it doesn't fulfill the same use-cases.
In complete seriousness, I think there are three broad categories:
* Use cases which actually despite the fears will be covered just fine by Stream * Use cases which will be covered by the upcoming expanded no-cost/low-cost RHEL programs * Use cases which, yeah, aren't covered
It's my estimation that the first two are actually the vast majority. I don't mean to be flippant (it was a long day). understand that people who are mostly in the third case are angry and disappointed, but from what I've seen in talking to people both when Stream was launched and after this announcement, at least some large number who are worried that that's their situation are going to be actually getting something better when the dust settles.
* Use cases which actually despite the fears will be covered just fine by Stream * Use cases which will be covered by the upcoming expanded no-cost/low-cost RHEL programs * Use cases which, yeah, aren't covered
It's my estimation that the first two are actually the vast majority. I don't mean to be flippant (it was a long day). understand that people who are mostly in the third case are angry and disappointed, but from what I've seen in talking to people both when Stream was launched and after this announcement, at least some large number who are worried that that's their situation are going to be actually getting something better when the dust settles.
According to the FAQ, specifically question 15: https://centos.org/distro-faq/
> CentOS Stream is focused on the next RHEL minor release. This means we are improving and influencing the shipping releases of RHEL. Fedora ELN is a testing area for changes that may occur in the next major release of RHEL.The CentOS Project cannot and does not speak for Fedora
> CentOS Stream is focused on the next RHEL minor release. This means we are improving and influencing the shipping releases of RHEL. Fedora ELN is a testing area for changes that may occur in the next major release of RHEL.The CentOS Project cannot and does not speak for Fedora
I am down to make a fork, like the original CentOS before they sell out, who's in ?
Rolling release doesn't mean bleeding edge... Sounds like some of you never update
Interesting development.
What's the current difference between RHEL and Oracle Linux? Our institution used to be an RHEL shop, but switched to OL -- I just assumed that RHEL was historical at this point.
[edit -- thanks for the answers. I realize now that my memory failed me... I mis-remembered that Oracle bought RedHat, not IBM.]
What's the current difference between RHEL and Oracle Linux? Our institution used to be an RHEL shop, but switched to OL -- I just assumed that RHEL was historical at this point.
[edit -- thanks for the answers. I realize now that my memory failed me... I mis-remembered that Oracle bought RedHat, not IBM.]
Oracle Linux is RHEL... just with the Red Hat branding replaced by Oracle branding. I guess there are some other differences as well but that's the gist of it.
It's mostly for Oracle products and has the oracle yum repositories preconfigured iirc. So their database products can be installed out of the box.
But RHEL is considered the industry standard when it comes to corporate Linux distributions.
It's mostly for Oracle products and has the oracle yum repositories preconfigured iirc. So their database products can be installed out of the box.
But RHEL is considered the industry standard when it comes to corporate Linux distributions.
Thanks, that helps. We're also an Oracle (database) shop, so the Oracle-specific repos are probably a plus in our case.
is there any license or other issue (apart from resources) restricting someone to just take on the Centos n downstream development in addition to redhat building stream?
Well, I am still using Debian distro.
Seems like RedHat wanting to make CentOS a less "safe" alternative to RHEL.
You want stability? Pay up!
In essence.
In essence.
Just upgraded to CentOS Stream from CentOS 7, so far so good.
Contrary to most commenters, I am actually optimistic. I switched to Arch on the desktop a decade ago because I was tired of having to often nuke and pave my install every 6 months. I am still with Arch all these years later, even for my work machine and I work as a programmer so instability wouldn't fly.
Obviously the support window for CentOS was much, much longer, but if they're careful we can perhaps have the convenience of a rolling release with the stability of RHEL, or close to then more power to them.
My only concern is the short EOL window for current CentOS 8 users.
Contrary to most commenters, I am actually optimistic. I switched to Arch on the desktop a decade ago because I was tired of having to often nuke and pave my install every 6 months. I am still with Arch all these years later, even for my work machine and I work as a programmer so instability wouldn't fly.
Obviously the support window for CentOS was much, much longer, but if they're careful we can perhaps have the convenience of a rolling release with the stability of RHEL, or close to then more power to them.
My only concern is the short EOL window for current CentOS 8 users.
People used to say that it’s possible to make money with OSS because Red Hat does it. This invalidates that already dated argument.
How so? RHEL is open source... Red Hat also owns Centos.
Red Hat already staged their exit.
What is happening with open source lately. Just this today I am.reading about QT, CENTOS, MAPBOX, travis all ditching open source. Well I don't remember the qt story but yeah.
What is the point of offering your software to the community as open source if the only end game is to make people dependent and then pull a fast one on them. Sigh
What is the point of offering your software to the community as open source if the only end game is to make people dependent and then pull a fast one on them. Sigh
Open Source is not the same as Free and Open Source (FOSS). If you want true software freedom, stick with communities or orgs based on the FOSS ideology. Big corporations cannot be FOSS, it's a conflict of interest for them.
People need to eat and pay rent. New developers are doing everything on web/cloud and see no reason to invest time in open source on “legacy” on-prem systems, despite the fact that those are what underlie all of those higher level tiers. Since new developers are not stepping in, the older guys who started the projects just want to get away from the relentlessly thankless activity of giving stuff away for free, or maybe retire.
my question stands. if you are a corporation, why are you offering an open source in the first place? i am not talking about a library developer who built it for fun but because its MIT, every faang is using it extensively and the original dev is not getting any remuneration while faang is earning big bucks. that is not the issue here.
specifically if travis had the idea to pull a bait and switch always to the community, isnt that bad? why offer "free for open source" in the first place when you know it will cost them money and developers need to earn? no open source community is begging for handouts.
specifically if travis had the idea to pull a bait and switch always to the community, isnt that bad? why offer "free for open source" in the first place when you know it will cost them money and developers need to earn? no open source community is begging for handouts.
As a corporation you open source at least pieces needed for interoperability, that is a valid reason. Otherwise you can get into the pains of SMB/Samba or drivers for paid databases for more programming languages one is able to support. For example Microsoft is working on the PHP driver for SQL server, this helps them by opening the door to PHP developers to use MS SQL and eventually pay for Standard or Enterprise editions instead of using the free Express one. It is kind of a freemium game.
CentOS is not "ditching open source" in any respect whatsoever.
Centos is ditching LTS release in favour of rolling release which makes it unsuitable for production servers. Is that not ditching open source production server software?
I read somewhere the founder of centos is thinking of forking. that'd be nice
I read somewhere the founder of centos is thinking of forking. that'd be nice
https://news.ycombinator.com/item?id=25345428&p=2
https://news.ycombinator.com/item?id=25345428&p=3
(This message will eventually self-destruct.)