Une mise à jour ratée, drivers nvidia

Cela faisait longtemps que je n’avais pas eu de problème avec arch linux. Aujourd’hui, grosse mise à jour, à cause de java qui nécessitait une intervention manuelle. Par flemme d’aller voir sur leur site web, j’avais laissé trainé pendant deux semaines.

Je réalise donc la petite manipulation, et tout se met à jour comme prévu. Je redémarre le PC et là c’est le drame, mon PC reste en mode console, pas d’interface graphique. Première sensation à chaud, c’est juste la grosse déception que de nos jours on puisse en arriver là suite à une mise à jour, dans ma tête c’était un gros « Non, ce n’est pas possible, quel blagueur ce linux« . Dans le doute, je redémarre à nouveau, sait-on jamais. Pas de chance, même problème.

Cela a commencé à me faire chier, je voulais tout simplement utiliser mon PC pour faire un truc et me voilà bloqué sur un problème à la con car personne n’est capable d’assurer qu’une mise à jour ne cassera pas le système. Je me suis déjà imaginé à devoir tout réinstaller, d’ailleurs un petit backup du système sera fait bientôt.

Bref, d’expérience, c’est le paquet nvidia qui doit causer problème. Un petit coup d’oeil dans les logs:

[ 756.591] (EE) NVIDIA: Failed to initialize the NVIDIA kernel module. Please see the
[ 756.591] (EE) NVIDIA: system’s kernel log for additional error messages and
[ 756.591] (EE) NVIDIA: consult the NVIDIA README for details.
[ 756.591] (EE) No devices detected.
[ 756.591] (EE)
Fatal server error:
[ 756.591] (EE) no screens found(EE)
[ 756.591] (EE)

C’est là qu’on apprécie d’avoir pris le temps de bien configurer le mode console basique (le bon layout de clavier). Un petit downgrade de nvida avec un grand merci ma tablette pour l’aide du wiki sur comment downgrader, un petit reboot, et le problème… n’est pas résolu.

Là je me dis que c’est un peu la merde. J’ai pensé à la nouvelle version du noyau linux (3.17), mais la mise jour était mineure (3.16.3-1 -> 3.16.4-1). Au début je me suis qu’une mise à jour mineure ne peut pas virer des drivers, mais ne voyant pas d’autres solutions « faciles », ça ne coutait rien de downgrader le noyau.

Un petit reboot, et ça marche… gros WTF. Maintenant une mise à jour mineure peut faire péter un driver. J’ai envie d’accuser la distribution, mais elle utilise les paquets upstream, on peut facilement suivre ce qui a changé dans le paquet entre la 3.16.3 et la 3.16.4. Il n’y a pas grand chose à part l’URL de la nouvelle version upstream.

On pourrait presque en déduire que c’est donc l’upstream (les auteurs originaux) responsable de ce problème. Mais cela pourrait être aussi nvidia (nvidia 340.32-1 -> 340.32-2, nvidia-utils 340.32-1 -> 343.22-1, nvidia-libgl 340.32-1 -> 343.22-1).

Peu importe le coupable, c’est juste ridicule! C’est surement le revers de la médaille d’utiliser une distribution en rolling release, même si la distribution n’y est pour rien. Sur une autre distribution, le problème arrivera peut-être lors d’une mise à jour majeure quand le noyau changera. Du coup, fuck linux.

La solution temporaire est d’interdire la mise à jour des paquets linux et nvidia*… jusqu’au prochain épisode.

J’en profite pour ajouter les désagréments habituels. Pourquoi la mise à jour de bash m’a fait perdre tout mon historique ? Le fichier .bash_history de mon compte utilisateur (non root) est devenu vide… Mais celui d’autres utilisateurs n’a pas changé…

Pourquoi le fichier /usr/share/X11/xkb/symbols/fr écrase mes modifications au lieu de faire comme tous les autres fichiers en créant un fichier .pacnew.

Et aussi, putain, pourquoi formater une clé USB est si compliqué ? J’ai eu à le faire pour m’en servir pour une imprimante/scanner pour scanner un document (car hors de question de faire marcher le scanner avec linux, je n’avais pas envie de jouer à la chasse au trésor). Et merde, un clique droit dans Dolphin ne propose rien de cela. Quand on pense que Windows a ajouté enfin l’option triviale et énormément demandée de monter une image ISO en un click sans avoir à installer de logiciels tiers, et bien sur linux (KDE) il n’est même pas possible de formater facilement.

Publicités

KDE Baloo indexeur de fichier

Mise à jour de linux, mon PC s’est mis à ramer comme pas possible lors du prochain lancement. Comme par hasard en utilisant Firefox. Au bout de quelques minutes, je lance un process monitor (iotop) et je vois baloo, c’est là, c’est le drame. C’est le putain d’indexeur de fichiers.

J’avais déjà désactivé Nepomuk car c’était de la pure merde, ordinateur inutilisable. Ben ici c’est pareil, c’est quoi qu’ils n’ont pas compris dans un indexeur de fichiers ? Peut-être que la solution est d’utiliser une priorité faible de processus qui ne freeze pas l’user interface des applications, de ne pas lire comme des fous tous les fichiers d’un coup pour mettre les acces disques en disk freeze pour les autres applications. C’est le minimum qu’on attend d’un indexeur de fichier, d’être discret.

Cela me fait penser à tous ces autres logiciels (digiKam, Gwenview, etc) où le minimum que l’on peut attendre du logiciel n’est pas présent.

La solution:
mv /usr/bin/baloo_file_extractor /usr/bin/baloo_file_extractor.orig
ln -s /bin/true /usr/bin/baloo_file_extractor

mv /usr/bin/baloo_file_cleaner /usr/bin/baloo_file_cleaner.orig
ln -s /bin/true /usr/bin/baloo_file_cleaner

chmod ugo-w ~/.local/share/baloo

Sur un autre post, on peut lire que baloo avait généré 14 Go de données avant que le mec trouve comment désactiver cette merde.

La solution la plus élégante: éditer $HOME/.kde4/share/config/baloofilerc et mettre false pour la clé Indexing-Enabled.

Grosse déception de KDE sur ce coup là, rien n’a été appris avec Nepomuk. C’est ma deuxième grosse déception de KDE avec Katepart.

Trouver les plus gros fichiers sous linux

En ligne de commande, ce n’est pas évident, je connais la command du, mais je me dis qu’une recherche web sera plus rapide. Cela a été le cas, je suis tombé sur un article d’un bloggeur que j’ai déjà critiqué: Korben.

J’ai même ouvert le second résultat de la recherche, mais le site a mis trop de temps à se charger. Du coup, me voilà avec Korben et sa commande magique:

du -hms /home/manu/* | sort -nr | head

Il ne faut pas se leurrer, bloggeur hi-tech, on se dit qu’il s’y connait et tout en linux, et que si il donne cette astuce soudainement c’est qu’il a du en avoir besoin. Surtout que son prénom est Manu et qu’il s’en sert pour lister les fichiers de l’utilisateur manu.

Et bien c’est FAUX. Dans les commentaires, krusaf montre que la commande originale était:

du -hs /home/manu/* | sort -nr | head

Ce qui produisait un résultat incorrect… La seule option que je connais de du c’est bien l’option h pour human readable, qui affiche la taille du fichier avec son unité de mesure la plus adaptée. Du coup, le tri se faisait sur les données qui n’étaient pas dans la même unité.

Alors, à moins d’avoir peu de fichiers, sa commande il n’a pas du la tester. Mais à cela, on remarque que dans la version corrigée il y a seulement une option qui a été ajouté, l’option m, sauf que cette option rend complétement inutile l’option h. En effet, cette nouvelle option force l’affichage en méga octets. On peut donc enlever l’option h et cela cela devient:

du -ms /path/* | sort -nr | head

Mais quand on donne une astuce, il est bon de rappeler à quoi servent les argument avec leur version longue, la voici:

du --block-size=1M --summarize /path/* | sort --numeric-sort --reverse | head

Et c’est testé et approuvé par moi-même. Du coup, en enlevant l’option –summarize, cela permet de rechercher dans les sous-dossiers, ce qui est bien pratique aussi. Et comme ce n’est pas expliqué sur le blog de notre célébre bloggeur, le résultat est en méga octet comme expliqué tout à l’heure.

Je trouve honteux que le mec débarque, donne une astuce non-testée trouvée ailleurs, et en vante ces méritent comme si cela lui avait rendu service. J’appelle ça prendre ses lecteurs pour des cons, cela fait un bout de temps que je lis plus Korben et je m’en porte beaucoup mieux.

Gwenview, supprimer un fichier

Parfois j’ai vraiment l’impression de rêver. Je trie tranquillement des photos avec Gwenview (4.12.2), je supprime des photos, puis sur une photo j’ai un doute, je décide d’annuler la suppression, je vais naturellement dans Edit, puis Undo, car c’est comme cela que ça marche dans mon file manager Dolphin… mais l’action Undo est grisée… WTF. Je regarde dans d’autre menu, rien pour annuler la suppression. C’est une blague ?

Gwenview est une sorte de file manager pour image et est le logiciel par défaut de KDE pour cela, ne pas supporter l’annulation d’une suppression est tout simplement ridicule. Le fichier supprimé est heureusement dans la corbeille, mais à chaque erreur de suppresion, il faut sortir de l’application, chercher le dernier fichier supprimé, le restaurer. Un Edit, Undo est beaucoup plus rapide et répandu dans tous logiciels qui se respectent.

Je suis profondément déçu qu’après toutes les versions et l’état actuel avancé de Gwenview, il manque une fonctionnalité basique. Cela me fait penser à digiKam

Mettons des valeurs en dur

Cet article suit de très prêt le précédent dans lequel un programme inexistant de mon système était exécuté au lieu de choisir le programme par défaut équivalent. C’est ce que l’on appelle mettre une valeur en dur dans le code. Une sorte de launch(« /bin/nautilus ») même si ce programme n’existe pas et que le filemanager du système est /bin/dolphin.

Je parcourais mes mails de maillist KDE, et sur celle de KDevelop je tombe sur un cas similaire qui m’a fait exclamé: « mais putain il faut être con pour ne pas avoir prévu ça dès le début et attendre que quelqu’un se plaigne ».

Il s’agit de la configuration d’un port TCP. Finalement, c’est un peu comme le cas du gestionnaire de fichier, quand on developpe en pensant qu’on est seul sur Terre, ou pire, en pensant que tout le monde est comme soi, on pense que tout le monde a son gestionnaire de fichier dans /bin/nautilus.

C’est pareil pour un port TCP, on croit que personne ne change sa valeur par défaut parce que le dev lui-même n’a jamais eu un jour besoin de changer la valeur par défaut. Du coup le petit dev il s’est dit qu’il allait mettre la valeur en dur dans le code.

C’est comme ça que l’on arrive à ce genre de patch, en particulier ce fichier (et debugsession.cpp):

- program << "-d xdebug.remote_port="+QString::number(9000);
+ program << "-d xdebug.remote_port="+QString::number(remotePortSetting);

Ca fait froid dans le dos. Une personne a été bloqué à cause de cela par la fainéantise d’un développeur. Ce n’est pas comme si il fallait mettre en place tout un système de gestion de configuration/préférence puisque celui-ci existe déjà, il a suffit d’ajouter une nouvelle valeur dans ce fichier.

N’importe quel programme peut utiliser un port, alors penser qu’un port choisi sera libre chez tout le monde est complétement stupide. Surtout quand le port est un chiffre rond.

GTK 3 ? De la merde en barre

Petite mise à jour de mon système Arch Linux (début janvier 2014). Le lendemain, je lance TrueCrypt, je monte mon volume, et je double click dessus pour l’ouvrir dans mon File Manager habituel, mon cher Dolphin, le gestionnaire de fichier par défaut de KDE.

Mais c’est alors que… SURPRISE, une popup apparait pour me dire que « nautilus » n’est pas trouvé. « Nautilus » est le file manager de Gnome. Qu’est ce que ça vient foutre dans une environnement full KDE.

Après de multiple « fuck linux », je sais que ça vient de Gnome de merde et de GTK en particulier car Truecrypt utilise wxGTK (la belle erreur, très mauvaise intégration). Je décide de regarder ce qui a été mis à jour hier. Il faut savoir que pour le coup j’ai eu de la chance de m’en rendre compte rapidement, si cela avait été dans plusieurs semaines j’aurai eu beaucoup de mal à trouver l’origine du bug.

Voici donc les paquets intéressants qui ont été mis à jour:

[PACMAN] upgraded wxgtk (2.8.12.1-5 -> 3.0.0-2)
[PACMAN] upgraded truecrypt (1:7.1a-1 -> 1:7.1a-2)

J’ai commencé par regarder ce qui a changé dans le paquet truecrypt au cas où nautilus aurait été ajouté en dur dans le code (bien que cela m’aurait énormément étonné). Il n’y a rien de spécial à part les dépendances (le code n’a pas changé car « pkgver » n’a pas changé, l’incrémentation de « pkgrel » n’indique pas un changement de version du code)

Les dépendances indiquent un changement au niveau de wxgtk, et d’après la liste des paquets, wxgtk a bien été mis à jour aussi.

Je n’ai pas eu envie de chercher plus loin, je voulais juste m’assurer que les devs de truecrypt n’avaient pas fait les boulets en mettant un filemanager par défaut. Une fois avoir eu la confirmation que cela vient de GTK ou de wxGTK, je n’allais pas partir dans une croisade à la recherche de bugs.

J’ai tout simplement fait une chose horrible qui n’aurait du jamais voir le jour: j’ai créé un lien symbolique de /bin/nautilus vers /bin/dolphin… GÉNIAL.

Tous les logiciels GTK ne semblent pas capable de lancer l’application par défaut associé à un type de fichier. L’exemple le plus courant est Firefox. À noter que pour truecrypt, avant il y arrivait bien, mais ça, c’était avant.

J’avais un logiciel qui a toujours bien fonctionné (même si il était moche à cause de GTK), à un logiciel qui s’est retrouvé buggé du jour au lendemain. C’est ça linux, c’est ça GTK, du chacun pour soi.

Design pattern, quand on fait mine de savoir

L’open source est magique. Comment croire qu’on utilise quelque chose, être persuadé de l’utiliser, et le clamer haut et fort, alors qu’en fait c’est totalement faux.

CodeIgniter l’a fait. Le design pattern Active Record, qui consiste en gros à encapsuler les données d’une base de données dans des classes, est largement mis en avant dans CodeIgniter alors que c’est faux.

Tout d’abord, ils ont appelé leur librairie Active Record, rien que ça, comme le design pattern, et on lit:

CodeIgniter uses a modified version of the Active Record Database Pattern.

Le design pattern semble être connu, mais il est modifié comment ? Au point de ne plus rien avoir avec. J’étais curieux de voir leur méthode, puis au fur est à mesure c’était de la déception.

Les méthodes s’appliquent directement sur l’objet base de données, toutes les métodes, y compris l’insertion. Rien n’est digne du design pattern Active Record. Comment ont-ils pu avoir le culot d’appeler leur librairie comme ça ?

Wikipedia me rassure dans la définition, on peut lire:

CodeIgniter has a query builder it calls « ActiveRecord », but which doesn’t implement the Active Record pattern. Instead it implements what the user guide refers to as a modified version of the pattern. The Active Record functionality in CodeIgniter can be achieved by using either CodeIgniter DataMapper library or CodeIgniter Gas ORM library.

Merci, CodeIgniter possède juste un Query Builder (et ils auraient du appeler leur librairie comme ça). Voici comment on apprend des choses fausses aux personnes. Il faut toujours garder un regard critique.

Messages d’erreur ?

Je me suis longtemps intéressé à Dart, qui est sortie récemment en version 1, mais faire apprendre un nouveau langage à une équipe de développement ce n’est pas évident.

J’ai donc pensé à TypeScript, un sur-ensemble de javascript, un peu comme SASS pour le CSS, le code CSS est du code SASS valide, le code javascript est du code TypeScript valide. Cela a été un avantage clé pour SASS/Compass dans son adoption autour de moi, et si cela pouvait faire la même chose avec TypeScript ça serait nickel.

En effet, quand on utilise un sur-ensemble, on conserve l’existant en utilisant progressivement les fonctionnalités offertes au fur et à mesure de l’apprentissage. Pour sass/compass, cela a commencé clairement avec l’imbrication des sélecteurs css (nesting selector), puis au fur et à mesure par l’utilisation de variables, l’utilisation des mixins, la génération de sprites, etc. Au final, un gain de temps et de maintenance énorme du code CSS, et si c’était aussi possible avec le javascript ?

Mais avant, testons TypeScript. C’est du Microsoft et c’est pour cette raison que je ne me suis jamais trop intéressé à ce langage. Cela commence très mal sur la page d’accueil, cela parle d’un plug-in Visual Studio (sans lien) mais que d’autres éditeurs sont supportés (vim, emacs, sublime text).

Après tout, c’est normal qu’ils mettent en avant Visual Studio, sauf que connaissant strictement rien à Visual Studio je ne sais pas si c’est gratuit, je ne sais pas où chercher le plug-in et ni où le télécharger. Grâce à Google je trouve le lien vers la page de téléchargement, mais il me faut un compte Microsoft pour télécharger le truc. Pas grave, dans l’immédiat testons avec un éditeur basique.

J’ai suivi le tutorial, For NPM users:

$ npm install -g typescript
npm http GET https://registry.npmjs.org/typescript
npm http 200 https://registry.npmjs.org/typescript
npm http GET https://registry.npmjs.org/typescript/-/typescript-0.9.5.tgz
npm http 200 https://registry.npmjs.org/typescript/-/typescript-0.9.5.tgz
/usr/bin/tsc -> /usr/lib/node_modules/typescript/bin/tsc
typescript@0.9.5 /usr/lib/node_modules/typescript

Je commence par simplement créer un fichier vide pour tester l’installation, et je lance la commande indiquée:

$ touch test.tsc
$ tsc test.tsc
error TS5007: Cannot resolve referenced file: ‘test.tsc’.

Ok baby. Testons avec le chemin complet alors, c’est du microsoft après tout, et on est sur linux:

$ tsc /home/test/www/test/typescript/test.tsc
error TS5007: Cannot resolve referenced file: ‘test.tsc’.

OKAY, je me dis que le compilateur doit être trop con et qu’il met l’erreur parce que le fichier est vide, je teste en mettant deux conneries, même erreur, je mets ensuite exactement la même chose que le tutorial, même erreur.

Sur internet, je ne suis pas le seul. Le problème se produit depuis la version 0.9. La meilleure réponse indique que c’est à cause du charset, qu’il faut utiliser l’encodage unicode (UTF-8 en suivant le lien). Sauf que:

$ file test.tsc
test.tsc: ASCII text

ASCII est un sous ensemble d’UTF-8, donc ASCII c’est de l’UTF-8. Et pour la peine, j’ai même ajouté un accent en commentant une ligne:

$ file test.tsc
test.tsc: UTF-8 Unicode text

Et là franchement, je me suis dis que ce n’est même pas la peine que je tente d’intégrer cet outil dans une équipe de développement. Je sais que c’est une technologie en preview, mais d’après la roadmap, la version 0.9.5 est la dernière avec la release candidate. Et cela apporte beaucoup de déception si TypeScript ne fonctionne pas du premier coup sur linux.

Finalement, après quelques tests, je décide de renommer mon fichier test.tsc en test.ts puis suivre précisément le tutorial. Et là, magie, le fichier se compile.

Dans le compileur, l’extension est donc vérifiée. Putain de merde, et c’est écrit nul part bien sûr et le message d’erreur est totalement à la ramasse. Heureusement, c’es un projet open source, même si c’est du MS, et en effet, en éditant tsc.js, on peut voir:

function isTSFile(fname) {
return isFileOfExtension(fname, « .ts »);
}

Mais la véritable question, est pourquoi ne pas indiquer que le fichier ne possède pas la bonne extension, au lieu d’indiquer qu’il n’est pas trouvé… Messages d’erreur incompréhensible, bonjour.

Puis-je blamer TypeScript pour ça ? Cela ne m’a pas donner une bonne image de Microsoft..

On peut par contre noter l’avantage d’utiliser des codes d’erreur (TS5007) qui permet de trouver une solution peu importe la langue du message d’erreur. Par opposition à Git par exemple, où recemment (début décembre 2013) la traduction française a été disponible dans plusieurs distributions. Ce qui cause un problème majeur, car en cas de problème on recherche le message d’erreur retourné par git pour trouver une solution. En recherchant le message d’erreur français on trouvera donc moins de résultat (voir aucun). On peut donc noter l’expérience de Microsoft dans l’internationalisation (et les erreurs à la con).

Quoi qu’il en soit, le code d’erreur TS5007 est trop générique, il correspond à un fichier non trouvé alors que mon problème était à cause d’un fichier dans la mauvaise extension.

Mon intérêt pour TypeScript est aussi lié à Anders Hejlsberg, architecte du langage et connu pour Turbo Pascal et Delphi. En tant qu’ancien développeur Delphi, je me demande ce qu’il va faire avec TypeScript.

digiKam Le logiciel partisan

Digikam: Gérez vos photos comme un professionnel avec la puissance de l’open source

C’est ce que l’on peut lire en lançant le logicel. Une belle figure de style pour faire croire que l’open source c’est de la puissance qui permet de faire les choses comme un professionnel. Ben voyons voir.

Je me sers de ce logiciel uniquement pour copier les photos d’un appareil photo vers mon PC. Car l’appareil photo ne se comporte pas comme un périphérique de stockage de masse. Une solution serait d’extraire la carte SD et de la lire directement mais cela me fait assez chier de le faire à chaque fois, amusons-nous avec Digikam, un logiciel pour gérer les photos comme un professionnel ahaha oops.

Assez de bla bla, je n’arrive plus à me retenir, digiKam 3.5.0 n’a pas de système de cache !! Et la génération des miniatures fait lagger le scroll, du beau travail vraiment. Disons que c’est quand même la base d’un outil de gestion de photos numériques issues d’un appareil photos. Autant dans les projets merdiques où le developpeur ne va pas prendre en compte les gros fichiers car ce n’est pas le cas usuel (ou plus précisément puisqu’on parle d’open source, car ce n’est pas le cas du développeur). Mais dans un logiciel de photos, la prise en considération que les images manipulées fassent plusieurs méga-octets doit être les fondations du logiciel pour avoir de bonne performance.

Donc on se retrouve du coup avec un calcul des miniatures qui fait freezer le scroll. Que le calcul des miniatures soit lent, on ne peut rien y faire car il y a beaucoup d’images, mais il ne devrait pas figer l’interface. Et comme il n’y a pas de cache, les miniatures sont calculées à chaque fois quand on change de fenêtre! (heureusement quand on scroll dans la même fenêtre cela conserve le cache ouf).

Surtout que leur interface est du plus que pourri. Les photos sont sous forme de miniatures qui recouvrent toute la fenêtre, pour l’instant ça va, appelons ça l’écran principal. Je click sur une photo pour la voir en grand, l’interface change avec un bandeau en haut de miniatures plus grosses mais pixélisées (comme si elles étaient issues des miniatures de l’écran précédent, mais ce n’est pas le cas car on sent du lag), et en bas l’image en grand.

Déjà les miniatures en haut ne se calculent pas toutes, après un moment de réflexion, c’est parce que j’ai supprimé des photos (à partir de digiKam), donc magnifique bug de digiKam, hey, c’est la puissance de l’open source dans sa grandeur. Ensuite, pour une image non supprimée, l’image en bas ne s’affiche pas, il est écrit « Il est impossible de charger l’image », génial, alors que la miniature se calcule bien et que j’ai bien réussi à l’exporter. Du coup je click sur la zone du bas (là où l’image ne s’affiche pas) et cela me fait revenir à l’écran principal (la liste des miniatures) avec à nouveau le calcul de celles-ci. Inversement, quand on passe de l’écran principal à la visualisation d’une image, le bandeau de miniature n’est pas en cache également.

Bref, pour revenir à mon but qui était juste de copier des photos, ce logiciel m’a profondément casser les couilles car j’ai voulu voir au moins une à deux photos avant de copier et effectuer quelques suppression. Je vois dans les options que ce logiciel peut faire des choses évoluées, mais la base de la base d’un logiciel de manipulation de photos est complétement buggé à en faire honte, surtout pour une version 3.5 qui pète plus haut que son cul avec sa phrase d’accueil.

xdotool

Comme on vient de le voir dans l’article précédent, xvkbd, qui permet d’envoyer des touches à une application, fait planter lamentablement qtcreator.

J’ai cherché un remplaçant et j’ai trouvé xdotool. Il semble plus puissant et possède l’objectif d’automatiser les tâches: command-line X11 automation tool, je ne pouvais pas mieux rêver. Je reprends un exemple de la page man:

xdotool key ctrl+l

Que j’adapte pour un CTRL+C pour simuler la copie. Là c’est le drame, cela flood la lettre « c » non-stop. Par chance, en appuyant sur la touche Entrée cela met fin au bug. Je teste pour être sûr avec l’exemple officiel, et c’est la touche « l » qui est floodé.

Cela commence vachement bien. Qu’à cela ne tienne, peut-être que ce logiciel va me servir à la saisie automatique de texte. En effet, j’utilise une combinaison de touche pour écrire automatiquement les mots les plus courant que j’utilise, comme le mot clé function. Je reprends l’exemple officiel de la page man:

xdotool type ‘Hello world!’

A noter la différence avec tout à l’heure, le paramètre est à présent type au lieu de key. J’exécute telle quelle la commande. Résultat: « >foor ]rloiY » est tapé automatiquement. WTF!

À n’y rien comprendre, au début je me suis dit que cela provient du fait que j’utilise un layout bépo sur un clavier azerty. Mais rien à faire, les lettres ne correspondent pas à Hello world! malgré que ce soit le bon nombre de lettre. Le ‘H’ en azerty/query doit être un ‘C’ en bépo, or un ‘>’ a été saisi, par contre « foor » correspondent bien à « ello », surement un petit bug pour le « H » en majuscule ? Pareil pour le W de ‘World’, surement un bug pour toutes les lettres en majuscules ?

Après plusieurs tentatives et options pour trouver le bon résultat, ce logiciel a eu raison de moi. Tout simplement ras le bol que même des logiciels basiques fassent mal leur travail. Ras le bol que la fonction primaire du logiciel soit buggée à mort, comme si il n’avait jamais été testé. Ras le bol de l’environnement linux. Il ne faut pas s’étonner que même les personnes les plus motivées se tournent finalement vers Mac pour avoir un unix avec des logiciels fonctionnels.