je suis assez surpris que ça bloque journalctl. Sur ma RHEL 7, un strace montre que ça ouvre directement le fichier journal, donc je voit pas vraiment comment un crash de systemd va impacter ça.
Je vois bien d'autres façons dont ça peut faire chier ( exemple, le démarrage à la demande de sshd qui marcherais sans doute plus ), mais ça n'a pas l'air d'être ce que tu décris.
Quand a bloquer reboot, je pourrais imaginer un fallback qui fait un echo 'b' dans /proc, mais ça peut être bloqué aussi. Ou juste l'appel reboot en direct.
Ceci dit, dans le cas de musl, c'est simplement que systemd utilise du code de la glibc, et les gens de musl veulent pas rajouter le code dans leur libc ( pour rester minimaliste ) , et les gens de systemd veulent pas dupliquer le code de la glibc dans leur projet ( car la copie de code, c'est mal ).
Je comprends le point de vue des 2, mais dans une optique de factorisation du code, je donnerais raison aux gens de systemd. Une solution serait peut être de faire un 3eme projet "compat-libc" qui rajoute les fonctions que musl refuse d'ajouter, quitte à linker différemment.
Mais bon, les gens préfèrent troller plutôt que de faire du code.
Y en a parfois, c'est juste que c'est masqué sous le FUD et les commentaires sans remarques, et du peu que j'ai réussi à trouver, ce sont pas tant des améliorations que des tradeoffs différents.
En pratique, ils prennent déjà en compte la communauté, sinon, ça serait pas adopté et il n'y aurait pas des patchs. Ensuite quand la remarque ça deviens "je pense qu'il faut tout refaire le logiciel parce que j'accorde plus d'importance à ce point qu'à ce point la", tu peux pas satisfaire tout le monde.
J'ai du mal m'exprimer, ce que je veux dire, c'est que la table des processus est limité à 65000 et des poussières entrées, non ? (en tout cas pid_t est un int sous la glibc, donc 32 bits, donc 2**32 entrées)
Ensuite, que ça soit le dernier truc à tomber, c'est une chose, et encore une fois, je ne doute pas que d'autres trucs tombent avant. J'ai pas fait de remarques sur la taille du process, mais du containers complets, ie avec le reste des process dedans pour estimer à la louche le nombre qu'on peut imaginer lancer avec la ram disponible. Mais encore une fois, c'est de l'estimation, j'ai pas réussi à trouver grand chose.
Et je présuppose aussi d'une archi ou chaque container est lancé par un service séparé, ce qui est pas forcément le cas (docker n'a pas l'air de faire ça, par exemple).
Mais bon, en effet, "64k of process is enough for everybody" :)
Que 'systemd' soit dans les dépôts de Debian malgré sa
philosophie anti UNIX et son code discutable,
Tu peux détailler ce que tu veux dire par "code discutable" ? Car à chaque fois que les gens disent ça, j'ai le sentiment que c'est juste pour trainer dans la boue le projet. Pour une raison inconnue, les gens estiment que pour systemd, la barre doit être plus haute que pour tout le reste, y compris le noyau.
Exemple, les devs refusent des patchs, c'est des gros dictateurs. Linus le fait, c'est un génie qui défend sa vision sans la moindre erreur. Les critiques sont systématiquement sur Lennart, même quand c'est GKH qui pousse kdbus. Le design est examiné en détail, alors que tout le monde se fout du reste.
Donc j'ai quand même le sentiment que les gens répètent des trucs sans se justifier, juste pour convaincre d'autre personnes qui n'ont pas les compétences pour juger.
En général, quand je dit ça, les gens sortent le bugzilla de freedesktop, sans prendre la peine de donner des chiffres pour comparer le nombre de bugs par rapport à d'autres projets, ou donne les CVE, pareil sans donner de chiffres moyens.
Et pour cause, car si on regarde la mise à jour d'un paquet du kernel, on voit que les CVE et les bugs sont la et sont corrigé, donc donner des chiffres ne serait pas vraiment productif, sauf à dire "le kernel aussi est buggué", ce qui entrainerais un blocage. Donc plutôt que de parler de chiffres en bon ingénieur, on utilise un argument d'autorité, et on ressasse sans arrêt sans se remettre en cause.
Donc, suite à ça,j'ai regardé à gauche à droite, mais j'ai pas la prétention de tout piger d'un coup, donc si je dit une connerie, faut le dire :).
Donc l'idée, est d'avoir un processus lancé par init, et ce processus, via un appel système, devient un "init local". Comme ça veut rien dire, j'explique. par init local, j'entends un processus en charge de recevoir les signaux des orphans, tout comme init, et qui chope les zombies pour les tuer, ce qui semble éviter les cgroups pour suivre les process, et ce qui permet de pousser le code en dehors du pid 1.
C'est une approche intéressante, mais ça veut pas dire une occupation doublé dans la table des processus ?
Genre si je lance 10 000 containers, je vais avoir 10 000 processus de supervision. C'est pas un souci en temps normal et pas un souci pour tout de suite ( voir même un souci pour jamais peut être ), mais si tu imagines 100 Mo par containers, ça va te faire 1T de ram pour 1000 ( ce qui est faisable ), donc on est pas loin du stade ou ça va AMHA poser souci ( genre vers les 10000/20000 ). Bien sur, avec un systéme comme ksm, et avec des containers plus petits, ça peut arriver vite.
Ensuite, peut être que c'est le cpu et les I/O qui vont tomber en premier donc je me fait des idées.
C'est une bonne remarque, mais ça devient du coup plus compliqué, car la logique de surveillance d'un process est présente 2 fois. une fois dans init et une fois dans smf.
Et comme quelqu'un l'a fait remarquer sur lwn ( http://lwn.net/Articles/623527/ ), le pid 1 pourrait très bien ne rien avoir de spécial, et ne pas planter le kernel en cas de crash ( ou se faire relancer par le kernel ).
Car c'est quand même la plus grande peur des gens "si ça plante, mon système plante", alors qu'en pratique, c'est pas le fait d'être PID1 qui nous mets dans la merde. C'est le fait de planter, PID1 ou PID50, à partir du moment ou il gère l'état des processus.
Donc faire 2 trucs, ça sert à juste à rajouter de la complexité. Si SMF se vautre, je suis spas sur d'imaginer l'état du système après ( sauf à avoir l'info poussé dans le kernel sous une forme quelquconque, genre l'équivalent des cgroupes avec des metadonnés , et à ce que smf reprenne l'info du kernel quand ile st relancé, mais on arrive à un truc encore moins portable et poussé dans un truc plus critique depuis l'userspace dans le kernel, alors qu'on essaye surtout l'inverse ).
La mise à jour est global parce que Debian a tardé. Sur Fedora, Arch, Mageia, ça s'est traduit par des mises à jours successives.
C'est bien joli de vouloir attendre pendant 3 ans que le projet se mette en place, mais voila, faut du coup aussi se prendre 3 ans de changements au lieu d'un.
Et la question est pas de "on peut utiliser les cgroups", mais d'une part, est ce que quelqu'un les utilise ( car globalement, y a que openrc et openrc l'a fait après que systemd est commencé ).
Et surtout, est ce qu'on peut tout faire ce que systemd fait via le shell. Et la réponse est "pour la plupart, peut être avec beaucoup de complexité et tout n'est pas possible", cf encore un gros pâté de ma part : https://linuxfr.org/nodes/103677/comments/1569313 ). En gros, il y a des trucs impossibles à faire en pur shell, et comme je conclue mon pâté, tu va te retrouver à faire un bout de systemd dans un start-stop-daemon magique qui fait tout. Autant faire des unités systemd.
Le fichier foo.conf permet de surcharger complétement le fichier monservice.service. Si je veux faire lancer un autre soft, je peux, je donne juste la valeur ExecStart= . Donc oui, ça spécifie plus que l'initscript (pas le logiciel, car le concepteur du logiciel et la personne qui fait l'initscript, c'est en général 2 personnes différentes, l'initscript venant de la distribution en général).
Et Ce que je veut dire, c'est que l'usage des drop-in configuration files (c'est le nom de la chose) permet une gestion plus propre.
Si je rajoute User=toto dans le fichier, ça va agir comme j'avais mis ça dans le fichier de base via une concaténation de tout les fichiers, avec une priorité défini pour savoir qui s'applique en dernier ( en l’occurrence, le fichier dans /etc prends le pas sur celui dans /usr donc la distro qui a /use sous son contrôle mets le défaut et l'admin a le dernier mot, sans interférence du gestionnaire de paquet qui va écraser le fichier ). Et comme c'est juste un fichier à déposer, ça se fait super facilement via ansible ou autre ( ou via un paquet qui dépose le fichier ). A contrario, va faire un modification propre et perenne d'un fichier shell.
Maintenant, peut être que tu fait encore tes configurations à la mano sans passer par puppet/ansible/etc, et que tu as du temps à perdre à vérifier à chaque upgrade que rien n'a changé dans le fichier pour faire une fusion de la modification à la main. Moi non.
Oui, c'est ce que je dit, et du coup, ça devient impossible à lire par un outil automatisé, car il ne va pas comprendre la syntaxe ( exemple augeas, etc ). Alors ensuite, y a plein de gens que ça dérange pas, mais y a des gens chez qui ça pose souci. C'est ce que j'ai dit au passage.
Ça me parait pas très concluant non plus comme division. Je pense qu'il y a une grande part des gens qui font de l'informatique pour leur métier, mais qui voient surtout que ça apporte des emmerdes, qu'on leur crie dessus quand ça ne marche pas, qu'on leur dit à longueur de temps qu'ils sont un cout financier, de façon direct ou indirect. La passion est peut être parti depuis longtemps, ou le temps. Et depuis quelques temps, j'ai le sentiment que l'informatique bouge de plus en plus vite, ne serais que parce qu'il y a un influx d'ingénieurs, une accélération de l'échange d'idée, et des moyens en plus.
Donc il y a peut être des gens qui ont peur de pas réussir à suivre, peur de ce que ça va apporter, et le changement par nature fait peur aux gens, c'est un mécanisme ancré dans notre subconscient. Il suffit de voir que beaucoup de choses ont commencé quand un journaliste a lancé l'idée d'une apocalypse qui vient, ce qui est quand même le summum du fear mongering. De voir que ça a provoqué des réactions disproportionnés pour un sujet technique comme celui la. Et que les gens relaient des informations sans vérifier si c'est vrai ou pas ( l'exemple de systemd et des logs binaires par exemple ). Les gens répètent ce qui confortent leurs peurs pour la propager, car c'est plus rassurant de pas être seul à paniquer.
Un autre exemple, le blog de iguru, totalement non fondé et basé sur des affirmations péremptoires non vérifiables, mais qui alimentent la paranoia.
Ensuite, encore une fois, tout le monde rentre pas dans ce cadre, et y a plein de gens avec un avis plus mesuré, mais masqué par les autres.
Ça dépend comment tu veux les utiliser. Pour limiter les processus en terme de ressources, non, tu as déjà des logiciels existants, tu peux le faire à la main. Systemd automatise cette partie et l'unifie au niveau de la configuration.
Pour ce qui est d'utiliser le tracking des processus, tu peux le faire à la main, mais c'est vite chiant. Donc openrc et systemd peuvent le faire pour toi.
Et le fait que les devs de cgmanager et de systemd se sont réunis pour trouver une solution il y a 2 mois à Dusseldorf pour discutter interopérabilité ( une info qu'on ne relaye pas assez, bien sur, ç'est moins vendeur pour un journal )
Non, parce que NetBSD n'a pas les même performances que linux et
parce qu'il n'a pas le même support (autant matériel que
logiciel).
Certes, mais on peut pas avoir le beurre et l'argent du beurre. La compatibilité a un cout humain, et le temps que tu passes à tester et à vérifier que rien ne casse, c'est du temps que tu passes pas à optimiser et à coder pour du nouveau hardware.
Un exemple stupide. Tu codes ton unix like avec l'infra video du moment, et en l'espace de 5 ans, tout change et il te faut de la 3d partout. Si tu t'occupes de la compatibilité, alors tu va maintenir 2 couches. Si tu t'en fout, alors tu va t'occuper que de la dernière. Et tu va passer plus de temps à rendre la dernière rapide/propre/etc que si tu avais que la moitié ou 75% du temps.
Bien sur, ça n'explique pas tout pour netbsd, mais ça explique une partie.
Et peut être qu'une innovation rapide mais chaotique et cahoteuse à la Linux marche mieux pour avoir le support du hardware et des perfs, ce qui ensuite attire plus de gens, dans un cercle vertueux.
Et en effet, des boites comme IBM, HP, RH font leur beurre sur les demandes de stabilité.
C'est un gros pâté, mais les exemples que je donnent sont vers 75% du texte. l'exemple de bind est facile à piger, mais il arrive sans doute peu en pratique sur une petite installation.
Tu as aussi mon exemple de apache et de sympa ( qui arrive plus souvent ). Ensuite, peut être que tu as accepté le fait que les bugs arrivent, ou que ça marche pas de temps en temps sans savoir pourquoi. D'autres non.
Non, sinon j'aurais dit "je trouve tel truc mieux que /etc/default".
Déjà, /etc/default est pourri car ça reste du shell. Ce qui veut dire que soit tu te limites à la syntaxe FOO="truc" et c'est plus du shell, soit tu mets du vrai shell (genre $() pour lire un truc dynamiquement) et la, ça devient difficile à parser par des outils automatisés (genre ansible/puppet, etc). Ensuite, la flexibilité d'un coté implique la lourdeur de l'autre, je peux comprendre que certains préfèrent la syntaxe de /etc/default pour divers raisons.
Ensuite, avec /etc/default, tu es quand même dépendant de ce que la personne qui a écrit le script a choisi d'utiliser. Par exemple, tu peux souvent pas surcharger proprement la ligne de commande complète du service que tu veux lancer, il te faut lire et trouver la version spécifique du paramètre que tu va utiliser. Paramètres non documentés upstream, bien sur, au contraire des options de démarrage. Parfois, c'est le contraire, tu as juste les options et tu peux faire presque ce que tu veux, sauf si ce que tu veux, c'est d'utiliser un programme avant (chroot foo, nsenter foo, runcon foo).
Donc non, je parle pas de /etc/default. C'est un mécanisme vite limité par rapport à ce que systemd propose et ce que j'utilise. Mais si tu as pas de souci avec et que tu penses que c'est suffisant, pas de souci pour moi.
Alors si tu lances bash -x /etc/init.d/blabla start , c'est pas le daemon que tu examine, mais son script d'init. Le daemon va pas forcement t'afficher grand chose en plus par magie. Et faire ça va avoir des effets de bords comme importer l'environnement de root dans celui du daemon, en fonction du script, ce qui va perturber le debuggage.
utiliser un truc en dev pour de la prod est typiquement une
mauvaise idée.
Systemd a maintenant 4 ans. Y a une branche stable v208 qui est largement stabilisé depuis longtemps. Tu peux me dire quel soft n'est pas en dev dans le libre ?
Et c'est pas aussi à ça que sert le freeze de Debian, à trouver les bugs pour avoir un logiciel utilisable en prod ?
Ce qui m'intéresse, c'est ce qu'il se passe lorsqu'il ne
fonctionne pas.
Il rajoute un message d'erreur dans les logs, comme à peut prêt tout les logiciels du monde. Et il y a assez de résultats sur "debug systemd" pour que la doc ne soit pas un souci. Est ce que tu peux détailler par exemple ce qui t'a manqué quand tu as eu un souci, à part le temps de lire avant ( chose que tu peux faire dès maintenant au lieu de poster sur linuxfr, par exemple )
Non, j'ai trouvé ça aussi comme une grosse simplification, surtout parce que je me retrouve plus dans le barbu hacker avec du bagage technique, et pourtant, je rentre pas dans la case "defend sysvinit".
Ensuite, c'est un essai, le mec a quand même eu une réflexion avec laquelle je suis d'accord sur certains points, même si je pense qu'une autre approche est nécessaire pour comprendre le débat. ( genre, je penche de plus en plus à des problématiques d'ordre social et communautaires plus profondes vis à vis du web, d'educations des gens, et de mythologie du libre ).
Alors moi, j'apprécie déjà d'avoir des trucs plus facile à écrire que les scripts d'init. J'ai par exemple fait mon script pour lancer un serveur irc en perl en 5 minutes juste en le lancant en premier plan. J'ai pas mis très longtemps non plus pour lancer prosody dans docker, bien moins que de faire marcher docker en premier lieu.
J'aime aussi beaucoup journalctl -u, au point que je me perde un peu quand je me retrouve sur des Centos 6 ( on s'habitue vite à la completion et au rangement )
Et j'ai surtout bien aimé de pouvoir mettre un bout de config via /etc/systemd/monservice.d/foo.conf, ça me parait plus perenne pour contourner un bug que l'ancienne façon, ou je devait copier et refaire le script.
Red hat a aussi d'autres contraintes. La ou le fait de rajouter un paquet dans Debian implique pas grand chose sur le long terme, le fait de rajouter un paquet dans RHEL implique d'avoir une vérification des licenses ( et des brevets ), le fait de faire un audit sommaire et/ou poussé de sécurité ( en fonction du paquet, de la criticité, etc ), le fait de s'assurer que le support soit capable de répondre ( donc des formations, de la doc ), d'avoir de la doc, parfois traduite. Et le fait d'avoir des ressources internes pour tester et corriger les bugs. Et faire évoluer aussi le projet.
Et tout ces gens ( car oui, c'est des humains ) ont un cout. Donc les clients ont du poids, mais surtout parce qu'ils payent pour faire le boulot, et avoir des gens est le principal poids bloquant dans le libre, car des idées, on en a tous des tonnes :)
C'est aussi l'occasion d'avoir les mains libres. Bien que je pense que les gens sous estiment les ressources pour faire un fork, je comprends aussi la position visant à avoir au moins un endroit pour rassembler les gens pas contents. Ensuite, je pense que malgré les efforts louables, et au vue de certaines personnalités qui viennent tourner autour du fork, j'ai peu d'espoir dans le dit fork.
Mais Debian va réussir à se débarrasser d'une partie de sa communauté ( genre tout les gens qui ont poussés les gens à partir du projet ces dernières semaines ), et ça ne peux pas être plus mal.
En pratique, upstart n'etait pas compatible inittab non plus et y a eu 0 personnes qui ont ralés pour ubuntu et rhel6.
En pratique aussi, rajouter un outil qui lit inittab et qui donne une unité systemd, ç'est assez trivial, je penche pour une après midi de boulot. Le fait que personne ne se charge de le faire depuis 4 ans laisse penser que ça intéresse pas grand monde en pratique.
Ah Joerg Reisenweber , aka doc_scrutinizer. Un mec incapable de garder son calme bien longtemps et de ne pas se lancer au mieux dans des diatribes sur irc, au pire de commencer à insulter les gens.
Il est sans doute compétent d'un point de vue technique, mais du peu que j'ai vu sur le canal du projet openmoko au fil des ans, il m'a pas donné envie de contribuer, plutôt de fuir
Dans le même genre, j'ai vu un autre Joerg bien connu venir sur leur irc, le renommé développeur de cdrtools, visiblement encore vexé par cdrkit ( en 2006 ).
Je m'attends à tout moment de voir ESR débarquer avec un tshirt "Theo for président" pour conseiller le projet sur la manière de rassembler une communauté saine ou les insultes ne volent pas.
[^] # Re: Fonctionnalités clées.
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 2.
je suis assez surpris que ça bloque journalctl. Sur ma RHEL 7, un strace montre que ça ouvre directement le fichier journal, donc je voit pas vraiment comment un crash de systemd va impacter ça.
Je vois bien d'autres façons dont ça peut faire chier ( exemple, le démarrage à la demande de sshd qui marcherais sans doute plus ), mais ça n'a pas l'air d'être ce que tu décris.
Quand a bloquer reboot, je pourrais imaginer un fallback qui fait un echo 'b' dans /proc, mais ça peut être bloqué aussi. Ou juste l'appel reboot en direct.
[^] # Re: Fonctionnalités clées.
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 6.
Il t’empêche pas de l'appliquer sur ton build.
Ceci dit, dans le cas de musl, c'est simplement que systemd utilise du code de la glibc, et les gens de musl veulent pas rajouter le code dans leur libc ( pour rester minimaliste ) , et les gens de systemd veulent pas dupliquer le code de la glibc dans leur projet ( car la copie de code, c'est mal ).
Je comprends le point de vue des 2, mais dans une optique de factorisation du code, je donnerais raison aux gens de systemd. Une solution serait peut être de faire un 3eme projet "compat-libc" qui rajoute les fonctions que musl refuse d'ajouter, quitte à linker différemment.
Mais bon, les gens préfèrent troller plutôt que de faire du code.
[^] # Re: Ou bien ?
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 3.
Y en a parfois, c'est juste que c'est masqué sous le FUD et les commentaires sans remarques, et du peu que j'ai réussi à trouver, ce sont pas tant des améliorations que des tradeoffs différents.
En pratique, ils prennent déjà en compte la communauté, sinon, ça serait pas adopté et il n'y aurait pas des patchs. Ensuite quand la remarque ça deviens "je pense qu'il faut tout refaire le logiciel parce que j'accorde plus d'importance à ce point qu'à ce point la", tu peux pas satisfaire tout le monde.
[^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 1.
J'ai du mal m'exprimer, ce que je veux dire, c'est que la table des processus est limité à 65000 et des poussières entrées, non ? (en tout cas pid_t est un int sous la glibc, donc 32 bits, donc 2**32 entrées)
Ensuite, que ça soit le dernier truc à tomber, c'est une chose, et encore une fois, je ne doute pas que d'autres trucs tombent avant. J'ai pas fait de remarques sur la taille du process, mais du containers complets, ie avec le reste des process dedans pour estimer à la louche le nombre qu'on peut imaginer lancer avec la ram disponible. Mais encore une fois, c'est de l'estimation, j'ai pas réussi à trouver grand chose.
Et je présuppose aussi d'une archi ou chaque container est lancé par un service séparé, ce qui est pas forcément le cas (docker n'a pas l'air de faire ça, par exemple).
Mais bon, en effet, "64k of process is enough for everybody" :)
[^] # Re: Fonctionnalités clées.
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 2.
Qu'est ce qui serait le taf, et le taf dans quel logiciel ou quel os ?
[^] # Re: Les raisons du fork
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 10.
Tu peux détailler ce que tu veux dire par "code discutable" ? Car à chaque fois que les gens disent ça, j'ai le sentiment que c'est juste pour trainer dans la boue le projet. Pour une raison inconnue, les gens estiment que pour systemd, la barre doit être plus haute que pour tout le reste, y compris le noyau.
Exemple, les devs refusent des patchs, c'est des gros dictateurs. Linus le fait, c'est un génie qui défend sa vision sans la moindre erreur. Les critiques sont systématiquement sur Lennart, même quand c'est GKH qui pousse kdbus. Le design est examiné en détail, alors que tout le monde se fout du reste.
Donc j'ai quand même le sentiment que les gens répètent des trucs sans se justifier, juste pour convaincre d'autre personnes qui n'ont pas les compétences pour juger.
En général, quand je dit ça, les gens sortent le bugzilla de freedesktop, sans prendre la peine de donner des chiffres pour comparer le nombre de bugs par rapport à d'autres projets, ou donne les CVE, pareil sans donner de chiffres moyens.
Et pour cause, car si on regarde la mise à jour d'un paquet du kernel, on voit que les CVE et les bugs sont la et sont corrigé, donc donner des chiffres ne serait pas vraiment productif, sauf à dire "le kernel aussi est buggué", ce qui entrainerais un blocage. Donc plutôt que de parler de chiffres en bon ingénieur, on utilise un argument d'autorité, et on ressasse sans arrêt sans se remettre en cause.
[^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 1.
Donc, suite à ça,j'ai regardé à gauche à droite, mais j'ai pas la prétention de tout piger d'un coup, donc si je dit une connerie, faut le dire :).
Donc l'idée, est d'avoir un processus lancé par init, et ce processus, via un appel système, devient un "init local". Comme ça veut rien dire, j'explique. par init local, j'entends un processus en charge de recevoir les signaux des orphans, tout comme init, et qui chope les zombies pour les tuer, ce qui semble éviter les cgroups pour suivre les process, et ce qui permet de pousser le code en dehors du pid 1.
C'est une approche intéressante, mais ça veut pas dire une occupation doublé dans la table des processus ?
Genre si je lance 10 000 containers, je vais avoir 10 000 processus de supervision. C'est pas un souci en temps normal et pas un souci pour tout de suite ( voir même un souci pour jamais peut être ), mais si tu imagines 100 Mo par containers, ça va te faire 1T de ram pour 1000 ( ce qui est faisable ), donc on est pas loin du stade ou ça va AMHA poser souci ( genre vers les 10000/20000 ). Bien sur, avec un systéme comme ksm, et avec des containers plus petits, ça peut arriver vite.
Ensuite, peut être que c'est le cpu et les I/O qui vont tomber en premier donc je me fait des idées.
[^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 3.
Possible, mais si tu peux préciser un peu plus ?
[^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 1.
C'est une bonne remarque, mais ça devient du coup plus compliqué, car la logique de surveillance d'un process est présente 2 fois. une fois dans init et une fois dans smf.
Et comme quelqu'un l'a fait remarquer sur lwn ( http://lwn.net/Articles/623527/ ), le pid 1 pourrait très bien ne rien avoir de spécial, et ne pas planter le kernel en cas de crash ( ou se faire relancer par le kernel ).
Car c'est quand même la plus grande peur des gens "si ça plante, mon système plante", alors qu'en pratique, c'est pas le fait d'être PID1 qui nous mets dans la merde. C'est le fait de planter, PID1 ou PID50, à partir du moment ou il gère l'état des processus.
Donc faire 2 trucs, ça sert à juste à rajouter de la complexité. Si SMF se vautre, je suis spas sur d'imaginer l'état du système après ( sauf à avoir l'info poussé dans le kernel sous une forme quelquconque, genre l'équivalent des cgroupes avec des metadonnés , et à ce que smf reprenne l'info du kernel quand ile st relancé, mais on arrive à un truc encore moins portable et poussé dans un truc plus critique depuis l'userspace dans le kernel, alors qu'on essaye surtout l'inverse ).
[^] # Re: Fonctionnalités clées.
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 6.
La mise à jour est global parce que Debian a tardé. Sur Fedora, Arch, Mageia, ça s'est traduit par des mises à jours successives.
C'est bien joli de vouloir attendre pendant 3 ans que le projet se mette en place, mais voila, faut du coup aussi se prendre 3 ans de changements au lieu d'un.
Et la question est pas de "on peut utiliser les cgroups", mais d'une part, est ce que quelqu'un les utilise ( car globalement, y a que openrc et openrc l'a fait après que systemd est commencé ).
Et surtout, est ce qu'on peut tout faire ce que systemd fait via le shell. Et la réponse est "pour la plupart, peut être avec beaucoup de complexité et tout n'est pas possible", cf encore un gros pâté de ma part : https://linuxfr.org/nodes/103677/comments/1569313 ). En gros, il y a des trucs impossibles à faire en pur shell, et comme je conclue mon pâté, tu va te retrouver à faire un bout de systemd dans un start-stop-daemon magique qui fait tout. Autant faire des unités systemd.
[^] # Re: Fonctionnalités clées.
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 7.
Le fichier foo.conf permet de surcharger complétement le fichier monservice.service. Si je veux faire lancer un autre soft, je peux, je donne juste la valeur ExecStart= . Donc oui, ça spécifie plus que l'initscript (pas le logiciel, car le concepteur du logiciel et la personne qui fait l'initscript, c'est en général 2 personnes différentes, l'initscript venant de la distribution en général).
Et Ce que je veut dire, c'est que l'usage des drop-in configuration files (c'est le nom de la chose) permet une gestion plus propre.
Si je rajoute User=toto dans le fichier, ça va agir comme j'avais mis ça dans le fichier de base via une concaténation de tout les fichiers, avec une priorité défini pour savoir qui s'applique en dernier ( en l’occurrence, le fichier dans /etc prends le pas sur celui dans /usr donc la distro qui a /use sous son contrôle mets le défaut et l'admin a le dernier mot, sans interférence du gestionnaire de paquet qui va écraser le fichier ). Et comme c'est juste un fichier à déposer, ça se fait super facilement via ansible ou autre ( ou via un paquet qui dépose le fichier ). A contrario, va faire un modification propre et perenne d'un fichier shell.
Maintenant, peut être que tu fait encore tes configurations à la mano sans passer par puppet/ansible/etc, et que tu as du temps à perdre à vérifier à chaque upgrade que rien n'a changé dans le fichier pour faire une fusion de la modification à la main. Moi non.
[^] # Re: Fonctionnalités clés.
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 5.
Oui, c'est ce que je dit, et du coup, ça devient impossible à lire par un outil automatisé, car il ne va pas comprendre la syntaxe ( exemple augeas, etc ). Alors ensuite, y a plein de gens que ça dérange pas, mais y a des gens chez qui ça pose souci. C'est ce que j'ai dit au passage.
[^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 2.
Ça me parait pas très concluant non plus comme division. Je pense qu'il y a une grande part des gens qui font de l'informatique pour leur métier, mais qui voient surtout que ça apporte des emmerdes, qu'on leur crie dessus quand ça ne marche pas, qu'on leur dit à longueur de temps qu'ils sont un cout financier, de façon direct ou indirect. La passion est peut être parti depuis longtemps, ou le temps. Et depuis quelques temps, j'ai le sentiment que l'informatique bouge de plus en plus vite, ne serais que parce qu'il y a un influx d'ingénieurs, une accélération de l'échange d'idée, et des moyens en plus.
Donc il y a peut être des gens qui ont peur de pas réussir à suivre, peur de ce que ça va apporter, et le changement par nature fait peur aux gens, c'est un mécanisme ancré dans notre subconscient. Il suffit de voir que beaucoup de choses ont commencé quand un journaliste a lancé l'idée d'une apocalypse qui vient, ce qui est quand même le summum du fear mongering. De voir que ça a provoqué des réactions disproportionnés pour un sujet technique comme celui la. Et que les gens relaient des informations sans vérifier si c'est vrai ou pas ( l'exemple de systemd et des logs binaires par exemple ). Les gens répètent ce qui confortent leurs peurs pour la propager, car c'est plus rassurant de pas être seul à paniquer.
Un autre exemple, le blog de iguru, totalement non fondé et basé sur des affirmations péremptoires non vérifiables, mais qui alimentent la paranoia.
Ensuite, encore une fois, tout le monde rentre pas dans ce cadre, et y a plein de gens avec un avis plus mesuré, mais masqué par les autres.
[^] # Re: Fonctionnalités clées.
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 8.
Ça dépend comment tu veux les utiliser. Pour limiter les processus en terme de ressources, non, tu as déjà des logiciels existants, tu peux le faire à la main. Systemd automatise cette partie et l'unifie au niveau de la configuration.
Pour ce qui est d'utiliser le tracking des processus, tu peux le faire à la main, mais c'est vite chiant. Donc openrc et systemd peuvent le faire pour toi.
Ensuite, dans le futur, le kernel s'oriente vers une architecture avec un seul processus autorisé à gerer les cgroups. Lennart parle sur la liste de systemd de l'impact qu'il y a eu ( http://lwn.net/Articles/555922/ ) et Linux.com explique pourquoi les devs kernels veulent changer ça :
http://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign
Il y a aussi pas mal d'info sur http://lwn.net/Articles/575672/
Et le fait que les devs de cgmanager et de systemd se sont réunis pour trouver une solution il y a 2 mois à Dusseldorf pour discutter interopérabilité ( une info qu'on ne relaye pas assez, bien sur, ç'est moins vendeur pour un journal )
[^] # Re: Ca ne règle pas la source du problème
Posté par Misc (site web personnel) . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 4.
Certes, mais on peut pas avoir le beurre et l'argent du beurre. La compatibilité a un cout humain, et le temps que tu passes à tester et à vérifier que rien ne casse, c'est du temps que tu passes pas à optimiser et à coder pour du nouveau hardware.
Un exemple stupide. Tu codes ton unix like avec l'infra video du moment, et en l'espace de 5 ans, tout change et il te faut de la 3d partout. Si tu t'occupes de la compatibilité, alors tu va maintenir 2 couches. Si tu t'en fout, alors tu va t'occuper que de la dernière. Et tu va passer plus de temps à rendre la dernière rapide/propre/etc que si tu avais que la moitié ou 75% du temps.
Bien sur, ça n'explique pas tout pour netbsd, mais ça explique une partie.
Et peut être qu'une innovation rapide mais chaotique et cahoteuse à la Linux marche mieux pour avoir le support du hardware et des perfs, ce qui ensuite attire plus de gens, dans un cercle vertueux.
Et en effet, des boites comme IBM, HP, RH font leur beurre sur les demandes de stabilité.
[^] # Re: Fonctionnalités clées.
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 6.
Alors je peux, avec une suffisance gonflant mon eog, me citer moi même, quand j'ai pourri Kadalka :
https://linuxfr.org/nodes/97210/comments/1426891
C'est un gros pâté, mais les exemples que je donnent sont vers 75% du texte. l'exemple de bind est facile à piger, mais il arrive sans doute peu en pratique sur une petite installation.
Tu as aussi mon exemple de apache et de sympa ( qui arrive plus souvent ). Ensuite, peut être que tu as accepté le fait que les bugs arrivent, ou que ça marche pas de temps en temps sans savoir pourquoi. D'autres non.
[^] # Re: Fonctionnalités clées.
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 5.
Non, sinon j'aurais dit "je trouve tel truc mieux que /etc/default".
Déjà, /etc/default est pourri car ça reste du shell. Ce qui veut dire que soit tu te limites à la syntaxe FOO="truc" et c'est plus du shell, soit tu mets du vrai shell (genre $() pour lire un truc dynamiquement) et la, ça devient difficile à parser par des outils automatisés (genre ansible/puppet, etc). Ensuite, la flexibilité d'un coté implique la lourdeur de l'autre, je peux comprendre que certains préfèrent la syntaxe de /etc/default pour divers raisons.
Ensuite, avec /etc/default, tu es quand même dépendant de ce que la personne qui a écrit le script a choisi d'utiliser. Par exemple, tu peux souvent pas surcharger proprement la ligne de commande complète du service que tu veux lancer, il te faut lire et trouver la version spécifique du paramètre que tu va utiliser. Paramètres non documentés upstream, bien sur, au contraire des options de démarrage. Parfois, c'est le contraire, tu as juste les options et tu peux faire presque ce que tu veux, sauf si ce que tu veux, c'est d'utiliser un programme avant (chroot foo, nsenter foo, runcon foo).
Donc non, je parle pas de /etc/default. C'est un mécanisme vite limité par rapport à ce que systemd propose et ce que j'utilise. Mais si tu as pas de souci avec et que tu penses que c'est suffisant, pas de souci pour moi.
[^] # Re: Hmm
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 10.
Alors si tu lances bash -x /etc/init.d/blabla start , c'est pas le daemon que tu examine, mais son script d'init. Le daemon va pas forcement t'afficher grand chose en plus par magie. Et faire ça va avoir des effets de bords comme importer l'environnement de root dans celui du daemon, en fonction du script, ce qui va perturber le debuggage.
Systemd a maintenant 4 ans. Y a une branche stable v208 qui est largement stabilisé depuis longtemps. Tu peux me dire quel soft n'est pas en dev dans le libre ?
Et c'est pas aussi à ça que sert le freeze de Debian, à trouver les bugs pour avoir un logiciel utilisable en prod ?
Il rajoute un message d'erreur dans les logs, comme à peut prêt tout les logiciels du monde. Et il y a assez de résultats sur "debug systemd" pour que la doc ne soit pas un souci. Est ce que tu peux détailler par exemple ce qui t'a manqué quand tu as eu un souci, à part le temps de lire avant ( chose que tu peux faire dès maintenant au lieu de poster sur linuxfr, par exemple )
[^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 6.
Non, j'ai trouvé ça aussi comme une grosse simplification, surtout parce que je me retrouve plus dans le barbu hacker avec du bagage technique, et pourtant, je rentre pas dans la case "defend sysvinit".
Ensuite, c'est un essai, le mec a quand même eu une réflexion avec laquelle je suis d'accord sur certains points, même si je pense qu'une autre approche est nécessaire pour comprendre le débat. ( genre, je penche de plus en plus à des problématiques d'ordre social et communautaires plus profondes vis à vis du web, d'educations des gens, et de mythologie du libre ).
[^] # Re: Fonctionnalités clées.
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 9.
Alors moi, j'apprécie déjà d'avoir des trucs plus facile à écrire que les scripts d'init. J'ai par exemple fait mon script pour lancer un serveur irc en perl en 5 minutes juste en le lancant en premier plan. J'ai pas mis très longtemps non plus pour lancer prosody dans docker, bien moins que de faire marcher docker en premier lieu.
J'aime aussi beaucoup journalctl -u, au point que je me perde un peu quand je me retrouve sur des Centos 6 ( on s'habitue vite à la completion et au rangement )
Et j'ai surtout bien aimé de pouvoir mettre un bout de config via /etc/systemd/monservice.d/foo.conf, ça me parait plus perenne pour contourner un bug que l'ancienne façon, ou je devait copier et refaire le script.
[^] # Re: Le choc ?
Posté par Misc (site web personnel) . En réponse au journal Devuan forks Debian: un choc ou c'était inévitable?. Évalué à 2.
Je suis en faveur du CCC
http://www.dailymotion.com/video/x1ivtx_les-nuls-comite-contre-les-chats_fun
[^] # Re: Le choc ?
Posté par Misc (site web personnel) . En réponse au journal Devuan forks Debian: un choc ou c'était inévitable?. Évalué à 5.
Red hat a aussi d'autres contraintes. La ou le fait de rajouter un paquet dans Debian implique pas grand chose sur le long terme, le fait de rajouter un paquet dans RHEL implique d'avoir une vérification des licenses ( et des brevets ), le fait de faire un audit sommaire et/ou poussé de sécurité ( en fonction du paquet, de la criticité, etc ), le fait de s'assurer que le support soit capable de répondre ( donc des formations, de la doc ), d'avoir de la doc, parfois traduite. Et le fait d'avoir des ressources internes pour tester et corriger les bugs. Et faire évoluer aussi le projet.
Et tout ces gens ( car oui, c'est des humains ) ont un cout. Donc les clients ont du poids, mais surtout parce qu'ils payent pour faire le boulot, et avoir des gens est le principal poids bloquant dans le libre, car des idées, on en a tous des tonnes :)
[^] # Re: Pourquoi un fork?
Posté par Misc (site web personnel) . En réponse au journal Devuan forks Debian: un choc ou c'était inévitable?. Évalué à 4.
C'est aussi l'occasion d'avoir les mains libres. Bien que je pense que les gens sous estiment les ressources pour faire un fork, je comprends aussi la position visant à avoir au moins un endroit pour rassembler les gens pas contents. Ensuite, je pense que malgré les efforts louables, et au vue de certaines personnalités qui viennent tourner autour du fork, j'ai peu d'espoir dans le dit fork.
Mais Debian va réussir à se débarrasser d'une partie de sa communauté ( genre tout les gens qui ont poussés les gens à partir du projet ces dernières semaines ), et ça ne peux pas être plus mal.
[^] # Re: Incompatible ?
Posté par Misc (site web personnel) . En réponse au journal Devuan forks Debian: un choc ou c'était inévitable?. Évalué à 7.
En pratique, upstart n'etait pas compatible inittab non plus et y a eu 0 personnes qui ont ralés pour ubuntu et rhel6.
En pratique aussi, rajouter un outil qui lit inittab et qui donne une unité systemd, ç'est assez trivial, je penche pour une après midi de boulot. Le fait que personne ne se charge de le faire depuis 4 ans laisse penser que ça intéresse pas grand monde en pratique.
[^] # Re: trop de bruit pour rien
Posté par Misc (site web personnel) . En réponse au journal Devuan forks Debian: un choc ou c'était inévitable?. Évalué à 3.
Ah Joerg Reisenweber , aka doc_scrutinizer. Un mec incapable de garder son calme bien longtemps et de ne pas se lancer au mieux dans des diatribes sur irc, au pire de commencer à insulter les gens.
Il est sans doute compétent d'un point de vue technique, mais du peu que j'ai vu sur le canal du projet openmoko au fil des ans, il m'a pas donné envie de contribuer, plutôt de fuir
Dans le même genre, j'ai vu un autre Joerg bien connu venir sur leur irc, le renommé développeur de cdrtools, visiblement encore vexé par cdrkit ( en 2006 ).
Je m'attends à tout moment de voir ESR débarquer avec un tshirt "Theo for président" pour conseiller le projet sur la manière de rassembler une communauté saine ou les insultes ne volent pas.