Benoît Sibaud a écrit 8924 commentaires

Pour LinuxFr.org, les dons sont rares et donc facilement rapprochables, et ce pour deux raisons :

• la première c'est que la personne vient de nous demander l'IBAN et que c'est probablement la seule sur plusieurs semaines
• la seconde c'est que c'est un pur don, donc d'un point de vue comptable, il suffit de l'affecter au bon compte indépendamment de savoir qui l'a fait (enfin sauf si on nous file des k€ par brouette, mais le cas ne s'est pas présenté)… L'info qui nous intéresse est de savoir si on doit ou non afficher le nom du donateur sur la page des dons, et là il faut qu'on sache qui a donné.

Pour d'autres structures genre April qui gèrent des milliers d'adhésion et potentiellement bien plus de dons que LinuxFr.org, la situation est plus délicate niveau comptabilité.

Autre exemple, LinuxFr :

Si vous préférez effectuer un virement bancaire, vous pouvez nous contacter, nous vous ferons parvenir les informations nécessaires (IBAN).

Un mini-hackathon, c'est plein de gens qui bossent sur leur portable, c'est difficile à filmer/retransmettre, sauf à donner une vision large d'une salle avec des petits groupes qui parlent devant un écran et des geeks scotchés sur leur portable. Ça reste peu télégénique. Par contre, faire un compte-rendu a posteriori, oui évidemment.

Par exemple http://april.org/association/adhesion.html (pour une adhésion donc, pas directement un don régulier) : « Une fois adhérent vous disposerez de cinq moyens de paiement : paiement en ligne par carte bancaire, prélèvement automatique, virement, chèques, espèces.  » (j'ai ajouté le gras)

Et a-t-on inventé un gestionnaire de gestionnaires de config pour faire facilement abstraction des différences entre les gestionnaires de config et ne pas avoir à maintenir plusieurs scripts différents ?

(sinon je fais de l'ansible, spéciale dédicace à lukhas)

Corrigé, merci.

Quand tu t'abonnes, tu n'as pas encore d'identité connue sur le site en question, pas de contenus, pas de commentaires. Quand tu te désabonnes, tu peux (si ça entraîne des suppressions/dépublications) perdre ton identité et la notoriété associée, tes contenus, tes commentaires et ça peut être irréversible. Il ne me semble pas si choquant que ça soit un peu plus compliqué qu'un simple clic, qui pourrait être fait par n'importe qui ayant accès 2s à ton navigateur (incluant ton collègue de bureau détesté, ton chat, etc.). Je ne justifie pas la nécessité d'un recommandé avec A/R, mais juste le besoin d'une vérification minimale.

Je dis ça par expérience car LinuxFr.org réouvre régulièrement des comptes, parce que l'on reçoit des demandes de fermetures/purges par courriel (qui nécessite une confirmation pour éviter une simple usurpation d'identité), etc.

Merci pour ces infos, ajoutées à la dépêche annuelle sur les dons, actuellement en préparation dans l'espace collaboratif de rédaction.

Le message dit « This site uses HTTP Strict Transport Security (HSTS) … not possible to add an exception for this certificate … uses an invalid security certificate » : bref le site exige/impose HTTPS et cela n'est pas possible pour cause d'expiration du certificat, donc le site était inaccessible (et pas juste accessible avec une alerte sécurité contournable). Et je n'ai rien pour ou contre Devuan.

Corrigé, merci.

C'est le bon canal. Et le micro-patch à prévoir est s/suffisament/suffisamment sur app/views/static/submit_content.html.haml

Corrigé, merci.

Corrigé, merci.

Pour illustrer la remarque, avec 100000 fichiers, on a 100001 processus (un find et 100k grep), 8 processus (un find et 7 grep), 9 processus (un find, un xargs et 7 grep), respectivement.

plutôt qu'un print pour un xarg; autant attaquer directement le fichier.

ça coûte pas le même prix.

$ for i in $(seq 1 10) ; do echo coin > $i ; done   # 10 fichiers contenant "coin"
$ strace -f -o "|grep execve" -e execve find . -type f -exec /bin/grep -s coin {} >/dev/null \;
15273 execve("/usr/bin/find", ["find", ".", "-type", "f", "-exec", "/bin/grep", "-s", "coin", "{}", ";"], [/* 67 vars */]) = 0
15275 execve("/bin/grep", ["/bin/grep", "-s", "coin", "./1"], [/* 67 vars */]) = 0
15276 execve("/bin/grep", ["/bin/grep", "-s", "coin", "./7"], [/* 67 vars */]) = 0
15277 execve("/bin/grep", ["/bin/grep", "-s", "coin", "./10"], [/* 67 vars */]) = 0
15278 execve("/bin/grep", ["/bin/grep", "-s", "coin", "./3"], [/* 67 vars */]) = 0
15279 execve("/bin/grep", ["/bin/grep", "-s", "coin", "./4"], [/* 67 vars */]) = 0
15280 execve("/bin/grep", ["/bin/grep", "-s", "coin", "./2"], [/* 67 vars */]) = 0
15281 execve("/bin/grep", ["/bin/grep", "-s", "coin", "./9"], [/* 67 vars */]) = 0
15282 execve("/bin/grep", ["/bin/grep", "-s", "coin", "./6"], [/* 67 vars */]) = 0
15283 execve("/bin/grep", ["/bin/grep", "-s", "coin", "./8"], [/* 67 vars */]) = 0
15284 execve("/bin/grep", ["/bin/grep", "-s", "coin", "./5"], [/* 67 vars */]) = 0
$ strace -f -o "|grep execve" -e execve find . -type f -exec /bin/grep -s coin {} +
15661 execve("/usr/bin/find", ["find", ".", "-type", "f", "-exec", "/bin/grep", "-s", "coin", "{}", "+"], [/* 67 vars */]) = 0
15663 execve("/bin/grep", ["/bin/grep", "-s", "coin", "./1", "./7", "./10", "./3", "./4", "./2", "./9", "./6", "./8", "./5"], [/* 67 vars */]) = 0
$ strace -f -o "|grep execve" -e execve sh -c "find . -type f -print0|xargs -0 /bin/grep -sh coin"
15393 execve("/bin/sh", ["sh", "-c", "find . -type f -print0|xargs -0 "...], [/* 67 vars */]) = 0
15395 execve("/usr/bin/find", ["find", ".", "-type", "f", "-print0"], [/* 67 vars */] <unfinished ...>
15396 execve("/usr/bin/xargs", ["xargs", "-0", "/bin/grep", "-sh", "coin"], [/* 67 vars */] <unfinished ...>
15397 execve("/bin/grep", ["/bin/grep", "-sh", "coin", "./1", "./7", "./10", "./3", "./4", "./2", "./9", "./6", "./8", "./5"], [/* 67 vars */] <unfinished ...>

donc onze processus (un find et 10 grep), deux (find, grep) ou trois (un find, un xargs et un grep) suivant les cas.

Remarque: le nombre de grep dans le 3^e cas peut augmenter suivant les limites d'xargs et du shell, mais il sera toujours largement inférieur au premier cas. Et on peut avoir des pièges comme le "|xargs tar cvf" qui est à proscrire.

Corrigé, merci.

FAQ et mentions légales :
« Liberapay respecte-t-il les réglementations financières ?
Oui. Liberapay est basé en France et respecte les réglementations financières de l'Union Européenne. Nos prestataires de paiement sont tous homologués et nous aident à bloquer la fraude, le blanchiment d'argent, et le financement du terrorisme. »

Le prestataire financier dit la même chose dans ces conditions contractuelles.

Et globalement ce qui est illégal est par définition illégal (sic), donc je dirais qu'on ne peut pas financer l'amicale des fans de cannibalisme, la troupe des joyeux violeurs de brebis et les fans de la pyromanie urbaine. Quand je dis « on ne peut pas », c'est « tu es libre d'accepter l'argent ou pas, mais comme c'est manifestement illégal, tu engages ta propre responsabilité si tu le fais et qu'un juge se décidait à engager des poursuites, pour complicité et financement illégal j'imagine).

Corrigé, merci.

Dans la FAQ, il y a cette liste détaillée :

« Quelles sont les différences entre Liberapay et les autres plateformes de dons récurrents comme Patreon ?
(…)
Pour plus de détails, voyez la grosse liste de snowdrift.coop comparant entre elles les différentes plateformes de financement participatif.
»

Corrigé, merci.

Pas d'annonce de l'événement sur l'Agenda du Libre ? Ça aurait permis d'être inclus directement dans la dépêche programme de la semaine.

Je joue en ligne sur euclidea.xyz, pour la qualité des graphismes, l'efficacité ergonomique et le scénario sur plusieurs millénaires. Mais je galère.

Ajouter des stats sur les interdictions temporaires de tribune ou de commenter ; de manière générale sur les opérations des rôles admin/modérateur.

Imagemagick, libtiff, gst-plugins, firefox… Il suffit de regarder les dernières alertes sécu pour voir que tout n'est pas parfait de ce côté.

Tu ne peux pas faire abstraction des outils utilisés: plus les outils (IDE, compilateur, analyseur statique et dynamique, etc.) progressent, plus on évite de bugs. À condition que l'on ne change pas de langage trop souvent, sinon les outils n'ont pas le temps d'atteindre le niveau des outils précédents. Par ailleurs le langage utilisé joue aussi évidemment (peut-on coder salement avec ? Peut-on créer des bons gros bugs avec ? Est-ce que coder un hello world avec coûte un bras ? Etc.)

Actuellement la mode est plutôt à empiler des couches de code qui marche dans 80% des cas (chiffre tiré du chapeau), pour faire pas trop cher et pour faire vite (puisqu'il faut rester dans la course). Au bout d'un moment, à empiler des couches logicielles, la probabilité de souci tend vers l'implacabilité de la loi de Murphy. Et tout est basé sur le fait de faire vite (au moins aussi vite que les autres sinon plus) et pas trop cher (coût des failles de sécurité, erreurs, pertes humaines et dommages à l'image suite aux intrusions et fuites compris). Avec une option « après moi le déluge », je m'en fous j'aurais revendu / disparu / changé de domaine avant qu'on découvre que mon code est non-maintenable et/ou dangereux, et de toute façon « personne n'utilisera mon code dans 3 ans hein ? ça peut pas arriver ? »

Alors oui c'est un compromis, mais quand même la qualité du code n'est pas encore top, et d'autres domaines de l'ingénierie sont plus fiables que le domaine logiciel (même si ça progresse en terme d'outils et de langages).

(nb: mon domaine professionnel est de mettre en place, tester et superviser des logiciels, j'imagine que j'ai une vision différente de celle d'un développeur)