freem a écrit 4918 commentaires

ET (on l'a vu également avec pulseaudio) lintégration avec un niveau de finition inadéquat avec un système en production car le release early c'est bien dans l'absolu, mais lorsque ca casse ton système, lorsque ce qui marchait avant ne marche plus, tu n'as pas envie de faire des bisous aux bisounours.

Le release early, release often est une bonne chose, pour les projets KISS (dont systemd ne fait clairement pas partie j'ai l'impression). Pour les autres, ça reste à définir…

Je suppose que ça dépend des usages, vu que perso j'ai jamais eu de problèmes de son. Mais bon, je me contente d'écouter de la musique, regarder des vidéos sur you…tube et de jouer alors forcément…

Soit tu réponds à autre chose (je pense que c'est ça ) et dans ce cas je me permets de rappeler ce dont on parle ici:

Tu as oublié le plus horrible : le code lui même mis en commentaire suite à des modifications.

Soit je n'ai rien compris à ton propos, soit tu dis n'imp.

On parle de code qui fut utile un jour, et qui ne l'est plus. En général, ce type de code est le résultat d'un bug ou d'une évolution, et l'on à donc mis en commentaire l'ancien pour y revenir plus vite si la nouvelle version merde.
Au bout de 10ans, tu peux te retrouver avec 3 versions de la même fonction, 2 bugguées (mais tu ne sais pas quel était le bug) et 1 est une ancienne version complète…

Et quand tu dois attaquer un petit code source de, disons, 5000 lignes, et que tu te retrouves avec 200 lignes de zombies, ben voila, ça aide pas à la compréhension.

Ils trollent nettement moins que d'autres

Certes.

et Linus code moins qu'avant, il relis/fait des choix, c'est ça d'être vieux

Ce qui est un travail également, auquel de nombreux logiciels (libres ou pas. À la rigueur, libres et faits par des bénévoles, je dirait qu'en général c'est fait et qu'au pire, ça reste du bénévolat, donc excusable. Les autres, non.) devraient affecter un peu de main d'œuvre à ça.

Tu veux dire que Linus et Lennart ne boosent pas? :p

Mouai… il paraît que c'est à ça que servent les VCS, en fait. Avoir le source d'origine, et la liste des patchs qui y ont été appliqués avec en prime, un commentaire de leur auteur.

Non non, c'est ce que j'appelle du code zombie :) il est mort mais pas totalement…

Quand je distribuais mes annuaires il y à 6 ans, un bon 60% de BaL l'étaient. En campagne.

Je n'ai pas de lien particulier, juste des prof/intervenants de droit qui me l'ont dit dans diverses formations (pas les mêmes formations, pas au même endroit et encore moins les même profs).

En gros, c'est relatif au fait qu'on à pas le droit de déposer ses "ordures" chez les gens, propriété privée. La boîte au lettre (et la voiture) faisant partie de la propriété privée, si je me souviens bien de leurs explications.

Je n'ai même pas regardé ton code source…

Un source, ça n'existe pas. Une source, à la rigueur… mais ce n'est pas la même chose.

C'est ça. Sentiment partagé, rassures-toi, mais dans ce type de code les commentaires sont un mal nécessaire, et on ne peut nettoyer le bordel que petit à petit… et croiser les doigts pour ne rien casser au passage.

Si le code est moche, il vaut mieux le changer, il y a de grande chance que malgré le commentaire, il pose problème plus tard.

Ce n'est pas toujours possible, pour diverses contraintes.
Genre: usine à gaz qui pète à la moindre modif (cause principale: variables globales, je vous hais!), manque de temps, fonction qui fait le café, le thé et accessoirement qui effectue une tâche utile, etc.

et il me semble qu’il y en a aussi sur Debian et Ubuntu.

Pour Ubuntu je ne sais pas. Pour une Debian "classique" avec grub, systemd et gnome, je ne sais pas non plus.
Mais chez moi (enfin, à mon taf sur mon desktop):

/etc# grep -ri "^#.*gener"|cut -d: -f1|uniq
krb5.conf.orig
mailcap
fpc-2.6.4.cfg
i3/config.keycodes
cron.daily/man-db
cron.daily/sysstat
pulse/client.conf
texmf/texdoctk/texdocrc.defaults
texmf/fmt.d/00tex.cnf
ca-certificates.conf.dpkg-old
bash_completion.d/libreoffice.sh
init.d/virtualbox
init.d/udev-finish
backup-manager.conf
ssl/openssl.cnf
kernel/postinst.d/apt-auto-removal
ca-certificates.conf
mpd.conf
mpd.conf.dpkg-dist
X11/Xwrapper.config
ssh/sshd_config
ssh/moduli
awstats/awstats.conf
cron.d/awstats
cron.weekly/man-db
default/awstats
default/nss
default/locale
default/useradd
udev/rules.d/70-persistent-cd.rules
udev/rules.d/70-persistent-net.rules
init/binfmt-support.conf
init/udevmonitor.conf
init/udev-finish.conf
openal/alsoft.conf
selinux/semanage.conf
locale.alias
cups/cupsd.conf.default.dpkg-new
dkms/template-dkms-mkdeb/debian/postinst
gftp/gftprc
sensors3.conf
manpath.config
pam.d/sshd
sysstat/sysstat.ioconf
sysstat/sysstat

Sachant bien sûr, que cette liste contiens énormément de faux positifs. En regardant de plus près, j'ai:

• mailcap
• fpc-2.6.4.cfg (que je devrais d'ailleurs dégager, finalement je n'ai pas eu à faire de pascal…)
• fmtutil.cnf (en fait, il est mentionné dans texmf/fmt.d/00tex.cnf que "In Debian, fmtutil.cnf is a file that is generated from configuration files in /etc/texmf/fmt.d/. This file, 00tex.cnf, contains only some comments on how to edit these files.")
• ca-certificates.conf.dpkg-old
• ca-certificates.conf
• X11/Xwrapper.config
• ssh/sshd_config (mais bon, en fait il est généré par le paquet, alors je ne sais pas si il est pertinent de l'avoir dans cette liste…)
• default/locale
• udev/rules.d/70-persistent-cd.rules
• udev/rules.d/70-persistent-net.rules

Mais il est vrai que je n'ai que 1028 paquets installés, dont la moitié sont des lib et ~70 libs de dev. Un système léger quoi (pas de DE, ça doit jouer à mort). Ceci dit, je pense que Debian reste malgré tout peu génératrice de config, pour éviter d'avoir un niveau trop peu élevé de "bidouillabilité".

Je préfère 10x un nom parlant à des commentaires.

Je suis d'accord, mais parfois il n'y à pas le choix.

Je connais 2 sortes de commentaires

Tu as oublié:

• le code zombifié,
• les notes style TODO,
• ceux qui disent ce que le dev pense de son propre code,
• ceux qui résument une ligne longue comme le bras et illisible, genre quand la ligne inclue des appels à std::mem_fun, std::bind1st, ou std::bind2nd (je sais, depuis C++11, on peut simplifier considérablement ça, mais on ne peux pas l'utiliser partout, le C++11…)
• ceux qui parlent des règles de gestion stupides
• ceux qui permettent de générer une doc

Mais c'est clair: je suis aussi du genre à préférer éviter les commentaires que je le peux, par exemple un truc genre "i = 2* 3.14 * r; //3.14 is PI" n'apparaîtra jamais dans mes codes. Je préfère faire une constante et lui filer la valeur 3.14… bon, avec PI, c'est trivial, mais un autre exemple déjà cité ici: i = 0x5f3759df - ( i >> 1 ); montre que ça ne l'est pas toujours… (oui, je trouve ce truc crade, peu m'importe qui l'a écrit à l'origine. Les magic values, c'est déjà pas top, mais quand en plus c'est pas mis dans des constantes… berk)

Sinon, y'a pas que les tinaïdjeurs qui parfois ont l'obligation de faire un taf de merde :)

Yep, surtout quand tu as laissé ta bagnole toute la journée sur un parking (de gare, par exemple) et qu'il à flotté à sceaux…

Je suis bien certain que tu es certain d'avoir peur des certitudes…

Laisser vide 2 des 4 instructions faisant partie de la boucle for

Des 4? Tu considères donc le corps d'une boucle comme partie intégrante de la boucle?
Pas moi, mais c'est une question d'opinion j'imagine.

Mais du coup, dans mon opinion, il n'y à donc qu'un champ sur 3 qui n'est pas utilisé, et il s'agit de l'initialisation de la boucle. Ce champ est régulièrement laissé vide, pour un tas de raisons.

"truc très élégants […]", il y a aussi Ségolène Royal

Élégant? Euhhhh si on veux… les goûts et les couleurs après tout…

Accessoirement, si le code n'est, par malheur, pas assez parlant lui-même, il reste les commentaires. Les commentaires qui peuvent aussi servir à pointer un endroit ou l'on à du tordre le code pour obéir à des règles métier un peu farfelues, ou parce que le code avec lequel on interagit (et sur lequel on à bien entendu aucun pouvoir) est buggué/complexe/bancal.

Je pense que tout le monde sera d'accord avec moi pour dire que quand on maintien du 10 ans d'âge, on fait attention quand on refacto, et même si c'est hyper tentant de refacto en masse, il faut savoir se contenir…

Donc, je suis complètement d'accord avec toi :)

On pourrait aussi rendre obligatoire la boîte aux lettre et remédier au problème des monceaux de pubs non sollicitées, par exemple par une loi rendant l'autocollant "Stop Pub" contraignant.

Ça ne servirait à rien. Parce que, en fait, une telle loi existe déjà: c'est illégal, de mettre de la pub dans une BaL, sauf si la personne à déjà fait montre d'un intérêt envers la pub en question. Autrement dit, si tu as une carte de fidélité machin, machin aura le droit de te spammer.

Donc, le problème n'est pas de passer une loi, mais de forcer ces emmerdeurs à la respecter, tout simplement.

Et puisque ça me gonfle sérieux aussi, je ne les qualifierai pas que d'emmerdeurs, mais aussi d'êtres irresponsables qui pourrissent notre planète avec du papier glacé et en dégommant quantité d'arbres pour rien. En fait, j'ai envie d'utiliser un terme bien plus puissant qu'emmerdeurs…
Mais d'un autre côté, c'est un truc qui fait vivoter (parce que livrer de la pub, je doute que ça paye plus que livrer des annuaires, chose que j'ai faite, et ça paye que dalle ou presque, surtout si on respecte la procédure qui implique de d'abord aller toquer pour livrer en main propre, et pire si on se voit attribuer un village genre cambrousse profonde) un certain nombre de gens (les petites mains qui livrent et que l'on maudit).
Donc, je ne réserve pas mes noms d'oiseau à ces gens, mais à ceux qui les payent: si le système est le même que pour les annuaires, ils sont payés au nombre de déchets déposés dans les BaL. Pour qu'ils respectent les "pas de pub", il faudrait qu'ils ne soient pas payés à la performance, mais sur un salaire fixe.

Je trouve bien xpath, mais pas moyen de mettre la main sur un man de xfind. Tu aurais une URI?

Je ne suis pas admin sys,

Je suis aussi loin d'être admin, mais j'essaie de me mettre aux scripts shell, parce que c'est vraiment puissant, même à mon très faible niveau.
Par exemple, quand on doit se taper des comparaisons de fichiers de log qui peuvent différer d'un serveur à un autre, ou d'une date à une autre, pour trouver des infos supplémentaires au sujet d'un bug qu'il faut corriger.
Ou quand on est dans une petite boîte et qu'il faut modifier une entrée SQL dans 5 bases de données, répliquées sur un autre serveur ( ce qui fait donc 10 fois la même manipulation à faire, à la main… c'est ce que mes collègues faisaient, c'est ce que je refuse de faire. ).
Pour ces situations, écrire un programme complet serait un peu overkill, quand on peut coder ça en 10-20 lignes de shell.
En fait, dans ma boîte je fait un peu de tout, sûrement pas du grand art, mais bon, faut bien que quelqu'un le fasse, et j'avoue que ça ne me déplaît pas. Tant qu'on me demandera pas de faire ce genre de trucs sur des serveurs windows du moins :)

Malheureusement, sed/cut/grep et Cie sont en effet assez peu adaptés à la manipulation des fichiers de conf (même textuels),

Si, ils sont très efficaces quand il s'agit de gérer des fichiers de type clé=valeur, genre INI ou… en fait la plupart de ce que je trouve dans mes /etc.

Ce n'est pas parce que c'est un *-like, que c'est moins bien ou pas pertinent. Au contraire, surtout que toi, tu utilises une approche radicalement différente (xml au lieu de langage de script).

Je ne sais pas si tu publies tes scripts, mais je pense qu'ici plusieurs seraient intéressés, à lire les différentes interventions.

Qu'est-ce qui te force à utiliser udev?