User: Password:
|
|
Subscribe / Log in / New account

Dispelling some misconceptions

Dispelling some misconceptions

Posted Mar 30, 2010 6:54 UTC (Tue) by rpwoodbu (guest, #64843)
Parent article: NixOS: purely functional system configuration management

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.


(Log in to post comments)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds