Comment by shevy-java

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.