Re: Announcing: a new Hurd distro, based on Alpine Linux

[jbranso]

January 20, 2024 at 3:03 PM, "Sergey Bugaev" <bugaevc@gmail.com> 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.

I'd be happy to buy a sourcehut account for it for a year.  

I'd also be happy to create a website for it and host it for a year.  
We should make this email (perhaps reword it) as the website's first
blog post.

Software with which we can build a static site (that runs on the hurd):

ikiwiki
Emacs org-mode (I vote this one)
guile's Haunt  (I am having a hard time installing this on Debian
                 GNU/Hurd).
 
> 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
>