D'autres choses sont cassées sur la tribune :
- Le backend XML n'est plus mis à jour depuis le post ID=2670473
- On ne peut plus poster non plus par un coincoin avec le cookie de session. Depuis le formulaire de https://linuxfr.org/board/ le serveur répond une Erreur 500 à la requête XHR (?!!) mais le post apparaît quand même ! Je suis fortement uxamifié
Tiens, tu n'as pas été tiraillé par la tentation de t'écrier "ASCII vaincra" ? Sinon, l'auteur du journal a raté une occasion de mieux tourner son titre pour cette annonce : "Devuan en version 2.0 ASCII paraît" ça aurait été pas mal :)
Voir la première réponse pour le port en C. Quant au C++, c'est le langage de l'implémentation originale de TapTempo et le journal correspondant a pu donc être plussoyé non pas à cause de l'attrait pour le langage, mais pour l'idée du logiciel en lui-même. Je l'ai donc exclu par souci de rigueur scientifique.
L'idée est absolument fascinante ! Cependant après avoir essayé ton serveur de tempo sur theglu.org, j'ai constaté qu'il se plantait allègrement d'environ un facteur 2 (le BPM affiché est 2x trop gros). Au vu du code, j'ai un peu de mal à comprendre pourquoi…
L'entrée qui parle de faire la moule, telle qu'elle est actuellement formulée, signifie "je fais la moule exclusivement sur linuxfr.org et pas ailleurs", déclaration dont on ne cerne pas bien le rapport avec le sujet. L'auteur avait probablement plutôt en tête "Je ne sais que faire la moule sur linuxfr.org" - notez la position du "que" qui change tout - qui, contrairement à la première formulation, constitue bien une réponse valide au sondage puisqu'elle signifie "ma contribution au libre se résume à mouler sur linuxfr.org car je ne sais faire que ça".
En tant qu'auteur de l'olcc original, je vais un peu expliquer le rôle du PHP là-dedans et pourquoi il est aussi basique.
A la base, l'idée d'olcc était de faire un client de tribune entièrement en javascript. C'était un peu ce que faisait le script Greasemonkey "EnhancedBoard", en transformant totalement la page peu pratique linuxfr.org/board en quelque chose qui se rapprochait véritablement de l'expérience utilisateur d'un coincoin du type wmcc ou pycc. Cependant, il lui manquait une fonctionnalité de taille : l'agrégation de plusieurs tribunes différentes.
Mais pour ce faire, Greasemonkey et le Javascript ne suffisaient plus, puisqu'on sortait de l'interaction avec un seul site, pour devoir afficher du contenu provenant de sites multiples, et donner la possibilité de poster dessus¹. Il fallait héberger le code d'olcc sur un serveur et permettre à ce serveur de requêter sur les sites hébergeant les tribunes.
J'ai donc conçu un mini proxy très simple en PHP qui est appelé par ajax, et se charge d'effectuer la requête vers le bon site avec la libcurl pour la récupération des backends XML et pour le post, uniquement dans le but de contourner l'impossibilité de faire les requêtes directement en js sur les sites cibles. Et effectivement, il serait simple de détourner l'utilisation de ce PHP pour par exemple en faire une sorte de proxy universel pour requêter n'importe quelle URL sur n'importe quel site (LiNuCe< en avait d'ailleurs fait un proof-of-concept). Il y aurait quelques trucs faciles à implémenter pour sécuriser un peu le bouzin, ne serait-ce par exemple que contrôler que l'url demandée correspond bien à une url de tribune configurée côté client. Mais moi, développer une partie serveur ne m'intéressait tout bonnement pas, j'étais dans une logique de pondre un client de tribunes purement javascript autant que possible.
D'autres se sont penchés sur la question : un "olccs" (s pour server) avait été développé, sorte d'agrégateur/archiveur de tribunes fournissant une API de consultation/recherche et de post unifiée, sur laquelle pouvait se greffer olcc ou n'importe quel coincoin. Je parle au passé car il n'y a plus d'instance maintenue.
Voilà voilà
¹ Je modère un peu cette remarque par la précision suivante : en fait, une possibilité purement javascript existe bien : le requêtage Ajax cross-domain (CORS). Mais pour que cela fonctionne, il faut que tous les serveurs de tribune l'autorisent, ce qui est rarement le cas en pratique. Sinon, linuxfr donne également la possibilité d'utiliser OAuth2 pour poster dans la tribune, mais c'est une spécificité que ne partagent pas les autres moteurs de tribunes et je ne me suis jamais penché sur la mise en oeuvre.
Nulle part, c'est un standard de fait. Enfin, il y a eu plusieurs tentatives, des wiki, des extensions à la RFCMoule42 (qui ne normalisait à l'origine que les ====> Moments <====), mais rien de maintenu ni à jour. Mais ça ne pose pas de problème à ceux qui développent des moteurs de tribune ou des coincoins, parce que les questions sont directement débattues par la communauté d'experts sur les tribunes actives. Par contre, ceux qui développent icitte ne participent pas à cette communauté ni ne s'intéressent à ce qui se fait dans l'univers qu'ils ont paradoxalement eux-même suscité, malheureusement.
Pour ceux qui ont confirmé, on se rencarde à 20h devant le resto et on rentre ensemble, et sinon on peut demander la table de devnewton ou chrisix. Je porterai un t-shirt Cowboy Bebop :)
Comment seraient encodés les retours à la ligne ou les tabulations dans les champs message ?
Pas. Comme un message de tribune est rendu comme du html, les \n, \t et espaces, ou toute chaîne constituée de ces caractères en nombre et combinaison quelconques, sont rendus par un espace simple. Par conséquent c'est au moteur de tribune de "sanitizer" le message en ce sens dans le backend tsv, comme il le fait déjà pour les tags.
C'est censé répondre à quel problème ?
C'est quoi le problème avec le XML ?
Pourquoi TSV et pas JSON, qui est largement plus supporté ?
Tu arrives longtemps après le débat, mais c'est vrai que tu ne fréquentes plus les tribunes où ces discussions ont lieu.
La réponse à tout cela est simplement "simplicité, légèreté et robustesse". Pourquoi se lancer dans un parsing complexe quand un split("\n") suffit à récupérer les posts et un split("\t") les champs du post ?
Le XML, outre qu'il est lourd à parser, comporte la problématique du double niveau de namespace entre les tags du backend et ceux du message, ce qui fait qu'il n'y a pas 2 moteurs de tribune le gérant de façon identique (tags encoded, not encoded, raw, encapsulation CDATA…)
Le JSON est particulièrement adapté pour un client web, mais des coincoins sont toujours développés en client lourd.
Et enfin, le sujet n'est pas d'éliminer les backends XML ou JSON qui ont toujours leur légitimité. Il s'agit de proposer une alternative et de laisser le choix au client.
Quels sont les tags qui doivent être interprétés par les clients ?
La balise a est-elle utilisée pour les urls ?
Hors-sujet, il n'y a pas de changement dans le format du contenu du message (si ce n'est la suppression des \n \t, ce que la plupart des moteurs fait déjà). La demande ne concerne que le format du backend.
Pourquoi ?
Je profite de cette dernière question plutôt large pour aborder d'autres points : on voit que le but premier d'un tel backend est l'efficacité, et celle-ci prend tout son sens lorsque le format TSV est couplé aux autres techniques d'optimisation : renvoi uniquement des posts utiles grâce au paramètre last-id, posts ordonnés par id croissant (permettant au client d'insérer tous les nouveaux posts d'un coup sans trier), support du XPOST pour économiser un get après un post, etc.
Bien cordialement,
Rock Hightram
Mouling Technologies Senior Architect
A l'époque où la Tribune était encore un lieu de discussions techniques de haute volée, de nombreux trolls se sont tenus sur ce sujet. Dans un esprit de conciliation, l'acronyme OPALPAG a été proposé et a rencontré un relatif succès pendant un temps, qui s'est étiolé ensuite avec la dispersion des moules historiques sur d'autres bouchots.
Et pourquoi donc OPALPAG, me direz-vous, si ce n'est pour l'amusante sonorité de ce nom original ? Eh bien, cela signifie tout simplement : OS Parfois Appelé Linux, Parfois Appelé GNU/Linux :-)
A partir de la page 75 pour les résultats concernant la Data.
Oui, je sais, ça date d'un an, mais le rapport 2015 n'est pas encore disponible (il ne devrait plus trop tarder je pense)
Hum, je n'avais jamais compris la formule "bien ou bien" comme posant une fausse alternative entre "aller bien" et "aller bien", mais comme une question ouverte : "[vas-tu] bien ou bien [pas si bien, auquel cas explique]" ? Il faut prendre le "ou bien" dans son ensemble comme une expression développée du "ou". Comme quand on dit par exemple : "tu veux manger quoi, une poire ou bien une pomme ?". Du coup, bon je me trompe peut-être, mais j'ai toujours pris ce "bien, ou bien" au sens suisse.
Et encore, je ne sais pas si tu as vu le détail, mais les 18h annoncées se basent sur une projection assez arbitraire des usages, c'est assez savoureux : en réalité ça correspond à moins de 2h d'utilisation réelle ! 90 vérifications de l'heure, 90 notifications, 45 minutes d'utilisation d'apps et 30 minutes de lecture de musique en Bluetooth
A part ça, d'autres infos ont filtré concernant le stockage, et ça n'a pas l'air très glorieux non plus, cf. ici par exemple
# Y'a pas que oauth.
Posté par Sten Spårvagnhög (site web personnel) . En réponse à l’entrée du suivi API Oauth2 cassée?. Évalué à 4 (+0/-0).
D'autres choses sont cassées sur la tribune :
- Le backend XML n'est plus mis à jour depuis le post ID=2670473
- On ne peut plus poster non plus par un coincoin avec le cookie de session. Depuis le formulaire de https://linuxfr.org/board/ le serveur répond une Erreur 500 à la requête XHR (?!!) mais le post apparaît quand même ! Je suis fortement uxamifié
[^] # Re: Mais il y a bien mieux !
Posté par Sten Spårvagnhög (site web personnel) . En réponse au journal Sortie de Devuan ASCII 2.0. Évalué à 10.
Tiens, tu n'as pas été tiraillé par la tentation de t'écrier "ASCII vaincra" ? Sinon, l'auteur du journal a raté une occasion de mieux tourner son titre pour cette annonce : "Devuan en version 2.0 ASCII paraît" ça aurait été pas mal :)
[^] # Re: erreur de recruteur...
Posté par Sten Spårvagnhög (site web personnel) . En réponse au journal Etude comparée de la popularité des langages de programmation sur linuxfr. Évalué à 6.
Voir la première réponse pour le port en C. Quant au C++, c'est le langage de l'implémentation originale de TapTempo et le journal correspondant a pu donc être plussoyé non pas à cause de l'attrait pour le langage, mais pour l'idée du logiciel en lui-même. Je l'ai donc exclu par souci de rigueur scientifique.
[^] # Re: Calcul un peu hasardeux
Posté par Sten Spårvagnhög (site web personnel) . En réponse au journal TapTempo sous la forme d'un service sur internet. Évalué à 3.
Arf excellent ! J'y aurais jamais pensé :)
# Calcul un peu hasardeux
Posté par Sten Spårvagnhög (site web personnel) . En réponse au journal TapTempo sous la forme d'un service sur internet. Évalué à 6.
L'idée est absolument fascinante ! Cependant après avoir essayé ton serveur de tempo sur theglu.org, j'ai constaté qu'il se plantait allègrement d'environ un facteur 2 (le BPM affiché est 2x trop gros). Au vu du code, j'ai un peu de mal à comprendre pourquoi…
# Reminder
Posté par Sten Spårvagnhög (site web personnel) . En réponse au message Génie logiciel. Évalué à 10.
Sheeva, n'oublie pas de penser à l'importance du Génie Logiciel dans l'évolution des sciences informatiques !
Voilà, de rien.
# Moulage
Posté par Sten Spårvagnhög (site web personnel) . En réponse au sondage Pour défendre le logiciel libre et ses valeurs. Évalué à 3.
L'entrée qui parle de faire la moule, telle qu'elle est actuellement formulée, signifie "je fais la moule exclusivement sur linuxfr.org et pas ailleurs", déclaration dont on ne cerne pas bien le rapport avec le sujet. L'auteur avait probablement plutôt en tête "Je ne sais que faire la moule sur linuxfr.org" - notez la position du "que" qui change tout - qui, contrairement à la première formulation, constitue bien une réponse valide au sondage puisqu'elle signifie "ma contribution au libre se résume à mouler sur linuxfr.org car je ne sais faire que ça".
[^] # Re: Mon positionnement
Posté par Sten Spårvagnhög (site web personnel) . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 10.
1 Mo de RAM en 1980 ? La vaaaaache !
[^] # Re: Perso, j'installe pas ça chez moi
Posté par Sten Spårvagnhög (site web personnel) . En réponse au journal Olcc-NG : un nouveau client de messagerie moderne et efficace. Évalué à 9.
En tant qu'auteur de l'olcc original, je vais un peu expliquer le rôle du PHP là-dedans et pourquoi il est aussi basique.
A la base, l'idée d'olcc était de faire un client de tribune entièrement en javascript. C'était un peu ce que faisait le script Greasemonkey "EnhancedBoard", en transformant totalement la page peu pratique linuxfr.org/board en quelque chose qui se rapprochait véritablement de l'expérience utilisateur d'un coincoin du type wmcc ou pycc. Cependant, il lui manquait une fonctionnalité de taille : l'agrégation de plusieurs tribunes différentes.
Mais pour ce faire, Greasemonkey et le Javascript ne suffisaient plus, puisqu'on sortait de l'interaction avec un seul site, pour devoir afficher du contenu provenant de sites multiples, et donner la possibilité de poster dessus¹. Il fallait héberger le code d'olcc sur un serveur et permettre à ce serveur de requêter sur les sites hébergeant les tribunes.
J'ai donc conçu un mini proxy très simple en PHP qui est appelé par ajax, et se charge d'effectuer la requête vers le bon site avec la libcurl pour la récupération des backends XML et pour le post, uniquement dans le but de contourner l'impossibilité de faire les requêtes directement en js sur les sites cibles. Et effectivement, il serait simple de détourner l'utilisation de ce PHP pour par exemple en faire une sorte de proxy universel pour requêter n'importe quelle URL sur n'importe quel site (LiNuCe< en avait d'ailleurs fait un proof-of-concept). Il y aurait quelques trucs faciles à implémenter pour sécuriser un peu le bouzin, ne serait-ce par exemple que contrôler que l'url demandée correspond bien à une url de tribune configurée côté client. Mais moi, développer une partie serveur ne m'intéressait tout bonnement pas, j'étais dans une logique de pondre un client de tribunes purement javascript autant que possible.
D'autres se sont penchés sur la question : un "olccs" (s pour server) avait été développé, sorte d'agrégateur/archiveur de tribunes fournissant une API de consultation/recherche et de post unifiée, sur laquelle pouvait se greffer olcc ou n'importe quel coincoin. Je parle au passé car il n'y a plus d'instance maintenue.
Voilà voilà
¹ Je modère un peu cette remarque par la précision suivante : en fait, une possibilité purement javascript existe bien : le requêtage Ajax cross-domain (CORS). Mais pour que cela fonctionne, il faut que tous les serveurs de tribune l'autorisent, ce qui est rarement le cas en pratique. Sinon, linuxfr donne également la possibilité d'utiliser OAuth2 pour poster dans la tribune, mais c'est une spécificité que ne partagent pas les autres moteurs de tribunes et je ne me suis jamais penché sur la mise en oeuvre.
# Le rêve millénaire des ménagères
Posté par Sten Spårvagnhög (site web personnel) . En réponse au journal Appel à idées pour prof(s) de lycée. Évalué à 4.
Un système robotique ou à quelconque automatisme pour laver les vitres, adaptable à n'importe quelle fenêtre. Et pas trop encombrant.
[^] # Re: linuxfr is debianing
Posté par Sten Spårvagnhög (site web personnel) . En réponse au journal WMCoincoin est à nouveau 100 % compatible avec LinuxFr.org !. Évalué à 10.
Nulle part, c'est un standard de fait. Enfin, il y a eu plusieurs tentatives, des wiki, des extensions à la RFCMoule42 (qui ne normalisait à l'origine que les ====> Moments <====), mais rien de maintenu ni à jour. Mais ça ne pose pas de problème à ceux qui développent des moteurs de tribune ou des coincoins, parce que les questions sont directement débattues par la communauté d'experts sur les tribunes actives. Par contre, ceux qui développent icitte ne participent pas à cette communauté ni ne s'intéressent à ce qui se fait dans l'univers qu'ils ont paradoxalement eux-même suscité, malheureusement.
[^] # Re: Aucune crédibilité de monsieur Lenglet
Posté par Sten Spårvagnhög (site web personnel) . En réponse au journal "Tant pis, ce seront nos enfants qui paieront". Évalué à 4.
Et puis surtout, depuis le BREXIT, Lenglet s'est lui-même exclu, alors…
[^] # Re: Un journal ?
Posté par Sten Spårvagnhög (site web personnel) . En réponse au journal Une charade. Évalué à 10.
J'allais au contraire proposer de promouvoir ce journal en dépêche ! C'est rare d'avoir de l'humour de qualitaÿ comme ça en page d'accueil…
[^] # Re: Réservation ?
Posté par Sten Spårvagnhög (site web personnel) . En réponse au journal Moulebouffe parisienne ce soir. Évalué à 5.
Pour ceux qui ont confirmé, on se rencarde à 20h devant le resto et on rentre ensemble, et sinon on peut demander la table de devnewton ou chrisix. Je porterai un t-shirt Cowboy Bebop :)
[^] # Re: question
Posté par Sten Spårvagnhög (site web personnel) . En réponse à l’entrée du suivi Backend TSV pour la tribune. Évalué à 3 (+0/-0).
Pas. Comme un message de tribune est rendu comme du html, les \n, \t et espaces, ou toute chaîne constituée de ces caractères en nombre et combinaison quelconques, sont rendus par un espace simple. Par conséquent c'est au moteur de tribune de "sanitizer" le message en ce sens dans le backend tsv, comme il le fait déjà pour les tags.
Tu arrives longtemps après le débat, mais c'est vrai que tu ne fréquentes plus les tribunes où ces discussions ont lieu.
La réponse à tout cela est simplement "simplicité, légèreté et robustesse". Pourquoi se lancer dans un parsing complexe quand un split("\n") suffit à récupérer les posts et un split("\t") les champs du post ?
Le XML, outre qu'il est lourd à parser, comporte la problématique du double niveau de namespace entre les tags du backend et ceux du message, ce qui fait qu'il n'y a pas 2 moteurs de tribune le gérant de façon identique (tags encoded, not encoded, raw, encapsulation CDATA…)
Le JSON est particulièrement adapté pour un client web, mais des coincoins sont toujours développés en client lourd.
Et enfin, le sujet n'est pas d'éliminer les backends XML ou JSON qui ont toujours leur légitimité. Il s'agit de proposer une alternative et de laisser le choix au client.
Hors-sujet, il n'y a pas de changement dans le format du contenu du message (si ce n'est la suppression des \n \t, ce que la plupart des moteurs fait déjà). La demande ne concerne que le format du backend.
Je profite de cette dernière question plutôt large pour aborder d'autres points : on voit que le but premier d'un tel backend est l'efficacité, et celle-ci prend tout son sens lorsque le format TSV est couplé aux autres techniques d'optimisation : renvoi uniquement des posts utiles grâce au paramètre last-id, posts ordonnés par id croissant (permettant au client d'insérer tous les nouveaux posts d'un coup sans trier), support du XPOST pour économiser un get après un post, etc.
Bien cordialement,
Rock Hightram
Mouling Technologies Senior Architect
# OPALPAG
Posté par Sten Spårvagnhög (site web personnel) . En réponse au sondage comment doit-on appeler les systèmes d'exploitation basés sur un noyau Linux ?. Évalué à 10.
A l'époque où la Tribune était encore un lieu de discussions techniques de haute volée, de nombreux trolls se sont tenus sur ce sujet. Dans un esprit de conciliation, l'acronyme OPALPAG a été proposé et a rencontré un relatif succès pendant un temps, qui s'est étiolé ensuite avec la dispersion des moules historiques sur d'autres bouchots.
Et pourquoi donc OPALPAG, me direz-vous, si ce n'est pour l'amusante sonorité de ce nom original ? Eh bien, cela signifie tout simplement :
OS Parfois Appelé Linux, Parfois Appelé GNU/Linux :-)
[^] # Re: ex-Free
Posté par Sten Spårvagnhög (site web personnel) . En réponse au journal Free Mobile: C'est quoi leur projet?. Évalué à 6.
http://www.arcep.fr/uploads/tx_gspublication/rapport-QS-mobile-2014-230614.pdf
A partir de la page 75 pour les résultats concernant la Data.
Oui, je sais, ça date d'un an, mais le rapport 2015 n'est pas encore disponible (il ne devrait plus trop tarder je pense)
[^] # Re: Mes encouragements pour cet atelier GIRLS CAN CODE ! :D
Posté par Sten Spårvagnhög (site web personnel) . En réponse à la dépêche Stage collégiennes/lycéennes « Girls Can Code! » en août. Évalué à 9.
Ca doit être un vieux réflexe de codeur (mâle) : CANT REPRODUCE - WONT FIX
[^] # Re: Zenitram et la démocratie
Posté par Sten Spårvagnhög (site web personnel) . En réponse au journal Et ce soir, la démocratie l'emporte ! . Évalué à 4.
En l'occurrence, il s'agissait plutôt d'une analogie bidet
[^] # Re: Et pour plus complet
Posté par Sten Spårvagnhög (site web personnel) . En réponse au journal Premiers pas avec Saru, outil de suivi commercial. Évalué à 4.
DOLIBAAAAARRRRRR ! DOLIBAR-BAR BARR ! https://www.youtube.com/watch?v=x81iip6psks&t=20s
[^] # Re: Sujet du commentaire
Posté par Sten Spårvagnhög (site web personnel) . En réponse au journal Et la politesse bordel !!!. Évalué à 4.
Hum, je n'avais jamais compris la formule "bien ou bien" comme posant une fausse alternative entre "aller bien" et "aller bien", mais comme une question ouverte : "[vas-tu] bien ou bien [pas si bien, auquel cas explique]" ? Il faut prendre le "ou bien" dans son ensemble comme une expression développée du "ou". Comme quand on dit par exemple : "tu veux manger quoi, une poire ou bien une pomme ?". Du coup, bon je me trompe peut-être, mais j'ai toujours pris ce "bien, ou bien" au sens suisse.
[^] # Re: Eh ben
Posté par Sten Spårvagnhög (site web personnel) . En réponse au journal Récit d'un gros dégringolage anticipable. Évalué à 2.
Il y en a déjà eu au moins deux, mais il semblerait qu'ils aient fermé leurs comptes :-/ https://linuxfr.org/users/pspj https://linuxfr.org/users/steve_jobs
[^] # Re: service-public.fr utilise toujours RC4
Posté par Sten Spårvagnhög (site web personnel) . En réponse à la dépêche Firefox : version 38. Évalué à 2.
Ah ! Il lui dit "Bondour ! Comment da ba ?"
[^] # Re: Pourquoi sont-ils en gréve ?
Posté par Sten Spårvagnhög (site web personnel) . En réponse au journal Redevance Radio France. Évalué à 2.
Vu sa mission j'aurais pensé que c'était Mathieu Calège (les charges)
[^] # Re: On a la durée de la batterie, et c'est un jour (18 heures selon Apple)
Posté par Sten Spårvagnhög (site web personnel) . En réponse au journal Tic-tac, tic-tac, tic-tac... plouf.. Évalué à 5.
Et encore, je ne sais pas si tu as vu le détail, mais les 18h annoncées se basent sur une projection assez arbitraire des usages, c'est assez savoureux : en réalité ça correspond à moins de 2h d'utilisation réelle ! 90 vérifications de l'heure, 90 notifications, 45 minutes d'utilisation d'apps et 30 minutes de lecture de musique en Bluetooth
A part ça, d'autres infos ont filtré concernant le stockage, et ça n'a pas l'air très glorieux non plus, cf. ici par exemple