Fosdem O'Reilly
2005 Edition Free and Open Source Software Developer's European Meeting


2005-02-09 - Alexander Larsson


An interview conducted by FOSDEM & theLinuxFR readers
FOSDEM - First traditional question : Please present yourself.

Alexander Larsson - My name is Alexander Larsson, I'm a 30 years old Swedish developer living in Stockholm, working remotely for Red Hat. I work mainly on Gnome, where I maintain Nautilus, Gnome-vfs and a few other modules. I do both packaging work, bug fixing and new development, mostly related to Gnome but sometimes on totally unrelated things.

During the years I've worked on many free software projects, like Gnome, Mozilla, Wine, the linux kernel, etc. My favourite hack of all time was when I added support for external debug info to gdb and made rpm automatically generate debuginfo packages.

FOSDEM - FUSE and Gnome-vfs seem to share many goals with two very different approachs. How would you compare them both from a theoretical perspective and from a practical user perspective?

Alexander Larsson - These systems are quite similar at the core, in that they allow you to write modules to access various kinds of new filesystems. The major difference between them is how programs access that new filesystem. With FUSE all access go through the kernel, and a filesystem must be mounted in the unix tree, while with gnome-vfs, programs just call the gnome-vfs library like any other library.

There are advantages and disadvantages to both ways. An important advantage for FUSE for instance is that all unix programs can access the mounted filesystems instead of only apps designed for gnome-vfs use.

For Gnome, a system such as FUSE is not very interesting. First of all Gnome has to be portable, which means it can't depend on something that only exists on really recent or patched versions of the linux kernel. Secondly, there are some problems with the FUSE approach that makes it less interesting for us:
  • The only way to access files on a FUSE filesystem is through the unix syscall interface. This is a pretty limited system that is hardcoded and very hard to extend. Having a more flexible api like gnome-vfs allows us to add functionality needed for gui applications. For instance, its hard to add support for progress indication. If a NFS share goes down then programs reading files on it just hang.
  • If you access a file through the normal syscall interface you generally expect it to obey the normal unix semantics. Although NFS and other common unix network filesystems isn't following posix semantics totally, they are very close. The kind of filesystems we're using in gnome-vfs don't really map well to these semantics, so applications using FUSE might be suprised when e.g. some of the atomicity or cacheing guarantees in unix suddenly no longer hold, or when it behaves slightly differently from what you expect from a filesystem.

    The gnome-vfs semantics are weaker, and the fact that you're using a different API makes the developer wary of things like this. Unfortunately everything isn't perfect in gnome-vfs land either. The gnome-vfs semantics is very weakly specified, and doesn't go far enough from posix semantics. If I were to design a user-space vfs now it would look quite differently. Likely a bit like what havoc describes at:

    As to a practical perspective, it depends a bit on the user. FUSE can be used right now by people with unix shell experience, but at the moment it lacks a GUI in the sense that gnome-vfs has in Nautilus. You have to manually mount the filesystems you want in some place, whereas with gnome-vfs and Nautilus you can just click on say "Network" and start browsing samba shares. MacOS X uses a FUSE-like approach, but has built-in support in the finder for this, so things are automatically mounted when you need it. FUSE would need something like that to be useful to desktop users in general.

    FOSDEM - The recent progress on inotify seems promising for Nautilus users' experience, thanks to the Gamin library. Are there any other kernel level changes that you expect or dream of?

    Alexander Larsson - Good file change notification has long been a problem with the Linux kernel, and I've often ranted about how crappy dnotify is. However, if that gets fixed then I think the 2.6 kernel is pretty good for desktop use. I can't think of any really important missing features. Some of the new features like sysfs probably needs time to mature, but it seems like they're getting there.

    There are still a couple of things I'd like to see though:
  • Working suspend/resume on laptops and desktops
  • Fix all the issues in the wireless drivers to work with NetworkManager
  • Good 3D graphic card drivers (only partially a kernel issue)

    FOSDEM - There exist - at least at an academic research state - some very interesting works about "Logical File System" and things like that, which allow for instance to navigate in an mp3 files collection by echoing commands like:
    # cd "year<=1980"
    # cd "style=Disco|Funk"
    # mpg123 *
    Have you ever thought of what a GUI file manager for that kind of file systems would look like?

    Alexander Larsson - I haven't really thought about this, but I know seths Storage project is doing something somewhat similar to this, and the Beagle project is doing some indexing and searching too. And of course, both Apple and Microsoft are working on indexing and searching for their systems.

    Clearly there seems to be an emerging interest in searching, and I hope free software can deliver a great experience in this area.

    FOSDEM - Are there any ongoing projects for Gnome 3? Is there a consensus about a high-level language (Python, Java or C#) or is it the C which gets the upper hand?

    Alexander Larsson - Not really. There is a wiki page discussing some of the things that could go into Gnome 3. Gnome 3, as defined by the Gnome project is the first release that totally breaks backwards compatibility with Gnome 2.x, and I'm not convinced that there is a need for such a break for quite some time yet. Many of the things people are discussing for Gnome 3 are in fact possible to do within the Gnome 2.x series, and some are already in the works. For instance, adopting a high level language (be it Python, C# or whatever) can easily be done without breaking backwards compatibility.

    I think C will stay at the core of Gnome for a very long time. The core libraries will continue to be written in C, but with wrappers for different languages. Hopefully the introspection work Mathias Clasen is doing in glib will make it even easier to use these libraries from high-level languages. However, I firmly believe that eventually there will be one or more high level languages used for writing applications in the core desktop. Which languages will be used I don't know.

    FOSDEM - What are you expecting from FOSDEM ?

    Alexander Larsson - I want to meet with interesting people and chat with them. Hopefully I'll learn about cool new stuff people are working in.


  • © FOSDEM 2003-2005 - powered by Argon7