Penguin Spirit

Some time ago, I read about a KDE 3.x fork named “Trinity”. Some IT magazines and news sites called it “zombified” and said it has no future. I strongly disagree with those claims.

First, Trinity is a very active project coordinated by Timothy Pearson, the KDE 3.x coordinator of previous Kubuntu releases. This guy is a real expert; he’s the boss behind a well-polished KDE 3.x distribution. He knows the internals of KDE 3.x. He has the skills to to work with large code repositories, large package repositories and definitely has what it takes to make Trinity a great open source project. So far he did a very good job; Trinity 3.5.12 is indeed a great desktop environment that is, undoubtly, a significant improvement over KDE 3.5.10. Trinity moves on and improves over the the wonderful work done by the KDE e.V.

Also, KDE 3.5.10 is dead; it simply won’t compile with recent distributions and toolchains. It heavily relies on legacy components that no longer ship with today’s distributions, as lots of progress in the fields of hardware abstraction and graphics has been made since the early days of the KDE 3.x backend. That’s not the case with Trinity; it will build just fine with recent distributions. It has its own wrapper for the legacy Qt3, which Perason intends to use, eventually, to translate Qt4 calls into deprecated Qt3 calls in order to bridge between Trinity and the more modern world of KDE 4.x. That’s a great ensurance plan that prevents Trinity from lagging behind in the long-term, as other transitions from legacy technologies (like HAL) to more modern ones (such as libudev and KMS) can be performed in a similar fashion.

Additionally, many distributions show interest in Trinity; Slackware, Ubuntu and Debian are only the first distributions that have their own Trinity repositories. Package builders of RPM-based distributions such as Mandriva already attempt to package Trinity. With the interest of major desktop distributions comes fast-paced upstream development, integration and support. Once Trinity becomes more popular, it’s just a matter of time before it expands and desktop distributions behind it appear all over and flourish.

To conclude, I truly believe Trinity is a great project that has a long future full of great, exciting development ahead of it. I wish it good luck and hope it’s here to stay for years to come.

 

Black Gold

As a regular follower of Motho ke motho ka botho, I feel compelled to write about my own experience when switching to a text-based environment.

It’s not so easy to make the switch. It’s hard to adjust to a new kind of user interface, but once you go black, you never go back: once you feel comfortable with console applications, you become more efficient and no longer need friendly, graphical applications; Your ten fingers are faster than one hand.

The easiest way to start making the switch is by replacing one graphical application that you find heavy with a text-based alternative, that’s something both me and K. Mandla agree about. The first console application I ever tried was WeeChat – I remember I first heard about it in the Puppy Linux IRC channel when a group of veteran users agreed it’s the best IRC client there is. Immediately, I got curious and decided to give it a go – I downloaded a PET package.

I found WeeChat to be too complex for me, as the first console application of an IRC newbie. I found it hard to remember all the different configuration options and the peculiar ways of doing things, like “/nick” instead of clicking my nickname with the mouse pointer.

However, I got to like it and it even inspired me to create a Puppy SFS extension with a bunch of console applications, which included WeeChat, ELinks, Vifm, Midnight Commander, MOC, Transmission, GNU Screen and other goodies. That was nothing but an experiment: I wanted to know how useful these applications are as when used as a working environment. I installed my extension and booted Puppy with the famous “pfix=nox”.

At first, I kept taking down GNU Screen sessions with the applications running inside them. However, it became my primary working environment, once I got used to the key bindings. I was fascinated by the low usage of resources, the responsiveness of applications and the efficiency of such environment: I could write and read interesting articles for hours. The black background was indeed one of the things I was most pleased about.

As time passed by, I became more and more familiar with the internals of a Linux distribution. I read guides that explain how to construct a simple live distribution that just boots to a shell prompt and many resources about embedded Linux systems. When I felt ready, I assembled my first embedded-like system – an x86 distribution that behaves like an embedded system. Then, I added SSH capability and other things. I also learned how to compile a kernel and became familiar with Busybox. This inspired me to create my own distribution, an entire text-based operating system.

However, at the time, I had no knowledge about constructing an entire distribution from scratch, so I read Linux From Scratch and built several systems based on it. As I became more and more familiar with it, I dropped some packages and found ways to customize it to suit my needs: I replaced some packages with Busybox and changed the order in which packages are built.

The first builds of Calf GNU/Linux were stupid and ran live. I could run all the console applications I used, but then I realized how stupid I was. Some packages had extra dependencies I missed and others were nothing but bloat. For example, Transmission requires some extra dependencies to compile properly and ELinks wanted Expat.

My experience with console applications made me a software minimalist and changed my perspective about software in general and Linux distributions in particular. For instance, a distribution that uses many graphical Python applications is not efficient, while applications like DeaDBeeF are real gems.

Real life events kept me away from working on Calf GNU/Linux, but sometimes I found the time to work on it. Gradually, it became smarter and now it’s my primary working environment: I use it for writing, programming and music. I browser the internet, chat in IRC and download stuff in a console-based environment.

It just makes me more efficient, makes my netbook’s battery last longer and doesn’t kill my eyes. The computer’s fan is completely silent and sound quality is superb. Also, the text-based interface does wonders with my 1024×600 display – no wasted pixels in the framebuffer console.

Also, applications such as dvtm can further enhance the usefulness of a text-based operating system on small screens. By using tiling window managers (well, dvtm can be considered to be a window manager) you save the extra pixels used for window borders and panels, because you no longer need them.

Moreover, some console applications form something better when used together. For instance, with both GNU Screen and dvtm inside each window, you get workspaces and windows with session detaching capability. If you also use MOC, you get an invisible, superb music player that plays music in the background while you do some serious work.

Anyway, this is just my subjective view of the subject and console applications are a matter of taste. Some find them precious, while others are scared of them. I just happen to like them and hope they’re here to stay.

A Date with Squashfs and Aufs

Yesterday I uploaded a testing build of Calf GNU/Linux with the version number “001″ (0.0.1). It uses Squashfs (with linking, like Tiny Core) and Aufs (for a “save file”, like Puppy).

Since yesterday, I’m recompiling the whole thing. I’m trying to find the right packages and right order to build them. For instance, I can compile Coreutils without GMP as a dependency – Coreutils goes first and GMP joins the distro only when it’s really needed (GCC needs it).

I was wondering … what is the most efficient way to get a writeable /, a persistent home directory and a package management system that allows packages to be installed on-the-fly and removed cleanly? The answer is already included in Calf 001.

Until 001, Calf used a tmpfs moutned on / and an image file mounted on the home directory. However, this approach had some limitations. First, it wasn’t very elegant – the home directory had “lost+found”. Second, packages could not contain any files that go to the home directory, for obvious reasons – they’re linked and not copied, so the save file doesn’t contain them. If you want to create a quick backup of your home directory, you’re in trouble. The init scripts were more complicated and did not allow the flexibility of Puppy.

However, 001 has a new init script – the whole thing in one script, it’s more efficient. It uses a file named “distrorc”, which resides in /etc. That file contains 4 variables: distroName, distroFilePrefix, distroReleaseDate and distroArch.

The first variable, distroName, is the user-friendly distribution name. The second one is the prefix for some of its files (for example, if Puppy 5.1.1 uses pup-511.sfs, this variable is the equivalent of the “pup” prefix). The third variable is the release date and the fourth one is the architecture, i486 in this case.

The init process starts when /init creates a tmpfs with the size tag of 80% of the available RAM. Then, it copies everything there and calls the real init, which runs /etc/init.d/rcS. The purpose of /init is the creation of the tmpfs file system, which is writeable and allows the “live” nature of the distro.

Then, the init script scans all partitions (it detects them through /sys) for a file named $distroFilePrefix-$distroVersion.sfs, both on the partition root and sub-directories. If it finds it, the Squashfs image is linked. Then, it does the same with all files that end with “.sfs” in a directory named $distroFilePrefix-extensions that is placed next to the Squashfs file,  if there is such.

After the extension linking, the init script checks whether a file named ${distroFilePrefix}save.img exists next to the Squashfs file; that’s the save file. It is mounted and used as a layer above the /root from the Squashfs file system found earlier.

At the moment the initramfs is really big, it’s 16 MB, because it has all kernel modules. Now I’m almost done rebuilding the whole Calf GNU/Linux and this time things that are highly likely to be needed on most machines are part of the kernel. For instance, USB support is something all computers have – if it’s part of the kernel image, the USB support code doesn’t have to be loaded as a kernel module, that saves precious boot time.

Additionally, 002 will have both Aufs and Squashfs compiled in and not as modules, to speed it up even further. The Squashfs loading will be faster and boot times should be shorter.

To conclude, Aufs and Squashfs are two interesting pieces of software that are vital for most mini-distributions and live distributions. Let’s hope Calf GNU/Linux will eventually make a good use of both.

Kernel Hacking Journal: Chapter 2

After a big success with the former LTS kernel, 2.6.27.x, I decided to make a tweaked 2.6.32.x kernel for Puppy Squeeze, the unofficial, community-built Puppy that has a Debian heart.

My first idea was patching the kernel (at the moment, I work on 2.6.32.23) to change its version number to 2.6.32. This way, the kernel is still compatible with all stuff for 2.6.32 (after all, the only difference between different 2.6.32.x releases is extra fixes backported from later kernels) but still allows modules compiled for an earlier 2.6.32.x to be used with it. This way, Puppy Squeeze 009 can use 2.6.32.23 and later releases won’t break compatibility with its drivers, as their more stable 2.6.32.x kernels use the same paths.

My second idea was patching the kernel with BFS, to enhance performance and benefit low-power machines or older, single-core processors. I also added HyperThreading support, which is omitted from all official Puppy kernels for some reason; I think it’s a mistake done by Barry which persisted until 5.1.1 because of the use of oldconfig. In other words, each new Puppy kernel is based on the decisions and choice of drivers done with its predecessor, so the choice of omitting HyperThreading survived. That’s a kill for netbooks, since most of them come with a single-core Atom processor that supports it.

My third idea was backporting stuff from the latest stable kernel, that’s something I’m still working on. At first, I tried to backport all laptop extras but the kernel failed to compile, probably due to the big changes in the WMI code. I also tried to backport the latest i915 driver but the compilation failed, I guess it’s DRM and KMS now.

To conclude, I find this really fun and challenging. I’d like to take a step back and be the Puppy Squeeze kernel guy at least for the next release, as I’m busy these days and I’m almost empty of new ideas. Need someone with the passion and the right attitude to lead this thing on.

I’m off to compile another 2.6.32.23 masked as 2.6.32, see you around.

Adventures with Seamonkey

I think it’s time to face it: Seamonkey is the ideal browser for Puppy Linux and pretty much any small distro. It’s stable as Firefox but feels slightly faster and comes with pretty much anything needed for typical internet usage.

However, Seamonkey’s biggest weaknesses are the slower development and the compatibility; it uses Gecko and XUL just like Firefox and it’s compatible with most Firefox 3.x addons. Another weak spot of Seamonkey is its low popularity.

Despite of these, Seamonkey runs exceptionally well with Puppy Squeeze, the revived dpup, a community-built Puppy built from Debian Squeeze binaries. It already has its own artwork and most applications, but the Debian package quality already shows its benefits: Seamonkey is faster than any other browser and its XUL-rendered interface isn’t quirky as in other distros or Mozilla applications.

At the moment Puppy Squeeze has Seamonkey 2.0.7 but three people reported the mail client doesn’t work and two reported the browser does not show the traditional Puppy welcome page.

I have a theory that Seamonkey needs to be packaged with a default profile and that’s why it doesn’t open the welcome page; it opens the 2.0.7 introduction and “what’s new” page instead, as it does on any fresh Seamonkey installation or upgrade.

Regarding the mail client, Seamonkey needs to be recompiled. At the moment I’m trying to get Puppy Squeeze installed on my netbook so I can work on it on-the-go, I hate being tied to one desktop computer.

I also want to package the statically-compiled binary distributions of both Firefox and Seamonkey to see whether they provide any performance boost. Even if they do, the Seamonkey package won’t be ideal, because the HTML editor is not really needed on Puppy; Geany can do HTML too. The extra size the static linking can be dangerous and every bit counts.

Let’s hope we get Seamonkey to work well on Puppy Squeeze, as a full browser is one of the best features of Puppy Squeeze, in my eyes. Most users will be more than happy with a snappy browser that is fully compatible with and similar to Firefox.