Creating a GNU/Linux distro
2014-04-03
UPDATE: The project died, it went nowhere.
On nixers.net, the IRC channel of which I spend a bit of time in, there has been a bit of a stir as the community tried to decide on a project to commit to. The idea of creating a distro of some OS came up. A few people wanted a BSD-based distro, but it was decided that the Linux kernel was
where the hardware support was, so that's the direction we went. After working out that we wanted a musl libc based distro with a focus on minimalism, someone drew our attentions to morpheus, a GNU/Linux distro that seems awfully similar to what we were doing, and had been established for a very long time compared to our still-hypothetical project (started in September 2013). After that, it seems that the buzz around making our own distro has died down. Nevertheless, I'm still up for it, and played around with building a few live USB images of TinyCore GNU/Linux (basically just Linux plus a rather fully featured initrd) and FreeBSD (something more substantial). Although I have nothing concrete yet, I have a few ideas on what I want in a distro, and what my environment usually ends up like after I'm done customising the package manager, programs, and so on.
Package Manager
This was a subject of much contention, but I think the best path for a new
distro run by a small community would not be to write our own package manager,
but to use one that already exists and works. I suggested pkgsrc, the NetBSD
package manager, which has been ported to GNU/Linux and has been proven to work
well. Indeed, I have personal experience using pkgsrc on Slackware, and I'm
confident it'd be perfect for our needs. It:
- has over 12000 packages ready for use
- comes with a binary package manager,
pkgin - is a tried and tested system for packages
- is bug-tested and securely audited by the NetBSD project
Writing our own package manager would require a monumental effort if we ever wanted to support anything more than a handful of programs, which is a large failing of morpheus' ports tree, and a reason it can never be anything more than a toy distro. Installing a package from source would be as simple as:
# cd /usr/ports/category/program
# make install clean
Similarly, installing from binary packages would require a simple:
# pkgin install program
This is assuming that we have built all packages, hosted them on a file server,
and pointed pkgin there by default, which is definitely doable.
pkgsrc has ports for an X11 server, thousands of applications and scripts,
and, most importantly, a way to keep the tree up to date. All of these features
are things we'd have to poorly reproduce in custom, buggy, hacked-together
scripts if we wanted to roll our own solution. Thankfully, this is not
necessary.
Init System
A while back, there was a big kerfuffle about Debian switching to systemd, then Ubuntu doing the same. This came as a shock to many, but to others, it represents a necessary shift towards a more modern init system. While I wasn't shocked, I wouldn't use systemd either. My belief is that /sbin/init should do as little as possible before handing off init to less important userspace programs (e.g. /etc/rc) and maybe waiting to run a shutdown script. This is exactly what sinit does and it is incredibly simple. We may end up writing our own init for fun and profit, but it'll be very, very similar to sinit. The plan, I'd imagine, is to populate /etc/rc.d/ with shell scripts, similar in format to OpenBSD's or FreeBSD's, but with our own /etc/rc.subr functions.
Alternatively, the init scripts could take the form of sysvinit services, which are essentially self-contained shell scripts. The latter option is the easiest to implement, even if the first isn't that hard to implement. In any case, the distro will end up with:
- Minimal /sbin/init binary
- Simple service files requiring little parsing
- /etc/rc.conf based service activation
Or at least something similar. Slackware's system of adding execute permissions
to init scripts to activate them is also something worth considering. Also, the
chmod +x /etc/rc.d/service could be aliased to initctl enable service, to
make it look like a lot of work has been done. At this point, we have basically
overtaken sysvinit in features, and are catching up with systemd rapidly.
File System
Back when a BSD kernel was still on the table, ZFS was also on the table. Unfortunately, even in FreeBSD, ZFS root is experimental, and it's even more so on Linux. Thus, ZFS is not an option, but btrfs may be. It's stable, has many of the features of ZFS, and is used in many high-profile distros, like Fedora. In the end, though, considering that ease-of-use needs to be a consideration, it would probably be easier to use ext4. That said, btrfs is a very attractive file system, but for now, ext4 is a lot easier.
Default Shell
The default shell, while not discussed at length yet, will no doubt be the subject of many an argument on the IRC channel. After a few discussions, I got the impression that others had the impression that zsh was bloated and slow, and that OpenBSD's ksh derivative, pdksh, was lighter. While this may be true in relative terms, I urged them to take into account than both shells used less than 1 MB of memory and both were responsive, even on an old 1995 ThinkPad running other programs in the background.
In fact, here is the line from top(1) for a zsh instance on my laptop right now:
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
1457 kaashif 1 52 0 37172K 1724K ttyin 0 0:00 0.00% zsh
So you can see, zsh uses 1724K of memory. Not exactly "bloated", is it?
Evidently, givina users a choice of modern shells like bash and zsh is far more important than saving the miniscule amount of memory switching to a gimped shell like pdksh would give. Perhaps it'd be worth it on an embedded system, but that is most certainly not the target audience.
The Plan
Taking into account what I have written here, I think the distro is headed in a good direction, provided development ever gets off the ground. While there are some disagreements about specifics, the overall sentiment is one of agreement, considering the sorts of people that congregate on #nixers (nee #unixhub) and their desires: minimalism, pragmatism and utility.
I hope our hacking will be happy and productive.