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.
Arch and derivatives expect you to check the news file before upgrading, but do not integrate this into the upgrade tool. I have not personally ran into a problem this way, but it’s frustrating that pacman doesn’t have any capability to do this if you’re expected to.
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.
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?
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.
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.
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.
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.
This is a fairly minor issue since it’s quite an easy fix, but it really annoys me that Debian doesn’t include the sbin folders in the default user path. Meaning that if you try to run a command that needs sudo, instead of telling you it needs sudo it just says the command doesn’t exist
oh so that’s why!
I thought this was how unix always has been? Sbin is for root binaries. It doesn’t make sense to include a bunch of commands you don’t have permission to execute in the path. I remember this being the case back in the 90s and didn’t realize it was no longer the norm.
Not sure about the history of it, but it’s different to every other distro I’ve used! Admittedly I’ve not tried loads and I’ve not been using Linux for that long, but to me it makes far more sense to tell me I don’t have permission to use a command/program than to pretend it isn’t installed
I think it’s fair to want a more helpful error message, but that’s not necessarily the purpose for path. There is a real cost to every entry in your $PATH. Not as much as in the world of spinning rust, but some.
There are some completion modules for shells that will suggest misspelled or even installable packages if it can’t find the command. Those are arguably better options.
As for traditional systems, I remember a time where running arbitrary commands, even with an --help argument could be dangerous and we had to set least try ‘man command’ first.
I think it’s obfuscation for security.
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.
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
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.
At least you were intellectually honest about NixOS rather than blaming them.
I swear by it but had a year or two where I was struggling. Particularly with languages like Python, it can be tough to train yourself in the Nix way (or to wrap compilation and dependency management into the nix paradigm in this case). With languages like Haskell though, the Nix way goes hand-in-hand with it.
I’ve found Zig to work well with Nix. And there are ways to use Nix REALLY elegantly with Python
Here’s an example of how you’d provision a super simple nix flake dev environment in x86_64 Linux for undetected web scraping with Python
# save this as flake.nix then run nix develop in the root of the repo { description = "Web Scraper"; inputs = { nixpkgs.url = "github:NixOS/nixpkgs?ref=nixpkgs-unstable"; utils.url = "github:numtide/flake-utils"; }; outputs = { self, nixpkgs, utils }: utils.lib.eachSystem ["x86_64-linux"] (system: let pkgs = import nixpkgs { system = system; }; in rec { packages = { pythonEnv = pkgs.python3.withPackages (ps: with ps; [ webdriver-manager openpyxl pandas requests beautifulsoup4 websocket-client selenium keyboard ]); }; devShell = pkgs.mkShell { buildInputs = [ pkgs.chromium pkgs.undetected-chromedriver packages.pythonEnv ]; shellHook = '' export PATH=${pkgs.chromium}/bin:${pkgs.undetected-chromedriver}/bin:$PATH ''; }; }); }
-
OP:
i SwItChEd On BlEeDiNg EdGe BuIlDs ThEn CaN’t UnDeRsTaNd WhY i NeEd To BuIlD tHe LaTeSt SoFtWaRe FrOm SoUrCe. It MuSt Be NiXoS’s FaUlT tHaT i DiDn’T bOtHeR tO lEaRn HoW nIxOs WoRkS bEfOrE sWiTcHiNg On FeAtUrEs ThAt ArE lItErAlLy LaBeLeD “uNsTaBlE”. pS. oH yEaH. bEfOrE sOmEoNe MeNtIoNs It, I kNoW tHe SoLuTiOn BuT wOn’T bOtHeR tO pOsT iT bEcAuSe I jUsT wAnTeD tO pUbLiClY sHiT oN aNd HaMpEr NiXoS’s ChAnCeS oF wIdEsPrEaD aDoPtIoN bEcAuSe It Is HaRd FoR mE. wHaT oThEr LiNuX dIsTrOs Do YoU tHiNk ArE rUn By UtTeR bOnEhEaDs ThAt BuIlD sTuFf ThAt MuSt Be FlAwEd Or WrOnG bEcAuSe YoU cAn’T gEt It To WoRk On ThE fIrSt TrY?
# /etc/nixos/configuration.nix nix.settings = { substituters = [ "https://nix-community.cachix.org/" ]; trusted-public-keys = [ "nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=" ]; };
