Creating an Arch Live-CD

This post is about something which I actually wanted to try out for quite a while: Building a custom Live-CD!

Another “Rolling Release” annoyance

Today I just wanted to give a little tool called archiso a try – however it wasn’t just as easy as that. I was off for some weeks and when I returned home now, my Arch-powered machines couldn’t even connect to the net after doing an update… What happened? Well, the trifle of replacing SysVinit with Systemd

Yes, I know that it’s really my fault and that I should read the Arch news on a regular basis. But honestly: For people who have various distros in use, always keeping up with the latest changes proves be a pain in the proverbial. Once again I can only praise Gentoo for providing a news system inside the OS (“eselect news”) where important changes are announced a long time before they actually take place. This is definitely something that Arch lacks. At least IMHO.

Setting up our system

So what are we going to do this time? The idea is to be left with a bootable iso that loads Arch Linux and provides a graphical DE of some sort, preferably something not too big that needs to be installed as a custom package. I choose EDE² for that reason.

Since it’s always a good idea to start over with a clean system, let’s download the latest Arch install CD and in the meantime set up a new VirtualBox VM. In installing I follow more or less the way that the installation guide on the wiki suggests (which has not yet been updated to cover systemd).

Thanks to that change, I have to create a network profile in /etc/network.d/ (or copy one of the examples). After adding this profile to /etc/conf.d/netcfg, both netcfg.service itself and net-auto-wired.service have to be added to the services loaded at system start. That brings my network back.

Preparations

Alright. Next, I install sudo, links, git and wget (archiso needs it but it’s not listed as a dependency). Then I create a new user named “builder” and add him to the sudoers. Now I can logout and login again as the new user.

The version of archiso that’s in the repos is old and no longer working (among other things thanks to systemd). So we’re using links to go to the AUR and download the PKGBUILDs for archiso, edelib2 and ede2. Now let’s build packages for these, shall we?

Once that’s done, I log out “builder” and log in as root again. I create a new directory /root/newrepo, copy the edelib and ede packages there and change to that dir. Then I use repo-add newrepo.db.tar.gz edelib-2.0.1-1-i686.pkg.tar.xz to create a custom local repo (and add ede-2.0-3-i686.pkg.tar.xz, too, using the same script). Now I just install the archiso package I compiled from the AUR and we’re good to go.

Content of the archiso-releng

Configuring archiso and building!

First we create a new directory /root/archlive and copy the content of /usr/share/archiso/configs/releng/ there. Next I add my custom repo to the pacman.conf file in the new releng directory (that’s the one that is used for the build process, not /etc/pacman.conf! Now all that is left to do is actually adding packages to /root/archlive/releng/packages.i686.

I choose to add xorg-server, xorg-xinit, xf86-video-vesa, xf86-input-evdev, libxpm, edelib and ede. Finally I can issue the command ./build.sh -v build single netinstall afterwards. The script begins building!

Archiso scripts building the initial ram file system image

The script first syncs all repos and downloads the needed packages. Afterwards they are installed and an initramfs image is build which doesn’t take a long time. The next thing the script does is building multiple squashfs’. These are compressed read-only file systems that archiso makes heavy use of. Since it uses strong compression, their creation take quite a while.

Archiso scripts building the squashfs file systems

Once it’s done, we’re left with an iso file placed in the out folder. Yes, that’s all!

Of course, as you can see in the first image, there are some more files that would allow for some more customizing but for our basic purposes what we did here was actually all we had to!

Archiso scripts: building done!

Testing the iso

Now it’s time to test the iso. I could burn it to a real cd but that would be a pure waste. Luckily VirtualBox can boot from an iso file just like from a real cd.

Boot menu of our freshly built iso!

In my case all went well and I was able to boot from the iso. And finally I can startx into the desktop environment I chose for it!

I have to confess that I thought things would be a lot more difficult. But of course our example was about the simplest case one could come up with. Adding more files to the iso, setting up users, adding a display manager for graphical login, etc. are things some people might want to consider, too. But that’s a little beyond the scope of this entry.

Starting EDE² from the iso

What’s next?

The next post will reveal what the “DDD” is that I’ve been playing with for quite a while now.

Advertisements

Linux GUI toolkits

We’re going to examine 7 toolkits in just a minute after discussing how to deal with this topic. These 7 are:

Some people say that Linux is all about is choice. True or not: When it comes to toolkits, it’s usually the programmers who have to make a choice. They have to check if a toolkit provides all the features they want and if they feel comfortable with its syntax and so on. However this blog entry is not about recommendations for programmers (there’s probably enough material out there already).

From which perspective are we going to look at them, if not from a programmer’s? Simple! From the perspective of a distribution creator wannabe! 😉

Distributions and toolkits

For a distro creator things are much easier here – he could decide at will or even decide not to make a decision for one but support several (or all) available toolkits instead. There are reasons why this makes sense. Many modern systems combine for example Qt and GTK+ since the users often “mix” applications of both TKs. You like the well-known VLC? Then you have Qt on board. Using GIMP, too? Not without GTK+! Thanks to the theming ability, you usually won’t even notice that your default applications relay on different toolkits.

However there’s also a very good reason not to provide several toolkits by default: They all use up valuable system resources! In the planing especially for a light-weight distribution, it’s a very good idea to make a decision towards one standard toolkit and package default applications which use this particular one.

However it’s not as easy as that in this case. There are lighter and heavier toolskits. Of course the lighter ones lack several features that the others provide. But even more importantly for us: There are huge differences in the number of applications available for each TK! Unfortunately it’s the lightest TKs which have the lowest number of programs using them… So let’s take a closer look at this post’s topic!

Test criteria

As I said before, we won’t examine the TKs in their technical aspects (or distinguish between toolkit, development framework, etc). Of course things like FOX not supporting themes can be very relevant when deciding on the right standard toolkit for our distro. But that’s beyond the scope of this blog entry.

We’re just going look at the various TKs in terms of how “heavy” the are. To do this, we compare the amount of drive space they need, how long they take to compile and how many dependencies they have. The first is done with the Arch Linux packages for the particular TK and the rest on a fresh Gentoo VM (emulating a single core 2.66 GHz pc with 2 GB ram and compiling with -j1) with just X11 installed. There are however a few things which make our comparison a bit difficult – for that reason I’ll explain each toolkit on its own first and provide a table at the end of the post.

Qt4

I thought about including Qt3, too, for a moment. Why? Well, it would have made a nice comparison on how much heavier Qt4 is and besides that, Trinity DE still uses it. But Qt5 is already on its way and so I decided to discard it.

Qt4 is one colossus of a TK! The Arch package (qt-4.8.2-3-i686.pkg.tar.xz) is 21.0 MB in size and 80.4 MB uncompressed!

It’s so big that it was split into smaller packages on Gentoo (qt-script, qt-bearer, qt-sql, qt-xmlpatterns, qt-opengl, qt-core, qt-phonon, qt-test, qt-declarative, qt-demo, qt-mobility, qt-qt3support, qt-svg, qt-dbus, qt-multimedia, qt-webkit, qt-openvg, qt-assistand, qt-gui). 115 packages have to be compiled and installed and 386 MB downloaded from the net to do this! The source code for Qt alone (qt-everywhere-opensource-src-4.8.2.tar.gz) is 234 MB in size; the total compilation process takes 3:20:45 of which Qt alone takes 2:32:14!

GTK+3

GTK+3 is not actually a stand-alone TK but in fact extends and as such depends on the older GTK+2.

The Arch package (gtk3-3.2.3-3-i686.pkg.tar.xz) is 6.6 MB in size (together with GTK+2: 13.3 MB) and uncompressed it needs 51.5 MB (together with GTK+2: 106 MB).

Building it on Gentoo means compiling and installing 89 packages whose source code is 132 MB in size of which the GTK+3 source makes up 12 MB (together with GTK+2: 24.6 MB. Compiling takes 45:51 minutes of which 5:37 are for compiling GTK+3 (together with GTK+2: 11:27 minutes).

GTK+2

The Arch package for GTK+2 (gtk2-2.24.10-3-i686.pkg.tar.xz) is 6.7 MB in size and 54.4 MB uncompressed.

To install it on Gentoo, 88 packages have to be built and 120 MB of sources downloaded. GTK+2 source code makes up 12.6 MB of that. Compiling the whole thing takes 40:00 minutes and GTK+2 alone takes 5:50 minutes.

GNUstep

GNUstep, being based on the objective-c language, has the disadvantage that the whole GCC needs to be recompiled with OBJ-c enabled on Gentoo. This is of course a very big factor, but while I wanted to mention it, I’ll subtract the GCC recompile on the comparison.

GNUstep consists of several packages by default. The Arch packages (gnustep-back-0.22.0-3-i686.pkg.tar.xz, gnustep-base-1.24.0-3-i686.pkg.tar.xz, gnustep-gui-0.22.0-3-i686.pkg.tar.xz, gnustep-make-2.6.2-2-any.pkg.tar.xz) are together 3.9 MB in size and 16.7 MB uncompressed.

Building on Gentoo means installing 93 packages for which 206 MB of source code needs to be downloaded (including GCC recompile) or 92 packages, 141 MB in size (without GCC recompile). The packages (gnustep-base-1.24.0.tar.gz, gnustep-gui-0.22.0.tar.gz, gnustep-make-2.6.2.tar.gz, gnustep-back-0.22.0.tar.gz) are 7,0 MB in size. Compiling takes 1:27:13 (including GCC recompile), 43:51 minutes (without it) and 4:22 minutes for GNUstep alone.

FOX

The Arch package for FOX (fox-1.6.40-1-i686.pkg.tar.xz) is 3.9 MB in size and 13.8 MB uncompressed.

Building it on Gentoo means compiling 6 packages whose source is 5.0 MB in size of which FOX’s source code makes up 4.3 MB. Compiling it all takes 5:59 minutes and FOX alone takes 4:49 minutes.

OpenMotif

OpenMotif’s Arch package (openmotif-2.3.3-2-i686.pkg.tar.xz) is 3.3 MB in size and 10.3 MB uncompressed.

Installing it on Gentoo means building 4 packages for which 6.7 MB of source code has do be downloaded, 5.9 MB of source for OpenMotif alone. Building it takes 3:29 minutes while OpenMotif alone takes 2:58 minutes.

FLTK

FLTK (pronounced “fulltick”) is a very light toolkit. It’s Arch package (fltk-1.3.0-3-i686.pkg.tar.xz) is just 1.0 MB in size and uncompressed it only takes 4.7 MB of space.

To install it on Gentoo, 7 packages have to be built, which needs 7.2 MB of source code downloaded from the net. 4.0 MB of which is for FLTK source. Building only takes 2:42 mintes and for FLTK alone it’s as little as 1:04 minutes!

Comparison

Toolkit Arch size Gentoo Src size Build time (h:m:s)
FLTK 1.0 / 4.7 7 pkgs 7.2 / 4.0 0:02:42 / 0:01:04
OpenMotif 3.3 / 10.3 4 pkgs 6.7 / 5.9 0:03:29 / 0:02:58
FOX 3.9 / 13.8 6 pkgs 5.0 / 4.3 0:05:59 / 0:04:49
GNUstep* 3.9 / 16.7 92 pkgs 141 / 7 0:43:51 / 0:04:22
GTK+2 6.7 / 54.4 88 pkgs 120 / 12.6 0:40:00 / 0:05:50
GTK+3** 13.3 / 106 89 pkgs 132 / 24.6 0:45:51 / 0:11:27
Qt4 21.0 / 80.4 115 pkgs 386 / 234 3:20:45 / 2:32:14

All sizes in MB.
*) without recompiling GCC for OBJ-C support
**) Including GTK+2

Conclusion

The winner and most light-weight toolkit is easily FLTK. It has the smallest installed size, smallest source and shortest compilation time, both including dependencies and on its own. Only in the number of dependencies it’s beaten by OpenMotif and FOX which are quite light-weight in the other aspects, too. With GNUstep things become a lot more heavy and GTK+ or Qt are of course full-blown toolkits which provide about every feature you’d need but are also very bloated.

We’ll drop FOX and GNUstep from now on, since there’s no working desktop environment using them at the moment (There’s a project to create a FOX DE, but it seems to be inactive since 2005 and Ètoilè (GNUstep) is a mess right now) which makes them irrelevant for our purpose. There was of course some value in adding them to this comparison, though.

What’s next?

Before we go on with comparing TKs and DEs while running some standard applications somewhen next month, the next post will deal with creating a live-cd. This will be an essential task sooner or later and I also need it for “DDD”, one of Eerie’s sub-projects which was not yet revealed (don’t expect too much, though).

An extraordinary TK example!

The last blog post was a little introduction to toolkits in general – now it’s time for a truly special case! While it doesn’t really fit completely with what we’re doing here, it’s close enough to provide a fine example. (That and I like it enough to think that it deserves some more attention outside the narrow scene that’s usually interested in such a thing!)

An unusual distribution

Our example is a graphical distribution with a tiny display server (Nano-X), a simple window manager and FLTK (Fast Light ToolKit) as GUI toolkit. According to its site, FLTK is a cross-platform C++ GUI toolkit for UNIX/Linux, Windows and MacOS X. The uncompressed iso of the distribution is just a little over 60 MB in size. Now take a look at the desktop and guess, which operating system this is based on (and don’t look at the tags of this post if you don’t want to spoil the fun)!

“A graphical distribution using Nano-X and FLTK”

Which OS?

So what do you think from what you see? It looks fairly decent if maybe a bit unoriginal. Is it Windows? No, Windows knows no X11 and thus no Nano-X – and Windows hasn’t fit in ~60 MB for ages! MacOS? To big, too and we were talking about a distribution. So again: No. Linux then? Sounds likely. But a tiny Linux distribution with graphical abilities is nothing special and even less something revolutionary!

Want to see another screenshot? Here’s a FLTK application running:
FlWriter – a simple FLTK word processor

So is it Unix? Some BSD? Or Minix perhaps? No, none of these! A rather exotic thing then? MenuetOS or V2-OS (two operating systems written entirely in assembler!)? Nope. Something completely new? No, you know it, trust me. And it’s not ReactOS or anything like that, either. It’s far easier: This is… DOS.

No, I’m serious! Really, this is Nano-X and FLTK ported to DOS by G. Potthast. The distribution we’re talking about is XFDOS! If you still don’t believe me, just scroll down to the end of this post. There’s a link to the project’s page where you can download it and see for yourself!

It comes with quite some programs, so you can really call it a distribution. There’s a word processor, a spreadsheet application, a painting program, a picture viewer, a pdf viewer and some more.

Alright, it’s still not of much value for daily use. While it even features USB support, there’s no multitasking for example and quite a few other things disqualify XFDOS as a primary OS. But that’s not what it’s meant for, anyway. It’s a great achievement and a neat example of what can actually be done. And it’s surely a huge step ahead of what a DOS GUI usually looks like! You don’t know what I mean? Heh, this gives me a good reason to set up a FreeDOS VM quickly and install OpenGEM again to show you (yes, I really worked with that before – but it’s been years…)!

OpenGEM – a DOS GUI running on FreeDOS

A toolkit in action

This exotic example now gives us the chance to compare a FLTK program running on two entirely different platforms. First take a look at the DOS port of the web browser Dillo:

Dillo – a FLTK-based browser (DOS version!)

And now compare it with Dillo running on a bare-bone Gentoo system running only X11+twm:

Dillo – a FLTK-based browser (on Gentoo)

As you can see, Dillo looks alike on such different platforms as DOS and Linux. Ok, the screenshots show quite some differences… But this is mainly the window bar which is a task of the window manager. Other than that there are a few differences thanks to the fact that XFDOS uses Dillo 3.0 and my Gentoo build is 3.0.2. Also some buttons are grayed out on the later but you can take my word for them to look alike if they both were active.

Even though in the first example the application is running in full screen while in the second it is not, it becomes clear that the application has the same style (buttons, scroll-bar, etc.) on both platforms and this is actually all I wanted to show here: GUI toolkits provide typical graphical elements so that the programmer doesn’t have to care for how they look on other platforms!

Interested in XFDOS?

You can explore the projet’s site here: http://code.google.com/p/nanox-microwindows-nxlib-fltk-for-dos/wiki/XFDOS

What’s next?

In the next post we’ll take a look at the various GUI toolkits available for Linux.

Toolkits – an introduction

The topic of this post is GUI (Graphical User Interface) toolkits. As I wrote before, the EERIE blog is for both Linux veterans and novice users. This entry is meant for the later. If you already have more than a rough idea about what toolkits are, save yourself some time and skip it.

Why to give thought about toolkits?

The importance of the decision which desktop environment to use is pretty obvious. In case of GUI toolkits this is less self-explanatory. However deciding on the right TK is a crucial issue when planing a new distribution. But what are toolkits and what do they do?

While this is not too complicated a subject, it can also be a bit confusing. Especially since there are several commonly used terms which mean the same thing and also some often used in a semi-wrong way that can easily lead to misunderstandings. But let’s shed some light on this topic!

Low-level and high-level programming

With any pc it’s the CPU that can execute a number of instructions. While the set of special instructions grew bigger and bigger (think of MMX, SSE, etc.) over time, it’s generally a big hassle to create more complex programs entirely by doing low-level programming.
Here’s one example in Assembler:

MOV AH,BX

This line translates more or less to “put the value of register AH into register BX“. It’s not hard to imagine that coding like that is complicated, tedious and not very intuitive at all (the programmer has to keep an overview of what is in which register in our example).

For this very reason high-level programming languages exist: it’s far easier to do complex tasks in a more abstract way that is closer to what the human brain works like. It’s not hard at all to tell what the following line does:

PRINT "Hello world!"

Yes, this code fit for the language Basic just prints the well-known message to the screen. Basic is for the main part an “interpreter language”. This means that a set of commands is “translated” into machine code by the interpreter. While Basic provides a fine example here, it’s a little too simple to be fit for serious programming today. There are many high-level languages available, probably the most common being C and C++.

Source code, compilers & libraries

If a programmer wants to create a new program, he or she writes the source code (all the commands which produce the program in the end) for it in his or her prefered language. Afterwards the source code gets compiled (and linked) and the result is an executable program file.

While all high-level languages offer a certain set of commands, it would still be very cumbersome if all programmers had to stick to just these. It absolutely makes sense not to re-invent the wheel each and every time but to simply use some advance routines. Those are often provided by various libraries which are not by themselves programs for the end-user but in fact act like collections of functions which can be called by other programs.

Printing some string on the screen is a typical example. Almost every program needs to have this ability. Every programmer could write his or her own routines or just use an external one to do it. In the later case the programmer also has to decide how to ensure that his program can relay on the external resources. There are two ways to do this!

Static and dynamic linking

It’s possible to append the library to your program executable – this is called static linking. This is obviously the safest way. The drawback however is that this increases the size of the executable. In case of bigger projects which use a lot of libraries this is not a good idea at all. In addition this may be a wast of disk space if you have several programs on your computer which use the same library and each one has it statically linked!

The other possibility is to use dynamic linking. In this case the external resource stays external: the program relays on a library that needs to be installed on your computer. These libraries are called *.so (shared object) on Linux systems and *.dll (dynamic link library) on Windows. To use these is much more efficient in terms of space. However it can be a nuisance if a program depends on a lot of libraries and it can also be a problem if one program relays on an old version of a library and doesn’t work with a newer one while another program needs the latest one…

GUI toolkits

A GUI toolkit, also known as widget toolkit or sometimes widget library is a special kind of library. Their purpose is to provide a set of “widgets” (like a button for example) which other programs can use. This ensures that any e.g. a button drawn by any application using the same TK follows the same style (i.e. looks alike). Many toolkits do not just support one platform but are cross-platform TKs. This means that you could write a program based on sometoolkit which could then run e.g. on Linux, MacOS and Windows without having to care about how the particular system manages drawing graphics on the screen!

However there are several toolkits available – some a bit lighter, some a lot heavier. Of course they work differently and offer a different function volume. But those things will be discussed at a later time.

What’s next?

The next post will be about something really neat that I discovered recently. I won’t spoil it yet, but it’s something that probably nobody would ever expect. I just have to write about it! After that we’re going to examine the toolkits a little closer.