Planet Ensigogne

Notification to speakers

The GUADEC 2012 programme committee took a bit more time than first anticipated to evaluate all talk submissions, but it's now all done: this morning, we finally sent the notification to speakers. Thanks to everyone who submitted a talk: it looks like we'll have a great GUADEC :-) Of course, we still need to create the schedule, but that should be trivial, right? (hmm...)

If you submitted a talk and didn't get a positive or negative answer by mail, please first check your spam folder: mail is from guadec-papers, and contains Your talk at GUADEC 2012 in the subject. If you don't find anything, feel free to ping me.

Help organize the lightning talks!

Next step is the call for lightning talks and for BoFs! I guess this will happen in the next few days. I don't think we have anyone in charge of this yet, so if that's something you'd like to help with, just drop us a quick mail on guadec-list and we'll happily give you a I'm fantastic: I'm helping organize GUADEC badge ;-)

10 May 2012 à 12:00

SUSE is hiring people for the Boosters team! This is the team I've been involved in in the last few years, so I thought I'd share with you a few words on this...

The Boosters are working on enabling openSUSE contributors to reach their goals. This can involve technical diving, an artistic vision (not required, obviously, or I woulnd't be in the team ;-)), marketing fun, talking at events, discussing issues, etc.: all skills are welcome in our team, as all skills are welcome and needed in the community! It's really an amazing job where you're simply part of the community and your goal is to help the community move in the right direction. On top of that, I have to mention that the Boosters team is full of great minds, and we're enjoying every day working on something we love!

Dream job, some might say :-)

Are you interested? Check out the details and apply! You can also check the other open positions at SUSE, there might be the one you're looking for... ­Oh, and as we keep hiring, remember to check out the careers page every now and then to see the latest openings!

26 April 2012 à 17:05

I’ve just updated the Debian Packaging Tutorial. This new version addresses a few comments and questions I received over the past months.

Note that there are also french and spanish versions of the tutorial, and I’m of course open to adding other translations.

The tutorial can be found in the packaging-tutorial package (PDF files are in /usr/share/doc/packaging-tutorial/), or on www.debian.org (see links above).

13 April 2012 à 11:28

If you want to give a talk at GUADEC 2012 in A Coruña (Spain), hurry up: the deadline for the GUADEC CfP is tomorrow. Don't think twice, just go ahead and submit your talk!

13 April 2012 à 07:20

The web at your fingertips (GNOME 3.4 banner)

One year ago, the release of GNOME 3.0 was laying solid foundations for the new design of our software. Fast forward to this week: our project is reaching the 3.4 milestone. It comes with a new flow of improvements for our users, and I believe it highlights our commitment to the GNOME 3 vision to offer a modern and innovative environment: revamped look of applications, the application menus, the many small annoyances we fixed, etc. But this is not all: the community is also preparing for the next level with behind the scenes work such as smooth scrolling and support for touch events.

Now that 3.4 is out, I know a lot of people are looking forward to the 3.6 release! Cool stuff is coming in the next six months, and there will an amazing opportunity before September to share what you believe will matter: GUADEC at the end of July!

So now that you're all done with the 3.4 release, it's time to go read again the GUADEC CfP and submit your awesome talk!

Port of A Coruña, where you will join us for GUADEC 2012!

Oh, and I cannot avoid a mention about GNOME 3.4 in the openSUSE land :-) The openSUSE GNOME team quickly got 3.4.0 packaged: it was in GNOME:Factory on Wednesday already, and the late tarballs were integrated yesterday. All of this has been submitted to Factory so it will be in the next 12.2 milestone. And some people are starting to look at building GNOME 3.4 for openSUSE 12.1 too, if you prefer to stay on a stable distribution.

30 March 2012 à 17:18

In case someone missed this information, in 2012, GUADEC is coming to A Coruña in Spain. This is a city that several members of our community already know well, thanks to various great hackfests. The core conference will be held from July 26th to 29th, with a few more days afterwards for BoF sessions, meetings, hackfests, etc.

I'm taking some time this year to help organize GUADEC, by joining the program committee. I feel we managed to gather a nice group of people (and also a group of nice people) in this committee, with contributors from various areas of the project: Andre, Allan, Ryan, Michael, Lennart, Christian, and myself.

And the call for participation for GUADEC 2012 is now open!

There are the usual topics for this CfP (design, web integration, plumbing, outreach, etc.), but 2012 is also a special year: GNOME will turn 15 in August, just a few days after GUADEC! That's a good opportunity for all kinds of crazy talks about what we did in the past, about looking back at our progress, but also about imagining the next 15 years. For instance, I'd really love to see someone demo old releases, like October GNOME or GNOME 2.0...

So go read the CfP, then go wild and submit a wonderful talk!

Note that there will be a later call for lightning talks, likely in April or May. We're looking for volunteers to help organize the lightning talks; feel free to ping me if you're willing to step up.

28 February 2012 à 10:51

(original post)

> If Ubuntu 12.04 if a LTS release, and Ruby 1.8.7 goes out of support in June of
> 2013, then why is the default still 1.8.7?
>
> Ruby 1.9.2 was released in 2010. Ruby 1.9.3 was released in October of this year.

First, there’s almost nobody in the Ubuntu development community doing any Ruby work. Packages are just imported from Debian, and Ubuntu follows what is done on the Debian side.

In the Debian/Ruby team, we are currently transitioning to a new packaging helper (gem2deb) that makes it much
easier to support several Ruby versions. Once this will be done, switching to 1.9.3 by default will be very easy. We already provide a way for the sysadmin to change the default on a system.

Now, doing that transition takes time, and we could have used *your* help (and could still use it). We are still quite on time to do it for Debian wheezy, but it sounds very hard to do it for Ubuntu 12.04 unless someone from Ubuntu steps
up to help.

01 January 2012 à 14:37

Context switches are expensive. When do they happen in D-Bus communication?

application1 sends a D-Bus message to application2 through dbus-daemon

The kernel may perform a context switch:

• During the sendmsg() system call, when application1 sends a D-Bus message to dbus-daemon
• During the sendmsg() system call, when dbus-daemon sends a D-Bus message to application2
• At the end of a time slice

I instrumented libdbus in order to trace events such as message parsing, dispatching messages in dbus-daemon,  sendmsg(), recvmsg(). I took inspiration from Federico’s performance scripts but without using strace because straced processes have a big overhead compared to the duration of events I want to measure. My instrumentation doesn’t save traced events in a file to avoid overhead as much as possible, but just keep them in memory and save them after the experiment is finished. This is triggered:

1. when a process using libdbus exits. The save function is registered by atexit().
2. when a process using libdbus receives a SIGUSR2 signal. The save function is registered by sigaction().

I collect logs generated by dbus-daemon and all D-Bus peers and feed them to plot-timeline.py to generate timelines. I estimate the overhead of logging between 3 microseconds and 5 microseconds by logging consecutively 2 events. All the experiments are run in a virtual machine with one processor.

Experiment #1: a D-Bus signal delivered to 10 recipients

I sent one D-Bus signal with dbus-send and received by 10 dbus-monitor. You can reuse this script.

In this experiment, dbus-send was context switched off during the send() system call and that system call returned after dbus-daemon received the message, sent it to the 10 recipients, and all of them received it.

We can see dbus-daemon iterating over every recipients and sending the message on each recipient’s socket.

There is 12 context switches in this experiment:

• 1 context switch from the sender to dbus-daemon
• 10 context switches to each recipient
• 1 final context switch to the sender

Experiment #2: 10 D-Bus signal delivered to 10 recipients

It is the same experiment as before but the sender emits 10 D-Bus signals (as fast as it could) instead of a single one. dbus-send cannot do that, so I used dbus-ping-pong.

The first three D-Bus signal are delivered in the same way; this timeline looks like the first timeline. There is also 12 context switches per D-Bus signal emitted.

But something different happen for the 7 next D-Bus signals: dbus-daemon is context switched off during the send() on every recipient.

The scheduler tries to maintain fairness along all the processes by giving them the same amount of CPU time. But dbus-daemon has about 10 times more work to do than every single recipient because it sends 10 messages and the recipients only receive 1 message. So when dbus-daemon writes on a recipient’s socket, there is two processes in the running state and the scheduler has to take a decision between a CPU hungry process (dbus-daemon) and a recipient. The recipient is chosen and it causes a context switches.

The context switches per D-Bus signal emitted are:

• 1 context switch from the sender to dbus-daemon
• 1 context switch from dbus-daemon to the first recipient
• 1 context switch from the first recipient back to dbus-daemon
• again 2 times 9 context switches between dbus-daemon and the remaining recipients
• 1 context switch from dbus-daemon to the sender

That’s 22 context switches in total instead of 12 for the same amount of work and the same amount of messages delivered.

The experiment was run in 0.036121 seconds.

Experiment #3: 10 D-Bus signal delivered to 10 recipients with a high priority dbus-daemon

With the command renice, I change the priority of dbus-daemon to -15.

In this case, the kernel chose the first scheduling strategy with 12 context switches per D-Bus signal emitted. The experiment was run in 0.019320 seconds. It is 1.8 times faster.

Most D-Bus messages don’t have so many recipients. But still, it is interesting to see how much the priority of dbus-daemon influences the performance.

On Debian, dbus-daemons (session and system bus) run with the default priority (nice level: 0). On the N900, they run with a higher priority (nice level: -5).

Experiment #4: details of dispatching

Let’s zoom on dbus-daemon’s dispatching for two different sizes of D-Bus signals:277 bytes and 17kB.

277 bytes D-Bus signal:

• Total: 524 microseconds
• Receiving: 36 microseconds (7%)
• Dispatch: 164 microseconds (31%)
  
  • 79 microseconds in match rules
• Sending: 324 microseconds (62%)

17kB D-Bus signal:

• Total: 1026 microseconds
• Receiving: 413 microseconds (40%)
• Dispatch: 230 microseconds (22%)
  
  • 79 microseconds in match rules
• Sending: 383 microseconds (37%)

19 December 2011 à 18:18

Telepathy is a big user of D-Bus, both on the GNOME desktop with Empathy and on the N900. When I have a lot of Telepathy accounts and contacts, the start-up time could be about 10 seconds. How much is the D-Bus communication responsible for the start-up time? When I tried the D-Bus in the kernel prototype on the N900, I win 1.3 seconds. It shows it is not negligible and there is room for improvements. But the slowness may not be due only to D-Bus itself but the way it is used. It is interesting to look at the D-Bus traffic pattern. This topic was already largely covered by Will’s  talk on Profiling and Optimizing D-Bus APIs but I want to give a preview on future D-Bus analysis tools. The existing D-Bus tools dbus-monitor, D-Feet and Bustle are still very useful of course.

A glance at D-Bus messages

The easiest to begin with is to record all the D-Bus traffic with dbus-monitor while I start Empathy, send a few messages, and quit. Let’s see if there is any surprise. dbus-monitor generated a 13MB text file containing 8313 D-Bus messages:

• 2850 method calls
• 761 methods returns
• 4699 signals
• 3 errors

The number of method calls and method returns are quite different! This is because dbus-monitor doesn’t record method returns from the bus driver (org.freedesktop.DBus, implemented by dbus-daemon). Indeed, my log file contains 2066 method calls to the bus driver:

• 1291 AddMatch
• 683 RemoveMatch
• 50 GetNameOwner
• others non significant calls

Method calls for D-Bus match rules (AddMatch/RemoveMatch) generate a lot of traffic. The test was done with the upstream dbus-glib 0.88-2.1, without the patch on DBusGProxy (Bug #23846) to have per-member match rules. If that patch was applied, the number of D-Bus match rules could be even bigger.

If the D-Bus match rules were implemented with socket filters on multicast Unix sockets, AddMatch and RemoveMatch messages would be completely replaced by the system call setsockopt(), reducing the number of context switches from D-Bus peers to dbus-daemon. But the situation could be improved with the current dbus-daemon implementation: 628 AddMatch are match rules on NameOwnerChanged (48%), generated by dbus-glib, but there is actually only 25 unique match rules. The duplicate match rules are caused by Bug #33646 on DBusGProxy.

Performance depends on the size of message

Now, let’s have a look on the size of messages and the impact on performances. I can use dbus-ping-pong to estimate how long it takes to send a D-Bus message with a specific size. The following script starts the ping-pong messages between two D-Bus peers, with several message sizes, and I gathered the results in the next graph:

#!/bin/bash

./dbus-ping-pong server org.Echos &
PID=$!
echo "Server is PID=$PID"
sleep 1

for i in 1 3 10 31 100 316 1000 3162 10000 31622 100000 316227 1000000 3162277 10000000 ; do
  echo $i
  ./dbus-ping-pong client org.Echos 100 $i
done

kill $PID

Figure 1

I ran the test twice with different values of max_bytes_read_per_iteration, the size of the buffer used to read on the socket; the first time with 2048 bytes and the second time with 65536. When the read buffer is 32 times bigger, there is less recvmsg() system calls for big incoming D-Bus messages and it makes the test 28% faster.

Usual message sizes in Telepathy

Let’s see what are the usual sizes of messages in the context of Telepathy. I just run bustle-dbus-monitor with a patch to get the size of each message (Bug #34067).

Figure 2

Most messages are between 101 bytes and 316 bytes (in orange on the graph).

With piecewise linear interpolation (spreadsheet source) based on the results of dbus-ping-pong, I can approximate how long takes the transmission of each individual message, and then what size of messages are the bottleneck and would be worth optimizing.

It may not be a good estimation because there is more computation in the real Telepathy scenario than in the synthetic dbus-ping-pong scenario: the number of match rules in dbus-daemon is different, there is more connections, and the Telepathy processes are not only sending D-Bus messages so the CPU caches are not behaving the same way. The real time spent in D-Bus communication should be larger than what is computed here with piecewise linear interpolation. But it can still give an idea.

Figure 3

For messages with a small size (under 3000 bytes), the two histograms (figure 2 and figure 3) have the same shape because the ping-pong time is almost constant for those messages. For the larger messages, they take a bit more time than their distribution because the ping-ping time is getting bigger on those messages.

Messages between 101 bytes and 316 bytes are the ones causing the most delay in Telepathy start-up.

The Stats interface

We can look at those messages in more details with the new Stats interface in dbus-daemon. The script messages_stats.py creates a csv file from the Stats interface containing the peak size of messages, the peak number of recipients and number of each D-Bus method call and signal. With that data, I can check that no messages from Telepathy are received too broadly, and if they are, I could use the GetConnectionMatchRules patch to find the application which subscribes to a too broad match rule.

Most of the D-Bus messages generated by Telepathy have a reasonable number of recipients. Only 2 different D-Bus signals have more than 3 recipients, and it is only a few messages in total:

• org.freedesktop.Telepathy.Connection.Interface.Aliasing.AliasesChanged (4 recipients)
• org.freedesktop.Telepathy.Connection.Interface.SimplePresence.PresencesChanged (4 recipients)

Figure 4

The most sent D-Bus messages by Telepathy are:

• org.freedesktop.Telepathy.Connection.Interface.Contacts.GetContactAttributes (17 calls)
• org.freedesktop.Telepathy.Account.AccountPropertyChanged (11 signals)

I don’t see anything obviously bad here. Telepathy is a good D-Bus citizen!

19 December 2011 à 18:18

I have been working on implementing multicast Unix sockets in the Linux kernel. This allows a process to send a message on a socket to a multicast group with one system call sendmsg() and the message will be received by all sockets member of the multicast group.

This work has been sponsored by my employer Collabora.

Several projects could benefit from this new IPC system:

1. D-Bus
   
   D-Bus is a message bus system. Applications exchange D-Bus messages traditionally through a central process, dbus-daemon. When dbus-daemon receives the message, it determines the recipients and delivers the message to each recipient’s socket. This architecture causes dbus-daemon to wake up for every single message causing expensive context switches, memory copies and processing. If the D-Bus peers were part of a multicast group, the kernel could deliver D-Bus messages directly to the recipients. It could use socket filters to deliver them only to the correct recipients, according to the D-Bus match rules.
2. The T IPC system
   
   In the same manner as D-Bus, multicast Unix sockets and socket filters could be used by the T IPC system.
3. Udev
   
   Udev uses Linux’ netlink sockets to send multicast messages from udevd to libudev listeners. Netlink sockets are usually used for communication between the kernel and userspace, but can also be used for userspace-only communication. It has limitations though; there are only 32 multicast groups, system-wide, and only root can send multicast messages.
   
   Update: netlink does not have that limit anymore since 2005.

My implementation aims to be a general purpose multicast IPC system, without the limitations of netlink multicast. The kernel patches and a test suite are available in git:

git clone git://git.collabora.co.uk/git/user/alban/linux-2.6.35.y/.git unix-multicast18

git clone git://git.collabora.co.uk/git/user/alban/check-unix-multicast

Multicast is implemented on datagram and seqpacket sockets, but not on stream sockets. It would not make sense on stream sockets because the messages are not delimited and there would be no guarantee that several senders’ messages would not be mixed. The semantics are different between datagram and seqpacket sockets.

Multicast on datagram sockets

The setsockopt() call which creates the multicast group binds the socket on the multicast address. Messages sent to the group are received by all members, including the sender, if it joined with the “loopback” feature. Socket filtering may be used by a recipient to avoid receiving messages, however this does not affect delivery of the message to other peers in the group.

The daemon controlling the multicast group can receive the messages from the peers if the feature “send-to-peer” is enabled.

Multicast on seqpacket sockets

 

Seqpacket sockets are connection-based and the daemon can control who is able to join the group. The daemon can receive the messages from the peers on its accepted sockets (A1, A2, A3 on the diagram above) with the “send-to-peer” feature. It is useful for D-Bus: dbus-daemon can reply to the method calls on the bus driver.

Socket filter for D-Bus

Each socket can upload a socket filter (or Berkeley Packet Filter, BPF) in the kernel. Socket filters are small programs, executed for every message sent to a socket. If the socket filter returns zero, the message is discarded and the process does not need to wake up.

The socket filter could be modified and uploaded in the kernel every time the D-Bus peer wants to add or remove a D-Bus match rule and get or lose a unique or well-known name. So D-Bus messages are not delivered to every D-Bus peer but only the right recipients.

Socket filters may be applied on SOCK_DGRAM and SOCK_SEQPACKET only. They make little sense on SOCK_STREAM because there are no message boundaries. This limits the size of D-Bus messages to about 110kB, although it can be changed with setsockopt(SO_SNDBUF) up to a maximum of 219kB (or more by tuning /proc/sys/net/core/rmem_max).

Atomic delivery

Messages are delivered atomically to all recipients. This is true even when the sender is interrupted by a signal, killed, lacks memory or is blocked because of the flow control. I don’t want a message to be partially delivered to some recipients. When the system call sendmsg() returns an error (such as EAGAIN), it is guaranteed that nobody received the message.

Ordering

When several senders are sending messages concurrently, the recipients need to receive messages in the same order. Here is a scenario I want to avoid:

A and B are sending one message concurrently to recipients C and D. Without proper locking, the recipients could receive the messages A and B in a different order. My patches take care of this and the test suite checks that messages are received in the same order by all recipients.

Flow control

When a reader is too slow to consume messages from its receiving queue, the receiving queue could be full. There is several ways to manage this situation:

• Have infinite sized receiving queues. This is not really an option, is it?
• Drop messages, either silently or with a notification to the recipient (”you have lost some messages”). This is the correct semantic for udev. Netlink sockets notifies recipients about lost messages with ENOBUFS in recvmsg(2).
• Block the sender. The sender will block or send() will return EAGAIN with non-blocking sockets. Poll() or select() will tell when a message can be delivered again.
• Disconnect the slow recipient
• Disconnect the spammy sender

The correct solution for D-Bus is not trivial. This is not a new problem: even without multicast Unix sockets, dbus-daemon already has the same problem. Discussion in bug #33606. The current implementation of multicast Unix sockets either drops messages silently or blocks the sender, depending on the setting of the multicast group.

19 December 2011 à 18:18

In the last few weeks at Collabora, I worked on having D-Bus directly in the Linux kernel to improve its performances. I based my work on what Ian Molton did. For now it’s just a prototype, but some benchmarks I did show a good performance improvement.

The cost of context switches

When an application sends a message on the bus to another application, the message is first sent to dbus-daemon through an Unix socket. The kernel copies the message to the receiving queue of dbus-daemon and dbus-daemon wakes up. Then dbus-daemon adds the sender field in the header of the message, and sends it to the recipients according to the destination field and the match rules (usually one recipient but there could be more for signals or in case of eavesdropping).

D-Bus message transmission with dbus-daemon

So dbus-daemon wakes up on every message, it costs a context switch and a memory copy.

Don’t wake up, dbus-daemon!

The idea of D-Bus in the kernel is to deliver the message directly to the right recipients without waking up any intermediary process. We added a new kind of socket, “AF_DBUS”, that behaves in a similar way to Unix sockets. Every application using DBus would need to use the new socket type, but that just means changing libdbus and the few other libraries for D-Bus.

Introducing AF_DBUS

The kdbus kernel module reads all the messages and check for the messages “Hello“, “NameAcquired“, “NameLost” and “AddMatch” to get to know the unique names, the well-known names and the match rules. Then it is able to deliver the messages only to the right applications and shortcut dbus-daemon. If there are several recipients, the message is still memcpied only one time thanks to skb_clone().

AF_DBUS does not wake up dbus-daemon unnecessarily

The prototype still uses dbus-daemon for authentication and D-Bus activation. The bus driver org.freedesktop.DBus is still implemented in dbus-daemon.

New performances

The first benchmark is dbus-ping-pong. It is a simple tool to call a D-Bus method and wait for the reply 10000 times. I tried it both on a KVM/i386 virtual machine and on a N900/arm.

• KVM/i386, without kdbus: 3.887s
• KVM/i386, with kdbus: 2.085s (x1.8)
• N900/arm, without kdbus: 28.00s
• N900/arm, with kdbus: 9.23s (x3)

I tried Adrien Bustany’s benchmark tool designed with Tracker in mind. My test is on KVM/i386 with #define CHUNK_SIZE 8 in order to have D-Bus messages of 6905 bytes (the kdbus prototype has a limitation at the moment: messages bigger than SKB_MAX_ALLOC or 8kB are still delivered to dbus-daemon so it does not bring better performances).

• KVM/i386, without kdbus: Fetched 300000 rows in 32874ms
• KVM/i386, with kdbus:Fetched 300000 rows in 24368ms (26% faster - x1.35)

I also tested how long does a N900 take to connect to Jabber and show my contacts’ presence on the desktop widgets. I measured the time manually but ran enough tests to be sure it is consistent.

• N900/arm, without kdbus:  avg 11.87s
• N900/arm, with kdbus: avg 10.56s (x1.12)

Sources

Keep in mind this is only a proof-of-concept. It is not ready for merging and has limitations, including security ones. However,  I managed to use kdbus for both the system and session bus on a N900 and, with just a few hacks, everything worked fine.

• libdbus-AF_DBUS.patch allow AF_DBUS sockets in libdbus
• libdbus-system-bus-address.patch if you want to try kdbus on the system bus
• linux-2.6.35.y git tree with the kdbus branch

19 December 2011 à 18:17

Due to unintentional behavior breakage in the newest versions of GUPnP and GSSDP, the UPnP NAT traversal in all VoIP applications that use Farsight2 is currently broken. This includes Empathy, Pidgin, aMSN, etc. I advise distributors to just stay with the older GUPnP 0.16 (and GSSDP 0.10) releases until this is sorted out. For those who care, the details are on bugzilla.

Update: I’ve released GUPnP-IGD 0.2.1 that works around these problems.

14 November 2011 à 15:18

I must admit that I’ve never been a big fan of the dash as /bin/sh change. I have three main problems with the switch:

POSIX compliance as an argument

Complying to standards is a really good thing. But when everybody is ignoring the standard because they want the comfort of newer features, maybe it’s a sign that the standard should be updated to include those newer features. Most of the bashims used everywhere in scripts were signifiant improvements, like the ability to write:
cp {short1/path1,short2/path2}/very/long/common/path/to/a/file
instead of:
cp short1/path1/very/long/common/path/to/a/file short2/path2/very/long/common/path/to/a/file

The option to improve bash was not fully explored

We started with the premise that bash is bloated, slow, and cannot be improved. Maybe you can help me with that, but I could only find a few simplistic benchmarks comparing dash and bash, and I could not find any analysis of why bash is slow, and why it cannot be improved.
One of the obvious problems is that bash is also an interactive shell, and is linked to ncurses and terminfo, which increases the startup time. But have we investigated the possibility to have a /bin/bash-non-interactive binary that would not be linked to ncurses?

The change was brought to users

While it is OK for Debian (or Ubuntu, in that case, since that change was done in Ubuntu first) to force its developers to use POSIX-compliant scripts, the switch could have been made only to Debian-created scripts (by switching them from a /bin/sh shebang to a /bin/dash shebang, for example). I have trouble justifying that this change was forced on users as well.

Next: linker changes

… and we are doing it again. A set of linker changes (see also the Ubuntu page) was already done in Ubuntu, and is very likely to be done in Debian as well. This switch requires deep changes in some buildsystems (it requires ordering of libraries and forbids indirect dependencies), and is rather painful (it was reverted before the Ubuntu 11.04 release because it was not possible to fix all the packages during the natty release cycle, but is done in the 11.10 release). Of course, there are justifications for this change. But I’m not sure that it’s worth all the trouble created for users.

06 November 2011 à 10:05

At the end of last week, we unleashed RC1 of our next openSUSE release (12.1, scheduled for November 16th), and it comes with GNOME 3.2.1, which went out only a couple of days before RC1. Go grab a live image if you want to play with either openSUSE or GNOME 3 :-) There are still a few bugs here and there to iron out, but overall, the experience is very solid!

"I upgraded to openSUSE 12.1, and this dramatically improved my life!" — Anonymous

It really feels good to have this openSUSE release nearing, as we missed the GNOME 3.0 boat (openSUSE 11.4 was released one month before GNOME 3.0): I, and I assume a few others, felt that we were stuck in the past with GNOME 2 in our world for so long. Sure, the work on backporting GNOME 3.0 and then 3.2 to openSUSE 11.4 helped, but we really wanted to share what was in Factory... Especially as there was really a lot of work to properly integrate this new GNOME.

I'm obviously really glad to see the GNOME 3 love in openSUSE, but looking back at the last few months, what is even greater to me is that we got many amazing people contribute to the GNOME team through-out this cycle. I'm sure I'll forget some of them (apologies for that, let me know so I add your name!), but here's a quick list:

• Atri Bhattacharya
• Bjørn Lie
• Casual J. Programmer
• Dominique Leuenberger
• Frédéric Crozat
• Gary Lin
• Guido Berhörster
• Joey Zheng
• Kirill Kirillov
• Malcolm Lewis
• Nelson Marques
• Richard Brown
• Sankar P
• Scott Reeves
• Stephen Shaw

Their various contributions include updating packages, fixing bugs, testing, polishing the experience, supporting users, providing ideas, and more! Go ahead and thank those people when you meet them (virtually or in the real life): they all make the GNOME team rock! And who knows, maybe next time you'll also be one of those rock stars?

24 October 2011 à 20:03

I happen to go to Berlin next week, and it seems a awful amount of other people are going too (including the evil twin). I wonder why so many people. Maybe they all want to listen to my ramblings on Monday just before the lunch break, or attend a dream team session later on the very same Monday, about upstream and downstream and co-presented by Allison Randal, Jaroslav Řezník, Harald Sitter and yours truly.

Of course, this could also be because of the FreeFA Tournament, sponsored by SUSE this year. This football game is always one of the highlights of our summer events, and I must admit I can't wait to see Bastien give it another try.

However I don't see any ice cream deathmatch in the program. This is rather unfortunate, but I guess Diego was way too afraid of trying again anyway... Or maybe the true Lennart voluntarily sabotaged this?

21 October 2011 à 16:08

While everybody is talking about going to some small event apparently occurring in Berlin next week (with random speakers), let me talk a bit about the RMLL 2011, which I attended a few weeks ago.

Close-up of the Strasbourg astronomical clock

For those who don't know, the RMLL is one of the main free software-related events in France. It's moving to a new city every year, and this year it happened to be Strasbourg. Obviously, this was a good choice since everybody knew that it would involve great food :-)

At the end of the RMLL in 2010, Michael Scherer suggested to organize a new track about Communities, and we were crazy enough to give it a try, with the help of another Vincent, Vincent Kaltenbronn. We managed to get a rather good program: we wanted to have some international outreach on the first day (english talks, and an interesting talk about an initiative related to Africa), a day specific to the french world of Free Software on the second day, and then talks about various projects on the last day. And it all turned out pretty well, thanks to the speakers!

While we had many GNOME-friendly people at the event (Frédéric, Claude, Alexandre, Didier, Michael, etc.), we didn't really have a proper booth as most of us were busy either with the organization of the event itself, the chairing of a track, the preparation of talks or the participation to Radio RMLL. But we still had PromoDVDs to give away (thanks openSUSE!), and apparently, people were happy to take them :-) We still managed to have a meeting to discuss the future of the GNOME-FR organization, and the good news is that there is a plan. Frédéric also had a talk about how the GNOME project changed in time, where people actively participated in a discussion about current issues in the community, with the discussion ending well after the end of the talk.

Illuminations of the Strasbourg Cathedral

It was also great to see the openSUSE presence there, with Jean-Daniel Dodin organizing the openSUSE part of a booth shared with Fedora and Mageia, and Alexis Guéganno sharing his Alionet experience while talking about non-profit organizations.

As I apparently can't go to an event without delivering talks (I keep submitting tons of proposals...), I had three talks scheduled: a brief introduction to packaging, an overview of GObject Introspection and a status update on the AppStream project. The three talks were well-received, or at least that's what I like to think :-) And during the GObject Introspection talk, a GSoC student working on MELT suggested the use of MELT to help make sure introspection annotations are correct; I didn't have time to take a close look at that, but that does sound like a fun project.

Fireworks during Bastille Day

Since the event ended on Bastille Day, I was able to stay a few days in Strasbourg to enjoy the city. There's no shortage of good time there, and it was funny to meet every now and then other RMLL participants who also stayed the week-end. The various illuminations organized by the city for the summer were extremely cool, and I felt I really had to make sure there was no missing step in the stairs to the top of the Cathedral. Interestingly, there seems to be less steps when going down than when climbing!

Oh, and I should do that more often, but thanks to SUSE for letting me go and participate to this event (and even encouraging me to do so)! That's really a cool company :-)

21 October 2011 à 16:08

Early last month, we had a GNOME-FR annual general meeting. It was a while since the last GNOME-FR meeting, and it felt good to get things moving forward again! For those who don't know, GNOME-FR is the french-speaking non-profit organization (association loi de 1901, to be exact), and while it's not the most active organization, it's quite useful to help organize the GNOME presence at events — usually french-speaking events, but also international events (like FOSDEM, for which GNOME-FR handles the t-shirts and more, since a bootstrapping fund given by the GNOME Foundation a few years ago).

We mostly discussed administrative details, like changing bank, relocating GNOME-FR to a new address (thanks to Frédéric Crozat for hosting it until last month, and thanks to Didier Roche for being the new host!), and updating the by-laws. You can go read the minutes (in french, obviously) if you want the details.

The real news is that we got a new GNOME-FR board (and new officers, obviosuly):

• Alexandre Franke (treasurer)
• Luis Menina (secretary)
• Baptiste Mille-Mathias (president)
• Claude Paroz
• Frédéric Peters
• Didier Roche (vice-president)

They are all people caring very much about GNOME, and it's great to have them in the board! Congratulations!

What makes me even more happy about this board is that we have people from Belgium, France and Switzerland: this really reflects the fact that we have people from different countries in the french-speaking community. And arguably, Alexandre could be considered German! ;-) Obviously, this board doesn't have as many tasks to deal with as the other board, but it's nonetheless important to me to know that GNOME-FR is in good hands!

And who knows, maybe GNOME-FR will participate again to a bid to host GUADEC or the Desktop Summit in 2013?

19 October 2011 à 13:16

Windows has a feature called Dynamic Disks, which makes it ignore the DOS partition table and manage partitions its own ways. gparted is supposed to detect that, and warn the user that it can’t deal with that. The solution is to reboot in Windows, switch the partition back to “Basic disks”, and then proceed with installing Debian (or Ubuntu).

However, a student of mine had an interesting experience because gparted did not detect the dynamic disk stuff and did not warn about it, so the student went ahead with installing Debian squeeze. After reboot in Windows, Windows sees the partition as “invalid”. The same happens with Ubuntu 11.04 (not really surprising).

I’m surprised I did not find much information about that issue. Does someone has more info ?

The student was using two disks in his laptop, and only the second one (not the one used to boot windows) was using “dynamic disks”.

22 September 2011 à 08:35

I must admit that I’m a bit lost about the conclusions of the Don’t fear the fsync()! (lf.org down; google cache) debate. My understanding was that using fsync() was the right thing to do when we cared about data being written to disk.

When using cp or tar, I usually care about my data being written to the disk, so why don’t they use fsync()? Shouldn’t they?

13 September 2011 à 17:01

Retour en Californie, et départ de San Luis Obispo (rien à voir avec le chanteur, bien évidemment, Obispo signifiant évêque en espagnol) après une soirée sympathique au marché suivi d'un bon petit resto et d'un petit café (avec un gâteau au chocolat végétalien étrangement bon) : autant dire que nous sommes au taquet pour cette dernière journée avant notre retour dans mon home sweet home.

Et nous commençons par la visite de Hearst Castle, la deuxième attraction de Californie après Disneyland ! Désormais géré par les parcs nationaux, il s'agissait auparavant du domaine d'un magnat de la presse du début du XXème siècle : William Heart. Monsieur Hearst est très riche, adore la Californie (au contraire de sa femme qui préfère la côte est) et a visiblement un penchant pour la démesure. et tout ce qui vient d'Europe et qui a un peu plus de 200 ans. Résultat : une sorte de château avec une soixantaine de chambres, environ 80 salles de bains, plusieurs piscines, un court de tennis et une salle de cinéma, où il projette à ses invités chaque soir les films dans lesquelles son amante - Marion Davies (célèbre actrice du cinéma muet, qui bizarrement n'a pas réussi sa transition au cinéma parlant, probablement parce qu'elle souffrait de bégaiement dans sa jeunesse) - juste après leur avoir servi de copieuses doses de café (car voir les mêmes films, à force, ça endort).

(Source : Wikicommons)

Visiblement, la démesure et l'argent ne vont pas forcément de pair avec le bon goût, et malheureusement pour Hearst, Valérie Damidot n'est pas encore disponible, si bien que l'intérieur du château est un joyeux mélange de vieilleries et de mobiliers contemporains. Avis aux amateurs de baroque !

Le domaine, situé en haut d'une colline, offre aussi une magnifique vue sur l'océan et sur les terrains environnants qui servent de pâturage aux Black et Red Angus, ainsi qu'aux zèbres (derniers reliquats du zoo personnel du magnat).

Mes quelques photos du château

02 September 2011 à 14:00

Comme tout Road trip qui se respecte, le passage par la route 66 est obligatoire (même si nous n'en avons parcouru que quelques dizaines de kilomètres sur les 4000 qui séparent Chicago à Los Angeles)!

02 September 2011 à 14:00

Suite de mon périple avec mes touristes alsaço-lorrains, et direction le Grand Canyon après avoir traversé le Nevada (et une pause à Las Vegas) pour rejoindre l'Arizona et la rive sud (ou South Rim), où se situe le Parc National.

Pour les amateurs de chiffre, le grand canyon fait 450km de long (surface : 5000km²), a une profondeur moyenne de 1300m (mais atteint 2000m par endroit) et une largeur comprise entre 5 et 30km (enfin pour les oiseaux. En auto, il faut 230km). En été, en haut du canyon, la température y est plus agréable (aux alentours de 30°C) mais en bas du canyon, elle passe facilement les 40°C (et ne comptez pas sur le fleuve Colorado pour vous rafraichir).

Pour les autres, le grand canyon, c'est... juste.... énorme !

Bon, là, c'est sûr, on peut pas dire que j'ai fait dans l'original et le descriptif (même si on peut dire que j'ai capturé l'essence du parc), mais c'est difficile à transcrire en mots. Pour ma part, j'ai craqué sur les couleurs, ce mélange d'ocre, de rouge et de vert, en couches bien alignées (causées par les différentes périodes géologiques). Et quand on surplombe le canyon, on ne se lasse pas de tout ces méandres de roches, et de se demander comment tout cela s'est déroulé (certes sur plusieurs millions d'années).

La suite en photos...

26 August 2011 à 14:00

Juste après Yosemite Park, se trouve un autre parc national nommé Sequoia Park, qui contient bien évidemment des Séquoias, mais pas n'importe lesquels, puisqu'il s'agit de Séquoia Géants.

Le séquoia géant (que l'on ne trouve qu'en Californie) est grand avec ses 80 mètres, mais n'est pas l'arbre le plus grand du monde, et vit longtemps (environ 3000 ans) mais fait petit joueurs comparé à d'autres espèces qui atteignent 8 à 10 millénaires. En fait le sequoia géant se distingue surtout par sa largeur, en général 6 à 8 mètres de diamètre (et une croissance comparable à la croissance humaine : d'abord une croissance verticale durant sa jeunesse, puis une croissance horizontale avec l'âge...)

Son représentant le plus connu, abrité au cœur du parc est le général Sherman : le plus gros arbre au monde : 1487m³ (pour comparaison : une piscine olympique = 2500m³)

(Général Sherman, par Jim Bahn)

Dans ce parc national (qui comprend aussi King's canyon), il n'y a pas que des arbres à regarder, il y a aussi de magnifiques points de vue sur la vallée traversée et sur les montagnes environnantes.

Le reste des photos est disponible sur Flickr avec celle de Yosemite

21 August 2011 à 19:41

(titre en hommage à cette publicité)

Une fois mes amis reposés et remis du décalage horaire, et après le traditionnel pèlerinage à San Francisco, son pont dans la brume, ses rues tortueuses et ses moyens de transport à la pointe de la modernité, cap sur Yosemite, l'un des plus fameux parcs nationaux de Californie.

Que dire sur Yosemite ? C'est grand, très grand ! C'est en fait le troisième parc national des États-Unis par la taille (environ 3000 km² soit 300 000 hectares), et aussi l'un des plus visités du pays. Forcément, les routes principales sont du coup taillées grand public (comprendre goudronnées), mais en s'éloignant un peu, on retrouve assez vite l'aspect sauvage qui est censé être le sien (Et en ce qui concerne l'empreinte écologique, les choses s'améliorent. Le parc vient d'installer le plus grand parc de capteurs solaires : 2800 panneaux qui représentent 12% de l'énergie consommée par le parc).

De notre côte, nous l'avons un peu joué touriste de base en nous baladant entre les différents sites comme Granite Dome et Liberty Cap:

Nous nous sommes fendues de plusieurs randonnées:

• petite balade autour de mirror lake

• grimpette pour admirer les chutes Vernal et Nevada

Pour l'hébergement, nous avons opté pour l'auberge de jeunesse ! Chambre individuelle, et petit café proposant des petits plats sympathiques mitonnés avec les légumes du jardin (mention spéciale pour le risotto du 1er soir : une pure tuerie, et le pancake aux bleuets était à tomber).

Le reste des photos est disponible sur Flickr

08 August 2011 à 04:46

Bienvenue à mes premiers invités, Agathe et Fabrice !

Ils sont venus de l'Est (de la France) avec plein de petits cadeaux, merci à eux mille fois encore.

Bon, en réalité, parce que nous avons passé deux semaines à rouler sur les routes américaines (et parce que je suis aussi très lent à mettre à jour mon blog), ils sont déjà repartis en France, mais par la magie de l'article différé, vous allez pouvoir suivre mes pérégrinations dans les parcs nationaux américains.

A suivre donc...

08 August 2011 à 03:59

Just like everyone else on Planet GNOME,

You are all cordially invited to my talk: Improving the quality of video calls on the Free Desktop. I will try to explain why Skype’s video calls look so much better than ours and what I’ve been doing to fix it, and how there is much more to do.

Now that WebRTC and RTCWeb are coming, it is more critical than ever that we can have good quality video calls in the GNOME platform so we can stay relevant.

I’d also like to thank my employer, Collabora, for once again sponsoring my trip. And don’t forget the Collabora party on Tuesday night!

05 August 2011 à 08:55

So, the fifth Debconf I’ve had the chance to attend is clearly over now. It was great, and all organizers (and sponsors) really deserve huge “thank you” for making this event so successful. I’m already looking forward to next year’s edition.

Debconf has been very productive for me. I chaired 4 sessions:

• the usual Quality Assurance BOF, which was a bit depressing: even if work gets done, the QA “team” doesn’t really feel like a “team”. Maybe that’s because a QA “team” is not needed, and we should instead split it into smaller teams focusing on subsets of the QA work (archive-wide testing, QA services, etc.)?
• a BOF on Ruby, where I demoed the work we have been doing around gem2deb, our new dh-based packaging helper [Ruby team website]
• a tutorial on archive testing, hoping to get more people involved in tests such as archive rebuilds. If you are interested in helping with reporting bugs, please drop me an email [doc about archive tests on wiki.d.o]
• a BOF on finding a ‘standard’ Git workflows for packaging teams. More work is needed on this, but it looks like a good start. [thread on -devel@, wiki page, BOF notes]

I’ve also made numerous uploads of Ruby-related packages, and reduced my backlog on UDD to a reasonable level. I even managed to make a developers-reference upload, integrating all the pending patches from the BTS.

In other news, I’m very excited about the recent progress on expo.debian.net (a mentors.debian.net replacement), which could help streamline our sponsorship process.

01 August 2011 à 13:10

The third openSUSE Conference will occur on September 11-14, and there are only a few days left to submit a talk: the call for papers is open until next Monday! So don't think twice, and go submit something now. If you really want to think twice, take a look at our guidelines for speakers, they should convince it's worth the effort!

There's a change this year: after thinking about how we could improve the conference, we decided that we wanted a stronger focus on smaller and interactive sessions. We describe this as read-write. But we also want to be ready to execute the results of those discussions, hence the execute bit. This is why we ended up with rwx, which might sound familiar. And since we want this for each of us, for our community and for the rest of the world, rwx³ is our motto for this year. Yes, it's geeky, but hey, this is also part of our identity ;-)

Since I really like this change in focus for this year's conference, I decided that I would not submit a talk, but only BoFs and workshops.

What about you? What will you submit?

08 July 2011 à 13:56

Next week, I’ll head to Strasbourg for Rencontres Mondiales du Logiciel Libre 2011. On monday morning, I’ll be giving my Debian Packaging Tutorial for the second time. Let’s hope it goes well and I can recruit some future DDs!

Then, at the end of July, I’ll attend Debconf again. Unfortunately, I won’t be able to participate in Debcamp this year, but I look forward to a full week of talks and exciting discussions. There, I’ll be chairing two sessions about Ruby in Debian and Quality Assurance.

04 July 2011 à 18:05

Ca y est, aujourd'hui, et pour la première fois, je suis allé voir un docteur. C'est donc pour moi le prétexte tout trouvé pour vous expliquer un peu le système de santé américain.

La première différence avec la France, c'est qu'il n'y a pas d'organisme central géré collectivement par l'État, des employeurs et des syndicats des cotisations pour procéder au remboursement des dépenses de santé : à la place, il y a un système décentralisé où l'État américain verse une enveloppe à chacun des états, qui gèrent plus ou moins différemment leur propre système de soins. Autre différence, pas de système obligatoire de cotisation (contrairement à la retraire), chacun est libre de choisir ou non et selon sa situation personnelle comment il prendra en charge ses dépenses.

Pour les personnes âgées et les plus démunis, il existe deux programmes gérés par l'État : ce sont Medicare et Medicaid : l'État prend en charge les dépenses, et reste à la charge de l'assuré la franchise ou copay en anglais.

Pour la grosse majorité des gens en revanche (75% de la population américaine), ce sont des assureurs privés qui prennent en charge les dépenses de soins : l'idée étant probablement que le marché est le meilleur moyen de réguler les prix et in fine profiter à l'assuré/consommateur. Malheureusement la réalité ne rejoint pas la théorie, et seuls 10% ont les moyens de s'assurer directement, quand 16% de la population n'a aucune assurance. En fait, pour la plupart des gens, le seul moyen d'obtenir une couverture santé est de travailler dans une entreprise proposant une assurance à ses employés (tous les employeurs de plus de 25 salariés sont tenus par ailleurs d'en offrir gratuitement à leur employés).

Ces assurances santé, comment sont elles organisées ? Généralement elles proposent plusieurs types d'assurances. Le plus basique est le HMO (Health maintenance organization) : l'assuré a accès à à peu près tous les soins à condition de consulter uniquement des praticiens appartenant au réseau de l'assurance. Assez restrictif donc. Pour ceux qui sont prêts à mettre un peu plus la main à la poche, il y a les PPO (Preferred provider organization) qui permettent de sortir du réseau voire de s'en affranchir totalement, selon les options.

Et donc c'est tout ? pas vraiment... les contrats sont assez complexes dans la forme et dans le fond (en tout cas, quand j'ai du choisir le mien, cela n'a pas été évident, et ça s'est fini en "lisant les grandes lignes et faisons confiance aux amis"), et surtout le système de franchises est particulièrement plombant, et peut vite revenir assez cher. Par exemple mon assurance a un copay de 15$ pour une consultation chez un généraliste, et de 5$ par boîte de médicaments si ce sont des génériques (c'est bien plus si c'est la marque originelle, sauf s'il n'y a pas encore de générique disponible, dans ce cas c'est juste un peu plus...). Copay veut dire de ma poche ! Et là je vous entends d'ici : Kwwwwwaaaaa ? 15$ à payer sur une consultation c'est énorme !!! 5$ de copay sur une boite de médicament, mais c'est l'arnaque ?. Oui, ça sent l'arnaque mais bon, la consultation chez un généraliste coûte facile entre 100 et 200$, et ma boîte d'antibio classique pour 5 jours passait à 40$ en caisse...

C'est probablement là le problème du système de soins des États-Unis (enfin, c'est mon analyse personnelle à 3 francs six sous) : dans son souhait d'intervenir le moins possible dans son système de santé, le gouvernement laisse libre court aux laboratoires et les assurances (et peut être aussi les praticiens dans une moindre mesure) de fixer les prix. Or le but principal de ces entreprises reste quand même de gagner de l'argent, elles se sont relativement consolidées si bien que la concurrence ne joue pas vraiment, et les prix restent finalement élevés. Parmi les pratiques (observées ou rapportées par d'autres français, je ne me soigne pas si souvent que cela) :

• les mêmes médicaments sont très souvent bien moins cher au Canada qu'aux États-Unis (et donc il existe des sites de vente par correspondance livrant aux US). Bien sûr acheter ses médicaments au Canada n'est pas remboursé, mais en faisant le calcul avec le copay, il est possible d'y gagner facilemement.
• les laboratoires pharmaceutiques proposent des coupons à télécharger pour certaines de leurs spécialités, afin de réduire le copay !
• certains praticiens effectuent des examens en plus non pris en charge, et te proposent de payer pour en connaitre les résultats (style, tiens je te fais un examen de l'oeil avec ma super machine. Maintenant, tu peux payer pour que je te donne les clichés ou alors, je peux te faire gratuitement le même fond de l'oeil mais old-school avec les gouttes qui piquent !)

Bref, un peu le bordel à comprendre (surtout quand tu as déjà du mal à expliquer tes symptômes en anglais), mais au final je fais partie des ces privilégiés dont l'employeur prend en charge la couverture de ses employés.

Pour ceux qui veulent en savoir un plus, il y a bien sûr wikipedia, mais aussi cet article de Rue89 sur la réforme portée par Obama (qui ne change pas fondamentalement le système mais rend un poil plus facile l'accès aux soins pour ceux qui en étaient exclus).

04 July 2011 à 00:20