However comfortable Ubuntu might be, my inner geek wanted to get his hands a little bit dirtier with configurations, and obtain a more responsive OS in return. And that’s where Arch Linux fits in. Arch Linux is regarded as one of the fastest Linux distros, at least among the ones based on binary packages, not source code. Is this fame deserved? Well, in my short experience, it seem to be.

First off, let us clarify what one means with a “faster” Linux distro. There are as I see it, broadly speaking, three things that can be faster or slower in the users’ interaction with a computer. The first one, and very often cited one, is the boot (and shutdown) time. Any period of time between a user deciding to use the computer and being able to do so is wasted time (from the user’s point of view). Many computers stay on for long periods of time, but for a home user, short booting times are a must. A second speed-related item would be the startup time of applications. Booting would be a sub-section of this, if we consider the OS/kernel as an “app”, but I refer here to user apps such as an e-mail client or text editor. Granted, most start within seconds at most, many below one second or apparently “instantly”, but some others are renowned for their slugginess (OpenOffice.org, Firefox and Amarok come to mind). Even the not-very-slow apps that take a few seconds can become irritating if used with some frequency. The third speed-related item would be the execution of long-running CPU-intensive software, such as audio/video coding or scientific computation.

Of the three issues mentioned, it should be made clear that the third one (execution of CPU-intensive tasks) is seldom affected at all by the “speed” of the OS. Or it shouldn’t be. Of course having the latest versions of the libraries used by the CPU-intensive software should make a difference, but I doubt that encoding a video with MEncoder is any faster in Gentoo than Ubuntu (for the same version of mencoder and libraries). However, the first two (booting and start up of apps) are different from OS to OS.

Booting

I did some timings in Ubuntu and Arch, both in the same (dual boot) machine. I measured the time from GRUB to GDM, and then the time from GDM to a working desktop environment (GNOME in both). The exact data might not be that meaningful, as some details could be different from one installation to the other (different choice of firewall, or (minimally) different autostarted apps in the DE). But the big numbers are significant: where Ubuntu takes slightly below 1 minute to GDM, and around half a minute to GNOME, Arch takes below 20 seconds and 10 seconds, respectively.

App start up

Of the three applications mentioned, OpenOffice.org and Firefox start faster in Arch than in Ubuntu. I wrote down the numbers, but don’t have them now. Amarok, on the other hand, took equally long to start (some infamous 35 seconds) in both OSs. It is worth mentioning that all of them start up faster the second and successive times, and that the Ubuntu/Arch differences between second starts is correspondingly smaller (because both are fast). Still Arch is a bit faster (except for Amarok).

ABS, or custom compilation

But the benefits of Arch don’t end in a faster boot, or a more responsive desktop (which it has). Arch Linux makes it really easy to compile and install any custom package the user wants, and I decided to take advantage of it. With Debian/Ubuntu, you can download the source code of a package quite easily, but the compilation is more or less left to you, and the installation is different from that of a “official” package. With Arch, generating a package from the source is quite easy, and then installing it with Pacman is trivial. For more info, refer to the Arch wiki entry for ABS.

I first compiled MEncoder (inside the mplayer package), and found out that the compiled version made no difference with respect to the stock binary package. I should have known that, because I say so in this very post, don’t I? However, one always thinks that he can compile a package “better”, so I tried it (and failed to get any improvement).

On the other hand, when I recompiled Amarok, I did get a huge boost in speed. A simple custom compilation produced an Amarok that took only 15 seconds to start up, less than half of the vanilla binary distributed with Arch (I measured the 15 seconds even after rebooting, which rules out any “second time is faster” effect).

Is it hard to use?

Leaving the speed issue aside, one of the possible drawbacks of a geekier Linux distro is that it could be harder to use. Arch is, indeed, but not much. A seasoned Linux user should hardly find any difficulty to install and configure Arch. It is certainly not for beginners, but it is not super-hard either.

One of the few gripes I have with it regards the installation of a graphical environment. As it turns out, installing a DE such as GNOME does not trigger the installation of any X Window System, such as X.org Server, as dependencies are set only for really vital things. Well, that’s not too bad, Arch is not assuming I want something until I tell it I do. Fine. Then, when I do install Xorg, the tools for configuring it are a bit lacking. I am so spoiled by the automagic configurations in Ubuntu, where you are presented a full-fledged desktop with almost no decision on your side, that I miss a magic script that will make X “just work”. Anyway, I can live with that. But some thing that made me feel like giving up was that after following all the instruction in the really nice Arch Wiki, I was unable to start X (it would start as a black screen, then freeze, and I could only get out by rebooting the computer). The problem was that I have a Nvidia graphics card, and I needed the (proprietary) drivers. OK, of course I need them, but the default vesa driver should work as well!! In Ubuntu one can get a lower resolution, non-3D effect, desktop with the default vesa driver. Then the proprietary Nvidia drivers allow for more eye-candy and fanciness. But not in Arch. When I decided to skip the test with vesa, and download the proprietary drivers, the X server started without any problem.

Conclusions

I am quite happy with Arch so far. Yes, one has to work around some rough edges, but it is a nice experience as well, because one learns more than with other too user-friendly distros. I think Arch Linux is a very nice distro that is worth using, and I recommend it to any Linux user willing to learn and “get hands dirty”.

The installer needs to remove operating system files from the install target, but was unable to do so. The install cannot continue

I was installing Ubuntu on top of a previous eeebuntu install, smashing the / partition, while reusing the /home. After minimal googling, I found this bug report at Launchpad, with the same problem (and one year old).

As it turns out, the problem was not with the root partition, as I assumed from the error message, but with the home one. Apparently, Ubuntu didn’t like the idea that my home partition was JFS (maybe it couldn’t mount it, because jfs_utils are not loaded by default). The solution: install the OS ignoring (not using) the home partition, and mount it afterwards.

Shame on you, Ubuntu, this solution is lame!

I recently upgraded to Ubuntu Jaunty Jackalope, and have experienced a much slower response of my desktop since. The problem seems to be with Intel GMA chips, as my computer has. The reason for the poor performance is that Canonical Ltd. decided not to include the UXA acceleration in Jaunty, for stability reasons (read more at Phoronix).

The issue is discussed at the Ubuntu wiki, along with some solutions. For me, the fix involved just making X.org use UXA, by including the following in the xorg.conf file, as they recommend in the wiki:

Section "Device"
        Identifier    "Configured Video Device"
        # ...
        Option        "AccelMethod" "uxa"
EndSection

Ever since using Debian and Ubuntu, I have installed the OS just once per computer. All software upgrades, including full releases, have been done through upgrades, not re-installations. This means that I have never actually had the need to download any ISO besides the first one used when I bought the computer.

This is fine, but I always felt the compulsion to share my bandwidth with fellow Linux users, and relieve some load from the Canonical Ltd. servers. So for every new Ubuntu release, I have downloaded one or more (amd64, i386, desktop, alternate…) Ubuntu CD ISOs via BitTorrent, and kept them uploading for some time. However, the full BT download of the ISO is a waste of bandwidth, and unless my later upload share is greater than 1.0, I will have been overloading the servers, not relieving them.

Now, with Jaunty Jackalope, I have a way to fix this. I could have done similarly with previous releases, but I didn’t. Here’s the deal: download the ISO and share it with BitTorrent, but don’t upgrade from the Internet as well. Upgrade from the ISO I just downloaded! In the past I would be reluctant to do this, among other things because I don’t want to waste a physical CD for that. However, the Ubuntu upgrade instructions say how to mount the ISO (yes, mounting ISOs is not new. I’ve done it in the past), then upgrade from the mounted image. Once the upgrade is done, I can keep seeding the ISO with BitTorrent.

With this procedure I can use bandwidth more efficiently (I download the required software just once), and I can still share the ISO with other people. Moreover, there is another plus: the ISO is just 699 MB, whereas the upgrade manager in Ubuntu tells me that for the upgrade I will need to download more than 1 GB! The difference is due to the ISO being somehow compressed, I think. I will report on the size of the file system mounted from the ISO (which should be much more than 1 GB).

Update: Well, actually the internet upgrade involves more packages. If you upgrade from the CD, you are still required to download 800 more MB to complete the upgrade, so no magic there.

However hibernating to disk is a whole different business. I never managed it to work, and that was an itch I wanted to scratch. Finally I managed, with the following recipe.

HowTo

First, make sure that you have enough swap space available in disk. In Linux you generally create a swap partition when installing the OS. The old adage states that one should make the swap partition twice as big as the RAM memory of the computer. With modern computers this is both unnecessary (because the big RAM makes sure you’ll never run out of it, and if you do, you are screwed anyway) and wasteful (if you have a 4GB RAM, it means that you dump 8GB of disk space). However, if you intend to hibernate your computer, all the information in the RAM memory has to be copied to the hard disk, so you sure need at least as much swap as RAM (but not twice).

Second, you need to use the correct tool. I use Xfce as desktop environment under Ubuntu, and the Exit menu presents me with six options: “Switch user”, “Log out”, “Restart”, “Shut down”, “Suspend” and “Hibernate”. I think that the latter two make use of the tools in the acpi-support package. The suspend action seems to work OK, but the hibernate one doesn’t (for me). It runs the command /etc/acpi/hibernate.sh, and it gives me problems. Thankfully I found some utilities that work reliably, namely pm-utils.

The pm-suspend command seems to work as correctly as the “Suspend” button in the Exit menu of Xfce. The pm-hibernate, on the other hand, works perfectly, unlike the “Hibernate” button. The drawback is that only root can run it. My solution is to put a launcher button in the Xfce task bar, that will run “gksudo pm-hibernate”. This way I am asked for my password and, if sudo is correctly set up, pm-hibernate will run.

More info

Sometimes it is very interesting to run some commands at suspension/hibernation moment, or at resuming/thawing. One such command is hdparm, with which you can fix the long known load/unload cycle problem (you can google about it). Another one is one to fix a problem that apparently appears on MacBooks: the touchpad is lost when the computer wakes up back. The keyboard works, and USB mice work, but the touchpad doesn’t. This problem can be fixed by reloading the appletouch kernel module:

You can fix both issues above by creating a file named, e.g., 99-macbook_fix, in /etc/pm/sleep.d/, and making it executable. Then write in it the following:

Pick a mirror and download. Or better yet, do it through BitTorrent.

% cd /usr/share/inkscape/extensions
% curl -s 'http://launchpadlibrarian.net/12978623/eqtexsvg.py.patch' | sudo patch -p0

The bug affects (and the patch fixes) Inkscape 0.46 on Ubuntu Hardy Heron and Debian Lenny (that I know of).

I have followed the instructions in the Ubuntu community site, as with the procedures detailed in the previous post.

Basically, it all boils down to:

Fetch the Apple drivers for the camera

As root (if, unlike me, you like sudo, then run the following as user, but prepended with sudo), mount the Mac OSX partition (you didn’t delete it, right?) and copy the relevant file somewhere else (the cp command should be all in one line):

# cd
# mkdir /mnt/macosx
# mount /dev/sda2 /mnt/macosx
# cp /mnt/macosx/System/Library/Extensions/
     IOUSBFamily.kext/Contents/PlugIns/AppleUSBVideoSupport.kext/
     Contents/MacOS/AppleUSBVideoSupport .
# umount /mnt/macosx

You might have noticed that the Mac OSX partition is not sda1, but sda2. Don’t ask me. It turns out like this after following my own installation instructions. Apple must have decided to install the OS in the second partition for some reason.

Install the required packages

We need a package called isight-firmware-tools. Unfortunately it is not present in the Hardy repos at the moment (it was in the Gutsy ones, I think). You can add a Launchpad repo, editing /etc/apt/sources.list to add:

deb http://ppa.launchpad.net/mactel-support/ubuntu hardy main
deb-src http://ppa.launchpad.net/mactel-support/ubuntu hardy main

Then, as root:

# aptitude update
# aptitude install isight-firmware-tools

You will be prompted for a path to the driver you copied before. You can press Enter without paying much attention, then execute (assuming you copied the driver to your root home):

# cd
# ift-extract -a ./AppleUSBVideoSupport

To activate the driver, restart HAL:

# /etc/init.d/hal restart

Test it with Ekiga

As explained in the Ubuntu community site, you can run Ekiga as user (after installing the ekiga package). Choose V4L2 as video plugin, and Built-in iSight should appear among the Input device list. If it does, the process worked.

You can see some pictures of it at my MacBook gallery.

If you, like me, are used to PCs, then there are a few things to note:

• It has a different layout in the keyboard. Most prominently, some keys are missing: Del, PgUp, PgDn, Home, End. Some others (Win key, AltGr) have substitutes that can be mapped. Also the equivalent to AltGr and right Ctrl are kind of swapped: the key closest to the SpaceBar is right “cmd” (could be right Ctrl), and the farthest one is left “alt” (could be AltGr)
• The touchpad has a single button, and tapping on it won’t click. There is no zone on it to use as vertical scroll, either. Luckily the latter can be fixed via software, so that in Ubuntu the touchpad does behave correctly: you can tap-click, and you can scroll with a smooth movement of a finger. The single-button issue is not present in USB mice: they work “normally”.

I would like to outline here the process of installing Ubuntu (Hardy Heron) in this machine. For that, I recommend reading (as I did), the following links:

• How to install Ubuntu on a MacBook
• Specifics for Santa Rosa MacBooks (mine is a SR).
• As usual, google the net for “Linux on a MacBook”, and you’ll find a good list of sites

Repartition of the hard disk

My Mac came with 120 GB (109 real) of HD, all of it devoted to OS X. Unfortunately, the Ubuntu installer can not cope with resizing of HFS+ partitions. Fortunately, OS X itself can. You can make use of Boot Camp as follows: go to Go->Utilities->Boot Camp Assistant. There you can (should) reduce the existing HFS+ partition to the bare minimum (in my machine it was 22GB, because OSX already uses 17GB, and it won’t accept less than 5GB of free disk). Leave the rest unassigned, and quit.

Installation of multi-boot system

The first hurdle in our Linux installation is that the Mac machines do not have a “normal” BIOS. The BIOS is important for Linux/Windows installations, so this is a drawback. Macs come with a thingie called Extensible Firmware Interface (EFI), instead. However, there is a nice little tool called rEFIt that can help us with it.

To install rEFIt, you can follow the instructions at its Sourceforge site. I followed the Automatic Installation with the Installer Package instructions. Basically I downloaded the Mac disk image from the download page, opened in the Mac OSX file browser, double-clicked it to open it, then double-clicked on the rEFIt.mpkg file inside, and followed the instructions.

This will make the rEFIt menu appear in the next reboot, but only if you hold some key while booting (I think it’s “C”). If you want the menu to always appear, do the following in a terminal, inside Mac OSX:

% cd /efi/refit
% ./enable-always.sh

Installation of Linux OS

After doing the above, you should reboot with an Ubuntu installation CD inserted. If the EFI installation was correct, you will be presented with the rEFIt menu, in which you will have two big icons (OSX and the Linux CD), and five small ones below (“Start EFI Shell”, “Start Partitioning Tool”, “About rEFIt”, “Shut down computer” and “Restart computer”).

Use the left-rigth arrow keys to select the Ubuntu CD, and press Enter. At that moment, or after installing Ubuntu (I don’t recall), the computer could complain saying: “No bootable device — insert boot disk and press any key”. If so, reboot and, in the aforementioned rEFIt menu, choose the second small icon, “Start Partitioning Tool”. This tool will prompt you to update the MBR. Accept, and let it do its magic.

When booting with the CD, you will have the option to make an absolutely normal Ubuntu installation. The Ubuntu MacBook page says that Boot Camp will complain if you make more than two partitions in total. It will, but for me this is ridiculous, since OSX is already eating up one. There’s no way I will install any Linux in a single partition (withouth even swap!). If you do not care about opening Boot Camp ever again (I don’t), do a totally normal install. I created two 8.5GB partitions for / (one for Ubuntu, another one unused for the future), a 750MB swap partition, and the rest (73GB) as /home (potentially shared among the two Linux I could install).

After the installation, reboot and you will find the aforementioned rEFIt menu. Choosing the penguin icon on the right side will take you to the GRUB screen you probably are accustomed to. What this means is that you have to go through two boot menus when booting, but that’s a minor issue, I think. The first menu is an EFI menu, in which you choose OSX or GRUB. The second one is the GRUB menu that lets you choose among different installed kernels.

And I think that’s it…

I will keep on writing when I have time, at least about how to make WiFi work, and also how to configure Compiz Fusion. Yes, the X3100 graphics chip that the MacBooks carry is blacklisted, as not working with CF. But, believe me, it does work!