Neunix: Eerie transitioning to Geminispace

Regarding my previous post (https://eerielinux.wordpress.com/2020/10/08/retreat-and-reboot-is-there-life-outside-of-the-web/) some witty people may have figured that this was a joke: The last post before that one was the long delayed February one and I wrote that I simply couldn’t post the next one (as I cannot stand the new WP editor). That could make said previous post the April one. Maybe it was meant for April 1st?

No, it wasn’t. I’m serious with my experiment of giving it a try to continue writing BSD and IT material in general in Geminispace. The plan is to continue to announce new posts on this platform but to provide the actual content in the new place.

Making a new home

So what’s the status of this? Well, it’s ready! I’ve contacted one of the people behind Gemini and was given access to a server that would host my new Gemlog for now (thanks solderpunk!). A first version of my capsule (in Web-speech this would be “homepage”) is up and available. It currently looks like this:

Capsule of kraileth - my new home on Gemini
Capsule of kraileth – my new home in Geminispace

I got the nice color scheme for my browser from samsai and generally recommend his introduction article to people who are interested in Gemini: https://samsai.eu/post/introduction-to-gemini/

Took me a day or so to get used to the reduced markup that is called gemtext. But now it’s working out well for the most part. There are some downsides that I’ll probably write about sometime in the future, but in general it works and it’s simplicity makes up for quite a refreshing experience.

Eerielinux blog -> Neunix Gemlog

I’ve picked a new name for the reboot of my previous blogging project. What was the eerielinux blog before is now the Neunix Gemlog. A few things changed or will change, but in general it’s a continuation of what I did with Eerie: I’ll publish articles that I hope are useful or at least interesting to some people.

Focus will remain *BSD-related material but like before I’ll write about other things as they arise. Of course I have some ideas for article series as well. I’ve also picked some old posts from Eerie and converted them (work to transfer more is ongoing).

This is what it looks like right now:

The Neunix index page - continuation of the eerielinux blog in Geminispace
The Neunix index page – continuation of the eerielinux blog in Geminispace

How to access it?

All nice and pretty, but how to you access this thing? Well, Gemini is a protocol wildly different from HTTP and is not currently supported by any mainstream web browser. It is a superset of what HTTP does, though and Gemtext is a superset of what HTML does, so it’s very much possible to convert one to the other – at least in the direction of simpler to more complex! Proxies that make Gemini content accessible via the Web already exist.

So you have two options:

1) Get a real Gemini browser. There are multiple projects out there. I might write about this topic at a later point in time. For now I can only point you to doing a little research and find one that suits you. I use Castor (https://git.sr.ht/~julienxx/castor) and find it to be pretty nice.

Then go to: gemini://gemini.circumlunar.space/users/kraileth/neunix/

2) Use a web proxy. Here you are: https://portal.mozz.us/gemini/gemini.circumlunar.space/users/kraileth/neunix/

What’s next?

I’ve already posted one new article on Neunix. In about a week or so when people had time to read this one, I’ll link to it directly with a new post on this platform.

And then? Well, we’ll see. The journey has begun and there’s vast, untamed land before me. The possibilities are next to endless. I’ll just pick one thing as the mood strikes me.

Retreat… and reboot! Is there life outside of the Web?

Dear readers,

the time has come for some fundamental re-organization of my Eerielinux blog. The impact of this year’s pandemic as well as family matters (a new family member that demands quite a bit of care!) have forced me to post-pone many of my posts that I usually published at least monthly. Right when I was getting back on track and stated that I intended to publish the missed articles (I’ve written them after all but didn’t find the time for final editing) something else happened.

No, to be honest, it has been happening for quite a while. I didn’t like it but had to cope with it as there was nothing I could do about that, anyway. What am I talking about? Well, the sad fact that I would call the “degradation of the Web”.

Eerielinux has always been about some experiments that I did and wanted to share in case anybody was interested. Now I’m in for a new experiment, a somewhat radical one (and what could be considered radical after going Linux-only and later FreeBSD-only for all of my machines?). I would appreciate feedback on the path that I choose to give a try. What do you think about it? Are you interested in that, too? Would you continue to read some of my material or does this mean that our ways will part? But let’s detail first what has made the time ripe for what is less of an elitist move then an act of mere desperation.

What’s wrong with the Web?

So, what has happened? And what’s the gripe that I have with the Web? Well… It’s actually not just the Web (read: WWW), it’s more things coming together. There seems to be a general direction that the IT world is heading which I don’t approve of. This blog is powered by WordPress for the simple reason that when I started in 2012 I had some material that I wanted to share with the world and going with a free plan on a blog hosting platform seemed like a nice way to get started quickly. And it was. Mind the past tense here.

WordPress evolved – which is a good thing in general. It evolved in a way that I loathe, however. There have been all these “new” and “easier” modes for XYZ which were admittedly more shiny and more “modern” than before. But they broke my workflow time and time again – and unfortunately not for the better. I actually like to re-evaluate my workflows, like to challenge my habits. When I was still using Ubuntu Linux I didn’t only give Canonical’s Unity DE a chance, I actually tried to use it before putting it aside because in the end it hindered me more than it helped. I forced myself to use the (then) new graphical TrueOS for half a year and suffered through incompleteness and breakage. I have a fairly high tolerance for things that are… sub-optimal. I’m also rather patient, I think, and I’m surely not a rage-quit type of person. But inevitably there’s this point where I have to admit: “Ok, that’s it, that’s simply too much”.

The same thing happened for WordPress, when they came up with various iterations of “new editors” – which is why I opted to go back to the “old editor” for writing and editing my blog posts. As I returned to finish the next old post however, I found out that the old editor was gone. They had “finally” removed it. Alright, so I had to try and get accustomed to the new one again. Perhaps it had matured since I tried it last? It had. But it proved to be even more annoying for me than before! I don’t know what the designers are thinking – certainly not what I do. For me it is a pain to work with the new tool: Things that worked perfectly fine before are gone and the new options are so much inferior to what we had before… And this is not even the worst thing that made me give up when I was more than half through with polishing the next post.

Technically the new editors work well for small posts. I seem to have a bit more to say than the average blogger, though; and here’s a very frustrating issue: When editing longer posts, the editor gets unresponsive and laggy. Yuck! Trading a working one for a “new” one that does less but eats up so much more resources? Are you freaking kidding me? Oh, right, that’s the way things go, I forgot for a second. There’s something within my very self that refuses to accept the lack of sanity around me, sorry. I should know better by now.

And even though WordPress makes up a quite large portion of today’s Web, that’s just the tip of the iceberg. All this JS nonsense, megs and megs of useless graphics, animations, tracking and spying cookies, etc. pp. make the Web such a obnoxious place! And don’t even get me started on the situation with web browsers…

What’s wrong with hardware?

After my little rant I can hear people say: “See, pal… If the WordPress editor makes your system struggle enough that you complain on the net, you reaaally want to get a new PC! There’s machines with more than 4 gigs of memory today, you know.”

The irony here is: I did get a newer laptop – and went back to primarily use the old one! Why? Because the new one is bugging me just too much whereas the older model works well for me. The newer follows that stupid trend of being extremely thin. “Thanks” to that design no DVD drive fits in there. While this is incredibly dumb, I can live with it. Carrying an external drive with me is not so much of a problem, but still the fact that the machine is missing the drive annoys me. The bigger problem: The battery of the old model can easily be removed and I can carry a second one with me e.g. on longer train rides. With the new one I’d need to open the case to access it! WTF HP? And finally: Some idiot decided that the “cool” flat design was so important that it’s thinner than the jack for an Ethernet connector… Yes, really: There’s some kind of… hatch that I need to pull down to make the opening big enough to insert the plug! If I remove the plug the hatch snaps back up. It’s not hard to see that this brain-dead construction is prone to defects. And really, it didn’t take too long until it stopped working reliably and I’m randomly losing connectivity every other day… Sorry, this is garbage. Plain as that.

I have another older laptop – that one has 24 GB of RAM and two hard drives. Nice, eh? Not so much because it also has some of those gross EFI quirks. When one of the drives has a GPT partition scheme applied to it, that drive won’t even be detected by the POST anymore! So on that machine I’m stuck with MBR which is not so much fun if you’re using ZFS and want to encrypt your pool with GELI – it can be done, but the workarounds have the side-effects of not working with Boot Environments! True garbage again.

“Come on, why don’t you simply get a different model then?” Yeah, right. As I said, I type a lot, so I have some demands concerning the keyboard. Unfortunately some manufacturers seem to take pride in coming up with new ways of f*cking up the keyboard layout. There are models that simply dropped the CAPS LOCK key, because nobody uses that, right? Wrong! There are people who remap their keys, and being a NEO² typist (a keymap that allows for 6 layers) I need that key as an additional modifier! Take it away and that keyboard is utterly useless to me. But don’t current models like the X1 Carbon still have CAPS LOCK? They do, but there’s another oddity: They swap the CTRL and FN keys! Having CTRL as the leftmost key on the keyboard that I use as my daily driver and switching around in my head at 3 AM when there’s an alarm during my on-call duty is something I fail to do properly. I used a Thinkpad for about a month for on-call and it drove me completely mad. Sorry Lenovo. Your laptops may be excellent otherwise, but they are not for me.

Oh, and it’s not so much of a secret that the situation with the x86 and x86_64 architectures is abysmal (need I say more than Meltdown / Spectre?). Modern hardware design is fundamentally broken and I cannot say that I completely trust the fixes and what unknown side-effects they might bring with them either. But that’s not even the point. We’re stuck with market-leading technology that has been criticized as crappy right from the start. It has come a long way since then, but it’s not a great technology in any regard. I’ve been playing with my Pinebook and it might have the potential to become something different. Maybe the Open Source PowerPC notebook initiative will succeed. Probably we’ll have something RISC-V-based in the long run. But right now we have to make use of what is available to us.

Can’t the Web be saved?

I’m a somewhat optimistic person, but in this regard not so much. While I have thought about just self-hosting my blog and using a nice static-site generator or something, that would only solve my issues regarding the blog. A huge portion of the Web will still be a terrible place. Browsers and software will still suck hard. Especially in terms of browsers I’ve found even the suckless offering far from being a good one (I like their work and agree with most of the suckless principles, but in my conclusion it’s not enough to really get me out of this whole mess).

Sure, I can install e.g. the Dillo browser. But its development has been extremely slow for years and the subset of HTML that it supports cannot render most of today’s websites properly. And going with just the pages of people who deliberately keep their sites simple? I like the idea, but there’s the problem that no real community (that I know of) exists which agrees on a single standard of which HTML features are ok and which ones should be avoided.

I’m old enough to remember the browser wars well enough. I also confess being guilty of having used “marquee” on my homepage for a while back in the day. Maybe all of the gibberish we’re facing today is a late punishment for sins committed when we were younger? I don’t know.

So – are we doomed? Should we just pull the plug, go to real libraries again, buy books when we need information and spend our free time in the garden? That thought is tempting only for a moment. I love tech. I love the net and the possibilities it brings with it. Plus I’m kind of a liberal today who believes that mankind will eventually make something good from it all. We’re on this planet to play, to learn and to grow. Some insights can only be gained the hard way. It’s ok that commercial interests ruined the Web for people like me. There are other people who have (monetary or idealistic) interests in the Web being like it is. That’s fine. And in fact: Today’s Web “works” for a lot of people who either have no clue why it’s problematic in the first place or who simply don’t care. Which is a legitimate stance. The tragedy is simply that the rest of us has kind of lost home for a while and we haven’t been able to find a new one, yet.

The “Big Internet” vs. the “Small Internet”

While the Web makes up for a very large and definitely the most visible part of the Internet, there are niches, lesser known parts of it which are certainly not less interesting. Some people speak of the Web as the “Big internet” and call the various special parts the “Small Internet”.

One such niche is the so-called Gopherspace. Gopher is a simple communication protocol for documents which predates the Web. Not just by today’s standards it’s primitive – but it works. And while the major browsers either never supported it or removed support long ago (e.g. Firefox dropped Gopher support for release 4.0), it’s still kept alive by enthusiasts. Some sources even suggest that it has seen moderate growth over the last years with more people fed up with the Web trying out something different. If you’re interested, start here with the web proxy or do some research on your own and install a Gopher client.

I’ve dug into various Gopher holes and my experience with it is a mixed bag. On the one hand it’s really cool to see people putting in the effort of creating a place that’s worthwhile to visit. I also liked the experience in general: It’s not bells and whistles everywhere (because that’s in fact impossible due to the protocols limitations) but rather a focus on the actual content. People have found ways to access git repositories over Gopher and there’s a community called Bitreich (via Gopher) that declared “suckless failed” and propose an even more radical approach. While some of it is probably parody, it’s an interesting one.

On the other hand some of the restrictions of the protocol make no sense at all today, like having a hard-coded limit of 80 characters per line. And there are more shortcomings. When Gopher was conceived, nobody thought of internationalization and indicating the charset that a document uses. Also Gopher is all plain-text and does not provide any means to help protect your privacy – which does not exactly make it overly appealing to me.

But there’s something else, an even smaller – but newer – niche, called Project Gemini. It is a newly designed protocol (2019!) that wants to provide kind of a middle ground between Gopher and the Web while clearly leaning towards the former. It remedies the privacy issues by making TLS mandatory and deliberately not supporting “user agents” or other ways to collect data about the user not required to deliver the content. And it wants to simply be an additional option for people to use not to replace either Gopher or the Web.

While I kind of like Gopher, I really admire Gemini. Having the balls to even try to actually do something like this in our time is simply (no pun intended) astonishing. In my opinion it’s high time to re-invent the wheel. Gemini is certainly not a panacea to all the problems that we have today. But it’s a much welcome (for me at last) chance to start fresh without that huge, huge bag of problems that we’re carrying on with the Web but with the experience that we gained from using it for several decades now.

What’s next?

My experiment is to move Eerielinux to Geminispace and post new content there as I find the time. The plan is to keep this WordPress blog and to create new posts here that simply reference the real content, providing a convenient link using a Web proxy. That should help keeping things accesible for people who prefer to stick with their known browsers instead of getting another one for such a tiny little world as Geminispace is right now.

And who knows? Perhaps something nice comes from Gemini in the long run. I’m looking forward to find out. And if you care — see you in Geminispace for some more articles on *BSD, computers and tech in general!

Top things that I missed in 2015

Another year of blogging comes to an end. It has been quite full of *BSD stuff so that I’d even say: Regarding this blog it has been a BSD year. This was not actually planned but isn’t a real surprise, either. I’ve not given up on Linux (which I use on a daily basis as my primary desktop OS) but it’s clear that I’m fascinated with the BSDs and will try to get into them further in 2016.

Despite being a busy year, there were quite a few things that I would have liked to do and blog about that never happened. I hope to be able to do some of these things next year.

Desktops, toolkits, live DVD

One of the most “successful” (in case of hits) article series was the desktop comparison that I did in 2012. Now in that field a lot has happened since then and I really wanted to do this again. Some desktops are no longer alive others have become available since then and it is a sure thing that the amount of memory needed has changed as well… 😉

Also I’ve never been able to finish the toolkit comparison which I stopped in the middle of writing about GTK-based applications. This has been started in 2013 so it would also be about time. However my focus has shifted away from the original intend of finding tools for a light-weight Linux desktop. I’ve become involved with the EDE project (“Equinox Desktop Environment”) that uses the FLTK toolkit and so people could argue that I’m not really unbiased anymore. Then again… I chose to become involved because that was the winner of my last test series – and chances are that the reasons for it are still valid.

And then there’s the “Desktop Demo DVD” subproject that never really took off. I had an Arch-based image with quite some desktops to choose from but there were a few problems: Trinity could not be installed alongside KDE, Unity for Arch was not exactly in good shape, etc. But the biggest issue was the fact that I did not have webspace available to store a big iso file.

My traffic statistics show that there has been a constant interest in the article about creating an Arch Linux live-CD. Unfortunately it is completely obsolete since the tool that creates it has changed substantially. I’d really like to write an updated version somewhen.

In fact I wanted to start over with the desktop tests this summer and had started with this. However Virtual Box hardware acceleration for graphics was broken on Arch, and since this is a real blocker I could not continue (has this been resolved since?).

OSes

I wrote an article about HURD in 2013, too, and wanted to re-visit a HURD-based system to see what happened in the mean time. ArchHURD has been in coma for quite some time. Just recently there was a vital sign however. I wish the new developer best luck and will surely do another blog post about it once there’s something usable to show off!

The experiments with Arch and an alternative libc (musl) were stopped due to a lack of time and could be taken further. This has been an interesting project that I’d like to continue some time in some form. I also had some reviews of interesting but lesser known Linux distros in mind. Not sure if I find time for that, though.

There has been a whole lot going about both FreeBSD and OpenBSD. Still I would have liked to do more in that field (exploring jails, ZFS, etc.). But that’s things I’ll do in 2016 for sure.

Hardware

I’ve played a bit with a Raspberry 2 and built a little router with it using a security orientated Linux distro. It was a fun project to do and maybe it is of any use to somebody.

One highlight that I’m looking forward to mess with is the RISC-V platform, a very promising effort to finally give us a CPU that is actually open hardware!

Other things

There are a few other things that I want to write about and hope to find time for soon. I messed with some version control tools a while back and this would make a nice series of articles, I think. Also I have something about devops in mind and want to do a brief comparison of some configuration management tools (Puppet, Chef, Salt Stack, Ansible – and perhaps some more). If there is interest in that I might pick it up and document some examples on FreeBSD or OpenBSD (there’s more than enough material for Linux around but *BSD is often a rather weak spot). We’ll see.

Well, and I still have one article about GPL vs. BSD license(s) in store that will surely happen next year. That and a few topics about programming that I’ve been thinking about writing for a while now.

So – goodbye 2015 and welcome 2016!

Happy new year everyone! As you can see, I have not run out of ideas. 🙂

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 like git and subversion, and lots of other things (cups, python, etc.). Only all packages of TeX are in their 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.