tu fais comment pour chercher des exemples représentatifs pour se mettre le pied à l'étrier ?
Je ne suis pas spécialiste, j'espère que quelqu'un de compétent me corrigera.
Le bon cas, c'est tous les algos trivialement parallélisables, sans divergence, et sans trop de pression sur la mémoire. Le hachage parallèle (hashcat), l'évaluation Monte Carlo, ou, pour faire une jolie démo, l'ensemble de Mandelbrot. (C'est assez impressionnant, Mandelbrot sur un GPU, même sur un iGPU de base, c'est instantané.)
Le moyen cas, c'est quand ça reste parallélisable sans divergence, mais c'est les temps de transfert qui dominent. C'est tout ce qui est convolutions, produits scalaires (donc réseaux de neurones), produits de matrices, etc. Ça inclut les filtres d'images et de vidéo, dont il y a plein d'exemples dans les sources de mpv. La difficulté, c'est les accès à la mémoire, l'architecture de la mémoire dans les GPU est complètement expicite, à la différence des CPU il faut gérer le cache manuellement. Et pour ce genre d'algorithmes, il faut un GPU discret, ça ne marche pas du tout sur les iGPU.
Le cas amusant, c'est quand intuivivement il y a des dépendances, mais des gens plus intelligents que moi arrivent quand-même à paralléliser. Il y a des gens qui font des tris sur GPU, l'algorithme du scan, etc. J'essaie de lire les articles à ce sujet, mais pour le moment ça me dépasse.
Ah, j'avais oublié le offload d'OpenMP (j'avais appris OpenMP à l'époque de la version 2, et je ne me suis toujours pas habitué à l'idée que ça marche aussi pour les GPU). Je n'ai pas réussi à trouver d'étude qui explique quels sont les cas dans lesquels ça marche bien, mais ça vaut probablement la peine d'essayer.
pour le codeur Vulkan compute c’est plus compliqué
Peut-être faudrait-il que j'essaie encore, mais pour moi, c'est inutilisable. L'API est encore plus complexe que celle d'OpenCL, sans bonne raison, et le langage de shading n'est pas adapté pour le calcul.
Alors qu’avec whisper.cpp en Vulkan
Oui, les gens de whisper.cpp ont fait du bon boulot, leur implémentation Vulkan a des performances comparables à leur version Cuda. Mais au prix de combien d'années d'efforts!
Supposez que j'écris un programme de traitement d'audio en C, et il s'avère qu'il est un petit peu trop lent. Je décide d'accélérer la boucle interne en AVX2, ça améliore un peu les performances, mais clairement c'est une application pour le GPU.
Pour NVidia, c'est facile, dix lignes de boilerplate CUDA qui copie le clip audio vers la mémoire « globale » (la VRAM), je recompile ma boucle interne pour le GPU, et j'ai fini.
Comment je fais pour que ça marche aussi sur AMD ? Points en plus si ça inclut les iGPU Intel (les derniers modèles sont carrément compétitifs, au moins en puissance de calcul).
J'ai récemment ouvert un compte en banque dans un pays européen fortement smartphonisé.
Suède? Pays bas? c'est deux pays qui sont dirigés par des smartphones, qui ont vendu leur âme aux applis?
Non, c'est la Pologne. J'aime assez ce qui se passe là-bas, tout est smartphonisé, mais avec les alternatives low-tech qui restent disponibles. Par exemple, la plupart des gens payent leur trajet de bus en scannant un QR code affiché en face de l'entrée, et, en même temps, il y a des distributeurs de tickets en carton ("bilet kartonikowy", tiens, maintenant vous comprenez le Polonais) à chaque arrêt. (Par contre, depuis deux ans environ il n'est plus possible d'acheter des tickets dans les kiosques à journaux.)
J'ai récemment ouvert un compte en banque dans un pays européen fortement smartphonisé.
Lors de mon premier rendez-vous avec la conseillère, j'ai poliment indiqué que je n'allais pas utiliser d'application sur mon smartphone, et que si l'application était nécessaire, je lui serais reconnaissant de me conseiller une banque concurrente où ce ne serait pas le cas. La dame était curieuse, mais elle m'a assuré que je pourrais accéder à toutes les fonctionnalités à travers le site web. Ce qui est normal, nous sommes des millions à ne pas vouloir dépendre autant de notre smartphone, il serait bizarre que les banques se privent de toute cette clientèle.
Ce que je te suggère, c'est de les rappeler dans quelques semaines, et leur indiquer poliment mais clairement que si toutes les fonctionnalités n'étaient plus accessibles sans smartphones, tu devrais, à ton grand regret, fermet ton compte. Si tu dois fermer ton compte, indique clairement (mais toujours poliment) la raison.
Ce serait bien que tu puisses faire la même chose dans ton autre banque, mais je sais que c'est parfois compliqué de changer de compte.
JPEG-XL pour le coup, ça a visiblement été conçu avec plus de soin
Tu pourrais donner un exemple concret de fonctionnalité qui est hackée dans AVIF mais faite proprement dans JPEG-XL?
Je n'y connais rien en formats d'image, j'ai plus d'expérience avec les formats vidéo. J'ai entendu ce genre d'affirmations à propos de VP9 (qui serait « hacké ») vis-à-vis de H.264 (qui serait plus professionnel), mais mon opinion personnelle est que H.264 inclut des fonctionnalités qui n'ont rien à faire à cette couche là (fragmentation, agrégation) et qui ne sont utiles que lorsque le transport est déficient, alors que VP9 est un format plus parsimonieux, qui délègue aux autres couches les fonctionnalités que celles-ci font déjà bien. D'où mon scepticisme.
En regardant la page Wikipedia, les fonctionnalités qui attirent mon attention sont les espaces de couleurs HDR et la compression efficace des images synthétiques (screenshots). Ce qui est certes utile, mais déjà supporté par AVIF.
Est-ce qu'un spécialiste pourrait nous expliquer ce que JPEG-XL apporte par rapport aux formats déjà supportés ?
Posté par jch .
En réponse au journal Logitech, domotique et libre.
Évalué à 4.
Dernière modification le 12 octobre 2025 à 23:34.
à un certain moment on doit faire confiance à ce que le serveur nous envoie
Entièrement d'accord (avec tous les deux). Si vous utilisez galene.org, vous me faites confiance (ainsi qu'à mon fournisseur de service) pour ne pas vous espionner. Je n'ai aucune envie de vous espionner, mais si jamais je reçois un ordre d'un juge, je n'irai pas en prison pour vous protéger.
De ce fait, j'encourage les gens à installer leur propre instance de Galène sur un serveur qu'ils contrôlent (éventuellement à travers https://yunohost.org), c'est ce qui donne les meilleures garanties de vie privée, et en même temps je maintiens de manière bénévole le service public sur galene.org pour ceux qui n'ont pas les moyens techniques ou tout simplement pas l'envie de maintenir leur propre serveur. Ce n'est peut-être pas idéal, mais c'est sans doute mieux que Zoom ou Google.
avec du logiciel libre quelqu'un quelque part trouvera certainement le moyen de faire tourner un serveur et le partagera avec la communauté (le moyen, pas le serveur)
Pourquoi pas le serveur ?
Depuis plus de trois ans, je mets le serveur de vidéoconférence https://galene.org:8443 à disposition du public. Ça me coûte 6€ par mois environ. Il n'y a aucun business model derrière, le seul but est d'aider les gens à éviter le spyware de Zoom.
Ce n'est pas un cas isolé. Le service https://beacondb.net est fourni gratuitement, sans aucun business model derrière. Et maintenant que j'y pense, c'est aussi le cas de https://linuxfr.org.
Les serveurs sont vraiment bon marché en ce moment, et ils risquent de devenir moins chers encore lorsque OpenAI aura déposé le bilan et vendu ses datacenters au rabais. Il n'y a aucune raison de se priver de la joie de fournir des services gratuits au public.
Ou est-ce qu'il n'y a pas de concurrents sérieux à Qualcomm ?
À l'époque dont datent mes informations, Qualcomm détenait un monopole absolu sur les modems LTE, et ils étaient essentiellement les seuls à pouvoir fournir du WiFi en quantité. Je ne sais pas si ça a changé depuis, peut-être qu'un spécialiste de l'électronique pourrait s'exprimer ?
Tu fais comment pour assurer le support du matériel alors qu'il s'appuie sur de nombreux blobs ?
Tu n'as pas le choix, tu mets les blobs dans ton noyau, et tu écris un shim, une couche qui adapte l'API du blob à ton noyau.
Google eux-mêmes ont ce problème : ils dépendent du matériel Qualcomm pour leurs Pixel, et non seulement ce matériel dépend de blobs, mais une fois le matériel vendu, Qualcomm refuse de mettre les blobs à jour. Un des buts du projet Fuchsia, c'était de faire un noyau où les modules pourraient avoir des permissions réduites, afin de sandboxer les drivers Qualcomm, à qui personne ne fait confiance. Ça n'a pas marché, probablement parce qu'après réflexion ils n'y ont trouvé aucun intérêt commercial.
je dispose d'un compte dans une banque en ligne avec 2FA obligatoire pour effectuer un achat en ligne
Il faut que tu changes de banque. N'oublie pas d'informer ton conseiller pourquoi tu fais ça.
Pareil, je ne suis pas sûr de pouvoir utiliser l'identité numérique de La Poste avec un téléphone rooté…
J'ai un vieux téléphone sous Android stock dans un tiroir, qui ne sert qu'à utiliser l'Identité Numérique de la Poste. (Demande à tes amis, la plupart des gens ont un tiroir plein de téléphones obsolètes.)
Ça dépend, si "la tâche" c'est juste assurer la maintenance du truc et corriger quelques bugs, il y a pas besoin d'une très grosse équipe.
Android est absolument gigantesque, et le code est de qualité variable: il y a des parties qui sont bien faites, d'autres qui ont été écrites par un stagiaire qui apprenait sur le tas, et enfin d'autres qui sont du « overengineered object-oriented crap », pour citer une source anonyme mais bien informée.
Du coup, la surface d'attaque est absolument énorme, et il faut une armée de gens qui bouchent les trous au fur et à mesure qu'ils sont découverts. On aimerait que les gens de GrapheneOS coordonnent un tel projet, mais comme ils ont tendance à entrer en conflit avec tous les autres projets de distributions Android alternatives, il n'y a pas beaucoup d'espoir.
Il me semble plus réaliste de commencer par un Linux pour smartphones minimal, qui ferait juste téléphone de base et navigateur web, et qui exécuterait les applications Android dans un container (genre Waydroid) ou carrément dans une machine virtuelle, isolée du reste du système. Le problème, c'est le support matériel, Les difficultés de PostmarketOS montrent combien ce n'est pas facile de supporter toutes les fonctionnalités d'un smartphone du commerce.
Ce qui m'a fait penser à ça, c'est l'histoire des cafards américains qu'on avait massivement nourris au glucose empoisonné. Ce qui a selectionné des cafards qui n'aiment plus le sucré.
Si j'ai bien compris, la pulvérisation, on est contre, afin d'éviter l'évolution d'individus résistants. On préfète les répulseurs. Pourquoi n'a-t-on pas peur de sélectionner des moustiques qui ignorent les répulseurs ?
[^] # Re: Comment ça se programme ?
Posté par jch . En réponse à la dépêche AMD mise tout sur RADV. Évalué à 2 (+1/-0).
Je ne suis pas spécialiste, j'espère que quelqu'un de compétent me corrigera.
Le bon cas, c'est tous les algos trivialement parallélisables, sans divergence, et sans trop de pression sur la mémoire. Le hachage parallèle (hashcat), l'évaluation Monte Carlo, ou, pour faire une jolie démo, l'ensemble de Mandelbrot. (C'est assez impressionnant, Mandelbrot sur un GPU, même sur un iGPU de base, c'est instantané.)
Le moyen cas, c'est quand ça reste parallélisable sans divergence, mais c'est les temps de transfert qui dominent. C'est tout ce qui est convolutions, produits scalaires (donc réseaux de neurones), produits de matrices, etc. Ça inclut les filtres d'images et de vidéo, dont il y a plein d'exemples dans les sources de mpv. La difficulté, c'est les accès à la mémoire, l'architecture de la mémoire dans les GPU est complètement expicite, à la différence des CPU il faut gérer le cache manuellement. Et pour ce genre d'algorithmes, il faut un GPU discret, ça ne marche pas du tout sur les iGPU.
Le cas amusant, c'est quand intuivivement il y a des dépendances, mais des gens plus intelligents que moi arrivent quand-même à paralléliser. Il y a des gens qui font des tris sur GPU, l'algorithme du scan, etc. J'essaie de lire les articles à ce sujet, mais pour le moment ça me dépasse.
[^] # Re: Comment ça se programme ?
Posté par jch . En réponse à la dépêche AMD mise tout sur RADV. Évalué à 1 (+0/-0).
Ah, j'avais oublié le offload d'OpenMP (j'avais appris OpenMP à l'époque de la version 2, et je ne me suis toujours pas habitué à l'idée que ça marche aussi pour les GPU). Je n'ai pas réussi à trouver d'étude qui explique quels sont les cas dans lesquels ça marche bien, mais ça vaut probablement la peine d'essayer.
Peut-être faudrait-il que j'essaie encore, mais pour moi, c'est inutilisable. L'API est encore plus complexe que celle d'OpenCL, sans bonne raison, et le langage de shading n'est pas adapté pour le calcul.
Oui, les gens de whisper.cpp ont fait du bon boulot, leur implémentation Vulkan a des performances comparables à leur version Cuda. Mais au prix de combien d'années d'efforts!
# Comment ça se programme ?
Posté par jch . En réponse à la dépêche AMD mise tout sur RADV. Évalué à 5 (+4/-0).
Comment ça se programme ?
Supposez que j'écris un programme de traitement d'audio en C, et il s'avère qu'il est un petit peu trop lent. Je décide d'accélérer la boucle interne en AVX2, ça améliore un peu les performances, mais clairement c'est une application pour le GPU.
Pour NVidia, c'est facile, dix lignes de boilerplate CUDA qui copie le clip audio vers la mémoire « globale » (la VRAM), je recompile ma boucle interne pour le GPU, et j'ai fini.
Comment je fais pour que ça marche aussi sur AMD ? Points en plus si ça inclut les iGPU Intel (les derniers modèles sont carrément compétitifs, au moins en puissance de calcul).
[^] # Re: Quelle taille fait votre petit doigt?
Posté par jch . En réponse au sondage Votre disposition de clavier. Évalué à 2 (+1/-0). Dernière modification le 27 février 2026 à 23:52.
Pour atteindre la touche entrée sans taper un µ.
Merci, maintenant je comprends pourquoi il est nécessaire d'avoir un µ placé à un endroit aussi central.
# Quelle taille fait votre petit doigt?
Posté par jch . En réponse au sondage Votre disposition de clavier. Évalué à 1 (+0/-0). Dernière modification le 25 février 2026 à 22:15.
Deux questions pour les gens en AZERTY:
[^] # Re: compte Google
Posté par jch . En réponse au journal Boursorama semble dorénavant imposer l'usage d'un smartphone pour utiliser ses services. Évalué à 1 (+0/-0).
https://en.wikipedia.org/wiki/Peter_principle
[^] # Re: Ferme ton compte !
Posté par jch . En réponse au journal Boursorama semble dorénavant imposer l'usage d'un smartphone pour utiliser ses services. Évalué à 7 (+6/-0).
Non, c'est la Pologne. J'aime assez ce qui se passe là-bas, tout est smartphonisé, mais avec les alternatives low-tech qui restent disponibles. Par exemple, la plupart des gens payent leur trajet de bus en scannant un QR code affiché en face de l'entrée, et, en même temps, il y a des distributeurs de tickets en carton ("bilet kartonikowy", tiens, maintenant vous comprenez le Polonais) à chaque arrêt. (Par contre, depuis deux ans environ il n'est plus possible d'acheter des tickets dans les kiosques à journaux.)
# Ferme ton compte !
Posté par jch . En réponse au journal Boursorama semble dorénavant imposer l'usage d'un smartphone pour utiliser ses services. Évalué à 9 (+8/-0).
J'ai récemment ouvert un compte en banque dans un pays européen fortement smartphonisé.
Lors de mon premier rendez-vous avec la conseillère, j'ai poliment indiqué que je n'allais pas utiliser d'application sur mon smartphone, et que si l'application était nécessaire, je lui serais reconnaissant de me conseiller une banque concurrente où ce ne serait pas le cas. La dame était curieuse, mais elle m'a assuré que je pourrais accéder à toutes les fonctionnalités à travers le site web. Ce qui est normal, nous sommes des millions à ne pas vouloir dépendre autant de notre smartphone, il serait bizarre que les banques se privent de toute cette clientèle.
Ce que je te suggère, c'est de les rappeler dans quelques semaines, et leur indiquer poliment mais clairement que si toutes les fonctionnalités n'étaient plus accessibles sans smartphones, tu devrais, à ton grand regret, fermet ton compte. Si tu dois fermer ton compte, indique clairement (mais toujours poliment) la raison.
Ce serait bien que tu puisses faire la même chose dans ton autre banque, mais je sais que c'est parfois compliqué de changer de compte.
[^] # Re: Fonctionnalités intéressantes ?
Posté par jch . En réponse au journal JPEG-XL est finalement intégré dans Chromium (et donc Google Chrome). Évalué à 4 (+3/-0).
Tu pourrais donner un exemple concret de fonctionnalité qui est hackée dans AVIF mais faite proprement dans JPEG-XL?
Je n'y connais rien en formats d'image, j'ai plus d'expérience avec les formats vidéo. J'ai entendu ce genre d'affirmations à propos de VP9 (qui serait « hacké ») vis-à-vis de H.264 (qui serait plus professionnel), mais mon opinion personnelle est que H.264 inclut des fonctionnalités qui n'ont rien à faire à cette couche là (fragmentation, agrégation) et qui ne sont utiles que lorsque le transport est déficient, alors que VP9 est un format plus parsimonieux, qui délègue aux autres couches les fonctionnalités que celles-ci font déjà bien. D'où mon scepticisme.
# Fonctionnalités intéressantes ?
Posté par jch . En réponse au journal JPEG-XL est finalement intégré dans Chromium (et donc Google Chrome). Évalué à 4 (+3/-0).
En regardant la page Wikipedia, les fonctionnalités qui attirent mon attention sont les espaces de couleurs HDR et la compression efficace des images synthétiques (screenshots). Ce qui est certes utile, mais déjà supporté par AVIF.
Est-ce qu'un spécialiste pourrait nous expliquer ce que JPEG-XL apporte par rapport aux formats déjà supportés ?
[^] # Re: On pousse en interne pour utiliser de l'opensource
Posté par jch . En réponse au journal L'Europe collecte les retours d'expérience pour créer la future stratégie en matière d'Open Source. Évalué à 2 (+1/-0).
Vous utilisez quoi pour la vidéconférence?
Pourquoi Zoom?
[^] # Re: Quel bureau d'enregistrement choisir ?
Posté par jch . En réponse au journal Tuto "Transférer un nom de domaine d'un Bureau d'Enregistrement à un autre" de Bortzmeyer. Évalué à 3.
Stéphane (l'auteur du blog lié ci-dessus) est en train de passer à Netim. Quant à moi, j'hésite encore entre Netim et OVH. Les deux sont français.
[^] # Re: Pourquoi pas le serveur?
Posté par jch . En réponse au journal Logitech, domotique et libre. Évalué à 4. Dernière modification le 12 octobre 2025 à 23:34.
Entièrement d'accord (avec tous les deux). Si vous utilisez galene.org, vous me faites confiance (ainsi qu'à mon fournisseur de service) pour ne pas vous espionner. Je n'ai aucune envie de vous espionner, mais si jamais je reçois un ordre d'un juge, je n'irai pas en prison pour vous protéger.
De ce fait, j'encourage les gens à installer leur propre instance de Galène sur un serveur qu'ils contrôlent (éventuellement à travers https://yunohost.org), c'est ce qui donne les meilleures garanties de vie privée, et en même temps je maintiens de manière bénévole le service public sur galene.org pour ceux qui n'ont pas les moyens techniques ou tout simplement pas l'envie de maintenir leur propre serveur. Ce n'est peut-être pas idéal, mais c'est sans doute mieux que Zoom ou Google.
# Pourquoi pas le serveur?
Posté par jch . En réponse au journal Logitech, domotique et libre. Évalué à 10.
Pourquoi pas le serveur ?
Depuis plus de trois ans, je mets le serveur de vidéoconférence https://galene.org:8443 à disposition du public. Ça me coûte 6€ par mois environ. Il n'y a aucun business model derrière, le seul but est d'aider les gens à éviter le spyware de Zoom.
Ce n'est pas un cas isolé. Le service https://beacondb.net est fourni gratuitement, sans aucun business model derrière. Et maintenant que j'y pense, c'est aussi le cas de https://linuxfr.org.
Les serveurs sont vraiment bon marché en ce moment, et ils risquent de devenir moins chers encore lorsque OpenAI aura déposé le bilan et vendu ses datacenters au rabais. Il n'y a aucune raison de se priver de la joie de fournir des services gratuits au public.
[^] # Re: Et si on boycottait Google?
Posté par jch . En réponse à la dépêche Android n’autorisera plus que les applications des développeurs autorisés. Évalué à 1.
C'est tout-à-fait possible, je ne m'y connais pas plus que ça, je rapporte juste ce que des gens bien informés m'ont racontė.
[^] # Re: Et si on boycottait Google?
Posté par jch . En réponse à la dépêche Android n’autorisera plus que les applications des développeurs autorisés. Évalué à 1.
À l'époque dont datent mes informations, Qualcomm détenait un monopole absolu sur les modems LTE, et ils étaient essentiellement les seuls à pouvoir fournir du WiFi en quantité. Je ne sais pas si ça a changé depuis, peut-être qu'un spécialiste de l'électronique pourrait s'exprimer ?
[^] # Re: Et si on boycottait Google?
Posté par jch . En réponse à la dépêche Android n’autorisera plus que les applications des développeurs autorisés. Évalué à 1.
Tu n'as pas le choix, tu mets les blobs dans ton noyau, et tu écris un shim, une couche qui adapte l'API du blob à ton noyau.
Google eux-mêmes ont ce problème : ils dépendent du matériel Qualcomm pour leurs Pixel, et non seulement ce matériel dépend de blobs, mais une fois le matériel vendu, Qualcomm refuse de mettre les blobs à jour. Un des buts du projet Fuchsia, c'était de faire un noyau où les modules pourraient avoir des permissions réduites, afin de sandboxer les drivers Qualcomm, à qui personne ne fait confiance. Ça n'a pas marché, probablement parce qu'après réflexion ils n'y ont trouvé aucun intérêt commercial.
[^] # Re: Privation de libertés et fin de la communauté "hacking"
Posté par jch . En réponse à la dépêche Android n’autorisera plus que les applications des développeurs autorisés. Évalué à 3.
Il faut que tu changes de banque. N'oublie pas d'informer ton conseiller pourquoi tu fais ça.
J'ai un vieux téléphone sous Android stock dans un tiroir, qui ne sert qu'à utiliser l'Identité Numérique de la Poste. (Demande à tes amis, la plupart des gens ont un tiroir plein de téléphones obsolètes.)
[^] # Re: Et si on boycottait Google?
Posté par jch . En réponse à la dépêche Android n’autorisera plus que les applications des développeurs autorisés. Évalué à 1.
Android est absolument gigantesque, et le code est de qualité variable: il y a des parties qui sont bien faites, d'autres qui ont été écrites par un stagiaire qui apprenait sur le tas, et enfin d'autres qui sont du « overengineered object-oriented crap », pour citer une source anonyme mais bien informée.
Du coup, la surface d'attaque est absolument énorme, et il faut une armée de gens qui bouchent les trous au fur et à mesure qu'ils sont découverts. On aimerait que les gens de GrapheneOS coordonnent un tel projet, mais comme ils ont tendance à entrer en conflit avec tous les autres projets de distributions Android alternatives, il n'y a pas beaucoup d'espoir.
Il me semble plus réaliste de commencer par un Linux pour smartphones minimal, qui ferait juste téléphone de base et navigateur web, et qui exécuterait les applications Android dans un container (genre Waydroid) ou carrément dans une machine virtuelle, isolée du reste du système. Le problème, c'est le support matériel, Les difficultés de PostmarketOS montrent combien ce n'est pas facile de supporter toutes les fonctionnalités d'un smartphone du commerce.
[^] # Re: Pourquoi pas d'immunité aux répulseurs ?
Posté par jch . En réponse au journal Ce que j'ai fait pendant vos vacances. Évalué à 2.
Ce qui m'a fait penser à ça, c'est l'histoire des cafards américains qu'on avait massivement nourris au glucose empoisonné. Ce qui a selectionné des cafards qui n'aiment plus le sucré.
https://www.sciencesetavenir.fr/nature-environnement/l-aversion-des-cafards-au-sucre-un-exemple-d-evolution-rapide_10303
# Exposés ?
Posté par jch . En réponse à la dépêche Lancement de l'EDRIX : un indice pour mesurer la souveraineté numérique européenne. Évalué à 1.
Stephane, est-ce que tu as pensé à faire un exposé à l'IRILL à ce sujet ?
# Pourquoi pas d'immunité aux répulseurs ?
Posté par jch . En réponse au journal Ce que j'ai fait pendant vos vacances. Évalué à 7.
Si j'ai bien compris, la pulvérisation, on est contre, afin d'éviter l'évolution d'individus résistants. On préfète les répulseurs. Pourquoi n'a-t-on pas peur de sélectionner des moustiques qui ignorent les répulseurs ?
[^] # Re: Les derniers mètres sont les plus durs
Posté par jch . En réponse à la dépêche Typst, un système de composition de document qui grandit. Évalué à 2.
Et bien sûr TeX versus RUNOFF.
[^] # Re: Raisonnement différent
Posté par jch . En réponse au journal Contribution à la consultation sur la première révision du Digital Markets Act. Évalué à 8.
L'un n'empêche pas l'autre. Il y a deux combats qu'on mène en ce moment :
Il n'y a aucune raison de croire que ces deux combats sont contradictoires.
[^] # Re: Mon expérience
Posté par jch . En réponse à la dépêche Typst, un système de composition de document qui grandit. Évalué à 3.
Je me trompe peut-être, mais je crois bien que c'est juste un parseur et un évaluateur d'expressions, pas un moteur de mise en page.
N'hésite pas, ça nous change un peu de la propagande Rust.