Le but c'est bien ça, réduire la voiture en Métropole.
Il faut bien comprendre l'ensemble. Les Métropoles n'ont pas la main là dessus, elles ne peuvent pas activement réduire la place de la voiture. La ZFE est un moyen détourné pour y arriver. C'est un secret de polichinelle ;)
Sur Grenoble, l'idée de la ZFE en discussion actuellement c'est d'interdire les thermiques horizon 2030. Donc on va parler avant tout de pollution de l'air, de particules, de bruit. Là où on a des normes à atteindre, et on va regarder comment y arriver. Sur Grenoble Alpes Métropole le but c'est de passer en dessous de la norme de l'OMS par exemple en terme de particules fines.
Bref, sur les projections que j'ai eu, c'est -20% du parc automobile qui sera autorisé à rouler en 2030. Sur ~200.000 véhicules particulier ça en retire quand même 40.000, ce n'est pas rien.
Après y'a toute la question du "report modal" qui se fera en gros sur 3 axes:
- L'achat de véhicules "propres" (et je garde les guillemets là)
- Le transport en commun
- La mobilité légère (marche, vélo, trottinette)
Pour les véhicules électriques, y'a plein de limites, le prix, l'infrastructure…. Sur Grenoble, le budget va être très limité pour le développement du transport en commun (il faudrait faire +30% d'ici 2030 pour contenir les effets de la ZFE, et il est plutôt en contraction aujourd'hui).
Du coup, ma vision c'est de faire de la mobilité légère, ça coute pas cher, c'est (plus) facile à déployer et financer et ça touche tout le monde.
(PS, je suis élu sur une commune de la Métropole de Grenoble).
La CE est complètement à la ramasse au niveau numérique.
Non respect du RGPD (scripts de tracking américains injectés dans l'espace privé, où il y a tous les détails bancaires!!!), script JS qui datent de 2010 avec le nom des développeurs et des console.log qui se baladent un peu partout.
Leur site ou des parties sont down très très souvent.
Leur service client est digne d'une banque des années 1995, à coup d'envois de mail avec des scan papier, des justifications foireuses et des process qui durent des mois (envoyer un chèque par la poste d'une CE à une autre CE d'un autre région au lieu de faire un virement).
Et pour couronner le tout, leurs frais sont exorbitant.
Bref, fuyez cette banque, au niveau national (j'ai changé de région plusieurs fois) !
Je pense qu'il serait intéressant de préciser que Firefox Lite n'est disponible que dans certains pays sur le Play-Store (et pas en Europe de ce que j'ai vu) et qu'il utilise (pour l'instant) le moteur Webkit/Chrome disponible sur le téléphone.
Le problème n'est pas d'intégrer ces fonctions nativement dans le navigateur ou non :)
Ces fonctions seront appelés par du JS qui sera chargé depuis le serveur web, il faut donc faire confiance au serveur, c'est bête pour un système de chiffrement bout en bout.
J'ai exactement le même soucis avec Movim (voir https://github.com/movim/movim/issues/63). La solution: chiffrer/déchiffrer les messages sur le serveur, donc ce n'est plus "bout en bout" mais bon ça revient au même que de chiffrer coté client avec du JS délivré depuis le serveur à ce niveau ;)
C'est le mot qui m'est venu à l'esprit en voyant ça.
Quand il s'agit de passer des dizaines d'heures pour être sûr que le trackeur remonte bien les données y'a pas de soucis, par contre pour virer tout ça et respecter un peu mieux les visiteurs tout de suite les budgets sont plus restreints.
le réseau XMPP est éclaté au gré des versions, là où je suppose que tout les serveurs Movim fournissent les mêmes fonctionnalités avec la même interface.
Bah c'est juste que le protocole évolue, donc non il n'y a pas de "versions" mais plutôt qui implémente quel bout de version du protocole (c'est un peu pareil pour tous les autres protocoles en fait).
Movim a une liste de fonctionnalités a peu prêt stables depuis quelques années en effet mais l'interface et features évoluent quand même un peu mois après mois.
Si j'ai un compte Movim, je peux donc faire de la messagerie instantanées avec les applications type Conversation, Pidgin, Gajim, etc?
Tu n'as pas de compte Movim, c'est tout le concept, tu as un compte XMPP, Movim est un client XMPP orienté "social" où tu te connecte avec ton compte XMPP dessus, c'est tout. Donc oui, par extension il est compatible avec tous les autres clients XMPP déjà dans la nature :)
Movim est-il sécurisé ?
Définir "sécurisé", Movim se connecte aux serveurs XMPP en utilisant la norme SASL (définit dans XMPP), en forçant TLS (définit dans XMPP) et délivre aussi le contenu en HTTPS/WSS. Si tu parles de chiffrement de bout en bout, la réponse courte et non, la réponse longue se situe ici https://github.com/movim/movim/issues/63.
Petite précision, pour pas se mélanger les pinceaux il va falloir être attentif à séparer proprement les "clients" des "réseaux".
Là ou un réseau centralisé comme Facebook est plutôt une solution tout en un Diaspora/Mastodon sont des solutions dont les "pods" hébergent aussi les comptes (c'est fédéré SUR les pods). Movim par exemple n'est qu'un client qui se connecte aux serveurs XMPP, les comptes ne sont pas sur les "pods" Movim mais sur les serveurs XMPP (plus à la manière des serveurs mails).
Je pense que c'est un détail qui a toute son importance.
TapTempo? Ah c'est le truc qui SPAM LinuxFR en ce moment avec une méthodologie digne d'une publicité TV Mercurochrome. Désolé j'ai même pas regardé ce que c'était à part un machin qui voulait être écrit dans tous les langages.
J'ai vraiment du mal à justifier le bashing continuel envers PHP.
Le langage à certes des défauts mais depuis quelques années, avec des frameworks comme Laravel, les PSR, Composer, la documentation… franchement je commence à douter du sérieux de ces points de vue.
On peut aussi parler de l'environnement autour de JS? Du clivage de la communauté Python avec l'arrivée de Python 3.
Peut être que le soucis ici c'est le mot "Web". L'IETF (et XMPP) a vocation à standardiser des protocoles s'appliquant sur le réseau "Internet" alors que le W3C ne s'occupe principalement que ce qui touche au Web (donc, en gros, ce qui est construit sur HTTP).
Ce que j'ai répété pendant pas mal de temps dans mes conférences c'est que le "Web" et un sous-ensemble de "Internet" (HTTP repose sur TCP…).
Ce n'est pas un soucis en soit mais XMPP a vocation d'être accessible depuis un nombre d'application bien plus grandes "by design" (ce qui est aussi une critique qu'on lui apporte, les premiers pas sur XMPP sont plus difficiles que de jouer avec une simple API REST/JSON). Aussi essayer de transformer un protocole "connecté" (construit sur des flux) comme XMPP en protocole "déconnecté" (construit sur des requêtes) est bien plus simple que l'inverse.
C'est assez rigolo qu'on trouve toujours quelqu'un pour critiquer un truc qui va pas :D
Les noms sont juste pris un peu au hasards dans la liste des comètes de Wikipedia D'ailleurs si tu souhaitais participer j'avais offert le choix à la communauté de trouver le nom de la release pour cette version https://nl.movim.eu/?node/pubsub.movim.eu/Movim/8d77979d-5485-4742-be83-b2669f58fbdd, vu que je n'ai pas eu de retours particulier j'ai choisit Lovejoy :) Le nom de la prochaine release reste à choisir ;)
Lovejoy c'est le nom d'une comète, comme pour les précédentes version depuis le passage à l'architecture temps-réel sur Movim (v0.11 – Tuttle, v0.10 – Holmes, v0.9 – Tchouri) ;)
Sinon la communauté (merci à eux) bosse sur des paquets pour les différentes distros (que ça soit pour les clients ou l'instance serveur).
irssi dans un screen permettait de le faire depuis 1999 pour IRC.
En lançant une VM avec une Ubuntu et un client XMPP, puis ne me connectant en bureau à distance dessus j'arrive aussi à garder synchronisé mes messages tout le temps depuis partout! Génial!
Ces évolutions (en particulier la gestion native des WebSockets) permettent-elles d'utiliser prosody pour faire tourner un client web comme Movim ?
Petite précision ici, Movim utilise bien la technologie WebSocket, mais coté navigateur, il se connecte à XMPP de façon standard (flux TCP avec TLS), rien de particulier n'est à configurer coté serveur pour qu'il fonctionne donc :)
Ça tombe bien, Jingle (la partie "visio/p2p") de XMPP est pleinement compatible avec WebRTC (il y a même des extensions spécialement écrites pour ça https://xmpp.org/extensions/xep-0343.html).
J'appelle ma moman de temps en temps en utilisant Movim et WebRTC entre nos deux comptes XMPP entre Chrome et Firefox, en 720p stéréo :)
Le recensement effectué en 2007 en Chine populaire donne 4700 noms, dont une centaine de doubles et de rares noms plus longs. Chez les Han, on compte en moyenne 320 000 personnes par nom, avec de très grandes variations en pratique. Une centaine de grands noms nomment réunis 84,77％ des Chinois. Wang (王) vient en tête avec 92,881 millions de porteurs (7,25％ de la population) suivi de Li (李) (92,074 millions, 7,19％) et Zhang (張/张) (87,502 millions, 6,83％). https://fr.wikipedia.org/wiki/Nom_de_famille_chinois#Statistiques
On est d'accord, il y a eu un problème de calendrier. Et oui je te l'accorde, XMPP a mis du temps, beaucoup de temps, à se réveiller et enfin intégrer des fonctionnalités "modernes" de messagerie (partage de fichier, synchronisation des messages entre clients, gestion de l'historique, édition des messages publiés…).
Là où il faut faire attention, et c'est un soucis de rôle qui revient couramment, c'est que "XMPP" n'a pas comme vocation de proposer une solution clé-en-main avec services et clients aux internautes. XMPP est un protocole, au même niveau que SMTP/IMAP/POP ou HTTP le sont pour l'email et le Web. La XSF offre juste une solution de messagerie fédéré.
D'ailleurs c'est une question qui revient assez souvent au sein de la XSF (dont je suis moi même membre). La XSF doit elle pousser ou mettre en avant certains clients ou solutions implémentant XMPP au détriment des autres? Jusqu'ici la réponse a été de jouer la carte de la neutralité et de se cantonner à simplement "faire le job de standardisation".
Mais pour revenir à ta remarque le problème de XMPP a bien été un problème temporel. Aujourd'hui on ne se pose plus la question de savoir quel protocole utiliser pour l'email et le Web, car très tôt un standard a émergé (surtout pour l'email, pour le "Web" ça a été un peu plus compliqué, on se souvient de la bataille des navigateurs dans les années 90-début 2000). Les protocoles et standards gravitant autour de l'email et du Web ne sont pas parfaites, loin de là, mais ont comme avantage de proposer une vision unifiée forçant même les "géants" à se plier à eux (tu peux envoyer un email d'un compte Outlook à un compte Gmail depuis un iPhone sur un Thunderbird installé sur une distro Linux).
Pour la messagerie instantanée (et même le réseau social, ce que j'essaye de montrer avec Movim), malheureusement ce sont les outils qui sont venus avant les protocoles, si bien qu'aujourd'hui il devient difficile d'expliquer que non le problème ne vient pas d'XMPP en lui même, mais du fait qu'il lui faut se justifier face à des solutions centralisées, complète, faciles et intégrées aux interfaces et appareils des utilisateurs.
La question que je poserais donc serait de savoir pourquoi aujourd'hui nous n'avons pas encore de clients/serveurs/plateformes qui permettent d'offrir des solutions de messageries instantanées "modernes" et étant construit sur LE standard (norme IETF, au même titre que POP/IMAP/SMTP/HTTP… le sont) existant.
Cela est entrain de changer, on commence (enfin) à avoir des clients complets et accessibles (Conversations ou Dino https://github.com/dino/dino, voir même Movim (dont je suis le développeur principal)) et les serveurs rattrapent leurs retard rapidement sur ce qui a été standardisé ces dernières années.
Il y a quelques années (je bosse sur Movim depuis 9 ans maintenant) j'étais très dubitatif quand au fait que XMPP soit réellement un protocole viable pour construire une solution moderne de messagerie instantanée (et de réseautage social dans mon cas) mais en travaillant de consorts avec les autres projets (clients comme serveurs) implémentant XMPP, en ouvrant des bugs et discutant continuellement des implémentations et de l'amélioration du protocole j'ai la forte impression qu'on est entrain de transformer l’essai.
Les discussions au sein de la XSF se sont énormément fluidifiés ces derniers mois, les nouvelles fonctionnalités peuvent être standardisés et intégrés en l'espace de quelques mois (alors qu'il fallait bien souvent des années auparavant). Même si nous avons nos propres points de vues je suis heureux de voir qu'il y a des échanges continuels sur comment "bien faire" avant de simplement implémenter et de voir ensuite. Tout ça permet de proposer des serveurs et clients compatibles à leur sortie et d'avoir systématiquement une documentation de référence pour les futur entrants souhaitant communiquer avec les projets existants.
XMPP n'a pas comme vocation à régler le problème de portabilité des comptes d'un serveur à un autre, qui est un problème plutôt complexe dans un réseau fédéré. Tu l'as dit toi même, pour l'email, ô combien c'était compliqué (je noterais tout de même que sur XMPP la liste de contacts est synchronisé avec le serveur ce qui facilite la transition).
Les réseaux centralisés n'amènent pas nom plus de solution à ce problème, au contraire, Facebook a t'il codé une solution pour permettre à ses utilisateur de migrer aisément sur Google+ ? Je ne le crois pas.
Nous pouvons tout de même noter que l'Europe est entrain de forcer la main à ces géants concernant la portabilité des données entre les plateformes (dans la section concernant la Data Portabity du tout récent GDPR https://en.wikipedia.org/wiki/General_Data_Protection_Regulation) et cela passera pas la mise en place et le développement d'outils prenant appuis sur des standards et protocoles existants.
L'histoire de l'identifiant unique "qui le suit toute sa vie" c'est une fausse solution, car elle amène également un grand nombre de soucis, notamment concernant la traçabilité et le recoupage. Il n'y a pas de solution miracle et XMPP à fait le choix d'être fédéré ("à la email") avec tous les défauts et contraintes inhérents à ce genre d'architecture.
L'un des gros points positifs, et tu l'as mentionné, d'un système centralisé c'est la découverte de contenu. Ou, dit d'une nouvelle façon, le "tu as déjà 9 contacts sur le réseau, on le sait car tout le monde est dans la même base de donnée". Cette fonctionnalité et ce qui marche le plus en ce moment, le dernier grand exemple étant WhatsApp: le recoupage et la découverte étant d'une simplicité absolue puisqu'il s'agit d'aspirer la liste de contacts (téléphonique) de l'utilisateur et de la comparer aux identifiants (numéros téléphoniques) des membres déjà inscrits.
Il n'y a pas de solution magique malheureusement, la découverte de contenu/contacts dans un réseau fédéré (ou pire décentralisé) est un problème très complexe. La solution la plus simple (et "scalable") que nous avons pour l'instant et d'indexer le réseau en un point: le moteur de recherche/annuaire (Google pour le Web, ThePirateBay pour le réseau Torrent…).
Merci à toi pour ce petit article pour faire découvrir cette merveilleuse radio sur LinuxFR.
Radio Paradise c'est depuis pas mal d'années déjà la webradio que j'écoute quand je ne sais pas quoi écouter dans mon audio-thèque MPD :) Elle a même un bouton assigné sur la télécommande IR de mon RPi (qui me sert de médiacenter à la maison).
C'est l'intérêt d'avoir ce genre d'infrastructure :) Au choix.
Il existe déjà plein d'instances déployées de part le monde ainsi que plusieurs serveurs XMPP compatibles mais rien ne t'empêche d'héberger toi même ton instance, voir ton serveur XMPP si tu le souhaites.
L'intérêt principal est souvent d'avoir le contrôle sur tes données.
Corrigé ;)
Petite précision, le paquet RPM n'est qu'une conversion du paquet DEB en utilisant Alien. Je n'ai malheureusement pas le temps de packager proprement Movim sur toutes les distros mais je suit ouvert à toute aide extérieure sur ce genre de tâche.
Merci à toi !
- En effet ce bouton n'est pas super évident, je vais voir ce que je peux faire
- La recherche/découverte est quelque-chose de très difficile sur un réseau décentralisé puisqu'il faut continuellement indexer et rapatrier des information du "réseau" sur le nœud sans pour autant tout récupérer. Ici cela doit être fait avec les contraintes d'XMPP également.
- Voici un des exemples de mon point précédent :D Comment proposer du contenu intéressant pour que l'utilisateur ne soit pas devant une interface vide au premier lancement sans pour autant avoir à le traquer ou le profiler dans les moindres détails.
- Basculer un article en "public" se fait en éditant chaque articles un par un.
- Merci :) Il est aussi possible d'ajouter une feuille de style CSS personnalisée dans la configuration pour customizer un peu le blog.
- Je vais y réfléchir
J'ai renégocié mon contrat de travail de 40h à 36h pour me dégager une journée toutes les deux semaines sur le projet. Cela est lié à la création de Movim Europe. L'idée étant d'essayer de rémunérer le travail fait sur Movim pendant cette journée afin de compléter la perte de salaire dû à la réduction du temps de travail. Pour l'instant c'est difficile mais je continue à chercher des entreprises et/ou structures qui seraient partantes pour supporter le développement du projet ou de certains fonctionnalités.
[^] # Re: Movim
Posté par edhelas (site web personnel) . En réponse à la dépêche Lettre d'information XMPP de juin 2021. Évalué à 5.
Ça arrive, ça arrive ;)
[^] # Re: Mon avis
Posté par edhelas (site web personnel) . En réponse au journal [HS] Parlons ZFE. Évalué à 6. Dernière modification le 15 juin 2021 à 13:11.
Le but c'est bien ça, réduire la voiture en Métropole.
Il faut bien comprendre l'ensemble. Les Métropoles n'ont pas la main là dessus, elles ne peuvent pas activement réduire la place de la voiture. La ZFE est un moyen détourné pour y arriver. C'est un secret de polichinelle ;)
Sur Grenoble, l'idée de la ZFE en discussion actuellement c'est d'interdire les thermiques horizon 2030. Donc on va parler avant tout de pollution de l'air, de particules, de bruit. Là où on a des normes à atteindre, et on va regarder comment y arriver. Sur Grenoble Alpes Métropole le but c'est de passer en dessous de la norme de l'OMS par exemple en terme de particules fines.
Bref, sur les projections que j'ai eu, c'est -20% du parc automobile qui sera autorisé à rouler en 2030. Sur ~200.000 véhicules particulier ça en retire quand même 40.000, ce n'est pas rien.
Après y'a toute la question du "report modal" qui se fera en gros sur 3 axes:
- L'achat de véhicules "propres" (et je garde les guillemets là)
- Le transport en commun
- La mobilité légère (marche, vélo, trottinette)
Pour les véhicules électriques, y'a plein de limites, le prix, l'infrastructure…. Sur Grenoble, le budget va être très limité pour le développement du transport en commun (il faudrait faire +30% d'ici 2030 pour contenir les effets de la ZFE, et il est plutôt en contraction aujourd'hui).
Du coup, ma vision c'est de faire de la mobilité légère, ça coute pas cher, c'est (plus) facile à déployer et financer et ça touche tout le monde.
(PS, je suis élu sur une commune de la Métropole de Grenoble).
# Peut être ça ?
Posté par edhelas (site web personnel) . En réponse au journal Ras le bol de ces moteurs de merde!. Évalué à 8.
Ce n'est pas lié au coup de gueule mais directement à ta recherche.
Je connais celui-là en C++ https://gitlab.linphone.org/BC/public/belcard :)
# La Caisse d'Épargne est à la ramasse
Posté par edhelas (site web personnel) . En réponse au journal Quand la Caisse d'Épargne force ses clients à réactiver des protocoles de sécurité obsolètes. Évalué à 10. Dernière modification le 19 juillet 2020 à 15:00.
La CE est complètement à la ramasse au niveau numérique.
Non respect du RGPD (scripts de tracking américains injectés dans l'espace privé, où il y a tous les détails bancaires!!!), script JS qui datent de 2010 avec le nom des développeurs et des console.log qui se baladent un peu partout.
Leur site ou des parties sont down très très souvent.
Leur service client est digne d'une banque des années 1995, à coup d'envois de mail avec des scan papier, des justifications foireuses et des process qui durent des mois (envoyer un chèque par la poste d'une CE à une autre CE d'un autre région au lieu de faire un virement).
Et pour couronner le tout, leurs frais sont exorbitant.
Bref, fuyez cette banque, au niveau national (j'ai changé de région plusieurs fois) !
J'avais fait un ptit thread sur Twitter à l'époque https://twitter.com/edhelas/status/1213031376393519104
# Firefox Lite sur Webkit
Posté par edhelas (site web personnel) . En réponse à la dépêche Firefox 65. Évalué à 4.
Je pense qu'il serait intéressant de préciser que Firefox Lite n'est disponible que dans certains pays sur le Play-Store (et pas en Europe de ce que j'ai vu) et qu'il utilise (pour l'instant) le moteur Webkit/Chrome disponible sur le téléphone.
[^] # Re: Et si le chiffrement devenait un standard du web ?
Posté par edhelas (site web personnel) . En réponse au journal ProtonMail (et les autres webmails) chiffrés e bout en bout ne sont pas fiables. Évalué à 2.
Le problème n'est pas d'intégrer ces fonctions nativement dans le navigateur ou non :)
Ces fonctions seront appelés par du JS qui sera chargé depuis le serveur web, il faut donc faire confiance au serveur, c'est bête pour un système de chiffrement bout en bout.
J'ai exactement le même soucis avec Movim (voir https://github.com/movim/movim/issues/63). La solution: chiffrer/déchiffrer les messages sur le serveur, donc ce n'est plus "bout en bout" mais bon ça revient au même que de chiffrer coté client avec du JS délivré depuis le serveur à ce niveau ;)
# Flemmardise
Posté par edhelas (site web personnel) . En réponse au lien Site des USA inaccessibles à cause du RGPD. Évalué à 4.
C'est le mot qui m'est venu à l'esprit en voyant ça.
Quand il s'agit de passer des dizaines d'heures pour être sûr que le trackeur remonte bien les données y'a pas de soucis, par contre pour virer tout ça et respecter un peu mieux les visiteurs tout de suite les budgets sont plus restreints.
# Anglicisme
Posté par edhelas (site web personnel) . En réponse au journal Pollution numérique. Évalué à 10.
"L'écologie digitale" c'est pour ceux qui ont la main verte ?
[^] # Re: dépêche en cours de rédaction
Posté par edhelas (site web personnel) . En réponse au message Comparatif réseaux sociaux. Évalué à 3.
Bah c'est juste que le protocole évolue, donc non il n'y a pas de "versions" mais plutôt qui implémente quel bout de version du protocole (c'est un peu pareil pour tous les autres protocoles en fait).
Movim a une liste de fonctionnalités a peu prêt stables depuis quelques années en effet mais l'interface et features évoluent quand même un peu mois après mois.
Tu n'as pas de compte Movim, c'est tout le concept, tu as un compte XMPP, Movim est un client XMPP orienté "social" où tu te connecte avec ton compte XMPP dessus, c'est tout. Donc oui, par extension il est compatible avec tous les autres clients XMPP déjà dans la nature :)
Définir "sécurisé", Movim se connecte aux serveurs XMPP en utilisant la norme SASL (définit dans XMPP), en forçant TLS (définit dans XMPP) et délivre aussi le contenu en HTTPS/WSS. Si tu parles de chiffrement de bout en bout, la réponse courte et non, la réponse longue se situe ici https://github.com/movim/movim/issues/63.
[^] # Re: dépêche en cours de rédaction
Posté par edhelas (site web personnel) . En réponse au message Comparatif réseaux sociaux. Évalué à 4.
Petite précision, pour pas se mélanger les pinceaux il va falloir être attentif à séparer proprement les "clients" des "réseaux".
Là ou un réseau centralisé comme Facebook est plutôt une solution tout en un Diaspora/Mastodon sont des solutions dont les "pods" hébergent aussi les comptes (c'est fédéré SUR les pods). Movim par exemple n'est qu'un client qui se connecte aux serveurs XMPP, les comptes ne sont pas sur les "pods" Movim mais sur les serveurs XMPP (plus à la manière des serveurs mails).
Je pense que c'est un détail qui a toute son importance.
[^] # Re: erreur de recruteur...
Posté par edhelas (site web personnel) . En réponse au journal Etude comparée de la popularité des langages de programmation sur linuxfr. Évalué à -5.
TapTempo? Ah c'est le truc qui SPAM LinuxFR en ce moment avec une méthodologie digne d'une publicité TV Mercurochrome. Désolé j'ai même pas regardé ce que c'était à part un machin qui voulait être écrit dans tous les langages.
# PHP…
Posté par edhelas (site web personnel) . En réponse au journal Etude comparée de la popularité des langages de programmation sur linuxfr. Évalué à 10.
J'ai vraiment du mal à justifier le bashing continuel envers PHP.
Le langage à certes des défauts mais depuis quelques années, avec des frameworks comme Laravel, les PSR, Composer, la documentation… franchement je commence à douter du sérieux de ces points de vue.
On peut aussi parler de l'environnement autour de JS? Du clivage de la communauté Python avec l'arrivée de Python 3.
Ah et aussi, c'est vendredi.
[^] # Re: Interopérabilité avec le Social Web ?
Posté par edhelas (site web personnel) . En réponse au journal Construisez un web décentralisé avec Salut à Toi et XMPP !. Évalué à 5.
Peut être que le soucis ici c'est le mot "Web". L'IETF (et XMPP) a vocation à standardiser des protocoles s'appliquant sur le réseau "Internet" alors que le W3C ne s'occupe principalement que ce qui touche au Web (donc, en gros, ce qui est construit sur HTTP).
Ce que j'ai répété pendant pas mal de temps dans mes conférences c'est que le "Web" et un sous-ensemble de "Internet" (HTTP repose sur TCP…).
Ce n'est pas un soucis en soit mais XMPP a vocation d'être accessible depuis un nombre d'application bien plus grandes "by design" (ce qui est aussi une critique qu'on lui apporte, les premiers pas sur XMPP sont plus difficiles que de jouer avec une simple API REST/JSON). Aussi essayer de transformer un protocole "connecté" (construit sur des flux) comme XMPP en protocole "déconnecté" (construit sur des requêtes) est bien plus simple que l'inverse.
[^] # Re: O'RLY
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim 0.12 — Lovejoy. Évalué à 3.
C'est assez rigolo qu'on trouve toujours quelqu'un pour critiquer un truc qui va pas :D
Les noms sont juste pris un peu au hasards dans la liste des comètes de Wikipedia D'ailleurs si tu souhaitais participer j'avais offert le choix à la communauté de trouver le nom de la release pour cette version https://nl.movim.eu/?node/pubsub.movim.eu/Movim/8d77979d-5485-4742-be83-b2669f58fbdd, vu que je n'ai pas eu de retours particulier j'ai choisit Lovejoy :) Le nom de la prochaine release reste à choisir ;)
[^] # Re: O'RLY
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim 0.12 — Lovejoy. Évalué à 6. Dernière modification le 03 novembre 2017 à 08:01.
Lovejoy c'est le nom d'une comète, comme pour les précédentes version depuis le passage à l'architecture temps-réel sur Movim (v0.11 – Tuttle, v0.10 – Holmes, v0.9 – Tchouri) ;)
Sinon la communauté (merci à eux) bosse sur des paquets pour les différentes distros (que ça soit pour les clients ou l'instance serveur).
Pour IRC ça va pas être simple de convaincre tout le monde mais movim.eu fournit un service pour se connecter au réseau très facilement, il se base sur l'excellent Biboumi (j'en parle ici d'ailleurs https://nl.movim.eu/?node/pubsub.movim.eu/Movim/8e3ab235-2de8-45c0-a3c7-62d6b40a9ef2).
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par edhelas (site web personnel) . En réponse à la dépêche Sortie du très attendu Prosody 0.10. Évalué à 6. Dernière modification le 14 octobre 2017 à 19:30.
En lançant une VM avec une Ubuntu et un client XMPP, puis ne me connectant en bureau à distance dessus j'arrive aussi à garder synchronisé mes messages tout le temps depuis partout! Génial!
[^] # Re: Conséquences ?
Posté par edhelas (site web personnel) . En réponse à la dépêche Sortie du très attendu Prosody 0.10. Évalué à 4.
Petite précision ici, Movim utilise bien la technologie WebSocket, mais coté navigateur, il se connecte à XMPP de façon standard (flux TCP avec TLS), rien de particulier n'est à configurer coté serveur pour qu'il fonctionne donc :)
[^] # Re: Ici aussi
Posté par edhelas (site web personnel) . En réponse au journal Pourquoi Jabber n'a pas plus de succès, même chez les informaticiens?. Évalué à 4.
Ça tombe bien, Jingle (la partie "visio/p2p") de XMPP est pleinement compatible avec WebRTC (il y a même des extensions spécialement écrites pour ça https://xmpp.org/extensions/xep-0343.html).
J'appelle ma moman de temps en temps en utilisant Movim et WebRTC entre nos deux comptes XMPP entre Chrome et Firefox, en 720p stéréo :)
[^] # Re: Parce que xmpp est un protocole
Posté par edhelas (site web personnel) . En réponse au journal Pourquoi Jabber n'a pas plus de succès, même chez les informaticiens?. Évalué à 9.
Ça marchera sûrement très bien en Chine
[^] # Re: Tentative de réponse
Posté par edhelas (site web personnel) . En réponse au journal Pourquoi Jabber n'a pas plus de succès, même chez les informaticiens?. Évalué à 10. Dernière modification le 29 septembre 2017 à 09:26.
On est d'accord, il y a eu un problème de calendrier. Et oui je te l'accorde, XMPP a mis du temps, beaucoup de temps, à se réveiller et enfin intégrer des fonctionnalités "modernes" de messagerie (partage de fichier, synchronisation des messages entre clients, gestion de l'historique, édition des messages publiés…).
Là où il faut faire attention, et c'est un soucis de rôle qui revient couramment, c'est que "XMPP" n'a pas comme vocation de proposer une solution clé-en-main avec services et clients aux internautes. XMPP est un protocole, au même niveau que SMTP/IMAP/POP ou HTTP le sont pour l'email et le Web. La XSF offre juste une solution de messagerie fédéré.
D'ailleurs c'est une question qui revient assez souvent au sein de la XSF (dont je suis moi même membre). La XSF doit elle pousser ou mettre en avant certains clients ou solutions implémentant XMPP au détriment des autres? Jusqu'ici la réponse a été de jouer la carte de la neutralité et de se cantonner à simplement "faire le job de standardisation".
Mais pour revenir à ta remarque le problème de XMPP a bien été un problème temporel. Aujourd'hui on ne se pose plus la question de savoir quel protocole utiliser pour l'email et le Web, car très tôt un standard a émergé (surtout pour l'email, pour le "Web" ça a été un peu plus compliqué, on se souvient de la bataille des navigateurs dans les années 90-début 2000). Les protocoles et standards gravitant autour de l'email et du Web ne sont pas parfaites, loin de là, mais ont comme avantage de proposer une vision unifiée forçant même les "géants" à se plier à eux (tu peux envoyer un email d'un compte Outlook à un compte Gmail depuis un iPhone sur un Thunderbird installé sur une distro Linux).
Pour la messagerie instantanée (et même le réseau social, ce que j'essaye de montrer avec Movim), malheureusement ce sont les outils qui sont venus avant les protocoles, si bien qu'aujourd'hui il devient difficile d'expliquer que non le problème ne vient pas d'XMPP en lui même, mais du fait qu'il lui faut se justifier face à des solutions centralisées, complète, faciles et intégrées aux interfaces et appareils des utilisateurs.
La question que je poserais donc serait de savoir pourquoi aujourd'hui nous n'avons pas encore de clients/serveurs/plateformes qui permettent d'offrir des solutions de messageries instantanées "modernes" et étant construit sur LE standard (norme IETF, au même titre que POP/IMAP/SMTP/HTTP… le sont) existant.
Cela est entrain de changer, on commence (enfin) à avoir des clients complets et accessibles (Conversations ou Dino https://github.com/dino/dino, voir même Movim (dont je suis le développeur principal)) et les serveurs rattrapent leurs retard rapidement sur ce qui a été standardisé ces dernières années.
Il y a quelques années (je bosse sur Movim depuis 9 ans maintenant) j'étais très dubitatif quand au fait que XMPP soit réellement un protocole viable pour construire une solution moderne de messagerie instantanée (et de réseautage social dans mon cas) mais en travaillant de consorts avec les autres projets (clients comme serveurs) implémentant XMPP, en ouvrant des bugs et discutant continuellement des implémentations et de l'amélioration du protocole j'ai la forte impression qu'on est entrain de transformer l’essai.
Les discussions au sein de la XSF se sont énormément fluidifiés ces derniers mois, les nouvelles fonctionnalités peuvent être standardisés et intégrés en l'espace de quelques mois (alors qu'il fallait bien souvent des années auparavant). Même si nous avons nos propres points de vues je suis heureux de voir qu'il y a des échanges continuels sur comment "bien faire" avant de simplement implémenter et de voir ensuite. Tout ça permet de proposer des serveurs et clients compatibles à leur sortie et d'avoir systématiquement une documentation de référence pour les futur entrants souhaitant communiquer avec les projets existants.
[^] # Re: Les informaticiens veulent pouvoir converser avec le reste du monde
Posté par edhelas (site web personnel) . En réponse au journal Pourquoi Jabber n'a pas plus de succès, même chez les informaticiens?. Évalué à 9.
Attention ne mélangeons pas tout.
XMPP n'a pas comme vocation à régler le problème de portabilité des comptes d'un serveur à un autre, qui est un problème plutôt complexe dans un réseau fédéré. Tu l'as dit toi même, pour l'email, ô combien c'était compliqué (je noterais tout de même que sur XMPP la liste de contacts est synchronisé avec le serveur ce qui facilite la transition).
Les réseaux centralisés n'amènent pas nom plus de solution à ce problème, au contraire, Facebook a t'il codé une solution pour permettre à ses utilisateur de migrer aisément sur Google+ ? Je ne le crois pas.
Nous pouvons tout de même noter que l'Europe est entrain de forcer la main à ces géants concernant la portabilité des données entre les plateformes (dans la section concernant la Data Portabity du tout récent GDPR https://en.wikipedia.org/wiki/General_Data_Protection_Regulation) et cela passera pas la mise en place et le développement d'outils prenant appuis sur des standards et protocoles existants.
L'histoire de l'identifiant unique "qui le suit toute sa vie" c'est une fausse solution, car elle amène également un grand nombre de soucis, notamment concernant la traçabilité et le recoupage. Il n'y a pas de solution miracle et XMPP à fait le choix d'être fédéré ("à la email") avec tous les défauts et contraintes inhérents à ce genre d'architecture.
L'un des gros points positifs, et tu l'as mentionné, d'un système centralisé c'est la découverte de contenu. Ou, dit d'une nouvelle façon, le "tu as déjà 9 contacts sur le réseau, on le sait car tout le monde est dans la même base de donnée". Cette fonctionnalité et ce qui marche le plus en ce moment, le dernier grand exemple étant WhatsApp: le recoupage et la découverte étant d'une simplicité absolue puisqu'il s'agit d'aspirer la liste de contacts (téléphonique) de l'utilisateur et de la comparer aux identifiants (numéros téléphoniques) des membres déjà inscrits.
Il n'y a pas de solution magique malheureusement, la découverte de contenu/contacts dans un réseau fédéré (ou pire décentralisé) est un problème très complexe. La solution la plus simple (et "scalable") que nous avons pour l'instant et d'indexer le réseau en un point: le moteur de recherche/annuaire (Google pour le Web, ThePirateBay pour le réseau Torrent…).
# Radio Paradise, une webradio qu'elle est bien
Posté par edhelas (site web personnel) . En réponse à la dépêche À la (re)découverte de Radio Paradise. Évalué à 3.
Merci à toi pour ce petit article pour faire découvrir cette merveilleuse radio sur LinuxFR.
Radio Paradise c'est depuis pas mal d'années déjà la webradio que j'écoute quand je ne sais pas quoi écouter dans mon audio-thèque MPD :) Elle a même un bouton assigné sur la télécommande IR de mon RPi (qui me sert de médiacenter à la maison).
Radio Paradise c'est bon, mangez-en.
[^] # Re: Installer son propre serveur ?
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim 0.11 — Tuttle. Évalué à 2.
C'est l'intérêt d'avoir ce genre d'infrastructure :) Au choix.
Il existe déjà plein d'instances déployées de part le monde ainsi que plusieurs serveurs XMPP compatibles mais rien ne t'empêche d'héberger toi même ton instance, voir ton serveur XMPP si tu le souhaites.
L'intérêt principal est souvent d'avoir le contrôle sur tes données.
[^] # Re: L'appli .rpm n'est pas disponible
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim 0.11 — Tuttle. Évalué à 3.
Corrigé ;)
Petite précision, le paquet RPM n'est qu'une conversion du paquet DEB en utilisant Alien. Je n'ai malheureusement pas le temps de packager proprement Movim sur toutes les distros mais je suit ouvert à toute aide extérieure sur ce genre de tâche.
[^] # Re: Petit retour utilisateur
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim 0.11 — Tuttle. Évalué à 7.
Merci à toi !
- En effet ce bouton n'est pas super évident, je vais voir ce que je peux faire
- La recherche/découverte est quelque-chose de très difficile sur un réseau décentralisé puisqu'il faut continuellement indexer et rapatrier des information du "réseau" sur le nœud sans pour autant tout récupérer. Ici cela doit être fait avec les contraintes d'XMPP également.
- Voici un des exemples de mon point précédent :D Comment proposer du contenu intéressant pour que l'utilisateur ne soit pas devant une interface vide au premier lancement sans pour autant avoir à le traquer ou le profiler dans les moindres détails.
- Basculer un article en "public" se fait en éditant chaque articles un par un.
- Merci :) Il est aussi possible d'ajouter une feuille de style CSS personnalisée dans la configuration pour customizer un peu le blog.
- Je vais y réfléchir
J'ai renégocié mon contrat de travail de 40h à 36h pour me dégager une journée toutes les deux semaines sur le projet. Cela est lié à la création de Movim Europe. L'idée étant d'essayer de rémunérer le travail fait sur Movim pendant cette journée afin de compléter la perte de salaire dû à la réduction du temps de travail. Pour l'instant c'est difficile mais je continue à chercher des entreprises et/ou structures qui seraient partantes pour supporter le développement du projet ou de certains fonctionnalités.