120

Folco (./119) :
Je dirais que c’est un gars qui fait de la trompette dans sa chambre.
rotfl
avatar

121

Pas très intuitif, ce logo... rien n'évoque systemd là-dedans. L'interprétation de Folco est pas mal, avec un tel logo ^^
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

122

123

Il paraît que c'est censé évoquer le [ OK ] des messages de démarrage des services.

Mais un commentaire dit quelque chose d'assez similaire à Folco : "c'est Poettering qui crie dans son mégaphone".
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

124

125

A peu pret grin
avatarProud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

126

Zerosquare (./123) :
Il paraît que c'est censé évoquer le [ OK ] des messages de démarrage des services..
Spontanément j'ai pensé à ça, moi smile
avatar

127

Bien joué, j'ai pas trouvé et pourtant j'ai cherché 30 secondes triso
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

128

Je vois toujours postering en train d’utiliser un mégaphone parce que pulse audio ne marche toujours pas embarrassed
avatarProud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

129

grin
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

130

Je vois toujours ça comme un canard vert vu de profil coin
En fait, c'est de l'art ce logo : tout le monde interprète ça comme il le veut bien grin
avatarAppartiens à l'Unification Ultime !

Si vous continuez, le topic devra bientôt être renommé en "publicité pour Asselineau". #roll# - Kevin

131

C'est vrai qu'il suffirait d'imprimer ce truc sur une toile pour obtenir un objet d'art contemporain. D'autant plus que SystemD en soi est déjà une œuvre controversée.
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

132

donc la en prod, on vient de se faire niquer par... journald , qui, ce connard, bouffe toute la RAM du serveur centos, au lieu d'écrire sur le disque, celui ci garde les logs en RAM... et l'OOM killer a pas apprécié, et a tué un soft applicatif au lieu de tuer journald. wtf!

Apparemment la config par défaut ne flushe pas les logs... disons très souvent.

Bordel de couille!

!slap pouet-ring

133

Ce comportement de journald n'est en effet pas sympa, mais quelle quantité de logs a-t-il eu à traiter en entrée pour en arriver à une telle extrémité ? Une quantité "normale", disons jusqu'à quelques dizaines de lignes de syslog par seconde, auquel cas le paramétrage par défaut est totalement inadéquat / journald est buggé jusqu'à la moelle pour ne pas avoir respecté le paramétrage, ou bien une quantité excessive, suffisante pour ralentir l'exécution de la machine (milliers de lignes par seconde) ?
L'info m'intéresse, car j'ai déjà vu des machines ralenties par le logging complet des opérations effectuées dans un chroot (avec un kernel systemd), sur des Debian, ou plus proche de ta config, par l'Advanced Error Reporting du bus PCI-Express sur une machine qui fait en permanence beaucoup d'erreurs corrigées, et qui tournait à l'époque Fedora 29 ou 30. Et cette dernière machine ayant 32 GB de RAM, je peux avoir raté une consommation excessive de RAM par journald.

Chez nous, c'est plutôt le pro-virus corporate, propriétaire et géré par une entité connue pour des liens avec le gouvernement d'un pays hostile, dont les binaires en code natif manquent gravement des mitigations devenues standard (mais ça s'explique en partie parce les chaînes d'identification compilo suggèrent que cette saloperie a été compilée en partie avec GCC 3.3 et 3.4...), qui fait du DoS sur les machines à cause de consommation excessive de RAM + swap (14 GB sur une machine équipée de 16 GB ? No problem !) et/ou création du nombre de processus seulement bornée par la limite du système (5K processus par défaut). Du coup on met parfois des cronjobs qui font un killall de certains processus du pro-virus, sur les machines qui ont été infectées avec cette merde...
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

134

Bon, moi aussi je me retrouve obligé d'utiliser systemd après une mise à jour de serveur. J'aurais bien du mal à dire si ça marche mieux ou moins bien étant donné que j'ai une utilisation assez simple, en tout cas ce qui est certain c'est que ça me rend un peu moins autonome pour faire des modifications même simples sur le système, et ça ça m'embête pas mal.

Par exemple je me rends compte que des VMs n'arrivent plus à se connecter à aucun service externe. Vérification faite, il semblerait que ce soit la résolution DNS qui soit cassée. Par habitude je vais vérifier le contenu de /etc/resolv.conf qu'il suffisait de modifier il n'y a encore pas bien longtemps. Maintenant c'est il y a tout un tas d'étapes supplémentaires : ce fichier est généré automatiquement et un commentaire indique que le modifier ne servirait à rien puisque ça serait perdu au prochain reboot, "See man:systemd-resolved.service(8) for details" me dit-on avec pédagogie. Pas mal de pages de lecture de manuel plus tard je crois avoir compris quelle commande taper, pour que systemd-resolved m'explique qu'en fait ça n'est pas lui qui gère cette interface mais qu'il ne fait que déléguer cette gestion à netplan, encore un nouveau logiciel à apprendre. En parallèle je vois que beaucoup d'utilisateurs ont jeté l'éponge et qu'on a même un paquet officiel "resolvconf" qui permet de revenir à l'ancien comportement en ajoutant la possibilité de spécifier du contenu custom qui sera ajouté à /etc/resolv.conf lors de sa génération. Au final, 4 paquets à comprendre, des nouveaux fichiers de configuration à écrire en YAML et un nouveau casse-tête de compatibilité, tout ça pour pouvoir saisir une adresse IP.

Je ne dois pas être la population à laquelle systemd simplifie la vie, mais punaise ça va être difficile de me faire avaler que ce sandwich d'abstractions poreuses est vraiment une amélioration sad

J'aimerais bien croiser quelqu'un convaincu de la valeur de systemd un jour pour m'expliquer ce que ça apporte (j'imagine qu'il y en a plein, sinon on ne l'aurait pas retrouvé dans toutes les distributions majeures). Sur internet on ne trouve que des gens échaudés qui ont plus ou moins réussi à faire ce qu'ils savaient déjà faire avant.
avatarAll right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

135

Zeph (./134) :
J'aimerais bien croiser quelqu'un convaincu de la valeur de systemd un jour pour m'expliquer ce que ça apporte (j'imagine qu'il y en a plein, sinon on ne l'aurait pas retrouvé dans toutes les distributions majeures).
Les distribs n'ont surtout pas eu le choix : GNOME et udev sont devenus dépendants de systemd, grâce aux efforts de lobbying de Poettering. Et ça n'a pas plus à tout le monde, loin de là.
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

136

pencil

sur le principe c'est très bien, paufiner finement ce qui démarre et quand/sous qu'elle condition
mais c'est peut être les outils d'admin qui manquent

moi il m'a rendu fou pour dnssec sans rtc, pas de dnssec sans l'heure, pas d'heure sans requête préalable, réponse du dev GFY, bref j'ai désactivé dnssec ...

(sinon journalctl peut avoir une taille max pour les logs

137

Avant il suffisait d'avoir une entrée dans /etc/fstab pour monter un répertoire partagé dans une VM.
Maintenant il faut le monter à la main, sinon systemd mouline au boot pendant une minute, avant permettre une réparation système, sans monter la partition évidemment.

SystemD = SHIT
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

138

C'est pourtant bien pratique pour ajouter des nouveaux services (ça se fait en 5min pour avoir quelque chose de propre, alors que faire un script d'init propre est quand même beaucoup plus long), et ça permet de récupérer l'état des services.

Pour moi, netplan est lié à Ubuntu uniquement, ce qui veut dire qu'avec un peu de chances ça sera abandonné après deux ou trois releases, comme pas mal de technos Ubuntu (upstart, Unity, Mir, …).
Je n'ai pas encore regardé, mais je vais bientôt devoir m'en servir et ça me fait un peu peur (j'ai deux ou trois interfaces réseaux sur certaines machines et c'est rigolo à configurer, avec des paquets qui arrivent sur une interface et qui veulent repartir sur une autre…).
avatar<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

139

J'ai déjà lu des écrits de Poettering et quelques autres listant des use cases pénibles à faire avec sysvinit, ou du moins nécessitant des daemons additionnels pour limiter le feature gap avec systemd, je pense notamment à cgmanager.
Et en effet, je suis d'accord avec Flanker, ayant déjà écrit à la fois des scripts d'init sysvinit /etc/init.d et des services systemd à titre professionnel, c'est beaucoup plus simple d'écrire des services systemd. Même s'il faut se plonger un peu dans la documentation, qui ne m'avait pas semblé mal faite, et pourquoi pas regarder d'autres services du système comme exemple, avec systemd, il y a beaucoup moins de boilerplate à copier à droite à gauche en espérant ne pas en oublier, et bien sûr, l'élimination de diverses non-portabilités intrinsèques dans les scripts sysvinit eux-mêmes (par exemple, que je sache, start-stop-daemon est une spécificité des Debian et dérivées), qui était du reste un des buts de systemd. Un service systemd simple pour déclarer un daemon tout bête, ou un cronjob simple, fait facilement moins de 10 lignes; des choses un peu plus complexes (commandes spéciales pour l'arrêt ou le redémarrage) font quelques lignes de plus. Bonne chance pour faire des scripts sysvinit "portables" (hors utilisation de chemins de conf différents selon les distros, mais systemd a également gommé des différences de ce type) équivalents en quelques lignes.
L'homogénéisation entre distros, ou des features plus avancées comme les profils seccomp (comme dans les conteneurs, à juste titre pour des raisons de sécurité) ou les capabilities, en mode déclaratif plutôt que programmatique, sont de gros plus.

Ca ne veut pas dire que tout est parfait avec systemd. Il y a des désagréments comme l'indiquent Folco et robinHood, même s'ils se contournent. Le log du journal systemd a une taille limitée, souvent réglée bas par défaut. La plupart des daemons gèrent une sortie logs autre que le journal, ce qui peut limiter les problèmes.
Aussi, plusieurs vulnérabilités historiques des composants de systemd sont embarrassantes. A l'époque où l'écriture de systemd a commencé, Rust n'était pas un choix possible; maintenant, ces composants critiques du système devraient être écrits dans un langage beaucoup plus sûr que C...

Quelles infrastructures utilises-tu pour gérer le réseau, Zeph ? NetworkManager et firewalld sont des usines à gaz exposant des services DBus et plein d'autres choses, je ne les utilise donc que si elles s'avèrent plus simples à mettre en service que la façon classique de gérer le réseau. /etc/resolv.conf et /etc/network/interfaces(.d) sur Debian/Ubuntu ou /etc/sysconfig/... sur CentOS, et règles iptables même s'il faut rentrer dedans au début, font ce que je veux pour des dizaines de machines headless ou installées sur des réseaux à assignation statique. Sur les desktops/laptops avec Desktop Environment que je n'administre pas finement, en général, je laisse NetworkManager et ses GUIs; sur ceux que j'administre finement, dont mes machines perso et pro directes, il est très rare que j'utilise NetworkManager. Le Wifi est clairement beaucoup plus facile à utiliser avec les GUIs qui commandent NetworkManager que les CLI iwconfig, iw et autres, mais en moyenne, je n'utilise même pas une fois par an du Wifi. Ce n'est, j'en conviens, pas le cas de la plupart des utilisateurs smile
Si je bascule un des laptops où le réseau est géré à la main entre un réseau avec assignation statique et un réseau DHCP, un coup de dhclient et c'est réglé.

Au fait: dans la GR sur les init systems, les DDs viennent de voter pour "B: Systemd but we support exploring alternatives", qui a légèrement devancé "F: Focus on systemd", et plus nettement tous les autres choix. https://lwn.net/Articles/808217/ . C'est une bonne chose pour l'avancement du projet.
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

140

J'ai SystemD sur Arch et il le semble que je peux modifier resolv.conf à la main, pour le coup.
avatar

141

tl;dr : systemd c'est plus cohérent pour ceux qui codent les services par contre c'est une usine à gaz pour ceux qui voudraient les utiliser
avatarWebmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

142

./139 : c'est un setup très simple avec un hyperviseur et quelques VMs, pour lequel systemd tout comme netplan sont probablement overkill

Mais je suis d'accord avec vince, surtout en lisant ce que dit Flanker : c'est peut-être plus simple pour les développeurs de service, mais ça serait une erreur de privilégier ça à la simplicité d'utilisation qui impacte largement plus de gens. C'est comme tous ces langages modernes qui vantent des syntaxes toujours plus concises, en passant à côté du fait qu'on lit un code source bien plus de fois qu'on ne l'écrit et qu'il vaut mieux privilégier la lisibilité au confort d'écriture :/
avatarAll right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

143

(ceci dit, privilégier la simplicité pour le développeur plutôt que pour l'utilisateur, c'est un peu un trait de caractère d'UNIX depuis l'origine ^^)

(et pour ceux qui pensent que c'est un troll gratuit, je vous renvoie à cet essai assez connu : https://en.wikipedia.org/wiki/Worse_is_better)
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

144

Je ne parle que des services avec systemd, pas de NetworkManager ou netplan (qui n'en font pas partie, si je ne me trompe pas). Et pour le coup, je trouve bien plus simple d'utiliser les services avec systemd qu'à l'ancienne (pour savoir si le service est bien lancé, pour le relancer automatiquement, pour la gestion des dépendances, pour le tuer de façon plus certaine, pour savoir quels services sont lancés, la ligne de commande pour lancer directement le service est en clair sans avoir à la reconstituer en analysant le script d'init, etc.). Pour l'utilisateur, avec le même système sur toutes les distribs est quand même bien pratique également.

En revanche, et ce n'est pas lié à systemd, quand on lit de la doc, on ne sait jamais si la méthode expliquée est à jour ou même si elle est correcte. Les outils ne sont également pas mis à jour ou veulent garder la compatibilité avec les vieux systèmes d'init'.

Pour le réseau, c'est quand même un gros bordel, avec un entrelacement de plusieurs systèmes et des nouvelles générations qui supplantent les anciennes mais pas trop.
Le meilleur exemple est NetworkManager. On peut toujours contrôler le réseau avec /etc/network/interfaces et les commandes ifup/ifdown/etc., et ça fonctionnera… jusqu'au moment où NetworkManager remettra sa propre configuration sans dire pourquoi.
avatar<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

145

Désolé mais si tu trouve des scripts RC compliqué, tu doit pas beaucoup faire de programmation alors.
avatarProud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

146

- compliqué + plus compliqué.

Il doit s'occuper du pid, de ne pas lancer le process en double, de s'assurer que le process est bien tué quand on veut le tuer, de le lancer avec le bon utilisateur, qu'il est bien encore vivant (indépendamment du pid), etc.
Ça sera toujours plus compliqué qu'un petit fichier de conf' systemd.
(et pour certains, oui, c'est pénible de déterminer la valeur de chaque variable et reconstituer la ligne de commande réellement lancée quand on fait du debug)
avatar<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

147

non tu n'est pas obligé de gerer le PID, et les incarnation moderne (genre OpenRC) le font pour toi
avatarProud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

148

OpenRC, s6 et quelques autres systèmes d'init modernes non systemd sont des améliorations par rapport à sysvinit, c'est un fait... mais voilà, les distros qui les utilisent out of the box sont moins populaires et/ou d'utilisation spéciale (Alpine, par exemple), et cet état de fait ne va probablement pas s'arranger maintenant que les DDs ont décidé (officiellement, je veux dire; c'était déjà partiellement le cas dans les faits) d'arrêter de freiner ou bloquer pour Debian, et donc pour un certain nombre de ses dérivées, des éléments qui ne cherchent pas à supporter autre chose que systemd... Et puis le poids historique de sysvinit reste significatif: s'ils veulent maximiser leur utilisabilité, les systèmes d'init modernes doivent rester compatibles avec sysvinit (parce qu'il existe encore un certain nombre d'upstreams qui ne gèrent que ça), ce qui les soumet à la fois aux limitations de sysvinit et aux problèmes de portabilité des scripts init, et aux bugs et limitations de leur propre couche de compatibilité sysvinit.

Les défauts de systemd à l'utilisation, réels et non tous listés dans ce topic, ne sont en aucune façon suffisants pour produire un mouvement significatif de rejet qui se traduise en un important manpower et financement correspondant pour aller à contre-courant du mastodonte systemd. Le financement du travail sur les logiciels ouverts est déjà un vrai problème en temps normal, alors quand on cherche à faire, sur le long terme, un concurrent fonctionnel frontal à la solution utilisée par toutes les distros commerciales modernes et la plupart des distros non commerciales populaires, c'est encore plus difficile...
Je dirais que Devuan l'a appris à ses dépens, de façon prévisible (en tout cas, j'avais pensé qu'ils auraient des problèmes) mais apparemment pas correctement prévue par ceux qui s'en sont occupés. L'énergie et l'argent qu'ils ont dû passer à forker Debian, monter et maintenir leur propre infrastructure au long cours, n'ont pas été passés à faire mieux fonctionner Debian et ses dérivées avec sysvinit.
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

149

As-tu discuté avec les gens qui ont travaillé sur Devuan ? Je doute qu'ils aient déployé autant d'efforts dans un fork sans avoir de bonnes raisons. Tu n'es pas obligé d'être d'accord avec eux, mais ça me paraît hâtif de prétendre que le fork est injustifié.

Par ailleurs, c'est un drôle d'argument venant d'un défenseur de l'open-source, parce que soyons honnête : si tu es contre la duplication d'effort et l’éparpillement, tu peux tuer facilement 90% ou plus des projets open-source (combien de softs différents qui font plus ou moins la même chose ? est-ce qu'il y a vraiment besoin d'avoir 36 000 distros ? etc.)
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

150

Hmm. Manifestement, je m'y suis mal pris dans mon post, parce que je semble avoir fait passer des choses que je ne voulais pas / auxquelles je ne pensais pas smile

A l'époque où ils ont forké Debian, la communication publique des "Veteran Unix Admins" était nettement sur les thèmes d'un fort rejet de systemd et un attachement fort à sysvinit. J'ai lu dès le début la critique faite aux VUA de passer une énergie importante à monter leur propre infra, à la maintenir, à maintenir et faire évoluer des choses qui leur sont propres, pour continuer leur combat d'arrière-garde après avoir perdu la bataille dans presque toutes les distros, plutôt que de chercher à garder et améliorer la compatibilité sysvinit des packages Debian au sein de Debian, au moins une fois que les choses se seraient calmées après l'âpre débat terminé par un vote du Technical Committee qui avait déjà poussé Debian vers systemd comme les autres distros. Je suis d'accord avec cette critique. Bien sûr qu'il aurait fallu (continuer à) contourner les upstreams qui ne veulent gérer que systemd, et faire évoluer sysvinit au sein de Debian plutôt qu'au sein de Devuan... mais par rapport à forker une distro mère comme Debian, qui pouvait - et ne s'en est évidemment pas privé, il n'y avait aucune raison technique ou légale de s'en priver - importer des versions de sysvinit et des scripts modifiées par Devuan, j'ai du mal à penser que ça aurait été plus lourd.

Sur le plan général, je ne comptais pas critiquer la duplication d'effort en open source, seulement pointer que même en la quasi-absence d'une telle duplication, c'est déjà très difficile de trouver un financement pour la quasi-totalité des logiciels ouverts smile
Vous aussi en faites presque forcément l'expérience dans les logiciels ouverts que vous maintenez / auxquels vous contribuez; j'en fais l'expérience sur libti*/gfm/tilp et par l'absence d'une génération suivante implémentée dans un langage plus moderne plus sûr mais toujours interopérable avec C, ajoutant une API asynchrone parce que c'est comme ça que fonctionnent des technos apparues "récemment" permettant de remplir de façon intéressante des use cases importants.
La duplication d'effort fait partie à la fois de la beauté, et des limitations, de l'approche open source. La critique "il y a trop de distros" est à la fois très vieille - elle est dans une certaine mesure antérieure à Linux, la fragmentation des BSDs et Unix propriétaires a été une faiblesse - et fondée pour certaines distros qui n'apportent que de faibles customisations à une grosse distro mère.
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.