In the light of the upcoming GNOME 3, the more document-centric Shell and the browser-mode nautilus (instead of spatial mode), I wanted to remix my thoughts a bit.

Note: I am not a developer and I am not on the Shell or Nautilus teams. The idea of a desktopless environment was briefly raised on the Nautilus mailing list months ago and has hesitantly appeared at the end of the GNOME Shell Design Document, as quoted below:

Used for both ephemeral, and working set data finding and reminding. Given time, the constant stream of things to do, the constant remainder that does not get done, and the unwillingness to categorize and archive manually, and the fact that the solution doesn’t scale (due to being spatially bound) results in the system breaking down. On top of this – so to speak – is the problem that this data lives underneath all of the current activities on the computer and is therefore very difficult to reach. Which also tends to reduce its effectiveness for finding and reminding. It also doesn’t provide any form of prioritization.

In the Shell design, the “desktop” folder should no longer be presented as if it resides behind all open windows. We should have another way of representing ephemeral and working set objects.

The reminding function of the desktop is really only available immediately after login. Once any activities are started its effectiveness is dramatically diminished. Starting the Journal automatically at login will have a equivalent effect and have the advantage of being easier to access later.

However, I haven’t seen much more happening since then, and I believe this to be a fundamental question to settle. GNOME 3 would be, in my humble opinion, a perfect window of opportunity for an “intrusive” paradigm shift like killing the aging desktop metaphor.

I believe the concept of “icons on the desktop” to be counterproductive and perhaps counterintuitive. This blog post is a humble attempt at demonstrating why.

Windows obfuscating contents

Most of the time, the desktop is hidden by multiple windows. To access your desktop contents, you need to manually minimize your windows, hit Ctrl+Alt+D, or use the “Show desktop” panel applet (which probably won’t exist in the Shell anyway). Then, when you are done interacting with your desktop, you need to raise all your windows again. You keep moving things out of the way and putting them back in the way, all the time!

Alternatively, you could use nautilus to access the contents of the desktop folder, which defeats the purpose of having contents on the desktop. Or you could always keep an empty virtual workspace to switch to, but it quickly fills itself with windows and the cycle repeats itself.

Icons, visual clutter and cognitive strain

The Desktop is typically “designed” for transient files (though, as I’m arguing here, the vast majority of users don’t actually use it for its intended purpose). By transient files, I mean the following categories/scenarios:

• Files that I received or downloaded (through instant messaging, or files that the web browser auto-downloaded for me, for example)
• Temporary crap: blogging material, files to be attached to bug reports, files from bug reports, emails, etc. Usually files with a lifespan of five minutes.
• “Reminder” files, there just to annoy me into doing something about them.
• Files that I am currently working on (though, in theory, nothing prevents us from working on files that were already filed properly in folders)
• Files that are “waiting” for something (for example, files I would need for project X in 2 months)

The distinguishing lines between those scenarios is often blurry, to say the least.

The problem with desktops is that we, modern “information workers”, have heaps of data to process, and we have the following choices to make about a file (GTD/Inbox Zero fans will see that one coming):

• Process it immediately (and then delete or archive it)
• Defer it (“I need to wait 2 weeks for event X to happen before I can touch this”)
• Archive it (in that case, it should not be on the desktop)
• Get lazy and let it sit there

Oftentimes, this means items start accumulating on the desktop for weeks on end, waiting for the right moment/motivation/energy to be used. All this has a price. For some, it can be annoying to have all that stuff in your face all the time, or it can become a chore to “clean up”.

Ironically, the inverse tendency can also be true: the less there is, the more we are inclined towards piling up new stuff.

Keeping the balance takes determination and technique (not everyone is a GTD/Inbox Zero maniac). For less organized people, the desktop just becomes a dumping ground, full of “stuff” constantly in your face, “urging” you to be processed and reminding you that you should be doing something else but don’t have the energy or resources needed.

My point is a bit hard to prove here because, to some, it may look like I am advocating “hiding stuff under the rug”. For the sake of the argument though, I shall say that I have been running my computers without a desktop since 2007. This is what it typically looks like:

And this is what happens if I reactivate the “icons on the desktop”:

As a real world analogy, my current summer job involves office work. Pure, old-fashioned office work with actual folders, tons of paper, a hole puncher, stapler, and pencils. I process a couple of dozen cases per day, which means that my desk is a constant mess, with me pushing and pulling folders around, using aforementioned tools, throwing them back in the pile while I go fetch printouts, letting objects fall on the floor, leaving bits of memos everywhere, etc.

It doesn’t look exactly like this, but close enough:

(picture by Rob)

It is Hell.

Why would I ever want to reproduce this kind of chaos onto my computer screen? Isn’t it the computer’s job to give me unlimited storage and triaging capability for me not to shuffle things around constantly?

Text legibility

Partly due to Bug 317764, GNOME’s text readability on the desktop is very poor, to put it nicely.

As I don’t want to nitpick on a bug report that I filed years ago, I won’t comment further on the matter. Suffice to say, reading text without a solid, contrasting background is an accessibility disaster. Those who want to dig the matter can take a look at the bug report linked above.

Wallpaper enjoyment

Not only complex wallpapers impair text legibility (as mentioned above), but the reverse is also true: text and icons take away from your enjoyment of a good wallpaper because they add visual clutter. When I wrote my original article a couple of years ago, I had calculated that out of my 2500+ wallpapers, about 5-10% of them could actually be used with the traditional desktop metaphor.

Here’s the thing: our icons are mostly bright, and their text labels are bright too. Even with sufficient text borders (if bug 317764 was fixed), having items on the desktop interferes with the artistic complexity of most wallpapers in terms of clutter, brightness, contrast, etc. For that reason, only a minority of minimalistic wallpapers are truly suitable for use with icons on a desktop.

Incoherence with the “file manager”

By exposing the desktop folder as a special use case, we lose a great amount of functionality and break the consistency with “normal” folders; the desktop does not have the same features as the “full-featured” file browser Nautilus. No side pane, menubar, toolbars, no listview/treeview/compact view/infrared view, etc.

It made “some” sense when spatial mode was the default behavior, but it doesn’t make much sense now that browser mode is the default.

TL;DR/summary: the desktop metaphor sucks. We are stuck with a limited surface, limited file management tools, and a background that actively impairs legibility of the files sitting on it (unless you’re using a solid black background).

Not so intuitive?

The desktop metaphor is often presumed to be more intuitive to use, because:

• The user would interact solely with that desktop, thus see the entirety of his/her’s important files. This falls short for anything but the simplest use cases.
• Users come from Windows/Mac OS/Altimit OS and are used to the desktop metaphor. This is one of the eternal debates of usability, “Do we make drastic changes or do we keep everything ‘familiar’?” It struck me, however, that one day my mom asked me directly if those desktop folders could vanish! A similar observation applies to a couple of other relatives: I suggested disabling the desktop because it was a mess and… they actually agreed!

In my opinion, for someone who was not trained for using the desktop (others can be retrained, or brainwashed), not having a desktop does not make a computer less intuitive. Actually, I believe having a desktop increases the difficulty, due to the reasons mentioned earlier and because it creates “another” way to access your files and folders.

You can easily explain to someone that “Whenever you need to access some of your documents, you just have to access the Activities screen and click your Documents folder, or your Home folder”. Explaining why some things appear on the desktop but at different places in the file chooser or Nautilus? Not so much.

As a matter of fact, unless the gconf key “desktop_is_homedir” is set to True, the standard XDG directories (Documents, Images, Music, etc.) are not even located on the desktop, so the user has to use the Activities menu to access them anyway. Many users don’t bother. And many users have no abstract conception of the distinction between the Home folder and the Desktop folder. I have observed this time and again.

In GNOME 2.x, switching non-geeks to launching their Home folder from the Places menu is a bit of a stretch, since it requires more abstract thinking (knowing what files and folders are).

Things change with the GNOME Shell: the incredible elegance of the Shell’s concept is that it combines applications, recent documents and places all into the Activities menu, which is accessible simply by a flick of the mouse. This means that accessing the home folder takes exactly one click, and is much, much less painful. The fact that the Home folder can now be accessed so easily is one more reasons why I believe the time is right to get rid of the desktop. The fact that removable devices can be accessed (and unmounted) directly from the Shell is icing on the cake.

Back when I wrote the first version of this essay a few years ago, the ecosystem was different. We were in the middle of a stable GNOME 2.x series, with no revolutionary 3.x redesign at our doorstep, and the thought of advocating a desktopless GNOME 2.x as the default behavior didn’t even cross my mind. However, at the dawn of a groundbreaking release, I believe now is the time to voice one of my deep convictions: we ought to kill the desktop by default. This means:

• Set the key “/apps/nautilus/preferences/show_desktop” to False by default
• Set the key “/apps/nautilus/preferences/desktop_is_home_dir” to True (unless we have a new use for the desktop folder)
• Ensure that the interaction between the Shell’s and its places shortcuts is rock-solid: it needs to fully support dragging and dropping items onto places such as Images, Documents, Home, etc; it needs to be reliable in showing all the removable storage devices and reliable in mounting/unmounting them. Have 20 usb keys plugged in? They should all be easily accessible without even launching Nautilus.
• Eventually: complement this vision with tools like GNOME Activity Journal and the (experimental) idea of “project-centric” workspaces. Surely someone smarter than me will be able to come up with a brilliant solution to the eternal problem of “limbo/temporary files”; perhaps a zone where files have “expiration” dates and where users can “pin” files to prolong their life before they are either archived (put in another folder) or trashed.

What about “@Waitingfor” files?

As I mentioned previously, there are some kinds of files that you need to work on at a later time. Back in the day, I wrote a horrible, hacky python script to deal with this, called FrontBringer. Again, perhaps that the great minds behind the 3.x vision could come up with a better way to handle this use case, with files that you can “pin” or put in a “cryogenic storage”. Or something based on Lucas’ newly announced Board. Perhaps Guadec would be a great time to discuss these things (I will not be able to attend, sadly).

Gentlemen, start your flamethrowers.

Depuis des années, je fais le soutien technique pour les membres de la famille qui roulent Ubuntu/Linux (j’ai une politique, à la Alan Pope ou à la Ploum, de n’offrir aucun soutien si la machine roule sous Windows). Pour la majorité de ces utilisateurs, je ne personnalise que très peu le bureau GNOME standard, parce que, bien que nécessitant quelques explications, ces utilisateurs ont déjà une certaine affinité avec le monde de l’informatique, et comprennent les principes de base sous-tendant l’interaction dans une interface graphique WIMP.

Or, le cas que je vous présente aujourd’hui est une exception, que nous surnommerons ici Alex. Alex est âgée d’une soixantaine d’années et n’a jamais touché à un ordinateur de sa vie avant que je lui en fabrique un avec Ubuntu. C’est dans des situations comme ça que l’on s’étonne de voir combien de choses, prises pour acquis pour la majorité d’entre nous, ne peuvent tout simplement pas être laissées au hasard ici, parce que dangereuses ou trop complexes.

Caractéristiques:

• Pas de conception mentale claire de fichiers/dossiers/etc. (ceci est commun à la majorité des utilisateurs “non-geeks/non-professionels”, pas juste aux non-ordinateuriens)
• Sa coordination motrice et son acuité visuelle sont problématiques (l’usage de la souris est extrêmement imprécis)
• Que ce soit le serveur X, les barres d’outils ou les tableaux de bord, si ça peut être détruit, ça va être détruit. Il faut que tout, absolument tout, soit verrouillé et cloué en place (utilisez le logiciel Pessulus pour arriver à cette fin). Exemples:
  • Alex fait ctrl+alt+backspace (ce qui tue le serveur X; j’ai été bouche bée de constater que les développeurs de Xorg avaient raison de désactiver cette fonction par défaut) parce qu’elle oublie de lâcher certaines touches du clavier. Ceci n’est plus activé par défaut.
  • Elle déplace des éléments des barres d’outils/panneaux sans le vouloir (puisqu’elle a du mal avec la souris; la moitié du temps, un “simple clic” se transforme en glisser-déposer)
• Considérez que les menus contextuels (accessibles par le clic droit) n’existent tout simplement pas. Si vous voulez que ce soit accessible, il faut que ça se fasse par la barre d’outils ou les menus.
• La liste des fenêtres est inutile. L’utilisateur ici ne sait pas et ne veut pas gérer des «fenêtres» (en ce sens, je comprends mieux le mot «Activités» de GNOME Shell). Le regard ne s’y porte même pas, c’est totalement périphérique. J’ai également constaté ce phénomène chez d’autres «non ordinateuriens»: je ne les ai pas encore vus une seule fois utiliser la liste des fenêtres.
• Une impatience marquée envers le temps de démarrage de l’ordinateur (ce qui est relativement rare parmis les gens que je croise); en ce sens, je suis bien content que ce dernier ait chuté considérablement dans les dernières moutures d’Ubuntu
• Lorsqu’un problème survient, ne vous attendez pas à avoir des explications claires ou des étapes pour les reproduire (qui plus est, le vocabulaire n’est pas assez complet pour pouvoir exprimer les idées).

Par dessus le marché, l’ordinateur en question n’a que 256 Mo de mémoire vive et doit nécessiter le moins de maintenance possible. Il faut qu’il soit blindé et léger. Dans cette optique:

• Le moins de processus au login possible: on retire Gestionnaire Bluetooth, Gestionnaire de réseau (NetworkManager applet), Notificateur de mises à jour (update manager), bureau à distance (s’il n’est pas utilisé), Ubuntu One, vérification de pilotes matériel (jockey), Mise à jour des dossiers utilisateur (xdg-user-dirs-gtk-update), etc.
• Un seul tableau de bord, avec le moins d’applets possible (en fait, rien sauf des lanceurs et un bouton pour éteindre l’ordinateur). Ceci contribue à réduire significativement la quantité de mémoire utilisée (et, indirectement, le temps de démarrage). C’est la différence entre 160 et 87 Mio de RAM utilisés au démarrage. Sur 256 Mo, c’est significatif, et ça implique moins d’utilisation du swap, donc de meilleures performances.
• Pas d’effets spéciaux: ce n’est pas le genre d’utilisateur à apprécier Compiz si, après tout, il ne «gère» pas les fenêtres; qui plus est, Compiz est une source de bugs potentielle et consomme des ressources du système.
• Barres d’outils simplifiées et personnalisées: il faut prendre le temps d’observer comment l’utilisateur interagit avec ses logiciels, et quelles tâches il veut réaliser courramment. Si c’est planqué dans un menu, ça risque d’être oublié. Ainsi, je suis bien content de pouvoir modifier la barre d’outils de Eye of GNOME pour y ajouter un bouton «Enregistrer», opération qui est nécessaire après que l’utilisateur ait utilisé l’outil de rotation d’image. Dans certains cas comme Epiphany, grâce à Pessulus, on peut simplifier encore plus l’interface en retirant la barre de menus, ce qui a également l’avantage de nous économiser une dizaine de pixels d’espace vertical (sérieusement, personne n’utilise les menus d’Epiphany sauf les geeks, et Alex n’a jamais utilisé les «Signets» dans les 4 dernières années).
• Un panel énorme (48 pixels de hauteur!) pour compenser les problèmes oculomoteurs de Alex et rendre les icônes plus faciles à reconnaître. Sur ce panel se trouvent simplement des lanceurs d’applications et un gros bouton pour éteindre l’ordinateur.
• Des barres de titre énormes: simplement changer la taille de la police de texte de Metacity permet d’avoir des boutons plus gros/accessibles (clé gconf: /apps/metacity/general/titlebar_font = Sans Bold 14)

Un autre constat: l’ordinateur ne sert, franchement, qu’à accéder au web et à deux ou trois autres choses. J’avais auparavant installé une multitude de logiciels, espérant susciter un intérêt, tels que Homebank, Contacts, Tasks, GThumb, etc.:

Des années plus tard, force m’est de constater qu’ils n’ont jamais été utilisés (l’ordinateur est un «moyen» pour accéder au net, pas une «fin» en soi). Conséquemment, je les ai retirés.

Le résultat final:

Epiphany 2.30 et GMail:

Temps de login total from cold metal (incluant le bios de 15 secondes) jusqu’au login avec bureau gnome: 45 secondes (25 secondes du démarrage du kernel jusqu’à GNOME chargé).

Entre temps, un nouveau projet en lequel je plaçais mes espoirs fit apparition: GNOME Scan (et sa librairie complément «Flegita»). Problème: il semble n’y avoir pratiquement qu’un dev à la tâche, et le projet avance quelque peu lentement. Conséquemment, GNOME Scan sortit un peu de mon champ de conscience dans les derniers temps, parce que, bien que l’interface de xsane tue des chatons, une fois configurée, elle fonctionne et est relativement flexible.

Tout ceci change avec Ubuntu 10.04, où un petit nouveau est apparu sur la scène: Simple Scan. Il est étonnant de constater que ce n’est pas dans leur release notes (et donc assez peu mentionné sur la blogosphère). Pourtant, ça doit bien être une des contributions les plus significatives que j’aie vu venir de Canonical depuis longtemps (si vous regardez le dialogue «À propos» du logiciel, on peut voir que ça a été créé par Canonical en 2009).

Dans un mini échange de courriels avec Étienne Bersac (auteur de GNOME Scan), ce dernier m’a précisé la différence entre les deux projets: Simple Scan se veut un simple moyen de mettre xsane dehors, alors que GNOME Scan se veut être une architecture/infrastructure pour les devs, faisant notamment appel à GeGL.

Mais je n’ai pas encore expliqué pourquoi Simple Scan, c’est du titane de carbone.

• Le logiciel se souvient de la taille de fenêtre que vous lui donnez. Nom d’un chien. Après des années de chasse aux bugs, je peux vous affirmer que moins d’une application sur dix se souvient de ses dimensions avant que j’emmerde les développeurs avec un rapport de bug (et encore, même les capplets/panneaux de préférences de GNOME ne le font pas, alors que je l’ai demandé il y a des années). Le fait que Simple Scan le fasse témoigne d’un certain souci du détail qui lui donne déjà des points en sa faveur avant même d’avoir commencé à tester le bestiau.
• Une interface simple, uni-fenêtre et conforme aux autres applications GNOME. Quand on compare à xsane, la différence est tellement frappante qu’il n’y a pas besoin d’explications poussées ici. Nous sommes devant une interface moderne au lieu d’une interface des années 90.
• Un design facilitant les numérisations par lots (ex: avec un «automatic document feeder»)
• Un design permettant deux «cas d’utilisation» simples pour les néophytes: la barre d’outils permet facilement de numériser du texte (150 dpi) ou numériser une photo (300 dpi). Les paramètres de DPI sont planqués dans la fenêtre des préférences.
• Pas de barre de progression ni d’attente: on voit le document s’afficher progressivement pendant qu’il se numérise. Comme dans un vrai logiciel de numérisation professionnelle/commercial. Après toutes ces années, je n’y croyais plus. Quelle élégance. J’ai dû ramasser ma mâchoire qui traînait sur le plancher.
• Des outils de traitement post-numérisation: pas besoin de prévisualiser, découper et tourner à l’avance. On numérise, et ensuite on choisit si on découpe l’image, si on la tourne, et si on l’enregistre. Pas besoin de réfléchir au préalable au document que l’on numérise, on peut le traiter post-facto. Conséquemmet, je ne suis plus forcément obligé de passer par GIMP pour faire le traitement (sauf si je veux faire des optimisations de couleurs/poids bien entendu).

Conclusion: Simple Scan est exactement ce que son nom laisse présager, et je serai fier de le montrer à des utilisateurs non-geeks.

Après avoir reçu des mises à jour du PPA GStreamer aujourd’hui, Epiphany peut lire les vidéos HTML5 WebM, telles que le trailer de Sintel avec le nouveau codec WebM (il faut souscrire au mode beta, mettre &webm=1 à la fin de l’URL, et s’assurer qu’il est bien écrit HTML5 WEBM sous la vidéo, sinon vous visionnez du Flash ou du H.264) ou Elephants Dream sur la page de test de Opera (avec des jolis boutons de contrôle de lecture).

Pourquoi est-ce donc notable?

• On parle ici d’Epiphany 2.30.2, qui est une version stable, pas une branche obscure d’un dépôt git
• Epiphany ne requiert aucune modification. Boum, un nouveau codec supporté en natif, grâce à la nature modulaire de GStreamer.
• WebM c’est bien, mais ça tout le reste du Web et de la planète libre se chargera probablement de vous dire pourquoi dans les 24hres qui suivent.

Bon, maintenant que j’ai pris la défense d’epiphany avec cette parenthèse théorique «vous voyez que GStreamer c’est bien», ça doit bien être une des rares fois (une expérience d’une vie!) où Epiphany est en avance sur les autres. Savourez le moment!

1. Peut monter/démonter/renommer/formater des partitions;
2. Offre une belle vue hiérarchique des disques;
3. Offre une visualisation très élégante des partitions/volumes sur un disque;
4. Gère l’état de santé de vos disques avec SMART, et vous alerte en cas de problèmes (même si palimpsest n’est pas en cours d’exécution);
5. Permet de faire des benchmarks de lecture et de lecture/écriture (requiert que la partition soit vierge);
6. Permet même de faire un RAID logiciel aisément. Nom d’un chien.

Le seul défaut: l’interface est tellement bourrée de fonctionnalités et d’informations qu’elle ne rentre pas entièrement dans la résolution typique d’un netbook (1024×600).

Exemple de benchmarks (lecture seulement) du disque dur SSD STEC PATA de mon Dell Mini 9:

Et le disque dur conventionnel SATA2 de mon ordinateur de bureau:

Notons la différence notable dans les temps d’accès (le SSD est environ 25 fois plus rapide). Les débits sont, quand à eux, similaires. C’est dommage qu’on ne puisse faire le test lecture+écriture que sur une partition vierge, parce que là on verrait probablement mon disque dur SATA pulvériser complètement le SSD cheap du Dell Mini 9 (vraiment, il est affreux en écriture et ça se sent très vite).

What I’ll do

I’ll be mostly blogging about PiTiVi (because that’s what I’m the most involved in these days, and the devs are usually too busy unleashing their fury onto foul minions of Hell), and I may remix some of my old usability thoughts in the new light of GNOME 3.0.

On that note, I’m still waiting to see whether or not the “icons on the desktop” debate/idea has been settled (I haven’t quite caught up on Nautilus’ and the Shell’s happenings in the past few months). If it has not, I may attempt a thought experiment on it.

What I will (probably) not do

So, what’s new in PiTiVi lately?

Note: I suggested that the Title and Description fields go into a dedicated “Metadata” tab, we’ll see.

However, PiTiVi 0.13.4 will be the version bundled with Ubuntu 10.04. It is quite basic, but, like many new applications in Ubuntu, should benefit from the large testing user base, and hopefully gain some new contributors. The current work highlighted above gives me an optimistic outlook on PiTiVi’s future.

Want to help out with PiTiVi? We need all the help we can get! Take a look at our contributing page.

Sintel logo proposal

I shall conclude this blog post by highlighting how awesome Inkscape is. In a matter of days, I managed to create this logo entry for the Sintel open movie project entirely in vector art.

While it took me a long time, I mastered the (over)use of shape masks and learned how to use “Live Path Effects” along the way. Some folks on #inkscape have been very helpful in pointing me in the right direction (which part of the documentation to look at). Along the way, I encountered a nice rendering bug with Live Paths Effects. Basically, my nice dragon scales looked like this:

Looks like Inkscape shares some attributes with inkjet printers! ;) To work around this problem,  I had to fiddle with the DPI/rendering resolution until I stumbled upon something that renders correctly. Ew.

Also, it seems Inkscape gets real sluggish on a Core2 Quad when you have a LPE with 9785 nodes on top of a dozen layers with masks and blur effects. And yet, somehow, I was surprised. Can you believe how demanding I have become of computers? :)

All in all, hats off to the Inkscape project. A great app, easy to pick up, stable, and a joy to use. You provided me with lots of fun in the past few days.

1. La capacité d’utiliser un langage naturel, tel que “defer:20100224″ ou “due:vendredi” (et on peut quand même utiliser les mots clés en anglais, c’est généralement plus court: “due:friday”);
2. La capacité de «reporter» une tâche;
3. Un mode «vue de travail», qui fait en sorte de masquer toutes les tâches reportées, qui ne peuvent pas encore être commencées ou qui dépendent d’autres tâches. Dans mon cas, c’est la différence entre avoir 130 tâches devant les yeux et en avoir 30. C’est fantastique, ce que ça permet et termes de «focus»;
4. Un système de «tags», avec la possibilité d’exclure certains tags de la «vue de travail»;
5. Un bouton «Marquer comme fait» qui est, naturellement, jouissif.

J’aime GTG. J’adore GTG. Voilà pour l’introduction que je voulais faire depuis des mois (autant faire d’une pierre deux coups).

Maintenant, si vous appliquez la technique GTD et que vous n’habitez pas sous une roche ou que vous n’êtes pas une délicieuse moule, vous avez probablement au moins cinquante tâches en tout temps dans votre système. Dans mon cas j’en traite des centaines par année. Par exemple, depuis que j’ai commencé à utiliser GTG «à plein temps» il y a quelque mois, j’ai clos environ 170 tâches.

Ayant quelques notions de performance tirées de Federico et eu une découverte désagréable avec les documents récents de GTK+ il y a un certain temps, et constatant que GTG conserve toutes les «tâches accomplies» par défaut, je sentais venir le désastre.

Eh bien, depuis la version 0.2.2, Getting Things GNOME a maintenant un greffon (plugin) de nettoyage automatique des tâches accomplies. On peut exécuter le nettoyage manuellement ou lui dire de s’effectuer tous les X jours.

«Mais Kiddo, est-ce que ça fait une différence?»

Eh bien oui. J’ai pris quelques mesures avant et après (130 tâches actives, 171 tâches accomplies):

• La taille du fichier XML est passée de 120,7 Kio à 56,0 Kio;
• Le nombre de lignes dans le fichier est passé de 4948 à 2221;
• Le temps de démarrage «à chaud» est passé de 15,0 (±0,5) secondes à 7,2 secondes. Les mesures ont été prises sur un netbook (Dell Mini 9) avec un processeur Atom et un SSD relativement lent. Sur un core2quad, on s’en foutrait un peu.

C’est donc un greffon obligatoire pour tous les utilisateurs intensifs de GTG qui préfèreraient ne pas penser à la poubelle.

[Illustration de Maëva Pierre]

Cependant, à la manière de Kant face à Hume, les billets de plus en plus radicaux de mon aimé comparse Antistress m’ont sorti de ma torpeur ce matin pour vous rédiger un contre-argumentaire. Des positions d’évangéliste comme celle-ci, je commence à en voir un peu trop. Je suis donc là pour faire l’avocat du diable et prendre la défense de Mono (Yorda pour les intimes). Attachez vos tuques, ce billet va être plus long que je ne l’avais prévu.

Clarifions certaines choses avant de commencer:

• Je ne suis PAS un fan de Mono.
• Je suis un fan du logiciel libre.
• J’ai déjà été un fervent évangéliste du logiciel libre, je me suis adouci dans les dernières années.
• J’ai déjà codé (en Python, PHP) et mon implication dans certains projets est d’assez longue date (PiTiVi en 2004, anyone?).

Je ne cherche pas à convaincre les argumentateurs anti-mono de soudainement lâcher prise. Je suppose que ce sont de bons chiens de garde et qu’ils ont leur utilité. Je cherche simplement à rétablir un certain équilibre et à susciter la pensée critique du lecteur, par rapport à notre écosystème de brevets en général et par rapport aux «factions» du logiciel libre (radicalisme vs pragmatisme). Ce qui m’inquiète, c’est un unilatéralisme dans la pensée et le groupthink. Je suis moi-même de ceux qui oscillent entre les deux camps, capable d’adhérer aux arguments des deux partis.

Même si mon but était de convaincre ceux du camp anti-mono, ça serait probablement peine perdue; ce truc là est aussi enraciné qu’une religion. Je m’adresse plutôt à ceux qui se situent entre les deux camps. Ceci est un exercice de réflexion et une catharsis.

C’est Mono! Fuyons!

Il n’y a pas d’autre solution. On ne transige pas avec les monstres. Je n’utilise pas de logiciels «Monoïsés» (quelle belle connotation négative)! Tout ce qui est écrit en C# est un danger pour nous.

Tel est le discours tenu par les plus fervents attaquants de Mono. Je le comprends. C’était celui que j’entretenais dans mon esprit initialement lors de l’annonce du partenariat entre Novell et Microsoft il y a quelques années. J’y reviendrai plus loin dans ce billet.

La chasse aux sorcières

Dans le bon vieux temps, on jetait les sorcières dans l’eau, et si elles flottaient, alors c’était la preuve qu’elles étaient des sorcières. Il faut croire que la natation (la programmation en C#) n’était pas une activité bien vue des gens. Quel choix cela laisse-t-il à la sorcière (Mono)? Si tu flottes, tu vas mourir brûlée/torturée. Si tu coules, ben… t’es morte noyée de toutes façons. Oups.

Peu importe ce qu’on dira à ceux du camp anti-logiciels-possiblement brevetés, ils ne seront pas satisfaits… parce que c’est ce qui arrive quand on acquiesce la validité du construit théorique que sont les brevets logiciels.

Je ne peux m’empêcher de repenser à cette scène de Monty Python and the Holy Grail. Voici une transcription abrégée pour ceux qui ont du mal avec l’anglais (britannique, qui plus est):

Sir Bedevere: How do you know she is a witch?
Villager 1: She looks like one!
Sir Bedevere: Bring her forward.
Woman: I’m not a witch! I’m not a witch!
Sir Bedevere: Uh, but you are dressed as one.
Woman: They dressed me up like this!
[...]
Sir Bedevere: What makes you think she is a witch?
Villager 2: Well, she turned me into a newt!
Bedevere examines the villager and sees that he is clearly not a newt.
Sir Bedevere: A newt??
Villager 2: …I got better.

(la foule crie, “Burn her!”)

Sir Bedevere: Quiet, quiet, quiet, quiet! There are ways of telling whether she is a witch. Tell me: what do you do with witches?

(d’autres cris: “Burn her!”)

Sir Bedevere: And what do you burn apart from witches?
[...]
Villager 1: Wood!
Sir Bedevere: So why do witches burn?
Villager 2: Be…cause they’re made of wood??
Sir Bedevere: Good! So how do we tell whether she is made of wood? Does wood sink in water?
Villager 3: No, no!
Villager 1: No, it floats! It floats!
[...]
Sir Bedevere: What also floats in water?
[...]
King Arthur: A duck!
Sir Bedevere: Exactly! So, logically…
Villager 3: If…she…weighs the same as a duck…she’s made of wood!
Sir Bedevere: And therefore…?
Villager 1: A witch!

L’évolution d’un évangéliste moyen

Au fil des années, j’ai constaté un phénomène. Je ne suis pas certain de ce que j’avance (je n’ai pas de données quantitatives solides sous la main, c’est pas mon sujet de thèse de doctorat), mais voici: la très forte majorité de ceux qui rhâlent sont des utilisateurs, et non des dévelopeurs. Et la majorité de ces utilisateurs qui rhâlent sont des nouveaux sur la scène (ou plutôt, l’audience). Évidemment, l’inverse tient toujours: certains développeurs sont radicaux tout comme certains «utilisateurs vétérans» (comprendre: plus de 5-10 ans) sont toujours radicaux même après le passage du temps. Mais je crois que la majorité des opposants de Mono sont des «bleus». Bon, mon but n’est pas de faire une attaque ad hominem, la question n’est pas là. Ce que je veux dire, c’est qu’une bonne portion de ces «bleus radicaux» risquent de s’adoucir avec le temps, comme je l’ai fait et comme beaucoup d’autres l’ont fait. Vivre et laisser vivre. Beaucoup d’évangélistes suivent une progression telle que celle-ci et finissent par adopter une position modérée et généralement plus efficace.

Un autre phénomène en place est celui des minorités vocales. Les «Croisés du Libre» qui cherchent l’exclusion de Mono sont ceux qui vont gueuler sur les forums, les blogs, les mailing lists. Ceux qui sont neutres (ou ceux qui sont optimistes, même) sont typiquement ceux qui n’iront pas se joindre au flamefest et envahir les zones de discussion. Les Croisés du Libre se reconnaissent par leur pose impressionnante et leur détermination qui tient de l’héroïsme:

[Illustration: One a day 34, par Saejinoh]

Les développeurs, quant à eux, se situent majoritairement dans la majorité silencieuse. Ils sont bien trop occupés à coder. Ils sont les fourmis de notre monde. Ils travaillent d’arrache-pied, dans une aire de tranquille plénitude. Leur éditeur de code est une clairière à l’abri du vent hurlant dans les plaines et les montagnes desquels crient les vigies. Ils vont au front sans mot dire, chevauchant un… hum.

[Illustration: Putin, par Subeo]

Bon, j’arrête la prose, c’est pas tellement ma force je suppose :)

En gros, s’ils pouvaient le faire, beaucoup de développeurs se lèveraient et diraient ceci:

Même, certains développeurs (pas tous, évidemment) ayant conçu des logiciels spécifiquement dans le but de contourner Mono, tels que le fameux Gnote (fréquemment utilisé comme argument anti-mono) vous diront que ce n’était pas pour des raisons philosophiques/une question de brevets, mais purement pour des raisons techniques. Et c’est la seule raison valide que je reconnais pour choisir Mono ou non. The best tool for the job. Pour certains développeurs, c’est Mono. Pour d’autres, c’est Python. Pour d’autres, c’est le C ou le Java.

The peanut gallery

(définition sur Wikipedia)

Un argument connexe que je veux amener, et attention, ça va être plus virulent/inflammatoire, est le suivant: êtes-vous celui ou celle qui produit le logiciel? Non? Alors get off my lawn.

Qu’est-ce que cette arrogance et sentiment «d’ayant-droit»? Boycotter un logiciel libre qui est écrit en C#, et le crier sur les toits par la suite? Qu’est-ce que vous pensez que les développeurs en ont à cirer, que vous l’utilisiez ou non? Ça pourrait fonctionner pour un logiciel payant. Pour un logiciel libre qui est également gratuit, pas tellement.

Rendu à un certain point, il faut se poser la question «est-ce que ce que je dis à l’autre est quelque chose qui le rend plus heureux» et si ça en vaut la chandelle.

Mais Microsoft / patent-troll-342987 va s’en servir pour nous attaquer!

Si on accepte le construit théorique d’un «brevet logiciel», alors ils peuvent déjà le faire, Mono ou pas. Et l’ont déjà fait avec le kernel Linux (avec des âneries comme proclamer qu’il enfreint 235 brevets de Microsoft). On est toujours en vie. Le Kernel est toujours bien portant. Ou peut-être préfèreriez-vous utiliser GNU Hurd pour être vraiment «à l’abri»? En fait, vous devriez immédiatement cesser d’utiliser Specto (que j’ai écrit, sans prendre soin de ne pas enfreindre de brevets, irresponsable que je suis). Vous devriez également cesser d’utiliser OpenOffice.org, Samba, VLC, MPlayer, la quasi totalité de GStreamer (ouais, je suis totalement convaincu que vous n’installez rien d’autre que gst-plugins-good et gst-plugins-base, hein?), Inkscape, Blender, … en fait, pour être vraiment en sécurité et vraiment libre, vous devez vous débarrasser de votre ordinateur et vos biens, et rejoindre notre secte.

Ironiquement, Antistress, dans son argumentaire contre Mono, dit ceci (je cite entièrement le paragraphe pour ne pas y faire injustice):

«Il est exact que tout brevet logiciel constitue une menace pour les développeurs, mais cela ne signifie pas que tous les brevets logiciels représentent la même menace. Différentes sociétés sont susceptibles d’avoir des brevets qui pourraient être utilisés contre d’autres langages, mais si nous nous inquiétions de chaque brevet qui pourrait être utilisé contre nous alors nous ne ferions plus rien. Les brevets de Microsoft sont bien plus dangereux : de toutes les principales sociétés informatiques, c’est la seule société qui s’est déclarée en guerre contre GNU/Linux et a fait part de son intention d’utiliser ses brevets contre notre communauté. Si Microsoft prépare un piège avec ses brevets sur C#, ça n’est rien d’autre que la mise à exécution de ses menaces.»

Ouais. En ce point, je suis moi-même radical: pour moi, les brevets ne sont pas «plus ou moins» risqués. Leur existence est un risque dichotomique. Aucun logiciel n’en est exempt (hé, après tout, même le double-clic et le simple clic sont brevetés).

Chercher à rédiger un code source exempt d’infractions sur un quelconque brevet détenu par Microsoft ou un “patent troll” relève de l’impossible, et est un premier pas vers la phobie (note: je parle de manière imagée; rien à voir avec la psychologie clinique ou mon champ d’étude). Comment ne pas être paralysé (ou du moins engourdi) dans son élan créateur si l’on vit dans l’anxiété constante d’enfreindre une «idée»? Les «artistes», s’ils reconnaissent la légitimité de la propriété intellectuelle, sont asujettis au même genre de bêtise (pas le «droit» d’utiliser un certain enchaînement mélodique utilisé dans une autre chanson, par exemple).

C’est intenable. Tout comme il n’y a pas une infinité de façons d’enchaîner trois notes de musique, il n’y a pas 65535 façons de rédiger du code pour faire une opération particulière. Breveter une façon de faire, dans un logiciel, serait breveter un vers d’un poème ou une formule mathématique.

Pour revenir à l’argument d’Antistress, il existe essentiellement deux positions anti-brevets:

• Certains logiciels sont à risques plus que d’autres, il faut donc considérer chaque logiciel au cas-par-cas (position d’Antistress)
• Tous les logiciels sont à risque, alors autant les ignorer et utiliser son énergie pour des choses plus productives ou se débarrasser entièrement du problème (ma position)

Ma position est celle qui fait normalement partie de notre subconscient, c’est une réalité qui fait mal et que l’on se refuse d’accepter. Je crois que la seule solution «à long terme» est de se battre pour que les brevets logiciels ne soient jamais reconnus où ils ne le sont pas déjà, et se battre pour qu’ils soient abolis aux États-Unis d’Amérique. Good luck with that.

Le reste n’est que tourner autour du problème. Je sais, c’est un peu déprimant. Je réalise également qu’en affirmant cela, je me positionne moi-même comme le radical opposé de ceux que j’appellais jusqu’ici les radicaux. Quelle belle ironie.

L’argument des «autres pays», inversé

Argument intéressant d’Antistress:

«Les brevets logiciels sont légaux dans d’autres pays et, dans la mesure où la communauté des utilisateurs et développeurs de logiciels libres est mondiale, il serait égoïste de se servir de logiciels brevetés en sachant que d’autres n’auront pas ce droit. En outre, nous devons éviter de diviser la communauté pour ne pas l’affaiblir.»

Qui êtes-vous, Croisés du Libre, pour dire aux autres nations comment fonctionner? L’égoïsme ne serait-il pas d’imposer qu’ils se conforment à cette logique? C’est en quelque sorte imposer/valider que ces pays «restent» dans leur système de brevets (j’y reviendrai dans un instant) et imposer, sur le reste du monde qui n’est pas asujetti aux brevets logiciels, des restrictions arbitraires et métaphysiques? D’un autre point de vue, pourquoi devrions-nous souffrir pour des systèmes législatifs étrangers corrompus? Ceci ne leur fera pas de bien. Et c’est là que j’amène ma deuxième inversion d’argument.

«Paradoxalement, pour éviter que les brevets logiciels ne soient un jour reconnus en Europe, il faut éviter d’utiliser des logiciels brevetés. Si les utilisateurs privilégient des logiciels non brevetés, ça réduit l’intérêt des brevets et ça diminue donc le risque que ça arrive chez nous (moins d’intérêts financiers en jeu, donc moins de lobbying de la part des détenteurs de brevets). Tout se tient.»

Au contraire. Éviter d’utiliser des logiciels asujettis aux brevets (ce qui est une impossibilité, comme je l’ai dit plus tôt), ou, plutôt, «éviter les logiciels que l’on perçoit comme plus à risques d’être asujettis aux brevets», peut aussi bien avoir l’effet inverse, parce que:

1. Ceci donne de la crédibilité au concept de brevet logiciel;
2. Ce n’est pas en boycottant bêtement des logiciels dans son salon qu’on empêche «l’invasion de l’Europe». C’est en se battant au niveau législatif/politique. Et ça, c’est beaucoup, beaucoup plus difficile que de simplement boycotter dans son salon.

Je veux que la situation des brevets empire aux États-Unis. Contourner le problème ne la fera pas empirer assez. C’est seulement lorsque la bulle pète qu’un changement législatif sera possible. Et pour ça, il va falloir que ça aille très, très, très mal, au point où c’en est encore plus ridicule que ça ne l’est déjà.

Je reviens également à ce bout de phrase du premier argument qui m’a fait sourire:

«En outre, nous devons éviter de diviser la communauté pour ne pas l’affaiblir.»

Eh bien, c’est précisément ce que vous faites en démonisant Mono et les logiciels libres «à risque». Je vois exactement où Antistress veut en venir avec son argument, qui se penche sur le côté législatif, mais je souhaite simplement souligner que le même argument peut être vu de manière totalement opposée, qu’il y a une manière différente de «diviser la communauté»: en ostracisant les projets «monoïsés» et en validant par le fait même le concept de «brevet logiciel».

Ouf. Moi qui voulais faire une tirade en deux ou trois paragraphes. C’est loupé, j’ai certainement assomé la majorité des lecteurs. Et hamster me dit que j’ai passé 4 heures et demie à rédiger cet essai .__. Je vais m’arrêter ici, j’ai d’autre pains sur la planche.

J’espère avoir suscité des réflexions socio/philosophiques. «Lâchez vos coms», mais comme dirait Ploum, «poster un commentaire n’est pas une obligation. Rappelez-vous de tourner 7 fois votre clavier dans votre bouche avant de poster». Les commentaires anti-mono sont les bienvenus (spécialement s’ils réussissent correctement à démolir mon propre contre-argumentaire, ça sera intéressant), mais si je vois un commentaire d’insultes ou d’attaque ad hominem, je supprime. J’espère que la blogosphère francophone saura s’élever au-dessus de ce que je vois courramment dans la blogosphère anglophone chaque fois que Mono est un sujet de discussion.

P.s.: Antistress, t’es sympa, et cet énorme billet n’est en aucun cas une attaque dirigée vers toi en particulier, mais plutôt une réflexion sur ce que j’observe dans la «communauté». Si tu trouves des failles dans ce que j’avance, tant mieux, mes lecteurs en bénéficieront :)

• Touched approximately 70 bugs or more today (out of ~230 initially), spending approximately 5.5 hours doing bug triaging and hunting (according to hamster)
• Confirmed many unconfirmed bugs
• Updated target milestones (even for already fixed bugs!)
• Added keywords (and added “Special searches” to the website)
• Reassigned components (so that Brandon can easily search for bugs that are related to the user interface)
• Closed a ton of obsolete/fixed/duplicate bugs.

Damn, this feels good. I hope Edward won’t be mad at me for doing the cleanup and flooding his inbox while he was on vacation.