Re: A GNU Distribution

[Brandon Invergo]

Hi everyone,

I just joined this list from being pointed this way by Karl Berry. I've
just volunteered to maintain the GSRC (GNU Source Release Collection)
project because I found that it covers a lot of functionality underlying
a free source-based distribution I've been planning in my head. I've
read this thread and I thought I'd document some of the ideas here to
see if they might be helpful. I'm sure there are holes in this and it
would need some work to get things right but here's the rough idea (I
imagine this will be long, so grab a tea).

First of all, there's the question of why to create a new distribution.
I think the concerns about providing a binary-based, easy-to-install
distro are unfounded. We already have, for example, Trisquel that covers
that niche. Parabola offers another option, with the ability to both
install binary packages via pacman and install from source via abs (the
Arch Build System). However, as a user of Arch (and Parabola once my new
laptop arrives...), I can say that the reality is that you usually just
install the binaries and aquiring the source requires extra,
out-of-the-ordinary steps that you tend not to take unless you really
have to. Parabola, does have the nice guiding principle of KISS, which
gives it a good reason to exist, though. 

So, to start from a guiding principle to give a new distro a reason to
exist alongside current ones, I decided that what we lack is a distro
with the goal of being extremely hackable for happy hackers. In other
words, one that takes the four essential software freedoms extremely
seriously and literally; one which, in every way, encourages the user to
dig in, make changes, and share those changes with others. I think that
the best way to achieve this would be via a source distribution, and
that it pretty much by definition *has* to be a free software
distribution, since binary blobs go against its core guiding principle. 

Here's the general idea I've had. First of all, the most easily hacked
software would be scripts rather than compiled software, so most of the
distribution-specific system programs should just be Bash scripts which
take advantage of other tools which already exist. So, to take package
management as an example, source would be retrieved, configured and
compiled via GSRC (for those who aren't familiar with it, it is based on
GAR, which was in turn based on BSD Ports, and it is written in GNU
Make). GSRC takes care of first building all necessary dependencies.
Currently GSRC only includes makefiles for GNU software and a few
external dependencies, but a non-GNU directory of makefiles for other
free software could also be built. Software would then be installed to
the system and maintained by GNU Stow. 

I would like to eventually update GSRC to automatically set up a Bazaar
repository in each package's source directory, with tags set for each
successive version of the package that is downloaded and installed by
the user. Rolling back to an older version is as simple as reverting to
a previous tag. The user could then easily branch the code, make their
own changes, push those changes upstream, merge changes from other
users, etc. Heck, if you want to jump on the "social" bandwagon, one
could have a central repository online where users could push and share
their custom branches with changes to packages that wouldn't necessarily
be of interest to the upstream maintainers.

All of this package management, with the built-in version control, would
be handled by a single, easily customized script that automates it all.
In fact, I think in general for a system like this, preference should be
given to programs which are easily scriptable. For example, nmh would be
better than Evolution (well, if nmh supported Maildir and such). Instead
of Metacity/Mutter for window management, something like Herbstluftwm (a
tiling window manager configured and manipulated via Bash scripting;
"BSD" license, but I'm not sure which version so it might not be free)
would be better. Uzbl (a Webkit-based browser whose functionality is
built from the ground up with config files and scripting) would be a
better browser than a Firefox-based one. Parabola's BSD-style init
scripts would be better than SystemV or Systemd init systems. Again the
point being that the user should feel at all times that every tiny
detail of the system is available for tweaking and hacking should the
desire to change something arise.

Ok, that is enough for now, just describing the basics. There are a lot
of details left to be worked out, such as system installation (live cd
with a basic GNU/Linux build environment?). I understand that it's
incredibly presumptuous to just drop in here, unload this huge block of
text and expect people to be interested. Hopefully some of these ideas
could be of use, though. I'm looking forward to seeing them discussed
since they've until now just been floating around unchallenged in my
head (where everything is sunny and all ideas are inherently extremely
great ideas).

Regards,
Brandon Invergo