Why Alpine
GNU/Linux has several different distributions: Ubuntu, Debian,
Fedora, Suze, etc, and each distribution is slightly different from
the others. Fedora usually uses the most recent software, while
Debian offers stability. Each distribution helps the entire
ecosystem, by ensuring various library versions play nicely together,
each develops of different package managers, some use different
compilers (LLVM
instead of GCC
) etc. Users are free to choose the
distribution that they prefer. This has worked out well for
GNU/Linux, but how many active Hurd distributions are there? 1
Currently? Just two: Debian GNU/Hurd and Guix System. Of these two,
Debian GNU/Hurd is more complete. Debian GNU/Hurd has more packages,
more global mirrors, etc. People run Debian GNU/Hurd in qemu
, Xen
,
and on real hardware (I use a T43). The Hurd Guix System is catching
up to Debian GNU/Hurd, but is not quite there yet 2. What is nice about
Guix System, is that they make it realy easy to run the Hurd in a
virtual machine via this bit of guile code:
(service hurd-vm-service-type (hurd-vm-configuration (disk-size (* 5000 (expt 2 20))) ;5G (memory-size 1024)))
We want to add a third distribution based on Alpine Linux. Please note that Alpine Linux is not directly involved in this project. We just like their design goals: small, simple, and secure.
But why another distribution? Why not invest in the Hurd distributions that already exist? We believe that creating another distribution will uncover bugs (like the one Sergey found in glibc), test the Hurd in new environments, encourage more users to run the Hurd, generate good publicity for the Hurd, and it's fun!
What makes Alpine Linux different from Guix and Debian? Debian is
stable and uses somewhat older software (notable not the latest
glibc), Guix is written entirely in guile scheme, breaks the FHS, and
has some exciting package management features. Alpine Linux is not a
GNU distribution, and it is also known for being light-weight, secure,
and simple. Alpine also keeps all of its packages' build recipes in
one git repo (aports
). To contribute a change, one would fork
aports
and make a MR against the repo. If its accepted, then
Alpine's continuous integration can rebuild the packages and within
minutes make the new package available for download.
What is the current status?
Sergey ported many Alpine packages to build with (i386, for now) GNU
Mach, the Hurd, and glibc, replacing Linux and musl. Sergey built
everything with GCC/binutils it uses gnumach, hurd, and glibc. But
other than that, GNU software is not the default. He has 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
Alpine provides; this is too somewhat like Flávio's scripts, but it
uses the real full Alpine package definitions for e.g. GCC (patched by
Sergey for glibc / Hurd support).
Above the kernel and libc, things remain much as they were in upstream Alpine: the system boots (Sergey hasn't tried booting it yet with busybox init & OpenRC yet), 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, Sergey bumped the minimum glibc symbol version for all architectures to GLIBC2.38. (And he will probably bump this further to GLIBC2.39) 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:
- 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.
- Somewhere to host the built packages, so they can be downloaded by
the package manager on users' machines.
- 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 for some
inspiration. There's also reposerve, which appears to have been
developed specifically to integrate with the workflow of packages
being built on GitLab CI. Or we could use forgejo, which supports
aports
.
Footnotes:
Arch Hurd did exist at some point, but it does not seem to be active. Perhaps you are interested in Arch, and want to re-start the Arch Hurd project?
Please note that we like Guix System too! Guix System has
plenty of active developers, lots of momentum, and is building lots of
cool software tools like guix shell
, the guix issue tracker, Guix
QA, and they are working really hard to translate their website and
manual into numerous languages.