Il n'a ni expérience avec X11 (on ne casse pas une ABI ni API de plusieurs décennies sans nécessité, documentation ni transition planifiée) ni compétence en C.
Le dev qui a accepté ses contributions dans xserver a été bien trop optimiste. Un exemple où l'on a confondu la quantité avec la qualité.
Je ne suis pas aller plus loin. Dans l'état actuel, c'est pas sérieux.
Le temps nous dira si cela se stabilise.
Je suis convaincu que ce qui aurait le plus de valeur actuellement pour xserver serait d'écrire une suite de tests et de passer au crible le code avec les analyseurs des compilateurs, pour corriger tout problème de mémoire, comportement indéfini, etc.
Note qu’il est possible de faire du ménage sans rien casser. Enfin j’essaie chez moi 😅
j'ai l'impression que tout est fait pour que xorg soit abandonné
Ben… oui, c’est un projet abandonné, de fait. Pourquoi les gens s’étonnent encore ? Il n’y a que Enrico qui y met autant d’entrain, quand tous les devs sont passés à Wayland (je compte XWayland dedans). À la limite des CVE sont corrigées, de temps en temps. Xorg est en mode de maintenance minimale.
Cela ne veut pas dire que tous les utilisateurs·trices sont passées sous Wayland, bien sûr. Mais geler un projet obsolète pour se concentrer sur la techno actuelle, ça me paraît une utilisation très sensée des ressources (limitées). Il y a encore beaucoup de boulot sur Wayland, cependant les progrès ont été plus rapides ces derniers 12 mois.
Je n’entrerais pas dans le débat Wayland vs. X11. Wayland n’est pas la panacée. Aucune techno ne l’est.
Mais les faits sont là : X est une techno reconnue obsolète par ses propres développeurs. Cf. l’excellente vidéo de Daniel Stone à ce sujet : “The Real Story Behind Wayland and X” (assez amusante en plus).
Je trouve cet environnement de dev assez toxique en fait
Ce n’est pas mon impression en lisant les liens. J’y note surtout une énorme lassitude sur le manque de rigueur des contributions et le déni de l’abandon de X par certains contributeurs.
et il a bien fait de plier bagages.
Je pense aussi, les points de vue des intéressé·e·s sont irréconciliables. Mais cela ne va pas être facile. Je lui souhaite bon courage pour remplacer la fondation XOrg et prendre en charge le développement du monstre. Il est très courageux et motivé, alors pourquoi pas ? Ce sera l’occasion de voir à quel point X suscite encore de l’intérêt et, qui sait, contredire la direction qu’ont la grande majorité des environnements de bureau et des distributions Linux.
Ce qui est vraiment repproché c'est que l'ABI a été cassée sans necessité et que ses patchs se contentent de bouger du code avec d'énormes diff, sans corriger de bug ni apporter de nouvelles fonctionnalités. Son code est également peu ou pas testé.
Pour couronner le tout c'est un adepte des théories du complot.
Notez qu’il y a plusieurs autres dispositions de clavier qui permettent de saisir ce caractère directement : cf. cette galerie des dispositions clavier françaises (cherchez ensuite « … » dans la page).
Je viens de réaliser que ce serait peut-être plus simple de générer la doc à partir du code de test plutôt que l’inverse. C’est-à-dire utiliser l’approche programmation lettrée, où on mêlerait pure texte avec le langage de test plus formel, ce dernier étant ensuite remplacé par du texte à la génération de la doc ou exécuté quand on lance les tests. La différence avec l’approche présentée dans le billet est juste que le langage de test est clairement séparé et plus formel.
Dans un autre domaine, je me souviens de Catala pour les textes législatifs, vous connaissez ?
Très intéressant comme approche. Après question outillage cela dépend beaucoup du langage de programmation utilisé : pour ma part j'aime beaucoup l'approche d'une doc rédigée directement dans le code, avec des exemples qui sont testés pour 1) rester à jour avec le code 2) vérifier les propriétés attendues. La doc est ensuite générée pour avoir un manuel approprié et on peut tester la couverture du code testé et documenté.
Les véhicules légers (voitures particulières, 2 roues motorisés, véhicules utilitaires) concernés peuvent circuler le soir de 20h à 8h, les weekend et les jours fériés.
[^] # Re: Zero bug original corrigé mais de nouveaux bugs
Posté par DerVogel . En réponse au lien XLibre Xserver: Banned by Red Hat Developer Plans Revival of X11. Évalué à 2 (+2/-0).
Il n'a ni expérience avec X11 (on ne casse pas une ABI ni API de plusieurs décennies sans nécessité, documentation ni transition planifiée) ni compétence en C.
Le dev qui a accepté ses contributions dans xserver a été bien trop optimiste. Un exemple où l'on a confondu la quantité avec la qualité.
# Zero bug original corrigé mais de nouveaux bugs
Posté par DerVogel . En réponse au lien XLibre Xserver: Banned by Red Hat Developer Plans Revival of X11. Évalué à 8 (+8/-0).
Ils ont cassé le clavier.
Le contributeur le plus prolifique prétend corriger des failles de sécurité mais ne ne maîtrise pas les bases de C.
Je ne suis pas aller plus loin. Dans l'état actuel, c'est pas sérieux.
Le temps nous dira si cela se stabilise.
Je suis convaincu que ce qui aurait le plus de valeur actuellement pour xserver serait d'écrire une suite de tests et de passer au crible le code avec les analyseurs des compilateurs, pour corriger tout problème de mémoire, comportement indéfini, etc.
[^] # Re: Slogan
Posté par DerVogel . En réponse au lien XLibre Xserver: Banned by Red Hat Developer Plans Revival of X11. Évalué à 5 (+6/-1).
Note qu’il est possible de faire du ménage sans rien casser. Enfin j’essaie chez moi 😅
Ben… oui, c’est un projet abandonné, de fait. Pourquoi les gens s’étonnent encore ? Il n’y a que Enrico qui y met autant d’entrain, quand tous les devs sont passés à Wayland (je compte XWayland dedans). À la limite des CVE sont corrigées, de temps en temps. Xorg est en mode de maintenance minimale.
Cela ne veut pas dire que tous les utilisateurs·trices sont passées sous Wayland, bien sûr. Mais geler un projet obsolète pour se concentrer sur la techno actuelle, ça me paraît une utilisation très sensée des ressources (limitées). Il y a encore beaucoup de boulot sur Wayland, cependant les progrès ont été plus rapides ces derniers 12 mois.
Je n’entrerais pas dans le débat Wayland vs. X11. Wayland n’est pas la panacée. Aucune techno ne l’est.
Mais les faits sont là : X est une techno reconnue obsolète par ses propres développeurs. Cf. l’excellente vidéo de Daniel Stone à ce sujet : “The Real Story Behind Wayland and X” (assez amusante en plus).
Ce n’est pas mon impression en lisant les liens. J’y note surtout une énorme lassitude sur le manque de rigueur des contributions et le déni de l’abandon de X par certains contributeurs.
Je pense aussi, les points de vue des intéressé·e·s sont irréconciliables. Mais cela ne va pas être facile. Je lui souhaite bon courage pour remplacer la fondation XOrg et prendre en charge le développement du monstre. Il est très courageux et motivé, alors pourquoi pas ? Ce sera l’occasion de voir à quel point X suscite encore de l’intérêt et, qui sait, contredire la direction qu’ont la grande majorité des environnements de bureau et des distributions Linux.
[^] # Re: Slogan
Posté par DerVogel . En réponse au lien XLibre Xserver: Banned by Red Hat Developer Plans Revival of X11. Évalué à 7 (+8/-1).
Ce qui est vraiment repproché c'est que l'ABI a été cassée sans necessité et que ses patchs se contentent de bouger du code avec d'énormes diff, sans corriger de bug ni apporter de nouvelles fonctionnalités. Son code est également peu ou pas testé.
Pour couronner le tout c'est un adepte des théories du complot.
[^] # Re: …
Posté par DerVogel . En réponse au journal Des points et des points de code. Évalué à 2.
Notez qu’il y a plusieurs autres dispositions de clavier qui permettent de saisir ce caractère directement : cf. cette galerie des dispositions clavier françaises (cherchez ensuite « … » dans la page).
Notamment :
- Bépo
- Ergo-L
- Le nouvel Azerty (Afnor)
# Et l’approche inverse ?
Posté par DerVogel . En réponse au journal Documenter ou tester, il faut trancher (j'ai pas trouvé de rime avec choisir...). Évalué à 2.
Je viens de réaliser que ce serait peut-être plus simple de générer la doc à partir du code de test plutôt que l’inverse. C’est-à-dire utiliser l’approche programmation lettrée, où on mêlerait pure texte avec le langage de test plus formel, ce dernier étant ensuite remplacé par du texte à la génération de la doc ou exécuté quand on lance les tests. La différence avec l’approche présentée dans le billet est juste que le langage de test est clairement séparé et plus formel.
Dans un autre domaine, je me souviens de Catala pour les textes législatifs, vous connaissez ?
# Très intéressant commme approche
Posté par DerVogel . En réponse au journal Documenter ou tester, il faut trancher (j'ai pas trouvé de rime avec choisir...). Évalué à 2. Dernière modification le 06 février 2025 à 06:10.
Très intéressant comme approche. Après question outillage cela dépend beaucoup du langage de programmation utilisé : pour ma part j'aime beaucoup l'approche d'une doc rédigée directement dans le code, avec des exemples qui sont testés pour 1) rester à jour avec le code 2) vérifier les propriétés attendues. La doc est ensuite générée pour avoir un manuel approprié et on peut tester la couverture du code testé et documenté.
Pour Haskell, il y ainsi doctest, très pratique.
[^] # Re: ferié
Posté par DerVogel . En réponse au journal ZFE, merdouilles ,et firefox. Évalué à 6.
Bien vu, ça a l'air le cas :
https://www.metropolegrandparis.fr/fr/la-zone-faibles-emissions-metropolitaine