Journal Systemd va gagner une console système, un bootsplash et un login-screen

Posté par (page perso) . Licence CC by-sa
Tags :
44
30
nov.
2013

Bonsoir, amis amateurs de systemd. Nous ne sommes plus Vendredi, mais j'ai pensé que ceci méritait d'être souligné :

http://lists.freedesktop.org/archives/systemd-devel/2013-November/014808.html

Pour les anglophobes, cela dit en gros que 4 nouveaux modules vont être ajoutés à Systemd :

  • systemd-consoled: Une console systemd (émulateur basique de terminal)utilisé comme session/console de "fallback" (secours ?).

  • systemd-splashd: Un boot-splash pour les initrds. Il n’inclura pas d'"eye-candy" (beaux graphismes?) mais sera seulement requis pour accepter les champs de mot de passe pour les partitions root encryptées. Il faudra utiliser Plymouth pour avoir des graphismes sexy.

  • systemd-welcomed: Un login-screen pour lancer des sessions. Cela remplace /sbin/agetty et /bin/login dans un VT. Après le login, il lance systemd-consoled.

  • systemd-er: L’assistant de la salle d'urgence.
    En résumé, une systemd-console en plus dépouillé conçu pour les développeurs. Ce n'est pas activé par défaut. Pensez-y comme une variante de "magic sysrq" en espace utilisateur.

Si vous n'aimez pas ces changements, vous n'aurez qu'à mettre CONFIG_VT=y au lieu de CONFIG_VT=n .

Des avis sur ces changements, pour ceux connaissant mieux ces parties du système ?

  • # La touche finale

    Posté par . Évalué à 1.

    Merci

    Je pense que c'est bien que systemd apporte sa touche finale avec un bootsplash graphique. Jusque là, en mode console, on avait seulement le manchot repu, ce qui est un peu limité.

    • [^] # Re: La touche finale

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

      À quand une alliance entre les devs de Systemd et Emacs pour nous faire enfin un vrai système d'exploitation ?

      • [^] # Re: La touche finale

        Posté par . Évalué à 9.

        Ils savent sans doute qu'une telle alliance serait vouée à l'échec car elle ne serait pas en mesure de prendre l'ascendant sur MultideskOS.

        Sinon, moi j'utilise vim (on est samedi).

        • [^] # Re: La touche finale

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

          Sinon, moi j'utilise vim (on est samedi).

          Pas de soucis, Systemd a besoin d'Emacs parce qu'il ne propose pas encore de navigateur web, et Emacs n'a pas encore à ma connaissance de login-screen avec bootsplash, mais aucun des deux ne propose un éditeur de texte, donc on est peut-être encore à temps pour nécogier cette partie là, faudra faire une feature-request dans leur bugtracker.

    • [^] # Re: La touche finale

      Posté par . Évalué à 1. Dernière modification le 30/11/13 à 12:31.

      Dans sa dernière diatribe sur son compte +Lennart, Lennart bien conscient que systemd est "validé" fini par expliquer réellement l'impact de ce dernier et qu'il va être très difficile de faire sans ce composant, chose qu'il niait au départ.

      The other thing is kdbus. The userspace of kdbus pretty much lives inside of systemd. Bus activation work will be using the same mechanisms as socket activation in systemd, and again you cannot isolate this bit out of systemd. Basically the D-Bus daemon has been subsumed by systemd itself (and the kernel), and the logic cannot be reproduced without it. In fact, the logic even spills into the various daemons as they will start shipping systemd .busname and .service unit files rather than the old bus activation files if they want to be bus activatable. Then, one of the most complex bits of the whole thing, which is the remarshalling service that translates old dbus1 messages to kdbus GVariant marshalling and back is a systemd socket service, so no chance to rip this out of systemd.

      Pareil pour logind etc…

      Canonical over the years has been working hard on building its own stack that is different to what others do to a major degree. Whether it is Upstart, Mir or Unity, there's a line through the whole stack where they make other choices. Every one of them is pretty much a Canonical exclusivity right now. It's up to Debian to decide whether to follow that, or whether the other communities aren't the happier places to be in.

      Je ne sais pas vous mais on n'est pas très loin de la rangaine GWBush: "Vous avec nous ou contre nous".

      D'où vient la suprématie de RedHat? Pour quiconque l'ayant utilisé en server, c'est une plaie! Fedora est horrible et je ne comprends pas que ça puisse "faciliter" la vie à un développeur.
      Sont-ce là les distributions qui vont définir le GNU/Linux de demain?

      • [^] # Re: La touche finale

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

        Dire que systemd devient nécessaire alors que ce n'était pas annoncé, ça se tient. Dans ce cas prends en toi à toutes les distro qui adoptent systemd, puis prends en toi à Greg Kroah-Hartman.

      • [^] # Re: La touche finale

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

        Pour quiconque l'ayant utilisé en server, c'est une plaie!

        Non. La plaie vient du fait qu'on cherche à utiliser RHEL comme Debian. La plaie vient aussi du fait qu'on démarre de projets en entreprise sur des versions antédiluviennes au lieu de prendre la version actuelle.

        Pour la maintenance à long terme d'un projet, RHEL c'est juste parfait :

        • pas de mises à jour qui pètent tout
        • un bon niveau de QA, peu de surprises.
        • un support vraiment long.

        RedHat te permet d'avoir une version de PHP maintenue durant plus de dix ans. Si cela ne t'intéresses pas alors tu t'es simplement trompé de distribution.

      • [^] # suprématie de RedHat?

        Posté par . Évalué à 4.

        Parce que des entreprises qui édite une distribution Linux avec un vrai support pouvant donner confiance aux entreprises se compte sur les doigts de la main.
        Mandriva = Très peu connu dans le monde de l'entreprise et plus pour sa version "grand public" que ses serveurs.
        Ubuntu = De base grand public et commence a percer sur les serveurs car de nombreux admin son séduit par la version bureau, je sais c'est pas logique mais c'est les retours que j'ai. Surtout d'admin Windows qui sont "obligés" d'avoir un serveur Linux.
        Suse = Trop peu connu malgré ses qualités, ils ont eux aussi adopté systemd

        Il me semble que IBM édite aussi une version de Linux mais pousse plus son AIX sur les grose machines.

        RedHat a toujours fait dans l'entreprise et les gros systèmes et ils ont acquis une belle notoriété dans ce domaine. Enfin et surtout RedHat est une boite Américain, donc tout le reste importe peu aux décideur pressé qui considère que le choix américain est toujours le meilleur :-/

        • [^] # Re: suprématie de RedHat?

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

          Il me semble que IBM édite aussi une version de Linux mais
          pousse plus son AIX sur les grosses machines.

          IB n'édite pas de version de Linux, ils proposent du RHEL, voir du SLES, en fonction de ce que les clients demandent. Si jamais les clients venaient à demander en masse autre chose, je suis sur qu'IBM le ferait sans souci.

      • [^] # Re: La touche finale

        Posté par . Évalué à 10.

        D'où vient la suprématie de RedHat ?

        Peut etre parce qu'ils ont un developpeur qui est un bon leader de developpeurs. Redhat n'est pas seul a developper systemd. Ce n'est d'ailleur pas une contribution de redhat, mais de David Herrmann qui est encore etudiant en Allemagne. Demande toi plutot comment avahi, pulseaudio, systemd ont pu reussir en etant si mauvais et nuisible a tes yeux a etre choisi par tout un tas de developpeurs et de distributions sur lequel RedHat n'a pas de controle. Et si tu as encore des doutes, commence donc a coder des alternatives et devient le leader de la resistance ! :-D

      • [^] # Re: La touche finale

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

        D'où vient la suprématie de Red Hat ?

        Je pense que ça vient de plusieurs choses.

        D'une part, du fait d'avoir des développeurs en grand nombre. Je peux citer par exemple les contributeurs à gcc, à Linux, à gnome, etc, etc. Des logiciels que tout le monde utilise sans le savoir sont des contributions directs de salariés de la boite, comme par exemple kvm. Tu retrouves les gens dans les projets comme coreutils ( http://git.savannah.gnu.org/cgit/coreutils.git ). Tu peux avoir plus de détails sur http://community.redhat.com/software/

        Ensuite, le fait d'avoir pris le magma primal qu'est le corpus de logiciels libres disponibles et d'en avoir fait un produit fini. Plein de boite le font, je ne dit pas le contraire, mais RH a réussi à s'en tirer de façon des plus honorables. La documentation traduite, écrit par des personnes à temps plein, a beaucoup aidé pour la perception du logiciel libre. De même, le fait de faire de la QA un peu plus formel que "si personne ne signale de bug alors c'est bon", de faire des revues de sécurités sur le code, de faire certifier les OS pour divers gouvernements, etc. Ou simplement de proposer du support, des roadmaps sur leurs produits.

        Et troisièmement, le fait de ne pas s'opposer à la communauté, mais d'en faire parti. Par exemple, avoir monté des choses comme l'OIN pour tous et pas juste pour leur propre pomme, d'envoyer des avis légaux sur les procés sur les brevets logiciels afin d'aider à établir une jurisprudence en faveur du libre, d'être sponsor pour la Linux Fondation, pour pycon et d'autres, d'avoir aidé à monter la fondation Openstack, d'avoir proposé des briques comme libvirt ( sur lequel repose quand même pas mal de projet d'IaaS du moment ).

        Pour quiconque l'ayant utilisé en server, c'est une plaie!

        C'est une affirmation qui manque fortement de substance, et je suis sur que ton propos gagnerais en solidité si il était moins lapidaire. Mais sinon, il semble qu'il y a plein de gens satisfait de RHEL sur les serveurs, en partie de part la stabilité de la chose.

        Sinon, moi, j'ai une Fedora sur un serveur, et je suis content d'avoir des choses comme selinux, comme systemd, comme des versions récentes de divers composants. Peut être qu'il y a des gens qui sont content d'avoir hadoop sans installer à la main ( cf https://fedoraproject.org/wiki/Releases/20/ChangeSet ) ou sans avoir à prendre des dépôts non officiels.

      • [^] # Re: La touche finale

        Posté par . Évalué à 4.

        Lennart dit que systemd n'est pas un marché de composant, et qu'il n'a pas l'intention de faire pour les autres le boulot d'extraction de logind, consoled, kdbus, etc.

        Libre à Canonical de forker. Ce qu'il font déjà pour logind. Mais qu'ils ne se plaignent pas.

  • # Busybox

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

    Ce sera en somme un super busybox ?

    • [^] # Re: Busybox

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

      bientôt, systemd-os, avec un serveur graphique qui va remplacer X11 wayland

      « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

      • [^] # Re: Busybox

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

        Il va falloir t'y faire, tu devras démarrer le serveur D avec startd et le .dinitrc, puis configurer ton dterm à l'aide du .Dressources. Pour le gestionnaire de fenêtres tu auras le choix entre dwm et xmonaD; dmenu pour lancer les applications et dzen pour afficher des infos sur la barre. Il paraît qu'on pourra désactiver certains trucs sur un fichier de conf, mais c'est sans doute juste un piège. Et d'ailleurs, ne faisons pas trop comme si on était surpris, alors qu'on pouvait s'en douter il y a longtemps que le mal s'était déjà glissé parmi nous : cd, dd, du, dmesg, ed,…

        • [^] # Re: Busybox

          Posté par . Évalué à 9.

          Au moins on aura droit à jackd par défaut, ce sera mieux que… mince, nous sommes foutus !

          • [^] # Re: Busybox

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

            on aura droit à jackd par défaut

            I have a dream…

            * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

            • [^] # Re: Busybox

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

              Faudrait avoir plus qu'un rêve, genre avoir la possibiltié de faire la chose, si seulement les sources des distributions étaient disponibles, et si seulement le code pouvait donner le droit de faire ce qu'on veut (ou presque) avec ..

              • [^] # Re: Busybox

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

                genre avoir la possibiltié de faire la chose, si seulement les sources des distributions étaient disponibles

                Figure-toi que j'ai quelques vieilles bricoles sonores qui trainent depuis des années, et dont je voudrais bien reprendre le développement. À l'époque (2007 en gros) j'en avait pas mal chié pour comprendre les subtilités de l'api d'ALSA. Et maintenant, je souhaite interfacer ces bricoles avec Jack, parce que bon, si tu veux faire du son sérieusement sous Linux, Jack me semble bien la voie à suivre.

                Et tout ça va se finir probablement par une Slack presque fabriquée à la main, pour ne pas avoir ce fscking pulseaudio en travers de mon chemin.

                Ça tombe bien, les sources sont disponibles :)

                * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

      • [^] # Re: Busybox

        Posté par . Évalué à 3.

        Entre Chrome, Android, Firefox OS, System D et même « FreeboxOS » qui a remplacé la chouette interface précédente de ma Freebox V6, les années 2010 seront celles de la guerre des aspirants OS. :-)

        J'ai bien peur qu'ils ne fassent tous qu'essayer de s'entretuer et qu'il ne se dégage rien de positif à l'issue de tout cela. Juste des centaines de miettes à gérer pour les gens qui travaillent dans le secteur…

    • [^] # Re: Busybox

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

      Non

    • [^] # Re: Busybox

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

      non parce que busybox a l'avantage d'être optionnel…

      « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

  • # .

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

    Sinon les FreeBSD c'est pas si mal maintenant qu'il y a pkg2ng.

    Opera le fait depuis 10 ans.

    • [^] # Re: .

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

      Sinon les FreeBSD c'est pas si mal maintenant qu'il y a pkg2ng.

      Oui mais non, il manque Systemd-pkg2ng.

  • # GNU/SystemD/Linux

    Posté par . Évalué à -9.

    J'espère franchement que Debian ne va pas adopté systemd, sinon il n'y aura plus de grande distribution de qualité qui ne sera pas sous le joug de cette brique obscure. L'avantage des Linux était de pouvoir remplacer une brique par une autre sans "trop" d'impact. Là il ne seras plus possible de se passer de ce composant sans tout refaire à la main. On parlera de GNU/SystemD/Linux

    • [^] # Re: GNU/SystemD/Linux

      Posté par . Évalué à 10.

      Les jolis briquent qu'on peut facilement remplacer. C'est cool, ca fait des jolis graphique pour les powerpoints. Apres dans la realite, je ne connais aucun logiciel qui remplace un autre. Il y a toujours quelques choses qu'on gagne, quelques choses qu'on perd. Depuis quand tu peux remplacer qt par gtk ou par les efl sans changement ? Et bind par dnsmasq ? Ou bash par csh ?

      Systemd apporte une coherence inter distribution qui n'existe pas sous Linux. Cela permet a un projet upstream de fournir un .unit qui fonctionnera de maniere optimale sur toutes les distributions. Plus de probleme de QA parce qu'un script est different ou parce que le shell est different ou on ne sait trop quel bizarrerie local. Et pour le meme prix, tu as tout un tas de fonction fort sympatique pour les devs qui l'utilisent.

      Mais bon, il ne faut pas oublier ce qu'est le logiciel libre. C'est un logiciel qui peut etre librement modifie pour etre adapate a SES propres besoins. Si ca ne te plaie pas, le code est libre, tu peux toujours l'adapter a tes besoins. Mais peut etre qu'a ce moment la tu decouvriras pourquoi la plus part des projets upstream ont librement decide de suivre systemd…

      • [^] # Re: GNU/SystemD/Linux

        Posté par . Évalué à -2.

        Apres dans la realite, je ne connais aucun logiciel qui remplace un autre. Il y a toujours quelques choses qu'on gagne, quelques choses qu'on perd.

        Non. Dans la pratique, on remplace jamais les logiciels qui marchent. Ceux là, on oublie presque qu'ils existent. Par contre on cherche à remplacer les logiciels qui marchent pas, qui sont de la merde, qui sont totalement inadaptés à ce qu'on veut faire, qui sont trop lent, trop gros, trop stupides, trop inutilisables ou trop limités.

        Si il y a autant de gens qui cherchent à remplacer NetworkManager, systemd, udev ou dbus, il faudrai peut-être regarder pourquoi.

        Depuis quand tu peux remplacer qt par gtk ou par les efl sans changement ? Et bind par dnsmasq ? Ou bash par csh ?

        La question ce n'est pas savoir si tu peux sans changement, c'est comment tu peux, et avec quels changements.

        Et puis, sérieusement, t'a vraiment besoin de Qt/GTK/EFL pour afficher un pov' texte sur une matrice LCD 200x40 ? T'a vraiment besoin de bind pour servir deux trois pecnos sur ton réseau local ? Ou d'un shell utilisable par un humain pour lancer deux trois scripts de démarrages sur une machine sans utilisateur ? Ou de lancer une session gnome pour afficher un écran de login ? Parce que dans tout les cas, ça va ptet te convenir à toi, mais chez d'autres, ça sera lent, chiant, inutilisable, ou les trois à la fois. Et ils devront changer ça.

        Systemd apporte une coherence inter distribution qui n'existe pas sous Linux.

        C'est complètement stupide comme idée. Systemd n'apportera jamais de cohérence entre Linux, BSD et Windows de toute façon, et les logiciels ne vont pas s'arrêter d'être portable.

        En fait, systemd ne va même pas apporter de cohérence dans les distributions Linux puisqu'il y aura des distributions Linux qui ne l'utiliseront pas et qui pourront même pas rester compatibles avec celles qui l'utiliseront tellement systemd n'est pas générique. Je vais pas encore ressortir le fameux XKCD, mais on est typiquement en plein dedans, Systemd n'est qu'un standard supplémentaire pour en unifier d'autres.

        Si tu a envie d'unifier des distributions Linux (et d'autres OS), tu fait pas des grosses implémentations monolithiques de standard hyper-spécifiques, tu fait des standard comme POSIX, FHS, LSB ou autres qui sont suffisamment génériques pour être applicables sur toutes les distributions Linux et Unix-like et voir même le gros OS monolithique qu'est Windows. Pas un faux "standard Systemd" qui dépend de D-Bus et de plein d'API spécifiques à Linux, et que tu ne peux pas intégrer à un système existant sans devoir tout refaire.

        Mais bon, il ne faut pas oublier ce qu'est le logiciel libre. C'est un logiciel qui peut etre librement modifie pour etre adapate a SES propres besoins.

        Raté. Un logiciel libre, c'est un logiciel qu'on réutilise. T'en vois souvent des logiciels clairement inadaptés se faire modifier en profondeur pour coller à un autre besoin ? Moi pas. À la place, je vois des grosses réimplémentations plus ou moins génériques, parce que d'une part ça prend moins de temps, ça collera mieux au besoin et que ça sera plus facile à maintenir qu'un fork d'un logiciel clairement pas fait pour et ou upstream ne voit même pas l'utilité du besoin.

        • [^] # Re: GNU/SystemD/Linux

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

          Si il y a autant de gens qui cherchent à remplacer NetworkManager, systemd, udev ou dbus, il faudrai peut-être regarder pourquoi.

          S'il y a autant de gens qui ont remplacé ce qu'il y avait avant par NetworkManager, systemd, udev ou dbus, il faudrait peut-être regarder pouquoi.

          mais on est typiquement en plein dedans, Systemd n'est qu'un standard supplémentaire pour en unifier d'autres.

          C'est quoi le(s) standard(s) en dehors de systemd (qui marche) des scripts init, du changement de hostname persistent, du changement de timezone… ?

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: GNU/SystemD/Linux

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

            NetworkManager, tu le vires et tu reprends le contrôle de ton réseau.

            C'est généralement la première chose que je fais quand un machine a un problème de connexion réseau, je regarde s'il y a NetworkManager et je le vire (proprement).

            Donc, non, la comparaison avec NetworkManager ne tiens pas.

            • [^] # Re: GNU/SystemD/Linux

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

              Si tu as un problème réseau avec NetworkManager et que ta seule solution est de le virer montre plutôt que tu ne sais pas l'utiliser correctement. NetworkManager est très puissant.

              • [^] # Re: GNU/SystemD/Linux

                Posté par . Évalué à 5.

                Si tu as un problème réseau avec NetworkManager et que ta seule solution est de le virer montre plutôt que tu ne sais pas l'utiliser correctement. NetworkManager est très puissant.

                Ah bah, t'a ptet raison, je sais peut-être pas l'utiliser correctement. NetworkManager doit être tellement puissant que je suis pas obligé de remonter des patches à son code moche pour lui rajouter des fonctionnalités.

                Je vais pas en dire plus, je risquerai d'être odieux. Ah je le suis déjà ? Mince alors.

              • [^] # Re: GNU/SystemD/Linux

                Posté par . Évalué à 10.

                Network-manager puissant ? Il ne faut pas exagérer non plus. Un gestionnaire de réseau qui ne gère pas les interfaces bridgés, c'est pas ce que j'appelle de la puissance. Non je ne travaille pas sur un serveur mais sur un portable avec des machines virtuelles qui me servent de maquettes et de support de démo.

                • [^] # Re: GNU/SystemD/Linux

                  Posté par . Évalué à 3.

                  Cela fait longtemps que je n'ai plus eu de problème avec network manager en combinaison avec un bridge pour les machines virtuelles. Sous Debian avec libvirt ça marche juste au poil, et NM n'essaie pas de chipoter avec les interfaces qu'il ne contrôle pas. Il s'abstient même explicitement de toucher aux interfaces qui sont définies dans /etc/network/interfaces (genre eth0 dans la config post-install par défaut de Debian).

              • [^] # Re: GNU/SystemD/Linux

                Posté par . Évalué à 6.

                Je confirme la puissance de NetworkManager et de systemd réunis. sur ma machine (Fedora 19), ils partent en vrille et me génèrent un /var/log/messages de plusieurs giga en qq heures. En qq jours, mon disque dur s'est retrouvé saturé, et j'avais beau faire du ménage, la place gagnée était automatiquement utilisée. J'ai depuis débarqué NetworkManager, après avoir passé des heures à écrire et tester des scripts systemd pour faire un pauvre dhclient de merde au boot.

                Peut être que systemd et son pote ont pleins de super avantages et que 2014 sera l'année du desktop sous Linux grâce à eux, en attendant c'est une véritable usine à gaz incompréhensible responsable du grand fail que j'ai rencontré sous Linux en 15 ans.

          • [^] # Re: GNU/SystemD/Linux

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

            C'est quoi le(s) standard(s) en dehors de systemd (qui marche) des scripts init,

            SysV RC.

            du changement de hostname persistent,

            echo "pouet" > /etc/hostname, un fichier utilisé par un script d'init fait pour.

            du changement de timezone… ?

            export TZ=Europe/Paris pour un changement spécifique à l'utilisateur. Pour un changement du fuseau horaire global, cp /usr/share/zoneinfo/Europe/Paris /etc/localtime.

            • [^] # Re: GNU/SystemD/Linux

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

              SysV RC.

              Un standard qui est différent par distribution, c'est un standard ?

              echo "pouet" > /etc/hostname, un fichier utilisé par un script d'init fait pour.

              Ça ne change pas l'hostname, ça le change après le prochain redémarrage. Ce n'est pas très user friendly.

              export TZ=Europe/Paris pour un changement spécifique à l'utilisateur. Pour un changement du fuseau horaire global, cp /usr/share/zoneinfo/Europe/Paris /etc/localtime.

              Ça demande aussi un redémarrage pour être appliquer. Si ta vision de Linux, c'est un truc à la Windows où il faut redémarrer dès qu'on change un paramètre, c'est bien mais je préfèrerais un truc mieux foutu.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: GNU/SystemD/Linux

                Posté par . Évalué à 3.

                Ça ne change pas l'hostname, ça le change après le prochain redémarrage. Ce n'est pas très user friendly.

                Faut être un peu couillon pour changer son hostname toutes les 5 minutes aussi.

                Ça demande aussi un redémarrage pour être appliquer. Si ta vision de Linux, c'est un truc à la Windows où il faut redémarrer dès qu'on change un paramètre, c'est bien mais je préfèrerais un truc mieux foutu.

                Sur un serveur on s'en fiche, et c'est même mieux qu'on ne puisse pas faire plein de changement à la volée : ça évite que n'importe qui fasse n'importe quoi sans prévenir personne. Quand tu fais des astreintes, c'est pas très agréable de se rendre compte qu'un truc ne marche plus parce que le hostname (ou autre) a été changé à la volée sans que personne ne soit prévenu. En cas de reboot, ça se voit plus facilement : faut demander un arrêt de service, ça risque pas de passer inapperçu.

                Ça ne change pas l'hostname, ça le change après le prochain redémarrage. Ce n'est pas très user friendly.

                hostname c'est pas mal non plus. Et pour être sur d'être cohérent avec ta config, un truc du genre hostname $(cat /etc/hostname) marche bien. Et surtout, ça n'a pas à être user friendly sur un serveur, mais admin friendly. Et les trucs user-friendly (qui bien souvent veut dire neuneu-friendly) , ça a tendance à ne pas trop plaire aux admins.

                • [^] # Re: GNU/SystemD/Linux

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

                  C'est encore pire : le gars d'astreinte qui va rebooter le serveur ne va pas comprendre pourquoi ces paramètres auxquels il n'a pas touché ont changé…

            • [^] # Re: GNU/SystemD/Linux

              Posté par . Évalué à 3. Dernière modification le 02/12/13 à 15:17.

              SysV RC.

              LOL, à pars Debian qui utilise encore cette m sous Linux ? Un système d'init même pas capable de suive le statut des processus qu'il a lancé…

              Je suis méchant mais demandez à n'importe qui dans la rue ce que je déteste sur Debian il répondra "le système d'init" et ce que j'aime ? /etc/network/interfaces

              echo "pouet" > /etc/hostname
              Debian specific, variable hostname du fichier /etc/conf.d/hostname pour Gentoo, variable HOSTNAME du fichier /etc/sysconfig/network pour RHEL/CentOS…

              • [^] # Re: GNU/SystemD/Linux

                Posté par . Évalué à 10.

                Je suis méchant mais demandez à n'importe qui dans la rue ce que je déteste sur Debian

                J'ai demandé à un type dans le métro, il m'a répondu "ta gueule". :(

                • [^] # Re: GNU/SystemD/Linux

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

                  C'est normal, il avait dit « dans la rue ».

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: GNU/SystemD/Linux

              Posté par . Évalué à 10.

              C'est quoi le(s) standard(s) en dehors de systemd (qui marche) des scripts init,

              SysV RC.

              Ben vas-y, montres nous comment tu fais marcher Apache sur une RHEL avec un script Debian. Rien que le nom et les chemins sont différents (httpd pour RHEL, apache2 pour Debian)…

              du changement de hostname persistent,

              echo "pouet" > /etc/hostname, un fichier utilisé par un script d'init fait pour.

              Ça c'est pour Debian. Ça ne marchera pas sous RHEL, où le nom est défini dans /etc/sysconfig/network.

              Bref, tu viens de prouver que non, rien n'est unifié.

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

              • [^] # Re: GNU/SystemD/Linux

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

                Bref, tu viens de prouver que non, rien n'est unifié.

                Quoi ? Debian n'est pas the universal operating system ? Ils nous ont donc menti depuis tout ce temps ?

        • [^] # Re: GNU/SystemD/Linux

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

          Si il y a autant de gens qui cherchent à remplacer (…) systemd (…) il faudrai peut-être regarder pourquoi.

          Wow… C'est vraiment nier la réalité, la transformer pour être en accord avec ses fantasmes.
          Quasi-tout le monde (on parle de ce qui doiven tse taper la maintenance hein, pas les trolleur qui foutent rien) veut mettre systemd sur Linux, et les seuls qui ne veulent pas sont ceux qui n'aiment pas le changement et veulent garder le "bohneur" de la maintenance pourrie de ce qui existe avant.
          Tu as raison sur un point mais en changeant juste un peu : Si il y a autant de gens qui cherchent à remplacer l'existant par systemd, il faudrai peut-être regarder pourquoi.
          Si tout le monde ou presque regarde systemd, c'est peut-être parce qu'il répond au besoin?

          Non. Dans la pratique, on remplace jamais les logiciels qui marchent. Ceux là, on oublie presque qu'ils existent. Par contre on cherche à remplacer les logiciels qui marchent pas, qui sont de la merde, qui sont totalement inadaptés à ce qu'on veut faire, qui sont trop lent, trop gros, trop stupides, trop inutilisables ou trop limités.

          Et systemd est en train de rempalcer tous les logiciels qui marchent, c'est ça? Tu donnes toi-même les arguments pour systemd et contre l'existant (ou plutôt ce qui existait)…

          Et ils devront changer ça.

          Personne ne met un flingue sur la tête des gens. Par contre, de moins en moins de monde a envie de se faire chier pour toi. Personne ne devra changer d'outil, juste se taper la maintenance (et c'est normal : si tu veux reter aec de la merde quand quelque chose de mieux existe, assume, gère la merde toi-même, les autres sont passé à autre chose et n'en ont plus besoin)

          Je vais pas encore ressortir le fameux XKCD, mais on est typiquement en plein dedans, Systemd n'est qu'un standard supplémentaire pour en unifier d'autres.

          Il faut croire, la vue du déploiement de systemd, que non, systemd va en tuer des système d'init (où ils seront tellement peu utilisé qu'on ne se fera plus chier à ce que tout soit compatible avec les vieux standards), donc non, on n'est pas en plein dedans. Et puis, bon, la, sortir ça pour un logiciel comme ça, va jusqu'au bout et gueule qu'il y a trop de distros Linux, c'est chiant.

          Raté. Un logiciel libre, c'est un logiciel qu'on réutilise.

          Sérieux, tu sais lire ce que sont les 4 libertés?
          Parce qu'un logiciel proprio, pas du tout libre, rentre dans ta définition de logiciel libre.
          Tu as sans doute loupé ce qui est important dans le libre (aide : relire ce à quoi tu répond "non").
          Triste pour le libre de le cantonner à être comme le proprio.
          Pas mal.

          • [^] # Re: GNU/SystemD/Linux

            Posté par . Évalué à 10.

            et les seuls qui ne veulent pas sont ceux qui n'aiment pas le changement et veulent garder le "bohneur" de la maintenance pourrie de ce qui existe avant.

            Euh…. Même si il y a énormément de trolls contre systemd, il y a des raisons parfaitement valides d'être contre. Le fait de ne pas vouloir autant de dépendances dans un système d'init est un point tout à fait valide. L'init c'est la première chose que va faire le système, si ca merde à ce moment là vous ne pouvez rien faire pour corriger le tir. Vouloir le garder aussi maigre que possible n'est pas fondamentalement idiot.

            Ensuite à l'heure actuelle il existe un certains nombres de matériels que l'on ne peut (toujours) pas initialiser proprement avec systemd. Typiquement les matériels multi-étage. Par exemple si vous devez initialiser une architecture crossbar sur laquelle est posée un émulateur réseau matériel (grosse station sun typiquement) systemd ne verra pas les cartes réseaux au moment de l'initialisation du réseau, et quand il les verra enfin pleins de services se seront déjà vautrés parce qu'il aura voulu anticiper l'ouverture des ports sur des cartes qu'il ne connait que plus tard. Idem pour les pinpad, si vous avez besoin de taper un code sur un clavier externe (ie pas le clavier de la machine) pour débloquer votre disque dur, à l'heure actuelle vous ne disposez d'aucun moyen de booter avec systemd à l'heure actuelle.

            Autre problème, systemd n'est pas turing complet et décide tout seul dans quel scope il se lance (essayez d'altérer les cgroups de lancement de systemd pour rire - surtout si c'est pour rajouter des restrictions en plus du taging). Mur assuré. Si vous avez déjà vos politiques cgroups et selinux, vous pouvez prier qu'elles soient compatibles avec systemd, parceque l'alternative est probablement de redéfinir des politiques à partir de 0… Certains logiciels (dont l'excellent HAProxy) ne peuvent tout simplement être lancés par systemd. En cas de reload systemd va interpréter l'arrêt du logiciel comme une panne et va tenter de le relancer avec les paramètres qu'il a en mémoire et dans le scope qu'il juge bon. Moralité vous êtes bon pour écrire des wrappers à la pelle ou à ne plus jamais utiliser de restart (sur un proxy c'est très emmerdant).

            Mais le truc qui m'emmerde le plus personnellement ce sont les templates d'une pourritude rare. Avec sysVinit ou bsdinit il est très facile de faire un script qui va prendre en paramètre une flopée de commandes et/ou de variables et me démarrer un service en fonction de ces variables. Par exemple pour créer un réseau virtuel avec un dhcp sur un segment IP donnée dynamiquement ca me prend une demi ligne de code. Je n'ai pas encore trouvé comment faire ça avec systemd. Il faut créer un service à la volée, l'enregistrer puis l'initialiser , savoir dès le début si on compte le relancer ou pas (sinon il faut faire un script pour le désinscrire au cas ou). ca devient d'une complexité démentielle de créer dynamiquement trois VM et de les mettre en réseau.

            Systemd a des idées géniales et de très bons cotés, mais dans le travail que je fais en ce moment il n'est pas adapté. Et par pas adapté je ne vaux par dire "j'ai pas envie de tout réécrire et d'apprendre systemd" je veux dire "Systemd m'empêche sciemment et volontairement de mettre en place les outils dont j'ai absolument besoin pour travailler".

            Mon point de vue est le suivant : systemd rend la vie de 95% des gens plus facile dans 95% des cas, c'était aussi le cas d'internet explorer 5.0

            • [^] # Re: GNU/SystemD/Linux

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

              Mon point de vue est le suivant : systemd rend la vie de 95% des gens plus facile dans 95% des cas, c'était aussi le cas d'internet explorer 5.0

              Il va y avoir un marché à la Firefox pour quand RedHat et SuSE (les deux seules distros "pro" qui ramènet de la thune) vont passer à systemd alors, pas de soucis, le fric sera la de tous ceux qui souffrent avec systemd et qui sont délaissés par les deux "pro", ça va déchirer en retour sur investissement, il suffira de maintenir des vieux trucs, trop facile. Si tous les reproches ne sont pas juste des détails temporaires (systemd étant encore en développement, c'est normal qu'il manque des trucs, ça ne veut absolument pas dire que le coeur du projet est mauvais).

              PS : personne n'a dit que systemd répond à tous les besoin maintenant. Il va en direction. Et rien ne me dit vraiment que le problème des exemples donnés ne vient pas d'un problème de l'admin qui fait des trucs bizarre ou d'un logiciel bizarre (combien de logiciels à la HAProxy qui en plus va refuser de s'adapter?). On verra quand systemd sera déployé par RedHat…

              • [^] # Re: GNU/SystemD/Linux

                Posté par . Évalué à 7.

                personne n'a dit que systemd répond à tous les besoin maintenant.

                et les seuls qui ne veulent pas sont ceux qui n'aiment pas le changement et veulent garder le "bohneur" de la maintenance pourrie de ce qui existe avant.

                Là, il va falloir choisir un des deux. Soit les personnes qui ne veulent pas de systemd sont des connards passéistes réactionnaires aigris et mal informés, soit il reste encore de vraies bonnes raisons de s'inquiéter de l'impact de systemd sur l'administration de certains systèmes dans certaines situations particulières.
                Tout ce que je demande c'est que la possibilité numéro ne soit pas ridiculisée systématiquement.

                Pour caricaturer, il y a deux possibilités :
                - soit systemd devient turing complet et on va se retrouver dans deux, trois, quatre ans dans le même bordel de maintenance des scripts d'init.
                - soit systemd ne devient pas turing complet et il y aura des admins qui ne pourront plus faire leur système comme ils ont l'habitude et qui devront recréer, tester et migrer vers une nouvelle architecture logicielle (nouvelles logiques d'init, nouvelles policies, potentiellement nouveaux logiciels).

                combien de logiciels à la HAProxy qui en plus va refuser de s'adapter?

                Typiquement un cas à la con pour systemd : mettre HAProxy derrière un wrapper entraine une perte de perfs, sortir HAProxy de son mode "single process, event driven" entraine une perte de perfs, bidouiller avec un pseudo-wrappo-manager à la nginx entrainne une perte de perf.
                Grosso-modo si HAProxy "s'adapte" à systemd, il devient un autre logiciel.

                • [^] # Re: GNU/SystemD/Linux

                  Posté par . Évalué à -4.

                  Laisse tomber : tu parles à quelqu'un qui a des oeuillères et qui n'a jamais eu à gérer des serveurs qui paraissent être des cas "rares" dans leur monde du poste de travail ou du serveur de fichier, mais qui est beaucoup plus courant que l'on ne le croit ailleurs.

                  • [^] # Re: GNU/SystemD/Linux

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

                    tu parles à quelqu'un qui a des oeuillères

                    J'ai bien rit, merci.

                    qui n'a jamais eu à gérer des serveurs qui paraissent être des cas "rares" dans leur monde du poste de travail ou du serveur de fichier,

                    Clair, chez Red Hat qui est à fond dessus, ils n'ont jamais eu à gérer des serveurs bizarres avec des demandes bizarres, ils font trop du "standard" sans beaucoup de machines et de configs à supporter… Red Hat, ce sont des petits joueurs face à Kaane et totof2000 qui sont des dieux des trucs compliqués…
                    J'ai encore bien rit, encore merci.

                    PS : tu attaques perso faute d'arguments vraiment contre et en ayant de très grandes oeillères, je répond perso, c'est nul mais je joue.

                    • [^] # Re: GNU/SystemD/Linux

                      Posté par . Évalué à 1.

                      Clair, chez Red Hat qui est à fond dessus, ils n'ont jamais eu à gérer des serveurs bizarres avec des demandes bizarres,

                      Redhat et Linux, dans la plupart des cas, c'est du PC X86, des VM sous VMWare. Les autres trucs plus costauds, c'est AIX, Solaris, HP-UX et zOS avec son monde particulier.

                      Tu peux rire tant que tu veux, Red!hart dans le monde des serveurs hauts de gamme, c'est rien du tout.

                      Red Hat, ce sont des petits joueurs face à Kaane et totof2000 qui sont des dieux des trucs compliqués…

                      Non, mais RedHat ce sont des petits joueurs face à IBM par exemple. Tu peux rire tant que tu veux et garder tes oeuillères, ça ne changera rien à la réalité.

                      PS : tu attaques perso faute d'arguments vraiment contre et en ayant de très grandes oeillères, je répond perso, c'est nul mais je joue.

                      Les arguments contre t'ont été donnés avec un exemple précis, je n'ai rien à y ajouter. Ce sont des arguments de personnes ayant des problématiques d'admn à régler au quotidien, pas des argments de marketteux comme chez RedHat. Et en général, chez RedHat, ils ne sont pas là pour faire de la gestion au quotidien.

                      Ah tiens, puisque tu me parle du Dieu Redhat : ils ont mis au point un système de déploiement qui s'appelle RedHat Sattellite: ce truc marche très bien pour faire du déploiement d'OS et de la gestion de configuration simple, mais c'est une plaie lorsque tu veux gérer des configurations complexes : ça n'empêche pas RedHat de le vendre pour ça, alors que des outils comme Puppet ou Chef sont beaucoup mieux fichu pour ça. Et je ne suis pas un dieu, je suis juste un utilisateur de ces outils au quotidien.

                      • [^] # Re: GNU/SystemD/Linux

                        Posté par (page perso) . Évalué à 1. Dernière modification le 02/12/13 à 12:45.

                        Redhat et Linux, dans la plupart des cas, c'est du PC X86, des VM sous VMWare.

                        Mouais, donc en gros la cible de Linux, cool on parle de Linux.
                        Finalement ça va bien dans la cible!

                        Les autres trucs plus costauds, c'est AIX, Solaris, HP-UX et zOS avec son monde particulier.

                        Plus costaud?
                        http://www.top500.org/statistics/list/
                        Unix (non Linux donc) : 2.2% (tendance : baissière)…
                        (OK, le top500 est un mode particulier, pas généralisable, mais bon, tu as commencé à parler de "monde particulier"… Et puis, IBM en fait du Linux aussi)

                        • [^] # Re: GNU/SystemD/Linux

                          Posté par . Évalué à 2.

                          Mouais, donc en gros la cible de Linux, cool on parle de Linux.
                          Finalement ça va bien dans la cible!

                          Non, la cible Linux c'est aussi les trucs un peu plus costauds, sans entrer dans le top 500. Ca commençait à bien partir. On commençait à avoir des choses intéressantes. RedHAt Cluster est assez bien fichu, et tourne pas trop mal. Il lui manque quelques fonctionnalités pour remplacer un HACMP ou un HP Serviceguard (a moins que depuis elles soient arrivés). Et je dis du bien de RedHAt Cluster, alors mêe que son fichier de conf est en XML, alors qu'en général je n'aime pas trop ça (l'avantage de ce fichier est qu'il est plutôt bien écrit, par contre il est parfois difficile de s'y retrouver dedans).

                          (OK, le top500 est un mode particulier, pas généralisable, mais bon, tu as commencé à parler de "monde particulier"… Et puis, IBM en fait du Linux aussi)

                          Je me suis mal exprimé sur le monde particulier. Je parle du monde que je cotoie au quotidien, que l'on retrouve dans les banques, les télécoms, l'industrie, etc … : j'aurais du parler d'un monde différent du desktop et des serveurs "bas de gamme", le monde entre ça et le top 500 (note qu'en général, les OS tournant sur ces environnements sont des OS adaptés spécifiquement, que ce soit du Linux, Windows, AIX ou autre).

                          • [^] # Re: GNU/SystemD/Linux

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

                            le monde entre ça et le top 500

                            Donc Linux est adapté au très bas de gamme et aussi au très haut de gamme, mais comme par magie il n'est pas adapté au milieu de gamme, le truc entre les deux.
                            J'avoue reste circonspect devant une telle affirmation.

                            • [^] # Re: GNU/SystemD/Linux

                              Posté par . Évalué à 2.

                              Donc Linux est adapté au très bas de gamme et aussi au très haut de gamme, mais comme par magie il n'est pas adapté au milieu de gamme, le truc entre les deux.

                              Tu parles de quoi ? Du noyau ou de la distribution ? comme je pense que tu parles de la distrib, tu devrais relire ce que j'ai écrit : les serveurs du top500 sont des serveurs qui tournent avec des versions adaptées spécifiquement des distributions d'OS, quel que soit l'OS sous-jacent. Tu n'installes pas une Debian ou une RedHat/centOS standard pour tirer profit du matos.

                              • [^] # Re: GNU/SystemD/Linux

                                Posté par (page perso) . Évalué à -4. Dernière modification le 02/12/13 à 13:30.

                                Dans le noyau aussi ils cassent souvent tout, c'est horrible etc… Aucune différence sur les principes (le monde évolue, le code aussi); systemd n'est juste dans la discussion pour être le souffre-douleur, mais tout Linux (le noyau) bouge de la même manière avec les mêmes impacts même si tu ne le vois pas (par exemple, grsecurity doit toujours s'adapter) et donc ne tape pas dessus.

                                • [^] # Re: GNU/SystemD/Linux

                                  Posté par . Évalué à 3.

                                  Red Hat tourne beaucoup sur les machines Blue Gene. Cependant, c'est une version ultra-light. De plus, si RHEL "light" est utilisé sur l'un des processeurs POWER/PowerPC, ils utilisent aussi très souvent KITTEN (développé dans les labos de Sandia), ou NanOS (développé au Barcelone Supercomputing Center), un « light-weight kernel » qui reprend partiellement l'API POSIX mais avec un modèle de threading et de gestion des ressources très différent en règle générale de ce que Linux offre.

                      • [^] # Re: GNU/SystemD/Linux

                        Posté par . Évalué à 6.

                        Redhat et Linux, dans la plupart des cas, c'est du PC X86, des VM sous VMWare. Les autres trucs plus costauds, c'est AIX, Solaris, HP-UX et zOS avec son monde particulier.

                        Si les trucs "plus costauds" ne sont pas sous Linux, je ne vois pas en quoi ils seront emmerdés par systemd…
                        Pour les trucs "simples" que fait RedHat, faut croire que ça marche!

              • [^] # Re: GNU/SystemD/Linux

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

                combien de logiciels à la HAProxy qui en plus va refuser de s'adapter?

                Haproxy s'est adapté puisqu'un wrapper à été commité. On peut le lancer avec l'option -Ds qui permet de lancer un wrapper qui ne fait rien d'autre qu'un wait() afin de donner à systemd un PID stable a monitorer.

                http://git.1wt.eu/web?p=haproxy.git&a=search&h=HEAD&st=commit&s=systemd

              • [^] # Re: GNU/SystemD/Linux

                Posté par . Évalué à 0.

                Systemd sur un poste de bureau, je n'ai rien contre, bien au contraire. Systemd, c'est sur les serveurs que je n'en veux pas, parce que les problématiques serveurs et poste de bureau ne sont absolument pas les mêmes. Et le genre de problème qui a été reonté par la personne à qui tu réponds, c'est ce que l'on rencontre couramment dans le monde des "gros" serveurs. Maintenant ce que je vois, c'est qu'à cause de ce genre de conneries, c'est une tentative de percer sur le bureau. ca ne marchera pas. Et surtout, Linux perdra le marché des serveurs au profit des OS proprios tels qu'AIX ou Solaris, voire Windows.

                • [^] # Re: GNU/SystemD/Linux

                  Posté par . Évalué à 7.

                  Et surtout, Linux perdra le marché des serveurs au profit des OS proprios tels qu'AIX ou Solaris, voire Windows.

                  T'es au courant que Solaris a un équivalent de systemd (SMF) depuis des années ?

                  • [^] # Re: GNU/SystemD/Linux

                    Posté par . Évalué à -1.

                    Je suis parfaitement au courant, c'est l'une des raisons pour lesquelles je ne fais plus de Solaris. Mais vu que Solaris est prévu pour tourner sur du matos spécifique, il est fort probable que les problématiques de desktop auxquelles tente de répondre SystemD n'ont pas été prises en compte. Sinon, il me semble que le système de démarrage de Solaris et de SystemD ne sont pas si proches que ça : le système de démarrage de Solaris - me semble-t-il - ne s'accapare pas la gestion des logs et tous les autres trucs que fait systemd. Il faudrait que je vérifie ça.

                  • [^] # Re: GNU/SystemD/Linux

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

                    T'es au courant que Solaris a un équivalent de systemd (SMF) depuis des années ?

                    Non SMF sert uniquement à gérer les services. init continue d'exister. Il lance et supervise svc.configd et svc.startd. Il peut également lancer des processus définies dans /etc/inittab bien que cette façon de faire soit dépréciée.

                    Les logs continent d'être gérés par syslogd et les tty par ttymon (qui existe depuis solaris 2 je crois) comme précédemment.

                • [^] # Re: GNU/SystemD/Linux

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

                  Et surtout, Linux perdra le marché des serveurs au profit des OS proprios tels qu'AIX ou Solaris, voire Windows.

                  Ou alors, il en gagnera car systemd, entre autres choix techniques, a des atouts, y compris sur les serveurs.

                  • [^] # Re: GNU/SystemD/Linux

                    Posté par . Évalué à -3.

                    Eh ben dis donc, mon Zenitram, tu progresses pas beaucoup en argumentation…

            • [^] # Re: GNU/SystemD/Linux

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

              Si vous avez déjà vos politiques cgroups et selinux, vous
              pouvez prier qu'elles soient compatibles avec systemd,
              parce que l'alternative est probablement de redéfinir des
              politiques à partir de 0…

              Tu bullshites ( comme d'hab sur certains sujets, donc je vais pas passer du temps à te répondre ). Sur une distro RHEL 6, pour avoir un programme lancé par init, tu va utiliser ça par exemple:

              init_daemon_domain(ahcpd_t, ahcpd_exec_t)
              

              Sur une fedora 20, avec systemd, tu va utiliser:

              init_daemon_domain(ahcpd_t, ahcpd_exec_t)
              

              La réécriture est en effet si douloureuse qu'on pourrais croire qu'il y a rien à faire à part recompiler la policy. Mais peut être que tu veux dire qu'il faut rajouter des autorisations quand on rajoute des fonctions ( car peut être que "compatible avec systemd", tu veux dire "compatible avec l'activation par socket" ce qui est totalement différent, et qui reviens à dire "selinux requiert de tout refaire de 0 si jamais on rajoute une feature sur un soft", ce qui est n'importe quoi ).

              Certains logiciels (dont l'excellent HAProxy) ne peuvent tout
              simplement être lancés par systemd

              [root@liliana misc]# systemctl status  haproxy
              haproxy.service - HAProxy For TCP And HTTP Based Applications
                 Loaded: loaded (/usr/lib/systemd/system/haproxy.service; disabled)
                 Active: active (running) since dim. 2013-12-01 23:10:03 CET; 988ms ago
                 Process: 9018 ExecStart=/usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid (code=exited, status=0/SUCCESS)
                Process: 9015 ExecStartPre=/usr/sbin/haproxy -c -q -f /etc/haproxy/haproxy.cfg (code=exited, status=0/SUCCESS)
              Main PID: 9019 (haproxy)
                 CGroup: /system.slice/haproxy.service
                         └─9019 /usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid
              déc. 01 23:10:03 liliana.example.com systemd[1]: Started HAProxy For TCP And HTTP Based Applications.
              

              Oups, tu peut remplir un bug pour Fedora, car visiblement, la fedora 20 que j'ai a l'air de réussir à le lancer, et visiblement, ç'est un bug que ça marche.

              Ensuite peut être que tu veux dire "haproxy n'utilise pas le démarrage par socket ou à la demande", ce qui est différent de "ne marche pas avec systemd". Mais bon, comme tout le reste de ta prose est assez souvent de la même acabit, je vais laisser quelqu'un d'autre te répondre ( ou ne pas passer de temps dessus, car ça ne vaut pas le temps passé à l'exercice ).

              • [^] # Re: GNU/SystemD/Linux

                Posté par . Évalué à 3.

                Tu bullshites ( comme d'hab sur certains sujets, donc je vais pas passer du temps à te répondre ). … Mais peut être que tu veux dire qu'il faut rajouter des autorisations quand on rajoute des fonctions

                Non, je parle des cgroups et de selinux.. Par exemple pour les cgroups : si tu veux que deux services partagent le même cgroup, ou si tu veux que ton cgroup de tagging serve aussi à créer des limites, ou si tu veux avoir plusieurs cgroups sur un service ou des dizaines d'autres choses. En fait quand les cgroups ont été créés, certaines personnes ont eu l'idée (idiote je le reconnais aujourd'hui, mais à l'époque c'était difficile à voir) que ça pouvait servir à autre chose qu'à permettre à un système d'init qui serait écrit plusieurs années plus tard. Un des trucs fantatisque (pour un admin) était les hiérarchies, créer un cgroup "database" qui a la priorité partout, et un cgroup "frontend" qui n'a le droit d'utiliser qu'un seul CPU, à peine un peu de bande passante et de mémoire. Bref les trucs fondamentaux vont dans le cgroup "database" et les autres trucs vont dans le cgroup "frontend" - donc même si un crétin avec les droits roots lance une commande bouffeuse de ressources, la base de données aura toujours quoi qu'il arrive 80% des ressources réservées pour elle. C'est cool c'est génial c'est beau.

                SAUF QUE - systemd va venir se servir du tagging des cgroups pour faire sa sauce, et la c'est le drame. Par exemple si j'ai l'habitude de faire des triplets apache/mysql/php en fastCGI et de les mettre dans le même cgroup pour limiter (par exemple) la consommation CPU dudit cgroups. Typique je lance 10 triplets AMP dans 10 cgroups AMP0, AMP1 … AMP9 qui déscendent tous de AMP_MASTER qui limite la consomation CPU à 25% MAX. Je vais pas rentrer dans les détails, mais pour faire un truc pareil avec systemd tu vas morfler. Une fois dans un cgroup un process ne peux pas en sortir, une fois un cgroup activé aucun process ne peut rentrer dedans. Et tu ne peux même plus utiliser le tagging pour suivre le lancement de tes process parce que systemd utilise le sien propre (et qu'un sous système ne peut se trouver à deux endroits d'une même hiérarchie bien sur).

                Voilà typiquement un exemple d'utilisation de cgroups que systemd empêche de faire fonctionner. Et typiquement pour t'en sortir il faut repenser tes policies.

                Oups, tu peut remplir un bug pour Fedora, car visiblement, la fedora 20 que j'ai a l'air de réussir à le lancer, et visiblement, ç'est un bug que ça marche.

                Dans mon post j'explique clairement ce que je veux dire :

                En cas de reload systemd va interpréter l'arrêt du logiciel comme une panne et va tenter de le relancer avec les paramètres qu'il a en mémoire et dans le scope qu'il juge bon. Moralité vous êtes bon pour écrire des wrappers à la pelle ou à ne plus jamais utiliser de restart (sur un proxy c'est très emmerdant).

                Fedora a écrit un wrapper qui a son tour lance HAProxy - sinon c'est la guerre au moment des reloads.

                • [^] # Re: GNU/SystemD/Linux

                  Posté par . Évalué à -10.

                  La premiere question qui me vient a l'esprit c'est "tu fais vraiment tourner mysql et apache sur la meme box?"

                  T'es serieux ou tu trolles juste?

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

                • [^] # Re: GNU/SystemD/Linux

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

                  Non, je parle des cgroups et de selinux

                  Non, la tu parles de cgroups tout court, à aucun moment tu ne parles de selinux dans ta réponse. Quand aux histoires de hiérarchies des cgroups, c'est une chose que le dev des cgroups veut revoir pour justement éviter l'explosion de complexité, cf par exemple le dernier linuxmag ou il est interviewé. Systemd utilise le concept de slices pour faire une abstraction sur tout ça.

                  Fedora a écrit un wrapper qui a son tour lance HAProxy - sinon
                  c'est la guerre au moment des reloads.

                  Je vais coller le fichier unit qu'on voit le fameux wrapper :

                  $ cat /usr/lib/systemd/system/haproxy.service
                  [Unit]
                  Description=HAProxy For TCP And HTTP Based Applications
                  After=syslog.target network.target
                  
                  [Service]
                  Type=forking
                  PIDFile=/run/haproxy.pid
                  ExecStartPre=/usr/sbin/haproxy -c -q -f /etc/haproxy/haproxy.cfg
                  ExecStart=/usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid
                  ExecReload=/bin/bash -c "exec /usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -sf $MAINPID"
                  
                  [Install]
                  WantedBy=multi-user.target
                  

                  Il n'y a pas de wrapper pour lancer haproxy, ça lance direct le binaire :

                  $ file /usr/sbin/haproxy
                  /usr/sbin/haproxy: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=337e0cbbbab915958b6be49b946ae1dc38ac4947, stripped
                  

                  Je ne sais pas quel distribution tu utilises pour faire du systemd avec un wrapper haproxy, mais ça doit pas être Fedora à vue de nez. Y a pas de mention du wrapper dans le changelog du paquet, pas de patch.

                  • [^] # Re: GNU/SystemD/Linux

                    Posté par . Évalué à 2.

                    Non, la tu parles de cgroups tout court, à aucun moment tu ne parles de selinux dans ta réponse.

                    Ca s'appelle donner un exemple. Ce qui est indiqué en plus par Par exemple pour les cgroups :
                    Pour se-linux les exemples seraient beaucoup plus longs et compliqués à expliquer (non pas fondamentalement, mais parcequ'il faudrait que je raconte ma vie sinon il y a encore des gens "qui savent mieux" qui viendraient m'expliquer comment faire autrement sans se-linux)
                    Maintenant grosso-modo l'idée générale est que si tu veux protéger ton service contre un restart intempestif même par un user même root (dans le mauvais domaine), ben systemd va péter un câble. Charge à toi donc de concilier les droits et les différents domaines d'une façon qui a) ne casse pas ta sécurité et b) ne casse pas systemd/ta distrib.

                    C'est lourd.

                    Il n'y a pas de wrapper pour lancer haproxy, ça lance direct le binaire :

                    Relis la ligne reload…
                    ExecReload=/bin/bash -c

                    • [^] # Re: GNU/SystemD/Linux

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

                      Donc récapitulons, l'incompatibilité entre haproxy et systemd, c'est le fait de devoir rajouter 1 ligne de bash dans l'unité systemd, chose qui a bien du prendre 5 minutes, vu que la ligne vient du script d'init haproxy avec une rapide adaptation pour l'accès à $MAINPID. Si une ligne de bash est un souci, j'ose me demander ce que les 108 autres lignes du script d'init sont…

                      J'imagine dire que "attention, des logiciels comme haproxy et plein d'autres que je ne cite pas peuvent requérir un oneliner bash pour fonctionner", ça casse vachement moins la baraque.

                      • [^] # Re: GNU/SystemD/Linux

                        Posté par . Évalué à 0.

                        J'imagine dire que "attention, des logiciels comme haproxy et plein d'autres que je ne cite pas peuvent requérir un oneliner bash pour fonctionner", ça casse vachement moins la baraque.

                        Bof tu sais dire "Attention, sur un logiciel comme HAProxy, quand on le lance avec systemd, même en mode fork (ce qui est déjà pas top) on est quand même obligé de faire un wrapper pour le reload", ca me gêne moins que de voir mes arguments réduit à peau de chagrin par les propres infos que j'ai donnée et que je n'ai pas su lire.

          • [^] # Re: GNU/SystemD/Linux

            Posté par . Évalué à 4.

            Wow… C'est vraiment nier la réalité, la transformer pour être en accord avec ses fantasmes.

            C'est plutôt toi qui lis des choses que je ne dis pas.

            Je n'ai jamais dis que la majorité voulais virer systemd, j'ai dis qu'ils y a des gens qui cherchent à le virer.

            Personnellement, je connais aucun système de boot assez générique, généraliste, simple et facile pour contenter tout le monde. Et je crois que ça n'existera jamais. Toute tentative d'unifier ça va forcement se terminer par un standard supplémentaire.

            Quasi-tout le monde (on parle de ce qui doiven tse taper la maintenance hein, pas les trolleur qui foutent rien) veut mettre systemd sur Linux, et les seuls qui ne veulent pas sont ceux qui n'aiment pas le changement et veulent garder le "bohneur" de la maintenance pourrie de ce qui existe avant.

            Si le système de boot est maintenu par la distribution, le boot de chaque système est maintenu par l'administrateur. Si l'administrateur peux pas gérer et agencer son boot comme il veut parce que le système de boot est trop borné ou trop imprévisible, c'est lui qui devra trouver une autre solution, pas le mainteneur de la distribution.

            Si tout le monde ou presque regarde systemd, c'est peut-être parce qu'il répond au besoin?

            Il répondra pas à tout les besoins. Surtout sur les systèmes ou lancer udev invoque l'OutOfMemory Killer du noyau dans les secondes qui suivent.

            Personne ne met un flingue sur la tête des gens.

            Ben non, personne n'est obligé de réparer son système pour qu'il marche. C'est tellement plus marrant d'acheter du matériel et d'installer des systèmes dont tu ne peux pas te servir pour ce que tu veut en faire.

            Personne ne te met un flingue sur la tête pour que tu livre des choses qui marchent à un client, pourtant tu le fait quand même, non ? (enfin j'espère)

            Personne ne devra changer d'outil,

            Tu prend le problème à l'envers. Ceux qui découvriront que systemd ne correspond pas à leur besoin devront changer d'outil. Faudrait quand même avoir un système qui marche à la fin, même s'il faut le maintenir soit-même. Parfois c'est la meilleure solution. Et parfois c'est la seule.

            Il faut croire, la vue du déploiement de systemd, que non, systemd va en tuer des système d'init (où ils seront tellement peu utilisé qu'on ne se fera plus chier à ce que tout soit compatible avec les vieux standards), donc non, on n'est pas en plein dedans.

            Avant, si je devais faire un démon à peu près portable, il suffisait généralement que je file un script rc.d pour les Linux et Unix-like, et peut-être de quoi avoir un service Windows et/ou un job launchd pour MacOSX.

            Maintenant, je doit faire tout ça, et aussi un unit systemd pour les distros qui utilise ce truc. Le script d'init ne va pas disparaître, vu que BSD est pas près de passer à systemd.

            Un standard de plus.

            Et puis, bon, la, sortir ça pour un logiciel comme ça, va jusqu'au bout et gueule qu'il y a trop de distros Linux, c'est chiant.

            Pourquoi ? Si toutes ces distributions respectent un standard de fait que je peux utiliser (au hasard, POSIX, FHS, ou l'API du noyau Linux), j'ai aucun problème avec ça. La seule chose chiante c'est les bugs que chaque distribution se prend. Mais heureusement qu'il y en a plusieurs. Si il y en avais qu'une seule, j'aurai aucun moyen d'échapper à ses bugs.

            Sérieux, tu sais lire ce que sont les 4 libertés?

            Je vois pas le rapport avec la choucroute. Note les trois premiers mots de ma réponse. "Dans la pratique".

          • [^] # Re: GNU/SystemD/Linux

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

            Si tout le monde ou presque regarde systemd, c'est peut-être parce qu'il répond au besoin?

            Ca inclu Gentoo, Slackware, et leurs forks respectifs ?

            Tant qu'on est à débattre/troller sur les fonctionnalités de systemd, ca marche comment pour les logs ? C'est toujours stocké en binaire, et pouvant être exporté en xml ? (vraie question, j'ai une distro qui utilise openrc).

            Opera le fait depuis 10 ans.

            • [^] # Re: GNU/SystemD/Linux

              Posté par . Évalué à 7.

              Non, c'est toujours stocké en binaire avec une bête option pour avoir du texte brut comme avant en plus, et au même endroit qu'avant (sur ma Debian au moins).

              Bref, si tu n'utilises pas journalctl, tu ne verras pas la différence.

              • [^] # Re: GNU/SystemD/Linux

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

                Hum, à quoi sont censés servir les logs binaires en fait ?

                Opera le fait depuis 10 ans.

                • [^] # Re: GNU/SystemD/Linux

                  Posté par . Évalué à 2.

                  Tout est expliqué ici

                  Pour résumer :

                  Simplicity: little code with few dependencies and minimal waste through abstraction.

                  Zero Maintenance: logging is crucial functionality to debug and monitor systems, as such it should not be a problem source of its own, and work as well as it can even in dire circumstances. For example, that means the system needs to react gracefully to problems such as limited disk space or /var not being available, and avoid triggering disk space problems on its own (e.g. by implementing journal file rotation right in the daemon at the time a journal file is extended).

                  Robustness: data files generated by the journal should be directly accessible to administrators and be useful when copied to different hosts with tools like “scp” or “rsync”. Incomplete copies should be processed gracefully. Journal file browsing clients should work without the journal daemon being around.

                  Portable: journal files should be usable across the full range of Linux systems, regardless which CPU or endianess is used. Journal files generated on an embedded ARM system should be viewable on an x86 desktop, as if it had been generated locally.

                  Performance: journal operations for appending and browsing should be fast in terms of complexity. O(log n) or better is highly advisable, in order to provide for organization-wide log monitoring with good performance

                  Integration: the journal should be closely integrated with the rest of the system, so that logging is so basic for a service, that it would need to opt-out of it in order to avoid it. Logging is a core responsibility for a service manager, and it should be integrated with it reflecting that.

                  Minimal Footprint: journal data files should be small in disk size, especially in the light that the amount of data generated might be substantially bigger than on classic syslog.

                  General Purpose Event Storage: the journal should be useful to store any kind of journal entry, regardless of its format, its meta data or size.

                  Unification: the numerous different logging technologies should be unified so that all loggable events end up in the same data store, so that global context of the journal entries is stored and available later. e.g. a firmware entry is often followed by a kernel entry, and ultimately a userspace entry. It is key that the relation between the three is not lost when stored on disk.

                  Base for Higher Level Tools: the journal should provide a generally useful API which can be used by health monitors, recovery tools, crash report generators and other higher level tools to access the logged journal data.

                  Scalability: the same way as Linux scales from embedded machines to super computers and clusters, the journal should scale, too. Logging is key when developing embedded devices, and also essential at the other end of the spectrum, for maintaining clusters. The journal needs to focus on generalizing the common use patterns while catering for the specific differences, and staying minimal in footprint.

                  Universality: as a basic building block of the OS the journal should be universal enough and extensible to cater for application-specific needs. The format needs to be extensible, and APIs need to be available.

                  Clustering & Network: Today computers seldom work in isolation. It is crucial that logging caters for that and journal files and utilities are from the ground on developed to support big multi-host installations.

                  Security: Journal files should be authenticated to make undetected manipulation impossible.

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

                  • [^] # Re: GNU/SystemD/Linux

                    Posté par . Évalué à 6.

                    Simplicity: little code with few dependencies and minimal waste through abstraction.

                    Le texte ne demande pas plus de code, de dépendances ou d’abstractions que le binaire.

                    Zero Maintenance: logging is crucial functionality to debug and monitor systems, as such it should not be a problem source of its own, and work as well as it can even in dire circumstances. For example, that means the system needs to react gracefully to problems such as limited disk space or /var not being available, and avoid triggering disk space problems on its own (e.g. by implementing journal file rotation right in the daemon at the time a journal file is extended).

                    Le texte le fait, en mieux (en binaire tu dois gérer le cas où ta donnée structurée est coupée en plein milieu, est parasitée par un secteur défectueux sur le disque… Bonne chance si ton outil te fait un segfault parce que le champ « taille de l’enregistement » a été corrompu)

                    Robustness: data files generated by the journal should be directly accessible to administrators and be useful when copied to different hosts with tools like “scp” or “rsync”. Incomplete copies should be processed gracefully. Journal file browsing clients should work without the journal daemon being around.

                    Le texte le fait, en mieux (je peux lire mail.log généré sous mon serveur Linux sous MacOS X, Windows ou FreeBSD ou une vieille distribution/LiveCD qui n’a pas journalctl, ce n’est pas le cas avec journald). Problème très concret rencontré récemment : le mode rescue d’OVH n’avait pas journalctl, si je n’avais pas les bons vieux logs texte à côté j’étais bien avancé pour analyser le problème…

                    Performance: journal operations for appending and browsing should be fast in terms of complexity. O(log n) or better is highly advisable, in order to provide for organization-wide log monitoring with good performance

                    Tu peux difficilement faire plus rapide qu’ajouter une ligne dans un fichier texte

                    Minimal Footprint: journal data files should be small in disk size, especially in the light that the amount of data generated might be substantially bigger than on classic syslog.

                    D’accord sur l’avantage du binaire sur ce point.

                    Pas d’accord sur le fait que ce soit une raison suffisante.

                    Le reste des points abordés est indépendant du format de stockage. C’est une très belle argumentation pour expliquer les avantages de journald (et encore, mais je n’ai pas envie de troller sur la logique bizarre de ce document qui dit en gros « si l’on suppose que journald est universel, alors journald est meilleur que syslog parce que l’universalité est une propriété désirable pour un système de log »…), pas de l’utilisation d’un format binaire.

                    • [^] # Re: GNU/SystemD/Linux

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

                      Tu peux difficilement faire plus rapide qu’ajouter une ligne dans un fichier texte

                      Merci, j'ai bien rit.
                      c'est vrai que formater un timestamp (généralement un entier 8 octets) en une date "humaine" de 40 caractères, puis écrire 5x plus de données sur le disque que nécessaire, pareil pour les autres champs, c'est ce qu'il y a de plus performant et difficile de faire plus rapide…
                      Tu as aussi oublié la partie "browsing", où la c'est le sport pour détecter le format (les langues etc… au bohneur la chance), convertir en timestamp pour enfin pouvoir comparer, c'est aussi difficile à faire plus rapide.

                      Tu plaisantes la, rassure-moi.

                      Minimal Footprint: journal data files should be small in disk size, especially in the light that the amount of data generated might be substantially bigger than on classic syslog.

                      D’accord sur l’avantage du binaire sur ce point.
                      Pas d’accord sur le fait que ce soit une raison suffisante.

                      Avec toutes les autres (dont le bordel du texte pour un non humain), ça le fait.
                      Et peut-être pour toi tu as rien à faire de perdre de la place, mais qui sait d'autres (qui payent car ont vraiment besoin) ont peut-être ce besoin… Qui ne t'enlève rien (Tu peux continuer à garder le texte si ça te chante).

                      Problème très concret rencontré récemment : le mode rescue d’OVH n’avait pas journalctl, si je n’avais pas les bons vieux logs texte à côté j’étais bien avancé pour analyser le problème…

                      Avec ce genre d'argument, on arrête toute évolution, on gèle tout. Non merci, je te laisse ce monde figé, d'autres souhaitent avancer.

                      • [^] # Re: GNU/SystemD/Linux

                        Posté par . Évalué à 5.

                        Avec ce genre d'argument, on arrête toute évolution, on gèle tout. Non merci, je te laisse ce monde figé, d'autres souhaitent avancer.

                        Tu devrais prendre des cours :

                        1. De politesse
                        2. De français

                        L’argument « on VEUT que des logs soient lisible de partout en toute circonstance », c’est un argument sortit par l’auteur de ce document hein, mais je suppose que lui aussi est un méchant réactionnaire rétrograde qui refuse tout changement.

                        Le problème de ce document c’est qu’il présuppose l’universalité de journald et qu’il se permet de déduire « donc c’est lisible partout en toute circonstance ». Le problème évident étant que journald n’est pas universel à l’heure actuelle (j’ai donné un exemple concret) et ne le sera probablement jamais (Windows, autres Unix qui refuseront d’intégrer du LGPL). Alors que le texte plat, c’est déjà universel (et encore même pas, il y a encore des systèmes en ECBDIC dans la nature, mais ça s’approche déjà infiniment plus de « universel » que journald)

                        J’ai rien contre le fait d’avancer, j’adhère à 90% aux positions de principe de ce document, mais quand je lis « les logs doivent être lisibles en toute circonstance et de partout », permet moi de pointer l’incohérence du choix d’un format binaire avec ce principe…

                        • [^] # Re: GNU/SystemD/Linux

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

                          Alors que le texte plat, c’est déjà universel

                          Tu as déjà essayé de lire une date en arabe?
                          A partir du moment où tu ne lis même pas ce qui est écrit et fait comme si ça n'avait pas été écrit… Tu risque de convaincre que toi-même avec de tels arguments.

                          De politesse

                          La première des politesses est de ne pas ignorer ce que les gens écrive, la deuxième est de ne pas les prendre pour des cons.

                          • [^] # Re: GNU/SystemD/Linux

                            Posté par . Évalué à 7.

                            Tu as déjà essayé de lire une date en arabe?

                            Et qui ici a dit que tu devais impérativement stocker les dates dans le format de la locale ? Qui ici a refusé tout principe d’uniformisation, standardisation et rationalisation des logs ? Personne. Mais comme c’est ce que tu veux entendre (parce que ça conforte tes préjugés « tous des réactionnaires réfractaires au changement »), ben c’est ce que tu lis.

                            J’arrête les frais avec toi, je savais que j’aurais même pas dû essayer d’argumenter. Honnêtement, il y a quelque mois encore ton côté « avocat du diable » était intéressant parce que pertinent, et argumenté et honnête, mais depuis quelques temps tu ne fais que sombrer dans l’invective (et je dis pas ça parce que je ne suis pas d’accord avec toi sur ce point, c’est quelque chose que j’ai remarqué bien avant, et même sur des sujets sur lesquels je suis 100% d’accord avec toi, comme par exemple le travail le dimanche, sujet sur lequel tu as été absolument odieux avec tes contradicteurs).

                            Oui, c’est de l’ad hominem, tu peux en faire de même en réponse si ça te défoule, mais il fallait que ça sorte.

                        • [^] # Re: GNU/SystemD/Linux

                          Posté par . Évalué à 9.

                          Moi ce que je ne comprends pas, c'est que journald permet d'avoir les logs à la fois en binaire et en texte exactement comme avant.

                          Alors pourquoi est-ce tellement un problème d'avoir les 2? Les regex, la lecture par un humain, tout ça reste possible, très exactement comme avant même, vu que journald peut aller remettre les logs au bon endroit dans /var/log.

                          Et quand bien même le format serait binaire, on n'a pas besoin de tout systemd pour lire un journal sur BSD. Si le besoin s'en fait sentir, libre à tous de faire un lecteur de journal au format journald (c'est pas comme si tous les formats pour tout étaient déjà standardisés et universels…).

                      • [^] # Re: GNU/SystemD/Linux

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

                        Et peut-être pour toi tu as rien à faire de perdre de la place, mais qui sait d'autres (qui payent car ont vraiment besoin) ont peut-être ce besoin

                        Mon dossier de log sur mon serveur fait 160Ko. Peux tu me donner un cas où 160Ko est un espace de stockage non négligeable ?

                        c'est le sport pour détecter le format (les langues etc… au bohneur la chance)

                        Pour la langue : par défaut en anglais. Je ne savais même pas qu'on pouvait avoir des logs localisés pour Apache, OpenSSH, Postfix, et cie, j'ai toujours cru que par convention on ne faisait que des logs en anglais.

                        (dont le bordel du texte pour un non humain),

                        Les outils Unix sont conçus spécifiquement pour traiter du texte ; ca reste le format universel pour Unix. Sinon, il y a un truc qui a 40 ans environ qui s'appelle "expressions régulières", très efficace pour parser du texte en O(n) quand c'est bien fait. Le gros intérêt est que ca existe ailleurs que sous Linux.

                        je te laisse ce monde figé, d'autres souhaitent avancer.

                        C'est très bien d'avancer, mais vaut mieux que ce soit en avant et non dans un mur. Je peux te citer des exemples de gens qui ont voulu faire et avancer, mais trop hâtivement, et se retrouver avec une magnifique différence entre leur propre doc et leur implémentation réelle.

                        Opera le fait depuis 10 ans.

                        • [^] # Re: GNU/SystemD/Linux

                          Posté par . Évalué à 2. Dernière modification le 03/12/13 à 21:22.

                          Les outils Unix sont conçus spécifiquement pour traiter du texte ; ca reste le format universel pour Unix. Sinon, il y a un truc qui a 40 ans environ qui s'appelle "expressions régulières", très efficace pour parser du texte en O(n) quand c'est bien fait. Le gros intérêt est que ca existe ailleurs que sous Linux.

                          Et c'est très fragile. Ta regex devient inutile dès que le format des messages changent.
                          Peut-être que tu peux écrire des regex très intelligentes. Mais dès que le format des messages va changer, t'auras 50% de chances pour que ta regex ne fonctionne plus.

                          Perso, je préfère avoir affaire à une API stable ou une base de données qu'à du texte. Pis, du texte en langue humaine, le genre de langages très peu standardisé (où personne n'arrive à se mettre d'accord sur une chose aussi bête que le format des dates !).

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

                          • [^] # Re: GNU/SystemD/Linux

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

                            Je suis tout à fait d'accord avec toi sur la stabilité de la chose. Mais n'importe quel format possible répond à tes critères, du moment que les logs sont générés par journald.

                            Opera le fait depuis 10 ans.

                          • [^] # Re: GNU/SystemD/Linux

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

                            Et c'est très fragile. Ta regex devient inutile dès que le format des messages changent.
                            Peut-être que tu peux écrire des regex très intelligentes. Mais dès que le format des messages va changer, t'auras 50% de chances pour que ta regex ne fonctionne plus.

                            Et qu’est-ce que systemd-journald va changer à cela au juste ?

                            Systemd-journald n’impose absolument rien quand au format des messages. Un programme souhaitant enregistrer une entrée dans le journal peut envoyer un message structuré basé sur des champs bien définis, mais le même programme peut aussi utiliser des champs qu’il définit lui-même et surtout il peut parfaitement se contenter de n’envoyer que de banales chaînes de caractères dans lequel il formatte les informations à sa guise. journald n’impose même pas la locale ou l’encodage des chaînes de caractères en question (UTF-8 est recommandé mais la documentation dit clairement que rien n’est fait pour l’imposer).

                            Perso, je préfère avoir affaire à une API stable ou une base de données qu'à du texte.

                            Tu auras une API stable pour accéder aux messages, mais pas pour exploiter leur contenu. Si un programme change le format de ses messages (que ceux-ci soit structurés ou non), tu devras toujours t’y adapter. systemd-journald ne résoudra pas automagiquement ce problème qui est totalement hors de sa portée, c’est entièrement dépendant des développeurs des programmes qui écriront dans le journal. Comme avec syslog en fait.

                            • [^] # Re: GNU/SystemD/Linux

                              Posté par . Évalué à 4.

                              Et qu’est-ce que systemd-journald va changer à cela au juste ?
                              Systemd-journald n’impose absolument rien quand au format des messages. Un programme souhaitant enregistrer une entrée dans le journal peut envoyer un message structuré basé sur des champs bien définis, mais le même programme peut aussi utiliser des champs qu’il définit lui-même et surtout il peut parfaitement se contenter de n’envoyer que de banales chaînes de caractères dans lequel il formatte les informations à sa guise. journald n’impose même pas la locale ou l’encodage des chaînes de caractères en question (UTF-8 est recommandé mais la documentation dit clairement que rien n’est fait pour l’imposer).

                              Ca change que le programme peut logguer des données de facon structurée. Avec syslog il ne le peut pas. Et meme si le programme ne le fait pas, journald log de base certaines infos de facon structurée, comme le PID et l'UID du process, l'ID de boot, l'unit systemd, les infos SELinux, etc …

                              Tu auras une API stable pour accéder aux messages, mais pas pour exploiter leur contenu. Si un programme change le format de ses messages (que ceux-ci soit structurés ou non), tu devras toujours t’y adapter. systemd-journald ne résoudra pas automagiquement ce problème qui est totalement hors de sa portée, c’est entièrement dépendant des développeurs des programmes qui écriront dans le journal. Comme avec syslog en fait.

                              Si les données sont logguées de facon structurée, il est relativement simple de ne pas casser la compatibilité, l'ajout d'un nouveau champ ne va pas poser de problèmes. Si tu loggues tes données en vrac sur une ligne de texte, l'ajout d'un nouveau champ peut facilement casser tes regexps.

                              • [^] # Re: GNU/SystemD/Linux

                                Posté par (page perso) . Évalué à 4. Dernière modification le 05/12/13 à 23:56.

                                Ca change que le programme peut logguer des données de facon structurée.

                                Et combien vont le faire ? Sachant que seul systemd-journald offre cette possibilité et qu’il n’est pas seul en jeu. Tu crois que les développeurs de démons vont laisser tomber syslog(3), largement disponible, et se mettre à utiliser l’API propre à systemd-journald ? Moi je n’y crois pas. Oh, certains le feront, certainement, mais je doute fort qu’ils soient nombreux.¹

                                D’ailleurs, d’après Lennart Poettering, la meilleure façon de logger, pour les démons « new style » (c’est comme ça qu’il appelle les démons conçus dès le départ pour profiter de systemd), c’est d’utiliser… le bon vieux printf(3), systemd se chargeant d’envoyer la sortie standard du démon vers journald.

                                Et meme si le programme ne le fait pas, journald log de base certaines infos de facon structurée, comme le PID et l'UID du process, l'ID de boot, l'unit systemd, les infos SELinux, etc

                                Sauf que typiquement ce ne sont pas ces informations que l’on veut aller grepper dans les logs, mais bien les informations propres au programme, celles contenues dans le message qu’il a envoyé.

                                Pour illustrer mon propos, mettons que je veuille récupérer les adresses des petits malins qui tentent de bruteforcer mon serveur SSH. Actuellement, avec des journaux au format texte gérés par syslog, je ferais quelque chose du genre :

                                $ grep sshd /var/log/messages | sed -nre 's/^.*\[(.+)\] failed - POSSIBLE BREAK-IN ATTEMPT!/\1/p'
                                

                                avec une belle regex fragile qui peut ne plus marcher à la prochaine mise à jour de sshd si les développeurs de celui-ci ont jugé bon de changer le format de ce message.

                                Avec des journaux au format binaire gérés par systemd-journald, je ferais (attention, révolution) :

                                $ journalctl _SYSTEMD_UNIT=sshd.service | sed -nre 's/^.*\[(.+)\] failed - POSSIBLE BREAK-IN ATTEMPT!/\1/p'
                                

                                … avec une belle regex fragile qui peut ne plus marcher à la prochaine mise à jour de sshd si les développeurs de celui-ci ont jugé bon de changer le format de ce message. Zut alors, ni systemd-journald ni le fait de stocker les journaux au format binaire n’ont empêché ça.

                                Le seul bénéfice visible de journald, ici, c’est de faire l’économie de la première regex, celle qui sert à filtrer les messages issus de sshd — c’est-à-dire, la plus simple et surtout celle qui n’est pas vraiment susceptible de changer.

                                il est relativement simple de ne pas casser la compatibilité, l'ajout d'un nouveau champ ne va pas poser de problèmes.

                                Je considérerai cet avantage lorsque je verrai les développeurs de sshd opter pour l’API de journald en lieu et place de syslog(3). En attendant, c’est purement théorique.


                                ¹ Quand je vois le nombre de programmes qui enregistrent encore leurs données directement à la racine de $HOME au lieu d’utiliser les répertoires proposés par la « XDG Base Directory Specification »… il ne suffit pas de proposer quelque chose de pratique pour que ce soit utilisé.

                                • [^] # Re: GNU/SystemD/Linux

                                  Posté par . Évalué à 2.

                                  Et combien vont le faire ? Sachant que seul systemd-journald offre cette possibilité et qu’il n’est pas seul en jeu. Tu crois que les développeurs de démons vont laisser tomber syslog(3), largement disponible, et se mettre à utiliser l’API propre à systemd-journald ?

                                  Il n'y a pas besoin de laisser tomber syslog, le support de l'API journal peut etre ajoutée dans des #ifdef.

                                  Moi je n’y crois pas. Oh, certains le feront, certainement, mais je doute fort qu’ils soient nombreux.¹

                                  Quelques uns c'est deja mieux que aucun. Et meme si peu de programmes le font pour l'instant, peu importe, c'est deja bien de pouvoir en profiter pour ses propres programmes.

                                  Le seul bénéfice visible de journald, ici, c’est de faire l’économie de la première regex, celle qui sert à filtrer les messages issus de sshd — c’est-à-dire, la plus simple et surtout celle qui n’est pas vraiment susceptible de changer.

                                  Non, ca peut permettre par exemple de ne grepper que les logs du dernier boot, ou du precedent, ou uniquement ceux depuis une certaine date.

                                  Pour la recherche par IP, c'est une bonne idée de patch à proposer aux developpeurs de OpenSSH. En rajoutant aussi le nom d'utilisateur.

                                  • [^] # Re: GNU/SystemD/Linux

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

                                    Il n'y a pas besoin de laisser tomber syslog, le support de l'API journal peut etre ajoutée dans des #ifdef.

                                    Quand je disais « laisser tomber syslog pour journald », je sous-entendais naturellement « sur les plate-formes où systemd est disponible ». Et ça ne change rien à mon propos : qui va le faire ? Qui va prendre la peine de préparer une entrée de log structurée quand systemd est disponible, et une ligne de texte partout ailleurs, alors qu’il peut tout simplement continuer à utiliser une ligne de texte partout comme actuellement ?

                                    Non, ca peut permettre par exemple de ne grepper que les logs du dernier boot, ou du precedent, ou uniquement ceux depuis une certaine date.

                                    Point accordé. Ça doit être bien pratique dans certains cas. Mais je ne trouve toujours pas ça transcendant (c’est-à-dire que je ne suis pas convaincu que ça justifie une telle refonte du système de log).

                                    Enfin bref, comme je n’ai pas spécialement l’intention d’intervenir davantage dans ce débat, je vais résumer ma position actuelle sur systemd :

                                    – détracteurs de systemd, ne vous tracassez pas trop, vous verrez qu’en définitive, systemd ne changera pas grand’chose ;

                                    – adorateurs de systemd, ne vous emballez pas trop, vous verrez qu’en définitive, systemd ne changera pas grand’chose.

                                    Bon vendredi.

                                    • [^] # Re: GNU/SystemD/Linux

                                      Posté par . Évalué à 3.

                                      La plus part des daemons codes proprement vont avoir une point unique ou sera code toute leur infrastructure de log. C'est actuellement 5 lignes de code a faire pour passer de syslog a journald dans une infrastructure existante. Pour le coup, l'integration systemd complete, c'est pas loin d'etre juste une 30 aines de ligne codable par un developpeur debutant dans le projet.

                                      Donc si tu utilises des daemons bien code, ils seront rapidement adapte pour tirer benefice de systemd. Si ils ne le sont pas, tu pourras le faire toi meme (logiciel libre, tu as les sources, tout ca). Ce sera l'occasion de te rendre compte si le code des daemons que tu utilisent est bien, ou pas, foutu. Globalement une tache plutot interressante pour decouvrir son systeme.

                                    • [^] # Re: GNU/SystemD/Linux

                                      Posté par . Évalué à 1.

                                      Qui va prendre la peine de préparer une entrée de log structurée quand systemd est disponible, et une ligne de texte partout ailleurs, alors qu’il peut tout simplement continuer à utiliser une ligne de texte partout comme actuellement ?

                                      Le packageur sur une distribution basée sur systemd va simplement activer la bonne option de compilation.

                        • [^] # Re: GNU/SystemD/Linux

                          Posté par (page perso) . Évalué à 0. Dernière modification le 03/12/13 à 21:24.

                          Sinon, il y a un truc qui a 40 ans environ qui s'appelle "expressions régulières", très efficace pour parser du texte en O(n) quand c'est bien fait. Le gros intérêt est que ca existe ailleurs que sous Linux.

                          Ok, j'ai encore bien rit, merci.
                          Me causer de trucs qui pète lors d'une bête mise à jour car la regex n'a pas prévu le léger changement… me parler du truc bâtard que tu fais parce que tu n'as pas le choix et qu'à chaque update de base (même pas un changement de version) tu croises les doigts pour ne pas manquer une regression, c'est ce qu'il me fallait. C'est bien le gros exemple de la merde que sont les logs texte (du moins ceux de la vraie vie, qui n'ont aucune spécification et où chacun fait un peu comme il veut de toutes façon c'est pas fait pour être lu par une machine. Dommage, on voudrait qu'une machine les lise…).

                          C'est très bien d'avancer, mais vaut mieux que ce soit en avant et non dans un mur. Je peux te citer des exemples de gens qui ont voulu faire et avancer, mais trop hâtivement, et se retrouver avec une magnifique différence entre leur propre doc et leur implémentation réelle.

                          Manque de pot, ici ça a l'air de marcher, vu la vitesse à laquelle le projet a été adopté pour des ditro professionnelles* (qui font attention donc)…
                          Qui peut démontrer que ça va dans un mur? C'est plutôt le contraire qui se voit…

                          Faudrait arrêter l'excuse "je suis pour avancer, mais il faut pas anvacenr tu as vu le voisin il en est mort". Ca veut dire "ne pas avancer".
                          D'autres avancent, tout le monde est libre de dire "non, je ne suis pas d'accord", c'est imposé à personne.
                          Si vous y croyez vraiment, assumez et gérez.

                          Pourquoi vous ne laisser pas les gens "se planter" pendant que vous montrez que c'était la mauvaise voie? Moi je conclu que vous n'y croyait pas du tout à ce que vous dites…

                          • [^] # Re: GNU/SystemD/Linux

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

                            Ok, j'ai encore bien rit, merci.

                            Je t'en prie :)

                            Sinon, on peut également définir des formats standards de texte, ce n'est aps réservé qu'au binaire.

                            Manque de pot, ici ça a l'air de marcher, vu la vitesse à laquelle le projet a été adopté pour des ditro professionnelles* (qui font attention donc)…

                            Tu veux qu'on discute des choix de Apple ou de Microsoft sur leurs OS ?
                            De l'adoption rapide de docx comme format d'échange de documents textes par des entreprises professionnelles du domaine ? Et par le reste du monde aussi ?
                            Je dois avouer que j'aurais été plutôt surpris si Red Hat n'avait pas adopté systemd.

                            D'autres avancent, tout le monde est libre de dire "non, je ne suis pas d'accord", c'est imposé à personne.

                            C'est très exactement ce que je fais.

                            Pourquoi vous ne laisser pas les gens "se planter" pendant que vous montrez que c'était la mauvaise voie?

                            C'est également ce que je fais. J'ai changé de distribution lors de l'obligation de son utilisation sur celle que j'utilisais avant.

                            Opera le fait depuis 10 ans.

                          • [^] # Re: GNU/SystemD/Linux

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

                            Ok, j'ai encore bien rit, merci.

                            Et moi, ça fait plusieurs fois que ça me pique les yeux : il n'y a pas de "t" au participe passé de rire. ;)

                            En ce qui concerne le débat, j'ai l'impression que bien que systemd soit libre et qu'il ne soit imposé à personne, le fait qu'il soit étroitement lié à d'autres projets importants (par exemple Gnome) et qu'il touche un peu à tout (journaux, consoles…), va rendre plus délicate la possibilité de ne pas le choisir. Tu ne crois pas ?

                            There is no spoon...

                            • [^] # Re: GNU/SystemD/Linux

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

                              il n'y a pas de "t" au participe passé de rire. ;)

                              oups…

                              (…) va rendre plus délicate la possibilité de ne pas le choisir. Tu ne crois pas ?

                              Je ne crois pas, non :
                              - Personne n'oblige à utiliser quoi que ce soit. Tu es libre de passer à Ubuntu ou FreeBSD si ça te chante, et en plus vu l'horreur qu'est systemd qui détruit tout, les distros ayant fait le "mauvais" choix mourront et donc on en entendra même plus parler (ou l'inverse en fait)
                              - C'est libre! Si il y a des gens qui croient vraiment que Linux va s'effondrer (on croirait les anti-mariage homo qui prédisent la fin du monde) et que c'est horrible, les gens dans ce style peuvent forker et prouver qu'ils ont raison. D'après toi, si il y a plus de paroles que d'actes, c'est pour quelle raison? Encore une fois pourquoi les autres devraient être les esclaves de gens pensant que c'est pas bien d'utiliser systemd?

                              Ca a déjà été dit maintes fois, je pense que le plus important maintenant est d'arrêter de colporter de telles sous-entendus qui n'est que du FUD. Il faut aussi arrêter dans la vie de tous les jours, pas que systemd, ce "j'ai pas le choix". On a le choix, il faut seulement en assumer les conséquences (les autres n'étant pas nos esclaves).


                              Peut-être que le problème se situe ailleurs, bref pas chez les distros, de l'autre côté… rien de nouveau, on interdisait bien à un moment aux voiture de rouler plus qu'au pas par peur que le monde s'écroule à coup d'argument "vraiment scientifiques, attention horrible", et les voitures n'ont pas tué la marche à pied.

                              • [^] # Re: GNU/SystemD/Linux

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

                                OK. Effectivement, je peux changer de distribution. Mais, je travaille sous Debian depuis quelques années, et son fonctionnement, ses conventions, ne sont pas les mêmes que celles de Gentoo par exemple. Je devrais donc me réadapter. Pourquoi pas, mais ça demande du temps et une envie que je n'ai pas. Je suis à l'aise sous Debian et en accord avec ses conventions.

                                Donc, si Debian choisi d'intégrer systemd, à moins de changer de distribution, j'ai peur qu'il soit compliqué pour moi de choisir une alternative à systemd sous Debian, du fait du design de systemd.

                                Dans le principe je n'ai rien contre une évolution des choses. Repenser le système d'init, pourquoi pas. Les raisons que tu évoques sont légitimes. Ce qui m'embête c'est cette impression que ça se fasse au détriment des autres solutions.
                                Vu les liens qui semblent exister entre Gnome et systemd, quelle va être la masse de boulot pour choisir et faire fonctionner une alternative à systemd ?

                                En essayant d'être plus parlant, toujours sous Debian, si Gnome ne me plaît pas ou plus, je le désinstalle et le remplace par xfce ou kde par exemple. Ça n'a pas d'impact. Mais si systemd ne me convient pas, je ne pourrais probablement pas utiliser Gnome, et donc il faudra soit que je change de DE (ce que je ne souhaite pas forcément), voir que je change carrément de distribution.
                                Et si toutes les distributions font le choix de systemd, que me reste t'il ? Développer et maintenir ma propre distribution ? Utiliser Windows ou Mac OS ?

                                D'accord pour ne pas considérer les développeurs comme des esclaves, mais il faut aussi que tu entendes que c'est pas juste pisser de la ligne de code. Il y a des utilisateurs derrière, tu ne pas les dénigrer non plus.

                                Tu développes mediainfo, tu ne le fais pas que pour toi. Je m'en sers moi et je t'en remercie. Mais si demain tu décides de tout arrêter, ce sera certes ton choix et je suis d'accord sur le fait que tu n'as pas à y être enchaîné à vie, mais ce sera également hyper égoïste de ta part. On n'y pourra rien, mais on ne t'avait pas non plus forcé à entreprendre son développement.
                                Pour mediainfo, on pourrait probablement trouver ou maintenir une alternative, mais pour systemd, les implications sont beaucoup grandes.

                                Tu vois ce que je veux dire ?

                                There is no spoon...

                                • [^] # Re: GNU/SystemD/Linux

                                  Posté par (page perso) . Évalué à 9. Dernière modification le 04/12/13 à 10:32.

                                  Mais si demain tu décides de tout arrêter, ce sera certes ton choix et je suis d'accord sur le fait que tu n'as pas à y être enchaîné à vie, mais ce sera également hyper égoïste de ta part.

                                  Ah ouais, quand même… je vais peut-être perdre un utilisateur, mais il faut que ça sorte : je ne te dois absolument rien. Il n'y aurait absolument rien d'égoïste de ma part à ce que j'arrête, vu qu'il n'y a aucun rapport avec l'égoïsme.
                                  "L'égoïsme est un trait de caractère, l'attitude d'une personne dont les actions ou les idées sont uniquement orientées par ses propres intérêts, sans prendre en compte les nécessités d'autrui."
                                  Est-ce que ne plus faire d'actions est une action?
                                  Refuser l'esclavagisme, se rebeller contre son maitre, est-il égoïste d'après toi?
                                  D'après toi, personne ne devrait démissionner, car 'est de l'égoïsme?
                                  Tout ces gens qui réclament des augmentation e salaire, n'est-ce pas de l'égoisme?
                                  Pour revenir à systemd, proposer mieux pour la majorité des gens (car c'est bien la raison pour laquelle systemd est déployé) quitte à froisser des râleurs est-il considéré comme de l'égoïsme? vraiment?

                                  On voit bien le problème qu'il y a dans la relation développeur FLOSS et utilisateur. Tu abuses du mot "égoïsme".

                                  Tu vois ce que je veux dire ?

                                  J'ai peur de voir, oui. Je préfère m'arrêter la, c'est trop gros.
                                  Tant pis si je perd un utilisateur, mais d'autres sont plus reconnaissant et ne me traitent pas d'égoïste parce que je ne vais pas dans leur sens mais pense à tous mes utilisateurs, de manière globale, plutôt (mais j'en ai déjà eux qui m'ont traité de tous les noms car j'ai refusé d'aller dans leur sens… Ce genre de délire d'utilisateur qui veut tout n'est pas propre à systemd).

                                  • [^] # Re: GNU/SystemD/Linux

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

                                    Ouh là ! Doucement.

                                    Je n'ai pas dit que tu étais égoïste, j'ai dit que ce serait égoïste de ta part d'arrêter du jour au lendemain le développement de mediainfo sans penser à tous à qui il rend bien service. Ça ne ferait pas de toi une mauvaise personne pour autant, ce serait ton choix et comme je l'ai dit, tu serais tout à fait libre de le faire car en effet, tu ne me dois rien.

                                    Par ailleurs, pourquoi voudrais-tu perdre un utilisateur ? Tu penses vraiment que je vais m'offusquer de ta réponse au point de refuser d'utiliser un logiciel que tu développes ? On peut quand même discuter intelligemment, non ? Et on a parfaitement le droit de ne pas être d'accord. Sans déconner Jérôme, détends-toi. :)

                                    Pour rester sur systemd, proposer mieux pour la majorité des gens, je suis pour. Je te rejoins sur le fait que l'innovation est une bonne chose.
                                    Ce que j'essaye d'expliquer c'est que je trouve dommage que ce soit au détriment d'autres choses. Je suis d'accord pour que systemd innove, mais pas d'accord sur le fait qu'il me soit imposé pour utiliser Gnome par exemple. Pas d'accord non plus pour qu'il empêche toute alternative. De la même manière que chacun est libre de l'utiliser ou non, je veux rester libre d'utiliser l'init actuel de Debian.
                                    Or j'ai le sentiment (peut-être à tort), que le fait que systemd soit si étroitement lié à tant de choses va m'empêcher de choisir autre chose (même si cette autre chose reste maintenue)

                                    There is no spoon...

                                    • [^] # Re: GNU/SystemD/Linux

                                      Posté par (page perso) . Évalué à 6. Dernière modification le 04/12/13 à 11:37.

                                      Tu penses vraiment que je vais m'offusquer de ta réponse au point de refuser d'utiliser un logiciel que tu développes ?

                                      Il y en a, du moins qui me le disent quand je leur dit que nous, je ne vais pas supporter le fichier buggué car c'est le fichier qui est buggé et pas mon logiciel.
                                      je sais que je prend un risque quand je réagi. Ca reste un risque, pas de certitude :).

                                      j'ai dit que ce serait égoïste de ta part d'arrêter du jour au lendemain (…)

                                      Je réagi en fonction de mes libertés potentielle. Et je n'accepte pas qu'on me parle d'égoïsme (mot très négatif, Wikipedia dit "Le terme est presque toujours utilisé de façon péjorative.") parce que j'utilise un droit.
                                      Ma réaction reste la même : tu parles d'égoïsme un peu trop facilement, quand une personne ne fait pas (présent ou futur) un truc pour toi.
                                      Tu n'as pas répondu à mes questions avec des exemples, qu'on sache comment tu vois l'égoïsme.

                                      mais pas d'accord sur le fait qu'il me soit imposé pour utiliser Gnome par exemple.

                                      Mais en quoi est-ce la faute de systemd? Le coupable est dans ce cas Gnome.
                                      C'est un truc que je trouve complètement ridicule aussi, ça n'a aune bonne justification de dépendre de l'init comme ça, c'est ridicule.
                                      Mais ça n'a absolument rien à voir avec le sujet.

                                      Pas d'accord non plus pour qu'il empêche toute alternative.

                                      Il n'empèche rien. Libre à toi d'utiliser ce que tu veux, juste qu'il faut pas demander aux autres qu'ils bossent pour toi à te le préparer gratos.

                                      De la même manière que chacun est libre de l'utiliser ou non, je veux rester libre d'utiliser l'init actuel de Debian.

                                      Qu'est-ce qui interdit de faire un paquet (et le maintenir) en plus? Tu es libre, tout le monde et libre. y compris de refuser dans le dépot de Debian d'ailleurs.
                                      La liberté des uns commence où celles des autres s'arrête. Tu parlait de communauté, mais si la communauté refuse, c'est la communauté. Tu ne peux pas dire que la communauté n'existe pas quand elle fiat juste un truc qui ne te plait pas.

                                      Or j'ai le sentiment (peut-être à tort), que le fait que systemd soit si étroitement lié à tant de choses va m'empêcher de choisir autre chose (même si cette autre chose reste maintenue)

                                      Encore une fois, tu as toujours le choix. Sur tout. En plus, c'est libre, le travail est donc faible (seulement au pire un fork si tu n'arrives pas à convaincre la communauté, pour prouver que c'est mieux).

                                      Tu es libre. Les autres aussi (la communauté comprise).
                                      Ici, on parle qu'une poignée de râleurs veulent imposer leur point de vue à la communauté. Qu'on vienne pas me parler ensuite de respect de la communauté, les premiers à ne pas la respecter sont ceux qui crachent sur systemd et le choix de la communauté.
                                      Comment peut-on parler de respect de la communauté quand on refuse les choix qu'elle fait?
                                      On a l'impression d'avoir des réaction face à la justice qui quand elle tranche, va toujours avoir le "perdant" dire que la justice est pourrie (non pa qu'elle a fait un truc de mal, jsute qu'elle a pas fait comme attendu par la personne).

                        • [^] # Re: GNU/SystemD/Linux

                          Posté par . Évalué à 8.

                          Les outils Unix sont conçus spécifiquement pour traiter du texte ; ca reste le format universel pour Unix. Sinon, il y a un truc qui a 40 ans environ qui s'appelle "expressions régulières", très efficace pour parser du texte en O(n) quand c'est bien fait. Le gros intérêt est que ca existe ailleurs que sous Linux.

                          Et dire que tout un tas de gens utilisent des bases de données structurées du genre MySQL alors qu'il leur suffirait de mettre ca en vrac dans un fichier texte et faire des grep dessus !

                      • [^] # Re: GNU/SystemD/Linux

                        Posté par . Évalué à 2.

                        Je suppose que si les log n’était pas en binaire dans les années 80-début 90, alors qu’un format binaire aurait été plus compact en ces temps reculés de l’informatique où le moindre octet avait son importance, que pour des raisons de performance word 5, works (en version DOS)… recopiait la structure en RAM dans un fichier sans conversion.
                        Les ingénieurs de l’époque étaient certainement plus bête que Lennart ? Je ne suis hélas pas aussi intelligent que toi, mais tu as certainement une théorie, que j’espère tu es près à m’instruire.

                        • [^] # Re: GNU/SystemD/Linux

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

                          Sans aller jusqu'a "instruire", je me rends compte que les entreprises, dans la "grande compétition internationale", cherchent de plus en plus le zéro faute, le zéro plantage, les mise à jour sans interruption de service, …

                          Et pour y arriver, on trace de plus en plus de chose, éléments susceptible de défaillir ou intéressant à analyser, scruté en temps réel pour agir dans l'instant. Mais globalement la quantité de data récolté/analysé explose [constatation perso]. Dans un petit SI, on compte rapidement en dizaine de Go/jours.

                          Toujours mon expérience, le format binaire ne me dérange pas, c'est un format interne, tout comme le format interne de mysql. Personne n'utilise mysql par son format de fichier binaire, mais plutôt par son API (SQL) et ses outils. C'est juste pareil avec systemd.

                          De toute façon, si on veut faire un travail sérieux dans un S.I. avec les logs (au delà des script à 2 balles qui font des grep dans des cron), on va se retrouver à centraliser ailleurs les logs dans d'autres bases servant à l'analyse, elle-même binaire, comme elasticsearch ou mongodb.

                      • [^] # Commentaire supprimé

                        Posté par . Évalué à 1.

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

                        • [^] # Re: GNU/SystemD/Linux

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

                          On pourrait imaginer l'ajout d'un pid ou autre bricoles

                          Justement, systemd-journald ajoute pas mal « d’autres bricoles », comme :

                          – PID, UID et GID du processus émetteur ;
                          – le chemin du fichier exécutable ;
                          – la ligne de commande complète avec laquelle il a été lancé ;
                          – le cgroup dans lequel il se trouve ;
                          – le unit systemd dont il dépend ;
                          – un identifiant unique de la machine émettrice ;
                          – etc.

                          Cf. systemd.journal-fields(7) pour la liste complète (dans la section « Trusted journal fields »).

                          Du coup, voici à qui peut ressembler une entrée journald complète (telle que renvoyée par journalctl -o export :

                          __CURSOR=s=739ad463348b4ceca5a9e69c95a3c93f;i=4ece7;b=6c7c6013a26343b29e964691ff25d04c;m=4fc72436e;t=4c508a72423d9;x=d3e5610681098c10;p=system.journal
                          __REALTIME_TIMESTAMP=1342540861416409
                          __MONOTONIC_TIMESTAMP=21415215982
                          _BOOT_ID=6c7c6013a26343b29e964691ff25d04c
                          _TRANSPORT=syslog
                          PRIORITY=4
                          SYSLOG_FACILITY=3
                          SYSLOG_IDENTIFIER=gdm-password]
                          SYSLOG_PID=587
                          MESSAGE=AccountsService-DEBUG(+): ActUserManager: ignoring unspecified session '8' since it's not graphical: Success
                          _PID=587
                          _UID=0
                          _GID=500
                          _COMM=gdm-session-wor
                          _EXE=/usr/libexec/gdm-session-worker
                          _CMDLINE=gdm-session-worker [pam/gdm-password]
                          _AUDIT_SESSION=2
                          _AUDIT_LOGINUID=500
                          _SYSTEMD_CGROUP=/user/lennart/2
                          _SYSTEMD_SESSION=2
                          _SELINUX_CONTEXT=system_u:system_r:xdm_t:s0-s0:c0.c1023
                          _SOURCE_REALTIME_TIMESTAMP=1342540861413961
                          _MACHINE_ID=a91663387a90b89f185d4e860000001a
                          _HOSTNAME=epsilon
                          

                          Vu le nombre de champs ajoutés à stocker (ici, seul les champs MESSAGE et PRIORITY viennent du programme émetteur, tout le reste est ajouté soit par syslog, soit par journald), le choix d’un format binaire devient peut-être plus compréhensible… (Et puis, ça aurait pu être pire : si systemd avait été inventé dix ans plus tôt on aurait probablement eu droit à du XML…)

                          En tout cas, toujours au vu de la quantité d’informations à obtenir et à écrire, débattre du temps mis pour écrire un timestamp selon que l’on stocke en texte ou en binaire me semble assez peu pertinent, ce n’est certainement pas là à mon avis que systemd-journald passe le plus de temps.

                          • [^] # Commentaire supprimé

                            Posté par . Évalué à 1. Dernière modification le 05/12/13 à 19:34.

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

                            • [^] # Re: GNU/SystemD/Linux

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

                              En quoi, est-ce plus compréhensible ? On a la moité des champs qui sont du texte (paths, messages, …), un grand nombre de champs qui sont des très petits nombre, quelques timestamps.

                              D’une part, le volume d’informations pour une entrée est tel que ça ne me paraitrait pas très pratique de tout stocker sur une ligne. Je note au passage qu’au moins deux de ces champs peuvent contenir des espaces (MESSAGE et CMDLINE), ce qui introduit la nécessité de trouver un séparateur dont on soit sûr qu’il ne figurera jamais dans le contenu d’un champ (ou de permettre des échappements).

                              On pourrait certes stocker une entrée sur plusieurs lignes, mais cela rendrait le journal sensiblement plus difficile à exploiter avec les outils Unix classiques qui sont typiquement conçus pour travailler sur des lignes (comment récupérer deux champs différents d’une même entrée à coups de grep|cut|sed|awk|etc. s’ils sont sur deux lignes différentes ? c’est possible, certes, mais certainement pas pratique).

                              D’autre part, avec systemd-journald la composition d’une entrée de journal n’est pas constante (par exemple, toutes les entrées n’auront pas de champ _SYSTEMD_UNIT, seules celles provenant d’un processus faisant partie d’une unité systemd). Et ce d’autant plus que systemd-journald veut offrir aux programmes la possibilité de créer leurs propres champs en plus des champs définis par défaut (même si je doute personnellement que cette fonctionnalité sera beaucoup utilisée). Encore une fois, gérer ça me paraît malaisé dans un format texte à la syslog (qui est facile à utiliser notamment parce que tous les champs sont à des positions connues d’avance sur une ligne).

                              Après, je n’ai pas dit que le format binaire était le meilleur choix (franchement, je n’ai pas d’opinion tranchée sur la question) : je dis juste que compte tenu des ambitions de systemd-journald (qui veut un journal plus riche), ça se défend.

                              C'est ce que j'ai dit […] non ?

                              Si. Ce passage s’adressait plus à Zenitram, à qui tu répondais.

                              • [^] # Re: GNU/SystemD/Linux

                                Posté par . Évalué à 3. Dernière modification le 05/12/13 à 21:58.

                                Après, je n’ai pas dit que le format binaire était le meilleur choix (franchement, je n’ai pas d’opinion tranchée sur la question) : je dis juste que compte tenu des ambitions de systemd-journald (qui veut un journal plus riche), ça se défend.

                                le journal binaire de systemd-journald peut comporter des données purement binaires (core dump, ATA SMART blobs, firmware dumps, SCSI sense data, …)

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

                                • [^] # Re: GNU/SystemD/Linux

                                  Posté par . Évalué à 0.

                                  Et alors ? MIME, format textuel, est totalement capable d’intégrer des attachment purement binaires (images, archives compressées, exécutables compilés…).

                                  • [^] # Re: GNU/SystemD/Linux

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

                                    C'est vrai. Mais avec un encodage (adieu la simplicité du texte) et 33% de taille en plus. Que du bohneur (tu as du disque en trop, pas forcément les autres, quoique des fois on se demande vu que les mail ont toujours ce truc de 33% en plus certes).

                    • [^] # Re: GNU/SystemD/Linux

                      Posté par . Évalué à 2.

                      A propos de l'utilisation d'un format binaire :

                      "Break-ins on high-profile web sites have become very common, including the recent widely reported kernel.org break-in. After a successful break-in the attacker usually attempts to hide his traces by editing the log files. Such manipulations are hard to detect with classic syslog: since the files are plain text files no cryptographic authentication is done, and changes are not tracked. Inspired by git, in the journal all entries are cryptographically hashed along with the hash of the previous entry in the file. This results in a chain of entries, where each entry authenticates all previous ones. If the top-most hash is regularly saved to a secure write-only location, the full chain is authenticated by it. Manipulations by the attacker can hence easily be detected."

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

                      • [^] # Re: GNU/SystemD/Linux

                        Posté par . Évalué à 2. Dernière modification le 03/12/13 à 20:15.

                        since the files are plain text files no cryptographic authentication is done

                        Non sequitur.

                        S/MIME, DKIM, OpenID, OAuth : tous des protocoles purement textuels qui utilisent pourtant de la signature cryptographique.

                    • [^] # Re: GNU/SystemD/Linux

                      Posté par . Évalué à 2.

                      L'utilisation d'un format binaire permet aussi de standardiser les logs (par exemple au niveau des dates). Fini les regex qui changent en même temps que les programmes tiers changent leurs messages de logs.
                      L'anglais (ou n'importe quelle langue humaine, d'ailleurs), c'est de la merde à parser.

                      Je suis sûr qu'on peut trouver d'autres avantages à un format binaire dans le lien que j'ai donné, mais ce lien ne parle pas spécifiquement de ça, et démêler tout ça serait plus d'efforts que j'en ai envie pour un n-ième troll au sujet de "binaire vs textuel".

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

                      • [^] # Re: GNU/SystemD/Linux

                        Posté par (page perso) . Évalué à 2. Dernière modification le 03/12/13 à 19:17.

                        L'anglais (ou n'importe quelle langue humaine, d'ailleurs), c'est de la merde à parser.

                        Surtout quand tu te tapes un serveur dans une langue que tu ne connais pas parce que l'admin local a oublié que sa locale pour le confort a de l'impact sur le fichier de log, et où changer la locale pour ta session ne change pas la locale du fichier texte (du moins, c'est pas implémenté dans les serveurs que j'ai vu… Peut-être que Moonz a des logiciels que je n'ai pas) alors que les logs binaires l'affichage utilise la locale de ta session.
                        Alors certes les boites internationales (le monde bouge, change, évolue, plus besoin d'avoir 100 000 personnes pour être une boite internationale) imposent souvent "en-US.utf8" comme locale pour ne pas avoir de surprise, quel plaisir de se limiter techniquement…

                      • [^] # Re: GNU/SystemD/Linux

                        Posté par . Évalué à 4.

                        Parce que les formats textes ne peuvent pas être standardisés ? HTTP, XML/HTML, vCard, SMTP, MIME, ce n’est pas standardisé ? JSON c’est de la merde à parser ?

                      • [^] # Re: GNU/SystemD/Linux

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

                        L'utilisation d'un format binaire permet aussi de standardiser les logs (par exemple au niveau des dates).

                        Ce n'est pas nécessaire. On peut standardiser les logs dans un format texte, on y arrive bien pour d'autres choses (au hasard je html ; ca reste du texte, et la syntaxe est plutôt précise).

                        L'anglais (ou n'importe quelle langue humaine, d'ailleurs), c'est de la merde à parser.

                        Question de format, et de techno employé. Si le texte est bien formaté, selon des règles lexicales et syntaxiques constantes et précises, et que tu utilises un outil adéquat, il n'y a pas énormément de difficulté à parser du texte.

                        Je sais que ca fait beaucoup de condition, sauf que pour celles qui concernent la génération de texte, journald le fait déjà au format binaire, et pourrait très bien le faire de façon aussi générique en texte.

                        Et bon, honnêtement, si je n'ai pas d'OS avec journalctl sous le coude, je trouve que le texte est quand même énormément plus facile à traiter que du binaire.

                        Opera le fait depuis 10 ans.

                        • [^] # Re: GNU/SystemD/Linux

                          Posté par (page perso) . Évalué à -2. Dernière modification le 03/12/13 à 21:29.

                          (au hasard je html ; ca reste du texte, et la syntaxe est plutôt précise).

                          Je rigole toujours, super!

                          Si (…)

                          Avec des si, on met Paris en bouteille.

                          Et bon, honnêtement, si je n'ai pas d'OS avec journalctl sous le coude, je trouve que le texte est quand même énormément plus facile à traiter que du binaire.

                          Sauf si tu n'as pas de traducteur ASCII --> affichage pour humain (tu parles bein d'absence de l'outil, j'utilise le même argument que toi qui aurait empéché l'avenement d'ASCII par exemple… Terrible comme argument)

                          Et quitte à se répéter, rien n'empèche de mettre une copie texte juste à côté (parait que ça bouffe rien!).
                          Et rien n'empèche de faire un lecteur de journaux journald comme on a des lecteurs de fichier ASCII spéciale Linux sous Windows (parce que tu as déjà ouvert un fichier log Unix sous Windows Notepad? Tout sur une ligne. Oui, voila, c'est ton super format texte, tout sur une ligne, très pratique… ou alors il faut avoir un outil "Unix" qui n'existait pas avant! Mais la on retombe sur ton argument "ça n'existe pas")

                          • [^] # Re: GNU/SystemD/Linux

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

                            Je rigole toujours, super!

                            Développe.

                            Avec des si, on met Paris en bouteille.

                            Ca c'est de l'argumentation en béton. Dans le même genre, je pourrais dit qu'avec des "si" et des "sinon" on a fait des OS.

                            Sauf si tu n'as pas de traducteur ASCII --> affichage pour humain (tu parles bein d'absence de l'outil, j'utilise le même argument que toi qui aurait empéché l'avenement d'ASCII par exemple… Terrible comme argument)

                            Cite moi un OS qui n'en est pas équipé par défaut, à son installation.

                            Tout sur une ligne. Oui, voila, c'est ton super format texte, tout sur une ligne, très pratique…

                            Oui très, parce qu'il ne m'empêche pas de le traiter avec l'outil que je veux. Alors que ton binaire, je dois passer par un outil Linux-only.

                            ou alors il faut avoir un outil "Unix" qui n'existait pas avant!

                            Lex, gcc, grep, sed, find, et autre, n'existent pas que sous Unix. Bien tenté.
                            Par contre journalctl n'existe que sous Linux et non sous Mac OS, FreeBSD, et les non-Unix.

                            Opera le fait depuis 10 ans.

                        • [^] # Re: GNU/SystemD/Linux

                          Posté par . Évalué à 0. Dernière modification le 03/12/13 à 21:37.

                          Ce n'est pas nécessaire. On peut standardiser les logs dans un format texte, on y arrive bien pour d'autres choses (au hasard je html ; ca reste du texte, et la syntaxe est plutôt précise).

                          Bonne chance pour standardiser les messages de logs de tous les logiciels existants.
                          Et puis :

                          Why do you guys reinvent the wheel, again? Why not just add what you need to existing syslog? If you just clean up your log formatting, syslog should be fine!
                          […] And no, just fixing the log formatting won’t get you much. Not even the most basic requirements like binary blobs or sensible structured logging. Let alone stuff like indexing or proper access control.

                          Et bon, honnêtement, si je n'ai pas d'OS avec journalctl sous le coude, je trouve que le texte est quand même énormément plus facile à traiter que du binaire.

                          Tu arrives à avoir un OS avec journald et ses logs binaires, mais sans journalctl ? Où, quand, comment, pourquoi ?

                          Et puis bon, c'est pas comme si journald n'était pas compatible avec syslog (il te manquera juste les méta-données, les blobs binaires au sein du journal ("ATA SMART health data, SCSI sense data, coredumps or firmware dumps"), l'access control & chiffrement du journal - comment savoir si le journal a été modifié ou non sans ça ? -, et la structuration du journal).

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

                          • [^] # Re: GNU/SystemD/Linux

                            Posté par (page perso) . Évalué à 3. Dernière modification le 03/12/13 à 21:45.

                            Tu arrives à avoir un OS avec journald et ses logs binaires, mais sans journalctl ? Où, quand, comment, pourquoi ?

                            La, tu merdes, l'argument a déjà été donné et c'est le seul de pas trop mauvais pour 1 minute de réflexion avant de savoir comment s'en sortir : mode rescue d'un serveur à distance (la distro n'est pas toujours la même, pas toujours à jour).
                            Argument qui vaut pour toute évolution, et se casse en une option (tu gardes le format binaire pour tes gros log, et si ton rescue ne connait pas systemd, tu perd du CPU et un peu de charge disque à faire une copie en mode "à l'ancienne" que tu effaces 48 heures après et basta, c'est un faux problème mais il ne fut pas leur donner le plaisir de dire que ça n'arrive pas d'avoir une machine sans journald mais un log journald, en attendant que leur rescue soit à jour)

                            Mais sinon, oui, le reste est difficile à faire passer… On ne leur enlève rien (faut juste activer une option), on ne fait que rajouter, mais ils se plaignent.

                          • [^] # Re: GNU/SystemD/Linux

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

                            Bonne chance pour standardiser les messages de logs de tous les logiciels existants.

                            La sortie de journald n'a pas de format standard ?

                            Tu arrives à avoir un OS avec journald et ses logs binaires, mais sans journalctl ? Où, quand, comment, pourquoi ?

                            Depuis que je ne lis pas forcément mes logs que sous Linux, surtout quand le sus-cité Linux ne boot plus.

                            Opera le fait depuis 10 ans.

                          • [^] # Re: GNU/SystemD/Linux

                            Posté par . Évalué à 3.

                            Bonne chance pour standardiser les messages de logs de tous les logiciels existants.

                            Tout ce qui est formaté automatiquement par journald dans un format binaire peut être formaté dans un format texte "standardisé". Je ne comprend pas l’argument.

                            Not even the most basic requirements like binary blobs or sensible structured logging. Let alone stuff like indexing or proper access control.

                            La structuration se fait très bien en texte, cf JSON.

                            Les blobs peuvent être mis dans un fichier à part s’ils sont gros (coredump par exemple) ou peuvent être sérialisés en base64.

                            L’indexation peut (et c’est même une très bonne idée, c’est ce que font la plupart des base de données à ma connaissance) se faire dans un fichier à part des données.

                            Pour l’access control, encore une fois je ne vois pas le rapport avec le débat texte/binaire

                            Tu arrives à avoir un OS avec journald et ses logs binaires, mais sans journalctl ? Où, quand, comment, pourquoi ?

                            Système non bootable, je veux voir les logs, j’ai un dual-boot MacOS X ou Windows (desktop). Même situation, j’ai une option netboot sur FreeBSD (serveur). Comment je lis les logs binaires pour savoir pourquoi ça boot pas ?

                            Et puis bon, c'est pas comme si journald n'était pas compatible avec syslog (il te manquera juste les méta-données, les blobs binaires au sein du journal ("ATA SMART health data, SCSI sense data, coredumps or firmware dumps"), l'access control & chiffrement du journal - comment savoir si le journal a été modifié ou non sans ça ? -, et la structuration du journal).

                            C’est en pratique ce que je fais, mais s’il faut avoir les logs en double pour avoir la fonctionnalité « être lisible en toute circonstance », je trouve que c’est loin d’être optimal… (et ça pénalise à peu près tous les autres critères discutés : vitesse (écrire deux fois sur le disque dans des fichiers séparés, pas glop), fiabilité dans une situation d’espace disque plein (le problème est doublé), taille prise sur le disque).

                        • [^] # Re: GNU/SystemD/Linux

                          Posté par . Évalué à 3.

                          Et bon, honnêtement, si je n'ai pas d'OS avec journalctl sous le coude, je trouve que le texte est quand même énormément plus facile à traiter que du binaire.

                          Ca tombe bien, journalctl permet justement d'exporter les logs en json.

                          • [^] # Re: GNU/SystemD/Linux

                            Posté par . Évalué à 0.

                            La situation dans laquelle tu veux directement les logs dans un format textuel c’est justement quand journalctl est indisponible.

                            • [^] # Re: GNU/SystemD/Linux

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

                              Libre à toi d'exporter tout le temps en JSON pourton cas (gestion du passé ou de l'incompatibilité, tranquille systemd te permet tout).
                              C'est quoi le problème? Que tu te rendes compte que ton argument tient pas et tu cherches à te racrocher aux branches?

                            • [^] # Re: GNU/SystemD/Linux

                              Posté par . Évalué à -1.

                              Et dans quel cas as tu besoin de consulter ces logs alors que journalctl est indisponible ?

                              La machine sur laquelle sont tes logs dispose forcement de journalctl. Si le problème est que la machine ne boot pas, ben tu prends un livecd ou une clef USB de la distro utilisée, qui doit normalement inclure journalctl.

                              • [^] # Re: GNU/SystemD/Linux

                                Posté par . Évalué à -2.

                                • [^] # Re: GNU/SystemD/Linux

                                  Posté par . Évalué à 5.

                                  Et le jour ou OVH oublie de mettre gzip sur leur mode rescue tu vas aller dire qu'il ne faut jamais compresser les logs ?

                                  Si OVH fournit des distributions utilisant systemd-journal sans les outils pour le lire dans le mode rescue, c'est un probleme du mode rescue OVH. C'est rien d'insurmontable à corriger, faut juste leur signaler.

                                  systemd-journal étant assez recent, c'est pas très étonnant qu'il puisse y avoir ce genre de problème, mais y a pas de raison que ca reste comme ca. Et si ca te gene vraiment, ben tu actives l'export vers syslog (ou tu ne le désactive pas, puisqu'il est encore souvent activé par default).

                  • [^] # Re: GNU/SystemD/Linux

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

                    Et pour remplir tout ces points, est-il nécessaire d'avoir un binaire en lieu et place d'un texte standard qui serait encore plus portable, encore plus facilement manipulable par des outils éprouvés et reconnus pour leurs grandes vitesse de fonctionnement (en O(n), et code machine optimisé pendant bientôt 40 ans) ?
                    Malgré la doc, je ne comprends toujours pas l'intérêt d'avoir un binaire en lieu et place d'un texte, à part pour le stockage, mais je crois que plus grand monde a des systèmes équipés de mémoires de stockages pour lesquelles 160Ko n'est pas négligeable (taille de mon dossier de log). Quelqu'un pour éclairer ma lanterne ?

                    Opera le fait depuis 10 ans.

                    • [^] # Re: GNU/SystemD/Linux

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

                      Faut croire qu'en 40 ans, pas foule a réussi à standardiser du texte (déjà que personne n'arrive à se mettre d'accord sur comment on écrit un retour à la ligne entre OS…)

                      Je retourne la question dans l'autre sens : quel interêt d'un stockage en texte "standard" (à définir)?

                      mais je crois que plus grand monde a des systèmes équipés de mémoires de stockages pour lesquelles 160Ko n'est pas négligeable (taille de mon dossier de log).

                      Donc au final, j'en conclue que ça ne te dérange pas de sélectionner l'option permettant de sortir en texte, ça bouffe rien. Finalement, en quoi le fait qu'il y a un stockage binaire (encore plus petit) à côté de ta sortie préférée te dérange?
                      Un truc que je ne capte pas : vous avez votre sortie texte, tous vos avantages d'une sortie texte sont la, donc quelle est la réélle critique?

                      Sinon, pour information, tu es sensé stocker tes logs pendant 1 an, et un jour ça passera à 2 ans. tout le monde n'a pas que 2 visiteurs par jour sur son site web et a des loggs à gérer.

                      Je jette un oeil vite fait sur mon petit site web, access_log d'httpd fait 100 Mo (non compressé ok, ça donne 3 Mo compressé, mais peut-on considérer du compressé comme du texte? Non, un octet quii saute et hop tout est perdu, pile une critique de journald, donc parlons de 100 Mo). Merci le texte (déjà un rapport de 1/30 juste en compressant de manière générique sans optimisation "pour logs"), sur 1 an ça donne 30 Go, et tout ça pour un petit site… Je n'ose pas imagine un site moyen ni gros.
                      Je tape un peu à côté, mais c'est juste pour dire que la où toi tu n'as pas de problème de place, d'autres en ont. J'ai vu plusieurs projets (dont un dont j'étais chef de projet, c'est moi qui ai pris la gueulate d'avoir fait planter un serveur à cause de lenteur non gérées quand le log a fait x100 d'un coup) se dire "pas grave, on a du CPU, du disque et du réseau" et ensuite exploser en vol à cause des perfs dès que ça montait en charge car succès, et le boss il a pas aprécié que ça se plante le jour où ça a du succès (ou simplement un gros problème qui fait faire de gros logs) avec les clients…

                      Bref, désolé, mais la taille, la perf, c'est critique pour certains, et le but d'un projet tel que celui dont en parle n'est pas de simples serveurs.

                      • [^] # Re: GNU/SystemD/Linux

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

                        Faut croire qu'en 40 ans, pas foule a réussi à standardiser du texte

                        Faut croire que si, (x)HTML est stocké en texte et non en binaire, pourtant son format est plutôt standard.

                        Je retourne la question dans l'autre sens : quel interêt d'un stockage en texte "standard" (à définir)?

                        La lisibilité par un humain, la possibilité le le lire et le traiter avec autre chose que journalctl.

                        Finalement, en quoi le fait qu'il y a un stockage binaire (encore plus petit) à côté de ta sortie préférée te dérange?

                        Selon entre autre toi, parce que ca bouffe de la place. Autrement, parce que ca fait des fichiers inutiles, et si tu veux de l'argument technique, certains FS, toujours utilisés, sont limités à ce niveau là.
                        Si tu as un cas d'utilisation d'un sysème qui n'a pas 160Ko pour les logs, n'hésite surtout pas à le donner, comme demandé plus haut.

                        Sinon, pour information, tu es sensé stocker tes logs pendant 1 an, et un jour ça passera à 2 ans. tout le monde n'a pas que 2 visiteurs par jour sur son site web et a des loggs à gérer.

                        Logs que tu n'utilises pas tout les jours et que tu archives. Tu peux donc les compresser en xz.

                        (non compressé ok, ça donne 3 Mo compressé, mais peut-on considérer du compressé comme du texte? Non, un octet quii saute et hop tout est perdu, pile une critique de journald, donc parlons de 100 Mo)

                        Contexte différent. Ce sont des logs archivés que tu ne gardes que pour respecter la loi, et non pour les utiliser toi même, pour maintenir ton système, avec des yeux ou avec des outils tels que Fail2Ban ou Ossec.
                        D'ailleurs à ce propos, Fail2Ban et Ossec gèrent comment ces logs binaires ? Tes 3 Mo, c'est en tar.xz ? Et ils donnent quoi en binaire ?

                        donc quelle est la réélle critique?

                        La façon dont systemd est poussé dans la majorité des distributions, et donc de l'imposer. Parce que oui, quand une distribution abandonne le support d'un logiciel au détriment d'un autre, et qu'elle retire l'ancien logiciel du système de l'utilisateur via une mise à jour, elle force ce dernier à changer de logiciel.

                        Merci pour ton retour d'utilisation, et les chiffres "à la louche" pour le stockage, ca donne une meilleure vu d'ensemble.

                        Opera le fait depuis 10 ans.

                        • [^] # Re: GNU/SystemD/Linux

                          Posté par (page perso) . Évalué à 2. Dernière modification le 03/12/13 à 22:06.

                          Logs que tu n'utilises pas tout les jours et que tu archives. Tu peux donc les compresser en xz.

                          Donc c'est du binaire (avec toutes les attaques sur les binaire : faut le logiciel, si un octet saute tout saute… Ca a été donné ici, tu n'as pas réagi, rien ne te choque dans le bianire en fait).
                          Merci, tu viens d'argumenter pour avoir du binaire, tu n'aimes pas le texte.

                          (non, parce que bon sur le rescue, xz est pas supporté… C'était vrai à une époque)

                          La façon dont systemd est poussé dans la majorité des distributions, et donc de l'imposer. (…)

                          Foutaises : tu es libre de prnedre une autre distro, de forker… Merci de ne pas sortir les argument d'hier, les réponses sont les mêmes : ce dotn vous vous plaingez, c'est que vous n'avez pas d'esclaves.
                          Monde pourri quand on n'a pas d'esclaves…

                          OK, c'est bon, belle démonstration d'incohérence complète sur le binaire + le problème est que les autres ne sont pas vos esclaves, ça n'a rien à voir avec systemd.

                          Merci pour ton retour d'utilisation, et les chiffres "à la louche" pour le stockage, ca donne une meilleure vu d'ensemble.

                          tu veux dire que tu as aucune idée de ce qu'est du volume de log mais dit que c'est "pas gros"? hum… Et dire que j'ai pris juste un petit site qu'est le mien, j'ai pas osé voir les logs de grosses machines auquelles se destine systemd…

                          • [^] # Re: GNU/SystemD/Linux

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

                            Merci, tu viens d'argumenter pour avoir du binaire, tu n'aimes pas le texte.

                            La lecture et l'étude de texte se fait dès la 6ème. Je te mets la suite que tu as visiblement oublié de lire.

                            "Contexte différent. Ce sont des logs archivés que tu ne gardes que pour respecter la loi, et non pour les utiliser toi même, pour maintenir ton système, avec des yeux ou avec des outils tels que Fail2Ban ou Ossec.
                            D'ailleurs à ce propos, Fail2Ban et Ossec gèrent comment ces logs binaires ? Tes 3 Mo, c'est en tar.xz ? Et ils donnent quoi en binaire ?"

                            Merci de répondre aux questions au passage, c'en sont de vraies, par pour faire joli.

                            Foutaises : tu es libre de prnedre une autre distro

                            Oui, donc je suis contrains de ne plus utiliser l'ancienne. Merci d'abonder dans mon sens, mais lis en entier un texte avant de passer à la suite.

                            ce dotn vous vous plaingez, c'est que vous n'avez pas d'esclaves.

                            Non. Ce dont je me plains, dans ce cas là, est la suppression pure et simple d'un logiciel des dépôts d'une distribution, alors qu'il y a eu une demande à ce qu'il y reste.

                            OK, c'est bon, belle démonstration d'incohérence complète sur le binaire + le problème est que les autres ne sont pas vos esclaves, ça n'a rien à voir avec systemd.

                            Non. Comme dit plus haut, la compréhension de texte s'étudie en 6ème. Je t'invite à tout relire en entier avant de parvenir à une conclusion aussi erronée. Je n'y peux rien si tu ne peux pas essayer de comprendre le point de vu de quelqu'un d'autre.

                            tu veux dire que tu as aucune idée de ce qu'est du volume de log mais dit que c'est "pas gros"?

                            Non, tu tires là, encore une fois devrais-je dire, une conclusion erronée. J'en ai une idée de ce que j'ai eu l'occasion d'en voir, avec mon serveur. D'ailleurs je trouve intéressant que tes logs prennent autant de place, et j'aimerais bien volontiers avoir le détail des services qui logs quelques choses qui tournent sur ton serveur.

                            Opera le fait depuis 10 ans.

                          • [^] # Re: GNU/SystemD/Linux

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

                            Foutaises : tu es libre de prnedre une autre distro, de forker… Merci de ne pas sortir les argument d'hier, les réponses sont les mêmes : ce dotn vous vous plaingez, c'est que vous n'avez pas d'esclaves.
                            Monde pourri quand on n'a pas d'esclaves…

                            Hum je vais illustrer un peu ton propos pour te montrer l'idiotie de ce genre de raisonnement.

                            J'échange ta femme avec la mienne. Si tu n'es pas content, tu es libre de changer de maison, ou de forker la tienne pour essayer d'y remettre ta femme.
                            Dois-je continuer l'analogie en parlant des esclaves ?

                            Opera le fait depuis 10 ans.

                            • [^] # Re: GNU/SystemD/Linux

                              Posté par . Évalué à 8.

                              L'analogie est pertinente.
                              Dans la vraie vie, c'est ta femme qui décide de se barrer chez le voisin, et chance: celle du voisin te trouve à son goût.

                              Les développeurs, en particulier les bénévoles, ont encore le droit de choisir ce sur quoi ils travaillent. S'ils sont payés, c'est peut-être la boite qui décide.
                              Les intégrateurs, en particulier les bénévoles, ont le droit de prendre des décisions sur l'intégration, vu que c'est eux qui vont faire le boulot. S'ils sont payés, c'est peut-être la boite qui décide.
                              Les utilisateurs ont le droit d'utiliser, de faire part de leur opinion, mais à la fin, celui qui tranche, c'est celui qui code, qu'il soit bénévole ou qu'il soit payé.
                              Si l'utilisateur est payé, ça ne change absolument rien.

                              Réclamer sans cesse le maintien d'une solution que les développeurs et intégrateurs ne veulent plus maintenir, c'est censé donner quel résultat? Qu'ils le fassent à contre-cœur pour te faire plaisir à toi et aux autres anti-systemd?

                              C'est des branleurs au marketing chez RedHat, il y a un marché gigantesque pour une distro exempte de systemd qui sera aussi rentable que celle avec systemd et ils ne l'ont pas vu?

                              Ils ne savent pas encore que le support technique va s'écrouler suite à la migration vers systemd?

                              • [^] # Re: GNU/SystemD/Linux

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

                                On m'a vendu Linux comme un système communautaire, où les utilisateurs peuvent donner leurs avis, et où les devs, en fonction des retours, prennent leurs décisions. J'ai donc encore le droit de donner mon avis je crois.

                                Pour information, pour Archlinux, le nombre de personne réclamant la cohabitation systemd sysVinit n'était pas de l'ordre de la dizaine, mais bien supérieur.

                                Alors certes les bénévoles ne veulent plus maintenir sysVinit, mais est-ce une raison suffisante pour forcer son remplacement via une mise à jour ? Et pour le sortir des dépôts comme un mal propre, alors qu'il fonctionne ?

                                Ce dernier point soulève également un débat un peu plus général que l'univers de systemd : est-ce que, parce qu'un logiciel n'a plus de mise à jour, il doit être considéré comme non maintenu, et est-ce parce qu'un logiciel est non maintenu qu'il doit forcément être éjecté des dépôts (je ne dis pas non plus de le garder dans le dépôt core) ?

                                C'est des branleurs au marketing chez RedHat, il y a un marché gigantesque pour une distro exempte de systemd qui sera aussi rentable que celle avec systemd et ils ne l'ont pas vu?

                                Systemd ne vient pas de chez eux ? On m'aurait menti ? Parce qu'autrement, ca serait comme dire que comme Microsoft vend et fourni un support de ISS, il est forcément meilleur techniquement et beaucoup plus fiable que Apache.

                                Opera le fait depuis 10 ans.

                                • [^] # Re: GNU/SystemD/Linux

                                  Posté par . Évalué à 3.

                                  Alors certes les bénévoles ne veulent plus maintenir sysVinit, mais est-ce une raison suffisante pour forcer son remplacement via une mise à jour ? Et pour le sortir des dépôts comme un mal propre, alors qu'il fonctionne ?

                                  Decider de ne plus maintenir sysv me parait une raison suffisante pour ne plus maintenir sysv init. Parce que oui, maintenir un paquet dans les depots, ca revient a le maintenir, donc s'ils ont decide de ne plus le maintenir.

                                  Si ca te derange qu'arch l'ait vire un beau matin (si c'est bien ce dont tu parles), fallait pas choisir une distro rolling ou aucune garantie n'est faite sur la stabilite des paquets ;-)

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

                                • [^] # Re: GNU/SystemD/Linux

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

                                  On m'a vendu Linux comme un système communautaire,

                                  Oui…

                                  où les utilisateurs peuvent donner leurs avis,

                                  Oui…

                                  et où les devs, en fonction des retours, prennent leurs décisions.

                                  Oui.

                                  Mais ici, ce n'est pas ce qui est demandé. Ici, la phrase change : et où les devs doivent obéir.
                                  Et la, c'est non.

                                  Rien de nouveau, syystemd n'est qu'un parmi d'autres avec le même type de personnes qui ne comprennent pas la différence entre choix communautaire et "mon choix".
                                  Ici, la communauté décide de prendre systemd, le fait que le choix ne soit pas le tien personnel ne change pas que c'est communautaire.

                                  dure la vie communautaire où le choix communautaire n'est pas toujours ton choix personnel…

                                  Bizarrement, ta phrase n'a absolument rien à voir avec ce qui est demandé par les gens qui râlent (ils veulent pas que les dév fassent un choix en fonction des retour, mais de leurs retours sans prendre en compte les retours des autres).
                                  Ou comment travestir la réalité (et ce n'est pas spécifique à systemd, pas spécifique à Linux, dans le monde politique on a exactement le même type de réaction où les gens se prennent pour les "99%" en ayant pas foule derrière eux en réalité).

                                  • [^] # Re: GNU/SystemD/Linux

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

                                    le fait que le choix ne soit pas le tien personnel

                                    Ce n'est pas uniquement mon choix personnel justement. Cesse de prétendre que je suis le seul et unique à ne pas vouloir de systemd, c'est une conclusion fausse.

                                    ils veulent pas que les dév fassent un choix en fonction des retour, mais de leurs retours sans prendre en compte les retours des autres

                                    Non. Ils veulent un choix qui satisfassent, ** entre autre ** leurs retours, tel qu'une cohabitation. Je doute fortement que les pro sysVinit refusent que les retours des pro systemd soit pris en compte.

                                    Ou comment travestir la réalité

                                    Oui en effet. Dire que tout le monde veut une chose quand justement une minorité non négligeable n'en veut pas, c'est travestir la réalité.

                                    Opera le fait depuis 10 ans.

                                • [^] # Re: GNU/SystemD/Linux

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

                                  Systemd ne vient pas de chez eux ? On m'aurait menti ?

                                  Ça vient d'un employé qui l'a commencé sans que ce soit un projet de Red Hat, et il y a des développeurs hors Red Hat qui bossent dessus. Du coup, vu le nombre d'employés qui bossent sur Linux (et les positions qu'ils ont), c'est aussi un projet Red Hat ?

                                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                                • [^] # Re: GNU/SystemD/Linux

                                  Posté par . Évalué à 9. Dernière modification le 04/12/13 à 14:10.

                                  Pour information, pour Archlinux, le nombre de personne réclamant la cohabitation systemd sysVinit n'était pas de l'ordre de la dizaine, mais bien supérieur.

                                  Alors certes les bénévoles ne veulent plus maintenir sysVinit, mais est-ce une raison suffisante pour forcer son remplacement via une mise à jour ? Et pour le sortir des dépôts comme un mal propre, alors qu'il fonctionne ?

                                  Blah blah blah. Le nombre de personnes réclamant la cohabitation était tellement grand qu'aucune de celles-ci n'a mis la main à la pâte pour maintenir sysinit (et tous les scripts qui vont avec) dans l'AUR. Bah, oui, parce que le paquet a été déplacé des dépôts binaires officiels vers le dépôt utilisateurs AUR. Parce qu'il n'y avait plus de support de la part des développeurs officiels, et que les utilisateurs intéressés étaient invités à le maintenir eux-même (et je vois mal comment on peut reprocher ceci).

                                  Alors les anti-systemd, faudra sortir du pathétisme de haut niveau et apprendre que râler != bosser, et que seule cette dernière action donne du résultat. Etre son propre esclave et faire le boulot soi-même, c'est tout de suite moins drôle, pas vrai?

                                  • [^] # Re: GNU/SystemD/Linux

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

                                    Blah blah blah

                                    Si tu ne veux pas lire, ne lis pas, je ne te force pas.

                                    La façon dont sysVinit a été remplacé directement dans le systeme des utilisateurs est assez intéressante, parce que justement, Sabayon a également opté pour systemed, mais n'a pas forcé la désinstallation de l'ancien init. Au final je peux continuer à faire mes mises à jours sans avoir systemd en guise d'init.

                                    Etre son propre esclave et faire le boulot soi-même, c'est tout de suite moins drôle, pas vrai?

                                    Surtout quand on est uniquement utilisateur d'un OS. Donc pour résumer ton point de vu, quand on veut utiliser un système, on ne peut pas être seulement utilisateur mais aussi être mainteneur ?

                                    Au fait, le ndd de ta page perso semble avoir expiré.

                                    Opera le fait depuis 10 ans.

                                    • [^] # Re: GNU/SystemD/Linux

                                      Posté par . Évalué à 3. Dernière modification le 05/12/13 à 18:08.

                                      Si tu ne veux pas lire, ne lis pas, je ne te force pas.

                                      Tu veux dire que tu peux dire des bêtises sur un site public sans que quiconque n'ai un droit de réponse?

                                      La façon dont sysVinit a été remplacé directement dans le systeme des utilisateurs est assez intéressante, parce que justement, Sabayon a également opté pour systemed, mais n'a pas forcé la désinstallation de l'ancien init. Au final je peux continuer à faire mes mises à jours sans avoir systemd en guise d'init.

                                      La cas Sabayon est peut être intéressant, mais si tu es en désaccord avec la façon de faire d'Arch (garantir la qualité des paquets officiels notamment) c'est que tu as trés mal choisi ta distribution. Arch, c'est pas seulement la distribution "hype" du moment, c'est avant tout une ligne directrice claire avec des utilisateurs cibles bien définis (relis "The Arch Way").

                                      Surtout quand on est uniquement utilisateur d'un OS. Donc pour résumer ton point de vu, quand on veut utiliser un système, on ne peut pas être seulement utilisateur mais aussi être mainteneur ?

                                      Non, quand tu es simple utilisateur tu utilises simplement ce qui est fourni par la distribution. Si tu veux t'amuser à sortir des sentiers battu, tu assumes, et encore plus quand tu es sous Arch.

                                      Au fait, le ndd de ta page perso semble avoir expiré.

                                      Arf, dommage. Pas ma page perso, mais un site en contraste avec linuxfr bien rigolo.

                                • [^] # Re: GNU/SystemD/Linux

                                  Posté par . Évalué à 6.

                                  Zenitram a répondu au reste et je suis d'accord avec lui.
                                  Juste ça:

                                  C'est des branleurs au marketing chez RedHat, il y a un marché gigantesque pour une distro exempte de systemd qui sera aussi rentable que celle avec systemd et ils ne l'ont pas vu?

                                  Systemd ne vient pas de chez eux ? On m'aurait menti ? Parce qu'autrement, ca serait comme dire que comme Microsoft vend et fourni un support de ISS, il est forcément meilleur techniquement et beaucoup plus fiable que Apache.

                                  MS est une boite qui fait du proprio et vend exclusivement des solutions internes (ou rachète des boites, ce qui fait que la solution devient interne).

                                  RedHat édite une distribution Linux, ça veut dire que même s'ils ont de (nombreux) développements internes, ils font surtout de l'intégration de multiples composants.
                                  J'aurais du mal à croire que le choix de ces composants se fait sans aucune idée de l'impact pour leurs clients, ou alors on doit attribuer leur succès jusqu'ici à la chance, ça me parait un peu gros.
                                  Donc l'idée que c'est un projet RedHat porté par un dev RedHat et donc forcément RedHat va le passer en force partout même si tout le monde sait que c'est pas bon, j'ai un peu de mal à le mettre en corrélation avec le succès commercial de RedHat.

                        • [^] # Re: GNU/SystemD/Linux

                          Posté par . Évalué à 3.

                          D'ailleurs à ce propos, Fail2Ban et Ossec gèrent comment ces logs binaires ?

                          Fail2ban a maintenant une interface journald. je n'ai pas regardé pour Ossec.

                          https://aur.archlinux.org/packages/fail2ban-systemd-journal-git/?setlang=fr
                          https://github.com/fail2ban/fail2ban/pull/82

                    • [^] # Re: GNU/SystemD/Linux

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

                      pour lesquelles 160Ko n'est pas négligeable (taille de mon dossier de log)

                      Je ne sais pas comment tu fais mais le dossier log de mon serveur fait 350Mo (et encore, il y a des trucs compressés) et je dois avoir un visiteur par jour sur mes sites.

                      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: GNU/SystemD/Linux

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

          Si il y a autant de gens qui cherchent à remplacer
          NetworkManager, systemd, udev ou dbus, il faudrai peut-être
          regarder pourquoi.

          bah, systemd est lui même censé remplacé sysvinit, et contrairement à systemd, sysvinit a été remplacé par : openrc, upstart, launchd, smf, parmi tant d'autres.

          Au contraire, j'attends de voir qui remplace udev ou dbus.
          Par exemple, qui utilise eudev, en dehors de gentoo ?
          Et en fait, au vue de l'activité des derniers mois, ou on voitsoit des commits qui sont globalement une synchro du travail de l'original, ou rien à part de la doc, ou sont tout les gens qui veulent remplacer udev ?

          Ou sont tout les gens qui poussent à faire des distros basé sur mdev ? Ou sont les gens qui ont cherché à garder devfsd en vie ? Tout ces howtos pour avoir une distro avec un /dev statique et tout les avantages si innombrale qu'on comprends pas comment on peut s'en passer ?

      • [^] # Re: GNU/SystemD/Linux

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

        Les jolis briquent qu'on peut facilement remplacer. C'est cool, ca fait des jolis graphique pour les powerpoints.

        Et c'est une spécificité des OS Unix, qui permet à l'utilisateur d'adapter son système en fonction de ses besoins, et de ses préférences.

        Il y a toujours quelques choses qu'on gagne, quelques choses qu'on perd.

        C'est ce qui permet d'avoir de la diversité dans un éco-système, pour pouvoir avoir un OS personnalisable selon ses préférences.

        Depuis quand tu peux remplacer […] bash par csh ?

        Tout ces shells ont un dénominateur commun : "sh". Je ne dis pas qu'un script écrit avec les spécificités de bash va marcher avec csh, mais qu'on peut faire des scripts génériques pour toutes les distributions.

        Systemd apporte une coherence inter distribution qui n'existe pas sous Linux. Cela permet a un projet upstream de fournir un .unit qui fonctionnera de maniere optimale sur toutes les distributions.

        Un service sysVinit est déjà compatible avec OpenRC, l'init de Slackware, l'init BSD, et sûrement d'autres. Le système d'init était déjà cohérent entre les distributions. De même que la gestion des logs d'ailleurs (je dis bien entre les distributions).

        Mais bon, il ne faut pas oublier ce qu'est le logiciel libre. C'est un logiciel qui peut etre librement modifie pour etre adapate a SES propres besoins.

        Tu penses honnêtement que quelqu'un qui a un besoin auquel ne répond pas systemd va avoir le temps de se pencher sur son code pour l'adapter, au risque de casser d'autres choses dedans ? Tu ne penses pas qu'il est plus simple de remplacer un logiciel qui ne répond pas à un besoin par un autre, déjà existant, qui y répond ?

        Opera le fait depuis 10 ans.

    • [^] # Re: GNU/SystemD/Linux

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

      J'espère que debian passera à systemd, et sinon, j'utiliserai probablement autre chose que debian, et j'en serai triste.
      Je comprends que Canonical préfèrerait que debian ne passe pas à systemd, voire, pourquoi pas, utilise Mir : l'isolationisme forcené ça coûte cher, et ils voudraient bien partager les coûts.

      • [^] # Commentaire supprimé

        Posté par . Évalué à 7.

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

        • [^] # Re: GNU/SystemD/Linux

          Posté par . Évalué à 5.

          Tiens, en parlant de choix, il y a une date butoir à laquelle Debian a prévu de faire son choix?
          Ou là encore, ils ont le choix…

        • [^] # Re: GNU/SystemD/Linux

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

          J'utilise systemd sous debian, mais pas complètement -init est encore marqué « essentiel » ; Debian, pour l'instant, est dans une phase de transition et de décision.
          En tant qu'utilisateur, j'utilise très souvent le boot et la mise en veille.
          En tant que développeur/admin, la gestion des dépendances et des services qui tournent ou pas est une de mes problématiques, et systemd a une bonne manière d'y répondre.

          Perso je vois systemd comme une extension de Linux en userspace, et à la limite je me demande s'il n'aurait pas été plus facile de faire passer cette pilule dans /usr/src/linux/userspace/systemd.
          Il semble que l'intégration avec systemd soit d'une complexité moindre qu'avec sysvinit qui oblige à fournir des scripts compliqués pour chaque démon (avec des while true, des sleep() etc), et je serais en faveur d'ériger une statue à sysvinit pour tous les services qu'il a rendus jusqu'à maintenant.

          Lennart a fâché les gens en disant que Debian/Freebsd était un OS jouet, ce n'était pas constructif ; n'empêche, je crains que plus Debian gèrera de noyaux différents de la même façon, plus le dénominateur commun sera petit, et moins on pourra avancer dans chacune de ces directions. MS pourrait opensourcer Windows RT, maintenant qu'ils l'ont abandonné, histoire de vraiment scléroser Debian. Et si la direction ne me convient pas, peut-être me prendrai-je une licence Redhat :-)

          • [^] # Commentaire supprimé

            Posté par . Évalué à 3. Dernière modification le 01/12/13 à 14:55.

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

            • [^] # Re: GNU/SystemD/Linux

              Posté par . Évalué à 4.

              Le caractère essential du package sysvinit me semble raisonnable contenu compte tenu de l'historique des unix et la compatibilité à avec l'existant. Rien n'empêche personne d'installer systemd s'il le veut.

            • [^] # Re: GNU/SystemD/Linux

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

              Mhhh intéressant :

              Je suis pour le choix

              suivi de

              Le caractère essential du package sysvinit me semble raisonnable

              Pour les gens qui n'ont pas lu le lien, je le colle :
              "Essential is defined as the minimal set of functionality that must be available and usable on the system at all times, even when packages are in the "Unpacked" state. "

              IE, essential est utilisé pour les trucs qu'on ne peut pas retirer, et qu'on estime donc faire parti de la base sur laquelle on peut s'appuyer. Donc ça impose le support des scripts d'init aux DDs. Le choix oui, mais pas pour les DDs, sauf si par choix on veut dire "faire tout ce que les utilisateurs veulent".

              • [^] # Commentaire supprimé

                Posté par . Évalué à 1.

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

                • [^] # Re: GNU/SystemD/Linux

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

                  Cela veux juste dire que les fonctionnalités de sysvinit doivent être dispo.

                  systemd est compatible avec les script init existant, ce n'est donc pas un problème.

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: GNU/SystemD/Linux

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

              Je ne vois pas l'intérêt d'apprendre un nouveau système qui résout un problème qui ne me concerne pas

              Mais PERSONNE, vraiment PERSONNE, ne t'oblige d'apprendre ce nouveau système.

              Je ne vois pas l'intérêt d'apprendre un nouveau système qui résout un problème qui ne me concerne pas.

              Tu affirmes donc haut et fort que tu fais la maintenance (puisque le fait que les autres ne veulent plus la faire ne te concerne pas), donc rien ne change pour toi quand les autres changent.

              Bref, je ne veux pas qu'il me soit imposer un système quelconque.

              Il est imposé à PERSONNE.

              Que des personnes ne souhaite plus faire les trucs chiants et te les laisse != Imposer (ce ne sont pas tes esclaves, ils sont libres de ne plus faire ce qui te plaisait).

              Le caractère essential du package sysvinit me semble raisonnable contenu de l'historique des unix et la compatibilité à avec l'existant.

              L'idée est de virer cet existant trop chiant à gérer et qui ne répond plus au besoin des gens qui développent.
              Non, ce n'est pas raisonnable.
              On peut aussi dire que le caractère essential de systemd est raisonnable vu que ça simplifie une tonen de trucs pour les mainteneurs, et que rien n'empèche personne d'installer sysinit s'il le veut (et que des gens se font chier à le maintenir).


              Ce qui me va en pleine figure quand je lis ce genre de prose, c'est que les utilisateurs d'un truc gratuit (le libre n'est pas le sujet la) considèrent que les mainteneurs sont leur esclaves, et qu'ils devraient continuer à faire un truc juste parce que cest utilisateurs ne veulent pas apprendre un tout petit truc de différent… Parce que la, personne n'empèche personne, on dit juste "plus avec nous car on a un truc mieux pour nous, vous êtes libre de maintenir si vous avez envie" et les gens considèrent bizarrement qu'on leur impose un truc. Faudra un jour m'expliquer ce qui est imposé.

              • [^] # Re: GNU/SystemD/Linux

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

                je ne vois pas pourquoi tu entres dans le débat vu que tu n'utilises pas de bureau linux, comme tu aimes à le rappeler.

                Là ta position, c'est juste de l'entrisme vis à vis de tes idées génériques (en gros tu te fais chier à faire plusieurs paquets de ton logiciel sous les diverses distributions linux, de cela tu considères que le boulot de maintenance est ingrat et tu prends partie pour systemd alors que je suis sûr que tu ne l'utilises pas et tu n'as pas à en subir les effets).

                Il y a plein de gens qui sont contre systemd et les autres délires de Lennart Poettering, et beaucoup d'entre eux sont des admin système ou des développeurs.

                http://www.linuxadvocates.com/2013/05/systemd-accident-waiting-to-happen.html
                http://lists.debian.org/debian-devel/2012/11/msg00617.html
                http://monolight.cc/2011/05/the-systemd-fallacy/
                http://seife.kernalert.de/blog/2013/05/31/the-systemd-journal-is-a-broken-piece-of-crap/
                http://phoronix.com/forums/showthread.php?73574-OpenSUSE-Not-Everyone-Likes-SystemD&s=a54953c55c66e646efc1093deabc1b55

                Ça ne sert à rien de ressortir le vieil argument « c'est libre, tu peux forker ». Je pense qu'on a encore heureusement le droit de dire que c'est de la merde et qu'on ne voit pas d'un bon oeil le fait de voir de moins en moins d'alternative à cette merde.

                « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

                • [^] # Re: GNU/SystemD/Linux

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

                  je ne vois pas pourquoi tu entres dans le débat vu que tu n'utilises pas de bureau linux, comme tu aimes à le rappeler.

                  Oh c'est vrai, excuse-moi, il faut "en être" à 100% (rien d'autre sur aucune machine) pour avoir le droit de parale.
                  Conneries.
                  Sans compter que tu sais effectivement ce qu'est mon OS principal, mais n'a aucune idée de ce que j'utilise au quotidien (bien que je le dise assez souvent en fait). Principal != tous.

                  Là ta position, c'est juste de l'entrisme vis à vis de tes idées génériques

                  Et ça serait mal?
                  En quel honneur n'aurais-je pas le droit d'estimer que les mainteneurs ont autre chose à foutre que de gérer un vieux truc otut pourri qui bouffe des ressources alors qu'ils ont autre chose à faire à coté? Désolé, mais indirectement ça m'impacte, que ça te plaise ou pas.

                  et beaucoup d'entre eux sont des admin système ou des développeurs.

                  combien d'entre eux sont des developpeur de systèmes d'init? combie nd'entre eux se tapent la maintenance? le reste, on s'en fout.

                  Ça ne sert à rien de ressortir le vieil argument « c'est libre, tu peux forker ».

                  Qu'on ne me sorte pas alors qu'on force quiconque. Ca sert à rien aussi. Ma réponse est uniquement uen réaction à un pseudo-argument "contre" qui ne sert à rien, pour reprendre ta description.

                  Je pense qu'on a encore heureusement le droit de dire que c'est de la merde et qu'on ne voit pas d'un bon oeil le fait de voir de moins en moins d'alternative à cette merde.

                  Tu as le droit, tu remarqueras que j'ai interdit à personne quoi que ce soit. J'ai heuresement tout autant le droit de réagir en disant que tu (et aures) racontes n'importe quoi avec des arguments qui tiennent pas 10 secondes de lecture (Il y a eu suffisament de monde pour démonter les pseudo-arguments des gens qui accusent systemd de tout alors que c'est faux, et qui utilisent encore les arguments malgré le fait qu'on leur a démontré, et "on" n'étant pas moi, que c'est faux, ce qui démontre que l'argument n'est pas pour être objectif mais juste une excuse).

                  Bref, pour paraphraser, on a encore heureusement le droit d'avoir un avis et réagir sans devoir remplir une liste de critères subjective (parce que le nombre de gens qui sont simples utilisateurs du système d'init et ne vuelent pas voir les merdes de l'autre côté, ils devraient aussi être éliminés… facile de faire des filtres subjectifs)

                  Au final, tu peux contre-argumenter plutôt que de tirer sur la personne gratos sans plus d'arguments que ça (j'ai mis "quasi" pour bien noter qu'il y en a… mettre des liens au pif comme ça ne change rien au débat)?

                • [^] # Re: GNU/SystemD/Linux

                  Posté par (page perso) . Évalué à 2. Dernière modification le 01/12/13 à 18:35.

                  http://seife.kernalert.de/blog/2013/05/31/the-systemd-journal-is-a-broken-piece-of-crap/

                  J'en ai lu qu'un (au pif), c'est celui-la. Je n'ose pas lire les autres tellement ce lien est démonstratif de l'énormaité :
                  - faudra un jour arrêter avec le fantasme du tout texte qui est trop bien trop génial et bugue jamais le binaire ça pue. Le gars a de la place (mineur mais quand même, à force de mineur ça fait beaucoup), du CPU (idem) et du temps (les fichiers texte étant super chiant à scripter vu que leur format n'est pas précis et change suivant la distro, trop fun à gérer) en trop, tant mieux pour lui, d'autres souhaitent optimiser.
                  - Il "oublies" étonnament qu'il peut tout mettre en texte à côté si il veut du truc "comme avant" pour se faire plaisir ou "au cas où".
                  - Le pauvre petit a été confronté à un bug. Ben oui, ça existe, même avec des programmes qui écrivent du texte (et qui font du coup du texte 100% illisible autant que journald). ca se corrige, et on passe à autre chose, point.

                  Bref, très démonstratif de l'anti qui va chercher le moindre petit détail et l'agrandir pour justifier sa haine non objective, merci.

                  Je recopie le dernier commentaire de la page :
                  "I just fixed your bug, now you need to find something else to bitch and flame about ;P"

                  • [^] # Re: GNU/SystemD/Linux

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

                    Tu aurais aussi pu cliquer sur le premier, qui pointe sur le 3eme. ( et vers d'autres articles de qualités comme "apt vs yum, what is the best one", et sans doute d'autres )

                    Le 3eme date de 2011, donc ça reste un document qui parle des premières versions de systemd, et qui n'abordent pas les features rajoutés par la suite ( genre les fonctions de sécurités de coupure du réseau, systemd-nspawn, etc).

                    Donc les arguments techniques ( car on va éviter ceux sur "propagande de RH avec tout son argent" en pointant la doc de systemd sur freedesktop , ç'est assez peu convaincant ) sont les suivants suivi de mon rebuttal :

                    • L'argument est assez mal construit. Soit il veut dire qu'il y a déjà des outils come monit/runit, et auquel cas, je dirais que /bin/init le fait aussi, soit il veut dire que la feature est déjà utilisé avant, et auquel cas je dirait qu'il s'agit juste de coder ce qui est utilisé.

                    • "collecting information on daemon crashes". C'est vrai, init ne le fait pas, et dans la philosophie d'avant, c'est fait par le kernel sous la forme de la création d'un coredump quelque part sur le FS. Ce que systemd fait, c'est d'enregistrer le coredump dans journald, et de sauver divers infos. Et ça n'implique pas de ne pas faire les choses à coté si quelqu'un le veux aussi, tout comme systemd n'implique pas de retirer les appels à chroot et/ou setuid bien que le faisant également ( appels parfois mal fait par les daemons, quand le logiciel ne fait pas de chdir avant ou d'initgroups, mais bon, on le saurait si la réécriture du code sans arrêt implique de faire des erreurs de temps en temps )

                    • keeping control with cgroups. L'argument est faible, car pour lui, on a pas besoin d'utiliser les cgroups car on peut juste utiliser les cgroups. Je suppose qu'il veut dire "y a pas besoin d'utiliser les cgroups dans le binaire d'init car on peut juste demander à tout les scripts de le faire directement". Mais la, curieusement, il ne dit pas "good luck making the author conform to a single standard", alors que visiblement, c'est ce qui arriverais.

                    • delayed on demand. La, l'auteur dit que ça sert à rien ( car la ram sur sa workstation est suffisante et/ou la swap sert à ça ), et si jamais ça venait à servir, on peut déjà le faire via xinetd ( car soyons sérieux, inetd est un peu merdique à utiliser, et je mentirais si je faisait la comparaison en le prenant comme base ). Le fait que par exemple xinetd ne supporte pas les sockets unix, le fait que ça supporte pas les scripts d'init classiques, c'est des détails d'implémentation. Détail que personne n'a codé depuis que xinetd existe mais sans doute parce que ça sert à rien ( le fait que cups s'en serve, que X11 sur mac s'en serve et que j'ai une dizaine d'autres trucs sur mon laptop montre peut être que ça sert pas à rien ). L'auteur loupe aussi que ç'est pas juste "économiser de la ram", mais surtout assurer la parallélisation par design.

                    • "dependency based service management". La, le mec semble vivre dans un monde à part, car "on range les choses dans un ordre arbitraire", ça n'a rien à voir avec la gestion de dépendance. Par exemple, la gestion de dépendance, ça implique que la transaction échoue si une dep échoue. Chose que sysvinit ne fait pas. Mais je peux reconnaitre que je voit fort peu d'usage en local ( à part "postfix a besoin que ldap soit up sinon il rejette les mails" et ce genre de choses ). Et bien sur, le mec n'a pas lu la doc de systemd, car l'option --ignore-dependencies existe. Donc la partie sur "l'admin doit pouvoir faire ce qu'il veut" est factuellement incorrect.

                    • la partie sur autofs est light sur les détails. Je ne pige pas exactement ce qu'il veut dire, car je voit moi que les unités sont pour la plupart lancé après local-fs.target, donc le souci ne semble pas vraiment se poser dans mon cas d'usage. Mais bon, je ne m'y connais pas en autofs, à part que autofs sur linux fait jurer mon coloc à intervalles régulier. Je vais donc laisser le bénéfice du doute.

                    • listening on hardware change. Que je sache, ç'est fait via udev. Et donc ça rentre dans "c'est déjà fait ailleurs". Donc c'est un peu creux comme argument, surtout parce qu'il est pas détaillé des masses. Au passage, upstart va bien plus loin que systemd et gère les choses de façons bien plus poussé, comme le montre un des développeurs :
                      http://ifdeflinux.blogspot.fr/2013/04/upstart-user-sessions-in-ubuntu-raring.html ( c'est vers la fin ).

                    • enfin, l'argument qui tue : "dbus, c'est orienté desktop, car c'est dans le nom". Il y a aucun example de ce qu'il propose de mieux comme les sunrpc de nfs, java rmi, ou faire ça en xml-rpc par dessus le réseau, en soap ? Je suis pas sur que ça soit mieux, tout le monde rale sur soap, sunrpc est inutilisé ( et semble un peu compliqué à utiliser ). Mais encore une fois, sans argument, j'aurais tendance à dire que c'est un détail. Après tout, d'autres composants ( nm, upstart, bluez, wpa_supplicant pour ne citer qu'eux) passent aussi par dbus donc ça a une certaine logique de se baser sur ce que les autres font.

                    Donc au final, les arguments sont très discutables. Certains sont incorrects ( le 5 ), d'autres sont assez peu explicites ( le 6, le 8, le 1 ), d'autres sont pas très clairs car ça demande à réutiliser des choses existantes ce qui est le cas ( le 3, le 7 ). Il reste donc le 2 et le 4, à savoir la gestion des crashs, qui n'obligent à rien ( et qui reste une feature pour journald, donc hors du pid 1 ) et la partie sur le démarrage à la demande.

            • [^] # Re: GNU/SystemD/Linux

              Posté par . Évalué à 10.

              Ce qui est différent d'avoir un « contact direct » (ce que je dis, parce que je m'attendais à cette réponse). C'est juste, il est là et tu ne t'en occupes pas. Que cela soit l'un ou l'autre l'utilisateur ne voit rien comme différence notable (avec l'arrivée des SSD, la différence de temps de boot est négligeable).

              Je n'ai pas de SSD. Mais disons que la différence au temps de boot n'est pas mon principal souci (cas particulier?).
              L'utilisateur ne voit pas de différence notable? Tant mieux, c'est que ce n'est pas l'apocalypse annoncée. Perso je ne vois aucune différence notable sauf quand je découvre les logs avec journalctl (note que je les ai encore dans /var/log comme avant aussi…).
              Par contre, même si je me suis inquiété (et m'inquiète toujours) au sujet du fossé qu'on creuse avec les BSD, je ne peux que constater que les mainteneurs de scripts sysV semblent se réjouir en masse de l'arrivée de systemd. Tout le temps qu'ils ne passent pas sur ces fameux scripts peut être passé ailleurs, tout bénéf pour moi aussi!
              Alors systemd n'est plus une alternative parmi d'autres mais la solution alpha? Et bien voilà, ce sera la nouvelle solution alpha qui remplacera l'autre.

              systemd répond à un problème que je n'ai pas. Je ne vois pas l'intérêt d'apprendre un nouveau système qui résout un problème qui ne me concerne pas.

              Faut voir. La maintenance autrement plus facile par les développeurs de la distribution, ce n'est pas ton problème? Je dirais que si, un peu quand même.
              Admettons-le, les scripts shell pour lancer les différents services, ce n'est pas ce qu'on a vu de plus propre dans le monde Unix: les mêmes scripts à quelques détails près sans aucune factorisation de code!

              Bref, je ne veux pas qu'il me soit imposer un système quelconque.

              Je serai limite de mauvaise foi, mais toutes les briques communes des distros t'ont été "imposées", non? Si tu avais découvert le monde Linux en 2014 (ou disons quelques années plus tard, le temps que la transition se termine), tu aurais appris à te servir de systemd dans la foulée du bash et des commandes GNU, non?
              Quand tu as débuté, tu as demandé quelles étaient les alternatives à sysV ou on te l'a imposé?

              • [^] # Re: GNU/SystemD/Linux

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

                Par contre, même si je me suis inquiété (et m'inquiète toujours) au sujet du fossé qu'on creuse avec les BSD

                Je pense que c'est un faux problème.
                SysV n'est pas commun avec *BSD, c'est un truc que GNU/Linux utilise de son côté donc finalement ça n'empire pas la situation existante de ce point de vue.

                Ajoutons que le but de *BSD et de GNU/Linux est d'être compatibles mais pas identiques. Si on veut que chaque système ait son intérêt, il faut des utilitaires par endroit unique et pas seulement un noyau différent. Linux est un noyau très puissant avec de nombreuses fonctionnalités que systemd exploite mais pas SysV, il serait dommage de se priver de certaines fonctionnalités possibles au nom de la sacro-sainte compatibilité.

                Je trouve très dubitatif que l'init soit commun aux *BSD et GNU/Linux car c'est un composant par essence proche du noyau, très bas niveau et assez « anecdotique », il est plus pertinent par contre que les composants de couches supérieurs soient compatibles car c'est là où réside l'utilisation de la machine et non dans les quelques secondes de démarrage.

              • [^] # Commentaire supprimé

                Posté par . Évalué à 3. Dernière modification le 01/12/13 à 22:42.

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

                • [^] # Re: GNU/SystemD/Linux

                  Posté par . Évalué à 3.

                  Combien de fois faudra le répéter ? Systemd fournit un sur-ensemble de sysvinit puisque si t'as besoin de faire des choses plus compliquées que ce que te permet le langage (pas Turing-complet, mais c'est le but !) des unit-files, tu demande à ton unit de lancer un script shell et tu y fais ce que tu veux et c'est tout pareil qu'avant.

                  Par contre, tous les autres qui ont des besoins simples (enfin, les units permettent déjà beaucoup de choses) ont pas besoin d'écrire un programme, toujours le même en plus, pour simplement lancer un autre programme.

                  • [^] # Re: GNU/SystemD/Linux

                    Posté par . Évalué à 4.

                    Vu la facilité à le faire, il doit être possible d'étendre systemd avec Lua :)

                    "La première sécurité est la liberté"

                    • [^] # Re: GNU/SystemD/Linux

                      Posté par . Évalué à 3.

                      au moins, il y a aurais un vrai langage utilisable à la place des scripts shell :)

                      "La première sécurité est la liberté"

                      • [^] # Re: GNU/SystemD/Linux

                        Posté par . Évalué à 1.

                        Moi j'ai toujours dit que le prochain truc que Lennart va péter, c'est les shells, c'est l'étape suivante logique. Mais comme sh, sainul, il va réinventer la roue carrée avec un nouveau truc qui servira pour systemd (et puis après, ça servira de shell dans Gnome Terminal pour pas que les users ils aient à apprendre bash, vous vous rendez compte de la taille de man bash ?). Allez, je vous donne le nom : shd :P

                        • [^] # Re: GNU/SystemD/Linux

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

                          J'aimerais bien un nouveau shell, un truc qui reprendrais certaines idées de powershell mais qui resterait utilisable. Malheureusement, je ne crois pas que ce soit possible sans réécrire toutes les applications et redéfinir les standards Unix. Du coup, demain, ça risque d'être un peu court.

                          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                          • [^] # Re: GNU/SystemD/Linux

                            Posté par . Évalué à 5.

                            je ne crois pas que ce soit possible sans réécrire toutes les applications et redéfinir les standards Unix

                            C'est précisément pour cette raison que je fais confiance à Lennart pour le faire !

                        • [^] # Re: GNU/SystemD/Linux

                          Posté par . Évalué à 5.

                          j'ai toujours dit que le prochain truc que Lennart va péter, c'est les shells, c'est l'étape suivante logique. Mais comme sh, sainul, il va réinventer […] Allez, je vous donne le nom : shd :P

                          D'ailleurs, sur sa machine de travail, Lennart a réinventé la commande ls, et il l'utilise quotidiennement.

              • [^] # Re: GNU/SystemD/Linux

                Posté par . Évalué à 1.

                Admettons-le, les scripts shell pour lancer les différents services, ce n'est pas ce qu'on a vu de plus propre dans le monde Unix: les mêmes scripts à quelques détails près sans aucune factorisation de code!

                Va voir les scripts rc de NetBSD et on en reparle. Sinon il y a de la factorisation de code dans les scripts des distribs Linux.

        • [^] # Re: GNU/SystemD/Linux

          Posté par . Évalué à 1.

          Le système d'init/boot, en temps que d'utilisateur et développeur, je n'ai que très rarement un contact direct avec.

          Si tu as envie que ça reste comme ça, je te déconseille formellement systemd.

        • [^] # Re: GNU/SystemD/Linux

          Posté par . Évalué à -2.

          Je passerai à debian le jour où ils utiliseront pleinement systemd.

        • [^] # Re: GNU/SystemD/Linux

          Posté par . Évalué à 2.

          Le système d'init/boot, en temps que d'utilisateur et développeur, je n'ai que très rarement un contact direct avec.

          Le système d'init et de boot, en tant qu'admin de serveurs, j'y suis confronté tous les jours. Et quand ça ne démarre pas, ce n'est pas toi, le développeur, qui se débrouille pour que la machine reparte. En tant que développeur, tu n'y vois que dalle. Par contre, quand il y a quelque chose qui ne part pas, c'est mon job de chercher à comprendre pourquoi, et je préfère dans ce cas un truc un peu moins "neuneu-friendly (sur un serveur - je précise) mais qui garde une certaine souplesse et une grande simplicité de design. Le système d'init a ses défauts qu' on aurait pu tenter de corriger plutôt que de vouloir tout réécrire from scratch.

      • [^] # Re: GNU/SystemD/Linux

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

        J'espère que debian passera à systemd

        apt-get install systemd

        • [^] # Re: GNU/SystemD/Linux

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

          Le système d'init/boot, en temps que d'utilisateur et développeur, je n'ai que très rarement un contact direct avec.

          Si tu as envie que ça reste comme ça, je te déconseille formellement systemd.

          du pdv de l'utilisateur, je n'ai pas plus de contact qu'avant. L'utilisateur n'a pas de besoin de man systemctl. Même les simples trucs ci dessous je les découvre aujourd'hui.

          http://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet

          après je ne développe pas de démon (vim existe déjà).

        • [^] # Re: GNU/SystemD/Linux

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

          Et aussi modification de la ligne de commande de linux pour le choisir comme init.

  • # résistance au changement

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

    Pour ceux qui ne veulent pas de systemd, y'a toujours la Slackware et les *BSD :)

    • [^] # Re: résistance au changement

      Posté par . Évalué à 5.

      Ce n’est pas de la résistance au changement, de la défiance à la rigueur.

      Les « Linuxiens » sont fier de leur écosystème varié de logiciel, si l’un n’est pas adapté, ils en utilisent un autre, nous avons ainsi un paquet d’applications, de gestionnaire de fenêtre, de gestionnaire de bureau… aujourd’hui des gens bien pensants veulent m’expliquer que pour mon bien, je devrais utiliser Wayland et que comme ça, ça simplifiera tout, puisque c’est lui qui gèrera mes fenêtres et que je n’aurais plus à m’inquiéter. Pareil pour SystemD, on m’explique que ça va uniformiser et que se sera mieux.
      Merci de penser pour moi, mais je sais faire ça seul. Moi je vois d’un mauvais œil cette uniformisation. Tu peux me taxer de « vieux con réfractaire au changement », ça ne changera rien au fait que je trouve ça mauvais pour l’avenir.

      Linux s’est un peu comme l’Évolution, la loi du darwinisme… heureusement, se brave homme n’a jamais essayé d’obtenir une seule espèce de fleur « pour les contrôler tous… ».

      Demain, on nous dira que c’est mal d’utiliser plusieurs lecteur pdf, que c’est mal d’utiliser plusieurs éditeurs de texte ?

      • [^] # Re: résistance au changement

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

        aujourd’hui des gens bien pensants veulent m’expliquer que pour mon bien, je devrais utiliser Wayland et que comme ça, ça simplifiera tout, puisque c’est lui qui gèrera mes fenêtres et que je n’aurais plus à m’inquiéter. Pareil pour SystemD, on m’explique que ça va uniformiser et que se sera mieux.
        Merci de penser pour moi, mais je sais faire ça seul

        Non, c'est juste que les distributions perdent beaucoup de temps et d'énergie pour rien à gérer SysV et les développeurs de Xorg veulent simplifier l'architecture d'un logiciel dont les méandres génèrent des bogues insolubles et des évolutions difficiles.

        Le code de X.org et de l'init classique sont disponibles, tu es libre de poursuivre le boulot mais c'est un travail fastidieux dont plus grand monde ne cherche à produire au profit d'autres plus attractifs. des espèces apparaissent et d'autres meurent avec l'évolution, et tant que systemd et Wayland n'auront pas des concurrents potables, ils seront dominants oui.

        Uniformiser a du bien aussi, il y a des tâches que les distributions font chacun dans leur coin pour rien pour un gain nul alors qu'en centralisant un peu on pourrait gagner du temps (beaucoup de distributions manquent de bras) mais aussi en possibilité et qualité. cela ne signifie pas qu'il faut totu mettre en commun mais ce qui est pertinent et les scripts init entrent dans ce cadre (le script à la Debian ou à la Fedora c'est du pareil au même, mais chacun a son bogue et personne n'a mieux ce qui double l'effort…). Systemd et Wayland sont des réponses à ces problèmes mais d'autres peuvent les supplanter si le cœur en dit à leurs détracteurs.

      • [^] # Re: résistance au changement

        Posté par . Évalué à 5.

        Tu mets les briques systèmes et les applications/DE (qui vivent dans les couches supérieurs) au même niveau, alors que ça n'a rien à voir.

        systemd et wayland sont des briques systèmes donc y'a intérêt à les uniformiser. Déjà pour uniformiser les API, ensuite pour éviter de se mettre pas mal de monde à dos (ceux qui écrivent des pilotes graphiques pour wayland, ceux qui écrivent des services/daemons pour systemd)

        D'ailleurs :
        On a plusieurs API pour le son dans le noyau ? Non, il n'y a que ALSA (et à la limite une couche de compatibilité avec OSS).
        On a plusieurs kernels ? Non, il n'y a que Linux.
        On a plusieurs système de TTY ? Non, il n'y a que l'implémentation fournie par le noyau.
        On a plusieurs implémentations d'OpenGL, juste histoire d'avoir le choix et de multiplier les bugs ? Non, y'a pas grand chose à part mesa.
        On a plusieurs implémentations d'initrd ? bah non.
        On a plusieurs manières de rendre une application accessible à l'utilisateur moyen dans son DE ? Bah non y'a pas grand chose à part les fichiers .desktop
        etc…

        Et l'uniformité au niveau du système de base, c'est bien pour les développeurs, et par conséquent les utilisateurs. Ça leur évite de fuir Linux. On a déjà trop de systèmes d'init (openrc, upstart, systemd, sysv, tout ça pour quoi ?), trop d'APIs pour la même chose (ALSA vs OSSv3 vs OSSv4, par exemple. Heureusement il y a des wrappers comme OpenAL ou la SDL ou PulseAudio-le-wrapper-universel, mais ça rajoute forcément de la latence).

        D'ailleurs la réponse est là : plein de distributions y passent à systemd ou y sont déjà passés (Archlinux, Fedora, RHEL, …), et Wayland est désigné comme étant le successeur de Xorg par beaucoup de distributions (à part Ubuntu, même si c'était le cas il y a pas si longtemps), avec une phase de transition (serveur XWayland).

        systemd et wayland vont-ils faire disparaître les dizaines de lecteurs PDFs, et imposer evince par exemple ?
        Non, parce que ça n'a aucun rapport avec la choucroute.

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

      • [^] # Re: résistance au changement

        Posté par . Évalué à 6.

        Sérieusement, pas quelle brique plus adaptée à certains besoins tu remplaces xorg chez toi aujourd'hui?

        Est-ce que tu as testé tous les systèmes d'init de ta distro avant d'en choisir un suivant les avantages et inconvénients, ou est-ce que tu utilises celui fourni par défaut?

        Je crois que changer mon lecteur PDF aura bien plus d'impact sur mon quotidien que la migration de ma distro vers systemd…

      • [^] # Re: résistance au changement

        Posté par (page perso) . Évalué à 4. Dernière modification le 02/12/13 à 07:11.

        aujourd’hui des gens bien pensants veulent m’expliquer que pour mon bien, je devrais utiliser Wayland et que comme ça, ça simplifiera tout, puisque c’est lui qui gèrera mes fenêtres et que je n’aurais plus à m’inquiéter. Pareil pour SystemD, on m’explique que ça va uniformiser et que se sera mieux.

        100% faux, à force c'est du mensonge…
        Le gens expliquent que pour leur bien ils font ce qui leur convient pour avoir ce qu'il y a de meilleur de leur point de vue. Libre à toi (c'est libre) de faire ou sponsoriser une autre distro qui va se faire chier avec les vieilleries si tu penses que ta vision est meilleure.

        Merci de penser pour moi,

        Pourquoi on penserai à toi? Les autres ne sont pas tes esclaves.


        au final, je constate juste une chose : des gens pour se plaindre, mais pas foule pour se bouger le cul. J'adore l'argument "oui mais Slack". Génial : 0.00001% de part de marché de Linux ne veut pas de systemd, quel argument percutant! Tous vos "arguments" tendent à montrer que systemd répond à un besoin, et que le problème est juste que vous ne trouvez pas d'esclaves qui font un boulot pour vous (eux n'en n'ont plus besoin, pourquoi le feraient-ils?)

        Vous êtes très nombreux (ok, pour de faux, en pratique je sais qu'il y a toujours plus de monde pour se plaindre que pour dire qu'ils sont contents) à vous plaindre, je trouve étonnant qu'aucune distro majeure (non, Ubuntu ne compte pas, eux c'est juste qu'ils aiment tout refaire et se plaindre ensuite que personne ne les suit) ne se dise pas que systemd est pourri.

        Et un truc que je ne comprend pas : Ubuntu est la pour vous sauvez, vous avez le choix, où est le problème?
        Le problème est-il qu'une distro qui fait le choix de ne pas avoir systemd fait aussi d'autres mauvais choix techniques qui vous dérangent?

        • [^] # Re: résistance au changement

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

          Vous êtes très nombreux (ok, pour de faux, en pratique je sais qu'il y a toujours plus de monde pour se plaindre que pour dire qu'ils sont contents) à vous plaindre, je trouve étonnant qu'aucune distro majeure (non, Ubuntu ne compte pas, eux c'est juste qu'ils aiment tout refaire et se plaindre ensuite que personne ne les suit) ne se dise pas que systemd est pourri.

          Ce serait pas la première fois qu'on voit les gens changer d'avis. Par exemple Hal : ah ouais trop de la balle on va faire une abstraction pour le matériel. Quelques années plus tard : Hal ça pue on va faire udev…

          Je dis ça…

          les pixels au peuple !

          • [^] # Re: résistance au changement

            Posté par . Évalué à 3.

            C'est justement ce que je reproche au monde Linux : vouloir toujours tout changer et tout révolutionner, puis se rendre compte que ce n'était pas la bonne solution ensuite puis rechanger pur un autre truc qui marche moins bien, et HAL est un exemple flagrant. Les scripts rc de NetBSD sont un exemple de propreté et de factorisation de code qui montre que des scripts, ce n'est pas si pourri que ça.

            • [^] # Re: résistance au changement

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

              Donc en gros tu dis que tout ce que Linux a fait depuis des lustres c'est pas bien… Et bizarrement, c'est à ce moment-la que Linux a explosé en part de marché. Et après, tu vas nous dire qu'à cause de systemd, Linux sur les serveurs va chuter? ha ha ha… Tu t'enfonces tout seul…

              Ce que tu reproches en fait, c'est que le monde bouge plus vite que toi et que ce qui a du succès est quelque chose que tu n'aimes pas.

              • [^] # Re: résistance au changement

                Posté par . Évalué à 1.

                Donc en gros tu dis que tout ce que Linux a fait depuis des lustres c'est pas bien… Et bizarrement, c'est à ce moment-la que Linux a explosé en part de marché.

                Enlève tes oeuillères : je ne parle pas de tout. Ou alors je me suis mal exprimé, ce qui est possible.

                Et bizarrement, c'est à ce moment-la que Linux a explosé en part de marché.

                Tout simplement parce que entre une station ultra5 + Solaris à 25000 F et un PC + Linux à 10000F le choix est vite fait. Ce n'est pas parce que Linux faisait mieux que les autres, au contraire dans certains cas, il faisait moins bien, mais les DSI s'en sont accomodés pour de petits serveurs qui autrefois étaient gérés par des machines Unix bas de gamme mais qui coutaient quand même très cher. Linux sur les grosses infras critiques, c'est relativement récent.

                Et après, tu vas nous dire qu'à cause de systemd, Linux sur les serveurs va chuter? ha ha ha… Tu t'enfonces tout seul…

                Il restera cantonné aux petits serveurs et aux petites VM, et perdra les parts qu'il est en train de gagner sur les trucs un peu plus musclés. Ou alors ce sera une distrib adaptée, comme on en voit sur certains clusters spécifiques, pour lesquels il faudra payer cher une prestation d'adaptation/maintenance. Et les systèmes que je cotoie tous les jours qui aujourd'hui tournent sous AIX/Solaris resteront sous AIX/Solaris parce que le cout d'adaptation/maintenance du Linux ne sera pas rentable.

                • [^] # Re: résistance au changement

                  Posté par . Évalué à 6.

                  Tout simplement parce que entre une station ultra5 + Solaris à 25000 F et un PC + Linux à 10000F le choix est vite fait.

                  C'est quoi ca F comme unite ? :-D

                  • [^] # Re: résistance au changement

                    Posté par (page perso) . Évalué à 3. Dernière modification le 03/12/13 à 07:02.

                    Une résistance au changement?
                    (désolé…)

                    N'empèche, je serai curieux de voir une station ultra5 datant d'avant le 1er Janvier 2001 encore en prod' et maintenue par son fournisseur (pareil pour un Linux d'avant 2001), 2001 étant l'année de disparition du F (il y a quasi 13 ans…).

                    • [^] # Re: résistance au changement

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

                      2001, c'est aussi l’apparition d'un certain Windows XP. Quasi 13 ans certes, mais encore pas mal en prod (malheureusement).

                      Ça ne nous rajeuni pas. :)

                      There is no spoon...

                      • [^] # Re: résistance au changement

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

                        A noter que certes Solaris ne suit pas (le Solaris de 2001 = v8 étant officielement mort début 2012), mais HP-UX tient encore le high-score (la version de 2001 = v11i tenant jusqu'à encore fin 2015, soit quasiment 2 ans de plus que WinXP si Microsfot ne cède pas à la demande insistance de maintenir WinXP plus longtemps), après HP-UX v11i est sans doute moins en prod que WinXP :) (et surtout, c'est un OS "client", type qui n'a pas l'habitude d'être supporté aussi longtemps, les grande durée étant pour les serveurs).

                        Oh oui, la veillesse nous rattrape…

                • [^] # Re: résistance au changement

                  Posté par . Évalué à 8.

                  Si je ne m'abuse, à l'époque, le choix ne s'est pas fait sur FreeBSD, NetBSD, OpenBSD.
                  Le choix a été Linux.

                  En dehors de la licence, les caractéristiques sont d'un côté le développement est très dynamique, ce qui veut dire qu'on rajoute et on balance des trucs assez vite.
                  Du côté des BSD, l'approche est plus conservatrice (sans connotation péjorative aucune). On n'aime pas casser et on n'aime pas les révolutions.

                  Ma conclusion c'est que je ne crois pas une seule seconde que systemd puisse être déclaré "cause de pertes de parts de marché". Ça sonne comme une excuse à la con par un manager qui rate ses objectifs, ça.

          • [^] # Re: résistance au changement

            Posté par (page perso) . Évalué à 2. Dernière modification le 02/12/13 à 12:30.

            Ce serait pas la première fois qu'on voit les gens résister au changement, et après quelques années plus personnes n'en parle, les gens ayant oublié et ceux qui étaient contre se gardant bien de rappeler qu'ils étaient contre. Par exemple… Euh… le droit de vote des femmes? (oui, je prend un gros exemple de la France arriérée qui a été en retard sur ce sujet, tout comme elle est en retard sur la mariage homo qui ressemble aussi au mariage blanc/noir pas bien, j'ai la flemme pour le software car justement on oublie et puis j'aime troller)

            Je dis ça…

            • [^] # Re: résistance au changement

              Posté par . Évalué à 3.

              Aucun rapport : restons dans la technique STP. Je ne suis pas résistant au changement, mais je n'aime pas le changement pour le changement. Il y a des changements assez réussi (on peut par exemple parler des changements sur l'ordonnanceur du noyau par exemple), /proc et /sys sont de bonnes idées (je ne dis pas que c'est parfait, notamment je trouve que les arborescences sont parfois complexes à retenr dans /sys et une commande faisant la modif au bon endroit serait parfois utile). Quitte à changer le système d'init, j'aurais préféré que ce ne soit pas aussi brutal, et qu'on s'attaque aux vrais problèmes. Là je vois urtout un gars qui a envie de faire parler de lui (et ça marche) et qui est parti dans son délire en voulant tout réécrire les fondamentaiux de Linux. En soit ça ne me gène pas, mais qu'il annonce la couleur de suite plutôt que de mentir comme il l'a fait, et qu'il appelle son OS Systemd/Linux et le présente comme une alternative à GNU/Linux. Parce que c'est bien vers ça que l'on va.

              Je trouve l'attitude de Google beaucoup plus clean sur ce point, et Androïd une alternative intéressante à un GNU/Linux

              • [^] # Re: résistance au changement

                Posté par (page perso) . Évalué à 1. Dernière modification le 02/12/13 à 13:09.

                Quitte à changer le système d'init, j'aurais préféré que ce ne soit pas aussi brutal, et qu'on s'attaque aux vrais problèmes.

                Justement, il le fait, jsute que ça ne te plait pas de s'attaquer au problèmes, tu aurais préféré que rien ne change (donc les prolbèmes restent…)

                et qui est parti dans son délire

                C'est fou comme du monde suit son délire… Ou alors c'est pas une délire. Un délire, c'est plutôt des gens qui crachent dessus mais que pas foule ne suit finalement, non?

                , et qu'il appelle son OS Systemd/Linux et le présente comme une alternative à GNU/Linux. Parce que c'est bien vers ça que l'on va.

                Hein? Moi qui croyais que systemd avait besoin de Linux (c'est d'ailleurs un reproche) et que Gnome (GNU Network Object Model Environment) était un projet GNU (alors qu'on critique gnome pour trop dépendre de systemd non?)…
                Foutaises : c'est juste un élément parmis plein d'autres, et ça reste GNU et Linux… Seulement ça ne te plait pas que Linux (les distros) et GNU aillent dans cette direction. Tu veux juste "renommer" car la direction ne te plait pas, mais dommage pour toi, tu n'as aucun pouvoir de décision dessus vu que tu ne participes pas aux décisions. Que du crachat. Et sans que ça te fasse "tilt"? J'y peux rien, je ne fais que lire et déduire., et j'en reste impressionné.

  • # Juste une question

    Posté par . Évalué à 4.

    Je profite de l'empoignade sur systemd pour poser une vraie question technique :
    Je veux lancer un programme au boot de ma machine, que ce programme renvoi un résultat que je place dans une variable d'environnement, et que cette variable soit accessible par la suite par tout le système.

    Il y a un moyen de faire ça proprement ?

    • [^] # Re: Juste une question

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

      Non.

      Les variables d'environnement sont hérités par les processus fils, pas par les processus parents. Tout au plus, tu peux bidouillé en écrivant /etc/profile ou en faisant des trucs avec pam.

      (ou tu peux faire un module moche dans le kernel pour écraser l'env des softs existants)

      • [^] # Re: Juste une question

        Posté par . Évalué à 4.

        De ce que je comprend, systemd est justement un seul processus qui traite les fichiers de configuration tout seul, à la différence de l'initialisation type System V ou BSD qui lancent des scripts dans des processus différents et qui ne peuvent pas remonter les variables vers init.

        J'espérais donc découvrir la commande magique QuiResoudExactementMonProbleme= qui allait éviter une magouille en plusieurs temps.

        Pas encore essayé, mais je pense maintenant à une première unit qui génère un fichier de conf dans /etc/sysconfig, puis à modifier display-manager.service avec EnvironmentFile= qui pointe vers le fichier en question.

        • [^] # Re: Juste une question

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

          Je pense qu'il serait plus efficace de dire ce que tu veux obtenir comme résultat plutôt que comment tu veux implémenter ce que tu penses être une solution.

          • [^] # Re: Juste une question

            Posté par . Évalué à 2. Dernière modification le 02/12/13 à 20:19.

            Heuuu…

            Avec une précision : par « tout le système » j'entends les programmes que je vais démarrer depuis une session utilisateur.

            • [^] # Re: Juste une question

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

              j'ai lu le truc vu que j'ai répondu.

              Mais pourquoi utiliser une variable d'environnement et pas autre chose comme maniére de transmettre l'information, et entre quoi et quoi. Pourquoi au boot et pas à chaque fois, pour détecter quoi, etc, etc.

      • [^] # Re: Juste une question

        Posté par . Évalué à 1.

        Une solution serait de mettre la variable d’environnement dans le fichier inittab… hélas, init n’a pas de syntaxe pour ça à ma connaissance.
        Syntaxe de inittab

    • [^] # Re: Juste une question

      Posté par (page perso) . Évalué à 3. Dernière modification le 02/12/13 à 15:14.

      Sous Slackware (mais ça doit être adaptable facilement sous une autre distribution), je ferais ça d’abord en ajoutant le code suivant dans /etc/rc.d/rc.local :

      mon_resultat=$(/usr/bin/mon_programme)
      echo "mon_resultat=$mon_resultat" > /var/state/resultats

      Le script /etc/rc.d/rc.local est exécuté à la fin de la séquence de démarrage (sous Slackware, il est vide par défaut — il est précisément conçu pour que l’administrateur puisse y rassembler ses bidouillages) ; ici, il exécute le programme demandé et stocke le résultat (sous une forme sourçable par un shell, c’est-à-dire nom=valeur) dans un fichier quelque part dans /var.

      Ensuite, dans /etc/profile, ou dans un fichier quelconque dans /etc/profile.d (ces fichiers étant sourcés lors de tout démarrage de session), on vérifie la présence du fichier /var/state/resultats, on le source, et on exporte la variable dans l’environnement :

      if [ -f /var/state/resultats ]; then
          . /var/state/resultats
          export mon_resultat
      fi

      (La variable n’est pas accessible depuis tout le système — en particulier, tous les processus démarrés dans les scripts d’init en ignoreront toujours l’existence —, mais elle sera accessible à tous les programmes démarrés depuis une session utilisateur.)

      La présence de systemd (ou d’un autre système d’init non-classique) ne devrait pas changer grand’chose, dès lors qu’on peut insérer un bout de script shell quelque part à une étape du démarrage. Avec systemd, j’imagine qu’il faudra créer une unit uniquement chargée d’exécuter un script dédié.

      • [^] # Re: Juste une question

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

        Avec systemd, j’imagine qu’il faudra créer une unit uniquement chargée d’exécuter un script dédié.

        Pas mal de distribution on une unit systemd qui lance rc.local, donc, ce que tu décris fonctionne aussi sur systemd (c'est peut-être même un comportement par défaut de systemd mais je ne suis pas sûr).

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Juste une question

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

          c'est peut-être même un comportement par défaut de systemd mais je ne suis pas sûr

          Vérification faite (directement depuis l’archive source de systemd-208), c’est le cas : c’est l’unité « rc-local.service », qui exécute par défaut /etc/rc.local (modifiable par --with-rc-local-script-path-start lors de la configuration de systemd).

    • [^] # Re: Juste une question

      Posté par . Évalué à 5.

      Depuis la version 207:

      systemd will no longer pass any environment from the kernel or initrd to system services. If you want to set an environment for all services, do so via the kernel command line systemd.setenv= assignment.

      Et depuis la version 205:

      systemd gained the new DefaultEnvironment= setting in /etc/systemd/system.conf to set environment variables for all services.

      Par contre, si la valeur de ta variable peut changer à chaque démarrage, le plus simple est apparemment d'écrire une unité qui se lance suffisamment tôt et qui utilise la commande set-environment de systemctl.

  • # Un vrai problème ?

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

    Au delà du troll l'auteur du patch semble pointer un vrai problème qui est la présence d'une interface utilisateur complète dans le noyau Linux. C'est l'option CONFIG_VT (activée par défaut sous RedHat et Debian et sur toutes les distributions que je connais).

    Cela sert au noyau à afficher divers messages, à deboguer mais aussi et surtout à ouvrir plusieurs terminaux sur la même machine (ctrl-alt-F1 …).

    L'auteur point du doigt que l'affichage des messages peut se faire de façon beaucoup plus simple avec par exemple fblog et que le débogage du noyau se fait habituellement par port série. Il pointe en outre que cette console dans le noyau pose divers problèmes notamment en terme d'occupation mémoire et de sécurité.

    systemd se propose donc d'offrir un système de console alternatif permettant de désactiver le support des terminaux virtuels du noyau.

    Ce qui est donc en cause ici est avant tout le support des VT dans linux et l'assertion selon laquelle il devraient être gérés en espace utilisateur.

    A noter que Kmscon < http://www.freedesktop.org/wiki/Software/kmscon/> fonctionne déjà sans la couche VT du noyau.

    • [^] # Re: Un vrai problème ?

      Posté par . Évalué à 10.

      Le support des VT dans Linux est un sacre bordel.
      Par exemple, je peux ecrire une appli console qui utilise drm pour gerer un affichage graphique. Par defaut, on ne peut plus changer de VT. Pour fonctionner, l'appli doit
      demander a etre notifie d'une demande de changement de console pour que l'appli console arrete de jouer avec la carte graphics. Et encore la, faut la jouer sympa. Pire, tu peux
      changer de console virtuelle tant que tu changes vers une console text. Pas possible de retourner sous X. Pour retourner sous X, tu dois d'abord lancer ton appli en tant que root pour pouvoir appler drmDropMaster(…) et drmSetMaster(…). Pour resumer:
      - En tant qu'utilisateur simple, il est plus facile de prendre le controle de la carte et bloquer les autres VTs que d'avoir une appli qui s'integre bien dans l'environment.
      - Pour s'integrer correctement, il faut etre root.
      C'est un peu le monde a l'envers. Et c'est ce que le gentil monsieur essaye de corriger avec son travail.

      • [^] # Re: Un vrai problème ?

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

        Donc pour toi les VT sont clairement mal foutus ? C'est une vrai question, j'y connais rien.

        Ça semble pas aberrant de gérer cela en espace utilisateur. Le noyau à priori n'as pas à fournir grand choses de plus que des tty. On a ceci dit du mal à imaginer comment gérer correctement les situations d'urgence. Typiquement l'usage que je vois des VT en mode noyau, c'est le lancement d'un debogueur suite à un panic.

        • [^] # Re: Un vrai problème ?

          Posté par . Évalué à 3.

          L'implementation actuelle des VT dans le kernel est pour moi effectivement mal foutu aujourd'hui. A l'epoque ou ca a ete implemente, cela avait du sens. Par contre je ne dis pas que d'un point de vue theorique on ne pourrait pas gerer les VT dans le kernel. Mais cela reposerai sur pas mal de pre-requis que l'on est pas pret d'avoir avant un moment et le passage par une solution dans l'espace utilisateur semble obligatoire pour l'instant.

          Le premier qui me vient a l'esprit c'est d'avoir une API graphique interne dans le kernel pour que celui-ci puisse controller le changement de context graphique. Faisable si l'on considere seulement les drivers open-source. Mais vu combien de temps il a fallu pour avoir KMS supporte par ces derniers, et que les drivers proprio ne le supportent toujours pas, je pense que l'on peut attendre un moment.

          De plus dans le contexte de la gestion multi-seat qui est gere dans l'espace utilisateur il me semble (j'y connais pas grand chose donc peut-etre je m'avance un peu), il faut une bonne coordination entre les deux. Donc autant avoir tout ca au meme endroit, dans l'espace utilisateur. Et le jour ou tout le monde est content et que l'on se rend compte que finalement, pour certaines raisons apparentes a ce moment la, ca serait mieux d'avoir cela dans le kernel, quelqu'un s'y collera surement.

  • # Singularité

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

    Mais la vraie question, c'est de savoir quand on va atteindre la singularité : le jour où systemd aura plus de features que Gnome, et réciproquement.

  • # Session management

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

    Au passage je vous conseil grandement cette série d'articles de David Herrmann expliquant la gestion des sessions (ainsi que les problèmes soulevés par les nouveaux usages) sous linux.

    http://dvdhrm.wordpress.com/2013/08/24/session-management-on-linux/
    http://dvdhrm.wordpress.com/2013/08/24/how-vt-switching-works/
    http://dvdhrm.wordpress.com/2013/08/25/sane-session-switching/

    Très rapidement, il explique :

    • Que les sessions (textuelles) sont, à la base, basées sur les VT.
    • Que les session graphiques se basent encore sur les VT, mais que d'un coup, on a des softs qui accèdent directement au matériel (carte graphique, clavier, souris) (serveurX)
    • Que ça fout la merde niveau gestion des sessions, des droits et cie.
    • Qu'avec le multi-seat, on a pas de VT sur les sièges secondaires, qu'on est donc obliger de dev un truc pour les remplacer.
    • Donc, si on dev des trucs à coté, pourquoi pas tous remettre à plat est refaire tous ce qui faut comme il faut avec les nouveaux usages pris en compte ?

    Je ne sais pas quel rapport ça a avec les derniers changements cités dans le journal. Mais ça met quand même bien en évidence les limites du système actuel et pourquoi il y a des mecs qui bossent pour pondre du systemd et cie au lieu de garder les trucs "qui marchent déjà" .

    Matthieu Gautier|irc:starmad

    • [^] # Re: Session management

      Posté par . Évalué à 0.

      Après la lecture de ces articles, je suis encore plus persuadé que systemd (enfin ici systemd-logind) est une surcouche, et que tout le travail devrait être fait à un niveau plus fondamental : dans le noyau. Le système entier des sessions semble être un bordel monstre et plus du tout adapté aux besoins d’aujourd’hui. Et mettre une surcouche sur un système qui ne convient plus est vraiment, vraiment une mauvaise chose.

      Vu l'état du truc actuellement, j'espère qu'on finira bien un jour ou l'autre par reprendre le système des sessions de zéro.

      • [^] # Re: Session management

        Posté par . Évalué à 10.

        Oui mais si quelqu'un écrit sessiond, on est reparti pour un tour de Trolls.
        "Quoi? Un mec veut enlever un pan entier du noyau!? Quoi sessiond a plus de 2 binaires et fait un chouia plus que CONSOLE_VT?! Mais c'est une usine à gaz!"

      • [^] # Re: Session management

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

        Vu l'état du truc actuellement, j'espère qu'on finira bien un jour ou l'autre par reprendre le système des sessions de zéro.

        Justement, c'est ce qui est en train d'être fait.

        Le but c'est clairement de virer les VT. C'est même le titre du mail cité dans le journal : "Bugfixes for CONFIG_VT=n". Les nouvelles fonctionnalités sont là pour virer les VT.

        Que David Herrmann explique sur son blog que son système de gestion reste compatible avec les VT (voir les améliore) c'est compréhensible (voir nécessaire) mais le but in fine c'est de virer les VT.

        Et systemd étant un daemon qui gère le système, il a toute légitimité pour gérer les sessions.

        Je m'avance peut-être mais j'ai vraiment l'impression que c'est un changement qu'on voit un peu à tous les niveaux.

        • Au niveau kernel, on est récemment passé au rendering/display nodes. L'idée étant de séparer le rendu (GPU) de l'affichage (port hdmi, raster). On peut donc avoir des applis qui gèrent l'affichage (résolution) et des appli qui font du rendu (3D) avec une gestion des droit plus saine.
        • An niveau Wayland, on prévoit d'avoir des compositeurs système. Pour simplifier : un compositeur spécialisé dans l'affichage d'une appli fullscreen (typiquement un compositeur de session).

        Quand je regarde ces changements j'ai justement l'impression qu'on est complètement en train de remettre à plat la gestion des sessions (notamment graphiques), des droits niveau accès matériel et autres…
        Bizarrement il y a plein de gens qui râlent parce que systemd et wayland, ça fait pas la même chose qu'avant…

        Matthieu Gautier|irc:starmad

        • [^] # Re: Session management

          Posté par . Évalué à 2.

          Juste pour preciser: Virer la gestion des consoles virtuelles du kernel. Pas pour virer purement et simplement le principe des consoles virtuelles.

  • # Next troll

    Posté par . Évalué à 3.

    Bon, et bien, il a remis ca, un nouveau truc dans systemd, systemd-su ! J'attend avec impatience le prochain journal et sa fournee de troll de compete. On va encore rire.

Suivre le flux des commentaires

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