Enj0lras a écrit 250 commentaires

À tout ceux qui moinssent, je vous mets au défi de vous confronter avec la réalité et d'essayer de recoder udev. Avant d'affirmer de telles choses, j'ai essayé.

Et au passage, j'aimerais bien les specs de udev.

Tu vis dans un monde magnifique. N'empêche que quand tu as une API comme ça qui devient utilisée par de très nombreux programmes, et que ces programmes ne fonctionnent pas sans cette API, et que cette API est liée fortement à un OS, tu n'es pas "libre de forker".

Tu ne peux pas forker, à moins de recoder linux. Donc il y a une contrainte, qui vient du fait que l'API n'est pas portable. Dans ce cas, moi je dis qu'on m'impose udev d'une certaine manière.

Non, je préfère que les fabricant écrivent des drivers portables. Ce que certains font. (faisaient ?)

Non clairement pas tout le monde à bien le droit de développer ce qu'il veut surtout quand il est crée son projet from scratch. Si son logiciel pose problème alors il n'est pas utilisé/intégré.

Un peu comme les pilotes propriétaires non ? Chacun est libre de développer un pilote libre. Et si le pilote propriétaire pose problème à des gens, alors il n'est pas utilisé/integré.

Oh wait.

En tout cas, il est dépendant de linux. ça c'est un fait. Et pas udev lui même, son API est dépendante de linux. Donc non chacun n'est pas "libre" de développer sa propre version d'udev.

fair point.

Ok. Cela dit il est possible de partir de dhclient (de BSD). La version dans OpenBSD est maintenue par les gens d'openbsd, qu'il est quand meme difficile de traiter d'amateurisme.

C'est pas parce que c'est orienté que c'est pas intéressant.

Le vrai avantage par rapport à la console linux, c'est que ça tourne pas dans l'espace noyau.

C'est plus subtile. C'est dans le pid 1 pour les fichiers de root, et dans le pid du gestionnaire de session pour les fichiers accessibles par l'utilisateur ( ie, sous l'uid de l'utilisateur ). Donc je pense que si tu peux écrire le fichier, alors c'est déjà trop tard, pas besoin d'exploiter une erreur dans le parser.

C'est bien ce que j'avais compris. Mais, je ne sauterais pas aussi vite que toi sur la conclusion. Les units sont distribués par des logiciels tiers, que tu peux ne pas vouloir faire tourner en root (souvent tu lances un daemon sous un autre utilisateur par exemple). Après je dis pas que c'est une faille majeure, et évidement c'est beaucoup moins important que dans un navigateur, pour autant je trouve un peu rapide une affirmation comme :

D’une part, systemd a été conçu pour être sécurisé : chaque binaire effectue une tâche très spécifique avec des privilèges minimaux.

Visiblement, c'est le dev de ksmcon qui a proposé systemd-consoled, mais j'imagine qu'il fait du NIH sans le vouloir :)

Oui je suis au courant que c'est le même dev, je vois pas en quoi ça change. Tu peux toujours te NIH tout seul. Bon après c'est probablement pas le meilleur exemple, mais encore une fois il y a des 100aines de libs pour emuler les terminaux, dont certaines avec un nombre minimal de dépendance. Par exemple il y a des gens qui travaillent sur le meme type de projet pour BSD qui reutilisent ce qui a été écrit pour le noyau. Après, je ne juge pas, je ne dis pas que c'est mieux ou moins bien, juste que pour moi ça rentre dans la catégorie NIH.

DHCP est pas le meilleur exemple de NIH. Timesyncd est déjà mieux. Ensuite, le client que tout le monde utilise ou presque, c'est celui de l'ISC. Pareil pour ntpd. Je dit pas qu'il y a un lien mais bon, peut être qu'il y a une piste.

Presque tout le monde sous linux :). Sinon je ne te suis pas. Quel est le soucis avec ISC ? Dans tout les cas, il y a toujours moyen d'extraire le code générique des logiciels existant, et de ne recoder que la partie qui t'intéresse, c'est à dire dans ce cas le glue avec systemd et les units. Je pense vraiment que réutiliser du code stable est toujours gagnant.

Des gens auraient râlé si l'utilisant avait été réutilisé, donc, c'est pas du NIH ?

Je ne suis pas sûr de suivre ton argumentation.

Sans vouloir remettre ta parole en doute, source? De plus, les scripts SysV étaient exécutés par root non? (vrai question)

Je pense que la déserialisation est implementée ici : http://cgit.freedesktop.org/systemd/systemd/tree/src/core/unit.c
et pour autant que je sache c'est executé dans le contexte du pid 1.

Après, oui les scripts sysV ont le même problème, je n'essaye pas de dire que c'est mieux ou moins bien que systemd, je réponds juste à certains points sur lesquels je suis en désaccord concernant systemd.

Ce qui rendrait le langage bien plus compliqué pour un gain à peu près nul, alors que là c’est TRÈS facile à analyser, en plus c’est un format standard de fait pour la configuration des logiciels. En plus il est facile de savoir si un script est faux, alors que si on commence à faire de la composition c’est déjà bien plus difficile. Là on a un nombre déterminé de champs que l’on maitrise parfaitement.

Admettons. C'est un point de vue que je ne partage pas, mais on peut dire que ça se rapporte à l'eternel débat vi/emacs, c'est deux visions des choses différentes :).

Pour la bibliothèque DHCP je ne sais pas, mais depuis quand systemd contient un émulateur de terminal?

J'ai cherché justement après avoir posté ça, apparament ça n'a pas été mergé, mais il y avait un début de code. J'espère juste simplement qu'ils vont ajouter cette fonctionnalité (parce que c'est une bonne idée) mais qu'ils vont se baser sur l'existant, notament kmscon.

Ils ne sont pas et n’ont jamais été intéressé par systemd, et ne le serait pas s’il était portable d’après tout ce que j’ai pu lire.

Par systemd non. Par un nouvel init, c'est pas aussi simple.

Quant au NIH, encore une fois, j’attends une preuve un peu plus convaincante qu’en affirmation en l’air.

Je pense que DHCP est un bon exemple, mais si ça te suffit pas, il y aussi timesyncd

Ce que je voulais noter c'est que ça semble largement plus rapide que les bibliothèques existantes.

Donc au lieu d'opmitimiser une bibliothèque existante, on en écrit une autre. Si c'est pas du NIH c'est quoi ?

Le parallele nginx apache ne tient pas car nginx a un design fondamentalement différent de nginx. Pour le reste oui je suis d'accord. C'est du NIH. Après tu peux aimer le NIH, mais prétendre que ça n'en est pas, c'est un peu gros.

Ce n'était peut être pas très clair, mais comme je le dis au début, je ne critique aucunement le fait d'avoir la gestion du réseau (ou d'autre chose) dans le dépot systemd et intégré avec systemd.

Cela dit, rien n'interdit de réutiliser une lib dhcp existante. En coder une nouvelle, c'est du NIH. ça ne veut pas dire que c'est bien ou mal, ça veut dire que c'est du NIH, affirmer le contraire c'est nier la réalité des faits.

ça arrive :

http://www.openbsdfoundation.org/gsoc2014.html#systemd

Sinon, le problème majeur, quand l'API n'est pas assez abstraite/portable pour être ré-implémentée simplement sous un autre OS, mais là je mettrais plus udev et udisks dans cette catégorie là que systemd. Par exemple, udev a une fonction new_device_from_systpath(ctx, path), ou path est une chaine. Abstraction : 0. En gros, soit tu as sysfs, avec exactement la même interface que linux, soit tu as pas udev.

Ça ressemble à un post de propagande à mon avis, j'aimerais faire quelques commentaires.

systemd est constitué de plus de 70 binaires (NdT : 72 sur ma machine !) clairement séparés. D’une part, systemd a été conçu pour être sécurisé : chaque binaire effectue une tâche très spécifique avec des privilèges minimaux — en utilisant les capacités (capabilities) du noyau par exemple — pour réduire la surface d’attaque et l’impact de failles de sécurité.

Bien que je n'irais pas jusqu'à dire que systemd est monolithique (je pense que ça s'apparente de plus en plus à un OS à la BSD, ce qui n'est pas une critique), je pense que ça va un peu loin.
En effet, je dirais que systemd n'est pas moins sécurisé qu'autre chose, mais de là à dire qu'il a été concu selon le modèle séparation des privilèges, il y a un pas (énorme). Exemple : le code qui parse les units s'execute en root, et il est privilégié. Ce qui augmente énormément la surface d'attaque;

C’est aussi un non-sens total. Une plateforme systemd est en réalité beaucoup plus simple que les Linux traditionnels, car elle unifie le système d’objets et leurs dépendances en unités systemd. Le langage des fichiers de configuration est très simple et on se débarrasse des fichiers de configuration redondants.

Je ne suis pas sûr de ça du tout. En tout cas, la courbe d'apprentissage est très élevée. Je pense qu'un logiciel simple c'est un logiciel qui fournit un petit nombre d'objets simples qui peuvent être composés simplement pour obtenir des choses complexes. C'est le cas de vi, c'est le cas du shell. CE qui n'est pas le cas de systemd du tout. Je prendrais un exemple simple, d'une option aléatoire :

IgnoreOnIsolate=
AllowIsolate=
IgnoreOnSnapshot=
L'utilisateur doit retenir plusieurs options. Un langage plus user friendly ne fournirait les commandes Ignore et allow qui seraient composable avec les événements Isolate et snaphots.

systemd est un résultat du syndrome NIH. Ce n’est pas vrai.

Quelle mauvaise foi ! Recode une bibliothèque dhcp alors qu'il en existe des 10aines ? Recoder un émulateur de terminal alors qu'il en existe des dizaines ? Si ce n'est pas du NIH, je ne sais pas comment ils appellent ça.

systemd n’est pas UNIX

Je ne rentrerais pas sur la polémique "les gens qui affirment ça sont des intégristes religieux", mais je ne reprendrais ce que j'ai dit un peu plus haut. Unix on dit souvent que c'est "tout est fichier". Ce qui est bien à cela c'est que l'OS fournit des commandes basiques pour s'occuper de fichiers. Et ils fournit un outil formidable pour composer ces commandes et obtenir des operations complexes. Le shell. Alors après, le shell est vieilli, je ne suis pas un fanatique du shell, je suis totatlement ouvert à autre chose. Mais encore une fois, "composer des operations simples" c'est ça unix. Le pipe a été une invention majeure dans la création d'unix. Et je trouve que systemd ne respecte pas vraiment ce principe.

systemd seulement pour Linux, pas sympa pour les BSD

Comme BSD ne veut pas d'un système non portable et qui reinvente pleins de bibliothèques présentes dans le systeme de base, on peut faire un tel systeme et dire que de toute façon il ne le veulent pas.
Admettons. Il y a une certaine logique à cela :). personnellement je pense que certains BSD n'auraient pas craché sur un nouvel init simple qui fait du monitoring et du démarage parallele.

Uniquement l'IA, et la logique du jeu. Enfin, les IA car il y aplusieurs bots disponibles.

Le code du moteur est en C++. C'est un schema classique pour les moteurs de jeux que d'avoir le moteur en C++ et la logique en un langage de script, que ça soit lua, javascript ou un truc interne comme QuakeVM.

Il y a peut de tests unitaires, mais ça veut pas dire qu'il n'y en a pas du tout ou que tu ne testes pas. Il y a de plus en plus de tests pour tester les API posix ou les appels systèmes. Evidement, ce n'est pas unitaire, mais ça reste un test.

j'arrive à avoir du code testable qui casse pas les autres tests en 3h… Je comprends pas ton point de vue. Ajouter du code sans casser les tests, ça peut signifier ajouter 50 lignes.

Au contraire
j'aimerais bien savoir ou tu lis un "contraire". Un projet pas fini, ça veut pas dire un projet pas testable/pas stable. ça veut juste dire pas fini.

J'abandonne.

Je viens de me rendre compte que ce type de workflow avait un nom, Agile. J'avais pas fait le lien. Comme je suis pas fan des discussions sans fin à propos de la manière de développer, et qu'apparament plus d'encre a coulé là dessus qu'il n'y a d'eau dans l'océan, autant laisser le soin à google de répondre au pour et au contre de ce genre de méthodes.

Je suis sûr que si je disais aux mecs d'openBSD qu'ils font du developpement agile, je me ferais massacrer, mais là n'est pas la question.

Il commit des qu'il ecrit un truc c' est a dire que c' est parfois (souvent) a moitie fini et il voudrait que tout le monde fasse la meme chose.

Justement, non. Je dis juste que le workflow que tu décris n'est pas forcément le One True Way et qu'on peut trouver des avantages à faire différement. Je ne dis pas que le workflow que tu décris ne marche pas, je trouve juste qu'il ne scale pas bien sur les gros projets fortement inter-dépendants comme les OS. Bon manifestement, ça doit marcher/scaler vu que des gens l'utilisent. Mais des gens utilisent aussi d'autres workflows, qui marchent aussi.

c' est parfois (souvent) a moitie fini

Oui. En quoi c'est un problème ? Tu n'es pas obligé d'activer l'option dans le système de compilation.

CVS tu peux pas bosser comme ça

C'est vrai. Mais si justement l'idée c'est de ne pas bosser comme ça, je ne vois pas en quoi ça pose un problème.

Franchement, git si tu rebase pas tout les jours, tu te retrouves très vite dans la merde. Quand tu veux rebaser 2semaines plus tard, il te faut une journée tout entière pour pouvoir rebaser et gérer tout les conflits. Personnellement, j'utilise git mais je suis plus pour développer dans la branche principale pour tout projet qui prend plus de 2 jours.

Surtout que quand tu résouds les conflits parfois tu comprends pas toujours très bien le code qui a été introduit et tu risques d'introduire un bug, donc il faut aller parler avec le type qui a fait l'autre commit. Alors que si c'était dans la branche principale, c'est lui qui gérerait ça quand il commit son code.

Tu peux signer les patchs indépendant du gestionnaire de version. D'ailleurs c'est le cas.
Franchement les utilisateurs n'ont rien à dire sur les outils qu'utilisent les devs d'un projet auquel ils ne contribuent pas, je soutiens totalement cette position.