Goffi a écrit 1556 commentaires

Oui ça n'est pas un problème, et on fournira le paquet APK séparément de toute façon.

Honte à moi, j'ai oublié de remercier les relecteurs et correcteurs ! Je me rattrape donc: merci à Nÿco, palm123, souliane, Ontologia, ZeroHeure, Nils Ratusznik. ainsi qu'à Xavier Claude pour la modération.

Tu viens de trouver la formule pour estimer le développement de GNU Hurd

J'ai de plus en plus de mal avec les financements participatifs concernant du développement logiciel. Je n'ai presque que des expériences qui n'aboutissent pas ou alors complètement hors délais (mailpie, lavabit, lolix, etc.). La seule exception que j'ai en tête, c'est gcompris.

C'est extrêmement difficile d'évaluer un temps de développement, surtout quand on est tout seul et qu'on (re)part de rien. En plus sur les campagnes de financement il vaut mieux demander pas trop et donner des délais pas trop éloignés. Y'en a plus d'un qui se sont cassés les dents. Les temps de dév explosent vite parce qu'on pensait utiliser telle ou telle bibliothèque mais on se rend compte qu'il faut l'adapter, ou qu'elle va pas du tout (et c'est pas toujours identifiable avant de développer), ou parce qu'un truc très actif au moment de commencer est mort en cours de route (ça c'est du vécu), parce que tel problème est plus difficile à résoudre qu'on ne l'avait imaginé, etc.

Un des premiers conseils qu'on m'a donné quand j'ai commencé à travailler était pour estimer le temps de développement de quelque chose : « estime le temps qu'il te faut en comptant large, et multiplie ça au moins par 2 ». Je pense ne pas être le seul à avoir eu ce genre de conseil, et avec l'expérience il est tout à fait approprié.

Dans le cas particulier de Lolix, je ne sais pas trop où ça en est, mais on peut difficilement râler vu le boulot qu'il y a eu avant la campagne, pendant des années, et vu que ça a permis à nombre d'en nous de trouver un travail à un moment ou un autre.

Ce qui semble plus te gêner est de le faire sous forme ludique à la manière d'un jeu, non ?

Oui, c'est un point qui me gêne, et de manière générale j'ai l'impression que c'est une chose qu'on voit de plus en plus souvent. J'ai rien contre le divertissement bien sûr, mais si ça devient le but (ou le moyen) de tout ça me pose problème.

Mais encore une fois c'est un ressenti, et ce n'est qu'un des points que j'ai mentionné, et pas le plus important.

Non l'indice de sécurité je pense que c'est une bonne idée aussi (je le dis dans mon premier commentaire d'ailleurs), et elle pourrait même être reprise ailleurs.

C'est son utilisation sous forme de jeu qui me gêne, et c'est ce que j'en avais compris à la conf d'il y a 2 ans: comme s'il était nécessaire de rendre la chose ludique pour qu'elle soit comprise et utilisée.

En voyant cette conf et ce qu'il se disait à l'époque, je voyais ça comme un gros jeu ou il faut avoir le plus de points (et de mémoire le mot « gamification » avait d'ailleurs été utilisé dans la conf). Mais comme j'ai dit c'est flou, donc difficile à juger.

Je te défie de me démontrer que j'ai dit ça.

considérer qu'un utilisateur doit faire un effort intellectuel et qu'il ne faut pas enrober, et qu'il faut qu'il en chier pour mériter.

Tu considères que faire un effort intellectuel c'est en chier. Une personne incapable d'allumer son cerveau, c'est la définition d'un con.

Comme il faut un effort intellectuel pour comprendre que les gens ne souhaitent pas entrer dans ton éducation forcée, et comme il faut faire un effort intellectuel pour ne pas transformer "non souhait d'apprendre quand ce n'est pas utile" en "con".

Qui t'as dit qu'il y avait un non souhait d'apprendre (sources ?) ? Et d'où ça n'est pas utile ?

Comme toi tu peux comprendre plein de chose mais ne le fait pas (je le sais, car c'est techniquement impossible de tout comprendre). […] J'imagine que soit tu ne prends jamais l'avion, soit tu sais comment ça fonctionne, à la pièce près (ce que même les gens concevant les avions ne savent pas, car ils sont spécialisés).

Ça c'était facile à voir venir avec tes gros sabots. Donc:

1) je n'ai jamais dit que j'étais contre la simplification, c'est la mise en jeu systématique que je critique

2) je n'ai jamais dit non plus qu'il fallait tout comprendre tout le fonctionnement interne. Mais bon comme d'hab tu prends la partie de la phrase qui t'intéresses, tu l'entends comme ça t'arrange, et après tu enrobe ça d'attaques directes.

3) je ne connais pas tous les détails du fonctionnement de ma voiture, mais je sais comment et pourquoi il faut mettre de l'huile et de l'eau, et ce que c'est que faire une vidange. Si je vois un garagiste me faire une vidange pour 1000 €, je sais qu'il se fout de moi. Ici c'est pareil, un utilisateur doit savoir qu'un message passe en clair la plupart du temps, je ne lui demande pas de savoir ce que c'est que SMTP ou IMAP. Et le chiffrement est une notion que j'estime importante à comprendre, là encore je ne dis pas qu'il faut connaître les formules mathématique, mais savoir que ça sert à fermer l'enveloppe c'est utile oui. Et je ne pense pas que la mise en jeu soit la bonne façon d'apprendre. Peut-être que je me trompe, c'est un ressenti, mais j'attends toujours des arguments pour en discuter.

4) je sais que tu fais ça parce que ça t'amuses et que tu ne cherches qu'à susciter de la réaction (et surtout pas à discuter), mais la mise en jeu n'était qu'une partie anecdotique du message qui dit pourquoi je suis dubitatif avec CaliOpen pour le moment.

Il peut. Mais il n'a pas le temps de tout comprendre.

Ce serait bien d'arrêter de parler à la place des autres. Et je vais te donner un scoop: je suis un utilisateur. Et c'est rigolo, je ne me reconnais pas du tout dans ton discours.

Bref, on voit juste des gens passionnés par un domaine et qui pensent que tous les autres devraient connaitre leur domaine, alors qu'ils font exactement ce qu'ils critiquent pour d'autres domaines (car c'est impossible de faire comme tu dis pour tous les domaines).

Que tu fasses exprès ou pas d'être à côté de la plaque c'est une chose, mais ça serait bien que t'évites de parler à ma place. D'une je n'ai pas critiqué l'utilisateur (qui n'est pas un « il », mais un « nous ») mais la mise en jeu par les concepteurs (et j'ai dit que je regardais de travers), et de deux je n'applique pas ça qu'à l'informatique. J'entends certains gens dire que le cinéma n'est que pour se divertir et se vider la tête, et je ne pense pas comme ça. Et je n'ai jamais dit non plus que tous les autres devaient connaître le domaine ; pour reprendre tes mots: « Je te défie de me démontrer que j'ai dit ça. ».

ben désolé, mais les utilisateurs ont vraiment d'autres choses à faire, surtout quand ils savent que les développeur peuvent faire des choses plus simples.

Tu devrais faire de la télé-politique tu sais, tu as déjà l'arrogance et la façon de parler à la place des autres (« les français veulent ci », « les français pensent ça »). Bon il faut encore travailler un peu le style par contre.

Tu considères que l'homme est au service de la machine, d'autres considèrent que la machine est au service de l'homme.

Non justement, je considère que l'homme est capable de comprendre son outil, et que c'est nécessaire s'il ne veut pas être à son service. À ne plus rien comprendre ou savoir faire soi même, on en perd le contrôle: du courriel envoyé en clair sans le savoir à la voiture et son moteur caché qui se fait contrôler à distance.

Mais ça il faut faire un effort intellectuel pour le comprendre.

les gens voulant que ça soit différent n'ayant pas de considération pour les utilsateurs (bon, la, il y a aussi framasoft qui aurait compris.

Oui bien sûr, pas manichéen pour un sou avec ça ! Donc soit on prend l'utilisateur pour un con, soit on n'a pas de considération pour lui, superbe.

Je viens de voir un nouvel article d'explication, https://reflets.info/re-expliquer-caliopen-encore/ et qui correspond à ce que j'avais compris. C'est un peu dommage de réinventer la roue… Enfin bonne chance tout de même au projet.

Je suis de plus ou moins près la plupart des outils ou projets d'outils de communication, et il faut dire que celui-ci est probablement un des plus flous et donc des plus difficiles à juger.

Il y a de bonnes idées, enfin surtout une: un indicateur de la qualité de la protection.
J'ai vu la conférence il y a 2 ans à PSES (les choses ont probablement évolué depuis), et il y a 2 choses que je regarde particulièrement de travers: la mise en jeu (« gamification ») et le « label » lié à la charte mentionnée ici.

La mise en jeu je trouve ça assez symptomatique de la société actuelle: le tout divertissement, considérer qu'un utilisateur est incapable d'effort intellectuel si on ne le prend pas par la main et qu'on n'enrobe pas le tout de sucre.

Le label me pose de nombreux problèmes: comment la charte est écrite ? Qui décide de son attribution ? Il y aura(it) une assoce derrière CaliOpen: comment est-elle organisée ? Qui prend les décisions ? Quid d'une instance qui ne signe pas la charte ? Et des autres pays ?

Disons que je serais moins sceptique si c'était plus clair, il faut voir ce que ça va devenir.

Il y a du monde sur le projet (7 personnes c'est une (très) grosse équipe pour un projet libre), et c'est probablement le plus visible en France (il a même été mentionné dans le diplo !), et cela peut donner quelque chose.

Toujours est-il qu'on n'a que très peu d'infos dessus, et que je pense que c'est une erreur de partir sur du multi-protocoles, quand XMPP répond largement à tout ce que je vois pour le moment.

ah oui en effet, et Twitter ne m'intéresse pas, c'est plus pour les futurs réseaux que tu pourrais ajouter que je disais tout ça.

Enfin bref, bon continuation en tout cas :)

Oui je comprends, les passerelles de chat à l'époque où c'était à la mode (y'a entre 10 et 5 ans je dirais) étaient souvent incomplètes, mal maintenues et difficiles à mettre à jour. Mais c'est un point qui j'espère va aller mieux avec la nouvelle génération qui vient.

Pour IRC par exemple, biboumi est une bonne passerelle: facile à installer et utiliser, elle est très complète (à comparer à la passerelle Spectrum qui est trop compliquée à installer/utiliser, ou à celle de jabberfr qui n'est pas non plus le top pour IRC).

Je vois que ton code est en Python, et nous on a l'intention de travailler sur les passerelles d'ici 2 à 3 mois. Ce qui serait pas mal, c'est de séparer la partie interface (la ligne de commande) de la partie qui gère la communication avec les réseaux que tu veux gérer, et on pourrait réutiliser ça derrière pour faire des passerelles. En fait ça pourrait même être une idée que tu te rapproches de weboob vu qu'ils font justement une abstaction des sites webs.

Ce sont juste des pistes pour regrouper les efforts, je comprends aussi si tu veux rester sur ton outil qui fait ce que tu veux.

Salut à Toi est multi-interfaces, et l'une d'elle, jp, est dédié à la ligne de commande.

Si j'ai bien compris, ton outil récupère stdin, et le met en forme/l'envoi sur un réseau (ici Twitter).

jp gère aussi les pipes, et peut le transformer stdin en diverses choses, par exemple en flux de données brutes (comme expliqué ici) ou comme message de chat (par exemple j'envoie souvent un bout de code à mon correspondant en le sélectionnant dans vim en mode visuel et en tapant « :w !jp message mon_correspondant@son_serveur.tld ».

Nous avons travaillé beaucoup sur le (micro)blogging, et la prochaine version permettra de rédiger un message dans vim dans la syntaxe de ton choix (par exemple markdown) et de l'envoyer en tant que message de blog (la syntaxe n'est pas encore définie, mais ça pourrait être « :w !jp blog send »).

D'un autre côté, XMPP permet de gérer des passerelles, en gros une passerelle se contente de convertir une syntaxe de réseau extérieur en XMPP (et vice versa). Du coup ça donnerait quelque chose comme ça (attention les yeux):

+---+         +--------+         +-----------+         +----------+         +------------+
|VIM|  ====>  |jp (SàT)|  ====>  |Server XMPP|  ====>  |Passerelle|  ====>  |autre réseau|
+---+         +--------+         +-----------+         +----------+         +------------+

Alors dans l'immédiat, ça n'apporterait pas grand chose par rapport à ton projet (le choix de la syntaxe tout de même) et pour ton utilisation.

Mais ça aurait quand même certains intérêts:

• la passerelle est côté serveur, si X utilisateurs sont sur le serveur et utilisent l'outil, et que ça casse du jour au lendemain (l'autre réseau change de protocole), il suffit de mettre à jour une fois la passerelle, et y'a rien à faire pour l'utilisateur (à part attendre et râler).

• la passerelle servira pour tous les projets XMPP qui parlent (micro)blogging, soit à ce jour Jappix, Movim et SàT.

• la passerelle ne servira pas que dans la cadre de la rédaction d'un message, tu pourras aussi si tu le souhaites recevoir les messages de ce réseau extérieur et en envoyer depuis le client XMPP de ton choix.

• comme la passerelle servira à plusieurs projets et à plus de cas, le jour où t'en as assez et que t'arrêtes le développement, y'a de fortes chances que quelqu'un le reprenne.

C'est peut-être un poil plus complexe que ce que tu voulais faire (parce qu'il faut la couche XMPP en plus), mais je cherche à pousser au maximum l'utilisation d'XMPP pour qu'on que ça soit réutilisable, et vu qu'on est en plein dans la création d'un outil similaire (sauf que nous on ne fera pas de passerelles pour des réseaux non libres), je me suis dis que ça peut valoir le coup de regrouper les efforts.

Salut,

ben en fait on fait exactement la même chose avec SàT et son interface ligne de commande (pour le chat uniquement pour le moment, mais on c'est prévu pour le blogging dans la version à venir), en passant par XMPP (et j'utilise également depuis vim avec « :w ! »

C'est probablement un peu tard maintenant que t'as bossé sur ton outil, mais ça te dirait pas de développer des passerelles XMPP ? Ça a de nombreux avantages, et en particulier pas besoin de faire les mise à jour côté client, c'est la partie serveur qui s'en occupe… Et puis ça servirait à tout les projets XMPP, en particulier Jappix, Movim et SàT.

Enfin dans tous les cas merci pour le partage :)

officiellement sur un site je n'en connais pas, mais ponctuellement on utilise souvent etherpad/framapad pour rédiger des articles ou faire des corrections.

Oui j'ai vu qu'il y avait des choses qui se faisaient en XMPP, mais il va falloir encore un peu d'eau sous les ponts je pense. Ce qu'il y a, c'est qu'on a aussi une grosses base de code qu'on ne va pas pouvoir migrer comme ça, et que toute façon une migration devra se prévoir. Je n'exclus pas de passer un jour à Asyncio, ou au moins de l'utiliser en même temps.

Nécessaire peut-être pas, mais elle facilite le passage pour Twisted (il me semble avoir vu une longue discussion sur le sujet, mais je ne retrouve pas là).

Je ne veux pas spécialement faire de la programmation réseau en Python 3, je veux porter mon projet en Python 3, et il est déjà entièrement basé sur Twisted. Je suis très content avec Twisted, c'est juste qu'on commence à avoir besoin de bosser en Python 3 (il y a des projets Python 3 qu'on veut utiliser, et côté Debian il est question de passer à Python 3 pour la prochaine version).

Asyncio est très intéressant, et je m'y pencherai sérieusement quand on sera à Python 3, mais ce n'est pas encore comparable à Twisted, il n'y a pas que le côté asynchrone, y'a tout le framework qui va avec.

Merci pour cette dépêche, je ne savais même pas qu'on pouvait exécuter une application complète depuis un zip.

Est-ce que la PEP 461 ne va pas débloquer Twisted ? Il me semble que c'était un des points majeurs qui posait problème. Ils ont déjà porté plus de la moitié du code, et surtout trial est porté depuis peu sous Python 3, peut-on espérer voir enfin un port complet en 2016 ? J'espère surtout que toute la hiérarchie twisted.words va suivre rapidement.

J'ai hâte !

Salut,

je vois à peine ton message (je rentre tout juste de la fête de l'huma). Alors de base il n'y a pas de redondance (c'est ton service pubsub qui gère les sauvegardes), mais rien n'empêche d'en faire une, il suffit qu'un autre service pubsub s'abonne à un nœud (et qu'ils soit autorisé à le lire) pour qu'il soit synchronisé. Après ce qu'il serait bien, c'est d'avoir une liste de nœuds à voir en cas de problème sur le principal, une XEP pourrait se charger de ça.

De toute façon c'est une question qu'il faudra aborder un jour où l'autre: si tu as un boîtier à la maison (comme celui qu'on veut faire), il serait sage d'avoir une sauvegarde extérieur en cas de vol, perte, ou problème sérieux.

Ah ben oui ils ont le droit, c'est eux la société privée en question.

arf, désolé pour les fautes, je faisais autre chose en même temps, et c'est trop tard pour modifier. version corrigée:

Il y a un mot, probablement le plus important à connaître, qui passe bien c'est « jid ». Il porte un peu à confusion parce qu'il y a encore « jabber » dedans (et ça ne changera pas). Je dis que j'utilise « XMPP », mais uniquement quand je fais des confs techniques, que je suis aux RMLL ou à PSES, sinon j'évite de plus en plus d'utiliser ce terme technique.

plutôt que dire « c'est quoi ton adresse courriel ? » on peut/pourra dire « c'est quoi ton jid ? ». On pourra même appeler ça courriel dans le futur, peu importe que ça ne soit plus du SMTP en dessous.

Mais je suis globalement d'accord avec ce que tu dis.

On avait discuté avec Nyco et Edhelas de l'utilisation du logo XMPP comme symbole de compatibilité (voire de pouvoir cliquer dessus et de voir une liste de projets compatibles, un peu comme les « ring » internet des années 90).

C'est un vieux débat sans vraiment de réponse. Je ne pense pas que c'est le nom qui va donner plus de succès à XMPP (le succès est déjà là depuis longtemps), mais plutôt des clients, et mon petit doigt me dit que c'est en bonne voie de ce côté ;)

XMPP intéresse surtout les développeurs, on peut le comparer à HTTP sur ce plan (c'est pas joli non plus HTTP, mais ça ne choque personne). Le seul intérêt que je vois, c'est pour dire que c'est compatible. C'est vrai que ça me gêne qu'on parle de réseau « Movim », « Jappix » ou « Libervia » quand c'est le même protocole derrière et que c'est compatible. Là le logo peut aider. Et puis après tout y'a tout un tas de noms imbitables qui passent très bien dans le grand public comme « USB », « VGA » ou « DVD ».

Et sinon il y a déjà une XEP qui commence à dater et qui indique les extensions à supporter pour un client moderne (la XEP-0312), il est question d'en refaire une à jour avec les différents type d'utilisation principaux (discussion, vidéo, transfert de fichier, etc).

Les notifications sont envoyées avec des <message/>, de type j'envoie et j'oublie, donc tu ne sais pas si la notification a échoué (enfin un serveur peut te retourner une erreur, mais ça n'est pas obligatoire, contrairement à <iq/> ou tu dois avoir une réponse, cf l'épisode 2). Donc sur le coup tu ne t'en rendras pas compte (en pratique si un message échoue, c'est très probablement que ta connexion a échoué, et donc tu vas t'en rendre compte tôt ou tard).

Par contre quand tu récupères les nouveaux items à la connexion suivante, tu rattrapes l'info perdue. Dans une implémentation PubSub basique, tu ne peux que tout récupérer, ou les X derniers items. Dans ce cas il faudra comparer ton dernier id pour voir si tu n'a rien raté, c'est pas super. Par contre tu as des extensions comme « PubSub Since » (XEP-0312) ou Message Archive Management (XEP-0313) qui permettent de récupérer les items depuis ta dernière déconnexion, c'est plus efficace.

Il y a guerre des religions sur le sujet, certains disent que Jabber c'est le réseau fédéré et XMPP le protocole.

A priori le nom « jabber » appartient désormais à une société privée, et il n'est pas libre de l'utiliser, aussi il faut parler d'XMPP. Les logiciels qui utilisaient jabber avant peuvent le garder pour des raisons historiques (cas de ejabberd par exemple), mais les nouveaux ne doivent pas. J'ai vu quelqu'un se faire refuser l'ajout de son logiciel sur la liste officielle parce qu'il y avait « jabber » dedans (de mémoire il a été ajouté après renommage).

Donc voilà, pour ma part je ne parle que de XMPP, sauf à l'oral si je vois que la personne ne connaît pas, parfois Jabber parle plus.

Je n'ai pas encore vu passer de protoXEP (nom d'une XEP avant sa publication par la XSF) sur le sujet, mais il y a eu plusieurs discussions à le sujet, notamment au dernier XMPP summit.

L'idée c'est d'avoir système compatible avec l'actuel, mais de corriger ses quelques défauts, notamment:

• pouvoir se connecter avec un même pseudo depuis un même jid avec sur plusieurs clients/appareils. C'est le plus gros point à corriger

• j'ai cru comprendre qu'il était question de passer les présences à la trappe: elles génèrent un gros trafic, et des extensions comme les états de discussions (chat states, XEP-0085) permettent de savoir si quelqu'un prête attention ou pas à la conversation. Pour ma part je ne suis pas 100% convaincu par ça, pouvoir dire explicitement qu'on est occupé est intéressant à mon avis.

• il a été question sur la liste standard@ de supprimer les salons anonymes et semi anonymes (voir l'épisode 4 pour des explications). L'argument est qu'on peut désormais utiliser une connexion temporaire si on veut être anonyme (pas au sens Tor mais au sens on ne dévoile pas son jid), et que connaître le jid permet de s'assurer qu'on parle à la même personne d'une fois sur l'autre.

• permettre de faire une couche de compatibilité est un point essentiel.

Et sinon je viens de me souvenir que j'avais déjà répondu à cette question, tu peux lire ce commentaire.