Kate, bugs forever

Kate (version 5.0.0 mai 2015, Kde framworks 5.9.0), qui comprend rien quand un fichier contient de trop longue ligne, monsieur m’ouvre le fichier qu’en lecture seule car son buffer est trop petit (4096). Il me propose débilement d’augmenter la limite temporairement, que c’est zentil. NON MAIS OÙ ÇA S’EST VU ÇA ? J’en ai utilisé des éditeurs de texte sur Windows, aucun ne m’a affiché ce genre de message, aucun, car c’est DÉBILE, bien sur que je vais l’augmenter trouduc, sur quelle planète les développeurs vivent ???

Ne parlons même pas de la LENTEUR de la frappe, un pauvre fichier json d’une seule ligne de moins de 8 Ko, la saisie de texte LAG (parce que je suis un ouf, j’édite sur la même et unique ligne de texte). CA LAG comme pas possible, je n’ai jamais vu ça sur Windows. Putain Kate sérieux, je n’ai jamais autant critiqué un logiciel de ma vie (cf tous les autres articles de mon blog, je devrais faire une catégorie Kate…). Je suis dans un fichier de 4 391 caractères composé d’une seule ligne, l’édition n’est pas fluide du tout, on sent le logiciel pensé pour fonctionner avec de courtes lignes.

Pour rappel, on parle quand même d’un bête éditeur de texte avec coloration syntaxique de base. Le genre d’application qui existe depuis la nuit des temps, qu’il en existe des tonnes en open source, et que cela nécessite pas une conception ni des algos ultra évolués. Putain de merde quand même, vivre ça en 2015, il y a que KDE pour faire ça.

KDE devrait virer tous les devs qui y ont contribuer, en voici la liste (c’est l’avantage du libre):

  • Christoph Cullmann, non de dieu, sacré mainteneur mon coquin, son rôle principal est de maintenir les bugs à jour, marque de fabrique du logiciel;
  • Anders Lund, spécialisé dans la conception de bugs complexes et innovants;
  • Joseph Wenninger, moins doué que le précédent, sa méthode consiste à glisser de simple usleep() dans le code, très pratique pour justifier un soudain gain énorme de performance pour les prochaines releases et prouver qu’on a travaillé dur;
  • Hamish Rodda, les bugs, c’est sa passion, actuellement au poste de designer de mauvaises expérience utilisateur, son pari a été gagné avec Kate.

Je pense que la palme d’or va pour Matt Newell, testeur, qui a validé que les bugs se comportaient comme prévu. Merci à toi, mec.

Pour rigoler, j’ai ouvert un autre fichier json, de 150 KB cette fois-ci. Outch. J’ai le retour à la ligne dynamique d’activé, quand on édite de grande ligne, c’est bien pratique. Déjà, la sélection rame à mort, car j’ai voulu sélectionner une ligne pour savoir combien de caractères par ligne il y avait… après avoir réussi à sélectionner une ligne, le nombre de caractères sélectionnés n’est pas affichés… ahahah, je ne savais pas que ça existait encore des éditeurs qui ne proposait pas ça, merci Kate de m’avoir faire rire.

Donc, il y a 110 caractères par lignes, la ligne unique du fichier est donc affichée sur plusieurs lignes, cela fait donc un peu plus de 1 300 lignes à afficher. Sauf que la barre de scroll ne tient pas du tout en compte de ce nombre de ligne affichée, j’ai donc une barre de scroll qui sert à RIEN, en scrollant, je vais à la fin de la ligne. La barre de scroll fonctionne par ligne réelle dans le fichier et non par ligne affichée… WOOT. Je disais quoi tout à l’heure ? Ah oui, que c’est un logiciel pensé pour fonctionner avec des lignes courtes… On parle quand même d’un éditeur de texte… La désactivation de la coloration syntaxique ne change évidemment rien au lag (au moins on sait que ça ne vient pas de là).

Lamentable, LAMENTABLE pour un logiciel BASIQUE: afficher et colorer des lignes ce n’est pas la fin du monde, la « techno » existe depuis 100 ans si je puis dire. LAMENTABLE également car c’est un logiciel clé de KDE, une honte.

En bonus, l’aspect modulaire de KDE fait que cette merde d’éditeur de texte est une librairie réutilisable par d’autres applications: KatePart. En particulier, c’est réutilisé par KDevelop. L’aspect modulaire est une bonne chose, sauf quand ce qui est réutilisé est de la merde en barre. Cela pourri tous les logiciels qui s’en servent.

Fuck Kate, Fuck KDE.

Publicités

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é ?

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.

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.