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? We’ll that’s actually quite likely as it is neither well-known nor in wide-spread use – even in my country.

It’s 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 (wikipedia article) 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).

Neo² promises even more typing speed once I learned it properly and 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 fool

And the second reason is… that most of what I wrote was not actually an april fool! Ok, some of it was. While the size of the TinyCore kernel is 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 musl.

This is clearly the most challenging experiment I’ve made so far. Many standard packages are tested only with 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 without 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 standard libc for “edge”!

Alpine has been a great resource for me while I was trying to build an Arch system 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 was actually quite painful. In some regards I had to resort to what I’d consider “cheating”: So far mkinitcpio 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 and runit (the init replacement I’m using) to spawn some tty… Welcome to a bare 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: 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 it 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 on EERIE and thus make the project self-hosted.

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. Look here for a little how-to on cloning the repository.

Join the feast!

Building an Arch-like Linux distribution 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 will 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!

Arch:E5 ditches eglibc and goes for musl libc!

Those of you who follow the development of Linux for embedded devices (or simply older hardware) will probably have noticed, that eglibc is effectively dead. According to their website “EGLIBC is no longer developed and such goals are now being addressed directly in GLIBC.”!

E5 and eglibc

Arch:E5 was built to be a bit lighter than todays mainline Arch. To do just that it’s obviously necessary to deal with the root of the trouble (yeah, a pretty lame pun, I know). The standard C library is – together with the kernel – the very heart of every Linux distro, that’s for sure! And since ordinary glibc is quite a memory hog, eglibc was a pretty self-evident choice to keep things a little smaller and prettier. But as this variant of the GNU C library will cease to exist after the 2.19 branch, E5 had to look for alternatives.

There are actually quite a few alternative C libraries around. Dietlibc for example. But it’s primarily meant for static linking. Yet there are more candidates. Like µclibc. A pretty nice libc actually which is also already proven and tested: There are even a few distributions built upon it. So could that be an option for E5? Nah, not really! Wanna know why not? ’cause it would be rather boring. And even worse: It has already been done for Arch and is even described in its own page on the ArchWiki!

So – is E5 doomed to eat humble pie and return to glibc, losing one of the main characteristics which made it diverge from mainline Arch? But no, fear not dear brethren! Luckily for us there’s also Musl, a rather young libc which you may not even have heard of. It has reached version 1.0 just these days and thus it practically calls for being used in place of our old C library! There are a few distros already which are based upon musl. But everything’s experimental and pretty much a mess to work with. In other words: Absolutely ideal preconditions!

I’ve been secretly working to make E5 run with musl as the distro’s libc for about two weeks now and just a few minutes ago I succeeded in getting E5 “Musl edition” to run! It was quite a bit of work and took quite some time. So far I have not spoken a word about it with anybody. But today’s the big day to announce it to the public!

Like the idea of Arch based on musl? If you don’t have a clue why you should like it, you may want to take a look at this table which compares musl to other libc projects. Convinced? Great! Now as proof that I’m not lying about the successful porting, here’s a screenshot which should confirm my claims:

Arch:E5 Musel’s boot screen!

Kernels…

While I was at it anyways, I thought that I might change the kernel as well. Ok, I have to admit that I’m still not cool enough to use some BSD kernel. But it’s clear that E5 (being an experimental distro!) needs something more… extraordinary. In the end I settled for a minimalistic Linux kernel by compiling one with the kernel settings from the TinyCore Linux project.

The result is really astounding if you ask me: That kernel image is just 2.5 Megs in size!! No, I’m not kidding. Don’t believe me? I can well understand you. But behold!, all you sceptics out there, here’s one more screenshot of the secret project for you:

Arch:E5 Musel with a TinyCore-like kernel!

So what do ‘ya say now? The “Arch Linux 3.10.33-1-LIBRE-LTS” line?? Uhm, well… *cough* Guess I gave that kernel a wrong name then! Yes, exactly that must be the case…

What’s next?

The logical next step would be publishing an E5-Musl repository, wouldn’t it??

Arch:E5 update and more repos (x11, gtk, fltk)

Finally I found some time to update and expand E5 a bit. The biggest news is surely the release of the e5-x11, e5-gtk and e5-fltk repositories. On the top of that packages have been updated and more than 80 new ones added (mostly to extra). This update also fixes a few issues that E5 had before.

Fixes

Most notably the docbook issue has been resolved. It took me quite a while to figure out what was wrong there. I was able to narrow down the problem to be solely related to the docbook-xsl package as simply replacing the E5 one with the package from Arch solved the problem. This made me guess that probably some other E5 components (docbook-xml?) were semi-broken. I tried this and that to no avail. Finally I decided to build a package on a pure Arch system using the PKGBUILD from E5. Result: Broken package. Build the package again with an unmodified Arch PKGBUILD? Result: Working. Hm! Since it is an arch-independant package I hadn’t really changed anything except for setting the epoch value. And in the end it turned out: Leaving out epoch makes the package work, setting it breaks it!

Even though it bugs me to make an exception the epoch “rule” for this package, I’ve removed the epoch value for docbook-xsl for now. If anybody has any idea exactly what’s going on there, feel free to tell me. I’m very interested in it but don’t have the time to dig any deeper on the issue in the forseeable future.

For some reason I had forgotten to disable the libsystemd dependency on the polkit package. And since E5 doesn’t come with systemd, polkit could not be used. This bug has been corrected.

There were two or three smaller issues I was able to solve during the last weeks but I didn’t write them down and can’t really remember what they were.

The Equinox Desktop Environment on Arch:E5

Updates

Quite a few packages have been updated to newer versions. Most of them are from the skel or default repository but a few other ones were updated as well.

Here are some of the most important ones:

  • linux-libre-lts-5:3.10.33-1-i686.pkg.tar.xz
  • ignite-5:20140212-3-i686.pkg.tar.xz
  • eudev-5:1.5-1-i686.pkg.tar.xz
  • tzdata-5:2014a-1-any.pkg.tar.xz
  • bash-5:4.3-1-i686.pkg.tar.xz
  • openssh-5:6.5p1-2-i686.pkg.tar.xz
  • openldap-5:2.4.39-1-i686.pkg.tar.xz
  • pulseaudio-5:5.0-1-i686.pkg.tar.xz

New repositories

However the main news is clearly that the new repositories “x11″, “fltk” and “gtk” are available now. Like their names suggest, they hold packages which provide graphical programs which run on pure X11 or depend on the FLTK or GTK+ toolkits.

To install a very light-weight desktop, simply install the package “ede”:

pacman -S ede

Or if you want a full-blown, yet traditional desktop, the “mate” (and probably “mate-extra”) group(s) may fit your needs:

pacman -S mate

I had also intended to package a game for demonstration and since the new widelands beta was released not too long ago, I tried to prepare that. Arch:E5 has all the packages needed to build it and widelands compiles fine, too. Unfortunately it segfaults upon execution… And since I don’t have the time needed to look into that, it’s unfortunately no widelands right now. :(

The new MATE 1.8 on Arch:E5

The furure

I think that Arch:E5 has already grown quite large for the quick project that it is. Right now it consists of 700+ packages which are roughly 1GB in size!

While it has been an interesting project, I’m not really sure what to do with it now. Most of what I was aiming for has been accomplished and the next step would now be bug hunting and adding even more packages. In other worlds: Nothing spectacular. In general I’m up to the challenge to maintain a linux distro for a longer time. However there’s of course no reason to maintain anything that isn’t of any use to anybody.

For that reason I’ll just let Arch:E5 live for a while doing the occasional update now and then and see if it is at least remotely interesting for somebody.

What’s next?

There are a lot of things which I’d like to do next. However I haven’t really decided, yet. So it’ll have to be a surprise!

[Edit: Added pictures]

More e5 repositories available (default, devel, extra)

Today more e5 repositories have been made available to the public. Most notably: e5-default, e5-devel and e5-extra. Also the linux-libre-lts kernel in e5-skel has been updated from minor version 27 to 29.

New to E5? You may want to read this and this post first!

An experimental Arch system

While a minimal working E5 system could be pacstrapped before since the time when the skel repository became available, it is possible to install an E5 system now that is actually useful (without having to relay on packages from mainline Arch). Unlike before, pacstrapping base now installs 34 more packages, among them vim and pacman. So you can now at least edit files and do package management! The base system is now also capable of dhcp.

The group base-devel installs everything necessary for starting to build programs yourself or to do some packaging. This group is a bit larger in comparison with mainline Arch: clang was added to it since that is meant to be the default compiler with E5. However the devel repository holds quite a few more packages which are not part of that group – cmake, valgrind or java7-openjdk are some examples (the later is not quite the latest version, though).

The extra repository offers what you would expect as an Arch user: Tools like wget, VCS’s like git and subversion, and lots of other things (cups, python, etc.). Only any packages of TeX is in its own separate repo (e5-tex), mainly due to its size.

To install it, see the previous post and add the e5-default repository together with the e5-skel one.

These packages allow for an Arch:E5 system which offers pretty endless possibilities for you to mess with. Happy hacking! ;)

(I’d love to hear your feedback, BTW. Don’t hesitate to post it here or to mail me!)

Known problems

There are a few issues that I am aware of but didn’t have the time to look into properly or haven’t found a solution for, yet. If you think you have an idea on what’s going wrong, please get in touch with me! I’m very interested in any help, even if it’s just a small clue. And of course: Please report any other issues you might run into!

Here’s a list of issues I’m currently aware of:

  • There are some packages which do not compile at all with clang. Sometimes they did work with clang 3.3 but stopped working with 3.4 (or vice-versa). In some cases I’ve found patches or was able to apply a little sed magic. But since I’m not a programmer my capabilities in this area are fairly limited.
  • With some packages the checks fail when built with clang. Since this is an experimental distribution I chose to simply ignore any failed tests and just hope that the package will work correctly, anyway. It’s quite likely however that some don’t.
  • There are cases where c++ programs compile with clang++ in general but not if libc++ is chosen as the standard c++ library. However libc++ is under active development and compatibility will surely increase over time.
  • DragonEgg is seems to be broken in version 3.4. When version 3.3 was the current one I used it with packages that didn’t work with clang and most of them were building fine. Currently I’m falling back on pure gcc for those, too (a bit unwillingly, though).
  • Some packages seem to work but are in fact broken. A perfect example of this is libxcb. It compiles fine with clang but makes X11 unable to start up (and rather misleading error messages made me search for a solution in an entirely wrong direction for days!).
  • The ca-certificates package is part of base but it’s not working corrently after the pacstrap for whatever reason. Simply re-installing it once E5 has booted up solves the problem, though. I’m a but puzzled about this one.
  • There’s some issue with docbook. Some packages try to load entries from the web (sourceforge). This fails with E5 for some reason. I’ve built a few custom Arch-like mini distros before (like an i586 Arch) and never had this problem. I’ll have to dig into that somewhen.
  • I REALLY should update elderlinux.org for E5, but I didn’t find the time to do so, yet…

What’s next?

I’ve already got a few more repositories on my drive. These are e5-x11 (which holds anything related to “pure” X), e5-plus (some uncommon stuff like anything that’s just a make dependency for some package), e5-gtk (for the GTK toolkit(s) and all applications that depend on it), e5-fltk (the FLTK toolkit, an FLTK-based desktop environment, FLTK-based applications) and e5-qt (obviously for Qt and Qt-based applications).

There are a few problems remaining with some packages and a lot of important ones missing completely. I’ll have to put some more work into that. I’d also like to provide the PKGBUILD files that I use(d) to build the E5 packages. These should be of some use for people who want to play around with E5 some more. Perhaps I should just put them on github like many other projects do?

And then I’d like to replace some more core system components with alternative ones (like trying to use obase instead of coreutils, dracut instead of mkinitcpio and things like that). In any case there’s a lot of fun waiting!

[Edit: Forgot to mention the ca-certificates issue.]

First public Arch:e5 repository published

The first public Arch:e5 repository is available now! If you have no idea what E5 is, you may want to take a look at the post Announcing Arch:E5! first.

About one month passed and I just made the skel (or “skeleton”) repository available. It can be used to pacstrap a fairly minimal Arch:e5 installation. I’ll describe how to do that in a minute, but first a few words about what this actually is.

Arch:e5 structure

Arch uses a rather simple repository layout: The most important packages are in core and everything else is in extra. Packages not officially maintained by the project can probably be found in community. Disregarding a few special things this is already it.

E5 booted using runit/ignite

While a “base” install of Arch is quite small compared to most well-known distros, it still pulls in quite a few things you might not want to have. Right, you can easily uninstall packages later. Or you could do without the “pacstrap” script and make use of pacman’s group feature. But using pacstrap is simply a very convenient way of installing Arch.

Now the idea is to allow for an installation that can be customized even more than Arch’s right from the beginning and thus split core into two repositories: skel and default. The former consists of everything absolutely necessary to get an Arch-based system up and running while the later holds the default packages that make the system actually useful.

The skeleton repository

Why would one do that split? Well, imagine you have a very specific idea of what your system should be. Perhaps you are an vi user. For what reason should nano even be installed at all? Or you don’t intend on using systemd. Why put it on your system in the first place?

Just pacstrapping the skeleton of your system together with what you actually want is a pretty obvious and comfortable solution.

E5 brings back one of the strong points of the classical Arch: rc.conf!

Right now skel contains all the packages which are in the “mini” group – 59 packages to be precise. I intend to put some more work into it to break it down to 50 packages at most (or rather: as few as possible). Some packages like the bootloader (syslinux) or the init-system (runit) are likely to be moved to the repository default in the future when E5 begins to offer alternative choices. Decreasing the number of packages could also be done by replacing some of them with others that have fewer dependencies.

How to install?

Warning: This ist just a preview. The system you’ll end up with is not of much use on its own at this time.

It doesn’t come with dhcp.
It doesn’t have a package manager.
It doesn’t even provide an editor.

If you want anything more than the bare skeleton, pacstrap it on top of E5 (from the Arch repositories) after the initial pacstrap is complete!

Preparing to pacstrap an Arch:e5 skeleton installation

As you can see, installing Arch:e5 is rather simple. Just boot from an Arch Linux live medium and make some changes to the /etc/pacman.conf file.

1. Comment out any Arch Linux repositories.

2. Then add the following:

[e5-skel]
SigLevel = Never
Server = http://www.elderlinux.org/repos/e5-skel

3. Once you saved the changes, you can check if pacman can read the package database using pacman -Sy. This is optional, of course, since the pacstrap script updates the db anyways.

4. Proceed with a more or less typical Arch installation:

Create and format your partitions, mount them and finally pacstrap the group mini instead of base. Then use genfstab and reboot. That’s it. If you follow the default partition layout, there’s no need to chroot to the environment since syslinux is installed automatically.

What’s next?

I’ll definitely continue working on E5. My next goal is currently to prepare and publish the default repository.

Content of skel

Since there’s not much in it, here’s the complete list of packages which skel currently holds (all but 3 packages were actually built with clang 3.4, btw.):

  1. acl-5:2.2.52-1-i686.pkg.tar.xz
  2. ath9k-htc-firmware-5:1.3.2-3-any.pkg.tar.xz
  3. attr-5:2.4.47-1-i686.pkg.tar.xz
  4. bash-5:4.2.045-5-i686.pkg.tar.xz
  5. bzip2-5:1.0.6-5-i686.pkg.tar.xz
  6. coreutils-5:8.22-2-i686.pkg.tar.xz
  7. cracklib-5:2.9.0-2-i686.pkg.tar.xz
  8. dash-5:0.5.7-4-i686.pkg.tar.xz
  9. db-5:5.3.21-2-i686.pkg.tar.xz
  10. e2fsprogs-5:1.42.8-2-i686.pkg.tar.xz
  11. eglibc-5:2.18r24829-1-i686.pkg.tar.xz
  12. eudev-5:1.4-1-i686.pkg.tar.xz
  13. expat-5:2.1.0-3-i686.pkg.tar.xz
  14. filesystem-5:2013.05-2-i686.pkg.tar.xz
  15. findutils-5:4.4.2-5-i686.pkg.tar.xz
  16. gawk-5:4.1.0-2-i686.pkg.tar.xz
  17. gcc-libs-5:4.7.3-4-i686.pkg.tar.xz
  18. glib2-5:2.39.3-1-i686.pkg.tar.xz
  19. gmp-5:5.1.3-1-i686.pkg.tar.xz
  20. grep-5:2.16-1-i686.pkg.tar.xz
  21. gzip-5:1.6-1-i686.pkg.tar.xz
  22. hwids-5:20130915.1-1-any.pkg.tar.xz
  23. iana-etc-5:2.30-4-any.pkg.tar.xz
  24. ignite-5:20131028-1-i686.pkg.tar.xz
  25. iproute2-5:3.12.0-1-i686.pkg.tar.xz
  26. iptables-5:1.4.21-1-i686.pkg.tar.xz
  27. kbd-5:2.0.1-1-i686.pkg.tar.xz
  28. keyutils-5:1.5.8-1-i686.pkg.tar.xz
  29. kmod-5:15-1-i686.pkg.tar.xz
  30. krb5-5:1.12.1-1-i686.pkg.tar.xz
  31. less-5:458-1-i686.pkg.tar.xz
  32. libarchive-5:3.1.2-3-i686.pkg.tar.xz
  33. libcap-5:2.24-1-i686.pkg.tar.xz
  34. libffi-5:3.0.13-4-i686.pkg.tar.xz
  35. libldap-5:2.4.38-1-i686.pkg.tar.xz
  36. libsasl-5:2.1.26-6-i686.pkg.tar.xz
  37. libtirpc-5:0.2.4-1-i686.pkg.tar.xz
  38. linux-libre-api-headers-5:3.10.27-1-i686.pkg.tar.xz
  39. linux-libre-firmware-5:3.10-1-any.pkg.tar.xz
  40. linux-libre-lts-5:3.10.27-1-i686.pkg.tar.xz
  41. lzo2-5:2.06-3-i686.pkg.tar.xz
  42. mkinitcpio-5:0.15.0-1-any.pkg.tar.xz
  43. mkinitcpio-busybox-5:1.21.1-2-i686.pkg.tar.xz
  44. mpfr-5:3.1.2.p5-1-i686.pkg.tar.xz
  45. ncurses-5:5.9-5-i686.pkg.tar.xz
  46. nettle-5:2.7.1-1-i686.pkg.tar.xz
  47. openssl-5:1.0.1.f-1-i686.pkg.tar.xz
  48. pam-5:1.1.8-2-i686.pkg.tar.xz
  49. pambase-5:20130928-1-any.pkg.tar.xz
  50. pcre-5:8.34-2-i686.pkg.tar.xz
  51. procps-ng-5:3.3.9-2-i686.pkg.tar.xz
  52. readline-5:6.2.004-1-i686.pkg.tar.xz
  53. runit-5:2.1.1-3-i686.pkg.tar.xz
  54. shadow-5:4.1.5.1-6-i686.pkg.tar.xz
  55. syslinux-5:6.01-4-i686.pkg.tar.xz
  56. tzdata-5:2013i-1-any.pkg.tar.xz
  57. util-linux-5:2.23.2-1-i686.pkg.tar.xz
  58. xz-5:5.0.5-2-i686.pkg.tar.xz
  59. zlib-5:1.2.8-3-i686.pkg.tar.xz

New year – looking back at 2013

Happy new year 2014 everybody!

For me the second blogging year has passed and the third one stands at the door. A good opportunity to look back at what 2013 brought!

Last year went by quickly from my perspective. This was due to huge and time-consuming changes in my life. Still I managed to publish 22 posts in the last 12 month – probably not too bad.

Topics

While I had intended to simply continue with the toolkit specific application tests, I chose to open up the blog for more diverse topics. The blogging year started with a series of memory consumption tests of various Qt-based applications. Following Canonical’s announcement of Mir I simply had to write about the Linux desktop again.

Experimenting with various Unix-like systems beside Linux during that time I chose to write about that topic, too. And being an Arch user, it suggests itself to introduce the ArchHurd and ArchBSD projects

Next was an interesting interview with the developer of the FLTK-based Equinox Desktop Environment, just before the Blog’s first birthday post.

The second half of the year started with the first GTK+ application tests. Since there are just so many terminals around which are built upon this toolkit, this was quite a bit of work. For that reason I decided to postpone further GTK+ application tests – and in fact I haven’t had the time for them up to now!

A sample of what elderlinux.org currently looks like

An American programmer got in touch with me and we soon agreed to work together on some projects. This was the initial spark for me to seriously start working on an experimental i586 distribution. Due to it progressing nicely, I registered the domain elderlinux.org which is meant to be the future home of various things related to distribution creation. I hadn’t written any html for more than 10 years and it took me quite some effort to come up with something that doesn’t instantly make your eyes bleed. Unfortunately I don’t have the time to update the page regularly.

I had used ConnochaetOS in the past and was a bit sad to see it shut down. Since I was building an Arch-inspired i586 distro, too, I decided to blog about it before it would vanish. Development of that distribution effectively stopped in 2011 and A LOT has happened since then in the rolling-release world of Arch. This made a journey possible which was more like a time-travel. In a series of three posts I described how such an old system could be (partially) updated to meet today’s standards. I had actually also updated the kernel, bootloader and made the switch from the old init-system to systemd in my VM, but I had forgotten to take screenshots and didn’t find the time to write another post about it, anyway.

While the i586 distribution is generally in a pretty usable shape, the project has already become a bit too big. It currently has repositories worth of several GB of data – and I honestly have no idea how I could share this with others. I was playing around with several other things again, anyway. I decided to put this project on hold when I gave in to the idea of going just one step back: Building something that could be used together with a big distribution (Arch) instead of being completely incompatible with anything but itself. This eventually lead to the creation of Arch:E5 and the last blog post of last year.

A little bit statistics

This kind of retrospect posts wouldn’t be complete without a bit of statistic, would it? So here it comes! Each and every month has surpassed the previous peeks by far. The blog had about 1.000 hits in 2012 – and even if you take into account that I didn’t start to blog before late June, the > 6.600 total hits of 2013 were simply amazing!

The weekly hit statistic on 12/31/2013

The least successful month was January which just barely beat December 2012 with about 320 hits. There was one month (April) which scored a little lower and two which had significantly fewer hits than the previous month. The best one of the year was October with well over 750 hits! The new all-time peak of page hits occurred on 10/11 with 85 in one day!

The monthly hit statistic on 12/31/2013

My blog got even more hits from around the world. However the top countries didn’t change much, so I’ll skip the graphic for it this time. But here’s the map:

Hits by country

Due to the higher variety and new sub-projects some new tags have been added. However these were added to recently to carry much weight.

Tags and categories

Now for some very pleasant changes: I finally started receiving the first comments which are not spam! ;) And yes, I’m pretty happy about that.

Some comments at last!

For those interested in exact numbers (and to document these statistics for later), here’s a summary:

Monthly and yearly totals

Daily averages

Very suitable for the blog’s first birthday, it was this day that scored four trophies! The trophy case also holds medals for 10 followers and likes now, but I think this little graphic is even nicer:


Four trophies for EERIE on the blog’s birthday

Outlook

So what’s going to come this year? Well, who knows? Honestly: I don’t know. There are three things I intend to dedicate some time to: The GTK+ application tests, the Desktop Demo DVD and of course Arch:E5. But as the past year has shown there’s no chance to know before what exactly will happen. But that’s a good thing actually. So let’s just see what 2014 has in store for all of us!

Announcing Arch:E5!

Merry Christmas, everybody!

I’ve been very busy the last couple of weeks. Time to reveal what I’ve been silently cooking up during that period of time: Welcome to “Arch Linux Epoch 5″ or – in short – Arch:E5.

What is it?

It’s basically a handful of repositories which allow pacstrapping a clean Arch:E5 system or turning an existing mainline Arch into a more experimental system. It’s generally possible to “mix” mainline Arch and Arch:E5 packages. These are the key differences from Arch:

  • Uses the Linux-libre kernel which has all binary blobs removed (yes, like Parabola GNU/Linux)
  • Provides eglibc (the binary compatible embedded variant) instead of glibc as standard libc
  • LLVM/Clang is the primary compiler used for package building; gcc with dragonegg is the second choice and pure gcc is the fallback option for some packages
  • Whenever possible libc++ and libc++abi are used instead of stdlibc++
  • Comes with the Runit init system instead of systemd
  • Replaces some core components with light-weight alternatives (like pkgconf instead of pkg-config)
  • Uncouples its packages from Arch’s rolling release process so that they won’t be overwritten automatically
  • Slight preference of more liberal licenses than GPL
  • There’s also a special “nucleus” repository which offers a minimal Arch system (without kernel, bootloader, etc.) meant for chroot environments. It’s using musl libc.

This is just the current status; more things are going to be changed eventually.

Why to give it a try?

Well, you’ve got to answer that for yourself. Perhaps you agree that Clang is cool/light-weight is better/systemd is playing bull in a china shop and rc.conf once was the very essence of Arch? Probably you have some more ideas in with other areas Arch could be modified and like to experiment with it? Or maybe you’ve got an additional Arch box (or VM) for playing around with, anyway? You decide.

Why “Arch:E5″??

Short version: It sounds pretty nice, doesn’t it?

Long version: Pacman provides the “epoch“ value which can be used to force lower version numbers to be treated as higher ones. It is separated from the regular version string by a colon.
EERIE starts with ‘E’, which is the fifth letter of the alphabet. To avoid self-built packages to be overwritten during updates thanks to Arch’s rolling release process, an epoch of five is used to prevent that. Hence the name.

What’s the current status? How to get it?

Arch:E5 is not currently available for downloading. The system is running nicely for a while now and I’ve got almost 1GB worth of packages in my local repositories. Currently I’m pursuing the goal of making Arch:E5 self-hosting. There should not be too many packages missing to reach that. The next step is to rebuild the whole thing (which comes at the right moment since LLVM 3.4 is to be released these days) and prove that it’s self-hosting.

Once I got through with that, I’ll have to decide how to make the derivative available. I’ll probably set up a publically available install repository on my site (elderlinux.org), but I don’t have the bandwidth to share the whole thing. I might upload the other repositories on some share-hosting service, though. Maybe I can organize something better at a later time. We’ll see.

What are the reasons for E5?

The primary reason for most of my computer projects is simply that I want to get familiar with Linux in-depth. And surely the best way to do so is by actually getting your feet wet and just try things out. You could say: For educational reasons.

Of course there are more specific reasons for E5. While I’m a happy Archer in general (using the OS both at home and at work) there are still a few things I’d do differently. But hey: this is FOSS – and therefore I actually can. Great, isn’t it?

Oh, of course everybody is invited to join the playground. This isn’t meant as a “one man show”. You like (some of the) idea(s)? Get in touch! I’m pretty open to any comments, proposals or offers.

Anything to show off, yet?

Yes, of course. I’ve got a screenshot from this morning for you. It’s demonstrating what E5 can actually do right now.

Just in case you care: DooM (considered the real father of FPS games by many) had its 20th anniversary this month. This good old game is still very much alive and thus we recently saw the release of a lot DooM related material – including a new version of the Chocolate DooM source port. And since I wanted to give it a try anyway, I thought, I might as well do it on E5!

Running Chocolate DooM on Arch:E5!

So what you can see here is Arch:E5 running X11 with the FLTK-based EDE desktop, the GTK+2-based LWT terminal and the SDL-based DooM port “Chocolate Doom”.

As you can see, quite a few things are actually working already. I haven’t made any statistics, yet, but I think that >90% of all packages were built successfully with clang. In general I’m pretty happy with the project and I think it was about time to announce it to the public. :)

What’s next?

I’ll write one final post in 2013, providing a retrospect of this year. And in January I hope to have some news regarding Arch:E5.