orfenor a écrit 1453 commentaires

Pour ceux qui préfèrent une solution simple, auto-hébergée, plus ou moins sécurisée (ça dépend de vous), on peut installer un gestionnaire de mots de passe dans Nextcloud. Et même son extension Firefox/Chrome.

Et Yunohost en propose d'autres.

Code source de gigablast
https://github.com/gigablast/open-source-search-engine

(notez les derniers chgangements de license, à propos de l'entrainement des IA, for intéressant).

Dans le récent journal de Ploum sur la rédaction on parlait de la présence anciens/nouveaux dans l'espace de rédaction. Pourrais-tu, d'un coup de scripting magique, nous éclairer là-dessus ?

Yacy est un excellent moteur, mais il est très différent : il est décentralisé, son index, sa pertinence et sa rapidité dépendent du nombre d'installations de Yacy (au passage, installez-le, il est peu gourmand).

Si tu veux citer des projets similaires, il y a (Mojeek)[https://www.mojeek.com/about/] qui en était à plus de 7 milliards de pages indexées fin 2023, qui ne vous trace pas et même vous protège, et Yep un petit nouveau.

Gigablast, un vieil indépendant, est mort récemment, mais le code source est disponible je ne sais plus où. Gigablast indexait environ 1 milliard de sites web pour un coût très faible, c'était même le but de son auteur : faire un moteur qui ne coûte presque rien. Donc si quelqu'un veut relancer le projet sans dépenser trop d'argent, c'est faisable.
NB: gigablast.org fonctionne sans que ce soit très clair et me semble récupérer les données de Bing.

Pour tout savoir sur les moteurs de recherche, leur indépendance et leurs index, Mojeek fournit la Search Engine Map, une carte interactive qui montre les relations entre tout ce beau trouble monde.

Linuxfr est un site d'actualités qui publie aussi des articles de fond, comme la plupart des bons sites d'actualité (Nextinpact)

Si on n’a jamais vu l’original, on ne peut pas savoir que l’information est perdue.

Je n'y avais pas pensé, c'est très pertinent. À mon avis, ça vaut le coup de transmettre cette remarque à Jon Sneyer et aux autres, vu qu'on n'en parle jamais et qu'il est couramment admis (au vu des tests) que l'algo de Mozjpeg est aussi performant que WEBP.

Très bonne idée
Les commentaires du journal pourraient servir à repasser le journal en dépêche… :-)

il ne faudrait pas oublier que l'âge aidant, des contraintes (familiales ?) surgissent inopinément pour ralentir brusquement notre écriture.

Ta comparaison entre JPEG et WEBP est critiquable. Mais tu ne connais probablement pas ces gory details :

Au niveau du JPEG, les niveaux de qualité ne veulent pas dire grand chose parce qu'ils ne sont pas standardisés. Ils diffèrent d'un logiciel à l'autre. Par conséquent comparer avec le même niveau de qualité en WEBP n'a pas de sens. On compare la qualité du rendu à la fois en l'appréciant de façon subjective (par exemple on compte les défauts, les mauvaises couleurs, les artefacts, …) et de façon quantifiée avec MSSIM.
L'algo de compression JPEG utilisé est très important. Lui aussi diffère d'un logiciel à l'autre. Celui de libjpeg-turbo est le plus rapide, tout en proposant un excellent rapport poids/qualité. Celui de Mozjpeg dérive de libjpeg-turbo et c'est de loin le plus avancé pour le rapport poids/qualité, au point d'égaler fréquemment WEBP sur ce point,tout en étant beaucoup plus rapide.

Je te renvoies aux comparaisons citées plus haut : l'équipe WEBP et celle de Cloudinary (dirigée par Jon Sneyer) utilise systématiquement libturbo et Mozjpeg.

Même si Jon Sneyers espère qu'on aura des circuits spécialisés pour JXL, il souligne que JXL se décode facilement en "pur logiciel" contrairement à AV1 et HEVC sur lesquels se basent AVIF et WEBP.

AVIF est limité dans la taille des images (9 Mo), le nombre de bits (12) et le nombre de canaux (3).

l'impression

C'est bien ce que je dis, vous n'en savez rien. Il ne s'étend pas sur le sujet (ce doit être lassant depuis toutes ces années) et vous en déduisez des trucs. C'est pourtant facile de déduire dans l'autre sens :

• Il a des services professionnels sur le web (des sites web quoi) et il utilise donc une solution d'analytics sur ses sites (il utilise Matomo) pour suivre les visiteurs. Peut-être que vous n'avez jamais regardé dans ces outils, mais moi qui m'en sers je peux te dire qu'on voit comment les visiteurs viennent, avec quelles recherches, et comment nos pages sortent dans les résultats de Google ou Bing. Avec ces outils, on peut très facilement et concrètement mesurer ce qu'un nom apporte en avantage d'audience parce que deux éléments sautent immédiatement aux yeux :
  1. ceux qui te cherchent via ton nom et qui te trouvent tout de suite parce que ton nom est suffisament différent pour que tu sortes en tête,
  2. ceux qui font des mauvaises recherches, c'est à dire les gens qui viennent chez toi par erreur et qui ralentissent ton serveur, bouffent ta bande passante, etc.
• Changer de marque commerciale ça coûte des sous et de la paperasse. L'avantage est peut-être justement là, si ne pas changer est jugé plus efficace.
• Enfin, tout bêtement le nom peut servir à filtrer les gens motivés. Vu les petits moyens ils n'ont peut-être pas envie de plus d'audience pour l'instant, seulement des gens motivés qui n'auront pas besoin de trop de support (il le dit d'ailleurs).

C'est d'ailleurs l'argument de Mozilla (lien cité plus haut).

C'est son universalité qui rend JPEG-XL intéressant. On voit bien pourquoi les photographes vont l'utiliser par exemple, d'autres secteurs vont aussi l'adopter (comme les nouveaux tel Samsung pour les photos). Ce qui pourrait alors se passer c'est une adoption plus tardive sur le web, vu que

• la taille des images augmente avec la taille des tuyaux,
• l'adoption de JXL pour d'autres usages que le web pourrait amener des circuits spécialisés dans les puces,
• la puissance du matériel et la quantité de Ram augmentent tout le temps, ce qui rendra le décodage du JXL plus facile.

Donc dans quelques années, les circuits spécialisés, la puissance disponible et la taille des images pourrait faire que le gain relativement faible de JXL sur AVIF ou WEBP représente un important gain absolu.

Ce support a été retiré par manque d'adoption.

Non c'est faux : le code était expérimental et pas activé.

Ah zut, je voulais dire que si l'on en croit les graphiques ça fait sens, etc. Pas que ça faisait sens tout court.

Les graphiques des test de performance montrent au contraire que JPG-XL est de loin le plus lent des formats à décoder.

Vu ces graphiques je trouve que ça fait sens de ne pas adopter JXL tout de suite. Grâce à Chrome, Google a d'excellentes statistiques sur les mobiles utilisés dans le monde. Beaucoup sont anciens à mon avis (sinon pourquoi inclure un Pixel3 dans les tests?), leur batterie l'est donc tout autant. Or plus c'est lent à décoder, plus ça bouffe du CPU et de la RAM, plus le niveau de la batterie baisse vite. Sur une batterie déjà usée, ça doit être catastrophique.

Finalement, Apple qui a aussi d'excellente statitiques et qui connaît à fond son matériel, l'implémente peut-être parce que sur les iPhones ça passe. En plus Apple connait bien ses acheteurs qui vont se ruer vers des iPhones plus puissant avec les nouvelles puces M1/M2 pour décoder le nouveau format qu'il est hype.

Comment peux-tu savoir mieux que lui ce que son nom lui apporte? il a certainement mesuré l'avantage.

Comme d'habitude avec Gael duval on sent l'enthousiasme, c'est rafraichissant!

Pour ceux qui préfèrent lire, l'interview est transcrite sous le lien audio.

changer le nom (…) mais Gaël ne veut pas l'entendre

Il explique pourquoi dans l'interview :

le nom il a des inconvénients mais il a aussi un avantage
…
faire parler les gens et d’avoir une espèce de truc qui se passe en termes de com, de buzz

C'est pour l'intéropérabilité

minimal set of mechanisms required to make modern Internet messaging services interoperable

Trop classe ton nouvel avatar! mais ça va pas du tout avec ton pseudo, surtout en pensant à sa voix ;-)

Je pense depuis longtemps que les «petits» ERP libres (OpenConcerto, Noalyss, Laurux, …), devraient avoir un modèle de données et des formats plus ou moins communs qui permettraient de passer de l'un à l'autre sans que ça coûte trop cher (voire d'échanger des infos entre ERP).
Par exemple un format de données exporté et importé en XML avec du XSLT / XPATH pour adapter les données à l'autre logiciel.
Comme ce n'est jamais rassurant de «confier les clés» de sa gestion à une boite qui gagne peu d'argent, savoir qu'on peut facilement changer pourrait aider à l'adoption, non?

Je sais bien que les modèles de données sont différents d'un logiciel à l'autre, mais puisqu'on adapte déjà à la main quand les clients migrent, ce doit être faisable d'adopter un modèle commun. Mis à part le temps d'implémentation, qu'est ce qui pourrait vous freiner à le faire ?

Fabien Pinckaers a expliqué dans je ne sais plus quelle vidéo comment le modèle de prix et les anciens noms gênaient la crédibilité d'Odoo: "TinyERP" = trop petit, "OpenERP" = pourquoi payer ? etc. On peut critiquer son changement de modèle de prix et de licence depuis 8 ans, mais ça lui a permis de satisfaire plein de clients petits et gros, et d'avoir de la trésorerie.
J'imagine que tu y as déjà réfléchi, mais au cas où.

Très intéressante et utile ta série d'articles, merci.

Tu devrais écrire dans la rubrique Journaux pour présenter le tout, ça donnerait beaucoup plus de visibilité.

J'oubliais :
Si tu as essayé Reactos x86-64 c'est normal d'avoir des problèmes, ce nb'est pas prêt du tout. La version 32 bits marche plutôt bien. Cela dit je n'ai pas retesté depuis 2021.

KolibriOs au delà de l'effet Waouh! et des jeux est loin d'être utilisable au quotidien.