LWN: Comments on "NixOS: purely functional system configuration management"

Dispelling some misconceptions

rpwoodbu — 2010-03-30T06:54:58+00:00

This article is beginning to show its age, but since it is one of the top
hits for Nix, I thought it is worth dispelling some misconceptions some of
the comments on this article might convey, as people eager to learn about
Nix may find themselves here.

Misconception #1: NixOS is a source-based OS.

Yes and no. Nix offers an elegant approach to building, installing, and
distributing software. The elegance stems from all install having the
_ability_ to build from source, but enjoying the _optimization_ of
downloading prebuilt binaries if they are available. User tweaks can be
made to some packages at install time (perhaps to include or remove a
compile-time feature), and if a prebuilt binary doesn't exist with exactly
those same tweaks, Nix will necessarily build it from source. In most
cases, though, the optimization kicks in and prebuilt binaries are
efficiently downloaded and installed, just like with a binary-based
distribution. It is the best of both worlds.

Misconception #2: Nix eliminates the benefit of shared libraries.

Nix still uses shared libraries extensively. Programs are not ordinarily
built statically. If two programs are built against exactly the same
version of a library, they will share it, conserving disk and memory
resources. But in the interests of full reproducibility, you are not meant
to modify the shared library in-place. If a library needs to be repaired
(perhaps to close a security hole), all packages that depend on it must be
rebuilt to enjoy the use of the new library. Nix makes this quite simple:
after a library package is updated, an ordinary "upgrade" action will
rebuild everything necessary. After that, you can run a garbage collection
operation to free the disk space used by all the old software. And,
perhaps more importantly, you can roll back to the old software easily
(assuming you haven't run the garbage collector) should you find the update
to be unsatisfactory. Yes, it takes more time to effect an upgrade if you
have to rebuild a lot of software. There are usually binaries available,
which automatically speeds up the process considerably.

The best part is that you can have both minor versions of the library
installed simultaneously, and choose to have some programs use one and
others use another. This can be especially useful if a security fix breaks
some security-insensitive software; for instance, a libpng exploit means
needing a new browser, but perhaps not needing a new version of a game that
doesn't read "wild" files.

Misconception #3: System X can already do something Nix can do.

Yes, there are other systems, like Store, like Gentoo, that can do _some_
of the things Nix can do. But Nix can only really be understood if you
look at the arc of functionality it provides: functional build expressions,
identification of builds by a cryptographic hash of its build inputs,
suppression of spurious (i.e. external) dependencies, binary distribution
as an optimization of building, etc. What emerges is a packaging system
(and ultimately a distribution) that is hard to sum up succinctly, and is a
different way of thinking about maintaining a computer system, but which
has properties of stability, reproducibility, and operational guarantees
that are hard to match.

Final thoughts:

Give it a go. It is easy. You don't have to use the whole distro; just
install the Nix package manager on whatever Linux distro you're running.
Except for the package manager code itself, which is conveniently available
in several popular package formats, the entirety of it installs by default
in /nix (you can install it anywhere you like, but you need to use /nix to
enjoy prebuilt binaries), so it is not going to interfere with anything.
Because it is fully contained, it is distro-agnostic. It is a great tool
to have in your back pocket when dealing with older installations that just
don't have the libs you need to run the code you want. My favorite example
was a situation where I was running a newer kernel on an old RHEL 4 box,
where upgrading wasn't an option, but I really needed online ext3 resizing.
The userspace tool resize2fs didn't support it on RHEL 4, because Linux
2.6.9 didn't have it anyway, and that was the official kernel version for
RHEL 4. The newer resize2fs depended on a library that wasn't available
for RHEL 4. I couldn't upgrade or reboot the box. But I was able to throw
Nix on there quickly (I installed it in /tmp to avoid any mishaps) and
installed its resize2fs, which had the feature I needed (and the right
libs). It saved me the huge trouble of trying to get the new resize2fs
built on this crusty old machine, and I didn't have any downtime.

NixOS: purely functional system configuration management

njs — 2009-07-05T03:33:53+00:00

That could mean two things: either there's a tool to check that whenever you depend on the existence of a symbol _FOO, there is indeed a symbol _FOO. Or, whenever you used to depend on the existence of a symbol _FOO, not only does _FOO still exist but that it refers to the "same thing". (E.g., if it points to a function, that that function's assembly is unmodified. And all the functions that it calls are, in turn, unmodified.)

I assume you mean the former. Such functionality is handy, but it's exactly what I'm referring to by "assumed" compatibility -- hey, the names are right, it must work! If the library author and the application author did their jobs perfectly then of course this is true, and often it works out well enough in practice, but... the value you see in something like NixOS will depend on how willing you are to assume that's the case.

Personally, I consider our present approach to be a lamentable imperfection imposed by a world of constant security updates, limited bandwidth, and awful QA capabilities. I'm not sure when or if I'll be able to switch to a NixOS-style system, but I'm glad someone is reminding us of this fact.

NixOS: purely functional system configuration management

astrashe — 2009-07-04T15:48:33+00:00

This strikes me as being really useful, especially for clouds or large server farms. There's a lot of value in having a server be in a known state.

It also seems to me that it fits in to some other changes that seem to be taking place. We used to think of computers as things, physical objects. But to a certain extent, "a computer" is becoming a blob of data that exists in some sort of container (ie., hardware).

My main desktop, for example, is a blob of data that lives at a VPS hosting company. Some people carry around their systems on USB sticks, and boot them wherever they happen to be. Etc.

If a computer is a blob of data, then having better tools with which we can describe and build these blobs is a really good thing.

NixOS: purely functional system configuration management

oak — 2009-07-04T12:40:00+00:00

> By not storing components such as libraries, header files or programs in
global locations, all packages are forced at build time to use a specific
version of their dependencies, located in the Nix store. To make this
happen, the developers have patched Glibc, GCC and the dynamic linker ld
to not search files in any default locations.

Something similar can be done also with scratchbox2 without a need to
patch Glibc, GCC & ld: http://packages.debian.org/squeeze/scratchbox2

(As it uses LD_PRELOAD, it works only for dynamically linked binaries or
scripts having dynamically linked interpreters.)

NixOS: purely functional system configuration management

oak — 2009-07-04T12:36:08+00:00

> Of course, that only works in the first place if you assume that the new
library *really is* compatible with your old binaries, which is often
assumed but rarely guaranteed.

Nowadays Debian provides some support for this. You can easily check
whether any of the symbols changes at build time and build will fail if
they changed, but the library version didn't.

NixOS: purely functional system configuration management

Duncan — 2009-06-26T12:30:45+00:00

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

NixOS: purely functional system configuration management

TRauMa — 2009-06-26T01:12:38+00:00

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.

NixOS: purely functional system configuration management

njs — 2009-06-20T21:07:56+00:00

Yes, that's exactly what it does. Whether this is good or bad depends on the situation. You lose the ability to drop an upgraded library into place and have everything start using it immediately. Of course, that only works in the first place if you assume that the new library *really is* compatible with your old binaries, which is often assumed but rarely guaranteed. With the NixOS approach you gain the ability to test and switch programs over to the new library one at a time in a controlled fashion, keep some particular critical program using a fixed version of a library while the rest of the system upgrades, etc. Win some lose some.

NixOS: purely functional system configuration management

Darkmere — 2009-06-19T16:42:26+00:00

Please correct me if I'm wrong, but doesn't this approach completely remove the win to be had by dynamic linking in favour of static binaries (over time) until you have rebuilt everything in a boostrap manner to reduce the duplications and have a single set of base+libraries?

In one way it strikes me as a step forwards, and in another a huge step back. The question is if it's a net move forwards.

NixOS: purely functional system configuration management

sasha — 2009-06-19T07:43:14+00:00

I failed to understand how this distro helps with managing configuration files. "upgrading a configuration is as safe as installing from scratch" makes me think that it is completely my responsibility to copy all my configuration files to the new version of a program being upgraded. I'm not sure it is correct understanding... Does this distro have any helpers to merge my changes in the config file with the upstream ones? Is it managed in "functional way"?

NixOS: purely functional system configuration management

ajb — 2009-06-18T16:39:21+00:00

A similar system is vesta: www.vestasys.org

That's a purely functional build system, but under the hood it's also a package manager of a kind. You can actually import rpm-s and debs into it.
I don't think anyone has actually made a distribution using it, but it could be done.

It seems to me that nix is not so well engineered as vesta underneath. vesta has its own filesystem, and can present multiple views of the world in their own chrooted environments.

NixOS: purely functional system configuration management

Cyberax — 2009-06-18T12:54:38+00:00

Neat project!

However, some things strike me as unnecessary. Building packages from sources can be avoided with the help of retargetable binary packets.

It can also allow slow migration of existing packets (first, make deb/rpm packages retargetable, then move to Nix).

NixOS: purely functional system configuration management

skvidal — 2009-06-18T12:27:36+00:00

"System administrators update them in-place with various administration commands, e.g. a RPM or APT package manager or a configuration tool such as Cfengine."

Just to keep this particular meme from continuing:

rpm and dpkg are comparable commands, not rpm and apt.

NixOS: purely functional system configuration management

michaeljt — 2009-06-18T07:57:16+00:00

My personal feeling is that it would be easier to achieve a reproducible setup with existing distributions if packaging practices were less messy. The current practice of running scripts as root when a package is installed, as well as messing with /etc, which should actually be reserved for configuration by the system owner/administrator (possibly using tools of course) is not good for reproducibility. OpenSolaris for instance now forbids postinstall scripts. Packages which really need to do things post-install must install a service or similar to handle that. I would love it if say Debian adjusted their policy to discourage installation scripts and files dropped into/changed in /etc at install time. I am sure this would be manageable on a medium term basis.

NixOS: purely functional system configuration management

cyperpunks — 2009-06-18T07:43:12+00:00

store has some of the same features: http://www.pvv.ntnu.no/~arnej/store/