Pinit ou parallele init : le première init parallèle pour Linux pour la partie init (Mandriva). ça pouvait gérer les dépendances entre scripts, compatible rc.d. Comme bien des choses, c'était super à l'époque, et vite abandonné. Je n'ai pas cherché des alternatives à ça.
C'est quoi, d'ailleurs, les consorts de sysV?
J'aurais pas dû dire consort, mais compatible. Consort suppose qu'il y a des alternatives à SysV (oui y a BSD, mais c'est la même chose).. mais disons tous les init "compatible" init SysV.
Avant SystemD, un fichier init Debian (le cas particulier car compatible BSD), Solaris, Fedora ou Mandriva n'était pas compatible entre eux, mais compatible Init System V. Super...
Et c'est quoi, selon toi, le rôle de systemd?
on dirait mon Psy.. Le rôle c'est s'occuper du cycle de vie des processus non interactifs de mon système, comme init, cron, at, udev, KSMServer (je connais pas bien le fonctionnement du desktop, mais il s'occupe de lancer les services desktop)... Il se permet également de traquer les changements de configurations. Il est responsable d'une partie de la configuration (le nom de la machine par exemple).
C'est ça qui m'a fait chercher des alternatives, et je dois à systemd le fait de connaître des alternatives à rc.d.
Très bien, partages tes trouvailles (tu l'as déjà fait dans un autre message)!
Par contre si tu critiques SystemD, c'est bienvenu, mais il faut être précis et ne pas hésiter à expliquer.
Tu dis "bugs qui sont liés à l'usage de fonctions dont la simple lecture du rôle me fait froid dans le dos (allouer sur la stack?)!" - Ça fait très peur quand on lit ça.. Je suis un peu distant avec le savoir académique, alors, je vais p-e te paraître grotesque, mais on passe notre vie à allouer sur la stack. Il y a même des intrinsic des compilateurs pour allouer sur la stack, c'est sans doute même le meilleur endroit pour allouer. Alors dis nous ce qui en terme de développement est problématique. Parce que "Oh, tu te rends compte, ils allouent sur la stack! Comment osent-ils!!!", moi, ça me fait ni chaud ni froid.
Et même, si certaines pratiques de développement seraient mauvaises, ça ne remet pas l'intérêt de SystemD en cause. Il répond à des besoins où nous n'avions pas de solution simple avant. Que ce soit parfait, certainement pas, nécessaire, oui.
[^] # Re: Devuan
Posté par YBoy360 (site web personnel) . En réponse au journal Remède au problème démarrage devuan ascii sur raspberry pi 2. Évalué à 2.
Pinit ou parallele init : le première init parallèle pour Linux pour la partie init (Mandriva). ça pouvait gérer les dépendances entre scripts, compatible rc.d. Comme bien des choses, c'était super à l'époque, et vite abandonné. Je n'ai pas cherché des alternatives à ça.
J'aurais pas dû dire consort, mais compatible. Consort suppose qu'il y a des alternatives à SysV (oui y a BSD, mais c'est la même chose).. mais disons tous les init "compatible" init SysV.
Avant SystemD, un fichier init Debian (le cas particulier car compatible BSD), Solaris, Fedora ou Mandriva n'était pas compatible entre eux, mais compatible Init System V. Super...
on dirait mon Psy.. Le rôle c'est s'occuper du cycle de vie des processus non interactifs de mon système, comme init, cron, at, udev, KSMServer (je connais pas bien le fonctionnement du desktop, mais il s'occupe de lancer les services desktop)... Il se permet également de traquer les changements de configurations. Il est responsable d'une partie de la configuration (le nom de la machine par exemple).
Très bien, partages tes trouvailles (tu l'as déjà fait dans un autre message)!
Par contre si tu critiques SystemD, c'est bienvenu, mais il faut être précis et ne pas hésiter à expliquer.
Tu dis "bugs qui sont liés à l'usage de fonctions dont la simple lecture du rôle me fait froid dans le dos (allouer sur la stack?)!" - Ça fait très peur quand on lit ça.. Je suis un peu distant avec le savoir académique, alors, je vais p-e te paraître grotesque, mais on passe notre vie à allouer sur la stack. Il y a même des intrinsic des compilateurs pour allouer sur la stack, c'est sans doute même le meilleur endroit pour allouer. Alors dis nous ce qui en terme de développement est problématique. Parce que "Oh, tu te rends compte, ils allouent sur la stack! Comment osent-ils!!!", moi, ça me fait ni chaud ni froid.
Et même, si certaines pratiques de développement seraient mauvaises, ça ne remet pas l'intérêt de SystemD en cause. Il répond à des besoins où nous n'avions pas de solution simple avant. Que ce soit parfait, certainement pas, nécessaire, oui.