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
Journal Rethinking PID 1
30
avr.
2010
# .
Posté par yastupin . Évalué à 5.
[^] # Re: .
Posté par Ramón Perez (site web personnel) . Évalué à 6.
[^] # Re: .
Posté par grid . Évalué à 3.
[^] # Re: .
Posté par tesiruna . Évalué à 2.
14:48:06 NedFlanders le sage montre la lune ... et tous les boulets vont faire une remarque sur la faute d'orthographe dans mon journalCf https://linuxfr.org//comments/1101596.html#1101596
[^] # Re: .
Posté par El Titi . Évalué à 2.
[^] # Re: .
Posté par DrBuenol . Évalué à -1.
[^] # Re: .
Posté par ianux (site web personnel, Mastodon) . Évalué à -1.
# La voie !
Posté par HardShooter . Évalué à 5.
[^] # Re: La voie !
Posté par El Titi . Évalué à 7.
Le pire c'est de donner de la voie.
En 68, c'est ce qu'ils ont fait et les CRS n'ont pas aimé les pavés.
[^] # Re: La voie !
Posté par El Titi . Évalué à 6.
Cette expression existe vraiment:
http://fr.wiktionary.org/wiki/donner_de_la_voie
[^] # Re: La voie !
Posté par Rémi Birot-Delrue . Évalué à 3.
# [:aloyd]
Posté par Dabowl_75 . Évalué à 1.
[^] # Re: [:aloyd]
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Sans chien, je comprendrais, mais là...
# [:Mouaifff]
Posté par dguihal . Évalué à 9.
[^] # Re: [:Mouaifff]
Posté par GeneralZod . Évalué à 8.
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 Antoine . Évalué à 10.
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 cedric . Évalué à 9.
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 ianux (site web personnel, Mastodon) . Évalué à 3.
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 Zenitram (site web personnel) . Évalué à 7.
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 Batchyx . Évalué à -2.
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 M . Évalué à 4.
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 Zenitram (site web personnel) . Évalué à 1.
... 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 Sébastien Wilmet . Évalué à 2.
« 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 Zenitram (site web personnel) . Évalué à 2.
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 Sébastien Wilmet . Évalué à 2.
[^] # Re: Marchera pas.
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
La force d'UNIX est aussi d'avoir des parties importantes en script facilement modifiable et modelable.
[^] # Re: Marchera pas.
Posté par Sébastien Wilmet . Évalué à 4.
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 Sytoka Modon (site web personnel) . Évalué à 3.
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 Croconux . Évalué à 3.
[^] # Re: Marchera pas.
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
[^] # Re: Marchera pas.
Posté par Mildred (site web personnel) . Évalué à 3.
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 Sytoka Modon (site web personnel) . Évalué à 2.
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 psychoslave__ (site web personnel) . Évalué à 4.
[^] # Re: Marchera pas.
Posté par psychoslave__ (site web personnel) . Évalué à 1.
Mais tout à fait, d'ailleurs je propose de, oh puis non pfff…
[^] # Re: Marchera pas.
Posté par bubar🦥 (Mastodon) . Évalué à 3.
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 BAud (site web personnel) . Évalué à 3.
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 Mildred (site web personnel) . Évalué à 2.
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 Antoine . Évalué à -1.
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 Zenitram (site web personnel) . Évalué à 2.
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 Antoine . É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.
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 CrEv (site web personnel) . Évalué à 4.
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 claudex . Évalué à 2.
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 bubar🦥 (Mastodon) . Évalué à -1.
ç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 Zenitram (site web personnel) . Évalué à 3.
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 Misc (site web personnel) . Évalué à 4.
[^] # Re: [:Mouaifff]
Posté par dguihal . Évalué à 4.
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 IsNotGood . Évalué à 3.
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 ianux (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: [:Mouaifff]
Posté par Fopossum . Évalué à 0.
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 bubar🦥 (Mastodon) . Évalué à 4.
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 Antoine . Évalué à 2.
http://www.joelonsoftware.com/articles/fog0000000018.html
[^] # Re: [:Mouaifff]
Posté par GeneralZod . Évalué à 5.
[^] # Re: [:Mouaifff]
Posté par Misc (site web personnel) . Évalué à 8.
"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 monde_de_merde . Évalué à 3.
Ceci dit ta remarque témoigne sans aucun doute de la puissance de ton analyse.
[^] # Re: [:Mouaifff]
Posté par GeneralZod . Évalué à 7.
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
[^] # Re: [:Mouaifff]
Posté par Sébastien Wilmet . Évalué à 2.
http://0pointer.de/blog/projects/pa-in-ubuntu.html
Faut espérer que la situation s'est améliorée pour la 10.04...
# Non au démarrage rapide ...
Posté par Etienne Bagnoud (site web personnel) . Évalué à 7.
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 Amand Tihon (site web personnel) . Évalué à 8.
[^] # Re: Non au démarrage rapide ...
Posté par Etienne Bagnoud (site web personnel) . Évalué à 10.
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 Mr Kapouik (site web personnel) . Évalué à -1.
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 claudex . Évalué à 5.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: C'est quoi le démarrage ?
Posté par Victor . Évalué à 2.
[^] # Re: C'est quoi le démarrage ?
Posté par Frank-N-Furter . Évalué à 5.
Depending on the time of day, the French go either way.
[^] # Re: C'est quoi le démarrage ?
Posté par William Briand . Évalué à 3.
[^] # Re: C'est quoi le démarrage ?
Posté par bubar🦥 (Mastodon) . Évalué à 2.
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 dyno partouzeur de drouate . Évalué à 2.
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 Dabowl_75 . Évalué à 0.
[^] # Re: Pourquoi ?
Posté par gnumdk (site web personnel) . Évalué à 2.
[^] # Re: Pourquoi ?
Posté par Misc (site web personnel) . Évalué à 3.
[^] # Re: Pourquoi ?
Posté par Dabowl_75 . Évalué à -3.
Tu dois pas te marrer tous les jours toi :)
[^] # Re: Pourquoi ?
Posté par M . Évalué à 3.
- 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 Julien Fontanet (site web personnel) . Évalué à 1.
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 Etienne Bagnoud (site web personnel) . Évalué à 9.
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 pyrollo (site web personnel) . Évalué à 4.
# Dans le même genre
Posté par Nerdiland de Fesseps . Évalué à 2.
# launchd?
Posté par octane . Évalué à 1.
[^] # Re: launchd?
Posté par GeneralZod . Évalué à 2.
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.