Seeing as IBM is involved, shouldn't "Big Purple Hat" read <knobGag>
"Big Purple Helmet'</knobGag>
?
AlmaLinux shows off its new Kitten
The AlmaLinux team unveiled a new distribution, but don't get too excited. It's not meant to be a new flavor or intended for production use. AlmaLinux OS Kitten is a new variety of AlmaLinux, but not a new distro, or a new version, or anything that is really intended for real deployment or use. "Kitten" is more like a public …
COMMENTS
-
-
Sunday 27th October 2024 14:29 GMT Martin Gregorie
RHEL has certainly gone downhill
I run Fedora Linux on all my computers use a weekly update cycle, which has worked well for me from around 2005 until the start of October this year, when the stuff described below started to happen.
Every Friday or Saturday I backup my computers to a cycle of 1GB USB disks before running software updates on my two active computers, currently a Thinkpad T440 and an AMD Rizen-based desktop.
However, since the start of October, things haven't been so straight forward:
- somebody seems to be messing about with dnf upgrades used by the Thinkpad: its still fully usable, but some thing or person is screwing round with the system code that handles temporary system
inactivity:
- sometimes the screen fails to blank after 10 minutes of inactivity (the timeout I set)
- sometimes the laptop fails to hibernate when the lid is closed
- the red LED on the lid is always steadily lit during normal operation, as you'd expect, but sometimes it also remains steadily on when the lid is closed: its supposed to hibernate and flash the red light
when the lid is closed unless, of course, you've shut the system down.
Since the start of October each Fedora update has been randomly messing with way this set of functions work.
Since last Friday (my last update, screen blanking after 10 minutes is working, but shutting the lid retains the steady red LED and leaves the system fully active: the disk remains spinning.
Previous updates have just disabled screen blanking or disabled everything (screen blanking, Led flashing and hibernation.
But at least the machine is still working: my RYzen desktop was completely messed up by by the update two weeks ago (earlier updates were fine) and has not been usable since then because:
- a seemingly random collection of logins are no longer working and this includes 'root'
- none of the logins that work will ececute 'su' or 'sudo' commands: there's no error reported: the command just doesn't do anything
- the emergncy boot process doesn't work
- the boot process will not boot any of the previous upgrades(I retain the default 4 versions kernel versions)
- so currently I can't become root at all.
The only bright spot is that I have a clean backup that was made immediately before the upgrrade that caused this problem.
I'm starting the wonder ii IBM's last set of so-called "Resource Management Actions" have been sufficiently badly handled to have wrecked what's left of Red Hat.
-
Sunday 27th October 2024 15:09 GMT Alistair
Re: RHEL has certainly gone downhill
Martin:
Check your scheduler settings, I'm on 39, and it appears that they've retired both of my preferred schedulers. This has resulted in my VMs doing rather strange things, since one is Slackware and the other is NetBSD, such that they don't seem to be correctly handling multiple CPU allocations. (Basically running single threaded) So far, I've gotten the host scheduler sorted, but I've not found the correct sysctl param to fix the vm behaviour.
-
Monday 28th October 2024 10:21 GMT Licensed_Radio_Nerd
Re: RHEL has certainly gone downhill
Using Fedora for main-stream was always playing with fire as new code would (and clearly still does) break things. Like Windows, I contain it in a VirtualBox VM where it can blow itself up without causing me an issue.
My old Lenovo T440s is happily running Rocky Linux 9.4, and everything works - including the fingerprint reader. I cannot comment on hibernation as I do not use it. My home-brew 8-core Ryzen 7 desktop is also happily running on Rocky Linux 9.4, with kmod-nvidia from the nice people at ELrepo.
My newer Lenovo P14s is waiting an upgrade. It has an AMD GPU, and a test upgrade a couple of months ago saw lots of noise on the LCD due to broken GPU code; so Clonezilla was deployed to restore the Rocky 8.10 image. My APRS iGate is still on Rocky Linux 8.10, and I am mulling whether to upgrade, or leave it be.
I can highly recommend Rocky if you want stability!
-
Friday 15th November 2024 15:07 GMT Cliffwilliams44
Re: RHEL has certainly gone downhill
I've run Fedora desktop since 36 without flaw!
Would I run Fedora server on production servers? Never!
I have recently started using Alma, seems very good. After the IBM/RedHat fiasco I upgrade some servers to Rocky, but the future of Ricky seems tenuous right now! I just don't feel comfortable basingf outr production servers on a distribution that is "essentially breaking the rules" with RedHat!
-
-
-
-
-
Sunday 27th October 2024 17:41 GMT LionelB
I might actually be be tempted if some critical (proprietary) software I require for my work -- in particular Matlab1 -- ran on any of the BSDs2. Ironically, this mirrors reasons commonly cited as a barrier to moving from Windows to Linux -- a move I made over twenty years ago.
1Sadly Octave, a rather good open-source Matlab-alike, will not cut it, for a raft of reasons ranging from compatibility to deployment issues.
2The most recent reports I've managed to find of anyone actually having successfully run Matlab on FreeBSD (under Linux emulation) are circa 2014.
-
-
Monday 28th October 2024 10:43 GMT LionelB
> My understanding is that FreeBSD has a petty complete optional Linux subsystem that allows Linux elf files to run directly.
Yes it does, but Matlab is a complex beast with arcane dependencies and an opaque installation procedure. The Linux installer will generally barf on FreeBSD, so some kind of manual install is required, which by all accounts is hideous. Matlab is also something of a fast-moving target (read: is rapidly bloating out), is notoriously laissez-faire about backward compatibility, and prone to introducing new subsystems with each (bi-annual) release. Also, Linux emulation on FreeBSD (the linuxulator) has its limitations and only appears to emulate rather old Linux kernels, although the performance overhead is claimed to be minimal. (Mathematica, though, will apparently install and run on FreeBSD.) Presumably there is limited interest in running Matlab on FreeBSD, and attempts to achieve this seem to have stalled around a decade ago.
-
-
-
-
Sunday 27th October 2024 03:53 GMT Groo The Wanderer
Debian based distros for me; I just find the whole philosophy of a Debian base for distributions to be far more palatable than RedHat. I currently use Ubuntu VMs, but as far as I know, there is no reason I couldn't use raw Debian except for the fact that Debian repos don't seem to support non-open-source codecs, which are needed for some of the Java work I do.
-
Sunday 27th October 2024 17:47 GMT Crypto Monad
Where's Alma going?
The whole point of the original CentOS was that it was almost a byte-for-byte clone of RedHat, without the registration / license fee. If you were running CentOS in production then you had the confidence of it being identical to RedHat.
If Alma starts changing the way they compile things - different instruction set options, different stack layouts - then it's diverging from Red Hat. In an ideal world these things *shouldn't* make a difference, but in some edge cases they might.
How many Alma users want frame pointers - something which the article admits could reduce performance by 1%? And do they want this *more* than they want Red Hat equivalence?