pasBill pasGates a écrit 16062 commentaires

Régler ce problème est exactement le but visé par le Driver Backport Workgroup de la Linux Foundation.

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/ )

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…

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é ?

Merci pour ce grand moment d'humour !

Population qui pourrait, à terme, cloner les comportements et la situation que l'on retrouve aujourd'hui sous Windows (récupérer des logiciels n'importe où, installer n'importe quoi, se retrouver avec des bloatwares, adwares, des barres de recherche qui s'accumulent…)

C'est faux. Le Windows store evite tous ces problèmes. Rien à voir avec le libre.

Même chose pour les drivers. Le fait qu'ils soient libres, inclus dans le kernel, permet (ou du moins, c'est l'idéal vers lequel on tend) de voir son matériel parfaitement supporté sans que l'utilisateur n'ai besoin de faire quoi que ce soit, de pouvoir maintenir le support dans le temps, de faire en sorte que tout soit parfaitement à jour avec une simple mise à jour du kernel, de pouvoir déplacer un disque système d'une machine à l'autre sans avoir besoin de réinstaller le système…

Ou comment parler de théorie sans jamais avoir fait l'expérience de la réalité…

Allez, petit exemple pratique…

La société X sort le 8 aout 2015 un nouveau matériel, ou un soft, qui a besoin d'un module kernel (bref, un driver).

Elle fait comment pour que son matériel/soft tourne sur les Linux existants chez les utilisateurs qui sont du Ubuntu 12.04, 14.04, Redhat 6, OpenSuse 11, Debian x/y, etc… ? Ah oui tiens, c'est 3252 versions différentes de kernel, avec l'ABI qui casse quasiment à chaque update, qui sortent à des périodes différentes, à des fréquences différentes, avec des règles différentes pour l'inclusion de modules dans les dépots, etc…

Tout ca pour supporter 1% du marché desktop.

Sous Windows ? Ils peuvent dans la plupart des cas faire un driver qui tournera sur toutes les versions depuis Vista. Ca couvre 90% du marché desktop.

Ca, c'est la réalite.

L'inclure dans le kernel mainline ne résoud absolument rien du tout.

C'est chaque fois le même topo quand qq'un dit ca : Il donne un exemple de son expérience et je lui montre telle ou telle fonctionnalité ou commande dont il n'avait jamais entendu parler et qui fait la même chose voire plus.

Tu sais, ton incompétence sous Windows ne signifie qu'une chose : que tu ne sais pas l'utiliser. Ton incompétence ne signifie pas que Windows ne peut pas le faire.

Et soyons un peu honnête, tu n'as visiblement aucune expérience de ce système et en parle négativement sans même l'avoir touché.

Faux c'est de l'opt-in. Il faut cocher la case pour chaque reseau que tu veux partager.

Perdu, les amis ne peuvent pas partager un mot de passe wifi qui a été partagé avec eux.

Et tu penses qu'une société qui se préoccupe des désirs de ses utilisateurs devrait faire quoi ? Forcer ses utilisateurs à changer fréquemment en leur disant que c'est pour leur bien et qu'ils n'ont pas le choix ?

IE a pas mal de failles oui, tout comme Firefox et Chrome. On notera notamment que FF n'a pas de sandbox ce qui le rend bien pire niveau sécurité que IE, mais pourtant je ne t'entends pas parler d'éliminer FF. A mon avis c'est du au fait que tu supputes qu'IE est pire car il est dans les news et pas FF. Devines quoi, il ne faut pas juger un produit sur les manchettes de journaux qui le mentionnent.

La clé du problème est peut-être là, non ? S'il y a trucs pourris qui fonctionnent, pourquoi ne pas les arrêter, et en faire quelque chose de mieux ?

Pourquoi ? Parce qu'il y a des utilisateurs de Windows qui en dépendent et que si un patch casse cela, non seulement cela emmèrdera nombre d'utilisateurs et les empêchera de faire leur boulot, mais certains n'installeront pas le patch de sécurité à cause de cela.

Au fil des années MS élimine doucement ces choses, mais c'est certainement pas quelque chose à faire avec un patch de sécurité.

et j'ai fait l'erreur de demander à ceux qui ont plussé et non pas à l'auteur, donc je reprend la question : de combien de temps juges-tu qu'il faut avant de sortir la faille non corrigée? 6 mois? 1 an? 10 ans? 100 ans?

Cela dépend de plusieurs facteurs :

• La complexité du correctif et du code ou se trouve le bug
• L'impact de la faille (genre tu trouves une faille simple à corriger, mais qui est dans un template C++ largement utilisé, ça amène à faire des correctifs pour 200 produits diffèrents)

Il y a des patchs que MS pourrait sortir en 3 semaines sans problème, et dans de rares cas même en 2-3 jours. Il y a aussi d'autres patchs qui vraiment prennent des mois et des mois à cause de la complexité énorme du problème.

pourquoi la norme tend-elle alors vers 90 jours pour les autres (y compris des boites qui gèrent plus d'1 milliard d'instances) et que juste Microsoft ne devrait pas avoir "si peu" de temps pour corriger?

Je ne connais aucune boite qui a à gèrer un écosystème aussi large, complexe et hétérogène que MS, et surtout, j'en connais très très peu qui font la masse de tests que MS fait. L'effort pour s'assurer que rien ne casse est largement, je dis bien largement, plus gros chez MS que chez la concurrence. MS fait bien attention à ce que même la plupart des softs pourris continuent à fonctionner là oû la plupart des autres se fichent royalement de casser ces softs là.

Android ? C'est un OS ou il y a très peu de variance en réalité : du HW diffèrent mais il n'y a quasiment aucune possibilité d'extension/modification de l'OS dans les configurations supportées. Google ne fait du support que pour les versions très récentes en plus.
Mac OS / iOS : Le HW est totalement sous contrôle de la boite
Firefox : Problèmatique très diffèrente, pas d'intégration dans un OS, pas de nombreux softs pour certains datant de Mathusalem qui réutilisent sont moteur de rendering, etc…
Chrome : Idem que Firefox

A noter que plus on attend, et plus on a de risques qu'un autre, moins sympa que ceux qui acceptent l'embargo, trouve la faille et l'exploite… du coup je suis plus convaincu par l'utilité d'un nombre de 90 pour tout le monde, arbitraire

Moi j'appelle ça la belle théorie qui en pratique n'a aucune valeur. Pourquoi ? Parce qu'en pratique on n'a quasiment (c'est arrivé mais en 13 ans ca doit se compter sur les doigts des 2 mains) jamais vu 2 personnes nous rapporter la même faille durant la même période chez MS. Les chances qu'un gus la trouve dans les 20 ou 30 jours supplèmentaires pour sortir un patch de qualité sont ridicules, surtout en face du risque qu'un mauvais patch poserait à la plupart des gens.

MS a depuis des années des sources multiples niveau télemetrie, et dés le moment ou il y a détection qu'une faille est peut-être exploitée de manière active, MS se met à évaluer le risque de sortir un patch à la vite comparé au risque encouru par l'exploitation.

Faut revenir sur terre un peu, MS est dans ce business de corriger des failles depuis 15 ans, ils ont une expèrience et une qualité construite pendant tout ce temps. A peu près toutes les boites de l'informatique moderne (Google, Amazon, VMWare, …) sont allées prendre des employés de chez MS pour construire leur propre teams sécurité, c'est pas un hasard. Ils savent ce qu'ils font, et plutôt qu'aller dire qu'ils s'en foutent/sont incompétents/… quand ils font qqe chose que vous ne comprenez pas, il serait humble de vous demander si il n'y a pas une bonne raison à leur comportement.

Oui, ça, ça doit arriver, on va dire pour être large, 15 jours (le temps de trouver la faille exacte dans le code, de patcher, et de faire tourner les tests de non régression qui sont prêt à être lancés) après l'étape 1.

Ben oui, bien sur ! En fait, MS pendant plus de 10 ans a mis bcp plus longtemps pour sortir ses patchs parce que…. parce que … ils étaient en vacances ? Ils s'en fichaient ? Ils étaient autour de la machine à café ? Ils sont totalement incompétents et ne savent pas écrire plus d'une ligne de code par jour ?

Il y a évidemment les tests de fonctionalité, il y a aussi les tests de localisation, de compatibilité descendante avec les 236223 diffèrentes configurations HW et softwares existants (eh oui, un browser ca touche la 3D et autres et plein de softs réutilisent le moteur de rendering d'IE sans parler des extensions et autres), les tests de sécurité pour s'assurer qu'on n'a pas ajouté un problème de sécurité en essayant d'en enlever un, un deep dive pour essayer de trouver les failles similaires, etc…

Maintenant essayes de mettre ça dans ton scénario imaginaire de 2 semaines pour corriger et tester. Parce qu'évidemment ces tests ne vont pas commencer à tourner avant que le patch soit prèt, le deep dive des ingénieurs sécurité prend du temps, surtout si ils sont en train de bosser sur d'autres failles en parrallèle. Et souvient toi qu'on parle ici de toutes les versions touchées, ça pourrait être IE8, 9, 10, 11 versions desktop, Metro et mobile.

Ensuite il y toute la problèmatique du nombre de gens disponibles (dans le team IE, et dans les teams sécurité, Windows, …), parce qui si il se trouve que le mois précédent un ou deux gars se sont barré chez une autre boite et que des remplacants n'ont pas encore été trouvé, et qu'en même temps une avalanche de trucs arrive sur ce team, ben c'est la merde, et non, tu ne peux pas garder 3 employés sous la main juste au cas ou dans chaque équipe parce que tu es le riche MS. Ces 3 employés qui ne servent pas à grand chôse sauf en cas de problème ils vont se faire chier, se plaindre qu'ils ne font pas grand chose d'intéressant et se barrer car ils ont de l'ambition, veulent voir leur carrière progresser et il y a 200 boites qui leur offre un job tous les mois.

MS pourrait regarder le patch et éviter certains tests parce que clairement cela ne touche pas ce code ?
Ah ben ça semble logique effectivement… sauf que dans les 3 mois précédents le team a corrigé 6 ou 7 bugs de fonctionalité pour des clients et leur a envoyé un patch. Maintenant ces changements vont se retrouvé deployés chez tout le monde, 1 milliard de personnes donc, potentiellement, et donc toutes ces sections de code qu'ils touchent doivent étre couvertes en profondeur. Bref, faut quasiment tout tester assez souvent.

Mon avis perso est que tu ne te rends pas du tout compte de tout ce que cela implique de tester une gamme, parce qu'on parle de plusieurs versions à corriger le plus souvent hein, de systèmes d'exploitation ou de browsers qui sont utilisés de 20'000 manières diffèrentes avec des milliers de dépendences diffèrentes par 1 milliard de personnes.

Oh tu sais, niveau régressions, je penses qu'on peut prendre n'importe qui en comparaison à MS, et MS sortira gagnant. Personne dans l'industrie ne fait autant attention à ne rien casser qu'eux à ce niveau.

Tu as vu ou qu'Azure indisponible 6 heures était du à ce patch, et qu'ils ont corrigé le problème pour eux seulement en passant ? Moi je vais appeler ça une énorme supputation sans rien de solide…

Tu aurais raison si la description de l'article était vraie pour toute personne qui a installé le patch, le truc est que ce n'est pas le cas, seuls certains ont eu le probléme.

Raison ? C'est du a des configurations particulières, et évidemment il n'est pas possible de toute tester.

Mais évidemment qu'ils vont sortir un patch. C'est exactement ce que mon post dit ! Simplement ils n'ont pas pu arriver à la date voulue.

Quand à ne pas mettre les moyens. Les moyens sont là et ils l'ont été depuis des années, il y a des centaines de patchs qui le montrent. J'en sais quelque chose j'ai passé des années et des années à faire exactement ce boulot là-bas, les gens qui s'occupent de ces patchs je les connais personnellement.

Ou comment ne rien comprendre à la problématique…

Je te donnes un autre scénario, qui lui est arrivé des dizaines de fois quand j'étais chez MS :

1) Microsft est informé des failles
2) Microsoft regarde, trouve que l'info est correcte et se met au boulot
3) Les devs se mettent à créer les patchs pour toutes les versions vulnérables
4) En parrallèle des ingénieurs sécurité se mettent à regarder si il y a des failles similaires
5) Peu avant la sortie prévue, des failles très similaires sont trouvées par 4) ou des régressions sont trouvées par les testeurs qui vérifient les patchs crées en 3)

Résultat, MS se trouve devant le choix de :

1) Sortir un patch qui casse des trucs, et que les gens au final n'installeront pas, mais qui donnera toutes les infos sur les vulnerabilités aux 'bad guys'
2) Sortir un patch qui corrige le problème, mais qui ne corrige pas X autres problèmes extremement similaires et qui seront vite détectés une fois la faille originelle publique
3) Se remettre immédiatement à bosser sur un patch qui résoud les problèmes décrits plus haut, et retarder la sortie

Inutile de dire que 3) est la solution au final qui est la moins mauvaise.

Ca fait plus de 10 ans que MS corrige les failles trouvées dans IE, tu crois que comme ça, au hasard, ils se sont dit "ah ben non, ces 4 là on a pas envie, on va aller faire du kayak plutôt" ?

LOL…

Sagic

51 BOULEVARD DE LATOUR MAUBOURG

http://www.sgdsn.gouv.fr/site_rubrique45.html

Déclaration officielle de Microsoft, qui a le mérite d'être assez précis sur le travail qu'ils ont effectué. Tu veux quoi d'autre?

C'est sympa de voir à quel point tu fais confiance à MS.

Le problème de l'OOxml notamment sur wikipédia, c'est qu'il n'y a pas de différenciation entre la version transitionnal et strict. Difficile de savoir à quoi font allusion les sources.

Tout à fait. Mais n'ayant pas assez d'info, tu assumes que le support est incomplèt. C'est bien, ce serait bien si tu faisais de même avec ODF.

Tu noteras en passant que Transitional est aussi ISO hein.

OCR et le support d'images est probablement l'étape 0 après le support du texte pour ce qui est d'analyser les emails.

A part emmerder l'utilisateur qui reçoit ton email, ça ne servira à rien.