SystemD: le retour de la vengeance - Page 2

(j'aurais aimer copier tous les posts, mais on est limite a 30 et on a fait bien plus de 30 posts sur le sujet )

Bref, ici c'est pour parler de SystemD, il y a assez de troll possible sur Linux pour laisser le topic linux tranquille


Une petite dose de SystemD pour bien commencer la semaine:

systemd-shitshowd
Src: https://t.co/uFwpV1CKbE pic.twitter.com/BIUtAmolxO

— Systemd Sucks (@systemdsucks) July 17, 2017

Surtout le dernier point: On utilise un truc de google, google dit "vous ne devez pas utiliser ca", réponse " google" (cf: https://github.com/systemd/systemd/issues/437 )

WAT?

edit: rah merde tu m'as doublé

XD

je me demande combien de temps encore avant que poettpoett se fasse virer de systemd

J'ai peur que ca soit difficile

Poettering dit que c'est juste le règlage par défaut que la distribution est censée changer et que pool.ntp.org ne permet pas d'offrir un réglage par défaut (ils exigent que chaque distribution ait son propre pool pour pouvoir agir en cas de bogue(s) du logiciel NTP qu'elle distribue), ça me paraît assez raisonnable comme justification.

Et pour l'histoire du "temps faux", franchement, le "temps Google" (ou idéalement, un mécanisme plus complexe qui distribue l'erreur sur plus longtemps) devrait être le standard, les minutes de 61 secondes cassent tout. Une seconde doit redevenir une approximation optimale de 1/86400 journées solaires. À bas la seconde nucléaire!

Kevin Kofler (./36) :
Une seconde doit redevenir une approximation optimale de 1/86400 journées solaires. À bas la seconde nucléaire!

Sauf qu'on se place justement dans un système qui se veut le plus indépendant possible de la localisation. Une journée solaire a tendance à changer avec le temps (la journée solaire d'il y a 1 million d'années n'a pas la même durée que l'actuelle) et, surtout, n'a plus aucun sens pour une équipe qui serait située sur Mars.

(mais ca sert a rien de répondre)

Kevin Kofler (./36) :
Poettering dit que c'est juste le règlage par défaut que la distribution est censée changer et que pool.ntp.org ne permet pas d'offrir un réglage par défaut (ils exigent que chaque distribution ait son propre pool pour pouvoir agir en cas de bogue(s) du logiciel NTP qu'elle distribue), ça me paraît assez raisonnable comme justification.

Non :

- le propriétaire des serveurs a demandé publiquement qu'on ne les utilise pas, la moindre des politesses c'est de le respecter

- il est de toute façon aberrant qu'un soft libre comme systemd dépende d'un service d'une boîte propriétaire

- s'il n'y a aucun réglage par défaut qui convienne, la bonne solution est de ne pas avoir de réglage par défaut. Les seuls utilisateurs impactés sont des gens qui sont suffisamment compétents pour choisir eux-mêmes, et c'est beaucoup plus sûr que d'avoir un truc qui fonctionne "par hasard" (et qui peut casser du jour au lendemain sans préavis).

c'est le bon sens même.

Et si google a ouvert ce bug report, c'est pour la simple raison qu'il y a un certains nombre (probabmelent grand) de requetes qui sont faites par SystemD pour qu'ils l'ai detecté.

oui, probabmelent.

Of course, if Google explicitly doesn't want us to use the service even for this kind of testing setups, even if we acknowledge that it isn't accurate and not officially supported, we could remove the reference entirely. Can you elaborate on this?

Again, all downstream distros I am aware of have their own ntp.org vendor pools anyway, and set them at ./configure time. Only folks who build everything from source on their own, without using any kind of prepackaged distro would run with these defaults. Hence the default should really doesn't matter too much in real life.

Vous êtes en train de lui reprocher un corner case qui ne doit pas dépasser le millionnième d'installation de linux quand même...
Et il est complètement ouvert à une meilleure solution que vous pourriez lui proposer :

shitty servers as default are better than none. If you let me know a set of servers that are openly accessible, that do not require registration as a vendor or product and are better then the shitty servers then let me know and we can switch over

De plus, il y a maintenant un warning pendant le configure, donc même les amateurs de LFS seront au coutant.

D'habitude j'aime pas top non plus les façons de faire du bonhomme, mais là je vois pas trop ce que vous pouvez demander de plus...

Peut-être, mais ça fait toujours plaisir de critiquer
Et j'ai déjà vu un de mes systèmes s'arrêter de booter parce qu'une partition sans intérêt était mal montée, alors je considère qu'il a tort.

Folco tu as raté cette partie:

The subtext here is that Google very likely noticed systemd's usage because they were watching NTP very closely today, and if I'm reading @isomer correctly, Google does not want this default in the software at all -- so I'm not sure where you're getting "good enough" from.

Si google en surveillant leur serveur NTP a remarqué que SystemeD faisait des requetes chez eux ça veux dire qu'il y en a un nombre consequent.

Et le warning est absurde, car les warning sont (comme dit dans un des commentaires) dans la majorité des cas ignoré. La solution est tres simple: ne rien metre par defaut comme le font TOUT les client NTP dans leur config de base, c'est a l'utilisateur (ou a mainteneur de distrib) de mettre une valeur, et ce n'est pas une modification dans du code comme l'est pour SD la, mais un fichier de config.

La config de SD est quand meme fait dans le fichier configure.ac, soit avant meme que SD soit compilé! (cf: https://github.com/systemd/systemd/pull/439/files )

Si google en surveillant leur serveur NTP a remarqué que SystemeD faisait des requetes chez eux va veux dire qu'il y en a un nombre consequent.

pas forcément, ça peut simplement être sur les plages d'IP ^^

(alors que si les mecs de chez Google avaient un peu d'humour, ils répondraient "premier janvier 70" quand ils détectent une requête "non souhaitée" due à systemD )

flanker (./47) :

Si google en surveillant leur serveur NTP a remarqué que SystemeD faisait des requetes chez eux va veux dire qu'il y en a un nombre consequent.

pas forcément, ça peut simplement être sur les plages d'IP ^^

Je vois pas le rapport ?!


Mais quoi qu'il en soit, google est venu, a dire "stop", LP a dit "rien a foutre je change pas" c'est pas normal. Et meme si il y a un warning, le warning ne change pas que personne (ou presque) ne regarde la sortie de autoconf/configure

Google a demandé d'arrêter pour des questions de fiabilité qu'ils se refusent à fournir, aucunement pour des questions de charge. Si c'était le cas ils ne se seraient certainement pas gênés pour le dire.

Là, tout se qui risque de se passer, c'est que Poettering se retrouve le bec dans l'eau le jour où Google coupe son service sans préavis.

(ps -> faut pas être malin pour prétendre builder un système from scratch et surtout ne pas s'intéresser aux warnings)

(http://www.commitstrip.com/fr/2015/04/27/the-eye-opener-commit/ )

(Folco > c'est rigolo de te voir dire ça, parce que je suis sûr que si je te reportais un bug dans un de tes softs, tu mettrais un point d'honneur à le corriger)

Quand tu es le mainteneur officiel d'un module majeur comme systemd, on s'attend à ce que :

- tu aies suffisamment de jugeote pour ne pas faire dépendre ton soft libre d'un service propriétaire

- si malgré tout tu utilises un service propriétaire, tu fasses l'effort de lire la doc et de respecter les conditions d'utilisation

- tu saches qu'un mauvais réglage par défaut est bien pire que pas de réglage du tout (à ton avis, mieux vaux une distro qui ne te laisse pas utiliser le compte root tant que tu ne lui as pas attribué de mot de passe, ou une distro qui utilise "password" par défaut ?)

- quand on te reporte un bug qui impacte des tiers qui ne sont pas tes utilisateurs (Google en l'occurence) et qui est en plus trivial à corriger, tu le corriges immédiatement, plutôt que d'exiger que ce soit ceux qui te rapportent le bug qui te fournissent une solution (et de rejeter la solution évidente).

Le fait que ce soit un "corner case" n'est pas une excuse : ce genre de comportement n'est pas acceptable pour un développeur, et il l'est encore moins quand tu gères quelque chose d'aussi critique que systemd.

(mégacross)

Ca se tient aussi, c'est sûr...

je crois qu´ il t'a eu, la, godzil

This is what nightmares are made of https://t.co/Kcn2OcU4Jg

— Systemd Sucks (@systemdsucks) July 18, 2017

The next step is clearly to run systemd directly in the intel management engine.

— Automaton (@automatonof) July 17, 2017

Systemd-processor!!!!!

Pitié, ne lui donnez pas des idées...

Pleins de petits utilitaires independant hein:

Make each program do one thing well. pic.twitter.com/SRc4121FJ7

— mulander (@mulander) July 18, 2017