Par contre, n'existe-t-il pas un « mode de traitement » des données arborescentes à la XSLT dans d'autres langage ? Je le trouve tellement efficace que je me vois mal m'en passer maintenant dans les autres langages…
Tiens, je viens de penser qu'on pourrait utiliser des décorateurs avec des expressions XPath pour faire comme du XSLT… marrant comme idée.
deux versions (v1 et v2) plus ou moins incompatibles et en concurrence
peu de documentation sur internet et surtout divisé entre v1 et v2 ce qui induit souvent en erreur si la version n'est pas précisé
Je n'ai pas trop eu le problème, je me suis limité à XSLT v1, la v2 étant peu supportée par des outils libres. J'ai ressenti certains manques des fois, mais rien de trop important.
la création de fonctions n'est pas intuitive du tout (le fait que ce soit du fonctionnel n'aidant bien sûr pas les gens qui n'y sont pas habitué, soit un bon paquet de programmeurs !)
Moi je la trouve intuitive… Et du coup, c'est l'occasion de se mettre au fonctionnel !
Bref pour contribuer à du XLST il faut déjà bien le connaître sous peine de passer beaucoup de temps à faire des choses assez triviales, là où Python (qui n'est certes pas très à son avantage ici) est bien plus simple à modifier, même pour un néophyte
Oui, mais on aborde le classique problème : doit-on utiliser des outils de merde (dans ce contexte) pour être accessible, ou doit-on demander à avoir un minimum d'initiation afin de pouvoir utiliser des choses plus adaptées, et sur le long terme, beaucoup plus efficaces ? Sur linuxfr, je pensais qu'on hésitait moins sur l'investissement dans des outils « complexes » si le jeu en vaut la chandelle…
Personnellement je me demande pourquoi ils ne sont pas partit sur un moteur de template comme il existe pléthore dans le monde web (au hasard, léger et puissant : http://jinja.pocoo.org/docs/dev/)
Pour la génération de texte, effectivement, ça aiderait (c'est un handicap de XSLT aussi : il est plus à l'aise dans la génération de XML que de texte brut) ; j'aime beaucoup Jinja2. Par contre, pour le parsing de XML d'entrée, ça n'aidera en rien, et c'est surtout là-dessus que Python pêche, je trouve.
plusieurs dizaines de lignes de code en tout, soit un facteur 10 par rapport à un langage généraliste.
Oui enfin dans ce cas, la bonne solution est d'en faire une bonne bibliothèque, comme pour les autres langages… mais c'est vrai qu'à ce niveau (ressources externes en extensions XSLT), le langage est malheureusement peu pourvu.
Mais le jour où l'on décide de normaliser certaines valeurs XML en croisant avec une base de données, alors la feuille XSL devient un boulet.
C'est vrai que dans ce genre de cas, je comprends que XSLT ne soit plus adapté.
Par contre, n'existe-t-il pas un « mode de traitement » des données arborescentes à la XSLT dans d'autres langage ? Je le trouve tellement efficace que je me vois mal m'en passer maintenant dans les autres langages…
s’il n’y a pas iso-fonctionnalité, la comparaison est intrinsèquement biaisée.
Si tu parles du fait que le code Python fait moins de choses dans le cas qui nous concerne, et est donc naturellement plus court, c'est le point principal que je voulais montrer, effectivement.
j’ai bossé sur un projet avec des feuilles de style xlst > 10k lignes, plus jamais ça
Ouch, ça fait mal, oui.
le manque d’opérations triviales (formatage de dates par exemple)
Bon, ça c'est vrai que ça semble un petit peu limité, et que je n'ai pas rencontré ce besoin encore, mais que ça serait handicapant.
la très mauvaise lisibilité --> il est difficile, en lisant une grosse feuille de style xlst, de comprendre ce qu’elle fait, dans quel ordre sont faits les traitements, etc.
Mmmhh… dans les exemples que j'ai vu, je ne vois pas en quoi un code procédural serait plus lisible.
le premier fait que tu dois « réécrire » un certain nombre de fonctionnalités de base, d’où surcoût.
Ça c'est clair que ça doit être rédhibitoire quand tu en as besoin.
le deuxième point fait que chaque bug / évolution coûte beaucoup plus cher, parce qu’il faut le temps de « rentrer dedans ».
Encore une fois, je ne vois pas trop la différence. À moins que ça soit pour quelqu'un qui connaît mal XSLT, mais la critique peut alors valoir pour n'importe quel langage.
la grosse galère à débugger (à fortiori quand il y a des inclusions multiples)
J'ai effectivement un petit peu vécu ça, xsltproc que j'utilise pourrait être plus explicite sur certaines erreurs (comme quand tu appelles une template qui n'existe pas quand tu t'es trompé dans le nom).
les perfs désastreuses
J'avoue ne pas avoir eu de problème avec ça, vu que mes fichiers sont de taille raisonnable.
Bref, personnellement, j’ai essayé, maintenant, j’évite autant que possible. À nombre de lignes égal, un programme est nettement plus lisible qu’une feuille xslt. Et xslt a tendance a être plus verbeux… :/
Oui, la verbosité n'aide vraiment pas. Mais ce qui me plaît vraiment et qu'on ne retrouve pas ailleurs, c'est la logique de parsing du langage : c'est hyper-bien adapté à du parcours d'arbre, et le matching est super pratique pour spécialiser certains cas. Ce genre de chose serait horrible à faire avec un autre langage. Tout ça se rapproche du fonctionnel, qui n'est pas facile à comprendre quand on est pas habitué, mais une fois que tu l'as saisi, ça simplifie tellement de choses…
En fait, il faudrait juste une version moins verbeuse. J'ai pensé à du YAML pour décrire les XSLT, je ne sais pas si ça pourrait le faire.
Merci pour ces remarques en tous cas, assez justes.
Dans le post originel, l'auteur comparait la popularité de XSLT à celle de COBOL
Ça tombe bien, il se trouve que j'ai déjà fait du COBOL : peut-être que niveau employabilité, ça le fait mieux (et encore, vu les usines à gaz Java qui touchent du XML, ça ne m'étonnerait pas que le XSLT soit populaire en entreprise bien que peu visible dans le libre, tout comme le COBOL), mais niveau « facilité » du langage, ça n'a rien à voir. Le XSLT est bien plus accessible et moderne (un langage plutôt déclaratif, quand même !) et, comme je le disais, apprenable assez facilement. Alors on peut mettre en face le fait que peu de monde le connaisse à priori, mais y mettre du Python et tous les risques associés que j'ai cité, ça ne me semble pas une très bonne idée.
Le code supprimé aurait très bien pu l'être dans sa forme XSLT, ça serait revenu au même, tout en gardant un langage fait pour ce travail. J'adore le Python, vraiment, mais pour certaines utilisations, il n'est vraiment pas adapté.
Après, tout ça c'est pour importer du OOXML, alors je pourrais m'en foutre aussi, mais bon, le XSLT m'a un peu appris le masochisme /o\
Les 4200 lignes de XLST ont été réécrites en 1300 lignes de Python - pour produire le même résultat avec une forte augmentation de la hackabilité.
Alors, faisant actuellement de la génération de code à base de XSLT pour un projet, ce refactoring m'a intrigué : me serais-je trompé d'avoir utilisé un langage déclaratif alors que j'aime pourtant bien Python ? Je suis donc allé voir de plus près.
J'ai pris un exemple de complexité moyenne, mais regardons par exemple le code original en XSLT :
Franchement, la différence de lisibilité et la soi-disant facilité de « hackage » ne sautent pas aux yeux. Certes il faut connaître XSLT pour mieux le « parser » visuellement, et passer outre sa verbosité, qui doit être son plus gros défaut, mais sinon je trouve la matching des balises avec DOM est vraiment horrible à lire. Tellement que ça doit amener des bugs : le getElementsByTagName() ligne 147 me semble faux, le XSLT ne va chercher que les enfants directs. De plus, tous les anciens cas ne sont pas gérés : rien pour un "refdefine" nul (c'est peut-être une hypothèse assumée, mais pas précisée). Et au passage on perd complètement la notion d'espace de nommage pour les tags ! La verbosité de l'API du DOM pour ça vis à vis de XPath ne doit pas y être pour rien…
En parlant d'API, Miklos les mélange d'ailleurs allègrement ; on passe à SAX pour un autre fichier (qui fait encore une fois des hypothèses plus stricte sur les entrées, les "fastoken" hors d'un "model" étant potentiellement traités, de manière erronée) :
Ce qui fait qu'on peut potentiellement avoir des documents qui ne valident pas, vu que ce genre de parser ne permet plus d'assurer la bonne forme du document…
Ah mais en fait, la conversion précédente amène un bug, qui complique le code python encore plus, corrigeons-le :
Voilà les joies de la conversion. Là où la nouvelle de linuxfr se fourvoie par contre — même si ça vient certes du blog de l'auteur, et qu'on ne vérifie pas forcément la véracité de sources aussi proches — c'est que la réduction du code XSLT ne vient pas de la supposée concision de Python pour ce genre de travail, mais juste de simples suppressions de code ! Le code précédent a par exemple simplement été retiré :
Et de même pour un paquet d'autres. Et la réduction du gros paquet de code généré vient principalement parce qu'on a implémenté moins de choses dans la version python que dans la version XSLT.
Bref, je peux très bien comprendre l'argument de la non-popularité de XSLT pour passer à un langage comme Python, mais d'un côté, ça s'apprend très vite (il y a deux semaines, je n'en avait jamais fait), et c'est un langage très adapté quand on tripote du XML, avec toutes les contraintes que ça amène, et toutes les facilités qu'offre un langage fait pour. En tous cas, les réductions en taille de code présentées n'ont rien à voir avec le fait que ça soit du XSLT. Je suppose que Miklos n'aimait pas, et en a profité pour cracher dessus, de manière fallacieuse.
Mangez du XSLT (mais seulement si vous faites du XML, hein, il ne faut pas être maso non plus), c'est bon.
Pas besoin de compléter les autres réponses au sujet de la sécurité des banques, les exemples donnés dans la news sont suffisants.
Ces exemples sont assez affligeants, mais il y a des bonnes banques, non ? Je sais que le Crédit Coopératif fonctionne avec un sésame depuis des années, et ça me semble quelque chose de plutôt bien sécurisé. Après, c'est clair que les banques ont une guerre de retard niveau accessibilité et interopérabilité, mais ça m'effraie que tu aies un avis si négatif sur l'ensemble de la profession. Crois-tu que les bons élèves soient des exceptions ?
Quant à SEPA et CFONB, c'est évidement une triste rigolade. Des retours que l'on a, les données ne sont pas fiables (« trous » dans les relevés), le format est moyenâgeux, comme tu dis au final peu standardisé, les banques facturent ça une blinde, et les délais d'accès sont de plusieurs semaines. Pas compatible avec une application « clic&play ». Sans oublier l'absence des cartes à débit différé dans les relevés.
Merci pour ce témoignage. Je ne connais pas le système en détail, j'ai juste regardé à droite à gauche, mais je pensais qu'il était quand même mieux fait que ça… c'est triste en 2015.
C'est hallucinant quand on voit que du côté de leur réseaux internes, avec SWIFT et compagnie, le HFT, etc, ils sont super à la pointe, mais que pour leurs clients « dans la vie réelle », ils ne font aucun effort.
Quand on passe par un service de paiement intermédiaire, qui est souvent indiqué, on est sûr qu'ils ne stockent pas. Sinon, quand c'est un petit site, en général ils ne stockent pas non plus à long terme, car ils n'ont pas les moyens. Certains autres sites, c'est par « réputation », ou plutôt que je me suis renseigné sur leurs méthodes. Ce qui ne laisse pas grand chose d'autre à part ceux qui sont connus pour ça, comme Paypal ou Amazon, que je n'utilise jamais.
Certes, je ne suis pas du genre à tester des nouveaux magasins tous les quatre matins, mais j'arrive à voir à l'avance, ou alors on s'en rend compte au milieu de la procédure (genre « enregistrer ma carte » dans son compte client). Ceux qui ne le disent pas et le font, ça m'est juste arrivé pour un, je ne recommande pas chez eux.
Je comprends un peu parfois le côté « repoussant » de faire du scraping de sites de banques pour en extraire le contenu, quand linuxfr est rempli de moules « puristes ». C'est là-dessus que viennent la plupart des critiques, je pense.
Cependant, je dois reconnaître que vu la non-coopération des banques à ce sujet, le fait que weboob fasse pression avec cette méthode crade n'est pas inutile. Par contre, c'est clair que même si les méthodes de rétention des banques sont dégueulasses, leurs craintes sur la sécurité ne sont à mon avis pas infondées : on peut le voir avec toutes les failles de sécurité qui ont conduit à des fuites de numéro de carte bancaire ou d'informations personnelles récemment par exemple.
À ce propos, il faut noter que ces problèmes sont arrivés à des sites qui stockaient localement les numéros de carte bancaire : il me semble que la certification PCI-DSS interdisait ce genre de pratique, justement pour éviter ces déconvenues. Et on voit que les banques n'avaient pas complètement tort d'interdire ces pratiques (perso, je ne comprends pas comment on peut laisser faire ça ; je quitte tout site qui le fait : certes, un site peut garder temporairement le numéro s'il fait lui-même la transaction au lieu de passer par un service ters, mais pas plus longtemps que le temps d'effectuer la transaction).
Maintenant, on voit que le fait d'empêcher les gens d'accéder à leur données pour raison de sécurité (un peu abusivement : c'est très utile pour proposer sa solution propriétaire très chère, aussi) n'a fait « qu'empirer » le problème de sécurité avec des logiciels comme weboob, qui font ce que les gens voudraient vraiment (accéder simplement à leurs données de manière automatique, indépendamment de la banque), même si c'est au dépend des procédures de sécurité voulues par la banque. J'espère qu'elles vont se réveiller et développer des systèmes interopérables et avec sécurité « intégrée » (surtout des conseils sur le workflow des données, sur la manière de stocker, etc). Les API qui sont offertes par certaines banques, comme indiqué dans la dépêche, sont peut-être bien mais à mon avis pas encore standards (quand on voit le SEPA qui aurait pu en profiter pour faire quelque chose de bien, mais non, les méta-données des virements ne sont même pas standardisée dans leur interface avec l'utilisateur…), et surtout doivent manquer de procédures quant à la sécurité de la gestion des données (certes, je parle sans connaître pour ce point : quelqu'un a plus d'infos ?).
En résumé, avec une taille insuffisante du buffer passé à gethostbyname_r(), pour faire des résolutions inverse de nom, on peut éventuellement exécuter du code. Mouai. C'est un buffer dont la taille et l'allocation n'est pas contrôlée par l'utilisateur, seul l'IP à résoudre le sera éventuellement. Bref, c'est assez mince comme faille.
systemd a une facheuse tendance à se planter en lancant networkd au démarrage de l'ordi : du coup, reboot obligatoire
Tu peux préciser comment ça se passe quand tu as un tel problème ? Pour moi, c'est un des problèmes majeurs que j'ai avec systemd : je n'ai pas envie de faire beta-testeur de fonctionnalités qui font revenir plus de 10 ans en arrière (devoir rebooter parce qu'un soft est buggé ?!…).
Ça plus le fait que networkd, par exemple, ne va sûrement pas gérer mes confs réseau « exotiques » (à l'époque, j'avais fait un patch pour ignorer les bridge dans network-manager, version 0.8 ; j'ai vu que la version « courante » à ce moment-là était un cran au-dessus, et que l'API avait complètement changé, ce qui faisait que mon travail était inutile : ça m'a bien calmé, j'ai laissé tomber).
Donc l'établissement sait que la personne s'est logguée. Pas si elle a voté, pas ce qu'elle a voté (tout comme Facebook sait que je me suis loggué avec Facebook sur le site XXX mais ne sait pas ce que j'ai fait ensuite).
Bien sûr (même si c'est faux pour Facebook qui va suivre ta navigation, au moins). Mais je ne peux en être sûr que si j'ai une confiance totale dans mon établissement pour ce scrutin et dans le prestataire du système de vote, car ils pourraient coopérer pour s'échanger des informations sur mon vote. Bien sûr, ça serait faisable même sans SSO, avec le système de numéro envoyé par la Poste qu'ils proposent à d'autres, c'est juste que là ça fait tellement « visible » que ça en est ridicule.
Pareil ici, sauf que c'est la première fois. Et pour éviter d'avoir à gérer un « espace électeur », ils ont eu la géniale idée de relier le système de vote… au SSO de l'établissement ! Et après, ils nous disent que les votes sont « anonymes »…
La CGT-SUD s'est opposée au vote électronique au départ (pas les autres d'après ce que j'ai lu) mais s'y est résignée. En signe de « protestation », ils invitent les gens à aller voter dans l'isoloir qu'ils ont réclamé pour mettre autour de la machine physique dédiée (un PC de l'établissement avec son navigateur qui pointe sur le site de vote) au lieu de leur machine. Vive la contestation…
Merci, tu as bien résumé ma pensée, avec un ton très intelligent et mesuré, j'aime bien ça.
C'est effectivement problématique qu'il y ait des attaques agressives des deux côtés. Mais laissons les méchants cracher leur bile, et trollons ensemble gentiment dans la joie !
Perso, j'attends de voir si uselessd devient une alternative potable, il me semble vraiment intéressant.
Attention à l'interaction du paquet ca-certificates et de iceweasel : la plupart des logiciels Debian se basent sur la base de ca-certificates, mais iceweasel a une sorte de « cache utilisateur » qui fait que les certificats ajoutés/enlevés à ca-certificates ne sont pas vraiment répliqués dans ce cache. D'après ce que j'ai compris, ma complication est due au fait que j'ai upgradé iceweasel depuis des version assez anciennes (squeeze) et que le format de ce cache a changé, mais j'ai eu du mal à faire marcher le bousin (il y a cert8.db et key3.db dans votre profil, et cert9.db et key4.db — le nouveau format à priori — dans ~/.pki/nssdb ; mais les deux ont des mtime récent, donc je ne sais pas ce que fait iceweasel exactement).
La seule solution qui a fonctionné pour moi est de manuellement importer un CA dans iceweasel (Préférences -> Avancé -> Afficher les certificats -> Autorités -> Importer).
De le même manière que l'on te dis rarement de qui tu es le client.
WTF ?
Pourquoi parler de moralité ? Les développeurs de Mozilla tuent des chatons devant les mamans chats chaque soir. Qu'est-ce que ça m'apporte ou m'enlève ?
Parce que le Libre, dans ses fondamentaux, défend la vie privée. Qu'ils fassent des choses pas en rapport avec le Libre, je m'en branle effectivement, mais qu'ils contrent une des valeurs fondamentale d'un truc qu'ils disent défendre, ça me gène beaucoup.
De quel compromis parles-tu ?
Du compromis qui choisit de sacrifier la vie privée de ses utilisateurs pour avoir le petit pouvoir de pousser un web plus ouvert.
La seule chose de nouveau c'est toi qui ouvre les yeux.
Rha putain j'ai horreur des argumentations comme celle-ci ! Genre « je l'avais prédit, t'es trop con de ne pas t'en être rendu compte », c'est abjecte et complètement présomptueux. Les gens qui réfléchissent comme toi sont ceux qui font perdre le libre car ils ne se rendent pas compte de la force de leur dédain : ça ne te rend pas juste supérieur aux autres, juste pour te la péter. Non, ça a réellement un impact fort sur beaucoup de gens plus faibles qui pensent que les gens comme toi sont des mecs trop forts qui savent deviner ce qui est bien, parce que tu es « pragmatique », « réaliste », que c'est « comme ça » et que si c'est la loi du plus fort qui s'impose, « c'est normal ». C'est faux.
Sincèrement intéresse toi aux choses avant de les juger et regarde la communication de Mozilla au sujet des DRM. Ils disent exactement ce que je dis "si on ne l'implémente pas, on perds des utilisateurs, si on perds trop d'utilisateurs, on ne pourra plus se battre sur d'autres front pour le web". J'invente rien, il n'y a rien de nouveau à part pour toi.
Ce qui est une grosse mentalité de merde. Je savais bien que la MoFo était déjà comme ça, ça ne fait que les enfoncer encore plus à mes yeux. Et se la jouer « réaliste » ne te rend pas meilleur, mais montre juste que tu es un bon suiveur comme tous les toutous adeptes de la compétition à outrance.
OK ton argument du coup c'est de mettre un couteau sous la gorge à tout le monde ?
Applique ton raisonnement pour le kernel, Debian, Gnome, et tu verras qu'il est inepte dans ces cas. Je n'ai pas vu de raison valable de faire une exception pour FF pour l'instant.
Ah ? si Mozilla représentait seulement 1% des utilisateurs, tu crois que ses représentants au W3C aurait autant de poids, autant de crédibilité dans les débats dans les groupes de travail ?
Oui peut-être, car il y a des mecs au W3C qui ne représentent quasiment personne à part eux, mais qui sont assez bon techniquement et qui contribuent pas mal aux standards. Ça se voit que tu dis ça sans rien connaître, donc tes moqueries à deux balles sont débiles.
J'aimerai bien savoir ou tu trouves la contradiction entre logiciel libre et le choix de Mozilla de faire financer le moteur de rechercher par défaut…
Je trouve ça plutôt logique moi…
Par hasard parce que un des buts premiers du Logiciel Libre, c'est de protéger ta liberté, et que avoir une vie privée fait partie des libertés fondamentales humaines ? Un logiciel libre te permet de savoir ce qu'il fait de tes données, contrairement à un logiciel propriétaire. Et en général, les logiciels libres sont faits de manière à protéger ta vie privée (cf les conditions d'acceptation de la plupart des distributions ; je ne connais pas de distro qui dit qu'ils acceptent volontiers des logiciels qui diffusent ta vie privée). Ici, on voit clairement que ça n'est pas le but de Mozilla.
Ce n'est pas à Mozilla de savoir ce que fait Google/Yahoo/… de tes données personnelles…
Heu… un peu quand même, s'ils veulent avoir une crédibilité : ils incitent les gens à aller donner leur vie privée à ces acteurs.
Si c'est un problème pour toi, c'est à toi de prendre des mesures… Les gens, pour la grande majorité s'en contre foute…
Ah, le classique « c'est pas mon problème », « je n'ai rien à me reprocher », « t'es qu'un extrémiste de la vie privée », etc.
Elle est simpliste est permet de rapidement faire adhérer les gens à son idée, mais elle est très loin d'aller au fond des choses.
Je pensais avoir pas mal argumenté à côté, quand même. Oui, c'était une accroche « facile ».
Oui on est le produit de Mozilla.
Puisque tu l'affirmes si directement, peux-tu me pointer l'endroit où c'est spécifié par la MoFo ? Est-ce un sous-entendu qu'il faut deviner quand on utilise ce logiciel ? Si c'est si peu mis en avant, que penser de la moralité de ceux qui font ce logiciel ? Est-ce qu'une cause comme celle du « web ouvert », aussi bonne soit-elle, peut se permettre ce genre de compromis ?
La force de Mozilla c'est son nombre d'utilisateur.
C'est nouveau, je pensais que c'était d'être un Logiciel Libre, qui promeut les standards ouverts du web.
C'est ce qui lui permet d'avoir le droit à la parole au W3C,
Je ne m'y connaît pas trop dans ce domaine, mais Mozilla n'a-t-il pas toujours eu une position importante dans cette institution ? Je sais que certaines contributions proviennent de Mozilla, mais de la à arguer que c'est dû à son nombre d'utilisateurs… ça me paraît un peu douteux.
[^] # Re: Nuances sur le nettoyage XSLT
Posté par benoar . En réponse à la dépêche LibreOffice 4.4 : sous le capot. Évalué à 2.
Tiens, je viens de penser qu'on pourrait utiliser des décorateurs avec des expressions XPath pour faire comme du XSLT… marrant comme idée.
[^] # Re: Nuances sur le nettoyage XSLT
Posté par benoar . En réponse à la dépêche LibreOffice 4.4 : sous le capot. Évalué à 2.
Je n'ai pas trop eu le problème, je me suis limité à XSLT v1, la v2 étant peu supportée par des outils libres. J'ai ressenti certains manques des fois, mais rien de trop important.
Moi je la trouve intuitive… Et du coup, c'est l'occasion de se mettre au fonctionnel !
Oui, mais on aborde le classique problème : doit-on utiliser des outils de merde (dans ce contexte) pour être accessible, ou doit-on demander à avoir un minimum d'initiation afin de pouvoir utiliser des choses plus adaptées, et sur le long terme, beaucoup plus efficaces ? Sur linuxfr, je pensais qu'on hésitait moins sur l'investissement dans des outils « complexes » si le jeu en vaut la chandelle…
Pour la génération de texte, effectivement, ça aiderait (c'est un handicap de XSLT aussi : il est plus à l'aise dans la génération de XML que de texte brut) ; j'aime beaucoup Jinja2. Par contre, pour le parsing de XML d'entrée, ça n'aidera en rien, et c'est surtout là-dessus que Python pêche, je trouve.
[^] # Re: Nuances sur le nettoyage XSLT
Posté par benoar . En réponse à la dépêche LibreOffice 4.4 : sous le capot. Évalué à 2.
Oui enfin dans ce cas, la bonne solution est d'en faire une bonne bibliothèque, comme pour les autres langages… mais c'est vrai qu'à ce niveau (ressources externes en extensions XSLT), le langage est malheureusement peu pourvu.
C'est vrai que dans ce genre de cas, je comprends que XSLT ne soit plus adapté.
Par contre, n'existe-t-il pas un « mode de traitement » des données arborescentes à la XSLT dans d'autres langage ? Je le trouve tellement efficace que je me vois mal m'en passer maintenant dans les autres langages…
[^] # Re: Nuances sur le nettoyage XSLT
Posté par benoar . En réponse à la dépêche LibreOffice 4.4 : sous le capot. Évalué à 4.
Si tu parles du fait que le code Python fait moins de choses dans le cas qui nous concerne, et est donc naturellement plus court, c'est le point principal que je voulais montrer, effectivement.
Ouch, ça fait mal, oui.
Bon, ça c'est vrai que ça semble un petit peu limité, et que je n'ai pas rencontré ce besoin encore, mais que ça serait handicapant.
Mmmhh… dans les exemples que j'ai vu, je ne vois pas en quoi un code procédural serait plus lisible.
Ça c'est clair que ça doit être rédhibitoire quand tu en as besoin.
Encore une fois, je ne vois pas trop la différence. À moins que ça soit pour quelqu'un qui connaît mal XSLT, mais la critique peut alors valoir pour n'importe quel langage.
J'ai effectivement un petit peu vécu ça,
xsltprocque j'utilise pourrait être plus explicite sur certaines erreurs (comme quand tu appelles une template qui n'existe pas quand tu t'es trompé dans le nom).J'avoue ne pas avoir eu de problème avec ça, vu que mes fichiers sont de taille raisonnable.
Oui, la verbosité n'aide vraiment pas. Mais ce qui me plaît vraiment et qu'on ne retrouve pas ailleurs, c'est la logique de parsing du langage : c'est hyper-bien adapté à du parcours d'arbre, et le matching est super pratique pour spécialiser certains cas. Ce genre de chose serait horrible à faire avec un autre langage. Tout ça se rapproche du fonctionnel, qui n'est pas facile à comprendre quand on est pas habitué, mais une fois que tu l'as saisi, ça simplifie tellement de choses…
En fait, il faudrait juste une version moins verbeuse. J'ai pensé à du YAML pour décrire les XSLT, je ne sais pas si ça pourrait le faire.
Merci pour ces remarques en tous cas, assez justes.
[^] # Re: Nuances sur le nettoyage XSLT
Posté par benoar . En réponse à la dépêche LibreOffice 4.4 : sous le capot. Évalué à 9.
Ça tombe bien, il se trouve que j'ai déjà fait du COBOL : peut-être que niveau employabilité, ça le fait mieux (et encore, vu les usines à gaz Java qui touchent du XML, ça ne m'étonnerait pas que le XSLT soit populaire en entreprise bien que peu visible dans le libre, tout comme le COBOL), mais niveau « facilité » du langage, ça n'a rien à voir. Le XSLT est bien plus accessible et moderne (un langage plutôt déclaratif, quand même !) et, comme je le disais, apprenable assez facilement. Alors on peut mettre en face le fait que peu de monde le connaisse à priori, mais y mettre du Python et tous les risques associés que j'ai cité, ça ne me semble pas une très bonne idée.
Le code supprimé aurait très bien pu l'être dans sa forme XSLT, ça serait revenu au même, tout en gardant un langage fait pour ce travail. J'adore le Python, vraiment, mais pour certaines utilisations, il n'est vraiment pas adapté.
Après, tout ça c'est pour importer du OOXML, alors je pourrais m'en foutre aussi, mais bon, le XSLT m'a un peu appris le masochisme /o\
# Nuances sur le nettoyage XSLT
Posté par benoar . En réponse à la dépêche LibreOffice 4.4 : sous le capot. Évalué à 10.
Alors, faisant actuellement de la génération de code à base de XSLT pour un projet, ce refactoring m'a intrigué : me serais-je trompé d'avoir utilisé un langage déclaratif alors que j'aime pourtant bien Python ? Je suis donc allé voir de plus près.
J'ai pris un exemple de complexité moyenne, mais regardons par exemple le code original en XSLT :
http://cgit.freedesktop.org/libreoffice/core/tree/writerfilter/source/ooxml/factoryimpl_ns.xsl?id=21977778168af134e7f72afcc07ff5062324a19d#n183
avec la version convertie en Python :
http://cgit.freedesktop.org/libreoffice/core/tree/writerfilter/source/ooxml/factoryimpl_ns.py?id=6c4de449094048465b81abf93139bb5950fa12c9#n128
Franchement, la différence de lisibilité et la soi-disant facilité de « hackage » ne sautent pas aux yeux. Certes il faut connaître XSLT pour mieux le « parser » visuellement, et passer outre sa verbosité, qui doit être son plus gros défaut, mais sinon je trouve la matching des balises avec DOM est vraiment horrible à lire. Tellement que ça doit amener des bugs : le getElementsByTagName() ligne 147 me semble faux, le XSLT ne va chercher que les enfants directs. De plus, tous les anciens cas ne sont pas gérés : rien pour un "refdefine" nul (c'est peut-être une hypothèse assumée, mais pas précisée). Et au passage on perd complètement la notion d'espace de nommage pour les tags ! La verbosité de l'API du DOM pour ça vis à vis de XPath ne doit pas y être pour rien…
En parlant d'API, Miklos les mélange d'ailleurs allègrement ; on passe à SAX pour un autre fichier (qui fait encore une fois des hypothèses plus stricte sur les entrées, les "fastoken" hors d'un "model" étant potentiellement traités, de manière erronée) :
http://cgit.freedesktop.org/libreoffice/core/commit/writerfilter/source/ooxml?id=dd5dfc8e2a0fc3c0307c0a782ae563b79ba8a84e
Ce qui fait qu'on peut potentiellement avoir des documents qui ne valident pas, vu que ce genre de parser ne permet plus d'assurer la bonne forme du document…
Ah mais en fait, la conversion précédente amène un bug, qui complique le code python encore plus, corrigeons-le :
http://cgit.freedesktop.org/libreoffice/core/commit/?id=63cd667ccb35325a973cf4f98c5e1bf9db92b9b4
Voilà les joies de la conversion. Là où la nouvelle de linuxfr se fourvoie par contre — même si ça vient certes du blog de l'auteur, et qu'on ne vérifie pas forcément la véracité de sources aussi proches — c'est que la réduction du code XSLT ne vient pas de la supposée concision de Python pour ce genre de travail, mais juste de simples suppressions de code ! Le code précédent a par exemple simplement été retiré :
http://cgit.freedesktop.org/libreoffice/core/commit/writerfilter/source/ooxml?id=2046fcd907fe8c0217c5cd43be8420859a0ad435
Et de même pour un paquet d'autres. Et la réduction du gros paquet de code généré vient principalement parce qu'on a implémenté moins de choses dans la version python que dans la version XSLT.
Bref, je peux très bien comprendre l'argument de la non-popularité de XSLT pour passer à un langage comme Python, mais d'un côté, ça s'apprend très vite (il y a deux semaines, je n'en avait jamais fait), et c'est un langage très adapté quand on tripote du XML, avec toutes les contraintes que ça amène, et toutes les facilités qu'offre un langage fait pour. En tous cas, les réductions en taille de code présentées n'ont rien à voir avec le fait que ça soit du XSLT. Je suppose que Miklos n'aimait pas, et en a profité pour cracher dessus, de manière fallacieuse.
Mangez du XSLT (mais seulement si vous faites du XML, hein, il ne faut pas être maso non plus), c'est bon.
[^] # Re: Dividende universelle
Posté par benoar . En réponse à la dépêche GnuPG utilisé, GnuPG oublié, mais GnuPG financé. Évalué à 2.
Je ne sais pas comment les prévenir, mais le site d'OpenUDC a l'air de s'être fait méchamment pirater…
[^] # Re:Propreté,standardisation et scraping
Posté par benoar . En réponse à la dépêche Création d'entreprise et logiciel libre - Romain Bignon de la société Budget Insight. Évalué à 2.
Ces exemples sont assez affligeants, mais il y a des bonnes banques, non ? Je sais que le Crédit Coopératif fonctionne avec un sésame depuis des années, et ça me semble quelque chose de plutôt bien sécurisé. Après, c'est clair que les banques ont une guerre de retard niveau accessibilité et interopérabilité, mais ça m'effraie que tu aies un avis si négatif sur l'ensemble de la profession. Crois-tu que les bons élèves soient des exceptions ?
Merci pour ce témoignage. Je ne connais pas le système en détail, j'ai juste regardé à droite à gauche, mais je pensais qu'il était quand même mieux fait que ça… c'est triste en 2015.
C'est hallucinant quand on voit que du côté de leur réseaux internes, avec SWIFT et compagnie, le HFT, etc, ils sont super à la pointe, mais que pour leurs clients « dans la vie réelle », ils ne font aucun effort.
[^] # Re: Propreté, standardisation et scraping
Posté par benoar . En réponse à la dépêche Création d'entreprise et logiciel libre - Romain Bignon de la société Budget Insight. Évalué à 2.
Quand on passe par un service de paiement intermédiaire, qui est souvent indiqué, on est sûr qu'ils ne stockent pas. Sinon, quand c'est un petit site, en général ils ne stockent pas non plus à long terme, car ils n'ont pas les moyens. Certains autres sites, c'est par « réputation », ou plutôt que je me suis renseigné sur leurs méthodes. Ce qui ne laisse pas grand chose d'autre à part ceux qui sont connus pour ça, comme Paypal ou Amazon, que je n'utilise jamais.
Certes, je ne suis pas du genre à tester des nouveaux magasins tous les quatre matins, mais j'arrive à voir à l'avance, ou alors on s'en rend compte au milieu de la procédure (genre « enregistrer ma carte » dans son compte client). Ceux qui ne le disent pas et le font, ça m'est juste arrivé pour un, je ne recommande pas chez eux.
# Propreté, standardisation et scraping
Posté par benoar . En réponse à la dépêche Création d'entreprise et logiciel libre - Romain Bignon de la société Budget Insight. Évalué à 6.
Je comprends un peu parfois le côté « repoussant » de faire du scraping de sites de banques pour en extraire le contenu, quand linuxfr est rempli de moules « puristes ». C'est là-dessus que viennent la plupart des critiques, je pense.
Cependant, je dois reconnaître que vu la non-coopération des banques à ce sujet, le fait que weboob fasse pression avec cette méthode crade n'est pas inutile. Par contre, c'est clair que même si les méthodes de rétention des banques sont dégueulasses, leurs craintes sur la sécurité ne sont à mon avis pas infondées : on peut le voir avec toutes les failles de sécurité qui ont conduit à des fuites de numéro de carte bancaire ou d'informations personnelles récemment par exemple.
À ce propos, il faut noter que ces problèmes sont arrivés à des sites qui stockaient localement les numéros de carte bancaire : il me semble que la certification PCI-DSS interdisait ce genre de pratique, justement pour éviter ces déconvenues. Et on voit que les banques n'avaient pas complètement tort d'interdire ces pratiques (perso, je ne comprends pas comment on peut laisser faire ça ; je quitte tout site qui le fait : certes, un site peut garder temporairement le numéro s'il fait lui-même la transaction au lieu de passer par un service ters, mais pas plus longtemps que le temps d'effectuer la transaction).
Maintenant, on voit que le fait d'empêcher les gens d'accéder à leur données pour raison de sécurité (un peu abusivement : c'est très utile pour proposer sa solution propriétaire très chère, aussi) n'a fait « qu'empirer » le problème de sécurité avec des logiciels comme weboob, qui font ce que les gens voudraient vraiment (accéder simplement à leurs données de manière automatique, indépendamment de la banque), même si c'est au dépend des procédures de sécurité voulues par la banque. J'espère qu'elles vont se réveiller et développer des systèmes interopérables et avec sécurité « intégrée » (surtout des conseils sur le workflow des données, sur la manière de stocker, etc). Les API qui sont offertes par certaines banques, comme indiqué dans la dépêche, sont peut-être bien mais à mon avis pas encore standards (quand on voit le SEPA qui aurait pu en profiter pour faire quelque chose de bien, mais non, les méta-données des virements ne sont même pas standardisée dans leur interface avec l'utilisateur…), et surtout doivent manquer de procédures quant à la sécurité de la gestion des données (certes, je parle sans connaître pour ce point : quelqu'un a plus d'infos ?).
[^] # Re: trop tôt
Posté par benoar . En réponse au journal Faille de sécurité glibc. Évalué à 6.
Ah ouai donc maintenant des boîtes de sécu embauchent des boîtes de communication pour annoncer les failles ? Tu m'étonnes du fail…
# Sans le bullshit marketing
Posté par benoar . En réponse au journal Faille de sécurité glibc. Évalué à 1.
Cette annonce ne sert strictement à rien techniquement parlant et fait sa promo de manière tellement éhontée…
Voir https://sourceware.org/bugzilla/show_bug.cgi?id=15014 pour une exploitation du bug, et https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-0235 pour le patch.
En résumé, avec une taille insuffisante du buffer passé à gethostbyname_r(), pour faire des résolutions inverse de nom, on peut éventuellement exécuter du code. Mouai. C'est un buffer dont la taille et l'allocation n'est pas contrôlée par l'utilisateur, seul l'IP à résoudre le sera éventuellement. Bref, c'est assez mince comme faille.
[^] # Re: Mais encore?
Posté par benoar . En réponse à la dépêche Sortie de la version 2.5 de Chouette. Évalué à 2.
Merci, c'est cette description qui aurait dû être dans la dépêche, c'est beaucoup plus clair comme ça.
[^] # Re: une solution
Posté par benoar . En réponse au message intel intrinsics. Évalué à 2.
Qu'est-ce que c'est moche par rapport aux intrinsics Altivec. À chaque fois que je lis du code SSE, je regrette la desparition des PPC…
[^] # Re: Fonctionnalités clées.
Posté par benoar . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 4.
Effectivement. Même pas un ^C pour arrêter le machin qui foire ? Ça fait peur.
[^] # Re: Fonctionnalités clées.
Posté par benoar . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 3.
Tu peux préciser comment ça se passe quand tu as un tel problème ? Pour moi, c'est un des problèmes majeurs que j'ai avec systemd : je n'ai pas envie de faire beta-testeur de fonctionnalités qui font revenir plus de 10 ans en arrière (devoir rebooter parce qu'un soft est buggé ?!…).
Ça plus le fait que networkd, par exemple, ne va sûrement pas gérer mes confs réseau « exotiques » (à l'époque, j'avais fait un patch pour ignorer les bridge dans network-manager, version 0.8 ; j'ai vu que la version « courante » à ce moment-là était un cran au-dessus, et que l'API avait complètement changé, ce qui faisait que mon travail était inutile : ça m'a bien calmé, j'ai laissé tomber).
[^] # Re: On en parle dans la fonction publique..
Posté par benoar . En réponse au journal Le début de la fin du vote électronique. Évalué à 3.
Bien sûr (même si c'est faux pour Facebook qui va suivre ta navigation, au moins). Mais je ne peux en être sûr que si j'ai une confiance totale dans mon établissement pour ce scrutin et dans le prestataire du système de vote, car ils pourraient coopérer pour s'échanger des informations sur mon vote. Bien sûr, ça serait faisable même sans SSO, avec le système de numéro envoyé par la Poste qu'ils proposent à d'autres, c'est juste que là ça fait tellement « visible » que ça en est ridicule.
[^] # Re: On en parle dans la fonction publique..
Posté par benoar . En réponse au journal Le début de la fin du vote électronique. Évalué à 3.
Pareil ici, sauf que c'est la première fois. Et pour éviter d'avoir à gérer un « espace électeur », ils ont eu la géniale idée de relier le système de vote… au SSO de l'établissement ! Et après, ils nous disent que les votes sont « anonymes »…
La CGT-SUD s'est opposée au vote électronique au départ (pas les autres d'après ce que j'ai lu) mais s'y est résignée. En signe de « protestation », ils invitent les gens à aller voter dans l'isoloir qu'ils ont réclamé pour mettre autour de la machine physique dédiée (un PC de l'établissement avec son navigateur qui pointe sur le site de vote) au lieu de leur machine. Vive la contestation…
Pour info, la société choisie est Neovote (.com).
[^] # Re: Ca ne règle pas la source du problème
Posté par benoar . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 2.
Merci, tu as bien résumé ma pensée, avec un ton très intelligent et mesuré, j'aime bien ça.
C'est effectivement problématique qu'il y ait des attaques agressives des deux côtés. Mais laissons les méchants cracher leur bile, et trollons ensemble gentiment dans la joie !
Perso, j'attends de voir si
uselessddevient une alternative potable, il me semble vraiment intéressant.[^] # Re: Pour Debian et Archlinux
Posté par benoar . En réponse au journal Il est temps que vous ayez un meilleur HTTPS. Évalué à 2.
Attention à l'interaction du paquet ca-certificates et de iceweasel : la plupart des logiciels Debian se basent sur la base de ca-certificates, mais iceweasel a une sorte de « cache utilisateur » qui fait que les certificats ajoutés/enlevés à ca-certificates ne sont pas vraiment répliqués dans ce cache. D'après ce que j'ai compris, ma complication est due au fait que j'ai upgradé iceweasel depuis des version assez anciennes (squeeze) et que le format de ce cache a changé, mais j'ai eu du mal à faire marcher le bousin (il y a cert8.db et key3.db dans votre profil, et cert9.db et key4.db — le nouveau format à priori — dans ~/.pki/nssdb ; mais les deux ont des mtime récent, donc je ne sais pas ce que fait iceweasel exactement).
La seule solution qui a fonctionné pour moi est de manuellement importer un CA dans iceweasel (Préférences -> Avancé -> Afficher les certificats -> Autorités -> Importer).
[^] # Re: C'est nous le produit ?
Posté par benoar . En réponse au journal Yandex, Baidu et Yahoo, un point commun ?. Évalué à 2.
WTF ?
Parce que le Libre, dans ses fondamentaux, défend la vie privée. Qu'ils fassent des choses pas en rapport avec le Libre, je m'en branle effectivement, mais qu'ils contrent une des valeurs fondamentale d'un truc qu'ils disent défendre, ça me gène beaucoup.
Du compromis qui choisit de sacrifier la vie privée de ses utilisateurs pour avoir le petit pouvoir de pousser un web plus ouvert.
Rha putain j'ai horreur des argumentations comme celle-ci ! Genre « je l'avais prédit, t'es trop con de ne pas t'en être rendu compte », c'est abjecte et complètement présomptueux. Les gens qui réfléchissent comme toi sont ceux qui font perdre le libre car ils ne se rendent pas compte de la force de leur dédain : ça ne te rend pas juste supérieur aux autres, juste pour te la péter. Non, ça a réellement un impact fort sur beaucoup de gens plus faibles qui pensent que les gens comme toi sont des mecs trop forts qui savent deviner ce qui est bien, parce que tu es « pragmatique », « réaliste », que c'est « comme ça » et que si c'est la loi du plus fort qui s'impose, « c'est normal ». C'est faux.
Ce qui est une grosse mentalité de merde. Je savais bien que la MoFo était déjà comme ça, ça ne fait que les enfoncer encore plus à mes yeux. Et se la jouer « réaliste » ne te rend pas meilleur, mais montre juste que tu es un bon suiveur comme tous les toutous adeptes de la compétition à outrance.
[^] # Re: C'est nous le produit ?
Posté par benoar . En réponse au journal Yandex, Baidu et Yahoo, un point commun ?. Évalué à 0.
OK ton argument du coup c'est de mettre un couteau sous la gorge à tout le monde ?
Applique ton raisonnement pour le kernel, Debian, Gnome, et tu verras qu'il est inepte dans ces cas. Je n'ai pas vu de raison valable de faire une exception pour FF pour l'instant.
[^] # Re: C'est nous le produit ?
Posté par benoar . En réponse au journal Yandex, Baidu et Yahoo, un point commun ?. Évalué à -1.
Oui peut-être, car il y a des mecs au W3C qui ne représentent quasiment personne à part eux, mais qui sont assez bon techniquement et qui contribuent pas mal aux standards. Ça se voit que tu dis ça sans rien connaître, donc tes moqueries à deux balles sont débiles.
[^] # Re: C'est nous le produit ?
Posté par benoar . En réponse au journal Yandex, Baidu et Yahoo, un point commun ?. Évalué à 5.
Par hasard parce que un des buts premiers du Logiciel Libre, c'est de protéger ta liberté, et que avoir une vie privée fait partie des libertés fondamentales humaines ? Un logiciel libre te permet de savoir ce qu'il fait de tes données, contrairement à un logiciel propriétaire. Et en général, les logiciels libres sont faits de manière à protéger ta vie privée (cf les conditions d'acceptation de la plupart des distributions ; je ne connais pas de distro qui dit qu'ils acceptent volontiers des logiciels qui diffusent ta vie privée). Ici, on voit clairement que ça n'est pas le but de Mozilla.
Heu… un peu quand même, s'ils veulent avoir une crédibilité : ils incitent les gens à aller donner leur vie privée à ces acteurs.
Ah, le classique « c'est pas mon problème », « je n'ai rien à me reprocher », « t'es qu'un extrémiste de la vie privée », etc.
[^] # Re: C'est nous le produit ?
Posté par benoar . En réponse au journal Yandex, Baidu et Yahoo, un point commun ?. Évalué à 1.
Je pensais avoir pas mal argumenté à côté, quand même. Oui, c'était une accroche « facile ».
Puisque tu l'affirmes si directement, peux-tu me pointer l'endroit où c'est spécifié par la MoFo ? Est-ce un sous-entendu qu'il faut deviner quand on utilise ce logiciel ? Si c'est si peu mis en avant, que penser de la moralité de ceux qui font ce logiciel ? Est-ce qu'une cause comme celle du « web ouvert », aussi bonne soit-elle, peut se permettre ce genre de compromis ?
C'est nouveau, je pensais que c'était d'être un Logiciel Libre, qui promeut les standards ouverts du web.
Je ne m'y connaît pas trop dans ce domaine, mais Mozilla n'a-t-il pas toujours eu une position importante dans cette institution ? Je sais que certaines contributions proviennent de Mozilla, mais de la à arguer que c'est dû à son nombre d'utilisateurs… ça me paraît un peu douteux.
C'est clair, d'après ce deal.