Florent Fourcot a écrit 398 commentaires

quand on voit des choses qu'a ecrit le fameux contributeur dans weboob, c'est clair qu'il n'aurait pas pu les ecrire dans le code de n'importe quel autre projet libre.

Mais de quoi tu parles exactement ?

J'ai été release manager du projet pendant plusieurs années (de 2013 à 2017 disons), j'ai vu passer bon nombre du millier (environ) de commits du « fameux » contributeur de Weboob dont tu parles, et j'ai l'impression que tu fantasmes complètement sur ce qu'il a pu écrire. Et c'est facile à vérifier, git a un historique plutôt bien fait, il y a même le nom des auteurs dedans.

Ou alors on aurait pu deviner ses opinions politiques (qui en 10 ans de projets peuvent aussi changer ? Sachant qu'il n'était plus actif depuis plusieurs années ?) avec ses contributions sur le module Arte ? Qu'il était le mainteneur du module radiofrance ?

J'ai commencé à croiser Laurent il y a maintenant plus de dix ans, en commençant à contribuer à Weboob. À l'époque, je ne devais pas avoir écrit plus de 30 lignes de python dans ma vie, et le moindre soucis avec git se résumait à rm -rf repo && git clone (je l'ai beaucoup fait pour le repo weboob…).

Il fait partie des gens grâce à qui cette expérience a continué, et petit à petit Weboob a rempli de nombreuses de mes soirées. J'ai beaucoup appris grâce à Laurent, et c'était un plaisir de le côtoyer (même si c'était principalement à distance pour des raisons géographiques, on a réussi à se rencontrer physiquement régulièrement en 10 ans). Sa disparition fait très mal.

La douleur dans la maladie est très compliquée. Je savais qu'il souffrait, mais je n'avais pas compris à quel point. La dernière fois que nous nous sommes vus, il parlait encore de ses projets, même si sa fatigue récurrente faisait déjà des dégâts depuis de nombreuses années.

Toutes mes condoléances à sa famille, à Romain, et à ses amis.

J'étais très triste que gitstats ne soit plus maintenu, ça fait plaisir de retrouver le même usage, en mieux.

Précision importante : en 64eme position. Il faudrait que la France Insoumise obtienne plus de 80% des sièges français pour qu'il puisse siéger au parlement.

Ce n'est forcément pas exhaustif mais quelques remarques en vrac :

• Bloquer tout l'icmp va t'empêcher d'avoir des détections d'erreurs bien utiles en IPv4 (host unreachable par exemple) (vu que tu n'autorises par les connexions en state RELATED).
• En IPv6, autoriser les RA et les NS est un bon début. Mais tu dois récupérer au minimum également les erreurs de paquets "too big", sous peine de casser pas mal de trucs si ta MTU n'est pas la même que le destinataire
• Les règles de log me semblent un poil absurdes, n'importe qui pourrait mettre la machine à genoux en visant des ports non-autorisés. Autant en OUTPUT en mode "parano" ça peut se comprendre, autant en INPUT c'est prendre des risques
• Tu peux aussi utiliser l'option multiport pour réduire le nombre de règles parfois

Si l'auteur original en parle dans l'article, mais le journal n'en fait pas mention, donc je me permet de compléter.

Cake est un projet pour rendre (notamment) la QoS facilement configurable sous Linux. Du coup d'ailleurs c'est pas le même algorithme fq_codel qui est utilisé que celui « classique » du noyau Linux, mais une variante (cobalt). Et cake a pour objectif de faire beaucoup de choses, notamment :

• ne pas prendre la tête lors de la configuration en cas de NAT (ce qui a été un problème pour son inclusion dans le noyau)
• garantir l'équité entre les utilisateurs/équipements (et là on sort du problème de bufferbloat). C'est d'ailleurs la raison de l'utilisation de cobalt vs fq_codel
• simplifier les configurations pour les différents types de liens WAN (voir la partie « Extensive framing compensation » de la page du projet)
• gestion de différentes classes de trafic
• filtrage des ACK inutiles de TCP

Cake a été mergé récemment (après 18 versions proposées des patchs !), et sera en version 4.19. Si vous voulez un peu d'histoire, lwn en parle.

Également sur lwn, c'est relié mais pas complètement, un article sur les problèmes de latence en WiFi avec Linux.

Si tu cherches la correspondance entre le type numérique d'un compte et une valeur compréhensible par un humain, c'est par là :

https://git.weboob.org/weboob/devel/blob/master/weboob/capabilities/bank.py#L187

Je ne dis pas que la documentation pour comprendre les types de comptes est très précise, loin de là. C'est également très ciblé sur la fiscalité et produits financiers français.

Par contre ça fait plaisir de voir quelqu'un utiliser les conditions. C'est pas forcément une fonctionnalité très mise en avant de Weboob, mais ça permet de faire des choses assez sympa dans des cron ou autres tâches automatisées (exemple : récupérer les deux derniers salaires ressemblerait chez moi à :

boobank history blabla@banque -n 12 "amount > 2000"
(si la banque conserve un bon historique bien sur…).

Sur cette ligne :

boobank $backends list -f csv

Le formateur CSV de boobank (et des applications weboob en général) ne te garanti en rien que le nombre de colonnes restera stable, et que la valeur que tu cherches restera à la même colonne.

Ce que tu peux faire par contre très facilement c'est filtrer ce dont tu as besoin avec l'option -c et récupérer que ce qui est pertinent pour toi :

boobank $backends list -f csv -s id

Et avec ça tu peux juste virer la premier ligne de la sortie et tu as directement ce que tu veux. Ou peut-être mieux :

boobank -b ing list -f multiline -s id | awk '{print $2}'

Aussi, la durée de l'historique qui sera remonté par weboob dépend en réalité de ta banque. Pour ING par exemple, c'est « infini » (depuis l'ouverture du compte si tu le souhaites). D'autres banques sont malheureusement plus restriive

J'ai un peu la même question mais pour la partie « collecte de documents ». Si je comprends bien, vous codez actuellement un « connecteur » pour chaque site que vous souhaitez ajouter. N'est-ce pas contradictoire avec le principe de ne pas re-développer ce qui existe déjà (l'exemple des banques étant pertinent) ? J'imagine que les connecteurs devront aussi être mis à jour régulièrement.

Weboob notamment permet déjà de récupérer des factures (EDF, GDF, Lampiris (Total spring désormais), freemobile, etc) voir des documents comme des fiches de paie (module ensap, utilisé par la fonction publique d'état). Je suis d'ailleurs curieux de savoir comment vous avez fait pour une intégration aussi poussée avec EDF.

Car il est pas toujours disponible, tout simplement. Le loyer charge comprise est toujours prioritaire, mais il faut qu'on remonte l'information si les charges ne sont pas comprises.

En fait la traduction dans la dépêche est assez mauvaise et confuse. Cette limite du nombre de paquets ICMP existait déjà, notamment pour éviter de mettre à plat le réseau. Ça change rien là-dessus.

Pour être plus clair, le cas d'usage est le suivant : normalement ton serveur écoute sur une socket en UDP et absorbe des Mb/s de trafic (par exemple un serveur de logs). Tu redémarres/coupes le service. Plus rien n'écoute sur ton port, alors le kernel génère des paquets ICMP d'erreurs pour dire « y'a personne ici ! ». Il y a depuis longtemps des mécanismes pour limiter le nombre d'erreur générées (par exemple voir les paramètres icmp_ratelimit et icmp_ratemask des sysctl).

Même avec du ratelimiting, on arrivait dans le noyau à une situation absurde : le noyau était plus efficace à traiter des paquets quand une socket était ouverte que si aucun service n'écoutait ! (notamment grâce à des optimisations récentes sur le cas « normal » d'un serveur absorbant le paquet). Le noyau 4.11 permet de remettre de l'ordre (ce serait logique d'aller plus vite quand on ne fait rien ou presque du paquet), notamment avec un changement assez malin. Avant, on générait le paquet, et on se demandait ensuite si on l'envoyait vraiment. Maintenant, on regarde si au final on l'enverra, et on ne le génère que si la réponse est positive (ça coûte donc beaucoup moins cher en ressource, allocations de mémoire, etc. On gagne environ un facteur deux).

J'ai été un peu surpris de voir mon nom ici (et très honoré), et après une recherche j'ai effectivement bien reçu un mail à ce sujet. Mais il était dans un dossier spam : X-Spam-Flag: YES.

Ce n'est pas un serveur que je gère mais le calcul du score ressemble à ça : ALL_TRUSTED=-1, BAYES_40=-0.001, DKIM_ADSP_ALL=0.8, FROM_NOT_REPLYTO=2, SPF_SOFTFAIL=0.665

Est-ce que le livre a bien été redistribué (je lis « Les lots ont été réattribués automatiquement ») ou est-ce que j'ai encore ma chance ?

qui n'est pas a son coup d'essai (Globalsclale)

Oui, ils ont notamment un beau foirage à leur actif, avec les GuruPlugs. Petit exemple de ressenti : http://wtarreau.blogspot.fr/2010/05/guruplug-server-plus-don-waste-your.html

Ils ont tout de même fait le coup d'énormes délais de livraisons pour « régler » le problème de température (après la livraison de premiers clients furieux…) en rajoutant un ventilateur aussi bruyant qu'un aspirateur. Dommage pour ce type de produits…

J'ai tendance à me méfier de cette entreprise depuis.

« x is None » et « x == None » donnent effectivement le même résultat, mais pas exactement les mêmes performances :

In [6]: timeit coin == None
10000000 loops, best of 3: 34.4 ns per loop

In [7]: timeit coin is None
10000000 loops, best of 3: 22.5 ns per loop

L'opérateur is est plus simple et plus rapide, il ne vérifie que l'égalité entre deux id.

De toute façon facebook et ses copains sont déjà passés à l'IPv6, donc peu concernés par ces mesures. Au delà de la blague, le nombre de ports nécessaire pour l'A+P baissera au fur et à mesure de la transition.

LOL, NOPE !

Le commentaire du dessus n'a pas raté la référence humoristique, toi si apparemment :-)

Sinon, même si je pense que cette valeur est insuffisante pour de nombreux usages, je me suis un peu renseigné sur le sujet (il y a quelques années déjà, c'est pas nouveau l'A+P).

seulement 4 clients derrière une IP quand un NAT444 permet d’en mettre des milliers

Petite précision : l'A+P est loin d'être limité à 4 clients. C'est le choix qu'a fait free, mais on peut très bien imaginer en mettre 65 (1000 ports par personne est suffisant pour tout le monde, non ?). On est bien loin des milliers par adresse, mais il y a de la marge.

1) Quel rapport entre un label "fiche de paie" et des labels de date ?

La question c'est comment je trouve mon fichier :-) Ton point deux y répond, on a une différence d'utilisation. De mon côté, je scan le tas de documents de temps en temps. J'ai donc des dizaines de fichiers avec la même date (que je ne change pas, je suis fainéant. Et je ne savais pas qu'on pouvait la changer).

Quelque-chose comme #423 ?

Oui. Le but concret, c'est de trouver rapidement les fichiers sans avoir besoin de lancer paperwork (accès distant notamment). Et sans avoir besoin d'aller lire les fichiers labels un par un.

J'ai deux réponses là-dessus. La première c'est qu'il faut que ça fonctionne pour toute la famille, donc que le script shell n'est pas forcément la bonne solution.

La seconde c'est que voici un exemple d'arborescence :

├── 20150223_1320_32
│   ├── labels
│   ├── paper.1.jpg
│   ├── paper.1.thumb.jpg
│   └── paper.1.words
├── 20150223_1323_23
│   ├── labels
│   ├── paper.1.jpg
│   ├── paper.1.thumb.jpg
│   └── paper.1.words

Comment je sais qu'est-ce qui correspond à quoi ? Disons que le label est un truc comme « fiche de paie » dans les deux, il faudrait que je mettre un label "Octobre" et "Novembre" pour savoir quel fichier correspond à quel mois ? Chercher dans le fichier words sera fastidieux et imprécis pour une si petite différence.

Ce dont je rêve (je sais, je pourrai payer mon patch) c'est de pouvoir formatter les dossiers et nom de fichiers en sortie (un peu comme tout bon gestionnaire de musique sait le faire, tu peux choisir des hiérarchies différentes en fonction de tes besoins (quitte à faire des liens symboliques pour les fichiers avec plusieurs tags)).

Pour avoir migré plus de 100 documents d'une arborescence paperwork vers un rangement plus classique, je peux dire que personnellement j'ai trouvé ça chiant :-) Ce qui n'enlève rien aux très nombreuses qualité du logiciel, qui répond à un vrai besoin.

J'ai utilisé pendant un petit moment paperwork, et il est vrai qu'il a de grands avantages. L'interface graphique est sympa, les labels marchent plutôt bien, et on trouve rapidement un document en utilisant le logiciel.

Mais seulement, dès qu'on souhaite retrouver via un gestionnaire de fichiers comme Nautilus ou Thunar, voir même à distance en SSH, ça devient une vraie galère. L'organisation des dossiers/fichiers est absolument pas pratique. J'avais commencé à bricoler un script de recherche dans les fichiers tags, mais ça restait difficile à gérer. Je pense que si la hiérarchie des fichiers et dossiers reprenait quelque chose compréhensible par un humain (quitte à mettre des liens symboliques pour créer des beaux dossiers du genre "paperwork/tag1/fichier1.pdf"), ça deviendrait le logiciel ultime. Pour le moment, je suis retourné à un scan et un rangement manuel (de type impots/revenu-2015.pdf). Et ça ferait un peu moins peur sur la récupération des fichiers si un jour paperwork cesse d'être développé pour une raison ou une autre.

La communauté parisienne de Weboob n'est pas (encore ?) assez grande pour privatiser la taverne :-) On a pu en tout cas y croiser plusieurs incarnations de Roger Philibert.

Quelques petites précisions sur la rédaction de cette dépêche :

• J'en suis l'auteur principal, et je ne suis lié à aucune des entreprises citées (il y a en plusieurs si tu regardes bien. Ce qui pour un publi-reportage est un peu con).
• Quand je parle de « principal », c'est que je dois avoir rédigé peut-être 30% de la dépêche. Elle a été écrite en collaboration avec divers contributeurs du projet.
• J'admets qu'il y a un problème sur le lien vers le Hall's Beer Tavern, on aurait du mettre du Openstreetmap. Mais je ne suis pas certain que ce soit le sens de ta remarque.
• Toutes les entreprises citées (à l'exception du bar) fournissent du code sous license AGPL au projet. Faut-il arrêter de parler des contributions de Google, Facebook, et d'autres, dans les dépêches sur le noyau ?

Ton comporte colle tout à fait à l'image que véhicule weboob : des mecs qui se prennent pas pour de la merde, qui se croient drôles et qui prennent les gens de haut.

Il y a une centaine de contributeurs à Weboob. J'ignore l'image que véhicule Weboob, mais je sais par contre que considérer que ces 100 personnes forment un groupe homogène est complètement faux.

Et en tant que développeur qui a le droit de merger les patchs, je peux te dire que je trouve la réponse de rzx complètement absurde.

Weboob n'est malheureusement pas basé sur Scrapy qui est LE framework de référence pour faire du crawling. Je me demande toujours pourquoi weboob ne s'est pas basé dessus et en suis vraiment curieux.

Weboob a été créé il y a six ans. Je doute déjà de l'affirmation « référence » de scrapy en 2016, mais alors si tu remontes début 2010, je crois que l'argument d'autorité tombe complètement. Au niveau technique et outils proposés, les projets divergent également.

Je n'ai pas compris la difficulté à trouver le code source. C'est sur le site officiel (et un gros lien "Get weboob" sur la page d'accueil). Ça prend quelques instants de trouver des clones sur Github. C'est quoi du coup pour toi un code source facile à trouver ?

La licence est effectivement un vrai choix.

La solution est d'utiliser Duplicity, qui va s'occuper de tout (en utilisant rsync en dessous) : http://duplicity.nongnu.org/

Tout est configurable (le nombre de sauvegardes complètes conservées, le délais entre deux sauvegardes complètes, etc).