For me, the last one is a gamechanger, as I am no longer worried about littering my system with tons of dependencies. Say I want to convert an eBook I downloaded. I can quickly use Calibre for a one-off thing, with nix run nixpkgs#calibre.
For me, the last one is a gamechanger, as I am no longer worried about littering my system with tons of dependencies. Say I want to convert an eBook I downloaded. I can quickly use Calibre for a one-off thing, with nix run nixpkgs#calibre.
it's like having your whole OS in git. it's amazing. want to try out some nightly build? no problem.
on most computers (personal, home computers) the various lib dirs get scary after a while. repoquery can help, but is kind of a hassle. if some executable `foo` depends on some specific behavior in some version of some library, it's fine. that weird library can stay in place, I can try out nightly's of foo, can always rollback to the system that used to work, and can flip to the new foo when it's ready.
I think it's a good practice to wipe and re provision from time to time to make sure provisioning and backups actually work, but like, you can screw around with _crazy_ things and not really have to worry about having to rebuild the whole thing. (well, I haven't yet) I still will, because that's how I am. but I can do it when I feel like it, not when I fucked up. it's so easy to un fuck a nix system.
I guess the big caveat is, this is a hobby. I haven't used nix for work. Back in the day, I did support docker in production when the kernel patches were coming pretty quickly. Finding the right balance of patch level, and libc version, that would support docker, and the other stuff that needed to run was a pretty complicated dance, and missing a step would be, not great. Knowing what I know now, even as a hobbyist, I probably could have made my life a lot easier back then.
Now I have 2 years old NixOS installs on personal machines and they do not get bloated with packages that the package manager can no longer handle, and is basically always at a state as if it were freshly installed. It just “feels right”. To me, that makes the occasional edge cases worthwhile to suffer through (some binary package, mostly) - especially that in most cases something like steam-run is enough to make it work. When it isn’t, systemd-nspawn can boot you into any systemd distro you would want.
In fact, I've departed from vanilla Silverblue, as now my base image is an actual, bona-fide Docker container as well.
I feel like the immutable Linux OS is the pragmatic approach, whereas NixOS is the pure, ideal way that requires a lot of changes to tools and workflow to work. Maybe even in this case, worse is better.
[0] - https://github.com/benpye/openocd/blob/mrs-2023-08-07/defaul...
Furthermore, Docker images are monoliths that's isolated from the system. Instead of system administrators choosing the isolation boundaries that best fits their requirements, the image packagers put walls around each and every image. As a result, Docker containers are inflexible compared to traditional Unix applications. Piecing together multiple Docker containers is a clunky experience.
In contrast, Nix is an integrated build/configuration/deployment system. Entire systems down to the package level can be reproduced from Nix expressions.
It also gives system administrators power over the whole process. Administrators have control over things like how each components are pieced together, and where isolation boundaries are placed. They can even make tweaks to the package build steps.
Docker can't substitute Nix. It's not a matter of elegance. Their features and capabilities are wildly different.
> Dockerfiles used to create Docker images don't have any mechanism to ensure reproducibility whatsoever
simply generate it once and keep it as an immutable artefact