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.
bandcamp est vraiment génial. Ce que je trouve encore plus fort, c'est qu'on peut acheter sans avoir besoin de s'inscrire a quoi que ce soit. C'est tellement rare que j'en frissonne des que j’achète quelque chose dessus.
Normalement, une démocratie pratique la séparation des pouvoirs: ce n'est pas le gouvernement qui décide des lois, c'est le pouvoir législatif. Ta remarque ne tient pas.
S'ils sont pollués avec des trucs sans importance, je les retrouve moins facilement
Mon exemple était peut-être un peu extrême, mais l'idée est tout simplement de ne pas avoir à se poser de question:
si tu es totalement sûr que tu ne vas pas avoir besoin de cet email, tu peux le supprimer
si tu te poses la question ne serait-ce qu'une seconde, garde-le, on sait jamais.
Maintenant, tu sembles croire que garder ces potentiels spams pourraient te gêner d'une quelconque manière, et à l'usage il s'avère que non. Tout simplement parce que tu auras taggé ces indésirables comme "spam", et que quand tu veux chercher quelque chose dont tu te souviens vaguement, tu peux afficher tous les emails moins les spams. En pratique, tu peux vivre ta vie en ne les voyant jamais, juste en incluant un filtre qui va les cacher.
en réalité ce que vous suggérez ce n'est pas « utilisez des tags », c'est « utilisez gmail »
C'est bien le problème. On pense que gmail est LE MUA qui change par rapport aux alternatives, et que sa gestion des emails va au-delà de la simple consultation: elle permet de réellement travailler avec ses emails. C'est pour ça que William Morgan a créé sup, et que d'autres alternatives similaires existent : notmuch, mu, manitou-mail, et plein d'autres. Le problème n'est clairement pas nouveau, mais aucune solution libre n'a jamais percé, peut-être parce que l'utilisation sans tag est trop ancrée dans les mœurs, utilisation confortée par tous les clients existants aujourd'hui (dont le plus connu, mutt). J'espère que ces quelques exemples vont changer les choses, ou tout du moins, faire comprendre qu'il existe d'autre manières d'utiliser sa boite mail que la hiérarchie classique.
d'entrée de jeu il [sup] a deux défauts pour moi :
les conversations. Je préfère l'affichage chronologique simple.
comme gmail, il semble qu'il affiche des noms réduits dès qu'il y a au moins deux correspondants.
Tu devrais essayer manitou-mail, il devrait plus répondre à tes attentes que les autres.
Non, on ne saura pas quel est le contenu exact que tu lis. Par contre, il y a quand même l'information que tu te connectes a linuxfr.org sur une socket TCP sur le port 443. C'est quand même beaucoup, suffisamment pour savoir ce que tu fais, et j'aurais presque tendance a dire que la page que tu consultes après n'a pas d'importance en comparaison.
Si on regarde bien, mumble fait de la voix là où les salons de discussions XMPP font du texte: une multitude de clients se connecte à un seul et unique serveur. Pas de fédération des salons de discussions (i.e un salon de discussion est accessible sur plusieurs serveurs), comme on peut le voir sur IRC. De ce point de vue on pourrait imaginer encapsuler le protocole mumble dans des messages xmpp, avec un bot du côté du host qui est en fait un serveur mumble, et ainsi utiliser mumble dans xmpp. On aurait une grosse perte en débit pur à cause de la transformation en Base64, mais ce serait techniquement possible.
Allez, encore un n-ième projet sur ma liste d'idées folles mais intéressantes à programmer.
À priori, je suis d'accord avec toi: je préfère le hasard sur le chemin de mes données fourni par un million de noeuds, fussent-ils tous lents, à quelques noeuds qui sont trop facilement trouvable, écoutables, éteignables. Manque de pot, Tor ne choisit pas ses noeuds de sortie totalement au hasard, mais les choisit en fonction de leur bande passante, ce qui fait que tu vas souvent tomber sur les même noeuds en pratique.
Du coup, on tourne sur les 50 mêmes noeuds de sortie en permanence, qu'il y ait 1 ou 1000 ou 1 million de noeuds de sortie sur une ligne ADSL.
Sans aller jusque là, peut-être que les SSLL proposaient plutôt de passer le logiciel sous une double licence classique, type libre pour tout le monde et non-libre pour le support, à la Qt ?
Tu peux lire la présentation, mais la réponse est simple: il ne sert à rien dans le modèle de Tor d'avoir une quantité énorme de noeuds si 95% sont sur une ligne ADSL en carton. Ce qu'il faut, c'est qu'il y ait une plus grande proportion que 5% de gros noeuds équivalents. L'association se propose de monter un autre gros noeud pour justement augmenter cette proportion.
Disons qu'à force de tapoter sur mon clavier, je suis devenu de moins en moins bon dans la communication par voie orale. Je préfère lui laisser ces tâches là.
Ils ne permettent pas l'affichage hiérarchisé classique.
Tu peux créer un tag "niveau1/niveau2/niveau3". La séparation logique entre trois niveaux hiérarchiques est une fonction que te donne le logiciel qui traite les mails par-dessus. GMail le fait bien, et, malheureusement, je crois que c'est le seul.
Tant qu'il n'y a pas une méthode standard pour pérenniser les tags, les échanger entre mailers
Et oui, tout le problème est là. Les emails ont été conçus avec une structure hiérarchique forte, et ça se sent dans le design de maildir et dans le design d'IMAP, qui peut tout à fait être assimilé à maildir sur le réseau. Maildir en soi ne supporte pas les tags, mais il existe tout de même une solution couramment utilisée qui est de stocker les tags dans les headers du message, avec un header "X-Keywords" ou "X-Label". Du coup tu pourrais continuer d'utiliser maildir, déplacer/archiver/importer tes emails dans tous les sens, les labels resteront là. C'est une manière assez simple de faire, et je sais que mu au moins fait ça.
Après, ça c'est uniquement pour accéder à maildir; on pourrait aussi penser accéder à un serveur IMAP local qui jouerait le rôle de simple forwarder un peu comme msmtp ou dnsmasq, et par lequel tous les MUA/MTA/MDA passeraient plutôt que maildir. Je pense à cette solution parce que IMAP est standard, extensible, et que justement les extensions IMAP de Gmail offrent des fonctionnalités vraiment intéressantes pour qui veut bosser avec des tags.
Pour faire court: aujourd'hui, il n'y a aucun standard fort pour bosser avec les tags. Quelques logiciels supportent les tags dans les headers d'un message (solution la plus pérenne/inter-opérable), mais ils sont peu nombreux. De l'autre côté GMail a quelques extensions pratiques, mais qu'il est seul à implémenter.
qui se veut plutôt être Là où tu as des répertoires, remplace-les par des tags. Les tags permettent de faire tout ce que les dossiers proposent, et offrent encore plus. Qui peut le plus peut le moins. Tu peux donc réutiliser ta logique dans un premier temps, quitte à utiliser la puissance des tags plus tard quand tu te rends compte petit à petit de leur puissance (combinée à la puissance d'une bonne recherche).
Pour ton exemple, tu peux avoir un tag Paris2008 qui contiendra tous les mails en question. Tu pourrais aussi tagger les mails correspondants avec Paris, et spécifier en 2008 dans ta recherche, pour retrouver les mails correspondants.
Le cas d'utilisation classique est celui-ci : deux catégories "Travail" et "Maison", et deux périodes : "en 2008" et "en 2010". La manière classique et naïve de faire avec des dossiers est de créer 4 dossiers : "Travail2008", "Travail2010", "Maison2008" et "Maison2010". On voit tout de suite où ça nous mène. Tant qu'on n'a pas trop de catégories, ça passe, mais c'est pas forcément le cas. Avec des tags, tu peux faire une recherche sur "Travail et 2008" pour retrouver tous les emails correspondants; ça passe mieux à l'échelle comme on dit.
Règle 4, ne rien effacer.
Parce que tu ne sais pas aujourd'hui ce que tu risques de faire de tes mails demain. Peut-être qu'une compagnie te spamme un peu trop aujourd'hui, et qu'elle fait partie des gros partenaires de l'opération commerciale de ta boîte demain, et que tu veux souhaite signaler (avec preuves) le côté spammeur de ce nouveau partenaire? Peut-être auras-tu envie de t'auto-héberger, et que disposer d'une bonne base de spams pour entraîner ton anti-spam est intéressant ?
# 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.
[^] # Re: HADOPI
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é à 10.
Raconte, raconte, on veut des potins !
[^] # Re: Non !
Posté par rakoo (site web personnel) . En réponse au journal Qui a vraiment besoin d'héberger soi-même ses données ?. Évalué à 3.
Non testé, semble faire tout ça
[^] # Re: C'est rudement bien écrit
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é à 4.
bandcamp est vraiment génial. Ce que je trouve encore plus fort, c'est qu'on peut acheter sans avoir besoin de s'inscrire a quoi que ce soit. C'est tellement rare que j'en frissonne des que j’achète quelque chose dessus.
[^] # Re: Pas de soucis à se faire ...
Posté par rakoo (site web personnel) . En réponse au journal "Glenn Greenwald, le blogueur qui défie Big Brother". Évalué à 4.
Normalement, une démocratie pratique la séparation des pouvoirs: ce n'est pas le gouvernement qui décide des lois, c'est le pouvoir législatif. Ta remarque ne tient pas.
[^] # Re: 0 folder = inbox 0
Posté par rakoo (site web personnel) . En réponse au journal La gestion de courriels est-elle adulte ou encore au stade de l'enfance ?. Évalué à 2.
Mon exemple était peut-être un peu extrême, mais l'idée est tout simplement de ne pas avoir à se poser de question:
Maintenant, tu sembles croire que garder ces potentiels spams pourraient te gêner d'une quelconque manière, et à l'usage il s'avère que non. Tout simplement parce que tu auras taggé ces indésirables comme "spam", et que quand tu veux chercher quelque chose dont tu te souviens vaguement, tu peux afficher tous les emails moins les spams. En pratique, tu peux vivre ta vie en ne les voyant jamais, juste en incluant un filtre qui va les cacher.
C'est bien le problème. On pense que gmail est LE MUA qui change par rapport aux alternatives, et que sa gestion des emails va au-delà de la simple consultation: elle permet de réellement travailler avec ses emails. C'est pour ça que William Morgan a créé sup, et que d'autres alternatives similaires existent : notmuch, mu, manitou-mail, et plein d'autres. Le problème n'est clairement pas nouveau, mais aucune solution libre n'a jamais percé, peut-être parce que l'utilisation sans tag est trop ancrée dans les mœurs, utilisation confortée par tous les clients existants aujourd'hui (dont le plus connu, mutt). J'espère que ces quelques exemples vont changer les choses, ou tout du moins, faire comprendre qu'il existe d'autre manières d'utiliser sa boite mail que la hiérarchie classique.
Tu devrais essayer manitou-mail, il devrait plus répondre à tes attentes que les autres.
[^] # Re: Flux atom et https
Posté par rakoo (site web personnel) . En réponse à la dépêche Certificat SSL/TLS pour serveur web, HTTPS et problèmes associés. Évalué à 6.
Non, on ne saura pas quel est le contenu exact que tu lis. Par contre, il y a quand même l'information que tu te connectes a linuxfr.org sur une socket TCP sur le port 443. C'est quand même beaucoup, suffisamment pour savoir ce que tu fais, et j'aurais presque tendance a dire que la page que tu consultes après n'a pas d'importance en comparaison.
[^] # Re: Très bon
Posté par rakoo (site web personnel) . En réponse à la dépêche Mumble 1.2.4 avec Opus. Évalué à 3.
Si on regarde bien, mumble fait de la voix là où les salons de discussions XMPP font du texte: une multitude de clients se connecte à un seul et unique serveur. Pas de fédération des salons de discussions (i.e un salon de discussion est accessible sur plusieurs serveurs), comme on peut le voir sur IRC. De ce point de vue on pourrait imaginer encapsuler le protocole mumble dans des messages xmpp, avec un bot du côté du host qui est en fait un serveur mumble, et ainsi utiliser mumble dans xmpp. On aurait une grosse perte en débit pur à cause de la transformation en Base64, mais ce serait techniquement possible.
Allez, encore un n-ième projet sur ma liste d'idées folles mais intéressantes à programmer.
[^] # Re: Charité bien ordonné...
Posté par rakoo (site web personnel) . En réponse à la dépêche Nos oignons, c'est notre affaire !. Évalué à 3.
Voici une autre explication bien claire du problème
À priori, je suis d'accord avec toi: je préfère le hasard sur le chemin de mes données fourni par un million de noeuds, fussent-ils tous lents, à quelques noeuds qui sont trop facilement trouvable, écoutables, éteignables. Manque de pot, Tor ne choisit pas ses noeuds de sortie totalement au hasard, mais les choisit en fonction de leur bande passante, ce qui fait que tu vas souvent tomber sur les même noeuds en pratique.
Du coup, on tourne sur les 50 mêmes noeuds de sortie en permanence, qu'il y ait 1 ou 1000 ou 1 million de noeuds de sortie sur une ligne ADSL.
[^] # Re: .
Posté par rakoo (site web personnel) . En réponse au journal L'open source va me tuer .... Évalué à 3.
Sans aller jusque là, peut-être que les SSLL proposaient plutôt de passer le logiciel sous une double licence classique, type libre pour tout le monde et non-libre pour le support, à la Qt ?
[^] # Re: Charité bien ordonné...
Posté par rakoo (site web personnel) . En réponse à la dépêche Nos oignons, c'est notre affaire !. Évalué à 2.
Tu peux lire la présentation, mais la réponse est simple: il ne sert à rien dans le modèle de Tor d'avoir une quantité énorme de noeuds si 95% sont sur une ligne ADSL en carton. Ce qu'il faut, c'est qu'il y ait une plus grande proportion que 5% de gros noeuds équivalents. L'association se propose de monter un autre gros noeud pour justement augmenter cette proportion.
[^] # Re: sup
Posté par rakoo (site web personnel) . En réponse au journal La gestion de courriels est-elle adulte ou encore au stade de l'enfance ?. Évalué à 2.
Disons qu'à force de tapoter sur mon clavier, je suis devenu de moins en moins bon dans la communication par voie orale. Je préfère lui laisser ces tâches là.
[^] # Re: 0 folder = inbox 0
Posté par rakoo (site web personnel) . En réponse au journal La gestion de courriels est-elle adulte ou encore au stade de l'enfance ?. Évalué à 4.
Tu peux créer un tag "niveau1/niveau2/niveau3". La séparation logique entre trois niveaux hiérarchiques est une fonction que te donne le logiciel qui traite les mails par-dessus. GMail le fait bien, et, malheureusement, je crois que c'est le seul.
Et oui, tout le problème est là. Les emails ont été conçus avec une structure hiérarchique forte, et ça se sent dans le design de maildir et dans le design d'IMAP, qui peut tout à fait être assimilé à maildir sur le réseau. Maildir en soi ne supporte pas les tags, mais il existe tout de même une solution couramment utilisée qui est de stocker les tags dans les headers du message, avec un header "X-Keywords" ou "X-Label". Du coup tu pourrais continuer d'utiliser maildir, déplacer/archiver/importer tes emails dans tous les sens, les labels resteront là. C'est une manière assez simple de faire, et je sais que mu au moins fait ça.
Après, ça c'est uniquement pour accéder à maildir; on pourrait aussi penser accéder à un serveur IMAP local qui jouerait le rôle de simple forwarder un peu comme msmtp ou dnsmasq, et par lequel tous les MUA/MTA/MDA passeraient plutôt que maildir. Je pense à cette solution parce que IMAP est standard, extensible, et que justement les extensions IMAP de Gmail offrent des fonctionnalités vraiment intéressantes pour qui veut bosser avec des tags.
Pour faire court: aujourd'hui, il n'y a aucun standard fort pour bosser avec les tags. Quelques logiciels supportent les tags dans les headers d'un message (solution la plus pérenne/inter-opérable), mais ils sont peu nombreux. De l'autre côté GMail a quelques extensions pratiques, mais qu'il est seul à implémenter.
[^] # Re: 0 folder = inbox 0
Posté par rakoo (site web personnel) . En réponse au journal La gestion de courriels est-elle adulte ou encore au stade de l'enfance ?. Évalué à 3.
qui se veut plutôt être Là où tu as des répertoires, remplace-les par des tags. Les tags permettent de faire tout ce que les dossiers proposent, et offrent encore plus. Qui peut le plus peut le moins. Tu peux donc réutiliser ta logique dans un premier temps, quitte à utiliser la puissance des tags plus tard quand tu te rends compte petit à petit de leur puissance (combinée à la puissance d'une bonne recherche).
Pour ton exemple, tu peux avoir un tag Paris2008 qui contiendra tous les mails en question. Tu pourrais aussi tagger les mails correspondants avec Paris, et spécifier en 2008 dans ta recherche, pour retrouver les mails correspondants.
Le cas d'utilisation classique est celui-ci : deux catégories "Travail" et "Maison", et deux périodes : "en 2008" et "en 2010". La manière classique et naïve de faire avec des dossiers est de créer 4 dossiers : "Travail2008", "Travail2010", "Maison2008" et "Maison2010". On voit tout de suite où ça nous mène. Tant qu'on n'a pas trop de catégories, ça passe, mais c'est pas forcément le cas. Avec des tags, tu peux faire une recherche sur "Travail et 2008" pour retrouver tous les emails correspondants; ça passe mieux à l'échelle comme on dit.
Parce que tu ne sais pas aujourd'hui ce que tu risques de faire de tes mails demain. Peut-être qu'une compagnie te spamme un peu trop aujourd'hui, et qu'elle fait partie des gros partenaires de l'opération commerciale de ta boîte demain, et que tu veux souhaite signaler (avec preuves) le côté spammeur de ce nouveau partenaire? Peut-être auras-tu envie de t'auto-héberger, et que disposer d'une bonne base de spams pour entraîner ton anti-spam est intéressant ?