Ubuntu on EEE PC

A few weeks ago I set out to upgrade Ubuntu on my EEE PC 901 from Intrepid to Jaunty. It was an, um, interesting experience, so I'm jotting down these notes for next time. Upgrading from Update Manager was not an option, because my root partition was not big enough to host the upgrade. The 901 has a 4GB SSD that I'm using as root and an 8GB (or 12GB) SSD that I've put /home on. It turns out that 4GB is OK for running a modern operating system, but a little short for updating it.

The usual procedure for upgrading is to use the official ISO images to boot from. As always you need a USB stick, or an external optical drive. I settled for the former, as you can see below.

The good news with Jaunty is that a special netbook edition is available for download. With previous editions you had to start with the desktop edition and do lots of tweaking, to arrive at a satisfactory result. With the netbook edition however things were unbelievably smooth. Everything worked out of the box with my EEE PC. Well, almost everything, but I will get to that in a while.

The first step after downloading the ISO (for the security paranoid at least) is verifying the download:


$ md5sum ubuntu-9.04-netbook-remix-i386.img
8f921e001aebc3e98e8e8e7d29ee1dd4 ubuntu-9.04-netbook-remix-i386.img

Then, we can write the image to the disk. I used Ubuntu ImageWriter (package usb-imagewriter) from another Ubuntu PC:

That went very smooth. Next step was booting the EEE PC with the newly formatted USB disk. Hitting ESC on boot, allows one to change the boot drive sequence. If this is the first time you are replacing the original OS, you probably need to disable Boot Booster from the BIOS first.

The installation process is quite simple. The only important thing was partitioning in my case, since I wanted to preserve my /home partition intact. Last time I installed Ubuntu I went with ext2 filesystems, trying to squeeze as much life from my solid state disks as I could. After doing some more research on the subject, I decided that I'll probably throw away my EEE long before the disks begin to wear out. Either that, or I'll throw an SD card in the expansion slot. Life is full of choices, particularly on the $300 range.

So I selected manual partitioning and chose ext3 for my first SSD. This is a screenshot from my first attempt. No, actually it was my second attempt. I screwed up the first one. Turns out I screwed up this one, too. See if you can spot why.

It may not be that obvious, but swap should not be on the first disk. If you are using swap at all (and I know many suggest that you don't), it would be a better choice to put it on the second disk. With 1GB of RAM, swap should be at least 1GB, which leaves only 3GB for Linux. The default installation needs something north of 2GB, so that leaves less than a gig to install software you use. Unless of course you are planning to play symlink tricks, in which case I should probably offer my condolences. Anyway, I ended up chopping 1GB with gparted from the second disk and redoing the installation again, but fortunately you won't have to.

What you should definitely do however, is put aside 16MB of space in the first disk for enabling Boot Booster in the BIOS again. This is an ASUS feature that persists the BIOS configuration on the disk, shaving a couple of seconds on each boot. It may not seem much, but think about how many times you are going to boot this thing. If you add them up, it starts to matter. Boot Booster needs only 8MB of disk to function, but I found that the installer's partition editor would only allocate one cylinder for 8MB, while we need two. Using 16MB did the right thing.

The regular customization I always do is to put /tmp and /var/tmp on tmpfs, so that many common operations don't touch the disks at all. Put the following lines in fstab to do that:


tmpfs /tmp tmpfs defaults,noexec,nosuid 0 0
tmpfs /var/tmp tmpfs defaults,noexec,nosuid 0 0


After editing /etc/fstab the proper way to remount these file systems is by following these steps:

1. Log out of the Ubuntu desktop in order to minimize the number of open temp files.
2. Press CTRL-ALT-F1 on your keyboard. You should see a login prompt. Login with your usual user/pass.
3. Clear out the files in the existing /tmp and /var/tmp directories.
   sudo rm -rf /tmp/* /var/tmp/*
4. Mount the filesystems using tmpfs.
   sudo mount /tmp
   sudo mount /var/tmp
5. Reboot the EEE PC.
   sudo shutdown -r now

Next, from the boot-as-fast-as-you-can department comes another tweak. In /boot/grub/menu.lst set "timeout 0" in order to skip the kernel selection delay. If I ever need to boot a different kernel, I'll change it back to something larger, thankyouverymuch.

1. Log out of the Ubuntu desktop. (Yes.. I said log out. This will go a long way to ensuring the fewest number of temp files are currently open.)
2. Press CTRL-ALT-F1 on your keyboard. You should see a login prompt. Login with your usual user/pass.
3. Clear out the files in the existing /tmp and /var/tmp directories.
   sudo rm -rf /tmp/* /var/tmp/*
4. Mount the filesystems using tmpfs.
   sudo mount /tmp
   sudo mount /var/tmp
5. Reboot the EEE PC.
   sudo shutdown -r now

Now in order to enable back Boot Booster follow these instructions for configuring the small partition we created earlier. When you reboot make sure to enable the option in the BIOS (it will be hidden when the proper partition isn't found).

Now you are all set. At least if you have no use for WPA-secured WiFi. Because if you do, you'll hit a bug with the included rt2860 driver. The details aren't that interesting, but the available options are two: either use the array.org kernel or patch the driver. The former solution used to be necessary with Intrepid, since lots of things were not working with the default kernel. However after trying out both, I don't see much need for Adam's kernel in Jaunty, unless you are terrified when encountering patch, make and their ilk. Since I'm on first name basis with them, I went with the second option, hoping that a future kernel update will bring along the fixes.

All in all, the process this time around was very easy. Almost easy peasy. My EEE PC with Ubuntu Netbook Remix makes me almost forget that I'm not on my beloved Mac.

Almost.

About Macs

If I hear one more time how Macs are expensive and just for fashion victims, I'll throw up. This urban myth keeps coming up for so long, that it's not really funny any more. These two statements that Macs are a) expensive and b) merely a fashion statement, are so easily debunked if one cares to look objectively for the truth that it's mind-boggling to see them come around so often. From personal experience, the (a) above is a farce. It is most ironic, that I mainly hear this from people who spend quite a lot on computers and tech gadgets in general. Like they are quite happy to shell out hundreds of euros for doubtful upgrades on PC hardware and assorted gizmos, but when contemplating a different platform altogether they become Ebenezer Scrooge.

When I picked a locally-assembled PC with Ubuntu for my desktop at work, I did it for two reasons. First, to save a little extra cash, since the budget was low and second, to keep up with developments on FLOSS desktops in general, since I already had a Mac at home. Both systems would work equally well for what I do at work. Now, the purchase savings from getting the PC, amounted to what I cost the company per day. Having spent about a day fiddling with driver's and software that was not readily available through synaptic (that was in Edgy if memory serves), that advantage was gone. I pretty much knew this was going to happen from the start. However, the second reason still holds. I believe that the inevitable progress in FLOSS desktop systems is eventually going to make proprietary products pointlessly expensive. Ubuntu's polish in each new version attests to this. However we are not there yet.

The "fashion" argument (b) is even worse. It might have had some merit in the nineties, when Apple was floundering and targeted mainly the publishing and multimedia markets, but as anyone can see today things have changed. Are all the Mac-carrying uber-hackers in large conferences fashion victims? Really? Those guys with the pony-tails, beards, glasses, t-shirts, shorts and slippers? Funny how they don't seem to spend much on clothes.

Actually, what people like Yakov Fain are really afraid of, is change. And that's perfectly OK. I'm afraid of change, too. Otherwise I might have moved already. Or changed jobs. Or get divorced. Um, nope, scratch that one. It's just that, occasionally, I do manage to build up the courage to face something foreign and exotic and learn to live with it. And sometimes even learn to like it. For someone like Fain who has spent most of his time in the Windows world, every other world will appear difficult to learn. I have a friend (hi George!) whose first computer was a SPARCstation. When he started using Windows, years later, the experience seemed weird and clunky. It's the same thing, only on the flip side of the coin.

Also, Mark Pilgrim's latest mocking of MySQL installation on Mac OS X while hilarious (which is why I like his blog), is unfair. Sam Ruby's too. Installing or upgrading MySQL on OS X is just a matter of getting the package from the vendor's site and launching it, not compiling from sources. The fact that there might be no package yet for Leopard or that the current package does not function well on it is utterly irrelevant. It will be fixed. Ubuntu is no different. I updated Firefox on my Mac at home the day 2.0.0.9 was shipped, yet one week later my Ubuntu box at work is still at 2.0.0.8. Of course, it will be fixed.

This is what you lose with centralized package repositories, in order to gain consistency and ease of upgrading. I'm no stranger to this kind of thing, having used FreeBSD and Linux as my main desktop for many years now. If you think installing things in Ubuntu is always as easy as launching Synaptic, try to use Skype on amd64. Or Flash and Adobe Reader pre-Gutsy. I'm quite used to watching compiler output scroll for hours so all of it was a walk in the park for me, but I can imagine how it might have been frustrating for someone less experienced. Ubuntu's (and FreeBSD's, Fedora's, etc.) advantage over the Mac is when installing something not packaged specifically for OS X by the vendor, like mutt or nmap. That is where the value of a community-maintained repository shines. Of course you can use MacPorts / Fink / pkgsrc / whatever, but they are not integrated into the system, so you merely moved the goal post a little further.

As a parting thought, I have a confession to make: I'd love to work with this guy. Interacting with human beings requires a set of skills that not many people in the technology world can brag about. Understanding how humans work and what makes them tickle is fundamentally different than being an expert with machines and software. Michael Lopp is an engineering manager at Apple. It figures, I guess.

On FreeBSD and Debian package management

About a year ago I was contemplating writing a graphical package management tool for FreeBSD. I had been using bpm on and off for a while and while it was close enough to what I needed, the effort to extend it wore me off pretty soon. After all, how much GUI programming in plain C can a decent man endure?

Anyway, after picking a more workable solution on the programming language front, I had sketched up a GUI prototype and was considering the available options for the actual package updating code. My main interest was in binary packages and there were a few available command-line tools and libraries. None of the options seemed to work well enough though. Besides various communication issues among the two tiers of my application, what really drove me off this pet project was the source-based nature of the ports framework. That and the tiny issue of fatherhood, to be precise. I've tried to explain it once, but what I really wanted was something like the Debian system, which I'd argue is a better fit for regular users.

Michel Talon, long time FreeBSD user and developer, appears to have researched the issue more thoroughly while developing pkgupgrade, a tool that would have been another great option for my own project, had it been available last year. Pkgupgrade is written in Python, which would make it even yummier in my opinion. It's not Java, but it's close enough for my taste. Michel's comparison of the FreeBSD package system and the Debian one, comes to the conclusion that binary package management systems are inherently better for casual users than source-based ones:

"But the main factor ensuring reproducibility and reliability of the apt system is working with binary packages. You can be sure at least of the existence of a binary package, and probably that it works, due to the severe testing in the Debian system. There is no guarantee in a source based system. Hence no package management system can be reliable, however sophisticated it is."

The above excerpt may sound a bit harsh, but if you read the whole paper you'll see that the author's arguments are pretty balanced. Now that I've had the chance to use Debian's apt system for a few months, I can say that I wholeheartedly agree with Michel. This is pretty much what I had in mind for FreeBSD last year and I still think this is the direction the project should follow.

The upside for FreeBSD is that I no longer have the time to work on my old Java-based graphical package management tool. Because, let's be honest here, a system tool in Java? How many rotten tomatoes would be coming my way?