Comments on Pourquoi l'écosystème Linux est un puzzle (et ce qu'on peut y faire)

Et encore, quand on arrive à un tant soit peu consolider les choses, les gens se plaignent. Ça me fait penser à ce que j'ai récemment lu sur systemd (<URL: https://blog.darknedgy.net/technology/2020/05/02/0/index.html>): un tas d'init systems différents et tous avec leurs problèmes disjoints ; vient enfin la convergence vers une solution pour l'écrasante majorité des distros, mais quelques réfractaires demandent encore à entretenir des scripts init à la OpenRC. Systemd est présent depuis plus de 15 ans, et des environnements de bureau comme KDE sont encore obligés de se défendre de l'utiliser: <URL: https://old.reddit.com/r/kde/comments/1r68jmi/a_quick_antifud_faq_to_debunk_the_kde_is_forcing/>

Cela dit, je pense qu'une certaine consolidation tend à venir, et que systemd sera aussi essentiel que coreutils. Et j'espère que des approches comme FreeDesktop vont aider à une meilleure interoptabilité :/

Pour une fois qu'on est d'accord sur un sujet informatique, ça mérite d'être signalé 😃

Je pense que ce billet est généralisable à tout artisanat, ou plutôt à tout art : il existe tant de manières de faire, tant de manières de penser comment bien faire, que je pense illusoire de jamais trouver vraiment chaussure à son pied. En y réfléchissant un peu plus, j'étendrais même cette observation au vivant : un grand bricolage tel que le plus étonnant est que « ça marche ! ».

Ah, la gestion du clavier… C'est en fait la raison principale pour laquelle je suis très réticent à mettre à jour mon installation Linux: j'ai toujours peur que la nouvelle version casse la configuration fonctionnelle que j'ai réussi à obtenir mais dont je ne comprends pas pourquoi elle fonctionne, et chaque fois que j'essaie, ça se transforme en nouvelle de Lovecraft et j'abandonne avant que mon cerveau se liquéfie.

J'aime bien les aphorismes de Perlis, ils n'ont pas tous bien vieilli mais certains conservent une applicabilité suprenante.
(Je présume que c'est un bonus de leur côté sybillin et très général qui leur permet de survivre au contexte maintenant très ancien qui leur a donné naissance)

« Every program is a part of some other program and rarely fits. »

Merci encore pour vos partages, c'est toujours un plaisir à lire.

Si "le sujet mériterait pourtant un traitement beaucoup plus long et approfondi", pourquoi s'en priver ?

En fait, on dirait que vous êtes face au choix suivant : ou bien traiter de davantage de sujets de manière plus concise (moins de temps par billet = davantage de billets), ou bien pas (c.-à-d. faire des billets très longs, quitte à ce qu'il y en ait moins).

Le constat actuel est que : 1. Vous vous êtes pendant longtemps laissé une liberté pour écrire de très longs billets, et 2. Petit à petit, vous avez commencé à vous dire qu'il faudrait arrêter, pour laisser place à des billets plus courts (et potentiellement plus fréquents).

S'il est vrai qu'il est dommage que certains sujets passent à la trappe car trop de temps a été passé sur un autre, on peut se dire qu'il n'y a cependant en soi pas forcément de raison fondamentale nécessairement toujours préférer 2. à 1.
Pour certains sujets, cela peut-être tout à fait une bonne chose de laisser la conscience et ses pensées jusqu'au bout, cela peut donner lieu à des idées intéressantes.

L'optimum consiste probablement à se poser la question, en entamant le sujet, jusqu'à quel point peut-ce être une bonne idée de continuer d'écrire. Une stratégie adaptative est probablement plus proche du ratio optimal entre temps passé (longueur de billet) et quantité écrite, que celle consistant à borner systématiquement et à contraindre sa pensée.

J'aurais peut-être du commencer par là, mais pour les lecteurs, c'est aussi un peu frustrant quand on voit un sujet qui nous intéresse beaucoup commencer par "pour information, ça aurait pu être beaucoup plus long (et donc intéressant). Mais ça ne l'est pas". Hahaha

Dès le début du billet, j'ai pensé aux méthodes de saisie, donc je suis content que tu en parles. Je suis d'accord avec l'ensemble du billet, mais c'est l'exemple qui m'affecte le plus au quotidien (j'utilise aussi un clavier US-international, et j'écris en chinois et parfois un peu de japonais ou coréen).

Il faut tout d'abord choisir un framework, il y a en effet Scim et Ibus, mais aussi Fcitx, qui en est à la version 5 mais certains sont resté sur la version 4, plus bien sûr d'autres plus obscurs

Il faut ensuite choisir la méthode de saisie elle-même, et là que ce soit pour le chinois ou le japonais il y en a beaucoup.

Enfin il faut réussir à faire fonctionner tout ça à l'intérieur des autres programmes, et ça ça change entre les programmes GTk, les programmes Qt, les autres programmes (toutes les joyeusetés de GTK_IM_MODULE, QT_IM_MODULE, XMODIFIERS, etc.)

J'ai parfois réussi à faire fonctionner le tout, mais cela donne l'impression d'être très fragile, c'est la partie du système qui casse le plus souvent sans raison lors d'une mise à jour mineure, sans avoir de moyen de savoir ce qui ne va pas.