Rocky Linux releases its first release candidate
rockylinux.org
rockylinux.org
What is the HN community's perception of this? Is AlmaLinux a good choice? Do you believe Rocky Linux will succeed?
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.
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.
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.
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
I'm assuming the Centos 8 install instructions for e.g. GitLab also work with Rocky Linux? Conda/Micromamba definitely should.
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.
In all likelihood it'll be as solid as it's ever been.
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.
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.
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.
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.
AWS are a sponsor of Rocky Linux
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.
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.
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.
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.
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.
It's also possible that in 2014 CentOS would have found other ways to remain viable if Red Hat hadn't stepped in.
CentOS was a success story and that’s not why it “failed”.
I wish Rocky Linux the same success!
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.
Hopefully Rocky wont suffer the same fate being supported by the community from the outset.
But I might wait a bit before trying it :)
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.
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.
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.
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 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.
(Nix is a package manager for Linux.)
In fairness, that's kind of the point of CentOS et al.
Same story as an Ubuntu user. Actually, doesn't everyone go to the Arch wiki? :D
CentOS, which used to be downstream of Red Hat, has changed its strategy. Rocky Linux is looking to replace CentOS.
[1] https://web.archive.org/web/20071114044958/http://www.centos...
I don't think being a downstream release of RedHat very different from it. In fact, that's kind of the point.
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.
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.
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.
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...
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.
> 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.
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.
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.
* 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
* 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.
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)
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.
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?
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).
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!
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
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.
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.
I won't comment on the experience of using Ubuntu vs. Debian on servers because I don't have any
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.
> 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.
Might be worth taking another look if the old installer is back again.
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.
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.
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.