rakoo a écrit 921 commentaires

Super projet dis donc !

Dans les micro-systèmes d'exploitation, un développeur sympathique a imaginé une stack qui s'appelle UXN, c'est une machine virtuelle qui est très facilement implémentable sur de très nombreuses architectures puisqu'il y a un nombre restreint d'opérations. Grâce à l'émulation une application tournera identiquement sur toutes les architectures: il y a par exemple un éditeur de texte (https://100r.co/site/left.html), une application de dessin (https://100r.co/site/noodle.html), et même un OS, potato (https://wiki.xxiivv.com/site/potato.html). Ça pourrait être des cibles intéressantes.

Le principe de fond de donner au logiciel libre a d'autant plus d'impact qu'il est visible. Faire partie de ce collectif informel c'est donner plus de chances aux projets d'être financés et se donner une meilleure image.

Est-ce que les initiatives de fédération de forges, avec tout ce qui se fait sur la fediverse, sera abordé ?

Est-ce que tu pourrais faire les mêmes stats par genre ? Comme tu le dis les vidéos ou les albums de musique devraient avoir moins de fichiers que ça. Peut-être que tu es tombé sur un torrent avec un million de fichiers qui fausse complètement le calcul. De manière générale tu en apprendras certainement plus en regardant la variance en plus de la moyenne, ainsi que les différents percentiles.

La looooongue discussion sur le sujet sur Hacker News(avec intervention du chef de projet!) te donnera probablement plus d'informations; il y a notamment un lien vers un exemple de code généré

Un équivalent est pacserve. J'avais profité de ce cahier des charges minimes pour en faire une version en Go, paclan (non maintenu car non utilisé)

Cependant, ce n'est pas un mélange de html et de javascript à la React

Tu veux certainement dire "à la JSX". React c'est du 100% javascript pur bio, élevé en plein air; JSX est un "sucre syntactique" qui est transformé en javascript avant d'être interprété. D'ailleurs tu peux tout à fait t'en passer, et tu auras un truc qui ressemble à ça:

    render: function () {
        return React.createElement("li", { className: "ListItem" },
            React.createElement("a", { href: "/items/" + this.props.item.id },
                this.props.item.name
            )
        );
    }

Ce qui est tout de même moche, du coup tu as des librairies qui te permettent de faire, par exemple, ça:

    renderTree: function () {
        return ["li", { className: "ListItem" },
            ["a", { href: "/items/" + this.props.item.id },
                this.props.item.name,
            ],
        ];
    }

Ou alors créer une fonction qui alias React.createElement, ou alors passer par une autre bibliothèque javascript… Toute la force de React, justement, c'est de n'être que du javascript.

XMPP fait tout pour ne pas perdre les messages, de base. Soit la connexion de bout en bout est vivante et le message est transmis, soit il y a un problème sur la ligne et les serveurs vont faire ce qu'ils peuvent pour retransmettre le message quand l'autre coté se réveille. Ce que fait la XEP-198, c'est faire en sorte que l'utilisateur ne voit pas d'interruption quand la connexion est coupée temporairement, et que son smartphone ne refasse pas toute la danse nécessaire a chaque reconnexion. En ce qui concerne les messages eux-mêmes, pour s'assurer a 100% qu'ils ne soient pas perdus c'est la XEP-0184 qu'il faut utiliser.

Oui, par "la communauté" et tu peux participer si tu le veux.

C'est un travail crucial qui est fait la, on a tous pris l'habitude de ne pas nécessairement croire Wikipedia sur parole et de jeter un coup d’œil aux sources. Merci !

As-tu déjà jeté un coup d’œil a notmuch ? Ça indexe les emails dans un xapian qui peut être accédée a l’extérieur par tout plein de moyens. Typiquement, il y a une UI pure web que je n'ai jamais utilisee, notmuch-web. Sur le desktop, tu as aussi Astroid, que j'aime bien après un test bref, qui est cité dans le journal.

Une autre possibilité que je vois est de bidouiller le système de stockage d'un serveur IMAP (plutôt qu'un client mail), et d'utiliser un client mail pur IMAP (dans le genre respect des standards, trojita est excellent). Avantage: c'est valable avec a peu près n'importe quel client !

impossible à comprendre à moins d'avoir un doctorat en chimie.

Alors déjà, qu'on se mette bien d'accord: tout est chimique. L'eau est chimique. Le savon est chimique. Toi ce que tu ne comprends pas ce sont les noms scientifiques de composants qui n'ont pas de nom marketing simple, et qui font peur. Moi, étant absolument nul en régimes, ce sont tous les mélanges "vitamine A/B/C/X/λ, magnésium, potassium, fer et assimilés" que je ne comprends pas. Quel aliment contient quoi ? Dans quel sens il faut les mélanger ? C'est aussi de la chimie, mais bizarrement ça ne pose pas autant de problèmes que "ya du chimique dedans".

Un peu moins de chimie dans la vie dans la vie quotidienne, ça ne peut pas faire de mal :-)

En partant du principe que tu voulais dire "Un peu moins de machins que je connais pas dans la vie quotidienne", je m'interroge: est-ce vraiment la meilleure solution ? Est-ce que tu t'interdirais des choses juste parce que tu ne sais pas ce qu'il y a dedans et comment ça marche ? Est-ce que tu t'interdirais les vaccins parce qu'on a entendu parler de traces de machins pas cool dedans, et "on sait jamais" ?

(Et hop)

Le problème c'est pas la distribution des tuiles, qui est déjà bien gérée et n’embête pas trop les serveurs. Le problème c'est la génération de tuiles: c'est un processus qui demande pas mal de ressources, tellement en fait que la plupart sont générées a la demande et mises en cache seulement pour un (relativement) court instant. C'est pour ça qu'OSM demande de pas trop surcharger les serveurs.

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