As RHEL clones hit version 10, Rocky and Alma chart diverging paths Rocky Linux 10 has caught up to the other high-profile RHELatives, but gaps between them are widening, both in tech and other ways. Rocky Linux 10 "Red Quartz" has reached general availability. The release notes describe what's new, such as support for RISC-V computers. Balancing that, this version only supports the Raspberry …
I spat out my coffee at that!
That said, I have used LLMs as a lazy way to jog my memory for tasks I don't do frequently enough to have them in working memory. They are very good for this, as long as you understand that they can and will hallucinate non-existent command line arguments. Like the Russians say, trust, but verify.
> users booting SunOS remember seeing
A classic. :-) It appeared in other places too.
Nope. I _think_ it's doing
superscript plus
subscript plus
normal plus
and replacing that with
superscript decimal point
subscript plus
normal plus
superscript plus
subscript decimal point
normal plus
then
superscript plus
subscript plus
decimal point
The effect is a tiny row of twinkling stars. It's quite well done and the impression is magical fairy sparkles or something.
Not what I expected in a Linux distro in a sober suit, but hey.
The fact that you traced this down for some reason reminded me of the ancient days when I ripped apart that weird Applesoft BASIC code to figure out how they did that little inch-worm making its way to the bitten apple on my ][.
Yes, I'm that old.
Also UCSD Pascal booting up.
AFAIK the record for the number of different time's-a-wasting features must belong to Windows. Microsoft must have an entire coloured pencil dept devoted to designing them.
Compaq RAID controller powering up the spindle-synced discs in a RAID set, one-by-one, so as not to overload the power supply. Tou got a spinning /-\-|-/ for every disc currently powered up, until they all were running.
I've been a RedHat user since RH4.1 (not RHEL; the original RH4.1). I got it on the InfoMagic CDs (remember them?!). Then I went to CentOS, then Rocky. It really helped when the US banking industry moved to Linux 'cos (RHAS then) RHEL was the most commonly picked distro, and I knew that.
But now RedHat is making it too hard for the copies. I don't need to admin servers professionally any more, so I don't _need_ compatibility, but the delays in releases and patches as those teams work hard to replicate RedHat's work are a little concerning.
So maybe it's time to switch; possibly to Debian since I use that on my desktop already.
Oh well. It's been a good run (almost 30 years!) but I think it's time to call "time".
You may as well go to CentOS stream. Uses the nearly the same commands as what you are using now. Post updates faster than Oracle, rocky or alma. Heck, ¡¡¡It posts updates faster than even RHEL too!!!
And since nowadays you do not need compatibility...
> So maybe it's time to switch
Yup, I started on RH around then as well. At that time the level of "polish" -- as in, more like "less encrusted in mud" -- than things like Slackware was apparent.
If you like RPM etc. then there are options.
- openSUSE is pretty good if you like something conservative and sane;
- Mageia or openMandriva if you want a fairly good KDE desktop;
- If you like APT as well as RPM and want a rolling distro, then PC Linux OS
Thanks for the link to your older article, Liam. I saw the amd-64-v3 and had no idea what it meant. A google search was not enlightening. The cpuinfo command on my old system includes
CPU family: 21
Model: 1
Model name: AMD FX(tm)-8150 Eight-Core Processor
Stepping: 2
none of which is a "version". I did push harder on Google search and it popped up an AI reply that said the V3 comes from the Ryzen 3rd generation cores. So, my perfectly good computer is not new enough to run these Linux versions - FX family is too old.
If you don't want to download and run the (short and harmless) script above, then if your current OS is Linux and is recent enough, you may be able to get a quick answer from running the following command:
And at this point I don't post often enough to have a badge and hence access to the code tag, but I'm sure you can interpret :)
<code> /lib64/ld-linux-x86-64.so.2 --help </code>
That generates output that should tell you about the x86-64-v? compatibility. For instance on an old Xeon E5-2470 v2 server running Debian, that gives me the following output, indicating that x86-64-v2 is supported but the higher levels are not.
<code>
Subdirectories of glibc-hwcaps directories, in priority order:
x86-64-v4
x86-64-v3
x86-64-v2 (supported, searched)
</code>
Lots of missing things, despite being quite a large list of changes (removals of previously supported things). Red Hat appears to be giving up. Sigh.
So, had the displeasure of Ubuntu the other day, a non-enterprise distro. Word to the wise, if you chose Ubuntu realize that what it supports today, won't work at all tomorrow. That's not "enterprise". Way too many dependencies on things that are not controllable (in an enterprise way). Yes, it's hard to be an enterprise focused distro. Hard enough for Red Hat to apparently want to quit... and something Ubuntu never understood to begin with.
SLES? Even Suse is debating letting all things go. The Linux world is wanting each corporation to manage all components on their own. And guess what? They will fail (vast majority, if they try to stay with Linux).
Right now, I don't see anyone stepping in to try to hold things together in a way that makes corporate sense. And then, we wonder why so many companies seem to be running back to (again, a very non-enterprise) a company like Microsoft. And we also why there's so much frustration in the IT industry as a whole? We created FOSS, and we can destroy it. And for whatever reason, we seem to be trying really hard. I'm talking at the corporate level. Sure, as a hobby OS, if it works today great, if it doesn't tomorrow, I just wait for a fix.... ok, for a hobby, not ok for a corporate enterprise.
Managing all packages (the container approach) is where we're heading. And the folks that a truly knee deep into it will tell you they can't wait for their retirement from IT tomorrow. It's a lot of work. More work than most can imagine. Individual software developers are clueless and don't really care if their rapid changes that break everything force you to do more work, nor are they aware of the massive dependencies to software they didn't even think would ever integrate with theirs. It's the beauty of FOSS, but without any enterprise control at all, everything will spin at different rates causing companies to have to manage a huge matrix of "drivers" (that is, upstream driving them) and trying to test and keep everything "working". It will eventually drive you mad. Controls can be a very good thing. Long term supportability as well. If everything delivers change all at once all the time, that world makes Microsoft "look very good" (which, btw, aren't the kings of stability... but why give them the crown?).
We need enterprise Linux. I'm hoping that "the clones" can save us. Red Hat is giving up. I think Suse is too. Ubuntu/Debian never had a clue, so, nothing changes there.
As a very seasoned configuration administrator, integrator, quality assurance, systems engineer and systems administrator.... I'm prepping for "chaos world". It will be a pain. But I've got to do my best to keep things stable in the midst of the apparent "aging out" of the enterprise Linux greats. Hope you're prepared.
And Red Hat, you suck. Quitters.
> "Word to the wise, if you chose Ubuntu realize that what it supports today, won't work at all tomorrow."
Interesting you say that about Ubuntu. I run Ubuntu (and Windows 7) as my bootable OSs; I run Rocky in a VirtualBox VM to test software compatibility. I just learned that Rocky 10 has been released, so downloaded a Live ISO and created a new VM. Fails to boot. Meanwhile, I have the latest Ubuntu version running in a VM without any issues.
The Rocky 10 announcement page states a requirement for "64-bit AMD/Intel x86-64-v3 (x86_64)" My computer only has v2. I read that VirtualBox can emulate the difference, but I don't see any setting for that. I hopped to a new tab to do some quick googling. Apparently the v3 capability was added in VirtualBox 7.1.0. Alas, my old computer (2013 running dual AMD Opteron 4234 CPUs Valencia cores) can't run that version. I realize I'm running a 12 year old computer. I'm retired, and it does what I need. I only responded because of the Ubuntu comment.
> dual AMD Opteron 4234 CPUs Valencia cores
> My computer only has v2
No, that is too old. RHEL and Rocky will not run on that.
> Apparently the v3 capability was added in VirtualBox 7.1.0.
No, I don't think so. I don't think an older CPU can emulate a newer one in any efficient way.
You can't run any x86-64-v3 OS on that, and never will.
But as I spelled out in the article you _can_ run AlmaLinux 10 on it. Alma still does an x86-64-v2 edition and it will get updates for the next decade or so.
That is why I highlighted the technological difference in the article you are commenting upon.
"A surprise from the Ubuntu Summit 2024 was the high level of Rocky usage. It's sticking closest to upstream, thanks to a clever loophole to obtain source RPMs."
And what happens to all those businesses that bet their future on Rocky when IBM closes this loop hole? Because they will!
Alma is the equivalent to an LTS version of CentOS Stream that also references Oracle Linux (The true enemy of RHEL) for security updates.
it seems you like Alma Linux based on the number of times you mentioned it. :)
But...first of all, I don't think people are looking at CentOS Stream as an alternative to RedHat/Rocky/OldCentos. Maybe I'm wrong, but I don't think saying "Almoa is Centos!" is a selling point. Second...you worry about IBM making things unpleasant, but then mention Alma relies on Oracle. I've never been a fan of IBM, but Oracle makes IBM look like the Saints of Capitalism.
The answer, unfortunately, is don't hitch your company to any one vendor or one product or any feature that is not available somewhere else. If you bring a product into your business, you have to have a plan to replace that product with something else, as you can't be betting YOUR business on another business's wellbeing or benevolence. You don't have to have another product in mind, but you have to ask, "How do we get our data out? how do we move our network infrastructure over to another product? How do we host our VMs on something other than VMware?"
A nice review, thank you.
On the download sizes of 8GB (RHEL) and 7GB (Rocky and Alma), these are for the ISO images containing all packages. The sort of installation which might be done for a machine isolated from the internet. A typical installation doesn't select all packages, and so the installed operating system on disk is smaller than the distribution's ISO.
For a machine connected to the internet choose the "boot" image. Say the image Rocky-10.0-x86_64-boot.iso, which is 817MB. After writing this image to a USB and booting from it. select the "Network install" path through the installer. Only the packages required for the type of installation requested will be downloaded. Better still, it will download the most recent of the required packages, so there will be no large update required after the installation.
Network installs are important, as that is the way RHEL-family installations are done for the many hundreds of servers in server farms.
The essential difference is that corporate installs have the computer boot the "boot image" across the network using PXE and TFTP rather than from the USB. Then the "kickstarter" facility provides pre-canned answers to the network install. The network install typically uses a copy of the package repositories located on a web server within the organisation, rather than across the Internet to Rocky's servers.
The "kickstarter" approach also allows the equivalent to Window's "slipstreaming". Example Corp creates its own package, say examplecorp-server. That package lists as dependencies the organisation's baseline of packages to install. The second-last command in the kickstarter configuration installs examplecorp-server (and its automatically-determined dependencies); and the last command runs Ansible to apply the corporate configuration to packages. This technique has two nice outcomes: (1) the first boot of the machine into the new operating system has it fully up-to-date and fully-configured, there's no race against malware; (2) the machine is fully described in Git (where the DHCP, kickstarter, examplecorp-server.spec package definition, and Ansible configurations are maintained). Therefore the only data which needs to be backed up is user and service data, not umpteen copies of the operating system. It typically takes 20 minutes to automatically install and configure up a new server after it is powered on.
