C'est aussi embêtant, si, comme moi, on utilise zeroconf/avahi-daemon pour tous ses services sur son réseau local perso (par exemple http://jellyfin.local/ ).
J'ai récemment passé le site openpaper.work dans Docker. C'est aussi du Django. J'avais vu beaucoup de doc et tutoriels de dockerisation qui montraient comment le faire en utilisant aussi le serveur web de développement de Django. Bien que ça peut peut-être faire l'affaire dans un environnement cloud, ça ressemble quand même à une mauvaise idée. Dans mon cas, je n'ai de toute façon qu'un seul conteneur qui tourne. Donc j'ai choisi de continuer à utiliser un serveur Apache dans le conteneur. Ça donne ça: Dockerfile + start.sh + docker.
Comme c'est la 1ère fois que je dockerise quelque-chose de sérieux, je serais intéressé d'avoir l'avis de gens qui s'y connaissent mieux en Docker.
Avant-hier et hier, j'ai voulu éditer rapidement 2 vidéos.
J'ai cru comprendre que Kdenlive était assez populaire, donc je l'ai essayé très rapidement avant-hier. Je l'ai fait freezer en moins de 5 minutes d'utilisation: J'ai déplacé son moniteur de projet sur mon deuxième écran, et paf, GUI bloquée. Depuis, quand je le démarre, il freeze après ~30s. Testé avec la version dans Debian stable et la version Flatpak. Du coup, j'ai passé mon chemin.
Je suis revenu sur un logiciel que j'avais déjà utilisé par le passé: Flowblade. Je l'avais choisi initialement parce-qu'il avait la réputation d'être un peu plus simple que les autres.
Positif:
Je l'ai fait freezer une fois hier, mais avec les sauvegardes automatiques toutes les minutes, il a repris sans problème.
Il est effectivement assez simple à prendre en main.
Négatif:
Je trouve son éditeur de titre peu pratique: Les titres sont un peu pénibles à bien aligner
(surtout si on veut aligner des textes sur leurs axes centraux). Le fait de passer par un export en PNG devient vite très lourd quand on se rend compte qu'on a mal placé ses titres et qu'il faut tous les changer.
Sa GUI a des comportements parfois peu intuitifs et/ou agaçants: Par exemple, il semble qu'il y a deux façons différentes de sélectionner plusieurs clips (Shift+clic, ou une sélection de zone à la souris), et que toutes les options ne s'appliquent pas sur ce qui est sélectionné, selon la façon dont on l'a sélectionné. Il m'a aussi fallu bon moment pour bien comprendre comment bien configurer les filtres (le point du filtre qui est sélectionné est loin d'être évidant). Mais il a fait le travail.
Le rendu par GPU est encore expérimental.
Je pense que je vais donner une chance à OpenShot la prochaine fois. Le rendu via GPU pourrait offrir un bon gain de temps.
Pour une victime en train de se vider de son sang, inutile d'attendre des conseils médicaux, c'est une évacuation d'urgence qu'il faut, donc appeler directement les pompiers.
Non, c'est le 15.
Les évacuations sont souvent faites par les pompiers, mais pas toujours. Ça peut être des ambulances privées ou des associations de secourisme agréées qui les font. Ces derniers se rattachent toujours au 15, jamais au 18.
De plus, en fonction du problème et de l'état de la victime, le 15 peut décider de faire intervenir un SMUR (médecin + infirmier + équipement spécifique) plutôt que juste un VSAV/VPSP/ambulance. Par exemple, si vous appelez pour une crise cardiaque, un SMUR va décoller immédiatement. Si vous appelez pour une hémorragie mais que la victime a déjà perdu beaucoup/trop de sang (voir même a perdu conscience), le transport peut se révéler dangereux et le médecin peut donc aussi décider d'envoyer un SMUR.
Encore une fois, le détail dépend des départements. Je suppose que certains 18 ont peut-être leur propre médecins et leur propre SMUR. Mais c'est difficile à savoir.
Dans tout les cas, ce n'est pas au secouriste de supposer qu'il y aura évacuation ou non. C'est le médecin du 15 qui décide ça (cf référentiel secourisme). Donc si c'est médical, c'est le 15 qu'il faut appeler.
Sauf erreur de ma part, en fonction de comment votre département est organisé pour les secours, appeler les pompiers pour un problème médical peut avoir différents résultats:
Identique: le 15 et le 18 sont en fait le même numéro (par exemple dans les Bouches-du-Rhône il me semble).
Redirection visible: le 18 vous redirigera sur le 15.
Redirection transparente: le 18 vous répond, mais en interne ils transfèrent les informations au 15.
Du coup, je vous suggère d'éviter de risquer une redirection et d'appeler directement le 15. Si le 15 ne vous répond pas dans un délai raisonnable pour votre problème (ça peut arriver malheureusement, mais heureusement c'est très rare), là je suppose que tenter le 18 a du sens.
Même logique pour les problèmes non-médicaux: autant appeler tout de suite le 18.
Pour la prochaine fois, je te suggère de mettre le lien vers la vidéo (ou à défaut au moins la page Wikipedia, qu'on comprenne que c'est une référence). Parce-que là, c'est verbalement violent comme citation, et si il ne connaissait pas, il ne pouvait pas le prendre autrement. Bref, un lien, ça peut éviter des incidents diplomatiques majeurs :)
Je reste sur mon idée de vieux con que "c'était mieux avant" et que je trouve les pages Patreon sont mal foutues (point de vue utilisateur à l'instant T ; peu importe les raisons de leurs choix, je constate juste le résultat). Mais c'est vrai que appliquer la même métrique pour le site dont O'neam Anne parlait, sans même l'avoir vu, était inapproprié.
Ou alors tu es juste plus malin que tu ne le penses.
Au cours de l'évolution des espèces animales, l'empathie et l'antipathie ne sont pas apparues par hasard. Je pense qu'on peut dire que ce sont des optimisations des fonctionnements des groupes sociaux. De façon générale, l'entraide (intelligente) est rentable pour l'aidé, mais aussi pour celui qui aide, même si ça ne saute pas toujours aux yeux.
Pour clarifier mon propos:
Dans ton cas, favoriser les clients "que tu aimes bien", et surtaxer "les gros pénibles", c'est maximiser les chances de survie des premiers, et minimiser celles des des autres. Ça peut sembler négligeable à ton échelle, mais tu n'es sûrement pas le seul à faire ça, et ça se cumule.
Ça veut aussi dire maximiser les chances que ton réseau se développe de clients sympas en clients sympas, plutôt que de gros pénibles en gros pénibles.
Du coup, personnellement, je vois plutôt ça comme un investissement à (très) long terme :-).
Par contre, tu ne récupéreras probablement pas ton investissement sous forme d'argent. Tu le récupéreras sous forme de confort et de satisfaction au travail. Évidemment, tu as quand même besoin d'argent, donc il faut doser.
Bref, pour moi ton comportement et ton ressenti tient surtout de l'intelligence.
Personnellement, je ne suis pas fan de ce genre de page. Je les trouve lentes à charger et je trouve la navigation plus difficile. Mais leur aspect esthétique est indéniable, et je suppose que pour une page de promotion d'un festival, ça a du sens.
Depuis http2, tu multiplexe les requêtes dans une même connexion tout ça donc ça ne sert à rien d'essayer d'économiser les ouvertures de connexion tcp.
C'est vrai que j'en suis resté surtout à HTTP/1.1. HTTP/2 règle une bonne partie de ce problème. Il va falloir que je me mette à jour.
Cependant si tu regardes la page Patréon que j'ai mentionné (il faut être logué ; j'ai constaté ça seulement après mon 1er commentaire), tu as du javascript qui charge des bouts de pages, qui charge du javascript, etc. HTTP/2 ne peut pas faire grand chose pour optimiser ça.
il faut prendre en compte quelques petites choses ta combinaison n'augmente pas trop le volume
En compression JPEG, les espaces vides dans une image ont une taille négligeable. Par contre c'est vrai qu'une fois décompressé en mémoire, c'est à prendre en compte.
la gestion du cache qui n'est pas forcément la même pour chacun
On parle ici d'image qui ne changent que très rarement (thème, etc). Ça me semble négligeable comme problème.
tu empêche les affichages progressif
C'est vrai. Mais ce problème peut être atténué en utilisant l'entrelacement.
Ta thèse c'est que les développeurs font n'importe quoi et ne cherche plus à bien faire tout en expliquant qu'ils en subissent les effets (tu as aussi le fait que le référencement prends en compte les temps de chargement).
Ils n'en subissent pas forcément les effets.
Dans mon exemple de Patréon, il s'agit des pages quand on est loggué. Quand on est pas loggué (--> ce qu'indexe les moteurs de recherche), les pages sont considérablement plus simples et chargent très vite. Donc ça n'embête que les utilisateurs. Ça réduit peut-être l'activité sur le site, mais ça ne réduit visiblement pas le salaire des développeurs.
Dans le cas d'un site web pour la boulangerie du coin, la société de prestation qui le fait cherche à faire un site "joli" (seul vrai critère du client), et se tape du reste.
Tout ça pour dire que prendre une métrique sans vraiment se poser la question de sa pertinence pour sortir des jugements
Dans le cadre de mon exemple (Patréon), je maintiens que cette métrique est pertinente. Par contre, je reconnais que dans le cas d'un site (presque) statique pour un festival, en HTTP/2, cette métrique n'a plus forcément de sens.
Tu considère que la population des développeurs sont des imbéciles incapables de se rendre compte de ce que toi tu vois ?
Pas tous.
Quand il s'agit de faire de la merde, certains ont une imagination sans fin (vécu). Il y en aussi beaucoup qui en font par manque de moyens ou de temps. Certains en font parce-que leur employeur ne leur laisse aucune flexibilité et les oblige à utiliser des méthodes de travail qui ont 20 ans de retard.
Après 10 ans de carrière, je peux dire que j'ai vu beaucoup trop d'atrocités et que plus rien ne me surprend. Vu tout les commentaires ici, je ne suis pas le seul.
Le trafic échangé est le même la RAM utilisé est la même.
Faux et faux.
C'est vrai que la différence de consommation RAM est subtile. Ça se joue probablement à un gros paquets de pointeurs mémoire prêt, et à une fragmentation mémoire plus importante. De nos jours, c'est clairement négligeable.
Par contre, pour le trafic, avec les cookies et tout les entêtes HTTP, tu as des sites qui montent facilement 1 à 2Ko par requête. Quand c'est pour des images de ~10Ko, ce n'est pas négligeable. (je me base sur ma connaissance de HTTP/1.1, je n'ai pas encore regardé comment HTTP/2 formate les entêtes)
Tu oublis aussi le principale problème posé par ces requêtes: la latence. Je t'accorde que HTTP/2 a résolu une grosse partie de ce problème. Mais quand tu as du javascript qui charge dynamiquement du javascript, qui charge dynamiquement du javascript (voir la page Patréon quand on est logué dessus), le temps de chargement explose quand même, HTTP/2 ou pas.
Aussi, beaucoup de sites sont encore en HTTP/1.1. Quand tu as 40 images à charger depuis le même host, tu as 40 requêtes/réponse. Le navigateur va peut-être paralléliser 2 ou 3 requêtes/téléchargements, mais pas plus.
C’est probablement beaucoup plus simple que ça : les pages « non identifié » sont statiques et servis par Cloudflare depuis le cache et les pages « identifié » sont généré côté serveur par un framework web quelconque.
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é.
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 :-)
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).
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 :-)
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).
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.
[^] # Re: Public Suffix List incomplète...
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Firefox 77. Évalué à 4. Dernière modification le 10 juin 2020 à 10:36.
C'est aussi embêtant, si, comme moi, on utilise zeroconf/avahi-daemon pour tous ses services sur son réseau local perso (par exemple http://jellyfin.local/ ).
# Docker + Django + Apache
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Ça passe crème. Évalué à 4. Dernière modification le 18 avril 2020 à 23:26.
J'ai récemment passé le site openpaper.work dans Docker. C'est aussi du Django. J'avais vu beaucoup de doc et tutoriels de dockerisation qui montraient comment le faire en utilisant aussi le serveur web de développement de Django. Bien que ça peut peut-être faire l'affaire dans un environnement cloud, ça ressemble quand même à une mauvaise idée. Dans mon cas, je n'ai de toute façon qu'un seul conteneur qui tourne. Donc j'ai choisi de continuer à utiliser un serveur Apache dans le conteneur. Ça donne ça: Dockerfile + start.sh + docker.
Comme c'est la 1ère fois que je dockerise quelque-chose de sérieux, je serais intéressé d'avoir l'avis de gens qui s'y connaissent mieux en Docker.
# FlowBlade
Posté par Jérôme Flesch (site web personnel) . En réponse au journal OpenShot Video Editor vs Kdenlive le retour !. Évalué à 5. Dernière modification le 08 avril 2020 à 21:40.
Avant-hier et hier, j'ai voulu éditer rapidement 2 vidéos.
J'ai cru comprendre que Kdenlive était assez populaire, donc je l'ai essayé très rapidement avant-hier. Je l'ai fait freezer en moins de 5 minutes d'utilisation: J'ai déplacé son moniteur de projet sur mon deuxième écran, et paf, GUI bloquée. Depuis, quand je le démarre, il freeze après ~30s. Testé avec la version dans Debian stable et la version Flatpak. Du coup, j'ai passé mon chemin.
Je suis revenu sur un logiciel que j'avais déjà utilisé par le passé: Flowblade. Je l'avais choisi initialement parce-qu'il avait la réputation d'être un peu plus simple que les autres.
Positif:
Négatif:
Je pense que je vais donner une chance à OpenShot la prochaine fois. Le rendu via GPU pourrait offrir un bon gain de temps.
[^] # Re: Prompt rétablissement !
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Sars-CoV-2 et moi. Évalué à 6.
Non, c'est le 15.
Les évacuations sont souvent faites par les pompiers, mais pas toujours. Ça peut être des ambulances privées ou des associations de secourisme agréées qui les font. Ces derniers se rattachent toujours au 15, jamais au 18.
De plus, en fonction du problème et de l'état de la victime, le 15 peut décider de faire intervenir un SMUR (médecin + infirmier + équipement spécifique) plutôt que juste un VSAV/VPSP/ambulance. Par exemple, si vous appelez pour une crise cardiaque, un SMUR va décoller immédiatement. Si vous appelez pour une hémorragie mais que la victime a déjà perdu beaucoup/trop de sang (voir même a perdu conscience), le transport peut se révéler dangereux et le médecin peut donc aussi décider d'envoyer un SMUR.
Encore une fois, le détail dépend des départements. Je suppose que certains 18 ont peut-être leur propre médecins et leur propre SMUR. Mais c'est difficile à savoir.
Dans tout les cas, ce n'est pas au secouriste de supposer qu'il y aura évacuation ou non. C'est le médecin du 15 qui décide ça (cf référentiel secourisme). Donc si c'est médical, c'est le 15 qu'il faut appeler.
[^] # Re: Prompt rétablissement !
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Sars-CoV-2 et moi. Évalué à 9. Dernière modification le 25 mars 2020 à 11:50.
Juste une petite note sur le 18:
Sauf erreur de ma part, en fonction de comment votre département est organisé pour les secours, appeler les pompiers pour un problème médical peut avoir différents résultats:
Du coup, je vous suggère d'éviter de risquer une redirection et d'appeler directement le 15. Si le 15 ne vous répond pas dans un délai raisonnable pour votre problème (ça peut arriver malheureusement, mais heureusement c'est très rare), là je suppose que tenter le 18 a du sens.
Même logique pour les problèmes non-médicaux: autant appeler tout de suite le 18.
[^] # Re: indispensable en entreprise
Posté par Jérôme Flesch (site web personnel) . En réponse au sondage Les proxys HTTP. Évalué à 2. Dernière modification le 17 janvier 2020 à 17:34.
Pour la prochaine fois, je te suggère de mettre le lien vers la vidéo (ou à défaut au moins la page Wikipedia, qu'on comprenne que c'est une référence). Parce-que là, c'est verbalement violent comme citation, et si il ne connaissait pas, il ne pouvait pas le prendre autrement. Bref, un lien, ça peut éviter des incidents diplomatiques majeurs :)
Au passage, c'est pas plutôt une référence à la classe américaine ?
[^] # Re: Les vieux de mon âge
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Tout cela me fatigue…. Évalué à 5.
En fait, tu as raison.
Je reste sur mon idée de vieux con que "c'était mieux avant" et que je trouve les pages Patreon sont mal foutues (point de vue utilisateur à l'instant T ; peu importe les raisons de leurs choix, je constate juste le résultat). Mais c'est vrai que appliquer la même métrique pour le site dont O'neam Anne parlait, sans même l'avoir vu, était inapproprié.
# Malin
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Facturer comme un chirurgien. Évalué à 7. Dernière modification le 17 janvier 2020 à 11:32.
Ou alors tu es juste plus malin que tu ne le penses.
Au cours de l'évolution des espèces animales, l'empathie et l'antipathie ne sont pas apparues par hasard. Je pense qu'on peut dire que ce sont des optimisations des fonctionnements des groupes sociaux. De façon générale, l'entraide (intelligente) est rentable pour l'aidé, mais aussi pour celui qui aide, même si ça ne saute pas toujours aux yeux.
Pour clarifier mon propos:
Dans ton cas, favoriser les clients "que tu aimes bien", et surtaxer "les gros pénibles", c'est maximiser les chances de survie des premiers, et minimiser celles des des autres. Ça peut sembler négligeable à ton échelle, mais tu n'es sûrement pas le seul à faire ça, et ça se cumule.
Ça veut aussi dire maximiser les chances que ton réseau se développe de clients sympas en clients sympas, plutôt que de gros pénibles en gros pénibles.
Du coup, personnellement, je vois plutôt ça comme un investissement à (très) long terme :-).
Par contre, tu ne récupéreras probablement pas ton investissement sous forme d'argent. Tu le récupéreras sous forme de confort et de satisfaction au travail. Évidemment, tu as quand même besoin d'argent, donc il faut doser.
Bref, pour moi ton comportement et ton ressenti tient surtout de l'intelligence.
[^] # Re: Les vieux de mon âge
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Tout cela me fatigue…. Évalué à 3.
Ah une page en continuous scrolling grosso-modo ?
Personnellement, je ne suis pas fan de ce genre de page. Je les trouve lentes à charger et je trouve la navigation plus difficile. Mais leur aspect esthétique est indéniable, et je suppose que pour une page de promotion d'un festival, ça a du sens.
[^] # Re: Les vieux de mon âge
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Tout cela me fatigue…. Évalué à 2.
C'est vrai que j'en suis resté surtout à HTTP/1.1. HTTP/2 règle une bonne partie de ce problème. Il va falloir que je me mette à jour.
Cependant si tu regardes la page Patréon que j'ai mentionné (il faut être logué ; j'ai constaté ça seulement après mon 1er commentaire), tu as du javascript qui charge des bouts de pages, qui charge du javascript, etc. HTTP/2 ne peut pas faire grand chose pour optimiser ça.
En compression JPEG, les espaces vides dans une image ont une taille négligeable. Par contre c'est vrai qu'une fois décompressé en mémoire, c'est à prendre en compte.
On parle ici d'image qui ne changent que très rarement (thème, etc). Ça me semble négligeable comme problème.
C'est vrai. Mais ce problème peut être atténué en utilisant l'entrelacement.
Ils n'en subissent pas forcément les effets.
Dans mon exemple de Patréon, il s'agit des pages quand on est loggué. Quand on est pas loggué (--> ce qu'indexe les moteurs de recherche), les pages sont considérablement plus simples et chargent très vite. Donc ça n'embête que les utilisateurs. Ça réduit peut-être l'activité sur le site, mais ça ne réduit visiblement pas le salaire des développeurs.
Dans le cas d'un site web pour la boulangerie du coin, la société de prestation qui le fait cherche à faire un site "joli" (seul vrai critère du client), et se tape du reste.
Dans le cadre de mon exemple (Patréon), je maintiens que cette métrique est pertinente. Par contre, je reconnais que dans le cas d'un site (presque) statique pour un festival, en HTTP/2, cette métrique n'a plus forcément de sens.
Pas tous.
Quand il s'agit de faire de la merde, certains ont une imagination sans fin (vécu). Il y en aussi beaucoup qui en font par manque de moyens ou de temps. Certains en font parce-que leur employeur ne leur laisse aucune flexibilité et les oblige à utiliser des méthodes de travail qui ont 20 ans de retard.
Après 10 ans de carrière, je peux dire que j'ai vu beaucoup trop d'atrocités et que plus rien ne me surprend. Vu tout les commentaires ici, je ne suis pas le seul.
[^] # Re: Les vieux de mon âge
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Tout cela me fatigue…. Évalué à 2.
Faux et faux.
C'est vrai que la différence de consommation RAM est subtile. Ça se joue probablement à un gros paquets de pointeurs mémoire prêt, et à une fragmentation mémoire plus importante. De nos jours, c'est clairement négligeable.
Par contre, pour le trafic, avec les cookies et tout les entêtes HTTP, tu as des sites qui montent facilement 1 à 2Ko par requête. Quand c'est pour des images de ~10Ko, ce n'est pas négligeable. (je me base sur ma connaissance de HTTP/1.1, je n'ai pas encore regardé comment HTTP/2 formate les entêtes)
Tu oublis aussi le principale problème posé par ces requêtes: la latence. Je t'accorde que HTTP/2 a résolu une grosse partie de ce problème. Mais quand tu as du javascript qui charge dynamiquement du javascript, qui charge dynamiquement du javascript (voir la page Patréon quand on est logué dessus), le temps de chargement explose quand même, HTTP/2 ou pas.
Aussi, beaucoup de sites sont encore en HTTP/1.1. Quand tu as 40 images à charger depuis le même host, tu as 40 requêtes/réponse. Le navigateur va peut-être paralléliser 2 ou 3 requêtes/téléchargements, mais pas plus.
Bien vu :)
[^] # Re: Les vieux de mon âge
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Tout cela me fatigue…. Évalué à 3. Dernière modification le 16 janvier 2020 à 12:07.
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é.
[^] # Re: sympa
Posté par Jérôme Flesch (site web personnel) . En réponse au journal term2web : un terminal sur le Web (Python). Évalué à 5.
Ce genre là: https://bellard.org/jslinux/ ?
[^] # Re: Les vieux de mon âge
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Tout cela me fatigue…. Évalué à 8. Dernière modification le 08 janvier 2020 à 14:18.
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:
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.
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.
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 …
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).
[^] # Re: flatpak c'est nul
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Flatpak et Nix. Évalué à 3. Dernière modification le 03 janvier 2020 à 14:29.
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.
# Problème mal défini
Posté par Jérôme Flesch (site web personnel) . En réponse au journal [HS] Quand les français votent avec leur argent. Évalué à 10. Dernière modification le 21 novembre 2019 à 10:36.
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.
/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.
# Comparer des pommes et des oranges
Posté par Jérôme Flesch (site web personnel) . En réponse au journal [HS] Quand les français votent avec leur argent. Évalué à 10. Dernière modification le 21 novembre 2019 à 09:59.
Donc 1 million de gens qui pensent que c'est une idée de merde.
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.
# La qualité des scams nouvelle génération
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Les compagnies informatiques le détestent. Évalué à 10. Dernière modification le 30 octobre 2019 à 16:53.
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 :-)
[^] # Re: Découverte de flatpak
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Snap, Flatpak, Packagekit : c'est quoi ce bordel ?. Évalué à 4.
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).
[^] # Re: Découverte de flatpak
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Snap, Flatpak, Packagekit : c'est quoi ce bordel ?. Évalué à 4. Dernière modification le 17 octobre 2019 à 12:23.
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.
[^] # Re: Signaler et porter plainte
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Les cons? ça ose tout!. Évalué à 10. Dernière modification le 17 octobre 2019 à 11:54.
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 :-)
# Propositions
Posté par Jérôme Flesch (site web personnel) . En réponse au journal recherche jeu et chat pour préados. Évalué à 3. Dernière modification le 07 octobre 2019 à 13:50.
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).
[^] # Re: Erreur
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Base de données de scanners : besoin de contributeurs (yep, encore). Évalué à 2.
https://gitlab.gnome.org/World/OpenPaperwork/ironscanner#from-sources
[^] # Re: Erreur
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Base de données de scanners : besoin de contributeurs (yep, encore). Évalué à 2. Dernière modification le 12 septembre 2019 à 17:25.
Au moins on avance :-)
Je crois qu'il y a une légère confusion dans les instructions. Comme indiqué dans le README, le
source ./activate_test_env.shest à 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, fairemake installdans 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.[^] # Re: Erreur
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Base de données de scanners : besoin de contributeurs (yep, encore). Évalué à 2.
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?sane-backends.pcquelque-part dans /usr ? Sinon, un.pcavec un nom similaire ? Auquel cas je peux patcher lemeson.build.