Comments on Quand l'informatique libre a-t-elle arrêté de progresser ?

Je sais faire sous xmodmap des choses que je ne sais pas faire sous son remplaçant.

Wayland cassera-t-il w3m-img?

Il y a une tendance que tu n'as pas vraiment mentionnée et qui rajoute encore à la chienlit : les développeurs de logiciels, lorsqu'ils y rajoutent des fonctionnalités, le font avec grande flemme, et donc une partie de la nouvelle fonctionnalité utilise une bibliothèque tierce qui n'était pas nécessaire auparavant.

Cette dépendance est obligatoire, c'est-à-dire que si la dépendance n'est pas présente, au lieu d'avoir un logiciel dont la fonctionnalité supplémentaire est désactivée, on a un logiciel qui refuse de fonctionner.

Ce qui fait que dans une distribution moderne, au lieu d'avoir peu de dépendances et de pouvoir supprimer ce dont on ne veut pas se servir, on a un plat de spaghettis indigestes qu'il faut avaler tout rond.

vraiment pas besoin de publier ce commentaire sous le blog (ce serait bizarre), c'était juste pour signaler que la phrase "Je ne comprends rien à la page de doc que je viens de lier" devrait peut-être plutôt lire "lire" au lieu de "lier"

Merci pour ce post, qui résonne avec ma propre expérience, et avec ce constat qu'il faut des machines de plus en plus puissantes et des logiciels de plus en plus gourmands pour des tâches simples qui ne les requièrent pas. Ainsi les applications sur les téléphones portables, qui ne sont que des pages web améliorées (voire…) et qui pèsent des centaines de Mio.
En même temps j'aime le mot anglais "deprecated"… Le sens est bien traduit par "devenu obsolète" mais on perd un peu de sa musique…
Et puis bien sûr, cela me fait penser à la part de plus en plus importante dans nos vies de l'intelligence artificielle, alors qu'on avait mis en place plein de bidouillages plaisants et utiles avec notre intelligence naturelle…
"The plugin is now deprecated, and users need to find alternatives."

@fakbill : tu as mal compris mon propos
Je suis à 200% pour les mises à jour. La maintenance d'une application - dont les mises à jour font partie - est une tâche nécessaire et indispensable au maintien en condition opérationnel de l'application.
J'indiquais juste les bonnes pratiques du monde informatique professionnel.
Pour faire simple : Si une mise à jour n'apporte que des nouvelles fonctionnalités, on regarde si on en besoin, on teste si nécessaire. Bref on n'applique pas aveuglément.
Pour les mises à jour permettant de rester sous la maintenance ou les patches de sécurité, on teste avant quand même (certains patches de sécurité amènent de nouvelles fonctions) et si ok (majorité des cas), on applique.
La seule exception est les patches 0day que l'on applique le plus rapidement à cause de la vulnérabilité.

Ça fait longtemps que j'ai renoncé à customiser mon environnement informatique. Aujourd'hui, j'essaye d'utiliser les outils standards au maximum et de ne pas aller à contre courant.

ScanX77 : Supposer que le monde ne va pas changer est le meilleur moyen de finir avec
1) un truc qui ne marchera plus
2) un truc qui sera très compliqué, pour ne pas dire impossible, à sauver.
Deux solutions : soit on vit avec et "après moi le déluge", soit on investit dans des mises à jour progressives.

Si vous êtes allergiques au changement, allez faire un pèlerinage ici : https://www.aconit.org/spip/

2 autres pratiques en industrie:
- la lecture du fichier "Release Notes" pour regarder si les mises sont vraiment nécessaires (et ne les appliquer que si besoin)
- la validation en amont dans un environnement de test

J'ai pas l'impression que ce soit un problème de l'informatique libre. Je dis ça en tant qu'utilisateur Windows qui a le même ressenti. Un exemple débile : la barre des tâches et le panneau de configuration sont progressivement dépréciés au profit de leurs équivalents modernes disposant de moins de fonctionnalités et d'ergonomie. Heureusement, la majorité des logiciels anciens fonctionnent encore, bien que les jeux vidéos aient rarement des problèmes.

Mon avis est que toute l'informatique est touchée en général, pour des raisons structurelles. L'informatique est devenue mature, mais doit quand même se trimballer la rétro-compatibilité avec l'ancien monde, la transition ne peut pas se faire sans casse. Surtout que les logiciels, libre ou non, ont tous des dépendances avec d'autres logiciels, des librairies, des OS, qui évoluent dans le temps pour X raisons. Vu que tout est indépendant, on ne peut pas figer un logiciel dans le marbre si tout autour évolue, pas le choix. Il suffit qu'un projet libre prenne du décision pour que ça en impacte un paquet d'autres, et que ca se répercute ailleurs, etc.

Et notons que paradoxalement, l'informatique actuelle a paradoxalement le pire des deux mondes : dans certains cas la compatibilité avec l'ancien est cassée de partout, dans d'autres cas les projets existants ont une inertie de fou. Un exemple débile : les dramas autour de Rust dans le noyau linux : ça pourrait donner des trucs vraiment intéressant, mais non, ca coince pour des raisons à la pertinence très variable.

Pour ALSA vs Pulse Audio, il y a quand même pas mal de nouvelles fonctionnalités qui viennent avec et qui sont utiles comme par exemple le niveau de volume par application, la possibilité de choisir par application le périphérique à utiliser et la gestion du Bluetooth. ALSA, ça marchait bien quand tu n'avais qu'une seule carte son qui savait faire le mixing hardware.

Ce que tu décris est un vrai problème en entreprise où le maintien en condition opérationnel du code "maison" coûte du temps/homme.
C'est pour cette raison que l'utilisation des versions LTS ou ESR des OS/applications est préférée afin d'avoir une certaine stabilité dans le temps.

Exemple:
Firefox ESR <URL: https://www.firefox.com/fr/browsers/enterprise/ >
Ubuntu LTS <URL: https://doc.ubuntu-fr.org/lts/ >
Debian LTS <URL: https://wiki.debian.org/fr/LTS/ > (voire Extented LTS <URL: https://wiki.debian.org/LTS/Extended/ >)
Plus d'informations sur Wikipedia <URL: https://en.wikipedia.org/wiki/Long-term_support >

Bon ça ne fait que retarder le problème mais en attendant ça te donne du temps pour continuer à travailler et te permettre les corrections.

@yogsototh

> Personnellement, j'aspirerais à un Linux produit avec la même philosophie que TeX. Essayer de construire les outils et les finir une bonne fois pour toute. Dans l'idéal, uniquement produire des mise à jour de sécurité, mais rien d'autre. Je ne pense pas qu'un tel projet existe. Le plus proche étant probablement Debian Stable.

Bien que ce ne soit pas Linux, la description me fait surtout penser à FreeBSD. Pour l'environnement de bureau, il y a des options beaucoup plus conservatrices que GNOME, comme MATE.

Il y a de l'obsolescence programmée, et certains projets sont particulièrement coupables. Notons, par exemple, gnome, qui a déprécié gtk+2 avant la sortie de gimp-3… un bug débile dans leur file-requester n'a pas eu de fix officiel, car gtk+2 était end-of-life, alors qu'il affectait gimp-2.

Et actuellement, je subis des pressions (légères) de mes co-dev Open pour virer gimp-2, car c'est un des rares outils qui a encore besoin de python-2. Chiendent: il manque une bonne partie des plugins que j'utilise dans gimp qu'il faut porter sur du gimp-3 (et dans certains cas entièrement réécrire vu que l'interface scheme a viré).

Pour wayland, il y a quelques "avantages" promis:
- le premier c'est de se débarrasser d'un protocole réseau vieillissant complexe. Note que c'est pas nouveau, le boulot de Dave Packard sur les polices client-side dans X11 en faisait déjà partie. Donc ça va marginalement plus vite et c'est censé être moins complexe à programmer.
- le second c'est en termes de sécurité, vu qu'il isole chaque fenêtre de ses voisines, ce qui évite que ton navigateur puisse voir ce qui se passe dans ton xterm… problème théorique surtout.
- le dernier, c'est en termes de stabilité. Mais là on est au royaume des shadocks. Avec de plus en plus de distrib linux sous wayland, les drivers accélérés sont bien moins testés sous X11, et donc ne marchent plus très bien. Note que là-aussi c'est pas nouveau, je me souviens avoir du rajouter xcompmgr dans ma config X11 car chromium ne gérait plus correctement les expose events…

C'est pourquoi avec l'age j'apprécie de plus en plus de travailler avec Clojure.
La philosophie est très conservatrice, l'auteur de Clojure a plusieurs fois expliqué que lorsqu'on produit de l'open source ou du FOSS, il n'est plus totalement a vous. Et c'est un manque de respect de casser quelque chose.

Certain environnement aident plus que d'autres. Par exemple dans la communauté d'Haskell, tout casse très souvent, parce qu'il est difficile de prévoir les bons types qui accueilleront une optimisation. Je me souviens encore avec horreur d'une "upgrade" du type nécessaire pour faire des midllewarxe d'un appli web. Le type "intuitif" est "(Request -> IO Response) -> (Request -> IO Response)" et il a été transformé en (actuellement en dernière version) " Application -> Application" où Application est devenu "Request -> (Response -> IO ResponseReceived) -> IO ResponseReceived)".

Ce n'est qu'un exemple parmi d'autres. Mais certains environnement favorisent de casser les choses. J'ai aussi l'impression terrible que plus personne ne cherche à finir un système. Il faut que tout se déroule comme une série de petites histoires, un travail incrémental qui s'étendrait à l'infini. Pire, la plupart des upgrades ont un goût de downgrade. J'ai vu ça avec Swagger UI entre les différentes version. La v3 produit plus de "nouvelles features" mais il faut payer un coût, l'UX est plus lourde, l'UI moins jolie. Un peu pareil avec kibana et chaque version successive.

Il existe peut-être des projets qui comme TeX sont fini. Mais une fois fini, on ne fait plus les news, et ces projets tombent probablement dans l'oubli.

Personnellement, j'aspirerais à un Linux produit avec la même philosophie que TeX. Essayer de construire les outils et les finir une bonne fois pour toute. Dans l'idéal, uniquement produire des mise à jour de sécurité, mais rien d'autre. Je ne pense pas qu'un tel projet existe. Le plus proche étant probablement Debian Stable.

> 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.

Ça a un nom que j'ai déjà lu quelque part mais que j'ai oublié, quelque chose comme "software development driven by hordes of pimply-faced teenagers" qui manquent d'expérience pour apprécier les avantages de la vieille roue et imposent la nouvelle parce qu'elle a plein de DEL de couleur collées dessus.

https://www.reddit.com/r/enshittification/

> je pense deviner que si on soumet un patch qui annule simplement la modification supprimant une fonctionnalité, ce ne sera pas accepté

A-t-on essayé ?

> et d'ailleurs, personne n'a été capable de me dire l'équivalent Wayland de xset s reset

systemd-inhibit ?