Ce qui prend le plus de temps c'est le BIOS maintenant.
Et quant le BIOS/EFI/OpenBoot sera enfin de nouveau rapide ou se re-souciera de la performance du système d'init ?
Combien de lignes en C (A comparer au shell) pour un non problème ?
Et grep combien de lignes de C ?
Si on en arrive à un script complexe à la place d'un truc avec trois fonctions (start/stop/reload) et juste deux appels à start-stop-daemon c'est bien qu'on as un "problème" à résoudre non ?
La bonne pratique voudrait que tout les trucs plus complexes que le démarrage d'un service simple où l’exécution d'une configuration basique (l'init c'est pas que du lancement de service) soit placé dans un helper externe, peu importe le langage utilisé, mais vu que les systèmes d'init Unix interprètent le shell on s'est vite retrouvé avec par flemmardise du code bien gruik dans /etc/init.d, ici systemd ne fait qu'imposer une bonne pratique qui aurait dû être la norme bien avant son arrivé !
[^] # Re: Si tu reboot une fois par an ça va !
Posté par Tonton Benoit . En réponse au journal De la façon dont un problème de boot est résolu sous FreeBSD. Évalué à 2. Dernière modification le 31 juillet 2012 à 02:10.
Et quant le BIOS/EFI/OpenBoot sera enfin de nouveau rapide ou se re-souciera de la performance du système d'init ?
Et grep combien de lignes de C ?
Si on en arrive à un script complexe à la place d'un truc avec trois fonctions (start/stop/reload) et juste deux appels à start-stop-daemon c'est bien qu'on as un "problème" à résoudre non ?
La bonne pratique voudrait que tout les trucs plus complexes que le démarrage d'un service simple où l’exécution d'une configuration basique (l'init c'est pas que du lancement de service) soit placé dans un helper externe, peu importe le langage utilisé, mais vu que les systèmes d'init Unix interprètent le shell on s'est vite retrouvé avec par flemmardise du code bien gruik dans /etc/init.d, ici systemd ne fait qu'imposer une bonne pratique qui aurait dû être la norme bien avant son arrivé !