NixOS is a pretty cool idea in theory. In actual practice
I found it too complicated to manage. Immutability is kind
of cool too, but it creates an obstacle to solving even
trivial task in my daily life using Linux. And I don't want
to really use such a domain specific language like Nix, for
things that really should not need a programming language
per se. For instance, I like ruby, but I don't want configuration
stuff to be kept in .rb files; that's also one gripe I have
with homebrew, even if the idea to HAVE a recipe in a .rb
file, is not bad per se. I am just too used to e. g. yaml
files or any other simple format for literally everything.
All my RC files and ENV data and aliases for shells is kept
in .yml files; ruby then just autogenerates any target
format I need for different shells/terminals, and so on and
so forth. Also, NixOS is not very flexible. I prefer e. g.
/Programs/Ruby/4.0.5/ rather than a hashed directory name.
It's not a bad idea here either, and there would be many
workarounds for that (see GoboHide on GoboLinux, for instance),
but at the end of the day it felt as if I was fighting NixOS
too much than getting real work done. There is something to
be said about simplicity at all times, even if the ideas in
NixOS are still great. For instance, we could guarantee that
every snapshot would work, so people having the same hardware
could just re-use configuration and have things work, without
needing to know how to change the system precisely. That would
not be needed because NixOS could make a guarantee about ALL
possible stable snapshots in time. I don't think NixOS goes
that far, so far, but it would be a very logical extension.
Same with immutable packages / reproducible packages:
https://wiki.debian.org/ReproducibleBuilds
We could make such a guarantee if we extend NixOS. But until
all of that happens, I stick with simplicity and flexibility.
It just kind of works better, even if it is nowhere near as
sophisticated as NixOS.