Articles : La paternité de Linux discutée
Posté par Colin Leroy (page perso, ). Modéré le 21 mai 2004.
Selon l'AdTI, il est probable que Linus Torvalds ne soit pas l'inventeur (sic) de Linux : il l'aurait écrit beaucoup trop vite pour avoir pu l'avoir fait tout seul.
Linus Torvalds a répondu de manière plutôt humoristique à ces accusations, avouant qu'en réalité il couvrait "le Père Noël et la petite Souris" ; expliquant par là même l'origine du premier nom de Linux, "Freax" : le père Noël et la petite Souris se sentent incompris.
Quelques jours plus tard, Andrew Tannenbaum, interviewé par Kenneth Brown pour cette étude, a publié une page sur son site, expliquant comment s'était passée son interview et pourquoi, selon lui, la crédibilité d'AdTI est proche de zéro.
Andrew Tanenbaum est l'auteur de Minix, un autre clone d'Unix qui a servi à Linus Torvalds d'inspiration et, initialement, de plate-forme de développement pour Linux. Toutefois, il n'y a pas trace de Minix dans le source de Linux, si ce n'est dans les noms de fichiers.
![[en]](../images/en.png)
Le scoop (2012 hits)-
L'aveu de Linus Torvalds (3680 hits)
-
La réponse d'Andrew Tanenbaum (2986 hits)
-
Le site d'AdTI (étude non accessible) (791 hits)
-
La dernière nouvelle sur slashdot (1105 hits)
> Lire la dépêche (204 commentaires, moyenne: 2,9).
Vous avez demandé le commentaire #416723.
Run by 
Cette page a été générée par Templeet en 0.2446s (dont 0.0201 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Andrew Tannenbaum en gentleman !
> On peut aussi noter, dans l'article d'Andrew Tannenbaum, qu'il n'a pas encore réellement pardonné à Linus Torvalds d'avoir choisi un design monolithique pour Linux.
Il n'empêche qu'il ne profite abolument pas de la situation pour revendiquer une quelconque paternité de Linux et qu'il reconnait tous les mérites de Linus dans Linux.
Un vrai gentleman.
> il n'a pas encore réellement pardonné
Il n'a pas à pardonner. Linus ne l'a pas torturé ou trahi...
[^]Re: Andrew Tannenbaum en gentleman !
Et puis il pense que le choix d'un noyau monolithique aurait été plus judicieux. Donc il le dit, tout simplement.
Sacrée personnalité.
Every takeoff is optional. Every landing is mandatory. -- Rules Of Flying
[^]Re: Andrew Tannenbaum en gentleman !
Non, c'est le contraire. Il pense encore que les micro-noyaux sont mieux.... comme le Hurd.
Non ne souriez pas, le Hurd sera peut être le successeur de Linux dans une vingtaine d'années avec des processeurs conçus autrement.
Dans le cas présent, Linux est le mieux adapté à son environnement et c'est lui qui gagne. C'est comme en biologie.
La diversité est une richesse et la meilleure garantie pour l'avenir.
Il n'y a pas de bonne solution dans l'absolu, il n'y a que des solutions adaptées ou non à leur environnement et c'est Linux qui était le mieux adapté quand il a été créé.
[^]Re: Andrew Tannenbaum en gentleman !
oui bien sûr, désolé pour l'inversion de terme. la fangue avait lourché.
Every takeoff is optional. Every landing is mandatory. -- Rules Of Flying
[^]Re: Andrew Tannenbaum en gentleman !
et pourquoi faire uml? ce n'est pas un peu le même principe que le hurd?
y a-t-il des distributions avec le hurd industrialisé (je ne veux pas dire "disponible" mais "utilisable en entreprise") ?
est ce que les bonnes idées du hurd ne sont pas reprises dans linux?
et dernière question:
C'est comme en biologie.
La diversité est une richesse et la meilleure garantie pour l'avenir.
que va trouver dame nature pour rediversifier l'homme?
[^]Re: Andrew Tannenbaum en gentleman !
UML ?
Est-ce que tu peux préciser ce que tu entends pas UML ?
[^]Re: Andrew Tannenbaum en gentleman !
User Mode Linux ?
[+] [^]Re: Andrew Tannenbaum en gentleman !
ben oui uml pas uml !
:)
on n'est pas sur java.sun.com ici?
je m'a gouré d'adresse?
De manière très macroscopique, il me semble que l'idée du Hurd de séparer les services ressemble un peu du point de vue des applicatifs (je prends mon pare-flammes) à la possibilité de lancer plusieurs noyaux, même si l'architecture des OS n'est pas la même.
[^]Re: Andrew Tannenbaum en gentleman !
UML <> Java
Tu peux faire de l'UML sans faire de Java. Et vice-versa, dieu merci.
Non, rien.
[^]Re: Andrew Tannenbaum en gentleman !
>> Il n'a pas à pardonner. Linus ne l'a pas torturé ou trahi...
Il a quand même eu l'audace de faire le noyau d'un os aujourd'hui vachement utilisé, même si pas assez, en se basant sur une architecture qu'il annonce depuis toujours comme obsolète et dangereuse.
Je suis pas apte à dire s'il a raison, mais pour l'instant en tout cas nos plateforme tournent dessus, pas sur hurd ni sur le noyau de minix...
[^]Re: Andrew Tannenbaum en gentleman !
Hmm, je veux pas remuer le couteau, mais le principe du noyau évoqué par Mr Tannenbaum est appliqué dans les versions NT de Microsoft, donc on peut dire que son concept fonctionne.
Après c'est sûr que niveau performance et stabilité, on a connu bien mieux que NT4 ;)
Bon et puis pour faire un peu de pub (en a-t-il besoin ?) pour ce grand Homme qu'est Tannenbaum, je recommande chaudement à celles et ceux qui veulent comprendre un peu mieux le fonctionnement d'un OS, de se procurer *la* bible des OS: "Systèmes d'exploitation". Tout simplement génial !!
[^]Re: Andrew Tannenbaum en gentleman !
Hmm, je veux pas remuer le couteau, mais le principe du noyau évoqué par Mr Tannenbaum est appliqué dans les versions NT de Microsoft, donc on peut dire que son concept fonctionne.
NT4 n'est pas un micro-kernel au sens de Tannenbaum vu que les drivers sont en kernel space, de ce point de vue il est comme Linux.
Si tu veux voir un vrai micro-kernel, va jeter un oeil du cote de QNX, et la, ben les utilisateurs font assez confiance a QNX pour le laisser jouer dans les elements sensibles des centrales nucleaires et navettes spatiales...
Architecturalement c'est clair et net, un micro-kernel est plus sur qu'un kernel monolithique, ca veut pas dire qu'il est 100% sur, mais qu'a la base le risque de crash fatal a qualite de code comparable est plus faible du simple fait que la quantite de code pouvant faire tomber le systeme est plus faible
[^]Re: Andrew Tannenbaum en gentleman !
NT4 n'est pas un micro-kernel au sens de Tannenbaum vu que les drivers sont en kernel space, de ce point de vue il est comme Linux.
Ha? je savais pas, on m'a parlé récemment d'exo-kernel, est-ce le cas de Win2000? Quelle différence avec un micro-kernel?
Toutefois Tannenbaun n'a t'il pas un peu influencé Linus? Linux aujourd'hui est bien modulaire (pas complètement ok la mm par exemple est toujours en dur), cela l'éloigne quand même un peu d'un système monolithique tel que DOS non?
De même pour rebondir sur un message precédent du thread, je ne pense pas que HURD - même si conceptuellement il semble être idéal - puisse être le systeme libre de l'avenir. La réalitée du terrain me fait plutôt croire que Linux changera de nouveau pour satisfaire les attentes de la communautée. Mais bon je ne suis pas Elisabeth Thessier ;) ...
[^]Re: Andrew Tannenbaum en gentleman !
>Ha? je savais pas, on m'a parlé récemment d'exo-kernel, est-ce le cas de Win2000? Quelle différence avec un micro-kernel?
C'est assez simple en fait, le noyau NT a tout du design d'un micro-kernel, les elements a l'interieur sont clairement separes en differentes entites(executive, memory manager, scheduler,...), la seule difference, c'est que ces choses la tournent en mode kernel.
Bref, c'est un design de micro-kernel, mais ce n'en est pas un, c'en etait presque un avant NT4, mais meme la c'etait pas un micro-kernel au sens ou Tannenbaum l'entend(cad quasiment rien en kernel space).
Toutefois Tannenbaun n'a t'il pas un peu influencé Linus? Linux aujourd'hui est bien modulaire (pas complètement ok la mm par exemple est toujours en dur), cela l'éloigne quand même un peu d'un système monolithique tel que DOS non?
Moi perso je ne vois rien de modulaire au kernel Linux, qu'on puisse charger/decharger les modules ne rend pas le kernel plus proche d'un micro-noyau. C'est un element tout a fait normal pour un OS de pouvoir charger/decharger un driver.
On peut pas comparer Linux a DOS, tout simplement car sous DOS il n'y a pas de reelle separation entre kernel et le reste.
De même pour rebondir sur un message precédent du thread, je ne pense pas que HURD - même si conceptuellement il semble être idéal - puisse être le systeme libre de l'avenir. La réalitée du terrain me fait plutôt croire que Linux changera de nouveau pour satisfaire les attentes de la communautée. Mais bon je ne suis pas Elisabeth Thessier ;) ...
Ben je suis persuade aussi que HURD, si il existe un jour dans un etat utilisable, ne remplacera pas Linux, et cela pour une raison simple :
Les gens s'en foutent d'avoir 99.9999% d'uptime plutot que 99.99%
C'est important pour les centrales nucleaires, les navettes spatiales et les fans d'informatique qui aiment dire qu'ils ont l'OS le plus stable ou l'OS avec l'architecture la plus "propre", mais 99% de la planete s'en fout, ce qui fait que 99% de la planete ne va pas echanger 10% de perfs en moins pour qqe chose dont elle se fiche
[^]Re: Andrew Tannenbaum en gentleman !
Pas Linux ?La seule diffèrence, pour ce que j'en sais, pourrais être l'absence d'une interface généraliste dans le cas de Linux. Mais à ce que j'avait cru comprendre de grands progrès ont été accomplis dans ce domaine, là où c'était nécessaire (HAL).
Respect à RMS.
[^]Re: Andrew Tannenbaum en gentleman !
Ben c'est pas vraiment la HAL, la HAL ca sert pour la portabilite principalement.
Le kernel, a l'interieur est vraiment separe en plusieurs composants distincts et independants, avec leurs interfaces pour communiquer, etc..
Dans Linux, de ce que j'en ai vu(bref, jusqu'aux pre-2.4), la separation entre les elements et leur interactions n'etait pas aussi claire.
C'est pas forcement un mal, remarque, vu que Linux n'a pas et n'a jamais eu pour vocation d'avoir une architecture en micro-kernel un jour, c'est surtout une question de choix de design.
[^]Re: Andrew Tannenbaum en gentleman !
Un des problemes de l'approche micro-noyau avec des entites parfaitement isolees tournant en user-space telle que la voit Tanenbaum, c'est que la complexite augmente enormement, notamment en terme de communication et de debuggage.
C'est pas pour rien que Hurd a 5 ans de retard sur Linux, c'est parce que c'est beaucoup beaucoup plus complique d'ecrire un kernel de cette facon. Hurd etait commence avant Linux (2 ans avant si je me souviens bien) mais de l'aveu de RMS << we never thought it would take so long to debug the thing >>.
phil.freehackers.org
[^]Re: Andrew Tannenbaum en gentleman !
"Un des problemes de l'approche micro-noyau avec des entites parfaitement isolees tournant en user-space telle que la voit Tanenbaum, c'est que la complexite augmente enormement, notamment en terme de communication et de debuggage."
En terme de debuggage, au contraire, chaque élément est indépendant, je pense que c'est plus facile à débugger.
Au niveau complexité de communication, oui, y'a notamment des pertes de performance, mais y'a moyen que ça soit acceptable (micro-noyaux de nouvelle génération L4)
"C'est pas pour rien que Hurd a 5 ans de retard sur Linux, c'est parce que c'est beaucoup beaucoup plus complique d'ecrire un kernel de cette facon."
Heu, si le Hurd a du "retard" (je mets entre guillemets, parce que c'est vrai que le Hurd est encore très loin d'être stable et utilisable, mais il a aussi certains concepts qui ne sont pas prêts d'être dans Linux, c'est deux trucs différents, le but du Hurd est pas de devenir dans 5 ans ce que Linux est aujourd) sur Linux, je pense que c'est aussi en bonne partie du au fait qu'il y a *beucoup* plus de monde à bosser sur Linux... Le fait que ce soit plus compliqué, j'en suis pas persuadé. Plus compliqué au début, peut-être (il a fallu faire un effort de conception, contrairement à Linux), mais à maintenir après, je crois pas.
"Hurd etait commence avant Linux"
Le Hurd a commencé à être conçu avant (IIRC), mais niveau codage, ce n'est pas le cas. De plus il a été "suspendu" pendant un certain nombre d'années... Faudrait pas croire qu'il y a eu autant de developpeurs qui ont codé sur le Hurd et pendant autant d'années que sur Linux.
[^]Re: Andrew Tannenbaum en gentleman !
Ben je suis persuade aussi que HURD, si il existe un jour dans un etat utilisable, ne remplacera pas Linux, et cela pour une raison simple :
Les gens s'en foutent d'avoir 99.9999% d'uptime plutot que 99.99%
Je ne vois pas vraiment la cause a effet : Si on prend a l'extreme ton exemple, Linux ne marchera jamais, car Windows leur suffit amplement, et Linux n'a rien de plus, il aurait des choses en moins (drivers, jeux...). Ceux qui disent que Windows c'est pas libre et payant, la c'est sûr ils se trompe de cible : le libre leur apporte rien à eux, et le prix personne le paye directement.
Hurd pourrait remplacer Linux simplement car les developpeurs n'auront pas envie de s'embeter a maintenier deux noyaux (un pour les sytemes sensibles, l'autre pour le grand public), qu'une majorité de developpeurs passera a Hurd, et que donc Linux veilliera en terme de fonctionnalités. Il remplacera au fur et a mesure Linux, comme Linux rempalce au fur et a mesure Solaris, HPUX, Microsoft Windows etc... actuellement.
[^]Re: Andrew Tannenbaum en gentleman !
Je ne vois pas vraiment la cause a effet : Si on prend a l'extreme ton exemple, Linux ne marchera jamais, car Windows leur suffit amplement, et Linux n'a rien de plus, il aurait des choses en moins (drivers, jeux...).
D'apres toi pourquoi est-ce qu'ici tant de gens se plaignent que ceux qu'ils essayent de convertir de Windows a Linux leur repondent qu'ils s'en battent les c**illes ? Parce que ce qu'ils ont leur va tres bien et qu'ils ne voient aucune raison de changer.
Hurd pourrait remplacer Linux simplement car les developpeurs n'auront pas envie de s'embeter a maintenier deux noyaux (un pour les sytemes sensibles, l'autre pour le grand public), qu'une majorité de developpeurs passera a Hurd, et que donc Linux veilliera en terme de fonctionnalités
La realite est que 95% des developpeurs sont sur Linux, meme pas 5% sur Hurd et que l'evolution de ces nombres n'est pas en faveur du Hurd, tout comme l'evolution du support hardware, software, commercial,...
[^]Re: Andrew Tannenbaum en gentleman !
C'est amusant, en reprenant ta dernière phrase et en remplaçant développeur par utilisateur, Linux par Windows et Hurd par Linux ça marche aussi ;)
La realite est que 95% des utilisateurs sont sur Windows, meme pas 5% sur Linux et que l'evolution de ces nombres n'est pas en faveur de Linux, tout comme l'evolution du support hardware, software, commercial,...
[^]Re: Andrew Tannenbaum en gentleman !
non çà marche pas. Sinon, pourquoi microsoft ferait tant de tapage pour décridibiliser l'open source? C'est bien que les variations des chiffres sont en faveur des systèmes gnu, non?
[^]Re: Andrew Tannenbaum en gentleman !
Oui mais la chance du hurd dans son malheure c'est que grace a la GPL il peut toujours recuperer certainnes des innovations ou du travail effectué sur le support materiel de linux pour lui.
Vive la GPL :-)
Il relève de la responsabilité du lecteur de contrôler, par tous moyens, l'adéquation du message à ses besoins et de s'assurer qu'il ne causera pas de dommages aux personnes et aux biens.
[^]Re: Andrew Tannenbaum en gentleman !
A voir... Hurd est certainement en "GPL v2 or later", tandis que Linux est en GPL v2 tout court (grande pomme de discorde entre Torvalds et la FSF).
[^]Re: Andrew Tannenbaum en gentleman !
«Ben je suis persuade aussi que HURD, si il existe un jour dans un etat utilisable, ne remplacera pas Linux, et cela pour une raison simple :
Les gens s'en foutent d'avoir 99.9999% d'uptime plutot que 99.99%»
Pour le peu que j'en sais, la stabilité du Hurd n'est pas son unique avantage. Par exemple l'intégration de serveur ftp ou d'archive dans le système de fichier, etc..
Hurd pourra devenir très attrayant, même pour l'utilisateur «moyen», si des applications utilisant ces nouvelles fonctionnalités, se développent.
Qui peut prévoir le futur...
[^]Re: Andrew Tannenbaum en gentleman !
C'est plus la peine car ce genre de service est deja integre a Gnome ou KDE (sous KDE, fish: -> ssh, ftp: -> ftp, smb: -> samba, ...).
A mon avis HURD n'arrivera jamais a prendre car ses avantages sur Linux sont trop minimaux pour justifier de changer de systeme. Malgre ses problemes, linux fait bien son boulot et pour l'instant, HURD le fait moins bien. Quand bien meme il le ferai un peu mieux, ca ne suffirait pas encore. Pour accrocher les gens, il faut plus qu'une superiorite de conception.
phil.freehackers.org
[^]Re: Andrew Tannenbaum en gentleman !
Il n'est pas question que ces accès soient transparents au niveau de l'application mais au niveau du "système". Il y a une grosse différence. De plus ton bel exemple ne sert pas à grand chose sur un serveur de fichier.
C'est sûr que l'utilisateur lambda se moquera de the Hurd comme de sa première paire de chausettes : ce qu'il a lui suffit. Mais un admin y verra sans doute une différence flagrante qui le fera passer à the Hurd.
Linux ou the Hurd ? l'avenir nous le dira ...
De toute façon, ce dont j'ai besoin, c'est d'un environnement GNU.
[^]Re: Andrew Tannenbaum en gentleman !
Je suis pas sur qu'un «utilisateur lambda» puisse être satisfait d'accéder à des ressources d'une certaine manière sous KDE, d'une autre sous Gnome et encore d'autres façons sous les innombrables applications qui existent et qui ne font partie ni de Gnome, ni de KDE. (et je ne parle pas même pas du shell: ls, cp, rm,...)
Comparé à ce que promet Hurd, c'est du bricolage.
[^]Re: Andrew Tannenbaum en gentleman !
Rien a voir.
Les manieres d'y acceder sont differentes car il y a plusieurs implementations differentes, rien ne t'empeche d'ecrire un composant qui soit utilise par KDE, Gnome, ... et la t'auras la meme technique d'acces.
Hurd ne promet rien de plus niveau capacites, c'est plutot au niveau de la methode d'implementation, et ca les gens s'en foutent.
[^]Re: Andrew Tannenbaum en gentleman !
«[...] rien ne t'empeche d'ecrire un composant qui soit utilise par KDE, Gnome [...]»
Dans le cas de Hurd, il s'agit de système de fichier montable, et donc transparent pour toutes applications, y compris les applis non-Gnome ou KDE, et les applis du shell (fileutils, etc..)
En revanche, pour utiliser les composants KDE ou Gnome, il faut que les applications ai été écrite pour.
«[...]
Hurd ne promet rien de plus niveau capacites, c'est plutot au niveau de la methode d'implementation, et ca les gens s'en foutent.
[...]»
Je pense que les non informaticiens préféreront accéder à toutes leurs ressources par le biais d'une arborescence unique, plutôt qu'en nommant les différents protocoles «ftp:/», «smbfs:/», etc...
[^]Re: Andrew Tannenbaum en gentleman !
Rien de moins évident, pour les non-informaticiens.
Sous Windows, rien que pour les partoches locales, ils utilisent déjà des noms différents (a:\, c:\, d:\ ....), alors je ne parle pas du reste !
(En fait si, on peut en parler, puisque c'est déjà le bordel : "http://...(...)", "\groupe\hôte\partage\...bla...." ... )
Alors non, les non-informaticiens feront comme toujours : ils feront ce qu'"on" leur dit de faire (en général, "on" = Microsoft), et ils en seront contents, en tout cas, pas assez mécontents pour aller voir ailleurs.
A côté de ça, je pense que les VFS proposés par KDE ou Gnome sont plutôt cohérents .... ah si seulement toutes les applis pouvaient se mettre d'accord sur un standard !
Sinon, avez-vous regardé du côté de LUFS, module du noyau qui permet de charger des gestionnaires de systèmes de fichiers en userland, si je ne m'égare pas ? Cette solution m'a l'air plutôt élégante et se rapproche de l'optique du micro-noyau et de sa horde de serveurs (en tout cas pour les gestionnaires de systèmes de fichiers).
[^]Re: Andrew Tannenbaum en gentleman !
Alors non, les non-informaticiens feront comme toujours : ils feront ce qu'"on" leur dit de faire
J'ajouterai même que les non-informaticiens continueront à cliquer sur leurs jolies icones-raccourcis vers les protocoles ou pseudo-protocoles (system://, smb:///, etc.).
[^]Re: Andrew Tannenbaum en gentleman !
Yeps. De ce que j'ai compris, fuse fait la meme chose que lufs:
http://wiki.kdenews.org/tiki-index.php?page=KIO+Fuse+Gateway(...)
Maintenant, j'aimerai voir l'avantage extra-ordinaire que va proposer hurd par rapport a ce systeme, qui va justifier la migration de tous les postes linux vers les postes HURD.
phil.freehackers.org
[^]Re: Andrew Tannenbaum en gentleman !
Les gens s'en foutent d'avoir 99.9999% d'uptime plutot que 99.99%
Mouais...Pour Monsieur tout le monde, c'est sur, mais pour les sociétés, le SLA depends justement du nombre de 9 apres la virgule.
[^]Re: Andrew Tannenbaum en gentleman !
Linux aujourd'hui est bien modulaire (pas complètement ok la mm par exemple est toujours en dur),
Modulaire et microkernélisé, ça n'est pas trop la même chose. Si tu regarde bien, le boot de Minix, c'est le chargement en mémoire d'une seule image contenant tout l'OS: le kernel proprement dit, le gestionnaire de mémoire, le système de fichiers...
cela l'éloigne quand même un peu d'un système monolithique tel que DOS non?
Bah non, pas tant que ça, MS-Dos aussi pouvait charger des modules (en général des pilotes de périphériques) dans le kernel au boot. Je le sais, j'en ai écrit dans le temps. Bien sur, on ne pouvait pas les décharger par la suite, mais le mécanisme était assez similaire.
Mes deux millicentimes...
( Zzzzzzzzz... )
[^]Re: Andrew Tannenbaum en gentleman !
Hmm, je veux pas remuer le couteau, mais le principe du noyau évoqué par Mr Tannenbaum est appliqué dans les versions NT de Microsoft, donc on peut dire que son concept fonctionne.
Tanenbaum lui-même dit qu'il ne considère pas NT (3 et suivants) comme un micro-noyau. C'est dans l'article pointé par la dépêche...
[^]Re: Andrew Tannenbaum en gentleman !
Oui, mais NT est un système à micro-noyau dont l'architecture s'est effondrée. Si la HAL (Hardware Abstraction Layer) existait encore et était en bon état, NT et XP seraient compilables et disponibles sur toutes les architectures. Il n'en est rien et il est clair que c'est parce que beaucoup d'entorses ont été faites. Ceci explique pourquoi NT a subi un gros échec sur Alpha, Mips, PowerPC. Comme disait le directeur de Digital : "Pourquoi continuer ? Avec alpha, processeur 64 bits, nous essayons d'émuler un intel 32 bits. C'est forcément moins bien et c'est plus cher".
En effet, si la HAL était encore une réalité chez Microsoft, on trouverait Windows sur toutes les architectures. Mais ce n'est pas le cas. Le code binaire indépendant de l'architecture et reposant sur une couche de bas niveau comme la HAL ou de plus haut niveau comme la machine Java est typiquement une stratégie issue du monde propriétaire.
Linux, avec son code ouvert, se compile sur la machine cible, quelle qu'elle soit et offre les meilleures performances. Donc, après le code portable qui voulait se substituer au code spécifique, le logiciel libre a répondu avec la portabilité du code source. Il semble que ce soit un aboutissement.
[^]Re: Andrew Tannenbaum en gentleman !
Oui, mais NT est un système à micro-noyau dont l'architecture s'est effondrée. Si la HAL (Hardware Abstraction Layer) existait encore et était en bon état, NT et XP seraient compilables et disponibles sur toutes les architectures.
La HAL est toujours la, et NT et XP sont compilables sur plein d'architectures, ils ne sont simplement pas compiles.
En passant, la HAL n'a RIEN a voir avec le fait d'etre un micro-noyau
Il n'en est rien et il est clair que c'est parce que beaucoup d'entorses ont été faites. Ceci explique pourquoi NT a subi un gros échec sur Alpha, Mips, PowerPC
Ca n'a rien a voir, et je te l'ai deja dit, mais tu ne comprends toujours pas ou fait expres de ne pas comprendre.
Supporter un systeme pour 2% des gens alors que 98% utilise autre chose, ca n'en vaut pas la peine, ca ne rapporte pas assez tout simplement vu les frais(support, test des systemes,...).
Linux, avec son code ouvert, se compile sur la machine cible, quelle qu'elle soit et offre les meilleures performances
Les meilleures performances ? Va mettre Linux sur un systeme a 32 cpu, on en reparlera apres...
[^]Re: Andrew Tannenbaum en gentleman !
Les meilleures performances ? Va mettre Linux sur un systeme a 32 cpu, on en reparlera apres...
Avec un 2.6, je veux bien en parler.
[^]Re: Andrew Tannenbaum en gentleman !
pbpg est resté en pre-2.4
c'est écrit plus haut!
faut pas répondre!
[+] [^]Re: Andrew Tannenbaum en gentleman !
Ben vas-y donc, montre moi les resultats.
[^]Re: Andrew Tannenbaum en gentleman !
va sur http://www.sgi.com/servers/altix/(...) et tu découvrira un superordinateur avec 256 processeurs itanium tournant sous linux.....rigolo non ?
c'est quoi déja les superordinateurs scientifiques sous Windows ?
[^]Re: Andrew Tannenbaum en gentleman !
oups j'avais pas lu en-dessous.
[^]Re: Andrew Tannenbaum en gentleman !
"Les meilleures performances ? Va mettre Linux sur un systeme a 32 cpu, on en reparlera apres... "
comme sur ce genre de machine ?
http://www.linuxjournal.com/article.php?sid=6440(...)
A noter l'utilisation de NUMAflex une evolution de CrayLink, dont le support à été porté de IRIX à Linux en un temps record.
d'ailleurs maintenant ils font du 256 CPU, ca commence a faire beaucoup pour un OS avec un support SMP supposé mauvais:
http://www.sgi.com/servers/altix/(...)
[^]Re: Andrew Tannenbaum en gentleman !
Et quelles sont les performances pour des workloads genre base de donnees, file server, web server, ... ?
Parce que les workload type HPC, c'est tres specifique et pas tres representatif vu qu'il y a peu de communications, peu de switchs kernel mode, peu de creations/destructions de process/thread,...
Si tu regardes ce qu'ils ont fait, ils l'ont fait sur un kernel 2.4, hors aucun de ces kernels made-in SGI n'est utilise sur des gros serveurs >8CPU pour faire web server/database server/... et pour une bonne raison, ces kernels SGI ne sont pas adaptes a ce type de boulot, ils sont specifique au HPC.
[^]Re: Andrew Tannenbaum en gentleman !
Aucune idée, bien que j'utilise chez moi une paire de vieilles Origin 200 en craylink comme serveur NFS (et comme chauffage d'appoint), je pense qu'utiliser ce genre de machine en serveur de fichier, ou pire serveur web, est absurde.
Il est bien plus efficace et moins cher de repartir la charge sur plusieurs machines.
Pour un serveur de DB, ma fois j'ai l'impression que la tendance (cf Oracle 10) est plutot aussi à la répartition sur des cluster.
C'est sans doute plus de boulot à maintenir, mais le rapport cout/puissance est plutot favorable à plein de petites machines qu'un grosse et en plus en faisant bien les choses la disponibilité est aussi augmentée.
C'est sans doute dommage (pour les fans de beau hardware comme moi en particulier), mais les performances sur machines à plus de quelques (<4 à vue de nez) CPU vont sans doute devenir d'un intéret marginal avec la croissance de la bande passante et des PC a pas prix et grande vitesse.
Au final, je ne pense pas que Linux soit une solution toujours plus rapide (ne serai-ce que parceque que developpeur corpo ne veut pas dire imbécile et parceceque GCC n'est pas le meilleur compilo en matière d'optimisation).
Mais je pense que les Altix prouvent une chose : Linux peut etre "tweaké" pour jouer dans la haute performance.
[^]Re: Andrew Tannenbaum en gentleman !
C'est sans doute plus de boulot à maintenir, mais le rapport cout/puissance est plutot favorable à plein de petites machines qu'un grosse et en plus en faisant bien les choses la disponibilité est aussi augmentée.
A mon avis ca depend du boulot demande, si c'est pour faire une ferme de serveurs web tous identiques, surement, si c'est pour qqe chose de plus complexe, les couts d'administration pourraient changer la donne, ca depend des cas.
C'est sans doute dommage (pour les fans de beau hardware comme moi en particulier), mais les performances sur machines à plus de quelques (<4 à vue de nez) CPU vont sans doute devenir d'un intéret marginal avec la croissance de la bande passante et des PC a pas prix et grande vitesse.
Oui, mais il y a un autre cote, la technologie des grosses machines arrive dans les petites. Typiquement, il y a des systemes AMD a 2 ou 4 CPU qui sont NUMA, si tu veux avoir des bonnes perfs, il faut que ton kernel soit optimise pour(allouer la RAM proche du cpu, pas de migration d'une partition a l'autre,...), meme chose pour l'hyper-threading, t'as beau avoir 4 CPU, t'as 8 unites a scheduler et il faut faire attention a pas claquer ton cache en schedulant,...
Mais je pense que les Altix prouvent une chose : Linux peut etre "tweaké" pour jouer dans la haute performance.
Pour le HPC, ca ne fait aucun doute, pour les workload plus "standards" a mon avis il a encore un peu de retard.
[^]Re: Andrew Tannenbaum en gentleman !
A mon avis ca depend du boulot demande, si c'est pour faire une ferme de serveurs web tous identiques, surement, si c'est pour qqe chose de plus complexe, les couts d'administration pourraient changer la donne, ca depend des cas.
On ne peut pas généraliser, mais la tendance est tellement forte en la matière que les outils vont évoluer pour compenser l'augmentation de la complexité de gestion. C'est déja le cas de la plupart des consoles de gestion de réseaux/parcs qui présentent depuis une même interface les informations d'une machine individuelle ou d'un groupe.
... Typiquement, il y a des systemes AMD a 2 ou 4 CPU qui sont NUMA, si tu veux avoir des bonnes perfs, il faut que ton kernel soit optimise pour(allouer la RAM proche du cpu, pas de migration d'une partition a l'autre,...), meme chose pour l'hyper-threading...
La dessus NT ou Linux meme combat : les structures de haut niveau du systeme ne changent que peut d'une archi à l'autre (d'ailleurs j'aimerai bien savoir si les differentes archis de PC sont gerees par des implementations differentes de l'HAL ?) alors que les parties basses dependante du hard peut etre optimisées.
Bref on retombe dans l'antique debat UNIX vs ITS: portabilite/optimisation.
Pour le HPC, ca ne fait aucun doute, pour les workload plus "standards" a mon avis il a encore un peu de retard.
Possible, je n'en sais rien.
Pour être honnete mon expérience (Telecom, Web, et PME tertiaire) ne m'a pas permis de connaitre de workload "standard' justifiant des machines de 32 CPU. Quasiment à chaque fois que j'ai rencontré un gros besoin en matière de CPU il y'a eu moyen de répartir la charge sur plusieurs machines.
Les exceptions à cette régle ont toujours été des serveurs de DB. Et encore, les besoins d'une DB ne sont pas "standards" dans le sens ou son type de charge va surtout dépendre de l'application et change grandement de l'une à l'autre (et en fonction des connaissances et du sens de l'acrobatie du DBA).
Donc à ce disclamer pret, j'ai vu Linux/Intel remplacer diverses archis: OSF/Alpha (et True64), Solaris/Sparc, NT/Alpha, Irix/Mips et à chaque fois la perte en optimisation propriétaire s'est vue compensée largement par la différence de coût et la simplicité d'évolution (qui n'a pas affronté le service commercial de Digital pour obtenir une mise à jour de pack logiciel ne peut qu'imaginer ce que utiliser un logiciel libre a de bénéfique).
[^]Re: Andrew Tannenbaum en gentleman !
(d'ailleurs j'aimerai bien savoir si les differentes archis de PC sont gerees par des implementations differentes de l'HAL ?)
En bonne partie oui, il y a des HAL differentes selon les controleurs d'interruption par exemple, IBM, Compaq et autres ecrivent leurs propres HAL pour certains de leur serveurs.
[^]Re: Andrew Tannenbaum en gentleman !
Les meilleures performances ? Va mettre Linux sur un systeme a 32 cpu, on en reparlera apres...
Les serveurs de Google ?
[^]Re: Andrew Tannenbaum en gentleman !
Google c'est un tas de machines 2 ou 4 CPU, pas de gros systemes.
[+] [^]Re: Andrew Tannenbaum en gentleman !
Tu vas leur installer un windows NT4 ou NT5 ?
[+] [^]Re: Andrew Tannenbaum en gentleman !
C'est quoi le rapport avec la choucroute ?
[+] [^]Re: Andrew Tannenbaum en gentleman !
C'était quoi alors ta question sur les perfs de linux sur du 32 processeurs ?
Si t'es sûr d'avoir des meilleures perfs avec ton NT, cours leur proposer ils en seront probablement ravis !
[^]Re: Andrew Tannenbaum en gentleman !
1) Ils n'ont pas de gros systemes SMP
2) Tu ne consideres que les perfs quand tu choisis un systeme toi ? T'as jamais pense aux besoins specifiques d'une entreprise ?
Bref, je ne vois toujours pas le rapport, on parlait des perfs sur gros systemes SMP, chose que Google n'a pas et l'on ne parlait que des perfs et rien d'autre.
[+] [^]Re: Andrew Tannenbaum en gentleman !
1) Je me rappelle plus où j'ai lu qu'ils avaient un petit paquet de plus de 10 processeurs par machine
2) Non mais apparemment c'est ton cas vu que tu souhaites parler des perfs de linux en SMP
[^]Re: Andrew Tannenbaum en gentleman !
1) Normal que tu ne t'en rappelles plus, ils n'en ont pas.
2) Ben non justement, moi je ne parles que de perfs, je n'insinue pas qu'il faille remplacer les systemes car je sais qu'il y a d'autres parameteres en jeu, chose que tu n'as visiblement pas comprise. Tu es le seul ici a parler de NT chez Google.
[^]Re: Andrew Tannenbaum en gentleman !
Non les serveurs de Google sont des PC de base. Ils sont juste très nombreux.
http://www.google.com/technology/(...)
The speed you experience can be attributed in part to the efficiency of our search algorithm and partly to the thousands of low cost PC's we've networked together to create a superfast search engine.
[^]Re: Andrew Tannenbaum en gentleman !
J'ai l'impression de répéter un peu les même choses à chaque fois que l'histoire des versions non x86 de NT reviennent sur le tapis, mais si NT n'a pas pris sur ces architectures "alternatives" c'est aussi très largement parce qu'il n'était pas compétitif.
Contrairement à des plateforme "pure source" comme freebsd ou gentoo (je télécharge que des sources et je compile) ou des distributions binaires du style redhat & cie (je télécharge des binaires mais j'ai les sources sous la main) la plateforme windows et ses applications c'est quasiment uniquement du binaire propriétaire et compilé vendu par des tierces parties (et c'est aussi, quoiqu'un chouia moins, le cas de mac os x par exemple). Donc migrer d'une architecture vers une autre représente un cout et des difficultés d'organisation spécifiques (mon programme favori de mahjong de la société XYZ est-il disponible sur la nouvelle architecture, etc).
Sachant que :
- Sur alpha, MIPS, ppc, NT était face à la concurrence d'UNIX propriétaires aboutis et solides (Digital UNIX, IRIX, AIX, etc) quand il était encore à essayer d'avoir un uptime décent même sur x86.
- La société éditrice n'a pas proposé de compilateur croisé, obligeant par là même les ISV voulant supporter cette nouvelle plateforme a faire un investissement significatif en matériel au départ.
- Ces même compilateurs, apporté dans leurs bagages depuis leur base de départ (l'architecture x86) n'étaient pas compétitifs en terme de qualité du binaire produit (c'est bien beau de porter son compilateur, mais quand on arrive sur une plateforme utilisant les load/store et un vaste jeu de registre, il faut fatalement refaire quelques trucs)
- Corrollaire de tout cela les performances sont fatalement inférieures au plateformes intel équivalentes ET aux autres systèmes fonctionnant sur le même hardware et il y a quasiment aucun produit de tierces partie disponible.
Etant donné que les gens consomment du windows pour sa logithèque, pas pour ses qualités intrinsèques (surtout à l'époque), il y a pas de grand mystère sur les raisons pour lesquelles ça n'a pas marché. Alors oui officiellement Microsoft a arrêté ces plateformes parce que ça recoupait pas les couts. Mais ils avaient pas fait au départ l'investissement nécessaire pour rendre leur offre un minimum attractive. Ces cons de consommateurs plutôt que financer de manière altruiste l'amélioration du produit en achetant un truc pas compétitif ont préféré s'en détourner ; c'est de leur faute forcément si ça n'a pas marché, surement pas celle de Microsoft qui avait avec les meilleurs intentions du monde emballé dans une jolie boite son bidule recompilé à la va vite.
[^]Re: Andrew Tannenbaum en gentleman !
"Supporter un systeme pour 2%..."
Oui, mais c'est comme ça que l'on verrouille l'évolution pour empêcher l'éclosion de toute concurrence. Et puis, pour les 2%, c'est quand même exagéré.
Pour le système à 32 CPU, c'est la limite de Microsoft. Les plus grosses machines au monde en ont des milliers et Linux est dans le peloton de tête.
Je peux lire sur http://www.yenra.com/linux/(...)
" SGI supports up to 256 processors on SGI Altix Systems running on single Linux kernel"
Et à http://www.yenra.com/linux-cluster-supercomputer/(...)
"Linux Networx announced today it has two systems ranked within the 10 fastest supercomputers in the world"
Ou encore "Thunder" - N. America's Fastest Linux Supercomputer à http://www.linuxworld.com/story/44799.htm(...) (4,096 Itanium 2 processor)
C'étaient des nouvelles récentes. Consulte aussi http://www.top500.org/(...) (actualisé en novembre) pour voir avec quoi sont faits les plus gros ordinateurs du monde. On peut voir que les clusters se développent au détriment des autres.
Tiens au fait, on ne parle jamais de Microsoft sur ce site ! Simple fait du hasard ?
[^]Re: Andrew Tannenbaum en gentleman !
ils arrivent (preuve qu'ils n'y étaient pas):
http://www.zdnet.com.au/news/business/0,39023166,39148606,00.htm(...)
CKR Solutions Open Source
[^]Re: Andrew Tannenbaum en gentleman !
Oui, mais c'est comme ça que l'on verrouille l'évolution pour empêcher l'éclosion de toute concurrence. Et puis, pour les 2%, c'est quand même exagéré.
Ben voyons, ne pas supporter une plateforme HW c'est verouiller l'evolution maintenant, tu veux qu'ils portent Windows 2000 sur 68000 aussi ? Quand a 2%, ca n'a rien d'exagere, compte les machines PPC MIPS et Alpha, t'arriveras a peine a 2% compare a Intel.
Pour le système à 32 CPU, c'est la limite de Microsoft. Les plus grosses machines au monde en ont des milliers et Linux est dans le peloton de tête.
Le maximum pour l'instant est a 64
http://www.tpc.org/tpcc/results/tpcc_result_detail.asp?id=103082701(...)
Je peux lire sur http://www.yenra.com/linux/(...(...))
" SGI supports up to 256 processors on SGI Altix Systems running on single Linux kernel"
Oui, et aucun serveur ne supportant des workload type database/file server/... sous Linux n'est a plus de 8 CPU, seules les machines HPC qui ont un workload tres specifique avec peu de context switchs, peu de destruction de threads/processes, ...
Bref, scalabilite uniquement avec des tres gros patchs de SGI, et pour un workload specifique uniquement.
Tiens au fait, on ne parle jamais de Microsoft sur ce site ! Simple fait du hasard ?
Non, simple manque d'interet de MS pour ce marche, qui commence a se reveiller la dessus d'ailleurs vu qu'il grossit a vue d'oeil.
Remarque, un cluster de 500 machines ne dit rien sur la scalabilite d'un OS.
[^]Re: Andrew Tannenbaum en gentleman !
Si la HAL (Hardware Abstraction Layer) existait encore et était en bon état, NT et XP seraient compilables et disponibles sur toutes les architectures.
Pourquoi dis-tu que la HAL est en mauvais état ? Microsoft s'apprête à faire tourner la XBox 2 sur un processeur IBM PowerPC avec un système d'exploitation basé sur Windows (noyau NT/2000/XP...). Il y a aussi un Windows pour Itanium, et un autre pour AMD64.
Donc, après le code portable qui voulait se substituer au code spécifique, le logiciel libre a répondu avec la portabilité du code source.
Tu crois que le code source de Windows n'est portable ?
A te lire j'ai franchement l'impression de quelqu'un qui emploie tous les moyens pour dénigrer gratuitement les produits Microsoft...
[+] [^]Re: Andrew Tannenbaum en gentleman !
Microsoft s'apprête à faire tourner la XBox 2 sur un processeur IBM PowerPC
çà tourne, ou çà tourne pas?
çà tourne pas, donc çà n'existe pas encore.
pour le reste, c'est jamais qu'une forme de technologie x86
bon, donc windows est globalement disponible sur une architecture.
tu bosses aussi chez crosoft toi?
si oui, pourquoi ils ont arrreté la distribution NT sur alpha?
si non, pourquoi tu racontes des trucs dignes d'un commercial crosoftien?
[^]Re: Andrew Tannenbaum en gentleman !
çà tourne, ou çà tourne pas?
çà tourne pas, donc çà n'existe pas encore.
NT tourne sur PPC depuis 1996, donc oui, on peut dire que ca tourne.
si oui, pourquoi ils ont arrreté la distribution NT sur alpha?
Parce que Compaq a decide d'arreter les frais et que MS voulait pas payer pour.
si non, pourquoi tu racontes des trucs dignes d'un commercial crosoftien?
Ah, t'es le genre de gars qui considere que dire la verite c'est etre un commercial MS si ca va dans le sens de MS ?
[^]Re: Andrew Tannenbaum en gentleman !
je l'ai vu tourner en son temps chez Dec dans un bench avant-vente pour la bourse de Chicago. Dès qu'on a augmenté le nombre d'utilisateurs simultanés, le truc est parti en rideau. Changement de paramètres, redémarrage et limite un peu plus loin mais de nouveau, machine figé, incontrolable. Evidemment, ils ont pris l'OSF/1
CKR Solutions Open Source
[^]Re: Andrew Tannenbaum en gentleman !
Pas specialement surprenant, NT4 n'etait pas a l'epoque pret a remplacer les gros serveurs.
[^]Re: Andrew Tannenbaum en gentleman !
>Parce que Compaq a decide d'arreter les frais et que MS voulait pas payer pour.
Ah bon ? C'est marrant, je me rapelle pas de la même chose : Digital a aidé MS à faire son bouzin en 64 bits. Et une fois que MS aie récupéré ce savoir faire et celui des cluster haute dispo, il ont laissé le terrain de l'alpha en friche.
Ce n'est que plus tard que digital a été vendu en morceaux.
[^]Re: Andrew Tannenbaum en gentleman !
Faux, il y avait meme une version de Windows 2000 64bit pour Alpha en beta quand Compaq a decide d'arreter les frais.
Digital avait deja ete vendu a Compaq a ce moment.
[^]Re: Andrew Tannenbaum en gentleman !
> Faux,
Tu dis faux à quoi ?
Au fait, pour ton information, Windows pour Alpha, ça date de NT4, hein. J'ai encore un CD par là.
[^]Re: Andrew Tannenbaum en gentleman !
Je dis faux a :
Digital a aidé MS à faire son bouzin en 64 bits. Et une fois que MS aie récupéré ce savoir faire et celui des cluster haute dispo, il ont laissé le terrain de l'alpha en friche
C'est Compaq(Digital avait deja ete rachete a ce moment la) qui a decide d'arreter de participer au developement de Windows pour Alpha, et MS ne voulait pas continuer seul vu le peut d'interet du marche. C'etait en plein milieu du developpement de Windows 2000, et MS avait une version pour Alpha(la beta dont je parle) 64bits, preuve qu'ils n'ont pas laisse l'Alpha de cote.
Merci je sais quand NT pour Alpha est sorti, je crois que je suis a l'endroit ideal pour le savoir.
[^]Re: Andrew Tannenbaum en gentleman !
Peut etre que QNX est-il un meilleur exemple que NT (surtout sur LinuxFR :-) ) de l'utilite d'un microkernel qui marche : pouvoir redemarrer et arreter des parties entieres des fonctionnalites de l'OS sans rebooter est plutot une bonne idee pour un OS qui va etre embarque dans une machine autonome ou sensible a des contraintes de forte disponibilite.
Ce genre de chose est quand meme plus facile a faire sur un micro-kernel qu'un OS monolithique (mais pas impossible avec des modules facon Linux par exemple).
Apparemment le gros defaut des micro-kernel est surtout la difficulte de conception compare à des noyeaux monolithiques (la performance ne semble plus etre un vrai probleme avec les CPUs actuels (quoi qu'en embarqué...)).
Du coup Linux est "mieux" tout betement parcequ'il a pu etre dispo plus precocement et repondre a un besoin immediatement pas 10 ans apres.
[^]Re: Andrew Tannenbaum en gentleman !
mouais..
faudra m'expliquer comment on redemarre le gestionnaire de memoire sans fermer tous les processus..
Je est un autre.
[^]Re: Andrew Tannenbaum en gentleman !
hum je crois avoir dit "des parties entieres", pas toutes les parties.
Un parrallele simpliste : les fichiers de DLL utilises sous Windows sont en general verrouilles en ecriture quand en cours d'utilisation. Resultat une mise à jour de libs importantes entraine en general un reboot. Sous Unix je mets à jour mes libs et je fais un ptit ldconfig: pas de reboot, tout au plus un redemarrage des demons utilisant les libs changées.
Ca ne veut pas dire que je peux TOUT changer sous Unix sans devoir rebooter (comme mettre à jour le kernel, ou faire des operations qui necessitent un acces en single user sur / ).
C'est mieux, mais jamais parfait.
Tels que je les vois, les microkernels sont un pas de plus vers le mieux, evidemment pas une espece de perfection revolutionnaire.
[^]Re: Andrew Tannenbaum en gentleman !
Je me souviens d'avoir lu il y a quelques années dans Login: que Sun réussisait à changer à chaud le noyeau de ses UNIX.
[^]Re: Andrew Tannenbaum en gentleman !
Ben non. Pour citer M. Tannebaum:
"Microkernels Revisited
I can't resist saying a few words about microkernels. A microkernel is a very small kernel. If the file system runs inside the kernel, it is NOT a microkernel. The microkernel should handle low-level process management, scheduling, interprocess communication, interrupt handling, and the basics of memory management and little else. The core microkernel of MINIX 1.0 was under 1400 lines of C and assembler. To that you have to add the headers and device drivers, but the totality of everything that ran in kernel mode was under 5000 lines. Microsoft claimed that Windows NT 3.51 was a microkernel. It wasn't. It wasn't even close. Even they dropped the claim with NT 4.0. Some microkernels have been quite successful, such as QNX and L4.[...]"
http://www.groklaw.net/article.php?story=20040522014416143(...)
[^]Re: Andrew Tannenbaum en gentleman !
A propos de Linus et de Tannenbaum, voici le lien vers leur "engueulade" (enfin discussion scientifique animée) initiale sur le meilleur type de noyau :
http://groups.google.com/groups?threadm=12595%40star.cs.vu.nl(...)
[^]Re: Andrew Tannenbaum en gentleman !
j'aime bien ce morceau
You use this as an excuse for the limitations of minix? Sorry, but you
loose: I've got more excuses than you have, and linux still beats the
pants of minix in almost all areas. Not to mention the fact that most
of the good code for PC minix seems to have been written by Bruce Evans.
--
[^]Re: Andrew Tannenbaum en gentleman !
Bruce Evans est effectivement un développeur qui a beaucoup amélioré le code de Minix. Il distribuait un patchset (la licence de Minix interdisant un fork) qui permettait à Minix de devenir, d'un OS à but éducatif, un OS tout à fait utilisable.
L'argument de Linus sur ce coup était un peu bas, vu que le but de Minix est exactement celui-ci: fournir les bases, et les bases seulement, pour permettre à d'autres de s'exercer à écrire du code noyau.
"Il était une fois Linux", le bouquin de Torvalds qui raconte l'histoire de linux (comme son nom l'indique), y consacre un chapitre très intéressant.
http://www.fnac.com/Shelf/article.asp?Mn=1&Mu=-13&SID=6ab37(...)
(ce bouquin a l'avantage d'être parmi les moins chers des bouquins d'info, il est très peu technique, et je le recommande à tous les curieux)
Claws Mail - it bites!
[^]Re: Andrew Tannenbaum en gentleman !
Peut étre le seul chapitre intéressant du bouquin, ou il nous parle de comment faire rentrer des biéres dans un sona en Californien, et pourquoi il ne prend pas la Z3 pour aller au boulot, sans compter les longs chapitres de remplicage sur les buts de sa vie.
Il relève de la responsabilité du lecteur de contrôler, par tous moyens, l'adéquation du message à ses besoins et de s'assurer qu'il ne causera pas de dommages aux personnes et aux biens.
[^]Re: Andrew Tannenbaum en gentleman !
Pour ceux que cela intéresse (ou qui ne l'aurait jamais lu), cette "mythique" engueulade entre Linus et Tanenbaum à propos du choix micro-noyau / noyau monolithique a été traduite dans le livre "Tribune Libre" d'Oreilly.
Version en ligne : http://www.oreilly.fr/divers/tribune-libre/fr-appa.html(...)
Si vous avez le temps, lisez le bouquin en entier, cela date un peu mais de nombreux chapitres sont de très bonnes réferences : http://www.oreilly.fr/divers/tribune-libre/index.html(...)
[^]Re: Andrew Tannenbaum en gentleman !
Ce qui finit par être assez drôle, c'est que Tanenbaum est maintenant moins connu pour ses travaux que pour ce différend avec Linus Torvalds !
[^]Re: Andrew Tannenbaum en gentleman !
Pour les utilisateurs oui, mais pour les programmeurs je pense qu'il as beaucoup marqué par son bouquin sur les OS plus que par une discussion avec linus.