Je pense de plus en plus à implémenter un init pour les BSDs avec les
mêmes possibilités qu'offre systemd. En effet, celui-ci offre des
avantages que l'on ne peut plus négliger pour un OS moderne.
Parmi ces avantages, on peut noter, par exemple, la possibilité
d'implémenter un monitoring de daemon évolué par rapport
à ce que permet l'init de BSD, la possibilité de gérer l'hard dans
l'init lui-même, d'avoir une journalisation digne de ce nom au format
binaire, s'il vous plait, de gérer des containers, etc. J'arrête là,
les avantages apporté par cet init qui, de fait, sont bien trop
nombreux pour qu'un humain ordinaire puisse tous les énumérer.
Certes, il reste peut-être quelques petites erreurs de jeunesse, qui
seront, à ne pas douter, rapidement corriger, les mainteneurs de systemd
étant particulièrement réceptifs aux corrections de bugs, mais tout
celà ne devrait pas empêcher une bonne intégration dans un système BSD,
d'autant plus si l'on implémente from scratch.
Pourquoi from scratch ? Le problème est que systemd est sous licence
GNU LGPL 1.2, et quand bien même il existe des logiciels sous
licence GNU dans le coeur des principaux BSDs, il serait préférable
d'utliser une vrai licence libre.
Enfin il reste le choix du premier BSD pour commencer cette
implémentation. Le choix de FreeBSD est évident. C'est le seul à
posséder un système de type MAC digne de ce nom grâce à Trusted BSD, ce
qui, de facto, démontre sans aucun doute que c'est le système le
plus sécurisé de la famille BSD.
Cependant, je ne suis pas assez familiarisé avec cet init
extraordinaire, d'où ma demande sur fcold aux divers spécialistes
des Linux qui ont très certainement d'autres arguments en faveur de
systemd, des conseils sur comment bien implémenter un journal binaire,
ce genre de choses, quoi.
A noter, si je ne crosspote pas avec fcob, c'est bien pour leur laisser
l'agréable surprise lorsque le nouvel init sera commité pour la
prochaine release de FreeBSD (la 11.1 donc).
En fait, de ce que j'ai compris, systemd est un logiciel fait pour pallier à la baisse de qualité des logiciels qui tournent sur Linux. Comme ça plante de plus en plus de tous les côtés, il faut inventer une usine à gaz pour cacher ça aux utilisateurs. Se faisant, le système s'enfonce dans une spirale ou il devient inutile de faire du beau code, puisque le système sait, de lui même, pallier à n'importe quel plantage.
C'est sans doute l'histoire qui recommence: il existait un binaire appelé init qui lançait et supervisait des programmes. init sait respawn des programmes qui s'arrêtent, il sait les surveiller, les forker, le tout dans un langage fonctionnel: ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now z6:6:respawn:/sbin/sulogin etc... Et on peut démarrer un linux uniquement avec init sans aucun script shell (spoiler: c'est très rapide). Bon, ensuite des gars ont voulu ajouter du scripting par dessus pour la souplesse. Ca donne les /etc/rc.d/ c'est bien, c'est souple, on oublie un peu init. Puis on a fait des liens, puis des /etc/alternative puis des start-stop-daemon, puis des lib etc.. puis des trucs atroces puis des réécritures avec /bin/dash qui cassent les scripts mais qui gagnent 3 pouillèmes de microsecondes à chaque lancement[1]. Quelques dizaines d'années plus tard, on arrive a un gros tas informe de scripts spaghettis juste improbables à lire, et à l'enchainement douteux (sauf slackware, mais slackware, c'est bien.) Breaking news: Lennart dit que non, ça suffit, qu'il faut faire quelque chose que ce n'est plus possible ces scripts, c'est le bordel. La surprise étant qu'il code réellement quelque chose. On aboutit à l'abandon des scripts, on retourne à un binaire qui supervise les lancements des programmes au boot avec une syntaxe propre à lui même. Ca vous rappelle /sbin/init? moi aussi. Il ne reste désormais plus qu'à avoir un systemd monolithique dont le rôle sera de lancer un /bin/rc.script qui possèdera plusieurs runlevel, et qui pour plus de souplesse lancera des scripts (shells? d'un autre langage de script? Powershell? perl? l'avenir nous le dira). Puis on verra revenir des liens symboliques, des superviseurs légers, des spaghettis, etc etc... Et puis des gens diront qu'il faut faire quelque chose, que ce n'est plus possible ces scripts, c'est le bordel. La suite dans 10 ans? [1] Big win les gars. Je pense que le temps passé à corriger les scripts a du exploser par mille le temps gagné par le lancement de dash. -- Kevin
Le 17-10-2016, S.T. <pffff@toutunehistoire.com> a écrit :
En fait, de ce que j'ai compris, systemd est un logiciel fait pour
pallier à la baisse de qualité des logiciels qui tournent sur Linux.
Comme ça plante de plus en plus de tous les côtés, il faut inventer une
usine à gaz pour cacher ça aux utilisateurs. Se faisant, le système
s'enfonce dans une spirale ou il devient inutile de faire du beau code,
puisque le système sait, de lui même, pallier à n'importe quel plantage.
C'est sans doute l'histoire qui recommence:
il existait un binaire appelé init qui lançait et supervisait des programmes.
init sait respawn des programmes qui s'arrêtent, il sait les surveiller,
les forker, le tout dans un langage fonctionnel:
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
z6:6:respawn:/sbin/sulogin
etc...
Et on peut démarrer un linux uniquement avec init sans aucun script
shell (spoiler: c'est très rapide).
Bon, ensuite des gars ont voulu ajouter du scripting par dessus pour la
souplesse. Ca donne les /etc/rc.d/ c'est bien, c'est souple, on oublie
un peu init. Puis on a fait des liens, puis des /etc/alternative
puis des start-stop-daemon, puis des lib etc.. puis des trucs atroces
puis des réécritures avec /bin/dash qui cassent les scripts mais qui
gagnent 3 pouillèmes de microsecondes à chaque lancement[1].
Quelques dizaines d'années plus tard, on arrive a un gros tas informe
de scripts spaghettis juste improbables à lire, et à l'enchainement
douteux (sauf slackware, mais slackware, c'est bien.)
Breaking news: Lennart dit que non, ça suffit, qu'il faut faire quelque
chose que ce n'est plus possible ces scripts, c'est le bordel. La
surprise étant qu'il code réellement quelque chose.
On aboutit à l'abandon des scripts, on retourne à un binaire qui
supervise les lancements des programmes au boot avec une syntaxe
propre à lui même. Ca vous rappelle /sbin/init? moi aussi.
Il ne reste désormais plus qu'à avoir un systemd monolithique dont
le rôle sera de lancer un /bin/rc.script qui possèdera plusieurs
runlevel, et qui pour plus de souplesse lancera des scripts (shells?
d'un autre langage de script? Powershell? perl? l'avenir nous le dira).
Puis on verra revenir des liens symboliques, des superviseurs légers,
des spaghettis, etc etc... Et puis des gens diront qu'il faut
faire quelque chose, que ce n'est plus possible ces scripts, c'est
le bordel.
La suite dans 10 ans?
[1] Big win les gars. Je pense que le temps passé à corriger les
scripts a du exploser par mille le temps gagné par le lancement de dash.
--
Kevin
En fait, de ce que j'ai compris, systemd est un logiciel fait pour pallier à la baisse de qualité des logiciels qui tournent sur Linux. Comme ça plante de plus en plus de tous les côtés, il faut inventer une usine à gaz pour cacher ça aux utilisateurs. Se faisant, le système s'enfonce dans une spirale ou il devient inutile de faire du beau code, puisque le système sait, de lui même, pallier à n'importe quel plantage.
C'est sans doute l'histoire qui recommence: il existait un binaire appelé init qui lançait et supervisait des programmes. init sait respawn des programmes qui s'arrêtent, il sait les surveiller, les forker, le tout dans un langage fonctionnel: ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now z6:6:respawn:/sbin/sulogin etc... Et on peut démarrer un linux uniquement avec init sans aucun script shell (spoiler: c'est très rapide). Bon, ensuite des gars ont voulu ajouter du scripting par dessus pour la souplesse. Ca donne les /etc/rc.d/ c'est bien, c'est souple, on oublie un peu init. Puis on a fait des liens, puis des /etc/alternative puis des start-stop-daemon, puis des lib etc.. puis des trucs atroces puis des réécritures avec /bin/dash qui cassent les scripts mais qui gagnent 3 pouillèmes de microsecondes à chaque lancement[1]. Quelques dizaines d'années plus tard, on arrive a un gros tas informe de scripts spaghettis juste improbables à lire, et à l'enchainement douteux (sauf slackware, mais slackware, c'est bien.) Breaking news: Lennart dit que non, ça suffit, qu'il faut faire quelque chose que ce n'est plus possible ces scripts, c'est le bordel. La surprise étant qu'il code réellement quelque chose. On aboutit à l'abandon des scripts, on retourne à un binaire qui supervise les lancements des programmes au boot avec une syntaxe propre à lui même. Ca vous rappelle /sbin/init? moi aussi. Il ne reste désormais plus qu'à avoir un systemd monolithique dont le rôle sera de lancer un /bin/rc.script qui possèdera plusieurs runlevel, et qui pour plus de souplesse lancera des scripts (shells? d'un autre langage de script? Powershell? perl? l'avenir nous le dira). Puis on verra revenir des liens symboliques, des superviseurs légers, des spaghettis, etc etc... Et puis des gens diront qu'il faut faire quelque chose, que ce n'est plus possible ces scripts, c'est le bordel. La suite dans 10 ans? [1] Big win les gars. Je pense que le temps passé à corriger les scripts a du exploser par mille le temps gagné par le lancement de dash. -- Kevin
Nicolas George
Kevin Denis , dans le message , a écrit :
C'est sans doute l'histoire qui recommence: il existait un binaire appelé init qui lançait et supervisait des programmes. init sait respawn des programmes qui s'arrêtent, il sait les surveiller, les forker, le tout dans un langage fonctionnel: ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now z6:6:respawn:/sbin/sulogin etc... Et on peut démarrer un linux uniquement avec init sans aucun script shell (spoiler: c'est très rapide). Bon, ensuite des gars ont voulu ajouter du scripting par dessus pour la souplesse. Ca donne les /etc/rc.d/ c'est bien, c'est souple, on oublie un peu init. Puis on a fait des liens, puis des /etc/alternative puis des start-stop-daemon, puis des lib etc.. puis des trucs atroces puis des réécritures avec /bin/dash qui cassent les scripts mais qui gagnent 3 pouillèmes de microsecondes à chaque lancement[1]. Quelques dizaines d'années plus tard, on arrive a un gros tas informe de scripts spaghettis juste improbables à lire, et à l'enchainement douteux Breaking news: Lennart dit que non, ça suffit, qu'il faut faire quelque chose que ce n'est plus possible ces scripts, c'est le bordel. La surprise étant qu'il code réellement quelque chose. On aboutit à l'abandon des scripts, on retourne à un binaire qui supervise les lancements des programmes au boot avec une syntaxe propre à lui même. Ca vous rappelle /sbin/init? moi aussi.
Très bon résumé. Évidemment, quand on refait from scratch quelque chose qui a trente ans d'histoire, on ne peut pas espérer avoir un résultat parfait tout de suite.
Il ne reste désormais plus qu'à avoir un systemd monolithique dont le rôle sera de lancer un /bin/rc.script qui possèdera plusieurs runlevel, et qui pour plus de souplesse lancera des scripts (shells? d'un autre langage de script? Powershell? perl? l'avenir nous le dira). Puis on verra revenir des liens symboliques, des superviseurs légers, des spaghettis, etc etc... Et puis des gens diront qu'il faut faire quelque chose, que ce n'est plus possible ces scripts, c'est le bordel.
Justement, le fait d'incorporer assez de logique dans /sbin/init permet de ne pas avoir besoin des scripts en plus.
Kevin Denis , dans le message
<slrno09nn2.s6b.kevin@slackwall.local.tux>, a écrit :
C'est sans doute l'histoire qui recommence:
il existait un binaire appelé init qui lançait et supervisait des programmes.
init sait respawn des programmes qui s'arrêtent, il sait les surveiller,
les forker, le tout dans un langage fonctionnel:
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
z6:6:respawn:/sbin/sulogin
etc...
Et on peut démarrer un linux uniquement avec init sans aucun script
shell (spoiler: c'est très rapide).
Bon, ensuite des gars ont voulu ajouter du scripting par dessus pour la
souplesse. Ca donne les /etc/rc.d/ c'est bien, c'est souple, on oublie
un peu init. Puis on a fait des liens, puis des /etc/alternative
puis des start-stop-daemon, puis des lib etc.. puis des trucs atroces
puis des réécritures avec /bin/dash qui cassent les scripts mais qui
gagnent 3 pouillèmes de microsecondes à chaque lancement[1].
Quelques dizaines d'années plus tard, on arrive a un gros tas informe
de scripts spaghettis juste improbables à lire, et à l'enchainement
douteux
Breaking news: Lennart dit que non, ça suffit, qu'il faut faire quelque
chose que ce n'est plus possible ces scripts, c'est le bordel. La
surprise étant qu'il code réellement quelque chose.
On aboutit à l'abandon des scripts, on retourne à un binaire qui
supervise les lancements des programmes au boot avec une syntaxe
propre à lui même. Ca vous rappelle /sbin/init? moi aussi.
Très bon résumé.
Évidemment, quand on refait from scratch quelque chose qui a trente ans
d'histoire, on ne peut pas espérer avoir un résultat parfait tout de suite.
Il ne reste désormais plus qu'à avoir un systemd monolithique dont
le rôle sera de lancer un /bin/rc.script qui possèdera plusieurs
runlevel, et qui pour plus de souplesse lancera des scripts (shells?
d'un autre langage de script? Powershell? perl? l'avenir nous le dira).
Puis on verra revenir des liens symboliques, des superviseurs légers,
des spaghettis, etc etc... Et puis des gens diront qu'il faut
faire quelque chose, que ce n'est plus possible ces scripts, c'est
le bordel.
Justement, le fait d'incorporer assez de logique dans /sbin/init permet de
ne pas avoir besoin des scripts en plus.
C'est sans doute l'histoire qui recommence: il existait un binaire appelé init qui lançait et supervisait des programmes. init sait respawn des programmes qui s'arrêtent, il sait les surveiller, les forker, le tout dans un langage fonctionnel: ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now z6:6:respawn:/sbin/sulogin etc... Et on peut démarrer un linux uniquement avec init sans aucun script shell (spoiler: c'est très rapide). Bon, ensuite des gars ont voulu ajouter du scripting par dessus pour la souplesse. Ca donne les /etc/rc.d/ c'est bien, c'est souple, on oublie un peu init. Puis on a fait des liens, puis des /etc/alternative puis des start-stop-daemon, puis des lib etc.. puis des trucs atroces puis des réécritures avec /bin/dash qui cassent les scripts mais qui gagnent 3 pouillèmes de microsecondes à chaque lancement[1]. Quelques dizaines d'années plus tard, on arrive a un gros tas informe de scripts spaghettis juste improbables à lire, et à l'enchainement douteux Breaking news: Lennart dit que non, ça suffit, qu'il faut faire quelque chose que ce n'est plus possible ces scripts, c'est le bordel. La surprise étant qu'il code réellement quelque chose. On aboutit à l'abandon des scripts, on retourne à un binaire qui supervise les lancements des programmes au boot avec une syntaxe propre à lui même. Ca vous rappelle /sbin/init? moi aussi.
Très bon résumé. Évidemment, quand on refait from scratch quelque chose qui a trente ans d'histoire, on ne peut pas espérer avoir un résultat parfait tout de suite.
Il ne reste désormais plus qu'à avoir un systemd monolithique dont le rôle sera de lancer un /bin/rc.script qui possèdera plusieurs runlevel, et qui pour plus de souplesse lancera des scripts (shells? d'un autre langage de script? Powershell? perl? l'avenir nous le dira). Puis on verra revenir des liens symboliques, des superviseurs légers, des spaghettis, etc etc... Et puis des gens diront qu'il faut faire quelque chose, que ce n'est plus possible ces scripts, c'est le bordel.
Justement, le fait d'incorporer assez de logique dans /sbin/init permet de ne pas avoir besoin des scripts en plus.
Jo Engo
Le Mon, 17 Oct 2016 09:22:26 +0000, Nicolas George a écrit :
le gros nul qui se prend pour un cador et qui affirme des choses fausses avec aplomb
Initiales NG ? -- La vision est l'art de voir les choses invisibles. -+- Jonathan Swift -+-
Le Mon, 17 Oct 2016 09:22:26 +0000, Nicolas George a écrit :
le gros nul qui se prend pour un cador et qui affirme des choses fausses
avec aplomb
Initiales NG ?
--
La vision est l'art de voir les choses invisibles.
-+- Jonathan Swift -+-
Le Mon, 17 Oct 2016 09:22:26 +0000, Nicolas George a écrit :
le gros nul qui se prend pour un cador et qui affirme des choses fausses avec aplomb
Initiales NG ?
Yep ! Ce que j'aime bien en lui, c'est sa modestie, sa simplicité naturelle.
Doug713705
Le 17-10-2016, Nicolas George nous expliquait dans fr.comp.os.linux.debats (<58049d5a$0$7996$) :
On aboutit à l'abandon des scripts, on retourne à un binaire qui supervise les lancements des programmes au boot avec une syntaxe propre à lui même. Ca vous rappelle /sbin/init? moi aussi.
Très bon résumé. Évidemment, quand on refait from scratch quelque chose qui a trente ans d'histoire, on ne peut pas espérer avoir un résultat parfait tout de suite.
Mais _pourquoi_ intégrer un truc clairement pas sec ? Pourquoi faire la sourde oreille quand on ose poser la question ? Il n'y avait pas une urgence absolue à intégrer une bouse pareille, on aurait pu attendre 5 ou 10 ans que quelques distributions aventureuses s'y casse les dents, ce n'était pas si grave.
Il ne reste désormais plus qu'à avoir un systemd monolithique dont le rôle sera de lancer un /bin/rc.script qui possèdera plusieurs runlevel, et qui pour plus de souplesse lancera des scripts (shells? d'un autre langage de script? Powershell? perl? l'avenir nous le dira). Puis on verra revenir des liens symboliques, des superviseurs légers, des spaghettis, etc etc... Et puis des gens diront qu'il faut faire quelque chose, que ce n'est plus possible ces scripts, c'est le bordel.
Justement, le fait d'incorporer assez de logique dans /sbin/init permet de ne pas avoir besoin des scripts en plus.
Même pas j'y crois. Enfin si je veux ben croire que les scripts ne sont plus nécessaires mais je ne crois pas qu'il n'y aura pas un jour un gars qui se lèvera un matin en disant "Hey les gars, j'ai une super idée, ajoutons des scripts" et d'autres gars de le suivre avec cet enthousiasme teinté de fanatisme qui caractérise si bien les inconscients et les fanboys. -- Les partouzeurs de miss métro Patrouillent au fond des souterrains Mais ils rêvent d'être en hélico À s'faire de nèg' et du youpin... H.F. Thiéfaine- 113ème Cigarette Sans Dormir
Le 17-10-2016, Nicolas George nous expliquait dans
fr.comp.os.linux.debats
(<58049d5a$0$7996$426a34cc@news.free.fr>) :
On aboutit à l'abandon des scripts, on retourne à un binaire qui
supervise les lancements des programmes au boot avec une syntaxe
propre à lui même. Ca vous rappelle /sbin/init? moi aussi.
Très bon résumé.
Évidemment, quand on refait from scratch quelque chose qui a trente ans
d'histoire, on ne peut pas espérer avoir un résultat parfait tout de suite.
Mais _pourquoi_ intégrer un truc clairement pas sec ?
Pourquoi faire la sourde oreille quand on ose poser la question ?
Il n'y avait pas une urgence absolue à intégrer une bouse pareille, on
aurait pu attendre 5 ou 10 ans que quelques distributions aventureuses
s'y casse les dents, ce n'était pas si grave.
Il ne reste désormais plus qu'à avoir un systemd monolithique dont
le rôle sera de lancer un /bin/rc.script qui possèdera plusieurs
runlevel, et qui pour plus de souplesse lancera des scripts (shells?
d'un autre langage de script? Powershell? perl? l'avenir nous le dira).
Puis on verra revenir des liens symboliques, des superviseurs légers,
des spaghettis, etc etc... Et puis des gens diront qu'il faut
faire quelque chose, que ce n'est plus possible ces scripts, c'est
le bordel.
Justement, le fait d'incorporer assez de logique dans /sbin/init permet de
ne pas avoir besoin des scripts en plus.
Même pas j'y crois. Enfin si je veux ben croire que les scripts ne sont
plus nécessaires mais je ne crois pas qu'il n'y aura pas un jour un gars
qui se lèvera un matin en disant "Hey les gars, j'ai une super idée,
ajoutons des scripts" et d'autres gars de le suivre avec cet
enthousiasme teinté de fanatisme qui caractérise si bien les
inconscients et les fanboys.
--
Les partouzeurs de miss métro
Patrouillent au fond des souterrains
Mais ils rêvent d'être en hélico
À s'faire de nèg' et du youpin...
H.F. Thiéfaine- 113ème Cigarette Sans Dormir
Le 17-10-2016, Nicolas George nous expliquait dans fr.comp.os.linux.debats (<58049d5a$0$7996$) :
On aboutit à l'abandon des scripts, on retourne à un binaire qui supervise les lancements des programmes au boot avec une syntaxe propre à lui même. Ca vous rappelle /sbin/init? moi aussi.
Très bon résumé. Évidemment, quand on refait from scratch quelque chose qui a trente ans d'histoire, on ne peut pas espérer avoir un résultat parfait tout de suite.
Mais _pourquoi_ intégrer un truc clairement pas sec ? Pourquoi faire la sourde oreille quand on ose poser la question ? Il n'y avait pas une urgence absolue à intégrer une bouse pareille, on aurait pu attendre 5 ou 10 ans que quelques distributions aventureuses s'y casse les dents, ce n'était pas si grave.
Il ne reste désormais plus qu'à avoir un systemd monolithique dont le rôle sera de lancer un /bin/rc.script qui possèdera plusieurs runlevel, et qui pour plus de souplesse lancera des scripts (shells? d'un autre langage de script? Powershell? perl? l'avenir nous le dira). Puis on verra revenir des liens symboliques, des superviseurs légers, des spaghettis, etc etc... Et puis des gens diront qu'il faut faire quelque chose, que ce n'est plus possible ces scripts, c'est le bordel.
Justement, le fait d'incorporer assez de logique dans /sbin/init permet de ne pas avoir besoin des scripts en plus.
Même pas j'y crois. Enfin si je veux ben croire que les scripts ne sont plus nécessaires mais je ne crois pas qu'il n'y aura pas un jour un gars qui se lèvera un matin en disant "Hey les gars, j'ai une super idée, ajoutons des scripts" et d'autres gars de le suivre avec cet enthousiasme teinté de fanatisme qui caractérise si bien les inconscients et les fanboys. -- Les partouzeurs de miss métro Patrouillent au fond des souterrains Mais ils rêvent d'être en hélico À s'faire de nèg' et du youpin... H.F. Thiéfaine- 113ème Cigarette Sans Dormir
Dominique MICOLLET
Bonjour, Nicolas George wrote:
Qu'est-ce que ça apporterait de plus ?
Il me semble impossible que deux processus différents aient le même PID et la même date de création. Cordialement Dominique
Bonjour,
Nicolas George wrote:
Qu'est-ce que ça apporterait de plus ?
Il me semble impossible que deux processus différents aient le même PID et
la même date de création.
Il me semble impossible que deux processus différents aient le même PID et la même date de création. Cordialement Dominique
JKB
Le Mon, 17 Oct 2016 10:12:51 +0000 (UTC), Doug713705 écrivait :
Le 17-10-2016, Nicolas George nous expliquait dans fr.comp.os.linux.debats (<58049d5a$0$7996$) :
On aboutit à l'abandon des scripts, on retourne à un binaire qui supervise les lancements des programmes au boot avec une syntaxe propre à lui même. Ca vous rappelle /sbin/init? moi aussi.
Très bon résumé. Évidemment, quand on refait from scratch quelque chose qui a trente ans d'histoire, on ne peut pas espérer avoir un résultat parfait tout de suite.
Mais _pourquoi_ intégrer un truc clairement pas sec ? Pourquoi faire la sourde oreille quand on ose poser la question ?
Parce que le débat ne peut exister. Ce truc est _forcément_ meilleur _par construction_. Ceux qui prédentent le contraire sont des incroyants.
Il n'y avait pas une urgence absolue à intégrer une bouse pareille, on aurait pu attendre 5 ou 10 ans que quelques distributions aventureuses s'y casse les dents, ce n'était pas si grave.
Remarque bien, on a vu ce que cela a donné dans Solaris 10. De Solaris 5 à 9, il y avait un système de démarrage éprouvé, façon SysV (sous SunOS 4, il me semble de mémoire que c'était du BSD, mais j'ai comme un doute et j'ai éteint ma denière installation de 4.1.3 il y a déjà quelques années). Sous Solaris 10, on a un truc avec des scripts enregistrés dans une base SQLite qu'il faut marabouter dès qu'on veut ajouter un daemon. Et c'est tellement plantogène que même les patches de Sun^WOracle finissent par le mettre en vrac.
Il ne reste désormais plus qu'à avoir un systemd monolithique dont le rôle sera de lancer un /bin/rc.script qui possèdera plusieurs runlevel, et qui pour plus de souplesse lancera des scripts (shells? d'un autre langage de script? Powershell? perl? l'avenir nous le dira). Puis on verra revenir des liens symboliques, des superviseurs légers, des spaghettis, etc etc... Et puis des gens diront qu'il faut faire quelque chose, que ce n'est plus possible ces scripts, c'est le bordel.
Justement, le fait d'incorporer assez de logique dans /sbin/init permet de ne pas avoir besoin des scripts en plus.
Même pas j'y crois. Enfin si je veux ben croire que les scripts ne sont plus nécessaires mais je ne crois pas qu'il n'y aura pas un jour un gars qui se lèvera un matin en disant "Hey les gars, j'ai une super idée, ajoutons des scripts" et d'autres gars de le suivre avec cet enthousiasme teinté de fanatisme qui caractérise si bien les inconscients et les fanboys.
Et c'est comme ça qu'on se retrouve avec un interprète Lua dans le noyau NetBSD. Bon, c'est moins pire que ce qu'il se passe avec les initrd, busybox et consorts sous Linux lorsqu'on regarde bien. JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Le Mon, 17 Oct 2016 10:12:51 +0000 (UTC),
Doug713705 <doug.letough@free.fr> écrivait :
Le 17-10-2016, Nicolas George nous expliquait dans
fr.comp.os.linux.debats
(<58049d5a$0$7996$426a34cc@news.free.fr>) :
On aboutit à l'abandon des scripts, on retourne à un binaire qui
supervise les lancements des programmes au boot avec une syntaxe
propre à lui même. Ca vous rappelle /sbin/init? moi aussi.
Très bon résumé.
Évidemment, quand on refait from scratch quelque chose qui a trente ans
d'histoire, on ne peut pas espérer avoir un résultat parfait tout de suite.
Mais _pourquoi_ intégrer un truc clairement pas sec ?
Pourquoi faire la sourde oreille quand on ose poser la question ?
Parce que le débat ne peut exister. Ce truc est _forcément_ meilleur
_par construction_. Ceux qui prédentent le contraire sont des
incroyants.
Il n'y avait pas une urgence absolue à intégrer une bouse pareille, on
aurait pu attendre 5 ou 10 ans que quelques distributions aventureuses
s'y casse les dents, ce n'était pas si grave.
Remarque bien, on a vu ce que cela a donné dans Solaris 10. De
Solaris 5 à 9, il y avait un système de démarrage éprouvé, façon
SysV (sous SunOS 4, il me semble de mémoire que c'était du BSD, mais
j'ai comme un doute et j'ai éteint ma denière installation de 4.1.3
il y a déjà quelques années). Sous Solaris 10, on a un truc
avec des scripts enregistrés dans une base SQLite qu'il faut
marabouter dès qu'on veut ajouter un daemon. Et c'est tellement
plantogène que même les patches de Sun^WOracle finissent par le
mettre en vrac.
Il ne reste désormais plus qu'à avoir un systemd monolithique dont
le rôle sera de lancer un /bin/rc.script qui possèdera plusieurs
runlevel, et qui pour plus de souplesse lancera des scripts (shells?
d'un autre langage de script? Powershell? perl? l'avenir nous le dira).
Puis on verra revenir des liens symboliques, des superviseurs légers,
des spaghettis, etc etc... Et puis des gens diront qu'il faut
faire quelque chose, que ce n'est plus possible ces scripts, c'est
le bordel.
Justement, le fait d'incorporer assez de logique dans /sbin/init permet de
ne pas avoir besoin des scripts en plus.
Même pas j'y crois. Enfin si je veux ben croire que les scripts ne sont
plus nécessaires mais je ne crois pas qu'il n'y aura pas un jour un gars
qui se lèvera un matin en disant "Hey les gars, j'ai une super idée,
ajoutons des scripts" et d'autres gars de le suivre avec cet
enthousiasme teinté de fanatisme qui caractérise si bien les
inconscients et les fanboys.
Et c'est comme ça qu'on se retrouve avec un interprète Lua dans le
noyau NetBSD. Bon, c'est moins pire que ce qu'il se passe avec les
initrd, busybox et consorts sous Linux lorsqu'on regarde bien.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Le Mon, 17 Oct 2016 10:12:51 +0000 (UTC), Doug713705 écrivait :
Le 17-10-2016, Nicolas George nous expliquait dans fr.comp.os.linux.debats (<58049d5a$0$7996$) :
On aboutit à l'abandon des scripts, on retourne à un binaire qui supervise les lancements des programmes au boot avec une syntaxe propre à lui même. Ca vous rappelle /sbin/init? moi aussi.
Très bon résumé. Évidemment, quand on refait from scratch quelque chose qui a trente ans d'histoire, on ne peut pas espérer avoir un résultat parfait tout de suite.
Mais _pourquoi_ intégrer un truc clairement pas sec ? Pourquoi faire la sourde oreille quand on ose poser la question ?
Parce que le débat ne peut exister. Ce truc est _forcément_ meilleur _par construction_. Ceux qui prédentent le contraire sont des incroyants.
Il n'y avait pas une urgence absolue à intégrer une bouse pareille, on aurait pu attendre 5 ou 10 ans que quelques distributions aventureuses s'y casse les dents, ce n'était pas si grave.
Remarque bien, on a vu ce que cela a donné dans Solaris 10. De Solaris 5 à 9, il y avait un système de démarrage éprouvé, façon SysV (sous SunOS 4, il me semble de mémoire que c'était du BSD, mais j'ai comme un doute et j'ai éteint ma denière installation de 4.1.3 il y a déjà quelques années). Sous Solaris 10, on a un truc avec des scripts enregistrés dans une base SQLite qu'il faut marabouter dès qu'on veut ajouter un daemon. Et c'est tellement plantogène que même les patches de Sun^WOracle finissent par le mettre en vrac.
Il ne reste désormais plus qu'à avoir un systemd monolithique dont le rôle sera de lancer un /bin/rc.script qui possèdera plusieurs runlevel, et qui pour plus de souplesse lancera des scripts (shells? d'un autre langage de script? Powershell? perl? l'avenir nous le dira). Puis on verra revenir des liens symboliques, des superviseurs légers, des spaghettis, etc etc... Et puis des gens diront qu'il faut faire quelque chose, que ce n'est plus possible ces scripts, c'est le bordel.
Justement, le fait d'incorporer assez de logique dans /sbin/init permet de ne pas avoir besoin des scripts en plus.
Même pas j'y crois. Enfin si je veux ben croire que les scripts ne sont plus nécessaires mais je ne crois pas qu'il n'y aura pas un jour un gars qui se lèvera un matin en disant "Hey les gars, j'ai une super idée, ajoutons des scripts" et d'autres gars de le suivre avec cet enthousiasme teinté de fanatisme qui caractérise si bien les inconscients et les fanboys.
Et c'est comme ça qu'on se retrouve avec un interprète Lua dans le noyau NetBSD. Bon, c'est moins pire que ce qu'il se passe avec les initrd, busybox et consorts sous Linux lorsqu'on regarde bien. JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Jo Engo
Le Mon, 17 Oct 2016 08:50:51 +0000, JKB a écrit :
accès 999
C'est un peu comme AAA en base dix ?
Faut de tout urgence t'acheter une calculette hexadécimale...
hexadécimal _en base 10_ -- Nous n'héritons pas la terre de nos ancêtres, nous l'empruntons à nos enfants. -+- Antoine de Saint-Exupéry (1900-1944) -+-
Le Mon, 17 Oct 2016 08:50:51 +0000, JKB a écrit :
accès 999
C'est un peu comme AAA en base dix ?
Faut de tout urgence t'acheter une calculette hexadécimale...
hexadécimal _en base 10_
--
Nous n'héritons pas la terre de nos ancêtres, nous l'empruntons à nos
enfants.
-+- Antoine de Saint-Exupéry (1900-1944) -+-
Faut de tout urgence t'acheter une calculette hexadécimale...
hexadécimal _en base 10_ -- Nous n'héritons pas la terre de nos ancêtres, nous l'empruntons à nos enfants. -+- Antoine de Saint-Exupéry (1900-1944) -+-
Kevin Denis
Le 17-10-2016, David Sarella a écrit :
Et y a-t-il un projet visant à surveiller le plantage du surveillant systemd ?
oui, avec -1 comme PID.
Qui lui même est surveillé par un process de PID -2. Soyons précis. -- Kevin
Le 17-10-2016, David Sarella <oldchap@remote.cispeo.fr> a écrit :
Et y a-t-il un projet visant à surveiller le plantage du surveillant
systemd ?
oui, avec -1 comme PID.
Qui lui même est surveillé par un process de PID -2.
Soyons précis.
--
Kevin
