Journal Debian à l'heure du choix

Posté par . Licence CC by-sa
48
31
jan.
2014

Comme vous le savez peut-être, le projet Debian s'interroge actuellement sur ce que doit être son système d'init par défaut (sysvrc, openrc, upstart, systemd).

Après de longs mois d'étude, le comité technique semble sur le point de rendre son avis. Une proposition de vote convenant à la plupart des membres a été rédigée, et les votes à son sujet devraient avoir lieu d'ici la fin de la semaine prochaine.

Pour les non-anglophones, voici une traduction de la résolution:

Nous avons pu rédiger collaborativement une résolution via IRC. En voici le résultat.
DT systemd sera l'init par défaut dans jessie, il est permis de dépendre d'un init particulier
DL systemd sera l'init par défaut dans jessie, il est interdit de dépendre d'un init particulier

UT upstart sera l'init par défaut dans jessie, il est permis de dépendre d'un init particulier
UL upstart sera l'init par défaut dans jessie, il est interdit de dépendre d'un init particulier

OT openrc sera l'init par défaut dans jessie, il est permis de dépendre d'un init particulier
OL openrc sera l'init par défaut dans jessie, il est interdit de dépendre d'un init particulier

VT sysvrc sera l'init par défaut dans jessie, il est permis de dépendre d'un init particulier
VL sysvrc sera l'init par défaut dans jessie, il est interdit de dépendre d'un init particulier

GR le projet décidera par une résolution générale

FD la discussion doit se poursuivre

Chacune de ces propositions correspond à une ou plusieurs sections de la résolution ci-dessous (dont on peut trouver le texte dans le git du comité, sous 727708_initsystem/draft-resolution.txt)
Nous nous sommes mis d'accord pour appeler à voter lundi soir, à moins q'un membre du comité ne s'y oppose. Nous commencerons à voter plus tôt si tout le monde approuve cette formulation.
Ian, Bdale, Andy, Don et Russ ont tous approuvé cette formulation via IRC. Steve, Colin et Keith, faites nous savoir votre avis, nous pourrons ainsi peut-être commencer le vote plus tôt.
Merci,
Ian

== version D (systemd) ==

Le système d'init par défaut dans jessie sous linux sera systemd

== version U (upstart) ==

Le système d'init par défaut dans jessie sous linux sera upstart

== version O (openrc) ==

Le système d'init par défaut dans jessie sous linux sera openrc

== version V (sysvinit) ==

Le système d'init par défaut dans jessie sous linux sera sysvinit

== version GR (résolution générale) ==

Le comité technique décide que la question du système d'init par défaut sera résolue via une résolution générale

== annexe sur les dépendances version T (couplage fort) ==

Cette décision se limite à la sélection du système d'init par défaut, nous continuons à accueilir les contributions visant à supporter d'autres systèmes d'init.
Il est permis que des logiciels dépendent d'un init spécifique en pid 1.
Cependant, lorsque possible, les logiciels devraient supporter tous les systèmes d'init, les mainteneurs sont encouragés à accepter des patchs raisonnables pour permettre l'interopérabilité, même si celà résulte en une réduction de fonctionnalités sous le sytème d'init pour lequel le patch a été proposé.

== annexe sur les dépendances version L (couplage faible) ==

Cette décision se limite à la sélection du système d'init par défaut, nous continuons à accueilir les contributions visant à supporter d'autres systèmes d'init.
Il n'est pas permis que des logiciels dépendent d'un init spécifique en pid 1.
Les mainteneurs sont encouragés à accepter des patchs raisonnables pour permettre l'interopérabilité entre les sytèmes d'init.

== annexe pour toutes les versions sauf GR ==

Cette décision est automatiquement annulée par une résolution générale contraire rassemblant une majorité simple. Le cas échéant, la résolution générale remplace cette résolution.

  • # Pari

    Posté par . Évalué à 6.

    Qui prend les paris ?

    • [^] # Re: Pari

      Posté par . Évalué à 1.

      Pas moi
      :-D

    • [^] # Re: Pari

      Posté par (page perso) . Évalué à 9.

      Moi je vote et je dis qu'il bluffe !

    • [^] # Re: Pari

      Posté par . Évalué à 5.

      OL :)

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Pari

        Posté par . Évalué à 4.

        Vu comment c'est parti, ça va plutôt finir en FD tout çà!

        • [^] # Re: Pari

          Posté par . Évalué à 2.

          Tant que ce n'est pas une ?L ça me va :)

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Pari

            Posté par (page perso) . Évalué à 4.

            Pourquoi, j'aurais plutôt dit l'inverse.

            « 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: Pari

              Posté par . Évalué à 3.

              Tu as raison j'ai inversé les lignes…

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Pari

        Posté par . Évalué à 3.

        OL également ! (et je parle pas de foot)

        • [^] # Re: Pari

          Posté par . Évalué à 1.

          C'était ironique… C'est à mon avis improbable qu'ils choisissent cette option, elle est fonctionnellement faible et n'apporte pas grand chose face à l'existant. Ce serait beaucoup de bruit pour presque rien. Vu le débat il n'y a pas grand monde pour défendre OpenRC (c'est un peu le truc qui est re sortie pour avoir quelque chose à répondre aux fan de systemd/upstart).

          AMHA il est important de choisir une option qui ne soit pas ?L, mais de la part de Debian ça m'étonnerait. Pour le reste c'est pas très gênant. Ils vont choisir DT, UT ou GR et ce sera bien. Ça permettra au packagers de commencer le boulot pour Jessie.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Commentaire supprimé

            Posté par . Évalué à 3.

            Ce commentaire a été supprimé par l'équipe de modération.

            • [^] # Re: Pari

              Posté par . Évalué à 3.

              En l'occurrence si, j'ai pas relu la constitution Debian, mais je parle des membres du ctte, ceux qui vont voter.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Pari

      Posté par . Évalué à 4.

      Je parie sur DT, ça m'a l'air de correspondre aux positions de Russ Albery, Bdale Garbee, Keith Packard et (dans une moindre mesure) Don Armstrong.

      Vu que Bdale a un vote supplémentaire en cas d'égalité, ça peut faire pencher la balance.

      • [^] # Re: Pari

        Posté par . Évalué à 2. Dernière modification le 31/01/14 à 13:13.

        Vu que Bdale a un vote supplémentaire en cas d'égalité, ça peut faire pencher la balance.

        Bah non, puisque l'égalité a déjà été atteinte lors du précédent-précédent vote (4.5 vs 4 avec le vote de Bdale, le vote suivant a été écourté), et il semble qu'il ne veuille pas forcer une décision controversée.

        Ca finira en FD ou GR pour sûr.

    • [^] # Re: Pari

      Posté par . Évalué à -4.

      UT, vu que c'est le cttt qui vote et qu'ils sont employés canonical, et que j'espère pour eux qu'ils aiment les softs canonical, il me semble naturels qu'ils poussent ce sur quoi ils travaillent, donc ce sera upstart.

      J'ai déjà commencé à migrer ailleurs, gentoo/arch on verra bien ;)

    • [^] # Re: Pari

      Posté par . Évalué à 6.

      Je parie sur DL.

      Et je dis ce que je veux, on est vendredi!

  • # dépendance à un système d'init

    Posté par . Évalué à 1.

    Il y a eu pas mal de trolls autour du fait que GNOME serait à terme dépendant de systemd.

    Quelle est la conséquence de ce passage de l'annexe sur les dépendances  ?
    « Il n'est pas permis que des logiciels dépendent d'un init spécifique en pid 1. »

    • [^] # Re: dépendance à un système d'init

      Posté par . Évalué à 4.

      Ce sera considéré comme un bug et :

      Les mainteneurs sont encouragés à accepter des patchs raisonnables pour permettre l'interopérabilité entre les sytèmes d'init.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: dépendance à un système d'init

      Posté par . Évalué à 10.

      GNOME n'est pas dépendant à systemd. Il est dépendant d'une API dbus qui pour l'instant n'est fournie que par systemd, aux systèmes concurrents de l'implémenter.

      Au passage, si je me souviens bien il s'agit de features non essentielles comme le réglage de l'hostname. Ça n'empêche pas le bureau d'être utilisable.

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: dépendance à un système d'init

        Posté par . Évalué à 0.

        GNOME n'est pas dépendant à systemd. Il est dépendant d'une API dbus qui pour l'instant n'est fournie que par systemd, aux systèmes concurrents de l'implémenter.

        C'est un peu comme si tu disais que KDE n'est pas dépendant de Qt mais d'une API fournie uniquement par Qt…

        On sait tous que c'est Gnome et GDM qui sont directement en ligne de mire là dessus notamment à cause d'un potentiel (je sais pas si ça a était fait finalement) couplage fort entre systemd, logind et gdm. La crainte que Gnome se dirige vers une dépendance forte avec logind/systemd n'est pas sans raison.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: dépendance à un système d'init

          Posté par . Évalué à 10. Dernière modification le 31/01/14 à 14:10.

          Tu confonds API et "API DBUS".

          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

        • [^] # Re: dépendance à un système d'init

          Posté par (page perso) . Évalué à 10. Dernière modification le 31/01/14 à 14:55.

          Je te propose de regarder comment fait ubuntu pour fournir les API DBUS en question alors qu'ils utilisent upstart…

          Donc, c'est juste du gros troll cette partie… Les services fournis par systemd ne dépendent pas de systemd (le PID 1)

        • [^] # Re: dépendance à un système d'init

          Posté par (page perso) . Évalué à 2.

          La crainte que Gnome se dirige vers une dépendance forte avec logind/systemd n'est pas sans raison.

          On est Vendredi, la raison, je te l'a donne, elle est cadeau : "De toute façon, Gnome/Gtk+/SystemD/PulseAudio, c'est la tambouille de Red Hat".

          Comment ? Ubuntu fait la même chose avec son Upstart/LightDM/Unity/Mir ? Ouais mais pas toujours les mêmes aussi.

      • [^] # Re: dépendance à un système d'init

        Posté par . Évalué à 5.

        Au passage, si je me souviens bien il s'agit de features non essentielles comme le réglage de l'hostname. Ça n'empêche pas le bureau d'être utilisable.

        Pas uniquement : la gestion d'énergie dans gnome est aussi dépendante d'une API dbus dépendante elle même de systemd, ce qui peut être considéré comme une feature essentielle
        Après, il y a toujours moyen de contourner le problème en bricolant un peu le JS de gnome-shell

        • [^] # Re: dépendance à un système d'init

          Posté par (page perso) . Évalué à 1.

          Non, même les infos d'énergie ? Bordel, mais ça marchait très bien sans systemd avant, ça…

          • [^] # Re: dépendance à un système d'init

            Posté par (page perso) . Évalué à 10. Dernière modification le 31/01/14 à 16:57.

            Répétons, GNOME n'a pas besoin de systemd mais d'une implémentation de l'API de DBus que notamment systemd propose mais que tout autre programme pourrait fournir.
            C'est tout l'intérêt d'une API que d'être utilisé par d'autre programme, rappelons qu'en soit POSIX est une API et personne ne semble être offusqué que GNU ou *BSD fournissent ces implémentations sans concurrent sur un système donné.

            Oui il peut y avoir des intérêt pour la gestion d'énergie qui nécessite pas mal d'informations pour être optimums (réglage sur le matériels ou certains logiciels) en réponse à des évènements que seul certains programmes ont l'information directement.

            EDIT : je pense qu'il faut arrêter de critiquer tout uniquement parce qu'il y a le mot systemd dans la phrase. Oui avant on savait faire des trucs avant qu'aujourd'hui on ne fait plus forcément, mais c'est pareil pour tout. Il y a une époque sous Linux il fallait monter sa clé USB à la main, c'était cool cette époque. Aujourd’hui on a besoin de HAL ou de udev dans son système… C'est à peu près pareil pour tout, pour plus de conforts et d'efficacité certains composants sont apparus avec son lot de dépendance par la suite.

            • [^] # Re: dépendance à un système d'init

              Posté par (page perso) . Évalué à -2. Dernière modification le 31/01/14 à 17:12.

              Répétons, GNOME n'a pas besoin de systemd mais d'une implémentation de l'API de DBus que notamment systemd propose mais que tout autre programme pourrait fournir.

              Et dépendait autrefois d'une autre API, celle d'UPower, qui ne dépendait pas du tout de systemd et marchait très bien. Donc on a bien ici une modification volontaire d'un truc qui marchait déjà, qui introduit une dépendance à un truc nouveau qui n'est fourni que par systemd.

              • [^] # Re: dépendance à un système d'init

                Posté par (page perso) . Évalué à 10.

                Et tu ne te demandes pas pourquoi ils ont changé d'API ?
                Peut être qu'il lui manquait des possibilités, pas assez performant ou non maintenu. Bref, ils ont changé d'API et alors ? On a bien remplacé HAL qui était aussi une couche d'abstraction mais abandonnée pour diverses raisons aujourd'hui au profit d'autres solutions. Ce n'est pas un phénomène nouveau et c'est même sain.

                Si un autre logiciel fournit cet API, GNOME ne dépendra plus de systemd mais il faut le faire (et personne ne semble particulièrement motivé pour faire cette tâche). C'est comme ça pour tout API.

                Avant on avait une distribution GNU/Linux presque nue, aujourd'hui il y a XFree86 qui est devenu X.org et qui deviendra Wayland, udev, dbus, HAL, les ConsoleKit/PolicyKit, on est passé de OSS à ALSA puis PulseAudio, la couche graphique s'est bien complexité avec des ajouts comme KMS, drm, GLX, OpenGL avec un mic-mac d'implémentations comme Mesa ou Gallium 3D.
                Bref des couches comme ça qui ont bougé ou sont en mouvement il y a des tas. Je trouve très malhonnête de ne se focaliser dans ce cadre la critique qu'envers les changements de système d'init avec systemd en tête.

                Les dépendances d'une distribution se complexifient avec le temps et c'est normal, systemd est loin d'être le seul cas existant et honnêtement ce n'est pas la partie à mon goût la plus problématique.

                • [^] # Re: dépendance à un système d'init

                  Posté par (page perso) . Évalué à 0.

                  on est passé de OSS à ALSA puis PulseAudio, la couche graphique s'est bien complexité avec des ajouts comme KMS, drm, GLX, OpenGL avec un mic-mac d'implémentations comme Mesa ou Gallium 3D.

                  Clair ! J'ai eu plus de problème à faire tourner Gnome sur des carte graphiques dont le pilote n’implémentait pas bien certaines dépendances fonctionnelles qu’à faire tourner Gnome sur du pulseaudio.

                  Typiquelent avec de vieilles Intel. Dernièrement j’ai eu un bug très bizarre, si je configurai XDM au boot, l'affichage fonctionnait bien et je pouvais lancer un environnament à l'ancienne genre metacity + nautilus + gnome-panel.

                  Si je configurai GDM au boot, l'affichage était noir. Si je lançais GDM à la main (service gdm start ou équivalent), j'avais l'affichage mais je ne pouvais pas ouvrir ma session Gnome, je pouvais ouvrir une session à l'ancienne genre LXDE, mais pas Gnome : si je me connectais avec la session Gnome sélectionnée, GDM faisait disparaitre l’écran de connexion pour switcher vers la session, mais n’aboutissait jamais, au passage l'affichage était foiré, je ne voyais plus que le fond d’écran, mais si je cliquais dans des endroits stratégiques, je voyais se dérouler des menus (comme le son en haut à droite) et c’était pas le menu de Gnome, mais de GDM !

                  Et si je lançais Gnome à la main avec un X11 sans GDM, j'avais un bug similaire que décrit après connexion dans le GDM : Gnome Shell se lançait bien, mais l'affichage était foireux, certains éléments n’apparaissant qu’au clic.

                  En mode "fallback", la session marchait très bien SAUF que je ne pouvais pas me connecter depuis GDM vers Gnome, fallaback ou pas.

                  C’était une Ubuntu 13.10, je l’ai remplacé par une Debian Wheezy avec un pilote un peu plus ancien et un Gnome un peu plus ancien, et tout marchait très bien…

                  Dans aucun des cas je n’avais systemd, mais y a donc parfois de gros problème où un bug dans un pilote graphique va entrainer quelque part un lock dans un service quelconque qui va bloquer… l'identification ! Incroyable complexité.

                  Dbus c’est cool, mais on devient très dépendant d’une foultitude de services et parfois ça foire. Aujourd’hui Dbus est aussi critique que le noyau, si on a un bug dbus plus rien ne fonctionne, ni le son, ni le réseau, ni l’identification, et si une api dbus se vautre à cause d’un problème sous-jacent ça peut être tout aussi gênant.

                  Un pulseaudio qui ne marche pas pour une raison X ou Y est très difficile à contourner. Si PulseAudio ne marche, pas vaut mieux être admin pour trouver une solution de secours.

                  ce commentaire est sous licence cc by 4 et précédentes

                  • [^] # Re: dépendance à un système d'init

                    Posté par . Évalué à 4.

                    Dbus c’est cool, mais on devient très dépendant d’une foultitude de services et parfois ça foire. Aujourd’hui Dbus est aussi critique que le noyau, si on a un bug dbus plus rien ne fonctionne, ni le son, ni le réseau, ni l’identification, et si une api dbus se vautre à cause d’un problème sous-jacent ça peut être tout aussi gênant.

                    DBus est peut-être critique pour toi, mais pas pour tout le monde.

                    Il offre certainement un grand confort, notament de permettre de configurer son réseau via une zolie IHM sans devoir devenir root, mais, ça ne signifie pas que ce ne soit pas faisable.
                    Et, même si je conçois très bien que mon cas personnel n'est pas représentatif d'une quelconque majorité, je peux te dire que jusqu'a présent, mes machines sur lesquelles dbus est installé, mais pas démarré ( dépendance dure de quelques logiciels et flemme de faire un paquet bidon… ) il ne me manque aucune fonctionnalité.

                    Pour le réseau, par exemple, j'édite tout bêtement /etc/network/interfaces à la main ( et pour les desktop, ça veut dire le faire 1 fois par installation, puisqu'au final la plupart des gens à un dhcp sur le LAN… ) . Pour le gestionnaire de session… j'avoue, je n'en utilise pas, je me log avec login, et un script lance startx si je suis en tty1.
                    Largement suffisant pour mes besoins, en somme.

                    Pulseaudio? Je crois que j'ai 1 ou 2 paquets avec pulse dans le nom d'installés ( mpd, de mémoire ), mais ce qui est certain, c'est que je n'ai aucun daemon PA qui tourne.

                    Donc, non, dbus est loin d'être aussi critique que le kernel. Pas même aussi incontournable que Xorg. D'ailleurs, à l'heure actuelle, il n'y a bien que linux et Xorg, que je considère comme des outils vitaux. Tous les autres ont des alternatives plus que viables. Et Xorg sera remplacé par wayland, un de ces 4. A voir pour linux également, il faudrait que je teste debian kfreebsd.

                    • [^] # Re: dépendance à un système d'init

                      Posté par (page perso) . Évalué à 6.

                      mes machines sur lesquelles dbus est installé, mais pas démarré ( dépendance dure de quelques logiciels et flemme de faire un paquet bidon… ) il ne me manque aucune fonctionnalité.

                      Je suis bien d’accord, comme le fait qu’au boulot, aucune machine n’utilise Network-Manager ni PulseAudio, et ça fonctionne très bien.

                      Le problème c’est que pour l’expérience citée, ce n’était pas critique pour moi mais pour un autre. La machine n’était pas la mienne, et je ne pouvais pas la laisser avec la solution startx pour le lancement du bureau, ce même bureau à base de .xinitrc, de metacity et de gnome-panel lancé à la main, tout comme je n’aurai pas pu laisser une telle machine avec une configuration façon le très efficace /etc/network/interface àla Debian.

                      On peut faire sans dbus, sans gdm, sans gnome, sans network-manager, sans pulseaudio… Mais quand tu installes un bureau grand public à un tiers, tu auras du mal à lui laisser autre chose dans les mains, en lui mettant dans les mains non seulement la machine, mais aussi le système d’exploitation et son autonomie à l’administrer à la cliquouille.

                      Bref, pour avoir un gdm+gnome+pulseaudio+network-manager parce que c’était le besoin, un bug du pilote intel d’Ubuntu foirait tout : si le néophyte ne peut pas passer l’étape d’ouverture de session de gdm, il ne peut rien faire. Les « pour toi pas pour tout le monde » n’ont aucun sens ici, et les « je t’apprend comment vivre avec » non plus : ce n’est pas pour moi que c’est critique, et ce n’est pas moi qui doit vivre avec.

                      Donc oui, on peut faire énormément de choses sans dbus, tout comme je m’en passe très souvent et que je me passe également des network-manager et de pulseaudio. Mais c’est un fait : dbus est aussi critique que le noyau dans une distribution bureautique grand public à la Ubuntu. Sans dbus, t’es même pas sûr que le gestionnaire de connexion se lance.

                      Il y a là des dépendances qui ne sont pas techniques. Par exemple si le serveur de connexion ne se lance pas parce que dbus ne se lance pas, X11 ne sera pas lancé même si X11 n’a pas besoin de dbus et qu’il peut être lancé manuellement. Dans mon exemple du post précédent, le fait que gdm ne lançait pas gnome après identification n’était peut-être même pas du à une dépendance technique, qui sait ?



                      NB : tout comme il est sain d’accorder le bénéfice du doute à celui que l’on ne comprend pas afin de ne pas partir du principe que celui que l’on ne comprend pas est bête mais qu’on ne l’a tout simplement pas compris, il est sain de ne pas partir du principe que celui qui relate un problème est celui qui doit vivre avec ce problème, ou bien les réponses apportées seront inadaptées.

                      Ici je relatais un problème qui affecterai quelqu’un d’autre que moi à la livraison, je ne pouvais donc pas installer un contournement. C’est pas la peine de m’enseigner ce que je fais tous les jour quand il m’est possible de le faire. Ça n’apporte aucune solution.

                      Celui qui réalise n’est pas forcément celui qui va utiliser. En oubliant ce point crucial, on apporte des solutions qui n’en sont pas.

                      ce commentaire est sous licence cc by 4 et précédentes

                    • [^] # Re: dépendance à un système d'init

                      Posté par . Évalué à 8.

                      Je suis sûr que sur tes machines, ta pile réseau utilise le protocole ARP. Pourtant, c'est complètement inutile, en plus, ça fait des requêtes en plus sur le réseau, du code qui tourne sur ta machine alors qu'un bête fichier /etc/networl/arp dans lequel tu mettrais toutes les correspondances IP - adresse MAC ferait parfaitement l'affaire.

                      Et puis, tu n'utilises pas vi mais ed parce que vi est complètement bloated.

                      Pour moi, un des intérêts de l'informatique est d'automatiser certaines tâches. L'informatique avance parce que les gens sont paresseux.

                      En ce qui me concerne, j'ai fondamentalement gardé les même besoins qu'en 1996. Je fais du mail, du LaTeX. J'écoute de la musique. Et je surf sur le web. Alors, c'est vrai que le web à changé. C'est donc normal que le navigateur aussi. Mais je pourrais en grande partie continuer à utiliser ma configuration de l'époque. Sauf que je ne veux pas. Certes ma configuration est beaucoup plus lourde. Mais ma machine est beaucoup plus puissante.

              • [^] # Re: dépendance à un système d'init

                Posté par (page perso) . Évalué à 8. Dernière modification le 31/01/14 à 17:36.

                celle d'UPower,

                Rien ne t'empèche de maintenir le bousin. Les mainteneur actuels n'étnt pas tes esclaves, ils ont la liberté de choisir le logiciel qui répond au mieux à leurs besoins.

                qui introduit une dépendance à un truc nouveau

                A chaque changement de logiciel pour faire une fonction X, il y a des râleurs pour se plaindre que ça marchait avant, qui ne se posent jamais la question de pourquoi les developpeurs et mainteneurs veulent changer…

            • [^] # Re: dépendance à un système d'init

              Posté par . Évalué à 8. Dernière modification le 01/02/14 à 00:49.

              Répétons, GNOME n'a pas besoin de systemd mais d'une implémentation de l'API de DBus que notamment systemd propose mais que tout autre programme pourrait fournir.

              C'est un peu fumeux ce que tu dis. Il ne s'agit pas de l'« API DBus », mais d'une API faite sur dbus et qui est proposée par systemd. Si tu veux parler en terme de couche il est bon d'être un peu plus précis et oui c'est une API c'est un ensemble de fonctions, donc ça peut se réimplémenter (comme Qt même si ça choque certains de le dire).

              Personnellement tu te fourvoie, je n'ai rien contre systemd (je l'utilise sur ma Debian stable), j'ai l'impression qu'il écrase n'importe quel autre init linux, je vois juste d'un mauvais œil cette API. Oui elle est réimplémentable, oui elle l'a déjà était pour ubuntu. Mais logind a ou va en présenter une nouvelle et celle de systemd peut très bien changer ou s’agrandir (c'est un logiciel en développement actif). Ça n'est pas un standard, ça tente de se présenter comme un standard de fait, mais aujourd'hui ça n'est pas le cas.

              Mais c'est pas une bonne chose de changer aussi régulièrement les API linux, c'est peut être l'un des gros problèmes de linux sur desktop. C'est les API du bureau linux. Le problème n'est pas fonctionnel. Avoir une vitesse de boot ou une gestion des sessions utilisateurs dans l'absolu c'est joli, mais ça apporte plus de bug d'intégration que de fonctionnalité pour l'utilisateur final.

              Bien sûr Lennart comme tout autre vis dans le monde du logiciel libre, un monde où chacun fait bien ce qu'il veut et qui est régis par une méritocratie celui qui fait a le dernier mot, mais ça n'empêche pas de donner son avis.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: dépendance à un système d'init

                Posté par (page perso) . Évalué à 7.

                Personnellement je ne te visais pas trop dans mon propos, je répondais plus à Tanguy qui faisait dans la critique gratuite de systemd alors que le problème est plus profond que ça et ne devrait pas s'attarder uniquement sur systemd. Enfin selon la vision des choses, car je pense qu'il y a deux approches que je vais expliciter plus bas.

                Note que je ne suis pas particulièrement en désaccord avec toi, je comprends en tout cas ton point de vue.

                Mais c'est pas une bonne chose de changer aussi régulièrement les API linux, c'est peut être l'un des gros problèmes de linux sur desktop. C'est les API du bureau linux. Le problème n'est pas fonctionnel. Avoir une vitesse de boot ou une gestion des sessions utilisateurs dans l'absolu c'est joli, mais ça apporte plus de bug d'intégration que de fonctionnalité pour l'utilisateur final.

                Je pense que c'est en soit quelque chose à double tranchant en effet :

                • La compatibilité ascendante et une API stable aident à concevoir un système stable où les composants sont bien intégrés, etc.
                • Cependant, si cela n'est jamais remis en cause (et certains le montrent clairement au sujet de SysV qui n'a pas beaucoup bougé en 30 ans), ça ne bouge plus du tout ou pas assez vite malgré l'évolution du contexte, des moyens et des technologies disponibles.

                C'est un peu comme vouloir la stabilité et l'intégration d'une Debian et les nouveautés de Fedora (par exemple) en même temps, ce sont deux visions à mon sens correctes mais qui s'opposent et qui sont difficiles à concilier. Comme on dit, on ne peut pas tout avoir.

                Beaucoup ici aiment les systèmes libres car tout peut être remis en question, que ça évolue suffisamment vite pour être en phase avec l'évolution technique. Ce sont des qualités souvent mis en opposition avec Windows par exemple mais qui nécessite de changer d'API quand on se rend compte que celles existantes ne parviennent pas à convenir à la situation d'aujourd'hui.

                Et il sera impossible d'avoir une API stable tant qu'il n'y aura pas de gouvernance suprême. Si le noyau est géré par une poignée de gens qui travaillent main dans la main (ou en tout cas, avec un seul arbre de développement) les couches au dessus ont autant de branches que de projet ce qui rend la coordination difficile. Et certaines tentatives de gouvernances ont été particulièrement rejetées comme la LSB ce qui montre la difficulté de se mettre d'accord pour essayer d'harmoniser l'ensemble.
                Si les projets majeurs sont prêts à s'unir sous un même pavillon, sans pour autant vendre leurs âmes au diable, il y aurait moyen en effet d'avoir une conception plus stable des cocuhes du systèmes. Mais étrangement, je n'y crois pas trop pour le moment à la possibilité d'une telle entreprise.

              • [^] # Re: dépendance à un système d'init

                Posté par (page perso) . Évalué à 2.

                Avoir une vitesse de boot ou une gestion des sessions utilisateurs dans l'absolu c'est joli, mais ça apporte plus de bug d'intégration que de fonctionnalité pour l'utilisateur final.

                Tu préfères un OS sans bug pas du tout utilisé à un OS avec un peu de bugs un peu utilisé, perso je préfère le contraire.
                Parce qu'ayant gouté à un OS (en fait deux : Windows et Mac OS X) qui bootent très rapidement, en tant qu'utilisateur desktop il est hors de question d'imaginer utiliser un OS qui prend son temp à booter, on n'est plus au 20è siècle.

                Les bugs sont un problème, mais ça ne cautionne pas de geler un OS, ce sont les bugs qu'il faut chasser.

                Ça n'est pas un standard, ça tente de se présenter comme un standard de fait, mais aujourd'hui ça n'est pas le cas.

                De la mème manière, si il faut attendre x (combien pour que ça te va? OK, le W3C dit 2 par exemple) implémentations, déjà que Linux est à la ramasse sur le desktop (Windows et Mac OS X bootent rapidement depuis quelques années maintenant), ça va être encore pire…

                mais ça n'empêche pas de donner son avis.

                Et les autres non plus ;-).

                • [^] # Re: dépendance à un système d'init

                  Posté par . Évalué à 5.

                  Parce qu'ayant gouté à un OS (en fait deux : Windows et Mac OS X) qui bootent très rapidement, en tant qu'utilisateur desktop il est hors de question d'imaginer utiliser un OS qui prend son temp à booter, on n'est plus au 20è siècle.

                  Tu ne peux pas nier qu'il y a un vrai problème d'intégration des nouveautés. L'évolution pourrait très bien prendre en compte l'existant. C'est sur ce genre de petite chose que MacOS fait son beurre.

                  Les bugs sont un problème, mais ça ne cautionne pas de geler un OS, ce sont les bugs qu'il faut chasser.

                  Pff sérieusement tu crois que personne le vois venir ton homme de paille. Il n'y a pas d'autres choix possible ?

                  De la mème manière, si il faut attendre x (combien pour que ça te va? OK, le W3C dit 2 par exemple) implémentations, déjà que Linux est à la ramasse sur le desktop (Windows et Mac OS X bootent rapidement depuis quelques années maintenant), ça va être encore pire…

                  L'intérêt de systemd n'est pas la vitesse de boot. Si on voulais juste faire quelque chose de rapide, on peut le faire de pleins de façons. Le problème est plus dans les dépendances entre le bureau et le système d'init. L'intérêt n'est pas notable (en tout cas pour moi).

                  mais ça n'empêche pas de donner son avis.

                  Et les autres non plus ;-).

                  Si je ne l'avais pas dis tu aurais était le premier à me répondre que je n'ai qu'à implémenter l'API en question et que si ce n'est pas fait c'est que tout le monde s'en fout (ça fait partie des tes arguments récurrent que tu sort à loisir).

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                  • [^] # Re: dépendance à un système d'init

                    Posté par . Évalué à 3.

                    Tu ne peux pas nier qu'il y a un vrai problème d'intégration des nouveautés. L'évolution pourrait très bien prendre en compte l'existant. C'est sur ce genre de petite chose que MacOS fait son beurre.

                    C'est le cas pour systemd, qui prend en charge les scripts d'init.

                    Quant à GNOME 3, quelques parties peuvent avoir besoin de logind ou d'un service équivalent (c'est pour ça que les patchs de Canonical pour que ça fonctionne sur Ubuntu ont été acceptés).

                    logind, lui, a besoin de systemd.

                    "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                  • [^] # Re: dépendance à un système d'init

                    Posté par . Évalué à 0. Dernière modification le 01/02/14 à 11:56.

                    L'intérêt de systemd n'est pas la vitesse de boot.

                    Tout à fait.

                    Si on voulais juste faire quelque chose de rapide, on peut le faire de pleins de façons

                    Non, pas vraiment. Le plus gros problème de la vitesse de boot sur SysV, c'est que SysV attend que chaque service ait fini de démarrer avant de démarrer un autre. Utiliser ureadahead, un SSD, ou autre astuce n'y changera pas grand chose du point de vue du temps de boot.

                    Le boot de systemd est parallélisable parce que les dépendances entre les services sont bien décrites, et que l'usage de udev et dbus font qu'elles sont plus faciles à gérer :

                    http://0pointer.de/blog/projects/the-biggest-myths.html

                    Yes, systemd is fast (A pretty complete userspace boot-up in ~900ms, anyone?), but that's primarily just a side-effect of doing things right. In fact, we never really sat down and optimized the last tiny bit of performance out of systemd. Instead, we actually frequently knowingly picked the slightly slower code paths in order to keep the code more readable. This doesn't mean being fast was irrelevant for us, but reducing systemd to its speed is certainly quite a misconception, since that is certainly not anywhere near the top of our list of goals.

                    OpenRC est rapide pour la même raison : il démarre les services de manière parallèle.

                    "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                    • [^] # Re: dépendance à un système d'init

                      Posté par (page perso) . Évalué à 5.

                      SysV attend que chaque service ait fini de démarrer avant de démarrer un autre

                      Non.

                      OpenRC est rapide pour la même raison : il démarre les services de manière parallèle.

                      L’implémentation du boot SysV de Debian aussi.

                      • [^] # Re: dépendance à un système d'init

                        Posté par . Évalué à 4. Dernière modification le 01/02/14 à 16:13.

                        Non.

                        Ah bon, j'ai sûrement rêvé quand SysV se bloquait lamentablement une fois sur deux sur un truc trivial comme le réseau. Alors que j'aurais bien voulu qu'il me démarre le display manager pendant ce temps. ;-)

                        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                        • [^] # Re: dépendance à un système d'init

                          Posté par . Évalué à 1.

                          […] SysV se bloquait lamentablement […] sur un truc trivial comme le réseau. Alors que j'aurais bien voulu qu'il me démarre le display manager pendant ce temps. ;-)

                          Ça dépend probablement des distributions, et de leurs versions. Lorsqu'Archlinux utilisait encore SysVinit, on pouvait démarrer des services en parallèle.

                          • [^] # Re: dépendance à un système d'init

                            Posté par . Évalué à 1.

                            Oui, et de plus, le réseau est considéré comme une dépendance pour beaucoup de services, donc une fois que le réseau a démarré, les services se lancent en parallèle.
                            Sur la plupart des distribs, le display manager se lance à la fin par défaut. C'est pas optimal, mais au moins tu sais que quand tu es loggué, tu n'as pas à attendre le démarrage d'un service en arrière plan, quelque soit l'action que tu veux faire.

                        • [^] # Re: dépendance à un système d'init

                          Posté par . Évalué à -2.

                          Ah bon, j'ai sûrement rêvé quand SysV se bloquait lamentablement une fois sur deux sur un truc trivial comme le réseau. Alors que j'aurais bien voulu qu'il me démarre le display manager pendant ce temps. ;-)

                          Génial, comme ça Lennux aura achevé de reproduire Windows. S'il y a bien un truc insupportable qui nous a pourri la vie des années durant dans Windows, c'est ces $@*#% de dizaines de secondes (ou de minutes) pendant lesquelles le système et l'interface graphique semblent avoir démarré alors qu'en fait les services continuent à être démarrés en arrière plan et toute action pendant ce laps de temps a un résultat indéfini (le seul truc sûr c'est de faire mouliner la machine à donf et de simuler des freezes).

                          • [^] # Re: dépendance à un système d'init

                            Posté par (page perso) . Évalué à -10.

                            Je ne sais pas de quel Windows tu parles, mais le mien out of the box est utilisable en moins de 10 secondes, alors que le Linux n'a pas fini de démarrer.
                            Faudrait arrêter un jour le FUD, et se demander pourquoi Linux est absent du Desktop (et non, ce n'est pas à cause d'une quelconque position domainante qui est une bonne excuse pour ne pas regarder le problème en face : il ne répond pas au besoin).

                            • [^] # Re: dépendance à un système d'init

                              Posté par . Évalué à 2. Dernière modification le 01/02/14 à 17:38.

                              (et non, ce n'est pas à cause d'une quelconque position domainante qui est une bonne excuse pour ne pas regarder le problème en face : il ne répond pas au besoin).

                              SI. C'est bien grâce à la livraison et préinstallation d'un système Windows (en fait ça a même débuté avec MS-DOS), que ses APIs se sont imposées aux développeurs tiers.

                              Et aujourd'hui on a une infinité d'applications qui ne fonctionne qu'avec Windows. Des milliers de gens qui n'ont connu que Windows sur le bureau. Ça continue depuis plus de 30 ans. Le nombre d'ordinateurs que l'on peut acheter avec Linux ou sans OS est ridicule. Windows est trop bien implanté (sur le desktop) pour que GNU/Linux le remplace un jour.

                              Ce ne sont pas les utilisateurs qui sont à convaincre, mais les constructeurs.

                              "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                            • [^] # Re: dépendance à un système d'init

                              Posté par (page perso) . Évalué à 10.

                              Ouais bah je ne sais pas de quel Windows tu parles non plus. Mon Seven est inutilisable pendant 1 à 2 minutes après l'apparition du bureau, et non j'ai pas installé de toolbar.

                              • [^] # Re: dépendance à un système d'init

                                Posté par (page perso) . Évalué à 6. Dernière modification le 02/02/14 à 12:12.

                                Inversement, je confirme que Windows 8 est démarré et «utilisable» en moins de 10 secondes.
                                Mais oui les précédentes versions sont des veaux et mettent bien plus longtemps à booter que mes Debian :/

                                À mon avis l'hardware joue beaucoup là dedans, tout comme le remplacement du BIOS par l'UEFI.

                                alf.life

                              • [^] # Re: dépendance à un système d'init

                                Posté par (page perso) . Évalué à 3.

                                Il est temps d'investir dans un bon SSD. Windows7 démarre en 20 secondes et Windows 8 en quelques secondes.

                                • [^] # Re: dépendance à un système d'init

                                  Posté par (page perso) . Évalué à 2.

                                  Il est temps de configurer la mise en veille ou l'hibernation, parce que c'est quand même plus pratique que de redémarrer son ordinateur tous les jours…

                                  « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

                                  • [^] # Re: dépendance à un système d'init

                                    Posté par (page perso) . Évalué à 2.

                                    Oui mais là on parle du démarrage. En hibernation, windows 8 est aussi très bon. Je n'ai aucune idée de comment il fait mais j'ai 16go de ram et la reprise est instantanée même après 3 mois sans électricité.

                                    • [^] # Re: dépendance à un système d'init

                                      Posté par (page perso) . Évalué à 3.

                                      De mémoire il y a plusieurs astuces.
                                      Windows 8 ne semble démarrer que le strict minimum avant de présenter l'écran de connexion (plusieurs fois j'ai vu l'interface Ethernet classique ou Wifi ne s'activer que quelques secondes après l'affichage de cet écran). Ils semblent mieux paralléliser les services au lancement au lieu d'un truc plus séquentiel et profite ben mieux de la technologie SSD (quand c'est disponible) que ses prédécesseurs.

                                      En soit l'idée n'est pas nouvelle, ni débile. Le temps que l'utilisateur entre son mot de passe le système peut légitimement lancer des tâches en arrière plan plutôt que de ne rien faire si cela permet à l'utilisateur que le système paraît plus réactif. Alors que GDM ici n'est lancé qu'une fois tous les services du système lancés même quand il n'en a pas forcément besoin le temps de se connecter.

                                      • [^] # Re: dépendance à un système d'init

                                        Posté par (page perso) . Évalué à 4.

                                        plusieurs fois j'ai vu l'interface Ethernet classique ou Wifi ne s'activer que quelques secondes après l'affichage de cet écran

                                        Je confirme, mon écran de connexion est toujours disponible avant la connexion de Wifi (qui est lente chez moi), et… Ca ne me dérange pas du tout! (je n'ai pas besoin de Wifi pour entrer mon mot de passe)

                                        Ils semblent mieux paralléliser les services au lancement au lieu d'un truc plus séquentiel et profite ben mieux de la technologie SSD (quand c'est disponible) que ses prédécesseurs.

                                        En gros, ça milite pour systemd qui remplace tous les vieux autres système d'init :)

                                        Alors que GDM ici n'est lancé qu'une fois tous les services du système lancés même quand il n'en a pas forcément besoin le temps de se connecter.

                                        En fait, le pire je crois est que certains trouvent que cette façon de faire est "horrible" sans qu'ils puissent vraiment expliquer pourquoi ça ne va pas de ne pas avoir le Wifi pendant qu'ils entrent leur mot de passe.

                                        Bref, plus on parle du système d'init de Linux, et plus on se rend compte qu'il a quelques années de retard… Et ça le fait pas trop pour un produit qu'on pusse sur le desktop (et je comrpedn encore mieux pourquoi tout le monde ou presque se jette sur systemd qui semble simplifier, optimiser tout ça).

                                        • [^] # Re: dépendance à un système d'init

                                          Posté par (page perso) . Évalué à 3.

                                          En fait, le pire je crois est que certains trouvent que cette façon de faire est "horrible" sans qu'ils puissent vraiment expliquer pourquoi ça ne va pas de ne pas avoir le Wifi pendant qu'ils entrent leur mot de passe.

                                          Le problème est que Microsoft est allé trop loin dans l'affaire dans le passé.
                                          Sous XP en tout cas, l'interface du bureau était affichée mais inutilisable pendant des dizaines de secondes ce qui est plutôt gonflant. Quitte à ne pas être utilisable, je préfère que l'affichage soit différent.

                                          Le coup de la fenêtre de connexion est une astuce qui est bien mieux pensée et intéressante pour l'utilisateur.

                                        • [^] # Re: dépendance à un système d'init

                                          Posté par (page perso) . Évalué à 2. Dernière modification le 04/02/14 à 21:06.

                                          Bref, plus on parle du système d'init de Linux, et plus on se rend compte qu'il a quelques années de retard…

                                          Parler de retard laisse sous-entendre qu'il y a un chemin tout tracé à suivre dans le logiciel vers un certain objectif unique obscur, alors que c'est pas du tout le cas. Perso, j'aime voir d'un coup d'œil que tous les services se lancent correctement, et c'est pas comme si ça mettait un temps fou : il y a plus de dix ans oui, mais aujourd'hui non, alors, à quoi bon de tout vouloir faire à la fois ?

                                          Ah, petite remarque : parler du système d'init sous Linux dans un journal qui parle des différents systèmes d'init, c'est rigolo.

                                          • [^] # Re: dépendance à un système d'init

                                            Posté par (page perso) . Évalué à 1.

                                            et c'est pas comme si ça mettait un temps fou : il y a plus de dix ans oui, mais aujourd'hui non,

                                            D'autres considèrent que c'est encore trop long, ne t'en déplaise…

                                            Perso, j'aime voir d'un coup d'œil que tous les services se lancent correctement

                                            Ca tombe bien, on s'interesse aux gens en général, qui s'en foutent complet et veulent pouvoir taper leur pass pendant que ça charge en attendant, par exemple. Pourquoi ton besoin serait supérieur aux autres? Libre à toi d'avoir ta distro aux petits oignons, mais libres aussi aux autres de répondre au besoin général.

                                            Ah, petite remarque : parler du système d'init sous Linux dans un journal qui parle des différents systèmes d'init, c'est rigolo.

                                            Ah, petite remarque : parler du système d'init sous Linux ça veut dire parler de la fonction "initialisation" de l'OS, pas dire qu'il y a un seul logiciel unique capable de le faire.
                                            systemd et plein d'autres sont le module qui s'occupent du système d'init sous Linux. Le système d'init de Linux peut être géré par différents logiciels etc…

                                          • [^] # Re: dépendance à un système d'init

                                            Posté par (page perso) . Évalué à 3.

                                            Perso, j'aime voir d'un coup d'œil que tous les services se lancent correctement

                                            En quoi est-ce incompatible avec les démarrages rapides et parallèles ?
                                            Et le fait que ce soit stocké dans des logs te permet de vérifier si tu en as vraiment besoin.

                                            Des palliatifs existent, cela ne signifie pas que les idées de Microsoft ou de systemd sont ridicules ou incompatibles avec ton besoin.

                                            et c'est pas comme si ça mettait un temps fou : il y a plus de dix ans oui, mais aujourd'hui non, alors, à quoi bon de tout vouloir faire à la fois ?

                                            Bah quand j'allume mon ordinateur, c'est préférable qu'il soit utilisable le plus tôt possible. Je sais que certains aiment en profiter pour lancer le café en même temps et le siroter mais ce n'est pas un cas d'utilisation très pertinent.
                                            Surtout, je ne vois pas pourquoi on devrait faire moins vite si aller plus vite ne dégrade pas la qualité du service (et ici ce n'est pas le cas).

                                            • [^] # Re: dépendance à un système d'init

                                              Posté par (page perso) . Évalué à 2. Dernière modification le 05/02/14 à 19:33.

                                              En quoi est-ce incompatible avec les démarrages rapides et parallèles ?

                                              Ce que je veux dire c'est que si ça démarre en une seconde j'ai le temps de rien voir, et pire encore si j'ai un écran de connexion qui apparaît avant que tout soit démarré.

                                              Et le fait que ce soit stocké dans des logs te permet de vérifier si tu en as vraiment besoin.

                                              Je suis d'accord, mais j'aime bien avoir un rendu visuel sur le moment, et s'il y a un souci je vais ensuite voir les logs pour les détails, car je vais pas systématiquement voir les logs après chaque démarrage non plus :)

                                              Mais bon, mes préférences sont sans doute particulières, je voulais juste dire que démarrer instantanément et sans infos ne fait pas l'unanimité, et non sous-entendre l'opposé et que tout le monde doit avoir mes habitudes comme semble l'avoir compris Zenitram, désolé si je me suis mal exprimé. Et bon, je suis même pas si attaché que ça à mes habitudes en matière de boot, c'est pas comme si j'éteignais mon ordi juste après, content de l'expérience ;) Ni d'ailleurs que mon choix d'os ou distribution se fonde sur ce type de considérations.

                                              Edit : Ah, et d'ailleurs, je pense à une chose : le seul moment où j'ai l'impression que le démarrage est trop long, c'est quand fsck fait son check des disques, et là je vois pas comment on pourrait raccourcir (enfin, peut-être, j'en sais rien).

                                              • [^] # Re: dépendance à un système d'init

                                                Posté par (page perso) . Évalué à 3.

                                                Ce que je veux dire c'est que si ça démarre en une seconde j'ai le temps de rien voir, et pire encore si j'ai un écran de connexion qui apparaît avant que tout soit démarré.

                                                Les logs sont là pour ça, puis y une époque sous un GDM de Fedora il était possible de voir une icône qui avertissait en cas de service mal lancé et qui pouvait te montrer le texte de démarrage si tu ne l'avais pas vu).
                                                D'autant que soyons honnêtes, en général les services se lancent bien et cet état ne change pas à chaque boot. L’usage de journaux me semble plus pertinent, car après tout on ne regarde pas le bon fonctionnement en permanence de toutes les applications sinon on ne pourrait rien afficher d'autres sur l'écran.

                                                Je suis d'accord, mais j'aime bien avoir un rendu visuel sur le moment, et s'il y a un souci je vais ensuite voir les logs pour les détails, car je vais pas systématiquement voir les logs après chaque démarrage non plus :)

                                                GDM te proposait de visualiser s'il y avait eu des erreurs au démarrage, je pense qu'il doit être possible de coder facilement un programme similaire qui t'avertit une fois connecté s'il y a eu des soucis. Cela t'évite de devoir être derrière ton écran au démarrage et de perdre du temps pour rien en ralentissant volontairement la durée du démarrage.

                                                • [^] # Re: dépendance à un système d'init

                                                  Posté par (page perso) . Évalué à 1.

                                                  Je suis plutôt d'accord, je reste pas toujours devant l'écran au démarrage d'ailleurs. Après, peut-être que comme j'ai une configuration plutôt minimale, et j'utilise un simple tiling wm, que je démarre avec startx, ça fait longtemps que j'ai l'impression que tout est suffisamment rapide, d'où le fait que j'aie pas un vision claire de ce sujet sans doute.

                                              • [^] # Démarrage séquentiel avec systemd

                                                Posté par . Évalué à 1. Dernière modification le 05/02/14 à 20:03.

                                                J'imagine qu'on peux obtenir un démarrage séquentiel (plutôt que parallèle) avec systemd. Comment ? En listant les différentes unités qui sont lancées au démarrage (il y en a un paquet) et en les personnalisant à coup de After :

                                                [Unit]
                                                …
                                                After=unité-précédente
                                                

                                                C'est certainement fastidieux à faire, mais ça me semble un bon exercice pour comprendre le déroulement d'un boot. Le schéma des différentes target du boot est un point de départ pertinent pour ce travail.

                                              • [^] # Re: dépendance à un système d'init

                                                Posté par . Évalué à 2.

                                                Edit : Ah, et d'ailleurs, je pense à une chose : le seul moment où j'ai l'impression que le démarrage est trop long, c'est quand fsck fait son check des disques, et là je vois pas comment on pourrait raccourcir (enfin, peut-être, j'en sais rien).

                                                C'est vachement plus court en ext4, et encore plus sur un SSD.

                                                "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                                          • [^] # Re: dépendance à un système d'init

                                            Posté par . Évalué à 4.

                                            Perso, j'aime voir d'un coup d'œil que tous les services se lancent correctement, et c'est pas comme si ça mettait un temps fou : il y a plus de dix ans oui, mais aujourd'hui non, alors, à quoi bon de tout vouloir faire à la fois ?

                                            Pourquoi tout démarrer en meme temps ? Par ce qu'avec un systeme d'init qui gere correctement les interactions entre les differents services on peut se le permettre, et il n'y a pas d'interet à ne pas le faire.

                                  • [^] # Re: dépendance à un système d'init

                                    Posté par (page perso) . Évalué à 0.

                                    • j'ai pas envie d'user mon SSD avec l'hibernation,
                                    • j'ai pas de partition de swap,
                                    • ça démarre et ça s'arrête super vite.

                                    Écrit en Bépo selon l’orthographe de 1990

                                • [^] # Re: dépendance à un système d'init

                                  Posté par . Évalué à 3.

                                  Si le logiciel peut évoluer et obtenir les mêmes résultats sans devoir acheter du nouveau matos, c'est quand même pas plus mal.

                                  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                            • [^] # Re: dépendance à un système d'init

                              Posté par . Évalué à 9.

                              Je ne sais pas de quel Windows tu parles, mais le mien out of the box est utilisable en moins de 10 secondes, alors que le Linux n'a pas fini de démarrer.

                              Tous jusqu'à Seven. Seven est un peu mieux, mais c'est pas encore ça.

                              Faudrait arrêter un jour le FUD, et se demander pourquoi Linux est absent du Desktop (et non, ce n'est pas à cause d'une quelconque position domainante qui est une bonne excuse pour ne pas regarder le problème en face : il ne répond pas au besoin).

                              Zenitroll detected.

                            • [^] # Re: dépendance à un système d'init

                              Posté par (page perso) . Évalué à 1.

                              Je viens de «mesurer» sur mon Laptop, en UEFI : entre le bouton «power» et l'écran de connexion GDM3, il se passe 9 secondes (dont 1 seconde d'attente pour GRUB, que je pourrais désactiver).

                              En l'état, ça me semble plutôt rapide, et oui je suis plutôt d'accord avec toi : sur un Laptop la vitesse de démarrage est importante.

                              alf.life

                            • [^] # Re: dépendance à un système d'init

                              Posté par (page perso) . Évalué à 5.

                              ce n'est pas à cause d'une quelconque position dominante

                              Disons que ça aide beaucoup.

                              J'aimerais bien que dans les boutiques le matériel soit vendu séparément du logiciel, carrément en deux boites distinctes, comme quand tu achètes ta lessive dans un autre rayon que ta machine à laver. Juste pour voir, que les gens puissent voir combien ça leur coûte et puisse choisir des alternatives.

                              Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

              • [^] # Re: dépendance à un système d'init

                Posté par . Évalué à 1.

                Mais c'est pas une bonne chose de changer aussi régulièrement les API linux, c'est peut être l'un des gros problèmes de linux sur desktop. C'est les API du bureau linux. Le problème n'est pas fonctionnel.

                Non. Les API Windows changent aussi souvent, depuis bien plus longtemps que Linux n'existe. Et pourtant, Windows est toujours largement dominant sur le desktop.

                Avoir une vitesse de boot ou une gestion des sessions utilisateurs dans l'absolu c'est joli, mais ça apporte plus de bug d'intégration que de fonctionnalité pour l'utilisateur final.

                Source ? Tu veux revenir à HAL + SysV ? Sérieusement ?

                "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                • [^] # Re: dépendance à un système d'init

                  Posté par . Évalué à 3.

                  Non. Les API Windows changent aussi souvent, depuis bien plus longtemps que Linux n'existe. Et pourtant, Windows est toujours largement dominant sur le desktop.

                  …Parce que MS fait attention à la rétrocompatiblité, que la plupart des applications tierces sont pour Windows, et que la vente liée Wintel est pratiquée depuis des décennies.

                  "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                • [^] # Re: dépendance à un système d'init

                  Posté par . Évalué à 3.

                  Non. Les API Windows changent aussi souvent, depuis bien plus longtemps que Linux n'existe. Et pourtant, Windows est toujours largement dominant sur le desktop.

                  Leur qualité c'est de gérer proprement la compatibilité avec l'existant. Ça ça a de la valeur pour le bureau.

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: dépendance à un système d'init

                Posté par (page perso) . Évalué à 0.

                oui elle l'a déjà était pour ubuntu.

                NON

                Ubuntu, ils ont pris le code source de systemd, ils ont fait un beau paquet qui ne build que les utilitaires systemd (et pas l'init) et voilà, ça fonctionne…

            • [^] # Re: dépendance à un système d'init

              Posté par (page perso) . Évalué à 3.

              EDIT : je pense qu'il faut arrêter de critiquer tout uniquement parce qu'il y a le mot systemd dans la phrase. Oui avant on savait faire des trucs avant qu'aujourd'hui on ne fait plus forcément, mais c'est pareil pour tout. Il y a une époque sous Linux il fallait monter sa clé USB à la main, c'était cool cette époque. Aujourd’hui on a besoin de HAL ou de udev dans son système… C'est à peu près pareil pour tout, pour plus de conforts et d'efficacité certains composants sont apparus avec son lot de dépendance par la suite.

              Perso, ce n'est pas le mot systemd qui me dérange, mais l'impression que ces derniers temps le problème du système d'init semble si important que si on n'accueille pas toutes les nouveautés avec enthousiasme en acceptant sans broncher qu'elles sont universellement supérieures aux solutions existantes c'est qu'on est un vieux conservateur qui veut en rester à la préhistoire. Le plus logique ne serait pas que, suivant les besoins, les ressources et les objectifs d'une distribution, un ou plusieurs de ces systèmes soient supportés ?

              C'est comme HAL ou udev, c'est très bien, ça permet à un plus ample public de pouvoir monter des clés USBs facilement etc… mais est-ce vraiment utile dans tous les contextes? (vraie question, j'en sais rien si c'est possible de s'en passer sous linux) Et sinon, pourquoi faudrait-il voir d'un mauvais œil une distribution qui déciderait de ne pas les supporter ? (l'idée ne me semble pas choquante a priori)

              Et en ce qui me concerne, le système d'init et udev ne sont pas des choses qui impactent mon utilisation quotidienne de type desktop, et je ne suis peut-être pas un cas isolé. Le seul truc qui change chez moi, c'est que si je devais passer à systemd, il me faudrait écrire un unit pour par exemple configurer mon réseau, ce qui est peu de chose, même s'il me semble un peu plus compliqué (peut-être parce que nouveau pour moi ?) que deux lignes dans /etc/conf.d/net avec openrc de gentoo, ou l'interfaces de debian, ou encore le hostname.if d'openbsd.

              • [^] # Re: dépendance à un système d'init

                Posté par . Évalué à 10.

                Et en ce qui me concerne, le système d'init et udev ne sont pas des choses qui impactent mon utilisation quotidienne de type desktop, et je ne suis peut-être pas un cas isolé.

                De ce que je comprends, moi qui suis également un utilisateur desktop, je ne pense pas non plus être sévèrement impacté. J'ai trouvé sympa journald, mais on ne peut pas dire que ça change ma vie (utilisateur desktop: c'est pas comme si j'avais quelque chose à y chercher toutes les semaines…). Le temps de boot n'a jamais été ma priorité (ça le serait plus sur un laptop ou un netbook).

                Par contre, je crois bien que ce sont les mainteneurs de paquets qui sont impactés. D'abord parce qu'il faudra tout convertir, mais surtout ensuite parce que la maintenance sera autrement plus simple avec systemd.
                Des développeurs seront impactés aussi s'ils se mettent à utiliser les API offertes par systemd. Si ça leur plait, ce sera positif.

                Alors personnellement, je pencherais pour systemd parce que ça a l'air bien branlé de loin (je veux dire en tant que pas-du-tout-expert), et qu'on sent quand même une large vague d'adoption. Je me dis que si c'est tellement bon pour tous les autres, ça ne doit pas être si mal pour Debian, et puis autant de distros qui l'utilisent ne peuvent que le rendre plus robuste et pérenne.

                Du côté Upstart, je vois qu'il n'y plus qu'Ubuntu (?), dont les choix techniques font de moins en moins, voire plus du tout d'émules, et RedHat l'a laissé tomber. Et si Ubuntu décide de le lâcher aussi un jour?

                • [^] # Re: dépendance à un système d'init

                  Posté par (page perso) . Évalué à 1.

                  Par contre, je crois bien que ce sont les mainteneurs de paquets qui sont impactés. D'abord parce qu'il faudra tout convertir, mais surtout ensuite parce que la maintenance sera autrement plus simple avec systemd.

                  Je suis d'accord qu'avant tout le plus important est ce qu'en pensent les mainteneurs, et si systemd permet de faciliter les choses, tant mieux. Mais pour les distributions (ou des *BSD), qui se contenteraient de fonctionnalités basiques du type start-stop-restart-reload-check, je ne pense pas que la maintenance soit forcément plus facile avec systemd.

                • [^] # Re: dépendance à un système d'init

                  Posté par . Évalué à -3.

                  Par contre, je crois bien que ce sont les mainteneurs de paquets qui sont impactés. D'abord parce qu'il faudra tout convertir, mais surtout ensuite parce que la maintenance sera autrement plus simple avec systemd.

                  Ç'est un des arguments principaux avancés en faveur de systemd. Le problème, c'est que jamais je n'ai vu cette supposée charge de travail de maintenance démontrée. Intuitivement, je me demande qu'est-ce qu'il y a de lourd à maintenir des scripts de démarrage de démons qui n'évoluent pas tous les quatre matins. et dont la plupart suivent le même modèle. Il est possible que cette intuition soit fausse mais à chaque fois (dans les discussins que j'ai suivies) qu'on en arrive là, c'est "vous ne pouvez pas comprendre", "puisqu'on vous le dit", "vous n'avez qu'à participer", "vous êtes maintenant banni de la liste", etc. J'aimerais voir autre chose que des arguments d'autorité ou des cas particuliers.

                  Donc si quelqu'un pouvait par exemple comparer les commits concernant les scripts de démarrage par rapport au nombre de commits totaux d'une distrib, ça m'intéresserait.

                  • [^] # Re: dépendance à un système d'init

                    Posté par . Évalué à 9.

                    je me demande qu'est-ce qu'il y a de lourd à maintenir des scripts de démarrage de démons

                    D'après son site officiel, Nginx est

                    un serveur HTTP libre […] ainsi qu'un proxy inverse. […] il intègre également du proxy pour l'IMAP et le POP3.

                    Quand les mainteneurs d'un système d'exploitation packagent Nginx, ils doivent écrire un fichier adéquat : un script shell pour les distributions utilisant SysVinit, un fichier .service pour celles utilisant systemd, etc.

                    Comme les développeurs de Nginx sont des gens bons, ils proposent des fichiers prêts à l'emploi sur leur wiki. On y trouve des fichiers pour démarrer Nginx sous Debian, sous FreeBSD, sous Fedora, sous Ubuntu, et même sous OSX ! Mais malheureusement, rien pour OpenSUSE, ni pour Archlinux. Pendant que les packageurs de Debian et FreeBSD se contenteront d'un copié-collé, ceux d'OpenSUSE et d'Archlinux devront écrire eux-mêmes leur fichier. C'est vraiment injuste, ce monde est bien cruel.

                    Mais en fait, non.

                    OpenSUSE et Archlinux ont un point commun avec Fedora : l'utilisation de systemd. Lorsqu'on regarde le fichier pour lancer Nginx sous Fedora, on lit ceci :

                    Should work on Fedora, OpenSUSE, Arch Linux.

                    Aaah ! Finalement, les packageurs d'OpenSUSE et d'Archlinux pourront eux aussi copier-coller joyeusement. Ça va mieux.

                    Bref : toutes les distributions utilisant systemd peuvent partager le même fichier .service. Ainsi, les packageurs repompent comme des gorets s'inspirent du travail déjà réalisé par les autres packageurs. Le travail est mutualisé.

                    Pour répondre à ta question : j'ignore si l'écriture de scripts shell pour démarrer/arrêter un démon est pénible, et j'ignore si la maintenance de ces scripts est chronophage. C'est juste que les scripts shell ne sont guère efficaces pour encadrer les processus.

                    • [^] # Re: dépendance à un système d'init

                      Posté par . Évalué à 1.

                      C'est juste que les scripts shell ne sont guère efficaces pour encadrer les processus.

                      Bof si. Tu peut très bien gérer des groupes de contrôle dans uns script shell, rien ne t'en empêche.

                      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                      • [^] # Re: dépendance à un système d'init

                        Posté par . Évalué à 3.

                        Mouais, du temps de SysV, quasiment à chaque fois où j'arrêtais un daemon bloqué, je me retrouvais avec des processus zombie.

                        Les control groups, c'est mieux :
                        https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/ch01.html

                        The problem for over 30 years:
                        1) init starts a service process.
                        2) The service process starts some other sub process it needs.
                        3) The service process gets terminated to restart
                        4) The sub process stays running.
                        5) service started falls over in a heap because sub process is still alive.
                        That 1 to 5 (rundown) to your normal init systems includes (Ubuntu's) upstart.

                        Solaris and systemd due to usage of zones and cgroups (respectively):
                        1) init starts a service process wrapped.
                        2) The service process starts some other sub process it needs.
                        3) The service process gets terminated to restart
                        4) The sub process stays running.
                        5) Init system checks if anything is left in the cgroup or zone that should have been terminated.
                        6) service restarted stable.

                        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                        • [^] # Re: dépendance à un système d'init

                          Posté par . Évalué à 3.

                          C'est pas parce que les distributions utilisent des scripts qui ne se servent pas des cgroups que c'est impossible. Tu peut le faire avec cgexec par exemple et donc avec sysv ou rc.d sans problème notable.

                          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                        • [^] # Re: dépendance à un système d'init

                          Posté par . Évalué à 2.

                          Je pense qu'il voulait dire qu'il était possible de configurer de faire de la supervision par les cgroups via le shell également. Le problème à mon sens étant que ça demanderait de faire spécifiquement appel à du boilerplate dans chaque script d'init pour en profiter, alors qu'avec systemd c'est garanti par le système.

                          • [^] # Re: dépendance à un système d'init

                            Posté par . Évalué à 1.

                            Le problème à mon sens étant que ça demanderait de faire spécifiquement appel à du boilerplate dans chaque script d'init pour en profiter, alors qu'avec systemd c'est garanti par le système.

                            Je pense que ça demanderait une mise à jour d'init-functions avec probablement une mise à jour de l'API qui va avec. Ça ne me paraît pas plus moche que ce qu'il y aujourd'hui.

                            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # Re: dépendance à un système d'init

                      Posté par (page perso) . Évalué à 1.

                      Bref : toutes les distributions utilisant systemd peuvent partager le même fichier .service. Ainsi, les packageurs repompent comme des gorets s'inspirent du travail déjà réalisé par les autres packageurs. Le travail est mutualisé.

                      Ça c'est le cas à partir du moment ou tout le monde utilise le même système d'init.
                      Que ce soit systemd ou un autre n'a rien à voir.

                    • [^] # Re: dépendance à un système d'init

                      Posté par (page perso) . Évalué à 4.

                      Sur openbsd nginx est installé par défaut depuis un certain temps, le script d'init est ici (dernière modification il y a presque deux ans), et représente moins de dix lignes de code que quiconque connaissant un peu de shell serait capable de faire, même si c'est son premier script d'init. Il faut qu'il connaisse aussi un peu nginx bien sûr, mais si celui qui écrit un script d'init pour un logiciel ne le connaît pas au moins un peu…

                      Donc je dirais que la réponse à :

                      Pour répondre à ta question : j'ignore si l'écriture de scripts shell pour démarrer/arrêter un démon est pénible, et j'ignore si la maintenance de ces scripts est chronophage.

                      est plutôt non.

                      C'est juste que les scripts shell ne sont guère efficaces pour encadrer les processus.

                      Par contre, ici, en effet ça ne serait probablement pas optimal, car non prévu spécifiquement pour ce genre de choses. Et pour comble, sur le script que j'ai signalé ce ne serait même pas possible vu qu'openbsd ne supporte pas ce genre de fonctionnalités.

                      Tout dépend des fonctionnalités dont on a besoin, mais l'argument de la simplicité de maintenance des scripts d'init semble être valide ou non qu'au cas par cas, suivant les distributions et os (en supposant qu'un systemd ou équivalent fut possible ailleurs que sous linux). En ce qui concerne debian, vu qu'il a vocation à être un os universel, généraliste et populaire, le plus logique c'est que systemd soit supporté (par défaut ou non c'est une autre histoire), mais ça ne m'étonnerait que ça devienne le seul système supporté, tout simplement parce qu'il y a trop de gens derrière debian, avec des besoins variés et avis divergents, et qu'il y aura probablement bien quelqu'un pour packager openrc ou autre, m'enfin, peut-être que je me trompe totalement.

                      • [^] # Re: dépendance à un système d'init

                        Posté par . Évalué à 4.

                        mais ça ne m'étonnerait que ça devienne le seul système supporté

                        Là je dirais: d'un côté non, ça ne devrait pas être le seul supporté.
                        Mais de l'autre, il y a une deuxième question au vote: est-il autorisé ou non de dépendre d'un système init en particulier?
                        Si la réponse est oui, systemd ou upstart pourraient devenir les seuls supportés de fait, à cause d'un gros nombre de services pas compatibles avec les autres systèmes d'init.
                        Si la réponses est non, on augmente cette fois pas mal la charge de boulot des mainteneurs, parce qu'il faut se farcir tous les systèmes d'init de la distro. De là à rebuter certains packageurs esseulés…

                        • [^] # Re: dépendance à un système d'init

                          Posté par (page perso) . Évalué à 1.

                          Peut-être qu'en pratique ce sera quelque chose de plus granulaire : certains paquets comme gnome auraient une dépendance à systemd obligatoire pour simplifier la vie des packageurs, sans que cela affecte le choix d'un système d'init pour le système de base et les paquets pour lesquels supporter plusieurs systèmes d'init n'est pas un problème majeur. C'est de toutes façons comme ça déjà pour d'autres choses que le système d'init dans toutes les distributions, surtout binaires, où on peut pas faire des paquets précompilés pour toutes les options de compilation possibles pour permettre de gérer totalement ce qu'on veut ou non dans son système.

                    • [^] # Re: dépendance à un système d'init

                      Posté par . Évalué à 1.

                      Et utiliser systemd qui est ouvertement et volontairement Linux-only est une avancée sur ce point parce que… ?

                      Si le but du jeu était de simplifier la vie des mainteneurs de logiciels tiers c’est OpenRC ou initng qui aurait été poussé au forceps, pas systemd.

                      • [^] # Re: dépendance à un système d'init

                        Posté par (page perso) . Évalué à 6.

                        Et utiliser systemd qui est ouvertement et volontairement Linux-only est une avancée sur ce point parce que… ?

                        SysV était aussi Linux-centré dans les faits.
                        Rien qu'entre Debian et une Red-Hat, les scripts étaient différents ! Alors je n'imagine pas avec d'autres UNIX utilisant SysV mais non Linux.

                        Bref, avant ce n'était pas du tout portable, aujourd'hui les distribution linux ont un truc portable, c'est mieux qu’avant non ?

                        • [^] # Re: dépendance à un système d'init

                          Posté par . Évalué à 1. Dernière modification le 03/02/14 à 22:29.

                          Avant une solution portable était possible mais tout le monde s’en foutait (la preuve, initng n’a jamais décollé alors qu’il était là des années avant même que upstart soit en discussion, qui lui-même est antérieur à systemd…)

                          Maintenant une solution portable est juste impossible.

                          J’ai du mal à voir l’amélioration sur cet axe d’analyse…

                          C’est pas grave hein : comme je l’ai dit, en pratique tout le monde s’en fout (tout simplement parce que les distribs tiennent à garder le contrôle de leurs scripts d’init, cf debian qui refuse d’utiliser des unit systemd dans lesquelles les chemins seraient hardcodés, et upstream sait que c’est pas son boulot de fournir 200 scripts d’init mais celui du packageur). Tout ce que je dis c’est qu’il est naïf de croire l’excuse que « systemd c’est fait pour simplifier la vie des mainteneurs upstream ». Ça n’a jamais été son but de toute façon, les buts affichés de systemd c’est :

                          • un démarrage rapide (parallélisation des serveurs)
                          • exposition de fonctionnalités Linux-centric peu utilisées à cause du manque d’outils en userspace (typiquement les cgroup)
                          • à plus long terme, intégration des services de bas niveau (init & udev c’est fait, logind va rejoindre bientôt, à terme wayland va probablement l’être)

                          SysV était aussi Linux-centré dans les faits.

                          Pas vraiment non.

                          • [^] # Re: dépendance à un système d'init

                            Posté par (page perso) . Évalué à 4.

                            SysV était aussi Linux-centré dans les faits.

                            Pas vraiment non.

                            Pas SysV en lui même, mais ses scripts inits de Linux ne sont pas utilisables en dehors de ce cadre.

                            • [^] # Re: dépendance à un système d'init

                              Posté par . Évalué à 1.

                              Mais ce n'est pas un problème de Linux/!Linux et il n'y a pas de "scripts inits de Linux", puisque SysV n'impose pas grand chose et que chaque distrib, de Linux ou autre, est libre de faire les scripts qu'elle veut pour coller à sa spécificité ou bien de reprendre tels quels les scripts d'une autre si elle ne tient pas à se différencier sur ce point.

                          • [^] # Re: dépendance à un système d'init

                            Posté par . Évalué à 5. Dernière modification le 03/02/14 à 23:35.

                            les buts affichés de systemd c’est :
                            - un démarrage rapide (parallélisation des serveurs)

                            Pas du tout.

                            Tout ce que je dis c’est qu’il est naïf de croire l’excuse que « systemd c’est fait pour simplifier la vie des mainteneurs upstream »

                            Et pourtant, dans les faits c'est le cas. Comme par exemple, pour les mainteneurs de Archlinux.
                            C'est l'une des raisons du passage à systemd, et ils ont eu raison.

                            Et puis :

                            Myth: systemd being Linux-only is not nice to the BSDs.

                            Completely wrong. The BSD folks are pretty much uninterested in systemd. If systemd was portable, this would change nothing, they still wouldn't adopt it. And the same is true for the other Unixes in the world. Solaris has SMF, BSD has their own "rc" system, and they always maintained it separately from Linux. The init system is very close to the core of the entire OS. And these other operating systems hence define themselves among other things by their core userspace. The assumption that they'd adopt our core userspace if we just made it portable, is completely without any foundation.

                            Myth: systemd being Linux-only makes it impossible for Debian to adopt it as default.

                            Debian supports non-Linux kernels in their distribution. systemd won't run on those. Is that a problem though, and should that hinder them to adopt system as default? Not really. The folks who ported Debian to these other kernels were willing to invest time in a massive porting effort, they set up test and build systems, and patched and built numerous packages for their goal. The maintainance of both a systemd unit file and a classic init script for the packaged services is a negligable amount of work compared to that, especially since those scripts more often than not exist already.

                            Myth: systemd could be ported to other kernels if its maintainers just wanted to.

                            That is simply not true. Porting systemd to other kernel is not feasible. We just use too many Linux-specific interfaces. For a few one might find replacements on other kernels, some features one might want to turn off, but for most this is nor really possible. Here's a small, very incomprehensive list: cgroups, fanotify, umount2(), /proc/self/mountinfo (including notification), /dev/swaps (same), udev, netlink, the structure of /sys, /proc/$PID/comm, /proc/$PID/cmdline, /proc/$PID/loginuid, /proc/$PID/stat, /proc/$PID/session, /proc/$PID/exe, /proc/$PID/fd, tmpfs, devtmpfs, capabilities, namespaces of all kinds, various prctl()s, numerous ioctls, the mount() system call and its semantics, selinux, audit, inotify, statfs, O_DIRECTORY, O_NOATIME, /proc/$PID/root, waitid(), SCM_CREDENTIALS, SCM_RIGHTS, mkostemp(), /dev/input, …

                            And no, if you look at this list and pick out the few where you can think of obvious counterparts on other kernels, then think again, and look at the others you didn't pick, and the complexity of replacing them.

                            Myth: systemd is not portable for no reason.

                            Non-sense! We use the Linux-specific functionality because we need it to implement what we want. Linux has so many features that UNIX/POSIX didn't have, and we want to empower the user with them. These features are incredibly useful, but only if they are actually exposed in a friendly way to the user, and that's what we do with systemd.

                            "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                            • [^] # Re: dépendance à un système d'init

                              Posté par . Évalué à 0.

                              Et pourtant, dans les faits c'est le cas. Comme par exemple, pour les mainteneurs de Archlinux.

                              upstream = nginx/mysql/…, pas arch/slackware/debian

                              Et puis :

                              Ben, c’est exactement ce que je dis :
                              - un système d’init portable tout le monde s’en fout
                              - systemd n’est pas et ne sera jamais portable parce qu’il expose des fonctionnalités spécifiques à Linux, donc prétendre que « systemd c’est bien parce que ça va enfin nous donner un init universel », je ris très fort

                              • [^] # Re: dépendance à un système d'init

                                Posté par . Évalué à 9.

                                • systemd n’est pas et ne sera jamais portable parce qu’il expose des fonctionnalités spécifiques à Linux, donc prétendre que « systemd c’est bien parce que ça va enfin nous donner un init universel », je ris très fort

                                Ris très fort, mais si tu fais exprès de ne pas comprendre, tu peux aller rire tout seul dans ton coin.
                                Lorsqu'il est dit « systemd c’est bien parce que ça va enfin nous donner un init universel », il faut bien comprendre l'ellipse faite ici qui est : un init universel pour toutes les distribs linux!

                                Comme çà:
                                - un utilisateur/admin système peut intervenir sur n'importe qu'elle distrib, il n'aura pas à réapprendre un init différent ou à analyser un script d'init différent,
                                - le fichier de config d'un service sera le même sur TOUTES les distribs et pourra être contribué en upstream

                            • [^] # Re: dépendance à un système d'init

                              Posté par . Évalué à -1.

                              Tout ce que je dis c’est qu’il est naïf de croire l’excuse que « systemd c’est fait pour simplifier la vie des mainteneurs upstream »

                              Et pourtant, dans les faits c'est le cas. Comme par exemple, pour les mainteneurs de Archlinux.

                              Quand j'ai parlé de gens qui n'avaient rien démontré à ce sujet, je parlais principalement d'eux.

                              C'est l'une des raisons du passage à systemd, et ils ont eu raison.

                              Ah.

                          • [^] # Re: dépendance à un système d'init

                            Posté par . Évalué à 8.

                            debian qui refuse d’utiliser des unit systemd dans lesquelles les chemins seraient hardcodés

                            Ce qui est idiot, il suffit de définir pour chaque unité un EnvironmentFile dans lequel tu peux définir les chemins dans des varibles…

                            Systemd a réellement été conçu pour être le plus générique possible, en fournissant le moyen de séparer configuration et commandes. À l'inverse de SysV où tout est mélangé.

                            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                          • [^] # Re: dépendance à un système d'init

                            Posté par . Évalué à 4.

                            exposition de fonctionnalités Linux-centric peu utilisées à cause du manque d’outils en userspace (typiquement les cgroup)

                            Justement. Systemd est maintenant un outil en plus en userspace, tu devrais être content :-)

                            Tu ne l'a pas écrit mais le but initial de Systemd est de simplifier la vie des administrateurs. Et après avoir passé un peu de temps avec c'est bien le cas.

                            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                          • [^] # Re: dépendance à un système d'init

                            Posté par . Évalué à 6.

                            Ce qui gène fondamentalement la portabilité, c'est que les fichiers sont placés à des endroits différents sur chaque distribution. Et ce pour des raisons historiques et de non concertation. Alors oui, certains choix sont vraiment motivés et il est important que les distrib puissent faire des choix différents. Mais dans pas mal de cas, c'est complètement inutile. Parce que bon, placer un fichier dans /etc/network-conf/ ou /etc/conf-network/ c'est kif kif et haricot, tout ça c'est du même acajou.

                            Je crois me souvenir que c'était aussi un des but de Poettering quand il a lancé systemd. Forcer un peu d'uniformisation.

                          • [^] # Re: dépendance à un système d'init

                            Posté par (page perso) . Évalué à 4.

                            Avant une solution portable était possible mais tout le monde s’en foutait

                            Ou alors tu avais une belle théorie, et une merde de pratique.
                            systemd a l'avantage de ne pas que théorique.

                            Et utiliser systemd qui est ouvertement et volontairement Linux-only

                            1/ Troll sur le "volontairement" alors que c'est juste le développeur principal qui ne veut pas se limiter en fonctionnalités ou perdre son temps dans des trucs qui ne l'interesse pas lui (genre séparer les fonctions en modules), et ça se comprend. libre à toi de te proposer pour aider à le faire (mais sans mettre des batons dans les roues pour le but du projet hein, ralentir le projet n'est pas acceptable et c'est normal)
                            2/ Tu es libre d'adapter systemd aux autres OS (et de désactiver les fonctionnalités pas supportés par l'OS si besoin, pas grave), d'utiliser le même format de fichier etc… Dur dur la liberté… Juste qu'en pratique, on s'en fou, sinon un gus porterai systemd ou un truc compatible avec les fichiers systemd sur les autres OS. Juste que les gars veulent surtout pas avoir un truc commun, donc ça n'arrivera pas de si tôt (vu le peu d'utilisation de Debian/kfreebsd, ça ne va pas pousser les gens àà avoir un système d'init commun).

                            Bref, tu parles de théorie, systemd vit dans la pratique.

              • [^] # Re: dépendance à un système d'init

                Posté par . Évalué à 2.

                C'est comme HAL ou udev, c'est très bien, ça permet à un plus ample public de pouvoir monter des clés USBs facilement etc… mais est-ce vraiment utile dans tous les contextes?

                udev sert à gérer le matériel, et c'est lui qui s'occupe de peupler /dev. Tu vois un exemple où il n'y en a pas besoin ?

                "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                • [^] # Re: dépendance à un système d'init

                  Posté par (page perso) . Évalué à 2.

                  Je pensais à un remplacement plus léger et avec moins de fonctionnalités (genre mdev peut-être, mais je connais pas assez pour dire s'il y a vraiment un intérêt ou non), ou au fork sous gentoo pour se passer d'une dépendance à systemd, je sais pas si c'est vraiment un bonne idée non plus, mais pourquoi pas.

                • [^] # Re: dépendance à un système d'init

                  Posté par . Évalué à -2.

                  Il y a eu une vie avant udev, hein… Et même pendant, vu l'instabilité du machin.

                • [^] # Re: dépendance à un système d'init

                  Posté par . Évalué à 2.

                  Je suis assez ignare sur ce sujet, mais il me semble avoir lu par ci et par là qu'avant, c'était un fichier qui contenait une description statique des périphériques.

                  Du coup, dans le cas, par exemple, d'un téléphone où de toute machine sur laquelle on ne peut pas ajouter de nouveaux périphériques plug-and-play, udev me semble totalement inutile ( si rien ne change, gérer dynamiquement les choses est juste débile ).

                  Pour les non plug-and-play "actifs" ( j'entends par actif qui ne fasse pas qu'émettre ou recevoir un signal analogique, c'est à dire plus compliqué qu'un bête écouteur ou chargeur de batterie ), je ne sais pas du tout si udev fonctionne ( ça fait bien longtemps que je n'ai pas vu de périphériques non plug-and-play "actifs" ).

                  Le seul souci étant, au final, d'avoir la bonne table au bon moment, ce qui peut être pénible pour des PCs ( portable ou non ) sur lesquels on branche pour certains régulièrement des périphériques USB par exemple, qui me semble actifs.

                  Mais, comme j'ai dit, je suis totalement novice en la matière et j'ai probablement effectué de gros raccourcis disgracieux. Si c'est le cas, je suis preneur de toute remarque constructive ( autre que rtfm, parce que, basiquement, ce type de fm nécessite pour être bien compris une certaine connaissance de toute l'archi linux, chose qui n'est pas à ma portée actuelle. ).

                  • [^] # Re: dépendance à un système d'init

                    Posté par . Évalué à 10.

                    Du coup, dans le cas, par exemple, d'un téléphone où de toute machine sur laquelle on ne peut pas ajouter de nouveaux périphériques plug-and-play, udev me semble totalement inutile ( si rien ne change, gérer dynamiquement les choses est juste débile ).

                    Cartes SD ?
                    Périphériques bluetooth ?
                    Activation dudit bluetooth, du wifi, etc
                    Périphériques USB, câble hdmi etc …

                    Bref, c'est loin d'être statique, tout ça…

                • [^] # Re: dépendance à un système d'init

                  Posté par . Évalué à 2.

                  mknod existe toujours :)

        • [^] # Re: dépendance à un système d'init

          Posté par (page perso) . Évalué à 4.

          Faux, il suffit d'utiliser le service systemd en question… En gros, savoir découper correctement un paquet, il me semble que chez Debian ils savent faire…

    • [^] # Re: dépendance à un système d'init

      Posté par . Évalué à 4.

      Je pense qu'arrivé là, tous les votants connaissent les tenants et aboutissants et les conséquences de chaque combinaison.
      Tu mentionnes Gnome de plus en plus dépendant de systemd, je peux répondre "quid de Debian/kFreeBSD?"

      J'ose espérer qu'ils savent déjà qu'aucune solution n'est parfaite, et quelle que soit la décision, il y aura beaucoup de boulot à abattre. On ne sait juste pas encore par qui… ;)

      • [^] # Re: dépendance à un système d'init

        Posté par . Évalué à 1.

        J'ai confiance en Debian pour ce genre de choses. Comme tu l'as souligné, quid de kFreeBSD? Après tout, cette version de la distro est bien moins obscure que le port Hurd, donc on peut supposer qu'elle à une certaine importance aux yeux des mainteneurs Debian.

  • # Simple

    Posté par (page perso) . Évalué à 10.

    Connaissant Debian, ils vont réussir à nous mettre toutes les solutions en même temps !

    • [^] # Re: Simple

      Posté par (page perso) . Évalué à 1.

      Je peux très bien imaginer lors d'une installation, que "l'installeur" me propose une solution par "défaut" tout en me laissant le choix d'opter pour un autre système d'init.

      • [^] # Re: Simple

        Posté par (page perso) . Évalué à 7.

        Ceux qui ont lu le journal avant de troller ont d'ailleurs déjà constaté que la décision concerne uniquement le choix du système d'init par défaut, et qu'à aucun moment il n'est évoqué l'idée d'arrêter de maintenir les autres.

      • [^] # Re: Simple

        Posté par . Évalué à 3.

        En effet. Et peut-être qu'un jour on aura tout le système configurable à partir de l'installateur… le kernel, l'init, le serveur d'affichage, le bureau… ça serai génial ça.

        A l'heure actuelle il n'y a que le bureau… pour certains autres outils le seul choix est de ne pas installer.

Suivre le flux des commentaires

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