À supposer que ce soit bien chiffré de bout en bout sans possibilité de déchiffrement dans le serveur, il y a encore de nombreuses possibilités d'analyses:
déjà le client peut faire une analyse sur le téléphone : tu peux envoyer ton message chiffré, mais ton client peut savoir que tu as dis marseille, voyage et août, et avertir le serveur qu'il faut envoyer des pubs sur les boules de pétanque et le Pastis
les métadonnées, comme dit plus haut
le chiffrement n'empêche pas d'envoyer des pubs
et c'est pas Whatapp qui envoit la liste complète des contacts aux serveur ? Niveau vie privée on a vu mieux
d'ailleurs je pense que même sans savoir à qui ont écrit (ce qu'ils savent), savoir avec qui on est en relation est une information extrêment intéressante
comme dit plus haut les bots en effet peuvent aider aussi, surtout que monsieur Z a annoncé qu'il mettait des billes dedans
Bon ce ne sont que des hypothéses, et c'est tout de même une (très) bonne chose que le chiffrement de bout en bout devienne un arguement de poids. Maintenant faudrait faire de même avec standardisation, décentralisation, et surtout code libre.
Oui la reprise de transfert est prévue de base (avec l'ancienne méthode également d'ailleurs). C'est tout à fait adapté, et même pensé pour le transfert de gros fichiers.
il est possible de fournir la somme de contrôle (« hash ») quand on le souhaite, et ainsi la calculer au fur et à mesure
Ah ça c'est super, c'est comme rsync.
Le hash y'a même une XEP dédiée maintenant (la XEP-0300), l'intérêt d'avoir fait ça à part, c'est de pouvoir s'adapter aux méthodes modernes en cas de failles découvertes et de nouvelles recommandations.
Je sais qu'il y a au moins un début d'implémentation pour SliXMPP qui a été conçu pour rester au maximum compatible avec SleekXMPP, donc ça devrait marcher pour les 2. Je fais passer la question à ceux qui s'en occupent pour voir s'ils peuvent compléter.
Sinon le manque d'implémentation il peut y avoir plusieurs raisons. Déjà c'est pas trivial à implémenter, la souplesse du protocole implique qu'il faut bien penser le code pour pouvoir s'adapter à tous les cas, c'est un gros morceau.
Au niveau du transfert de fichiers, c'est pas encore stable, ça rebute certains développeurs de clients, ou alors ils ne voient pas l'intérêt parce qu'ils ont déjà stream initiation (l'ancienne méthode).
Pour la visioconférence, ça peut bloquer parce qu'on se dit qu'il y a beaucoup à faire : Jingle est une première couche déjà pas simple, mais après y'a toutes les questions de gestion de formats vidéos, de débit, de performances, etc. C'est un autre domaine que la messagerie texte de base.
C'est vraiment dommage qu'il n'y ait pas plus d'implémentations en effet, quand on voit tout ce que Jingle permet de faire, j'espère que la vague de nouveauté actuelle va motiver du monde (à bon entendeur…).
Pyjamas est mort (cf. ce commentaire). La solution la plus prometteuse pour Python dans un navigateur à l'heure actuelle semble être Brython, et là aucune idée si wasm peut apporter quelque chose ou est envisagé…
Ça parle de plugin Firefox qui est peut-être sorti depuis. Bref, c'est super de voir un tel outil arriver, j'aimerais beaucoup l'intégrer à SàT d'ailleurs à terme.
En fait Blender a plusieurs modules, et celui dont je parle, le « Video Sequence Editor », peut être utilisé entièrement en dehors de la partie modélisation. Ça fait un peu peur quand on voit la première fois, mais au final tu importes les vidéos, les déplaces où tu veux, applique tes effets etc très facilement. Quand tu connais déjà les raccourcis de Blender c'est sûr que ça aide bien. Ça lit un grand nombre de format, c'est stable et puissant.
Il y aussi le « node editor » pour faire du compositing ou le « movie clip editor » pour faire du tracking et par exemple stabiliser une vidéo, mais ça c'est déjà compliqué à prendre en main (enfin pas tant que ça non plus).
Tout ça XMPP le fait déjà également (il est parfaitement possible de passer par Tor — faut pas mettre les majuscules, sinon y'a les gars de nos oignons qui nous enguelent ;) — ça fait même un moment qu'on parle d'une version spécialisée de SàT qui fait ça directement).
Ce qui avait l'air intéressant sur Ricochet quand j'avais regardé (mais pas testé), c'est qu'il ajoute du bruit pour rendre plus difficile l'analyse du trafic. Sûrement utile dans les cas très sensibles, mais ça me semble à double tranchant sur l'utilisation des ressources processeur/réseau (encore une fois pas testé).
Pour ma part, je vois un inconvénient principal : on devient dépendant du serveur qui maintient notre JID. Que ce soit le nôtre ou pas. Typiquement, j'ai un compte sur jabber.fr, que je n'utilise plus, parce que les certificats SSL n'ont pas été renouvelés. La migration vers un autre serveur est trop coûteuse pour que j'en voit l'intérêt.
C'est surtout du nom de domaine que tu dépends, si tu veux pouvoir bouger facilement, en prendre un et le faire suivre ton serveur est une option. Mais la migration entre les comptes est un truc à travailler en effet.
jabber.fr manque de bras, il n'y a plus qu'un admin actif à ma connaissance, et vu la place du serveur (souvent le premier sur lequel on tombe quand on est francophone), un coup de main serait sans doute très apprécié.
Comparé a IRC, peu importe le serveur sur lequel je me connecte, ça marche toujours aussi bien.
XMPP est capable de fonctionner de la même façon, avec les connexions « anonymes » (anonymes parce que pas de JID fixe, aucun rapport avec l'anonymat à la TOR). Et là aussi c'est d'autres admins qui gèrent les certificats ou état du serveur (et c'est même pire parce que les salons sont très liés aux serveurs).
Alors certes, IRC n'offre pas le même service, mais finalement ça me convient mieux.
IRC fait sont boulot depuis plusieurs dizaines d'années, si ça te convient c'est très bien, rien à redire dessus.
XMPP bien plus que de la messagerie, comme je le répète régulièrement, en ce moment on le montre avec son utilisation pour du blogage.
Ben en fait c'est déjà plus ou moins ce qu'il passe qu'on on utilise XMPP à travers TOR. Un nom de domaine reste adapté, c'est juste qu'il est lié à un autre système que l'actuel. À l'heure actuelle tu peux même utiliser une IP directement si tu veux.
XMPP n'est pas forcément lié à TCP, il y a tout un tas de possibilités envisageables.
Pour les autres problèmes, je ne vais pas supputer, du 100% pair à pair n'est clairement pas ma priorité pour le moment, il y a d'autres problèmes à régler avant, et comme je l'ai dit plus haut un serveur intermédiaire a de nombreux avantages et je pense qu'à l'heure actuelle c'est préférable. Dans l'idéal, il serait possible dans le futur de choisir 100% P2P ou avec serveur intermédiaire, mais bon on n'en est pas là.
Dans le premier cas, il reste un "centre" qui échappe à l'utilisateur. Dans le second, le poids de la mise en place et de l'entretien de ce "centre" lui incombe. Aucun de ces horizons ne me semble désirable au point de ne pas investiguer celui des services distribués, pour justement, entre autre, envisager leurs limitations. C'est de la prospective.
Oui il y a plusieurs questions à prendre en compte. Pour ma part je ne suis pas gêné d'avoir un serveur géré par une entité si j'ai confiance en elle (une assoce que je connais bien par exemple), mais même dans ce cas je chiffrerai de bout en bout les infos très sensibles (par exemple un mot de passe que je donne à quelqu'un). Pour faire un parallèle, j'ai très souvent laissé les clefs de chez moi à des inconnus (je suis sur des sites d'hospitalité comme BeWelcome).
Il y a aussi des questions écologiques (mutualiser les ressources sera toujours mieux de ce point de vue), d'entretien (en dehors du serveur pour ton logiciel lui même, la gestion des sauvegardes ou des risques d'intrusion ne vont a priori pas être géré par ton logiciel final, même s'il est entièrement P2P). Bref, c'est pas mal si une ou plusieurs personnes s'en occupent sérieusement. Je pense que le mieux est de permettre les 2 : mutualiser et si voulu autohébergement facile.
Je vois Tox, ring.cx et ricochet comme outsiders. Si tu as le temps, je serais ravi - et probablement pas que moi - d'avoir ton avis sur ces derniers.
Tox j'ai essayé mais il y a plus d'un an, avec un des frontaux les plus communs (je ne sais plus lequel, peut-être Venom). J'avais apprécié la simplicité (en dehors du hash quasi inévitable, on lance est c'est OK), mais impossible d'avoir une vidéo fonctionnelle, et c'est pour ça que je voulais l'utiliser. À vrai dire même avec Jitsi j'ai pas eu des résultats très probants (pas essayé non plus depuis longtemps), et c'est encore Mumble qui me donne les meilleurs résultats, mais c'est audio uniquement. Il faut dire que je suis souvent dans des conditions mauvaises (pas de connexion directe, mauvais débit, etc).
Ring et Ricochet pas essayé, Ricochet leur technique pour couvrir le bruit semble intéressante, mais c'est un cas d'utilisation particulier, pour des messages très sensibles, pas sûr que ça soit viable pour de la conversation de tous les jours (encore une fois, question de ressources).
Dans tous les cas ces projets vont accuser un énorme retard sur XMPP, car il y a beaucoup de problèmes qui sont déjà réglés dans ce dernier, et qu'ils vont avoir. Et c'est souvent plus difficile quand il n'y a pas de serveur intermédiaire. Sans parler des fonctionnalités à implémenter (des trucs comme la correction du dernier message, l'état de discussion, la gestion des archives, des appareils multiples connectés en même temps, etc).
Tiens d'ailleurs XMPP est un cas particulier : c'est un réseau décentralisé « hybride », c'est à dire qu'il y a des serveurs intermédiaires mais il est capable de faire du P2P (j'ai un article à publier sur Jingle à ce sujet). On est aussi plusieurs à envisager à terme d'en faire un réseau entièrement pair à pair en regroupant serveur et client (optionnellement), ça ne se fera peut-être jamais, mais c'est techniquement possible (on peut déjà se passer de serveur en local).
déjà merci pour ce journal, il est intéressant et j'aimerais aussi voir d'éventuelles suites.
Juste une petite remarque, il y a une tendance à penser que quelque chose de « distribué » (dans le sens utilisé ici) est nécessairement mieux que quelque chose de « décentralisé » (dans le sens avec un serveur intermédiaire). C'est à mon sens une erreur.
Un système « distribué » comme compris ici (que j'appelle plutôt « entièrement pair à pair » pour éviter les confusions), ne se passe pas de serveur, c'est juste que le serveur est placé au niveau du client, ou en d'autres terme c'est le client qui fait le boulot.
C'est intéressant sur plusieurs points (on devrait pouvoir couper une partie du réseau sans grosse conséquence sur les autres par exemple), et c'est clairement très très intéressant sur le plan technique/recherche.
Mais placer le serveur au niveau du client a ses conséquences : le client devant faire le boulot, c'est autant en plus sur la bande passante et la charge processeur, ce qui est particulièrement gênant pour le monde mobile où ça va en plus influer sur la batterie.
Il y a d'autres problèmes : l'accessibilité des données par exemple ; et d'ailleurs on le voit dans ton journal, dans le paragraphe « Pseudo synchronisation asynchrone » :
Une solution simple consiste à partager le répertoire également avec une machine C qui reste allumée entre temps
En gros tu mets un serveur en place…
Autre soucis : l'identifiant. Il n'y a pas aujourd'hui — à ma connaissance — de solution simple et facile pour identifier une machine sans serveurs intermédiaires.
Avec Syncthing: pas de nom d'utilisateur, pas de mot de passe, tout passe par des clés, des hashs, et des QR codes très pratiques.
des hashs et des QR codes, je trouve pas ça très pratique moi, les QR codes sont plutôt des cache-misères.
Le choix d'un serveur intermédiaire est généralement voulu, et en simplifiant, il suffirait de mettre serveur et client sur la même machine pour en faire ce que tu appelles « distribué » (et de trouver un substitut au DNS avec probablement à la clef des hashs imbitables et autres QR codes).
J'avais d'ailleurs fait un billet sur mon blog à ce sujet, lisible ici.
Enfin bref, du 100% pair à pair c'est intéressant, mais c'est pas forcément mieux qu'un serveur intermédiaire, à mon sens du moins.
Si ton but principal c'est la simplification de la configuration, c'est peut-être de ce côté qu'il faut regarder (un serveur intermédiaire ne devrait pas être synonyme d'un truc relou à installer).
Ceci-dit, je vais lire tes prochains articles avec intérêt :)
OK donc Sophia c'est l'administration, et Paris un bureau de contact régional. Je ne suis pas persuadé par l'utilisation d'auto-portraits comme moyen de pression politique (sauf si vous faites vraiment peur), mais dans tous les cas ça aura sans doute plus de poids à Sophia qu'à Paris.
Content de voir que ça avance toujours (j'avais fait une dépêche sur le sujet il y a bientôt 7 ans (wow, ça ne me semblait pas aussi vieux).
Je ne suivais plus trop l'actualité de ce projet, mais il y a un domaine où ça pourrait m'intéresser fortement, c'est pour le développement de version Windows de mes logiciels. Il y a déjà eu des expériences de ce type ? Je suis encore moins l'actualité Windows, est-ce que ça aurait du sens aujourd'hui de compiler/tester dessus alors qu'il y a des Windows 7, 8 et 10 ?
La déduplication envisagée avec OSTree et le systèmes de couches déjà en place avec Docker permettent de profiter en partie des dépendances déjà installées.
Les conteneurs sont une solution intéressante, notamment pour des applications en lesquelles tu n'as pas confiance, après je ne pense pas que le but est de remplacer les gestionnaires de paquets de ta distro, et pour ma part je préfère nettement un truc déjà intégré dans ma Debian ou autre, mais je suis content d'installer un truc tiers ou à tester avec gestion des permissions très facilement.
Autant le ton et l'humour de ton journal que ton utilisation de XMPP qui sort enfin des sentiers battus. Vraiment super, continue comme ça, c'est un plaisir de te lire et de voir tes (vos) aventures continuer !
J'ai pas testé mais d'après la capture c'est joli en effet. Faire un nouveau jeu n'aurait sûrement pas plu à ta grand mère (quoi que), mais si tu diffuses oui ça risque de poser problème.
Petite remarque en passant, le ® est un truc des pays du common law (É.-U., Angeleterre, Australie, etc), ça n'a aucune valeur en France et ça ne sert à rien de le mettre (perso ça me donne même l'impression que la personne soutien ce genre de système).
Un des intérêts majeurs, c'est que tu donnes accès à ton environnement extérieur, par exemple le serveur X ou le système de fichier via un système simple de permissions. Tu peux toujours mettre dans un Docker, mais tu devras soit rester dans ton conteneur, soit avoir un moyen de donner ces permission (et donc refaire Subuser en gros).
En plus je ne suis pas sûr que faire tourner un Docker dans un conteneur Docker soit une super idée, notamment avec le système de fichiers par couches.
Je ne sais pas si je suis clair, mais la réponse est non, ça ne serait pas viable de distribuer ça via une image Docker.
Si tu veux tu peux me contacter sur goffi @ goffi . org (ou via XMPP, mon jid est renseigné ici, il y a juste à cliquer), ou directement Timothy, l'auteur (son adresse est dans l'exemple de configuration dans la dépêche).
Bis repetita… L'important ce n'est pas d'avoir le code du serveur (tu ne sais jamais si tu as vraiment le code du serveur), mais d'avoir des données utilisables.
Pour moi, à partir du moment où tu as décidé d'aller voir ailleurs, et problématiques de confiance mises de côté, il y a 2 facteurs majeurs:
le code source, pour reproduire à l'identique
et les données
tu peux avoir l'un sans l'autre, mais les 2 sont importants.
Si tu n'as pas le code source, tu devras trouver (ou écrire) un logiciel compatible, et tu risques de perdre des fonctionnalités.
Si tu n'as pas les données, tu vas devoir passer par des méthodes détournées comme le scrapping, là encore, du temps et des efforts pour migrer. Et il y a possiblement des cas où c'est même pas possible ou extrêmement difficile de migrer (par exemple une vidéo avec DRM)
Tu sais qu'on peut être piégé par un logiciel tout ce qu'il y a de plus libre ? Si tu fais de la photo et que tu as déjà changé de logiciel de gestion de photo, tu dois voir de quoi je parle. Chaque logiciel créer son propre silo de données que tu alimente fièrement et qui n'ai pas interopérable dommage. Me faire avoir par un service ou par un logiciel (qu'il soit libre ou non) ça laisse le même arrière goût
Même pour le libre il y a une question de confiance, la licence est un élément majeur mais pas suffisant. Si l'éditeur du logiciel ajoute volontairement des données difficiles à transférer, il vaut mieux l'éviter, si c'est juste un manque d'outil de migration, c'est l'occasion de contribuer. Dans tous les cas, c'est bien plus simple si tu as les sources (et le droit d'y toucher).
Pfff rhétorique… Je croyais que tu répondais au commentaire qui disait que l'article n'était pas intéressant (c'est vachement intéressant de se renvoyer la balle comme ça tu ne trouve pas ?….)
Je reproche juste de me faire dire des choses que je n'ai pas dites. Je ne connais pas suffisamment Gitlab pour le conseiller, et j'essaye d'éviter la centralisation autant que possible (ce qui ne m'empêche pas d'être sur DLFP ou SeenThis). Et pareil pour la remarque suivante, rappeler le contexte c'est une chose, me mettre dans le « vous » c'est me faire dire des choses que je n'ai pas dite. Enfin pas la peine de s'étendre dessus, je voulais aussi d'éviter d'avoir à défendre ou réfuter des arguments qui ne sont pas les miens.
De manière très général, je trouve que critiquer n'est pas très intéressant, c'est souvent pas très constructif. Il est bien plus intéressant pour tout le monde et bien plus efficace pour lutter contre l'uniformisation de présenter son alternative et pas comme un St Graal (ça met sur la défensive), mais en expliquant en quoi ça te convient.
Critiquer (quand c'est pas gratuit et que c'est argumenté), ça permet de réfléchir, et peut-être de déboucher sur une solution.
Non. Tu peux très bien monter un pataquès trop complexe pour qu'un particulier puisse jouer avec.
J'ai dis « tu peux le reproduire chez toi (ou ailleurs) à l'identique », évidemment tu peux chercher le cas tordu où on va chercher à rendre le truc difficile à installer, mais ça ne change rien au fait que tu peux le reproduire à l'identique, alors que si tu n'as pas les sources tu ne peux pas.
La majorité des données sont exportables. Dans un format très largement utilisé quand c'est possible (les sources et le wiki). Il n'y a tout simplement pas de forge libre qui propose d'exporter autant/aussi facilement ses données.
Dans le cas présent (github), si tu dis « la majorité », ça veut dire qu'il y a des données non exportables. Et dans tous les cas tu as un effort d'export à faire, avec risque de perte de fonctionnalités si tu n'as pas le même logiciel en face.
Se plaindre de l'uniformisation de github en prônant gitlab, c'est ridicule.
C'est possible, sauf que je n'ai pas plus « prôné Gitlab » comme tu dis qu'une autre solution, si tu réponds à l'auteur de l'article original, c'est pas à mon commentaire qu'il faut répondre. Je réponds uniquement au commentaire qui dit que ça n'a pas d'intérêt d'avoir le code source d'un « service », et j'explique pourquoi c'est faux.
Mais tout ça c'est surtout ridicule parce que les gens qui se plaignent ne veulent pas révolutionner le monde des forges, ils veulent juste quelques fonctionnalités en plus. Ça n'a rien avoir avec tout ce que vous racontez. Vous faites dire n'importe quoi à cette lettre.
Merci de ne pas m'inclure dans ce « vous », je n'ai ni lu, ni mentionné cette lettre (et pour tout dire, je me cogne pas mal de ce qu'il se passe chez Github, sauf quand ça me concerne directement comme dans le cas de la XSF).
# modèle économique
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal WhatsApp active le chiffrement de bout en bout. Évalué à 4.
À supposer que ce soit bien chiffré de bout en bout sans possibilité de déchiffrement dans le serveur, il y a encore de nombreuses possibilités d'analyses:
déjà le client peut faire une analyse sur le téléphone : tu peux envoyer ton message chiffré, mais ton client peut savoir que tu as dis marseille, voyage et août, et avertir le serveur qu'il faut envoyer des pubs sur les boules de pétanque et le Pastis
les métadonnées, comme dit plus haut
le chiffrement n'empêche pas d'envoyer des pubs
et c'est pas Whatapp qui envoit la liste complète des contacts aux serveur ? Niveau vie privée on a vu mieux
d'ailleurs je pense que même sans savoir à qui ont écrit (ce qu'ils savent), savoir avec qui on est en relation est une information extrêment intéressante
comme dit plus haut les bots en effet peuvent aider aussi, surtout que monsieur Z a annoncé qu'il mettait des billes dedans
Bon ce ne sont que des hypothéses, et c'est tout de même une (très) bonne chose que le chiffrement de bout en bout devienne un arguement de poids. Maintenant faudrait faire de même avec standardisation, décentralisation, et surtout code libre.
[^] # Re: Implémentations python
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Parlons XMPP - épisode 10 - copie de fichiers et Jingle (suite). Évalué à 2.
Ah et j'oubliais, il y a bien sûr Gajim qui a une implé, et qui est en Python.
[^] # Re: Gros fichiers
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Parlons XMPP - épisode 10 - copie de fichiers et Jingle (suite). Évalué à 3.
Oui la reprise de transfert est prévue de base (avec l'ancienne méthode également d'ailleurs). C'est tout à fait adapté, et même pensé pour le transfert de gros fichiers.
Le hash y'a même une XEP dédiée maintenant (la XEP-0300), l'intérêt d'avoir fait ça à part, c'est de pouvoir s'adapter aux méthodes modernes en cas de failles découvertes et de nouvelles recommandations.
[^] # Re: Implémentations python
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Parlons XMPP - épisode 10 - copie de fichiers et Jingle (suite). Évalué à 2.
Je sais qu'il y a au moins un début d'implémentation pour SliXMPP qui a été conçu pour rester au maximum compatible avec SleekXMPP, donc ça devrait marcher pour les 2. Je fais passer la question à ceux qui s'en occupent pour voir s'ils peuvent compléter.
Sinon le manque d'implémentation il peut y avoir plusieurs raisons. Déjà c'est pas trivial à implémenter, la souplesse du protocole implique qu'il faut bien penser le code pour pouvoir s'adapter à tous les cas, c'est un gros morceau.
Au niveau du transfert de fichiers, c'est pas encore stable, ça rebute certains développeurs de clients, ou alors ils ne voient pas l'intérêt parce qu'ils ont déjà stream initiation (l'ancienne méthode).
Pour la visioconférence, ça peut bloquer parce qu'on se dit qu'il y a beaucoup à faire : Jingle est une première couche déjà pas simple, mais après y'a toutes les questions de gestion de formats vidéos, de débit, de performances, etc. C'est un autre domaine que la messagerie texte de base.
C'est vraiment dommage qu'il n'y ait pas plus d'implémentations en effet, quand on voit tout ce que Jingle permet de faire, j'espère que la vague de nouveauté actuelle va motiver du monde (à bon entendeur…).
[^] # Re: Normal !
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Bash dans Windows. Évalué à 4.
En tout cas c'est un point sur lequel on ne pourra plus basher Zindoz.
[^] # Re: WebAssembly
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Firefox 45 ESR et autres actualités mozilliennes. Évalué à 5.
Pyjamas est mort (cf. ce commentaire). La solution la plus prometteuse pour Python dans un navigateur à l'heure actuelle semble être Brython, et là aucune idée si wasm peut apporter quelque chose ou est envisagé…
[^] # Re: Si seulement !
Posté par Goffi (site web personnel, Mastodon) . En réponse au sondage Pour mes problèmes d'orthographe.... Évalué à 5.
Pour Vim je ne sais pas si c'est déjà possible, mais en tout cas l'auteur explique son avancement ici: http://dicollecte.org/thread.php?prj=fr&t=471 (le dernier message date du début du mois, plutôt encourageant), et je suis tombé sur ça aussi pour l'utiliser en ligne de commande : https://blog.sciunto.org/posts/grammalecte_avancement/
Ça parle de plugin Firefox qui est peut-être sorti depuis. Bref, c'est super de voir un tel outil arriver, j'aimerais beaucoup l'intégrer à SàT d'ailleurs à terme.
[^] # Re: Autour de GNOME : Pitivi 0.96 is coming
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Parution de GNOME 3.20 Delhi. Évalué à 7.
En fait Blender a plusieurs modules, et celui dont je parle, le « Video Sequence Editor », peut être utilisé entièrement en dehors de la partie modélisation. Ça fait un peu peur quand on voit la première fois, mais au final tu importes les vidéos, les déplaces où tu veux, applique tes effets etc très facilement. Quand tu connais déjà les raccourcis de Blender c'est sûr que ça aide bien. Ça lit un grand nombre de format, c'est stable et puissant.
Pour donner une idée, c'est avec lui qu'on a monté notre vidéo de campagne : http://ftp.goffi.org/media/video/libervia_arizuka_50%25_hard_sub_fr.webm la prise de son était séparée et c'était trivial de la synchroniser avec.
Il y aussi le « node editor » pour faire du compositing ou le « movie clip editor » pour faire du tracking et par exemple stabiliser une vidéo, mais ça c'est déjà compliqué à prendre en main (enfin pas tant que ça non plus).
[^] # Re: Autour de GNOME : Pitivi 0.96 is coming
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Parution de GNOME 3.20 Delhi. Évalué à 6.
Tu as essayé Blender ? La partie montage vidéo est excellente (comme l'ensemble du logiciel), et très intuitive.
[^] # Re: Ne pas jeter le bébé avec l'eau du bain
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Partage: de ownCloud (décentralisé) à Syncthing (distribué). Évalué à 3.
Tout ça XMPP le fait déjà également (il est parfaitement possible de passer par Tor — faut pas mettre les majuscules, sinon y'a les gars de nos oignons qui nous enguelent ;) — ça fait même un moment qu'on parle d'une version spécialisée de SàT qui fait ça directement).
Ce qui avait l'air intéressant sur Ricochet quand j'avais regardé (mais pas testé), c'est qu'il ajoute du bruit pour rendre plus difficile l'analyse du trafic. Sûrement utile dans les cas très sensibles, mais ça me semble à double tranchant sur l'utilisation des ressources processeur/réseau (encore une fois pas testé).
[^] # Re: Ne pas jeter le bébé avec l'eau du bain
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Partage: de ownCloud (décentralisé) à Syncthing (distribué). Évalué à 3.
C'est surtout du nom de domaine que tu dépends, si tu veux pouvoir bouger facilement, en prendre un et le faire suivre ton serveur est une option. Mais la migration entre les comptes est un truc à travailler en effet.
jabber.fr manque de bras, il n'y a plus qu'un admin actif à ma connaissance, et vu la place du serveur (souvent le premier sur lequel on tombe quand on est francophone), un coup de main serait sans doute très apprécié.
XMPP est capable de fonctionner de la même façon, avec les connexions « anonymes » (anonymes parce que pas de JID fixe, aucun rapport avec l'anonymat à la TOR). Et là aussi c'est d'autres admins qui gèrent les certificats ou état du serveur (et c'est même pire parce que les salons sont très liés aux serveurs).
IRC fait sont boulot depuis plusieurs dizaines d'années, si ça te convient c'est très bien, rien à redire dessus.
XMPP bien plus que de la messagerie, comme je le répète régulièrement, en ce moment on le montre avec son utilisation pour du blogage.
[^] # Re: Ne pas jeter le bébé avec l'eau du bain
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Partage: de ownCloud (décentralisé) à Syncthing (distribué). Évalué à 2.
Ben en fait c'est déjà plus ou moins ce qu'il passe qu'on on utilise XMPP à travers TOR. Un nom de domaine reste adapté, c'est juste qu'il est lié à un autre système que l'actuel. À l'heure actuelle tu peux même utiliser une IP directement si tu veux.
XMPP n'est pas forcément lié à TCP, il y a tout un tas de possibilités envisageables.
Pour les autres problèmes, je ne vais pas supputer, du 100% pair à pair n'est clairement pas ma priorité pour le moment, il y a d'autres problèmes à régler avant, et comme je l'ai dit plus haut un serveur intermédiaire a de nombreux avantages et je pense qu'à l'heure actuelle c'est préférable. Dans l'idéal, il serait possible dans le futur de choisir 100% P2P ou avec serveur intermédiaire, mais bon on n'en est pas là.
[^] # Re: Ne pas jeter le bébé avec l'eau du bain
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Partage: de ownCloud (décentralisé) à Syncthing (distribué). Évalué à 5.
Oui il y a plusieurs questions à prendre en compte. Pour ma part je ne suis pas gêné d'avoir un serveur géré par une entité si j'ai confiance en elle (une assoce que je connais bien par exemple), mais même dans ce cas je chiffrerai de bout en bout les infos très sensibles (par exemple un mot de passe que je donne à quelqu'un). Pour faire un parallèle, j'ai très souvent laissé les clefs de chez moi à des inconnus (je suis sur des sites d'hospitalité comme BeWelcome).
Il y a aussi des questions écologiques (mutualiser les ressources sera toujours mieux de ce point de vue), d'entretien (en dehors du serveur pour ton logiciel lui même, la gestion des sauvegardes ou des risques d'intrusion ne vont a priori pas être géré par ton logiciel final, même s'il est entièrement P2P). Bref, c'est pas mal si une ou plusieurs personnes s'en occupent sérieusement. Je pense que le mieux est de permettre les 2 : mutualiser et si voulu autohébergement facile.
Tox j'ai essayé mais il y a plus d'un an, avec un des frontaux les plus communs (je ne sais plus lequel, peut-être Venom). J'avais apprécié la simplicité (en dehors du hash quasi inévitable, on lance est c'est OK), mais impossible d'avoir une vidéo fonctionnelle, et c'est pour ça que je voulais l'utiliser. À vrai dire même avec Jitsi j'ai pas eu des résultats très probants (pas essayé non plus depuis longtemps), et c'est encore Mumble qui me donne les meilleurs résultats, mais c'est audio uniquement. Il faut dire que je suis souvent dans des conditions mauvaises (pas de connexion directe, mauvais débit, etc).
Ring et Ricochet pas essayé, Ricochet leur technique pour couvrir le bruit semble intéressante, mais c'est un cas d'utilisation particulier, pour des messages très sensibles, pas sûr que ça soit viable pour de la conversation de tous les jours (encore une fois, question de ressources).
Dans tous les cas ces projets vont accuser un énorme retard sur XMPP, car il y a beaucoup de problèmes qui sont déjà réglés dans ce dernier, et qu'ils vont avoir. Et c'est souvent plus difficile quand il n'y a pas de serveur intermédiaire. Sans parler des fonctionnalités à implémenter (des trucs comme la correction du dernier message, l'état de discussion, la gestion des archives, des appareils multiples connectés en même temps, etc).
Tiens d'ailleurs XMPP est un cas particulier : c'est un réseau décentralisé « hybride », c'est à dire qu'il y a des serveurs intermédiaires mais il est capable de faire du P2P (j'ai un article à publier sur Jingle à ce sujet). On est aussi plusieurs à envisager à terme d'en faire un réseau entièrement pair à pair en regroupant serveur et client (optionnellement), ça ne se fera peut-être jamais, mais c'est techniquement possible (on peut déjà se passer de serveur en local).
# Ne pas jeter le bébé avec l'eau du bain
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Partage: de ownCloud (décentralisé) à Syncthing (distribué). Évalué à 9. Dernière modification le 24 mars 2016 à 11:37.
Salut,
déjà merci pour ce journal, il est intéressant et j'aimerais aussi voir d'éventuelles suites.
Juste une petite remarque, il y a une tendance à penser que quelque chose de « distribué » (dans le sens utilisé ici) est nécessairement mieux que quelque chose de « décentralisé » (dans le sens avec un serveur intermédiaire). C'est à mon sens une erreur.
Un système « distribué » comme compris ici (que j'appelle plutôt « entièrement pair à pair » pour éviter les confusions), ne se passe pas de serveur, c'est juste que le serveur est placé au niveau du client, ou en d'autres terme c'est le client qui fait le boulot.
C'est intéressant sur plusieurs points (on devrait pouvoir couper une partie du réseau sans grosse conséquence sur les autres par exemple), et c'est clairement très très intéressant sur le plan technique/recherche.
Mais placer le serveur au niveau du client a ses conséquences : le client devant faire le boulot, c'est autant en plus sur la bande passante et la charge processeur, ce qui est particulièrement gênant pour le monde mobile où ça va en plus influer sur la batterie.
Il y a d'autres problèmes : l'accessibilité des données par exemple ; et d'ailleurs on le voit dans ton journal, dans le paragraphe « Pseudo synchronisation asynchrone » :
En gros tu mets un serveur en place…
Autre soucis : l'identifiant. Il n'y a pas aujourd'hui — à ma connaissance — de solution simple et facile pour identifier une machine sans serveurs intermédiaires.
des hashs et des QR codes, je trouve pas ça très pratique moi, les QR codes sont plutôt des cache-misères.
Le choix d'un serveur intermédiaire est généralement voulu, et en simplifiant, il suffirait de mettre serveur et client sur la même machine pour en faire ce que tu appelles « distribué » (et de trouver un substitut au DNS avec probablement à la clef des hashs imbitables et autres QR codes).
J'avais d'ailleurs fait un billet sur mon blog à ce sujet, lisible ici.
Enfin bref, du 100% pair à pair c'est intéressant, mais c'est pas forcément mieux qu'un serveur intermédiaire, à mon sens du moins.
Si ton but principal c'est la simplification de la configuration, c'est peut-être de ce côté qu'il faut regarder (un serveur intermédiaire ne devrait pas être synonyme d'un truc relou à installer).
Ceci-dit, je vais lire tes prochains articles avec intérêt :)
[^] # Re: Sophia
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Campagne FSF contre les DRM dans les standards du web. Évalué à 8.
OK donc Sophia c'est l'administration, et Paris un bureau de contact régional. Je ne suis pas persuadé par l'utilisation d'auto-portraits comme moyen de pression politique (sauf si vous faites vraiment peur), mais dans tous les cas ça aura sans doute plus de poids à Sophia qu'à Paris.
# Sophia
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Campagne FSF contre les DRM dans les standards du web. Évalué à 3. Dernière modification le 17 mars 2016 à 10:29.
Bonjour,
Curieux ça, à moins que ça ait changé depuis mon époque, mais il me semblait que le W3C était à Sophia Antipolis
[^] # Re: libvirt
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche ReactOS 0.4.0. Évalué à 7.
Non non, c'est bien ça : un écran bleu qui ne bouge pas, ils ont réussi à reproduire Windows à la perfection !
# Développement windows
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche ReactOS 0.4.0. Évalué à 9.
Content de voir que ça avance toujours (j'avais fait une dépêche sur le sujet il y a bientôt 7 ans (wow, ça ne me semblait pas aussi vieux).
Je ne suivais plus trop l'actualité de ce projet, mais il y a un domaine où ça pourrait m'intéresser fortement, c'est pour le développement de version Windows de mes logiciels. Il y a déjà eu des expériences de ce type ? Je suis encore moins l'actualité Windows, est-ce que ça aurait du sens aujourd'hui de compiler/tester dessus alors qu'il y a des Windows 7, 8 et 10 ?
[^] # Re: Securite
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Subuser, une sur‐couche à Docker. Évalué à 2.
Salut Cédric,
La déduplication envisagée avec OSTree et le systèmes de couches déjà en place avec Docker permettent de profiter en partie des dépendances déjà installées.
Les conteneurs sont une solution intéressante, notamment pour des applications en lesquelles tu n'as pas confiance, après je ne pense pas que le but est de remplacer les gestionnaires de paquets de ta distro, et pour ma part je préfère nettement un truc déjà intégré dans ma Debian ou autre, mais je suis content d'installer un truc tiers ou à tester avec gestion des permissions très facilement.
# rafraîchissant
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Mon ami se fait des amis. Évalué à 10.
Autant le ton et l'humour de ton journal que ton utilisation de XMPP qui sort enfin des sentiers battus. Vraiment super, continue comme ça, c'est un plaisir de te lire et de voir tes (vos) aventures continuer !
[^] # Re: droit d'auteur
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Trivabble : jouez au Scrabble ® en ligne. Évalué à 2.
J'ai pas testé mais d'après la capture c'est joli en effet. Faire un nouveau jeu n'aurait sûrement pas plu à ta grand mère (quoi que), mais si tu diffuses oui ça risque de poser problème.
Petite remarque en passant, le ® est un truc des pays du common law (É.-U., Angeleterre, Australie, etc), ça n'a aucune valeur en France et ça ne sert à rien de le mettre (perso ça me donne même l'impression que la personne soutien ce genre de système).
[^] # Re: Packaging deb/rpm
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Subuser, une sur‐couche à Docker. Évalué à 4.
Un des intérêts majeurs, c'est que tu donnes accès à ton environnement extérieur, par exemple le serveur X ou le système de fichier via un système simple de permissions. Tu peux toujours mettre dans un Docker, mais tu devras soit rester dans ton conteneur, soit avoir un moyen de donner ces permission (et donc refaire Subuser en gros).
En plus je ne suis pas sûr que faire tourner un Docker dans un conteneur Docker soit une super idée, notamment avec le système de fichiers par couches.
Je ne sais pas si je suis clair, mais la réponse est non, ça ne serait pas viable de distribuer ça via une image Docker.
[^] # Re: Packaging deb/rpm
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Subuser, une sur‐couche à Docker. Évalué à 2.
salut sham, super !
Si tu veux tu peux me contacter sur goffi @ goffi . org (ou via XMPP, mon jid est renseigné ici, il y a juste à cliquer), ou directement Timothy, l'auteur (son adresse est dans l'exemple de configuration dans la dépêche).
Merci :)
[^] # Re: service...
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Le danger github. Évalué à 10. Dernière modification le 26 février 2016 à 15:44.
Pour moi, à partir du moment où tu as décidé d'aller voir ailleurs, et problématiques de confiance mises de côté, il y a 2 facteurs majeurs:
tu peux avoir l'un sans l'autre, mais les 2 sont importants.
Si tu n'as pas le code source, tu devras trouver (ou écrire) un logiciel compatible, et tu risques de perdre des fonctionnalités.
Si tu n'as pas les données, tu vas devoir passer par des méthodes détournées comme le scrapping, là encore, du temps et des efforts pour migrer. Et il y a possiblement des cas où c'est même pas possible ou extrêmement difficile de migrer (par exemple une vidéo avec DRM)
Même pour le libre il y a une question de confiance, la licence est un élément majeur mais pas suffisant. Si l'éditeur du logiciel ajoute volontairement des données difficiles à transférer, il vaut mieux l'éviter, si c'est juste un manque d'outil de migration, c'est l'occasion de contribuer. Dans tous les cas, c'est bien plus simple si tu as les sources (et le droit d'y toucher).
Je reproche juste de me faire dire des choses que je n'ai pas dites. Je ne connais pas suffisamment Gitlab pour le conseiller, et j'essaye d'éviter la centralisation autant que possible (ce qui ne m'empêche pas d'être sur DLFP ou SeenThis). Et pareil pour la remarque suivante, rappeler le contexte c'est une chose, me mettre dans le « vous » c'est me faire dire des choses que je n'ai pas dite. Enfin pas la peine de s'étendre dessus, je voulais aussi d'éviter d'avoir à défendre ou réfuter des arguments qui ne sont pas les miens.
Critiquer (quand c'est pas gratuit et que c'est argumenté), ça permet de réfléchir, et peut-être de déboucher sur une solution.
[^] # Re: service...
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Le danger github. Évalué à 10.
J'ai dis « tu peux le reproduire chez toi (ou ailleurs) à l'identique », évidemment tu peux chercher le cas tordu où on va chercher à rendre le truc difficile à installer, mais ça ne change rien au fait que tu peux le reproduire à l'identique, alors que si tu n'as pas les sources tu ne peux pas.
Dans le cas présent (github), si tu dis « la majorité », ça veut dire qu'il y a des données non exportables. Et dans tous les cas tu as un effort d'export à faire, avec risque de perte de fonctionnalités si tu n'as pas le même logiciel en face.
C'est possible, sauf que je n'ai pas plus « prôné Gitlab » comme tu dis qu'une autre solution, si tu réponds à l'auteur de l'article original, c'est pas à mon commentaire qu'il faut répondre. Je réponds uniquement au commentaire qui dit que ça n'a pas d'intérêt d'avoir le code source d'un « service », et j'explique pourquoi c'est faux.
Merci de ne pas m'inclure dans ce « vous », je n'ai ni lu, ni mentionné cette lettre (et pour tout dire, je me cogne pas mal de ce qu'il se passe chez Github, sauf quand ça me concerne directement comme dans le cas de la XSF).