Journal Rethinking PID 1

Posté par  (site web personnel) .
Étiquettes :
15
30
avr.
2010
Une entrée de blaug très interessante de Lennart Poettering (redhat, pulseaudio) sur le demarrage et le babysittage des differents demons et services sous Linux. Il parle de l'état actuel ( sysvinit ), de Apple qui une fois de plus montre la voix avec launchd, de upstart, pour finir par présenter son propre systeme d'init "systemd" . C'est de la bonne lecture, pédagogique et interessante.

http://0pointer.de/blog/projects/systemd.html
  • # .

    Posté par  . Évalué à 5.

    • [^] # Re: .

      Posté par  (site web personnel) . Évalué à 6.

      Oh, je vois la voie de la voix !
      • [^] # Re: .

        Posté par  . Évalué à 3.

        le sage montre la lune ... et tous les boulets vont faire une remarque sur la faute d'orthographe dans du journal
        • [^] # Re: .

          Posté par  . Évalué à 2.

          Le sage montre la lune ... et les boulets qui n'ont rien à dire continuent de reprendre les pensées des autres.

          14:48:06 NedFlanders le sage montre la lune ... et tous les boulets vont faire une remarque sur la faute d'orthographe dans mon journal
          Cf https://linuxfr.org//comments/1101596.html#1101596
        • [^] # Re: .

          Posté par  . Évalué à 2.

          Bon, le sage, il montre la lune ou la voie, faudrait choisir.
    • [^] # Re: .

      Posté par  . Évalué à -1.

      pas mal du tout (voix -> voie)
  • # La voie !

    Posté par  . Évalué à 5.

    Ça doit faire super mal de montrer la voix :-)
  • # [:aloyd]

    Posté par  . Évalué à 1.

    Toutes ces fautes me laisse sans voie...
  • # [:Mouaifff]

    Posté par  . Évalué à 9.

    Un système d'init écrit par le mec qui a pondu pulseaudio, je vais laisser passer mon tour si ça ne vous dérange pas.
    • [^] # Re: [:Mouaifff]

      Posté par  . Évalué à 8.

      Le principal de problème de PA c'est que derrière t'as ALSA et tout les pilotes pourris qui vont avec. T'as deux stratégies, soit tu fais avec et tu bidouilles ton daemon pour contourner les bogues (arts et ESD ont montré que cette solution avait des limites), soit tu retrousses les manches et tu aides à corriger les bogues dans ALSA.
      Le mec a sévi sur d'autres projets (il est également le dictateur d'Avahi entre autre)

      Ce qui est intéressant dans la conception de systemd, c'est qu'il a mis en parrallèle son expérience d'écriture de daemon (Cf libdaemon). Au final, le système est plus simple, plus léger et point important simplifie l'écriture de daemon (donc potentiellement moins de bogues).
      Si les développeurs de systemd arrive à créer une réelle dynamique autour du projet, ça pourrait d'ici un an, se retrouver sur bon nombre de machines.
      • [^] # Re: [:Mouaifff]

        Posté par  . Évalué à 10.

        Le problème avec le gestionnaire de démarrage c'est que c'est légèrement critique, et difficile à dépatouiller pour l'utilisateur moyen. Faire des changements disruptifs tous les deux ans (upstart, systemd...) au prétexte qu'on gagne trois secondes de temps de démarrage (au prix, assez ironiquement, de centaines ou milliers d'heures de développement, d'intégration, etc.) me semble légèrement irresponsable.

        J'ai l'impression que le développement de l'infrastructure Linux tient beaucoup de l'agitation moléculaire ces temps-ci. Ça bouge dans tous les sens, mais le mouvement global est à peu près nul.
        (vu de chez moi : ça marche ni mieux ni moins bien qu'il y a cinq ans)
        • [^] # Re: [:Mouaifff]

          Posté par  . Évalué à 9.

          Il n'y a pas que ton desktop :-)

          Aujourd'hui, il y a surement bien plus de Linux dans l'embarque que ailleur. Et ca va vraiment plus dans cette direction, smartbook, telephone, homeserver, tablette ...

          Toutes ces machines les gens s'attendent a ce qu'elle demarre instantanement. Alors ameliorer le temps de boot et optimiser le systeme, ca interresse beaucoup beaucoup d'utilisateurs, en fait surement la majorite et en plus ceux qui payent !

          D'un point de vue pragmatique, le projet qui va surement etre le plus interresse par ce nouvel init, ce sera MeeGo. Donc ca redescendra surement par toutes les distrib qui l'utiliseront.
          • [^] # Re: [:Mouaifff]

            Posté par  (site web personnel, Mastodon) . Évalué à 3.

            Aujourd'hui, il y a surement bien plus de Linux dans l'embarque que ailleur. Et ca va vraiment plus dans cette direction, smartbook, telephone, homeserver, tablette ...

            Toutes ces machines les gens s'attendent a ce qu'elle demarre instantanement. Alors ameliorer le temps de boot et optimiser le systeme, ca interresse beaucoup beaucoup d'utilisateurs, en fait surement la majorite et en plus ceux qui payent !


            Toutafait, attendre voir booter un Neo FreeRunner, ça fait super peur !
        • [^] # Re: [:Mouaifff]

          Posté par  (site web personnel) . Évalué à 7.

          au prétexte qu'on gagne trois secondes de temps de démarrage (au prix, assez ironiquement, de centaines ou milliers d'heures de développement, d'intégration, etc.)

          Ta façon de penser est bizarre : pour moi, si perdre des centaines ou milliers d'heures de développement est utile pour gagner 1 milliard de fois 3 seconde (soit 833 333 heures cumulées), alors oui ça vaut le coût, je ne vois donc pas ce qu'il y a d'ironique dans ce "prix" : beaucoup de monde travailler sur gagner des secondes de démarrage, ce n'est pas pour rien.

          Ça bouge dans tous les sens, mais le mouvement global est à peu près nul.

          Temps de démarrage réduit, ce n'est pas nul comme mouvement global, c'est demandé par les utilisateurs. Windows 7 a fait d'énormes progrès de ce côté (Microsoft a bossé dessus car c'était demandé par... Les utilisateurs), si Linux veut rentrer chez Madame Michu, Linux doit proposer un temps de démarrage égal (ou inférieur) à Windows 7 (entre autres caractéristiques)

          Toi tu te fous peut-être des autres utilisateurs, pas Canonical (et Redhat, et...)
          • [^] # Marchera pas.

            Posté par  . Évalué à -2.

            Pour avoir bidouillé pour essayer de réduire mon temps de démarrage,
            Démarrer tout en parallèle ça n'a jamais fait grand chose, c'est pas avec ça que l'on va démarrer beaucoup plus vite. Dans mes bidouillages, je suis rapidement coincé par le temps de démarrage de grub/linux et par un démon système de base, genre Udev, qui prend facilement 100% du CPU, et qui va énumérer les disques ET les bidules genre webcam/wifi/bluetooth qui ne servirons pas de suite, alors qu'il y a plus urgent à faire.

            Y a pas de miracle, si on veut démarrer vite, il faut avant tout faire moins. D'ailleurs, je suis surpris qu'il ne donne aucun résultat : combien de temps à t'il économisé ?
            • [^] # Re: Marchera pas.

              Posté par  . Évalué à 4.

              Y a pas de miracle, si on veut démarrer vite, il faut avant tout faire moins.
              Tout a fait sur un vieux pc, j'avais fait une init au petit oignon (dev statique, minimum de service) et ca démarrait très vite. Le plus lent était le démarage de X...
              En théorie sous debian il y a désormais un systeme d'init avec gestion des dépendance. Ce qui devrait permettre de démarrer l'essentiel le plus rapidement possible, sauf que les dépendances sont pas toujours au top [1].

              La parallélisation c'est très limité. Ca marche seulement pour les scripts qui bloque (sleep, attente IO), mais ça à un coût (l'ordonnanceur bosse, les IO ne sont plus séquentielles, ...)


              [1] l'utilisateur lambda n'a pas besoin d'avoir les disques réseau, donc du réseau avant de démarrer une session graphique.
            • [^] # Re: Marchera pas.

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

              Y a pas de miracle, si on veut démarrer vite, il faut avant tout faire moins.

              ... Ou mieux, plus vite, pour une même chose.
              Parce que si on reprend ta phrase tel quel, ça sert à rien qu'on se soit industrialisé, accéléré des processus, accéléré des processeurs, il suffisait de faire moins, tout simplement.

              Désolé, mais ça ne marche pas toujours comme ça : parfois (souvent même), revoir son algorithme peut permettre de grandement accélérer une tâche identique sur un matériel identique (dernièrement, j'ai fait un x10 sur une partie de code, sans rien enlever : j'ai "juste" cherché les goulots d'étranglement, et je les ai optimisés)

              Et pour info, Windows 7 fait plus de choses au démarrage que Vista, le tout plus vite. Comme quoi... Ca marche même pour les OS.
              • [^] # Re: Marchera pas.

                Posté par  . Évalué à 2.

                Je pense qu'il voulait plutôt faire référence à l'article :

                « For a fast and efficient boot-up two things are crucial:

                * To start less.
                * And to start more in parallel.

                What does that mean? Starting less means starting fewer services or deferring the starting of services until they are actually needed. There are some services where we know that they will be required sooner or later (syslog, D-Bus system bus, etc.), but for many others this isn't the case. For example, bluetoothd does not need to be running unless a bluetooth dongle is actually plugged in or an application wants to talk to its D-Bus interfaces. Same for a printing system: unless the machine physically is connected to a printer, or an application wants to print something, there is no need to run a printing daemon such as CUPS. Avahi: if the machine is not connected to a network, there is no need to run Avahi, unless some application wants to use its APIs. And even SSH: as long as nobody wants to contact your machine there is no need to run it, as long as it is then started on the first connection. (And admit it, on most machines where sshd might be listening somebody connects to it only every other month or so.) »
                • [^] # Re: Marchera pas.

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

                  Je pense qu'il voulait plutôt faire référence à l'article :

                  Alors je ne suis pas d'accord avec l'article :).
                  (On peut aussi changer les composants "lents" par des plus optimisés, ça demande du boulot certes mais c'est très faisable et souvent la seule voie à prendre quand on a déjà fait les deux autres propositions plus faciles à réaliser)
                  • [^] # Re: Marchera pas.

                    Posté par  . Évalué à 2.

                    Pour systemd c'est prévu de réécrire tous les scripts d'init en C au lieu de simples scripts shell (contenus dans /etc/init.d/).
                    • [^] # Re: Marchera pas.

                      Posté par  (site web personnel) . Évalué à 5.

                      Ca c'est idiot car on retrouve dans la position de Windows avec des trucs binaires dont personne ou presque ne comprends rien au fonctionnement.

                      La force d'UNIX est aussi d'avoir des parties importantes en script facilement modifiable et modelable.
                      • [^] # Re: Marchera pas.

                        Posté par  . Évalué à 4.

                        Rien n'empêche d'avoir un dossier contenant le code source qu'on pourrait facilement modifier, compiler puis installer dans le répertoire contenant les binaires.

                        Et ça permettrait un temps de démarrage beaucoup plus rapide, car notamment moins de processus sont créés (dans l'article un ordre de grandeur est donné avec la commande « echo $$ » exécutée juste après le démarrage : Linux PID 1823; MacOS PID 154).
                        • [^] # Re: Marchera pas.

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

                          Qui n'a jamais mis un LANG=C en début de script pour éviter les messages en Francais... Qui n'a jamais bidouillé les dépendances... Qui n'a jamais lu un script pour comprendre comment ce p... de service fonctionnait. Un exemple rapide qui me vient en tête, l'option --ghost de l'automonteur AutoFs ne fonctionne pas de la même manière sous debian et sous Suse, la version debian se règle par table d'automount alors que celle de Suse est globale (donc inutilisable). Seule la lecture des script d'init m'a permit de comprendre cela facilement. La lecture du code C est bien moins évidente pour certains administrateurs systèmes (dont moi).

                          Avoir des fichiers en scripts permet de savoir exactement comment sont lancés les services et d'en faire soit même en quelques instant. Je doute que le gain soit aussi important que cela (sauf sur les équipements de type téléphone portable mais la problématique n'est pas tout à fait la même).

                          Un des problèmes des scripts en bash peut être effectivement le nombre de sous processus, alors pourquoi ne pas les écrire en Perl6 avec mise en cache en bytecode parrot ;-)
                      • [^] # Re: Marchera pas.

                        Posté par  . Évalué à 3.

                        Alors on doit aussi réécrire le noyau en shell parce que sinon "on se retrouve avec des trucs binaires dont personne ou presque ne comprends rien au fonctionnement" ? Les scripts d'init, on n'a normalement pas besoin de la bidouiller à la main tous les 4 matins. Et puis entre nous un code C me semble plus lisible que du shell qui permet très facilement de se prendre les pieds dans le tapis sans s'en rendre compte (espaces significatifs, etc).
                        • [^] # Re: Marchera pas.

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

                          Justement, si le tout binaire est mauvais, le tout script n'est pas mieux. Il faut simplement trouver un juste équilibre et mettre de la souplesse au bon endroit et non partout.
                      • [^] # Re: Marchera pas.

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

                        C'est idiot d'utiliser des scripts shell là où c'est inutile. A mon avis, les scripts shell est la raison principale du temps de démarrage long. Parce que forker pour chaque grep ou awk, au final, ça prend du temps.

                        Et c'est pas pour dire, mais ton script shell qui va lancer ton fsck, ça m'étonnerait que tu y touches souvent. Et pour celui qui lance apache httpd, c'est aussi bien d'avoir la même chose dans un fichier de configuration .desktop
                        • [^] # Re: Marchera pas.

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

                          Et ou je rajoute export LANG=C dans ton fichier .desktop ?

                          Le problème est que tu perds toute souplesse car ton fichier .desktop ne permet de résoudre qu'un problème de dimension fini connu à l'avance. Or, l'expérience montre qu'on se retrouve toujours un jour ou l'autre devant un cas non prévu et c'est la qu'il faut alors de la souplesse.

                          Je me méfie beaucoup des "On crois", avant de tirer un vu sur un système qui a fait ses preuves question maintenance, je voudrais savoir de manière chiffré le vrai temps perdu par ces fork.

                          Si ces fork prenait réellement un temps fou, je préférerais alors adopter un langage de script plutôt que de basculer en C et rendre encore un peu plus le système obscure.
                    • [^] # Re: Marchera pas.

                      Posté par  (site web personnel) . Évalué à 4.

                      Pourquoi ne pas les écrire plutôt en assembleur avec des optimisations de la mort qu'un stupide compilateur pourra jamais atteindre ? :P
              • [^] # Re: Marchera pas.

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

                Parce que si on reprend ta phrase tel quel, ça sert à rien qu'on se soit industrialisé, accéléré des processus, accéléré des processeurs, il suffisait de faire moins, tout simplement.

                Mais tout à fait, d'ailleurs je propose de, oh puis non pfff…
            • [^] # Re: Marchera pas.

              Posté par  (Mastodon) . Évalué à 3.

              En pensant "desktop", le temps de "boot" n'est pas plombé par les services, le gros point noir c'est les services bureau, non ?

              Un temps de démarrage résumé (machine aspire one)
              Kernel -> (grub à 1 + Kernel lui même + initrd) : 4 secondes
              Services -> entre 6 et 7 secondes, pour tout.
              Bureau -> entre 7 et 8 secondes.
              Ici en plaçant le serveur Xorg comme étant dans les services. Et le bureau est Gnome.
              Le temps total oscille entre 17 et 21 secondes.

              En changeant de bureau pour prendre LXde, on obtiens ceci :
              Kernel -> 4 secondes
              Services -> entre 6 et 8
              Bureau -> entre 2 et 3 secondes
              Le temps total oscille entre 12 et 15 secondes.

              En enlevant certains services, ce temps tombe entre 10 et 12 secondes. En compilant un noyau "monolithique" je n'ai rien gagné (ou si peu), tout est compilé en dur et juste pour ce matos là sans rien d'autre, pas d'initrd donc. (me disait gagner un chouilla sans initrd, bof c'est pas visible...pourtant le noyau est resté léger)

              A noter que la première mesure se fait sur un bureau Gnome vierge (ie : par défaut mais ayant déjà lancé une fois). Bien entendu ces chiffres sont à prendre avec des pincettes : ils ne reflètent qu'une expérience utilisateur et ne peuvent nullement être considérés comme valides. Les bureaux (kde et gnome) sont des veaux au démarrage. Et je sais ne pas savoir pourquoi d'une part, ni ne pas savoir ce que ça m'apporte vraiment d'autre part. LXde me suffit : cliques dans pcmanfm et la clef/carte/cd est monté.

              -> Savez vous s'il existe un outil de type de bootchart mais dédié aux (ou à un) bureau ?
              • [^] # Re: Marchera pas.

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

                -> Savez vous s'il existe un outil de type de bootchart mais dédié aux (ou à un) bureau ?

                bin Bootchart2 ;-)
                j'avais essayé en mars sur une Cooker (bêta 2)
                http://cookerspot.tuxfamily.org/wikka.php?wakka=Blog20100329(...)

                Ça donne à peu près 45 secondes :
                http://download.tuxfamily.org/cooker/images/bootchart/e6400_(...) [~500 ko]

                Mais en 2010.0 avec le bootchart (1.0), il y avait déjà une idée du temps de boot (avec Gnome il est vrai) sans aucune optimisation sur un eee pc 901 (cf. page au-dessus).

                Je vais refaire des tests avec l'eee pc 901 en Mandriva Linux Cooker 2010.1 pour voir si les temps que j'avais constatés lors de la bêta sont avérés en rc aussi.
              • [^] # Re: Marchera pas.

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

                C'est pour ça qu'il veut aussi utiliser systemd pour la session utilisateur:

                More importantly however, it is also our plan to experiment with systemd not only for optimizing boot times, but also to make it the ideal session manager, to replace (or possibly just augment) gnome-session, kdeinit and similar daemons. The problem set of a session manager and an init system are very similar: quick start-up is essential and babysitting processes the focus. Using the same code for both uses hence suggests itself. Apple recognized that and does just that with launchd. And so should we: socket and bus based activation and parallelization is something session services and system services can benefit from equally.
          • [^] # Re: [:Mouaifff]

            Posté par  . Évalué à -1.

            Ta façon de penser est bizarre : pour moi, si perdre des centaines ou milliers d'heures de développement est utile pour gagner 1 milliard de fois 3 seconde (soit 833 333 heures cumulées),

            Ce qui est bizarre, c'est de penser que ces secondes sont "gagnées". Cela supposerait qu'elles sont actuellement "perdues", ce qui est ridicule. Les tâches effectuées sur un ordinateur sont des tâches intellectuelles, on ne peut pas les "optimiser" en grapillant une seconde de-ci de-là.

            C'est un peu comme si on cherchait à optimiser le temps de rasage ou à pisser plus rapidement, sous prétexte que cela fait gagner du temps. C'est pire que de la comptabilité d'épicier, c'est absolument inepte.

            (note : on va en général plus souvent pisser qu'on ne reboote son ordinateur)

            Microsoft a bossé dessus car c'était demandé par... Les utilisateurs

            Windows demande à être souvent rebooté pour des raisons diverses, notamment pendant les procédures d'installation, ce qui est là assez pénible. Donc, oui, je comprends que sous Windows ce soit important d'optimiser le temps de démarrage (la vraie solution serait évidemment d'éviter les reboots intempestifs).
            • [^] # Re: [:Mouaifff]

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

              C'est un peu comme si on cherchait à optimiser le temps de rasage ou à pisser plus rapidement, sous prétexte que cela fait gagner du temps. C'est pire que de la comptabilité d'épicier, c'est absolument inepte.

              Pour toi peut-être. Mais si tu as des solutions pour accélérer ça, je suis preneur (pour le rasage, j'ai trouvé une solution : je ne me rase plus beaucoup :-D ).

              Si pour toi perdre du temps devant un ordi qui boote est agréable, ça ne l'est pas pour d'autres, désolé.

              "dit-moi ce dont tu as besoin, je te dirais comment t'en passer" est la meilleur solution pour que Linux ne soit pas utilisé, bizarrement ceux qui codent n'ont pas cet avis.

              Windows demande à être souvent rebooté pour des raisons diverses, notamment pendant les procédures d'installation, ce qui est là assez pénible

              Faudrait te mettre à jour sur le sujet, ce n'est plus le cas.
              Sinon, quand tu mets à jour ton kernel Linux, tu ne reboote pas? Tu es très fort...
              Et comme l'ont dit d'autres : pensent à d'autres périphériques (genre... Smartphones, tu sais le truc à la mode en ce moment)

              Ce n'est pas parce qu'on ne boote pas souvent qu'ont ne veut pas que ça aille vite (je dois rebooter mon Windows genre une fois par mois ne t'en déplaise, le rets du temps c'est en suspend to RAM, et c'est quand même chiant les boots qui sont longs, c'est comme ça... Pour beaucoup de monde)
              • [^] # Re: [:Mouaifff]

                Posté par  . Évalué à 2.

                Sinon, quand tu mets à jour ton kernel Linux, tu ne reboote pas?

                Si si... ça arrive une fois tous les trois mois, peut-être. Et quand ça reboote je peux me faire un thé, ou aller pisser tout simplement.

                Ce n'est pas parce qu'on ne boote pas souvent qu'ont ne veut pas que ça aille vite

                Oh, bien sûr.
                C'est juste que dans une existence où on passe entre une et deux heures par jour dans les transports, une heure à se sustenter, trente minutes (minimum) pour les diverses nécessités de l'hygiène, etc. ... considérer le temps de boot (une minute par jour ?) comme une contrainte importante, c'est totalement pathétique. C'est du pur délire de geek technocentré, le même genre qui pense que le bureau 3D va enfin faire migrer les masses sous Linux.

                (et, aussi chiants soient les fans d'Apple, je n'en ai jamais entendu un seul m'expliquer que les Macs étaient mieux parce qu'ils bootaient plus rapidement... ce qui montre bien à quel point cette métrique est non-pertinente)

                Et pour terminer sur une note plus terre-à-terre, à propos de ce temps de boot : la majorité du temps "perdu" n'est pas dû au démarrage du système proprement dit (scripts d'init et démons divers), mais au fait de redémarrer toutes les applis que j'utilise, initialiser les connexions IMAP & co.
                (il y aussi le fsck occasionnel qui, lui, pour le coup, bouffe beaucoup de temps)
                • [^] # Re: [:Mouaifff]

                  Posté par  (site web personnel) . Évalué à 4.

                  > les fans d'Apple, je n'en ai jamais entendu un seul m'expliquer que les Macs étaient mieux parce qu'ils bootaient plus rapidement... ce qui montre bien à quel point cette métrique est non-pertinente

                  Normal que les fans de mac s'en fouttent totalement, quand tu as un mac tu le laisse en veille, tu ne l'arrête pas.
                  Mon mac, y compris lorsque je l'utilisais de manière pro, passe facilement 1 mois sans être redémarré.
                  Je lève l'écran et hop il fonctionne, j'ai mon environnement fonctionnel, reste juste à attendre un peu le wifi.
                  J'arrête de bosser ? je le rabat et c'est fini.

                  Donc la problématique de l'arrêt redémarrage est tout autre...

                  Par contre, j'ai été très agréablement surpris par ma mandriva sur mon portable de boulot (Dell E6400) où la mise en veille fonctionne de manière assez correcte, pas aussi parfaite, mais c'est utilisable de manière ponctuellement quand même.

                  > il y aussi le fsck occasionnel qui, lui, pour le coup, bouffe beaucoup de temps
                  Ca existe encore ? Ca fait bien longtemps que j'en ai pas eu...
                • [^] # Re: [:Mouaifff]

                  Posté par  . Évalué à 2.

                  Si si... ça arrive une fois tous les trois mois, peut-être. Et quand ça reboote je peux me faire un thé, ou aller pisser tout simplement.

                  Et bien moi, ça m'arrive beaucoup plus souvent, c'est parce que ma carte réseau déconne ou parce qu'il faut que j'utilise un programme sous Windows.

                  Pense à tous les gens qui font la transition Windows -> Linux, il faudra qu'ils redémarrent souvent, s'ils perdent 10 minutes à chaque fois, ça va vite les faire chier.

                  « 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: [:Mouaifff]

                Posté par  (Mastodon) . Évalué à -1.

                Faudrait te mettre à jour sur le sujet, ce n'est plus le cas.
                ça t'ennuie pas si je répond que non ? non pas envie de me mettre à jour sur windows. Désolé. La référence c'est gnu/linux et point barre. D'ailleurs je dois pas être seul vu que windows s'est amélioré sur le sujet.

                /mode évidence :
                d'accord
                • [^] # Re: [:Mouaifff]

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

                  non pas envie de me mettre à jour sur windows. Désolé.

                  Antoine critiquait Windows. Pour critiquer, vaut mieux être à jour.
                  Après, que tu veuilles faire l'autiste et ne surtout ne pas regarder la concurrence, libre à toi tant que tu ne craches pas sur cette concurrence sur des choses vielles de 5 ans...
        • [^] # Re: [:Mouaifff]

          Posté par  (site web personnel) . Évalué à 4.

          Je pense que tu devrais ressortir un systéme d'il y a 5 ans pour voir qu'il y quand même eu du changement. Les isos sont surle web, fait l'expérience ( et un journal pour nous raconter ça ). J'ai personnelement souvent des trucs minucules qui manquent quand je vais sur le pc que j'ai mis à mes parents, avec 3 ans de retard sur les distros courantes ( par manque de temps pour la mise à jour ).
      • [^] # Re: [:Mouaifff]

        Posté par  . Évalué à 4.

        C'est marrant parce que tant que j'avais dmix/plug sur mon PC tout fonctionnait à merveille. Du jour ou la distrib' (mandriva à l'époque) à commencé à coller PA ça a commencé par merder grave, alors dire qu'alsa est pourri je veux bien mais tout lui coller sur le dos c'est abuser.

        Alors on va me dire oui mais PA ça fait plus de choses et tout, mais ça sert à rien si ça ne permet pas de faire une chose simple et de base : mixer deux (ou +) source sonores pour n'en faire qu'un flux en entrée de la carte son.

        donc PA ça commence à fonctionner (et encore hier soir je l'ai surpris à passer au delà des 10% de CPU sur un top et qu'en plus y'avais rien qui sortait des enceintes) mais ce n'est pas sans peine, et ce n'est pas fini.
        • [^] # Re: [:Mouaifff]

          Posté par  . Évalué à 3.

          Je pense qu'il ne doit plus y avoir grand monde qui n'a pas PA ou qui veut le désactiver.
          Pour moi PA est totalement indispensable (et pas que pour mixer des sons).
          Consommation CPU quand il ne fait pas de rééchantillonnage : 0,2 % sur un core2 qui a presque 4 ans.
          • [^] # Re: [:Mouaifff]

            Posté par  (site web personnel, Mastodon) . Évalué à 2.

            Moi j'ai pas (sous Arch). Je m'en porte très bien (et j'ai testé PA, et même fais un détour par OSS, mais non, retour à la case départ).
          • [^] # Re: [:Mouaifff]

            Posté par  . Évalué à 0.

            J'ai pas, sur aucune de mes machines, toutes Gentoo powered.

            Chaque fois que j'ai essayé PA, je m'en suis mordu les doigts pour finalement en revenir.

            Le comble étant avec mythdora et mythbuntu où il m'a été impossible de dire que je ne voulais pas le son sur la sortie hdmi mais UNIQUEMENT sur la sortie SPDIF/Toslink vers l'ampli.

            Alors que avec ALSA tout seul, une fois revenu sous Gentoo, un tout petit .asoundrc de 5 lignes, un mute de la sortie son hdmi dans alsamixer, et hop, ça juste marche. Et c'est pas sur du matos exotique, un chipset intel tout ce qu'il y a de normal.

            Donc, à mon avis, PA est merdique à l'heure actuelle. De plus, ça doit être moi, j'ai jamais réussi avec PA à avoir une vue complète de tous les mixers de ma carte son... Et ça, ça me broute. (Et quand on a une SB Live Platinium, benh ça fait chier !)

            cd /pub && more beer

        • [^] # Re: [:Mouaifff]

          Posté par  (Mastodon) . Évalué à 4.

          J'vais faire l'avocat de P.A sur ce coup là \o/ (bien qu'ayant eu le même ressenti alors car une expérience similaire)

          PulseAudio était un projet jeune. L'intégration dans les distributions a permis certainement de le faire avancer plus vite. Est ce que Mandriva a eu raison, en tant que distribution grand public, d'intégrer un projet aussi jeune aussi vite ? Je ne sais pas (et finalement la question de savoir si n'avoir qu'une seule distrib c'est bien) Ce qui est sûr par contre c'est qu'en faisant également cet effort, Mandriva a participer à l'effort dès le départ. Et à pleinement jouer un rôle d'intégrateur d'une part et de travail en commun directement avec les projets d'autre part. Chapeau à eux, non ?

          Donc objectivement on peux pas, il me semble, reprocher à P.A ses erreurs de jeunesse éternellement. Tout comme on ne peux pas objectivement, il me semble, tout rejeter sur Alsa en disant "c'est de la faute de alsa" (c'est faux et malhonnête : alsa a certainement des difficultés et des merdes, n'empêche que ça marche et que d'autres serveurs de son s'en sortent bien mieux avec des contraintes bien plus importantes. De plus si c'était vraiment "de la faute de alsa" pourquoi s'être lancé sur P.A plutot que sur Alsa ? non il y avait bien un manque et ce manque se situait au dessus, P.A est venu combler ce manque). On pourrait aussi dire (et certainement de manière "plus vraie") que beaucoup de problème de P.A incombent en fait à Dbus, non ??
    • [^] # Re: [:Mouaifff]

      Posté par  . Évalué à 2.

      A lire sa description gourmande du système de démarrage générique et polyvalent, ce type est un "architecture astronaut" comme les croque Joel Spolsky:
      http://www.joelonsoftware.com/articles/fog0000000018.html
      • [^] # Re: [:Mouaifff]

        Posté par  . Évalué à 5.

        C'est surtout un mec très compétent et qui maitrise son sujet. On n'explique clairement que ce que l'on connait bien.
      • [^] # Re: [:Mouaifff]

        Posté par  (site web personnel) . Évalué à 8.

        À une différence prés :
        "These are the people I call Architecture Astronauts. It's very hard to get them to write code or design programs, because they won't stop thinking about Architecture."

        Et si tu as bien lu l'article, tu peux voir qu'il y a déja un dépot git, qui marche, qu'il est pas seul à coder dessus, et qu'il y a même des VMs de test afin de montrer que ça marche.
    • [^] # Re: [:Mouaifff]

      Posté par  . Évalué à 3.

      Je sais plus qui disais sur ce site dans un commentaire fort pertinent que c'était étonnant comme l'intégration raté de pulse audio dans Fedora/Ubuntu lui avait pourris la réputation.

      Ceci dit ta remarque témoigne sans aucun doute de la puissance de ton analyse.
      • [^] # Re: [:Mouaifff]

        Posté par  . Évalué à 7.

        Juste Ubuntu, alors.
        Pour Fedora, c'est l'audio terrorist himself qui s'est occupé de l'intégration, les mainteneurs Debian, et Mandriva ont eu l'idée saugrenue de lui demander conseil et chose surprenante, il les a aidé. En revanche, Ubuntu a intégré PA à la va-vite sans même prendre le temps de lire le wiki ou les listes de diffusions alors que de l'aveu même de son auteur, ça demande quelques efforts d'adaptation (des patchs pour le kernel, alsa, applications, etc ..). OpenSuSE eux avaient eu le bon goût de fournir des paquets défraichis avec des bogues corrigés dans des versions publiés quelques mois avant.
        La première étape pour devenir un bon mainteneur de distribution, c'est de communiquer avec upstream, avec PA c'est même indispensable sinon on coure droit à la catastrophe.

        LP s'était expliqué à ce sujet après une série d'articles négatifs (limite violents) sur PA:
        http://0pointer.de/blog/projects/jeffrey-stedfast.html
  • # Non au démarrage rapide ...

    Posté par  (site web personnel) . Évalué à 7.

    Avoir un démarrage lent me permet de tranquillement faire mon café le matin et quand j'arrive devant l'ordi avec mon café, j'ai l'écran de login.
    Sinon je vais devoir faire "tune2fs -c 1 /dev/sda1" pour ralentir le démarrage ...

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

    • [^] # Re: Non au démarrage rapide ...

      Posté par  (site web personnel) . Évalué à 8.

      Ben ça fonctionne aussi avec un démarrage rapide : quand tu arriveras devant l'ordi avec ton café, il en sera toujours l'écran de login :)
      • [^] # Re: Non au démarrage rapide ...

        Posté par  (site web personnel) . Évalué à 10.

        Sauf que si mon ordi est prêt à travailler (donc l'écran de login), ça veut dire que je suis "disponible" pour répondre aux éventuels besoins immédiat des utilisateurs/serveurs/... Là je peux encore dire "ah, ben attends, mon ordi il démarre et je m'occupe de ça tout de suite. Quoi c'est le 4ème checkdisk de suite ? N'importe quoi !".

        Bon je peux toujours faire le daemon suivant :

        #!/bin/bash
        echo "Starting hyper-server supervisor and management daemon (hyper important)"
        sleep(600)

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

  • # C'est quoi le démarrage ?

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

    Bah pourquoi démarrer rapidement ? Une fois que c'est démarré on ne l'arrête plus et le problème est réglé alors perdre 1 minutes de temps en temps lors d'une mise a jour kernel parce qu'on a pas envie de configurer kexec ...

    ps : j'emmerde la nature et l'écologie et j'utilise une centrale a pétrole pour alimenter en électricité les 5kW nécessaire pour la maison :)
    • [^] # Re: C'est quoi le démarrage ?

      Posté par  . Évalué à 5.

      Parce que si tu as comme moi, une carte réseau de merde sur un portable, tu es obligé de redémarrer de temps en temps parce qu'elle a décidé de ne plus fonctionner.

      « 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: C'est quoi le démarrage ?

      Posté par  . Évalué à 3.

      Un peu HS, mais est qu'il y a des distribution qui utilise kexec lors de l'installation ? Exemple: à la fin de l'installation, "sync" puis "kexec" sur le noyau installé. J'avais entendu ça dans les suggestions pour mandriva, mais je n'ai jamais su ce qu'il en était advenu...
      • [^] # Re: C'est quoi le démarrage ?

        Posté par  (Mastodon) . Évalué à 2.

        Kexec c'est génial. "A l'époque" j'avais posé la question, la réponse est simple : cela ne fonctionne pas pour tout les matos (et faire des workarounds ou des listes d'exclusion juste pour ça serait l'enfer je présume). Donc Kexec n'est pas viable de manière "industrielle", c'est typiquement le genre de trucs qu'on utilise pour soi sur ses machines car on les connait et on sait ce qu'on fait avec.

        Il me semble bien avoir vu un "reboot" de système d'installation ne pas passer par le bios, effectivemement, vers 2009.0...mais je ne sais plus si je l'ai rêvé ou pas ... En tout cas le reboot après install passe bien par un reboot complet et belle vue sur le bios : donc il n'y a pas de Kexec, là.

        /me qui s'est déjà gourrer à faire un $ fastboot au lieu de faire un $ ./fastboot (...) rien à voir avec kexec, mais drôle ...
  • # Pourquoi ?

    Posté par  . Évalué à 2.

    C'est quoi son objectif ? La vitesse de boot ? Ca a pas l'air très convaincant au vu du seul chiffre qu'il donne (Ok, il dit que ce chiffre ne veut rien dire).

    Et puis les requirements qu'il donne pour les daemons, c'est quand même pas rien, il doit y avoir pas mal de services qui ne marchent pas out of the box avec systemd.

    Bref, c'est loin d'arriver sur le desktop tout ça...
    • [^] # Re: Pourquoi ?

      Posté par  . Évalué à 0.

      et d'ici que ce soit intégré dans debian /o/
      • [^] # Re: Pourquoi ?

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

        Surtout que Debian parle d'intégrer upstart pour la prochaine version (squeezy + 1) donc c'est vraiment pas gagné :)
    • [^] # Re: Pourquoi ?

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

      En même temps, il n'y a pas besoin de tout intégrer d'un coup, il y a une couche de compatibilité.
      • [^] # Re: Pourquoi ?

        Posté par  . Évalué à -3.

        $ man humour

        Tu dois pas te marrer tous les jours toi :)
    • [^] # Re: Pourquoi ?

      Posté par  . Évalué à 3.

      Et puis recoder tout les scripts init en C, c'est une grosse connerie :
      - ca va etre sympa a modifier
      - le C c'est super adapté à la manipulation de chaine

      Alors que résoudre le pb est assez simple : limité les scripts init à un certain nombre de commande et utiliser un shell avec les built-in adéquat.
      • [^] # Re: Pourquoi ?

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

        En même temps, c'est pas une obligation, tu peux tout à fait utiliser C++ ou même une langage plus haut niveau tel Ruby ou Python.

        Tout ce que Lennart dit c'est que les scripts shell ne sont absolument pas performants car pour la moindre action ils lancent des milliards (oui, j'exagère un petit peu) de processus.

        Exemple :

        [ -d "$(basename "$file")" ] && echo "Le dossier existe."

        => Paf ! Trois processus lancés en plus de l'interprète de commandes.
  • # Calme avec Apple

    Posté par  (site web personnel) . Évalué à 9.

    de Apple qui une fois de plus montre la voix avec launchd

    Bon le temps gagné avec launchd, ils l'ont perdu dans les fichiers de configuration XML ...
    Ensuite ils n'ont pas fait quelque chose de nouveau puisqu'un système similaire était sorti auparavant dans Solaris (janvier 2005).

    Combien de fois il faut rappeler qu'Apple n'a rien inventer, même pas sa propre marque : http://en.wikipedia.org/wiki/Apple_Corps

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

  • # Gentoo

    Posté par  (site web personnel) . Évalué à 4.

    La partie dépendance entre les service me fait beaucou penser à celle de Gentoo ( http://www.gentoo.org/doc/fr/handbook/handbook-x86.xml?part=(...) ).
  • # Dans le même genre

    Posté par  . Évalué à 2.

    En alternative à init, du style léger cette fois, il y a runit : http://smarden.org/runit/
  • # launchd?

    Posté par  . Évalué à 1.

    Tiens, ils en parlent justement dans le linux mag de ce mois
    • [^] # Re: launchd?

      Posté par  . Évalué à 2.

      L'article en question parle du système de démarrage sous GNU/Linux et il y a une partie sur Upstart puis une bafouille sur launchd (très bon article au passage).

      Launchd est sous licence Apache 2.0, ça se configure à l'aide de fichiers plist (un format xml somme toute classique), avec des outils amicaux. OS X démarre très rapidement et c'est très agréable d'utilisation mais mon expérience s'arrête là. :o)
      http://developer.apple.com/macosx/launchd.html
      Il avait été un temps évoqué d'utiliser launchd dans Fedora mais le choix s'est porté sur Upstart qui semblait prometteur et très actif à l'époque (c'était déjà Harald Hoyer qui s'en occupait côté Fedora)

Suivre le flux des commentaires

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