Changement d’ABI, cassons les logiciels sans tester ni réparer

Une bonne news comme on les aime: https://www.archlinux.org/news/c-abi-change/. Mais qu’est-ce qu’une ABI ? Comme si c’était évident pour tout le monde. C’est Application Binary Interface.

Ok, l’interface binaire va changer mais l’ancienne est toujours fonctionnelle. Et puis le principe de l’open source est d’avoir justement le code source pour pouvoir tout recompiler en cas de besoin comme c’est le cas actuellement.

Ca tombe bien, TrueCrypt a été recompilé pour cette raison. Manque de bol, le logiciel ne fonctionne plus du tout.

C’est trop cool de mettre à jour un logiciel sans le tester. Ce n’est pas parce que ça compile que ça marche. 20 jours plus tard, problème toujours pas résolu.

Si le rapport de bug propose des solutions bizarres, le plus simple est le rollback puisque l’ancienne ABI existe toujours:

# cd /var/cache/pacman/pkg/
# pacman -U truecrypt-1:7.1a-2-x86_64.pkg.tar.xz

Ca, c’est fait.
Linux de merde. Ou plutot distrib de merde ? Ou encore Antonio Rojas (packageur) de merde ? Ou bien Rémy Oudompheng (le mainteneur, donc responsable) de merde ? « Monde de merde ». A coté, les problèmes de mises à jour de Windows 10 c’est du pipi de chat.

Publicités

KDE: la merde est de retour

Cela faisait longtemps que je n’avais plus eu de couille avec les mises à jour. C’était trop beau pour durer. KDE est passé à la version 5.6 début janvier. Le temps que ça arrive dans ma distribution (Arch linux), je fais la mise à jour fin janvier, et c’est la catastrophe.

Tout d’abord, c’est devenu moche. Le theme Oxygen ne peut plus être utilisé. Ca c’est fait.

Seconde chose qui se remarque très vite, la perte des préférences. Konsole n’a plus la police que j’avais choisi, et je ne suis pas le seul à avoir remarqué cela. Autre changement notable pour Konsole, c’est qu’à présent les onglets ne se restaurent plus au redémarrage. Je ne sais pas si il y avait une option avant, mais en tout je ne trouve rien dans les options actuelles.

Ensuite, le classique PC qui rame, comme d’habitude, c’est surtout après avoir lancé Firefox, avec l’expression typique: « oh non ils ont encore fait les bourrins chez Mozilla ». Le gestionnaire des tâches me montre le réel coupable: baloo qui s’est réactivé. Pas de problème, j’en avais déjà parlé, j’ai simplement à relancer les mêmes commandes. Ceci est la routine, rien de dramatique, mais cela vaut la peine de le signaler car cela s’ajoute à la pile de problèmes et cela peut facilement être la goute qui fait déborder le vase.

Dans la même session, Dolphin qui plante, à chaque fois, chaque jour au moins une fois. Première fois de ma vie que je le vois planter. Un bon gros freeze sans raison, je ne faisais rien dedans, l’application était en arrière plan tranquille, puis je retourne dessus et plus rien… Fantastique.

Peu de temps après, la découverte que vagrant ne fonctionnait plus (il faisait parti de la mise à jour). Dans un projet sous vagrant, impossible de lancer la machine virtuelle. Une recherche m’a permis de résoudre ce problème, la machine virtuelle était bloquée dans le GRUB, cool.

Peu de temps après toujours, car on ne découvre pas tous les bugs d’un coup, ce serait trop facile, je constate que j’ai perdu la préférence du nombre de lignes scrollées avec la molette de la souris. C’est revenu à la valeur par défaut de trois, au lieu de plus de 10. Je n’aime pas scroller pendant des heures pour rien. Pas de problème, je retourne dans les préférences configurer cela… sauf que c’est déjà sur la bonne valeur, de 12 lignes (Mouse wheel scrolls by). Ce n’est donc plus pris en compte par Kate et Konsole, et surement d’autres logiciels. Encore une belle régression.

À ce moment là, j’ai vu une autre belle régression dans le panneau de configuration (System setting), les info-bulles scintillent lorsque l’on passe d’une icone à l’autre. Comme si il y avait un fondu, mais raté. J’en ai fait une vidéo tellement que c’était drôle, ce genre de bug en 2015 ? C’est possible ? LOL. Soyons gentil, on dira que c’est ma carte graphique qui suck, avec des drivers qui suck, alalala (mais non, c’est bien un bug).

On en arrive au crash du serveur X. Alors je ne sais pas trop si ce n’est pas kwin qui a plutôt fait de la merde au point de faire monter X à 100% du cpu et conduire au crash. Mais ça a crashé, première fois également que je vois ça. Fort heureusement, contrairement à Dolphin, le serveur X ne crash pas tous les jours (ouf, il crash très rarement heureusement).

Encore une régression dans Kate, quand on déplace un texte sélectionné, la sélection se positionne sur les caractères suivants au relachement du click. Au mieux on fait en sorte que la sélection disparait, mais on ne sélectionne pas du texte qui n’a rien avoir… Cela enchaine les fails pour Kate, cela me fait penser à mon très vieux billet relatif aux problèmes de conception. Cela doit donc toujours être la même équipe de bras cassés qui s’occupe de ce logiciel.

Puis il y a le bug ultra bloquant, xbindkeys ne fonctionnait plus. Et il ne fonctionne toujours pas d’ailleurs, au point que ça va bientôt être bloquant si je n’ai pas de solution. Pour résumer, Xbindkeys permet de lier une touche (ou combinaison de touches) à une commande. Cette même commande peut générer des touches, ainsi on peut lier une touche à une touche, ou une touche à une action. Dit autrement, cela fait gagner un temps monstrueux et c’est un confort non négligeable. Il est possible de faire la même chose sur Windows, mais je préfère la manière de faire de linux… du moins je préférai.

Après plusieurs tentative pour Xbindkeys, je découvre que le bug ne se produit que sur Kate et Kwrite, c’est con, mes macros concernent justement les éditeurs de texte (et donc ces deux logiciels). C’est donc un très bel enchainement de fails pour Kate: 1 bug bloquant plus 2 gênants.

Un dernier mot pour Konsole, il plante également par moment, en tuant donc tous les processus lancés dedans. Une autre grosse régression, il n’est plus possible de déplacer les onglets de session (dans Konsole toujours, oui oui, c’est bien une régression sévère… bon d’accord, une régression juste chiante). Je n’ai jamais autant adorer utiliser linux…

Si j’ai eu des bugs un peu dans tous les sens, je blame en particulier KDE qui sort une mise à jour sans tests poussés. Mais je me souviens à présent pourquoi cela faisait longtemps que je n’avais plus eu de bugs. Je n’installais jamais les mises à jour de KDE le jour de leur sorti, j’attendais toujours qu’ils fassent leur mise à jour de bugfix. Dit comme ça, Linux fait comme Windows, cela prend les utilisateurs pour des béta testeurs.

Es-ce le prix à payer pour être à jour ? Non clairement pas, je me paie ces bugs à cause des développeurs qui font de la merde. Sérieux, des fois je regarde leur code source, j’ai juste envie de vomir, le nom des variables suffit pour avoir peine pour eux, à se demander pourquoi à chaque nouvelle génération de développeurs tout est ré-écrit.

Déjà que c’est moche de base, si en plus c’est buggé. FUCK KDE. Les fautifs sont ceux qui sortent les logiciels buggés, ce n’est pas à cause de la distribution qui les fournis sans avoir débuggé la merde upstream (mais parfois la distribution ajoute des bugs en voulant fournir un beau bureau intégré, mais ce n’est pas le cas d’Arch linux dont le but est de modifier au minimum les logiciels).

Bref, j’écris ce billet en retard car il y a eu tellement de bugs que je le gardais de coté pour le remplir au fur est à mesure… mais j’ai tout simplement jeter l’éponge. Es-ce là la contre partie d’une distribution en rolling release ? La distribution fait son travail, j’ai des logiciels à jour, le problème est réellement des développeurs qui sortent des logiciels non terminés sous prétexte d’une migration progressive.

Pour terminer, une citation du forum de ma distribution car je ne suis pas le seul (et ni fou)

I am a litle sad to see that each time a new version of the desktop (any desktop…) is released, we have something bugy for a year or two before it become stable. As a consequence, we are left most of the time with beta software.

Je partage exactement le même sentiment.

Git stash: perdre du code, c’est possible

Parfois on pense naïvement que certains logiciels sont vraiment sûrs. C’est faux et on l’a vu avec OpenSSL (heartbleed, etc), une librairie critique. A présent c’est à git de me décevoir, célèbre logiciel de gestion de source.

Le bug est simple, vos fichiers sont perdus, un comble pour un logiciel de versioning de fichiers. La commande en question est git stash à utiliser when you want to record the current state of the working directory and the index, but want to go back to a clean working directory).

Après un git pull foireux, je me dis que je vais stasher mon code. ERREUR, car j’étais dans un cas particulier où git stash détruit magnifiquement les fichiers sans avertissement. Voici la procédure de reproduction du bug:

$ git --version
git version 2.2.1
$ mkdir test
$ cd test
$ git init
Dépôt Git vide initialisé
$ # création d'un fichier nommé "important"
$ echo "initial" > important
$ cat important 
initial
$ git add .
$ git commit -m "init"
[master (commit racine) 2847f2d] init
 1 file changed, 1 insertion(+)
 create mode 100644 important
$ # puis soudain, erreur de logique humaine, un fichier se transforme en dossier
$ rm important
$ mkdir important
$ # creation d'un fichier woot.txt dans important
$ echo "super important" > important/woot.txt
$ cat important/woot.txt 
super important
$ # le temps passe et un jour... git stash
$ git stash
Saved working directory and index state WIP on master: 2847f2d init
HEAD est maintenant à 2847f2d init
$ git st
Sur la branche master
rien à valider, la copie de travail est propre
$ # ensuite on restaure nos données
$ git stash pop
Suppression de important
Sur la branche master
Modifications qui ne seront pas validées :
  (utilisez "git add/rm ..." pour mettre à jour ce qui sera validé)
  (utilisez "git checkout -- ..." pour annuler les modifications dans la copie de travail)

        supprimé :        important

aucune modification n'a été ajoutée à la validation (utilisez "git add" ou "git commit -a")
refs/stash@{0} supprimé (9dcc39966175d918f30bb21bfbe11c9e6e8ab5ca)
$ # et BIM, tout a disparu
$ ls -a
.  ..  .git

Le dossier important n’existe plus, il n’était d’ailleurs pas versionné. A noter que git stash -u ne change rien sur la perte de données:

$ mkdir test02
$ cd test02
$ git init
$ echo "initial" > important
$ git add .
$ git commit -m "init"
$ rm important
$ mkdir important
$ echo "super important" > important/woot.txt
$ git st
$ git stash -u
$ git stash pop
$ ls -a
.  ..  .git  important
$ cat important
initial

Évidemment, c’est totalement con de transformer un fichier en dossier. Sauf dans le cas d’un lien symbolique vers un dossier qui se transforme en un vrai dossier, exemple:

$ mkdir test02
$ cd test02
$ git init
$ mkdir dir1
$ ln -s dir1 dir2
$ echo "initial" > dir1/important
$ git add .
$ git commit -m "init"
$ unlink dir2
$ mkdir dir2
$ echo "super important" > dir2/woot.txt
$ git st
$ git stash
$ git stash pop
$ ls -a
$ .  ..  dir1  .git

La logique humaine est incompréhensible sur le pourquoi du comment on se retrouve dans ce cas, au point de se dire que c’est à cause d’une mauvaise utilisation, mais je ne pense pas, un logiciel de gestion de version se doit de gérer tous les cas, mais surtout il se doit impérativement d’informer l’utilisateur en cas de perte de données possible.

Dans mon cas personnel, c’était un dossier « test », avec heureusement presque rien dedans. Sur un repository de longue date, on oublie facilement qu’un lien symbolique a été transformé en dossier, et on fait confiance au stash qui est censé tout sauvegarder (sauf les untracked, sauf si c’est demandé, dans ce cas comme on a vu, le untracked ne restaure pas les bons fichiers ensuite).

C’est un cas que je qualifierai de très exceptionnel, mais il est arrivé. Perdre des données c’est possible. J’ai quand même cherché pour savoir si j’étais tout seul, mais il semblerait que non, avec TortoiseGit, dont la conclusion est:

I’m able to reproduce this with git version 1.7.10.msysgit.1 as well as on Linux, so please report this upstream to the git mailing list. Thank you.

Même si le cas ne semble pas trop identique (cela concerne des fichiers ignorés), le problème est le même: perte de données. Moi qui utilisait git stash très souvent avec une grande confiance, à présent un backup du working directory sera effectué pour éviter toutes mésaventures sur du vrai code.

Cela me rappelle la fiabilité de linux avec cet article, où au lieu de couper/coller des fichiers, je devais, suite à un bug, copier/coller puis supprimer une fois que tout était bon pour éviter la perte de données… rebelote avec git, faire un backup avant de lancer une commande de « backup »… ahahaha, mais c’est vraiment triste pour linux en fait.