Le débat Tanenbaum-Torvalds\nAnnexe A. Le débat Tanenbaum-Torvalds\nVous trouverez dans cette annexe le texte du débat entre Tanenbaum et Linus connu dans la communauté sous le titre « Linux est dépassé ». Andrew Tanenbaum est un chercheur très respecté, qui a fort bien gagné sa vie en étudiant les systèmes d'exploitation et leur conception. Au début de 1992, ayant remarqué que les discussions sur Linux prenaient le pas sur les autres dans comp.os.minix, il décida qu'il était temps de publier ses opinions.\nBien qu'Andrew Tanenbaum fut tourné en ridicule pour sa maladresse et ses mauvais jugements sur le noyau Linux, la réaction qu'il essuya fut injuste. Lorsque Linus lui-même entendit dire que nous allions publier ce débat, il voulut s'assurer que tout le monde comprenne qu'il ne gardait aucune animosité envers Tanenbaum, et n'aurait en fait pas approuvé cette publication si nous n'avions pu le convaincre que cela montrerait comment les systèmes d'exploitation étaient perçus à l'époque.\nLa publication de cette annexe pourrait donner une bonne idée de l'état des choses dans les milieux universitaires au moment où Linus était sous pression pour avoir abandonné l'idée de micro-noyau. Le premier tiers de la discussion montre cela plus en détail.\nDes copies électroniques de cette discussion sont faciles à trouver sur le Web. Il est amusant de lire ceci et de noter que parmi les personnes qui se joignirent à la discussion vous trouverez Ken Thompson (l'un des concepteurs d'Unix) et David Miller (devenu un hacker majeur du noyau Linux) et encore bien d'autres.\nPour replacer cette discussion dans son contexte, lorsqu'elle commença en 1992, le 386 était le microprocesseur dominant et le 486 n'était pas sorti sur le marché. Microsoft était encore une petite entreprise commercialisant MS-DOS et Word pour MS-DOS. Lotus 123 dominait le marché des tableurs, et WordPerfect celui des éditeurs de texte. DBASE était l'éditeur dominant de logiciels de gestion de base de données, et beaucoup d'entreprises dont les noms sont maintenant connus de tous (Netscape, Yahoo, Excite) n'existaient tout simplement pas.\nDe: ast@cs.vu.nl (Andy Tanenbaum)\nGroupe de discussion: comp.os.minix\nSujet: Linux est dépassé\nJ'ai passé 15 jours aux États-Unis, je n'ai donc pas pu faire\nbeaucoup de remarques sur Linux (non pas que j'en aurais dit plus,\naurais-je été dans le coin), mais souhaite à présent publier un ou deux\nComme la plupart d'entre vous le savent, MINIX est pour moi un\npasse-temps, quelque chose que je fais le soir quand j'en ai assez\nd'écrire des livres et qu'il n'y a pas de guerre exceptionnelle, de\nrévolution, ou d'audience au sénat retransmise sur CNN. Mon vrai\ntravail est professeur et chercheur dans le domaine des systèmes\nÉtant donnée ma profession, je pense que je sais à peu près vers où\nl'exploitation va se diriger dans la décennie à venir. Deux aspects\n1. SYSTÈME MONOLITHIQUE CONTRE MICRO-NOYAU\nLa plupart des anciens systèmes d'exploitation sont monolithiques,\nc'est-à-dire que le système d'exploitation entier est un unique\nfichier a.out qui s'exécute en 'mode noyau'. Ce binaire contient la\ngestion des processus, la gestion de la mémoire, le système de\nfichiers et le reste. Des exemples de tels systèmes sont UNIX,\nMSDOS, VMS, MVS, OS/360, MULTICS, et beaucoup d'autres.\nL'autre option est un système à micro-noyau, dans lequel le\nplus gros du SE s'exécute en tant que processus séparés, pour la\nplupart en dehors du noyau. Ils communiquent par passage de\nmessages. Le travail du noyau est de contrôler le passage des\nmessages, le contrôle des interruptions, la gestion des processus\nbas-niveau, et si possible les E/S. Des exemples de cette conception\nsont les RC4000, Amoeba, Chorus, Mach, et le pas-encore-réalisé\nBien que je pourrais me lancer ici dans une longue histoire sur les\nmérites relatifs des deux concepts, je me contenterai de dire que\nparmi les personnes concevant à l'heure actuelle des systèmes\nd'exploitation, la discussion est essentiellement close. Les\nmicro-noyaux ont gagné. Le seul vrai argument pour les systèmes\nmonolithiques était la performance, et il est maintenant assez\névident que les systèmes à micro-noyau peuvent être tout aussi\nrapides que les systèmes monolithiques (par ex., Rick Rashid a\npublié des notes comparant Mach 3.0 à des systèmes monolithiques),\net il ne reste donc maintenant que des détails à régler.\nMINIX est un système à micro-noyau. Le système de fichiers\net la gestion de la mémoire sont des processus séparés, s'exécutant\nen dehors du noyau. Les gestionnaires d'E/S sont aussi des processus\nséparés (dans le noyau, mais seule la nature comateuse des\nprocesseurs Intel fait qu'il est difficile de faire autrement).\nLINUX est un système de style monolithique. C'est un pas de géant en\narrière dans les années 1970. C'est comme prendre un programme C\nexistant et qui marche et le réécrire en BASIC. Pour moi, écrire un\nsystème monolithique en 1991 est une idée vraiment médiocre.\nIl était une fois le microprocesseur 4004. En grandissant, il devint\nun 8008. Puis il subit une opération de chirurgie plastique et devint\nle 8080. Il engendra le 8086, qui engendra le 8088, qui engendra le\n80286, qui engendra le 80386, qui engendra le 80486, et ainsi de suite\njusqu'à la Nième génération. Pendant ce temps, les microprocesseurs\nRISC apparurent, et certains d'entre eux développant plus de 100 MIPS.\nDes vitesses supérieures à 200 MIPS seront vraisemblables atteintes\ndurant les prochaines années. Ces choses ne vont pas disparaître\nsubitement. Ils prennent peu à peu le pas sur la lignée des 80x86\net exécuteront de vieux programmes MS-DOS en simulant le 80386 au\nniveau logiciel (j'ai même écrit mon propre simulateur IBM PC en C,\nqui peut être obtenu par FTP depuis ftp.cs.vu.nl = 192.31.231.42\ndans le répertoire minix/simulator). Je pense que c'est une erreur\ngrossière que de concevoir un SE pour une architecture spécifique,\nalors que celle-ci ne sera bientôt plus disponible.\nMINIX a été conçu pour être raisonnablement portable, et a été porté\nde la ligne Intel aux 680x0 (Atari, Amiga, Macintosh), SPARC, et\nNS32016. Linux est attaché de très près au 80x86. C'est une mauvaise\nNe le prends pas mal, je ne suis pas mécontent de LINUX. Il va amener\ntous ceux qui veulent faire évoluer MINIX en BSD UNIX derrière moi.\nMais en toute honnêteté, je voudrais suggérer à ceux qui veulent un\nSE "libre" **MODERNE** qu'ils recherchent un SE à micro-noyau,\nportable, comme peut-être GNU ou quelque chose comme ça.\nP.S. Juste en passant, Amoeba a un émulateur UNIX (s'exécutant au\nniveau utilisateur), mais il est loin d'être complet. S'il y a\nquelqu'un qui veut travailler dessus, merci de me le faire savoir.\nPour exécuter Amoeba, vous devez avoir quelques 386, l'un d'eux\nnécessitant 16M, et tous équipés d'une carte Ethernet WD.\nSujet: Re : LINUX est dépassé\nBien, avec un sujet tel que celui-ci, j'ai bien peur de devoir\nrépondre. Que les utilisateurs de minix qui en ont assez d'entendre\nparler de linux m'excusent. J'aimerais pouvoir dire "ne tenez pas\ncompte de cette attaque", mais... il est temps d'entamer une\nsérieuse querelle !\nDans l'article <12595@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum)\n> J'ai passé 15 jours aux États-Unis, je n'ai donc pas pu faire\n> beaucoup de remarques sur Linux (non pas que j'en aurais dit plus,\n> aurais-je été dans le coin), mais souhaite à présent publier un ou deux\n> Comme la plupart d'entre vous le savent, MINIX est pour moi un\n> passe-temps, quelque chose que je fais le soir quand j'en ai assez\n> d'écrire des livres et qu'il n'y a pas de guerre exceptionnelle, de\n> révolution, ou d'audience au sénat retransmise sur CNN. Mon vrai\n> travail est professeur et chercheur dans le domaine des systèmes\nVous utilisez cela [être un professeur] comme excuse pour les\nlimitations de minix ?\nDésolé mais vous avez perdu : j'ai plus d'excuses que vous, et linux\nbat toujours minix à plate couture dans la plupart des domaines.\nEt je n'insisterai pas sur le fait que le plus gros de l'excellent code\ndu minix pour PC semble avoir été écrit par Bruce Evans.\nRe 1 : vous considérez minix comme un passe-temps - regardez qui gagne\nde l'argent avec minix, et qui offre linux. Maintenant\nparlons passe-temps. Faites en sorte que minix soit librement\naccessible, et l'un de mes plus gros griefs disparaîtra. Linux a été\ntrès certainement un passe-temps (mais du type meilleur type : sérieux)\npour moi : je n'ai pas reçu d'argent, et il ne fait même pas partie\nde mes études universitaires. J'ai tout réalisé sur mon propre temps,\net sur ma propre machine.\nRe 2 : vous êtes professeur et chercheur : c'est une sacrée bonne\nexcuse expliquant les dommages cérébraux provoqués par minix.\nJ'espère seulement (et je le suppose) qu'Amoeba n'est pas aussi\nnul que minix.\n>1. SYSTÈME MONOLITHIQUE CONTRE MICRO-NOYAU\nC'est vrai, linux est monolithique, et je suis d'accord que les\nmicro-noyaux sont mieux. Sur un sujet appelant moins à polémique,\nj'aurais été probablement d'accord avec l'essentiel de ce que\nvous avez dit. D'un point de vue théorique (et esthétique),\nlinux a perdu.\nSi le noyau GNU avait été fini au dernier printemps, je ne me serais\nmême pas embêté à démarrer mon projet : le fait est qu'il ne l'était\npas et ne l'est pas encore. Linux a l'énorme avantage\nd'être disponible maintenant.\n>   MINIX est un système à micro-noyau. [ écourté, mais de\n> façon que vous ne puissiez perdre le fil ].  LINUX est un système\nSi c'était le seul critère de « bonne qualité » d'un\nnoyau, ce serait exact. Ce que vous ne mentionnez pas, c'est\nque minix ne fonctionne pas comme un micro-noyau de manière correcte,\net pose des problèmes avec le multitâche en temps réel (dans le\nnoyau). Si j'avais fait un SE ayant des problèmes avec un système\nde fichiers subdivisé en unités d'exécution, je n'aurais pas été\naussi prompt à condamner les autres : en fait, j'aurais fait tout\nmon possible pour que les autres oublient ce fiasco.\n[ Oui, je sais qu'il y a des bitouillages sur le multithreading\npour minix, mais ce sont des bitouillages, et Bruce Evans m'a dit\nqu'il existe un tas de contraintes ]\n« La portabilité, c'est pour les gens qui ne savent pas écrire de\nnouveaux programmes » - moi, à l'instant (ton ironique).\nLe fait est que linux est plus facilement portable que minix. Quoi ?\nvous entends-je dire. C'est vrai - mais pas dans le sens où l'entend\nast : j'ai conçu linux aussi conforme qu'il m'était possible aux\nnormes (sans avoir de copie des normes POSIX sous la main).\nPorter des choses sous linux est généralement /beaucoup/ plus facile\nque de les porter sous minix.\nJe suis d'accord avec le fait que la portabilité est une bonne chose :\nmais uniquement lorsque cela a réellement une signification. Cela\nn'a pas de sens de créer un système d'exploitation totalement\nportable : coller à une API portable suffit. La véritable\n/idée/ d'un système d'exploitation est d'utiliser les fonctionnalités\ndu matériel, et de les placer derrière une couche d'appels de haut\nC'est exactement ce que fait linux : il utilise en fait plus\ncomplètement les fonctionnalités du 386 que les autres noyaux.\nBien sûr cela rend le noyau non portable au sens strict, mais cela\nconduit à une conception /vraiment/ plus simple. Un compromis\nacceptable, mais qui a eu pour premier avantage de permettre\nl'existence de linux.\nJe suis d'accord également avec le fait que linux porte la\nnon-portabilité à un extrême : j'ai acquis mon 386 en janvier\ndernier, et linux faisait partie d'un projet visant à m'apprendre\nà m'en servir. Les choses auraient été faites de manière plus\nportable si j'avais eu un projet concret. Je ne cherche pas des\ntas d'excuses, bien que c'était une décision de conception, et quand\nj'ai démarré les choses en avril dernier, je ne pensais pas que\nquelqu'un l'utiliserait réellement. Je suis heureux de dire que j'ai\neu tort car mes sources sont librement disponibles et chacun\npeut essayer de les porter, même si cela ne sera pas facile.\nPS. Excusez-moi pour ce qui peut sembler parfois sévère : minix est\nsuffisant si vous n'avez rien d'autre. Amoeba pourrait être\nimpeccable si vous possédez 5 à 10 386 en secours, mais je ne m'y\nrisquerai pas. Je ne me lance pas habituellement dans les querelles\nmais suis susceptible quand il s'agit de linux :)\n(Linus Benedict Torvalds) écrit :\n>Vous utilisez cela [être un professeur] comme excuse pour les\n>limitations de minix ?\nLes limitations de MINIX sont liées en partie au fait que\nje suis professeur : j'avais comme objectif précis de le faire\nfonctionner sur du matériel bon marché afin que les étudiants puissent\nse l'offrir. En particulier, durant des années il tourna sur un PC\nordinaire à 4.77 MHz sans disque dur. Vous pouviez tout faire avec,\nmodifier et recompiler le système inclus. Juste pour mémoire,\njusqu'à il y a un an environ, il y avait deux versions, une pour\nle PC (disquettes 360K) et une pour le 286/386 (1.2M). La version PC\nse vendait deux fois mieux que la version 286/386. Je n'ai pas de\nchiffres, mais mon opinion est que la fraction des 60 millions de PC\nexistants qui sont des machines 386/486 opposées aux 8088/286/680x0\netc est faible. Parmi les étudiants elle est encore plus faible.\nDévelopper du logiciel gratuit uniquement destiné aux gens ayant\nassez  d'argent pour acheter du matériel de première classe est un\nBien sûr, dans 5 ans, ça sera différent, mais dans 5 ans tout le\nmonde emploiera le GNU gratuit sur sa station SPARC-5 à 200 MIPS,\n>Re 2 : vous êtes professeur et chercheur : c'est une sacrée bonne\n>excuse expliquant les dommages cérébraux provoqués par minix.\n>J'espère seulement (et je le suppose) qu'Amoeba n'est pas aussi\n>nul que minix.\nAmoeba n'a pas été conçu pour fonctionner sur un 8088 sans disque dur.\n>Si c'était le seul critère de « bonne qualité » d'un\n>noyau, ce serait exact. Ce que vous ne mentionnez pas, c'est\n>que minix ne fonctionne pas comme un micro-noyau de manière correcte,\n>et pose des problèmes avec le multitâche en temps réel (dans le\n>noyau). Si j'avais fait un SE ayant des problèmes avec un système\n>de fichiers subdivisé en unités d'exécution, je n'aurais pas été\n>aussi prompt à condamner les autres : en fait, j'aurais fait tout\n>mon possible pour que les autres oublient ce fiasco.\nUn système de fichiers multi-thread est seulement un bitouillage\nperformances. Lorsqu'il y a seulement un processus actif, cas normal\nsur un petit PC, cela ne vous apporte rien et ajoute de la complexité\nau code. Sur des machines suffisamment rapides pour servir\nplusieurs utilisateurs, vous avez probablement assez de mémoire-cache\npour assurer un bon cache à un bon taux, auquel cas le multi-thread\nne vous apporte rien non plus. Cela ne rapporte vraiment que\nlorsque plusieurs processus font au même moment des E/S effectives\nsur disque. Que ça vaille la peine de rendre le système plus complexe\ndans ce cas est pour le moins discutable.\nJe persiste à penser que concevoir un noyau monolithique en\n1991 est une erreur fondamentale. Estime-toi heureux de ne pas être\nun de mes étudiants. Tu n'obtiendrais pas une bonne note pour une\ntelle conception :-)\n>Le fait est que linux est plus facilement portable que minix. Quoi ?\n>vous entends-je dire. C'est vrai - mais pas dans le sens où l'entend\n>ast : j'ai conçu linux aussi conforme qu'il m'était possible aux\n>normes (sans avoir de copie des normes POSIX sous la main).\n>Porter des choses sous linux est généralement /beaucoup/ plus facile\n>que de les porter sous minix.\nMINIX fut conçu avant POSIX, et est maintenant en train d'être\n(lentement) POSIXisé comme quiconque suivant ce groupe le sait. Tout\nle monde convient que des normes au niveau utilisateur sont une bonne\nidée. En aparté, je te félicite d'être capable d'écrire un système\nen conformité avec POSIX sans avoir les normes POSIX en face de toi.\nJe trouve ceci assez difficile après avoir étudié les normes dans le\nJe pense qu'écrire un nouveau système d'exploitation\nétroitement lié à un matériel particulier, surtout aussi étrange\nque la ligne Intel, est fondamentalement mauvais. Un SE lui-même doit\nêtre facilement portable vers de nouvelles plates-formes matérielles.\nLe fait qu'OS/360 fut écrit en langage d'assemblage IBM 360 il y a 25\nans peut probablement être excusé. Lorsque MS-DOS fut écrit\nexplicitement pour le 8088 il y a 10 ans, c'était moins que brillant,\ncomme le réalisent trop péniblement IBM et Microsoft maintenant\nseulement. Écrire un nouveau SE seulement pour le 386 en 1991 te donne\nune autre mauvaise note pour ce trimestre. Mais si tu fais vraiment\nmieux à l'examen final, tu peux encore empocher le module.\nDe: feustel@netcom.COM (David Feustel)\nOrganisation: DAFCO - An OS/2 Oasis\nast@cs.vu.nl (Andy Tanenbaum) écrit :\n>Je persiste à penser que concevoir un noyau monolithique en\n>1991 est une erreur fondamentale. Estime-toi heureux de ne pas être\n>un de mes étudiants. Tu n'obtiendrais pas une bonne note pour une\n>telle conception :-)\nC'est vrai. Einstein a eu des notes déplorables en maths et en\nDe: pete@ohm.york.ac.uk (-Pete French.)\nOrganisation: Electronics Department, University of York, UK\ndans l'article <1992Jan30.195850.7023@epas.toronto.edu>,\nmeggin@epas.utoronto.ca (David Megginson) dit :\n> Dans l'article <1992Jan30.185728.26477feustel@netcom.COM>\nfeustel@netcom.COM (David > Feustel) écrit :\n>>C'est vrai. Einstein a eu des notes déplorables en maths et en\n> Et Dan Quayle une mauvaise note en sciences politiques. Je pense\n> qu'il y a plus de Dan Quayle que d'Einstein ici bas.. ;-)\nQuelle abominable réflexion !\nMais pour revenir au débat micro-noyau <-> monolithique,\nn'utilise-t-on pas en partie un artifice de langage ? MINIX peut\ntrès bien être conçu comme un système micro-noyau, mais au bout du\ncompte vous finirez toujours avec un gros morceau monolithique\nde données binaires constituant « le système d'exploitation ».\nN'est-il pas écrit en plusieurs programmes distincts parce que C\nn'accepte pas l'idée de plusieurs processus inclus dans un seul\nmorceau de code monolithique. Y a-t-il vraiment une différence\nentre un micro-noyau écrit en plusieurs morceaux de C et un noyau\nmonolithique écrit dans le style d'OCCAM ? Je suis enclin à penser\nque dans ce cas le concept monolithique serait meilleur que le\nconcept micro-noyau, puisqu'avec l'avantage d'avoir un langage\nhomogène, le noyau peut être conçu de manière encore plus modulaire\nque celui de MINIX.\nMINOX cherche un défenseur :-)\nDe: kt4@prism.gatech.EDU (Ken Thompson)\nDate: 3 Fév 92 23:07:54 GMT\nLe point de vue peut être dissocié du côté utilitaire.\nSurtout si ce n'est pas la majorité du logiciel utilisé\nqui est peut-être dépassé, suivant le tout dernier critère\nde conception. La plupart des utilisateurs se soucieront\npeu du fait que la conception interne du système d'exploitation\nqu'ils utilisent est dépassée. Ils seront beaucoup plus intéressés\npar les performances et les possibilités au niveau utilisation.\nJe serais plutôt d'accord avec le fait que les micro-noyaux vont\nprobablement dans le sens de l'histoire. Cependant, à mon avis,\nil est plus facile d'implémenter un noyau monolithique. Et il est\négalement plus facile pour lui de tourner rapidement en eau de\nboudin en cas de modification.\nDe: kevin@taronga.taronga.com (Kevin Brown)\nDate: 4 Fév 92 08:08:42 GMT\nOrganisation: University of Houston\nDans l'article <47607@hydra.gatech.EDU> kt4@prism.gatech.EDU\n(Ken Thompson) écrit :\n>Le point de vue peut être dissocié du côté utilitaire.\n>Surtout si ce n'est pas la majorité du logiciel utilisé\n>qui est peut-être dépassé, suivant le tout dernier critère\n>de conception. La plupart des utilisateurs se soucieront\n>peu du fait que la conception interne du système d'exploitation\n>qu'ils utilisent est dépassée. Ils seront beaucoup plus intéressés\n>par les performances et les possibilités au niveau utilisation.\n>Je serais plutôt d'accord avec le fait que les micro-noyaux vont\n>probablement dans le sens de l'histoire. Cependant, à mon avis,\n>il est plus facile d'implémenter un noyau monolithique. Et il est\n>également plus facile pour lui de tourner rapidement en eau de\n>boudin en cas de modification.\nQuelle difficulté y a-t-il à structurer l'arborescence des\nprogrammes source d'un noyau monolithique en sorte que\nla plupart des modifications\nn'auront pas de répercussions vraiment négatives sur les sources ?\nDans quelles sortes de pièges vous précipitez-vous avec ce type\nde comportement, et quelles suggestions pouvez-vous faire pour\nvous en sortir ?\nVoilà ce que je demande : qu'y a-t-il de difficile à organiser\nles sources de manière à ce que la plupart des changements\neffectués dans le noyau restent localisés quant à leurs conséquences,\nmême si le noyau est lui-même monolithique ?\nJe pense que vous avez des années d'expérience sur les noyaux\nmonolithiques :-), dès lors je pense que vous essayerez de répondre\nau mieux à de telles interrogations.\nDe: rburns@finess.Corp.Sun.COM (Randy Burns)\nOrganisation: Sun Microsystems, Mt. View, Ca.\nDans l'article <12615@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum)\n>Dans l'article <1992Jan29.231426.20469@klaava.Helsinki.FI>\n>torvalds@klaava.Helsinki.>FI (Linus Benedict Torvalds) écrit :\n>Bien sûr dans 5 ans ça sera différent, mais dans 5 ans tout le monde\n>emploiera le GNU gratuit sur sa station SPARC-5 à 200 MIPS, 64M.\nEt bien, je suis de ceux qui _aimeraient_ que cela arrive.\n>>Le fait est que linux est plus facilement portable que minix. Quoi ?\n>>vous entends-je dire. C'est vrai - mais pas dans le sens où l'entend\n>>ast : j'ai conçu linux aussi conforme qu'il m'était possible aux\n>>normes (sans avoir de copie des normes POSIX sous la main).\n>>Porter des choses sous linux est généralement /beaucoup/ plus facile\n>>que de les porter sous minix.\n>Je pense qu'écrire un nouveau système d'exploitation\n>étroitement lié à un matériel particulier, surtout aussi étrange\n>que la ligne Intel, est fondamentalement mauvais.\nEn premier lieu, les parties de Linux qui s'adaptent le mieux aux\n80x86 sont le noyau et les pilotes de périphériques.\nMon sentiment est que même si Linux n'est simplement qu'un pis-aller\npour nous permettre d'employer des logiciels GNU, cela vaut\nencore la peine d'avoir un noyau bien adapté pour le plus grand\nnombre d'architectures existantes.\n>Un SE lui-même doit\n>être facilement portable vers de nouvelles plates-formes matérielles.\nBien, la seule partie de Linux qui ne soit pas portable est le noyau\net les pilotes de périphériques. Par rapport aux compilateurs,\naux utilitaires, aux systèmes de fenêtrage, etc. c'est vraiment une\npetite partie de l'effort. Étant donné que Linux possède une grande\ncapacité de compatibilité dans les appels avec les SE portables, je\nne m'en plaindrais pas. Je suis personnellement très heureux\nd'avoir un SE qui fait que certains d'entre nous pourront\ntirer avantage des logiciels provenant de Berkeley, FSF, CMU, etc.\nPeut-être que dans 2 à 3 ans les variantes super économiques BSD et\nHurd feront des petits, et Linux sera dépassé. Mais juqu'à présent\nLinux réduit de manière notable le coût d'utilisation des outils\ntels que gcc, bison, bash qui servent pour le développement d'un tel\nDans  l'article <12615@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum)\n>Les limitations de MINIX sont liées en partie au fait que\n>je suis professeur : j'avais comme objectif précis de le faire\n>fonctionner sur du matériel bon marché afin que les étudiants puissent\nD'accord : c'est un point technique indiscutable, ce qui rend certains\nde mes commentaires inexcusables. Mais en même temps vous vous emmêlez\nun peu les pinceaux : maintenant vous admettez que certaines erreurs\nde minix proviennent de sa trop grande portabilité : y compris pour\ndes machines qui n'étaient pas vraiment conçues pour\nunix.  Cette supposition induit alors que minix ne pourrait\npas facilement être développé en y incluant des choses telles que\nla pagination, même avec des machines pouvant l'accepter.\nOui, minix est portable, mais vous pouvez  reformuler ceci\ncomme « n'utilisant aucune fonctionnalité », et ce serait toujours\n>Un système de fichiers multi-thread est seulement un bitouillage\n>d'amélioration des performances.\nCe n'est pas vrai. C'est un bitouillage d'amélioration des\nperformances /avec un micro-noyau/, mais cela devient automatique lorsque\nvous écrivez un noyau monolithique - c'est un domaine où les micro-noyaux\nne sont pas très performants (comme je le faisais remarquer dans ma\ncorrespondance privée avec ast). Lorsque vous concevez un unix de\nmanière « dépassée », vous obtenez automatiquement un noyau\nmultithread : chaque processus fait son propre travail, et vous n'avez\npas à faire de vilaines choses telles que des files d'attente de\nmessages pour qu'il fonctionne de manière efficace.\nDe plus, il y a des gens qui considèrent « seulement un\nbitouillage d'amélioration des performances » comme vital :\nexcepté le cas où vous possédez un cray-3, je pense que tout le monde\nse lasserait d'attendre le micro-ordinateur tout le temps. Je sais\nque je l'ai fait avec minix (bien sûr, je l'ai fait avec linux aussi,\nmais il est /beaucoup/ mieux).\nBien, je n'aurais pas eu de très bonnes notes même avec vous : j'ai eu\nune discussion (sans rapport aucun - même pas avec les SE) avec la\npersonne qui enseigne ici à l'université la conception des SE.\nJe me demande quand j'apprendrai :)\n>que la ligne Intel, est fondamentalement mauvais. Un SE lui-même doit\nMais /mon/ point de vue est que le système d'exploitation /n'est pas/\nlié à un type quelconque de microprocesseur : UNIX fonctionne sur la\nplupart des processeurs existants. Oui, /l'implémentation/ dépend\nde l'architecture, mais c'est une ÉNORME différence. Vous citez\nOS/360 et MS-DOG comme exemples de mauvaise conception car ils sont\ndépendants du matériel, et je suis d'accord avec vous. Mais il y a\nune grande différence entre ceux-ci et linux : l'API de linux\nest portable (non pas parce que je l'ai conçu astucieusement, mais\nparce que j'ai décidé de faire un unix plutôt-bien-pensé et testé).\nSi vous écrivez des programmes pour linux à ce jour, vous ne devriez\npas avoir trop de surprises en les recompilant pour Hurd au\n21ème siècle. Comme remarqué (et pas seulement par moi), le noyau\nlinux est une toute petite partie d'un système complet : les sources\ncomplètes de linux prennent environ 200 Ko sous forme compactée - les\nsources complètes d'un système en développement prennent au moins\n10 Mo sous forme compactée (et facilement beaucoup, beaucoup plus).\nEt les sources complètes sont portables, sauf pour le minuscule noyau\nque vous pouvez (pour preuve : je l'ai fait) réécrire totalement à\npartir de rien en moins d'un an sans avoir /aucune/ connaissance\nDe fait, le noyau linux /complet/ est beaucoup plus petit que ce qui\nconcerne le 386 dans mach : i386.tar.Z pour la version actuelle\nde Mach fait plus de 800 Ko compactés (83391 octets selon\nnic.funet.fi). Il est vrai que mach est « quelque peu » plus gros et\na plus de fonctionnalités, mais cela devrait toujours vous dire\nDe: kaufman@eecs.nwu.edu (Michael L. Kaufman)\nDate: 3 Fév 92 22:27:48 GMT\nOrganisation: EECS Department, Northwestern University\nJ'ai essayé d'envoyer ces deux réponses depuis mon travail, mais pense\nqu'elles ont disparu. Désolé si vous les avez déjà lues.\nAndy Tanenbaum écrit un article intéressant (de même, il est\nintéressant de savoir qu'il lit effectivement ce groupe de discussion)\nmais je pense qu'il oublie un point important.\n>   Comme la plupart de vous le savent, pour moi MINIX est un\nCe qui est probablement vrai pour la plupart des personnes, si ce\nn'est toutes, qui travaillent sur Linux. Nous ne développons pas un\nsystème pour conquérir le marché des systèmes d'exploitation, nous\npassons seulement un bon moment.\n>   Ils prennent peu à peu le pas sur la lignée des 80x86 et\n>   exécuteront de vieux programmes MS-DOS en simulant le 80386\n>   au niveau logiciel\nBien, quand ceci arrivera et si je désire toujours jouer avec Linux,\nje pourrai le lancer sur mon simulateur de processeur 386.\n>  MINIX a été conçu pour être raisonnablement portable, et a été porté\n>  de la ligne Intel aux 680x0 (Atari, Amiga, Macintosh), SPARC, et\n>  NS32016. Linux est attaché de très près au 80x86. C'est une mauvaise\nC'est très bien pour les personnes qui possèdent ces machines, mais\ncela ne s'est pas passé  sans dommage. Cette portabilité fut atteinte\nau détriment des performances et de quelques caractéristiques propres\nau 386. Avant de décréter que Linux n'est pas sur le bon chemin, vous\ndevriez penser à quoi il va servir. Je vais l'utiliser sur mon 486\npour lancer des applications graphiques très gourmandes en calcul et\n>Mais en toute honnêteté, je voudrais suggérer à ceux qui veulent un\n>SE "libre" **MODERNE** qu'ils recherchent un SE à\n>micro-noyau, portable, comme peut-être GNU ou quelque chose comme ça.\nJe ne connais pas de système d'exploitation micro-noyau portable et\nlibre. GNU Hurd est toujours dans les limbes et va le rester pour un\nmoment encore. En avez-vous un à recommander, ou bien me\ntaquinez-vous ? ;-)\nJe pense comprendre nos points de désaccord. Vous regardez la\nconception de systèmes d'exploitation comme une fin en soi. Minix est\nbien car il est portable, micro-noyau, etc. Linux est mauvais car il\nest hermétiquement attaché à Intel. Ce n'est pas une étrange attitude\nvenant de quelqu'un du monde académique, mais vous ne devriez pas\nvous attendre à la voir universellement partagée. Linux n'est pas\nconçu comme un outil pédagogique, ou un exercice abstrait. Il est\nécrit pour permettre aux gens d'exécuter des logiciels GNU\naujourd'hui. Le fait qu'il ne puisse pas être utilisé dans cinq ans\nest moins important que le fait qu'aujourd'hui, je peux lancer dessus\ntoutes sortes de logiciels que je veux. Vous maintenez que Minix est\nmeilleur, mais s'il ne permet pas d'exécuter les logiciels que je\nveux, il n'est pas du tout bon (pour moi).\n>Le fait qu'OS/360 fut écrit en langage d'assemblage IBM 360 il y a 25\n>ans peut probablement être excusé. Lorsque MS-DOS fut écrit\n>explicitement pour le 8088 il y a 10 ans, c'était moins que brillant,\n>comme le réalisent trop péniblement IBM et Microsoft maintenant\nMême point. Microsoft n'est pas sorti avec DOS pour « explorer les\nfrontières des systèmes d'exploitation ». Ils l'ont écrit pour faire\nde l'argent. En considérant le fait que MS-DOS se vend en plus grande\nquantité que tout le reste réuni, vous ne pouvez pas dire qu'ils ont\nraté leur but. Ce n'est pas que MS-DOS soit le meilleur système\nd'exploitation suivant d'autres caractéristiques, mais il a servi leur\nDe: julien@incal.inria.fr (Julien Maisonneuve)\nDate: 3 Fév 92 17:10:14 GMT\nJ'aimerais apporter de l'eau au moulin de Kevin Brown pour la plupart\nde ses remarques.\nJ'ajouterai quelques considérations propres à l'utilisateur :\n- Quand ast affirme que le multi-thread pour un système de fichiers\nest inutile, cela me rappelle toutes les fois où j'ai voulu laisser\nune tâche en arrière-plan (comme la lecture d'une archive\ndepuis une disquette), c'est tout simplement inutilisable, l'opérateur\ndu shell & aurait pu tout aussi bien être laissé de côté.\n- Les utilitaires les plus intéressants ne sont même pas compilables\nsous Minix en raison des limitations incroyables du compilateur d'ATK.\nOn pouvait les admettre à la rigueur sur un PC de base, sur un 386,\ncela devient absurde. N'importe quel bête compilateur DOS est doté\nd'un modèle mémoire 'large' (plus cher, d'accord).  Je déteste le\ncompactage 13 bits !\n- L'absence de gestion de la mémoire virtuelle interdit d'étudier\nce domaine à des fins d'expérimentation et d'utiliser des programmes\nLa conception étrange du MM le rend également difficile à modifier.\nLe problème est que même des travaux d'exploration sont pénibles sous\nminix. Si vous voulez accomplir une tâche (ou même vous amuser), même\nDOS devient un meilleur choix (avec des choses telles que DJ GPP).\nÀ la base, ce n'est rien d'autre qu'un exemple didactique de SE, un\nbeau jouet, certes, mais un jouet quand même. Récupérer et appliquer\ndes patches est fastidieux et exclut les mises à jour ultérieures.\nDommage quand il manque si peu pour en faire quelque chose de vraiment\nbien.  Merci pour le travail Andy, mais Linux ne méritait pas votre\nréponse.  Pour le commun des mortels, il fait beaucoup de choses\nmieux que Minix.\nCe n'est pas une descente en flamme, seulement mon expérience.\nDe: richard@aiai.ed.ac.uk (Richard Tobin)\nDate: 4 Fév 92 14:46:49 GMT\nRépondre à: richard@aiai.UUCP (Richard Tobin)\nOrganisation: AIAI, University of Edinburgh, Scotland\n>performances. Lorsqu'il y a seulement un processus actif, cas normal\n>sur un petit PC, cela ne vous apporte rien\nJe trouve l'utilisation d'un système de fichiers à thread unique\nparticulièrement pénible avec Minix. J'ai souvent besoin de faire\nautre chose pendant que je lis des fichiers depuis une (atrocement\nlente) disquette. Je préfère jouer au solitaire pendant les grosses\ncompilations de C ou de Lisp. J'aime bien examiner des fichiers dans\nle tampon d'un éditeur tout en compilant dans un autre.\n(Le problème serait sans doute moindre si le système de fichiers se\ncontentait de servir des fichiers au lieu d'interagir avec les\nentrées/sorties de terminal).\nÉvidemment, sur du Minix de base, sans consoles virtuelles ni aucune\npossibilité de lancer emacs, ce n'est pas vraiment un problème. Mais\npour la plupart des gens, c'est un inconvénient, pas un avantage. Ce\nn'est pas simplement le fait que sur des machines mono-utilisateur il\nn'y a pas besoin de plus d'un processus actif.\nCette idée n'est envisageable que parce que tant de gens sont habitués\nà des machines médiocres dotées de systèmes d'exploitation médiocres.\nQuant à la portabilité, Minix ne l'emporte que grâce à ses prétentions\nlimitées. Si vous vouliez un Unix complet avec pagination,\nordonnanceur, système de fenêtrage et ainsi de suite, serait-il plus\nrapide de partir d'un Minix de base et d'ajouter ces fonctionnalités,\nou depuis Linux et de s'occuper des spécificités du 386 ? Je ne crois\npas qu'il soit juste de critiquer Linux quand ses objectifs sont si\ndifférents de ceux de Minix. Si on veut un système à but pédagogique,\nMinix est la réponse. Mais s'il s'agit d'avoir un environnement aussi\nproche que possible de celui d'une Sun (par exemple) sur son\nordinateur personnel, il a quelques lacunes.\nDate: 5 Fév 92 14:48:48 GMT\nOrganisation: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam\nDans l'article <6121@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin)\n> Si vous vouliez un Unix complet avec pagination,\n> ordonnanceur, système de fenêtrage et ainsi de suite, serait-il plus\n> rapide de partir d'un Minix de base et d'ajouter ces fonctionnalités,\n> ou depuis Linux et de s'occuper des spécificités du 386 ?\nUne autre option qui semble être totalement oubliée ici est d'acheter\nUNIX ou un clone. Si vous voulez juste UTILISER le système, plutôt que\nde bitouiller dans ses entrailles, vous n'avez pas besoin du code\nsource. Coherent est à seulement 99 $, et il y a plusieurs vrais\nsystèmes UNIX avec plus de fonctionnalités pour plus d'argent. Pour\nle vrai bitouilleur, ne pas avoir le code source est fatal, mais pour\nceux qui veulent juste un système UNIX, il y a beaucoup d'autres options\nDe: ajt@doc.ic.ac.uk (Tony Travis)\nDate: 6 Fév 92 02:17:13 GMT\nOrganisation: Department of Computing, Imperial College, University of London, UK.\n>Une autre option qui semble être totalement oubliée ici est d'acheter\n>UNIX ou un clone. Si vous voulez juste UTILISER le système, plutôt que\n>de bitouiller dans ses entrailles, vous n'avez pas besoin du code\n>source. Coherent est à seulement 99 $, et il y a plusieurs vrais\n>systèmes UNIX avec plus de fonctionnalités pour plus d'argent. Pour\n>le vrai bitouilleur, ne pas avoir le code source est fatal, mais pour\n>ceux qui veulent juste un système UNIX, il y a beaucoup d'autres options\nAndy, j'ai suivi le développement de Minix depuis que les premiers\narticles ont été postés dans ce groupe et emploie actuellement\nla version 1.5.10 avec les correctifs de Bruce Evans pour le 386.\nJe veux 'simplement' un Unix sur mon PC et bitouiller ses entrailles\nne m'intéresse pas, mais je *veux* le code source !\nLa philosophie qui consiste à créer à partir du travail des autres\nest un des grands principes sous-jacents qui explique le succès et la\nCette philosophie repose sur la disponibilité du code source afin\nqu'il puisse être examiné, modifié et réutilisé pour des nouveaux\nIl y a des années de cela, j'étais l'heureux bénéficiaire d'une\nlicence pour le code source Unix AT&T 7ème édition mais, même\nalors, j'ai accueilli votre décision de rendre celui de Minix\ndisponible comme une libération par rapport aux entraves du\ncopyright AT&T !!\nIl me semble que vous devez parfois oublier que votre 'hobby' a eu un\neffet déterminant sur la disponibilité d'un Unix 'personnel'\n(c-à-d financièrement accessible) et que le PC 8086 sur lequel\ntournait Minix 1.2 m'a coûté en fait bien plus que le clone 386/SX\nque j'utilise à présent.\nIl est clair que Minix _n'est pas_ la panacée, mais je vois\nl'évolution vers des versions 386 et le 68000 ou d'autres\narchitectures à espace d'adressage linéaire d'une manière assez\nsemblable : c'est une bonne chose pour les gens comme moi qui\nutilisent Minix et se sentent gênés par l'architecture segmentée\nde la version PC dans le domaine des applications.\nRIEN de ce que vous pouvez dire ne pourrait me convaincre d'utiliser\nDate: 7 Fév 92 14:58:22 GMT\nDans l'article <12696@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum)\n> Si vous voulez juste UTILISER le système, plutôt que de bitouiller\n> dans ses entrailles, vous n'avez pas besoin du code source.\nBeaucoup d'entre nous souhaitent pouvoir bitouiller dans les\nentrailles du système...  Vous serez débarrassé de la plupart d'entre\nnous quand BSD-detox ou GNU sortiront, ce qui devrait arriver dans\nles tous prochains mois (ouais, exactement).\nDe: comm121@unixg.ubc.ca (Louie)\nOrganisation: University of British Columbia, Vancouver, B.C., Canada\nDans <12595@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) écrit :\nIl n'y a réellement pas d'autre choix que Linux pour les gens qui,\ncomme moi, veulent un SE "libre". Considérant que la majorité des\npersonnes susceptibles d'opter pour un SE "libre" utilisent le 386,\nla portabilité n'est vraiment pas un si gros problème. Si j'avais une\nSparc, j'utiliserais Solaris.\nJusqu'ici, j'ai installé Linux avec gcc, emacs 18.57, kermit et tous\nles utilitaires GNU sans le moindre ennui. Nul besoin d'appliquer des\ncorrectifs.  J'ai simplement suivi les instructions d'installation.\nJe ne peux pas trouver un tel SE *n'importe où* au même prix pour\nmes devoirs d'informatique. Et il semble que la gestion du réseau\nainsi que X-Window seront portés sous Linux bien avant Minix.\nC'est quelque chose qui serait vraiment utile. À mon avis, la\nportabilité des programmes Unix standards est également importante.\nJe sais que le concept du système monolithique n'est pas aussi bon\nque celui du micro-noyau. Mais à court terme (et je sais que je ne\nvoudrais/pourrais pas faire évoluer mon 386), Linux me convient\nDe: dgraham@bmers30.bnr.ca (Douglas Graham)\nDate: 1 Fév 92 00:26:30 GMT\nOrganisation: Bell-Northern Research, Ottawa, Canada\n>  Bien que je pourrais me lancer ici dans une longue histoire sur les\n>  mérites relatifs des deux concepts, je me contenterai de dire que\n>  parmi les personnes concevant à l'heure actuelle des systèmes\n>  d'exploitation, la discussion est essentiellement close. Les\n>  micro-noyaux ont gagné.\nPouvez-vous recommander une documentation (sans parti pris)\nqui traite des forces et faiblesses des deux approches ? Je suis\ncertain qu'il y a quelque chose à dire sur l'approche\nmicro-noyau, mais je m'interroge sur la similitude de Minix vis à vis\ndes autres systèmes qui utilisent cette approche. Bien sûr, Minix\nfait appel à beaucoup de tâches et de messages, mais il en faudrait\nplus pour qu'il ait une architecture de micro-noyau. Je suspecte\nque le code Minix ne soit pas découpé en tâches de manière optimale.\n>  micro-noyaux ont gagné. Le seul vrai argument pour les systèmes\n>  monolithiques était la performance, et il est maintenant assez\n>  évident que les systèmes à micro-noyau peuvent être tout aussi\n>  rapides que les systèmes monolithiques (par ex., Rick Rashid a\n>  publié des notes comparant Mach 3.0 à des systèmes monolithiques),\n>  et il ne reste donc maintenant que des détails à régler.\nMon principal grief envers Minix ne concerne pas ses performances.\nAjouter des fonctionnalités est un calvaire - ce que,\nje suppose, une architecture micro-noyau est supposée alléger.\n> MINIX est construit autour d'un micro-noyau. Le système de fichiers\nY a-t-il un consensus à ce sujet ?\n> LINUX est un système de style monolithique. C'est un pas de géant en\n> arrière dans les années 1970. C'est comme prendre un programme C\n> existant et qui marche et le réécrire en BASIC. Pour moi, écrire un\n> système monolithique en 1991 est une idée vraiment médiocre.\nC'est une affirmation pertinente, mais je cherche encore à voir\nune raison d'être pour cela.\nJe crois que Linux consiste seulement en 12000 lignes de codes.\nJe ne vois pas en quoi le diviser en tâches et en messages\nà droite et à gauche l'améliorerait.\n> Ne le prends pas mal, je ne suis pas mécontent de LINUX. Il va amener\n> tous ceux qui veulent faire évoluer MINIX en BSD UNIX derrière moi.\n> Mais en toute honnêteté, je voudrais suggérer à ceux qui veulent un\n> SE "libre" **MODERNE** qu'ils recherchent un SE à\n> micro-noyau, portable, comme peut-être GNU ou quelque chose comme ça.\nBien, il n'y a pas d'autres choix sur lesquels je puisse me porter\nen ce moment. Mais lorsque le SE de GNU viendra, j'aimerais bien\nreprendre ce bateau. Je sens que vous *êtes* quelque peu insatisfait\nde Linux  (et cela me surprend un peu). Je suis enclin à penser\nque la raison pour laquelle tant de personnes s'y intéressent est\nqu'il offre plus de possibilités. Votre approche sur les gens\ndésirant des fonctionnalités dans Minix a été de dire qu'ils n'en\nvoulaient pas vraiment. Je prétends que l'exode vers Linux prouve\nAvertissement : je n'ai rien à voir avec le développement de Linux.\nJe pense simplement que c'est un système plus facile à comprendre\nDoug Graham   dgraham@bnr.ca  Mes opinions sont les miennes propres.\nDe: hedrick@klinzhai.rutgers.edu (Charles Hedrick)\nDate: 1 Fév 92 00:27:04 GMT\nOrganisation: Rutgers Univ., New Brunswick, N.J.\nL'histoire du logiciel montre qu'à chaque fois la disponibilité\nl'emporte sur la qualité technique. Voilà le principal\navantage de Linux. C'est un petit système pour 386,\ntout-à-fait compatible avec l'Unix d'origine, et qui est disponible\nlibrement. J'ai laissé tombé la communauté Minix il y a quelques\nannées quand il devint évident que (1) Minix ne tirerait profit de\nrien à part du 8086 dans le futur proche, et (2) que la licence -\nbien qu'étonnamment bienveillante - le rendait toujours difficile\nd'accès pour ceux qui voudraient produire une version pour le 386.\nApparemment plusieurs personnes ont effectué un bon travail\npour le 386.  Mais elles ne pouvaient distribuer que des fichiers\ndiffs. Cela rend le travail sur un 386 peu pratique pour un nouvel\nutilisateur, et de fait je n'étais pas sûr de vouloir le faire.\nExcusez-moi si les choses ont changé ces dernières années. S'il est\nmaintenant possible d'avoir une version 386 prête à l'emploi,\nla communauté a développé un moyen de distribuer\nles sources Minix, et que  des programmes Unix normaux\nest dorénavant devenu plus facile, alors je reconsidérerai ma\nposition en ce qui concerne Minix. J'aime bien sa conception.\nIl est possible que Linux soit rattrapé par Gnu ou un BSD libre.\nCependant, si le SE Gnu suit l'exemple de tous les autres logiciels\nGnu, il aura besoin de 128 Mo de mémoire et d'un disque de 1 Go. Il\ny aura toujours de la place pour un petit système.\nMon système idéal serait le 4.4 BSD, mais la date de la version du 4.4\na considérablement dérapé dans le temps. Et puis avec toute\nl'équipe migrant vers BSDI, il est difficile de croire que la\nsituation va aller en s'améliorant. Pour mon usage personnel,\nle système BSDI sera certainement très bien. Mais même leur prix\ntrès attractif est vraiment trop élevé pour la plupart de nos\nétudiants, et bien que les utilisateurs puissent en acquérir\nles sources, le fait que certaines soient propriétaires signifie\nencore que vous ne pourrez que mettre du code modifié sur les sites\nFTP accessibles au public.\nDe toutes façons Linux existe et tout le reste n'est que littérature.\nDe: tytso@athena.mit.edu (Theodore Y. Ts'o)\nEn réponse à: message d'ast@cs.vu.nl du 29 Jan 92 12: 12:50 GMT\n>De : ast@cs.vu.nl (Andy Tanenbaum)\n>dans le répertoire minix/simulator). Je pense que c'est une erreur\n>grossière que de concevoir un SE pour une architecture spécifique,\n>alors que celle-ci ne sera bientôt plus disponible.\nCe n'est pas de votre faute si vous croyez que Linux est limité à\nl'architecture 80386, puisque de nombreux adeptes de Linux (y compris\nLinus lui-même) sont partis de ce principe. Néanmoins, la quantité de\ncode spécifique 80386 n'est probablement pas plus importante que dans\nune implémentation Minix, et il n'y a certainement pas plus de code\nspécifique 80386 dans Linux que de code spécifique Vax dans BSD 4.3.\nCeci dit, le portage sur d'autres architectures n'a pas encore été\nréalisé. Mais si je commençais à porter un système de type Unix vers\nune nouvelle architecture, je commencerais probablement par Linux\nplutôt que Minix, simplement parce que je veux avoir un certain\ncontrôle sur ce que je pourrais faire avec le système résultant une\nfois que j'aurais fini.\nOui, j'aurais à réécrire de grandes portions du VM et des couches des\ngestionnaires de périphériques -- mais j'aurais à le faire avec\nn'importe quel SE. Cela serait peut-être un petit peu plus difficile\nque pour porter Minix sur la nouvelle architecture, mais cela ne\nserait probablement vrai que pour la première architecture cible du\nportage de Linux.\n>Bien que je pourrais me lancer ici dans une longue histoire sur les\n>mérites relatifs des deux concepts, je me contenterai de dire que\n>parmi les personnes concevant à l'heure actuelle des systèmes\n>d'exploitation, la discussion est essentiellement close. Les\n>micro-noyaux ont gagné. Le seul vrai argument pour les systèmes\n>monolithiques était la performance, et il est maintenant assez\n>évident que les systèmes à micro-noyau peuvent être tout aussi\n>rapides que les systèmes monolithiques (par ex., Rick Rashid a\n>publié des notes comparant Mach 3.0 à des systèmes monolithiques),\n>et il ne reste donc maintenant que des détails à régler.\nCe n'est pas forcément le cas. Je pense que vous peignez une vue plus\nmanichéenne de l'univers qu'il ne l'est.  Je vous renvoie à des\narticles du genre de celui de Brent Welsh « le système de fichiers\nest intrinsèque au noyau » dans lequel il estime que le système de\nfichiers est une abstraction suffisamment mature pour qu'elle réside\ndans le noyau, et non en-dehors comme ce serait le cas dans une\nconception micro-noyau stricte.\nUn certain nombre de gens sont préoccupés par la rapidité de OSF/1\nMach comparée à celle des systèmes monolithiques ; plus spécialement,\nle nombre de changements de contexte nécessaires à la gestion du\ntrafic réseau, et des systèmes de fichiers réseau en particulier.\nJe connais les bénéfices d'une approche micro-noyau. Néanmoins, le\nfait reste que Linux est là, et que GNU  non - et que les gens ont\ntravaillé sur Hurd beaucoup plus longtemps que Linus n'a travaillé\nMinix ne compte pas parce qu'il n'est pas libre.  :-)\nJe suspecte que le choix entre micro-noyaux et noyaux monolithiques\ndépend de ce que l'on en fait. Si l'on s'intéresse à la recherche, il\nest évidemment bien plus facile de retirer et de remplacer des modules\ndans un micro-noyau, et puisque seuls les chercheurs écrivent des\narticles sur les systèmes d'exploitation, ipso facto les micro-noyaux\ndoivent être la bonne approche.  Néanmoins, je connais des tas de\ngens qui ne sont pas chercheurs, mais au contraire des programmeurs\nnoyau pratiques, dont les préoccupations principales sont dans le\ncoût de copie et de changement de contexte inhérents à un\nPour autant, je n'adhère pas à votre argument selon lequel un système\nde fichiers multi-thread n'est pas nécessaire sur un système\nmono-utilisateur. Une fois lancé un système de fenêtrage, ainsi\nqu'une compilation dans une fenêtre, un lecteur de courrier dans une\nautre et les nouvelles arrivant par UUCP en arrière-plan, il vous\nfaut de bonnes performances du système de fichiers, même sur un\nsystème mono-utilisateur. C'est peut-être une optimisation inutile\naux yeux du théoricien et un bitouillage de performance (pour\nreprendre vos propres termes), mais je m'intéresse à un Vrai système\nd'exploitation - pas à un jouet de chercheur.\nTheodore Ts'o   bloom-beacon!mit-athena!tytso\n308 High St., Medford, MA 02155  tytso@athena.mit.edu\nTous jouent au jeu, mais aucun avec les mêmes règles !\nOrganisation: a blip of entropy\n> MINIX a été conçu pour être raisonnablement portable, et a été porté\n> de la ligne Intel aux 680x0 (Atari, Amiga, Macintosh), SPARC, et\n> NS32016. Linux est attaché de très près au 80x86. C'est une mauvaise\nSi vous regardiez le source au lieu de croire l'auteur, vous\nréaliseriez que ce n'est pas vrai !\nIl a remplacé "fubyte" par une routine qui utilise explicitement un\nregistre de segment - mais cela peut être facilement modifié. De même,\nà part à quelques endroits qui présument la présence d'une MMU 386,\ndeux ou trois macros qui cachent les tailles exactes de pages, etc.\nrendraient triviale la tâche de portage. L'utilisation des TSS 386\nsimplifient le code, mais le VAX et le WE32000 ont des structures\nComme il l'a déjà admis, un peu de planification rendrait le système\nplus propre, mais ce n'est pas un crime de mettre un peu de langage\nd'assemblage 386 ici ou là !\nEt avec tout le respect que je dois :\n- le Livre ne fait pas un but de la portabilité (à part sur\nquelques "#ifdef M8088") ;\n- au moment de sa sortie, Minix dépendait de certaines\n« fonctionnalités » du 8086 qui ont causé l'ire des utilisateurs de\nDe: entropy@wintermute.WPI.EDU (Lawrence C. Foard)\nDate: 5 Fév 92 14:56:30 GMT\nOrganisation: Worcester Polytechnic Institute\n>Ne le prends pas mal, je ne suis pas mécontent de LINUX. Il va amener\n>tous ceux qui veulent faire évoluer MINIX en BSD UNIX derrière moi.\nJe crois que certains points de votre position sont valides, bien que\nje ne sois pas sûr qu'un micro-noyau soit nécessairement meilleur. Il\npeut y avoir plus de sens de permettre une certaine combinaison des\ndeux. Dans le code d'IPC que je suis en train d'écrire pour Linux, je\nvais inclure du code qui permettra aux gestionnaires de périphériques\net aux systèmes de fichiers tourner en mode utilisateur.\nCela sera significativement plus lent malgré tout, et je crois qu'il\nserait une erreur de tout sortir du noyau (TCP/IP sera interne).\nEn réalité, mon principal problème avec les théoriciens des SE est\nqu'ils n'ont jamais testé leurs idées !\nAucune de celles-ci (à l'exception partielle de MACH) n'a jamais vu\nle jour. Les ordinateurs personnels 32 bits sont disponibles depuis\nau moins une décennie et Linus a été le premier à écrire un SE qui\nfonctionne pour eux sans devoir verser 100 000$ à AT&T.\nUn morceau de logiciel en mains vaut mieux que dix logiciels fictifs,\nles théoriciens des SE sautent vite sur un SE mais ne veulent même\npas fournir une autre option.\nLe consensus général que les micro-noyaux sont la direction à prendre\nne veut rien dire tant qu'aucune application réelle n'a fonctionné\nsur l'un d'entre eux.\nLa sortie de Linux me permet d'essayer quelques-unes des idées que je\nsouhaite expérimenter depuis des années, mais je n'avais jamais eu\nl'occasion de travailler avec le code source d'un SE qui\nDate: 5 Fév 92 23:33:23 GMT\nDans l'article <1992Feb5.145630.759@wpi.WPI.EDU>\nentropy@wintermute.WPI.EDU (Lawrence C. Foard) écrit :\n>En réalité, mon principal problème avec les théoriciens des SE est\n>qu'ils n'ont jamais testé leurs idées !\nJe suis mortellement injurié. JE NE SUIS PAS UN THÉORICIEN. Demandez\nà tous ceux qui étaient à la réunion du département hier\nEn fait, ces idées ont été très bien testées en pratique. OSF est en\ntrain de jouer son va-tout sur un micro-noyau (Mach 3.0). USL\njoue son affaire sur un autre (Chorus). Tous deux font tourner de\nnombreux logiciels et ont été intensivement comparés à des\nsystèmes monolithiques. Amoeba a été complètement implémenté et testé\npour un certain nombre d'applications. QNX est bâti autour d'un\nmicro-noyau, et on m'a dit que le parc installé était de 200 000\nsystèmes. Les micro-noyaux ne sont pas des châteaux en Espagne. Ils\nreposent sur une approche éprouvée.\nLes gars de Mach ont écrit un papier appelé « UNIX comme programme\napplicatif ». C'était de Golub et al., durant la conférence USENIX de\nl'été 1990. Les gens de Chorus ont eux aussi un rapport technique sur\nles performances des micro-noyaux, et je suis co-auteur d'un autre\npapier sur le sujet, que j'ai mentionné hier (Computing Systems de\nDéc. 1991). Jetez-y un œil.\nDe: peter@ferranti.com (peter da silva)\nDate: Xenix Support, FICC\nOrganisation: Jeu, 6 Fév 1992 16:02:47 GMT\nDans l'article <12747@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum)\n> QNX est un système à micro-noyau, et on m'a dit que le parc\n> installé était de 200 000 systèmes.\nAh, oui, tant que je suis sur le sujet... il y a plus de 3 millions\nd'Amiga dans la nature, ce qui veut dire qu'il y en a plus que ce que\nn'importe quel constructeur d'UNIX a vendu, et probablement plus que\ntous les systèmes UNIX combinés.\nOrganisation: Jeu, 6 Fév 1992 16:00:22 GMT\n> En réalité, mon principal problème avec les théoriciens des SE est\n> qu'ils n'ont jamais testé leurs idées !\nJe m'inscris en faux... il y a de nombreux systèmes à micro-noyau\ndans la nature pour tout depuis un 8088 (QNX) jusqu'à de grands\n> Aucune de celles-ci (à l'exception partielle de MACH) n'a jamais vu\n> le jour. Les ordinateurs personnels 32 bits sont disponibles depuis\n> au moins une décennie et Linus a été le premier à écrire un SE qui\n> fonctionne pour eux sans devoir verser 100 000$ à AT&T.\nJe dois avoir rêvé AmigaOS, alors. J'ai utilisé un produit de mon\nimagination durant les 6 dernières années.\nAmigaOS a une conception de passage de messages de micro-noyau, avec\nun temps de réponse et des performances meilleurs que tout autre\nsystème d'exploitation pour PC disponible : y compris\nMINIX, OS/2, MS-Windows, MacOS, Linux, UNIX, et *certainement* MS-DOS.\nLa conception micro-noyau a prouvé sa valeur incalculable. Des choses\ncomme de nouveaux systèmes de fichiers disponibles en principe\nseulement auprès de leur constructeur sont des produits de l'activité\nde loisirs sur l'Amiga. Les pilotes de périphériques sont simplement\ndes bibliothèques partagées avec des points d'entrée spécifiques et\ndes ports de messages.  Il en est de même pour les systèmes de\nfichiers, le système de fenêtrage, etc. C'est une conception\nMERVEILLEUSE, qui valide tout ce que les gens ont pu dire sur les\nmicro-noyaux. Oui, cela représente un plus gros travail de les faire\ndécoller qu'un macro-noyau fondé sur les co-routines comme UNIX,\nmais la souplesse vous le rembourse plusieurs fois.\nJe souhaite vraiment qu'Andy fasse un nouveau MINIX fondé sur ce qui\na été appris depuis la première sortie. La construction des\nresponsabilités dans MINIX est assez pauvre, mais le concept de base\n> Le consensus général que les micro-noyaux sont la direction à prendre\n> ne veut rien dire tant qu'aucune application réelle n'a fonctionné\n> sur l'un d'entre eux.\nJe rêve encore. J'ai sûrement imaginé que Deluxe Paint, Sculpt 3d,\nPhoton Paint, Manx C, Manx SDB, Perfect Sound, Videoscape 3d, et les\nautres programmes que j'ai achetés étaient « réels ». Je vais avoir à\nrenvoyer ces sacrés trucs, je pense.\nLa disponibilité de Linux est une excellente chose. Je suis ravi qu'il\nexiste. Je suis sûr que sa conception macro-noyau est une des raisons\nde son implémentation si rapide, et c'est une raison valable\nd'utiliser ceux-ci. MAIS... cela ne veut pas dire que les micro-noyaux\nsoient intrinsèquement lents, ni de simples jouets de chercheurs.\nDe: dsmythe@netcom.COM (Dave Smythe)\nDate: 10 Fév 92 07:08:22 GMT\nOrganisation: Netcom - Online Communication Services (408 241-9760 guest)\n>Aucune de celles-ci (à l'exception partielle de MACH) n'a jamais vu\nDavid Cheriton (Prof. à Stanford, et auteur du systemV) disait\nquelque chose de similaire dans son cours de systèmes distribués.\n« Il y a deux types de chercheurs : ceux qui ont implémenté quelque\nchose et ceux qui ne l'ont pas fait. Ces derniers vous diront qu'il\ny a 142 manières de faire les choses et qu'il n'y a pas de\nconsensus sur la meilleure. Les premiers vous diront simplement que\n141 d'entre elles ne fonctionnent pas. »\nIl tire aussi sur les ISO-philes, pour des raisons similaires. Les\nprotocoles Internet ne sont adoptés qu'après avoir été utilisés\npendant un certain temps, ce qui évite de standardiser des choses qui\nne seront jamais implémentables de manière raisonnable. Les adhérents\nà l'ISO, d'un autre côté, semblent tenter de standardiser tout ce qui\nest possible, y compris les « évasions » du standard, avant qu'une\nimplémentation raisonnable de référence existe. En conséquence, on\ntrouve immortalisées des idées dépassées, telles que le paquet de\nchamps de données de niveau infra-octet, ce qui rend difficile de\nréaliser de bonnes performances lorsque votre ordinateur est alimenté\npar une lance d'incendie à plus de 10 Gbit/s :-)\nJuste mes  0,02 $\nSujet: Excuses (était Re : LINUX est dépassé)\nDans l'article <1992Jan29.231426.20469@klaava.Helsinki.FI>\n>Bien, avec un sujet tel que celui-ci, j'ai bien peur de devoir\nEt j'ai répondu, je me suis laissé aller, sans une pensée pour\nle bon goût et la netiquette. Pardon à ast, et merci à John Nall\npour sa lettre « ce n'est pas comme ça que l'on fait ». Je me suis\nemporté, et je vais composer maintenant une lettre personnelle\n(beaucoup moins acerbe) à ast. J'espère que personne ne se\ndétournera de linux parce qu'il est (a) peut-être dépassé (je\npense toujours que ce n'est pas le cas, bien que certaines critiques\nsoient valables) et (b) qu'il a été écrit par une tête brûlée :-)\nLinus « mon premier, et j'espère mon dernier festival\nincendiaire » Torvalds\nDe: pmacdona@sanjuan (Peter MacDonald)\nSujet: Re: Linux est dépassé\nDate: 1 Fév 92 02:10:06 GMT\nOrganisation: University of Victoria, Victoria, BC, CANADA\nDepuis, je pense, que j'ai posté l'un des messages précédents dans\ntoute cette discussion sur Linux contre Minix, je me sens obligé de\ncommenter mes raisons de basculer de Minix vers Linux.  Par\nordre d'importance, elles sont :\n1) Linux est gratuit ;\n2) Linux évolue de manière satisfaisante (car les nouvelles\nfonctionnalités sont acceptées dans la distribution par Linus).\nLa première nécessite quelques explications, puisque si j'ai déjà\nacheté Minix, en quoi le prix peut-il me concerner ?  Simple. Si\nle système d'exploitation est gratuit, beaucoup plus de gens vont\nl'utiliser/le maintenir/l'améliorer. C'est aussi le raisonnement que\nj'ai tenu lorsque j'ai acheté mon 386 au lieu d'une SPARC (que\nj'aurais pu avoir pour seulement 30% de plus). Depuis que les PC sont\nbon marché et partout disponibles, de plus en plus de gens les\nachètent/ les utilisent et ainsi, le logiciel bon marché/gratuit est\nLa seconde doit être assez évidente pour quiconque a utilisé\nMinix durant un certain temps.  AST n'accepte généralement pas\nd'améliorations à Minix.  Ce n'est pas destiné à être un challenge,\nmais seulement un fait.  AST a de bonnes et légitimes raisons pour\ncela, et je ne les discute pas.  Mais Minix a quelques limitations\navec lesquelles je ne peux plus continuer à vivre, et à cause de\ncette position, l'hypothèse de les voir résolues dans un temps\nraisonnable n'est pas satisfaisante.  Parmi ces limitations, il y a :\npas de gestion des instructions 386 ;\npas de console virtuelle ;\npas de liens symboliques ;\npas d'appel select ;\npas de pseudo-terminal ;\npas de pagination à la demande/pagination disque/\ntexte partagé/bibliothèque partagée (mm efficace)...\nchmem (mm inflexible) ;\npas de X-Window (pour les mêmes raisons que celles invoquées\npour Linux et les 386) ;\npas de TCP/IP ;\npas d'intégration GNU/SysV (portabilité) ;\nCertaines de ces limitations peuvent être levées par des correctifs\n(et si vous l'avez réalisé vous-même, je n'ai pas besoin de vous\ndire la satisfaction que cela procure), mais au moins les cinq\nderniers points étaient/sont hors de toute attente raisonnable.\nFinalement, mon commentaire (ma saillie ?) sur l'architecture en\nnoyau segmenté, ou micro-noyau de Minix était plus une\nexpression de ma frustration/désorientation dans ma tentative\nd'utilisation des correctifs de pseudo-terminaux de Minix\ncomme un guide sur la manière de le réaliser sous Linux.  Cette\nfonction particulière était une de celles pour lesquelles le passage\nde messages en rendait l'implémentation vraiment complexe.\nJ'ai une opinion sur le sujet Monolithique contre passage de messages,\nmais je ne vais pas l'exprimer maintenant, et je n'ai pas songé à le\nfaire jusqu'à présent.  Mes buts sont totalement à court terme\n(fonctionnalités maximales et temps/coût/effort minimaux), c'est\npourquoi mes vues ne sont pas appropriées, et ne doivent pas être\nmal interprétées.  Si le manque des fonctionnalités ci-dessus ne vous\ngêne pas, alors vous devez prendre Minix en considération (si cela\nne vous gêne pas de payer bien sûr :).\nDe: olaf@oski.toppoint.de (Olaf Schlueter)\nDate: 7 Fév 92 11:41:44 GMT\nOrganisation: Toppoint Mailbox e.V.\nJuste quelques commentaires sur la discussion Linux contre Minix,\nqui devient en partie une discussion monolithique contre micro-noyau.\nJe pense qu'il n'y aura pas d'accords entre les tenants de chacun de\nces concepts, s'ils oublient que Linux et Minix ont été conçus pour\ndes utilisations différentes. Si vous voulez un système Unix\nabordable, puissant et évolutif sur une machine unique, avec la\npossibilité d'adapter des logiciels Unix sans difficulté, alors Linux\nest fait pour vous.  Si vous vous intéressez aux concepts des systèmes\nd'exploitation modernes, et que vous voulez apprendre comment\nfonctionne un micro-noyau, alors Minix est le meilleur choix.\nCe n'est pas un argument contre le système micro-noyau, que pour\nl'instant les implémentations monolithiques d'Unix sur PC aient de\nmeilleures performances.  Cela veut simplement dire qu'Unix est\npeut-être mieux implémenté en monolithique, au moins tant qu'il\ns'exécute sur une seule machine.  Du point de vue des utilisateurs,\nla conception interne du système n'a aucune importance.  Jusqu'à\nce qu'il soit en réseau.  Selon l'approche monolithique, un serveur\nde fichiers deviendra un processus utilisateur qui s'appuie sur un\nmatériel quelconque comme Ethernet. Les programmes qui\nsouhaitent utiliser ce support devront utiliser des bibliothèques\nspécifiques qui offrent les appels de communication avec ce serveur.\nDans un système micro-noyau il est possible d'incorporer tout le\nserveur dans le système sans qu'il soit besoin de « nouveaux » appels\nsystème. Du point de vue de l'utilisateur c'est un avantage, car rien\nne change, il bénéficie juste de meilleures performances (en termes\nd'augmentation d'espace disque, par exemple). Du point de vue\nde l'implémenteur, le micro-noyau est plus rapidement adaptable\nà des modifications de la conception matérielle.\nIl a été critiqué qu'AST rejette toute amélioration à Minix.  Puisque\nson intérêt est dans la valeur éducative de Minix, je comprends cet\nargument de vouloir conserver la simplicité du code, et de ne pas\nvouloir le surcharger de fonctionnalités.  En tant qu'outil éducatif,\nMinix est écrit comme un système micro-noyau, bien qu'il fonctionne\nsur des plates-formes qui se comporteraient probablement mieux\navec un système monolithique.  Mais la zone d'influence des\napplications réseau croît et des systèmes modernes comme Amoeba\nou Plan 9 ne peuvent être écrits sous forme monolithique. Ainsi\nMinix a-t-il été écrit dans l'intention de donner aux étudiants un\nexemple pratique d'un système micro-noyau, pour qu'ils puissent\njouer avec les tâches et les messages.  Ce n'était pas l'idée de\nfournir à de nombreuses personnes un système économique et\npuissant pour le dixième du prix d'implémentations SYSV ou BSD.\nRésumé : Linux n'est pas meilleur que Minix, ni le contraire. Ils\nsont différents pour de bonnes raisons.\nDe: meggin@epas.utoronto.ca (David Megginson)\nSujet: Mach/Minix/Linux/Gnu etc.\nDate: 1 Fév 92 17:11:03 GMT\nOrganisation: University of Toronto - EPAS\nBien, c'était une chouette discussion. Je suis totalement convaincu\npar le professeur Tanenbaum qu'un micro-noyau _est_ la direction à\nprendre, mais plus je regarde dans le source de Minix, moins je crois\nque ce soit un micro-noyau.  Je ne m'occuperai sans doute pas du\nportage de Linux sur le M68000, mais je souhaite plus de services\nque Minix puisse offrir.\nQuid d'un micro-noyau compatible MACH au niveau message/appel\nsystème ? Il n'a pas en fait besoin de faire tout ce que fait MACH,\ncomme la pagination virtuelle de mémoire, il doit juste _avoir l'air_\nde MACH depuis l'extérieur, pour tromper des programmes comme le\nfutur émulateur Unix Gnu, BSD, etc.\nCela prolongerait un peu la vie utile de nos machines sur M68000 ou\nsur 286. Dans l'intervalle, je vais probablement rester sous Minix\navec mon ST plutôt que repasser à MiNT après tout, Minix au moins\nressemble à Unix, alors que MiNT ressemble au TOS en essayant de\nressembler à Unix (il est bien obligé d'être compatible TOS).\nSujet: Que rapporte cette guerre? (Re : LINUX est dépassé)\nDate: 3 Fév 92 16:37:24 GMT\nOrganisation: Xenix Support, FICC\nAllez-vous arrêter de vous descendre en flamme les uns les autres ?\nJe veux dire par là que linux est conçu pour fournir un environnement\nayant d'assez bonnes performances sur un matériel handicapé par des\nannées passées à traîner le boulet de la compatibilité ascendante.\nMinix est conçu comme outil d'enseignement. Il n'est pas bon de faire\nle travail d'un autre, et pourquoi le ferait-il ? Le fait que Minix\ns'essouffle rapidement (et c'est vrai) n'est pas un problème dans\nson milieu de prédilection. Il est sûrement meilleur que le système\nd'exploitation JOUET. Le fait que Linux ne soit pas transposable sur\nd'autres plates-formes que le 386/AT ne pose pas problème car on en\ntrouve des millions ici-bas (et vraiment pas chers : vous pouvez\ntrouver un 386/SX en dessous de 1000 dollars).\nUn noyau monolithique est assez facile à fabriquer, ce qui vaut le\ncoup si cela permet au système de sortir rapidement. Considérez-le\ncomme une économie de travail pour le temps du programmeur.\nL'API est portable.\nVous pouvez remplacer le noyau par un autre ayant la conception\nmicro-noyau (et en matière de conception de micro-noyau MINIX ne\nreprésente pas le top du top, même pour des PC d'entrée de gamme...\nvoyez l'AmigaOS) sans perturber les applications.\nC'est tout l'intérêt d'avoir une API portable au départ.\nLes micro-noyaux sont certainement ce qu'il y a de mieux pour\nbeaucoup de choses. Cela demande plus de travail pour en améliorer\nl'efficacité, et dès lors une conception plus simple, ne tirant\nréellement pas partie des avantages du micro-noyau est préférable,\nsi on veut le faire pour des raisons pédagogiques. Pensez que c'est\nune économie de temps pour les étudiants. Le concept est toujours bon\net lorsqu'il est possible d'avoir une interface de programmation\nd'applications pour le micro-noyau on peut obtenir une amélioration\nTRÈS impressionnante (des milliers de commutations par seconde avec\nun 68000 8 MHz).\nSujet: Campeurs mécontents\nDate: 3 Fév 92 22:46:40 GMT\nJ'ai récemment reçu quelques courriers de campeurs mécontents\n(en fait 10 messages venant des 43000 lecteurs pourraient paraître\nbeaucoup, mais ça ne l'est pas réellement).\nIl semble en ressortir trois points :\n1. Les noyaux monolithiques sont tout aussi bien que les micro-noyaux\n2. La portabilité n'est pas si importante\n3. Les logiciels devraient être gratuits\nSi quelqu'un veut avoir une discussion sérieuse entre micro-noyaux et\nnoyaux monolitiques, très bien. Nous pouvons le faire sur\ncomp.os.research. Mais par pitié ne venez pas faire de bruit si vous\nn'avez aucune idée de ce dont vous parlez. J'ai aidé à concevoir et\nimplémenter 3 systèmes d'exploitation, un monolithique et deux micro,\net étudié beaucoup d'autres en détail. Beaucoup des arguments proposés\nne valent rien (par exemple, les micro-noyaux ne sont pas bons car on\nne peut pas faire de pagination au niveau utilisateur - alors que Mach\nFAIT de la pagination au niveau utilisateur).\nSi vous ne connaissez pas grand-chose à propos de la discussion\nmicro-noyaux contre noyaux monolithiques, il existe quelques\ninformations utiles dans un article que j'ai écrit en collaboration\navec Fred Ouglis, Frans Kaashoek et John Ousterhout dans le numéro de\nDéc. 1991 de COMPUTING SYSTEMS, le journal USENIX). Si vous n'avez pas\nce journal, vous pouvez FTPer l'article depuis ftp.cs.vu.nl\n(192.31.231.42) dans le répertoire amoeba/papers sous comp_sys.tex.Z\n(source TeX compacté) ou comp_sys.ps.Z (PostScript compacté).\nL'article donne des mesures de performances actuelles et appuie la\nconclusion de Rick Rashid comme quoi les systèmes à\nmicro-noyaux sont tout aussi efficaces que les noyaux monolithiques.\nÀ propos de la portabilité, il n'y a plus de discussion possible. UNIX\na été porté sur tout depuis les PCs jusqu'aux Crays. Écrire un SE\nportable n'est pas beaucoup plus dur qu'un non portable, et tous les\nsystèmes doivent être écrits en gardant à l'esprit la portabilité de\nnos jours. Le professeur de SE de Linus l'a sûrement signalé. Faire un\nSE portable n'est pas quelque chose que j'ai inventé en 1987.\nAlors que l'on peut rationnellement parler de la conception du noyau\net de la portabilité, la question de la gratuité est 100%\némotionnelle. Vous ne pourrez pas croire à quel point j'ai été\ndernièrement [juron supprimé] au sujet de la non gratuité de MINIX.\nMINIX coûte 169$, mais la licence permet de faire deux copies de\nsauvegarde, le prix effectif peut donc être de moins de 60$. De\nplus, les professeurs peuvent en faire des copies ILLIMITÉES pour\nleurs étudiants. Coherent coûte 99$. FSF facture plus de 100$ pour\nles bandes sur lesquelles sont fournies son logiciel\n« gratuit » si vous n'avez pas d'accès à l'Internet, et je\nn'ai jamais entendu personne se plaindre. 4.4 BSD coûte 800$. Je ne\npense vraiment pas que l'argent soit la question. D'ailleurs, il est\nprobable que la plupart des lecteurs de ce forum l'ont déjà.\nUne opinion, que je pense tout le monde ne partage pas, est que de\nrendre quelque chose disponible par FTP n'est pas nécessairement le\nmoyen de fournir la plus large distribution. L'Internet est toujours\nun groupe hautement élitiste. La plupart des utilisateurs\nd'ordinateurs n'y sont PAS.  J'ai compris d'après PH que le pays où\nMINIX est le plus utilisé est l'Allemagne, et non les USA,\nprincipalement parce qu'un des magazines informatiques (commercial)\nallemand l'a activement appuyé. MINIX est aussi très utilisé en\nEurope de l'Est, au Japon, Israël, Amérique du Sud, etc. La plupart\nde ces gens ne l'auraient jamais obtenu s'il n'y avait eu une\nentreprise pour le vendre.\nPour revenir à ce que « libre » veut dire, qu'en est-il du code source\nlibre ? Coherent est binaire seulement, mais MINIX a le code source,\nexactement comme LINUX. Vous pouvez le changer comme vous le désirez,\net poster ici les changements. Tout le monde l'a fait pendant 5 ans\nsans problèmes. J'ai aussi donné des mises à jours gratuites pendant\nJe pense que la question réelle est quelque chose d'autre. Je me suis\nvu offrir de façon répétée mémoire virtuelle, pagination, liens\nsymboliques, systèmes de fenêtrage, et toutes sortes de\nfonctionnalités. J'ai en général refusé car j'essaie toujours de\ngarder le système assez simple pour qu'il soit compris par des\nétudiants. Vous pouvez mettre toutes ces choses dans votre version,\nmais je ne les mettrais pas dans la mienne. Je pense que c'est ce\npoint qui ennuie les gens qui disent que « MINIX n'est pas libre », pas\nUne question intéressante est de savoir si Linus est prêt à laisser\nLINUX devenir « libre » de son contrôle. Quelqu'un peut-il\nle modifier (le ruiner ?) et le vendre ? Souvenez-vous des centaines\nde messages avec le sujet « Re : Votre logiciel vendu pour de\nl'argent » lorsqu'il a été découvert que le centre MINIX en\nAngleterre vendait des disquettes avec des articles de news,\nplus ou moins au prix coûtant ?\nSupposez que Fred van Kempen revienne et veuille prendre le relais, en\ncréant un LINUX Fred et un LINUX Linus, tous deux utiles mais\ndifférents. Est-ce ok ? La question se pose lorsqu'un groupe assez\ngrand de personnes veut faire évoluer LINUX d'une manière que Linus ne\nveut pas. Avant que ça n'arrive, la question reste néanmoins sur le\nSi vous préférez la philosophie de Linus à la mienne, bien sûr,\nsuivez-le, mais par pitié ne prétendez pas que vous faites ça parce\nque Linux est « libre ». Dites simplement que vous voulez\nun système  avec un tas de fonctionnalités. Très bien. C'est votre\nchoix. Je n'ai pas d'argument contre ça. Dites juste la vérité.\nEn aparté, pour ces gens qui ne lisent pas les en-têtes des news,\nLinus est en Finlande et je suis aux Pays-Bas. Atteignons-nous une\nsituation où une autre industrie critique, le logiciel libre, qui a\nété totalement dominée par les USA est en train de céder la place à la\nconcurrence étrangère ? Verrons-nous bientôt arriver le Président Bush\nen Europe avec Richard Stallman et Rick Rashid à la remorque,\ndemandant que l'Europe importe plus de logiciels libres Américains ?\nSujet: Re : Campeurs mécontents\nDate: 5 Fév 92 23:23:26 GMT\nDans l'article <205@fishpond.uucp> fnf@fishpond.uucp (Fred Fish)\n>Si PH ne s'était pas octroyé le monopole de la distribution, il\n>aurait été possible pour tous les bitouilleurs minix intéressés\n>d'organiser et de mettre en place un groupe qui se serait consacré\n>à produire un minix amélioré. Le but de ce groupe aurait été de\n>produire une unique version vivante de minix avec toutes les\n>améliorations couramment demandées. Cela aurait permis à minix\n>d'évoluer un peu de la même manière que gcc a évolué durant ces\nCeci EST possible. Si un groupe de personnes veut le faire, c'est très\nbien. Je pense que coordonner 1000 prima donnas vivant tout autour du\nmonde sera aussi facile que de mener des chats en troupeau, mais il\nn'y a pas de problème légal. Lorsqu'une nouvelle version est prête, il\nsuffit de faire un fichier diff par rapport à la 1.5 et le poster ou\nle rendre disponible par FTP. Bien que cela requiert quelque travail\nde la part des utilisateurs pour l'installer, ce n'est pas tant de\ntravail. D'ailleurs, j'ai des scripts shell pour créer les diffs et\nles installer. C'est ce que Fred van Kempen faisait. Ce qu'il a fait\nde mauvais est d'insister sur le droit de publier la nouvelle version,\nplutôt que les diffs par rapport à la base de PH. Ceci mettait PH\nhors course, ce qui, rien d'étonnant, ne les emballait pas. Si des\npersonnes veulent toujours le faire, qu'elles le fassent.\nBien sûr, je ne vais pas nécessairement appliquer tous ces\nchangements à ma version, il y a donc du travail pour garder la\nversion officielle et celles qui sont améliorées en synchro, mais je\nsuis disposé à coopérer pour minimiser le travail. Je l'ai fait\npendant longtemps avec Bruce Evans et Frans Meulenbroeks.\nSi Linus veut garder le contrôle de la version officielle, et qu'un\ngroupe d'acharnés veulent continuer dans une direction différente, le\nmême problème arrive. Je ne pense pas que le droit de copie soit\nréellement le problème. Le problème est de coordonner les choses. Des\nprojets comme GNU, MINIX, ou LINUX tiennent debout seulement si une\npersonne en a la charge. Durant les années 1970, lorsque la\nprogrammation structurée a été introduite, Harlan Mills signala que\nl'équipe de programmation devait être organisée comme une équipe\nchirurgicale (un chirurgien et ses assistants), et non comme une\néquipe de bouchers (donnez à chacun un morceau et laissez-les hacher\nQuiconque disant que l'on peut avoir un grand nombre de personnes\ntrès dispersés bitouillant sur une même partie complexe de code\net éviter l'anarchie totale n'a jamais dirigé un projet logiciel.\n>Où est le groupe important de personnes désirant fair évoluer gcc\n>d'une manière que rms/FSF n'approuve pas ?\nUn compilateur n'est pas une chose pour laquelle les gens ont un grand\nattachement émotionnel. Si le langage à compiler est une donnée (par\nexemple, une norme ANSI), il n'y a pas de place pour que quiconque\ninvente de nouvelles fonctionnalités. Un système d'exploitation a des\noccasions illimitées pour que des personnes implémentent leurs\nDate: 6 Fév 92 10:33:31 GMT\nDans l'article <12746@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum)\n>Si Linus veut garder le contrôle de la version officielle, et qu'un\n>groupe d'acharnés veulent continuer dans une direction différente, le\n>même problème arrive.\nC'est la seconde fois que je vois cette « accusation » de la part de\nast, qui trouve malin de faire des commentaires sur un noyau qu'il\nn'a probablement jamais vu. Ou tout au moins il ne m'a jamais\nquestionné, ou bien lu alt.os.unix sur le sujet. Seulement pour que\npersonne ne prenne ses suppositions comme vérité première, voici ma\nposition sur « la prise de contrôle », en 2 mots (ou trois ?) :\nLe seul contrôle que je garde effectivement sur linux est que je\nle connais mieux que quiconque, et que j'ai fait en sorte que mes\nchangements soient disponibles sur les sites ftp, etc. Ceux-ci sont\ndevenus des versions officielles et je ne m'attends pas à ce que cela\nchange pour quelque temps : non pas parce que j'estime que j'ai un\ndroit moral sur lui, mais je n'ai pas entendu trop de\nréclamations et il se passera beaucoup de mois avant que je ne puisse\ntrouver des gens ayant le même « feeling » au sujet du\nnoyau.  (Bon, peut-être certains y arrivent : tytso a effectué\nassurément des changements significatifs même jusqu'au 0.10, et\nd'autres l'ont bitouillé également).\nDans les faits, j'ai lancé quelques ballons d'essai sur une liste\nde diffusion « noyau-linux » qui prendraient les décisions sur les\nmises à jour, et je m'attends à ce que je ne puisse pas apporter\ntoutes les fonctionnalités qui /devront/ être\najoutées : SCSI etc, car je ne dispose pas du matériel. Le résultat\nfut négatif : les gens ne semblent pas pressés de changer à l'heure\nactuelle. (oui, quelqu'un a pensé que je devrais demander aux\nalentours des dons pour pouvoir développer le logiciel nécessaire\n- et si quelqu'un a du matériel intéressant, je serai heureux de\nLa seule chose que le copyright interdise (et je pense que cela est\néminemment raisonnable) est que d'autres personnes commencent à se\nfaire de l'argent avec et ne fournissent pas les sources, etc.\nCe n'est pas une question de logique, mais je le vivrais mal si\nquelqu'un venait à vendre mon travail pour de l'argent, alors que\nje l'avais rendu disponible exprès afin que tout le monde puisse\ns'amuser comme il l'entend.  Je pense que la plupart des gens\ncomprennent mon point de vue.\nCeci mis à part, si Fred van Kempen veut faire un super-linux, il est\ntout-à-fait le bienvenu. Il ne se fera pas beaucoup d'argent avec\n(hormis les frais de distribution), et je ne pense pas que ce soit\nune bonne idée de diviser linux, mais je ne voudrais pas arrêter\nmême si le copyright me le permet.\n>Je ne pense pas que le droit de copie soit\n>réellement le problème. Le problème est de coordonner les choses. Des\n>projets comme GNU, MINIX, ou LINUX tiennent debout seulement si une\n>personne en a la charge.\nOui, la coordination est un gros problème, et je ne pense pas\nque je quitterai le poste de « chirurgien chef » pour linux avant\nlongtemps, en partie parce que la plupart des gens\ncomprennent ces problèmes. Mais le copyright /est/ une solution :\nsi on sent que je fais du mauvais boulot, ils peuvent le faire\neux-mêmes. Tout comme pour gcc. Le copyright de minix, cependant,\nsignifie que si quelqu'un a le sentiment qu'il peut faire un\nmeilleur minix, soit il doit faire des patches (qui ne sont pas\nsi gros quoi que vous ayez dit à ce sujet) ou démarrer à partir\nde rien (et être attaqué car vous avez d'autres idéaux).\nLes patches ne sont pas très drôles à diffuser : je n'ai pas encore\nfait de cdiff pour une seule version de linux (j'espère que ça\nchangera : bientôt les patches seront beaucoup plus\npetits que le noyau et faire à la fois les patches et une version\ncomplète deviendra une bonne idée - notez que j'ai toujours donné\naussi la version complète).  Faire des patches sur des patches est\nsimplement impraticable, spécialement pour les personnes pouvant\neffectuer les changements elles-mêmes.\n>>Où est le groupe important de personnes désirant faire évoluer gcc\n>>d'une manière que rms/FSF n'approuve pas ?\n>Un compilateur n'est pas une chose pour laquelle les gens ont un grand\n>attachement émotionnel. Si le langage à compiler est une donnée (par\n>exemple, une norme ANSI), il n'y a pas de place pour que quiconque\n>invente de nouvelles fonctionnalités. Un système d'exploitation a des\n>occasions illimitées pour que des personnes implémentent leurs\nBien, il y a GNU emacs... Ne nous dites pas que les gens n'ont pas\nde relation émotionnelle avec leurs éditeurs :)\nDe: dmiller@acg.uucp (David Miller)\nSujet: Linux est dépassé et messages suivants\nDate: 3 Fév 92 01:03:46 GMT\nEn tant qu'observateur intéressé dans la conception de systèmes, je ne peux\nrésister à cette enfilade.  Rendez-vous compte que je ne suis pas réellement\nexpérimenté avec minux ni linux. Je suis avec unix depuis de\nnombreuses années.  Tout d'abord, quelques observations :\nMinix fut écrit pour être un outil éducatif pour les classes d'AST,\npas un système d'exploitation commercial. Il n'a jamais été un\nparamètre de conception de le faire fonctionner en code source\nlibrement disponible pour les systèmes unix.  Je pense qu'il était\naussi une présentation de la manière dont les systèmes d'exploitation\ndoivent être conçus, avec un micro-noyau et des processus séparés\ncouvrant autant de fonctionnalités que possible.\nLinux fut écrit essentiellement en tant qu'exercice d'apprentissage\nde la part de Linus comment programmer la famille 386.  La conception\ndu système d'exploitation ultime n'était pas un objectif. Fournir une\nplate-forme utilisable, libre, qui puisse exécuter toutes sortes de\nlogiciels libres partout disponibles fut une considération, et\nc'est une de celles qui apparaît avoir été remplie au mieux.\nLa critique de qui que ce soit considérant que l'un de ces systèmes\nn'est pas ce que *lui* aurait voulu qu'il soit est déplacée. Après\ntout, quiconque possédant un ordinateur capable d'exécuter l'un ou\nl'autre de ces systèmes est libre de réaliser lui-même ce que Linus\net Andrew ont écrit !\nMoi, pour ce que je suis, j'applaudis Linus pour son effort\nconsidérable dans le développement de Linux et dans sa décision\nde le rendre libre pour tous.  J'applaudis AST pour son effort pour\nrendre minix accessible. J'ai un gros problème par rapport aux\nremarques sur l'aspect non-libre de minix. Si vous pouvez trouver\nle temps d'explorer minix et un système d'ordinateur de base,\n150 dollars ne sont pas grand-chose et vous avez en plus un livre\nEnsuite, quelques questions pour le professeur :\nMinix est-il supposé être un « vrai système\nd'exploitation » ou un outil éducatif ?\nEn tant qu'outil éducatif, c'est un excellent travail. En tant que\nvrai système d'exploitation, il présente quelques manques\nterriblement gênants (pourquoi pas de malloc() ?, juste pour les\ndébutants). Mon impression à la lecture du Livre et des\nmessages qui passent ici est que vous vouliez un outil pour enseigner\nen classe, et que de nombreux autres souhaitaient jouer avec un\nsystème d'exploitation accessible.  Ces autres ont tenté de lui\ngreffer suffisamment de fonctions pour en faire un « vrai système\nd'exploitation » , avec un succès moins éclatant.\nPourquoi séparer les fonctions fondamentales du SE, telles que la\ngestion mémoire, dans des processus utilisateurs ? Comme le savent\ntous les bons gourous *nix, la voie du succès est de diviser pour\nrégner, avec pour but de *simplifier* le problème en composants\ngérables, bien définis. Si le découpage des éléments de base du\nsystème d'exploitation en processus de l'espace utilisateur complique\nla fonction en y introduisant des mécanismes additionnels (passage de\nmessages, signaux compliqués), avons-nous atteint l'objectif de\nsimplifier la conception et l'implémentation ?\nJe suis d'accord que *nix a souffert d'un mauvais niveau de\nfonctionnalités et particulièrement sysVr4. Peut-être\nles fonctions que les gens veulent pour telle ou telle fonctionnalité\nou compatibilité peuvent-elles être offertes par des\nmodules/bibliothèques chargeables dynamiquement ?\nLe micro-noyau serait toujours un gestionnaire de ressources de bas\nniveau capable de router les demandes de fonctions au module ou à la\nbibliothèque approprié. Les modules peuvent être des threads ou des\nprocessus utilisateurs (je pense. Bitouilleurs de systèmes, corrigez-moi :-) ).\nJuste la valeur de mes 0,04 dollars. N'hésitez pas à m'envoyer\nvos réponses ici ou par la messagerie électronique. Je n'ai pas de\nformation traditionnelle en informatique, et je pose donc réellement\nces questions naïvement. Je suppose qu'un tas d'autres sur le Net\nont des questions similaires en tête, mais je me suis déjà trompé.\nDe: michael@gandalf.informatik.rwth-aachen.de (Michael Haardt)\nSujet: 1.6.17 résumé et pourquoi je pense qu'AST a raison.\nDate: 6 Fév 92 20:07:25 GMT\nRépondre à: u31b3hs@messua.informatik.rwth-aachen.de (Michael Haardt)\nOrganisation: Gandalf - a 386-20 machine\nIl y a quelques temps, j'ai demandé des détails sur la prochaine\nversion de MINIX (1.6.17).\nJ'ai obtenu quelques réponses, mais seulement de gens utilisant\nla 1.6.16. Les informations qui suivent sont officieuses et peuvent\nêtre erronées, mais elles sont tout ce que j'en sais actuellement.\nCorrigez-moi si quelque chose est faux.\n-  Les correctifs 1.6.17 s'appliqueront sur la 1.5 fournie par PH ;\n-  Les fichiers d'en-tête sont propres ;\n-  Les deux types de systèmes de fichiers peuvent être utilisés\n-  La gestion des signaux est réécrite pour POSIX. Le vieux bogue\nest supprimé ;\n-  Le compilateur ANSI (disponible auprès de Transmediar, je crois)\nest fourni avec les binaires du compilateur et de nouvelles\n-  Le protocole réseau d'Amoeba ne semble pas pris en charge ;\n-  times(2) renvoit une valeur correcte.  termios(2) est implémenté,\nmais c'est surtout une bitouille. Je ne sais pas si « implémenté »\nveut dire dans le noyau ou l'émulation actuelle ;\n-  Le nouveau système de fichiers n'est pas documenté. Il y a de\nnouveaux fsck et mkfs, pas d'infos sur cela ;\n-  Le compilateur ANSI travaille mieux sur les flottants ;\n-  L'ordonnanceur est amélioré, mais pas aussi bien écrit que celui de\nJ'ai demandé cela pour appuyer sur des faits ma décision de migrer\nvers MINIX 1.6.17 ou vers Linux après la fin des examens. Eh bien\ncelle que j'ai prise est de migrer vers Linux à la fin du mois et de\nretirer MINIX de mon disque lorsque Linux fera tourner tous les\nlogiciels dont j'ai besoin qui tournent actuellement sous MINIX 1.5\navec des correctifs lourds.  J'imagine que cela pourra prendre deux\nmois au plus. Voici les principales raisons de ma décision :\n-  Il n'y a pas de version « en cours » de MINIX qui puisse être\nutilisée comme base de correctifs, et personne ne connaît la date\nd'arrivée de la 1.6.17 ;\n-  La bibliothèque contient un certain nombre de bogues, et d'après\nce que j'ai entendu, ils ne sont pas en cours de correction.  Il n'y\naura pas de nouveau compilateur, et les utilisateurs en 16 bits\ncontinuent à devoir utiliser les ACK bogués ;\n-  1.6.17 doit se rapprocher de POSIX, mais il manque encore un\ntermios complet ;\n-  Je doute qu'il y ait encore beaucoup de développements pour les\nutilisateurs en 16 bits.\nJe pense cesser de maintenir la liste des logiciels MINIX dans\nY a-t-il quelqu'un par ici qui veuille le continuer ?  Jusqu'à ce que\nLinux tourne *parfaitement* sur ma machine, toutes les mises à jour\nd'Origami continueront à fonctionner en MINIX 16 bits. J'annoncerai\nlorsque la dernière de ces versions apparaîtra.\nÀ mon avis, AST a raison dans sa décision concernant MINIX.  J'ai lu\nla guerre incendiaire et ne peux m'empêcher de dire que j'aime MINIX\ncomme il est, par rapport à l'état actuel de Linux. MINIX a quelques\n-  Vous pouvez commencer à jouer avec sans disque dur, et même\ncompiler des programmes.  Je l'ai fait il y a quelques années ;\n-  Il est si petit qu'il n'est pas nécessaire d'en savoir beaucoup\npour avoir un petit système qui fonctionne correctement ;\n-  Il y a le livre. Ok, seulement pour la version 1.3, mais le plus\ngros est toujours valide ;\n-  MINIX est un exemple de noyau non monolithique. Appelez-le\nmicro-noyau ou bitouille pour contourner une architecture débile :\nIl démontre un concept, avec ses pour et ses contre - un concept\nPour moi, c'est un bon système pour les premiers pas dans UNIX et la\nprogrammation système. J'ai appris l'essentiel de ce que je sais sur\nUNIX avec MINIX, dans tous les domaines, depuis la programmation en C\nsous UNIX jusqu'à l'administration système (et les trous de sécurité).\nMINIX a grandi avec moi : mises à jour 1.5.xx, consoles virtuelles,\ncourrier et nouvelles, traitement de texte, compilation croisée, etc.\nMaintenant, il est trop petit pour moi. Je n'ai plus besoin d'un\nsystème pour l'enseignement, je voudrais un UNIX plus complexe et\nplus complet, et il y en a un : Linux.\nÀ l'époque, v7 était l' « état de l'art ». Il y avait MINIX qui en\noffrait le plus gros. En un ou deux ans, POSIX est devenu ce qu'on a\nl'habitude de voir. Espérons qu'il y aura MINIX, offrant le plus gros,\navec un nouveau livre, pour ceux qui veulent un petit système pour\njouer et expérimenter.\nCessez de vous incendier, MINIX et Linux sont deux systèmes différents\navec des buts différents. L'un est un outil d'enseignement (et un bon,\nje pense), l'autre est un vrai UNIX pour les vrais bitouilleurs.\nDe: dingbat@diku.dk (Niels Skov Olsen)\nSujet: Re : 1.6.17 résumé et pourquoi je pense qu'AST a raison.\nDate: 10 Fév 92 17:33:39 GMT\nOrganisation: Department of Computer Science, U of Copenhagen\nmichael@gandalf.informatik.rwth-aachen.de (Michael Haardt) écrit :\n>Cessez de vous incendier, MINIX et Linux sont deux systèmes différents\n>avec des buts différents. L'un est un outil d'enseignement (et un bon,\n>je pense), l'autre est un vrai UNIX pour les vrais bitouilleurs.\nOyez, oyez ! Et maintenant, les articles sur Linux sont dans\nalt.os.linux (ou comp.os.misc si vous ne recevez pas la hiérarchie\nalt.*) et ceux sur Minix ici.\nfin (festival d'incendies noyé :-)\nN.d.T. : mot utilisé dans la VO.\nPerspectives Version 1.0 de la définition de l'Open Source de Bruce Perens


Wiko View 3 Archives - Comment réparer\nÉtiqueté : Wiko View 3\nComment faire un copier-coller sur Wiko View 3 Le copier-coller sur Wiko View 3 peut réduire considérablement votre temps de travail, notamment en vous évitant de recopier un texte à la main. Nous vous montrons ici comment copier et coller avec votre Wiko View 3. Voici les étapes pour faire un copier-coller (ou « copier coller ») sur votre Wiko View 3. Tout d’abord, ouvrez un texte au hasard, que...\nNFC sur Wiko View 3\nLe NFC sur Wiko View 3 Qu’est-ce que le NFC ? La communication en champ proche ou NFC (en anglais: Near-Field Communication) est un ensemble de protocoles, permettant à deux appareils électroniques (généralement des appareils mobiles, comme votre Wiko View 3) de communiquer entre eux à quelques centimètres de distance. Le NFC a de multiples applications, comme le paiement ou les échanges de fichiers avec votre Wiko View...\nComment mettre une sonnerie personnalisée sur votre Wiko View 3 Nous allons vous montrer à travers cet article comment mettre une sonnerie personnalisée sur votre Wiko View 3, notamment si cette sonnerie vient d’un MP3. Encore mieux, nous vous indiquerons comment éditer vos morceaux MP3 préférés sur votre Wiko View 3. Par exemple, il se peut que vous souhaitiez retenir uniquement le refrain de votre musique préférée pour...\nComment récupérer des SMS ou textos effacés sur votre Wiko View 3 ? Il arrive très fréquemment de supprimer les SMS ou textos de votre Wiko View 3 car l’utilité de les garder semble faible.Ce cas peut arriver soit parce que vous n’avez plus de place sur la mémoire de votre appareil ou bien car vous devez effectuer une suppression totale de vos données sur votre Wiko View...\nUn guide pour réaliser une saisie d’écran sur Wiko View 3 Réaliser sa capture d’écran sur Wiko View 3 est sûrement très pratique si vous avez le souhait de garder en mémoire un topo de la commune, ou encore vous permettre d’envoyer les plus récentes notes dans un fichier, ou juste faire quelques sauvegardes.C’est en outre un bon moyen de faire des sauvegardes Instagram, Snapchat, Facebook, WhatsApp et...\nCe que vous devriez savoir pour désactiver internet et les données sur Wiko View 3 Que vous soyez dans un avion ou plus simplement en famille, pour que vous puissiez ne pas être importuné par vos notifications et autres, il se pourrait que vous souhaitiez enlever internet sur votre Wiko View 3, ou plus complètement couper ses émissions d’ondes.Vous allez voir : c’est très simple à faire lorsque...\nComment transformer en télécommande votre Doro Primo 413\nTransférer vos photos de votre Landvo Xm100 vers votre PC\nComment enlever le vibreur clavier sur Wiko Lubi 5\nComment activer et utiliser le GPS sur Siemens SXG75\nComment activer et utiliser le GPS sur Sony Ericsson G705\nComment configurer un partage de connexion sur Archos Sense 50X