NixOS: purely functional system configuration management [LWN.net]

NixOS: purely functional system configuration management

Posted Jun 26, 2009 1:12 UTC (Fri) by TRauMa (guest, #16483)
Parent article: NixOS: purely functional system configuration management

What I don't quite get is how this helps with the kind of upgrades we are actually doing - security upgrades mostly. In those cases we never want to roll back, we don't want to switch over gradually, we basically want to apply a single well-contained change (that comes pre-tested and hopefully doesn't break anything) globally and right now. All the things NixOS provides you can have with a modern Gentoo installation and careful snapshotting, except the possibility to have a system where every step of the upgrade is atomic and the system as a whole is still in a well defined state. But in critical setups you'll have two systems anyway, one where you test the change and one in production. And with security updates you are in a "bad state" as soon as the security issue goes full disclosure (ok, you learn that you were in a bad state all the time) and no intermediary step is interesting until you upgraded all consumers/dependencies of the packet in question. From this view a half-upgraded NixOS is working, but insecure, while a half-upgraded Gentoo is perhaps not working and insecure. But how does "working, insecure" help I wonder.

to post comments

NixOS: purely functional system configuration management

Posted Jun 26, 2009 12:30 UTC (Fri) by Duncan (guest, #6647) [Link]

In addition, there seems no provision for the customizability that is the
forte of Gentoo and a good portion of the benefit of building from source
in the first place. Either that, or that aspect simply wasn't covered.

Where's the system default CFLAGS/CXXFLAGS (Gentoo's make.conf settings),
with the ability to override them per-package (Gentoo's /etc/portage/env),
without having to edit the pre-packaged nix expressions (Gentoo ebuilds)?
Where's the ability to specify compile-time dependencies (Gentoo USE
flags, both make.conf and package.use), again without having to edit the
pre-packaged nix expressions?

Maybe nix has that and it simply wasn't covered, as customizing to that
degree isn't something the binary distributions could do. But it's a
major benefit to building from source, which nix does, so it'd have been
nice to have a description of how that's handled, or a definite no, it
doesn't handle that. Without it, tho, I don't know as I'd consider it
worth the trouble to run compile-from-source, as that really is one of the
biggest benefits of doing so.

Meanwhile, Gentoo has config-protect functionality, with rollback if
desired, depending on one's choice of config reconciliation tool. And
binpkgs allow reasonably easy no-recompile rollback to previous package
versions for the binaries, while keeping them in a centralized location.
While centralized does mean everything uses the same library version,
there are tools to resolve breakage, automating the recompiles, and
it /does/ eliminate the security updates issue others mentioned for NixOS.

Now Gentoo does not have per-user installations and user installable
packages by default, but the Gentoo/prefix project addresses that,
allowing package installation at arbitrary prefixes, including home dirs,
for various Linux and non-Linux (FreeBSD, etc) installations.

Still, NixOS is using a very interesting idea, and as it matures, it could
well give Gentoo and other build-from-source distributions a run for their
money. If the (currently) much more mature Gentoo wasn't around filling
my needs better, I could certainly see giving NixOS a try, and who knows
what'll happen over a few years? As I said, I could see it giving Gentoo
a run for its money. Its devs definitely have the guts it takes to go
against the flow and develop something that really does fill a niche
filled imperfectly if at all by others, and as such, certainly has the
potential to become the leading from-source distribution, a position
Gentoo has filled for most of this century so far.

Duncan