Journal APPEL POUR ACTION : LES BOOBS ONT BESOIN DE VOUS *MAINTENANT*

Posté par  . Licence CC By‑SA.
40
16
fév.
2012

Le web libre, Tanguy Ortolo, Weboob et l'humanité ont besoin de vous, et je veux vraiment dire vous TOUS. L'article suivant a été écrit par moules<, président de la Weboob Fundation, homme de chaises et élu de Dieu.

Weboob a demontré que le navigateur n'était pas une fatalité. Nombreux sites ont été rendus utilisables, agréables, et accessibles (par exemple il est possible de lire les trolls énormes de DLFP sans avoir des blocs de commentaires qui font moins de 10 pixels de large).
Si des victoires ont été établies, la guerre est loin d'être terminée, et des ennemis redoutables se profilent.

Laissez-moi être très clair : ce n'est PAS hypothétique et je ne suis pas en train de parler de quelque chose qui pourrait arriver.

CECI NE DOIT PAS ARRIVER.

J'ACCUSE tout d'abord l'infameux Microsoft, même si il a enfin échoué du côté de l'utilisateur avec son navigateur Internet Explorer, il reste présent du côté serveur avec ASP.NET. Et il ne suffit pas de renommer Firefox en « Internet » pour l'éradiquer. Pourquoi est-ce tant un mal ? Car il combine un grand nombre de pratiques suboptimales.

J'ACCUSE ASP.NET (et d'autres Web Créateurs) de ne pas fournir de HTML lisible par un humain. Par là, je ne veux pas dire <div><div><div><div><div><span><br> TITRE </b><html>. Je veux dire <INPUT ID="ctl00$ContentPlaceHolder1$ctl00$ctl04$ctl00$btnImgConnexion.x">.
Même si l'on comprend l'amour de Microsoft pour les dollars, ce n'est pas raisonnable. Si cela continue, le Web pourrait ne pas s'en relever.

J'ACCUSE les Web Créateurs de sites inutilisables sans JavaScript d'alourdir leurs pages et la navigation sur celles-ci, de cacher les données à exploiter et de contribuer au réchauffement climatique (avec l'aimable participation de Firefox).
Il n'est pas normal de ne pas pouvoir soumettre un formulaire sans simuler ce que fait un code JavaScript illisible (car mal écrit ou « minifié »). Là encore, ASP.NET est un coupable chronique.
Heureusement Richard Stallman va nous libérer du JavaScript non-libre avec sa nouvelle initiative !

J'ACCUSE les Web Créateurs de sites usant de captchas d'empêcher un partage équitable (aucun rapport avec les poneys) de l'information via une mesure inefficace et pénible que ce soit pour l'utilisateur lambda que pour Weboob qui se trouve limité dans sa tâche d'automatiser les actions fastidieuses. Il s'agit d'une protection d'autant plus inutile que depuis plusieurs années, des boites douteuses permettent moyennant une modique rétribution de les résoudre à la chaîne (on se consolera en se disant que ça fait vivre une famille de petits chinois, quelque part dans le tiers monde).

J'ACCUSE les Web Créateurs de sites présentant une suite de balises sans identifiants et manquant cruellement de classe d'empêcher une localisation aisée des informations utiles présentes dans les pages, de nuire à l'accessibilité, de ne pas respecter la séparation entre les données et l'affichage.

J'ACCUSE les Web Créateurs qui ont décidé que leur site se comporterait différemment suivant l'User-Agent. Ou pas, ça permet parfois à Weboob de l'exploiter à son avantage.

Donc, merci d'exprimer votre opinion, aidez le Web à se faire boobiser, ircez, mailez et usenez que vous ne voulez pas voir ceci apparaître. Certains ont déjà commencé, après avoir participé à un des nombreux événements consacrés à Weboob. Si les décideurs pressés font le Web, ce sont les utilisateurs et les auteurs qui font le boob, et c'est le moment de le leur rappeler. VOTRE VOIX COMPTE.

Si vous êtes un journaliste, je suis immédiatement ouvert à… non je déconne, ce serait trop prétentieux !

Par contre, un Boobathon est organisé à la Fondation pour le Progrès de l'Homme le samedi 10 17 mars. Si vous aussi vous souhaitez contribuer à la libération du web, n'hésitez pas à vous manifester sur IRC (#weboob @ freenode) ou sur la mailing-list.

Enfin, si vous préférez picoler, sachez qu'en l'honneur de ses deux années d'existence, Weboob organise aujourd'hui une soirée au Petit Chat, 9 rue Saint-Denis à Paris, à partir de 19h. Les personnes intéressées sont priées de prévenir.

Merci à vous.

  • # Enfin un journal qui dénonce !

    Posté par  . Évalué à 9.

    Tout est dans le titre.

  • # Booba(r)thon & Debian

    Posté par  (site web personnel) . Évalué à 9.

    Petite précision, le boobathon ne se tiendra pas le 10 mars, comme initialement prévu (la FPH étant finalement indisponible à cette date), mais le 17 mars, c'est à dire le samedi d'après.

    Sinon le boobarthon de ce soir sera également l'occasion de fêter l'arrivée de weboob dans sid.

  • # Icones des sites

    Posté par  (site web personnel) . Évalué à 2.

    Sur le site de Weboob, les icones des modules officiels ou sites populaires sont pour la plupart modifiés. C'est par impossibilité légale de reprendre le logo je suppose?

    Pourquoi vouloir utiliser une application différente pour chaque site (un peu comme sur les applications téléphone) plutôt que leur site internet (qui par ailleurs est parfois bien fait)?

    En tous cas merci pour le boulot, notamment pour les sites bancaires où l'interface et la compatibilité avec grisbi, kmymoney et autres n'est pas toujours réussi. Cela me semble intéressant. (Pour l'instant je suis toujours a télécharger le relevé puis l'importer... pas compliqué mais cela devrait pouvoir se faire de manière automatique)

    • [^] # Re: Icones des sites

      Posté par  (site web personnel) . Évalué à 6.

      On n’utilise pas une appli différente par site, on utilise la même appli pour des sites différents. Par exemple, mes comptes dans 3 banques distinctes sont consultables simultanément, avec une interface unifiée, et exportables en plein de formats dans boobank.

    • [^] # Re: Icones des sites

      Posté par  (site web personnel) . Évalué à 6.

      Pourquoi vouloir utiliser une application différente pour chaque site

      C'est justement le but de ne pas utiliser une application pour chaque site.

      boobank pour tout les comptes banquaire
      videoob pour les sites de videos etc...

    • [^] # Re: Icones des sites

      Posté par  (site web personnel) . Évalué à 6.

      C'est par impossibilité légale de reprendre le logo je suppose?

      Oui. Le logo original n'est de toute façon souvent pas libre, donc difficile de l'inclure dans les sources. Et quitte à refaire le logo, autant s'amuser un peu (et le côté parodique permet de profiter d'une exception au droit d'auteur je suppose).

      Cela changera peut-être dans le futur, puisque les modules sont maintenant capables de récupérer le « favicon », tout en nous évitant de le distribuer.

  • # Bonnes pratiques vs liberté

    Posté par  . Évalué à 10.

    Bon, je comrpends un peu le pourquoi du journal, mais je pense que tous les points de vue se défendent.

    1) Les mauvais sites web sont souvent dus à l'incompétence des programmeurs. C'est comme le mauvais code. On a parfaitement le droit d'accuser les gens d'être mauvais, malheureusement, il n'y a pas vraiment de remède à l'incompétence.

    2) Il y a un conflit d'intérêt évident entre les concepteurs des sites et les programmeurs de scripts. Dans la grande majorité des cas, l'objectif d'un site web est d'être visité et d'apparaitre sur l'écran de l'utilisateur exactement comme le concepteur du site l'a voulu, avec l'ergonomie qu'il a développé, avec les mentions qu'il considère comme importantes (y compris des trucs comme "contenu disponible sous CC-BY-SA"), avec la charte graphique, les logos, les marqueurs visuels qui ont couté très cher à mettre en place, et éventuellement avec la pub qui assure des revenus. Même si on peut ne pas être d'accord avec cette philosophie, il parait naturel que les concepteurs des sites n'aient aucun intérêt à faciliter le travail des outils destinés à trier le contenu, modifier la charte graphique, ou retirer les pubs. Il pourrait même sembler à certains qu'il pourrait même etre profitable de tout faire pour que ça ne soit pas possible.

    3) Le HTML a une caractéristique particulière, c'est qu'il impose un modèle "open source" (je n'ai pas dit libre). Il existe tout plein de libristes qui admettent l'existence du logiciel proprivateur ; et dans cette optique, les méthodes d'obfuscation du HTML ne seraient qu'un moyen de mimer ce que pourrait être un site propriétaire : l'utilisateur ne dispose que d'une forme "binaire", le concepteur ne lui donne pas la possibilité d'étudier son fonctionnement ou de le modifier pour l'adapter à ses besoins.

    4) Si les concepteurs de sites doivent quelque chose à leur visiteur, c'est l'efficacité de l'interface ou la continuité du service par exemple. Ce n'est pas du tout la stabilité et la "propreté" de la structure du site. Il est par exemple parfaitement admissible pour un webmaster, même pour un projet libre, de modifier la structure du site et l'arborescence des liens profonds. Ça casse des liens, c'est triste, mais la liberté de faire évoluer son site est fondamentale, on ne peut pas être prisonnier de ses visiteurs, et on a le droit de tout changer (de manière équivalente, on peut décider de ne pas assurer la compatibilité d'une nouvelle version d'un logiciel avec les anciennes, ce n'est pas immoral).

    Au final, je comprends que les gens qui s'investissent dans weboob et dans d'autres projets similaires soient gonflés par tous ces problèmes et qu'ils préfèreraient que les concepteurs de sites pensent à eux, mais d'un autre côté, ils l'ont choisi : ils cherchent à utiliser un outil mis à leur disposition d'une manière qui n'était pas prévue (et peut-être même pas admise) par son concepteur. Je me vois mal aller dire à Wirlpool "j'ai démonté le capot du lave-vaisselle et j'ai mis ma teub dans le trou A8, mais il y a le rouage de la pale rotative qui passe devant, c'est vraiment un deisgn de merde et je ne peux pas utiliser l'appareil comme je le souhaite". Quand on veut jouer au plus malin, on doit l'assumer jusqu'au bout...

    • [^] # Re: Bonnes pratiques vs liberté

      Posté par  (site web personnel) . Évalué à 2.

      Concernant le point 3.
      Tu as des exemples de sites "obfuscés" ? Car en général je n'en vois pas. Je dirais même qu'il y a trois grandes catégories de sites :

      • les faits à la main ou avec de bons outils, propres et lisibles (une variante supprimant les espaces inutiles pour gain de bande passante n'est pas obfuscé, il ne faut pas confondre les deux)
      • les générés depuis un outil : on arrive à des choses idiotes (genre 60% ou plus des caractères de la page sont des espaces / retour à la ligne, c'est illisible parce que le programme employé est mal fait, l'outil pouvant être un script php fait n'importe comment). On met dedans ASP.Net, l'objectif n'est pas de rendre les choses illisibles mais de faire différemment, d'ajouter des informations inexistantes dans l'html, souvent en vue d'une communication avec le serveur
      • les plus marrants, finalement c'est un sous ensemble des deux premiers, c'est le code commenté ! Outre le fait que c'est de la bande passante perdue, c'est plutôt cool lorsque c'est sur des sites importants et que ça permet d'accéder à des fonctionnalités "masquées" car commentées (le mieux étant les commentaires dans le js en général)

      Mais en fait je ne vois jamais de sites volontairement illisibles pour empêcher d'étudier le fonctionnement ou le modifier. D'ailleurs, étudier le fonctionnement de quoi ? (sachant que n'importe quel outil de dev, firebug et les pendants ie / chrome) sont capables d'afficher le html propre). Et aussi, modifier quoi pour ces propres besoins ?

      • [^] # Re: Bonnes pratiques vs liberté

        Posté par  . Évalué à 6.

        Tu as des exemples de sites "obfuscés" ?

        Le meilleur exemple que je connaisse c'est des noms d'images codés qui bougent tout le temps pour qu'adblock ne les trouve pas. Appeler tes pubs c342sdx.jpg , ça ressemble fort à de l'obfuscation.

        Un autre exemple serait les interfaces 100% flash, même si je ne sais jamais si c'est volontaire ou simplement attribuable à la stupidité.

        • [^] # Re: Bonnes pratiques vs liberté

          Posté par  . Évalué à 3.

          Attention à ne pas voir le mal partout quand même : a ce compte là on pourrait aussi dire que linuxfr fait dans l'obfuscation : on trouve très vite application-c4022eed62edce864ce4270e8ed909e9.css dans le code de cette page , selon toi est-ce aussi de l'obfuscation ?

      • [^] # Re: Bonnes pratiques vs liberté

        Posté par  . Évalué à 1.

        trois grandes catégories de sites

        Tu as oublié tous ceux qui génèrent une partie du HTML par du javascript.

        Exemple : www.google.fr. Ils n'ont pas de </body> ni de </html>. je ne sais pas si c'est généré par javascript, oublié, ou omis pour mise à jour périodique de la page...

    • [^] # Re: Bonnes pratiques vs liberté

      Posté par  (site web personnel) . Évalué à 10.

      "j'ai démonté le capot du lave-vaisselle et j'ai mis ma teub dans le trou A8"

      Ahahaha. Ptite bite.

      • [^] # Re: Bonnes pratiques vs liberté

        Posté par  . Évalué à 2.

        Quand on veut jouer au plus malin, on doit l'assumer jusqu'au bout...

        Ben non, il peut pas:

        Ahahaha. Ptite bite.

    • [^] # Re: Bonnes pratiques vs liberté

      Posté par  (site web personnel) . Évalué à 4.

      Il y a un conflit d'intérêt évident entre les concepteurs des sites et les programmeurs de scripts.

      C'est vrai, mais ce n'est pas une fatalité. Je serai prêt à payer un abonnement modique pour avoir accès à une bonne API. Cela devrait compenser par exemple les pertes de revenus liés à la publicité. De plus, fournir une information par une API coûte largement moins cher que de fournir un site complet.
      Et je serai prêt à payer encore plus pour un module weboob maintenu par le site en question (et si les choses sont bien faites, le site pourrait ajouter un cache local permettant de diminuer le « coût » de weboob).

      Le HTML a une caractéristique particulière, c'est qu'il impose un modèle "open source"

      Je vois ce que tu veux dire. On a pu rencontrer du HTML bien pourri (notamment les sites de banques où il faut y aller de manière quasiment heuristique) et arriver à en faire quelque chose. Cependant le code JavaScript, surtout minifié, est une autre paire de manches.

      la liberté de faire évoluer son site est fondamentale, on ne peut pas être prisonnier de ses visiteurs

      Je n'ai rien contre leur liberté, mais je trouve justement étrange le peu d'attachement à la stabilité et la rétrocompatibilité des sites internet, alors que c'est beaucoup plus répandu dans le logiciel « lourd ». C'est d'ailleurs ce qui a poussé la création du système de mise à jour des modules dans Weboob. On est attachés à la stabilité des applications et de l'API (du moins dans une même version majeure), mais pour les modules on est obligés de s'aligner sur les sites.

      • [^] # Re: Bonnes pratiques vs liberté

        Posté par  . Évalué à 3.

        je trouve justement étrange le peu d'attachement à la stabilité et la rétrocompatibilité des sites internet, alors que c'est beaucoup plus répandu dans le logiciel « lourd »

        La rétrocompatibilité des liens peut en effet poser problème (c'est même certainement assez pénalisant pour le référencement), mais il faut bien avouer que personne se s'attend à avoir un internet pérenne. Même dans le libre ; prends par exemple tous les rapports de bugs avec une capture d'écran hébergée chez un truc gratuit qui supprime les fichiers au bout de 30 jours, les liens cassés vers les tutoriels sur comment installer StarOffice sur Mandrake... Le web ne peut pas vivre figé, on peut le regretter ou non, mais l'usage veut qu'un lien cassé soit quelque chose d'acceptable.

        Pour les changements d'API, c'est en théorie complètement transparent pour l'utilisateur "normal" ; si tu passes par Weboob, c'est une autre affaire, mais ce n'est pas une utilisation "normale".

    • [^] # Re: Bonnes pratiques vs liberté

      Posté par  . Évalué à 3.

      malheureusement, il n'y a pas vraiment de remède à l'incompétence.

      Un coup sec derrière la nuque ?

      il parait naturel que les concepteurs des sites n'aient aucun intérêt à faciliter le travail des outils destinés à trier le contenu, modifier la charte graphique, ou retirer les pubs. Il pourrait même sembler à certains qu'il pourrait même etre profitable de tout faire pour que ça ne soit pas possible.

      Dans le cas d'une banque en ligne ou d'un service (pseudo) public, c'est inacceptable.

      Dans le cas des logiciels libres (mediawiki, redmine, linuxfr, etc.), il n'y a pas de volonté manifeste (normalement) d'éviter ce genre de comportement.

      Les autres sites, à la limite, on pourrait comprendre dans certains cas.

      ils cherchent à utiliser un outil mis à leur disposition d'une manière qui n'était pas prévue[...] Quand on veut jouer au plus malin, on doit l'assumer jusqu'au bout...

      Est ce que tu penses que les webmasters avaient prévu adblock, noscript et autres ? Penses-tu qu'adblock soit une mauvaise chose ?

      Le FN est un parti d'extrême droite

      • [^] # Re: Bonnes pratiques vs liberté

        Posté par  . Évalué à 3.

        Penses-tu qu'adblock soit une mauvaise chose ?

        Bien sûr que non, mais je ne trouve pas anormal que certains sites tentent de gêner le fonctionnement d'Adblock. C'est un petit jeu pas très productif, mais c'est la vocation de tels systèmes de jouer au chat et à la souris.

  • # Captcha

    Posté par  . Évalué à 5.

    • [^] # Re: Captcha

      Posté par  . Évalué à 3.

      A price of $1 per 1000 correct CAPTCHAs

      Ce qui serait super ironique et amer, ce serait que captchatrader.com soit en fait une boite appartenant à une major d'holywood.

  • # captchas

    Posté par  (site web personnel) . Évalué à 3.

    J'ACCUSE les Web Créateurs de sites usant de captchas [...] une mesure inefficace et pénible que ce soit pour l'utilisateur lambda que pour Weboob qui se trouve limité dans sa tâche d'automatiser les actions fastidieuses.

    Weboob peux juste montrer les captchas à l'écran et demander à l'utilisateur de le « résoudre ».

    Il pourrait aussi s'interfacer avec une librairie tel que http://caca.zoy.org/wiki/PWNtcha ou http://www.brains-n-brawn.com/default.aspx?vDir=aicaptcha (ou autre)

    • [^] # Re: captchas

      Posté par  . Évalué à 3. Dernière modification le 16 février 2012 à 12:04.

      Il y a justement un système de callbacks qui permettent aux modules de faire des prompts à l'utilisateur (en cli ou graphiquement, suivant la nature de l'application). Les modules n'ont pas encore été confronté à des sites présentant des captcha (ou alors les résout tout seul, comme pour adopteunmec), donc ce mécanisme n'est pas encore utilisé.

      Mais demander à l'utilisateur de résoudre la captcha empêche l'automatisation des tâches.

      Pour ce qui est de PWNtcha, il ne supporte qu'un set réduit de captchas, dans lequel n'est pas inclus recaptcha qui est quand même le plus utilisé.

      • [^] # Re: captchas

        Posté par  . Évalué à 3.

        Mais demander à l'utilisateur de résoudre la captcha empêche l'automatisation des tâches.

        J'ai loupé un épisode ou c'est plus ou moins exactement l'objectif?

        • [^] # Re: captchas

          Posté par  (site web personnel) . Évalué à 3.

          le captcha n'est pas là pour éviter l'automatisation des tâches, il est là pour éviter les bots de spam / virus.
          L'automatisation en soit ne pose pas de problème (genre aller récupérer ses comptes tout seul comme un grand).
          En tout cas c'est comme ça que, historiquement, je note l'arrivée des captcha (par exemple verrouillage des commentaires de blogs)

          • [^] # Re: captchas

            Posté par  . Évalué à 4.

            Eh bien va voir sur Wikipédia par exemple :

            Un captcha est une forme de test de Turing permettant de différencier de manière automatisée un utilisateur humain d'un ordinateur.

            Le captcha n'a qu'un seul but : s'assurer qu'il y a une personne physique derrière l'écran. De mon point de vue, c'est exactement synonyme à "empêcher l'automatisation d'une tâche".

            Éviter le spam dans les commentaires des forums par exemple, c'est une application du captcha. Il y en a beaucoup d'autres : limiter le nombre de fichiers téléchargés sur megaupload rapidshare, par exemple.

            Donc, ce que tu critiques, c'est une utilisation injustifiée du captcha : on bloque l'automatisation d'une tâche que tu souhaiterais automatiser.

            On pourrait trouver plein de justifications possibles : gêner une éventuelle tentative de deviner le mot de passe, ou simplement empêcher une utilisation par API qui est vendue aux professionnels.

            • [^] # Re: captchas

              Posté par  . Évalué à 4.

              Tu confonds but et moyen.

              99.99% des gens mettent des captchas pour éviter le spam.

              Le reste, je doute qu'il y aient réfléchi outre mesure.

              Le FN est un parti d'extrême droite

            • [^] # Re: captchas

              Posté par  (site web personnel) . Évalué à 3.

              s'assurer qu'il y a une personne physique derrière l'écran. De mon point de vue, c'est exactement synonyme à "empêcher l'automatisation d'une tâche".

              Ben non, justement, c'est pas du tout synonyme.

              Si je suis physiquement derrière mon écran mais que je lance un script qui me connecte sur le site de ma banque, récupère mon solde et l'affiche dans conky, il s'agit bien de l'automatisation d'une tâche. Pourtant il y a quelqu'un physiquement derrière l'écran.

              Par contre la définition wikipédia est bien meilleurs, car ce n'est pas du tout le fait qu'il y ait quelqu'un ou non derrière l'écran, il s'agit de savoir qui exécute les actions. En ce sens oui ça permet d'interdire les automates. Mais ce n'est pas pour autant, de mon point de vue, l'objectif. L'objectif réel étant d'interdire le spam. La sélection automate / humain n'étant finalement qu'un moyen technique d'y parvenir, même si on met rajoute des faux positifs (interdiction d'automates non néfastes ou interdiction à des personnes n'arrivant pas à décripter les captcha) et des vrai négatifs (je sais pas si ça ce dit) (autorisation d'automates capables de lire les captcha).

              • [^] # Re: captchas

                Posté par  . Évalué à 1.

                C'est un faux négatif. Un vrai négatif, ce serait de correctement laisser se connecter un humain.

    • [^] # Re: captchas

      Posté par  (Mastodon) . Évalué à 2. Dernière modification le 16 février 2012 à 12:05.

      Weboob marchant en ligne de commande / scripts, ça va pas être facile quand même.

      Et si c'est pour les résoudre automatiquement, autant les supprimer définitivement alors !

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: captchas

        Posté par  . Évalué à 5.

        Si c'est du jpeg, tu peux le convertir en ascii-art avec jp2a. Après, ça devient un peu sportif mais ça reste possible :-)

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: captchas

          Posté par  (Mastodon) . Évalué à 2.

          Oui ou libcaca doit faire ça aussi non ? Sauf si c'est que pour les videos ?

          En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

          • [^] # Re: captchas

            Posté par  (site web personnel) . Évalué à 4.

            Déjà que la moitié des captchas sont difficilement lisibles dans leur forme original, j'imagine pas ce que ça donne en ASCII :-D

            • [^] # Re: captchas

              Posté par  . Évalué à 7.

              excuser moi, je vais de ce pas déposé un brevet: la captcha en ascii art.

      • [^] # Re: captchas

        Posté par  (site web personnel) . Évalué à 3. Dernière modification le 16 février 2012 à 14:46.

        w3m (avec le paquet w3m-img sous debian) parviens à afficher une image dans un terminal. Exemple : Exemple w3m-img

        • [^] # Re: captchas

          Posté par  . Évalué à 2.

          fbi (fbida sous Arch Linux) affiche aussi les images en TTY.

        • [^] # Re: captchas

          Posté par  . Évalué à 1.

          C'est quoi le truc? J'ai installé w3m-img et lancé w3m dans Konsole, mais toujours pas d'images.

          • [^] # Re: captchas

            Posté par  (site web personnel) . Évalué à 2.

            Je pense que ça dépend du terminal. Chez moi, en TTY, ça marche bien. Dans xterm, uxterm, et lxterm (et je suppose tous les autres *xterm), les images s'affichent bien également. Dans terminator et gnome-terminal les images s'affichent presque bien. Dans lxterminal et xfce4-terminal, les images ne s'affichent pas. ('pas essayé konsole par contre)

  • # plus direct

    Posté par  . Évalué à 6. Dernière modification le 16 février 2012 à 12:24.

    Au lieux d'accuser les développeur web d'éssayer de faire des sites utilisables sur les différent navigateurs web.
    Accuse les de ne pas fournir d'api rest/web-service/boob-service/non-http standardisé, libre et bien documenté.
    C'est plus mieux non?
    n'hésitez pas à me moinser(attention c'est de la psychologie inversé) si de telles choses existes.

    • [^] # Re: plus direct

      Posté par  . Évalué à 7.

      Au lieux d'accuser les développeur web d'éssayer de faire des sites utilisables sur les différent navigateurs web.
      Accuse les de ne pas fournir d'api rest/web-service/boob-service/non-http standardisé, libre et bien documenté.

      Voire, de ne pas proposer le même service via un autre protocole. Typiquement, un moteur de forum (style phpBB) pourrait très bien avoir un backend NNTP, pour ceux qui préfèrent. Ou bien un plan de réseau de transport pourrait être disponible dans sous formes de fichiers vectoriels avec rsync (afin de ne télécharger que les différences en cas de modifications).

      Ça existe déjà pour certains cas : recevoir un mail en cas de réponse à un sujet de discussion, rejoindre un salon IRC soit via une appli Web soit avec un client IRC, la compatibilité du chat Facebook© avec les clients XMPP..

      Ce serait bon de généraliser ce type de "ponts" afin que le Web, et HTTP, ne soient plus un chemin imposé, si le service est naturellement convertible, côté serveur, dans un protocole bien adapté.

      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

      • [^] # Re: plus direct

        Posté par  . Évalué à 1.

        Entre les forums web et nntp la différence d'un point de vu fonctionnel est énorme. Ce n'est pas parce que les deux sont des forums qu'ils ont les mêmes fonctionnalités.

        Par exemple, je ne crois pas que tu puisse avec nntp, fusionner/scinder des fils, en marquer comme résolu (ajouter [résolu] comme le font certains forum n'est pas très agréable et complexifie la classification). Je ne crois pas non plus que tu puisse faire de l'édition après envoie.

        Mais oui ce serait bien que nntp évolue pour pouvoir faire plus de choses.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: plus direct

          Posté par  . Évalué à 1.

          Entre les forums web et nntp la différence d'un point de vu fonctionnel est énorme. Ce n'est pas parce que les deux sont des forums qu'ils ont les mêmes fonctionnalités.

          Oui, je suis d'accord. D'un autre côté, vu qu'à 95% l'usage est le même (rechercher - lire - répondre - citer), c'est idiot de gaspiller autant de ressources en MySQL - PHP - Apache - javascript - navigateur Web juste pour les 5% restants. Pas tant d'un point de vue économique ou écologique que dans une optique d'a-centralisation d'Internet (avec une ligne ADSL et un modem-routeur en ARM je peux faire tourner un node NNTP, pas un forum phpBB).

          Ce qui fait que je suis d'accord avec la solution que tu proposes :

          Mais oui ce serait bien que nntp évolue pour pouvoir faire plus de choses.

          Pour que les anciens protocoles évoluent il faudrait aussi un peu plus d'utilisation.. pour l'instant, la seule chose qui évolue activement sur Internet ce sont les couches de base (IP de v4 vers v6, des ajouts de sécurité sur DNS, BGP).. et le format "HTML" avec tout son contenu (vidéo, images, scripts). C'est triste.

          THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

          • [^] # XMPP

            Posté par  . Évalué à 4.

            Oui, je suis d'accord. D'un autre côté, vu qu'à 95% l'usage est le même (rechercher - lire - répondre - citer), c'est idiot de gaspiller autant de ressources en MySQL - PHP - Apache - javascript - navigateur Web juste pour les 5% restants. Pas tant d'un point de vue économique ou écologique que dans une optique d'a-centralisation d'Internet (avec une ligne ADSL et un modem-routeur en ARM je peux faire tourner un node NNTP, pas un forum phpBB).

            On constate tout de même des évolutions, par exemple XMPP, qui s'est fait une place tout seul, et évolue grâce aux XEP.

            Il est aussi intéressant de voir qu'XMPP a donné lieu à d'autres protocoles par son extensibilité et sa qualité.

            Cependant, ces protocoles dérivés restent des protocoles dédiés à un programme, et non à une tâche. Salut à Toi et Jappix sont deux protocoles dérivés d'XMPP, mais ils ne sont (à ma connaissance extrêmement limitée) compatibles entre eux du point de vue des fonctionnalités relatives au réseau social. Peut-être un jour verra-t-on une une plus grande standardisation entre ces deux (ce n'est qu'un exemple).

            XMPP commence à servir de socle à de nouveaux protocoles, peut-être semble-t-il avoir une certaine flexibilité, comme HTTP et HTML/etc. en a une, qui a conduit à ce qu'il soit utilisé pour tout et n'importe quoi, même quand c'est sous-optimal. Certains se décarcassent à faire évoluer HTTP et HTML en ajoutant SPDY/WebSockets, la vidéo, WebGL, le stockage hors-ligne, la géolocalisation, etc. mais c'est signe qu'on manque d'un certain nombre de protocoles plus adaptés, et surcharger HTTP/HTML uniquement pour cette raison est une erreur.

            Si XMPP commence vraiment à prendre plus d'ampleur, c'est bien, mais il ne faudrait pas faire la même erreur que la sur-utilisation d'HTTP.

            • [^] # Re: XMPP

              Posté par  . Évalué à 1.

              On constate tout de même des évolutions, par exemple XMPP, qui s'est fait une place tout seul, et évolue grâce aux XEP.

              Par curiosité : où donc ? Parce qu'à part Gtalk (que je ne vois utilisé nulle part…), je ne vois pas où il a pu se faire une place.

              Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

              • [^] # Re: XMPP

                Posté par  . Évalué à 2.

                Ça ne se voit pas mais il est utilisé par facebook aussi (pour le chat et en interne).

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: XMPP

                  Posté par  . Évalué à 2. Dernière modification le 17 février 2012 à 12:56.

                  Ainsi que la messagerie Microsoft, et celle d'Apple. Je pense qu'il ne veut pas le(s) compter car il n'y a pas la fédération. Facebook et le reste du monde ne sont pas dans la même composante connexe bien qu'ils utilisent tous les deux XMPP.

                  • [^] # Re: XMPP

                    Posté par  . Évalué à 2.

                    Ce n'est pas une preuve que XMPP est de plus en plus utilisé ?

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # Re: XMPP

                      Posté par  . Évalué à 4.

                      Si, mais cela diminue profondément son intérêt.
                      C'est un peu comme si chaque fournisseur d'email ne permettait de communiquer qu'avec les autres utilisateurs de ce même fournisseur. C'est trop local. Le fait que ça utilise XMPP n'est qu'un "détail d'implémentation". Ils auraient aussi bien pu inventer leur propre protocole et en publier les spécifications que ça n'aurait fait presque aucune différence.

                      • [^] # Re: XMPP

                        Posté par  . Évalué à 2.

                        L'objectif était de montrer la stature que prend ce protocole notamment grâce à sa flexibilité.

                        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: XMPP

              Posté par  (site web personnel, Mastodon) . Évalué à 4.

              Cependant, ces protocoles dérivés restent des protocoles dédiés à un programme, et non à une tâche. Salut à Toi et Jappix sont deux protocoles dérivés d'XMPP, mais ils ne sont (à ma connaissance extrêmement limitée) compatibles entre eux du point de vue des fonctionnalités relatives au réseau social. Peut-être un jour verra-t-on une une plus grande standardisation entre ces deux (ce n'est qu'un exemple).

              Alors petite précision à ce sujet. On est, et on cherche à être compatibles entre nous au sujet de nouvelles fonctionnalités (celle qui me vient principalement en tête est le microblogage); et pour ce on s'appuie sur des XEP qui sont en cour d'élaboration, et qui ne sont donc pas encore des standards (Celle ci pour ceux que ça intéresse). La standardisation et donc la compatibilité entre client est un point important que nous ne voulons pas perdre.

              Cependant, les fonctionnalités étant nouvelles, il y a aussi des expérimentation. Buddy Cloud par exemple élabore son propre protocole pour le microblogage. Je les ai rencontré au FOSDEM, ils envisagent la standardisation, mais à terme, le but est de tester avant dans leur coin, et de le proposer si c'est valable.

              À ceci s'ajoutent les fonctionnalités qui ne sont pas standards. Salut à Toi par exemple propose la gestion des droits par groupes (ce que Google appelle les cercles, même si ça existait dans SàT avant que G+ ne soit publique). Étant à ma connaissance le seul projet basé sur XMPP à permettre ça (sinon Diaspora permet quelque chose de similaire que eux appellent aspects), ce n'est pas encore un standard. Mais je pense que ça la deviendra à terme. Pour le moment ça utilise une méthode bricolée qui ne fonctionne qu'avec Openfire, il est prévu de revoir ça très rapidement (c'est d'ailleurs ma prochaine chose dans ma TODO) pour que ça fonctionne de manière plus générique.

              Donc pour résumer, oui on est standard et on ne fait pas de « sous protocole propriétaire »: le microblogage Jappix (ou MOVIM), est compatible avec celui de SàT.
              Par contre il y a des différence sur les terrains expérimentaux, parce que justement c'est expérimental. Mais le but est pour la plupart des projet de standardiser les nouveauté. Seulement le processus de standardisation est long, et changer un protocole a des conséquences, c'est pour ça qu'il peut y avoir des différence entre un projet qui implémente une nouveauté, et la version standard (l'exemple le plus connu est celui de Jingle version Google qui diffère du Jingle standardisé: Google passe à la version standard, mais ça ne se fait pas en un claquement de doigts).

              • [^] # Re: XMPP

                Posté par  . Évalué à 2. Dernière modification le 17 février 2012 à 13:02.

                On est, et on cherche à être compatibles entre nous au sujet de nouvelles fonctionnalités (celle qui me vient principalement en tête est le microblogage); et pour ce on s'appuie sur des XEP qui sont en cour d'élaboration, et qui ne sont donc pas encore des standards (Celle ci pour ceux que ça intéresse). La standardisation et donc la compatibilité entre client est un point important que nous ne voulons pas perdre.

                Mes excuses, je ne savais pas (faute d'intéressement et d'utilisation), c'était donc un mauvais exemple. J'aurais pu parler des différentes solutions de surveillance de serveurs basées sur XMPP, mais hélas, je n'en sais pas plus non plus, peut-être qu'également il y a concertation entre celles-ci pour que des standards de supervisions basés sur XMPP émergent.

          • [^] # Re: plus direct

            Posté par  . Évalué à 1.

            […] c'est idiot de gaspiller autant de ressources en MySQL - PHP - Apache - javascript - navigateur Web juste pour les 5% restants.

            Les serveurs nntp n'utilisent pas de base de données ? Si c'est le cas c'est probablement qu'ils ont peut d'utilisateurs …

            Pour que les anciens protocoles évoluent il faudrait aussi un peu plus d'utilisation.. pour l'instant, la seule chose qui évolue activement sur Internet ce sont les couches de base (IP de v4 vers v6, des ajouts de sécurité sur DNS, BGP).. et le format "HTML" avec tout son contenu (vidéo, images, scripts). C'est triste.

            C'est un cercle vicieux, mais à la base je crois savoir que nntp était très utilisé (il y a 15 ou 20 ans). Peut être que c'est à l'IETF de se remettre en cause plutôt qu'aux utilisateurs.

            L'énorme avantage du web, le truc qui fait que ça a tout écrasé c'est les moteurs de recherche. Si linuxfr était un serveur nntp comment ferais-tu pour savoir qu'il existe ?

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: plus direct

              Posté par  (site web personnel) . Évalué à 3.

              Si linuxfr était un serveur nntp comment ferais-tu pour savoir qu'il existe ?

              Ça ne semblait pas si obscur à l'époque, ceci dis je ne sais plus comment j'était tombé dessus, en parcourant la hierarchie peut être.

              https://linuxfr.org/users/juke/journaux/acces-nntp-linuxfr

              • [^] # Re: plus direct

                Posté par  . Évalué à 2.

                Parcourir une arborescence pour rechercher des forum intéressant c'est pas super agréable et le problème d'une arborescence c'est que c'est centralisé et que pleins de forum pourraient aller dans plusieurs branches.

                Il faudra de toute manière publier les messages sur le web pour gagner en visibilité et que des nouveaux puissent faire des recherches sur le forum sans inscription et sans télécharger l'ensemble des messages.

                Comment ça se passe avec nntp ? Les messages restent sur le serveur ou ils sont téléchargés ? S'ils sont téléchargés, avec un forum double-pile web/nntp ne me semble pas possible sans brider de manière importante la partie web (impossible de retoucher/déplacer un message après envoie).

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: plus direct

                  Posté par  (site web personnel) . Évalué à 3.

                  Parcourir une arborescence pour rechercher des forum intéressant c'est pas super agréable

                  Passer par son navigateur non plus car ça ne permet pas de bénéficier d'un bon correcteur orthographique.

                  C'est pourtant ce que propose linuxfr sur les forums.

                  le problème d'une arborescence c'est que c'est centralisé

                  L'arborescence en elle même est centralisée, mais usenet ne l'est pas.

                  pleins de forum pourraient aller dans plusieurs branches.

                  Je vois pas de contre indications à être dans plusieures branches.

                  Il faudra de toute manière publier les messages sur le web pour gagner en visibilité

                  C'est intéressant de publier sur plusieures plateforme, ou de faire une client web effectivement, comme il peut être intéressant pour certaines personnes de consulter leurs mails via le web.

                  Comment ça se passe avec nntp ? Les messages restent sur le serveur ou ils sont téléchargés ? S'ils sont téléchargés, avec un forum double-pile web/nntp ne me semble pas possible sans brider de manière importante la partie web (impossible de retoucher/déplacer un message après envoie).

                  Les mêmes « problemes » se posent via le web, comment retouche/déplace (RAIVI-SIONISTE !!! ) un message après envoi alors que le lecteur l'a téléchargé ?

                • [^] # Re: plus direct

                  Posté par  . Évalué à 1.

                  Parcourir une arborescence pour rechercher des forum intéressant c'est pas super agréable et le problème d'une arborescence c'est que c'est centralisé et que pleins de forum pourraient aller dans plusieurs branches.

                  Si mes souvenirs sont bons, j'utilisais des recherches sur la hiérarchie et nom un parcours à la main (les noms étaient suffisamment explicites), pour ensuite souscrire aux sujets qui m'intéressaient. Je trouve qu'un des avantages était que l'info était moins dispersée (sans doute parce que moins nombreuse aussi).

            • [^] # Re: plus direct

              Posté par  (Mastodon) . Évalué à 6.

              Les serveurs nntp n'utilisent pas de base de données ?

              En général non.

              Soit ça utilise directement le système de fichier : fr.usenet.divers devient $NEWS/fr/usenet/divers/, chaque post étant un fichier dont le nom peut être du genre MD5(MId), avec éventuellement des fichiers d'index.

              Soit c'est une sorte de système de fichier placé dans un gros fichier-blob, optimisé spécialement pour un spool Usenet. Ce qui se rapproche un peu d'un bon vieil ISAM des années 80 ;)

              Plus de détails (pour INN) ici ou .

          • [^] # Re: plus direct

            Posté par  . Évalué à 2.

            avec une ligne ADSL et un modem-routeur en ARM je peux faire tourner un node NNTP, pas un forum phpBB

            Un node NNTP connecté avec personne, oui, c’est possible, mais ça a pas grand intérêt.

            Par contre, si tu veux faire du peering avec un node usenet, m’est avis qu’en tant que particulier tu n’en auras jamais les moyens.

    • [^] # Re: plus direct

      Posté par  (Mastodon) . Évalué à 7.

      J'ai rien compris à ta "psychologie inversée", alors dans le doute, j'ai moinsé.

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: plus direct

        Posté par  . Évalué à 8.

        Dans le doute, toujours moinser.

        Depending on the time of day, the French go either way.

    • [^] # Re: plus direct

      Posté par  . Évalué à 2.

      Je te moinsse par principe; je vais m'expliquer.

      Dans ce cas particulier, je suis le dev qui s'est coltiné ce site, et j'ai contacté l'éditeur pour lui annoncer mes intentions, et lui demander si il existait une interface web-service ou autre pour automatiser la chose. Je n'ai pas eu de réponse. En même temps, ce ne serait pas la première fois qu'un formulaire de contact ne fonctionne pas…

      Ensuite, sur les aspects techniques, avoir 3 balises DOCTYPE et 4 balises html dans une même page, c'est sale. Avoir un flux rss référencé dans la page qui ne fonctionne pas (erreur serveur) c'est mal. Quoi qu'on en dise. N'avoir qu'un seul formulaire pour l'ensemble des actions, ça va à l'encontre de tout, et surtout de la simplicité, même pour les devs eux-mêmes.

      Et l'incompétence, je suis d'accord avec celui qui commente en disant "un coup sec derrière la nuque". J'en ai marre de me taper des gros nuls ("des experts") au bureau tous les jours.

  • # Norme ?

    Posté par  . Évalué à 2.

    Il me semblait que la norme imposait que le site soit lisible pour les mals-voyants. Si c’était effectivement le cas, votre boulo serait plus simple… j’ai déjà envoyé des mails d’insulte de mécontentement à des web master.
    Le problème est que certain sans foute royalement. D’autre ne sont pas joignable, d’autre ne réponde pas :-(

    • [^] # Re: Norme ?

      Posté par  (site web personnel) . Évalué à 3.

      Il me semblait que la norme imposait que le site soit lisible pour les mals-voyants.

      Non. Des conditions d'accessibilité (pas seulement la gestion du handicap visuel) sont exigées des sites institutionnels, mais pas souvent respectées.
      Pour tout dire, bien coder n'est même pas une norme. Alors l'accessibilité… :/

      D’autre ne sont pas joignable, d’autre ne réponde pas :-(

      Ah, mais c'est has-been les formulaires de contact ! Faut touiter maintenant !

      Debug the Web together.

  • # Le 17 mars ?

    Posté par  . Évalué à -1.

    Sérieux ?

  • # ils ne veulent PAS

    Posté par  . Évalué à 5.

    Tout d'abord bravo pour ce projet.
    Fournir une architecture un peu élégante à tous les scripts que nous avons pu faire dans notre coin pour améliorer notre expérience avec le web est une très belle initiative.

    Mais justement, on parle bien de hacks.
    Les sociétés qui mettent en place des sites web grand public (souvent gratuits) ne le font pas pour que nous puissions facilement en contourner l'usage premier.
    Si ils avaient voulu faire des systèmes ouverts, ils auraient proposé des webservices, comme ils le font avec leurs partenaires ou leur clients pro, moyennant finance d'ailleurs.
    Une banque veut que l'utilisateur voit ses offres d'assurance vie quand il consulte ses comptes.
    Un site de partage de vidéo veut que le visiteur voit les vidéos suggérées et les pubs qu'il affiche en même temps que la vidéo.

    Rien que adblock est difficilement acceptable pour les sites qui vivent de la pub; c'est un peu comme si on inventait des lunettes qui filtrent les affiches 4x3.
    Car comme le dit Homer S: "If you don't watch [commercials] it's like stealing TV".

    Je pense donc qu'il sera toujours aussi laborieux, bien que toujours possible, de développer des hacks de site web.

    Mais, longue vie aux boobs !

    • [^] # Vivre de la pub

      Posté par  . Évalué à 0.

      Mauvais modèle économique : changer de modèle économique.

    • [^] # Re: ils ne veulent PAS

      Posté par  (Mastodon) . Évalué à 3.

      Si ils avaient voulu faire des systèmes ouverts, ils auraient proposé des webservices, comme ils le font avec leurs partenaires ou leur clients pro, moyennant finance d'ailleurs.

      Ne jamais attribuer à la malignité ce qui dépend de l'incompétence.

      • [^] # Re: ils ne veulent PAS

        Posté par  . Évalué à 5.

        De manière générale, je plussois. C'est ma devise, en particulier pour lutter contre les théories du complot.

        Maintenant, dans ce cas précis, pour avoir travailler sur les systèmes d'informations de grand comptes, je t'assure que les compétences sont présentes et que quand il faut faire des outils interopérables, ils savent faire.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.