Comme certains se plaignent que les discussions ne sont pas assez techniques ( voir le journal précédent ), et comme le vendredi bat encore son plein, je vais essayer d'apporter ma pierre au redressement productif de la technicité du site.
Donc résumé de la situation ( je ne suis pas assez bon développeur en js, mais si vous pouviez imaginer le texte défiler à la façon d'une franchise disney bien connu, ça ne sera que mieux )
Init wars, épisode III
Par la ruse et la force, l'empire maléfique de Darth Poetter a pris le contrôle des systèmes Mageia, Suse, Arch, Fedora et RHEL, et avec l'aide de sa station de combat "init de la mort" de classe systemd, il s’apprête à s'attaquer à de nouveaux systèmes pour asseoir son hégémonie.
Dans la constellation de la confédération de Debian, les sages du conseil s'interrogent sur le bien fondé de faire une alliance avec l'empire. En effet, la confédération a récemment ouvert des avants postes commerciaux dans la galaxie BSD, avec qui l'empire est est en guerre, et la monarchie d'Ubuntu voit d'un assez mauvaise œil l'arrivée de la station de combat, craignant un isolement politique et l'arrivé d'un régime fasciste entrainant dans son sillage la ruine du monde civilisé. Le débat est toujours en cours, mais pendant ce temps, Darth Poetter peaufine sa nouvelle arme, s'attaquant directement au noyau du monde connu en essayant d'ouvrir un passage permettant de faire voyager à tout vitesse ses troupes, le projet kdbus.
Quand soudain, un étranger venu de la théocratie de Spo-ti-fy prends la parole…
(fin de l'histoire qui glisse)
Et donc maintenant que tout le monde est au courant de l'histoire, je vous invite à lire le bug ouvert par Paul Tagliamonte
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708
pour bien avoir l'histoire. Grosso modo, quelqu'un a lancé la question de savoir si debian devait faire un choix vis à vis des évolutions autour de systemd, de upstart et de l'init par défaut. Et donc, ce fut l'occasion d'interroger le comité technique de Debian, et d'utiliser le système de débat. Il y a grosso modo 6 propositions sur le site :
https://wiki.debian.org/Debate/initsystem
Systemd, upstart, openrc, le status quo ( ie, rien changer ), en supporter plusieurs, ou en supporter 2.
Le débat est toujours en cours. Pour résumer, les membres du comité qui sont aussi employés Canonical ( ou ex ) pensent que Upstart est la meilleur solution ( sans grand surprise, car je pense que si c'était pas le cas, ils ne bosseraient pas chez Canonical, la passion étant un motivateur assez courant chez les libristes ). Les 2 autres membres ayant parlé semble être en faveur de systemd.
Le débat a commencé sur un meta débat, puis sur la question d'une transition, puis est parti assez vite sur la question "systemd ou upstart". Le sujet du hurd et du port kfreebsd a été évoqué, divisant un peu les gens ( entre ceux qui pensent que ça sert à rien, et ceux qui pensent que c'est utile ), et une grande partie des discussions a été sur la question technique du protocole d'activation et de l'activation par socket.
Alors c'est la que je vais commencer à sortir de mon rôle de narrateur pour dire que je pense que Ian jackson fait preuve d'une mauvaise foi énorme sur le sujet de systemd, et propose une solution moisi.
Le sujet de cette sous partie du débat est de savoir si il faut patcher les logiciels pour signaler au gestionnaire de démarrage qu'ils sont prêts. Systemd utilise un socket et propose une bibliothèque pour ça, et s'en passe aussi très bien. Upstart n'a pas de tel système, et marche aussi très bien sans. Ce qui n'a pas empêche de proposer d'utiliser SIGSTOP pour ça, ce qui pose certains soucis.
Le débat est par la :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#1139
La réponse de Lennart :
https://bugzilla.redhat.com/show_bug.cgi?id=833105
Tout d'abord, il ne faut pas lancer SIGSTOP si le logiciel est lancé à la main. Donc pour ça, soit on rajoute une option pour activer le protocole, soit une option pour désactiver. ( personne n'a proposé d'utiliser une variable d'environnement, curieusement ). Ensuite, qu'est ce qui se passe si le logiciel utilise déjà SIGSTOP pour autre chose ?
Pour une raison que j'ai pas trop compris, le débat s'est enlisé pendant longtemps sur le sujet, alors que ça marche très bien sans ( alors que les soucis réglés par l'usage des cgroups sont bien plus courant )
Puis, il y a la question de l'activation par socket. Pour les gens qui ne connaissent pas, c'est ce que fait xinetd, mais augmenté aux anabolisants. Dans le cas du système d'init, ça permet de faire du démarrage à la demande ( économie de ressources ), et de lancer tout en même temps et de laisser le systéme temporiser les connexions ( du moins pour systemd ).
Systemd est bien plus avancé que upstart à ce niveau. Il gère plus de socket ( genre ipv6, udp, unix, tcp, etc ), il gère plus d'un socket à la fois. À coté, upstart ne gère que l'ipv4 et un socket à la fois. Mais la raison avancée par les devs est que ça ne sert à rien pour upstart, donc qu'ils n'ont pas fait plus de travail que ça.
L'analyse détaillé de Russ Alberty vaut le détour :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#1729
Il y a eu bien sur d'autres discussions ( par exemple, savoir si systemd est le mal absolu ou juste un mal mineur, savoir si les gens de Canonical sont vraiment objectifs, etc, etc ), et je ne pense pas réussir à tout résumer. Il y a grosso modo 700 messages dans le bug, plus un bon millier sur debian-devel.
Et vous, vous avez un avis sur le sujet, sur l'architecture d'upstart par rapport à systemd, sur kdbus par rapport à dbus, sur le fait que le débat dure depuis 3 mois et sur les implications techniques, voir même une solution pour les problématiques de Debian ?
Et surtout, est ce que les parisiens vont aller en parler lors de la mini debconf de ce weekend ( http://france.debian.net/events/minidebconf2014/ ) ?
(ah oui, et pour que les gens de #weboob viennent troller, on va activer leur echelon local en disant les mots clés budgea et weboob)
# Et pour une poignée de liens en plus
Posté par Misc (site web personnel) . Évalué à 10.
La discussion sur hacker news :
https://news.ycombinator.com/item?id=7076294
La discussion sur lwn :
http://lwn.net/Articles/578208/
Une autre sur kdbus :
http://lwn.net/Articles/580194/
Et une réponse de GKH :
http://lwn.net/Articles/580814/
Si avec ça, personne n'est inspiré pour une discussion technique, je peux commencer à lancer la discussion sur le nombre de ligne de code upstart et systemd comparé, et comment upstart passe vraiment trop de temps à communiquer en interne de part son architecture la ou systemd rajoute des features dans son code à la place, mais j'ai peur d'être tout seul sur le sujet.
[^] # Re: Et pour une poignée de liens en plus
Posté par bubar🦥 (Mastodon) . Évalué à 10. Dernière modification le 18 janvier 2014 à 10:26.
Je ne tiendrais pas la discussion technique que tu souhaites, mais plus simplement y apporter un point de vue de sysadmin qui suit l'actualité (et peut être relancer ce thread) Et ça me fait bien marrer de voir kdbus aujourd'hui porté dans la branche principale après les commentaires rageux d'il y a quelques années «mais ils sont fous / c'est dégueulasse / on en a pas besoin» lorsque ghk a mis cette demande (venant de l'automotive) dans sa branche. Il y a un petit goût de déjà vu … :) Concernant systemd, c'est déconcertant la facilité avec laquelle il est maintenant possible de réaliser des choses un peu complexes auparavant, execreload, limitnofile, environnment, conditionpath, stopwhenunneeded, … (et je ne parlerai pas des TTY*, que je n'ai pas pigés et qui me posent qq soucis). C'est un plaisir, un régal, que de pouvoir faire aussi facilement des confs comme ça, je n'avais pas connu plus simple.
Mon tit point de vue de tit sysadmin c'est que systemd gagne haut la main, en explosant tout le reste. Je veux bien "argumenter" là dessus, à défaut d'avoir une discussion de développeur. Nous avons là un système d'init plus simple à utiliser (pour un sysadmin mais aussi -surtout- un intégrateur) tout en permettant plus de possibilités.
A mon humble avis cette discussion est close depuis 2 ans, en fait.
Et toujours à mon bien humble avis, si Debian adopte systemd, ça sera le moment où systemd entrera en production, la communauté peut le prendre en charge non une seule entité. si Debian n'adopte pas systemd par contre, donc n'y fourre plus son nez dedans, là ça sera un frein sévère à systemd (à mes yeux)
(Maintenant on peut troller sur le format binaire (et le niveau de verbosité, et la compacité des informations sur un seul endroit) du journal, qui est horreur : les logs sont faites pour être utilisées, journal visiblement beaucoup moins…lol)
[^] # Re: Et pour une poignée de liens en plus
Posté par Sylvain Blandel . Évalué à 10.
L'Empire Red Hat juge que l'Étoile Noire systemd est prête pour
dézinguer les Ewoksentrer en production. En effet, systemd sera utilisé par la version 7 de Red Hat Enterprise Linux (actuellement en béta). Sachant que le support de Red Hat Enterprise Linux peut s'étendre jusqu'à 13 années, j'en déduis que, quelque soit la décision de la communauté Debian, systemd va entrer en production. Et, durant de nombreuses années, des gens seront rémunérés pour assurer sa maintenance.[^] # Re: Et pour une poignée de liens en plus
Posté par Misc (site web personnel) . Évalué à 9.
Et des gens seront payé pour écrire la doc ( https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html/System_Administrators_Guide/chap-Managing_Services_with_systemd.html ), très logiquement pour expliquer comment marche systemd à des gens en formation ( formation RHCE, etc ), et des gens seront payé pour faire des unités systemd pour les outils proprios.
Et je pense que tu peux aussi rajouter SLES 12, qui devrait logiquement également proposer systemd ( cf https://www.suse.com/communities/conversations/systemd-is-not-about-systeme-d/ )
Ou parler de CoreOs ( http://coreos.com/ ), qui est une startup qui bosse sur l'hebergement de container, et qui au passage embauche de ce que j'ai compris. Ou Pantheon ( https://www.getpantheon.com/blog/pantheon-running-over-500000-systemd-units ).
C'est un peu ce qui est reproché à Upstart par un membre du tech-ctte, c'est que sur upstart, il y a que Canonical ( et Google via ChromeOS ) qui contribue.
[^] # Re: Et pour une poignée de liens en plus
Posté par Misc (site web personnel) . Évalué à 10.
Dans la mesure ou systemd est déjà dans plein de distributions, dans le mesure ou j'ai vu presque personne dire "je suis sysadmin, je surkiffe trop upstart qui permet des trucs trop bien", je pense que la communauté a déjà choisi.
Non pas que upstart soit catastrophique, mais j'ai le sentiment que personne parmi les sysadmins que je connais ne cherche à tirer parti des fonctions avancés. Et pourtant, upstart est présent dans RHEL, Ubuntu server, etc.
Upstart a déjà 5 ans, est globalement mature ( minus certains soucis de conceptions, genre l'usage de ptrace pour suivre les process ), et bien qu'il a été utilisé dans l'embarqué ( genre le nokia n9 ), j'ai pas le sentiment que son modèle à base d'evenement ne séduise plus que ça. Ça se voit par rapport par exemple aux posts de blog qui parlent du projet, qui sont bien moins nombreux que pour systemd, ou du moins, qui m'avait l'air moins nombreux quand j'ai regardé il y a quelques semaines, alors que la communauté Ubuntu est censé être une des plus grande niveau utilisateur.
Donc non, je pense pas qu'une non-adoption de systemd par debian soit un frein. J'aurais plus tendance à dire que ça va arriver dans debian, quoi que le tech-ctte fasse, et que au contraire, un refus ( ce qui n'est pas le cas actuellement, mais le cas chez Ubuntu ) serait un frein pour la distribution, sauf à avoir l'égalité au niveau des fonctions, ce qui est un travail en cours ( par exemple, l'usage des cgroups dans upstart, il reste plus que tout le reste à faire ).
[^] # Re: Et pour une poignée de liens en plus
Posté par bubar🦥 (Mastodon) . Évalué à 10. Dernière modification le 18 janvier 2014 à 13:39.
Cela rejoint le titre du journal auquel celui ci fait référence. Il y a quelque chose entre ces deux mondes. Ou pas, dans cet exemple.
Ce n'est pas contradictoire. Il semble important pour (notre regard sur) systemd que Debian l'adopte. Sans cela, il continuera de vivre sans problème, et d'être présent dans de nombreuses distributions ou sous-distributions, mais disons que le regard porté sur systemd ne sera pas le même… Que Debian adopte systemd semble être un gage d'assurance pour tous. Ce n'est pas contradictoire et ça semble important.
Ubuntu s'est isolée toute seule avec le sujet mir, ça serait dommage qu'elle entraine Debian avec elle sur l'init.
[^] # Re: Et pour une poignée de liens en plus
Posté par cluxter . Évalué à 2.
"Ubuntu s'est isolée toute seule avec le sujet mir, ça serait dommage qu'elle entraine Debian avec elle sur l'init"
Très gros +1.
Ubuntu adopte de plus en plus une stratégie de fork solitaire réinventeur de roue à la Android et c'est son droit. Mais venir semer la lèpre dans la communauté Debian, ça on s'en passerait.
La seule raison valable selon moi pour laquelle le choix n'a pas encore été fait en faveur de "systemd" pour Debian, c'est la présence de 2 développeurs de Canonical dans l'équipe. Je n'ai jusqu'à présent vu aucun argument plaidant techniquement en faveur de "upstart" plus que de "systemd".
Canonical essaye tant bien que mal d'influencer le développement de Debian pour servir ses intérêts et économiser des ressources.
Je n'aime pas ça du tout car si Debian est une si bonne distribution, c'est bien parce qu'elle a su évoluer indépendamment de toute priorité financière. Elle se concentre sur comment faire les choses bien avant de vouloir les faire à moindre coût (tout comme le noyau Linux d'ailleurs). Ubuntu est développée dans une optique de rentabilité à court/moyen terme, et on le voit clairement avec Mir sûrement pas à long terme !
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Et pour une poignée de liens en plus
Posté par barmic . Évalué à 4.
En quoi il est le nœud ?
C'est des développeurs Debian qui FUD sur Lennart ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Et pour une poignée de liens en plus
Posté par briaeros007 . Évalué à -2.
si tu lis bien, certains préfère avoir à gérer upstart partout, et essayer de faire quelque chose contre les CLA, que d'avoir à gérer upstart sur !linux, systemd sur linux, et gérer les tentatives pieuvresques de systemd (logind & consors).
[^] # Re: Et pour une poignée de liens en plus
Posté par Misc (site web personnel) . Évalué à 8.
Je pense que logind va être difficile à éviter, vu que ça remplace consolekit.
Et je pense que l'argument de Lennart sur "la gestion des cgroups doit être dans le pid 1 si le pid 1 utilise les cgroups" me semble assez logique. Et la méthode de gestion des processus de upstart ( soit pas de fork, soit avec l'envoie de SIGSTOP, soit avec ptrace, ie 2 hacks fragiles et un truc potable mais pas complet ) ne me semble pas fiable par rapport à l'usage des cgroups pour les cas complexes.
Et comme Lennart le dit sur son g+ ( https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/ip8e1DqJdxT ), upstart n'utilise même pas son propre paradigme correctement pour les systèmes de fichiers, et n'a pas énormément bougé depuis 4 ans ( et c'est vrai que upstart a l'air de moins bouger que systemd :
https://www.ohloh.net/p/systemd
vs
https://www.ohloh.net/p/upstart
et surtout que c'est reparti entre 2012 et 2013, curieusement quand systemd a commencé à prendre la place de upstart un peu partout ( y a 2/3 ans chez Fedora, et un peu partout ailleurs après ).
[^] # Re: Et pour une poignée de liens en plus
Posté par briaeros007 . Évalué à -2.
tu pratique la méthode coué et l'évangélisme ?
Je n'ai juste fait qu'extraire les infos du mail cité, et un mail d'une personne légèrement plus compétente que moi, et excuse moi, bien que je ne te connaisse pas, sans doute de toi aussi.
Ensute perso je m'en fous je n'ai aucun pouvoir de décision. Si ça vous fait tellement de bien de croire que systemd est le sauveur du monde, croyez ce que vous voulez.
[^] # Re: Et pour une poignée de liens en plus
Posté par Sébastien Douche . Évalué à 6.
Oula pas si vite, ton avis de sysadmin m'intéresse fortement. Peux tu développer ?
[^] # Re: Et pour une poignée de liens en plus
Posté par laurentb (site web personnel) . Évalué à 10.
Mon expérience pour avoir créé un service systemd démarrant buildbot, qui a tendance à se ramasser :
Quant je le lance, et que ça ne marche pas, systemd me le signale comme un grand et me donne une commande pour voir les sorties du logiciel (sorties standard, pas syslog). Écrire le start/stop dans un init classique aurait globalement été beaucoup plus lourd, avec quelques options je peux faire comprendre comment l'application se comporte, y compris ses comportements, disons, mauvais.
Mon service est aussi paramétrable ; le même fichier me sert à lancer plusieurs buildbots (bon, ça c'est relativement facile avec OpenRC).
journalctl est très bien fait, on peut filtrer, avoir un équivalent de tail -f, il y a des couleurs, etc. Je n'ai pas pour l'instant eu le besoin de dumper le tout dans un fichier texte.
# OpenRC
Posté par laurentb (site web personnel) . Évalué à 10.
J'allais dire "et OpenRC ?" mais en fait, c'est une des options proposées !
OpenRC n'est pas du tout moderne mais il est performant, simple à administrer, et plein de fonctionnalités sympathiques pour créer des scripts, points qui sont actuellement plutôt mauvais chez Debian.
C'est sûr que systemd, du moins d'après ma petite expérience de la chose, fait aussi tout ça en plus performant et concis. Mais OpenRC est un compromis assez simple, portable, qui résout déjà pas mal de points gênants pour les administrateurs finaux.
Ce que semble faire Gentoo (premier utilisateur de openrc), c'est de supporter les deux à la fois, ce qui n'est pas vraiment inhabituel pour cette distribution ; et elle a les mêmes problèmes que Debian puisque possédant des déclinaisons BSD.
[^] # Re: OpenRC
Posté par Misc (site web personnel) . Évalué à 6.
En effet, mais openrc ne semble pas passionner les foules. Malgré le fait que les devs rajoutent des fonctions ( support de cgroups pour suivre les processus ), seul Thomas Goirand semble le pousser. Mais il ne perds pas son temps, et je pense qu'il travaille d'arrache pied pour résoudre les soucis, et je pense qu'en effet, ça pourrait faire un bon complément sur les plateformes BSD et Hurd si un autre système d'init est choisi pour Linux.
Ensuite, quelqu'un note dans les liens que ce bug sur le boot en parallèle n'est toujours pas corrigé
https://bugs.gentoo.org/show_bug.cgi?id=391945
Debian comme la plupart des distributions utilise ce genre de fonction pour gagner du temps au boot depuis longtemps, donc ça pourrait être un retour en arrière que de devoir la désactiver par défaut.
[^] # Re: OpenRC
Posté par rewind (Mastodon) . Évalué à 10.
Choisir systemd+openrc me paraît être le choix le plus raisonnable : systemd est partout ailleurs (malheureusement), Gentoo ferait pareil, les variantes non-Linux pourrait avoir un init un peu plus moderne que l'actuel. Mais je crains que les intérêts personnels des membres du comité technique ne viennent jouer les trouble-fêtes.
D'ailleurs, j'ai toujours été étonné par cette instance bizarre au sein de Debian dont personne ne parle jamais mais qui a le réel pouvoir au sein de Debian et qui est tout sauf un truc démocratique. Ses membres sont cooptés, immuables, et en l'occurrence, pas vraiment impartiaux, notamment par rapport à Ubuntu. Bref, on parle souvent du DPL, mais le ctte, c'est le vrai cœur de Debian, c'est là que sont prises les vraies décisions.
[^] # Re: OpenRC
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
Bof, la plupart des décisions sont prises par les gens prêts à bosser pour les mettre en œuvre. Là par exemple, quoi que le ctte puisse décider, si quelqu'un maintient un paquet pour un système d'init supplémentaire et qu'il fonctionne, il ne se fera pas virer de Debian.
[^] # Re: OpenRC
Posté par rewind (Mastodon) . Évalué à 10.
Je ne suis pas tout à fait d'accord. Le ou les systèmes d'init qui seront marqués comme officiels auront un impact sur tous les DD, en particulier devoir offrir systématiquement un fichier d'init au bon format quand il n'en existe pas. Pour un système d'init supplémentaire, ça ne sera pas le cas et ça relèvera de la bonne volonté des développeurs. C'est une grosse différence tout de même.
On peut le voir à l'heure actuelle avec systemd qui est dans les dépôts Debian, mais pour lequel tous les packages qui en ont besoin n'ont pas de fichier d'init au format systemd.
Donc, pour moi, la décision du ctte est plutôt engageante.
[^] # Re: OpenRC
Posté par bubar🦥 (Mastodon) . Évalué à 3. Dernière modification le 18 janvier 2014 à 11:11.
Maintenir deux systèmes d'init ne (me) parait pas raisonnable. Doubler le travail (même si openrc demande bien moins d'efforts) ne semble pas raisonnable.
D'autant que cela déporte la question sur «quel init par défaut», qui se déportera sur «quelle arch», et qui quasi-inévitablement aura en résultat «bien, 4 ans après, le systeme d'init par défaut est utilisé sur 99% des plateformes intel et arm via l'usage de 90% de linux, le reste étant dû au port de kfreebsd puis au quelques choix rares et volontaires d'autres choses que l'init par défaut sur intel/arm/linux». Hum, c'est une projection (d'autres argueront que d'ici là, la glib ne sera plus utilisable/portable sur le noyau freebsd parceque …) certes. Mais même si les résultats étaient différents, à la base cela demande double travail.
Mes deux cents.
[^] # Re: OpenRC
Posté par rewind (Mastodon) . Évalué à 10.
Oui et non.
D'une part parce que comme ça a déjà été souligné à plusieurs reprises, il y a une réduction des choix qui est en train de s'opérer de manière globale dans le monde libre (Linux, BSD) autour de quelques solutions, là où auparavant chacun avait sa solution soit-disant générique mais surtout maison. Ce qui fait qu'un développeur pourra bientôt fournir lui-même deux ou trois fichiers d'init pour les quelques solutions majeures, évitant une partie de ce travail à la distribution. D'autant que Gentoo a visiblement fait le même choix dont l'effort pourra être réparti.
D'autre part parce que c'est une nécessité. Systemd ne fonctionnera jamais sur autre chose que Linux, c'est un fait. Donc, il faut bien trouver une solution à l'échelle de Debian et avoir openrc pour tout le monde, qui pourtant semble être une bonne solution, isolerait Debian durablement des autres distributions. Le choix ne devrait se faire que sur cette base. Debian ne pratique pas le sondage pour décider si un paquet reste ou pas dans l'archive (heureusement !). Donc s'ils font le choix systemd+openrc, ils maintiendront ces deux solutions pour un très long moment.
[^] # Re: OpenRC
Posté par briaeros007 . Évalué à 0.
Ahahah. J'ai eu à installer un jboss il y a peu. Le fichier d'init pour redhat est fournis dans les sources (pas une version packagée par une distrib … de toute façon à part redhat, et encore même pas sur, il y a vraiment peu de distrib qui package des jboss récents).
C'était sur une redhat. Bon le fichier d'init fournis ne marchait tout simplement pas (ou plus exactement très mal).(et même chose sur debian).
Donc je serais toi, je ne m'attendrais pas à des miracles. Si déjà dans le cadre de jboss (qui est poussé par redhat & tutti quanti) les devs sont pas foutu de faire un fichier d'init à peu près propre pour leur propre distrib, que dire d'un dev lambda qui devra gérer trois système d'init différent.
/me espère que ce ne sera pas systemd. J'ai lu le lien vers redhat pour approfondir ma méconnaissance de l'outil vu que tout le monde l'encense. La doc décrit en 15 pages ce qu'un simple --help suffit. On apprend que le mode "rescue" et le mode "emergency"* demande tous le mdp root (pratique si tu n'a pas celui de la bécane et que tu passes en rescue pour le péter. La ça sera à coup de bin/sh ou de livecd).
*Et on apprend aussi qu'en mode rescue il démarre des trucs qui seraient suceptible de pas trop bien démarrer donc ils ont mis aussi un mode qui démarre encore moins de chose : le "emergency".
Par contre aucune info sur la création d'un service, la modification d'un service, …
Soit la doc de redhat est vraiment pas finalisée, soit redhat se microsoftifient de plus en plus avec des docs au kilomètres, mais un rapport "intérêt/nombre de mots" qui diminue.
[^] # Re: OpenRC
Posté par cosmocat . Évalué à 8.
Il me semble que ta façon de juger un système d'init est un peu foireuse…
Si j'ai bien compris, faire un fichier .unit pour systemd est plus facile que faire un script d'init. Tu peux donc juste t'estimer heureux que les développeurs (qui ne sont pas forcement des packageurs et que ça fait donc chier de faire les fichiers d'init et qui n'ont peut-être pas les compétences) ne t'aient pas pondu un script d'init encore pire!
En plus, le gros avantage que j'y vois est que le fichier de conf de systemd étant upstream, il suffit que t'aillant aperçu que le fichier est bancal, tu pousses la correction au projet pour que toutes les distributions en profitent. Tu n'auras pas à corriger tous les scripts d'init foireux (et différents) que les différentes distributions auront du écrire! De même, il suffit qu'un mainteneur d'une distribution écrive un bon fichier d'init et le propose au projet pour que TOUTES les distributions en profitent.
Quant à ton avis sur la documentation, si tu t'en ai aperçu, c'est qu'il y a peut-être un besoin et la doc pourra être améliorée. Il me semble qu'améliorer une documentation est bien plus facile qu'améliorer l'architecture foireuse d'un logiciel, non?
[^] # Re: OpenRC
Posté par briaeros007 . Évalué à 1. Dernière modification le 19 janvier 2014 à 15:59.
Je pense qu'il y a méprise. Je ne jugeais pas le système d'init avec cette phrase.
Je jugeais "l'espoir" qui si on a qu'un nombre restreint de système d'init, alors les developpeurs feront de "beau scripts d'init" pour ce pool restreint.
Et pour confirmer ce point j'indiquais une anecdote personelle montrant que même pour un système d'init (sysV sauce redhat) les devs n'ont pas la volontée/connaissance/expérience/temps/… pour faire un script d'init "correct". Alors pour plus de un, je te laisse imaginer.
Je ne vois vraiment pas comment à partir de ma citation tu as réussi à partir sur systemd.
Eusse-tu pris la fin de mon post j'aurais pu comprendre et argumenter, mais là j'avoue que je ne te suis pas.
Même chose avec trois scripts (ou même un seul) dans le projets. On sait tous les tenants et les aboutissants quand c'est upstream ou pas.
Ca c'est la théorie.
La pratique je l'ai eu avec jboss (entre autre) et force est de constater qu'il y a un léger delta entre la théorie et la pratique.
(et avant que tu pose la question : non je n'ai pas fait un bug report pour mes problèmes avec jboss. J'aurais sans doute due … si j'avais un compte kivabien et le temps, mais comme je n'ai eu ni l'un ni l'autre, ben j'ai mes scripts "jalousement gardé" faute de temps.)
Améliorer la documentation ne remplace pas de mauvais choix d'architecture ;)
[^] # Re: OpenRC
Posté par claudex . Évalué à 8.
En tout cas, j'ai déjà pu tester l'intérêt d'avoir un format commun entre les distribution. Pour ttrss, j'ai pu recopier le fichier .service que quelqu'un avait publié pour fedora et l'utiliser sur debian (en changeant juste le nom d'utilisateur avec lequel il se lance et en vérifiant que ça ne fasse pas un rm -rf à chaque démarrage) sans 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: OpenRC
Posté par barmic . Évalué à 3.
Je ne comprends pas pourquoi ils ne prennent pas en compte la possibilité d'améliorer metainit pour générer les fichiers à partir d'un fichier de description de base. Ça ne me parait pas si démesuré que ça à faire.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# kdbus
Posté par claudex . Évalué à 5.
Je n'ai pas compris l'intérêt de kdbus par rapport à dbus. Quelqu'un connaît la raison d'être du projet ?
« 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: kdbus
Posté par Shuba . Évalué à 10.
Lennart Poettering donne les explications au LCA.
Pour résumer ce que j'en ai compris, kdbus présente les avantages d'être présent dès le démarrage et jusqu'à l'extinction de la machine, de garantir l'ordonnancement des messages et d'être beaucoup plus efficace que dbus.
[^] # Re: kdbus
Posté par claudex . Évalué à 10.
J'ajouterais que le but est d'avoir un mécanisme d'IPC évolué (appel de méthode, propriété, notification…) que d'autres noyau ont. Et que les performances de Dbus ne pouvaient pas être améliorées sans l'intégrer au noyau (à moins de laisser tomber la sécurité) car il fallait utiliser les IPC existantes (sockets) qui nécessite beaucoup de copie de mémoire. Et l'efficacité permet d'envoyer du contenu au lieu de se limiter à des commandes.
Au point de vue sécurité, cela permet aux frameworks de sécurité (SELinux, Apparmor…) d'éviter de faire confiance à l'userspace.
« 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: kdbus
Posté par claudex . Évalué à 10.
J'ai oublié de préciser que tout Dbus n'est pas implémenté dans le kernel. Par exemple, le kernel ne connait rien du marshalling à part pour la destination du message.
« 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: kdbus
Posté par Misc (site web personnel) . Évalué à 4.
je suis modérement pas d'accord. D'une part, dans l'état des choses, le démon dbus fait l'arbitrage de qui a le droit de faire quoi via selinux et apparmor. Pour cela, il profite du fait qu'il a une vision globale sur les messages.
Bien sur, il est en userspace, mais il tourne dans un domaine de sécurité séparé du process userspace auquel on ne fait pas confiance, donc la distinction est plus complexe que kernel space vs userspace.
Et c'est ce point qui pose souci au dev de Canonical, car ils ont besoin de plus de précision que juste laisser passer ou non le message.
Actuellement, pour reprendre une analogie, le filtrage par selinux est de l'ordre d'un filtrage de niveau ip/tcp sur une couche réseau classique. Ce que Canonical a besoin pour confiner les applications, c'est plus un truc du style filtrage protocolaire. Ce qui se fait sans souci en userspace, et qui va avoir une énorme résistance au niveau du kernel. Et si le positionnement d'un tel filtre est évidement au lieu de passage dans le kernel, ça va pas aller.
Une solution serait de faire comme le défunt nufw, ie faire passer le message en userspace pour filtrage avant de retourner au kernel, mais ça devient inefficace. Une autre solution pourrait être une dérivation ( ie, le message va au destinataire et à un démon de filtrage, et le destinataire attends que le demon de filtrage dise "oui" ), mais la, on rajoute des délais un peu inutile et une architecture un peu plus complexe et fragile.
Donc je comprends que le passage vers le kernel dérange des gens, même si je pense qu'avec le temps, un moyen de filtrer efficacement soit ajouté dans le kernel.
[^] # Re: kdbus
Posté par claudex . Évalué à 5. Dernière modification le 18 janvier 2014 à 23:49.
Je ne sais pas si c'est vrai mais Lennart dit dans sa conférence que les types de SELinux ne sont pas vraiment contents de la situation actuelle et préféreraient que tout se fasse dans le kernel.
« 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
# Les choix des membres du technical comitee
Posté par Shuba . Évalué à 10.
La plupart des membres du technical comitee ont déjà fait savoir leur avis, ce qui peut permettre de se faire une idée.
Ian Jackson a choisi upstart
Russ Alberry marque sa préférence pour systemd
Steve Langasek (le mainteneur d'upstart) penche pour upstart, mais a fait savoir à plusieurs reprises qu'il concentrerait ses efforts sur l'intégration de systemd si ce dernier venait à être choisi.
Colin Watson (développeur Ubuntu) penche également pour upstart.
Bdale Garbee opte pour systemd
Keith Packard fait le choit de systemd
Don Armstrong a une légère préférence poyur systemd
Andreas Barth n'a pas encore exprimé sa position, mais devrait le faire dans le weekend.
On voit donc que les avis sont partagés, avec un léger avantage pour systemd pour le moment, même si l'égalité reste envisageable selon l'avis d'Andreas Barth.
Cependant, n'étant pas versé dans les rouages du système de vote utilisé, je me garde bien de pronostiquer le résultat.
[^] # Re: Les choix des membres du technical comitee
Posté par nive . Évalué à 6.
Et la réponse d'Andreas Barth est Upstart : 4-4 balle au centre
A la fin de ce message
[^] # Et maintenant ?
Posté par Sylvain Blandel . Évalué à 3.
Et maintenant, que va-t-il se passer ? Le projet Debian va-t-il rester au statu quo, c'est-à-dire que SysVinit reste le seul système d'init officiellement supporté ? Se dirige-t-on vers un vote lors d'une résolution générale ?
[^] # Re: Et maintenant ?
Posté par Misc (site web personnel) . Évalué à 4.
Il reste encore une personne. Et bon, une fois que le tech-ctte dit un truc, faut juste attendre que quelqu'un fasse le boulot.
Il serait amusant que ça soit upstart, ne serais que pour continuer à troller :p
[^] # Re: Et maintenant ?
Posté par Sylvain Blandel . Évalué à 2.
Qui ?
Le comité technique est composé de 8 membres (lien), et d'après ces 2 messages (premier, deuxième), ils se sont tous exprimés.
[^] # Re: Et maintenant ?
Posté par Misc (site web personnel) . Évalué à 1.
Ah merde, ça m'a semblé tellement logique d'avoir un nombre impair :/
[^] # Re: Et maintenant ?
Posté par Spyhawk . Évalué à 7. Dernière modification le 21 janvier 2014 à 12:26.
Le vote de Bdale Garbe compte double, puisqu'il est le chairman du Debian technical committee (voir la constitution Debian, point 6.3.2). Faut voir comment ça se passe en pratique, mais avantage à Systemd pour le moment.
# Mini précision, variable d'environnement
Posté par Frédéric Péters (site web personnel) . Évalué à 8.
C'est abordé, Russ Allbery, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#2553
[^] # Re: Mini précision, variable d'environnement
Posté par benoar . Évalué à 9.
Quand on voit la réponse de Lennart https://bugzilla.redhat.com/show_bug.cgi?id=833105, on ne peut s'empêcher de voir la mauvaise foi de partout : il ignore l'utilisation de SIGSTOP seulement si un flag/variable d'environnement est mis, dit que ça peut être utilisé pour autre chose, mais là c'est dans le cas où le process l'utilise sur lui-même, il indique qu'il ne voit pas de différence entre appeler une fonction de la libc et introduire une dépendance à sa lib (il doit s'en foutre du boulot de mise à jour de tous les paquets, même les plus vieux/exotiques/etc…), … Alors que le rapport original demande juste une simple mesure pour être compatible optionnellement avec certains programmes !
Il est trop reulou. Techniquement, c'est à dire au niveau des capacités, je trouve que systemd bat de loin tous les autres. Ça serait la raison qui me fait le supporter. Mais entre son implémentation lourdingue, sa volonté de vouloir tout remplacer d'un coup (génial), l'intégration de tout dans systemd ce qui rend udev et d'autres utilitaires essentiels forcément dépendants de systemd sans toujours de bonne raisons, le « j'en n'ai rien à foutre des autres qui ne peuvent pas suivre », et l'ego démesuré de ce mec… c'est super chiant. Alors oui, je ne vois pas de solution aussi « bien » que la sienne, mais on sent tellement une sorte d'imposition de l'avis de RedHat sur un paquet de choses d'un coup, et que plein de monde va être largué parce que non compatible, que ça fait très peur.
[^] # Udev
Posté par Sylvain Blandel . Évalué à 5.
D'ailleurs : pour qu'udev soit intégré à systemd, il a bien fallu que les anciens mainteneurs d'udev choisissent d'abandonner leur travail, non ?
Que les mainteneurs de systemd aient copié-collé tout le code d'udev dans systemd, c'est une chose. Mais si la version originale d'udev (celle qui était « en dehors de systemd ») est morte, cela signifie que les anciens mainteneurs d'udev ont abandonné, non ?
[^] # Re: Udev
Posté par briaeros007 . Évalué à 9.
ou que les deux équipes étaient déjà proches …
[^] # Re: Mini précision, variable d'environnement
Posté par Misc (site web personnel) . Évalué à 5.
L'implémentation d'upstart a un souci :
https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/upstart/trusty/view/head:/init/job_process.c#L1482
Elle relance le process tout le temps. Donc SIGSTOP ne marche plus. Tu noteras que visiblement, il n'y a pas de vérification de l'endroit d'ou viens le signal, vu que ça utilise waitid (cf le code de libnih) qui reçoit juste l'état. Donc si j'envoie un signal SIGSTOP, il est ignoré.
Les logiciels marchent sans avoir besoin de signaler leur "readyness", le fait que personne ou presque n'implémente le protocole d'upstart est la preuve. Et rajouter l'appel en question , c'est surtout du taf sur les autootools que sur le code, c'est pas vraiment le plus compliqué.
Et j'ai bien regardé, j'ai trouvé 2 softs qui utilisent le dit protocole. openssh et xorg. Et c'est des patchs de Canonical dans les 2 cas. Pour un truc qui date de 2008, on peut pas dire que les foules se jettent dessus.
[^] # Re: Mini précision, variable d'environnement
Posté par benoar . Évalué à 1.
Bah, l'implémentation d'upstrart est pourrie, et ? Tu relances au premier SIGSTOP uniquement, et c'est bon (tu vas me sortir le coup du mec qui SIGSTOP entre le lancement du programme et la fin de l'initialisation, je te sortirais qu'on ne demande pas une solution extrêmement parfaite ; c'est un truc pour aider ceux qui ne veulent pas dépendre de systemd).
Mouai, alors toi tu n'as pas du faire beaucoup d'empaquetage de logiciels. Quand tu fais réellement de l'intégration, ajouter une dépendance n'est pas du tout anodin. Après, je ne dis pas que c'est insurmontable, mais c'est ajouter des milliers de fois une charge qui pourrait être évitée (enfin, très réduite) si systemd l'implémentait.
[^] # Re: Mini précision, variable d'environnement
Posté par Misc (site web personnel) . Évalué à 10.
et ça fait 5 ans qu'elle est pourrie. Que dire de plus à part que visiblement, personne n'a revu le truc dans le détail ?
Sinon je peux continuer pour te dire pourquoi le protocole est pourri et pas juste l'implémentation. Prends par exemple un soft comme couchdb en erlang. Comme c'est de l'erlang, il faut lancer via erl avec souvent un script bash qui va mettre divers variables, etc. Du coup, comme un processus ne peut surveiller que son fils, il se passe quoi dans le cas d'un soft comme le dit couchdb qui fait pas forcément un exec à la fin ( ie, le cas très précis de couchdb avec l'option pour relancer automatiquement le soft quand il se gauffre, cf /usr/bin/couchdb ) ?
Soit le script fait le SIGSTOP mais il va faire ça avant que couchdb soit prêt, soit erl le fait, mais personne ne va le surveiller.
On peut tenter le coup aussi avec un soft qui lance 2 softs ( genre miredo-client, qui va se relancer avec moins de priviléges ). Celui qui est surveiller (le premier) est pas celui qui fait le taf (le 2eme).
Et on peut généraliser le cas avec apache, php-fpm. Du coup, le code passe de "je fait raise(sigstop) + un if" à "je mets en place un canal de comm entre le fils et moi pour que le fils me signal son état, et que moi ensuite je fasse un SIGSTOP pour signaler à mon propre père.
Avec le protocole de systemd, on se contente juste de passer la variable et le file descriptor. Le travail est beaucoup plus simple. Et point bonus, tu peux faire plus que juste dire "je suis prêt".
Je ne suis pas sur qu'il soit sage d'user d'un argument de ce genre sans avoir fait un minimum de vérification et vérifier avant de supposer. ( mais je reconnais que depuis que j'utilise que mon pseudo sur linuxfr, c'est beaucoup plus dur de vérifier qui je suis quand on n'a pas plus de choses pour une recherche google ). mais je te laisse le soin de vérifier quand je te dit que ça doit bien faire 10 ans que je fait des paquets rpms, que j'ai codé sur des softs comme rpmlint, que j'ai participé à divers distros voir forké une distro et bosser sur la mise en place de son systéme de build entre autres choses.
Si il y a que ça, tu peux aussi prendre les fichiers .c et .h prévu pour ça depuis le code de systemd. Moi, je trouve ça dégeu, mais si upstream insiste à pas rajouter de lien, c'est son code.
Encore une fois, il y a 2 logiciels dans tout debian qui supporte le dit protocole. Donc il faudrait :
1) rajouter le dit protocole dans systemd de façon correcte ( ce qui est déjà pas le cas chez upstart )
2) rajouter le support sur les milliers de paquets en question 3) patcher la documentation des milliers de paquets.
Et bien sur, résoudre les cas épineux tels que j'ai énoncé ( et sans trop me forcer )
Ensuite, c'est pas comme si Debian avait déjà fait des milliers de patchs pour tout un tas de trucs ( GFDL et la DGSF, le portage sur le Hurd, le portage pour kfreebsd ). C'est pas comme si les packageurs de Fedora ou d'autres distros doivent régulièrement faire des patchs pour tel nouvelle version de gcc ou tel options de gcc, tel lib qui a été mise à jours et qui changent 2/3 trucs.
Enfin, je continue à dire qu'il n'y a pas vraiment besoin de rajouter de protocole de notification pour la plupart des softs. Il y a plus d’intérêt à faire du on-demand avec les sockets par exemple.
[^] # Re: Mini précision, variable d'environnement
Posté par benoar . Évalué à 3.
Je n'ai peut-être pas capté un truc, mais pourquoi ne fait-il pas le SIGSTOP après ? Le coup de ne pouvoir surveiller que son fils, c'est sans utiliser les cgroup, hors, systemd l'utilise justement. Et même, pourquoi n'exec-t-il pas erl ? Bon, il a peut-être des raisons, et le coup du SIGSTOP peut effectivement sembler bidouille dans ce cas.
OK, merci de l'explication sur les désavantages, je comprends mieux. À la base, je disais juste que l'excuse de « le coup du SIGSTOP est pourri car upstart le fait mal » me semblait en légère. Je suis d'accord du coup que ça n'est pas forcément le mieux.
Rho, c'était pas une attaque ad hominem, c'était juste pour dire que ta remarque « c'est super facile de rajouter une dépendance » ne sera peut-être pas acceptée par tous les développeurs : oui, quand tu connais, c'est plus ou moins facile, mais en général les devs upstream ont besoin de faire appel à des empaqueteurs aguerris pour les aider à gérer tout ce bordel. Ça n'est pas pour rien que tout le monde peste contre les autotools : ils ne sont pas facile à aborder. (je ne dis pas qu'ils sont mauvais, au contraire : je suis même en train d'écrire une doc sur mon expérience dessus)
Quant à ton nick, oui, je sais que tu n'es pas un débutant, je fréquente linuxfr depuis un bout de temps quand même… ne le prend pas personnellement.
J'espère que ça peut être aussi facile que tu le dis. Vu l'inter-dépendance de tous les morceaux de systemd, je me permets d'avoir un petit doute, mais comme je n'ai pas regardé, je ne protesterais pas plus que ça.
Ah ? Merde, j'aurais dû vérifier, je pensais que c'était plus courant /o\
Note que ces points deux et trois sont aussi valables avec systemd.
Oui, mais dans ce que tu cites, c'est souvent soit pour enlever des trucs, soit pour adapter du code existant. L'ajout de dépendance sur un autre logiciel, pas prévu au début pour le programme, ça rentre pour moi quand même dans une catégorie un peu plus pointue de travail et potentiellement d'emmerdes. Mais bon, si ça permet d'améliorer la gestion de démons du système, ça mettra peut-être plus de motivation dans le cœur des empaqueteurs…
Perso, je trouverais ça pratique avec des softs qui ont des comportements pas facile à gérer pour moi ; typiquement, qui offrent un socket de contrôle, mais qui est créé après que l'exécutable se soit démonisé. Typiquement, dans le monde réel, ça passe, mais en VM ça va tellement vite que mes scripts d'init doivent kludger (sleep…) pour que ça marche. C'est pour ça que si systemd prend bien, et que le travail colossal pour l'intégrer est fait, je trouverai ça bien au final.
[^] # Re: Mini précision, variable d'environnement
Posté par Misc (site web personnel) . Évalué à 6. Dernière modification le 24 janvier 2014 à 01:10.
L'idée d'utiliser un signal, c'est bien pour signaler que le processus est prêt. SI on le fait sans vraiment savoir ( iequand on a lancé mais qu'on a pas vraiment vérifié ), on reviens à ce que ferait un gestionnaire de processus sans notification.
Je suis pas spécialiste des cgroups, mais waitid ( qui est utilisé par upstart pour choper l'état d'un fils ) n'est pas lié avec les cgroups. La façon dont systemd utilise les cgroups, c'est juste pour grouper les process et les limiter. Et il se sert du second pour la répartition des ressources, et du premier comme un liste de soft à tuer avec une boucle. Les primitives unix ne permettent pas autre chose, sauf erreur de ma part ( ie, surveiller un processus arbitraire, sauf via ptrace, ce qui pose un autre type de souci, et ptrace qui est utilisé justement aussi par upstart, avec aussi une implémentation avec un certain nombre de souci dans son design )
ça oui, c'est la solution théorique, et je suis d'accord qu'idéalement, c'est ce qu'il faut faire. Ensuite, il y a la pratique, et dans la pratique, il y a des options pour que ça n'arrive pas ( dans le cas de.
Et c'est le souci. Le SIGSTOP semble séduisant pour un daemon simple, mais pour un daemon simple, il y a pas de souci.
Et ça deviens compliqué assez vite pour les programmes non triviaux, programmes non triviaux qui justement bénéficient d'autant plus de la notification car ils font plein de choses avant d'être prêt.
L'avantage du protocole de systemd, c'est qu'il est transparent si c'est fait comme il faut. sd_notify est une non opération si il n'est pas lancé avec les variables qui vont bien. Donc pas de souci de doc, pas d'interférence avec un usage ( bien que ça soit un souci d'ordre très théorique, j'ai passé du temps à voir en pratique ce qui l'utilise chez debian et j'ai trouvé surtout des softs pour utilisateur plus que système, donc le souci est pas non plus trés bloquant, on peut reconnaitre ça )
[^] # Re: Mini précision, variable d'environnement
Posté par cedric . Évalué à 5.
Va falloir venir avec un veritable argument la. Parce que pour le coup, il est assez facile de rentrer dans le code, j'en veux pour preuve le nombre de contribution.
La volonte de systemd, c'est de repondre a un probleme. Le fait est qu'il est plus facile de faire tout proprement en integrant toute la chaine que de diviser le tout en 25 projets differents qui n'auront pas autant de traction et en dispersant les forces. Integrer ca aide clairement a faire bouger les choses, un seul projet dans lequel ameliorer les choses, impactant toutes les distributions moderne de linux, pas de probleme de synchronisation de version, …
Ah ah ah, non, pas l'avis de Redhat, l'avis des developpeurs actifs sur Linux. C'est ceux qui codent qui font la direction, Redhat a certe un certain nombre de dev, mais ils n'ont pas le pouvoir d'imposer leur solution. De meme pour Ubuntu. Il y a une raison pour que Systemd progresse bien plus vite et couvre bien plus de cas d'usage que Upstart…
[^] # Re: Mini précision, variable d'environnement
Posté par barmic . Évalué à 4.
Autant j'aime bien systemd autant ça c'est faut ou du moins c'est pas vraiment le sujet. L'auteur s'attaque à plusieurs problématique de front systemd et logind répondent à des problèmes existant, mais différents qu'il y ai un lien entre les deux problématiques c'est un fait mais rien oblige à tenter de faire les 2 en même temps. systemd n'est même pas encore mature que logind arrive et le couplage fort entre les deux n'est pas une qualité.
Dis autrement peut être qu'il faut tout changer dans la manière dont on gère nos distributions (« c'est une révolution ! »), mais c'est logique et normal de s'en prendre pleins la gueule quand on demande de changer autant de composants critique en aussi peu de temps.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mini précision, variable d'environnement
Posté par benoar . Évalué à 3.
C'est marrant, ya quelques temps on me balançait l'argument contraire : systemd est super modulaire, il est bien divisé, il y a plein d'outils « indépendants »… Mais en fait, quand on creuse, non, tout est intégré à tout, et on a beau avoir des commandes séparées, elles utilisent leurs conventions légèrement différentes d'Unix, leur format spécifique, etc. Mais bon, ça a été clairement annoncé par Lennart, donc au moins on ne peut pas lui reprocher de cacher ses ambitions.
Dernière critique en date sur laquelle je suis tombé : http://lists.busybox.net/pipermail/busybox/2014-January/080379.html
(de Denys Vlasenko, lead developer de busybox, qui est ironiquement aussi un truc « tout en un » mais qui essaye de le faire en respectant les standards Unix, lui).
Et c'est marrant ton argument sur la « traction » d'un projet unique, sans « disperser » les forces : le LL en général est quand même plutôt basé sur un ensemble de projets indépendants, ou en tous cas un ensemble de développeurs indépendants, qui mettent leur travail ensemble. Là, prendre tous les devs qui sont chez Red Hat (même si je sais que RH n'est pas une boîte comme les autres qui ne va pas complètement pouvoir imposer sa vue à tous les devs qu'elle embauche) pour bosser sur un truc unique qui va « révolutionner » le Libre, je trouve ça dangereux, au contraire. Je pense qu'une des réussites du Libre, c'est de faire travailler ensemble des gens qui ont des objectifs différents, mais qui s'en accommodent. Si on commence à avoir une armée de devs à la botte d'une seule boîte, aussi bienveillante soit-elle (en général j'aime bien tout ce que fait RH, j'avoue que systemd est un des seuls trucs qui me picote un peu), ça peut facilement partir en sucette par la suite.
On dirait le discours de Shutlleworth… Non, je pense qu'il est impossible d'arriver à synchroniser tout, et même si c'est moins efficace, c'est mieux comme ça. Un peu comme une démocratie est vachement moins « efficace » qu'une dictature : oui, il faut mettre tout le monde d'accord pour avancer, au lieu de juste écouter un mec, mais c'est pour le mieux de tous. Pour info, je « viens » plutôt du monde Debian, où le truc important ça n'est pas tant le code, mais la constitution (le mot n'est pas anodin).
Oui, ceux qui codent font la direction, et RH a une bonne partie des devs systemd, udev, etc, il me semble. Ubuntu, eux, ils ont quelques mecs important mais j'ai toujours eu une impression de lacune technique globale, quand même : il ont débauchés quelques balèzes, mais globalement ça donne une résultat très bof, pas réfléchi. RH, au contraire, quand je vois leurs projets, je suis toujours assez impressionné. Là je bosse pas mal sur libvirt, et tu vois que c'est un putain de truc bien réfléchi. Pour parler du même domaine, tu vois rapidement qu'OpenStack c'est un gros bordel ; pourtant, tu as un paquet de monde qui bosse dessus. RH s'est « plié » commercialement à s'intégrer dans OpenStack, mais techniquement, tu vois bien qu'ils maîtrisent libvirt, et qu'ils font du OpenStack parce que ça marche commercialement, mais ils gardent la maîtrise technique de leurs outils.
C'était juste un exemple, mais c'était pour dire que chez RH, la domination des codeurs permet d'imposer leurs solutions car ils sont mieux « organisés », ou je ne sais pas trop pourquoi, mais en tous cas ils sont forts. Je connais peu d'autres boîtes qui sont capables de ça, c'est pour ça que d'un côté, je les admire, mais de l'autre (pour systemd), ils me font peur.
Parce que ça a été architecturé et développé par des mecs plus balèzes, mieux organisés. Même si niveau expertise technique, je pense que Lennart part beaucoup trop sur l'approche « table rase ».
# Couche de compatibilité?
Posté par MCMic (site web personnel) . Évalué à 6.
Question pour ceux qui comprennent un peu mieux que moi ce qui se passe sous le capot, qu'est-ce qui s'oppose à utiliser systemd pour linux et pour les autres noyaux un système d'init patché (ou avec surcouche) de manière à savoir lire les fichiers unit de systemd? (ça pourrait même permettre de proposer cet autre système à la place de systemd pour les installations linux si souhaité)
Est-ce impossible d'adapter upstart ou openrc ou que-sais-je pour implémenter les APIs systemd? Ou d'avoir un convertisseur unit systemd> fichier d'init d'un autre format?
[^] # Re: Couche de compatibilité?
Posté par claudex . Évalué à 4.
Pour les cas basiques, ça ne doit pas poser de problème, mais il doit y avoir pas mal de soft qui ont un init un peu plus complexe et risque d'utiliser des fonctionnalités pas (facilement) portable automatiquement entre les systèmes d'init.
« 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
# Où en sommes-nous ?
Posté par Sylvain Blandel . Évalué à 2.
La discussion du comité technique Debian dure maintenant depuis 3 mois. Plus de 900 mails ont été postés ! J'ai renoncé à tout lire.
Où en est le comité technique ? Une décision est-elle prise ? La communauté Debian votera-t-elle une Résolution Générale ?
[^] # Re: Où en sommes-nous ?
Posté par Shuba . Évalué à 3.
Pour l'instant, Bdale Garbee a proposé un premier vote sur le système par défaut pour linux, mais après discussions la résolution proposée n'a pas convenu à la plupart des membres du comité, et ils ont voté pour continuer la discussion. La raison pour laquelle la résolution était vue comme non satisafaisante est que le comité technique souhaite qu'une résolution générale puisse prendre le dessus sur leur décision avec une simple majorité, au lieu d'une majorité aux deux tiers comme le prévoie la constitution debian. Une résolution en ce sens est en discussion.
Le débat tourne cependant beaucoup autour de la dépendance d'un packet à un système d'init particulier (comme c'est le cas pour GNOME).
[^] # Re: Où en sommes-nous ?
Posté par Sylvain Blandel . Évalué à 1.
Merci Shuba.
On se dirige donc vers une Résolution Générale. Reste à voir comment celle-ci sera formulée.
# noyautage...
Posté par RD . Évalué à -3.
incroyable !
si le comité technique de Debian se résout à faire passer les fichiers de log system dans un format binaire, c'est qu'on a vraiment touché le fond…
Auparavant les distributions GNU/Linux incarnait le choix, désormais c'est devenu le choix par élimination : il reste Gentoo avec OpenRC.
Quelle déception. Reste plus qu'à les voir foutre en l'air le kernel Linux, reste à savoir comment.
[^] # Systemd et format des fichiers de log
Posté par Sylvain Blandel . Évalué à 3.
Les utilisateurs de
systemdpeuvent installersysloget obtenir ainsi des fichiers de log au format texte (explications).Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.