Je rêve ! On est bien en train d'assister a un concours de kekettes sur le temps de compilation d'un programme tellement trivial qu'il n'est pas représentatif d'un vrai programme ?
Euh nan, configure et make doivent absolument être lancés en tant qu'utilisateur non privilégié; ça n'a absolument pas besoin de droits supplémentaires.
make install n'a besoin des droits root que si tu installes l'application dans les répertoires "OS", genre /usr, /bin et tout le tintouin. Si tu as configuré l'install pour se faire dans un répertoire dans lequel tu as les droits (genre /home/chezmoi/monappli), tu n'as pas besoin des droits root. Mais, c'est vrai, un petit malin peut très bien avoir placé une commande pas drôle dans la cible install.
De manière générale cette discussion me fait un peu peur sur l'état général des déploiements au grand large des applications et sur l'absence d'un moyen-qui-marche-à-tous-les-coups si on sort des moyens privilégiés de son OS…
Heureusement que tu précises que t'es pas énervé, parce qu'on pourrait croire le contraire :)
Débattons, débattons !
J'aimerais juste rappeler le point de départ de la discussion, qui est la question intéressante posée par devnewton:
si vous deviez refaire un protocole depuis 0 aujourd'hui, est-ce que vous aboutiriez à un XMPP like ou à complètement autre chose?
À laquelle je réponds "XMPP c'est top, ça juste marche dans les cas où on l'utilise le plus, c'est extensible, c'est ouvert, c'est implémenté de milles et une manières et ça a pas l'air de s’essouffler de ce coté là". Bref, c'est bien, il faut aller dans ce sens et améliorer l'existant plutôt que réinventer la roue. Je suis d'accord avec toi. Si on devait recommencer de 0, on pourrait garder une grosse grosse majorité de ce qu'on a déjà.
Mais (et ça n'est que mon avis), ça n'est pas parfait, et si je devais recommencer de 0 je changerais XML par autre chose. Encore une fois, expérience de pensée !
Maintenant, quelques précisions:
Sur le routage
Je persiste et signe, XMPP est un protocole de routage, clairement pas au sens de "routage de paquets IP", mais bien "routage de fragment XML". La différence est qu'une table de routage, c'est à dire l'ensemble des routeurs qu'un routeur connaît et à qui il est capable de parler, c'est l'ensemble des domaines qui ont un serveur.
Cas simple: je veux envoyer un message à edward@snowden.com; le seul qui sait comment faire c'est snowden.com. Je ne connais pas snowden.com, par contre mon serveur le connaît; j'envoie mon stanza à mon serveur qui transmet.
Cas MUC/Pubsub: c'est du multicast tout ce qu'il y a de plus connu. Ma ressource -> mon serveur -> le serveur qui héberge le service de pubsub -> le noeud pubsub, et inversement pour la diffusion (Note que cette fois ce qui est routé c'est pas un stanza entier, c'est le(s) item(s))
Cas un peu plus compliqué: je veux parler à quelqu'un sur IRC. Ma ressource -> mon serveur -> le serveur qui héberge la passerelle -> la passerelle (possiblement en tant que composant) -> IRC
Je vois XMPP comme étant capable de beaucoup plus que juste amener les stanza d'un client à un autre: par exemple si un domaine héberge un "serveur" XMPP sur un cluster de serveurs, ça serait vraiment bien d'utiliser XMPP de bout en bout. Ça permettrait par exemple de construire "facilement" des clusters en prenant n'importe quelle implémentation qui respecte les standards pour se faire son n-ième SecretWhatSnapLine, et ainsi faire avancer le protocole (soit en participant au réseau, soit en améliorant les outils existants).
Ça va vachement plus loin que SMTP, qui s'arrête au To, là on a potentiellement plusieurs niveaux de routage qui permettent un adressage vraiment fin.
Sur le binaire
J'ai l'impression que tu fais le raccourci "binaire => gros machin qui bouche le tuyau".
C'est très certainement vrai si tu utilises la manière naïve, qui est de tout mettre dans un gros paquet, ce qui est à mon sens sacrément stupide. Dans ce cas-là tu segmentes ton binaire, tu l'envoies morceau par morceau avec la possibilité pour les messages non-binaires de passer. Mais c'est vrai, ça veut aussi dire qu'un participant à une MUC peut envoyer des méga-gifs de chatons qui vont juste embêter tout le monde. Au fond je me disais juste "qui peut le plus peut le moins": si le protocole pouvait utiliser du binaire, il pourrait faire passer n'importe quoi par dessus, y compris du XML structuré comme ce qu'on a aujourd'hui, mais aussi du HTML sans avoir à l'échapper ou un message chiffré/signé sans avoir à le base64.
Sur le parsing
Parser, ça veut dire passer la suite d'octets reçus de la socket dans la moulinette pour en extraire une structure qui a du sens (de manière à poser quelques pointeurs qui permettent un accès rapide aux différents éléments). Sauf que si c'est un serveur, le "sens" qui l'intéresse, il s'arrête au to; le sens de ce qu'il y a en dessous c'est surtout pour le niveau suivant, par exemple le module de pubsub, qui potentiellement peut être sur un autre serveur (routage, encore). Dans ce cas là on aura 2 "analyses" complètes du message…
Plus généralement
Encore une fois, je parle de ce qu'il y aurait à changer si on repartait de 0, mais c'est clairement du chipotage, et ça n'enlève en rien les qualités de XMPP. Je crois que la seule bonne conclusion qu'on peut avoir c'est si on repartait de 0, on arriverait largement à la même chose.
Perso, s'il y a bien un truc a changer pour moi, c'est XML.
Non pas parce que c'est verbeux (c'est verbeux, mais c'est pas le problème) mais précisément pour ce que tu penses être un non-problème:
Pas de support du binaire
Pourquoi ? XMPP est un protocole de routage, pourquoi devrait-il dicter quoi que ce soit sur le format du contenu ? (Je pense aussi a XHTML-IM, qui va dans le même sens: en fonction du contenu que tu as a envoyer, tu dois le formater correctement…)
Sur ce point je vois pas pourquoi il faudrait ouvrir une 2e connexion en parallèle alors qu'on en a déjà une. Ouvrir une 2e connexion c'est intéressant si t'as un flux long terme en parallèle, comme de la VoIP. Mais avoir du binaire dans la connexion déjà ouverte, ça peut être utilisé par exemple pour un petit transfert (genre image de chaton dans le salon de discussion) ou pour signer/chiffrer un message.
Pas de framing
Encore une fois, je considère XMPP comme un protocole de routage. Du coup, les éléments sur la route n'ont pas besoin de savoir ce qu'ils routent… et pourtant, ils doivent parser tout le stanza pour récupérer les éléments qui les intéressent. Même si ça les concerne a peine; je pense par exemple aux stanza dans la XEP de microblogging, qui concernent pas le serveur mais plutôt le service de microblogging lui-même, et pourtant ils sont assez énormes. Tout ce qui les intéresse, c'est le "to" du message pour savoir dans quel tuyau envoyer le stanza. Et ça peut aller plus loin, pour reprendre l'exemple du microblogging, on pourrait imaginer pour un domaine suffisamment gros que les items sont envoyés sur un serveur différent en fonction du node associé; ça, c'est pas faisable simplement avec XML, mais avec du framing propre c'est envisageable.
C'est même pas du vrai XML
Bon la c'est plus pour le troll qu'autre chose, parce que je connais pas suffisamment, mais c'est pas moi qui le dit, c'est les gens de Psyc et cette lib.
Du coup
S'il y a une chose que je changerais, ce serait remplacer XML par un protocole qui répond a ces deux besoins tout en restant humainement lisible/hackable, parce que faut pas se mentir, un protocole ouvert ne se répand que s'il est facilement implementable. Mais je garderai la structure générale des messages et de leur traitement qu'on a aujourd'hui, pour le peu que je connais ça marche plutôt bien
Du coup JSON n'est pas une solution, mais je pense par exemple a bencode (moyen) ou otnetstring (mieux) avec une spécification supplémentaire pour garder la compatibilité avec le XML existant (du genre, un element == un dict, les attributs sont des valeurs dont les clés sont par exemple "@xmlns" ou "@to", les éléments a l’intérieur sont accessibles via leur nom, potentiellement avec leur xmlns, et si c'est pas du dict on y accede via "#in")
Là encore, tu pars du principe que Microsoft est un mauvais acteur du jeu vidéo, qui transforme tout ce qu'il touche en Candy Crush. On a l'habitude de dire la même chose dans le domaine du logiciel en général (à tort ou à raison, c'est une autre question), mais dans le domaine du jeu vidéo il s'en sort pas trop mal.
Peut-être qu'ils ont des plans pour d'autres jeux vidéos intéressants ? Des plans qui nécessitent une équipe de développeurs talentueux et qui sait travailler ensemble, comme un studio qui existe déjà ?
En gros, on est dans le flou, c'est dommage (et peut-être dangereux) de se dire que tout va péter alors qu'on n'en a aucune idée.
Je pense qu'on peut aller plus loin dans la réflexion que "Microsoft = caca".
Du coup je me demande: en quoi est-ce que cette nouvelle est une mauvaise nouvelle ? Je ne suis pas de très près le monde des jeux vidéos, mais j'ai plutôt un bon souvenir de Microsoft dans ce domaine là (les Age of Empires, les Halo, Flight Simulator même-si-c'est-pas-vraiment-un-jeu..). La page du studio me fait penser que la situation est plutôt positive.
En plus de ça, on n'a (il me semble) pas d'info sur le deal; peut-être que l'équipe gardera une liberté suffisante pour continuer à produire du bon ?
Quand on pense qu'ils auraient pu se faire racheter par EA, on se dit qu'ils auraient pu tomber bien plus bas. Mais même, dans l'absolu, c'est pas trop mal; alors, il est où le problème ?
Je n'aime pas le principe de déclarer au monde entier que ce midi, qu'il y avait frites à la cantoche et que ça va bien, merci !
Faudrait arrêter de résumer "réseau social" a "Facebook tel qu'utilisé par certains mais moi je sais pas de toute façon j'utilise pas ça". Oui, il y en a qui utilisent Facebook ou Twitter comme ça. Non, ça ne veut pas dire que c'est pareil partout.
Est-ce qu'on parle des frites de la cantoche sur la LKML ? Non, et pourtant la LKML est un réseau social. Est-ce qu'on parle de tarte aux pommes sur LinuxFR ? Oui, même si on peut naïvement considérer que LinuxFR est mieux que Facebook. Est-ce que Humhub interdit de parler de frites de la cantoche ?
Je vois au moins un intérêt a Facebook: l'organisation d’évènements est vraiment simple. Non pas que c’était impossible avant, juste que les moyens de communication offerts par Facebook permettent de tout faire depuis une seule interface, a un seul endroit, sans avoir a rien installer, et qui tient tout le monde a jour en continu.
Maintenant, si nous autres adeptes des libertés individuelles voulons arrêter que tout le monde donne ses informations a un tiers et qu'ils gardent le contrôle sur leurs données, il faut qu'on comprenne les besoins pour fournir des alternatives, pas cracher sur les outils qu'on n'utilise même pas.
Les 2 XEPs que je propose (celle en attente de publication et celle qui ne devrait pas tarder) devraient permettre d'utiliser un service PubSub indépendant de celui du serveur
Par pure curiosité, qu'est-ce qui empêche de faire tourner un pubsub en tant que composant ? (Si vous avez d'autres canaux de discussions ça m'intéresse, j'ai envie que XMPP se répande un peu plus)
J'ai lu il y a quelque jours (il faudrait que je retrouve la source) que si XMPP avance pas, c'est parce qu'il y a beaucoup de discussions mais personne pour prendre les rênes sur un projet en particulier et le faire avancer. C'est donc pas un problème technique.
À l'avenir je ne pense pas que XMPP disparaîtra, parce que c'est juste un protocole et qu'il est suffisamment (trop ?) documenté pour que quelqu'un l'implémente dans le langage du jour. Tox a son propre protocole mais est avant tout un ensemble d'applications qui sont faites pour communiquer ensemble.
nous recherchons quelques idées de démos logicielles (il y aura 4 cartes mono Xeon par RuggedPOD interconnectées en 10Gb/s)
Minez du bitcoin, ou plutôt une altcoin dans laquelle les CPU ont encore du sens face aux GPU et ASIC (cf ici).
Vous pouvez aussi jouer au concours de kékettes (c'est le but) et faire un million de transactions par seconde sur la base de données Nosql du jour. Si des entreprises sont là, ça peut être vendeur (bon pour info ils ont réussi à atteindre le même nombre psychologique sur des instances EC2).
Le web tel qu'on l'utilise aujourd'hui, c'est deux choses:
Une identité, qui permet d'accéder à des services: "Madame Soleil, quel temps fera-t-il demain ?"
Un transport, qui permet d'échanger du contenu: "Boulangère, donnez-moi les 2 plus belles miches que vous avez"
On a fait beaucoup de choses. Ce qui t'intéresse c'est d'abord et avant tout les miches de la boulangère; qu'elle les distribue dans sa boulangerie ou ailleurs, à partir du moment où tu es sûr qu'elles sont authentiques, on est bon. Pour prendre un exemple un peu plus parlant, que tu achètes ton pot de Nutella chez Casino ou chez Carrefour, c'est le même; peu importe qui le distribue.
Et bah bittorrent et consorts, c'est la même chose. Peu importe qui le distribue, tant que le contenu est le bon tout va bien. Le terme kivabien est Content Addressed Storage, qui montre bien que le contenu est plus important que la provenance. Tout ça c'est un problème plutôt résolu. Un projet intéressant à suivre dans ce domaine: ipfs. Il s'agit d'avoir un système global permettant de donner une URI à n'importe quelle donnée et de pouvoir ainsi y accéder quel que soit le serveur hébergeant les données, tout en étant bien plus souple que bittorrent… enfin ya plein d'idées, vaut mieux lire le papier et regarder la vidéo pour voir plus en détails.
D'ailleurs, BitWeb, ça me rappelle SyncNet, une idée vachement similaire (un navigateur qui utilise Bittorrent Sync pour transporter le contenu).
Par contre, la première utilisation que j'ai listée, les services, c'est plus difficile à décentraliser. Parce que contrairement à de simples octets que tu peux distribuer, là il s'agit de distribuer des fonctionnalités, donc en gros du code. Et il faut soi faire confiance à chaque nœud pour être sûr qu'il répond correctement, soi avoir un moyen de vérifier ce qu'il dit… ce qui voudrait dire qu'on a déjà la réponse, auquel cas on n'aurait même pas besoin de lui demander quoi que ce soit. M'enfin.
Il me semble que c'est la direction que veut prendre Ethereum , mais j'ai pas suivi de trop près, il faut creuser pour en savoir plus.
Donc ça ne te dérange pas d'avoir partout dans le monde un "Nicolas Boulay a dit qu'il faut tuer tous les non français" ou qu'on montre des vidéos de toi dans ta vie la plus intime (par exemple), au nom de la liberté d'expression?
Petite parenthèse parce que cet argument est stupide: "Ça te dérangerait pas qu'on fasse ça ? Si ? Bon, alors il faut l'interdire".
Non. C'est même pas un argument ça. C'est pas parce que je fais (ou ne fais pas) quelque chose que tout le monde devrait faire pareil. Je (en tant que cible de ce genre de questions) ne suis pas le modèle à suivre pour la société, les lois se décident ensemble.
"Ça te dérangerait pas qu'on autorise le cannabis ? Si ? Bon, alors il faut l'interdire"
"Ça te dérangerait pas qu'on autorise le mariage homosexuel ? Si ? Bon, alors il faut l'interdire"
"Ça te dérangerait pas qu'on autorise Netflix en France et qu'on tue les pov' créateurs de contenu ? Si ? Bon, alors il faut l'interdire"
Ça fait juste appel aux mœurs et aux émotions, pas à la logique. Cette habitude doit disparaitre.
Le vrai problème, c'est l'interface utilisateur. Tu peux utiliser tous les protocoles que tu veux dans tous les sens, a partir du moment ou tu as besoin de deux applications différentes pour avoir les mêmes fonctionnalités c'est mort. Les protocoles c'est un problème de développeur, pas d'utilisateur. Alors comme on est tous des gens techniques qui voyons comment se passent les choses en coulisse, on se dit que "ça devrait marcher si on fait ça comme ça; pas besoin de ce mastodonte". Le problème c'est qu'en faisant ça on ne résout que la moitie du problème. C'est une erreur de se focaliser uniquement sur la technique.
Pour aller plus loin dans ton idée, fais nous donc:
une appli unique
qui permet d’héberger un site web et d'en éditer les pages
qui fait aussi MTA et MUA pour gérer les emails lies aux sites (pas besoin d'un truc multi-comptes)
qui gère les mailing-lists, permet de valider qui s'inscrit, et d'ajouter/enlever des personnes si on le souhaite
Bonus si tout ça marche dans un navigateur.
Au final, tu vas plus te casser la tête qu'autre chose avec les emails… alors que tu peux utiliser un protocole beaucoup plus adapte pour ca. Mais ça ne changera rien au problème: L'interface utilisateur est la chose la plus importante a garder en tête.
Ceci dit, j'imagine qu'avec un proxy, on peut changer cela, le proxy faisant office de passerelle d'internaute, c'est lui qui déchiffre les informations
Bien sur ça existe, et il en parle même dans l'article: le déchiffrement dégraderait les performances de 74%. C'est une des raisons qui fait qu'il est contre.
Comme dit en dessous, c'est DANE. Le problème de DANE est qu'il part du principe que les enregistrements DNS arrivent intacts depuis le NS du domaine jusqu’à chez toi, ce qui est pour le moment hautement illusoire. Il faut utiliser DNSSEC (ou autres) pour acheminer les enregistrements, mains DNSSEC c'est une autre paire de manches a installer et maintenir.
Ou alors se reposer sur un truc style protocole bitcoin (ou bitcloud ! http://bitcloudproject.org/) pour stocker la clé de validation ?
Et bien justement, dnschain permet ça. Le principe est simple: il y a deja des specifications pour enregistrer ses noms de domaines et son identite dans Namecoin. Malheureseument Namecoin c'est son monde a part avec son client specialement fait pour. C'est la que dnschain fait le pont, puisqu'il permet d'acceder aux informations depuis des moyens connus:
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par rakoo (site web personnel) . En réponse au journal Retour aux sources. Évalué à 10.
Je rêve ! On est bien en train d'assister a un concours de kekettes sur le temps de compilation d'un programme tellement trivial qu'il n'est pas représentatif d'un vrai programme ?
[^] # Re: Au secours !!!
Posté par rakoo (site web personnel) . En réponse au journal git-webui : une interface web pour vos repos git. Évalué à 3.
Euh nan,
configureetmakedoivent absolument être lancés en tant qu'utilisateur non privilégié; ça n'a absolument pas besoin de droits supplémentaires.make installn'a besoin des droits root que si tu installes l'application dans les répertoires "OS", genre/usr,/binet tout le tintouin. Si tu as configuré l'install pour se faire dans un répertoire dans lequel tu as les droits (genre/home/chezmoi/monappli), tu n'as pas besoin des droits root. Mais, c'est vrai, un petit malin peut très bien avoir placé une commande pas drôle dans la cibleinstall.De manière générale cette discussion me fait un peu peur sur l'état général des déploiements au grand large des applications et sur l'absence d'un moyen-qui-marche-à-tous-les-coups si on sort des moyens privilégiés de son OS…
[^] # Re: on refait le protocole
Posté par rakoo (site web personnel) . En réponse au journal Retour de Berlin. Évalué à 4.
Heureusement que tu précises que t'es pas énervé, parce qu'on pourrait croire le contraire :)
Débattons, débattons !
J'aimerais juste rappeler le point de départ de la discussion, qui est la question intéressante posée par devnewton:
À laquelle je réponds "XMPP c'est top, ça juste marche dans les cas où on l'utilise le plus, c'est extensible, c'est ouvert, c'est implémenté de milles et une manières et ça a pas l'air de s’essouffler de ce coté là". Bref, c'est bien, il faut aller dans ce sens et améliorer l'existant plutôt que réinventer la roue. Je suis d'accord avec toi. Si on devait recommencer de 0, on pourrait garder une grosse grosse majorité de ce qu'on a déjà.
Mais (et ça n'est que mon avis), ça n'est pas parfait, et si je devais recommencer de 0 je changerais XML par autre chose. Encore une fois, expérience de pensée !
Maintenant, quelques précisions:
Sur le routage
Je persiste et signe, XMPP est un protocole de routage, clairement pas au sens de "routage de paquets IP", mais bien "routage de fragment XML". La différence est qu'une table de routage, c'est à dire l'ensemble des routeurs qu'un routeur connaît et à qui il est capable de parler, c'est l'ensemble des domaines qui ont un serveur.
Cas simple: je veux envoyer un message à edward@snowden.com; le seul qui sait comment faire c'est snowden.com. Je ne connais pas snowden.com, par contre mon serveur le connaît; j'envoie mon stanza à mon serveur qui transmet.
Cas MUC/Pubsub: c'est du multicast tout ce qu'il y a de plus connu. Ma ressource -> mon serveur -> le serveur qui héberge le service de pubsub -> le noeud pubsub, et inversement pour la diffusion (Note que cette fois ce qui est routé c'est pas un stanza entier, c'est le(s) item(s))
Cas un peu plus compliqué: je veux parler à quelqu'un sur IRC. Ma ressource -> mon serveur -> le serveur qui héberge la passerelle -> la passerelle (possiblement en tant que composant) -> IRC
Je vois XMPP comme étant capable de beaucoup plus que juste amener les stanza d'un client à un autre: par exemple si un domaine héberge un "serveur" XMPP sur un cluster de serveurs, ça serait vraiment bien d'utiliser XMPP de bout en bout. Ça permettrait par exemple de construire "facilement" des clusters en prenant n'importe quelle implémentation qui respecte les standards pour se faire son n-ième SecretWhatSnapLine, et ainsi faire avancer le protocole (soit en participant au réseau, soit en améliorant les outils existants).
Ça va vachement plus loin que SMTP, qui s'arrête au To, là on a potentiellement plusieurs niveaux de routage qui permettent un adressage vraiment fin.
Sur le binaire
J'ai l'impression que tu fais le raccourci "binaire => gros machin qui bouche le tuyau".
C'est très certainement vrai si tu utilises la manière naïve, qui est de tout mettre dans un gros paquet, ce qui est à mon sens sacrément stupide. Dans ce cas-là tu segmentes ton binaire, tu l'envoies morceau par morceau avec la possibilité pour les messages non-binaires de passer. Mais c'est vrai, ça veut aussi dire qu'un participant à une MUC peut envoyer des méga-gifs de chatons qui vont juste embêter tout le monde. Au fond je me disais juste "qui peut le plus peut le moins": si le protocole pouvait utiliser du binaire, il pourrait faire passer n'importe quoi par dessus, y compris du XML structuré comme ce qu'on a aujourd'hui, mais aussi du HTML sans avoir à l'échapper ou un message chiffré/signé sans avoir à le base64.
Sur le parsing
Parser, ça veut dire passer la suite d'octets reçus de la socket dans la moulinette pour en extraire une structure qui a du sens (de manière à poser quelques pointeurs qui permettent un accès rapide aux différents éléments). Sauf que si c'est un serveur, le "sens" qui l'intéresse, il s'arrête au to; le sens de ce qu'il y a en dessous c'est surtout pour le niveau suivant, par exemple le module de pubsub, qui potentiellement peut être sur un autre serveur (routage, encore). Dans ce cas là on aura 2 "analyses" complètes du message…
Plus généralement
Encore une fois, je parle de ce qu'il y aurait à changer si on repartait de 0, mais c'est clairement du chipotage, et ça n'enlève en rien les qualités de XMPP. Je crois que la seule bonne conclusion qu'on peut avoir c'est si on repartait de 0, on arriverait largement à la même chose.
[^] # Re: ISO-8859-1 ???
Posté par rakoo (site web personnel) . En réponse au journal Le prix des carburants enfin en OpenData. Évalué à 4.
[^] # Re: on refait le protocole
Posté par rakoo (site web personnel) . En réponse au journal Retour de Berlin. Évalué à 4.
Perso, s'il y a bien un truc a changer pour moi, c'est XML.
Non pas parce que c'est verbeux (c'est verbeux, mais c'est pas le problème) mais précisément pour ce que tu penses être un non-problème:
Pas de support du binaire
Pourquoi ? XMPP est un protocole de routage, pourquoi devrait-il dicter quoi que ce soit sur le format du contenu ? (Je pense aussi a XHTML-IM, qui va dans le même sens: en fonction du contenu que tu as a envoyer, tu dois le formater correctement…)
Sur ce point je vois pas pourquoi il faudrait ouvrir une 2e connexion en parallèle alors qu'on en a déjà une. Ouvrir une 2e connexion c'est intéressant si t'as un flux long terme en parallèle, comme de la VoIP. Mais avoir du binaire dans la connexion déjà ouverte, ça peut être utilisé par exemple pour un petit transfert (genre image de chaton dans le salon de discussion) ou pour signer/chiffrer un message.
Pas de framing
Encore une fois, je considère XMPP comme un protocole de routage. Du coup, les éléments sur la route n'ont pas besoin de savoir ce qu'ils routent… et pourtant, ils doivent parser tout le stanza pour récupérer les éléments qui les intéressent. Même si ça les concerne a peine; je pense par exemple aux stanza dans la XEP de microblogging, qui concernent pas le serveur mais plutôt le service de microblogging lui-même, et pourtant ils sont assez énormes. Tout ce qui les intéresse, c'est le "to" du message pour savoir dans quel tuyau envoyer le stanza. Et ça peut aller plus loin, pour reprendre l'exemple du microblogging, on pourrait imaginer pour un domaine suffisamment gros que les items sont envoyés sur un serveur différent en fonction du node associé; ça, c'est pas faisable simplement avec XML, mais avec du framing propre c'est envisageable.
C'est même pas du vrai XML
Bon la c'est plus pour le troll qu'autre chose, parce que je connais pas suffisamment, mais c'est pas moi qui le dit, c'est les gens de Psyc et cette lib.
Du coup
S'il y a une chose que je changerais, ce serait remplacer XML par un protocole qui répond a ces deux besoins tout en restant humainement lisible/hackable, parce que faut pas se mentir, un protocole ouvert ne se répand que s'il est facilement implementable. Mais je garderai la structure générale des messages et de leur traitement qu'on a aujourd'hui, pour le peu que je connais ça marche plutôt bien
Du coup JSON n'est pas une solution, mais je pense par exemple a bencode (moyen) ou otnetstring (mieux) avec une spécification supplémentaire pour garder la compatibilité avec le XML existant (du genre, un element == un dict, les attributs sont des valeurs dont les clés sont par exemple "@xmlns" ou "@to", les éléments a l’intérieur sont accessibles via leur nom, potentiellement avec leur xmlns, et si c'est pas du dict on y accede via "#in")
[^] # Re: Question naïve
Posté par rakoo (site web personnel) . En réponse au journal Minecraft est mort :-( Vive... Minetest \o/. Évalué à 3.
Là encore, tu pars du principe que Microsoft est un mauvais acteur du jeu vidéo, qui transforme tout ce qu'il touche en Candy Crush. On a l'habitude de dire la même chose dans le domaine du logiciel en général (à tort ou à raison, c'est une autre question), mais dans le domaine du jeu vidéo il s'en sort pas trop mal.
Peut-être qu'ils ont des plans pour d'autres jeux vidéos intéressants ? Des plans qui nécessitent une équipe de développeurs talentueux et qui sait travailler ensemble, comme un studio qui existe déjà ?
En gros, on est dans le flou, c'est dommage (et peut-être dangereux) de se dire que tout va péter alors qu'on n'en a aucune idée.
# Question naïve
Posté par rakoo (site web personnel) . En réponse au journal Minecraft est mort :-( Vive... Minetest \o/. Évalué à 10.
Je pense qu'on peut aller plus loin dans la réflexion que "Microsoft = caca".
Du coup je me demande: en quoi est-ce que cette nouvelle est une mauvaise nouvelle ? Je ne suis pas de très près le monde des jeux vidéos, mais j'ai plutôt un bon souvenir de Microsoft dans ce domaine là (les Age of Empires, les Halo, Flight Simulator même-si-c'est-pas-vraiment-un-jeu..). La page du studio me fait penser que la situation est plutôt positive.
En plus de ça, on n'a (il me semble) pas d'info sur le deal; peut-être que l'équipe gardera une liberté suffisante pour continuer à produire du bon ?
Quand on pense qu'ils auraient pu se faire racheter par EA, on se dit qu'ils auraient pu tomber bien plus bas. Mais même, dans l'absolu, c'est pas trop mal; alors, il est où le problème ?
[^] # Re: Foo = bar
Posté par rakoo (site web personnel) . En réponse au journal Toutes vos base sont appartiens à nous. Évalué à 7.
Si c'est pour qu'il ne reste que les analogiques "à l'ancienne", t'aurais au moins pu prendre un meilleur exemple.
# Les réseaux sociaux c'est pour les teubés
Posté par rakoo (site web personnel) . En réponse au journal Humhub, (encore) un réseau social libre. Évalué à 10.
Faudrait arrêter de résumer "réseau social" a "Facebook tel qu'utilisé par certains mais moi je sais pas de toute façon j'utilise pas ça". Oui, il y en a qui utilisent Facebook ou Twitter comme ça. Non, ça ne veut pas dire que c'est pareil partout.
Est-ce qu'on parle des frites de la cantoche sur la LKML ? Non, et pourtant la LKML est un réseau social. Est-ce qu'on parle de tarte aux pommes sur LinuxFR ? Oui, même si on peut naïvement considérer que LinuxFR est mieux que Facebook. Est-ce que Humhub interdit de parler de frites de la cantoche ?
Je vois au moins un intérêt a Facebook: l'organisation d’évènements est vraiment simple. Non pas que c’était impossible avant, juste que les moyens de communication offerts par Facebook permettent de tout faire depuis une seule interface, a un seul endroit, sans avoir a rien installer, et qui tient tout le monde a jour en continu.
Maintenant, si nous autres adeptes des libertés individuelles voulons arrêter que tout le monde donne ses informations a un tiers et qu'ils gardent le contrôle sur leurs données, il faut qu'on comprenne les besoins pour fournir des alternatives, pas cracher sur les outils qu'on n'utilise même pas.
[^] # Re: Ne pas jeter le bébé avec l'eau du bain
Posté par rakoo (site web personnel) . En réponse au journal Question ouverte : Quel futur pour le web, au delà de HTTP.. Évalué à 2.
Par pure curiosité, qu'est-ce qui empêche de faire tourner un pubsub en tant que composant ? (Si vous avez d'autres canaux de discussions ça m'intéresse, j'ai envie que XMPP se répande un peu plus)
[^] # Re: incendies
Posté par rakoo (site web personnel) . En réponse au journal RuggedPOD première présentation publique de ce projet communautaire . Évalué à 3.
Est-ce que c'est vraiment de l'huile genre huile moteur ? J'imagine qu'il doit y avoir des liquides plus adaptés au transfert de chaleur.
[^] # Re: Ne pas jeter le bébé avec l'eau du bain
Posté par rakoo (site web personnel) . En réponse au journal Question ouverte : Quel futur pour le web, au delà de HTTP.. Évalué à 2.
J'ai lu il y a quelque jours (il faudrait que je retrouve la source) que si XMPP avance pas, c'est parce qu'il y a beaucoup de discussions mais personne pour prendre les rênes sur un projet en particulier et le faire avancer. C'est donc pas un problème technique.
À l'avenir je ne pense pas que XMPP disparaîtra, parce que c'est juste un protocole et qu'il est suffisamment (trop ?) documenté pour que quelqu'un l'implémente dans le langage du jour. Tox a son propre protocole mais est avant tout un ensemble d'applications qui sont faites pour communiquer ensemble.
# Fais chauffer Monique
Posté par rakoo (site web personnel) . En réponse au journal RuggedPOD première présentation publique de ce projet communautaire . Évalué à 3.
Minez du bitcoin, ou plutôt une altcoin dans laquelle les CPU ont encore du sens face aux GPU et ASIC (cf ici).
Vous pouvez aussi jouer au concours de kékettes (c'est le but) et faire un million de transactions par seconde sur la base de données Nosql du jour. Si des entreprises sont là, ça peut être vendeur (bon pour info ils ont réussi à atteindre le même nombre psychologique sur des instances EC2).
# Ça dépend
Posté par rakoo (site web personnel) . En réponse au journal Question ouverte : Quel futur pour le web, au delà de HTTP.. Évalué à 7.
Le web tel qu'on l'utilise aujourd'hui, c'est deux choses:
Une identité, qui permet d'accéder à des services: "Madame Soleil, quel temps fera-t-il demain ?"
Un transport, qui permet d'échanger du contenu: "Boulangère, donnez-moi les 2 plus belles miches que vous avez"
On a fait beaucoup de choses. Ce qui t'intéresse c'est d'abord et avant tout les miches de la boulangère; qu'elle les distribue dans sa boulangerie ou ailleurs, à partir du moment où tu es sûr qu'elles sont authentiques, on est bon. Pour prendre un exemple un peu plus parlant, que tu achètes ton pot de Nutella chez Casino ou chez Carrefour, c'est le même; peu importe qui le distribue.
Et bah bittorrent et consorts, c'est la même chose. Peu importe qui le distribue, tant que le contenu est le bon tout va bien. Le terme kivabien est Content Addressed Storage, qui montre bien que le contenu est plus important que la provenance. Tout ça c'est un problème plutôt résolu. Un projet intéressant à suivre dans ce domaine: ipfs. Il s'agit d'avoir un système global permettant de donner une URI à n'importe quelle donnée et de pouvoir ainsi y accéder quel que soit le serveur hébergeant les données, tout en étant bien plus souple que bittorrent… enfin ya plein d'idées, vaut mieux lire le papier et regarder la vidéo pour voir plus en détails.
D'ailleurs, BitWeb, ça me rappelle SyncNet, une idée vachement similaire (un navigateur qui utilise Bittorrent Sync pour transporter le contenu).
Par contre, la première utilisation que j'ai listée, les services, c'est plus difficile à décentraliser. Parce que contrairement à de simples octets que tu peux distribuer, là il s'agit de distribuer des fonctionnalités, donc en gros du code. Et il faut soi faire confiance à chaque nœud pour être sûr qu'il répond correctement, soi avoir un moyen de vérifier ce qu'il dit… ce qui voudrait dire qu'on a déjà la réponse, auquel cas on n'aurait même pas besoin de lui demander quoi que ce soit. M'enfin.
Il me semble que c'est la direction que veut prendre Ethereum , mais j'ai pas suivi de trop près, il faut creuser pour en savoir plus.
[^] # Re: critique constructive
Posté par rakoo (site web personnel) . En réponse au journal Le retour de la censure d'Etat : la loi Cazeneuve. Évalué à 10.
Petite parenthèse parce que cet argument est stupide: "Ça te dérangerait pas qu'on fasse ça ? Si ? Bon, alors il faut l'interdire".
Non. C'est même pas un argument ça. C'est pas parce que je fais (ou ne fais pas) quelque chose que tout le monde devrait faire pareil. Je (en tant que cible de ce genre de questions) ne suis pas le modèle à suivre pour la société, les lois se décident ensemble.
"Ça te dérangerait pas qu'on autorise le cannabis ? Si ? Bon, alors il faut l'interdire"
"Ça te dérangerait pas qu'on autorise le mariage homosexuel ? Si ? Bon, alors il faut l'interdire"
"Ça te dérangerait pas qu'on autorise Netflix en France et qu'on tue les pov' créateurs de contenu ? Si ? Bon, alors il faut l'interdire"
Ça fait juste appel aux mœurs et aux émotions, pas à la logique. Cette habitude doit disparaitre.
[^] # Re: critique constructive
Posté par rakoo (site web personnel) . En réponse au journal Le retour de la censure d'Etat : la loi Cazeneuve. Évalué à 4.
oh
Pour moi, en tout cas, il est nécessaire que cette autorité soit indépendante de l'éxécutif.
# Le problème c'est pas le protocole
Posté par rakoo (site web personnel) . En réponse au journal La recette miracle pour créer un réseau social décentralisé ?. Évalué à 10.
Le vrai problème, c'est l'interface utilisateur. Tu peux utiliser tous les protocoles que tu veux dans tous les sens, a partir du moment ou tu as besoin de deux applications différentes pour avoir les mêmes fonctionnalités c'est mort. Les protocoles c'est un problème de développeur, pas d'utilisateur. Alors comme on est tous des gens techniques qui voyons comment se passent les choses en coulisse, on se dit que "ça devrait marcher si on fait ça comme ça; pas besoin de ce mastodonte". Le problème c'est qu'en faisant ça on ne résout que la moitie du problème. C'est une erreur de se focaliser uniquement sur la technique.
Pour aller plus loin dans ton idée, fais nous donc:
Bonus si tout ça marche dans un navigateur.
Au final, tu vas plus te casser la tête qu'autre chose avec les emails… alors que tu peux utiliser un protocole beaucoup plus adapte pour ca. Mais ça ne changera rien au problème: L'interface utilisateur est la chose la plus importante a garder en tête.
[^] # Re: Free paie pour son insolence
Posté par rakoo (site web personnel) . En réponse au journal Orange attaque Free pour son offre de replay. Évalué à 10.
Je dirais même plus: le fait que Xavier Niel ait fait fortune dans le minitel rose n'est pas un problème, comme c'est trop souvent sous-entendu.
[^] # Re: Juste une question de point de vue
Posté par rakoo (site web personnel) . En réponse au journal Dominique Loiselet, Blue Coat : « généraliser le HTTPS va rendre la sécurité aveugle ». Évalué à 2.
Bien sur ça existe, et il en parle même dans l'article: le déchiffrement dégraderait les performances de 74%. C'est une des raisons qui fait qu'il est contre.
[^] # Re: btrfs
Posté par rakoo (site web personnel) . En réponse au journal Marque page sur l'unification possible des systèmes Linux. Évalué à 7.
Elle s'applique aux données binaires.
[^] # Re: Un blog sans RSS...
Posté par rakoo (site web personnel) . En réponse au journal Le Parisien attaque un blog pour contrefaçon, ou comment se tirer une balle dans le pied. Évalué à 5.
Il existe, mais passe par feedburner.
[^] # Re: Comme quoi les Chinois aiment Microsoft.
Posté par rakoo (site web personnel) . En réponse au journal Microsoft IIS dépasse Apache en terme de part de marché grâce à la Chine !. Évalué à 4.
Ou alors, peut être que c'est juste les gens de ta boite qui étaient nuls, rien a voir avec les chinois ?
[^] # Re: Peut être à rien pour toi
Posté par rakoo (site web personnel) . En réponse au journal Jabber ça sert à quoi pour un particulier ?. Évalué à 2.
J'utilise moi-même yaxim que je trouve beaucoup plus stable que Chatsecure, même s'il ne propose pas l'OTR.
Enfin, quand je dis utiliser, c'est qu'il est installé et prêt à l'emploi, mais ça va rarement plus loin…
[^] # Re: Suggestion de correction
Posté par rakoo (site web personnel) . En réponse au journal La crypto ça sert plus à rien de toute façon. Évalué à 2.
Ouais mais ça le faisait moins, sur le coup.
[^] # Re: Et si on passait à un truc genre DKIM ?
Posté par rakoo (site web personnel) . En réponse au journal Passer au HTTPS pour améliorer son PageRank. Évalué à 5.
Comme dit en dessous, c'est DANE. Le problème de DANE est qu'il part du principe que les enregistrements DNS arrivent intacts depuis le NS du domaine jusqu’à chez toi, ce qui est pour le moment hautement illusoire. Il faut utiliser DNSSEC (ou autres) pour acheminer les enregistrements, mains DNSSEC c'est une autre paire de manches a installer et maintenir.
Et bien justement, dnschain permet ça. Le principe est simple: il y a deja des specifications pour enregistrer ses noms de domaines et son identite dans Namecoin. Malheureseument Namecoin c'est son monde a part avec son client specialement fait pour. C'est la que dnschain fait le pont, puisqu'il permet d'acceder aux informations depuis des moyens connus: