Qui va remplacer SysVinit ?

Posté par  (site Web personnel) . Modéré par Florent Zara.
Étiquettes :
0
29
août
2006
Linux
Selon l'article "Upstart in Universe" (second lien), Ubuntu travaille actuellement sur Upstart, un nouveau démon chargé de lancer et stopper les processus, pour remplacer l'actuel SysVinit utilisé dans la plupart des distributions Linux. Il existe également d'autres projets :
  • initng : cependant, Ubuntu souhaite un démon dynamique qui ne nécessite aucune politique de démarrage prédéfinie ; avec initng, Il faut définir explicitement la liste des dépendances alors qu'Upstart est bien plus autonome ;
  • pinit : intégré par Mandriva dans sa Mandriva 2007, actuellement en version beta ; pinit ne casse pas la compatibilité avec le SystemV et permet de démarrer les daemons en parallèle, faisant gagner ainsi 20 secondes au démarrage ; les derniers problèmes de mise au point semblent résolus et pinit est désormais opérationnel ; de plus pinit ne rompt pas la compatibilité LSB ;
  • launchd : le système d'Apple sous licence APSL ;
  • SMF : le système de Sun.

Selon l'auteur, la solution d'Ubuntu Upstart conservera la compatibilité avec les scripts actuels. La seule question à laquelle l'article ne répond pas, c'est la date de sortie du logiciel. Edgy est fortement pressentie, mais rien n'est encore définitif. On peut supposer que cela sera de toute façon prêt pour la version Edgy+1.

On se posera effectivement la question de la normalisation LSB si le système qui sera adopté le plus massivement est incompatible avec les normes actuellement en vigueur.

Aller plus loin

  • # Pour ma part...

    Posté par  . Évalué à 5.

    Pour ma part je pense que tout dépendra des performances obtenues.
    Si initng reste grand maître dans ce secteur, d'autant plus qu'il est bien plus mature que les autres, il pourrait être choisi à long terme.

    Mais pour le moment, il vaut mieux préférer la compatibilité jusqu'à que le monde soit prêt à rompre avec les anciens standards au prix de meilleures performances.
    • [^] # Re: Pour ma part...

      Posté par  (site Web personnel) . Évalué à 9.

      Je peux répondre pour pinit. Sur ma machine de test, Mandriva 2005 boote en 97s avec un init standard. Mandriva 2007 en version beta boote en 72s.
      Une amélioration a été aussi apportée à KDE dont le lancement passe de 25s à 12s.

      Ma machine de test est un Pentium 4 avec 512Mo de RAM. Pendant le boot, il n'y a plus de temps mort, le CPU et le disque sont très bien utilisés. Pour le voir, l faut utiliser BootChart http://www.bootchart.org/

      Plus d'informations sur le wiki Mandriva http://qa.mandriva.com/twiki/bin/view/Main/BootTimeOptimisat(...) où l'on pourra voir les graphiques avant et après pinit.
      • [^] # Re: Pour ma part...

        Posté par  (site Web personnel) . Évalué à 10.

        Je viens d'avoir (trop tard pour les intégrer dans l'article) un supplément d'informations de la part de Couriousous l'auteur de pinit :

        - Pinit n'est pas le vrais nom de l'amélioration, le vrais nom de l'executable
        est "prcsys".

        - Prcsys ne remplace pas l'init SysV, il ajoute la possibilité de démarrer les
        services ayant une entête LSB en parallèle. On peut le désactiver et retrouver
        l'initialisation traditionelle très facilement. Je le vois plus comme une
        amélioration se basant sur les possibilité du standard LSB.

        Pour les 20 secondes, je sens déja le troll gronder :) il est hautement
        variable en fonction de la machine et des services activés.

        Ha, au fait, si vous mettez des liens pour les différentes implémentations,
        http://www.zarb.org/~couriousous/boot/ est pas a jour et donne une ancienne
        version du code. Mettez plutot l'adresse du SVN:
        http://zarb.org/users/svn/trem/prcsys/trunk/
      • [^] # Re: Pour ma part...

        Posté par  . Évalué à 4.

        Je suis le seul à trouver que 90 secondes, et meme 70 secondes, c'est énorme, comme temps de démarrage, surtout sur une machine qui a l'air assez récente !!! ??? !!!

        Enfin, si tu parles de KDE, c'est que tu démarres aussi KDM, et que c'est compté dans le temps de démarrage ???

        En parallèle à ca, je suis à peu près sur qu'une news ici qui dirait "Windows met maintenant moins de 60 secondes pour booter", tout le monde incendierait en disant que 60 secondes c'est énorme et que windows c'est nul......

        A +

        VANHU, qui boote ses FreeBSD/NetBSD en moins de 30 secondes sur de vieilles babasses.......
        • [^] # Re: Pour ma part...

          Posté par  . Évalué à 3.

          InitNG offre de bien meilleures performances, mais en attendant, mieux vaut démarrer une fois un système qu'on peut suspendre et laisser tourner des années que rebooter deux fois par jour un système qui démarre vite.
        • [^] # Re: Pour ma part...

          Posté par  (site Web personnel) . Évalué à 2.

          Le temps que j'ai donné est le temps jusqu'à la demande de login de kdm. C'est compté dedans et c'est une machine peu performante par rapport aux actuelles. Il y a 2 disques durs, 2 swaps, 6 partitions et ça prend du temps à monter.

          Pour Windows, le bureau est affiché tôt mais il faut attendre un bon moment après pour que l'on puisse s'en servir. Microsoft triche donc... Surpris ?
          • [^] # Re: Pour ma part...

            Posté par  (site Web personnel) . Évalué à 4.

            Pour Windows, le bureau est affiché tôt mais il faut attendre un bon moment après pour que l'on puisse s'en servir.

            Oui, et c'est très désagréable d'avoir une interface qui semble prête... mais qui ne répond pas - au moins quand l'interface de KDE démarre, on a un spash screen avec un feedback de progression.

            Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

            • [^] # Re: Pour ma part...

              Posté par  . Évalué à 5.

              Qui sait, peut-être que dans Vista le bootsplash ça sera un screenshot du bureau, y aura un tas de gens qui croiront que c'est le vrai bureau et que Vista est supérieur car il démarre en 3 secondes...
        • [^] # Re: Pour ma part...

          Posté par  . Évalué à 4.

          Je suis le seul à trouver que 90 secondes, et meme 70 secondes, c'est énorme, comme temps de démarrage

          Je suis entièrement d'accord mais je n'avais pas osé commenter sur le sujet, et j'ajoute que le temps de démarrage de KDE me semble délirant aussi (chez moi comme chez Pierre), 12 s c'est un superbe progrès par rapport à 25, mais j'ai du mal à comprendre un tel temps.

          La réflexion que je ne peux m'empêcher de faire, même si elle n'est peut-être pas totalement pertinente, c'est qu'on est allé sur la lune avec des machines 1000 fois moins puissantes. J'ai écrit 1000 mais c'est bien plus. On doit bien être capable de programmer une interface graphique qui démarre en quelques secondes, même si de nos jours on utilise plus de couches d'abstraction.

          Je suspecte que les mecs qui ont codé KDE (et l'environnement qui va avec, toutes les libs) n'ont pas fait très optimal. Le fait qu'on a pu réduire de moitié le temps de démarrage l'indique déjà. Côté GNOME ça n'a pas l'air mieux, pour cela il suffit de se référer à la présentation de Dave Jones intitulée "On how user space sucks", cf par ex http://lwn.net/Articles/192214/ . La présentation est disponible par ex chez RedHat directement http://ols2006.108.redhat.com/reprints/jones-reprint.pdf (158 K) ou bien au sein de ce PDF de 6-7 Mo http://www.linuxsymposium.org/2006/linuxsymposium_procv1.pdf (pages 441 à 449). On y voit que HAL et X11 ne sont pas non plus optimaux, ce qui n'aide pas.
          • [^] # Re: Pour ma part...

            Posté par  . Évalué à 2.

            La réflexion que je ne peux m'empêcher de faire, même si elle n'est peut-être pas totalement pertinente, c'est qu'on est allé sur la lune avec des machines 1000 fois moins puissantes.

            Ouais, on est allé sur la lune, ca c'est ce que la NASA affirme :)
            • [^] # Re: Pour ma part...

              Posté par  . Évalué à 3.

              Ouais, on est allé sur la lune, ca c'est ce que la NASA affirme :)

              C'est clair, je demande à voir les vidéos originales !
              • [^] # Re: Pour ma part...

                Posté par  . Évalué à 1.

                1000 fois moins puissant certes, mais si je me souvient bien Le système "laguait" tellement que l' alunissage a du être fait en commande manuelle... Bon, moi je vais pas sur la lune alors...
          • [^] # Re: Pour ma part...

            Posté par  . Évalué à 5.

            le temps de chargement, c'est proportionnel aux nombres de trucs qui sont démarrés. Tu peux faire booter un linux en une poignée de secondes avec un environnement plus léger.

            Mais Gnome et KDE gèrent et préchargent des tonnes de trucs. En plus si tu y ajoutes quelques applets sur ton bureau, que l'une soit codée en python, une autre en Perl, une autre en ruby ou mono et java et pouf, tu dois lancer 5 VM en même temps !

            Bref, tout est question de ce que tu veux au démarrage, c'est identique au dilemme qui se pose entre activer l'autostart d'openoffice ou pas. Soit tu attends gentillement le matin que tout se lance en arrivant au bureau en prenant ton café parce que tu sais que tu l'utilises de toute façon tout le temps et tu veux qu'il s'ouvre instantanément en cas de besoin, soit tu décides que tu peux te permettre un temps de chargement d'openoffice plus long parce que tu n'utilises openoffice qu'une fois de temps en temps.
            • [^] # Re: Pour ma part...

              Posté par  . Évalué à 1.

              Mais Gnome et KDE gèrent et préchargent des tonnes de trucs. En plus si tu y ajoutes quelques applets sur ton bureau,

              En effet, mais dans mon cas, je n'ai que 2 applets de chargées, toutes les 2 appartenant à l'environnement KDE normal, dont une qui indique qu'on est connecté au réseau.
              Je n'ai pas essayé de les virer, mais du temps où je démarrais uniquement avec l'applet réseau, je ne crois pas que c'était beaucoup plus rapide.

              C'est comme le temps de lancement d'un Konqueror, c'est pas super rapide non plus, et ça ne me paraît pas justifié (au fait j'ai un Athlon64 2800+ et 1 Go de mémoire, ce n'est quand même pas une brouette à l'heure actuelle). J'ai bien entendu une page blanche comme page de démarrage.
              • [^] # Re: Pour ma part...

                Posté par  . Évalué à 1.

                C'est comme le temps de lancement d'un Konqueror, c'est pas super rapide non plus, et ça ne me paraît pas justifié (au fait j'ai un Athlon64 2800+ et 1 Go de mémoire, ce n'est quand même pas une brouette à l'heure actuelle)


                Je pense que le proc et la mémoire ne sont pas si importantes pour le lancement des programmes : j'ai un pIII 600 MHz et 192 Mo de mémoire, et ça mets pas énormement plus de temps que sur une machine plus récente (surtout que dans le cas de konqueror, je dois aussi charger les librairies KDE)
          • [^] # Re: Pour ma part...

            Posté par  . Évalué à 1.

            On doit bien être capable de programmer une interface graphique qui démarre en quelques secondes, même si de nos jours on utilise plus de couches d'abstraction.


            Mais ça existe depuis longtemps : sawfish démarre en moins de 4 secondes. Et je suppose que ion, ratpoison et autres wmaker en font autant.
  • # D'autres opinions ?

    Posté par  . Évalué à 3.

    L'annonce d'upstart détaille bien les raisons de leur choix est très intéressante. Connaissez vous d'autres articles ayant aussi détaillés présentant et comparant différentes approches et ayant des conclusions différentes ?

    Je sais que Fedora aussi a l'air de réfléchir au sujet mais s'ils détaillent l'existant ils sont plutôt laconiques concernant les alternatives sur leur wiki :
    http://fedoraproject.org/wiki/FCNewInit
  • # Normalisation avec la LSB et ... avec Debian?

    Posté par  . Évalué à 2.

    Quelle est la vision Debian de ce "probleme" ?
    J'ose esperer que Ubuntu et Debian vont negocier afin de choisir le meme systeme d'init.
  • # rc.d

    Posté par  (site Web personnel) . Évalué à 6.

    Il y a aussi le système rc.d de netbsd, qui est assez élégant

    http://www.usenix.org/events/usenix01/freenix01/full_papers/(...)
    http://www.mewburn.net/luke/talks/auug-2003/

    et fait pas mal de trucs sympas, comme ordonner tout seul les dépendances.
    De plus, il n'a que très peu de dépendances et peut fonctionner a peu près partout
  • # launchd : APSL ?

    Posté par  . Évalué à 0.

    il me semble que maintenant le projet d'apple : launchd est sous licence Apache Version 2.

    source : http://launchd.macosforge.org/
    • [^] # Re: launchd : APSL ?

      Posté par  . Évalué à 1.

      oui mais c'est arrivé trop tard et les développeurs de startup n'ont plus de raison d'arrêter leur développement.
      • [^] # Re: launchd : APSL ?

        Posté par  (site Web personnel) . Évalué à 5.

        > les développeurs de startup n'ont plus de raison d'arrêter leur développement.

        Superbe lapsus :).

        Sinon, les dévelopeurs d'upstart ne veulent pas faire un clone de launchd, bien que le concept central soit le même, à savoir réagir aux évènements. cependant upstart n'a pas les même contraintes que launchd : compatibilité, environnement très différent (notamment au niveau du partitionnement). Bref, upstart va plus loin que launchd, quelleque soit la licence de ce dernier.
        • [^] # Re: launchd : APSL ?

          Posté par  . Évalué à -2.

          je vais re répondre

          >> les développeurs de startup n'ont plus de raison d'arrêter leur développement.
          >Superbe lapsus :)."

          clarifions ma pensée parce qu'on me prête un lapsus je ne sais où

          Les développeurs de Startup ont DEJA répondu au changement de licence de Launchd
          en disant que NON ils n'arrêteront PAS le travail sur Startup
          parce que
          1 : startup est dèjà très avancé
          2 : si launchd avait eu une meilleure licence dés son début , certainement ils auraient cherché à y contribuer. Maintenant c'est TROP TARD
          3 : comme c'est expliqué dans le blog d'un des développeurs (qui est dans planet.ubuntu.com) , Startup est devenu plus sophistiqués, ne se contente pas d'un système de dépendance mais d'un système événementiel.


          Bref, il n'y avait pas de lapsus. j'ai simplement écrit une phrase maladroite incompréhensible. (très pratique dans un forum).

          les développeurs "n'ont plus" de raison d'arrêter parce que Startup est maintenant capable de faire ce que fait Launchd, voir plus. il y a 6 mois ou 1 an ç'aurait été différent. Mais maintenant ils N'ont PLUS de raison de changer d'avis.
          voilà ce que je sous-entendais (dans ma tête).
  • # "limitations de sh"

    Posté par  . Évalué à 1.

    Les scripts shell ont l'avantage indéniable d'être simple et léger. Par contre je préfère passer à Perl pour les scripts plus complexe. Pour initd je pense surtout a un affichage évolué, "echo" n'est pas ce qui a de plus élégant pour la couleur, l'indentation ... Mais j'imagine mal démarrer sur Perl ou Python. Un Perl léger me plairait bien.
    • [^] # Re: "limitations de sh"

      Posté par  (site Web personnel) . Évalué à 10.

      puis c'est facile à apprendre en plus. Tout le monde vient au monde en sachant coder en perl, c'est comme l'instinc, c'est dans les gènes.
      • [^] # Re: "limitations de sh"

        Posté par  . Évalué à 2.

        Je dis on fait tout en lisp, on oublie les affichages graphiques et on met tout en bleu ciel sur fond vert pomme pour bien peter les yeux le matin au reveil.

        Sinon vous croyez vraiment qu'un langage sera plus adapté qu'un autre? On aura toujours le conflit rapidité <> lisibilité. Apres c'est suivant la logique de la dsitrib, non?
    • [^] # Re: "limitations de sh"

      Posté par  . Évalué à 2.

      Pour initd je pense surtout a un affichage évolué, "echo" n'est pas ce qui a de plus élégant pour la couleur
      Rien n'empeche d'appeler une autre commande gérant mieux la couleur ou de te definir des fonctions que tu reutiliser pour tous les affichages (c''est plus ou moins ce qui est fait).

      , l'indentation ...

      C'est sur que perl est mieux indenté que sh....
      • [^] # Re: "limitations de sh"

        Posté par  . Évalué à 3.

        Quitte à troller... autant démarrer une machine virtuelle Java dans Xen, ou bien démarrer en Ruby :-)

        Ceci dit, du moment que le bouzin démarre plus vite, qu'il est un minimum propre, un minimum souple et que la distrib' gère les paquets, peu importe la solution choisie.
        • [^] # Re: "limitations de sh"

          Posté par  . Évalué à 1.

          >>Quitte à troller... autant démarrer une machine virtuelle Java dans Xen, ou bien démarrer en Ruby :-)>>

          Et alors : m0n0wall et Freenas démarrent bien en PHP, initiative très intéressante, puisque des scripts de démarrage jusqu'à l'interface il n'y a plus qu'un seul langage à maîtriser...
  • # Bah, et daemontools ?

    Posté par  (site Web personnel) . Évalué à 0.

    Pourquoi ne pas utiliser Daemontools ?

    http://cr.yp.to/daemontools.html

    C'est que j'en ai marre de le recompiler à la mimine sur tout mes serveurs.

    (quoi, une odeur de troll ? J'ai meme pas parlé de qmail là).
    • [^] # Re: Bah, et daemontools ?

      Posté par  . Évalué à 1.

      Pour ceux qui n'auraient pas suivi la partie "troll", c'est justement parceque ca serait compliqué de devoir le recompiler sur toutes les machines (ce qu'impose la licence, entre autres choses), que c'est pas utilisé......

      Et tant qu'on y est, pourquoi on démarre pas avec un .bat, qui lancerait une interface graphique qui lirait tout ce qu'il faut dans une grosse base de registre binaire avant de tout lancer......

      Nan, trop novateur, passera pas..... ;-)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.