David Madore's WebLog: Quand l'informatique libre a-t-elle arrêté de progresser ?

Bon, je conviens que le titre de ce billet est un petit peu provocateur. Néanmoins, je veux parler de quelque chose de sérieux.

Quand j'ai commencé à utiliser l'écosystème Linux, chaque nouvelle version de la distribution (d'abord Red Hat, avec laquelle j'ai débuté en 1997, puis Debian à partir de 2004) était pour moi une sorte de fête : certes, il y aurait des choses qui casseraient, mais il y aurait aussi de nombreuses nouveautés intéressantes à tester et à utiliser. Puis ces progrès, ou cette perception par moi de progrès, ont ralenti, et ensuite se sont arrêtés à peu près complètement.

Maintenant, chaque mise à jour de la distribution (Debian ou Ubuntu : j'utilise les deux selon mes machines) est pour moi uniquement synonyme d'emmerdes : énormément de temps perdu à la mise à jour elle-même, bien sûr, mais aussi énormément de temps perdu à traquer tout ce qui aura été cassé par elle, et, ce qui est le plus grave, énormément de tracas à découvrir que telle fonctionnalité dont je dépendais a été supprimée, que tel programme que j'utilisais n'est « plus supporté » parce que « plus maintenu », que telle configuration n'est plus possible, etc.

Ça doit faire une dizaine d'années environ qu'il n'y a essentiellement pas eu de progrès intéressant, de mon point de vue, dans un des programmes que j'utilise : je veux dire quelque chose de nouveau qui pourrait m'être utile, qui me simplifie la vie, qui me permet de faire quelque chose que j'ai envie de faire. En revanche, les suppressions sont pléthore : au mieux, je découvre qu'il faut maintenant faire les choses autrement (et que j'ai des pelletées de configuration à revoir ou à migrer au nouveau standard), au pire, j'apprends que tel truc n'est plus disponible du tout.

Ceci vaut pour à peu près tous les aspects de l'informatique que j'utilise : j'évoque la distribution Linux dans son ensemble, mais c'est vrai aussi pour un programme spécifique comme Firefox, ou pour Android sur mon téléphone mobile.

Je peux lister plein d'exemples. Aucun n'est particulièrement intéressant en lui-même, et mériterait plein de précisions ou d'explications que je n'ai pas envie de fournir, mais en voici quelques uns juste pour montrer le genre de choses dont je parle :

Quand j'ai commencé à utiliser Mozilla (ensuite rebaptisé en Firefox, transition qui a d'ailleurs apporté son propre lot de problèmes), il était extrêmement configurable par un mécanisme appelé XUL (j'avais même fait un petit tutoriel à ce sujet sur ce blog), une sorte de HTML spécialisé dans la conception d'interfaces graphiques, et qui pouvait d'ailleurs cohabiter avec HTML. Je m'en suis servi pour plein de petites choses utiles pour moi, et, vlan, ça a été supprimé (je ne sais plus quand exactement) en faveur d'un mécanisme d'extensions beaucoup moins puissant, qui a d'ailleurs mis fin à un nombre hallucinant de plugins du navigateur.
Ce n'est pas le seul exemple au rayon des navigateurs, d'ailleurs : aussi bien Chrome que Firefox n'arrêtent pas de retirer des choses (le plus épatant a été quand Chrome a, du jour au lendemain, totalement retiré le MathML — il est vrai, là, qu'ils ont fini par le remettre, mais ça a pris des années). D'ailleurs, le standard HTML lui-même retire des fonctionnalités (par exemple ils ont retiré l'attribut scoped sur la balise <style>, et ça m'a bien emmerdé parce que moi je m'en servais beaucoup, par exemple quand je veux ajouter du style sur un billet de blog).
Android mériterait un chapitre à lui entier. Mais donnons juste quelques exemples. À un moment, j'utilisais adb pour faire du reverse-tethering, c'est-à-dire que je fournissais au téléphone une connexion réseau par l'ordinateur au lieu de faire le contraire, ce qui était très pratique pour échanger entre les deux : ça a été rendu impossible pour des raisons, je crois, de sécurité. J'utilisais énormément le recovery mode TWRP pour faire des backups de mes fichiers Android : le projet est plus ou moins abandonné parce qu'Android a changé de mécanisme de boot. J'utilise régulièrement F-Droid pour installer des apps : de ce que je comprends, Google est en train de le tuer aussi pour un prétexte de sécurité.
Pendant tout ce temps, d'ailleurs, je n'ai pas vu la moindre nouveauté vaguement utile apparaître dans Android depuis une dizaine d'années. Entre autres, ils ne sont toujours pas foutu d'inventer un mécanisme de backup complet de l'appareil (avec toutes les données de toutes les apps) sur ordinateur, un truc que l'informatique est censée savoir faire depuis les années 1950 environ.
Sous Linux, il y a eu toute la saga de la migration forcée de sysvinit vers systemd. D'autres gens pourront vous dire plein de mal de systemd, ce n'est pas vraiment mon propos ici. Mon propos, en tout cas, c'est que ça a cassé plein de choses dans ma config, qu'il y a encore plein de choses que je ne sais pas faire avec, et que je n'ai absolument rien gagné au change.
(Ma machine démarrait très bien avec sysvinit. Depuis le passage à systemd, une fois sur trois elle ne démarre pas bien, probablement parce qu'il essaie de tout lancer d'un coup et qu'il doit y avoir des dépendances qui ne sont pas correctement enregistrées ; mais je ne sais pas lesquelles, je ne sais pas comment débugguer ça, et ce n'est pas moi qui ai écrit ces scripts de démarrage : du coup, moi, j'aimerais juste pouvoir lui dire de tout lancer dans un ordre prescrit et reproductible, comme c'était le cas avec sysvinit, mais ça je ne sais pas le faire simplement avec systemd.)
J'avais une config son qui marchait très bien avec ALSA. Un jour on m'a expliqué : maintenant il ne faut plus utiliser ALSA directement, il faut utiliser PulseAudio. Mais PulseAudio, je n'ai jamais réussi à le faire fonctionner (au pire ça ne marche pas du tout ; au mieux, ça marche, mais dès que j'essaie d'ouvrir une seconde session au nom d'un autre utilisateur sur un autre terminal virtuel, la deuxième session n'arrive pas à lancer son PulseAudio, donc il n'y pas de son… alors que ça marchait très bien avec ALSA et que je crois comprendre que c'est exactement ce que PulseAudio était censé régler, comme problème).
Du coup, je serais bien resté avec ALSA, mais un jour Firefox m'a dit : ALSA c'est fini, on ne supporte plus, il faut utiliser PulseAudio. Donc plus moyen pour moi d'avoir du son dans Firefox (pendant longtemps j'ai dû le compiler spécialement avec une option qui rétablissait le support ALSA, mais ça a fini par cesser de marcher).
Bon, ceci étant, il faut croire je ne suis pas le seul à maudire PulseAudio, parce que des gens très malins ont inventé un truc appelé apulse qui fait semblant d'être un PulseAudio au-dessus d'ALSA, et, contrairement à PulseAudio, lui, il fonctionne pour moi. Mais que de temps perdu !
Et bien sûr, entre temps, les gens ont encore changé d'avis et maintenant le nouveau truc shiny qu'on va nous imposer à tous, c'est PipeWire. Je n'ai pas encore testé, mais je sens que ça va être autant la merde que PulseAudio, et j'espère qu'il y aura un truc qui est à PipeWire ce que apulse est à PulseAudio.
Le poussinet et moi nous sommes récemment acheté une nouvelle imprimante (Brother HL-L5210DW, mais peu importe). Je me documente sur comment la configurer, et j'apprends que les pilotes d'imprimante c'est obsolète et que maintenant on est censé utiliser du driverless. Je ne comprends rien à la page de doc que je viens de lier, mais je tente de configurer l'imprimante en driverless comme je peux, j'essaie d'imprimer une page de test, et évidemment il a craché quelque chose comme 50 pages de symboles aléatoires (comme si on avait envoyé un fichier binaire à l'imprimante et qu'elle l'avait imprimé comme du texte… ce qui est peut-être peu surprenant s'il n'y avait pas de driver pour l'interpréter). Beau gâchis de papier, soit dit en passant (le problème des imprimantes laser, c'est qu'elles impriment vite, donc si on leur balance du junk, ça gâche du papier très vite).
Bon ben je ne sais pas comment cette merde était censée marcher, mais le fait est que, pour moi, elle ne marche pas, et que la doc n'est pas vraiment Éclairante. Peut-être qu'avant de remplacer un truc qui marche il faudrait avoir un remplacement qui marche aussi ? Peut-être que les pilotes d'impression, ils servaient à quelque chose et que se dire qu'on va simplement les supprimer ce n'est pas une idée si géniale que ça ? Mais je dis ça je dis rien.

J'entends dire de plus en plus fortement que X11 (le système graphique que j'utilise) va être remplacé par un truc appelé Wayland (et personne n'a été capable de me dire ce que Wayland était censé m'apporter comme bienfait en contrepartie des tracas qu'il va me causer). L'ennui, c'est que Wayland retire plein des fonctionnalités de X11 que j'utilise, et qu'il n'y a rien pour les remplacer.
Le problème le plus criant et la plus concret pour moi est que Wayland ne peut pas faire tourner le gestionnaire de fenêtre que j'utilise (fvwm) et sur lequel toute ma configuration graphique est construite. Manifestement la philosophie de Wayland a été de n'être conçu que pour les intérêts des grosses interfaces graphiques (essentiellement : Gnome et KDE) en ignorant tous les autres, qui vont devoir réécrire plein de choses qui eurent autrefois été dans X11 et qui auront été abandonnées par Wayland, une tâche qui, pour beaucoup d'entre eux, est assez insurmontable. Donc apparemment le message est : si vous utilisez autre chose que Gnome ou KDE, vous n'aurez que vos yeux pour pleurer, et nous on passe en force le changement de X11 à Wayland.
Il y a vaguement une couche de compatibilité X11 sous Wayland, mais elle est totalement inaboutie parce que même sous Ubuntu (ou j'utilise effectivement Gnome et pas fvwm), je me suis rendu compte que plein de choses étaient cassées (par exemple, xset s reset ne fonctionnait pas quand je voulais empêcher, dans un script, le screensaver de s'activer : c'est dire si cette couche de compatibilité est incomplète ! et d'ailleurs, personne n'a été capable de me dire l'équivalent Wayland de xset s reset).
Prenons un exemple de petit réglage de configuration auquel je tiens beaucoup : en tant qu'utilisateur d'Emacs, j'aime que, dans à peu près n'importe quel contexte, control-A (beaucoup plus commode à taper que la touche Home) aille au début de la ligne plutôt que tout sélectionner. (Ce n'est d'ailleurs pas que pour aller au début de la ligne, mais aussi pour éviter de tout sélectionner, manip dangereuse si on le fait par accident et qu'on tape une lettre derrière, tout sera remplacé.)
Dans le temps on pouvait obtenir ce comportement en mettant gtk-key-theme-name = "Emacs" dans le fichier .gtkrc-2.0 ; puis un jour quelqu'un a décidé que maintenant la bonne façon de faire serait de mettre gtk-key-theme-name = Emacs (sans guillemets, c'est important !) dans le fichier .config/gtk-3.0/settings.ini ; puis un jour quelqu'un a décidé que, sous Gnome, c'est gsettings set org.gnome.desktop.interface gtk-key-theme Emacs qu'il faut faire à la place ; puis un jour c'est Firefox qui décide que ça ne marche plus, jusqu'à ce que je passe des heures à découvrir la préférence super cachéee ui.key.textcontrol.prefer_native_key_bindings_over_builtin_shortcut_key_definitions (sérieux ‽) qui permet de le refaire marcher. Vous imaginez tout le temps perdu pour trouver comment réparer cette fonctionnalité qu'on n'arrête pas de me casser sous les pieds ? Pourquoi tant de haine ?

Et maintenant j'entends dire que Gtk4 va purement et simplement supprimer cette fonctionnalité.
Voilà qui illustre très bien le problème : dès que vous sortez du moule avec un micro petit réglage qui vous simplifie la vie, on n'arrête pas de le casser sous vos pas, pour finalement vous dire un gros fsck you, on va vous le supprimer complètement. (Parce que oui, certainement, permettre de configurer quelle touche fait quoi dans l'édition d'un champ texte, ça doit être un grooooos travail de maintenir ça. C'est certainement une exigence déraisonnable de ma part de vouloir paramétrer un peu les bindings clavier de l'édition des champs texte. /s)
Les pages des billets individuels de ce blog sont générées par Apache Tomcat. Quand j'ai voulu faire je ne sais plus quelle mise à jour, il est passé de Tomcat 9 à Tomcat 10. Et j'ai appris qu'à cette occasion j'étais censé… complètement réécrire le code Java, parce qu'ils ont totalement cassé l'interface. Je ne m'en suis pas encore occupé, ça va certainement encore être douloureux (mais pour le coup, peut-être qu'une IA saura m'aider !). Néanmoins, cet exemple est assez ironique, parce que ça signifie que même dans le monde de Java, où les choses ne sont justement pas censées casser, eh bien les choses cassent quand même.

Encore une fois, je peux en donner plein d'autres, et mon propos n'est pas de me focaliser sur tel ou tel de ces points. Le motif commun, c'est une combinaison des choses suivantes :

On a décidé de réinventer la roue, en prétendant que la nouvelle roue est mieux que l'ancienne roue. On ne va implémenter que la moitié des fonctions de la roue précédente, parce que les autres sont pénibles à réécrire. Si vous dépendiez des fonctions qu'on ne réinvente pas, on vous dit un gros fsck you.
On vire des fonctionnalités au hasard des prétextes suivants : c'est pour la sécurité !, c'est pour l'efficacité ! ou c'était trop compliqué à faire interagir avec le reste du code (dans tous les cas : la fonction posait tel ou tel problème, et plutôt qu'essayer de régler le problème on vire la fonction).
On prétend qu'on n'a pas assez de développeurs pour continuer à maintenir cette fonctionnalité (et/ou que personne ne s'en sert), donc on la retire.

Toujours est-il que maintenant chaque mise à jour est une angoisse : combien de choses dont j'ai besoin vont avoir cessé de fonctionner à cause d'une décision de ce genre ? Combien vais-je souffrir à réparer les dégâts de la mise à jour, à devoir trouver des façons de les contourner, ou à chercher des succédanés pour remplacer ce qui n'existe plus ? Je ne suis certainement pas un novice dans l'usage de Linux, mais je traîne la patte pour faire les mises à jour substantielles autant que les novices qui sont terrifiés par la manip (et, de fait, je suis assez terrifié).

Certainement une partie de l'effet vient de ce que j'ai vieilli, et que si à 20 ans je trouvais rigolo de découvrir tout ce qui a cassé dans une mise à jour de Linux, c'est carrément moins rigolo à 50 ans de passer plein de jours à réparer tout un tas de trucs : je n'ai plus juste envie de m'amuser avec les ordinateurs en découvrant des nouvelles babioles, j'ai aussi et surtout envie qu'ils marchent. Donc, oui, on peut m'accuser du conservatisme de la vieillesse, mais d'une part ce serait bien que les vieux aient aussi le droit d'utiliser Linux, d'autre part je pense que ce n'est pas juste moi qui ai changé en ~30 ans — il y a vraiment plus de choses qui cassent et de fonctionnalités qui disparaissent.

L'écosystème Linux ressemble de plus en plus à l'écosystème Google (et ce n'est peut-être pas un hasard), qui a la réputation de tuer sans arrêt les projets ou fonctionnalités que les gens utilisaient (il y a même un site Web consacré spécialement au recensement de ces choses).

Et en contrepartie… ben il n'y a pas de contrepartie. Il n'y a plus la moindre nouvelle fonctionnalité qui pourrait m'être vaguement intéressante ou utile. En exceptant les corrections de bugs, la dernière fois que j'ai remarqué le moindre truc utile nouveau dans un programme que j'utilise, c'était l'apparition de l'option --open-noatime de rsync (ajoutée dans la version 3.2.0 en 2020) : comme on le voit, ce n'est pas vraiment fulgurant (d'ailleurs, il se peut que ce soit un copain qui soit responsable de son ajout). Pas franchement fulgurant.

Soyons bien clairs : je veux juste dire que l'absence de nouvelle fonctionnalités utile à mes yeux signifie que j'ai du mal à avaler l'excuse qu'il fallait virer Foo pour faire de la place pour Bar. À titre personnel, je ne réclame pas spécialement de nouveautés. Ça me va très bien s'il n'y en a pas (c'est juste que, du coup, il ne faut pas non plus retirer des choses). L'idée qu'un programme soit figé dans le temps et n'ajoute rien de nouveau à part des correctifs de sécurité et de bugs (et éventuellement du support pour du matériel nouveau, si ça a un sens) me convient parfaitement.

Je trouve parfaitement stupide cette espèce de course de la Reine rouge qui exige qu'il doive toujours y avoir du nouveau, sinon le programme est considéré comme moribond. Au contraire, au bout d'un moment, le programme fait ce qu'on attend de lui, et on devrait arrêter d'y toucher et passer à autre chose (sauf si et quand un trou de sécurité est découvert, mais normalement le nombre de trous de sécurité devrait décroître exponentiellement avec le temps à partir du moment où on n'ajoute rien de nouveau !).

Le problème, c'est que justement, à cause de ces trous de sécurité permanents, on ne peut pas rester sur une vieille version (enfin, en tout cas, pas sur le moindre programme qui peut avoir un enjeu de sécurité, ce qui signifie quasiment tous). Ça c'est quelque chose de beaucoup plus prégnant maintenant que quand j'ai commencé à utiliser Linux : tout le monde est tout le temps connecté à Internet, donc on ne peut vraiment pas se permettre de tomber en retard sur les mises à jour de sécurité. Et si le mainteneur du programme a décidé de virer une fonctionnalité, ben on n'a pas de choix que de la voir disparaître, parce qu'il faudra bien faire les mises à jour. Donc ces gens ont, en pratique, et sans aucun compte à rendre, le pouvoir de retirer des choses que j'utilise vraiment sur mon ordinateur. Et ça me met très en colère. Parce que c'était précisément tout le but du logiciel libre que cette situation ne se produise pas.

Alors je sais ce qu'on peut me rétorquer : C'est gratuit donc tu ne peux pas te plaindre. (Je devance cette réplique parce qu'on me l'a souvent faite.) Cet argument est doublement stupide.

Il est stupide, d'abord, parce que c'est tout simplement faux de prétendre qu'on ne peut pas se plaindre de quelque chose de gratuit. À titre d'exemple, ce n'est pas parce que Twitter est gratuit que personne (ou alors, seulement les gens qui ont pris une formule payante) n'a le droit de se plaindre de la manière dont Elon Musk en fait un instrument de propagande ; ce n'est pas parce que Google est gratuit que personne n'a le droit de se plaindre de la manière dont ils référencent les pages ; et ce n'est pas parce que ChatGPT est gratuit que se plaindre des IA est inacceptable. Les gens qui prennent des décisions politiques qui orientent des pans entiers de l'écosystème Linux ou Web ou mobile prennent des décisions politiques (n'ayant certes pas autant d'impact sur toute la société que les décisions prises par Twitter, Google on OpenAI, mais, toutes proportions gardées, néanmoins importantes) : il est normal de demander à qui ces gens répondent (les utilisateurs ? les gens qui payent ?), et qui choisit ces décideurs et comment.

Ensuite, si je comprends bien l'argument si on t'offre un cheval, ne regarde pas ses dents, ce n'est pas la bonne analogie ici : la bonne analogie serait plutôt qu'on m'a offert un cheval avec une visite d'entretien régulière, et qu'un jour le cheval revient de cette visite amputé de toutes ses dents et qu'on m'explique que quelqu'un a décidé que c'était mieux comme ça et que je n'ai pas à me plaindre vu que le cheval était gratuit (et que ce n'est pas leur problème si je ne sais pas comment je vais nourrir le cheval maintenant).

La deuxième chose qu'on peut me rétorquer (et on le fait souvent), c'est qu'on ne peut pas forcer les mainteneurs à maintenir une feature qu'ils n'aiment pas.

Alors oui, ça c'est vrai : je ne propose absolument pas qu'un mainteneur quelconque soit obligé de s'occuper d'une fonctionnalité qu'ils n'aiment pas. Mais ce n'est pas pareil que d'avoir le droit de la virer du code. Le mainteneur a le droit d'ignorer ce bout de code et de ne pas y toucher. Il a aussi, et surtout, le droit de démissionner du projet s'il ne veut pas maintenir un bout du projet qu'il n'aime pas. Si vraiment un projet ne trouve personne pour faire ne serait-ce que des mises à jour de sécurité sur un bout de code, alors il y a vraiment un problème, et effectivement je ne peux pas trop me plaindre. Mais en général ce n'est pas ça : c'est que quelqu'un à la tête du projet décide d'utiliser sa position politique pour attribuer les ressources de développeurs dans la direction qui l'amuse.

Or sur le principe, on doit toujours privilégier la fonctionnalité existante par rapport à celle qui est en passe d'être écrite, parce que la fonctionnalité existante peut servir à des gens, lesquels peuvent même dépendre d'elles, tandis que celle qui est en passe d'être écrite, par définition, ne sert encore à personne, et personne n'en dépend. Je conviens que ce n'est pas un argument absolu, et je ne défends pas l'idée que jamais personne ne doit retirer le moindre bout de code d'un programme, mais si ça m'affecte aussi fréquemment sur le nombre certainement pas gigantesque de programmes que j'utilise c'est forcément que ça arrive trop souvent et que ça affecte plein de gens.

En général on peut dire aux gens qui ne sont pas contents d'un logiciel libre soumettez un patch pour réparer le problème, mais je pense deviner que si on soumet un patch qui annule simplement la modification supprimant une fonctionnalité, ce ne sera pas accepté.

Bien sûr, en principe, celui qui n'est pas content de telle ou telle évolution peut forker le projet (c'est-à-dire en créant un nouveau sur la base du code préalable). Mais en pratique, il y a un immense effet de réseau, donc une immense barrière au fork : c'est la raison pour laquelle on ne peut pas juste ignorer ce qui se passe sur le Twitter d'Elon Musk en disant ceux qui ne sont pas contents n'ont qu'à monter leur propre réseau social (ou, de façon un tout petit peu moins irréaliste, n'ont qu'à aller sur Bluesky/Mastodon/quidlibet).

Je dis plus haut qu'un des buts du logiciel libre était d'éviter la situation où une personne peut, en pratique, priver une autre de telle ou telle fonctionnalité. J'ajouterais encore que le but était aussi de permettre aux programmes d'être configurables et de s'adapter aux besoins d'un maximum d'utilisateurs. (Or les fonctionnalités qu'on supprime sont souvent de l'ordre de la possibilité de configurer ceci ou cela : parce que la configurabilité, c'est difficile à maintenir, donc ça fournit un bon prétexte pour la supprimer.)

On peut me rétorquer (et on me l'a fait) que ceci ne fait pas du tout partie de la définition du logiciel libre (par exemple, les quatre libertés fondamentales selon Stallman sont celles d'exécuter, d'étudier et modifier, de redistribuer, et de redistribuer des copies modifiées). Il me semble que c'est rater la forêt pour les arbres : la définition du logiciel libre n'implique peut-être pas la configurabilité, mais le but du logiciel libre, si, parce que c'est bien de donner le pouvoir aux utilisateurs et pas aux seuls gardiens du code.

Et c'est bien le problème que je vois : on est passé de logiciel libre à open source. Sur le papier, ça veut dire presque la même chose. Mais le but n'est pas du tout le même. L'attention portée à ce que veulent les utilisateurs, y compris les minorités, a disparu (ou, dans la mesure où on fait attention à eux, le but est la massification, donc les intérêts standardisés, pas ceux qui veulent faire de la configuration, pas ceux qui veulent un truc minoritaire comme fvwm ou changer leurs bindings clavier). Les mainteneurs des gros projets open source ne sont souvent plus des hackers passionnés mais des salariés d'entreprises comme[#] Red Hat, Google, Oracle, Intel, AMD ou Microsoft, dont les décisions reflètent donc les intérêts des clients, dirigeants ou actionnaires de ces entreprises, pas le service à la communauté d'utilisateurs, et certainement pas aux gens comme moi. Il n'y a plus de différence sérieuse avec Windows ou Mac OS[#2].

[#] Le cas de Mozilla (qui est une fondation, pas une entreprise à but lucratif) est à part, et de fait, Mozilla est relativement peu enclin à supprimer gratuitement de la configurabilité ou des fonctionnalités utiles, même s'ils le font aussi : mais Mozilla commet l'erreur d'essayer de refaire dans Firefox, en plus mal, tout ce que fait Google dans Chrome, en oubliant que ses utilisateurs sont souvent justement des gens qui ne veulent pas de Chrome. Et de toute façon, Mozilla est en train de mourir, ce qui est un autre problème très sérieux pour l'écosystème Web (et dont il faudrait parler).

[#2] C'est en partie le fait de voir des gens paniquer devant la fin du support de Windows jenesaispascombien (et donc la nécessité de passer au suivant) qui m'inspire ces réflexions. Ceci étant, je crois comprendre que Windows a plus tendance à tirer un trait sur du support matériel que sur des fonctionnalités logicielles comme ce dont je me plains pour Linux.

En tout cas, que la cause en soit mon propre vieillissement ou le changement de l'orientation de la communauté autour de Linux, le fait est là : les mises à jour qui autrefois étaient pour moi un plaisir sont maintenant un cauchemar.

Zut, j'ai ranté, et zut, ça a encore été long (même si j'ai écrit ça très vite, pour le coup).