désolé, j'avais commencé à répondre, puis j'ai fait autre chose à côté et quand je suis revenu sur ma réponse et l'ai publiée, je vois que tu t'es auto-répondu!
Donc voilà, c'est une question de définition. Avoir des automatismes permet de rendre l'implémentation plus facile. Si on se met à dire « ah oui mais "ceci" sert à X, mais parfois à Y en même temps, et des fois — mais c'est rare! — ça sert juste à Y mais pas à X », ça rend les choses compliqué. Donc nous, on a un automatisme: on identifie les diverses entités du réseau avec SASL. À partir de là, il nous faut choisir un mécanisme SASL pour identifier deux serveurs. Bah ça tombe bien, y a external fait justement pour ce genre de cas!
C'est un peu comme les fonctionnalités à négocier lors de la création d'une connexion. Avant dans la RFC3920, c'était un gros bordel. C'était en gros "ben on peut un peu envoyer des nouvelles fonctionnalités à tout moment, et des fois, on peut ne pas les envoyer, c'est un peu comme on veut hein, ici c'est à la bonne franquette!". Quand j'ai commencé à implémenter ça, je me suis dit que c'était nul. Y avait aucune fiabilité dans cette logique, que des cas particuliers. J'ai donc relevé le problème, on en a discuté et on a maintenant un beau diagramme d'état avec des explications précises de ce qu'il faut envoyer, et quand. Et maintenant c'est facile à implémenter.
Ce genre de design ne peut impliquer sur le long terme que bug et incompatibilité entre systèmes poppant de temps en temps.
Ben là pour SASL EXTERNAL, je n'étais pas là quand ça a été décidé donc je ne peux assurer que c'est la raison exacte pour laquelle c'est là, mais dans mon esprit, c'est la même chose. Ça permet un système logique et fiable.
Et donc si au final, SASL external et Dialback ont tout à voir. Ils ont tous les deux pour but d'identifier des serveurs quand ils communiquent ensemble. Sauf que la vieille méthode le faisait avec un système à part basé sur le DNS et donc était totalement bancal. Le nouveau est un mécanisme SASL (qui encapsule certes le protocol TLS) permettant d'homogénéiser l'identification en S2S et C2S: tout SASL, quel que soit le type d'identité.
En fait faut voir SASL EXTERNAL comme une encapsulation de code qui rend le code plus haut niveau bien plus lisible et donc exempt de bug. Si tu es développeur, tu comprendras de quoi je parle.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
vraiment désolé, je me suis emmêlé les pinceaux, et pourtant j'ai pas mal relu! Il s'agit de SASL external (c'est le protocole SASL qui gère l'identification). C'est le seul mécanisme décrit dans la RFC de base de SASL. Si on pouvait corriger la dépêche sur ce point svp!
En fait le principe de ce mécanisme est très simple. Il s'agit de dire "on s'est déjà identifié précédemment, tu te rappelles pas?". Cela implique une décision au niveau du protocole applicatif d'un autre moyen de s'identifier (SASL external est le plus générique des mécanismes et n'a aucun sens sans contexte). Dans le cas de XMPP, en S2S, nous nous reposons sur l'identification TLS.
Pour ceux qui ne savent pas comment marche TLS, il y a une partie vérification de l'identité d'un correspondant, avec les fameux certificats. Mais comme les certificats, c'est un concept difficile pour le grand public (= chiant, ils veulent juste un mot de passe, et basta! C'est parti mon kiki!), seul l'identité du serveur est vérifiée. C'est ce que fait aussi http avec https, sauf que nous, on rend ça obligatoire (ça veut pas dire que tous le font réellement malheureusement, mais ça veut dire qu'on dit aux développeurs de serveurs: si vous le faites pas, vous n'êtes pas une implémentation complète).
Or en S2S, c'est deux serveurs, donc normalement chacun doit avoir un certificat. Donc on est capable de créer une liaison TLS vérifiée des deux côtés. À partir de ce moment là, quand arrive le moment de l'identification, on peut dire "ah bah on fait, on se connaît déjà".
En gros donc, SASL external, pour le S2S XMPP, ça signifie juste (parce que c'est la définition qu'on a donnée) utiliser 2 certificats en TLS.
Et ça c'est autrement plus sécurisé que le protocole originel (à vrai dire, c'est ce qu'il y a de plus sécurisé dans ce genre de communications. Je parle bien sûr de notre contexte précis avec deux serveurs qui se connaissent pas outre mesure et qui ont cependant besoin de s'identifier et de crypter les communications, et aussi on fait avec les limites de TLS que nous connaissons tous ici car on arrive pas encore à trouver un meilleur système, du moins pas sur lequel tout le monde est d'accord).
Pour rappel, le Dialback, le principe c'était juste qu'on identifiait le serveur qui nous appelait en créant une second connexion dans l'autre sens et où on dit "c'est bien toi qui m'a appelé à l'instant et qui m'a dit ça?", ce qui rend très facile de se faire passer pour un autre serveur avec du DNS poisoning ou d'autres méthodes similaires.
NOTE: le SASL external peut théoriquement aussi être utilisé en C2S avec une clé cliente. Mais je sais pas si beaucoup de serveurs utilisent un tel système (peut-être sur des réseaux d'entreprises où on veut se passer de mot de passe?).
Je crois que c'est aussi utilisé par Google en C2S lorsqu'on est dans l'interface web gmail. Dans ce cas là, le SASL external, c'est "on s'est identifié quand on s'est identifié à l'email, pas la peine de le refaire pour XMPP!". Comme je disais, tout est une question de définition par le protocole applicatif.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Bien que n'ayant jamais testé ton projet, j'avais vu tes divers journaux que tu avais fait dessus, et en fait tu m'avais presque énervé, parce que t'as plein d'idées très similaires aux miennes. ;-)
Quoiqu'il en soit, si ton projet est suffisamment avancé pour être utilisable (parce qu'y a quand même une sélection, on ne peut laisser n'importe quel projet inexistant prendre la place de projet solides) et que tu souhaites aller encore plus loin, tu peux probablement proposer une idée (ou plusieurs même) de projet impliquant SaT, pour lesquels tu pourrais être mentor. Donc SaT pourrait participer au Google Summer of Code sous la tutelle de la XSF. Jette donc un œil au lien donné plus haut.
Bonne continuation!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
comme je disais dans le ticket, même programmé avec les pieds, je suis persuadé que ce sera déjà mieux que Google (qui est vraiment super mauvais pour Linuxfr dans mon expérience, pas vous?), parce que nous avons accès à la structure et logique interne du site.
À partir de là, ça signifie qu'on peut commencer par avoir un moteur de recherche basique fait en 30 minutes (genre on cherche juste la liste des mots en se limitant aux tags, au titre, puis au texte, et enfin on rajoute un bonus aux tickets récents, avec cet ordre de poids: ce sera déjà une grosse amélioration et ça fait quelques lignes de code pour la logique), puis progressivement l'améliorer avec le temps (affiner les poids, rajouter des éléments, créer un systèmes d'options à sélectionner, voire un jour tenter l'expérience d'un moteur de recherche avec apprentissage).
Notez que je suis prêt à aider, mais il me faudrait un environnement de développement déjà prêt. Mon expérience désastreuse lors du concours pour le nouveau site m'a décidé à ne plus essayer d'installer cela moi-même.
Enfin pour les pubs, je comprends. Oui l'idée de tous les ans proposer une campagne de don est intéressante en switchant sur Google search en même temps, et tant que la campagne n'est pas bouclée, semble bien. Aussi n'y a-t-il pas des entreprises qui pourraient sponsoriser Linuxfr (sous et/ou matériel, je crois que les deux se sont déjà faits pour l'assoce, non?)? Je suis sûr que c'est facile, surtout si c'est pas grand chose, parce que vous représentez la source numéro 1 d'informations relatives à Linux et au Libre en France.
Peut-on avoir un ordre de grandeur sur la somme représentée par ces pubs? Quand vous dites que c'est pas grand chose, c'est quoi? 50 euros? 100? 1000?
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
cette solution permet-elle de restreindre les droits utilisateurs simples (1)? Par exemple si je veux lancer un programme en m'assurant que ce problème ne puisse pas du tout lire dans le système de fichier (même les fichiers appartenant à l'utilisateur qui fait tourner le programme), est-ce possible?
Ou bien cela permet simplement de donner quelques droits supplémentaires à un utilisateur (qui sont normalement réservés à root), mais pas tous (2)?
Je m'intéresse justement en ce moment à faire la première chose (1) en particulier. Quelles sont les solutions existantes (Capsicum ou autre) capables de faire ce genre de restrictions sous Linux?
Je suis intéressé par tout lien sur la chose ou points de départ pour une recherche. En particulier je souhaite ne pas avoir à modifier un kernel (donc en fait Capsicum, qui m'intéresse dans le concept et peut-être dans l'avenir, n'est cependant pas intéressant pour moi à court terme tant que ce n'est pas un élément de base de Linux).
Merci pour ce sujet intéressant en tous cas. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Oui tout à fait. Mon exemple était simpliste à l'extrême pour être le plus explicite possible.
En fait, windu2b, ce que tu proposes est souvent fait entre versions mineures. Dans ce genre de cas, les développeurs vont définir une nouvelle fonction avec une meilleure interface et vont flagguer l'ancienne comme "dépréciée", ce qui (si le langage le permet) va en général générer des warnings à la compilation sans pour autant provoquer de vraie erreur.
Mais parfois c'est plus compliqué. Comme kaouete le dit, il peut y avoir des problèmes de "structures internes". De manière générale, les problèmes compliqués concernent l'architecture globale de l'API qui est trop complexe. Quand on s'en aperçoit après coup, cela implique que le problème n'est pas juste de changer une ou deux fonctions, mais qu'il faudrait changer l'API complète plus en profondeur (plus ou moins). C'est donc compliqué quand le problème vient des choix de "design" originel.
Parfois vous ne pouvez même pas imaginer les choix étranges d'architectures de certaines librairies/programmes! Pour OpenGL en particulier, je ne sais pas, ceci dit.
Ensuite on peut presque toujours faire des fonctions qui appellent d'autres (encapsulation) pour avoir une interface plus agréable. On appelle cela une "abstraction" (on prend quelque chose de concret, par exemple "allumer un pixel à l'écran" pour en faire un concept plus abstrait comme "dessiner un point", donc plus facile à appréhender par l'esprit humain). Mais parfois on veut se limiter pour des raisons de performances. En effet à chaque fois qu'on appelle une fonction, l'ordinateur va la chercher dans la mémoire. Ensuite quand la fonction finit, on doit rechercher la fonction appelante et lui donner la réponse. Tous ces "allers et retours" en mémoire prennent du temps. On appelle cela l'overhead. C'est particulièrement important pour les APIs de bas niveau qu'on veut les plus optimisées possibles (en général on se "relâche" en montant les niveaux, ce qui se voit par le fait que les API bas niveaux sont souvent très concrêtes mais très optimisées alors que le haut niveau est très abstrait avec beaucoup d'overhead).
Donc si on se met à faire massivement ce genre de choses, c'est probablement comme on disait qu'il y a un problème dans l'architecture et que c'est à ce niveau qu'il faudrait revoir l'API.
Enfin pour répondre à Shuba plus haut. C'est vrai que comme OpenGL/DirectX sont fait pour s'interfacer avec du matériel, j'imagine que certaines choses seront limitées si l'API (donc le matériel) ne définit pas certaines fonctionalités.
Ensuite en ce qui concerne les shaders, l'article cite le fait que malgré qu'il n'y avait pas ça dans OpenGL à une époque, cela avait ajouté par extension avant que ce soit dans l'API. En outre, ça ne semble pas gêner Carmack plus que cela, et il ne parle pas de différence de performance. Donc cet exemple me semblait pertinent.
Ensuite comme je disais, je ne connais pas le sujet de la 3D en particulier. Et tu as sans doute raison.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
je ne fais pas de 3D, mais je suis développeur. Et donc de ce que je comprends des termes employés, notez tout de même que Carmack ne semble pas critiquer la qualité finale d'OpenGL, mais son API seulement, ce qui pour nous programmeurs peut être synonyme de "simplicité d'utilisation". Pour exprimer cela simplement, voici une analyse du discours:
I actually think that Direct3D is a rather better API today.
imaginez que pour dessiner un cube de côté l, une bonne API a une fonction cube(l) alors qu'une moins bonne aurait la fonction make_a_regular_hexahedron(d) où d est la diagonale et non le côté. C'est chiant à développer car le nom de la fonction est plus long et mal choisi (un regular hexahedron est un cube, le nom n'est pas clair). Aussi bien que l'on sache sache calculer sans problème le côté en fonction de la diagonale et vis-versa, "en général" les gens vont vouloir dessiner un cube dont il connaisse le côté, non la diagonale. Donc la seconde fonction demandera la plupart du temps une ligne de calcul supplémentaire dans le code: paramètre mal choisi.
C'est cela que l'on appelle une mauvaise API (Interface!) en général.
Microsoft had the courage to continue making significant incompatible changes to improve the API, while OpenGL has been held back by compatibility concerns
De même quand il parle de compatibilité, il entend donc une pratique courante. Plus tard, on se rend compte que notre fonction make_a_regular_hexahedron est vraiment chiante à utiliser. On aimerait bien changer le nom et le type de paramètre. Mais voilà, plein de logiciels l'utilisent et si on change cela, ça va "casser" la compatibilité ascendante => les développeurs devront revoir leur code et changer tous les endroits où ils créaient un cube avant s'ils veulent utiliser la nouvelle API.
C'est quelque chose que les bonnes APIs refusent de faire de manière générale sauf en passant une version majeure où ils se permettent de casser plein de choses. C'est un choix accepté, en particulier dans le logiciel Libre où ce serait très dur de suivre les évolutions de toutes les librairies et on essaie de se fier aux numéros de version.
Direct3D handles multi-threading better, and newer versions manage state better.
Cela confirme assez. Il dit bien que c'est mieux géré (donc plus simple à utiliser ou mettre en œuvre), pas que c'est plus efficace.
Maintenant quand il parle de nouvelles fonctionnalités, cela implique surtout que l'API Direct3D a intégré des facilités dans son interface. Supposons qu'aucune des API ne savait faire des boules. Puis notre bonne API se dit: tiens, je vais intégrer un algorithme pour faire une boule et j'encapsule ça dans une fonction que j'appelerai ball(r). On peut maintenant faire des boules en une ligne de code.
De son côté la mauvaise API n'a pas la fonction encore. Cela ne signifie pas que les développeurs ne peuvent pas faire de boule. Simplement ils sont obligés de calculer eux même ses limites, puis les remplir (avec d'autres types d'objets que l'API sait faire). C'est donc chiant.
C'est en gros, ce qu'ils disent dans l'article là:
While newer versions of OpenGL have kept up-to-date with some of the features found in DirectX, including DirectX 10's geometry shader, they usually have to be implemented via extensions, rather than the main API.
Enfin tout cela est confirmé par:
we wouldn’t get any huge benefits by making the switch, so I can’t work up much enthusiasm for cleaning it out of our codebase.
où Carmack explique que maintenant ils utilisent OpenGL et que s'ils passaient à DirectX ça ferait beaucoup de boulot (même si ce dernier est visiblement plus facile à utiliser, leur base de code depuis les années doit être énorme), pour au final peu de bénéfice. Les bénéfices évidents avec une meilleure API: plus facile à maintenir (débugguer, etc.). Mais comme ils ont déjà une base très solide, ils n'y touchent sûrement plus autant qu'avant. Donc ce bénéfice est au final minime comparé au travail colossal de tout changer pour Direct3D. Quant à l'utilisateur final, il n'y verra probablement aucune différence car les deux APIs sont aussi performantes ou proches à mon avis. En effet si cela impliquait vraiment une différence pour l'utilisateur (plus fluide et/ou plus beau), alors ce serait vraiment un énorme bénéfice, surtout pour le domaine du shoot 3d, fer de lance de cette entreprise où le graphisme règne en maître. Si ça ne l'est pas, c'est que la seule différence est probablement pour le développement.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
en fait les designers ont de la chance. Pour eux, c'était "facile" de participer (j'entends par là qu'ils n'ont rien à installer: ils codent, et testent direct sur le site alpha). Pour les développeurs "cœur", on devait se taper toute l'installation du site web (ruby, rails, la dizaine de module, le serveur web, etc.), avec des problèmes de version, etc.
J'ai perdu des heures dessus. Puis un autre développeur sympa a monté une image virtuelle et on nous l'a gentiment fournie. Alors moi, je cherche un logiciel de virtualisation pour cette image. Mais... erreur: la version du logiciel fournie dans ma vieille distri n'était pas compatible avec l'image. Je vais sur le site du logiciel, je prends les sources du logiciel, je compile, je l'installe. Je lance... cette fois la version est bonne, ça ne refuse pas l'image, mais... le serveur virtuel ne veut pas démarrer. J'ai des erreurs. Puis au final j'en ai eu marre et j'ai arrêté.
J'ai passé je-ne-sais-combien d'heures rien que pour essayer de monter mon environnement de développement avant d'abandonner (peut-être même plus que ça m'aurait pris pour coder cette killer-feature que je prévoyais). Je ne sais si c'est la raison pour les autres (je crois qu'y en a eu d'autres, il me semble avoir vu mention de cela), mais c'est la mienne.
Il faut dire aussi: je suis développeur, pas admin. Normalement quand je bosse sur un environnement complexe déjà en place (et linuxfr en est un), on a des admins qui se chargent de tout nous mettre en place. Non pas que je ne peux pas le faire moi-même, mais:
1/ ça me fait grave chier. Je déteste administrer. J'aime coder.
2/ ça me prendrait beaucoup plus de temps que l'admin qui connait bien son système.
3/ étant donné tous les problèmes que j'ai rencontrés, je me dis maintenant qu'il aurait fallu une doc bien plus précise que celle qu'on a eu malheureusement pour remonter tout cet environnement (dans un temps raisonnable, j'entends).
4/ ça tombe mal, ce mois en particulier, j'avais encore moins de temps que le mois d'avant et d'après.
Admins de Linuxfr, ne prenez pas cette critique mal surtout. Je n'ai aucun ressentiment contre vous. Donc ce n'est que de la critique que j'espère constructive, et sans aucune amertume. Je voulais juste participer au concours parce que je trouvais cela marrant et qu'y avait justement une nouvelle fonctionnalité html5 avec laquelle j'aurais voulu m'amuser un peu. Le prix à gagner ne valait pas ce développement donc ce n'était pas vraiment dans le but de le gagner de toutes façons.
Mais je suis sûr que ça prendrait juste 20 mins à un admin pro qui connait l'environnement Linuxfr de monter un environnement virtuel (par participant) et de fournir un accès ssh au participant dessus. Donc la prochaine fois que vous organisez un tel concours, je conseillerais de préparer qqch comme ça.
:-)
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
dois-je comprendre de ta réponse que tu penses que je trouve que XMPP est bon pour plein de choses parce que je souhaite ensuite me vendre dans la foulée comme consultant ou quelque chose du genre? Donc en gros que même si je ne croyais pas en XMPP, je le "vendrais" tout de même, pour ensuite pouvoir me vendre moi-même?
Alors outre le fait que quelqu'un pourrait trouver cela insultant (mais t'as de la chance, je ne suis pas susceptible), je tiens juste à préciser que je ne suis pas "consultant XMPP" (ni consultant tout court), et que je ne travaille (j'entends ici "travailler" dans le sens où je gagne ma vie) pas dans le milieu XMPP (bien que ça peut m'intéresser bien évidemment, mais je ne cherche pas plus que ça).
Ma "seule" relation avec XMPP est que j'y "travaille" (cette fois dans le sens "j'y passe du temps") sur mon temps libre, à la fois en développement perso de logiciel Libre, et aussi sur l'amélioration des RFCs IETF associées et des XEPs.
Donc si je promeus XMPP, c'est vraiment parce que j'y crois, et non pas pour des raisons vénales.
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
j'avais fait un plugin pour Firefox (doit y avoir 2 ans, waw le temps passe!) qui stocke justement les marques pages sur un nœud pubsub de son compte Jabber (cf. XEP-0048 bien que celle-ci mérite une bonne réécriture, que je prévoyais également en même temps de compléter le plugin). Mais ce plugin est resté à un stade très expérimental (il est très mal intégré à Firefox, pour l'instant c'est tout juste un "proof of concept" basique, fonctionnel mais pas du tout utilisable avec plaisir) parce que je n'ai jamais pris le temps d'aller plus loin, bien que j'ai encore envie d'y revenir dès que je le veux.
En gros, les marques pages sont stockées sur son serveur XMPP (qui est donc décentralisé, on peut même avoir son propre serveur si on veut contrôle total), et est privé. Mais PubSub étant ce qu'il est avec son système de droit, on doit aussi pouvoir avoir des nœuds publiques ou semi-publiques (comme je dis plus haut: on choisit à qui on partage au cas par cas, ou bien par groupe de contact, ou à tout le monde, etc.) pour partager ses marques pages, de sorte que si quelqu'un change ses marques pages publiques et que j'y suis inscrit, la liste serait automatiquement mise à jour dans mon navigateur. Etc.
Aussi vous l'aurez compris, je ne suis pas d'accord avec les gens plus haut qui pensent que XMPP n'est pas du tout adapté pour ce genre de choses.
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
P.S.: les avatars PEP ont un autre gros avantage (en plus de garantir la vie privée de certains s'ils ne souhaitent pas rendre leur avatar publique, ce qui est leur droit, non?), c'est que ton bot peut (il "peut", mais n'est pas obligé et peut se contenter de demander l'avatar une seule fois) aussi s'inscrire au nœud PEP publique de l'avatar (ce n'est pas une inscription à la présence de l'utilisateur, il ne devient pas contact), de sorte qu'à chaque fois que le nœud est mis à jour (nouvel avatar), il envoie l'information à tous les inscrits. Donc lors de sa prochaine connexion, ton bot peut mettre à jour l'avatar de l'utilisateur sur ton site web.
C'est même beaucoup mieux qu'une inscription à la présence puisque c'est la seule information dont ton bot a besoin. Avec une inscription présence, cela génère plein d'information inutile sur le réseau (la présence elle-même déjà, que ton bot envoie et qu'il reçoit de tous les contacts, puis toute information relative, comme des "découvertes" de fonctionnalités faites par les contacts du bot à celui-ci, ou bien la liste de leur propre fonctionnalité qu'ils envoient potentiellement pro-activement, etc.).
Là, aucun échange superflu, uniquement la nouvelle information nécessaire, SI et QUAND l'avatar change, et seulement à ce moment là.
C'est de là que vient le nom PubSub: "Publish-Subscribe" (Publier-S'inscrire).
Perso j'irais avec une implémentation là dessus si j'étais toi (mais je suis pas sûr que ce soit l'implémentation choisie par la plupart des clients à l'heure actuelle).
Enfin bon vcard marche aussi parfaitement pour ton use case, seulement il n'y aura pas de mise à jour pro-active (si jamais tu veux savoir si un avatar est mis à jour et que tu n'as pas d'inscription présence, tu dois redemander).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
tout dépend de comment sont implémentés les avatars actuellement.
Il existe pour l'instant 3 (je pense pas plus, mais qui sait?.. on a tellement de doublons) spécifications pour les avatars XMPP:
- ceux basés sur une requête spécifique (IQ-based, XEP-0008), historiquement. Mais cette méthode n'est plus considérée comme valide et obsolète (ce qui ne signifie pas qu'il n'y a pas quelques implémentations qui l'utilisent encore peut-être).
Ta demande est-être possible avec cette XEP mais je ne creuse pas, cette spéc est très limitée et inintéressante.
- ceux basés sur les vcards (XEP-0153), méthode très répandue et la spéc est considéré comme active (la seule spéc avatar active), bien qu'historique également (donc potentiellement supplantable).
Cette spéc te permet déjà de faire ce que tu souhaites puisque la spéc vcard (XEP-0054) précise bien dans les considérations de sécurité que la vcard est visible par le monde entier. Il n'y a pas de notion de droits sur une vcard donc ton bot XMPP peut demander la vcard de n'importe qui et *n'a pas besoin de demander à être inscrit dans ses contacts!*
- ceux basés sur PEP, donc PubSub (XEP-0084). Son statut est en "brouillon", mais c'est le seul considéré comme en état de standardisation. En gros ça se bagarre avec la XEP vcard pour savoir qui l'emporte.
Là aussi c'est possible puisque PubSub a un système de droits élaborés, contrairement à vcard qui est "visible par le monde entier". Donc un utilisateur peut théoriquement décider à qui il montre ses infos publiés au cas par cas (ça peut être seulement à ses contacts, voire seulement à un groupe de contacts, par une liste de JID, à tout le monde, ou même sur demande que l'utilisateur reçoit puis valide ou refuse ensuite). Évidemment les clients gèrent très mal, voire pas du tout pour tous ceux que j'ai vu, ce genre de droits sur les nœuds Pubsub ou PEP, et il ne demandent jamais ce genre d'infos. Donc cela dépend probablement de l'implémentation du client et du serveur, cad quels droits par défaut ils mettent en créant un nœud. Étant donné ce que j'avais vu à l'époque de tests sur PubSub (mais mes derniers tests remontent bien à un an ou plus maintenant), y a de fortes chances que les droits par défaut soient souvent publiques, malheureusement (je dis "malheureusement" de manière générale, par contre le nœud avatar, je pense que "publique" peut être une bonne valeur par défaut, mais il faudrait quand même que l'utilisateur puisse changer cette valeur s'il le souhaite).
Mais heureusement par contre pour toi qui peut sûrement récupérer les avatar PEP de cette façon.
Pour conclure, je pense que tu n'auras pas de problème pour faire ce que tu veux. Par contre tu peux voir que les avatars Jabber sont un peu un bordel pour l'instant et que théoriquement, un même utilisateur pourrait avoir 3 avatars différents selon la technologie choisie pour la récupérer.
Bye.
Jehan
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Cool. Merci à vous deux. J'ai pas eu de linuxfriens dans mon public (enfin je crois, ou bien trop timide pour dire bonjour) mais ,ca s'est bien pass'e en tous cas. À une prochaine peut-etre donc. Je vais voyager encore mais je reviendrai peut-etre vivre au Japon dans quelques mois, donc si je refais un concert... j'en ferai à nouveau part ici.
Bonne journ'ee!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
donc si je comprends bien ce que tu me dis, en gros il ne *faut pas* refuser un email si le FROM ne correspond pas à la vraie adresse d'envoi ou en vérifiant l'enregistrement SPF du FROM?
Donc je suis condamné à recevoir des faux emails d'arnaque de mon propre domaine en gros (ou encore des faux emails de mes comptes Facebook/Twitter/le truc hype du moment, alors que je n'ai aucun compte chez les moindre de ces services), lesquels passent le filtre SPF car celui-ci ne se base pas sur l'adresse du FROM mais sur la vraie adresse d'envoi.
Alors bien sûr, ces emails ne passent en général pas le filtre spam ensuite, mais j'aimerais tout de même pouvoir les refuser avant tellement ce sont des faux évidents selon moi (mon domaine, donc mon adresse email, datant de nombreuses années, je reçois plus d'une centaine de spams par jour, aux alentours de 150 même. Et je parle juste de mon compte, pas du serveur).
C'est quand même vraiment un protocole ridicule le protocol email.
Si quelqu'un a des suggestions, je suis tous yeux.
Merci pour la réponse et pour d'éventuelles autres réponses.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
le lendemain de l'annonce de libération du VP8, quelqu'un a posté un patch sur la mailing list de développement de mplayer/mencoder, pour le support de VP8/WebM.
Donc oui, c'est actuellement supporté dans la version de développement (dans le dépôt de source donc), bien que je n'ai pas testé personnellement.
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
non si tu lis le post de la fondation, ou mon explication plus haut, tu verrais que le tinyurl pointe sur le site Jira lui-même. Il n'y a pas d'autre machine impliquée ici. Le tinyurl très probablement ne devait servir qu'à cacher la taille de l'url (ainsi que le fait qu'elle contienne un script pour ceux qui l'auraient lu). Mais le domaine de l'url n'aurait rien eu de suspicieux par contre.
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Donc en ce cas, la solution 3/ est à bânir. Le navigateur peut juste filtrer par les méthodes 1/ et 2/ (même si le script est intégré dans la page "graphiquement", il n'est pas exécuté, juste affiché, donc le navigateur peut faire la différence et la méthode 2/ ne bloque donc pas ce type d'utilisation).
Mais je vois d'autres problèmes.
Par exemple, imaginons qu'on veuille justement désactiver, mais partiellement seulement, certaines parties d'un script inclus dans une page et que cela permette d'en changer le sens (et obtenir même un usage néfaste), on pourrait alors:
- inclure dans une url une variable contenant la copie de la partie du script à virer (que l'on sait sera incluse dans la page retournée).
- Le serveur lui en réalité ne connaît pas cette variable bidon, n'en prendra pas compte et retournera la page normalement.
- Le navigateur ne sait pas ce que fait ou non le serveur en interne, bien évidemment, par contre il reconnaît que le bout de script qu'il a vu dans l'url se retrouve dans la page comme code à exécuter. Il en conclut "intelligemment" qu'il s'agit sûrement d'une faille de cross scripting et que ce code a été injecté (alors qu'il n'en est rien, il n'y a aucune corrélation réelle entre l'url et ce script).
- Le navigateur retire ce bout de script, mais s'il exécute le reste, ça peut devenir dangereux (si ça a été pensé pour l'être).
Donc ici on a généré une attaque en faisant croire au système de protection qu'il y avait une autre attaque! Ainsi il faut faire très gaffe aussi avec ce genre de sécurité intelligente qui peuvent elle-même créer des failles là où il n'y en avait pas auparavant.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Psychofox, justement le script ne vient pas d'une autre machine. Je sais que l'explication est assez technique donc difficile à comprendre mais c'est ce que j'explique dans mon message plus haut.
Le script est injecté dans la page (par une url dans ce cas, mais d'autres méthodes sont envisageables), de sorte qu'il est tout à fait envisageable que le serveur lui-même sert la page avec le script inclus dedans. Là encore, les deux sont possibles. On pourrait aussi imaginer que le script est inséré côté client, par exemple si les variables url sont parsées par du javascript, qui à son tour exécute des scripts qui y sont passés. Mais le cas où l'url est parsée côté serveur et donc que ce dernier sert une page avec le script dedans est tout à fait probable. Dans l'attaque en question, rien n'est précisé sur la méthode exacte du cross scripting (encore une fois, ils attendent probablement que la faille soit comblée).
Par conséquent, d'un point de vue purement basique techniquement, le script ne vient pas d'une autre machine: il vient du serveur.
Cependant il est clair que toute méthode impliquant un script (donc une exécution sur machine) passable par url est mauvaise par design (franchement! Non?). Et comme je soulignais, le navigateur peut sûrement détecter ce genre d'anomalie, mais ce n'est pas du tout un truc évident, car de manière générale, il n'y a pas de bug technique, mais un "bug humain". On demande au navigateur là de repérer et protéger une grosse erreur du développeur (= accepter du code exécutable dans l'url sans protection particulière, l'équivalent d'utiliser la fonction "system" dans un programme sans aucune vérification, et pour une exécution de code très sensible). Néanmoins comme dans ce cas, il y a peu de chances que ça soit bien utilisé, on peut essayer...
Perso, je vois ca ainsi:
1/ si le script est intégré côté client, on peut repérer ça facilement et donc bloquer un tel script.
2/ sinon (intégré côté serveur), on peut essayer de repérer des familiarités entre les scripts intégrés dans la page et ce qui est passé en url. C'est apparemment ce que fait IE8beta2 par exemple (lien très intéressant donné par PasBill PasGate ci-dessous).
3/ de manière générale et plus simple, je me demande s'il ne faut pas virer de l'url tout ce qui ressemble à un script avant même de faire la requête au serveur. Comme je disais, je ne vois pas de bon usage, et même si le script n'est pas intégré dans la page en réponse, rien ne dit qu'il n'est pas exécuté sur le serveur lui-même et peut donc s'avérer très dangereux là-bas.
Néanmoins cela pose la question: jusqu'où «l'intelligence» (au sens IA) du navigateur doit aller pour protéger les erreurs de développement? Et qui sait si — en faisant cela — on ne bloque pas aussi des requêtes légitimes (contre toute attente, il existe peut-être de bons usages, même si je ne les vois pas dans l'immédiat, avec des serveurs qui vérifient et traitent le script au préalable par exemple pour en faire quelque chose d'adéquat, ou le supprimer si dangereux).
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
ce n'est pas du phishing. Le lien ne redirigeait pas vers un autre serveur (un serveur des attaquants ou déjà corrompu par ces derniers par exemple). Cela redirigeait vers le serveur Apache lui-même. Il y a apparemment une faille de cross scripting (script croisé serait une trad adéquate) dans le logiciel Jira qui — à une certaine page — accepte donc un script externe en url (le post n'en dit pas plus sur ce point, mais j'imagine car ils l'ont rapporté à Atlassian et la faille exacte ne sera divulguée qu'une fois corrigée).
En gros, pour expliquer, dans l'url même, ils ont écrit un script (dans une quelconque variable probablement) — ce pourquoi le tinyurl était notamment intéressant pour cacher la longueur de l'url fort probablement, ainsi que son contenu évidemment aussi bien que, redirigeant sur Jira, ça puisse ne pas éveiller de soupçon sur un rapide coup d'œil — puis ce script a donc été intégré dans la page web comme s'il faisait partie normale du site, et donc le script avait accès au cookie de session. Le navigateur n'a donc aucune raison de refuser à ce script d'accéder au cookie de session correspondant à l'url du bugtracker Apache a priori. Ce pourquoi je pense que même Firefox ferait l'erreur. D'ailleurs les gars de la fondation Apache ne donnent pas de détails sur les navigateurs touchés ou non, donc je pense que tous le sont.
Le seul truc que peut faire le navigateur, c'est détecter un comportement étrange et peut-être générer un avertissement, j'imagine. En effet, comme le script est côté client, le navigateur voit peut-être qu'il est intégré de l'url (mais ce n'est pas sûr, ça doit dépendre comment il est intégré, si l'intégration est en PHP, elle est faite par le serveur à partir de l'url).
Enfin bon... le bug vient de Jira, pas du navigateur en l'occurrence (même si ces derniers peuvent peut-être être améliorés pour détecter des comportements étranges et des failles potentielles).
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
J'aime pas faire des commentaires pour rien dire, mais pour une fois j'avais quand même envie de dire que j'aime bien aussi (par conséquent, m'avoir fait répondre quelque chose qui sert à rien, c'est donc pas rien). J'ai même ri sur la fin.
Et moi je dis, pour faire écho à une demande d'un autre commentaire plus haut: non pas de wiki. Je veux lire ton histoire à toi. Après, c'est du CC-by. Si les gens veulent modifier après coup, libre à eux, mais perso dans un premier temps, je préférerai ta version brute à toi. Ensuite c'est toi qui choisis, évidemment. :-)
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
si je résume, le problème principal pour leur participation aux projets de Logiciels Libres dédiés à l'édition sonore, ainsi que davantage d'implication dans la production sonore est que ce n'est pas leur but principal. Il s'agit après tout de la Blender Foundation, et je comprends d'ailleurs tout à fait qu'ils décident de s'impliquer principalement dans le graphisme, mais c'est dommage. Je le dis en tant que personne intéressée par ces projets, et en tant que musicien.
Cependant il eût probablement été possible de monter une équipe pour le son, avec des musiciens, et des développeurs pour améliorer les programmes choisis. Évidemment cela demande également une levée de fonds, de même que fait la fondation Blender pour la partie graphisme. C'est donc probablement trop tard pour le projet en cours (hormis faire rétroactivement, après la vente, comme proposé, mais ce n'est pas pareil). Néanmoins pour les futurs projets, cela peut être très intéressant. Je pense qu'il peut valoir le coup de monter un dossier, de le leur présenter et de chercher déjà des sponsors (associé aux projets Blender qui devient de plus en plus gros, cela devrait se faire assez bien) pour les futurs films/jeux. Le but serait de pouvoir monter une équipe de développeurs (pour les programmes sons choisis)/compositeurs/musiciens/ingénieur du son rémunérés le temps du projet (comme pour la partie graphisme actuellement donc), d'améliorer l'ensemble des outils audio choisis, et de proposer un travail de qualité faits avec des outils Libres (pour démontrer leur qualité et l'état de l'art), sous licence Libre, par exemple CC-by comme pour la partie vidéo (pour le plaisir de faire de la musique Libre).
Si cela intéresse des gens, on peut monter un tel projet et le proposer à la Blender Foundation. Je pense qu'il peut être bien de se regrouper. N'hésitez pas à me contacter.
Pour le présent fim, où je pense qu'il est un peu tard pour envisager un projet de cette ampleur, on peut déjà travailler avec l'état de l'art actuel dans le traitement de son. J'ai cependant quelques questions:
- Où a-t-on accès aux images? Sur le blog, on a à peine un concept art en video clip, pas de scénario (juste un concept: une fille et un dragon... Bon les films Blender font pas dans l'original jusque là ;-), et d'ailleurs c'est normal puisqu'ils commencent à peine la pré-prod.
J'ai donc l'impression qu'il faut travailler sur cette base très vague pour l'instant, non? Ou y a des données plus avancées, mais un peu plus cachées?
- Je suis intéressé par ce projet, mais je suis actuellement au Japon, tout juste arrivé, avec un visa un an. Je ne connais pas encore vraiment de musicien ici. Je suis pour ma part harmoniciste, suffisamment bon (j'aime pas dire ça, mais bon si je dis "je suis mauvais" pour faire le modeste à deux sous, y a pas d'intérêt) et je ne connais pas bien les outils actuels (j'ai essayé Ardour et compagnie, très sympa, mais très simplement. Je ne suis pas du tout calé dans ces produits pour être efficace). En l'absence donc d'une équipe cohérente et en un même lieu physique comme pour le graphisme (cf. projet de plus grosse envergure pour les prochains projets Blender), quelles sont les possibilités de créer un groupe de musicien à distance? Et si oui y a-t-il des personnes intéressés? Je suis fortement intéressé et j'ai un peu de temps à l'heure actuelle, pour jouer (et peut-être pour composer).
- Avez-vous des contacts de musiciens intéressés par le Libre ou de studios qui utilisent des outils Libres (on en a quelques un en France a priori) au Japon? Cela m'intéresserait. :-)
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Tests intéressants. Pour ma part, le problème qui me saute aux yeux est tout de même de tout baser sur un unique compilateur. Je pense à cette liste, sûrement non exhaustive, d'inconvénients:
- Tu as testé sur quelques exemples, mais comme tu le dis, à ce que je comprends, llvm est expérimental. Peut-être que sur des bouts de code utilisant des fonctionnalités de langage très particulières, llvm peut montrer des limites? Cela n'est qu'une hypothèse basé sur le fait que llvm est apparemment expérimental (cf tes dires) et que les dévs eux-même semblent surtout destiner ce compilo/VM à des chercheurs (cf. section "LLVM Audience" de la page "Features" du site, où la plupart des lignes désignent chercheurs ou développeurs, hormis la dernière pour un certain type d'utilisateurs finaux).
- Et si le développement de LLVM s'arrête? Ton idée est entièrement dépendante de ce produit. Tout autre gestionnaire de paquet marche avec n'importe quel compilateur.
- Apparemment LLVM ne supporte vraiment que C et C++ pour l'instant (et qques autres en développement). C'est beaucoup étant donné que ce sont les langages les plus utilisés, historiquement. Mais on sait que de nos jours, il y a foultitude plus de langages et que ces autres langages sont de plus en plus utilisés, étant donné qu'on considère de plus en plus le gain de temps apporté par les langages de haut niveau.
Une "solution" serait que les programmes utilisant un langage non supportés seraient en binaire dans tes repositories, et ceux en C/C++ en bytecode. Néanmoins je ne connais pas les statistiques sur le pourcentage de programme non C/C++, mais cela ne m'étonnerait pas que ce soit plus de la moitié des programmes existants. Et dans ce cas, on réduit énormément les intérêts principaux de ton gestionnaire de paquet et de ses dépôts de programme très petits.
Évidemment si à l'avenir, LLVM se met à supporter tous les langages (boulot titanesque), cela n'est plus un problème.
Sinon une petite question: puisque LLVM est avant tout une VM, peut-être n'y aurait-il même pas besoin de compiler en langage machine les programmes chargés, non? Si on considère que qqun utilisant ton gestionnaire de fichier a de toutes façons LLVM d'installé, il peut directement exécuter les fichiers en bytecode, d'où gain de place, de temps, etc. Ensuite je ne sais pas, peut-être que les programmes interprétés ne sont pas suffisamment performants, mais j'ai l'impression de comprendre tout de même que LLVM (qui se définit comme Low Level Virtual Machine) prétend avoir des binaires interprétés plutôt performants. Donc peut-être est-il intéressant de s'arrêter à ce niveau (bytecode) de compilation?
Quoiqu'il en soit, tiens nous au courant des avancées de l'idée...
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
une Yamaha Ténéré. Mais pas le nouveau modèle, mais le vieux (XTZ 660), en l'occurrence une de 1991, donc agée de 18 ans. De toutes façons, la nouvelle Ténéré est jolie, mais je suis montée sur une dans un garage et je ne pouvais même pas toucher le sol avec la pointe des pieds en les étendant au max (aucun pied). Beaucoup trop grande pour moi. Je ne pourrais même pas l'essayer puisque je ne suis pas assez grand pour la mettre droite (et en m'arrêtant, je tomberais uhuh).
Ici par exemple, tu peux voir ma moto: http://www.flickr.com/photos/sonnyp/3534465576/
Mon copilote (regardez, juste derrière la visière, il a son casque en cuir et son écharpe, la Marmotte qui a le plus voyagé dans le monde) et moi, on avait un peu froid: Autriche en montagne, proche de la frontière allemande, fin avril...
Bye.
Jehan
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
c'est pas la peine de me convaincre, je suis d'accord avec tout ce que tu dis. Et de ce que j'en avais entendu dire, ainsi que de ce que j'en vois, couchsurfing m'a l'air d'être une superbe idée. C'est juste qu'elle convient moyennement à mon mode de vie. Là depuis hier je regarde et j'essaie d'envoyer des demandes. Mais bon déjà les demandes envoyées hier, finalement aujourd'hui je me dis que j'irai peut-être pas à ces endroits (ou peut-être juste en passant).
Alors aujourd'hui je viens de passer plusieurs heures à me demander où j'irai demain, et je regarde la carte. Ben rien que ça, ça m'énerve. C'est beaucoup plus simple et je perds moins de temps quand je pars simplement et que je vois où ça me mène au fur et à mesure.
Pour moi, dernier moment, c'est même pas forcément un jour en avance. C'est souvent plus le jour même. Un jour, je veux me barrer, je prends mes cliques et mes claques et ciao!
Donc maintenant je vais essayer d'envoyer qques demandes pour demain soir dans d'autres bleds où je suis susceptible de passer... mais bon...
Comme je le disais, je m'étais inscrit y a qques jours. En fait c'était genre y a une semaine. J'étais encore en Grèce. Je me demandais alors si je montais vers la Roumanie, je descendais vers Athènes ou je continuais en Turquie. Puis je me suis inscrit à CS, tellement on m'en avait parlé. Je trouve une connex wifi un peu bancale (qui coupe régulièrement, donc patience requise), fais un compte, une recherche pour Bucharest. Je prends la première réponse. La personne dit dans son profil "je réponds qu'à ceux ayant un profil rempli et une photo". Je comprends tout à fait son sentiment, donc je m'exécute avant d'envoyer ma demande. Là y a 20 000 champs à remplir. Heureusement pour la photo que j'avais voyagé avec les gars de Mozilla, sinon je n'aurais pas eu de photo de moi-même. Je mets donc la photo du blog Mozilla. Puis après avoir passé un temps fou pour remplir ce profil un minimum, j'envoie une demande, rédigée, et personnalisée (comme demandé aussi).
J'ai juste le temps d'envoyer cette seule demande au final avant que le portable coupe par fin de batterie.
Cette nuit, je dormais dehors, donc le lendemain je m'évertue à trouver de quoi remplir un peu la batterie du portable dans un bar, puis à trouver un wifi ouvert, pour finalement lire les emails et voir que la personne ne peut pas me recevoir.
Au final, je ne suis pas allé en Roumanie, et toute cette "paperasse" m'a décidément énervé et refroidi.
Là comme en Turquie, je fais dans le grand luxe et me suis payé un lit dans un dortoir, avec électricité et wifi, ben je me permets donc de recommencer... mais n'empêche, je ne peux m'empêcher de me dire que c'est pas vraiment la méthode qui me correspond.
Ça n'enlève en rien les qualités de ce site et projet pour tout autre voyageur à qui cela correspond davantage. Et ça ne m'empêche pas de recommencer et de voir si ça donne quelques choses... Mais bon ça m'empêche pas non plus de voir si y a pas des linuxfriens éparpillés dans le monde. Mais au final, je pense bien que je reviendrai à ma bonne vieille méthode. :-) Je sens que je pourrai pas tenir ce système longtemps, surtout qu'y a des endroits, à mon avis, le net redeviendra rare pour moi.
Jehan
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: TLS external
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche XMPP au printemps, le grand rafraîchissement. Évalué à 1.
Salut,
désolé, j'avais commencé à répondre, puis j'ai fait autre chose à côté et quand je suis revenu sur ma réponse et l'ai publiée, je vois que tu t'es auto-répondu!
Donc voilà, c'est une question de définition. Avoir des automatismes permet de rendre l'implémentation plus facile. Si on se met à dire « ah oui mais "ceci" sert à X, mais parfois à Y en même temps, et des fois — mais c'est rare! — ça sert juste à Y mais pas à X », ça rend les choses compliqué. Donc nous, on a un automatisme: on identifie les diverses entités du réseau avec SASL. À partir de là, il nous faut choisir un mécanisme SASL pour identifier deux serveurs. Bah ça tombe bien, y a external fait justement pour ce genre de cas!
C'est un peu comme les fonctionnalités à négocier lors de la création d'une connexion. Avant dans la RFC3920, c'était un gros bordel. C'était en gros "ben on peut un peu envoyer des nouvelles fonctionnalités à tout moment, et des fois, on peut ne pas les envoyer, c'est un peu comme on veut hein, ici c'est à la bonne franquette!". Quand j'ai commencé à implémenter ça, je me suis dit que c'était nul. Y avait aucune fiabilité dans cette logique, que des cas particuliers. J'ai donc relevé le problème, on en a discuté et on a maintenant un beau diagramme d'état avec des explications précises de ce qu'il faut envoyer, et quand. Et maintenant c'est facile à implémenter.
Ce genre de design ne peut impliquer sur le long terme que bug et incompatibilité entre systèmes poppant de temps en temps.
Ben là pour SASL EXTERNAL, je n'étais pas là quand ça a été décidé donc je ne peux assurer que c'est la raison exacte pour laquelle c'est là, mais dans mon esprit, c'est la même chose. Ça permet un système logique et fiable.
Et donc si au final, SASL external et Dialback ont tout à voir. Ils ont tous les deux pour but d'identifier des serveurs quand ils communiquent ensemble. Sauf que la vieille méthode le faisait avec un système à part basé sur le DNS et donc était totalement bancal. Le nouveau est un mécanisme SASL (qui encapsule certes le protocol TLS) permettant d'homogénéiser l'identification en S2S et C2S: tout SASL, quel que soit le type d'identité.
En fait faut voir SASL EXTERNAL comme une encapsulation de code qui rend le code plus haut niveau bien plus lisible et donc exempt de bug. Si tu es développeur, tu comprendras de quoi je parle.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: TLS external => SASL external
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche XMPP au printemps, le grand rafraîchissement. Évalué à 2.
Salut,
vraiment désolé, je me suis emmêlé les pinceaux, et pourtant j'ai pas mal relu! Il s'agit de SASL external (c'est le protocole SASL qui gère l'identification). C'est le seul mécanisme décrit dans la RFC de base de SASL. Si on pouvait corriger la dépêche sur ce point svp!
En fait le principe de ce mécanisme est très simple. Il s'agit de dire "on s'est déjà identifié précédemment, tu te rappelles pas?". Cela implique une décision au niveau du protocole applicatif d'un autre moyen de s'identifier (SASL external est le plus générique des mécanismes et n'a aucun sens sans contexte). Dans le cas de XMPP, en S2S, nous nous reposons sur l'identification TLS.
Pour ceux qui ne savent pas comment marche TLS, il y a une partie vérification de l'identité d'un correspondant, avec les fameux certificats. Mais comme les certificats, c'est un concept difficile pour le grand public (= chiant, ils veulent juste un mot de passe, et basta! C'est parti mon kiki!), seul l'identité du serveur est vérifiée. C'est ce que fait aussi http avec https, sauf que nous, on rend ça obligatoire (ça veut pas dire que tous le font réellement malheureusement, mais ça veut dire qu'on dit aux développeurs de serveurs: si vous le faites pas, vous n'êtes pas une implémentation complète).
Or en S2S, c'est deux serveurs, donc normalement chacun doit avoir un certificat. Donc on est capable de créer une liaison TLS vérifiée des deux côtés. À partir de ce moment là, quand arrive le moment de l'identification, on peut dire "ah bah on fait, on se connaît déjà".
En gros donc, SASL external, pour le S2S XMPP, ça signifie juste (parce que c'est la définition qu'on a donnée) utiliser 2 certificats en TLS.
Et ça c'est autrement plus sécurisé que le protocole originel (à vrai dire, c'est ce qu'il y a de plus sécurisé dans ce genre de communications. Je parle bien sûr de notre contexte précis avec deux serveurs qui se connaissent pas outre mesure et qui ont cependant besoin de s'identifier et de crypter les communications, et aussi on fait avec les limites de TLS que nous connaissons tous ici car on arrive pas encore à trouver un meilleur système, du moins pas sur lequel tout le monde est d'accord).
Pour rappel, le Dialback, le principe c'était juste qu'on identifiait le serveur qui nous appelait en créant une second connexion dans l'autre sens et où on dit "c'est bien toi qui m'a appelé à l'instant et qui m'a dit ça?", ce qui rend très facile de se faire passer pour un autre serveur avec du DNS poisoning ou d'autres méthodes similaires.
NOTE: le SASL external peut théoriquement aussi être utilisé en C2S avec une clé cliente. Mais je sais pas si beaucoup de serveurs utilisent un tel système (peut-être sur des réseaux d'entreprises où on veut se passer de mot de passe?).
Je crois que c'est aussi utilisé par Google en C2S lorsqu'on est dans l'interface web gmail. Dans ce cas là, le SASL external, c'est "on s'est identifié quand on s'est identifié à l'email, pas la peine de le refaire pour XMPP!". Comme je disais, tout est une question de définition par le protocole applicatif.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Salut à Toi
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche XMPP au printemps, le grand rafraîchissement. Évalué à 1.
Salut à toi aussi! ;-)
Bien que n'ayant jamais testé ton projet, j'avais vu tes divers journaux que tu avais fait dessus, et en fait tu m'avais presque énervé, parce que t'as plein d'idées très similaires aux miennes. ;-)
Quoiqu'il en soit, si ton projet est suffisamment avancé pour être utilisable (parce qu'y a quand même une sélection, on ne peut laisser n'importe quel projet inexistant prendre la place de projet solides) et que tu souhaites aller encore plus loin, tu peux probablement proposer une idée (ou plusieurs même) de projet impliquant SaT, pour lesquels tu pourrais être mentor. Donc SaT pourrait participer au Google Summer of Code sous la tutelle de la XSF. Jette donc un œil au lien donné plus haut.
Bonne continuation!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Google nous donne des sous
Posté par Jehan (site web personnel, Mastodon) . En réponse à l’entrée du suivi Avoir enfin un vrai moteur de recherche. Évalué à 3 (+0/-0).
Salut,
comme je disais dans le ticket, même programmé avec les pieds, je suis persuadé que ce sera déjà mieux que Google (qui est vraiment super mauvais pour Linuxfr dans mon expérience, pas vous?), parce que nous avons accès à la structure et logique interne du site.
À partir de là, ça signifie qu'on peut commencer par avoir un moteur de recherche basique fait en 30 minutes (genre on cherche juste la liste des mots en se limitant aux tags, au titre, puis au texte, et enfin on rajoute un bonus aux tickets récents, avec cet ordre de poids: ce sera déjà une grosse amélioration et ça fait quelques lignes de code pour la logique), puis progressivement l'améliorer avec le temps (affiner les poids, rajouter des éléments, créer un systèmes d'options à sélectionner, voire un jour tenter l'expérience d'un moteur de recherche avec apprentissage). Notez que je suis prêt à aider, mais il me faudrait un environnement de développement déjà prêt. Mon expérience désastreuse lors du concours pour le nouveau site m'a décidé à ne plus essayer d'installer cela moi-même.
Enfin pour les pubs, je comprends. Oui l'idée de tous les ans proposer une campagne de don est intéressante en switchant sur Google search en même temps, et tant que la campagne n'est pas bouclée, semble bien. Aussi n'y a-t-il pas des entreprises qui pourraient sponsoriser Linuxfr (sous et/ou matériel, je crois que les deux se sont déjà faits pour l'assoce, non?)? Je suis sûr que c'est facile, surtout si c'est pas grand chose, parce que vous représentez la source numéro 1 d'informations relatives à Linux et au Libre en France.
Peut-on avoir un ordre de grandeur sur la somme représentée par ces pubs? Quand vous dites que c'est pas grand chose, c'est quoi? 50 euros? 100? 1000?
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Restreindre les droits utilisateurs ou avoir un utilisateur avec certains droits admins?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Capsicum, une séparation fine des privilèges pour UNIX. Évalué à 2.
Salut,
cette solution permet-elle de restreindre les droits utilisateurs simples (1)? Par exemple si je veux lancer un programme en m'assurant que ce problème ne puisse pas du tout lire dans le système de fichier (même les fichiers appartenant à l'utilisateur qui fait tourner le programme), est-ce possible?
Ou bien cela permet simplement de donner quelques droits supplémentaires à un utilisateur (qui sont normalement réservés à root), mais pas tous (2)?
Je m'intéresse justement en ce moment à faire la première chose (1) en particulier. Quelles sont les solutions existantes (Capsicum ou autre) capables de faire ce genre de restrictions sous Linux?
Je me suis bien sûr intéressé aux "capabilities" du noyau Linux mais tout ce que je lis (par exemple http://www.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.4/capfaq-0.2.txt ) semble indiquer que cela ne permet que la seconde fonctionnalité (2) que j'ai citée plus haut.
Je suis intéressé par tout lien sur la chose ou points de départ pour une recherche. En particulier je souhaite ne pas avoir à modifier un kernel (donc en fait Capsicum, qui m'intéresse dans le concept et peut-être dans l'avenir, n'est cependant pas intéressant pour moi à court terme tant que ce n'est pas un élément de base de Linux).
Merci pour ce sujet intéressant en tous cas. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Meilleure interface de développement, pas forcément meilleure 3D
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Direct3D vs OpenGL. Évalué à 4.
Oui tout à fait. Mon exemple était simpliste à l'extrême pour être le plus explicite possible.
En fait, windu2b, ce que tu proposes est souvent fait entre versions mineures. Dans ce genre de cas, les développeurs vont définir une nouvelle fonction avec une meilleure interface et vont flagguer l'ancienne comme "dépréciée", ce qui (si le langage le permet) va en général générer des warnings à la compilation sans pour autant provoquer de vraie erreur.
Mais parfois c'est plus compliqué. Comme kaouete le dit, il peut y avoir des problèmes de "structures internes". De manière générale, les problèmes compliqués concernent l'architecture globale de l'API qui est trop complexe. Quand on s'en aperçoit après coup, cela implique que le problème n'est pas juste de changer une ou deux fonctions, mais qu'il faudrait changer l'API complète plus en profondeur (plus ou moins). C'est donc compliqué quand le problème vient des choix de "design" originel. Parfois vous ne pouvez même pas imaginer les choix étranges d'architectures de certaines librairies/programmes! Pour OpenGL en particulier, je ne sais pas, ceci dit.
Ensuite on peut presque toujours faire des fonctions qui appellent d'autres (encapsulation) pour avoir une interface plus agréable. On appelle cela une "abstraction" (on prend quelque chose de concret, par exemple "allumer un pixel à l'écran" pour en faire un concept plus abstrait comme "dessiner un point", donc plus facile à appréhender par l'esprit humain). Mais parfois on veut se limiter pour des raisons de performances. En effet à chaque fois qu'on appelle une fonction, l'ordinateur va la chercher dans la mémoire. Ensuite quand la fonction finit, on doit rechercher la fonction appelante et lui donner la réponse. Tous ces "allers et retours" en mémoire prennent du temps. On appelle cela l'overhead. C'est particulièrement important pour les APIs de bas niveau qu'on veut les plus optimisées possibles (en général on se "relâche" en montant les niveaux, ce qui se voit par le fait que les API bas niveaux sont souvent très concrêtes mais très optimisées alors que le haut niveau est très abstrait avec beaucoup d'overhead). Donc si on se met à faire massivement ce genre de choses, c'est probablement comme on disait qu'il y a un problème dans l'architecture et que c'est à ce niveau qu'il faudrait revoir l'API.
Enfin pour répondre à Shuba plus haut. C'est vrai que comme OpenGL/DirectX sont fait pour s'interfacer avec du matériel, j'imagine que certaines choses seront limitées si l'API (donc le matériel) ne définit pas certaines fonctionalités. Ensuite en ce qui concerne les shaders, l'article cite le fait que malgré qu'il n'y avait pas ça dans OpenGL à une époque, cela avait ajouté par extension avant que ce soit dans l'API. En outre, ça ne semble pas gêner Carmack plus que cela, et il ne parle pas de différence de performance. Donc cet exemple me semblait pertinent. Ensuite comme je disais, je ne connais pas le sujet de la 3D en particulier. Et tu as sans doute raison.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Meilleure interface de développement, pas forcément meilleure 3D
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Direct3D vs OpenGL. Évalué à 9.
Bonjour,
je ne fais pas de 3D, mais je suis développeur. Et donc de ce que je comprends des termes employés, notez tout de même que Carmack ne semble pas critiquer la qualité finale d'OpenGL, mais son API seulement, ce qui pour nous programmeurs peut être synonyme de "simplicité d'utilisation". Pour exprimer cela simplement, voici une analyse du discours:
imaginez que pour dessiner un cube de côté l, une bonne API a une fonction
cube(l)alors qu'une moins bonne aurait la fonctionmake_a_regular_hexahedron(d)où d est la diagonale et non le côté. C'est chiant à développer car le nom de la fonction est plus long et mal choisi (un regular hexahedron est un cube, le nom n'est pas clair). Aussi bien que l'on sache sache calculer sans problème le côté en fonction de la diagonale et vis-versa, "en général" les gens vont vouloir dessiner un cube dont il connaisse le côté, non la diagonale. Donc la seconde fonction demandera la plupart du temps une ligne de calcul supplémentaire dans le code: paramètre mal choisi.C'est cela que l'on appelle une mauvaise API (Interface!) en général.
De même quand il parle de compatibilité, il entend donc une pratique courante. Plus tard, on se rend compte que notre fonction
make_a_regular_hexahedronest vraiment chiante à utiliser. On aimerait bien changer le nom et le type de paramètre. Mais voilà, plein de logiciels l'utilisent et si on change cela, ça va "casser" la compatibilité ascendante => les développeurs devront revoir leur code et changer tous les endroits où ils créaient un cube avant s'ils veulent utiliser la nouvelle API.C'est quelque chose que les bonnes APIs refusent de faire de manière générale sauf en passant une version majeure où ils se permettent de casser plein de choses. C'est un choix accepté, en particulier dans le logiciel Libre où ce serait très dur de suivre les évolutions de toutes les librairies et on essaie de se fier aux numéros de version.
Cela confirme assez. Il dit bien que c'est mieux géré (donc plus simple à utiliser ou mettre en œuvre), pas que c'est plus efficace.
Maintenant quand il parle de nouvelles fonctionnalités, cela implique surtout que l'API Direct3D a intégré des facilités dans son interface. Supposons qu'aucune des API ne savait faire des boules. Puis notre bonne API se dit: tiens, je vais intégrer un algorithme pour faire une boule et j'encapsule ça dans une fonction que j'appelerai
ball(r). On peut maintenant faire des boules en une ligne de code. De son côté la mauvaise API n'a pas la fonction encore. Cela ne signifie pas que les développeurs ne peuvent pas faire de boule. Simplement ils sont obligés de calculer eux même ses limites, puis les remplir (avec d'autres types d'objets que l'API sait faire). C'est donc chiant. C'est en gros, ce qu'ils disent dans l'article là:Enfin tout cela est confirmé par:
où Carmack explique que maintenant ils utilisent OpenGL et que s'ils passaient à DirectX ça ferait beaucoup de boulot (même si ce dernier est visiblement plus facile à utiliser, leur base de code depuis les années doit être énorme), pour au final peu de bénéfice. Les bénéfices évidents avec une meilleure API: plus facile à maintenir (débugguer, etc.). Mais comme ils ont déjà une base très solide, ils n'y touchent sûrement plus autant qu'avant. Donc ce bénéfice est au final minime comparé au travail colossal de tout changer pour Direct3D. Quant à l'utilisateur final, il n'y verra probablement aucune différence car les deux APIs sont aussi performantes ou proches à mon avis. En effet si cela impliquait vraiment une différence pour l'utilisateur (plus fluide et/ou plus beau), alors ce serait vraiment un énorme bénéfice, surtout pour le domaine du shoot 3d, fer de lance de cette entreprise où le graphisme règne en maître. Si ça ne l'est pas, c'est que la seule différence est probablement pour le développement.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Chez moi, ca marche
Posté par Jehan (site web personnel, Mastodon) . En réponse à l’entrée du suivi Raccourci clavier pour venir au commentaire non lu précédent cassé. Évalué à 1 (+0/-0).
Ici Firefox 3.6.11 sous Linux. Ailleurs je sais pas, j'ai pas.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Et la partie "killer feature" du concours ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Les résultats du concours LinuxFr.org. Évalué à 10.
en fait les designers ont de la chance. Pour eux, c'était "facile" de participer (j'entends par là qu'ils n'ont rien à installer: ils codent, et testent direct sur le site alpha). Pour les développeurs "cœur", on devait se taper toute l'installation du site web (ruby, rails, la dizaine de module, le serveur web, etc.), avec des problèmes de version, etc.
J'ai perdu des heures dessus. Puis un autre développeur sympa a monté une image virtuelle et on nous l'a gentiment fournie. Alors moi, je cherche un logiciel de virtualisation pour cette image. Mais... erreur: la version du logiciel fournie dans ma vieille distri n'était pas compatible avec l'image. Je vais sur le site du logiciel, je prends les sources du logiciel, je compile, je l'installe. Je lance... cette fois la version est bonne, ça ne refuse pas l'image, mais... le serveur virtuel ne veut pas démarrer. J'ai des erreurs. Puis au final j'en ai eu marre et j'ai arrêté.
J'ai passé je-ne-sais-combien d'heures rien que pour essayer de monter mon environnement de développement avant d'abandonner (peut-être même plus que ça m'aurait pris pour coder cette killer-feature que je prévoyais). Je ne sais si c'est la raison pour les autres (je crois qu'y en a eu d'autres, il me semble avoir vu mention de cela), mais c'est la mienne.
Il faut dire aussi: je suis développeur, pas admin. Normalement quand je bosse sur un environnement complexe déjà en place (et linuxfr en est un), on a des admins qui se chargent de tout nous mettre en place. Non pas que je ne peux pas le faire moi-même, mais:
1/ ça me fait grave chier. Je déteste administrer. J'aime coder.
2/ ça me prendrait beaucoup plus de temps que l'admin qui connait bien son système.
3/ étant donné tous les problèmes que j'ai rencontrés, je me dis maintenant qu'il aurait fallu une doc bien plus précise que celle qu'on a eu malheureusement pour remonter tout cet environnement (dans un temps raisonnable, j'entends).
4/ ça tombe mal, ce mois en particulier, j'avais encore moins de temps que le mois d'avant et d'après.
Admins de Linuxfr, ne prenez pas cette critique mal surtout. Je n'ai aucun ressentiment contre vous. Donc ce n'est que de la critique que j'espère constructive, et sans aucune amertume. Je voulais juste participer au concours parce que je trouvais cela marrant et qu'y avait justement une nouvelle fonctionnalité html5 avec laquelle j'aurais voulu m'amuser un peu. Le prix à gagner ne valait pas ce développement donc ce n'était pas vraiment dans le but de le gagner de toutes façons.
Mais je suis sûr que ça prendrait juste 20 mins à un admin pro qui connait l'environnement Linuxfr de monter un environnement virtuel (par participant) et de fournir un accès ssh au participant dessus. Donc la prochaine fois que vous organisez un tel concours, je conseillerais de préparer qqch comme ça.
:-)
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: autre décentralisation
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Généralisation de la décentralisation & XMPP ?. Évalué à 5.
dois-je comprendre de ta réponse que tu penses que je trouve que XMPP est bon pour plein de choses parce que je souhaite ensuite me vendre dans la foulée comme consultant ou quelque chose du genre? Donc en gros que même si je ne croyais pas en XMPP, je le "vendrais" tout de même, pour ensuite pouvoir me vendre moi-même?
Alors outre le fait que quelqu'un pourrait trouver cela insultant (mais t'as de la chance, je ne suis pas susceptible), je tiens juste à préciser que je ne suis pas "consultant XMPP" (ni consultant tout court), et que je ne travaille (j'entends ici "travailler" dans le sens où je gagne ma vie) pas dans le milieu XMPP (bien que ça peut m'intéresser bien évidemment, mais je ne cherche pas plus que ça).
Ma "seule" relation avec XMPP est que j'y "travaille" (cette fois dans le sens "j'y passe du temps") sur mon temps libre, à la fois en développement perso de logiciel Libre, et aussi sur l'amélioration des RFCs IETF associées et des XEPs.
Donc si je promeus XMPP, c'est vraiment parce que j'y crois, et non pas pour des raisons vénales.
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: autre décentralisation
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Généralisation de la décentralisation & XMPP ?. Évalué à 5.
j'avais fait un plugin pour Firefox (doit y avoir 2 ans, waw le temps passe!) qui stocke justement les marques pages sur un nœud pubsub de son compte Jabber (cf. XEP-0048 bien que celle-ci mérite une bonne réécriture, que je prévoyais également en même temps de compléter le plugin). Mais ce plugin est resté à un stade très expérimental (il est très mal intégré à Firefox, pour l'instant c'est tout juste un "proof of concept" basique, fonctionnel mais pas du tout utilisable avec plaisir) parce que je n'ai jamais pris le temps d'aller plus loin, bien que j'ai encore envie d'y revenir dès que je le veux.
En gros, les marques pages sont stockées sur son serveur XMPP (qui est donc décentralisé, on peut même avoir son propre serveur si on veut contrôle total), et est privé. Mais PubSub étant ce qu'il est avec son système de droit, on doit aussi pouvoir avoir des nœuds publiques ou semi-publiques (comme je dis plus haut: on choisit à qui on partage au cas par cas, ou bien par groupe de contact, ou à tout le monde, etc.) pour partager ses marques pages, de sorte que si quelqu'un change ses marques pages publiques et que j'y suis inscrit, la liste serait automatiquement mise à jour dans mon navigateur. Etc.
Aussi vous l'aurez compris, je ne suis pas d'accord avec les gens plus haut qui pensent que XMPP n'est pas du tout adapté pour ce genre de choses.
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Théoriquement, ça devrait déjà être possible
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Généralisation de la décentralisation & XMPP ?. Évalué à 4.
C'est même beaucoup mieux qu'une inscription à la présence puisque c'est la seule information dont ton bot a besoin. Avec une inscription présence, cela génère plein d'information inutile sur le réseau (la présence elle-même déjà, que ton bot envoie et qu'il reçoit de tous les contacts, puis toute information relative, comme des "découvertes" de fonctionnalités faites par les contacts du bot à celui-ci, ou bien la liste de leur propre fonctionnalité qu'ils envoient potentiellement pro-activement, etc.).
Là, aucun échange superflu, uniquement la nouvelle information nécessaire, SI et QUAND l'avatar change, et seulement à ce moment là.
C'est de là que vient le nom PubSub: "Publish-Subscribe" (Publier-S'inscrire).
Perso j'irais avec une implémentation là dessus si j'étais toi (mais je suis pas sûr que ce soit l'implémentation choisie par la plupart des clients à l'heure actuelle).
Enfin bon vcard marche aussi parfaitement pour ton use case, seulement il n'y aura pas de mise à jour pro-active (si jamais tu veux savoir si un avatar est mis à jour et que tu n'as pas d'inscription présence, tu dois redemander).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Théoriquement, ça devrait déjà être possible
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Généralisation de la décentralisation & XMPP ?. Évalué à 6.
tout dépend de comment sont implémentés les avatars actuellement.
Il existe pour l'instant 3 (je pense pas plus, mais qui sait?.. on a tellement de doublons) spécifications pour les avatars XMPP:
- ceux basés sur une requête spécifique (IQ-based, XEP-0008), historiquement. Mais cette méthode n'est plus considérée comme valide et obsolète (ce qui ne signifie pas qu'il n'y a pas quelques implémentations qui l'utilisent encore peut-être).
Ta demande est-être possible avec cette XEP mais je ne creuse pas, cette spéc est très limitée et inintéressante.
- ceux basés sur les vcards (XEP-0153), méthode très répandue et la spéc est considéré comme active (la seule spéc avatar active), bien qu'historique également (donc potentiellement supplantable).
Cette spéc te permet déjà de faire ce que tu souhaites puisque la spéc vcard (XEP-0054) précise bien dans les considérations de sécurité que la vcard est visible par le monde entier. Il n'y a pas de notion de droits sur une vcard donc ton bot XMPP peut demander la vcard de n'importe qui et *n'a pas besoin de demander à être inscrit dans ses contacts!*
- ceux basés sur PEP, donc PubSub (XEP-0084). Son statut est en "brouillon", mais c'est le seul considéré comme en état de standardisation. En gros ça se bagarre avec la XEP vcard pour savoir qui l'emporte.
Là aussi c'est possible puisque PubSub a un système de droits élaborés, contrairement à vcard qui est "visible par le monde entier". Donc un utilisateur peut théoriquement décider à qui il montre ses infos publiés au cas par cas (ça peut être seulement à ses contacts, voire seulement à un groupe de contacts, par une liste de JID, à tout le monde, ou même sur demande que l'utilisateur reçoit puis valide ou refuse ensuite). Évidemment les clients gèrent très mal, voire pas du tout pour tous ceux que j'ai vu, ce genre de droits sur les nœuds Pubsub ou PEP, et il ne demandent jamais ce genre d'infos. Donc cela dépend probablement de l'implémentation du client et du serveur, cad quels droits par défaut ils mettent en créant un nœud. Étant donné ce que j'avais vu à l'époque de tests sur PubSub (mais mes derniers tests remontent bien à un an ou plus maintenant), y a de fortes chances que les droits par défaut soient souvent publiques, malheureusement (je dis "malheureusement" de manière générale, par contre le nœud avatar, je pense que "publique" peut être une bonne valeur par défaut, mais il faudrait quand même que l'utilisateur puisse changer cette valeur s'il le souhaite).
Mais heureusement par contre pour toi qui peut sûrement récupérer les avatar PEP de cette façon.
Pour conclure, je pense que tu n'auras pas de problème pour faire ce que tu veux. Par contre tu peux voir que les avatars Jabber sont un peu un bordel pour l'instant et que théoriquement, un même utilisateur pourrait avoir 3 avatars différents selon la technologie choisie pour la récupérer.
Bye.
Jehan
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Pour une prochaine fois ?
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Concert blues-rock à Nakano, Tokyo le 31 juillet. Évalué à 1.
Bonne journ'ee!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Pratique courante
Posté par Jehan (site web personnel, Mastodon) . En réponse au message Améliorer la configuration SPF. Évalué à 2.
donc si je comprends bien ce que tu me dis, en gros il ne *faut pas* refuser un email si le FROM ne correspond pas à la vraie adresse d'envoi ou en vérifiant l'enregistrement SPF du FROM?
Donc je suis condamné à recevoir des faux emails d'arnaque de mon propre domaine en gros (ou encore des faux emails de mes comptes Facebook/Twitter/le truc hype du moment, alors que je n'ai aucun compte chez les moindre de ces services), lesquels passent le filtre SPF car celui-ci ne se base pas sur l'adresse du FROM mais sur la vraie adresse d'envoi.
Alors bien sûr, ces emails ne passent en général pas le filtre spam ensuite, mais j'aimerais tout de même pouvoir les refuser avant tellement ce sont des faux évidents selon moi (mon domaine, donc mon adresse email, datant de nombreuses années, je reçois plus d'une centaine de spams par jour, aux alentours de 150 même. Et je parle juste de mon compte, pas du serveur).
C'est quand même vraiment un protocole ridicule le protocol email.
Si quelqu'un a des suggestions, je suis tous yeux.
Merci pour la réponse et pour d'éventuelles autres réponses.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: mencoder
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Quelques outils pour générer des fichiers WebM. Évalué à 2.
le lendemain de l'annonce de libération du VP8, quelqu'un a posté un patch sur la mailing list de développement de mplayer/mencoder, pour le support de VP8/WebM.
Donc oui, c'est actuellement supporté dans la version de développement (dans le dépôt de source donc), bien que je n'ai pas testé personnellement.
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Mesures anti-phishing.
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Des serveurs de la fondation Apache compromis à cause d'un tinyurl, entre autre.. Évalué à 1.
non si tu lis le post de la fondation, ou mon explication plus haut, tu verrais que le tinyurl pointe sur le site Jira lui-même. Il n'y a pas d'autre machine impliquée ici. Le tinyurl très probablement ne devait servir qu'à cacher la taille de l'url (ainsi que le fait qu'elle contienne un script pour ceux qui l'auraient lu). Mais le domaine de l'url n'aurait rien eu de suspicieux par contre.
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Mesures anti-phishing.
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Des serveurs de la fondation Apache compromis à cause d'un tinyurl, entre autre.. Évalué à 3.
Donc en ce cas, la solution 3/ est à bânir. Le navigateur peut juste filtrer par les méthodes 1/ et 2/ (même si le script est intégré dans la page "graphiquement", il n'est pas exécuté, juste affiché, donc le navigateur peut faire la différence et la méthode 2/ ne bloque donc pas ce type d'utilisation).
Mais je vois d'autres problèmes.
Par exemple, imaginons qu'on veuille justement désactiver, mais partiellement seulement, certaines parties d'un script inclus dans une page et que cela permette d'en changer le sens (et obtenir même un usage néfaste), on pourrait alors:
- inclure dans une url une variable contenant la copie de la partie du script à virer (que l'on sait sera incluse dans la page retournée).
- Le serveur lui en réalité ne connaît pas cette variable bidon, n'en prendra pas compte et retournera la page normalement.
- Le navigateur ne sait pas ce que fait ou non le serveur en interne, bien évidemment, par contre il reconnaît que le bout de script qu'il a vu dans l'url se retrouve dans la page comme code à exécuter. Il en conclut "intelligemment" qu'il s'agit sûrement d'une faille de cross scripting et que ce code a été injecté (alors qu'il n'en est rien, il n'y a aucune corrélation réelle entre l'url et ce script).
- Le navigateur retire ce bout de script, mais s'il exécute le reste, ça peut devenir dangereux (si ça a été pensé pour l'être).
Donc ici on a généré une attaque en faisant croire au système de protection qu'il y avait une autre attaque! Ainsi il faut faire très gaffe aussi avec ce genre de sécurité intelligente qui peuvent elle-même créer des failles là où il n'y en avait pas auparavant.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Mesures anti-phishing.
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Des serveurs de la fondation Apache compromis à cause d'un tinyurl, entre autre.. Évalué à 4.
Le script est injecté dans la page (par une url dans ce cas, mais d'autres méthodes sont envisageables), de sorte qu'il est tout à fait envisageable que le serveur lui-même sert la page avec le script inclus dedans. Là encore, les deux sont possibles. On pourrait aussi imaginer que le script est inséré côté client, par exemple si les variables url sont parsées par du javascript, qui à son tour exécute des scripts qui y sont passés. Mais le cas où l'url est parsée côté serveur et donc que ce dernier sert une page avec le script dedans est tout à fait probable. Dans l'attaque en question, rien n'est précisé sur la méthode exacte du cross scripting (encore une fois, ils attendent probablement que la faille soit comblée).
Par conséquent, d'un point de vue purement basique techniquement, le script ne vient pas d'une autre machine: il vient du serveur.
Cependant il est clair que toute méthode impliquant un script (donc une exécution sur machine) passable par url est mauvaise par design (franchement! Non?). Et comme je soulignais, le navigateur peut sûrement détecter ce genre d'anomalie, mais ce n'est pas du tout un truc évident, car de manière générale, il n'y a pas de bug technique, mais un "bug humain". On demande au navigateur là de repérer et protéger une grosse erreur du développeur (= accepter du code exécutable dans l'url sans protection particulière, l'équivalent d'utiliser la fonction "system" dans un programme sans aucune vérification, et pour une exécution de code très sensible). Néanmoins comme dans ce cas, il y a peu de chances que ça soit bien utilisé, on peut essayer...
Perso, je vois ca ainsi:
1/ si le script est intégré côté client, on peut repérer ça facilement et donc bloquer un tel script.
2/ sinon (intégré côté serveur), on peut essayer de repérer des familiarités entre les scripts intégrés dans la page et ce qui est passé en url. C'est apparemment ce que fait IE8beta2 par exemple (lien très intéressant donné par PasBill PasGate ci-dessous).
3/ de manière générale et plus simple, je me demande s'il ne faut pas virer de l'url tout ce qui ressemble à un script avant même de faire la requête au serveur. Comme je disais, je ne vois pas de bon usage, et même si le script n'est pas intégré dans la page en réponse, rien ne dit qu'il n'est pas exécuté sur le serveur lui-même et peut donc s'avérer très dangereux là-bas.
Néanmoins cela pose la question: jusqu'où «l'intelligence» (au sens IA) du navigateur doit aller pour protéger les erreurs de développement? Et qui sait si — en faisant cela — on ne bloque pas aussi des requêtes légitimes (contre toute attente, il existe peut-être de bons usages, même si je ne les vois pas dans l'immédiat, avec des serveurs qui vérifient et traitent le script au préalable par exemple pour en faire quelque chose d'adéquat, ou le supprimer si dangereux).
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Mesures anti-phishing.
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Des serveurs de la fondation Apache compromis à cause d'un tinyurl, entre autre.. Évalué à 7.
ce n'est pas du phishing. Le lien ne redirigeait pas vers un autre serveur (un serveur des attaquants ou déjà corrompu par ces derniers par exemple). Cela redirigeait vers le serveur Apache lui-même. Il y a apparemment une faille de cross scripting (script croisé serait une trad adéquate) dans le logiciel Jira qui — à une certaine page — accepte donc un script externe en url (le post n'en dit pas plus sur ce point, mais j'imagine car ils l'ont rapporté à Atlassian et la faille exacte ne sera divulguée qu'une fois corrigée).
En gros, pour expliquer, dans l'url même, ils ont écrit un script (dans une quelconque variable probablement) — ce pourquoi le tinyurl était notamment intéressant pour cacher la longueur de l'url fort probablement, ainsi que son contenu évidemment aussi bien que, redirigeant sur Jira, ça puisse ne pas éveiller de soupçon sur un rapide coup d'œil — puis ce script a donc été intégré dans la page web comme s'il faisait partie normale du site, et donc le script avait accès au cookie de session. Le navigateur n'a donc aucune raison de refuser à ce script d'accéder au cookie de session correspondant à l'url du bugtracker Apache a priori. Ce pourquoi je pense que même Firefox ferait l'erreur. D'ailleurs les gars de la fondation Apache ne donnent pas de détails sur les navigateurs touchés ou non, donc je pense que tous le sont.
Le seul truc que peut faire le navigateur, c'est détecter un comportement étrange et peut-être générer un avertissement, j'imagine. En effet, comme le script est côté client, le navigateur voit peut-être qu'il est intégré de l'url (mais ce n'est pas sûr, ça doit dépendre comment il est intégré, si l'intégration est en PHP, elle est faite par le serveur à partir de l'url).
Enfin bon... le bug vient de Jira, pas du navigateur en l'occurrence (même si ces derniers peuvent peut-être être améliorés pour détecter des comportements étranges et des failles potentielles).
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: LA SUITE ! LA SUITE! LA SUITE! LA SUITE ! LA SUITE !
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Présentation d'un projet de sensibilisation à l'informatique libre. Évalué à 4.
J'aime pas faire des commentaires pour rien dire, mais pour une fois j'avais quand même envie de dire que j'aime bien aussi (par conséquent, m'avoir fait répondre quelque chose qui sert à rien, c'est donc pas rien). J'ai même ri sur la fin.
Et moi je dis, pour faire écho à une demande d'un autre commentaire plus haut: non pas de wiki. Je veux lire ton histoire à toi. Après, c'est du CC-by. Si les gens veulent modifier après coup, libre à eux, mais perso dans un premier temps, je préférerai ta version brute à toi. Ensuite c'est toi qui choisis, évidemment. :-)
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Pourquoi ne pas créer un projet parallèle pour la partie sonore?
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Le son des films libres faits avec Blender. Évalué à 2.
si je résume, le problème principal pour leur participation aux projets de Logiciels Libres dédiés à l'édition sonore, ainsi que davantage d'implication dans la production sonore est que ce n'est pas leur but principal. Il s'agit après tout de la Blender Foundation, et je comprends d'ailleurs tout à fait qu'ils décident de s'impliquer principalement dans le graphisme, mais c'est dommage. Je le dis en tant que personne intéressée par ces projets, et en tant que musicien.
Cependant il eût probablement été possible de monter une équipe pour le son, avec des musiciens, et des développeurs pour améliorer les programmes choisis. Évidemment cela demande également une levée de fonds, de même que fait la fondation Blender pour la partie graphisme. C'est donc probablement trop tard pour le projet en cours (hormis faire rétroactivement, après la vente, comme proposé, mais ce n'est pas pareil). Néanmoins pour les futurs projets, cela peut être très intéressant. Je pense qu'il peut valoir le coup de monter un dossier, de le leur présenter et de chercher déjà des sponsors (associé aux projets Blender qui devient de plus en plus gros, cela devrait se faire assez bien) pour les futurs films/jeux. Le but serait de pouvoir monter une équipe de développeurs (pour les programmes sons choisis)/compositeurs/musiciens/ingénieur du son rémunérés le temps du projet (comme pour la partie graphisme actuellement donc), d'améliorer l'ensemble des outils audio choisis, et de proposer un travail de qualité faits avec des outils Libres (pour démontrer leur qualité et l'état de l'art), sous licence Libre, par exemple CC-by comme pour la partie vidéo (pour le plaisir de faire de la musique Libre).
Si cela intéresse des gens, on peut monter un tel projet et le proposer à la Blender Foundation. Je pense qu'il peut être bien de se regrouper. N'hésitez pas à me contacter.
Pour le présent fim, où je pense qu'il est un peu tard pour envisager un projet de cette ampleur, on peut déjà travailler avec l'état de l'art actuel dans le traitement de son. J'ai cependant quelques questions:
- Où a-t-on accès aux images? Sur le blog, on a à peine un concept art en video clip, pas de scénario (juste un concept: une fille et un dragon... Bon les films Blender font pas dans l'original jusque là ;-), et d'ailleurs c'est normal puisqu'ils commencent à peine la pré-prod.
J'ai donc l'impression qu'il faut travailler sur cette base très vague pour l'instant, non? Ou y a des données plus avancées, mais un peu plus cachées?
- Je suis intéressé par ce projet, mais je suis actuellement au Japon, tout juste arrivé, avec un visa un an. Je ne connais pas encore vraiment de musicien ici. Je suis pour ma part harmoniciste, suffisamment bon (j'aime pas dire ça, mais bon si je dis "je suis mauvais" pour faire le modeste à deux sous, y a pas d'intérêt) et je ne connais pas bien les outils actuels (j'ai essayé Ardour et compagnie, très sympa, mais très simplement. Je ne suis pas du tout calé dans ces produits pour être efficace). En l'absence donc d'une équipe cohérente et en un même lieu physique comme pour le graphisme (cf. projet de plus grosse envergure pour les prochains projets Blender), quelles sont les possibilités de créer un groupe de musicien à distance? Et si oui y a-t-il des personnes intéressés? Je suis fortement intéressé et j'ai un peu de temps à l'heure actuelle, pour jouer (et peut-être pour composer).
- Avez-vous des contacts de musiciens intéressés par le Libre ou de studios qui utilisent des outils Libres (on en a quelques un en France a priori) au Japon? Cela m'intéresserait. :-)
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Intéressant
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal LLVM dans un gestionnaire de paquets ?. Évalué à 2.
- Tu as testé sur quelques exemples, mais comme tu le dis, à ce que je comprends, llvm est expérimental. Peut-être que sur des bouts de code utilisant des fonctionnalités de langage très particulières, llvm peut montrer des limites? Cela n'est qu'une hypothèse basé sur le fait que llvm est apparemment expérimental (cf tes dires) et que les dévs eux-même semblent surtout destiner ce compilo/VM à des chercheurs (cf. section "LLVM Audience" de la page "Features" du site, où la plupart des lignes désignent chercheurs ou développeurs, hormis la dernière pour un certain type d'utilisateurs finaux).
- Et si le développement de LLVM s'arrête? Ton idée est entièrement dépendante de ce produit. Tout autre gestionnaire de paquet marche avec n'importe quel compilateur.
- Apparemment LLVM ne supporte vraiment que C et C++ pour l'instant (et qques autres en développement). C'est beaucoup étant donné que ce sont les langages les plus utilisés, historiquement. Mais on sait que de nos jours, il y a foultitude plus de langages et que ces autres langages sont de plus en plus utilisés, étant donné qu'on considère de plus en plus le gain de temps apporté par les langages de haut niveau.
Une "solution" serait que les programmes utilisant un langage non supportés seraient en binaire dans tes repositories, et ceux en C/C++ en bytecode. Néanmoins je ne connais pas les statistiques sur le pourcentage de programme non C/C++, mais cela ne m'étonnerait pas que ce soit plus de la moitié des programmes existants. Et dans ce cas, on réduit énormément les intérêts principaux de ton gestionnaire de paquet et de ses dépôts de programme très petits.
Évidemment si à l'avenir, LLVM se met à supporter tous les langages (boulot titanesque), cela n'est plus un problème.
Sinon une petite question: puisque LLVM est avant tout une VM, peut-être n'y aurait-il même pas besoin de compiler en langage machine les programmes chargés, non? Si on considère que qqun utilisant ton gestionnaire de fichier a de toutes façons LLVM d'installé, il peut directement exécuter les fichiers en bytecode, d'où gain de place, de temps, etc. Ensuite je ne sais pas, peut-être que les programmes interprétés ne sont pas suffisamment performants, mais j'ai l'impression de comprendre tout de même que LLVM (qui se définit comme Low Level Virtual Machine) prétend avoir des binaires interprétés plutôt performants. Donc peut-être est-il intéressant de s'arrêter à ce niveau (bytecode) de compilation?
Quoiqu'il en soit, tiens nous au courant des avancées de l'idée...
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Couchsurfing
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Vagabond libre cherche lit. Évalué à 1.
une Yamaha Ténéré. Mais pas le nouveau modèle, mais le vieux (XTZ 660), en l'occurrence une de 1991, donc agée de 18 ans. De toutes façons, la nouvelle Ténéré est jolie, mais je suis montée sur une dans un garage et je ne pouvais même pas toucher le sol avec la pointe des pieds en les étendant au max (aucun pied). Beaucoup trop grande pour moi. Je ne pourrais même pas l'essayer puisque je ne suis pas assez grand pour la mettre droite (et en m'arrêtant, je tomberais uhuh).
Ici par exemple, tu peux voir ma moto: http://www.flickr.com/photos/sonnyp/3534465576/
Mon copilote (regardez, juste derrière la visière, il a son casque en cuir et son écharpe, la Marmotte qui a le plus voyagé dans le monde) et moi, on avait un peu froid: Autriche en montagne, proche de la frontière allemande, fin avril...
Bye.
Jehan
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Couchsurfing
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Vagabond libre cherche lit. Évalué à 1.
c'est pas la peine de me convaincre, je suis d'accord avec tout ce que tu dis. Et de ce que j'en avais entendu dire, ainsi que de ce que j'en vois, couchsurfing m'a l'air d'être une superbe idée. C'est juste qu'elle convient moyennement à mon mode de vie. Là depuis hier je regarde et j'essaie d'envoyer des demandes. Mais bon déjà les demandes envoyées hier, finalement aujourd'hui je me dis que j'irai peut-être pas à ces endroits (ou peut-être juste en passant).
Alors aujourd'hui je viens de passer plusieurs heures à me demander où j'irai demain, et je regarde la carte. Ben rien que ça, ça m'énerve. C'est beaucoup plus simple et je perds moins de temps quand je pars simplement et que je vois où ça me mène au fur et à mesure.
Pour moi, dernier moment, c'est même pas forcément un jour en avance. C'est souvent plus le jour même. Un jour, je veux me barrer, je prends mes cliques et mes claques et ciao!
Donc maintenant je vais essayer d'envoyer qques demandes pour demain soir dans d'autres bleds où je suis susceptible de passer... mais bon...
Comme je le disais, je m'étais inscrit y a qques jours. En fait c'était genre y a une semaine. J'étais encore en Grèce. Je me demandais alors si je montais vers la Roumanie, je descendais vers Athènes ou je continuais en Turquie. Puis je me suis inscrit à CS, tellement on m'en avait parlé. Je trouve une connex wifi un peu bancale (qui coupe régulièrement, donc patience requise), fais un compte, une recherche pour Bucharest. Je prends la première réponse. La personne dit dans son profil "je réponds qu'à ceux ayant un profil rempli et une photo". Je comprends tout à fait son sentiment, donc je m'exécute avant d'envoyer ma demande. Là y a 20 000 champs à remplir. Heureusement pour la photo que j'avais voyagé avec les gars de Mozilla, sinon je n'aurais pas eu de photo de moi-même. Je mets donc la photo du blog Mozilla. Puis après avoir passé un temps fou pour remplir ce profil un minimum, j'envoie une demande, rédigée, et personnalisée (comme demandé aussi).
J'ai juste le temps d'envoyer cette seule demande au final avant que le portable coupe par fin de batterie.
Cette nuit, je dormais dehors, donc le lendemain je m'évertue à trouver de quoi remplir un peu la batterie du portable dans un bar, puis à trouver un wifi ouvert, pour finalement lire les emails et voir que la personne ne peut pas me recevoir.
Au final, je ne suis pas allé en Roumanie, et toute cette "paperasse" m'a décidément énervé et refroidi.
Là comme en Turquie, je fais dans le grand luxe et me suis payé un lit dans un dortoir, avec électricité et wifi, ben je me permets donc de recommencer... mais n'empêche, je ne peux m'empêcher de me dire que c'est pas vraiment la méthode qui me correspond.
Ça n'enlève en rien les qualités de ce site et projet pour tout autre voyageur à qui cela correspond davantage. Et ça ne m'empêche pas de recommencer et de voir si ça donne quelques choses... Mais bon ça m'empêche pas non plus de voir si y a pas des linuxfriens éparpillés dans le monde. Mais au final, je pense bien que je reviendrai à ma bonne vieille méthode. :-) Je sens que je pourrai pas tenir ce système longtemps, surtout qu'y a des endroits, à mon avis, le net redeviendra rare pour moi.
Jehan
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]