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 Yth (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.
[^] # Re: email, maildir, offline, etc.
Posté par ploum (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 :
"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 Pierre-Alain TORET (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 ploum (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 Luvwahraan . Évalué à 2.
Il est possible de créer un compte sans IMAP.
C'est comme avec, mais il faut choisir configurer manuellement, puis configuration avancée, ce qui va créer le compte quelque soit la config.
Ensuite on peut changer le stockage des messages.
[^] # Re: email, maildir, offline, etc.
Posté par bertile . Évalué à 3.
Le stockage se fait au format maildir, mais effectivement la relève des messages est en IMAP ou POP. Après, l'objectif de Thunderbird n'est pas de fonctionner en 100% maildir, donc, RAS.
[^] # Re: email, maildir, offline, etc.
Posté par cg . Évalué à 5.
Tu as raison Ploum ! Le non-support du format Maildir "habituel" dans Thunderbird est plutôt bien documenté :
https://support.mozilla.org/fr/kb/maildir-thunderbird
https://wiki.mozilla.org/Thunderbird/Maildir
https://bugzilla.mozilla.org/show_bug.cgi?id=845952
En résumé, pour le moment Thunderbird fait un truc qui ressemble à du Maildir, mais ce n'est pas du Maildir. Ça finira bien par arriver !
En attendant, c'est ce qui fait que je ne peux pas utiliser mutt et Thunderbird sur le même répertoire de mails. Du coup je n'utilise que mutt :-/.
[^] # Re: email, maildir, offline, etc.
Posté par Philippe F (site web personnel) . Évalué à 6.
Tu rigoles ? Ca fait plus de 10 ans que c'est comme ça et il n'y a plus aucun investissement sur maildir ou dans Thunderbird en général. C'est parti pour rester encore loooooooooooooongtemps comme ça.
[^] # Re: email, maildir, offline, etc.
Posté par Yth (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 ?
[^] # Re: email, maildir, offline, etc.
Posté par ptit_poulet . É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 ploum (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 Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 2.
Et qu'on retrouve dans les captures d'écran du site de ScuttleBug, mentionné dans un commentaire plus bas.
[^] # Re: email, maildir, offline, etc.
Posté par arnaudus . Évalué à 5.
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 Stéphane Bortzmeyer (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 Yth (Mastodon) . Évalué à 2.
L'interview de Vint Cerf est très intéressante sur le sujet !
Je recommande d'aller lire tout ça.
# Edgenet
Posté par Benjamin Henrion (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
[^] # Re: Edgenet
Posté par Benjamin Henrion (site web personnel) . Évalué à 3.
Archive ici:
https://web.archive.org/web/20201218134724/http://edgenet.io/#/
https://www.youtube.com/watch?v=0_dfrHxLOrc
[^] # Re: Edgenet
Posté par Benjamin Henrion (site web personnel) . Évalué à 1.
NNTP mentioné dans la vidéo:
https://www.youtube.com/watch?v=SPpM-gsqnQU&t=0s
# Fidonet ?
Posté par Yannick (site web personnel) . É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 hugotrip . É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.
[^] # Re: Fidonet ?
Posté par Psychofox (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 Benjamin Henrion (site web personnel) . Évalué à 1.
Un lien vers le bug en question?
[^] # Re: Fidonet ?
Posté par symp . Évalué à 2.
Manyverse ?
[^] # Re: Fidonet ?
Posté par Psychofox (Mastodon) . Évalué à 3.
je crois oui
[^] # Re: Fidonet ?
Posté par Anonyme . É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 jseb . É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 Astaoth . É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 guppy . Évalué à 4.
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 ploum (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 xcomcmdr . Évalué à 5.
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 barmic 🦦 . Évalué à 3.
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 Adrien Dorsaz (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érifientCORS
. En plus de celle-ci j'emploie save access token pour configurer une en-têteAuthorization
avec un access token récupérer d'une requête OAuth2.[^] # Re: pas étonnant
Posté par Renault (site web personnel) . Évalué à 6.
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 ckiller . Évalué à -3.
On regrette presque d'être aveugle quand on lit ce genre de débilité.
# git?
Posté par devnewton 🍺 (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 freem . É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:
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 srb (site web personnel) . Évalué à 3.
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.
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 freem . É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 Gil Cot ✔ (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.
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 yannv . É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 Pierre_Roc . É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 Alex G. . É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 Vroum . É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.