vlamy a écrit 751 commentaires

« Fait soit même » ça irait ?

Bon, c'est Dredi alors je me permet de répondre à Zenitram :

(même si il "limite" à certains domaine, de manière arbitraire tiens, le contraire du libre qui ne fait pas de décision arbitraire sur tel ou tel domaine), wow quelle liberté

Non, pas de manière arbitraire, il argumente :

Selon moi, les licences non libres qui permettent le partage sont légitimes pour des œuvres artistiques ou de divertissement. Elle le sont également pour des œuvres qui expriment un point de vue (comme cet article lui-même). Ces œuvres ne sont pas dédiés à une utilisation pratique, donc l’argument concernant le contrôle par l’utilisateur ne s’y applique pas. Ainsi, je ne vois pas d’objection à ce qu’elles soient publiées sous licence CC BY-NC-ND, qui ne permet que la redistribution non commerciale de copies identiques à l’original.

Quand bien même le problème posé par les CC BY-NC-SA et BY-NC serait résolu, elles continueront de ne pas être la bonne façon de publier des œuvres pédagogiques censées servir à des tâches pratiques.

Après on a le droit (ou le gauche, là je ne sais plus), d'être en désaccord avec RMS. Mais dire qu'il décide de façon arbitraire ce qui doit être libre ou pas, c'est mal comprendre ce qu'il dit.

Je ne cherche pas à défendre le point de vue de RMS, mais si on critique : critiquons correctement !

Rhooooo ! Le cochon !
-->[]

« Fabrication maison », je le traduirais plutôt par "home made", déclinable en "homemade". C'est une expression assez utilisé par les anglophones il me semble : "home-made cake, home-made cookies, etc". J'ai l'impression que dans "do it yourself" il y a le concept de faire soit même quelque chose qu'on est bêtement habitué à acheter. Pourquoi pas simplement "Fais le toit même !" ?

Oui je sais bien ce que RMS en pense, mais je voulais avoir l'avis des auteurs concernés : qui m'intéresse aussi.

Joli projet, j'adore le concept.
Par contre, une petite remarque :

… et le code (open source)

On parle bien du code du site Web? , c'est qu'en lisant j'ai cru que vos projets (contenus) apportaient aussi du code ouvert (et j'aurais demandé : quel licence?). Mais à priori non, pas de code fourni autre que celui du site (j'ai cru comprendre que c'était pas loin pour le juke box Raspberry-Pi). C'est bien ça?

Au passage, pour le site, n'hésitez pas à dire que la licence est Apache V2 (open source c'est un peu vague).

Et bon, comme je suis pinailleur et que c'est vendredi : pourquoi la clause NC dans la licence des articles?

C'est une vraie question: quel est le rapport entre The Pirate Bay et le libre?

C'est une bonne question, mais le but de la dépêche n'est pas d'y apporter une réponse. Personnellement j'en sais rien !

En regardant la bande annonce, j'ai vu du hack, du nerd et du fun, ça m'a donné envie de voir le film.

C'est petit et non argumenté :)

Java n'est peut être pas le bon langage pour faire un OS (encore que certains pensent que si), mais quand on voit la charge que supportent les serveurs d'applications JEE type JOnAs ou Jboss : il n'y a vraiment pas de quoi se plaindre. Java a deux points forts pour moi : l'interopérabilité et l'outillage. Il est vrai que des (méga) usines à gaz sont développées avec java (Eclipse?), et encore on ne parle pas de prototypes de projets collaboratifs dans lesquels chacun amène sa bibliothèque, voir son service : on mélange tout, on touille et ça marche (lentement, mais ça marche).

Bref, c'est l'architecture du projet qui fait que le logiciel est une usine à gaz, pas le langage. Et :oui on peut faire de l'OSGI embarqué qui pédale !

Je vais chercher si je trouve un compte rendu des travaux auxquels je faisais référence, je me rappelle qu'il y avait un robot qui devait sortir d'un labyrinthe, pleins de générations de robots (calculées sur au moins un an) et des réseaux de neurones.

Mais d'après l'article wikipédia sur les algos génétiques :

Le temps de calcul des algorithmes génétiques croît en n \ln(n), n étant le nombre de variables.

Donc je dirais, tout dépend du nombre de variables. Dans le cas d'un robot, ça doit effectivement être pas cher.
Pour des modèles météo, c'est autre chose :)

notre solution libre (licence GLPL)

LGPL, je pense. Non?

J'ai passé mon master (il y a 5/6 ans) avec un gars qui faisait exactement ça : ça s'appelait algorithmes génétiques.
Il arrêtait pas de monopoliser la grappe de machine. Le nombre d'heures de simulation, pour arriver à un robot qui se cognait dans les murs, faisait peur (je crois me rappeler de plusieurs milliers d'heures).

Ça a peut être évolué depuis, mais j'ai peur que ça soit encore gourmand en ressources de calcul. Et le niveau en mathématiques pour comprendre les équations est sympa aussi (réseaux de neurones, tous ça).
Mais en tous cas, c'est ultra fun !

J'avoue que je ne suis pas très doué pour la lecture des news et autres journaux.
Je préfère lire autre chose.
D'ailleurs côté écriture ce n'est pas trop cela aussi…
( j'fé pas mal de fotes )

Le projet s'est plus au moins endormi

Le projet s'est plus ou moins endormi

Laisse tomber, ton karma a assez souffert pour aujourd'hui.
Il y a des jours ou mieux vaut se taire (oui moi aussi j'ai du mal des fois, mais c'est comme ça ! Et c'est mieux pour la communauté.).

Sinon : enchanté Bleuette ! Tu as l'air toute mignonne.

maintenant si le message de charlie ou garspard se perd tu fait comment ?

L'avantage c'est qu'en recevant le message d'Alice, tu connaîtra l'existence de ces deux messages, donc soit tu les attends (quitte à demander une retransmission) avant d'afficher le message d'Alice, soit tu affiches le fait qu'il manque des messages.

Enfin c'est mieux que de ne pas savoir qu'il manque un ou des messages.

Je suis loin d'avoir fait le tour, mais j'ai regardé telehash : ça à l'air pas mal !
Après as-tu une spec? ou un cahier des charges vite fait? Histoire de savoir sur quoi on part.
Car en fait, on peut mettre du p2p à plusieurs niveaux (stockage partiel ou total, caches, partage de bande passante, …etc) et avec plus ou moins de difficulté et de pertinence.
J'ai pas non plus les idées claires sur ce qui est fait et ce qui reste à faire :)
Mais ça va venir.

Oui, je suis bien d'accord, je pense que ça va venir :)

Ok, donc effectivement le problème réside dans la décentralisation des bases de données.

A ce propos, j'ai une question : pour le moment le projet est de répliquer les bases de données à l'identique, non?

C'est déjà énorme comme projet, mais je n'appelle pas ça décentralisé, plutôt réparti. Effectivement, répliquer une base de données, pour moi ça ne passe pas à l'échelle : en gros avec plus de 1000 bases de données (voir bien avant), on commence à se poser des questions.

Enfin je ne dénigre pas du tout ton projet, je trouve déja énorme que tu ais réussi à faire un prototype qui tourne. C'est juste que pour avoir du vrai décentralisé, il faudrait taper dans une table de hachage distribuée (DHT), en guise de base de données, du style Chord, Pastry ou Kademlia (voir Dynamo pour un exemple d'implémentation, qui est à la base de S3 chez Amazon).
Et là, on perd le relationnel (fini SQL) et on se trouve avec une base de donnée clef/valeur (une table de hachage quoi).
Pour approfondir sur les BDs décentralisées, si ça intéresse quelqu'un, je vous propose de regarder Cassandra (un projet libre Apache). C'est ce qui à l'air de se rapprocher le plus d'une BD distribuée libre et largement utilisée.

Bon, déjà je suis une quiche en C++, mais bon ça c'est pas grave à la rigueur.
Et pour LSD : je suis payé pour développer un concurrent direct, libre et français, de ZeroMQ : Joram (quelqu'un connait?).
Juste pour dire que j'aurai du mal à partir sur LSD, même si la solution est très bien :)
Cela dit, pour moi zeroMQ n'a rien de réellement décentralisé, sans avoir étudié dans les détails non plus.

Je regarderais un peu plus en détail et je te dirai ce que j'en pense, mais quand je vois des trucs comme Kademlia dans Telehash, je commence à penser qu'on se rapproche du vrai décentralisé et non pas de ce que j'appellerai de la redondance (BD répliquée sur tous les nœuds à l'identique, par exemple). Mais c'est ambitieux, c'est sûr !

Je crois que j'ai compris, mais je suis pas sûr.

En fait tu dis que l'historique des messages n'a d'importance qu'entre un message et son prédécesseur (enfin la norloge auquel il répond, s'il y a lieu).
C'est bien ça?

Je travaille sur un projet libre et je voudrais atteindre cet objectif

Si tu acceptes les contributions/remarques/relectures ça m'intéresse. Enfin si jamais je peux t'apporter quelque chose…

, mais j'ai pas fais de thèse :)

C'est tout à ton honneur :) En fait, je dis ça parce que j'ai bouffer 4 ans de théorie, ça fait 2 ans environ que je bosse sur autre chose (rien à voir avec le p2p) et j'aimerais bien essayer de coder un truc concret (et libre) un jour en p2p.

La plus grosse difficulté étant de développer un protocole de synchronisation entre des instances, sachant que certaines instances pourrait ne pas avoir suffisamment d'espace disque pour tout stocker.

Je vois bien le problème, mais il y a peut être moyen de faire quelque chose quand même, avec des caches, de la hiérarchie ou encore des codes de compressions…etc
Bref, autant d'idées théoriques qui peuvent aussi être hors contexte tant qu'on a pas un truc concret devant les yeux.

J'avoue ne pas savoir comment marche friendica et newebe, je veux dire côté serveur.

Je vais faire remonter l'inspection de ces solutions dans ma todolist, mais elle a tendance à croître de façon exponentielle en ce moment :)

Les horloges de Lamport sont bien pour des réplications de serveurs (tu garde un pool de serveurs synchronisés), mais pour un fonctionnement sur un réseau asynchrone avec un nombre variable de nœuds, je ne pense pas que ce soit une bonne idée.

Pour la réplication on utilise généralement une diffusion totalement ordonnée. Selon le protocole (séquenceur fixe, mobile ou à base d'historique) on a, ou pas, des horloges de Lamports.

Il faut aussi prendre en compte l'éventualité d'une attaque du réseau. De ce que je crois savoir les horloges de Lamport supportent très mal les pannes byzantines.
Les seuls protocoles que je connais et qui soient tolérants (partiellement en général) aux fautes byzantines utilisent des concepts "way much complex" que les horloges de Lamports.

Ça m'intéresse. Je n'ai étudié que les grandes lignes des réseaux paire à paire (structuré ou non) avec comme problématique la recherche de ressources/documents. Comment fais-tu pour assurer le séquencement des messages ? À moins de s'amuser à modifier l'historique (te rendre compte que tu as un nouveau message qui est apparu 10min avant le dernier message que tu as délivré), je ne vois pas comment.

Alors en pair-à-pair : je n'ai jamais vu d'études la dessus. Et à priori j'ai bien creusé le problème :) Par contre un truc tout con pour délivrer les messages dans le même ordre (en modifiant l'historique localement si message en retard, ce qui ne devrait pas poser de problème pour les norloges) : tu établis un ordre sur les estampilles horaires et tu résous le conflit, en cas d'égalité, en utilisant l'identifiant de l'émetteur (en général un hash de @IP+port qui est donc unique).

Pourquoi se contenter de décentraliser une tribune et pas un site web complet ? Ainsi il pourrait y avoir des instances de linuxfr un peu partout et lorsqu'un article, journal, commentaire est posté sur l'une d'elle c'est synchronisé avec les autres.

Honnêtement, un projet comme ça , ça me fait fantasmer. J'ai eut fait une thèse dont le sujet se rapproche un peu (P2P et compagnie). S'il y a des gens sérieux pour tester quelque chose, je suis chaud bouillant :)

Suivre des conversations dans un système décentralisé c'est juste des horloges de lamport.

Pardon d'avance, mais pour une fois qu'on tombe dans mon domaine de compétence, je vais pinailler un peu :

Les horloges de Lamport (horloges scalaires) te permettent de re-séquencer (garder la causalité) les messages d' une source. Et encore, si tu fais de la diffusion tu peux avoir besoin d'horloges vectorielles.
Donc en gros, HL Lamport suffisent pour du dialogue à 2 participants. A N participants (N potentiellement grand) et avec des communications asynchrones, le problème se corse : tu dois garder des structures (vecteurs ou matrices) en O(N) et les faire transiter dans chaque message. J'ai étudié des protocoles pair à pair (théoriques) qui sont censés résoudre ce problème à large échelle et il semblerait que la meilleur des solutions, pour passer à l'échelle, est de se baser sur une synchronisation UTC des horloges (avec des erreurs de séquencement potentiellement selon la précision des horloges et de leur synchro). Bref, si vous voulez vraiment gardez des norloges en pair à pair je vous conseille la synchro UTC. Et je peux étayer mes dires avec des publications si besoin est :)

Ta question est tout à fait pertinente.
En fait je ne connais pas trop l'histoire d'Alan Cox et je fonctionne par rapport à ce que je connais et qui est peut être différent.
Je m'explique : d'après ce que je sais (peu de choses), le kernel Linux est une méritocratie (le facteur Linus mis à part) : l'idée étant que tout le monde peut contribuer et que les meilleurs en terme de mérite (notion floue qui mélange talent, investissement en temps passé, expérience, chance? et d'autres paramètres) occupent les postes stratégiques (comme l'a fait Alan Cox). Ensuite, pour avoir une idée, même floue, du niveau d'excellence du code kernel : il n'y a qu'à se dire qu'il sert de modèle à tous (Google, Microsoft, IBM, …etc), c.-à-d. pas des ptits joueurs en termes de système. Mais le meilleur moyen pour s'en convaincre reste de l'étudier et d'essayer de modifier quelque chose, pour se rendre compte.

Tu as oublié :
- viennent mouler sur DLFP