On peut concevoir un système de démarrage séquentiel ou basé sur des événements prévisible, propre et prenant en compte l'environnement autour.
C'est le coté prévisible qui ne me semble pas possible, parce que tu réagis à des évènements physiques par définition non maitrisables.
Dans mon esprit, cet init utiliserait des scripts, mais j'avoue ne pas être un grand fan des scripts sh (comme le fait Pacemaker), je verrais bien du lua dans ce rôle (peut-être parce que NetBSD a choisi ce langage pour scripter le noyau).
Personnellement pour moi c'est du détail sans grand importance, le DSL utilisé n'est pas particulièrement intéressant. Je préfère largement quelque chose de déclaratif quelque chose comme dans gradle en groovy ou dancer en perl.
Je penses que c'est plus facile qu'il n'y paraît si on part du principe que l'init ne doit fournir qu'un cadre de travail et n'essaie pas de tout faire. Après à chaque solution, donc distribution, administrateur, utilisateur, d'utiliser ce système comme il le souhaite.
Ce que je dis c'est que les solutions actuelles ne permettent pas de répondre à ces questions.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Justement
Posté par barmic . En réponse au journal Centos / Redhat 7 : coup de gueule sur systemd. Évalué à 3.
C'est le coté prévisible qui ne me semble pas possible, parce que tu réagis à des évènements physiques par définition non maitrisables.
Personnellement pour moi c'est du détail sans grand importance, le DSL utilisé n'est pas particulièrement intéressant. Je préfère largement quelque chose de déclaratif quelque chose comme dans gradle en groovy ou dancer en perl.
Ce que je dis c'est que les solutions actuelles ne permettent pas de répondre à ces questions.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)