Fini les temps où seul le "uptime" comptait? En se tournant de plus en plus vers l'utilisation bureautique, les distributions Linux n'ont en cette année 2009 qu'une idée en tête : démarrer plus vite.
Ce coup-ci, c'est de la liste de diffusion d'Ubuntu que ça vient : https://lists.ubuntu.com/archives/ubuntu-devel/2009-June/028(...)>Scott Scott James Remnant y décrit l'objectif que s'est donné Canonical : 10 secondes sur un Dell Mini 9 (disque SSD). Cet objectif est visé pour un bureau connecté en autologin, et aucune activité CPU ou disque. Cela exclut notamment le retardement de démarrage de services : seul le démarrage sur demande est accepté. Je crois qu'xinetd a encore de beaux jours devant lui ;-)
# Hum
Posté par Pascal Terjan (site web personnel) . Évalué à 10.
Donc ils preferent qu'on perde du temps à faire la requete dhcp quand on veut le réseau et attende la réponse plutot que d'activer le réseau en tache de fond?
[^] # Re: Hum
Posté par Alexandre COLLIGNON (site web personnel) . Évalué à 3.
ça risque d'être pénible à la première utilisation après démarrage effectivement !
Je ne sais pas si ce choix est judicieux dans le cas du réseau.
Cela dit rien n'empêche d'avoir un un mix des deux modes (démarrage en tâche de fond et à la demande) pour tirer profit du meilleur de ces deux fonctionnements.
Alexandre COLLIGNON
[^] # Re: Hum
Posté par Étienne . Évalué à 8.
Je pense plutôt qu'ils démarrent le service NetworkManager. Le service est démarré mais la récupération d'une adresse peut être faite après par NetworkManager pendant que le reste démarre.
# launchd
Posté par 태 (site web personnel) . Évalué à 6.
Après, il faut faire attention : certains services fonctionnent mal dans cette configuration (je pense à postfix sous mac osx qui ne se réveille pas tout seul pour réenvoyer les mails greylistés). Cette amélioration est intéressante pour les portables mais est-elle judicieuse pour les machines de bureau qui sont éteintes moins souvent ?
Pour les portables, j'utilise plutôt la mise en veille (to-disk) qui me fait gagner quelques secondes par rapport à un boot complet, mais la "to-ram" qui serait la plus indiquée consomme beaucoup trop de batterie sur ma machine.
[^] # Re: launchd
Posté par Psychofox (Mastodon) . Évalué à 4.
Je trouve ça pas mal moi, au point de me dire que faire du suspend to disk ne m'apporte pas grand chose. De toute façon j'arrête mon pc quand je sais que je ne l'utiliserais pas dans la journée et 30 secondes de perdu au redémarrage, c'est pas la mère à boire. Je prends juste la précaution de l'allumer et de le mettre en veille le matin si je sais que je vais l'utiliser dans le train.
[^] # Re: launchd
Posté par claudex . Évalué à 3.
Ça dépend énormément du PC, le miens ne doit pas tenir beaucoup plus de 5h en veille (alors qu'il tient facilement 2h en utilisation pas trop intensive).
« 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: launchd
Posté par 태 (site web personnel) . Évalué à 2.
[^] # Re: launchd
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
/me va prévenir la société protectrice des babasses.
[^] # Re: launchd
Posté par yellowiscool . Évalué à 4.
Envoyé depuis mon lapin.
[^] # Re: launchd
Posté par benoar . Évalué à 3.
[^] # Re: launchd
Posté par yellowiscool . Évalué à 3.
Envoyé depuis mon lapin.
[^] # Re: launchd
Posté par Alexandre COLLIGNON (site web personnel) . Évalué à 3.
Alexandre COLLIGNON
[^] # Re: launchd
Posté par ckyl . Évalué à 2.
[^] # Re: launchd
Posté par thedude . Évalué à 5.
Ou alors, aidez moi, j'ai pas encore trouve.
En regle general, je comprends pas trop cette manie de s'acharner a demarrer le plus vite possible, la ou la vraie valeur ajoutee pour l'utilisateur serait plutot de fournir une veille ram/disk fiable a 100%.
'fin je sais pas, je redemarre mon macbook pro tous les ...
heuuu....
ben juste pour les mises a jour en fait, le reste du temps je ferme l'ecran et paf, je retrouve ma session comme elle etait.
[^] # Re: launchd
Posté par yellowiscool . Évalué à 2.
Envoyé depuis mon lapin.
[^] # Re: launchd
Posté par claudex . Évalué à 5.
« 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: launchd
Posté par benoar . Évalué à 8.
[^] # Re: launchd
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Mais en suspend to RAM, il ne devrait rester d'alimenter que les chips DRAM en mode self-refresh.
Ce qui est intéressant, c'est qu'entre un lp-ddram d'un téléphone et les puces DDRAM des PC, la conso du refresh doit aller de 1 à 100 :)
Donc, même pour un PC, selon le type de mémoire, la durée de la veille change beaucoup.
"La première sécurité est la liberté"
[^] # Re: launchd
Posté par obiyann . Évalué à 1.
Personnellement, je boot en moins de 40 secondes, alors que mon hdd ne tourne qu'à 5400tpm. Et quand je dis 40s, c'est avec le bureau près à l'emploi sur mon écran.
Je n'ai donc aucun intérêt avec les suspend to...
C'est un système Debian 5 léger avec lxde comme bureau.
[^] # Re: launchd
Posté par yellowiscool . Évalué à 1.
C'est un système archlinux léger avec zsh comme shell.
Envoyé depuis mon lapin.
[^] # Re: launchd
Posté par thedude . Évalué à 4.
[^] # Re: launchd
Posté par B16F4RV4RD1N . Évalué à 2.
ben si, avec un bon suspend to... cela ne prendrait qu'une seconde pour le sortir de veille !
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: launchd
Posté par thedude . Évalué à 2.
au lieu de focaliser sur des demi secondes au boot, si vous realisiez qu'un suspend, ca conserve la session, les applis, etc?
Et que les 2.432 secondes qu'on gagne au boot, elles sont perdues quand il faut tout relancer, reouvrir ses onglets, etc?
Et que donc un temps de boot rapide ne sert strictement a rien tant qu'on a pas un systeme capable de faire dodo, et surtout de sortir de sa sieste?
[^] # Re: launchd
Posté par B16F4RV4RD1N . Évalué à 2.
Et surtout, comme tu le soulignes, avec une mise en veille on garde toutes les applications en cours, ce qui rajoute encore l'intérêt de se baser là dessus plus que sur le temps de démarrage. (l'intérêt d'un démarrage rapide je ne vois cela que pour un netbook type eeepc dont les batteries ne tiennent pas bien la mise en veille)
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: launchd
Posté par Epy . Évalué à 2.
[^] # Re: launchd
Posté par pasBill pasGates . Évalué à 6.
Pour tous les autres par contre, ca compte peu effectivement.
[^] # Re: launchd
Posté par Sébastien B. . Évalué à 5.
- le temps de poster un journal type bookmark
- le temps de trouver deux fautes d'orthographe dans un journal ou dans une news et d'en faire un commentaire
- le temps de dire que ce journal aurait plus sa place dans les forums.
# Précision
Posté par brazz . Évalué à 4.
http://www.ubuntulinux.fr/index.php?post/2009/06/09/Vitesse-(...)
et ça
https://lists.ubuntu.com/archives/ubuntu-devel/2009-June/028(...)
ce qui est explicite sur le réseau...
Alors, soyons prudent peut être. Mais de toutes manières, il est évident -comme aujourd'hui- que plus de services sont lancés, plus de ressources sont mobilisées, il n'y a guère de miracles mais des choix.
# suspend to disk
Posté par Nicolas Boulay (site web personnel) . Évalué à 7.
J'imagine que relancer une image suspend to disk doit être plus rapide qu'un reboot.
"La première sécurité est la liberté"
# Ridicule ...
Posté par Francois G. (site web personnel) . Évalué à 6.
Il serait bien plus pertinent de calculer le temps entre :
- une pression sur le bouton de démarrage et l'affichage d'une page web de test.
- une pression sur le bouton de démarrage et le début de l'écoute d'un fichier audio.
- une pression sur le bouton de démarrage et l'affichage d'un fichier pdf, odt, ...
etc ...
On aurait sûrement des ordinateurs plus réactifs ... à tous les niveaux.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.