Knoppix is a fun one :) Didn’t know it was independent.

Can you name 10 base/independent distros?

Mostly, I’ve only had minor issues: Old packages on Linux Mint, missing packages on Debian and Arch, system instability after updating without a reboot on many distros (NixOS, Fedora, Alma, …). But I’ve had two major issues that caused me to abandon a distro:

1. On Fedora KDE, I felt that my system was overall not as stable as other distros. Then they decided to ship (as a rolling update to a “stable” version) an experimental KDE patch that broke the lock screen for a week. The breakage itself was not so bad, but shipping a patch before upstream merged it to their nightly builds irked me quite a bit.

2. On NixOS, I was not able to get development stuff to work (I’m probably just too dumb for Nix/NixOS). First, I tried to set up a dev workflow that has quite a few external constraints (glibc version, Python version, running on other distros, …). I failed on multiple fronts and gave up on this. Then I tried to build my own KDE/Kirigami app on NixOS and also struggled a lot with it. I struggled for quite a while but gave up on it in the end. I moved to CachyOS afterwards and it worked flawlessly 🤷

I would go a bit further than that. To me, not keeping archival backups for at least a few months seems grossly negligent. To a degree where they should be legally liable for the damages. They probably have some waivers for that in their terms… but they may not hold depending on the jurisdiction.

To be fair, $600 for 64GB of RAM is a steal in this economy (you could probably sell the RAM alone for $800). So if you want that much RAM and are ok with the rest of the system - go for it. I mostly wanted to point out why I personally would not like such a machine (why I’m “sleeping” on it).

Mine was the equivalent of $660 at the time with 32GB of RAM (excl. HDDs). In this RAMpocalypse it would probably cost around $1k.

I am interested in trying out an Arm/RISC-V PC for a Linux server. However, what stops me from buying almost all of them is that they require you to use a dubious, poorly-maintained manufacturer fork of some Linux distro.I don’t want my hardware to become e-waste when the manufacturer looses interest in 10 months, so running an upstream distro (like Fedora/Debian/NixOS) is a hard requirement for me. It seems that they half-solved that issue for this machine, so that’s actually good progress.

For this particular machine, Jeff Geerling also reported that the idle power draw is 17W. That’s higher than my faster, fully-upgradable mATX AM5 x86 NAS…

Ok, thanks! Thaf sounds quite advanced, but I’ll have a read afterwards :)

I run it using LM Studio, which defaults to Q4 quantization, I think. I was able to put about 10 layers on the GPU with 64k token context. That put me at about 9.1 GB VRAM usage, leaving some room for Video playback xD

What version do you use and how do you run Qwen3.6? I’ve played around a bit with the Q4 version in LM studio +Zed, but I was not happy with the results. It looses track very often and often enters infinite loops or just stops…

I can run both the 27B and 35B version of Qwen3.6 on my 10GB VRAM 3080, and they run ok. You don’t need to put the entire model in VRAM, even if it’s probably beneficial.

This sounds like a rather weird issue. I agree with your take that grub is not the problem. It seems that there is some issue with the kernel, or the initramfs systemd… Downgrading the kernel didn’t resolve it, so maybe it is a corrupted disk after all? Some suggestions:

1. Run fsck on the partition from a live USB if you haven’t already
2. Enable more verbose logs from the kernel and the initramfs systemd. The LLM suggests removing quiet splash and adding rd.debug systemd.log_level=debug systemd.log_target=console ignore_loglevel (best check the actual parameters yourself).
3. If possible for you: Copy the install to another drive, change the UUIDs, and try again with that.

Debian also supports “unattended-upgrades”: https://wiki.debian.org/PeriodicUpdates

I actually have it set up the same way on both: Automatically install updates (and restart some services), but don’t reboot. I don’t think it was different/easier on Ubuntu.

Overall, the two distros are very similar for a server application. If you’re already running Debian on your PC, I would also go with that for a server.

It really should be shut down for Arch’s sake.

I think it should really be split into two parts:

1. The more widely used packages should be moved to an official repository with review procedures. Perhaps the (quality) requirements can be lower, but these must be reviewed by trusted people.
2. The remaining packages should be moved to user namespaces, like the other user-package repos do. That will at least prevent (most) takeover attacks.

the CPU is never taxed, albeit undervolted with minus 30 on all cores in PBO

In case of an unstable system, the first thing I would do is disable all overclocks (including PBO, EXPO, undervolt, …)

Do you think benchmark results like these are meaningful when comparing Linux distributions?

They don’t really provide any explanation for why it should be faster than CachyOS. So I’d take their claims with a bucket or two of salt.

No, Debian is typically quite a bit older than even the Ubuntu LTS. E.g. they currently still don’t ship a Nvidia driver that supports the 50 series GPUs.

It looks like the fixes were merged in 6.18, 6.19, and 7.0. But all older (but supported) LTS kernels didn’t have the fix, like 6.12, which is used in Debian 13. And it also seems that Ubuntu, RHEL, and SUSE had not picked up the patches in their kernel versions.

That may be true for personal computers, but the impact of this vulnerability is mainly on servers. And those typically run distros like Debian, Ubuntu, RHEL that didn’t have a patch at that time.