Journal Vous avez aimé BSD vs System V ? Vous aimerez systemd vs openRC (et le reste du monde)

Posté par  (site web personnel) . Licence CC By‑SA.
-20
25
juil.
2017

C'est assez intéressant de prendre les choses avec recul. Comme par exemple systemd. Vous avez tenté de passer de CentOS 6 à CentOS 7 ? Voilà un changement majeur du boot, et même du fonctionnement global des services qui s'opére au sein de Linux. En fait c'est bien simple : en utilisation serveur on a l'impression d'avoir changé de distribution. Or les distributions, voilà un sujet de guerre de religion pour le vendredi ; et quand on sait que dans un passé que je n'ai pas connu, on a déjà eu droit à de long trolls BSD vs System V… Ajoutez à cela la résistance au changement, et le fait que le développeur de systemd se vante d'avoir cassé le son sous Linux dans son précédant projet (Pulse Audio), et s'est fait détesté cela (à juste titre, même si les distributions ne sont pas innocentes). Ça y est nous avons une planche savonneuse pour systemd.

Techniquement, on ne va pas nier qu'il y a des apports. Est-ce le problème ? En fait, systemd n'est pas « que » un simple remplacement de sysvinit que nous connaissions. C'est un changement de philosophie.

Alors qu'anciennement sous Linux les différents briques d'une distribution étaient assez indépendants, dans un philosophie KISS, systemd viens englober de plus en plus de fonctionnalités : login, pam, getty, syslog, udev, cryptsetup, cron, at, dbus, acpi, cgroups, gnome-session, autofs, tcpwrappers, audit, chroot, mount… Certaines de ces fonctionnalités pas nécessairement utiles pour un boot (D-BUS au boot ? pour quoi faire ?). Toutes les distributions systemd sont en train de converger pour se ressembler, et bientôt, tout comme freedesktop a tenté d'unifier le desktop, systemd unifiera les distributions entre elles.

Est-ce un mal ? Freedesktop a fait converger KDE et Gnome, mais pour ce qui est du code commun, très peu. En outre rien n'interdit de continuer à utiliser window maker ou enlightment. Au contraire de systemd, qui est en train de bouffer l'univers Linux : dépendance de KDE à systemd, dépendance de Gnome à systemd. Les distributions majeures sont toutes en train de sauter le pas. Se passer de systemd deviends difficile, alors même que le rôle important du logiciel (PID 1) en fait une partie importante, et même essentielle du système. Dans l'univers libre, on s'est toujours vanté de la diversité des approches et des logiciels et des manières de faire (KDE / Gnome, vim/emacs, Linux/BSD, gcc/LLVM, libc/musl, etc…), avec systemd que désire unifier le boot, c'est aussi la perte de la diversité. En conséquence, nous avons une centralisation du développement de toutes les distributions Linux chez Red Hat. Certains paranos ne voient pas cela d'un bon oeil.

Pourrons-nous encore nous passer de systemd ? Car en fait, aussi bien ceux qui rêvent que systemd vienne unifier le joyeux bordel que peut être le libre et les distributions que ceux qui en ont peur oublient une chose : la diversité du libre. Au début des années 90 étaient 386BSD, qui a alors forké en Net/Open/Free BSD d'un côté, et GNU/Linux de l'autre. On a pu penser vers 2005 que NetBSD et sa portabilité était mort, que FreeBSD 5 en retard sur Linux 2.6, et OpenBSD se portait bien, mais essentiellement en utilisation sur un système qui a besoin de haute sécurité / un routeur… Et pourtant, NetBSD est aujourd'hui plus actif que jamais, des forks ont eu lieu notamment de FreeBSD (Dragonfly, TrueOS, etc), et ZFS y est supporté nativement, ce qui n'est pas le cas de Linux. Et je ne parle même des distributions Linux de plus en plus nombreuses avec des philosophies différentes qui se sont créés. Et voila où je veux en venir : si par le passé on a pu opposer des distributions KDE à des distributions Gnome (aujourd'hui on peut rajouter XFCE, Mate, LXDE, etc..), bientôt on parlera de deux familles de distributions différentes : les distributions systemd, et les distributions non systemd/openRC. Vous vouliez unifier ? Nous allons forker !

En réalité, le fork a déjà eu lieu lors de l'inclusion d'udev dans systemd : gentoo a déjà forké udev et travaille sur un système de démarrage moderne restant dans la philosophie traditionnelle : openRC.

Alors allons-y, pour les membres importants de chaque famille :

Famille systemd : RedHat, Centos, Fedora, OpenSüse, Ubuntu et ses dérivés (abandon d'upstart), Mint, Debian (systemd est débrayable, non sans poser des problèmes de dépendance).

Famille non systemd : Gentoo (bien que systemd soit disponible optionnellement, OpenRC est un projet issu de Gentoo), Devuan (fork de debian sans systemd dont on pourrait bien entendre parler dans les prochains mois), Slackware (on voit mal Patrick Volkerding changer le système d'init particulier de la distribution), PCLinuxOS, Alpine Linux, Puppy Linux (distribution musl), à laquelle on pourra rajouter toute la famille des BSD.

Famille non décidée : Manjaro, Arch Linux. Systemd est un troll très récurrent chez Arch Linux, le choix par défaut est systemd, mais le fonctionnement sans systemd est possible.

Voilà, je suis prêt à parier que dans les mois qui vont venir, certains seront tentés de migrer de distribution, si ce n'est déjà fait.

  • # Ah le désespoir

    Posté par  . Évalué à 10.

    Famille systemd : RedHat, Centos, Fedora, OpenSüse, Ubuntu et ses dérivés (abandon d'upstart), Mint, Debian (systemd est débrayable, non sans poser des problèmes de dépendance).

    Famille non systemd :

    Bref, 95% du monde Linux sur systemd, 5% sur le reste (et encore je suis gentil).

    Amusant que vous croyiez encore qu'il y a une bataille ici. Systemd a gagné la guerre, c'est fini.

    • [^] # Re: Ah le désespoir

      Posté par  . Évalué à -7. Dernière modification le 25 juillet 2017 à 21:45.

      Oui et non. Il faut attendre que SystemD murisse… ou pourisse. On a déjà vu des retours arrière spectaculaire même s'il est assez peu probable. Tant que des distributions assez importantes (Gentoo) ne s'y mettent pas tout reste possible tant que les compétences SystemV existent encore chez les Linuxiens.

      • [^] # Re: Ah le désespoir

        Posté par  . Évalué à 10.

        Tant que des distributions assez importantes (Gentoo)

        Tout à fait. Le problème est que Gentoo n'est pas importante. C'est un nain comparé à l'autre camp.

      • [^] # Re: Ah le désespoir

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

        systemd, pas SystemD. sinon on a pas fini avec HttpD, NgircD, DhcpcD,

        git is great because linus did it, mercurial is better because he didn't

    • [^] # Re: Ah le désespoir

      Posté par  . Évalué à -10.

      c'est toujours très intéressant lorsqu'un non-utilisateur de Linux donne son avis sur la question.

      « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

    • [^] # Re: Ah le désespoir

      Posté par  . Évalué à -3. Dernière modification le 26 juillet 2017 à 10:51.

      Amusant que vous croyiez encore qu'il y a une bataille ici.

      Tu ne t'adresses pas au rédacteur du journal, sinon tu utiliserais la deuxième personne du singulier au lieu de celle du pluriel. L'adverbe ici ne se rapporte pas à systemd, tu aurais écrit à ce sujet sinon. Donc, ça voudrait dire que sur DLFP les gens en général (cette formule est en elle-même un peu vague, j'essaie de traduire) pensent encore qu'il y a une bataille à propos de systemd. Ça me semble totalement faux. Ou alors tu voulais dire autre chose et il faudrait que tu l'exprimes mieux.

      • [^] # Re: Ah le désespoir

        Posté par  . Évalué à -2.

        Pour ceux qui ont la compréhension lente ou difficile ou qui ont du mal à dégager le sens d'une phrase quand ils trouvent qu'elle comporte trop de mots, le commentaire précédent ne dit rien contre systemd.

        Ceci fait partie de la série comment se faire des amis.

        • [^] # Re: Ah le désespoir

          Posté par  . Évalué à 10.

          Elle ne dit rien contre systemd mais tout le monde avait compris que le « vous » s'adressait aux gens qui critiquent systemd à tout va.

          « 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: Ah le désespoir

            Posté par  . Évalué à 2.

            Ben critiquer systemd et donc regarder ce qui se passe chez la concurrence c'est un peu logique … vu les merdes que systemd a eu recemment niveau securite. Alors moi je suis qu'un trolleur mais bon quand meme Linus commence a peter un cable je pense qu'il peut y avoir des questions a se poser mais bon sinon on peut encore utiliser des OS merdiques si on refuse de poser les questions.

            Par exemple:

            https://usn.ubuntu.com/usn/usn-3341-1/

            Systemd veut tout faire et en fait clairement trop aujourd'hui. C'est ce que l'on appele a "single point of failure".

            • [^] # Re: Ah le désespoir

              Posté par  . Évalué à -4. Dernière modification le 26 juillet 2017 à 15:08.

              "single point of failure".

              Yep. C'est un peu ce que les détracteurs se sont tués à expliquer. Moi, j'ai envie de dire: "Et SPOF dans vos faces les pro-sysd!".

              (pas pu m'empêcher pour la vanne merdique)

            • [^] # Re: Ah le désespoir

              Posté par  . Évalué à 9.

              Ça n'affecte que les gens qui utilisent systemd-resolved. Il n'est pas obligatoire.

              « 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: Ah le désespoir

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

              Encore cette histoire du systemd-resolved qui n'est presque jamais activé ?

              Un libriste qui en a sa claque des puristes.

    • [^] # Re: Ah le désespoir

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

      Bah Slackware a l'air de représenter entre 9% et 10% des Linux, et n'est pas la seule distribution sans systemd.
      Donc le 95% est bien ce qu'il semble être : trollesque.
      Maintenant si tu avais dit 80%, l'idée était la même, et déjà bien plus difficile à réfuter.

      Mais bon, quand on trolle, on ne compte pas :)

      Yth.

      • [^] # Re: Ah le désespoir

        Posté par  . Évalué à 7.

        Slackware a l'air de représenter entre 9% et 10% des Linux

        source?

        • [^] # Re: Ah le désespoir

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

          J'ai peut-être mal cherché, mais la seule source que j'ai trouvé c'est celle-là :
          https://www.linuxcounter.net/statistics/distributions
          Sur distrowatch on a juste la popularité des pages des distribs, ce qui n'indique pas grand chose sur leur utilisation.
          Et ailleurs, rien trouvé de spécialement pertinent…

          Ça m'embête de n'avoir qu'une seule source, généralement j'aime bien recouper et me faire une meilleure idée, mais c'est une question difficile.

          Yth.

          • [^] # Re: Ah le désespoir

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

            Site qui a un biais assez fort lié au niveau technique et à la date de première installation (ce site était populaire il y a longtemps, bien moins aujourd'hui).

            Honnêtement, je n'ai jamais croisé plus qu'un couple de Slackware en utilisation dans n'importe qu'elle convention du LL que j'ai assisté. 5-10% de Slackware cela me semble bien trop élevé par rapport à la réalité du terrain.

            De toute façon sur la question, c'est difficile d'avoir des chiffres absolus, et cela dépend si tu prends en compte ou non les serveurs et machines virtuelles.

          • [^] # Re: Ah le désespoir

            Posté par  . Évalué à 5.

            Si on suppose que les gens qui vendent des journaux le font en espérant toucher le public le plus large possible, alors je dirais que je n'ai juste jamais rien vu qui parle de slackware, a mettre en parallèle avec le fait que j'ai déjà vu des journaux parler de la famille BSD.

            Le sentiment (ben oui, ce ne sont pas des chiffres, tout comme les chiffres de distrowatch ne concernent pas l'utilisation) qui s'en dégage, c'est que slack est ultra minoritaire en normandie et région parisienne (les lieux ou j'ai acheté ce type de magazines ces 4 dernières années).
            Comme 10% ne me semble pas du tout ultra minoritaire, l'impression que j'ai est que ce chiffre est totalement faux.

            Bon après, ma base de raisonnement est limitée dans le temps et l'espace, et je ne connais moi-même personne qui utilise linux au quotidien. Au niveau taf, les seules distrib que j'ai croisées sont Debian et CentOS, ainsi que Red Hat Linux en recherche d'emploi (pas croisée donc, mais a été mentionnée).
            Si je m'en tenais a mon vécu "physique", slack n'existerait tout bonnement pas du tout, ce qui est évidemment faux. Par contre, même sur le net, on en parle quand même très peu, il y a peu de références à elle (comparé aux autres distrib linux et aux *BSD, hein).

            mais c'est une question difficile.

            Impossible, même. C'est impossible de chiffrer le taux d'utilisation d'une distrib gratuite au niveau mondial.

            • [^] # Re: Ah le désespoir

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

              Par contre, même sur le net, on en parle quand même très peu, il y a peu de références à elle

              En même temps, pourquoi parlerait-on d’une distribution dont le (quasi-)seul développeur n’est pas une grande gueule, n’a pas d’opinion tranchée sur Systemd, Wayland, Flatpak ou tous les autres sujets qui animent les forums des autres distributions, et globalement fait son job dans son coin sans faire d’histoires ? (À ma connaissance, la seule opinion tranchée bien connue de Patrick Volkerding est sa préférence marquée pour KDE par rapport à GNOME, et même là-dessus on ne peut pas dire qu’il soit très véhément.)

              Slackware n’est pas non plus une distribution qui se fixe des objectifs grandiloquents (genre faire tomber Windows de son piédestal sur le marché du desktop, cf. un certain « bug numéro 1 »), et ne se précipite pas pour intégrer les dernières nouveautés.

              Franchement, pourquoi parlerait-on de Slackware ? Les seules fois où il y a quelque chose à dire sur cette distribution, c’est pour annoncer une nouvelle version. Et à chaque fois, ça semble d’ailleurs surprendre du monde de constater que, ah tiens, Slackware est encore là.

              Ben oui, Slackware est encore là. Ce n’est pas parce ce qu’elle est médiatiquement inexistante qu’elle a cessé d’être.

              • [^] # Re: Ah le désespoir

                Posté par  . Évalué à 2.

                Mais du coup, comment une distribution quasi inexistante médiatiquement pourrait avoir 10% des utilisateurs de distrib linux, même en se limitant au monde serveurs et machines de bureau (parce que si on inclue android, c'est juste évident qu'on est loin des 10%)?

                Je ne dis pas que son auteur devrait l'ouvrir plus, je réagissais juste à l'affirmation que slack représente 10% de PdM dans le monde linux sus-cité.

          • [^] # Re: Ah le désespoir

            Posté par  . Évalué à 8.

            Site qui ne couvre que les hobbyistes, et qui compte probablement encore ma Mandrake d'il y a presque 20 ans.

            Ayant connaissance des chiffres sur AWS je peux te dire que linuxcounter est à la ramasse.

            • [^] # Re: Ah le désespoir

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

              Si tu as mieux comme chiffres, je t'en prie, fais-toi (et nous) plaisir et donne-les !

              J'ai du mal à croire que Slackware et Gentoo, ainsi que leurs dérivés, ne fassent pas 5% des machines sous Linux.

              Pas au vu du dynamisme des communautés, des retours, du nombre de mainteneurs (non, non, la Slackware au sens large, officiellement reconnue, n'est pas réduite à Patrick et à AlienBob).

              Mais d'un autre côté, le nombre d'utilisateurs de Linux a beaucoup augmenté avec Ubuntu.

              Après, les disparités locales sont une évidence. Il y a 15 ans en France c'était Mandrakiva la favorite, et le biais français la mettait clairement au dessus de son niveau international. Il y a peu de chance que les anciens utilisateurs de cette distribution soient 1) tous passés à Mageia, et 2) beaucoup passés à la Slackware. Essentiellement du fait de la différence de façon d'administrer qui sépare quand même beaucoup les Debianidés et les Redhatidés, des autres.

              Ya-t-il un biais en Normandie ? Oui, comme partout.
              Est-ce que 95% des installations Linux utilisent systemd ? J'en doute très fortement…

              Ça ne change pas grand chose au propos initial, 95% c'est du trollage, mais dire probablement plus de 80% c'était crédible, difficilement réfutable sans une bonne dose de mauvaise foi, et servait tout aussi clairement ton propos.

              Propos dont au final on se fout pas mal, parce que bon, Linux sur le desktop ça reste moins de 5%, complètement écrasé par Windows et MacOS, et ce n'est certainement pas une raison de le laisser tomber, pas plus que les BSD d'ailleurs, et d'accepter qu'il n'y a plus de lutte, et que tout est joué.
              Ça n'a pas de sens, et en plus il n'y a pas d'opposition.
              Qu'est-ce que ça pourrait faire que 95% des installation Linux utilisent systemd si j'ai envie de faire partie du 5% ?
              Je n'ai pas conscience d'une guerre, pas conscience qu'on m'ait enlevé mon choix non plus.
              Je ne me sens pas plus concerné que par l'existence de Windows ou MacOS, pas mon problème.

              Yth.

              • [^] # Re: Ah le désespoir

                Posté par  . Évalué à 7.

                Si tu as mieux comme chiffres, je t'en prie, fais-toi (et nous) plaisir et donne-les !

                Je ne peux évidemment pas donner de chiffres, pas le droit.

                Pas au vu du dynamisme des communautés, des retours, du nombre de mainteneurs (non, non, la Slackware au sens large, officiellement reconnue, n'est pas réduite à Patrick et à AlienBob).

                Faut que tu reviennes sur terre, ce qu'ils font est une goutte d'eau comparé à ce qui se passe chez Ubuntu & Redhat par exemple.

                Qu'est-ce que ça pourrait faire que 95% des installation Linux utilisent systemd si j'ai envie de faire partie du 5% ?

                Tout à fait, mon propos était de souligner que l'idée d'aller tourner le marché Linux loin de systemd était une cause perdue, ensuite ce que les individus font, ou certaines distrib spécialisées font, c'est évidemment purement de leur ressort.

                Notes bien que je dis tout cela en n'ayant personnellement pas de préférence pour ou contre systemd. C'est juste que voila, faut arrèter de réver à un moment… les faits sont là, systemd a pris sur toutes les grosses distribs, il ne disparaitra pas à moins qu'un autre système, nouveau lui-aussi, le remplace dans quelque années.

    • [^] # Re: Ah le désespoir

      Posté par  . Évalué à 1.

      Remet toi 10 ans en arrière (ou pas), remplace Systemd par Windows et on reparle de guerre définitivement gagné …

      Pour rappel tu utilise un OS qui a une part de marché inférieur à 5% selon certains sondages.

      • [^] # Re: Ah le désespoir

        Posté par  . Évalué à 2.

        Ben appelles moi le jour ou une boite énorme se met derrière Gentoo, et on en reparlera.

        Note : aucun sondage réaliste ne donne Windows à 5%. Il y a plus d'un milliard de Windows en circulation, il n'y a certainement pas 20 milliard de smartphones et tablettes en circulation.

  • # Gentoo décidée ?

    Posté par  . Évalué à 10.

    Je dirais que gentoo est dans la catégorie "non décidée". J'ai un laptop en systemd et un serveur en openrc et les deux fonctionnent très bien, c'est au choix. Encore plus que Archlinux je dirais.

  • # Portnawak

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

    Au début des années 90 étaient 386BSD, qui a alors forké en Net/Open/Free BSD d'un côté, et GNU/Linux de l'autre.

    Ouch ! Va dire ça à RMS et Linus et tu vas te prendre un coup de pelle.
    Pour le reste je trouve ton trollo-journal assez médiocre et convenu. Non systemd n'est pas "en train de bouffer l'univers Linux" comme si c'était un prédateur venu de l'extérieur. Ce sont les développeurs de l'écosystème Linux qui ont décidé de créer et de passer à systemd. Ce sont eux, les faiseurs, et pas les commentateurs qui sont les créateurs de l'univers Linux.

    • [^] # Re: Portnawak

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

      Ce sont les développeurs de l'écosystème Linux qui ont décidé de créer et de passer à systemd

      Redhat à créé systemd.

      Des développeurs des autres distributions Linux se sont résignés à ne maintenir de compatibilité qu'avec systemd et non plus avec les autres systèmes d'inits. Simplement parce que ça nécessite beaucoup de travail de prendre en charge plusieurs systèmes d'init.

      Le passage vers systemd chez Debian ne s'est pas fait dans la joie.

      Je n'en dis pas plus, je ne souhaite pas alimenter un éventuel troll.

      Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

      • [^] # Re: Portnawak

        Posté par  . Évalué à 10.

        Simplement parce que ça nécessite beaucoup de travail de prendre en charge plusieurs systèmes d'init.

        En l'occurrence, des développeurs d'autres distributions Linux se sont décidés à passer à systemd simplement parce que ça nécessite moins de travail que de maintenir leur bousin system-v dans leur coin.

      • [^] # Re: Portnawak

        Posté par  . Évalué à 9.

        Des développeurs des autres distributions Linux se sont résignés à ne maintenir de compatibilité qu'avec systemd

        LOL, réécriture de l'histoire much ?!

        Pour Arch par exemple, les développeurs étaient super motivés de passer à systemd, et depuis ils ne s'en portent que mieux.

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

      • [^] # Re: Portnawak

        Posté par  . Évalué à 10.

        Redhat à créé systemd.

        Non.

        Who's behind this?
        Well, the current code-base is mostly my work, Lennart Poettering (Red Hat). However the design in all its details is result of close cooperation between Kay Sievers (Novell) and me. Other people involved are Harald Hoyer (Red Hat), Dhaval Giani (Formerly IBM), and a few others from various companies such as Intel, SUSE and Nokia.

        Is this a Red Hat project?
        No, this is my personal side project.

        Source : FAQ de systemd
        Date : 2010

        • [^] # Re: Portnawak

          Posté par  . Évalué à -6.

          Petite question: c'est qui qui paie le salaire de LP?

          • [^] # Re: Portnawak

            Posté par  . Évalué à 4.

            Et qui paie le tien ?

          • [^] # Re: Portnawak

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

            Quel rapport avec la génèse du projet s'il a démarré sur son temps libre ?

          • [^] # Re: Portnawak

            Posté par  . Évalué à 10. Dernière modification le 26 juillet 2017 à 17:00.

            C'est Red Hat en effet.
            Et Novell pour le co-auteur de systemd.
            Alors dire que Red Hat a créé systemd est faux. Pourquoi ne pas prendre en compte Novell aussi ?

            Déjà je ne sais pas si systemd a été créé au départ sur leurs temps de travail.

            Ensuite je ne sais pas non plus si ce sont des dirigeants de chez Red Hat et Novell qui se sont dit un jour "tiens on va demander à 2 gars de chez nous de bosser sur un nouveau système d'init et bien plus encore".

            Dans des grosses sociétés de ce genre, chez Google par exemple, des employés peuvent travailler quelques heures par semaine/mois sur des projet "perso". J'imagine que chez Red Hat ils doivent avoir la possibilité de faire cela. Par exemple David Airlie (Red Hat) qui bosse sur la pile graphique et pilote AMD depuis très longtemps, a créé il y a quelques années Virgil3D pour la virtualisation. C'est un "pet-project", Red Hat ne lui a jamais demandé de créer cela expressément à ce que je sache. La même chose a du se produire pour systemd.

            LP a créé des logiciels (avahi puis pulseaudio) parce qu'il avait envie de bosser là dessus (pour des raisons qu'il explique parfois sur ses billets de blog). Faut pas y chercher un complot de Red Hat.

  • # Arch non-décidée ?

    Posté par  . Évalué à 10.

    Chez Arch, Systemd est par défaut depuis Octobre 2012.

    Donc c'est plutôt bien décidé…

    Et pour avoir essayé d'utiliser OpenRC il y a de ça quelques mois, ça reste assez casse-gueule avec toutes les dépendances… La maintenance était tellement pénible que j'ai préféré retourner sous Systemd parce que ça "juste marche".

    La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.

    • [^] # Re: Arch non-décidée ?

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

      Oui, Arch a été une des première distributions à basculer sur systemd et à déprécier officiellement son propre système d'init.

      De plus, certains mainteneurs de la distribution ont intégré l'équipe de développement de systemd.

      Essayez de vous plaindre sur la mailing-list que votre système ne fonctionne pas bien parce vous refusez d'utiliser systemd et vous vous ferez jeter comme un malpropre, à juste titre.

      • [^] # Re: Arch non-décidée ?

        Posté par  . Évalué à 2.

        Essayez de vous plaindre sur la mailing-list que votre système ne fonctionne pas bien parce vous refusez d'utiliser systemd et vous vous ferez jeter comme un malpropre, à juste titre.

        Sur #archlinux-fr tu peux parler de ton problème d'openrc sans aucun soucis.. On continue de faire de l'informatique, les utilisateurs ont encore la liberté de faire leur choix techniques et être soutenus, à juste titre.

  • # Clarifications requises

    Posté par  . Évalué à 10.

    Au début des années 90 étaient 386BSD, qui a alors forké en Net/Open/Free BSD d'un côté, et GNU/Linux de l'autre.

    GNU/Linux, un fork de BSD386 ? Si tu as des informations pour étayer je suis preneur, puisque je ne trouve pas grand chose là-dessus, mis à part Linus qui dit (en 1992) qu'il n'aurait pas commencé Linux si BSD386 avait été prêt plus tôt (ce qui me fait penser à Git vs Mercurial, mais c'est un autre sujet).

    …ZFS y est supporté nativement, ce qui n'est pas le cas de Linux.

    La phrase a un air de reproche, hors si ZFS n'a pas son module noyau intégré à toute les bonnes distros aujourd'hui c'est parce que la licence utilisée par ZFS (CDDL) est incompatible avec la GPL (merci Sun !). Donc côté Linux on n'y peut rien. Cela dit, si l'inclusion en binaire est proscrite, la compilation depuis les sources reste possible.

    En réalité, le fork a déjà eu lieu lors de l'inclusion d'udev dans systemd : gentoo a déjà forké udev et travaille sur un système de démarrage moderne restant dans la philosophie traditionnelle : openRC.

    Là aussi la tournure est trompeuse : quand je lis ça, j'ai l'impression que OpenRC serait un fork de Systemd, mais en fait non.

    Sortie d'OpenRC : 5 avril 20071
    Sortie de Systemd : 30 mars 20102

    Pour rappel : "Un fork, en français fourche ou encore embranchement, est un nouveau logiciel créé à partir du code source d'un logiciel existant."3

    Devuan (fork de debian sans systemd dont on pourrait bien entendre parler dans les prochains mois)

    On en a entendu parler il y a plus ou moins longtemps.
    Pour quelle raison on entendrait parler davantage bientôt ?

    Voilà, je suis prêt à parier que dans les mois qui vont venir, certains seront tentés de migrer de distribution, si ce n'est déjà fait.

    Et dans les mois qui vont venir il se passe quoi ? Systemd, c'était le sujet chaud fut un temps, mais maintenant plus trop.

    • [^] # Re: Clarifications requises

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

      GNU/Linux, un fork de BSD386 ?

      Non, pas du tout, la phrase peut porter à confusion, c'est bien (386BSD->Net/Open/FreeBSD) d'un côté, et Linux de l'autre, les 2 projets n'ont vraiment rien à voir l'un avec l'autre. Tu dois probablement déjà connaître la cathédrale et le bazar, je n'ai malheureusement rien de mieux à te conseiller pour l'histoire de Linux.

      (ZFS) La phrase a un air de reproche

      Pas du tout, ou alors caché. Le sujet est systemd, pas le problème de la licence ZFS dont j'étais bien au courant.

      Pour quelle raison on entendrait parler davantage bientôt ?

      La version 1.0 est maintenant sortie (certes basée sur Jessie ou moment où Stretch sort), le site n'a plus l'air d'une vieillerie. Le projet me donne l'impression d'être de plus en plus actif.

      Quand à systemd, il ne semble pas digéré par tout le monde. En tout cas, tant mieux si tu ne trouves pas le sujet chaud (pas mon cas, mais j'évite justement de suivre l'actualité de trop près) ; c'est que les gens vraiment fâchés auront migré de distrib.

      • [^] # Re: Clarifications requises

        Posté par  . Évalué à 0.

        En tout cas, tant mieux si tu ne trouves pas le sujet chaud (pas mon cas, mais j'évite justement de suivre l'actualité de trop près) ; c'est que les gens vraiment fâchés auront migré de distrib.

        Le sujet est clairement clos.
        Ce qu'il reste aujourd'hui, c'est des fanboys systemd qui tapent sur Devuan quand on leur annonce que, finalement, si, c'est possible de faire une grosse distrib sans systemd.
        Bon, il faut reconnaître que ce serait pas mal si ils (devuan) pensaient à sortir de sysVinit quand même.
        Les anti-systemd connaissent les distrib alternatives (Devuan pour le truc périodique, voidlinux pour la rolling release… et d'autres, y compris certaines dont je ne connais pas le nom) et soit les utilisent, soit restent sur leur distrib pro-systemd en changeant l'init.
        Dans le cas de Debian, c'est relativement aisé, et perso je n'ai aucun des "problèmes de dépendance" suggéré par le… "journal".

    • [^] # Re: Clarifications requises

      Posté par  . Évalué à 6.

      Sortie de Systemd : 30 mars 20102

      On en a entendu parler il y a plus ou moins longtemps.
      Pour quelle raison on entendrait parler davantage bientôt ?

      dans les mois qui vont venir il se passe quoi ? Systemd, c'était le sujet chaud fut un temps, mais maintenant plus trop.

      Il ne l'a pas précisé, mais ce journal a été posté il y a un an via IPoT

  • # Pas le problème mais la raison !

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

    Techniquement, on ne va pas nier qu'il y a des apports. Est-ce le problème ?

    Encore la semaine dernière … un serveur dédié qui ne redémarre pas après une mise à jour. Évidement sur un serveur pas sous systemd … Franchement j'ai bien regretté systemd/journald.

    On peut toujours discuter du sexe des anges mais les avancées de systemd sont suffisamment important pour justifier son inclusion dans les distributions majeurs.

    Tous tes arguments … ce n'est que la rhétorique.

    • [^] # Re: Pas le problème mais la raison !

      Posté par  . Évalué à 3.

      Encore la semaine dernière … un serveur dédié qui ne redémarre pas après une mise à jour. Évidement sur un serveur pas sous systemd … Franchement j'ai bien regretté systemd/journald.

      En quoi systemd t'aurais permis de faire ce que tu n'a pas pu faire avec l'init classique ? Pas de troll, j'utilise et apprécie systemd, c'est donc une vraie question. À quel niveau ça a planté dans le boot?

      • [^] # Re: Pas le problème mais la raison !

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

        En quoi systemd t'aurais permis de faire ce que tu n'a pas pu faire avec l'init classique ?

        La différence c'est qu'avec systemd/journald tu as les logs de tout, chronologique et facilement accessible. Là je n'avais strictement aucun log.

        Le problème que j'avais ? Je n'en suis pas bien sûr (pas de log et pas d'accès à l'écran). Ca semble être liée à des règles de firewall qui ne s'appliqueraient pas.

        • [^] # Re: Pas le problème mais la raison !

          Posté par  . Évalué à -2.

          Si je comprend bien, tu t'es formé à systemd, et pas au mécanisme de journalisation de la distrib en question, et tu râles de ne pas avoir les compétences?
          Ah… oups, ça ressemble fort à un des argument que les pro-systemd utilisaient tant: t'es juste dans tes habitudes, faut penser a se former au reste.

          M'enfin, pour le coup de dire que le trollnal n'a que des arguments de réthoriques, je suis bien d'accord, je n'ai rien vu de pragmatique et même pas un des réels arguments contre systemd. Mon avis: l'auteur se fait chier au taf parce qu'il a rien à faire en cette période de vacance, donc il lance un troll pour s'occuper ;)

          • [^] # Re: Pas le problème mais la raison !

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

            Non, il y a un vrai apport avec systemd/journald, les logs sont capturés bien plus tôt qu'avec syslog dans la séquence de boot, et sont donc accessibles même après un reboot, là où traditionnellement si tu n'avais pas d'écran/console/… branché (pas gagné sur un serveur distant pas trop cher) ils auraient été perdus. Ce n'est pas qu'une question d'habitude des outils.

            • [^] # Re: Pas le problème mais la raison !

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

              Et comment on fait quand on relance un service (avec systemctl restart nginx, par exemple), pour avoir le retour d'erreur directement dans la console comme avant dans system-v?
              Actuellement, avec systemd, je suis obligé d'avoir une autre console ouverte pour afficher les logs. Ou bien je peux utiliser journalctl et chercher le message d'erreur (et qui ne s'affichera pas au complet).

              Je n'ai rien trouvé à ce sujet dans le man de sytemctl.

              Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

              • [^] # Re: Pas le problème mais la raison !

                Posté par  . Évalué à 6.

                Ou bien je peux utiliser journalctl et chercher le message d'erreur (et qui ne s'affichera pas au complet).

                journalctl -n 10 --no-pager -p 2
                

                Et tu peux ajouter un -u pour limiter à ta unit.

                « 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: Pas le problème mais la raison !

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

                Je ne sais pas, pour moi le principe d'afficher les erreurs via la commande journalctl que t'indique systemctl lors d'une erreur au démarrage d'un service n'est pas suffisamment laborieux pour que je cherche autre chose. Et désolé mais "pour avoir le retour d'erreur directement dans la console comme avant dans system-v" je vois pas en quoi c'était garanti. Suivant comment le script d'init était fait on pouvait très bien se fader une erreur dans les logs de l'appli et pas dans le retour du script, donc obligé là aussi d'aller lire un fichier de log.

                • [^] # Re: Pas le problème mais la raison !

                  Posté par  . Évalué à 6.

                  uivant comment le script d'init était fait on pouvait très bien se fader une erreur dans les logs de l'appli et pas dans le retour du script, donc obligé là aussi d'aller lire un fichier de log.

                  Je suis d'accord, mais justement les bons scripts d'init affichaient directement une belle erreur. Alors qu'avec systemd, même avec une unit bien écrite, on n'a rien.

                  « 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: Pas le problème mais la raison !

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

                    Je suis d'accord, mais justement les bons scripts d'init affichaient directement une belle erreur. Alors qu'avec systemd, même avec une unit bien écrite, on n'a rien.

                    Personnellement ça ne me gène pas parce que le "status" donne explicitement les erreurs en cas d'erreur de démarrage. Ca reste rapide pour trouver les messages d'erreurs. Par contre, il faut effectivement 2 commandes.
                    Il manque peut être une option pour afficher les erreurs au démarrage/arrêt.

                  • [^] # Re: Pas le problème mais la raison !

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

                    Je ne vois pas ce que tu veux dire. J'ai arrêté httpd et fait un nc -l 80 dans un screen :

                    $ systemctl start httpd
                    Job for httpd.service failed because the control process exited with error code. See "systemctl status httpd.service" and "journalctl -xe" for details.
                    
                    $ systemctl status httpd
                    ● httpd.service - The Apache HTTP Server
                       Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
                       Active: failed (Result: exit-code) since mer. 2017-07-26 17:23:22 CEST; 13s ago
                         Docs: man:httpd.service(8)
                      Process: 30227 ExecReload=/usr/sbin/httpd $OPTIONS -k graceful (code=exited, status=0/SUCCESS)
                      Process: 11030 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=exited, status=1/FAILURE)
                     Main PID: 11030 (code=exited, status=1/FAILURE)
                    
                    juil. 26 17:23:22 myserver systemd[1]: Starting The Apache HTTP Server...
                    juil. 26 17:23:22 myserver httpd[11030]: [Wed Jul 26 17:23:22.565935 2017] [so:warn] [pid 11030] AH01574: module proxy_wstunnel_module is already loaded, skipping
                    juil. 26 17:23:22 myserver httpd[11030]: (98)Address already in use: AH00072: make_sock: could not bind to address [::]:80
                    juil. 26 17:23:22 myserver httpd[11030]: (98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80
                    juil. 26 17:23:22 myserver httpd[11030]: no listening sockets available, shutting down
                    juil. 26 17:23:22 myserver httpd[11030]: AH00015: Unable to open logs
                    juil. 26 17:23:22 myserver systemd[1]: httpd.service: Main process exited, code=exited, status=1/FAILURE
                    juil. 26 17:23:22 myserver systemd[1]: Failed to start The Apache HTTP Server.
                    juil. 26 17:23:22 myserver systemd[1]: httpd.service: Unit entered failed state.
                    juil. 26 17:23:22 myserver systemd[1]: httpd.service: Failed with result 'exit-code'.
                    
                    

                    Alors oui deux commandes pour avoir l'erreur, mais au moins je sais que je vais l'avoir de manière standard. Et surtout je n'ai pas rien

            • [^] # Re: Pas le problème mais la raison !

              Posté par  . Évalué à 2.

              Non, il y a un vrai apport avec systemd/journald, les logs sont capturés bien plus tôt qu'avec syslog dans la séquence de boot,

              Tu veux dire les logs du kernel, ou des services?
              Concrètement, qu'est-ce qui empêche les services d'avoir leur stdout/err redirigés par le script d'init (que ce soit sysV ou un autre, on s'en cogne) dans un fichier propre?

              • [^] # Re: Pas le problème mais la raison !

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

                Concrètement, qu'est-ce qui empêche les services d'avoir leur stdout/err redirigés par le script d'init (que ce soit sysV ou un autre, on s'en cogne) dans un fichier propre?

                Rien. Sauf qu'a priori ce n'est pas fait (puisque je n'ai pas de log).

                Il n'y a pas de mécanisme prévu pour que pour je modifie le script d'init tout en conservant les mises à jour (ben oui si tu modifie un fichier dans /etc sous debian/ubuntu il n'est plus mis à jour). Donc j'évite (surtout avec mes faibles compétences en ma possession).

                • [^] # Re: Pas le problème mais la raison !

                  Posté par  . Évalué à -1.

                  Donc j'évite (surtout avec mes faibles compétences en ma possession).

                  Voila. Donc c'est bien ce que je disais, l'argument que j'ai souvent lu en provenance d'un pro-systemd vers les autres se retourne bien ici.
                  Et tu le prouves ici:

                  ben oui si tu modifie un fichier dans /etc sous debian/ubuntu il n'est plus mis à jour

                  Faux pour pas mal d'entre eux. A minima, les conf de vim et de bash, probablement d'autres, je n'ai pas une mémoire d'éléphant.
                  Le logiciel te demande ce que tu veux faire, typiquement: prendre la version du mainteneur, regarder le diff ou garder ta version. En tout cas, sous Debian. Conclusion, il est très possible de générer un diff avant (voire pendant) la MàJ et de porter le diff après la MàJ en ayant accepté au préalable la version du mainteneur.

                  • [^] # Re: Pas le problème mais la raison !

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

                    Voila. Donc c'est bien ce que je disais, l'argument que j'ai souvent lu en provenance d'un pro-systemd vers les autres se retourne bien ici.

                    Tu fais référence à quel argument ?

                    Le logiciel te demande ce que tu veux faire, typiquement: prendre la version du mainteneur, regarder le diff ou garder ta version.
                    En tout cas, sous Debian.
                    Conclusion, il est très possible de générer un diff avant (voire pendant) la MàJ et de porter le diff après la MàJ en ayant accepté au préalable la version du mainteneur.

                    Effectivement, mais je ne fais jamais les mises à jour à la main mais j'utilise des outils comme "unattended-upgrades".

                    • [^] # Re: Pas le problème mais la raison !

                      Posté par  . Évalué à 0.

                      Tu fais référence à quel argument ?

                      Le coup du "c'est juste que vous ne voulez pas apprendre".

                      Effectivement, mais je ne fais jamais les mises à jour à la main mais j'utilise des outils comme "unattended-upgrades".

                      D'ac. Du coup, ça se passe comment si dpkg pose une question à l'utilisateur? Je n'ai jamais utilisé ce type d'outils, j'ai toujours repoussé ça à plus tard, un peu comme le backup de mes données -.-'

                      • [^] # Re: Pas le problème mais la raison !

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

                        Tu fais référence à quel argument ?
                        Le coup du "c'est juste que vous ne voulez pas apprendre".

                        C'est marrant comme remarque :) Ma phrase faisait référence à la phrase que tu as écrite :

                        Si je comprend bien, tu t'es formé à systemd, et pas au mécanisme de journalisation de la distrib en question, et tu râles de ne pas avoir les compétences?

                        Donc tu me reproches à moi de faire référence à tes propres arguments ?

                        Très marrant.

                        D'ac. Du coup, ça se passe comment si dpkg pose une question à l'utilisateur?

                        dpkg prends la valeur par défaut au question posée si je me souviens bien.

                        • [^] # Re: Pas le problème mais la raison !

                          Posté par  . Évalué à -1.

                          Donc tu me reproches à moi de faire référence à tes propres arguments ?

                          Ce n'était pas un reproche, en soi. En fait, j'avoue m'être laissé séduire par la possibilité de retourner cet argument pénible si souvent utilisé par les pro-systemd contre l'un d'entre eux, qui n'y est d'ailleurs probablement pour rien ;)

                          dpkg prends la valeur par défaut au question posée si je me souviens bien.

                          Merci.

              • [^] # Re: Pas le problème mais la raison !

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

                Vu que je parle explicitement de logs capturés très tôt dans la séquence de boot, il me semblait assez clair que je ne parle pas d'un petit problème du genre httpd qui ne démarre pas, mais bien de problèmes plus grave donc plutôt kernel en effet. Je me souviens qu'il y avait eu des articles sur le fait que systemd de par sa conception permettait une capture des logs à un moment où ça aurait été simplement impossible pour SysV/syslog.

                Enfin bon, comme d'habitude avec les anti-systemd primaires, "qu'est-ce qui empêchait qu'on le fasse alors qu'on l'a pas fait pendant 15 ans ? hein ?". Bah, j'en sais rien, c'était à vous de le dire ou de le faire avant, justement…

                • [^] # Re: Pas le problème mais la raison !

                  Posté par  . Évalué à -1.

                  Anti-systemd primaire? Si ça t'amuse de le croire…
                  Concrètement, les trucs que je reproche à systemd c'est bien de ne pas avoir de limites fonctionnelles définies, ce qui me paraît dangereux pour un projet, et de ne pas être portable, ce qui est un choix totalement défendable. Juste, moi, je préfère utiliser du code portable, au cas ou un jour je décide que finalement linux ne me conviens pas.
                  Si jamais tu as un de mes messages dans lequel je dis un truc du style que je préférerai que systemd n'ai jamais existé, ou qu'il devrait mourir, je veux bien un lien.
                  Des anti primaires, il y en a, certains ont même utilisé l'argument qu'ils n'aiment l'auteur comme argument contre. Si je l'ai fait, prouves-le.
                  J'ai aussi vu des arguments techniques stupides genre que sysVinit est parfait et moderne. Perso, quand j'ai appris la naissance de systemd et l'idée générale, j'étais enthousiaste. Parce que j'avais déjà essayé de lire le tas de spaghettis qu'étais le système d'init de Debian.

                  Ma question était honnête, y compris celle sur le kernel.
                  Maintenant, je vois assez mal comment un système d'init, de manière générale, pourrait accéder aux logs du kernel alors que les autres ne le pourraient pas.
                  Clairement, systemd peut utiliser l'API spécifique du kernel, c'est très possible. Mais il me semble que le kernel expose énormément de choses via un système de pseudo-fichiers, accessible donc par n'importe quel soft POSIX, et j'imagine que les logs en font partie.

                  Si j'ai bien compris, tu soupçonnes le pare-feu de faire planter le kernel? Mouai. Et t'as pas les logs? Re-mouai. Je sais pas ce que tu utilises pour configurer ton pare-feu, mais je doute fort que la sortie d'erreur ne soit pas redirigeable vers un fichier.
                  Et dans ce cas, le coupable du manque de logs, c'est pas l'init hein, non non, c'est l'admin qui n'a pas fait son job. Job peut-être plus simple avec systemd, pourquoi pas, mais vu que tu ne nous donne pas de détails sur les logs qu'il te manque, on ne peux même pas le prouver.
                  En fait, comme tu te contente de supposer, il n'y a même aucune preuve que systemd aurait fait le taf. Au lieu de ça, tu m'attaques personnellement. La classe.

                  • [^] # Re: Pas le problème mais la raison !

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

                    Si j'ai bien compris, tu soupçonnes le pare-feu de faire planter le kernel? Mouai. Et t'as pas les logs? Re-mouai. Je sais pas ce que tu utilises pour configurer ton pare-feu, mais je doute fort que la sortie d'erreur ne soit pas redirigeable vers un fichier.

                    Moi je n'ai jamais parlé de Kernel. Ma préoccupation était de remettre en place le plus rapidement le serveur. Donc … ben j'ai regardé les fichiers de log modifiés depuis le dernier reboot. Et ben …, rien d'intéressant. Non je n'avais pas envie de modifier des scripts d'init pour avoir plus de log.

                    J'ai désactivé le service du firewall (au hasard) et j'ai redémarré. J'ai eu accès au serveur. Je n'en sais pas plus malheureusement (est-ce que le firewall étant en cause ? aucune idée).

                    Avec systemd/journald j'aurais au moins pu savoir quels services étaient démarrés ou non au dernier reboot ainsi que les logs et les status. C'est tout ce que j'ai dit.

                    Après mon propos était de dire que, pour moi, les apports techniques sont bien évidement a prendre en compte, parce que, pour moi, systemd me simplifie la vie. Pour ne citer que ce qui me passe par la tête : journalctl, systemctl is-system-running, systemclt status xxx, systemctl --state=failed, systemctl edit xxxx, systemctl set-environment xxxx n'ont pas d'équivalent aussi puissant et simple.

                    La perte de diversité supposée, la personnalité de Lennart, le changement de philosophie, et le reste du blah blah ne me préoccupe pas le moins du monde.

                    • [^] # Re: Pas le problème mais la raison !

                      Posté par  . Évalué à 4. Dernière modification le 27 juillet 2017 à 10:36.

                      Après mon propos était de dire que, pour moi, les apports techniques sont bien évidement a prendre en compte,

                      Et sur ce point je suis d'accord. Chacun utilise bien ce qu'il veut.

                      journalctl, systemctl is-system-running, systemclt status xxx, systemctl --state=failed, systemctl edit xxxx, systemctl set-environment xxxx n'ont pas d'équivalent aussi puissant et simple.

                      Possible. Mais j'ai bien l'impression que systemctl status xxx à une variante pour les sysVinit. Pas sous Debian la (à mon grand regret) mais ça ressemble à services status xxx?
                      Pour systemctl --state=failed effectivement, en général je me fade une commande à rallonge, combo de grep et de redirection de stderr vers /dev/null.

                      Le reste, je ne sais pas, et/ou ne vois pas nécessairement l'utilité (différents usages, différents besoins).

                      La perte de diversité supposée

                      Ca, c'est une connerie: le fait de proposer un autre modèle augmente la diversité. Si d'autres projets meurent parce que plus utilisés et remplacés par systemd, c'est juste qu'ils ne sont pas assez efficaces.
                      SysVinit ne me manquera pas, et grâce à systemd j'ai découvert runit, qui à son tour m'a fait découvrir voidlinux.
                      Perso, j'y ai gagné, dans cette affaire. Je n'ai pas l'intention d'utiliser systemd, j'ai mes raisons, mais je sais que sans systemd je n'aurai pas fait ces recherches et je n'aurai pas appris tout ce que j'ai pu apprendre sur l'init.

                      • [^] # Re: Pas le problème mais la raison !

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

                        Le reste, je ne sais pas, et/ou ne vois pas nécessairement l'utilité (différents usages, différents besoins).

                        systemctl is-system-running : te dis si le système est complètement démarré et sans erreur (c'est quand le minimum qu'on puisse demander)
                        systemclt status xxx == service xxx status
                        systemctl edit xxxx : te permet de personnaliser un script d'init
                        systemctl set-environment xxx : te permet de setter de variable d'environnement

                        Je pourrais rajouter à la liste :

                        systemd-cgls pour voir le contenu des cgroups
                        systemd-cgtop pour l'usage des ressources des cgroups à la top
                        systemd-analyze plot > plot.svg : pour avoir les graphs de démarrage en svg

                        Et plein de détail dont je ne pense pas là tout de suite.

                  • [^] # Re: Pas le problème mais la raison !

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

                    Écoute, tu demandes en quoi systemd/journald changent quelque chose, notamment pour diagnostiquer un problème de démarrage, j'explique une première fois en quoi (il capture les logs beaucoup plus tôt dont certains qui étaient auparavant volatiles).

                    Tu me réponds "tu parles de logs de services ? avec 45 lignes de bash on aurait pu faire pareil", je ré-explique que je parle de capture de logs très tôt au démarrage de la machine, au passage je demande pourquoi ça n'était pas fait avec SysV/syslog si c'était si simple. Et oui, je fais remarquer que selon moi ça sent le mec qui veut absolument trouver un truc à redire sur systemd.

                    Maintenant il faut que j'explique je sais pas quoi ? Non, désolé, j'arrête là.

                    • [^] # Re: Pas le problème mais la raison !

                      Posté par  . Évalué à 0.

                      il capture les logs beaucoup plus tôt dont certains qui étaient auparavant volatiles

                      Tu me réponds "tu parles de logs de services ?

                      Bah en gros j'essaie de comprendre comment il fait, et donc pourquoi ce serait infaisable par les autres. Tout bêtement. A partir de la, je pourrai ensuite vérifier que les autres ne le font effectivement pas.

                      Par exemple, si je te demande s'il fait en gros le même travail que klogd ( The klogd program will extract messages from the kernel log buffer ) mais dès le début, je me trompe ou pas? Ou est-ce qu'il utilise un truc plus bas niveau, ce qui serai impossible à d'autres qui refuseraient le code spécifique à un OS?

                  • [^] # Re: Pas le problème mais la raison !

                    Posté par  . Évalué à 2.

                    Clairement, systemd peut utiliser l'API spécifique du kernel, c'est très possible.

                    C'est exactement pourquoi systemd log bien plus que les autres systèmes d'init.
                    Il n'a pas peur d'utiliser des API spécifiques à Linux.

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

                    • [^] # Re: Pas le problème mais la raison !

                      Posté par  . Évalué à 2.

                      Ce qui est à la fois une bonne et une mauvaise chose. C'est une bonne chose parce que ça permets une meilleure intégration, et pour la majorité qui se contrefiche (avec raison) de la portabilité c'est juste positif.

  • # Slackware ?

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

    Slackware (on voit mal Patrick Volkerding changer le système d'init particulier de la distribution)

    En quoi le système d’init de la Slackware est « particulier » ?

    Slackware n’a pas un init qui lui est propre, elle utilise le sysvinit de Miquel van Smoorenburg dont l’historique remonte à 1992 (un an avant la naissance de la Slack). Rien de spécifique à Slackware, Debian et RedHat par exemple utilisaient aussi cet init.

    Et moi ce que je vois mal, c’est Patrick Volkerding se farcir la maintenance d’une alternative à Systemd. Le jour où intégrer Systemd représentera moins de travail que de continuer à faire en sorte que tout fonctionne sans Systemd, m’est avis que la décision sera vite prise (comme ça a été le cas pour PulseAudio, quand Pat s’est rendu compte que les dernières versions de Bluez — la pile Bluetooth pour Linux — dépendaient de PulseAudio).

    Voilà, je suis prêt à parier que dans les mois qui vont venir, certains seront tentés de migrer de distribution, si ce n'est déjà fait.

    Bof, pas si sûr.

    Tiens, puisqu’on parle de Slackware, quelqu’un a prophétisé un « exode massif » des Slackeux vers les BSD si jamais un jour Slackware passe à Systemd. J’avoue n’avoir pas lu les 113 pages (!) de la discussion, mais rien qu’à voir quelques réactions sur la première page, cette prophétie a l’air assez bancale :

    several Slackware users have declared, in this forum, that if Patrick decides to adopt systemd, they will trust his judgement and continue using Slackware.
    […]
    I really don't see the sense in advising Slackware users to just switch to *BSD.
    […]
    I trust Patrick Volkerding to make sound decisions, and if this means shipping systemd in the future, well, so be it.
    […]
    Should Slackware ship systemd as a whole, that won't be in the upcoming release, so I'm not in a hurry, and anyway I'd (fairly, IMO) give it a go if/when that happens before making a decision to move or not.
    […]
    Init is not a make or break issue for me, nor do I really believe that it is for the majority of users. I can't see why we should sacrifice everything great about Slackware just to avoid systemd.
    […]
    Who here selected Slackware purely because of its init? I'm not saying it wasn't a factor for some people but I doubt it was in the primary selection criteria for most.
    […]
    Well, I'm pretty anti-systemd and can't stand its creator, but I don't think I'll be dumping Slackware if and/or when it's adopted.

    Et je m’ajoute volontiers à cette liste : si j’apprécie Slackware, c’est pour la distribution dans son ensemble, pas parce qu’elle est systemd-free.

    Ah , et pour donner des sueurs froides à certains : Systemd dans Slackware, ça existe déjà. :D

  • # S'il te plaît Lennaert, remplace GRUB

    Posté par  . Évalué à 7.

    Si il y a bien une pièce du système d'initialisation de GNU/Linux qui me gave, c'est l'amorceur GRUB.

  • # Lancé médiocre

    Posté par  . Évalué à 10.

    Allons-y dans l'ordre:

    1.Les journaux trolls vides de nouveaux arguments au débat, par tradition, c'est le vendredi
    2.Le troll systemd contre les autres init, il commence à passer de mode
    3.Le troll "systemd est monolitique" n'impressionne plus personne depuis que Trump twitte n'importe quoi tous les jours, mais en plus en réussissant l'exploit de se renouveler constamment, lui!

    Sérieusement, vous ne voulez pas prendre un peu de risques et faire original, genre je ne sais pas moi, "Wayland va casser la pile graphique", ou "BTRFS c'est de la merde parce que c'est pas optimal sur ma clé USB"?

  • # Commentaire supprimé

    Posté par  . Évalué à 10.

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

  • # lag

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

    On dirait que ce journal a été écrit il y'a 5 ou 6 ans.

    Jami: beabb2b063da0a2f0a2acaddcd9cc1421245d5de

    • [^] # Re: lag

      Posté par  . Évalué à 10.

      On dirait que ce journal a été écrit il y'a 5 ou 6 ans.

      Quelque chose me dit qu'il utilise Debian.

      • [^] # Re: lag

        Posté par  . Évalué à 7.

        Perso, a voir les connaissances sur l'histo des distro dont il fait étalage, je dirais qu'il utilise Windows.

  • # Scripts inits : ça marche toujours sous Debian

    Posté par  . Évalué à 2.

    Tout n'est pas noir au sujet de la migration systemd. systemd-sysv-generator aide pas mal pour la migration des scripts /etc/init.d ; les scripts fonctionnent par défaut. Ce qui n'est pas le cas sous Arch, versions 2017. Et avec la commande "service" et les logs syslog activés par défaut à l'ancienne, la migration s'est vraiment faite sans accroc sous Debian.
    Autant, je ne vois pas le bénéfice de ma petite lorgnette, autant, c'est clairement pas pire qu'avant.

  • # Bof...

    Posté par  . Évalué à -1.

    System V, systemd ou openRC ? M'en fiche, je n'utilise aucun de ces programmes (du moins pas de façon consciente).

  • # OpenRC

    Posté par  . Évalué à 2.

    Quelle aurait été ma joie si j'avais pu avoir un peu plus d'infos sur OpenRC en lisant ce journal !
    Mais non, je n'ai vu qu'une amorce de troll, suivi de trolls en pagaille.
    Tant pis, j'irai m'informer ailleurs…
    Sinon, OpenRC, ça a quoi de particulier ?

    • [^] # Re: OpenRC

      Posté par  . Évalué à -2. Dernière modification le 27 juillet 2017 à 09:55.

      system d'init moderne pour Unix contrairement a systemd qui est, a la base, un systeme d'init moderne pour linux only et qui maintenant fait aussi le cafe, creuse des trous et, pour certains, d'objet de jouissance.

    • [^] # Re: OpenRC

      Posté par  . Évalué à 3.

      Sinon, OpenRC, ça a quoi de particulier ?

      De ce que j'ai retiré de mes diverses lectures, ça semble offrir nativement le support du parallélisme et la gestion des dépendances.
      Ces points sont 2 des points d'accroche initiaux de systemd selon moi, avec en bonus non négligeable la facilité de configuration (aka: possibilité d'éviter les scripts mais plutôt d'utiliser des fichiers de config plus traditionnels).

      Je ne sais pas s'il y a d'autres points intéressants dans OpenRC.

      Perso, j'ai plus été séduit par runit qu'OpenRC, la configuration est nettement plus triviale. En revanche, pas de gestion des dépendances, il faut le faire manuellement: soit un programme sait qui dépend de lui et créées leurs liens symbolique (ce qui serait une grosse galère à maintenir) soit un programme sait de quels services il dépend et attend gentiment que ceux-ci soient démarrés, par exemple en scrutant la création d'un fichier PID (a priori, simple à faire et à maintenir).

    • [^] # Re: OpenRC

      Posté par  . Évalué à 2.

      Un début de réponse sur DLFP et un peu plus d'infos sue le wiki de Gentoo

      cd /pub && more beer

  • # T'es courageux...

    Posté par  . Évalué à -6.

    Tu es courageux de faire une telle déclaration sur LinuxFR, là où le moindre commentaire pouvant être perçu comme défiant systemd est qualifié de rageux.

    Là où tous les commentateurs ponctuaient leurs phrases de liberté, vie privée, interopérabilité, NSA, … il n'y a personne pour s'insurger que systemd envoie tes requêtes DNS chez google, ou qu'il se foute de POSIX.
    Je ne parle pas de la fâcheuse tendance qu'il a de reparser les usernames ou les noms DNS et de faire n'importe quoi au cas où nous aurions eu l'idée d'utiliser un username que systemd. n'estime pas valide.

    Donc oui, je pense que tu as tout à fait raison quand tu parles d'un changement de philosophie. Systemd impose sa loi. Là encore la plupart des gens ici étaient heureux de la diversité, et sont finalement ravis de l'uniformité qu'impose systemd. Va comprendre.

    • [^] # Re: T'es courageux...

      Posté par  . Évalué à 1.

      systemd envoie tes requêtes DNS chez google

      Wut ?

      Là encore la plupart des gens ici étaient heureux de la diversité, et sont finalement ravis de l'uniformité qu'impose systemd.

      Avant, tout le monde utilisait SystemV ou autre chose.
      Maintenant, tout le monde utilise systemd ou autre chose, y compris parfois SystemV.

      LOL, la "perte" de la diversité…

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

      • [^] # Re: T'es courageux...

        Posté par  (site web personnel) . Évalué à 10. Dernière modification le 28 juillet 2017 à 13:38.

        Wut ?

        Il parle du fait que, par défaut et de manière configurable à la compilation, et si c'est pas non plus surchargé dans la configuration, si tu te retrouves avec du réseau mais, dieu sait pourquoi, sans DNS configuré, alors quand tout ça est réuni, systemd se rabat sur 8.8.8.8 pour assurer un fonctionnement normal.

        Ce qui bien évidemment via la magie de Twitter et des trolls anti-systemd, est devenu Lennart envoie toutes vos requêtes à Google.

Suivre le flux des commentaires

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