A bit of context:

Notwithstanding the Red Hat scandal, it just so happened that, after having used several other distros on my 2021 HP ProDesk 400 G6 Desktop Mini PC (Intel i5-10400T), initially Fedora XFCE, but later on Manjaro XFCE, Manjaro KDE, Fedora KDE, openSUSE Tumbleweed KDE, at some point I tried AlmaLinux 9.1 KDE on it, because of all RHEL9 clones, AlmaLinux also offers an installable LiveISO with KDE (from EPEL), and I liked it. I then went to 9.2, and recently I updated it to 9.3. Rock-solid.

It’s a long story why and how I ended up with a RHEL9 clone, definitely for some other time. I still remember my time with CentOS 4 and 5 (also with Scientific Linux 4 and 5, and even with StartCom Linux), and the last time with Stella. Back then, GNOME2 was usable (MATE and XFCE are still usable), but with the new GNOME, whose Nautilus has “uninvented” the Compact List View (something that even the File Manager of Windows 3.0 had!), I had to switch to another desktop environment before I had a stroke. How I abandoned XFCE for KDE (instead of MATE or Cinnamon) is another long story. But now, maybe the question is:

Why AlmaLinux, of all RHEL clones?

Well, in the aftermath of the CentOS debacle, I followed (from a distance) the development of the new clones, starting with Rocky Linux, which was supposed to be the “rightful successor” to CentOS, as it has been initiated by Gregory Kurtzer, the original CentOS project founder. For some weird reason, I dislike the person. There were some aspects and declarations of the beginnings that turned me off. Even recently, he boasted that “Multiple industry reports and data sources are showing that the world has chosen Rocky Linux to be the successor of CentOS.” Well, not so fast, Bob!

As someone noted on Reddit, Rocky Linux being a Public Benefit Corporation,

A PBC is basically like a LLC but with a special status because it’s designed to benefit the greater good; where it is non-profit-ish but it can most definitely churn a profit and make money its priority (unlike standard non-profits which make money to fund themselves). And because it’s similar to an LLC, that means Greg is essentially the CEO and owner. If Greg wants to sell it to Red Hat or Canonical, or even just shut it down, he absolutely can. Rocky Linux says they’ve implemented checks and balances to ensure that a take-over can’t happen, but legally it absolutely could.

In contrast, the AlmaLinux Foundation is a 501(c)(6) non-profit and has bylaws (sort of “constitution” or “articles of association”; in languages other than English, think of a statut, statuto, estatuto) that prevent such a thing from happening.

Subjectively, Alma is more positive a word, as in several languages it has felicitous, warm meanings. I’ve chosen to take “alma” to mean “anima”–Latin and Italian for “soul.” Also, I have my theory that names that start with letters closer to the beginning of the alphabet (A, B, C) are more suggestive of success than names further down in the alphabet, with the possible exception of the very end (X, Y, Z). And Rocky fails this ad-hoc criterion 🙂

On a more serious note, there seem to be a future for RHEL clones, when even SUSE wants to build one! Not that benny Vasquez (her choice for a minuscule “b”) wrote, The Future of AlmaLinux is Bright, but for the non-enterprise user, their choice of dropping the aim to be “1:1 with RHEL” and opting to be Application Binary Interface (ABI) compatible has some positive implications:

The most remarkable potential impact of the change is that we will no longer be held to the line of “bug-for-bug compatibility” with Red Hat, and that means that we can now accept bug fixes outside of Red Hat’s release cycle. While that means some AlmaLinux OS users may encounter bugs that are not in Red Hat, we may also accept patches for bugs that have not yet been accepted upstream, or shipped downstream.

Now, it gets even better: they added two new repositories, of which my favorite is obviously Synergy, because it contains unexpected goodies, most notably dnfdragora and Warpinator!

In conjunction with EPEL, RPM Fusion, and possibly ELRepo, AlmaLinux with Synergy enabled becomes a strong candidate for a desktop usage, with very little need to use flatpacks or snaps.

Enter my new laptop.

Acer, c’est pas cher

Dirt cheap Aspire 3 A315-59-32MA, I mean. I described my initial experience with it here (unfortunately in Romanian), when I left it running openSUSE Tumbleweed. Eventually, I got pissed off by the continuous upgrade of the kernels (something that also annoyed me in Fedora, but Tumbleweed being rolling-release, it was to be expected, and they don’t maintain any LT kernel à la Manjaro or EndeavourOS). I also hated openSUSE’s idiosyncrasies, such as: (1) not exporting DISPLAY XAUTHORITY and XDG_RUNTIME_DIR in env_keep, so starting a GUI with sudo from a terminal would fail; (2) sudo asking for root’s password, because it’s not configured; and (3) not only the impossibility to run Kate or Featherpad as root, but also the impossibility to run them as a regular user, and being asked for a sudo password upon saving to a root-owned file! That was the last drop… so I dropped it!

After an attempt to go for Debian 12 + MX repos, specifically for featherpad, I decided I can do better. As a side note: featherpad 1.4.1 was released on June 12, but Debian only got it in sid on Sept. 6, and in testing on Sept. 12. This led to the ridiculous situation that it was too late for Ubuntu 23.10. It shouldn’t be too late for Ubuntu 24.04, but despite this package being in Debian testing, Ubuntu 24.04 still has 1.3.5.
To see why and how this is ridiculous: EPEL9 got featherpad 1.4.1 on Aug. 4, and mxrepo, which can be used by Debian 12 users, has it since June 14. Yet Ubuntu 24.04 might not have it!

I can do better with AlmaLinux 9, because EPEL will keep updating KDE, albeit at a slow pace, while MX might not do that for Debian 12, and Norbert Preining stopped doing it, having been abused by several people for one too many times; I remember how, back in 2019, Martina Ferrari called him names because he wasn’t aware that Martina Ferrari, born Martin Ferrari (with XY chromosomes), is now a she/her. The Debian community is toxic.

But there is a problem with my new Acer: RHEL9, hence AlmaLinux 9.2 and now 9.3, uses a 5.14 kernel, which cannot support the MT7663-based Wi-Fi/BT combo! The fix comes in the form of the 6.1 kernel-lt package from ELRepo, provided that I can use it. For this, I had to:

  1. Install AlmaLinux from the Live KDE ISO image (using Ventoy) over Ethernet, and by using a USB adapter (this laptop lacks a RJ45 socket).
  2. Disable Secure Boot in the BIOS/UEFI.

This was doable, but what if I need a rescue memory stick with a Live AlmaLinux ISO that could be used without that bloody adapter and a patch cord?

So I built a custom KDE Live ISO based on AlmaLinux 9.3 with kernel 6.1 from ELRepo!

The opportunity came from the frustration that, while AlmaLinux 9.3 was released on Nov. 13, it lacked the installable Live images. As I am writing this, the released Live ISOs are still for 9.2. Meanwhile, test builds were announced on SIG/LiveMedia, but the KDE image came late. And it would still be unable to detect my Wi-Fi chip anyway!

So here’s the thing:


All the details are to be found in those two places. The ISO is larger than the official one (SF displays 2.8 GB for the latest ISO, which has 2630 MiB / 2758 MB), but for good reasons:

  • The ISO will boot the kernel 6.1.63, but Anaconda will install both 5.14 and 6.1 kernels, with 6.1 being the default one.
  • KDE Plasma 5.27.6, KF5 5.108, Apps 23.04.3, from EPEL.
  • dnfdragora from AlmaLinux-Synergy!
  • Preinstalled codecs from RPMForge, and also VLC and SMPlayer.
  • Preinstalled from EPEL: featherpad, krename.
  • Other preinstalled packages: alsa-sof-firmware (newer laptops need it, but most distros don’t install it), fortune-mod (because you should add it to ~/.bashrc), mc, neofetch, warpinator.
  • You’ll have EPEL, ELRepo and RPM Fusion enabled on the final system.
  • Please take note of the “Known Issues and Errata” (README.md) that are displayed on SourceForge for each build.

The AlmaLinux SIG LiveMedia team was blocked by an EPEL issue: kdepim-addons couldn’t be updated because kf5itinerary needed a newer poplar than the one available in EL9 (read about it here). I’m not using KDE PIM at all, so I just excluded kdepim-addons. Now they have excluded this package too from their builds.

KRename has recently arrived in EPEL. On August 18, I asked them to build krename in EPEL. The build of Nov. 3 entered EPEL testing the next day, and it was released on Nov. 12. I have used their build from testing; prior to that, I was using the RPM from FC38 (literally any package that offers version 5.0.2, as it’s very tolerant, not requiring an exact version of its dependencies).

UPDATE: Build AlmaLinux-9.3-x86_64-Live-KDE-Ludditus_2023.11.24.iso works around EPEL’s bug 2251295, which means that Color Management doesn’t work unless you manually install kf5-kirigami2-addons-dateandtime.

That’s all, folks!