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.

Publicités

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.

Les dépôts

Encore… j’en profite de la sortie de GIMP 2.8, voici ce que l’on peut lire sur pcinpact:

Bien que The GIMP 2.8 soit officiellement disponible, les utilisateurs de distributions Linux devront attendre que les dépôts idoines soient mis à jour. Il reste possible de le télécharger manuellement pour l’installer soi-même ensuite.

Merci de faire comprendre que les gens sous linux ne peuvent pas être à jour tout de suite, et sont ainsi des gens calmes non impulsifs. Ah mais, on peut l’installer soi-même, allons faire un tour sur la page de téléchargement

Déjà on découvre que les « devs » de GIMP sont de vrais branleurs: ils ne fournissent pas de binaire officiellement pour Windows. Mais ils ne sont pas débile non plus, ils ont heureusement un binaire de disponible. Mais ça veut dire quoi ? il n’est pas officiel donc peut-être qu’il ne faut pas avoir confiance ? Qu’il y a un trojan dedans ? D’ailleurs en général, un développeur Windows fournit au minimum un exécutable (pour sa plateforme donc), et quand son application est plus conséquente, il s’emmerde, lui, à créer l’installeur de son application.

Et bien pour linux, c’est souvent je compile pour moi et que pour moi, les autres se démerdent. GIMP est un bel exemple, mais mauvais exemple pour montrer que les dépôts sont bidons, car sa popularité va lui permettre d’être rapidement disponible dans la majorité des distributions. C’est également un bon exemple pour montrer la complexité si l’on souhaite l’installer soi-même.

Je modère toute fois mes propos, sous linux le développeur participe généralement aux dépôts de sa distribution, en particulier si elle est populaire, comme Ubuntu. Les dépôts sont bien pour centraliser les applications, comme les Store, par contre les rendre obligatoire (pour un noob qui ne sait pas compiler ou qui n’a pas installer ce qu’il faut pour), c’est stupide.

Quand on bugfix à moitié, quand on release sans tester

Je dois installer GTK+ 2 et d’autres logiciels pour diverses raisons, et dont je dois compiler moi-même le code source, pour diverses raisons encore. Je télécharge la dernière version à ce jour, là 2.24.5: gtk+-2.24.5.tar.bz2 du 15-Jun-2011 19:23 (http://ftp.gtk.org/pub/gtk/2.24/)… et je me retrouve confronter à un bug remonté et corrigé datant d’avril 2011, voir ici. Malgré la correction, la dernière release ne contient pas le correctif. On peut voir sur la page du bugzilla, qu’une personne (Colin Walters), qui est développeur apparemment, a validé le correctif de Kalev Lember. Ce même développeur a « pushé » le correctif selon ses dires, et je le crois.

Le hic est que le bug a été rapporté pour la version 3.0 de GTK+, et non la version 2.0. Du coup le correctif, on l’aura jamais sauf si un autre rapport de bug est crée. Or GTK 3.0 est récent et la branche 2.0 est toujours supporté. Ce qui signifie simplement que le gars n’a pas cherché plus loin que le bout de son nez. « Ca bug dans la v3 ? Ok je corrige que la v3, osef de vérifier si le bug est aussi dans la v2, et puis ça forcera les gens à passer à la v3« .

Voici un autre problème que j’ai eu, la compilation d’un logiciel (libsigc++-2.2.3) qui foire parce qu’il est impossible de générer la documentation. Ah pire, il y a même une segmentation fault dans la génération de la documentation. C’est xsltproc qui est utilisé à cette finalité et qui plante, un soft Gnome. Juste avant le segfault, j’ai un message qui m’indique qu’une variable d’environnement est non définie. Mais cela ne semble pas être lié, ce serait quand même fort un segfault à cause d’une variable non définie.

Bien sûr, –disable-docs ne fonctionne pas alors que ce serait énormément utile pour ce programme avec beaucoup de documentation. La solution pour ne plus avoir le segfault a été de remplacer xsltproc par le programme /bin/true (par un lien symbolique) pour faire croire que la génération fonctionnait correctement. Cependant, cela n’a pas tout résolu, un autre problème venait de la copie de fichiers lors de l’installation. En effet, l’installeur essayait de copier un dossier inexistant, le dossier tutorial qui a du être supprimé avec le temps et qui du coup faisait planter l’installation. Le font-ils exprès ?

La grande question est es-ce qu’ils ont au moins testé une fois que leur logiciel (leur merde ?) s’installait correctement ? J’espère que oui et ça a du marcher surement grâce à des versions du programme d’installation différent (/usr/bin/install ?) ou d’environnement plus tolérant. Je ne vois pas d’autres solutions.

Ensuite, il y a les programmes qui se foutent des standards, comme pour le .config vu dans un article précédent. La sauvegarde des fichiers package config s’effectue dans /lib/pkgconfig, il y en a qui ont décidé de faire chier et d’aller se mettre dans /share/pkgconfig. C’est la vrai jungle linux… codé par qui/quoi déjà ?

Après il y a aussi les messages d’erreurs incomplets. Visuellement:

checking for XOpenDisplay… no
configure: error: *** libX11 not found. Check ‘config.log’ for more details.

et après il faut décortiquer config.log. Certes ce n’est pas compliqué, mais pourquoi ne pas donner simplement la solution plutôt que de dire grossièrement: "va voir l’erreur et débrouille toi pour y remédier".

GNU est une grosse déception aussi. J’ai eu à compiler binutils2.21.1, nickel la première fois. Quelques heures après je me décide à recompiler pour ajouter une option, mais entre temps j’avais changé la variable d’environnement LIBS. Pas de problème, il me chie dessus mais il me dit quoi faire, un make distclean. Sauf que, ça ne marche pas, malgré tous les cleans possible, il ne veut rien entendre, LIBS a changé et même en remettant la valeur d’origine cela ne marche pas. La solution ? Supprimer le dossier et décompresser à nouveau binutils… ou bien supprimer tous les config.status des sous-dossiers. Si les développeurs de GNU ne savent même pas faire un clean propre, où va t-on ? Ah linux. A croire que c’est fait exprès pour permettre à des entreprises de vendre du support… le seul modèle économique viable pour l’open source c’est bien vendre du support.

Avec GNU toujours, autant pour tous les autres logiciels la commande ./configure indique quels sont les paquets manquants qui vont faire obligatoirement échouer la compilation, autant pour binutils ce n’est pas bloquant. D’un certain coté c’est bien si jamais ./configure se trompe. Linux, la diversité des compilations, des installations et des bugs, le prix de la trop grande liberté ?

Pour finir, je vais rappeler l’exemple déjà énoncé dans un autre article, bumblebee. Le script d’installation qui possédait un bug, un espace supplémentaire a été inséré dans une commande de suppression qui provoquait la suppression complète du dossier /usr au lieu d’un simple fichier.

C’est ce qui arrive quand il n’y a aucune conséquence pécuniaire quand on fait une connerie: on ne fait pas attention, on fait ce que l’on veut pour le plaisir de le faire, pour le plaisir de faire plaisir aux autres et si ça rate tant pis, au pire on déçoit quelqu’un, alors pourquoi faire un travail de qualité professionnelle quand on s’investit dans le libre sur son temps libre ?

Cela me permet de faire naturellement le lien avec le système de dépôts/paquets de linux. Le système de dépôts, même si je l’ai beaucoup critiqué, est dans un sens pratique: il met à jour tous les logiciels facilement. Des systèmes équivalents ont vu le jour sur Windows (en plus de Windows Update), il y a ninite par exemple. C’est en effet pratique même si l’on devient dépendant d’une entité qui offre un service. Cependant, lors de mise à jour majeur d’une logiciel, ce sont des habitudes ou des fonctionnalités qui peuvent être perdu.

Mais dans le cadre de linux, les dépôts sont obligatoires pour les raisons évoquées ci-dessus: il est impossible d’installer soi-même un logiciel. Les paquets permettent de s’affranchir de toute la merde des développeurs en amont pour avoir un logiciel qui s’installe et marche. Les paquets nécessitent l’intervention d’une personne qui va compiler, configurer les fonctionnalités avec les options de configuration et pré configurer le logiciel pour vous, et en sous entendu: traiter tous problèmes éventuels pour faire réussir la compilation et le logiciel (car cela peut compiler, mais le logiciel peut ne pas marcher). Il faut cet intermédiaire obligatoire sur linux quand on n’est pas un bidouilleur (et là attention, tout fanatique vous répondra pour vous rassurer qu’il y aura toujours au moins un bidouilleur pour vous créer un paquet).

Etre dépendant à ce point, cela ne me plait pas du tout. Autant pour Windows, ce que fait ninite est grosso modo une automatisation d’installation, autant pour Linux, les paquets sont une valeur ajouté indispensable. Autant être dépendant des paquets (ou Windows Update) pour la mise à jour du système d’exploitation est une chose, autant pour des logiciels classiques c’est autre chose.

Certains diront que c’est un avantage, d’autres un inconvénient, car avec ce système de dépôts, une librairie peut-être mise à jour facilement. Par exemple zlib se met à jour (sans changer l’API existante quand même, donc une mise à jour de sécurité) et tous les programmes peuvent en profiter. Sous Windows, jamais on va se dire « tiens, je vais voir si il y a une nouvelle version de zlib », d’ailleurs on ne se le dit pas non plus sur linux, puisque ce sont les mainteneurs qui s’en occupent. Sous windows, la librairie zlib n’est pas forcément partagée, elle est incluse à chaque fois par l’assistant d’installation des programmes qui s’en servent. Anisi quand on installe un programme, il va installer tout ce qui est nécessaire à son fonctionnement, sauf cas particulier, genre les applications .NET qui ont besoin du framework .NET, ou bien de grosse application dont l’installateur principal va exécuter l’installeur d’un sous programme.

Sous linux, ce ne sont pas des cas particuliers, c’est le fonctionnement normal. Il y a une arborescence de dépendances entre les logiciels et les librairies, donc par exemple pour installer GTK+2.0, il faudra avant plein de paquets mais c’est un mauvais exemple car on peut considérer que GTK+2.0 c’est le coeur d’un système et personne n’aura à l’installer (à part les mainteneurs). Pour installer mumble, comme a pu le voir dans mon article sur les dépôts, il fallait installer plein de dépendances, la liste de paquets que l’on avait vu était les dépendances et les dépendances des dépendances. Du coup, qui détermine cette arborescence de dépendance ? la distribution, les mainteneurs. Ce n’est pas le développeur, lui il dit simplement qu’il faut telle librairie avec telle version pour compiler son programme. Il ne peut même pas aider les mainteneurs car le nom des paquets peut être différent entre les distribution. La création des paquets est un travail superflu qu’aucun développeur ne veut faire.

Qt ou GTK

Qt qui s’écrit comme je viens de le faire, et surtout pas QT comme beaucoup de français le font. Cela veut dire qu’ils ne comprennent même pas ce que cela veut dire, en effet Qt se prononce « cute » et qui signfie mignon. GTK s’écrit comme je viens de le faire car c’est un acronyme pour Graphic Tool Kit.

Les deux « outils » permettent de créer des interfaces utilisateurs graphique (GUI), c’est à dire des fenêtres en gros, avec tout ce qu’il faut dedans (bouton, case à cocher, etc). GTK est créé à l’origine pour GIMP, Qt a été développé par Trolltech et est à présent dans les mains de Nokia. Qt possède une license commerciale mais aussi Open source pour les projets libres.

Qt est utilisé par KDE, c’est l’outil principal utilisé pour les fenêtres, et GTK est utilisé pour Gnome. Cela donne l’impression qu’une application GTK ne fonctionnera pas sur KDE et réciproquement (une application Qt sur Gnome). C’est faux heureusement, sauf si l’application utilise des fonctionnalités propres à l’environnement de bureau (par exemple KatePart qui est un composant de KDE comme on a pu le voir tout à l’heure). Par contre il va y avoir une différence de rendu visuel: le thème. Une application GTK sera moche sur KDE, et une application Qt sera moche sur Gnome… ou pas. Qt 4+ est cute sur beaucoup d’environnements, dont Gnome. Il s’adapte parfaitement, à quelques exceptions prêts. Par contre GTK est moche de partout, sauf sur Gnome. Même sur Windows, c’est moche, mal intégré, mais ça marche et c’est l’essentiel (sauf pour le grand public). Bon ce n’est pas toujours si moche, pidgin est assez correct mais on sent qu’il est différent des autres applications KDE.

Un autre problème est si vous êtes sur KDE par exemple, et que vous voulez utiliser une et seulement une seule application GTK, il va falloir télécharger tous les paquets GTK. Cela représente des mégaoctets, juste pour une seule application. C’est d’ailleurs également valable pour Windows, à la différence sur linux, c’est que cela fonctionne par paquet, qui eux sont dépendants de la distribution, et si la distribution est pourrie alors GTK a mal été packagé et l’installation de GTK peut faire plusieurs centaines de méga. C’est réciproque pour Qt pour un environnement Gnome, alors la solution consiste à utiliser une meilleure distribution.

Sur linux il y a donc des trolls entre Qt et GTK, de qui est mieux, du pourquoi, du comment. Que Qt est maintenu par Nokia et non par la « communauté » (pas de l’anneau). Mais d’un autre coté cela stimule la compétition, tout en fragmentant les applications: il y a généralement deux versions d’une application: une en Qt, une en GTK, quand ce n’est pas 50 en Qt, 50 en GTK, et 25 avec des toolkits nouveaux ou exotiques.

Lequel est mieux, lequel est pire ? Généralement avec cette question facheuse, le camp qui se sent du coté du pire va tout simplement répondre: il y a des besoins différents… qui est pourtant le même: afficher une fenêtre et des boutons. Derrière cela se cache d’autres raisons, si c’est Qt le pire:

  • soit parce qu’on a pas envie d’apprendre un nouvel outil par fénéantise ou par manque d’utilité (à quoi bon connaître deux outils identiques)
  • soit parce qu’on aime pas Qt
  • soit parce qu’on est dans l’idéologie libriste et on refuse de toucher à Qt car c’est Nokia qu’il le gère (note: mais accepte les contributions externes)
  • soit parce que c’est pour le plaisir de la diversité
  • soit parce qu’on a participé à GTK et qu’on ne le laissera pas tomber par principe

ou toutes autres raisons auxquelles je ne pense pas actuellement. Pour GTK c’est la même chose, sauf pour l’idéologie libriste. Pour ma part, j’ai du mal à comparer les deux, je me suis servi de GTK à l’université et j’ai détesté, et je me suis servi de Qt et j’ai accroché. La notion Signal/Slot est très puissante, bien que l’on retrouve presque la même chose dans GTK, mais surtout Qt est un framework plutot qu’un simple outil dédié à l’UI, qui du coup peut sembler plus lourd mais il est découpé en module et permet de faire beaucoup plus de choses en beaucoup moins de lignes. Le framework Qt est cross-plateforme, utiliser ce que fourni le framework est alors préférable pour faciliter le portage.

Voici deux applications que j’apprécie et qui fonctionnent aussi bien sur Windows que Linux: Mumble et KVirc. Une application bien utile en GTK était aMSN, entièrement mal intégrée quand utilisée sur Windows, et pire sur KDE.

Les cas d’erreur

Si il y a un reproche à faire aux logiciels de linux, c’est la gestion des erreurs. Il y a l’outil magnifique qui est syslog, mais je fais plutot référence au style de codage: le programmeur s’attend quasiment à avoir des données dans le bon format en entrée. Tout débutant débute comme cela car déjà on n’y pense pas forcément, mais en plus la gestion des erreurs peut être chiante, surtout une bonne gestion d’erreur qui consiste au moins à afficher l’erreur, voire la raison dans le meilleur des cas.

Dans le pire des cas, on se retrouve avec une erreur de segmentation. Cela m’est arrivé une fois et si j’en parle aujourd’hui c’est parce que cela ne concerne pas un logiciel inconnu mais un outil de base du système: update-mime-database. Pour résumer, ce programme s’occupe de mettre à jour la base de données des types MIME connus. Ceci fonctionne à base de fichiers XML qui sont en gros analysés et sauvegardés dans un fichier binaire. Rien de bien sorcier, sauf qu’un fichier XML a pour vocation d’être édité à la main, et malgré avoir rigoureusement suivi le tutorial pour ajouter un nouveau type MIME, le programme plante lamentablement sur un Segmentation fault. Un programme critique du système qui plante à cause d’un XML bien formé et qui ne donne pas la raison de plantage…

Déjà dans le tutorial (ce n’est pas le lien exact, je ne retrouve plus le tutorial), on voit que l’on est dans la rubrique Administrator du site de Gnome, on est plus dans la branche Users, donc la réaction classique: « tu es un mauvais admin, bla bla bla », et donne l’impression que cela ne concerne pas les utilisateurs. Passons… Je débogue le programme… c’est ça qui est bien avec l’open source, les sources sont disponibles, et miracle, elles se compilent sans complication.

Déjà ce programme est juste une grosse blague: un fichier immense (3500+ lignes), écrit par Thomas Leonard et bien sûr « with ABSOLUTELY NO WARRANTY » et ça se voit. Il a été écrit en 2003, on peut dire que cette absence de structure est dû au faible génie logiciel de l’époque, c’est pardonnable (quoi que). Hors de question de plonger dans ces 3500 lignes, une compilation avec les options de débogage et j’aurais la ligne du « Segmentation fault ». Je fais donc tout cela, j’utilise Valgrind aussi tant qu’à faire, je trouve la ligne correspondante, sans comprendre pourquoi je la corrige, juste un simple test à ajouter (cf le patch) puis j’ai créé un bug report avec son patch (sans fournir de testcase dans l’immédiat car je pensais que ça allait sauter aux yeux des développeurs xD).

Évidemment il n’y avait plus de développeurs, juste le mainteneur (qui est quand même un dév), et il a mieux corrigé le problème avec l’ajout d’un message d’erreur. J’ai pu ainsi connaître la raison du plantage: il manquait une balise XML dans le fichier… WTF. C’est la base du XML pourtant d’être éditable par un humain et donc sujet à des erreurs ou des oublis (je précise que le XML était bien formé, ce n’est pas une balise fermante ou ouvrante qui manquait, mais une balise apparemment obligatoire).

A vrai dire, des fois il y a des bugs gros comme une montagne, et montre tout simplement que du code critique est commité et est passé en production (release) sans jamais avoir été testé. Exemple classique: bumblebee, qui va certainement en devenir une référence en la matière. En effet, c’est le script d’installation qui possédait un bug, un espace supplémentaire a été inséré dans une commande de suppression qui provoquait la suppression complète du dossier /usr au lieu d’un simple fichier.

C’est la dure vérité des projets non financé: certains (impossible de sortir des chiffres) développeurs s’en foutent et release leur logiciel en comptant sur la communauté pour remonter les bugs. Ils ne se reliront pas avant de commiter, ils ne testeront pas (dans le cas de bumblebee peut-être qu’il ne pouvait pas car il fallait une carte graphique nvidia), il y a personne pour assurer la qualité, c’est à vos risques et périls, ce n’est pas pour rien qu’il est rappelé dans tout logiciel qu’il est distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Ceci dit, il n’y a aussi aucune garantie pour les logiciels propriétaire.

Le pire est que c’est pareil avec la release de GTK+2… un gros projet avec du monde derrière. J’ai eu le malheur de devoir compiler GTK+2 et j’ai téléchargé l’archive version 2.24.5 (daté du 16-Jun-2011) qui est donc la dernière version stable pour la version 2 (la 3 étant sortie depuis un moment)… et au moment de la compilation… grosse blague, je retombe sur un vieux bug censé être corrigé en avril 2011…

Plus précisément, la correction a été « pushed ». C’est à dire que la proposition de patch a été faites, mais que personne n’a voulu l’intégrer. Le rapport de bug indique que cela provient du linker et que windows serait fautif, pour ma part je suis sur linux et j’ai eu ce problème. En fait ça revient à ce que je dis depuis toujours: à partir du moment que les développeurs ne rencontrent pas le bug alors il n’y a rien qui change, ou alors lentement.

Ceci dit, coté logiciels propriétaires ce n’est pas mieux, voire pire… ou meilleur, c’est comme partout, cela dépend des personnes qui s’occupent d’un projet.