C'est claire que les guerres à la "fonctionnalité qui tue", ça va pas aider à produire du logiciel de qualité et c'est bien plus rentable. Le jour où on oblige une garantie sur les logiciels aussi (parce qu'il y en a sur le matériel), et bien tu verras qu'il y aurait bien moins de technos inutiles (ou vaguement utile) et un poil plus de logiciel de qualité (et moins de réécriture complète de systèmes).
Mais ca n'a pas grand-chose a voir.
Tu prends un browser web basique qui ne supporte que HTTP et HTML 4 avec javascript, rien que ca c'est extremement complexe de garantir que ca fonctionnera correctement. Je te parles meme pas de rajouter des plugins, une UI skinnable, SSL, etc...
Oh, ben ca tu ne le verras jamais que ce soit du soft proprietaire ou open-source, faut etre realiste. Si il fallait faire un truc pareil, le cout de l'OS serait beaucoup, beaucoup, beaucoup plus eleve car le travail requis pour eviter d'avoir chaque societe qui debarque et demande du fric a chaque fois qu'un bug (genre le meme pour 10'000 entreprises) touche quelqu'un serait enorme et a mon avis tout simplement impossible..
Autant il est possible d'assurer une tres tres haute qualite pour du code de petite taille dans les ordinateurs embarques sur avions et autre, autant c'est impossible a faire dans un soft de la complexite d'un browser web, alors imagine un OS.
Si un problème arrive, pouvoir prouver que j'avais les conditions X et qu'on m'a garanti le fonctionnement Y, c'est pour moi le stricte nécessaire. Si Microsoft me fourni ces garanties là, je passes tout de suite sur du Microsoft. Mais un logiciel où je n'ai _aucun_ contrôle et qui commence par un texte disant que je l'utilise "à mes risques et périls", je vois, finalement, pas quel business j'ai à faire avec Microsoft.
Ben ca on le fait plus ou moins hein : une faille reportee on la corrige, mais je pense pas que ca te contenterait, visiblement tu preferes avoir l'option de plonger dans le code, creer un patch toi-meme et le deployer le jour suivant.
Windows ne te contentera pas de ce point de vue, c'est clair et net.
En résumé, la soit disant lettre d'IBM menaçant d'attaquer sur les brevets est une lettre écrite suite à une demande de TurboHercule pour avoir la liste des brevets qu'ils enfreignaient, ce n'est donc absolument pas une lettre de menace.
Quelle belle connerie tu nous dis la, voila la lettre de TurboHercules, tiree de ton lien sur Groklaw :
We also were surprised at the suggestion that our TurboHercules product -- which merely relies on Hercules open source emulation software to run z/OS on Intel-based servers -- might infringe certain IBM intellectual property. Hercules has been widely used in the development community, as well as within IBM itself, over the past ten years. Prior to receiving your letter, we were not aware of any claim that Hercules might infringe IBM's intellectual property. If you believe that the Hercules open source project infringes any IBM intellectual property, please identify it so that we can investigate that claim.
Clairement, ce n'est pas TH qui a demande soudainement la liste, il y a eu un clair message d'IBM causant cela.
Enfin dernier point, toute cette affaire ressemble étrangement à celle de SCO ou une compagnie attaque au niveau légal sans fondement ou sans possibilité de réussite légale. Avec le petit détails "amusant" qui permet de relativiser encore plus le journal précèdent, Microsoft, comme pour SCO, participe au financement de ces procès...
C'est rigolo ce que tu dis, et c'est drole que tu ne mentionnes pas le fait qu'une autre societe avait porte plainte contre IBM pour les memes raisons, et qu'est ce qu'IBM a fait ? Ils les ont rachete pour eteindre l'incendie.
Le reste de ton post n'es vraiment rien d'autre que supputations sans rien de valable pour les supporter (le proces n'a aucune chance d'aboutir, ils ont tort, etc...)
Je te crois sur parole, je prétends pas être un expert en développement de pilotes, mais c'est du vécu. Il est beaucoup plus simple de développer un pilote Linux que Windows et ce malgré toute la doc et l'outillage Microsoft.
Creer un pilote basique oui, creer un pilote avec tout le bousin qu'il faut, en gardant a l'esprit la maintenance, je trouves pas.
Bon nombre de BSOD sont dû à des pilotes foireux, foireux à cause d'une API monstrueusement complexe. C'est même une des raisons pour laquelle, personne n'enseigne en école le développement de pilotes sous Windows.
Ben il y a des ecoles qui enseignent le developpement de pilotes Windows, en France je sais pas, mais ici c'est clair et net, il y en a meme plusieurs qui plongent leurs etudiants dans le code du kernel Windows.
Certes, Microsoft est capable d'innover et de fournir des produits de qualité (.Net, Silverlight, Visual Studio, etc...), mais la sacro-sainte compatibilité est un boulet. Raymond Chen l'avait très bien expliqué sur blog.
C'est bien d'avoir le choix, mais si ça résulte par une inflation des entrailles, à plus ou moins long terme, on tombe sur mur (ce qui est arrivé à DOS/windows 9x).
Oui et non, c'est une question d'architecture. Typiquement avec la virtualisation aujourd'hui, ca resoud pas mal de ces problemes.
Alors la compatibilite c'est un boulet, mais au final c'est MS qui gere le boulet, les developpeurs n'ont pas a s'en charger. Et visiblement ca nous a pas empeche d'innover dans l'OS donc c'est faisable. Certes ca serait plus simple pour nous de casser les APIs, mais au final pour l'ecosysteme, ca serait pire.
Ce qu'ils veulent, c'est fermer les sources et faire chier la concurrence, juste des broutilles non négociables. Si tu dois te soumettre aux diktats des constructeurs, c'est ingérable, c'est ce qui a mené à la création d'OpenGL, Direct3D, OpenCL, etc ...
Honnetement, je suis pas la pour dire qui a tort et qui a raison. Je vois la situation :
- Les constructeurs n'aiment pas la solution proposee, peu importe leurs raisons.
- Linux a besoin de drivers de qualite si il veut avoir une chance sur le desktop
Partant de la, le choix est entre :
- Avoir une chance sur le desktop
- Garder l'ensemble libre
Question de choix, que voulez vous ? Mais faut assumer le choix fait : perdre un peu de liberte ou perdre le desktop et la masse critique
Je sais, la conception originale de NT à base de micro-noyaux était particulièrement bien foutue, et extrêmement portable. Ce qui a plombé NT c'est la compatibilité, au revoir la portabilité, au revoir une API pilote simple à appréhender etc ...
La portabilite est toujours la, elle n'a pas change. Le nombre de plateformes supportees il depend pas du code, il depend de la viabilite de la plateforme d'un point de vue commercial : est-ce que ca vaut la peine d'investir dans une passe de test specifique pour cette plateforme, former le support, pousser les constructeurs a creer les drivers pour, etc...
Porter le code, c'est de loin la partie la plus simple.
L'API de pilotes quand a elle n'a pas enormement change (excepte pour les drivers graphiques) depuis Windows 2000 reellement.
Allez, le jour ou tu comprendras ce qu'est un driver et quelles sont les differences/similarites tu reviendras causer de drivers, d'ici la je te suggeres de retourner a tes cours d'introduction a l'informatique.
oui c'est vrai, tu as raison, mais le coeur des utilisateur linux, il s'en carre de pas avoir des vendeurs de cartes graphiques qui font des pilotes. Il veut juste pouvoir être libre sur sa machine.
Ben ca depend de ce que la communaute Linux veut au final hein.
Ils veulent du libre plus qu'autre chose et se moquent d'avoir une large base installee(et les avantages/desavantages qui en decoulent) : continuez comme cela, meilleure maniere d'atteindre l'objectif, tout restera libre
Ils veulent grossir la base installee de Linux sur le desktop pour attirer plus d'editeurs, plus de constructeurs, etc... : Va falloir faire des concessions.
Au final, c'est a la communaute Linux de choisir ce qu'elle veut, et agir en fonction.
C'est absolument une question economique, on est d'accord la dessus.
La proposition economique du cote Linux est extremement mauvaise : quasiment rien a gagner, et devoir donner ses sources ou devoir maintenir un driver dans un environnement qui change tout le temps et qui est chiant pour programmer.
Du cote Windows, c'est stable, peu de boulot pour la maintenance, un marche gigantesque, un environnement pour developper qui est a peu pres sans egal.
Alors evidemment quand t'es un constructeur qui fait du fric sous Windows, quelque gus tapant a la porte qui veulent te dire comment faire, et qui ne t'amenent rien en retour, ca attire pas.
Si Linux arrive a 50%, evidemment l'equation economique change, mais notre cher Linux il va avoir du mal a passer la barre des 2-3% sans support graphique digne de ce nom. Bref faut pas inverser l'ordre des choses, pour arriver a 50% il va devoir seduire les constructeurs, et pas l'inverse.
L'écriture de pilotes windows est la première cause de suicide et d'auto-mutilation parmi les développeurs de pilotes matériels. Pour sortir ce genre d'âneries, tu t'es déjà frotté à l'écriture de pilote ?
Oh, on peut regarder ou je bosse et sur quoi je bossais il y a quelques annees de cela, ca devrait te donner une idee de mes competences sur le sujet. A ce niveau la je doutes que tu aies quoi que ce soit a m'apprendre
Certes, les chans irc, la kernel M-L sont pas aussi accueillants que les forum MSDN mais on obtient les informations nécessaires assez rapidement. Certes, on peut appeller le support Microsoft, mais la plupart du temps, on tombe sur un technico-commercial complétement largué qui va mettre des plombes à obtenir une information de quatrième main.
Meric de confirmer que TU ne sais pas de quoi tu parles.
Allez, pour commencer tu vas sur les forums publiques poser tes questions, ensuite tu vas sur les forums chez Microsoft, ou il y a des employes qui trainent, comme sur les ML du kernel, ensuite tu cherches sur le net et tu decouvres qu'il y a plein de societes specialisees dans le developpement de drivers Windows (osr.com pour ne citer que les plus celebres), ensuite tu appelles le support MS et tu decouvres que tu peux vite arriver a qq'un de technique si besoin est, ensuite tu decouvres que Nvidia, ATI et autres grosses societes ont des employes qui sont sur place sur notre campus, avec leur bureau ici meme, ils n'ont qu'a marcher jusqu'au bureau du gars si ils ont une question.
L'idée que se fait Microsoft de faire plaisir aux constructeurs est très spếciale, parce que le framework ampoulé, horriblement complexe, la gestion d'énergie imbitable (qui doit générer une bonne partie des bogues dans windows) est très loin de faire plaisir aux développeurs. À côté de ça, l'IOKit et sa documentation lacunaire, son embedded C++ ou l'API Linux quasiment pas documenté, c'est une vraie partie de plaisir
Le fait que tu ne saches pas gerer cela ne signifie pas que c'est un probleme. Suffit de voir la flopee de drivers qui le font, et le fait que le sleep/hibernate sous Windows est enormement plus fiable que sous Linux
On leur demande pas pas non plus les masques et je ne crois pas que tu puisses apprendre grand chose d'utile à partir d'un simple pilote ou même de specs vu la vitesse de développement en ce domaine.
Ecoutes, tu peux avoir ton avis, libre a toi. Le truc, c'est que c'est l'avis des constructeurs qui importe parce que sans eux pas de driver de qualite. Alors tu peux leur repeter a l'envie que leur avis est mauvais et que tu sais mieux qu'eux ce qu'il leur faut, mais ca ne va pas aider et les drivers pour Linux resteront aussi pourri qu'ils le sont aujourd'hui.
Je te suggeres a la place un peu d'humilite, arreter de les prendre pour des cons qui ne comprennent rien, accepter que le modele que vous leur proposez ne leur convient pas, et essayer d'ameliorer le systeme pour qu'il reponde mieux a leurs besoins.
Techniquement, c'est une connerie les interfaces stables à long terme, windows en est bien la preuve avec win32, MFC, GDI, COM, ODBC une belle brochette de techno dépassées depuis plus d'une décennie et toujours au coeur du développement d'application windows.
Il y a plein de nouvelles interfaces dispo : D2D, WPF, etc... qui permettent de supporter les avancees, l'avantage c'est que tu as le choix.
Si les vendeurs faisaient un peu plus d'efforts à collaborer avec upstream, ils auraient pu aider à stabiliser l'architecture de Xorg, et en libérant les pilotes, laisser la communauté se charger des tâches subalternes. Les plus gros committers dans Xorg. ne sont pas employés par des constructeurs de cartes graphiques
De nouveau, la seule chose que tu fais c'est repeter a tut-tete ta vision des choses : C'est plus facile de liberer les sources ,etc...
Faut te faire a l'idee que les constructeurs, ils sont pas d'accord avec toi. Tu as le choix entre trouver un terrain d'entente avec eux en prenant en compte leurs desirs, ou leur repeter 500x fois qu'ils ont tort et qu'ils ne comprennent rien.
Si tu veux mon avis, la 1ere methode a beaucoup plus de chance d'aboutir.
Unix était un logiciel à sources ouvertes bien avant que ton patron ne troque ses culottes courtes pour des pantalons d'homme.
Tout a fait, et mon (ex-)patron a bouffe Unix par les couilles avec un OS ayant des interfaces standardisees, qui permettait de faire tourner l'OS sur une enorme variete de materiel tout en assurant que les softs tourneraient sans probleme sur cette variete de systemes.
Oh, et en passant, NT a ete cree par Dave Cutler, pas par Bill Gates, et ce dernier, il a comment dire une certaine experience du developpement d'OS, genre un truc insignifiant nomme VMS
Avec Xorg, ils ont mieux que ça, ils peuvent directement participer et influer sur le développement de Xorg.
C'est beau la theorie hein ? Le truc c'est qu'en pratique visiblement ce que vous leur proposez ne leur plait pas.
Vous avez inventé un système pourri qui oblige les vendeurs à faire ce que vous voulez ...
Haha, certes, l'architecture de pilotes de windows est stable dans le temps, mais personne n'ose imaginer la terrible expérience infantile traumatisante qui a pu mener ses concepteurs à ça.
WDM, WDF efficaces ? faciliter la vie des développeurs ? j'en pleure de rire :o)
De nouveau, je regarde la realite, pas la theorie : Les constructeurs sont tres contents de faire leur drivers sous Windows, pas sous Linux. Ils n'ont pas besoin de filer leur specs ou sources, leurs drivers n'ont pas besoin d'etre modifies toutes les 3 semaines, les APIs sont tous documentes, MS livre des softs de tests pour verifier les drivers, il y a un debugger kernel extremement efficace, etc... et en bonus ils ont 95% du marche.
En face, ils doivent filer leur specs ou code source, ou ils doivent se taper la maintenance de drivers qui petent tous les mois pour supporter 1% de la population, le support du developpement kernel est comment dire, prehistorique, ...
Ca c'est une description de la realite. N'importe quel manager ou ingenieur qui n'est pas un fanatique de Linux verra vite quelle plateforme est la plus attrayante.
Techniquement, Apple fait ce que je propose de faire avec Xorg ===> une architecture unifié et la maintenance des pilotes par un seul acteur et non pas le foutoir où chacun fait ce qu'il veut.
Du tout, ce que fait Apple est ce que je dis : faire plaisir aux constructeurs.
Ils s'occupent du driver, tout en gardant secret ce qui doit l'etre, chose que X.org ne fait pas.
Sans eux, on ira pas très loin, on a beau les inviter à construire un chateau dans notre bac à sable, mais l'un veut construire un quart de pagode en bois dans son coin et écrase tout les 3 mois le flan droit, l'autre une fusée ariane qui finit invariablement par exploser en projetant du sable sur les enfants.
C'est un point de vue, moi je vois que :
a) Les constructeurs veulent avoir un support linux, ils paient des devs pour ca
b) Les constructeurs ne veulent pas partager leurs secrets
c) Moins il y a de travail necessaire pour le dev de drivers, mieux c'est
b) et c) ca signifie avoir une interface de drivers stable, qui ne demande pas aux constructeurs de devoir ouvrire leur specs et code source
Rien a voir avec construire des pagodes a la place de chateaux, c'est un concept informatique vieux de plusieurs decennies
La seule façon d'imposer une "pax Xorg" serait d'avoir des pilotes et/ou spécifications libres. Vous imaginez le temps que cela aurait pris pour imposer un changement majeur tel que KMS si chaque pilote dupliquait une partie de Xorg et/ou était fermé ? D'ailleurs, reste guère que nVidia qui refuse de passer à KMS (pour faire chier le monde quoi)
Non, la seule facon d'avoir un systeme efficace c'est d'ecouter ce que veulent les constructeurs et let aider en creant une plateforme qui leur facilite la vie.
Si on avait cree un systeme pourri ou ils doivent refaire leurs drivers tous les 4 matins, ou sinon ils sont obliges de devoiler leur code source, on en serait au meme point que X.org
Cf. le Mac qui a une part de marche minuscule, mais qui a un systeme efficace et qui fonctionne. Le probleme c'est pas forcement les parts de marche uniquement.
Vous pouvez continuer a vous enfoncer la tete dans le sable en rejetant la faute sur les constructeurs, mais ca ne fera certainement pas avancer le schmilblick.
Non il ne s'enerve pas tout seul, d'autres sont d'accord avec lui dont moi (ce qui va logiquement lui couter plusieurs -1 , desole mon cher imr !), simplement lui il exprime son enervement,
Non je n'ai pas les compétences de faire un audit. Mais, par exemple, aujourd'hui je debug mon serveur DNS.
D'avoir le code source me permet de réparer un dysfonctionnement quand je le détecte et ensuite j'aurais des risques en moins sur mon système
Ca c'est la theorie. Ca marche quelque fois. Mais tu sais si ton correctif ne va pas casser quelque chose d'autre ? Tu as une batterie de tests pour le valider ? Tu sais si ton correctif ne va pas creer une faille ailleurs ? Non, verifier ces choses la demande d'avoir une connaissance approfondie du soft et de pouvoir le tester de maniere approfondie.
Parce que j'ai rencontré ces problèmes et que j'ai eu les informations à disposition, j'ai pu les résoudre, envoyer ça en upstream et aujourd'hui certains logiciels sont un poil plus sécurisé.
Quand le firewall checkpoint plantait, à part envoyer un 32ème mail d'insulte que ça fait trois mois qu'on attend, je pouvais rien faire.
Ca c'est un autre probleme, le fait que certains editeurs ne donnent pas de reponse est un probleme, mais un probleme different.
Donc si j'utilises des systèmes Microsoft (c'est pas du troll) je n'ai aucune garantie de la part de Microsoft et je mets en jeu ma place de travail autant qu'avec des logiciels open-source, sauf que dans un cas j'ai accès au code.
La première menace informatique c'est l'obscurité. Si je ne peux pas voir tous les rouages du système que j'utilise, comment je peux les montrer aux utilisateurs et les éduquer à utiliser correctement le logiciel ?
Tu m'excuseras, mais ca c'est une raison a la con.
Tu n'as certainement jamais audite le code de Linux ou de Firefox du point de vue securite, tu n'en as pas les competences (pas une critique, tres peu de gens l'ont), tu n'as pas la connaissance du code pour comprendre ce qu'il fait et ce qu'il est sense faire, ...
Tout ce que tu fais c'est te raccrocher a l'espoir que quelqu'un d'autre le fera, et le truc le plus fantastique est que cet "espoir" est absolument inutile. Quasiment aucun bug de securite n'est trouve par audit de code, quasiment tous sont trouves par fuzzing, y compris dans les logiciels open-source, car c'est une methode beaucoup plus efficace que revoir des millions de lignes de code. Et le fuzzing, ca ne depend pas de l'acces au code source.
a) Cette banque est geree par le gouvernement norvegien, pas par une societe.
b) Les produits deposes (semences) ne peuvent etre repris que par le depositaire et restent sa propriete
Bref, rien d'anormal ou de scandaleux au contraire, c'est quelque chose d'extremement utile.
Oh si, mais la difference est que Windows 7, on ne le sous-traite pas a des gerants externes, c'est un peu les joyaux de la couronne, et les employes de MS sont mis au courant assez clairement que si le code est GPL c'est pas touche, chose qui pourrait ne pas etre aussi clair chez les sous-traitants.
Du point de vue de l'utilisateur de l'application (hopital, etc...) je comprends selon sa situation, mais du point de vue du developpeur de l'application on voit les choses differemment, on est sense proteger les donnees de l'application d'acces non-autorises.
Ca marche que l'application soit existante ou nouvelle en fait, ca se base simplement sur le design de l'application, donc une fois que le design est decide, le threat modeling peut avoir lieu. Ca permet de definir la phase de test alors que le code a tout juste commence a etre ecrit.
La problématique des données privilégiées est surtout d'en avoir ou pas. La majorité des applications qui te demandent ces informations n'en ont pas besoin, c'est juste un besoin commercial, pas fonctionnel.
Dans le monde du web oui je peux le comprendre, dans le monde de l'entreprise par exemple c'est pas le cas. Les informations ici elles sont d'un tout autre ordre : code source, informations financieres, details techniques de produits a venir, etc...
Ça, c'est débile : tu ne peux pas définir une liste des attaques possibles pour la simple et bonne raison qu'il en apparaît tous les jours.
...
Même tonneau pour celle-là : tu ne peux pas prévoir l'ensemble des risques donc ta liste va être obsolète aussitôt éditée.
Tout a fait, mais donc tu proposes quoi ? De ne rien faire parce qu'il est impossible de tout prevoir ?
Youpi, maintenant que tu as défini ce que tu appelles un "risque", tu es content d'avoir un outil pour classer les combinaisons entre attaque, cible et coût. L'ennui c'est que cette classification va te faire mettre en place des mesures préventives dédiées aux attaques les "plus risquées" tout en laissant de côté celles que tu vas considérer comme négligeables.
C'est possible, mais pas forcement, ca te permet aussi d'approcher la liste en odre de priorite tout simplement, savoir par quoi commencer.
Parce que soyons realiste, si tu ne l'as pas, tu risques a l'inverse de commencer par le risque le plus negligeable sans regler le risque le plus gros.
Toutes. La sécurité se conçoit comme un élément initial du développement du projet, pas comme une surcouche.
Oui ca c'est la belle theorie des gens qui n'ont jamais eu a s'occuper de la securite d'un gros projet.
La realite c'est que si tu as des composants qui sont utilises uniquement par l'interface d'administration par exemple, et que celle-ci est uniquement accessible a root, ben les auditer d'un point de vue securite ne sert pas a grand-chose, le gars il est deja root, une faille la dedans ne lui servira a rien, il n'en tirera rien d'utile, donc ca tombe en bas de la liste des priorites.
Ib idem, et pas que pour des raisons de sécurité, pour des raisons de stabilité aussi.
De nouveau, tu vas faire quoi avec ca ? Tu vas fuzzer la fonction memcpy(...) et lui passer des pointeurs illegaux dans ton espace d'addresse ? Pas tres utile vu que memcpy considere ses entrees comme sur par definition.
Tous. Sinon on en arrive à un désastre du même acabit que celui que Microsoft a su mettre en place lorsqu'ils ont autorisé leurs programmeurs à ne pas vérifier les valeur de retour des fonctions appelées.
On dit pas "ab hominem" mais "ad hominem", et sur le sujet, tu sais parfaitement que tu n'as absolument aucune lecon a donner. Perso je me suis pas encore fait ejecter de ce site pour avoir eu un comportement inacceptable(qui me visait d'ailleurs, original non ?).
Quand a tes dire, je te suggeres de te relire :
On pourra noter que les defenseurs de Bill Gates crie au scandale sur une attaque personnelle mais naturellement ne donne strictement aucun lien prouvant que tout ce qui a ete dit est faux. Curieux non?
Je te laisse une semaine pour analyser ta propre phrase, parce que visiblement c'est difficile pour toi, une fois que tu auras termine, reviens avec la reponse, sinon pense a arreter de pourrir ce site.
Donc ce n'est pas seulement Flash, Scheme, C#, Lua, Mozart/Oz, OCaml, et tous les autres langages qui sont interdits, mais aussi tous les toolkits/frameworks, même codés dans un des langages autorisés, qui ne viennent pas d'Apple.
Tu confonds, "private APIs" ca veut dire les APIs du systeme qui sont non-documentes, bref les APIs qu'ils utilisent en interne et qu'ils se reservent le droit de changer a un moment ou un autre.
C'est quelque chose que je peux tout a fait comprendre. Quand aux autres limitations, on va dire qu'Adobe est dans la ligne de mire d'Apple...
[^] # Re: Et ne pas avoir à protéger ces informations ?
Posté par pasBill pasGates . En réponse à la dépêche Threat modeling - Savez vous quelles sont les menaces qui guettent votre application ?. Évalué à 1.
Mais ca n'a pas grand-chose a voir.
Tu prends un browser web basique qui ne supporte que HTTP et HTML 4 avec javascript, rien que ca c'est extremement complexe de garantir que ca fonctionnera correctement. Je te parles meme pas de rajouter des plugins, une UI skinnable, SSL, etc...
[^] # Re: Et ne pas avoir à protéger ces informations ?
Posté par pasBill pasGates . En réponse à la dépêche Threat modeling - Savez vous quelles sont les menaces qui guettent votre application ?. Évalué à 2.
Autant il est possible d'assurer une tres tres haute qualite pour du code de petite taille dans les ordinateurs embarques sur avions et autre, autant c'est impossible a faire dans un soft de la complexite d'un browser web, alors imagine un OS.
[^] # Re: hmmm
Posté par pasBill pasGates . En réponse au journal Un serveur Windows parmi 5000 : début. Évalué à 3.
VMBus est le nom du bus interne d'Hyper-V, ca n'a rien a voir avec VMWare.
[^] # Re: Et ne pas avoir à protéger ces informations ?
Posté par pasBill pasGates . En réponse à la dépêche Threat modeling - Savez vous quelles sont les menaces qui guettent votre application ?. Évalué à 1.
Ben ca on le fait plus ou moins hein : une faille reportee on la corrige, mais je pense pas que ca te contenterait, visiblement tu preferes avoir l'option de plonger dans le code, creer un patch toi-meme et le deployer le jour suivant.
Windows ne te contentera pas de ce point de vue, c'est clair et net.
# Quel bel amas de merde
Posté par pasBill pasGates . En réponse au journal analyse de Groklaw sur l'affaire TurbiHercule versus IBM. Évalué à -8.
Quelle belle connerie tu nous dis la, voila la lettre de TurboHercules, tiree de ton lien sur Groklaw :
We also were surprised at the suggestion that our TurboHercules product -- which merely relies on Hercules open source emulation software to run z/OS on Intel-based servers -- might infringe certain IBM intellectual property. Hercules has been widely used in the development community, as well as within IBM itself, over the past ten years. Prior to receiving your letter, we were not aware of any claim that Hercules might infringe IBM's intellectual property. If you believe that the Hercules open source project infringes any IBM intellectual property, please identify it so that we can investigate that claim.
Clairement, ce n'est pas TH qui a demande soudainement la liste, il y a eu un clair message d'IBM causant cela.
Enfin dernier point, toute cette affaire ressemble étrangement à celle de SCO ou une compagnie attaque au niveau légal sans fondement ou sans possibilité de réussite légale. Avec le petit détails "amusant" qui permet de relativiser encore plus le journal précèdent, Microsoft, comme pour SCO, participe au financement de ces procès...
C'est rigolo ce que tu dis, et c'est drole que tu ne mentionnes pas le fait qu'une autre societe avait porte plainte contre IBM pour les memes raisons, et qu'est ce qu'IBM a fait ? Ils les ont rachete pour eteindre l'incendie.
Le reste de ton post n'es vraiment rien d'autre que supputations sans rien de valable pour les supporter (le proces n'a aucune chance d'aboutir, ils ont tort, etc...)
Qui c'est qui parlait de FUD ?
[^] # Re: Argh
Posté par pasBill pasGates . En réponse au journal Xorg 1.8: épatant ?. Évalué à 1.
Creer un pilote basique oui, creer un pilote avec tout le bousin qu'il faut, en gardant a l'esprit la maintenance, je trouves pas.
Bon nombre de BSOD sont dû à des pilotes foireux, foireux à cause d'une API monstrueusement complexe. C'est même une des raisons pour laquelle, personne n'enseigne en école le développement de pilotes sous Windows.
Ben il y a des ecoles qui enseignent le developpement de pilotes Windows, en France je sais pas, mais ici c'est clair et net, il y en a meme plusieurs qui plongent leurs etudiants dans le code du kernel Windows.
Certes, Microsoft est capable d'innover et de fournir des produits de qualité (.Net, Silverlight, Visual Studio, etc...), mais la sacro-sainte compatibilité est un boulet. Raymond Chen l'avait très bien expliqué sur blog.
C'est bien d'avoir le choix, mais si ça résulte par une inflation des entrailles, à plus ou moins long terme, on tombe sur mur (ce qui est arrivé à DOS/windows 9x).
Oui et non, c'est une question d'architecture. Typiquement avec la virtualisation aujourd'hui, ca resoud pas mal de ces problemes.
Alors la compatibilite c'est un boulet, mais au final c'est MS qui gere le boulet, les developpeurs n'ont pas a s'en charger. Et visiblement ca nous a pas empeche d'innover dans l'OS donc c'est faisable. Certes ca serait plus simple pour nous de casser les APIs, mais au final pour l'ecosysteme, ca serait pire.
Ce qu'ils veulent, c'est fermer les sources et faire chier la concurrence, juste des broutilles non négociables. Si tu dois te soumettre aux diktats des constructeurs, c'est ingérable, c'est ce qui a mené à la création d'OpenGL, Direct3D, OpenCL, etc ...
Honnetement, je suis pas la pour dire qui a tort et qui a raison. Je vois la situation :
- Les constructeurs n'aiment pas la solution proposee, peu importe leurs raisons.
- Linux a besoin de drivers de qualite si il veut avoir une chance sur le desktop
Partant de la, le choix est entre :
- Avoir une chance sur le desktop
- Garder l'ensemble libre
Question de choix, que voulez vous ? Mais faut assumer le choix fait : perdre un peu de liberte ou perdre le desktop et la masse critique
Je sais, la conception originale de NT à base de micro-noyaux était particulièrement bien foutue, et extrêmement portable. Ce qui a plombé NT c'est la compatibilité, au revoir la portabilité, au revoir une API pilote simple à appréhender etc ...
La portabilite est toujours la, elle n'a pas change. Le nombre de plateformes supportees il depend pas du code, il depend de la viabilite de la plateforme d'un point de vue commercial : est-ce que ca vaut la peine d'investir dans une passe de test specifique pour cette plateforme, former le support, pousser les constructeurs a creer les drivers pour, etc...
Porter le code, c'est de loin la partie la plus simple.
L'API de pilotes quand a elle n'a pas enormement change (excepte pour les drivers graphiques) depuis Windows 2000 reellement.
[^] # Re: Argh
Posté par pasBill pasGates . En réponse au journal Xorg 1.8: épatant ?. Évalué à 2.
[^] # Re: Argh
Posté par pasBill pasGates . En réponse au journal Xorg 1.8: épatant ?. Évalué à 1.
Ben ca depend de ce que la communaute Linux veut au final hein.
Ils veulent du libre plus qu'autre chose et se moquent d'avoir une large base installee(et les avantages/desavantages qui en decoulent) : continuez comme cela, meilleure maniere d'atteindre l'objectif, tout restera libre
Ils veulent grossir la base installee de Linux sur le desktop pour attirer plus d'editeurs, plus de constructeurs, etc... : Va falloir faire des concessions.
Au final, c'est a la communaute Linux de choisir ce qu'elle veut, et agir en fonction.
[^] # Re: Argh
Posté par pasBill pasGates . En réponse au journal Xorg 1.8: épatant ?. Évalué à 1.
[^] # Re: Argh
Posté par pasBill pasGates . En réponse au journal Xorg 1.8: épatant ?. Évalué à 2.
La proposition economique du cote Linux est extremement mauvaise : quasiment rien a gagner, et devoir donner ses sources ou devoir maintenir un driver dans un environnement qui change tout le temps et qui est chiant pour programmer.
Du cote Windows, c'est stable, peu de boulot pour la maintenance, un marche gigantesque, un environnement pour developper qui est a peu pres sans egal.
Alors evidemment quand t'es un constructeur qui fait du fric sous Windows, quelque gus tapant a la porte qui veulent te dire comment faire, et qui ne t'amenent rien en retour, ca attire pas.
Si Linux arrive a 50%, evidemment l'equation economique change, mais notre cher Linux il va avoir du mal a passer la barre des 2-3% sans support graphique digne de ce nom. Bref faut pas inverser l'ordre des choses, pour arriver a 50% il va devoir seduire les constructeurs, et pas l'inverse.
[^] # Re: Argh
Posté par pasBill pasGates . En réponse au journal Xorg 1.8: épatant ?. Évalué à 5.
Oh, on peut regarder ou je bosse et sur quoi je bossais il y a quelques annees de cela, ca devrait te donner une idee de mes competences sur le sujet. A ce niveau la je doutes que tu aies quoi que ce soit a m'apprendre
Certes, les chans irc, la kernel M-L sont pas aussi accueillants que les forum MSDN mais on obtient les informations nécessaires assez rapidement. Certes, on peut appeller le support Microsoft, mais la plupart du temps, on tombe sur un technico-commercial complétement largué qui va mettre des plombes à obtenir une information de quatrième main.
Meric de confirmer que TU ne sais pas de quoi tu parles.
Allez, pour commencer tu vas sur les forums publiques poser tes questions, ensuite tu vas sur les forums chez Microsoft, ou il y a des employes qui trainent, comme sur les ML du kernel, ensuite tu cherches sur le net et tu decouvres qu'il y a plein de societes specialisees dans le developpement de drivers Windows (osr.com pour ne citer que les plus celebres), ensuite tu appelles le support MS et tu decouvres que tu peux vite arriver a qq'un de technique si besoin est, ensuite tu decouvres que Nvidia, ATI et autres grosses societes ont des employes qui sont sur place sur notre campus, avec leur bureau ici meme, ils n'ont qu'a marcher jusqu'au bureau du gars si ils ont une question.
L'idée que se fait Microsoft de faire plaisir aux constructeurs est très spếciale, parce que le framework ampoulé, horriblement complexe, la gestion d'énergie imbitable (qui doit générer une bonne partie des bogues dans windows) est très loin de faire plaisir aux développeurs. À côté de ça, l'IOKit et sa documentation lacunaire, son embedded C++ ou l'API Linux quasiment pas documenté, c'est une vraie partie de plaisir
Le fait que tu ne saches pas gerer cela ne signifie pas que c'est un probleme. Suffit de voir la flopee de drivers qui le font, et le fait que le sleep/hibernate sous Windows est enormement plus fiable que sous Linux
On leur demande pas pas non plus les masques et je ne crois pas que tu puisses apprendre grand chose d'utile à partir d'un simple pilote ou même de specs vu la vitesse de développement en ce domaine.
Ecoutes, tu peux avoir ton avis, libre a toi. Le truc, c'est que c'est l'avis des constructeurs qui importe parce que sans eux pas de driver de qualite. Alors tu peux leur repeter a l'envie que leur avis est mauvais et que tu sais mieux qu'eux ce qu'il leur faut, mais ca ne va pas aider et les drivers pour Linux resteront aussi pourri qu'ils le sont aujourd'hui.
Je te suggeres a la place un peu d'humilite, arreter de les prendre pour des cons qui ne comprennent rien, accepter que le modele que vous leur proposez ne leur convient pas, et essayer d'ameliorer le systeme pour qu'il reponde mieux a leurs besoins.
Techniquement, c'est une connerie les interfaces stables à long terme, windows en est bien la preuve avec win32, MFC, GDI, COM, ODBC une belle brochette de techno dépassées depuis plus d'une décennie et toujours au coeur du développement d'application windows.
Il y a plein de nouvelles interfaces dispo : D2D, WPF, etc... qui permettent de supporter les avancees, l'avantage c'est que tu as le choix.
Si les vendeurs faisaient un peu plus d'efforts à collaborer avec upstream, ils auraient pu aider à stabiliser l'architecture de Xorg, et en libérant les pilotes, laisser la communauté se charger des tâches subalternes. Les plus gros committers dans Xorg. ne sont pas employés par des constructeurs de cartes graphiques
De nouveau, la seule chose que tu fais c'est repeter a tut-tete ta vision des choses : C'est plus facile de liberer les sources ,etc...
Faut te faire a l'idee que les constructeurs, ils sont pas d'accord avec toi. Tu as le choix entre trouver un terrain d'entente avec eux en prenant en compte leurs desirs, ou leur repeter 500x fois qu'ils ont tort et qu'ils ne comprennent rien.
Si tu veux mon avis, la 1ere methode a beaucoup plus de chance d'aboutir.
Unix était un logiciel à sources ouvertes bien avant que ton patron ne troque ses culottes courtes pour des pantalons d'homme.
Tout a fait, et mon (ex-)patron a bouffe Unix par les couilles avec un OS ayant des interfaces standardisees, qui permettait de faire tourner l'OS sur une enorme variete de materiel tout en assurant que les softs tourneraient sans probleme sur cette variete de systemes.
Oh, et en passant, NT a ete cree par Dave Cutler, pas par Bill Gates, et ce dernier, il a comment dire une certaine experience du developpement d'OS, genre un truc insignifiant nomme VMS
[^] # Re: Argh
Posté par pasBill pasGates . En réponse au journal Xorg 1.8: épatant ?. Évalué à 6.
C'est beau la theorie hein ? Le truc c'est qu'en pratique visiblement ce que vous leur proposez ne leur plait pas.
Vous avez inventé un système pourri qui oblige les vendeurs à faire ce que vous voulez ...
Haha, certes, l'architecture de pilotes de windows est stable dans le temps, mais personne n'ose imaginer la terrible expérience infantile traumatisante qui a pu mener ses concepteurs à ça.
WDM, WDF efficaces ? faciliter la vie des développeurs ? j'en pleure de rire :o)
De nouveau, je regarde la realite, pas la theorie : Les constructeurs sont tres contents de faire leur drivers sous Windows, pas sous Linux. Ils n'ont pas besoin de filer leur specs ou sources, leurs drivers n'ont pas besoin d'etre modifies toutes les 3 semaines, les APIs sont tous documentes, MS livre des softs de tests pour verifier les drivers, il y a un debugger kernel extremement efficace, etc... et en bonus ils ont 95% du marche.
En face, ils doivent filer leur specs ou code source, ou ils doivent se taper la maintenance de drivers qui petent tous les mois pour supporter 1% de la population, le support du developpement kernel est comment dire, prehistorique, ...
Ca c'est une description de la realite. N'importe quel manager ou ingenieur qui n'est pas un fanatique de Linux verra vite quelle plateforme est la plus attrayante.
Techniquement, Apple fait ce que je propose de faire avec Xorg ===> une architecture unifié et la maintenance des pilotes par un seul acteur et non pas le foutoir où chacun fait ce qu'il veut.
Du tout, ce que fait Apple est ce que je dis : faire plaisir aux constructeurs.
Ils s'occupent du driver, tout en gardant secret ce qui doit l'etre, chose que X.org ne fait pas.
Sans eux, on ira pas très loin, on a beau les inviter à construire un chateau dans notre bac à sable, mais l'un veut construire un quart de pagode en bois dans son coin et écrase tout les 3 mois le flan droit, l'autre une fusée ariane qui finit invariablement par exploser en projetant du sable sur les enfants.
C'est un point de vue, moi je vois que :
a) Les constructeurs veulent avoir un support linux, ils paient des devs pour ca
b) Les constructeurs ne veulent pas partager leurs secrets
c) Moins il y a de travail necessaire pour le dev de drivers, mieux c'est
b) et c) ca signifie avoir une interface de drivers stable, qui ne demande pas aux constructeurs de devoir ouvrire leur specs et code source
Rien a voir avec construire des pagodes a la place de chateaux, c'est un concept informatique vieux de plusieurs decennies
[^] # Re: Argh
Posté par pasBill pasGates . En réponse au journal Xorg 1.8: épatant ?. Évalué à 8.
Non, la seule facon d'avoir un systeme efficace c'est d'ecouter ce que veulent les constructeurs et let aider en creant une plateforme qui leur facilite la vie.
Si on avait cree un systeme pourri ou ils doivent refaire leurs drivers tous les 4 matins, ou sinon ils sont obliges de devoiler leur code source, on en serait au meme point que X.org
Cf. le Mac qui a une part de marche minuscule, mais qui a un systeme efficace et qui fonctionne. Le probleme c'est pas forcement les parts de marche uniquement.
Vous pouvez continuer a vous enfoncer la tete dans le sable en rejetant la faute sur les constructeurs, mais ca ne fera certainement pas avancer le schmilblick.
[^] # Re: Argh
Posté par pasBill pasGates . En réponse au journal Xorg 1.8: épatant ?. Évalué à 0.
[^] # Re: Et ne pas avoir à protéger ces informations ?
Posté par pasBill pasGates . En réponse à la dépêche Threat modeling - Savez vous quelles sont les menaces qui guettent votre application ?. Évalué à 2.
D'avoir le code source me permet de réparer un dysfonctionnement quand je le détecte et ensuite j'aurais des risques en moins sur mon système
Ca c'est la theorie. Ca marche quelque fois. Mais tu sais si ton correctif ne va pas casser quelque chose d'autre ? Tu as une batterie de tests pour le valider ? Tu sais si ton correctif ne va pas creer une faille ailleurs ? Non, verifier ces choses la demande d'avoir une connaissance approfondie du soft et de pouvoir le tester de maniere approfondie.
Parce que j'ai rencontré ces problèmes et que j'ai eu les informations à disposition, j'ai pu les résoudre, envoyer ça en upstream et aujourd'hui certains logiciels sont un poil plus sécurisé.
Quand le firewall checkpoint plantait, à part envoyer un 32ème mail d'insulte que ça fait trois mois qu'on attend, je pouvais rien faire.
Ca c'est un autre probleme, le fait que certains editeurs ne donnent pas de reponse est un probleme, mais un probleme different.
[^] # Re: Et ne pas avoir à protéger ces informations ?
Posté par pasBill pasGates . En réponse à la dépêche Threat modeling - Savez vous quelles sont les menaces qui guettent votre application ?. Évalué à 3.
La première menace informatique c'est l'obscurité. Si je ne peux pas voir tous les rouages du système que j'utilise, comment je peux les montrer aux utilisateurs et les éduquer à utiliser correctement le logiciel ?
Tu m'excuseras, mais ca c'est une raison a la con.
Tu n'as certainement jamais audite le code de Linux ou de Firefox du point de vue securite, tu n'en as pas les competences (pas une critique, tres peu de gens l'ont), tu n'as pas la connaissance du code pour comprendre ce qu'il fait et ce qu'il est sense faire, ...
Tout ce que tu fais c'est te raccrocher a l'espoir que quelqu'un d'autre le fera, et le truc le plus fantastique est que cet "espoir" est absolument inutile. Quasiment aucun bug de securite n'est trouve par audit de code, quasiment tous sont trouves par fuzzing, y compris dans les logiciels open-source, car c'est une methode beaucoup plus efficace que revoir des millions de lignes de code. Et le fuzzing, ca ne depend pas de l'acces au code source.
[^] # Re: Un seul son de cloche...
Posté par pasBill pasGates . En réponse à la dépêche Bill Gates et la diversification externe. Évalué à 1.
a) Cette banque est geree par le gouvernement norvegien, pas par une societe.
b) Les produits deposes (semences) ne peuvent etre repris que par le depositaire et restent sa propriete
Bref, rien d'anormal ou de scandaleux au contraire, c'est quelque chose d'extremement utile.
[^] # Re: normal, le libre c'est gratuit…
Posté par pasBill pasGates . En réponse au journal [OSM] Mappy veut bien piller mais pas contribuer. Évalué à 1.
[^] # Re: Et ne pas avoir à protéger ces informations ?
Posté par pasBill pasGates . En réponse à la dépêche Threat modeling - Savez vous quelles sont les menaces qui guettent votre application ?. Évalué à 2.
[^] # Re: Pratiques d'une ère (dé)passée
Posté par pasBill pasGates . En réponse à la dépêche Threat modeling - Savez vous quelles sont les menaces qui guettent votre application ?. Évalué à 1.
[^] # Re: Et ne pas avoir à protéger ces informations ?
Posté par pasBill pasGates . En réponse à la dépêche Threat modeling - Savez vous quelles sont les menaces qui guettent votre application ?. Évalué à 2.
Dans le monde du web oui je peux le comprendre, dans le monde de l'entreprise par exemple c'est pas le cas. Les informations ici elles sont d'un tout autre ordre : code source, informations financieres, details techniques de produits a venir, etc...
[^] # Re: Pratiques d'une ère (dé)passée
Posté par pasBill pasGates . En réponse à la dépêche Threat modeling - Savez vous quelles sont les menaces qui guettent votre application ?. Évalué à 6.
...
Même tonneau pour celle-là : tu ne peux pas prévoir l'ensemble des risques donc ta liste va être obsolète aussitôt éditée.
Tout a fait, mais donc tu proposes quoi ? De ne rien faire parce qu'il est impossible de tout prevoir ?
Youpi, maintenant que tu as défini ce que tu appelles un "risque", tu es content d'avoir un outil pour classer les combinaisons entre attaque, cible et coût. L'ennui c'est que cette classification va te faire mettre en place des mesures préventives dédiées aux attaques les "plus risquées" tout en laissant de côté celles que tu vas considérer comme négligeables.
C'est possible, mais pas forcement, ca te permet aussi d'approcher la liste en odre de priorite tout simplement, savoir par quoi commencer.
Parce que soyons realiste, si tu ne l'as pas, tu risques a l'inverse de commencer par le risque le plus negligeable sans regler le risque le plus gros.
Toutes. La sécurité se conçoit comme un élément initial du développement du projet, pas comme une surcouche.
Oui ca c'est la belle theorie des gens qui n'ont jamais eu a s'occuper de la securite d'un gros projet.
La realite c'est que si tu as des composants qui sont utilises uniquement par l'interface d'administration par exemple, et que celle-ci est uniquement accessible a root, ben les auditer d'un point de vue securite ne sert pas a grand-chose, le gars il est deja root, une faille la dedans ne lui servira a rien, il n'en tirera rien d'utile, donc ca tombe en bas de la liste des priorites.
Ib idem, et pas que pour des raisons de sécurité, pour des raisons de stabilité aussi.
De nouveau, tu vas faire quoi avec ca ? Tu vas fuzzer la fonction memcpy(...) et lui passer des pointeurs illegaux dans ton espace d'addresse ? Pas tres utile vu que memcpy considere ses entrees comme sur par definition.
Tous. Sinon on en arrive à un désastre du même acabit que celui que Microsoft a su mettre en place lorsqu'ils ont autorisé leurs programmeurs à ne pas vérifier les valeur de retour des fonctions appelées.
Du tout, cf. l'exemple de memcpy
[^] # Re: Ah la moderation
Posté par pasBill pasGates . En réponse à la dépêche Bill Gates et la diversification externe. Évalué à 1.
Quand a tes dire, je te suggeres de te relire :
On pourra noter que les defenseurs de Bill Gates crie au scandale sur une attaque personnelle mais naturellement ne donne strictement aucun lien prouvant que tout ce qui a ete dit est faux. Curieux non?
Je te laisse une semaine pour analyser ta propre phrase, parce que visiblement c'est difficile pour toi, une fois que tu auras termine, reviens avec la reponse, sinon pense a arreter de pourrir ce site.
[^] # Re: normal, le libre c'est gratuit…
Posté par pasBill pasGates . En réponse au journal [OSM] Mappy veut bien piller mais pas contribuer. Évalué à 3.
Parce que bon, les accusations sans preuve, ca va un moment mais faudrait penser a elever le niveau quand meme a un moment.
[^] # Re: Restriction du choix des langages sur l'iPhone
Posté par pasBill pasGates . En réponse à la dépêche Panaché de brèves informatiques de la semaine. Évalué à 4.
Tu confonds, "private APIs" ca veut dire les APIs du systeme qui sont non-documentes, bref les APIs qu'ils utilisent en interne et qu'ils se reservent le droit de changer a un moment ou un autre.
C'est quelque chose que je peux tout a fait comprendre. Quand aux autres limitations, on va dire qu'Adobe est dans la ligne de mire d'Apple...