More specifically, issues for one distro (or maybe family of distros if applicable) and not other distros.
I’ll start: NixOS. I love how I can have my whole operating system configuration defined deterministically with configuration files, but what I believe is a serious flaw, is when you choose the “unstable” channel, the channel for receiving the latest packages rather than ones up to 6 months old: stable. Unstable package often build dependencies on device, and I’ve often faced build failures, why are new package versions given if they fail to build?!
Why can’t Nixpkgs backend ensure that new package versions build successfully before shipping them to end users?! It would take a lot of work to do so, but I can’t think of any other distros that have this problem: where installing a new package version that came out a few days or even a week ago, has a chance of failing after its made available in the distro’s official package manager.
There are a handful of workarounds for your NixOS configuration in this case, but it happens too often for me and I shouldn’t have to edit my config for to work around it.
Fedora Core (so it’s quite a while ago) had dependency hell on a completely fresh install. In fact it was the first update. I’m still salty about it!
Bazzite: You can’t rollback if you replace rpm-ostree binary with a buggy bash script
Wait really? What did they do? Is there a forum announcement about this?
Nothing. That was totally PEBCAK-class problem.
Edit: For questionable maintainers decisions I have seen a few. They changed default wifi manager that didn’t work with enterprise networks/encryption and sometimes nvidia driver versions desynchronise between flatpak and system breaking GPU rendering in blender.
Got it you worried me for a sec there 😅
For questionable maintainers decisions I have seen a few
Yeah they definitely aren’t perfect but it’s good enough for me, I’m too lazy to manage my OS myself
Fedora Selinux, I mean, yes security is important. But how often is it in the way. In docker my mounts always need a :z and other stuff. Switched back to Debian. Apparmor doesn’t need this finetuning and just works.
OpenSuse TW. Network seems to be permission based. If I’m connected to the Internet on one user and someone logs in, they cannot connect without my pass. Quite ridiculous.
Oh, and I used to hibernate. Then it stopped working. Now I try to sleep and that sporadically fails requiring restart.
Used Tumbleweed as my main OS for years and this was always a pain point. Why do you need root privileges to connect to a network on a fresh install?? I can’t be bothered to find a link, but Linus Torvalds himself complained about this and said it was the reason he didn’t want his kids to use SUSE/openSUSE on their computers, since he didn’t want them to have root privileges, lol.
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:
-
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.
-
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’m probably just too dumb for Nix/NixOS
Probably just didn’t want to put in the time/effort. From what I’ve heard, NixOS takes a lot more time/effort than other distros. Not everybody wants that.
-
CachyOS, freshly installed: KDE Connect doesnt work, as Cachy blocks the needed ports. Was solved by 1’ of searching online but still irritating that such a simple thing is a problem, as KDE is top of the list of DE while installing and KDE Connect comes preinstalled.
Other Distros arent that strict with the ports so its (almost) only a Cachy problem.
It’s frustrating that in 2026, Debian doesn’t have a firewall installed by default.
iirc Debians reasoning is that on a desktop you dont really have any ports exposed anyway, so theres nothing to firewall. And on a base install your expected to follow the documentation that includes a guide to setting up a firewall
Choice? I don’t use one but that’s due to never exposing ports that don’t need to be. Some that do that would still want one to provide “belt and suspenders”. Others want a specific one vs another primarily due to the software they use, that others do not. Given how trivial it is to install one does it really matter? I’m fine if they do as long as it is easy to remove, i.e., not a critical system/global dependency. I always install and remove some anyway, don’t you?
The
nixos-unstablechannel actually does ensure a minimum set of required packages work: Those that would prevent you from booting. The compiling-from-source is because Hydra (the binary cache) only starts building once a package appears innixpkgs-unstable, and if it immediately proceeds intonixos-unstable, or one of its dependencies is different there, that build won’t be finished yet.release-and versionednixos-don’t have that problem, as they have a merge freeze, and are mostly fast-forwarded along unstable.What would be good is a mechanism for Hydra to tell you “I tried to build this derivation, and it failed.” For this, Nix first needs to store build failure, and since store paths are input-addressed by default, you can also skip builds that will certainly still fail.
Debian - the very slight value hassle of having to install the web blobs for glances manually. This is really minor, because it only comes up occasionally, but it’s rare enough that I can’t remember what the path is each time.
That said, I totally agree with Debian’s stance on the issue, and I think glances should change their process. Debian’s way makes me acknowledge the risk of installing the blob. It’d be nice if there was a package I could install after going, yep, I know this is potentially dangerous.
Honestly I thought I’d be disappointed with Debian on my gaming machine, but it works fine. I updated Wine to the newer version on their site (instead of using Debian’s packages), and it works great.
Also Nixos, when it took an embarrassing amount of time to purge the backdoored xz dependent packages. If there were any problems with Nixos, this would’ve been it.
I use bunsenlabs Linux and it reports as the version type, which in this case is boron. There’s a lot of scripts that see boron and not oslike which is debian. I have to manually edit a lot of install scripts for them to work as boron isn’t a valid debian version.
