[gobolinux-users] NixOS vs GoboLinux

[Isaac Dupree]

Samuel A. Falvo II wrote:
> On 10/22/07, Isaac Dupree <isaacdupree at charter.net> wrote:
>> I think Nix and Gobo might have some things to learn from each other.
>> So here are my thoughts in random order (some more interesting than
>> others, and altogether more ignorant on Nix than Gobo) :
> 
> I seem to recall others making similar comparisons.

I didn't find any in my personal gobo e-mail archives, so I guess I've 
seen Nix mentioned a few times in Haskell mailing-lists...

>> Nix is purely functional, so it doesn't like the idea of "Alien" package
> 
> I'm not quite sure what this is referring to.  Are you (or they)
> confusing the term "functional" with "transactional"?  They are quite
> different.

I didn't see them using the word 'transactional' ... maybe I just meant 
that they really wanted everything to fit into their packaging system, 
because it makes things so much more reliable and flexible when it 
works.  I'm not sure what exactly you mean by "transactional", and 
Wikipedia isn't helping...

> 
>> Gobolinux uses ldd & friends to try to determine runtime dependencies;
>> NixOS names each package directory like
>> /nix/store/r8vvq9kq18pz08v249h8my6r9vs7s0n3-firefox-2.0.0.1/
>> (corresponding roughly to Gobo /Programs/Firefox/2.0.0.1) and searches
>> for the hash string to find out if a program depends on firefox, for
>> example (I think).
> 
> I don't see the advantage.

Gobo's method only detects dynamically linked binaries - not python 
scripts, not dlopen(), not paths in config files the build process 
generates... (I don't know how common those are)

> 
>> Gobolinux likes to use chroot and other OS mechanisms to ensure reliable
>> (i.e. purely functional) package creation, and is going towards using it
>> more throroughly; NixOS doesn't seem to bother (which works most of the
>> time for it).
> 
> I *really* prefer chroot'ing.  It provides a kernel-enforced sandbox.

I agree, when there is root access there's pretty much no reason not to 
use all possible kernel-based sandboxing mechanisms.  I still want to 
know how they deal with C macros __DATE__ and __TIME__ being 
nondeterministic - patch gcc (which they already do somewhat)?  Ideally 
there would be a kernel solution to that, but `make` relies on 
timestamps, so you can't just stop time.  After the build process, all 
file creation/modification timestamps are reset to 1970.  The website 
says the mode is set to 644 or 755 too such that all suid/sgid bits are 
erased... I guess this means sudo doesn't work nor nix's unprivileged 
installation... it might not be true anymore

>> Nix uses a (Berkeley) database, with all the unreliability, reliability,
>> and speed that that entails.
> 
> While it may be fast, I don't like its opacity.  I am more than
> willing to pay the (negligible in practice) performance hit for Gobo's
> package hierarchy transparency.

I don't know if Nix database is purely a cache (though I doubt it).

The difficulty is that a hierarchical structure with no redundancy is 
asymptotically inefficient in some ways!  Symlinks in Gobo help.

When Nix-package-manager dies, the database has to be recovered, which 
sounds expensive (because a changelog entry was that nix now handles 
more fatal signals so it can close the database cleanly so it doesn't 
need to be recovered).

>> Like zero-install's theory, NixOS allows multiple unprivileged users to
>> install software without it being duplicated on disk, because
>> installation is deterministic.
> 
> This sounds like a very weird argument to make.  I'll have to read up
> on what, precisely, "Deterministic" means in this context.

Well it's not entirely the right word.  Nix expressions are "purely 
functional" descriptions of how to get from source to binary (the same 
binary is always arrived at from the same Nix-value), and they use 
cryptographic hashes to help ensure this: of source tarballs at least. 
And possibly of the generated binary, to verify that compilation has 
been done correctly. (then what was the point of compilation if you knew 
what it would create?? maybe it creates something that takes up much 
more space (disk/bandwidth) than the sources?)

Nix expression-files for a program typically are functions that take 
arguments for their dependencies, such as "stdenv" (gcc, coreutils..), 
perl, and others.  Also I guess this mechanism can be used for a sort of 
"use-flags"..

> 
>> Nix is academically minded, generally (this has its pros and cons).
> 
> I'm not exactly sure what this means.

I think it prefers to do things right (more than gobo? I don't know! 
NixOS website says that 'sh' is the only thing in /bin); ignores chroots 
and such (so far); and is in fact supported by several research papers.

I also like functional thinking, (mostly using Haskell as my language)



What I want to know is how Nix deals with the dependency cycles that are 
beginning to plague Gobo.


Isaac