Rocky Linux releases its first release candidate(rockylinux.org)
rockylinux.org
Rocky Linux releases its first release candidate
https://rockylinux.org/download
118 comments
I’d say “neither”. CentOS would have fail had Redhat not taken over. My guess is that supporting all the companies who do not want to pay Redhat, for free, is going to push developers way pretty quickly.
Even if I’m wrong I’d still want to see at least two or three solid release before using either in production.
Just use Redhat or switch to Ubuntu. Then you can re-evaluate in five tears time.
Even if I’m wrong I’d still want to see at least two or three solid release before using either in production.
Just use Redhat or switch to Ubuntu. Then you can re-evaluate in five tears time.
> I’d say “neither”. CentOS would have fail had Redhat not taken over.
While it's possible that CentOS would have failed (I'm not sure slow initial releases actually indicate that), it also wasn't the only popular clone of RHEL in popular use. Scientific Linux (developed by FermiLab) was also popular and in fairly wide use. I doubt Red Hat would have made the change to CentOS that spurred all this if Scientific Linux hadn't decided not to continue and just use CentOS instead in 2019, because instead of a "crap, we have to start a new distro to provide what CentOS did" movement there would have been a much quicker and easier mass exodus to Scientific Linux.
While it's possible that CentOS would have failed (I'm not sure slow initial releases actually indicate that), it also wasn't the only popular clone of RHEL in popular use. Scientific Linux (developed by FermiLab) was also popular and in fairly wide use. I doubt Red Hat would have made the change to CentOS that spurred all this if Scientific Linux hadn't decided not to continue and just use CentOS instead in 2019, because instead of a "crap, we have to start a new distro to provide what CentOS did" movement there would have been a much quicker and easier mass exodus to Scientific Linux.
You might be right, there was not stopping Redhat from effectively killing CentOS anymore.
I still don’t want to build anything new on an distro that have still to prove they can maintain the project for two or three release.
I still don’t want to build anything new on an distro that have still to prove they can maintain the project for two or three release.
The Scientific Linux team decided to not make a Scientific Linux 8, and instead switch over to CentOS 8[0]. Note this was announced prior to the announcement about CentOS 8 going away.
CERN et al are still deciding what to do[1].
[0]: https://listserv.fnal.gov/scripts/wa.exe?A2=SCIENTIFIC-LINUX...
[1]: https://linux.web.cern.ch/#update-on-centos-linux-strategy
CERN et al are still deciding what to do[1].
[0]: https://listserv.fnal.gov/scripts/wa.exe?A2=SCIENTIFIC-LINUX...
[1]: https://linux.web.cern.ch/#update-on-centos-linux-strategy
Would Rocky Linux be an option for CERN?
I'm assuming the Centos 8 install instructions for e.g. GitLab also work with Rocky Linux? Conda/Micromamba definitely should.
I'm assuming the Centos 8 install instructions for e.g. GitLab also work with Rocky Linux? Conda/Micromamba definitely should.
> CentOS would have fail had Redhat not taken over...
CentOS had a great backing from supercomputing centers at least (I work for one of them). We'd have supported it with no problems whatsoever if they needed any help.
They're in a pretty good shape even before acquisition. Even CERN has decided to migrate (which is a big deal), as mentioned elsewhere.
CentOS had a great backing from supercomputing centers at least (I work for one of them). We'd have supported it with no problems whatsoever if they needed any help.
They're in a pretty good shape even before acquisition. Even CERN has decided to migrate (which is a big deal), as mentioned elsewhere.
Ubuntu LTS popularity suggests 5 year timeframe is long enough.
If people are happy with that, then why not be happy with Centos Stream which is also supported 5 years?
In all likelihood it'll be as solid as it's ever been.
In all likelihood it'll be as solid as it's ever been.
The problem isn't the 5 years. It is the fact that Stream will have packages more towards the leading edge and potentially have more bugs. Then, when a bug is found in a package, RHEL gets the patch first, but then the patch needs to be re-worked to get it to apply against the newer version of the package that is in Stream. I don't know if the wall will still exist between CentOS and RHEL teams, where CentOS won't know of a(n) (embargoed) patch that RHEL has prior to public release. If they don't, then potentially something like Rocky will get the patch before Stream (due to the above mentioned re-working of the patch).
Now if that firewall between the two groups gets some holes poked in it, where Stream can start working with the patch sets prior to release on RHEL, then it may not be such an issue.
Now if that firewall between the two groups gets some holes poked in it, where Stream can start working with the patch sets prior to release on RHEL, then it may not be such an issue.
> (if) Stream can start working with the patch sets prior to release on RHEL, then it may not be such an issue...
From the chats I had with people who work either on RH or Fedora, CentOS Stream is actually RHEL's next point release's candidate version.
In practicality, CentOS will move from RHEL-1 to RHEL+1 with security patches included.
We're one of the parties get pretty burned by this, but things look better than the start. We'll see.
From the chats I had with people who work either on RH or Fedora, CentOS Stream is actually RHEL's next point release's candidate version.
In practicality, CentOS will move from RHEL-1 to RHEL+1 with security patches included.
We're one of the parties get pretty burned by this, but things look better than the start. We'll see.
Are you just guessing that third parties have enough resource to release proper patches quicker?
Not sure what the "rework" is about when a bug is found in Stream, the "rework" is toward older versions of the package in RHEL.
I always wonder how the statements to dismiss Stream is quite weak.
Not sure what the "rework" is about when a bug is found in Stream, the "rework" is toward older versions of the package in RHEL.
I always wonder how the statements to dismiss Stream is quite weak.
[deleted]
Nothing wrong with debian minimal. things a beast.
Isn't almalinux some cpanel tainted nasty horror? The base derivative of cloudlinux instead of centos. If you want you can md5 hash your passwords, unsalted and run telnetd too..
I'd never heard of the company behind Alma before this shambles, while Greg K is pretty well known in the HPC world and as the original CentOS founder. If I had to bet, I'd say 2 years from now adoption of these will be 80/20 in favour of Rocky.
I don't get it. CentOS "failed" because there were not enough community resources to sustain it. Rocky Linux is founded by the CentOS founder. Why will Rocky Linux succeed where CentOS "failed"? How would Rocky Linux get resources to sustain it?
The “failure” of the CentOS community is really related to the nature of the distro. As they aimed to be a fully compatible clone of RHEL, there’s not much you can allow in terms of community contribution to packages, etc,. Those kind of restrictions don’t lend themselves well to forming a vibrant group of contributors.
The main area that was lacking are the other resources, like wiki, forums, and other docs. That’s one area where criticism is warranted. I always wince when I have to go to the Arch wiki to figure out how to set something up in CentOS.
The main area that was lacking are the other resources, like wiki, forums, and other docs. That’s one area where criticism is warranted. I always wince when I have to go to the Arch wiki to figure out how to set something up in CentOS.
> The main area that was lacking are the other resources, like wiki, forums, and other docs. That’s one area where criticism is warranted. I always wince when I have to go to the Arch wiki to figure out how to set something up in CentOS.
Same story as an Ubuntu user. Actually, doesn't everyone go to the Arch wiki? :D
Same story as an Ubuntu user. Actually, doesn't everyone go to the Arch wiki? :D
Only issue I have with using the Arch wiki (really the best Nix only wiki) to troubleshoot CentOS is due old versions in CentOS. CentOS seemed to mainly backport security fixes to older versions, so often flags or features of commands don't apply.
Your use of "Nix" to mean Unix (if that is what you are doing) is confusing!
(Nix is a package manager for Linux.)
(Nix is a package manager for Linux.)
> CentOS seemed to mainly backport security fixes to older versions, so often flags or features of commands don't apply.
In fairness, that's kind of the point of CentOS et al.
In fairness, that's kind of the point of CentOS et al.
You can just go to the RHEL docs.
https://access.redhat.com/documentation/en-us/red_hat_enterp...
There are plenty of RHEL docs that will show up in a search but are inaccessible because it's hidden behind a login.
That's not documentation that's support knowledgebase. You can just pay for a single subscription at 349$/yr and get access to it. It's worth it if you are running a large fleet.
Upvoting because you are correct that the documentation is freely available and it’s only the knowledge-base that requires an account. However, there can be some very useful information in the knowledge-base, e.g., resolutions to problems that don’t have a readily available answer anywhere else on the Internet. If you’re not running a large fleet, a cheaper option is to sign up for a developer account which costs nothing.
Didn’t it fail because RH chose so? C8 certainly works fine, if boring.
Before RH took over CentOS it was pretty much dying on the vine, releases were getting VERY slow, etc.
It remains to be seen if the cloud companies will find a CentOS-like OS important enough to fund the development of things like Rocky.
It remains to be seen if the cloud companies will find a CentOS-like OS important enough to fund the development of things like Rocky.
> Before RH took over CentOS it was pretty much dying on the vine, releases were getting VERY slow, etc.
A slow initial release and dying on the vine are two completely separate things. There's significant overlap in time between major distro releases, and while many users of CentOS were excited about getting newer versions, it was usually not imperative and all involved would likely agree that making sure existing releases continue to have timely updates for security and other things was more important.
> It remains to be seen if the cloud companies will find a CentOS-like OS important enough to fund the development of things like Rocky.
Whether cloud companies or not, there are a few ways forward now that weren't really considered previously. CentOS always had a somewhat tacit agreement with Red Hat to not overtly compete with Red Hat's revenue stream. i.e. Don't sell support, if advanced help is needed refer them to Red Hat for a license and support.
I would say the relationships now are a tad more adversarial. Asking for money in more direct manners may now be more feasible. Even without that, I do think the cloud providers can easily fund one or more of these projects enough. The amount of money even one could spend to ensure the staffing of one of these projects is less than a rounding error in their operating budget, and given how often I suspect CentOS was chosen as the deployed OS in a way that makes their total cost numbers reflected back to a CTO look less, a very good investment for them.
A slow initial release and dying on the vine are two completely separate things. There's significant overlap in time between major distro releases, and while many users of CentOS were excited about getting newer versions, it was usually not imperative and all involved would likely agree that making sure existing releases continue to have timely updates for security and other things was more important.
> It remains to be seen if the cloud companies will find a CentOS-like OS important enough to fund the development of things like Rocky.
Whether cloud companies or not, there are a few ways forward now that weren't really considered previously. CentOS always had a somewhat tacit agreement with Red Hat to not overtly compete with Red Hat's revenue stream. i.e. Don't sell support, if advanced help is needed refer them to Red Hat for a license and support.
I would say the relationships now are a tad more adversarial. Asking for money in more direct manners may now be more feasible. Even without that, I do think the cloud providers can easily fund one or more of these projects enough. The amount of money even one could spend to ensure the staffing of one of these projects is less than a rounding error in their operating budget, and given how often I suspect CentOS was chosen as the deployed OS in a way that makes their total cost numbers reflected back to a CTO look less, a very good investment for them.
Amazon Linux 2 is built on CentOS 7.
AWS are a sponsor of Rocky Linux
AWS are a sponsor of Rocky Linux
Don't think this is the case. It's downstream of RHEL but with a bunch of liberties, so CentOS/Rocky doesn't change much there
I guess they’re kinda forced to. Switch to Ubuntu or Debian for Amazon Linux 3 would be weird, but perhaps a smart choice.
They could do their own Fedora downstream, or jump to openSUSE for a different stable RPM distro.
The could just do their own RHEL fork, which would make Amazon Linux a peer to rocky instead of a downstream.
They could have done that from the start, like Oracle, but they choose not to for a reason, most likely to save money.
So now they either have to support Rocky Linux, and hope others do to, or pay the full cost of maintaining a RHEL compatible distro.
So now they either have to support Rocky Linux, and hope others do to, or pay the full cost of maintaining a RHEL compatible distro.
Looking at all your comments in this thread and you really don't know what you are talking about. Just spreading FUD.
RHEL7 is the upstream for AL2 and there is a LOT of heavy lifting done by AWS. Newer kernel, newer toolchain, newer glibc. They do live patching. They actually test all sorts of workloads before even a minor errata update. They took OpenSSL 1.0.2 through FIPS validation with NIST.
Just stop talking.
RHEL7 is the upstream for AL2 and there is a LOT of heavy lifting done by AWS. Newer kernel, newer toolchain, newer glibc. They do live patching. They actually test all sorts of workloads before even a minor errata update. They took OpenSSL 1.0.2 through FIPS validation with NIST.
Just stop talking.
> Before RH took over CentOS it was pretty much dying on the vine, releases were getting VERY slow, etc.
Remind me again, how long did it take RedHat to publish CentOS 8 images out to cloud providers or virtualbox? I think it was the very least 6 months behind the RedHat 8 release.
Only started using CentOS at 7, so not sure how much they used to lag behind releases beforehand.
But I've also had a dozen quality issues with RedHat software and services since they've been assimilated by IBM; so there's room for plenty of surprises.
Remind me again, how long did it take RedHat to publish CentOS 8 images out to cloud providers or virtualbox? I think it was the very least 6 months behind the RedHat 8 release.
Only started using CentOS at 7, so not sure how much they used to lag behind releases beforehand.
But I've also had a dozen quality issues with RedHat software and services since they've been assimilated by IBM; so there's room for plenty of surprises.
Wikipedia has both dates and the delay for each version:
https://en.wikipedia.org/wiki/CentOS#CentOS_releases
6.0 had a 242 day delay--I never really paid attention to why, but that was a very noticeable lag compared to their previous release schedule.
6.0 had a 242 day delay--I never really paid attention to why, but that was a very noticeable lag compared to their previous release schedule.
> I don't get it. CentOS "failed" because there were not enough community resources to sustain it
CentOS was a success story and that’s not why it “failed”.
I wish Rocky Linux the same success!
CentOS was a success story and that’s not why it “failed”.
I wish Rocky Linux the same success!
How was it a success story? Sure many used it, but the project wasn’t successful in terms of long term survival.
I think CentOS had failed had Redhat not maintained it.
Hopefully Rocky Linux will have better luck and more community involvement. It is likely, given the number of companies that have come to depend on CentOS, but I would not use Rocky Linux in production for critical system in the next two to five years.
I think CentOS had failed had Redhat not maintained it.
Hopefully Rocky Linux will have better luck and more community involvement. It is likely, given the number of companies that have come to depend on CentOS, but I would not use Rocky Linux in production for critical system in the next two to five years.
CentOS was huge in the cloud. Run by admins that want to config and forget. That 10 years support is nice. Boring and bullet proof is a feature (look at Debian). RedHat were a large contributor and also provided funding. When they pulled the plug the project didn’t survive and admins around the world cried.
Hopefully Rocky wont suffer the same fate being supported by the community from the outset.
But I might wait a bit before trying it :)
Hopefully Rocky wont suffer the same fate being supported by the community from the outset.
But I might wait a bit before trying it :)
> CentOS was huge in the cloud
There's no question about that, but I just don't equate a large install base with being successful. Had CentOS been successful, there would have been no Redhat involvement. CentOS failed the day Redhat took control of the project. After that it was just an version of RHEL without the subscription.
Companies wanted RHEL, but not pay for the development and maintenance. If this changes, and more companies are will to either donate to pay developers, or hire Rocky Linux develops, then maybe it will be successful. If it's just a few people slaving away in their free time, trying to maintain a parallel RHEL build, then I kinda doubt it's longevity.
There's no question about that, but I just don't equate a large install base with being successful. Had CentOS been successful, there would have been no Redhat involvement. CentOS failed the day Redhat took control of the project. After that it was just an version of RHEL without the subscription.
Companies wanted RHEL, but not pay for the development and maintenance. If this changes, and more companies are will to either donate to pay developers, or hire Rocky Linux develops, then maybe it will be successful. If it's just a few people slaving away in their free time, trying to maintain a parallel RHEL build, then I kinda doubt it's longevity.
Rocky Linux seems to have made a bigger deal of getting and advertising sponsors than I remember from CentOS. CentOS had a subtle link to donate, but that was it. Right off the bat, Rocky Linux had a nicer looking landing page and BIG sponsor logos. And I would absolutely have thrown $100 at CentOS to keep existing, it just never occurred to me that it was needed or would make a difference.
It's not the I just want something for nothing. I'll pay for good tools, but my time is money too and if I feel myself going down a high-touch sales process with stuff that feels like lock-in and DRM, I'm gonna check out and go for an alternative pretty quick. I used CentOS all the time because I was in the position of trying to support people running my software on Red Hat. And I never had to worry about talking to a sales person, or making sure my keys for the repository were everywhere they needed to be. I would have still used it, even if I had to enter my personal credit card to get an official ISO. Even once my company had a proper agreement and partnership with Red Hat, it was still a pain for me to get a system up and running without talking to IT, etc.
Red Hat seems to have lighter-weight licensing for such use cases now, so we'll see. But at this point I've already switched over to Ubuntu and I doubt Red Hat or Red Hat clones will ever fully recover to their former glory.
It's not the I just want something for nothing. I'll pay for good tools, but my time is money too and if I feel myself going down a high-touch sales process with stuff that feels like lock-in and DRM, I'm gonna check out and go for an alternative pretty quick. I used CentOS all the time because I was in the position of trying to support people running my software on Red Hat. And I never had to worry about talking to a sales person, or making sure my keys for the repository were everywhere they needed to be. I would have still used it, even if I had to enter my personal credit card to get an official ISO. Even once my company had a proper agreement and partnership with Red Hat, it was still a pain for me to get a system up and running without talking to IT, etc.
Red Hat seems to have lighter-weight licensing for such use cases now, so we'll see. But at this point I've already switched over to Ubuntu and I doubt Red Hat or Red Hat clones will ever fully recover to their former glory.
> How was it a success story? Sure many used it, but the project wasn’t successful in terms of long term survival.
CentOS 3, 4, 5, 6 and now 7 have all fulfilled their mission to be bit-clones of RHEL since 2004. As a CentOS user of every single one of them, they were a success and satisfied the needs of the community for 17 years. The first version of Ubuntu was released 6 months after CentOS 3.
CentOS 3, 4, 5, 6 and now 7 have all fulfilled their mission to be bit-clones of RHEL since 2004. As a CentOS user of every single one of them, they were a success and satisfied the needs of the community for 17 years. The first version of Ubuntu was released 6 months after CentOS 3.
CentOS failed because it's sponsor willed it to do so. When it went from being focused on long term stability to a rolling release, it was no longer in alignment with the reason it's users selected it. Since Rocky is being developed by some of the same people that did CentOS, I suspect that things will be just fine... after all, they benefit from being a downstream distribution.
> When it went from being focused on long term stability to a rolling release
The approach to "long term stability" has not changed whatsoever. The only difference is whether the updates are delivered as point-release bundles every 6 months, or incrementally. And it's supported for 5 years instead of 10, which is in-line with other free LTS distros.
The approach to "long term stability" has not changed whatsoever. The only difference is whether the updates are delivered as point-release bundles every 6 months, or incrementally. And it's supported for 5 years instead of 10, which is in-line with other free LTS distros.
Nope. CentOS stream is ahead of RHEL and has been pitched as a developent version of RHEL. Prior to the change, CentOS was basically a complete opensource RHEL with long term support. https://thenewstack.io/back-to-the-future-a-look-at-centos-s...
CentOS is used on a huge number of severs. That success became a threat the RedHat/IBM, as they were not getting customers signing up for their paid offerings. Hence, CentOS was killed off.
MoviePass had a large number of subscribers. It's very easy to be successful if you're giving something away for free and ignore sustainability.
Seven years is quite a long time in this area. It's possible that running exactly the CentOS-in-2014 model would work now even if it didn't then.
It's also possible that in 2014 CentOS would have found other ways to remain viable if Red Hat hadn't stepped in.
It's also possible that in 2014 CentOS would have found other ways to remain viable if Red Hat hadn't stepped in.
The home page[1] bends over backwards not to use the name "Red Hat", which renders the FAQ weirdly obtuse.
CentOS, which used to be downstream of Red Hat, has changed its strategy. Rocky Linux is looking to replace CentOS.
[1] https://rockylinux.org/
CentOS, which used to be downstream of Red Hat, has changed its strategy. Rocky Linux is looking to replace CentOS.
[1] https://rockylinux.org/
That's to avoid trademark infringement.
It used to be the same case with CentOS early on. Check out the "CentOS Overview" section in this version, with references to "a prominent North American Enterprise Linux vendor": https://web.archive.org/web/20050322010830/https://www.cento...
IMHO the proper purpose of trademarks should be to prevent consumer confusion. From that perspective, it’s absurd to have to dance around mentioning a trademark in a context where you’re explicitly stating that your product is different from it.
Tell that to Red Hat's lawyers [1]
[1] https://web.archive.org/web/20071114044958/http://www.centos...
[1] https://web.archive.org/web/20071114044958/http://www.centos...
I rather doubt IBM's lawyers are more friendly about trademark use.
Better safe than to wake up the Nazgul.
>> From that perspective, it’s absurd to have to dance around mentioning a trademark in a context where you’re explicitly stating that your product is different from it.
I don't think being a downstream release of RedHat very different from it. In fact, that's kind of the point.
I don't think being a downstream release of RedHat very different from it. In fact, that's kind of the point.
[deleted]
I'm responsible for fairly critical infrastructure and I've been putting all my bets on RHEL/CentOS these last 7 years.
So my plan is to just sit back and watch how all this develops until 2023. Use RHEL when possible, Fedora or CentOS 7. Worst case maybe CentOS Stream.
But there is no rush. Just sit back and let time decide which of these new contenders looks the best after 2 years.
So my plan is to just sit back and watch how all this develops until 2023. Use RHEL when possible, Fedora or CentOS 7. Worst case maybe CentOS Stream.
But there is no rush. Just sit back and let time decide which of these new contenders looks the best after 2 years.
Is RHEL compatibility a must? At this point it feels like the only community solution that has a long term track record is Debian.
I have government contractors specify versions of Red Hat and they will not support other distributions. Of course, these vendors also specify versions of Windows Server that Microsoft recommends you no longer run.
Yes, as others have pointed out already.
Partly you have enterprise software from big vendors like Dell or Alcatel that is packaged for RHEL.
You have hardware vendors like Dell and HPE who only offer support for supported OS. And yes I know CentOS is not a supported OS but its binary compatibility with RHEL meant you always had the option of migrating it to RHEL and get support.
Also I have government clients who require SLA with support contracts on the systems. In those cases, given the arguments above, including years of experience, RHEL has more weight than Canonical or Suse.
And besides all that, I'm actually a SElinux fanboy. I've had a lot of upgrade issues on Debian in the past and some clients even require certain yum features like history and rollback for patching.
That said, I tend to use whatever is the right tool. I tend to look at how a service is designed to decide which distro to use. Of course I prefer homogenous environments but for example I'd rather put a stable CentOS as a webfront/TLS terminator and a bleeding edge Fedora as an application server for things like Node or Python.
So in the future I would not rule out using Debian Stable as web front instead.
Partly you have enterprise software from big vendors like Dell or Alcatel that is packaged for RHEL.
You have hardware vendors like Dell and HPE who only offer support for supported OS. And yes I know CentOS is not a supported OS but its binary compatibility with RHEL meant you always had the option of migrating it to RHEL and get support.
Also I have government clients who require SLA with support contracts on the systems. In those cases, given the arguments above, including years of experience, RHEL has more weight than Canonical or Suse.
And besides all that, I'm actually a SElinux fanboy. I've had a lot of upgrade issues on Debian in the past and some clients even require certain yum features like history and rollback for patching.
That said, I tend to use whatever is the right tool. I tend to look at how a service is designed to decide which distro to use. Of course I prefer homogenous environments but for example I'd rather put a stable CentOS as a webfront/TLS terminator and a bleeding edge Fedora as an application server for things like Node or Python.
So in the future I would not rule out using Debian Stable as web front instead.
There is a whole smorgasbord of entrenched application servers/software that are targeted mainly at the RHEL ecosystem. These would have a very difficult time transitioning to non-RHEL.
How do updates/security updates look on C7/C8 until then? Assuming you don’t have any C8? Otherwise, stable updates are going to be problematic converting those to Stream, no? Also, I wouldn’t myself count on Red Hat not welching on that C7 2024 EOL date. I can’t see them not pushing that up honestly.
As far as whether CentOS was a success or not, of course it was a massive success. The circumstances of its unnaturally accelerated death don’t change its wild popularity/usage/prevalence.
As far as whether CentOS was a success or not, of course it was a massive success. The circumstances of its unnaturally accelerated death don’t change its wild popularity/usage/prevalence.
I have several Kubernetes clusters, Postgres and Mariadb clusters on CentOS 7. I'm not worried about updates, at least not until 2023. I am not going to put any money on Stream right now. It's just too unstable.
In fact, we're a RedHat partner so I'd rather migrate to RHEL. But of course management love me when I save money. :)
And I'm not worried about migrating C7 to a new distro either, as long as the cluster software is the same you can add new nodes and remove old ones gradually.
My knee jerk reaction to CentOS dying was horror but now I'm much more relaxed.
In fact, we're a RedHat partner so I'd rather migrate to RHEL. But of course management love me when I save money. :)
And I'm not worried about migrating C7 to a new distro either, as long as the cluster software is the same you can add new nodes and remove old ones gradually.
My knee jerk reaction to CentOS dying was horror but now I'm much more relaxed.
> How do updates/security updates look on C7/C8 until then? Assuming you don’t have any C8? Otherwise, stable updates are going to be problematic converting those to Stream, no? Also, I wouldn’t myself count on Red Hat not welching on that C7 2024 EOL date. I can’t see them not pushing that up honestly.
Given that C8 was supposed to be supported into 2029[0] and then they cut it to 2021, that does seem plausible enough...
[0] https://web.archive.org/web/20201101131417/https://wiki.cent...
Given that C8 was supposed to be supported into 2029[0] and then they cut it to 2021, that does seem plausible enough...
[0] https://web.archive.org/web/20201101131417/https://wiki.cent...
For anyone else that was missing context, there is an about section on the wiki[0]
> Rocky Linux is a community enterprise Operating System designed to be 100% bug-for-bug compatible with Enterprise Linux, now that CentOS has shifted direction.
[0] https://wiki.rockylinux.org/
> Rocky Linux is a community enterprise Operating System designed to be 100% bug-for-bug compatible with Enterprise Linux, now that CentOS has shifted direction.
[0] https://wiki.rockylinux.org/
What is enterprise operating system anyway?
* long term support (e.g. don't EOL something just because it's 5 years old, etc)
* immediate support (have someone you can call 24/7 if your system blows up)
* responsive support (have engineers on staff to close support tickets fairly quickly. This applies especially to bugfixes)
* good QA process so that you do not use your enterprise customers as free QA but pay people to test the product thoroughly before releasing it. This ties into the notion of long term support as something that stays in the QA matrix and receives bugfixes/updates.
* good documentation, in multiple languages
* A supporting ecosystem of certifications/training materials, so a business can hire people qualified to use the product
All of the above boils down to having people on staff doing all the boring, costly things that reduce the pain of companies using the software. Those things are not fun, so they tend not to happen consistently by open source volunteers, so they have to be paid for, hence "enterprise", as end users don't value these enough to pay for them over free but big businesses do.
* immediate support (have someone you can call 24/7 if your system blows up)
* responsive support (have engineers on staff to close support tickets fairly quickly. This applies especially to bugfixes)
* good QA process so that you do not use your enterprise customers as free QA but pay people to test the product thoroughly before releasing it. This ties into the notion of long term support as something that stays in the QA matrix and receives bugfixes/updates.
* good documentation, in multiple languages
* A supporting ecosystem of certifications/training materials, so a business can hire people qualified to use the product
All of the above boils down to having people on staff doing all the boring, costly things that reduce the pain of companies using the software. Those things are not fun, so they tend not to happen consistently by open source volunteers, so they have to be paid for, hence "enterprise", as end users don't value these enough to pay for them over free but big businesses do.
> e.g. don't EOL something just because it's 5 years old, etc
How about "Don't say at release time that you'll support something for 10 years, and then change your mind a year later and say that you'll be dropping support in a year?"
(Yeah, I'm still not over that)
How about "Don't say at release time that you'll support something for 10 years, and then change your mind a year later and say that you'll be dropping support in a year?"
(Yeah, I'm still not over that)
For the purposes of avoiding trademark infringement all RHEL clones go out of their way to avoid mentioning Red Hat, thusly Red Hat Enterprise Linux and all derived from its sources tend to get lumped together as “Enterprise Linux”
Sure, but what makes Rocky "enterprise"? Is it just marketing or can everything be "enterprise"? Is Windows not "enterprise"?
To me, being "enterprise" means shipping/supporting running enterprise functions on the OS. So things like network information services, databases, perhaps giving options of filesystems that can handle extremely large sizes, cluster support, added support from the vendor, etc.
Stuff that a typical desktop user probably won't run or use. Maybe they can if they really wanted to, but not the common use case.
>Is Windows not "enterprise"?
Funny you ask when Microsoft literally sells a version of Windows called "Windows Enterprise". https://www.microsoft.com/en-us/windowsforbusiness/compare
Find the differences between Windows 10 Home and Windows 10 Enterprise and that may help you understand what makes Rocky Linux also enterprise.
Stuff that a typical desktop user probably won't run or use. Maybe they can if they really wanted to, but not the common use case.
>Is Windows not "enterprise"?
Funny you ask when Microsoft literally sells a version of Windows called "Windows Enterprise". https://www.microsoft.com/en-us/windowsforbusiness/compare
Find the differences between Windows 10 Home and Windows 10 Enterprise and that may help you understand what makes Rocky Linux also enterprise.
Rocky aim for “bug for bug” compatibility with RHEL.
Red Hat target RHEL to a conservative, enterprise audience who look for a long lived well supported operating system, Rocky (and CentOS before it) court the same audience.
The primary difference being that RHEL is a premium product differentiated by the Red Hat support, training and documentation offering.
Support in so far as Red Hat will work with you to troubleshoot your OS issues, and issue custom patches to the packages they supply that you’re encountering issues with etc etc.
Training in that Red Hat offer many training courses and certifications in the usage and deployment of their many software packages and collections (System Administration, Troubleshooting & Diagnosis, High Availability Cluster administration etc etc)
If you look at Microsoft’s offering for Windows server you’ll see many parallels in the offerings that Red Hat present.
Red Hat target RHEL to a conservative, enterprise audience who look for a long lived well supported operating system, Rocky (and CentOS before it) court the same audience.
The primary difference being that RHEL is a premium product differentiated by the Red Hat support, training and documentation offering.
Support in so far as Red Hat will work with you to troubleshoot your OS issues, and issue custom patches to the packages they supply that you’re encountering issues with etc etc.
Training in that Red Hat offer many training courses and certifications in the usage and deployment of their many software packages and collections (System Administration, Troubleshooting & Diagnosis, High Availability Cluster administration etc etc)
If you look at Microsoft’s offering for Windows server you’ll see many parallels in the offerings that Red Hat present.
Being based on Red Hat by way of CentOS, who's full name initial-ized as RHEL is "Red Hat Enterprise Linux"
* Long-term stability and ABI guarantees. A software / hardware stack for a platform that isn't going to change or break underneath your feet while still receiving bugfixes and security updates for multiple years.
* A software stack that large third-party vendors of software and hardware are willing to certify their products against, e.g. SAP, databases, etc.
* Support contracts
* A software stack that large third-party vendors of software and hardware are willing to certify their products against, e.g. SAP, databases, etc.
* Support contracts
In my world: Something that comes with and 24/7 support contract.
RedHat
This looks awesome -- congrats to the team on the landmark milestone. I've been eagerly anticipating the release since their initial announcement.
I am left to wonder how seamless this migration will be in practice. I'm a heavy user of, for example, zfs-kmod, and would be thrilled to learn that I won't suddenly be on the hook for coordinating dkms build shenanigans across my ZoL machines.
Bonus points if they offer a direct upgrade path from CentOS -- although I'm not holding my breath on this one.
I am left to wonder how seamless this migration will be in practice. I'm a heavy user of, for example, zfs-kmod, and would be thrilled to learn that I won't suddenly be on the hook for coordinating dkms build shenanigans across my ZoL machines.
Bonus points if they offer a direct upgrade path from CentOS -- although I'm not holding my breath on this one.
In terms of speed it looks as if Oracle was the first to get 8.4 of their RHEL clone out of the door, Alma Linux came second and RockyLinux is still at 8.3
I'm optimistic that they will get faster!
I understand the desire to stick with the 10yrs of updates model, but it seems outdated with how fast things evolve. I am still waiting for Redhat to bring some details on how Stream will work long term.
We need to know what packages will be unstable. People seem to be held up that Redhat releases will be taken from Stream, making it a "beta" of things to come instead of a free RH. I personally see this no different than Fedora > CentOS release cycle. I welcome newer features hitting our enterprise boxes sooner than later.
I have read that it's also not a true rolling release, and instead will have minor stop gap channel releases along the way. Unless there is another big shake up like init vs systemD, it will be excellent to have an enterprise grade rolling release option for long lived (non-cattle) servers. Updating our fleet from 5 to 6, 6 to 7 was painful...
Currently moved most of my Dev servers to Stream, and I am excluding a few packages from rolling with DNF-Automatic. Will this stay supported?
We need to know what packages will be unstable. People seem to be held up that Redhat releases will be taken from Stream, making it a "beta" of things to come instead of a free RH. I personally see this no different than Fedora > CentOS release cycle. I welcome newer features hitting our enterprise boxes sooner than later.
I have read that it's also not a true rolling release, and instead will have minor stop gap channel releases along the way. Unless there is another big shake up like init vs systemD, it will be excellent to have an enterprise grade rolling release option for long lived (non-cattle) servers. Updating our fleet from 5 to 6, 6 to 7 was painful...
Currently moved most of my Dev servers to Stream, and I am excluding a few packages from rolling with DNF-Automatic. Will this stay supported?
CentOS Stream is rolling between minor releases, not between major releases. So e.g. a CentOS Stream 8 system won't roll over to CentOS Stream 9.
I do believe they're working on making major version upgrades easier, but they would still not be automatic.
None of the packages should be "unstable" barring any major bugs, (or maybe proprietary kernel modules that expect a very specific kernel version).
I do believe they're working on making major version upgrades easier, but they would still not be automatic.
None of the packages should be "unstable" barring any major bugs, (or maybe proprietary kernel modules that expect a very specific kernel version).
IMHO: For those who want more frequent upgrades, then I would say a container-based solution is a good fit. Then the container don’t need to care if the underlying host has very old packages.
If I was starting "another CentOS" I would ensure that companies above a certain amount of revenue had to pay (either in licensing fees or in engineer time). Non-corporate and FOSS uses should remain free. The reason I suggest this is differences in user engagement.
It's hard to get community support for projects that are business-focused. A project that is very general-purpose can get quite a few volunteers or donations. But if businesses are the primary users, the project often gets little to no support from those businesses, and very infrequently any contributed code or support. Getting my own company to donate to an OSS project that they heavily depend on is like pulling teeth. Which is ridiculous, because without that project they'd be paying a lot more for proprietary software!
It's hard to get community support for projects that are business-focused. A project that is very general-purpose can get quite a few volunteers or donations. But if businesses are the primary users, the project often gets little to no support from those businesses, and very infrequently any contributed code or support. Getting my own company to donate to an OSS project that they heavily depend on is like pulling teeth. Which is ridiculous, because without that project they'd be paying a lot more for proprietary software!
I mean that kind of defeats the point of the effort and FOSS in general.
If you need to pay you just buy RedHat.
CentOS reached ubiquity by being free. Many large corporations already have competent system admins managing large installations/clusters that RedHat offered nothing worth purchasing over CentOS.
Another approach to support is probably better rather than becoming RedHat 0.1
If you need to pay you just buy RedHat.
CentOS reached ubiquity by being free. Many large corporations already have competent system admins managing large installations/clusters that RedHat offered nothing worth purchasing over CentOS.
Another approach to support is probably better rather than becoming RedHat 0.1
I used to support a corporate CentOS fork for years. I think I built something like 10,000 custom packages over several releases. If I found a bug and wanted to submit a code fix, I couldn't just submit it, because corporate wouldn't allow us to "release intellectual property". If I wanted to donate money I had to do it from my own wallet, because the company wouldn't approve the expense.
But if our only legal option (given our size) was to pay one flat fee for infinite installs, or one flat fee per N nodes or something, the company would have approved that, because we needed to use something RHEL-like. If it's totally free, the company won't help at all. I think a few large companies could probably provide most of the funding necessary for the project, and still be ridiculously cheaper than RHEL.
I'd only do this for business-focused projects, because of the tendency for those "users" not to contribute anything back. FOSS only thrives when people contribute. Otherwise you're a one-man software welfare program.
But if our only legal option (given our size) was to pay one flat fee for infinite installs, or one flat fee per N nodes or something, the company would have approved that, because we needed to use something RHEL-like. If it's totally free, the company won't help at all. I think a few large companies could probably provide most of the funding necessary for the project, and still be ridiculously cheaper than RHEL.
I'd only do this for business-focused projects, because of the tendency for those "users" not to contribute anything back. FOSS only thrives when people contribute. Otherwise you're a one-man software welfare program.
> If I was starting "another CentOS" I would ensure that companies above a certain amount of revenue had to pay (either in licensing fees or in engineer time). Non-corporate and FOSS uses should remain free. The reason I suggest this is differences in user engagement.
That's just RHEL; https://www.redhat.com/en/blog/extending-no-cost-red-hat-ent... for FOSS and https://developers.redhat.com/blog/2021/02/10/how-to-activat... for non-corporate users.
That's just RHEL; https://www.redhat.com/en/blog/extending-no-cost-red-hat-ent... for FOSS and https://developers.redhat.com/blog/2021/02/10/how-to-activat... for non-corporate users.
We run an HPC cluster on CentOS 8 and looking at moving to Rocky but I wonder if we shouldn’t just jump to Ubuntu or OpenSUSE. The main thing keeping us is that kickstart works pretty well over PXE with dnsmasq and I never found good docs for the equivalents elsewhere.
PXE for Ubuntu is a nightmare compared to centos, but it is doable. It took me about four months (on and off with other responsibilities) to figure it out... It's been a while but iirc the biggest trick is to use the "legacy" installer iso.
Yeah, I have a PXE install system for Ubuntu too, built on the text mode installer. They are really pushing people to use MAAS, for a while the legacy installer for 20.04 wasn't released, and I thought I'd have to change, but it's out now. We'll see if they still have it for 22.04. :fingers crossed:
I really wantedan excuse to PXE alpine Linux, but I couldn't figure out how to bootstrap a post-pxe script. Which I'm sure is super easy and I just missed a really obvious strategy about Linux sysadminning, the docs anyway do not provide easy to understand guidance on that, unfortunately, and I have no idea where to go to get community support for quick one-off questions.
I expect PXE booting hasn't changed much in 15 years, so you can go find The Linux Documentation Project's HOWTOs on PXE and network booting and it should be about the same now. After that you just need to learn how to extract and create an initrd, and how the init system works to trace the execution of your network boot system.
This is also where shell script-based init systems rock. It's pretty easy to figure out how things get executed in an unusual environment like a network-installer because you can just open up the files used by your installer and follow them. To figure out how systemd might work in a PXE environment you'll need to find the version of systemd and then go download the source code and start reading... Might want to keep a notebook as you go.
This is also where shell script-based init systems rock. It's pretty easy to figure out how things get executed in an unusual environment like a network-installer because you can just open up the files used by your installer and follow them. To figure out how systemd might work in a PXE environment you'll need to find the version of systemd and then go download the source code and start reading... Might want to keep a notebook as you go.
Hell, I wrote my own PXE server (from scratch, starting with UDP primitives for DHCP and TFTP) that could PXE boot and track/log the status of several concurrently PXE booting servers in a rack. That sounds crazy, but its' surprisingly easy in Elixir. It was arguably easier (and more reproducible) to do this than to figure out how to configure, say, isc-dhcpd to give out specific ip addresses based on a mac-ip lookup table you put on s3, log the progress of each client, and then ninja out isc-dhcpcd to not exist anymore once you've provisioned the rack (and then figure out what to do if you had an error)... you can imagine the nightmarish statefulness problems with system config files all over the place.
> learn how to extract and create an initrd
that was the hard part. CentOS and Ubuntu (poorly documented) give you a specific bootstrapping pathway that would kick in the initial installer, and at the other end you would have the system as you wanted it. The PXE instructions for alpine drops you into a shell. I couldn't figure out how to create and launch a "script" that would kick off the software installation beyond the basics. Like I said, it's probably easy, just not my wheelhouse.
> learn how to extract and create an initrd
that was the hard part. CentOS and Ubuntu (poorly documented) give you a specific bootstrapping pathway that would kick in the initial installer, and at the other end you would have the system as you wanted it. The PXE instructions for alpine drops you into a shell. I couldn't figure out how to create and launch a "script" that would kick off the software installation beyond the basics. Like I said, it's probably easy, just not my wheelhouse.
Ah, nice. The installer mess was one of the reasons I steered clear of 20.04. (Along with the netplan vs cloudinit dumpster fire, and Canonical's rabid pro-snap stance).
Might be worth taking another look if the old installer is back again.
Might be worth taking another look if the old installer is back again.
Right, I forgot that I had tried nfsroot with Ubuntu which surprisingly much easier to get started. I like the idea in a sibling thread of your own pxe server: I switched from dhcpd to dnsmasq a while ago just because it was a lot simpler to get working.
>> We run an HPC cluster on CentOS 8 and looking at moving to Rocky but I wonder if we shouldn’t just jump to Ubuntu or OpenSUSE.
Sounds like an installation that might be able to afford RedHat. In fact, had that been the case already there would be no need to change anything now.
Sounds like an installation that might be able to afford RedHat. In fact, had that been the case already there would be no need to change anything now.
Check out FAI [0] (Fully Automatic Installation) for something similar to kickstart but for Debian/Ubuntu. When you get into it, it is quite nice to configure.
[0] https://fai-project.org/
[0] https://fai-project.org/
It turns out Ubuntu can be used with kickstart
https://help.ubuntu.com/community/KickstartCompatibility
https://help.ubuntu.com/community/KickstartCompatibility
I would stay away from Ubuntu. IMHO, Canonical has too much of a “throw everything at the wall to see if it sticks” approach.
i want to second this.
ubuntu has this horrible habit of re-inventing stuff that works well and then push it to users and customer, only to deprecate that in the next release.
ubuntu has this horrible habit of re-inventing stuff that works well and then push it to users and customer, only to deprecate that in the next release.
OpenSUSE is a good option, as is waiting for a stable Rocky release. Ubuntu is fine if your definition of HPC is actually mostly focused on data science and ML. For classical HPC you probably have to watch out for whatever commercial software you have and their support requirements, many proprietary packages are RPM only.
If you're tied to software that is used on RHEL or release in sync with RHEL I'd say stick with CentOS-like distributions - but if you're not I'd say that moving to Ubuntu LTS doesn't seem that bad of an option.
If you need LTS would Debian not be a better choice for servers?
Debian and Ubuntu have the same LTS policies, but Ubuntu has the option of paid "extended LTS".
I won't comment on the experience of using Ubuntu vs. Debian on servers because I don't have any
I won't comment on the experience of using Ubuntu vs. Debian on servers because I don't have any
The main advantage with Ubuntu is “everyone uses it” so there’s almost certainly a setup for it. Debian may have a bit more hoops to jump through.
ISOs are a bare minimum of course, but what about official container images? Personally I'd like to see how it works with existing package repos that are out there.
EDIT: tried unofficial image and it seems you can use stuff from mirror.centos.org if you mimic Centos by modifying /etc/dnf/vars/contentdir and /etc/dnf/vars/cloudsigdist. Use --nogpgcheck if necessary.
EDIT: tried unofficial image and it seems you can use stuff from mirror.centos.org if you mimic Centos by modifying /etc/dnf/vars/contentdir and /etc/dnf/vars/cloudsigdist. Use --nogpgcheck if necessary.
Frankly, since my company is pushing hard for a move away from the data center, we're really not talking about moving from CentOS 7 to e.g. Rocky any more anyway; we're talking about moving from CentOS 7 to Amazon Linux 2.
This was released back at the end of April.
https://rockylinux.org/news/rocky-linux-8-3-rc1-release/
https://rockylinux.org/news/rocky-linux-8-3-rc1-release/
Congratulations to the Rocky Linux team. I hope this is a sign of things to come
We jumped off the CentOS boat after their statement and switched to OpenSuSe, no regrets so far, smooth sailing.
Good to see this project moving along, and if the team is monitoring this, give Brian a smack from me :P
let’s hope the release isn’t rocky
What is the HN community's perception of this? Is AlmaLinux a good choice? Do you believe Rocky Linux will succeed?