You are viewing np237

np237
01 April 2011 @ 03:51 pm

For the whole week, I’ve been in Bangalore for the GNOME.Asia 2011 hackfest. I’ve been delegated by Stefano to represent Debian here, and my employer EDF has agreed to cover for travel costs since they are very interested in first-hand information the future of the Linux desktop and sharing our work on scientific computing.

It’s been a really exciting week; I’ve spent quite some time packaging missing pieces of GNOME 3.0 (well, the release candidate versions of course) in experimental, together with Fred Peters. I think it’s reaching a usable state now, so we’ll probably soon provide metapackages to make it easily installable.

The latest developments of the Shell make it a very exciting piece of software, with a strong focus on usability. Many things were written about it, but in the end my main criticism would be that it lacks some functionality - for example, the combined clock/weather/locations applet will be greatly missed. The good news is that it is extremely customizable, and with all the libraries being made accessible through GObject introspection, there are many features that are accessible from it. If you know how to write JavaScript, now is the time to write your favorite extension.

On the good news front, Vincent Untz also spent a lot of time improving the so-called “legacy mode”, which is more and more starting to look like the Shell without special effects, and with all the features from gnome-panel 2.x that are still here. We will try in Debian to cover all uses cases that there were for GNOME 2 with GNOME 3 technology, so that panel lovers are not left behind.

I’ve also proposed an update to the dh_gsettings proposal, which will provide the same functionality as dh_gconf and allow to easily set distribution-specific overrides. It is still missing a way to set mandatory settings, which might come as a problem for some corporate users, but this is planned for a future version of GSettings.

Today, we’re having a business track where I and representatives of other companies (Oracle, Lanedo, Dexxa) are sharing experiences about making money with free software. Unfortunately the local organizers didn’t manage to gather many people, despite our being in a city with an incredible number of IT industries.

Tomorrow, the public conference starts, and this should be the opposite: we’re expecting around 1000 people, which is a great achievement for a free software conference.

For an unrelated topic, being around so many GNOME hackers has some interesting side effects; I’ve been added to Planet GNOME. So, hey, hello Planet GNOME readers!

 
 
np237

There have been a lot of web browsers embedding the Gecko engine, especially through the gtkmozembed “library” (it was not really a proper library but let’s call it like that). I remember being a happy user of galeon, which went on as epiphany, but there were also all these small applications that just need a good HTML renderer in one of their widgets, like yelp, or several Python applications using python-gtkmozembed.

Anyone having had to deal with these applications, especially the most complex ones, could tell you a few things:

  • the Mozilla developers never gave a friggin’ damn about embedding;
  • they don’t know how to develop an easily embeddable library;
  • the notion of a stable interface is a very arcane concept that they don’t wish to grasp.

So, today, it is official: Mozilla is dropping gtkmozembed from their codebase.

I don’t think this will come as a surprise to anyone. You can’t develop a new version of a behemoth, monolithic application every 3 months while still caring about the interfaces underneath. Embedded applications have been migrating to webkit over the recent years, and those that don’t do it really soon will die.

The interesting part of the announcement is not here. It can be found hidden in a bug report: a stable and versioned libmozjs will just never happen.

What does it mean?

First of all, it means that Debian and Ubuntu will have to go on maintaining their own versioning of libmozjs so that it can be linked to in a decent way by applications using the SpiderMonkey JS engine. It also means that this version will have to be bumped more often.

But it also puts into question the whole future of SpiderMonkey as a separate library. With a shortened release cycle, the Mozilla developers will be tempted to add more specific interfaces to SpiderMonkey, reducing its genericity in favor of its use in Firefox itself. This will produce less and less useful libmozjs versions, until we reach the point when they’ll make the same announcement as above, with s/gtkmozembed/libmozjs/.

This is especially relevant in the context of the GNOME Shell, which is at the core of the GNOME 3 experience. The developers deliberately chose to avoid using JavaScriptCore (the JS library inside webkit) through the Seed engine, and used GJS instead, that relies on libmozjs. In my opinion this was done for frivolous reasons (being able to use more language extensions); and not only this put the GNOME developers in an awkward situation where 2 JS interpreters compete in the same desktop, but now it puts a risk on a technology which is at the core of the desktop.

One of the reasons for the limited adoption of JSCore is that it lies currently in the same library as Webkit, which is a huge dependency. I’ve been very glad to learn that Gustavo is considering the idea of splitting it. We need to provide an escape route for applications using libmozjs, and it looks like more than a decent one. I hope that GNOME Shell follows it sooner than later.

 
 
np237
24 March 2011 @ 08:54 am
 
 
np237

A few weeks ago, at work, we were looking for a solution to a tricky printing problem: how to manage, in a centralized infrastructure, a large number of locations, worstations and printers?

One of the consultants working for us came up with a great idea. With only a 20-line patch to CUPS, workstations would be able to find which printers are on the same location. 20 lines of code, instead of a complex virtualisation solution? This is exactly the kind of reasons why we use free software: when there’s something wrong, you can fix it. When you need something more, you can code it.

Now, many others could benefit of such an improvement, and we don’t want to maintain a forked version of CUPS, so we forwarded it upstream, who looked interested. But upstream now being Apple, they requested a stupid copyright assignment agreement.

I will leave to the reader’s imagination the complexity of getting such a document signed in a Fortune 500 company with no business with Apple. This will, of course, not happen - and if the decision was mine, the answer would have been a clear “No.” No, because I want to improve free software, not to contribute to Apple’s proprietary version. No, because copyleft is about giving as much as you take.

How many contributions are being left out of CUPS because of this stupid copyright assignment? It looks to me that such software is doomed to remain crippled as long as companies like Apple are in charge of their maintenance.

There is free software. And there is free software by Apple. And Oracle. And Canonical.

 
 
np237
07 March 2011 @ 01:39 pm

At first, it looked nice:

But then, it was more like:

 
 
np237
25 December 2010 @ 11:09 am

My only contribution will be: merry FSMas to all!

 
 
np237
01 December 2010 @ 08:12 pm

We’ve come a long way since the times when you needed to configure 2 X servers in XDM just to be able to use 2 X sessions at once. However there was still some way to go until recently. A number of bugs that could be wrongly attributed to bugs in the X server or in the desktop environment were actually caused by the display manager doing crap.

GDM up to 2.20

Since the introduction of the “flexible X servers” feature, GDM hadn’t evolved much on the matter of user switching. What it used to do was pretty straightforward:

  • a specific protocol can be invoked by the gdmflexiserver command;
  • the gdm daemon spawns a new X server on an empty console;
  • it initiates another login process in it;
  • when the session exits, or if the user clicks on “Quit” instead of logging in, the X server exits.

It is interesting to note that VT (console) switching is purely handled by the X server. When starting, the new server switches the current VT to where it is. When exiting, it automatically switches back to the VT from which it was launched.

While very simple, this idea fails to work correctly every time you try to do something more complicated than starting a temporary session for a guest and exiting it. For example, if you start two of them, there is a chance that, when the X server switches back to the console it was run from, there is nothing left running in this console, leaving you with the funny Control-Alt-Fn shortcuts to find your way back to a X server. You will also meet interesting race conditions when trying to switch back to an existing session from the login window.

GDM 2.28 and above

In the process of rewriting the code entirely, the GDM developers tried to address a number of those shortcomings, making use of D-Bus and ConsoleKit. The new design is slightly more complicated, however.

  • The gdmflexiserver tool will first try to look for an existing login window in another X server, and just switch to the VT it is in if it finds one.
  • Otherwise, the daemon starts a new slave process with a new X server and a new login window, in a very similar way to what older versions did.
  • When logging in as a user with an existing session, it switches to the VT it is in, but leaves the login window and its X server running.
  • When going into a new session, the X server is simply left to die at the end of the session, and to switch back to the VT from which it was launched.

Not killing the X server in some cases partly addresses the problems caused by letting it switch back to the original VT when exiting. However in several ways the cure is worse than the disease.

  • First of all, it will leave unused X servers, with all processes used by the login window - and that makes quite a number of them, with GDM now using a minimal GNOME session.
  • When there is such a login window remaining, ConsoleKit will refuse to let you shut down your computer, being lured into thinking there is someone else using it.
  • It doesn’t solve the inconsistency issue. When you leave a session, you can find either of: a login window, a screensaver unlock dialog, or a black screen.

Getting it to work

The modular architecture of GDM makes it possible to improve the situation. (Possible but not easy because of the millefeuille of classes.) However, it is merely a band-aid unless you fix the root issue: the X server knowing better than you which VT it should switch to when exiting.

Fortunately Xorg now features an option to avoid that behavior: -novtswitch. So the first step is to enable it, and let the GDM daemon (or slave) handle VT switching through ConsoleKit. With that, the following changes are possible.

  • When switching to an existing session, don’t leave a X server behind. You can now kill it safely without risking a VT switch.
  • On the opposite, when exiting a session, always respawn a login window on the same VT.
  • The last step is to stop making a difference between the first launched X server (called a static server) and the flexible servers. The only remaining difference between a static display and a flexible one is that the static one honors automatic login/timed login settings.

The result

With all these changes the behavior of the display manager is finally completely consistent.

  • When exiting a session, regardless of it, you always find the same login window.
  • There is never an unused process left.
  • You will never find yourself facing a black screen with only keyboard shortcuts to leave you out of it.

Interestingly enough, this is very similar to what user switching looks like on Vista or MacOS X.

So what now? These changes are stabilized for Debian squeeze, but of course it has been long overdue to get them accepted upstream, along with the very large number of Debian-specific changes that still lie in our packages.

 
 
np237
13 November 2010 @ 12:29 pm

If you use pbuilder, you probably already use cowbuilder too, in order to save on chroot instantiation time. You also probably use ccache in order to save on compilation time.

If you do that, the longest time taken by your build is, by far, the time needed to install the build-dependencies, because dpkg likes to fsync() every file it writes. It’s a good thing it does that on your main system, but in a disposable chroot you really, really don’t care what happens to it if the system crashes. Thanks to Mike, I discovered eatmydata, and tried it with cowbuilder.

If you want to try it out, add this to your pbuilderrc file:

EXTRAPACKAGES="eatmydata"

if [ -z "$LD_PRELOAD" ]; then
  LD_PRELOAD=/usr/lib/libeatmydata/libeatmydata.so
else
  LD_PRELOAD="$LD_PRELOAD":/usr/lib/libeatmydata/libeatmydata.so
fi
export LD_PRELOAD

You will also need to install eatmydata in your chroot, unless you want to regenerate it from scratch. And now you can enjoy your super-fast builds.

 
 
np237
06 November 2010 @ 08:18 pm

My wife has been pestering me for months to get a replacement for our dead Epson inkjet printer (which didn’t last long, mind you). To avoid the nightmare of printer support, which, unless you buy a high-end professional printer which does everything plus the coffee, is usually somewhere between “disaster” and “works sometimes”, we spent a long time on manufacturers websites to choose wisely the model.

We chose the HP Laserjet P1102, which, according to HP, has a full support level and is even part of their recommended models.

Yet, after plugging it in, it took me quite some time to understand why it would behave as a brick instead of a printer. First, I thought it was a bug in hplip. Then, I soon discovered that the printer advertised itself as a storage device instead of a printer. What, a buggy firmware?

Thanks to a random question on Launchpad I discovered it’s not a bug, it’s a feature. It’s named HP Smart Install and it turns out it’s yet another stupid idea to support OSes that are too dumb to detect your printers automatically: the printer advertises itself as a CD drive, until you install the driver that will make it switch back to being a printer.

What happens to those who don’t want this “feature” that turns your printer into a 10 kg, read-only USB drive? Well, HP has a solution in the Smart Install FAQ:

25. Can I turn HP Smart Install off or on?
Yes. You can use the HP Smart Install utility to disable/enable HP Smart Install. The utility is stored on the software CD, in the UTIL folder. SIUtility.exe is for 32-bit operating systems and SIUtility64.exe is for 64-bit operating systems.

Bunch of idiots. If I buy a €100 printer, it’s not so that I have to buy a €100 operating system just to activate it.

 
 
np237
02 November 2010 @ 02:57 pm

Several people asked me for the slides I presented Saturday at the Mini Debconf. Until they are available on the Debconf website, here they are:

Despite having gone completely overboard with the timing (let me apologize again to the organizers), the talk seems to have gathered quite some interest. Several people looked surprised to learn Debian is used on such a large scale.