Rocky Linux releases its first release candidate (opens in new tab)

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:

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.

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.

If you need LTS would Debian not be a better choice for servers?

> 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

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.

You can just go to the RHEL docs. https://access.redhat.com/documentation/en-us/red_hat_enterp...

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.

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.

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.

> 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.

> 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.

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.

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.

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.

> 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...

* 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.

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”

* 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

In my world: Something that comes with and 24/7 support contract.

RedHat

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.

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.