The compiler toolchain – updating an old Linux system pt.3

In the previous two posts I showed how to install ConnOS (website here, will vanish at the end of 2013!) and demonstrated how to update a few important system components. Today we’re in for more updating fun: We’ll be rebuilding the whole compiler toolchain and replace the pretty ancient versions available on ConnOS with far more current software.

Updating the toolchain

Now that our system is much easier to work with we’re ready to go on with the more important stuff, right? Right. The first package we’re going to update is the api-headers of the kernel. Since we’re going to stick with Linux-libre (a variant of Linux that has each and every binary blob removed from the kernel), we can get a PKGBUILD over at Parabola GNU/Linux.

Downloading the PKGBUILD file from Parabola

There’s not much to say about it except for the fact that it needs the kernel source which is really big (about 70 MB!). In building and installing it there’s nothing special.

Normally our next candidate would be tzdata, which contains time zone information. However it won’t build yet as the zic tool is not available in ConnOS’s native eglibc. For that reason we will have to build a more current libc first.

Installing new api headers

This means we’re in for a special package: The system’s standard C library. Most Linux distributions use glibc which is rather fat and lavish but also has the best level of compatibility with most applications (due to it being the de-facto standard). ConnOS uses a glibc variant called eglibc which has some patches applied to make it work better on embedded systems (and thus on all kinds of machines with low resources). Unfortunately neither Arch nor Parabola use it and even on the AUR there’s only an ancient version of it (just barely newer than the one ConnOS ships).

The eglibc project also doesn’t seem to provide source tarballs. Instead the source is always cloned from their repository. However we’re not going to mess with a VCS (Version Control System) now. Fortunately there are projects using eglibc which provide source packages for it. Debian does and Cross-Linux-from-scratch does, too, just to name two. We opt for the later since it offers a more current version.

So our best bet with eglibc is to take the very old PKGBUILD from ConnochaetOS and update it to build a newer version. This is actually a bit tricky. If you want to save yourself some time trying everything out you can just use the PKGBUILD I prepared.

Installing a new version of eglibc

For some reason makepkg has difficulties with the packaging of this one. It creates the pkg directory with too restrictive permissions and fails to go one with package building. The easy solution here would be to simply use sudo since root is allowed to write anywhere. However package building as root is strongly discouraged – for a good reason. If you’re not absolutely sure your PKGBUILD is completely correct, some files could end up being installed to wrong paths on your real system, creating a glorious mess! So we’re going to take the right path and avoid dangerous root packaging. Which means we have to fix that directory issue. And right: It’s actually as simple as changing the directory permissions in the PKGBUILD.

Once it finished building (which can take a while) we’re going to install it. Since the contents of the package has changed compared to the older version we have to install the new one with the –force parameter, allowing to overwrite files owned by other packages currently installed (-f as we used before doesn’t work with the updated pacman anymore…).

Now that we have replaced eglibc version 2.11 (sic!) with 2.18, we’re good to build and install tzdata. It’s an unproblematic quickie.

Installing current tzdata

On to the next step: Updating the binutils package. Binutils consists of several tools needed whenever binaries are created: like two linkers (ld and gold), an assembler (gas), the stripping tool and some more. It’s one of the bigger packages and thus takes a while to complete. Other than that there’s nothing special here.

Upgrading binutils

Next in line: The GMP library (providing some advanced math functions). Again building and installing it is nothing special. However the library received what is called a soname bump. The non-technical explanation of that is that the number after the “.so” (for shared object) extension increased. But since many applications (including e.g. GCC and pacman!) were built against the old one, they expect that it is still available and will be missing it after installing the new one.

In theory we should now rebuild all (!) packages which depend on GMP so we have a clean system again, working entirely with the new one. Of course we’re not going to do this now and even if we did plan to do so, we first need to make GCC work again. We do so by softlinking the new library to the file name of the old one with the command: sudo ln -s /usr/lib/libgmp.so.10.1.2 /usr/lib/libgmp.so.3

Updating the GMP library

The old GCC present on our system uses a package called cloog-ppl. It does no longer exist as cloog and ppl are separate packages now. With newer GCC versions ppl is now an optional dependency. And since it also is a monster of a package (compiling it on an 1.6 GHz Pentium4m machine took over 40h!) we’re going to drop it. You most likely don’t feel like building it on a pc you’re using ConnOS on, anyway, do you?

Our updated GMP enables us to build a new package – isl – which itself is a dependency of cloog. So we’re building and installing both of them.

Adding the new package isl to our system

Isl shouldn’t be a problem at all and cloog only needs to be installed with the –force parameter, as it needs to overwrite some files of the old cloog-ppl package. Of course it would be better if we could just remove the conflicting package. Unfortunately it’s not that easy in our case. Said old package is needed for the currently installed version of GCC to work so we currently have no chance to uninstall it without breaking the compiler and rendering our system useless for the further updating process.

Installing cloog

Thanks to the updated GMP we can also update another library which depends on it: mpfr. The one on our system is very old and like GMP it has received a soname bump in between. Since it’s also a dependency of GCC, we need to symlink the new library to the names in use with the old version (see the picture for details) or our compiler will be broken.

Updating the mpfr library

The last library in line is libmpc. We’re going to update it right now as it’s one more dependency of GCC. It’s soname hasn’t changed so we’re good with the update and don’t need any symlinks this time.

Updating libmpc

Finally we’re in for the true bigwing of our update: GCC! We’ve built all the dependencies for it in their newest versions available. However we’re not going to build GCC 4.8x and opt for 4.7x instead. Why? Simple. I had first built 4.8 before and all seemed to be working well. Then however I came across a rather special package required to go on. It builds its own temporary toolchain since it’s only known to compile well with certain versions of the compiler and libraries. Now for some reason (one of the more or less frequent regressions) GCC 4.8x is severely broken: Building older versions of GCC with it doesn’t seem to be working easily! And since I passionately hate software broken in such a way, I’ll ignore that there is such a thing as GCC 4.8x. Period.

For that reason we’re going to build GCC 4.7.3 (a version Arch never used since they went from 4.7.2 directly to 4.8.0). If you want to use the PKGBUILD I prepared, it builds GCC fit for the languages C, C++ and fortran. We won’t need the later right now and thus I also don’t install it yet. But there are some important packages that use fortran. So it’s good to support it, too. GCC takes very, very long to build, btw. Depending on the speed of your machine, it may even be a good idea to start building it over night.

Updating GCC

Now we have to build libtool and libltdl. Don’t look for the PKGBUILD file of the later; it’s part of the libtool source package. Also don’t ask me for what reason they are being packaged separately now…

Even if there was no new version of it, we would now rebuild libtool. Why? Because we’ve just built GCC! Libtool is tied to GCC very closely and needs to be rebuilt as well if GCC changes. Another thing about libtool which is important to know: Due to its close ties to GCC you should avoid just updating one of the two. If a new libtool is released it’s meant for the recent version of GCC and not for older versions. Also newer versions of GCC may be meant to work with current libtool and you can run into trouble if you stick with older versions. Just keep that in mind to avoid unneccessary issues.

Updating libtool

Now as a last step we need to rebuild and reinstall two packages we’ve built before: binutils and eglibc. The reason is that binutils should be rebuilt with the current version of GCC (the previous binutils package was built before we updated the compiler) and the C-library was built with both the old GCC and the old binutils. Once we’re done with these two packages we again have what is called a sane toolchain. With the big difference of course that it’s more than two full years newer than the one our system had before!

That means we’re done with the task of today’s post. Having taken a crucial step this time, we’ve already gone a fair bit on the path of updating ConnOS. But still this is just a start.

What’s next?

I’m considering to write one more updating post. But honestly I’m not quite sure if I should. Free time is a scarce resource. And thinking about how short the rest of 2013 is and how many topics there are which I’d like to write about in the remaining one and a half months… Well. I simply don’t know right now. Feel free to comment on this topic and tell me what you think. Would one more update post be a good thing or should this be the final one?

Sudo and package manager – updating an old Linux system pt.2

The previous post introduced ConnochaetOS, a nice i586 Linux-libre desktop distro which is now dead. Not having received any updates for a long time makes it the ideal target for a little (?) exercise: Updating an old Linux distro which has missed a lot of important changes!

While the previous post showed how to install, update to the most recent (albeit very old) versions available on the repos and change the filesystem to today’s (Arch Linux) layout, we’re going a little bit deeper today by doing some package building and manual updating. The goal is to build newer packages of some important programs which can then be used to further update the system.

It’s only 5 packages today – but I show the package building process in detail here so that even people new to this can easily follow it. Also the next part can then be much shorter.

Package building on Arch-derivatives

With ConnOS being an Arch-derivative, there are fortunately a great many of PKGBUILDS available for most of the programs relevant for us. Most of them can be downloaded from archlinux.org or the Arch User Repository (AUR). When it comes to completely free software replacements (like Linux-libre, a modified kernel without any binary blobs and such) there’s parabolagnulinux.org, another fine source.

With these two alone we already have a great resource which almost completely satisfies our needs. Most of the package build recipes need to be modified for use with ConnOS, primarily because both distributions are not targeted at i586 machines. However this is usually a simple thing to do.

Generally arch=(‘any’) PKGBUILDs will work without modifications if all the dependencies are available on ConnOS. If they are not, it may be desirable to modify them and drop some dependencies which may not be worth the effort. All other recipe files need to be modified to make the i586 architecture available and often to add –host=i586-pc-linux-gnu and –build=i586-pc-linux-gnu to the configure parameters, too.

In many cases this is already all there is to do and package building can begin. The more interesting part is to understand which packages should be updated – and in which order. This is not always clear. And the really tricky part is finding out what to do in case any technology leaps occurred and there isn’t simply a newer version of some package available but a whole new application (which works differently) has replaced it. However this won’t be the case in this part of the updating series.

But enough of the theoretical talk – let’s get started!

Filesystem related updates

I’ll describe what I did to update ConnochaetOS here – including downloading the PKGBUILD files (but not my modifications to them in detail). If you also want to update ConnOS, you can save yourself some time and download my update pack which contains the modified PKGBUILDs I use here.

ConnOS with the “new” kernel

Alright. We have a system which runs on top of the “new” 3.2 kernel and uses the new filesystem layout now. First I create a new src directory and a subdirectory called iana-etc in my user’s home. Then I use links to go to http://www.archlinux.org/packages/, search for iana-etc and download both files needed to create the package.

Getting the PKGBUILD with links

Since the version of links available is very old, it doesn’t cope well with compressed files. Both PKGBUILD and newer.patch are gzipped files. And thanks to gzip being an incredibly stupid program (behaving like a Windows application!) we need to add the .gz extension to both files so that we can decompress them…

Building the package

Then we’re set and can begin building the package with makepkg. If all goes well (and it should) we’re left with a new package called iana-etc-2.30-3-any.pkg.tar.xz. After we become root (with su) we can install it using the pacman -Uf command (“f” is for force and allows pacman to overwrite files currently installed by other packages). Pressing CTRL+D (or typing exit) we leave the root shell since packages should in general not be built with root privileges.

Forcefully updating the package as root

The next package is called filesystem (which could not be installed if we hadn’t adapted our filesystem’s layout to the new one in the previous post). I create a directory for it, download all the required files and decompress them.

Links again

While you can at least use wildcards with gunzip, this is not possible when renaming the files. Since there are quite a lot of them in case of this package, the for command comes in handy (for file in *; do mv $file $file.gz; done).

It should actually be adapted to ConnOS, but then again it won’t hurt anybody if some of the installed files say “Arch Linux”, right? Also I simply disabled the manpage part of it – this saves us from building the package asciidoc first and I don’t think that it would be worth our time.

Renaming files and package building

Building and installing (after becoming root) is just the same as above. This package must also be installed with the “f” switch enabled since it needs to override some already existing files which were not part of the old filesystem package. We’ll ignore the warnings and errors right now.

Modernizing a few system components

Next we have to take care of one of the biggest drawbacks with ConnOS: The unavailability of sudo! Creating a new dir for it, downloading the files, renaming and decompressing is nothing new anymore. But since we’re building a package now that contains binaries, the PKGBUILD from Arch needs to be modified. Afterwards the new package can be installed as root (for the last time now). Then only the file /etc/sudoers needs to be changed so that the new user is allowed to use sudo to temporarily gain root privileges.

Adding the normal user to the sudoers file

Now it’s a good idea to update pacman. The most important reason is because the old version ConnOS has cannot understand some important things which many new PKGBUILDs rely on (like e.g. the options variable or the prepare() function). Downloading and building is more or less like before and the modifications include disabling the depends since the PKGBUILD claims pacman to need newer versions of bash, curl and others which is not quite the case. Also some architecture related changes have to be made.

Upgrading pacman

Installing pacman is now a lot more convenient since we can use sudo from now on (no more su!). After upgrading it, the package database must be converted to the new format and the repositories should be updated, too.

The next one is a mere convenience update: Links. The version that comes with ConnOS works well enough but updating it means no more messing with gzipped files. So from my point of view it’s well worth it.

Upgrading links

So now ConnOS is in a state where it is much more pleasant to work with. Still this is just one little step compared to all the work that would have to be done to fully update the system.

What’s next?

Describing package building at length took more space than I had anticipated. So the next post will deal with a very important process: Updating the compiler toolchain!

ConnochaetOS – An example of updating an old Linux system pt.1

Surprise, surprise! Today we have a topic very different from what I guessed it to be. I’m going to write about the process of updating an old Linux system (which is in fact rather challenging due to the fact that so many things changed in the time that has passed).

Updating an old Linux system can be quite adventurous (seriously!). If you’ve never done it there’s quite a bit you can learn from the process. This post is in fact more or less just an introduction. It describes installing the system (ConnochaetOS) and making some preparations.

ConnochaetOS

This would probably have remained a little personal experiment but I wanted to dedicate this post to the memory of ConnochaetOS – an Arch-based GNU/Linux-libre distro with eglibc which was made with older PCs (i586) in mind. It has been a great distro but has been inactive for a long time. A few month ago the maintainer finally decided to shut down the project. While this didn’t really come unexpected, it still is a pity.

Well, there’s one very important sentence in Haary’s post: Of course everyone is welcome to overtake and to fork.


The ConnochaetOS logo

So far it doesn’t look like somebody will do this, though. I would consider to take it over – but then again I don’t feel that I have the knowledge needed for such a project just yet. Also there’s EERIE/ELDER to work on and while it’s going in a somewhat similar direction there are of course quite a few differences in design. Still I’d like to show how a system like ConnOS can be (partly) updated to become a more modern Linux system.

Installing the system

Currently all the files from the project are still accessible but will be removed at the end of the year. You can download the ISO directly from SF.

The ConnOS installer

ConnochaetOS comes with a very simple but friendly installer. It lets you choose how to install and then simply does the rest of the show.

Preparing the kernel images

Unlike Arch, ConnOS never was a rolling-release distro. For that reason the system packages are not downloaded from the net but installed from cd. This is actually a good thing since it enables you to install the system on old machines without access to the internet, too.

The installer finished

Once the installer is done, just reboot and you should be able to log into your “new” ConnOS system!

Starting and updating

ConnochaetOS is a desktop distribution so you will be greeted by a graphical display manager. After the login ConnOS provides us with a simple, light-weight wm (iceWM) which is quite nice.

The ConnOS login screen

First it’s of course a good idea to install any updates available from the distro’s repositories. Since there’s no sudo installed we have to do this the old-fashioned way and use su to become root. Now we have the chance to start updating.

Updating the system with pacman

There are not too many updates available (and these are pretty old, too, but installing them surely doesn’t hurt).

While ConnOS 0.9.1 comes with a 2.6.32 (lts) kernel it also has a 3.2 (“current”) kernel available. Of course we’re going to uninstall the 2.6 one and replace it with the 3.2 kernel!

Updating the kernel

Following the kernel update we’re left with a broken system for the moment. This means that rebooting now would be a bad idea. For that reason we’re going to edit /boot/grub/menu.lst and point the boot manager to the new kernel image.

Modifying the boot loader config

This is as far as we can update the system with already existing binary packages. We’ll have to do the rest by hand! To be able to do so we first need to install the development tools.

Installing development tools

Filesystem change

One of the big things that happened after ConnOS fell dormant was a change of the filesystem layout in Arch. Since all current package recipes are expecting the system to follow the new way, we’re converting our system to the new standard.

As this involves moving important system executables it cannot be done while the system is running. We’ll have to use an external live system to be able to manipulate our ConnOS installation according to what we’re up to. Unfortunately I have not been able to get this done with ConnOS’s own installation image. But pretty much any live distro should do the trick.

Making changes to the filesystem

I’ve booted into an Arch install system. Doing the changes is actually pretty simple:

  1. we need to mount the system partition
  2. we move all the files from lib to usr/lib
  3. we move all the files from bin and sbin to usr/bin
  4. we remove the directories lib, bin and sbin
  5. we create new symlinks instead which point to the new locations
  6. we modify GRUB’s menu.lst again, appending init=/usr/bin/init to the kernel line

Notifying GRUB on where init resides

So far for our preparations. Now at this point we have a ConnOS system which is ready to receive some manual updating!

What’s next?

Part two of the updating example will deal with building packages to update a few important system components and building an up-to-date toolchain (for compiling even more updated packages ;)).

Status update

Just as the title says this post is meant as a little status update. I’m currently having little free time – so don’t expect any big things right now. But there are of course still a few things going on which I wanted to let you know about.

elderlinux.org

The project homepage has finally received something that can be called a design. I’m using a slightly modified version of a template which is available for free use. So far everybody I asked liked the colors. Any (different) opinion? Write me a comment and tell me!

Also the homepage offers some limited content now. It’s still not much but it’s a beginning.

The new elderlinux.org design

Free time is scarce and the process of building the homepage and maintaining it is something which will take me a while to get familiar with. So this does of course have a huge impact on both my blogging activity here and on the EERIE development.

eerielinux.wordpress.com

While I’ve certainly only used a small percentage of all the functions WP.com offers me for free, I’m pretty much accustomed to work with these after more than a year of blogging. Despite that the world WP.com is slowly getting too small for me and the needs of this blog. On the one hand it offers a lot of features I never felt the need for. On the other however there are features which it doesn’t provide and among which are some I’d really like to use.

The one big problem I was having for quite a while was that I’d like to adjust the width of the two columns the blog page consists of. Not possible with WP.com. And now finally with the homepage up the need arises for a consistent theming. The template which I use for the page even offers a WP.org theme, too. But it’s not possible to use it with free WP.com.

These two issues are the main reasons why I’m considering to move a way from WP.com free hosting. This is also why I’m going to try out if I’m able to manage a WP.org installation myself. The plan is to set one up on a private pc and play around with it until I’m satisfied. The next step would be researching how to migrate this blog to a self-hosted one. I haven’t found the time to do anything in that direction but I’ll keep you updated.

GTK+ tests

So far I’ve started compiling a list of GTK+ based file managers. I’m not done with it, yet, but I hope that I can start testing them soon.

Afterwards, just like with Qt, I intend to test some GTK+ text editors, too. That would conclude the GTK+ series of posts.

DDD and desktops in general

Recently I’ve come into a situation where a better version of the DDD would have come in handy. For that reason I plan to soon give it another shot, too. And the desktop comparison of last year has been one of the strong points of this blog. However I feel that a lot of things have changed since then. E.g. OpenCDE is gone, Consort has arrived and it might be nice to compare new values against the ones from last year! Maybe it is a good idea to repeat these tests? Feel free to comment on that issue. I’m slightly in favour of repeating it but – again – time is the limiting factor here.

What’s next?

Good question. There’s currently a whole lot of things which I’ve started working at. Most likely I’ll try to get the GTK+ file managers done first. But at this point I won’t promise anything.

New domain registered

Here’s some probably unexpected news: While it may look like things are slowing down if you just consider this blog, there has been a lot going on behind the curtain. So far I’ve given a few hints but now its time to reveal a bit more information.

Progress

Project EERIE was created with two goals in mind: I wanted to learn more about the nuts and bolts of Linux and I dreamed about creating a new distribution – both for learning purposes again and to change a few things I was never happy with the other distros. And while I was at it, it seemed like a good idea to share it. Still I wasn’t sure if I’d have the endurance to stick to that project. And of course I had no idea if anybody would actually care for what I was trying to do. Luckily those concerns proved to be false.

The monthly hits of the blog are increasing and finally people even start to write comments. Also the amount of people who don’t just read one or two entries but also visit the About Eerie page grows. Better yet: I’m in contact with two other Linux users who’d also like to build a new distro. While there’s still a lot things to be discussed actually quite a bit of work has already been done. We’ve done some tests which enable us to make important decisions. In fact I have already built a test distribution worth of over 500 software packages (about 2.6 GB compressed data). We’ll have to start over once we’re done with planning. But building these was a very informative task and will surely be very helpful in the future.

A step ahead

Since things are going nicely imo, I decided to make a step ahead and get a domain for the distribution to be. Today elderlinux.org was registered! Right now there’s no content there, yet. But you can now use the new URL blog.elderlinux.org to reach the EERIE blog. For now it redirects here.

Placeholder text on the new page

There are a few things which I’d like to do in the near future. Of course I’ll continue with the toolkit tests. But I’ll also try to set up my own WordPress installation and will perhaps transfer the blog completely over to my own space. We’ll also have a forum where we’ll discuss all the issues of the distribution to be. Everybody is invited to join us there. There are almost always some points where people are not happy with their (otherwise) distribution of choice. Tell us what you think! What makes a good Linux distribution? What are annoying issues with the existing ones? What are things that should be experimented with?

ELDER Linux!

We’ve already got pretty clear ideas of where we want to go with ELDER. I’m going to save the details for a later post but one thing that I can already say is that it’s going in a light-weight direction. And while that word is often a bit, well, unsubstantial, be assured that we really mean it. What we have in mind is a desktop distro with a rather small base. It won’t exactly be minimalistic – just very light.

As the name ELDER suggests, it should also run well on older machines. Everything that needs a strong CPU and tons of RAM is strictly optional. If all works as intended, you will be able to do some pretty nice things on newer machines but it should also allow you to resurrect some of your old pre-Pentium 4 machines – and actually put them to some use!

Back to work

While we’re pretty confident that we’ll be able to cook up something any help is appreciated. Feel free to contact us if you consider lending us a hand. There are plenty of fields where some work could be done. Whether you want to discuss your ideas on how to organize the file system, whether you’re an artist and would like to contribute some nice artwork or whether you even think you have no special abilities but are interested in how a distribution is planned and created – just join the discussion. We’re all hobbyists. Linux is meant to be fun. And if one thing is certain then it is that there’s lots of fun to be had in the process of creating your own operating system.

EERIE’s first birthday!

Today it’s exactly once year since I’ve made my first post here. One whole year has passed on this project and it’s time again to look back. If EERIE was a human child, it’d still be wearing diapers but would also have grown quite a bit and learned enough to make the parents proud!

Where EERIE comes from

On a personal level I was an ordinary Linux user who wanted to get to know his operating better. Distro hopping was fun (and informative) for some time but I wanted to get into it a fair bit deeper. While this of course involves a lot of reading, it’s always best to just try out things yourself. Thanks to virtual machines (which are clonable without much hassle) you can just do your experiments without fear of breaking anything critical. I did just that pretty often (things like uninstalling glibc is obviously not a smart thing to do – but there are moments you just want to know what exactly will happen if you do it anyway!). I’ve been breaking things out of curiosity sometimes (and aware of what I was about to do) but most of the time by accident or ignorance.

I had already been interested in how programs are being packaged and how the various distributions were made. Soon the question arose: “How do you actually start a distribution?” I read what I could find on that topic and went back as far as possible to the beginning of some of the big distros. Then I tried to imagine how things really started and begun to grow. I finally got hooked by the idea to try this out for myself. It wouldn’t need to be something special – maybe not even something useful in the narrow sense of it. Just the result of a little playing around and a personal project for the sake of learning how you do it.

Linux From Scratch (LFS) would be an excellent thing to begin with, I thought. And since I had been reading a lot on the net I figured that I might as well share my experience with the project. The worst thing that could happen would be that nobody cared for it but probably a few people might find it informative. I decided that it wouldn’t hurt to just give it a try as well. However I never completed LFS since I soon became distracted by plenty of other things!

During my preparations (I was just reading the Filesystem Hierarchy Standard (FHS) since I had always found the filesystem organization a bit confusing) I begun to wonder if I really should just build a distro “by the book” (which LFS is literally all about) or if that wouldn’t mean a missed chance to do something else at the same time. There were a few things with every distro that I wasn’t happy with. Wouldn’t it be a good idea then to build an experimental distro which tried to do things differently in those cases? I decided to create a free blog and just start with it (and see if I have the discipline to stick with it). When I talked to Pheak about my ideas he liked them and joined the project. So far we’ve worked on it independently and he remained more or less in the background, helping me out when I ran into problems and giving suggestions.

The project

Pheak and I decided that the goal for project EERIE (short for “Elementary energy-efficient resource-saving internet experiment” ;)) would be to come up with the base for an experimental desktop distro. So its primary task was and is conducting a series of tests to find a base suitable for it. Also a subproject emerged from the desktop environment tests: The DDD (Desktop Demo DVD). It’s all about bringing as many DEs as possible together on one live medium so that anybody interested in it can easily try them out and compare them to each other.

What has been accomplished so far? A lot actually.

  • I started with describing how I came to Linux (more or less to get familiar with blogging at all)
  • and by offering a few thoughts on Linux for desktop use.
  • First I tried to do my tests with Gentoo but eventually changed to Arch (which Pheak admittedly proposed right from the start).
  • The desktop tests were published in a series of 5 posts (dealing with 3 – 5 DEs each!).
  • Then the various toolkits were discussed and compared briefly.
  • After that I wrote about live cd creation on Arch and released the first alpha version of the “DDD”.
  • The next posts contained thoughts about which applications are crucial for a desktop distribution.
  • Following this I posted comparisons of Qt-based programs to find out which were the most light-weight ones.
  • While I intended to release a new version of the “DDD” and then go on with the GTK applications I postponed these topics and wrote about something I was just messing with at that time: Other Unix-like systems and their Arch variants.
  • And last but not least I managed to get an interview with the EDE (a FLTK-based light-weight DE) developer!

But that’s not all. There are a few other things I kept silent about. While I won’t reveal anything yet, let me tell you that these mean going a huge step beyond of what has been done so far (just doing tests and such)! πŸ™‚

The blog

I’ve already taken a look back after 3 month and after 6 month. I’m quite happy that the trend of more and more visitors coming here has continued.

There are days with more and days with fewer hits but there has not been a single day this year without any visitors. In the 12 month it has existed so far, the blog already scored well over 3,600 hits (exactly 3,625 as I’m writing this)!

Number of daily visitors, etc.

While the weekly hits are of course also fluctuating a bit, they cover a much longer period of time and thus show pretty well that overall the number of hits is increasing. As if it were called for this week is an exceptionally good one.

Weekly hits and visitors

While last year saw November scratching at the 300 hits per month mark, January and February have crossed it. March then stormed forward, skipping 400 hits and coming close to 500! And since June is not over yet – maybe it’ll be the first month to exceed 500?

Monthly hits statistics

So far I got visitors from 85 (!) countries in the world, 7 of which have over 100 hits. Here’s the top countries 30:

Visitors by country

Also the average hits have increased steadily. The best month last year was November with 10 average hits per day; currently it looks like June has doubled this with 20 hits per day on average! The number of total hits has even more than doubled when we compare the six month of last year and of this year. 2,600 hits alone in the first half-year of 2013 – and counting!

Daily and monthly averages

I can only say that I’m very impressed by these values. Of course I had hoped that some people cared for what I post here (especially since I’ve put quite a few hours of work into it). But even in my wildest dreams I would not have hoped for well over 3,500 visitors in the first year! I also didn’t dare to think I would be able to write 3 posts every month (on average). 36 posts so far – I think that’s a nice achievement.

But none of all that is what actually makes me happy the most. While hits were also increasing before, I was really missing feedback. Now I’ve finally got my first comments and thanks to that got in touch with another light-weight FOSS enthusiast (and we’re discussing the details of something I’m looking forward to reveal to you later this year)!

What else can I tell you? Well, you probably already know it, but few days ago I, too, was witness to the fact that spam really is EVIL!!!!!!!!!1111one For proof just look here:

666 – the number of the spam!

And just like in my two previous retrospect posts here are some of the (funny or unusual) search engine terms which lead to the blog:

  • qt3 games for linux
  • game windows 95
  • archbsd pacstrap fails
  • “dos gui” tool download
  • ede live cd
  • best fltk based applications
  • extraordinary linux distro
  • fltk webkit
  • eeire linux
  • windows 2000 control panel
  • installing archhurd
  • xfdos forum
  • “nowadays” distribution with trinity desktop
  • future of linux desktop 2013
  • windows 3.11 wallpaper
  • fltk 3.0
  • energy efficient linux
  • how to start plasma from tty2
  • 56647680 b to mb
  • fltk vs fox vs tk
  • xfdos
  • linux exotic desktop distribution

What’s next?

So what can you expect from EERIE in the future? Of course official announcements of what I made hints of above. Other than that I want to resume work on the “DDD” and get the tests with the GTK+ applications done. Not sure in which order.

And then there’s of course a lot of other things to investigate when planing a new distro. Which standard C library to use? Which compiler to build with? Which package management system to choose? There’s enough to do so we won’t get bored!

Taking a look at ArchBSD

[UPDATE 06/2016: The project has changed its name and is now known as PacBSD. I’ll leave the rest of the post as-is.]

Today’s post will deal with ArchBSD, a rather young project which brings the familiar Arch way to the FreeBSD world.

Edit: Sorry for the delay in making this post public. Just like with the previous post I was having problems with the images. Also had to replace some of them.

Prerequisites and Installation

First go here and download the iso. This post was done with the new iso released in the beginning of this month.

If you’re going to try out ArchBSD in VirtualBox you better enable the IO APIC function first. Otherwise the FreeBSD kernel won’t boot and it’s not even going to give you any error message.

Enableing IO APIC in VirtualBox.

Let’s boot the iso! The new boot loader (GRUB 2) is looking nice. The previous iso still came with another boot loader.

ArchBSD’s boot loader on the live iso: GRUB 2.

It’s a good idea to follow the official install guide. I only have two things to add:

  1. Be sure to replace daX with adaX when referring to the hard disks.
  2. If you’re as lazy as me and use auto-completion even for /mnt, be sure to remove the tailing slash since the command ‘pacstrap /mnt/ base‘ won’t work.

Mind that and you should be ok. I won’t cover more of the installation here; except for those two things the guide is fine and the installation procedure is typical nowadays Arch-style.

Pacstrapin’ the “base” group.

The installation is a bit faster than that of ArchLinux since the base system is (currently) a little smaller. As you can tell from the packages and their download sizes, ArchBSD could more or less be called “FreeBSD with pacman“.

ArchBSD!

After setting it all up and rebooting we’re greeted by the ArchBSD boot screen. It features some very nice ASCII art and has a clean look. This is how things should be. Great work if you ask me!

The ArchBSD boot screen.

The FreeBSD kernel boots a little slower than we’re used to with the Linux-based system. But when the system is up we find a familiar Arch environment where little shows that this is not Linux.

ArchBSD has started.

Working with a distribution following a rolling release model our system is already up to date after installation and doesn’t have to be updated. So what to do next? Let’s see if ArchBSD provides Xorg! Does it? Of course it does. However it does not currently have twm available so we can’t simply get the traditional X11 – but who seriously uses that today?

So far nobody has packaged GNOME or KDE but since this is a nice slim system it’s not like I’d miss them here. Currently I have the choice between Xfce or LXDE if I want a full DE. LXDE is fine for me.

Installing the “lxde” group.

Just having LXDE installed, we really have a fairly light graphical system: Just look at the menu! There’s almost nothing there (which is good since that means we can install whatever we want).

LXDE running on ArchBSD.

Alright. Next we have to populate that bare system a bit, right? One of the most important things today surely is a web browser. ArchBSD currently offers Chromium and Links. Both are nice browsers in their own regard, the first one probably a bit too heavy, the later a bit too minimalistic. I’d like something in between – and that probably makes for a good next step! Let’s install the development group and links so I can get some PKGBUILDs from the ArchLinux site.

Installing “build-devel” and downloading PKGBUILDs.

Now things are getting a little more interesting. Just building the FLTK packages on ArchBSD using the ArchLinux PKGBUILD doesn’t work. The sed utility from the BSD world works differently and packagers for ArchBSD are to translate the lines calling sed. Since I have no experience with BSD sed, I’d have to read how to do it. Fortunately ArchBSD comes with gsed, too, the familiar GNU sed utility. It’s deprecated to use that but since I’m not an official packager and just want to get FLTK running, I guess it will be ok to just use that. After calling gsed and commenting out the lines installing the LICENSE files as a quick and dirty “fix”, FLTK compiles nicely and the packages are built.

Let’s install FLTK and try to build Dillo, a very light-weight FLTK based browser. The default ArchLinux configuration wants OpenSSL which is not (currently) available on ArchBSD. So for this quick look at the system it will suffice to just build Dillo without SSL support. It works perfectly and after the package is built, I can run the application:

Running the freshly built Dillo.

Well, obviously building packages on ArchBSD works well. You can easily run into problems (like with the OpenSSL package), though since the BSD world is quite a bit different from Linux under the hood. In cases like that a bit of deeper knowledge is required.

You have some time on your hands? You like what you’ve just seen? And think you’re cool enough to be part of BSD? Why not give ArchBSD a try then? Head over to their forums sign up there and lend them a hand! They will surely appreciate it.

What’s next?

The next post will be something special. I won’t spoil it here – but it has something to do with my favorite light-weight DE. Guess which one that is!

Taking a look at ArchHurd

Just as promised, this post will deal with ArchHurd a project aiming to bring what makes ArchLinux great to another kernel: GNUMach/GNUHurd.

edit: Sorry for making this long finished article public so late (same for the next one)… WordPress was giving me a hard time with my screenshots for some reason. But now I got things fixed.

Booting the live CD

So… Let’s take a look at the ArchHurd, shall we? However… Things are a bit.. messy right now. Let me make that absolutely clear before you might decide to give it a try, too. Don’t expect everything simply work like a charm. It won’t.

First it’s necessary to get the iso from the project’s download page. Don’t try to open the Installation Guide which the page links to. It points to the old wiki – which is gone. There are plans to re-add the old pages in the new wiki but this has not happened, yet. Fortunately there’s the Internet Archive which has archived the old wiki so that we can still access it here.

The bootloader: It has written “experimental” all over it.

The iso boots in a new VM set up for it. Despite the “hit ‘e’ and edit hd2 …” stuff things work if you have a standard VB configuration – and you wouldn’t be trying out ArchHurd on real hardware, would you?!

Booting the GNUMach micro-kernel.

Just be patient while the kernel probes the hardware – the rather old version which is used in ArchHurd contains a few glitches which make it take a long time to complete when used with Virtual Box.

Login – it’s not done automatically, yet.

Installing

Alright! ArchHurd has started up and we can move on to installing it. Just one more warning: There’s some kind of error in the kernel which makes the system freeze if doing nothing for a while. So keep it busy or pause your VM if you don’t want to reboot often!

Package selection in the installer.

I won’t cover the installation here – just follow the Installation Guide. The installation program is quite self-explanatory and the guide covers the rest you might need to know.

System configuration in the installer.

If you’re a long-time Archer, you’ll remember the “Arch Installation Framework”. If not, you’ll find out ArchHurd is also an OS without systemd and you have to take a look at rc.conf, the central configuration file which Arch Linux was famous for in the past.

ArchHurd!

After installing the bootloader according to the guide, we’re left with a working system. And after setting up network, it’s even actually usable. πŸ˜‰ However the first time trying to update the repos, pacman crashed for me, so I had to remove the lock and try again. But from that moment on, network works fine. If you’re having trouble, selecting an older network card to emulate in VirtualBox (like PCnet-FAST III) might help with the Hurd.

Now let’s see how many new packages have been uploaded to the repos since the creation of the (now rather old live cd)!

Update the system?

Right, 31 packages is not really much… Especially if you’re used to ArchLinux’s rate of updating! So it might be a good idea to edit /etc/pacman.conf and uncomment the “testing” repo.

Updating with “testing” repo enabled

That’s not really up to date either, but at least a little more up to date. Ok, all nice and well… It’s a funny system – a little slow perhaps, rather old and pretty unstable. But what now? That just can’t be all.

Xorg running on ArchHurd

Of course not. X11 anyone? Yes, it does actually work. However I failed to get mouse support working in VirtualBox. If the xf86 driver for it is installed, Xorg won’t start anymore. Since I’m not an X guru, this is where I stopped and that’s also why I skipped showing you that ArchHurd is capable of running Openbox, too (which does in fact work – but is quite useless without a mouse…).

Anything else? Yes, a lot. The Arch Build System is working which means that you could build your own packages if you’re missing anything (which is rather likely ;)). That is: If you are lucky and the package will just work on Hurd – and if not you need some deeper knowledge about porting things over.

Building a package on ArchHurd

As an example I tried to build FLTK – and that proved to be one of the packages that simply worked. However I had trouble building with an ordinary user. The problem is known among ArchHurd developers and it’s not happening if you’re building as root (appending –asroot so that makepkg accepts this). I know that this is usually considered bad practice and should never be used on a productive system. But we’re playing around with the Hurd here, aren’t we?

Alright. This concludes our little examination of ArchHurd. If you liked what you just saw and are feeling brave enough – why not help the project a little? While it’s officially being worked on, it would certainly be nice if some visible progress was to be achived.

What’s next?

Next I intend to take a look at ArchBSD. Edit: You can count on it. I’ll do a little revision of the article and then set it to “public” in a few days.

Situation of the Linux Desktop #2: Habemus tumultum…

… qui nomen nominatur “pacem”!

Wow, Latin! Oh er, welcome back! Wonder what that strange sentence does there – and what it may have to do with the Linux Desktop? Well, due to unforeseeable incidents when moving houses along with some family matters, I was more or less cut off from any news. I didn’t have internet connection for about one month and was not in the mood to buy a newspaper (and since TV and radio programs are more or less useless to disgusting and a total waste of time, I don’t own a TV or a radio). You can probably imagine how surprised and amazed I was yesterday when I finally read what had happened in the meantime!

The news of not even a handful of weeks missed – and all of a sudden the Roman Catholic church has a new pope (even though the old one didn’t die!). That was what inspired my headline which translates (or at least should translate) to: “We have a turmoil… which is called (the name) peace!”

“ΠœΠΈΡ€”

“Peace”?! Yes, peace. It’s one possible translation of the Russian word in the sub-headline above. Others are “world” or even “universe”, but I couldn’t resist to put together peace and turmoil. πŸ˜‰ What the heck am I talking about? Alright, alright. You’ll know what I mean right away. “ΠœΠΈΡ€” is pronounced… Mir!

Well, Mir! You’ve probably heard of the new display server which Canonical (makers of Ubuntu) announced. Even this announcement had a huge impact in the Linux world. A lot has already been written about it. But this is one topic that clearly affects the subject of my blog – the Linux Desktop. While I tried not to be too biased about Ubuntu in the past, Canonical are giving me a hard time once again.

Closed graphic drivers

My position on the efforts of Canonical, Valve and others was one of cautious confidence that it could be of great value to the Linux community. I’m not one of those Linux fans who want this operating system to “succeed” and I don’t really care for market shares and things like that. But there’s certainly some truth to the fact that we’d all benefit from good drivers provided by the companies who build the hardware. Yes, while I prefer open drivers (for obvious reasons), I don’t have a problem with closed drivers being available, too. It’s one additional option for those who need the performance, reliability, etc.

It’s common knowledge that X11 is really old now and that this is not just beginning to show. For the conservative desktop environment X will remain the display server of choice but the general next step, the future of the modern Linux Desktop would be Wayland. Almost everybody agreed with that – at least until early march. A few years ago even Canonical had praised Wayland and planed migrating to it in the future. Now said Company is developing their own display server Mir…

Canonical’s Mir and Wayland

Alright, Canonical have abandoned the classic desktop with Unity and are clearly aiming for the mobile market. That’s ok, I guess. But developing a new display server and convincing Nvidia (who already hesitated to support Wayland!) to support it instead of Wayland is not a nice move at all. Doing so at this particular time (before Wayland could actually play any role) really looks like an attempt at backstabbing that other display server for me!

Thanks to Canonical, Nvidia will be even less motivated to offer drivers compatible with Wayland. Canonical’s founder even boasted of Mir possibly running on more devices than Wayland! That sounds like a plan. A plan that may be very profitable for Canonical but also a plan that can prove to be devastating for the Linux community. How to treat the new situation? Curse and boycott Mir? That’s probably overreacting. Embrace and praise Mir? Certainly not at this time. Anyway all this is a development that we should eye closely. Perhaps Mir will provide a few interesting features in the future. Right now it’s just a concept – and a splitting one. Let’s see what happens next.

GNOME 3 and Consorts

Another thing has happened since I wrote the first “Situation of the Linux desktop” in November. MATE is no longer the only promising GNOME fork. Now there’s also Consort.

The difference between them is that MATE picked up the dead GNOME 2 and remains based on the GTK+2 toolkit. According to the makers of Consort, this is “dead technology” and their effort is maintaining a classic GNOME desktop based on GTK+3. GNOME 3 will be dropping their “GNOME classic” or “fallback” mode with the upcoming version 3.8. This mode resembles GNOME 2 in many ways – but the most important thing for many people is the fact that it does not require hardware graphics acceleration. So Consort will be picking up where GNOME 3 Classic left.

Currently Consort doesn’t work with Arch Linux so I didn’t test it, yet. So I can’t say much more about it right now.

The situation!

The Linux Desktop has fragmented even more since my last post. With Consort there’s a new desktop environment in preparation and with Mir there’s even a new display server in the making. The later could even be seen as a hostile attempt to sabotage Wayland. More than ever the situation is getting unclear and confusing. Probably a good time to work on the DDD again?

What’s next?

Next I’d like to release a new version of the DesktopDemoDVD.

Qt-based applications #3: Text Editors (2/2)

The last blog entry was about a test of 9 Qt-based text editors (those which I could get to run on Arch Linux). And since the comparison of so many programs and values is not really an easy thing, here’s a second post providing some tables which show the programs sorted not by name but by values.

Overall ranking

Here’s the table with the overall results. The text editors were compared in terms of 1. memory consumption (most important for me and thus weighted *3), 2. disk space used (weighted *2) and 3. size of packages to download:

Rank Text editor Version
01 Minerva GIT20130220
02 CuteNotes 0.9
03 TEA editor 34.0.1
04 Catlooking Writer 1.0
05 JuffEd 0.8.1
06 FocusWriter 1.4.1
07 KoalaWriter 1.0
08 Marave 0.7
09 kWrite 4.10

RAM usage

Here’s the table comparing memory use:

<10 MB 10 – 25 MB 26 – 50 MB > 50 MB
Rank Text editor Version
01 Minerva GIT20130220 4 MB
02 TEA editor 34.0.1 6 MB
03 Cutenotes 0.9 8 MB
03 JuffEd 0.8.1 8 MB
04 Catlooking Writer 1.0 15 MB
05 FocusWriter 1.4.1 26 MB
06 KoalaWriter 1.0 36 MB
07 kWrite 4.10 64 MB
08 Marave 0.7 78 MB

Drive space needed

Here’s the drive space table:

<20 MB 20 – 100 MB 101 – 200 MB > 200 MB
Rank Text editor Version Disk space used
01 Cutenotes 0.9 +1 MB
02 Catlooking Writer 1.0 +2 MB
03 Minerva GIT20130220 +5 MB
04 TEA editor 34.0.1 +6 MB
05 JuffEd 0.8.1 +7 MB
06 FocusWriter 1.4.1 +9 MB
07 Marave 0.7 +154 MB
08 KoalaWriter 1.0 +363 MB
09 kWrite 4.10 +582 MB

Download size

And the download size table:

<1 MB 1 – 10 MB 11 – 50 MB >50 MB
Rank Text editor Version size
01 CuteNotes 0.9 +143 KB
02 Minerva GIT20130220 +319 KB
03 JuffEd 0.8.1 +973 KB
04 Catlooking Writer 1.0 +1.2 MB
04 TEA editor 34.0.1 +1.2 MB
05 FocusWriter 1.4.1 +2,4 MB
06 Marave 0.7 +24 MB
07 KoalaWriter 1.0 +77 MB
08 kWrite 4.10 +126 MB

Conclusion

When it comes to Qt-based text editors, we can see huge differences between them. With Minerva there’s an editor that really deserves the MIN in its name: It does good in all aspects and is the winner in this test. Rank 4 for the Catlooking Writer shows that even those non-distracting writers don’t necessarily have to be extremely resource-hungry. And well, no surprise: kWrite scores the last rank since it depends on the super-heavy kdelibs.

What’s next?

Next I’d like to pick up the DDD again and create a new version. Then I’ll examine the basic GTK+ applications.

This post was written on 02/27 and automatically published. If I didn’t remove that line that means that I still don’t have a working internet connection.