> > 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 ?
Si c'est si indispensable que ça, pourquoi ça n'a pas été fait ?
Depuis combien de temps existe Windows ?
Oublions Win16 et Win 9*. Mais le noyau d'aujourd'hui descend directement de Windows 2000. En presque 10 ans ça n'a pas été fait alors que MS (ou que toi) ne juge que par les micro-noyau, n'y voit que des avantages, pense que ça ne demande pas plus de moyen à faire qu'un noyau classique, etc. Et en plus MS a des moyens délirant.
Expliques moi ça ?
> c'est ce que fait fuse pour les FS
Fuse c'est bien mais c'est lent et ça le restera très probablement.
> En fait tout le monde est d'accord sur le principe
Non. Sinon "tout le monde" dans le libre se serait précipité sur Minix ou Hurd. NB: ça existait avant que Linux soit commercialement utilisé.
> > Ç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 !
Tu ne peux pas décharger un module Linux s'il est utilisé. En fait, on peut, mais s'il n'y a pas une explosion après, c'est un coup de chance. le "rmmod --force" n'est pas supporté (les rapports de bug sur ses conséquences seront refusés).
Le problème, à mon avis qui n'est pas celui d'un expert, n'est pas principalement côté noyau, mais côté userland. Les applis peuvent écrire directement dans la mémoire de la carte graphique (par exemple une texture) et surtout sans le savoir (avec Direct3D on sait que tout peu disparaitre à tout moment et donc le développeur le gère). Elles ont l'adresse de la texture et peuvent l'utiliser. Comment tu fais si tu vires tout le driver et donc tout ce qui a été alloué par la carte graphique ?
C'est de l'informatique on peut trouver une solution. Mais bonjour la quantité de boulot à faire seulement pour un gain théorique de fiabilité. Surtout que cette quantité de boulot serait plus efficace pour la fiabilité s'il était mis sur la fiabilité des drivers au-lieu de singer un micro-noyau.
Cool.
Combien d'année homme il a fallu ? Linux préfère les mettre ailleurs.
> > mais le problème de Linux n'est pas l'absence de barrière (Vista avec des barrières plante aussi)
> Argument totalement fallacieux.
Il ne l'ai pas. Windows n'a pas de barrière pour TCP/IP, etc et si tu expliques pourquoi je ne vais pas rétorquer systématique "Argument totalement fallacieux".
Ici tu dis que MS n'a aucun excuse de ne pas avoir encore fait de barrière pour le réseau, les systèmes de fichier, etc.
Si Linux est un connard de ne pas l'avoir fait pour les cartes graphiques, MS est un double connard. MS croit aux barrières, Linux non (et donc n'est pas un double connard).
> C'est autant de plantage en moins : la barrière montre tout son intérêt.
Je vais me répéter, je n'ai pas dit que ce n'était pas bien, mais que :
1- dans le cas de Windows un driver graphique peut toujours faire plante tout le système
2- Linux a d'autres priorités
> 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).
Merci.
> Mais affirmer comme le fait Linus que ca sert rien, que c'est inutile, c'est du foutage de gueule.
Windows n'a pas un micro-noyau. Répète après moi et lentement : "Win-dows n'a pas un mi-cro-noy-au".
Certes on trouve des trucs qui ressemble à un micro-noyau mais Windows n'a pas fait, ni le peu, la démontration qu'un micro-noyau est mieux qu'un noyau classique.
> c'est du foutage de gueule.
Le foutage de gueule, c'est toi qui le fait. Tu dis que les micro-noyau c'est mieux, que ça ne demande pas de moyen suplémentaire pour les faire, pousse Windows comme exemple de micro-noyau alors que ce n'est pas un micro-noyau, pire, tu dis que tout le monde est d'accord sur ça, mais ... il n'y a pas de micro-noyau de qualité pour les OS généraliste.
Pour le foutage de gueule, tu sais y faire.
De loins la théorie peut te donner la raison, mais l'histoire donne raison Linus et la position de Linus s'est faite avant que l'histoire en est jugé.
> Ca a un coût et demande des moyens pour être mis en place, certes.
C'est bien de le reconnaitre enfin. Merci.
> 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
Hurd a 18 ans ! Hurd a débuté avant Linux ! Soyons gentil, en même temps que Linux.
Je ne sais pas exactement dans quel état il est, mais je ne serait pas étonné qu'il soit aujourd'hui moins fonctionnel qu'un Linux 2.0 qui est sorti il y a plus 10 ans.
Bref, tu dis n'importe quoi.
> 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 ? :)
Tu refuses de considérer l'ensemble du problème. Un projet n'est pas que la somme des atouts théorique loin des réalités. Un projet est un compromis entre différentes contraintes et c'est l'équilibre du tout qui fait la qualité du projet. Les micro-noyau, théoriquement et sans considérer les contraintes (complexité, difficulté à optimiser), c'est bien. Mais un projet qui n'est maîtrisé que par une poignée de personnes et accèpte une pénalité en performance de 30 % (a performance équivalente il faut acheter du matos plus cher) pour éviter un plantage pour les 36 du mois à quelques bécanes non critiques est un mauvais projet.
> > T'es bien prétentieux de contredire Linus.
> Ah oui on peut pas contredire le pape.
Rires. C'est toi qui traitait Linus de prétentieux :
- "il paraît donc un brin prétentieux de la part de Linus"
Linus est un pointeur et tu lui fais la leçon.
C'est mortel de rire.
> 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.
Avec l'historique de Windows, il y a de quoi rire.
Si MS était si soucieux des désagréments des utilisateurs, MS n'aurait pas fait la niche a virus qu'est Windows (ou IE ou Outlook etc).
Les choses s'arrange (très lentement), mais pitié, ne nous fait pas du violon.
> 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.
C'est du libre. Si le chef déconne, il est viré. Linus ne sait pas auto-proclamé chef, les développeurs l'y ont mis et il a largement fait ses preuves comme "dictateur" (d'une dictature douce sinon il est viré) d'un des projets les plus regardé et dont les enjeux sont énormes.
Que tu ne sois d'accord avec lui, OK, mais tu lui dois plus de respect et aussi aux développeurs qui accèptent librement (contrairement aux développeurs Windows) d'avoir Linus comme "dictateur".
[^] # Re: L'avis de Linus
Posté par IsNotGood . En réponse à la dépêche MINIX 3 - Google Summer of Code. Évalué à 2.
> Ben oué et pouquoi pas ?
Si c'est si indispensable que ça, pourquoi ça n'a pas été fait ?
Depuis combien de temps existe Windows ?
Oublions Win16 et Win 9*. Mais le noyau d'aujourd'hui descend directement de Windows 2000. En presque 10 ans ça n'a pas été fait alors que MS (ou que toi) ne juge que par les micro-noyau, n'y voit que des avantages, pense que ça ne demande pas plus de moyen à faire qu'un noyau classique, etc. Et en plus MS a des moyens délirant.
Expliques moi ça ?
> c'est ce que fait fuse pour les FS
Fuse c'est bien mais c'est lent et ça le restera très probablement.
> En fait tout le monde est d'accord sur le principe
Non. Sinon "tout le monde" dans le libre se serait précipité sur Minix ou Hurd. NB: ça existait avant que Linux soit commercialement utilisé.
> > Ç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 !
Tu ne peux pas décharger un module Linux s'il est utilisé. En fait, on peut, mais s'il n'y a pas une explosion après, c'est un coup de chance. le "rmmod --force" n'est pas supporté (les rapports de bug sur ses conséquences seront refusés).
Le problème, à mon avis qui n'est pas celui d'un expert, n'est pas principalement côté noyau, mais côté userland. Les applis peuvent écrire directement dans la mémoire de la carte graphique (par exemple une texture) et surtout sans le savoir (avec Direct3D on sait que tout peu disparaitre à tout moment et donc le développeur le gère). Elles ont l'adresse de la texture et peuvent l'utiliser. Comment tu fais si tu vires tout le driver et donc tout ce qui a été alloué par la carte graphique ?
C'est de l'informatique on peut trouver une solution. Mais bonjour la quantité de boulot à faire seulement pour un gain théorique de fiabilité. Surtout que cette quantité de boulot serait plus efficace pour la fiabilité s'il était mis sur la fiabilité des drivers au-lieu de singer un micro-noyau.
> http://en.wikipedia.org/wiki/Windows_Display_Driver_Model
Cool.
Combien d'année homme il a fallu ? Linux préfère les mettre ailleurs.
> > mais le problème de Linux n'est pas l'absence de barrière (Vista avec des barrières plante aussi)
> Argument totalement fallacieux.
Il ne l'ai pas. Windows n'a pas de barrière pour TCP/IP, etc et si tu expliques pourquoi je ne vais pas rétorquer systématique "Argument totalement fallacieux".
Ici tu dis que MS n'a aucun excuse de ne pas avoir encore fait de barrière pour le réseau, les systèmes de fichier, etc.
Si Linux est un connard de ne pas l'avoir fait pour les cartes graphiques, MS est un double connard. MS croit aux barrières, Linux non (et donc n'est pas un double connard).
> C'est autant de plantage en moins : la barrière montre tout son intérêt.
Je vais me répéter, je n'ai pas dit que ce n'était pas bien, mais que :
1- dans le cas de Windows un driver graphique peut toujours faire plante tout le système
2- Linux a d'autres priorités
> 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).
Merci.
> Mais affirmer comme le fait Linus que ca sert rien, que c'est inutile, c'est du foutage de gueule.
Windows n'a pas un micro-noyau. Répète après moi et lentement : "Win-dows n'a pas un mi-cro-noy-au".
Certes on trouve des trucs qui ressemble à un micro-noyau mais Windows n'a pas fait, ni le peu, la démontration qu'un micro-noyau est mieux qu'un noyau classique.
> c'est du foutage de gueule.
Le foutage de gueule, c'est toi qui le fait. Tu dis que les micro-noyau c'est mieux, que ça ne demande pas de moyen suplémentaire pour les faire, pousse Windows comme exemple de micro-noyau alors que ce n'est pas un micro-noyau, pire, tu dis que tout le monde est d'accord sur ça, mais ... il n'y a pas de micro-noyau de qualité pour les OS généraliste.
Pour le foutage de gueule, tu sais y faire.
De loins la théorie peut te donner la raison, mais l'histoire donne raison Linus et la position de Linus s'est faite avant que l'histoire en est jugé.
> Ca a un coût et demande des moyens pour être mis en place, certes.
C'est bien de le reconnaitre enfin. Merci.
> 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
Hurd a 18 ans ! Hurd a débuté avant Linux ! Soyons gentil, en même temps que Linux.
Je ne sais pas exactement dans quel état il est, mais je ne serait pas étonné qu'il soit aujourd'hui moins fonctionnel qu'un Linux 2.0 qui est sorti il y a plus 10 ans.
Bref, tu dis n'importe quoi.
> 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 ? :)
Tu refuses de considérer l'ensemble du problème. Un projet n'est pas que la somme des atouts théorique loin des réalités. Un projet est un compromis entre différentes contraintes et c'est l'équilibre du tout qui fait la qualité du projet. Les micro-noyau, théoriquement et sans considérer les contraintes (complexité, difficulté à optimiser), c'est bien. Mais un projet qui n'est maîtrisé que par une poignée de personnes et accèpte une pénalité en performance de 30 % (a performance équivalente il faut acheter du matos plus cher) pour éviter un plantage pour les 36 du mois à quelques bécanes non critiques est un mauvais projet.
> > T'es bien prétentieux de contredire Linus.
> Ah oui on peut pas contredire le pape.
Rires. C'est toi qui traitait Linus de prétentieux :
- "il paraît donc un brin prétentieux de la part de Linus"
Linus est un pointeur et tu lui fais la leçon.
C'est mortel de rire.
> 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.
Avec l'historique de Windows, il y a de quoi rire.
Si MS était si soucieux des désagréments des utilisateurs, MS n'aurait pas fait la niche a virus qu'est Windows (ou IE ou Outlook etc).
Les choses s'arrange (très lentement), mais pitié, ne nous fait pas du violon.
> 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.
C'est du libre. Si le chef déconne, il est viré. Linus ne sait pas auto-proclamé chef, les développeurs l'y ont mis et il a largement fait ses preuves comme "dictateur" (d'une dictature douce sinon il est viré) d'un des projets les plus regardé et dont les enjeux sont énormes.
Que tu ne sois d'accord avec lui, OK, mais tu lui dois plus de respect et aussi aux développeurs qui accèptent librement (contrairement aux développeurs Windows) d'avoir Linus comme "dictateur".