Goffi a écrit 1555 commentaires

Je suis étonné de ne pas avoir vu cette info alors je l'ajoute :

Si toi ou quelqu'un·e d'autre a des choses à ajouter dans la newsletter/infolettre, on peut soit faire une PR rédigée sur https://github.com/xsf/xmpp.org/milestone/3, soit indiquer l'info (et si possible rédiger quelque chose) sur le pad à https://yopad.eu/p/xmpp-newsletter-365days, soit en parler sur la salon MUC commteam@muc.xmpp.org.

Et j'en profite pour dire merci à la commteam et aux traducteurs·rices/relecteurs·rices pour leur boulot régulier et très apprécié.

utilisateur de vim depuis très longtemps, j'ai voulu mettre un peu à jour les plugins il y a quelques mois.

Je n'en avais pas spécialement ressenti le besoin jusqu'ici parce que je fais majoritairement du Python et que c'est un langage suffisamment peu verbeux pour qu'il n'y ait pas vraiment besoin de complétion de partout (j'avais quand même YouCompleteMe et UltiSnips depuis quelques années).

Je suis passé à neovim (principalement parce que ça m'a permis de scripter facilement un changement de thème quand je passe sur un écran e-ink) et j'ai installé coc. C'est vraiment pas mal, faut reconnaître que le Language Server Protocol a permis de regrouper les efforts, et que ça apporte un certain confort.

Tout ça pour dire que sans utiliser directement Visual Studio, les outils que j'utilise en héritent en partie (mais sont libres).

Ah oui je me sens un peu con du coup !

Faut pas, l'informatique c'est très large et personne n'est omniscient.

Content d'avoir aidé.

Salut,

Hors, lorsqu'on remplace simplement le contenu d'une balise html avec le texte saisi, les retours chariot passent naturellement à la trappe. Pas terrible d'avoir toute la description d'un film condensée sur une seul longue ligne !

j'ai peut-être mal compris le problème mais les retours à la ligne peuvent être gardés avec la propriété CSS white-space (cf. https://developer.mozilla.org/fr/docs/Web/CSS/white-space), en utilisant la valeur pre-line par exemple.

Bon après ton projet semble gérer des langages de balisage, donc c'est plus poussé que ça.

C'est toujours le nom de l'association loi 1901. Ça m'a chagriné aussi, mais en dehors du monde francophone ça posait problème (à prononcer, ou des gens pensaient que c'était réservé aux français). C'était aussi l'occasion de simplifier les noms, des noms pour chaque frontaux ça perdait tout le monde, y compris des utilisateurs de la communauté XMPP.

Pour la petite histoire, quand on a créé l'association, on a envoyé un courriel aux bérus en disant en gros « on utilise ce nom informellement depuis quelques années, maintenant on aimerait créer une assoce et on aimerait vérifier que ça ne vous pose pas de problème avant ». Ils (PariA au nom du groupe) nous ont répondu très gentiment, en disant non seulement qu'ils connaissaient déjà (tombés dessus avec le nom) mais aussi que ça avait l'air dans l'esprit, ça nous avait bien fait plaisir.

Merci beaucoup à l'équipe de Linuxfr.org ainsi qu'aux éditions Eyrolles et ENI.

Linuxfr fait partie de ma vie numérique depuis de nombreuses années et il a su traverser les années en s'améliorant tout en gardant son esprit d'origine. C'est un gros boulot de maintenir et modérer un tel site (sans compter les mises en demeures, spams et autres trolls), et c'est vraiment apprécié. Bravo à vous, et bonne continuation.

Merci ! Oui NLnet est une sacrée bouffée d'oxygène, ils aident beaucoup le libre, et plusieurs projets XMPP en bénéficient ou en ont bénéficié. C'est un gros projet qu'ils ont validé pour Libervia, et ça devrait aider au développement d'XMPP en général et ne pas seulement profiter à ce client.

Bonjour,

j'ai répondu il y a peu de temps, vous avez dû recevoir. Et merci beaucoup !

Ah oui en effet, désolé. J'ai adapté la note de version de mon blog où les personnes qui suivent sont supposées connaître le projet, mais il serait judicieux de rapidement le présenter ici en intro.

Est-ce qu'un modérateur ou une modératrice peut ajouter le petit texte suivant dans le chapeau ? Merci :)

Libervia est un client XMPP multi-interfaces qui ne se concentre pas uniquement sur la messagerie instantanée et intègre des fonctionnalités telles que le blogage, le partage de fichiers, les albums photos, ou encore la gestion d'événements. Il a été mentionné plusieurs fois sur ce site sous son ancien nom « Salut à Toi ».

J'ai aussi noté une typo :

Le site officiel a été mise mis à jour

Merci, ainsi que pour la modération rapide.

C'est exact, si on n'est pas en UTC c'est toujours bien de préciser la TZ.

Même en UTC, dans ce cas il faut ajouter un Z à la fin. La raison est que tu montres que la zone est spécifiée, autrement tu ne peux pas savoir si c'est UTC ou un indicateur de fuseau manquant.

Tiens petite note rigolote au passage, UTC est un mélange de l'abréviation comme elle devrait être en anglais (CUT pour « coordinated universal time ») est en français (TUC pour « temps universel coordonné »), histoire de mettre tout le monde d'accord (enfin au moins les anglophones et francophones).

Ça dépend du contexte. Quand t'es à l'école par exemple, et que t'as des devoirs à rendre, c'est souvent quelques jours après. L'année t'es censé déjà la connaître, et le mois probablement aussi, du coup l'info qui t'intéresse le plus c'est le numéro du jour, et c'est ce qui est mis en premier. Ça ne t'arrive jamais d'omettre l'année pour un RDV par exemple ? Genre « RDV le 30/11 » ? Ou tout simplement « On se voit le 4 » ou même « on se voit samedi » ?

Si tu veux classer des fichiers sur plusieurs années, là oui la date au format ISO est nettement plus intéressante. Et si tu veux vraiment être « civilisé » comme tu dis, tu spécifies le fuseau horaire et pas juste yyyy-mm-dd HH:MM:SS ;)

Le truc que j'ai toujours trouvé complètement illogique par contre, c'est les dates format É-U : mois/jour/année . Si quelqu'un a une explication rationnelle à ça, je suis preneur.

oui AngularJS, désolé (en plus je connaissais la subtilité).

edit: on utilise aussi typescript depuis un bon moment dans le frontend.

Alors je ne suis pas la personne la mieux placée pour en parler parce que je fais principalement du backend et je touche assez rarement au frontend.

D'un côté React a été introduit par l'équipe qui a commencé à travailler sur le planning (composant additionnel mentionné dans la dépêche), et de l'autre Angular a vue une nouvelle version qui cassait beaucoup de choses. Il y a eu des réunions (VueJS a aussi été mentionné à l'époque), et après avoir discuté les avis des un·e·s et des autres, il a été décidé de passer à React parce que c'est un cadriciel très utilisé, avec un développement soutenu et qu'on ne risque pas de voir disparaître de jour au lendemain. React est aussi très rapide, et c'est important pour nous parce qu'on a beaucoup d'éléments qui peuvent être affichées sur une page.

D'autre part, et c'est sans doute le plus important, les dévs frontends sont contents avec.

Ça serait sans doute utilisable, mais au prix de pas mal d'adaptations. Par exemple, dans Superdesk tu as plutôt un·e rédacteur·ice qui écrit l'article, qui est relu et commenté/corrigé par quelqu'un d'autre. Dans DLFP, tu as une édition collaborative où n'importe qui avec un compte peut modifier l'article en cours, c'est différent et ça demanderait du développement spécifique.

Il n'y a pas de tchat/tribune dans SD (ça a été discuté, mais personne n'en a actuellement vraiment besoin, il y a souvent d'autres messageries déjà en place).

Superdesk est vraiment un outil conçu pour le monde professionnel, avec beaucoup d'options, un vocabulaire très spécifique, les articles ont généralement nombre de métadonnées (parfois remplies automatiquement, parfois manuellement), etc. DLFP nécessite quelque chose de plus simple et accessible.

Sans doute que Publisher pourrait être utilisé pour développer une interface utilisateur similaire au DLFP qu'on connaît, mais là encore ça demanderait du développement.

Bref, DLFP est un site spécialisé avec une interface particulière. On est dans un site destiné au grand public (même si c'est un public plutôt technique) et où tout le monde peut rédiger un article ; il faut donc une interface accessible et relativement simple, avec juste des permissions privilégiés pour les modérateurs et admins.

Superdesk est un site destiné à un milieu professionnel, l'interface est nettement plus complexe (bien qu'accessible, je pense que l'interface est bien faite, mais ça reste un outil pro qui demande de pouvoir faire beaucoup de choses). Ce sont plutôt des articles qu'une équipe bien définie peut rédiger (plus potentiellement des rédacteurs externes), avec d'autres personnes pour les relectures et corrections, et un système de revue pour la validation.

Tout est toujours possible si on y consacre le temps et les moyens nécessaire, mais a priori SD n'est pas l'outil le plus adapté pour un site comme DLFP.

Il me semble que le moteur actuel fonctionne bien, pourquoi changer ?

Est-ce qu’il est possible de chiffrer les données sur le serveur pour les chiffrer / déchiffrer dans le navigateur ?

Pour être sûr de bien comprendre : tu parles de chiffrement de bout en bout ? En gros un article serait entièrement chiffré dans le navigateur, et le serveur ne ferait que du stockage de blob ? Si c'est bien ça ça n'est pas possible à l'heure actuelle, mais cette approche aurait beaucoup de problèmes : on perd la recherche (qui est un outil indispensable pour des journalistes) vu que le serveur ne voir plus rien et ne peut donc plus indexer (et pas question de faire de la recherche dans le navigateur, il faudrait toutes les archives, c'est potentiellement énorme), et il faudrait partager des clefs entre collaborateurs, ce qui complique beaucoup. Je ne dis pas que c'est impossible, il faudrait voir un cas d'usage très précis et peser les conséquences. Il serait sans doute possible de ne chiffrer qu'une partie des données, et en garder quelques-unes pour l'indexation.

Si tu parles de chiffrement au repos, on utilise MongoDB/ElasticSearch, donc les méthodes compatibles avec sont disponibles.

Quels sont les langages utilisés pour l’implémentation.

Le backend est en Python (avec Eve, Flask, Celery) et le frontend est, sans surprise, en JavaScript (initialement avec Angular, c'est désormais du React et les parties encore en Angular sont portées petit à petit).

Merci pour les encouragements, je ferai suivre à l'équipe.

Ça me semble un peu trop pour un particulier, c'est un logiciel vraiment fait pour le travail en équipe, et je pense qu'il y a des solutions plus simples pour faire un blog ou similaire. Pour un journaliste indépendant ça pourrait être intéressant ne serait-ce que pour la gestion des sources et des archives.

Pour des petites structures par contre, surtout tout ce qui s'occupe de la rédaction régulière d'articles, là ça commence à être plus adapté.

Évidemment dès qu'on tape dans le journalisme, même pour des organisations petites, là on est en plein dans le cœur de métier.

L'installation n'est pas très compliquée avec docker, pour voir si ça correspond à un cas d'usage, le mieux est encore d'essayer.

Non non je suis là, vraiment je ne disparais pas, et j'ai dis que j'allais compléter Superdesk dans les semaines à venir il n'y a pas si longtemps ! J'ai juste un emploi du temps très, très chargé, mais il n'y a pas de date de péremption sur les dépêches en cours non ?

Kivy idem, il n'y pas tant de boulot pour la finir, il ne faut pas la supprimer. Quand on m'a relancé en fin d'année dernière, j'ai dis que ces 2 dépêches seraient finies dans l'année, ça laisse encore près de 2 mois :)

Je comprends que c'est frustrant de voir ces dépêches qui mettent du temps, j'en suis désolé, c'est vraiment difficile de composer avec tout, mais elles ne sont pas oubliées (en tout cas pas celles que j'ai initiées).

jingle qui est resté en draft pendant des annees,

Le nom draft, hérité de l'IETF, portait à confusion et a récemment été renommé en stable justement pour éviter ce genre de mauvaise compréhension.

Jitsi qui est une des solutions les plus populaires pour la visioconférence de nos jours est basée sur XMPP/Jingle, et c'est ce qui est actuellement utilisé dans Matrix aussi pour les visioconférences (à plus de 2).

La bibliothèque libwebrtc de Google qui est utilisé par la grande majorité des implémentations de webrtc et de tout ce qui fait de la visioconférence hérite en partie de libjingle (Jingle est originairement une contribution de Google à XMPP).

Bref je n'ai pas franchement l'impression que Jingle soit un raté.

XMPP gère des appareils multiples (via les ressources) depuis le début, et pendant très, très longtemps ça n'était pas possible sur les autres messageries (Skype te déconnectait par exemple).

L'historique quand tu n'es pas là (ou "backlog") c'est sur XMPP que je l'ai vu en premier. Après sa s'est modernisé avec MAM et Carbon pour suivre l'évolution des usages (et c'est ce qui fait la force de XMPP et que c'est toujours aujourd'hui le protocole le plus adapté à mon avis: il est extensible et s'adapte aux évolutions).

Mais oui il y a eu des erreurs, comme des clients pas très facile à aborder (Psi notamment qui est je pense le premier client que j'ai utilisé n'est pas très ergonomique, et la découverte de services était présenté de manière trop brute aux utilisateurs).

D'un autre côté, il faut aussi garder en tête qu'il y a eu des tâtonnements partout et que les interfaces clonés qu'on a aujourd'hui sont le fruit de ces essais (et des gros budgets de recherche en UI/UX dans les grosses boîtes).

XMPP a mis du temps à s'adapter aux téléphones (un peu), mais ça reste raisonnable quand on pense au peu de ressources par rapport aux gros acteurs (beaucoup de clients sont développés par une poignet de développeur·se·s, voir un·e seul·e).

Côté serveurs il y a un peu plus de moyens chez certains (EjabberD par exemple), et c'est pas pour rien que c'est à la base de gros acteurs comme Whatsapp, de nombreux jeux, ou les notifications push d'Apple.

En tout cas, si toutes les critiques à faire c'est sur des problèmes réglés depuis des années, c'est que ça ne va pas si mal.

Pour vim : il est indispensable de remapper certaines touches, mais le wiki bépo explique très bien comment faire.

Le seul bémol, ce sont les raccourcis claviers pas toujours adaptés et qu'il faut réajuster…C'est même parfaitement chiant. Par exemple, sur Blender, il y a littéralement des centaines de raccourcis claviers et c'est une gymnastique des doigts ou un travail de recomposition qui sont obligatoires…

C'est exactement ce qui me pose problème. Au final je pense opter pour un clavier EurKey, ce qui ne m'empêchera pas de taper en azerty à l'aveugle si besoin, ou d’apprendre le bépo/béop toujours à l'aveugle (certain·e·s recommandes d'ailleurs d'apprendre le bépo à l'aveugle).

Merci pour les réponses.

Oui ce n'est pas tant une question de vitesse de frappe que de confort pour le développement. Pour les détails je travaille de la maison et je peux utiliser mon ordi perso, le changement de clavier n'est donc pas nécessaire. Je peux taper à l'aveugle, en fait je me pose la question actuellement parce que j'envisage de faire graver une disposition sur un clavier d'ordinateur portable. Si je me déplace j'ai généralement ma machine, et de toute façon ce n'est pas parce que je tape dans telle disposition que je vais oublier les autres.

Pour le moment j'hésite principalement entre l'AZERTY AFNOR et le EurKey, je suis en train de tester ce dernier. A priori je m'en sort pas trop mal avec (je connais déjà à peu près le qwerty), la transition devrait se faire facilement.

Le béop programmeur m'intéresse beaucoup aussi, mais je n'ai pas le temps de m'y investir actuellement, et je veux éviter d'avoir à passer des heures à reconfigurer mes logiciels pour qu'ils soient utilisables.

Pour celles et ceux qui ont connu ce dessin animé/manga, Bébel a servi de modèle au personnage.

Outre les classiques qu'on lit partout en ce moment, il est aussi à revoir dans Week-end à Zuydcoot qui raconte la débâcle de 1940 et l'opération Dynamo, avec une scène impressionnante de mitraillage par avion sur une plage entre Dunkerque et Bray-Dunes, suivie de l'éjection du pilote allemand au milieu de ceux qu'il vient de viser.

OK, c'est que j'avais soupçonné avec le nom, merci.

Une note serait bienvenue oui.

Coucou,

merci pour ce chouette entretien, c'est très agréable de lire le travail d'artistes, ça change du développement logiciel.

Petite question pour un non initié, qu'est-ce que le « in-between » ?

Bravo pour réussir à continuer sur la durée, c'est vraiment pas évident de porter un gros projet à bouts de bras quand on est une petite équipe avec peu de moyens.

Mais XMPP reste un petit réseau, malheureusement.

XMPP est très utilisé, mais ça n'est pas toujours visible ou fédéré. Quelques chiffres sont dispos sur https://xmpp.org/uses/instant-messaging.html (mais j’exclurais Whatsapp qui a utilisé une variante maison de XMPP au début). C'est aussi utilisé dans le domaine du jeu, médical ou militaire, ou comme base pour des services (de mémoire les plateformes de notification — push — d'Apple et de Google utilisent XMPP, enfin si c'est encore le cas). C'est peu utilisé (très peu en comparaison à IRC) pour les projets libres, ça c'est vrai. Avec les évolutions énormes en cours (Snikket, vidéoconférence sur plusieurs projets, interface de Gajim, chiffrement de bout en bout sur Movim, passerelle ActivityPub sur laquelle je travaille), je m'attends à une sérieuse montée en puissance dans les 1 ou 2 années à venir.

Pour Haiku on se pose la question (entre XMPP et Matrix) et pour l'instant le sujet est suspendu en attente d'avoir un bon client natif pour l'un ou pour l'autre.

Qu'est-ce que tu appelles un bon client natif ? Quelles fonctionnalités ? Et natif sur Haiku ou d'autres plateformes ? Gajim ne fonctionne pas sur Haiku ?