I’ve been curious about NixOS for quite some time. Reading about it I couldn’t see how the config sharing capabilities, setup, or rollabck would be better than Arch and sharing the list of installed packages, using downgrade or chroot.
So I decided to run NixOS in a VM and I’m still confused. An advantage I can see for NixOS is its better use of cores and parallel processing for packages install.
It’s clear that I’m missing something so please help me understand what it is.
Edit: Thank you to everyone in this great community! It’s always so nice to have a constructive and sane discussion.
After reading so many comments, they all confirm what I’ve read before and I may realize that my real problem is already having a stable system and no need for the great NixOS options that are very neat but would not benefit my specific and simplistic needs.
That being said I can’t refrain myself from being curious and will continue testing NixOS.
The need for only 2 config files is the top of the iceberg but hiding more complex configuration to rely on. Not that I really have too much spare time but I do enjoy learning and tweaking NixOS. With its current development state, things are changing a lot so it can keep me busy for months. That’s probably what I was mostly looking for: another toy to play with.
Along my journey I will learn a lot about NixOS and may find a feature that will motivate my switch to it. Thanks again for all your precious feedback!
I’ll also take this opportunity to share the best help I’ve found so far to start with NixOS: https://github.com/MatthiasBenaets/nixos-config And his 3 hours (!) video: https://m.youtube.com/watch?v=AGVXJ-TIv3Y
Better in some ways, but it has the worst documentation of any distro I’ve seen so far. https://nixlang.wiki is trying to improve that
How to read NixOS documentation:
- Go to wiki, see if topic exists
- If it does, notice how it doesn’t cover your case
- Use the hints from the wiki to get your search engine redirect you to https://ryantm.github.io/nixpkgs/
- Notice it still doesn’t cover your use case
- Use search engine again, this time with the hints from aforementioned page, to arrive in the proper code in the nixpkgs repository
- Read annotated source code to see what actually happens
Yeah, this is how I found https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/setup-hooks/make-wrapper.sh yesterday because I wanted to install some shell scripts that needed to be adapted.
Don’t get me wrong, maintaining a distribution the way NixOS is a huge effort and I can’t praise the maintainers and developers enough. The ecosystem they’ve built is unlike I’ve seen anywhere, and the technical foundation is sound – in fact I’d wager more sound than what commercial distributions offer. The latter just have more grease. But I do understand the criticism about lacking documentation. But human labor is scarce, and I mean look at me posting this here instead of improving it.
There’s also no good guidance or best practices for packages in nixpkgs and stuff is permanently changing (which in my opinion is good). E.g. did you know that new derivations should be sorted by letters, not categories, and not go into
all-packages.nix? At least if your derivation doesn’t require fancy attributes (pardon me if that is not the correct term). Or thatstdenv.mkDerivation rec {…}is not best practice, but ratherstdenv.mkDerivation (finalAttrs: {…})? And why the latter even works?Writing good documentation for a system, especially one that’s permanently evolving, is not easy, and I prefer all efforts going to actually maintaining and evolving the system itself than trying to get the perfect documentation that’s outdated in a matter of time. And without trying to gatekeep it, NixOS is a distribution for advanced users. I recommend it to everyone who has a solid understanding of how a Linux system is composed because I think it’s important what NixOS abstracts away from you. And as an advanced user, reading commented code once in a while is fine in my opinion.
The problems with nix/nixos documentation are:
- documentation isn’t sexy so not many want to do it
- documentation is difficult to be written by beginners because… they’re beginners
- nix/nixos maintainers undervalue documentation efforts - I’ve tried to get in pull requests, but they just stall (not reviewed, nitpicked to death, simply not merged, etc.)
- it isn’t generated from source code
Also, the very top heavy decision making process harms the community. Some person with hundreds of commits can push through nearly any change (good or bad) relatively quickly, unless other frequent contributors are really really against it. However, fresher contributor with a great change is forced to go through a never-ending process and few stay to actually finalize it.
Pushing tomasterwas not seldom for a long time and IINM it isn’t possible anymore. But maintainers can simply (and do) create a PR, make a change and merge it.These difficulties just make me want to fork nixos. For documentation, at least there’s https://nixlang.wiki
Good points. If you go through the open pull requests on nixpkgs, there’s a lot of stuff that never got through and it’s not obvious as to why. I was happy to see a lot of stuff merged less than a week ago. But at this point, there’s a huge backlog.
As to forking NixOS, which in my opinion means forking Nixpkgs, Guix system seems like a good start. I decided for NixOS because of proprietary packages as I use Steam, and support for secure boot which while still young and only through lanzaboote works very well for what I use it.
Guix system seems like a good start
I’m glad they exist. It shows that the concepts can be successful using another language. To me, the major downside is exactly what you said: no proprietary stuff. Additionally, it’s LISP.
In a fork, I’d try to change the way decisions are made, which software is used, add linting and autoformatting to repositories, move away from github (maybe by the time I find the time to we’ll have federated sourceforges) and github actions, maybe use nickel or haskell instead of nix, generate documentation from sourcecode, try and use a distributed cache (tahoelafs, ipfs, storj or some other distributed/decentralised file storage), etc. Getting any of that done in the current repos seems like an uphill battle.Let us know when you do! It’s a huge undertaking and NixOS has a pretty big network effect. Doesn’t mean no one should tackle creating an alternative. I fully believe declarative distros are the future for any production environment and that the space is far from taken by current distributions.
What is good about NixOS (and GuixOS) is that they apply to package management the same principles that Git applies to managing source code. The Nix store is basically an append-only database (you might even call it a “blockchain”) of inter-dependent packages.
So from an individual computer user’s point of view, it is much safer to install and roll-back software with Nix than with an ordinary package manager that might allow you to accidentally delete package dependencies and break your system. With Nix, you can install packages that actually do break your system, but because of the append-only nature, you can actually roll-back the install automatically right from the Grub boot menu, no need to re-install anything.
Another advantage of NixOS, though this is more from a system operator’s point of view, is that you can guarantee reproducible builds. If the package you have installed has the same hash on all of your computers, that is a simple, human-verifiable proof that all of those systems are running the exact same build of the software. You can probably see that this is very useful for people running servers, like compute clusters, or doing things like A-B testing.
(don’t know if arch supports this natively now but) declarative package managment is why j started using it… having ansible/terraform basically be a part of the os is great for me because a reinstall of the current running system just means i copy my configuration.nix and i’m back to where i was but fresh…
another thing is build isolation (you can have clashing dependencies without issues because each package specifically links to the dependencies it needs)… it does kind of bloat the disk a bit, but it also shares dependencies of the same version across packages so it’s not like flatpack (if i understand that correctly)
Just wait until you mess up something like DNS or delete every text editor and you’ll be grateful for rollbacks.
Can you elaborate? I messed up DNS when I started with Arch and it was easy to recover from that. For text editing, I’m using neovim and can go back with undotree. Of course, if I delete my file and remove it from the trash it’s too late. Can you recover deleted files with NixOS?
That’s not what rollbacks are for.
On NixOS, to change most configs, you need to rebuild.
To rebuild, you need internet.
If you mess up DNS, you need to rebuild to gain internet.
But you need internet to rebuild, so you can’t.
That’s when rollbacks are useful
Got it. So you can rollback without Internet access. I get that point and Arch can also do that with pacman -U. Again I feel like I’m just stupid and am missing something. Like I said I genuinely try to figure out what it is. NixOS would be the only distro I could consider switching to and that’s why I’m currently testing it.
One issue with rollbacks Arch has is that there’s basically only up to three valid configurations available at any time. These are your current system configuration (oldest state), upstream repositories (newest) and your local database copy (somewhere in-between, though all three states can be identical, e.g. straight after Syuing). By definition, you can’t convert your system configuration back to an older one because it’s the oldest one of the three already. What you can do is mix your current oldest configuration with packages from the cache, older or newer doesn’t actually matter. But you’re not getting back the old state really, you’re creating a new one that’s different from Arch’s repository.
A configuration on NixOS includes all exact package versions and their exact configurations. No exceptions.
If you actually need these guarantees is a different question. I used Arch for 15 years and never had significant issues. I switched to NixOS instantly after trying it on an old notebook and immediately recognized that the whole approach suits me so much better that I switched almost all machines over by now.
