Announcing: a new Hurd distro, based on Alpine Linux (original) (raw)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

From: Sergey Bugaev
Subject: Announcing: a new Hurd distro, based on Alpine Linux
Date: Sat, 20 Jan 2024 23:03:31 +0300

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

Please let me know what you think!

Sergey