Seems like this distro is getting a lot of traction recently. Has anyone tried it? Is it any good?
I’ve been using it for around a year and really like it so far. It is however very different from almost every other linux distro, so I would think carefully about it before switching. If you’re not prepared to invest significant time and/or don’t really care about the advantages of NixOS, you should stay away from it.
Pros of NixOS:
- Declarative configuration: This is probably the main selling point. The whole system configuration and installed packages are neatly in one place. Using home-manager, this can also replace config files for many programs. All of this is especially useful if you share that configuration between multiple devices.
- System rollbacks: If something breaks, simply boot into the previous generation.
- Very customizable system: You can freely choose your desktop environment & basic system packages.
Pros of Nix in general (you don’t need to install NixOS for this):
- Huge package repository (also very up-to-date if you want to use the unstable channel)
- Consistent developer environments that can easily be shared
Cons of Nix & NixOS:
- Very steep learning curve: You essentially have to learn (the basics of) the Nix programming language.
- There are often many ways to do things without any clear recommendation: Channels / Flakes, whether nix-env should be used, etc.
- The documentation isn’t always great (although it is improving)
- If something is not packaged in nixpkgs, it can be difficult to run it, since NixOS doesn’t follow the Filesystem Hierarchy Standard. There are some tools to run flatpaks, appimages and arbitrary executables, but especially the later might not always work out of the box.
I hear you with the “many ways to do things”. The flexibility in the language to get from input to outputs means every GIT I look at has differently constructed flakes. Finally, after pouring some time in these last couple of weeks i am grasping the basics. Zero to Linux
https://zero-to-nix.com/was the first time it came together for me.Thanks for the in-depth review. I think I’ll give it a shot.
Yes, and NixOS is the most frustrating Linux distro I ever tried, without a doubt. I love the concept, but the execution is hard. NixOS can’t configure desktop environments, such as Gnome and KDE. NixOS is stable, so NixOS works best in server environments.
But in server environments, tools such as Ansible are orders of magnitudes more comprehensive to everyone who understands the Linux basics. NixOS is therefore dominant in neither desktop nor server environments, but it’s a neat academic project.
I failed to find sources for what I’m about to say, but there was a point where the NixOS stable branch… broke. I’m not sure what went down, but I think that a manual merge train messed smth up. If that’s correct, then NixOS is less stable than Debian.
There’s also the situation where they store the entire package store in Amazon S3 because someone else paid for it. That someone disappeared, and they expect the community to stem the costs now. If they don’t pay up, NixOS stability is once again dead.
I feel like the tooling is all over the place. There are many ways to do one thing, and you never know what’s the right thing to do.
Overall a poor experience.
NixOS can’t configure desktop environments, such as Gnome and KDE.
The issue here from my point of view is rather that
- Desktop environments expect to be configured by the user through their graphical interface for that user only (Nix doesn’t touch user configuration) and
- DEs tend to mix configuration with state (especially Plasma).
Both of these make it close to impossible to configure DEs as Nix configures other services and programs.
For clarification for readers, Nix does allow you to install these environments and associated display managers as in making them available to the user.
But in server environments, tools such as Ansible are orders of magnitudes more comprehensive to everyone who understands the Linux basics. NixOS is therefore dominant in neither desktop nor server environments, but it’s a neat academic project.
Having used Ansible superficially for an Arch server, I disagree. The beauty of Nix isn’t (only) that what you declare in your configuration is available to the system. It is the guarantee that it’s only these declarations and their dependencies are active. E.g. when you remove something from your systemPackages list, it’s no longer installed, you don’t need to uninstall it explicitly. Applying a configuration to a system will lead to a known state (if not using flakes, this doesn’t apply to derivation versions though). The same cannot be said for applying an Ansible playbook to a system because it’s rather additive.
Its nature also makes it a good candidate for development as you can enter well-defined environments regarding available libraries. That’s why it’s also a good contender there.
I failed to find sources for what I’m about to say, but there was a point where the NixOS stable branch… broke. I’m not sure what went down, but I think that a manual merge train messed smth up. If that’s correct, then NixOS is less stable than Debian.
First off, I haven’t heard about the issue. I agree this is something that shouldn’t happen, however I’m also having a bit of a hard time understanding what this would mean. You can always boot your old generations and wait for upstream nixpkgs to be fixed; plus, if using flakes, you can also go back to a pinned version of nixpkgs on your current channel. At least that’s my understanding. Myself I have never had the need.
There’s also the situation where they store the entire package store in Amazon S3 because someone else paid for it. That someone disappeared, and they expect the community to stem the costs now. If they don’t pay up, NixOS stability is once again dead.
The situation isn’t great, I agree, however it should be noted that this concerns the binary cache that keeps compiled copies of all revisions of all packages. Even if it was gone tomorrow, one could still use NixOS as a source based distribution, which would of course require the original sources still being online. The thread is not about the nixpkgs repository — it is fully defined by the Github repository — but about the (arguably very important) binary cache. It would not lead to NixOS being unstable.
I feel like the tooling is all over the place. There are many ways to do one thing, and you never know what’s the right thing to do.
I agree on this point, especially stuff like
nix-shellvsnix shelldoesn’t help, and the language feels a bit opaque. But I guess that’s the logical conclusion when your configuration is code — the former is usually assumed to be a fixed pattern while actual code leaves the decision how to do something to yourself. I have thought about the issue myself, but I don’t know how it would actually be solved. Though if you don’t deviate from the very defaults, it feels like a classic configuration (if that makes sense).Overall a poor experience.
It was the extreme opposite for me, I switched my main machine to NixOS after many years on Arch (I joined the BBS about 15 years ago) even though there were no real issues with Arch for me just because the concept had convinced me so quickly.
I will say that the experience is not perfect, but that’s not an euphemism. I’m very happy with how everything works. The approach might have issues with certain applications (as you mentioned desktop environments; another big one is Steam) but I rather consider this shoddy application behavior than system shortcomings.
I’m happy that it works for you. I love the concept, but it doesn’t work me. I switched from Arch to NixOS too. I’m on Fedora now, though. But I still have a NixOS sticker on my laptop.
You’re free to use whatever you like, my post was in no way a criticism of yours, but I wanted to clarify some points to people not familiar with the distribution and add my own perspective.
Thank you all for correcting me on the NixOS stability front.
NixOS can’t configure desktop environments, such as Gnome and KDE.
That’s because those DEs are configured via config files in your home and NixOS is only about system management; it does not touch your home (other than creating its directory).
If you want to configure home files, you use home-manager which has some support for configuring those DEs.
NixOS is stable, so NixOS works best in server environments.
NixOS has a “stable” version and a rolling one. The stable one is bi-annual though with no LTS, so it’s more of a Fedora than a Debian.
The rolling channel (“nixos-unstable”) is where all the actual development happens. It has similar stability to Arch, though we do more QA through our CI.
You cannot get an update where the e.g. bootloader breaks. That just doesn’t happen for us because the update must have passed a test where the bootloader gets installed in a VM and then booted before it can reach you.there was a point where the NixOS stable branch… broke. I’m not sure what went down, but I think that a manual merge train messed smth up.
Stable is pretty damn stable, we usually only backport security fixes and the odd bug fix. If a bug fix introduces new bugs, that could “break” stable in a way but stable “breaking” in a major way is pretty much unheard of. Again, as I mentioned, basic things like networking or filesystems are tested by CI.
You’re going to have to be a bit more specific than that.
There’s also the situation where they store the entire package store in Amazon S3 because someone else paid for it. That someone disappeared, and they expect the community to stem the costs now. If they don’t pay up, NixOS stability is once again dead.
This is way overblown. That someone is still paying. They’ve just said they don’t want to continue doing so (which is absolutely understandable) and asked to find an alternative soon. They’re not suddenly cutting us off; this is not an immediate threat.
The NixOS foundation has funds set aside to continue even this very expensive way of hosting the cache for at least a year. Even if they were to suddenly cut us off (which they won’t), we’d be fine.
The post you linked is a call to action to find solutions to reduce that cost and to find a way to sustainably finance it without relying on a single sponsor.
More critical would be if the CDN in front of the S3 Bucket (which is what actually serves most paths to users) were to disappear but the provider of said CDN is directly sponsoring us they haven’t shown any sign of wanting out. People are brainstorming to find possible alternatives to that setup aswell though, just in case.
We’re fine. Even in the worst case scenario, we’d be fine. In the migration time frame, there might be hiccups here and there but that’s not too concerning or special.
I feel like the tooling is all over the place. There are many ways to do one thing, and you never know what’s the right thing to do.
Yeah, tooling has been in a bit of a weird spot where we’re currently in the transition between the old and the new way of doing things. The new way isn’t finished yet however an is still unstable.
The “old way” works just fine though and you can ignore all the new stuff if you don’t like instability. I myself still use the old way. Sometimes I use the “new way” too because it’s got some convenient features.
Being using it for almost 2 years. Was very weird at the beginning because of the “declarative” approach they used. But once you get used to it… Its a life changer.
Declarative? Could you explain?
Your whole system is defined in a file called
configuration.nix. This file describes everything about your system: all packages installed, which Desktop Environment / Window Manager to use, and also configuration for almost everything (e.g. zsh or neovim). When “switching” (which is basically installing/updating the system), Nix looks at the configuration and changes your system according to what you’ve declared in theconfiguration.nix, installing or uninstalling packages for instance.So, the state of your system is “declared” in a single file, which can be tracked in git or backed up wherever. If you have mulitple systems, you can also share parts of your config between them, which makes configuring and customizing stuff a lot easier.
There are a lot of other aspects, but thats the basic gist of it
That sounds really cool… so you could just take that file, do a clean install of nix, then put that file back and it’ll install all your old packages and stuff?
Basically yes
you could also go so far as to wipe your root partition (except for some selected dirs) on every boot, although I don’t do that myself: https://github.com/nix-community/impermanence
Not just your packages, but all your config as well.
Also, I believe updates are transactional, so if something goes wrong in the middle it can just abort and your system isn’t left in an inconsistant state. And if an update breaks something you can easily roll back to a previous version.
Is it a big learning curve? Is this the emacs equivalent of OS configuration/installation?
edit: another question - Could I play around with it by installing in qemu and if I like that, take my configuration.nix from qemu and install it as my main OS?
I’d say it’s a pretty steep curve unfortunately, and nixOS is also not perfect, mind you
- The nix language (that is used for the configuration) itself has sometimes weird syntax. It’s also a proper functional programming languages with all bells ans whistles that brings
- The documentation is less than ideal (to put it mildley). Most of the times you need to search reddit (rip) and the forums to find how to do certain things.
- Nix is not FHS
compliant. Basically everything is a symlink to some file in the nix store,
located in
/nix. Packages installed with nix are patched to work that way, but things not installed with it might not run out of the box
As for trying it out, yeah copying the config from the vm should work (except for maybe some hardware-specific stuff). remember to backup your stuff just in case lol
It’s also a proper functional programming languages with all bells ans whistles that brings
It’s really not. It has no runtime for starters; it’s a pure expression language. It can’t i.e. read stdin, open a socket or do an arbitrary syscall.
The end result is always data. You could and can turn every sensible evaluation of Nix into JSON.
There are indeed side-effects but they’re indirect; implied by the data that is the actual end result of an evaluation of Nix expressions. If your expression evals to a derivation (data), Nix will create a .drv file for you for example. They’re well defined and not arbitrary though.
Could I play around with it by installing in qemu and if I like that, take my configuration.nix from qemu and install it as my main OS?
Absolutely. That’s how I got started ;)
If you install Nix (the package manager) on your current system, you can actually directly build a vm from a config file via
nixos-rebuild build-vm.
Oh my bad. Yeah you can configure almost anything in a declarative way on the
/etc/nixos/configuration.nixfile:services.xserver.enable = true; services.xserver.displayManager.gdm.enable = true;Or
services.xserver = { enable = true; display manager.gdm.enable = true; };You can define a lot more (programs, users) and then you build the config file to take effect. By default NixOS is immutable so you can’t change anything in the root partition and if there is something that broke you can rollback to a previous build!
That is very interesting! Thank’s mate!
NixOS: The Most Over-Engineered Linux Distribution
Take this with a grain of salt.
I loved using NixOS with flakes, home-manager and custom minimalistic setup with XMonad or Sway. I was also using Nix with direnv whenever I could for my development projects. At the same time I’ve noticed that a lot of my programming focus (and time) was being used by solving niche issues with Nix, packaging things for Nix, suddenly breaking applications (because of upstream changes within nixpkgs). I’ve also had issues with using other ways of providing development environment (npm, pip stuff etc).
I was using unstable channel so breakages part is most likely on me. But apart from that I’m left with the feeling that NixOS is a huge time sink which isn’t necessarily worth it if you aren’t managing a whole fleet of machines.
Nowadays I am happy not using Nix at all. My development needs are fullfilled by what is available via dnf (Fedora package manager) and npm. I also use podman containers and flatpak a lot more since I’ve switched to Silverblue.
I like Nix and used it for a year or so before kind of just getting tired of using a non-standard distro. Mostly just felt like it was trying to solve a bunch of problems that I never had.
Seems like it’s targeting devops, only I can’t really picture a devops situation where the powers that be would be interested in Nix…
I am both a fan of NixOS and The Linux Experiment, but I’m kind of surprised he liked it so much.
I’ve played with it an a few occasions, and I like what they’re going for. However, I just couldn’t put it onto a production computer.
Right or wrong, I feel like I’d have to over-write a LOT of muscle-memory from using regular distros for the past 8 years to use it regularly. If I’d been working in dev-ops, I may feel differently.
I feel like nix could be a good ‘project’ distro, but I would hesitate on installing it on my main computer until I was quite familiar with it and had a few months with it on another computer.
I agree, but I’ve decided to play with it in qemu for a while. I’ve also been looking at Chimera and have that in a vm too. Currently I use Void, btw
