Euh … salut. Ce commentaire ne parle ni d'orthographe, ni de féminisme. A-t-il sa place ici ? était-ce un journal piège ? Je n'ai pas vraiment perdu de vue mon projet de mémo (pour une liste des clones de Red Hat Entreprise Linux), c'est le temps qui a l'air monté sur patins à roulettes et m'échappe. En voulant faire ça bien, j'ai fait du sur-place. Pour être utile ce mémo doit rester globalement court, concis et informatif, avec une pifométrie rigoureuse pour évaluer les avantages présents et futurs, les communautés, l'engagement, le cuir du portefeuille et les intentions cachées.
Je pourrai m'y remettre, j'espère, avant l'été, quand les vagues viendront lêcher mes pieds le matin, un café chaud sur ma gauche, une étendue de sable lisse à ma droite pour prendre des notes.
Au delà du côté marketing évident — c'est nouveau, ça lave encore plus blanc que blanc — c'est peut-être aussi lié à la vitesse d'assemblage des portables, qui est supérieure à celle de production des composants. C'est le cas pour les disques durs : pour réparer les cartes contrôleuses (PCB), on doit chercher un disque identique, sorti de la même usine, de la même ligne d'assemblage, le même jour voire la même heure ; sans cela, on risque de tomber sur des composants différents, donc un firmware différent, donc une lecture impossible… et tout ce tintouin parce que les fournisseurs de composants ne peuvent pas suivre la cadence de production, ils sont donc plusieurs, ce qui provoque de multiples combinaisons d'assemblage sur les cartes contrôleuses.
Si je me souviens bien d'une interview de Noam Chomski, c'est un point de vue lié à la culture française. Alors qu'aux États-Unis la liberté d'expression est presque absolue, ne se discute pas. Noam Chomski y trouvait plus d'avantages que de défaut. Je ne sais pas s'il a discuté le problème que tu évoques, mais ce serait intéressant de confronter, sur ce sujet, les points de vue de chercheurs américains avec ceux des chercheurs français (les sociologues surtout).
est-ce que Facebook peut espérer avoir plus d'utilisateurs, en dehors de la croissance de la population humaine ?
Je pense que oui : vers la fin des années 90, les logiciels de marketing viral permettait d'animer des personnages fictifs dans les forums. Ces personnages étaient bien définis, avec chacun ses caractéristiques réalistes : langage, tics, sujets d'intérêt, amitiés, etc. Ça ne demandait pas beaucoup d'employés pour gérer des dizaines ou des centaines de personnages. Je ne vois pas pourquoi on n'en trouverait pas sur Facebook, et ça va même se développer.
On ne parlait que du web dans cette discussion… Or, JPEG-XL n'est plus dans Chrome ni Chromium, Mozilla se déclare neutre sur le sujet (autrement dit ça va stagner) et Apple, 3ème poids lourd, n'a pas commencé. Et ce n'est que le dessus de l'iceberg ! Aucun navigateur mobile n'a commencé son intégration, or le web est majoritairement visité sur des mobiles. Voilà pourquoi je pense qu'aujourd'hui c'est mal barré pour JPEG-XL sur le web. Mais bien entendu ça peut changer.
Non, tu n'as pas compris. Faut lire la discussion et les critiques sous la PR et les bugs en rapport : il y a des trucs à revoir, du code à faire. Les changement dans Mozjpeg permettront seulement de l'inclure dans les distros Linux et donc d'en faire une dépendance de Gimp. Tout restera à faire concernant un plugin de Gimp. Et accessoirement, Mozjpeg n'est plus maintenu par Mozilla, mais par Kornelski.
Mozjpeg utilisable dans Gimp c'est assez simple : il faut rendre Mozjpeg installable en parallèle de libjpeg (ou libjpegturbo). C'est un patch de Jehan qu'il faut revoir.
Mais pour avoir une interface graphique avec les options qui vont bien c'est autre chose. Jehan me l'a bien expliqué. Y'a du boulot et on voulait le payer pour ça. J'ai fait une interface en CLI qui masque la difficulté et nous permet (ma copine et moi) de l'utiliser en rafale sur un grand nombre d'images.
Effectivement ça vaudrait le coup de lancer un co-financement. Il suffit d'essayer Mozjpeg via ImageOptim online pour se rendre compte des bons résultats. Cela dit il y a des images pour lesquelles on ne fait pas aussi bien que WebP. L'image utilisée dans l'article en est un bon exemple.
Oui j'avais proposé à Jehan de le payer pour une interface à Mozjpeg. Mais on avait peu de moyens. De fil en aiguille il a proposé à Kornelski des modifications, pour intégrer Mozjpeg à Gimp, mais ça stagne.
Save for the web fait du bon boulot à partir de la libjpeg. Mais ne peut pas faire plus que ce que la lib propose. Tandis que Mozjpeg est basé libjpegturbo, qui dispose d'options avancées — et en ajoute qq autres bien sûr.
Pour utiliser Libjpegturbo/Mozjpeg je prépare une image de la plus haute qualité possible, parce que JPEG est mauvais sur la recompression. Ensuite je passe les paramètres à cjpeg (l'utilitaire de compression JPEG standard). J'utilise le cjpeg de Mozjpeg si je l'ai compilé, sinon celui de libjpegturbo.
Voilà les paramètres de libjpegturbo
progressive: progressive jpeg (default)
optimize: libturbo optimizations (default)
smooth: smoothness to reduce jpeg artifacts
sample 1x1: allow to separate Luminance & Chrominance quality
quality: Luminance and Chrominance quality (JPEG compression)
5 Table from paper by Klein, Silversteien and Carney
6 Table from paper by Watson, Taylor and Borthwick
7 Table from paper by Ahumada, Watson, Peterson
8 Table from paper by Peterson, Ahumada and Watson
dc-scan-opt: DC scan optimization mode (default is 1)
notrellis Disable trellis optimization
trellis-dc Enable trellis optimization of DC coefficients (default)
notrellis-dc Disable trellis optimization of DC coefficients
tune-psnr Tune trellis optimization for PSNR
tune-hvs-psnr Tune trellis optimization for PSNR-HVS (default) mesure la distorsion de l'image
tune-ssim Tune trellis optimization for SSIM
tune-ms-ssim Tune trellis optimization for MS-SSIM
… et d'autres pour les "sorciers"
Et voici comment faire
Le paramètre qui a le plus d'effet est dans libjpegturbo, c'est la compression différente pour la Luminance et la Chrominance. On va vulgariser un peu et les appeler lumière et couleur (c'est moins long à taper). Pour la lumière on met le paramètre de compression JPEG habituel, pour la couleur on met 1/4 ou 1/3 en général. Attention c'est lumière d'abord, couleur ensuite.
Pour jouer sur les qualités de lumière et de couleur il faut impérativement le paramètre sample 1x1.
Le lissage (paramètre smooth) alourdit l'image et créé un peu de flou, auquel mon oeil est très sensible. L'utilisation des tables de quantisation permet de s'en passer avec Mozjpeg.
Les tables de quantisation, c'est le deuxième paramètre qui a beaucoup d'effet. Pour le web, c'est le plus souvent la table 3 qui fait gagner le plus de poids, ensuite ce sont les tables 2 et 5. Les tables 7 et 8 permettent d'archiver avec une excellente qualité (je ne retrouve pas la discussion dans les bugs et PR de mozjpeg, mais c'est dedans) ; il m'arrive de m'en servir pour améliorer le rendu d'une image bien compressée, le poids supplémentaire est alors acceptable.
La CLI de base est donc cjpeg -sample 1x1 -quality 65,21
ça marche avec libjpegturbo (on peut ajouter -smooth [un nombre] pour corriger les artefacts de compression JPEG.
Et si on compile Mozjpeg, la CLI de base est cjpeg -sample 1x1 -quality 65,21 -smooth 0 -quant-table 3
… à laquelle je rajoute souvent -dc-scan-opt 2
Les autres paramètres servant (si j'ai bien compris) pour faire des comparaisons automatiques de qualité d'image.
J'utilise tout le temps Mozjpeg. Avec des options "bien choisies", le poids des images descend au niveau d'une compression WebP. Kornelski, le mainteneur de Mozjpeg, a fait un utilitaire bien utile pour ceux qui ne veulent pas mettre la main dans le cambouis : ImageOptim qui existe en version online et en version Mac, livre directement l'image optimisée.
Avec un petit script Perl, on arrive à faire mieux qu'ImageOptim, en conservant la simplicité d'usage, mais au prix d'une appréciation "manuelle" de la qualité (avec l'habitude ça va vite).
Et à propos de la qualité, il faudrait que "les gens" remettent un peu les pieds sur terre : dans la plupart des pages web que je vois, on passe rapidement sur les images, rares sont celles qu'on regarde. De toute façon, les 3/4 des visiteurs sont sur mobile et consultent donc les pages dans de mauvaises conditions de lumière, et avec des reflets. Quant à ceux qui surfent sur grand écran, lequel a fait un calibrage ? Bref, rappelez vous les années modems, quand les images étaient petites et allégées au max. Une bonne pratique c'est d'alléger au max les premières images de la page, celles qui soutiennent le texte pour donner une vue d'ensemble. Et d'en mettre des belles, si besoin, un peu plus bas, pour ceux qui veulent des détail et s'intéressent au sujet. Ma copine le fait depuis 2 ans (elle vend des jouets), sa clientèle est ravie d'aller vite.
En faveur de JPEG, il ne faut pas oublier la relative rapidité de décompression sur nos CPUs.
Peut-être faudrait-il ajouter dans le statut du document DESIGN les priorités (révisées) et une indication de la stabilité (ou toute autre méthode, comme MoSCoW… utilisée dans les RFC) ?
Posté par orfenor .
En réponse à la dépêche DragonFlyBSD 6.2 et 6.4.
Évalué à 4.
Dernière modification le 12 février 2023 à 08:43.
La partie sur le clustering n'est plus aussi intéressante qu'il y a 10 ans, je doute que ce soit encore un objectif majeur d'HAMMER2. En effet, on croyait beaucoup aux grappes de machines qui apparaissaient comme une machine unique. Ce qu'on appelle du Single System Image (SSI) : on prend un cluster de machine hétérogène, on installe le soft magique, et hop, toutes les machines n'en font plus qu'une ; les ressources CPU, disques, mémoire sont partagées et gérées de façons globales. Par exemple on a beaucoup parlé de Kerrighedici-même. Jean Parpaillon, qui fut membre de l'équipe, pourrait peut-être en parler.
Il me semble que les SSI sont plus ou moins abandonné parce que l'intéret s'est déplacé sur les machines virtuelles.
Je parcours ceux de KDE pour me faire une idée des changements, plus sérieuse que les copies d'écran tape à l'oeil des annonces de sortie ; je les parcours aussi pour vérifier qu'un projet est super actif ou continue la chasse aux bugs (Kate et les KIO pour rester dans KDE par exemple).
J'y farfouille avant de rapporter un bugs
Je les lis sans rien comprendre, en me disant que ça avance ça avance, trop frustré par le laconisme des développeurs consciencieux qui laissent passer des années entre les nouvelles versions salivantes (par exemple chez Haïku)!
Je les remplis avec excès pour me dire que j'ai fait plein de trucs, c'est dur le travail solitaire.
Sous ma casquette de sysadmin je lis certains changelogs de paquets, mais je ne suis pas assidu.
si tu contribuais avec des identités différentes, il ne serait pas possible de faire le lien entre le "toi" du xonotic (ou unvanquished, ou je ne sais quel autre projet, peu importe) et le "toi" de linuxfr, ce qui te permettrait donc d'être une source secondaire au lieu de primaire.
Certes, mais je pense que ça n'a pas d'importance si la contribution est validée par le plussage de la communauté. C'est la pertinence de la contribution qu'il faut prendre en compte, c'est à dire que la personne ne raconte pas n'importe quoi.
C'est comparable à une interview de presse écrite. Bien que l'interviewé puisse raconter n'importe quoi sans grand contrôle. Hors, comme je l'ai mentionné plus haut (juste au-dessus et en dessous du propos de Thomas sur Linuxfr), ces interviews n'en demeurent pas moins une source référencée dans un bon nombre d'articles sur Wikipedia.
Euh… je ne parlais pas des dépêches ni des journaux, mais des commentaires :
pourquoi un commentaire authentifié, validé par le plussage, ne peut-il servir de source dès lors qu'il raconte un truc personnel ? alors qu'une interview parue dans la presse le peut (sauf erreur, je répète) ? Le problème est important lorsqu'on aborde des sujets contemporains pour lesquels il y a plus d'infos sur le web que dans la presse écrite, vu que la presse a beaucoup de mal a parler sans erreurs de sujets contemporains.
Pour éviter qu'on ne sabote un article sur un écrivain décédé, j'ai précisé dans la page de discussion que je restructurai beaucoup et que j'ajouterai les sources correctes à la fin. C'était efficace.
Absolument. Je remarque aussi que ce commentaire détaillant toute l'histoire, s'il était dans une interview de Thomas dans la presse papier, pourrait servir de source (y'en a plein comme ça dans Wikipedia), tandis que sur un site collaboratif comme linuxfr, non. Sauf erreur de ma part bien sûr.
# J'adore cet article
Posté par orfenor . En réponse à la dépêche Une page se tourne à l'April, une libraire est présidente depuis 100 jours. Évalué à 8.
Quel enthousiasme, quel ton, quelle liberté ! ça fait respirer.
# suis-je à ma place ?
Posté par orfenor . En réponse au journal Recherche auteurice d'adoption. Évalué à 6.
Euh … salut. Ce commentaire ne parle ni d'orthographe, ni de féminisme. A-t-il sa place ici ? était-ce un journal piège ? Je n'ai pas vraiment perdu de vue mon projet de mémo (pour une liste des clones de Red Hat Entreprise Linux), c'est le temps qui a l'air monté sur patins à roulettes et m'échappe. En voulant faire ça bien, j'ai fait du sur-place. Pour être utile ce mémo doit rester globalement court, concis et informatif, avec une pifométrie rigoureuse pour évaluer les avantages présents et futurs, les communautés, l'engagement, le cuir du portefeuille et les intentions cachées.
Je pourrai m'y remettre, j'espère, avant l'été, quand les vagues viendront lêcher mes pieds le matin, un café chaud sur ma gauche, une étendue de sable lisse à ma droite pour prendre des notes.
[^] # Re: Distribution
Posté par orfenor . En réponse au lien HP Dev One (sous Pop!_OS) : HP jette l’éponge mais assurera un support. Évalué à 4.
Au delà du côté marketing évident — c'est nouveau, ça lave encore plus blanc que blanc — c'est peut-être aussi lié à la vitesse d'assemblage des portables, qui est supérieure à celle de production des composants. C'est le cas pour les disques durs : pour réparer les cartes contrôleuses (PCB), on doit chercher un disque identique, sorti de la même usine, de la même ligne d'assemblage, le même jour voire la même heure ; sans cela, on risque de tomber sur des composants différents, donc un firmware différent, donc une lecture impossible… et tout ce tintouin parce que les fournisseurs de composants ne peuvent pas suivre la cadence de production, ils sont donc plusieurs, ce qui provoque de multiples combinaisons d'assemblage sur les cartes contrôleuses.
[^] # Re: Paradoxale liberté d'expression
Posté par orfenor . En réponse au lien Technoféminisme - comment le numérique aggrave les inégalités : entretien avec Mathilde Saliou. Évalué à 3. Dernière modification le 26 février 2023 à 13:17.
Si je me souviens bien d'une interview de Noam Chomski, c'est un point de vue lié à la culture française. Alors qu'aux États-Unis la liberté d'expression est presque absolue, ne se discute pas. Noam Chomski y trouvait plus d'avantages que de défaut. Je ne sais pas s'il a discuté le problème que tu évoques, mais ce serait intéressant de confronter, sur ce sujet, les points de vue de chercheurs américains avec ceux des chercheurs français (les sociologues surtout).
[^] # Re: Impressionné je suis
Posté par orfenor . En réponse au lien Un NAS-Routeur sous TrueNAS et OpenWRT en financement participatif (complété). Évalué à 2.
La prochaine fois, fais un journal au lieu d'écrire 3 commentaires sous ton lien… Non ?
[^] # Re: Sentiment étrange quand je lis ce billet (et d'autres du même acabit)
Posté par orfenor . En réponse au lien Meta Verified : c’était gratuit et cela ne le sera plus jamais.. Évalué à 4.
Je pense que oui : vers la fin des années 90, les logiciels de marketing viral permettait d'animer des personnages fictifs dans les forums. Ces personnages étaient bien définis, avec chacun ses caractéristiques réalistes : langage, tics, sujets d'intérêt, amitiés, etc. Ça ne demandait pas beaucoup d'employés pour gérer des dizaines ou des centaines de personnages. Je ne vois pas pourquoi on n'en trouverait pas sur Facebook, et ça va même se développer.
[^] # Re: Il y a aussi Imgp et...
Posté par orfenor . En réponse au lien It’s the future — you can stop using JPEGs. Évalué à 2.
Sauf erreur de ma part, cet outil (très intéressant par ailleurs, merci de l'info!) ne propose pas plus qu'une compression JPEG de base ?
[^] # Re: JPEG XL
Posté par orfenor . En réponse au lien It’s the future — you can stop using JPEGs. Évalué à 4.
On ne parlait que du web dans cette discussion… Or, JPEG-XL n'est plus dans Chrome ni Chromium, Mozilla se déclare neutre sur le sujet (autrement dit ça va stagner) et Apple, 3ème poids lourd, n'a pas commencé. Et ce n'est que le dessus de l'iceberg ! Aucun navigateur mobile n'a commencé son intégration, or le web est majoritairement visité sur des mobiles. Voilà pourquoi je pense qu'aujourd'hui c'est mal barré pour JPEG-XL sur le web. Mais bien entendu ça peut changer.
Pour les intégrations voir https://caniuse.com/?search=jpegxl
[^] # Re: Bref ?
Posté par orfenor . En réponse au lien It’s the future — you can stop using JPEGs. Évalué à 2. Dernière modification le 19 février 2023 à 14:14.
Non, tu n'as pas compris. Faut lire la discussion et les critiques sous la PR et les bugs en rapport : il y a des trucs à revoir, du code à faire. Les changement dans Mozjpeg permettront seulement de l'inclure dans les distros Linux et donc d'en faire une dépendance de Gimp. Tout restera à faire concernant un plugin de Gimp. Et accessoirement, Mozjpeg n'est plus maintenu par Mozilla, mais par Kornelski.
[^] # Re: Bref ?
Posté par orfenor . En réponse au lien It’s the future — you can stop using JPEGs. Évalué à 3.
Mozjpeg utilisable dans Gimp c'est assez simple : il faut rendre Mozjpeg installable en parallèle de libjpeg (ou libjpegturbo). C'est un patch de Jehan qu'il faut revoir.
Mais pour avoir une interface graphique avec les options qui vont bien c'est autre chose. Jehan me l'a bien expliqué. Y'a du boulot et on voulait le payer pour ça. J'ai fait une interface en CLI qui masque la difficulté et nous permet (ma copine et moi) de l'utiliser en rafale sur un grand nombre d'images.
Effectivement ça vaudrait le coup de lancer un co-financement. Il suffit d'essayer Mozjpeg via ImageOptim online pour se rendre compte des bons résultats. Cela dit il y a des images pour lesquelles on ne fait pas aussi bien que WebP. L'image utilisée dans l'article en est un bon exemple.
[^] # Re: Bref ?
Posté par orfenor . En réponse au lien It’s the future — you can stop using JPEGs. Évalué à 2.
Trimage ne fait que du Lossless.
Si tu regardes le code source d'ImageOptim tu vas voir qu'il y a pas mal de boulot sur le glue code ;-)
[^] # Re: Bref ?
Posté par orfenor . En réponse au lien It’s the future — you can stop using JPEGs. Évalué à 2.
NB : Pour le web, on ne s'embête pas avec des valeurs précises de lumière et couleur , ça ne joue pas, aller de 5 en 5 est suffisant.
[^] # Re: JPEG XL
Posté par orfenor . En réponse au lien It’s the future — you can stop using JPEGs. Évalué à 3.
C'est mal barré pour JPEG-XL, qui ne sera peut-être jamais ajouté aux navigateurs (cf journaux récents).
[^] # Re: Bref ?
Posté par orfenor . En réponse au lien It’s the future — you can stop using JPEGs. Évalué à 3. Dernière modification le 18 février 2023 à 15:44.
Oui j'avais proposé à Jehan de le payer pour une interface à Mozjpeg. Mais on avait peu de moyens. De fil en aiguille il a proposé à Kornelski des modifications, pour intégrer Mozjpeg à Gimp, mais ça stagne.
Save for the web fait du bon boulot à partir de la libjpeg. Mais ne peut pas faire plus que ce que la lib propose. Tandis que Mozjpeg est basé libjpegturbo, qui dispose d'options avancées — et en ajoute qq autres bien sûr.
Pour utiliser Libjpegturbo/Mozjpeg je prépare une image de la plus haute qualité possible, parce que JPEG est mauvais sur la recompression. Ensuite je passe les paramètres à cjpeg (l'utilitaire de compression JPEG standard). J'utilise le cjpeg de Mozjpeg si je l'ai compilé, sinon celui de libjpegturbo.
Voilà les paramètres de libjpegturbo
et ceux rajoutés par Mozjpeg
Et voici comment faire
Le paramètre qui a le plus d'effet est dans libjpegturbo, c'est la compression différente pour la Luminance et la Chrominance. On va vulgariser un peu et les appeler lumière et couleur (c'est moins long à taper). Pour la lumière on met le paramètre de compression JPEG habituel, pour la couleur on met 1/4 ou 1/3 en général. Attention c'est lumière d'abord, couleur ensuite.
Pour jouer sur les qualités de lumière et de couleur il faut impérativement le paramètre
sample 1x1.Le lissage (paramètre
smooth) alourdit l'image et créé un peu de flou, auquel mon oeil est très sensible. L'utilisation des tables de quantisation permet de s'en passer avec Mozjpeg.Les tables de quantisation, c'est le deuxième paramètre qui a beaucoup d'effet. Pour le web, c'est le plus souvent la table 3 qui fait gagner le plus de poids, ensuite ce sont les tables 2 et 5. Les tables 7 et 8 permettent d'archiver avec une excellente qualité (je ne retrouve pas la discussion dans les bugs et PR de mozjpeg, mais c'est dedans) ; il m'arrive de m'en servir pour améliorer le rendu d'une image bien compressée, le poids supplémentaire est alors acceptable.
La CLI de base est donc
cjpeg -sample 1x1 -quality 65,21ça marche avec libjpegturbo (on peut ajouter -smooth [un nombre] pour corriger les artefacts de compression JPEG.
Et si on compile Mozjpeg, la CLI de base est
cjpeg -sample 1x1 -quality 65,21 -smooth 0 -quant-table 3… à laquelle je rajoute souvent
-dc-scan-opt 2Les autres paramètres servant (si j'ai bien compris) pour faire des comparaisons automatiques de qualité d'image.
[^] # Re: Bref ?
Posté par orfenor . En réponse au lien It’s the future — you can stop using JPEGs. Évalué à 4.
J'utilise tout le temps Mozjpeg. Avec des options "bien choisies", le poids des images descend au niveau d'une compression WebP. Kornelski, le mainteneur de Mozjpeg, a fait un utilitaire bien utile pour ceux qui ne veulent pas mettre la main dans le cambouis : ImageOptim qui existe en version online et en version Mac, livre directement l'image optimisée.
Avec un petit script Perl, on arrive à faire mieux qu'ImageOptim, en conservant la simplicité d'usage, mais au prix d'une appréciation "manuelle" de la qualité (avec l'habitude ça va vite).
Et à propos de la qualité, il faudrait que "les gens" remettent un peu les pieds sur terre : dans la plupart des pages web que je vois, on passe rapidement sur les images, rares sont celles qu'on regarde. De toute façon, les 3/4 des visiteurs sont sur mobile et consultent donc les pages dans de mauvaises conditions de lumière, et avec des reflets. Quant à ceux qui surfent sur grand écran, lequel a fait un calibrage ? Bref, rappelez vous les années modems, quand les images étaient petites et allégées au max. Une bonne pratique c'est d'alléger au max les premières images de la page, celles qui soutiennent le texte pour donner une vue d'ensemble. Et d'en mettre des belles, si besoin, un peu plus bas, pour ceux qui veulent des détail et s'intéressent au sujet. Ma copine le fait depuis 2 ans (elle vend des jouets), sa clientèle est ravie d'aller vite.
En faveur de JPEG, il ne faut pas oublier la relative rapidité de décompression sur nos CPUs.
# coquille sur un lien
Posté par orfenor . En réponse à la dépêche Entretien avec Stephane-D à propos du SGDK. Évalué à 2.
il manque une parenthèse fermante sur le lien
[planar](https://en.wikipedia.org/wiki/Planar_(computer_graphics)
# teasing teasing
Posté par orfenor . En réponse au lien "Story Killers", enquête de 100 journalistes révélant l’ampleur de l’industrie de la désinformation. Évalué à 2.
Pas encore sortie, c'est seulement l'annonce des publications à venir du consortium de journalistes (en France Radio-France et Le Monde)
[^] # Re: à tester
Posté par orfenor . En réponse à la dépêche DragonFlyBSD 6.2 et 6.4. Évalué à 4.
Je ne suis pas Matthew Dillon :-)
# les testeurs sont en liste d'attente
Posté par orfenor . En réponse au lien Demandez à Bing : "Qui est Sydney ?" (spoiler : ChatGPT ne sait pas garder les secrets). Évalué à 0.
Du coup je me suis inscrit sur la liste d'attente!
[^] # clustering et Single System Image
Posté par orfenor . En réponse à la dépêche DragonFlyBSD 6.2 et 6.4. Évalué à 4. Dernière modification le 12 février 2023 à 08:43.
La partie sur le clustering n'est plus aussi intéressante qu'il y a 10 ans, je doute que ce soit encore un objectif majeur d'HAMMER2. En effet, on croyait beaucoup aux grappes de machines qui apparaissaient comme une machine unique. Ce qu'on appelle du Single System Image (SSI) : on prend un cluster de machine hétérogène, on installe le soft magique, et hop, toutes les machines n'en font plus qu'une ; les ressources CPU, disques, mémoire sont partagées et gérées de façons globales. Par exemple on a beaucoup parlé de Kerrighed ici-même. Jean Parpaillon, qui fut membre de l'équipe, pourrait peut-être en parler.
Il me semble que les SSI sont plus ou moins abandonné parce que l'intéret s'est déplacé sur les machines virtuelles.
# un retour de loup solitaire
Posté par orfenor . En réponse au journal Changelog, pour quoi, pour quoi ?. Évalué à 4. Dernière modification le 05 février 2023 à 23:25.
Peut-être un peu comme Benoît ci-dessus.
[^] # Re: le petit bout de la lorgnette
Posté par orfenor . En réponse au journal si on ne fait rien, Xonotic va disparaitre de wikipedia FR. Évalué à 4.
Certes, mais je pense que ça n'a pas d'importance si la contribution est validée par le plussage de la communauté. C'est la pertinence de la contribution qu'il faut prendre en compte, c'est à dire que la personne ne raconte pas n'importe quoi.
C'est comparable à une interview de presse écrite. Bien que l'interviewé puisse raconter n'importe quoi sans grand contrôle. Hors, comme je l'ai mentionné plus haut (juste au-dessus et en dessous du propos de Thomas sur Linuxfr), ces interviews n'en demeurent pas moins une source référencée dans un bon nombre d'articles sur Wikipedia.
[^] # Re: le petit bout de la lorgnette
Posté par orfenor . En réponse au journal si on ne fait rien, Xonotic va disparaitre de wikipedia FR. Évalué à 7.
Euh… je ne parlais pas des dépêches ni des journaux, mais des commentaires :
pourquoi un commentaire authentifié, validé par le plussage, ne peut-il servir de source dès lors qu'il raconte un truc personnel ? alors qu'une interview parue dans la presse le peut (sauf erreur, je répète) ? Le problème est important lorsqu'on aborde des sujets contemporains pour lesquels il y a plus d'infos sur le web que dans la presse écrite, vu que la presse a beaucoup de mal a parler sans erreurs de sujets contemporains.
[^] # Re: le petit bout de la lorgnette
Posté par orfenor . En réponse au journal si on ne fait rien, Xonotic va disparaitre de wikipedia FR. Évalué à 2.
Pour éviter qu'on ne sabote un article sur un écrivain décédé, j'ai précisé dans la page de discussion que je restructurai beaucoup et que j'ajouterai les sources correctes à la fin. C'était efficace.
[^] # Re: le petit bout de la lorgnette
Posté par orfenor . En réponse au journal si on ne fait rien, Xonotic va disparaitre de wikipedia FR. Évalué à 7.
Absolument. Je remarque aussi que ce commentaire détaillant toute l'histoire, s'il était dans une interview de Thomas dans la presse papier, pourrait servir de source (y'en a plein comme ça dans Wikipedia), tandis que sur un site collaboratif comme linuxfr, non. Sauf erreur de ma part bien sûr.