Journal Init-ng est encore vivant !

Posté par (page perso) .
Tags : aucun
16
3
sept.
2009
Bonjour,

Init-ng est un remplacement du vieillissant System V init utilisé entre autre par les ordinateurs sous Linux pour démarrer.

La particularité d'init-ng, comme les autres remplaçants de SysVinit est de lancer les processus et démons non pas dans un ordre bien défini et les uns à la suite des autres, mais en parallèle et en fonction de dépendances.

Un autre avantage d'init-ng est qu'il n'utilise pas de scripts shell, mais des fichiers .i bien à lui. Bien sûr, il faut réécrire les scripts de démarrage pour les porter vers init-ng, mais une fois réécrits, ils sont bien plus rapides ! En effet, charger, pour chaque démon, un shell bash et un peu lourd. Debian avait avancé dans ce domaine en remplaçant Bash par Dash, ce qui amène déjà une grosse amélioration.

Les présentations étant faites, venons-en au fait. Il y a quelques semaines, j'ai fait quelques recherches sur un remplaçant du vieux init. Je suis tombé sur pas mal de résultats, dont beaucoup parlaient d'init-ng. J'essaie de trouver son site, mais pas moyen d'y arriver, il est down.

Les dernières activités d'init-ng (paquets Debian, trolls en sa faveur, etc) remontaient aux environs de 2005, comme souvent (c'est la sortie d'Ubuntu qui a tué le Libre de cette sorte ou quoi ? Plus de 50% des projets moyens s'arrêtent aux environs de sa sortie, comme sawfish, initng, Mandriva (qui a eu des problèmes mais qui se redresse), et même linuxfr qui était plus actif). Je pensais donc que le projet devait être mort et enterré depuis longtemps, avec tristesse (upstart, bon voilà quoi).

Et bien, j'avais faux ! Il y a deux ou trois jours, je retente d'accéder au site, en désespoir de cause. Et là, il marche, et même bien !

J'apprends que le développement a toujours continué, très fortement au ralenti. On peut même observer que le forum est couvert de spams, mais néanmoins, ce qui reste de la communauté (donc juste le mainteneur) a entamé ... une migration vers Git !

Ça, c'est bien commencer une semaine. Voir init-ng renaître de la sorte fut un grand plaisir, surtout que j'avais eu l'occasion de le tester (et effectivement, c'est bluffant de démarrer en 5 secondes (sans compter le kernel)). Je vois qu'il prépare même une version 0.7.0, mais sans avoir fixé de date.

Voilà, c'est tout ce que j'ai à dire. Testez init-ng, c'est intéressant. Pas mal de scripts sont fournis pour démarrer tous les services que vous voulez, et c'est assez stable. Aussi, plus du monde s'intéressera à init-ng, moins son mainteneur risque de partir.

Montrez tous que vous voulez un vrai système d'init, autre-chose que de simples scripts shell, quelque-chose d'intelligent, et plus léger qu'upstart !

PS: Oui il existe l'init des BSD, mais c'est aussi un script shell.
  • # Pinit

    Posté par (page perso) . Évalué à 7.

    Ne pas oublier l'implémentation Mandriva: pinit/prcsys pour la gestion du lancement de scripts en parallèle. Utilisé depuis janvier 2006 par défaut.
    http://wiki.mandriva.com/en/Development/Howto/Pinit
  • # bsd

    Posté par (page perso) . Évalué à 7.

    > PS: Oui il existe l'init des BSD, mais c'est aussi un script shell.

    ça ne me pose pas de problème de booter ma netbsd en 15s, kernel compris
    • [^] # Re: bsd

      Posté par (page perso) . Évalué à 10.

      En même temps, 15s rien que pour démarré le grille-pain, c'est long.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: bsd

        Posté par . Évalué à 0.

        Et puis si tu veux ton faire ton BSDien barbu fanatique et cranner avec ta BSD qui démarre en 15s, sache que le fils de madame michou à son ubuntu qui démarre en 14s, et là, tu as grave les boules!!!

        Bref le sujet c'était pas qui démarre le plus vite c'était juste de montrer qu'il existe des alternatives prometteuses qui pourrons surement encore accélérer le démarrage de nos pc.
        • [^] # Re: bsd

          Posté par (page perso) . Évalué à 1.

          marrant, j'aurait pas associé le verbe "cranner" avec "BSDien barbu fanatique", alors qu'avec un prébubère sur son Ubuntu thême linsta compiz fusion, j'imagine que ça colle plutôt bien.

          Bref le sujet c'est que la description d'initng sur la page du projet c'est que c'est pour acceler le boot, donc on parle bien de "démarrer plus vite", ne t'en déplaise, et bien que je trouve important d'avoir des alternatives, je n'ai pas envie, ne trouve pas d'interet, à changer d'init actuellement.

          remarque que c'est à peut pres pareil sur ma Debian avec dash, modulo que tous les services installés sont quasi toujours lancés par défaut à chaque boot (et que sur une machine de boulot t'es tenté de tester etc, donc beaucoup de services) alors que sous NetBSD faut le vouloir.
          • [^] # Re: bsd

            Posté par . Évalué à 1.

            ouai le sujet c'est bien " démarrer plus vite " mais pas " QUI démarre le plus vite" (genre c'est moi qui ai la plus grosse).
            Sinon c'est juste histoire de placer une boutade.
            mais encore un truc me turlupine : Es-tu barbu ?
            • [^] # Re: bsd

              Posté par (page perso) . Évalué à 3.

              on est bien d'accord. Je ne dis pas que j'ai la plus grosse (d'ailleurs 15s c'est acceptable mais pas des meilleurs timings), mais que ça me suffit, que ça me convient.

              et pour répondre à ta question: non, je ne suis pas barbu. Du tout :)
              • [^] # Re: bsd

                Posté par . Évalué à 4.

                moi 15s ca me convient mais ca suffi pas quand tu voi les vidéo qui traine sur le net d'un eepc qui boot en 5s la ca commence a etre suffisant (ca, ca n'est qu'une question de point de vue).

                Sinon pour la barbe je suis déçu!! les valeurs se perdent de nos jour!!

                ca devient n'importe quoi ce commentaire (ca doit etre le vendredi)...
  • # Script shell

    Posté par (page perso) . Évalué à 10.

    Moi j'aime bien les scripts shell. On a ainsi un système souple qui se modifie facilement. Il est aussi facile de deboguer un script....

    Pour moi, une grande force d'UNIX est justement d'avoir encore plein de bout de sa config qui se font en script (BASH pour la plupart). Je ne suis pas sur que mettre de la syntaxe avec du méta langage permettent à terme une telle souplesse et une telle durée de vie.

    On peu avoir un init en script qui soit parallèle...
    • [^] # Re: Script shell

      Posté par (page perso) . Évalué à 7.

      Un script shell, c'est lent (quand on voit que Debian en passant de Bash à Dash m'a fait gagner 8s au boot, alors que je n'avais que peu de services, ça fait réfléchir).

      Et puis, qu'est-ce qu'il y a de mal là-dedans ?


      service system/usplash {
      exec start = /bin/true;
      exec stop = /sbin/initng-usplash-shutdown;
      }


      C'est simple, rapide à parser, et ça évite de réinventer la roue (pas mal de scripts init standards commencent par une définition de $PATH, contiennent le fameux swtich pour start, stop, reload, etc).
      • [^] # Re: Script shell

        Posté par . Évalué à 9.

        dash reste du script shell, et un script shell restera extrêmement souple;

        si dans un service, je ne sais pas moi, timidity, par exemple, je souhaite ajouter une commande en plus de start/stop/status/restart, que pour le plaisir de l'exemple j'appellerai balsa qui me redémarrerai le service avec un backend alsa ( ou pulseaudio si il est déjà en alsa), il va falloir que le système remplaçant les script me le permette (et ce n'est qu'une subtilité parmi tant d'autre...).

        Alors oui y a moyen de faire accélérer le schmilblik, y a même pleins de piste explorée (remplacer bash par dash, supprimer au maximum les appels aux fonctions externes (remplacer les basename et dirname par leur équivalent en bash), ne pas recharger 50 fois le même PATH

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

        • [^] # Re: Script shell

          Posté par (page perso) . Évalué à 10.

          Entre Dash et la lessive Linux il faut choisir !
        • [^] # Re: Script shell

          Posté par (page perso) . Évalué à 4.

          Il y a aussi un avantage, chaque script est un processus indépendant... En cas de plantage, bogue, on a une très grande indépendance des services les uns par rapport aux autres.

          Moi je suis pour rester simple, orthogonal, indépendant... Cela permet la robustesse mais aussi l'évolution.
      • [^] # Re: Script shell

        Posté par . Évalué à 5.

        Le problème de cette conf, c'est que tu dépends totalement d'init-ng, tu ne peux pas le remplacer par un autre système d'init sans te retaper toute la conf. Avec des scripts shell d'init, tu peux remplacer par le shell que tu veux (enfin pas tout à fait à cause des bashismes qui ne se voient souvent que quand le système ne boote plus)
        • [^] # Re: Script shell

          Posté par . Évalué à 5.

          je dirais même plus, ce n'est pas compatible LSB. Est-ce qu'il existe un système dans init-ng pour lancer un script d'init standard shell, compatible LSB ? si oui ça ne coute rien de migrer, il suffira de migrer progressivement les scripts d'init paquet par paquet.

          Dans le cas contraire, t'es pas prêt de voir ça par défaut dans les distributions (ou alors, pas dans une distrib que j'installerais dans un cadre pro).

          Quand c'est un script shell, même si c'est pas compatible LSB au moins c'est facile de rajouter la compatibilité. Là tout le travail est dans les mains de la distribution (les mainteneurs upstream se donne rarement la peine de faire des scripts d'init pour d'autres distributions que celle qu'ils utilisent ou qu'on leur a contribués, alors des scripts pour des système alternatifs)...
        • [^] # Re: Script shell

          Posté par (page perso) . Évalué à 2.

          Pas tout-à-fait...

          Tu te retrouve à dépendre d'un logiciel compatible avec les scripts init-ng au lieu de dépendre d'un système ayant un shell compatible bourne.
          Bien sûr, pour l'instant il y a plus de réimplémentations du bourne shell que de init-ng, mais est-ce une preuve que techniquement c'est mieux ?
          • [^] # Re: Script shell

            Posté par . Évalué à 2.

            Le format de conf d'init-ng me semble moins enclin à devenir interopérable que sh (qui dispose de specs, qui n'évolue pas, etc.).
            Puis pour le troll du vendredi, les formats style xml/yaml diminuent le problème de la syntaxe de la conf qui peut changer tout le temps, mais il reste le problème de la sémantique du contenu de la conf.
      • [^] # Re: Script shell

        Posté par . Évalué à -4.

        Ces histoires de gagner 5 ou 10 secondes au bootça me fait bien rire ..... Pour un windows qui plante tout le temps, pourquoi pas mais sur un unix ..... C'est pas censé booter toutes les 15 mn.
        • [^] # Re: Script shell

          Posté par . Évalué à 1.

          mouarf.

          C'est marrant, sous windows ou macos, tout le monde s'en cogne du temps de boot parce que la mise en veille/hibernation marche et que les boots sont donc generalement limites aux updates necessitant un reboot (soit une fois par mois sous windows et je sais pas trop quand sous macos).

          La ou sous linux, tout le monde a tellement la petoche de voir sa sessions exploser en plein vol qu'on est oblige d'eteindre sa machine tous les jours, d'ou l'importance d'un boot rapide.
          • [^] # Re: Script shell

            Posté par . Évalué à 7.

            En tout cas ce n'est pas un GNU/Linux qui demandera de redémarrer totalement la machine pour une mise à jour de navigateur ou de lecteur multimédia.

            Et au passage, j'ai une machine avec macos et l'hibernation bug souvent (sympa le portable qui se réveille tout seul dans un sac et plutôt pratique pour se cuire un steak en arrivant), alors que la même machine avec une debian hiberne sans problème.
            • [^] # Re: Script shell

              Posté par . Évalué à -4.

              En tout cas ce n'est pas un GNU/Linux qui demandera de redémarrer totalement la machine pour une mise à jour de navigateur ou de lecteur multimédia.

              ben voyons.
              Ca a deja ete discute ici longuement.
              Deja ca ne concerne que les updates de secu, faut etre precis, hein ;-)
              De source sur, ni windows ni macos ne requiert un redemarrage apres une update non critique.

              Le probleme est que le navigateur/lecteur (ou plutot ses libs) ont ete mises a jour sur le disque, mais en ram tu as toujours l'ancienne version ('fin si elle est chargee, evidemment).

              Si tu veux faire les choses proprement, tu as deux choix:
              - quitter ta session ou redemarrer (ca revient au meme en pratique)
              - traquer tous les process qui pourraient avoir une dependance sur les libs updates, les fermer proprement et les redemarrer.

              Le premier choix est simple, 100% fiable et (relativement) rapide.
              Le deuxieme est tres complexe a mettre en oeuvre, long et tu risques d'oublier qq chose.

              Conclusion: si ton gnu/linux ne te demande pas de rebooter apres une update de navigateur, c'est que soit l'update etait mineure, soit ta distrib n'inspire pas confiance.

              Quand a ton probleme avec macos, je suis pour le moins dubitatif.
              apres 3 laptops chez eux, le seul qui deconne, c'est mon ibook vieux de 5 ans, qui a un probleme de contact physique ecran ferme (en clair: le capteur qui determine si l'ecran est ferme croit qu'il est ouvert et lance donc la sortie de veille).
              Enquete peut etre de ce cote la...

              Et pour finir, je suis tres content pour toi que l'hibernation fonctionne sur ta debian, mais mon point etait plutot de dire que dans le cas general, c'est plutot casse gueule comme operation, et surtout, on verra si elle marche encore a la prochaine update du kernel, l'hibernation.
              • [^] # Re: Script shell

                Posté par . Évalué à 6.

                Euh...
                Une mise à jour d'un navigateur devrait demander un reboot ?
                C'est une blague ?
                Quand tu mets à jour ton navigateur, pour utiliser le nouveau binaire/les nouvelles libs, tu le relances simplement...que ce soit une mise à jour mineure ou majeure d'ailleurs.
                Pour l'histoire des dépendances sur les libs, déjà les libs d'un navigateur à part le navigateur lui même, je vois pas bien ce qui peut en dépendre, et surtout je vois pas pourquoi ça nécessiterait un reboot.
                Ensuite, dans les cas ou les libs mises à jour sont des dépendances de beaucoup de programmes (je pense à Qt notamment), et bien il suffit de tuer la session X et la relancer, c'est BEAUCOUP moins long qu'un reboot complet.

                Sous Linux, j'ai besoin de rebooter uniquement si j'ai mis à jour le kernel. Le reste c'est pas nécessaire.

                De l'autre côté sous Windows, je viens de réinstaller un XP pour mon père, et le nombre de reboot nécessaire m'a rendu fou: chaque driver installé, certains logiciels (dont Java je crois), les mises à jour évidemment. Le pire, c'est qu'après avoir installé le driver son, j'avais directement du son, mais non il veut qu'on redémarre...
                • [^] # Re: Script shell

                  Posté par . Évalué à 0.

                  et merde, j'ai remit 10 balles dans la machine a troll.
                  Et non, c'est pas une blague du tout.

                  Pour faire court.
                  Pour le navigateur: mon petit doigt me dit que les applications de ton bureau qui affichent du html sous quelque forme que ce soit (aide, composant UI ou que sais je encore) ne vont pas reimplementer un moteur html mais plutot se baser sur celui du systeme.
                  Si ton navigateur est un tant soit peu bien fait, le navigateur en lui meme n'est qu'un front end se basant sur un moteur de rendu.
                  Et les applications tierces vont se baser sur ce moteur pour rendre le html quand elles en ont besoin.

                  Sur une update non triviale, ya de grandes chances pour que le moteur de rendu soit mit a jour.
                  Et pas de bol, la probabilite pour que ton moteur de rendu soit loade par une quelconque appli dans un bureau en utilisation est non negligeable (pour ne pas dire egale a 1).

                  Je sais pas trop comment fonctionne gnome, mais je met ma main a couper qu'une update un tant soit peu consequent a konqueror implique de redemarrer la plupart des applis kde (si ce n'est le bureau entier) pour etre reellement appliquee.

                  et bien il suffit de tuer la session X et la relancer, c'est BEAUCOUP moins long qu'un reboot complet.
                  Ben ca depend ce que tu prend en compte.
                  C'est sur que juste relancer le bureau, c'est assez rapide.
                  Sauver tout mon travail en cours, verifier que tout va bien, quitter, me relogger, relancer le tout, ca va etre vachement plus long par contre, et meme si toujours plus rapide qu'un reboot, ca me demande d'arreter de bosser, context switch tout ca, et au final, redemarrer le bureau ou la machine, je vois pas la difference fondamentale.

                  Sous Linux, j'ai besoin de rebooter uniquement si j'ai mis à jour le kernel. Le reste c'est pas nécessaire.
                  Ah, bien.
                  Et si t'as libssl qui est mit a jour? libxml? libpng? synaptic te patches a chaud la version en ram aussi?
                  • [^] # Re: Script shell

                    Posté par (page perso) . Évalué à 2.

                    Sauver tout mon travail en cours, verifier que tout va bien, quitter, me relogger, relancer le tout, ca va etre vachement plus long par contre

                    Déjà, si tu ne sauvegardes pas régulièrement, tu es mal barré. Coupure de courant, bogue, crac, travail perdu.

                    Quant au temps gagné à éviter de redémarrer, il suffit de voir la différence, déjà sensible, entre un redémarrage matériel et un rechargement du noyau par kexec pour s'en rendre compte.
                    • [^] # Re: Script shell

                      Posté par . Évalué à 1.

                      ....
                      Qu'est ce qu'on ferait pas comme pirouette pour proteger son os cheri d'une remarque pourtant fondee.

                      Bon, si tu veux.

                      Dire a mes contacts sur IM que je doit rebooter, verifier que je suis pas en train de transferer/downloader un fichier qq part, que j'ai pas un collegue connecte sur mon serveur en train de faire qq chose, que j'ai pas un calcul en cours que si je l'interrompt, je repart pour 2h00 de calcul, que j'ai pas un post sur linuxfr non envoye dans un onglet chrome, que j'ai pas des journeaux/depeches ouverts dans linuxfr que si je ferme je vais perdre les nouveaux commentairs, bref, la liste peut etre longue...
                  • [^] # Re: Script shell

                    Posté par . Évalué à 3.

                    Et pas de bol, la probabilite pour que ton moteur de rendu soit loade par une quelconque appli dans un bureau en utilisation est non negligeable (pour ne pas dire egale a 1).

                    À priori ton gestionnaire de packets connait les applications dépendantes de la librairie, donc il est assez simple d'identifier les processus associés. S'il n'est pas capable de lister correctement les applis dépendantes de la mise à jour, tu risques d'avoir pas mal de choses cassées et des problèmes plus sérieux à court terme que la compromission de la sécurité.
                    • [^] # Re: Script shell

                      Posté par . Évalué à 2.

                      oui, il l'a, l'arbre de dependance, maintenant deux choses:
                      - meme si le gestionnaire de paquet a la liste des applis, il ne te la communique pas,
                      - et il ne fait rien pour s'assurer que les applis ont bien ete relancees

                      Et si en plus dans les dependances, t'as un systeme service bas niveau, ben les chances pour devoir redemarrer vont etre tres grandes de toutes facons...

                      note au moinsseurs: je ne fait pas une critique contre linux, j'explique juste pourquoi "je ne doit rebooter que quand le kernel est patche" est faux et dangereux comme raisonnement.
                      • [^] # Re: Script shell

                        Posté par . Évalué à 7.

                        Debian (apt en fait) le propose pour la libc
                • [^] # Re: Script shell

                  Posté par (page perso) . Évalué à 3.

                  Il y a une raison à la nécessité de redémarrer, sous Windows. Ça vient d'une conception assez particulière du noyau, à l'origine : ouvrir un fichier en lecture entraine implicitement son verrouillage exclusif (sauf si on demande explicitement le contraire). Ça s'est avéré être une grosse erreur, parce que ça rend impossible la mise à jour de bibliothèques en utilisation. Donc contournement : on marque qu'il faut le remplacer au démarrage, et on redémarre.
                  • [^] # Re: Script shell

                    Posté par . Évalué à -3.

                    LOL

                    merci pour cette tranche de rire.
                  • [^] # Re: Script shell

                    Posté par . Évalué à 7.

                    Il y a une raison à la nécessité de redémarrer, sous Windows. Ça vient d'une conception assez particulière du noyau, à l'origine : ouvrir un fichier en lecture entraine implicitement son verrouillage exclusif (sauf si on demande explicitement le contraire).

                    Ca n'a rien, mais alors rien a voir avec le probleme et c'est faux, si tu ouvres un fichier en lecture, tu n'as pas un verrouillage exclusif, tout le monde peut lire le fichier

                    Ce que tu ne peux pas faire, c'est effacer un fichier sous les pieds d'un processus qui a un handle dessus, et la raison est que sous Unix, un fichier c'est 2 entites : une "directory entry" et un inode, le "handle" est sur l'inode, resultat tu peux effacer le fichier (directory entry) et en recreer un autre qui aura un nouvel inode, l'ancien inode disparaissant lorsque le dernier handle est ferme.

                    Sous Windows, un fichier c'est une seule entite, un handle est sur le fichier lui-meme, resultat tu ne peux pas remplacer un fichier tant qu'il y a un handle dessus.
                    • [^] # Re: Script shell

                      Posté par . Évalué à 4.

                      Ca n'a rien, mais alors rien a voir avec le probleme et c'est faux

                      Pas besoin d'enfoncer le clou comme cela hein. Tu dis sensiblement la même chose que lui, pinaillage offert...

                      (Dans le contexte, celui d'une mise à jour ou remplacement de fichiers systèmes, cela nous fait une belle jambe de savoir que 2 process peuvent lire le même fichier; "le verrou exclusif" se comprend bien sûr "empêcher le remplacement" ).
                • [^] # Re: Script shell

                  Posté par . Évalué à -1.

                  Quand tu mets à jour ton navigateur, pour utiliser le nouveau binaire/les nouvelles libs, tu le relances simplement...que ce soit une mise à jour mineure ou majeure d'ailleurs.
                  Pour l'histoire des dépendances sur les libs, déjà les libs d'un navigateur à part le navigateur lui même, je vois pas bien ce qui peut en dépendre, et surtout je vois pas pourquoi ça nécessiterait un reboot.


                  Demande a KDE et Gnome pourquoi ils ont besoin d'afficher du HTML alors.

                  Ensuite, dans les cas ou les libs mises à jour sont des dépendances de beaucoup de programmes (je pense à Qt notamment), et bien il suffit de tuer la session X et la relancer, c'est BEAUCOUP moins long qu'un reboot complet.

                  Tu pourrais tout a fait updater IE sans rebooter le systeme(tu fermes explorer, etc...) mais faut etre un minimum realiste hein, ca revient au meme au final: presque tous tes softs doivent etre fermes.
                  Tu pourrais rajouter un merdier pour gerer ca et sauver 20s chaque mois, mais ca s'appelle prendre un marteau pour tuer une souris vu la difference pour 99% des utilisateurs.

                  Sous Linux, j'ai besoin de rebooter uniquement si j'ai mis à jour le kernel. Le reste c'est pas nécessaire.

                  T'as oublie la glibc

                  De l'autre côté sous Windows, je viens de réinstaller un XP pour mon père, et le nombre de reboot nécessaire m'a rendu fou: chaque driver installé, certains logiciels (dont Java je crois), les mises à jour évidemment. Le pire, c'est qu'après avoir installé le driver son, j'avais directement du son, mais non il veut qu'on redémarre...

                  Ben la prochaine fois t'apprendras que tu peux installer presque tout en meme temps et rebooter bcp moins plutot que rebooter apres chaque truc installe.
                  • [^] # Re: Script shell

                    Posté par . Évalué à 7.

                    > T'as oublie la glibc

                    Faux !

                    Sous Debian, en cas de remplacement de la glibc, tous les processus critiques (serveurs) sont relancés de manière transparente, sans rebooter. Même le processus init est relancé tranquillement sans même avoir à quitter sa session X. Pour les trucs moins importants (genre la session X en question), le gestionnaire de paquet prévient qu'il faudra se déconnecter puis se reconnecter pour prendre en compte le changement de libc.

                    Conclusion : il n'y a bien qu'une mise à jour du noyau qui oblige à un reboot sous Linux.
                    • [^] # Re: Script shell

                      Posté par . Évalué à -5.

                      Sous Debian, en cas de remplacement de la glibc, tous les processus critiques (serveurs) sont relancés de manière transparente, sans rebooter. Même le processus init est relancé tranquillement sans même avoir à quitter sa session X. Pour les trucs moins importants (genre la session X en question), le gestionnaire de paquet prévient qu'il faudra se déconnecter puis se reconnecter pour prendre en compte le changement de libc.

                      C'est super, ca revient a redemarrer tous les processus quoi, vachement different d'un reboot...
                      • [^] # Re: Script shell

                        Posté par . Évalué à 7.

                        Chez moi un tiers du temps de démarrage se passe avant d'avoir accès à grub ce qui n'est pas négligeable.
                      • [^] # Re: Script shell

                        Posté par . Évalué à 3.

                        Bah non, puisqu'il dit :
                        Même le processus init est relancé tranquillement sans même avoir à quitter sa session X.

                        Après, je ne sais pas comment c'est possible, mais je comprends sa phrase comme : tout se relance en arrière-plan.

                        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                        • [^] # Re: Script shell

                          Posté par . Évalué à -1.

                          Sur un serveur: les services doivent etre relances, car ce sont les vecteurs d'attaque--> equivalent a un reboot du point de vue du service rendu par le systeme

                          Sur un desktop : les softs clients + services doivent etre relances, car se sont les vecteurs d'attaque --> equivalent a un reboot du point de vue du systeme

                          Alors oui, tu peux te retrouver sur ton desktop avec tes softs clients non-patches et tes services d'arriere plan patches, super, t'es a moitie-protege...
                          • [^] # Re: Script shell

                            Posté par (page perso) . Évalué à 8.

                            Relancer toutes mes applis y comprit X prend quand même nettement moins de temps que redémarrer mon ordinateur au complet (bios, bootloader, init, ...)
                            • [^] # Re: Script shell

                              Posté par . Évalué à -3.

                              Mais le truc c'est qu'on s'en fout du temps que ca prend en secondes!!!
                              Que ca soit 45 ou 60 ou 90 secondes, c'est pas ca qui compte vraiment...

                              Du point de vue experience utilisateur (ou pour utiliser un terme moins pompeux: la gene occasionnee pour l'utilisateur), ca revient au meme: l'utilisateur doit arreter tout ce qu'il fait, casser sa concentration, pour relancer toutes ses applis et remettre son bureau dans l'etat dans lequel il etait.
                              Tu pourrais booter en 2 secondes, l'utilisateur serait tout aussi emmerde.

                              Du point de vue utilisateur, quitter son bureau puis se relogger, c'est la meme gene que redemarrer la machine.
                              Qu'il ait le bootsplash de windows pendant 30 secondes en plus ne fait pas une difference fondamentale.

                              C'est un peu une des regles de base en termes d'IHM: dans le fond, on se fout de savoir combien de temps ca prend techniquement, ce qui est important, c'est le temps/gene percu par l'utilisateur.
                              En fonction de comment l'interface est designe, une UI techniquement moins performante pourra etre percue comme plus performante en fonction du feedback et de ce genre de chose.
                              J'ai eu un exemple frappant au boulot, le simple fait de rajouter un wait cursor a droite a gauche dans l'appli a fait que les testeurs ont trouve l'appli plus reactive.
                              Et pourtant, les temps de reponses sont *strictement* les memes (on a simplement passe un flag de false a true quand on envoie les requetes au serveur).
                              A l'inverse, sur des parties ou les temps de reponses etaient suffisament rapides pour donner l'impression de travailler en local, le wait cursor leur a donne l'impression que ces parties avaient ralenti.

                              Bref, bottom line: l'UI etant un domaine tres subjectif, le caracteristiques techniques pures sont moins importantes que le ressenti de l'utilisateur.
                              • [^] # Re: Script shell

                                Posté par . Évalué à 10.

                                Que ca soit 45 ou 60 ou 90 secondes, c'est pas ca qui compte vraiment...
                                Donc une interruption de services de 5 à 10 minutes (temps que toutes les cartes raid boot, que le système vérifie les trucs etc...) c'est la même chose qu'une interruption de service de 3sec.

                                Rapelle moi la boite où tu travailles ...
                                • [^] # Re: Script shell

                                  Posté par . Évalué à -4.

                                  Nan, mais sinon, t'as quelque chose a dire qui soit en rapport avec le sujet?

                                  Nan parce que la on parle de desktop et des temps de boots < 120 secondes, ton serveur de prod avec carte raid qui boote en 15 minutes, je vois pas trop ce qu'il vient faire dans la discussion...

                                  Rappelle moi ou t'as appris a lire, que j'y envoie pas mes gosses...
                                  • [^] # Re: Script shell

                                    Posté par . Évalué à 8.

                                    Nan parce que la on parle de desktop
                                    Non. on parle des mises à jours et du besoin qu'a windows de redemarrer pour des mise à jour.

                                    Allez je t'aide, tu remonte de 2 commentaires (pas trop dur, tu arrives encore à compter ?)
                                    Sur un serveur: les services doivent etre relances, car ce sont les vecteurs d'attaque--> equivalent a un reboot du point de vue du service rendu par le systeme

                                    Donc pour toi un desktop c'est un serveur...

                                    tu disais quoi à propos de la lecture en fait ?
                                    • [^] # Re: Script shell

                                      Posté par . Évalué à -4.

                                      MOUARF!!!
                                      T'es toujours aussi con toi...
                                      T'en es reduit a attaquer sur des points de details pour (tenter) de prouver que ce que je n'ai pas dit est faux.

                                      Va donc falloir m'expliquer pourquoi est ce qu'on n'arrete pas de parler de kde, gnome, relancer X et tout ce genre de choses.

                                      Je sais bien compter effectivement, et quand je remonte de un (1) commentaire (sans s du coup) a compter du message auquel tu as repondu, je vois que ca parle de relancer X, c'est clair qu'on est en contexte serveur dis donc.

                                      Mais bon, j'aimerais savoir ou tu bosses toi aussi sinon, histoire de savoir quelle bande de clampins fait des reboots de maintenance sans avoir un spare pour assurer la continuite du service.
                                      • [^] # Re: Script shell

                                        Posté par . Évalué à 4.

                                        Ah voui, la vue c'est vraiment pas ton fort... a moins que ton fort soit autre part.
                                        parce que pour réussir à partir sur un delierium tremens aussi corsé, et une telle poutre dans tes yeux, excuse moi de te dire que tu es un vrai champion.

                                        sisi, parce que me dire que je sais pas lire parce "qu'on" parlais de desktop, alors que 2 post avant le tien c'était de serveur, et quand je te le fais remarquer dire que c'est "un point de détail" (alors que ca ne semblait pas du tout un point de détail quant tu as voulu me reprendre).

                                        bref, toujours aussi puant, toujours aussi de mauvaise fois, toujours aussi aggressif, et tes commentaires, excuse moi, toujours aussi nul et inutiles.
                                        • [^] # Re: Script shell

                                          Posté par . Évalué à -1.

                                          Mouahahaha.
                                          Note que je m'attendais pas a te voir reconnaitre ton erreur, le jour ou tu feras ca... Meme le nez dans la merde tu continueras a affirmer que ca sent bon.

                                          Bref, bref, bref...

                                          Marrant quand meme, tout le fil parle de X, de gnome, de kde, d'installer un navigateur ou un lecteur multimedia, de relancer le bureau, de visual studio, de bureau qui met 5 minutes a etre utilisable.
                                          Mais il suffit que pbpg ait mentionne une fois le mot serveur pour que ta distortion de la realite prenne le relais et hop la, on parlait de serveur sur tout le fil.
                                    • [^] # Re: Script shell

                                      Posté par . Évalué à 1.

                                      ah et derniere chose.
                                      On parle pas de windows, mais de la problematique de s'emboucanner a relancer toutes les applis dependant d'un bout de soft mit a jour contre celle de faire simple et de rebooter la machine.

                                      C'est valable pour Linux ou windows (ou macos ou sunos ou gnu/hurd meme si tu veux, Multidesk OS n'etant pas concerne), c'est pas le probleme.

                                      Mais faut croire que la simple presence de pbpg et de moi meme dans la discussion te font passer en mode "mais t'avec eux ou contre moi?" et que ca en devient donc necessairement un windows contre linux.
                                      Marrant quand meme ta mentalite bipolaire.
                                      • [^] # Re: Script shell

                                        Posté par . Évalué à 5.

                                        On parle pas de windows,
                                        Non non pas du tout. On parle de l'emboucannement des choux et du replantage complet des carottes pour les arroser.
                                  • [^] # Re: Script shell

                                    Posté par . Évalué à 2.

                                    Et on n'a pas le droit d'avoir du raid sur les stations de travail?
                                    • [^] # Re: Script shell

                                      Posté par (page perso) . Évalué à 1.

                                      Perso sur mon pc perso j'ai du RAID. Et heureusement, un des disques dur est tombé en panne la semaine dernière, et grâce au RAID je n'ai rien perdu.

                                      Merci Linux (RAID soft)
                                    • [^] # Re: Script shell

                                      Posté par . Évalué à 1.

                                      ben t'avoueras qu'une carte controlleur raid sur un desktop, ca court pas les rues quand meme.
                                      Je parle pas du raid soft hein...
                                      • [^] # Re: Script shell

                                        Posté par . Évalué à 4.

                                        Dans les stations de travail un peu haut de gamme (1500-2000€), ce n'est pas rare de trouver un contrôleur RAID.
                          • [^] # Re: Script shell

                            Posté par . Évalué à 1.

                            Ce qui serait vraiment intéressant, ce serait de pouvoir recharger une bibliothèque déjà en mémoire, sans affecter les logiciels qui s'en servent : ça doit pouvoir être possible, dans la mesure où une bibliothèque n'est qu'un ensemble de fonctions, en « freezant » les applis qui y font appel le temps du changement.

                            Mais je ne suis pas développeur, je pars peut-être dans quelque chose d'aberrant, et puis ça doit dépendre de l'OS.

                            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                            • [^] # Re: Script shell

                              Posté par . Évalué à 7.

                              Ben le probleme c'est garder l'etat du systeme, lorsque tu utilises la librairie pour creer une session, pour creer une connection, etc... si tu veux decharger et recharger la librairie, va falloir stocker ces etats qqe parts et pouvoir les reprendre au chargement. Ensuite dans les changements majeurs, faut aussi t'assurer que le contenu de la dll est "compatible", le cardinal des fonctions est le meme, etc... histoire que ton code se mette pas a appeler la fonction B alors qu'il appelait la fonction A precedemment, ...

                              La technique tu hotpatching permet de modifier des bouts de code a chaud tant qu'ils ne touchent pas aux structures de donnees, mais decharger/recharger une librairie a chaud de maniere generale c'est complique.
                              • [^] # Re: Script shell

                                Posté par (page perso) . Évalué à 2.

                                Erlang est un langage qui a été développé pour cela. On peut modifier son code à chaud pour mettre des mises à jour de sécurité.

                                C'est intéressant comme concept et je pense que cela va se propager petit à petit comme philosophie. Déjà avec le noyau et ksplice, on peut recharger un module à chaud...

                                Pour les serveurs, on pourrait laisser le serveur traiter les requêtes en cours et utiliser la nouvelle version pour les requêtes suivantes... C'est un peu ce que fait ssh lorsqu'on le relance. J'utilise comme QPSMTP comme serveur de mail qui fork pas mal d'instance pour répondre à la charge et régulièrement, il fork son processus principal... Une mise à jour se fera donc automatique au fork suivant (c'est pas un fork au sens UNIX du terme...). Parfois, on n'est pas à 10mn pour une mise à jour de sécurité si on peut éviter un interruption de service.
                  • [^] # Re: Script shell

                    Posté par . Évalué à 4.

                    Demande a KDE et Gnome pourquoi ils ont besoin d'afficher du HTML alors.

                    Gnome aucune idée, mais sous KDE l'affichage du HTML se fait avec khtml. Donc quand je met à jour les kdelibs, ben je relance ma session X.

                    Tu pourrais tout a fait updater IE sans rebooter le systeme(tu fermes explorer, etc...) mais faut etre un minimum realiste hein, ca revient au meme au final: presque tous tes softs doivent etre fermes.
                    Tu pourrais rajouter un merdier pour gerer ca et sauver 20s chaque mois, mais ca s'appelle prendre un marteau pour tuer une souris vu la difference pour 99% des utilisateurs.


                    Certes, beaucoup de gens en ont peut-être rien à faire..mais moi j'aime pas redémarrer, déjà parce que lors du boot pas mal de temps est passé dans le bios, alors j'évite.

                    T'as oublie la glibc

                    Yep. Apparemment sous Debian c'est géré, sous Arch linux non.

                    Ben la prochaine fois t'apprendras que tu peux installer presque tout en meme temps et rebooter bcp moins plutot que rebooter apres chaque truc installe.

                    Ouais, mais ça me dit pas pourquoi ils ont besoin d'un reboot si tout marche directement après l'installation.
                  • [^] # Re: Script shell

                    Posté par . Évalué à 4.

                    Prendre un marteau pour tuer une souris, c'est vrai que cela éclabousse
                • [^] # Re: Script shell

                  Posté par . Évalué à 2.

                  Tu n'es pas obligé de rebooter à chaque driver...

                  Tu installes tout et tu reboot après.
                  • [^] # Re: Script shell

                    Posté par . Évalué à 3.

                    Quand tu a le choix. Certains drivers ne te demandent rien et redémarrent direct.
              • [^] # Re: Script shell

                Posté par . Évalué à 3.

                De source sur, ni windows ni macos ne requiert un redemarrage apres une update non critique.
                Pour toi changer le nom de la machine c'est une update "critique" ?
                Parce que j'ai testé
                windows 200
                2003
                2003 R2
                et 2008
                ils demandent TOUS de rebooter après avoir changer le nom de la machine
                et crois pas que tu puisse dire "je redemarrerais plus tard", parce que tu peux plus ajouter de roles à ton serveur tant que tu as pas rebooter.

                Alors ta source sur, je crois que tu verrais bien de la revoir
                • [^] # Re: Script shell

                  Posté par . Évalué à -2.

                  heuuu...

                  C'est moi ou on parlait de mettre a jour les programmes/libs sur la machine et tu debarques avec tes gros sabots en nous parlant de la configuration de la machine?

                  A moi que t'aies encore lu en diagonale, facon: "thedude, windows, reboot, il a tord, j'ai raison, linux est mieux de toutes facons" et que tu soit (encore) completement passe a cote de la discussion?
                  • [^] # Re: Script shell

                    Posté par . Évalué à 4.

                    Et sinon, une mise à jour de Windows Update lui même, c'est une update critique qui nécessite un redémarrage ?
              • [^] # Re: Script shell

                Posté par . Évalué à 7.

                De source sur, ni windows ni macos ne requiert un redemarrage apres une update non critique.

                C'est faux.
                Je viens d'installer Visual Studio (version beta 1 de 2010) sur une machine Windows 2003, eh bien il m'a fallu 4, oui quatre, redémarrages pour que l'installation se fasse jusqu'au bout.
                Pourtant, ce n'est pas une mise à jour de sécurité...
                • [^] # Re: Script shell

                  Posté par . Évalué à 3.

                  oui, l'install de Visual Studio et la MSDN c'est une horreur, t'en as pour l'après midi et il faut surveiller pour mettre les différents CD, appuyer sui "suivant", rebooter ... je garde en mémoire ce douloureux moment où j'ai du réinstaller windows pendant la rédaction de ma thèse: il m'a 2 jours pour retrouver un système opérationnel (Visual studio, quelques bibliothèques, et MikTeX en gros) et un nombre de redémarrage incalculable ...
            • [^] # Re: Script shell

              Posté par . Évalué à 0.

              En tout cas ce n'est pas un GNU/Linux qui demandera de redémarrer totalement la machine pour une mise à jour de navigateur ou de lecteur multimédia.

              Windows non plus, tu peux mettre a jour Firefox ou MPlayer sans rebooter.

              Maintenant, va essayer de mettre a jour la KPart qui fait affichage HTML sans redemarrer KDE(ce qui en gros revient a redemarrer car il faut fermer toutes tes applis), t'auras bcp plus de mal...
              • [^] # Re: Script shell

                Posté par . Évalué à 2.

                Ben justement, le problème est que tu considères que "relancer KDE" et "rebooter", ça revient au même (remplacer par Gnome, le bureau Windows, etc.).
                Je me permets de te dire que je ne suis pas d'accord:

                La veille marche bien sur mon portable sous XP (bon, j'ai galéré pour la faire remarcher après augmentation de la RAM, mais c'est une toute autre question...).
                Donc, en sortant de veille, ça démarre vite, quelques secondes à peine. Cool.

                Par contre, quand il faut rebooter, ça bricole pas mal! Ca bricole tellement que je n'arrive même pas à lancer le task manager pour tracer tout ça 2 MINUTES APRES APPARITION DU BUREAU!
                (Je n'installe jamais de freeware/shareware/jeu débile/appli benchmark pour avoir la plus grosse et autre connerie sur mon ordi. C'est l'ordi du bureau, j'essaie de le garder aussi propre que possible).

                Alors c'est sûr, j'installe pas de nouveau driver tous les jours, je ne change pas le nom de ma machine tous les jours. Seules les mises-à-jour demandent de redémarrer. Mais je te promets que s'il suffisait d'arrêter toutes mes applis, voire même de me déconnecter/reconnecter, je crois que ce serait mieux pour mes nerfs (particulièrement quand le redémarrage se lance automatiquement le temps que tu regardes ailleurs alors que tu as un rapport à rendre dans 5min...).

                L'amélioration du temps de boot, c'est comme tu dis pour que "arrêter toutes les applis" et "rebooter" revienne presque au même. Pour l'instant, on ne peut pas dire que ce soit vrai!
                • [^] # Re: Script shell

                  Posté par . Évalué à 0.

                  Par contre, quand il faut rebooter, ça bricole pas mal! Ca bricole tellement que je n'arrive même pas à lancer le task manager pour tracer tout ça 2 MINUTES APRES APPARITION DU BUREAU!

                  C'est qu'il y a clairement qqe chose qui cloche sur ton systeme alors, parce qu'un boot de XP sur une machine a peu pres recente (moins de 4-5 ans), c'est moins d'une minute et c'est utilisable apres.

                  Mais je te promets que s'il suffisait d'arrêter toutes mes applis, voire même de me déconnecter/reconnecter, je crois que ce serait mieux pour mes nerfs (particulièrement quand le redémarrage se lance automatiquement le temps que tu regardes ailleurs alors que tu as un rapport à rendre dans 5min...).

                  Si tu resoud ton probleme de boot lent, a mon avis tu te sentiras beaucoup mieux, et tu te sentiras encore mieux si tu regle Auto Update pour qu'il t'offre les updates a installer et te laisse choisir quand rebooter plutot que le faire automatiquement.

                  L'amélioration du temps de boot, c'est comme tu dis pour que "arrêter toutes les applis" et "rebooter" revienne presque au même. Pour l'instant, on ne peut pas dire que ce soit vrai!

                  Mon temps de boot sur un Vista SP1+toutes les updates(et un nombre de softs installes genre Office 2007, VStudio 2008, ...) sur un laptop de 2006 : ~45 secondes , la plupart de mes machines au boulot ont des temps de boot plus court, avant de pester contre l'OS, il serait bon de comprendre ou se situe le probleme, j'imagines que tu n'as jamais essaye de mesurer ou se situait la lenteur de boot(soit par flemme soit parce que tu ne sais pas comment).
              • [^] # Re: Script shell

                Posté par . Évalué à 3.

                Sur un disque dur lent, il y a une grosse différence entre relancer la session X et rebooter. Le deuxième boot d'un KDE est environ 5 fois plus rapide que le premier sur ma machine, car tout est en cache mémoire.
                Même raisonnement pour le bios, qui prend énormément de temps.
            • [^] # Re: Script shell

              Posté par (page perso) . Évalué à 5.

              alors que la même machine avec une debian hiberne sans problème.

              Mais Debian n'est pas représentative des distributions Linux, c'est la seule qui fonctionne vraiment.

              "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

          • [^] # Re: Script shell

            Posté par . Évalué à 1.

            Dans mon expérience personnelle, c'est l'inverse.

            Sous Linux, la mise en veille en RAM fonctionne très bien. Sous Vista, elle fonctionne aussi très bien. Le problème sous Vista, c'est que dès que je bouge la souris, ça réveille l'ordinateur ce qui est plutôt gênant dans le cas d'un portable que l'on veut déplacer ou mettre de côté.

            Donc, si je devais me servir de Vista, j'éteindrais beaucoup plus souvent mon portable que sous Linux. ;-)
            • [^] # Re: Script shell

              Posté par . Évalué à 4.

              Si je devais me servir de windows, je n'éteindrai mon portable qu'une seule fois
        • [^] # Re: Script shell

          Posté par . Évalué à 6.

          je profite de ce commentaire pour faire part de mon point de vue.
          il est inutile, en effet, de révolutionner un OS pour ganger 10s de boot quand on reboot très rarement; pour un serveur par exemple.
          or, pour un portable, on a besoin d'un boot très rapide. d'abord parce que la veille coute en batterie et que l'hibernation ne marche pas si bien que ça.
          j'en viens à mon idée.
          qu'est ce qui empêche d'avoir un init basé sur un shell pour les distributions serveurs, stable, standard et facile à adapter à ses besoins.
          et un init basé sur qqch de plus rapide, de moins flixible mais simple.
          je pense qu'un boot rapide (<10s) peut repositionner linux sur le marché des laptops (je le souhaite); c'est d'ailleurs ce que tente certaines distribs, moblin en tête.
          • [^] # Re: Script shell

            Posté par . Évalué à 0.

            rebooter ?
            c'est quoi, exactement, en fait ?

            d'après wikipédia, ReBoot est une série télévisée, rien d'autre.
            d'après nous, qui employons si mal notre belle langue ;) il s'agit de re-démarrer un ordinateur.

            mais en fait rebooter est ce re-démarrer un ordinateur ou re-démarrer un O.S.

            Par exemple, si je change de nom de machine, il me faut, par prudence, fermer toutes les connections au système. Sur Linux cela suffit.
            Si je veux re-demarrer la machine, ben je "reboot" selon le terme communément employé, jusque dans les traductions des IHM. (ils sont où nos ayathollas -bien aimés- de la langue française ?)

            Mais finalement lorsque je reboot mes machines, à titre personnel, je me contente de re-démarrer le système d'exploitation, et non pas la machine elle même. Kexec est notre ami (et on ne peux que regretter l'absence de prise en compte de kexec par les nouveaux systèmes de type pinit / init-ng / upstort, ou alors l'inverse ? que sais je ? je comprends que kexec ne puisse être déployer par défaut car des matériels ne le supportent pas (ou l'inverse...) mais chez moi ça marche (c) sur toutes les machines, et donc ces machines ne revoient que très rarement leur bios. Rebooter reviens juste a re-démarrer le système, et la machine.
      • [^] # Re: Script shell

        Posté par . Évalué à 1.

        Et quelle est la probabilité que le fameux /sbin/initng-usplash-shutdown soit lui-même un script shell ?
        • [^] # Re: Script shell

          Posté par (page perso) . Évalué à 4.

          C'est pas compliqué à calculer, tu compte tout les fichiers qui sont des script shell dans /sbin et tu divise par le nombre de fichiers dans /sbin.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Script shell

            Posté par . Évalué à 2.

            Non, ça c'est biaisé. La vraie proba est influencée par la facilité d'écrire un truc dans le super langage d'init-ng.
  • # eINIT & Kyuba

    Posté par . Évalué à 3.

    Tu peux jeter un œil (attention à ne pas te blesser) sur eINIT [1] mais surtout sur son successeur Kyuba [2].

    [1] http://einit.jyujin.de/
    [2] http://kyuba.org/kyuba
    • [^] # Re: eINIT & Kyuba

      Posté par (page perso) . Évalué à 3.

      J'ai déjà regardé tout ça. J'ai vraiment retourné toute la toile pour trouver un remplacement de Sysvinit.

      Je ne me suis pas particulièrement intéressé à ceux-là. Il faut dire que eInit est ouvertement abandonné, et Kyuba ouvertement expérimental (mais sans être développé) et noyé dans un site qui parle de tout sauf de lui.

      Bref, ils ne sont pas attirants du tout (et absolument pas connus, contrairement à init-ng).

      Sans compter qu'ils sont beaucoup moins documentés (il n'y a qu'à regarder la page de téléchargement de Kyuba : la page standard de téléchargement d'un site basé sur Drupal, juste du code, pas de documentation. On ne sait même pas si le machin utilise des scripts shell ou son propre format).
  • # Sans changer d'init

    Posté par . Évalué à 6.

    Plusieurs distributions ont mis au point un moyen de paralléliser le lancement des daemons en gardant le bon vieux init. Sous Debian, il faut setter une variable d'environnement "CONCURRENCY" pour l'autoriser [1]. Le système
    est apparemment basé sur insserv de Suse[2] donc je suppose que ça marche aussi sur Suse.

    En gros, les scripts d'init doivent contenir des commentaires formatés indiquant de quoi ils ont besoin pour fonctionner. Un script va ensuite (si nécessaire) modifier l'ordre de démarrage des scripts (liens Sxxx/Kxxx). Tous les scripts avec le même numéro son lançables en parallèle. Au démarrage, si la parallélisation est activée, il n'est plus nécessaire que l'exécution d'un script soit terminée pour attaquer le suivant s'il n'y a pas de dépendance.

    [1]http://wiki.goatpr0n.de/blog/2008/04/09.speed.up.debian.boot(...)
    [2]http://susefaq.sourceforge.net/faq/services.html
  • # Qu'en est t'il de OpenRC ?

    Posté par . Évalué à 1.

    Sur gentoo, on a OpenRC, c'est pas mal du tout je dois dire, est ce similaire a init-ng ?
    • [^] # Re: Qu'en est t'il de OpenRC ?

      Posté par . Évalué à 2.

      La doc Gentoo étant le meilleure de toutes, elle nous dit d'une manière parfaitement concise, claire et précise :

      http://www.gentoo.org/doc/fr/openrc-migration.xml

      De là à dire que c'est similaire, je m'abstiens, me contentant de dire que le but recherché est similaire. Une différence très notable est que init-ng n'est plus compatible sysV, tandisque OpenRC (et d'autres solutions comme Pinit) conservent une compatibilité.

      Compatibilité nécessaire me semble t il tant que tout les programmes dont à besoin sans en avoir la maitrise, ne seront pas passer à un autre que sysV. Typiquement en contexte professionnel.

Suivre le flux des commentaires

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