Journal Temps de démarrage: Mac OS X contre Linux

Posté par  (site Web personnel) .
Étiquettes : aucune
0
20
sept.
2007
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 ?
  • # Pareil

    Posté par  . Évalué à 3.

    Ça fait longtemps que j'ai fait ce constat. Mais je me rassure en disant que Linux n'as jamais brillé par sa vitesse de démarrage. (Même Zindows démarre plus vite)

    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  (site Web personnel) . Évalué à 8.

      Si vous avez envie de vous amuser pour tenter d'optimiser un peu son temps de boot, il y'a un outil pour grapher ce que votre ordi fait : http://www.bootchart.org/
      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  (site Web personnel) . Évalué à 4.

        Franchement je ne sais pas comment vous faites. Sur un portable de 2002 à base de PIII 1Ghz il lui faut 20 secondes pour démarrer X après que lilo ait passé la main au kernel, plus 20 à 25 secondes pour démarrer KDE complètement. Et c'est un linux tout neuf avec tout à jour (Xorg 7.3 KDE 3.5.7 kernel 2.6.22 etc...).
        • [^] # Re: Pareil

          Posté par  . Évalué à 5.

          Hé! Tu pourrais au moins lancer un gros troll bien poilu en annonçant ta distrib et en expliquant finement que ça va plus vite parce qu'elle est mieux!
          • [^] # Re: Pareil

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

            Pas de troll (quoique...) mais des détails :
            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  . Évalué à 2.

              Donc attend voir ça fait 26+4+28: 58s.

              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  . Évalué à 3.

        Personnellement pour faire booter une debian en 25 secondes, je met juste la variable CONCURRENCY de /etc/init.d/rc à ''shell'' (startpar me pose trop de problèmes) et je réorganise un peu les rc?.d pour que les taches qui peuvent être lancées ensemble ai le même numéro après S

        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  . Évalué à 5.

      Ça fait longtemps que j'ai fait ce constat. Mais je me rassure en disant que Linux n'as jamais brillé par sa vitesse de démarrage. (Même Zindows démarre plus vite)

      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)...

      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. :-)

      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  (site Web personnel) . Évalué à 5.


        Parce que sur mon laptop, le XP il mets 3 fois plus de temps que ma Debian


        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  . Évalué à 2.

          Bah oui, j'ai réinstallé un XP Pro à la place de l'ancien en mettant dessus uniquement le strict nécessaire, en virant des services qui servent pas, etc...
    • [^] # Re: Pareil

      Posté par  . Évalué à 7.


      (Même Zindows démarre plus vite)


      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  (site Web personnel) . Évalué à 5.

    Les équipes de dev de Mac OS X ont fait un trés gros effort d'optimisation du démarrage et de mise en cache des paramètres lors du boot.

    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  . Évalué à 4.

      Ils utilisent tout simplement pas un init SysV ou BSD mais un machin plus moderne: launchd (remplaçant, init, crond, atd, inetd etc..)
      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  . Évalué à 1.

        Pas seulement il me semble, il y a aussi un mécanisme qui réarrange les donnée de telle façon a ce les accés disques soient optimisé:
        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  (site Web personnel) . Évalué à 5.

    Bon je suis nombriliste donc j'expose mon experience:
    -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  (site Web personnel) . Évalué à 1.

      Bon, j'en ai une sous la main alors je viens de chronométrer ...

      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  (site Web personnel) . Évalué à 2.

        Blah les BIOS .... Je les oublie toujours ces cochonneries ...
        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  (site Web personnel) . Évalué à 1.

          Bah pour iceweasel, c'est même pas vrai que ça bouge pas, y'a le curseur de souris qui montre une horloge qui tourne :) C'est pas pour rien qu'on l'a patché pour qu'il supporte libsn (startup-notification)

          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  . Évalué à 4.

    Pas mal de petits scripts sont fait en bash, ou autre. Ré-interpréter le tout à chaque fois, ça peut prendre du temps.

    Envoyé depuis mon lapin.

    • [^] # Re: Bash

      Posté par  . Évalué à 2.

      cela n'existe pas une moulinette bash2bin, car mes scripts une fois ecrit je n'y touche jamais. et le binaire compatible avec l'init.

      un genre de compilateur.
      • [^] # Re: Bash

        Posté par  . Évalué à 4.

        A ma connaissance, ça n'existe pas, et le problème en soit n'est pas forcément l'interprétation du langage. bash a le mérite d'être lisible et facilement modifiable, si on est obligé de compiler, on perd cet avantage.

        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  . Évalué à 7.

          Et est-ce que le problème ne viendrait pas aussi du nombre de fichiers à ouvrir ?
          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  . Évalué à 2.

          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, ...

          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  . Évalué à 6.

    je comprends que c'est pas mal d'avoir un ordinateur qui démarre vite, mais finalement ce n'est pas si important lorsque l'on peut le mettre en veille sur ram (consomme un peu) ou sur disque (ne consomme rien).
    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  (site Web personnel) . Évalué à 5.

      Sauf que l'hibernation est tellement mal foutue qu'il y a toujours un truc pour arreter de fonctionner une fois sortie de veille (sur mon nouveau portable, c'est le clavier ...
      • [^] # Re: mise en veille

        Posté par  . Évalué à 4.

        moi, c'est le wifi...
      • [^] # Re: mise en veille

        Posté par  . Évalué à 2.

        Ah oui, pour le clavier c'est embêtant :-/

        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  . Évalué à 2.

      Sur un portable avec 1.5 Go de RAM, c'est la misère, le retour
      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  . Évalué à 1.

    Qu'en pensez-vous ?

    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.
  • # Xorg

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

    Salut,

    Pour Xorg, l'avenir est quand même un peu plus rose. Le travail en amont permettra d'éviter la reprogrammation de la carte, de sorte que Linux gère bien l'affichage dès le démarrage et que Xorg n'ai pas à tout redédecter, etc. Ça clignotera plus, ça sera plus rapide et plus sécurisé. comme sous Mac OS X.

    Ensuite y'a init qu'il faudra un jour ou l'autre remplacer, c'est sûr. Tout ces scripts bash, c'est pratique, mais en production, on s'en fout un peu ! faudrait optimisé tout ça. upstart ne semble pas avoir reçu autant de boulot qu'il n'en mérite …

    Cordialement,
    • [^] # Re: Xorg

      Posté par  . Évalué à 6.

      pourquoi, en "production" est-il si vital d'avoir une machine qui reboote en 15 secondes au lieu de 50 secondes ?
      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  . Évalué à 4.

        Le en production est AMHA pas a prendre au sens serveur mais plutot au sens PC configuré et finit d'installer.
        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
        • [^] # Re: Xorg

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

          Exactement, c'est là que Mac OS X gère bien avec ses caches. Un démarrage lent, c'est compréhensible après une màj, et c'est suffisament rare.
      • [^] # Re: Xorg

        Posté par  . Évalué à 4.

        Le mieux n'est-il pas d'avoir une machine qui ne reboote pas du tout ?

        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  . Évalué à 2.

        pas qu'en production, aussi en embarqué le temps de boot peut etre important.
        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  (site Web personnel) . Évalué à 1.

      Ça m'intéresse ce que tu dis à propos de Xorg ... Tu veux dire que le kernel et Xorg seront intégrés ? J'ai lu un jour un article qui disait que c'était ce qu'il fallait faire mais je ne savais pas que c'était en route.

      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  . Évalué à 2.

        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.


        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  (site Web personnel) . Évalué à 1.

          Non, rien de particulier ... Je remarque juste que l'indicateur de remplissage de ma RAM et de ma swap augmentent toujours... Mais je ne remarque pas non plus vraiment de baisses de performances.

          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  . Évalué à 2.

            au pire des cas essaye de fermer toutes ces fenêtres (je fais pareil, avec konqueror), voire de quitter X, je ne pense vraiment pas que le redémarrage fasse quoi que ce soit de mieux.

            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  (site Web personnel) . Évalué à 2.

        Salut,

        Après discussion, il semblerai que framebuffer et drm vont fusionner afin d'offir une gestion unifié de la mémoire des GPU. Le but est que le noyau gère lui-même la configuration du mode de la carte (resolution, fréquence, couleurs, etc.) et qu'Xorg n'ai plus a accéder en root via /dev/mem aux registre de la carte.

        Benjamin Herrenschmidt m'a dit mot pour mot qu'il faut buter radeonfb ! (au moins sur ppc).

        Cordialement,
        • [^] # Re: Xorg

          Posté par  . Évalué à 3.

          Il y a un article qui va dans ce sens dans le "kernel corner" du GLMF de ce mois.
  • # jusqu'au prompt de login oui,

    Posté par  . Évalué à 4.

    Mais alors après, je sais pas ce qu'il charge, mais sur mon mac, il met une plombe pour lancer thunderbird, firefox et adium, J'en déduis qu'il doit charger un paquet de trucs après le login...
    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  . Évalué à 1.

      Fais gaffe, le long de mes interminables pérégrinations cybernétiques, j'ai vu avec une grande constance des utilisateurs de Mac OS X se plaindre que Firefox y soit bien plus lent et moins optimisé que sur Windows.
      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  . Évalué à 2.

        Lorsque tu fermes firefox et que tu le ré-ouvres aussitôt, tout est déjà en cache dans la mémoire (toutes les libs au moins), rien à charger sur le disque-dur, c'est rapide (ça marche même avec OpenOffice ;-))

        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  . Évalué à 1.

        Je n'ai pas été très clair, je pense.

        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  . Évalué à 2.

    Il y a aussi la mise en veille... Je n'utilise pratiquement que des logiciels libres sauf... pour l'OS.

    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  (site Web personnel) . Évalué à 3.

    c'est à dire la distribution ArchLinux personnalisée pour utiliser upstart


    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  . Évalué à 1.

    La seule chose qui m'avait semblé un peu longue sur Archlinux
    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  (site Web personnel) . Évalué à 4.

    Il manque quelques infos à tes essais. En particulier, est-ce que les deux environnements sont "fonctionnellement" équivalent ?
    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  (site Web personnel) . Évalué à 1.

      Je ne cherche pas vraiment à faire un test objectif, ni a chercher des conseils...

      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  (site Web personnel) . Évalué à 4.

    J'ai aussi un mactel et j'ai fait la même observation sur le temps de boot entre macosx rapide et Ubuntu lent.

    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  . Évalué à 2.

      Mais Ubuntu c'est lent à démarrer. Pas la peine d'avoir un mac pour le remarquer.

      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  . Évalué à 3.

        Ça dépend pour archlinux. Moi il me faut un peu moins d'une trentaine de seconde (sur la même machine que le journal), mais je pourrais encore gagner un peu. La solution ? Un noyau plus ou moins réduit à ce que j'ai besoin (bon, on gagne pas grand chose là dessus, mais un peu), lancer le moins de services possibles (j'ai pas de sshd, et de trucs comme ça, sur mon laptop soit je l'ai avec moi, soit il n'est pas allumé, généralement), et dans les services qui restent en lancer le plus possible en arrière plan (noter @service plutot que service dans /etc/rc.conf)
      • [^] # Re: Problème corrigé

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

        Je précise quand même que j'utilise upstart pour le démarrage et que j'ai l'impression que le driver de ma carte graphique est en cause pour le démarrage lent de xorg.

        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  (site Web personnel) . Évalué à 2.

        Je n'aurais jamais du dire que c'était ArchLinux !

        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  . Évalué à 3.

      avec une Mandriva 2007.0 (du vieux), je mets à tout péter 25 secondes à démarrer X depuis lilo, sur un AMD 3000+ (malgré udev and co). C'est franchement raisonnable, de plus ça semble encore plus rapide sur la RC1 de la 2008.0.

      J'imagine qu'avec un dual core, ça irait encore plus vite ...
      • [^] # Re: Problème corrigé

        Posté par  . Évalué à 2.

        Je mettais autant de temps avec une Debian sur la même machine... Et le double pour Ubuntu.
  • # essaye la ZenWalk

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

    Je ne sais pas si elle est compatible Mac, mais la ZenWalk est très rapide assurément plus que Windows.
  • # LinuxConsole

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

    http://linuxconsole.org
    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  . Évalué à 2.

    Ce journal me fait penser que je n'ai toujours testé runit :
    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  (site Web personnel) . Évalué à 1.

      Ça a l'air pas mal, et comme c'est simple, ça me tente.

      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  . Évalué à 2.

        Étonnant l'heure à laquelle tu as posté ton message... (cf mon heure à moi)

        IPoT ?

Suivre le flux des commentaires

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