Journal yet another journal about systemd

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
26
6
sept.
2012

Bonjour, suite aux différents trolls commentaires à propos de systemd dans les différents journaux (dernier en date celui sur LFS) je voulais aborder quelques points et questions qui me tracassent à ce propos.

Avant toute chose, je tenais à souligner que je ne suis que développeur et pas administrateur système, et donc en ce qui concerne le système d'init je ne suis qu'utilisateur, je n'ai aucune idée de comment ça fonctionne et ça m'intéresse pas franchement.

Cependant, regardant systemd, les questions suivantes me tracassent:

  • Si c'est aussi contesté, pourquoi toutes les distributions y passent? (Je veux dire, avant l'actuelle intégration de udev qui semble compliquer les choses si on veut s'en passer) Il y a des tas d'outils géniaux qui ne sont pas repris d'une distribution sur l'autre, et là on voudrait me faire croire qu'un truc qui est loin de faire l'unanimité s'est retrouvé en si peu de temps maintenu, packagé et imposé dans toute distrib grand public? Je veux dire, Gnome 3 me plaît pas, je l'utilise pas et j'ai pas de soucis. Pourquoi n'en est-il pas de même pour systemd?
  • Si il y a autant de gens qui savent ce qui ne va pas dans systemd, pourquoi ne travaillent-ils pas ensemble pour faire quelque chose qui va? Je veux dire, on parle partout de l'ancien système et du nouveau, quand on voit le nombre de navigateurs libres, ça parait étrange qu'il n'y ai ici que deux softs en compétition…
  • J'ai vu pas mal de critiques du genre "systemd impose ci, systemd impose ça", ou "on ne peut plus faire telle chose avec systemd, ou en tout cas plus de telle manière", tout ça me donne une image très "fermée" de systemd, autrement dit pas modulaire. Systemd n'est pas modulaire du tout? Il est si difficile de l'étendre en ajoutant des fonctionnalités, de compiler en virant les parties qui plaisent pas, etc? Aussi, n'y a-t-il aucune chance/possibilité qu'il devienne plus modulaire à l'avenir? (sous-entendu est-il pourri jusqu'à la racine ou peut-il être amélioré au cours des versions pour devenir quelque chose de bien)
  • Certains critiquent aussi le fait que ce soit compatible uniquement avec Linux, d'une part j'ai du mal à voir à quel point c'est vrai (il n'y a aucune chance de l'adapter à un autre noyau?), d'autre part en quoi est-ce un problème, ce n'est ni le dernier ni le premier des softs qui ne sont pas multi-plateformes, et si c'est si critiqué pourquoi les autres noyaux en voudraient?

Bref, comme Zenitram le souligne parfois, c'est libre, si ça ne vous plaît pas pourquoi vous en préoccuper?
Si Lennart avait vraiment pondu un truc pourri, il ne serait pas utilisé, là tout le monde l'utilise tout en le critiquant copieusement, ça me laisse perplexe.

PS: En tant qu'utilisateur, je ne compte pas changer de système d'init manuellement si ce n'est pas nécessaire, par contre à la prochaine installation je prendrais le truc installé par défaut par la distribution que j'installerai, peu importe ce que c'est…

  • # RH

    Posté par  . Évalué à 10. Dernière modification le 06 septembre 2012 à 16:57.

    Il se trouve que une boite a un poid preponderant dans le monde linux et qui pese donc enormement sur les decisions techniques bien souvent prise de facon unilateral. Cette boite est aussi l'employeur de l'auteur de systemd, c'est aussi la boite qui est majoritairement derriere Gnome.

    Cette boite n'a jamais supporte KDE, d'ou la creation de mandrake, et donc les devs ont parfois (souvent) du mal a ecouter les autres devs (voir le nombre de technos KDE qui ont ete refuse puis reprise en plus mal comme DCOP transforme en DBUS) et ne parlons meme pas des utilisateurs desktop.

    Apres certes on ne peut pas nier leur contribution mais bon putain la communication c'est tres tres loin d'etre le fort de cette boite sauf pour dire a posteriori : "on a pondu ca maintenant tout le monde doit y passer". Parfois ils ont raisons, parfois non mais surtout ce comportement a un peu le don d'herisser le poil des autres devs.

    • [^] # Re: RH

      Posté par  . Évalué à 10.

      Depuis que cette boîte est hégémonique, toutes les distribs utilisent le format de paquets rpm et le gestionnaire de pacquets yum…..

    • [^] # Re: RH

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

      Ma foi, j'aimerais bien voir un mail ou il est marqué "vous passerez à systemd ou on butte le chien", si possible en anglais, et qui a décidé par exemple opensuse ou mageia à le faire. ( parce que globalement, c'est ce que tu décrit, et j'ai pas vu passer ce genre de mail, les gens ont choisit volontairement de basculer que je sache ).

      Par exemple, pour Opensuse, est ce que quelqu'un s'est plaint de pression de la part d'une autre boite ? Est ce que tu as , genre, des preuves, des mails publiques ?

      Tu fais aussi abstraction des discussions qu'il y a eu sur Fedora, sur Mageia, sur openwrt en toute transparence sur le passage ( ce qui ma foi, ne me parait pas faire preuve de beaucoup de rigueur dans l'hégémonie, mais bon, c'est bien connu que soit on est d'accord avec une décision technique, soit les devs et les packageurs sont des cryptofachistes doublés d'incapables de voir la vérité et de coder ).

      Tu fais abstraction du fait que les devs de arch ont discuté de ça. Tu fais abstraction du fait que quand Fedora est passé à upstart, personne n'a ralé ( alors que upstart n'est pas compatible bsd, dépend de dbus, change les outils en ligne de commandes, n'utilise pas du tout de shell et fait juste moins de choses que systemd ). Et que upstart avait prévu de remplacer cron, at ( http://upstart.ubuntu.com/faq.html#replace-cron ), ce qui n'a fait bondir personne.
      Au passage, personne n'a suivi, alors que pourtant, RHEL 6 utilise upstart.

      Donc tu peux sans doute expliquer pourquoi un truc utilisé par Ubuntu, RHEL/Centos, et Fedora pendant un temps est vu comme moins hégémonique qu'un truc utilisé au début juste par Fedora ?

      • [^] # Re: RH

        Posté par  . Évalué à 5.

        Ma foi, j'aimerais bien voir un mail ou il est marqué "vous passerez à systemd ou on butte le chien"

        tu n'as pas bien lu, il etait ecrit:

        Ma foi, j'aimerais bien voir un mail ou il est marqué "vous passerez à systemd car on mange udev"

      • [^] # Re: RH

        Posté par  . Évalué à 10.

        Ma foi, j'aimerais bien voir un mail ou il est marqué "vous passerez à systemd ou on butte le chien", si possible en anglais

        S'il n'y a que ça pour te faire plaisir…

  • # Trop d'honneurs...

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

    Je vais prendre la grosse tête à force d'être cité.

    Bon, pour une des questions, j'aurai bien une réponse :

    Si il y a autant de gens qui savent ce qui ne va pas dans systemd, pourquoi ne travaillent-ils pas ensemble pour faire quelque chose qui va?

    On te répondra certainement que c'est parce que le système actuel est parfait, mais bon, ma réaction serait d'être surpris que si c'est parfait, il n'y a pas de raison de faire systemd par les autres, pas logique. Moi j'ai plutôt l'impression que :
    - Dès que ça a du succès (Windows, Ubuntu, systemd…), on est jaloux
    - Résistance au changement
    - Troller en sortant n'importe quoi comme idée de critique est plus rigolo que de se mettre autour d'un table, mettre le plus de monde possible d'accord (partie la plus dure), et coder. Lennart a réussi à mettre pas mal de monde d'accord et a codé. Lui. (2 sur 3, certes, mais 2 de mieux que les autres. Je ne sais pas si il y a eu une table avant)

    • [^] # Re: Trop d'honneurs...

      Posté par  . Évalué à 9.

      On te répondra certainement que c'est parce que le système actuel est parfait

      Perso, je l'ai toujours trouvé ultra pourri le système d'init actuel…

      Il a quoi de si génial ?
      Pourquoi, si je veux juste démarrer un truc avec ma machine, il faut que je fasse un scripte qui gère 5 (ou 6 ?) paramètres différents (start, stop, restart, …) et en faire des liens complètement abscons dans d'autres dossiers avec comme seul ordre pour déterminer à quel moment il sera exécuté….. l'ordre alphabétique du système de fichier ??????

      Ensuite, c'est quoi ces histoires de runlevel à la con ??? géré par des chiffres qui n'ont aucun sens ? (différents entre les distrib au passage) et limité à 9 en plus (d'ailleurs c'est vraiment limité à 9 ou c'est juste mon impression ?) ???
      Et pour le passage de l'un a l'autre, on coupe tout et on relance tout ?? ça serait pas possible de juste gérer le delta ??

      Et un point marquant que je lui trouve, c'est qu'il y a des différence notables entre chaque distributions sur comment il fonctionne. C'est bien qu'il y avait des problèmes à la base, et que chaqun ait ses propres solutions, c'est bien que la solution n'est pas simple.

      Et j'effleure juste la surface en tant qu'utilisateur de ma machine là.

      Je sais pas si systemd est bien ou pas, mais l'init actuel, pour moi, il est juste vraiment moisi…

      • [^] # Re: Trop d'honneurs...

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

        en faire des liens complètement abscons dans d'autres dossiers avec comme seul ordre pour déterminer à quel moment il sera exécuté….. l'ordre alphabétique du système de fichier ??????

        Tes infos datent un peu, aujourdh'hui on a les en-têtes de méta-infos LSB pour indiquer les dépendances et les niveaux d'exécutions où il doit être démarré et arrêté. Les liens sont créés par update-rc.d.

        Et pour le passage de l'un a l'autre, on coupe tout et on relance tout ??

        Non. On ne relance pas tout.

        • [^] # Re: Trop d'honneurs...

          Posté par  . Évalué à -1.

          Tes infos datent un peu, aujourdh'hui on a les en-têtes de méta-infos LSB pour indiquer les dépendances et les niveaux d'exécutions où il doit être démarré et arrêté. Les liens sont créés par update-rc.d

          Ha oui, je viens de voir ça.
          Mais pourquoi des liens sont toujours crées si les niveaux d'exécution sont spécifiés dans l'entête ?

          Non. On ne relance pas tout.

          Alors si je ne dis pas de bêtises. Quand je suis en runlevel 2, si je fais init 3, j'appelle tous les scripts qui sont dans rc2.d avec le paramètre "stop" puis ceux de rc3.d avec le paramètre start.

          En sachant que si je fais ça, c'est que généralement, j'ai un ou deux services qui changent, donc 95% des services sont identiques.
          C'est pas super génial comme idée je trouve. Le mieux aurait été de n'arrêter que ceux qui sont dans 2 et pas dans 3 et de ne démarrer que ceux qui sont dans 3 et pas dans 2.
          C'est possible de faire ça ?

          • [^] # Re: Trop d'honneurs...

            Posté par  . Évalué à 4.

            Heu… quand tu passe du runlevel 2 au runlevel 3, tu lances juste les scripts censés s'exécuter au runlevel3.

        • [^] # Re: Trop d'honneurs...

          Posté par  . Évalué à 9.

          Les liens sont créés par update-rc.d.

          Ça c'est pour Debian. Les distribs type RPM, c'est chkconfig.

          Tu viens de prouver que rien n'est unifié.

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

      • [^] # Re: Trop d'honneurs...

        Posté par  . Évalué à 4.

        Pourquoi, si je veux juste démarrer un truc avec ma machine, il faut que je fasse un scripte qui gère 5 (ou 6 ?) paramètres différents (start, stop, restart, …) et en faire des liens complètement abscons dans d'autres dossiers avec comme seul ordre pour déterminer à quel moment il sera exécuté….. l'ordre alphabétique du système de fichier ??????

        Quelqu'un a un tuto, une doc, une spécification, qui indique comment on fera avec systemd ?

        Puisqu'on en est à comparer :)

        C'est vrai qu'écrire un script pour init n'est pas motivant.

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

        • [^] # Re: Trop d'honneurs...

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

          Pour l'avoir fait, écrire un fichier service pour systemd est assez simple (plus simple qu'un initscript en tout cas).
          http://0pointer.de/blog/projects/systemd-for-admins-3.html

          on passe de ça :
          http://svnweb.mageia.org/packages/cauldron/dnsmasq/current/SOURCES/dnsmasq.init?revision=42235&view=markup
          à ça :
          http://svnweb.mageia.org/packages/cauldron/dnsmasq/current/SOURCES/dnsmasq.service?revision=254453&view=markup

          (le fichier initscript est spécifiquement complexe en tripliquant la configuration, j'en ai profité pour ne garder que 2 endroits).

          • [^] # Re: Trop d'honneurs...

            Posté par  . Évalué à -1.

            ah c'est compliqué un script qui fait un case sur $1 et qui gère "start" et "stop" ?
            si c'est trop compliqué, peut être qu'il faut changer l'administrateur, pas le système d'init

            • [^] # Re: Trop d'honneurs...

              Posté par  . Évalué à 8.

              Le boilerplate c'est pourri et ça doit disparaître, vive la concision et la lisibilité. En plus, si un conservateur est vraiment motivé, je suis sûr qu'il est possible d'écrire en shell posix un parser de .ini à la systemd. Pénible, mais possible, pour prouver que le shell posix est un si bon langage de programmation.

            • [^] # Re: Trop d'honneurs...

              Posté par  . Évalué à 5.

              ah c'est compliqué un script qui fait un case sur $1 et qui gère "start" et "stop" ?

              Figure toi que j'en ai un qui fait "juste" ça.
              Et qu'à chaque mise à jour de init-je-sais-plus-quoi sur ma debian, j'ai des warnings m'indiquant que le script de démarrage n'est pas LSB compliant, que c'est mal (tm) et qu'à cause de ça, il ne peut pas passer à un système d'init basé sur des dépendances qui est trop bien.

              Donc même si c'est pas compliqué, ça reste pas suffisant pour avoir un truc propre dans ton démarrage.

              Ensuite, change l'administrateur… Ça aurait pu être là solution, s'il y en avait un. Moi, je suis utilisateur de ma machine.

              Dernier point, si c'est si simple et si facile, pourquoi les scripts de démarrage sur ma machine font-ils tous en moyenne 100 lignes (ça va de 33 à 408 !!) Et en plus avec des paramètres dans des fichiers extérieurs (ce que je comprends très bien, mais ça fait des lignes en plus et c'est pas toujours évident à trouver)

              • [^] # Re: Trop d'honneurs...

                Posté par  . Évalué à 1.

                le lsb-compliant c'est que tu indique dans les commentaires les dépendances.
                Si ton script n'a pas dans ses commentaires les dépendances dont il dépend, normal qu'il ne puisse pas passer à une gestion des scripts d'init par dépendances vu que tu ne les lui spécifie pas.

                Mais rassure moi sous systemd, tu lui spécifie quand tu veux qu'il démarre non?
                Sous les script init c'est la même chose.

                Donc j'oubliais, faire un case $1, et faire 3 lignes de commentaire à la bonne syntaxe (en s'inspirant d'un autre script par ex) , si tu trouves que c'est vraiment trop dur arrête l'admin système.

                • [^] # Re: Trop d'honneurs...

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

                  En fait, c'est la même diffrence qu'entre java et python. java, faut rajouter toujours le même boilerplate pour les trucs simple, genre un hello world.

                  Ou la différence du xml et un DSL parfaitement prévu pour. Si tu commences à faire du copier coller, y a 2 choses :
                  - tu va jamais avoir besoin de toucher à ça, donc tu gaspilles juste de l'espace et tu rajoutes du bruit, autant faire un système qui retire tout ( ce que gentoo ou plf ont fait, par exemple )
                  - tu va devoir toucher au code un jour, et la, bah tu as juste des centaines de copies, et tu as fait de la merde

                  Donc dans les 2 cas, ça pose problème.

                  • [^] # Re: Trop d'honneurs...

                    Posté par  . Évalué à 1.

                    alors j'aimerais que tu m'explique en quoi tu n'as pas besoin de toucher les dépendances dans ton boilerplate…

                    Oui tu as besoin d'y toucher pour chaque script, mais non ton boilerplate ne vas pas changer "un jour" vu que les noms utilisés sont normalisés.
                    A la rigueur tu vas rajouter qqch, mais les scripts existant n'auront pas besoin d'être touchés.

                    • [^] # Re: Trop d'honneurs...

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

                      Je crois que le souci est qu'on a pas l'air d'accord sur le mot "boilerplate", donc je vais donner ma définition, puis toi la tienne, et la, je vais pouvoir répondr eà ta question, car la, je la comprends pas.

                      Pour moi, le boilerplate, c'est tout les trucs inutiles que tu est obligé de copier partout mais que tu ne touche pas

                      Dans le cas d'un script d'init, c'est :
                      - la déclaration ". /etc/init.d/functions" ou équivalent, qu'on retrouve partout
                      - le gros case pour la lecture des arguments,
                      - la fonction restart, qui, sauf cas particulier, fait toujours start, stop
                      - la gestion des pids, des lockfiles, etc qu'on refait tous à la main à chaque fois
                      - la fonction qui affiche les actions du script.

                      tout ça, c'est des trucs qui sont, à défaut d'être pareil partout tout le temps, souvent copié coller, et ce que j'appelle le boilerplate. Si jamais je veux pouvoir dire "je lance tel truc dans un chroot", l'architecture actuel a base de shell fait que ça va sans doute coincer ( entre les scripts qui utilise une fonction shell spécifique, et ceux qui le font pas , par exemple ).

                      Donc voila, à toi de me dire ce que tu appelles "boilerplate", et me dire ce que ta question veux dire.

              • [^] # Re: Trop d'honneurs...

                Posté par  . Évalué à -1.

                j'ai oublié de répondre aux autres points, mea culpa :

                Donc même si c'est pas compliqué, ça reste pas suffisant pour avoir un truc propre dans ton démarrage.

                oui, 3 lignes de commentaires en plus.

                Ensuite, change l'administrateur… Ça aurait pu être là solution, s'il y en avait un. Moi, je suis utilisateur de ma machine.

                Non, tu es administrateur de ta machine.
                Tu modifie le fonctionnement de ta machine, c'est un administrateur qui le fait, pas un utilisateur.
                Comme tu te met en tant qu'"utilisateur" tu n'as pas envie de faire la recherche minimum pour faire ce que tu veux. (mais les scripts d'ini de systemd tu les inventes du chapeau ?)
                C'est pas un mal, mais râle pas quand ça fait pas ce que tu veux parce tu ne veux pas faire ce qu'il faut.

                Si tu étais utilisateur, tu n'aurais pas le droit de modifier ces scripts.

                C'est exactement le même problème qu'on avait sous windows, des "utilisateurs" qui étaient persuadé d'être des administrateurs sans faire la moindre recherche et oh leur machine était pété au bout de 6 mois.

                linux est plus résilient que windows, mais modifier le système sans prendre le temps de comprendre ce qu'on fait (et que ce soit avec l'init standard, le dependency-based ou systemd, même cause même conséquence) ne te méneras que des problèmes.

                Dernier point, si c'est si simple et si facile, pourquoi les scripts de démarrage sur ma machine font-ils tous en moyenne 100 lignes (ça va de 33 à 408 !!) Et en plus avec des paramètres dans des fichiers extérieurs (ce que je comprends très bien, mais ça fait des lignes en plus et c'est pas toujours évident à trouver)

                parce qu'un script qui est distribué dans une distrib a certaines règles a respecter pour s'intégrer correctement (par exemple que tous les scripts aient les mêmes jolis "ok" vert, et pas l'un entre crochet à la fin de la ligne, l'autre après un saut de ligne, un autre sans ok vert etc…)

                • [^] # Re: Trop d'honneurs...

                  Posté par  . Évalué à 5.

                  Donc j'oubliais, faire un case $1, et faire 3 lignes de commentaire à la bonne syntaxe (en s'inspirant d'un autre script par ex) , si tu trouves que c'est vraiment trop dur arrête l'admin système.

                  Et bien quand je l'ai écrit, ça c'était pas le cas. Car oui, je me suis bien inspiré des autres scripts.

                  Et je me considère toujours comme un utilisateur et pas un administrateur. Il se trouve que je suis aussi un développeur et j'ai j'ai codé un petit jouet que j'ai envie de démarrer sur ma machine.
                  Ça n'est pas un service ultra perfectionné de luxe (même si dans le principe, ça reste un service qui attends des requêtes depuis mon réseau interne)
                  Et je continue à trouver ça trop compliqué.
                  Un simple "lance cet exécutable avant le prompt de login" est suffisant pour moi, et ça devrait être une des fonctionnalité simple à utiliser d'un système de démarrage.

                  oui, 3 lignes de commentaires en plus.

                  C'est vrai que je n'ai jamais pris le temps de voir ce qui lui manquait, donc quelque part, c'est de ma faute, mais j'ai mis ce point pour souligner que ça n'est pas "3 lignes de script" mais plus que ça ! Et aussi que ça n'est pas si trivial que ça, avec des parties non cohérentes (entête non interprété par le shell dans un script shell)

                  Si tu étais utilisateur, tu n'aurais pas le droit de modifier ces scripts.

                  Si j'avais pu faire démarrer mon utilitaire sans avoir à ajouter un script, je l'aurais fait avec plaisir. C'est le système qui me force à cela.
                  Moi j'aurais aimé un outil avec une syntaxe du genre :

                  "#>execute_ce_binaire_au_démarrage_de_la_machine --c_est_un_demon_alors_inutile_d_attendre_qu_il_termine --si_tu_peux_le_relancer_quand_il_plante_ça_m_arrangerait /chemin/vers/mon/binaire"

                  Et il se serait chargé de créer la config qui va bien pour ça.

                  avec des commandes qui me disent ce que est déjà dans la liste de lancement (pas tous les services, mais juste ceux que j'ai ajouté via cette commande), ceux qui tournent, me permettre de les arrêter, les relancer, de les virer.
                  J'ai l'impression qu'il y a presque tout déjà, mais qu'il faut un enrobage énorme de shell autour et que le binaire en question ait quelques bons goûts dans sa façon de fonctionner pour que ça se passe comme on veut.

                  Au fait, ma machine (principale) n'est pas pétée au bout de 6 mois ! je ne l'ai réinstallée qu'une seule fois récemment pour passer en arch amd64.

                  parce qu'un script qui est distribué dans une distrib a certaines règles a respecter pour s'intégrer correctement (par exemple que tous les scripts aient les mêmes jolis "ok" vert, et pas l'un entre crochet à la fin de la ligne, l'autre après un saut de ligne, un autre sans ok vert etc…)

                  La complexité pour ces choses ne devrait pas être dans les script, mais dans l'init.
                  En tant que développeur, si je veux que tous les utilisateurs de ma lib se comportent bien, je ne leur laisse pas la possibilité de mal se comporter.
                  C'est un peu comme les histoires de mutlitâche préemptif et coopératif, on est bien d'accord que le coopératif est une vaste fumisterie…

                  • [^] # HS

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

                    Il se trouve que je suis aussi un développeur et j'ai j'ai codé un petit jouet que j'ai envie de démarrer sur ma machine.

                    Et dire que sous Windows il suffit de mettre un bête lien dans le répertoire "démarrage" au simple niveau de l'utilisateur… Bien plus simple qu'init.d ou systemd! Pourquoi faire simple quand on peut faire compliqué :).

                    • [^] # Re: HS

                      Posté par  . Évalué à 3.

                      ça j'aurais pu le faire avec le démarrage de ma session.
                      les 2 soucis que j'ai c'est que :

                      1) je veux que ça tourne même quand je ne suis pas logué

                      2) mon jouet lance certaines commandes depuis des requêtes sur le réseau, et pour lancer ces commandes il faut être root. (c'est pas sécurisé, plein de buffer overflow et autres joyeusetés…) donc à lancer en root.

                      Donc je n'ai pas trouvé d'autres moyens que de la lancer avec un script de démarrage.

                      • [^] # Re: HS

                        Posté par  (site web personnel) . Évalué à 3. Dernière modification le 07 septembre 2012 à 10:19.

                        Oui, bon, la, un script bash start/stop, même si c'est pas sexy, ne devrait pas te faire peur alors, l'argument ne tient plus.

                        • [^] # Re: HS

                          Posté par  . Évalué à 8.

                          Ça ne m'a pas fait peur ;) d'ailleurs je l'ai fait.

                          Mais j'ai trouvé ça compliqué et lourdingue !
                          De mon point de vu de développeur, c'est vraiment mal fichu !!
                          Mettre du code (script bash) dans de la config (ce qui doit être démarré, où et comment), je trouve ça très pourri comme design.
                          Après, peut-être que pour les adim de machine, c'est indispensable, mais j'aurais plutôt tendance à penser que c'est parce que le système d'init est très très incomplet, mal fichu et mal pensé, donc il délègue la complexité sur les fichier de config en les laissant gérer eux même la façon dont ils veulent faire les choses.

                          En tous cas, quand je code, la config, c'est de la config, il n'y a aucune logique dedans. Ensuite, l'appli lit et interprète la config, c'est elle qui sait comment bien faire les choses ! Séparer la logique des données est un concept de base dans le design d'un logiciel chez moi, et à chaque fois que j'ai prototypé un truc à la va vite et que je ne l'ai pas fait correctement, j'ai du revenir dessus par la suite.

                          • [^] # Re: HS

                            Posté par  . Évalué à 2.

                            tant qu'on est dans tous les petits fichiers, en system V tu as inittab aussi :) (avec respawn si on veut)

                    • [^] # Re: HS

                      Posté par  . Évalué à 7.

                      C'est possible aussi sous Linux : il suffit de mettre l'appel dans /etc/rc.local.

                      Mais ça ne répond qu'à la problématique « lancer un truc au démarrage », ça n'est pas un vrai service.

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

                    • [^] # Re: HS

                      Posté par  . Évalué à 1.

                      même chose sous linux, le répertoire dépend de ton environnement de fenêtre (ou ton .xinitrc)

                      Sauf que la tu parle d'un script lancé au démarrage d'une session, et pas un système windows.

                      C'est un poil plus compliqué d'insérer un script pour l'utiliser avec sc sous windows.

                      mais bon, comme à ton habitude, tu compare des choux et des navets.

                  • [^] # Re: Trop d'honneurs...

                    Posté par  . Évalué à -2.

                    Et je continue à trouver ça trop compliqué.

                    Si trois commentaire et un case c'est trop compliqué, du javadoc c'est quoi, l'himalaya …

                    C'est vrai que je n'ai jamais pris le temps de voir ce qui lui manquait, donc quelque part, c'est de ma faute, mais j'ai mis ce point pour souligner que ça n'est pas "3 lignes de script" mais plus que ça ! Et aussi que ça n'est pas si trivial que ça, avec des parties non cohérentes (entête non interprété par le shell dans un script shell)

                    Dans un sens je comprend.
                    De l'autre coté, le javadoc il est utilisé par les ide java pour stocker des métadonnées dans le code ?

                    Là tu as des métadonnées dans des commentaires dans un script shell.

                    le shell pour l'execution du service (stop/start/status/…) proprement dis, les commentaires pour les métadonnées (quel fonction fait quoi, le script doit se lancer quand, …)

                    Oui c'est un peu particulier, mais pas tant que ça, et ça se retrouve autre part.

                    Si j'avais pu faire démarrer mon utilitaire sans avoir à ajouter un script, je l'aurais fait avec plaisir. C'est le système qui me force à cela.

                    Non, c'est ta méconnaissance du système :
                    - /etc/inittab
                    - /etc/rc.local
                    …

                    Moi j'aurais aimé un outil avec une syntaxe du genre :

                    utiliser un outil quand un éditeur de texte suffit, ou comment se compliquer la vie.

                    La complexité pour ces choses ne devrait pas être dans les script, mais dans l'init.

                    Ca tombe bien ce sont des scripts d'init.

                    Si tu veux tu peux avoir des scripts "startup.sh" et "shutdown.sh" et avoir un script de démarrage générique.

                    Ne t'en déplaise : le système d'init est simple. Les scripts d'init sont simples.
                    Par contre, le système d'init doit s'adapter à tout.
                    Tu as le choix de faire une grosse usine a gaz, que tu sera obligé de mettre à jour tout le temps pour s'adapter à toutes les façons possible et imaginable de lancer un service ou un script.
                    Ca c'est le principe "télécom" au niveau réseau : l'intelligence au coeur du réseau (ton init), et des terminaux complètement idiots (scripts de démarrage)

                    le principe de linux, c'est le principe inverse (et c'est aussi le principe d'internet) :
                    un réseau "idiot" (init) et des terminaux intelligents (scripts).

                    On a vu quel architecture est la plus dynamique et la plus scalable.

                    alors oui ca demande un poil de motivation, mais honnêtement 2 arguments et trois commentaires, j'ai déjà eu plus de propblème.

                    Perso je suis sur un petit dev, et il faut comprendre le fonctionnement interne du co processeur etc…
                    Autrement plus compliqué que de voir 3 commentaires et 2 cases.

                    • [^] # Re: Trop d'honneurs...

                      Posté par  . Évalué à 6.

                      La question est plutot pourquoi tout le monde doit s'emboucanner a implementer un case (et pourquoi pas un if/else d'ailleurs?), et pourquoi on doit copier/coller le meme bouzin partout quand on peut faire un truc configuration driven qui va juste marcher.
                      Sans compter que ceux qui vont ecrire les scripts en question sont loin d'etre repute pour leur qualite de programmeur. Leur temps serait bien mieux employe a faire ce qu'ils font le mieux (l'administration) plutot que de perdre du temps a ecrire tout ca.
                      Et laisser des gens qui sont bien plus competent dans leur domaine gerer le bordel de la synchronisation des services me parait aussi un bonne utilisation du temps et des competences de chacun.

                      le principe de linux, c'est le principe inverse (et c'est aussi le principe d'internet) :
                      un réseau "idiot" (init) et des terminaux intelligents (scripts).

                      C'est un peu un comparaison foireuse, l'init n'a pas grand chose d'un réseau, je vois pas ce que l'analogie vient faire ici.

                      alors oui ca demande un poil de motivation, mais honnêtement 2 arguments et trois commentaires, j'ai déjà eu plus de propblème.

                      Multiplie par quoi, 30 a 40 services? C'est la que ca commence a poser des problemes.

                      Perso je suis sur un petit dev, et il faut comprendre le fonctionnement interne du co processeur etc…
                      Autrement plus compliqué que de voir 3 commentaires et 2 cases.

                      Oui, et certains bossent sur des centrales nucleaires et d'autres envoient des robots sur mars. C'est quoi ton point? Que parce que toi t'en chie sur des trucs durs tout le monde doit en chier pour des trucs qui pourraient etre simplifies et automatises?

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

                • [^] # Re: Trop d'honneurs...

                  Posté par  . Évalué à 4.

                  parce qu'un script qui est distribué dans une distrib a certaines règles a respecter pour s'intégrer correctement (par exemple que tous les scripts aient les mêmes jolis "ok" vert, et pas l'un entre crochet à la fin de la ligne, l'autre après un saut de ligne, un autre sans ok vert etc…)

                  Généralement il utilise la lib fournie pas la distro pour faire ça…

              • [^] # Re: Trop d'honneurs...

                Posté par  . Évalué à 2.

                Moi, je suis utilisateur de ma machine.

                Et ta machine n'a pas d'administrateur ? Personne n'en fait la maintenance ? C'est dangereux une machine pas entretenue, si tu la connectes à Internet. (Oui, comme une voiture sur laquelle personne n'ouvre le capot, et qui circule sur route ouverte, j'ose la comparaison).

                THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

                • [^] # Re: Trop d'honneurs...

                  Posté par  . Évalué à 3.

                  Je la maintiens à jour, de la à me considérer comme un administrateur…

                  • [^] # Re: Trop d'honneurs...

                    Posté par  . Évalué à 3.

                    Je ne m'estime pas un pilote de F1, pourtant quand je conduis une voiture, j'agis en tant que conducteur, pas en tant que passager.

                • [^] # Re: Trop d'honneurs...

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

                  Et ta machine n'a pas d'administrateur ? Personne n'en fait la maintenance ?

                  L'avantage des distros Linux, si on reste dans les repos, c'est que l'admin, c'est le mainteneur de la distro qui fait ça gratos pour toi. L'utilisateur n'a rien à faire.

          • [^] # Re: Trop d'honneurs...

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

            Elle est où la gestion des paramètres du script init original, à savoir :

            # change this line if you want dnsmasq to serve an MX record for
# the host it is running on.
MAILHOSTNAME=""
# change this line if you want dns to get its upstream servers from
# somewhere other that /etc/resolv.conf
RESOLV_CONF=""
# change this if you want dnsmasq to cache any "hostname" or "client-hostname" from
# a dhcpd's lease file
DHCP_LEASE="/var/lib/dhcp/dhcpd.leases"
DOMAIN_SUFFIX=`dnsdomainname`

            Ainsi que :

            if [ ! -z "${MAILHOSTNAME}" ]; then
OPTIONS="$OPTIONS -m $MAILHOSTNAME"
fi
if [ ! -z "${RESOLV_CONF}" ]; then
OPTIONS="$OPTIONS -r $RESOLV_CONF"
fi
if [ ! -z "${DHCP_LEASE}" ]; then
OPTIONS="$OPTIONS -l $DHCP_LEASE"
fi
if [ ! -z "${DOMAIN_SUFFIX}" ]; then
OPTIONS="$OPTIONS -s $DOMAIN_SUFFIX"
fi

            ?

            • [^] # Re: Trop d'honneurs...

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

              Comme je l'ai précisé initialement, je l'ai enlevé. Avec l'initscript il était possible de configurer dans dnsmasq.conf, dans /etc/sysconfig/dnsmasq (qui utilisait les mêmes variables) et dans le script lui même. Les 2 dernières conf étant passé en argument au lancement.

              J'ai simplifié en supprimant la conf dans le script d'init (il y a un message lors de la mise à jour) et en ne conservant que le fichier dans sysconfig (sourcé) et le fichier de conf.

        • [^] # Re: Trop d'honneurs...

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

          Pour systemd :
          http://patrakov.blogspot.fr/2011/01/writing-systemd-service-files.html

          Pour un initscript mandriva
          http://wiki.mandriva.com/en/Development/Howto/Initscripts

          Pour gentoo :
          http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=4#doc_chap4

          Je suis sur que tu peux trouver pareil pour le reste.

    • [^] # Re: Trop d'honneurs...

      Posté par  . Évalué à 1.

      On te répondra certainement que c'est parce que le système actuel est parfait,

      On t'a déjà répondu ça ?
      Ah oui, jamais.
      Comme quoi tu es toujorus d'aussi mauvaise foi .

      Alors pourquoi pas systemd ?
      Parce que ca répond à de mauvaise question de mauvaise facon (si la compatibilité ca nous interesse. Non on a pas envie d'un démon qui gère tout car le jour ou il y a problème ca pose un problème, oui on veut du kiss et pas une usine a gaz et non a pas envie d'un autre pulseaudio qui ne fait que cache misère et rajoute plus de problème qu'il n'en corrige).

      • Dès que ça a du succès (Windows, Ubuntu, systemd…), on est jaloux
        Ah on est jaloux ?
        Mais reste sur ton windows ca ne me gêne pas.
        Moi je suis sur ma deb et ca me convient parfaitement. Et honnêtement ubuntu, moins je la touche mieux je me porte (enfin surtout gnome )

      • Résistance au changement
        Il y a certainement une part de ça.
        De l'autre coté quand des sysadmins compétents ayant de la bouteille dis "on aime pas", soit le gars qui fait ça est un génie précurseur incompris, soit …

      Et vu les arguments des défenseurs de systemd (vous etes que des jaloux qui résistent au changement) bizarrement mon choix est vite fait.

      Troller en sortant n'importe quoi comme idée de critique est plus rigolo que de se mettre autour d'un table, mettre le plus de monde possible d'accord (partie la plus dure), et coder. Lennart a réussi à mettre pas mal de monde d'accord et a codé. Lui. (2 sur 3, certes, mais 2 de mieux que les autres. Je ne sais pas si il y a eu une table avant)

      Note pour mes réunions de boulot : faire un truc dans son coin, sans vrai doc, et étant appuyé par un ponte ça s'apelle, en ayant pas mal de monde contre soi, ça s'appelle "mettre le plus de monde possible d'accord".
      Remarque c'est vrai que tu n'as pas dis si le "plus de monde" était d'accord "pour" ou "contre"

      • [^] # Re: Trop d'honneurs...

        Posté par  . Évalué à 10.

        oui on veut du kiss et pas une usine a gaz

        Donc tu ne veux pas d'init Sys V ? Non parce que niveau usine à gaz, avec ses scripts dans tous les sens ça se pose là…

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

        • [^] # Re: Trop d'honneurs...

          Posté par  . Évalué à 2.

          Ils sont où ton "tous les sens" dans tes scripts init V ?

          • [^] # Re: Trop d'honneurs...

            Posté par  . Évalué à 3.

            Je l'ai dit plus bas. Tu as tout ça :

            • /etc/rc0.d à /etc/rc6.d ;
            • /etc/rcS.d ;
            • /etc/init.d/rc ;
            • /etc/rc.local.
            • /etc/inittab

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

  • # linuxfr: doc officielle de systemd

    Posté par  . Évalué à 1.

    Si il y a autant de gens qui savent ce qui ne va pas dans systemd, pourquoi ne travaillent-ils pas ensemble pour faire quelque chose qui va?

    systemd n'apporte pas de nouveautés, il agrège dans un seul outil des composants déjà existant.
    Il y a déjà un système fonctionnel qui fait la même chose, pas besoin d'en recoder un autre

    En fait AMHA, systemd est un bon outil, mais il s'écarte fortement de l'esprit unix (KISS, un outil par tache, modularité des composants, etc…) d'où une certaine résistance.
    Rajoute à celà le caractère de lennart qui pousse fortement son produit en voulant y intégrer des éléments qui avant se voulait modulaire, le troll est loin d'être mort

    du coup:

    Il est si difficile de l'étendre en ajoutant des fonctionnalités

    ben c'est l'inverse qui est demandé

    • [^] # Re: linuxfr: doc officielle de systemd

      Posté par  . Évalué à 10.

      Je trouve que systemd apporte au contraire beaucoup de fonctionnalités supportées nulle part ailleurs. Pour moi les deux fonctionnalités suivantes sont vraiment les plus importantes :

      • Activation à partir des socket : quand on démarre un service, si on a besoin d'un autre composant à travers une socket, alors systemd va intercepter cet appel et va retarder sa connection jusqu'au moment où l'autre composant en question est capable de la traiter (c'est à dire que la connection du composant est configurée). Ça permet de démarrer tous les process en même temps et de les faire communiquer le plus tôt possible. Par exemple, plutôt que de lancer dbus, puis lancer NetworkMonitor, on lance les deux en même temps et on gagne du temps (par exemple on résoud les bibliothèque en parallèle pour les deux programmes).
      • Gestion des cgroups automatiquement : lorsque l'on démarre un service (par exemple apache), celui-ci est démarré dans un cgroup distinct. Lorsque l'on va arrêter ce service, on va tuer tous les process du cgroup. L'intérêt principal, c'est qu'un serveur qui lancerait plusieurs process en tâche de font va être correctement terminé ainsi que tous les autres process qui y sont liés. Plutôt que de devoir gérer les pids d'une manière toujours différente d'un programme à l'autre, ici c'est générique quel que soit le programme à gérer.

      Une liste plus longue est disponible ici : http://0pointer.de/blog/projects/why.html
      Elle est à mon avis sujette à interprétation mais ça donne à mon avis quelques points à investiguer.

      • [^] # Re: linuxfr: doc officielle de systemd

        Posté par  . Évalué à 3.

        Tiens, des arguments qui tiennent la route et qui ne parlent pas de résistance au changement ou je ne sais quelle autre connerie

        et tu as raison, il y a bien sûr des plus values, et c'est pour ça que je disais que c'était un bon outil

        Par contre j'avais déjà vu ces tableaux, j'espère qu'on sera d’accord pour dire qu'ils ne valent pas grand-chose, il est toujours facile de créer ce genre de comparatif qui tourne à l'avantage de qui on veut.
        Bon après, il est vrai que je ne sais pas à quoi correspondent certaines features, et que justement l'une des critiques envers systemd est qu'il essaye de tout faire au lieu de laisser chaque tache à un outil dédié.

        • [^] # Re: linuxfr: doc officielle de systemd

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

          l'une des critiques envers systemd est qu'il essaye de tout faire au lieu de laisser chaque
          tache à un outil dédié.

          Wai, enfin ca veut pas dire un seul exécutable, logind et journald sont des exécutables distincts. Et si un jour systemd doit remplacer crond & ses petit frères, ce sera pareil.

          Parce que bon, on peut dire, mais cron c'est quand meme bien merdique à l'utilisation, pour faire tourner un truc le premier samedi du moi, t'es obligé de faire des trucs du genre:

          7 0 * * 0 root if [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ]; then /usr/share/mdadm/checkarray --cron --all --idle --quiet; fi

          Puis se limité à une date pour lancer un script, avec systemd, il serait bien de pouvoir réagir à des évènements.

          • [^] # Re: linuxfr: doc officielle de systemd

            Posté par  . Évalué à 5.

            Mais c'est pour cela que j'aurai préféré que systemd ne veuille pas remplacer la plupart des services "classiques" unix.

            Sur ton exemple sur cron, au contraire j'y vois la souplesse d'unix en 2 points:
            - la capacité de mettre du shell (même si en effet c’est crade, ça offre de la souplesse)
            - la capacité de changer le composant si nécessaire, pour ce genre de problèmes j'ai utilisé une alternative a cron et une a syslog
            si systemd n'adresse pas correctement un problème, est il possible de modifier son comportement (par du script par ex), ou d'utiliser un autre composant en parallèle sans foutre le bordel partout ? (c'est une vrai question, pas un début de troll)
            à l'inverse peut-on utilisé journald sans systemd ?

            • [^] # Re: linuxfr: doc officielle de systemd

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

              est il possible de modifier son comportement (par du script par ex)

              Tu peux lancer n'importe quel script shell dans un unit systemd donc oui.

              à l'inverse peut-on utilisé journald sans systemd ?

              Non, c'est systemd qui permet à journald de mieux loguer que syslog: du début du boot et pour tout ce qui est lancé par systemd, pas juste les trucs qui ont prévu d'envoyer des logs dans syslog.

              • [^] # Re: linuxfr: doc officielle de systemd

                Posté par  . Évalué à 2.

                Mais vois-tu, sans vouloir troller plus, c'est ce qui AMHA gène la plupart des users (en dehors de la non-portabilité, et des dépendances):

                si systemd ne me convient pas pour une utilisation, je ne peux pas simplement changer un composant (mais au moins je peux scripter).

                A l'inverse, autant il ne me gêne pas d'avoir systemd sur mes machines persos, mais sur les 2/3 machines que j'administre à distance, j'aimerai bien utilisé journald (et même le conseiller en test à des clients), néanmoins à l'heure actuelle il me parait prématuré d'installer systemd, et de déployé tout ce va autour

                Bon il reste aussi apparement de vrai problèmes à résoudre, notament sur le montage des vpns et des volumes chiffrés

                • [^] # Re: linuxfr: doc officielle de systemd

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

                  Ouh là, systemd sur mes serveurs ? Mais ce n'est pas prévu et vu que tout est sous Debian, ca va pas arriver demain.

                  Mais bon, je pense que quand RedHat le mettra par défaut, ce sera bon.

                • [^] # Re: linuxfr: doc officielle de systemd

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

                  Le montage des vpns marchent très bien ( en tout cas avec openvpn ), donc je vois pas ou serait le souci. Tu as 1 unité par vpn, ça démare quand le réseau se lance, ça se relance si ça tombe ( systéme de watchdog ), et conceptuellement, je sais pas trop ce qu'un autre vpn changerais ( genre, un daemon ipsec, ça reste un daemon ). Au pire, l'intégration est la même qu'avec les autres logiciels.

                  Quand aux fs chiffrés, si le souci est "systemd ne peux pas monter automatiquement un truc qui demande une intervention manuel" ( cf exemple donné plus tard ), je vois pas ce qu'un logiciel peut faire contre ça. Si un truc a besoin d'une intervention à la main, oui, tu va pas pouvoir faire grand chose pour automatiser ça. Et marqué le fs en "noauto" devrait suffire à régler le souci. Une fois que tu montes ça à la main ( avec ton mot de passe tapé ), systemd va réagir, si je comprends bien la doc de systemd.mount :

                  Mount points created at runtime independent on unit files or /etc/fstab
will be monitored by systemd and appear like any other mount unit in
systemd.

                  Donc soit je comprends de travers les soucis ( car la description est des plus lapidaires ), soit on n'a pas répondu comme il faut à tes questions.

          • [^] # Re: linuxfr: doc officielle de systemd

            Posté par  . Évalué à 2.

            Parce que bon, on peut dire, mais cron c'est quand meme bien merdique à l'utilisation, pour faire tourner un truc le premier samedi du moi, t'es obligé de faire des trucs du genre:
            7 0 * * 0 root if [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ]; then /usr/share/mdadm/checkarray --cron --all --idle --quiet; fi

            Le problème c'est ton implémentation de cron. Avec dcron c'est plutôt :

            * * 1 * sat /usr/share/mdadm/checkarray --cron --all --idle --quiet

            C'est tout de suite plus propre et moins « merdique » …

        • [^] # Re: linuxfr: doc officielle de systemd

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

          Tiens, des arguments qui tiennent la route et qui ne parlent pas de résistance au changement ou je ne sais quelle autre connerie

          "Ca n'apporte rien", c'est pas une connerie non plus de personnes ne voulant pas s’intéresser à la chose mais ayant leur avis définitif?
          Quand je parle de résistance au changement, c'est quand le "oh c'est nul systemd" vient de personnes n'acceptant pas que systemd répond à un problème, ou qui trouvent que des scripts bash c'est plutôt bien (la, c'est à mourir de rire, c'est vraiment une résistance au changement, les scripts bash sont tout sauf facilement maintenables) --> C'est "c'est pas bien" par défaut, c'est ça la résistance au changement.

          Encore une fois, si systemd est pris par les distros aussi rapidement, il faut peut-être se poser des questions plutôt que de dire que ça n'apporte rien.

          • [^] # Re: linuxfr: doc officielle de systemd

            Posté par  . Évalué à 6.

            Pour la résistance au changement, j'ajouterais les gens qui ont acquis un savoir, et qui ne veulent pas le voir devenir obsolète… C'est vrai que si tu t'es fais chié à apprendre le Bash, ça fait mal de se dire que ça ne servira plus :-)

    • [^] # Re: linuxfr: doc officielle de systemd

      Posté par  . Évalué à 6.

      Le KISS, ça reste un vœu pieux.
      En pratique GNU/Linux n'est pas un vieil UNIX

      Tant la somme de logiciels (et donc de développeurs) est devenu conséquente que lorsqu'il s'agit de faire une tâche, ce principe favorise l'empilement de solutions logiciels.
      Ironiquement, cela va à l'encontre même du but premier qui est d'assurer la maintenabilité.

      Je ne remet pas le principe en cause mais je suis tenté de croire que les mainteneurs sont plus pragmatiques.
      Puis, qu'est ce qui est KISS, franchement?

      Linux est monolithique et modulaire, KISS? Pourquoi pas un micro-noyaux?
      Le serveur d'affichage X.Org, KISS? Même quand il sert à faire de l'affichage distant?
      Le shell, KISS? Même quand ça sert à démarrer tous les services?
      Un navigateur web, KISS? Alors qu'on peut télécharger les pages et les afficher dans un éditeur de texte?
      Un environnement de bureau, KISS? etc.
      Poettring travail trop et communique mal. Pas KISS, apparemment.

      • [^] # Re: linuxfr: doc officielle de systemd

        Posté par  . Évalué à -3.

        Linux est monolithique et modulaire, KISS? Pourquoi pas un micro-noyaux?

        Linux c'est le noyau. Il fait son taff de noyau. Il s'occupe pas de lancer les différents scripts de démarrage par exemple.

        tu te trompes de débat.

        Le serveur d'affichage X.Org, KISS? Même quand il sert à faire de l'affichage distant?

        Le protocole X permet l'affichage distant ou l'affichage local. Le serveur d'affichage X.org implémente le protocole X.
        Encore une fois tu te trompes de débat.

        Un navigateur web, KISS? Alors qu'on peut télécharger les pages et les afficher dans un éditeur de texte?

        Un navigateur web a pour but la mise en forme des pages web téléchargés. Pas l'édition des sources des pages webs.
        Encore une fois tu te trompes de débat.

        Un environnement de bureau, KISS?

        oui. Il n'y a pas que kde ou gnome dans la vie.

        etc.

        etc quoi ? Pour l'instant tu n'as rien trouvé.

        • [^] # Re: linuxfr: doc officielle de systemd

          Posté par  . Évalué à 6.

          Linux c'est le noyau. Il fait son taff de noyau. Il s'occupe pas de lancer les différents scripts de démarrage par exemple.

          Puisque ton argumentaire se résume à donner des définitions, je t'invite à définir "taff de noyau". Les rôles tenus par le noyau Linux sont multiples (plouf, plouf, gestion de matos, ordonnancement, réseau voir protocoles, etc.). Un micro-noyau permettrait de délimiter lesdits rôles. Débat sur le KISS donc.

          Le protocole X permet l'affichage distant ou l'affichage local. Le serveur d'affichage X.org implémente le protocole X.
          Encore une fois tu te trompes de débat.

          Tu réponds à côté alors je vais préciser ma pensée: Pourquoi aurait-on besoin de lier affichage locale et affichage distant, deux rôles distincts, dans un même protocole qui soit le seul utilisable à ce jour sur certains OS. Encore une histoire de KISS.

          Un navigateur web a pour but la mise en forme des pages web téléchargés. Pas l'édition des sources des pages webs.
          Encore une fois tu te trompes de débat.

          Alors remplace editeur par visualisateur. Reste que le navigateur web, s'il remplit bien son rôle sur ce point, il sert aussi, entre autres, au multimédia, à la sauvegarde et au jeu vidéo. Toujours une histoire de KISS

          oui. Il n'y a pas que kde ou gnome dans la vie.

          Alors un DM c'est KISS, je note.

          etc quoi ? Pour l'instant tu n'as rien trouvé.

          etc. En effet. L'épopée de la gestion du son sous GNU/Linux est un exemple de caetera.

          Conclusion: le KISS, ça sert surtout a troller sur dlfp.

          • [^] # Re: linuxfr: doc officielle de systemd

            Posté par  . Évalué à 2.

            Alors un DM c'est KISS, je note.

            Oui ça peut. Par exemple Fluxbox est un DM KISS.

            • [^] # Re: linuxfr: doc officielle de systemd

              Posté par  . Évalué à 5.

              Surtout que c'est pas un DM, c'est un WM.

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

              • [^] # Re: linuxfr: doc officielle de systemd

                Posté par  . Évalué à 3.

                Ça gère aussi une zone de notification, etc… Pas que les fenêtres. Mais bon tu as raison, la terminologie qui va bien c'est WM. La nuance entre DM et WM est quand même mince.

                • [^] # Re: linuxfr: doc officielle de systemd

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

                  Un WM qui gère une zone de notification, est-ce vraiment KISS? ;-)

                  • [^] # Re: linuxfr: doc officielle de systemd

                    Posté par  . Évalué à 2.

                    Dans le sens où un icône dans une zone de notification correspond à une application, donc à une fenêtre, fenêtre qui n'est pas affichée (processus en arrière-plan pas vraiment interactifs…) Il me semble que la fonction "Coller un icône cliquable permettant d'accéder (de repasser au premier plan) cette application" me semble du ressort du windows manager.

                    • [^] # Re: linuxfr: doc officielle de systemd

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

                      Dans le sens où… Je crois qu'on peut reprendre la même phrase pour udev et systemd…

                    • [^] # Re: linuxfr: doc officielle de systemd

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

                      Dans le sens où un icône dans une zone de notification correspond à une application, donc à une fenêtre

                      Ouh la la, faux sur plusieurs plans… Déjà dans un environnement document-oriented comme OSX, l'implication application => fenêtre est fausse (gnome3 a également cette saine approche différenciatrice entre application et fenêtre). Ensuite même à l'époque de gnome2 il y avait protestation contre les gens qui confondaient notification et minimisation d'où l'arrivée de tentatives de standardisations chez fd.o (dont j'ai oublié les noms).

                      Il me semble que la fonction "Coller un icône cliquable permettant d'accéder (de repasser au premier plan) cette application" me semble du ressort du windows manager.

                      En conséquence du premier point, il est normal que le WM propose une liste de Windows (avec la fameuse barre de fenêtres visible sur Windows, Gnome 2, KDE, XFCE… en bas de l'écran) mais ça n'a que peu à voir avec des notifications. Encore une fois, parce que j'aime gnome3, voir leur différentiation claire entre les fenêtres, visibles en mode "Exposé", les applications dans le dock, et les notifications dans la zone de notification.

          • [^] # Re: linuxfr: doc officielle de systemd

            Posté par  . Évalué à 1.

            Puisque ton argumentaire se résume à donner des définitions, je t'invite à définir "taff de noyau". Les rôles tenus par le noyau Linux sont multiples (plouf, plouf, gestion de matos, ordonnancement, réseau voir protocoles, etc.). Un micro-noyau permettrait de délimiter lesdits rôles. Débat sur le KISS donc.

            Je suis d'accord sur le principe.
            Ensuite l'ensemble des fonctions bas niveau (interaction avec le matos, gestion des taches, …) est géré par le même ensemble (sauf qq trucs de plus nécessaires dans certains cas , client dhcp pour du pxe).

            Tu réponds à côté alors je vais préciser ma pensée: Pourquoi aurait-on besoin de lier affichage locale et affichage distant, deux rôles distincts, dans un même protocole qui soit le seul utilisable à ce jour sur certains OS. Encore une histoire de KISS.

            Non je répond pile poil dedans.
            Quel est le lien commun entre "affichage local" et "affichage distant" ?
            affichage
            Quel est le protocole X ? Un protocole d'affichage agnostique du réseau (peut fonctionner sur ou en dehors).

            Pourquoi séparer artificiellement ?

            il sert aussi, entre autres, au multimédia, à la sauvegarde et au jeu vidéo. Toujours une histoire de KISS

            Ah ca je suis tout à fait d'accord que c'est pas KISS.
            Mais là linux n'y est pour rien. Vois ça avec les fournisseurs de services qui foutent tous dans le http.

            • [^] # Re: linuxfr: doc officielle de systemd

              Posté par  . Évalué à 1. Dernière modification le 08 septembre 2012 à 00:03.

              Tu réponds à côté alors je vais préciser ma pensée: Pourquoi aurait-on besoin de lier affichage locale et affichage distant, deux rôles distincts, dans un même protocole qui soit le seul utilisable à ce jour sur certains OS. Encore une histoire de KISS.

              Non je répond pile poil dedans.
              Quel est le lien commun entre "affichage local" et "affichage distant" ?
              affichage
              Quel est le protocole X ? Un protocole d'affichage agnostique du réseau (peut fonctionner sur ou en dehors).

              Pourquoi séparer artificiellement ?

              Flagrant délit d'enthymème. Tu prends deux assertions irréfutables certes, mais tu élude sur un sophisme. Je répète: Pourquoi un protocole qui gère le réseau par défaut ?

              Cesse donc de drosophiler. Je n'émets pas de jugement de valeur, j'imagine que ce sont des choix techniques liés à des raisons historiques mais, quoi qu'il en soit un protocole d'affichage dépourvu de prise en charge du réseau serait plus simple. Cela relève donc bien de la notion de KISS.

        • [^] # Re: linuxfr: doc officielle de systemd

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

          Linux c'est le noyau. Il fait son taff de noyau.

          Il fait plein d'autres choses. Débat sur ce que fait un noyau.
          Mais c'est Linux, donc on accepte le "bloat" qu'on refuse à systemd.

          Deux poids, deux mesures…

          • [^] # Re: linuxfr: doc officielle de systemd

            Posté par  . Évalué à 4.

            Si il y avait un choix (aussi utilisable) en micro noyau, je pense qu'on serait nombreux à apprécier

            Mais on va tomber dans un autre débat stérile

            • [^] # Re: linuxfr: doc officielle de systemd

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

              Si il y avait un choix (aussi utilisable) en micro noyau, je pense qu'on serait nombreux à apprécier

              Pareil pour systemd. Non, le système actuel n'est pas une solution viable, on change, c'est pour une raison. Je te laisse proposer ta version qui fait autant de choses que systemd (les perfs, la synchro, les configs communes à toutes les distros, ce sont des choses à faire).

              • [^] # Re: linuxfr: doc officielle de systemd

                Posté par  . Évalué à 2.

                Mais moi je n'ai rien contre systemd ;)

                • [^] # Re: linuxfr: doc officielle de systemd

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

                  C'est malin, comme on fait pour troller alors? :)
                  Je suis d'accord pour dire que ce serait mieux un truc moins "envahissant", mais ce truc a un avantage : il existe et répond au besoin. initd existe mais ne répond pas/plus au besoin et le projet X répond au besoin tout en étant modulaire mais n'existe pas…

                  • [^] # Re: linuxfr: doc officielle de systemd

                    Posté par  . Évalué à 4.

                    C'est malin, comme on fait pour troller alors? :)

                    Boah la pomme de terre est un bon sujet si tu veux, car si la patate cuite à l'eau est un produit éprouvé (certain ont même fait une fourchette de la patate à l'eau pour répondre à la problématique de mastication, j'ai nommé la purée), la frite est; je pèse mes mots; une aberration.

                    La frite ne répond à aucune problématique, si ce n'est terminer son assiette plus vite, super! Or, la faute à MacDal, une multinationale tentaculaire qui veut imposer la frite dans nos habitudes culinaires, cela rompt avec nos habitudes d'amateur de vraies patates.

                    Si ça continue on va manger… des chips! T'entends? Des chips! C'est tout ce que ça te fait quand je te dis qu'on va manger des chips?

                    Ah, monde de merde !

                    • [^] # Re: linuxfr: doc officielle de systemd

                      Posté par  . Évalué à 3.

                      ca critique la frite, mais ça utilise de la patate à l'eau
                      pourtant c'est bloater la patate à l'eau, tu es contraint d'utiliser une interface couteau, et ce n'est absolument pas portable sur un poële ou un four, on est obligé d'utiliser une casserole ! Bref, ça respecte autant le principe kiss que ta frite.
                      S'en compter que si tu as déjà un composant hamburger, ça ne colle pas du tout

                      Mais bon je comprends que tu es un vieu con, tu as peur du changement

                      Alors que la patate au four, c'est souple, ça va avec tout, un composant qui peut même se suffire à lui même

                      • [^] # Re: linuxfr: doc officielle de systemd

                        Posté par  . Évalué à 2.

                        S'en compter que si tu as déjà un composant hamburger, ça ne colle pas du tout

                        Les frites dans le hamburger c'est vraiment la loose (i.e : la déchéance).

                        Mais bon je comprends que tu es un vieu con, tu as peur du changement

                        Moi je comprends que tu es patatophobe. On fait quoi ?

                      • [^] # Re: linuxfr: doc officielle de systemd

                        Posté par  . Évalué à 2. Dernière modification le 07 septembre 2012 à 21:50.

                        Billevesées!
                        Moi qui m'inscris directement dans la tradition de la Patate avec un grand P, j'affirme que la patate à l'eau ravira restaurateurs et utilisateurs lambdas, contenant de nouvelles versions massivement améliorées de recettes et accompagnements, les plus utiles.

                        Elle peut s'interfacer avec plus de 1 000 récipients: avec un micro onde, une poêle profonde ou un four munis d'un contenant en pyrex. Performance, évolution, innovation, stabilité, gestion et nouveauté, sont sont les mots d’ordre de la patate à l'eau !

                        La patate à l'eau, un choix d'avenir ?

                        La patate à l'eau devrait faire le bonheur des habitués comme des nouveaux : certains y reconnaîtront la rigueur Inca loin d'autres légumes parfois moins abouties: tout a été testé et profondément pensé pour éviter tout travers qui risquerait de dégouter les nouveaux arrivants.

                        La patate à l'eau s'écarte de systèmes non standard et permet, à terme, de s'attirer les faveurs du monde professionnel.

                        N'oubliez pas que, si vous êtes un décideur pressé, une version surgelée est disponible.

                    • [^] # Re: linuxfr: doc officielle de systemd

                      Posté par  . Évalué à 2.

                      Toi, j'espère que t'as pu avoir une assiette de frites ce soir sinon je crains le pire.

                    • [^] # Re: linuxfr: doc officielle de systemd

                      Posté par  . Évalué à 3.

                      La frite ne répond à aucune problématique, si ce n'est terminer son assiette plus vite, super! Or, la faute à MacDal, une multinationale tentaculaire qui veut imposer la frite dans nos habitudes culinaires, cela rompt avec nos habitudes d'amateur de vraies patates.

                      La frite répond à la problématique du cornet. Il est peu pratique de manger ses patates à l'eau dans un cornet tandis que c'est tout à fait faisable avec des frites. Sinon, McDonald ne fait pas des frites, ils coupent des pommes de terres et les mettent dans l'huile bouillante (comme beaucoup de restaurant français qui essayent de servir des frites) mais ce n'est pas des frites.

                      « 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: linuxfr: doc officielle de systemd

                        Posté par  . Évalué à 1. Dernière modification le 08 septembre 2012 à 00:24.

                        Oooh, toi, t'es du genre friteux.
                        Le cornet, c'est juste un effet de mode pour bobo en mal de hype.
                        Tout ces sales friteux et ces sales friteuses qui se la pêtent avec leurs cornets, ça m'agace.

              • [^] # Re: linuxfr: doc officielle de systemd

                Posté par  . Évalué à -4.

                . Non, le système actuel n'est pas une solution viable,

                il a fonctionné pendant 20 ans, mais tu as raison c'est pas viable.

                Je te laisse proposer ta version qui fait autant de choses que systemd (les perfs, la synchro, les configs communes à toutes les distros, ce sont des choses à faire).

                la perf ? celle actuelle me suffit
                la synchro ? sert à quoi ?
                config commune a toutes les distros? c'est pas le cas de systemd.
                Sinon la config actuelle est "commune a toutes les distribs" (en tout cas plus que systemd) LSB tu en as entendu parler ?

                • [^] # Re: linuxfr: doc officielle de systemd

                  Posté par  . Évalué à 6. Dernière modification le 07 septembre 2012 à 22:26.

                  il a fonctionné pendant 20 ans, mais tu as raison c'est pas viable.

                  Fonctionner ne signifie pas être viable, surtout quand on a rien d'autre.

                  Après tout, HAL fonctionnait, pourquoi a-t-on décider de ne plus l'utiliser ?

                  la perf ? celle actuelle me suffit

                  Tant mieux pour toi. Maintenant tu peux penser aux autres, ceux que ça intéresse.

                  En plus, Linux ça tourne sur de plus en plus de matos, pas que sur PC : smartphones, tablettes, etc. Et même sur PC, ça a son intérêt, comme pour l'autonomie sur portable.

                  la synchro ? sert à quoi ?

                  Là, je ne vois pas de quoi il parle.

                  config commune a toutes les distros? c'est pas le cas de systemd.

                  Justement si. Le but c'est de remonter les scripts init à l'upstream.

                  Sinon la config actuelle est "commune a toutes les distribs" (en tout cas plus que systemd)

                  Pas du tout. Actuellement, chaque distrib fournit ses propres scripts d'init.

                  Pour lancer Apache, c'est /etc/init.d/httpd chez Red Hat et /etc/init.d/apache2 chez Debian. C'est vachement commun.

                  LSB tu en as entendu parler ?

                  Oui et ? C'est utilisé par les projets upstream ? Ben non, parce qu'ils ne peuvent pas fournir un script adapté pour chaque distribution.

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

          • [^] # Re: linuxfr: doc officielle de systemd

            Posté par  . Évalué à -1.

            Tout est affaire de compromis.

            Le noyau doit être extrêmement performant, il doit donc être monolithique (sans sacrifier à un design modulaire d'ailleurs).
            La performance de l'init est beaucoup moins critique (on passe un temps significatif dans le démarrage des services par rapport au temps de l'init proprement dit). Pourquoi sacrifier sa modularité ? Pourquoi sacrifier la modularité d'autres programmes ?

            • [^] # Re: linuxfr: doc officielle de systemd

              Posté par  . Évalué à 4.

              Et en quoi systemd est il moins modulaire que les autres systemes d'init ?

              • [^] # Re: linuxfr: doc officielle de systemd

                Posté par  . Évalué à 2.

                Des features du systèmes de journal ne sont pas séparées de systemd proprement dit alors qu'elles pourraient (tout le mécanisme de verrouillage des logs en modification par exemple : ça pourrait être très utile pour d'autres applications).

                systemd inclut udev qui pourtant vivait bien tout seul, mais maintenant il faudra l'un pour avoir l'autre, pour le moment seulement à la compilation, bientôt pour l'exécution (la volonté n'est pas de maintenir udev indépendant). Ce ne sont plus deux programmes indépendants.

                Etc etc.

            • [^] # Re: linuxfr: doc officielle de systemd

              Posté par  . Évalué à 6.

              Pourquoi sacrifier sa modularité ? Pourquoi sacrifier la modularité d'autres programmes ?

              Ce que tu appelles modularité, je l'appelle beau bordel.

              Franchement, il y avait moyen de faire plus simple que ça :

              • /etc/rc0.d à /etc/rc6.d ;
              • /etc/rcS.d ;
              • /etc/init.d/rc ;
              • /etc/rc.local.

              Comment tu connais l'ordre d'appel des scripts ?

              Et il faut reconnaître que l'idée de nommer les états du système plutôt que les numéroter est tout de même bien appréciable.

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

              • [^] # Re: linuxfr: doc officielle de systemd

                Posté par  . Évalué à 4. Dernière modification le 07 septembre 2012 à 19:24.

                C'est vrai qu'avec ce système, moi sous une Debian de test avec pas mal de services lancés, j'en ai finit par inclure des commandes de restart de certains services, notamment ceux basés sur postgres, dans le /etc/rc.local pour avoir tous les services debout au démarrage de la machine…

                Je ne sais pas pourquoi, malgré un ordre de démarrage prioritaire, postgres se lance sur le tard (si j'en crois ce qu'il s'affiche à l'écran) et lentement (enfin ça je peux comprendre pour un SGBD si complexe).

                Faut reconnaitre que les systèmes actuels d'init, SysV et BSD ont comme avantage l'adaptabilité : même si c'est crade on peut faire un peu ce qu'on veut.

                Avec systemd va falloir être plus carré.

                Moi je sors le pop-corn et j'attends de voir. J'ai le temps, c'est, au plus tôt, pour la prochaine prochaine Debian…

              • [^] # Re: linuxfr: doc officielle de systemd

                Posté par  . Évalué à 2.

                Ce que tu appelles modularité, je l'appelle beau bordel.
                C'est surtout que je répondais à Zenitram et à son "Mais c'est Linux, donc on accepte le bloat qu'on refuse à systemd." Pas que j'encensais systemV.

          • [^] # Re: linuxfr: doc officielle de systemd

            Posté par  . Évalué à -1.

            si systemd était au niveau de linux, on aurait pas de débat.

            Toujours est il que l'on palre du système d'exploitation, et linux c'est du noyau, ce qui sont des domaines différents (déjà les applications du système d'exploitation tourne pas en ring 0)

  • # Parce que les distributions et les users, c'est 2 choses différentes

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

    En fait, c'est simple, les distributions l'utilisent car elles pensent que c'est sur le long terme plus facile à maintenir. Il y a moins de code à faire pour lancer un demon, ça permet des choses choupis, c'est moderne. Les raisons que j'estime pleinement valable de pas y passer sont soit d'ordre du minimalisme ( exemple, lfs et co ), soit de l'ordre de la diversité, soit de l'ordre de la portabilité ( exemple debian ).

    La plupart des distribs ne sont pas dans ce cas la. La diversité, c'est un cout à la QA, à la compilation et à la gestion et tente d'être diminué avec plus ou moins de bonheur. Autant offir X WM, ça va, autant offrir par exemple X serveurs webs et espérer une intégration fine, c'est plus dur ( d'ailleurs, c'est pour ça que la plupart le font pas, et propose juste une intégration avec apache, et pas X fichiers de conf pour nginx, lighttpd, pour php en fastcgi, en demon avec fpm, etc ). Et dans le cas d'un truc comme un système d'init qui touche tout le monde c'est simplement trop complexe.

    La portabilité, ça a un cout aussi, et la plupart des distribs ne sont pas prêtes à le payer. EN fait, il y a que Debian ( et Arch ) qui tente de tourner sur autre chose qu'un noyau Linux. Pour les autres, avant, les initscripts n'étaient pas compatible avec les BSDs, et était fait par la distro, maintenant, ça ne va pas changer. Donc globalement, ça, à part pour Debian, ça change rien.

    Enfin je pense que la plupart des distributions ne souffrent pas des soucis de lfs, vu que la plupart ont besoin déjà de tout un tas de trucs. Donc c'est déja un souci qui est maitrisé, et qui n'affecte pas trop l'utilisateur ( ie, les deps de systemd sont déjà toutes dans les distros, donc le surcout est mineur du point de vue packaging ).

    Et moi, en tant que packageur de longue date, je pense que le format de fichier de systemd est beaucoup plus facile à écrire, à comprendre et à vérifier qu'un script shell à base de boilerplate et de copier coller, et qu'il fait juste des tas de trucs en plus. Systemd gére aussi de façon élégante des cas à la con comme "lancer plusieurs fois un service", "gérer des services à la con comme bind qui utilise un canal de com à part pour se couper" ou d'autres exemples que je sort à chaque fois ( bla bla sympa bla bla 5 services bla bla bloquant bla bla postgresql pas lancé bla bla ).

    Et je suis aussi sensible à l'idée "on pousse le fichier upstream", car ç'est la façon la plus simple de collaborer, ce qui est la base du logiciel libre. Ça a relativement bien marché pour les menus en .desktop ( pour ceux qui sont assez vieux pour se souvenir du merdier infame que c'était avant ), je vois pas pourquoi ça ne marcherais pas pour les services. Et autant j'ai rarement confiance dans un script d'init qui vient d'upstream ( qui va toujours faire 3 fois trop de trucs, et qui va tourner correctement sur 1 distro ), autant, un fichier de config, je pense que ça peut passer.

    Donc tout ce qui peut réduire la charge de travail d'un packageur est la bienvenue.

    Et ça, c'est mon avis en tant que mec du coté distro.

    • [^] # Re: Parce que les distributions et les users, c'est 2 choses différentes

      Posté par  . Évalué à 8.

      En tant que luser qui aime de temps en temps changer un boulon sur sa distro, je suis assez convaincu par tes arguments.

      Après, la perte de la compatibilité "hors Linux" me dérange un peu, éthiquement.

      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

      • [^] # Re: Parce que les distributions et les users, c'est 2 choses différentes

        Posté par  . Évalué à 10.

        Et les bsdistes, ils en pensent quoi de la "perte de compatibilite"?
        Parce que c'est un peu les premiers concernes, ca serait pas mal de leur demander leur avis plutot que de les considerer comme des pauvres, gentils mais un peu idiots, qui vont necessairement mourir si linux arrete de leur tenir la main.

        La derniere phrase est pas forcement dirige vers toi, mais c'est un peu le sentiment que j'ai quand je lit pas mal de linuxiens sur le sujet.

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

  • # les autres Unices...

    Posté par  . Évalué à 10.

    Personnellement, je ne suis pas expert non plus sur le plan technique.

    Je suis un peu plus rebuté par contre par le côté "les non-Linux, on s'en cogne!".
    J'ai une vision un peu optimiste du mode de développement Libre dans lequel le partage est important, et donc la portabilité est importante.
    Que tous les noyaux fassent leur sauce chacun dans leur coin, grand bien leur fasse.

    Mais là on parle d'encourager les développeurs à utiliser la configuration façon systemd, et donc zapper les fichiers de config pour les systèmes BSD.
    Et ça, on ne peut pas s'en foutre! Aujourd'hui on utilise Linux, qui sait si demain ce ne serait pas l'un de ces BSD "LE" système Libre sur lequel les enthousiastes se jetteront?
    Et bien non, Lennart a parlé: les BSD, on s'en fout.

    Combien de logiciels dans nos distros viennent de ces BSD? Combien d'idées venant de ces projets reprises dans GNU/Linux?
    Quelle ingratitude, finalement!

    J'ai lu des arguments "quasi personne n'utilise BSD sur son bureau/portable/etc.". Venant de Linuxien (3% de part de marché? 1%?), je trouve ça choquant.

    Du coup, encore une fois, techniquement, je suis (j'ai installé systemd), mais Lennart me met très mal à l'aise. Il a un discours de marketeux (je te raconte n'importe quoi pour te vendre mon idée) avec les Linuxiens, et se fout de tous les autres.

    C'est peut-être ça, le plus gros problème de systemd…

    • [^] # Re: les autres Unices...

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

      Combien de logiciels dans nos distros viennent de
      ces BSD? Combien d'idées venant de ces projets
      reprises dans GNU/Linux?
      Quelle ingratitude, finalement!

      Tu déconnes j'espère ? Les BSDistes passent leur temps à recoder les softs sous licence GPL/LGPL parce que la liberté, la vraie, la contagieuse, pas le libéralisme à trois francs leur fait peur…

      Alors, je vois pas pourquoi on se ferait chier…

      ps: un troll s'est caché, ou pas, dans ce message…

      • [^] # Re: les autres Unices...

        Posté par  . Évalué à -3.

        Tu déconnes j'espère ? Les BSDistes passent leur temps à recoder les softs sous licence GPL/LGPL parce que la liberté, la vraie, la contagieuse, pas le libéralisme à trois francs leur fait peur…

        Aucun arguments et des préjugés merdiques. Il n'y a pas qu'un troll dans ce message totalement inutile voir même dégradant.

        • [^] # Re: les autres Unices...

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

          Des préjugés? Non, c'est la réalité, les devs BSD ne veulent pas de (L)GPL dans leur OS (pour les bases), je l'ai dit en trollant mais c'est la réalité.

          Donc un port de systemd sous BSD, sans changement de licence, j'y crois pas.

          • [^] # Re: les autres Unices...

            Posté par  . Évalué à 3.

            Ah je croyais que l'on parlais d'un port fait par Lennart Poetering ou son équipe, après que cela soit intégré ou non sur BSD n'est pas la question.

            • [^] # Re: les autres Unices...

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

              Lennart a dit qu'il ne ferait jamais le port sous BSD et que si ca intéresse les devs BSD, ils peuvent le faire.

              Et un port de systemd si ce n'est pas utilisé par défaut pas les BSDs, ca sert à rien et je vois pas pourquoi on vient nous dire que c'est une honte que systemd soit orienté Linux ;)

      • [^] # Re: les autres Unices...

        Posté par  . Évalué à 6.

        Si, c'est du Troll de compétition, avec le vocabulaire qui va avec et tout.

        On peut écrire "par forte conviction idéologique, ils tentent d'éliminer tout ce qui pourrait être incompatible avec la licence BSD".
        Mais non, à la place, on va écrire "la vraie liberté leur fait peur".

        Et les BSDistes passent leur temps à recoder les softs du monde Linux?
        Effectivement, ils utilisent même iPot pour porter OpenSSH sous BSD avant sa sortie sous GNU/Linux…

        Pour être sûr de comprendre ce qu'il en retourne, je remets ici une citation de Lennart lui-même:

        What I actually suggested in that interview was not so much that the BSDs should adopt the Linux APIs, but instead that people should just forget about the BSDs. Full stop.

        Voilà! Le monde Libre, une atmosphère de saine compétition dans laquelle on veut carrément tuer les projets qui pourraient devenir des concurrents…

        • [^] # Re: les autres Unices...

          Posté par  . Évalué à 8.

          Si, c'est du Troll de compétition, avec le vocabulaire qui va avec et tout.

          C'est l'histoire d'un-e geek qui voit un troll devant lui et qui se dit "Ah zut, je vais marcher dedans !"

          THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

        • [^] # Re: les autres Unices...

          Posté par  . Évalué à 7.

          What I actually suggested in that interview was not so much that the BSDs should adopt the Linux APIs, but instead that people should just forget about the BSDs. Full stop.

          Voilà! Le monde Libre, une atmosphère de saine compétition dans laquelle on veut carrément tuer les projets qui pourraient devenir des concurrents…

          Il dit "on devrait les oublier" (donc, ne pas en tenir compte), toi tu lis "on veut les tuer". Comme quoi, un troll peut en cacher un autre.

    • [^] # Re: les autres Unices...

      Posté par  . Évalué à 7.

      Mais là on parle d'encourager les développeurs à utiliser la configuration façon systemd, et donc zapper les fichiers de config pour les systèmes BSD.

      Je ne vois pqs en quoi, actuellement, les scripts d'init ne sont pas compatibles entre les distributions et très rarement fournis par uptstream, la seule chose qui va changer, c'est le fichier de configuration systemd qui va être upstream.

      « 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 autres Unices...

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

      Selon toi, le plus gros problème de systemd, c'est que les gens jugent pas le soft mais l'idée qu'ils se font d'un des auteurs sur la base d'extrait de discussions qu'ils ont pas suivi, mais dont il garde une sous partie qui leur semble choquante, c'est ça ?

      Perso, je dirais pas que c'est un problème de systemd, plus un problème de gens.

      Encore une fois, les technos linux only et bsd only abondent depuis des années. Samba utilise sendfile sur linux et pas sur bsd, personne trouve rien à redire. Nufw ne tourne que sur netfilter donc Linux, personne ne trouve rien à redire ( et dieu sait que mon patron, créateur du soft, a trollé pf plus d'une fois ).
      NetworkManager tourne pas sur freebsd, wicd non plus, et je doute que connman soit dispo. Et pourtant, personne n'a jamais dit "faut pas coder ces outils". Ni personne n'a dit "je vais aller faire des patches".
      Bluez tourne pas ( que je sache ) sur Openbsd, c'est pareil, ou sont les gens pour crier au complot de Nokia et Intel ?

      • [^] # Re: les autres Unices...

        Posté par  . Évalué à 8.

        Un tas de softs tournent ou ne tournent pas sous Linux/BSD.

        Le problème est que plus tu vas partir sur des incompatibilités de bas niveau, et plus il sera difficile d'avoir des applis qui marchent des deux côtés en même temps sans trop d'effort.

        Voir un type avec autant d'influence déclarer qu'il faut laisser tomber les systèmes BSD, je trouve ça très malsain.

        La coopération, la compétition saine? Tu imagines vraiment voir les dévs BSD venir s'asseoir à une table avec Lennart pour discuter standardisations d'API ou de fichiers de config, de logs, etc. après ce qu'il a balancé?

        En fait, non, ils ne pourront même pas: Lennart ne veut pas discuter!
        Tout ce qui l'intéresse, c'est d'avoir un GNU/Linux/Lennart.

        Et quant au bien qu'il fait à Linux, j'ai quand même un doute. Les distros intègrent son travail, c'est que les mainteneurs s'y retrouvent.

        Maintenant, les dévs et les utilisateurs doivent s'entendre, et donc s'écouter.
        C'est pour ça que Xfce est monté à la suite des récentes euh… "améliorations" de Gnome.
        Je crains qu'un mouvement similaire s'opère de Linux à BSD à plus ou moins long terme, rapport aux "améliorations" que Lennart offre au monde! PulseAudio a été un désastre de ce côté. On peut dire que les distros ont mal joué le jeu. On peut aussi en conclure que c'est vachement difficile à intégrer!! On verra pour systemd…

        • [^] # Re: les autres Unices...

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

          Ça fait 20 ans que les BSD et les systèmes Linux existent, et c'est quand la dernière fois qu'il y a eu des gens autour de la table pour discuter de standard communs entre les 2 ?

          Quand tu vois que les gens sont pas capable de se mettre d'accord sur les conventions d'appel, sur la présence ou pas de fonction de manipulation de chaines ( strnlen ), sur la version de gcc, ou sur justement les initscripts, et les apis, je vois pas ce que Lennart va changer à ça.

          D'ailleurs, la dernière fois qu'il a fait un soft portable ( genre avahi ), y a eu un gsoc pour coder un truc compatible sous une license BSD :
          http://wiki.freebsd.org/MulticastDNS

          Donc oui, ce que les BSDistes veulent, c'est pas du code GPL, c'est des interfaces.
          Grande nouvelle, y en a :

          http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart

        • [^] # Re: les autres Unices...

          Posté par  . Évalué à 5.

          Voir un type avec autant d'influence déclarer qu'il faut laisser tomber les systèmes BSD, je trouve ça très malsain.

          Il n'a pas dit qu'il fallait laisser tomber les systèmes BSD. Juste qu'il pense que supporter plusieurs OS serait trop compliqué et contraignant, et qu'il faut plutot forker et se contenter de partager les interfaces.

          Voir http://0pointer.de/blog/projects/systemd.html#faqs :

          Will this run on [insert non-Linux OS here]?
          Unlikely. As pointed out, systemd uses many Linux specific APIs (such as epoll, signalfd, libudev, cgroups, and numerous more), a port to other operating systems appears to us as not making a lot of sense. Also, we, the people involved are unlikely to be interested in merging possible ports to other platforms and work with the constraints this introduces. That said, git supports branches and rebasing quite well, in case people really want to do a port.
          Actually portability is even more limited than just to other OSes: we require a very recent Linux kernel, glibc, libcgroup and libudev. No support for less-than-current Linux systems, sorry.
          If folks want to implement something similar for other operating systems, the preferred mode of cooperation is probably that we help you identify which interfaces can be shared with your system, to make life easier for daemon writers to support both systemd and your systemd counterpart. Probably, the focus should be to share interfaces, not code.

      • [^] # Re: les autres Unices...

        Posté par  . Évalué à 0.

        NetworkManager tourne pas sur freebsd

        En même temps je vois pas pourquoi ils seraient maso pour vouloir importer cette bouse. (sisi c'est une bouse. Pas pour des portables, mais pour des serveurs c'est une belle bouse).

        • [^] # Re: les autres Unices...

          Posté par  . Évalué à 3.

          En même temps, personne ne te force à l'installer.

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

          • [^] # Re: les autres Unices...

            Posté par  . Évalué à -1.

            installer de base sur une redhat…
            pourtant orienté serveur.

            • [^] # Re: les autres Unices...

              Posté par  . Évalué à 2.

              Faux. Une RHEL installée de base, c'est orienté workstation. Tous les outils graphiques sont installés (dont OOo et GIMP).

              Si tu veux une RHEL orientée serveur, tu n'installes pas l'interface graphique. Et là, pas de NM.

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

        • [^] # Re: les autres Unices...

          Posté par  . Évalué à 3.

          Meme pour des portables, exemple essaye d'avoir plusieurs VPN en meme temps avec ce truc c'est impossible… (j'ai des collegues qui ont besoin de ca me demande pas pourquoi :) )

          Je vais etre honnete il crache moins depuis quelques temps mais dommage que wicd ne gere pas le VPN…

        • [^] # Re: les autres Unices...

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

          Ma foi, parce que peut être, y a des gens qui veulent avoir une interface graphique capable de gerer le wifi, etc ?
          Mais si tu aimes pas nm, tu as connman, tu as wicd, et pareil, ils tournent pas sur les bsd.

          Donc à la fin, c'est "est ce que les gens sur un système bsd (autre que celui d'apple) veulent tous gérer le wifi à la mano en cli" ?

          Perso, nm marche sur mon portable et me taper wpa_supplicant à la main, ça va 5 minutes ( surtout vu que j'ai besoin d'une authentification à 2 facteurs pour le wifi au travail ), tout comme devoir faire les 3/4 commandes pour un wifi classique, ça me ferait chier ( à commencer par me connecter en root ).

    • [^] # Re: les autres Unices...

      Posté par  . Évalué à 8.

      Et ça, on ne peut pas s'en foutre! Aujourd'hui on utilise Linux, qui sait si demain ce ne serait pas l'un de ces BSD "LE" système Libre sur lequel les enthousiastes se jetteront?
      Et bien non, Lennart a parlé: les BSD, on s'en fout.

      Ah bon, Lennart a décidé de ne pas se préoccuper des BSD, ça veut dire qu'ils vont mourir ?

      Je suis convaincu que les BSD sauront très bien se passer de systemd, comme ils ont su le faire pour udev et autres.

      Si vraiment ils ont besoin d'un truc équivalent, ils sauront le coder, sinon c'est qu'ils n'en ont pas besoin et tout va bien.

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

  • # quelques réponses a de fausses questions

    Posté par  . Évalué à 4.

    Si c'est aussi contesté, pourquoi toutes les distributions y passent? (Je veux dire, avant l'actuelle intégration de udev qui semble compliquer les choses si on veut s'en passer) Il y a des tas d'outils géniaux qui ne sont pas repris d'une distribution sur l'autre, et là on voudrait me faire croire qu'un truc qui est loin de faire l'unanimité s'est retrouvé en si peu de temps maintenu, packagé et imposé dans toute distrib grand public? Je veux dire, Gnome 3 me plaît pas, je l'utilise pas et j'ai pas de soucis. Pourquoi n'en est-il pas de même pour systemd?

    1°) liste moi la liste des distribs qui y passent, et ensuite liste moi la liste des distribs qui existent, avec leur "souche".
    Et on en reparle de "toute les distribs".

    Ensuite les distribs se basent sur ce qui est offert à un instant t. Gnome3 est opffert à un instant t ? Ben les distribs vont l'utilise -sauf backport ou autre-.

    Une distrib n'a pas vocation à maintenir les logiciels mais a proposer un ensemble cohérent.

    Si il y a autant de gens qui savent ce qui ne va pas dans systemd, pourquoi ne travaillent-ils pas ensemble pour faire quelque chose qui va? Je veux dire, on parle partout de l'ancien système et du nouveau, quand on voit le nombre de navigateurs libres, ça parait étrange qu'il n'y ai ici que deux softs en compétition…

    Peut etre que les gens travaillent mais se font pas mousser comme lennart ?
    Les init sur la gestion des dépendances c'est mis progressivement en place. Upstart aussi un moment.

    La différence, ca arrive pas en disant que "le reste c'est de la merde, moi je suis parfait c'est ca qu'il faut", et c'est compatible avec le reste. Alors forcément on en parle moins.

    Certains critiquent aussi le fait que ce soit compatible uniquement avec Linux, d'une part j'ai du mal à voir à quel point c'est vrai (il n'y a aucune chance de l'adapter à un autre noyau?), d'autre part en quoi est-ce un problème, ce n'est ni le dernier ni le premier des softs qui ne sont pas multi-plateformes, et si c'est si critiqué pourquoi les autres noyaux en voudraient?

    Un soft utilisateur mono plateforme c'est pas la même chose qu'un système d'init (central à la machine).

    Et si demain on considère que dbus c'est de la merde (oups désolé, c'est de la merde déjà), il faut changer tout ton sytème d'init pour changer un soft utilisateur.
    \o/ quelle avancée dis moi.

    bientot, on va avoir un système d'init spécifique si tu utilise gnome sur du nvidia, un système d'init différent si tu utilise kde sur de l'amd ou si tu utilise fwwm sur du intel
    quelle avancée extraordinaire.

  • # Commentaire supprimé

    Posté par  . Évalué à 9.

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

    • [^] # Re: Théorème de la mouche à merde

      Posté par  . Évalué à 4.

      La grosse différence, c'est que Windows est préinstallé sur chaque PC vendu. Les gens ne choisissent pas, puisqu'ils ne connaissent pas le reste.

      Là, ce sont les distributions qui incorporent Systemd de leur plein gré.

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

  • # System_D_inisme

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

    En tout cas on peut remercier l'ami Lennart d'avoir enclenché - sans le vouloir ? - un désintérêt progressif pour le féminisme des contributriceseurs du site.

    • [^] # Re: System_D_inisme

      Posté par  . Évalué à 10.

      Tu as raison, lennart fait des outils bien trop compliqué (et des trolls de bien trop haut niveau) pour une simple femme (et les apparentés tels les féministes).
      Lennart veut rendre linux a son propriétaire d'origine: le vrai barbu

      • [^] # Re: System_D_inisme

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

        Je sais que la mode est à l'épilation mode gonzo US, mais ne t'inquiète pas, les femmes peuvent te contenter niveau barbu si elles le veulent :o)

    • [^] # Re: System_D_inisme

      Posté par  . Évalué à 8.

      J'aurais dit qu'il a enclenché un désintérêt profond pour les références machistes, au profit d'un débat trollesque sur des questions purement techniques.

      Comme quoi il ne faut pas désespérer des geeks, quand on les pousse à bout, ils se concentrent sur l'essentiel :P

      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

  • # ou bien..

    Posté par  . Évalué à 7.

    J'ai une autre théorie qui va probablement me donner un karma négatif, mais cette idée m'a traversée l'esprit, je dois donc pas être le seul.

    Le problème c'est que Microsoft à toujours cru dur comme fer à sa console de gestion qui regroupe les Services et les Logs et que ce système à toujours été critiqué avec des raisons plus ou moins valable, du genre:
    - c'est une boîte noire
    - rien ne vaut un bon script shell
    - c'est pas assez configurable
    Etc
    Et v'la t'y pas que ce monsieur Lennart débarque et semble vouloir faire tout ce qu'on critiquait! Balayant nos arguments anti Windows
    Il manque plus qu'il developpe une base de donnée pour remplacer /etc et on sera obligé de dire Windows avait pas eut de si mauvaises idées que ça!

    Et je parle même pas du troll sur le libre qui n'innove pas et ne fait que reimplementer.

    Tu vois le soucis?

    • [^] # Re: ou bien..

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

      systemd est beaucoup plus inspiré de ce qui fait du côté de la pomme (launchd) que des fenêtres…

    • [^] # Re: ou bien..

      Posté par  . Évalué à 2.

      C'est marrant, c'est un système identique à ce que fait KDE avec ses kparts.

      Tout ce qui apparait dans la console de MS peut être appelé directement seul : le journal des évenements par eventvwr.exe, les services c'est services.msc.

      Et pour KDE : soit on lance Kontact et on a tout dans une fenêtre, soit on lance Kmail, puis Korganizer, etc

      Mais c'est KDE, donc c'est bien, c'est ça ?

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

      • [^] # Re: ou bien..

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

        Où il parle de KDE?
        Où il dit que le concept de composants enfichables est pourri ?

        • [^] # Re: ou bien..

          Posté par  . Évalué à 2.

          Où il parle de KDE?

          Nulle part, c'est moi qui pose la question : pourquoi critiquer systemd qui reprend le comportement de Windows et pas KDE ?

          Où il dit que le concept de composants enfichables est pourri ?

          En tout cas, je n'ai pas compris qu'il en disait du bien :

          • c'est une boîte noire
          • rien ne vaut un bon script shell
          • c'est pas assez configurable

          […]

          Et v'la t'y pas que ce monsieur Lennart débarque et semble vouloir faire tout ce qu'on critiquait! Balayant nos arguments anti Windows

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

          • [^] # Re: ou bien..

            Posté par  . Évalué à 1.

            Nulle part, c'est moi qui pose la question : pourquoi critiquer systemd qui reprend le comportement de Windows et pas KDE ?

            Parce que KDE est justement le contraire. Chaque kpart fait une chose et le fait bien. Ensuite, ton application ne fait que charger un kpart (kmail) ou plusieurs (kontact). Ce n’est pas un bloatware, mais pleins de briques qui s’assemble ensemble. Bref tout le contraire.

            • [^] # Re: ou bien..

              Posté par  . Évalué à 5.

              En quoi c'est différent des MSC ?

              Chaque MSC fait une chose et le fait bien. Ensuite, ta console ne fait que charger un MSC (services.msc) ou plusieurs (Poste de travail → Gérer l'ordinateur). Ce n’est pas un bloatware, mais pleins de briques qui s’assemble ensemble.

              Bref tout le contraire.

              Ben non.

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

              • [^] # Re: ou bien..

                Posté par  . Évalué à 2.

                Je ne connais pas cette techno.
                Bref j’ai relu le commentaire auquel tu répondais.
                Et oui, je suis d’accord, j’avais utilisé le partitionneur soit dans le panneau de contrôle soit en appli séparée.
                Je pensais que tu répondais à du KISS ou du bloatware… avec tous ces fils, je me suis perdu.

                Je citerais ma fille : « Oups, désolée ».

                • [^] # Re: ou bien..

                  Posté par  . Évalué à 3.

                  Pas de soucis. Ça me fait juste sourire quand je vois qu'on descend une technologie fermée (avec arguments techniques à l'appui) quand de l'autre côté on encense (ou on oublie dans le cas présent) la même chose qui se fait en libre.

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

  • # Cross compilation

    Posté par  . Évalué à 4. Dernière modification le 06 septembre 2012 à 21:45.

    Je me pose une question bien stupide…
    Imaginons que j'ai une toolchain d'une archi x86_64 vers une archi arm par exemple…
    systemd et toutes ses dépendances sont-elles cross-compilables?

    • [^] # Re: Cross compilation

      Posté par  . Évalué à 2.

      Uep.
      http://archlinuxarm.org/forum/viewtopic.php?f=15&t=3492&start=10#p20669

      D'ailleurs les paquets précompilés sont dispo pour archlinux-arm (armv5, armv6, armv7)
      http://archlinuxarm.org/packages (page 119)

      • [^] # Re: Cross compilation

        Posté par  . Évalué à 2. Dernière modification le 07 septembre 2012 à 00:08.

        Arch utilise distcc pour cross-compiler, n'est-ce-pas?
        Il faut donc avoir déjà booté la cible et avoir un client distcc dessus…
        Ma question est peut-être mal formulée.
        Comment Arch fait pour bootstrapper une archi cible?

        • [^] # Re: Cross compilation

          Posté par  . Évalué à 2.

          Les détails ici:
          http://archlinuxarm.org/developers/distcc-cross-compiling
          Mais n'est-on pas un peu hors propos?

          • [^] # Re: Cross compilation

            Posté par  . Évalué à 2.

            Merci pour le lien que je donne déjà…

            Non, je ne pense pas être hors sujet, et je vais faire moins de rhétorique.

            Pour bootstrapper un système sur une archi, j'ai besoin d'une toolchain, d'un chargeur de boot, d'un noyau, d'un init puis d'un userland minimal…
            Il est nécessaire de cross-compiler le tout en général. Si on se focalise sur l'init, on peut utiliser, pour faire simple soit l'init de busybox, soit l'init sys v car ceux-ci sont cross-compilables.
            Mais question est donc simple:
            Est-ce-que l'init systemd et ses dépendances sont cross-compilable sans user de distcc?
            Si, je parle de cela, c'est que je trouverais particulièrement cocasse, que pour bootstrapper systemd sur une archi, j'aurais besoin d'un init sys V (ou l'init de busybox).

  • # Système D

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

    Bon, c'est toujours difficile de se lancer à corps perdu dans un troll qui dure depuis plusieurs centaines de commentaires.

    Lennart ne m'enthousiasme pas du tout, je n'aime pas son attitude, on dirait qu'il se prend pour un sous-Linus, avec moins de classe et de répartie.

    Je n'utilise pas NetworkManager, je le vire dès que je le vois car j'ai eu pas mal de déboires avec lui (il cramait systématiquement ma config maison).
    De même, à mon niveau, j'ai plus (+) de soucis avec PulseAudio qu'avec les autres serveurs de son que j'ai pu connaître précédemment (je n'ai pas creusé la cause vu que j'ai toujours réussi à régler mes soucis en bidouillant un peu). Peut-être que le matériel n'y est pas pour rien.

    systemd, je suis mitigé. Je n'aime pas changer quelque chose qui "just works" pour moi. Mais les fois où j'ai fourré mon nez dans le système d'init pour une modif ou une autre, je n'ai pas été frappé par la simplicité du truc. Et je pense qu'on peut gagner en réactivité au boot avec un autre système.
    Une remise en question est probablement une bonne chose, même si l'éloignement probable avec les origines m'attriste un peu.

    J'espère juste que cela n'aura pas les défauts de NM ou PA, et surtout le même mépris pour les critiques envers ces deux outils.

    Mais je suis à l'abri quelques temps avec Debian.

    Voilà, j'aurais regretté de ne pas participer à la fête.

    Prochainement, je vous proposerai peut-être un commentaire constructif.

    • [^] # Re: Système D

      Posté par  . Évalué à 4.

      Je n'utilise pas NetworkManager

      Combien de fois faudra-t-il le dire ? NM c'est pas Lennart .

      • [^] # Re: Système D

        Posté par  . Évalué à 2.

        Ça vient de Red Hat, donc c'est pareil.

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

      • [^] # Re: Système D

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

        Il n'est même pas le dev principal du projet chez RedHat?

        Prochainement, je vous proposerai peut-être un commentaire constructif.

Suivre le flux des commentaires

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