Announcing: a new Hurd distro, based on Alpine Linux

[Sergey Bugaev]

Hello!

Those of you who made it to Joshua's belated New Year's party have
heard me mumble my way through announcing this: I have been working on
a new Hurd-based disto, based on the Alpine Linux distribution [0]!

[0] https://www.alpinelinux.org/about/

Now, before I go any further, I should say that this is not trying to
displace Debian or anything like that. We all love Debian GNU/Hurd,
and are thankful for Samuel's hard work that makes it possible. I am
using Debian, and will continue to do so. (Especially given that this
project might not succeed, after all.)

That being said, I have for a long time thought that the Hurd needed
more _distro diversity_. The other existing distro is Guix on the
Hurd, made by our Guix friends, which is great, and it seems to have
generated some interest towards the Hurd in the Guix community, and
some positive publicity for the Hurd too.

Historically, I know that there has been the Arch Hurd project [1]
(just look at all the excitement it has generated! [2]), but it seems
to have stalled. (By the way, if you're a fan of Arch who's interested
in the Hurd, I encourage you to revive Arch Hurd, that'd be so cool!)
There's been talks of Gentoo GNU/Hurd, but it doesn't look like
they've made much progress. (Fun story: I have once almost convinced a
friend of mine who was a Gentoo user to try and bootstrap a Hurd
version of Gentoo on his own.)

[1] https://archhurd.org/
[2] https://bbs.archlinux.org/viewtopic.php?pid=682472

Awesome as Debian is, there are issues with it. Firstly, the tooling
(and the social processes) used around Debian packaging seems rather
arcane and complicated for someone like myself who is not experienced
in Debian packaging. This is not a criticism; I'm sure it works great
for them! — but this also means that most of us in the already small
Hurd community are essentially unable to contribute to it.

Secondly, Debian GNU/Hurd being the full "grown-up" Debian distro has
— well, certainly a lot of upsides, and that's what makes it so
appealing — but also, I imagine, some downsides, in that it cannot
just be our little playground. For example, I imagine Debian cannot
ship the latest & greatest glibc master with all of my fixes, because
that might break Debian GNU/Linux, which has different expectations
around stability and a lot more users. In fact, Debian still ships
glibc 2.37, with some patches backported.

Now, on the other hand of the spectrum are Flávio's cross-hurd
scripts, which bootstrap a minimal Hurd-based system. These are small,
self-contained, and hackable. You can build the whole thing, including
the cross toolchains required, in a few minutes, without much of a
special setup required. Bumping glibc (or something) should be
trivial. If you want to contribute, you fork the Git repo, apply your
changes, and just open a PR. How cool is that?

So I think there is a place for some middle ground between the two: a
full (although small, "embedded") distro, with a package manager and
many available packages, that is at the same time easy to bootstrap,
to hack on, experiment with, and contribute to. The hackability should
hopefully ensure that this becomes a community project rather than a
one man show, and has a healthy bus factor.

I chose Alpine Linux as the upstream distribution for the project, for
various reasons; not least because I thought it would be a fun
endeavour to try and port Alpine which is known for not being a GNU
distro and in particular not using glibc (and it was!). Alpine
certainly fills the bill of being small and extremely hackable. They,
too, keep all of their package build definitions/scripts in a single
Git repo (aports); updating a package or adding a patch only requires
making an MR against the repo. The CI can then pick up the change,
rebuild the package, and without minutes of the MR being merged have
the new package available for download from the repo.

I have ported many Alpine packages to build with (i386, for now) GNU
Mach, the Hurd, and glibc, replacing Linux and musl. If you want a
specific number: as of yesterday, I have 299 installable packages; the
number of source packages is of course several times less than that.
Still, this includes things like curl, ncurses, nano, native binutils
& gcc & mig, libffi, openrc, openssl, util-linux, busybox, apk-tools,
... and of course gnumach, hurd (with dependencies like libdaemon,
parted, ...), and glibc. Importantly, all this cleanly bootstraps
using the scripts/bootstrap.sh script that they provide; this is too
somewhat like Flávio's scripts, but it uses the real full Alpine
package definitions for e.g. GCC (patched by me for glibc / Hurd
support).

Above the kernel and libc, things remain much as they were in upstream
Alpine: the system boots (will boot — I haven't tried it yet) with
busybox init & OpenRC, and uses busybox as its basic userland. GNU
software such as Bash is installable, too.

There is no ABI compatibility with either Alpine Linux or other Hurd
distributions implied: only binaries built targeting this system will
run on it. So, I have gone and bumped the minimum glibc symbol version
for all architectures to GLIBC_2.38. (And I should probably bump this
further to GLIBC_2.39 in fact.) This drops code that only exists for
supporting older binaries, and saves some disk space.

The future of this project depends entirely on you. If there's no one
interested in hacking on it and using it, it will go down in history
as another attempt at making an alternative Hurd distro that failed to
gain traction, much like Arch Hurd. This will be fine too; at least it
was a fairly interesting hack.

But if you are interested, speak up, join in, and spread the word! :) We need:

1. A name :) I'm not calling it "Alpine GNU/Hurd" or some such, as to
not imply any involvement of the upstream Alpine project. We are
purely their downstream; we're based on them, but we are not them.
"Everest Hurd" has been suggested during the party call, which sounds
nice, but it looks like "Everest Linux" is already a thing :-| Pick
another mountain name, maybe? :)

2. Somewhere to keep our aports fork in. Depending on how serious we
are about this (if at all), this may range from a personal repo on
GitHub, to a GitHub/GitLab "organization", to a whole website of our
own with our own Git hosting solution (whether GitLab or something
else) running on it.

3. Somewhere to host the built packages, so they can be downloaded by
the package manager on users' machines.

4. A CI setup that would build packages when their package definition
changes, and upload the built result to the hosting solution from the
previous point. Perhaps see the CI setup in the pmaports repo [3] for
some inspiration. There's also reposerve [4], which appears to have
been developed specifically to integrate with the workflow of packages
being built on GitLab CI [5]. Somebody mentioned they were a CI
expert? :D

[3]: https://gitlab.com/postmarketOS/pmaports/
[4]: https://github.com/eburghar/reposerve
[5]: https://itsufficient.me/blog/alpine-container#packages-repository

Please let me know what you think!

Sergey