Journal Un réseau offline "delay-tolerant" avec NNCP

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
30
13
oct.
2021

Cher journal,

Je m’intéresse particulièrement à la création d’un réseau décentralisé, offline et "delay-tolerant".

Un réseau offline ou "delay tolerant" ? Kezako ?

C’est un réseau sur lequel les nodes ne se connectent que ponctuellement. L’accès aux données n’est pas immédiat et 2 nodes peuvent communiquer même s’ils ne sont jamais connectés ensembles. (il existe d’autres noms comme "sneakernet", je ne maitrise pas toutes les subtilités).

Lowtech en parle dans la seconde partie de cet article :
https://solar.lowtechmagazine.com/2015/10/how-to-build-a-low-tech-internet.html

De manière étonnante, je trouve assez peu de logiciels pour créer ce genre de réseau de manière assez transparente. Pire : la plupart de nos logiciels exigent désormais une connexion permanente. Même un protocole comme l’email, qui est asynchrone par nature, est difficile à mettre en place de manière structurelle en mode delay-tolerant (les clients mails s’attendent désormais à une connexion IMAP et SMTP permanente sous peine d’erreurs, aucun client graphique ne supporte plus le format local Maildir nativement, etc).

J’ai cependant découvert une suite logicielle très intéressante appelée NNCP. NNCP est une série d’outils qui servent à transmettre et synchroniser des fichiers entre des ordinateurs rarement connectés ensemble voire même air-gapped (pas de connexion physique du tout, la synchronisation se faisant avec une clé USB).

http://www.nncpgo.org/index.html

Le problème de NNCP c’est que la documentation est pour le moins minimaliste. NNCP nécessite également un routing manuel. Si je veux synchroniser A et B, je dois manuellement indiquer que C sert d’intermédiaire. Pas de routing automatique donc.

Le développeur Debian John Goerzen s’est passionné pour le sujet et a écrit plusieurs articles qui servent d’à peu près unique documentation du bazar.

Il a notamment imaginé combiner NNCP et Syncthing :
https://changelog.complete.org/archives/10219-a-simple-delay-tolerant-offline-capable-mesh-network-with-syncthing-optional-nncp

ou NNCP et Git
https://changelog.complete.org/archives/10274-distributed-asynchronous-git-syncing-with-nncp

Le tout semble quand même assez périlleux à mettre en place.

Je me demandais donc si vous connaissiez des solutions dédiées à la création de réseaux delay-tolerant. Intuitivement, des briques logicielles existantes comme git pourraient jouer un rôle mais, en creusant, le problème se révèle assez rapidement complexe : notion d’intégrité d’un fichier (pour qu’il ne soit pas altéré par un intermédiaire), notion de routing, etc.

QQn a déjà creusé le sujet ici ?

  • # email, maildir, offline, etc.

    Posté par  (Mastodon) . Évalué à 9.

    Je te trouve un peu dur au sujet de l'email.
    KMail, sylpheed et même Thunderbird comprennent le Maildir.
    Ils ont tous une option d'envoi différé et un bouton envoi/réception (parfois séparé aujourd'hui).
    Sur sylpheed tu as même le bouton pour passer offline manuellement, et ne pas risquer de faire des requêtes sans une petite popup qui te demande si tu veux passer online pour faire ça.
    Même sous Android, avec K9-Mail tu as la boîte d'envoi, qui va envoyer quand il peut.

    Et les serveurs mails gèrent bien l'accès discontinu avec une tolérance de base de 4h il me semble, avant de te renvoyer un message d'indiquant que pour le moment ça rate, et jusque 7j avant abandon.

    Après, c'est sûr que ça foire totalement avec les webmails, qui ne sont que des interfaces avec un serveur mail.

    Pour d'autres aspects, si tu as dans ton réseau interne ton propre serveur XMPP, il me semble qu'il a aussi un comportement similaire, capables de conserver les messages à envoyer pendant un certain temps, tant qu'il n'arrive pas à se connecter au serveur distant.
    Par contre les clients ne gèrent pas l'envoi de message en étant hors-ligne (enfin pas que je sache), donc tu as besoin d'avoir en local ton propre serveur XMPP pour faire comme avec un serveur SMTP : tu lui files le bébé, et il se démerde ensuite.

    Un outil de synchronisation de fichiers comme syncthing peut très bien ne travailler que quand il a de la connectivité et reprendre où il en était de façon transparente dès que cette dernière revient. Y compris en changeant complètement de réseau, entre chez toi, ta location de week-end, ton boulot, ou la connexion 4G partagée de ton téléphone.

    Bref, quelques vagues pistes sur des petits aspects de tout un réseau à l'en-lignage inconstant.

    • Yth.

    • [^] # Re: email, maildir, offline, etc.

      Posté par  (site web personnel, Mastodon) . Évalué à 5.

      "KMail, sylpheed et même Thunderbird comprennent le Maildir."

      non.

      Pour Kmail, je ne sais pas (pas envie d’installer 344Mo de dépendances pour tester).

      En ce qui concerne sylpheed et claws-mail, ils supportent un autre format (MH) mais pas nativement le maildir. Il suffit d’essayer avec un répertoire maildir existant : ça ne fonctionne pas.

      Thunderbird non plus.

      Plusieurs personnes ont réussi à le faire fonctionner mais, d’après ce que je lis :

      1. c’est du bidouillage
      2. Ce n’est pas parfait et ça peut foutre le bronx dans tes mails.

      "Et les serveurs mails gèrent bien l'accès discontinu avec une tolérance de base de 4h il me semble, avant de te renvoyer un message d'indiquant que pour le moment ça rate, et jusque 7j avant abandon."

      C’est utile pour gérer le cas de déconnexion intempestive mais cela suppose une connexion au moins régulière. La déconnexion est vue comme une exception.

      Dans le cas d’un DTN, c’est le contraire. La connexion est vue comme très rare et imprévisible. Lorsque la connexion est là, le système en profite pour faire le maximum possible de la manière la plus efficace.

      Mes livres CC By-SA : https://ploum.net/livres.html

      • [^] # Re: email, maildir, offline, etc.

        Posté par  (Mastodon) . Évalué à 3.

        Pour Thunderbird, mes comptes sont configurés en maildir depuis plusieurs années, sans aucun problème, à part le fait d'avoir beaucoup moins de lenteurs avec plusieurs gigas d'emails stockés.

        La subtilité étant d'aller dans les préférences générales et de changer "Message store for new account" de "mbox" à "maildir", puis seulement après de créer son compte, car une fois créé on ne peut pas changer le type de stockage d'un compte.

        • [^] # Re: email, maildir, offline, etc.

          Posté par  (site web personnel, Mastodon) . Évalué à 2.

          Y’a un truc qui doit m’échapper : comment tu fais pour avoir un folder Maildir que tu gères manuellement (avec mbsync par exemple) et auquel Thunderbird accède pour visualiser les mails, les trier, etc.

          À ma connaissance, il est impossible de créer un compte mail sous thunderbird qui ne soit pas lié un compte IMAP/SMTP. Cette impossibilité me semble d’ailleurs confirmée par le fait que toutes les solutions que j’ai vue sur des stackoverflow/etc impliquent d’installer en local ton propre serveur IMAP pour ensuite faire communiquer Thunderbird avec (et oui, ça duplique ta boite mail sur ton disque dur).

          Mes livres CC By-SA : https://ploum.net/livres.html

      • [^] # Re: email, maildir, offline, etc.

        Posté par  (Mastodon) . Évalué à 3.

        Ok, donc dans l'idéal il faudrait un truc capable de synchro un dossier type maildir, qui serait analysé par un serveur à la synchro et ferait des envois/réceptions ?

        Comme ça tu peux être au milieu de trifouillis-sous-cambrousse, récupérer les dossiers de tout le monde sur un périphérique, et aller envoyer ça dans le vaste monde avec un petit trek de 12h pour chopper une antenne Edge ?
        Mais cette logique se base quand même sur l’existence d'un réseau global type internet, c'est juste toi ou ton groupe, qui êtes déconnectés.

        Syncthing c'est une bonne réponse à ce genre de problématiques, mais tu dois définir tes connexions.
        Tu pourrais définir un groupe de gens avec leurs périphériques, qui se partagent un - ou plein - de répertoires, et dès que deux d'entre eux sont en contact, paf ça synchronise entre eux.
        De proche en proche tout se transmet au gré des rencontres.
        Mais pour ça il faut une connexion réseau local entre deux proches, ou une connexion commune à internet à un instant donné.

        Et à moins de combiner avec d'autres outils, tu n'as pas de porteur neutre d'un message qui ne lui est pas destiné et que seul le destinataire final peut lire (problématique potentiellement soluble avec du PGP, mais il faut automatiser).
        Et puis faire du chat/mail avec ça n'est pas simple : comment tu lâches un simple fichier à droite à gauche qui se transformerait en mail chez son destinataire ?

        Donc il faudrait construire au dessus d'un outils de partage brut comme syncthing, un autre système permettant de laisser des fichiers chiffrés à destination d'une personne (ou d'un terminal) en particulier, qui puisse ensuite, selon son format, ou ses métadonnées, être utilisé dans différents contextes (mail/discussion, photos de chats, documents…).

        Tout dépend de ce que tu veux partager, comment, ensuite.

        Et surtout de si tu es intéressé par la connexion avec internet, et l'envoi de divers données selon des protocoles plus connectés (transformation de tel fichier en email envoyé sur un SMTP, tel autre en messages postés sur un forum ou un salon de discussion, telle vidéo sur telle instance peertube, tel document sur un blog, etc).
        Et potentiellement récupérer en retour des réponses : checker tes nouveaux mails, récupérer la conversation dudit salon, récupérer les commentaires sur ton précédent post de blog etc.
        Mais ça veut dire une infra bien mise en place sur internet, un serveur (ou des services) configuré aux petits oignons.
        Par exemple une passerelle XMPP qui lirait une série de fichiers et en ferait des articles de blog et des messages pas si instantanés sur Movim, avec réception des messages en attente (abonnements micro-blogging, messages persos, etc.) qui feraient le chemin inverse vers ton client local.
        Un client XMPP-filesystem qui bosserait avec des données chiffrées, que toi seul pourrait déchiffrer depuis ton terminal (et ton client XMPP local avec ta clé PGP) une fois les fichiers synchronisés et en utilisant de l'autre côté la même passerelle filesystem-XMPP en mode serveur local, pour ton client local.

        Bref, tu aurais des cas d'usage pratiques ?

        • Yth.

        • [^] # Re: email, maildir, offline, etc.

          Posté par  . Évalué à 5.

          Les dernières version de Syncthing ajoutent l'option de chiffrer les données pour pouvoir les partager sur des appareils qui n'ont pas à voir le contenu mais pourront à leur tour le partager jusqu'au destinataire final qui lui aura le mot de passe pour y accéder.

        • [^] # Re: email, maildir, offline, etc.

          Posté par  (site web personnel, Mastodon) . Évalué à 3.

          Voilà, je pense que tu as compris la problématique. C’est loin d’être simple. Pour le pratique, je t’invite à lire le blog de John Goerzen qui semble être à fond dans ce trip. Il y’a aussi Hundredrabbits, un couple qui vit sur un bateau.

          Mais je comprends que c’est un truc de niche et que le concept n’intéresse pas tout le monde.

          Mes livres CC By-SA : https://ploum.net/livres.html

      • [^] # Re: email, maildir, offline, etc.

        Posté par  . Évalué à 5.

        Et les serveurs mails gèrent bien l'accès discontinu avec une tolérance de base de 4h il me semble, avant de te renvoyer un message d'indiquant que pour le moment ça rate, et jusque 7j avant abandon.
        C’est utile pour gérer le cas de déconnexion intempestive mais cela suppose une connexion au moins régulière. La déconnexion est vue comme une exception.

        Euh… Je ne vois pas trop ce que tu voudrais. Tu ne pourras jamais faire la différence entre un serveur qui se connecte une fois tous les 36 du mois et un serveur qui ne se connectera plus jamais. Du coup, tu fais quoi avec tes mails quand le serveur de destination n'est pas joignable? Il faut bien à un moment prévenir l'expéditeur que le mail n'est pas arrivé.

        De toutes manières, autant je peux comprendre qu'il soit prévu qu'un client mail ne soit pas connecté 100% du temps, autant un serveur mail… Ça sert vraiment à quelque chose de mettre en place un serveur mail pour un seul utilisateur? Du genre, tu héberges ton serveur sur ton ordinateur portable, et paf, il arrive en ligne quand tu démarres la machine? Dès que tu as un deuxième utilisateur du serveur sur une autre machine, il ne va jamais réussir à relever ses mails, c'est infernal.

        Du coup, ce qui est important, c'est de gérer la déconnexion des clients, pas des serveurs. Un serveur déconnecté, c'est une panne.

  • # Normes DTN

    Posté par  (site web personnel, Mastodon) . Évalué à 7.

    Du côté des normes techniques, on peut regarder le travail DTN à l'IETF (et le protocole Licklider). RFC 4838 https://www.bortzmeyer.org/4838.html et suivants.

    • [^] # Re: Normes DTN

      Posté par  (Mastodon) . Évalué à 2.

      L'interview de Vint Cerf est très intéressante sur le sujet !
      Je recommande d'aller lire tout ça.

      • Yth.

  • # Edgenet

    Posté par  (site web personnel) . Évalué à 3.

    C'est ce que Pieter Hintjens voulait faire avec Edgenet et Zeromq:

    http://hintjens.com/blog:76

    Il faudrait continuer le projet Hydra:

    https://github.com/ZyreApps/hydra

  • # Fidonet ?

    Posté par  . Évalué à 3.

    Je ne sais pas si ça correspond à tes besoins, mais dans les années 90, il y avait Fidonet qui permettait les échanges entre PC dont le modem était allumé "de temps en temps". Visiblement, il n'est pas encore mort.

    • [^] # Re: Fidonet ?

      Posté par  . Évalué à 5.

      Et plus récemment il y a un espèce de réseau social de ce type qui s'est créé : Scuttlebutt : si j'ai bien suivi, l'idée est effectivement d'être offline de ce réseau la plupart du temps, mais de se synchroniser soit avec ses amis (wifi/usb), soit de passer par des pubs (des bots toujours accessibles online).
      le protocole développé permet en fait de faire plus de choses qu'un réseau social.

      • en creusant vite fait, quelques applications l'utilisant sont présentées ici

      • [^] # Re: Fidonet ?

        Posté par  (Mastodon) . Évalué à 4.

        J'ai essayé de l'utiliser, après un jour d'utilisation la seule appli (je ne me rappelle plus son nom) utilisant scuttlebut que j'avais trouvé sur f-droid s'est mise à crasher à chaque ouverture.

        Alors ouais je sais on parle ici d'un bug sur une des implémentations. Le problème c'est qu'il n'y en a pas 10000 et que ça refroidit vite.

    • [^] # Re: Fidonet ?

      Posté par  . Évalué à 4. Dernière modification le 14 octobre 2021 à 10:06.

      Vivement la résurrection de A.C.E. BBS ! et merci à Gandalf et aux autres pour tous ces merveilleux moments !

      • [^] # Re: Fidonet ?

        Posté par  . Évalué à 2.

        Eden était bien aussi.

        Une pensée pour Tchi :)

        Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr

  • # Retroshare ?

    Posté par  . Évalué à 5.

    Retroshare est un réseau P2P F2F, et une suite logiciel qui gère l'échange de fichiers, mais aussi des forums, l'echanges de messages et ptetre d'autres trucs que j'ai totalement oublié.

    Dans le principe, les réseaux p2p sont conçus pour ne pas avoir de serveur central contenant les donnés, n'ayant pas besoin de l'ensemble des noeuds existants qui soient connectés, et pour justement gérer le routage automatiquement. A voir si ca fonctionne aussi avec 2 PC sur un même LAN coupé d'internet, mais dans le principe ca se rapproche de ce que tu cherches je trouve.

    Emacs le fait depuis 30 ans.

  • # pas étonnant

    Posté par  . Évalué à 4.

    De manière étonnante, je trouve assez peu de logiciels pour créer ce genre de réseau de manière assez transparente. Pire : la plupart de nos logiciels exigent désormais une connexion permanente.

    Pour ma part je ne trouve pas ça étonnant.
    La grande majorité des utilisateurs ont une connexion permanente, il me semble donc que le temps de dev (qui est limité par essence) serait mieux utilisé en travaillant sur les problèmes de cette majorité (améliorer la fiabilité, la vitesse, l'ergonomie ou autre).

    On me l'a déjà demandé sur certains logiciels que je développe, mais je ne l'ai jamais fait. Je ne conteste pas que ce soit une fonctionnalité qui peut se révéler utile (mes clients auraient pu travailler lors de la panne OVH d'hier, par exemple), mais le jeu n'en vaut pas la chandelle à mon avis. Le temps de dev de mon équipe est mieux occupé ailleurs.

    • [^] # Re: pas étonnant

      Posté par  (site web personnel, Mastodon) . Évalué à 8.

      ta réflexion est pertinente dans le cadre d’un développement ad-hoc pour un client où la connexion permanente fait partie du cahier des charges.

      Pour les logiciels grand-public, cela revient à exclure toute une partie du monde : ceux qui n’ont pas de connexion permanente pour raison financière ou pour raison d’infrastructure (beaucoup de régions sont encore mal couvertes, je t’invite à lire les liens que j’ai mis dans le journal).

      C’est de nouveau la notion de privilège : l’homme blanc occidental sans handicap visuel à une connexion permanente, un écran retina et un nouveau processeur et voit donc toute optimisation pour un autre cas d’usage comme une perte de temps. Ce qui va exclure une partie de la population et mettre une pression terrible à une autre (aller une fois par jour se connecter au wifi du café du coin, on va payer 50€/mois pour une connexion permanente, 100€/mois pour des nouveaux téléphones et vu qu’on a payé cette box qui vient avec abonnement télé, on va en profiter pour que les enfants regardent des dessins animés tandis que nous on est sur nos téléphones).

      Ces simples choix par facilités de la classe privilégiée ont, en fait, un impact incroyable social et écologique. Je ne crois pas trop me tromper en disant d’ailleurs que toute la crise climatique actuelle peut se résumer à "une partie privilégiée du monde a pris et continue à prendre des choix qui sont plus faciles à court terme pour elle, nonobstant l’impact sur le reste du monde".

      Pourquoi est-ce que de nombreuses applications ne tournent pas sur un système relativement ancien ? Parce que les développeurs ont considéré que tout le monde avait de toutes façons un nouveau système. Pourquoi est-ce que tout le monde a un nouveau système ? Parce que les nouvelles apps ne tournent pas sur l’ancien. (cercle vicieux alimenté, en plus de cela, par le marketing évidemment).

      Mes livres CC By-SA : https://ploum.net/livres.html

      • [^] # Re: pas étonnant

        Posté par  . Évalué à 5.

        Pourquoi est-ce que de nombreuses applications ne tournent pas sur un système relativement ancien ?

        Bah je sais pas, si faut viser Windows XP aujourd'hui ça devient chaud. Ou même Windows 7. Qui lui, n'est pourtant pas si vieux. Mais il est déjà obsolète !

        Par contre la connexion permanente à Internet ça m'horripile. Je vis ça avec postman, qui au départ était très pratique pour tester des APIs.

        Maintenant, il n'a pas de concurrence, et cet idiot en profite pour exiger une connexion à Internet pour sauvegarder tout ce que tu fais dans le Cloud. Mais quelle bêtise !

        Et quand y'a pas de connexion, tu peux même pas voir ce que tu as écrit précedemment. Mais quelle connerie ! Vas y j'en ai des kilo-octets en local pour 2/3 JSON, p'tain !

        Qu'on pendent les décideurs !

        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

        • [^] # Re: pas étonnant

          Posté par  . Évalué à 3.

          Maintenant, il n'a pas de concurrence[…]

          Je n'ai jamais était fan de postman, mais en outil du même genre tu as soapui (qui contrairement à ce que son nom indique ne se limite pas à soap). En client rest avec moins de fonctionnalités (pas de scripting principalement), tu as rest-client, une extension de vscode. L'utilisation de simples fichiers textes permet de partager facilement les requêtes contrairement à postman.

          Je me doute que tu as des fonctionnalités que tu ne retrouvera pas, mais comme je ne connais pas très bien postman je suis intéressé de savoir les quels.

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: pas étonnant

            Posté par  (site web personnel, Mastodon) . Évalué à 3.

            Dans le même genre que Postman, j'avais trouvé Insomnia (sous licence MIT) comme client d'API REST et qui peut être étendu avec des plugins.

            Par exemple, j'emploie l'extension Global Header pour ajouter une en-tête Origin pour les APIs qui vérifient CORS. En plus de celle-ci j'emploie save access token pour configurer une en-tête Authorization avec un access token récupérer d'une requête OAuth2.

      • [^] # Re: pas étonnant

        Posté par  (site web personnel) . Évalué à 6.

        Pourquoi est-ce que de nombreuses applications ne tournent pas sur un système relativement ancien ? Parce que les développeurs ont considéré que tout le monde avait de toutes façons un nouveau système. Pourquoi est-ce que tout le monde a un nouveau système ? Parce que les nouvelles apps ne tournent pas sur l’ancien. (cercle vicieux alimenté, en plus de cela, par le marketing évidemment).

        Le problème aussi c'est un manque de temps, d'argent et de matériel.

        Ton développeur ne peut pas travailler sur le support d'un matériel ancien qu'il n'a plus lui même. Et comme son temps et ses finances sont limitées, il ne peut pas s'occuper de tout le monde à la fois, les demandes plus complexes qui ne l'intéressent pas ou qui concernent trop peu de monde sont souvent refoulées. Mais c'est valable pour plein de chose, pas que le support d'un matériel ancien.

      • [^] # Re: pas étonnant

        Posté par  . Évalué à -3.

        C’est de nouveau la notion de privilège : l’homme blanc occidental sans handicap visuel à une connexion permanente,

        On regrette presque d'être aveugle quand on lit ce genre de débilité.

  • # git?

    Posté par  (site web personnel) . Évalué à 4.

    Pour les fichiers pourquoi ne pas utiliser un gestionnaire de version ?

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: git?

      Posté par  . Évalué à 4.

      Alors, git… non.

      Un DVCS, oui, peut-être, mais pas git.

      Ce que je reproche à git, notamment pour un usage de ce type:

      • ne résiste pas aux déconnections (git clone d'un truc un peu gros sur une connection pourrie, couper la co: doit reprendre à zero);
      • performances exécrables (overhead du disque dur, bande passante, surtout quand on commence a utiliser des submodules), d'ou l'existence de git-lfs d'ailleurs (jamais testé, je sais pas ce que ça vaut, mais ça sent le workaround a 10 km);
      • interface horrible (on va pas se mentir: utiliser git, ça va à peu près, quand on a l'habitude, mais il suffit de voir quelqu'un qui apprend… c'est pas simple du tout). Attention: je ne connais pas mieux (ce qui ne veut pas dire que ça n'existe pas) mais le problème reste réel;

      Outre ces points, il requiert une série d'actions complexes pour synchroniser des points ensemble, et je ne parle que de point à point (la gestion des conflits est loin d'être simple, et les patchs de conflit à résoudre qu'il génère sont loin d'être minimaux ou d'avoir une sémantique potable, en tout cas par défaut, peut-être que ça se configure…). Je n'ose imaginer le merdier à gérer pour avoir plus de 2 ou 3 cibles "remote"… et ça, c'est probable que ça soit pour tous les DVCS.

      Il est possible qu'un autre DVCS fasse mieux: got par exemple, l'implémentation WiP d'openBSD, ou, possiblement encore plus mieux (parce que liés à git d'aucune façon), fossil, mercurial… mais git est bien le dernier que j'utiliserais pour un tel usage (je part du principe que le réseau ne doit pas être élitiste, donc un truc facile à utiliser et à apprendre pour un non-dev).
      Probablement fossil, en fait. Au moins, par défaut il a une interface graphique (je considère une application web comme une interface graphique, oui), et déplacer un dépôt fossil est nettement plus simple: un seul fichier à déplacer.

      • [^] # Re: git?

        Posté par  (site web personnel) . Évalué à 3.

        […] d'ou l'existence de git-lfs d'ailleurs (jamais testé, je sais pas ce que ça vaut, mais ça sent le workaround a 10 km);

        D'après des développeurs de Mercurial, leur version de lfs est inspirée de celle de Git mais est mieux faite car ils ont aussi appris des défauts de git-lfs.

        interface horrible (on va pas se mentir: utiliser git, ça va à peu près, quand on a l'habitude, mais il suffit de voir quelqu'un qui apprend… c'est pas simple du tout).

        L'interface de Mercurial me semble mieux conçue que celle de Git. Les sorties sont homogènes entre elles. Par contre, étant moins utilisé, beaucoup moins d'infos sont disponibles, ce qui est moins pratique pour les débutants. De même, rebase doit être activé (c'est une ligne dans un .hgrc) ce qui peut surprendre quand on vient de Git.

        Pour les autres éléments cités précédemment, je pense qu'il n'y a pas de différence significatives entre Git et Mercurial.

        • [^] # Re: git?

          Posté par  . Évalué à 2.

          Je suis, ou ai été, sûrement très con, mais en fait, la raison initiale qui m'a fait rejeter hg était… c'est en python. Et j'avais (et toujours en vrai) plus confiance dans les langages compilés qui ont, par défaut, un minimum d'analyse statique.

          Je n'ai aucune opinion sur hg en soit, et j'en ai entendu pas mal de bien.

          D'un autre côté, je suis content d'avoir fait confiance à un outil codé dans un langage standardisé ISO vue la transition «difficile» entre python 2&3.

          Ceci n'est en revanche qu'un détail d'implem. Git commence a avoir un 2nd utilisateur got, qui le rend d'autant plus crédible. À quand un autre outil de versionning assez fiables et simples sur le long terme pour avoir d'autres clients qui émergent (l'inverse du web)?

          • [^] # Re: git?

            Posté par  (site web personnel, Mastodon) . Évalué à 3.

            Tut tut tut, me semble que tous les gestionnaires de versions, libres et décentralisés, nés en 2005 ont leur cœur écrit en C… Mercurial a fait le choix de Python là où Git utilise en général Bash, et cela ne te fait pas dire que ce dernier est écrit en shell.

            • Git : C, Shell Unix, Perl, Tcl, Python et C++
            • Mercurial : Python, C et Rust
            • Bazaar : Python, Pyrex et C
            • feu Codeville : Python, ??

            Dans le temps on a commencé à passer progressivement de C à C++ et Rust pour Git et Mercurial respectivement.
            Sinon, la qualité et le suivi du code de Mercurial sont tels que les ruptures de compatibilité de Python n'ont jamais posé de problème (du moins à ma connaissance.)

            “It is seldom that liberty of any kind is lost all at once.” ― David Hume

  • # Comment créer un Internet low-tech

    Posté par  . Évalué à 7. Dernière modification le 14 octobre 2021 à 12:39.

    Au cas où certains n'auraient pas vu, cet article très intéressant existe aussi en français :
    https://solar.lowtechmagazine.com/fr/2015/10/how-to-build-a-low-tech-internet.html

    https://solar.lowtechmagazine.com/fr/ pour les amoureux de la technique élégante

  • # systemd

    Posté par  . Évalué à 3.

    Sans connexion internet filaire malgré moi, je me suis retrouvé en 4G à 7Go/mois, 5ko/s au-delà.

    Je branche mon téléphone en USB, vu comme une carte réseau. Dans un netup.target j'ai fait un BindTo sur le device. Ensuite je mets scripts et timers (en mode persistant) dans le netup.target.wants.

    Ça se réveille quand je branche le réseau, ça se rendort quand je déco. Après le but c'est d'éviter au max le bloatware qu'est devenu le www, et pour ce dernier de désactiver un max de chose : scripts, images, etc.

  • # Scuttlebutt réseau social pour connexions intermittentes

    Posté par  . Évalué à 4.

    Pour ce que le sujet intéresse, j'avais rapidement testé https://scuttlebutt.nz/ et trouvé ça très intéressant (le seul truc que je n'avais pas trouvé encore abouti était l'utilisation disque un peu haute, mais ça pourra s'améliorer).

    L'idée est d'un réseau où chacun à sa chaînes de notes. De temps en temps on peut se connecter en allant au "café" (virtuel, où imaginons aussi un endroit) et synchroniser nos notes et du coup synchroniser aussi les flux de nos amis communs.

  • # UUCP

    Posté par  . Évalué à 3.

    Il n'y a que moi ou cela vous fait également penser au projet uucpssh.org qu'avaient lancé les fondateurs de linuxfr.org. Souvenir, souvenir: http://linuxfocus.org/Francais/March2004/article330.shtml

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.