rakoo a écrit 921 commentaires

Pour contrebalancer, personne ne nous oblige à rester avec Firefox si on est pas content de leur politique.

Ouais mais la le problème n'est même pas qu'ils ont une mauvaise politique, mais qu'ils fourvoient sur la politique. C'est un peu comme Google qui dit avoir comme fil conducteur do no Evil, et qui ne se gênent pas pour vendre l'ensemble des informations qu'ils ont sur toi aux plus offrants.

Alors bien sur ils ont leurs raisons, et on est tous quelque part fautifs parce qu'on donne pas assez pour assurer l’indépendance (comme OpenSSH, comme OpenSSL, et tous les autres). Mais ça c'est pas une excuse, c'est une explication.

La source, déjà: Google + is walking dead. Beaucoup de rumeurs et de bruits de couloirs, rien de concret à part le chef de la division qui quitte Google. Bref, du vent.

Je vous invite maintenant à lire une autre lecture de la nouvelle, extrêmement critique, et offre une nouvelle vision de ce qui risque d'arriver: Google+ ne sera pas "fermé", bien au contraire. Il sera moins visible, mais liera tous les services ensembles.

• Vous avez un compte Youtube ? Paf, vos commentaires se retrouvent sur votre mur
• Vous avez un Android ? Paf, vous retrouvez vos contacts sur votre page Google+
• Vous avez Chrome ? Paf, vos favoris sont visibles sur votre page Google+

Google+ va peut-être arrêter d'être un produit qui vit sa vie en tant que tel, mais il est possible qu'il devienne une plateforme pour lier tous les autres produits. Pas forcément de quoi se réjouire.

Tu vas être content d'apprendre qu'il y a une implémentation de référence libre du protocole, alors.

Tahoe-LAFS: la cible est plus le stockage distribué et sécurisé que le partage facile.

Je pense que c'est vrai, mais en plus d’être distribué et chiffré c'est quand même super simple pour le partage.

Par défaut tout ce que tu mets dans Tahoe-LAFS est immuable; lorsque tu donnes la référence d'un fichier a quelqu'un, tu lui donnes une identité immuable. Il peut uploader une autre version mais elle aura une autre identité et il faudra alors convaincre les autres que sa version est la bonne.

Les dossiers sont (en général) mutables, c'est-a-dire que tu peux modifier leur contenu et garder la même identité. Cette identité mutable est basée sur une bête paire de clés asymétriques (RSA pour le moment). Lorsque tu as créé le dossier tu as 2 identités: une qui contient la clé privée et une qui ne la contient pas. Tu peux choisir de donner la première, et tout ceux qui ont cette référence pourront modifier la valeur pointée par cette référence (puisqu'ils ont la clé privée), ou tu peux donner la deuxième, que les autres pourront seulement lire.

Et tout ça se fait de manière transparente pour l'utilisateur: tout ce qu'il voit c'est une URI qui peut pointer sur n'importe lequel des nœuds qui servent du HTTP.

Ah et en plus de ça, pour l'installation, tu galères peut-être un peu (ou pas) pour installer les dépendances python, mais après ça marche nickel.

En même temps c'est pas détectable: je crois que personne ne logue la requête de heartbeat, et personne ne logue les réponses; impossible de savoir que la fonctionnalité (ou la faille, selon le point de vue) a été utilisée.

J'ai oublie de mettre ça dans le 'nal, mais c'est intéressant: le commentaire de miod@ sur "quel nom choisir"

Il explique très clairement que le nom de cette nouvelle librairie n'avait aucune importance, que la roadmap était assez standard:

• Enlever tout ce qui dépasse
• Ajouter des features
• Faire une release stable pour OpenBSD
• En faire un projet a part, qui pourra être porté sur d'autres environnements, et en profiter pour trouver un nom
• Le tout en s'assurant de ne rien casser

Donc oui, ils ont prévu de ne supporter qu'OpenBSD dans un premier temps, ce qui est normal puisqu'ils font ça d'abord et avant tout pour eux, mais que dans la tradition OpenBSD ils feront du code suffisamment portable pour que n'importe qui puisse adapter ça a sa plateforme. Ils te disent pas juste merde, ils te disent "merde pour le moment, reviens dans 6 mois. Oh et la page de dons c'est par la".

Bon, au final ils ont fait les choses a l'envers (ils ont trouvé un nom), j’espère qu'ils se travestiront pas plus que ça.

C'est quand même un peu ballot. Tu quittes Dropbox pour son œil qui s'attarderait potentiellement un peu trop sur tes données, pour te réfugier chez Bittorrent Sync qui ne t'offre pas plus de garanties de ce côté. C'est dommage. Malheureusement, comme tu dis, il n'y a pas d'alternatives libre à la hauteur…

Et pour comprendre pourquoi le système actuel est naze mais qu'il est difficile d'en changer, je te conseille une présentation de Moxie Marlinspike, quelqu'un qui bosse dans la cryptographie.

La deuxième partie présente l'une de ses solutions, qui a peu de chances d’être déployée (il promeut lui-même quelque chose d'encore différent) mais la première partie explique bien le problème.

Autopub: viendez essayer sup. C'est l'ancêtre de notmuch, abandonné pendant un temps, mais qui est maintenant bien vivant. C'est du terminal, certes, mais je pense que ça peut en intéresser certains. Le plus intéressant est qu'il est basé sur les mêmes principes que GMail:

• les messages sont la ressource principale, les threads sont créés dynamiquement en suivant les guidelines standards
• pas de dossiers, mais des labels
• tout est recherche

et le mieux, c'est que la ui est complète, contrairement à notmuch qui demande un logiciel à part pour l'utilisation au quotidien de ses emails.

Je l'utilise quotidiennement avec offlineimap pour avoir une copie locale de mes mails (au cas où je suis déconnecté, je peux toujours lire mes mails) et opensmtpd pour envoyer les mails, mais msmtp marche très bien aussi. Le chiffrement s'intègre directement avec le trousseau de clefs du système: la seule interaction que vous verrez est l'agent qui vous demandera le mot de passe pour chiffrer/déchiffrer les messages à la volée.

Il y a un utilitaire de configuration qui permet de débuter, avec suffisamment de questions pour aider les débutants complets. Et s'il le faut, la mailing-list est disponible et accueillante.

Car un article qui dès le titre établit une relation possible avec la NSA ne peut augurer que du bon.

Bon, c'est vrai que j'évite de tomber dans la parano quand je peux. Mais là, en l’occurrence, il est difficile de croire que la NSA n'avait pas cette info et n'en avait pas profité.

Tiens, d'ailleurs, on commence à voir des articles qui accusent la NSA d'avoir su.

C'est par ici.

Tiens, sur le sujet, j'ai vu fpm l'autre jour, peut-être que ça t'intéressera.

je ne vous pas en quoi il serait techniquement impossible de faire en p2p ce que nous faisons avec des services centraux

Juste sur le plan technique, je vois 2 gros problèmes:

• La masse écrasante de machines placées derrière un NA(P)T, inaccessibles depuis l'extérieur
• Les débits montants ridicules d'une ligne fixe classique

En plus de ça, comme les mobiles ont rarement une IP fixe, il est difficile de leur envoyer des paquets sans passer par des moyens détournés. Et comme à peu près personne dans le public n'a de noms de domaine, impossible de masquer la mobilité de l'IP derrière un DNS.

Sur le plan légal, il me semble que l'affirmation "je partage un bout de mon disque dur et tout le monde met ses informations chiffrées dessus, donc si c'est illégal je n'ai aucun moyen de le savoir donc je suis innocent" n'a jamais été testée. C'est un peu sur ce point que certains, même techniques, restent frileux (si vous lancez un nœud Freenet, j'ai peur de devoir vous dire qu'il y a une chance assez élevée pour que vous hébergiez du contenu pas joli-joli).
Je comprends que la plupart des gens ne veulent pas risquer d'aller là-dedans, surtout quand ils savent qu'un tiers peut prendre cette responsabilité plutôt qu'eux.

Foutaises !

Ben justement: la priorisation du trafic doit être l'affaire des pairs (donc de mon téléphone et du pc de mon correspondant), pas des réseaux qui sont au milieu. Si le routeur est bouché, faut pas qu'il privilégie les paquets de tel ou tel type: faut passer par un autre routeur moins encombré.

Ubuntu One est base sur le protocole u1db, qui est lui-même dérivé de couchdb. Les raisons de la divergence sont expliquées dans un mail: en gros, couchdb tel quel n'est pas pratique a utiliser pour une utilisation personnelle et pour une utilisation massivement centralisée. En plus de ça, couchdb n'est pas évident a utiliser lorsqu'on veut faire des requêtes dessus. Du coup ils ont implémenté leur propre sauce qui ressemble beaucoup a couchdb dans les principes (voir lien précédent).

Le plus intéressant est qu'ils fournissent une implémentation libre de reference, c'est a dire qu'un client pouvait être développé en la prenant comme référence, et remplacer l'url distante par celle de Ubuntu One sans se poser de questions sur la compatibilité. Pour tous ceux qui cherchent une implémentation libre, je leur conseille d'y jeter un coup d’œil (bien sur, cette implémentation est oriente utilisateur unique, mais ça devrait suffire pour pas mal d'usages).

C'est dommage, ils avaient plein d’idées intéressantes dans leur machin. J’espère que quelqu'un reprendra la chose.

Merci pour cette présentation, je trouve Clojure vraiment intéressant pour voir à quoi le LISP peut ressembler, vu les éloges qu'on en fait. Comme prévu, ça change de la programmation impérative.

Pour ceux qui veulent aller plus loin, il y a ce tutorial qui permet d'aller assez loin dans la découverte de Clojure.

Réflexion

Alors c'est comme ça qu'on appelle un troll aujourd'hui ? Les choses changent trop vite pour moi.

La plus grosse blague, qui m'a l'air d’être apparu avec Windows 7, c'est les "Libraries" (je sais pas comment c'est dans la version francaise, ou meme si c'est traduit). En fait ce sont des faux dossiers qui agrègent d'autres vrais dossiers sur le disque.

Par défaut, les applications proposent de sauvegarder dans le dossier "Documents" dans "Libraries", super. Sauf que c'est un dossier virtuel, et qu'il n'y a aucune indication nulle part sur ou c'est mis sur le disque dur. Donc si tu ouvres l'explorateur de fichiers tu peux retomber sur ce "Documents", mais si ton application ne sait parler que système de fichiers, et ben tu l'as dans l'os.

Alors oui, on peut faire clic-droit sur le faux-dossier et définir ou sont enregistres les fichiers. Et bah sur la machine que j'utilise, le dossier est un "My Documents" dans mes userfiles. Rien a voir avec le fameux "My Documents", le dossier poubelle par défaut, qui existe bien, et qui est dans le même dossier. Et il n'y a aucun conflit de nommage, puisque l'un des deux s'appelle réellement "My Documents" et que l'autre s'appelle en fait "Documents" mais est traduit "My Documents" dans l'explorateur. Mais pas en ligne de commande.

Du coup, quand on me demande de l'aide sur Windows 7, l'un de mes conseils est de ne JAMAIS utiliser ce dossier virtuel, source de confusion pour moi.

Avec un nom comme ça, pas étonnant qu'ils te connectent à tout le monde.

Blague à part, j'utilise Disconnect, qui à l'air de faire la même chose que RequestPolicy. Et bah ça fait bien son boulot.

L'un des gros avantages de Hack est que par défaut, les types n'acceptent pas de valeur nulle. Impossible donc, à priori, de se manger des exceptions de pointeur nuls en prod: on détecte tout ça à la compilation !

Enfin je dis ça sans avoir testé, mais si ça marche vraiment comme ça c'est vraiment un plus indéniable par rapport à un bête typage statique qu'on peut trouver ailleurs. Bravo, les gars.

Et si on accepte une valeur nulle, il faut le dire explicitement en rajoutant un ? devant le type: celui-ci devient alors nullable

Oh oui je suis tout à fait d'accord, le JSON est bien plus facile à utiliser dans n'importe quel langage puisqu'il y aura à peu près tout le temps une librairie pour le faire. C'est aussi plus agréable de bosser avec.

Je demandais ça parce que le RSS et l'Atom ont déjà un format, qui en plus est fait pour les traitements automatisés. Ce format est normalisé et spécifié un peu partout (contrairement au tien qui bien que simple, n'existe que sur un README en plus du code) et pour lequel tu trouveras déjà de la documentation et des outils.

Si tout le monde utilisait des flux RSS en JSON, ça serait quand même plus simple.

Super projet ! J'adore l'idée de séparer les bouts de logique et de faire communiquer sur stdout. Philisophie UNIX toussa.

Par contre je m'interroge sur l'intérêt de mettre une couche intermédiaire de JSON. À ce que je sache, le JSON n'apporte rien fonctionnellement ou techniquement par rapport aux entrées qui sont déjà formatées et normalisées, que ce soit RSS ou Atom.

PSHH

PSHB (Le nom correct est PubSubHubBub).

Ouais, ce nom est relativement naze.

est-ce qu'il est totalement illégitime pour l'auteur de la copie de souhaiter que cela se passe ainsi ?

Ce que les autres essaient de te dire, et ce avec quoi je suis d'accord, c'est que son travail (une photographie fidèle d'une œuvre d'art) n'est pas une œuvre nouvelle en soi; le droit qui s'applique sur les œuvres ne s'applique pas dessus, et donc il n'a rien a en exiger. Je pourrais recopier un livre lettre par lettre et distribuer ma copie, ça n'en ferait pas un œuvre nouvelle pour autant. Encore une fois, si c'est pas considéré comme une nouvelle œuvre c'est parce que le photographe (ou moi dans mon parallèle) n'a rien apporté a l’œuvre originale.

Comment fait-il pour remplir son frigo à la fin du mois ?

Absolument rien a fiche. Si le photographe veut prendre des photos, c'est un artiste. S'il veut gagner de l'argent avec son activité, c'est un homme d'affaires. Il n'y a rien dans la loi qui oblige la société a remplir le frigo de tous ceux qui veulent gagner de l'argent avec leur activité, peu importe leur activité… et je suis plutôt pour que ça reste comme ça.