💾 Archived View for gemini.circumlunar.space › users › kraileth › neunix › eerie › 2014 › eerie_musl… captured on 2022-06-11 at 21:39:44. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2021-12-05)

-=-=-=-=-=-=-

Here I'm republishing an old blog post of mine originally from mid April 2014. The article has been slightly improved.

Background info: The project never took off beyond what is described here. Nobody ever reached out to me about Musl-based Arch.

Eerie Linux and Musl libC

Happy Easter, everyone! Guess it's about time I admit that my previous post was just an April fools, right? It's been 20 days already after all! Well, there are reasons why I couldn't do it. Two actually, if you disregard obstacles due to real life!

Keyboard issues

The first one is that I'm currently trying to get used to an alternate keyboard layout called _Neo²_. You've never heard of it? Well that's actually quite likely as it is neither well-known nor in wide-spread use - even in my country.

Neo² keyboard layout

Neo² is basically an ergonomic keyboard layout optimized primarily for the German language (but also well fit for English as many of us frequently use that language, too). It uses six (!) layers and quite some dead keys, thus allowing for many, many more characters that you can type with it. Have you heard about Dvorak for example? Then you know the basic idea of rearranging keys - and the advantage of having more characters easily accessible, like e.g. the whole Greek alphabet, is pretty obvious.

Dvorak Article on Wikipedia

This layout promises even more typing speed once learned properly and you've got some experience with it. I can already see that this claim makes sense as the keys are re-arranged very reasonably. However for the time being, it makes me type _damn slow_! Do I hear anybody laughing? Well, chances are that there's an alternate keyboard for your language, too. Why don't you try it out yourself and share some of the pain having to relearn something you've gotten used to for way over two decades? 😉

Not really all an April fools

And the second reason is... that most of what I wrote was not actually an April fools! Ok, some of it was. While the size of the TinyCore kernel is actually true (I really built it), I do not intend to use it as the default kernel. Also E5 won't switch to Musl - because I consider E5 a project on halt. What _is_ true however, is the fact that I've been experimenting with Musl for quite a while now. In fact I actually plan to build another experimental Arch-like system which will be based on it.

This is clearly the most challenging experiment I've done so far. Many standard packages are tested only against glibc and may require excessive patching to play together with Musl nicely. Fortunately one of my favorite Linux distributions, _Alpine Linux_, decided to switch to Musl! Thanks to their experience with µClibC - another alternative libc - it's out of question that they have the technical knowledge to make this happen. I have been very excited since I read their announcement and had been following the "edge-musl" branch closely. Now only ten days ago they dropped the "edge-musl" branch. First I was shocked, but then I realized that Musl is now the default libc for "edge"!

Alpine Linux

Alpine has been a great resource for me while I was trying to build an Arch system based on Musl. Musl is also available on Arch thanks to the AUR, but there it's only a secondary libc installed with a different prefix. It's meant more or less for static linking only. The great news: There seem to be quite a few people around who are interested in both Arch and Musl. So why not combine the two?

Project status

It didn't really take me long to get a musl-based mini-system working in a chroot. Adding more packages and making the beast boot however has actually been quite painful. In some regards I had to resort to what I'd consider "cheating": So far _mkinitcpio_ for example is completely broken and I just copied an initramfs image from my previous Arch:E5 project. I was _really_ happy, though, when I finally got the whole thing booting...

Then it took a few weeks to get _pam_ and logging in working as well as _runit_ (the init replacement I'm using) to spawn some tty... Welcome to a bare-bones system that won't provide much more functionality than just coreutils and the like! Next I added a text editor, so messing with configuration files became easier and prepared all the dependencies for pacman. There were quite some struggles along the way but in the end I succeeded: Musl-based Eerie has pacman now!

The logical next step was adding the basic development packages. Most of them even built without any special means necessary. However GCC proved really troublesome to build. I was stuck on that one for weeks (and even though those were weeks with little time on my hands, it proved to be a real blocker). In the end I gave in and used what Alpine provides (did the same thing for gcc-libs before, anyways!). So I at least have a working GCC.

Getting the net to work has been giving me the creeps. I have failed to get _xinetd_ to compile against Musl and I've also failed to find an alternative to it that would do the job instead. Now I know why many distros use busybox together with a dhclient script... Definitely have to take a look at how Alpine does it, but I'm not really knowledgable about openRC and would like to look into that one first. Maybe I'll find a little time for that soon. Who knows. The most important thing is that network connection with Eerie is possible.

I've built a few packages natively on my Eerie system but most of them were built externally. My goal is of course to be able to build all of them directly on Eerie and thus make the project self-hosting.

Open development

So far I've done all my projects in a semi-open way. I came up with an idea and tried to cook something up behind closed doors. When I thought that it was ready, I made it public and that was it. However these projects were more or less personal experiments that I shared with anybody who might care. Now I'd like to take the next step and set up a project that's actually useful (while still being experimental for the forseeable future).

For that reason I set up a repository to store all PKGBUILD files for Eerie using a DVCS (Distributed Version Control System) called _Fossil_. It's way less known that e.g. git, mercurial, etc., but it provides some nice extras. I've also written a little how-to on cloning the repository.

Fossil Homepage

PKGBUILD repository

Cloning how-to

Join the fun!

Building an Arch-like Linux distribution based on Musl is a gigantic task. For that reason I could really use any bit of help I can get. If you care for Musl and like Arch, please consider supporting this project. And no, I'm not asking for money. If you think you have a bit of free time on your hands and the skill (or are willing to learn since that's what we all start with) to mess with package building, just get in touch with me! Oh, and even if you don't think you can help by making more packages available, you may just invest the one or two minutes that it takes to write me a comment here and show some interest in the project. That would also help and is greatly appreciated!

What's next?

I'm busy getting the repos with binary packages up so that an Eerie system can be pacstrapped. I'll try to make a release announcement as soon as possible, probably in early May. Please bear with me!

BACK TO 2014 OVERVIEW