The appeal of it, to me, is the same as why Docker containers are really good. You write your definition, save it to git, for example, and if you ever need to setup your computer from scratch, if you restore that config, it’ll setup your computer exactly like it was before. But even besides that, being able to roll back if something goes wrong, is a big plus

for me personally I like to be able to install software temporarily using nix-shell command it’s awesome. the installed program will be gone once you leave the nix-shell. It’s just awesome for me.

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.

I think if you have no answer, it could be that NixOS doesn’t solve any problem for you. In effect, it’s not better. Don’t buy into social media hype. It’s just a tool like any other.

For me it’s the fact that I have one source of truth for my whole system config that I can stick in git

If I want to clean up software I don’t need anymore I just remove them from the package list and they’re gone next rebuild

Also means when I reinstall or setup a new system I just run the installer, do a git pull, rebuild and I’ve instantly got all my tools, configured just how I like them

Also, if I want to make a big change I can build my system in a VM first to make sure it works first (not that I do that because it also lets me revert to an earlier build from grub if I need to)

I’ve also got both my laptop and my PC on basically identical configurations from the same git repo with each of them having a smaller config file for hardware specific stuff

I’m currently working on rebuilding a Debian web server that’s been around for 10 years and accrued configuration over that time in NixOS. It’s nice to have one single easy to understand file that fully defines the server and can be used to rebuild it if needed.

If I didn’t already have my relevant configurations tracked in git and my (quite simple) post-install script to copy the configs to relevant dirs, I guess I’d use Nix. I don’t see the appeal when I have the same functionality on a distro I am familiar with.

So, it’s like this. Your operating system is an environment. It has it’s paths, it’s got it’s file system. In many ways said system can have plenty of conflicts and issues regarding dependencies, runtime and permissions, even cruft that it will accrue over the years even.

This is where nix comes in. Nix creates sterile, reproducible environments. With flakes, the reproducibility is 1:1. It can also manage several environments, all isolated from each other.

Not only that, but technically speaking, nix can build anything, as it’s a build system of build systems. You don’t have to rely on nixpkgs or NixOS. You still get the environmental magic, along with whatever nix evaluations you put into it, so you could make your own nixpkgs (or recipes, really).

Personaly I want to go deeper, so I was thinking of how I could beat make my own package set by getting all the SRPM’s of say RockyLinux to create rockypkgs, which is just the Rocky Linux selection of packages and patches built into nix environments.

Maybe you could then also have ubupkgs, fedpkgs, rhelpkgs… mix and match packages lol Yeah, it really is that insane.

Imho Nix has not reached it’s potential yet because of some stuff that needs to be fixed, but restructuring and refactoring is underway. Nix as a command will become more streamlined and central for ease of use, and nixpkgs needs a bit of recajiggering to get the package layering just right - or so I’ve heard (find us, in the Matrix chats).

LETS GO, RFC136!!!

NixOS puts your full system configuration in a portable set of files. You can easily reproduce the same configuration on another machine. I also like that instead of accumulating a growing list of packages that I don’t remember why I installed I have package lists specified in files with comments, and split into modules that I can enable or disable.

IMO NixOS works best when you also use Home Manager to apply the same benefits to your user app configurations and such. (OTOH you can use Home Manager to get those benefits without NixOS. But I like that I get consistency between the OS-level and user-level configurations, and that both use the same set of packages.) I use Home Manager to manage my list of installed packages, my dot files, Gnome settings, Firefox about:config settings, and so on.

You might be installing packages imperatively with nix profile install or with nix env -i. If that’s the case you’re not going to see the full benefits of a declarative system in my opinion. I prefer to install packages by editing my Home Manager configuration and running home-manager switch.

I like that NixOS + Home Manager automates stuff that I used to do by hand. A couple of the things that I do or have done are to,

• test an experimental window manager, Niri
• use Neovide (a GUI frontend for Neovim) with a custom patch to tweak font rendering

Now I have that kind of stuff automated:

• Since there was no packaging for Niri when I started trying it I wrote my own in my NixOS config with a NixOS module to set up a systemd unit to run it. Because Nix packages are effectively build scripts, whenever I update Nix automatically pulls the latest version of Niri and compiles it without me having to think about it anymore.
• I use the Neovide package from nixpkgs with an override to compile with my custom patch. Like with Niri my configuration automatically gets the latest Neovide version and builds it with my patch when I update, and I don’t have to think about it anymore. I use this overlay to do that:

modifications = final: prev: {
  neovide = final.neovide.overrideAttrs (oldAttrs: {
    patches = (oldAttrs.patches or [ ]) ++ [ ./neovide-font-customization.patch ];
  });
};

You can see that I compile some things from source. That’s fine on my desktop, but takes a while on my travel laptop. But I don’t need to compile on my laptop because I can use Nix’s binary cache feature. I push my NixOS and Home Manager configurations to Github, and I have Garnix build everything that I push. Garnix stores everything it builds in a binary cache. So when I pull my latest configuration version on my laptop it downloads binaries from that cache.

Just wait until you mess up something like DNS or delete every text editor and you’ll be grateful for rollbacks.

You’ll understand when you’re older, son

NixOS is better because…

…broken link … or non-existent reasoning?

@wwwgem