So, Waldi filed #545032, arguing the udev rules shipped in devicekit-disks are broken. He even added a conflict in dmsetup because of that. Whenever you ask him about this issue, the only things he answers are:

• The rules are broken and they need to be removed.
• The information is already available in other variables.

It would be nice if all of this was true, but:

• There is no explanation about how and why these rules could actually break anything.
• The information is not available in other variables, apart from a couple of trivial things. Or maybe it is, but since all that udev crap has absolutely zero documentation, there is no way to know how it is available.

The result: GNOME is currently not installable on a system with LVM. There is no foreseeable possibility to fix that. Great. Thanks.

I can’t say I’m surprised, but I’m still appalled by reading, again, a completely out-of-reality polemic about a leader of the Free software community being called sexist (among other nice names), after an innocent and random word used in a talk.

Oh noes! Serving in the navy will hurt!

It’s often that you hear jokes or references picturing French as arrogant, Italians as womanizers, geeks as bearded and smelling under the arms, sailors as gay, et cætera. It’s called a cliché, and it helps people understand each other because it’s part of the collective imagination. If you insert a reference to an Italian in a speech about womanizers, it helps picturing the cliché of a guy in a black Armani suit, wearing sunglasses and using gomina. It doesn’t mean you think Italians are like this, and if it ever convinces someone that they are so, it means that someone really had trouble using the thing she calls brain to begin with.

The same goes for a talk about people not being familiar to computers, that is using women as a cliché. When you look for a picture in your mind of someone who has trouble with using computers, what do you find? A granny fighting with her keyboard which keys are not in alphabetical order, or a busty blonde following with her eyes each movement of the mouse cursor. It’s only natural to use these pictures as a ground for communication, and it doesn’t mean you think bad of grannies or busty blondes. And if, because of that or of anything else, some people end up thinking that women can’t use a computer, or that they are not equal to men in this regard, these people are the sexist ones. Not the guy who drew that picture in a magazine you read 10 years ago and forgot since, nor the one using it as a reference.

My intolerance is worth more than yours

And instead of actually focusing on educating or slapping those people, some of us are conducting a witch hunt, in which anyone implying the very existence of different categories of people, called men and women, regardless of his merits or opinions, is called a sexist and has stones thrown to him on several public fora. This is not acceptable. Do not let your speech be dictated by intolerance. If you apply the same reasoning to anyone that could be possibly hurt, in a completely literal and simplistic analysis of the speech, you can stop right now using any kind of metaphor, idiomatic expression or proverb. All that remains is a poor, sterilized speech. And when the speech is poor, the ideas get poorer as well.

Imagine what would a complete stranger reading those blogs understand. She would surely picture hackers as a completely misogynistic community in which people only talk about women (whether it is for sexist jokes or for rhetorical discussions about them) and never talk with them. Which would be utterly wrong, since hackers (and geeks in general) are on the contrary open-minded and friendly to feminism, compared to the rest of the population — of course, except for the “OMG OMG it’s a woman! We need to be nice!!!” kind.

And this is actually the reasoning that hides behind all this insane “RMS and Mark Shuttleworth are sexist” trolls. The picture they are giving of women are that of fragile little things that need to be protected against any attack of all these evil misogynist bearded geeks. Pretty ironical for people who claim fighting for gender equality, isn’t it?

Questioning the unquestionable

Frankly, RMS and Mark are among the people I trust the less in the community, but I don’t need to paint them as misogynists for that. Look at what they say instead of how they say it: one is an intolerant man who used to be a visionary but turned his principles into dogma; the other has seen the light and behaves as if he was the savior of Free software. I’d prefer if we questioned their vision and leadership based on their ideas and actions, not on distorted ways to interpret what they say based on a few people’s neuroses.

Or, to say it shorter: dudes, get a life.

In my haste to fix #545254, I have uploaded nautilus 2.28.0 a bit too early. If you have not upgraded yet, please don’t install 2.28.0-1!

If you have already upgraded, you should install 2.28.0-2 as soon as it is available, and then remove any ~/.nautilus/metafiles/migrated-to-gvfs files. This way you will find back your metadata (icon positions on the desktop, window sizes, emblems…) at the next login.

Sorry for the inconvenience.

Maybe this will make the anti-Mono religious zealots shut their mouth.

Summary: there won’t be any patent claims filed against implementations of ECMA 334 (C# language specification) and ECMA 335 (CLI specification) from Microsoft. Now, the whole movie-plot scenario boycottnovell imagined collapses like a house of cards.

So many wrong statements were made in the insane troll about Mono, I feel that somehow I need to write some explanations about the current situation. So far the closest post to the reality was made by Tolimar but there are still some inaccuracies in it.

Q: Will Debian squeeze include Mono and Tomboy in the default install?

A: Short answer: yes. Long answer: in the current state of affairs, the GNOME installation media (which, remember, are far from being the only ones) will install tomboy if it is available. This might change depending on the feedback of the installer team and the CD team, but currently there isn’t a compelling reason to change this.

Q: Wasn’t it excluded from lenny because of problems with Mono?

A: There were two reasons to exclude Tomboy from lenny: the size, and the lack of support for some of our architectures. It has nothing to do with anything specific to Mono.

Q: What has changed since lenny that makes this situation evolve?

A: First, the size of Mono packages and of Tomboy itself was considerably reduced, thanks to awesome work from the Debian CLI team. Second, the availability of GNote means that architectures without Mono support can have a stripped down version (although this makes the situation far from ideal for these architectures, see next question).

Q: Why not ship GNote instead by default?

A: GNote was written for bad reasons, without even respecting the GPL copyright requirements. But more importantly, its maintenance model is going to make it only follow behind the Tomboy lead, as any code changes in Tomboy will need to be translated to C++. It also supports less languages and less features. Furthermore, it was introduced in Debian for political reasons, by a maintainer who doesn’t use it and isn’t involved in GNOME maintenance.

Q: Isn’t GNote much smaller?

A: Not really. C++ bindings are larger than CLI bindings, so the only real differences are the size of the Mono interpreter, and the size of translations. In the end, Tomboy with all its dependencies is only 10 MiB larger; that includes 3 times as many translations, and some important functionality.

Q: I disagree with this decision. What can I do to change this?

A: Get yourself seriously involved in either of Tomboy development, GNOME development, Debian GNOME packaging, or the Debian installer. Then, maybe your opinion will mean more than a troll on your pet free software news site.

Q: Tomboy should use Python / Vala / Java / Parrot / Lisp / (insert here your favorite pet language).

A: The developers prefer C#. While I’d personally appreciate if they could switch to a less controversial language like Vala (mainly because it would avoid trolls), I have no right to tell them to do so.

Q: Why is there a difference of treatment between Mono and Java?

A: Because there are about 30 applications using Gtk# in Debian, several of which are among the most popular in their category, while there is exactly 0 useful application using java-gnome.

Q: Is Mono free software?

A: Yes, it is 100% free software. Just as everything in Debian, it was scrutinized by FTP masters who found it is free. Most of the code is under the GPL, LGPL or MIT licenses.

Q: Are there patent issues with Mono?

A: Just like any other software, Mono certainly infringes on thousands of stupid software patents. However the Debian policy with patents is to put them in a trash and pee on them, unless they are actively enforced with reasonable chances to win. The situation of Mono is much more comfortable than (for example) that of MP3 decoders, for which patents are actively enforced; it’s just that they are so lame that we choose to ignore them.

Q: Are there specific dangers coming from Microsoft regarding Mono?

A: Microsoft has claimed to possess patents on some Mono compatibility layers with non-standard Microsoft APIs. Not only this is completely irrelevant to GNOME, since nothing in Gtk# and related stuff uses these compatibility layers, but if you know how things work in the patent world, you already understand this is merely FUD. Microsoft has nothing, but claims to have something in order to scare consumers away from Mono. Actually, not enforcing the patents, while knowing they are violated, would make their case very weak in a patent suit. What their behavior shows is that they are very afraid of Mono. It is stealing customers from their best and most advanced product, their lead development framework. There is absolutely zero chance that they are sustaining Mono from behind, since its very existence is going to make them lose a large amount of money.

Q: Would it make Debian uncomfortable if these patents were starting to be enforced?

A: In the very unlikely situation where Mono would be found to infringe on valid Microsoft patents, we would simply have to remove it from the Debian archive. We are not short from alternatives, and it wouldn’t be long before we had drop-in replacements in Vala or Python.

Q: What is the agenda of Roy Schestowitz, Sam Varghese, Robert Millan and their friends?

A: What they are doing is giving credit to the Microsoft FUD in order to also scare consumers and developers away from Mono. They want to scare them away to other free software environments, but what they achieve is scaring people away to buy Microsoft products instead. It is tempting to conclude, because of the result, that they are employed by Microsoft underhand, but applying Hanlon’s razor, I think they are just incredibly incompetent, to the point where they are dangerous. These people are toxic to the community, and we really need them to shut up. If they ever reach their goal and destroy a great piece of free software like Mono, they will go on and find something else to destroy. Remember, their goal is to SDD: scare, disrupt and destroy. You cannot build anything useful or interesting with such goals.

Q: But Richard Stallman says they are right!

A: RMS is also the guy who wants us to ship non-free documentation. I don’t think RMS has enough connection left to the real world for his opinion to be considered relevant.

Ever noticed how the dependency fields of development library packages are tedious to maintain? They are often:

• out of sync with the build dependencies,
• outdated regarding the actual requirements of pkg-config files,
• and of course incorrect whenever libtool decides to add tons of unneeded dependencies.

In order to improve the situation a bit, I have written a debhelper script to handle development libraries and generate automatically these dependencies in a ${dev:Depends} variable, using the pkg-config information. I have requested its inclusion in debhelper, but in the meantime, I’d appreciate if people could test it against various library packages so that its potential bugs can be fixed; this could surely convince Joey to accept it faster.

Here you go: dh_devlibs.

The next step in this direction is to do some automatic validation of build-dependencies. The first approach I thought of requires some improvements in pkg-config, but given how this package is maintained, I’m afraid it will require some time. There are other possibilities involving diversions, so it is still possible that something good comes out of this.

If forums did not exist, happily we would have blog comments for entertainment.

From Jo Shields’ insightful explanations:

“Mono is a cancer that attaches itself in an intellectual property sense to everything it touches.”

“Mono serves no useful purpose to anyone other than Microsoft.”

“Fuck mono, parrot will probably end up replacing that piece of shit.”

From LHB’s link to the previous post:

“It shouldn't be a surprise to find out this crappy little blog was de Icaza's.”

“Mono is dead”

From Robert Millan’s uninformed accusations:

“It is sick and a slap in the face to the good people in Debian to tolerate such a psycho.”

“When also Miguel de lcaza stops getting checks from M$, even he will stop pushing Mono and get a life.”

“How much did Microsoft pay Joss for this? We know de Icaza is getting paid “bonuses” fro his work, so what was Joss’ paycheck?”

“I think Mono is an abomination”

“If this happen i will switch distro to slackware.”

From my previous blog entry:

“Hey whats your salery for this -Hey we all love Mono- Posting? Did Novell or Microsoft paid you?”

“Have you noticed that you are arguing from the same position as Microsoft is with Internet Explorer ?”

“An email client is not part of a Desktop.”

“These are *APPLICATIONS* and forcing me to install them is, to my mind, antithetical to the open source ideal.”

“The majority of the Debian userbase has no use for patent-encumbered microsoft-wannabe software.”

“Will somebody kick Joss a** already? Thank you.”

“ notice that you didn't contradict me, so we are in agreement that Tomboy, Fspot, and GnomeDo aren't cool.”

“I sincerely hope you drop any kind of linux and/or debian development ASAP.”

“honestly all those mono files horribly ending with .exe on Linux sucks”

“Evolution serves no useful purpose in today's world”

“As an aside, I still write programs for Messy Doss.”

“Hey, before you start packaging up software where you have no idea whatsoever why people have an issue with it […]”

“That last bit about you watching anime instead of working on that project because some journalist hurt your feelings is a concern for me. I wasn't aware children had leadership roles in Debian's future...”

“You don't know nor belong the free software movement. You should go and ask for a job at Microsoft! (lame botas de Microsoft!)”

From OSnews’ surprisingly neutral explanations about what is happening in Debian:

“And gnuplot is neither GNU nor OpenSource.”

“GNote is not a Tomboy ripoff.”

“I swear people like you are just sitting in a call center in india getting paid by microsoft to post lame anti-anti-mono crap. ”

“Or are you just copying and pasting rebuttals from a spreadsheet put together by MS's marketing/psychology department?”

“You can't just remove mono and the associated apps as this will cause problems when doing updates due to a meta package being missing.”

And of course, Boycott Novell’s troll of the day is a recommended reading for anyone wanting to get a share of fun.

And there are now some in this very blog entry! We’re going into a loop!

“After this, I do really hope they kick you out of Debian.”

“have you guys kicked out Kurt Roeckx for crippling OpenSSL? I heard he got a nice job offer from the NSA over that.”

UPDATE: we made Slashdot!

“It's just like Wine and DOSEmu: a gateway to viruses that originated on Microsoft platforms.”

“I see Microsoft having a field day with this...”

“But it's not just Microsoft's products that bloat Debian.”

“Why are this guys, which I believe have their best of interests, trying to shove up our asses a lame excuse of a programming language that basically doesn't bring anything new but license agreements, EULAs, patents to a perfectly, usable environment?”

“I can code a Tomboy like app in Python in three days...”

“Because nobody fucking wants Mono on their system!”

“Get in bed with Microsoft and you have to be careful that you don't end up with a knife in your back and act accordingly.”

“He's just a pushy immature unmannered jerk who managed to slip something in early in the development cycle.”

Let me add to this a disclaimer: if the people who want me out of the Project – for re-adding a dependency into a metapackage – volunteer to contribute to Debian, and manage during 6 months to contribute together the same amount of work I am contributing currently in GNOME packaging, I’ll happily leave the project.

EDIT: added new quotes, last addition: 16 june, 08:13 UTC.

Robert,

Unlike what you are suggesting, I’m not the one who decides what goes into the default Squeeze installation. There is most likely going to be a small discussion with the debian-installer team, like the one we went through for Lenny and which turned out very constructive. Saying that I “decided that Mono must be part of the default desktop install” is so freakingly untrue that it leaves me somehow speechless.

Of course, the real discussion around including Mono by default is not about Tomboy. If they don’t want of it, the debian-installer team just has to include GNote in the gnome-desktop task to get it by default instead of Tomboy; note that this is possible since I added an or dependency, precisely as you suggested. No, the applications that are going to make a difference are things like GNOME Do and F-Spot. If we want to include these cool applications that have no real alternative (even proprietary), this will include the Mono stack as well. And there are no stripped down C++ versions of those.

Let’s get back to Tomboy. The reason why it is now a dependency of the gnome metapackage is the same reason why upstream GNOME included it in their default desktop release. It is not to bow before Microsoft or Novell, as you and your paranoid friends seem to think; it is because professional-grade note-taking is a vital application to an important share of our users.

Everyone working in a corporate environment, with many projects to manage with several clients, meetings every other day, and random thoughts to write somewhere, needs to manage notes. Some use random pieces of paper scattered on their desk. Some use notebooks. Some use Emacs. Some write formal proceedings for each of their actions. It turns out that none of these methods are comparable to Tomboy in terms of efficiency.

As such, I’m wondering whether you are actually using the software you packaged. Your writings suggest that you don’t need an application such as GNote. Which means that, consistently with your other actions in the project, you only packaged it to push your pointless political agenda, not to do something useful for our users. That also explains why you proved to be so clueless while packaging it.

And I am sorry to inform you that the Project does not give a shit of your political agenda. The reason why Tomboy was not included in the default Lenny installation is not because of stupid software patents. If we gave a shit of inapplicable software patents, we wouldn’t be shipping MP3 decoding software by default. If we gave a shit, we wouldn’t ship Mono in main, regardless of what is in the default installation. We don’t give a shit of where is Mono coming from, as long as it is free software. As Jo explained, we don’t even give a shit of what Mono is, it just happens to be a dependency for Tomboy. No, the reason why Tomboy was not here by default is simply because its dependency stack was too big for some installation media. Now, the Debian Mono team managed to reduce a bit the installation size, and the availability of GNote as an alternative is giving a last-resort choice that will be much smaller.

Oh, and just a side note: I was going to work on the remaining bits of GNOME 2.26 in Debian this week-end. You just convinced me to watch anime on my home cinema instead. With new seasons of Higurashi and Haruhi Suzumiya coming around, this is perfect timing.

Here are a few hints if you want your reports to be treated more promptly.

When testing fails, try unstable

If you are running testing, not all bug reports are interesting. More specifically, the relevant ones are about insufficient dependencies that let slip into testing a non-working combination of packages. Think of the “I upgraded foo, then bar broke” category.

Otherwise, the reason why reportbug looks for newer versions of a package in unstable is that, in most cases, the bug is fixed in unstable. If you can, always try the unstable version before reporting the bug.

Report bugs against the failing package

“This is related to printing in a GNOME program, so I report this against libgnomeprint.”

Always file reports against the failing program. If there is a library involved, reportbug will include the necessary information so that the maintainer can easily reassign. If you’re not sure of the affected package, use a metapackage (for example, gnome for GNOME-related packages).

Do not second-guess the origin of the bug

“After upgrading libfoo, bar starts crashing, so I’m reporting it against libfoo.”

Unless you can tell which function is at fault and how this is ABI breakage, you should report the bug against the program that crashes. The program’s maintainer will reassign if needed, and will hit the library’s maintainer with a hammer if needed.

Don’t forget to explain what’s wrong

“The frobniz in libfrob is broken, you should change /usr/share/libfrob/blah line 13 to something else. I don’t know what libfrob is about, but I have some problems that look frobniz-related.”

Do not second-guess, always start explaining what bug you are seeing first. Your attempts at investigating it can be interesting, but don’t forget to explain what bug lead you on investigating.

What is the use case we should cover?

“I’m trying to do that with your package and it looks extremely complicated/doesn’t work as expected/fails miserably. Your package is clearly broken!”

If your attempts to do something that should be trivial, given the purpose of the package, fail, then you are probably looking at the problem at the wrong angle. There may be a much simpler, though radically different, way to do what you are trying to achieve.

In these situations, always include in your report what you are trying to do and why you want to do it.

strace is not a general-purpose debugging tool

Whether you observe a crash, a deadlock or a livelock, strace is not the tool that will give us information. The only thing you do by adding a strace log to the bug report is making it unreadable with its thousands of lines of output.

For the specific cases that require strace for debugging, these traces are welcome but if you’re not sure, don’t attach them. The developers will ask them for you. Otherwise, the general-purpose debugging tool is gdb.

Use reportbug

There is a good reason why some packages include bug control files and scripts. Use a reporting tool that takes them into account. Unless you are requesting an enhancement, always use reportbug. Please avoid reportbug-ng since it only provides parts of the required information.

Seen on Slashdot: a large discussion forum site hacked through its backups.

I had seen this coming. And it’s just the beginning, you can expect this to be a major attack vector in the next years. Until people understand it’s not possible to secure data without securing the network.

Due to the repeated tendency of our friends of the MPAA beloved government to create laws that turn computer and Internet users into criminals, I’m considering to shutdown any kind of non-encrypted communications that I initiate from France.

Therefore, I’m looking for cheap dedicated hosting in an Internet-friendly country, in a way similar to what we have here with OVH or Iliad. My requirements are:

• low ping times from France
• high bandwidth (100 Mbits/s would be nice)
• 100 GB of RAID disk space

Suggestions are welcome. I’m currently considering hosting solutions in the Netherlands, but I’d appreciate some advice.

Up to lenny, our GNOME desktop lacks a bit branding. We used to have the splash screen but it doesn’t show up anymore, so that only leaves the background. It has several times been requested to put a bit of branding in the menu, as most distributions do, and this has been in my mind for a while.

I have uploaded a first attempt to unstable. Since I didn’t want the branding to be too intrusive, I used the “swirl foot“ logo of the pkg-gnome page. So far, the reactions haven’t been very enthusiastic, that’s why I’m writing here. Any change generates an amount of grumpiness, and it’s hard to distinguish what’s caused by the mere fact that something broke people’s habits, and what’s really changed for the bad.

This is why I have set up a little poll where users are welcome to voice their opinion. What should we set as the main menu icon?

• The good old GNOME foot icon
• The Debian swirl icon
• The “swirl foot“ icon

I also welcome proposals for some other icon that would be better for this place. Actually, that would be my favorite option if I had something to propose, as I’m not enthusiastic about any of the available ones. Time to be creative!

So now is the time to express your preferences. If you have comments, please put them in the blog entry, not in the poll page.

EDIT : I found that some opacity settings in the SVG I used for the “swirl foot” icon were completely wrong. Here is a new version, taking account what has been proposed in the comments:

The gnome-power-manager developers like clean code. Actually, more than clean code: code that will not generate a single nitpicking warning. The package builds with the following C compiler flags:

-Werror -Wcast-align -Wno-uninitialized -Wall -Wformat-security

Sometimes the compiler is more clever than the coder…

On the SPARC architecture, -Wcast-align really starts to mean something. Unlike most other architectures, any alignment error on here will leave you gather your teeth spread on the floor after you’ve been hit by a SIGBUS. It tries to catch at build time alignment errors resulting from a cast between pointers to different types.

Together with -Werror, it triggered a first FTBFS bug. The error occured on the following code:

        if (XRRGetOutputProperty (brightness->priv->dpy, output, brightness->priv->backlight,
                                  0, 4, False, False, None,
                                  &actual_type, &actual_format,
                                  &nitems, &bytes_after, &prop) != Success) {
                egg_debug ("failed to get property");
                return FALSE;
        }
        if (actual_type == XA_INTEGER && nitems == 1 && actual_format == 32) {
                *cur = *((int *) prop);
                ret = TRUE;
        }
        XFree (prop);
        return ret;

More precisely, the error occurs when casting prop (which is an array of pointers) into an int *.

The compiler is clearly right. The alignment requirements are different for a pointer and an integer; therefore, casting a pointer to a pointer into a pointer to an integer will always work, but dereferencing the pointer later will possibly cause a crash. Turning this expression into a memcpy leads to code that should always work.

Lesson learned: do not design APIs where an array of pointers can actually store integers. Have you ever heard of opaque structures?

… and sometimes it is not

This was not enough and a second FTBFS bug showed up. Here, the error happens in the following code:

static inline GstBuffer *
gst_buffer_ref (GstBuffer * buf)
{
  /* not using a macro here because gcc-4.1 will complain
   * if the return value isn't used (because of the cast) */
  return (GstBuffer *) gst_mini_object_ref (GST_MINI_OBJECT_CAST (buf));
}

GstBuffer is a structure which contains a GstMiniObject at the beginning. Therefore, you conduct operations on the GstMiniObject through a mere cast. The first cast (GstBuffer → GstMiniObject) is fine, but in the second cast (GstMiniObject → GstBuffer), the compiler suspects a problem, since the alignment requirements on GstBuffer are stronger than those on GstMiniObject.

The compiler is wrong because it didn’t read the API documentation; otherwise, it would have known that gst_mini_object_ref can only return NULL or its argument, which means there can’t be any loss of alignment. Since there are no function attributes to express such complex things, we are still forced to rely on the developer having correctly read the documentation. Way to go, compiler.

Lesson learned: there are good reasons why some warnings are not part of -Wall. Especially, it is dubious to use them with -Werror. Does anyone know whether it is possible to apply -Werror only to some of the warnings and not to all of them? It would sound like a useful improvement.

For various reasons (which in the end boil down to lack of manpower), we are quite late in the process of packaging GNOME 2.24. (This is almost finished now, I’ll keep you informed.) Which is why I may sound coming a bit late on noticing this one, but I was really speechless.

The problem: session management has flaws

Currently, a session manager uses XSMP (the X Session Management Protocol) to talk to applications. What it means is that for applications supporting this protocol, it is able to do more than simply starting and killing them: it will also remember their state, and offer them a way to shut down gracefully. However, XSMP is really a shitty protocol – I won’t explain why here, you will find tons of better explanations on the intarweb.

The gnome-session developers, being quite aware of this issue, did what anyone interested enough would have done: they designed a new protocol, based on D-Bus, and implemented it. The new protocol is not considered stable yet, but it is simple, efficient and above all, reliable – that’s a giant leap forward. For this reason, I was very excited to see what gnome-session 2.24 would look like, since it brings major cleanups in the code.

The solution: remove session management!

When I first started it, it did not restore my saved session. I simply supposed that the format of the saved session had changed, and that writing a conversion tool would be in order. Wrong. Let’s bring the session preferences:

The UI of this dialog hasn’t changed since 2.22. However, I do not resist the urge to show you the code behind the “Remember Currently Running Applications” button:

static void
on_save_session_clicked (GtkWidget           *widget,
                         GsmPropertiesDialog *dialog)
{
        g_debug ("Session saving is not implemented yet!");
}

If you know the long term plans for GNOME, it makes sense: when gnome-shell replaces the panel and the window manager, it will also be responsible for starting the visible applications, while gnome-session will deal with what’s happening behind the scenes. But gnome-shell is still far from ready, and you need something in the meantime for the basic requirements of a session manager!

Backwards compawhat?

The surprises don’t stop here. I also noticed that logout was much faster – instantaneous instead of the usual 2-3 seconds. The reason why logging out is this long currently is not because it takes long to kill applications; it’s because the session manager kindly requests applications supporting XSMP to shut down before killing them. If a document isn’t saved, an application will be able to prevent the logout process. Guess what? Now gnome-session completely ignores XSMP applications. Since it doesn’t need them to register for saving the session, it also saves the time to ask them to close cleanly.

The result is that you will see a lot of such dialogs:

It’s very nice to replace a flawed protocol ; and really, the new protocol goes in the correct direction. But let’s be realistic, it’s impossible to immediately port hundreds of applications to a new protocol without having a transition time during which both protocols are supported. You also need to consider your protocol as stable before asking other developers to port their applications. And to get it accepted, you need to standardize it; freedesktop.org would have been the correct body. (Currently, the protocol lies in the org.gnome namespace, not org.freedesktop.)

Release management at its best

Wait… aren’t there some distributions out there which already released stable versions with GNOME 2.24? The answer is yes. At least Ubuntu Intrepid and Fedora Core 10 ship with a session manager that:

• is unable to restore applications;
• kills applications without letting you save your work.

It’s good to see such improvements on the session manager coming, and I’m really thankful to the gnome-session developers to work on it. What I wonder is:

• How could it slip into a stable GNOME release?
• How could two major distributions let it slip into a so-called stable release?

So what?

This is a very good example of a lack of “big picture” thinking. On one side, there is a brilliant design and its good implementation. On the other side, two major regressions from the user’s point of view – the kind of regressions that make people fly away.

If there’s one thing that I’ve learned from working in IT, it’s that you must often keep your brilliant designs as long-term goals. In the short term, you will run a bastardized version of your brilliant design that will make you cry; but it will work. When you need to talk to shitty applications or with shitty protocols, you need to write shitty code.

during the ongoing avalanche of posts on Planet and on Debian mailing lists where you ask everyone to be friendly and considerate, you have so far:

• deliberately framed the discussion in a gender-oriented fashion to throw away unjustified accusations of sexism;
• inflated a 85-post long mudslinging thread with my name in the topic (which is the Google version of publicly throwing stones at people);
• vomited on people on an IT news site and helped the site spreading misinformation about the Project;
• shown your own frustration by trying to find hidden sexual references in messages you find offensive;
• and I’m probably missing a lot since I’m not reading all that crap.

Pretty please. What you mean is “Go fuck yourself”, but the way you are saying it is no more friendly and actually much more rude. If you meant “Go fuck yourself”, why not just say it?

• I would have felt better since it’s much less insulting.
• You would have felt better since it’s really a relief to say it frankly.
• Everyone else would have felt better since this would have ended the discussion instead of polluting the lists with useless wanking.

As for those starting discussions on the community and on the code of conduct: do you want a community like Ubuntu where everyone can be scornful and prepare lousy tricks, but always preserving the appearances (thanks to a mandatory broomstick), or a community like the Linux kernel, where people say frankly what they think, even if what they think is “I hope you were on crack while writing that” ? I know which one I choose. I may disagree with their technical development model, but at least they know that a software community is not a group of friends. And that is a sign of maturity.

There is again some ongoing debate about Ruy gems and how to integrate them cleanly into the operating system.

Let’s put aside the fact such tools are useful on Windows and MacOS which don’t have decent packaging systems. This is not a reason to dictate stupid requirements for other operating systems. Still, even without that, gems, eggs and the like are great tools for development; tools that developers can’t work without today. They allow to easily setup a development environment with everything needed, at the latest versions. However they were not meant for integration and production environments, and will never be suitable for them. We’re living in another world indeed: a world where servers must be up 24/7, where security issues flood your inbox every day, where you need dozens of servers running the very same software. This world is the Earth.

Python eggs and Ruby gems were designed for the same target audience and with similar requirements; as such, they share the same deficiencies when it comes to other audiences:

1. They replace the operating system’s packaging tool. This is very nice to not wait for the packagers when you want the latest development version, but you lose track of what is actually installed. In production, you need to know exactly what’s installed and at what version. You also need to know what you will need to update in case of a security issue.
2. They install packages automatically on the system. This is really the biggest WTF; there are some reasons to do that to begin with, but they are all wrong.
3. They use a specific file format. This requirement comes mostly from the Windows world, and it really makes no sense on Unix. It makes it much harder to integrate complex applications using components in different languages.
4. They ship all files at the same place, happily violating the FHS and making it even harder to integrate with other things.

Python tools (setuptools and easy_install) have shifted their philosophy and brought a few small improvements which allow us to easily work around issues 1-3. These tools now include all you need to build a development environment in any directory that will not have an impact on the system packaging, making a clear distinction between the two targets. Furthermore, the metadata is shipped separately and can safely be included in a distribution package. Similarly, modules will not be installed automatically on your system. I have yet to see such a move from Ruby developers.

However, what we are still missing is something along the lines of dh_make_perl: starting from a CPAN module, it will generate a clean and working Debian package in a few minutes. There have been some similar attempts for Python, but nothing as efficient. And I am certainly guilty of not having done something in this area, as one of the most knowledgeable of issues we encounter while packaging Python modules.

As a note, I should add the underlying issue behind all of this is still the same: the NIH syndrome. Developers are reinventing the wheel, engine and transmission. Which is not that bad per se, but by not looking at existing solutions for the problem of making a car move, they are inventing a square wheel, a steam-powered engine and a superconductor-powered magnetic transmission. For example, while trying to fix the 4th of items listed earlier – and they are really willing to fix it – and several more general issues, setuptools developers forgot to look at the existing solutions:

• API versioning in /usr/include/package-X.Y
• ABI versioning of libraries
• Build/install-time requirements gathering using an extensible format with pkg-config
• Automated generation of config.h containing all system-specific macros (including paths), with autoconf
• The Mono Global assembly cache which solves some of the specific issues of interpreted languages

Certainly, the existing tools are everything but perfect, and not necessarily suitable for Ruby and Python, but some of the design ideas behind them are clearly the good solutions to some of the issues of software development and integration. Adapting these ideas to radically different languages is going to take more time than just throwing other layers of symlink farms.