Pardon ? Chez moi j'ai un joli fichier wmmintrin.h fourni par GCC, qui contient les fonctions C à appeler sur des données C, que le compilateur remplace par l'instruction AES-NI si elle est présente.
Idem avec la quasitotalité des fonctions vectorielles.
Au temps pour moi, je suis confus, quand j'ai regardé les intrinsics gcc j'ai eu la bêtise de le faire sur une machine où il y avait un vieux gcc (4.1.2).
Cela dit je serai curieux de savoir pourquoi ni openssl ni gnutls ne les utilisent (les deux libs font directement de l'assembleur).
Ou (corollaire) qui utilise ces intrinsics, puisque les deux principaux utilisateurs libres potentiels qui me viennent à l'esprit ne les utilisent pas…
Il n'y a que 6 commentaires sur la dépêche pour le moment (enfin ça va faire 7 avec le mien), du coup c'est pour ça que tu ne reproduit pas le bug, il en faut plusieurs centaines! Dès que les moules auront suffisamment commenté la dépêche, tous les Shinken de la planète planteront.
En fait en informatique le mot supervision est en général utilisé au sens de supervision de l'infrastructure (serveurs notamment) et des logiciels qui tournent dessus ("en général" est un euphémisme).
D'ailleurs regarde la catégorie de la dépêche (l'icône en haut à gauche représentant un oscilloscope bleu que quand on passe la souris dessus ça affiche "Supervision"), elle ne dit pas non plus ce qu'on doit superviser.
Du coup personnellement je pardonne les rédacteurs de la dépêche de ne pas avoir précisé. Mais c'est juste mon choix individuel.
++
il y aura certainement en Rust des fonctions intrinsics qui permettent d'appeler directement les opérations assembleur d'un chiffrement AES, comme il y en a déjà en C/C++ avec gcc et d'autres compilateurs
Eh bien figure-toi qu'il n'y en a pas non plus en C/C++ (et qu'il n'y en aura probablement jamais vu comment ces opcodes ont un usage très spécifique), c'est pour ça que quand on doit utiliser ce genre d'opcodes on le fait en assembleur.
Ce n'est pas parce que Rust, comme d'autres langages, donne accès aux opérations atomiques qu'il donnera accès à toutes les opérations des processeurs.
Pour illustrer, on peut prendre une opération beaucoup moins spécialisée: la rotation de bit, qui est un équivalent du décallage de bit (opérateurs << et >> en C, Java & co) mais où le bit qui disapraît à droite ou à gauche réapparait de l'autre côté. Ces opérations existent depuis plus de 30 ans dans tous les processeurs (à part peut-être certains RISC j'en sais rien), et il n'y a pas de méthode ou d'opérateur standard en C pour effectuer cette opération. Probablement parce qu'il est rare d'en avoir besoin à part dans des algos ultra optimisés. Et ça fait plus de 30 ans.
Et la rotation de bit, elle existe sur tous les processeurs, contrairement aux spécificités comme AESNI. Donc ce serait facile de fournir un langage fortement portable avec des rotations de bits. Pour AESNI en revanche…
plus le langage est de haut niveau plus il y a de comportements déclaratifs ou implicites
Je ne perçois pas bien ce que cela signifie concrètement.
Je veux dire que c'est plus simple d'auditer un switch case tout moche qu'un ensemble de méthodes surchargées (polymorphisme dynamique) qui prennent des lambda en paramètre.
Oui, bon, en gros tu dis que tu veux un truc sûr même si il ne répond plus au besoin initial. Facile!
D'ailleurs, je propose une solution sans Rust, sans Ada, sans Go et sans C¹:
Il suffit de débrancher l'électricité, de prendre une² feuille de papier et du crayon et de faire à la main, c'est possible et c'est juste moins performant. :-)
¹: je n'ai pas dit "sensé", j'ai dis "sans C"
²: ok, il va falloir plusieurs feuilles, et probablement une gomme également, mais ça reste juste une question de performance par rapport aux opcodes aesni
J'ai cité rust, comme j'aurais pu/du citer Ada, ou d'autres.
(…)
Sinon, non aucune foutre idée de comment ré implémenter cela en rust, je fuis le C comme bill gates.
C'est bien à ça que je réponds: tu dis que le problème vient de l'utilisation du C, mais tu ne connais pas le sujet et n'a pas envie de le connaître, sauf que justement on est en plein cœur d'une des rares utilisation actuelles ou le C et l'assembleur restent incontournables. Malgré leurs défauts (et là on s'en tape un en pleine face, c'est clair).
La crypto doit être à la fois optimisée en perfs, facile à auditer (plus le langage est de haut niveau plus il y a de comportements déclaratifs ou implicites) et disponible sur toutes les plateformes (Rust c'est 4 plateformes pour le moment, Ada je ne dis pas). C'est contraignant comme du réseau ou du noyau.
Sachant qu'en l'occurrence le bug n'était pas un problème de lecture dans un pointeur mal alloué qui se règlerait trivialement avec un array de plus haut niveau qui ferait lui-même le bound-check comme en Rust, en C++, en Pascal ou en Visual Basic. C'était l'oubli d'un sanity check sur la valeur lue dans le message réseau qui arrive, auquel le code a malheureusement¹ fait confiance aveuglément.
Je ne comprends pas bien ce que les les fonctions intrinsics de Rust apportent pour soit implémenter de la crypto avec les opcodes AESNI en Rust soit garantir que du code assembleur ajouté à un programme Rust ne contienne pas de buffer underrun.
On peut très bien implémenter AES en C, en Java, ou en OCaml. Ce que tu montres est le support d'une extension Intel pour accéléer AES, ce qui n'est absolument pas indispensable pour faire de la crypto.
Pour faire de la crypto en labo non, mais pour faire le site de vente en ligne ou d'une banque, je crains que si.
c'est juste pour avoir de meilleures performances que c'est fait en assembleur
Exactement. Juste, c'est le mot.
on peut mettre de l'assembleur inline dans du code Rust
Et l'assembleur mis en inline dedans, Rust s'assure qu'il n'y a pas de buffer overflow dedans ?
;-)
A t'on réellement besoin de le faire en C ?
(…)
Dit autrement, a quand une implémentation d'openssl en rust ?
Quand Rust sera prêt, peut-être… :-p
Plus sérieusement, c'est un peu naïf de dire qu'OpenSSL est écrit en C. Parce que quand tu fais de la crypto tu dois faire de l'assembleur, et du coup reposer sur un langage plus évolué que C pour tester tes accès mémoire est une vaste blague, puisque ça ne concerne pas tout ton code.
Et comme aujourd'hui il y a des nouvelles opérations dédiées à la crypto directement dans le processeurs et qu'elles changent à chaque nouvelle version des processeurs, l'assembleur a de beaux jours devant lui.
Après t'as des gens qui ont fait une lib ssl complète en Ada, t'en auras qui le feront en Rust un jour (en plus c'est cool), mais à côté des opcodes AES (ou même juste vectoriels) dans les processeurs, j'ai peur que le rapport de performance reste de 100 ou 1000…
Il y a même des indices concordants du fait que la DGSE alimente amicalement les bases de données américaines (probablement en échange d'un non moins amical droit de consultation).
Ah oui, dans ce cas, c'est certain. La préfecture de police n'aime déjà pas les manifestations sur la place de la Concorde, alors a fortiori tout près de l'Élysée, sans déclaration, ça risque d'être mal pris.
Pour les provinciaux qui ne comprendraient pas ton humour subtil: l'ambassade des États-Unis est précisément sur la place de la Concorde, cise à deux pas de l'Élysée (bref il y a "déjà" et "a fortiori" de trop dans la phrase).
Sachant que le lieu de manif proposé dans la dépêche et non déclarée à la Préfecture de Police est à quelques mètres de l'Élysée et à peine plus de la place Bauveau, je pense que la nervosité des forces de l'ordre est acquise d'avance.
Je me permets donc plutôt de conseiller de reporter cette manifestation au 11 février 2015, mais bon…
Et si quelqu'un vient quand même manifester ce soir place de la Concorde, Stéphane Fermigier du fait de son post ci-dessus encours 6 mois de prison et 75 k€ d'amende si j'en crois l'excellent Maître Éolas, quand bien même il s'agirait d'une apéritif sans revendication politique.
Concernant les sauvegardes, la méthode de Linus est stupide. T'as qu'à juste envoyer tes trucs importants par mail dans des headers, et zou, la NSA fait les sauvegardes pour toi.
Tu comptes le surcoût de temps de réponse lors de l'exécution du traitement, et juste ce surcoût là j'imagine.
Non parce qu'il y a le surcoût de complexité, de maintenabilité (pas seulement de l'appli mais aussi de toute la stack middleware), etc. et ceux-là ne sont pas négligeables. Ou du moins ils ne le sont pas dès que tu as passé les 8 semaines après la première livraison de ton appli en prod.
De plus envisager d'utiliser XA en batch de façon automagique dans un MDB, c'est faire l'hypothèse que tout le traitement tient dans une transaction. Et en général pour un batch c'est impossible. Sans parler du fait que même quand ça rentre (par miracle) dans les ressources allouables sur la base et ailleurs, c'est une mauvaise idée d'avoir un scope de transaction énorme.
Si c'est avoir des centaines de traitements d'informatique de gestion toutes les nuits avec des points de reprise pour que des exploitants puissent les relancer le matin (voire des pilotes la nuit) avec des consignes d'exploitation simples (j'ose pas écrire en français simplifié mais je le pense, ah bah si tiens je l'ai écrit), bah comment te dire que je me demande bien comment on peut faire ça avec Camel…
Je préfère de loin avoir le bidule JQM que le bidule Camel pour faire des batches, au sens que je viens de donner à batch. Malgré tous les défauts que j'ai cités plus haut.
Et le bouquin que tu cites il est cool à feuilleter, il présente des jolies briques de lego qu'on peut assembler pour faire des applications qui ressemblent à The Incredible Machine: c'est trop cool à regarder, c'est assez cool à construire, faut pas trop avoir à le maintenir plus d'un an et surtout, surtout, faut jamais avoir à l'exploiter quand un grain de sable rentre dans un rouage.
L'article que tu cites dit que l'API ProcessBuilder est moche et pleine de pièges. C'est vrai. Mais elle est utilisable quand on est obligé de lancer un fils en Java. Même si je reconnais préférer le faire en C qu'en Java.
Depuis Java 5 c'est possible avec un thread par fils. Les flux sont pas selectables mais on peut faire des i/o avec timeout dessus alors on s'en sort. D'ailleurs c'est pas on peut mais il faut, pour les raisons cités dans ton article (pour pas se le faire bourrer d'un coup en mémoire à la mort du process) et pour d'autres (pour pas freezer le fils).
Ok un thread par fils c'est beaucoup si tu comptes avoir des centaines ou des milliers de fils mais dans le cas présenté ici (lancer quelques batches en parallèle) je continue à trouver que c'est un moindre mal par rapport à se retrouver avec un batch qui OOM la JVM et et plante les autres batches. Quand c'est pas pire qu'un OOM (parce qu'encore un OOM c'est la roulette russe, t'as de grande chance de pas tomber sur une balle et que l'exception libère masse mémoire ou les autres batches).
Après si les flux étaient selectables ont pourrait mutualiser un fils sur plusieurs processus, ou au moins éviter l'inélégance de faire des read avec timeout alternativement sur out et err. Certes. Ça ne serait pas pour me déplaire.
Perso j'ai fait en Java 4 et en Java 5 (ou 6 je sais plus mais ça n'a pas d'importance de ce point de vue 6 = 5).
Avant Java 5, tu pouvais pas lire les flux avec timeout du coup t'avais le choix entre ne pas lire les flux et prier pour que le fils ne remplisse pas les buffers et ne se freeze pas, ou bien ne pas pouvoir tuer le fils s'il est trop long car tu étais bloqué dans la lecture des flux, ou encore avoir 3 ou 4 threads (je sais plus) juste pour gérer un flux.
Rien n'empêche d'avoir un job JQM qui lance une JVM externe, ce n'est pas l'esprit mais rien ne l'empêche.
Je pense qu'il y a une certaine valeur ajouté à ce qu'un framework de batches java prévoit et organise réellement le cas et ne se contente pas de laisser le développeur forker une JVM s'il en a envie en lui précisant que ce n'est pas l'esprit.
Tu tiens quelques lignes plus pas dans un commentaire à l'apologie de la beauté de Python les propos suivants, ils sont un peu excessifs mais ont le mérite d'assez bien exprimer les limiter de "ce n'est pas l'esprit mais rien ne l'empêche":
c'est peu brut de décoffrage en Java pour par exemple gérer une communication inter process ou gérer un verrou etc. Il faut tout se refaire à la main
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par DerekSagan . En réponse à la dépêche Nouvelle vulnérabilité dans l’implémentation OpenSSL. Évalué à 1.
Ah bah surtout une fois qu'on a éteint l'électricité et qu'on encode l'AES et le RSA à la main, ça, va y avoir de l'erreur humaine à gogo. :-)
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par DerekSagan . En réponse à la dépêche Nouvelle vulnérabilité dans l’implémentation OpenSSL. Évalué à 2.
Au temps pour moi, je suis confus, quand j'ai regardé les intrinsics gcc j'ai eu la bêtise de le faire sur une machine où il y avait un vieux gcc (4.1.2).
Cela dit je serai curieux de savoir pourquoi ni openssl ni gnutls ne les utilisent (les deux libs font directement de l'assembleur).
Ou (corollaire) qui utilise ces intrinsics, puisque les deux principaux utilisateurs libres potentiels qui me viennent à l'esprit ne les utilisent pas…
[^] # Re: explosion mémoire dû aux commentaires
Posté par DerekSagan . En réponse à la dépêche Shinken version 2.0. Évalué à 9.
Il n'y a que 6 commentaires sur la dépêche pour le moment (enfin ça va faire 7 avec le mien), du coup c'est pour ça que tu ne reproduit pas le bug, il en faut plusieurs centaines! Dès que les moules auront suffisamment commenté la dépêche, tous les Shinken de la planète planteront.
[^] # Re: Supervision oui, mais de quoi ?
Posté par DerekSagan . En réponse à la dépêche Shinken version 2.0. Évalué à 10.
En fait en informatique le mot supervision est en général utilisé au sens de supervision de l'infrastructure (serveurs notamment) et des logiciels qui tournent dessus ("en général" est un euphémisme).
D'ailleurs regarde la catégorie de la dépêche (l'icône en haut à gauche représentant un oscilloscope bleu que quand on passe la souris dessus ça affiche "Supervision"), elle ne dit pas non plus ce qu'on doit superviser.
Du coup personnellement je pardonne les rédacteurs de la dépêche de ne pas avoir précisé. Mais c'est juste mon choix individuel.
++
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par DerekSagan . En réponse à la dépêche Nouvelle vulnérabilité dans l’implémentation OpenSSL. Évalué à 0.
Ton modélisateur, dès qu'il sera au point, te vaudra le prix Nobel.
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par DerekSagan . En réponse à la dépêche Nouvelle vulnérabilité dans l’implémentation OpenSSL. Évalué à 1. Dernière modification le 10 avril 2014 à 21:23.
Eh bien figure-toi qu'il n'y en a pas non plus en C/C++ (et qu'il n'y en aura probablement jamais vu comment ces opcodes ont un usage très spécifique), c'est pour ça que quand on doit utiliser ce genre d'opcodes on le fait en assembleur.
Ce n'est pas parce que Rust, comme d'autres langages, donne accès aux opérations atomiques qu'il donnera accès à toutes les opérations des processeurs.
Pour illustrer, on peut prendre une opération beaucoup moins spécialisée: la rotation de bit, qui est un équivalent du décallage de bit (opérateurs << et >> en C, Java & co) mais où le bit qui disapraît à droite ou à gauche réapparait de l'autre côté. Ces opérations existent depuis plus de 30 ans dans tous les processeurs (à part peut-être certains RISC j'en sais rien), et il n'y a pas de méthode ou d'opérateur standard en C pour effectuer cette opération. Probablement parce qu'il est rare d'en avoir besoin à part dans des algos ultra optimisés. Et ça fait plus de 30 ans.
Et la rotation de bit, elle existe sur tous les processeurs, contrairement aux spécificités comme AESNI. Donc ce serait facile de fournir un langage fortement portable avec des rotations de bits. Pour AESNI en revanche…
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par DerekSagan . En réponse à la dépêche Nouvelle vulnérabilité dans l’implémentation OpenSSL. Évalué à 0.
Je veux dire que c'est plus simple d'auditer un switch case tout moche qu'un ensemble de méthodes surchargées (polymorphisme dynamique) qui prennent des lambda en paramètre.
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par DerekSagan . En réponse à la dépêche Nouvelle vulnérabilité dans l’implémentation OpenSSL. Évalué à 7.
D'ailleurs, je propose une solution sans Rust, sans Ada, sans Go et sans C¹:
Il suffit de débrancher l'électricité, de prendre une² feuille de papier et du crayon et de faire à la main, c'est possible et c'est juste moins performant. :-)
¹: je n'ai pas dit "sensé", j'ai dis "sans C"
²: ok, il va falloir plusieurs feuilles, et probablement une gomme également, mais ça reste juste une question de performance par rapport aux opcodes aesni
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par DerekSagan . En réponse à la dépêche Nouvelle vulnérabilité dans l’implémentation OpenSSL. Évalué à 4.
C'est bien à ça que je réponds: tu dis que le problème vient de l'utilisation du C, mais tu ne connais pas le sujet et n'a pas envie de le connaître, sauf que justement on est en plein cœur d'une des rares utilisation actuelles ou le C et l'assembleur restent incontournables. Malgré leurs défauts (et là on s'en tape un en pleine face, c'est clair).
La crypto doit être à la fois optimisée en perfs, facile à auditer (plus le langage est de haut niveau plus il y a de comportements déclaratifs ou implicites) et disponible sur toutes les plateformes (Rust c'est 4 plateformes pour le moment, Ada je ne dis pas). C'est contraignant comme du réseau ou du noyau.
Sachant qu'en l'occurrence le bug n'était pas un problème de lecture dans un pointeur mal alloué qui se règlerait trivialement avec un array de plus haut niveau qui ferait lui-même le bound-check comme en Rust, en C++, en Pascal ou en Visual Basic. C'était l'oubli d'un sanity check sur la valeur lue dans le message réseau qui arrive, auquel le code a malheureusement¹ fait confiance aveuglément.
C'est bien expliqué dans le lien plus haut, en même temps c'est tellement simple que ça se voit bien dans le correctif aussi (d'autant plus qu'il a été largement commenté ligne à ligne, probablement un effet médiatique ;-)):
https://github.com/openssl/openssl/commit/731f431497f463f3a2a97236fe0187b11c44aead
¹: exprès, disent les plus méfiants
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par DerekSagan . En réponse à la dépêche Nouvelle vulnérabilité dans l’implémentation OpenSSL. Évalué à 1. Dernière modification le 10 avril 2014 à 12:05.
Je ne comprends pas bien ce que les les fonctions intrinsics de Rust apportent pour soit implémenter de la crypto avec les opcodes AESNI en Rust soit garantir que du code assembleur ajouté à un programme Rust ne contienne pas de buffer underrun.
Mais je veux bien comprendre.
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par DerekSagan . En réponse à la dépêche Nouvelle vulnérabilité dans l’implémentation OpenSSL. Évalué à 3.
Pour faire de la crypto en labo non, mais pour faire le site de vente en ligne ou d'une banque, je crains que si.
Exactement. Juste, c'est le mot.
Et l'assembleur mis en inline dedans, Rust s'assure qu'il n'y a pas de buffer overflow dedans ?
;-)
[^] # Re: Remplacer l'assembleur par Ada ou Rust ?
Posté par DerekSagan . En réponse à la dépêche Nouvelle vulnérabilité dans l’implémentation OpenSSL. Évalué à 1.
Et encore j'ai pas linké la bonne implem, celle qui n'est vraiment pas possible d'écrire en Rust:
https://github.com/openssl/openssl/blob/master/crypto/aes/asm/aesni-x86_64.pl
[^] # Re: Debian compromis par la NSA ?
Posté par DerekSagan . En réponse à la dépêche Nouvelle vulnérabilité dans l’implémentation OpenSSL. Évalué à 10.
Factoriser un nombre premier grand ou petit est effectivement un problème qui ne sera jamais résolu, par définition.
C'est un peu comme tracer 7 lignes rouges perpendiculaires entre elles…
;-)
(désolé c'était un peu facile de profiter de ton raccourci)
[^] # Remplacer l'assembleur par Ada ou Rust ?
Posté par DerekSagan . En réponse à la dépêche Nouvelle vulnérabilité dans l’implémentation OpenSSL. Évalué à 3.
Quand Rust sera prêt, peut-être… :-p
Plus sérieusement, c'est un peu naïf de dire qu'OpenSSL est écrit en C. Parce que quand tu fais de la crypto tu dois faire de l'assembleur, et du coup reposer sur un langage plus évolué que C pour tester tes accès mémoire est une vaste blague, puisque ça ne concerne pas tout ton code.
Dit autrement, explique-moi comment tu ré-écris ça en Rust ou comment Rust s'assurera qu'il n'y a pas de buffer underrun dedans:
https://github.com/openssl/openssl/blob/master/crypto/aes/asm/aes-x86_64.pl
Et comme aujourd'hui il y a des nouvelles opérations dédiées à la crypto directement dans le processeurs et qu'elles changent à chaque nouvelle version des processeurs, l'assembleur a de beaux jours devant lui.
Après t'as des gens qui ont fait une lib ssl complète en Ada, t'en auras qui le feront en Rust un jour (en plus c'est cool), mais à côté des opcodes AES (ou même juste vectoriels) dans les processeurs, j'ai peur que le rapport de performance reste de 100 ou 1000…
# Merci pour ce résumé
Posté par DerekSagan . En réponse à la dépêche Leslie Lamport, prix Turing 2013. Évalué à 1.
Je ne le connaissais que pour LaTeX, et pourtant j'avais déjà utilisé d'autres de ces travaux. Je me coucherai moins bête ce soir. Merci.
[^] # Re: sympa mais ...
Posté par DerekSagan . En réponse à la dépêche Accès libre à la bibliothèque numérique d’ENI pendant 3 jours. Évalué à 3.
Troll tros gros. Passera pas. Et on n'est pas vendredi.
[^] # Re: Manifestation non déclarée
Posté par DerekSagan . En réponse à la dépêche Le jour de la riposte (« The Day We Fight Back ») contre la surveillance généralisée. Évalué à 4. Dernière modification le 11 février 2014 à 15:20.
Il y a même des indices concordants du fait que la DGSE alimente amicalement les bases de données américaines (probablement en échange d'un non moins amical droit de consultation).
[^] # Re: Manifestation non déclarée
Posté par DerekSagan . En réponse à la dépêche Le jour de la riposte (« The Day We Fight Back ») contre la surveillance généralisée. Évalué à 2.
Pour les provinciaux qui ne comprendraient pas ton humour subtil: l'ambassade des États-Unis est précisément sur la place de la Concorde, cise à deux pas de l'Élysée (bref il y a "déjà" et "a fortiori" de trop dans la phrase).
Et pour les provinciaux qui préfèrent un dessin, c'est ici: http://www.openstreetmap.org/?mlat=48.86770&mlon=2.32060#map=18/48.86770/2.32060
[^] # Re: Manifestation non déclarée
Posté par DerekSagan . En réponse à la dépêche Le jour de la riposte (« The Day We Fight Back ») contre la surveillance généralisée. Évalué à 6.
Sachant que le lieu de manif proposé dans la dépêche et non déclarée à la Préfecture de Police est à quelques mètres de l'Élysée et à peine plus de la place Bauveau, je pense que la nervosité des forces de l'ordre est acquise d'avance.
Je me permets donc plutôt de conseiller de reporter cette manifestation au 11 février 2015, mais bon…
Et si quelqu'un vient quand même manifester ce soir place de la Concorde, Stéphane Fermigier du fait de son post ci-dessus encours 6 mois de prison et 75 k€ d'amende si j'en crois l'excellent Maître Éolas, quand bien même il s'agirait d'une apéritif sans revendication politique.
[^] # Re: La nostalgie du minitel
Posté par DerekSagan . En réponse à la dépêche 0.h un weboob. Évalué à 10.
C'est du très beau troll de compétition ça. Ses poils c'est carrément des arbres…
[^] # Re: Obi-Wan Kenobi
Posté par DerekSagan . En réponse au sondage Vivez vous du libre?. Évalué à 2.
Concernant les sauvegardes, la méthode de Linus est stupide. T'as qu'à juste envoyer tes trucs importants par mail dans des headers, et zou, la NSA fait les sauvegardes pour toi.
[^] # Re: Questions
Posté par DerekSagan . En réponse à la dépêche JQM, un serveur de batchs asynchrones en Java. Évalué à 2.
Tu comptes le surcoût de temps de réponse lors de l'exécution du traitement, et juste ce surcoût là j'imagine.
Non parce qu'il y a le surcoût de complexité, de maintenabilité (pas seulement de l'appli mais aussi de toute la stack middleware), etc. et ceux-là ne sont pas négligeables. Ou du moins ils ne le sont pas dès que tu as passé les 8 semaines après la première livraison de ton appli en prod.
De plus envisager d'utiliser XA en batch de façon automagique dans un MDB, c'est faire l'hypothèse que tout le traitement tient dans une transaction. Et en général pour un batch c'est impossible. Sans parler du fait que même quand ça rentre (par miracle) dans les ressources allouables sur la base et ailleurs, c'est une mauvaise idée d'avoir un scope de transaction énorme.
[^] # Re: Intéressant
Posté par DerekSagan . En réponse à la dépêche JQM, un serveur de batchs asynchrones en Java. Évalué à 1. Dernière modification le 01 janvier 2014 à 23:36.
Ça dépend ce que t'appelles faire du batch.
Si c'est avoir des centaines de traitements d'informatique de gestion toutes les nuits avec des points de reprise pour que des exploitants puissent les relancer le matin (voire des pilotes la nuit) avec des consignes d'exploitation simples (j'ose pas écrire en français simplifié mais je le pense, ah bah si tiens je l'ai écrit), bah comment te dire que je me demande bien comment on peut faire ça avec Camel…
Je préfère de loin avoir le bidule JQM que le bidule Camel pour faire des batches, au sens que je viens de donner à batch. Malgré tous les défauts que j'ai cités plus haut.
Et le bouquin que tu cites il est cool à feuilleter, il présente des jolies briques de lego qu'on peut assembler pour faire des applications qui ressemblent à The Incredible Machine: c'est trop cool à regarder, c'est assez cool à construire, faut pas trop avoir à le maintenir plus d'un an et surtout, surtout, faut jamais avoir à l'exploiter quand un grain de sable rentre dans un rouage.
[^] # Re: de la pertinence d'une JVM permanente pour y exécuter les tâches longues et gourmandes
Posté par DerekSagan . En réponse à la dépêche JQM, un serveur de batchs asynchrones en Java. Évalué à 0.
L'article que tu cites dit que l'API ProcessBuilder est moche et pleine de pièges. C'est vrai. Mais elle est utilisable quand on est obligé de lancer un fils en Java. Même si je reconnais préférer le faire en C qu'en Java.
Depuis Java 5 c'est possible avec un thread par fils. Les flux sont pas selectables mais on peut faire des i/o avec timeout dessus alors on s'en sort. D'ailleurs c'est pas on peut mais il faut, pour les raisons cités dans ton article (pour pas se le faire bourrer d'un coup en mémoire à la mort du process) et pour d'autres (pour pas freezer le fils).
Ok un thread par fils c'est beaucoup si tu comptes avoir des centaines ou des milliers de fils mais dans le cas présenté ici (lancer quelques batches en parallèle) je continue à trouver que c'est un moindre mal par rapport à se retrouver avec un batch qui OOM la JVM et et plante les autres batches. Quand c'est pas pire qu'un OOM (parce qu'encore un OOM c'est la roulette russe, t'as de grande chance de pas tomber sur une balle et que l'exception libère masse mémoire ou les autres batches).
Après si les flux étaient selectables ont pourrait mutualiser un fils sur plusieurs processus, ou au moins éviter l'inélégance de faire des read avec timeout alternativement sur out et err. Certes. Ça ne serait pas pour me déplaire.
Perso j'ai fait en Java 4 et en Java 5 (ou 6 je sais plus mais ça n'a pas d'importance de ce point de vue 6 = 5).
Avant Java 5, tu pouvais pas lire les flux avec timeout du coup t'avais le choix entre ne pas lire les flux et prier pour que le fils ne remplisse pas les buffers et ne se freeze pas, ou bien ne pas pouvoir tuer le fils s'il est trop long car tu étais bloqué dans la lecture des flux, ou encore avoir 3 ou 4 threads (je sais plus) juste pour gérer un flux.
[^] # Re: de la pertinence d'une JVM permanente pour y exécuter les tâches longues et gourmandes
Posté par DerekSagan . En réponse à la dépêche JQM, un serveur de batchs asynchrones en Java. Évalué à 1.
Je pense qu'il y a une certaine valeur ajouté à ce qu'un framework de batches java prévoit et organise réellement le cas et ne se contente pas de laisser le développeur forker une JVM s'il en a envie en lui précisant que ce n'est pas l'esprit.
Tu tiens quelques lignes plus pas dans un commentaire à l'apologie de la beauté de Python les propos suivants, ils sont un peu excessifs mais ont le mérite d'assez bien exprimer les limiter de "ce n'est pas l'esprit mais rien ne l'empêche":