Just tried CachyOS in VirtualBox... - ISO boots - You have to select "Plasma Wayland" session to log into "live CD".  You can't log in from "Plasma X11" which is selected by default. - Installs okay. - Booting from the harddisk is where it's stuck.  It spins forever in blank screen.  I don't even get to boot splash. Reading the docs, it reminds me of Gentoo.  If I want rolling release, I'd would go with - Fedora -- practically rolling-release. - OpenSUSE Tumbleweed -- real rolling-release. I'm looking for rolling-release of Debian/Ubuntu + KDE.  The reasons are - Recent KDE is very crisp and fast, unlike older versions.  Probably, faster than other desktops.  Yes, KDE is bigger install on harddisk.  But, I care about running speed.  I want desktop to do its stuffs, and get out of the way. - Recent kernel has more bug fixes.  Most features of embedded boards are accessed via kernel subsystems, usually "sysfs" and "configfs". - All current embedded boards come with Debian distro. I guess, I'm looking for "rolling-release Mint".  Forces of Kubuntu is strong...  2025-12-27 10:35, Evan Leibovitch wrote:

I'd been asking what people thought of CachyOS, which is about as recent as one can get (kernel 6.18.2, KDE 6.5.4 which is the default desktop) plus has fine tuned kernels and compilers for various CPU architectures. It might be worth your while to check out.

- Evan

On Sat, Dec 27, 2025 at 2:17 AM William Park via Talk <talk@lists.gtalug.org> wrote:

(Double posted, so reply to your list)

I've been looking for a distro with recent KDE and recent kerne*l*.  So, the benchmark was *Kubuntu* 25.10 (v6.4 KDE, v6.17 kernel).

1. Started with *Mint* + "apt install kde-full".  Result was comparable to Kubuntu LTS, ie. v5.27 KDE, v6.14 kernel.  Makes sense, since Mint is based on Ubuntu LTS.

2. Then, tried *LMDE* + "apt install kde-full".  I was surprised to get a rather recent v6.3 KDE with v6.12 kernel.  I was expecting an old KDE, even older than Mint version.

3. So, decided to try *Debian* *testing* + KDE.  I got v6.5.4 KDE (latest) and v6.17.12 kernel.  Not bad.

Right now, *Debian testing* is compiling v6.12.62 and v6.18.1 kernels for Raspberry Pi Zero 2W.  We'll see how it goes.

To those using Debian testing, how would you rate its stability?  Is it suitable for daily PC? ------------------------------------ Description: GTALUG Talk Unsubscribe via Talk-unsubscribe@lists.gtalug.org Start a new thread: talk@lists.gtalug.org This message archived at https://lists.gtalug.org/archives/list/talk@lists.gtalug.org/message/B2VA56Z...

On 2025-12-29 19:03, Evan Leibovitch wrote:

I admire CachyOS's advances in kernel-tuning and other forward-thinking offerings (such as Lemine as a modern alternative to GRUB, btrfs as default and alternate kernel schedulers) but I too am uninterested in being an involuntary regression tester. I'm hoping that other distros can learn from it.

Thanks for the pointer to "Limine".  Since "bootloader" is the root cause of failed installs, I decided to give CachyOS another try, with other bootloaders (they give 5 choices). * CachyOS + grub --> *fail* * CachyOS + systemd-boot --> *fail* * CachyOS + Refind --> *success* * CachyOS + another Refind --> *success* * CachyOS + Limine --> *success* -- I like this one. You get "tree" list, rather than just linear list. I found CachyOS about 10% faster than Fedora 43 in compiling Raspberry Pi kernels.  But, there are quirks with CachyOS.  Eg. "usermod" changes "user:group" in /etc/passwd okay, but doesn't change group setting of  home directory.  It's simple things, but it requires manual touch here and there, and pretty soon, leads to confusion and mistakes. In the old days, Fedora's grub can boot other distros.  But, on my machine, it can only boot itself, Fedora.  It can't boot other distros on other disk.  What is going on?  Maybe motherboard problem?  It is 10 year old.

On Sun, Dec 28, 2025 at 10:47 AM D. Hugh Redelmeier via Talk < talk@lists.gtalug.org> wrote:

This thread went off in different directions on each list, both interesting.

This feels like a problem: why split the conversation?

On the other hand, posting to only one of the lists would have prevented the useful conversation that occurred on the other list.

Good point. Could you summarize the KWLUG thread here? Or better still, is there an online archive of it? Here is the GTALUG thread <https://lists.gtalug.org/archives/list/talk@lists.gtalug.org/thread/B2VA56ZGH4LYIXGGE3DVI34DCTADZWQX/#Z4PYKL2KMGMKZEAUTZ3R2B4AVOTLLQCO> . - Evan

On Sat, Jan 03, 2026 at 09:38:20AM +0000, Andre via Talk wrote:

More than likely you need to increase UEFI partition on /dev/sda*. Slackware that took my cherries will typically create 100MB (Same as windows) size and that's not enough if you are multi booting or distro hopping and reason is cachyOS + limine (which i use) will copy multiple initramfs and vmlinuz to the UEFI partition to select or revert via multiple kernels with corresponding btrfs snapshots. Other Linux distro will do roughly the same, except a few like Fedora where it points vmlinuz and initramfs to /boot. This is probably why fedora worked for you. My UEFI Partition is currently 653MB out of 2GB, where a big portion is only 3 linux kernels + additional files for cachyOS.

What's worse is distro hopping installs will fill your UEFI partition overtime and will not be removed(you have to do it yourself) and therefore, also not go overboard with lots of Linux kernels to install.

I dual boot cachyOS (/dev/sdc*) and windows 11 (/dev/nvme*). have to manually expand windows UEFI fat32 partition from 100MB to 2GB for multi boot cachyOS or any Linux distro to work.

This issue is not just you... i've encountered this last year too but not well publicized on the internet.

I know Debian puts the kernel and initramfs in /boot and only puts grub on the UEFI partition. Why would any distribution put the kernel files on the UEFI partition? That sounds like a dumb thing to do. I think I have read some distributions mount the UEFI partition as /boot and then dump crap in there, so I can see how that would be a problem. Checking opensuse, I see kernel and such in /boot and the uefi partition with grub is mounted as /boot/efi. -- Len Sorensen

From: Lennart Sorensen via Talk <talk@lists.gtalug.org>

I know Debian puts the kernel and initramfs in /boot and only puts grub on the UEFI partition. Why would any distribution put the kernel files on the UEFI partition? That sounds like a dumb thing to do.

I think I have read some distributions mount the UEFI partition as /boot and then dump crap in there, so I can see how that would be a problem.

Checking opensuse, I see kernel and such in /boot and the uefi partition with grub is mounted as /boot/efi.

GRUB has to understand all filesystem types that might contain the kernel and initramfs. This is goofy. Especially when you realize implementations may accidentally diverge. - filesystem code must be in the kernel AND in GRUB - GRUB gets larger and larger over time as potential filesystems get added - GRUB holds back filesystem and RAID etc progress. Just dump every file that GRUB must deal with into the ESP. Then GRUB only needs to handle DOS filesystem variants. And that code is already in the UEFI firmware so it need not understand any filesystem at all, it just needs to use the UEFI API for files. In fact, I think there is a move to package kernels as .efi files and let the UEFI firmware boot it directly. In an EFI world, what value does GRUB add? Anything beyond what an EFI shell would provide? As far as the size of the ESP, 100M is clearly too small. If you google, you will find that pure Win 11 systems are now banging into that limit. My default would be 1G because why not? I find it irritating that gparted won't resize a 100M ESP. And it won't move a Microsoft Reserved / Restoration partition. That's what I'm faced with on machines with pre-installed Windows. I could just throw away the Windows installation but I don't want to. <https://askubuntu.com/questions/1491415/gparted-always-fails-at-resizing-the-efi-boot-partition-how-can-i-fix-it>

If I'm using same disk, yes.  Because all the distros will be sharing the same EFI partition.  In my case, I only have only 2 distros, old Slackware and new distro, and on separate disk. I'll test your idea, as soon as I find a spare disk.  I just found out CachyOS repository only has 64-bit arm cross compile toolchains.  I still have to use Debian VM for 32-bit arm. --William On 2026-01-03 04:38, Andre via Talk wrote:

More than likely you need to increase UEFI partition on /dev/sda*. Slackware that took my cherries will typically create 100MB (Same as windows) size and that's not enough if you are multi booting or distro hopping and reason is cachyOS + limine (which i use) will copy multiple initramfs and vmlinuz to the UEFI partition to select or revert via multiple kernels with corresponding btrfs snapshots. Other Linux distro will do roughly the same, except a few like Fedora where it points vmlinuz and initramfs to /boot. This is probably why fedora worked for you. My UEFI Partition is currently 653MB out of 2GB, where a big portion is only 3 linux kernels + additional files for cachyOS.

What's worse is distro hopping installs will fill your UEFI partition overtime and will not be removed(you have to do it yourself) and therefore, also not go overboard with lots of Linux kernels to install.

I dual boot cachyOS (/dev/sdc*) and windows 11 (/dev/nvme*). have to manually expand windows UEFI fat32 partition from 100MB to 2GB for multi boot cachyOS or any Linux distro to work.

This issue is not just you... i've encountered this last year too but not well publicized on the internet.

/Balrog

William Park wrote:

...

I just found out CachyOS repository only has 64-bit arm cross compile toolchains.  I still have to use Debian VM for 32-bit arm.

Assuming you are using rpi zero w 2, why use 32bit arm binaries (or maybe OS as well)... any specific use case? i'm running 64bit Alpine: # uname -a Linux al 6.12.60-0-rpi #1-Alpine SMP PREEMPT Wed Dec 3 08:36:42 UTC 2025 aarch64 Linux All the older boards I have are 32-bit, eg. Raspberry Pi (Model 1)B+, BeagleBone Black, and Odroid U3+. Only BeagleBone Black is still in

On 2026-01-06 19:27, Andre via Talk wrote: production, and that's because it includes eMMC, PWM, eQEP, and PRU on top of what Raspberry Pi has. Going forward, yeah, all vendors are moving 64-bit. --William

D. Hugh Redelmeier wrote:

...

From: Andre via Talk <talk@lists.gtalug.org>

...

Assuming you are using rpi zero w 2, why use 32bit arm binaries (or maybe OS as well)... any specific use case? i'm running 64bit Alpine: My recollection is that 64-bit ARM machine code is significantly less dense that 32-bit ARM code. If you are short of memory, this may matter.

On RPi 3, if I remember correctly, 64-bit performance was worse than 32-bit performance.

If your processes are less that 3GiB, 64-bit pointers are only a waste.

That's the thing. interwebs "recommends" 32bit OS on 4GB or less as an example, rpi w 2 (armv8 CPU and 512MB memory) and have followed the dogma too for years. Stumbled last year an old benchmark from phoronix where it shows 64bit faster: https://www.phoronix.com/review/raspberrypi-os-64bit Did my own quick and very rudimentary test, alpine linux or raspbian 64bit is indeed faster than raspbian 32bit. Complicating matters is even though rpi w 2 is armv8, raspbian 32 OS kernel is compiled as armv6 which could be the reason for the slower performance. 64bit systems will increase memory usage by 20-40MB which is a reasonable use case for me as i used it as a headless server for chrony and adguard home for blocking ads home wide. I know it's counter intuitive, Implementing compressed zstd swap in memory, is like adding roughly free 100MB RAM on top of 512MB. Sample below on my live system: # free -m total used free shared buff/cache available Mem: 465 167 286 1 11 287 Swap: 500 344 156 Moved away from 32bit for peace of mind because of the Epochalypse 2038 time and not that it matters, a lot of docker containers doesn't even have 32bit armv6 images, like portainer. That's all i can think of, there maybe other compelling reasons not to use 32bit. /Balrog

William Park wrote:

On 2026-01-08 17:12, Andre via Talk wrote:

...

That's all i can think of, there maybe other compelling reasons not to use 32bit. There is. You can't buy 32-bit anymore.

Sorry to be pedantic, 32bit HW variants still sold new... notably "rpi zero w" production till 2030. Probably why raspberry pi foundation targeted raspbian 32bit OS for armv6 architecture. Performance will suffer, but work on all models from zero w to 5. /Balrog

There have been a couple of interesting discussions on the Debian list lately around the distribution. One asks about the amount of orphaned packages still kept in the distro. The other though? Has to do with something I have always felt was a Linux basic assurance. It has to do with hardware being recognized by the distribution, no matter the age. In the latter case the posting person listed some details outlining errors they were getting. Still, it has me wondering if custom is truly custom? If I say wanted to install Debian on an older apple laptop, how successful would the effort be in general? Kare

On Tue, Jan 06, 2026 at 04:59:06PM -0500, Karen Lewellen via Talk wrote:

If I say wanted to install Debian on an older apple laptop, how successful would the effort be in general?

Well Apple hardware being Apple hardware is often not trivial to work with because it seems to be explicitly designed to not make it easy to run anything other than Apple software on it. Non standard boot methods, non standard hardware interfaces. Definitely not the easiest option. On the other hand there are often a lot of them sold so you might find good information on making a particular model work. -- Len Sorensen

On Tue, Jan 6, 2026 at 11:24 PM Karen Lewellen via Talk < talk@lists.gtalug.org> wrote:

The idea of matching a distribution to hardware seems like a daunting task for anyone new to Linux though.

Sorry, but I call shenanigans on this assertion. Pretty well any PC able to run Windows 10 or 11 will be fine with any of the mainstream distributions. Most people with edge-case hardware (either really old, really new, non-x86 or niche peripherals) will already have some idea that a mainstream system might not be best; heck, most of them can't run Windows at all. And there are plenty of sources of helpful answers for those seeking a starting point. Twenty years ago this was indeed an issue. But these days, "ChatGPT, what are the best Linux options for my use case?" is the opposite of daunting. - Evan

There are several things here that are different cases. The key factor is that without a maintainer, code can stop working. In addition, the maintainer of hardware support needs to have access to the hardware to do testing. Support for old packages: If nobody steps forward to maintain a package, it can stop working. For example, new compilers can enforce rules that were previously unenforced. New compiler optimizations can cause latent bugs to manifest themselves. Another example: things used by a package can change. The package may need to be updated to reflect that change. Similarly, there has been an increasing focus on security. Lots of old code was a bit careless and people have found ways to exploit this. Code that is security-critical needs to be reviewed. So stale packages look like a hazard. Any distro should kick out a package that has no maintainer. How else can quality standards be maintained? A temporary gap is probably OK. Support for old hardware: I see this as two cases: support for once-common hardware that is so old as to have few users, and support for rare and quirky hardware. And there are two parts to it: should the Linux kernel support this old hardware and should a particular distro enable this kernel support. And there are two scales: the architecture scale and the device scale. Once in a while, the kernel developers change internal interfaces that device drivers use. Sometimes the driver maintainers have to update the driver to reflect this change. Without a maintainer, the driver may cease to work. This freedom to change internal interfaces has allowed the kernel to improve over the years. Examples: - Intel's Itanium architecture is no longer supported by the Linux kernel. Supporting a whole architecture puts a burden on the rest of the kernel. The kernel devs decided that the burden was more than the benefit. (I have an Itanium box but haven't turned it on in a decade.) - Some stylus hardware support has been removed from libinput. I have a ThinkPad x61 tablet with a stylus that works in Fedora 20 but when I tried Fedora 43, the stylus didn't work. Clearly not enough people cared. - 32-bit x86 support still exists in the kernel but fewer distros are bothering to provide this. Funny case: I have a number of cheap x86 machines that have 32-bit UEFI but 64-bit processors. Those can run 64-bit Linux but not 64-bit Windows. Difference between Windows and Linux support: - With open source, anyone can step forward to become a maintainer - With closed source, support can be turned off when the maintainer finds it advantageous. For example, when they want to force you to buy a new device. - Windows tries to keep a stable ABI for drivers so drivers can work without updates for many years.

From: Karen Lewellen via Talk <talk@lists.gtalug.org>

There have been a couple of interesting discussions on the Debian list lately around the distribution. One asks about the amount of orphaned packages still kept in the distro. The other though? Has to do with something I have always felt was a Linux basic assurance. It has to do with hardware being recognized by the distribution, no matter the age. In the latter case the posting person listed some details outlining errors they were getting. Still, it has me wondering if custom is truly custom? If I say wanted to install Debian on an older apple laptop, how successful would the effort be in general?

Kare