[Nix-dev] Announcing free-nix: the free Linux distribution based on the Nix package manager

[Bryce L Nordgren]

> In the Linux kernel development process, the only official tree is Linus'
> kernel tree. Linus only works with a small group of people each maintaining
> a subsystem of the kernel, such as the memory manager, I/O scheduler etc.
> These subsystem maintainers have their own tree (which they regularly merge
> with Linus' tree) and they have other people that they work with. This
> organisational structure is what Linus calls "a network of trust". This
> development model makes sense for Linux.
>

US Military and the civilian Incident Command System call this "Span of
control": One person can do no more than five things well. So, the one
person in charge divides responsibilities to 5 or less subordinates. This
goes on down the line until actual work transpires. As you say, the use of
a DVCS is merely a technical device to facilitate the hierarchical
organizational structure.


>
> For Nixpkgs/NixOS and other Nix subprojects, we haven't really properly
> thought about such a development model and I have never heard any concrete
> suggestions what we should do and what we shouldn't do.
>
>
I can lay no claim to long history with this project, I can only tell you
what features distinguish it from other efforts in my mind, and how I hope
to be able to use it one day. At your core is "Nix". Nix's primary feature
is that it manages software installations and software consistency for many
masters: system admins as well as users. If you get any larger than a
single-person company, these two masters are commonly at odds. What I hope
for is that Nix/NixOS inspires an enterprise software deployment model
where end users (such as myself) can package and install software specific
to my needs, while leaving the security and network configuration to the
CIO. And of course, the big benefit is the common pool of packaged software
called "The Distribution". Everyone should benefit from the distribution.
But there should also be a feedback loop to capture new packages and common
configurations developed by those who use the distribution; and there
should be a plan for handling variations on a theme. This should be scale
invariant, like a fractal pattern: the same processes which allow competing
end-users within a single organization to coexist should also allow
competing organizations to coexist "within" a single distribution.

So the question in my mind is not: "How does the community come to
agreement on the One True Way to which everyone must adhere?" The question
is more: "What organizational structure retains flexibility for
subcommunities having differing interests while maximizing the common
benefit?"  This is compatible with the original Nix philosophy of allowing
"variants" to coexist side by side.

Switching to a DVCS is definitely a step in the right direction, but it's
just a tool, and can't resolve the human disputes. Other tools may need to
evolve which make some of the human disputes moot. Management and
integration of "small forks", may require that Nix expressions start to
understand URLs instead of just paths. And end users may want to pick and
choose packages from multiple small forks, because they don't totally agree
with the decisions made by any individual project. It seems to me that Nix,
Hydra, and the proper application of channels should be able to minimize
the amount of end-user compiling required to install a truly custom hybrid
system.

Seen from this perspective, the "nixpkgs/nixos" repositories are rather
monolithic: You'd have to manually assemble a complete Nix expression in a
directory on your system, composed of "some" free-nix expressions and
"some" NixOS expressions. Then you'd have to manually merge in changes as
time goes on. Is there a better way to modularize Nix expressions into
libraries, such that assembling a complete expression could be
automate-able? Maybe instead of a static "composition", do the composition
with a Nix-compiler? (a Nix-linker?) I think NixOS and/or free-nix should
both allow for a new reality: the end-user's computer may not be installed
from a single upstream source of expressions. Modular things, allowing for
coexisting variants, make for harmony. Monolithic things make people
compete so that they're not the ones who get left out.

Anyway, that's what I see Nix's potential to be.

Bryce
Bryce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20120626/5d1106f1/attachment.html