4 ms·
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
by shevy-java 3mo ago
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 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.
- rgoulter 3mo ago> Also, NixOS is not very flexible. I prefer e. g. /Programs/Ruby/4.0.5/ I'd characterise it as the opposite: A unique aspect of NixOS is that it avoids global state as much as possible (& prefers to symlink things). -- By conspicuously avoiding / preventing this global state, everything has to be declared as an input for the 'package'. For example: the Nix package for "ruby 4.0.5 built with gcc 16.1" would be a different package than "ruby 4.0.5 built with gcc 16.0". -- That afforts a greater level of flexbility. e.g. allows easily having multiple concurrent shells which run different versions of the same program.