Jérôme Flesch a écrit 359 commentaires

rien qu'avec les affiches des films (19 requêtes) et les logos des partenaires (26 requêtes), j'explose largement les 30 requêtes

Dans le cas de Patréon, c'est 14 images, donc avec la page HTML, la CSS et 1 fichier Javascript, ça pourrait se faire 17 requêtes. Là, ça en fait 30.

Dans ton cas, 19 + 26 images + 1 page HTML + 1 CSS + 1 Javascript --> Ça pourrait se faire en 48 requêtes. 59 requêtes, je trouve ça excessif, mais dans notre beau monde 2.0 et pour un site temporaire, je suppose que c'est déjà pas si mal.

Pour Google Maps, pas sûr que OpenStreet Maps fasse mieux en nombres de requêtes, et ils font probablement bien pire en temps de réponse. :/

Ceci dit, je m'interroge aussi sur la gestion du contenu de ton site: pourquoi l’intégration Google Maps et les logos partenaires sont sur la même page que les affiches de films ? Ça ne fait pas trop chargé pour une seule page ?

<mode vieux con>
À noter aussi que je souviens d'une époque où les mecs se faisaient ch*er à rassembler toutes les images statiques de leurs pages en une seule mosaïque. Ça faisait donc une seule image, une seule requête et qu'un seul blob dans la mémoire du navigateur. Il s'arrangeait ensuite pour que le navigateur affiche chaque bout de la mosaïque aux bons endroits (à coup de CSS je suppose). En détails: http://www.websiteoptimization.com/speed/tweak/combine/
</mode vieux con>

Pour conclure, je ferais aussi remarquer qu'une page trop longue à charger, ça peut faire perdre des visiteurs. D'ailleurs, c'est pour ça que je soupçonne Patréon d'avoir d'avoir fait des pages légères pour quand on est pas logué, mais qu'ils n'en ont visiblement plus rien à secouer une fois logué.

Ce genre là: https://bellard.org/jslinux/ ?

Pouvoir publier sur le web (= faire du JS) sans être un spécialiste hardware ni savoir coder en assembleur est une bonne chose

Tout d'abord, pour moi, publier, c'est publier du contenu. Il n'y a pas besoin de Javascript pour ça. Au contraire même, le Javascript est souvent totalement superflu ! (et là on en revient à la remarque initiale du journal d'ailleurs)

Ensuite, il y a être un spécialiste et il y a avoir une connaissance élémentaire.

Par exemple, je n'aurais jamais la prétention d'être un garagiste. Mais je conduis un véhicule régulièrement. Donc sans être garagiste, je connais la théorie de base du fonctionnement d'un moteur à 4 temps. J'ai aussi déjà fait l'entretien de base de ma voiture et de ma moto moi-même occasionnellement (ne serait-ce que pour me prouver que je peux aussi le faire).

En informatique, on se retrouve avec des gulus qui se prétendent programmeur professionnels, mais qui:

• ne savent pas ce qu'est la stack ou le heap,
• savent vaguement ce qu'est une IP mais qui sont perdus dès qu'on parle de sous-réseau,
• trouvent normal de faire plus de 30 requêtes HTTP pour une seule page web,
• n'ont jamais entendu parler d' "injection SQL", de "complexité algorithmiques", etc.

Ceci dit, ce n'est pas du tout spécifique au développeurs Javascript. J'ai croisé le même genre d'animaux en faisant passer des entretiens d'embauche pour des programmeurs C embarqués. C'est juste que le web et le Javascript étant à la mode, j'ai l'impression qu'ils sont nettement plus nombreux dans ce domaine (ou juste plus visibles ?).

Si tu en as l'occasion, je t'invite à participer à des tests techniques d'embauche, mais coté recruteur plutôt que candidat. Personnellement, depuis, j'ai envi de pleurer quand je pense à l'état du monde de l'informatique.

Le fait que les pages web soient surchargées en revanche est un problème de marketing/merchandisation

Pas besoin que le marketing vienne mettre les doigts dedans pour que ce soit surchargé.
En ce moment, le site que j'aime bien citer en parfait exemple de ce qu'il ne faut surtout pas faire, c'est Patreon: Charger ma page Patreon complètement, avec le bloqueur de pub UBlock, c'est 37 requêtes HTTP pour 14 images. Il y a des éléments chargés dynamiquement, qui contiennent des éléments chargés dynamiquement. C'est absolument ridicule. Et ce n'est malheureusement qu'un exemple (certes un peu extrême) d'une tendance de plus en plus présente.

Ce qui est dommage c'est l'absence de maintenance des anciennes versions, mais libre à toi de contribuer dans ce sens.

Tu peux contribuer à la maintenance de programmes et sites web propriétaires toi ? oO

Et même pour les logiciels libres, ce n'est pas une bonne approche. Plus longtemps les anciennes versions sont maintenus, plus il y a de versions qui se baladent dans la nature. Ça devient un cauchemar pour les développeurs (ceux des applications concernés, mais aussi ceux qui codent des applications dépendantes de celles-ci).

La seule vraie solution, c'est de prendre le temps de tester son code sur des machines pourries. Mais qui dit temps dit argent …

je ne reprocherai à un pair de mal faire, puisqu'il a l'a fait librement

Dans le contexte de développement web, "librement", c'est très rarement le bon mot. On touche un autre problème: La plupart des sites web et "applications web" sont totalement propriétaires et très peu interopérables.

Exemple que j'ai trouvé récemment: ze-coloc.fr (pas de lien, c'est fait exprès).
Chargé en Javascript totalement inutile, avec les bugs qui vont de paire (problème de scrolling sur certains pages notamment), et surtout, impossible d'exporter ses données sans payer (contraire à la RGPD). J'ai arrêté d'utiliser leur service récemment après avoir trouvé une alternative sur Nextcloud. Il n'y aurait pas eut cette alternative, j'aurais été coincé parce-que je n'ai juste pas le temps d'en coder une.

Les quelques rares sites web qui sont libres/opensources me semblent généralement plus légers (sauf Nextcloud :-P).

Je crois que le problème de base, c'est que les bundles Flatpak ne correspondent pas à l'utilisation courante prévue de Flatpak. Ils me donnent l'impression d'être plutôt un rajout, juste là pour dépanner.

À coté de ça, ce n'est pas complètement illogique que les bundles ne contiennent pas les runtimes. Ça évite aux utilisateurs d'avoir à retélécharger les runtimes plusieurs fois. Mais oui, c'est moins pratique.

Il me semble que Flatpak est plutôt prévu pour que les applications soit téléchargées et mises à jour via un dépôt (soit hébergé toi-même, soit sur FlatHub). Dans ce cas, tu mets à disposition de tes utilisateurs un fichier .flatpakref qui indique les dépôts à utiliser pour l'application et le runtime (exemple 1, exemple 2). L'avantage est que ça règle aussi le problème des mises à jour. L'inconvénient est que c'est dépendant d'une connexion Internet.

Là mon impression, c'est comme si tu tentais de distribuer un .deb en te plaignant que APT/dpkg c'est pourri parce-que le .deb que tu fais ne contient pas toutes les dépendances.

ce sans parler de victimes de la société passant ses vacances à Cancun puis demandant de l'aide pour ses études

Je n'ai pas suivi cette histoire, mais à la louche j'ai l'impression qu'il y a une mauvaise interprétation de ses demandes.

Elle demande les "les conditions les plus favorables" pour ses études. Ça veut certes dire un logement, de quoi manger, etc, mais aussi et surtout du temps et du repos. Là, elle dit devoir travailler jusqu'à 2h du mat'. Donc elle a un problème de temps et de repos.

Un voyage à Cancun en été, c'est ~1500€. De mon point de vue, il est tout à fait envisageable que son travail lui a laissé un excédant financier pour y aller hors période scolaire, mais elle reste en déficit de temps et de repos pendant la période scolaire.

Bref, il ne me semble pas y avoir de contradictions dans ses propos.

où trouvent-ils donc 15 milliards d'€ par an (+50% en 10 ans) à claquer

/me sort sa calculette.

15g€ / 25m joueurs / 12 mois ≅ 50€ / mois

Il y a 8m de pauvres en France (revenus < 880€/mois). En supposant qu'ils jouent tous, ils représenteraient seulement 1 joueur sur 3.

Il faut prendre en compte que c'est une moyenne. Faute d'informations détaillées, on peut faire en tirer une supposition pif-o-métrique sortie de mon cul : la dépense moyenne pour un pauvre non-addict en jeux est probablement de l'ordre de 25~30€/mois.

Étant donné le manque d'éducation en statistiques du pauvre moyen, ça ne me semble nullement surprenant.

Donc pour répondre à ta question, ils trouvent ces 15 milliards dans 3,4% de leurs maigres revenus.

Chose amusante, c'est tout de même exactement ce qui est reproché aux jeux d'argent de façon générale : faire dépenser bêtement de l'argent aux plus pauvres.

Contre la privatisation d'ADP : 1 million de signature en 6 mois

Donc 1 million de gens qui pensent que c'est une idée de merde.

Pour la privatisation de FDJ: 0.5 million de personnes pour en quelques mois

Donc 0.5 million de gens qui pensent que c'est l'occasion de se faire de la thune sur les dos des idiots-qui-ne-savent-pas-compter et des rêveurs-qui-ont-trop-d'argent.

Avoir investi dans la FDJ ne veut pas dire qu'on considère cette privatisation comme une bonne idée. Ça veut juste dire être assez intelligent pour y voir un gain personnel potentiel malgré les dommages potentiels pour le collectif. Bref, ces deux nombres ne sont pas incompatibles et tu ne peux pas les mettre en opposition juste comme ça.

Il y a un truc qui m'amuse sur cette page. Un des éléments qui peut mettre la puce à l'oreille que c'est une arnaque, c'est les pseudo-commentaires Facebook en dessous : il n'y a aucune faute d'orthographe ou de grammaire (que j'ai vu). Pas vraiment crédible :-)

flatpack-builder ne propage pas http_proxy

Flatpak-builder bloque volontairement le réseau pendant les builds de chaque composant. L'objectif est de s'assurer que la liste des dépendances est complète et que le build reste 100% reproduisible. C'est notamment pour éviter que des dépendances soient téléchargées pendant le build.

Par exemple, lors de l'installation d'un module Python avec pip, si une dépendances n'est pas sur le système, pip va essayer de la télécharger. Et par défaut, il va tenter de télécharger la dernière version. Or ce pourrait ne pas être la même entre 2 tentatives de build différentes. Donc il faut que les dépendances soient installées avant explicitement (y compris les dépendances des dépendances, etc).

J'ai eut le même genre de problèmes avec Paperwork. Heureusement pour moi, Mathieu Jourdan avait fait un début de Flatpak qui réglait le problème de l'installation des paquets Python. De mon coté, j'ai pu me concentrer sur les problèmes de fichiers de données spécifiques à la langue de l'utilisateur et sur le problème de l'accès aux scanners.

Pour Maven, je pense que tu peux t'en sortir comme Mathieu Jourdan avait fait pour Python:
- Compiler et installer Maven comme faisant partie du build Flatpak
- Utiliser un mini Makefile bidon pour construire les builds suivants avec Maven

C'est effectivement difficile, mais Flatpak offre ensuite plusieurs avantages:
- Tu as une liste quasi-exhaustive des dépendances de ton programme.
- Tes utilisateurs peuvent tester la dernière version de ton programme quelque-soit leur distribution.
- Tes utilisateurs peuvent te faire des rapports de bugs indépendamment des 25000 versions des dépendances disponibles dans les diverses distributions.
- Tu peux faire de l'intégration continue en mettant à jour ton dépôt Flatpak automatiquement.

Juste pour la blague, une anecdote plus ou moins hors-sujet que j'ai vécu:

Il y a un gars de plus de 50 ans aux US qui a longtemps cru que jflesch@gmail.com était son adresse email. J'ai plusieurs fois prévenu ses interlocuteurs qu'ils avaient une mauvaise adresse.

Un jour ce monsieur a passé une commande pour des chaussures dans un magasin (physique) en donnant mon adresse email. J'ai reçu l'email de confirmation. L'expéditeur de l'email était "support@magasin-xyz.com". J'ai donc répondu à l'email en leur demandant si il était possible d'annuler cette commande. Ils m'ont répondu OK, commande annulée.

Bizarrement, depuis, je ne reçois plus aucun mail à sa place :-)

Pour les jeux:
1) https://store.steampowered.com/app/433340/Slime_Rancher/
2) https://store.steampowered.com/app/331870/AER_Memories_of_Old/

J'ai passé beaucoup trop de temps sur le premier :-)

Le seul défaut de ces deux jeux sous GNU/Linux, c'est le clavier : je suis en QWERTY, et je n'ai pas vu de problème, mais ma petite amie est en AZERTY et a du réglé son clavier en QWERTY pour que ces jeux prennent les entrées clavier correctement (bug Unity ?).

Pour le chat, le seul truc qui me vient à l'esprit serait un serveur IRC privé, avec en client/proxy QuasselIRC (disponible pour GNU/Linux et Android).

https://gitlab.gnome.org/World/OpenPaperwork/ironscanner#from-sources

Au moins on avance :-)

./libinsane] $ source ./activate_test_env.sh

Je crois qu'il y a une légère confusion dans les instructions. Comme indiqué dans le README, le source ./activate_test_env.sh est à faire à partir des sources de IronScanner, et non pas celle de la Libinsane. Ce script va s'occuper de créer un environnement de dev/test pour IronScanner, ce qui implique qu'il va compiler la dernière Libinsane lui-même.

Un script similaire existe aussi dans les sources de la Libinsane, mais celui-là est uniquement pour le développement/test de la Libinsane toute seule (sans IronScanner).

Pour le make install, pareil, c'est uniquement à faire dans les sources d'IronScanner. Ça va installer IronScanner dans le virtualenv Python (ou sur le système si aucun virtualenv n'est actif). Par contre, faire make install dans Libinsane va tenter d'installer la Libinsane sur le système (il n'y pas vraiment de virtualenv pour une librairie C), d'où les erreurs je suppose.

• https://gitlab.gnome.org/World/OpenPaperwork/libinsane/blob/master/subprojects/libinsane/src/meson.build#L60
• https://mesonbuild.com/Dependencies.html

Sauf erreur de ma part, Meson utilise pkg-config pour trouver les dépendances. Donc ce qu'il faudrait regarder:

• pkg-config --libs --cflags sane-backends ?
• Est-ce qu'il y un fichier sane-backends.pc quelque-part dans /usr ? Sinon, un .pc avec un nom similaire ? Auquel cas je peux patcher le meson.build.

D'après le rapport, c'est l'API WIA2 qui a utilisée. Libinsane n'a pas trouvé la DLL TWAIN.

Et effectivement, ce n'est pas le bon nom qui s'est affiché. C'est un point qu'il faut que je travaille.

En fait j'ai cru que tu avais voulu lancer IronScanner depuis ses sources comme rapido l'avait fait. Je viens de réaliser que toi tu as utilisé le binaire IronScanner.

Toutes les dépendances du binaire devrait être incluses dedans. Cependant il y a visiblement un soucis dans le packaging de IronScanner qui fait qu'il cherche quand même à utiliser quelques librairies du système.

En attendant que je trouve comment régler ça proprement, je pense qu'installer les paquets suivants devrait régler le problème:

sudo apt install \
    python3-gi libgirepository1.0-dev gobject-introspection \
    gir1.2-gdkpixbuf-2.0 gir1.2-gtk-3.0

Nop, même idée. Il faut juste espérer que le trafic réseau n'est pas chiffré …

J'ai commité un fix dans la Libinsane et j'ai rebuildé IronScanner. Le fix n'est pas aussi propre que ce que j'aurais voulu, mais ça permettra déjà de confirmer que c'est bien le problème que je pense.

De ce que j'en ai compris, le problème est que le pilote de son scanner founit une source de numérisation 0000\\Root\\Auto. Je suppose que si utilisée, elle sélectionne automatiquement une des sources qui a du papier. Problème: elle ne fournit pas les options requises par Libinsane et IronScanner (resolution et mode), et ça a l'air de faire planter IronScanner. Donc là j'ai patché Libinsane pour qu'elle l'ignore.

Est-ce que tu pourrais retélécharger IronScanner et réessayer s'il te plait ?

Malheureusement, on tape en plein dans le problème de la diversité des distributions Linux … :/. Pour ma part, je ne teste que sur Debian, Ubuntu, et plus rarement sur Fedora. Comme je fais ça sur mon temps libre, je peux difficilement assurer le support des autres distributions :(

En supposant qu'il s'agit d'un scanner USB, ce que je ferais:

• Voir si il n'y a pas des applications tierces opensource (non-Sane) qui le supporte. J'avais un vieux scanner supporté comme ça il y a longtemps par exemple.
• sniffer le trafic USB avec Wireshark:
  • tout en sniffant, faire un scan d'une page rouge, puis d'une verte, puis d'une bleue (ça suppose que le scanner est en RGB, mais ça devrait aussi permettre de voir si le scanner est en CMYK ou dans un autre espace de couleur fantaisiste).
  • tout en sniffant, essayer des scans en changeant juste un réglage à chaque fois.
• jouer aux devinettes
• jouer avec pyusb et le scanner pour voir si ces devinettes sont tombées juste
• rajouter un backend à sane et soumettre un patch

Et il marche avec l'application "Numérisation et Fax" de Windows ?

Ok en fait cette question est inutile. Je vois bien le scanner dans les traces du rapport donc il marche sûrement avec "Numérisation et Fax. Par contre il manque l'option "resolution", ce qui est sacrément étrange vu que cette option est normalement rajoutée par Libinsane.
Va falloir que je creuse ça.

le scanner n'apparait pas dans la liste.

Et il marche avec l'application "Numérisation et Fax" de Windows ?

Apparemment, os.uname ne marche pas sous Windows, il faudrait utiliser platform.uname à la place.

Bonne remarque. Ce warning est non-bloquant mais je vais voir pour corriger ça.

Y a-t-il une solution simple, ou reconstruire l'exécutable à partir des sources est-elle la seule ?

Je ne vois que deux solutions malheureusement:

• Le lancer à partir des sources + un virtualenv python (voir le readme sur gitlab)
• Faire un schroot Debian Buster

Bizarre, toutes les dépendances devraient être incluses dans le binaire. Essaye voir en installant ce paquet: libgdk_pixbuf-gir2.0

Fait, ça a marché.

\o/

Ils seront détectés ?

Si ils sont installés sur la machine, ils devraient l'être. Une façon de confirmer qu'ils sont bien installés est de lancer l'application "Numérisation et Fax" de Windows et de voir si elle les trouve.