Puisque pour 2 écrans et un pied on est largement plus chère que ce soit chez rueducommerce, amazon, …
Heu… en suivant le premier lien, par exemple, on est à 300 € au lieu de 365 € si tu prends les même séparés, ce qui n'est pas « largement » plus cher je trouve.
Si tu vois du beaucoup plus cher, à mon avis, c'est que tu ne compares pas avec les même écrans. D'un côté, c'est vrai que ceux du pack que tu présente ont l'air bien merdiques. Si tu veux deux bons écrans, tu on auras pour le double je pense.
Perso, j'aime bien logcheck qui me fait un rapport quotidien (si besoin) des choses « bizarres » qui arrivent dans les logs. Son inconvénient par contre est qu'il demande de mettre à jour les règles assez régulièrement si on ne veut pas en arriver à ne plus le lire parce qu'il rapporte trop de choses : il faut lui dire d'ignorer les choses qu'on sait bénignes au fur et à mesure.
Ça n'est pas de la sécurité préventive, mais c'est toujours utile.
Je connais encore mal le domaine, mais il me semble que des OS pour STM32 (ou autre micro-contrôleur), on en trouve à la pelle¹… Le tiens a-t-il quelque-chose de spécial en dehors de ce qui existe déjà ? Ou c'est juste pour s'amuser ?
En passant, je mets un référence vers un « OS » un peu différent, basé également sur un STM32F103, qui ne gère que l'ordonnancement de threads et c'est tout : Chopstx https://gitorious.org/chopstx/
Il a été écrit pour le projet GnuK http://www.fsij.org/gnuk/, qui utilisait auparavant ChibiOS/RT http://www.chibios.org/, un truc un peu plus lourd. Je le trouve intéressant car il n'essaye pas de réinventer une couche d'abstraction.
Un facteur qui puisse expliquer ce choix: est ce que l'on peut debugguer du XSLT?
Pas super facilement en effet. Je comprends que ça joue un peu contre lui. Perso, je le fais avec les messages la plupart du temps assez clair de l'interpréteur (xsltproc) et des <xsl:message> placés aux endroits stratégiques. Mais ça n'est clairement pas idéal.
En fait le problème que j’avais eu à l’époque avec Xslt, c’est que le découpage fonctionnel est beaucoup moins évident à voir et à faire que dans un langage impératif. Or, le découpage fonctionnel, c’est un des critères principaux de lisibilité.
C'est le but des templates nommées. Après, c'est vrai qu'en XSLT on privilégie un maximum les templates « matchées », dont le découpage est alors imposé par la structure du document, c'est vrai.
L’autre gros soucis, c’est qu’il est facile d’avoir des effets de bord globaux sans le faire exprès --> ça, c’est terrible pour la maintenance. À chaque modification de la feuille, tu pries (et en plus, on n’avait pas TUs corrects derrière).
Mmhh… je n'ai pas vraiment eu le cas, mais je crois imaginer le danger que tu évoques. Ça me paraît quand même d'une probabilité assez faible à moins d'avoir des documents à traiter ayant une structure vraiment casse-gueule. Mais j'avoue ne pas avoir assez de pratique pour savoir si c'est courant ou pas.
En tous cas, c'est clair qu'avec du XSLT, tu lies pas mal la structure du « code » avec celle du document que tu as à traiter. Ça fait partie de ses forces, dans le sens où sa méthode de parsing devient « claire » quand tu imagines bien la structure du document, mais aussi de ses faiblesses dans le sens où il est difficile de faire quelque-chose d'arbitrairement différent, je pense.
On retrouve le même genre de choses chez prolog, erlang (je crois), ou dans une certaine mesure les templates c++.
Whoua, des langages tout aussi populaires que XSLT ! Si c'est ça les alternatives… je vais peut-être rester sur XSLT :-)
Plus sérieusement par contre, ce que j'évoque c'est le pattern matching + récursion « automatique » façon arbre. Je ne les vois pas trop dans ceux que tu cites (le prolog pour la récursion en arbre, si, mais les autres… bon, je les connais moins aussi).
C’est très pratique pour certaines choses, très puissant, mais quand on en abuse, c’est facile d’arriver à des choses totalement illisibles.
Oui enfin XSLT ayant un périmètre d'utilité assez déterminé, je trouve qu'il est plus simple et moins « abusable » que ces langages à tout faire. Je le vois comme une sorte de “Domain Specific Language” pour le traitement d'arbres.
LibreOffice a quand même pas mal de tests autour de l'import des doc/docx et ça m'étonnerait que Miklos ait accepté une solution qui introduise des régressions.
Le code qu'il a enlevé n'a à priori pas introduit de régression, c'est seulement du code qui a été jugé « inutile » parce que les fonctionnalités n'étaient (apparemment) que peu utilisées dans les documents créées par MS Office, ou alors pas implémentées par MS, d'après ce que j'ai compris.
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.
[^] # Re: Support deux écrans
Posté par benoar . En réponse au message [MATERIEL] Acheter un dual Screen. Évalué à 2.
Heu… en suivant le premier lien, par exemple, on est à 300 € au lieu de 365 € si tu prends les même séparés, ce qui n'est pas « largement » plus cher je trouve.
Si tu vois du beaucoup plus cher, à mon avis, c'est que tu ne compares pas avec les même écrans. D'un côté, c'est vrai que ceux du pack que tu présente ont l'air bien merdiques. Si tu veux deux bons écrans, tu on auras pour le double je pense.
# Et logcheck pour les logs
Posté par benoar . En réponse à la dépêche Un peu plus de sécurité sous Linux. Évalué à 9.
Perso, j'aime bien
logcheckqui me fait un rapport quotidien (si besoin) des choses « bizarres » qui arrivent dans les logs. Son inconvénient par contre est qu'il demande de mettre à jour les règles assez régulièrement si on ne veut pas en arriver à ne plus le lire parce qu'il rapporte trop de choses : il faut lui dire d'ignorer les choses qu'on sait bénignes au fur et à mesure.Ça n'est pas de la sécurité préventive, mais c'est toujours utile.
[^] # Re: Lingua::Romana::Perligata
Posté par benoar . En réponse au journal Et vous, à votre avis, pour où commencer une quête pour une chaîne de compilation espérantophone ?. Évalué à 6.
« que de chique » ?! Faut qu'il retourne à l'école l'gadjo ! http://fr.wiktionary.org/wiki/que_tchi
# Un peu comme mr ?
Posté par benoar . En réponse au journal Gérer son espace de travail git avec "gws". Évalué à 2.
Je n'utilise pas, mais ça ressemble beaucoup à mr : http://myrepos.branchable.com/
# En version plus légère
Posté par benoar . En réponse à la dépêche Écrire son système d'exploitation - Partie 1 : préparer le terrain. Évalué à 2.
Je connais encore mal le domaine, mais il me semble que des OS pour STM32 (ou autre micro-contrôleur), on en trouve à la pelle¹… Le tiens a-t-il quelque-chose de spécial en dehors de ce qui existe déjà ? Ou c'est juste pour s'amuser ?
En passant, je mets un référence vers un « OS » un peu différent, basé également sur un STM32F103, qui ne gère que l'ordonnancement de threads et c'est tout : Chopstx https://gitorious.org/chopstx/
Il a été écrit pour le projet GnuK http://www.fsij.org/gnuk/, qui utilisait auparavant ChibiOS/RT http://www.chibios.org/, un truc un peu plus lourd. Je le trouve intéressant car il n'essaye pas de réinventer une couche d'abstraction.
1 : http://en.wikipedia.org/wiki/List_of_real-time_operating_systems
[^] # Re: Nuances sur le nettoyage XSLT
Posté par benoar . En réponse à la dépêche LibreOffice 4.4 : sous le capot. Évalué à 1.
Pas super facilement en effet. Je comprends que ça joue un peu contre lui. Perso, je le fais avec les messages la plupart du temps assez clair de l'interpréteur (xsltproc) et des <xsl:message> placés aux endroits stratégiques. Mais ça n'est clairement pas idéal.
[^] # Re: Nuances sur le nettoyage XSLT
Posté par benoar . En réponse à la dépêche LibreOffice 4.4 : sous le capot. Évalué à 3.
C'est le but des templates nommées. Après, c'est vrai qu'en XSLT on privilégie un maximum les templates « matchées », dont le découpage est alors imposé par la structure du document, c'est vrai.
Mmhh… je n'ai pas vraiment eu le cas, mais je crois imaginer le danger que tu évoques. Ça me paraît quand même d'une probabilité assez faible à moins d'avoir des documents à traiter ayant une structure vraiment casse-gueule. Mais j'avoue ne pas avoir assez de pratique pour savoir si c'est courant ou pas.
En tous cas, c'est clair qu'avec du XSLT, tu lies pas mal la structure du « code » avec celle du document que tu as à traiter. Ça fait partie de ses forces, dans le sens où sa méthode de parsing devient « claire » quand tu imagines bien la structure du document, mais aussi de ses faiblesses dans le sens où il est difficile de faire quelque-chose d'arbitrairement différent, je pense.
Whoua, des langages tout aussi populaires que XSLT ! Si c'est ça les alternatives… je vais peut-être rester sur XSLT :-)
Plus sérieusement par contre, ce que j'évoque c'est le pattern matching + récursion « automatique » façon arbre. Je ne les vois pas trop dans ceux que tu cites (le prolog pour la récursion en arbre, si, mais les autres… bon, je les connais moins aussi).
Oui enfin XSLT ayant un périmètre d'utilité assez déterminé, je trouve qu'il est plus simple et moins « abusable » que ces langages à tout faire. Je le vois comme une sorte de “Domain Specific Language” pour le traitement d'arbres.
[^] # Re: Nuances sur le nettoyage XSLT
Posté par benoar . En réponse à la dépêche LibreOffice 4.4 : sous le capot. Évalué à 2.
Le code qu'il a enlevé n'a à priori pas introduit de régression, c'est seulement du code qui a été jugé « inutile » parce que les fonctionnalités n'étaient (apparemment) que peu utilisées dans les documents créées par MS Office, ou alors pas implémentées par MS, d'après ce que j'ai compris.
[^] # 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.