Je vais être un peu théâtral (tu me pardonneras ?). C'est pas une niche, c'est un impératif moral.
C'est le problème d'entrer du texte différement qu'avec un clavier AZERTY, par exemple en utilisant un dictionnaire de caractères chinois, un clavier virtuel sur un écran tactile. Idéalement, n'importe quelle méthode d'entrée marcherait avec n'importe quel compositeur et avec n'importe quel toolkit d'interface utilisateur.
Là où ça devient un impératif moral (tu m'as pardonné ?), c'est quand il s'agit de rendre implémentables les méthodes d'entrée adaptées aux invalides.
vue la quantité de contenu sur l'IA/les LLM permet moi d'en douter
C'est pas parce qu'on s'y intéresse qu'on n'est pas méfiants. Au contraire, ce sont généralement ceux qui n'ont pas regardé ça de près qui sont les plus technobéats.
On adore pas les outils créés complètement par une IA
c'est qui le "on" ? qui est-ce que tu inclus dedans ?
Je crois que c'est la position d'une bonne partie des gens qui commentent sur LinuxFR (on n'a pas d'informations sur la position des gens qui suivent sans commenter). Personnellement, je suis assez d'accord avec cette position, j'ai appris à me méfier du code généré par LLM. Sans même parler de l'enjeu écologique.
Je pense donc qu'impromptux a tout-à-fait raison de demander à kwisatz de nous indiquer comment il a utilisé le LLM, et quelle partie de la conception est due à un être humain compétent. (L'impression que j'ai, à la vue du code, c'est que le code est entièrement généré par un LLM haut de gamme, donc écologiquement désastreux, guidé par un être humain compétent.)
je me rends compte que [Wayland] est ultra fragmenté
C'était bien pire pour X11. Il y avait la distribution libre de X11R5, qui ne supportait que core X pour la 2D, PHIGS pour la 3D, XKB pour configurer le clavier. Il y avait XFree86, qui supportait OpenGL (GLX) pour la 3D. Il y avait le serveur X de Sun, qui utilisait Display Postscript pour faire de la 2D décente. Le serveur X de SGI avait la meilleure implémentation de OpenGL, naturellement, je ne sais pas s'ils supportaient aussi Display PostScript ou PHIGS. Et puis il y avait les divers serveurs X pour Windows, qui généralement étaient très limités.
Et c'est sans parler des différences entre MWM qui supportait tout un protocole privé pour définir l'apparence des fenêtres, OLWM qui en supportait un complètement différent, et twm qui ne supportait presque rien (impossible de désactiver la barre de titre; j'aimais bien twm). Et si vous me lancez sur les problèmes du copier-coller entre applications, on n'a pas fini.
Tout ça s'est réglé quand X11 a perdu contre Windows, et les Unix propriétaires ont abandonné leurs serveurs X propriétaires. Ils se sont rabattus sur X.Org, un fork de XFree86 (XRENDER pour la 2D, OpenGL pour la 3D, XKB pour la configuration du clavier). Ensuite, Gnome (je crois) ont publié sur freedesktop.org leur protocole de communication avec les window managers, et tout le monde l'a implémenté, de manière plus ou moins compétente.
(Source : j'y étais. Je suis l'auteur de la spec qui fait que vous pouvez copier-coller des caractères Unicode sans peur.)
Il y a un outil en ligne de commande qui expose l'API REST au shell:
$ galenectl create-group -group 'linuxfr'
$ galenectl create-user -group linuxfr -user lebouquetin
$ galenectl set-password -group linuxfr -user lebouquetin
New password:
d'accepter des participants sans compte (exemple : je fais une conf avec des collègues qui ont un compte + un client qui n'a pas de compte)
Oui, bien sûr. Va sur public/lebouquetin, connecte-toi, clique sur ton propre nom dans la liste en haut à gauche, et fais Invite User. Si tu as besoin de scripter ça, le mécanisme est exposé à travers l'API REST et aussi à travers l'outil en ligne de commande :
$ echo "https://galene.org:8443/group/public/lebouquetin/?token=$(galenectl create-token -group public/lebouquetin)"
https://galene.org:8443/group/public/lebouquetin/?token=tQyuuomDAFM
Tu peux bien sûr déléguer le droit d'inviter des gens, en créant un token qui permet de créer de nouveaux tokens :
$ galenectl create-token -group public/lebouquetin -permissions '["token"]'
Posté par jch .
En réponse au journal Galène 1.1.
Évalué à 10 (+10/-0).
Avant de parler du SDK, la grande force de Livekit est je pense la possibilité de le faire fonctionner en SAAS.
Un des buts de Galène est d'encourager le déploiement local (self-hosting), tu n'es donc pas le public visé. Après tout, Galène n'est pas adaptée à tous les déploiements, et LiveKit est un excellent produit.
(Mais pour être entièrement franc, j'ai du mal à comprendre pourquoi, dans un univers où un VPS européen se loue à 6€ par mois, les gens choissent de se lier à un fournisseur de cloud qui peut changer sa politique commerciale à tout moment. Si tu as envie de nous expliquer, ça m'intéresse.)
Suite à notre conversation entourée de bières belges au Fosdem, il semblerait que la partie réseau (forwarding de ports) est vraiment problématique.
Oui, en ce moment Galène a tendance à utiliser des ports aléatoires. J'ai commencé à travailler à résoudre ça (regarde l'option -udp-mux), mais il reste du travail.
Mais bon, c'est un seul binaire à déployer, je recommande donc de le déployer en natif.
Posté par jch .
En réponse au journal Galène 1.1.
Évalué à 10 (+9/-0).
As-tu un comparatif LiveKit / Galène ?
LiveKit et Galène se ressemblent beaucoup, même s'ils n'ont pas de code en commun. LiveKit est basé sur ion-sfu, un SFU libre qui utilise la même bibliothèque WebRTC (Pion) que Galène. Du coup, LiveKit profite du travail que j'ai fait pour rendre Pion plus économe en ressources, et Galène inclut tous les bug fixes que les gens de LiveKit apportent régulièrement à Pion.
La grosse différence, c'est que LiveKit est un projet commercial open core, dont le business model avoué est de vendre du support, de vendre des déploiements cloud, et de pousser les gens vers la version propriétaire. Du coup, la version libre de LiveKit ne sera jamais facile à administrer (car cela nuirait au support payant et au déploiement cloud), et n'aura jamais les fonctionnalités qui sont spécifiques à la version propriétaire. Galène, a contrario, est un projet individuel, et mon but est de fournir un serveur de vidéconférence complet, suffisamment robuste et simple à administrer pour que les utilisateurs n'aient pas besoin de me demander du support.
Là où les gens de LiveKit ont fait du bon boulot, c'est sur les SDK : le SDK JavaScript est de très haut niveau, et suffisamment simple à utiliser pour qu'un programmeur web, même médiocre, puisse écrire un frontend sans rien comprendre à la vidéoconférence. Le SDK de Galène est beaucoup plus primitif, il laisse beaucoup plus de travail à l'application. (Le client web minimal pour Galène fait 314 lignes de JavaScript.) LiveKit fournit aussi des SDK pour d'autres environnements que le web, notamment Android et iOS. (Dans le cas de Galène, je fournis la bibliothèque JavaScript et une bibliothèque client en Go. J'avais aussi un client Android à un moment, mais je l'ai abandonné, et je n'ai pas séparé la partie Galène pour en faire un SDK.)
En ce qui concerne le serveur, LiveKit a beaucoup, beaucoup de fonctionnalités, dont certaines dont je ne comprends pas le but (j'imagine que, étant un produit commercial, ils ont des contraintes que je n'ai pas). Naturellement, leur serveur est beaucoup plus complexe que celui de Galène : Galène contient 18000 lignes de code, alors que LiveKit en contient 130000.
Mais la concurrence n'est pas vraiment entre Galène et LiveKit, elle est entre les systèmes libres, respectueux de la vie privée, et les systèmes propriétaires qui espionnent leurs utilisateurs. La mission de la DINUM est de fournir un système qui évite à l'administration française de faire transiter ses secrets par les serveurs de Zoom, et si LiveKit leur permet d'atteindre ce but, tant mieux.
Suppose que j'ai un numéro de téléphone mobile chez play.pl. Si je change de fournisseur d'Internet mobile, je perds mon numéro. C'est de la vente liée.
Non, en France, on a le RIO, aka la procédure de portabilité.
La procédure de portabilité me permet de transférer mon numéro vers un autre fournisseur de téléphonie. Elle ne me permet pas de garder mon compte de téléphonie (et donc mon numéro) si je résilie mon contrat Internet. C'est un chouette workaround, mais ça ne résoud pas le problème fondamental (la vente liée de l'accès à l'Internet et de la téléphonie).
Je crois que c'est basé sur un accord imposé par l'ARCEP français.
D'après moi, c'est la Directive 2018/1972 du Parlement européen, mais j'avoue que c'est un peu vague.
Si je prends un abonnement 4G chez Free, je ne peux pas acheter mes minutes de voix chez Orange. C'est pour cela que je paie tous les mois pour une SIM polonaise dont je ne me sers quasiment jamais : j'ai besoin d'un numéro polonais, donc on me force à prendre une connexion Internet en Pologne.
Je n'ai pas très bien compris ce passage.. Encore moins vers où il veut en venir.
Suppose que j'ai mon mail chez laposte.fr (mauvaise idée, je sais, mais supposons). Si je change de fournisseur d'Internet, je garde mon mail.
Suppose que j'ai un numéro de téléphone mobile chez play.pl. Si je change de fournisseur d'Internet mobile, je perds mon numéro. C'est de la vente liée.
Ne serait-ce pas aux explorateurs de fichiers de s’adapter pour générer une vignette d’un fichier XCF à la volée (en prenant en charge ces nouveaux calques) ?
Juste pour que ce soit cassé à la prochaine mise à jour du format ?
La solution suggérée par Maderios me semble plus robuste : le fichier XCF contient un thumbnail généré par Gimp lui-même lors de chaque sauvegarde, et les gestionnaires de fichier ont besoin de savoir analyser la structure générale d'un XCF de manière grossière, juste suffisante pour trouver le thumbnail. Le code est écrit une fois, et plus la peine de mettre à jour tous les gestionnaires de fichiers à chaque fois que le format XCF acquiert une nouvelle fonctionnalité.
JPEG (JFIF) fait ça depuis toujours, je ne comprends pas pourquoi XCF ne le fait pas.
Je ne possède pas de Kindle, j'ai lu qu'on peux décharger d'un Kindle les "ebooks" en format ePub via l'USB.
Le firmware du Kindle ne supporte pas le format EPub, et avant de charger un livre dans le Kindle, il faut le convertir en un format supporté, comme AZW ou AZW3. J'utilise pour cela l'utilitaire ebook-convert fourni avec Calibre, ça marche fort bien (sauf pour les mathématiques).
Il est tout-à-fait possible de télécharger les livres depuis le Kindle vers le PC, mais naturellement ils sont dans le format AZW ou AZW3, pas en EPub. Je n'utilise le Kindle qu'avec des EPub que j'ai moi-même convertis, sans passer par les services d'Amazon, je n'ai donc pas d'expérience avec les DRM. J'imagine que les fichiers protégés sont chiffrés, mais je n'ai pas essayé.
Unicode simplifie énormément les choses. Avoir une seule table de caractères pour toutes les langues au monde évite de prendre en compte l'état du système quand on traite le texte. Certes, il faut gérer la sémantique d'Unicode, mais c'est beaucoup plus simple que ça se fasse sans état, et c'est normalement géré par des bibliothèques externes.
(Ce qui se faisait avant, c'est des sous-ensembles plus ou moins ad hoc de ISO 2022. J'en sais quelque chose, j'ai été obligé d'implémenter ISO 2022 lorsqu'on travaillait à la transition de Linux à Unicode.)
Même si j'aurais attendu une « simple » option dans l'espace en ligne, tel que le fait Free
J'en profite pour mentionner que Free aussi propose une offre moins chère sans télé (mais incluant le téléphone fixe), la Freebox Pop S, mais elle ne vous sera pas proposée si vous appelez — elle existe uniquement si vous commandez sur leur site web.
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).
[^] # Re: X11 aussi était fragmenté
Posté par jch . En réponse au journal wlr-utils : je voulais juste un sélecteur de fenêtres, je me suis retrouvé avec une suite de capture pour wlroots. Évalué à 2 (+1/-0).
Je vais être un peu théâtral (tu me pardonneras ?). C'est pas une niche, c'est un impératif moral.
C'est le problème d'entrer du texte différement qu'avec un clavier AZERTY, par exemple en utilisant un dictionnaire de caractères chinois, un clavier virtuel sur un écran tactile. Idéalement, n'importe quelle méthode d'entrée marcherait avec n'importe quel compositeur et avec n'importe quel toolkit d'interface utilisateur.
Là où ça devient un impératif moral (tu m'as pardonné ?), c'est quand il s'agit de rendre implémentables les méthodes d'entrée adaptées aux invalides.
[^] # Re: Cela devient lassant…
Posté par jch . En réponse au journal wlr-utils : je voulais juste un sélecteur de fenêtres, je me suis retrouvé avec une suite de capture pour wlroots. Évalué à 6 (+5/-0).
C'est pas parce qu'on s'y intéresse qu'on n'est pas méfiants. Au contraire, ce sont généralement ceux qui n'ont pas regardé ça de près qui sont les plus technobéats.
[^] # Re: Cela devient lassant…
Posté par jch . En réponse au journal wlr-utils : je voulais juste un sélecteur de fenêtres, je me suis retrouvé avec une suite de capture pour wlroots. Évalué à 8 (+7/-0).
Je crois que c'est la position d'une bonne partie des gens qui commentent sur LinuxFR (on n'a pas d'informations sur la position des gens qui suivent sans commenter). Personnellement, je suis assez d'accord avec cette position, j'ai appris à me méfier du code généré par LLM. Sans même parler de l'enjeu écologique.
Je pense donc qu'impromptux a tout-à-fait raison de demander à kwisatz de nous indiquer comment il a utilisé le LLM, et quelle partie de la conception est due à un être humain compétent. (L'impression que j'ai, à la vue du code, c'est que le code est entièrement généré par un LLM haut de gamme, donc écologiquement désastreux, guidé par un être humain compétent.)
[^] # Re: Cela devient lassant…
Posté par jch . En réponse au journal wlr-utils : je voulais juste un sélecteur de fenêtres, je me suis retrouvé avec une suite de capture pour wlroots. Évalué à 3 (+2/-0).
Après avoir jeté un coup d'œil rapide au source, je confirme que le code est en grande partie produit par un ou plusieurs LLM.
[^] # Re: X11 aussi était fragmenté
Posté par jch . En réponse au journal wlr-utils : je voulais juste un sélecteur de fenêtres, je me suis retrouvé avec une suite de capture pour wlroots. Évalué à 5 (+4/-0).
Effectivement, j'ai été trop lapidaire. La spec qui fait que vous pouvez copier-coller sans peur que vos accents se transforment en Hanzi.
[^] # X11 aussi était fragmenté
Posté par jch . En réponse au journal wlr-utils : je voulais juste un sélecteur de fenêtres, je me suis retrouvé avec une suite de capture pour wlroots. Évalué à 10 (+18/-0). Dernière modification le 26 juin 2026 à 13:46.
C'était bien pire pour X11. Il y avait la distribution libre de X11R5, qui ne supportait que core X pour la 2D, PHIGS pour la 3D, XKB pour configurer le clavier. Il y avait XFree86, qui supportait OpenGL (GLX) pour la 3D. Il y avait le serveur X de Sun, qui utilisait Display Postscript pour faire de la 2D décente. Le serveur X de SGI avait la meilleure implémentation de OpenGL, naturellement, je ne sais pas s'ils supportaient aussi Display PostScript ou PHIGS. Et puis il y avait les divers serveurs X pour Windows, qui généralement étaient très limités.
Et c'est sans parler des différences entre MWM qui supportait tout un protocole privé pour définir l'apparence des fenêtres, OLWM qui en supportait un complètement différent, et twm qui ne supportait presque rien (impossible de désactiver la barre de titre; j'aimais bien twm). Et si vous me lancez sur les problèmes du copier-coller entre applications, on n'a pas fini.
Tout ça s'est réglé quand X11 a perdu contre Windows, et les Unix propriétaires ont abandonné leurs serveurs X propriétaires. Ils se sont rabattus sur X.Org, un fork de XFree86 (XRENDER pour la 2D, OpenGL pour la 3D, XKB pour la configuration du clavier). Ensuite, Gnome (je crois) ont publié sur freedesktop.org leur protocole de communication avec les window managers, et tout le monde l'a implémenté, de manière plus ou moins compétente.
(Source : j'y étais. Je suis l'auteur de la spec qui fait que vous pouvez copier-coller des caractères Unicode sans peur.)
[^] # Re: Galène en remplacement de Jitsi ?
Posté par jch . En réponse au journal Galène 1.1. Évalué à 8 (+7/-0).
Oui, on peut déléguer à un serveur tiers. Il y a deux exemples de serveurs sur lesquels vous pouvez vous baser :
Oui, il y a deux mécanismes pour cela :
public/sur galene.org ;Il y a un outil en ligne de commande qui expose l'API REST au shell:
$ galenectl create-group -group 'linuxfr'
$ galenectl create-user -group linuxfr -user lebouquetin
$ galenectl set-password -group linuxfr -user lebouquetin
New password:
Oui, bien sûr. Va sur public/lebouquetin, connecte-toi, clique sur ton propre nom dans la liste en haut à gauche, et fais Invite User. Si tu as besoin de scripter ça, le mécanisme est exposé à travers l'API REST et aussi à travers l'outil en ligne de commande :
$ echo "https://galene.org:8443/group/public/lebouquetin/?token=$(galenectl create-token -group public/lebouquetin)"
https://galene.org:8443/group/public/lebouquetin/?token=tQyuuomDAFM
Tu peux bien sûr déléguer le droit d'inviter des gens, en créant un token qui permet de créer de nouveaux tokens :
$ galenectl create-token -group public/lebouquetin -permissions '["token"]'
[^] # LiveKit et déploiement cloud
Posté par jch . En réponse au journal Galène 1.1. Évalué à 10 (+10/-0).
Un des buts de Galène est d'encourager le déploiement local (self-hosting), tu n'es donc pas le public visé. Après tout, Galène n'est pas adaptée à tous les déploiements, et LiveKit est un excellent produit.
(Mais pour être entièrement franc, j'ai du mal à comprendre pourquoi, dans un univers où un VPS européen se loue à 6€ par mois, les gens choissent de se lier à un fournisseur de cloud qui peut changer sa politique commerciale à tout moment. Si tu as envie de nous expliquer, ça m'intéresse.)
[^] # Re: Docker?
Posté par jch . En réponse au journal Galène 1.1. Évalué à 3 (+2/-0).
Valent Turković y travaille. https://github.com/jech/galene/issues/312
Oui, en ce moment Galène a tendance à utiliser des ports aléatoires. J'ai commencé à travailler à résoudre ça (regarde l'option
-udp-mux), mais il reste du travail.Mais bon, c'est un seul binaire à déployer, je recommande donc de le déployer en natif.
[^] # Re: LiveKit
Posté par jch . En réponse au journal Galène 1.1. Évalué à 10 (+9/-0).
LiveKit et Galène se ressemblent beaucoup, même s'ils n'ont pas de code en commun. LiveKit est basé sur ion-sfu, un SFU libre qui utilise la même bibliothèque WebRTC (Pion) que Galène. Du coup, LiveKit profite du travail que j'ai fait pour rendre Pion plus économe en ressources, et Galène inclut tous les bug fixes que les gens de LiveKit apportent régulièrement à Pion.
La grosse différence, c'est que LiveKit est un projet commercial open core, dont le business model avoué est de vendre du support, de vendre des déploiements cloud, et de pousser les gens vers la version propriétaire. Du coup, la version libre de LiveKit ne sera jamais facile à administrer (car cela nuirait au support payant et au déploiement cloud), et n'aura jamais les fonctionnalités qui sont spécifiques à la version propriétaire. Galène, a contrario, est un projet individuel, et mon but est de fournir un serveur de vidéconférence complet, suffisamment robuste et simple à administrer pour que les utilisateurs n'aient pas besoin de me demander du support.
Là où les gens de LiveKit ont fait du bon boulot, c'est sur les SDK : le SDK JavaScript est de très haut niveau, et suffisamment simple à utiliser pour qu'un programmeur web, même médiocre, puisse écrire un frontend sans rien comprendre à la vidéoconférence. Le SDK de Galène est beaucoup plus primitif, il laisse beaucoup plus de travail à l'application. (Le client web minimal pour Galène fait 314 lignes de JavaScript.) LiveKit fournit aussi des SDK pour d'autres environnements que le web, notamment Android et iOS. (Dans le cas de Galène, je fournis la bibliothèque JavaScript et une bibliothèque client en Go. J'avais aussi un client Android à un moment, mais je l'ai abandonné, et je n'ai pas séparé la partie Galène pour en faire un SDK.)
En ce qui concerne le serveur, LiveKit a beaucoup, beaucoup de fonctionnalités, dont certaines dont je ne comprends pas le but (j'imagine que, étant un produit commercial, ils ont des contraintes que je n'ai pas). Naturellement, leur serveur est beaucoup plus complexe que celui de Galène : Galène contient 18000 lignes de code, alors que LiveKit en contient 130000.
Mais la concurrence n'est pas vraiment entre Galène et LiveKit, elle est entre les systèmes libres, respectueux de la vie privée, et les systèmes propriétaires qui espionnent leurs utilisateurs. La mission de la DINUM est de fournir un système qui évite à l'administration française de faire transiter ses secrets par les serveurs de Zoom, et si LiveKit leur permet d'atteindre ce but, tant mieux.
# Yunohost
Posté par jch . En réponse au journal Galène 1.1. Évalué à 9 (+8/-0).
Elle est déjà arrivée. Merci Éric !
# Syndrome de Stockholm?
Posté par jch . En réponse au journal Pourquoi le modèle de concurrence de Node.js est bien. Évalué à 1 (+5/-5).
https://fr.wikipedia.org/wiki/Syndrome_de_Stockholm
[^] # Re: réponse
Posté par jch . En réponse au journal Le protocole SIP et la bibliothèque jart/gosip. Évalué à 2 (+1/-0).
La procédure de portabilité me permet de transférer mon numéro vers un autre fournisseur de téléphonie. Elle ne me permet pas de garder mon compte de téléphonie (et donc mon numéro) si je résilie mon contrat Internet. C'est un chouette workaround, mais ça ne résoud pas le problème fondamental (la vente liée de l'accès à l'Internet et de la téléphonie).
D'après moi, c'est la Directive 2018/1972 du Parlement européen, mais j'avoue que c'est un peu vague.
[^] # Re: réponse
Posté par jch . En réponse au journal Le protocole SIP et la bibliothèque jart/gosip. Évalué à 2 (+1/-0).
Suppose que j'ai mon mail chez laposte.fr (mauvaise idée, je sais, mais supposons). Si je change de fournisseur d'Internet, je garde mon mail.
Suppose que j'ai un numéro de téléphone mobile chez play.pl. Si je change de fournisseur d'Internet mobile, je perds mon numéro. C'est de la vente liée.
[^] # Re: GIMP 3.2.2 est déjà là!
Posté par jch . En réponse à la dépêche GIMP 3.2.0 est sorti. Évalué à 4.
Juste pour que ce soit cassé à la prochaine mise à jour du format ?
La solution suggérée par Maderios me semble plus robuste : le fichier XCF contient un thumbnail généré par Gimp lui-même lors de chaque sauvegarde, et les gestionnaires de fichier ont besoin de savoir analyser la structure générale d'un XCF de manière grossière, juste suffisante pour trouver le thumbnail. Le code est écrit une fois, et plus la peine de mettre à jour tous les gestionnaires de fichiers à chaque fois que le format XCF acquiert une nouvelle fonctionnalité.
JPEG (JFIF) fait ça depuis toujours, je ne comprends pas pourquoi XCF ne le fait pas.
[^] # Re: GIMP 3.2.2 est déjà là!
Posté par jch . En réponse à la dépêche GIMP 3.2.0 est sorti. Évalué à 3.
Merci, j'ai appris des choses de ton code. J'ai encore quelques questions :
[Thumbnailer Entry]?[^] # Re: Libérez-les!
Posté par jch . En réponse à la dépêche 8 liseuses Kindle seront débranchées par AMAZON en mai 2026 - Quelles alternatives FOSS?. Évalué à 3.
Le firmware du Kindle ne supporte pas le format EPub, et avant de charger un livre dans le Kindle, il faut le convertir en un format supporté, comme AZW ou AZW3. J'utilise pour cela l'utilitaire
ebook-convertfourni avec Calibre, ça marche fort bien (sauf pour les mathématiques).Il est tout-à-fait possible de télécharger les livres depuis le Kindle vers le PC, mais naturellement ils sont dans le format AZW ou AZW3, pas en EPub. Je n'utilise le Kindle qu'avec des EPub que j'ai moi-même convertis, sans passer par les services d'Amazon, je n'ai donc pas d'expérience avec les DRM. J'imagine que les fichiers protégés sont chiffrés, mais je n'ai pas essayé.
[^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
Posté par jch . En réponse au journal NextCloud et le format ODF : des gros nuages orageux. Évalué à 5.
Unicode simplifie énormément les choses. Avoir une seule table de caractères pour toutes les langues au monde évite de prendre en compte l'état du système quand on traite le texte. Certes, il faut gérer la sémantique d'Unicode, mais c'est beaucoup plus simple que ça se fasse sans état, et c'est normalement géré par des bibliothèques externes.
(Ce qui se faisait avant, c'est des sous-ensembles plus ou moins ad hoc de ISO 2022. J'en sais quelque chose, j'ai été obligé d'implémenter ISO 2022 lorsqu'on travaillait à la transition de Linux à Unicode.)
[^] # Re: Du coup, ce n'est pas si facile ;)
Posté par jch . En réponse au journal Sortir du CGNAT chez Red by SFR, c'est facile. Évalué à 4.
J'en profite pour mentionner que Free aussi propose une offre moins chère sans télé (mais incluant le téléphone fixe), la Freebox Pop S, mais elle ne vous sera pas proposée si vous appelez — elle existe uniquement si vous commandez sur leur site web.
[^] # Re: Comment ça se programme ?
Posté par jch . En réponse à la dépêche AMD mise tout sur RADV. Évalué à 3.
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é à 2.
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.
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. 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é à 2. 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.
https://en.wikipedia.org/wiki/Peter_principle