freem a écrit 4965 commentaires

Et là, je n'ai aucune idée de comment faire ni si une telle solution existe déjà.

Hum… je dirais:

1. créer un dossier temporaire (si tu mets le noms en fonction de l'horodatage, ça devrait le faire)
2. copier les sources vers ledit dossier
3. s'y déplacer
4. compiler
5. déplacer le résultat à l'endroit souhaité.

Je serai volontiers plus précis, mais je ne sais pas quels outils tu compiles, et il est même possible que certaines étapes soient inutiles en fonction du CMS (on pourrait imaginer un CMS qui supporte une interface en ligne de commande, et du coup pas mal d'étapes seraient inutiles).

Un filtre latex->html qui fonctionne bien, a priori, je ne connais que pandoc.

Ça en fait déjà un :) j'admets n'avoir jamais essayé.

il faut dire que c'était à une période antédiluvienne ou tout se passait en ligne de commandes avec des instructions aussi alambiquées que hasardeuses …

Mon secret: l'utilisation d'une interface interactive nommée aptitude. Bien qu'il soit foutrement lent à faire le moindre truc (je suis manifestement relativement jeune, et donc impatient :)) quand une cassure est détectée, les choses restent simples à condition d'avoir aux paquets auxquels ont veut revenir.

Bon, j'imagine qu'avoir des notions de quels paquets servent à quoi aide, mais c'est en général assez explicite.

Vous faites bien d'utiliser "purge" car on se retrouve parfois avec un nombre impressionnant de fichiers ne servant plus à rien.

Le pire étant que la purge ne résout pas tout: certains fichiers ou répertoires sont générés par le logiciel, et non par le script d'installation, et ne seront donc pas nettoyés par une purge.
Mais les mainteneurs de Debian sont assez sérieux de ce côté là.

(mais jamais sans vous être assuré que vous n'avez pas gardé volontairement un vieux fichier obsolète que vous vouliez reprendre pour le remanier, …je sais de quoi je parle! Étourdi!)

Dans ces cas la, je préfère faire une copie en .bak, ça évite les ennuis :)

non, mais y a besoin de faire le taf pour que l'avis compte.

Suis d'accord. Mais dans ce cas, 90% des avis, pro ou anti, sont inutiles :)

Bien sur, mais au final, ceux qui font le boulot décident.

C'est bien pour ça que, malgré que je ne sois pas d'accord avec Debian (parce que mes besoins actuels ne collent pas à leurs objectifs) je respecte profondément cette distribution et le boulot de ceux qui la font vivre.
franchement, Devuan, j'ai été sérieusement agacé par leur 1er «nom» (debian-fork, ou un truc à la con du style) et leur argumentaire de base. Le fork était peut-être utile et bon, mais de forker sur un troll, ça ne peut pas attirer les gens, fatalement.

Ses scripts de lancement doivent rester en premier plan, contrairement aux lancements de démons qu'on trouvent dans /etc/init.d/.

Je sais, oui. Ceci dit, quand on fait une migration, il est quand même utile de pouvoir le faire au fur et à mesure, et c'est d'ailleurs l'impression qui ressort de ce document

For those services that are not migrated to use run scripts yet, add the corresponding init-script startup to /etc/runit/1

Je me trompe? D'ailleurs, pas mal de bordel dans /etc/init.d/ n'a pas vocation à resté lancé (initialisation des partoches/réseau, notamment).

Merci de ne pas déformer mes propos. Je disais que pour Runit les scripts shell ne suivaient pas la norme de SysVinit. Je n'ai pas comparé avec systemd et son format de configuration.

Tu as, bien sûr, noté le smiley?

Mais si tu viens sur ce terrain, alors parlons de la magnifique norme pour lancer un démon avec SysVinit : chacun se démerde comme il peut avec son shell et les outils du bord.

Yep, sysVinit, c'est le pire qui existe à ma connaissance.

Aptitude est simple dans le sens ou il n'est pas obligatoire de connaître le paquet que tu veux installer: c'est l'avantage des programmes interactifs (personnellement, je considère qu'aptitude n'a aucun intérêt en mode commande).

Au niveau de la souplesse, c'est justement qu'il est (relativement) simple de visualiser pourquoi tel ou tel paquet sera installé.

Je n'ai quasiment jamais eu de problèmes avec les scripts d'installation, et c'était toujours sur du testing/unstable/experimental.

Bon, pour le coup, j'ai jeté un œil aux screenshot de pacman que l'on peut trouver sur le web. Désolé, mais c'est à la ramasse comparé à aptitude.
Pas de couleur, et juste une liste d'états? Ouch.
Accessoirement, j'ai déjà essayé archlinux. Je ne le referai pas, pas quand il était impossible d'installer Xorg à cause d'une dépendance cassée. Je ne crois pas être fait pour le rolling release pur et dur, en fait.

Pour le coup, joli troll, je marche dedans (bon certes, «un peu» en retard, mais je suis moins à mouler qu'avant, mea culpa) :)

Je te conseille le grymoire pour les questions syntaxiques sur le shell.
Bon, ok, c'est en anglais, mais c'est jusqu'à présent le meilleur que je connaisse pour acquérir les bases sur pas mal d'outils unix (et des bases qui dépassent de loin celles que mes profs m'ont inculquées xD mais il part vraiment du début et c'est truffé d'exemples, c'est vraiment un site que je qualifierai de référence).
Tu y apprendras pas mal d'astuces qui te simplifieront la vie en plus des réponses à tes questions, pour une lecture de quelques heures (juste pour le shell, 2 ou 3 peut-être, en fonction de ton niveau actuel bien sûr.) ça vaut le coup.

Perso, je dirais qu'un dépôt git pour du code LaTeX, avec un hook qui compile à chaque à chaque push le code LaTeX en HTML devrait pouvoir répondre au plus gros des tes problèmes.

La seule chose qu'il te resterait ensuite à faire, c'est de trouver un CMS qui supporte d'avoir les posts en HTML. Je suppose que ce n'est pas trop complexe, mais ce n'est que supposition (jamais cherché).
Enfin, je dis HTML, mais LaTeX supporte peut-être d'autres formats utilisés sur la toile en sortie (un des nombreux formats de wiki, ou des trucs de forums, que sais-je?).

Pour le coup, avec git+LaTeX, en bricolant un hook, tu réponds déjà aux points 1 à 8, c'est à dire tous les points relatifs à la présentation des données. Les autres points, je ne doute pas que la plupart des moteurs de blogs en sont capables. En gros, l'idéal serait que tu cherches un CMS qui supporte une interface shell, histoire de compléter le hook parfaitement.

Cette réponse n'apporte pas grand chose, je sais, je voulais juste dire qu'à mon avis tu cherches trop de choses et que tu peux réduire ta recherche.

Il y a besoin d'être mainteneur pour avoir un avis sur systemd? Tout le monde peut avoir un avis, mainteneur ou non. Et donc, tout le monde peut être pro, anti, ou entre les deux.

Enfin, je suis d'accord que les discours autour de systemd virent souvent à l'extrême.
J'ai arrêté de suivre la ml de debian à cause de ça et de certains débordements (tant des utilisateurs que des modérateurs) que j'ai constatés (et non, je n'irai pas exhumer des preuves, ça fait longtemps que je n'en ai plus rien à foutre).
Par contre, je ne crois pas que seuls les anti mènent les «débats» dans la direction des décharges. Pour ma part, j'ai vu pas mal de débats constructifs être pourri par les deux camps extrêmes, ce qui est dommage, parce que j'ai aussi vu des avis constructifs tant des pro que des antis.

Exact, et c'est assez simple: il suffit d'aller dans la description du paquet, d'aller tout en bas et de prendre la version de son choix.

Sauf qu'en fait, il y à deux problèmes:

1. Une version bugguée peut avoir introduit un bug dans la configuration, qui ne sera pas nécessairement nettoyé (si le fichier à été généré particulièrement) par une downgrade.
2. Les seules versions affichées par aptitude sont les versions actuellement diffusées par les dépôts dans /etc/apt/sources.list(.d). Hors, quand tu fais une MàJ de stable vers stable (correctif de sécurité principalement) l'ancien paquet tombe dans l'oubli. Le seul moyen que je connaisse pour le récupérer, c'est le dossier que j'ai cité dans mon autre post. Et encore, problème: cette archive qu'aptitude construit, tu peux régler aptitude pour "supprimer automatiquement les paquets obsolètes" (ceux qui ne sont plus listés). Si tu fais ça, t'es bon pour aller faire de l'archéologie. Le fait de ne pas pouvoir indiquer combien de versions de backup conserver avec aptitude est l'un de ses inconvénients (mais c'est toujours mieux que les autres outils qui ne proposent même pas ce nettoyage automatique, sachant que quleques MàJ de gros paquets peuvent vite bouffer inutilement plusieurs Go).

99% Compatible virus.

Stats Zenitram, la majorité des gens qui critiquent systemd se défoulent pour le plaisir (ça a l'air de faire du bien) et continue d'utiliser leur distro (avec systemd donc).

Stats Freem, la majorité des gens qui critiquent systemd lui font une critique positive. Ça à l'air de faire du bien :D

T'inquiètes pas, Lennart nous sauvera bien à un moment donné…

Ce que ne comprennent pas les "anti-systemd", c'est qu'en face il n'y a pas de "pro-systemd"

.

des mainteneurs, qui eux […] on trouvé la chose utile

C'est contradictoire, non? Être "pro-whatever", c'est bien être en faveur de whatever? Si on trouve une chose assez utile pour en remplacer une autre, c'est bien que l'on est en faveur de la première, sans obligatoirement considérer que la seconde est absolument mauvaise?

Pour le reste… il n'y a pas que des extrémistes et des aveugles dans la discussion, ce n'est pas parce que l'on n'apprécie pas systemd qu'on le déteste, et j'ose espérer que ce n'est pas parce qu'on l'apprécie que l'on doit jouer les zélotes.

D'abord, il faut rappeler que runit ne suit pas la norme SysVinit. Donc il faut se coltiner l'écriture de scripts en shell pour piloter le démarrage des services, en remplacement de ceux écrits dans /etc/init.d/.

Hum… sysVinit, il ne fait que lancer des services, il ne les gère pas. Il le faut au travers de scripts shell. Alors tout ce qui gère les services, sors forcément de la «norme» sysVinit.
Runit, il lance des services, et il les gère. Au travers de scripts shell.

Le langage shell utilisé est le même pour les deux cas. Du coup, je ne vois pas trop comment runit ferait moins bien que sysVinit?
Je reconnais n'avoir pas essayé, mais, ça ne marche pas de lancer les scripts de /etc/init.d par runit?

Et le coup de la norme sysVinit pas respectée, ça ne prend pas.
Oui, systemd peut lancer des scripts sysVinit (comme runit, j'en suis persuadé), mais il ne respecte pas non plus celle-ci. Donc il faut se «coltiner» (ton terme) l'écriture de fichiers de config avec la syntaxe de systemd .
Maintenant, je trouve que le shell à une syntaxe de merde (et des mots-clé à la con, genre fi et esac, par contre pas de rof ni de elihw? Mots clé à la con, et même pas consistants! Je ne parlerai pas de test, à chaque fois que je m'en sers, je sors le man!), est bourré de chausses-trappes et à pleins d'autres inconvénients (me semble plusieurs de ces inconvénients on causé la naissance de perl, d'ailleurs).
Mais pas obligé de connaître le shell pour écrire des scripts runit, rien n'empêche d'utiliser python par exemple (j'en ai vu un exemple sur github, il y a quelques jours).
D'un autre côté, systemd «impose» un langage, plus simple qu'un langage de programmation. Par contre, il s'agit d'une technologie spécifique, qui ne servira que pour systemd.

Du coup, vraiment, l'argument de la norme en faveur de systemd et contre runit il est pas terrible :)
D'ailleurs, le coup d'utiliser un autre langage pour écrire les scripts d'init, pourquoi ne pas l'avoir utilisé pour sysVinit? Je viens de réaliser que je n'ai pas souvenir d'avoir lu quoique ce soit à ce sujet? Ça aurait sûrement pu simplifier énormément les usines à gaz.

Par contre, je me suis retrouvé avec le problème inverse : il fallait que les services soit lancés en premier plan, sans forker en tâche de fond.

Oui, c'est le problème, le service doit avoir un moyen de ne pas utiliser le double fork. Qui ressemble quand même pas mal à un workaround, pour moi (traditionnel, certes, mais workaround quand même).

Par exemple, je lançais autant que possible les processus avec des utilisateurs différents, pour des raisons de sécurité. Avec Runit, soit il faut activer un mécanisme global de déclaration dans les répertoires des utilisateurs, soit il faut jouer avec su dans les scripts shell des services.

Ou utiliser le programme chpst fourni par runit? Cet outil est vraiment très intéressant, il permets notamment de:

• changer l'utilisateur
• les groupes du processus
• les variables d'environnement (bien apprécié ça, récemment) en définissant un dossier dont chaque fichier/contenu est une variable/valeur
• créer un fichier de verrouillage. Peut-être que ça aurait pu résoudre ton problème de fichier PID manquant? (je viens de l'apprendre, cette option, j'ai ouvert le man par curiosité)

Par contre, je ne sais pas s'il y a un workaround contre les programmes qui exigent de forker. À part les forker eux, pour faire sauter le double fork et recompiler, bien sûr :D

Quant à la vitesse, oui runit est rapide, mais je doute qu'il le soit plus que systemd, notamment parce qu'il lance un nouveau shell pour chaque service.

C'est vrai, le lancement d'un shell est lent. Celui qui lance des bash à chaque fois dois prendre bien cher… d'un autre côté, celui qui lance juste busybox-static, ça doit être raisonnable, niveau coût.
Par contre, je ne sais pas du tout comment systemd marche, de ce côté la. C'est un binaire séparé de l'init qui lit la config?

(hélas peu documenté)

C'est vrai, la documentation tiens sur peu de place. D'un autre côté, je n'ai pas l'impression qu'il y ait besoin de plus. Après tout, runit délègue au système la plupart de ses actions. Alors que systemd c'est plutôt le contraire, il prend les prérogatives du système pour la plupart des actions du systèmes :)

il n'y a pas une grosse communauté autour de runit (admirez la litote ;-).

Oui, je pense que c'est une des raisons qui fait qu'il n'est pas utilisé plus que ça.

à mon avis il n'a pas la carrure pour être le gestionnaire de démarrage d'une grande distribution.

Probablement. Le point le plus noir étant probablement sa communauté trop réduite. Du coup, effectivement, peu de scripts sont fournis, et soyons honnêtes, ceux du site officiel semblent un peu obsolètes.
Je ne pense pas que runit vise à gérer le démarrage d'une grande distribution. Pour moi, il est plus adapté à des distributions qui cherchent à laisser le contrôle à l'utilisateur. Ne serait-ce que par la quasi absence de comportement par défaut.

Surtout que l'auto-complétion pour les chemins de zsh est bien sympa (pas besoin de mitrailler les tab, on take 1 lettre, 1 slash, 1 lettre… et à la fin, ). La seule chose que j'aimerai, c'est qu'il arrête de faire défiler les résultats quand il y a plusieurs choix, mais plutôt tape le maximum et s'arrête au moment ou il ne sait plus, comme le fait bash. Doit être possible, j'ai juste pas cherché comment faire (pareil pour vim d'ailleurs).

Quelle utilisation vais je faire de mon ordinateur ?

Très vrai.

Je pense donc pouvoir vous dire que Debian est vraiment stable si vous utilisez Stable

Vrai aussi, la réputation de Debian n'est pas usurpée. Je me suis amusé avec ma machine personnelle, à plusieurs mois d'intervalle, de passer de stable à testing, de testing à unstable/experimental, en passant par des sessions de jeu sur /etc/apt/preferences puis à revenir à stable. Le retour à stable est une manipulation longue (résoudre les conflits à la main dans aptitude, c'est long et fastidieux) mais simple.

J'ai aussi traîné mes octets sur la ml pendant un temps, et cette question revenais assez souvent (stable vs testing vs unstable).
En général, ce qui était conseillé pour les serveurs, c'était soit stable, soit unstable. Pas testing, parce que les correctifs de sécurité mettent (mettaient, je crois que ça a changé) trop de temps à descendre.

Pour le bureau…
Pas vraiment de consensus.

Mon avis est moi, c'est que pour ne pas être embêté, le mieux c'est stable + backports, avec éventuellement les dépôts source de testing/unstable enregistrés.
Comme ça, on peut avoir un système au cœur stable (Xorg, kernel, terminal), accompagné de logiciels «finaux» plus récents (browser, gestionnaire de fenêtres…).
Et si vraiment il faut à tout prix un truc dernier cri, alors on peu utiliser un paquet source plus récent et recompiler. Ça demande plus de travail, et ça ne se mets pas à jour tout seul, mais ça à le mérite d'éviter de casser le système.

Et si jamais un truc pète à cause d'une MàJ (sait-on jamais), par défaut, les anciens paquets sont conservés dans /var/cache/apt/archives.
Il suffit donc de purger le paquet incriminé (pas supprimer ni réinstaller: purger. Ça nettoie la config système au passage), puis d'aller installer à coup de dpkg la version voulue présente dans le répertoire sus-cité.

C'est plus rapide pour les aller-retour.

Je pense que ceux qui ne sont pas 100% pour systemd ont juste lâché l'affaire. Ils utilisent autre chose, et basta.
Perso, quand je vois un article qui va clairement faire l'apologie de systemd, en général, je me contente des 10-20 1ères lignes et je passe à autre chose. Je peux limite deviner le reste sans le lire.

Les débats autour de systemd que j'ai lu ont toujours été menés à charge contre sysVinit (et la plupart des arguments étaient fondés) mais pas en montrant en quoi systemd était le meilleur (de tous les init).

Maintenant, parmi les opposants à systemd, certains faisaient de la résistance au changement (genre ceux qui défendaient les scripts de sysVinit…), mais pas tous. D'autres disaient qu'il existe des alternatives, aussi bien voire mieux en terme de maintenance (daemontools/runit étaient régulièrement cités, et je n'ai souvenir d'aucun argument contre eux, étrange… au lieu de ça, la discussion re-déviait sur une attaque à sysVinit qui démontrait combien le bash ne conviens pas pour les scripts d'init, comme si sysVinit en faisait le meilleur usage…).
N'étant pas fan de systemd, et encore moins de sysVinit, j'ai un peu suivi certaines de ces alternatives et lu quelques articles (pas de grands livres rentrant dans les détails, des articles relativement courts, pas plus de 2 pages A4) s'y relatant (donc mon opinion est clairement partielle).

• sysVinit, j'avais eu l'occase d'essayer de faire un service… Tout est dit.
• openrc, je n'en ai pas vu l'intérêt. Je ne l'ai pas considéré assez supérieur à sysVinit pour justifier un remplacement.
• upstart, réputation à problèmes.
• uselessd est mort, de mémoire l'auteur affirme que le code de systemd est trop… heu… on va dire, complexe…
• systemd, et son flou «artistique» sur les limites du projet. Sans parler de son code C assez hermétique (de mémoire, parce que oui, j'ai été voir un peu, il y a perpette).
• runit. Simple. Efficace. Le code C est lisible et concis. La doc complète (sans les exemples de services) tiendrai, à vue de nez, sans difficulté sur 5 feuilles a4.

Sur deux VMs, j'ai fait des tests niveau vitesse. À services égaux, runit semble légèrement plus rapide, au démarrage comme à l'extinction.
C'est probablement égal, une fois pris en compte le manque de précision de mon outil de mesure (horloge système de l'hôte, combiné à un regard vissé sur les fenêtres des VMs) biais d'observation et le fait que la nature même d'une VM virtualbox rend les mesures aléatoires.

Personnellement, je ne comprends pas cet engouement qu'il y a pour systemd. A la limite, il se limiterait à la fonction d'init pourquoi pas. Ce serait une alternative de plus et puis voilà.

Je pense que l'engouement est lié à:

• quelques fortes personnalité qui ont fait du buzz autour, en promouvant son adoption rapide
• le fait que son inventeur ait été connu avant
• le fait qu'il fournisse, justement, tant de fonctionnalités. Ça plaît, ça donne l'impression que c'est bien, parce que les logiciels qui ne font qu'une chose, ça n'impressionne pas.
• du fait de l'engouement, il a bénéficié d'un vrai travail pour remplacer l'init sur plusieurs distributions.

Runit, puisque tu le cites, n'a, à priori, pas eu le même nombre de personnalités célèbres derrière. Et il ne cherche évidemment pas à faire autre chose que

1. initialiser le système
2. superviser les services

C'est tout de suite moins sexy. Du coup, j'imagine que peu de gens on fait l'effort de fournir des scripts d'initialisation pour une distribution, ce qui n'aide pas non plus.

tu connais la SPL ? https://raw.githubusercontent.com/matildah/SPL/master/LICENSE :)

Je connaissais pas moi, très fun :)

Sans oublier parfois l'incompatibilité manifeste entre deux paquets de distributions différentes, si un paquet a besoin de Qt 4 et l'autre de Qt 5, tu peux avoir des soucis si la distribution cible n'a pas plusieurs exemplaires de la bibliothèque.

Bien entendu, si la bonne version n'est pas disponible dans le bon système, ça passe pas.
C'est d'ailleurs une des faiblesses de Debian quand on veut des logiciels pas trop anciens (p.e., j'aimerai bien tester openmw, mais ils ont une dépendance sur une version de openscenemap qui n'est pas encore dans debian stable, backports inclus :'( ).

C'est juste que je supposais que si 2 distrib ont la même version mineure (c'est à dire avec API compatible, et puisque c'est interprété, pas de problème d'ABI) de python-qt4 (ou peu importe le nom) les paquets qui ne dépendraient que de ça n'auraient pas besoin d'être repackagé si le gestionnaire de paquet était compatible.
Manifestement, je me trompais, puisqu'ils semblerait que les mainteneurs changent les noms.

Probablement pour des raisons plus ou moins bonnes en fonction de la situation d'ailleurs: j'avais oublié qu'il puisse même y avoir des conflits de noms, par exemple dans Debian le paquet "apcalc" pour lequel "Le nom original de ce paquet est « calc » mais à dû être changé en « apcalc » pour debian car il y a déjà un autre paquet appelé « calc » dans Debian. Les binaires et les pages de manuel installés par ce paquet sont encore nommés « calc ».".
À noter qu'il n'y a plus de paquet "calc" depuis longtemps, et que celui qui à fait ce paquet à été sympa: il a mis dans la description le nom du binaire… combien de fois j'ai du décortiquer le paquet pour savoir ou les trucs étaient installés…

Je suis pas non plus vraiment d'accord pour dire que ça rende tout si compliqué. Si c'était le cas, je pense qu'il y aurait plus de matos avec une variante de netbsd/freebsd plutôt que Linux. Surtout dans la mesure ou on arrête pas de dire que le code de Linux est pas claire, que les BSD ont une meilleur pile réseau et que la GPL est trop compliqué.

Je pense qu'une raison majeure de l'utilisation de la GPL est simplement l'effet de masse. C'est l'une des licences libres les plus célèbres, après tout, et encensée plus bruyamment que les autres.
En tout cas, ce sont les raisons pour lesquelles j'avais plus "d'affinités" pour elle quand je découvrais le logiciel libre. À l'époque, j'aurai surement pas dit ça, bien sûr. Mais si on s'était avisé de me poser des questions sur la LGPL, GPL ou AGPL, j'aurai été bien embêté. Oui, je connaissais les grandes lignes, mais, par exemple, je n'ai jamais su quelle est la différence entre la v1 et la v2 de GPL. Pour la v3, je crois que c'est un truc lié au code qui tourne sur du matos loué?
Malgré que je les aie lues, et plus d'une fois, j'ai découvert aujourd'hui cette histoire de devoir fournir le code pendant 3 ans… Mon cerveau à du le zapper à chaque lecture.

Maintenant que je me soucie vraiment de comprendre les autorisations liées à un bout de code, je préfère des licences courtes (BSD 2/3 clauses, MIT, zlib…) qui restreignent moins que la GLP&co. Moins complexes. Lisibles.
Sinon les licences CC me semblent bien aussi, même si j'admets ne jamais les avoir lues.

Pour faire comme toi le lien avec du code, il y à plus de systèmes qui tournent avec:

• la version GNU de coreutils
• libstdc++
• glibc

Alors que, sincèrement, pour avoir lu le code de 2 commandes (yes et echo, de mémoire. Des commandes relativement simples, quoi.) des coreutils GNU, FreeBSD, NetBSD et OpenBSD, le code GNU est le moins lisible et de très loin. Le plus lisible était NetBSD, puis OpenBSD.
Ça me fait penser que je n'ai pas lu le code de busybox, et qu'à l'heure actuelle, c'est le sort -n de busybox que j'utilise, celui de GNU ne fonctionnant pas comme je veux (et ajouter l'option -b, qui ignore les blancs d'en-tête, ne change rien):

% ps -orss,vsz,comm -A | sort -n | grep -C 3 'ssh-agent' 
 1108   4252 runsvdir
 1424   4256 acpid
 2116   8172 pager
  336  10700 ssh-agent
 1108  10928 dropbear
 1808  15492 init
 1900  15952 xinit

% ps -orss,vsz,comm -A | busybox sort -n | grep -C 3 'ssh-agent'
    0      0 writeback
  RSS    VSZ COMMAND
    4    160 ngetty
  336  10700 ssh-agent
  672   5964 cat
  704   5964 cat
  720   4712 busybox

Pour ce qui est des lib C et C++, quand j'ai un doute sur un prototype ou une struct (parce que les manpages sont super mal branlées de ce point de vue, sans parler du fait qu'il n'y a rien pour la STL), je vais lire les header de la libc++ (de llvm) ou de muslc.
Les headers sont moins chargés, moins de branchements et inclusions, et accessoirement, la dernière fois que j'ai regardé, les espaces et les tabulations n'étaient pas mixés pour l'indentation. Contrairement au code GNU.

Dans la pratique, j'ai la flemme de recompiler ma Debian pour me débarrasser des outils GNU en faveur des alternatives plus propres. Et je parie que je ne suis pas le seul dans ce cas.
Donc, oui, vraiment, je doute que l'usage actuel des outils GNU (code comme licences) tiens énormément à un effet de masse et d'historique.
Absolument pas à des choix techniques éclairés.

Pour le code kernel (puisque tu as cité Linux), je n'en ai aucune idée, je n'ai pas encore osé mettre mon nez dedans. Les kernels restent des choses qui m'intimident, et de toute façon je n'aurai pas vraiment d'usage: je ne parviens pas à imaginer ce que je pourrai leur apporter :D

Par exemple, pour python, le paquet pour avoir pyyaml s'appelle python3-yaml chez Debian et python3-PyYAML

Effectivement, si les paquets changent de nom, c'est pas simple.

Mais sinon, tous ces langages compilés finissent très souvent par appelé du code compilé

Je pensais que les libs natives étaient encapsulées. Si ça avait été le cas, seule la lib python elle-même aurait eu une dépendance sur du natif, pas les applications (ou du moins, pas directement).

Ce qui n'empêche pas qu'il soit possible que ce soit le dernier arrivé. Je ne sais pas moi, personne ne donne de dates, et j'ai rien trouvé sur wikipedia.

Bien d'accord avec toi, mais je tenais à préciser que ce problème de disparité me semble surtout lié aux binaires exécutables.
Pour pas mal de paquets, ça ne devrait pas être le cas, puisque de nos jours, il y a énormément de logiciels écrits en langages interprétés (surtout python).

Ça serait très bien si ça se passe comme ça mais on peut en douter. Quand tu vois qu'il y a toujours les deux formats deb/rpm alors que c'est strictement la même chose.

Ironiquement, deb semble antérieur à rpm, et c'est rpm qui a été adopté par le «standard». Si c'est la même chose, pourquoi? Si FDO était là pour favoriser l'amélioration de l'existant, pourquoi?

On peut vouloir améliorer les choses plutôt que de ne rien faire

Il est plus facile d'améliorer quand il y a des concurrence à priori. Il suffit de voir les progrès que GCC fait depuis que clang est populaire.