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

Sander van der Burg - EWI S.vanderBurg at tudelft.nl
Tue Jun 26 21:55:57 CEST 2012


I've just noticed that there is a very big mailing list discussion going on here. Actually, I'm very busy now with writing my PhD thesis and I didn't really have the time to respond yet. Nonetheless, I think it's important that I express my thoughts about this matter, although I haven't read all the previous messages in this topic very thoroughly.

I see a lot frustrations expressed in this discussion and I also noticed that Eelco is blamed for all kinds of issues. Although I don't want to deny that there are issues in our project (such as the way repository access is "arranged" now, and several technical dissatisfactions in Nixpkgs), I think some conclusions that are drawn are too simple and I don't see the free-nix fork as the solution for this. Furthermore, it is also a bit cheap to blame Eelco for all these issues.

Let me give you some thoughts:

- I still remember all the discussions we have had about adopting a DVCS. Actually, (if I still remember it correctly) we had a huge mailing list discussion somewhere in August 2010. But long before that, we have had many discussions as well. What I've noticed is that all these discussions were mostly about the technical aspects of these tools and why they are better than Subversion or a particular other type of VCS. To me it also looked like everybody had his own favourite DVCS system and nobody really agreed which one was the most suitable. The only thing that everybody had in common is that using Subversion was inferior. Unfortunately, we cannot simply pick the solution that everybody likes.

- A long time ago, back in 2007, I tried to raise a discussion about organisational aspects of using a DVCS. I'm in principle also a proponent of using a DVCS, but I also think that in order to use such a system properly, we need some kind of organisational structure that works for us. Unfortunately, these discussions always resulted in technical aspects rather than organisational discussions. I think we still haven't thought properly about such a structure, and that's why several problems have arised now. 

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.

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.

The reason that many contributors do not have access to the main Git repository is not that Eelco wants to exclude people. It's simply because we (the community as a whole) have no clue how the distributed development process for the NixOS project should be organised. There are still a lot of aspects that we should think about and decisions that must be made, which haven't been done yet.

For me it's ok that simple package updates (e.g. a version bump) go into the main repository directly. What I don't like is experimental/unfinished stuff that may potentially break all kinds of packages immediately become part the main repository. New concepts or significant changes (such as implementing a new stdenv or a new NixOS module system) should be developed in a separate tree and be merged once they are considered stable/mature enough.

We have to discuss these issues, come to a consensus and write these ideas down.

- Important decisions should also be communicated through the mailing lists, before they become part of the main tree. For example, I still remember this huge Python packages update, that broke nearly every package that uses Python. I don't want to encounter such a major change anymore, without discussion.

- I also agree with some here that Nixpkgs is big and could be better "modularised". This would properly also make it easier to implement a better organised distributed development process. I already have some ideas in mind which I haven't communicated to the mailing list yet, but implementing these will also take a lot of time and effort, which I don't have right now, unfortunately.

So I see some room for improvement and things we have to think and discuss about. I'm not blaming anyone in particular, but I think that many of us in the Nix project are responsible for this, not just Eelco or some other person.
________________________________________
From: nix-dev-bounces at lists.science.uu.nl [nix-dev-bounces at lists.science.uu.nl] on behalf of Marc Weber [marco-oweber at gmx.de]
Sent: Tuesday, June 26, 2012 7:07 PM
To: nix-dev
Subject: Re: [Nix-dev] Announcing free-nix: the free Linux distribution based on the Nix package manager

> Eelco revoked all access of all regular contributors without prior
> warning.
Everything is still open source - so we all could fork anytime (which
you actually proofed). We all have local copies - so ...
But its also known (to me) that Eelco started getting more and more
interested in git very recently (less than many years) - I'd vote for
giving this change some additional time.

I invite you to use the gist to push your changes to unless we all know
what will happen in the future - and how different "our vision" is from
Eelcos (maybe he doesn't know yet himself). I know that I'm thankful for
almost all of his work and time he spend on this project - even though I
may not agree on all details.

You say that you want "democracy" - and that the policies should be
(initially) created by the community - but community in 2 years may have
different feelings than the core has today - so your community may not
be more stable than nixos (for those reasons).

Thus if 30 devs join - will you start negotiating about policies again?

> indication that we would be losing access to the infrastructure that we
> have helped build over the last couple of years.
The nixos/nixpkgs repositories are on your disk (you have git copies).
So it can't be lost.
Hydra? The source is there, too. but who pays the electricity and the
servers? ... (Thanks to whoever does it).

We all don't know what Eelco will do with this project in X month.
We will never do - but neither do we know what a community like free-nix
would do with the core in Y month.

It is important that we (the community) can fork whenever we want when
we feel it is necessary.

And Eelco moving to github does not make me think he's trying to prevent
this in any way because all code is still public.

Maybe Eelco has time to talk about what he wants to do with nixos in the
future - maybe we can understand his choices better and maybe even
assist him.

There are so many use cases for nixos:
  - mobile phones (android)
  - desktop pcs (linux like ..)
  - server systems (security is very important here)

That maybe one distribution won't be enough in the future anyway.
That's why it may make sense to delay the decisions when and what to
fork till such different use cases get more urgent.
Eg Gentoo has a "hardened" version: http://en.wikipedia.org/wiki/Hardened_Gentoo
which indicates that some forks happen naturally due to different
requirements. Thus if you want free-nix to be a success - you setup a
system which allows such different projects to co exist.

So whatever you want - you will never have "common sense" in your new
community - which is why I think that your fork alone will not solve any
potential issues.

In the end we all want to improve the fitness of the nix package
management system so that we can adopt it to different needs easily
without switching tools (That's my impression).

Marc Weber
_______________________________________________
nix-dev mailing list
nix-dev at lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


More information about the nix-dev mailing list