Journal systemd un gros binaire ?

Posté par (page perso) .
Tags :
39
24
oct.
2012

On accuse souvent systemd de devenir un énorme SPOF. On l’accuse également d’intégrer énormément de services auparavant distincts : init, inetd, cron, syslog, udev, etc.

Pourtant, quand je lis la présentation de journalctl et d’autres billets de vulgarisation de systemd, je ne peux que reconnaître l’utilité et l’aboutissement du bousin face la bordée de scripts sh, perl, awk et sed qu’on utilise pour le même but, et qui rendent l’administration système si obscure à certains.

En lisant Lennart exposer méthodiquement un tas d’outils, je me suis demandé si systemd était vraiment si monolithique. Un simple coup d’œil à http://www.freedesktop.org/software/systemd/man/ — même en ignorant les pages man de développement — m’a convaincu que systemd est un projet conséquent, mais pas monolithique. Ça me rappelle l’architecture éprouvée de Postfix.

Quand on compare à la doc d’upstart, y’a pas photo : systemd est vraiment plus adapté aux adminsys UNIX. C’est structuré, tout est documenté en pages de man, et les cas d’utilisation concrets de l’admin sys sont pris en compte dans la conception.

À noter qu’upstart veut intégrer des fonctionnalités de cron

Bref, vivement qu’on puisse migrer nos serveurs Debian sur systemd. \o/

  • # migrer nos serveurs debian sur systemd

    Posté par . Évalué à  2 .

    systemd est d'ailleurs présent dans la Debian Wheezy, mais je ne sais pas du tout s'il est «bien» utilisé par Debian. J'ai plutôt l'impression que pour le moment il est en mode de compatibilité, car utilise tous les scripts d'init classiques de la Debian. Non ?

    • [^] # Re: migrer nos serveurs debian sur systemd

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

      Oui, c'est cela, systemd sous Debian est en mode compatibilité sysvrc, je suis pas sur que cela soit très utile de l'utiliser tel quel :)

      • [^] # Re: migrer nos serveurs debian sur systemd

        Posté par (page perso) . Évalué à  8 . Dernière modification : le 24/10/12 à 13:38

        Il y a quelques jours, à force de voir des trolls poilus à propos de Systemd sur linuxfr, je m'étais dit qu'il était temps que j'essaye pour savoir de quoi il retourne vraiment.

        En fait, sous Debian Testing, l'installation est assez simple et peu risquée (pour quelqu'un qui connait bien Linux j'entends):

        # apt-get install systemd
        # gvim /etc/default/grub
        on rajoute "init=/bin/systemd" aux options à passer au noyau
        # update-grub
        # reboot
        
        

        Le résultat pour moi fût un boot ~2x plus rapide. À première vue, Systemd parallélise aussi les fsck, ce qui très appréciable quand on a comme moi 4 disques d'1 To.

        Après il s'agit juste d'un poste de travail avec une installation relativement standard. Je n'ai aucun script de boot custom ou quoique-ce-soit de tordu. Donc je ne saurais pas dire si il va faciliter la vie à tout le monde. Tout ce que je sais, c'est que, moi, il me fait gagner du temps au boot.

        • [^] # Re: migrer nos serveurs debian sur systemd

          Posté par . Évalué à  8 .

          Systemd parallélise aussi les fsck, ce qui très appréciable quand on a comme moi 4 disques d'1 To.

          Et la dernière colonne (ou l'avant dernière je les confonds toujours) de fstab, elle servait à quoi ?

          Non parce que j'en ai marre d'avoir des commentaires à la "apple" où le "ceci est une révolution" alors que ça fait 25 ans que ça marche comme ça.

          • [^] # Re: migrer nos serveurs debian sur systemd

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

            Tu ferais mieux d'apprendre à quoi sert la dernière ligne… A donner l'ordre des fsck ou à les désactiver…

            Mais certainement pas à les paralléliser…

            • [^] # Re: migrer nos serveurs debian sur systemd

              Posté par . Évalué à  10 .

              Et toi tu ferais bien d'apprendre la différence entre une ligne et une colonne ;)

              ===> []

            • [^] # Re: migrer nos serveurs debian sur systemd

              Posté par . Évalué à  10 .

              RTFM

              The sixth field (fs_passno).

              This field is used by the fsck(8) program to determine the order in which filesystem checks are done at reboot time. The root filesystem should be specified with a fs_passno of 1, and other filesystems should have a fs_passno of 2. Filesystems within a drive will be checked sequentially, but filesystems on different drives will be checked at the same time to utilize parallelism available in the hardware. If the sixth field is not present or zero, a value of zero is returned and fsck will assume that the filesystem does not need to be checked.

              • [^] # Re: migrer nos serveurs debian sur systemd

                Posté par . Évalué à  3 .

                Il a raison, non ? La dernière colonne sert à définir un ordre ou à désactiver. Le parallélisme est par défaut. Je ne vois pas pourquoi le commentaire de gnumdk a été inutilisé. C'est débile. Il n'a pas dit que le parallélisme n'était pas géré avant…

                • [^] # Re: migrer nos serveurs debian sur systemd

                  Posté par . Évalué à  4 .

                  Il a raison, non ?

                  Oui.

                  Je ne vois pas pourquoi le commentaire de gnumdk a été inutilisé.

                  Peut-être parce qu'il a écrit ligne alors qu'il pensait à colonne, semant une confusion inacceptable ;)

                  C'est débile.

                  Non, c'est parce qu'il reprenait, pertinemment mais un peu sèchement, le commentateur auquel il répondait. Quand on fait ce genre de remarque il faut éviter de faire une erreur d'étourderie du genre ligne à la place de colonne (ou champ plus précisément).

            • [^] # Re: migrer nos serveurs debian sur systemd

              Posté par . Évalué à  2 .

              Big fail.

        • [^] # Re: migrer nos serveurs debian sur systemd

          Posté par . Évalué à  1 .

          on rajoute "init=/bin/systemd" aux options à passer au noyau

          C'est l'option "GRUB_CMDLINE_LINUX_DEFAULT" ou "GRUB_CMDLINE_LINUX" dans /etc/default/grub ?
          Parce que je l'ai installé également vu le nombre de commentaire actuellement à son sujet, mais pour l'instant je n'ai pas l'impression que ça ait changé quelque chose …

          • [^] # Re: migrer nos serveurs debian sur systemd

            Posté par . Évalué à  4 .

            GRUB_CMDLINE_LINUX_DEFAULT s'applique au label standard de grub , tandis que la seconde s'applique aux 2 labels ( normal et recovery )

            Sinon question idiote , t'as bien fait un update-grub ?

        • [^] # Re: migrer nos serveurs debian sur systemd

          Posté par . Évalué à  10 .

          tu peux faire un :
          $ systemd-analyze blame
          pour voir ce qui prend du temps

          un
          $ systemd-analyze time
          Startup finished in 582ms (kernel) + 2232ms (initramfs) + 6008ms (userspace) = 8823ms

          Pour voir le temps de boot (je boot entre 7 et 8 secondes avec une mageia 3 sur un core dans virtualBox… je pourrais encore en gagner en supprimant l'inird)

          un
          $ systemd-analyze plot
          pour obtenir un svg que tu pourras afficher dans Gimp.

          Ce sont des commandes qu'il est sympa de connaître. je sais pas si d'autres avant moi y pense à ces commandes.

        • [^] # Re: migrer nos serveurs debian sur systemd

          Posté par (page perso) . Évalué à  3 . Dernière modification : le 25/10/12 à 20:45

          Ça a marché à condition de supprimer le splash (ligne GRUB_CMDLINE_LINUX_DEFAULT) dans mon cas (j'avais configuré plymouth) sinon j'ai une erreur GLib au démarrage

        • [^] # Re: migrer nos serveurs debian sur systemd

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

          mais c'est pas plus rapide.

          Ici je lis

          It was not noticeable faster. That's because Debian's systemd honors /etc/rcS.d/ and /etc/rc2.d/. Every file in those directories are made implicitly into systemd services and started. But all of those files use lots of shell script magic, which make them slow.

        • [^] # Re: migrer nos serveurs debian sur systemd

          Posté par . Évalué à  1 .

          Bugs de systemd avec wheezy chez moi. Les 3/4 des services ne démarrent pas au boot. J'ai passé pas mal de temps à tester, modifier, retester, messages sur la liste debian, rien n'y fait, donc j'ai abandonné…

          "L'art est fait pour troubler. La science rassure" (Braque)

  • # troll !

    Posté par (page perso) . Évalué à  10 . Dernière modification : le 24/10/12 à 11:16

    systemd est vraiment plus adapté aux adminsys UNIX. C'est structuré, tout est documenté en page de man, et les cas d'utilisations concrets de l'admin sys sont pris en comptes dans la conception.

    Je suis désolé mais je fais de l'adminsys UNIX et j'ai aucune chance de voir systemd dans mes parc Unix vu que je n'ai aucun linux.

    Donc je demande des excuses publiques de l'auteur pour que la vérité soit révélée : systemd ne sera potentiellement, selon le point de vu, profitable qu'aux adminsys GNU/Linux qui se foutent royalement de tout les autres Unix qui existaient bien avant leur système d'exploitation de prédilection !

    • [^] # Re: troll !

      Posté par . Évalué à  2 .

      tout les autres Unix qui existaient bien avant leur système d'exploitation

      Les premiers ont toujours raison ?

      • [^] # Re: troll !

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

        Un vieux con a toujours raison selon son point de vue par rapport au jeune rebelle qui veut tout révolutionner. Suffit de sortir de chez soit pour le voir tout les jours dans la rue !

        • [^] # Re: troll !

          Posté par . Évalué à  10 .

          Entre deux cons alcooliques qui sont pas d'accord, je suis toujours pour celui qui est de la CGT :)

          Coluche

    • [^] # Re: troll !

      Posté par . Évalué à  -5 .

      Systemd ne sera peut-être pas sur les Unix, mais ils ont tous leur mer..de qui y ressemble fortement : svcadm pour solaris, le mélange rc.xx et /sbin/init.d d'AIX (avec ODB), HPUX et tru64 …
      Quand aux admin GNU/Linux … je ne suis pas sûr qu'ils "profitent" de ce nouveau "truc"
      Certes, les scripts d'init ne sont peut-être pas claires au néophyte, mais avec un peu de temps et de rigueur, tout le processus de boot peu être suivi et compris, systemd permettra de démarrer plus vite mais pour le deboggage du boot et sa compréhension, il faudra être beaucoup beaucoup plus patient.

      Enfin, avant qu'il ne soit généralisé, il y a encore un peut de temps ….

      ;-)

      • [^] # Re: troll !

        Posté par . Évalué à  4 .

        Explique moi quel est l'équivalent de systemd sur HP-UX tiens. J'attends. Et je tiens à rappeler que le chamboulement introduit par Solaris 10 dans le process de démarrage a fait le même bruit.

    • [^] # Re: troll !

      Posté par . Évalué à  1 .

      aux adminsys GNU/Linux qui se foutent royalement de tout les autres Unix

      aux adminsys GNU/Linux aux Lennart qui se foutent royalement de tout les autres Unix

    • [^] # Re: troll !

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

      Et ça marche comment sous Mac OS X Server ?

      • [^] # Re: troll !

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

        Je pense avec launchd, http://en.wikipedia.org/wiki/Launchd

        Ceci dit, je suis pas sur que os x server existe encore.

        Et d'ailleurs, je trouve amusant de voir que quelqu'un a porté launchd sur freebsd dés 2005. Ça prouve qu'à l'époque, au moins un dev de freebsd pensait que ça serait utile de changer le sacro saint init. Sans doute un mec infiltré de Apple

    • [^] # Re: troll !

      Posté par . Évalué à  5 .

      systemd ne sera potentiellement, selon le point de vu, profitable qu'aux adminsys GNU/Linux qui se foutent royalement de tout les autres Unix qui existaient bien avant leur système d'exploitation de prédilection !

      Et sinon, on a le droit d'apprécier systemd sans être un gros connard qui a envie que le reste du monde autour crève dans la faim et la douleur avec du tabasco plein les yeux ?
      Parce que vu d'ici, ton commentaire me fait penser à une personne qui se fout royalement de tous les autres systèmes qui existent et qui ne sont sont système de prédilection.

  • # Et sinon...

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

    plutôt mayonnaise, ketchup ou moutarde ?

    • [^] # Re: Et sinon...

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

      Aucun des trois : je mange mon steak nature !

      • [^] # Re: Et sinon...

        Posté par . Évalué à  -2 .

        Moi je mets du Tabasco sur mes filets de poisson lune !

        Poisson lune avec des piques

        • [^] # Re: Et sinon...

          Posté par . Évalué à  5 .

          En réalité, il s'agit d'un poisson-globe (ou poisson-ballon ou Fugu).

          • [^] # Re: Et sinon...

            Posté par . Évalué à  10 .

            Oui, et il faut éviter de les faire gonfler à la surface car ils aspirent de l'air et pas de l'eau, et après c'est la galère pour eux de retrouver leur forme normale (sans compter qu'ils flottent dans ce cas là).

          • [^] # Re: Et sinon...

            Posté par . Évalué à  0 . Dernière modification : le 24/10/12 à 13:55

            J'avais conscience d'être à coté. Cependant poisson globe me redirige vers Tetraodontidae où il est écrit :

            Les Tetraodontidés (Tetraodontidae) (du grec ancien tetra = quatre et odous = dent) ou poissons-ballons forment une famille de poissons ayant la capacité de gonfler. Une autre de leurs caractéristiques est de ne pas avoir de piquants, ce qui les distingue des Diodon qui en ont.

            C'est donc à priori un diodon sur la photo. Ce qui correspond plus au poisson mascotte d'OpenBSD.

            Celui là peut-être :

            Diodon_liturosus

            Diodon_liturosus.jpg

    • [^] # Re: Et sinon...

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

      Pour les frites, mayonnaise, mais faite maison bien sûr, pas de la merde industrielle sans saveur.

      Pour la viande, je suis plutôt moutarde.

      Et là c'est malin, parce que tu m'as donné faim, et il n'y a aucune friteuse autour de moi!!

  • # Un exemple de fichier .service (lancement de boinc)

    Posté par . Évalué à  10 .

    Je profite de l'occasion pour partager un exemple de fichier .service que je suis parvenu à écrire :

    $ cat /etc/systemd/system/boincsystemd.service
    
    

    [Unit]
    Description=Logiciel boinc lancé par systemd
    
    [Service]
    WorkingDirectory=/boinc_user/BOINC
    User=boinc_user
    Nice=10
    IOSchedulingClass=idle
    ExecStart=/boinc_user/BOINC/boinc
    ExecStop=/boinc_user/BOINC/boinccmd --quit
    Type=simple
    
    [Install]
    WantedBy=multi-user.target
    
    

    Ce fichier sert à lancer et stopper le démon boinc. Il remplace le fichier /etc/rc.d/boinc (ou /etc/init.d/boinc sous Debian) et est, à mon avis, plus lisible.

    Le tutoriel complet est disponible sur ce lien. Voir le manuel de systemd pour la signification des différentes options.

  • # La comparaison avec Upstart est superflue...

    Posté par . Évalué à  7 .

    Upstart ne tiens absolument pas la comparaison vis à vis de systemd…
    http://0pointer.de/blog/projects/why.html

    On se demande pourquoi Ubuntu continue à l'utiliser (mis à part une question d'ego) car systemd résout mieux les problématique que Upstart devait résoudre!

    Je me demande également pourquoi il n'y a pas eut le foin qu'il y a autours de systemd quand Upstart est sorti? Parce que systemd a du succès (là où upstart est resté cantoné à Ubuntu)?

    le seul débat qu'il reste est bien entre systemd et SysV… Peser les avantages qu'il apporte avec les inconvénients…

  • # Philosophie Unix != Linux ?

    Posté par . Évalué à  10 .

    Une de première chose que l'on m'a enseigné quand je suis entré dans le monde fabuleux des *nix est sa philosophie.
    Dont "Un outils pour une fonction" qui en dérivait impliquait que cet outil fasse peut de chose mais le fasse bien.

    Ensuite j'ai découvert la philosophie KISS
    "Keep It Simple Stupid"
    Donc laisser les choses les plus simple possible pour ne pas à avoir se faire des nœuds au cerveau pour comprendre comment cela fonctionne.

    Donc les UUID je trouve ça anti-KISS. J'ai bien compris l'avantages mais je le trouve faible comparativement à l'obscurcissement de la configuration.

    Pour systemd, je comprend bien les divers avantages, merci les super dépêches de ce site. Le fait d'avoir des journaux en binaire, je met ça au même niveau que les UUID, mais en plus il réunit tout un tas d'outils qui peuvent tout à fait être indépendant. On se dirige petit à petit vers un assemblage de quelques gros bloques (Kernel, système d'init, serveur d'affichage, serveur son, environnement graphique, …) pour faire une distro. Ne va t on pas perdre en diversité ? En personnalité des distros ?

    Je sens que systemd apporte de bonne chose, mais aussi des désavantages qui ne sont pas négligeable. Au final devra t on se tourner vers d'autres OS (*BSD, Haïku, ….) pour pouvoir bidouiller comme bon nous semble ?

    • [^] # Re: Philosophie Unix != Linux ?

      Posté par . Évalué à  8 .

      Tu l'as bien dit, KISS est une philosophie.

      Pour moi, il faut l'avoir en tête pour tendre vers ça mais il faut aussi savoir faire des concessions.

      Ca me rappelle un cas où un message de Linus (qui me semble est un bon représentant de la notion de KISS) où il disait qu'il était pas fan du fait que le système de fichier (en l'occurrence btrfs) fasse des choses jusqu'à présent réservées au userspace mais qu'apparemment, c'était la meilleure solution pour avoir quelque chose d'optimal.

      Il me semble que systemd est dans le même cas.

      Et puis, si on était TOUS des intégristes du KISS, je vois pas pourquoi on utilise Linux. Hurd (ou minix) aurait beaucoup plus de succès que Linux, non?

      • [^] # Re: Philosophie Unix != Linux ?

        Posté par . Évalué à  4 .

        Il me semble que systemd est dans le même cas.

        Perso toujours pas vu où est l'argument permettant de dire ça.

        • [^] # Re: Philosophie Unix != Linux ?

          Posté par . Évalué à  3 .

          On attends aussi l'argument permettant de dire le contraire.

          A part des enoncer des grands principes aussi bateau que "petit a petit l'oiseau fait son nid", "tout vient a point a qui sait attendre", "Neige en Novembre, noel en Decembre" ou encore "En Avril ne te decouvre pas d'un fil, en Mai va te faire enculer".

          En gros, les arguments contre systemd se resument a:
          - ZOMG je vais devoir apprendre qq chose
          - c'est pas KISS et c'est trop complique (parce que 150 lignes de shell, c'est vachement KISS, evidemment)
          - ca va a l'encontre d'UNIX (on sait toujours pas pourquoi)
          - ya des bugs (elle est pas mal celle la dans la bouche de linuxien)
          - moi j'en ai pas besoin, donc personne en a besoin
          - baaah, on a toujours fait comme ca!

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

          • [^] # if it ain't broke, don't fix it

            Posté par . Évalué à  4 .

            Pourquoi changer quelque chose qui fonctionne ?

            Finalement c'est bien ça qui me dérange. Le système d'init est ce qu'il est mais il fonctionne pas trop mal depuis des lustres (enfin je n'ai jamais eu à m'en plaindre).
            La vitesse de boot ? Hum à part des concours de la plus grosse, je ne vois pas à quoi ça va m'avancer (moi je joue au concours de l'uptime :))

            Mon système actuel m'offre un système fiable/stable/simplissime depuis longtemps et comme je me fiche pas mal du "progrès" pour le progrès…

            Sans parler de tous les changements que ça induit et tout ce que ça tire derrière (fstab, automount/autofs, …)

            A la rigueur le seul truc qui m'attirerais serait la syntaxe des .services qui, il faut bien le reconnaitre, est beaucoup plus concise que les rc du coin ;)

            Perso, sur mes slack, j'observe de loin et je compte les points en espérant très fort que cette "révolution" ne m'atteigne pas (trop vite).

            • [^] # Re: if it ain't broke, don't fix it

              Posté par . Évalué à  -5 .

              Pourquoi changer quelque chose qui fonctionne ?

              Parce que ca a 30 ans et qu'on fait des trucs vachement mieux depuis. Ca s'appelle le progres.
              Quasi tous les autres unices ont laisse tombe sysvinit, a commencer par l'unix le plus populaire chez le grand public (un indice, en fait il est deux et leur noms ne commencent pas par un A et ne finisse pas par un d), ou Solaris, c'est bien qu'il ya une raison, non?
              Surtout que la plupart des distros qui pesent suivent la mouvance, c'est peut etre qu'ils pensent que ya qq chose a y gagner, non?

              La vitesse de boot ? Hum à part des concours de la plus grosse, je ne vois pas à quoi ça va m'avancer (moi je joue au concours de l'uptime :))

              Regardes vers l'avenir, du cote mobile ou laptop. Un boot quasi instantane est tres appreciable dans ce domaine. Et pour la millième fois, c'est pas la feature principale de systemd, juste un effet de bord appreciable.
              Ta tele boot instantanement ou presque, ya pas de raison que ton telephone ou ton laptop ne fasse pas pareil.

              Sans parler de tous les changements que ça induit et tout ce que ça tire derrière (fstab, automount/autofs, …)

              Oh mon dieu! Un changement! Etonamment, personne ne hurle au changement quand la librarie son de la saison sort, quand KDE pete tout, quand gnome pete tout, quand linux pete une API ou que sais je encore. Wayland sort et personne ne vient gueuler que c'est un gros changement.

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

              • [^] # Re: if it ain't broke, don't fix it

                Posté par . Évalué à  8 .

                En quoi est-ce le progrès, vraiment, personne n'est en mesure de le dire c'est bien qu'il y a quelque chose qui cloche, non ? Le fait que le système actuel date un peu est bien un gage de fiabilité, non ? Et ce n'est pas parce que une poignée d'unices (morts) font des changements qu'il faut à notre tour "embrasser ce mouvement".

                Et oui, je suis plus virulent contre systemd qui touche aux fondements de mes machines que kde/gnome/wayland ou que sais-je que je n'utilise pas. Si KDE/Gnome pète tout à chaque release, les utilisateurs peuvent aisément s'orienter vers autre chose. Pour systemd, ça parait plus délicat. systemd me fait penser à PAM: quelque chose de délibérément (ou pas) très compliqué à appréhender (utiliser ?). Chez moi, on appelle ça une usine à gaz. Aujourd'hui, slackware n'a toujours pas PAM et on vit bien (mieux?).

                Je me doute que beaucoup de gens vont passer à systemd par la force des choses; je ne suis pas convaincu que ce soit de gaité de coeur ou un choix sciemment assumé :)

                • [^] # Re: if it ain't broke, don't fix it

                  Posté par . Évalué à  9 .

                  je suis plus virulent contre systemd qui touche aux fondements de mes machines

                  La coloscopie, ça ne laisse personne indifférent.

                • [^] # Re: if it ain't broke, don't fix it

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

                  Chez moi, on appelle ça une usine à gaz.

                  L'exemple de la syntaxe des services est là pour montrer que, du point de vue admin, c'est simple d'utilisation.
                  Pareil pour journalctl. Est-ce que tu es allé lire le post sur le blog de Lennart ? Franchement ça donne envie parce que ça a l'air très puissant et facile à utiliser.

                • [^] # Re: if it ain't broke, don't fix it

                  Posté par . Évalué à  4 .

                  En quoi est-ce le progrès, vraiment, personne n'est en mesure de le dire.

                  Une discussion a déjà eu lieu à cet endroit sur les avantages de systemd.

                • [^] # Re: if it ain't broke, don't fix it

                  Posté par . Évalué à  1 . Dernière modification : le 26/10/12 à 12:24

                  Le fait que le système actuel date un peu est bien un gage de fiabilité, non ?

                  T'as raison. Je vais revendre ma Y et acheter une 2CV. Ça date mais au moins c'est fiable. Et tant pis pour le confort.

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

                  • [^] # Re: if it ain't broke, don't fix it

                    Posté par . Évalué à  2 .

                    C’est vrai que la rouille, c’est un problème très grave dans le développement logiciel. Ce doit être pour ça que mon médecin du travail me rappelle régulièrement que je suis pas à jour sur mon vaccin du tétanos…

                  • [^] # Re: if it ain't broke, don't fix it

                    Posté par . Évalué à  0 .

                    Ce n'est pas le rapport… Les bagnoles d'aujourd'hui utilisent toujours le même principe fondamental pour le moteur (qui pourtant sont plus performants) et la roue (qui pourtant est plus fiable). Et à propos de confort, faut-il que ce soit la contrepartie de la fiabilité (nombre d'automobiles de nos jours sont à l'instar de nombre de produits de consommation à la con : juste jetable…) ;-(

              • [^] # Re: if it ain't broke, don't fix it

                Posté par . Évalué à  4 .

                quand la librarie son de la saison sort

                C’est pas mon problème, c’est le problème des devs des logiciels qui choisissent leur lib en fonction de leur besoin.

                quand KDE pete tout, quand gnome pete tout

                J’ai ni Gnome ni KDE sur mes serveurs. Et si tu as entendu personne râler là dessus, c’est que tu vis dans une grotte.

                quand linux pete une API ou que sais je encore

                Parce que les API du noyau n’ont pas vocation à être stables ? Parce que les changements sont là pour justement éviter une explosion de la complexité ? (coucou, on doit maintenir 3 apis différentes y compris les bugs dans les vieilles apis)

                Wayland sort et personne ne vient gueuler que c'est un gros changement.

                Parce que ce changement vise à simplifier les choses et non les complexifier ?

              • [^] # Comment ça, personne ne hurle ?

                Posté par . Évalué à  1 .

                Etonamment, personne ne hurle au changement quand la librarie son de la saison sort,

                Pulseaudio, je vire.
                J’ai beaucoup râlé dessus aussi.

                quand KDE pete tout,

                J’ai arrêté avant la 3. Trop instable (quand c’est stable, ils refont une nouvelle version), temps d’ouverture de session rédhibitoire.

                quand gnome pete tout,

                Je jette et j’ai beaucoup râlé dessus. L’Ignominie, enfin Gnome Shell, est le seul logiciel libre que je hais. Je n’aurais jamais cru ça possible, une belle réussite, donc.

                Wayland sort et personne ne vient gueuler que c'est un gros changement.

                J’ai déjà râlé avant que confier la gestion des décorations aux applications, c’est n’importe quoi. Au delà, je n’y passerai pas avant qu’il y ait un environnement correct dessus (du genre Xfce).

                En fait, j’ai moins cassé systemd, probablement parce qu’il est bien conçu et bien documenté. Après, le système qu’on obtient avec lui n’est plus vraiment un Unix et il n’est pas fini (surtout sur Fedora, qui garde bien les vieilles versions et leurs bugs gênants après la sortie de la distribution)… J’aurais préféré que d’autres projets ne le rendent pas incontournable (Policy Kit…) et qu’on continue aussi d’avoir des distributions Linux sauce Unix.

                Et je me rappelle bien ne pas avoir été le seul à râler sur ces divers sujets.
                En fait, tu as juste la mémoire courte ou sélective.

                Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

                • [^] # Re: Comment ça, personne ne hurle ?

                  Posté par . Évalué à  -1 .

                  Et a part gueuler, donc, tu fais quelque chose?
                  Apparement, t'as rale contre la plupart des gros projet du libre ces derniers temps, si ca ajoute pas de l'eau au moulin "resistance au changement/jamais content", je sais pas ce que c'st.
                  Parce qu'a te lire, j'ai l'impression que t'as un avis sur tout, mais que dans le fond, t'as surtout un avis.

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

            • [^] # Re: if it ain't broke, don't fix it

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

              Pourquoi changer quelque chose qui fonctionne ?

              Parce qu'il ne fonctionne pas si bien que ça. Peut-être que ça te suffit à toi mais plein de gens aimerait autre chose. Ce n'est pas pour rien qu'on le retrouve dans plein de distribution.

              « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

            • [^] # Re: if it ain't broke, don't fix it

              Posté par . Évalué à  4 .

              Pourquoi changer quelque chose qui fonctionne ?

              C'est pas parce que ça fonctionne que c'est bien. Au hasard, ça peut être chiant à administrer, à debogguer, à faire évoluer, etc.

              Je suppose que tu es aussi contre Wayland ? Après tout, Xorg fonctionne.

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

          • [^] # Re: Philosophie Unix != Linux ?

            Posté par . Évalué à  10 .

            • ZOMG je vais devoir apprendre qq chose

            Dans le monde réel, pas dans le monde des bisounours OMG c’est nouveau donc c’est bien (c’est facile de caricaturer le point opposé n’est-ce pas ?), la formation a effectivement un coût, si derrière ce coût il y a un avantage ok pour le changement, si par contre c’est juste pour faire plaisir à deux technophiles chez redhat qui se touchent la nouille sur « mon nouveau design est tellement meilleur que maintenant init peut automatiser les pauses café de toute les machines à café de l’entreprise, chose qu’on pouvait pas faire avant », je crois que beaucoup de DSI préfèreraient largement dire « je passe ».

            c'est pas KISS et c'est trop complique (parce que 150 lignes de shell, c'est vachement KISS, evidemment)

            Tu n’es évidemment pas développeur pour raconter des âneries pareil, la complexité ne se mesure évidemment pas en nombre de lignes de code. La simplicité se réfère à trois axes :
            - simplicité de conception : plus le système a des fonctionnalités différentes qui interagissent entre elles, plus le système est complexe. Sur ce point, systemd « j’intèggre udev, un système de log, un système d’init, un système de gestion de processus, un système de gestion de sockets, une palanquée de services DBUS pour faire plaisir aux devs gnome » est infiniment plus complexe oui
            - simplicité d’implémentation : de manière évidente, plus la conception est complexe, plus l’implémentation l’est
            - simplicité d’interface (présenter une interface à l’utilisateur qui soit simple, minimale, sans surprise) : même combat, sans une conception simple tu ne peux pas avoir une interface simple (la réciproque n’est pas automatiquement vraie, ne me faites pas dire ce que je n’ai pas dit)

            Et si la simplicité est à ce point invoquée comme argument, c’est qu’elle a des avantages concret, pas pour se toucher la nouille « quelqu’un a dit un jour que la simplicité c’était bien donc on va le répéter comme des ânes », que ce soit en terme de coûts, de fiabilité ou de flexibilité. Alors oui, « coût », « fiabilité » et « flexibilité » c’est pas une super liste de fonctionnalités sur lesquelles on peut se gausser, donc forcément les ayatollah de la nouveauté inconditionnelle à courte vue peuvent dire « systemd a plus de fonctionnalités donc systemd est plus bien ».

            • ya des bugs (elle est pas mal celle la dans la bouche de linuxien)

            Engineering 101 : plus un système est complexe, plus il a de possibilités de merder.

            Bon sens de base : plus un système est utilisé (à la fois en temps et en nombre), moins le nombre de bugs encore inconnus est élevé. On reproche justement sa vieillesse au vénérable sysvinit ? C’est précisément ce qui fait sa fiabilité.

            Encore une fois : ça veut pas dire qu’il faut pas changer, ça veut dire qu’il faut mettre en face les fonctionnalités apportées par le changement avec la quasi-certitudes qu’il faudra essuyer les plâtres pendant de nombreuses années. Si la fonctionnalité apportée c’est « on remplace des scripts shell par des ini-like, saytrobien ! » (ou pire : c’est nouveau donc c’est le progrès donc c’est bien ma bonne dame), je suis quelque peu dubitatif sur la pertinence du changement.

            • moi j'en ai pas besoin, donc personne en a besoin

            Non, c’est : pourquoi imposer la migration à ceux qui en ont pas besoin ?

            Scoop : c’est pas les contradicteurs à systemd les intégristes qui pensent qu’à leur cas particulier qui en font une généralité. Personnellement, j’avais déjà installé systemd sur un de mes serveurs, qui avait besoin de quelques fonctionnalités de systemd qu’on avait implémentées sous la forme de scripts maison. Dans ce cas précis évidemment, coûts de maintenance des scripts maison > coût de migration + maintenance de systemd, donc on est passé à systemd.

            Par contre, sur mes autres serveurs systemd n’apporte rien d’autre que des emmerdes et des dépenses, donc quand on me dit « c’est le progrès donc c’est bien », j’ai tendance légèrement à rire jaune, tu comprends ?

            • [^] # Re: Philosophie Unix != Linux ?

              Posté par . Évalué à  4 .

              Tu n’es évidemment pas développeur pour raconter des âneries pareil, la complexité ne se mesure évidemment pas en nombre de lignes de code. La simplicité se réfère à trois axes :

              Moi je suis développeur, j'ai le droit de raconter des âneries ?

              • simplicité de conception : plus le système a des fonctionnalités différentes qui interagissent entre elles, plus le système est complexe. Sur ce point, systemd « j’intèggre udev, un système de log, un système d’init, un système de gestion de processus, un système de gestion de sockets, une palanquée de services DBUS pour faire plaisir aux devs gnome » est infiniment plus complexe oui

              C'est d'ailleurs pour cela que linux est un micro noyau et pas un noyau monolithique… hheeuuu, attends une minutes là…
              Bon, pour faire simple, tous les systèmes de dont tu parles sont présents sur ta machine et interagissent déjà entre eux. À partir de là, je reste quand même convaincu qu'il est plus simple de les faire gérer par le même sous système.

              • simplicité d’implémentation : de manière évidente, plus la conception est complexe, plus l’implémentation l’est

              Oui, et ???
              L'init est complexe, d'ailleurs, si j'en crois ton message, il y a de la gestion de service, de log, de matériel, d'ordonnancement de tâches.
              Et ça c'est très complexe, d'ailleurs, j'y comprends rien moi perso, c'est bien que c'est très complexe (tm) (r) (c) !!
              Et l'implémentation actuelle, n'en parlons même pas, des tas d'applications et de services dans tous les sens, avec des syntaxes différentes pour chacun, des milliers de lignes de script de partout, appelées dans tous les sens, de la configuration complètement éclatée dans tout /etc

              • simplicité d’interface (présenter une interface à l’utilisateur qui soit simple, minimale, sans surprise) : même combat, sans une conception simple tu ne peux pas avoir une interface simple (la réciproque n’est pas automatiquement vraie, ne me faites pas dire ce que je n’ai pas dit)

              Bah pareil aussi, l'interface actuelle est tout sauf simple et sans surprise.
              Régulièrement, quand j'ai à changer des choses (ça n'arrive pas souvent ok) je dois me battre pendant plusieurs heures à chercher comment ça marche, par où cela peut bien passer, quel script est appelé avant quel autre, où est la config de telle chose, …
              Je sais pas si je mettrait plus ou moins de temps avec systemd, mais ce qui est sûr, c'est actuellement, c'est une merde sans nom !
              La simplicité d'interface de l'ensemble des services ultra trop kikou-kiss-lol-un-tache-comme-il-faut-par-appli de unix qu'elle est bien, c'est quelque part entre une blague hongro-guatémalaise sur les choux fleurs et les curés et la maison qui rend fou des 12 travaux d'astérix

              Pour conclure, définitivement, d'un point de vu d'un développeur qui dit des âneries, si un système doit gérer 10 services qui ont besoin de s'échanger des informations, qui le tout doit-être stable et sécurisé, et facile à maintenir.
              Je fais le tout dans un seul projet, je fais un superviseur qui chapôte tout ça, fait communiquer le tout et maintiens la cohérence de l'ensemble, gère les services de base dont tout le monde à besoin, et des modules pour chaque service distinct suffisamment autonome.
              Je mets en place une ipc centrale qui permet à tous mes client d'accéder à mes services de façon uniforme, claire et documentée.
              C'est marrant ça me fait vaguement penser à systemd, et en poussant un peu plus loin, même à l'organisation modulaire du noyau ! C'est que ça ne doit pas être une si mauvaise idée que ça ! D'un point de vue d'un développeur, bien sûr !

              • [^] # Re: Philosophie Unix != Linux ?

                Posté par . Évalué à  9 .

                Bon, pour faire simple, tous les systèmes de dont tu parles sont présents sur ta machine

                Non. inetd et atd ne sont pas installés partout par exemple. Et j’ai jamais utilisé ni les cgroups ni les capabilities (je dis pas que ça me servira jamais ou que personne en a l’usage, je dis que actuellement c’est une complexité qui est ABSENTE de mon système d’init. Note bien : absente, pas qui est présente mais que j’ignore).

                et interagissent déjà entre eux

                Non. Chez moi crond n’interagit pas avec apache.

                La conception de l’init actuel est quand même simple : le kernel lance init. Ce dernier lit /etc/inittab qui liste deux choses (la liste étant fonction uniquement du runlevel) :

                • Les services à lancer/(relancer en cas d’arrêt), généralement uniquement les tty sont listés ici
                • Les scripts à lancer une fois au démarrage.

                Ces derniers s’occupent de l’initialisation du système (montage de la partition racine, réinitialisation de l’horloge système, etc), puis lancent les scripts de démarrage des services placés dans /etc/rcx.d (x fonction du runlevel), puis un script de finalisation (vide par défaut mais utilisé par l’administrateur) dans /etc/rc.local

                Voilà, je t’ai décrit succinctement mais EXHAUSTIVEMENT le fonctionnement de sysvinit. La gestion des services on-demand, la crontab, les cgroups n’apparaissent pas ? Normal, c’est pas son rôle.

                Je te met au défi de m’expliquer le fonctionnement EXHAUSTIF de systemd aussi rapidement. Tu n’y arriveras évidemment pas parce que toi tu devras parler de toutes les solutions spécifiques à des problèmes spécifiques, comme justement les cgroups, les socket activation, etc.

                Elle est là la différence de complexité de conception.

                • [^] # Re: Philosophie Unix != Linux ?

                  Posté par . Évalué à  1 .

                  Non. Chez moi crond n’interagit pas avec apache.

                  Même pas par effet de bord de logrotate ?

                • [^] # Re: Philosophie Unix != Linux ?

                  Posté par . Évalué à  5 .

                  Cool, une réponse :)

                  Non. inetd et atd ne sont pas installés partout par exemple.

                  et bien du coup ils ne seront plus installés nulle part ! Il est où le problème ?

                  Et j’ai jamais utilisé ni les cgroups ni les capabilities (je dis pas que ça me servira jamais ou que personne en a l’usage, je dis que actuellement c’est une complexité qui est ABSENTE de mon système d’init. Note bien : absente, pas qui est présente mais que j’ignore).
                  Ce sont des fonctionnalités de ton système là, rien à voir avec l'init, que le système d'init s'en serve est très bien et n'ajoute pas de complexité inhérente à ce que tu fais. Le système d'init actuel se sert de fork, d'exec, d'open, de read, … ça ne le rends pas plus complexe, ce sont des services de l'os.
                  Le système actuel à même besoin d'un interpréteur très évoluer pour exécuter les script, ce que systemd ne requiert pas, donc sur ce terrain là, pas sûr qu'init soit gagnant à la comparaison.

                  Voilà, je t’ai décrit succinctement mais EXHAUSTIVEMENT le fonctionnement de sysvinit.

                  La blague, ce que tu ma décris, c'est effectivement ce que fait init, mais il manque toute la complexité, qui elle est planquée dans les scripts de démarrage des services, la gestion des dépendences, des configurations, des demons, du respawn, …
                  init fait une chose et le fait bien, mais ce qu'il fait est complètement inutile et demande l'intervention de tas d'autres choses pour un résultat qui résous mal la moitiés des problèmes d'un init d'un système digne de ce nom. Toute la partie complexe est laissée ailleurs (scripts de démarrage, interpréteur ultra complexe et pas kiss du tout pour le coup, personne n'en parle de celui là tien, ordre de démarrage des services, configuration et paramètres de démarrage, …).
                  Systemd la résoud pour toi. Et c'est exactement la bonne chose à faire, prendre en charge et mutualiser la partie complexe pour ne laisser que les choses simple et spécifique aux services à démarrer à l'utilisatur/administrateur/écrivateur de services à démarrer.

                  La gestion des services on-demand, la crontab, les cgroups n’apparaissent pas ? Normal, c’est pas son rôle.

                  Pas son rôle ?? tu veux dire qu'il ne sait pas faire oui !
                  La gestion des services on-demand, il n'en a aucune espéce d'idée, le on-demand=tout le temps pour init, génial ! Si on a écrit d'autres sous système pour faire ça par la suite, c'est juste que le besoin est arrivé plus tard et que personne n'a eu la bonne idée de modifier init pour ça cr il aurit fallu aussi changer tous les scripts de lancement, s'assurer que les services n'ont pas de problèmes, alors que là, on laissait seulement les services qu'on voulait dans inetd (ou autre) avec du coup un script de démarrage et des options différentes… bonjour la simplicité d'interface dont tu parlais avant !
                  Les cgroups ? ça n'existait même pas quand init a été conçu. Et une fois encore, c'est une fonctionnalité de l'os, les utiliser est un détail d'implémentation du même accabit qu'utiliser fork au autre chose.
                  Cron ? à vérifier mais pas sur que systemd sache gérer ça, à mon avis c'est un plugin ou un service à part (ou en tous cas, ça devrait l'être, sinon c'est mal fichu), qui me fait revenir donc à mon message précédent, un superviseur qui mutualise et des plugins pour les différentes tâches. En fait, plus tu m'en parles et plus je cherche les bonnes réponses au problème, plus je suis convaicu que systemd s'en approche 1000 fois plus qu'init !
                  D'ailleurs, s'il s'appelle systemd et pas newinitd, c'est bien que c'est le deamon de gestion du systeme et pas de l'init !

                  Je te met au défi de m’expliquer le fonctionnement EXHAUSTIF de systemd aussi rapidement. Tu n’y arriveras évidemment pas parce que toi tu devras parler de toutes les solutions spécifiques à des problèmes spécifiques, comme justement les cgroups, les socket activation, etc.

                  1) je n'y arriverai pas parce que je n'en ai aucune idée, je ne l'utilise pas et je n'en ai que lu des choses par ci par là et je m'en fait mon idée petit à petit, mais je reste dans une approche de haut niveau, je ne suis pas rentré dans les détails encore.
                  Mais de ce point du vue là, l'approche me parait plus que pertinente !

                  2) les sockets d'activation résolvent un (des) problème spécifique qu'on tous les demons : lancement à la demande (d'accord, pour un système en production, c'est pas forcément toujours utile, on veut que le service soit lancé en permanence pour répondre au quart de tour), supervision du service lancé, ordre de démarrge (peut-être d'autres, je ne vois que ceux là pour l'instant) !! du coup c'est plus très spécifique, et les cgroups, et bien c'est un choix d'implémentation, mais ça reste une fonctionnalité du noyau, pas de systemd !

                  J'en reviens toujours au même, on mutualise la complexité dans systemd, pour simplifier la gestion autour, en fait, tous les admin système devraient être super content !! Pourquoi vous râlez au juste ?? Quelqu'un peut m'expliquer ?

                  • [^] # Re: Philosophie Unix != Linux ?

                    Posté par . Évalué à  5 .

                    et bien du coup ils ne seront plus installés nulle part ! Il est où le problème ?

                    Que tout la complexité de ces sous-système, actuellement optionnelle, sera installé maintenant partout de base.

                    Pas son rôle ?? tu veux dire qu'il ne sait pas faire oui !

                    Je ne vois pas la différence entre les deux propositions. Pas son rôle, sait pas faire, c’est du pareil au même.

                    c'est juste que le besoin est arrivé plus tard et que personne n'a eu la bonne idée de modifier init pour ça cr il aurit fallu aussi changer tous les scripts de lancement, s'assurer que les services n'ont pas de problèmes, alors que là, on laissait seulement les services qu'on voulait dans inetd (ou autre) avec du coup un script de démarrage et des options différentes… bonjour la simplicité d'interface dont tu parlais avant !

                    C’est très précisément systemd que tu décris là, pas init.

                    init n’a aucune idée de ce qu’est un « script d’init », justement, et c’est pour ça que toute modification dans init a au final très peu de chances (j’ose pas dire nulle parce que le risque 0 n’existe pas, mais c’est tout comme) d’influer sur les scripts d’init. C’est précisément systemd qui a le souci « faut tout tester quand on change quoi que ce soit », parce que justement absolument tout est dans le même exécutable qui gère tout.

                    Avec le système actuel, un changement concernant un besoin spécifique (exemple : lancement à la demande) n’affecte que les scripts de lancement qui sont concernés par ce besoin spécifique. Avec systemd par contre, un besoin spécifique demande un changement dans le binaire systemd, changement qui peut potentiellement affecter des choses qui n’ont rien à voir.

                    Et on en arrive à :

                    J'en reviens toujours au même, on mutualise la complexité dans systemd, pour simplifier la gestion autour, en fait, tous les admin système devraient être super content !! Pourquoi vous râlez au juste ?? Quelqu'un peut m'expliquer ?

                    Qu’actuellement tous les besoins spécifiques soit actuellement implémenté par des outils spécifiques signifie très concrètement que tout besoin spécifique inconnu aujourd’hui (ou considéré comme pas assez important par upstream…) PEUT être implémenté pas d’autres outils spécifiques. Si inetd n’existe pas et que j’en avais le besoin, je pourrais faire inetd moi-même sans avoir à toucher à une seule ligne de init. Ce n’est pas le cas pour systemd : si demain j’ai un besoin qui n’est pas couvert par systemd, je n’ai plus qu’à modifier systemd, avec une probabilité non-nulle d’introduire un bug qui affectera TOUT ce qui est géré par systemd (et ça en fait un joli paquet), pas seulement ce qui est affecté par ce nouveau besoin.

                    Bref, ce qu’on lui reproche (en plus d’amener un joli paquet de code inutile, encore une fois toutes les lignes dans systemd qui font le boulot de inetd, c’est des bugs potentiels pour une valeur ajoutée de 0), c’est une énorme perte de flexibilité.

                    • [^] # Re: Philosophie Unix != Linux ?

                      Posté par . Évalué à  6 .

                      Ce n’est pas le cas pour systemd : si demain j’ai un besoin qui n’est pas couvert par systemd, je n’ai plus qu’à modifier systemd, avec une probabilité non-nulle d’introduire un bug qui affectera TOUT ce qui est géré par systemd (et ça en fait un joli paquet), pas seulement ce qui est affecté par ce nouveau besoin.

                      Heu, WTF ? Systemd est un sur-ensemble strict de sysvinit+rc : si systemd ne fournit pas via sa configuration dans l'unit une fonctionnalité dont tu a besoin, tu peux toujours demander à l'unit de lancer un wrapper en shell autour de ton daemon, dans lequel tu fera tout ce que tu voudras, exactement comme avant.

                    • [^] # Re: Philosophie Unix != Linux ?

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

                      Ce n’est pas le cas pour systemd : si demain j’ai un besoin qui n’est pas couvert par systemd, je n’ai plus qu’à modifier systemd, avec une probabilité non-nulle d’introduire un bug qui affectera TOUT ce qui est géré par systemd (et ça en fait un joli paquet), pas seulement ce qui est affecté par ce nouveau besoin.

                      Si demain j'ai un besoin qui n'est pas couvert par la libc, je n'ai plus qu'a modifier la libc, avec une probabilité non-nulle d'introduire un bug qui affectera TOUT ce qui utilise la libc, pas seulement ce qui est affecté par ce nouveau besoin.

                      Je propose donc qu'on supprime la libc et demande à chaque programme de réimplementer lui meme toutes les fonctions qu'il utilise. D'ailleurs il faudrait une bonne fois pour toute en finir avec ce concept fumeux de librairies et de la réutilisation de code: un bug introduit dans une lib peut affecter TOUT ce qui l'utilise.

                      en plus d’amener un joli paquet de code inutile, encore une fois toutes les lignes dans systemd qui font le boulot de inetd, c’est des bugs potentiels pour une valeur ajoutée de 0

                      Au contraire, systemd permet de supprimer du code inutile, en factorisant le code de gestion des processus. Le meme code est maintenant utilisé quelle que soit la facon de démarrer le service. Ce qui est evidemment une très mauvaise chose, car comme tu l'as expliqué plus haut, un bug dans ce code affectera potentiellement plus de chose. Il est urgent de remplacer les librairies par des copier collés (qu'on modifie legerement à chaque fois pour ne pas avoir les meme bugs partout) et défactoriser un maximum de code pour eviter ce fléau du bug qui affecte tout un tas de choses d'un coup !

                      • [^] # Re: Philosophie Unix != Linux ?

                        Posté par . Évalué à  3 .

                        Si demain j'ai un besoin qui n'est pas couvert par la libc, je n'ai plus qu'a modifier la libc, avec une probabilité non-nulle d'introduire un bug qui affectera TOUT ce qui utilise la libc, pas seulement ce qui est affecté par ce nouveau besoin.

                        Il peut y avoir plusieurs libc sur un système, pas la peine de péter celle qui éxiste déjà. Si tu à un moyen pour permettre qu'il y ai deux systèmes d'init qui fonctionnent en même temps sans coopération sur un seul système, je suis preneur si c'est pas trop moche. Et je suis sérieux.

                        Au contraire, systemd permet de supprimer du code inutile, en factorisant le code de gestion des processus.

                        Contrairement à la libc qui possède la même interface sur tout les systèmes POSIX ou C (selon les fonctions que tu utilise), systemd est spécifique à Linux. Donc tout projet portable devra à la fois avoir du code systemd et du code POSIX (voir non-POSIX), donc une multiplication de code qui font la même chose et une contrainte supplémentaire d'architecture, ce qui est exactement la dé-factorisation que tu préconise.

                        • [^] # Re: Philosophie Unix != Linux ?

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

                          Il peut y avoir plusieurs libc sur un système, pas la peine de péter celle qui éxiste déjà.

                          Tu as deja testé ?

                        • [^] # Re: Philosophie Unix != Linux ?

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

                          Contrairement à la libc qui possède la même interface sur tout les systèmes POSIX ou C (selon les fonctions que tu
                          utilise)

                          Selon ce que tu utilises. Par exemple, bionic est pas compatible avec la glibc. Et les softs ont plus que leur part de "fonctions pas posix" dans leur code.

                          systemd est spécifique à Linux.
                          L’implémentation est spécifique.
                          En pratique, un étudiant en summer of code pour Debian a fait un outil qui converti les unités systemd en script d'init. Donc tu peux trés bien t'en servir pour reprendre les unités poussés upstream, ou reprendre le concept pour faire un script d'init sur autre chose que linux. je suis sur que tu peux même convertir ça en fichier pour launchd ou upstart, au moins pour les trucs les plus rudimentaires.

                          Donc tout projet portable devra à la fois avoir du code systemd et du code POSIX (voir non-POSIX), donc une
                          multiplication de code qui font la même chose et une contrainte supplémentaire d'architecture, ce qui est
                          exactement la dé-factorisation que tu préconise.

                          Alors j'ai regardé ( parce que bon, parait que ça fait pas de mal ) et grosso modo, pour systemd, tu as 2 choses qui pourrait te faire rajouter du code.

                          Soit les logs ( http://0pointer.de/blog/projects/journal-submit.html ), avec les 3 méthodes, dont 2 sont portables et de base ( ie, printf et syslog ), et la 3eme qui est spécifique à systemd ( et qui soit dit en passant est compatible avec syslog dans son cas le plus simple d'utilisation ).

                          Soit tu veut faire de l'activation par socket, chose dont tu peux tout à fait te passer de faire, et qui n'est pas adapté à tout ( donc qui en aucun cas ne va remplacer la méthode classique ), et le code, ça ressemble à ce qu'on trouve la
                          http://0pointer.de/blog/projects/socket-activation.html

                          En gros, inclure 1 header ( sous license BSD ), faire un appel à sd_listen_fds et un if. Violent la compatibilité.
                          Dans la mesure ou la plupart des serveurs vont tout de même avoir envie de se lancer normalement, tu va devoir garder ton code existant. Tu va juste rajouter des fonctionnalités, si ça a un sens.

                          Et pendant ce temps la, des softs multiplateformes comme samba ou apache ont du code pour sendfile en version Linux et version freebsd, car c'est le même nom et pas la même signature
                          http://www.kernel.org/doc/man-pages/online/pages/man2/sendfile.2.html
                          http://www.freebsd.org/cgi/man.cgi?query=sendfile&sektion=2

                          Dbus et cups ont par exemple déjà des ifdef pour des choses comme launchd ( cf HAVE_LAUNCHD dans le code de cups ) et l'activation de socket, ou pour kqueue vs epoll. Donc au final, ça semble ne pas gêner tant de monde que ça de rajouter du code pour une meilleur intégration à la plateforme ( en fait, si ça fait chier lennart ).

                          Donc si tu fait rien, ça marche quand même. Si tu veux tirer parti des fonctions en plus, ouais, faut rajouter du code, comme ce qui est fait depuis des années pour tirer parti des fonctions du kernel sous jacent.

                          Donc oui, il y a factorisation du code dupliqué par chaque distro pour faire les mêmes taches.

                          Il y a factorisation du code des demons pour utiliser les fonctions de namespace ( genre pour avoir un /tmp privé http://0pointer.de/blog/projects/security.html , une fonction qui sauf erreur de ma part est déja linux only à la base ), pour limiter le cpu ( via les cgroups, encore une truc linux only ), ou le filtrage de syscall ( méthode non portable, et je suis pas sur que ça marche pareil sur systrace sur netbsd ). Y a déja plein de trucs qui sont pas fait, et qui ne sont plus à faire, ou qui serait linux only si ils étaient fait.

                      • [^] # Re: Philosophie Unix != Linux ?

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

                        Je propose donc qu'on supprime la libc

                        Pfiou, ça ne nous rajeunit pas : http://pafoo.net/uninstallglibc/uninstglibc.html

                        * Ils vendront Usenet quand on aura fini de le remplir.

            • [^] # Re: Philosophie Unix != Linux ?

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

              "La formation a un cout", c'est une conception faussé. C'est comme dire "l'informatique a un cout". Oui, dans les 2 cas, ça coute. Mais si ça coute tellement, pourquoi ne pas s'en passer ?

              Donc non, on ne peux pas généraliser sur ça coute. Oui, trop de changement trop souvent n'est pas rentable. mais dans le cas de systemd, c'est faire preuve de mauvaise foi car 1) les anciens scripts marchent 2) chkconfig et service marchent. Utiliser les nouvelles fonctions, oui, faut apprendre des nouvelles choses. Mettre les mains dans le système, oui, faut s'attendre a ce que les rouages internes changent. Mais franchement, dans mon boulot de sysadmin, la seule fois ou j'ai du faire un script d'init, c'était quand je contribuait sur mon temps de travail à des distros linux.

              Quand à la simplicité, il ne faut pas se voiler la face. Un système moderne est plus compliqué que le DOS a tout point de vue, et pourtant, presque plus personne ne va rien faire avec le DOS juste parce qu'il aime nom de la simplicité. On a des systèmes compliqués parce que personne ne veux simplifier ses besoins pour garder un système simple. Qui va renoncer au multi tache alors que c'est plus complexe que le mono tache ? Qui va renoncer à un compilateur ou un langage de haut niveau alors que c'est plus complexe que l'assembleur ?

              Et la complexité d'un coté ( par exemple une interface graphique ) est échangé par la simplicité ailleurs ( par exemple, avoir des métaphores plus intuitives dans justement l'interface graphique de la parenthèse d'à coté ).
              Ouais, le format mp3 est plus complexe que le wave, le wave est plus complexe que le raw. Mais la complexité est pas ajouté gratuitement. Le mp3 prends moins de place, propose des meta données, etc. Le raw, non.

              Un /dev statique, ça marche encore. Pourtant, tout le monde semble preferer la complexité d'udev. Est ce que tout les codeurs du libre n'ont pas suivi le cours de première année d'ingénierie dont tu parles et aurais du lutter contre ça ? Ou est ce qu'ils ont juste fait le constat que les gens demandent de plus en plus, et que le /dev statique, ça marche pas dans les nouveaux cas ?

              Enfin tu parles de cout de migration à systemd. Moi, j'ai eu aucun cout sur mon portable, parce que je fait pas ma propre distro, c'est le concept de base de la mutualisation. Oui, j'ai trouvé des bugs, genre 2/3. Mais comme j'ai rapporté les bugs, bah ils sont corrigés pour tous.

              Maintenant, si ta distrib ne supporte pas ça pour toute les raisons du monde, ouais, tu va te taper la QA chez toi. Est ce que c'est une raison de pas le prendre ? Sans doute, mais pas parce que le logiciel a un souci. Juste parce qu'il est pas intégré. Et justement, au nom de la simplicité, si ta distro propose par défaut un truc, je pense que vouloir s'accrocher à l'ancien système, c'est se compliquer la vie.

              Tout comme le meilleur serveur web du monde, si tu dois faire le paquet et compiler, et te taper les mise sà jours de secu, je pense que ça vaut pas le coup. Et ça, indépendamment du logiciel.

              • [^] # Re: Philosophie Unix != Linux ?

                Posté par . Évalué à  5 .

                Tu m’as lu ?

                C’est exactement ce que je dis : le changement a un coût, pour savoir s’il est pertinent il faut mesurer ce qu’il apporte. Dans la majorité des cas systemd n’apporte rien, le coût est non nul, le choix est vite fait. Enfin, ça, c’était si on nous laissait le choix…

                Moi, j'ai eu aucun cout sur mon portable, parce que je fait pas ma propre distro

                Tu peux difficilement comparer la situation de ton portable perso avec un serveur en entreprise…

                Et justement, au nom de la simplicité, si ta distro propose par défaut un truc, je pense que vouloir s'accrocher à l'ancien système, c'est se compliquer la vie.

                Qui a dit que j’allais m’y accrocher ? Je migrerai quand ma distrib y passera, mais ce sera un coût imposé pour aucun gain derrière.

                • [^] # Re: Philosophie Unix != Linux ?

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

                  Tu peux difficilement comparer la situation de ton portable perso avec un serveur en entreprise…

                  Ben figure toi que si. Dans le cas du serveur, si jamais la distro passe à systemd, je n'aurais pas plus de cout que dans le cas de mon portable. Y a surement des tas de serveurs moins critiques que le portable d'un PDG.

                  Dans les 2 cas ( mon portable perso ( enfin mon portable de boulot ) et les serveurs d'entreprises ), je gère ça avec puppet, dans les 2 cas, j'ai besoin que ça marche. Dans les 2 cas, le fait de dévier de la norme apporte un cout. Que les gens passent pas d'eux même est logique, et je pense que personne ne demande de le faire.
                  Faire une distribution, c'est tout un boulot, et la plupart des gens savent pas par ou commencer, donc je comprends qu'ils se fatiguent pas à vouloir toucher à ça, indépendamment du changement à faire.

                  Qui a dit que j’allais m’y accrocher ? Je migrerai quand ma distrib y passera, mais ce sera un coût imposé pour aucun
                  gain derrière.

                  Cout imposé à qui ? À toi ? Il faut prendre en compte le fait que mutualiser va peut être réduire les coûts justement pour les distros. Par exemple, aller piquer le .service upstream ou ailleurs au lieu de repartir de 0.
                  Et garder l'ancien système la ou il te va, et apporter le nouveau la ou le nouveau apporte des choses, ça a un cout plus grand que juste garder un système.

                  A la fin, c'est pas le cout pour l'utilisateur qui importe tant que celui pour la distro. Si la distro n'a pas les ressources, elle va pas le faire, même si ça coute un peu à tout les utilisateurs.

            • [^] # Re: Philosophie Unix != Linux ?

              Posté par . Évalué à  0 .

              Tu n’es évidemment pas développeur pour raconter des âneries pareil, la complexité ne se mesure évidemment pas en nombre de lignes de code. La simplicité se réfère à trois axes :

              Ben voyons!
              Et comme toi t'es un developeur de ouf malade, tu vas me sortir ton cv, qui est j'en suis sur, rempli de plusieurs annees d'experience d'architecture systeme. Si c'est pas le cas, je te suggere de ne pas utiliser d'argment d'autorite, Lennart en fait plus pour l'informatique a la pause cafe que toi dans l'annee, donc abstients toi stp.
              Juste parce que tu deployes qq serveurs ne fait pas de toi un expert en la matiere. De la meme maniere qu'avoir 100 000km par an sur un 15 tonnes ne fait pas de toi un ingenieur en mecanique capable de concevoir un moteur de camtard.

              Les concepts de 70's eriges en dogme, ca va 5 minutes, mais c'est a peu pres aussi utile que les proverbes de ma grand mere.
              Declarer que l'init ne doit rien faire et juste lancer un script shell, c'est pas faire plus simple. Ca revient juste a declarer forfait face un probleme complexe et pousser la complexite en dehors de son domaine, mais ca ne rends rien plus simple, juste simpliste. C'est la version informatique du "chat bite, perche, pas le droit de toucher son pere". Ta complexite est toujours la, et en plus elle a augmente et se retrouve demultipliee parce que tu te retrouves a la gerer au mauvais endroit.
              Je suis pas ingenieur systeme, mais ce que je sais pour le voir au quotidien, c'est que les Ops ont autre chose a faire que d'ecrire des scripts shells a la con.
              Et ceux que je connais sont plutot d'accord avec moi, ce qu'ils veulent eux c'est automatiser leurs environnements de productions, faire de l'autoscaling et ce genre de conneries. Pas s'emmerder avec du shell a refaire un truc qui devrait etre gere par l'os de base, et pas non plus faire des copier/coller partout des memes scripts de demarrages.

              Ca te plait peut etre pas, mais tous ces process interagissent les uns avec les autres, et gerer tout ca avec du shell chacun de son cote et a sa propre sauce me parait pas une solution particulierement robuste.
              Ca marchait en 77, mais l'utilisation des ordinateurs a quelque peu evolue en complexite.

              Engineering 101 : plus un système est complexe, plus il a de possibilités de merder.

              Engineering 102: un systeme est au moins aussi complexe que le probleme qu'il resoud.
              Dit autrement, la complexite d'une solution est directement proportionelle au probleme qu'elle resoud, et ca c'est le meilleur cas,
              En 1999, le probleme de la recherche sur le web etait simple: 2 gus et qq machines sous un bureau.
              En 2012, les memes gus sont a la tete d'une armee d'ingenieurs, leur propres data center avec hardware custom et en arrivent a pousser un TCP modifie parce qu'ils atteignent les limites physiques de la latence reseau mondiale et que un roundtrip en plus pour le ACK leur coute qq millions en chiffre d'affaire.

              Si vous vouliez des problemes simples a resoudre, fallait naitre en 1950 et devenir ingenieur systeme en 1970.
              Tous les domaines technologiques suivent la meme evolution.

              Compares une tele de 1970 et une de 2012, tu vas voir un gouffre niveau complexite. La raison? Les fonctionnalites. En 1970, t'etais content d'avoir des couleurs pourries. En 2012, tu commandes ta playstation avec la telecommande, tu rales que le hd, c'est pas assez, la tele gere la luminosite elle meme et s'eteint toute seule quand tu t'endors devant.

              Refuser de resoudre un probleme au pretexte que c'est trop complique, c'est au mieux de la faineantise au pire de l'incompetence. Je suis paye pour la comprendre et l'automatiser cette complexite. Si j'explique a mon PM que telle feature on va pas la faire parce que l'appli doit rester simple, il va me regarder avec des gros yeux et ensuite me faire virer. Et il aura raison, je ferais pareil si un de mes gars me sort la meme excuse foireuse.

              Ce que KISS dit, c'est de garder la complexite de la solution au meme niveau que celle du probleme. Pas qu'il ne faut rien faire parce que, pfouuuuyaya, faut resoudre un probleme! Et ca c'est dur!
              Commencer par identifier clairement le probleme a resoudre. Ensuite, identifier comment ce probleme va evoluer et prevoir en consequence.
              Et oui, engineering 103: l'ingenierie ne consiste pas a resoudre des problemes, mais les remplacer par d'autres, plus simples. Problemes qu'il va par la suite remplacer par d'autres. Si t'as suivi Recursivite 101, tu dois etre en mesure de me dire quand le travail de l'ingenieur finit.

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

              • [^] # Re: Philosophie Unix != Linux ?

                Posté par . Évalué à  7 .

                Et comme toi t'es un developeur de ouf malade, tu vas me sortir ton cv, qui est j'en suis sur, rempli de plusieurs annees d'experience d'architecture systeme. Si c'est pas le cas, je te suggere de ne pas utiliser d'argment d'autorite, Lennart en fait plus pour l'informatique a la pause cafe que toi dans l'annee, donc abstients toi stp.

                Le joli homme de paille. Je prétend pas être meilleur que Lennart, loin de là, mais que je sache c’est pas Lennart qui a prétendu que la complexité se mesurait en nombre de lignes de code…

                Les concepts de 70's eriges en dogme, ca va 5 minutes, mais c'est a peu pres aussi utile que les proverbes de ma grand mere.

                Le progrès érigé en dogme, ça va 5 minutes, mais c’est à peu près aussi utile que les proverbes de ma grand mère.

                C’est super facile en fait. Mais on avance pas beaucoup…

                Declarer que l'init ne doit rien faire et juste lancer un script shell, c'est pas faire plus simple. Ca revient juste a declarer forfait face un probleme complexe et pousser la complexite en dehors de son domaine, mais ca ne rends rien plus simple, juste simpliste. C'est la version informatique du "chat bite, perche, pas le droit de toucher son pere". Ta complexite est toujours la, et en plus elle a augmente et se retrouve demultipliee parce que tu te retrouves a la gerer au mauvais endroit.

                Quelle complexité ?

                Parce que le problème il est là : tu as plein de problèmes complexes avec l’init, mais TOUT le monde n’a pas TOUS les problèmes. Untel veut pouvoir isoler le processus du réseau (jamais rencontré cette problématique perso, mais si c’est implémenté c’est que ça doit intéresser quelqu’un je suppose…), untel veut pouvoir lancer 5 processus apache, tel autre veut les fonctionnalités de inetd, etc. Le problème c’est que personne veut résoudre tout ça en même temps sur la même machine. D’où on en arrive à :

                Ce que KISS dit, c'est de garder la complexite de la solution au meme niveau que celle du probleme

                Je suis d’accord avec ça, mais c’est exactement ce que je dis : systemd est plus complexe que le problème qu’on cherche à résoudre sur la plupart des serveurs, tout bêtement parce que ça va finir comme les suites bureautique : chaque utilisateur va utiliser (c’est pour imager hein, je prétend pas à l’exactitude) 10% des fonctionnalités de systemd, mais chacun 10% différentes.

                Refuser de resoudre un probleme au pretexte que c'est trop complique, c'est au mieux de la faineantise au pire de l'incompetence

                Et ajouter de la complexité sans qu’elle serve à résoudre le moindre problème, ben pareil.

                • [^] # Re: Philosophie Unix != Linux ?

                  Posté par . Évalué à  3 . Dernière modification : le 26/10/12 à 15:18

                  En fait, on est d'accord sur pas mal de choses, mais les 2 gros points que je vois où nos avis divergent c'est :

                  1) systemd résous des problèmes qui ne sont pas assez important et ne gênent pas assez de monde pour toi.
                  Pour moi ces problèmes sont là et si des personnes n'ont pas l'impression que ça les gêne, c'est qu'ils s'en sont accomodé (un peu comme les bugs et limitations inhérents à un environnement)

                  2) systemd est est trop complexe pour ce qu'il résous pour toi.
                  Pour moi le système d'init est déjà au moins aussi complexe, et même si systemd est est plus complexe que le process init, il est bien moins complexe que l'ensemble des mécanismes, processus et autres mis en oeuvre dans le démarrage du système actuellement.

                  Et petite cerise sur le gâteau, systemd apporte des fonctionnalités en plus, pour un coût très modique (voir nul) en terme de complexité qu'il aurait été très très compliqué d'ajouter dans init et qui peuvent servir de temps en temps, des fois, tout le temps !

                  • [^] # Re: Philosophie Unix != Linux ?

                    Posté par . Évalué à  2 .

                    Pour moi ces problèmes sont là et si des personnes n'ont pas l'impression que ça les gêne, c'est qu'ils s'en sont accomodé (un peu comme les bugs et limitations inhérents à un environnement)

                    Où plutôt que ces problèmes n’arrivent pas à tout le monde, tout bêtement, sur un serveur web j’ai pas besoin de passer par inetd pour lancer apache, parce que sur un serveur web j’aurais toujours besoin d’apache.

                    Pour moi le système d'init est déjà au moins aussi complexe, et même si systemd est est plus complexe que le process init, il est bien moins complexe que l'ensemble des mécanismes, processus et autres mis en oeuvre dans le démarrage du système actuellement.

                    Si par « l’ensemble des mécanismes » tu inclus tous les trucs optionnels possibles pour répondre à toutes les problématiques imaginables, je veux bien te croire. Maintenant justement dans le système de démarrage actuel tu n’as pas tout, encore une fois ya bien des petits serveurs sans atd ou inted (pour ne citer des exemples concrets)

                  • [^] # Re: Philosophie Unix != Linux ?

                    Posté par . Évalué à  -2 .

                    c'est qu'ils s'en sont accomodé (un peu comme les bugs et limitations inhérents à un environnement)

                    le principal progrès qu'indique les pro-systemd c'est la vitesse de boot.

                    Et sur mes machines perso, et sur mes machines au taff (enfin sauf celles qui sont sous ubuntu au taff ) , le bios et la détection des != cartes mes plus de temps que le boot système…

                    Donc gagner 20 secondes sur un boot de 2m30 (voir 15 min quand c'est des cartes pour les SAN) oui je m'en accomode , et pas qu'un peu.

                    • [^] # Re: Philosophie Unix != Linux ?

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

                      le principal progrès qu'indique les pro-systemd c'est la vitesse de boot.

                      Tu as dû loupé énormément de troll et d'être arrêter à ceux du début pour dire ça.

                      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                      • [^] # Re: Philosophie Unix != Linux ?

                        Posté par . Évalué à  -1 .

                        possible que je me soit mal exprimé.

                        Le but initial (ie le problème à résoudre) de systemd était améliorer la vitesse de boot.

                        Et ensuite ils ont décidé de rajouter plein de chose parce que "tu comprends c'est le progrès", mais ce n'était pas le but initial de systemd (ie de remplacer tout l'os).

                        • [^] # Re: Philosophie Unix != Linux ?

                          Posté par . Évalué à  -4 .

                          Donc en fait, le principal avantage de systemd, c'st la vitesse de boot, mais en fait, c'est pas la vitesse de boot l'avantage principal, c'est ca?
                          Limpide!

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

                        • [^] # Re: Philosophie Unix != Linux ?

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

                          Le but initial (ie le problème à résoudre) de systemd était améliorer la vitesse de boot.

                          J'ai un gros doute là dessus. Il y a depuis le début une simplification du démarrage avec les fichiers de configuration (les units de systemd), la volonté de ne pas créer des process qui ne servent qu'à lancer d'autres process. Je ne connais pas la feuille de route du départ mais c'était bien plus qu'améliorer la vitesse de boot.

                          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                        • [^] # Re: Philosophie Unix != Linux ?

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

                          mouais, c'est pas super évident à première lecture :
                          http://0pointer.de/blog/projects/systemd.html

                          • [^] # Re: Philosophie Unix != Linux ?

                            Posté par . Évalué à  2 .

                            merci pour le lien :
                            je constate qu'effectivement il veut modifier le pid 1
                            et dis en substance :

                            As mentioned, the central responsibility of an init system is to bring up userspace. And a good init system does that fast. Unfortunately, the traditional SysV init system was not particularly fast.

                            For a fast and efficient boot-up two things are crucial:

                            To start less.
                            And to start more in parallel.

                            Alors on peut me dire que c'est "juste une citation" , mais au vu du liens, cette "volontée" semblait quand même la volontée centrale.

                            Il dis aussi ensuite que c'est à l'init de gérer le hotplug (lancer un service ou des actions lors d'un plug/unplug d'un périphérique).
                            Chacun décide si cette vision de l'init lui convient..

                            Le reste de l'article listant les moyens d'y arriver (paralléliser plus, socket activation, & tutti quanti).

                            Bref ce liens semble plutôt confirmer mes dires.

                • [^] # Re: Philosophie Unix != Linux ?

                  Posté par . Évalué à  -3 .

                  Le joli homme de paille. Je prétend pas être meilleur que Lennart, loin de là, mais que je sache c’est pas Lennart qui a prétendu que la complexité se mesurait en nombre de lignes de code…

                  Je te retourne le compliment. Je n'ai pas pretendu que la complexite se mesurait uniquement en lignes de code.
                  Par contre ce qui est sur c'est que les seuls bugs que tu n'auras pas sont dans du code qui n'a pas ete ecrit, d'une part, d'autre part les ops ne sont pas franchement repute pour leur capacité a ecrire du code robuste.
                  Le shell est un langage bien pourri, de mon point de vue 100 lignes de shell c'est bien trop.

                  Quelle complexité ?

                  Demarrage efficace et simplifie. A savoir ne pas avoir a ecrire une palanquee de code pour gerer la dependance de ses services. Ce genre de choses est bien mieux exprimee en dependance qu'en numero de séquences, et systemd est tres bien place pour mutualiser 99% des scripts d'init actuels. Comme il demarre ses services lui meme, il est aussi tres bien place pour faire office de watchdog.
                  Interactions entre process. Quand qq1 change le nom d'hôte, le processus a cote qui tourne et qui se presente comme un service Bonjour va probablement vouloir etre mit au courant et changer le nom qu'il annonce sur le reseau (exemple concret que je rencontre avec un de mes projets perso), pour reprendre hostname cite qq part dans un troll.
                  Gerer les permissions de facon bien plus fine - je veux pouvoir changer mes parametres reseaux sans mot de passe sur mon laptop au taff, mais il est hors de question de laisser quiconque faire ca sur par les serveurs divers et varies.
                  L'exemple du fast user switching ou tu veux couper le son des applis en cours, et faire en sorte que la cle usb qui a ete montee en tant que "user1 700" soit maintenant "user 2 700".

                  C'est (entre autres) ce genre de chose que systemd resoud. Et il le fait parce qu'il est le mieux place pour le faire. Tout ce que j'ai entendu jusqu'a present contre ca, c'est "systemd n'a pas a faire ça, parce qu'init ne le fait pas, alors ya pas de raison", je veux bien une autre solution, mais va falloir prouver en quoi ca marche mieux.

                  Parce que le problème il est là : tu as plein de problèmes complexes avec l’init, mais TOUT le monde n’a pas TOUS les problèmes.

                  C'est pas pour autant qu'il ne faut pas les resoudre. C'est meme assez typique ce genre de problematique. Le kernel adresse un paquet de problemes et pourtant chaque utilisateur n'en utilise qu'une partie. Va tu sortir les memes arguments la dessus?
                  On fait quoi alors, on casse une myriade de problemes interconnectes en plusieurs solutions qui vont forcement ne rien savoir les unes des autres et donc ne pas vraiment pouvoir resoudre le probleme?
                  C'est un peu le point central de systemd: il faut un chef d'orchestre pour organiser tout ce joyeux bordel, sinon tu t'en sort pas.

                  Je suis d’accord avec ça, mais c’est exactement ce que je dis : systemd est plus complexe que le problème qu’on cherche à résoudre sur la plupart des serveurs, tout bêtement parce que ça va finir comme les suites bureautique : chaque utilisateur va utiliser (c’est pour imager hein, je prétend pas à l’exactitude) 10% des fonctionnalités de systemd, mais chacun 10% différentes.

                  Et? Separer l'init serveur et desktop n'ajouterais pas de la complexite? On se retrouve avec 2 stacks differentes a maintenir? Tout ca pour quoi? Pour eviter d'avoir du code qui de toutes facons ne tournera jamais sur la machine?
                  Apple utilise launchd sur toute sa gamme, des (feu) serveurs aux telephones, et c'est honnetement dur de les accuser d'etre des apotres de la complexité, ca te met pas la puce a l'oreille?

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

            • [^] # Re: Philosophie Unix != Linux ?

              Posté par . Évalué à  -1 .

              Merci ; j';aurais pas dit mieux !

      • [^] # Re: Philosophie Unix != Linux ?

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

        Linus (qui me semble est un bon représentant de la notion de KISS)
        [ … ]
        si on était TOUS des intégristes du KISS, je vois pas pourquoi on utilise Linux.

        Il y a tout de même un petit problème dans ton paragraphe, non ?

        • [^] # Re: Philosophie Unix != Linux ?

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

          conseil communication : évite d'avoir un intégriste comme représentant ;)

          ce commentaire est sous licence cc by 4

        • [^] # Re: Philosophie Unix != Linux ?

          Posté par . Évalué à  2 .

          pas tout à fait, mais on pourrait le penser.

          Cela montre moins point de vue que c'est bien une philosophie et donc que chacun la voie à sa façon.
          La vision de Linus sur le KISS est assez poussée mais je relève qu'il arrive a être pragmatique et que dès fois, ce n'est pas la meilleur solution.

          Et ma dernière remarque sur Hurd vient enfoncer le clou sur le fait que si on suivait à la lettre le KISS, Linux serait un micro-noyau. Mais la philosophie du KISS de Linus ne va pas aussi loin et il reste convaincu que c'est de l'enculage de mouches!

    • [^] # Re: Philosophie Unix != Linux ?

      Posté par (page perso) . Évalué à  4 . Dernière modification : le 24/10/12 à 13:15

      Dont "Un outils pour une fonction" qui en dérivait impliquait que cet outil
      fasse peut de chose mais le fasse bien.

      Je sais que je me répète mais ça me gonfle de voir passer cette incompréhension d'Unix. Ceci ne concerne que la ligne de commande et les utilitaires qui lui sont associée, ce afin d'utiliser principalement deux programmes et un "|" plutot que de tout faire dans le même exécutable.

      Pour un système d'init, cela n'a aucun sens…

      Parce que pour le coup:
      - Vu le nombre de commandes internes, ksh ne serait donc pas du tout adapté à la philosophie Unix ?
      - Vu l'architecture des premiers noyaux Unix, alors ces derniers ne seraient pas adaptés à la philosophie Unix ?
      - etc

      En conclusion, sortie des commandes externes du shell générant/lisant des données, le principe une commande == une fonctionnalité n'a aucun sens.

      • [^] # Re: Philosophie Unix != Linux ?

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

        Vu le nombre de commandes internes, ksh ne serait donc pas du tout adapté à la philosophie Unix ?

        Exactement. Je t'invite à lire (écrit par des gens qui ne connaissent rien à unix) :

        http://harmful.cat-v.org/cat-v/
        http://harmful.cat-v.org/cat-v/unix_prog_design.pdf

        At the USENIX Summer Conference of 1983 Rob Pike made a presentation titled ‘UNIX Style, or cat -v Considered Harmful’ and together with Brian Kernighan wrote the paper ‘Program Design in the UNIX Environment’ (pdf version, ps version).
        
        This was a prelude for their famous book The Unix Programming Environment (Prentice-Hall Software Series) that today is considered the bible of Unix.
        
        Unfortunately their advice has been completely ignored, and today Unix has become overcome by exactly the kind of mistakes they warned against.
        
        Bell Laboratories
        
        Murray Hill, NJ (dec!ucb)wav!research!rob
        
        It seems that UNIX has become the victim of cancerous growth at the hands of
        organizations such as UCB. 4.2BSD is an order of magnitude larger than Version
        5, but, Pike claims, not ten times better.
        
        The talk reviews reasons for UNIX's popularity and shows, using UCB cat as a
        primary example, how UNIX has grown fat. cat isn't for printing files with line
        numbers, it isn't for compressing multiple blank lines, it's not for looking at
        non-printing ASCII characters, it's for concatenating files.
        
        We are reminded that ls isn't the place for code to break a single column into
        multiple ones, and that mailnews shouldn't have its own more processing or joke
        encryption code.
        
        Rob carried the standard well for the "spirit of UNIX," and you can look
        forward to a deeper look at the philosophy of UNIX in his forthcoming book.
        
        

        Vu l'architecture des premiers noyaux Unix, alors ces derniers ne seraient pas adaptés à la philosophie Unix ?

        Je t'invite de nouveau à lire les mêmes articles.

        Pour un système d'init, cela n'a aucun sens…

        Ben si. Un système d'init, cela doit faire l'init.

        • [^] # Re: Philosophie Unix != Linux ?

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

          Exactement. Je t'invite à lire (écrit par des gens qui ne connaissent rien à
          unix) :

          Et moi je t'invite à regarder comment fonctionne un shell parce que je te parle de commandes internes et tu me réponds commandes externes (cat, ls, …)

          Mais bon, bizarrement, tu vas encore plus dans mon sens, si même les commandes externes de base ne sont pas "unix spirit", alors je vois pas pourquoi le reste le serait :p

          • [^] # Re: Philosophie Unix != Linux ?

            Posté par . Évalué à  1 .

            Historiquement, en tous cas, sur certain serveur SUN, dans ksh, la commande cd est une commande externe. Bash la mise en buitin pour optimiser.
            Mais, oui, en tant que langage de programmation certaines chose sont indispensable : while, for, if. Ensuite, il y a certaine commande qui sont devenues internes pour optimiser.

            • [^] # Re: Philosophie Unix != Linux ?

              Posté par . Évalué à  3 .

              J'ai du mal à comprendre comment fonctionnerait une telle commande (je ne suis pas développeur cela dit).

              En gros je vois un truc genre :

              shell
               |- cd
                    |- cd(<foo>)
                    |- exit(0)
               shell
              
              

              Et ça, ça ne marche pas. Par contre, si la commande relance un shell :

              shell
              |- cd
                    |- cd(<foo>)
                    |- exec(<shell>)
                         |- shell
                    |- exit(0)
              
              
              • [^] # Re: Philosophie Unix != Linux ?

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

                cd ne fait que changer la variable d'environnement CWD, avec quelques contrôles au passage.

                • [^] # Re: Philosophie Unix != Linux ?

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

                  Ce qui est un peu compliqué à faire dans un processus séparé.

                • [^] # Re: Philosophie Unix != Linux ?

                  Posté par . Évalué à  4 .

                  Comme le dit b<, comment peut-on modifier l’environnement d’un processus parent dans un processus enfant ?

                • [^] # Re: Philosophie Unix != Linux ?

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

                  Tiens, ça marche pas chez moi :

                  /tmp $ pwd
                  /tmp
                  /tmp $ CWD=/home
                  /tmp $ pwd      
                  /tmp
                  
                  
                  • [^] # Re: Philosophie Unix != Linux ?

                    Posté par . Évalué à  0 . Dernière modification : le 26/10/12 à 10:08

                    Oui, ça ne marche pas sous GNU/Linux. Et ça prouve ? que GNU/Linux abandonne les vieilleries et la rétro compatibilité.

                    • [^] # Re: Philosophie Unix != Linux ?

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

                      Je pense que c'est pas une question de noyau, mais de shell. L'information du répertoire courant est au niveau du noyau ( vu que ça apparait dans /proc ). Ce qui implique donc de reporter l'information la bas, donc que le shell fasse un traitement spécifique, ou que le noyau découvre le changement en observant les changements dans les variables d'environnement.

                      Autant avoir une syntaxe spécifique pour le shell, pourquoi pas, autant j'ai des doutes sur le bien fondé de vérifier tout changement de environnement au niveau du noyau ( pour des questions de performances de la chose ).

                      Ceci dit, j'aimerais quand même bien voir ou est ce que ça a marché un jour. Je doute que ça soit dans un standard posix, et je doute que ça soit au niveau du kernel. Donc une reference un chouia plus précise serait la bienvenue.

                    • [^] # Re: Philosophie Unix != Linux ?

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

                      Oui, ça ne marche pas sous GNU/Linux.

                      Ça ne marche pas sous FreeBSD non plus, ni sous OpenSolaris. CWD n'est pas une variable d'environnement. C'est un élément de la table des descripteurs de fichiers. Au même titre que le root directory.

                      struct filedesc {
                              struct  file **fd_ofiles;       /* file structures for open files */
                              char    *fd_ofileflags;         /* per-process open file flags */
                              struct  vnode *fd_cdir;         /* current directory */
                              struct  vnode *fd_rdir;         /* root directory */
                              struct  vnode *fd_jdir;         /* jail root directory */
                              int     fd_nfiles;              /* number of open files allocated */
                              NDSLOTTYPE *fd_map;             /* bitmap of free fds */
                              int     fd_lastfile;            /* high-water mark of fd_ofiles */
                              int     fd_freefile;            /* approx. next free file */
                              u_short fd_cmask;               /* mask for file creation */
                              u_short fd_refcnt;              /* thread reference count */
                              u_short fd_holdcnt;             /* hold count on structure + mutex */
                              struct  sx fd_sx;               /* protects members of this struct */
                              struct  kqlist fd_kqlist;       /* list of kqueues on this filedesc */
                              int     fd_holdleaderscount;    /* block fdfree() for shared close() */
                              int     fd_holdleaderswakeup;   /* fdfree() needs wakeup */
                      };
                      
                      

                      La référence la plus ancienne que j'ai trouvé date de 3BSD dans laquelle cet élément était dans la structure user. chdir était alors déjà un appel système.

                  • [^] # Re: Philosophie Unix != Linux ?

                    Posté par . Évalué à  1 .

                    Avec $PWD cela marche.

                    [matthieu:/home] $ PWD=/tmp
                    [matthieu:/tmp] $

                    Marrant.

                • [^] # Re: Philosophie Unix != Linux ?

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

                  cd ne fait que changer la variable d'environnement CWD, avec quelques contrôles au passage.

                  heu oui enfin chdir est un appel système un peu plus compliqué que ça.

              • [^] # Re: Philosophie Unix != Linux ?

                Posté par . Évalué à  6 . Dernière modification : le 25/10/12 à 00:37

                Tu as raison. Il y a une légende comme quoi à un moment cd aurait été un executable et que l'astuce était que le shell au lieu de forker faisait uniquement un exec et sautait le fork pour ce binaire particulier. On retrouve quelques références à l'histoire, mais ce n'est jamais sourcé et toujours vague. J'ai remonté un peu les archives de Sun Os (1..4) et des (3|4)BSD et ça n'a jamais été comme cela. Pas réussi à mettre la main un sysVr4.

                On peut considérer ça comme une légende pour deux raisons. Premièrement ça serait très con. Deuxièmement ça ressemble à une grossière mauvaise interprétation de The Evolution of the Unix Time-sharing System de Ritchie. Il y décrit notamment l'introduction du multiprocessus et du fork/exec dans le PDP-7 et comment chdir à du devenir un builtin à cause de ça. Donc le coup du binaire est vrai… mais clairement pas dans UNIX. Et si tu refais la chronologie de leur patch de chdir c'est totalement improbable. PDP-11 c'est 1970, Sun OS 1 c'est 1983. Bon c'est pas dit que leur premier patch n'ait pas été de sauter le fork non plus ;)

                Historiquement, en tous cas, sur certain serveur SUN, dans ksh, la commande cd est une commande externe.

                Je suis donc très intéressé par la ref exacte du système et idéalement une preuve ou une VM du système.

          • [^] # Re: Philosophie Unix != Linux ?

            Posté par . Évalué à  8 .

            Puisque quelques pages semblent si dures à avaler, laissons simplement s'exprimer la conclusion de ces braves gens qui ne connaissent probablement rien à Unix :

            The key to problem-solving on the UNIX system is to identify the right primitive operations and to put them at the right place. UNIX programs tend to solve general problems rather than special cases. In a very loose sense, the programs are orthogonal, spanning the space of jobs to be done (although with a fair amount of overlap for reasons of history, convenience or efficiency). Functions are placed where they will do the most good: there shouldn’t be a pager in every program that produces output any more than there should be filename pattern matching in every program that uses filenames.

            One thing that UNIX does not need is more features. It is successful in part because it has a small number of good ideas that work well together. Merely adding features does not make it easier for users to do things — it just makes the manual thicker. The right solution in the right place is always more effective than haphazard hacking.

        • [^] # Re: Philosophie Unix != Linux ?

          Posté par . Évalué à  -5 .

          Sortir une citation datant de 1983, c'est pas mal quand meme.

          We are reminded that ls isn't the place for code to break a single column into
          multiple ones, and that mailnews shouldn't have its own more processing or joke
          encryption code.

          Et on est cense faire comment?
          Piper du texte de ls vers string_formatter?
          En gros son argument c'est qu'aucune de ces commandes ne doit avoir aucune logique de presentation, on est cense faire comment pour presenter les donnees a l'utilisateur (qu'il soit de chair ou de silicium)?
          On pipe le texte vers la commande string_formatter?

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

    • [^] # Re: Philosophie Unix != Linux ?

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

      Ensuite j'ai découvert la philosophie KISS
      "Keep It Simple Stupid"
      Donc laisser les choses les plus simple possible pour ne pas à avoir se faire des nœuds au cerveau > pour comprendre comment cela fonctionne.

      Je suis pas persuadée qu'entre avoir plein de petits trucs censés être simples, et en avoir un gros un peu plus compliqué, ce soit forcément le plus cas qui soit globalement le plus «simple» quand on regarde l'ensemble.

      En ce qui concerne systemD, j'admets être une quiche en système d'init et ne jamais avoir regardé ça de près, mais les quelques fois ou j'ai jeté un coup d'oeil dans mes repertoires /etc/rc*, le terme «simple» n'est pas le premier qui me soit venu à l'esprit. À l'inverse, l'exemple de fichier de configuration pour systemd posté plus haut me parait plus simple.

      Bref, autant je trouve l'approche KISS relativement pertinente pour éviter les usines à gaz, autant je trouve que le terme «simple» n'est pas si simple à définir : simple à maintenir ? à utiliser ? simplicité de l'ensemble ou juste simplicité des modules pris séparément ? Etc.

      • [^] # Re: Philosophie Unix != Linux ?

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

        […] je trouve que le terme «simple» n'est pas si simple à définir : simple à maintenir ? à utiliser ? simplicité de l'ensemble ou juste simplicité des modules pris séparément ?

        À mon sens, ce qui définit le canon de la simplicité dans ce cas est la phrase de Boileau:

        Ce que l'on conçoit bien s'énonce clairement,
        Et les mots pour le dire arrivent aisément.
        
        

        Cela décrit une relation importante entre «simple» et «comprendre» (d'usage plus contemporain que «concevoir» :) )

        Ainsi si une situation nous paraît complexe ou embrouillée, c'est souvent, ou toujours, un signe que nous n'avons pas trouvé les mots et les concepts adaptés à la description de cette situation.

  • # Sur le blog de Lennart

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

    "Systemd for administrators, part XVIII"

    ixe-vé-hi-hi-hi ça fait 18. Son nouveau projet super simple super mieux que tout le reste a besoin de 18 articles pour être expliqué ? (Et encore ce n'est pas fini)

    • [^] # Re: Sur le blog de Lennart

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

      C'est n'importe quoi ta façon de compter !

      Tout le monde sait que XVIII, c'est croix-vé-baton-baton-baton.

    • [^] # Re: Sur le blog de Lennart

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

      Tu veux dire que s'il n'écrit pas de doc et se limite à dire "read the source, lurk", ça signifierai que son projet est excellent et simplissime ?

      ce commentaire est sous licence cc by 4

    • [^] # Re: Sur le blog de Lennart

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

      Faut plus de 18 articles pour expliquer la syntaxe du shell et l'ensemble des commandes de bases + leurs options disponibles ;)

      • [^] # Re: Sur le blog de Lennart

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

        Sauf que la syntaxe du shell, elle te sert ailleurs. (Et il ne faut pas 18 articles pour expliquer le fonctionnement de sysvinit… en tout cas pas pour les distributions qui ont un init BSD-style. Les autres aiment se compliquer la vie de toute façon.)

        • [^] # Re: Sur le blog de Lennart

          Posté par . Évalué à  1 .

          Ça veut peut-être dire qu'il est très complet…
          Par contre pour faire des choses basiques il a l'air assez simple et donc il n'est pas nécessaire de lire toute la doc.
          Regarde l'exemple de Sylvain.
          Je trouve ça nettement plus simple que les scripts actuels.

          • [^] # Re: Sur le blog de Lennart

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

            Même avec toute la mauvaise foi du monde, en regardant l'exemple dont tu parles, je suis obligé de reconnaître que c'est plus simple. Sur ce point là, systemd a un avantage très net.

            • [^] # Re: Sur le blog de Lennart

              Posté par . Évalué à  2 .

              Encore que, il faut savoir quoi coller dans les fichiers :) et donc apprendre/lire une énième doc là où, finalement, le rc.fourretout est universel :)

        • [^] # Re: Sur le blog de Lennart

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

          En même temps, y a pas besoin de 18 pages parce qu'il n'a juste aucune fonctionnalité, et qu'il faut bricoler le reste.

          Elle est ou la doc sur "comment j'isole un demon du réseau ( http://0pointer.de/blog/projects/security.html ) ? Ah oui, faut se taper la doc sur comment écrire le script d'init, et aller modifier le script. Ou se faire son propre jail.
          ( et c'est surement plus compliqué que http://0pointer.de/blog/projects/changing-roots ).

          Ou comment je lance 3 fois openvpn ( http://0pointer.de/blog/projects/instances.html ), pareil, faut aller patcher le script, ou refaire son script.

          Ou comment je mesure la vitesse de boot ( http://0pointer.de/blog/projects/blame-game.html ), faut aller installer et modifier le boot loader ( cf fonctionnement de bootchart )

          • [^] # Re: Sur le blog de Lennart

            Posté par . Évalué à  2 .

            Ou comment je lance 3 fois openvpn ( http://0pointer.de/blog/projects/instances.html ), pareil, faut aller patcher le script, ou refaire son script.

            Avec un outil qui sert à ça ?

            # grep "CONNECTION=" /etc/network.d/{foo,bar,baz}
            CONNECTION="openvpn"
            CONNECTION="openvpn"
            CONNECTION="openvpn"
            # netcfg up foo
            # netcfg up bar
            # netcfg up baz
            
            
            • [^] # Re: Sur le blog de Lennart

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

              Netcfg, ça rentre pas dans init, donc ça montre bien que pour faire ce que systemd gére de façon native et générique ( car le système de template, ça s'applique à plus qu'openvpn ), il faut que tu adaptes un système à part, et que tu refasses le taf pour chaque sous domaine. Ie, je range ça dans la catégoerie "refaire ton script", ie déléguer

              Genre, tu veux refaire ça pour un bot irc, tu va devoir refaire le taf de 0. Tu veux faire ça pour des instances oracles, faut refaire le script et l'outil. ( ou comme déja vu à mon ancien taf, avoir 8 démons syslog dans un chroot chacun )

              Bien sur, des solutions existent. On a pas attendu systemd pour ça. mais systemd permet d'industrialiser ça, et ça permet donc de rendre les choses plus accessibles.

              • [^] # Re: Sur le blog de Lennart

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

                Et d'ailleurs, pour résoudre des équations aux dérivées partielles, il faut un programme externe qui ne rentre pas dans init, alors que systemd gère cela de façon native et générique. Ergo systemd est supérieur.

                Il manque une petite base de registres, une interface graphique, et là on aura une vraie révolution de l'informatique sous Linux.

              • [^] # Re: Sur le blog de Lennart

                Posté par . Évalué à  3 . Dernière modification : le 26/10/12 à 19:34

                Juste pour la précision, OpenRC fournit bien un système de templating comme systemd, c'est pas que pour le réseau.

                • [^] # Re: Sur le blog de Lennart

                  Posté par . Évalué à  2 .

                  Encore un truc qu'on ne trouve que sur une seule distribution, alors que systemd est disponible sur la plupart des grosses distributions.

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

                • [^] # Re: Sur le blog de Lennart

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

                  Oui, le mécanisme de systemd est clairement inspiré de celui de gentoo.

                  Sauf erreur de ma part, la convention est de faire un lien vers le script, en rajoutant .toto.
                  Puis dans le script, on joue avec SVCNAME et on retrouve des choses comme

                  VPN=${SVCNAME#*.}
                  
                  

                  pour dire que le nom du VPN qu'on prends, c'est toto, et on ajuste partout dans le script.

                  Un truc tout simple qu'on aurait pu adapter à service/chkconfig, mais que sauf erreur de ma part, personne n'a fait.

                  Perso, j'ai toujours pensé que openrc/gentoo était en avance sur un certain nombre de concepts. Par exemple, il y a eu un système de dépendance à l'init avant que les distros plus classiques s'y mettent. Il y a toujours eu la séparation entre start/stop ( et pas besoin d'explicitement dire "le restart se fait avec stop et start" ) ou de rajouter partout le même switch/case pour les arguments. Les créateurs de la distro ont fait le choix d'aller au delà des 6 runlevels traditionnels ( comme le hurd ), concept qu'on retrouve aussi dans systemd, ce qui permet une forme d'héritage des runlevels ( et que je trouve plus élégant que la façon de faire de systemd avec wants, des targets, etc ).

                  ( tout comme je pense que faire un ebuild est largement plus simple qu'un deb ou un rpm ( en partie aussi parce que la policy gentoo est bien moins contraignante ))

            • [^] # Re: Sur le blog de Lennart

              Posté par . Évalué à  2 .

              Et tu fais ça sur toutes les distributions ? Parce que sous Debian, j'ai pas de /etc/network.d.

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

              • [^] # Re: Sur le blog de Lennart

                Posté par . Évalué à  1 .

                Même question avec systemd.

                • [^] # Re: Sur le blog de Lennart

                  Posté par . Évalué à  4 .

                  Ben oui, je fais la même chose avec toutes les distributions qui fournissent systemd, c'est-à-dire Debian, Fedora, Suse, Mandriva, Arch, bientôt Red Hat, autant dire les plus répandues.

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

  • # Gros binaire

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

    Le dernier binaire vraiment impressionnant que j'ai eu l'occasion de croiser, c'était celui d'un chromium tout frais compilé qui dépassait les 100MiO. Soit à peut près deux Damn Small Linux. Est-ce que systemd joue vraiment dans le même catégorie ?

    • [^] # Re: Gros binaire

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

      $ ls -lh /lib/systemd/systemd
      -rwxr-xr-x. 1 root root 1000K 23 oct. 02:35 /lib/systemd/systemd

      Bah, il tient tout juste sur une disquette.

  • # journal fort argumenté

    Posté par . Évalué à  5 .

    on y apprend que systemd est décrié par certain comme spof et fait pleins de trucs qui incombait avant à différent démons.
    jusque là ça va.

    Ensuite on a un lien vers un article (pas de résumé ni rien) et une concliusion en disant "donc c'est bien" …
    je regarde en rapide , chouette c'est un article 18 sur un truc parlant d'un journalctl et qui sert à gérer la persistence ?
    Je sais pas a quoi sert journalctl et visiblement il faut que je m'amuse à saute mouton pour lire un article d'un autre blog pour comprendre les tenants et aboutissants de journalctl.

    Quand même.
    Supposons que je suis maso et que quand je cherche une info, j'adore perdre 3 heure a rebondir d'article en blog en page de man.

    Donc cette sublime page nous montre quelques exemples d'utilisation de ladite commande avec 4 options.

    Cool …

    Et à partir de ça on arrive à avoir "donc systemd finalement c'est super abouti" ?

    Pour rappel le donc entraine une implication, et je ne vois aucun raisonnement un tantinnet logique, même pour le cerveau le plus tortueux pour arriver à lier l'article sur journalctl qui montre 4 arguments à cette dernière, et le fait que systemd soit "abouti et utile".

    Bref on affirme un truc, et bien entendu, comme d'hab, sans référence correcte.

    Mais bon continuons.

    La personne "lis lennart lui expliquer des trucs et finalement systemd est pa si monolithique que ca. Regardez le nombre de page de man"…
    Comme il y a plein de page de manuel, le projet n'est pas monolithique…
    1°) Quand on ré-écris les binaires classiques forcément on rajoute des lignes. Je pense à … hostname (non mais franchement qu'est ce que hostname viens foutre dans systemd ???)
    2°) Regarde le nombre de page de manuel d'openssl. Et sisi openssl c'est un bon gros truc monolithique.
    3°) est ce que tu peux utiliser les outils de systemd de façon indépendante (sans systemd) ? Parce que bon 80% des pages de manuel sont dans les "S" avec des systemd.qqch ou équivalent.

    Bref encore une fois, on prend un exemple et on a une conclusion qui n'a rien a voir avec l'exemple.

    Enfin le dernier commentaire "tout est documenté en page de man donc c'est bon pour les admins unix"… Comment dire, que tout soit documenté c'est une condition nécessaire mais pas suffisante pour que ce soit "bon pour les admins GNU/Linux" (et non pas unix comme faisait remarquer un commentaire.

    Enfin malgré tout ça, je ne vois toujours pas en quoi systemd est mieux que le système actuel.
    Je ne vois toujours pas comment je peux modifier facilement l'équivalent de rc.S sous systemd…

    • [^] # Re: journal fort argumenté

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

      Allez, encore un mec qui ne sait pas de quoi il parle…

      qu'est ce que hostname viens foutre dans systemd

      hostname n'est pas dans systemd, hostname existe toujours. Systemd est par contre capable de lire le nom de la machine et de le changer (ouh la la, ca doit être violent comme code ça…)

      Bref encore une fois, on prend un exemple et on a une conclusion qui n'a rien a
      voir avec l'exemple.

      Non, c'est vrai, il est bien connu que les exécutables de postfix (donné en exemple) peuvent fonctionner tout seul ou encore mieux avec un autre MTA…

      • [^] # Re: journal fort argumenté

        Posté par . Évalué à  7 .

        Systemd est par contre capable de lire le nom de la machine et de le changer (ouh la la, ca doit être violent comme code ça…)

        Ce n'est pas à l'init de faire ça mais à l'outillage réseau.

        Si systemd veut appeler hostname(1) pour changer le nom de la machine ça me va.

        Mais ce n'est pas à ce putain d'init de changer mon nom de machine.

        Bordel. Nonmého. Fopadéconé non plus.

        Lennart faut qu'il arrête la fumette hein.

        Il va recoder ifconfig et le mettre dans systemd pendant qu'il y est ?

        cd /pub && more beer

        • [^] # Re: journal fort argumenté

          Posté par (page perso) . Évalué à  9 . Dernière modification : le 24/10/12 à 17:38

          ifconfig est obsolète, utilise iproute2 et ifup/ifdown :-)

          ip route (ou ip r)
          ip addr (ou ip a)
          ip link (ou ip l) pour les interfaces, les vlans
          ip tunnel
          ip neigh (pour les infos arp)


          https://en.wikipedia.org/wiki/Iproute2

          C'est assez intuitif passé les 200 premières utilisations.

          • [^] # Re: journal fort argumenté

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

            Je refuse d'utiliser une usine à gaz qui fait tout et n'importe quoi et souhaite repartir sur des bases KISS et des outils qui font une chose et qui la font bien!

            À bas iproute2!

            Qui m'aime me suive!!

            Hé! Les gars… vous venez?!?
            Nan mais ho!! Hé!! iproute2 c'est le systemd des outils réseaux, là!! Faut se révolter!

            En plus, j'ai pas lu la doc, donc on peut pas dire que ce soit plus pratique ou simple à utiliser: moi je sais pas m'en servir, et ifconfig, je sais m'en servir!!

            ------------------> [ ]

        • [^] # Re: journal fort argumenté

          Posté par . Évalué à  4 . Dernière modification : le 24/10/12 à 17:56

          J'allais répondre la même chose. Mais je pense que tout ça part d'une incompréhension énorme à la base: systemd n'est pas seulement un système d'init. C'est un ensemble d'outils et de modules pour gérer le système, et cet ensemble comprend l'init.

          Ce qui fait peur finalement, c'est le coté tentaculaire, aux limites floues, de systemd. Qu'il y ait une API D-Bus pour hostname, je trouve ça chouette. Mais je ne vois pas le rapport avec le coeur de systemd là-dedans: Lennart tente-t-il d'écrire une implémentation par défaut de plein d'APIs D-Bus dédiées à la gestion du système ? C'est une idée intéressante, mais pour moi c'est un projet à part, qu'il faudrait séparer de systemd lui-même.
          D'ailleurs je suis sûr que si Lennart l'avait présenté ainsi, beaucoup de gens ne se seraient pas tant braqués.

          • [^] # Re: journal fort argumenté

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

            Il faut au minimum passer par D-Bus pour lire ou définir le hostname. On est en 2012, on a du cycle CPU à consommer !! Trop fun !

            Se contenter de lire ou d'écrire dans /proc/sys/kernel/hostname c'est tellement has been, so 90'.

            • [^] # Re: journal fort argumenté

              Posté par . Évalué à  3 .

              C'est surtout une question de droits. Le service dbus permet à n'importe quel utilisateur de changer le hostname. Ecrire dans /proc/sys/kernel/hostname nécessite d'être root.

              • [^] # Re: journal fort argumenté

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

                Le service dbus permet à n'importe quel utilisateur de changer le hostname.

                Et il y a combien d'autres services/couches pour empêcher cette idiotie?

                Newton Adventure est sur Lumière Verte : http://steamcommunity.com/sharedfiles/filedetails/?id=187107465

                • [^] # Re: journal fort argumenté

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

                  En fait, ça gère plus que le simple hostname. Il y a aussi le concept de nom d'affichage, et un nom statique ( qui correspond pas forcément au nom attribué par le réseau )

                  Donc j'invite les gens voulant troller à au moins lire la doc ( genre
                  http://www.freedesktop.org/wiki/Software/systemd/hostnamed ).

                  Quand on dit "permet de", ne pas comprendre que ça veut dire que tout le monde peut le faire sans mot de passe ou sans controle. En l'occurence, l'objet dbus est sur le bus systéme, qui n'est pas accessible au commun des mortels en écriture. Dbus laisse pas n'importe qui faire n'importe quoi, mais au contraire, en séparant en 2 les choses, proposent une méthode plus sur et plus souple. Par exemple, si tu es sur un système mono utilisateur des familles, dbus peut suivre une politique policykit moins restrictive ( par exemple, demande du mot de passe de l'utilisateur, ou pas de demande de mot de passe, ça reste qu'un nom d'hote ).

                  Si tu es dans un réseau avec un admin, bah tu prends une autre politique dans policykit ( décidé par l'admin ou la distro ), et qui demandes le mot de passe root.

                  Ce qui fait que tu repousses la problématique de config en dehors du soft.

                  Dans la plupart des cas sans ça, tu va devoir
                  1) trouver comment passer root dans ton soft ( méthode habituel, tu lances tout l'ui via sudo )
                  2) rajouter une config spécifique à ton soft, ou décider de coder en dur le mot de passe que tu demandes
                  3) refaire du taf comme la demande de mot de passe, le changement du fichier et de /proc

                  Pour moi, avoir un démon lancé à la demande ( cf la doc ) pour gérer ça, ça me parait plus propre d'un point de vue de l'architecture.

              • [^] # Re: journal fort argumenté

                Posté par . Évalué à  1 .

                La plupart des distributions GNU/Linux s’orientent vers le desktop les laptops mono-utilisateur que veux-tu…

              • [^] # Re: journal fort argumenté

                Posté par . Évalué à  1 .

                Euh perso je NE VEUX PAS que mes users me change le nom de la machine.

              • [^] # Re: journal fort argumenté

                Posté par . Évalué à  2 .

                Boudiouh ! Je comprends mieux pourquoi d-bus et toutes les nouveautés sont si décriées par les dinosaures.

                A quoi ça sert de se faire chier à coller des droits/propriétaires sur des ficheirs, faire des séparations quenelle/boulet (comprendre: kernel/user) si c'est pour se faire vomir dessus par le premier sex-toy venu du monde de la contrefaçon ?

                • [^] # Re: journal fort argumenté

                  Posté par . Évalué à  10 .

                  L'étape d'après c'est de comprendre en quoi la dualité root-user ou la vue FS n'offre pas toujours une granularité suffisante et pourquoi une gestion plus fine des droits peut être intéressante.

                  • [^] # Re: journal fort argumenté

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

                    Ou juste se souvenir que par exemple, on peut pas changer les droits partout :

                    # chown misc /proc/sys/kernel/hostname 
                    chown: changement de propriétaire pour « /proc/sys/kernel/hostname »: Opération non permise
                    
                    

                    ( et par pitié qu'on me dise pas "mais je peux le faire avec sudo et cat" )

                    • [^] # Re: journal fort argumenté

                      Posté par . Évalué à  2 .

                      En fait je considère que les droits positionnés en dehors de /home (grosse maille) ne relève de personne d'autre que du super-user. C'est peut-être une approche naive mais ça évite bien des prises de tête. Je n'ai, pour reprendre ton exemple, jamais eu besoin de changer le hostname d'une machine en mode RUN.

                      Je vous rejoinds sur la rigidité du système des ACLs et des difficultés à mettre en oeuvre un système plus souple par contre.

              • [^] # Re: journal fort argumenté

                Posté par . Évalué à  6 .

                il y a d'autres raisons je pense à utiliser dbus, imagine que tu changes le nom de ta machine, dbus permet de prévenir les applications de ce changement.

                Faut arrêter de prendre les développeurs pour des cons, ça n'a jamais été simple de changer ne serait-ce que le nom d'une machine sous un Unix, ou une distribution Linux.

                On peut reprocher à SystemD de changer des trucs, mais il va grandement homogénéiser les distributions Linux (qui dépenseront moins d'énergie à perdre du temps à faire la même chose).

                • [^] # Re: journal fort argumenté

                  Posté par . Évalué à  -1 .

                  mais il va grandement homogénéiser les distributions Linux

                  On perd l’aspect Darwinien :'(

                  • [^] # Re: journal fort argumenté

                    Posté par . Évalué à  5 .

                    Pas du tout, on est en plein dedans.

                    Des distributions évoluent vers un homogénéisation, si elles sont mieux adaptées à l'écosystème de l'informatique elles croîtront, si au contraire elles perdent leur public au profit d'autres OS, elles tenteront une retour en arrière et disparaîtrons peut-être !

                • [^] # Re: journal fort argumenté

                  Posté par . Évalué à  2 .

                  Admettons.

                  Mais ce n'est pas au daemon gérant l'init de faire ça.

                  Ça, c'est le boulot de hostname, ou dhcpcd ou dhclient ou à la limite celui de NetworkManager, mais pas de l'init.

                  Qu'on adapte tout ça pour éventuellement causer via DBUS, pourquoi pas, mais qu'on arrête de vouloir tout mettre dans le daemon d'init.

                  Systemd est gonflant à vouloir refaire le boulot de tous les outils existant déjà.

                  Lennart, si il n'est pas content, il fait LennartOS pour prouver que ça marche bien et mieux et on laisse aux autres distros le soin de prendre ou pas. Mais il fout la paix à l'existant.

                  cd /pub && more beer

                  • [^] # Re: journal fort argumenté

                    Posté par . Évalué à  4 .

                    Bah c'est ce qu'il fait après, ça s'appelle pas LennartOS mais Fedora / RedHat. Et figure toi que comme d'autre trouves ça interressant, elles le prennent. Les distrib qui l'intègre n'ont jamais eu le couteau sous la gorge pour les forcer à utiliser Systemd ou tout autre "horreur" de Lennart. Il fait juste proposer et les intègre dans la distrib' de son employeur.

                  • [^] # Re: journal fort argumenté

                    Posté par . Évalué à  5 .

                    Ah ben ça tombe bien, c'est pas dans le code de l'init. C'est dans un daemon à part, lancé par systemd. Ce daemon propose la fameuse API D-Bus.
                    J'ai de gros doutes sur systemd, notamment sur le fait qu'il arrive à garder indépendantes des briques qui devraient l'être. Pour l'instant, c'est encore bon; mais pour combien de temps ?

                    En attendant, il faudrait commencer à réaliser qu'assimiler systemd à l'init, c'est comme assimiler GNU/Linux au noyau: c'est faux.

                    • [^] # Re: journal fort argumenté

                      Posté par . Évalué à  1 .

                      oui, et c'est bien ce qui est décrié (qu'ils fassent le café en plus de l'init).

                      • [^] # Re: journal fort argumenté

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

                        Si tu ne veux pas qu'il ne fasse, il suffit de ne pas lancer ces processus au démarrage (que tu utilise systemd ou pas).

                        « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                        • [^] # Re: journal fort argumenté

                          Posté par . Évalué à  1 .

                          Et si j'ai pas envie de lancer dbus ? :)

                          Et j'ai envie de minimiser les possibilité d'attaque. C'est pas en rajoutant du code au niveau de binaires aux privilèges extrêmement élévé (même avec des MAC activés) que je peux diminuer mes vecteurs d'attaques.

                          • [^] # Re: journal fort argumenté

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

                            Je pense que c'est possible (peut-être pas facilement) mais on perd beaucoup d'avantage de systemd.

                            « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                            • [^] # Re: journal fort argumenté

                              Posté par . Évalué à  3 .

                              Et c'est bien une partie de mon reproche initial.

                              systemd c'est un système d'init pour les poste bureautique … Et encore pas trop exigeant.

                              Sous couvert de nouveauté on rajoute des tas de trucs, on dépend d'une tonne de dépendances difficilement dissociable (fameux principe KISS oublié)

                              J'ai un temps de boot système moins important sur ma machine perso (debian), qui doit avoir 3-4 ans et une tonne de service (un proxy, un postgresql, un lighttpd, argus, ….) que sur les postes au bureau sous ubuntu (que bureautique donc normalement que le X a lancer…) ou sous le portable sous fedora de mes parents (qui lancent aussi une tonne de services inutile au possible).

                              On ris au nez des admins qui ont peu d'expérience et qui voient que quand on fait un bloatware, peut être avec les meilleurs idées du monde , il finira immanquablement par s'engrossir et s'enlaidir.

                              Et là pour un init on demande d'avoir dbus de lancer…
                              niveau "moins de service et plus de rapidité" on repasseras …

                              Avec un systemd d'init simple et léger initial, et des modules que l'ont peut désinstaller (physiquement, pour éviter que le code existe sur la machine et faire de la place par exemple) ou installer suivant ses besoins, systemd aurait eu beaucoup moins de détracteur, et aurait facilité le dvp (beaucoup plus facile de débugger et/ou de proposer un patch une sous sous partie bien délimité que tu peux relancer à la volée qu'un système d'init complet).

                              mais non, c'est qu'on est "contre le progrès" …

            • [^] # Re: journal fort argumenté

              Posté par . Évalué à  3 .

              "Passer par D-Bus", c'est pas non plus la mer à boire. Même si on lui trouvait un remplaçant, avec un daemon qui unifie et centralise les communications entre différentes briques du système, ça ressemblerait fortement à D-Bus. De quoi dépend D-Bus ? De la libc.

              Dans une opération non critique en temps, qui demande de faire attention aux droits et où le message d'erreur en retour peut être intéressant pour l'utilisateur, je trouve que c'est un choix qui se défend.

              • [^] # Re: journal fort argumenté

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

                En fait, avoir un système d'appel ou de commande distant, il y a ça depuis toujours.
                Des bus d'entreprises, y en a dans les SI des grosses boites ( EJB, etc ). rpcbind, c'est très lié à NFS et à Sun ( donc Unix ), tout comme l'équivalent dans samba. Named utilise son propre système de rpc pour se lancer. Même avec le vénérable init, c'était quoi le fait d'écrire dans /dev/initctl si c'était pas un protocole de communication ultra simplifié ?

        • [^] # Re: journal fort argumenté

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

          Sur une distro avec sysvinit, c'est init qui lance un script qui lance un script qui change le nom de la machine.

          Sur systemd, bah il lit le fichier, et il le fait. Ça me choque pas.

    • [^] # Re: journal fort argumenté

      Posté par . Évalué à  8 .

      non mais franchement qu'est ce que hostname viens foutre dans systemd ???

      Ça a toujours été dans le système d’init l’appel à sethostname il me semble (sous forme de script d’init sous sysvinit, directement dans le process d’init sous Arch et Pardus)

  • # Personnellement ce qui me gène le plus avec systèmd ...

    Posté par . Évalué à  9 .

    C'est ce genre de truc , comme toute lennarterie qui se doit.

    Si sustemd ne se contentait que de hanger la façon de démarrer des process, ça ne me gènerait pas. Le problème c'est que ça va beaucoup plus loin, et que ça va devenier la grosse galère de porter les logiciels spécifiquement écrits pour systemd (et les horreurs qui gravitent autour) vers d'autres systèmes.

    Les process démarrés par n'importe quel système ne devraient pas se soucier du fait qu'ils soient démarrés par systemd ou autre chose. De même que le programme ne devrait pas savoir s'il ytilise le système de logs classique ou on : ce choix doit revenir à l'admin.

    • [^] # Re: Personnellement ce qui me gène le plus avec systèmd ...

      Posté par . Évalué à  2 .

      Je suis entièrement d'accord sur la conclusion, mais pas sur le prémice.

      Si les process avaient à savoir qu'ils sont démarrés par systemd, ça serait vraiment mal fichu je pense. Mais en l'occurence, ce qu'ils ont à savoir, c'est la méthode de démarrage (par socket d'activation) qui peut changer certaines choses. Et ça, c'est la bonne façon de faire quand on veut introduire une nouveauté.
      Si tu introduis une nouvelle API dans la libc, les processus doivent pouvoir l'utiliser sans savoir qu'ils sont sur un noyau linux 3.6.5 ou 3.6.42
      Une nouvelle fonctionnalité est proposé, et ils l'utilisent. Et c'est galère à porter sur des libc qui n'ont pas ces fonctionnalités. Mais c'est comme ça qu'on avance et que des nouveautés sont introduites.

  • # Réjouissez-vous ...

    Posté par . Évalué à  6 .

    Car on va aussi pouvoir accéder aux logs via une interface HTTP \o/

    http://cgit.freedesktop.org/systemd/systemd/commit/?id=7b17a7d72f5ba5ad838b19803534c56a46f3bce9

Suivre le flux des commentaires

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