Please cut them some slack for this. It is not like this is the rc for the next version of a long running distribution. It is the first ever release using a from scratch implemented build infrastructure.

People have been treating Rocky as a done deal, a ready to go CentOS replacement for months. It will be very soon, hopefully, but the developers haven’t claimed to ready.

Using Rocky Linux as a basis for a long term production system is still a few months or perhaps a year into the future, and people need to let the team get everything in place before complaing that they can’t seemlessly move from one free OS to another.

I'd say this is pretty fair considering that a fair amount of serious issues can be expected for the first ever release of a distro.

But isn't this just Red Hat with the name changed?

Kinda sorta yeah. But I guess the Rocky project still needs to set up their own build servers, CI/CD, package repositories and that kinda stuff.

And yet, ironically people like it better than CentOS stream?

People are making such a big fuss about CentOS getting slightly closer to Fedora.

That's not what this is about.

The scientific community cannot run a distribution with "unneeded" updates to libraries.

That goes for other organizations as well.

That's for those who can't pay for RHEL subscriptions and they have such critical experiments going on that getting updates earlier than RedHat screws them up?

They can surely opt out of updating automatically and only apply updates after reading the changelogs.

In many cases systems run out-of-tree drivers like Lustre, MOFED, NVIDIA etc. that tend to break due to kernel internal API changes. Yes, also for changes incorporated into minor RHEL releases like X.Y -> X.(Y+1), though not for kernel security updates within a minor X.Y release. At the same time they might need to keep up to date wrt security updates. So if CentOS stream implies that the kernel will randomly get an API-breaking update, with no security support for the previous version, that is not workable.

I always found that to be a little weird. Why is scientific projects that dependent on even minor version changes?

Isn’t that normally an indication that there’s something horribly wrong in your code?

The reason they don't want to do anything other than security updates, and sometimes not even that, is because they need consistency across calculations over time.

This might be a poor example, but lets say an error was found in a computation in a library, for example a rounding error or something, in that case, more often than not, the community will rather live with the known error and have consistency instead.

Ideally, yes, but in my experience it's more often due to software management processes being, well, non-existent, and whatever exact version that is 'required' is the version that the original developer used and no attention whatsoever has been given to portability or even testing on other versions.

Luckily containers have become quite popular in the HPC world, to isolate such 'tricky' applications from the host OS.

Won’t that make reproducing results difficult? I mean it seems like a result won’t be worth much if it’s only reproducable with a specific version of say glibc from five years ago.

Over the cause of one experiment sure, I can see why you’d like to know the calculation are done identically. I just question the validity/usefulness of a calculation that can only be repeated on one version of some library. Surely the overall result should remain the same.

There are always inconsistencies in the scientific world:

* https://en.wikipedia.org/wiki/Fudge_factor

A good portion of experimentalists' time is probably spent in trying to figure just how badly they've messed their experiments as compared to reality. Major discoveries are sometimes based on teasing apart those differences:

* https://en.wikipedia.org/wiki/Muon_g-2

In my EE studies we had a specific course just in examining the limitations of (digital) numbers:

* https://en.wikipedia.org/wiki/Numerical_analysis

* https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.h...

Stream type systems are pretty much a non-starter in high security and safety critical applications.

Personally, I care very little about the technical angle (yes, Stream is probably a fine product) and very much about Red Hat reneging (yanking CentOS 8 from 2029 to 2021).

"…meaning it will not be tested nor documented."

Likely, you'll still be able to do it.

You will. Considering how easy it is to convert between distros with DNF (I've often wished APT had distro-sync) I'd be surprised if there were any real issues upgrading; it's most likely just left to the user's expertise to fix things should any issues arise.

Exactly this. No reason to think it shouldn't work, but probably a better use of folks' time doing something else than trying to troubleshoot this very corner case.

It's easy to convert between distros based on RH. The package manager is coincidental. You wouldn't have as smooth conversion between SL, Fedora, and Suse for example.

I wouldn't say the package manager is entirely coincidental; distro-sync and transaction support makes it easier than it would be if you did the equivalent operation using APT.

I'm pretty sure I could convert RHEL into Fedora and vice versa (probably not Suse though, it's too different), but I admit it's not going to be as easy as switching between EL distros.