Le modèle pipeline sur lequel est basé systemd me laisse
perplexe et je lui préfère, par expérience, le modèle par
événements
Je suppose que tu veux dire "le modèle de dépendance" plus que le modèle en pipeline.
C'est un modèle par événement en interne tout comme upstart.
Mais à la différence d'upstart, c'est pas remonté au niveau de la configuration qui en effet ne permet que d'exprimer de "j'ai besoin de ça et ça", et systemd gére en interne sa sauce.
Parce que quand c'est pas le cas, tu as des soucis. Exemple avec upstart qui fait les choses via des réactions à des événements, tu remontes tout les soucis du modèle sur l'utilisateur/intégrateur, ce qui aboutit à ça:
C'est connu depuis longtemps qu'il y a des races conditions à ce genre d'architecture (exemple, les signaux unix https://lwn.net/Articles/414618/ ). Donc mettre ça entre les mains des utilisateurs qui sont moins au courant de tout ce qui peut arriver de mal, c'est chercher les emmerdes.
Mais je lui préfère le bon vieux schéma Unix dans lequel
chaque outil ne fait qu'une et une unique chose et le fait
bien et jusqu'au bout et c'est par assemblage de ceux-ci que
sont accomplis des tâches plus complexes (ha et aussi dans
lequel tout est texte).
Tout n'est pas texte, loin de la. C'est un fantasme. Les ioctls, c'est pas du texte par exemple, alors que ça pourrait.
Les outils ne font pas non plus qu'une chose. sort peut remplacer uniq, par exemple. ls peut faire du tri sans passer par sort. tr peut être remplacer par sed. more existe encore, faisant moins que less. zcat intégre gzip dans cat, ce qui fait du coup 2 choses.
Y a plein de cas comme ça ou on voit que les outils en ligne de commandes ont été plus le résultat du hasard qu'un design précis.
Et les scripts d'init n'utilisent pas vraiment les primitives de passages de flux d'unix, c'est juste des enchainements de commande bash (dont un paquet sont pas des binaires séparés, donc on repassera pour "faire une chose et le faire bien", vu que ça fait pas une chose, et ça le fait pas bien dans la mesure ou y a 2 façon différentes de faire les tests, etc, etc)
Et une préférence n'est pas vraiment un argument technique en tant que tel. Ça serait comme dire "je préfère que ça soit écrit en majuscule".
le dernier point est peut-être le plus important pour moi :
je me sens imposé systemd. En fait, au lieu d'avoir un systemd
qui évolue dans son coin chez RedHat et petit à petit s'impose
pour ses qualités fonctionnelles et techniques, son adoption a
été rapide sans aucune commune mesure alors même que celui-ci
n'était pas encore abouti.
Je me gausse. Systemd a mis 4 ans à arriver, Fedora a mis 2 release à faire le changement, Debian aussi et propose , Ubuntu l'a pris y a 6 mois.
Je sais pas dans quel référentiel temporel tu vis, mais un projet qui mets 6 ans à être adopté, ç'est pas ce que j'appelle "rapidement". Pour te remettre dans le contexte, en 2010, KDE était encore en version 4, le kernel était encore 2.6, gcc 4.5 était sorti. Goalgn avait été annoncé 1 an avant. Docker n’était pas la, Openstack venait juste d'être crée, Nicolas Sarkozy était président, Steve Jobs était encore en vie, tout comme Dennis Richie.
Quand à dire "non abouti", c'est du logiciel libre. Le travail est jamais fini. Et pour un truc non abouti, il n'a pas vraiment causé de dégâts à grande échelle. On nous avez promis des départs massifs d'utilisateurs de Debian, j'ai pas vu ça.
On avait promis le départ des developpeurs pour des plateformes autre que Linux, et des migrations à BSD, et j'ai pas vu ça. Il suffit de voir les stats: https://www.openhub.net/p/netbsd https://www.openhub.net/p/freebsd https://www.openhub.net/p/openbsd
NetBSD perds un peu, OpenBSD gagne un peu, FreeBSD reste stable.
Ou juste voir que Devuan galére à sortir sa version stable alors que tout le travail est fait par Debian.
Quand à se sentir imposé, bienvenue dans le monde réel. À partir du moment ou tu es en bout de la chaine de production, c'est un cadeau que tu reçoit, tu as juste le choix de ne pas le prendre. Personne n'a d'obligation de te filer autre chose, et visiblement, le consensus va plus vers l'usage de systemd que vers le fait d'aider Devuan a sortir une version sans systemd.
[^] # Re: systemd
Posté par Misc (site web personnel) . En réponse au journal Devuan a deux ans. Évalué à 8.
Je suppose que tu veux dire "le modèle de dépendance" plus que le modèle en pipeline.
C'est un modèle par événement en interne tout comme upstart.
Mais à la différence d'upstart, c'est pas remonté au niveau de la configuration qui en effet ne permet que d'exprimer de "j'ai besoin de ça et ça", et systemd gére en interne sa sauce.
Parce que quand c'est pas le cas, tu as des soucis. Exemple avec upstart qui fait les choses via des réactions à des événements, tu remontes tout les soucis du modèle sur l'utilisateur/intégrateur, ce qui aboutit à ça:
https://bugs.launchpad.net/upstart/+bug/447654
Le bug est marqué corrigé, mais parce qu'il y a plus un workaround qu'un correctif, car utiliser "et" pose toujours souci à upstart:
https://bugs.launchpad.net/upstart/+bug/447654/comments/6
En utilisant des dépendances simple "en pipeline", systemd évite le souci.
Et des soucis liés au coté asynchrone des événements, y en a d'autres dans le bug tracker.
Par exemple:
https://bugs.launchpad.net/upstart/+bug/516713 , https://bugs.launchpad.net/upstart/+bug/539175
C'est connu depuis longtemps qu'il y a des races conditions à ce genre d'architecture (exemple, les signaux unix https://lwn.net/Articles/414618/ ). Donc mettre ça entre les mains des utilisateurs qui sont moins au courant de tout ce qui peut arriver de mal, c'est chercher les emmerdes.
Tout n'est pas texte, loin de la. C'est un fantasme. Les ioctls, c'est pas du texte par exemple, alors que ça pourrait.
Les outils ne font pas non plus qu'une chose. sort peut remplacer uniq, par exemple. ls peut faire du tri sans passer par sort. tr peut être remplacer par sed. more existe encore, faisant moins que less. zcat intégre gzip dans cat, ce qui fait du coup 2 choses.
Y a plein de cas comme ça ou on voit que les outils en ligne de commandes ont été plus le résultat du hasard qu'un design précis.
Et les scripts d'init n'utilisent pas vraiment les primitives de passages de flux d'unix, c'est juste des enchainements de commande bash (dont un paquet sont pas des binaires séparés, donc on repassera pour "faire une chose et le faire bien", vu que ça fait pas une chose, et ça le fait pas bien dans la mesure ou y a 2 façon différentes de faire les tests, etc, etc)
Et une préférence n'est pas vraiment un argument technique en tant que tel. Ça serait comme dire "je préfère que ça soit écrit en majuscule".
Je me gausse. Systemd a mis 4 ans à arriver, Fedora a mis 2 release à faire le changement, Debian aussi et propose , Ubuntu l'a pris y a 6 mois.
Je sais pas dans quel référentiel temporel tu vis, mais un projet qui mets 6 ans à être adopté, ç'est pas ce que j'appelle "rapidement". Pour te remettre dans le contexte, en 2010, KDE était encore en version 4, le kernel était encore 2.6, gcc 4.5 était sorti. Goalgn avait été annoncé 1 an avant. Docker n’était pas la, Openstack venait juste d'être crée, Nicolas Sarkozy était président, Steve Jobs était encore en vie, tout comme Dennis Richie.
Quand à dire "non abouti", c'est du logiciel libre. Le travail est jamais fini. Et pour un truc non abouti, il n'a pas vraiment causé de dégâts à grande échelle. On nous avez promis des départs massifs d'utilisateurs de Debian, j'ai pas vu ça.
On avait promis le départ des developpeurs pour des plateformes autre que Linux, et des migrations à BSD, et j'ai pas vu ça. Il suffit de voir les stats:
https://www.openhub.net/p/netbsd
https://www.openhub.net/p/freebsd
https://www.openhub.net/p/openbsd
NetBSD perds un peu, OpenBSD gagne un peu, FreeBSD reste stable.
Ou juste voir que Devuan galére à sortir sa version stable alors que tout le travail est fait par Debian.
Quand à se sentir imposé, bienvenue dans le monde réel. À partir du moment ou tu es en bout de la chaine de production, c'est un cadeau que tu reçoit, tu as juste le choix de ne pas le prendre. Personne n'a d'obligation de te filer autre chose, et visiblement, le consensus va plus vers l'usage de systemd que vers le fait d'aider Devuan a sortir une version sans systemd.