- 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
- Journal à l'origine de la dépêche (2 clics)
- Upstart in Universe (1 clic)
- Spécification chez Ubuntu (1 clic)
- Page du Wiki Ubuntu (1 clic)
- DLFP : Choix de pinit par Mandriva (1 clic)
# Pour ma part...
Posté par Manger sur pattes . Évalué à 5.
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 Pierre Jarillon (site web personnel) . Évalué à 9.
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 Pierre Jarillon (site web personnel) . Évalué à 10.
- 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 Vanhu . Évalué à 4.
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 Manger sur pattes . Évalué à 3.
[^] # Re: Pour ma part...
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
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 lolop (site web personnel) . Évalué à 4.
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 Manger sur pattes . Évalué à 5.
[^] # Re: Pour ma part...
Posté par Olivier Jeannet . Évalué à 4.
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 Anonyme . Évalué à 2.
Ouais, on est allé sur la lune, ca c'est ce que la NASA affirme :)
[^] # Re: Pour ma part...
Posté par Uvoguine . Évalué à 3.
C'est clair, je demande à voir les vidéos originales !
[^] # Re: Pour ma part...
Posté par franckd . Évalué à 1.
[^] # Re: Pour ma part...
Posté par Psychofox (Mastodon) . Évalué à 5.
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 Olivier Jeannet . Évalué à 1.
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 Anonyme . Évalué à 1.
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 Anonyme . Évalué à 1.
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 SF . Évalué à 3.
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 Rossel Olivier . Évalué à 2.
J'ose esperer que Ubuntu et Debian vont negocier afin de choisir le meme systeme d'init.
[^] # Re: Normalisation avec la LSB et ... avec Debian?
Posté par Xavier Maillard . Évalué à 4.
Je suis personnellement favorable à cette approche. De plus le fait que tout reste compatible laisse la porte ouverte aux autres approches (initng & co). Après rien n'empêche aux versions d'être mis en paquets .deb.
De toute façon, ce n'est pas pour demain...
[^] # Re: Normalisation avec la LSB et ... avec Debian?
Posté par Fathi BOUDRA . Évalué à 2.
[^] # Re: Normalisation avec la LSB et ... avec Debian?
Posté par rahan . Évalué à 4.
Plus d'info :
Les objectifs présentés à Google : http://code.google.com/soc/debian/appinfo.html?csaid=4F8C269(...)
La page de préparation du travail chez Debian : http://initscripts-ng.alioth.debian.org/soc2006-bootsystem/
Le blog de l'étudiant : http://bootdebian.blogspot.com/
# rc.d
Posté par Antoine Reilles (site web personnel) . Évalué à 6.
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 olwin . Évalué à 0.
source : http://launchd.macosforge.org/
[^] # Re: launchd : APSL ?
Posté par - - . Évalué à 1.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: launchd : APSL ?
Posté par - - . Évalué à -2.
>> 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).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 8.
Ce commentaire a été supprimé par l’équipe de modération.
# "limitations de sh"
Posté par salvaire . Évalué à 1.
[^] # Re: "limitations de sh"
Posté par Bactisme (site web personnel) . Évalué à 10.
[^] # Re: "limitations de sh"
Posté par matthieupoirot . Évalué à 2.
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 M . Évalué à 2.
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 bmc . Évalué à 3.
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 Loïc Ibanez . Évalué à 1.
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 Maxime Ritter (site web personnel) . Évalué à 0.
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 Vanhu . Évalué à 1.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.