[gobolinux-users] NixOS vs GoboLinux

[Samuel A. Falvo II]

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.

> 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.

> 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.

> 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.

> 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.

> In theory the NixOS system is hard to break and easy to tell if it's
> broken.  It already has build-farms and some sort of theoretical
> security regarding them (not sure how much).  Gobolinux is easy to hack
> and have a system that runs but is arguably a little broken in some way.

I feel that more rigorous software development techniques and
languages would significantly assist the stability of the operating
system.  For example, it's OK to keep everything in Python, but there
needs to be an extensive suite of unit tests AND integration tests.
I'm not sure if this is being done now.  A strict policy (one that
depends on the honor system though) of writing/updating tests first,
and production code second, must be adopted in order to ensure the
code never regresses.

> GoboLinux currently has a participatory community for its recipe-store;
> all I know about Nix is that it's not currently dead.

I really *LIKE* the participatory system.  It allows me, a relative
nobody in the Gobo community, to contribute packages (or updates to
existing packages) without having to endure the red-tape of other
distributions.

There is some amount of peer review with Gobo's system, as Lucas has
called me on a few issues with my packages in the past.  So I know the
system isn't totally wide open.

> 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.

> Nix is academically minded, generally (this has its pros and cons).

I'm not exactly sure what this means.  Are you saying that NixOS is a
research distribution?

If you're referring to the 'functional mindset,' then I have a blog
article I'd like to contribute.  It's a quick-n-dirty tutorial I wrote
up while in 'maintenance-mode' at work, about how I used my experience
in "real-world" functional programming to maintain a non-functional
piece of software.  It might be interesting.

You can read the article here: http://tinyurl.com/3cmn6f

To summarize, functional programming ain't just for college grads.

-- 
Samuel A. Falvo II