Oui cv est bien utile, je viens de le mettre sur 2 des mes machines :). Sans compter que ça gère d'autre outils, que ça fonctionne une fois la copie lancée (donc idéal en cas d'oubli de barre de progression), et que ça permet de voir ce qui est en cours. Tu as l'intention de l'empaqueter sous Debian et/ou dans d'autres distros ?
Je trouve l'astuce excellente, outil intéressant. Mais si j'ai bien compris ça ne marche que pour un gros fichier (ça cherche le fichier ouvert le plus gros), si tu copies une arborescente complète t'es marron.
J'en profite pour placer un petit outil que j'avais écrit, gcp: il est dans Debian et gère entre autres une barre de progression et l'ajout de fichiers à copier en cours de route, il y avait eu une dépêche à l'époque: https://linuxfr.org/news/gcp-un-outil-de-copie-%C3%A0-la-cp
Bon je suis tellement pris par Salut à Toi que je n'ai plus trop de temps à y consacrer (dernier commit en 2011), mais je m'en sers régulièrement et je vais peut-être me prendre une journée à l'occase pour ajouter 2/3 améliorations.
À vrai dire, s'il y a un remplaçant digne de ce nom, ça ne me dérangerait pas que Twisted perde en popularité.
Ouai, enfin moi c'est au cœur de mon projet, et ça me ferait plus qu'un peu chier (je suis loin d'être le seul dans ce cas). Et je ne regrette pas du tout ce choix: Twisted m'a permis d'implémenter des idées très rapidement, les outils sont pratiques, et je trouve le tout relativement bien fait.
Utiliser Twisted, c'est une expérience un peu particulière : ils ont leurs propres conventions de nommage, ils réinventent la roue sur beaucoup de sujets (par exemple ils utilisent leur propre système de logging largement inférieur à celui de la stdlib). Et quand tu contribues un patch ils sont capables d'ergoter sur des points de détails comme le nombre de retours chariot dans les définitions de classe.
Les conventions de nommage, sauf erreur, c'est historique: c'était là avant la PEP 8 et ils ont gardé ensuite pour ne pas casser la compatibilité.
Ceci dit j'ai arrêté de suivre Twisted depuis l'échec de mon fork :-)
Ah oui, j'ai vu après coup que le message avait 2 ans. Pourquoi le fork à échoué ? Et pourquoi ne pas avoir directement proposé des patchs mainsteam ?
asyncio a été conçu pour que les principales bibliothèques d'I/O asynchrones pour Python puissent s'y adapter (Twisted, Tornado, gevent…). Ce n'est pas spécialement adapté à Twisted. La notion de protocole et de transport a été adoptée simplement parce qu'elle est assez pertinente :-)
Je disais ça par rapport à ce genre de messages: l'API semble compatible, et Twisted devrait permettre à terme une compatibilité entre les deferred et les futures de Tulip. C'est vrai que ça serait super d'unifier un peu tout ça.
J'espère en tout cas que la multiplication des API asynchrones ne va pas provoquer un désintérêt pour Twisted, mais bon je ne m'inquiète pas trop surtout que le développement est toujours très actif.
Ils ont commencé le port depuis longtemps et la plupart des modules sont portés, ils cherchent à faire un port en faisant un code qui tourne à la fois sur python 2.7 et python 3, et ils ont une grosse batterie de tests pour valider ça. L'avancement peut être vu (si c'est à jour) à ces deux adresses:
La syntaxe callback pose des problèmes à certains, personnellement je m'y suis fait et je n'ai pas tant de mal que ça à la débogguer (je la trouve même plutôt bien faite). Mais même s'il y a une API asynchrone qui arrive dans Python (qui a été faite en prenant en compte Twisted pour qu'il puisse l'intégrer si j'ai bien compris, tu en sauras sûrement plus que moi là dessus), ça n'apporte pas tous les protocoles supportés avec, avec les 11 ans d'expérience pour la gestions des subtilités, et les outils autour. Twisted est riche et mature, c'est une base solide.
En ce qui me concerne, c'est en particulier (mais pas seulement) la partie XMPP qui m'intéresse, et Ralph Meijer devrait remonter petit à petit Wokkel dans Twisted cette année.
Le fork semble tout à fait amical (je n'avais pas suivi ce fil je suis assez peu la liste de Twisted en ce moment), à lire en diagonale j'ai même l'impression qu'il va servir à porter le tronc principal.
Ça change des pubs virales et des chats qui se cassent la gueule, merci pour le lien :)
Pour ceux qui trouvent ça trop long, en résumé c'est « élections, piège à cons ». L'argumentation est intéressante, je vais essayer de trouver le bouquin (les références pour ceux que ça intéresse: Démocratie. Histoire politique d'un mot aux États-Unis et en France, Lux, 2013 - ISBN 978-2-89596-090-4).
Je ne savais pas qu'il y avait eu les assemblées d'habitants dans les villages au Moyen Âge dont il parle (à part les Communes mais on n'est plus au Moyen Âge là), ça donne envie de se renseigner plus.
En suivant Wikipédia, on tombe sur ces 2 lettres émouvantes qui montrent les opinions de 2 camps opposés:
Ça fait un peu penser au Maria de Jean Ferrat, pas tant pour le contexte - qui n'est quand même pas comparable -, que pour le frère et la sœur dans les camps opposés, sûrs de leurs convictions.
ce que je veux dire, c'est outre le fait de proposer un truc sur github (il est hors de question que je me fasse un compte dessus), ça complique pas mal pour signer le manifeste. Je pense qu'un simple email aurait facilité les choses.
Alors oui peut-être qu'on peut envoyer un git-diff mais d'une ça oblige d'une à utiliser git, et de deux à chercher une adresse je ne sais où pour envoyer le patch.
Et puis pour la forme, ça aurait été pas mal de proposer un jid pour signer.
Ah je ne retrouvais plus le nom du site web qui permettait de chercher sur pas mal de service MUC, merci à Link Mauve pour le lien: http://search.wensley.org.uk/
Pour ce qui est de l'implémentation, pour MUC c'est pas très compliqué et y'a quand un bon paquet de bibliothèques qui le gèrent déjà.
Pour la mise à l'échelle, c'est déjà répondu par ailleurs, mais je pense que les cas où ça gênent sont rares pour le moment (y'a peu de salon qui dépassent la centaine de participants, et peut de services qui dépassent la centaine de salons).
Le jour où ça sera vraiment gênant, gageons que les implémentations de solutions iront vite.
C'est juste une traduction et une expression, faut pas voir le mal partout :).
De toute façon je pense que la plupart des clients/serveurs sont chiffrés, mais il y a probablement de vieux trucs qui traînent encore et qui vont toussoter. XMPP est très répandu, y'a des chance que ça casse quelques trucs.
installer et administrer un serveur xmpp: c'est compliqué.
ça je ne pense pas, OpenFire est ultra facile à installer, Prosody pas très compliqué pour qui sait utiliser un éditeur de textes.
ejabberd est de mémoire plus compliqué mais c'est pas la mort, et je ne sais pas trop pour les autres (Tigase ?).
utiliser un serveur existant: certains gros ne proposent pas ou ne documentent pas la gestion des salons.
il y a un problème lié à la décentralisation de la liste des salons: c'est facile d'avoir la liste d'un service MUC en particulier, mais pas de tous ceux existants.
Pour l'administration des salons elle-même au niveau serveur, c'est dépendant des implémentations, faut voir au cas par cas, mais a priori tu dois avoir au moins la base (liste de tous les salons, suppression de salon, etc). Quels serveurs a tu rencontré qui ne proposent pas ça ? Faut leur demander directement si ça manque.
Il faut voir aussi qu'un service MUC peut être totalement indépendant du serveur, ça peut être un composant qui fonctionne avec tous les serveurs. Du coup si le MUC de ton serveur XMPP ne te plaît pas, tu peux en prendre un autre (je ne sais pas ce qu'il y a d'intéressant, faut chercher).
créer et administrer un salon: peu de clients le permettent et en général c'est caché sous plusieurs menus et sous menus.
Gajim et Psi le permettent sans soucis. Je pense que Poezio aussi. D'autre (comme SàT) ne le permettent pas encore (enfin créer si, il manque l'administration), mais ça va venir :). Encore une fois il faut demander
rejoindre un salon: idem.
Les clients qui ne gèrent pas MUC sont rare quand même
rejoindre un salon sans créer un compte: Poezio est le seul à ma connaissance à le proposer.
Jappix mini le permet il me semble. Pareil faut en faire la demande, on envisage de l'implémenter dans SàT, mais c'est pas prioritaire.
Du coup la plupart des gens se contentent d'un chan sur freenode, les Élites installent une tribune et quasiment seuls les développeurs XMPP utilisent les salons XMPP…
IRC est simple et efficace, et dispo partout. XMPP est beaucoup plus puissant, mais c'est pas forcément nécessaire pour un projet. De toute façon XMPP peut parler avec IRC, donc tout le monde est content :)
Ça me semble intéressant, et je suis content aussi qu'on ait des alternatives aux kickstarters et autres Ulule, surtout orienté libre.
Comme dit dans mon précédent message, c'est un moyen de financement qu'on envisage, et ce n'est pas une mauvaise idée de faire un événement autour, on va voir ce que ça donne.
bon apparemment c'est 3 sociétés (distinctes ? associées ? Appartenant à un groupe ?) de financement collaboratif.
J'ai un avis très mitigé sur la question, et même si le principe me plaît, je n'aime pas toujours la forme qu'il a. On l'envisage pour le projet sur lequel je travaille, disons qu'on veut étudier ça de près.
Quelques questions:
quel est le pourcentage réél qui va aller dans la poche des projets, et qu'est-ce qui va rester dans celle des entreprises organisatrices ?
est-ce qu'il y a des contreparties de la part des projets (goodies ou autre): beaucoup aiment ça, moi c'est un des trucs qui ne me plaît justement pas dans les formes actuelles de financement collaboratif.
qui décident de quels projets peuvent recevoir les dons ? qui décide de la répartition ?
quel intérêt pour les projets ? Je vois la mise en avant et la gestion du circuit bancaire, il y en a d'autres ?
pourquoi ne pas donner directement aux projets ? Parce qu'on me dit « donner au libre qui vous a tant donné », mais les quelques dons que j'ai fait jusqu'ici je les ai fait directement aux projets qui m'intéressaient.
et pour finir une petite remarque: je trouve ça dommage qu'il faille une campagne pour financer la soirée elle même, est-ce qu'il n'était pas possible de s'arranger avec un GUL ou autre pour avoir une salle et faire la diffusion sur le net ? J'ai l'impression que c'est un peu gâcher les dons, mais je ne connais pas tous les tenants et aboutissants, aussi des précisions ne seraient pas de trop.
Ne prenez pas mal mon message, je me pose de réelles questions sur tout ça, et j'ai déjà été approché par quelqu'un du milieu pour financer mon projet de cette façon, ce que j'ai pour le moment refusé.
Bon je ne suis pas développeur weboob (juste une petite contribution jusqu'ici, mais j'ai toujours dans les cartons un passerelle weboob/XMPP), mais allons y quand même:
weboob est principalement fait pour la ligne de commande, les applications c'est juste du bonus, et je n'ai aucunement l'impression qu'il s'agisse de bricolage, c'est plus un exemple concret de ce qu'on peut faire avec. Le code est propre, et pour connaître certains developpeurs, il y a un bon niveau technique, aucun problème là dessus, et ils sont ouverts aux suggestions/patches (par exemple un commentaire ici même sur l'arborescence des fichiers de conf pour suivre les recommandations Freedesktop a été pris en compte à la version suivante)
les backends concernent aussi des sites communautaires, ou des trucs génériques basés sur des logiciels libres, et a priori plutôt stables. Par exemple il y a un backend mediawiki, qui m'est utile pour mettre à jour automatiquement certaines pages de mon wiki (c'est d'ailleurs pour lui que j'ai contribué)
pour le reste oui c'est instable, y'a des tests automatisés (enfin s'ils tournent toujours) pour essayer de se rendre compte d'un changement le plus rapidement possible. Pour youtube, j'ai déjà vu un changement pris en compte en moins de 4 h, ce qui me semble pas mal. De plus il y a un système de dépôt local pratique pour les mises à jour (par contre ça me plaît moins qu'on puisse savoir quel backends je télécharge, mais c'est déjà le cas avec Debian et ses paquets).
au niveau juridique je ne suis pas spécialiste, mais a priori ça fait techniquement la même chose qu'un butineur. Enfin bon ça l'avenir dira ce que ça donne (ça fait quand même déjà quelques années que ça tourne)
les problèmes de sécurité sont les mêmes avec firefox/iceweasel ou Chromium ou Epiphany, etc. Il y a plus de monde sur ces projets donc plus d'yeux pour déboguer, mais aussi plus de monde pour tenter des attaques
sur le fond, c'est le hacking que tu ne comprends pas. C'est détourner un usage de son cadre fermé originel. Ça peut servir pour des tas de choses, mettre à jour un wiki automatiquement, télécharger une vidéo pour pouvoir la voir avec le lecteur de ton choix, la voir hors-ligne ou s'assurer de sa pérénité, utilisé son MUA pour aller sur DLFP, etc.
enfin pour le nom et l'esprit, je trouve personnellement le nom « weboob » bien trouvé et amusant, ce n'est pas toujours le cas pour le nom des applis ou captures qu'on voit des fois, mais ce n'est pas ce qui va me bloquer d'utiliser ce projet fort intéressant et utile. Je sais que ça gêne du monde au point de ne pas utiliser/contribuer, ça ne me choque pas non plus qu'on refuse d'utiliser pour ça (je refuse bien d'acheter dans certains magasins pour des raisons similaires). Je suis plus choqué qu'on puisse déposer un nom de tous les jours (Fenêtre, Bureau, Mot). Par contre ça commence à tourner en rond les critiques de l'esprit, si ça vous gêne à ce point, vous pouvez ignorer ou forker.
Comme tout le monde a vu ton journal, tout le monde va poster mercredi, donc tu auras plus de journaux mercredi, et donc plus de choses à lire/ton journal restera moins longtemps en tête. Du coup il y aura moins de commentaires, et suite à ton journal il vaut mieux ne pas poster mercredi… CQFD
sauf que, maintenant que j'ai posté mon commentaire, les gens vont se dire qu'il vaut mieux ne pas poster le mercredi, et du coup…
le chiffrement s2s et c2s n'est qu'une partie qui ne protège pas des administrateurs des serveurs (donc Google ici), il faut au minimum ajouter le chiffrement de bout en bout (OTR/GPG), et encore ça ne résout pas tout (on sait toujours à qui et quand on écrit - bref les informations de routage -, le volume approximatif du message, etc.).
Même en dehors de l'affaire PRISM, le fait que les messages soient en clair côté serveur peut poser problème si on ne l'administre pas nous même, ou si on n'a pas une confiance extrême en l'équipe qui administre. D'ailleurs faire administrer un serveur par quelqu'un de proche (famille, association proche, etc), peut inciter plus facilement à jeter un œil aux logs (petit(e) ami(e) jaloux par exemple).
S'ajoute à ça des problèmes qui ne sont pas forcément encore pris en compte dans XMPP: l'usage actuel des clients qui gère le chiffrage de bout en bout chiffre les messages texte, mais pas les données supplémentaires (par exemple texte riche avec XHTML-IM).
La situation semble être en passe de s'améliorer (XEP-0200 par exemple, enfin faudrait que je vois ça plus en détails pour être sûr), il faut voir comment ça évolue en particulier du côté des clients.
oui je connais ces outils (depuis peu), vu que j'envisage de les utiliser pour automatiser certains tests de SàT (j'hésite entre PhantomJS et Selenium pour le moment).
Disons que pour cette tache, le javascript n'était pas nécessaire (sauf pour iMacros, mais là vu que j'avais déjà une macro presque fonctionnelle à disposition, et que PhantomJS ou Selenium j'aurais du me taper de la doc pour les utiliser, j'ai été au plus simple), et le couple mechanize/lxml permet quand même de faire les choses rapidement (surtout que je le connais déjà, et puis c'est du Python :) ).
Ceci merci pour les liens, c'est toujours utile à connaître.
[^] # Re: Intéressant
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal cv, un petit outil pour surveiller vos copies. Évalué à 4.
Oui cv est bien utile, je viens de le mettre sur 2 des mes machines :). Sans compter que ça gère d'autre outils, que ça fonctionne une fois la copie lancée (donc idéal en cas d'oubli de barre de progression), et que ça permet de voir ce qui est en cours. Tu as l'intention de l'empaqueter sous Debian et/ou dans d'autres distros ?
# Intéressant
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal cv, un petit outil pour surveiller vos copies. Évalué à 10.
Je trouve l'astuce excellente, outil intéressant. Mais si j'ai bien compris ça ne marche que pour un gros fichier (ça cherche le fichier ouvert le plus gros), si tu copies une arborescente complète t'es marron.
J'en profite pour placer un petit outil que j'avais écrit, gcp: il est dans Debian et gère entre autres une barre de progression et l'ajout de fichiers à copier en cours de route, il y avait eu une dépêche à l'époque: https://linuxfr.org/news/gcp-un-outil-de-copie-%C3%A0-la-cp
Bon je suis tellement pris par Salut à Toi que je n'ai plus trop de temps à y consacrer (dernier commit en 2011), mais je m'en sers régulièrement et je vais peut-être me prendre une journée à l'occase pour ajouter 2/3 améliorations.
à noter aussi ((Ultra)|(Super))copier d'alpha_one_x86 dont on entend parler régulièrement ici.
[^] # Re: Twisted
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Python 3.4 beta 1 est sortie. Évalué à 2.
Ouai, enfin moi c'est au cœur de mon projet, et ça me ferait plus qu'un peu chier (je suis loin d'être le seul dans ce cas). Et je ne regrette pas du tout ce choix: Twisted m'a permis d'implémenter des idées très rapidement, les outils sont pratiques, et je trouve le tout relativement bien fait.
Les conventions de nommage, sauf erreur, c'est historique: c'était là avant la PEP 8 et ils ont gardé ensuite pour ne pas casser la compatibilité.
Pour le logging, il est parfaitement possible d'utiliser la stdlib: https://twistedmatrix.com/documents/current/core/howto/logging.html#auto3
Pour le reste c'est dommage.
[^] # Re: Twisted
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Python 3.4 beta 1 est sortie. Évalué à 2.
Ah oui, j'ai vu après coup que le message avait 2 ans. Pourquoi le fork à échoué ? Et pourquoi ne pas avoir directement proposé des patchs mainsteam ?
Je disais ça par rapport à ce genre de messages: l'API semble compatible, et Twisted devrait permettre à terme une compatibilité entre les deferred et les futures de Tulip. C'est vrai que ça serait super d'unifier un peu tout ça.
J'espère en tout cas que la multiplication des API asynchrones ne va pas provoquer un désintérêt pour Twisted, mais bon je ne m'inquiète pas trop surtout que le développement est toujours très actif.
[^] # Re: Twisted
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Python 3.4 beta 1 est sortie. Évalué à 2.
À lire aussi sur le sujet, ce billet (qui a pas loin d'un an): http://labs.twistedmatrix.com/2013/01/twisted-python-3-and-you.html
[^] # Re: Twisted
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Python 3.4 beta 1 est sortie. Évalué à 2.
Ils ont commencé le port depuis longtemps et la plupart des modules sont portés, ils cherchent à faire un port en faisant un code qui tourne à la fois sur python 2.7 et python 3, et ils ont une grosse batterie de tests pour valider ça. L'avancement peut être vu (si c'est à jour) à ces deux adresses:
https://twistedmatrix.com/trac/milestone/Python-3.x
https://twistedmatrix.com/trac/wiki/Plan/Python3
La syntaxe callback pose des problèmes à certains, personnellement je m'y suis fait et je n'ai pas tant de mal que ça à la débogguer (je la trouve même plutôt bien faite). Mais même s'il y a une API asynchrone qui arrive dans Python (qui a été faite en prenant en compte Twisted pour qu'il puisse l'intégrer si j'ai bien compris, tu en sauras sûrement plus que moi là dessus), ça n'apporte pas tous les protocoles supportés avec, avec les 11 ans d'expérience pour la gestions des subtilités, et les outils autour. Twisted est riche et mature, c'est une base solide.
En ce qui me concerne, c'est en particulier (mais pas seulement) la partie XMPP qui m'intéresse, et Ralph Meijer devrait remonter petit à petit Wokkel dans Twisted cette année.
Le fork semble tout à fait amical (je n'avais pas suivi ce fil je suis assez peu la liste de Twisted en ce moment), à lire en diagonale j'ai même l'impression qu'il va servir à porter le tronc principal.
# Twisted
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Python 3.4 beta 1 est sortie. Évalué à 3.
Ce serait déjà bien que Twisted finisse son passage à Python 3.
asyncio a été discuté sur la liste de diffusion de twisted: https://twistedmatrix.com/pipermail/twisted-python/2013-March/026700.html
# Eh beh
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Démocratie : histoire d'un malentendu. Évalué à 2.
Ça change des pubs virales et des chats qui se cassent la gueule, merci pour le lien :)
Pour ceux qui trouvent ça trop long, en résumé c'est « élections, piège à cons ». L'argumentation est intéressante, je vais essayer de trouver le bouquin (les références pour ceux que ça intéresse: Démocratie. Histoire politique d'un mot aux États-Unis et en France, Lux, 2013 - ISBN 978-2-89596-090-4).
Je ne savais pas qu'il y avait eu les assemblées d'habitants dans les villages au Moyen Âge dont il parle (à part les Communes mais on n'est plus au Moyen Âge là), ça donne envie de se renseigner plus.
En suivant Wikipédia, on tombe sur ces 2 lettres émouvantes qui montrent les opinions de 2 camps opposés:
Lettre à ma soeur militaire qui part en Afghanistan
Réponse à mon frère qui s'oppose à mon déploiement en Afghanistan
Ça fait un peu penser au Maria de Jean Ferrat, pas tant pour le contexte - qui n'est quand même pas comparable -, que pour le frère et la sœur dans les camps opposés, sûrs de leurs convictions.
décidément un intéressant personnage
[^] # Re: Si on n'a pas de compte GitHub
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Organisation de tests de sécurité pour XMPP. Évalué à 3.
ah oui en effet, j'avais pas lu le message sur github, autant pour moi.
[^] # Re: HTTPS
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Du chiffrement et de la sécurité sur LinuxFr.org (statut au 24/11/2013). Évalué à 3.
euh, si ! T'as même un petit cadenas en dessous du logo qui est ouvert ou fermé selon que tu utilises ou pas l'accès https.
[^] # Re: Si on n'a pas de compte GitHub
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Organisation de tests de sécurité pour XMPP. Évalué à 3.
ce que je veux dire, c'est outre le fait de proposer un truc sur github (il est hors de question que je me fasse un compte dessus), ça complique pas mal pour signer le manifeste. Je pense qu'un simple email aurait facilité les choses.
Alors oui peut-être qu'on peut envoyer un git-diff mais d'une ça oblige d'une à utiliser git, et de deux à chercher une adresse je ne sais où pour envoyer le patch.
Et puis pour la forme, ça aurait été pas mal de proposer un jid pour signer.
[^] # Re: Si on n'a pas de compte GitHub
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Organisation de tests de sécurité pour XMPP. Évalué à 3.
Il faut donc un dépôt git public.
[^] # Re: Ah si !
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal HowTo: suppression de compte FB. Évalué à 2.
je viens de faire le test 16 jours après la demande de suppression, mon compte a bien été supprimé…
[^] # Re: Coquille ou péssimisme ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Organisation de tests de sécurité pour XMPP. Évalué à 3.
Ah je ne retrouvais plus le nom du site web qui permettait de chercher sur pas mal de service MUC, merci à Link Mauve pour le lien: http://search.wensley.org.uk/
[^] # Re: Coquille ou péssimisme ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Organisation de tests de sécurité pour XMPP. Évalué à 3.
Pour ce qui est de l'implémentation, pour MUC c'est pas très compliqué et y'a quand un bon paquet de bibliothèques qui le gèrent déjà.
Pour la mise à l'échelle, c'est déjà répondu par ailleurs, mais je pense que les cas où ça gênent sont rares pour le moment (y'a peu de salon qui dépassent la centaine de participants, et peut de services qui dépassent la centaine de salons).
Le jour où ça sera vraiment gênant, gageons que les implémentations de solutions iront vite.
[^] # Re: Coquille ou pessimisme ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Organisation de tests de sécurité pour XMPP. Évalué à 3.
C'est juste une traduction et une expression, faut pas voir le mal partout :).
De toute façon je pense que la plupart des clients/serveurs sont chiffrés, mais il y a probablement de vieux trucs qui traînent encore et qui vont toussoter. XMPP est très répandu, y'a des chance que ça casse quelques trucs.
[^] # Re: Coquille ou péssimisme ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Organisation de tests de sécurité pour XMPP. Évalué à 4.
ça je ne pense pas, OpenFire est ultra facile à installer, Prosody pas très compliqué pour qui sait utiliser un éditeur de textes.
ejabberd est de mémoire plus compliqué mais c'est pas la mort, et je ne sais pas trop pour les autres (Tigase ?).
il y a un problème lié à la décentralisation de la liste des salons: c'est facile d'avoir la liste d'un service MUC en particulier, mais pas de tous ceux existants.
Pour l'administration des salons elle-même au niveau serveur, c'est dépendant des implémentations, faut voir au cas par cas, mais a priori tu dois avoir au moins la base (liste de tous les salons, suppression de salon, etc). Quels serveurs a tu rencontré qui ne proposent pas ça ? Faut leur demander directement si ça manque.
Il faut voir aussi qu'un service MUC peut être totalement indépendant du serveur, ça peut être un composant qui fonctionne avec tous les serveurs. Du coup si le MUC de ton serveur XMPP ne te plaît pas, tu peux en prendre un autre (je ne sais pas ce qu'il y a d'intéressant, faut chercher).
Gajim et Psi le permettent sans soucis. Je pense que Poezio aussi. D'autre (comme SàT) ne le permettent pas encore (enfin créer si, il manque l'administration), mais ça va venir :). Encore une fois il faut demander
Les clients qui ne gèrent pas MUC sont rare quand même
Jappix mini le permet il me semble. Pareil faut en faire la demande, on envisage de l'implémenter dans SàT, mais c'est pas prioritaire.
IRC est simple et efficace, et dispo partout. XMPP est beaucoup plus puissant, mais c'est pas forcément nécessaire pour un projet. De toute façon XMPP peut parler avec IRC, donc tout le monde est content :)
# ortho
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Organisation de tests de sécurité pour XMPP. Évalué à 3. Dernière modification le 21 novembre 2013 à 13:16.
arf, j'ai loupé le s/Organisations/Organisation/ dans le titre, si un modo pouvait corriger ça, merci :)
et aussi s/rentre/rendre/
[^] # Re: Oui et non
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Hackadon : Donnez au libre !. Évalué à 3.
Merci pour vos réponses.
Ça me semble intéressant, et je suis content aussi qu'on ait des alternatives aux kickstarters et autres Ulule, surtout orienté libre.
Comme dit dans mon précédent message, c'est un moyen de financement qu'on envisage, et ce n'est pas une mauvaise idée de faire un événement autour, on va voir ce que ça donne.
bon courage en tout cas.
# Oui et non
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Hackadon : Donnez au libre !. Évalué à 5. Dernière modification le 19 novembre 2013 à 16:21.
Salut,
bon apparemment c'est 3 sociétés (distinctes ? associées ? Appartenant à un groupe ?) de financement collaboratif.
J'ai un avis très mitigé sur la question, et même si le principe me plaît, je n'aime pas toujours la forme qu'il a. On l'envisage pour le projet sur lequel je travaille, disons qu'on veut étudier ça de près.
Quelques questions:
quel est le pourcentage réél qui va aller dans la poche des projets, et qu'est-ce qui va rester dans celle des entreprises organisatrices ?
est-ce qu'il y a des contreparties de la part des projets (goodies ou autre): beaucoup aiment ça, moi c'est un des trucs qui ne me plaît justement pas dans les formes actuelles de financement collaboratif.
qui décident de quels projets peuvent recevoir les dons ? qui décide de la répartition ?
quel intérêt pour les projets ? Je vois la mise en avant et la gestion du circuit bancaire, il y en a d'autres ?
pourquoi ne pas donner directement aux projets ? Parce qu'on me dit « donner au libre qui vous a tant donné », mais les quelques dons que j'ai fait jusqu'ici je les ai fait directement aux projets qui m'intéressaient.
et pour finir une petite remarque: je trouve ça dommage qu'il faille une campagne pour financer la soirée elle même, est-ce qu'il n'était pas possible de s'arranger avec un GUL ou autre pour avoir une salle et faire la diffusion sur le net ? J'ai l'impression que c'est un peu gâcher les dons, mais je ne connais pas tous les tenants et aboutissants, aussi des précisions ne seraient pas de trop.
Ne prenez pas mal mon message, je me pose de réelles questions sur tout ça, et j'ai déjà été approché par quelqu'un du milieu pour financer mon projet de cette façon, ce que j'ai pour le moment refusé.
[^] # Re: Pour weboob
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal contenus epub. Évalué à 10.
Bon je ne suis pas développeur weboob (juste une petite contribution jusqu'ici, mais j'ai toujours dans les cartons un passerelle weboob/XMPP), mais allons y quand même:
weboob est principalement fait pour la ligne de commande, les applications c'est juste du bonus, et je n'ai aucunement l'impression qu'il s'agisse de bricolage, c'est plus un exemple concret de ce qu'on peut faire avec. Le code est propre, et pour connaître certains developpeurs, il y a un bon niveau technique, aucun problème là dessus, et ils sont ouverts aux suggestions/patches (par exemple un commentaire ici même sur l'arborescence des fichiers de conf pour suivre les recommandations Freedesktop a été pris en compte à la version suivante)
les backends concernent aussi des sites communautaires, ou des trucs génériques basés sur des logiciels libres, et a priori plutôt stables. Par exemple il y a un backend mediawiki, qui m'est utile pour mettre à jour automatiquement certaines pages de mon wiki (c'est d'ailleurs pour lui que j'ai contribué)
pour le reste oui c'est instable, y'a des tests automatisés (enfin s'ils tournent toujours) pour essayer de se rendre compte d'un changement le plus rapidement possible. Pour youtube, j'ai déjà vu un changement pris en compte en moins de 4 h, ce qui me semble pas mal. De plus il y a un système de dépôt local pratique pour les mises à jour (par contre ça me plaît moins qu'on puisse savoir quel backends je télécharge, mais c'est déjà le cas avec Debian et ses paquets).
au niveau juridique je ne suis pas spécialiste, mais a priori ça fait techniquement la même chose qu'un butineur. Enfin bon ça l'avenir dira ce que ça donne (ça fait quand même déjà quelques années que ça tourne)
les problèmes de sécurité sont les mêmes avec firefox/iceweasel ou Chromium ou Epiphany, etc. Il y a plus de monde sur ces projets donc plus d'yeux pour déboguer, mais aussi plus de monde pour tenter des attaques
sur le fond, c'est le hacking que tu ne comprends pas. C'est détourner un usage de son cadre fermé originel. Ça peut servir pour des tas de choses, mettre à jour un wiki automatiquement, télécharger une vidéo pour pouvoir la voir avec le lecteur de ton choix, la voir hors-ligne ou s'assurer de sa pérénité, utilisé son MUA pour aller sur DLFP, etc.
enfin pour le nom et l'esprit, je trouve personnellement le nom « weboob » bien trouvé et amusant, ce n'est pas toujours le cas pour le nom des applis ou captures qu'on voit des fois, mais ce n'est pas ce qui va me bloquer d'utiliser ce projet fort intéressant et utile. Je sais que ça gêne du monde au point de ne pas utiliser/contribuer, ça ne me choque pas non plus qu'on refuse d'utiliser pour ça (je refuse bien d'acheter dans certains magasins pour des raisons similaires). Je suis plus choqué qu'on puisse déposer un nom de tous les jours (Fenêtre, Bureau, Mot). Par contre ça commence à tourner en rond les critiques de l'esprit, si ça vous gêne à ce point, vous pouvez ignorer ou forker.
# sauf que
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal DLFP journalyser 2.0 : pas de veille techologique le weekend. Évalué à 2.
Comme tout le monde a vu ton journal, tout le monde va poster mercredi, donc tu auras plus de journaux mercredi, et donc plus de choses à lire/ton journal restera moins longtemps en tête. Du coup il y aura moins de commentaires, et suite à ton journal il vaut mieux ne pas poster mercredi… CQFD
sauf que, maintenant que j'ai posté mon commentaire, les gens vont se dire qu'il vaut mieux ne pas poster le mercredi, et du coup…
[^] # Re: Le problème n'est pas tant le compte Google+
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Google+ recherche utilisateurs désespérément. Évalué à 10.
Eh beh, le marketing a bien marché :(
[^] # Re: Les "petits frères" de l'IETF aussi
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal L'IETF se lance dans la lutte contre l'espionnage. Évalué à 5.
le chiffrement s2s et c2s n'est qu'une partie qui ne protège pas des administrateurs des serveurs (donc Google ici), il faut au minimum ajouter le chiffrement de bout en bout (OTR/GPG), et encore ça ne résout pas tout (on sait toujours à qui et quand on écrit - bref les informations de routage -, le volume approximatif du message, etc.).
Même en dehors de l'affaire PRISM, le fait que les messages soient en clair côté serveur peut poser problème si on ne l'administre pas nous même, ou si on n'a pas une confiance extrême en l'équipe qui administre. D'ailleurs faire administrer un serveur par quelqu'un de proche (famille, association proche, etc), peut inciter plus facilement à jeter un œil aux logs (petit(e) ami(e) jaloux par exemple).
S'ajoute à ça des problèmes qui ne sont pas forcément encore pris en compte dans XMPP: l'usage actuel des clients qui gère le chiffrage de bout en bout chiffre les messages texte, mais pas les données supplémentaires (par exemple texte riche avec XHTML-IM).
La situation semble être en passe de s'améliorer (XEP-0200 par exemple, enfin faudrait que je vois ça plus en détails pour être sûr), il faut voir comment ça évolue en particulier du côté des clients.
[^] # Re: Outils mieux adaptés ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal HowTo: suppression de compte FB. Évalué à 2.
Salut Laurent,
oui je connais ces outils (depuis peu), vu que j'envisage de les utiliser pour automatiser certains tests de SàT (j'hésite entre PhantomJS et Selenium pour le moment).
Disons que pour cette tache, le javascript n'était pas nécessaire (sauf pour iMacros, mais là vu que j'avais déjà une macro presque fonctionnelle à disposition, et que PhantomJS ou Selenium j'aurais du me taper de la doc pour les utiliser, j'ai été au plus simple), et le couple mechanize/lxml permet quand même de faire les choses rapidement (surtout que je le connais déjà, et puis c'est du Python :) ).
Ceci merci pour les liens, c'est toujours utile à connaître.