Non, sérieusement, WTF? Suis-je le seul à trouver louche le fait qu’en dix ou vingt ans, les fraises aient quintuplé en volume? Ok ok, croisements génétique, OGM, etc… mais quand même. Tout est plus gros ces derniers temps en Amérique du nord (je sais pas ailleurs).

Les fraises, dans la nature (au Lac Saint-Jean par exemple), c’est maximum deux centimètres de diamètre, pas sept centimètres minimum!). Les bleuets* qu’on voit dans beaucoup de supermarchés font deux centimètres de diamètre (au lieu de 0.5-1 cm)… l’énormité ne relève plus de l’exceptionnel, c’est la norme. Dans quelques générations, personne ne saura que ce n’est pas la taille «naturelle» (prenons exemple de la sélection génétique de l’épis de maïs). Franchement, ça donne quelques frissons dans le dos et des pensées nostalgiques par moments. Quand j’étais jeune…

* contrairement aux fraises géantes, les bleuets géants ne goûtent habituellement presque rien. On dirait que c’est gonflé d’eau.

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!

• http://www.businessinsider.com/category/facebook
• Well, these new Zuckerberg IMs won’t help Facebook’s privacy problems
• Facebook Privacy: A Bewildering Tangle of Options

Software patents are nonsense. We should destroy them into oblivion, we should not try to comply or circumvent them. I won’t base my open source software choices on vague McCarthyist patent “risks” (or even threats).

That is all.

This is from the daily build PPA, svn revision 22377. Yeah I know, it’s not officially supported by the Chromium devs… I wonder if it’s a bug, a silly joke, or an exploit. It’s both funny and scary at the same time.

A friend of mine was asking me to investigate why Firefox alwas hung when quitting on his Dellbuntu today. After an hour, I found out the culprit:

See, the horrible thing with databases such as SQLite (according to my limited understanding) is that you have to keep vacuuming them manually all the time because they keep growing exponentially. Liferea suffers the same, and the author seems to have no other solution than manually vacuuming. Evolution having recently started using a sqlite database for mail indexing too is worrying me.

Is this a disease? Somebody explain to me how come it spreads like wildfire when we have such horrible drawbacks? At least, from what I’ve seen by glancing in ~/.config/chromium, Chromium doesn’t use this.

Best. Screensaver. Ever.

1. Je préfère, «s’il y a une alternative égale», éviter les applications en .net/Mono
2. Hubert est un maniaque de performance (à ce que j’en sais). D’où le choix du C++ au lieu de mono/python/java/etc.

C’est sur ce point que je m’attarde aujourd’hui, ayant réalisé un petit banc d’essai pour comparer la performance des deux applications.

Méthodologie

• Mesurer le temps de démarrage (±objectif): ce dernier est ici considéré comme le temps écoulé entre le moment où je lance la commande («time tomboy» ou «time gnote») et le moment où l’icône apparaît dans la zone de notification (où je fais ctrl+C immédiatement).
  • Faire cette mesure lors d’un démarrage à froid, c’est-à-dire après avoir flushé les caches du kernel (sync && sync && echo 3 > /proc/sys/vm/drop_caches)
  • Faire cette mesure lors d’un démarrage à chaud, c’est-à-dire après trois démarrages consécutifs de l’application
• Mesurer subjectivement la performance d’écriture de grosses notes: GNote gagne haut la main, ne montrant aucun problème de performance perceptible, ce qui n’est pas le cas de Tomboy (bonjour le bug vieux de trois ans).
• Les tests sont effectués sur les mêmes fichiers «.note» copiés de ~/.tomboy/ vers ~/.gnote/, c’est-à-dire 135 éléments, totalisant 296,0 Kio de fichiers XML.

Résultats

Toutes les mesures sont des mesures approximatives de temps de démarrage en secondes; comme je devais manuellement interrompre le processus pour que time s’arrête, j’estime la marge d’erreur à ±250 ms. Notez également que cette étude se base sur l’hypothèse que «lorsque l’icône dans la zone de notification apparaît, on considère l’application chargée et prête à servir», ce qui, en soi, est à vérifier. Je crois néanmoins que malgré cela, la différence de résultats entre les deux applications est tellement monumentale que l’on peut considérer la marge d’erreur expérimentale comme négligeable.

À froid (après avoir flushé les caches):

• Tomboy = 12.110s
• GNote = 5.138s

À chaud:

• Tomboy = 2.394s
• GNote = 0.909s

Vendu. Je passe à GNote quand il pourra créer des liens automatiquement pour les expressions.