Étant abonné à la liste des développeurs de Mozilla Persona/Identity, j'ai vu qu'ils parlaient de l'évolution de Camlistore, produit que je ne connaissais pas. ( http://camlistore.org/ )
Comme j'ai fait une recherche avec le mot Camlistore sur linuxfr, et que ça ne m'a donné qucun résultat, je me permet d'en toucher quelques mots.
Camlistore est sensé être une sorte de système de stockage hybride et universel :
- Système pub/sub (publication de flux, abonnement à des flux) qui regrouperait les fonctionnalités d'un CMS classique avec flux RSS, d'un flux XMPP, ou Twitter…
- Média d'interaction sociale à la facebook/diaspora/g+ (qu'on appelle "réseau social") le fait de pouvoir partager, commenter, taguer, créer des groupes, apprécier etc. Voire de télécharger toutes les photos de l'anniversaire de l'oncle Fred.
- Système de stockage de contenus classique en arborescence (Posix) et/ou sémantique sans arborescence, au choix, selon les besoins. En fait, camlistore est sensé pouvoir adopter n'importe quel modeling.
Le tout avec plein d'API (ligne de commande, FUSE, interfaces web) à la manière d'un Citadel ou d'un Salut-à-Toi.
À noter toutes les "promesses" de ce MultiDeskOS du cloud, qui en plus d'être opensource et selon toute vraisemblance libre, puisque publié sous licence apache, serait universel, extrêmement protecteur de la vie privée (même utilisé sur une infrastructure cloud propriétaire), langage-agnostique (désolé pour l'anglicisme, c'est pour dire que ça ne dépend pas d'un langage informatique particulier), protecteur des données avec du mirroring, backup, versionning dans tous les sens, avec un super-moteur de recherche qui permet de retrouver en deux clics toutes ses données grâce à son intelligence sémantique, il ferait du pain et des smoothies que ça ne m'étonnerait plus…
Cependant, c'est un projet soutenu à 20% par google. Évidemment ça ne veut rien dire, ce projet peut connaître la même destinée qu'un Google Wave, d'autant que si ça fonctionnait vraiment, ça créerait sûrement une forte concurrence à toutes la galaxie de services de Google…
En attendant, vous pouvez toujours leur envoyer des bitcoins, ils les acceptent.
# et une vidéo de démo, une !
Posté par Anonyme . Évalué à 6. Dernière modification le 02 juillet 2013 à 11:51.
https://developers.google.com/live/shows/806271345
à noter que d'après la liste des contributeurs, Julien Danjou, développeur de l'excellent awesome, travaille également sur ce projet
Concernant le soutien à 20% par google, j'ai compris cela différemment: les responsables du projet travaillent pour google et profitent du fait que leur employeur les encourage à utiliser 20% de leur temps de travail à d'autres projets que ceux de la société. Il ne s'agit donc pas d'un soutien financier direct, ou d'une main mise sur les droits relatifs à ce projet.
[^] # Re: et une vidéo de démo, une !
Posté par deasy . Évalué à 2. Dernière modification le 02 juillet 2013 à 18:22.
Si c'est leur temps de travail c'est donc payé et c'est donc d'une certaine façon un soutien financié. C'est une bonne initiative…qu'on est pas prêt de voir partout.
# 20%
Posté par Gui13 (site web personnel) . Évalué à 9.
Il n'est pas soutenu à 20% par google, c'est un projet 20% de quelques employés Google.
Les contrats de travail de Google laissent 20% de leur temps aux employés pour faire ce qu'ils souhaitent, et ce sans que Google y ait des choses à dire (sauf si c'est manifestement un plagiat).
Donc en gros, ce projet n'a presque rien à voir avec Google :)
[^] # Re: 20%
Posté par Bruce Le Nain (site web personnel) . Évalué à 2. Dernière modification le 02 juillet 2013 à 12:21.
Merci pour la précision (ainsi qu'à Pierre Maziere). C'est clair que j'avais complètement déformé le propos du coup. D'un certain point de vue, c'est rassurant, ce n'est peut-être pas encore un projet qui finira dans le cimetière aux éléWWW la fondation Apache :]
[^] # Re: 20%
Posté par stopspam . Évalué à 2.
Dans 1 mois, il sera devenu un Apache Top-Level Project, comme 99% des projets apache.
A quand le ChuckNorris-Level Project™ ?
[^] # Re: 20%
Posté par mpl . Évalué à 4.
Etant fortement impliqué dans ce projet (et accessoirement pas chez Google), je peux vous confirmer que ce projet n'est pas du tout sous la tutelle de Google. Il se trouve juste que Brad en est le "leader", qu'il bosse dessus pendant ses week-ends, et que comme il est chez Google, tout travail qu'il produit est Copyright Google.
D'où la différence entre le fichier AUTHORS et CONTRIBUTORS, comme pour le projet Golang.
Mathieu
(qui avait un autre compte linuxfr mais qui ne le retrouve plus).
[^] # Re: 20%
Posté par Juke (site web personnel) . Évalué à 2.
Meme ce qu'il produit pendans ses week-ends ?
[^] # Re: 20%
Posté par mpl . Évalué à 4. Dernière modification le 02 juillet 2013 à 17:04.
Oui, c'est ce qu'il m'a dit.
Il s'en fiche puisque le soft est sous licence Apache. c'est même gagnant-gagnant d'une certaine manière; ce qui lui importe c'est que le soft soit libre, et en plus si jamais y'a des soucis de Copyright avec quelqu'un un jour, ce n'est pas lui qui aura à s'embêter avec les procès et les avocats, puisque c'est Google qui devra défendre le projet.
[^] # Re: 20%
Posté par claudex . Évalué à 3.
Vu que c'est une concurrence directe pour son employeur, ça me semble plus ou moins normal.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Petites précisions
Posté par rakoo (site web personnel) . Évalué à 10.
Merci pour le journal. J'avais moi-même jeté un oeil là-dessus il y a peu et j'aimerais apporter de petites précisions sur son fonctionnement interne pour démystifier un peu la chose :
Dans camlistore, tout est blob. Un blob est une suite d'octets. Lorsqu'on la rentre dans camlistore, celui-ci va nous sortir le hash SHA1 du blob et identifier ce blob avec ce hash; ce sera son identité (et elle a le bon goût d'être stable, puisqu'elle dépend uniquement du contenu de la suite d'octets).
Seulement voilà, une suite d'octets c'est bien gentil mais pas très flexible. Par exemple, je sais pas si c'est un fichier texte ou un fichier image… Pour résoudre ça, je vais donc ajouter un autre blob, qui sera une structure spécifiant tous les attributs de ma suite d'octets :
Cette structure est à mettre au format JSON et à stocker dans camlistore, qui va nous ressortir… un hash SHA1. Et oui, cette structure sérialisée est en soi un blob, donc je la stocke en tant que blob dans camlistore ! Et si je veux accéder au contenu, je vais voir dans le champ "objet en question", j'y lis le hash du contenu et je vais lire ce contenu !
Et on peut monter comme ça au dessus, en décrivant un dossier comme un ensemble de fichiers avec quelques attributs, et cet ensemble de fichiers sera décrit comme une liste de fichiers, et chacun de ces fichiers sera décrit comme précédemment…
Maintenant, ça marche bien pour des fichiers immutables, mais comment on fait pour des fichiers que l'on souhaite modifier ? "Simple": on va créer un permanode, un noeud totalement au hasard, qui aura donc un hash SHA1 totalement au hasard, disons "hash-permanode". On va ensuite créer une autre structure JSON avec comme attributs:
et je vais stocker ça dans camlistore qui va là encore me donner un hash, disons "hash-ajout-tag". Ce hash représente ainsi un objet mutable auquel j'ai ajouté un tag et celui-là uniquement. Je peux ensuite apporter une modification, et dire que je veux que cet objet ait comme contenu le fichier précédemment entré dans camlistore. Je vais alors avoir un nouveau hash, disons "hash-ajout-contenu", qui représentera mon fichier avec le tag "demo" et avec un pointeur vers le contenu du fichier. On voit donc qu'on a tout naturellement un système de versionnement qui vient se mettre en place: j'ai 2 versions d'un objet unique qu'on peut appeler "hash-permanode", la première étant "hash-ajout-tag" et la deuxième étant "hash-ajout-contenu" ! Et si je veux accéder à la dernière version de l'objet, je vais directement demander "hash-permanode", qui est en fait une indirection vers l'ensemble des modifications mergées jusqu'à la dernière version !
L'approche tout-hash n'est pas nouvelle, et le système le plus connu qui fait ça est certainement git. git utilise un système beaucoup plus basique, puisque les types d'objets sont fixés (contrairement à camlistore où c'est totalement dynamique), il n'y en a que 4, et chacun est très simple… mais le principe est exactement le même : un fichier est hashé et son contenu brut stocké, la liste des fichiers avec le nom et les droits UNIX et un pointeur vers leur contenu brut est hashé et son contenu stocké, et un commit avec les informations importantes et un pointeur vers la liste des fichiers est hashé et son contenu stocké. Tout pareil.
Maintenant qu'on a posé les bases, on peut s'amuser à faire tout plein de choses :
Camlistore c'est aussi plein de bonnes idées :
[^] # Re: Petites précisions
Posté par mpl . Évalué à 4.
Petite correction sur l'histoire des "modifications mergées jusqu'à la dernière version", juste pour être sûr qu'il n'y ait pas de confusion.
Il n'y a pas de merging/fusion ou quoi que ce soit du genre. Tous les claims (modifications) restent stockés et distincts, et il n'y a pas à proprement parler d'objet qui représente la dernière version.
Simplement, quand on demande à voir l'état d'un permanode, l'indexeur va retourner le dernier claim pertinent en date pour chaque attribut (ou un sous ensemble, selon la requête). De même, lorsqu'on veut annuler une modification, il n'y a pas supression du claim concerné; un nouveau claim invalidant le claim concerné est créé.
[^] # Re: Petites précisions
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
J'ai plein de question !
On peut imaginer que chaque bloc est crypté avec un AES, la clef est dans le fichier chapeau. Il suffit qu'un fichier top, soit crypté avec gpg, pour que "ses amis" puissent lire l'arborescence, non ?
Pourquoi rester avec http ? On peut imaginer utiliser bittorrent pour diffuser les données. On peut même imaginer une sauvegarde par duplication chez les voisins, sécurisé par le cryptage symétrique, cela permet d'évacuer le problème de disponibilité des données si elles sont dupliquées et accessible ailleurs que sur un serveur perso.
On peut même utilisé un cloud sans avoir peur de la NSA (sauf si elle casse de l'AES ayant une clef issue d'un vrai hasard et non un hash de mot de passe trouvé par un humain)
Pourquoi avoir choisi sha1, et pas un truc encore complétement sûr comme sha256 ?
Pour gérer les mises à jour, pourquoi ne peut jouer sur un numero de version basé sur une date, dans le fichier chapeau ?
"La première sécurité est la liberté"
[^] # Re: Petites précisions
Posté par mpl . Évalué à 3.
Parce que http est bien plus souple. parce que tu as besoin de faire des requêtes et toutes sortes de transferts point à point, et de définir une API par dessus. parce que le support http en Go est plus avancé que celui pour bittorrent. probablement aussi parce que Brad est un expert dans ce domaine. Si ma réponse n'est pas satisfaisante, la ML camlistore@googlegroups.com est là pour ça. :-)
Parce que sha1 suffit contre les collisions accidentelles. Ceci dit, ce n'est pas (complètement) codé en dur évidemment, et la possibilité d'utiliser d'autres hashes est bien sûr prévue.
Quelles mises à jour?
[^] # Re: Petites précisions
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Si le but est de faire des échanges de fichiers, le binaire de bitorrent peut être utiliser telquel. Il reste les notifications (le push) a coder. Mais on eut imaginer un message purement textuel que l'on mettre n'importe ou (forum, twitter, tribune,…).
"Quelles mises à jour?"
Celle d'une donnée, un blob.
"La première sécurité est la liberté"
[^] # Re: Petites précisions
Posté par mpl . Évalué à 1.
Les blobs sont immuables.
[^] # Re: Petites précisions
Posté par maboiteaspam . Évalué à 1.
Je suis pas rentré dans tous les détails de la bête, mais il me semble que
1/ c'est fait pour être déployé à la maison, aussi bien qu'au DC
2/ comme il gère nativement les fichiers fragmenté en blocs, je me dit qu'une fois qu'il y à un tracker et/ou un algo de découvrement des pairs proches, alors il n'y à pratiquement plus rien à faire. Et puis si tu shootes un email à ton ami, tu n'as besoin ni de l'un ni de l'autre !
Ici http://camlistore.org/docs/uses
bon je ne plus retrouves le lien d'hier où j'avais lu des exemples de fichiers splittés avec des blobref en pagaille stacker dans un paramètre GET, qui d'ailleurs me faisait me demander si il supportait les short-tags pour les signatures comme GIT sait le faire car à empiler les blobrefs on va atteindre la limite de la taille d'une url, bref une paille quoi : )
[^] # Re: Petites précisions
Posté par Shuba . Évalué à 5.
Merci beaucoup pour toutes ces informations sur le fonctionnement de camlistore, c'est très instructif. J'aurais juste une question: quand tu dis
je me demande comment on fait pour réconcilier deux données qui ont évolué différemùent. Le merge est à faire explicitement, comme avec git?
[^] # Re: Petites précisions
Posté par rakoo (site web personnel) . Évalué à 4.
Je dois t'avouer que je ne suis pas dans les arcanes de camlistore, je fais ici que supposer, considérant la vision des créateurs et le travail existant dans le milieu. Si quelqu'un pouvait corriger, ce serait bien sympathique.
Pour faire simple, camlistore ne fera rien. camlistore n'est qu'un serveur de contenus, avec quelques petits plus par-dessus pour chercher et te montrer rapidement ce qui t'intéresse. Les conflits entre versions de fichiers sont le problème de l'application qui est au-dessus (le fait même que ce soit un conflit est le problème de l'application, pas du serveur de blobs). Fais le parallèle avec le système de fichiers : comment il gère les conflits entre versions ? Il ne les gère pas, c'est à l'application qui utilise les données en tant que version de gérer ça : prendre un bout de ce qu'il y a à droite, un bout de ce qu'il y a à gauche, mélanger le tout, enregistrer dans le système de fichiers, tout ça est le problème de l'application. Le système de fichiers ne fait qu'enregistrer ce qu'on lui dit d'enregistrer, rien d'autre, exactement comme camlistore.
git est différent dans la mesure où c'est un gestionnaire de versions de code source. Il va donc t'avertir qu'il y a un problème dans les versions, parce que c'est son boulot.
Et comme le dit mpl, merge est un mauvais mot. Ce qu'il se passe est qu'il va juste afficher la dernière version de chaque propriété de l'objet. Ça peut tout à fait être faux, mais dans ce cas c'est faux pour l'application seulement et c'est à elle de créer une nouvelle version (plus récente, donc) avec les propriétés qui vont bien. Du point de vue de camlistore, tant que le contenu matche avec le hash (il y a aussi d'autres choses notamment pour l'indexation du contenu, c'est encore un peu flou pour moi), les données sont correctes.
# merci !
Posté par maboiteaspam . Évalué à 2.
La précision était la bienvenue.
Pour ceux qui se posent encore des questions,
http://camlistore.org/docs/uses
http://camlistore.org/docs/overview
+1 pour l'explication du permanode !
[^] # Re: merci !
Posté par Larry Cow . Évalué à 2.
Par contre, c'est du Go. Et il faut une version assez récente du langage (plus que ce que fournissent les distribs, apparemment).
[^] # Re: merci !
Posté par Anonyme . Évalué à 1.
je l'ai compilé sous debian testing sans aucun souci
[^] # Re: merci !
Posté par zebra3 . Évalué à 5.
Le problème, c'est qu'un serveur web qu'on met sur internet sera plutôt sur Stable.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: merci !
Posté par mpl . Évalué à 4.
On refuse de compiler avec toute version en dessous de Go 1.1, certes. C'est une solution de facilité qui nous permet d'enlever certains hacks qui étaient nécessaires pour Go 1.0. Si quelqu'un en a vraiment besoin, ce n'est pas très difficile de remettre ces hacks et de désactiver le check pour Go > 1.1.
Après, toute personne faisant sèrieusement du Go vous encouragera clairement à installer Go 1.1. C'est officiellement la version stable, quoi qu'en disent les paquets des distros.
[^] # Re: merci !
Posté par hercule_savinien . Évalué à 5.
Les distros n'en disent rien du tout.
Si la version X du logiciel machin était la version stable au moment où la distro a été releasé, alors la version X restera la version utilisée sur la distro pendant tout le reste de sa vie. Sauf mise à jour ou backuport de sécurité, ça ne devrait plus bouger.
Il peut y avoir quinze version stable du logiciel sorties entre temps, les distros s'en branlent. T'as qu'à te l'installer en local si tu le souhaite. Ce n'est pas le problème du mainteneur de la distro (que tu n'iras pas ennuyer si tu casse tout de ton côté).
C'est le prix de la stabilité.
Le FN est un parti d'extrême droite
[^] # Re: merci !
Posté par maboiteaspam . Évalué à 5.
bah de toute façon, vu comment il est simplissime de compiler une source go, même en cross plateforme (quoi que j'ai pas encore testé en 1.1), il est hautement préférable, dans ce cas là en effet, de passer outre ta distro.
Go c'est d'la balle ! Allez y mangez en tant que faire ce peut.
# Publicité mensongère
Posté par Perthmâd (site web personnel) . Évalué à 9.
Non mais allô !
Appeler un logiciel Camlistore alors qu'il est écrit en Go, c'est un peu comme si on décidait de lancer un noyau iLinux…
[^] # Re: Publicité mensongère
Posté par mpl . Évalué à 2.
Officiellement, on ne refuse aucune contribution dans d'autres langages (surtout pour les clients). Après, on fait presque tout en Go parce que c'est ce qu'on préfère et que c'est le plus adapté pour ce genre de projet (je ne vais pas me lancer dans un débat sur les langages), et tant qu'on y est on élimine peu à peu toutes les dépendances inutiles (surtout aux niveau des outils tiers et du système de build). Genre scripts perl, shell, makefile…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.