Triste de voir ce genre de chose se passer sur un des piliers historiques du logiciel libre (entre autres choses)
Après quel que soit les protocoles et logiciels de votre choix, c'est une fois de plus un événement qui montre l'importance de la décentralisation (et malgré cela, on voit encore, y compris chez les libristes et autres publics qui se voudraient avertis, les mêmes erreurs se répéter).
j'avoue (honteusement) que le XMPP est un protocole dont je ne sais presque rien
Oui ben c'est normal, honnêtement se farcir les protocole c'est pas la chose la plus excitante du monde dans le développement.
Le rôle des bibliothèques c'est justement de rendre ça plus facile d'accès sans avoir à trop s’inquiéter des détails internes. Si t'as besoin d'aide, tu peux me contacter ou aller sur un salon dédié. Avec JavaScript, je vois par exemple que ça a l'air assez facile d'utiliser Pubsub via stanzaJS.
En gros dans ton cas, l'avantage c'est que tu peux utiliser un serveur XMPP existant (https://jabberfr.org/ par exemple) et implémenter la synchro via Pubsub par dessus, et tu as ainsi une implémentation prête à l'emploi pour les notifications, permissions, et abonnements (et dans quelques mois le chiffrement de bout en bout), ça ne devrait pas être si compliqué à greffer sur une archi existante, même centralisée.
Enfin bref, c'est juste une suggestion tu en fais ce que t'en veux. C'est surtout que j'aimerais bien voir une compatibilité entre les différentes options libres :)
Pour info, j'ai aussi travaillé sur une liste de courses avec Libervia, basée sur XMPP. Elle est donc décentralisée avec un système de permissions (dans la capture ci-dessous il suffit de cliquer sur manage invitations et de choisir les personnes à inviter).
Ton projet est bien avancé mais vu que tu n'as pas encore fait le système de permission/synchronisation, peut être que tu peux envisager d'utiliser XMPP pour ça (avec une des bibliothèques disponibles ça devrait être relativement facile) ? Ça serait chouette que ça soit compatible, et ça t'éviterait d'avoir à réinventer la roue.
Depuis quelque temps, il y a Poetry qui a le vent en poupe, il gère tout ce qu'il faut pour le packaging, la publication, et l'exécution (y compris les environnements virtuels dont on parle ici). Je n'y suis pas encore passé moi même donc je n'ai pas de retour d'expérience, mais ça semble être vraiment bien.
J'avais aussi vu passer un outil qui utilisait __pypackages__ (cf. PEP 582) et qui n'avait donc pas besoin d’environnement virtuel. J'ai oublié le nom, mais après une recherche je suis tombé sur PDM, c'était peut-être celui-là.
Petit retour d'expérience sur Latex, que j'utilise avec un mélange de Kile et Vim :
ça demande un apprentissage, et il y a parfois voire souvent besoin de chercher sur le net, donc ça peut être exclus d'après tes critères
il y a des erreurs de compilations, ça peut taper sur les nerfs quand on ne sait pas d'où ça vient, mais si tu sauvegardes/compile régulièrement, tu devrais les voir suffisamment tôt pour trouver le problème.
il accuse son age, et n'est pas toujours très intuitif (les erreurs peuvent être cryptiques, il faut activer Unicode et les paquets qui correspondent à ce que tu veux avant que ça soit agréable à utiliser),
Ça c'est pour les mauvais côtés maintenant les bons :
le résultat est souvent très (très très) bien, et correspond aux normes typographiques
c'est du texte, ça se sauvegarde facilement et tu peux versionner sans problème
c'est du texte, tu peux utiliser tous les outils standards pour faire des modifications, tu peux faire un script qui t'importe automatiquement toutes les images d'un répertoire si ça t'arrange pas exemple.
ça s'exporte dans n'importe quoi (PDF, ePub, HTML, etc.). Avec Pandoc tu peux très certainement en faire du RST voire du ODT, donc possibilité de changer de train si tu changes d'idée.
une fois que t'as compris le truc, ça te fait une grosse partie du boulot (tout ce qui est références, figures, table des matières, numérotation, etc. est fait automatiquement et dans les règles de l'art, et ça s'adapte relativement facilement à tes besoins)
une fois que t'as compris le truc, tu te concentres sur le contenu, la mise en page est gérée en grande partie automatiquement, et tu ajustes comme tu l'entends vraiment à la fin
il y a une grosse communauté et beaucoup de ressources/paquets/thèmes
c'est utile à connaître, ça peut servir pour faire des présentations, pour écrire des formules mathématiques, d'autres livres à l'avenir
Sphinx est super pour de la doc (je l'utilise) mais ça ne serait pas mon outil de choix pour un livre. Scribus j'avais utilisé à ses début, c'était déjà bien et je pense que c'est super aujourd'hui, mais je l'utiliserais plutôt pour un dépliant ou un magazine.
Bref, pour un livre je choisirais très probablement Latex, mais c'est un choix qui demande un certain investissement (qui vaut le coup sur le long terme à mon avis), il n'est pas forcément le bon pour tout le monde (et puis je suis développeur).
J'ai une tablette Nexus 7 (flo) de 2013 achetée il a plusieurs années d'occasion. Elle est officiellement supportée (après repartitionnement) et tourne sous Lineage OS 18.1 avec mises à jour régulières : c'est fluide, stable, et fait parfaitement tourner ce dont on a besoin (sans gapps, ni même microG, mais ça pourrait s'installer facilement).
Il y aurait sans doute beaucoup moins de gaspillage électronique si ce genre de projets, et le libre en général étaient plus répandus.
Petites précisions pour le PinePhone, parce que ça ne me semple pas clair avec la dépêche alors que c'est mis en avant pour le Librem :
on peut aussi le brancher à un écran + clavier + souris (ou autre périphériques USB) pour en faire un ordinateur de bureau avec le pack convergence. J'ai testé avec Manjaro/Plasma Mobile et ça fonctionne pas mal du tout (à quelques crashs près, ça n'est pas encore tout à fait stable).
il y a des kill switchs aussi (interrupteurs pour couper caméra, micro, modem, etc.), ils sont placés sous la coque à côté de la batterie
Et surtout, une killer feature pour moi : il lance automatiquement un OS installé sur la carte SD externe. En d'autres termes, il suffit de mettre une carte SD pour tester un autre système (et les données sont enregistrées dessus).
En plus de cela la communauté est sympathique et très dynamique, et le développement logiciel avance très très vite. C'est utilisable en l'état contrairement on ce qu'on a pu connaître avec des prédécesseurs comme le Neo FreeRunner à l'époque (qui était une super machine quand même).
Bref pour moi c'est le téléphone idéal pour celles et ceux qui veulent développer sur OS libres (c'est d'ailleurs la raison pour laquelle j'en ai un, porter des logiciels sur les différents OS libres).
Et puis on peut lancer les mêmes logiciels que sur son ordi de bureau, c'est bien agréable (évidemment, avec beaucoup moins de puissance).
À noter aussi l'arrivée prochaine d'un accessoire clavier intégrant une grosses batterie, qui va transformer le téléphone en terminal GNU/Linux portable (une sorte de PDA).
Comme les autres, bravo et merci pour le boulot et la passion.
Vous faites partie de ces projets tenus par peu de personnes avec peu de moyens et qui tiennent malgré tout sur la longueur. Votre projet de lier création artistique avec développement libre est vraiment intéressant, et inspirant.
Merci aussi pour les contributions régulières notamment ici, et pour les commentaires autant techniques que sur ce qu'il se passe dans le monde libre artistique.
Dans une meilleure société vous devriez avoir les ressources pour vivre décemment, et ne pas tenir uniquement par la passion et les nerfs.
Exemple : un serveur FTP dans un réseau local utilisé pour partager des fichiers pour tout le monde, manque de bol, l'appliance qui ne supporte pas le https, et est trop vieille pour être mise à jour …
Seulement voilà, tous ces protocoles ne sont supportés qu'à moitié. Il manque le chiffrement de bout-en-bout à Matrix par exemple.
Mais comment est-ce possible ? Je croyais que le fonctionnement monolithique de Matrix, à l'opposé des extensions de XMPP, rendait une fonctionnalité manquante impossible ! On m'aurait menti ?
Blague à part, c'est souvent le problème des clients multi-protocoles, difficile d'implémenter correctement des tonnes de protocoles. D'ailleurs côté XMPP aussi c'est critiqué pour une implémentation très en dessous de ce qu'on attend de nos jours.
auto-hébergé, installable en moins d'1/2 heure (avec des containeurs Docker)
un client est choisi par plateforme (pour le moment Android avec Conversations et iOS avec Siskin)
les fonctionnalités sont testées entre ces clients, tout problème est corrigé et proposé en amont (upstream)
on parle de Snikket, pas de XMPP. Les clients sont renommés (« rebrandés » pour les marketeux) et c'est « Snikket » sur les dépôts d'applications
système d'invitation
les personnes invitées apparaissent automatiquement dans la liste de contacts (roster) des autres
même si ça n'est pas présenté explicitement comme tel, c'est du XMPP donc les utilisatrices et utilisateurs avancé·e·s peuvent utiliser le client de leur choix
Bref, c'est idéal pour faire un réseau familial rapidement et facile d'accès, tout en laissant la possibilité d'utiliser ses clients favoris.
C'est en bêta, mais côté Android c'est Conversations qui est largement éprouvé, et côté iOS je pense que ça tourne bien aussi (à vérifier).
Ayant participé plusieurs fois à l'espace numérique de la fête de l'huma, j'ai été en contact avec lui et j'ai eu l'occasion de discuter avec lui. Une personne engagée et intéressante, ça fait mal au cœur d'apprendre qu'il est parti comme ça.
C'est grâce à lui que l'espace numérique de la fête de l'huma existait, j'espère qu'il continuera. C'est un de mes événements préférés, car on y rencontre un public différent de celui des événements libristes habituels. Merci à Yann d'avoir permis ça.
Mes sincères condoléances à sa famille, ses ami·e·s et camarades.
Quand on est capable d'inventer les rouleaux de glace on est un anglais original, pas un escroc.
Je ne sais pas si c'est antérieur, mais j'ai déjà vu ça en Slovaquie (et c'est pas terrible, ça vaut pas les glaces traditionnelles qu'on a quelques dizaines de mètres plus loin).
Tu dis toi même qu'il faut que les 2 clients implémentent les mêmes XEP, et au moins pour certaines,
Il me semble assez évident que pour une conversation audio ou vidéo, il faut que les clients supportent, quel que soit le protocole. Y'a vraiment besoin de préciser ça ?
Me semble difficile de commencer ta phrase par un simple "ça c'est faux" du coup.
Si ce qui est affirmé plus haut est faux, et je le démonte dans mon commentaire.
On est bien d'accord qu'en dehors des fonctions les plus basiques, il faut que tous les participants utilisent un client qui supportent des XEP, qui sont optionnelles …
J'aime bien comme ça a glissé de « toute la chaîne » à « tous les clients ». Évidemment que pour afficher de la vidéo, il faut que le client soit prévu pour.
Déjà mentionné plus haut, Prosody le fait (cf. conclusion).
non Prosody utilise une version hashée, en tout cas c'est ce qui est mis dans la configuration de base (si on omet l'option je ne sais pas, il faudrait vérifier les sources plus en détails et je n'ai pas le temps, mais cette page laisse entendre que c'est bien la version hashée qui est utilisée par défaut) : https://hg.prosody.im/0.11/file/tip/prosody.cfg.lua.dist#l127 . La page citée plus haut ne doit plus être à jour depuis longtemps, il faudrait sans doute leur remonter d'ailleurs.
Pour ejabberd je ne sais pas, à vérifier. Tu cites un ticket de plus de 2 ans qui pointe sur un fichier qui n'existe plus, c'est le code actuel qu'il faut regarder.
Enfin bref, ça sert à rien de tourner en rond, j'ai déjà répondu plus haut : oui il faut hasher les mots de passe, non le protocole n'incite pas à garder les mots de passe en clair, et oui la spec citée plus haut devrait être corrigée pour mettre ça plus en évidence.
Les salons sont distribués sur tous les serveurs qui y participent. Il n'est donc pas possible de faire fermer un salon en supprimant un serveur qui l'hébergerait
Je ne pense pas qu'une réplication systématique soit une bonne chose pour beaucoup de raisons (maîtrise des données et ressources notamment), mais elle est très intéressante si elle est optionnelle.
Note qu'il est possible de le faire avec XMPP aussi (XEP-0282 et XEP-0289), mais c'est vrai que je ne connais aucune implémentation en pratique (je ne sais même pas trop ce que les XEPs valent, il faudrait regarder ça en détails). Aussi MIX (le nouveau protocole de chat en court d'élaboration/implémentation) devrait permettre aussi la réplication.
Enfin qu'on aime ou pas cette fonctionnalité, c'est vrai que Matrix le fait aujourd'hui, et XMPP en pratique non, reste à voir si c'est une fonctionnalité critique pour la personne qui choisi.
Par contre je crois me souvenir que le serveur principal de matrix était tombé il y a quelque temps, et que ça avait sacrément perturbé le réseau (à confirmer, je suis ça de très loin). Est-ce qu'en pratique la réplication permet vraiment de fonctionner sans accroc quand notre serveur principal tombe ?
Le protocole est versionné au lieu d'avoir un cœur simpliste et toute une collection d'extensions optionnelles. C'est ce qui fait que XMPP ne marche pas dans le monde réel : pour pouvoir utiliser des fonctions élémentaires, il faut que toute la chaîne (ton client, ton serveur, le serveur de ton interlocuteur, le client de ton interlocuteur) supporte les mêmes XEP et que tout soit bien configuré. Comme c'est rarement le cas, et qu'il n'y a aucune façon de le garantir … On fini par ne plus l'utiliser pour envoyer des fichiers par exemple (puisque trop de risque que ça ne passe pas). Je parle même pas d'appels audio/vidéo. Avec Matrix, ça juste marche.
Ça c'est faux. Il y a très peu de fonctionnalités qui demandent que toute la chaîne implémente quelque chose (en fait je n'en vois aucune là tout de suite), excepté PEP qui est implémenté par absolument tout le monde (c'est nécessaire pour publier des infos comme des clefs publiques). L'audio vidéo peut fonctionner si uniquement les clients l'implémentent, le serveur ne fait que fournir une aide pour traverser les réseau difficiles, et même là il suffit qu'un des 2 serveurs implémente ce qu'il faut.
L'envoi de fichier marche à ma connaissance avec tous les clients et serveurs, ça fait combien d'années que tu n'as pas essayé ?
Matrix utilise justement XMPP pour les appels audio/vidéo (via Jitsi Meet qu'il embarque), sauf pour les appels 1:1 qui sont du webRTC (et là c'est les navigateurs qui font le boulot principal).
Et en pratique, combien de clients autres que le client principal de Matrix (Element) implémentent toutes les fonctionnalités ? Est-ce qu'il y a un seul client tiers qui le fait ? Ils ont exactement le même problème pour la même raison : c'est une question de ressource, et le client principal de Matrix avance bien parce qu'ils ont de l'argent pour payer des équipes de développement à plein temps (tant mieux pour eux), mais les clients tiers n'ont pas souvent les moyens de suivre au même rythme.
Tu parles d'une extension qui a été écrite en 2007, et qui n'a pas été touchée depuis 2010, à l'époque les mots de passe étaient stockés beaucoup plus souvent en clair, maintenant il y a des méthodes plus à jour, et je ne pense qu'il y ait beaucoup de serveurs qui gardent les mots de passe en clair. Et le principe d'un protocole ouvert comme XMPP, c'est qu'on peut justement pointer ce genre de problème et y répondre par une mise à jour de la spécification (ou une nouvelle qui va remplacer l'ancienne).
De la même façon un code libre n'est pas dépourvu de bugs ou failles de sécurités parce qu'il est libre, mais il y a plus de chance que quelqu'un voit le problème et le corrige.
Bref, bien sûr que le protocole n'est pas parfait, il ne doit pas y en avoir beaucoup qui le sont (on trouve des failles dans des protocoles bien plus utilisés que XMPP), mais on peut le corriger et le faire évoluer, et il y a de bon mécanismes pour ça.
Tous les avantages que tu cites pour XMPP se retrouvent dans le protocole Matrix.
Avec peut être en plus des passerelles vers pas mal d'autres solutions (dont signal, Slack,IRC,Telegram,etc)
Il y a des passerelles avec XMPP aussi, et je doute qu'il existe beaucoup de protocoles qui ont un « bridge » Matrix et pas de passerelles XMPP. En tout cas pour Signal, Slack, IRC et Telegram ça existe.
Le problème de XMPP du point de vue utilisateur lambda, c'est qu'il faut faire, au minimum, 2 choix :
- le logiciel à utiliser (et il y en a pléthore)
- le serveur sur lequel sera héberger notre compte (et potentiellement, pour les plus geek, installer ce-dit serveur).
Ce sont 2 questions de trop pour la plupart des gens. Quand on leur dit, je suis sur Signal, rejoins moi, les gens ne se posent pas la question de savoir quel logiciel installer, ni où créer leur compte. C'est "naturel".
Avec Signal aussi tu choisis un logiciel (Signal), et un serveur (le serveur officiel de Signal), la seule différence c'est que tu l'imposes aux autres.
XMPP est un protocole qui te permet de choisir un logiciel est un serveur, ça ne veut pas dire que chaque utilisateur doit le faire, il y a des projets qui le font pour toi. C'est le cas de Snikket par exemple où le serveur est déjà choisi par la personne qui invite, et les clients sont déjà choisis aussi. La différence avec Signal, c'est que je peux communiquer avec eux avec le serveur et le client de mon choix.
Mais malheureusement, de plus en plus mes contacts chiffrent leurs messages avec OMEMO, bien souvent sans le savoir, juste parce que c'est activé par défaut dans Conversations.
C'est gênant quand son client ne le gère pas encore, mais je ne dirais pas « malheureusement », c'est une très bonne chose (même s'il y a redire sur beaucoup de points, le mouvement général va dans le bon sens).
Sinon le frontal TUI de Libervia (ex. Salut à Toi) que je développe gère aussi OMEMO (en 1:1, groupe et pour les fichiers). Et accessoirement, je suis ouvert au suggestions pour améliorer l'interface.
Et Poezio est un très bon client, et il me semblait que OMEMO était en cour d'implémentation dedans (mathieui tu peux confirmer ou infirmer ?).
[^] # Re: Triste
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Multiple démissions dans l'équipe du réseau IRC Freenode. Évalué à 7.
Sauf erreur ou évolution, cela ne compte que des serveurs Prosody qui ont installé un plugin particulier, ça limite beaucoup.
# Triste
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Multiple démissions dans l'équipe du réseau IRC Freenode. Évalué à 6.
Triste de voir ce genre de chose se passer sur un des piliers historiques du logiciel libre (entre autres choses)
Après quel que soit les protocoles et logiciels de votre choix, c'est une fois de plus un événement qui montre l'importance de la décentralisation (et malgré cela, on voit encore, y compris chez les libristes et autres publics qui se voudraient avertis, les mêmes erreurs se répéter).
[^] # Re: Merci pour ton travail de traduction
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Lettre d'information XMPP d'avril 2021. Évalué à 3.
idem, travail utile et apprécié, mais c'est compréhensible de vouloir passer à autre chose. Merci !
[^] # Re: XMPP
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Our Shopping List : liste de courses partagée et libre. Évalué à 3.
Oui ben c'est normal, honnêtement se farcir les protocole c'est pas la chose la plus excitante du monde dans le développement.
Le rôle des bibliothèques c'est justement de rendre ça plus facile d'accès sans avoir à trop s’inquiéter des détails internes. Si t'as besoin d'aide, tu peux me contacter ou aller sur un salon dédié. Avec JavaScript, je vois par exemple que ça a l'air assez facile d'utiliser Pubsub via stanzaJS.
En gros dans ton cas, l'avantage c'est que tu peux utiliser un serveur XMPP existant (https://jabberfr.org/ par exemple) et implémenter la synchro via Pubsub par dessus, et tu as ainsi une implémentation prête à l'emploi pour les notifications, permissions, et abonnements (et dans quelques mois le chiffrement de bout en bout), ça ne devrait pas être si compliqué à greffer sur une archi existante, même centralisée.
Si tu veux une idée du fonctionnement, j'avais écris un article de vulgarisation ici même : Parlons XMPP - épisode 8 - PubSub et PEP.
Enfin bref, c'est juste une suggestion tu en fais ce que t'en veux. C'est surtout que j'aimerais bien voir une compatibilité entre les différentes options libres :)
# XMPP
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Our Shopping List : liste de courses partagée et libre. Évalué à 6.
Salut et bravo pour ton projet.
Pour info, j'ai aussi travaillé sur une liste de courses avec Libervia, basée sur XMPP. Elle est donc décentralisée avec un système de permissions (dans la capture ci-dessous il suffit de cliquer sur
manage invitationset de choisir les personnes à inviter).Ton projet est bien avancé mais vu que tu n'as pas encore fait le système de permission/synchronisation, peut être que tu peux envisager d'utiliser XMPP pour ça (avec une des bibliothèques disponibles ça devrait être relativement facile) ? Ça serait chouette que ça soit compatible, et ça t'éviterait d'avoir à réinventer la roue.
[^] # Re: tout bêtement
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Our Shopping List : liste de courses partagée et libre. Évalué à 2. Dernière modification le 08 mai 2021 à 10:19.
Par curiosité, c'est un message texte simple que vous supprimez ensuite (ou barrez ?), ou Telegram gère une forme de liste dynamique ?
# Poetry et PEP 582
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Python — partie 7 — Environnements virtuels. Évalué à 9.
Depuis quelque temps, il y a Poetry qui a le vent en poupe, il gère tout ce qu'il faut pour le packaging, la publication, et l'exécution (y compris les environnements virtuels dont on parle ici). Je n'y suis pas encore passé moi même donc je n'ai pas de retour d'expérience, mais ça semble être vraiment bien.
J'avais aussi vu passer un outil qui utilisait
__pypackages__(cf. PEP 582) et qui n'avait donc pas besoin d’environnement virtuel. J'ai oublié le nom, mais après une recherche je suis tombé sur PDM, c'était peut-être celui-là.# Latex
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Outils pour écrire un livre. Évalué à 8. Dernière modification le 05 mai 2021 à 10:41.
Petit retour d'expérience sur Latex, que j'utilise avec un mélange de Kile et Vim :
Ça c'est pour les mauvais côtés maintenant les bons :
Sphinx est super pour de la doc (je l'utilise) mais ça ne serait pas mon outil de choix pour un livre. Scribus j'avais utilisé à ses début, c'était déjà bien et je pense que c'est super aujourd'hui, mais je l'utiliserais plutôt pour un dépliant ou un magazine.
Bref, pour un livre je choisirais très probablement Latex, mais c'est un choix qui demande un certain investissement (qui vaut le coup sur le long terme à mon avis), il n'est pas forcément le bon pour tout le monde (et puis je suis développeur).
[^] # Re: Et les téléphones basiques (aka dumb phones) ?
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Quel téléphone (plus ou moins) libre en 2021 ?. Évalué à 2.
Il y a le ZeroPhone, mais je ne sais pas s'il est encore en développement.
[^] # Re: LineageOS
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Quel téléphone (plus ou moins) libre en 2021 ?. Évalué à 6.
J'ai une tablette Nexus 7 (flo) de 2013 achetée il a plusieurs années d'occasion. Elle est officiellement supportée (après repartitionnement) et tourne sous Lineage OS 18.1 avec mises à jour régulières : c'est fluide, stable, et fait parfaitement tourner ce dont on a besoin (sans gapps, ni même microG, mais ça pourrait s'installer facilement).
Il y aurait sans doute beaucoup moins de gaspillage électronique si ce genre de projets, et le libre en général étaient plus répandus.
# PinePhone
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Quel téléphone (plus ou moins) libre en 2021 ?. Évalué à 10. Dernière modification le 01 mai 2021 à 11:09.
Merci pour la dépêche.
Petites précisions pour le PinePhone, parce que ça ne me semple pas clair avec la dépêche alors que c'est mis en avant pour le Librem :
Et surtout, une killer feature pour moi : il lance automatiquement un OS installé sur la carte SD externe. En d'autres termes, il suffit de mettre une carte SD pour tester un autre système (et les données sont enregistrées dessus).
En plus de cela la communauté est sympathique et très dynamique, et le développement logiciel avance très très vite. C'est utilisable en l'état contrairement on ce qu'on a pu connaître avec des prédécesseurs comme le Neo FreeRunner à l'époque (qui était une super machine quand même).
Bref pour moi c'est le téléphone idéal pour celles et ceux qui veulent développer sur OS libres (c'est d'ailleurs la raison pour laquelle j'en ai un, porter des logiciels sur les différents OS libres).
Et puis on peut lancer les mêmes logiciels que sur son ordi de bureau, c'est bien agréable (évidemment, avec beaucoup moins de puissance).
À noter aussi l'arrivée prochaine d'un accessoire clavier intégrant une grosses batterie, qui va transformer le téléphone en terminal GNU/Linux portable (une sorte de PDA).
[^] # Re: Merci !
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.24: version cartographe. Évalué à 10.
Comme les autres, bravo et merci pour le boulot et la passion.
Vous faites partie de ces projets tenus par peu de personnes avec peu de moyens et qui tiennent malgré tout sur la longueur. Votre projet de lier création artistique avec développement libre est vraiment intéressant, et inspirant.
Merci aussi pour les contributions régulières notamment ici, et pour les commentaires autant techniques que sur ce qu'il se passe dans le monde libre artistique.
Dans une meilleure société vous devriez avoir les ressources pour vivre décemment, et ne pas tenir uniquement par la passion et les nerfs.
[^] # Re: Est-ce que quelqu'un pourrait m'indiquer ...
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Firefox met fin au FTP. Évalué à 10.
python3 -m http.server
[^] # Re: Snif
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal GAIM, c'est fini. Évalué à 9.
Mais comment est-ce possible ? Je croyais que le fonctionnement monolithique de Matrix, à l'opposé des extensions de XMPP, rendait une fonctionnalité manquante impossible ! On m'aurait menti ?
Blague à part, c'est souvent le problème des clients multi-protocoles, difficile d'implémenter correctement des tonnes de protocoles. D'ailleurs côté XMPP aussi c'est critiqué pour une implémentation très en dessous de ce qu'on attend de nos jours.
[^] # Snikket
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Signal envoie des signaux inquiétants. Évalué à 10.
À noter le project Snikket lancé par l'équipe de Prosody, qui est très prometteur.
https://snikket.org
Le projet fonctionne comme ça:
Bref, c'est idéal pour faire un réseau familial rapidement et facile d'accès, tout en laissant la possibilité d'utiliser ses clients favoris.
C'est en bêta, mais côté Android c'est Conversations qui est largement éprouvé, et côté iOS je pense que ça tourne bien aussi (à vérifier).
Ce projet mérite une dépêche d'ailleurs.
# Condoléances
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche À la mémoire de Yann, notre camarade libriste. Évalué à 7.
Ayant participé plusieurs fois à l'espace numérique de la fête de l'huma, j'ai été en contact avec lui et j'ai eu l'occasion de discuter avec lui. Une personne engagée et intéressante, ça fait mal au cœur d'apprendre qu'il est parti comme ça.
C'est grâce à lui que l'espace numérique de la fête de l'huma existait, j'espère qu'il continuera. C'est un de mes événements préférés, car on y rencontre un public différent de celui des événements libristes habituels. Merci à Yann d'avoir permis ça.
Mes sincères condoléances à sa famille, ses ami·e·s et camarades.
[^] # Re: SVN
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Adieu vieille branche. Évalué à 5.
bon autant aller directement à l'origine : la nature le faisait encore avant
[^] # Re: Attention, escroquerie
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal titre. Évalué à 4.
Je ne sais pas si c'est antérieur, mais j'ai déjà vu ça en Slovaquie (et c'est pas terrible, ça vaut pas les glaces traditionnelles qu'on a quelques dizaines de mètres plus loin).
[^] # Re: Matrix vs XMPP
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Messagerie instantanée : ce n’est pas une question d’applications. Évalué à 4. Dernière modification le 02 février 2021 à 15:57.
Il me semble assez évident que pour une conversation audio ou vidéo, il faut que les clients supportent, quel que soit le protocole. Y'a vraiment besoin de préciser ça ?
Si ce qui est affirmé plus haut est faux, et je le démonte dans mon commentaire.
J'aime bien comme ça a glissé de « toute la chaîne » à « tous les clients ». Évidemment que pour afficher de la vidéo, il faut que le client soit prévu pour.
[^] # Re: Configuration serveur et écosystème de clients
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Messagerie instantanée : ce n’est pas une question d’applications. Évalué à 4.
non Prosody utilise une version hashée, en tout cas c'est ce qui est mis dans la configuration de base (si on omet l'option je ne sais pas, il faudrait vérifier les sources plus en détails et je n'ai pas le temps, mais cette page laisse entendre que c'est bien la version hashée qui est utilisée par défaut) : https://hg.prosody.im/0.11/file/tip/prosody.cfg.lua.dist#l127 . La page citée plus haut ne doit plus être à jour depuis longtemps, il faudrait sans doute leur remonter d'ailleurs.
Pour ejabberd je ne sais pas, à vérifier. Tu cites un ticket de plus de 2 ans qui pointe sur un fichier qui n'existe plus, c'est le code actuel qu'il faut regarder.
Enfin bref, ça sert à rien de tourner en rond, j'ai déjà répondu plus haut : oui il faut hasher les mots de passe, non le protocole n'incite pas à garder les mots de passe en clair, et oui la spec citée plus haut devrait être corrigée pour mettre ça plus en évidence.
[^] # Re: Matrix vs XMPP
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Messagerie instantanée : ce n’est pas une question d’applications. Évalué à 7. Dernière modification le 02 février 2021 à 13:40.
Je ne pense pas qu'une réplication systématique soit une bonne chose pour beaucoup de raisons (maîtrise des données et ressources notamment), mais elle est très intéressante si elle est optionnelle.
Note qu'il est possible de le faire avec XMPP aussi (XEP-0282 et XEP-0289), mais c'est vrai que je ne connais aucune implémentation en pratique (je ne sais même pas trop ce que les XEPs valent, il faudrait regarder ça en détails). Aussi MIX (le nouveau protocole de chat en court d'élaboration/implémentation) devrait permettre aussi la réplication.
Enfin qu'on aime ou pas cette fonctionnalité, c'est vrai que Matrix le fait aujourd'hui, et XMPP en pratique non, reste à voir si c'est une fonctionnalité critique pour la personne qui choisi.
Par contre je crois me souvenir que le serveur principal de matrix était tombé il y a quelque temps, et que ça avait sacrément perturbé le réseau (à confirmer, je suis ça de très loin). Est-ce qu'en pratique la réplication permet vraiment de fonctionner sans accroc quand notre serveur principal tombe ?
Ça c'est faux. Il y a très peu de fonctionnalités qui demandent que toute la chaîne implémente quelque chose (en fait je n'en vois aucune là tout de suite), excepté PEP qui est implémenté par absolument tout le monde (c'est nécessaire pour publier des infos comme des clefs publiques). L'audio vidéo peut fonctionner si uniquement les clients l'implémentent, le serveur ne fait que fournir une aide pour traverser les réseau difficiles, et même là il suffit qu'un des 2 serveurs implémente ce qu'il faut.
L'envoi de fichier marche à ma connaissance avec tous les clients et serveurs, ça fait combien d'années que tu n'as pas essayé ?
Matrix utilise justement XMPP pour les appels audio/vidéo (via Jitsi Meet qu'il embarque), sauf pour les appels 1:1 qui sont du webRTC (et là c'est les navigateurs qui font le boulot principal).
Et en pratique, combien de clients autres que le client principal de Matrix (Element) implémentent toutes les fonctionnalités ? Est-ce qu'il y a un seul client tiers qui le fait ? Ils ont exactement le même problème pour la même raison : c'est une question de ressource, et le client principal de Matrix avance bien parce qu'ils ont de l'argent pour payer des équipes de développement à plein temps (tant mieux pour eux), mais les clients tiers n'ont pas souvent les moyens de suivre au même rythme.
[^] # Re: Configuration serveur et écosystème de clients
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Messagerie instantanée : ce n’est pas une question d’applications. Évalué à 5.
Tu parles d'une extension qui a été écrite en 2007, et qui n'a pas été touchée depuis 2010, à l'époque les mots de passe étaient stockés beaucoup plus souvent en clair, maintenant il y a des méthodes plus à jour, et je ne pense qu'il y ait beaucoup de serveurs qui gardent les mots de passe en clair. Et le principe d'un protocole ouvert comme XMPP, c'est qu'on peut justement pointer ce genre de problème et y répondre par une mise à jour de la spécification (ou une nouvelle qui va remplacer l'ancienne).
De la même façon un code libre n'est pas dépourvu de bugs ou failles de sécurités parce qu'il est libre, mais il y a plus de chance que quelqu'un voit le problème et le corrige.
Bref, bien sûr que le protocole n'est pas parfait, il ne doit pas y en avoir beaucoup qui le sont (on trouve des failles dans des protocoles bien plus utilisés que XMPP), mais on peut le corriger et le faire évoluer, et il y a de bon mécanismes pour ça.
[^] # Re: XMPP ou Matrix ?
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Messagerie instantanée : ce n’est pas une question d’applications. Évalué à 5.
Il y a des passerelles avec XMPP aussi, et je doute qu'il existe beaucoup de protocoles qui ont un « bridge » Matrix et pas de passerelles XMPP. En tout cas pour Signal, Slack, IRC et Telegram ça existe.
[^] # Re: Mauvaise question...
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Messagerie instantanée : ce n’est pas une question d’applications. Évalué à 7.
Avec Signal aussi tu choisis un logiciel (Signal), et un serveur (le serveur officiel de Signal), la seule différence c'est que tu l'imposes aux autres.
XMPP est un protocole qui te permet de choisir un logiciel est un serveur, ça ne veut pas dire que chaque utilisateur doit le faire, il y a des projets qui le font pour toi. C'est le cas de Snikket par exemple où le serveur est déjà choisi par la personne qui invite, et les clients sont déjà choisis aussi. La différence avec Signal, c'est que je peux communiquer avec eux avec le serveur et le client de mon choix.
[^] # Re: mcabber (ou profanity ?)
Posté par Goffi (site web personnel, Mastodon) . En réponse au sondage Quel est selon vous le client XMPP à l'interface la plus adaptée pour une équipe soudée de gens inconnus?. Évalué à 3.
C'est gênant quand son client ne le gère pas encore, mais je ne dirais pas « malheureusement », c'est une très bonne chose (même s'il y a redire sur beaucoup de points, le mouvement général va dans le bon sens).
Sinon le frontal TUI de Libervia (ex. Salut à Toi) que je développe gère aussi OMEMO (en 1:1, groupe et pour les fichiers). Et accessoirement, je suis ouvert au suggestions pour améliorer l'interface.
Et Poezio est un très bon client, et il me semblait que OMEMO était en cour d'implémentation dedans (mathieui tu peux confirmer ou infirmer ?).