For student and hobbyist developers
[…]
Je serais curieux de voir qui exactement sera concerné et le niveau de flexibilité que ça laissera.
Il faudra présenter une pièce d'identité et faire vérifier son numéro de téléphone. Il faudra autoriser Google à communiquer vos informations personnelles à des parties tierces. Le nombre d'installations autorisées sera limité. En contrepartie, on économisera les 25$ que coûtera une validation ordinaire.
Les gens qui s'occuppent du Digital Markets Act, qui vise notamment à interdire à Google d'agir comme "gatekeeper", ont mis en ligne un formulaire de contact:
Je ne pense pas (en tout cas je n'espère pas) que ce nouveau système interdise de fabriquer une app dans Android Studio et de l'installer sur ton téléphone.
Je cite l'annonce pour les développeurs :
For student and hobbyist developers […] we're working on a separate type of Android Developer Console account for you.
Je ne serais pas surpris si c'était justement le mécanisme prévu pour autoriser les gens à tester sur leur propre téléphone.
En théorie ça ne devrait pas être authorisé en Europe puisque Apple a été imposé d'ouvrir l'accès à des playstore alternatifs.
Ça n'empêche pas les dépôts alternatifs, ça empêche les utilisateurs d'installer les applications qui n'ont pas été signées par un membre du parti. Google obéit à la lettre des décisions de la Comission tout en violant complètement leur esprit.
Il sera peut-être possible d'attaquer cela en justice, mais ça prendra des années, et Google a le temps de trouver une nouvelle astuce d'ici là.
ça t'intéresserait que je te propose un pull request avec une documentation configurée avec Sphinx, thème comme Furo et éventuellement une configuration pour la publier sur ReadTheDocs ?
Je préfère rester avec du markdown aussi bête que possible, et éviter de dépendre encore davantage de sites commerciaux. (Seul le dépôt et le issue tracker sont sur GitHub, tout le reste est sur galene.org, et tout est prêt pour migrer depuis GitHub si ça devient nécessaire.)
Oui, ce serait bien, à ma connaissance il n'y a que Arch, FreeBSD et NixOS qui ont des paquets de Galène à jour.
Maintenant, c'est pas comme pour un logiciel en Python ou en node.js, c'est vraiment facile à installer manuellement :
git clone https://github.com/jech/galene
cd galene
CGO_ENABLED=0 go build -ldflags='-s -w' ./...
mkdir groups
./galenectl/galenectl initial-setup
mv config.json data/
./galene &
J'ai implémenté un composant XMPP qui l'utilise pour faire des visioconférence
Je sais, j'ai suivi.
adapter l'implémentation aux changements récents
Il faudrait qu'on se rencontre à l'occasion, pour que tu m'expliques exactement ce dont Libervia a besoin. Je n'aurais a priori pas d'objection à faire un protocole privé Galène <-> Libervia, et le garder (vaguement) stable.
On peut pour une fois faire un peu de pub pour les rares services pas encore merdifiés.
Non, car cela n'a rien d'exceptionnel: dans mon expérience, c'est le cas de la plupart des banques en briques et mortier, qui offrent les mêmes services dans l'application et au guichet, et la plupart des services sur l'interface web.
Une autre anecdote : toujours dans le même pays smartphonisé, j'ai voulu louer une voiture. Les amis m'ont conseillé un loueur, impossible de l'utiliser sans smartphone. J'ai décidé de payer quelques unités monétaires locales de plus pour un loueur traditionnel, on n'a même pas parlé de smartphone.
Les services privés ne sont pas encore un problème, il est presque toujours possible d'en choisir un qui a un guichet physique, quitte à payer quelques euros de plus. C'est dans le service public que la dématérialisation conduit à des situations scandaleuses.
La grosse différence c'est que la banque c'est une entreprise privée, tu peux en changer.
J'ai récemment ouvert un compte dans un pays européen où le smartphone est utilisé partout (on peut payer dans le bus en scannant un code QR). À mon premier rendez-vous, j'ai dit à la conseillère que je ne désirais pas utiliser d'application, elle à tout de suite compris. Et effectivement, tout fonctionne à travers l'interface web, même si c'est parfois un peu long de recopier les codes reçus par SMS.
Les banques ont un intérêt commercial à se montrer conciliantes avec tous les publics, tout au moins ceux qui ont de l'argent. Ce n'est pas forcément le cas des administrations sous-financées telles que France Travail.
Oui et non : si toutes les banques font pareil, on est coincé.
Tout-à-fait. Il faut rester vigilants, et notamment refuser catégoriquement de mettre les sous gagnés à la sueur de notre front dans des banques qui n'ont pas de guichet web.
Il y a plusieurs bonnes solutions, chacune a ses avantages et ses inconvénients :
transfert par câble USB (aucune installation, très haut débit, mais demande de connecter un câble) ;
transfert BlueTooth (aucune installation, limité au voisinage, petit débit) ;
LocalSend (application à installer, limité au réseau local) ;
transfert en SFTP, par exemple à l'aide de SimpleSSHD ou SshDaemon (application à installer, ne traverse pas les NAT, donc en pratique limité au réseau local) ;
syncthing-fork (peut-être un peu lourd à mettre en place pour un transfert occasionnel) ;
transfert pair-à-pair en WebRTC, par exemple à l'aide de WebWormhole our de la fonctionnalité équivalente intégrée à Galène (aucune installation, mais demande de pouvoir faire confiance au fournisseur de l'application web).
L'article passe un peu vite sur Clozure Common Lisp (aucun rapport avec Clojure).
CCL est un compilateur natif, un peu moins performant mais beaucoup plus léger que CMUCL et SBCL. Il a toutes les fonctionnalités d'une implémentation avancée de Common Lisp : bon support pour Unicode, threads natifs, sockets, accès natif aux appels système et aux bibliothèques écrites en C.
À la différence de SBCL, qui est dans toutes les distributions respectables, il faut l'installer soi-même, mais c'est facile.
Je me suis beaucoup investi dans Common Lisp au début du siècle, et je suis l'auteur de CL-Yacc, qui me semble encore utilisé. Ça a peut-être changé depuis, mais à l'époque, il n'était pas faisable d'écrire du logiciel libre en Common Lisp et de s'attendre à ce qu'il soit distribué.
Distribution difficile
J'avais écrit Cedilla, un formateur de texte avec support assez complet (pour l'époque) pour Unicode. J'ai trouvé que les distributions n'étaient absolument pas prêtes à accepter un utilitaire écrit en Common Lisp. J'ai fini par écrire mon propre installateur (en Common Lisp, bien sûr), ce qui limitait mon public aux gens qui étaient prêts à installer un compilateur et lancer un programme eux-mêmes.
Il n'existait à l'époque aucune implémentation libre de Common Lisp capabe de générer un binaire vaguement compact. Je ne sais pas si ça a changé.
Morcellement de l'écosystème
La dernière norme de Common Lisp remonte à 1994. Elle est excellente, mais elle ne dit rien à propos du support Unicode, de la concurrence, du parallélisme, de l'accès au réseau, des serveurs HTTP, ou des interfaces graphiques.
Du coup, chaque programme non-trivial dépend d'une implémentation spécifique, ce qui morcelle la communeauté. Je me suis laissé dire que la situation s'est améliorée depuis (grâce à ASDF et les bibliothèques de compatibilité), mais je ne sais ce qu'il en est vraiment.
Est-ce qu'un utilisateur ne doit créer qu'un seul compte pour avoir accès aux différentes applis
ça dépend de l'appli et de son intégration avec […] yunohost.
Je confirme.
D'un point de vue technique, Yunohost embarque un serveur LDAP. Si l'application est capable de s'authentifier à l'aide du serveur LDAP, alors un login commun est possible. Sinon, il faut s'authentifier avec les mécanismes spécifiques à l'application.
Pour ceux qui ne connaissent pas, Yunohost est une suite logicielle qui permet d'auto-héberger (self-host) des services sur son propre serveur sans forcément être un expert en administration système. Si vous voulez votre propre instance de NextCloud, votre propre serveur de musique Navidrome, ou votre propre serveur de vidéoconférence Galène, la solution la plus simple, c'est Yunohost.
En pratique, vous commencez par acheter un nom de domaine. Vous vous organisez ensuite un serveur pas cher (par exemple chez OVH ou Hetzner), ou alors vous connectez votre petit board (genre Raspberry Pi ou Olimex) à l'Internet, et vous installez Yunohost. Vous mettez à jour le DNS (dans l'interface web de votre fournisseur de domaine), vous créez des comptes sur votre serveur pour vos amis (dans l'interface web de Yunohost), puis vous installez les applications que vous voulez héberger (de nouveau dans l'interface web de Yunohost).
Si vous avez un problème, vous demandez de l'aide sur le forum Yunohost, et ce sont souvent les développeurs de Yunohost eux-mêmes qui vous aident.
QUESTION : quand j'utilise jitsi, vu que l'essentiel tourne dans mon navigateur, ça leur coûte quelque chose ?
Presque rien. Jitsi est en pair-à-pair (par défaut), et seul le traffic de signalisation passe par le serveur. C'est même le contraire, si les gens se servent de leur service, ils peuvent dire (honnêtement) qu'ils ont des utilisateurs lorsqu'ils demandent du financement.
Maintenant, même la vidéoconférence traditionnelle (client-serveur) ne coûte pas très cher. Je paie le serveur galene.org de ma poche, et ça me coûte l'équivalent d'une pinte par mois dans un bar parisien (hors happy hour).
[^] # Re: Europe
Posté par jch . En réponse à la dépêche Android n’autorisera plus que les applications des développeurs autorisés. Évalué à 1 (+0/-0).
Alors ? Tu as réussi à trouver ?
(Pour ceux qui ne le connaissent pas, Benjamin est une des rares personnes qui comprennent vaguement comment fonctionne la Commission.)
[^] # Re: Voir les précisions à venir
Posté par jch . En réponse à la dépêche Android n’autorisera plus que les applications des développeurs autorisés. Évalué à 4 (+3/-0).
Il faudra présenter une pièce d'identité et faire vérifier son numéro de téléphone. Il faudra autoriser Google à communiquer vos informations personnelles à des parties tierces. Le nombre d'installations autorisées sera limité. En contrepartie, on économisera les 25$ que coûtera une validation ordinaire.
Source : https://developer.android.com/developer-verification/guides/android-developer-console
# Contacter le "DMA team" à la Commission
Posté par jch . En réponse à la dépêche Android n’autorisera plus que les applications des développeurs autorisés. Évalué à 5 (+4/-0).
Les gens qui s'occuppent du Digital Markets Act, qui vise notamment à interdire à Google d'agir comme "gatekeeper", ont mis en ligne un formulaire de contact:
https://digital-markets-act.ec.europa.eu/contact-dma-team_en
Je leur ai envoyé un petit mot poli mais inquiet.
[^] # Re: chat control
Posté par jch . En réponse à la dépêche Android n’autorisera plus que les applications des développeurs autorisés. Évalué à 3 (+2/-0). Dernière modification le 27 août 2025 à 15:06.
C'est un moyen d'empêcher d'utiliser des services Google sans les pubs, par exemple à l'aide de PipePipe. Mais l'un n'empêche pas l'autre.
[^] # Re: Développeur et build local
Posté par jch . En réponse à la dépêche Android n’autorisera plus que les applications des développeurs autorisés. Évalué à 2 (+1/-0).
Je cite l'annonce pour les développeurs :
Je ne serais pas surpris si c'était justement le mécanisme prévu pour autoriser les gens à tester sur leur propre téléphone.
[^] # Re: Europe
Posté par jch . En réponse à la dépêche Android n’autorisera plus que les applications des développeurs autorisés. Évalué à 6 (+5/-0).
Ça n'empêche pas les dépôts alternatifs, ça empêche les utilisateurs d'installer les applications qui n'ont pas été signées par un membre du parti. Google obéit à la lettre des décisions de la Comission tout en violant complètement leur esprit.
Il sera peut-être possible d'attaquer cela en justice, mais ça prendra des années, et Google a le temps de trouver une nouvelle astuce d'ici là.
# Article Arstechnica
Posté par jch . En réponse à la dépêche Android n’autorisera plus que les applications des développeurs autorisés. Évalué à 4 (+3/-0).
Arstechnica a aussi fait un article à ce sujet :
Un modérateur pourrait-il l'ajouter à la dépêche ?
[^] # Re: Documentation
Posté par jch . En réponse au journal Galenectl, l'outil d'administration de Galène. Évalué à 3 (+2/-0).
Je préfère rester avec du markdown aussi bête que possible, et éviter de dépendre encore davantage de sites commerciaux. (Seul le dépôt et le issue tracker sont sur GitHub, tout le reste est sur galene.org, et tout est prêt pour migrer depuis GitHub si ça devient nécessaire.)
[^] # Re: Merci
Posté par jch . En réponse au journal Galenectl, l'outil d'administration de Galène. Évalué à 2 (+1/-0).
https://galene.org/galene-install.html#run-galene-on-the-server
[^] # Re: Merci
Posté par jch . En réponse au journal Galenectl, l'outil d'administration de Galène. Évalué à 4 (+3/-0).
Avec plaisir. Fais-moi un mail quand tu es prêt.
[^] # Re: Merci
Posté par jch . En réponse au journal Galenectl, l'outil d'administration de Galène. Évalué à 2 (+1/-0).
Oui, ce serait bien, à ma connaissance il n'y a que Arch, FreeBSD et NixOS qui ont des paquets de Galène à jour.
Maintenant, c'est pas comme pour un logiciel en Python ou en node.js, c'est vraiment facile à installer manuellement :
git clone https://github.com/jech/galene
cd galene
CGO_ENABLED=0 go build -ldflags='-s -w' ./...
mkdir groups
./galenectl/galenectl initial-setup
mv config.json data/
./galene &
[^] # Re: Merci
Posté par jch . En réponse au journal Galenectl, l'outil d'administration de Galène. Évalué à 2 (+1/-0).
Merci pour les compliments :-)
Je sais, j'ai suivi.
Il faudrait qu'on se rencontre à l'occasion, pour que tu m'expliques exactement ce dont Libervia a besoin. Je n'aurais a priori pas d'objection à faire un protocole privé Galène <-> Libervia, et le garder (vaguement) stable.
[^] # Re: sans ios, sans android/aosp?
Posté par jch . En réponse au journal L'Identité Digitale Numérique Européenne et attestation Google. Évalué à 1 (+0/-0).
Non, car cela n'a rien d'exceptionnel: dans mon expérience, c'est le cas de la plupart des banques en briques et mortier, qui offrent les mêmes services dans l'application et au guichet, et la plupart des services sur l'interface web.
Une autre anecdote : toujours dans le même pays smartphonisé, j'ai voulu louer une voiture. Les amis m'ont conseillé un loueur, impossible de l'utiliser sans smartphone. J'ai décidé de payer quelques unités monétaires locales de plus pour un loueur traditionnel, on n'a même pas parlé de smartphone.
Les services privés ne sont pas encore un problème, il est presque toujours possible d'en choisir un qui a un guichet physique, quitte à payer quelques euros de plus. C'est dans le service public que la dématérialisation conduit à des situations scandaleuses.
[^] # Re: sans ios, sans android/aosp?
Posté par jch . En réponse au journal L'Identité Digitale Numérique Européenne et attestation Google. Évalué à 3 (+2/-0). Dernière modification le 02 août 2025 à 18:05.
J'ai récemment ouvert un compte dans un pays européen où le smartphone est utilisé partout (on peut payer dans le bus en scannant un code QR). À mon premier rendez-vous, j'ai dit à la conseillère que je ne désirais pas utiliser d'application, elle à tout de suite compris. Et effectivement, tout fonctionne à travers l'interface web, même si c'est parfois un peu long de recopier les codes reçus par SMS.
Les banques ont un intérêt commercial à se montrer conciliantes avec tous les publics, tout au moins ceux qui ont de l'argent. Ce n'est pas forcément le cas des administrations sous-financées telles que France Travail.
Tout-à-fait. Il faut rester vigilants, et notamment refuser catégoriquement de mettre les sous gagnés à la sueur de notre front dans des banques qui n'ont pas de guichet web.
[^] # Re: Outil de vérification d'âge
Posté par jch . En réponse au journal L'Identité Digitale Numérique Européenne et attestation Google. Évalué à 10 (+16/-1).
Pour le moment.
# Plusieurs solutions
Posté par jch . En réponse au journal LocalSend une application pour envoyer vos photos de smartphone sur votre GNU/Linux. Évalué à 6 (+5/-0). Dernière modification le 28 juillet 2025 à 14:49.
Il y a plusieurs bonnes solutions, chacune a ses avantages et ses inconvénients :
# CCL
Posté par jch . En réponse à la dépêche Common Lisp ces deux dernières années: un monstre de l'évolution parmi nous. Évalué à 4 (+3/-0).
L'article passe un peu vite sur Clozure Common Lisp (aucun rapport avec Clojure).
CCL est un compilateur natif, un peu moins performant mais beaucoup plus léger que CMUCL et SBCL. Il a toutes les fonctionnalités d'une implémentation avancée de Common Lisp : bon support pour Unicode, threads natifs, sockets, accès natif aux appels système et aux bibliothèques écrites en C.
À la différence de SBCL, qui est dans toutes les distributions respectables, il faut l'installer soi-même, mais c'est facile.
# Difficile à utiliser en pratique
Posté par jch . En réponse à la dépêche Common Lisp ces deux dernières années: un monstre de l'évolution parmi nous. Évalué à 2 (+1/-0).
Je me suis beaucoup investi dans Common Lisp au début du siècle, et je suis l'auteur de CL-Yacc, qui me semble encore utilisé. Ça a peut-être changé depuis, mais à l'époque, il n'était pas faisable d'écrire du logiciel libre en Common Lisp et de s'attendre à ce qu'il soit distribué.
Distribution difficile
J'avais écrit Cedilla, un formateur de texte avec support assez complet (pour l'époque) pour Unicode. J'ai trouvé que les distributions n'étaient absolument pas prêtes à accepter un utilitaire écrit en Common Lisp. J'ai fini par écrire mon propre installateur (en Common Lisp, bien sûr), ce qui limitait mon public aux gens qui étaient prêts à installer un compilateur et lancer un programme eux-mêmes.
Il n'existait à l'époque aucune implémentation libre de Common Lisp capabe de générer un binaire vaguement compact. Je ne sais pas si ça a changé.
Morcellement de l'écosystème
La dernière norme de Common Lisp remonte à 1994. Elle est excellente, mais elle ne dit rien à propos du support Unicode, de la concurrence, du parallélisme, de l'accès au réseau, des serveurs HTTP, ou des interfaces graphiques.
Du coup, chaque programme non-trivial dépend d'une implémentation spécifique, ce qui morcelle la communeauté. Je me suis laissé dire que la situation s'est améliorée depuis (grâce à ASDF et les bibliothèques de compatibilité), mais je ne sais ce qu'il en est vraiment.
[^] # Re: experience perso avec SIP sans TLS/ZRTP
Posté par jch . En réponse au journal Galene-sip: une passerelle entre Galène et SIP. Évalué à 3 (+2/-0).
Tu aurais des détails ?
[^] # Re: experience perso avec SIP sans TLS/ZRTP
Posté par jch . En réponse au journal Galene-sip: une passerelle entre Galène et SIP. Évalué à 1 (+0/-0).
Pourquoi ?
[^] # Re: précision
Posté par jch . En réponse au journal Galene-sip: une passerelle entre Galène et SIP. Évalué à 2 (+1/-0).
Moi qui étais si fier d'avoir pensé à mettre une minuscule à « juin »… merci pour l'éducation.
# Désolé pour le formatage
Posté par jch . En réponse au journal Galene-sip: une passerelle entre Galène et SIP. Évalué à 4 (+3/-0).
Mes excuses pour le formatage — j'ai rédige ce journal dans Emacs, et j'ai apparemment utilisé le mauvais dialecte de Markdown.
[^] # Re: Qu'est-ce que Yunohost
Posté par jch . En réponse à la dépêche Campagne de dons : Yunohost a besoin de vous !. Évalué à 2.
Je confirme.
D'un point de vue technique, Yunohost embarque un serveur LDAP. Si l'application est capable de s'authentifier à l'aide du serveur LDAP, alors un login commun est possible. Sinon, il faut s'authentifier avec les mécanismes spécifiques à l'application.
# Qu'est-ce que Yunohost
Posté par jch . En réponse à la dépêche Campagne de dons : Yunohost a besoin de vous !. Évalué à 10.
Pour ceux qui ne connaissent pas, Yunohost est une suite logicielle qui permet d'auto-héberger (self-host) des services sur son propre serveur sans forcément être un expert en administration système. Si vous voulez votre propre instance de NextCloud, votre propre serveur de musique Navidrome, ou votre propre serveur de vidéoconférence Galène, la solution la plus simple, c'est Yunohost.
En pratique, vous commencez par acheter un nom de domaine. Vous vous organisez ensuite un serveur pas cher (par exemple chez OVH ou Hetzner), ou alors vous connectez votre petit board (genre Raspberry Pi ou Olimex) à l'Internet, et vous installez Yunohost. Vous mettez à jour le DNS (dans l'interface web de votre fournisseur de domaine), vous créez des comptes sur votre serveur pour vos amis (dans l'interface web de Yunohost), puis vous installez les applications que vous voulez héberger (de nouveau dans l'interface web de Yunohost).
Si vous avez un problème, vous demandez de l'aide sur le forum Yunohost, et ce sont souvent les développeurs de Yunohost eux-mêmes qui vous aident.
[^] # Coût de la vidéoconférence
Posté par jch . En réponse au message groupe privé de conversation (genre jitsi, whatsapp, etc.). Évalué à 5.
Presque rien. Jitsi est en pair-à-pair (par défaut), et seul le traffic de signalisation passe par le serveur. C'est même le contraire, si les gens se servent de leur service, ils peuvent dire (honnêtement) qu'ils ont des utilisateurs lorsqu'ils demandent du financement.
Maintenant, même la vidéoconférence traditionnelle (client-serveur) ne coûte pas très cher. Je paie le serveur galene.org de ma poche, et ça me coûte l'équivalent d'une pinte par mois dans un bar parisien (hors happy hour).