It’s a somewhat immutable distro, that is however fully configurable.
The configuration is all in one place. No more changing a bunch of files in /etc, some in /lib, etc, and having to remember all files you’ve changed.
You can easily recreate your system from your configuration or boot to older configuration.
You can easily open shells with different programs available. Very useful for development, when you need a reproducible environment with the project’s specific dependencies.
Very hard to learn, but if you have learned it well, a lot of things become easier than in other distros.
/nix/store is immutable. But there are some files in other places like /etc and /var that are mutable. Also I (or a malicious executable) could, in theory, delete store symlinks and replace them with mutable files. Impermanence helps, but you’ll still want some mutable state.
Fully immutable systems have everything outside of /home read-only. NixOS is not one of them.
I don’t really get the malicious software point though. All immutable distros have a mechanism for changing, after all they need to be updated. If a malicious executable has root access, which is what you need to change symlinks on NixOS (I know services often get their own user, but unless modified, only root has access to those users), then these malicious executables could also leverage whatever mechanism for change other immutable distros have, to do malicious things, no?
Though I do agree with you, now, that NixOS isn’t immutable.
There are ways to secure the update process. For example, you can enable secure boot and store your secure boot keys encrypted (or on a smart card). Then (if a full chain of trust is implemented) to update your system, you’d need to enter the private key password (or insert the smart card), and a root-access executable couldn’t to that automatically.
I think it can in theory, but there will be some problems. But most likely Silverblue or something else would have its own problems trying to implement something like that - I don’t have any experience with them and don’t know how they’d compare.
The control and deterministic nature of it is amazing. I have a git repo for all of my machines entire config. I have no fear that installing something will break or make things that would require blowing away and reinstalling. Also blowing away and reinstalling is no big deal, as is building new boxes. It has a high bar for learning to use it effectively, but the view is worth climbing the mountain.
How configurable is the build process for individual applications? I run Gentoo, have all my config files stored in a git repo which includes the defaults supplied to any application’d configure/make/make install steps.
You could apply patches or change the build process. But there are some limitations to ensure reproducible builds. For example, compiler optimizations that break reproducibility are disabled.
I think you could disable build reproducibility to get rid of those limitations, but I haven’t tried it.
The way I run Gentoo would be the type of thing to break reproducibility, getting rid of features globally that I never need. I keep getting the itch to run NixOS but then I remember rebuilding my Gentoo build from scratch is a weekend task I don’t have time for as I’m too frugal to actually upgrade my hardware.
While technically possible, you wouldn’t want to compile everything locally on NixOS. Only packages that you’ve made changes to (such as applied a patch) will be built locally, and everything else (by default) will be pulled from the precomputed binary cache.
You can disable the binary cache, or make changes to every package. The thing is, if you update a nix package, you’ll have to rebuild everything that depends on it, and with lower-level components, that can be literally everything. It’s not a sustainable workflow.
NixOS is not the most efficient distro either. I already mentioned some compiler optimizations are disabled by default, because they break build reproducibility. It also tends to use more disk space than other distros. So actually trying to super-optimize every package on it is somewhat pointless.
My config is in a single github repo for all of my machines and my user.
It’s really tightly integrated and just works with the nix package manager, which has a huge repo and builds packages reproducibly, so theoretically what would work on my machine would also work on yours. Also, with nix you can run software without installing it, you can have multiple versions of the same library, and there are way more benefits just from this package manager that I can’t list here.
You can iteratively test your config, apply it on a live system and roll it back. You can also use git to roll back to an older version while keeping the actual source files.
There’s no dependency hell / leftover packages after uninstalling something - what you declare in your config is what is installed, and if an app has unspecified dependencies it won’t build. I guess this would also be a part of #2
And there are probably other benefits I can’t remember.
NixOS. After trying it, I could never go back to a “regular” distro.
What makes NixOS standout?
It’s a somewhat immutable distro, that is however fully configurable.
/etc, some in/lib, etc, and having to remember all files you’ve changed.NixOS is an immutable distro. Immutability is binary, it either is, or it isn’t.
/nix/storeis immutable. But there are some files in other places like/etcand/varthat are mutable. Also I (or a malicious executable) could, in theory, delete store symlinks and replace them with mutable files. Impermanence helps, but you’ll still want some mutable state.Fully immutable systems have everything outside of
/homeread-only. NixOS is not one of them.I see.
I don’t really get the malicious software point though. All immutable distros have a mechanism for changing, after all they need to be updated. If a malicious executable has root access, which is what you need to change symlinks on NixOS (I know services often get their own user, but unless modified, only root has access to those users), then these malicious executables could also leverage whatever mechanism for change other immutable distros have, to do malicious things, no?
Though I do agree with you, now, that NixOS isn’t immutable.
There are ways to secure the update process. For example, you can enable secure boot and store your secure boot keys encrypted (or on a smart card). Then (if a full chain of trust is implemented) to update your system, you’d need to enter the private key password (or insert the smart card), and a root-access executable couldn’t to that automatically.
Yeah, but do other distros do this though? Not that I’m aware.
And surely the same could be done to NixOS, no?
I think it can in theory, but there will be some problems. But most likely Silverblue or something else would have its own problems trying to implement something like that - I don’t have any experience with them and don’t know how they’d compare.
The control and deterministic nature of it is amazing. I have a git repo for all of my machines entire config. I have no fear that installing something will break or make things that would require blowing away and reinstalling. Also blowing away and reinstalling is no big deal, as is building new boxes. It has a high bar for learning to use it effectively, but the view is worth climbing the mountain.
How configurable is the build process for individual applications? I run Gentoo, have all my config files stored in a git repo which includes the defaults supplied to any application’d configure/make/make install steps.
You could apply patches or change the build process. But there are some limitations to ensure reproducible builds. For example, compiler optimizations that break reproducibility are disabled.
I think you could disable build reproducibility to get rid of those limitations, but I haven’t tried it.
The way I run Gentoo would be the type of thing to break reproducibility, getting rid of features globally that I never need. I keep getting the itch to run NixOS but then I remember rebuilding my Gentoo build from scratch is a weekend task I don’t have time for as I’m too frugal to actually upgrade my hardware.
While technically possible, you wouldn’t want to compile everything locally on NixOS. Only packages that you’ve made changes to (such as applied a patch) will be built locally, and everything else (by default) will be pulled from the precomputed binary cache.
You can disable the binary cache, or make changes to every package. The thing is, if you update a
nixpackage, you’ll have to rebuild everything that depends on it, and with lower-level components, that can be literally everything. It’s not a sustainable workflow.NixOS is not the most efficient distro either. I already mentioned some compiler optimizations are disabled by default, because they break build reproducibility. It also tends to use more disk space than other distros. So actually trying to super-optimize every package on it is somewhat pointless.
My config is in a single github repo for all of my machines and my user.
It’s really tightly integrated and just works with the nix package manager, which has a huge repo and builds packages reproducibly, so theoretically what would work on my machine would also work on yours. Also, with nix you can run software without installing it, you can have multiple versions of the same library, and there are way more benefits just from this package manager that I can’t list here.
You can iteratively test your config, apply it on a live system and roll it back. You can also use git to roll back to an older version while keeping the actual source files.
There’s no dependency hell / leftover packages after uninstalling something - what you declare in your config is what is installed, and if an app has unspecified dependencies it won’t build. I guess this would also be a part of #2
And there are probably other benefits I can’t remember.