D'où vient Mac OS X?


43

En discutant avec les propriétaires de Mac, j'ai eu plusieurs versions de la provenance de Mac OS X. On sait qu’il a des racines dans BSD, mais combien et où?

Certains disent que Mac OS X a un noyau FreeBSD, avec tous les utilitaires ci-dessus qui en font un système d'exploitation spécifique à Mac. ( Il ne parle pas sur les applications utilisateur ici, que tous les init, ls, cdet d' autres. Binutils? )

D'autres disent que Mac OS X est un noyau Darwin, c'est-à-dire un Mac pur, et que les utilitaires OS proviennent de BSD.

Où est la vérité?


11
Le titre de cette question devrait vraiment être "D'où vient Mac OS X", car toutes les versions de Mac OS antérieures à X sont un système d'exploitation complètement différent de celui basé sur non-unix.
Sandy

1
@Sandy: correction du problème
Warren Young

J'allais suggérer «l'enfer», mais ensuite, j'ai eu le souvenir déplaisant de Microsoft et leur horrible «Windows» ... Autre chose? NeXTSTEP et BSD si ma mémoire est bonne et je suis sûr que les réponses le notent.
Pryftan

Réponses:


67

L'histoire de MacOS est un peu plus compliquée. Cela m'intéressait beaucoup à la fin des années 90, alors que Mach avait été présenté dans le monde entier comme un moyen plus rapide de construire un système Unix.

L'origine du noyau est un peu plus compliquée.

Tout commence avec AT & T qui distribue gratuitement son système d'exploitation à certaines universités. Cet Unix a été considérablement amélioré à Berkeley et est devenu le fondement des variantes d’Unix BSD. Il intègre plusieurs innovations telles que le "Fast File System" (UFS), les liens symboliques introduits et l’API de sockets. AT & T suivit sa propre voie et construisit System V en même temps.

Pendant ce temps, les recherches se sont poursuivies et certaines personnes ont adopté les travaux de BSD comme base. À la CMU, le noyau BSD a été utilisé comme base pour le prototypage de quelques nouvelles idées: des threads, une API permettant de contrôler le système de mémoire virtuelle (via des "pagers" enfichables - mmap au niveau utilisateur), un système d’appel de procédure distant au niveau du noyau et la plupart des autres. surtout l’idée de déplacer certaines opérations au niveau du noyau vers l’espace utilisateur. Ceci est devenu le noyau de Mach.

Je ne suis pas sûr à 100% de savoir si mmap venait de Mach et a été adopté plus tard par BSD, ou si Mach a simplement lancé l'idée et que BSD a ajouté son propre mmap basé sur les idées de Mach.

Bien que le noyau Mach ait été décrit comme un micro-noyau, jusqu'à la version 2.5, il s'agissait simplement d'un système fournissant le fil, mmap, des fonctionnalités de transmission de messages, mais demeurant un noyau monolithique, tous les services s'exécutaient en mode noyau.

À cette époque, Rick Rashid (maintenant chez Microsoft) et Avie Tevanian (maintenant chez Apple) avaient eu une idée nouvelle qui pourrait accélérer Unix. L'idée était d'utiliser l'appel système mmap pour transmettre les données à copier de l'espace utilisateur aux "serveurs" implémentant le système de fichiers. Cette idée consistait essentiellement à essayer d'éviter de copier les mêmes données, mais elle était présentée comme un avantage des micro-noyaux, même si la fonctionnalité pouvait être isolée d'un micro-noyau.

Les points de repère de ce système Unix plus rapide soutenu par VM sont ce qui a poussé les gens de NeXT et de la FSF à choisir Mach comme base de leurs noyaux.

NeXT est allé avec le noyau Mach 2.5 (qui était basé sur BSD 4.2 ou 4.3) et GNU ne commencerait pas le travail avant des années. C'est ce que les systèmes d'exploitation NeXTSTEP utilisaient.

Pendant ce temps à la CMU, le travail sur Mach continuait et ils ont finalement réalisé la vision de plusieurs serveurs s'exécutant sur un micro-noyau avec la version 3.0. Je ne suis pas au courant que quiconque dans la nature soit capable d'exécuter Mach 3.0, car tous les serveurs de niveau utilisateur intéressants utilisaient du code AT & T, ils étaient donc considérés comme encombrés. Il restait donc un produit de recherche.

À peu près à la même époque, l’équipe Jolitz avait réalisé un portage de plus de 4,3 BSD vers l’architecture 386 et avait publié ses efforts de portage sur DrDobbs. 386BSD n’était pas activement maintenu et un groupe a été créé pour maintenir et faire progresser 386BSD, l’équipe de NetBSD. Des combats internes au sein du groupe NetBSD ont provoqué la première scission et FreeBSD en est issu. À l'époque, NetBSD souhaitait se concentrer sur un BSD multiplate-forme et FreeBSD souhaitait se concentrer sur un système Unix performant sur les plates-formes x86. Un peu plus tard, NetBSD s'est à nouveau séparé en raison d'autres conflits, ce qui a conduit à la création d'OpenBSD.

Une fourchette de BSD 4.3 pour plates-formes x86 est devenue commerciale avec une société appelée BSDi, et divers membres de l’équipe initiale de Berkeley y ont travaillé et ont maintenu de bonnes relations avec l’équipe de BSD de l’Université.

AT & T n'a pas été amusé et a entamé le procès AT & T vs BSDi, qui a ensuite été élargi pour poursuivre également l'Université. La plainte portait sur BSDi et utilisait un code propriétaire d’AT & T qui n’avait pas été réécrit par Berkeley. Cela établissait un décalage entre BSD et le système d’exploitation Linux à venir.

Bien que les choses ne semblaient pas bonnes pour les défendeurs, quelqu'un a vite compris que SystemV avait incorporé d'importants morceaux de code BSD sous licence BSD et qu'AT & T n'avait pas rempli ses obligations. Un accord a été conclu selon lequel AT & T n'aurait pas à retirer son produit du marché et l'Université a accepté d'extraire tout code pouvant encore être basé sur le code AT & T.

L'université a ensuite publié deux versions de BSD 4.4 encombré et 4.4 lite. La version encombrée démarrerait et s'exécuterait, mais contiendrait du code AT & T. La version lite ne contenait aucun code de AT & T mais ne fonctionnait pas.

Les différents efforts de BSD ont repris leur travail sur la nouvelle version 4.4 lite et ont mis en place un système de démarrage en quelques mois.

Pendant ce temps, le micro-noyau Mach 3.0 n'est pas très utile sans aucun des serveurs utilisateurs.

Un étudiant d’une université scandinave (je pense que j’ai peut-être tort) a été le premier à créer un système complet Mach 3.0 avec un système d’exploitation complet basé sur la version 4.4 lite. Je crois que cela s’appelait "Lites". Le système fonctionnait mais était lent.

Entre 1992 et 1996, BSD avait déjà un appel système mmap () et la plupart des autres systèmes Unix. Le "micro-noyau" qui n’était pas là ne s’est jamais vraiment concrétisé. NeXT avait toujours un noyau monolithique. La FSF essayait toujours de construire Mach, et ne voulant pas toucher au code BSD ni contribuer aux efforts de la BSD open source, elle continuait de s'en prendre à une vision du noyau mal spécifiée et se noyait sous les protocoles RPC. noyau. Le micro-noyau avait fière allure sur le papier, mais il s’est avéré trop technique et a tout ralenti.

À ce stade, nous avons également eu le débat Linus vs Andy sur les micro-noyaux vs les noyaux monolithiques et le monde a commencé à se rendre compte qu’il était tout simplement impossible d’ajouter tous ces cycles supplémentaires à un micro-noyau et d’avancer encore devant un noyau monolithique bien conçu. .

Apple n'avait pas encore acquis NeXTSTEP, mais commençait également à considérer Mach comme un noyau potentiel pour ses futurs systèmes d'exploitation. Ils ont embauché Open Software Foundation pour porter Linux sur le noyau Mach, et cela a été fait depuis leurs bureaux de Grenoble. Je crois que cela s'appelait "mklinux".

Lorsque Apple a acheté NeXT, il ne disposait que d'une base Unix relativement ancienne, d'un Unix basé sur 4.2 ou 4.3 et, à ce jour, même les logiciels libres ne fonctionnaient pas correctement sur ces systèmes. Ils ont engagé Jordan Hubbard hors de FreeBSD pour mettre à niveau leur pile Unix. Son équipe était responsable de la mise à niveau du territoire des utilisateurs, et il n’est pas surprenant que l’utilisateur MacOS ait été mis à niveau vers les dernières versions disponibles sur BSD.

Apple a fait passer leur Mach de 2,5 à 3,0 à un moment donné, mais a décidé de ne pas adopter l'approche du micro-noyau et a tout gardé en cours de traitement. Je n'ai jamais été en mesure de confirmer si Apple utilisait Lites, avait embauché le pirate informatique scandinave ou s'il avait adopté la version 4.4 lite comme système d'exploitation. J'imagine que oui, mais j'étais déjà passé sous Linux et j'avais arrêté de suivre le monde BSD / Mach.

Il y avait une rumeur à la fin des années 90 selon laquelle Avie chez Apple aurait tenté d'embaucher Linus (qui était déjà célèbre à ce moment-là) pour travailler sur son bébé, mais Linus a choisi de continuer à travailler sur Linux.

En dehors de l’histoire, cette page décrit l’utilisateur et le noyau Mach / Unix:

http://developer.apple.com/mac/library/documentation/Darwin/Conceptual/KernelProgramming/Architecture/Architecture.html#//apple_ref/doc/uid/TP30000905-CH1g-CACDAEDC

J'ai trouvé ce graphique de l'histoire d'OSX: texte alternatif


Je croyais comprendre que la raison principale invoquée par Stallman à la FSF pour Mach n’était pas la performance mais la facilité d’utiliser un débogueur: il pouvait utiliser le débogueur pour déboguer des serveurs Mach beaucoup plus facilement que le code de débogage exécuté dans l’espace noyau. Bien que ce soit peut-être la performance qui l’ait convaincu, c’était un moyen viable de le mettre en œuvre.
skiphoppy

4
Si vous voulez vraiment voir un vrai micro-noyau en action, essayez QNX. Dans QNX4, le noyau ne contenait que 32 Ko et ne gérait que le transfert de messages, la planification du processeur et les interruptions. Toutes les autres parties du système d'exploitation QNX pouvaient être remplacées sans arrêter ou redémarrer le système, ce qui était extrêmement robuste. À une époque, il existait un émulateur de fenêtre pour QNX appelé Willows, qui exécutait les applications Windows plus rapidement que les fenêtres natives. Bien que cela n’ait rien à voir avec OS-X en tant que tel, QNX a prouvé que les micro-noyaux sont vraiment viables s’ils sont correctement préparés.

20
l'image n'est plus disponible.
Hermann Ingjaldsson le

7
Image pas encore disponible
Sildoreth

Steve Jobs a proposé un emploi à Linus en 2000. Linus en parle ici. wired.com/2012/03/mr-linux/all/1
Alistair McMillan

24

Du côté Unix, OS X est un descendant de NeXTSTEP , qui a été dérivé de 4.3BSD avec les parties essentielles du noyau remplacées par Mach .

L'API de programmation NeXT, qui a fini par être appelé OpenStep , est la base de l'API Cocoa d'aujourd'hui pour OS X. Deux API ont divergé considérablement depuis Apple a acheté NeXT en 1997, mais il y a en cours des efforts pour fournir des API compatibles open source clones de cacao .

Ajoutez à cela l'API de compatibilité Classic MacOS, appelée Carbon, et vous avez l'interface de programmation OS X.

(Il y a beaucoup plus à OS X, mais ce sont des applications en plus de tout cela: le Finder, les outils BSD et GNU, etc.)

Pour ce qui est de l’idée du noyau FreeBSD, c’est un peu correct, mais c’est une façon peu sophistiquée de la regarder. Le noyau original est venu, comme je l'ai dit, de NeXT, qui a assemblé son premier noyau à partir de 4.3BSD et Mach. Cela signifie que FreeBSD et NeXTSTEP ont partagé du code via 4.3BSD.

Le meme que OS X est basé sur FreeBSD a deux sources plus récentes. Premièrement, Apple a continué à emprunter des innovations du monde BSD, généralement de FreeBSD. Deuxièmement, Apple a embauché Jordan Hubbard, cofondateur du projet FreeBSD, peu après la publication de la première version publique d'OS X. Il a travaillé pour Apple jusqu'en juin 2013.


0

Quand on vous a dit qu'OSX a sa propre saveur d'Unix, ils sont techniquement corrects.

BSD + Elements de NeXTSTEP + Apple Tweaks = DARWIN

Pour le dire autrement. Commande uniquement du fudge chaud / de la crème glacée (BSD), ajoutez des noix (NeXTStep), de la crème fouettée et une cerise (un complément Apple et des réglages) = un fudge Sundae (Darwin)

Mais BSD est la base sur laquelle les autres ont été ajoutés, c’est pourquoi une grande partie de BSD fonctionnera à Darwin (avec quelques modifications ici et là).

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.