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.

Système de paquets

En faisant le tri, je découvre à la surprise générale que j’ai un dossier ~/.thumbnails/normal/ avec 11 200 fichiers pour 550 MB, à en faire crever Gwenview (qui peut donc rejoindre digikam). C’est là l’originalité de linux, on ne sait pas trop où est quoi, c’est le gros bordel avec tout dans le dossier home sous forme de fichiers cachés (berk). Cela aurait pu au moins être dans ~/.cache/thumbnails, merde! Même mieux, ~/.tmp/cache/thumbnails.

L’adoption d’un standard permet à n’importe quel administrateur (ou utilisateur d’ailleurs) de purger un dossier sans risque de perdre des données. Par exemple, le dossier ~/.tmp pourrait se vider sans problème, sans réfléchir. Encore faut-il que les développeurs sachent aller au delà de leurs complexes et cesser de penser qu’ils sont seuls au monde.

Du coup, pour connaitre quels sont les dossiers/fichiers qui prennent le plus de place, j’ai décidé d’installer KDirStat. Un magnifique logiciel qui scanne tout dossier pour ensuite afficher un beau graphique.

J’utilise l’équivalent windows au travail, un pur régal. Sur linux… ahahahaahah. Si sur windows j’avais pu utiliser exactement le même logiciel pour windows XP et windows 7, sur linux, il m’est impossible d’installer KDirStat.

Sur la page du paquet de ma distribution, il y a deux dépendances: kdelib3 et optipng. Si la seconde est facile à résoudre, la première est la plus drôle:

# pacman -S kdelibs3
erreur : impossible de trouver la cible : kdelibs3

Un commentaire récent m’indique que je ne suis pas le seul dans ce cas:

Comment by rajuk 2015-05-13 09:20
Fails to build, unable to satisfy kdelibs3 dependency.

Ouaip, magnifique système de dépendances. Ce magnifique système où un logiciel qui évolue empêche tous les autres logiciels qui n’ont pas été migré de fonctionner, ça c’est la classe.

C’est surtout le gros problème de linux, si il n’y a plus de mainteneur, le logiciel cesse d’exister.

Fuck linux ?

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.

Heartbleed, OpenSSL, Heartbeat

Mon problème récent avec le kernel linux et/ou les drivers nvidia me fait penser à Heartbleed et Shellshock. Je m’étais abstenu d’en parler ici tellement que ces failles ont bien été expliqué et ont montré à quel point la négligence de qualité existe, en particulier pour OpenSSL.

OpenSSL, un logiciel que j’ai déjà abordé dans un de mes articles, dont le titre est « Quand on code avec les pieds ». J’en avais conclu que les gens en avait marre de patcher OpenSSL et cherchent une alternative, et ce, bien avant Heartbleed.

Avec Heartbleed, même ceux qui n’ont jamais regardé le code d’OpenSSL ont reçu un message clair: OpenSSL est réellement codé avec les pieds. Créer une alternative n’est pas facile, des entreprises se sont mises à faire des dons pour améliorer le tas de merde, mais ça restera un tas de merde, toujours difficilement compréhensible mais avec moins de failles surement.

Concernant Heartbleed, les explications écrites par des journalistes qui ne comprennaient rien étaient souvent vagues ou erronées. Il existe même un hall of fame des pires erreurs journalistiques à ce sujet qui démontre très bien qu’un journaliste de nos jours ne mérite aucune crédibilité aveugle (finalement comme tout sur Internet, mais aussi à la télévision).

Du coup, pour comprendre j’ai consulté la RFC (ou ce lien, je ne sais plus), le but est de faire un keep-alive de la connexion TCP pour éviter une nouvelle connexion et donc une renégociation longue et couteuse en CPU de la connexion sécurisée. Bref, un PING/PONG basique, à titre d’exemple, c’est ce qu’IRC fait déjà depuis des années, SSL ou non puisque le ping/pong est au niveau applicatif. Avec Heartbeat, l’application n’a pas à se soucier du ping/pong puisque c’est réalisé par la couche SSL.

Comme sur l’IRC, quand un client fait un PING, le client transmet une chaîne arbitraire dans la requête et le serveur répond avec cette même chaîne arbritaire. Le contenu de cette chaine arbitraire n’a de sens que pour le client, il peut s’en servir pour suivre l’évolution des réponses du serveur, mais pas obligatoirement. Par exemple sur l’IRC, un usage bien connu est de calculer la latence avec le serveur en utilisant l’heure comme chaîne arbitraire (et on mesure ainsi le temps que le message a mis pour être envoyé et reçu).

C’est exactement la même chose avec Heartbeat (à quelques détails prêt) le client envoie des données arbitraire, et le serveur répond avec ces mêmes données. Rien de sorcier, c’est expliqué très simplement ici, sauf que contrairement à l’IRC qui est exclusivement du texte, en SSL c’est du binaire, et là, « c’est le drame« .

Une erreur de débutant de base, dont le principe bien connu dans le web est: ne jamais faire confiance aux données que le client transmet. Si le client dit qu’il a envoyé une chaîne aléatoire de 64KB, il vaut mieux en être sûr avant de lire ces 64KB qui n’existent peut-être pas.

On disait que l’open source est plus sûr car il y a des gens qui relisent le code et tout et tout, foutaise! Relire du code de merde ça ne fait plaisir à personne, déjà quand on est payé à faire ça c’est chiant, alors faire ça bénévolement et bien, je vous laisse imaginer.

A part suivre l’évolution du code et relire chaque commit, c’est impossible de partir dans un code source à la recherche de bug. C’est impossible pour un bénévole qui n’a aucun autre intérêt que de se faire chier à faire un rapport de bug qui peut être refusé et ensuite se faire traiter comme une merde (au moins Google paie bien pour trouver des bugs dans Chrome). Par contre, quelqu’un qui aurait un intérêt à exploiter un logiciel, lui il va passer du temps à la recherche de faille et on peut compter sur lui pour ne pas les signaler.

D’ailleurs, voici le commit qui a introduit le bug. Très pénible à lire, ce qui me choque le plus c’est la grosse duplication de code entre les fonctions dtls1_process_heartbeat(SSL *s) et tls1_process_heartbeat(SSL *s) qui ont exactement la même signature et font la même chose. Comment une telle chose peut être acceptée ? Ne serait-ce qu’en terme de maintenance derrière. Qu’il existe deux fonctions avec deux noms différents car c’est deux protocoles différents, OK, mais derrière le même code peut être utilisé.

Mais pour avoir déjà travaillé avec OpenSSL pour KvIRC, et pour avoir déjà lu des avis dessus, il est clair que ce projet doit mourrir. C’est juste rédhibitoire, rien que le style de codage est un non sens mais ça c’est une question de goût.

En dehors de la technique, il y a des râleurs qui pensent encore que l’open source c’est être redevable quand on en profite à fond pour en faire du fric. En effet, OpenSSL ne récolte pas beaucoup d’argent, mais c’est leur choix de ne rien demander en retour (l’open source n’est pas tout le temps gratuit). Je comprends les personnes qui se trompent sur l’open source (et gratuit), car quand on construit un outil gratuitement et qu’une autre personne utilise cet outil pour faire des millions, la conscience pousse à être reconnaissant envers l’outil. Mais ils sont dans l’erreur, d’autant plus que ce n’est pas forcément un choix puisqu’un commercial ou qu’un PDG n’a pas connaissance de l’utilisation d’outils open sources gratuits.

Personnellement, je ne donnerai jamais d’argent à des personnes qui codent avec les pieds et feront gaspiller tout l’argent en maintenance.

Pour revenir sur linux de manière générale, quand il n’y a pas d’entreprise derrière un projet, quand des bénévoles sont impliqués, en particulier quand ils sont étudiants et donc débutant, il est particulièrement important de comprendre que la négligence est vite arrivée, avec une qualité médiocre. On l’a vu dans ce blog avec Katepart, on le voit avec OpenSSL, et on le verra encore et encore. La question qui se pose est de savoir si …. c’est le prix à payer de la liberté ?

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.

alsa config (crap?) – asoundrc

Encore une belle chose de linux, les choses basiques ne sont pas réalisables facilement. Cas concret tout bête, je veux créer une vidéo de mon bureau, avec le son émis des haut-parleurs et le son (reçu) de mon micro. Pour l’image, on va dire que c’est assez simple, rien à dire là dessus. Pour le son, c’est une autre histoire…

Il y a des serveurs de son sous: linux, Pulseaudio, jack, et des API du kernel: oss, alsa. Imaginer déjà comment doit faire le pauvre développeur si il doit gérer du son dans son application, mais heureusement, il y a des solutions.

Mais cet article n’est pas là pour débattre du bordel de la multitude de système de gestion de son sur linux. Je vais m’attarder sur alsa (mALSAin?) car OSS est obsolète on va dire, JACK ne correspond pas à mes besoins, et PulseAudio malheureusement ne marche pas dans mon cas précis. D’ailleurs, mon cas précis est de créer une vidéo d’un jeu (StarCraft 2, qui produit du son donc) sous Wine. PulseAudio, que j’ai testé, divise par 10 les fps du jeu et c’est un bug connu. PulseAudio colle bien à sa réputation pour le coup. Je me retrouve donc coincé avec ALSA, ce qui est surement le mieux, plutot que de passer par des couches d’abstraction.

L’objectif numéro 1, est donc d’enregistrer le son qui sort du PC. Ce n’est pas très compliqué quand la carte son propose d’elle-même de capturer le son qu’elle émet. Mais même lorsqu’elle le propose, cela ne semble pas si évident (c’est ironique) car j’ai trouvé de multiples articles qui expliquent comment choisir la source de données à capturer. Grosso-modo, c’est choisir dans un menu déroulant la source sonore, pour certaines personnes c’est d’un compliqué de faire ça, surtout quand on passe par la console et que l’on s’y prend mal, à tel point au début j’ai cru que c’était la solution à mon problème. Malheureusement, ma carte son ne propose pas d’elle-même, donc matériellement, d’enregistrer le son qu’elle émet, il me faut une solution logicielle.

asoundrc

Cette satanée solution logicielle, je ne l’ai jamais trouvé dans mes recherches pour ALSA, la solution étant de nos jours d’utiliser PulseAudio ou JACK (qui sont des solutions logicielles). Du coup, j’ai du m’inspirer d’exemples. Pour commencer, il y a un fichier magique, ~/.asoundrc (appelé simplement « asoundrc » par la suite), qui permet de personnaliser ALSA par utilisateur. C’est là dedans que tout va se passer, en fait c’est ça la solution logicielle…

Contrairement aux conneries qu’on peut lire sur Internet, pas besoin de se délogguer de la session à chaque modification du fichier, ni de redémarrer son PC. C’est encore une fois une bonne illustration des bêtises qu’on peut trouver sur Internet. Le fichier asoundrc est lu à chaque lancement par l’application (si celle-ci utilise ALSA). C’est tout simple. C’est aussi perturbant, c’est un gros WTF car on peut changer la configuration à la volée dans une session, mais en fait cela semble très logique.

Il faut comprendre ALSA, on peut appliquer des filtres aux différents périphériques, comme la conversion de fréquence, la conversion de stéréo en mono, etc. Ces filtres, une fois chargés dans l’application, restent actifs jusqu’à la fermeture de l’application. Ce n’est donc pas un problème de modifier asoundrc entre temps, les nouveaux filtres (ou ceux supprimés) seront disponible pour les futures applications qui seront lancées.

Si les tests sont effectués avec VLC par exemple, il ne faudra pas oublier de bien le fermer avant d’ouvrir un autre fichier. L’idéal, est de tester en ligne de commande avec aplay et arecord. Au début c’est bien chiant, mais à la fin c’est bien pratique. D’ailleurs, aplay -L et arecord -L (fonctionne aussi avec un L minuscule pour d’autres infos) vont bien aider par la suite.

Terminologie

Quand je dis capturer ou enregistrer cela signifie que le flux (de bits) du périphérique ou interface ou autre peut être lu, c’est une source d’entrée. L’exemple d’interface que l’on peut capturer/enregistrer c’est le micro. On ne peut enregistrer seulement les entrées, sinon je ne me ferai pas chier à mettre en place une interface logicielle pour pouvoir enregistrer ce qui passe par une sortie (le son qui sort de mon PC). A noter que pour les cartes sons qui permettent d’enregistrer leur sortie, c’est parce qu’elles offrent d’elles même une entrée pour ça (ce qui n’est pas mon cas je le rappelle).

Pour résumer: sur une entrée (synonyme: source de données), on lit (synonyme: capture/enregistre) des données, comme lire le flux du micro; sur une sortie on écrit des données, comme écrire vers les haut-parleurs. J’évite le verbe enregistrer car il donne l’impression qu’on sauvegarde les données dans un fichier, ce qui n’est pas notre cas.

Ce n’est pas pour rien si j’utilise capturer comme verbe, en anglais capture est le type d’interface qui permettent d’être lu. Pour l’interface qui permet d’écrire des données, en anglais c’est playback

loopback

L’interface loopback c’est une carte audio logicielle avec plusieurs points d’entrées (sur lesquels il y a du son à capturer) et plusieurs points de sorties (qui peuvent servir de sortie pour le son). Elle correspond au module du kernel snd-aloop et est chargée par défaut de nos jours, il existe plein de documentation sur Internet sur comment la charger sinon.

Cette interface loopback, va créer des tunnels, ou plutot des boucles pour reprendre son appellation (loop): ce qui sera écrit sur une sortie pourra être lu (capturé) sur une entrée. C’est pour cela qu’il y a autant de sorties que d’entrées.

Cela ne semble pas très parlant peut-être, pourtant c’est simple: cela transforme une sortie en entrée. C’est exactement ce que je veux, transformer la sortie des haut-parleurs en entrée.

Dans le cadre de la vidéo que j’ai à réaliser, la source de données sera une des interfaces loopback pour résoudre mon problème de capture du son du PC. Ce ne sera pas l’interface par défaut (default) qui correspond à mon micro. Dans le logiciel d’enregistrement il faudra spécifier correctement cette source de données.

Déclarons déjà juste ces interfaces virtuelles, on prend soin d’utiliser un nom parlant pour ces interfaces.

pcm.loophwOut {
  type hw
  card Loopback
  device 0
  subdevice 0
  hint {
    show on
    description "Loop Output00"
  }
}


pcm.loophwCapt {
  type hw
  card Loopback
  device 1
  subdevice 0
  hint {
    show on
    description "Loop Input10 Rec"
  }
}

loophwOut correspond à la carte logicielle Loopback, mais elle est quand même de type hw (hardware) car c’est une carte (une émulation), elle utilise le périphérique (device) 0 et sous-device 0. Ce qui sera écrit dedans pourra être lu par loophwCapt, qui correspond à la même chose sauf pour le champ device. C’est assez simple, pour un même subdevice, ce qui est écrit dans un device 0, se lit dans un device 1, et il y a jusqu’à 8 subdevice (voir aplay -l).

La source de données pour ma vidéo, sera alors loophwCapt. Tout ce que je veux enregistrer pour la vidéo devra figurer (être envoyer) dans loophwOut.

Dans le nom de périphérique loophwCapt, j’ai préféré utiliser « Capt » pour « Capture » au lieu de « In » pour insister que c’est une périphérique qui va servir à capturer des données, dans ma tête c’est plus clair pour moi. Libre à chacun d’utiliser les mots qui leur parlent le plus, l’essentiel est de ne pas être perdu quand un lit un fichier asoundrc, de ne pas devoir analyser chacune des lignes du fichier pour le comprendre. Car c’est exactement ce qu’il faut faire sur les articles que j’ai pu lire…

Multiplication

Pour capturer le son du PC, il suffit donc que celui-ci soit écrit sur une interface loopback (loophwOut), mais aussi sur la carte son pour pouvoir l’entendre. Un même flux doit être envoyé à deux cartes différentes: une matérielle, une logicielle (le type de carte n’a pas d’importance, c’est juste pour insister que loopback est une carte son, même si elle est logicielle).

Il faut donc dupliquer le son sur deux cartes, cela tombe bien, il y a plein d’exemples sur Internet pour ça. Mal expliqué malheureusement, en fait, c’est généralement un bloc de code à mettre dans asoundrc, avec une explication de comment s’en servir, mais rien n’explique le fonctionnement du code qui a été collé. C’est une chose que je déteste, faire quelque chose sans comprendre, et du coup sans être capable d’adapter à mon besoin précis ou de corriger si c’est buggé ou pas à jour.

En fait, ce que l’on écrit dans asoundrc, ce sont des « plug-ins », qui se connectent en eux, le premier plugin de cet article était loophwOut qui se « connecte » (plug) sur la carte audio loopback. Un plugin possède des données en entrée, et des données en sortie, entrée/sortie qui n’ont rien avoir avec la notion de « capturer/enregistrer », le plugin c’est une boite de transition, qui peut effectuer une transformation, servir de redirection ou d’alias, ou autre.

Cette fois-ci, on va faire un plug-in qui duplique un flux sur deux cartes audios, appelés loopOutMix (loopback) et speakersOutMix (la carte son). Ces plug-ins n’existent pas encore, en réalité ils ne sont pas nécessaire, on peut directement spécifier un plug-in hardware (ou équivalent comme loopback), sauf que j’anticipe le problème de mixage auquel je me suis confronté pour éviter d’écrire du code qui marche mal. Par exemple, loopOutMix devrait correspondre à loophwOut créé plus haut, et speakersOutMix devrait correspondre naturellement à default (ou hw:0,0), les haut-parleurs.

Donc créons déjà le plug-in qui duplique le flux, appelons le « speakersMulti » puisqu’il sert à dupliquer le son des haut-parleurs (en fait il effectue seulement des branchements, la duplication se fait avant). Appeler correctement les plug-ins est une chose indispensable pour trouver les choses logiques en lisant le fichier asoundrc, sur l’article original, le nom utilisé était « mdev », très pratique…

pcm.speakersMulti {
  type multi

  # première sortie
  slaves.a.pcm "loopOutMix"
  slaves.a.channels 2

  # seconde sortie
  slaves.b.pcm "speakersOutMix"
  slaves.b.channels 2

  # configuration des liaisons
  bindings.0.slave a
  bindings.0.channel 0
  bindings.1.slave a
  bindings.1.channel 1

  # seconde sortie
  bindings.2.slave b
  bindings.2.channel 0
  bindings.3.slave b
  bindings.3.channel 1
}

Le fonctionnement ne semble pas très compliqué, on définit une première sortie avec 2 canaux (car stéréo), on définit la seconde sortie de la même manière, puis on effectue les liaisons… Sauf qu’il semble y avoir 4 canaux en entrée. C’est parce qu’à mon avis, on ne peut pas lier un seul flux d’entrée à deux flux sortie, il est alors nécessaire de dupliquer ce flux avant de le passer au plugin qu’on a créé.

Le flux c’est du son en stéréo, donc deux canaux. Si on duplique le flux, il y aura 4 canaux en entrée du plugin speakersMulti. Ce sont ces 4 canaux que l’on lit. Les chiffres 0 à 3 situés après bindings correspondent au numéro du canal en entrée, que l’on lie aux sorties. Le canal 0 et 2 sont identiques, et 1 et 3 également. Pourquoi ? Parce que l’on va utiliser un autre plugin pour réaliser cette duplication. Mais ça, c’est rarement expliqué dans les articles que j’ai lu. C’est pour cela que j’ai volontairement expliqué dans cet ordre, pour montrer la démarche, les problèmes.

Donc c’est partie, dupliquons les canaux et connectons le. Appelons ce plug-in intelligemment, ce plug-in sera celui qui recevra tous les sons du PC pour les transmettre à speakersMulti et donc aux haut-parleurs ensuite, je vais utiliser le nom « speakersOut ». Sur les articles que j’ai lu, c’était mdevplug

pcm.speakersOut {
  type plug
  slave.pcm speakersMulti
  route_policy "duplicate"
}

Tout simplement. Les canaux en entrées sont dupliqués avec route_policy sur la destination (slave) qui est speakersMulti.

Pour résumer: pour un logiciel configuré avec « speakersOut » comme périphérique de son, il va écrire dessus, le flux stéréo sera dupliqué en 4 canaux, puis passés à speakersMulti. Deux de ces canaux iront dans loopOutMix, les deux autres dans speakersOutMix.

Si l’on remplace loopOutMix par la carte son, en général hw:0,0, et speakersOutMix par loophwOut comme on a vu en haut, cela devrait marcher. Et bien… oui, ça marche! Mais pour un seul logiciel… cela ne gére pas plusieurs logiciels simultanément. Grand moment de déception sur le moment, car c’est une chose tellement évidente que je pensais que c’était géré par défaut dans le système, masqué aux logiciels et à nous utilisateurs. Linux :-/

Mixage

Un périphérique c’est une ressource, cette ressource ne peut-être utilisée que par une seule chose. Par exemple, si un logiciel qui utilise le micro est en cours d’exécution, et bien on ne pourra pas se servir du même micro en même temps dans une autre application… débile ? oui. Autre exemple, si un logiciel diffuse du son sur la carte son, c’est pourtant normal qu’un autre logiciel puisse faire de même. Dans ce dernier cas, le problème est juste masqué car géré par défaut, sinon tout le monde crierai au scandale. Car j’ai testé comme on vu ci-dessus, en écrivant du son directement sur la carte son (hw:0,0 dans mon cas), cela réserve la ressource (la carte son) et aucune autre application ne peut écrire du son.

Pour que plusieurs logiciels puissent écrire du son simultanément, il faut un mixeur. Le son sera mixé par un intermédiaire et envoyé à la carte son. Cet intermédiaire s’appelle dmix. Il ne faudra pas l’oublier pour écrire sur les cartes sons, dont l’interface loopback qui est aussi une carte son (virtuelle).

Si il y a plusieurs logiciels, ils vont tous écrire sur speakersOut, et donc tous transmettre sur speakersMulti. Deux solutions, soit mixer avant d’envoyer sur speakersMulti, soit mixer à la sortie de speakersMulti.

Pour ma part, j’ai mixé à la sortie de speakersMulti. Parce qu’en général, le mixeur est l’avant dernier plugin de la chaine, le dernier étant le hardware. Dans notre cas, il semble logique de mixer avant, sauf qu’ensuite, il faudra aussi mixer le micro… donc commençons par mixer en fin de chaîne, le reste c’est de l’optimisation qui pourra se faire plus tard (en fait non, j’ai testé et ça ne marche pas, le mixeur doit se trouver toujours avant une carte son).

Ajoutons le plugin de type dmix sur l’interface loopback:

pcm.loopOutMix  {
   type dmix
   ipc_key 1024
   slave {
      pcm "loophwOut"
      format S32_LE
      period_time 0
      period_size 1024
      buffer_size 8192

      rate 44100
      channels 2
      format S16_LE
   }
   bindings {
      0 0
      1 1
   }
}

L’ipc_key doit être unique, la sortie (slave) est le périphérique logiciel loophwOut, sur lequel on configure un buffer de mixage. Du coup on ne doit jamais écrire le son sur loophwOut mais toujours passer par loopOutMix. Il suffit de faire la même chose pour la carte son:

pcm.speakersOutMix  {
   type dmix
   ipc_key 1024
   slave {
      # à adapter en fonction de votre matériel
      pcm "hw:0,0"
      #format S32_LE
      period_time 0
      period_size 1024
      buffer_size 8192

      rate 48000
      channels 2
      format S16_LE
   }
   bindings {
      0 0
      1 1
   }
}

A ce stade, je suis en mesure d’enregistrer le son qui sort de mon PC (avec loophwCapt), mais pas celui qui rentre.

Le micro

Le son du micro n’est pas émis aux haut-parleurs, il ne sort pas du PC, il ne fait pas partie du flux de sortie, il faut donc une astuce encore. De plus, nous pouvons enregistrer (avec le logiciel pour faire la vidéo) qu’une seule source de données, or il y en a deux: le micro et l’interface loopback utilisé pour le son qui sort du PC.

Pour ce problème, c’est très simple, il suffit de rediriger le flux du micro vers la sortie de l’interface loopback, notre loopOutMix. Le son du micro sera ainsi mixé avec le son du pc. Cela se fera à la demande, avec la commande alsaloop, qui prend l’interface (le plugin) d’entrée, et l’interface de sortie. L’ensemble mixé pourra être enregistré avec loophwCapt.

Alors qu’on pense y être arrivé, il y a encore un problème à résoudre. Le micro est capturé deux fois: une fois par le logiciel de conférence, et une fois par alsaloop. En effet, j’ai oublié de préciser que je serai en conférence et qu’on sera plusieurs à commenter la vidéo. Il faut donc faire en sorte que plusieurs logiciels puissent capturer le micro. Ca encore ce n’est pas courant et cela vaut la peine de l’expliquer.

Tout comme dmix pour mixer plusieurs sources en une seule, il existe dsnoop pour dupliquer logiciellement parlant une seule source en plusieurs. Même si dans l’immédiat j’aurai pensé à réutiliser la même astuce de duplication route_policy, dsnoop est le plus approprié et dédié à cet usage (cela évite la duplication de canaux, etc). Tout comme plusieurs applications peuvent écrire dans un plugin dmix sans se poser de question, la même chose en capture est possible avec dsnoop.

Déclarons ce nouveau plugin, appelé microMix (mixage du son du micro pour créer plusieurs sorties), sur les articles trouvés, le nom « dsnooped » avait été utilisé, vraiment pas pratique pour comprendre.

pcm.microMix {
  type dsnoop
  ipc_key 11834
  slave {
    # le périphérique du micro, à adapter si besoin
    pcm "hw:0,0"
    period_size 256
    periods 16
    buffer_size 16384
  }
  bindings {
     0 0
  }
}

Rien d’extraordinaire, c’est comme dmix, sauf qu’il y a qu’un seul canal (mono), d’où un seul canal dans bindings. ipc_key doit toujours être unique. Dans le logiciel de conférence, il faudra utiliser microMix comme source de données… ou pas.

Voici maintenant la commande alsaloop puisque toutes les interfaces sont connues:

$ alsaloop -P loopOutMix -C microMix -t 200000

On capture de microMix pour écrire dans loopOutMix, avec une latence de 200000 microsecondes (200ms). On peut baisser la latence ou l’augmenter, le CPU sera plus ou moins chargé en fonction de cette valeur.

Par défaut

On peut regrouper tous ces changements dans default pour ne pas avoir à changer la configuration de chacune des applications:

pcm.!default {
  type asym
  playback.pcm "speakersOut"
  capture.pcm "microMix"
}

Assez simple à comprendre, default est un périphérique asymétrique dans lequel on peut donc écrire (playback) du son et capturer du son. On précise quel plugin est à utiliser pour les deux cas. Et le tour est joué.

Si plusieurs logiciels doivent enregistrer à partir de loophwCapt, il faut faire comme pour le micro (microMix) et ajouter un plugin dsnoop. Ce n’est pas mon cas, mais c’est possible à faire.

Mais quand on pense avoir fini, il reste les bugs logiciels… mon logiciel de conférence (mumble), n’affiche pas les interfaces alsa, il faut la spécifier dans le fichier de configuration (source). Wine a un problème avec ALSA, impossible d’utiliser l’interface par défaut, j’ai du adapter Wine. Seul VLC a fonctionné comme sur des roulettes. Le coût de la diversité encore…

Au final, l’étape du mirco n’a servi à rien. Le son capturé est le flux brut du micro, et à moins d’avoir un micro de qualité, il faut nettoyer le son pour enlever les parasites, les petits claquements, etc. Ce que fait par exemple très bien mon logiciel de conférence. Il a fallu tricher et tricher encore et encore pour arriver au bon résultat. Certains appellent ça hacker, cela fait plus hype que de dire qu’on galère, comme quoi il y a du marketing aussi du coté de linux…

PS1 ? Bash ?

Le prompt de bash, c’est un peu un élément clé de linux. Mais voici des exemples de configuration:

PS1=’\[\e[0;32m\]\u\[\e[m\] \[\e[1;34m\]\w\[\e[m\] \[\e[1;32m\]\$\[\e[m\] \[\e[1;37m\]’
PS1=’\[\e[1;32m\][\u@\h \W]\$\[\e[0m\] ‘

C’est illisible et incompréhensible sans documentation. Tous ces caractères d’échappement et crochets, l’insertion de couleurs de manière farfelues, par exemple « \e[0;37m » pour du blanc, cela commence par « \e[ » et se termine par « m ». DEBILE. Non c’est pire, il faut en plus préciser que ces caractères sont spéciaux et qu’ils ne doivent pas être comptés comme des caractères (puisqu’ils sont invisibles) pour ne pas fausser la position du curseur du shell. Et pour cela, il faut les entourer des crochets, de crochets échappés bien sûr.

Ainsi, pour ajouter toto en jaune dans le prompt, il va falloir ajouter: « \[\e[1;33m\]toto\[\e[0m\] », soit 21 caractères pour la couleur.

Certes, oui, le prompt de linux est puissant car il peut afficher le résultat de commandes dedans, et ainsi afficher l’état du système juste dans la prompt. Mais quelle syntaxe horrible. Mais c’est vrai que l’on parle de bash, le shell qui fait un caca nerveux si on met des espaces autour du symbole égal. Un blog entier ne suffirai pas à montrer tous les défauts de cet ancêtre.

Car justement tous les problèmes proviennent de son âge, bash devrait être obsolète et plus utilisé, mais comme il est présent de partout, il est un standard (malgré l’existence d’autres shell), et il est très souvent par défaut sur les distributions, alors il reste, la compatibilité a un prix… le pire est qu’il est enseigné à l’université, j’espère que c’est seulement les bases…

Libre office ?

Libre office… ahahahaha… mouahhaah… es-ce utile de continuer ? Déjà ce vert sur le site… ensuite le choix de la version, ils se sont améliorés depuis, car avant c’était à n’y rien comprendre. Mais le plus important c’est le logiciel. Calc, c’est un logiciel que je me sert peu souvent, non pas car j’utilise Excel, mais parce que je n’en ai pas le besoin. Mais il se trouve que j’avais un besoin extrêmement mineur, qui grosso modo consistait à saisir deux nombres, effectuer une opération mathématique dessus, et afficher le résultat. Bref, le truc de base de calc. Il se trouve que même faire ça, ça m’a gavé et j’ai du chercher sur Internet une solution.

Car LibreOffice est un logiciel respectueux des standards et des animaux. Ainsi, comme séparateur des décimales, ce merveilleux logiciel va utliser le séparateur de la langue du système, c’est à dire la « virgule » en français. Et comme les personnes de libreoffice ont pensé à tout, le point du pavé numérique correspond… à un vrai point, il n’est pas interprêté comme un séparateur de décimales.

Disons que c’est un peu la base du logiciel. J’imagine très bien les gens installer le logiciel, faire un bête calcul et PAF, ils y arrivent pas à cause d’un nombre décimal. On s’étonne après que libreoffice ne perce pas dans l’administrateur et les entreprise. Même si j’ai fortement envie d’en faire la promotion dans la boîte où je suis, je sais que si déjà le logiciel n’a pas un comportement cohérent pour saisir un nombre décimal, alors je n’imagine pas tout le reste. Surtout que je ne m’en sers pas, et faire la promotion juste car c’est libre c’est du suicide.

Le logiciel est pensé pour choisir ce séparateur, ça se configure, mais si par défaut il n’est pas capable de proposer le bon, alors POUBELLE. Ceci dit, même en configurant le truc, c’est à dire en allant dans les options, puis « Language Settings » et « Languages », en décochant « Same as locale setting », cela ne marche quand même pas. J’ai pensé que c’était vraiment des boulets les dév et qu’il fallait peut-être relancer l’application, mais non, ça ne marche toujours pas. Du coup je me demande, puisqu’il n’utilise plus le séparateur de la langue locale, lequel utilise-t-il ce con ? La version anglaise sûrement, surtout que j’ai le logiciel en anglais, et il se trouve que c’est le « point » en anglais… alor WTF, pourquoi ça ne marche toujours pas…

Surtout, que le but du point sur le pavé numérique, c’est de pouvoir saisir les décimales du nombre. Il me semble que c’est le cas dans n’importe quelle langue, ce point il est sur un pavé numérique (composé de chiffres donc) car il a un rapport avec les nombres et en particulier ceux avec des décimales. Après peu importe si il affiche une virgule, un point, un point virgule, une parenthèse ou autre, merde cette touche là c’est le séparateur de décimales, il n’est pas censé être nécessaire de la configurer.

C’est à ce moment là qu’on constate le cycle de vie d’un logiciel Open Source: pas de test à grande échelle. En fait, grâce à google, on voit que ce problème existe depuis longtemps. Il y a un article sur le wiki, et j’ai même de la change, il y a un message sur le forum de ma distribution. Sur le forum, il est dit qu’il faut carrément configurer la touche suppression du pavé numérique (dans le système d’exploitation, le bureau plus spécifiquement). Le wiki officiel explique ma solution de tout à l’heure dans les options, sauf que cela m’affiche déjà un point.

Je suis remonté jusqu’à des sujets de 2007 évoquant ce problème dans OpenOffice (j’en profite pour préciser que j’utilise la dernière version de libre office grâce au génial système de dépôts qui m’a tout mis à jour tout seul tellement que cay tro puissant linusque). Puis finalement je me sens vraiment moins seul, une autre personne raconte bien galérer également (en 2011), suivi de ses camarades bien au courant du problème, comme quoi finalement, dès l’installation de libreoffice c’est le premier problème qu’on rencontre et qu’on s’amuse à corriger.

Et là, il ne reste qu’une envie de crier MAIS PUTAIN POURQUOI PERSONNE FAIT EN SORTE DEPUIS LE TEMPS QUE ÇA MARCHE DU PREMIER COUP. Non de dieu, c’est la base ce truc. Comment être crédible face à ceux qu’on veut convertir si la fonction de base ne marche pas et ce depuis plusieurs années. Es-ce qu’à cause de linux ? NON, sous Windows, car justement à l’origine c’est sous Windows que j’ai eu le problème, aisément, très aisément reproductible sur linux bien sûr. Donc même sur Windows XP, configurer comme il faut, du bon standard français, bla bla bla, LibreOffice Calc m’a fait chier avec ce putain de point du pavé numérique. A tel point que vu le temps passé à chercher une solution sous Windows, j’ai laissé tombé et je me suis fait chier à saisir la virgule du clavier alphanumérique pour les trois merdes de calcul à faire.

Bref, LibreOffice ? Ahahahahah, et il y en a qui s’étonnent que ça ne perce pas… 🙂

Cet exemple résume parfaitement la philosophie de linux. Des bugs de merde qui restent juste par plaisir de faire chier, ou de la config de merde mal réalisée juste parce que linux c’est trop bien tout est configurable alors on met une conf de merde par défaut comme ça chacun la personnalise c’est trop génial dit le mec qui a trouvé l’idée et en plus, vu que ça marchera mal le premier coup, ça obligera le mec à bidouiller car comme la planète est geek et aime bidouiller et aime les défis, ça va leur faire supair plaisir.

Cela amène une très bonne constation. On peut dire que linux n’est pas utilisé par le grand public, c’est à cause du support matériel incomplet, l’absence de jeux ou tout aure raison presque valable. Par contre, pour LibreOffice, célèbre suite bureautique gratuite (célèbre par ses bugs?), c’est un logiciel comme un autre à installer sur Windows, et finalement ça ne le fait pas trop pour le grand public. Le problème le linux est le même que celui de LibreOffice: aucune qualité et produit pas fini.

Suite histoire d’ext4

Un beau jour ça a recommencé à nouveau… freeze, freeze, freeze à cause des accès disque. F.U.C.K linux. Je ne suis vraiment pas le seul à qui cela le fait (une recherche avec flush-8:16 ou flush-8:0 suffit). Actuellement, même KWrite freeze parfois quand je sauvegarde le fichier texte dans lequel je rédige les articles du blog… un ordinateur i7 4Go de ram inutilisable avec seulement deux applications de lancées: firefox avec un seul onglet sur une vidéo youtube, et KWrite (bon, seul firefox suffit en fait xD). Pitoyable.

Dans un autre genre, les toolkits graphiques étant différents, avec certaines applications, le CTRL+C et CTRL+V ne fonctionne pas: exemple, firefox sous kde. Il existe une solution mais elle me provoque le bug du double CTRL+C dans la console (voir article précédent). Pour d’autres applications, ce sont les nombres du clavier alphabétique qui ne marche pas (maj+numero) (exemple: truecrypt).

Dans un autre genre encore: l’écran de veille s’active après un délai très court d’inactivité (~1 minute, souvent un peu moins), malgrés une configuration à 30minutes… Le PC est devenu inutilisable, obligation de désactiver l’écran de veille.

Ou encore, au moment de se déconnecter, un écran noir avec une confirmation est censée s’afficher… sauf que le fond noir est raté, un bug fait en sorte qu’une bande de 2 cm n’est pas dessinée, du coup on voit le bureau. WTF.

Autre exemple, une application peut freezer tout le bureau, obliger d’aller dans un tty (ctrl+alt+f1 par exemple) pour tuer l’application concernée…

Ou la sauvegarde d’une image dans firefox, cela lag à cause de l’OS qui calcule à chaque fois la miniature de toutes les images du dossier dans la fenêtre de sauvegarde… La gestion du cache ? Windows le faisait déjà il y a 10 ans (Thumbs.db).

De mieux en mieux linux. C’est un produit pas fini, et finalement mal « packagé » pour ma distribution. Mais il ne faut pas se leurrer, l’herbe n’est pas plus verte ailleurs, avec une société derrière (Red hat ?) ou bien un millionnaire (Ubuntu), linux reste basé sur une multitude de logiciels open source non maitrîsés.

ufw et recordmydesktop

Avant que j’oublie, voici encore un problème de paquets, c’était en mars, lors de la mise à jour du paquet ufw, les fichiers de configuration ont été déplacé (de /lib vers /usr) mais le script d’installation n’a pas prévu de les copier au nouvel endroit… Tout le monde utilisant ce paquet s’est retrouvé à devoir les copier à la main. Et pour ceux qui n’ont pas vu les avertissements lors de là mise à jour, des topics comme celui-ci ont fleuris.

On peut voir les changements ici, et s’apercevoir qu’un « cp » des anciennes configurations n’était pas compliqué à faire. C’est la faute du mainteneur bien évidemment, mais cela fait parti des petits détails qui énervent. Il a surement été blamé, mais d’autres l’ont aussi défendu en signalant que les avertissements lors de mise à jour sont à lire.

Pourquoi ce problème a été particulièrement gênant ? ufw est un pare-feu, la perte de la configuration implique que tous les ports de la machine seront fermés. Et sans accès physique à la machine, il devient impossible de se connecter dessus pour corriger le problème. Ah vraiment sympa linux, un mainteneur d’un paquet critique incapable de réfléchir à deux fois sur comment s’y prendre.

Quant à recordmydesktop, un super outil pour enregistrer son bureau et faire des démonstrations sur le comment du pourquoi linux est génial… ou pas. Programme en ligne de commande, mais disponible avec des interfaces graphiques non officielles, moi je m’en sers en ligne de commande pour maitriser toutes les options que je lui passe. Pour arrêter l’enregistrement, on peut utiliser CTRL-C, ce qui est le plus pratique pour moi puisque je retouche la vidéo ensuite. Sauf que, après CTRL-C, il y a l’étape de compression de la vidéo, rien d’anormal pour l’instant, si ce n’est que pour mettre fin à cette étape, il faut presser CTRL-C encore une fois.

Tout fonctionnait nickel jusqu’au jour où… merde, j’ai appuyé deux fois sur CTRL-C comme un con. Je recommence et je fais bien attention de n’appuyer qu’une seule fois. La fois suivante… fuck, deux fois CTRL-C et j’ai perdu une assez longue vidéo. FUCK linux, je regarde de plus prêt, et sûrement suite à une mise à jour (puisque ça ne me le faisait jamais avant) CTRL-C provoque 70% du temps deux CTRL-C (deux ^C) dans la console. GÉ-NI-AL.

Qui blamer ? xbindkeys ? xvkbd ? bash ? le clavier qui déconne ? ah bash, dernière mise à jour le 07 mai, c’est le plus récent à avoir changé. Et puis fuck, je n’ai pas envie de tester en downgradant, fait chier linux de merde, toujours des problèmes quand tout marchait très bien, au point de dire que c’est aussi recordmydesktop qui est mal foutu, un CTRL-C pour démarrer la compression, un autre pour l’arrêter (mais d’un autre coté c’est logique aussi). Bon, linux, prêt pour le desktop ? JAMAIS puisque la philosophie est Do it yourself (source, 1996) pas compatible avec Mme Michu.

Pour finir, un rapide retour sur mon optimisation de partition ext4 effectuée sur sdb, il se trouve que depuis peu, j’ai des erreurs au démarage sur sda, drole de coïncidence. Mais les disques durs étant différent, j’espère bien que c’est indépendant, mais c’est linux, on est jamais à l’abri d’un stagiairebénévole nolife.

Après plus d’un an d’utilisation de linux, je commence sérieusement à devenir un anti-linux. Sachant qu’au final, linux ne m’apporte pas grand chose de plus par rapport à Windows.