Bonsoir,
Mon ordinateur est un MacBook et je dispose donc à la fois de Mac OS X (que je n'utilise pratiquement pas) et GNU/Linux, c'est à dire la distribution ArchLinux personnalisée pour utiliser upstart à la place du system init standard.
Première constatation, Mac OS X démarre très rapidement et Linux beaucoup plus lentement. Voici mes quelques mesures:
Entre rEFIt et le prompt de login Mac OS X, il se passe eactement 15 secondes.
maintenant, coté Linux, rEFIt passe à la main à un GRUB (avec un timeout de 5 secondes) ... ce qui ralonge le démarrage. Mais finalement pas tant que ça :
À partir du moment où GRUB démarre linux et le moment ou je peux voir le curseur de la souris Xorg (j'utilise l'autologin GDM), il se passe environ 50 secondes, c'est à dire beaucoup plus que Mac OS X.
Plus finement, j'ai remarqué que entre le moment ou GRUB passe la main au kernel (écran noir) et le moment ou je vois le début de l'affichage de l'init, il se passe 10 secondes.
Et entre le moment où l'écran commence à clignotter et le moment où j'ai un curseur de souris, il se passe aussi 10 secondes.
J'en déduis donc qu'il y a 30 secondes au milieu pour l'init normal. Mais cela comprend aussi le temps (je dirais à vue de nez au moins 5 secondes) entre le moment où je démarre Xorg (via GDM) et le moment où je commence à voir l'écran clignotter.
Finalement je constate que GNU/Linux démarre très lentement. Est-ce à cause de mon kernel ? De mon initrd ? De mon adaptation de upstart qui est foireuse ? De mon driver intel provenant de Xorg 7.3 ?
J'ai tout de même l'impression qu'on pourrait faire mieux. Et je trouve étonnant que le kernel mette tant de temps à démarrer. De même pour Xorg. 15 secondes pour démarrer Xorg c'est à mon avis beaucoup trop.
Qu'en pensez-vous ?
Journal Temps de démarrage: Mac OS X contre Linux
20
sept.
2007
# Pareil
Posté par Snarky . Évalué à 3.
Par contre, j'ai déjà vu des démarrages super rapide avec des mecs qui l'avais optimisé. Si quelqu'un à un tutoriel pour faire ça, je suis preneur. :-)
[^] # Re: Pareil
Posté par Gregory Auzanneau (site web personnel) . Évalué à 8.
C'est assez facile à mettre en place et souvent très instructif.
Ensuite, init devient vieux : initng fait gagner quelques secondes aussi.
-> Tout ça pour faire booter une debian en en 25 secs (bon, c'est un bon pc portable aussi...)
[^] # Re: Pareil
Posté par Benoît Déchamps (site web personnel) . Évalué à 4.
[^] # Re: Pareil
Posté par Maclag . Évalué à 5.
[^] # Re: Pareil
Posté par Benoît Déchamps (site web personnel) . Évalué à 2.
Les chiffres que je donnais étaient un peu optimistes (je n'étais pas chez moi) mais pas loin de ce que je viens de mesurer :
Démarrage kernel par lilo ==> apparition du Login: 26 secondes
startx ==> croix du serveur X : 4 secondes
startx ==> extinction de la led du HDD après le chargement de KDE vide (mais pas vierge : le profil est celui que j'utilise normalement) : 28 secondes.
Pour la distrib il s'agit d'un Linux From Scratch compilé et optimisé par mes soins il y'a une semaine avec toutes les dernières version des softs.
Pour le matos il s'agit d'un toshiba S1800 712 dont le CPU Celeron 1.1 Ghz à été remplacé par un PIII 1Ghz bien plus efficace.
La partition qui contient /usr est compressée avec squashfs ce qui semble améliorer la vitesse de démarrage de KDE.
[^] # Re: Pareil
Posté par reno . Évalué à 2.
Bon c'est correcte pour un Linux, mais il faut toujours garder a l'esprit que dans l'absolu c'est très lent: un BeOS sur un Celeron333 avec 128Mo de RAM allait de lilo a un desktop utilisable (autlogin donc) en moins de 20s, j'ai 14s comme chiffre en tête (et sans avoir eu a faire aucun réglage).
OK, on ne boote qu'une fois par jour (économisez l'énergie ceux qui laissent leur station allumé la nuit), donc ce n'est pas important..
Mais j'avoue que ça me fait toujours mal de lire l'équivalent de 'mon Linux démarre vite, il met une minute a demarrer'..
[^] # Re: Pareil
Posté par Batchyx . Évalué à 3.
je fait aussi en sorte de démarrer les services qui servent qu'une fois tout les mois après Xorg.
[^] # Re: Pareil
Posté par Moogle . Évalué à 5.
Zindows démarre vite ? T'es sûr que c'est pas juste un retour d'hibernation ? Parce que sur mon laptop, le XP il mets 3 fois plus de temps que ma Debian (avec quelques services en prime).
Sous Linux, ça dépend pour beaucoup de la distrib, des services démarrés, du WM (WindowMaker ownz KDE/Gnome)...
J'ai déjà entendu parlé de kernel flashé dans le bios, mais bon, là c'est un truc de warrior ;)
[^] # Re: Pareil
Posté par Infernal Quack (site web personnel) . Évalué à 5.
Tu as pensé à virer les trucs genre Norton, (Asus/Dell/PackardBell)autoUpdate, la barre Office, WindowsMediaPlayer,... ? Parce que mon portable neuf c'était une grosse bouze toute lente sous Windows. Une fois viré tous les softs 'gratuits' préinstallé pour en mettre des efficaces et une fois les services inutiles virés, je peux dire que c'est difficile de faire booter un linux plus vite d'XP.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Pareil
Posté par Moogle . Évalué à 2.
[^] # Re: Pareil
Posté par ethtezahl . Évalué à 7.
Mouais, pas faux...
M'enfin, la différence, c'est que quand mon Linux est démarré, je sais qu'il est démarré et entièrement accessible, pas comme l'autre bousin qui veut te faire croire qu'il est prêt sur le bureau alors qu'il te charge encore des progs (Le systray est réellement une horreur)
Non mais!
# Mise en Cache
Posté par superna (site web personnel) . Évalué à 5.
C'est d'ailleurs la raison pour laquelle lors d'une mise a jour de sécurité, le boot suivant prends considérablement plus de temps, afin de regénérer les nouveaux caches.
Les distributions pourraient effectivement optimer le boot, mais ça semble assez complexe car il faut garder des compatibilités en distribs et versions, et il semble pas exister de discussions dans ce sens entre les distribution...
Là ou on peut optimer c'est lancer Xorg beaucoup plus tôt, et réorganiser les init pour qu'ils se lancent mieux, genre Apache2 ou autre serveur pendant le login (c'est d'ailleurs presque le cas sous feisty). Mais ça s'applique surtout aux ordinateurs portable et station de travail ou y'a pas besoin de serveur Apache ou MySql.
[^] # Re: Mise en Cache
Posté par GeneralZod . Évalué à 4.
http://developer.apple.com/macosx/launchd.html
launchd est sous licence Apache, mais à ma connaissance personne n'a essayé de l'intégrer dans une distribution GNU/Linux (il y a un port *BSD). Fedora l'a envisagé comme un des remplaçants potentiels pour init.
De plus l'init classique est pas capable de démarrer en parrallèle plusieurs services. Déjà, init-ng fait gagner pas mal de temps en permettant le lancement en parrallèle de plusieur services.
Quant à upstart, je suppose qu'ils n'ont pas encore eu le temps de s'intéresser à l'optimisation en vitesse, développer une alternative à init ça se fait pas en claquant des doigts.
[^] # Re: Mise en Cache
Posté par ham . Évalué à 1.
si les extensions kernerls sont toujours chargé dans le meme ordre, ont peut les mettre toute au meme endroit sur le disque et utiliser au mieux les méchanismes de cache. (windows fait pareil)
# Moi
Posté par Ph Husson (site web personnel) . Évalué à 5.
-La plus ancienne: j'ai programmé mon propre init (non je l'utilise plus et le code source doit être tres dur à retrouver), avec ma propre config de kernel, ben je comptais 6 secondes je dirais à vue de nez pour avoir un systeme completement démarré hors interface graphique (donc en gros y a pas grand chose de démarré mais bon quand même udev & hal, réseau, un serveur httpd, enfin pas grand choses mais bon pas besoin de plus). Bon pour kdm c'etait beaucoup plus long (un jour je reessayerais peut être mais je crois que c'etait un probleme de driver X), 15 secondes de plus.
-Plus récente: l'easygate (ordi prévu pour être simple par neuf): démarrage pas trop lent, une trentaine de secondes pour avoir la GUI (un xfwm + un dock fait maison si je ne me trompe pas le tout sur un Xorg 7.2 banal), bon par contre pour lancer firefox apres il faut rajouter 30 secondes (bon ok un peu moins), MAIS il faut noter que c'est un celeron 600Mhz avec 512Mo de RAM + 512Mo de flash.
Je connais pas encore le débit de la flash, mais bon des ordinateurs actuels peuvent largement faire mieux, pour le temps de latence on peut s'arranger pour mettre les fichiers nécessaires au boot dans un gros fichier à lire au démarrage sans trop de difficultés.
Bref le temps de démarrage d'une distrib Linux est en tres grande partie un probleme de motivation. (et me faites pas rire avec upstart)
[^] # Re: Moi
Posté par Leroy Frederic (site web personnel) . Évalué à 1.
18s pour passer le bios ... fucking x86
19s pour arriver sous X. Traditionnellement, il faut compter 3/4s de moins car c'était un premier démarrage qui a regénéré le cache des fontes et des librairies.
13s pour démarrer firefox (Les suivants prennent 3s)
[^] # Re: Moi
Posté par Ph Husson (site web personnel) . Évalué à 2.
Et c'est vrai que sur l'easygate il est pas préssé .... (et oui pour les 30s de firefox c'etait ma mauvaise foi, mais bon au moins les 19s pour arriver à X ca bouge un peu, pour firefox nada, meme pas de disque dur qui gratte !)
[^] # Re: Moi
Posté par Leroy Frederic (site web personnel) . Évalué à 1.
J'ai refais un essai depuis, 14s pour booter le système (sans regénération des caches). Mais on doit pouvoir encore gagner du temps, je pense.
Pour le bios ... on a quand même une lueur d'espoir avec linuxbios.
Et puis Na ! J'ai le droit de poster sur Linuxfr et ce, à n'importe quelle heure ! (cf irc)
# Bash
Posté par yellowiscool . Évalué à 4.
Envoyé depuis mon lapin.
[^] # Re: Bash
Posté par Anonyme . Évalué à 2.
un genre de compilateur.
[^] # Re: Bash
Posté par gentildemon . Évalué à 4.
Il semblerait que le gros problème vienne surtout de la création massive de processus lors du boot (facilement 1000) lié justement à l'utilisation de bash qui rend nécessaire l'utilisation de grep, sed, sort, tr, awk, ...
En utilisant un langage de script plus évolué (perl, python, ruby, ...), un script d'init ne créerait qu'un seul processus (+ le démon si le script lance un démon).
Je croyais d'ailleurs que c'était un des buts d'upstart, remplacer les scripts bash par du python...
[^] # Re: Bash
Posté par Aldoo . Évalué à 7.
Les fichiers de démarrage n'étant pas a priori dans des secteurs contigus du disque dur, j'imagine que chaque ouverture provoque un accès physique au disque. Imaginons 2000 fichiers à 10ms de temps d'accès, ça fait déjà 20 secondes ! Bon ensuite, 2000, c'est peut-être exagéré ;-). N'empêche que ça correspond à peu près à la différence entre un boot sur disque dur magnétique et un boot sur mémoire flash.
Une solution à cela serait de forcer les fichiers à être écrits physiquement dans des secteurs contigus, mais ce n'est toujours pas optimal (ça dépend trop de l'implémentation du FS et des pilotes du disque !).
Une autre solution serait de copier tous les fichiers dans un fichier de cache (contigu dans le FS, autant que possible), qui serait chargé inconditionnellement en RAM à chaque boot en premier lieu.
Ce cache serait mis à jour plus tard pendant la session, dès qu'on a un peu de temps, par exemple en contrôlant les access time des fichiers potentiellement concernés, et tant qu'à faire en les rangeant dans l'ordre.
Une mise en ½uvre pas trop difficile serait de monter ce cache en tant que /etc ou /truc (avec un système qui irait chercher dans le vrai FS en cas de défaut de cache).
On pourrait encore optimiser en lançant le chargement du cache en parallèle de l'exécution du démarrage, en donnant la priorité aux accès demandés explicitement par l'init (dans les rares cas où le fichier n'a pas déjà été chargé : en effet, le cache est ordonné !).
Résultat : utilisation optimale du disque dur pendant le démarrage.
Est-ce que des solution similaires auraient déjà été mises en ½uvre dans d'autres OS ? Est-ce cela qui se passe sous MacOSX ? Est-ce que je réinvente la roue parce que les FS actuels réorganisent déjà les fichiers de telle sorte que ça passe bien ?
Bon, évidemment tout ce que je dis là est peut-être un peu naïf, car je ne suis pas un gourou de la programmation système. Donc n'hésitez pas à critiquer.
[^] # Re: Bash
Posté par mammique . Évalué à 2.
Exact, je crois d'ailleurs avoir lu que les performances de boot de certaines mini distribs seraient dues à buzybox (un seul binaire pour, grep, sed, sort, tr, awk, ...).
# mise en veille
Posté par B16F4RV4RD1N . Évalué à 6.
Pour la remise en service, sur mon ordinateur avec Linux / Debian, cela doit mettre dans les 15 secondes également...
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: mise en veille
Posté par Georges Dubus (site web personnel) . Évalué à 5.
[^] # Re: mise en veille
Posté par cosmocat . Évalué à 4.
[^] # Re: mise en veille
Posté par gentildemon . Évalué à 2.
Perso, c'est la carte son, mais uniquement en hibernation, tout est parfait en mise en veille, et j'ai découvert que si sorti de l'hibernation, je fais une mise en veille et relance, ça remarche :-)
[^] # Re: mise en veille
Posté par fasthm . Évalué à 2.
d'hibernation prend beaucoup plus de temps que le boot.
Sans doute à cause d'un disque dur à 5400 tours/minute.
La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".
# Qu'en pensez-vous ?
Posté par moramarth . Évalué à 1.
Que tu n'as pas chronométré les extinctions !
Blagues à part, je pense qu'aujourd'hui, avec la suspension/hibernation, ça n'a plus du tout la même importance. Ne t'inquiète pas.
Dans l'absolu évidemment, un démarrage et une extinction rapide seraient un plus, je ne le nie pas. Chacun ses priorités, évidemment.
# Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Xorg
Posté par B16F4RV4RD1N . Évalué à 6.
Le mieux n'est-il pas d'avoir une machine qui ne reboote pas du tout ?
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: Xorg
Posté par Toto . Évalué à 4.
Que les première fois il s'amuse à démarrer lentement je peux comprendre (detection du matos et autres contraintes), mais on ne change pas tous les jours de matériel. Et comme le suspend to RAM marche quand il pleut le soir du 31 février, j'aimerai que mon PC démarre un peu plus vite
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Xorg
Posté par Serge Julien . Évalué à 4.
Je ne doute pas que ce soit intéressant pour certains, mais pas pour tout le monde. Par exemple, je n'utilise mon PC que quelques heures (5-6) par semaine. Je ne vois donc pas de raison de le laisser allumé en dehors de ce temps-là. En effet, même si mon fournisseur d'électricité me garantit une énergie propre à 100%, je dois quand même la payer...
[^] # Re: Xorg
Posté par ham . Évalué à 2.
un serveur n'est pas forcement utilisé seul, il peut faire partie d'un cluster avec tolérance au panne, dans ce cas la c'est parfaitement gérée et attendus que des truc reboot ( bouton rouge sur le mur, cable foireux, UPS mort, ..etc) et ca n'affecte pas le service.
Par contre il est préférable que ton système boot rapidement parceque si il met une heure a rebooter, tu prie pour que les autres ne tombe pas, moins si il met une minute.
Donc ce n'est pas qu'un critére desktop mais ca peut etre aussi important pour les serveurs.
[^] # Re: Xorg
Posté par Mildred (site web personnel) . Évalué à 1.
Tu as des liens ?
Pour le suspend, c'est très pratique mais:
- le suspend to disk ne marche pas chez moi, il faut dire que je n'ai pas cherché à le faire fonctionner. Mais avec un clavier qui marche une fois sur vingt sur le prompt grub (bug du BIOS) ...
- et pour le suspend to ram, c'est bien mais ça continue de consommer un peu. Et surtout après quelques jours sans arrêter l'ordinateur tu finis par avoir une RAM pleine, et une SWAP pas loin des 100%. Après un redémarrage ça va un peu mieux.
[^] # Re: Xorg
Posté par B16F4RV4RD1N . Évalué à 2.
hein ? Tu fais tourner un windows avec vmware pour avoir ce problème ?
Je n'ai jamais eu de soucis de ram même avec un uptime d'une quarantaine de jours sous linux.
Il me semble que Linux "garde tout en ram", mais réserve des zones pour ce qui est nécessaire, et ce qui peut être libéré instantanément, ainsi même si la ram peut paraître surchargée, en fait ce n'est pas souvent un problème. Par contre si cela swappe vraiment trop, il y a peut être un soucis ailleurs.
Au niveau des problèmes de mise en veille, c'est vrai que c'est très pénible lorsque cela ne fonctionne pas bien :(
Sur mon ibook, une fois cela allait, ensuite avec un nouveau noyau c'était cassé, cela refonctionnait plus tard, puis des problèmes survenaient si on avait laissé quelque chose en usb de branché (par exemple clavier ou souris...).
J'ai eu également des problèmes avec linux non ppc, une fois sur 3 la remise en service plantait la machine (ou alors reboot propre via ssh)
Mais depuis le noyau 2.6.22 je n'ai plus de problème notable avec uswsusp (s2ram / s2disk), tout semble fonctionner correctement, et c'est très rare si la remise en service plante (1 fois tous les 50, voire moins ?)
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: Xorg
Posté par Mildred (site web personnel) . Évalué à 1.
C'est peut être du a mon habitude de laisser 15 fenêtres epiphany ouvertes avec au moins 15 onglets dans chacune...
[^] # Re: Xorg
Posté par B16F4RV4RD1N . Évalué à 2.
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
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Xorg
Posté par GeneralZod . Évalué à 3.
# jusqu'au prompt de login oui,
Posté par nazcafan . Évalué à 4.
En comparaison, mon athlon 2200 d'il y a 4 ans est une flèche pour charger gnome, iceweasel, icedove et pidgin.
Je n'ai pas quantifié ça, ceci dit, faudrait que je chronomètre.
[^] # Logiciel tiers
Posté par moramarth . Évalué à 1.
J'ai noté aussi que Firefox était lent à lancer la première fois, mais beaucoup plus rapide ensuite (en quittant l'application, pas juste en fermant la fenêtre, bien sûr).
Tu crois sincèrement que le démarrage d'un GNU/Linux est lent parce qu'il te précharge Firefox, Thunderbird ou autres applications ? Je ne le pense pas.
[^] # Re: Logiciel tiers
Posté par gentildemon . Évalué à 2.
Sur ton Linux, lorsque tu démarre Gnome, il va charger GTK du disque vers la mémoire. Les autres applications n'auront plus à le faire, ainsi, Firefox démarrera plus rapidement.
Si tu es sous Gnome, essaie de lancer une application Kde (Konsole par exemple), au premier démarrage, c'est horrible, il faut qu'il charge Qt, kde-base, etc. Ensuite, tu peux démarrer une autre Konsole très rapidement, mais une autre application Kde aussi, le plus gros est déjà chargé!
(Après je voudrais bien croire que Firefox soit optimisé Windows...)
[^] # Re: Logiciel tiers
Posté par nazcafan . Évalué à 1.
Ce que je voulais dire, c'est qu'il faut bien attendre une bonne minute après s'être loggué avant d'avoir une certaine réactivité de la part des applications
Sinon, si je lance firefox (ou autre) après avoir laissé écouler ce délai, ça se charge très vite, en effet (ce qui m'avait amené à supposer qu'il doit continuer de charger des surtonnes de services après le login)
Cette réactivité, il me faut maxi 15 secondes sous debian-gnome pour l'avoir.
En gros, quand je lance gnome, en 15 secondes tout est chargé. Quand je lance aqua, là ça met beaucoup, beaucoup plus.
# Il n'y a pas que le démarrage dans la vie
Posté par Laurent GUEDON . Évalué à 2.
Ca fait quelques années (3 je crois) que j'ai acheté mon premier powerbook pour remplacer mon thinkpad sous Linux. Et je dois avouer en être très ravis : je ne le lacherais ni pour Windows Vista, ni pour une Ubuntu.
Je vois encore mon thinkpad mettre 15 secondes pour se mettre en veille ou pour se réactiver alors qu'OSX est instantané... Sans compter qu'en veille j'ai encore des trucs qui sont activé et la batterie ne dure pas plus d'une nuit (mais bon, ça c'est un problème de driver).
Mais, hors laptop, j'adore nunux : j'ai une station sous Debian et une sous Ubuntu.
# upstart
Posté par solsTiCe (site web personnel) . Évalué à 3.
ah, et t'as trouvé un paquet tout fait ? t'en a fait un ?
euh tu partages ? le PKGBUILD ?
# Avec aucune info technique pas facile de donner des conseils
Posté par naibed . Évalué à 1.
c'est l'initialisation de udev pour le reste c'est configurable
facilement.
Tu pourrai éditer le fichier /etc/rc.conf,
dans la section hardware tu peux ajouter la listes des modules
à charger et désactiver la détection automatique.
Désactiver lvm si tu ne l'utilise pas.
Pour ce qui est du démarrage de Xorg je viens de chronométrer
sur ma machine (sempron 2000 , 256mo de ram) cela met moin
de deux secondes.
A mon avis ton problème c'est pas le kernel ni Xorg mais tout ce qu'il
y a autour.
# Objectivité du test
Posté par Bonnefille Guilhem (site web personnel) . Évalué à 4.
Par exemple, ma machine perso Linux propose beaucoup (beaucoup) plus de service que mon poste bureautique (un windows, mais c'est dans le même genre d'idée) au taf : serveur ftp, ssh, mail...
De plus, je me demande si faire la comparaison avec le temps avec la première apparition de la souris est vraiment une bonne mesure.
Toujours dans mon cas, les windows que j'utilise propose très rapidement l'écran de login. Pourtant, une fois mes identifiants fournis, il moulinent un moment...
Voilou, juste mes 2 cents pour aider à avoir des bench plus précis.
[^] # Re: Objectivité du test
Posté par Mildred (site web personnel) . Évalué à 1.
Pour ce que tu dis, c'est vrai. Je n'utilise pas du tout Mac OS X donc forcément, c'est une configuration par défaut, d'un OS tout neuf. Alors que j'ai déjà bidouillé énormément ArchLinux, et même remplacé son système d'init.
Par contre je maintiens que l'apparition du curseur de la souris est une bonne mesure... Du moins pour Linux or Mac OS. C'est à partir de ce moment que tu peux faire quelque chose.
Je me rappelle d'un article que j'avais du lire qui disait qu'un utilisateur préférait une application qui démarre lentement mais qui affiche directement un retour visuel (splash screen) qu'une application qui démarrait plus vite sans retour visuel. Pour le démarrage de l'OS, c'est un peu pareil.
Une fois l'OS démarré, en général je ne cherche pas à faire quelque chose directement. Je prend un peu de temps pour savoir ce que je vais faire ... Donc finalement ça ne me dérange pas que tous les services ne soient pas encore là.
# Problème corrigé
Posté par Bruno Coudoin (site web personnel) . Évalué à 4.
Mais le problème a été corrigé par la dernière mise à jour de macosx car, depuis, ce dernier met un temps infini pour booter. Plus précisément, il boote plus du tout.
Par contre Ubuntu est toujours aussi lent mais en proportion infiniment plus rapide que macosx. Merci Apple ;)
[^] # Re: Problème corrigé
Posté par Dan . Évalué à 2.
Apparemment, la ArchLinux n'est pas bien rapide non plus...
Et un test sous Debian ou une autre ça donne quoi avec un mac ?
Sinon, sympa ce genre de journal, c'est très instructif :-)
[^] # Re: Problème corrigé
Posté par Nicolas Schoonbroodt . Évalué à 3.
[^] # Re: Problème corrigé
Posté par Mildred (site web personnel) . Évalué à 1.
Avec le système de boot archlinux, c'est fort possible que ça aille plus vite. Seulement je préfère upstart car il me permet de configurer tout comme je le souhaite. Par exemple j'active tty2 au tout début, du coup c'est très pratique.
[^] # Re: Problème corrigé
Posté par Mildred (site web personnel) . Évalué à 2.
Donc en gros, pour être claire : J'ai modifié complètement le système de boot super rapide de ArchLinux pour le remplacer par upstart, on ne peux donc rien conclure sur la vitesse de boot de ArchLinux !
Et la suite : Sur un autre ordinateur (desktop), ArchLinux démarre sensiblement plus rapidement que Ubuntu ... C'est visible.
Certes une fois que j'ai rajouté un serveur http, un serveur jabber, et diverses autres joyeusetés, c'est moins sensible ... mais à nu, ça démarrait vite.
[^] # Re: Problème corrigé
Posté par thedidouille . Évalué à 3.
J'imagine qu'avec un dual core, ça irait encore plus vite ...
[^] # Re: Problème corrigé
Posté par Dan . Évalué à 2.
# essaye la ZenWalk
Posté par papap . Évalué à 1.
# LinuxConsole
Posté par Yann LD . Évalué à 1.
La version 'micro' démarre en 30 secondes avec Qemu
Avec la version normale, "F2" permet de voir le nombres de secondes depuis le démarrage
# runit
Posté par ioguix . Évalué à 2.
http://smarden.org/runit/
runit est un projet qui se propose en remplacement du init traditionnel. Son avantage est qu'il est trés léger et utilise un programe pour gérer et monitorer les services lancé : runsvdir.
J'ai ouï dire cette même semaine via une source de confiance que runit dopait significativement la durée de boot.
Seul petit hic : se repalucher une conf de chaque service pour runit (notez que Debian a un paquet qui propose ça : runit-services).
Bref, j'en dis pas plus car je n'ai toujours pas testé le bestiot...Avis à ceux-ce qui ont tenté l'expérience.
[^] # Re: runit
Posté par Mildred (site web personnel) . Évalué à 1.
Upstart, sur le papier c'est bien. Sauf qu'en pratique il manque plein de choses. Les conditions pour lancer un service sont insuffisantes (par exemple il est possible de lancer un service si on a reçu l'évennement A ou B, mais pas si on a reçu A et B). Donc c'est gênant. Un service ne peux dépendre que d'un autre service, pas de deux à la fois.
Ensuite, le design est joli, mais cf les derniers messages de la mailing liste, ça pose des petits problèmes. Et si on veut faire quelque chose dans l'esprit d'upstart, il faudrait écrire plein de scripts udev ou autre pour transformer les evennements udev en evennements upstart.
Donc upstart c'est bien mais c'est pas encore ça. Sans compter qu'il est facile de le faire entrer dans une boucle infinie. Par exemple j'ai eu un service qui dépendant pour être démarré de lui même. Du coup j'ai un processeur qui tourne comme un fou et la seule solution, c'est de redémarrer.
Donc quelque chose de simple ça me tente. Seulement je crains un peu que les scripts bash plombent les performances du système d'init. Je me dis que si on base tout sur un langage de script très léger comme Lua [http://lua.org], ça peut améliorer les performances. Donc du coup j'ai commencé à écrire un truc.
L'avantage de lua, c'est qu'il est possible d'avoir plusieurs threads. Et ces threads sont gérés par la machine virtuelle et ne sont pas ordonnancés. C'est le programmeur qui va définir quand le thread va se stopper en faveur d'un autre. Donc du coup pas mal de problèmes de concurrence sont résolus (car il n'y a pas vraimment de concurrence).
Bon, je vais me coucher, bonne nuit :)
[^] # Re: runit
Posté par ondex2 . Évalué à 2.
IPoT ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.