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. Pacemaker est un système proche de celui que nous décrivons.
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). Ensuite, oui, il faudrait un système qui permet de lier des morceaux de lua à des événements. Cet init ne deviendrait plus qu'un cadre de travail fournissant les fonctionnalités de base à travers une jolie API en lua qui permettrait d'exprimer des trucs genre : Quand X est vrai, fait Y, où X est, en fait, une fonction qui attend sur le réseau et, quand l'attente est finie, fait une requête HTTPS pour récupérer un résultat, le parser et, selon le résultat, paramétrer le service correctement puis retourner vrai. Y est simplement l'exécution d'un binaire avec vérification de signature.
Tout ça n'est pas facile à obtenir aujourd'hui
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.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Justement
Posté par Etienne Bagnoud . En réponse au journal Centos / Redhat 7 : coup de gueule sur systemd. Évalué à 1.
Nos avis ne s'opposent aucunement.
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. Pacemaker est un système proche de celui que nous décrivons.
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). Ensuite, oui, il faudrait un système qui permet de lier des morceaux de lua à des événements. Cet init ne deviendrait plus qu'un cadre de travail fournissant les fonctionnalités de base à travers une jolie API en lua qui permettrait d'exprimer des trucs genre : Quand X est vrai, fait Y, où X est, en fait, une fonction qui attend sur le réseau et, quand l'attente est finie, fait une requête HTTPS pour récupérer un résultat, le parser et, selon le résultat, paramétrer le service correctement puis retourner vrai. Y est simplement l'exécution d'un binaire avec vérification de signature.
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.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell