Goffi a écrit 1524 commentaires

Déjà bravo pour cette version et le travail qui va avec.

Est-ce qu'il y a un endroit où on peut suivre l'évolution de l'API ? Je fais parti de ceux intéressés.

D'autre part en Python je vois principalement 2 modules : diaspy et federation. Si je comprends bien le premier utilise l'API (il y en a une provisoire donc ?) et le second est une implémentation du protocole, c'est bien ça ? Est-ce que l'évolution de l'API risque de casser diaspy ?

Bonne continuation.

toi tu vas te faire engueuler ! ;)

Sinon merci pour le partage, même si ça ne me sera pas utile à titre personnel.

C'est pas vim, c'est ton terminal ça , appuie sur Ctrl+Q pour débloquer.

stty -ixoff -ixon avant de lancer Vim et ça va rouler.

C'est un projet très intéressant, et un que je n'ai pas encore testé moi même bien que j'en entende parler depuis plusieurs années. Je viens de regarder la démo vite fait, c'est complet.

Au sujet de l'identité nomade, je me pose plusieurs questions :

• comment contacte-t-on quelqu'un qui peut être sur n'importe quel serveur ? Il y a un hash ou quelque chose compliqué, ou une astuce ?
• je suppose que oui mais je demande par acquis de conscience : les données sont chiffrées en cas de duplication ? Si je mets une identité sur plusieurs serveurs, ça ne veut pas dire que tous les admins de ces serveurs ont accès à mon nom, ma liste de contacts, mes messages, etc ?
• du coup si les admins n'ont pas accès (ce que je suppose), est-il possible de dire qu'on ne veut pas de quelqu'un ?
• quid de la place aussi, est-ce que dupliquer une identité ça prend beaucoup de place ? Si j'ai des albums photos, des vidéos, etc., est-ce qu'ils me suivent ?

D'autre part, est-ce qu'on a une idée du nombre d'utilisateurs ? Est-ce qu'il y a un modèle économique ? Comment c'est développé (prise de décisions) et par qui ?

Bon courage, il faudra que je prenne le temps de regarder ça de plus près un jour.

Il y a le bot officiel de SàT, Sabot, qui affiche les commits. En fait c'est juste un script sh qui est appelé par un hook Mercurial. J'avais expliqué le fonctionnement dans un épisode de parlons XMPP, avec un autre bot fait avec SleekXMPP.

Il va probablement bientôt afficher les tickets également.

Je soupçonne que beaucoup de monde ici a au moins fait un bot IRC, c'est un classique chez les développeurs.

Mon message n'était absolument pas dirigé contre toi, je trouve ta dépêche très bien, et la comparaison est un sujet compliqué, parce qu'il faut bien connaître les 2 environnements (d'ailleurs je ne connais pas suffisamment bien Matrix pour faire une comparaison technique poussée, j'espère avoir le temps un jour de regarder de plus près). Et c'est un projet qui fait parler de lui, c'est une très bonne chose de faire des dépêches travaillées sur le sujet, donc merci :)

Cependant même après ton message, il me semble que la différence fondamentale est bien que Matrix intègre (kitchen sink…) à la base beaucoup plus que XMPP ? Et du coup est clairement moins flexible au niveau des extensions ?
Cela me rappelle un peu le débat micro-noyau et noyau monolithique.

Je pense que le débat micro-noyau/monolithique est plutôt applicable au débat décentralisé client/server contre 100% P2P, parce qu'au niveau des fonctionnalités XMPP est justement proche du fonctionnement de Linux, avec un noyau dur (les RFCs), et des modules dynamiques (les extensions).

Au niveau des différence fondamentales, il n'y en a pas tant que ça, le système de réplication est parfaitement adaptable à XMPP. XMPP utilise XML ce qui est critiqué par certains (à tort à mon avis) sur TCP (ou autre), Matrix utilise HTTP qui a sa lourdeur.
XMPP a des recommandations par années (les « compliance suite »), qui permet d'avoir une base commune pour les clients « modernes ».

Par contre sur le plan politique (c'est pour ça que j'ai dis que j'attendais de voir), XMPP a beaucoup d'entreprises/associations et de particuliers impliqués (certains avec un but lucratif d'autre non), un système (par parfait certes) d'élection, de « council » (conseil), et des règles écrites (par exemple, il ne peut pas y avoir plus d'un certain pourcentage de membres de la même entreprise, je n'ai pas le chiffre exact en tête).

Matrix souhaite un chemin similaire d'après ce que j'ai compris, mais est développé par des membres issus d'une même entreprise, avec un financement privé, une influence et une prise de décision très concentrée, et un but probablement lucratif.

Pour moi la différence se situe plutôt là que sur le plan technique.

En tout cas j'ai jeté un oeil vite fait, et rien ne semble avoir bougé sur leur FAQ au niveau de XMPP depuis un moment. Un point que je ne comprends pas très bien, c'est pourquoi tu te refuses à proposer un changement (pull request) pour leur FAQ ?

À l'époque je n'avais pas (et ne voulais pas) de compte Github. Entre temps j'ai dû en faire un pour mon travail salarié, et je me suis résigné à en faire un autre pour contribuer à titre personnel à des projets dessus (que j'ai appelé goffi_contrib pour bien spécifier que c'était uniquement pour la contribution).

Je pense aussi que je suis trop biaisé pour modifier ça moi même, et que c'est à eux de le faire de toute façon. De la même façon je ne touche pas à la page Wikipédia de SàT parce que Wikipédia demande aux gens impliqués de ne pas le faire, et pourtant je regrette que cette page est quasiment vide et n'est pas à jour.

Et aussi (surtout), je n'ai pas le temps pour ce genre de choses annexe, même si au final écrire des commentaires comme ici est aussi long, mais j'ai vraiment un rythme de fou.

C'est je trouve assez constructif de leur part, d'essayer d'expliquer les différences avec XMPP. Et c'est risqué car du coup ils s'exposent aux critiques si ce n'est pas parfait (seuls ceux qui ne font rien ne font jamais d'erreurs).

Ah mais ça n'est pas ça le mal, c'est tout à fait légitime de faire ça, même de critiquer.

Ce que je reproche c'est la manière dont ça a été fait, et dans la FAQ les réponses sont mises, mais toujours avec une formulation qui fait douter.

Plutôt que de supprimer l'affirmation fausse que XMPP n'est pas « web-friendly », ils mettent une remarque entre parenthèses, dire que la synchronisation d'historique ou les passerelles sont des « second class citizen feature » (fonctionnalités de seconde zone) est un mensonge, c'est plein de « apparently », « questionable », il y a des guillemets autour de « fine » quand la communauté répond que ça marche avec un satellite à très faible débit.

Sans oublier la phrase « The whole subject of XMPP vs Matrix seems to bring out the worst in people » (« le sujet de XMPP contre Matrix semble faire sortir le pire côté des gens ») qui laisse entendre que c'est la communauté XMPP qui a agit avec agressivité (il y a eu en effet quelques réponses sèches à la longue).

Salut,

bon malgré mes vacances je reste un peu en ligne :). Merci pour cette dépêche détaillée.

Je vais donner mon point de vue d'un dév très impliqué dans XMPP, comme les lecteurs réguliers de ce site le savent peut-être.

Côté technique, je pense que le projet est intéressant, mais pas exceptionnel. La réplication des données risque de poser un problème de mise à l'échelle (ce qui semble se confirmer en lisant cette dépêche et par des échos que j'ai eu de gens ayant des difficultés à joindre des gros salons sur des petites machines type Raspberry Pi), et je ne vois rien qui ne pourrait être implémenté avec XMPP.

Mais côté forme, c'est un des rares, et je pense même le seul projet contre lequel j'ai une dent, et je pousse pourtant à la coopération entre les projets libres. La raison est simple, pour se faire connaître, et dès le début (j'ai connu Matrix à leur présentation lors de leur premier FOSDEM) ils ont cherché à taper sur XMPP et sa communauté. Attention, je n'ai rien contre les critiques techniques (j'en fais moi-même, XMPP a ses défauts comme tout), mais là on a vraiment eu le sentiment qu'il fallait essayer d'appuyer sur la tête du voisin pour nager à la surface, et c'est le seul projet qui m'a donné ce sentiment malgré les tonnes de projets existants, ce qui a eu des effets jusqu'ici même. Et avec leur budget marketing qui semble très important, cela a provoqué une ambiance délétère dont on se serait bien passé.

Maintenant que ce projet commence à être connu, la situation s'est nettement améliorée, mais ce n'est pas tout à fait fini pour autant, leur FAQ en particulier, qui a pourtant déjà été complétée suite à une réponse de la communauté, reste un cas d'école de mauvaise foi. Je l'ai déjà fait remarquer, on m'a promis de le corriger, mais force est de constater que c'est toujours là.

Sur le plan politique (qu'on oublie un peu trop souvent), j'attends de voir ce que ça va donner.

Enfin pour la comparaison avec XMPP, il est absolument ridicule de comparer les fonctionnalités avec la base RFC de XMPP. les RFCs sont volontairement très réduites et minimales, et toutes les extensions (et non la plupart) sont optionnelles. C'est une force et certainement pas une faiblesse. XMPP a bien plus de fonctionnalités que Matrix.

XMPP est capable de négocier les fonctionnalités disponibles et de s'adapter. Il est évident qu'un client XMPP qui se concentre sur, disons, le partage de fichier, n'a pas forcément besoin des fonctionnalités de blogage.

Aujourd'hui le nombre de serveurs et de clients est réduit pour Matrix, ou du moins se base sur un nombre réduit d'implémentations (je n'ai pas vérifié, mais je ne serais pas étonné que les clients bureau/téléphone soient des ports de la version web à coups d'Electron ou similaire). On en reparlera si le succès est là et que les implémentations se multiplient, il y aura inévitablement des problèmes de compatibilité et de fonctionnalités non implémentées ou implémentées un peu différemment.

Bref, encore une fois je n'ai rien contre la technologie elle-même, et je souhaite qu'on puisse communiquer entre les différents protocoles, mais diplomatiquement ils ont très mal commencé et ça a l'air de se tasser (même si on attend toujours pour la FAQ). À mon sens (forcément biaisé), ça n'apporte strictement rien par rapport à XMPP, c'est un énorme désavantage de ne pas avoir le système d'extensions, et cela semble lourd à l'usage (à voir ce que ça va donner avec Dentrite). Par contre leur logiciel a l'air léché ce qui est une bonne chose et sans doute la raison du succès (avec la com). Ceci dit, une dizaine de dév à plein temps (jusqu'ici) c'est énorme, et ça explique le résultat rapide.

En comparaison, un projet comme Movim, certes plus ancien, a été fait par principalement une seule personne sur son temps libre, et je n'ai pas l'impression qu'il a beaucoup à envier.

s/donc 4 amis/dont 4 amis/
s/voir que XMPP et actif/voir que XMPP est actif/
s/mais ça cruellement de bras/mais ça manque cruellement de bras/

Et sûrement d'autres que j'ai laissé passé :(

Non, et je vois très rarement des réactions « directes » (à part des vagues d'inscriptions suite à des versions majeures et des publications ici, ou celles qu'il y a eu sur Framablog ou Reflets, mais qui s’essoufflent vite).

C'est pareil dans les événements : il y a toujours un enthousiasme certain quand t'es sur place, t'as des tas de gens qui te disent qu'ils vont t'aider, contribuer, ou faire ci ou ça, et au final ça n'arrive jamais ou presque.

Mais par contre je vois clairement les évolutions avec le temps : à force d'en parler, le projet est connu dans la communauté francophone. À ma première conf aux JDLL il y a 6 ans il y avait 4 ou 5 personnes. À mes dernières confs aux RMLL il y a 2 ans, il y avait salle comble, et les gens disent presque tout le temps avoir entendu parler du projet désormais dans le monde francophone. Par contre j'ai fait une conférence en République Tchèque l'année dernière, il y avait… 4 ou 5 personnes (donc 4 amis :) ).

Les articles sur XMPP ont été utiles également, il y a notamment eu un regain d'intérêt pour l’authentification XMPP (et le composant de Chteufleur< a été écrit suite à ça), et ça a incité du monde à utiliser XMPP pour des projets (au moins jnanar< qui a fait une interface ad-hoc pour son robot). Et surtout ça permet de voir que XMPP et actif, et à ceux qui s'y intéressent de comprendre un peu mieux comment ça marche, ce qui était le but.

En ce qui concerne cette émission en particulier, je ne crois pas que l'audience de Radio Prague soit faramineuse, mais elle est très accessible et je m'en servirai comme référence pour expliquer le projet à ceux qui le souhaitent.

SàT reste encore confidentiel, et à la limite c'est pas plus mal de rester sous les radars tant que la version grand public n'est pas sortie (mais ça cruellement de bras, je suis le seul à développer à l'heure actuelle), par contre une fois celle-ci en place, j'espère et je pense que ça va décoller assez rapidement.

J'utilise Linphone avec mon opérateur mobile qui me permet de passer les appels ou SMS en SIP, c'est très pratique, la version Android marche vraiment bien, et elle est plus intuitive que la version bureau (je suis en 3.11.1, la version Arch n'a pas encore l'air à jour). De ceux que j'ai essayé, c'est de loin celui qui marche le mieux avec SIP.
Bref, merci pour cet outil bien utile.

Salut,

déjà bravo pour ce super boulot, j'utilise Grammalecte de temps en temps (par exemple en relecture de longues dépêches, notamment avec le greffon Vim), et c'est un super outil.
La dépêche a beau parler de grammaire, elle m'a paru très intéressante (et a dû te prendre un temps fou à écrire).

J'ai quelques questions/remarques:

1. Sur un plan pratique, tu maintiens désormais 2 moteurs (Python et Javascript) si j'ai bien compris, même 3 vu que Firefox et Thunderbird ont un moteur différent. C'est gérable sur le long terme ? Il n'y a pas un risque d'abandon de la version Python ?
2. Comment est-il possible d'utiliser Grammalecte depuis un logiciel tiers, au hasard en Python ? Comme une bibliothèque ? La dernière campagne parlait d'un mode serveur si mes souvenirs sont bons, est-ce la façon de faire ? Peut-on trouver de la documentation sur le sujet ?
3. Question liée à la précédence : il y a-t-il moyen d'utiliser des fonctions internes, je pense en particulier à la possibilité de retrouver la forme canonique d'un mot ? Ça pourrait m'être très utile.
4. Pour ma part je préférerais avoir un mode strict qui refuse les néologismes et autres bizarreries sur le web justement (pour choisir moi même ce que je souhaite garder ou non), est-ce qu'il serait possible de faire un mode plus ou moins laxiste (une sorte de liste déroulante avec un niveau de ce qui est accepté) ?

Encore bravo et merci pour ce projet.

En effet, j'ai cru que c'était un des dévs qui parlait (et il n'y a pas que le dernier « nous », les 2 sont trompeurs). Je ne vois nulle part une mention que c'est une traduction, du coup ça serait bien de la mettre.

Merci pour l'article en tout cas.

Cher EauChaude (j'ai fait une recherche entre-temps, mais pas sur Google).

J'ai quand même un sacré doute (en plus sa justifierais d'utiliser google en lieu et place des moteurs de recherche décentralisé qui doivent polluer beaucoup plus)

C'est des chiffres qui sont discutés en effet, mais on retrouve rapidement ce genre d'article qui est dans le même ordre d'idée (mais qui a 8 ans tout de même, ça a pu évoluer beaucoup). D'après l'article la recherche est effectuée dans plusieurs datacenters à la fois et le résultat trouvé en premier et retourné, ça sous-entend un certain gaspillage qu'on n'aurait pas forcément sur des moteurs décentralisés (enfin c'est très complexe comme question de toute façon).

 Je n'ai pas compris non plus se qu'ils entendent par lowtech.

je ne veux pas parler à la place des auteurs, mais on peut imaginer des choses plus proche de l'open hardware et du D.I.Y., plus facilement réparable et qu'on ne doit pas changer tous les 6 mois, par opposition a la grosse industrialisation high tech, très complexe, et de plus en plus difficile voire impossible à réparer nous même.

Et quelles sont ses activités?

des vidéos de chats qui se cassent la gueule, des gif animés pour un oui ou un non, des algos pour te faire rester le maximum de temps, des vidéos qui se lancent toutes seules, regarder les infos toutes les 5 min, la culture de l'instantanée, le self branding, etc.

Sans forcément tout foutre à la poubelle, il y a certainement moyen de réduire et de repenser notre utilisation des outils informatiques.

 Les objets connecté et la domotique c'est le futur.

Ça c'est ta vision, pas forcément celle de tout le monde. Pour ma part par exemple même si j'apprécie de l'automatisation, je ne suis pas du toute enchanté à l'idée d'avoir des espions en puissance partout, et que des algos décident, analysent et gèrent tout pour moi.

 Vu la complexité de mise en place des logiciels, et l'austérité des interfaces (autant utilisateur qu'admin) de certains, l'auto hébergement n'est pas près d'arriver dans les maisons.

L'auto-hébergement n'est pas forcément souhaitable. Des gestions communautaires et locales comme ce qu'on voit avec le super boulot des CHATONS actuellement me semble une solution beaucoup plus faisable et pérenne.

A moins de faire des composants visible (et réparable) par un humain sans 1G €, ou des bio composants autorégénérable, se serait plus "simple" de faire des ordinateurs facilement recyclable (fondable + tri automatique et récupération de tout les matériaux) puis recréable à coups d'imprimante 3D.

Ben justement des outils « recréable à coups d'imprimante 3D » on est en plein dans le réparable. C'est ce qu'on voit avec par exemple les Fairphone, et c'est une très bonne chose.

En tout cas c'est un très bon article, on a eu une discussion sur le sujet sur Seenthis également

C'est intéressant. Ça se rapproche en certains points de subuser dont j'avais parlé ici l'année dernière : https://linuxfr.org/news/subuser-une-sur-couche-a-docker .

Est-ce que vous envisagez ou est-il déjà possible d'avoir un système de permissions similaire ? Et serait-il envisageable de vous rapprocher de ce projet ?

Il y a clairement des choses qui se font autour des containers, mais du point de vue utilisateur on a un peu l'impression que ça part dans tous les sens (Docker, lxc, systemd-nspawn, subuser, flatpack, guix, et probablement d'autres). C'est autant de technologies à apprendre, chacune ayant ses avantages/inconvénients, mais du coup on en perd un peu son latin.

Ce sont les 2 seuls qui gèrent le blogage à l'heure actuelle, et Libervia n'est pas encore en version stable (ça sera le cas pour la prochaine version), donc Movim est un bon choix oui.

Pour de la messagerie simple il y a d'autres choix : Candy ou Converse.js par exemple. Il y a eu Kaiwa un moment mais il n'est plus maintenu.

On en a une en développement également pour bureau/Android pour SàT, cf. ce journal. S'il y a des fonctionnalités que vous aimeriez y voir, n'hésitez pas à demander/proposer.

pourquoi ne ramènes tu pas des amis sur https://linuxfr.org/redaction pour montrer l'avancement de SàT ? c'est de la rédaction collaborative, pas de l'instantané (dont l'historique n'est pas forcément disponible).

Je fais des dépêches pour les grosses sorties, entre 2 versions je fais plutôt des journaux, je ne veux pas non plus faire du matraquage.

La deuxième chose c'est qu'écrire une dépêche comme celles cités c'est du boulot, bien une soirée entre la rédaction, la vérification des points techniques ou dates, la relecture, les captures d'écrans éventuelles, etc. Une rédaction collective ça aide beaucoup surtout sur la forme et l'orthographe, mais si le contenu de base ne peux pas être écrit à plusieurs (ce qui est le cas pour une dépêche sur SàT vu qu'il n'y a que ceux qui y bossent qui connaissent les détails), ça reste un gros boulot pour le ou les rédacteurs principaux.

J'ai repris un travail salarié depuis plus d'un an (il y a d'ailleurs à journal à ce sujet), et avec le développement de SàT c'est comme-ci j'avais 2 boulots, et je suis donc obligé de réduire les choses qui me prennent du temps (rédaction d'articles, participation aux événements du Libre, j'ai même pris du retard sur l'intégration de contributions : quelqu'un a contribué une traduction du contrat social en italien qui n'est toujours pas dans les dépôts).

Donc ces derniers temps j'ai vraiment voulu me concentrer sur le code, mais je vais certainement bientôt faire des articles vu les grosses nouveautés et l'orientation prise (notamment Libervia devient un framework web).

Oui c'est ce que j'avais expliqué dans ce journal et sa suite.

Le problème est que Prosody ne gère pas la persistance pour PEP/PubSub, ce qui est nécessaire aux clients gérant le microblogage (sans ça tous les billets publiés disparaissent au redémarrage du serveur). À ça 2 solutions : se concentrer sur un serveur qui le gère voire développer le nécessaire pour ce serveur – ce que Jappix et Movim ont choisi – ou développer un composant qui fait ce qu'on veut ; c'est ce qu'on a fait avec SàT et SàT PubSub. Cette dernière solution a l'avantage de ne pas êtres limité à un serveur spécifique, et de toujours fonctionner si le serveur n'est plus développé comme c'est le cas ici.

Bref, pour régler le problème de Yunohost (serveur plus maintenu), il y a 2 options:

• passer sur un serveur qui gère ce qu'il faut à l'heure actuelle, ce qui est le cas notamment de Ejabberd, ou OpenFire, et probablement Mongoose qui est un fork de Ejabberd (et je n'ai pas utilisé Tigase ou les autres, donc à voir). Il faut alors bien choisir pour pas se retrouver dans le même situation dans quelques années (a priori avec ces 3 là on est tranquille), et espérer que les futures fonctionnalités qui peuvent être intéressantes seront développées rapidement (ce qui est moins sûr).

• passer sur Prosody dont Metronome était un fork, donc configuration et extensions similaires (ainsi que ressources nécessaires, administration, etc). Il faut alors soit implémenter la persistance pour PubSub (il y a eu un début de travail par Link Mauve je ne sais pas où sans en est), soit utiliser notre composant. Notre composant est utilisé notamment sur notre serveur de démo à https://libervia.org et sur mon blog à https://www.goffi.org et il fonctionne également avec Ejabberd.

À savoir aussi que dans le cas de Movim, il manque une fonctionnalité dans notre composant, la gestion des présences et de +notify, qui ne demande pas un travail fou (je pense pouvoir l'implémenter en 1 week-end) mais qui n'est pas indispensable pour SàT et a donc été mis de côté (par manque de temps). Si on arrive à se mettre à plein temps un jour ça ira évidemment beaucoup plus vite (j'en profite pour laisser un lien vers liberapay tant qu'à faire).

Donc oui ça n'est pas si simple, PubSub est un gros morceau qui est indispensable pour nombre de fonctionnalités avancées (c'est à la base de MIX – anciennement appelé MUC 2 – qui est le futur de la messagerie par exemple), mais c'est aussi un développement nécessaire pour l'avenir. Et dans le cas de Prosody c'est pratiquement bon (travail de Link Mauve et/ou notre composant, dans les 2 cas il manque un chouïa pour que ça soit complet, et les contributions sont bienvenues).

Ça dépend des clients et serveurs que tu utilises et de leur configuration, il faut voir les docs correspondantes. En général un client va t'afficher un message d'avertissement si un certificat est auto-signé mais se connecter quand même si tu confirmes, et un serveur va utiliser une vérification par DNS en méthode de secours, sauf si c'est configuré autrement.

Pour Prosody par exemple, c'est expliqué sur cette page: http://prosody.im/doc/s2s#security

Salut,

petite remarque en passant, je vois Jappix et Metronome en captures d'écran, mais aucun des 2 n'est maintenu, du coup il faudrait vraiment songer à les remplacer.

Je crois que Movim est déjà empaqueté pour Yunohost, et pour SàT la prochaine version sera stable et du coup si quelqu'un veut nous filer un coup de main pour l'empaqueter ça serait pas mal :).

Côté serveur, Metronome étant un fork de Prosody, il devrait être assez simple de passer sur ce dernier (et des serveurs comme Ejabberd et probablement les autres ont des outils de transition de toute façon).

J'ai utilisé pendant un moment Aptosid qui est surtout intéressante à l'installation (installation de SID directement), et également pour son forum qui permet d'anticiper/trouver de l'aide pour les problèmes après des mises à jour : http://aptosid.com/index.php?name=PNphpBB2&file=viewforum&f=3&sid=e8fcdae185d9730c83d52ad50f9d5fcf

Ça vaut le coup d'y jeter un œil.

Là ça fait un peu plus d'un an que je me suis mis à Arch, c'est une distro qui a bonne réputation et c'est mérité elle est vraiment chouette, et j'ai très peu voire pas d'ennuis avec (et son wiki est excellent). Ça peut être utile de coupler à un système de containeurs (lxc, Docker ou autre) pour certains cas, notamment quand on veut des versions précises de logiciels ou une distro particulière.

Ce n'est pas la première fois que j'en entends parler, et c'est vraiment intéressant, merci pour la dépêche.

Comment ça marche pour le fichier de configuration unique ? Le coup des paquets, des locales, etc pas de soucis. Mais pour les fichiers de confs dans les différents formats, il faut bien que ça passe par /etc/ non ? Si la conf est générée depuis le fichier unique, comment est faite la correspondance (mapping) ? Est-ce qu'il n'y a pas un risque qu'une option ne soit pas disponible ? Et la doc du coup est totalement différente non ?

exemple concret : comment je change mon port ssh ? Comment je décide de quels services démarrent avec un fichier unique ?

Je m'étais intéressé à Org-mode et étant utilisateur de Vim (même si j'ai utilisé Emacs par le passé), j'ai regardé de ce côté.

Le plugin vim-orgmode qui semble être le plus complet et maintenu s'installe de manière inhabituelle (un script à exécuter), du coup je m'inquiète des mise à jours, et il y a une palanquée d'autres plugins recommandés pour l'utilisation, ce qui me gène aussi (autant de plugins à maintenir et qui peuvent être gênants d'une manière ou d'une autre). J'ai déjà un vim personnalisé (comme beaucoup de monde), et j'aimerais ne pas avoir trop de choses qui viennent polluer ma config.

Du coup je me demande si des gens ici l'ont essayé et si ça vaut le coup d'insister. Et aussi est-ce que des gens connaissant bien la version Emacs ont un retour sur la version Vim (très en dessous, comparable, meilleur ?).

J'entends parler de org-mode depuis tellement longtemps que je me dis que ça doit valoir le coup d'essayer.

Écoute, quelqu'un de vraiment très très proche de moi que je ne balancerai pas choisit ses voitures sur leur design et leur couleur. Si je parle de consommation d'essence, accessoires, performance, ben je parle dans le vide. Tout le monde ne s'intéresse pas aux voitures. Et quand on ne s'y intéresse pas, il ne reste que la perception basique: beau, confortable, etc.

Oui enfin c'est avec ce genre de raisonnement que les gens votent pour des candidats beaux, confortables, etc.
(le parallèle est très douteux, mais je le trouvais amusant).

Plus sérieusement je n'ai jamais dit que beau et simple à utiliser n'étaient pas de bonnes choses, c'est même une question d'accessibilité (pour la simplicité tout du moins).
Ce qui me chagrine, c'est que dans tout l'enthousiasme actuel, et qui concerne quand même une population à dominante technique (on parle des lecteurs de hacker news, numérama, etc tout de même, même s'il y a eu quelques article après coup sur des médias généralistes), personne ne semble s’inquiéter des questions politiques autour. Et là je cite parce que c'est flagrant, mais c'est le cas à chaque truc à la mode, les seuls critères sont est-ce que c'est libre ? Est-ce que c'est décentralisé ? Est-ce qu'il y a du monde ? est-ce que c'est beau ? Est-ce que c'est chiffré ? C'est déjà une bonne base, mais je regrette que ça s'arrête là.

Et ça va sans doute te paraître bizarre vu mon historique, mais je me moque du protocole en dessous sur le plan purement technique, par contre je m'inquiète qu'il soit standard (et donc documenté), et non contrôlé par une grosse entité, ce qui est le cas ici).

Ceci mis de côté, je suis très content que les projecteurs soient sur un projet libre, et que ça amène un peu du monde sur GNU Social, et je compte utiliser si ça tient sur la durée (je le fais déjà d'ailleurs, et j'étais sur GNU Social avant), voire faire une passerelle XMPP.

Salut,

m'intéressant de près à ce genre de logiciels, j'ai testé un peu.

Déjà ça n'est pas nouveau, ça se base sur un protocole existant et documenté (ostatus/GNU Social), ce qui est un très bon point. À l'usage je n'aime pas trop (je trouve ça trop compliqué pour un utilisateur lambda, et ça manque de fonctionnalités pour un utilisateur avancé), mais les gens s'y retrouvent parce que ça ressemble à TweetDeck (ce qui ne fonctionne qu'avec un public restreint). C'est propre et y'a des petits animations agréables.

Je trouve le besoin de créer un nouveau vocabulaire pour se différencier à chaque fois non seulement ridicule mais aussi perturbant (« pouet » ou « toot » pour billet/publication)

C'est toujours une bonne chose d'avoir un peu d'attention sur un projet libre., même si je trouve que l'excitation est un peu exagérée (faire peur à Twitter c'est juste bon pour les titres chocs, faut avoir un minimum le sens des proportions du moins à l'heure actuelle).

Après ce que je regrette, comme pratiquement à chaque fois, c'est qu'il y ait une excitation sur une simple base visuelle/technique (de loin, on évalue principalement le côté libre et décentralisé), sans s’inquiéter de toute la partie politiques (gouvernance, fonctionnalités et leur disposition, public présent, etc).

J'ai développé un peu ce point sur seenthis: https://seenthis.net/messages/585190#message586271

À l'heure actuelle je ne crois pas trop à son succès sur le long terme, si ce n'est avec le réseau GNU Social déjà existant (ce qui est déjà pas mal).