Je te rappelle donc que j'ai passé 13 ans à MS. A peu près 8 de ces années ont été passées à construire des fuzzing frameworks et fuzzers. SAGE j'ai revu son design, je l'ai utilisée de manière répetée moi-même, j'en ai parlé avec les auteurs directement, j'en ai parlé avec des dizaines de testeurs et ingénieurs sécurité qui l'utilisent, j'ai vu les bugs qu'il a trouvé, je sais exactement comment il fonctionne et ce qu'il faut pour qu'il fonctionne.
Pour résumer, on a Sage qui est apparemment génial, qui demande un bac+18 pour être mis en oeuvre, sur un sous-ensemble réduit de fonctionnalités.
Tu en sais quoi ? Tu n'a aucune idée de la manière de l'utiliser. Et devines quoi, tu as totalement tort.
Dans le monde réél, je ne crois pas avoir lu: "This bug has been found with Sage". Par contre, j'ai beaucoup lu "Alors le bug machin qui a été trouvé, on a essayé de le reproduire avec Sage, on a monitoré la fonction coupable et on a réussi à retrouver la faille, regardez comme Sage c'est génial et ça écrase les fuzzers".
1/3 des bugs trouvés dans les composants desktop & multimedia de Windows 7 l'ont été par SAGE. Ca inclue tout ce qui est PNG/JPG/MPG/… et bien plus, et c'était donc avant 2009, SAGE a été optimisé et amélioré depuis pour optimiser ses prioritizations de branches et sa manière de surveiller les processus.
Tu peux lancer SAGE sur Word ou Excel donc, c'est légérement plus qu'un soft de 8 lignes.
Tu as visiblement focalisé sur le fait que SAGE vient de MS Research, et donc est probablement juste un projet de recherche inutilisable dans le monde réel. Tu as faux sur toute la ligne, c'est un projet qui a été construit dans l'idée de l'utiliser en production, par des testeurs normaux, pour trouver des bugs, et il en trouve à la pelle.
J'ai dit plus haut que c'était le système le plus efficace que j'ai jamais vu, je dis ça en connaissance de cause. Je connais Sulley, Peach, AFL, SAGE, les fuzzers que j'ai construit moi-même, Codenomicon, … SAGE les éclate tous en ce qui concerne le fuzzing de fichiers (pour le traffic réseau c'est une autre pair de manche vu le coté transactionnel des protocoles réseaux)
SAGE va passer un fichier de base à ton soft(en réalité il y a un corpus, de manière à accélérer SAGE en utilisant plusieurs fichiers qui ensemble couvrent de base la majorité des branches). Il va regarder toutes les instructions que ton code éxécute pendant le parsing du fichier. Il va ensuite regarder quelles sont les branches de code qui pourraient être prises et qui ne l'ont pas été. Il va alors créer des fonctions mathématiques pour résoudre le problème suivant :
- a quoi devrait ressembler le fichier pour que la branche X soit éxécutée ?
Il va ensuite utiliser un solveur (Z3 de MS Research) pour résoudre cela, créer le fichier, et le repasser dans le soft.
Il fait ça constamment, pour au final éxécuter toutes les branches de ton code (idéalement, en asymptotique).
La différence avec AFL :
AFL fait un changement au hasard, et si une branche diffèrente est éxécutée, il fait un changement de plus, pour essayer d'avancer dans la nouvelle branche. C'est une méthode un peu à l'aveugle
SAGE sait exactement ce qu'il faut faire pour avancer dans une branche, de manière mathématique
SAGE a des limites : genre si t'as une one-way hash dans ton format, il ne va évidemment pas pouvoir faire une résolution pour trouver une valeur de hash correcte, et si il y a de la compression, cela ralentit SAGE de manière significative. Mais c'est de loin, très loin, le système de fuzzing le plus efficace que j'ai jamais vu( au point ou je préféres ne pas utiliser le mot fuzzing pour SAGE, parce que justement ce n'est pas aléatoire du tout), et j'ai passé la majorité de ma carrière sur ce sujet précis à MS.
Cette approche est une forme primitive de résolution de contraintes appliquée aux tests sécurité. Quelque chose que Microsoft fait depuis presque 10 ans avec SAGE :
Techniquement parlant oui ce serait idéal. Le problème est que ta méthode ajoute une étape pour tous les utilisateurs, ce qui garantit des problèmes car le papier avec la clé est perdu ou autre. Et cette étape devrait être ajoutée à tout le monde pour résoudre un problème qui ne touche que 1% des gens en gros… Bref en théorie bien, en pratique pas top.
Tu as oublié l'élément le plus important: La productivité des employés.
Quand aux éditeurs, le fait qu'ils se plaignent de piratage ne signifie pas forcément que la gestion de licence soit une partie importante du tco pour les entreprises, ces 2 choses ne sont pas liées.
a) T'as raison, c'est simple à régler et se sont des nuls
b) C'est pas aussi simple que cela
La vraie réponse ? J'en sais rien, mais j'ai tendance à me dire qu'ils ne sont pas tous stupides et que donc la résolution du problème est probablement plus complexe que cela.
Mais juste proposer (fortement) de ne pas imposer des polices exotiques dans les pdfs c'est un truc trop complexe sinon quelqu'un l'aurait fait ?
Oui ça l'est.
Parce que les employés, ils partent, de nouveaux arrivent, des internes sont mis sur la tâche chiante du jour. Ils ont 4233 règles à suivre, ils ne se souviennent que des plus importantes, ils créent un document 10% de leur temps si ça se trouve, c'est pas le coeur de leur métier.
Cette règle, tu crois qu'elle va être suivie tout le temps ? Evidemment que non.
Faudrait faire quoi alors ? Ecrire une plateforme qui automatise la vérification des PDFs ?
Qui va payer pour ?
Qui va la maintenir ?
Comment tu t'assures que tous les documents sont vérifiés par cette plateforme ?
etc…
Tu veux utiliser un système de pénalités plutôt que construire cette plate-forme ? Comment tu vas justifier ça aux employés ?
Tu as visiblement un gros problème à comprendre qu'il y a un facteur humain là dedans.
Tu es resté trop longtemps sous windows ou tout semble si compliqué.
Ah cette obsession de toute ramener a MS-Windows dés que j'ouvres la bouche… triste et inutile.
Tu peux te taper la tête contre les murs, en te disant que tous ces gens sont incroyablement stupides et incompétents, qu'au final c'est super simple et logique, qu'il suffit de faire X ou Y.
Ou tu peux te dire qu'au final, ces gens ne sont pas en moyenne plus bête que toi ou moi, ils sont allé dans les mêmes écoles que toi ou moi, ils ont certainement des compétence sur un sujet donné, et pas sur d'autres, comme toi et moi.
Tu peux te dire que si ce problème est systématique, qu'il est là depuis si longtemps, c'est que la solution n'est probablement pas si simple, sinon quelqu'un l'aurait déjà résolu ce problème.
Il n'y a qu'un geek/informaticien qui pensera à cette problématique de gérer plusieurs lecteurs PDFs, de savoir qu'il y a des polices intégrées dans des lecteurs, que les utiliser réduit la taille, et même que réduire la taille est important.
Ah oui tiens, c'est vrai, il n'y a que les drivers pour ces ASICs qui comptent, j'avais oublié !
Perso je trouves quand même amusant cette obsession que vous avez de vouloir vous convaincre et convaincre les gens autour de vous que Linux est "mieux" que Windows. C'est quoi exactement ce besoin ? Vous ne pouvez pas imaginer utiliser Linux sans cela ? Vous avez absolument besoin de cette validation pour vous convaincre que vous avez fait le bon choix ?
C'est quoi l'explication ? Tu n'as pas un QI assez élevé pour comprendre que des choses comme la disponibilité de drivers et support pour le HW spécialisé comptent ?
Moi perso je votes plutôt pour une mauvaise foi crasse.
Seul un idiot, ou une personne d'incroyablement mauvaise foi se braque et refuse de changer d'opinion sans voir le code car il y a plein d'autres elements qui prouvent clairement que la stack reseau est fondamentalement differente.
a) Non il n'a jamais dit ca. Il repetait simplement que les guignols comme toi qui sortaient leur FUD en disant que c'etait une stack BSD pompee mentaient a pleines dents
b) Je ne vois nulle part dans cette annonce un lien entre les perfs de la stack reseau de Windows et leur choix. Devines quoi, il y a plein de raisons qui amenent a un choix particulier, mais visiblement c'est trop complique a comprendre pour toi.
6 mois, c'est effectivement trop long dans la plupart des cas (même si il y en a certains à qui ça convient, comme par exemple Intel). Ceci étant, je n'ai aucune statistique sur le délai moyen entre un premier pull request dans stagging et une inclusion dans le mainline.
mainline on s'en fiche. Ce qui importe c'est le délai pour que le pekin moyen sur son Ubuntu/Suse/… le reçoive. C'est la seule date qui compte pour l'éditeur.
Par ailleurs, je réitère : beaucoup de périphériques n'ont pas à avoir un driver en espace noyau.
Bien évidemment que pour ceux-ci le problème ne se pose pas, mais on ne parle pas d'eux ici.
Je ne dis pas que tout le monde peut faire ça, mais pour la plupart des boites dont l'écriture de drivers n'est pas le coeur de métier (par exemple des compagnies qui veulent commercialiser un nouveau produit dont le driver n'est qu'une interface, l'innovation étant vraiment dans le produit en soi), il n'y a aucun problème avec le modèle actuel.
Là tu te fourvoies. Il y a nombre de choses ou un driver noyau est essentiel pour le bon fonctionnement de la chose, et cela n'inclut pas forcèment du matériel.
Pour les boites plus grosses, pour qui les drivers représentent en soi un atout important, oui, j'espère que ceux-ci sont terminés 3 mois avant la sortie du produit qu'ils accompagnent, et que les développeurs sont passés à l'écriture du driver de la génération suivante.
Et elle sort d'ou cette règle arbitraire ? En quoi faudrait-il attendre 3 mois pour sortir un truc plutôt que le sortir quand il est prêt ?
Et le driver, tu l'as fini 2 jours avant de devoir livrer le produit? Parce que fondamentalement, c'est ça le problème…
2 jours non, je suis sensé le finir 6 mois avant aussi ? A chaque update je dois attendre 6 mois ? Sur des projets dont le cycle est de moins de 6 mois, on va dire que c'est pas top.
Pour ce qui est de le faire tourner sur les distribs existantes, si tu tiens absolument à rester hors de l'arbre principal du kernel, tu fais comme tous les fabricants de matériel : tu certifies le fonctionnement sur certaines distros commerciales (RedHat, Suse, Ubuntu, etc.) et si l'utilisateur veut l'installer sur son Damn Small Linux, ben c'est son problème (ou plutôt le tien, puisque cet utilisateur là, pour qui tout aurait bien fonctionné si tu avais empaqueté ton driver dans le kernel, n'achèteras probablement plus tes produits).
Ça on est bien d'accord, c'est pas le problème.
Après, effectivement, si tu es une boîte qui compte distribuer planétairement un produit dont le driver a été terminé une semaine avant la sortie commerciale, le modèle de Windows convient mieux.
Le problème c'est d'être forcé à être en synchro complète avec ces 232 diffèrents kernels des distribs. Ca crée plusieurs dépendences externes sur lesquelles il y a très peu de contrôle, qui se chevauchent, … C'est juste le bordel, c'est compliqué et couteux.
La question que je me pose, c'est surtout de savoir si je veux acheter ce genre de produits…
Tous les produits que tu achètes ont été terminé 3 mois avant leur sortie ? Ils font quoi les développeurs entre temps ? Du ski ?
dkms est bien, le problème c'est qu'il ne résoud pas tout (pas sur Fedora notamment) et qu'il force l'installation de compilateur et tout ce qui vient avec.
Tu prends le standard PCI pour les systemes ayant des données sensibles, il demande que seul le minimum soit installé sur ces systèmes. Quand on va expliquer à ces utilisateurs qu'ils doivent mettre un compilateur, make, etc… sur leurs machines, ils ont une crise cardiaque.
De nouveau, c'est pas de la théorie là, c'est du vécu.
On revient à la bonne vieille critique du libre : "bouh mais mon concurrent va pouvoir copier sur moi…". Sinon, il est tout à fait possible de travailler de manière confidentielle un bon moment avec les développeurs du noyau, grâce au Linux Foundation NDA Program.
Ce qui ne résoud absolument rien à la problématique d'avoir les drivers sur les distribs déjà sorties. Le problème n'est pas d'écrire le driver, je l'ai fini le driver, le problème c'est le faire tourner sur les distribs existantes, s'assurer qu'il est updaté quand une update du kernel est installée sur ces distribs, etc…
Je ne parle pas non plus de l'appel explicite des développeurs centraux aux mainteneurs à merger le plus rapidement possible les drivers, tant que ces derniers n'affectent pas le reste du noyau.
Ce qui ne résoud absolument rien à la problématique d'avoir les drivers sur les distribs déjà sorties.
Non vraiment, c'est beau de sortir la théorie, je te suggères d'essayer en pratique, tu m'en diras des nouvelles.
a) C'est pas le meme outil selon les distribs
b) Ca force les utilisateurs a avoir un compilateur et les headers du noyau sur chaque machine, sur les machines sensibles qui sont sensées avoir le strict minimum, ca fait moche.
DKMS aide, mais ne résoud pas tout malheureusement.
Note que je n'ai aucun problème envers la certification WHQL en soi, je pense que c'est déjà un bon système qui a limité grandement le nombre de drivers pourrave, mais je veux juste te faire remarquer à quel point il est facile de descendre un système à grand coup de "les entreprises n'aiment pas ça"…
Ben justement non.
WHQL permet à une entreprise de faire les drivers à son rythme, quand elle veut, sans dépendence. Tant que son driver passe les tests, il sera disponible pour tout le monde.
Linux ? Ben à moins de se mettre à parler a Ubuntu, Suse, etc… 6 mois-1 an avant la sortie, ce qui est absolument énorme, c'est impossible, et ils ne pourront pas non plus avoir une sortie synchronisée sur les diffèrentes distribs, leurs concurrents vont voir le module kernel apparaitre des mois avant la sortie finale du produit, avoir le temps de faire du reverse engineering dessus et réagir, etc…
Et le pire, c'est que vous croyez probablement tous que je dis ça pour descendre Linux au profit de Windows sans savoir de quoi je parles, la triste nouvelle est que je suis en train de passer à travers cette horreur en ce moment même pour un module noyau Linux, et que nombre de gens au boulot poussent pour l'abandon de ce module à cause justement de tous ces problèmes.
A un moment va falloir que vous ouvriez les yeux, arrétez de vous braquer à la moindre critique, et vous rendre compte que le système actuel à des limites sérieuses qui empêchent nombre de sociétés de développer des trucs sympa sur Linux car le modèle ne colle pas du tout à ce dont un éditeur a besoin.
La problématique est simple : Comment une société, qui veut faire du développement rapide, sortir des produits avec des itérations successives tous les quelques mois qui puissent être installées par la majorité du marché, peut faire sur Linux si elle a besoin d'un module noyau ?
Vraiment, posez ça sur une feuille de papier, les étapes les unes après les autres, avec le temps que cela demande à chaque étape, la dépendance sur des groupes externes, le risque de fuite sur un nouveau projet, etc… Arrétez de vous exciter à la moindre critique et faites l'exercice sérieusement, alors vous vous rendrez compte à quel point c'est douloureux.
Tu sais, essayer de faire changer d'avis quelqu'un qui se limite à ce qu'il a eu il y a 15 ans et parle des versions d'aujourd'hui sans jamais y avoir touché ben comment dire… on s'en fiche un peu ?
LOL merci pour ce grand moment d'humour.
Les tests WHQL que les drivers doivent passer pour etre signé par MS sont largement plus aboutis que ce qui se trouve sur Linux pour tester les modules kernel, et de très très loin.
Faudrait quand même penser à regarder objectivement ce dont tu parles avant de sortir des trucs pareils.
Un store ne sera effectivement jamais 100% sur, mais c'est tout à fait vrai pour les depots aussi. Ensuite, le système de sandbox dans ces OS limite de manière assez effective l'effet de ces malwares.
Pour Linux et les drivers, le scenario que j'ai donné plus haut je ne l'ai pas sorti de mon chapeau hein, et il bloque à lui seul nombre de développements. Parce que l'insertion dans mainline, ça prend du temps, le produit il doit sortir hier, il doit supporter autant de systèmes que possible, et il faut que ce soit pas cher à maintenir.
Et l'approche Linux avec cassage d'ABI rend ces développements horriblement complexe et couteux. Tu regardes Ubuntu 14.x, toutes les 2-3 semaines l'ABI est cassé dans une update. Un éditeur serait obligé de se taper une update chaque mois, avec la batterie de tests afférents, le packaging, etc… les utilisateurs se verraient avec un kernel teinté car le module n'est pas dans le noyau de base ce qui limite l'adoption, etc…
Un constructeur / editeur doit attendre que Ubuntu fasse son update tous les X mois, et prier pour que tout le monde l'installe rapidement. Oh, et il attendra aussi pour Suse, pour Debian, etc… qui ont tous leur cadence, diffèrentes bien entendu.
Ensuite, contribuer bien en amont, quand tu veux faire une sortie avec un effet de surprise sans que ta concurrence s'en rende compte et te suive pas à pas, super !
Sérieusement, t'as déjà bossé dans une boite qui développe des produits ? Tu te rends compte à quel point ce que tu décris est horrible pour une société ?
[^] # Re: Rien de nouveau
Posté par pasBill pasGates . En réponse au journal Fuzzing : éprouver les entrées de vos développements. Évalué à 8.
T'es gentil :)
Je te rappelle donc que j'ai passé 13 ans à MS. A peu près 8 de ces années ont été passées à construire des fuzzing frameworks et fuzzers. SAGE j'ai revu son design, je l'ai utilisée de manière répetée moi-même, j'en ai parlé avec les auteurs directement, j'en ai parlé avec des dizaines de testeurs et ingénieurs sécurité qui l'utilisent, j'ai vu les bugs qu'il a trouvé, je sais exactement comment il fonctionne et ce qu'il faut pour qu'il fonctionne.
Tu en sais quoi ? Tu n'a aucune idée de la manière de l'utiliser. Et devines quoi, tu as totalement tort.
C'est parce que tu ne lis pas au bon endroit. Lien donné par Benoit Sibaud plus haut : http://research.microsoft.com/en-us/um/people/pg/public_psfiles/SAGE-in-1slide-for-PLDI2013.pdf
1/3 des bugs trouvés dans les composants desktop & multimedia de Windows 7 l'ont été par SAGE. Ca inclue tout ce qui est PNG/JPG/MPG/… et bien plus, et c'était donc avant 2009, SAGE a été optimisé et amélioré depuis pour optimiser ses prioritizations de branches et sa manière de surveiller les processus.
Tu peux lancer SAGE sur Word ou Excel donc, c'est légérement plus qu'un soft de 8 lignes.
Tu as visiblement focalisé sur le fait que SAGE vient de MS Research, et donc est probablement juste un projet de recherche inutilisable dans le monde réel. Tu as faux sur toute la ligne, c'est un projet qui a été construit dans l'idée de l'utiliser en production, par des testeurs normaux, pour trouver des bugs, et il en trouve à la pelle.
J'ai dit plus haut que c'était le système le plus efficace que j'ai jamais vu, je dis ça en connaissance de cause. Je connais Sulley, Peach, AFL, SAGE, les fuzzers que j'ai construit moi-même, Codenomicon, … SAGE les éclate tous en ce qui concerne le fuzzing de fichiers (pour le traffic réseau c'est une autre pair de manche vu le coté transactionnel des protocoles réseaux)
[^] # Re: Rien de nouveau
Posté par pasBill pasGates . En réponse au journal Fuzzing : éprouver les entrées de vos développements. Évalué à 10.
Ca revient à cela :
SAGE va passer un fichier de base à ton soft(en réalité il y a un corpus, de manière à accélérer SAGE en utilisant plusieurs fichiers qui ensemble couvrent de base la majorité des branches). Il va regarder toutes les instructions que ton code éxécute pendant le parsing du fichier. Il va ensuite regarder quelles sont les branches de code qui pourraient être prises et qui ne l'ont pas été. Il va alors créer des fonctions mathématiques pour résoudre le problème suivant :
- a quoi devrait ressembler le fichier pour que la branche X soit éxécutée ?
Il va ensuite utiliser un solveur (Z3 de MS Research) pour résoudre cela, créer le fichier, et le repasser dans le soft.
Il fait ça constamment, pour au final éxécuter toutes les branches de ton code (idéalement, en asymptotique).
La différence avec AFL :
SAGE a des limites : genre si t'as une one-way hash dans ton format, il ne va évidemment pas pouvoir faire une résolution pour trouver une valeur de hash correcte, et si il y a de la compression, cela ralentit SAGE de manière significative. Mais c'est de loin, très loin, le système de fuzzing le plus efficace que j'ai jamais vu( au point ou je préféres ne pas utiliser le mot fuzzing pour SAGE, parce que justement ce n'est pas aléatoire du tout), et j'ai passé la majorité de ma carrière sur ce sujet précis à MS.
# Rien de nouveau
Posté par pasBill pasGates . En réponse au journal Fuzzing : éprouver les entrées de vos développements. Évalué à 8.
Cette approche est une forme primitive de résolution de contraintes appliquée aux tests sécurité. Quelque chose que Microsoft fait depuis presque 10 ans avec SAGE :
http://research.microsoft.com/en-us/um/people/pg/public_psfiles/ndss2008.pdf
[^] # Re: rectification et précisions
Posté par pasBill pasGates . En réponse au journal Logiciels pré-installés : actualité. Évalué à -1.
Techniquement parlant oui ce serait idéal. Le problème est que ta méthode ajoute une étape pour tous les utilisateurs, ce qui garantit des problèmes car le papier avec la clé est perdu ou autre. Et cette étape devrait être ajoutée à tout le monde pour résoudre un problème qui ne touche que 1% des gens en gros… Bref en théorie bien, en pratique pas top.
[^] # Re: Gérer les licences
Posté par pasBill pasGates . En réponse au journal Jargon légal chez Microsoft?. Évalué à -1.
Tu as oublié l'élément le plus important: La productivité des employés.
Quand aux éditeurs, le fait qu'ils se plaignent de piratage ne signifie pas forcément que la gestion de licence soit une partie importante du tco pour les entreprises, ces 2 choses ne sont pas liées.
[^] # Re: Gérer les licences
Posté par pasBill pasGates . En réponse au journal Jargon légal chez Microsoft?. Évalué à 2.
Faudrait quand même voir à ne pas exagérer hein… le TCO c'est bcp, bcp plus que cette gestion de licences.
Les logiciels proprios oui ont cela en plus dans leur colonne, ça ne veut pas dire que cela fait automatiquement pencher la balance.
[^] # Re: Déjà ils proposent un PDF ..;
Posté par pasBill pasGates . En réponse au journal À quoi sert le RGI ?. Évalué à -1.
Ben il y a 2 possibilités :
a) T'as raison, c'est simple à régler et se sont des nuls
b) C'est pas aussi simple que cela
La vraie réponse ? J'en sais rien, mais j'ai tendance à me dire qu'ils ne sont pas tous stupides et que donc la résolution du problème est probablement plus complexe que cela.
[^] # Re: Déjà ils proposent un PDF ..;
Posté par pasBill pasGates . En réponse au journal À quoi sert le RGI ?. Évalué à 5.
Oui ça l'est.
Parce que les employés, ils partent, de nouveaux arrivent, des internes sont mis sur la tâche chiante du jour. Ils ont 4233 règles à suivre, ils ne se souviennent que des plus importantes, ils créent un document 10% de leur temps si ça se trouve, c'est pas le coeur de leur métier.
Cette règle, tu crois qu'elle va être suivie tout le temps ? Evidemment que non.
Faudrait faire quoi alors ? Ecrire une plateforme qui automatise la vérification des PDFs ?
Qui va payer pour ?
Qui va la maintenir ?
Comment tu t'assures que tous les documents sont vérifiés par cette plateforme ?
etc…
Tu veux utiliser un système de pénalités plutôt que construire cette plate-forme ? Comment tu vas justifier ça aux employés ?
Tu as visiblement un gros problème à comprendre qu'il y a un facteur humain là dedans.
Ah cette obsession de toute ramener a MS-Windows dés que j'ouvres la bouche… triste et inutile.
[^] # Re: Déjà ils proposent un PDF ..;
Posté par pasBill pasGates . En réponse au journal À quoi sert le RGI ?. Évalué à 1.
Ben c'est simple.
Tu peux te taper la tête contre les murs, en te disant que tous ces gens sont incroyablement stupides et incompétents, qu'au final c'est super simple et logique, qu'il suffit de faire X ou Y.
Ou tu peux te dire qu'au final, ces gens ne sont pas en moyenne plus bête que toi ou moi, ils sont allé dans les mêmes écoles que toi ou moi, ils ont certainement des compétence sur un sujet donné, et pas sur d'autres, comme toi et moi.
Tu peux te dire que si ce problème est systématique, qu'il est là depuis si longtemps, c'est que la solution n'est probablement pas si simple, sinon quelqu'un l'aurait déjà résolu ce problème.
[^] # Re: Déjà ils proposent un PDF ..;
Posté par pasBill pasGates . En réponse au journal À quoi sert le RGI ?. Évalué à 8.
Ben oui tu es un martien.
Il n'y a qu'un geek/informaticien qui pensera à cette problématique de gérer plusieurs lecteurs PDFs, de savoir qu'il y a des polices intégrées dans des lecteurs, que les utiliser réduit la taille, et même que réduire la taille est important.
[^] # Re: petite question
Posté par pasBill pasGates . En réponse au journal Microsoft sort sa distribution Linux, dédiée au réseau du Cloud Azure. Évalué à -2.
Ah oui tiens, c'est vrai, il n'y a que les drivers pour ces ASICs qui comptent, j'avais oublié !
Perso je trouves quand même amusant cette obsession que vous avez de vouloir vous convaincre et convaincre les gens autour de vous que Linux est "mieux" que Windows. C'est quoi exactement ce besoin ? Vous ne pouvez pas imaginer utiliser Linux sans cela ? Vous avez absolument besoin de cette validation pour vous convaincre que vous avez fait le bon choix ?
[^] # Re: petite question
Posté par pasBill pasGates . En réponse au journal Microsoft sort sa distribution Linux, dédiée au réseau du Cloud Azure. Évalué à -2.
C'est quoi l'explication ? Tu n'as pas un QI assez élevé pour comprendre que des choses comme la disponibilité de drivers et support pour le HW spécialisé comptent ?
Moi perso je votes plutôt pour une mauvaise foi crasse.
[^] # Re: petite question
Posté par pasBill pasGates . En réponse au journal Microsoft sort sa distribution Linux, dédiée au réseau du Cloud Azure. Évalué à -4.
C'est bon tu as temporairement calmé tes frustrations en crachant ta haine sur MS ? Tu es calmé maintenant ?
[^] # Re: petite question
Posté par pasBill pasGates . En réponse au journal Microsoft sort sa distribution Linux, dédiée au réseau du Cloud Azure. Évalué à 0.
Seul un idiot, ou une personne d'incroyablement mauvaise foi se braque et refuse de changer d'opinion sans voir le code car il y a plein d'autres elements qui prouvent clairement que la stack reseau est fondamentalement differente.
[^] # Re: petite question
Posté par pasBill pasGates . En réponse au journal Microsoft sort sa distribution Linux, dédiée au réseau du Cloud Azure. Évalué à 5.
a) Non il n'a jamais dit ca. Il repetait simplement que les guignols comme toi qui sortaient leur FUD en disant que c'etait une stack BSD pompee mentaient a pleines dents
b) Je ne vois nulle part dans cette annonce un lien entre les perfs de la stack reseau de Windows et leur choix. Devines quoi, il y a plein de raisons qui amenent a un choix particulier, mais visiblement c'est trop complique a comprendre pour toi.
[^] # Re: Tu peu même élargir ...
Posté par pasBill pasGates . En réponse au journal C'est lundi : Mon expérience Linux ou l'utopie devient réalité extatique. Évalué à 2.
mainline on s'en fiche. Ce qui importe c'est le délai pour que le pekin moyen sur son Ubuntu/Suse/… le reçoive. C'est la seule date qui compte pour l'éditeur.
Bien évidemment que pour ceux-ci le problème ne se pose pas, mais on ne parle pas d'eux ici.
Là tu te fourvoies. Il y a nombre de choses ou un driver noyau est essentiel pour le bon fonctionnement de la chose, et cela n'inclut pas forcèment du matériel.
Et elle sort d'ou cette règle arbitraire ? En quoi faudrait-il attendre 3 mois pour sortir un truc plutôt que le sortir quand il est prêt ?
[^] # Re: Tu peu même élargir ...
Posté par pasBill pasGates . En réponse au journal C'est lundi : Mon expérience Linux ou l'utopie devient réalité extatique. Évalué à -1.
2 jours non, je suis sensé le finir 6 mois avant aussi ? A chaque update je dois attendre 6 mois ? Sur des projets dont le cycle est de moins de 6 mois, on va dire que c'est pas top.
Ça on est bien d'accord, c'est pas le problème.
Le problème c'est d'être forcé à être en synchro complète avec ces 232 diffèrents kernels des distribs. Ca crée plusieurs dépendences externes sur lesquelles il y a très peu de contrôle, qui se chevauchent, … C'est juste le bordel, c'est compliqué et couteux.
Tous les produits que tu achètes ont été terminé 3 mois avant leur sortie ? Ils font quoi les développeurs entre temps ? Du ski ?
[^] # Re: Tu peu même élargir ...
Posté par pasBill pasGates . En réponse au journal C'est lundi : Mon expérience Linux ou l'utopie devient réalité extatique. Évalué à 2.
dkms est bien, le problème c'est qu'il ne résoud pas tout (pas sur Fedora notamment) et qu'il force l'installation de compilateur et tout ce qui vient avec.
Tu prends le standard PCI pour les systemes ayant des données sensibles, il demande que seul le minimum soit installé sur ces systèmes. Quand on va expliquer à ces utilisateurs qu'ils doivent mettre un compilateur, make, etc… sur leurs machines, ils ont une crise cardiaque.
De nouveau, c'est pas de la théorie là, c'est du vécu.
[^] # Re: Tu peu même élargir ...
Posté par pasBill pasGates . En réponse au journal C'est lundi : Mon expérience Linux ou l'utopie devient réalité extatique. Évalué à -2.
Ah oui, ce workgroup qui n'a pas eu le moindre post sur sa ML depuis Mars 2013 et une main page pas updatée depuis Fevrier 2014 ? ( http://lists.linuxfoundation.org/pipermail/lf_driver_backport/ )
Ce qui ne résoud absolument rien à la problématique d'avoir les drivers sur les distribs déjà sorties. Le problème n'est pas d'écrire le driver, je l'ai fini le driver, le problème c'est le faire tourner sur les distribs existantes, s'assurer qu'il est updaté quand une update du kernel est installée sur ces distribs, etc…
Ce qui ne résoud absolument rien à la problématique d'avoir les drivers sur les distribs déjà sorties.
Non vraiment, c'est beau de sortir la théorie, je te suggères d'essayer en pratique, tu m'en diras des nouvelles.
[^] # Re: Tu peu même élargir ...
Posté par pasBill pasGates . En réponse au journal C'est lundi : Mon expérience Linux ou l'utopie devient réalité extatique. Évalué à 0.
a) C'est pas le meme outil selon les distribs
b) Ca force les utilisateurs a avoir un compilateur et les headers du noyau sur chaque machine, sur les machines sensibles qui sont sensées avoir le strict minimum, ca fait moche.
DKMS aide, mais ne résoud pas tout malheureusement.
[^] # Re: Tu peu même élargir ...
Posté par pasBill pasGates . En réponse au journal C'est lundi : Mon expérience Linux ou l'utopie devient réalité extatique. Évalué à 1.
Ben justement non.
WHQL permet à une entreprise de faire les drivers à son rythme, quand elle veut, sans dépendence. Tant que son driver passe les tests, il sera disponible pour tout le monde.
Linux ? Ben à moins de se mettre à parler a Ubuntu, Suse, etc… 6 mois-1 an avant la sortie, ce qui est absolument énorme, c'est impossible, et ils ne pourront pas non plus avoir une sortie synchronisée sur les diffèrentes distribs, leurs concurrents vont voir le module kernel apparaitre des mois avant la sortie finale du produit, avoir le temps de faire du reverse engineering dessus et réagir, etc…
Et le pire, c'est que vous croyez probablement tous que je dis ça pour descendre Linux au profit de Windows sans savoir de quoi je parles, la triste nouvelle est que je suis en train de passer à travers cette horreur en ce moment même pour un module noyau Linux, et que nombre de gens au boulot poussent pour l'abandon de ce module à cause justement de tous ces problèmes.
A un moment va falloir que vous ouvriez les yeux, arrétez de vous braquer à la moindre critique, et vous rendre compte que le système actuel à des limites sérieuses qui empêchent nombre de sociétés de développer des trucs sympa sur Linux car le modèle ne colle pas du tout à ce dont un éditeur a besoin.
La problématique est simple : Comment une société, qui veut faire du développement rapide, sortir des produits avec des itérations successives tous les quelques mois qui puissent être installées par la majorité du marché, peut faire sur Linux si elle a besoin d'un module noyau ?
Vraiment, posez ça sur une feuille de papier, les étapes les unes après les autres, avec le temps que cela demande à chaque étape, la dépendance sur des groupes externes, le risque de fuite sur un nouveau projet, etc… Arrétez de vous exciter à la moindre critique et faites l'exercice sérieusement, alors vous vous rendrez compte à quel point c'est douloureux.
[^] # Re: Tu peu même élargir ...
Posté par pasBill pasGates . En réponse au journal C'est lundi : Mon expérience Linux ou l'utopie devient réalité extatique. Évalué à -3.
Tu sais, essayer de faire changer d'avis quelqu'un qui se limite à ce qu'il a eu il y a 15 ans et parle des versions d'aujourd'hui sans jamais y avoir touché ben comment dire… on s'en fiche un peu ?
[^] # Re: Tu peu même élargir ...
Posté par pasBill pasGates . En réponse au journal C'est lundi : Mon expérience Linux ou l'utopie devient réalité extatique. Évalué à -10.
LOL merci pour ce grand moment d'humour.
Les tests WHQL que les drivers doivent passer pour etre signé par MS sont largement plus aboutis que ce qui se trouve sur Linux pour tester les modules kernel, et de très très loin.
Faudrait quand même penser à regarder objectivement ce dont tu parles avant de sortir des trucs pareils.
[^] # Re: Tu peu même élargir ...
Posté par pasBill pasGates . En réponse au journal C'est lundi : Mon expérience Linux ou l'utopie devient réalité extatique. Évalué à -10.
Un store ne sera effectivement jamais 100% sur, mais c'est tout à fait vrai pour les depots aussi. Ensuite, le système de sandbox dans ces OS limite de manière assez effective l'effet de ces malwares.
Pour Linux et les drivers, le scenario que j'ai donné plus haut je ne l'ai pas sorti de mon chapeau hein, et il bloque à lui seul nombre de développements. Parce que l'insertion dans mainline, ça prend du temps, le produit il doit sortir hier, il doit supporter autant de systèmes que possible, et il faut que ce soit pas cher à maintenir.
Et l'approche Linux avec cassage d'ABI rend ces développements horriblement complexe et couteux. Tu regardes Ubuntu 14.x, toutes les 2-3 semaines l'ABI est cassé dans une update. Un éditeur serait obligé de se taper une update chaque mois, avec la batterie de tests afférents, le packaging, etc… les utilisateurs se verraient avec un kernel teinté car le module n'est pas dans le noyau de base ce qui limite l'adoption, etc…
[^] # Re: Tu peu même élargir ...
Posté par pasBill pasGates . En réponse au journal C'est lundi : Mon expérience Linux ou l'utopie devient réalité extatique. Évalué à -10.
Ah oui c'est bien marrant ca !
Un constructeur / editeur doit attendre que Ubuntu fasse son update tous les X mois, et prier pour que tout le monde l'installe rapidement. Oh, et il attendra aussi pour Suse, pour Debian, etc… qui ont tous leur cadence, diffèrentes bien entendu.
Ensuite, contribuer bien en amont, quand tu veux faire une sortie avec un effet de surprise sans que ta concurrence s'en rende compte et te suive pas à pas, super !
Sérieusement, t'as déjà bossé dans une boite qui développe des produits ? Tu te rends compte à quel point ce que tu décris est horrible pour une société ?