> Bien plus que celui de Linus qui est "de toute façon ca sert à rien c'est nul"
Linus dit ça des micro-noyau alors qu'il parle de l'architecture d'un noyau.
Et comme Windows n'est pas un micro-noyau, Microsoft ne lui donne tord. Microsoft a écrit de 0 Windows NT et n'a pas choisi de faire un vrai micro-noyau car Microsoft pense grosso-modo la même chose que Linus.
> reconnaître que le chemin pris par MS va dans le sens des micro-noyaux
Mouaif. Ben ça ne va pas vite en plus de 15 ans (?) d'existance de Windows NT.
> c'est les arguments totalement bancales de Linus.
Pourquoi ils son bancales ?
Ils sont confirmés par la réalité. En 1990 si tu disais qu'ils étaient bancales, je n'aurais rien dit. Mais aujourd'hui... Faut arrêter le délire.
Certes Linus le dit brutalement, on peut penser qu'il exagère, etc. Mais l'histoire lui a donné raison. Tu peux ajouter "jusqu'à maintenant".
> Non, Linux a eu du succès parcqu'il est vite devenu opérationnel et qu'il a su fédérer les développeurs. Il a maintenant une base très importante de drivers ce qui fait son succès.
Donc il a eu raison. Fin.
> C'est pas pour autant que le choix d'architecture fait y'a 15 ans est toujours aussi pertinent.
Non, presque rien n'a changé !
Je peux aussi dire que faire un noyau en Java ou C# est un avantage et blablabla.
Honte à Microsoft, Microsoft ne veut pas faire son noyau en C# alors que c'est irréfutablement un avantage !
Sur le papier c'est un avantage. Dans la réalité non. Idem pour les micro-noyau.
> Si les autres noyaux n'ont pas de succès, c'est pas pour des problèmes d'architecture, c'est pour des problèmes de moyens
Les micro-noyau ont eu des moyens et même beaucoup plus que Linux à l'époque des débuts de Linux. MS avec WinNT, Apple/Nextstep, Digital. Mais, ils n'ont pas fait de vrai de micro-noyau...
Pourtant à l'époque le concèpte de micro-noyau était plus séduisant qu'aujourd'hui : les micro-noyau était l'avenir et les noyaux monolithique était destiner à disparaitre.
Aujourd'hui les choses sont encore moins en faveur pour les micro-noyau alors j'ai bien du mal à croire qu'aujourd'hui il est plus pertinent de faire un micro-noyau qu'il y a 15 ans.
> un noyau sans drivers n'aura pas d'utilisateurs, c'est un cercle vicieux.
Le problème des micro-noyau n'est pas que là. L'histoire l'a montré.
> j'ai environ un crash graphique toutes les 2h de jeu
Sous Linux on corrige le driver, on ne met pas en place une infrastructure pour récupérer le driver.
Je ne vois absolument pas en quoi l'une des deux démarches est supérieure à l'autre.
> Hop je le vois mais ca me gène pas.
Hop je ne vois pas de problème sous Linux, ça ne me gène pas.
> Ca c'est la vraie vie
Ça c'est la vraie vie
> un constat clair : cette fonctionnalité de Vista est un confort indéniable.
Quand on a un driver pourri. Oui. Mais Linux ne veut pas de driver pourri pour les cartes graphiques comme Windows ne veut, ni ne peut tolérer, de driver pourri pour les disques, pour le réseau, pour le son, pour le gestionnaire de mémoire, pour l'ordonnanceur, etc.
> Linus s'obstine à dire que ca sert à rien quand des gens s'en servent dans la vraie vie.
Si tu décides qu'il ne faut pas corriger le driver, ça sert à quelque chose. Si tu décides corriger le driver ça ne sert à rien. Le logiciel libre a les sources, le logiciel libre corrige les bugs.
> Qui est éloigné de la réalité ?
Tu ne veux entendre que la réalité de Windows.
Écoute la réalité de Linux.
Je n'ai pas dit que Windows avait tord, mais que ça ne me semble pas bon pour Linux dont le contexte de développement, ses méthodes, etc n'ont pratiquement rien à voir avec Windows qui a le culte du binaire et des API figées. Si l'API Linux sucks, on l'a change et on met à jour tous les drivers (on a les sources). Si l'API Windows sucks ? Ben on prie que le système de récupération fasse son job.
Essaie de comprendre la réalité de Linux qui n'est pas celle de Windows. Peut-être que tu penseras toujours que Linux a tord, mais tu dois au moins reconnaitre que Linux a moins de raison de faire des barrières pour les drivers graphiques que Windows.
> Oui je dis qu'il est prétentieux, et j'essai d'argumenter. Toi tu me dis que je peux pas, par respect pour je-sais-pas-quoi.
Tu as dit : "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. "
Que tu le traites de prétentieux me fait seulement rire.
Que tu remettes en cause la position de leader de Linus (comme s'il avait été parachuté "chef"), ça ne me fait pas rire.
Que tu traites les développeurs linux d'idôlatrer Linus (ils suiveraient aveuglement Linus), ça ne me fait pas rire.
Linus peut être viré à tout moment. Il est le leader de Linux car il le mérite et qu'il n'y a pas meilleur que lui pour ce job actuellement. Il n'est pas le chef car une autorité supérieur lui en a donnée mandat, mais car les développeurs le veulent (jusqu'à maintenant).
> Le pape déconne, il est toujours là.
T'es con ou tu le fais exprès ?
Le pape est nommé à vie. Linus non.
> je pars de la réalité, de la vraie vie, d'exemples concrêts : mon expérience avec les crash graphiques, d'autres que moi ici semble vivre le même genre de problème
Et ?
En passant, je n'ai pas dit que MS avait tord de le faire (faut dire que Windows n'est pas une de mes préoccupations). Je dis qu'une autre voix est possible, que les micro-noyau ne sont pas forcément supérieur dans la pratique.
Donnes à Linux les moyens de MS, le même support des constructeurs, et je serais HYPER supris qu'il y ait plus de plantage du système à cause des drivers graphiques sous Linux que sous Windows.
Les plantages du système à cause du drivers graphique existe sous Windows et sous Linux. Ils ont rares (j'en ai jamais eu sur mes systèmes Linux ; je veux bien croire que j'ai eu de la chance). Je ne crois pas que si Linux avait les même moyens que Windows, ou même seulement un quart des moyens de Windows, Linux aurait plus de plantage système à cause du driver graphique que Windows.
> je t'ai pointé un doc de stats de MS sur le nombre de plantage récupérés, c'est autant de faits qui montre que ces barrières ont un intérêt
Les barrières ne sont pas un truc qui s'ajoute, comme par exemple on ajoute SeLinux à Linux. Elles demandes un grosse réorganisation du noyau, de nouvelles contraintes, etc. C'est l'ensemble qu'il faut juger. Et si on juge l'ensemble (noyau Windows et noyau Linux), les barrières n'ont pas montré un intérêt. Peut-être un intérêt pour le noyau Windows, son organisation, son mode de développement. Pas pour Linux.
T'as pointé une truc qui montre qu'il y a des plantages des drivers graphiques sur Vista. T'as pointé un truc qui montre qu'il y a beaucoup de plantage des drivers graphiques sous Vista. Tu confirmes qu'il y a beaucoup de plantage des drivers graphiques sous Vista. D'autres utilisateurs le confirme. Je le confirme aussi, le drivers graphique Intel (i945) sous Vista plante et ça m'arrivait toutes les semaines. Certes, dans mon cas tous ces plantages ont été récupérés (sauf que parfois je n'avais plus l'interface aero...).
Il y a beaucoup de plantage graphique et 7 % (si j'ai bonne mémoire) de ces nombreux plantages graphiques, aboutisse à un plantage système !
Bref, ce n'est pas la preuve que l'architecture de Vista donne une meilleur fialibité, mais seulement que beaucoup de ses très nombreux plantages graphiques sont récupérés.
Linux ne veut pas récupérer la majorité des plantages du drivers graphiques, Linux veux des drivers graphiques de qualité. Je ne crois pas qu'il sera difficule pour Linux d'avoir 20 fois moins de plantage du drivers graphique que Vista. Et même si chaque plantage graphique aboutit à un plantage système pour Linux, ça fera moins de plantage système que Vista à cause du driver graphique.
> Mais visiblement il a un problème d'égo.
Et toi ?
Ton raisonnement est pourri.
Je vais l'appliquer pour les transports :
- Les airbags des voitures sauvent 30 % de vie
- Les avions n'ont pas d'airbags
- Donc se déplacer en avion est plus dangereux que se déplacer en voiture
> mais les développeurs de micro-noyau ont-ils les moyens qu'à linux ?
Aujourd'hui c'est claire que non.
Mais en 1990 l'écart n'était pas celui d'aujourd'hui. En tout cas, si les micro-noyau étaient aussi prometteurs qu'on le dit, le manque de moyen aurait dû être compensé par la supériorité (prétendue) de l'architecture micro-noyau. Mais ce n'est pas que qu'on a vu.
Notons aussi que Hurd n'a pas créé de micro-noyau, il en a pris des déjà existant. A l'époque Linux a pratiquement tout fait.
> Derrière linux il y a quand même un investissement croissant d'un certain nombre de boites dont certaines ne sont pas des plus petites (au hasard IBM).
MS, Apple (et nextstep), Digital Equipement, pour en citer quelques uns, sont aller sur la voie micro-noyau. Donc les moyens ne manquaient pas et les micro-noyau ont eu leur chance. Au final ils ont fait des trucs "bâtards". En face le petit linux et avec des moyens bien moindre c'est fait une place au soleil.
Pourquoi ils ne sont pas allé au bout de la démarche micro-noyau ? Peut-être car ils ont rapidement constaté que c'était aller droit dans le mur en klaxonnant. Hurd a fait la tête de mule.
> A l'origine ce mechanisme est destiné a garantir la sécurité (en évitant les fausses mires de login par ex) mais peut aussi servir a lancer un interface de gestion de process comme c'est le cas dans WinNT (sequence ctrl-alt-del).
Le ctrl-alt-del pour se logguer c'est très limité.
Un programme ne peut détecter ctrl-alt-del (il n'y a que le noyau sous win qui peut le faire), mais il suffit de faire une mire de login qui ne détecte que des touches ctrl et alt. Je suis sûr que ça marchera au moins 19 fois sur 20.
Mouaif.
Sûr, il y a QNX. Je n'ai pas dit que les micro-noyau sont obligatoirement mauvais, mais qu'ils n'ont rien démontré lorsqu'il sagit d'un OS généraliste (desktop et serveur). S'ils ont démontré quelque chose, c'est la quasi inadaption des micro-noyau pour faire un OS généraliste.
> mais il a aussi rejeté des arguments pour le micro-noyau sans réelles justifications (stabilité, sécurité).
Il l'a justifié, le problème est la complexité.
> Le micro-noyau apporte plus de sécurité et de stabilité 'by-design'.
Ce n'est pas le design de haut-niveau qui compte, c'est la réalité.
Un petit exemple : http://fr.wikipedia.org/wiki/Noyau_de_système_d'exploitation
D’un point de vue théorique, le grand nombre de lignes de code exécutées en mode noyau engendre des problèmes de portabilité. La pratique contredit largement la théorie et les noyaux modulaires sont aujourd’hui les plus portés.
> Il n'y a qu'à compter le nombre d'exploits noyau pour Linux,
Mauvais argument. Compile un Linux pour l'embarquer (en virant le maximum de chose) et il n'y a qu'un très petit nombre de bug de Linux qui t'affecte. Les bugs qui t'affectent peuvent être plus probablement trouvé et plus vite si tu utilises un système très diffusé/audité.
> suivent une courbe exponentielle
Exponentielle par rapport à quoi ?
> Mais plus la complexité du système augmente plus ceci devient coûteux alors que l'isolation dans des systèmes étanches permet de limiter le périmètre impacté par les bugs.
L'argument se tient. Mais faire "des systèmes étanches" est compliqué, pas simple. Et dans quelle mesure sont-ils étanches ? Un serveur web, même dans un micro-noyau, n'est pas isolé du reste. Il doit récupérer des fichiers (donc intération avec le FS, le pilote des disques), accéder au réseau (intéraction avec la pile TCP/IP), etc.
Linus répond à ton argument, ça commence par "Tout l'argument disant que les micro-noyaux sont "plus sécurisés" ou "plus stables" est aussi totalement grotesque".
Le "grotesque" est un peu fort, mais on sait comment s'exprime Linus.
Ici chaque solution a ses avantages et inconvéniants pour la stabilité et sécurité.
Notons que Linus est dans l'objectif de faire un OS généraliste. Pas un OS qui sacrifie tout pour conserver la pureté du design.
Chercher les performances à un coût : http://fr.wikipedia.org/wiki/Noyau_de_système_d'exploitation#Syst.C3.A8mes_.C3.A0_micro-noyaux (on y trouvera aussi des conneries :-))
Le grand nombre d’appels système et la communication sous-jacente sont un défaut inhérent à la conception des micro-noyaux. Dans L4, il a été résolu en plaçant encore plus de services en espace utilisateur. La rapidité de traitement des IPC a pu être améliorée en simplifiant les communications au maximum, par exemple en supprimant toute vérification des permissions, laissant ce soin aux serveurs externes.
Es-ce le cas de QNX ?
Si oui, l'avantage sécurité est très discutable pour ne pas dire qu'il disparait.
> plus un code est long et plus il y a de chande d'y avoir des erreurs à l'intérieur
La longueur du code compte mais ne me semble pas le facteur le plus important.
Ajouter des drivers à Linux augmente le nombre de bug dans les sources du noyau, chaque driver pouvant apporter son lot de bug. Mais tous les drivers de Linux ne sont pas utilisés en même temps, donc ajouter un driver ou un système de fichier ne diminue pas la fiabilité de Linux.
Par contre la complexité est vraiment un paramètre important sur la qualité.
On peut faire un programme fleuve (par exemple les programmes avec interface graphique riche) sans beaucoup de bug mais surtout assez facile à trouver. Dans le cas de programme comme un noyau, avec des optimisations un peu partout, avec du multi-thread, etc ça peut tourner au cauchemar.
J'avais vu un blog "marrant". Un développeur esprimait sa joie d'avoir enfin supprimé un bug de Linux après 4 mois d'effort à le chercher !
Une fois j'ai passé 2 semaines à seulement chercher un bug (plantage aléatoire en moyenne toutes les 4 heures) dans un de mes programmes. C'est vraiment creuvant à faire et on passe par des "grands moments de solitude".
> Je ne sais plus quel scientifique démontrait que les logiciels sans bugs sont une utopie.
Je n'ai pas voulu dire que faire un driver sans bug était réaliste (quoique pour seulement un driver ça doit être possible), mais que faire un noyau Linux sans bug est aussi irréaliste que faire un micro-noyau sans bug. Ou que les deux peuvent être aussi fiable.
> > Avec toi oui. Mais ce n'est pas le cas avec patrick_g. Relis moi.
> J'ai parlé spécifiquement de patrick_g pour les ad hominem? Relis moi.
Autant pour moi. Mais ce n'était pas claire surtout avec ces deux trucs qui se suivent :
- "Bref la désolé, mais les attaques ad hominem NAZE ..."
- "Même chose à propos de ton opinion sur patrick_g."
> Arrête de prendre tes désirs pour tes réalité. Je t'ai attaqué d'ad hominem quant tu as dis "ce journal et les commentaires de ce journal sont minables". Rien de spécifique à patrick_g,
M'accuser de faire des attaques ad hominem à plein de gens ici et pas uniquement à patrick_g doit me réjouir ?
Ça ne marche pas alors.
> quant tu as dis "ce journal et les commentaires de ce journal sont minables"
Ce n'est pas une attaque ad hominem.
> Et insultes maintenant.
Oui. Il m'arrive d'insulter. Mais accuser, sans preuve, quelqu'un de faire des attaques ad hominem (et en plus à pleins de personnes qui font des commentaires dans ce journal) est bien une insulte (et une "belle"). Et c'est bien toi qui a commencé à m'insulter (relis le thread ; ou je dois encore prouver à toi et aux autres que ton affirmation est fausse ?). Certes, ça ne pardonne mes insultes envers toi, ça les explique seulement.
J'ai mis ailleurs les insultes que tu m'as envoyé *avant* que je t'insulte.
> "comportement inutilement aggresif sans argumentation concrète".
Quel est l'argument de patrick_g pour traiter l'article de la journaliste de poisson d'avril ?
Un préjugé. C'est argumenté pour toi ?
On peut dire que c'est argumenté, mais l'argument est naze. Dois-je t'expliquer pourquoi l'argument est naze ? Simplement car l'argument sent fort la discrimination. J'espérais n'avoir pas à sortir le mot tant c'est évident. En gros la discrimantion est porter sur quelqu'un un jugement non basé sur ses mérites mais sur son appartenance à un groupe (noir, gros, vagement lié à la MPAA, etc).
Oui, ça m'arrive aussi, je suis parfois minable. Personne n'est parfait.
Il tire un jugement sur la journaliste avec un préjugé et conclus que son article est un poisson d'avril. Clairement une attaque ad hominem (pour caser un terme que t'aime bien).
> c'est un comportement relativement aggressif.
Oui, j'ai été aggressif.
> L'argumentaion, avec les bonnes citation itou, on l'a eu seulement APRES que j'ai écris mes commentaires.
Tu réponds à ce commenatire de ma part : http://linuxfr.org/comments/1019171,1.html
Entre autre :
La journaliste a fait un boulot correct. Elle a utilisé le conditionnel, elle indique les sources, donne que l'avis du rapport et pas le sien, y va avec des pincettes, etc. Elle a fait le boulot qu'on attend d'un journaliste et ce boulot ce n'est pas [de] censurer ce qui ne plait pas.
> ça veut aussi dire que je préfère peut etre indiqué le nom de l'attaque que repartir dans les invectives
La première fois que tu réponds à un de mes commentaires :
- "Clair que traiter les autres, qu'on refuse de comprendre, de minable, fait preuve d'une grande ouverture d'esprit et t'élève tellement au dessus des autres."
- "Bref la désolé, mais les attaques ad hominem NAZE (même pas un minimum recherché),"
- "Même chose à propos de ton opinion sur patrick_g" [que je n'avais pas donné...]
Notons que tu n'as jamais dit où j'ai fait une attaque ad hominem. T'as fait une affirmation gratuite grave sans rien prouver. Je suis OK que tu me traites de connard (=! ad hominem) même si évidemment ça ne m'enchante pas ; on ne peut pas plaire à tout le monde. Je suis furieux qu'on me prête des attaques ad hominem que je n'ai pas faite et d'autant plus envers une personne que je respecte.
Même si je respecte patrick_g, ça ne m'empêche pas de penser que son journal est naze. Mais surtout, traiter un travail de journaliste, manifestement honnète, de poison d'avril, seulement sur un préjugé (que reconnait patrick_g ; merci pour l'honnèteté), est minable.
Quand patrick_g le fait je trouve ça minable, quand d'autres ici le font je trouve ça minable aussi. Donc rien de personnel avec patrick_g dans cette appréciation.
Sûr que j'ai fait déjà la même connerie que patrick_p (typiquement envers MS). Il n'empêche que ce qui doit être dit ... doit être dit :-)
J'admet sans problème que je suis aggressif et parfois insultant.
Par contre, même si je suis aggressif voire insultant envers patick_g, c'est quelqu'un que j'apprécie beaucoup (du moins ce qu'il écrit ici, je ne le connait pas vraiment) et même que je respecte puisque je lis avec attention ce qu'il écrit. Je respecte mais ne verse pas dans l'idôlatrie. Je suis convaincu que j'ai plus de respect pour patrick_g qu'il en a pour moi. N'est pas patrick_g qui veut et le respect (qui va au-dela de la politesse) se gagne. Il l'a gagné.
Quand je pense qu'une connerie est dite, je ne me prive de le souligner.
> - Langage cru: Tu penses ca, donc tu es con
Je sais que ça ne m'est pas spécifiquement adressé, mais je précise que je n'ai pas fait ça. J'ai seulement parlé d'une "crise de connerie" car je voulais être provoquant. A aucun moment je n'ai traité patrick_g de con ou autre. Les crises sont temporaires.
> > 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".
Où tu veux en venir ?
Tu cherches à faire un troll de compétition ?
> Quand je dis que c'est pertinent, c'est du point de vue utilisateur.
Et ?
Un windows manager potable pour Windows c'est pertinent et aussi du point de vu de l'utilisateur.
> C'est pertinent pour la qualité du logiciel
Je ne vois pas pourquoi.
> indépendamment de toute question de moyen.
Chez MS ce type de raisonnement est accèptable, mais chez Linux on est obligé de prendre en compte les moyens. Juste comme petit exemple, connais-tu le plus gros contributeur à Xorg ?
C'est Red Hat... Ce n'est pas une distribution dont la vie dépend du desktop, ce n'est pas un fabriquant de hardware ou un éditeur de jeux vendu ($$) en millions d'exemplaires, c'est une boite dont récemment le PDG a dit ne pas savoir faire de l'argent avec le desktop. C'est dire comme les moyens sont ridicules et comme il est difficile d'avoir des développeurs.
Combien fait de pognon MS avec le desktop ? Des milliards, il est normal que MS y mettent des moyen délirant comparé à GNU/Linux, mais logique vu les enjeux financier.
> Mais ca fait trop mal au cul d'admettre que le kernel commence à avoir une architecture un peu vieillotte
De quoi tu parles ? De micro-noyau ?
Ça existe depuis des plombes les micro-noyau. Ça a quoi de moderne ?
Puis Windows n'a pas un micro-noyau, mais un truc bâtard.
> De plus je croyais que le principal intérêt d'avoir un développement centralisé et monopolistique des drivers avaient pour principal objectif de faciliter les évolutions
Oui. Mais où tu veux en venir ?
Parce que c'est exatement ce qu'on voit dans Linux. Actuellement la configuration passe de Xorg au noyau. Tout ce qui est dépendant de l'hardware va être dans le noyau et plus dans Xorg (qui n'aura plus de drivers ; ni d'ailleurs de fichier de configuration ; ni besoin de privilège particulier et pourra s'excuter sans droit root). Il y a aussi du boulot côté gestion mémoire de la carte graphique avec GEM, mais je n'y comprend pas grand chose :-)
Donc oui, ça facilite l'évolution. Mais ce n'est pas le "développement centralisé" (et surtout pas monopolistique) qui fait la différence, mais car c'est du logiciel libre. On peut casser l'API, on a les sources des drivers s'il faut les mettre à jour. D'où Red Hat qui pousse le drivers Nouveau et vire l'obscurci NV.
> ah bah non tiens, finalement ca marche pas
Oui ça marche.
> question de moyen tu comprends
Plus t'as de moyen, mieux ça marche.
Ne crois pas que les méthodes qui marchent chez MS peuvent marcher dans le libre (je ne crois pas l'inverse non plus).
Fais des plans sur la comète et dit que Xorg sera inutilisable durant 1 ans, c'est un excellent moyen pour faire fuire les contributeurs. Fais des plans monstreux avec du UML, les plannings, des tests unitaires, etc et tu fais fuire les contributeurs. Force un projet, et du fait fuire Intel. Etc.
MS n'a pas ce "problème" (qui n'en est pas vraiment un) car MS a d'énorme moyen. MS peut avoir un dictateur qui fixe ce qui doit être développé et peut payé des gens en masse pour tous les trucs rébarbatifs. Pour tenir les délais, MS peut embaucher par centaines (ou payer des boites externes).
Etc.
Etc.
Tous ça ne marche pas dans le libre. Le libre a une autre méthode, elle n'est pas plus mal.
> Les propos de Linus ne font pourtant nullement référence à un problème de moyen
Bullshit.
Les micro-noyaux sont bien plus difficiles à écrire et à maintenir
[...]
j'ai vu les gens échouer avec leurs micro-noyaux encore et encore - Il est devenu évident pour moi que l'argument de la simplicité était faux.
Ce qui est compliqué demande beaucoup de boulot.
> il affirme juste gratuitement que ces barrières de protection ca n'a aucun intérêt, que ca n'apporte rien au niveau qualité (stabilité, fiabilité, sécurité, etc.). Et les ouailles disent amen ou cherchent à justifier ces propos avec d'autres arguments.
Et toi tu affirmes l'inverse gratuitement. Balle au centre. M'enfin, je tendance à croire Linus.
Et il y a des faits :
- Il n'y a pas de micro-noyau en production ! Il n'y a que des trucs qui marchouillent et/ou sont très loins de rivaliser avec Linux. Pourtant ça fait depuis des années (et bientôt des dizaines d'années) que des micro-noyau sont en développement.
- Windows n'a pas un micro-noyau. C'est autant un micro-noyau que MacOS est un micro-noyau.
Si tu penses que faire un micro-noyau est facile, pourquoi il n'y en a pas ? On ne trouve que des trucs pour des niches ou qui marchouille si on veut en faire un OS généraliste.
> Même les catholiques (et pourtant je suis loin de les trouver malins) sont plus critiques envers le pape quand il parle de protection inutiles :)
Linus parle de ce qu'il connait. Le pape n'a jamais baisé (avec ou sans capote).
Linus parle de techniques qu'il faut appliquer. Le pape délivre d'un message (qui n'est pas le sien) d'idéal.
C'est pertinent pour MS qui a des tonnes de pognon. Ce n'est pas pertinent pour Linux.
Je peux aussi dire que les windows manager à la Linux sont pertinent pour Windows ou qu'un vrai (pas cette merde de powershell) shell c'est pertinent pour Windows. Sauf que la culture, les moyens, etc ne sont pas Linux et donc ça ne marchera pas.
S'il te plait, vu le succès de Firefox, dis que la GPL est pertinent pour IE.
> Mon dieu MS n'arrive pas à gérer la qualité de ce que fait NVidia ATI ou Intel !
Tu disais que Vista arrivait à se démerder avec des drivers pas terrible. Ce n'est pas le cas ?
Faut croire que non.
> Heuresement, le kernel Linux, lui il sait gérer ça.
Ce n'est pas ce que j'ai dit.
> C'est pour cela qu'on a pas besoin de barrière, les drivers graphiques sous linux qui plantent, ca n'existe pas, car Linux sait gérer la qualité.
Ce n'est pas ce que j'ai dit, je n'ai pas caché qu'il y avait des problèmes avec Linux.
Mais pour toi, avec Windows et ses barrières magiques il n'y a pas de problème.
Avec Vista on ne doit avoir un plantage à cause d'un driver, on ne doit pas avoir ça : http://www.youtube.com/watch?v=zFx62_Iadjg
Ooops.
Si 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.
Si on a des moyens infinis, autant faire des barrières, des tests exhautif de regression systématique, etc.
Ce n'est pas le cas de Linux.
Windows avec ses mignonnes barrières et ses moyens délirants ne plante pas moins qu'un Linux.
Tu m'expliques ça ?
En tout cas Linus donne une très bonne explication (c'est le commentaire un peu plus haut si tu l'as raté).
Ce n'est pas car Linux n'a pas des mignonnes barrières que Linux est fragile au moindre problème matériel ou de driver. On est nombreux a avoir eu un problème de driver ou hard sans que ça plante tout le reste. On est nombreux à faire tourner Xorg des semaines de suite sans problème. Un driver merde, on le corrige. On ne met pas 20 ingénieurs à plancher durant 2 ans pour faire un truc qui atténu le problème. Linux préfère corriger directement le problème.
> > Je ne crois pas que le driver soit déchargé et rechargé à la volé.
> Si.
Ça m'étonnerais grave mais admettons.
> Ce qui était également le cas de XP.
C'est toujours le cas avec Vista. Un driver graphique mal écrit peu faire planter Vista.
> mais la capacité au projet dans son ensemble à croire qu'il est possible de maintenir un aussi grand nombre de drivers de qualité, sans avoir besoin de mettre de barrière.
En quoi ajouter des barrières va aider à maintenir plus de driver. Je ne vois pas ou tu veux en venir.
C'est même le contraire. Avec les barrières il y a plus de complexité et il faut plus de moyen pour maintenir l'ensemble.
> Désolé, c'est le problème de Linux. C'est lui qui fourni l'infrastructure pour les drivers, et c'est de sa faute si un driver a un impact aussi important qu'un crash d'une application voir le plantage total du kernel.
Je suis d'accord avec ça, mais le problème de Linux n'est pas l'absence de barrière (Vista avec des barrières plante aussi), mais principalement le manque de moyen (peu de soutient des fabriquants de hardware) et qu'actuellement la partie graphique de Linux est en plein bouleversement.
Je dois insister sur les faibles moyens de Linux. Compte tenu des failbles moyens et qu'il y a des priorités très élevées (virer nv pour utiliser Nouveau, finaliser KMS, virer les vieilleries dans Xorg, etc), ajouter des barrières n'apporte pratiquement rien et ne va pas résoudre ces problèmes. Si le driver Nouveau ne gère pas la carte bidule, ajouter des barrières ne va pas ajouter le support de la carte bidule et donner un support nickel 3D pour les cartes NVidia.
Même si la situation était bonne chez Linux, je ne suis pas convaincu que d'ajouter des barrières serait un plus significatif. Ça complexifie beaucoup, etc.
> Y'a des solutions pour limiter l'impact de ces problèmes
Quand un driver ne marche pas, il ne marche pas. Ajouter des barrières n'y changera rien. Je suis sûr qu'on va assiter à une amélioration énorme de la qualité globale de Linux sur la partie graphique dans les quelques mois à venir (au moins pour Intel et ATI). Et ça sera sans barrière.
> les micro-noyaux sont une partie de cette solution, il paraît donc un brin prétentieux de la part de Linus de dire que ces solutions n'apportent rien au niveau qualité. La stabilité est une qualité.
T'es bien prétentieux de contredire Linus.
> Je penses pas que ce soit une question de moyen.
Dit le à MS. MS sera content de savoir qu'il a des économies à faire.
Dit le à Hurd qui après des années et des années n'arrive toujours pas à décoller.
Dit le à Minix qui cherche ici des développeurs.
Etc.
Mouaif. Ou ça a été fait car MS n'arrivait pas à gérer la qualité et donc a un conçu un truc pour gérer un truc merdique (c'est une supposition).
> un petit tressautement visuel et je peux continuer de jouer avec mon jeu préféré sans interruption.
Je ne connais pas l'architecture de Windows, mais il est possible qu'il ne sache réinitialiser qu'une partie du driver graphique. D'autres parties ne devant pas planter. Je ne crois pas que le driver soit déchargé et rechargé à la volé.
De plus il semble avoir lu que beaucoup des problèmes avec vista sont liés aux drivers graphiques. Donc le système qui supporte les plantages graphiques et les sépare du reste du système n'est manifestement pas au point.
> Va aussi falloir qu'il se fasse une raison Linux, le noyau Linux et le nombre de drivers qu'il y a dedans devient plus que conséquent
???
Les drivers/modules sont chargés que s'il y a le matos qui correspond.
> la complexité de ces drivers est croissante (ex : les drivers graphiques)
Pour Linux, ce n'est pas le problème du moins pour la qualité (ou plantage).
Le problème actuellement est :
- faible support des constructeurs (mais ça s'améliore).
- architecture qui a beaucoup changé sans être encore finalisée (KMS, Gem, Xorg, etc).
- les moyens de Linux pour tout ce qui est desktop est sans commune mesure avec MS.
Avec les faibles moyens qu'a Linux, je pense que ça serait une erreur de faire une usine à gaz qui gère les plantages des drivers.
J'ai lu "Chuck Norris", pas ses écrits son nom seulement, des milliers de fois.
J'ai vu des tonnes de photos de Chuck Norris.
Mais je n'ai pas vu le moindre film de Chuck Norris.
Le titre de l'article est "La contrefaçon de DVD financerait le terrorisme". C'est du conditionnel.
Le titre de l'étude est "Film Piracy, Organized Crime, and Terrorism". Je ne crois pas que ça soit mieux. "Film Piracy" c'est aussi le p2p sur internet.
> La contrefaçon est un financement des mafias et autres et ça ne fait pas de doute, vu que c'est illégal, la contrefaçon ne peux à priori rien financer de légal mais pour conclure ça pas besoin de faire un titre/article à la mort moi le noeud.
La contrefaçon en général n'était pas l'objet principal de l'étude. Preface
This report presents the findings of research into the involvement of
organized crime and terrorist groups in counterfeiting a wide range
of products, from watches to automobile parts, from pharmaceuticals
to computer software. It presents detailed case studies from around
the globe in one area of counterfeiting, film piracy, to illustrate the
broader problem of criminal...
[...]
Introduction: Defining the Issues
This report investigates the extent to which criminal and terrorist
groups are engaging in counterfeiting, using film piracy as an example.
[...]
Chapter Three turns to counterfeiting, using film piracy as an example
of the low risks and high rewards that make this criminal activity so
attractive.
[...]
Motivation for entry into piracy. What was the type of connec-
tion between organized crime and film piracy, and between ter-
rorism and film piracy?
Peut-être que la contrefaçon de Rolex est plus lucratif. Mais ce n'est pas l'objet du rapport.
> J'avais lu un papier où ils ont téléchargé une image ISO avec wget en tuant le pilote réseau toutes les 10 secondes. Bah ça fonctionne : l'ISO est chargée sans erreur !
Bof.
C'est quoi "tuer le pilote" ?
Tu peux plus ou moins faire ça avec Linux, par exemple en branchant et débranchant une carte réseau USB. Wget fera le nécéssaire pour relancer une connexion (ce qu'il a très probablement fait avec Minix 3).
Les drivers ont toujours une tolérance aux erreurs.
> Bien sûr, y'a la solution d'écrire des pilotes sans bug, hum hum.
Pourquoi pas. Ce n'est pas plus irréaliste que de faire un micronoyau hypra souple et capable de gérer toutes les erreurs (voire de faire de l'auto-guérison comme le dit la dépêche). Le principe de Minix 3 supose qu'il y a une partie (assez grosse) sans bug.
C'est pareil avec GNU/Linux, sauf que la partie sans bug est plus grosse. Mais comme c'est moins compliqué, il n'est pas dit que l'un soit intrasèquement moins fiable que autre.
Pour une solution complète, c'est la fiabilité de l'ensemble qui compte. Minix 3 peut ne pas avoir d'erreur, mais si le driver réseau plante toutes les millisecondes c'est sans intérêt. Si la libc déconne, c'est sans intérêt. S'il y a un bug dans wget, c'est sans intérêt.
C'est louable de faire un noyau hyper fiable. Mais il ne faut pas compter sur ça pour corriger ou compenser les erreurs qui sont ailleurs.
Avec toi oui. Mais ce n'est pas le cas avec patrick_g. Relis moi.
> Bon je vais t'aider aucun argument, et attaque personelle de l'interlocuteur,
Faux.
> Cas d'école, et qui montre bien ta grande méconnaissance dans les termes de la réthoriques
Pour la réthorique, t'es plus fort que moi.
Tu m'as accuser d'attaques ad hominem sur patrick_g sans la moindre preuve.
Alors arrête avec ta morale et ta réthorique.
> "Les chercheur ont trouvé que"... ça c'est une belle source.
Lis l'article bouffon.
Les chercheurs de la très respectée Rand Corporation [http://www.rand.org/], à Santa Monica (Californie), ont interrogé 120 agences de maintien de l'ordre, dans plus de vingt pays, pour analyser le "marché" du piratage de films. "Il existe des preuves substantielles d'un lien important et continu entre le piratage de films et le crime organisé", conclut leur rapport, "Film Piracy, Organized Crime and Terrorism", commandé par les studios d'Hollywood, et publié début mars
C'est parfaitement sourcé. On a l'auteur, le titre du document, le lieu et la date. Il faut être un débile profond pour ne pas trouver le document en moins de 2 minutes.
> bon petit apprentissage à l'usage de isnotgood : "comment on source".
C'est sourcé. Vous faites un caca nerveux car il n'y a pas un lien direct sur l'étude. Rien d'autre. C'est minable.
Oui, Microsoft aussi prouve que Linux (même quand il est gratuit) a un TCO plus élevé que Windows.
Donne des chiffres, va sur le site de Sun, commande une bécane avec Solaris + Virtualisation + clusturing et donne le prix de la partie logiciel/support. Ajoute aussi du support pour le serveur web, Mysql, PostgreSQL, etc (puisque RHEL le fait). Fais de même avec RHEL et t'en conclus que RHEL est NETTEMENT moins cher. Fin du débat, pas besoin d'une étude de 3 mois pour savoir ça.
Juste pour cluster : http://catalog.sun.com/is-bin/INTERSHOP.enfinity/WFS/Sun_Cat(...)
CLNIS-320-A929 Frais à acquitter pour la licence serveur Sun Cluster 3.2 pour Netra 210, (une licence par serveur), facture uniquement € 2,000.00
Jusqu'où ça peut monter ?
Roulement de tambour :
CLAI9-LCA-1199 Frais de licence Sun Cluster Advanced Edition pour Oracle RAC, Niveau 11, comprend des licences d’utilisation pour Sun Cluster RAC Agent, Shared QFS Metadata Server and Client, Sun Cluster Agent for QFS Metadata Server, Sun Cluster-Oban, Sun Cluster-QFS-Oban, prend en charge Solaris SPARC/x86, (facturation au nœud) € 151,200.00
WS72I-LCO-9929 Licence Sun Java System Web Server 7.0 Enterprise Edition, Solaris/x86, (par socket) € 1,350.00
Fichtre !
Tout est dans ce style. Avec le Solaris de base, tu as trois fois rien, il faut acheter plein de truc après.
Tu vas maintenant expliquer que Sun vend des trucs qui ne servent à rien ?
Alors ta comparaison biaisée de Sun pour Sun, je m'en torche le cul.
[^] # Re: L'avis de Linus
Posté par IsNotGood . En réponse à la dépêche MINIX 3 - Google Summer of Code. Évalué à 3.
Linus dit ça des micro-noyau alors qu'il parle de l'architecture d'un noyau.
Et comme Windows n'est pas un micro-noyau, Microsoft ne lui donne tord. Microsoft a écrit de 0 Windows NT et n'a pas choisi de faire un vrai micro-noyau car Microsoft pense grosso-modo la même chose que Linus.
> reconnaître que le chemin pris par MS va dans le sens des micro-noyaux
Mouaif. Ben ça ne va pas vite en plus de 15 ans (?) d'existance de Windows NT.
> c'est les arguments totalement bancales de Linus.
Pourquoi ils son bancales ?
Ils sont confirmés par la réalité. En 1990 si tu disais qu'ils étaient bancales, je n'aurais rien dit. Mais aujourd'hui... Faut arrêter le délire.
Certes Linus le dit brutalement, on peut penser qu'il exagère, etc. Mais l'histoire lui a donné raison. Tu peux ajouter "jusqu'à maintenant".
> Non, Linux a eu du succès parcqu'il est vite devenu opérationnel et qu'il a su fédérer les développeurs. Il a maintenant une base très importante de drivers ce qui fait son succès.
Donc il a eu raison. Fin.
> C'est pas pour autant que le choix d'architecture fait y'a 15 ans est toujours aussi pertinent.
Non, presque rien n'a changé !
Je peux aussi dire que faire un noyau en Java ou C# est un avantage et blablabla.
Honte à Microsoft, Microsoft ne veut pas faire son noyau en C# alors que c'est irréfutablement un avantage !
Sur le papier c'est un avantage. Dans la réalité non. Idem pour les micro-noyau.
> Si les autres noyaux n'ont pas de succès, c'est pas pour des problèmes d'architecture, c'est pour des problèmes de moyens
Les micro-noyau ont eu des moyens et même beaucoup plus que Linux à l'époque des débuts de Linux. MS avec WinNT, Apple/Nextstep, Digital. Mais, ils n'ont pas fait de vrai de micro-noyau...
Pourtant à l'époque le concèpte de micro-noyau était plus séduisant qu'aujourd'hui : les micro-noyau était l'avenir et les noyaux monolithique était destiner à disparaitre.
Aujourd'hui les choses sont encore moins en faveur pour les micro-noyau alors j'ai bien du mal à croire qu'aujourd'hui il est plus pertinent de faire un micro-noyau qu'il y a 15 ans.
> un noyau sans drivers n'aura pas d'utilisateurs, c'est un cercle vicieux.
Le problème des micro-noyau n'est pas que là. L'histoire l'a montré.
> j'ai environ un crash graphique toutes les 2h de jeu
Sous Linux on corrige le driver, on ne met pas en place une infrastructure pour récupérer le driver.
Je ne vois absolument pas en quoi l'une des deux démarches est supérieure à l'autre.
> Hop je le vois mais ca me gène pas.
Hop je ne vois pas de problème sous Linux, ça ne me gène pas.
> Ca c'est la vraie vie
Ça c'est la vraie vie
> un constat clair : cette fonctionnalité de Vista est un confort indéniable.
Quand on a un driver pourri. Oui. Mais Linux ne veut pas de driver pourri pour les cartes graphiques comme Windows ne veut, ni ne peut tolérer, de driver pourri pour les disques, pour le réseau, pour le son, pour le gestionnaire de mémoire, pour l'ordonnanceur, etc.
> Linus s'obstine à dire que ca sert à rien quand des gens s'en servent dans la vraie vie.
Si tu décides qu'il ne faut pas corriger le driver, ça sert à quelque chose. Si tu décides corriger le driver ça ne sert à rien. Le logiciel libre a les sources, le logiciel libre corrige les bugs.
> Qui est éloigné de la réalité ?
Tu ne veux entendre que la réalité de Windows.
Écoute la réalité de Linux.
Je n'ai pas dit que Windows avait tord, mais que ça ne me semble pas bon pour Linux dont le contexte de développement, ses méthodes, etc n'ont pratiquement rien à voir avec Windows qui a le culte du binaire et des API figées. Si l'API Linux sucks, on l'a change et on met à jour tous les drivers (on a les sources). Si l'API Windows sucks ? Ben on prie que le système de récupération fasse son job.
Essaie de comprendre la réalité de Linux qui n'est pas celle de Windows. Peut-être que tu penseras toujours que Linux a tord, mais tu dois au moins reconnaitre que Linux a moins de raison de faire des barrières pour les drivers graphiques que Windows.
> Oui je dis qu'il est prétentieux, et j'essai d'argumenter. Toi tu me dis que je peux pas, par respect pour je-sais-pas-quoi.
Tu as dit : "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. "
Que tu le traites de prétentieux me fait seulement rire.
Que tu remettes en cause la position de leader de Linus (comme s'il avait été parachuté "chef"), ça ne me fait pas rire.
Que tu traites les développeurs linux d'idôlatrer Linus (ils suiveraient aveuglement Linus), ça ne me fait pas rire.
Linus peut être viré à tout moment. Il est le leader de Linux car il le mérite et qu'il n'y a pas meilleur que lui pour ce job actuellement. Il n'est pas le chef car une autorité supérieur lui en a donnée mandat, mais car les développeurs le veulent (jusqu'à maintenant).
> Le pape déconne, il est toujours là.
T'es con ou tu le fais exprès ?
Le pape est nommé à vie. Linus non.
[^] # Re: L'avis de Linus
Posté par IsNotGood . En réponse à la dépêche MINIX 3 - Google Summer of Code. Évalué à 1.
OK, désolé.
> je pars de la réalité, de la vraie vie, d'exemples concrêts : mon expérience avec les crash graphiques, d'autres que moi ici semble vivre le même genre de problème
Et ?
En passant, je n'ai pas dit que MS avait tord de le faire (faut dire que Windows n'est pas une de mes préoccupations). Je dis qu'une autre voix est possible, que les micro-noyau ne sont pas forcément supérieur dans la pratique.
Donnes à Linux les moyens de MS, le même support des constructeurs, et je serais HYPER supris qu'il y ait plus de plantage du système à cause des drivers graphiques sous Linux que sous Windows.
Les plantages du système à cause du drivers graphique existe sous Windows et sous Linux. Ils ont rares (j'en ai jamais eu sur mes systèmes Linux ; je veux bien croire que j'ai eu de la chance). Je ne crois pas que si Linux avait les même moyens que Windows, ou même seulement un quart des moyens de Windows, Linux aurait plus de plantage système à cause du driver graphique que Windows.
> je t'ai pointé un doc de stats de MS sur le nombre de plantage récupérés, c'est autant de faits qui montre que ces barrières ont un intérêt
Les barrières ne sont pas un truc qui s'ajoute, comme par exemple on ajoute SeLinux à Linux. Elles demandes un grosse réorganisation du noyau, de nouvelles contraintes, etc. C'est l'ensemble qu'il faut juger. Et si on juge l'ensemble (noyau Windows et noyau Linux), les barrières n'ont pas montré un intérêt. Peut-être un intérêt pour le noyau Windows, son organisation, son mode de développement. Pas pour Linux.
T'as pointé une truc qui montre qu'il y a des plantages des drivers graphiques sur Vista. T'as pointé un truc qui montre qu'il y a beaucoup de plantage des drivers graphiques sous Vista. Tu confirmes qu'il y a beaucoup de plantage des drivers graphiques sous Vista. D'autres utilisateurs le confirme. Je le confirme aussi, le drivers graphique Intel (i945) sous Vista plante et ça m'arrivait toutes les semaines. Certes, dans mon cas tous ces plantages ont été récupérés (sauf que parfois je n'avais plus l'interface aero...).
Il y a beaucoup de plantage graphique et 7 % (si j'ai bonne mémoire) de ces nombreux plantages graphiques, aboutisse à un plantage système !
Bref, ce n'est pas la preuve que l'architecture de Vista donne une meilleur fialibité, mais seulement que beaucoup de ses très nombreux plantages graphiques sont récupérés.
Linux ne veut pas récupérer la majorité des plantages du drivers graphiques, Linux veux des drivers graphiques de qualité. Je ne crois pas qu'il sera difficule pour Linux d'avoir 20 fois moins de plantage du drivers graphique que Vista. Et même si chaque plantage graphique aboutit à un plantage système pour Linux, ça fera moins de plantage système que Vista à cause du driver graphique.
> Mais visiblement il a un problème d'égo.
Et toi ?
Ton raisonnement est pourri.
Je vais l'appliquer pour les transports :
- Les airbags des voitures sauvent 30 % de vie
- Les avions n'ont pas d'airbags
- Donc se déplacer en avion est plus dangereux que se déplacer en voiture
C'est ça ton raison. De la merde.
[^] # Re: L'avis de Linus
Posté par IsNotGood . En réponse à la dépêche MINIX 3 - Google Summer of Code. Évalué à 4.
Aujourd'hui c'est claire que non.
Mais en 1990 l'écart n'était pas celui d'aujourd'hui. En tout cas, si les micro-noyau étaient aussi prometteurs qu'on le dit, le manque de moyen aurait dû être compensé par la supériorité (prétendue) de l'architecture micro-noyau. Mais ce n'est pas que qu'on a vu.
Notons aussi que Hurd n'a pas créé de micro-noyau, il en a pris des déjà existant. A l'époque Linux a pratiquement tout fait.
> Derrière linux il y a quand même un investissement croissant d'un certain nombre de boites dont certaines ne sont pas des plus petites (au hasard IBM).
MS, Apple (et nextstep), Digital Equipement, pour en citer quelques uns, sont aller sur la voie micro-noyau. Donc les moyens ne manquaient pas et les micro-noyau ont eu leur chance. Au final ils ont fait des trucs "bâtards". En face le petit linux et avec des moyens bien moindre c'est fait une place au soleil.
Pourquoi ils ne sont pas allé au bout de la démarche micro-noyau ? Peut-être car ils ont rapidement constaté que c'était aller droit dans le mur en klaxonnant. Hurd a fait la tête de mule.
[^] # Re: Plantage
Posté par IsNotGood . En réponse à la dépêche MINIX 3 - Google Summer of Code. Évalué à 3.
Le ctrl-alt-del pour se logguer c'est très limité.
Un programme ne peut détecter ctrl-alt-del (il n'y a que le noyau sous win qui peut le faire), mais il suffit de faire une mire de login qui ne détecte que des touches ctrl et alt. Je suis sûr que ça marchera au moins 19 fois sur 20.
[^] # Re: Velu du vendredi ?
Posté par IsNotGood . En réponse à la dépêche MINIX 3 - Google Summer of Code. Évalué à 2.
Sûr, il y a QNX. Je n'ai pas dit que les micro-noyau sont obligatoirement mauvais, mais qu'ils n'ont rien démontré lorsqu'il sagit d'un OS généraliste (desktop et serveur). S'ils ont démontré quelque chose, c'est la quasi inadaption des micro-noyau pour faire un OS généraliste.
> mais il a aussi rejeté des arguments pour le micro-noyau sans réelles justifications (stabilité, sécurité).
Il l'a justifié, le problème est la complexité.
> Le micro-noyau apporte plus de sécurité et de stabilité 'by-design'.
Ce n'est pas le design de haut-niveau qui compte, c'est la réalité.
Un petit exemple :
http://fr.wikipedia.org/wiki/Noyau_de_système_d'exploitation
D’un point de vue théorique, le grand nombre de lignes de code exécutées en mode noyau engendre des problèmes de portabilité. La pratique contredit largement la théorie et les noyaux modulaires sont aujourd’hui les plus portés.
> Il n'y a qu'à compter le nombre d'exploits noyau pour Linux,
Mauvais argument. Compile un Linux pour l'embarquer (en virant le maximum de chose) et il n'y a qu'un très petit nombre de bug de Linux qui t'affecte. Les bugs qui t'affectent peuvent être plus probablement trouvé et plus vite si tu utilises un système très diffusé/audité.
> suivent une courbe exponentielle
Exponentielle par rapport à quoi ?
> Mais plus la complexité du système augmente plus ceci devient coûteux alors que l'isolation dans des systèmes étanches permet de limiter le périmètre impacté par les bugs.
L'argument se tient. Mais faire "des systèmes étanches" est compliqué, pas simple. Et dans quelle mesure sont-ils étanches ? Un serveur web, même dans un micro-noyau, n'est pas isolé du reste. Il doit récupérer des fichiers (donc intération avec le FS, le pilote des disques), accéder au réseau (intéraction avec la pile TCP/IP), etc.
Linus répond à ton argument, ça commence par "Tout l'argument disant que les micro-noyaux sont "plus sécurisés" ou "plus stables" est aussi totalement grotesque".
Le "grotesque" est un peu fort, mais on sait comment s'exprime Linus.
Ici chaque solution a ses avantages et inconvéniants pour la stabilité et sécurité.
Notons que Linus est dans l'objectif de faire un OS généraliste. Pas un OS qui sacrifie tout pour conserver la pureté du design.
Chercher les performances à un coût :
http://fr.wikipedia.org/wiki/Noyau_de_système_d'exploitation#Syst.C3.A8mes_.C3.A0_micro-noyaux (on y trouvera aussi des conneries :-))
Le grand nombre d’appels système et la communication sous-jacente sont un défaut inhérent à la conception des micro-noyaux. Dans L4, il a été résolu en plaçant encore plus de services en espace utilisateur. La rapidité de traitement des IPC a pu être améliorée en simplifiant les communications au maximum, par exemple en supprimant toute vérification des permissions, laissant ce soin aux serveurs externes.
Es-ce le cas de QNX ?
Si oui, l'avantage sécurité est très discutable pour ne pas dire qu'il disparait.
[^] # Re: Plantage
Posté par IsNotGood . En réponse à la dépêche MINIX 3 - Google Summer of Code. Évalué à 6.
La longueur du code compte mais ne me semble pas le facteur le plus important.
Ajouter des drivers à Linux augmente le nombre de bug dans les sources du noyau, chaque driver pouvant apporter son lot de bug. Mais tous les drivers de Linux ne sont pas utilisés en même temps, donc ajouter un driver ou un système de fichier ne diminue pas la fiabilité de Linux.
Par contre la complexité est vraiment un paramètre important sur la qualité.
On peut faire un programme fleuve (par exemple les programmes avec interface graphique riche) sans beaucoup de bug mais surtout assez facile à trouver. Dans le cas de programme comme un noyau, avec des optimisations un peu partout, avec du multi-thread, etc ça peut tourner au cauchemar.
J'avais vu un blog "marrant". Un développeur esprimait sa joie d'avoir enfin supprimé un bug de Linux après 4 mois d'effort à le chercher !
Une fois j'ai passé 2 semaines à seulement chercher un bug (plantage aléatoire en moyenne toutes les 4 heures) dans un de mes programmes. C'est vraiment creuvant à faire et on passe par des "grands moments de solitude".
[^] # Re: Plantage
Posté par IsNotGood . En réponse à la dépêche MINIX 3 - Google Summer of Code. Évalué à 2.
Je n'ai pas voulu dire que faire un driver sans bug était réaliste (quoique pour seulement un driver ça doit être possible), mais que faire un noyau Linux sans bug est aussi irréaliste que faire un micro-noyau sans bug. Ou que les deux peuvent être aussi fiable.
[^] # Re: joli sophisme...
Posté par IsNotGood . En réponse au journal Contrefaçon de DVD et terrorisme. Évalué à 2.
http://www.lemonde.fr/culture/reactions/2009/03/26/la-contre(...)
Qu'il y est des commentaires sur dlfp, n'autorise pas n'importe quoi pour les dépêches. Sinon pourquoi les modérer ?
[^] # Re: joli sophisme...
Posté par IsNotGood . En réponse au journal Contrefaçon de DVD et terrorisme. Évalué à 2.
> J'ai parlé spécifiquement de patrick_g pour les ad hominem? Relis moi.
Autant pour moi. Mais ce n'était pas claire surtout avec ces deux trucs qui se suivent :
- "Bref la désolé, mais les attaques ad hominem NAZE ..."
- "Même chose à propos de ton opinion sur patrick_g."
> Arrête de prendre tes désirs pour tes réalité. Je t'ai attaqué d'ad hominem quant tu as dis "ce journal et les commentaires de ce journal sont minables". Rien de spécifique à patrick_g,
M'accuser de faire des attaques ad hominem à plein de gens ici et pas uniquement à patrick_g doit me réjouir ?
Ça ne marche pas alors.
> quant tu as dis "ce journal et les commentaires de ce journal sont minables"
Ce n'est pas une attaque ad hominem.
> Et insultes maintenant.
Oui. Il m'arrive d'insulter. Mais accuser, sans preuve, quelqu'un de faire des attaques ad hominem (et en plus à pleins de personnes qui font des commentaires dans ce journal) est bien une insulte (et une "belle"). Et c'est bien toi qui a commencé à m'insulter (relis le thread ; ou je dois encore prouver à toi et aux autres que ton affirmation est fausse ?). Certes, ça ne pardonne mes insultes envers toi, ça les explique seulement.
J'ai mis ailleurs les insultes que tu m'as envoyé *avant* que je t'insulte.
[^] # Re: joli sophisme...
Posté par IsNotGood . En réponse au journal Contrefaçon de DVD et terrorisme. Évalué à 2.
Quel est l'argument de patrick_g pour traiter l'article de la journaliste de poisson d'avril ?
Un préjugé. C'est argumenté pour toi ?
On peut dire que c'est argumenté, mais l'argument est naze. Dois-je t'expliquer pourquoi l'argument est naze ? Simplement car l'argument sent fort la discrimination. J'espérais n'avoir pas à sortir le mot tant c'est évident. En gros la discrimantion est porter sur quelqu'un un jugement non basé sur ses mérites mais sur son appartenance à un groupe (noir, gros, vagement lié à la MPAA, etc).
Oui, ça m'arrive aussi, je suis parfois minable. Personne n'est parfait.
Il tire un jugement sur la journaliste avec un préjugé et conclus que son article est un poisson d'avril. Clairement une attaque ad hominem (pour caser un terme que t'aime bien).
> c'est un comportement relativement aggressif.
Oui, j'ai été aggressif.
> L'argumentaion, avec les bonnes citation itou, on l'a eu seulement APRES que j'ai écris mes commentaires.
Tu réponds à ce commenatire de ma part :
http://linuxfr.org/comments/1019171,1.html
Entre autre :
La journaliste a fait un boulot correct. Elle a utilisé le conditionnel, elle indique les sources, donne que l'avis du rapport et pas le sien, y va avec des pincettes, etc. Elle a fait le boulot qu'on attend d'un journaliste et ce boulot ce n'est pas [de] censurer ce qui ne plait pas.
2 bonnes heures avant ton commentaire, j'ai fait ce commentaire :
http://linuxfr.org/comments/1019198,1.html
Et encore avant ce commentaire :
http://linuxfr.org/comments/1019081,1.html
Bref, ton affirmation est (encore et indiscutablement) fausse. C'était argumenté (bien ou mal, c'est un autre débat).
[^] # Re: joli sophisme...
Posté par IsNotGood . En réponse au journal Contrefaçon de DVD et terrorisme. Évalué à 2.
C'était provateur (même si je le pense un peu). Et c'était aussi mal venu, patrick_g a répondu ailleurs. Ooops.
[^] # Re: joli sophisme...
Posté par IsNotGood . En réponse au journal Contrefaçon de DVD et terrorisme. Évalué à 2.
La première fois que tu réponds à un de mes commentaires :
- "Clair que traiter les autres, qu'on refuse de comprendre, de minable, fait preuve d'une grande ouverture d'esprit et t'élève tellement au dessus des autres."
- "Bref la désolé, mais les attaques ad hominem NAZE (même pas un minimum recherché),"
- "Même chose à propos de ton opinion sur patrick_g" [que je n'avais pas donné...]
Notons que tu n'as jamais dit où j'ai fait une attaque ad hominem. T'as fait une affirmation gratuite grave sans rien prouver. Je suis OK que tu me traites de connard (=! ad hominem) même si évidemment ça ne m'enchante pas ; on ne peut pas plaire à tout le monde. Je suis furieux qu'on me prête des attaques ad hominem que je n'ai pas faite et d'autant plus envers une personne que je respecte.
Même si je respecte patrick_g, ça ne m'empêche pas de penser que son journal est naze. Mais surtout, traiter un travail de journaliste, manifestement honnète, de poison d'avril, seulement sur un préjugé (que reconnait patrick_g ; merci pour l'honnèteté), est minable.
Quand patrick_g le fait je trouve ça minable, quand d'autres ici le font je trouve ça minable aussi. Donc rien de personnel avec patrick_g dans cette appréciation.
Sûr que j'ai fait déjà la même connerie que patrick_p (typiquement envers MS). Il n'empêche que ce qui doit être dit ... doit être dit :-)
[^] # Re: joli sophisme...
Posté par IsNotGood . En réponse au journal Contrefaçon de DVD et terrorisme. Évalué à 2.
J'admet sans problème que je suis aggressif et parfois insultant.
Par contre, même si je suis aggressif voire insultant envers patick_g, c'est quelqu'un que j'apprécie beaucoup (du moins ce qu'il écrit ici, je ne le connait pas vraiment) et même que je respecte puisque je lis avec attention ce qu'il écrit. Je respecte mais ne verse pas dans l'idôlatrie. Je suis convaincu que j'ai plus de respect pour patrick_g qu'il en a pour moi. N'est pas patrick_g qui veut et le respect (qui va au-dela de la politesse) se gagne. Il l'a gagné.
Quand je pense qu'une connerie est dite, je ne me prive de le souligner.
> - Langage cru: Tu penses ca, donc tu es con
Je sais que ça ne m'est pas spécifiquement adressé, mais je précise que je n'ai pas fait ça. J'ai seulement parlé d'une "crise de connerie" car je voulais être provoquant. A aucun moment je n'ai traité patrick_g de con ou autre. Les crises sont temporaires.
[^] # 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".
[^] # Re: L'avis de Linus
Posté par IsNotGood . En réponse à la dépêche MINIX 3 - Google Summer of Code. Évalué à 2.
Tu cherches à faire un troll de compétition ?
> Quand je dis que c'est pertinent, c'est du point de vue utilisateur.
Et ?
Un windows manager potable pour Windows c'est pertinent et aussi du point de vu de l'utilisateur.
> C'est pertinent pour la qualité du logiciel
Je ne vois pas pourquoi.
> indépendamment de toute question de moyen.
Chez MS ce type de raisonnement est accèptable, mais chez Linux on est obligé de prendre en compte les moyens. Juste comme petit exemple, connais-tu le plus gros contributeur à Xorg ?
C'est Red Hat... Ce n'est pas une distribution dont la vie dépend du desktop, ce n'est pas un fabriquant de hardware ou un éditeur de jeux vendu ($$) en millions d'exemplaires, c'est une boite dont récemment le PDG a dit ne pas savoir faire de l'argent avec le desktop. C'est dire comme les moyens sont ridicules et comme il est difficile d'avoir des développeurs.
Combien fait de pognon MS avec le desktop ? Des milliards, il est normal que MS y mettent des moyen délirant comparé à GNU/Linux, mais logique vu les enjeux financier.
> Mais ca fait trop mal au cul d'admettre que le kernel commence à avoir une architecture un peu vieillotte
De quoi tu parles ? De micro-noyau ?
Ça existe depuis des plombes les micro-noyau. Ça a quoi de moderne ?
Puis Windows n'a pas un micro-noyau, mais un truc bâtard.
> De plus je croyais que le principal intérêt d'avoir un développement centralisé et monopolistique des drivers avaient pour principal objectif de faciliter les évolutions
Oui. Mais où tu veux en venir ?
Parce que c'est exatement ce qu'on voit dans Linux. Actuellement la configuration passe de Xorg au noyau. Tout ce qui est dépendant de l'hardware va être dans le noyau et plus dans Xorg (qui n'aura plus de drivers ; ni d'ailleurs de fichier de configuration ; ni besoin de privilège particulier et pourra s'excuter sans droit root). Il y a aussi du boulot côté gestion mémoire de la carte graphique avec GEM, mais je n'y comprend pas grand chose :-)
Donc oui, ça facilite l'évolution. Mais ce n'est pas le "développement centralisé" (et surtout pas monopolistique) qui fait la différence, mais car c'est du logiciel libre. On peut casser l'API, on a les sources des drivers s'il faut les mettre à jour. D'où Red Hat qui pousse le drivers Nouveau et vire l'obscurci NV.
> ah bah non tiens, finalement ca marche pas
Oui ça marche.
> question de moyen tu comprends
Plus t'as de moyen, mieux ça marche.
Ne crois pas que les méthodes qui marchent chez MS peuvent marcher dans le libre (je ne crois pas l'inverse non plus).
Fais des plans sur la comète et dit que Xorg sera inutilisable durant 1 ans, c'est un excellent moyen pour faire fuire les contributeurs. Fais des plans monstreux avec du UML, les plannings, des tests unitaires, etc et tu fais fuire les contributeurs. Force un projet, et du fait fuire Intel. Etc.
MS n'a pas ce "problème" (qui n'en est pas vraiment un) car MS a d'énorme moyen. MS peut avoir un dictateur qui fixe ce qui doit être développé et peut payé des gens en masse pour tous les trucs rébarbatifs. Pour tenir les délais, MS peut embaucher par centaines (ou payer des boites externes).
Etc.
Etc.
Tous ça ne marche pas dans le libre. Le libre a une autre méthode, elle n'est pas plus mal.
> Les propos de Linus ne font pourtant nullement référence à un problème de moyen
Bullshit.
Les micro-noyaux sont bien plus difficiles à écrire et à maintenir
[...]
j'ai vu les gens échouer avec leurs micro-noyaux encore et encore - Il est devenu évident pour moi que l'argument de la simplicité était faux.
Ce qui est compliqué demande beaucoup de boulot.
> il affirme juste gratuitement que ces barrières de protection ca n'a aucun intérêt, que ca n'apporte rien au niveau qualité (stabilité, fiabilité, sécurité, etc.). Et les ouailles disent amen ou cherchent à justifier ces propos avec d'autres arguments.
Et toi tu affirmes l'inverse gratuitement. Balle au centre. M'enfin, je tendance à croire Linus.
Et il y a des faits :
- Il n'y a pas de micro-noyau en production ! Il n'y a que des trucs qui marchouillent et/ou sont très loins de rivaliser avec Linux. Pourtant ça fait depuis des années (et bientôt des dizaines d'années) que des micro-noyau sont en développement.
- Windows n'a pas un micro-noyau. C'est autant un micro-noyau que MacOS est un micro-noyau.
Si tu penses que faire un micro-noyau est facile, pourquoi il n'y en a pas ? On ne trouve que des trucs pour des niches ou qui marchouille si on veut en faire un OS généraliste.
> Même les catholiques (et pourtant je suis loin de les trouver malins) sont plus critiques envers le pape quand il parle de protection inutiles :)
Linus parle de ce qu'il connait. Le pape n'a jamais baisé (avec ou sans capote).
Linus parle de techniques qu'il faut appliquer. Le pape délivre d'un message (qui n'est pas le sien) d'idéal.
[^] # Re: L'avis de Linus
Posté par IsNotGood . En réponse à la dépêche MINIX 3 - Google Summer of Code. Évalué à 2.
Je peux aussi dire que les windows manager à la Linux sont pertinent pour Windows ou qu'un vrai (pas cette merde de powershell) shell c'est pertinent pour Windows. Sauf que la culture, les moyens, etc ne sont pas Linux et donc ça ne marchera pas.
S'il te plait, vu le succès de Firefox, dis que la GPL est pertinent pour IE.
[^] # Re: L'avis de Linus
Posté par IsNotGood . En réponse à la dépêche MINIX 3 - Google Summer of Code. Évalué à 2.
On n'a peut-être pas envis de le faire. MS n'est pas toujours un exemple à suivre.
[^] # Re: L'avis de Linus
Posté par IsNotGood . En réponse à la dépêche MINIX 3 - Google Summer of Code. Évalué à 3.
Tu disais que Vista arrivait à se démerder avec des drivers pas terrible. Ce n'est pas le cas ?
Faut croire que non.
> Heuresement, le kernel Linux, lui il sait gérer ça.
Ce n'est pas ce que j'ai dit.
> C'est pour cela qu'on a pas besoin de barrière, les drivers graphiques sous linux qui plantent, ca n'existe pas, car Linux sait gérer la qualité.
Ce n'est pas ce que j'ai dit, je n'ai pas caché qu'il y avait des problèmes avec Linux.
Mais pour toi, avec Windows et ses barrières magiques il n'y a pas de problème.
Avec Vista on ne doit avoir un plantage à cause d'un driver, on ne doit pas avoir ça :
http://www.youtube.com/watch?v=zFx62_Iadjg
Ooops.
Si 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.
Si on a des moyens infinis, autant faire des barrières, des tests exhautif de regression systématique, etc.
Ce n'est pas le cas de Linux.
Windows avec ses mignonnes barrières et ses moyens délirants ne plante pas moins qu'un Linux.
Tu m'expliques ça ?
En tout cas Linus donne une très bonne explication (c'est le commentaire un peu plus haut si tu l'as raté).
Ce n'est pas car Linux n'a pas des mignonnes barrières que Linux est fragile au moindre problème matériel ou de driver. On est nombreux a avoir eu un problème de driver ou hard sans que ça plante tout le reste. On est nombreux à faire tourner Xorg des semaines de suite sans problème. Un driver merde, on le corrige. On ne met pas 20 ingénieurs à plancher durant 2 ans pour faire un truc qui atténu le problème. Linux préfère corriger directement le problème.
> > Je ne crois pas que le driver soit déchargé et rechargé à la volé.
> Si.
Ça m'étonnerais grave mais admettons.
> Ce qui était également le cas de XP.
C'est toujours le cas avec Vista. Un driver graphique mal écrit peu faire planter Vista.
> mais la capacité au projet dans son ensemble à croire qu'il est possible de maintenir un aussi grand nombre de drivers de qualité, sans avoir besoin de mettre de barrière.
En quoi ajouter des barrières va aider à maintenir plus de driver. Je ne vois pas ou tu veux en venir.
C'est même le contraire. Avec les barrières il y a plus de complexité et il faut plus de moyen pour maintenir l'ensemble.
> Désolé, c'est le problème de Linux. C'est lui qui fourni l'infrastructure pour les drivers, et c'est de sa faute si un driver a un impact aussi important qu'un crash d'une application voir le plantage total du kernel.
Je suis d'accord avec ça, mais le problème de Linux n'est pas l'absence de barrière (Vista avec des barrières plante aussi), mais principalement le manque de moyen (peu de soutient des fabriquants de hardware) et qu'actuellement la partie graphique de Linux est en plein bouleversement.
Je dois insister sur les faibles moyens de Linux. Compte tenu des failbles moyens et qu'il y a des priorités très élevées (virer nv pour utiliser Nouveau, finaliser KMS, virer les vieilleries dans Xorg, etc), ajouter des barrières n'apporte pratiquement rien et ne va pas résoudre ces problèmes. Si le driver Nouveau ne gère pas la carte bidule, ajouter des barrières ne va pas ajouter le support de la carte bidule et donner un support nickel 3D pour les cartes NVidia.
Même si la situation était bonne chez Linux, je ne suis pas convaincu que d'ajouter des barrières serait un plus significatif. Ça complexifie beaucoup, etc.
> Y'a des solutions pour limiter l'impact de ces problèmes
Quand un driver ne marche pas, il ne marche pas. Ajouter des barrières n'y changera rien. Je suis sûr qu'on va assiter à une amélioration énorme de la qualité globale de Linux sur la partie graphique dans les quelques mois à venir (au moins pour Intel et ATI). Et ça sera sans barrière.
> les micro-noyaux sont une partie de cette solution, il paraît donc un brin prétentieux de la part de Linus de dire que ces solutions n'apportent rien au niveau qualité. La stabilité est une qualité.
T'es bien prétentieux de contredire Linus.
> Je penses pas que ce soit une question de moyen.
Dit le à MS. MS sera content de savoir qu'il a des économies à faire.
Dit le à Hurd qui après des années et des années n'arrive toujours pas à décoller.
Dit le à Minix qui cherche ici des développeurs.
Etc.
[^] # Re: L'avis de Linus
Posté par IsNotGood . En réponse à la dépêche MINIX 3 - Google Summer of Code. Évalué à 1.
Mouaif. Ou ça a été fait car MS n'arrivait pas à gérer la qualité et donc a un conçu un truc pour gérer un truc merdique (c'est une supposition).
> un petit tressautement visuel et je peux continuer de jouer avec mon jeu préféré sans interruption.
Je ne connais pas l'architecture de Windows, mais il est possible qu'il ne sache réinitialiser qu'une partie du driver graphique. D'autres parties ne devant pas planter. Je ne crois pas que le driver soit déchargé et rechargé à la volé.
De plus il semble avoir lu que beaucoup des problèmes avec vista sont liés aux drivers graphiques. Donc le système qui supporte les plantages graphiques et les sépare du reste du système n'est manifestement pas au point.
> Va aussi falloir qu'il se fasse une raison Linux, le noyau Linux et le nombre de drivers qu'il y a dedans devient plus que conséquent
???
Les drivers/modules sont chargés que s'il y a le matos qui correspond.
> la complexité de ces drivers est croissante (ex : les drivers graphiques)
Pour Linux, ce n'est pas le problème du moins pour la qualité (ou plantage).
Le problème actuellement est :
- faible support des constructeurs (mais ça s'améliore).
- architecture qui a beaucoup changé sans être encore finalisée (KMS, Gem, Xorg, etc).
- les moyens de Linux pour tout ce qui est desktop est sans commune mesure avec MS.
Avec les faibles moyens qu'a Linux, je pense que ça serait une erreur de faire une usine à gaz qui gère les plantages des drivers.
[^] # Re: Confusion
Posté par IsNotGood . En réponse au journal Derniers résultats financiers de Red Hat. Évalué à 1.
J'ai vu des tonnes de photos de Chuck Norris.
Mais je n'ai pas vu le moindre film de Chuck Norris.
[^] # Re: joli sophisme...
Posté par IsNotGood . En réponse au journal Contrefaçon de DVD et terrorisme. Évalué à 2.
Le titre de l'étude est "Film Piracy, Organized Crime, and Terrorism". Je ne crois pas que ça soit mieux. "Film Piracy" c'est aussi le p2p sur internet.
> La contrefaçon est un financement des mafias et autres et ça ne fait pas de doute, vu que c'est illégal, la contrefaçon ne peux à priori rien financer de légal mais pour conclure ça pas besoin de faire un titre/article à la mort moi le noeud.
La contrefaçon en général n'était pas l'objet principal de l'étude.
Preface
This report presents the findings of research into the involvement of
organized crime and terrorist groups in counterfeiting a wide range
of products, from watches to automobile parts, from pharmaceuticals
to computer software. It presents detailed case studies from around
the globe in one area of counterfeiting, film piracy, to illustrate the
broader problem of criminal...
[...]
Introduction: Defining the Issues
This report investigates the extent to which criminal and terrorist
groups are engaging in counterfeiting, using film piracy as an example.
[...]
Chapter Three turns to counterfeiting, using film piracy as an example
of the low risks and high rewards that make this criminal activity so
attractive.
[...]
Motivation for entry into piracy. What was the type of connec-
tion between organized crime and film piracy, and between ter-
rorism and film piracy?
Peut-être que la contrefaçon de Rolex est plus lucratif. Mais ce n'est pas l'objet du rapport.
[^] # Re: Plantage
Posté par IsNotGood . En réponse à la dépêche MINIX 3 - Google Summer of Code. Évalué à 3.
Bof.
C'est quoi "tuer le pilote" ?
Tu peux plus ou moins faire ça avec Linux, par exemple en branchant et débranchant une carte réseau USB. Wget fera le nécéssaire pour relancer une connexion (ce qu'il a très probablement fait avec Minix 3).
Les drivers ont toujours une tolérance aux erreurs.
> Bien sûr, y'a la solution d'écrire des pilotes sans bug, hum hum.
Pourquoi pas. Ce n'est pas plus irréaliste que de faire un micronoyau hypra souple et capable de gérer toutes les erreurs (voire de faire de l'auto-guérison comme le dit la dépêche). Le principe de Minix 3 supose qu'il y a une partie (assez grosse) sans bug.
C'est pareil avec GNU/Linux, sauf que la partie sans bug est plus grosse. Mais comme c'est moins compliqué, il n'est pas dit que l'un soit intrasèquement moins fiable que autre.
Pour une solution complète, c'est la fiabilité de l'ensemble qui compte. Minix 3 peut ne pas avoir d'erreur, mais si le driver réseau plante toutes les millisecondes c'est sans intérêt. Si la libc déconne, c'est sans intérêt. S'il y a un bug dans wget, c'est sans intérêt.
C'est louable de faire un noyau hyper fiable. Mais il ne faut pas compter sur ça pour corriger ou compenser les erreurs qui sont ailleurs.
[^] # Re: joli sophisme...
Posté par IsNotGood . En réponse au journal Contrefaçon de DVD et terrorisme. Évalué à 0.
Merci. Enfin quelqu'un qui fait la part des choses.
> c'est l'étude/le rapport qu'elle relate qui lui est complètement con
L'avis est brutal et non argumenté, mais pourquoi pas.
[^] # Re: joli sophisme...
Posté par IsNotGood . En réponse au journal Contrefaçon de DVD et terrorisme. Évalué à 1.
Avec toi oui. Mais ce n'est pas le cas avec patrick_g. Relis moi.
> Bon je vais t'aider aucun argument, et attaque personelle de l'interlocuteur,
Faux.
> Cas d'école, et qui montre bien ta grande méconnaissance dans les termes de la réthoriques
Pour la réthorique, t'es plus fort que moi.
Tu m'as accuser d'attaques ad hominem sur patrick_g sans la moindre preuve.
Alors arrête avec ta morale et ta réthorique.
> "Les chercheur ont trouvé que"... ça c'est une belle source.
Lis l'article bouffon.
Les chercheurs de la très respectée Rand Corporation [http://www.rand.org/], à Santa Monica (Californie), ont interrogé 120 agences de maintien de l'ordre, dans plus de vingt pays, pour analyser le "marché" du piratage de films. "Il existe des preuves substantielles d'un lien important et continu entre le piratage de films et le crime organisé", conclut leur rapport, "Film Piracy, Organized Crime and Terrorism", commandé par les studios d'Hollywood, et publié début mars
C'est parfaitement sourcé. On a l'auteur, le titre du document, le lieu et la date. Il faut être un débile profond pour ne pas trouver le document en moins de 2 minutes.
> bon petit apprentissage à l'usage de isnotgood : "comment on source".
C'est sourcé. Vous faites un caca nerveux car il n'y a pas un lien direct sur l'étude. Rien d'autre. C'est minable.
[^] # Re: Confusion
Posté par IsNotGood . En réponse au journal Derniers résultats financiers de Red Hat. Évalué à 1.
Donne des chiffres, va sur le site de Sun, commande une bécane avec Solaris + Virtualisation + clusturing et donne le prix de la partie logiciel/support. Ajoute aussi du support pour le serveur web, Mysql, PostgreSQL, etc (puisque RHEL le fait). Fais de même avec RHEL et t'en conclus que RHEL est NETTEMENT moins cher. Fin du débat, pas besoin d'une étude de 3 mois pour savoir ça.
Juste pour cluster :
http://catalog.sun.com/is-bin/INTERSHOP.enfinity/WFS/Sun_Cat(...)
CLNIS-320-A929 Frais à acquitter pour la licence serveur Sun Cluster 3.2 pour Netra 210, (une licence par serveur), facture uniquement € 2,000.00
Jusqu'où ça peut monter ?
Roulement de tambour :
CLAI9-LCA-1199 Frais de licence Sun Cluster Advanced Edition pour Oracle RAC, Niveau 11, comprend des licences d’utilisation pour Sun Cluster RAC Agent, Shared QFS Metadata Server and Client, Sun Cluster Agent for QFS Metadata Server, Sun Cluster-Oban, Sun Cluster-QFS-Oban, prend en charge Solaris SPARC/x86, (facturation au nœud) € 151,200.00
Fichtre 151 200 € !
Un serveur web avec support :
http://catalog.sun.com/is-bin/INTERSHOP.enfinity/WFS/Sun_Cat(...)
WS72I-LCO-9929 Licence Sun Java System Web Server 7.0 Enterprise Edition, Solaris/x86, (par socket) € 1,350.00
Fichtre !
Tout est dans ce style. Avec le Solaris de base, tu as trois fois rien, il faut acheter plein de truc après.
Tu vas maintenant expliquer que Sun vend des trucs qui ne servent à rien ?
Alors ta comparaison biaisée de Sun pour Sun, je m'en torche le cul.