Alexander Larsson

I’m back from my vacation now, and instead of spending days reading through the backlog of emails I decided to polish up glick and make a release so that people can play with it.

One problem that the initial glick version had was that all file lookups were done via the /tmp/glick_root symlink. This symlink being in /tmp and possibly being owned by someone else is a security issue. So, in the new release we instead use “/proc/self/fd/1023″ as the absolute prefix for the glick mount. While this looks a bit strange it is much more secure. However, it does make it a bit more complicated to create and test glick bundles, so glick now ships with the “glick-shell” tool that lets you point to a working directory and make /proc/self/fd/1023 point to that.

The new release also contains an easy to use script “glick-mkext2″  that creates minimally sized ext2 images from a directory, in addition to the mkglick script that creates the actual glick.

I’ve also added –icon and –desktop-file switches to mkglick that lets you embed 48×48 png icons and desktop files into the ELF file. These are stored in the “.xdg.icon.48″ and “.xdg.desktop” sections and can be easily extracted (using e.g. objdump, or some simple ELF header parsing code). In fact, glick now also ships with a tool “glick-extract” that lets you extract the filesystem, icon and desktop file parts easily.

I’ve talked to some people about the GPL licensing issue discussed in my previous entry, and I’ve come to believe that its ok to distribute glick bundles that contain non-GPL programs even though the glick code is GPL. Distributing such a bundle is really no different from distributing an iso file with both GPL and non-GPL software, which is explicitly ok due to the aggregation section in the GPL:

In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.

Of course, I am not a lawyer, so seek your own legal advice if you are unsure.

Anyway, this version of glick should be secure, easy to use and useful, please play with it and do amazing things. The source for the release and Fedora 7 rpms are availible from the glick webpage.

I’ve always admired the klik
project. At least the idea behind it, because the implementation was
(by necessity) a bit ugly. There are two main problems, first it uses
loopback mounts (requires root/setuid, has weird limitations, etc) and
secondly it does relocation of packages (so that they can find their
files) by patching the binaries.

Thats why I was so happy when i saw this blog
entry. The klik developers are working on klik2, which is working
to clean up these issues. I took a quick look at it, and they seem to
be using fuse instead of loopback, which is very good. To solve the
relocation problem they seem to be using fuse to implement a full
union filesystem.

I wasn’t completely sold on the union filesystem thing, as I thought
that was a bit overkill. All that really needs to be virtualized is one
directory, accessible via a fixed name for the running
application. Then you can install things in that given prefix, make a bundle of it and it
will run fine.

A few days later when I was lying on the beach I came up with various ways this
could be done. After a while I realized that it would be
possible to use fuse to do a runtime-less bundle system. In other
words, all you needed to install was a standard fuse, and then you can download the
app as one file and just run it. I’m on vacation and shouldn’t even be
touching my computer, but I was so exited about this idea I just had
to see if I could do it. After a day or so of hacking, i was able to make it work.

Introducing glick

glick bundles are standard ELF files that you can run like any other
binary, but they contain all the files, libs and binaries needed for
the application in that one file. glick files embedd a filesystem in the
rodata section of the elf file, and the startup code contains a fuse
filesystem to mount this filesystem, and some magic glue code to make
it all work together.

Here are two example bundles: fancy
greeter, katach.

I’ve tested these on F7, and it seems to work. (fuse-lib and fuse must be
installed, and due to a broken Fedora packaging of fuse the user must be a
member of the fuse group or fusermount needs to be chmod:ed).

Implementation details

On application launch the glick code is started. It then creates a
temporary directory where the filesytem will be mounted. Then it creates a pipe to
talk to a child process and forks. The child process starts up the
fuse filesystem (reading from the automatically mmap:ed rodata section) and mounts that on the temp directory. Then it talks
to the parent by writing to the pipe.

The parent code opens the directory, and uses dup2() to store the file
descriptor to it as fd number 1023. Then it creates (or ensures that
there already exists) a symlink called “/tmp/glick_root” that points
to “/proc/self/fd/1023″. This is the magic part. Since we have the
target directory opened at fd 1023 the /tmp/glick_root symlink will
point to the mounted fuse filesystem for this process and all its children
(that don’t close fd 1023). This means the code in the filesystem can
hardcode /tmp/glick_root to access their files. (Having this in /tmp
is slightly non-ideal. A better place would be in say /var/glick_root,
but then it wouldn’t be a runtime-less system).

Then it reads from the pipe, waiting for the mount to finish. When the
mount is up it it execs /tmp/glick_root/start which is a script or a
symlink that starts up the real application inside the fuse mount.
When the application dies the pipe to the fuse child is automatically
closed. The child notices this, unmounts the mount, removes the
temporary mountpoint and exits.

Licensing issues?

The implementation uses e2fsprogs-libs to implement the fuse
filesystem (based on fuse-ext2 by Jeff Garzik). This library is
unfortunately GPL, which is not ideal for maximal reuse (my code in glick is X-style
BSD). Does embedding an ext2 filesystem inside an elf
file that contains GPL code make the files in the filesystem a derived
work of the GPL code, or is this a “mere aggregation” in the terms of
the GPL? License questions abound… Anyway, perhaps using fuse-cramfs
that the klik people are working on is a better idea anyway.

The code

The code is availible via git here. Play
around with it, experiment, have fun. I did.

Note: The name “glick” is a pun on the kde:ish name of the the klik
project. This is not ment to be a slight or anything like that. I
greatly appreciate the work of the klik project (although I do believe
that their choice of name unfortunately is costing them mind-share
amongs gnome users). Hopefully the klik people will look at my work and steal the appropriate ideas.

A recurring theme at this years Guadec was the need for a toolkit next to Gtk+ for doing some of the next generation fancy effects that Gtk+ isn’t suited to (i.e. things like coverflow). One of the current experimental approaches for this is Clutter. In order to get a feel for clutter and the requirements and usecases for a toolkit supporting fancy effects I started writing a small demo for a fancy version of a gdm greeter. Its basically a fullscreen face-browser in the form of a Rolodex:

I did all development on a machine without 3D acceleration (way to go ATI! I’ll never buy your hardware again), and it does work with the Mesa software rasterizer, but its really meant to be running on a 3D accelerated machine, and that is where it looks and behaves nice.

If you want to test it out, the code is available via git at http://www.gnome.org/~alexl/git/fancy-greeter.git/ . You need clutter and clutter-cairo from svn too.

As to clutter, It seems very nice. I got a bunch of OpenGL error spew when removing actors errors that I don’t believe is my fault, so it seems to have some bugs, but it was easy for me to hack up this example in a few hours, so the API is easy to use. I’m not completely sold on the animation framework though, it seems a little hard to use. Hopefully with the competition from other projects like pigment we’ll figure out the best API for this eventually.

On Wednesday I did a presentation on GVFS at guadec, and a bunch of people have asked me for the slides, so I put them up here.

The talk went ok. There was a bunch of questions during the talk, so unfortunately I had to skip a couple of slides. But at least thats better than having no questions (and thus interest) at all.

Update: pdf version availible

I’ve been put (temporary) on the OLPC project at work, working on the update system for that. That, plus the fact that all my spare time (and then some!) are being sucked up by the baby means I have very little time to work on Gnome at the moment.

This means most of my work on gvfs is frozen atm, and I don’t have time to follow the gnome-vfs and nautilus lists much. This is just a temporary thing though, and in a month or two i’ll be back hacking on gvfs!

The (so far unnamed, but we’re working on that) baby hasn’t given us much sleep recently. But she is very cute!

I put up some photos on flickr.

For a long time Gnome and other desktops have been using an english directory name for the desktop folder (and a few other common directories like music, download and documents). There has been a lot of discussions (read: flamewars) on how to localize these filename. After the last one I’ve finally broken down and done something about this. So, I present to you xdg-user-dirs.

It is a desktop-agnostic (and dependency free) program that is meant to be integrated by distros so that it gets run very early in the login phase. It will then look at the users locale and system-specific default configurations and use these to create a set of folders in the users homedirectory. It also generates (or updates) a user configuration files that points to these directories so that applications can find them.

I’ve also created the gnome-specific module xdg-user-dirs-gtk and a set of gnome patches that integrates these directories into the Gnome desktop. With these in place (availible in the Fedora 7 rawhide repositories now) users automatically get localized folders like Music, Movies, and Documents, plus default bookmarks to these in the gtk file selector. Any changes to these folders (e.g. moves or renames) with nautilus will automatically be updated in the bookmarks and the user directory configuration.

The Gnome integration even detects when you log in with a new locale and asks you if you want to move your directories to the new language.

Its also very easy for the sysadmin to change the default directories created for users (or to disable the whole thing). Just edit a simple config file.

I’ve been looking at some nasty nautilus crashers this week, including bug 343488 which has several hundreds of duplicates in bugzilla. Thankfully the bug team has managed to mark all of these as duplicates, or this would be a major undertaking.

One problem with autogenerated bugreports like this is the lack of information in them. All they have is a backtrace (generally without debug information, i.e. pretty useless) and a short line of text saying what the reporter did at the time. You can get a better feeling for the bug by reading a lot of the duplicates and try to detect common patterns, but this only works sometimes.

Thanks to the miracle of separate debug info and debuginfo packages (which I created back in 2002) its now pretty easy to have a user create a backtrace with debug information. This makes the backtraces much more useful, and we eventually got someone to report a nice backtrace for the bug.

Sometimes that is not really enought, like in the case of this hard to reproduce bug. To verify my suspicions I really needed to see the stderr output from nautilus to verify that an assertion warning triggered. But the output from nautilus isn’t normally visible as nautilus isn’t started from a terminal. We eventually managed to find someone who could reproduce this and send us the end of ~/.xsession-errors which had the suspected output.

This got me thinking a bit. If that information had been availible in the automatic bug reports it would have been much easier to find this bug, and similarly with all crashes that spew several warnings or asserts before crashing. So, I wrote a patch for bug-buddy to output some extra information when it creates crash dumps.

The patch also adds some information on the kernel used, the X server used, whether accessibility is enabled and the selinux mode. I hope we’ll get this out to users soon so that we can do a better job fixing bugs.

I’ve spent most of yesterday and today in the ninth circle of X hell, also known as XKB onfiguration. However, I’m now starting to see the light from above.

Why would anyone willingly look at XKB configuration you might ask. Well, I recently got a MacBook Pro, and the keyboard layout it used is slightly different than the regular pc105 keyboard. The main problems are that the key to the left of “1″ and the key to the left of “z” somehow got their keycodes swapped, and the fact that there is no right Alt which means its hard to type certain symbols (there is a right Apple key though).

There are various places on the internet that shows you the magic xmodmap incantations you need to “fix” this, but I wanted a real fix that would let anyone set up a MacBook keyboard. So, I set out to add XKB configuration that lets you use the gnome control center to pick the right keyboard.

So, I proudly present the result of my labor:

I added not only fixes for the keycodes, I also added the correct symbol for the eject button, a geometry description, and an option to make the apple keys act as Alt (since they are in the normal Alt positions).

There seems to be some redraw bug in the applet, because the return key isn’t rendered right.

I’ve already build the patch in Fedora Core (development), and the upstreams patch is availible here.

After some discussion with Michael Meeks about yesterdays post we decided to move the problematic gnome-vfs functions to libbonobo, so that we can totally avoid bonobo in gnome-vfs. This is ok, since these functions are useless unless you use bonobo yourself, so you’ll be linking to libbonobo if you use them. In fact all old apps are guaranteed to do this since gnome-vfs pulled in libbonobo.

So, what happens is that the function declarations are in the gnome-vfs headers, but the actual implementation is in libbonobo. This means we can now push gnome-vfs much lower in the gnome build stack. It now only depends on glib, dbus, gconf and libxml.

There is only one minor issue. Since we don’t want gnome-vfs to depend on bonobo I had to remove a bonobo include from the gnome-vfs headers. Its likely that apps that use these functions already include this header, but if they don’t they can just add that include, or define GNOME_VFS_INCLUDE_BONOBO to make gnome-vfs include it. The only application in Gnome that uses these functions is evolution, and it didn’t need any modification to keep building.