Hi Sergey. Sorry for top-posting.
This is very interesting, especially now when the Debian (GNU/Linux, GNU/Hurd) project is heading in the wrong direction. I'll take a closer look on Alpine in due time. Thanks! On Sat, 2024-01-20 at 23:03 +0300, Sergey Bugaev wrote: > 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 >
