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.
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.
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.
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.
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.
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.
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:
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.
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).
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.
So are Red Hat source packages still available? What incentive does IBM have to make them available? The source code of the applications, sure. But why the source rpms?
Why doesn't Amazon and friends just make a dist that is not tied to Red Hat?
> Why doesn't Amazon and friends just make a dist that is not tied to Red Hat?
Because RHEL is a known distro many vendors test for and allow. Having compatibility with it is a huge boon for adoption, since you can just use lots of software. If you do a distro from scratch, you're on your own.
Amazon is already releasing Amazon Linux AMIs which are similar to rhel, but you're not supposed to expect any compatibility. They're branching the behaviour off when needed.
It's hard to know design about compatibility between Amazon Linux and RHEL. It seems that Amazon Linux no longer targets full RHEL/Fedora compatible, but it still support EPEL. Anyone know good documentation?
Some vendors that didn’t support Ubuntu now do after the CentOS disaster and I’m much happier now. But I feel for those that don’t want or can’t use Debian based distros.
It's healthy for everyone to have a competition. I want successful Debian even though I'm running CentOS these days.
But really, it doesn't look like you're in the market for it. Some solutions welcome slow releases - many users will list that as a benefit. Even more these days with containerised apps.
Recompile src-files and exchange a branding is not really what i call "competition"
>I want successful Debian
Debian IS successful.
>But really, it doesn't look like you're in the market for it. Some solutions welcome slow releases
That's not what is said nor meant, if for example RHEL 8.2 was released it took CentOS sometimes up to 6 month to release their 8.2 counterpart, in the meantime the newest patch (let's say for OracleDB) is just compatible/certified for 8.2, but you sit for 6 month on a centos 8.1.
But maybe your not in the market of having the latest patch for 3rd party software.
> in the meantime the newest patch (let's say for OracleDB) is just compatible/certified for 8.2, but you sit for 6 month on a centos 8.1.
Is this a real scenario? Can you point to a product officially compatible with CentOS, with a patch released only for rhel 8.2 and ignoring CentOS 8.1?
If you pay for Oracle, why would you run on promises? I get that the lag is disappointing, but "compatible with RHEL" is not the same as "compatible with RHEL and distributions that claim compatibility with it".
Look i just said there where problems with that lag, and yes true, if you need a OracleDb you will use OracleLinux and probably OracleHardware (because free support for OracleLinux).
> but "compatible with RHEL" is not the same as "compatible with RHEL and distributions that claim compatibility with it".
That was the promise of CentOS 100% compatible with RHEL bug for bug.
RHEL is free for up to 16 instances for individuals not working in a team. This is frequently ignored, but it says so crystal clear, black on white, on the developer program terms page: https://developers.redhat.com/terms-and-conditions
> The Individual Developer Subscriptions are unsupported, intended for your individual use in your personal capacity and are not intended or supported for any other purpose. If you are interested in the Red Hat Developer Subscriptions for Teams other terms apply and please contact your Red Hat sales associate.
> [...]
> By accepting the Program Terms, you represent that you are acting on your own personal behalf and not as a representative or on behalf of an entity [...]
I would love for my vendors to support Debian but they won’t. Hell, it was hard enough to get them to update their systems to RHEL7 much less move to a totally different distro.
A significant number of Enterprise-oriented 3rd party vendors directly support SLES with their products. It's possible with the new release of openSUSE 15.3 being a bit-clone of SLES 15sp3 that we'll see an uptick in the general FOSS world, time will tell.
You can convert between any RHEL-like distro by changing your repos, swapping/removing a few key packages (release, branding, subscription-manager certs if converting from RHEL) and then running distro-sync to make sure your other packages match your repositories. This can be done transactionally via the "shell" subcommand which allows you to run multiple commands in a single transaction.
Also take a look at their principal sponsors list. It includes AWS and Google cloud. They would both have an invested interest in keeping a supported free RHEL clone around.
Windows 10 had its sunset date announced back when it launched. Most versions of Windows have only come with a two year support life cycle. The LTSC lifecycle has been halved recently, but the 2019 LTSC release will still get 10 years of support like before.
Windows has, before Windows 10, had a support cycle of 5 years for feature updates and another 5 for maintenance.
XP was supported past that term for (too) long because people refused to or were unable to switch, and 7 has befallen a similar faith.
The news media recently found the support cycle page again after the leaks about the upcoming Windows 11 release, but none of this should be a surprise for people who need to look into long term support for Windows.
The difference here, or course, is that a big company like Microsoft is more likely to stick around than a small, open source project. They currently don't have any plans to stop support, but who knows what the future may bring. Covid is a stark reminder of how the world can change in just a few months.
”I mean if I install rocky Linux 8.4 will I still have a supported OS at 2029?“
That question is impossible to answer with 100% certainty. There are no 100% guarantees. It all comes down to how much you trust the Rocky Linux crew and also how much you trust the project’s ability to raise the necessary funds.
There is also the option to buy licenses for Red Hat Linux.
> A. How easy will it be for the unlucky people that have installed Centos 8 to convert it to rocky Linux?
The AlmaLinux team (another RHEL8 clone created by CloudLinux in the wake of the CentOS news, already released/available) has created a tool to do the conversion. Rocky should have no problem, if Alma can do it Rocky can do it.
You should also look into AlmaLinux (https://almalinux.org) which released 8.4 Stable quite a while ago already. Super experienced team and they also established a true non-profit to avoid what happened to CentOS in the past.
Seconding this. As someone who's depended on CentOS for years, I like how AlmaLinux has been set up so far. The fact that it's the CloudLinux people who made this is also a plus.
Personally the reason I use a RHEL based distro on servers is due to third party tools that target RHEL, and also I am heavily invested in a personal knowledge base on the RHEL specifics such as how they implement SElinux, etc. Therefore I run Fedora on my personal workstations so that when a new release of RHEL comes out, I already know it.
But now I'm seeing more items target Ubuntu first. For example a colleague at work wanted me to get an overview of Swift -- for the longest time I couldn't get it for RHEL or Fedora, but could for Ubuntu. And a number of tutorial articles assume using Debian or Ubuntu. My main issue with Debian based distros is the package manager doesn't track enough metadata about packages (a lot is stored in a sequential log file that can get purged/rotated out, but isn't in a package database, such as install date/history/rollback information). That, and packages on RHEL / Fedora tend to install without needing input (they have sane defaults that you customize after), they also don't auto-enable when installing (so you have more control), etc.
> Swift -- for the longest time I couldn't get it for RHEL or Fedora, but could for Ubuntu
Long before it became available on Ubuntu you could very easily run it on Arch. Same for many other applications. It's pretty sad that a bunch of pimply children managed to meme it into a thing that a civilized person shouldn't even mention these days, because the software availability situation is above everything else out there (thanks to AUR and incredibly simple package format — you can write a proper package in a few minutes).
Some people prefer stability over software availability. Arch leaves much to be desired given it's lack of tooling that's been available for years for other distributions. It's an hobbyist project all along.
I run Fedora on both my desktop and home server. If/when the server goes sideways I'll choose something RHEL based, It's changed from something that I tinker on to something that I depend on for Plex, torrent seeding, ad blocking, and more recently, hosting game servers.
I wonder what CERN going to do next. Which distro will they choose after CentOS 7? Rocky linux, Ubuntu, or go back to Scientific Linux. Lots of HEP softwares have pre-compiled packages for CentOS and Ubuntu. CERN has been pretty quiet in past several months.
67 comments
[ 3.6 ms ] story [ 135 ms ] threadI installed it on a VM for a quick look and promising so far.
Why does this distro make it hard for people to use it?
Likely, you'll still be able to do it.
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.
People are making such a big fuss about CentOS getting slightly closer to Fedora.
The scientific community cannot run a distribution with "unneeded" updates to libraries.
That goes for other organizations as well.
They can surely opt out of updating automatically and only apply updates after reading the changelogs.
Isn’t that normally an indication that there’s something horribly wrong in your code?
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.
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.
* 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...
Luckily containers have become quite popular in the HPC world, to isolate such 'tricky' applications from the host OS.
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.
Please use FreeBSD or OpenBSD.
Why doesn't Amazon and friends just make a dist that is not tied to Red Hat?
Because RHEL is a known distro many vendors test for and allow. Having compatibility with it is a huge boon for adoption, since you can just use lots of software. If you do a distro from scratch, you're on your own.
Why? CentOS was already a terrible choice, artificially slow release compared to RHEL, now you can choose from:
-OracleLinux (pretty good..and no i don't like oracle itself...but the Wallpaper is extremely beautiful..UEK is cool too)
-RHEL (free for up to 16 instances)
-That new one with A
-That Chinese one with the UNIX certification
.....and so on
But really, it doesn't look like you're in the market for it. Some solutions welcome slow releases - many users will list that as a benefit. Even more these days with containerised apps.
Recompile src-files and exchange a branding is not really what i call "competition"
>I want successful Debian
Debian IS successful.
>But really, it doesn't look like you're in the market for it. Some solutions welcome slow releases
That's not what is said nor meant, if for example RHEL 8.2 was released it took CentOS sometimes up to 6 month to release their 8.2 counterpart, in the meantime the newest patch (let's say for OracleDB) is just compatible/certified for 8.2, but you sit for 6 month on a centos 8.1.
But maybe your not in the market of having the latest patch for 3rd party software.
Is this a real scenario? Can you point to a product officially compatible with CentOS, with a patch released only for rhel 8.2 and ignoring CentOS 8.1?
>Minimum supported versions: Red Hat Enterprise Linux 8.2: 4.18.0-193.el8.x86_64 or later
https://docs.oracle.com/en/database/oracle/oracle-database/2...
>product officially compatible with CentOS,
Ehh, that's the point of CentOS being the same as RHEL...bug for bug
> but "compatible with RHEL" is not the same as "compatible with RHEL and distributions that claim compatibility with it".
That was the promise of CentOS 100% compatible with RHEL bug for bug.
RHEL is free for up to 16 instances for individuals not working in a team. This is frequently ignored, but it says so crystal clear, black on white, on the developer program terms page: https://developers.redhat.com/terms-and-conditions
> The Individual Developer Subscriptions are unsupported, intended for your individual use in your personal capacity and are not intended or supported for any other purpose. If you are interested in the Red Hat Developer Subscriptions for Teams other terms apply and please contact your Red Hat sales associate.
> [...]
> By accepting the Program Terms, you represent that you are acting on your own personal behalf and not as a representative or on behalf of an entity [...]
A. How easy will it be for the unlucky people that have installed Centos 8 to convert it to rocky Linux?
B. Will rocky Linux fulfill its promises? I mean if I install rocky Linux 8.4 will I still have a supported OS at 2029?
YUM/DNF can do the whole thing without much fuss.
I'm not sure that's a fair question to a new project. If you asked that recently about Windows 10, you'd have a different answer than today.
But seriously, Rocky was started by the person doing CentOS before and unhappy with changes. They're at the very least not planning to go away.
Windows has, before Windows 10, had a support cycle of 5 years for feature updates and another 5 for maintenance. XP was supported past that term for (too) long because people refused to or were unable to switch, and 7 has befallen a similar faith.
The news media recently found the support cycle page again after the leaks about the upcoming Windows 11 release, but none of this should be a surprise for people who need to look into long term support for Windows.
The difference here, or course, is that a big company like Microsoft is more likely to stick around than a small, open source project. They currently don't have any plans to stop support, but who knows what the future may bring. Covid is a stark reminder of how the world can change in just a few months.
That question is impossible to answer with 100% certainty. There are no 100% guarantees. It all comes down to how much you trust the Rocky Linux crew and also how much you trust the project’s ability to raise the necessary funds.
There is also the option to buy licenses for Red Hat Linux.
The AlmaLinux team (another RHEL8 clone created by CloudLinux in the wake of the CentOS news, already released/available) has created a tool to do the conversion. Rocky should have no problem, if Alma can do it Rocky can do it.
https://github.com/AlmaLinux/almalinux-deploy
https://github.com/containers/toolbox
On my laptop and desktop, I run Fedora and Arch, though, so keeping that consistent with my servers might be nice.
For that reason, I’ve been thinking of kicking the tires on Debian testing / sid for the laptop.
But now I'm seeing more items target Ubuntu first. For example a colleague at work wanted me to get an overview of Swift -- for the longest time I couldn't get it for RHEL or Fedora, but could for Ubuntu. And a number of tutorial articles assume using Debian or Ubuntu. My main issue with Debian based distros is the package manager doesn't track enough metadata about packages (a lot is stored in a sequential log file that can get purged/rotated out, but isn't in a package database, such as install date/history/rollback information). That, and packages on RHEL / Fedora tend to install without needing input (they have sane defaults that you customize after), they also don't auto-enable when installing (so you have more control), etc.
Long before it became available on Ubuntu you could very easily run it on Arch. Same for many other applications. It's pretty sad that a bunch of pimply children managed to meme it into a thing that a civilized person shouldn't even mention these days, because the software availability situation is above everything else out there (thanks to AUR and incredibly simple package format — you can write a proper package in a few minutes).