Anonyme a écrit 62265 commentaires

si un dialogue constructif s'était ouvert dès le début, en lieu et place de l'agressivité de Kay Sievers

Il y a eu de l'agressivité des 2 cotés, pas uniquement de Kay.

Les extraits de codes produit ici sont hallucinants.

Oula, ne regarde surtout pas le code de Linux, Xorg, la libc et autres alors !

Je crois plutôt que c'est le ton, la tournure qui ne te conviens pas.

je te confirme: j'ai trouvé le ton condescendant, ce qui tranchait avec ta réponse précédente.

Finalement, je ne pense pas une seconde qu'en postant cela sur github il trouvera beaucoup d'echo à son appel de pied, je peux toujours me tromper, supposons, mais mon constat est que sur github il y à plus de pleureurs que de faiseurs.

En tout cas, c'est parce que son code a été mis sur github qu'il a pu bénéficié de tes conseils

mes 2 cents car je suis très soulé que ton poste paternaliste soit applaudit ainsi.

ne pleure pas si vite: mon poste paternaliste a démarré à 2 et ne semble avoir été applaudi, à cet instant, que par NomadSoul, pour atteindre le score extraordinairement mirifique de 3 ! On est donc loin de l'encensement de masse du paternalisme.

Conformisme quand tu nous tiens … .

bouh les méchants … ;)
Si on remettait les choses à leur place ?
1/ tu fais une réponse constructive,
2/ tu rajoutes une commentaire pour expliquer que finalement il aurait du bosser plus avant de rendre public son code, sur un ton qui tranche avec ta première réponse,
3/ je te fais remarquer qu'il y a une contradiction, sur le fond comme sur la forme, entre tes deux commentaires

Ça te semble vraiment culminer à un seuil si intolérable pour se vexer ou crier à la domination paternaliste de la pensée unique ?
si c'est le cas, toutes mes excuses pour t'avoir soulé, mais honnêtement, ne devrais-tu pas essayer la camomille ? (ok, la c'est moi qui suis condescendant … et pour le coup réellement paternaliste :) )
Sans rancune si je passe à autre chose ?

et pour finir sur du positif, merci pour les différents liens de ton premier commentaire.

Le bug aurait été évident.

Le bug était deja evident si on lit le code attentivement pour remarquer le - en trop. Avec ce commentaire la ca ne change rien, ca ne met pas en evidence le - qui est en trop. Moi en fait un commentaire aussi long pour un truc comme ca, je ne le lis meme pas.

On a pu déduire que c'était un bug, mais ça aurait aussi pu être un hack dégueu qui fonctionne.

Ca aurait aussi pu etre une erreur dans le commentaire. Le seul moyen d'en etre sur c'est d'aller lire le code de la fonction qui est appellée pour voir ce qu'elle retourne.

Et c'est en postant sur github qu'il aura un retour comme celui que tu as pu lui apporter et qu'il s'améliorera dans ce domaine: j'ai apprécié ton premier commentaire qui était constructif et instructif; celui-ci beaucoup moins.

Et un type sur un forum a appliqué ces règles dans son code et s'est rendu compte de la même chose, et ne comprend pas que des devs soit-disant "pro" n'appliquent pas certaines de ces règles.

Ils appliquent d'autres regles que celles que tu as décreté comme étant les bonnes, par ce qu'ils ont l'habitude de développer, et en appliquant leurs regles ils se sont rendus compte qu'ils écrivaient du code plus lisible et plus maintenable.

Moi ca ne me choque pas. Je prefere largement un code avec très peu de commentaires, sauf aux endroits ou il y a un truc particulier pas simple à comprendre, qu'un code bourré de commentaires.

En general avec le code bourré de commentaires:
- on ne voit plus les trucs particuliers, puisqu'il y a des commentaires partout
- on a vite fait d'updater le code en oubliant de mettre à jour le commentaire, qui devient alors faux
- on se met à lire les commentaires au lieu de lire le code, ce qui peut nous induire en erreur quand le code ne fait pas exactement ce que dit le commentaire

Et puis en cas de doute sur la raison de la présence d'une ligne, il y a 'git blame' qui permet de voir le message de commit qui peut aider à comprendre.

Commenter le code aussi ça prend du temps, mais s'il avait été commenté, il aurait peut-être été plus clair que "return -r;" était un bug.

Non, ce genre de typo, ca arrive que le bug soit commenté ou pas. Et puis on ne peut pas non plus se fier au commentaire, parfois le code est bon, et c'est le commentaire qui est faux.

J'en ai un peu marre de l'argument "oui mais c'est un pro, il sait ce qu'il fait, il doit bien avoir des raisons que tu es trop con pour comprendre". Pour que ça soit vrai, il faudrait pouvoir éliminer l'argument "flemme de coder proprement".

C'est pas "flemme de coder proprement" mais "flemme de coder en rajoutant de la complexité qui sert à rien par ce qu'un type sur un forum a décreté que c'est comme ca qu'on faisait du code propre et pas autrement".

Au passage, je sais que git n'est pas un composant critique en terme de sécurité, mais ça ne coutait pas grand chose de mettre des strNcmp.

Ca servirait à quoi ?

D'ailleurs, il y en a un au milieu qui est un memcmp, ça ne doit pas être la même personne qui l'a écrit, celui là :)

C'est la meme personne, mais il y a une raison pour utiliser memcmp et pas strcmp dans ce cas la. Ca permet de ne regarder que les 2 premiers caracteres.

Le coup du gros bloc de if avec des str(n)cmp, je trouve ça assez moyen (euphémisme)

Ben pourtant c'est une methode assez classique pour parser des arguments/options dans un format basic. Par exemple dans git:
https://git.kernel.org/cgit/git/git.git/tree/builtin/commit-tree.c#n43

Moi, c'est comme ça que je code, et pour des appli perso qui n'ont rien à voir avec la complexité et le caractère critique de systemd. Je suis juste surpris que des programmeurs professionnels de haut niveau ne respectent pas les consignes de base qu'on donne aux étudiants, et ont du mal à avoir un regard critique sur le code des autres : dans cette discussion, il y a plein de gens qui se prétendent programmeurs C qui ne voient rien à redire au code cité.

Par ce que les consignes données aux étudiants, c'est des conseils sur une bonne facon de faire du code, qui aident pour apprendre, mais certainement pas des regles à respecter au pied de la lettre quand on sait ce qu'on fait. Par exemple beaucoup de profs disent qu'ils ne faut absolument jamais utiliser de goto, mais c'est faux, il y a pleins de cas ou cela peut etre bien utilisé.

Et il y a des profs qui disent qu'il faut toujours utiliser des constantes, et c'est sans doute une bonne regle à respecter quand on apprend à programmer. Mais quand on a compris l'interet des constantes et dans quel cas ca ne servait à rien on est pas obligés de respecter cette regle de facon systematique.

De toute facon un prof n'est pas un dieu qui connait LA bonne facon de faire du code. Par ce qu'il n'y a pas une seule bonne facon de faire, et chacun peut avoir son propre style. Et puis il peut aussi se tromper.

Bref, on peut imaginer qu'un jour, on puisse vouloir changer les permissions attribuées au fichier, et ce jour là, il faudra que le patch modifie des trucs partout dans le programme, avec de grosses possibilités de bugs ou de modifs non nécessaires, parce que le programmeur initial n'a pas indiqué la sémantique (qu'il connaissait pourtant). Juste en définissant dans un header PERM_ACCESS_PASSWD à 0700, le code n'est pas moins lisible, il n'est pas moins portable, il est juste mieux organisé avec toutes les permissions dans un seul fichier, les unes à la suite des autres : en un coup d'œil, on a l'intégralité de la logique de la gestion de permissions dans systemd.

Bravo et le jour ou tu as besoin de changer la permission sur le fichier, tu modifies la constante en oubliant qu'elle est aussi utilisée pour les permissions d'un autre fichier qui ne doit pas avoir ses permissions modifiées.

Et je vois pas l'interet de regrouper en un seul endroit toutes les permissions, surtout avec des noms aussi peu claires que "PERM_ACCESS_PASSWD" ou tu n'as aucune idée de quel fichier ca parle. Si tu veux voir toutes les permissions d'un coup tu fais un "ls -lR /run/systemd". Et si tu veux voir exactement comment elles sont gerées, tu lis le code, ce que tu devrais faire aussi si il y avait des constantes puisque tu ne peux pas deviner comment elles sont utilisées précisement.

Le nom de la constante non plus. Et si la raison pour laquelle le fichier est utilisé n'est pas evidente, on rajoute un commentaire.

Utiliser une constante definie plutot qu'un chiffre est toujours la bonne chose a faire.

On parlait d'une constante pour un nom de fichier.

A) Parce que ca donne un nom a la valeur, qui explique ce qu'elle represente, sans empecher la lecture car tout IDE qui se respecte montrera la valeur

Le nom de fichier c'est deja un nom. Aucun interet à un rajouter un different.

Après, je ne sais pas comment ça se passe en interne, mais je trouve plutôt drôle que ce Kay Sievers déclare ne pas vouloir discuter le sujet dans Bugzilla parce que "ce n'est pas un bug", mais ne participe pas non plus en fait à la discussion sur la mailing-list de systemd. Je vois plusieurs hypothèses pour expliquer ça:
-il est borné comme une autoroute et donc refuse ne serait-ce que de discuter la question, ou il boude
-il s'est fait prié de la mettre en veilleuse en message privé
-autre?

Ou peu etre qu'il n'a juste pas encore eu le temps de répondre / il est occupé à autre chose. La discussion sur la ML n'a été ouverte que aujourd'hui.

Bref il n'y a pas grand-chose à redire à ce bout de code.

Oui, tout comme dans celui de systemd qui a été cité.

J'ai pris cgroup.c par ce que c'est le premier fichier que j'ai ouvert, au hasard. On trouve le meme genre de code ailleurs dans le kernel.

De toute facon les cgroups ne sont pas utilisés que par systemd, et si le code a été accepté c'est qu'il répond aux critères de qualité du kernel.

Ah oui ? Tu utilises quoi pour evaluer ca ?

De nouvelles versions de systemd sortent très regulierement avec des tas de nouvelles fonctionnalités, sans regressions importantes.

Et ca change quoi ? Les cgroups existaient avant systemd, ce code n'a pas été écrit par les developeurs de systemd, et il fait partie du kernel.

Mais ce code qui a ete poste la, il est moche,

Du code moche ca veut dire quoi ?

pas facilement maintenable,

Les developeurs de systemd ne semblent pas avoir de problème particulier pour le maintenir.

pas facilement portable.

Ne pas etre portable sur d'autres OS est un choix des developeurs de systemd, pour simplifier le code.

Pas, c'est aussi valable que de vouloir changer le nom d'un fichier. Ca dépend du point de vue.

L'utilité de booter un autre OS, c'est un truc qui se justifie facilement. Changer un nom de fichier sans donner de raison particulière non.

Donc il faut accepter quand Microsoft décide de ne pas te simplifier la vie lors d'un boot, il a décidé que c'était mieux.

J'accepte que Microsoft fasse ce qu'ils veullent. J'utilise pas leur produits et voila.

/proc c'est vraiment très très spécial. Je crois me souvenir qu'il y avait des raisons techniques pour forcer l'arborescence

Et /run/systemd c'est aussi très spécial, et il y a des raisons techniques pour forcer l'arborescence.

C'est EXACTEMENT ce que répond Microsoft quand tu demande pourquoi il n'est pas prévu de booter un autre OS.

Sauf que ca n'a rien à voir. Booter un autre OS c'est une raison valable d'avoir une option pour ca. Changer le nom d'un fichier juste pour le plaisir de le changer, non.

Ce n'est pas à toi de décider s'il y a des raisons valables de faire quelque chose ou non. Surtout pour du code libre : après tout, il est fait pour être réutilisé.

C'est au developeur de choisir quelles parties il veut rendre configurables ou pas. Et au pire tu peux toujours patcher le code pour faire ce que tu veux, mais c'est pas au developpeur de se compliquer la vie pour te faciliter la tache pour faire un truc qu'il estime ne pas etre une bonne chose à faire.

Et comme deja dit, il est toujours possible d'envoyer un patch pour rajouter l'option si vraiment ca sert à quelquechose.

En fait on s'en fiche de ça. Ce que je voulais te dire, c'est que quelqu'un qui n'est pas dev C et qui dit approximativement n'importe-quoi, ce n'est certes pas étonnant par contre c'est assez prétentieux.

En lisant les commentaires qui succèdent au tiens, on trouve pleins de bonnes réponses qui ne peuvent qu'être confirmées… et qui confirment que les critiques négatives que tu exposes ne sont pas ou peu valables.

Voilà voilà.

Je regarde un fichier du kernel au hasard, par exemple kernel/cgroup.c, et je tombe sur la fonction parse_cgroupfs_options:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/kernel/cgroup.c#n1129

Fonction de 150 lignes. 4 niveaux d'imbriquation. Des "return -EINVAL" et pas de variable retval. Des if sans {} sur plusieurs lignes. Les noms des options hardcodés sans un define.

En gros, comme ce qui est reproché au code de systemd.