Journal Systemd contrôlera bientôt tout votre réseau

Posté par (page perso) . Licence CC by-sa
19
14
jan.
2015

Bonjour 'nal.

Nous ne sommes certes pas encore Vendredi, mais un journal sur systemd ne fait pas de mal de temps à autres, afin que la flamme entre nous ne s'éteigne pas.

Aujourd'hui, à vu se concrétiser le rêve de beaucoup d'entre nous : remplacer Iptables sous Linux par quelque chose de mieux.

Bien sûr qu'il existe un projet nommé "nftables", dont le but est de remplacer Iptables, avec une syntaxe proche de celle de pf. Néanmoins, c'est bien plus cool et hype de taper des commandes du genre "systemctl allow 22 on localhost", ne trouvez-vous pas ? (Cette commande n'existe pas (encore ?), c'est une simple blague)

Pour ceux ayant parié que Systemd gérerait bientôt le pare-feu, vous avez gagné. Pour les autres, prenez les paris sur le prochain composant d'un système Gnu/Linux que Systemd gérera !

À vos trolls !

Source : Systemd Gains IP Forwarding, IP Masquerading & Basic Firewall Controls

  • # Lien cassé

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

    Visiblement, le titre du lien et l'URL ont été inversés : l'URL s'affiche et le lien est cassé

    • [^] # Re: Lien cassé

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

      Oups, oui. Si un modo pouvait passer dans le coin pour corriger, je lui en serais gré. :)

      • [^] # Locution verbale.

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

        Attention, il faut employer la locution verbale "savoir gré" et non "être gré". Il fallait donc lire "Je lui en saurais gré" (conditionnel par déférence)
        http://www.langue-fr.net/spip.php?article237

        • [^] # Re: Locution verbale.

          Posté par (page perso) . Évalué à 1. Dernière modification le 14/01/15 à 15:03.

          Attention, il faut employer la locution verbale "savoir gré" et non "être gré". Il fallait donc lire "Je lui en saurais gré" (conditionnel par déférence)
          http://www.langue-fr.net/spip.php?article237

          Entendu, je m'en souviendrais. :)

          • [^] # Re: Locution verbale.

            Posté par . Évalué à 4.

            Entendu, je m'en souviendrais. :)

            A quelle condition ?

            souviendrais avec un s, c'est du conditionnel. Au futur, c'est sans s.

            http://sensmotdire.gnunux.info/souvenir.html

            • [^] # Re: Locution verbale.

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

              souviendrais avec un s, c'est du conditionnel. Au futur, c'est sans s.

              Il me semble que, depuis quelques années, on rencontre de plus en plus souvent cette confusion entre le conditionnel et le futur, et je me demandais pourquoi. Il y a des régions où le é (ai) et le è (ais) se prononcent pareil, mais ça me semble tout de même minoritaire.

              • [^] # Re: Locution verbale.

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

                Il y a des régions où le é (ai) et le è (ais) se prononcent pareil

                C'est quoi le rapport avec l'explication de la confusion ?

                • [^] # Re: Locution verbale.

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

                  Il y a des régions où le é (ai) et le è (ais) se prononcent pareil

                  C'est quoi le rapport avec l'explication de la confusion ?

                  Pour moi, c’est facile :

                  • je prononce souviendré au futur, et je l’écris donc souviendrai

                  • je prononce le -ais du conditionnel comme celui de l’imparfait, souviendrè, et je l’écris donc souviendrais

                  Après, c’est sûr que pour ceux qui prononcent tout pareil ou qui n’entendent plus la différence, c’est plus dur !

                  • [^] # Re: Locution verbale.

                    Posté par . Évalué à 5.

                    En fait pour écrire les prononciations, on a un alphabet pour ça. Alors pour le verbe se souvenir, selon le wikitionnaire :

                    • je me souviendrai /ʒə mə su.vjɛ̃.dʁe/ (indicatif futur)

                    • je me souviendrais /ʒə mə su.vjɛ̃.dʁɛ/ (conditionnel présent)

                    Et en effet, quand on prononce différemment on ne fait pas la faute, si on verbalise au moment où on écrit, ce qui n'est pas le cas de tout le monde. Personnellement je sais que je le fais, mais pas tout le temps.

                    • [^] # Re: Locution verbale.

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

                      Disons que si on prononce différemment, on a plus de chance de faire attention à la différence, que ça soit plus clair dans sa tête.

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

              • [^] # Re: Locution verbale.

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

                Il y a des régions où le é (ai) et le è (ais) se prononcent pareil, mais ça me semble tout de même minoritaire.

                Il y a vraiment des régions où on prononce différemment "-ai" et "-ais" ?
                Ah, les merveilles de la langue parlée…

                • [^] # Re: Locution verbale.

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

                  Ah, les merveilles de la langue parlée…

                  Hé, cong !

                • [^] # Re: Locution verbale.

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

                  Ah, les merveilles de la langue parlée…

                  Ou les merveilles d’une langue dont la phonétique est ambigüe.

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

                  • [^] # Re: Locution verbale.

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

                    une langue dont la phonétique est ambigüe.

                    Il n'y a rien d'ambigu dans le -ai -ais -ait : ça se prononce officiellement TOUJOURS ɛ (en alphabet phonétique).

                    La question des accents locaux, je ne pense pas que ce soit pris en compte par qui que ce soit.

                    N'empêche qu'avoir une prononciation différente pour l'imparfait, le futur et le conditionnel serait top. Il faudrait en profiter pour qu'à l'écriture ce soit plus marqué. Autant modifier la langue :-)

                    • [^] # Re: Locution verbale.

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

                      la phonétique pour ferai indique /fə.ʁe/

                      (un contre-exemple suffit à infirmer un toujours, dont acte, il y a bien une prononciation différente entre ferai et ferais qui se dit /fə.ʁɛ/).

                    • [^] # Re: Locution verbale.

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

                      Pardon: une langue qui n’est pas phonétique, que tout le monde prononce comme il veut en fonction de l’heure de la journée. Quantique, /kã/ ou /kwã/ au début? Oignon ou ognon? Différence entre a et â? Entre un et in? Entre é et è? Entre -ais et -ai? Agenda, /ɛ̃/ ou /ã/? Examen mais spécimen! Forum mais parfum! Damné, automne, à croire que les m sont inutiles! La prononciation des mots abbaye ou solennel est hilarante! Faisan, poêle, second (ce con!).

                      Le fait qu’il y ait une prononciation officielle ne veut rien dire, la prononciation varie pas mal, les mots se prononcent n’importe comment.

                      On voit par contre que dans d’autres langues comme le Japonais ou l’espéranto, la prononciation est (quasiment dans le cas du japonais) sans exception. Et puis surtout, en espéranto, le conditionnel (-us) et le futur (-os) ne se prononcent pas pareil. C’est d’ailleurs un des points qui me permettra sans doute de me poser la question du futur/conditionnel en français et d’arrêter de faire l’erreur.

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

                      • [^] # Re: Locution verbale.

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

                        et tu prononces comment « les poules du couvent couvent » ?

                        l'orthographe de 1990 s'est peut-être intéressée à la prononciation aussi ? (j'en doute, même si l'écriture d'ognon y est sans doute pour quelque chose :/).

                        Pour quantique, j'imagine qu'il y a possibilité de le distinguer de cantique dans un cas ;-)

                        Entre le a et le â : tu prononce pareil « une patte » et « de la pâte » ?

                        Sinon, évidemment qu'il y a une différence avec évidement ! ;-)

                        • [^] # Re: Locution verbale.

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

                          et tu prononces comment « les poules du couvent couvent » ?

                          Ça me rappelle la célèbre dictée « les poules étaient sorties dès qu’on leur avait ouvert la porte », où tous les gosses avaient bien sûr écrit « des cons ».

                        • [^] # Re: Locution verbale.

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

                          l'orthographe de 1990 s'est peut-être intéressée à la prononciation aussi ? (j'en doute, même si l'écriture d'ognon y est sans doute pour quelque chose :/).

                          Pas pour la conjugaison (entre é, ez, ais et ai, je crains qu’on est plus de terminaisons pour indiquer le son /e/ ou /ɛ/). Par contre, on a vu l’apparition d’ognon, et des changements tels que évènement à la place d’événement, ambigüe plutôt qu’ambiguë, serpillère à la place de serpillière, etc.

                          Je ne sais pas si je t’en avais parlé mais dans les propositions de modification de l’orthographe qui me trottent dans la tête, il y a des trucs comme: solanel, abbéi/abbéie, alcol, autone, (con)dané, examin (par analogie à examinateur), segond, et quelques autres comme ça. Il y a clairement des trucs à creuser.

                          Entre le a et le â : tu prononce pareil « une patte » et « de la pâte » ?

                          Je ne fais pas la différence, et on fait assez peu la différence en France je crois en France. Par contre au Québec il font la différence entre tout. ^^

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

                          • [^] # Re: Locution verbale.

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

                            Pas pour la conjugaison (entre é, ez, ais et ai, je crains qu’on est plus de terminaisons pour indiquer le son /e/ ou /ɛ/).

                            Ben, justement, là, c'était « je crains qu’on ait » ;-)

                            • [^] # Re: Locution verbale.

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

                              Fatigue fatigue…

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

                              • [^] # Re: Locution verbale.

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

                                et plutôt moins que plus, sinon il vaut mieux préciser la négation « je crains qu’on n'ait plus » : autrement, cela ne se prononce pas pareil ce que ne permet pas l'écrit pour discerner le sens effectif ;-)

              • [^] # Re: Locution verbale.

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

                Il y a des régions où le é (ai) et le è (ais) se prononcent pareil, mais ça me semble tout de même minoritaire.

                -ai, -ais et è c’est pareil pour moi (je vis en banlieue parisienne). Minoritaire, ça m’étonnerait fort.

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

                • [^] # Re: Locution verbale.

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

                  En région parisienne, c'est encore pire que dans le sud (ou tout est é) : c'est un gros mélange, donc il y a même des inversions de sons entre é et è ! Par exemple, il y a des gens qui disent du lé (lait) et un cahiè (cahier)…

      • [^] # Re: Lien cassé

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

        C'est corrigé.

  • # Les conteneurs

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

    Je prends le pari sur une implémentation de conteneurs à la docker. Après tout les cgroups ils savent faire aussi. Un intérêt serait par exemple d'avoir une unique distribution "systemd" qui lance des applis d'autres distributions dans leur propre conteneur.

    De là à penser qu'ensuite une intégration poussée entre openstack et ces hyperviseurs systemd rendrait la plateforme redhat parfaitement adaptée et surtout centrale…

    Pour en revenir à des sujets moins trollesque (et encore), c'est pas complètement stupide de laisser à systemd le soin de gérer les flux et les redirections. En effet ça peut être lié à un service (genre un service apache ou un load balanceur?), mais ça signifie qu'il va falloir réimplémenter tout iptable/nftable pour que ce soit viable (deux systèmes qui se marchent dessus ça ne fonctionne jamais bien longtemps sur un système). Le coût me parait gros à vrai dire.

    On pourrait presque demander ce qui ne va pas dépendre de systemd en fait, car s'il gère les services et la pile réseaux, restera les filesystems et la gestion de version des données dessus.

    A la limite ce qui serait bien c'est que systemd nous sorte un gestionnaire de paquet qui soit pris d'office partout (ce qui serait quasiment ait s'ils font des conteneurs). Là ça serait un vrai changement majeur et un bénéfice non négligeable je trouve :)

    • [^] # Re: Les conteneurs

      Posté par . Évalué à 6.

      STP, ne parle pas de cauchemard.

      • [^] # Re: Les conteneurs

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

        Ah oui ça change :p

        Ça mets aux oubliette les principes unix une telle vision (quoi que chaque conteneur faisant son travail spécifique, et systemd étant là pour faire le pipe c'est pas non plus orthogonal avec unix en fait… juste à 89° ^ ).

        Ensuite faut pas se leurrer, on s'oriente de plus en plus vers des systèmes applicatifs jetables une fois instanciés (l'image et la manière dont on orchestre les images est ce sur quoi on travaille, les instances non). EC2 a ouvert la voie, Docker renfonce le clou avec son écosystème (peu importe ce qu'on pense prod/pas prod, la question n'est pas là, si c'est pas lui ça sera un autre qui arrivera à la prod). On est plus qu'incité avec les outils qu'on a à notre disposition de bâtir de manière quasi-automagique notre infra. Or arrivé à ce niveau là, on n'a plus trop besoin d'avoir un init à la systemd pour lancer X services sur le même serveur, mais plutôt de lancer X boites sur X serveurs hôtes différents qui échangeront ensemble à travers un réseaux bâti lui aussi de manière quasi-automagique.

        Bien? Mal? Sincèrement je ne sais pas. De plus peu être que finalement seule une minorité d'admins en aura besoin réellement d'un tel système, et que la majorité restera avec le bon vieux système de VM installée à la main.

        Je pense que personne n'est naïf au point de croire que systemd est juste là pour faire plaisir à ses développeurs, et que lorsqu'ils rajoutent un pan à leur outil c'est juste pour avoir ds lignes de code à entrer dans leur emacs/vi/nano/notepad (rayé la mention inutile). C'est leur taf, pas leur hobbie, il y a une raison économique derrière. Ainsi lorsque je m'amuse à extrapoler les avancées des différents outils ça donne ça, ensuite rien ne dit qu'une autre organisation que redhat n'a pas autre chose dans les cartons :) (je pense tout particulièrement à google, facebook ou amazon, qui ont l'air de ne pas attendre que des éditeurs leur fournissent les outils centraux de leur SI).

        Ou alors je me trompe complètement et Lennart c'est juste un grand curieux qui veut toucher à tous les domaines d'un OS ^ ^

        • [^] # Re: Les conteneurs

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

          Bon en fait les conteneurs systemd les a déjà: http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html …..

        • [^] # Re: Les conteneurs

          Posté par . Évalué à 6.

          C'est vrai, ça serait super cool ça.

          Si on résume, on aurait un système ultra minimal qui se chargerait de lancer des hôtes pour les diverses applications. Poussé au max, on aurait un hôte pour le système de fichier (les autres hôtes y accédant par le réseau) et plus généralement, on en aurait un pour chaque périphérique. On pourrait imaginer un hôte dont le boulot serait de géré les droits d'accès. On pourrait imaginer qu'un hôte puisse lancer un hôte sans avoir de droits privilégiés. Avec ça, on pourrait retirer plein de trucs inutiles du noyau. Bien évidemment, on n'utiliserait pas le vrai réseau mais un système d'IPC super optimisé. Je propose qu'on appelle ce nouveau noyau « micro linux ». Mais certains esprits chagrins risqueraient de dire que c'était mieux avant quand ça ne s'appelait encore que le Hurd.

          • [^] # Re: Les conteneurs

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

            Poussé au max, on aurait un hôte pour le système de fichier (les autres hôtes y accédant par le réseau)

            Ah non, il faut un namespace par hôte.

            On pourrait imaginer qu'un hôte puisse lancer un hôte sans avoir de droits privilégiés.

            Comme LXC ?

            ien évidemment, on n'utiliserait pas le vrai réseau mais un système d'IPC super optimisé.

            Donc, les namespaces ?

            « 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: Les conteneurs

      Posté par . Évalué à 4.

      Tu va rigoler, mais il y avait un journal ici qui pointait vers un lien où l'on parlait d'utiliser les capacités de btrfs(?) et systemd pour gérait les "paquets" sur un système. Au lieu de décompresser ses paquets dans son fs, on crée plusieurs volumes logiques dans lesquels on a ses différents logiciels. Par exemple, tu peux avoir un volume avec un /usr pour GNOME, un /usr avec des paquets de Fedora 20, un /usr avec des paquets de Fedora 21, etc.
      Du coup, au lieu de te casser les pieds à créer des paquets, tu créés une fois un volume qui va bien et voilà.

    • [^] # Re: Les conteneurs

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

      Je prends le pari sur une implémentation de conteneurs à la docker.

      Tu veux dire comme systemd-nspawn

      mais ça signifie qu'il va falloir réimplémenter tout iptable/nftable pour que ce soit viable

      Là, je ne comprends pas, pour l'instant, ça utilise nftable pour gérer le pare-feu.

      « 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: Les conteneurs

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

        Ah j'avais cru comprendre que c'était en parallèle et non pas en réutilisant nftable. Techniquement c'est déjà moins lourd, même si sur le fond ça fait que tu as quand même deux endroits/manières de gérer ton firewall.

        Systemd tente quand même d'unifier pas mal de points en un tout cohérent, ce n'est pas rien. Ensuite s'il est facile de déboîter une brique pour en mettre une autre à la place ça bien. Genre ici ce qu'il ne faut pas c'est que du doive obligatoirement passer par la définition des services pour gérer la partie réseau de tes daemons. Si ça repose sur des briques/lib communes, tu peux avoir 80% des cas gérés avec systemd, et les 20% derniers avec des briques plus adaptés/spécifiques :D

        Je pense que son soucis c'est qu'il a été vu comme un "simple" serveur d'init. Or c'est une sorte de middleware pour l'OS. C'est plus à comparer avec la libc qu'avec un systemV au final. Bon après il a du démarrer comme un init et évoluer vers ça.

        • [^] # Re: Les conteneurs

          Posté par . Évalué à 4.

          C'est plus à comparer avec la libc qu'avec un systemV au final.

          Plutôt un base system comme on en trouve chez BSD.

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

        • [^] # Re: Les conteneurs

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

          Ah j'avais cru comprendre que c'était en parallèle et non pas en réutilisant nftable

          C'est moi qui avait mal compris.

          « 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: Les conteneurs

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

          Je pense que son soucis c'est qu'il a été vu comme un "simple" serveur d'init.

          Je pense qu'il a été vu comme ça par ses premiers développeurs qui se sont rendus compte que leurs travaux avaient un intérêt ailleurs en développant.

          « 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: Les conteneurs

      Posté par . Évalué à 10.

      Systemd peut-il se remplacer lui même?

      • [^] # Re: Les conteneurs

        Posté par . Évalué à 1.

        Oui, et c'était prévu depuis longtemps dans le plan machiavélique de Lennart.
        Parce que soyons honnête, systemd, c'est à chier comme nom.

        Lennart avait déjà prévu de le remplacer par quelque chose d'autre à l'apogée de la résistance contre systemd.
        Bientôt, vous verrez apparaître la révolution:

        systèmE

        Et oui, Lennart va basculer tous les commentaires du code en Français!

        • [^] # Re: Les conteneurs

          Posté par . Évalué à 10.

          Si il comptait changer de nom, il aurait mieux fait de l'appeler systemboob au départ.

          • [^] # Re: Les conteneurs

            Posté par . Évalué à 10.

            Je suis scandalisé.

            • [^] # Re: Les conteneurs

              Posté par . Évalué à 4.

              Hé! Dans le dialecte du celte ancien qui était utilisé dans le village situé sous ma ville natale il y a 2430ans, "skandl" signifiait "gros sein avec des poils" et était une insulte aux femmes.

              Surveille un peu ton langage, tout de même. Il pourrait y avoir des enfants qui passent dans le coin!

    • [^] # Bedrock Linux

      Posté par . Évalué à 1.

      Il y a déjà ça qui marche bien :
      http://bedrocklinux.org/
      qui fait méta distribution pour utiliser plusieurs distributions au dessus en parallèle

  • # Précision

    Posté par . Évalué à 10.

    Le pare-feu sous linux est fait de plusieurs composants, le framework Netfilter qui intercepte et manipule les paquets, ip_tables, le module, qui s'insère dans Netfilter et décrit les règles de filtrages, et iptables l'outil en userspace qui transmet les règles à ip_tables, le module.

    Ca m'étonnerait que systemd est l'intention de toucher aux de premiers (quoi que on sait jamais où ils s'arrêtent, c'est uniquement l'outil iptables qui est remplacé, celui étant assez simpliste. D'ailleurs quand on utilise ufw ou autre, il se passe la même chose.

    nftables a pour but de remplacer le module et l'outil. Le module nftables pourrait donc être utilisé par systemd, ils sont complémentaires, pas opposés.

    Après on peut débattre de la pertinence d'un gestionnaire de pare-feu dans systemd (même si pour l'instant ça semble se limiter à du NAT)

    • [^] # Re: Précision

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

      nftables a pour but de remplacer le module et l'outil. Le module nftables pourrait donc être utilisé par systemd, ils sont complémentaires, pas opposés.

      Merci de la précision, je n'étais pas au courant pour le module, je pensais que iptables dialoguait directement avec netfilter.

  • # Les truc essentiels

    Posté par . Évalué à 1.

    Pour les autres, prenez les paris sur le prochain composant d'un système Gnu/Linux que Systemd gérera !

    La barbichette du GNU et la banquise du pingouin.

    kentoc'h mervel eget bezan saotred

  • # Proposition

    Posté par . Évalué à 4.

    Je proposes de renommer systemd en MCP

    trolldi c'est demain je sais

  • # Journal approximatif

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

    systemd-networkd sert à configurer les interfaces réseaux. Ca peut être pratique que cet outil gère l'option IP forward et le NAT. Par contre, l'article Phoronix ne parle pas d'une réimplémentation du parefeu ni d'outil pour manipuler iptables ou nftables. Extrait :

    Also added on Tuesday was minimal firewall manipulation helpers for systemd's networkd.

    Et puis bon, Phoronix n'est pas la meilleure source qui existe…

    • [^] # Re: Journal approximatif

      Posté par . Évalué à 2.

      Tout comme ça serait sûrement très pratique que 'systemd' fasse le café.

      Est-ce intelligent pour autant ? Non.
      Ce n'est pas parce qu'on peut le faire qu'on doit le faire.

      Visiblement certains semblent oublier pourquoi les *NIX ont réussi à devenir des OS de référence et à tenir la distance depuis tant d'années. Une de ces raisons, c'est qu'on a segmenté les tâches simples sous formes de briques assemblables et indépendantes, plutôt que de tout mettre dans un gros ensemble qui ferait tout et sur lequel tout reposerait.

      Ca fait 40 ans qu'on aurait pu écrire un 'systemd'. Si ça n'a pas été fait c'était pour de bonnes raisons. Il y a des fois où il faut savoir faire marche arrière et se dire que les vieilles recettes sont parfois les meilleures.

      • [^] # Re: Journal approximatif

        Posté par . Évalué à -1.

        LOL

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

      • [^] # Re: Journal approximatif

        Posté par . Évalué à 3.

        L’approche monolithique fonctionne aussi, cf Windows.

        La question c’est pas qu’est-ce qui fonctionne ou pas, les deux approches fonctionnent, la question c’est quelle culture technique tu veux promouvoir/attirer, celle qui a conduit à Linux (avec ses grandes réussites en terme d’adaptabilité, d’outils pédagogiques, d’innovations techniques), ou celle qui a conduit à Windows (avec ses grands succès en terme d’adaptation au grand public, d’expérience utilisateur).

        • [^] # Re: Journal approximatif

          Posté par . Évalué à 3.

          systemd n'a rien à voir avec Windows, mais bon…

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

        • [^] # Re: Journal approximatif

          Posté par . Évalué à -1.

          Techniquement, évidemment que ça fonctionne.

          Je parle de faire tourner les choses proprement pour qu'on puisse continuer à avoir un système fiable et performant. Linus Torvald est du genre à passer une nuit sur une fonction appelée 1 fois par jour pour gagner 5 cycles microprocesseur, son argument étant de dire que 5 cycles CPU x des millions de machines, ça fait beaucoup d'énergie économisée. C'est cette approche que j'aimerais voir dans les distributions.

          Lennart Pottering est bien loin de cet état d'esprit selon moi, sinon il aurait contribué à des systèmes de démarrage existants en vue de les améliorer (je pense à OpenRC qui n'est pas parfait mais qui se rapproche de ce que 'systemd' sait faire, et pour le coup de manière propre, intelligente et compatible UNIX).

          • [^] # Re: Journal approximatif

            Posté par . Évalué à 5.

            systemd est bien plus léger et économe !
            1° On évite de faire appel au shell pour chaque service (et vas-y que je fais une nouvelle instance du shell et un double fork, youhou !)
            2° On évite de prendre 30 ans pour démarrer ou s'arrêter
            3° On évite de répéter du code dans 10 000 scripts shell, ce qui fait perdre du temps à tout le monde, à la fois en amont (développement de ces scripts) et en aval (quand tout le monde exécute tout le code spaghetti)
            4° Je pourrais en citer d'autres, mais j'ai la flemme.

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

            • [^] # Re: Journal approximatif

              Posté par . Évalué à 2.

              Pour le point 2, OpenRC peut être plus rapide au démarrage que systemd.

              Pour le point 3, je suis totalement d'accord et je n'ai jamais compris pourquoi on avait conçu des trucs aussi compliqué pour lancer des choses simples.

      • [^] # Re: Journal approximatif

        Posté par . Évalué à 3.

        Tout comme ça serait sûrement très pratique que 'systemd' fasse le café.

        Ça n'aurait rien à voir avec systemd.

        Est-ce intelligent pour autant ? Non.

        Non, en effet.

        Ce n'est pas parce qu'on peut le faire qu'on doit le faire.

        C'est bien pour ça que chaque changement de systemd est justifié (il suffit de fouiller un peu)

        Visiblement certains semblent oublier pourquoi les *NIX ont réussi à devenir des OS de référence et à tenir la distance depuis tant d'années.

        La stagnation, c'est l'avenir !

        Une de ces raisons, c'est qu'on a segmenté les tâches simples sous formes de briques assemblables et indépendantes, plutôt que de tout mettre dans un gros ensemble qui ferait tout et sur lequel tout reposerait.

        Change vite d'OS, ça fait plus de vingt ans que Linux (le *NIX majoritaire depuis 15 ans au moins) utilise un gros noyau monolithique.

        Ca fait 40 ans qu'on aurait pu écrire un 'systemd'.

        Pas vraiment. D'abord, pour avoir systemd il faut linux. Aussi, systemd aurait été plus difficile avec 16 Kio de mémoire (la taille de la mémoire vive du premier IBM PC), AMHA.

        Si ça n'a pas été fait c'était pour de bonnes raisons

        Lesquelles ?

        Par pitié, dis moi pourquoi on devrait encore se taper SysV, lequel ne sait même pas te dire de manière fiable si un service est vraiment démarré.

        les vieilles recettes sont parfois les meilleures.

        Les vielles recettes puent. Quand on copie/colle du code shell mal fichue pendant 40 ans plutôt que d'arrêter de re-faire le même boulot des milliers de fois :
        1) soit on a la foi
        2) soit on est stupide

        Et c'est parce qu'on sait quand savoir évoluer, qu'on a eu bien d'autres systemd-like avant systemd (qui ne fait que réunir le meilleur des systemd-like qui sont apparus avant lui).

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

        • [^] # Re: Journal approximatif

          Posté par . Évalué à 2.

          Ça n'aurait rien à voir avec systemd.

          Tout comme systemd n'a pas grand chose à voir avec une des règles de base d'UNIX malheureusement, à savoir la séparation de tâches simples en briques logicielles indépendantes.

          La stagnation, c'est l'avenir !

          J'ai dit "Il y a des fois où il faut savoir faire marche arrière et se dire que les vieilles recettes sont parfois les meilleures". Pas "Maintenons le statu quo". Parfois, oui, il vaut mieux refuser certaines évolutions qui en réalité amènent autant de problèmes qu'elles n'en résolvent. Ce qui ne veut pas dire qu'il ne faille rien faire pour améliorer par exemple OpenRC.

          Change vite d'OS, ça fait plus de vingt ans que Linux (le *NIX majoritaire depuis 15 ans au moins) utilise un gros noyau monolithique.

          C'était même tellement bien qu'on a été obligé de créer une v2 de Linux pour y ajouter des modules.

          Pas vraiment. D'abord, pour avoir systemd il faut linux. Aussi, systemd aurait été plus difficile avec 16 Kio de mémoire (la taille de la mémoire vive du premier IBM PC), AMHA.

          C'est bien tout le coeur du problème : pour avoir systemd, il ne faut que Linux.

          Lesquelles ?

          Ca fait 3 fois que je l'écris dans ce fil mais je vais le redire : séparer des tâches en briques logicielles indépendantes. C'est un des concepts de base de la programmation système sous les *NIX, j'en veux pour référence cet excellent ouvrage : http://www.oreilly.com/openbook/linuxdrive3/book/

          Les vielles recettes puent. Quand on copie/colle du code shell mal fichue pendant 40 ans plutôt que d'arrêter de re-faire le même boulot des milliers de fois :
          1) soit on a la foi
          2) soit on est stupide

          Je te rejoins totalement sur ce point. Mais si c'est remplacer un truc qui pue par un truc moisi, non merci, je préfère encore conserver l'ancien truc en bossant sur un système correct qui viendra le remplacer plus tard (je pense à OpenRC).

          Et c'est parce qu'on sait quand savoir évoluer, qu'on a eu bien d'autres systemd-like avant systemd (qui ne fait que réunir le meilleur des systemd-like qui sont apparus avant lui).

          Par évolution, j'entendrais quelque chose comme "contribuer à l'existant pour le rendre vraiment meilleur", plutôt que de prendre plein de fonctionnalités et de les agréger en un ensemble de briques pas indépendantes qu'on aura entièrement recodées. Plutôt que de faire un peu de vérification de système de fichiers + un peu de parefeu + un peu de ceci et un peu de cela, systemd ferait bien de ne faire que l'initialisation. Ou s'il veut tout faire, qu'il ait au moins la gentillesse de séparer les briques logicielles de façon indépendantes, qu'on puisse remplacer chaque élément par un autre si l'on préfère. Mais ce n'est pas du tout la logique adoptée ici, et c'est je crois ce qui pose problème à tant de personnes.

          • [^] # Re: Journal approximatif

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

            C'est bien tout le coeur du problème : pour avoir systemd, il ne faut que Linux.

            Je pense au contraire que dans le cas précis du système d’init et de l’espace utilisateur bas niveau, c’est plutôt une qualité (pouvoir profiter de toutes les fonctionnalités de Linux).

            Je te rejoins totalement sur ce point. Mais si c'est remplacer un truc qui pue par un truc moisi, non merci, je préfère encore conserver l'ancien truc en bossant sur un système correct qui viendra le remplacer plus tard (je pense à OpenRC).

            Ça tombe bien, c’est que les gens ont fait et on finit par se décider sur systemd après avoir vu passer init-ng, le système de Pardus (qui n’ont pas marché), Upstart (qui est mort), OpenRC, etc.

            Dire que systemd est pourri, c’est remettre en question les compétences de tous ceux qui ont choisi systemd, à savoir à peu près toutes les distributions sauf Slackware et Gentoo par défaut.

            […] qu'il ait au moins la gentillesse de séparer les briques logicielles de façon indépendantes, qu'on puisse remplacer chaque élément par un autre si l'on préfère. Mais ce n'est pas du tout la logique adoptée ici, et c'est je crois ce qui pose problème à tant de personnes.

            On ne peut pas utiliser la plupart des composants de systemd sans systemd, mais on peut se passer de pas mal de composants. Certes, ça n’est pas aussi flexible qu’avant, mais je n’ai pas l’impression que cela pose des problèmes concrètement.

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

            • [^] # Re: Journal approximatif

              Posté par . Évalué à 3.

              Dire que systemd est pourri, c’est remettre en question les compétences de tous ceux qui ont choisi systemd, à savoir à peu près toutes les distributions sauf Slackware et Gentoo par défaut.

              1) Malgré ça, on assiste à des développeurs Debian officiels qui créent un fork ;

              2) "Ce n'est pas parce qu'ils sont une majorité à avoir tort qu'ils ont raison", pour reprendre Coluche. Entendre par là : je tiens à me faire ma propre opinion, même si le meilleur programmeur du monde me dit que j'ai tort, car c'est comme ça que je comprendrai pourquoi j'ai tort (ou lui éventuellement, ça arrive…).

              • [^] # Re: Journal approximatif

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

                Je vois pas le rapport, y’a une différence entre dire que c’est pourri et dire que c’est pas satisfaisant, que ça ne nous plait pas, etc.

                D’autre part, imaginons que systemd soit génial, ils peuvent forker quand même ça veut pas dire que systemd est mauvais, juste que ça ne correspond pas à leur vision des choses.

                Les gens qui disent que systemd est pourri c’est typiquement le genre de choses qui fait la bonne ambiance des discussions sur le sujet, et c’est dommage.

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

                • [^] # Re: Journal approximatif

                  Posté par . Évalué à 4.

                  ils peuvent forker quand même

                  https://linuxfr.org/news/pourquoi-les-zelateurs-et-detracteurs-de-systemd-ne-s-entendront-jamais#%C3%89crire-une-alternative

                  Je crois qu’on pourrait refaire (en mieux) toutes les discussions de systemd de DLFP rien qu’en copiant collant cet article. On pourrait pas s’arrêter un jour ?

                  Ça sert à quoi de relancer des débats stériles encore et encore, toujours avec les mêmes arguments ? Tu espères vraiment voir de nouvelles choses se dire ?

                  • [^] # Re: Journal approximatif

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

                    • Je dis que dénigrer (pas critiquer hein, dénigrer) systemd c’est aussi insulter toutes les gens compétents pour gérer toute la distributions (sauf le système d’init bien entendu…).
                    • On me dit ouais mais les gens forkent Debian pour pas avoir systemd et que la majorité n’a pas forcément raison (rapport avec la choucroute?).
                    • Je dis que s’ils forkent Debian c’est pas que systemd est pourri mais que ça ne correspond pas à leurs attentes. En insistant bien sur mon argument initial qui était, dénigrer systemd c’est bien pour déclencher des discussions de merde (ce qui semble se confirmer).
                    • On me cite, une phrase complètement hors-contexte, et on me réponds que j’ai dit qu’il n’ont qu’à forker s’ils ne sont pas contents et on m’accuse de lancer des débats stériles (sérieux?).

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

                    • [^] # Re: Journal approximatif

                      Posté par . Évalué à 2. Dernière modification le 23/01/15 à 08:57.

                      Bon j'arrive après le débat, mais bon…
                      Après faut aussi voir que certains "antis" sont contre l'implémentation qui est systemd mais pas forcement contre l'idée de systemd. La simplicité, dépendances, …(mettre ici tous les arguments des "pros") sont des très bonnes idées par contre la façon de faire; monolithique, NIH, (mettre ici tout les arguments des "antis") sont pour la plupart des points noirs du projet.

                      • [^] # Re: Journal approximatif

                        Posté par . Évalué à 2. Dernière modification le 23/01/15 à 09:09.

                        L'aspect NIH est à prouver.

                        Quant à l'aspect monolithique, ce n'est pas un mauvais point en soit (Linux, Xorg, Firefox, etc… sont plutôt monolithiques)

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

                        • [^] # Re: Journal approximatif

                          Posté par . Évalué à 1.

                          Je pense notamment au DHCP(http://www.phoronix.com/scan.php?page=news_item&px=MTY1Mjc). Alors on va me sortir qu'ils n'ont pas trouvé de bibliothèque avec toutes les fonctionnalités, que c'est un petit truc, ou autres. Mais ils auraient pu très bien apporter leurs contributions à un projet existant. Après c'est peut être le seul cas dans systemd…
                          Pour l'histoire du monolithique je reprenais un argument, en outre il me dérange pas, c'est plus l'aspect "tout les oeufs dans le même panier" qui me dérange

                      • [^] # Re: Journal approximatif

                        Posté par . Évalué à 5. Dernière modification le 23/01/15 à 10:44.

                        mais pas forcement contre l'idée de systemd

                        Mal dit.

                        Pas forcément contre l’idée de systemd-le-système-de-gestion-de-services (cf uselessd), mais contre systemd-le-projet-pour-les-amener-tous-et-dans-les-ténèbres-les-lier (tous = tous les composants système bas niveau). Ça n’a pas grand chose à voir avec l’implémentation.

                        M’enfin encore une fois tout ça a été déjà dit et en mieux dans le gros article lié plus haut.

Suivre le flux des commentaires

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