[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Adoption of Nix?

On Wed, Dec 24, 2008 at 03:08:20PM +0600, Artyom Shalkhakov wrote:
> Cite from the homepage:
> > Nix is a purely functional package manager. It allows multiple

Hi all, I've studied a bit NixOS and written something about its
problems in a recent paper [1] (last paragraph of section
3). Interestingly enough, all the critics I've raised have been
confirmed by the authors of Nix, which I've met at the HotSWUp
workshop this year.

Summarizing the main objections I've raised against Nix are:

- a weird intermix between build-time dependencies and runtime
  configuration, both in some cases get mixed into arguments to the
  build functions, while it is clear that in Debian we prefer a more
  clear distinction among the two

- not everything which compose a distribution can be made functional,
  by the authors' own admission. The "solution" to similar problem is
  in some case just living with that (e.g., while updating the user
  database), in some other cases they just get rid of the
  non-functional part.

  It is for example the case of the ldconfig cache, they just live
  without that. Such approach is surely interesting for the properties
  you gain (atomicity of upgrades), but not something I want in a
  production system. Also consider that they have packaged _way_ less
  software than Debian, it is likely that more and more inherently
  imperative parts of a system will be found by packaging more stuff.

- the garbage collection thingy (as other already observed in this
  thread) is a PITA for security as you cannot completely get rid of
  security flawed code (or, if you do that you loose the "applications
  never break" property)

- maintainer scripts are not turned in functional (and revertible)
  expressions, so the only way to "undo" them is living without them,
  or restore whole parts of the filesystem (with the disk consumption
  problems other observed)

All in all, the authors are conducing a (really nice!) experiment, but
they are aware themselves that it is not ready to scale to a system of
the size of Debian.

What is, IMO, way more interesting for us is the evolution of DistNix,
a distributed version of the Nix package manager (think, e.g., at
upgrading of cluster of machines all together) [2]. What they have in
that part of their system is a language for specifying assignments of
services (data-base, web server, MTA, ...) to machines and
inter-machine dependencies. Those information are used to guide
cluster upgrades granting transactional properties.

Unfortunately (for us) the needed underlying assumption is that
upgrades on the single machines are transactional, which is not
something we can currently grant on top of APT.


Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime

Attachment: signature.asc
Description: Digital signature

Reply to: