Thursday, June 26, 2008

XO Post Upgrade

When you run olpc-update to upgrade the software on your XO laptop, you lose some of your customizations (which I just did). Here's what I've customized so I have a quick reference to get it all back next time.

Set the timezone:

su
sugar-control-panel -s timezone 'America/Los_Angeles'

Set a root password:

su -l
passwd

This allows me to ssh to the XO (as root, I know, I know) which at least allows me to use my nice desktop keyboard and monitor to do most of the rest. I tried setting the user account password instead once, but it seems like Sugar wouldn't start after that. This page seems to indicate that you should be able to do that (now?) though. I'll have to try it again.

Set up quake terminal (scroll down the page a bit). I keep a copy of the quake_terminal.txt file in my home directory on the laptop. To set it up I just do this:

su -l
cp /home/olpc/quake_terminal.py /usr/share/sugar/shell/view/quake.py

Then apply this patch to /usr/share/sugar/shell/view/keyhandler.py:

--- keyhandler.py.beforequaketerm 2008-06-25 07:26:44.000000000 -0700
+++ keyhandler.py 2008-06-25 07:26:04.000000000 -0700
@@ -22,6 +22,8 @@ import subprocess
 import dbus
 import gtk
 
+import quake
+
 from hardware import hardwaremanager
 from model.shellmodel import ShellModel
 from sugar._sugarext import KeyGrabber
@@ -32,6 +34,7 @@ _BRIGHTNESS_MAX = 15
 _VOLUME_MAX = 100
 
 _actions_table = {
+    'Down'     : 'quake_term',
     'F1'             : 'zoom_mesh',
     'F2'             : 'zoom_friends',
     'F3'             : 'zoom_home',
@@ -87,6 +90,10 @@ class KeyHandler(object):
         for key in _actions_table.keys():
             self._key_grabber.grab(key)            
 
+    def handle_quake_term(self):
+        quake_term = quake.get_quake()
+        quake_term.toggle_visible()
+
     def _change_volume(self, step=None, value=None):
         hw_manager = hardwaremanager.get_manager()

Except diff and patch aren't installed on the XO by default. You can yum install patch as root to get patch. I haven't tracked down which rpm supplies diff yet, actually.

You probably don't have to restore mplayer if you install it according to these instructions.

A nice open source eBook reader is FBReader. Here's how to install an olpc version of FBReader:

wget http://imagic.weizmann.ac.il/~dov/olpc/fbreader-0.8.15-1.dov.i386.rpm
su
rpm -Uvh fbreader-0.8.15-1.dov.i386.rpm

I have to have my emacs on my XO:

su
yum install emacs

I've decided that Firefox is my favorite browser on the XO. To install, edit /etc/yum.repos.d/olpc-koji-update1.repo and remove firefox from the exclude= list. Then

yum install firefox

Or, you could try firefox 3. It seems like it'd be really nice since it uses less memory. I just installed it for the first time on the XO and I'll report back how it works. To install it download the Linux version from Mozilla and uncompress it in your /home/olpc directory like so:

tar -jxvf firefox-3.0.tar.bz2

Then run it from the command-line like this:

firefox/firefox &

It will take a loooong time to start. Accept the licence agreement and wait a bit more. Then you have some huge icons and fonts staring back at you. Type about:config in the address bar and hit tab a few times and then enter to get past the warning. Adjust the layout.css.dpi setting to be 134. I got that from this forum post. So far it seems pretty good. With Firefox 2 gmail was completely unusable except in basic HTML mode and with Firefox 3 it's almost doable when it's in its default javascripty mode.

And that's really all I've had to customize on this thing. Maybe someday I'll try Ubuntu or Debian on it, but so far the modified fedora 7 and Sugar work fine. Linux is Linux.

UPDATE: I forgot two things: flash and java (just follow the instructions on the wiki). Oh, and Firefox 3 is still working great.

MORE UPDATES: OK, with firefox 3, you can't just follow the instructions on the wiki for flash and java. You also have to do this (assuming you simply untarred firefox-3.0.tar.bz2 in your home directory like I directed above):

cd /home/olpc/firefox/plugins
ln -s /usr/lib/flash-plugin/libflashplayer.so
ln -s /usr/java/jre1.5.0_13/plugin/i386/ns7/libjavaplugin_oji.so

The version numbers might change for java, but otherwise, that's how you get the plugins to be found by firefox 3.

Upgrade XO to Build 703

I upgraded my XO to Build 703 this week. It was a little difficult at first, but I like it now. It's so cool that it now suspends when you close the lid. This is the first Linux laptop that I've had that does that so smoothly.

Disk space is at a premium on this little machine. I actually couldn't get Sugar to start after the upgrade until I did a ctrl-alt-f1 over to a virtual console and removed some files from my home directory. One utility that is nice for adding and, maybe more importantly, removing Activities is xo-get.py. Once installed you can just ./xo-get.py remove ActivityName to free up more disk space. Nice.

Removing activities wasn't nearly enough though. I was still really full on disk space and after poking around with du I found the /versions directory that seems to contain the complete set of files for the previous version of the OLPC software (after an update you can boot the previous version by holding down tho 'o' gamepad key). That takes up a lot of disk space. I searched and searched to see if there was a recommended safe way to get rid of stuff in /versions, and all I found was a mailing list post saying that you *should* be able to delete stuff in the versions directory. I didn't feel safe deleting stuff that seemed to be the currently running OS (I checked /versions/run/BIGLONGHASHEDVALUE/etc/issue to be sure), but I deleted the old version and everything seems to be running OK still. A little faster even.

We are going on a long road trip and the XO is the only laptop I'm going to bring. Wish me luck.

Saturday, June 14, 2008

You Really Should Hack Linux

I have a confession to make. I'm an avowed Linux geek, yet I haven't complied the kernel in years. The last time was probably in school when I had to write my own scheduler for the kernel as an assignment, which isn't all that bad when you consider that most people compiling their own kernels are just enabling some obscure driver that they needed. They haven't made Major Modifications to a core piece like The Scheduler. Right? Right? Well, OK, the scheduler wasn't anything to write home about, but it still felt pretty l33t. Anyway, I've decided it's time I delve into the source of Linux again. It's one of the most successful large software projects on the planet, and it's completely open for anyone to dig into. It would be a horribly wasted opportunity for a serious software engineer to miss out on, especially someone interested in nitty-gritty low-level stuff. Even if you aren't interested in OS code or drivers at all, you could study it to learn about tools, coding conventions, documentation techniques, release management processes, debugging techniques, or how to do modularity and configurability, all for a pretty big project. Where else can you get all that for free? Convinced yet? OK then. Off we go.

I'll be using my Ubuntu Hardy Heron machine for development. Conveniently enough, there is a nice little package you can install called linux-kernel-devel which is described thusly:

This is a dummy package that will install all possible packages required to hack comfortably on the kernel.

I don't know about you, but I like to be comfortable when I hack. There is a helpful package included in linux-kernel-devel called kernel-package that makes it easy to create a debian package (.deb) out of our custom kernel, and to do that it's nice to have fakeroot, which allows you to make debian packages without actually being root, so install these two packages like so:

sudo aptitude install linux-kernel-devel fakeroot

It is customary (necessary?) to put your Linux source code in the /usr/src directory. Astute readers will notice that this directory is owned by root, but users in the src group can write there too. To avoid doing too much as root, add yourself to the src group like so:

sudo adduser <username> src

You'll need to log out and log back in (or start a new login shell, or maybe you can simply newgrp src) for the change to take effect. Test that you can create a file in /usr/src with a touch newfile command in that directory. Did it work? Sweet.

Now it's time to download some source code. The kernel is kept under revision control with git. There are other ways to get the source, but if you want the full kernel hacking experience, clone Linus' git repository in /usr/src like so:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6

This will probably take a while (I told you this was no toy project!). Once you've done that you can stay up-to-date by running git pull in the linux-2.6 directory.

Before we make a change, let's create our own branch to work off of. In the linux-2.6 directory run

git checkout -b my-cool-branch

Choose a better branch name then that. This will create the branch and make it current. Type git branch to see which branches you have and which one is current. OK, now we can make sure that the kernel will build (a good idea to do before you go making changes to the code). Before you build though, you need to configure your kernel. There are an amazing number of configuration options for the kernel. You can see these by running make xconfig (if it doesn't work, try installing libqt3-headers first, or maybe you only need qt3-dev-tools and libqt3-mt-dev, sorry, I didn't test that very well). Pretty overwhelming at first. An easier thing to try at first is to re-use the configuration for the currently running kernel. On Ubuntu (and Debian) the configurations for installed kernels are found in /boot/config-*. Copy the config for the currently running kernel like this:

cp /boot/config-`uname -r` .config

Then run

make xconfig

to see what is in that configuration and tweak it if desired (I wouldn't yet). Once you are happy with your configuration, save and exit xconfig. Now it's time to start building. Well almost. First make sure we are starting out clean. This is where we start doing everything as "fakeroot," and we use the make-kpkg command instead of make itself (read their man pages for more information). OK, clean:

fakeroot make-kpkg clean

That should have been fairly quick. Now the big command:

fakeroot make-kpkg --revision=1 --append-to-version=mycustomkernel --initrd kernel_image kernel_headers

Time to sit back and watch compiler messages fly by. This will take a while (it took 104 minutes on my kvm ubuntu virtual machine). When it finishes, you will have a nice .deb package of your new kernel and its modules in your /usr/src directory. From anywhere you can now type this to install it:

sudo dpkg -i /usr/src/linux-image-2.6.26-rc5mycustomkernel_1_i386.deb

(Obviously the filename will vary depending on which version you are based off of and what options you fed to make-kpkg for --revision and --append-to-version). Now reboot and see if it runs!

OK, I think that's enough for one blog entry. I cover actually making a change to some kernel code in another entry. I'll just close with a list of good references that I used in getting this done.

References:

Thursday, June 12, 2008

WAF Build System

I just took WAF for a very brief test drive after seeing ESR mention it on emacs-devel (trying to find an answer to a completely different emacs related issue). I really like how easy it is to install and try out a demo with it, and the manual isn't bad. I like the colored output and ascii-art progress bars. Nice touches.

It's all Python, which is both good and bad. The syntax isn't super intuitive (compared to basic make where you pretty much just list files and commands), being all python functions that set up and and get called by internals of the tool itself, but I guess once you get the hang of it that wouldn't be too bad. It also does more than just build. It handles detection of compilation tools, dependency tracking (yes it understands C/C++ preprocessing), and also does languages other than C/C++. If I had a new project I'd definitely give it a try.

Monday, June 9, 2008

Ubuntu Hardy - Worse Photo Import Than Before

I like f-spot a lot, but it has a few things that really bug me. I guess I should stop complaining and get involved, but then I'd have to learn C#. I don't know if I can bring myself to do that ;-) Anyway, here is what I used to see when I connected my digital camera to my Ubuntu 7.10 machine:

Now that I have Ubuntu 8.04, when I plug in my camera I first see this:

Yes, that's two confusing choices for one camera. Choosing either gets the same results:

Yup, it's offering to download some xml files and some other non-image files, and more room is devoted to showing you the full path to the files (that you really don't care about) than to showing you the actual thumbnail image. The option to delete from the camera what you just downloaded is gone too. Oh, and no videos will actually show up in F-spot, the program that is now doing this importing. Was anyone who uses a digital camera consulted on this move? I'm not alone in not liking this change.