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.

Publicités

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.