C'est pas du libre, on s'en fout un peu. Peu être pas tellement en fait.
Ah non non non: moins de concurrence, c'est moins d’interopérabilité, c'est la domination d'un (ou de quelques) constructeurs/éditeurs qui font ce qu'ils veulent sans penser aux autres. Si ça continue comme ça, on va arriver a la situation qu'on a dans les OS pour ordinateur de bureau avec Windows ultra-dominateur, Mac OSX qui n'est officiellement disponible que sur très peu de matériels, et les centaines de distribution Linux qui mises ensemble n'ont pas assez de poids pour faire changer les choses (on en est ou du remboursement de l'OS sur un PC neuf ?).
Ouais, donc tu veux pouvoir utiliser le service principal de Google (la recherche) sans qu'il t'aide a aller plus vite (la completion de la recherche).
Je crois que tu n'es pas allé assez loin dans le raisonnement.
Prenons le cas des prisons, tiens. Avant, il y avait des logiciels propriétaires, des "prisons". Je mets prisons entre guillemets parce qu'à l'extérieur, il n'y avait pas grand chose… donc pas vraiment d'autre endroits où aller.
Puis sont arrivés les logiciels libres. Super ! Je peux enfin faire ce que je veux, et je peux même partager avec mes copains ! Là le terme prisons prend tout son sens, puisqu'un logiciel propriétaire fait tout pour empêcher l'interopérabilité et pour que l'utilisateur reste au même endroit.
Avec le temps, de plus en plus de monde a ouvert les yeux/pris la pilule rouge/s'est éveillé, et s'est rendu compte qu'il y avait effectivement quelque chose en dehors des prisons, et y est allé. Aujourd'hui ils commencent doucement à être entendus (ces gens, c'est nous, ceux qui savent que le libre existe) mais restent encore en minorité. C'est dommage, parce que c'est joli ici. Du coup, des gens comme Mozilla se battent pour faire en sorte que le monde de dehors soit sympa pour que les prisonniers puissent venir (c'est quand même assez aride ici: si t'es pas un minimum débrouillard, tu as pas mal de chances de te perdre). Et là, en l’occurrence, le message est simple: "Vous êtes dans la prison A, vous pouvez aller à la prison B en passant par nous si vous voulez. Ah et tant que vous y êtes, pourquoi ne pas rester avec nous dans le monde libre ?". Et pour faciliter les choses, ils font un deal avec la prison B pour attirer les pauvres non-initiés à l'extérieur de leur prison.
Maintenant c'est à nous éclairés de faire en sorte que les profanes restent à l'extérieur de leur prison. Là, on pourrait suivre les traces de Mozilla et faire en sorte qu'au lieu de blablater sur Facebook, les profanes blablatent sur leur compte Jabber, par exemple.
Utilisation de Facebook => plus de monde qui utilise => plus d'argent qui rentre.
Firefox est un excellent logiciel libre, Thunderbird est également un très bon MUA, ils essaient d'améliorer les choses pour l'identification en ligne, ils bougent sacrément côté mobile, et le tout reste libre (et gratuit). Les logiciels de qualité, malheureusement, ça ne se développe pas qu'avec de la bonne volonté.
Et surtout, surtout:
Tu peux désactiver la fonctionnalité
Tu peux la modifier
Tu peux en créer une autre à partir de l'API qui est ouverte pour aller faire l'équivalent sur ton autre réseau social favori
C'est très gentil de proposer une version alternative, mais c'est dommage de s'arrêter à un format de distribution pourri. Voici le magnet correspondant.
Plus exactement, ça devait être en octobre 2010, nous sommes en aout 2013. En même temps quand on prend le pouvoir par la force et qu'on exile les opposants politiques, on n'a pas envie d'organiser des élections dans les règles de l'art.
Après, ça me semble très dur d'arriver à trouver un système pour stocker mes index dans un ou quelques fichiers
Vu la taille de tes fichiers (qqes centaines d'octets), je pense que tu pourrais remplacer le système de fichiers par une base de données clé-valeur plus simpliste. D'expérience, leveldb est parfaitement taillé pour le job, extrêmement rapide et offre même une compression (snappy) à partir d'une certaine taille. J'imagine qu'il doit y avoir tout ce qu'il faut en python pour en profiter.
Ça ne répond pas à la problématique de base: comment tu fais quand tu n'es pas dans un environnement connu ? Tu te débrouilles pour installer un binaire-compatible-encfs en plus de télécharger le fichier de mots de passe ?
Je ne dénigre pas ta solution hein, je fais juste remarquer qu'elle ne marche que tant que tu es dans un environnement que tu maitrises totalement.
Puisque tu as l'air de bien connaitre ces deux-la, est-ce que tu saurais me dire quelle est la différence par rapport a Kademlia ? Je parle surtout en termes de performances dans le monde réel, comme c'est l'algorithme derrière le DHT de Bittorrent, je me disais que ça doit être la plus large installation d'un DHT (en tout cas grand public) et j'aurais aime savoir quelles sont les conséquences derrière.
En tout cas merci pour le cours, je vais voir un peu plus en détail a quoi ça ressemble.
Je suis moi aussi triste de voir que Zeroconf n'a pas créé l'essor massif de la communication en réseau interne, malgré ce qu'en dit Lennart … Peut-être encore une fois à cause de Microsoft, qui pousse sa solution à lui ?
Je ne parlerai pas du choix de SPIP que je ne connais pas, mais j'aimerais savoir: est-ce que les instances peuvent communiquer entre elles ? Si je suis inscrit sur seenthis.net, est-ce que je pourrais publier sur mon nœud installé sur mon serveur ? Ou est-ce que, comme je le crains, les instances sont indépendantes et il faut s'inscrire sur chacune d'entre elles ou espérer qu'un géant bienveillant fera tourner un nœud central ?
Si tu veux écouter de la musique en mobilité, il va falloir choisir entre tout emporter avec toi et tout streamer depuis chez toi, mais quoi qu'il arrive une compression avec perte aura de l’intérêt. Ces formats ne sont pas encore morts, loin de la !
J'ai l'impression, d’après les quelques explications techniques du machin, que le seul compte google nécessaire est celui du développeur pour son application. L'application envoie les messages via GCM au serveur du développeur, qui fait toute la logique de redistribution.
En gros, chaque appareil est un device différent pour un seul et unique compte XMPP, celui du développeur. GCM n'est la qu'en tant que transport, pas plus.
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 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 :
type: c'est un fichier
objet en question: le hash du contenu pur
taille: 1234 kO
utilisateur UNIX: rakoo
groupe UNIX: users
et d'autres paramètres selon l'envie
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:
type: modification
lié au permanode: hash du permanode
modification: ajout du tag "demo"
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 :
toutes les données sont auto-vérifiées, puisque leur identifiant est leur hash SHA1.
on l'a vu, par construction l'historique complet depuis la création du fichier est là. En fait, ça crée un autre problème : comment vider les anciennes versions pour faire de la place.
la synchronisation est "triviale" : il "suffit" d'envoyer les hash qui ne sont pas présent de l'autre côté.
le partage avec un autre utilisateur est trivial : il suffit d'envoyer le hash de la donnée, l'autre peut prendre la donnée d'où elle veut (avec le bonus qu'elle est auto-vérifiée): mon serveur de stockage, son serveur de stockage, un serveur de stockage tiers qui fournirait ce service, peu importe…
Camlistore c'est aussi plein de bonnes idées :
C'est du HTTP+JSON. On n'est certes que lundi, mais le HTTP et le JSON sont compréhensibles par à peu près tous les langages existants.
La gestion des données du point de vue utilisateur se fait via un moteur de recherche (venant de gens de Google, rien d'étonnant là-dedans): celui-ci va indexer par exemple tous les objets JSOn qui ont un attribut "tag", et qui ont "fichier" comme "type", pour que l'utilisateur puisse chercher ses fichiers avec un certain tag. On retrouve là l'un des concepts de CouchDB, à savoir que tout est JSON et que les données se trouvent à posteriori via des requêtes bien placées, mais en étant un peu plus générique.
Certains blobs peuvent être gros, et ça peut être sous-efficace de tout stocker d'un coup. Du coup ils ont implémenté le protocole de split de bup. Pour résumer, le principe est d'avoir une somme de contrôle spéciale dans laquelle on met tous les octets un par un et on regarde le résultat après chaque octet. Dès que le résultat a une forme spéciale (aujourd'hui, lorsque les 13 derniers bits sont à 1), on dit qu'on a atteint un octet frontière, et on casse le fichier entre l'octet frontière précédent et celui-ci. On a comme ça un découpage du fichier en blocs de taille variable qu'on va stocker dans camlistore en lieu et place du fichier complet, en général assez faible (quelques centaines de kO tout au plus), mais au moins si le fichier change peu, il n'y a pas besoin de stocker tout le nouveau fichier, juste les nouveaux blocs. On en avait déja parlé ici.
Il y a une gestion des droits pour le partage avec d'autres utilisateurs, et d'identités. Plutôt que de réinventer la roue, les auteurs ont décidé d'utiliser PGP.
Un seul et unique binaire pour le serveur. Yapasplusimple.
Ouais, 'fin c'est Paris quand même hein. Allez en province, il parait qu'il y a plein de choses intéressantes !
La remarque de rewind< n'est pas que dans le sens "Pourquoi faire dans le faste" mais bien "Pourquoi forcement Paris centre". C'est une question intéressante, parce que ça serait bien d’arrêter de tout mettre a Paris même. Pourquoi toujours tout concentrer ?
La carte n'est pas entièrement chargée en mémoire, ça serait bien stupide. Ça pose d'ailleurs quelques problèmes, parce que pour que certains événements arrivent, il faut qu'elle soit chargée… mais dans certains mods, il existe des solutions pour ca.
Je ne comprends pas bien pourquoi les plateformes de streaming/téléchargement en ligne internationales limitent leur contenu en fonction de l'origine géographique
Business as usual: tant qu'il y aura des gens pour acheter de la rareté artificielle, il y aura des gens pour vendre de la rareté artificielle.
Là où un studio de production fait fort, et où il se détache par rapport aux autres industries, c'est que personne n'a le droit le concurrencer sur ses propres produits (et on sait tous quelle est leur puissance pour faire respecter cette loi). Il n'y a même pas de concurrence possible. Tout ce qu'on peut faire pour les faire bouger, c'est de proposer du contenu alternatif. Mais bon là on commence à considérer les œuvres d'art comme des yaourts achetés au kilo, j'aime pas.
Ce qu'il faudrait, c'est un free de la production artistique, qui redéfinit la distribution d’œuvres nouvelles.
# Non, on ne s'en fout pas
Posté par rakoo (site web personnel) . En réponse au journal L'avenir de la telephonie mobile ?. Évalué à 7.
Ah non non non: moins de concurrence, c'est moins d’interopérabilité, c'est la domination d'un (ou de quelques) constructeurs/éditeurs qui font ce qu'ils veulent sans penser aux autres. Si ça continue comme ça, on va arriver a la situation qu'on a dans les OS pour ordinateur de bureau avec Windows ultra-dominateur, Mac OSX qui n'est officiellement disponible que sur très peu de matériels, et les centaines de distribution Linux qui mises ensemble n'ont pas assez de poids pour faire changer les choses (on en est ou du remboursement de l'OS sur un PC neuf ?).
Franchement, c'est pas intéressant.
[^] # Re: Déception
Posté par rakoo (site web personnel) . En réponse à la dépêche 23 de Firefox. Évalué à 1.
Ah, oui, c'est vrai tiens. Merci pour le texte !
[^] # Re: Déception
Posté par rakoo (site web personnel) . En réponse à la dépêche 23 de Firefox. Évalué à 3.
Ouais, donc tu veux pouvoir utiliser le service principal de Google (la recherche) sans qu'il t'aide a aller plus vite (la completion de la recherche).
T'as pas l'impression d'en demander beaucoup ?
[^] # Re: Déception
Posté par rakoo (site web personnel) . En réponse à la dépêche 23 de Firefox. Évalué à 10.
Je crois que tu n'es pas allé assez loin dans le raisonnement.
Prenons le cas des prisons, tiens. Avant, il y avait des logiciels propriétaires, des "prisons". Je mets prisons entre guillemets parce qu'à l'extérieur, il n'y avait pas grand chose… donc pas vraiment d'autre endroits où aller.
Puis sont arrivés les logiciels libres. Super ! Je peux enfin faire ce que je veux, et je peux même partager avec mes copains ! Là le terme prisons prend tout son sens, puisqu'un logiciel propriétaire fait tout pour empêcher l'interopérabilité et pour que l'utilisateur reste au même endroit.
Avec le temps, de plus en plus de monde a ouvert les yeux/pris la pilule rouge/s'est éveillé, et s'est rendu compte qu'il y avait effectivement quelque chose en dehors des prisons, et y est allé. Aujourd'hui ils commencent doucement à être entendus (ces gens, c'est nous, ceux qui savent que le libre existe) mais restent encore en minorité. C'est dommage, parce que c'est joli ici. Du coup, des gens comme Mozilla se battent pour faire en sorte que le monde de dehors soit sympa pour que les prisonniers puissent venir (c'est quand même assez aride ici: si t'es pas un minimum débrouillard, tu as pas mal de chances de te perdre). Et là, en l’occurrence, le message est simple: "Vous êtes dans la prison A, vous pouvez aller à la prison B en passant par nous si vous voulez. Ah et tant que vous y êtes, pourquoi ne pas rester avec nous dans le monde libre ?". Et pour faciliter les choses, ils font un deal avec la prison B pour attirer les pauvres non-initiés à l'extérieur de leur prison.
Maintenant c'est à nous éclairés de faire en sorte que les profanes restent à l'extérieur de leur prison. Là, on pourrait suivre les traces de Mozilla et faire en sorte qu'au lieu de blablater sur Facebook, les profanes blablatent sur leur compte Jabber, par exemple.
[^] # Re: Déception
Posté par rakoo (site web personnel) . En réponse à la dépêche 23 de Firefox. Évalué à 10.
Utilisation de Facebook => plus de monde qui utilise => plus d'argent qui rentre.
Firefox est un excellent logiciel libre, Thunderbird est également un très bon MUA, ils essaient d'améliorer les choses pour l'identification en ligne, ils bougent sacrément côté mobile, et le tout reste libre (et gratuit). Les logiciels de qualité, malheureusement, ça ne se développe pas qu'avec de la bonne volonté.
Et surtout, surtout:
Bref, tu restes libre.
[^] # Re: video avec le son corrigé
Posté par rakoo (site web personnel) . En réponse à la dépêche Vie Privée en 2013 : Pourquoi. Quand. Comment. - une conférence de Werner Koch traduite en français. Évalué à -1.
C'est très gentil de proposer une version alternative, mais c'est dommage de s'arrêter à un format de distribution pourri. Voici le magnet correspondant.
[^] # Re: Mystere
Posté par rakoo (site web personnel) . En réponse au journal [HS] Madagascar en 2013. Évalué à 6.
Plus exactement, ça devait être en octobre 2010, nous sommes en aout 2013. En même temps quand on prend le pouvoir par la force et qu'on exile les opposants politiques, on n'a pas envie d'organiser des élections dans les règles de l'art.
[^] # Re: Indexation
Posté par rakoo (site web personnel) . En réponse au journal Mon projet : Feedspot. Évalué à 4.
Vu la taille de tes fichiers (qqes centaines d'octets), je pense que tu pourrais remplacer le système de fichiers par une base de données clé-valeur plus simpliste. D'expérience, leveldb est parfaitement taillé pour le job, extrêmement rapide et offre même une compression (snappy) à partir d'une certaine taille. J'imagine qu'il doit y avoir tout ce qu'il faut en python pour en profiter.
[^] # Re: encfs
Posté par rakoo (site web personnel) . En réponse au journal Mot de passe etc. Évalué à 2.
Ça ne répond pas à la problématique de base: comment tu fais quand tu n'es pas dans un environnement connu ? Tu te débrouilles pour installer un binaire-compatible-encfs en plus de télécharger le fichier de mots de passe ?
Je ne dénigre pas ta solution hein, je fais juste remarquer qu'elle ne marche que tant que tu es dans un environnement que tu maitrises totalement.
[^] # Re: Parlons projet alors !
Posté par rakoo (site web personnel) . En réponse au journal Présentation d'idée : PGPID. Évalué à 2.
Puisque tu as l'air de bien connaitre ces deux-la, est-ce que tu saurais me dire quelle est la différence par rapport a Kademlia ? Je parle surtout en termes de performances dans le monde réel, comme c'est l'algorithme derrière le DHT de Bittorrent, je me disais que ça doit être la plus large installation d'un DHT (en tout cas grand public) et j'aurais aime savoir quelles sont les conséquences derrière.
En tout cas merci pour le cours, je vais voir un peu plus en détail a quoi ça ressemble.
# Je comprends pas
Posté par rakoo (site web personnel) . En réponse au journal tric trac linkeo-isé. Évalué à 2.
MyWittyGames édite des jeux de société, pas des jeux vidéo; quel est le rapport avec Tric Trac ?
[^] # Re: L'install
Posté par rakoo (site web personnel) . En réponse à la dépêche CozyCloud, la mise en nuage personnelle et modulaire. Évalué à 2.
Tu as lu la depeche ?
[^] # Re: Fermé
Posté par rakoo (site web personnel) . En réponse à la dépêche Le code source de Seenthis est disponible. Évalué à 2.
Ratée ? Seenthis est utilisé, je crois que c'est le plus important. Pour réussir, il faut avoir le même nombre d'utilisateurs ?
# idées
Posté par rakoo (site web personnel) . En réponse au journal Réseau domestique : Interactions entre différents PC et téléphones. Évalué à 3.
Je suis moi aussi triste de voir que Zeroconf n'a pas créé l'essor massif de la communication en réseau interne, malgré ce qu'en dit Lennart … Peut-être encore une fois à cause de Microsoft, qui pousse sa solution à lui ?
[^] # Re: Oui
Posté par rakoo (site web personnel) . En réponse au journal Fonctionnalités du bureau Linux en 2013. Évalué à 2.
libnotify.
Coté serveur, j'utilise dunst qui remplit le rôle à la perfection.
# Fermé
Posté par rakoo (site web personnel) . En réponse à la dépêche Le code source de Seenthis est disponible. Évalué à 6.
Je ne parlerai pas du choix de SPIP que je ne connais pas, mais j'aimerais savoir: est-ce que les instances peuvent communiquer entre elles ? Si je suis inscrit sur seenthis.net, est-ce que je pourrais publier sur mon nœud installé sur mon serveur ? Ou est-ce que, comme je le crains, les instances sont indépendantes et il faut s'inscrire sur chacune d'entre elles ou espérer qu'un géant bienveillant fera tourner un nœud central ?
[^] # Re: Pour le succès
Posté par rakoo (site web personnel) . En réponse à la dépêche Daala, le codec vidéo du futur, par Xiph. Évalué à 2.
Si tu veux écouter de la musique en mobilité, il va falloir choisir entre tout emporter avec toi et tout streamer depuis chez toi, mais quoi qu'il arrive une compression avec perte aura de l’intérêt. Ces formats ne sont pas encore morts, loin de la !
[^] # Re: Questions…
Posté par rakoo (site web personnel) . En réponse à la dépêche CyanogenMod 10.1, basé sur Jelly Bean 4.2. Évalué à 1.
J'ai l'impression, d’après les quelques explications techniques du machin, que le seul compte google nécessaire est celui du développeur pour son application. L'application envoie les messages via GCM au serveur du développeur, qui fait toute la logique de redistribution.
En gros, chaque appareil est un device différent pour un seul et unique compte XMPP, celui du développeur. GCM n'est la qu'en tant que transport, pas plus.
[^] # Re: Petites précisions
Posté par rakoo (site web personnel) . En réponse au journal Camlistore, système de stockage universel, opensource et protégeant de la vie privée?. É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.
# Petites précisions
Posté par rakoo (site web personnel) . En réponse au journal Camlistore, système de stockage universel, opensource et protégeant de la vie privée?. É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: Hein?
Posté par rakoo (site web personnel) . En réponse à la dépêche Discours de Fleur Pellerin sur le libre chez Mozilla à Paris. Évalué à 8.
Ouais, 'fin c'est Paris quand même hein. Allez en province, il parait qu'il y a plein de choses intéressantes !
La remarque de rewind< n'est pas que dans le sens "Pourquoi faire dans le faste" mais bien "Pourquoi forcement Paris centre". C'est une question intéressante, parce que ça serait bien d’arrêter de tout mettre a Paris même. Pourquoi toujours tout concentrer ?
[^] # Re: Java ?
Posté par rakoo (site web personnel) . En réponse à la dépêche Sous le capot de la beta LibreOffice 4.1. Évalué à 2.
La carte n'est pas entièrement chargée en mémoire, ça serait bien stupide. Ça pose d'ailleurs quelques problèmes, parce que pour que certains événements arrivent, il faut qu'elle soit chargée… mais dans certains mods, il existe des solutions pour ca.
[^] # Re: install sur /dev/sda
Posté par rakoo (site web personnel) . En réponse au journal Ma vie et debian.... Évalué à 3.
Oh que si :)
[^] # Re: Correction
Posté par rakoo (site web personnel) . En réponse au journal Shaarli désormais disponible dans les dépôts de Debian. Évalué à 3.
Le bon lien
[^] # Re: Limitation géographique
Posté par rakoo (site web personnel) . En réponse au journal J'ai^W Klaire a testé pour vous, le téléchargement légal. Évalué à 2.
Business as usual: tant qu'il y aura des gens pour acheter de la rareté artificielle, il y aura des gens pour vendre de la rareté artificielle.
Là où un studio de production fait fort, et où il se détache par rapport aux autres industries, c'est que personne n'a le droit le concurrencer sur ses propres produits (et on sait tous quelle est leur puissance pour faire respecter cette loi). Il n'y a même pas de concurrence possible. Tout ce qu'on peut faire pour les faire bouger, c'est de proposer du contenu alternatif. Mais bon là on commence à considérer les œuvres d'art comme des yaourts achetés au kilo, j'aime pas.
Ce qu'il faudrait, c'est un free de la production artistique, qui redéfinit la distribution d’œuvres nouvelles.