KDE, la fin d’une époque

Voici les bugs ces derniers temps:

Dolphin: incapable de surveiller la création de fichier dans le dossier actuellement affiché. Je télécharge un fichier avec Chromium, il faut que je fasse F5 pour qu’il soit visible (même au bout de plusieurs secondes d’attente)

Dolphin: peut ouvrir un fichier compressé comme un dossier, mais ouvrir un des fichiers à l’intérieur ne fonctionne pas. Ni Gwenview, ni Kate, ni les autres applications car le fichier ouvert correspond au protocol « tar », le chemin est « tar:/path/to/file.gz/path/to/file/data.txt »…
Même problème avec le protocole MTP utilisé par les téléphones et appareils photos… malgré kio-mtp de KDE, dans Dolphin, je ne peux pas ouvrir de fichier car le chemin utilisé est « mtp:/path/to/file/… que les applications ne supportent pas… ou plutot « The process for the mtp protocol died unexpectedly ». Retour à la vieille technique de copier le fichier dans un dossier temporaire pour ensuite l’ouvrir, la lose.

Mi-2015 passé et j’ai un système d’exploitation incapable de gérer le protocol MTP correctement. A noter que l’erreur d’ouverture du fichier je l’ai obtenu grâce à Okular, car Gwenview et KolourPaint s’en branlent complétement et n’affiche aucun message d’erreur, on sent les développeurs bien branleurs à en faire le moins possible, ou ultra débutants. Ah le libre, ah oui ça sucks. Le début de la fin de KDE peut-être.

Dolphin: Pourquoi, mais pourquoi dans le menu contextuel d’un fichier HTML, pour « Ouvrir avec » j’ai 3 fois Chromium et 2 deux Kate dedans. Sérieux, je n’ai jamais touché à ce truc, comme est-ce possible… Prochainement un CCleaner version linux ?

Dolphin: pas de barre de progression à l’ouverture d’un zip… un zip de 150 Mo, je ne savais pas si cela avait planté ou si c’était en cours de chargement…

Dolphin: Le tri par « Type » dans Dophin est une blague… Pour reproduire le bug, j’ai trois types:

  • « plain text » pour les fichiers « *.txt »;
  • « backup file » pour les fichiers « *~ »;
  • « PHP script » pour les fichiers « *.php »;
  • « HTML document » pour les fichiers « *.html ».

Je voulais supprimer tous les fichiers de backup d’un dossier, je vais donc trier par Type, et je m’attends à ce que « backup file » soit en tête de liste (ou en fin de liste en fonction de l’ordre de tri). Ce n’est pas le cas à cause des majuscules (les minuscules sont après les majuscules). C’est presque un problème de « locale », mais non.

VLC: fait lagger un jeu sous wine en lisant une musique ogg

ark: ne permet toujours pas de choisir le niveau de compression (suite à la suppression de l’UI de 7z, j’ai du remettre ark), surement car c’est juste une interface pour plusieurs programmes lancés en ligne de commande, MAIS, cela ne l’empêche pas de connaitre le paramètre du niveau de compression pour chaque programme (et de proposer seulement les niveaux disponibles).

Firefox: Impossible de renommer un fichier dans la boite de dialogue Ouvrir… Firefox qui utilise une boite de dialogue Ouvrir différente de KDE (gnome surement).

Dolphin: bug critique qui m’a poussé à publier cet article: redimensionner une colonne dans le mode de vu « détail » fait planter l’application.
https://bbs.archlinux.org/viewtopic.php?id=201550

Beaucoup de Dolphin dans cette liste. Le gestionnaire de fichiers, l’élément le plus important dans un système d’exploitation, complétement à la ramasse dans KDE. La qualité de KDE s’est fortement dégradé au point que je songe à changer de desktop.

Firefox: Mauvaise communication

Firefox 34 possède la possiblité de faire de la communication en temps réel directement dans le navigateur en proposant son propre service de WebRTC: Firefox hello. Tout content de voir cela dans la release note, je me suis dis que je vais aller tester cela.

Je clique sur le lien de la release note pour en savoir plus. Je ne vois toujours pas comment m’en servir, je ne vois rien de nouveau dans l’interface Firefox.

Je clique sur le lien de cette même page, et je vois enfin une capture d’écran qui m’indique où se trouve la fameuse icone. Sauf que… je n’ai pas ça moi. Moi je n’ai rien.

J’ai peut-être raté un truc en lisant en diagonale (après tout je m’en tape du bla bla, je veux juste m’en servir merde). En lisant les pages ci-dessus, je n’ai trouvé aucune information supplémentaire.

Cela commence à gonfler. Firefox qui met en avant sa killer feature avec tout ce buzz, mais elle est introuvable… WTF. J’ai bien la dernière version pourtant.

C’est parti pour une recherche sur un moteur de recherche, je tombe sur le lien suivant de la kb. Si le bouton n’est pas visible, il faut donc l’ajouter soi-même. Super, essayons… ah, le bouton est introuvable dans la personnalisation. Je retourne lire l’aide, et je vois:

If you don’t see the Hello button in the Additional Tools and Features drawer, please check back in a few weeks. The feature is being made available to users on a gradual basis to ensure that our server infrastructure is able to keep up with the load.

WHAT THE FUCK. L’idée c’est donc: « on va buzzer sur cette feature, mais on va fruster les utilisateurs en l’activant petit à petit ».

On constatera que l’aide française est plus cool:

Si le bouton Hello n’est pas disponible dans le panneau Outils et fonctionnalités supplémentaires , allez dans about:config et changez le paramètre Loop.throttled pour false. Vous pouvez toujours recevoir des appels d’un utilisateur Hello entre-temps.

L’aide française nous donne la solution pour quand même activer Firefox Hello, tandis que l’aide anglaise nous laisse frustré.

Sachant déjà que la majorité des personnes n’iront même pas consulter l’aide, Firefox passe juste pour un navigateur buggé. Au hasard de mes recherches, il semblerait que c’est seulement 10% des personnes qui ont cette option active… c’est ridicule! 9 personnes sur 10 vont se demander où est cette satanée option.

Bref, comme quoi on peut se rater sur autre chose que du code. Les choix totalement débiles en communication, ça existe. Ce qui est surprennant, c’est que je n’ai vu que très peu de sites de news parler de ce problème.

Linux et les disques durs… suite et fin ?

L’histoire de lag des disques durs, c’est à présent le fil rouge de mon blog. Sur google maps, sous Chromium (et Firefox aussi bien sûr), cela rame comme pas possible, pourtant, j’aurai bien aimé que ce soit comme Windows, aucune activité de disque significative (par déduction, les données manipulées sont en RAM). Comme cela m’a vraiment gavé, que les optimisations (nobarrier,data=writeback,noatime et companie) n’y change rien, j’ai sorti l’artillerie lourde block_dump. Un bel outil de bourrin pour linux qui affiche tout se qui se passe sur les disques durs. Autant que c’est vraiment pour du débogage de désespoir car il n’existe aucun outil comme filemon sur linux (inotifywatch -r ahah).

Après avoir activé l’outil, je vois énormément de flush-8:16 et jbd2. Génial, mais je les voyais déjà avec iotop. Sauf que cette fois-ci, je peux voir l’application à l’origine de ces appels. Puis j’arrive finalement à une très longue série de:

Jul 7 23:39:41 localhost kernel: [40813.222707] Chrome_CacheThr(1237): READ block 49119816 on sdb5 (8 sectors)
Jul 7 23:39:41 localhost kernel: [40813.222912] Chrome_CacheThr(1237): READ block 49119824 on sdb5 (8 sectors)

sdb étant mon second disque dur pour /home, j’en déduis que chromium met en cache les données dans /home… ahaha ? étonnant car je vois aussi beaucoup d’accès à tmpfs.

Jul 7 23:47:48 localhost kernel: [41298.459319] Chrome_IOThread(1238): dirtied inode 105835 (?) on tmpfs
Jul 7 23:47:48 localhost kernel: [41298.513204] Chrome_IOThread(1238): dirtied inode 105837 (?) on tmpfs

Mais ceux-ci ne se produisent pas au moment du lag, et en plus l’exemple est mal choisi car c’est seulement du dirtied. Un autre exemple dans un autre lag:

Jul 7 23:49:53 localhost kernel: [41422.756314] Chrome_CacheThr(1237): READ block 49050968 on sdb5 (8 sectors)
Jul 7 23:49:53 localhost kernel: [41422.756494] Chrome_CacheThr(1237): READ block 49050976 on sdb5 (8 sectors)
Jul 7 23:49:53 localhost kernel: [41422.756649] Chrome_CacheThr(1237): READ block 49050984 on sdb5 (8 sectors)
Jul 7 23:49:53 localhost kernel: [41422.817261] Chrome_IOThread(1238): dirtied inode 104017 (?) on tmpfs
Jul 7 23:49:53 localhost kernel: [41422.820708] Chrome_IOThread(1238): dirtied inode 106735 (?) on tmpfs
Jul 7 23:49:53 localhost kernel: [41422.825369] Chrome_IOThread(1238): dirtied inode 106736 (?) on tmpfs
Jul 7 23:49:53 localhost kernel: [41422.825656] Chrome_CacheThr(1237): READ block 49050992 on sdb5 (8 sectors)

En cherchant comment mettre en RAM le cache, je trouve la solution sur le wiki de ma distribution. Mettre le cache en RAM, c’est tellement plus pratique que ce ne soit pas le comportement par défaut pour forcer les gens à trouver la solution eux-même… LINUX!!

Bon après, c’est peut-être parce que le cache en RAM de Chromium est complet qu’il utilise le disque dur (mais j’en doute). Cela provoque des comportements totalement débile que l’on ne rencontre pas sur Windows. Mais le plus étonnant dans tout ça, c’est qu’avant cela ne le faisait pas, c’est venu d’un coup, enfin suite à une mise à jour bien sûr, mais impossible de dire laquelle car le problème n’a pas été rapidement identifié.

Je suppose que pour firefox c’est le même combat. En regardant la solution, elle est pire, il y a une page dédiée à cela, qui concerne tout le profil de firefox mis en RAM (et pas seulement le cache). Avec un script de synchronisation entre la RAM et le système de fichier, avec une CRON pour synchroniser régulièrement… OH STOP, si il faut faire tout ça pour avoir un firefox fluide, c’est hors de question, je reste sur Chromium.

Finalement je trouve cet article, qui permet de changer le dossier de cache seulement. Je me suis retrouvé avec un firefox rapide… non il ne faut pas déconner xD Mais relativement plus rapide qu’avant c’est sûr.

Sincérement, le navigateur est de nos jours généralement le logiciel le plus utilisé sur un desktop, n’avoir ni firefox, ni chromium de correctement configuré par défaut est catastrophique. Mais c’est linux, c’est normal 🙂