• [^] # Re: Le vendredi c'est permis.

    Posté par (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 10.

    bon nombre de technologies flaguées "experimental" dans le noyau

    comme ?

    DBus utilise les sockets. Du moment que vous avez les droits
    root, une version custom de DBus avec tracages des paquets
    et la logique de désérialisation - ca n'est pas plus dur à
    suivre qu'un socket non DBus.

    tu bullshites un peu ( comme d'hab ). Y a dbus-monitor, fourni de base, pas besoin de version custom.

    Mais sur systemd avoir un /usr séparé fonctionne très bien (sauf
    en double montage - mais que personne n'arrive à faire marcher.
    Je vous jure, si, si)

    Oui, ça marche, si tu fait monter le /usr par l'initrd. D'ailleurs, c'est la raison de l'unification de /bin et /usr/bin, refaire un /usr commun pour plusieurs containeurs.

    En ce qui concerne l'ajout d'un serveur DHCP dans l'init,
    c'était obligatoires. Parceque des raisons

    Visiblement, tu as oublié de te relire ici, tu as oublié un 's' en trop dans ta précipitation et tu as oublié le lien vers le post qui donnent une raison. Heureusement, il y a des gens qui suivent pour te corriger:

    https://plus.google.com/+TomGundersen/posts/ht4nn9jHbAR

    Encore faux, systemd peut parfaitement renvoyer le contenu de
    journald sur syslog si vous tenez tant que ça à doubler les
    I/Os.

    Si je peux me permettre (c'est une formule de politesse), tu fait encore preuve d'imprécision (on t'en veux pas, on peut pas passer sa soirée sur un commentaire et savoir de quoi on parle), la page de man (c'est la documentation sous Unix, si tu connais pas) semble indiquer que si tu ne fait pas un repertoire /var:log/journal, alors rien n'est écrit sur le disque par journald. Donc je ne suis pas sur que les I/Os soient doublé, sauf si tu configures mal ton systéme aprés ne pas avoir lu la page de man.
    Reference :
    http://www.freedesktop.org/software/systemd/man/systemd-journald.service.html

    "By default, the journal stores log data in /run/log/journal/.". Comme /run est un tmpfs, ça fait pas d'I/O sur le disque (sauf si tu configures /run pour ne pas être un tmpfs, cad sauf si tu fait exprés de rendre les choses moins performantes).

    Tu peux aussi filer à syslog et envoyer ça vers splunk/logstash ou autre. Enfin, ça, c'est pour les admins avec du pognon et ou des infras plus conséquentes.

    Honnêtement on ne peut pas porter systemd ailleurs.

    Visiblement, en 4 ans, personne n'a tenté, et encore moins réussi. Donc soit c'est pas faisable et Lennart a raison, soit ça intéresse personne, et Lennart a raison de pas perdre de temps dessus. Dans les 2 cas, il a raison.

    Nous on a un système centralisé ou pour lancer une copie d'un
    service qui tourne déjà avec d'autres paramètres il faut
    copier un template

    Non, tu fait le fichier et un include.

    , le linker symboliquement, l'enregistrer, et finalement
    l'initialiser (éventuellement avec des scripts pre et post
    traitement) via des commandes DBus et/ou systemctl.

    Faire un lien, comme sur gentoo et openrc ? C'est vrai, je me souviens des cris des gens quand on a dit "oui, faut faire un lien d'un script d'init pour en lancer plusieurs exemplaires, puis il faut connaitre le nom du nouveau script, puis taper 1 commande par script à lancer, comme c'était long. les gens ont râlés de partout à dire que Gentoo ne marcherais jamais avec un système si fastidieux. Je me souviens des gens envoyant des menaces à Daniel Robbins, etc.

    Mais bon, je doit reconnaitre que ta mauvaise foi est distrayante, et ça change des fois ou tu as affirmé (je cite) que RHEL sortirais mi-2013 (supposition de ton chapeau), en envisageant sérieusement de ne pas mettre systemd. Comme tu as la mémoire courte (vu le nombre conséquent d'oubli à chaque fois), je te remets le lien:

    https://linuxfr.org/nodes/96086/comments/1401229

    Au final c'est pas bien connu, mais il me semble que les distributions serveurs (comme Suse Entreprise ou Red Hat) envisagent très sérieusement de ne PAS passer à systemd. En tout cas pas tout de suite.
    

    En fait, ils envisagent tellement de revenir en arrière qu'il reste que 3 scripts d'init dans la version finale de RHEL 7.