Image de Chandler Reed, citation d’un livre que vous connaissez sûrement

Au-delà de l’Internet

Pour commencer, je n’ai jamais eu confiance envers le pouvoir médiatique. De ce que j’avais pu conclure du visionnement de Manufacturing Consent: Noam Chomsky and the Media, ainsi que mes réflexions dans mon parcours scolaire, j’étais à la base vacciné. Le tout m’a été confirmé comme étant un phénomène bien réel au printemps 2011, lorsque j’ai vu des choses capitales être sciemment auto-censurées par Radio-Canada et toute la presse francophone québécoise. Par son écrasant pouvoir, le système médiatique a alors réussi à renverser le gouvernement en place, sur une histoire que les journalistes savaient fausse (« mais on s’en fout, ça fait notre affaire, si je vais à contre-courant je vais me faire crucifier sur place de toutes façons »).

Tout ça pour dire que je prends tout ce qu’on me dit avec une grande dose de scepticisme et de questionnement. Ce qui compte n’est pas ce qu’on me dit, mais comment on me le dit ou ce qu’on ne me dit pas. Assez contextualisé maintenant, amorçons le sujet du jour.

Les tabloïdes du libre

Je croise parfois des gens qui jurent par certains sites de nouvelles pourtant reconnus parmi les cercles des « faiseurs » (de logiciels) comme étant des tabloïdes, c’est-à-dire de « presse à sensation », de la presse boulevardière, de la fiction pulpeuse. Étant donné l’immense pouvoir d’influence que détiennent ces sites, leur rôle semble donc osciller entre « alliés » et « épines dans le pied ».

Avec une déconcertante régularité ils se fourvoient, créent de fausses rumeurs, discréditent certains projets libres et font l’éloge de certains logiciels propriétaires (tant qu’ils sont excitants et « shiny »).

Je cite ici les principaux coupables que j’observe régulièrement:

• Phoronix
• OMG! Ubuntu
• Slashdot, dépendamment du moment et des commentateurs. Je lis Slashdot (seulement la catégorie Linux) principalement pour les commentaires parfois hilarants et souvent déprimants. Au final, la majorité des nouvelles « à sensation » ou visant à créer la controverse… émanent de Phoronix, qui les poste sur Slashdot pour avoir du traffic.

Il y en a sûrement plein d’autres dont vous pourrez me faire mention, mais pour l’instant j’aimerais simplement donner ceux-là en exemple.

Phoronix: le site où M. Larabel poste en moyenne 8 à 12 articles par jour (!), typiquement en s’auto-spammant de liens vers ses propres articles et en soumettant chaque controverse à Slashdot pour le plaisir des barbus qui ont une dent contre projet XYZ, la Free Software Foundation ou autre.

On me dira que l’intérêt principal de Phoronix, c’est ses bancs d’essais de matériel. En théorie, c’est effectivement intéressant d’avoir un site centré sur le matériel pour Linux. En pratique, cependant:

• Habituellement, les résultats annoncés sont statistiquement non significatifs. Dans à peu près tous les articles par exemple, vous verrez une ou deux images par seconde de différence (sur un total de 30, 50, 100 images par seconde) pour un test graphique XYZ entre deux distributions, ou encore une demie seconde de gain de vitesse de compression d’un fichier d’archive qui prend trois minutes à décompresser… bref, des nombres et des graphes vides de sens dans le « monde réel », qui permettent toutefois de générer des articles constamment.
• La méthodologie de mesure de la Phoronix Test Suite est à vérifier. J’étais excité de faire mes propres tests avec PTS lorsque le pilote libre r600 est apparu circa 2010, mais j’ai découvert par le fait même que les résultats n’avaient absolument rien à voir avec ce que je mesurais dans la réalité! En effet, j’obtenais, en testant manuellement au lieu d’utiliser PTS, plus de deux fois le framerate dans Urban Terror avec les réglages graphiques au maximum, alors que la PTS les réglait au minimum. Depuis, je n’ai plus confiance en la représentativité des mesures de PTS. Si on peut me prouver que ce n’est plus le cas de nos jours, j’en serais plutôt content.

Bref, il y a fort à douter sur les mesures effectuées par la Phoronix Test Suite lors des bancs d’essai. Ce qui nous laisse alors la deuxième partie du site: les « actualités »… et là, c’est pas joli à voir. De mémoire récente:

• Les sondages (aux échantillons non-représentatifs de la population) qui servent d’exutoire aux diatribes et permettent d’affirmer que tout le monde déteste passionnément GNOME [1, 2]
• Ciel! Fedora 19 va utiliser Cinnamon comme environnement de bureau par défaut, et inclure le kernel FreeBSD! Excepté que ce n’était pas vrai, ce n’était qu’une idée lancée aléatoirement sur une page de wiki.
• Des mentions à répétition au fil des années comme quoi Lightworks est un « logiciel open source » (même à l’intérieur des autres nouvelles concernant Openshot, Cinelerra, Avidemux, etc.)… ce qui est encore à ce jour faux. Soit, la vaste majorité des sites Internet commettent la même erreur… Est-ce que Phoronix admet l’erreur lorsque quelqu’un se donne la peine de l’indiquer, cependant? Non monsieur. On poste un nouvel article qui place le blâme sur l’autre, en l’intitulant « Lightworks Is Not As Open As Some Would Like » (emphase ajoutée) et en terminant l’article par une mention insinuant que, de toutes façons, les logiciels libres dans le domaine sont tous à chier. Bon, moi, au final, ça ne me fait ni chaud ni froid, je préfèrerais d’ailleurs ne pas donner en exemple un tel article de Phoronix qui pointe vers un de mes propres billets de blog — ça donne faussement l’impression que je tiens une rancune personnelle envers Phoronix, ce qui n’est pas le cas. J’utilise cette anecdote seulement pour illustrer comment les rédacteurs de tabloïdes tordent les mots pour nous faire dire n’importe quoi et se déresponsabiliser autant que possible. Si ça peut vous rassurer, le cas ici était relativement isolé, comparativement à ce qu’on voit tout le temps de la part de Sam Varghese chez ITWire, par exemple.
• Apparemment, qu’un illustre développeur de KDE poste un billet énonçant son scepticisme face à l’approche de Canonical concernant le Ubuntu Phone constitue, aux yeux de Phoronix, du bashing. N’oublions pas le link-spam obligatoire à travers Slashdot. Dans l’instance présente, les commentateurs de Slashdot ne sont pas dupes.
• « Tiens, pourquoi ne pas rappeller que projet XYZ n’avance pas? Si on peut essayer de discréditer la FSF, tant mieux! Alors si c’est pas pour rhâler envers l’état des logiciels de montage vidéo, autant basher Gnash parce que ces maudits hippies ne travaillent pas assez vite ». Et pour s’assurer de bien éclabousser la FSF, on va vous pointer vers de multiples liens d’articles internes similaires qui continuent la longue lignée.

OMG! Ubuntu: ne rentrons pas ici dans l’énumération exhaustive des nombreuses histoires à sensation et de « hype » autour de logiciels propriétaires ou n’existant même pas… observons simplement quelques perles récentes:

• Un article originellement intitulé « Photoshop CS2 available for free, works fine in WINE »… suivi du « Oups, en fait on a sauté dessus la nouvelle avec l’empressement habituel, c’était complètement faux ».
• Un joli petit vox populi après avoir diabolisé Nautilus 3.5+. Pas étonnant que tout monde ait vu rouge vu le traitement honteux que OMG! Ubuntu en a fait. Je cite: « Amongst the features you will find missing in the version of Nautilus (now renamed ‘Files’) are ones you may have used on a daily basis, including:
  • Compact View: removed
  • ‘Type Ahead Find’: removed
  • ‘New file’ templates: removed
  • Application Menu: removed
  • ‘Go’ menu: removed
  • F3 split screen: removed
  • ‘tree’ view: removed
  • Bookmark menu items: removed
  • Backspace shortcut to return to parent folder: removed
  • [...]
  • Default icons size set to 32px
  • New date-list view
  • Folders no longer sorted by default
  • Floating status bar »

Effrayant et révoltant, n’est-ce pas? Sauf que le tout a été volontairement rédigé de cette façon pour amener le lectorat à bondir d’indignation. Parce que si on prend le temps de réfléchir à l’effet global de ces changements, et qu’on se donne la peine de suivre les liens vers les commits que OMG! Ubuntu citait… on se rend compte que tout ça est plein de bon sens dans l’ensemble:

• Certains éléments de la liste n’ont en fait pas été enlevés, juste remplacés par quelque chose de mieux ou affichés uniquement au moment opportun. C’est le cas du « type ahead find », du « new file templates » (ben ouais, pourquoi montrer un menu quand il n’y a pas d’items dans ~/Modèles?)
• Application Menu removed, ‘Go’ menu removed, Bookmark menu items removed, etc.: tous le même truc, vraiment. Entièrement sensé. Ça s’appelle… se conformer au design du reste de l’environnement! Nautilus est le gestionnaire de fichiers de GNOME, n’est-il donc pas normal qu’il s’y intègre de la même façon que les autres applications « core »?
• Pour monter d’un dossier dans la hiérarchie… le raccourci officiel/standard a toujours été « Alt+↑ ». Je devine que le retrait du raccourci Backspace était pour améliorer la cohérence avec les autres applications comme Epiphany et pour empêcher les conflits avec la nouvelle fonctionnalité de recherche.
• Les véritables changements: le « treeview » a été remplacé par un « listview », la barre latérale a été simplifiée (et s’en trouve franchement plus robuste) et le mode « split panes » a été retiré. Ils étaient ridiculement buggés et ne me manquent pas le moins du monde, mais je suis probablement un des rares à penser celà. Sur ces points là, ça ne me dérange du tout qu’on soit en désaccord avec moi, c’est un débat légitime. Soit. Quand on y pense, c’est quand même pas la fin du monde.

…Le tout suivi d’articles indiquant que c’est tellement un désastre que Ubuntu pense à boycotter le nouveau Nautilus, si si ils y pensent vraiment.

Après ce genre de couverture médiatique « amicale », il y a eu du damage control obligé [1, 2] pour éviter un attentat à la bombe… Ce qui n’a pas empêché OMG! Ubuntu de continuer à jeter de l’huile sur le feu. Parce que la situation n’était pas déjà assez tendue.

Je vous épargne d’ailleurs un argumentaire assez long sur les principes d’échantillonnage et de validité statistique — principes que les sondages retrouvés sur les tabloïdes ci-haut ne peuvent fondamentalement pas respecter concernant des sujets controversés comme GNOME (le seul moyen serait d’avoir un échantillon véritablement aléatoire et représentatif aux allures d’un référendum planétaire).

Au final, puis-je vraiment les blâmer?

Les journalistes sont humains et ont essentiellement un travail de merde dans un monde de plus en plus frénétique.

Et là, je vous évite un bloc de texte immense, parce que quelqu’un a déjà fait tout le travail d’analyse de « pourquoi les journalistes se comportent comme ça!? » à ma place. C’est assez volumineux, mais allez voir cet article éventuellement: Cheap Tabloid Tricks: The Truth About Linux, Open Source And The Media.

La fin du monde annoncée sous diverses formes n’a pas eu lieu.

À en croire les sites de nouvelles, Nautilus 3.6 est un désastre, l’installateur (Anaconda) repensé de Fedora 18 est un désastre, et il y a une conspiration pour saboter nos logiciels favoris.

Pourtant, j’admire les améliorations et raffinements apportés à Nautilus 3.6 et je suis ravi du nouvel installateur de Fedora 18. Dans le cas de Nautilus 3.6, j’ai refusé de juger un logiciel par la mauvaise presse qu’on lui donnait et ai préféré donner la chance au coureur et l’essayer moi même, ce que OMG! Ubuntu ne s’est pas donné la peine de faire. Après un mois d’usage, je me sens plus à l’aise avec 3.6 et me sens irrité quand j’utilise la version 3.4. Clairement, je dois faire partie d’une minorité de mollusques fanatiques zélés qui accepte n’importe quoi. Je dois être fou.

Nautilus 3.6, le mangeur d’âmes nocturne

La lecture des commentaires est, vous le devinez, bien plus nocive que la lecture des articles: même quand un geek on ne peut plus conciliant se donne la peine d’expliquer pendant 55 minutes, de façon calme et raisonnable, les malentendus autour de projets controversés comme GNOME, la première chose que les gens vont faire sur Internet c’est de dire « De toutes façons c’est un connard, j’ai arrêté d’écouter à 7 minutes parce que ça me plaisait pas ». Tous des fascistes qui n’écoutent pas ce qu’on a à dire, ces développeurs!

Tout ça me fait présager que lorsque la prochaine version de Pitivi sortira (« un jour »), les commentateurs du net trouveront sûrement plein de choses pour dire que c’est un désastre. Même Joey de OMG! Ubuntu n’avait que ceci à dire lors de l’annonce de la dernière release d’Openshot: « Meh. » (traduction: « Bof/bah. »). Mais c’est pas grave, c’est l’Internet, personne ne sait que vous êtes un chien, et on s’en fout des sentiments des développeurs à l’autre bout, ils sont grands et costauds, ils s’en remettront!

Pour conclure

• Les sites de nouvelles similaires à ceux mentionnés précédemment ne doivent pas être considérés comme des sources fiables pour se former une opinion.
• Lire les critiques sur ce genre de sites est nocif pour votre bien-être mental. Spécialement si vous êtes un contributeur au Logiciel libre. Là-dessus, je vous recommande la lecture de ce billet de mon pote Federico (oui, ce Federico là). Rien de révolutionnaire, mais quand même une lecture intéressante pour comprendre le phénomène du blues du hacker. Des fois, les développeurs libristes souffrent également de dépression sévère [1] [2] [3]. Heureusement pour moi, ce n’est pas mon cas, je suis typiquement optimiste.
• Plutôt que de vous demander « Qu’est-ce qu’on me dit? », questionnez-vous toujours sur « Qu’est-ce qu’on ne me dit pas? », « À quel point les sources sont pertinentes? » et « Où est-ce que ça rentre dans le grand ordre des choses? »

When people trash the work you’ve been doing fully in the open for over a year and almost nobody stands up to defend you, you have to have a really tough skin. I can afford to read those articles with no ill effects because I have an emotional distance from the matter (not being closely related to the project, except in spirit), but otherwise, you have to swallow tears and quietly breathe fire in lieu of ragequitting, and continue improving your software for the next release. With the side-effects on user expectations from such a long development cycle, you start brainstorming ways to adapt the cycle to prevent such events from occuring again.

And yet, I’m sure there are many who are quietly happy or optimistic about the progress being made. I, for one, would like to focus on one particular aspect where my quality of life improved significantly with the new installer. Thanks to one of my favorite heroines and the hard work of the Anaconda team, the Fedora installer now allows you to set up your system with any keyboard layout supported by X.org. As usual, all it took was a crazy belgian pirate to stir things up.

As I’ve been waiting for a long time for this, I appreciate the work that has been done towards this goal. I’d like to thank Máirín for the research/followup work she did on the matter to ensure we could all switch to French Canadian Dvorak for F18. Now that is what I call customer service :)

By the way, if you care about usability/UX and haven’t added Máirín’s blog to your feed reader already, do it. Do it now. The posts in the Anaconda category are especially interesting for those who are willing to understand the long and elaborate design process that led to the new Fedora installer.

Following up on the 2012.9 “Amazon” release, this SDK release, codenamed “Brahmaputra”, reveals a natural pattern: akin to the river of the same name, it streams down from the Himalayas, brings the coolness downstream, keeps flowing and breathes life onto the lands.

Evening on the Brahmaputra River, by Vikramjit Kakati

A particularly interesting piece of land that now gets irrigated by the flow of GStreamer is the Android plateau (some say platform, but that’s less geographically-fitting!).

Yep, you heard that right, pioneers of the open world! The land of Android is now fertile, free and wide open to rapid development of multimedia applications with GStreamer. Go ahead and try it out today, let us know how it helps you Get Things Done—and how GStreamer can be made even better!

The SDK currently supports a bunch of Linux distributions, Windows (from XP to 8), Mac OS, and Android 2.3.1 and newer (some features such as hardware acceleration will require Android 4.1 or newer). It is fully documented, free as in both, and has a sexy website (what more could you ask for?).

However, after all these years, most of the blogs or news sites (including the most popular ones) still don’t bother checking for factual accuracy and just blindly accept what corporate press releases would have them believe. I would have thought they would have grown more careful with time, but the situation has generally not improved, to the point where I am now compelled to say this now, officially, in public: Lightworks is currently not open-source and never has been. Furthermore, if it ever is open-sourced, it most likely won’t be anywhere close to a truly open project.

From what I’ve seen by reading the comments on these articles, the Lightworks forums or elsewhere, it seems that those who point out the very issue that I’m about to explain are routinely labelled as ungrateful, arrogant freetards or considered trolls to be banned. It is my hope that you will read this blog post with an open mind, and that you might see where I’m getting at with the last section.

The source code that never saw the light

EditShare announced two years ago their intention to make Lightworks “open-source” someday, and that’s it. They have never released any source code since then. A code drop was planned for 2011 and it was postponed indefinitely. Calling Lightworks an “award-winning open-source video editor” currently is a lie. Even if they do open-source it someday, until the very day they do so, that statement remains a lie. Such a statement can only be a “truth” when you start saying it after the source code has actually been released under an open-source license.

Until then, you can’t simply trust a corporation on that promise without some cautious skepticism. They have a ton of business imperatives and constraints: the bottomline, strategic direction, competition, logistical and legal challenges, investors to answer to… and virtually no compelling reason to open-source their product (we’ll come back to that further below).

Although I do have some faith that they might release it eventually, personally, after two years of waiting, I’m even beginning to doubt that. I’m not saying that EditShare wishes to do evil or just throw a marketing ploy together; I heard the numerous justifications/excuses along the lines of “we’ve got bigger priorities”, “we have a reputation to uphold” and “we’re stuck in legal review”, I just don’t buy those arguments.

Anyway. Whether or not not you believe they will release the source code someday is irrelevant, that’s not the point I want to make here in the first part. The point is: until then, it should not be considered open-source and should be treated with the default assumption that it may never be. If you see articles spreading inaccurate statements along the lines of “Lightworks is an open-source video editor” or “Lightworks, the professional non-linear video editor that was open-sourced in mid-2010” (instead of “Lightworks is supposed to be open-sourced sometime in the next decade, according to press releases”), please comment and request the authors to correct or back their statements with references to publicly available source code repositories. We cannot stand by while untrue statements are being repeated all over the place, it is a disservice to the public.

What if they do release the source code then?

Most likely scenario: it won’t change a thing.

• It’s a million lines of code (compare and contrast)! Good luck attracting people to work on such a monster codebase with 20 years of history. Most of which has been on the Windows platform (some of which on DOS… before that, I don’t know). Those of you who have done software maintenance know what this means. If projects with clean, modern and simple codebases like Pitivi struggle to attract any developers at all, don’t expect a “community” of benevolent hackers to form around your project anytime soon.
• The open source version will be crippled. As far as one can understand from their communications and their pricing page(see the image further below), there would be three editions: the open-source edition, the “free” (freeware) edition, and the “pro” edition. Currently, only the “free” and “pro” editions are available. The open-source version probably won’t support anything but, say, Theora and Vorbis. It wouldn’t make sense to have the “open-source” version have support for the codecs that their “free” edition currently offers:
  

  The upper portion of the comparison table between the free and pro version

  • They can’t just bundle patented codecs for Free. Licensing those (if you can license those) is typically done on a “number of installations” basis and with limits on redistribution. You can’t do that with fully free and open-source software on which you have no control over.
  • They won’t switch their plumbing to use GStreamer or ffmpeg/libAV, for various obvious reasons (technical, manpower, QA, control, legal, etc.).
  • A significant part of their business model will be to differentiate the “freeware/premiumware” version from the fully “open source” (crippled) version. You want proprietary codecs? Pony up. This is how it works pretty much everywhere, and arguably, this is what their clients expect and accept. And that’s fine. As I said, it makes sense. For them and their intended clients.
  • Ignoring the whole codec issue for a minute, it is possible that the “open-source edition” will be only a portion of the application (ie: “crippled”). Anything that touches DRM, trade secrets, whatever, might be stripped out—it’s hard to tell currently, as no source code has ever been released. If the current differences in featureset between the “Free” and “Pro” versions are any indication, then this might be a real scenario.
• It won’t cater to those who want a simple, native application that is well-integrated with their desktop environment. Or those who want a workflow for on-set redundant assets management as their top priority (Novacut). It will only solve the problems of a particular niche.
• Community-wise: there are many ways Editshare can screw their community management (see further below).
• With all that in mind, it would be very surprising to see the open-source edition start appearing in your official Linux distribution repositories.

I might add some amusing observations from trying the beta:

• You’re forced to accept a EULA with a restrictive (non-free, non-open-source) license, which just confirms my points above about the various “editions”. However, do take note that the Lightworks beta was explicitely not the “open source release”. Again, that’s not the license the open-source edition is meant to be released under. Nobody knows what the chosen license will be at this point in time.
• Lightworks is riddled with DRM and copy protections. It refuses to run in a virtual machine (such as VirtualBox) and cannot be run in a debugger (because it would be a threat to its copy-protection mechanisms).

Why would they even still care?

The typical Lightworks demographic usually doesn’t give a damn about the code being open-source. That’s secondary. They just want software that is reliable, efficient, supports their crazy formats, and is reasonably priced (bonus points if it’s free or very cheap, given the competition from other pro-level packages). “Open source”? Nice to have in theory, cool for bragging with friends at the pub, but not much else. Kinda like saying that you’re using a “green” product. The typical Lightworks user is never going to study or modify Lightworks source code.

With that in mind, what does EditShare hope to achieve? They’ll be lucky if they get more than two crazy geeks to hack benevolently on the code outside of their official paid developers. I know because I’ve dealt with open source projects for years, and even those that are incredibly well-managed and welcoming to contributors struggle to attract and retain them. EditShare is aware of this, and they express it with some snobbism (warranted, to some extent):

Of course users want software that’s written by us at this stage. Is there anyone other than the original developers of Lightworks, and the best of developers that have moved across to us from other products, who are better placed to move Lightworks forward? Of course there are great Open Source developers out there, but they would be working from a standing start.

This is a specialist and complex product. We are not going to release it to Open Source until it is ready. Do to otherwise would cause untold issues.

It is quite clear that they are expecting to shoulder the whole burden of development and maintenance. If someone else bothers to investigate a bug and send them a patch for it, they’ll certainly consider it, but I’d be surprised to see them giving “commit access” to anyone else than themselves (but hey, who knows). If my guess is correct, we’ll just be inheriting another Cinelerra (except that the base application is arguably of much higher quality this time).

Open-source “product” vs open-source “project”

This subtle distinction is probably only obvious to those who are familiar with the open-source ecosystem (don’t flame me for my choice of words here, I’m trying to be comprehensible to the average person!), but there are countless ways in which EditShare LLC can screw up their “community” before even considering technical details like the ginormous codebase. They can screw up their licensing, they can try to exert too much control over the direction of the project, they can do like HeroineVirtual with Cinelerra and just release a monolithic code drop every six-to-twelve months, they can do like Sun/Oracle did with OpenOffice.org, like Canonical with their copyright assignment clauses, like Google does with its “read-only” open-source development model for Android, etc. That’s just from the top of my head.

It’s not the first time we see a company try to “open-source” a product and mess things up. And so far, EditShare has had a terrible track record when it comes to communication, multiple delays and broken promises, and just being clueless about how to properly interact with the “open” world generally speaking: the fact that they hyped their upcoming Linux alpha launch for months and then suddenly revealed, at the time of the release, that they were releasing it only to a select few insiders… All that without foreseeing the harm it would do to their already strained relationship with the public? That’s just pitiful—and terribly far from Kdenlive, OpenShot, PiTiVi, and all the others whose development has occurred fully in the open from the start.

The greater ecosystem: being a good open-source citizen

An open-source project is not about throwing together a pile of code and slapping a copyleft license on top of it. It’s about a superior software development model (given equal manpower) where you foster reuse and collaboration with other open-source projects. It is about being a living cell of an organism, an active part of an ecosystem.

Lightworks might be released under an open-source license someday, but unless they rewrite the whole application (which would make no sense), it’s still going to be one monolithic “bundle everything, do everything in-house” piece of technology.

This has all sorts of technical implications I won’t be getting into. More importantly however, there are some absolutely crucial implications on the greater scale of the “Free Software ecosystem” that I must mention.

When you contribute to open-source projects that have been doing things “the open-source way” (that is: depending on shared libraries and contributing to them—be it testing or providing fixes upstream), such as Pitivi/Kdenlive/OpenShot/etc., you end up fostering the use and improvement of the technologies that are the heart and soul of your open-source desktop/operating system.

• In the long run, you end up improving GTK+, Qt, GStreamer, Webkit, Pango, FFmpeg/Libav, GES, MLT, Cairo, X/Wayland, goocanvas, Clutter, GLib, the icon themes and artwork… the list goes on.
• Recently, over the course of two months, Pitivi contributors have reported (and often fixed) more problems in GTK+, GLib and PyGObject than EditShare could ever hope to achieve in a lifetime—and that’s not even taking GStreamer into account.

Lightworks, as far as I know, doesn’t use any of these. Improvements you make there will not find their way to your desktop or mobile device. Whatever you do with Lightworks stays within Lightworks—and that’s it.

• Update: it is claimed in the comments below that Lightworks does use Cairo and Pango.

If you take “collaboration with the greater cause” out of the equation, one might argue that you could just as well have bought a package on the shelves for 80$ way back in 2003, instead of spending years hoping for an open-source “project” to solve your problem. Unsurprisingly, that’s what many people do.

Recently, a significant piece of the puzzle has been fully solved in PulseAudio 2.0: real, rock-solid acoustic echo cancelling. Echo cancelling is not to be confused with echo concealment/suppression, which is basically just muting the other person while you’re talking (most phones and software applications—including Skype—do that, and it sucks).

As Christian nicely summarized, audio/video calls over the past few years have been a complex story. Unless you are close to GStreamer and Telepathy developers, it’s hard to see the big picture. Christian’s blog post is thus helpful, but I think it does not truly express how mindboggingly awesome this feature is, from a “What? Computers can do that? With Free Software?!” perspective.

A test call through XMPP/Jabber with Google Talk accounts. Notice that the echo-cancelled virtual device shows up in the GNOME volume control panel during the call. Yes, I cheated and used gnome-tweak-tool to change the control center’s colors to the dark variant.

Let me put it this way: I unplugged the headphones, called my laptop, put it into the garage, closed the door and went back to the previous room with the phone. I spoke, and I thought it was broken because the echo cancellation was working too well. I could not hear myself nor any audio artifacts. When I fetched someone else to go speak in front of the computer, it turned out that there was simply no echo whatsoever. Jaw on the floor. And that was with the laptop’s crappy 1-watt speakers; I then called across the globe to Bangalore, with my trusty USB microphone and 5.1 sound system, and it felt just like the other person was in the same room as me.

It works even if there’s ambient noise. The only way to confuse the echo canceller is to be in the same room with both the phone and the laptop. Not likely, unless you like talking to yourself.

Finally, no more fumbling around to pick up a call when your gear is not plugged in. Conference calls the way they were meant to be. Hands-free discussions while cooking or in a car. Holy smokes, we’re only missing holograms and flying cars… Folks, you know what to do.

J’avais entretenu l’idée de ressusciter cet ordinateur pour un usage de serveur ou «media center» ou autre chose en live USB, mais ce n’était qu’une idée. Récemment, l’ami en question a décidé de tenter la chose et s’est procuré une clé USB, amenant le coût total de la réincarnation à environ 10 dollars.

J’ai d’abord tenté de faire fonctionner le tout simplement en créant un live USB Fedora 16 «persistant», malgré les limitations inhérentes de cette approche, comme le fait que l’espace ne se libère jamais même si on supprime les fichiers:

One very important note about using the “primary” persistent overlay for system changes is that due to the way it’s currently implemented (as a LVM copy-on-write snapshot), every single change to it (writes AND deletes) subtracts from its free space, so it will eventually be “used up” and your USB stick will no longer boot

… puis j’ai rencontré une embûche qui avait échappé à ma planification: la carte sans fil était une Broadcom 4312 (donc nécessitant un module kernel non-libre).

Utilisant mon téléphone android (acheté d’occasion l’été dernier) pour partager la connexion WiFi par USB, je tentai néanmoins d’installer «akmod-wl» de rpmfusion (c’est le paquet pour faire marcher les chips Broadcom sous Fedora. Oubliez les kmod-wl). Cependant, une fausse manipulation mit l’ordinateur en veille, et il ne voulait plus se réveiller correctement par la suite. Comme le barbare que je suis, j’ai croisé les doigts, éteint de force et redémarré le système… pour constater que le système de fichiers de la clé USB était corrompu.

Après quelques minutes de réflexion pondérées de «FFFUUUU», j’ai retourné le problème dans un sens moins conventionnel. Le «live USB» n’est pas la solution. «Installer vers la clé USB» est la solution.

Il nous faut donc utiliser deux clés USB:

• L’une pour booter et lancer l’installation
• L’autre (une clé 16 GB vierge, sans aucune partition dessus) qui sert comme cible d’installation. Il a fallu la partitionner comme suit: une partition de type «BIOS BOOT» de 2 MB, une partition swap de 50 MB (juste parce que Fedora insiste pour me faire croire qu’il faut plus d’un gigaoctet de mémoire pour installer… donc à désactiver post-installation) et le reste en ext4.

… et ça marche. Après l’installation, j’ai effectué quelques hacks pour améliorer la performance et augmenter un peu (en théorie) la durée de vie de la clé USB:

• Modifier /etc/fstab pour désactiver le swap et ajouter l’option «noatime» à la partition /
• Désactiver presto dans /etc/yum/pluginconf.d/presto.conf
• Désactiver le firewall et selinux
• Supprimer abrt

Après avoir fait fonctionner la carte sans-fil Broadcom, il ne restait qu’à appliquer les ~400 mises à jour, rajouter LibreOffice et les plugins GStreamer. Heureusement que j’avais désactivé presto et fait effectuer cette opération durant mon sommeil: le tout a nécessité un peu plus de six heures (processeur Atom N270 et lenteur de clé USB obligent)!

L’aspect intéressant de tout ça est que nous sommes maintenant en présence d’un véritable système d’opération USB portable, sans les limitations d’un live USB persistant conventionnel. Peu importe dans quel ordinateur on le branche. C’est quand même pas mal moins cher qu’un «Cotton Candy» quand on y pense.

Last week, Lars Lindner provided us with an early christmas gift when he announced that a new stable release of our beloved feed reader was now available. First, I would like to applaud him for his continued efforts over the years in maintaining this handy and high quality application. Many users like me have been patiently waiting for the 1.8 release in the hope that it would finally solve the infamous performance problems of the 1.4 and 1.6 series. However, while I can’t speak of the performance once the app is launched, the startup performance has not met my expectations (in some cases, it has regressed). This blog post is intended to share my findings (which I discussed with Lars) and to invite you to comment on possible solutions.

Here’s an introduction to the problem:

• An average Liferea user is expected to have hundreds of feeds and thousands of unread items (I have about 200 feeds and 2500 unread items). From discussions I’ve had, this is not considered excessive by Liferea standards.
• Liferea uses SQLite as a database for storing feed data into a single “liferea.db” file. Mine currently weighs 115 Mo in its vacuumed form. SQLite has this terrible tendency to suck because you need to vacuum (compact) it every once in a while or the performance degrades terribly. Firefox has the same problem.
• There also was ext4 as a suspect, although from all my tests on that matter in the 1.6 series, ext4 was definitely not the culprit. An ext3 partition had the same performance problems (or, at least, the same Liferea startup times).

On a beefy machine with a Core2Quad CPU, 4 GB of RAM and SATA2 hard drives, the only thing that made my 45-50 seconds startup time go down was… buying a solid state drive. Then, the startup time went down to about 10 seconds. I could live with that.

Enthusiastic about the prospect of a 1 second startup time (and a pony), I did not wait for Liferea to be packaged in my favorite distro and compiled it myself. Then I realized that not only had startup times stayed mostly unchanged on a conventional hard drive, they actually increased with the solid state drive. Here are my general startup times (with repeated measurements to ensure validity):

The hard drive times went down slightly, but the SSD times went way up (compared to a 10 seconds cold start time in 1.6). Whatsmore, for both the HDD and SSD, the “warm start” times are almost the same as the “cold start” times! What’s going on here?

Luckily, liferea has a built-in profiling system. You can use “liferea –debug-performance”, or even “liferea –debug-performance –debug-db” to get measurements of individual operations. Liferea will tell you if any particular function call is slow. I’ll spare you the details of my analysis (ie: how I determined the total count, which functions to ignore/merge together, etc. This is left as an exercise for the curious reader) and show you the pretty executive charts:

As we can see, the things that stick out first are VACUUM, doing the “default source import” (parsing the .opml xml file containing the list of feeds?) and counting the unread items. I have about 200 feeds, each requiring 0.02 second to count unread items on a conventional hard drive (notice how the solid state drive completely nullifies this? :).

…Wait a second, VACUUM?! In previous Liferea releases, vacuuming the database was never done by the application, users had to do it themselves. But now, Liferea 1.8 vacuums automatically on startup.

Let’s represent this breakdown in a different way:

Vacuuming eats between 33 and 80% of the startup time (HDD vs SSD). We now have some explanations for our initial observations:

• Liferea has seen some performance optimizations that probably improve startup times.
• Those using solid state drives do not truly benefit from these optimizations, but are heavily affected by the newly added “vacuum” operation. Result: startup times went up.
• For users with conventional hard drives, the optimizations improved startup times (I think) but vacuuming increased startup times, thus masking those improvements. Result: startup times stayed mostly the same.

By disabling the vacuum (commenting out the code), Liferea now starts in 4.48 seconds on my computer. That’s night and day.

Back in 2008, Lars himself thought that vacuuming automatically was not a good idea:

“The problem with it is that it also takes very long. With a 50MB DB file I experienced a runtime of over 1 minute. This is why this can be only a tool for experienced users that know how to do it manually knowing what to expect. For executing such a long term operation automatically on runtime would surely be unacceptable to the unsuspecting user. Also there is no good way how to decide when to do a VACUUM to save disk space and improve performance.”

Here’s a key rule about software performance optimization: performance problems are very often “needless work done at the wrong time”.

I’m no database expert (correct me if I’m wrong), but as I understand it, running vacuum everyday provides no significant benefit (it only provides a benefit when there’s a significant amount of stuff to vacuum). If you’re vacuuming on every startup, you’re using a nuclear weapon to dig a hole in a small garden.

Well, here’s the problem:

1. You can’t vacuum while you’re actively using the application (as it blocks the database).
2. You can’t vacuum when Liferea exits. According to Lars, “Liferea is too often killed by the session manager or [computer] shutdowns”.
3. You can’t vacuum on startup “only once in a while” because, according to Lars, “if a program is sometimes slow (because of VACUUM) and sometimes not, users will complain or cancel the slow startup. So not doing it everytime is no real option.”

Short of finding a magical database backend that never hits those kinds of issues, here’s the potential solution I came up with:

1. We already have a way to measure the startup times. Make it so that Liferea measures its startup time on every startup even without debugging mode.
2. Factor in the count of items in the database, and the filesize of db file. [insert clever mathematical formula here]
3. Once startup is done, if the startup time was unreasonably/statistically slow, offer to vacuum the database to improve performance.

An unintrusive infobar widget could be shown to the user:

Yes, imposing the responsibility of database performance optimization onto the user sounds like a bad idea… but I think we can agree that Liferea is a special case: it is an application that is meant to handle huge amounts of ever-changing data over time. It is not entirely unreasonable, in my humble opinion, to present the user with this occasional, unobtrusive prompt.

Of course, we should avoid nagging the user about it:

• If the user clicks Optimize, do not ask again for at least a few weeks/month.
• If the user clicks “Later”, do not ask for a few days.

As I said in the beginning, this blog post is intended as a summary of my findings and as a call for the collective wisdom of the hive. I know there’s a lot of very smart developers out there who might know of a solution we haven’t thought of.

What do you think? Is there a better way (be it in terms of backend scalability or in terms of UI/UX)?

Le présent billet a pour but de partager, à la demande populaire et pour mes amis curieux, mes notes/observations sur ma migration d’Ubuntu à Fedora. Évidemment, je ne peux pas couvrir de manière exhaustive tous les cas d’utilisation, seulement les choses les plus saillantes qui m’ont embêtées. Somme toute, une fois ces soucis résolus, je me plais à utiliser Fedora 15 (et bientôt Fedora 16).

Quelques différences par rapport à Ubuntu/Debian

• Comment arrêter gdm: “service prefdm stop” (pas de service nommé “gdm”)
• Nano et Wget ne sont pas installés par défaut, et nano n’est pas utilisé comme éditeur de texte par défaut même s’il est installé. Il faut mettre un export EDITOR=nano dans son ~/.bashrc. Ugh.
• La commande rename a une syntaxe différente (elle n’utilise pas des regex comme sous Debian): au lieu de rename “s/2011_/blah/” *.pdf, on utilise: rename “2011_” “blah” *.pdf
• Installer les paquets de débug pour un logiciel donné: sudo debuginfo-install nom_du_logiciel (il n’y a pas de paquets “*-dbg” visibles directement dans les dépôts)
• Les paquets de dépendances de compilation sont suffixés de “-devel”, pas “-dev”
• Yum met sa liste de dépôts à jour automatiquement lorsque vous tentez d’installer ou mettre à jour des paquets. C’est bien du fait qu’on n’a pas besoin de réfléchir et que c’est automatique, mais ça finit par énerver du fait que ça n’utilise pas de diff binaire et que ça prend donc un temps fou à chaque fois.
• Les noms des paquets, dans Yum ou PackageKit, sont sensibles à la casse. Par exemple, tenter d’installer “virtualbox-ose” ne fonctionnera pas, il faut “Virtualbox-OSE”. WTF, seriously. Je sais pas qui a bien pu se dire un jour que ça serait une bonne idée.

Les dépôts supplémentaires

• RPM Fusion free (équivalent de “universe”)
• RPM Fusion nonfree (équivalent de “multiverse”)
• Dépôt Adobe officiel: 32 bits et 64 bits
• Dépôt Chromium non-officiel: voir les instructions

Quelques optimisations potentielles

• Désactiver presto si vous avez plus de bande passante que de puissance de traitement (pratique sur les netbooks ou ordinateurs plus âgés): éditez le fichier /etc/yum/pluginconf.d/presto.conf
• Pour les aventureux qui trouvent yum trop lent, essayez zif (un outil fait maison par Richard Hughes, auteur de packagekit et de tout ce qui a “kit” dans le nom, sauf les Kit-Kat): yum install zif PackageKit-zif
• Installer gnome-shell-extensions-* (du moins, toutes celles qui vous intéressent; lisez les descriptions)

Abaisser la sécurité (si le coeur vous en dit)

Je sens qu’on va me flamer pour recommander de telles hérésies, mais SELinux et le pare-feu sont franchement excessifs pour une utilisation de bureau typique.

Le pare-feu me gêne constamment. Comme je suis derrière un routeur qui remplit ce rôle, je le désactive entièrement. D’ailleurs, par défaut il empêche avahi (aka zeroconf) de fonctionner correctement, qui casse empathy, mes accès SSH locaux et mes profils unison.

Il en va de même pour selinux qui est une source infinie d’emmerdements (je roule pas les serveurs de la NSA, j’ai pas à être si paranoïaque que ça)… En fait, il y a une blague qui dit que si, sous Windows, la réponse typique est «Avez-vous redémarré votre ordinateur?», l’équivalent Fedora est «Avez-vous désactivé SELinux?».

• Pour désactiver temporairement: echo 0 > /selinux/enforce
• Pour désactiver de manière permanente, éditer /etc/selinux/config et changer la ligne SELINUX=enforcing à SELINUX=permissive
• Notons que faire un “disable” (au lieu de permissive) aurait, semble-t-il, d’autres conséquences (mais je n’ai jamais eu de problèmes avec ça… au contraire). Voir le bas de cette page.

Désactiver le login root du serveur SSH

Sous Fedora, le root login à travers SSH est permis par défaut (c’est un peu débile à mon avis), donc il faut le désactiver dans /etc/ssh/sshd_config

Les paquets de modules de kernel automatiques

Si on veut faire fonctionner une de ces infâmes cartes sans fil Broadcom, il faut installer akmod-wl, pas kmod-wl (de rpmfusion). Du moins si on veut s’éviter des modules qui cassent lors de mises à jour de kernel, ou des problèmes de dépendances quand on est dans une version de test de Fedora. Il en va de même avec les modules nvidia, par exemple. Source: fedoraforum.

This image is now published in the contributing section of PiTiVi’s website (as if you did not have enough arguments already! What are you waiting for? Come here and help us rock the world!).

Oh, and gnuclad is awesome.