rakoo a écrit 933 commentaires

Le langage et la bibliothèque standard resteront retro-compatibles, c'est dans le contrat (et c'est pas juste une promesse, les développeurs de Go eux-mêmes se rendent compte de certains problèmes avec les APIs telles qu'elles sont aujourd'hui, qui auraient pu être pensées un peu plus génériquement pour être plus facilement utilisables mais qu'ils ne peuvent pas casser)

Pour l'écosystème, par définition, c'est pas quelque chose garanti par une entité en particulier donc il faut y aller a la confiance… mais c'est la même chose dans les autres langages de toute façon.

La retro-compatibilité est aussi un des buts de Go (voir cette page), ça devrait aller de ce cote la.

Oui, c'est sur, si tu veux que la totalité de ton infrastructure soit écrite dans un seul et unique langage, Erlang est probablement la réponse. Sauf que justement il n'y a pas besoin de se contenter d'un seul et unique langage, si tu veux scaler tu dois jouer sur l'architecture de ton système. Il faut voir les microservices comme des librairies, avec l'avantage que tu peux les utiliser depuis n'importe quel langage.

Petite correction:

elles illustrent les risques de se baser sur une techno non libre contrôlée par un seul acteur pour développer son activité Oracle

Il ne faut pas se tromper de cible, le gros problème dans l'histoire c'est bel et bien Oracle qui, comme a son habitude, casse volontairement les pieds de tout le monde juste pour se faire plus d'oseille. Non pas que j'ai un problème avec l'oseille ou les gens qu'y s'en font, mais on a justement la un projet théoriquement libre mais qui en pratique se comporte comme un système propriétaire.

Et pour ceux qui doutent encore, Oracle n'en est pas a son coup d'essai. Loin de la, on se souvient de l'historique d'OpenSolaris qui a du être forké, d'OpenOffice qui a été lâchement abandonné, du créateur de MySQL qui a préféré forker MySQL que de le laisser dans les mains d'Oracle. Java EE n'est qu'un bullet point dans la liste des projets qu'Oracle tue sans laisser la communauté prendre les commandes.

Et les mails n'ont pas été conçus pour envoyer du contenu mis en page, et n'ont pas été conçus pour envoyer autre chose que du texte. Ce qui n'a absolument pas empêché ces deux utilisations de se développer, au grand dam des puristes. De la même manière les réseaux téléphoniques n'ont pas été conçus pour envoyer des messages… et pourtant les SMS ont été créés en exploitant les quelques octets libres dans les messages de statut. Le design initial n'est jamais parfait, et lorsque le besoin se fait sentir il y a toujours moyen de trucher le système pour avoir une nouvelle fonctionnalité.

En parlant de SMS, eux non plus n'ont aucune garantie de distribution, et aucun moyen de savoir si le message est bien arrivé, et pourtant on est bien capables d'avoir une conversation avec. Alors oui, du coup elle n'est peut-être considérée comme instantanée, mais ce n'est pas non plus une correspondance "lente" type email classique. Un peu comme le Google Cloud Storage Nearline qui n'a pas un temps de réponse de l'ordre de la centaine de millisecondes, et pas non plus un temps de réponse de l'ordre de l'heure, mais quelque chose de l'ordre de quelques secondes. À mon avis c'est cette utilisation de conversation "tranquille" à laquelle zezinho< fait allusion, et je pense moi aussi qu'il y a quelque chose de faisable dans ce milieu-là avec l'email, et tout ce qu'il manque pour dominer le monde c'est la ui kivabien. YakaFokon !

Bien vu, mais malheureusement tous les logiciels ne tombent pas dans cette catégorie. J'ai la licence NASA en tête, reconnu comme open source par l'OSI mais non-libre par la FSF. Si on part du principe que la NASA ne fermera jamais ses portes, le code restera non-libre-selon-la-FSF pour toujours, à priori.

qui se veut être une bibliothèque mondiale du logiciel libre en archivant, rien de moins, l'ensemble du code libre écrit jusqu'à ce jour.

Non, c'est encore mieux que ça: ils ont décidé d'archiver tout le code librement accessible. Ce qui veut dire aussi tout le code source qui est dans des licences du type "vous avez le droit de lire mais pas de modifier". Et c'est tout aussi important.

Dans une vie sans logiciel, on ne pourrait plus envoyer de SMS, ni prendre un billet de train, payer ses impôts ou même faire démarrer sa voiture

C'est rigolo, parce que du coup même si l'entièreté du code librement accessible est disponible, on ne pourra toujours pas faire ce qu'il liste.

Mieux encore, utilise webtorrent. Ça passe par WebRTC donc c'est aussi de navigateur a navigateur. Et c'est suuuuper simple a utiliser, regarde l'exemple donne sur la doc du packet npm:

Cote envoyeur:

var dragDrop = require('drag-drop')
var WebTorrent = require('webtorrent')

var client = new WebTorrent()

// When user drops files on the browser, create a new torrent and start seeding it! 
dragDrop('body', function (files) {
  client.seed(files, function (torrent) {
    console.log('Client is seeding:', torrent.infoHash)
  })
})

Cote recepteur:

var WebTorrent = require('webtorrent')

var client = new WebTorrent()
var magnetURI = '...'

client.add(magnetURI, function (torrent) {
  // Got torrent metadata! 
  console.log('Client is downloading:', torrent.infoHash)

  torrent.files.forEach(function (file) {
    // Display the file by appending it to the DOM. Supports video, audio, images, and 
    // more. Specify a container element (CSS selector or reference to DOM node). 
    file.appendTo('body')
  })
})

Jette un coup d'oeil sur https://instant.io, ça fait plus ou moins la même chose sauf qu'il faut donner le lien magnet a l'autre personne. Si tu mélanges ça a ton logiciel qui partage automatiquement les ressources pour tous les clients qui ont la même IP publique, tu peux te débrouiller pour envoyer le lien magnet a chacun directement, et roulez jeunesse.

Effectivement, tu ne pourras pas faire de backup incrémental en branchant juste C14, mais si ta solution de backup te permet de sauvegarder l'index des blocs existants en parallele des blocs de données, alors tu peux te débrouiller pour n'envoyer que les blocs de données dans C14. Si ton logiciel est bien fichu, le(s) fichier(s) d'index peut dans le pire des cas être régénéré depuis les blocs de données, au pire tu peux le(s) sauvegarder dans un autre système accessible plus dynamiquement tel que S3.

Ah ! Je savais bien que le monde n'était pas complètement pourri et qu'il y avait une certaine justice. Merci pour la référence.

Faux, Syncthing n'utilise pas le protocole Bittorrent, il utilise son propre protocole (qui reprend des éléments de Bittorrent, certes)

Par contre il y a un point qui est important pour moi: lorsque le fichier est gros, est-ce qu'il faut attendre qu'il ait été complètement traité avant de pouvoir être envoyé ? Ou est-ce qu'il peut être envoyé au fur et a mesure que les blocs sont calculés ?

Tu peux me citer une autorité de certification qui a arrêté de certifier quoi que ce soit après que sa clé a été utilisée de manière frauduleuse, même pas nécessairement par eux ?

Le seul exemple que j'ai en tête c'est que Chrome a arrêté de faire confiance au CNNIC par défaut. C'est pas beaucoup.

Un peu de visionnage: https://www.youtube.com/watch?v=pDmj_xe7EIQ

Je connais l'existence des procédures standardisées de chiffrement. Mais cela implique des modifications sur les logiciels client.

Ben non, justement; bien que nous autres amateurs du libre auront une préférence naturelle pour PGP et dérivés, il y a aussi S/MIME qui est déjà reconnu par la majorité des MUA commerciaux (même l'iPhone le fait!), et qui fournit plus de fonctionnalité que PGP.

A priori:

1. Dans la mesure ou les records nécessaires a SPF, DKIM et DMARC transitent via DNS, il faut aussi s'assurer qu'ils ont voyagé sans encombre, c'est-a-dire les signer de ton cote avec DNSSEC et être sur que le destinataire fait aussi du DNSSEC et les vérifie correctement (c'est-a-dire que si les records sont invalides, l'email doit être considéré comme invalide… ce qu'aucune application ne fait aujourd'hui)

2. Effectivement, un MD5 ou meme un SHAx d'un document ne sert a rien, dans la mesure ou les pièces jointes font partie du body qui est signé par DKIM. Surtout que MD5 peut tranquillement être considéré comme cassé aujourd'hui.

Après, au niveau légal, je ne peux pas me prononcer. Même pour la solution qui me parait la plus adaptée (S/MIME) je ne sais pas quelle est sa valeur légale.

Riot games (les gens qui font LoL) utilisent XMPP pour la messagerie instantanée, les rosters et la présence. Ils ont fait un ensemble de post de blogs intéressants la-dessus:

• Aperçu du protocole
• Un petit talk avec le recapitulatif qui explique comment ils ont fait pour scaler
• Plus de détails sur l'architecture exacte qu'ils utilisent en interne

Je ne me souviens pas avoir vu un compte-rendu aussi détaillé de l'utilisation d'XMPP ailleurs.

Non mais tout le monde ici sait ce qu'est un glider; c'est a l’extérieur que les gens pourraient se demander ce qu'un caractère braille vient faire dans le texte.

Ah oui, tu as raison, je n'avais pas pensé à ça.

Je ne connais pas vraiment les autres solutions donc je ne sais pas si elles pourront t'aider. Pour rester dans ce que je connais et dans les bup et autres restic, une autre solution serait de faire un truc à la rdiff-backup:

• Le serveur de backup garde une zone "staging" avec la hiérarchie à backuper
• Le serveur de prod rsync ses données vers la zone de staging, ne transférant ainsi qu'une partie des données
• Le serveur de backup déduplique via bup, de son côté, une fois que le transfert est fini

Le gros inconvénient c'est que ça demande de la bonne synchronisation pour que les différents processus ne se marchent pas sur les pieds. En plus de ça tu stockeras toutes les données sur la zone de staging en plus du vrai backup dédupliqué. Une solution serait peut-être de faire en sorte que la zone de staging soit en fait un mount FUSE du backup qui pointe vers le dernier backup. Ou, encore plus poussé un server qui fait rsync+ssh+déduplication, qui n'existe pas mais dit comme ça ça a l'air plutôt alléchant.

J'ai pas entièrement compris la question: tu as un serveur distant que tu aimerais backuper sur un autre serveur distant, sans envoyer la totalité des données sur le réseau ?

bup et associés permettent de faire sans en feintant le système: monte le dossier de backup sur la machine à backuper. Seuls les index seront transférés du serveur de stockage vers le serveur à backuper, et dans l'autre sens seuls les blocks complètement nouveaux seront envoyés.

Ou alors j'ai pas tout saisi.

Le mieux reste encore d'aller voire la page DESIGN de bup que j'ai pointée plus haut. Pour faire simple, l’idée est la suivante:

Rolling checksum

Deja tu prends un algorithme qui te permet de calculer des rolling checksum; c'est une checksum qui permet de calculer efficacement une somme de contrôle a partir de n'importe quel offset du fichier. Imagine une fenêtre de calcul qui donne la valeur de l'octet N a l'octet M. Tu veux calculer la somme de l'octet N+1 a l'octet M+1, c'est a dire décaler la fenêtre d'un octet vers la droite. Avec une somme de contrôle "standard", il faudra tout recalculer octet par octet. Avec une rolling checksum pour calculer cette nouvelle valeur tout ce dont tu as besoin c'est:

• la valeur precedente, c'est-a-dire de l'octet N a l'octet M
• l'octet que tu rajoute, a M+1
• l'octet que tu enlèves, a N

En pratique, il y a adler32, créée par Mark Adler (le créateur de rsync, qui a mis au point cette checksum justement pour rsync vu son fonctionnement particulier) et Rabin-Karp, du même nom que l'algorithme de recherche de string dans une string (justement parce que l'algorithme a besoin d'une rolling checksum)

Trouver une limite aux chunks

Une fois que tu as une rolling checksum, tu peux calculer la somme de contrôle "a chaque octet", c'est a dire que tu calcules de 0 a W, de 1 a W+1, etc…

A chaque somme tu appliques une petite heuristique, du style "est-ce que les 13 premiers bits sont a 1". Une telle heuristique a une probabilité de 1 / 2¹³; dit autrement, la réponse devrait être oui si tu calcules cette somme 2¹³ = 8192, c'est-a-dire que après avoir avancé de 8192 octets tu devrais avoir un oui. Comme c'est juste une probabilité, en pratique tu te retrouves avec des valeurs différentes, mais en gros tous les ~8kio tu es capable de définir une limite; a partir de la, un bloc est l'ensemble des octets entre deux limites (qui devrait donc avoir une taille moyenne de 8kio, donc).

La ou il faut bien faire la différence, c'est que la rolling checksum est calcule sur une petite fenêtre, typiquement 128 octets. Si tu as trouve une limite, on dira qu'elle correspond au dernier octet de la fenêtre. Par contre tu peux être certain que la limite précédente est en-dehors de la fenêtre. Voici un schéma fait a l'arrache, dans lequel les octets sont alignes, tu vois la limite precedente, la fenêtre ou la valeur est calculée, et comme la rolling checksum matche la condition, on met une limite a la fin de la fenêtre.

____________________________________________________________________________________________________
              |                                                   [     ]|
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
            limite                                               fenêtre  limite

Et voila, tu peux calculer une somme de contrôle forte (type SHA-1, SHA-256) sur chaque bloc, qui lui donnera une identité, et ne le stocker qu'une seule et unique fois; si le même bloc se retrouve dans un autre fichier ou dans une version ultérieure du même fichier (qui n'est qu'un cas particulier d'un autre fichier, après tout), il existera déjà, pas besoin de le stocker une 2nde fois.

(note: la valeur exacte de la première somme de contrôle ne sert a rien; tout ce qu'on regarde c'est si elle passe le test des x premiers bits)

Pourquoi c'est top

Dit comme ça on ne voit pas vraiment l'avantage par rapport a, par exemple, du chunking statique tous les X octets. La ou ça fait la différence c'est si tu modifies le fichier, par exemple en plein milieu. En refaisant passer la moulinette, bien entendu le début suivra exactement la même procédure, et tu te retrouveras avec les même blocs. Par contre a l'endroit ou il y a eu une modification le contenu a change, donc la rolling checksum va changer, et la limite se retrouvera a un autre endroit. Le truc c'est que après la modification le contenu n'a pas changé, donc la rolling checksum donnera la même valeur qu'avant, et ce jusqu’à la fin du fichier. Du coup tu te retrouves avec les mêmes blocs avant et après la modification, et seule la modification crée de nouveaux blocs, le tout sans même avoir besoin de faire un traitement spécial. La grosse différence par rapport a un diff classique c'est que les deux versions sont totalement indépendantes; tu peux tout a fait supprimer les blocs uniques a une version donnée sans pour autant affecter les autres versions, a la différence des rdiff-backup et autre duplicity, ou tu as une longe chaine de backups "incrémentaux" qui se suivent tous les uns les autres depuis un backup "full". Dans les backups qui utilisent du content-defined chunking, il n'y a plus de "full" et d’"incrémentaux", tous les backups sont considérés comme full et c'est le stockage derrière qui fait de la magie.

Je suis tombé sur le sujet de la déduplication avec bup, que j'aime beaucoup parce que le code est lisible et la démarche est documentée. Je pense qu'il a plus ou moins engendré les autres qui fonctionnent de la même manière (à savoir content-defined chunking), mais je n'en suis pas sûr à 100%:

• ddar, qui n'a pas l'air d'avoir beaucoup bougé mais qui a priori marche. L'auteur a choisi d'utiliser SQLite pour stocker les métadonnées, ce qui peut s'avérer intéressant pour le futur (supprimer des blocs est par exemple
• attic, déja mentionné
• restic, encore une autre implémentation des mêmes idées
• zbackup, qui contient quelques liens vers la fin

Tout ça pour un rendement énergétique (pour l'homme) moindre que si on mangeait directement l'équivalent de la nourriture des bêtes.

Ben non, à la base si on mange de la viande c'est parce que c'est bon, ça n'a rien à voir avec l'apport énergétique. De l'autre côté je suis d'accord avec toi, la consommation que l'on fait par chez nous de viande est source de problèmes environnementaux et même de santé si on en mange trop.

Du coup j'ai d'abord pensé au tofu. […] Soit je suis infoutu de le préparer comme il faut, soit c'est vraiment fade avec une texture bizarroïde.

En même temps c'est du tofu, hein. La réponse 2 est la bonne réponse.

Donc mon FAI le vois aussi.

Pas tout à fait, tout ce que voit ton FAI est que tu utilises Whatsapp, quand et pendant combien de temps. Il manque l'information la plus juteuse, qui est de savoir avec qui tu parles.

Ok, c'était un peu rapide mais je pensais que le contexte était clair: il y a un canal chiffré end-to-end du contenu entre les participants, et un canal chiffré entre chaque participant et Whatsapp. Le contenu est invisible par Whatsapp, mais les métadonnées (qui parle avec qui, quand, combien de temps, …) leurs sont accessibles. Le monde extérieur n'a accès à rien, bien sûr.

Le contenu est chiffré mais les métadonnées sont en clair. Qui parle a qui, combien de temps, etc… Ça peut avoir l'air anodin en termes de monétisation mais avec l’arrivée des bots qui communiquent directement avec le client, ça peut être très intéressant pour Facebook de voir que tu passes ton temps a parler avec le bot de Coca-Cola…

(Grosse spéculation bien sur, je n'ai aucune donnée pour confirmer ça)

Il y a deux choses différentes:

Et il faut de vrai compétence pour ça : avoir un serveur bien sûr, mais au delà de ça, des admin, de la sécurité, des sauvegardes…

C'est pour moi une perte de temps et de moyens de chercher a héberger ses outils sur des serveurs a l'ancienne depuis que le cloud existe. Il faut penser comme une startup: quand t'es a la rache en termes de moyens, il faut concentrer le peu de temps et d'argent que tu as sur la construction de ton produit/projet, pas se perdre en infrastructure.

des personnes qui réfléchissent à l’outil le plus pertinent, démocratique, etc…

Ca c'est la vraie question, parce que l'outil doit servir la fonction. J'ai pas de vraie réponse de cote la, pour moi un *pad ou, mieux, un Google Docs (ou équivalent libre, hein, mais j'en connais pas) bordelique-mais-persistent reste la meilleure solution dans un mouvement comme celui-ci quitte a réorganiser après coup quand les choses sont en place, dans un wiki ou un site ou un blog ou autre.

En fait la vraie question dans mon message est: existe-t-il des logiciel facilement hébergeable dans le Claude sans administration qui passent a l’échelle facilement ? Des trucs qui s'"hébergent" sur un PaaS comme AppEngine plutôt que sur un VPS en gros.