Ce n'est pas ce que j'ai dit.
Désolé, c'étais juste du sarcasme.
Mais pour toi, avec Windows et ses barrières magiques il n'y a pas de problème.
Jamais dis ça. Juste que c'est mieux, personne ne prétend que c'est magique. Y'a encore plein d'effort à faire pour sortir des trucs en userland, que ce soit dans le kernel NT que Linux.
Ooops.
Bah oué, c'est comme les capotes hein, c'est pas magique, des fois ça marche pas, faut-il pour autant s'en passer ? A part par conviction religieuse (Linus l'a dit : ca ne sert à rien)...
i tu trouves que les barrières sont indispensables, mets des barrières pour la pile TCP/IP (si elle plante elle est déchargée et rechargée), sur le FS, sur lvm, etc.
Ben oué et pouquoi pas ? C'est ce que fait minix pour TCP/IP, c'est ce que fait fuse pour les FS, c'est ce qu'explore MS avec Singularity, etc. En fait tout le monde est d'accord sur le principe, le seul soucis, c'est l'existant : pour des questions de performances (et pour pas se faire chier à s'enmerder), on a mis pleins de trucs prêt du kernel, trop prêt. Même dans Vista pour les drivers graphiques c'est pas "parfait", y'a encore un bout qui tourne avec les droits du kernel, mais l'objectif est clairement de limiter au maximum la quantité de code qui tourne dans cet espace.
Ça m'étonnerais grave mais admettons.
Mais où est la difficulté ? Même le kernel Linux est capable de charger et décharger dynamiquement des modules ! La seule différence, c'est dans quel espace ils tournent... "If a WDDM driver hangs or encounters a fault, the graphics stack will restart the driver. A graphics hardware fault will be intercepted and if necessary the driver will be reset. Drivers under Windows XP were free to deal with hardware faults as they saw fit either by reporting it to the user or by attempting to recover silently. With a WDDM driver, all hardware faults cause the driver to be reset and the user
will be notified by a popup; this unifies the behavior across vendors." http://en.wikipedia.org/wiki/Windows_Display_Driver_Model
En quoi ajouter des barrières va aider à maintenir plus de driver. Je ne vois pas ou tu veux en venir.
Mais je prétend pas que ca va aider à maintenir plus de driver, je dis juste que ca va éviter à un driver buggé (aucun driver n'est exempt de bug) de faire tomber le système.
mais le problème de Linux n'est pas l'absence de barrière (Vista avec des barrières plante aussi)
Argument totalement fallacieux. La question n'est pas de savoir si ca plante ou non : aucune protection n'est parfaite, aucun logiciel et donc barrière logicielle n'est exempt de bug et de plantage.
Ce qui est sûr, c'est que dans la vraie vie, de nombreux plantage de driver graphique sous Vista sont récupérés proprement. C'est autant de plantage en moins : la barrière montre tout son intérêt.
ajouter des barrières n'apporte pratiquement rien et ne va pas résoudre ces problèmes.
On est d'accord, y'a un problème de moyen, faut faire des priorités, je ne remets même pas en cause ces choix de priorité (je préfères avoir Nouveau on est d'accord). Mais affirmer comme le fait Linus que ca sert rien, que c'est inutile, c'est du foutage de gueule.
Avec les barrières il y a plus de complexité et il faut plus de moyen pour maintenir l'ensemble.
Ca a un coût et demande des moyens pour être mis en place, certes. Mais c'est pas "plus complexe" pour moi. Une fois mis en place, c'est pas plus dur à maintenir. Le plus dur, c'est la transition avec l'existant. C'est d'ailleur pourquoi tous les projets de kernel comme Hurd Mach ou Minix vont direct sur ce type de segmentation : c'est pas plus dur, parcqu'ils s'enmerdent pas avec l'existant.
Quand un driver ne marche pas, il ne marche pas.
Encore une fois, c'est pas une question de "ca marche"/"ca marche pas". C'est des logiciels informatiques : y'a des bugs, qui apparaîssent dans certaines conditions, pas chez tout le monde, avec une fréquence plus ou moins élevée, ca peut aussi être un problème hardware ponctuel, etc.
Faut s'y faire, rien n'est parfait. Les barrières permettent juste à l'utilisateur de ne pas vivre une mauvaise expérience au moment où ca part en vrille.
Je suis sûr qu'on va assiter à une amélioration énorme de la qualité globale
Quand la solution concurrente améliore la qualité de son système, c'est pas possible puisque "ca marche ou ca marche pas". Et là tout à coup c'est l'inverse ? :)
T'es bien prétentieux de contredire Linus.
Ah oui on peut pas contredire le pape. C'est vrai que Linus n'est pas du tout réputé pour être un trolleur aux idées bien arrêtés. C'est pas parcqu'ils a de nombreuses qualités (techniques et leadership) qu'il a la vérité absolue.
Dit le à MS. MS sera content de savoir qu'il a des économies à faire.
Ben infine, pour MS, le but est de limiter les coûts de maintenance/support et d'image : quand l'OS tombe à cause d'un driver, l'utilisateur il voit un écran bleu et peste après Microsoft. Là MS se "protège" des drivers qu'il ne maîtrise pas : au final ils font des économies.
De toute façon je suis bien d'accord que c'est en partie un problème de moyen. Mais quand le chef dit que de toute façon ca sert à rien, la question des moyens se pose même pas puisque le chef a dit.
[^] # Re: L'avis de Linus
Posté par TImaniac (site web personnel) . En réponse à la dépêche MINIX 3 - Google Summer of Code. Évalué à 2.
Désolé, c'étais juste du sarcasme.
Mais pour toi, avec Windows et ses barrières magiques il n'y a pas de problème.
Jamais dis ça. Juste que c'est mieux, personne ne prétend que c'est magique. Y'a encore plein d'effort à faire pour sortir des trucs en userland, que ce soit dans le kernel NT que Linux.
Ooops.
Bah oué, c'est comme les capotes hein, c'est pas magique, des fois ça marche pas, faut-il pour autant s'en passer ? A part par conviction religieuse (Linus l'a dit : ca ne sert à rien)...
i tu trouves que les barrières sont indispensables, mets des barrières pour la pile TCP/IP (si elle plante elle est déchargée et rechargée), sur le FS, sur lvm, etc.
Ben oué et pouquoi pas ? C'est ce que fait minix pour TCP/IP, c'est ce que fait fuse pour les FS, c'est ce qu'explore MS avec Singularity, etc. En fait tout le monde est d'accord sur le principe, le seul soucis, c'est l'existant : pour des questions de performances (et pour pas se faire chier à s'enmerder), on a mis pleins de trucs prêt du kernel, trop prêt. Même dans Vista pour les drivers graphiques c'est pas "parfait", y'a encore un bout qui tourne avec les droits du kernel, mais l'objectif est clairement de limiter au maximum la quantité de code qui tourne dans cet espace.
Ça m'étonnerais grave mais admettons.
Mais où est la difficulté ? Même le kernel Linux est capable de charger et décharger dynamiquement des modules ! La seule différence, c'est dans quel espace ils tournent...
"If a WDDM driver hangs or encounters a fault, the graphics stack will restart the driver. A graphics hardware fault will be intercepted and if necessary the driver will be reset. Drivers under Windows XP were free to deal with hardware faults as they saw fit either by reporting it to the user or by attempting to recover silently. With a WDDM driver, all hardware faults cause the driver to be reset and the user
will be notified by a popup; this unifies the behavior across vendors."
http://en.wikipedia.org/wiki/Windows_Display_Driver_Model
En quoi ajouter des barrières va aider à maintenir plus de driver. Je ne vois pas ou tu veux en venir.
Mais je prétend pas que ca va aider à maintenir plus de driver, je dis juste que ca va éviter à un driver buggé (aucun driver n'est exempt de bug) de faire tomber le système.
mais le problème de Linux n'est pas l'absence de barrière (Vista avec des barrières plante aussi)
Argument totalement fallacieux. La question n'est pas de savoir si ca plante ou non : aucune protection n'est parfaite, aucun logiciel et donc barrière logicielle n'est exempt de bug et de plantage.
Ce qui est sûr, c'est que dans la vraie vie, de nombreux plantage de driver graphique sous Vista sont récupérés proprement. C'est autant de plantage en moins : la barrière montre tout son intérêt.
ajouter des barrières n'apporte pratiquement rien et ne va pas résoudre ces problèmes.
On est d'accord, y'a un problème de moyen, faut faire des priorités, je ne remets même pas en cause ces choix de priorité (je préfères avoir Nouveau on est d'accord). Mais affirmer comme le fait Linus que ca sert rien, que c'est inutile, c'est du foutage de gueule.
Avec les barrières il y a plus de complexité et il faut plus de moyen pour maintenir l'ensemble.
Ca a un coût et demande des moyens pour être mis en place, certes. Mais c'est pas "plus complexe" pour moi. Une fois mis en place, c'est pas plus dur à maintenir. Le plus dur, c'est la transition avec l'existant. C'est d'ailleur pourquoi tous les projets de kernel comme Hurd Mach ou Minix vont direct sur ce type de segmentation : c'est pas plus dur, parcqu'ils s'enmerdent pas avec l'existant.
Quand un driver ne marche pas, il ne marche pas.
Encore une fois, c'est pas une question de "ca marche"/"ca marche pas". C'est des logiciels informatiques : y'a des bugs, qui apparaîssent dans certaines conditions, pas chez tout le monde, avec une fréquence plus ou moins élevée, ca peut aussi être un problème hardware ponctuel, etc.
Faut s'y faire, rien n'est parfait. Les barrières permettent juste à l'utilisateur de ne pas vivre une mauvaise expérience au moment où ca part en vrille.
Je suis sûr qu'on va assiter à une amélioration énorme de la qualité globale
Quand la solution concurrente améliore la qualité de son système, c'est pas possible puisque "ca marche ou ca marche pas". Et là tout à coup c'est l'inverse ? :)
T'es bien prétentieux de contredire Linus.
Ah oui on peut pas contredire le pape. C'est vrai que Linus n'est pas du tout réputé pour être un trolleur aux idées bien arrêtés. C'est pas parcqu'ils a de nombreuses qualités (techniques et leadership) qu'il a la vérité absolue.
Dit le à MS. MS sera content de savoir qu'il a des économies à faire.
Ben infine, pour MS, le but est de limiter les coûts de maintenance/support et d'image : quand l'OS tombe à cause d'un driver, l'utilisateur il voit un écran bleu et peste après Microsoft. Là MS se "protège" des drivers qu'il ne maîtrise pas : au final ils font des économies.
De toute façon je suis bien d'accord que c'est en partie un problème de moyen. Mais quand le chef dit que de toute façon ca sert à rien, la question des moyens se pose même pas puisque le chef a dit.