[aklug] Nix

This is intriguing!
"A next-generation package manager called Nix <http://nixos.org/> provides a
simple distribution-independent method for deploying a binary or source
package on different flavours of Linux, including Ubuntu, Debian, SUSE,
Fedora, and Red Hat. Even better, Nix does not interfere with existing
package managers. Unlike existing package managers, Nix allows different
versions of software to live side by side, and permits sane rollbacks of
software upgrades. Nix is a useful system administration tool for
heterogeneous environments and developers who write software supported on
different libraries, compilers, or interpreters.

Why provide yet another package manager? Because current package managers
fall short in the upgrade cycle. Everyone gets burnt by software
dependencies, at some point. In particular, with a major release of any
given distribution, many people choose not to upgrade until it is time to do
a fresh install. With Nix, upgrades are always safe: they don't overwrite
previously installed packages. This means previous versions will continue to
work, and you can easily roll back.

Nix started as an academic project at Utrecht University in the Netherlands.
The name is tongue in cheek; in Dutch it means "nothing."
The problems: destructive upgrades, software versioning, heterogenous
environments

All popular package managers, including APT, RPM and the FreeBSD Ports
Collection, suffer from the problem of destructive upgrades. When you
perform an upgrade -- whether for a single application or your entire
operating system -- the package manager will overwrite the files that are
currently on your system with newer versions. As long as packages are always
perfectly backward-compatible, this is not a problem, but in the real world,
packages are anything but perfectly backward-compatible.

Suppose you upgrade Firefox, and your package manager decides that you need
a newer version of GTK as well. If the new GTK is not quite
backward-compatible, then other applications on your system might suddenly
break. In the Windows world a similar problem is known as the DLL
hell, but dependency
hell <http://en.wikipedia.org/wiki/Dependency_hell> is just as much a
problem in the Unix world, if not a bigger one, because Unix programs tend
to have many external dependencies.

Also, destructive upgrades make it hard to undo, or roll back, an upgrade.
Unless you or your package manager makes a backup of all the files that got
replaced, you cannot easily undo an upgrade.

Finally, while the package manager is busy overwriting all the files that
belong to a package, your system is temporarily in an inconsistent state in
which a package may or may not work properly. Hit the power switch on your
computer halfway through your next OS upgrade and see if the system will
still boot properly!

Usually, an upgrade of a package will make the older version disappear.
Sometimes a package manager allows a few versions next to each other -- say
gcc-3.4 and gcc-4.3. However, this only works if the packager has arranged
for this by making sure that the two versions install to different paths.
What if you want to test gcc-4.0.3 without disrupting your system? Or if you
want to test software using different compiler, library, or interpreter
versions and combinations? What if you want to try the latest beta version
of an application without risking your existing installation?

Then there is the problem of multi-distribution support. Developers and
systems administrators have no way of knowing what combinations of kernel,
libraries, and packages a user is running. When a user tries to install some
software and complains about a missing library, you can suggest he try to
find the appropriate packages, but you have not tested them in the same
combination of dependencies. You can ask him to build from source, but he
may not be using appropriate versions of libraries and compiler. Even if you
are lucky enough to work for an institution that standardizes on a single
distribution, you may find users' libraries are outdated and do not support
the software you want to deploy.

Existing package managers do well enough in furnishing stable systems
because they depend on a long period of testing by a lot of people. However,
when users need more recent software, because of a bug or some missing
functionality, they turn to so-called "testing" or even "unstable" packages,
which often come with a range of dependencies that also get updated on the
users' systems, potentially introducing instabilities in other software that
depends on those components.

Nix has a more graceful approach that lets different versions of software
coexist. Rather than installing packages in global locations such as /usr,
it instead stores each package in its own directory under /nix/store. The
top-level directory for each package contains a cryptographic hash based on
all the inputs used to build the package. That creates a unique identifier
such that multiple versions of a package don't interfere with each other,
and different packages on your system can use different versions of some
dependency without causing a conflict. This means that you can atomically
upgrade and roll back packages..."

Read the rest here <http://nixos.org/about.html>.

-- 
ØÖ! ì~
"Listen to me! When you die in Alaska you die in real life!"
"Change before you have to"
"If you want to build a ship
don't herd people together to collect wood
and don't assign them tasks and work,
but rather teach them to long for the
endless immensity of the sea."
Antoine-Marie-Roger de Saint-Exupery
Powered by Xubuntu 8.10 encrypted sda Ultra fast and lean-never phear the
Penguin ;)
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.