I’ve been here a week ago already asking if Arch would be fine for a laptop used for university, as stability is a notable factor in that and I’m already using EndeavourOS at home, but now I’m curious about something else too - what about Arch vs NixOS?
I heard that NixOS is pretty solid, as due to the one file for your entire system format you can both copy and restore your system easily whenever, apart from your normal files and application configurations of course.
Are there any major downsides to NixOS compared to Arch apart from the Arch Wiki being a bit less relevant? I’d also lose access to the AUR, but admittedly I don’t think I’ve ever actually needed it for anything, it’s just nice to have. Also, since NixOS has both rolling release and static release and you can mix and match if you wanna get packages from unstable or not, I’m not losing Arch’s bleeding edge, which is nice.
Using NixOS for more than six months, and I think I’m eligible to say what I like and hate about it.
What you’ll like:
https://search.nixos.org
, it’s that easy. I’m not taking that comment about “NixOS being hard to configure” seriously - and this is coming from someone who hasn’t even learnt the language properly. Yes, myconfiguration.nix
is slightly polluted with Starship configs, and I might want to break them into modules, but it is still a job done decently.nixos-rebuild switch --upgrade
- I guess it was the physical trauma to my device messed up the mount path to/boot
, but it was rescued by a single CLI command from the recovery USB, and I didn’t lose any files.What you won’t like:
Binaries do not work properly - since Nix store is a completely different storage system compared to your usual FHS, most of the binaries will suffer from incorrect RPATH and dynamic loader issues - you might have to autopatchELF them, which is kind of irritating. This is also the case for AppImages, by the way.
Nix language is more like a custom DSL and less of a general purpose language, so you’re gonna have to use another language for automation (Shell, Python, Ruby), which might pollute your self-hosted Nixpkgs - Guix fixes this issue.
The bad part about NixOS is writing Nixpkgs expressions. The repository is damn huge and it is hard to maintain spaghetti code, writing your own package can be pretty hard, there’s some “hack”-y stuff you’re gonna have to use for building in, let’s say, using
buildRustPackage
andbuildDotnetModule
, and you’re gonna have to work with a senior maintainer.Honestly, if I had to avoid Nix, I would go for Guix, Gentoo or Devuan. But yes, if you’re a beginner, I’d ask that you refrain from touching NixOS.
+1, since for me it’s much easier to grok the language and the schema at a single glance.
Plus for those worrying about linux-libre kernel not having the right drivers for your hardware, non-guix has you covered and you can easily switch to linux-mainline. I’m really enjoying Guix a lot right now.
After having used Parabola GNU/Linux-libre for more than ten years, I seriously considered moving to GNU Guix System. The only thing holding me back is that I saw some seriously out of date packages in the repository. Off the top of my head, GNOME was like three major versions behind. How do you deal with that?
There’s a lack of contributors. Honestly, if not for the stupid recession and joblessness, I would have loved to dive into Guix packaging.
Its pretty easy to update the packages yourself, just bump the version and the hash, or if needed add some missing libraries.
Because the review process is slow, sometimes it’s easier to just check the Guix Patches buglist for existing submitted patchfiles and then add them to your tree
I’m a bit surprised to see that you disagreed with the “NixOS is hard to configure” bit, but then also listed some of the reasons why it can be hard to configure as cons.
By “configure”, they probably didn’t mean just setting up say, user accounts, which is definitely easy to set up in Nix.
The problems start to arise when you want to use something that isn’t in Nixpkgs, or even something that is out of date in Nixpkgs, or using a package from Nixpkgs that then has plugins but said plugin(s) that you want aren’t in Nixpkgs.
From my experience with NixOS, I had two software packages break on me that are in Nixpkgs - one of them being critical for work, and I had no clue where to even begin trying to fix the Nixpkg derivation because of how disorganized Nix’s docs can be.
Speaking of docs inconsistencies you still have the problem of most users saying you should go with Flakes these days, but it’s still technically an experimental feature and so the docs still assume you’re not using Flakes…
I was also working on a very simple Rust script, and couldn’t get it to properly build due to some problem with the OpenSSL library that one of the dependent crates of my project used.
That was my experience with NixOS after a couple of months. The concept of Nix[OS] is fantastic, but it comes with a heavy cost depending on what you’re wanting to do. The community is also great, but even I saw someone who heavily contributes to Nixpkgs mention that a big issue is only a handful of people know how Nixpkgs is properly organized, and that they run behind on PRs / code reviews of Nixpkgs because of it.
I’d still like to try NixOS on say, a server where I could expect it to work better because everything is declarative such as docker containers - but it’s going to be a while before I try it on my PC again.
deleted by creator
deleted by creator
Nix would need some proper GUI for that. It’s very “shove into cold water”, which isn’t exactly the best experience.
You might want to look into SnowFlake OS, which is supposed to be an easier NixOS.