De onde vem o Mac OS X?

A história do MacOS é um pouco mais complicada. Eu estava muito interessado nisso no final dos anos 90, já que Mach havia sido lançado em todo o mundo como uma maneira mais rápida de construir um sistema Unix.

A origem do kernel é um pouco mais complicada.

Tudo começa com a AT&T distribuindo seu sistema operacional para algumas universidades gratuitamente. Este Unix foi aprimorado extensivamente em Berkeley e tornou-se a base para as variações BSD do Unix e incorporou várias inovações como o "Fast File System" (UFS), introduziu links simbólicos e a API de sockets. A AT&T seguiu seu próprio caminho e construiu o System V ao mesmo tempo.

Enquanto isso, a pesquisa continuou e algumas pessoas adotaram o trabalho do BSD como base. Na CMU, o kernel BSD foi usado como base para a criação de protótipos de algumas novas idéias: threads, uma API para controlar o sistema de memória virtual (através de "pagers" conectáveis - mmap no nível do usuário), um sistema de chamada de procedimento remoto no nível do kernel e a maioria importante a idéia de mover algumas operações no nível do kernel para o espaço do usuário. Este se tornou o núcleo do Mach.

Não tenho 100% de certeza se o mmap veio do Mach, e mais tarde foi adotado pelo BSD, ou se o Mach apenas foi pioneiro na idéia e o BSD adicionou seu próprio mmap com base nas idéias do Mach.

Embora o kernel do Mach tenha sido descrito como um micro-kernel, até a versão 2.5 era apenas um sistema que fornecia os recursos de thread, mmap, passagem de mensagens, mas permanecia um kernel monolítico, todos os serviços estavam em execução no modo kernel.

Nessa época, Rick Rashid (agora na Microsoft) e Avie Tevanian (agora na Apple) tiveram uma nova idéia que poderia acelerar o Unix. A idéia era usar a chamada do sistema mmap para transmitir dados a serem copiados do espaço do usuário para os "servidores" que implementam o sistema de arquivos. Essa ideia era essencialmente uma variação de tentar evitar fazer cópias dos mesmos dados, mas era apresentada como um benefício dos micro kernels, mesmo que o recurso pudesse ser isolado de um micro kernel.

Os benchmarks deste sistema Unix mais rápido, apoiado por VM, foi o que levou as pessoas da NeXT e da FSF a escolherem Mach como a base de seus kernels.

O NeXT foi com o kernel do Mach 2.5 (que era baseado no BSD 4.2 ou 4.3) e o GNU não iria realmente começar o trabalho por anos. Era isso que os sistemas operacionais NeXTSTEP estavam usando.

Enquanto isso, na CMU, o trabalho continuou em Mach e eles finalmente perceberam a visão de ter vários servidores rodando em cima de um micro kernel com a versão 3.0. Não estou ciente de que alguém na natureza possa executar o Mach 3.0, pois todos os servidores interessantes no nível do usuário usavam o código AT&T para que fossem considerados onerados, por isso continuava sendo um produto de pesquisa.

Por essa época, a equipe de Jolitz fez uma porta de 4,3+ BSD para a arquitetura 386 e publicou seus esforços de portabilidade no DrDobbs. O 386BSD não foi mantido ativamente e surgiu um grupo para manter e avançar o 386BSD, a equipe do NetBSD. Brigas internas no grupo NetBSD causaram a primeira divisão e o FreeBSD foi formado a partir disso. O NetBSD na época queria se concentrar em ter um BSD de plataforma cruzada, e o FreeBSD queria se concentrar em ter um Unix que tivesse um ótimo desempenho em plataformas x86. Um pouco mais tarde, o NetBSD se dividiu novamente devido a outras disputas e isso levou à criação do OpenBSD.

Um fork do BSD 4.3 para plataformas x86 foi comercializado com uma empresa chamada BSDi, e vários membros da equipe original de Berkeley trabalharam lá e mantiveram boas relações com a equipe BSD da Universidade.

A AT&T não se divertiu e iniciou o processo AT&T vs BSDi, que posteriormente foi expandido para processar a Universidade. O processo era sobre a BSDi usando código proprietário da AT&T que não havia sido reescrito por Berkeley. Isso atrasou o BSD em comparação com o sistema operacional Linux.

Embora as coisas não parecessem boas para os réus, em algum momento alguém percebeu que o SystemV havia incorporado grandes partes do código BSD sob a licença BSD e a AT&T não havia cumprido suas obrigações na licença. Foi alcançado um acordo no qual a AT&T não precisaria retirar seu produto do mercado, e a Universidade concordou em retirar qualquer código que ainda pudesse se basear no código da AT&T.

A universidade lançou duas versões do BSD 4.4 oneradas e 4.4 lite. A versão onerada seria inicializada e executada, mas continha o código AT&T. A versão lite não continha nenhum código da AT&T, mas não funcionou.

Os vários esforços do BSD refizeram seu trabalho além da nova versão 4.4 lite e tinham um sistema de inicialização dentro de meses.

Enquanto isso, o micro kernel do Mach 3.0 permaneceu pouco útil sem nenhum servidor de usuários.

Um estudante de uma universidade escandinava (acredito que possa estar errado) foi o primeiro a criar um sistema Mach 3.0 completo com um sistema operacional completo baseado no lançamento 4.4 lite, acredito que isso se chama "Lites". O sistema funcionou, mas estava lento.

Durante o período 1992-1996 e agora o BSD já tinha uma chamada de sistema mmap (), assim como a maioria dos outros sistemas Unix. A "vantagem do micro kernel" que não existia nunca chegou a ser concretizada. O NeXT ainda tinha um núcleo monolítico. A FSF ainda estava tentando fazer o Mach construir, e não querendo tocar no código BSD ou contribuir com qualquer um dos esforços do BSD de código aberto, eles continuavam cobrando uma visão de kernel mal especificada e estavam se afogando nos protocolos RPC por conta própria. núcleo. O micro-kernel parecia ótimo no papel, mas acabou sendo projetado demais e apenas tornava tudo mais lento.

Nesse ponto, também tivemos o debate Linus vs Andy sobre micro-kernels e núcleos monolíticos, e o mundo começou a perceber que era impossível adicionar todos esses ciclos extras a um micro-kernel e ainda vir à frente de um kernel monolítico bem projetado .

A Apple ainda não havia adquirido o NeXTSTEP, mas também estava começando a considerar o Mach como um kernel potencial para seus futuros sistemas operacionais. Eles contrataram a Open Software Foundation para portar o Linux para o kernel Mach, e isso foi feito em seus escritórios em Grenoble, acredito que isso foi chamado de "mklinux".

Quando a Apple comprou a NeXT, o que eles tinham em mãos era uma fundação Unix relativamente antiga, uma versão Unix baseada em 4.2 ou 4.3 e, atualmente, nem mesmo o software livre funcionava bem nesses sistemas. Eles contrataram Jordan Hubbard para o FreeBSD para atualizar sua pilha Unix. Sua equipe foi responsável por atualizar o território do usuário e não é surpresa que o território do usuário do MacOS tenha sido atualizado para as versões mais recentes disponíveis no BSD.

A Apple mudou seu Mach de 2.5 para 3.0 em algum momento, mas decidiu não seguir a abordagem do microssistema e, em vez disso, manteve tudo em andamento. Nunca consegui confirmar se a Apple usou o Lites, contratou o hacker escandinavo ou se eles adotaram o 4.4 lite como seu sistema operacional. Eu suspeito que sim, mas eu já havia migrado para o Linux e havia parado de rastrear o mundo do BSD / Mach.

Houve um boato no final dos anos 90 de que Avie na Apple tentou contratar Linus (que já era famoso neste momento) para trabalhar em seu bebê, mas Linus optou por continuar trabalhando no Linux.

Histórico à parte, esta página descreve a terra do usuário e o kernel do Mach / Unix:

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

Encontrei este gráfico da história do OSX: texto alternativo

miguel.de.icaza
fonte

Entendi que a principal razão pela qual Stallman na FSF buscou o Mach não foi o desempenho, mas a facilidade de usar um depurador: ele poderia usar o depurador para depurar servidores Mach com muito mais facilidade do que o código de depuração executado no espaço do kernel. Embora talvez tenha sido o desempenho que o convenceu de que essa era uma maneira viável de implementar.

Skiphoppy

Se você realmente deseja ver um verdadeiro microkernel em ação, experimente o QNX. No QNX4, o kernel tinha apenas 32 K bytes, e apenas tratava a passagem de mensagens, o agendamento da CPU e as interrupções. Todas as outras partes do QNX OS podiam ser trocadas sem desligar ou reiniciar o sistema, e era extremamente robusto. Ao mesmo tempo, havia um emulador de janela para o QNX, chamado Willows, que executava aplicativos do Windows mais rapidamente que o Windows nativo. Embora isso não tenha nada a ver com o OS-X, o QNX provou que os microkernels são realmente viáveis quando feitos corretamente.

a imagem não está mais disponível.

Hermann Ingjaldsson

Imagem ainda não disponível

Sildoreth 17/04/2015

Steve Jobs ofereceu a Linus um emprego em 2000. Linus fala sobre isso aqui. wired.com/2012/03/mr-linux/all/1

Alistair McMillan

De onde vem o Mac OS X?

Respostas: