Je viens de voir une dépèche en cours de rédaction : celle-ci s'appelle "Mise au point sur systemd".
Ceci n'est pas un appel à polluer la dépèche. Donc SVP, les anti-systemd, laissez les auteurs la rédiger. Laissez aussi le temps à cette dépèche de sortir. Ne répondez pas ici. Par contre comme cette dépèche est assez dense (allez jeter un oeil), vous ne pourrez absolument pas y répondre "à chaud". Allez donc suivre la rédaction de celle-ci et préparez vos arguments : personnellement je ne répondrai pas à tout mais j'en ai au moins un sur lequel j'ai beaucoup à dire. D'ailleurs si l'auteur initial pouvait nous dire quel est son métier, ça aiderait beaucoup (il est souvent utile de savoir qui on a affaire avant de répondre). En tout cas ça promet de longues discussions et perte énorme de productivité. Mais attendez la sortie pour répondre SVP !!! Laissez les arguments se former.
# m'enfin !
Posté par CHP . Évalué à 10.
Ca vire un peu à l'obsession, là…
[^] # Re: m'enfin !
Posté par Lutin . Évalué à 7.
La réponse typique d'un anti-systemd, tu es contre le progrès et résistant au changement !
Pourtant avec systemd, mon clavier ne s'est jamais blo
[^] # Re: m'enfin !
Posté par modr123 . Évalué à 1.
La réponse typique du pro systemd, tu dois etre aussi un ouiouiste
[^] # Re: m'enfin !
Posté par Nico C. . Évalué à 2.
La reponse typique du pro-pocoyo, tu dois aussi etre a droite a aimer autant le bleu…
[^] # Re: m'enfin !
Posté par skeespin (site web personnel) . Évalué à 2.
Un propos typique du pro-Po, tu dois aussi être un populiste
[^] # Re: m'enfin !
Posté par modr123 . Évalué à 2. Dernière modification le 08 avril 2014 à 15:29.
pas les teletubbies !!!!!!!!!!!
je devais regarder ça parce que certains episodes faisait pleurer mon neuveu…
dorah ca va mais teletubbies
[^] # Re: m'enfin !
Posté par modr123 . Évalué à 1.
je n'aime pas le bleu et tu sais parmi les noniste tu as des gens de gauche
# meme sa façon d'argumenter est nulle
Posté par modr123 . Évalué à -3.
on ne combat pas les idées des autres mais on defend les siennes
il faudrait dire quelle probleme le nouveau système d'init resout et en quoi cette solution est une amelioration
[^] # Re: meme sa façon d'argumenter est nulle
Posté par Zenitram (site web personnel) . Évalué à 1.
Au cas où tu n'ais pas de mauvaise foi et que tu as juste énormément de mal à comprendre certaines choses, la dépèche (et l'article de l'auteur initial) est pour tordre le cou aux idées reçues sur systemd, pour tordre le cou aux pseudo-arguments aux anti-systemd qui ont besoin d'inventer des reproches faute de vrais reproches sauf que ça se voit (et ça fait rire).
Pour les fonctionnalités, ce que ça résoud, c'est un autre sujet et il faut croire que les mainteneurs de distros ont été convaincus… c'est qu'il doit y avoir des endroits qui parlent des fonctionalités, des problèmes résolus, mais si tu n'es pas de mauvais foi tu le sais déjà ou va faire un peu de recherches… On peu même relire les journaux dessus, les infos sont la. Pour qui ça interesse, évidement, les autres ne font que dire "il n'y a pas d'info" sans les chercher réellement et sans les lire si on montre où c'est (faut pas déconner, ça enleverai encore un argument bidon).
ah oui, j'oubliais : les mainteneurs, les personnes les plus concernées, sont tous des idiots, évidement!
[^] # Re: meme sa façon d'argumenter est nulle
Posté par CHP . Évalué à 9.
Sincèrement, ta zenitramerie saoule. T'es obligé de rajouter "ah oui, j'oubliais : les mainteneurs, les personnes les plus concernées, sont tous des idiots, évidement!" ?
Qui a écrit ça ? Tu es le seul à l'avoir lu !
Ça ne sert à rien. Ça pourrait décrédibiliser les autres, si effectivement ils avaient dit ou sous-entendu quelque chose d'approchant, mais ce n'est pas le cas. Ça ne décrédibilise que toi, et ça énerve le lecteur (et encore plus la personne à qui tu réponds), ce qui n'aide pas à avoir un débat posé basé sur des arguments.
Je passe sur les "et ça fait rire" et autre "faut pas déconner, ça enlèverai encore un argument bidon" : faut bien que tu gardes un peu de ton arrogance, ça fait partie de ton identité…..
[^] # Re: meme sa façon d'argumenter est nulle
Posté par Renault (site web personnel) . Évalué à 8.
D'un autre côté il n'a pas tort, les anti-systemd sont persuadés d'avoir raison et en critiquant le choix de systemd ils insinuent que les intégrateurs des distributions sont des idiots aussi. En tout cas ils remettent en cause leur compétence, car sinon ils n'auraient pas tous fait le mauvais choix.
Les gens qui critiquent systemd, en général, manque d'humilité. Ils ne cherchent pas à comprendre pourquoi autant de gens veulent l'utiliser et par conséquent en quoi le produit est bien. C'est un peu comme pour l'histoire du nucléaire en France, à quoi sert la commission qui s'occupe de la sécurité des centrale si derrière la population ou les politiques trouvent leurs décisions débiles, dangereuses ou autres ? À quoi ça sert de donner la responsabilité à tant de gens si derrière on remet en cause leurs décisions, autant les virer !
D'autant que la remise en cause se fait souvent sur des arguments assez simplistes et contredites un peu partout depuis…
[^] # Re: meme sa façon d'argumenter est nulle
Posté par CHP . Évalué à 9.
S'il n'a pas tord sur le fond, la forme est (comme toujours avec lui ?) détestable. C'est ça qui m'a fait réagir, bien que j'ignore pourquoi j'ai réagit sur ce commentaire et pas un autre, d'autant plus que je n'ai pas d'opinion particulière sur systemd.
Bref, ca résume bien la personne : il a souvent raison sur le fond, mais il le met dans une forme qui donne envie de lui latter les couilles avec une planche à clou rouillés (surtout quand ca se répète à chaque intervention). Mais à part ça, je l'aime bien : il m'a souvent fait considérer d'autres points de vue que je n'avais pas même entrevus. J'aimerais juste qu'il change la forme de ses propos.
[^] # Re: meme sa façon d'argumenter est nulle
Posté par anaseto (site web personnel) . Évalué à 1.
Je trouve que c'est franchement différent comme problème.
systemd c'est juste un outil, il répond à certains besoins et a certains avantages : les distributions qui veulent répondre à ces besoins l'utiliseront, les autres non. C'est juste un logiciel.
Pour ce qui est du nucléaire, ce qui est critiqué ce n'est pas que la commission qui s'occupe de la sécurité nucléaire fasse son travail, mais l'utilisation même de cette source d'énergie à la place d'autres sources, avec des arguments que chacun juge plus ou moins valides, et d'ailleurs pas forcément liés à la sécurité.
Et je ne sais pas ce que tu entends par « À quoi ça sert donner la responsabilité à tant de gens » : ceux qui critiquent les centrales ne sont pas ceux qui ont voulu créer ces responsabilités.
[^] # Re: meme sa façon d'argumenter est nulle
Posté par modr123 . Évalué à 0.
trouve dans mon message, une seule critique de systemd.
La question est pourquoi les gens n'aiment pas systemd ?
est-ce technique ?
est-ce parce que certains voient derriere systemd la mainmise de redhat sur linux dans une piece importante ?
est ce que parce que les gens n'aiment pas lennart ?
pour le reste on attends la depeche pour troller
[^] # Re: meme sa façon d'argumenter est nulle
Posté par zebra3 . Évalué à 3. Dernière modification le 12 avril 2014 à 09:40.
Quels gens ?
Que ce soit dans ce journal ou globalement sur internet, j'ai au contraire l'impression qu'il y a plus de personnes pour le défendre.
Au passage, si tu n'as vraiment aucune idée de ce qu'il apporte, ce que tu n'as vraiment rien lu, je les vois régulièrement rabachés ici.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: meme sa façon d'argumenter est nulle
Posté par Misc (site web personnel) . Évalué à 10.
Ok, alors systemd résoud plusieurs soucis.
Tout d'abord, ça permet d'arreter un démon de manière sur. Sur dans le sens ou on est sur qu'il le fait. Plus de trucs qui trainent aprés un crash d'un process lancé par apache qui lance un cgi qui lance un truc à la con qui plante en faisant un pipe.
Plus de race condition comme dans le script bind de Debian.
Ensuite, ça permet de résoudre le souci des interfaces haut niveau de pas avoir d'API à utiliser. Par exemple, un projet comme cockpit (http://cockpit-project.org/) utilise les API, au lieu de lancer le script d'init avec un code de retour non assuré. Ou ça permet de changer de maniére fiable le nom de domaine de la machine (hostnamectl), l'arrangement du clavier et de la console (localectl), l'heure et l'usage ou pas de ntp. Gnome devait avoir un code relativement compliqué pour s'adapter à la façon de faire de chaque distro pour un taf globalement la même partout, à savoir lancer ntpd.
Enfin, il permet de lancer les services dans un environnement propre. Cad sans groupe supplémentaire (genre, si le programmeur se plante et change d'abord l'uid avant le gid, si il change le gid sans mettre à zero la liste des groupes supplémentaires), sans variable d’environnement parasites (genre, si quelqu'un avec un shell en allemand relance apache, alors les pages en php vont utiliser les locales allemandes pour le tri alphabétique).
Normalement, tu es censé utilisé service pour régler le 2nd souci, mais d'expérience, tout le monde ne le fait pas. Et pour le premier, ma fois, j'ai du trouvé 3 bugs comme ça, genre https://bugzilla.redhat.com/show_bug.cgi?id=1000722 , https://bugzilla.redhat.com/show_bug.cgi?id=894626
Et ça arrive aussi à d'autres programmes :
https://bugzilla.redhat.com/show_bug.cgi?id=130112
https://bugzilla.redhat.com/show_bug.cgi?id=828436
( et ça, c'est juste dans mon historique firefox )
Et pour finir, ça réduit aussi la maintenance des distros car tu peux mettre en commun les unités de services, c'est plus facile pour les mainteneurs débutants, donc ça réduit la courbe d'apprentissage pour eux.
J'ose croire que ça réponds à la question.
[^] # Re: meme sa façon d'argumenter est nulle
Posté par zebra3 . Évalué à 4.
Mettre en commun les unités, ça va être très difficile vu que pas mal de distribs n'utilise pas les mêmes noms et chemins pour un même logiciel (l'exemple classique étant Apache sur Debian et Red Hat).
Mais le plus gros du boulot est tout de même fait : les modifications restent relativement triviales pour passer d'une distrib à l'autre.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: meme sa façon d'argumenter est nulle
Posté par Renault (site web personnel) . Évalué à 4.
Normalement cette situation est gérée contrairement à SysV… Ou en tout cas c'est une ligne à modifier bien fixe ce qui est plus simple que de chercher cela dans un script totalement différent.
[^] # Re: meme sa façon d'argumenter est nulle
Posté par zebra3 . Évalué à 7.
Hum, je ne crois pas que ça soit si simple.
Pour Apache, Debian utilise :
* le script apache2
* l'utilisateur www-data
* le démon /usr/lib/apache2/mpm-worker/apache2
* la conf dans /etc/apache2/
* les libs dans /usr/lib/apache2/
* les donneés dans /var/www/
* instructions de lancement dans /etc/default/apache2
Sous RHEL :
* le script httpd
* l'utilisateur apache
* le démon /usr/sbin/httpd
* la conf dans /etc/httpd/
* les libs dans /usr/lib/httpd/
* les données dans /var/www/html
* instructions de lancement dans /etc/sysconfig/httpd
Et bien sûr les contenus des arborescences et fichiers sont souvent différents (les conf et instructions de lancement surtout).
En une ligne, ça me paraît bien difficile même si c'est peut-être faisable.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Apache : que de différences entre deux distributions !
Posté par Sylvain Blandel . Évalué à 2.
Je suis étonné que, pour un même logiciel, il y ait autant de différences d'une distribution à l'autre ! À quoi cela est-il dû ?
[^] # Re: Apache : que de différences entre deux distributions !
Posté par Misc (site web personnel) . Évalué à 3.
Y a plusieurs raisons.
Raison historique, parfois, genre le packageur a fait ça il y a 10 ans et il change pas pour pas briser la compatibilité.
Arrangement des packageurs pour faire cohabiter 2 distros en même temps ( genre parfois /etc/toto et /etc/toto2 ), exemple, nsd sur Debian.
Parfois, le paquet rajoute des fonctionnalités en plus ( genre a2enmod pour Debian ).
[^] # Re: meme sa façon d'argumenter est nulle
Posté par Misc (site web personnel) . Évalué à 4.
Apache est un cas quand même assez extreme. À coté, tu as des trucs comme postgrey, nginx, auditd pour ne citer que 3 exemples qui me viennent à l'espirt en regardant une debian ou y a pas de souci de nommage vis à vis des autres distributions.
On peut aussi imaginer avoir des switchs de compilations comme c'est justement déjà le cas pour le placement des répertoires, et donc s'intégrer dans l'actuel.
Aprés tout, si les distributions se retrouvent à mettre des patchs sur les pages de man, c'est pas très différent.
Et on peut aussi se dire que pour les nouveaux services, le fichier sera déjà de base, ce qui va réduire les risques de divergences.
# Traduction sans valeur ajoutée
Posté par Fabrice Devaux . Évalué à -2.
Bon, en gros, cette dépêche est une traduction d'un article écrit par la personne la moins objective sur systemd, paru il y a plus d'un an.
On va en apprendre, des choses !
Je suis en train de préparer une dépêche sur la sortie de Firebird, un nouveau navigateur web meilleur que Internet Explorer 6.
# Pourquoi continuer à discuter sur ce sujet éculé ?
Posté par Sylvain Blandel . Évalué à 10.
Pourquoi ?
Les débats concernant systemd ont été forts nombreux, toutes les personnes intéressées par ce sujet ont eu le temps de lire, réfléchir et tester. Leurs opinions sont déjà faites. À quoi servira un énième débat sur le sujet ?
Totof2000 : comme beaucoup, tu n'aimes pas systemd. Il me semble que le temps passé à en discuter ici servirait bien mieux votre cause si, par exemple, vous vous proposiez de maintenir SysVinit sous Debian, ou bien si vous contribuiez à une alternative à systemd (par exemple : OpenRC). Ce travail aurait plus d'influence sur l'avenir que nos discussions à rallonge.
[^] # Re: Pourquoi continuer à discuter sur ce sujet éculé ?
Posté par Zenitram (site web personnel) . Évalué à 0.
Tu demandes beaucoup!
C'est moins marrant que de dire du mal d'autres personnes.
[^] # Re: Pourquoi continuer à discuter sur ce sujet éculé ?
Posté par vlamy (site web personnel) . Évalué à 6.
Entre développeur et moule, il faut faire un choix !
Je connais des développeurs qui n'arrivent plus à jouer sérieusement (FPS, MMORPG, etc) à cause de leur travail, j'imagine que le problème se pose également pour les moules : le développement demande du temps et de l'engagement, ce qui nuit au « moulage » (il n'y a pas de nom pour « l'action de mouler sur LinuxFr » ?).
[^] # Re: Pourquoi continuer à discuter sur ce sujet éculé ?
Posté par Batchyx . Évalué à -4.
Moi je veux bien contribuer, c'est pas comme si je récrivait jamais les scripts d'init de mes systèmes et que des gens me payait pas pour en faire.
Mais plus sérieusement: il leur manque quoi à ces scripts ? Ils sont la pour des cas d'utilisations généraux, et ils marchent. Mis à part les nettoyer un peu, il y a pas grand chose à faire.
[^] # Re: Pourquoi continuer à discuter sur ce sujet éculé ?
Posté par claudex . Évalué à 10.
Parce qu'il y a tous les jours des nouveaux logiciels et donc des nouveaux scripts init à écrire. Et les scripts actuelles ne marchent pas si bien que ça. Par exemple, sous Debian, tu te retrouve avec du code dupliqué dans plusieurs scritps pour créer des répertoires (pas pratique pour corriger un bug). Comme le fais remarquer Misc https://linuxfr.org/news/speciale-lennart-poettering-nouvelles-versions-de-systemd-et-pulseaudio#comment-1527828 , il y a certains scripts qui prennent en compte SELinux et d'autres pas (pour les mêmes actions), c'est un bug de la part de qui ?
En gros, tu as des scripts de 400 lignes que personne ne refactorise de peur de casser quelque chose. Ce n'est pas vraiment une situation idéale.
« 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: Pourquoi continuer à discuter sur ce sujet éculé ?
Posté par Batchyx . Évalué à 1.
J'en doute pas. Par contre, je vois pas comment je peux aider à écrire des nouveaux scripts d'init pour des paquets Debian qui n'existent pas encore.
J'ai plus de problèmes avec les services en eux-mêmes qu'avec leur script d'init. Mais corriger des scripts d'init reste plus facile que de corriger des services ;)
Supporter SELinux n'est pas qu'une affaire de script d'init. En fait je suis même pas sûr qu'il faille normalement gérer SELinux dans les scripts d'init.
Si tu peux pas corriger ça sans casser la LSB, je vois pas trop comment tu peux faire; Un script LSB est quand même censé être quasiment auto-suffisant et de ne rien dépendre d'autre que des helpers dans /lib/lsb/.
Ce que tu demande n'est pas de maintenir les script SysvInit, mais d'écrire un autre système d'init. Et ça je trouve ça inutile, il y a d'autres problèmes plus urgents à régler avant, autre que de nettoyer du code qui sert que pendant la première minute de démarrage.
[^] # Re: Pourquoi continuer à discuter sur ce sujet éculé ?
Posté par Misc (site web personnel) . Évalué à 6.
Je pense que tu te rajoutes une contrainte sorti de nulle part. Certains scripts debian utilise par exemple start-stop-daemon et c'est pas spécifié dans la lsb. Donc soit tu considères que les scripts sont pas portables d'une distro à une autre malgré le fait d'être lsb-compliant et donc la limitation n'a aucun sens. Soit c'est un bug, et voila ce que tu as à corriger. ( j'ai juste vu puppet, nginx, mcstrans vite fait, mais tu as le temps de faire un audit complet ).
Enfin ça, c'est si ton affirmation "il manque quoi" n'est pas juste une formule rhétorique, car la, tu sembles plus dire que y a des problèmes, mais c'est pas urgent alors personne devrait bosser dessus.
[^] # Re: Pourquoi continuer à discuter sur ce sujet éculé ?
Posté par Batchyx . Évalué à 4.
Si il n'y avais que ça … Debian en à strictement rien à foutre de la LSB. Normalement, si un script d'init LSB se rend compte que le programme qu'il est censé lancer n'est pas installé, il est censé retourner un code d'erreur bien particulier: 5. Les politiques Debian force les scripts d'init à retourner 0 dans ce cas, pour pas que ça balance des erreurs partout lorsque un paquet est enlevé mais pas purgé.
Et vu que c'est un problème politique, il suffit pas de patcher.
Oui les scripts d'init ont des problèmes, puisqu'ils ne sont pas parfait. Encore que leur problème principal est politique: personne ne veut les maintenir, alors que c'est pas bien compliqué. On pourrai très bien leur enlever de la duplication, ou les rendre plus LSB-compliant, mais pour un résultat qui ne casse pas des briques et qui n'apportera pas beaucoup de fonctionnalités.
Enfin bref, c'est qu'un système d'init quoi. Ça sert qu'a démarrer des services. Même si tu nous sort le meilleur système d'init au monde, ça ne fera juste que … démarrer des services.
[^] # Re: Pourquoi continuer à discuter sur ce sujet éculé ?
Posté par claudex . Évalué à 4.
Donc, tu as un bug à corriger chez Debian.
« 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: Pourquoi continuer à discuter sur ce sujet éculé ?
Posté par Misc (site web personnel) . Évalué à 10.
j'ai pas la bande passante pour dire tout ce qui manque, mais par exemple, le manque flagrant de suite de tests est un manque.
Upstart a une suite de test. Systemd a une suite de test. SysVInit a rien. Donc voila, commence déjà par ça.
Sauf à dire "j'ai pas besoin de tester, je sais que tout marche comme il faut".
# LinuxFr et IPOT
Posté par Le Pnume . Évalué à 8.
Nous sommes en présence de la première dépêche IPOT de Linuxfr. Le troll charge toutes dents dehors avant même la sortie de la dépêche. D'ailleurs j'ai appris que, suite à ce journal, Prumpleffer avait détaché une équipe R&D pour travailler sur l'évolution de son célèbre trollomètre.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.