Goffi a écrit 1523 commentaires

  • [^] # Re: Sophia

    Posté par  (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  (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,

    ailleurs, notamment, en France, c'est Paris (INRIA)

    Curieux ça, à moins que ça ait changé depuis mon époque, mais il me semblait que le W3C était à Sophia Antipolis

  • [^] # Re: libvirt

    Posté par  (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  (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  (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  (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  (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  (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  (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  (site web personnel, Mastodon) . En réponse au journal Le danger github. Évalué à 10. Dernière modification le 26 février 2016 à 15:44.

    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.

  • [^] # Re: service...

    Posté par  (site web personnel, Mastodon) . En réponse au journal Le danger github. Évalué à 10.

    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).

  • [^] # Re: service...

    Posté par  (site web personnel, Mastodon) . En réponse au journal Le danger github. Évalué à 6.

    Si tu as les sources du « service » comme tu dis, tu peux le reproduire chez toi (ou ailleurs) à l'identique, si tu n'as pas les sources tu ne peux pas, du moins pas trivialement (tu peux toujours essayer de reproduire).

    Avoir tes données sur une machines que tu ne maîtrise pas est un autre problème, qui dépend beaucoup de la confiance que tu as en la personne ou l'organisme qui maîtrise la machine.

    Tu peux certainement récupérer tes données brutes sur Github, mais ça ne veut pas dire que tu pourras les réutiliser facilement, parce que si tu n'as pas le logiciel qui va avec tu vas devoir adapter (si c'est dans un format standard ça peut déjà grandement faciliter la tâche). Et Github ça n'est pas que git (qui lui est libre et décentralisé), c'est le système de revue, de bugs etc.

    À ça s'ajoute que github exploite ou peut exploiter tes données (je ne connais pas le modèle exacte de github, mais ça ne m'étonnerait pas qu'il utilise les données pour des offres d'emplois par exemple, après on aime ou pas c'est une autre question).

    Il y a tout un tas d'autre problèmes liés à la centralisation et à l'uniformisation, bref c'est un débat tout à fait pertinent.

    À titre perso, je suis particulièrement gêné que la XSF soit passé à github, car ça arrive de plus en plus souvent que des commentaires se fassent là bas au lieux d'être sur la liste de diffusion dédiée. Mais bon on s'éloigne de la problématique du logiciel propriétaire que tu citait.

  • [^] # Re: Xpra

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche Subuser, une sur‐couche à Docker. Évalué à 7.

    C'est pas un peu lourd par rapport a binder la socket X au lancement d'un conteneur ?

    En relisant ton commentaire je me dis qu'il faut préciser que c'est fait pour des raisons de sécurité, un serveur X permet aux applications d'accéder aux autres, mettre Xpra au milieu permet de les isoler.

  • [^] # Re: Correction

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche Subuser, une sur‐couche à Docker. Évalué à 3.

    salut,

    je dois pas être réveillé, je ne vois pas de différence, où est la faute ? Iceweasel est barré dans la N.D.T. en référence à ce journal.

  • [^] # Re: Xpra

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche Subuser, une sur‐couche à Docker. Évalué à 4.

    Comme je l'ai compris, les conteneurs avec les applications ont juste une socket et le serveur Xpra est dans un conteneur à part (le client est lui dans un autre conteneur).

    À l'usage, j'ai vu un Firefox tourner et on peut difficilement dire qu'il est dans un conteneur, c'est très fluide. Sur la page d'explications l'auteur indique que même pour les vidéos plein écran ça marche bien.

    Le système est pensé pour pouvoir changer de serveur facilement, aussi quand Wayland sera dispo, il devrait être facile de faire la transition.

  • [^] # Re: Fringe Events

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche Retour sur le FOSDEM 2016 à Bruxelles. Évalué à 6.

    Oué alors en fait, comme ça a été indiqué, j'ai fait circuler le lien il y a une semaine, notamment sur Diaspora, pour demander que tous ceux présents participent, pour qu'on fasse une grosse dépêche Fosdem.

    après plusieurs jours, personne ou presque n'a participé, et ceux qui l'ont fait ont parlé uniquement de XMPP, du coup on a renommé une première fois pour dire que c'était un retour sur la partie XMPP.

    À ce moment y'a eu 2 mini paragraphes sur des trucs qui n'ont rien à voir avec XMPP et qu'on n'a pas voulu supprimer, du coup on a re-renommé et on a mis la note pour dire que c'était principalement centré sur XMPP et qu'on pouvait toujours compléter en commentaires. C'était ça, ou virer des contributions (dont la tienne), ou attendre 6 mois pour avoir un truc potable et plus générique.

    Bref, c'est centré sur XMPP parce que c'est ce qu'on vu les (rares) contributeurs à ce compte rendu. Tes impressions tu peux aussi les mettre dans une nouvelle dépêche si tu veux rien ne t'en empêche.

  • [^] # Re: si votre serveur XMPP le prend en charge

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche Movim 0.9 - Tchouri. Évalué à 5.

    Pendant longtemps ce fut le seul serveur XMPP à implémenter correctement le protocole.

    c'est pas tout à fait vrai. Ejabberd (et donc probablement MongooseIM) et Openfire ont un excellent support de PubSub depuis longtemps (et je ne sais pas ce qu'il en est de Tigase que je n'ai jamais essayé), et Prosody le supporte mais ne gère pas pour le moment le stockage hors ligne (à ma connaissance). À la base Prosody se veut très KISS, et enregistre tout en fichiers, ce qui pose des problèmes pour PubSub (c.f. mes 2 journaux où j'explique ça : Retour de Berlin et De l'autre côté). Ça a évolué (il y a une API pour utiliser une BDD), mais je ne crois pas que c'est utilisé pour PEP à l'heure qu'il est.

    De notre côté nous avons développé notre propre service PubSub, et on le fait tourner avec Prosody. Vu que c'est un serveur taillé sur mesure, il a presque (*) tout ce dont nous avons besoin (et donc Movim aussi).

    (*) je dis presque parce qu'on n'a pas encore implémenté la gestion des présences nécessaire pour faire un vrai PEP

  • [^] # Re: si votre serveur XMPP le prend en charge

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche Movim 0.9 - Tchouri. Évalué à 2.

    C'est quand même possible de savoir si le serveur supporte ce que l'on désire (comme expliqué ici). Reste à faire ça joli dans l'interface: tu prends une liste de serveurs publiques, tu enlèves ou grises ceux qui n'ont pas ce que tu veux, et tu mets des icônes selon les fonctionnalités intéressantes, un peu dans l'esprit de ça: https://www.jabberes.org/servers/ .

    Tu peux même proposer par défaut une liste restreinte de serveurs bien testés, et proposer à ceux qui le souhaitent d'en choisir un autre. C'est pas les solutions qui manquent, le plus difficile, mais pas insurmontable, c'est de rendre ça facile et intuitif dans l'interface.

  • [^] # Re: Ouah!

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche XMPP à fond !. Évalué à 5.

    Salut

    Aujourd’hui j’utilise Telegram parce qu’il existe un client Android et un client GNU/Linux qui sont très bons, notamment grâce à la synchronisation des conversations. J’attends avec impatience d’avoir la même chose en décentralisé et chiffré de bout en bout! Pour le moment Jabber n’est pas vraiment utilisable pour mon usage…

    La synchronisation de salon est déjà possible avec MAM. Le chiffrement de bout en bout sur salon toujours pas par contre. Ça sera probablement un des sujet du summit à venir.

    Petite question, même si elle est sans doute un peu hors-sujet: une fonctionnalité très à la mode en ce moment, les autocollants (au moins dans Telegram, Line, Facebook), est fort sympathique. Il s’agit de collections d’images que l’on peut insérer en un clic dans la discussion, un peu comme des smileys mais plus grand. Y’a aussi des clients qui permettent d’enregistrer ses propres gifs pour pouvoir les ressortir plus tard

    Comme a dit Edhelas, c'est possible d'afficher des images via XHTML-IM.
    Mais pour être honnête, c'est pas le genre de fonctionnalités que j'ai très envie d'implémenter (les autocollants, pas les images).

  • [^] # Re: fosdem 2016

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche XMPP à fond !. Évalué à 4.

    J'ai fait (regardé) pas mal de confs l'année dernière, et du coup j'ai loupé du monde oui. Si je ne suis pas au lounge le mieux c'est encore de me chopper à la fin d'une de mes 2 confs, ou de me laisser un numéro de téléphone (ou une adresse courriel).

    Le dimanche je risque de partir tôt en milieu d'aprem.

  • [^] # Re: fosdem 2016

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche XMPP à fond !. Évalué à 4.

    Salut,

    moi oui, j'y ferai même 2 conférences (c'est indiqué dans la dépêche ;) ).

  • # Jingle ICE

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche XMPP à fond !. Évalué à 7. Dernière modification le 21 janvier 2016 à 17:22.

    La publication était vraiment imminente, la XEP est parue aujourd'hui: https://xmpp.org/extensions/xep-0371.html .

    En clair, ça signifie que les communications TCP (pour UDP il y avait déjà une XEP avant) pourront plus facilement traverser les NAT, ce qui va profiter en premier lieu au transfert de fichiers.

  • [^] # Re: Une série ?

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche Comment j’en suis venu à découvrir Linux, par Ian Murdock. Évalué à 2.

    Salut,

    framasoft a une équipe de traduction utilisant le framapad, je pense qu'un tel projet les intéresserait beaucoup, tu peux peut-être les contacter ? Avec Publication commune sur Framablog/DLFP ça serait top :)

  • [^] # Re: Violences faites aux diptères

    Posté par  (site web personnel, Mastodon) . En réponse au journal Quelques nouvelles en vrac de XMPP. Évalué à 3. Dernière modification le 20 janvier 2016 à 16:35.

    Salut,

    Sauf funeste erreur de ma part, ça n'a rien à voir. Le PFS est une propriété cryptographique, qui ne dépend pas (et heureusement) de la capacité à "stocker" un message. Après, la page Wikipedia d'OTR rappelle que GTalk disposait d'une option "off-the-records" qui ne faisait qu'annuler (au moins officiellement) l'archivage.

    La formulation est sans doute raccourcie, mais c'est bien ce que je voulais dire (et ça n'est bien sûr par une confusion avec l'OTR de GTalk, je n'ai même jamais utilisé ce dernier). Bien entendu une fois que le message est déchiffré, tu peux en faire ce que tu veux, mais le principe de le confidentialité persistante, du moins telle qu'implémentée dans OTR, fait que tu as une clef temporaire, jetable, et qu'il faut être en ligne en même temps pour échanger le message, du coup c'est à cause de PFS que tu ne peux pas utiliser OTR hors ligne. Après je ne suis pas expert en chiffrement, il est possible que je me trompe.

    D'ailleurs dans le brouillon de la nouvelle XEP OpenPGP, ils mentionnent même l'absence de confidentialité persistante (PFS) comme un moyen de chiffrer ses archives MAM.

    Encore sous réserve de bon fonctionnement de mes neurones, c'est à peu près exactement l'inverse : les petits trous du "hole punching" ne sont qu'une des techniques utilisées par l'ICE. En gros, l'ICE c'est "je tente de passer en direct… ah non zut ça passe pas, bah je vais essayer divers contournements de NAT alors …. ah ben non plus, vous auriez un relai TURN sivouplé?".

    Une autre XEP que je n'ai pas encore implémenté, donc que je ne maîtrise pas. Il faudrait à ce moment changer comme suit:

    s/ICE est une méthode pour faire du « TCP hole punching », une méthode pour traverser les NAT/ICE est une méthode pour faire de la traversée de NAT/

    Si un modo passe par là…

    Merci pour la correction.

  • [^] # Re: Flarum et NodeBB : forums ng faciles à installer

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche Discourse, plate-forme de discussion atypique. Évalué à 4.

    Je suis curieux de savoir ce que vous attendez d'un tel logiciel, parce que dans la liste des fonctionnalités que je vois ici, y'en a beaucoup qu'on recoupe.

    Ça m'intéresse parce que maintenant qu'on a fait l'essentiel des couches basses, c'est beaucoup sur l'interface qu'il y a du travail.

    Bref, quels sont les fonctionnalités essentielles selon toi (ou d'autres) d'un « forum nouvelle génération » ? Et qu'est-ce qui le différencie d'un forum « ancienne génération » à la phpBB ?