Journal systemd ca a l'air super...

Posté par  . Licence CC By‑SA.
-13
21
fév.
2014

Un journal bookmark sur le nouvelle version de systemd

Quand je vois ce genre de chose ca me fait un peu peur tout de meme systemd…
Je n'y connais rien en init donc je ne troll pas sur le sujet mais c'est juste que des que j'ai un peu toujours la meme impression avec la facon de faire de Lennart Poettering et qu'il adore utiliser les dernieres nouveautes meme si elles sont instables ou n'existe que sur un systeme (linux) ou une plateforme (x86-64) et on pourrait presque dire une distribution (voir le merdier que cela a ete pour inclure un pulseaudio dans les distribs non-redhat like, il a fallu plusieurs annees avant que cela se stabilise un peu!)

En resume la il semblerait que:

1 - changement enorme donc a ne pas utiliser en prod surtout pas en LTS.
2 - systemd le truc qui va bientot etre le seul system d'init sous linux parait il car il est super genial, en fait ca peut pas fonctionner actuellement sur les ARM car cela utilise une fonctionnalite de GCC a priori legerement experimentale et/ou non presente sur toutes les architectures. Ca me laisse tres legerement dubitatif sur ce systeme. Enfin bon de tout de facon on n'a pas le choix, sauf si on utilise un proc ARM (!), on va devoir passer dessus.

There's no Fedora Rawhide packages yet since the systemd Fedora ARM package isn't building due to lack of IFUNC support, so Lennart is just contemplating on disabling systemd Fedora ARM support as the workaround… Meanwhile, GCC developers advise against depending upon IFUNC. GCC developer Jakub Jelinek wrote in the bug report, "requiring ifunc in systemd is way too premature, most architectures don't implement ifunc and that is hardly going to change any time soon. You can surely use it if available, but requiring it? Eh."

  • # On n'est pas vendredi!!

    Posté par  . Évalué à 2.

    Ah si… pardon =>[]

  • # Troll

    Posté par  . Évalué à 10.

    Bon, je vais épargner aux anti-systemd le besoin d'écrire un commentaire eux même.

    Systemd, c'est caca, unix, posix, kiss, syslog, journald, pulseaudio, linux, bsd, cgroups, lennart, nazi.

    J'ai tout couvert ou j'ai oublié des trucs ?

    • [^] # Re: Troll

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

      J'ai tout couvert ou j'ai oublié des trucs ?

      T'as oublié de dire que sysv-init, c'était plus mieux bien.

    • [^] # Re: Troll

      Posté par  . Évalué à 9. Dernière modification le 21 février 2014 à 11:52.

      Tu as oublié logind et udev.

    • [^] # Re: Troll

      Posté par  . Évalué à 8.

      et aucune mention du sexisme ?

      …tout se perd

      L'acacia acajou de l'académie acoustique est acquitté de ses acrobaties. Tout le reste prend "acc".

    • [^] # Re: Troll

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

      et les log au format txt.

      sinon on connaît la chanson:

      systemd, je te trollerai,
      Je te trollerais les logs,
      et les logs, et les log.

      systemd, je te trollerai,
      je te trollerai posix,
      et posix, et posix.

      • [^] # Re: Troll

        Posté par  . Évalué à 6.

        Ça ne vaut pas Jean-Pierre François : Vous me trollerez

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

    • [^] # Re: Troll

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

      J'ai tout couvert ou j'ai oublié des trucs ?

      Et Mir alors ??

      kentoc'h mervel eget bezan saotred

  • # ifunc

    Posté par  . Évalué à 3.

    Yep, tu dénonce grave, mais tu veux nous renseigner un peu plus sur ifunc ?

    • [^] # Re: ifunc

      Posté par  . Évalué à 2.

      Absolument pas le seul truc que je peux dire c'est que systemd l'utilise, que cela n'est pas multiplateforme et que les devs de GCC disent "c'est pas bien malin d'utiliser ce truc actuellement".

    • [^] # Re: ifunc

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

      http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html /ifunc

      De rien. Et je suppose que arm n'est pas la seule victime, même si c'est la plus grosse plateforme impactée.
      (On s'en fout des autres plateformes de toute façon).

      Ça ne doit pas compiler avec clang non plus (mais on s'en fout de clang aussi de toute façon je suppose aussi)

      • [^] # Re: ifunc

        Posté par  . Évalué à 5.

        À vue de nez ça doit être faisable de faire quelque chose d'à peu près similaire avec des pointeurs de fonction et une fonction attribute((constructor)).
        Surtout qu'au final ça fonctionnerait de la même façon et c'est pas beaucoup plus intrusif.

        Du coup je vois pas pourquoi ça pose tellement de problème qu'ils en viennent à totalement se passer de systemd !
        Enfin bon, je suivrais le bug pour voir comment ça se résoud:
        https://bugzilla.redhat.com/show_bug.cgi?id=1067245

  • # systemd-networkd ?

    Posté par  . Évalué à 6.

    Pour ma part, ce qui m'a fait tiquer en premier c'est plutôt ça :

    Systemd 209 has a new systemd-networkd component for configuring and bringing up your network

    Là, ça devient vraiment excessif. Jusque-là, je trouvais plutôt logique qu'il intègre certains trucs, mais à mon avis il ne devrait pas gérer ça, il devrait plutôt s'appuyer sur NetworkManger qui commence enfin à être complet (les bridges) et qui est déjà dbus-aware.

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

    • [^] # Re: systemd-networkd ?

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

      De ce que j'ai compris l'idée est de pouvoir configurer le réseau dans l'initrd. Je ne pense pas que NetworkManager puisse permettre cela. Je ne suis pas sûr que systemd-networkd ait vocation à remplacer NetworkManager.

      • [^] # Re: systemd-networkd ?

        Posté par  . Évalué à 5.

        Après avoir parcouru les release notes, j'ai au contraire le sentiment que ça a vocation à remplacer NetworkManager.

        Par exemple, j'avoue avoir du mal à voir l'intérêt de confier la gestion des bridges et des VLAN à l'initrd.

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

        • [^] # Re: systemd-networkd ?

          Posté par  . Évalué à 2.

          NetworkManager, ça fonctionne ?

          • [^] # Re: systemd-networkd ?

            Posté par  . Évalué à 10.

            Aussi bien que systemd.

          • [^] # Re: systemd-networkd ?

            Posté par  . Évalué à 10.

            Quand quelque chose commence à marchoter, il est grand temps de le remplacer par un autre bidule…

            • [^] # Re: systemd-networkd ?

              Posté par  . Évalué à 2.

              Ben chez moi, je crois bien que Network-manager, il marche pas!
              J'ai 2 machines (une fedora et une xubuntu), tous les 2 des asus un peu vieux pour lequel j'ai exactement le même problème. J'ai beau chercher je trouve pas le problème (bon, je m'y connais pas trop en linux donc ça doit pas aider!).
              Les 2 machines fonctionnent bien en wifi, mais si j’essaie d'utiliser le cable réseau, la connexion ne marche pas.
              Je pense que ça viens d'un problème de config de Network-manager mais je sais pas pourquoi aucune des distrib ne fonctionne par défaut :(

              • [^] # Re: systemd-networkd ?

                Posté par  . Évalué à 2.

                Je pense que ça viens d'un problème de config de Network-manager

                Si tu shootes le NetworkManager et que tu fais un dhclient eth0, ça dit quoi ? Parce que ton problème, normalement, ça marche. Ca n'a peut-être (probablement) rien à voir.

              • [^] # Re: systemd-networkd ?

                Posté par  . Évalué à 0.

                Est ce que ce ne serait pas un problème de MTU ?

        • [^] # Re: systemd-networkd ?

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

          Après avoir parcouru les release notes, j'ai au contraire le sentiment que ça a vocation à remplacer NetworkManager.

          Dans les releases notes, il est écrit ceci :

          Use this for your initrd, container, embedded, or server setup if you need a simple, yet powerful, network configuration solution.

          Il me semble que ce n'est pas la cible de NetworkManager.

          Par exemple, j'avoue avoir du mal à voir l'intérêt de confier la gestion des bridges et des VLAN à l'initrd.

          Je suppose qu'il y a des cas d'usage un peu tordu pour lesquels ça peut avoir un intérêt (genre / sur un réseau complexe).

          • [^] # Re: systemd-networkd ?

            Posté par  . Évalué à 2.

            Le seul cas ou à mon avis ça peut avoir un sens, c'est lorsque tu boot sur le réseau (pas de FS local).

            Sinon, je ne pense pas qu'il y ait un intérêt à monter le réseau dans l'initrd.

            • [^] # Re: systemd-networkd ?

              Posté par  . Évalué à 8.

              Si si, pour monter à distance un système de fichier chiffré par exemple.

              Dropbear permet de faire ça notamment : on charge le réseau minimal et on ouvre un serveur ssh, ce qui permet de taper la phrase de passe du système de fichier à monter avant la suite du démarrage.

              • [^] # Re: systemd-networkd ?

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

                Nan mais commence pas à ruiner tout l'argumentaire avec des vrais features et des use cases qui sont pas tirés par les cheveux, tu te rends compte que Linuxfr vit grace aux contributions, et que systemd a augmenté les contributions sur les commentaires :)

              • [^] # Re: systemd-networkd ?

                Posté par  . Évalué à -1.

                Et pourquoi a-t-on besoin de le mettre dans l'initrd ?

                • [^] # Re: systemd-networkd ?

                  Posté par  . Évalué à 5.

                  Parce que le système de fichier est chiffré.

                  « 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: systemd-networkd ?

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

                    Rajoute "et parce que toute les machines ne sont pas équipés en IMPI ou carte d'admin couteuses, ce qui permet d'adresser le marché des hobbyistes ayant leur serveur sous forme d'un shuttle dans le salon".

                    Et comme je peux pas me fatiguer à répondre à la même question sur le réseau, avoir un rescue sur le systéme qui a le réseau ça permet par exemple de télécharger le fichier de la glibc qu'on a écrasé par erreur depuis le rescue.

                    Bien sur, on arrive à se débrouiller autrement quand on a pas le réseau, mais je peux imaginer que ça peut faciliter la vie.

                    Et ça prends aussi moins de place dans l'initrd, au moins sur Fedora.

                    systemd-networkd fait 343k après passage de strip, bash + /etc/init.d/network + divers scripts dans /etc/sysconfig/network-scripts/ , ça fait 960k + ~100k de scripts.

                    Et si on me dit "mais networkd- tire la libpcre, ça fait 410k de plus", je dirais que les scripts d'init tire gawk, qui fait 570k.

                    Et que le fait de tirer pcre est listé comme bug dans la TODO list de systemd :
                    https://github.com/systemd/systemd/blob/master/TODO#L152

                    • [^] # Re: systemd-networkd ?

                      Posté par  . Évalué à 1. Dernière modification le 22 février 2014 à 10:58.

                      Tu n’oublierais pas les 1020k de systemd (qui en plus tire la libdbus de 290k) dans ton décompte ? :)

                      • [^] # Re: systemd-networkd ?

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

                        Ca fait sourire cette bataille de ko à l'heure où on parle de plusieurs Go de RAM et de DVD de 4 Go (ne parlons pas de Bluray ou de clé USB qui coûtent rien de nos jours) sur une machine de base.

                        Ca me rappelle l'histoire des gars qui ont passé des jours d'ingé hautement payés à optimiser pour être super fiers de gagner 50% de taille mémoire et où le stagiaire a posé la question qui tue "mais pourquoi n'avoir tout simplement pas acheté une barette de RAM?"

                        • [^] # Re: systemd-networkd ?

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

                          Sauf que si tu regardes un peu autour de toi, tu va voir que le monde n'est pas composé uniquement de machines de bureau surdimensionnés.

                          D'une part, quand tu produit des appareils à des millions d'exemplaire, ton histoire de la barrette de ram devient "pourquoi ne pas avoir acheté des millions de barrettes de ram" ce qui reviens d'un coup à "pourquoi ne pas avoir dépenser beaucoup plus de pognon en achat, en logistique et en test". D'ailleurs, il suffit de voir qui teste networkd sur la list, et tu va voir des emails @intel.com, @axis.com .

                          Ou simplement que malgré le fait qu'on trouve des Giga de ram, on trouve pas encore des giga sur les contrôleurs embarqués et sur toutes les pièces d'un appareil.

                          Et d'autre part, la tendance est à faire des conteneurs pour augmenter la densité du nombre de service par machine. Donc quand tu tapes dans les 2/3, ça va, ça fait pas grand choses. Quand tu tapes dans les centaines, tout d'un coup, ça commence à faire un multiplicateur qui rends la chose un chouia moins futile que tu sembles le croire, aussi bien en temps de démarrage qu'en occupation mémoire.

                          Donc oui, je pense que Moonz a raison de pointer l'overhead de systemd lui même par rapport à /bin/init du bon vieux temps, et que même si ça semble futile, ça reste un point à regarder. Mais comme j'ai dit plus loin, j'ai changé juste un paramètre à la fois pour comparer.

                          • [^] # Re: systemd-networkd ?

                            Posté par  . Évalué à 8. Dernière modification le 22 février 2014 à 16:27.

                            L'overhead entre :

                            • Du code C
                            • Des scripts interpretes

                            est sacrement evident, le C ecrase les scripts. Je ne doutes pas un moment que systemd sera plus optimise que le systeme d'init actuel, peu importe le nombre de lignes.

                          • [^] # Re: systemd-networkd ?

                            Posté par  . Évalué à 2.

                            le monde n'est pas composé uniquement de machines de bureau surdimensionnés

                            Effectivement, mon bureau est tellement petit que je dois bosser sur un portable ridicule pour avoir la place de mettre mes papiers en bordel à côté !

                      • [^] # Re: systemd-networkd ?

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

                        Non, car je ne parle de l'amélioration par rapport à ce que j'ai maintenant sur ma Fedora 20, histoire de comparer à feature grosso modo égales.

                        Sinon, je pourrait aussi dire "bah je flash coreboot et je boote direct sur un kernel qui lance un shell en 2 secondes" comme sur la demo ici ( https://www.youtube.com/watch?v=IKBtQYNrsBU ) et conclure "tout est bloated, il suffit juste que tout le monde tourne sur exactement mon pc et mon setup".

                        Il y a bien sur sans doute toujours moyen de faire plus spécialisé et qui prends le moins possible de place ( genre coder en dur les ip partout, voir pousser directement ça sur la stack du kernel ), mais l'exercise me parait futile.

                        Ensuite, je reconnait que le script network fait beaucoup plus que networkd. Par exemple, il gére l'isdn [~1.4M pour le rpm), le ppp (380k pour le soft), le dhcpv6, le bonding via teamd ( 250k ) ou ipx. Donc c'est pas vraiment à feature égal.

                        Mais sachant que je doute que l'isdn, le ppp ou ipx dans l'initrd soit vraiment présent dans la majorité des cas, je vois pas l’intérêt de prendre ça en compte. Et malgré le fait que ça soit fait de manière ad-hoc, comprendre "à l'arrache", en ne copiant pas ce qui ne doit pas être copié sans avoir vraiment de vision haut niveau de ce qui est requis, le script network marche sans la majorité des dépendances. Alors que bash et awk sont requis.

                        J'ai non plus pas compté les 400k de iputils, car je part du principe que même si c'est pas requis pour que networkd fonctionne, dans le cas d'une machine de rescue, on peut en avoir besoin. mais si le but est juste de comparer la taille sans prendre en compte le rescue (ce qui me semble tricher un peu, car je pense qu'on a besoin des outils), on peut retirer ça et mettre networkd, et voila.

                        Et en compilant systemd sans selinux, on retire les 400k de la libpcre, et les 140k de la libselinux, et j'imagine qu'avec kdbus, on peut sans doute retirer les 430k de dbus-daemon.
                        Je suis pas sur pour la libdbus car systemd a sa propre lib pour le support de dbus et de kdbus, et je suis pas assez courageux pour faire un make install sur ma bécane de prod, ni assez motivé pour faire une vm pour vérifier l'hypothèse.

                        Donc oui, dans le cas d'un initrd avec systemd/udev/etc, mettre networkd à la place du script network permet d'avoir un solution plus économe à mon sens. Mais tu peux sans doute faire mieux en sacrifiant des features qui te paraisse superflu (sans discuter du fait qu'elles le soit ou pas pour d'autres, et je reconnais bien volontiers que pas grand monde n'a besoin des vlans dans l'initrd par exemple)

                        C'est comme démarrer directement erlang depuis xen directement. C'est custom made, c'est rapide, ça permet d'avoir des choses qu'on arrive pas à avoir autrement mais voila, la majorité des gens vont pas utiliser ça.

                        • [^] # Re: systemd-networkd ?

                          Posté par  . Évalué à 1.

                          Non, car je ne parle de l'amélioration par rapport à ce que j'ai maintenant sur ma Fedora 20, histoire de comparer à feature grosso modo égales.

                          Parce que dans Fedora 20 systemd est déjà intégré à l’initrd mais pas bash ? Parce que chez moi (Archlinux) c’est l’inverse, dans l’initrd j’ai bien un shell de base (ash) et pas systemd, donc si je veux y mettre systemd-networkd je dois à priori ajouter systemd. À l’inverse, si je veux mettre un script network pas la peine de compter le shell, il y est déjà.

                          • [^] # Re: systemd-networkd ?

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

                            Systemd est intégré, oui. Et bash est présent ( via le module bash de dracut ), mais pas awk ni rien d'autre. Bash est présent uniquement pour le shell de secours, et visiblement parce que dracut est écrit en shell. Savoir si c'est remplaçable par dash/ash/sh est un exercise pour le lecteur.

            • [^] # Re: systemd-networkd ?

              Posté par  . Évalué à 7.

              Sinon, je ne pense pas qu'il y ait un intérêt à monter le réseau dans l'initrd.

              Avoir du réseau direct lors d'un boot rescue par exemple.

        • [^] # Re: systemd-networkd ?

          Posté par  . Évalué à 5.

          La remarque à été faite hier sur la mailling list dev de systemd. C'est affectivement lancé par défaut et ne fait rien si il y n'à pas de configuration. Évidement première remarque c'est que il faut pas lancer un truc qui sert à rien. La discussion est toujours en cour mais l'idée est semble t'il de laisser les distrib voir si elle l'utilise systemd.networkd par défaut ou NetworkManager ou autre.

        • [^] # Re: systemd-networkd ?

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

          Networkmanager fait beaucoup plus de choses, genre le wifi, le bluetooth, le ppp. Il gère les proxys dns ( via dnsmasq) et le partage de connexion.

          La, je pense que l'idée est surtout de remplacer /etc/init.d/network ( sur fedora ), et l'idée n'est pas non plus de Lennart, mais de Tom Gundersen, packageur Arch.

          • [^] # Re: systemd-networkd ?

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

            mais de Tom Gundersen, packageur Arch.

            Encore un salop de chez Archlinux qui veut dominer le monde et imposer ces vus à RedHat !

      • [^] # Re: systemd-networkd ?

        Posté par  . Évalué à 2.

        Pourtant y a des gens qui mettent NetworkManager dans l'initrd, et qui écrivent même des patchs noyau (foireux, mais c'est une autre histoire) pour rendre ça plus simple. Donc dire qu'il y a besoin de tout recoder from stratch pour faire quelque chose dans l'initrd c'est du bullshit.

        Sinon moi j'aurai bien envie d'avoir du réseau dans l'initrd, mais pour utiliser une conf que même NetworkManager ne supporte pas, alors que la fonctionnalité date des noyau 2.4.

        • [^] # Re: systemd-networkd ?

          Posté par  . Évalué à 2.

          Ouf, pourtant je comprends qu'on veuille pas mettre NM dans l'initrd, c'est un phacochère.

    • [^] # Re: systemd-networkd ?

      Posté par  . Évalué à 2.

      SystemD 209 ? Un rapport avec ED 209 ?

      S'il est conçu de la même manière, ça expliquerait bien des choses depuis le début (et ne présagerait rien de bon pour la suite)…

    • [^] # Re: systemd-networkd ?

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

      il devrait plutôt s'appuyer sur NetworkManger

      Je ne connais pas ce logiciel mais rien que le nom me fais peur Oo
      Un bouffeur de réseau qui a t il de pire pour un network addict ?

      Bon ok ça vole pas haut

      kentoc'h mervel eget bezan saotred

      • [^] # Re: systemd-networkd ?

        Posté par  . Évalué à 3.

        En anglais, "manger", c'est un mangeoire

        Un mangeoire à réseau, c'est pour que les autres viennent mangent mes paquets ?

  • # Et si on lisait un peu plus loin ?

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

    systemd le truc qui va bientot etre le seul system d'init sous linux parait il car il est super genial, en fait ca peut pas fonctionner actuellement sur les ARM car cela utilise une fonctionnalite de GCC a priori legerement experimentale et/ou non presente sur toutes les architectures

    Il va falloir citer ta source concernant le côté experimental de ifunc. Je suppose aussi que tu n'as pas lu le bug report en lien dans phoronix, ou il est indiqué :

    It's only for compat libs until stuff is re-compiled and the compat stuff goes
    away.

    C'est donc uniquement temporaire pour une transition. Par ailleurs, tu remarqueras que les développeurs systemd commentant le bug report sont Kay Sievers et Zbigniew Jędrzejewski-Szmek.

    Je ne sais pas si ton impression est vraie en fausse, mais il semble bien que l'utilisation d'ifunc dans systemd ne puisse pas permettre d'en confirmer la véracité.

    • [^] # Re: Et si on lisait un peu plus loin ?

      Posté par  . Évalué à -10.

      J'y connais rien a ifunc et a systemd vu que je ne l'utilise pas (et depuis quand faut il connaitre quelques chose pour troller surtout un vendredi!). Du coup je ne sais pas si ifunc c'est experimental ou pas mais cela n'existe pas et a priori d'apres la reponse du dev GCC cela n'existera pas avant longtemps sur ARM et pas mal d'autre architecture. Maintenant c'est peut etre super genial et ca permet de faire le cafe en plus de gagner 3 milliemes de seconde au demarrage mais bon si cela fait que l'init ne fonctionne plus que sur une seul architecture cela me semble pas etre un super choix mais comme je dis on est vendredi et je troll comme un goret.

      • [^] # Re: Et si on lisait un peu plus loin ?

        Posté par  . Évalué à 8.

        J'y connais rien a ifunc et a systemd […]

        Et en anglais tu t'y connais ? Tu as lu la discussion ? (https://bugzilla.redhat.com/show_bug.cgi?id=1067245#c4)

        It's only for compat libs until stuff is re-compiled and the compat stuff goes
        away. Pkgconfig files are changed, a simple re-build should switch over to the
        new lib.

        Any better idea/way than ifunc to wrap the symbols of a lib with a new name
        in a stub .so with the old name?

        Ils ont choisi une solution temporaire simple pour faire une transition et son ouverts à d'autres solutions pour faire la même chose. Il te faudrait quoi ?

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

    • [^] # Re: Et si on lisait un peu plus loin ?

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

      Je suppose aussi que tu n'as pas lu

      Albert, lire? :p

  • # Le nid à trolls

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

    We merged libsystemd-journal.so, libsystemd-id128.so, libsystemd-login
    and libsystemd-daemon into a a single libsystemd.so to reduce code
    duplication and avoid cyclic dependencies (see below).

    C'est marrant comme systemd peut être un vrai nid à trolls. Il faut dire que Lennart y met beaucoup d'entrain. Là, pour les non-anglophones, il annonce qu'il fusionne plusieurs bibliothèque en une seule. Et quand on voit la liste, on se dit que systemd devient de plus en plus un truc monolithique, loin de ce que ses défenseurs nous vendent depuis des lustres comme quoi tout est bien séparé. Bref, je constate que les pourfendeurs de Lennart avait vu juste sur ce point… et la suite alors ? Va falloir refaire du pop corn là !

    • [^] # Re: Le nid à trolls

      Posté par  . Évalué à 10.

      Oui effectivement systemd commence à devenir un bon OS, il lui manque juste un bon système d'init ;)

      Il ne faut pas décorner les boeufs avant d'avoir semé le vent

      • [^] # Re: Le nid à trolls

        Posté par  . Évalué à 10.

        systemctl enable openrc.service ?

        • [^] # Re: Le nid à trolls

          Posté par  . Évalué à 5.

          hum, est ce que ça s'apparente plus à
          M-x vi-mode
          ou
          M-! gvim ?

          Il ne faut pas décorner les boeufs avant d'avoir semé le vent

      • [^] # Re: Le nid à trolls

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

        il lui manque juste un bon système d'init ;)

        j'aurais plutôt dit qu'il manquait un éditeur de texte :P

      • [^] # Re: Le nid à trolls

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

        Franchement Lennart déconne. Il aurait pu écrire systemd en Scheme afin de le faire tourner avec Guile qui lui-même lancera bientôt Emacs, et nous aurions enfin pu avoir l'OS de rêve : la machine LISP … heu .. Scheme.

    • [^] # Re: Le nid à trolls

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

      Ils ont fusionné une lib de 15kio avec une lib de 51kio et une autre de 111kio?

      Effectivement, c'est la fin des haricots…

      • [^] # Re: Le nid à trolls

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

        Le problème n'est pas dans la quantité… Depuis le début, on nous vend logind, journald et systemd (l'init, pas le projet complet) comme étant des trucs séparés qu'on peut remplacer par d'autres composants toussa toussa. Et là, paf, on met tout ensemble. Moi, je dis qu'il y a comme un problème, mais après, je veux pas être mauvaise langue. N'empêche que si on va relire tous les trolls sur la dépendance de GNOME à systemd, je pense qu'on va bien se marrer avec des arguments de l'époque qui viennent de voler en éclat d'un seul coup.

        • [^] # Re: Le nid à trolls

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

          Et là, paf, on met tout ensemble.

          Es-tu obligé d'utiliser logind, journald, networkd pour pouvoir utiliser systemd?

          sur la dépendance de GNOME

          Bordel! On y retourne aux trolls pourris… C'est un choix de GNOME, pas de Lennart/systemd. Plaint-toi à GNOME, systemd n'a rien à voir la dedans.


          C'est fou comme on peut chercher tout et n'importe quoi quand on a décidé de ne pas aimer, faut croire que dès que ça marche et que plein de gens adhèrent, ça embète des gens qu'un logiciel fasse trop ce qui plait à ceux qui en ont besoin…

          • [^] # Re: Le nid à trolls

            Posté par  . Évalué à 1. Dernière modification le 21 février 2014 à 22:59.

            Es-tu obligé d'utiliser logind ?

            Non

            Es-tu obligé d'utiliser journald ?

            Oui

            Es-tu obligé d'utiliser networkd ?

            Oui

            pour pouvoir utiliser systemd ton ordinateur ?

            Oui

            systemd n'a rien à voir la dedans

            Oh que si, on fusionne avec udev, on commence a exiger que toutes les applications deviennent des "services" (processus ? non, c'est trop old school), on mélange programme et init file au sein d'un même projet pour "plus de simplicité". Du beau, du propre, du simple, du léger, du portable, et en plus systemd est facilement remplaçable par une alternative.

            Dîtes, ça existe encore des personnes qui savent faire de beaux programmes, proprement, le plus simplement possible, qui soient légers et portable, le tout bien intégré au système ?

            • [^] # Re: Le nid à trolls

              Posté par  . Évalué à 10.

              qui soient légers et portable, le tout bien intégré au système ?

              Je crois qu'il y a un léger soucis de compatibilité entre ces deux points.

              • [^] # Re: Le nid à trolls

                Posté par  . Évalué à 3.

                Ben si, ça signifie respecter les spécificités du système cible sans introduire de couplage fort dessus.

                Cairo par exemple est portable et intégré au système : portable pas la peine de s’étendre dessus, intégré au système : il utilise Quartz sous OSX, xlib/xcb sous Linux, GDI sous Windows. Apache est portable mais capable d’utiliser des mécaniques spécifiques à l’OS (epoll sous Linux, GCD sous OSX)…

                • [^] # Re: Le nid à trolls

                  Posté par  . Évalué à 7.

                  Le but de systemd est de profiter des spécificités de Linux, et de fournir un ensemble d'outils en espace utilisateur permettant d'utiliser et de profiter des cgroups, pas de faire quelque chose de générique.

                  On peut faire un système d'init qui s'adapte selon le kernel, mais dans ce cas on écrit autre chose qu'un systemd.

                  L'exemple de Cairo est donc hors sujet, d'autant plus que c'est une bibliothèque graphique, pas un système d'init (le problème est totalement différent).

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

                • [^] # Re: Le nid à trolls

                  Posté par  . Évalué à 5.

                  Là tu parles d'interface graphiques, déjà branchées par dessus des abstractions (libc, c++, X11, wayland)

                  En l'occurence, systemd est la couche basse, directement branchée sur le noyau.
                  Or la principale différence entre un linux et un BSD est … le noyau, linux ou BSD.

                  Du coup je ne vois pas comment faire un truc portable directement au dessus du noyau, à moins de faire une lib d'abstraction intermédiaire ? qu'on appellerai libsystem, et par dessus, on aurait notre outil portable, que l'on pourrait appeler libbus !

                  Je tiens un truc là je crois…

              • [^] # Re: Le nid à trolls

                Posté par  . Évalué à 2.

                Il y a une panacée d'outils qui sont utilisable sur les BSD et Linux par exemple. Regarde Qt, il n'est pas léger mais par contre il est portable et bien intégré au système, les fenêtres s’adapte selon le système qui exécute le programme. Tout les WM minimalistes sont légers, portables et sont généralement bien intégré au système. Bref, tu utilises quasi tout les jours des programmes bien conçu, légers, portable, intégré a ton système, etc…

                • [^] # Re: Le nid à trolls

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

                  La portabilité, c'est trés surfait. par exemple, awesome est minimaliste, mais est ce qu'il est portable ? Par exemple, je peux faire tourner ça sur ios, android ou windows ?

                  Ou est ce que la portabilité est une notion faiblement défini par "portable sur ce qui me parait important et fuck off les chiffres et les stats qui montrent que ça reste 1% du parc" ?

                  • [^] # Re: Le nid à trolls

                    Posté par  . Évalué à 0. Dernière modification le 22 février 2014 à 12:42.

                    La portabilité, c'est trés surfait. par exemple, awesome est minimaliste, mais est ce qu'il est portable ? Par exemple, je peux faire tourner ça sur ios, android ou windows ?

                    Pour l'avoir utilisé très longtemps, je peux te dire que awesome n'a rien de minimaliste et est plutôt lourd comparé à beaucoup d'autres WMs tel que Openbox ou WMFS.

                    Si le serveur X tourne sous Windows alors un programme portable est un programme que tu pourra aussi faire tourner sous Windows. Disons qu'un WM fait à la systemd ne tournerais que sous Linux, même si le serveur X tourne sous Windows.

                    Ou est ce que la portabilité est une notion faiblement défini par "portable sur ce qui me parait important et fuck off les chiffres et les stats qui montrent que ça reste 1% du parc" ?

                    La portabilité, c'est de ne pas dépendre de fonctionnalités spécifiques d'un système lors d'un fonctionnement normal.

                    • [^] # Re: Le nid à trolls

                      Posté par  . Évalué à -1.

                      La portabilité, c'est de ne pas dépendre de fonctionnalités spécifiques d'un système lors d'un fonctionnement normal.

                      Il est possible de faire tourner les apps Android sous Windows, ca veut dire qu'elles sont toutes portables ?

                      • [^] # Re: Le nid à trolls

                        Posté par  . Évalué à 1.

                        Il est possible de faire tourner les apps Android sous Windows, ca veut dire qu'elles sont toutes portables ?

                        Avec un émulateur ?

                        • [^] # Re: Le nid à trolls

                          Posté par  . Évalué à -1.

                          Non, avec une VM, tout comme Android fait tourner ces apps

                          • [^] # Re: Le nid à trolls

                            Posté par  . Évalué à 0.

                            C'est quoi un émulateur, si ce n'est une VM ?

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

                            • [^] # Re: Le nid à trolls

                              Posté par  . Évalué à 1.

                              Je pense qu'il veut dire une dalvik vm, pas un systeme complet dans une vm a la vmware/whatever.

                              Linuxfr, le portail francais du logiciel libre et du neo nazisme.

        • [^] # Re: Le nid à trolls

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

          Les arguments à l'époque était sur les appels de fonctions dbus. La, on parle de fonctions en C et la différence entre avant et maintenant, c'est ce sur quoi tu lies ton binaire.

        • [^] # Re: Le nid à trolls

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

          Cela n'a rien à voir. Ils fusionnent un bibliothèque ELF (.so). Donc on va gagner en RAM et en temps de chargement. En cas de bogue, c'est corrigé partout.

          Bref, les binaires restent séparés.

        • [^] # Re: Le nid à trolls

          Posté par  . Évalué à 6. Dernière modification le 21 février 2014 à 21:41.

          Oh ben ça se voit que certains ne savent pas lire.

          Systemd, une fois compilé, est composée d'une soixantaine de binaires (notamment pour des raisons de sécurité), pour la plupart remplaçeables.

          systemd /usr/bin/bootctl
          systemd /usr/bin/hostnamectl
          systemd /usr/bin/journalctl
          systemd /usr/bin/kernel-install
          systemd /usr/bin/localectl
          systemd /usr/bin/loginctl
          systemd /usr/bin/machinectl
          systemd /usr/bin/systemctl
          systemd /usr/bin/systemd-analyze
          systemd /usr/bin/systemd-ask-password
          systemd /usr/bin/systemd-cat
          systemd /usr/bin/systemd-cgls
          systemd /usr/bin/systemd-cgtop
          systemd /usr/bin/systemd-coredumpctl
          systemd /usr/bin/systemd-delta
          systemd /usr/bin/systemd-detect-virt
          systemd /usr/bin/systemd-inhibit
          systemd /usr/bin/systemd-machine-id-setup
          systemd /usr/bin/systemd-notify
          systemd /usr/bin/systemd-nspawn
          systemd /usr/bin/systemd-run
          systemd /usr/bin/systemd-stdio-bridge
          systemd /usr/bin/systemd-tmpfiles
          systemd /usr/bin/systemd-tty-ask-password-agent
          systemd /usr/bin/timedatectl
          systemd /usr/bin/udevadm

          (il y en a aussi beaucoup que je n'utilise jamais, du genre hostnamectl ou timedatectl)

          Là, on met juste le code de plusieurs bibliothèques en commun pour réduire le code dupliqué, ça ne change strictement rien pour les utilisateurs (à part qu'il y a potentiellement moins de bugs, et un peu moins de mémoire utilisée).

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

  • # lanĉo

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

    Allez hop, un petit concurrent pour la forme. lanĉo est un lanceur de tâches utilisant les cgroups, il a pas besoin d'avoir le PID=1 pour fonctionner.

    http://vincent.bernat.im/fr/blog/2013-lanco.html

Suivre le flux des commentaires

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