Plano 9 da Bell Labs

Plan 9 da Bell Labs é um sistema operacional distribuído que se originou do Centro de Pesquisa em Ciência da Computação (CSRC) na Bell Labs em meados da década de 1980 e construído sobre conceitos UNIX desenvolvidos pela primeira vez lá no final 1960. Desde 2000, o Plan 9 é gratuito e de código aberto. O lançamento oficial final foi no início de 2015.

No Plano 9, a metáfora tudo é um arquivo do UNIX é estendida por meio de um sistema de arquivos centrado na rede abrangente, e a E/S baseada em terminal endereçada ao cursor no coração do Os sistemas operacionais do tipo UNIX foram substituídos por um sistema de janelas e interface gráfica do usuário sem endereçamento de cursor, embora rc, o shell do Plan 9, seja baseado em texto.

O nome Plan 9 from Bell Labs é uma referência ao filme Z de ficção científica cult de Ed Wood de 1957 Plan 9 from Outer Space. O sistema continua a ser usado e desenvolvido por pesquisadores de sistemas operacionais e amadores.

História

Screenshot da instalação do Plano 9

O Plan 9 da Bell Labs foi desenvolvido originalmente, a partir do final dos anos 1980, por membros do Centro de Pesquisa em Ciência da Computação da Bell Labs, o mesmo grupo que originalmente desenvolveu o Unix e a linguagem de programação C. A equipe do Plan 9 foi inicialmente liderada por Rob Pike, Ken Thompson, Dave Presotto e Phil Winterbottom, com o apoio de Dennis Ritchie como chefe do Departamento de Pesquisa de Técnicas de Computação. Ao longo dos anos, muitos desenvolvedores notáveis contribuíram para o projeto, incluindo Brian Kernighan, Tom Duff, Doug McIlroy, Bjarne Stroustrup e Bruce Ellis.

O Plan 9 substituiu o Unix como a principal plataforma da Bell Labs para pesquisa de sistemas operacionais. Explorou diversas mudanças no modelo original do Unix que facilitam o uso e a programação do sistema, notadamente em ambientes multiusuários distribuídos. Após vários anos de desenvolvimento e uso interno, a Bell Labs despachou o sistema operacional para universidades em 1992. Três anos depois, o Plan 9 foi disponibilizado para partes comerciais pela AT&T por meio da editora de livros Harcourt Brace. Com licenças de origem custando US$ 350, a AT&T visava o mercado de sistemas embarcados, e não o mercado de computadores em geral. Ritchie comentou que os desenvolvedores não esperavam fazer "muito deslocamento" dado o quão estabelecidos outros sistemas operacionais se tornaram.

No início de 1996, o projeto Plan 9 havia sido "colocado em banho-maria" pela AT&T em favor da Inferno, destinada a rivalizar com a Sun Microsystems. plataforma Java. No final dos anos 1990, a Bell Labs' o novo proprietário, Lucent Technologies, abandonou o suporte comercial ao projeto e, em 2000, um terceiro lançamento foi distribuído sob uma licença de código aberto. Um quarto lançamento sob uma nova licença de software livre ocorreu em 2002. No início de 2015, ocorreu o lançamento oficial final do Plan 9.

Uma comunidade de usuários e desenvolvedores, incluindo funcionários atuais e antigos da Bell Labs, produziu pequenos lançamentos diários na forma de imagens ISO. Bell Labs sediou o desenvolvimento. A árvore de fonte de desenvolvimento é acessível através dos protocolos 9P e HTTP e é usada para atualizar as instalações existentes. Além dos componentes oficiais do sistema operacional incluídos nas ISOs, o Bell Labs também hospeda um repositório de aplicativos e ferramentas desenvolvidos externamente.

Como a Bell Labs passou para projetos posteriores nos últimos anos, o desenvolvimento do sistema oficial do Plan 9 foi interrompido. Em 23 de março de 2021, o desenvolvimento foi retomado após a transferência dos direitos autorais da Bell Labs para a Plan 9 Foundation. O desenvolvimento não oficial do sistema também continua no fork 9front, onde colaboradores ativos fornecem compilações mensais e novas funcionalidades. Até agora, o garfo 9front forneceu drivers Wi-Fi do sistema, drivers de áudio, suporte USB e emulador de jogo integrado, além de outros recursos. Outros sistemas operacionais recentes inspirados no Plan 9 incluem Harvey OS e Jehanne OS.

Conceitos de design

Plan 9 é um sistema operacional distribuído, projetado para fazer uma rede de computadores heterogêneos e geograficamente separados funcionar como um único sistema. Em uma instalação típica do Plan 9, os usuários trabalham em terminais que executam o sistema windows rio e acessam servidores de CPU que lidam com processos de computação intensiva. O armazenamento permanente de dados é fornecido por hosts de rede adicionais que atuam como servidores de arquivos e armazenamento de arquivos.

Seus designers afirmam que,

[t]ele as fundações do sistema são construídas em duas ideias: um espaço de nome por processo e um protocolo de sistema de arquivos orientado por mensagem simples.

—Pike. et al.

A primeira ideia (um namespace por processo) significa que, ao contrário da maioria dos sistemas operacionais, cada processo (programas em execução) tem sua própria visão do namespace, correspondendo ao que outros sistemas operacionais chame o sistema de arquivos; um único nome de caminho pode se referir a diferentes recursos para diferentes processos. A complexidade potencial dessa configuração é controlada por um conjunto de localizações convencionais para recursos comuns.

A segunda ideia (um sistema de arquivos orientado a mensagens) significa que os processos podem oferecer seus serviços a outros processos, fornecendo arquivos virtuais que aparecem nos arquivos dos outros processos. namespace. A entrada/saída do processo cliente em tal arquivo torna-se a comunicação entre processos entre os dois processos. Dessa forma, o Plano 9 generaliza a noção Unix do sistema de arquivos como o ponto central de acesso aos recursos de computação. Ele transporta a ideia do Unix de arquivos de dispositivo para fornecer acesso a dispositivos periféricos (ratos, mídia removível etc.) conexão a um programa servidor que fala um protocolo padronizado e trata seus serviços como parte do namespace.

Por exemplo, o sistema de janelas original, chamado 8½, explorou essas possibilidades da seguinte maneira. O plano 9 representa a interface do usuário em um terminal por meio de três pseudo-arquivos: mouse, que pode ser lido por um programa para obter notificação de movimentos do mouse e cliques de botão, cons, que pode ser usado para executar entrada/saída textual, e bitblt, escrita para a qual executa operações gráficas (consulte bit blit). O sistema de janelas multiplexa esses dispositivos: ao criar uma nova janela para executar algum programa, ele primeiro configura um novo namespace no qual mouse, cons e bitblt estão conectados a si mesmo, ocultando os arquivos reais do dispositivo aos quais ele próprio tem acesso. O sistema de janela, portanto, recebe todos os comandos de entrada e saída do programa e os manipula adequadamente, enviando a saída para o dispositivo de tela real e fornecendo ao programa atualmente focado a entrada do teclado e do mouse. O programa não precisa saber se está se comunicando diretamente com os drivers de dispositivo do sistema operacional ou com o sistema de janelas; ele só precisa assumir que seu namespace está configurado para que esses arquivos especiais forneçam o tipo de entrada e aceitem o tipo de mensagem que ele espera.

A operação distribuída do Plan 9 também depende dos namespaces por processo, permitindo que os processos do cliente e do servidor se comuniquem entre as máquinas da maneira que acabamos de descrever. Por exemplo, o comando cpu inicia uma sessão remota em um servidor de computação. O comando exporta parte de seu namespace local, incluindo os dispositivos do terminal do usuário (mouse, cons, bitblt), para o servidor, para que programas remotos possam realizar entrada/saída usando o mouse, teclado e tela do terminal, combinando os efeitos de login remoto e um sistema de arquivos de rede compartilhada.

Protocolo 9P

Todos os programas que desejam fornecer serviços como arquivos para outros programas falam um protocolo unificado, chamado 9P. Em comparação com outros sistemas, isso reduz o número de interfaces de programação personalizadas. 9P é um protocolo genérico, independente de meio e orientado a bytes que fornece mensagens entregues entre um servidor e um cliente. O protocolo é usado para se referir e se comunicar com processos, programas e dados, incluindo a interface do usuário e a rede. Com o lançamento da 4ª edição, foi modificado e renomeado 9P2000.

Ao contrário da maioria dos outros sistemas operacionais, o Plan 9 não fornece interfaces de programação de aplicativos especiais (como soquetes Berkeley, recursos X ou chamadas de sistema ioctl) para acessar dispositivos. Em vez disso, os drivers de dispositivo do Plan 9 implementam sua interface de controle como um sistema de arquivos, de modo que o hardware possa ser acessado pelas operações comuns de entrada/saída de arquivo leitura e gravação. Conseqüentemente, o compartilhamento do dispositivo pela rede pode ser feito montando a árvore de diretórios correspondente na máquina de destino.

União de diretórios e namespaces

O plano 9 permite que o usuário colete os arquivos (chamados nomes) de diferentes árvores de diretório em um único local. O diretório de união resultante se comporta como a concatenação dos diretórios subjacentes (a ordem da concatenação pode ser controlada); se os diretórios constituintes contiverem arquivos com o mesmo nome, uma listagem do diretório de união (ls ou lc) simplesmente relatará duplicação nomes. A resolução de um único nome de caminho é executada de cima para baixo: se os diretórios top e bottom forem unidos em u com top primeiro, então u/name denota top /name se existir, bottom/name somente se existir e top/name não exist, e nenhum arquivo se nenhum deles existir. Nenhuma união recursiva de subdiretórios é executada, portanto, se top/subdir existir, os arquivos em bottom/subdir não poderão ser acessados por meio do União.

Um diretório de união pode ser criado usando o comando bind:

; ligar /arm/bin /bin
; liga -a /ame/bin/arm /bin
; liga -b /usr/alice/bin/bin

No exemplo acima, /arm/bin é montado em /bin, o conteúdo de /arm/bin substituindo o conteúdo anterior de /bin. O diretório bin da Acme é então montado em união após /bin e o bin é montado em união antes. Quando um arquivo é solicitado de /bin, ele é procurado primeiro em /usr/alice/bin e depois em /arm/bin e, finalmente, em /acme/bin/arm.

Os namespaces de processo separados geralmente substituem a noção de um caminho de pesquisa no shell. Uma variável de ambiente de caminho ($path) ainda existe em o shell rc (o shell usado principalmente no Plan 9); no entanto, a variável de ambiente de caminho do rc convencionalmente contém apenas o / bin e . e modificando o variável é desencorajada, em vez disso, adicionar comandos adicionais deve ser feito vinculando vários diretórios juntos como um único /bin. Ao contrário do Plan 9, a variável de ambiente path dos shells Unix deve ser definida para incluir os diretórios adicionais cujos arquivos executáveis precisam ser adicionados como comandos.

Além disso, o kernel pode manter tabelas de montagem separadas para cada processo e, assim, fornecer a cada processo seu próprio namespace de sistema de arquivos. Processos' namespaces podem ser construídos independentemente, e o usuário pode trabalhar simultaneamente com programas que possuem namespaces heterogêneos. Namespaces podem ser usados para criar um ambiente isolado semelhante ao chroot, mas de forma mais segura.

A arquitetura de diretórios de união do Plan 9 inspirou as implementações do sistema de arquivos de união 4.4BSD e Linux, embora os desenvolvedores da instalação de montagem de união BSD tenham achado a fusão não recursiva de diretórios no Plano 9 "muito restritiva para uso geral finalidade de uso".

Sistema de arquivos virtual especial

/proc

Processos de listagem com conteúdo de lista de comando (ls, lc) /proc

Em vez de ter chamadas de sistema especificamente para gerenciamento de processos, o Plan 9 fornece o sistema de arquivos /proc. Cada processo aparece como um diretório contendo informações e arquivos de controle que podem ser manipulados pelas chamadas de sistema IO de arquivos comuns.

A abordagem do sistema de arquivos permite que os processos do Plan 9 sejam gerenciados com ferramentas simples de gerenciamento de arquivos, como ls e cat; no entanto, os processos não podem ser copiados e movidos como arquivos.

/rede

O Plan 9 não possui chamadas de sistema especializadas ou ioctls para acessar a pilha de rede ou o hardware de rede. Em vez disso, o sistema de arquivos /net é usado. As conexões de rede são controladas pela leitura e gravação de mensagens de controle nos arquivos de controle. Subdiretórios como /net/tcp e /net/udp são usados como uma interface para seus respectivos protocolos.

Unicode

Para reduzir a complexidade do gerenciamento de codificações de caracteres, o Plan 9 usa Unicode em todo o sistema. A implementação inicial do Unicode foi ISO/IEC 10646-1:1993. Ken Thompson inventou o UTF-8, que se tornou a codificação nativa no Plano 9. Todo o sistema foi convertido para uso geral em 1992. O UTF-8 preserva a compatibilidade com versões anteriores com strings tradicionais terminadas em nulo, permitindo um processamento de informações mais confiável e o encadeamento de multilíngues dados de string com Unix pipes entre vários processos. O uso de uma única codificação UTF-8 com caracteres para todas as culturas e regiões elimina a necessidade de alternar entre conjuntos de códigos.

Combinando os conceitos de design

Embora interessantes por conta própria, os conceitos de design do Plan 9 deveriam ser mais úteis quando combinados. Por exemplo, para implementar um servidor de conversão de endereços de rede (NAT), um diretório de união pode ser criado, sobrepondo a árvore de diretórios /net do roteador com sua própria classe /net. Da mesma forma, uma rede privada virtual (VPN) pode ser implementada sobrepondo em um diretório de união uma hierarquia /net de um gateway remoto, usando 9P seguro na Internet pública. Um diretório union com a hierarquia e filtros /net pode ser usado para proteger um aplicativo não confiável ou para implementar um firewall. Da mesma forma, uma rede de computação distribuída pode ser composta por um diretório de união de hierarquias /proc de hosts remotos, o que permite interagir com eles como se fossem locais.

Quando usados juntos, esses recursos permitem a montagem de um ambiente de computação distribuído complexo, reutilizando o sistema de nome hierárquico existente.

Software para Plano 9

Como benefício do design do sistema, a maioria das tarefas no Plan 9 pode ser realizada usando os utilitários ls, cat, grep, cp e rm em combinação com o shell rc (o shell padrão do Plan 9).

O Factotum é um servidor de autenticação e gerenciamento de chaves para o Plan 9. Ele lida com a autenticação em nome de outros programas, de forma que tanto as chaves secretas quanto os detalhes de implementação precisam ser conhecidos apenas pelo Factotum.

Programas gráficos

Plano 9 que executa o acme e rc

Ao contrário do Unix, o Plan 9 foi projetado com gráficos em mente. Após a inicialização, um terminal Plan 9 executará o sistema de janelas rio, no qual o usuário pode criar novas janelas exibindo rc. Os programas gráficos invocados a partir deste shell o substituem em sua janela.

O encanador fornece um mecanismo de comunicação entre processos que permite hiperlinks em todo o sistema.

Sam e acme são os editores de texto do Plan 9.

Sistema de armazenamento

O Plan 9 suporta os sistemas de arquivos Kfs, Paq, Cwfs, FAT e Fossil. O último foi projetado no Bell Labs especificamente para o Plan 9 e oferece capacidade de armazenamento de instantâneos. Ele pode ser usado diretamente com um disco rígido ou apoiado com Venti, um sistema de arquivo de arquivo e sistema de armazenamento permanente de dados.

Desenvolvimento de software

O pacote de distribuição para o Plan 9 inclui variantes especiais de compilador e linguagens de programação e fornece um conjunto personalizado de bibliotecas junto com um sistema de interface de usuário em janelas específico para o Plan 9. A maior parte do sistema é escrita em um dialeto de C (ANSI C com algumas extensões e alguns outros recursos deixados de fora). Os compiladores para esta linguagem foram construídos de forma personalizada tendo em mente a portabilidade; de acordo com o autor, eles "compilam rapidamente, carregam lentamente e produzem código de objeto de qualidade média".

Uma linguagem de programação concorrente chamada Alef estava disponível nas duas primeiras edições, mas foi descartada por motivos de manutenção e substituída por uma biblioteca de threading para C.

Compatibilidade com Unix

Embora o Plan 9 fosse um desenvolvimento adicional dos conceitos do Unix, a compatibilidade com o software Unix preexistente nunca foi o objetivo do projeto. Muitos utilitários de linha de comando do Plan 9 compartilham os nomes de equivalentes do Unix, mas funcionam de maneira diferente.

Plan 9 pode suportar aplicações POSIX e pode emular a interface socket Berkeley através do ANSI/POSIX Environment (APE) que implementa uma interface próxima a ANSI C e POSIX, com algumas extensões comuns (as interfaces nativas Plan 9 C não estão em conformidade com padrão). Ele também inclui um shell compatível com POSIX. Os autores do APE afirmam tê-lo usado para portar o X Window System (X11) para o Plan 9, embora não enviem o X11 "porque suportá-lo adequadamente é um trabalho muito grande". Alguns binários do Linux podem ser usados com a ajuda de um "linuxemu" (emulador de Linux) aplicativo; no entanto, ainda é um trabalho em andamento. Vice-versa, a máquina virtual vx32 permite que um kernel Plan 9 ligeiramente modificado seja executado como um processo de usuário no Linux, suportando programas Plan 9 não modificados.

Recepção

Comparação com sistemas operacionais contemporâneos

Em 1991, os projetistas do Plan 9 compararam seu sistema com outros sistemas operacionais do início dos anos 1990 em termos de tamanho, mostrando que o código fonte para um mínimo ("funcionando, embora não muito útil") a versão tinha menos de um quinto do tamanho de um microkernel Mach sem nenhum driver de dispositivo (5.899 ou 4.622 linhas de código para o Plano 9, dependendo da métrica, contra 25.530 linhas). O kernel completo compreendia 18.000 linhas de código. (De acordo com uma contagem de 2006, o kernel tinha então cerca de 150.000 linhas, mas isso foi comparado com mais de 4,8 milhões no Linux.)

Dentro da comunidade de pesquisa de sistemas operacionais, bem como no mundo comercial do Unix, outras tentativas de obter computação distribuída e acesso remoto ao sistema de arquivos foram feitas simultaneamente com o esforço de design do Plan 9. Estes incluíram o Network File System e a arquitetura vnode associada desenvolvida na Sun Microsystems, e saídas mais radicais do modelo Unix, como o Sprite OS da UC Berkeley. O desenvolvedor do Sprite, Brent Welch, aponta que a arquitetura SunOS vnode é limitada em comparação com os recursos do Plan 9, pois não suporta acesso remoto a dispositivos e comunicação entre processos remotos de forma limpa, embora pudesse ter, se tivesse o domínio UNIX preexistente. sockets (que "essencialmente podem ser usados para nomear servidores de nível de usuário") foram integrados com a arquitetura vnode.

Uma crítica ao design de "tudo é um arquivo", comunicação por mensagem textual do Plan 9 apontou as limitações desse paradigma em comparação com as interfaces digitadas do Sun' sistema operacional, Primavera:

O Plano 9 constrói tudo para parecer um arquivo. Na maioria dos casos, o tipo de interface real compreende o protocolo de mensagens que devem ser escritas e lidas a partir de um descritor de arquivo. Isso é difícil de especificar e documentar, e proíbe qualquer verificação automática de tipo, exceto por erros de arquivo no tempo de execução. (...) [A] nome de caminho relativo ao contexto de raiz implícita de um processo é o apenas como nomear um serviço. Ligar um nome a um objeto só pode ser feito dando um nome existente para o objeto, no mesmo contexto do novo nome. Como tal, referências de interface simplesmente não pode ser passado entre processos, muito menos em redes. Em vez disso, a comunicação tem de confiar em convenções, que são propensas a erros e não escalar.

—Roscoe; ênfase no original.

Uma comparação retrospectiva posterior do Plan 9, Sprite e um terceiro sistema operacional de pesquisa distribuído contemporâneo, Amoeba, descobriu que

os ambientes que eles [Amoeba e Sprite] construir são firmemente acoplados dentro do sistema operacional, tornando a comunicação com serviços externos difícil. Esses sistemas sofrem da saída radical do modelo UNIX, que também desencoraja a portabilidade do software já existente para a plataforma (...). A falta de desenvolvedores, a pequena gama de hardware suportado e a pequena, mesmo em comparação com o Plano 9, a base de usuários também diminuiu significativamente a adoção desses sistemas (...). Em retrospecto, o Plano 9 foi o único sistema operacional distribuído pela pesquisa daquele tempo que conseguiu atrair desenvolvedores e ser usado em projetos comerciais o suficiente para garantir sua sobrevivência até hoje.

—Mirtchovski, Simmonds e Minnich

Impacto

O gerenciador de janelas wmii X foi inspirado pelo acme, um editor de texto do projeto Plan 9.

O Plano 9 demonstrou que um conceito integral do Unix – que cada interface do sistema pode ser representado como um conjunto de arquivos – pode ser implementado com sucesso em um sistema distribuído moderno. Alguns recursos do Plan 9, como a codificação de caracteres UTF-8 do Unicode, foram implementados em outros sistemas operacionais. Os sistemas operacionais do tipo Unix, como o Linux, implementaram o 9P2000, o protocolo do Plan 9 para acessar arquivos remotos, e adotaram recursos do rfork, o mecanismo de criação de processos do Plan 9. Além disso, no Plan 9 do User Space, vários aplicativos e ferramentas do Plan 9, incluindo os editores sam e acme, foram portados para sistemas Unix e Linux e alcançaram algum nível de popularidade. Vários projetos buscam substituir os programas do sistema operacional GNU em torno do kernel do Linux pelos programas do sistema operacional Plan 9. O gerenciador de janelas 9wm foi inspirado no 8½, o sistema de janelas mais antigo do Plan 9; wmii também é fortemente influenciado pelo Plan 9. Na pesquisa em ciência da computação, o Plan 9 tem sido usado como uma plataforma de computação em grade e como um veículo para pesquisa em computação ubíqua sem middleware. No comércio, o Plan 9 é a base dos sistemas de armazenamento Coraid. No entanto, o Plan 9 nunca se aproximou do Unix em popularidade e tem sido principalmente uma ferramenta de pesquisa:

[Eu] não parece que o Plano 9 falhou simplesmente porque caiu aquém de ser uma melhoria bastante convincente no Unix para deslocar seu antepassado. Em comparação com o Plano 9, Unix creaks e clanks e tem pontos de ferrugem óbvios, mas ele faz o trabalho bem o suficiente para manter sua posição. Há uma lição aqui para arquitetos de sistema ambiciosos: o inimigo mais perigoso de uma solução melhor é uma base de código existente que é apenas bom o suficiente.

—Eric S. Raymond

Outros fatores que contribuíram para a baixa adoção do Plan 9 incluem a falta de backup comercial, o baixo número de aplicativos de usuário final e a falta de drivers de dispositivo.

Os proponentes e desenvolvedores do Plan 9 afirmam que os problemas que impedem sua adoção foram resolvidos, que seus objetivos originais como sistema distribuído, ambiente de desenvolvimento e plataforma de pesquisa foram alcançados e que ele desfruta de uma popularidade moderada, mas crescente. O Inferno, por meio de seus recursos hospedados, tem sido um veículo para levar as tecnologias do Plan 9 a outros sistemas como parte hospedada de grades de computação heterogêneas.

Vários projetos trabalham para estender o Plan 9, incluindo 9atom e 9front. Esses forks aumentam o Plan 9 com drivers de hardware e software adicionais, incluindo uma versão aprimorada do sistema de e-mail Upas, o compilador Go, suporte ao sistema de controle de versão Mercurial (e agora também uma implementação git) e outros programas. O Plan 9 foi portado para o computador de placa única Raspberry Pi. O projeto Harvey tenta substituir o compilador Plan 9 C personalizado pelo GCC, para alavancar ferramentas de desenvolvimento modernas, como GitHub e Coverity, e acelerar o desenvolvimento.

Desde a versão 1903 do Windows 10, o Windows Subsystem for Linux implementa o Plan 9 Filesystem Protocol como um servidor e o sistema operacional host do Windows atua como um cliente.

Derivados e bifurcações

Inferno é um descendente do Plan 9 e compartilha muitos conceitos de design e até mesmo código-fonte no kernel, particularmente em torno de dispositivos e do protocolo Styx/9P2000. A Inferno compartilha com a Plan 9 a herança Unix da Bell Labs e a filosofia Unix. Muitas das ferramentas de linha de comando no Inferno eram ferramentas do Plan 9 que foram traduzidas para o Limbo.

• 9atom aumenta a distribuição do Plano 9 com a adição de um kernel PAE 386, um amd64 cpu e kernel terminal, nupas, suporte de hardware de PC extra, fs de IL e Ken.
• 9 frente é um garfo do Plano 9. Começou a remediar uma percepção da falta de recursos de desenvolvimento dedicados dentro do Bell Labs, e acumulou várias correções e melhorias.
• 9legacia é uma distribuição alternativa. Inclui um conjunto de patches com base na distribuição atual do Plano 9.
• Akaros é projetado para arquiteturas de muitos núcleos e sistemas SMP de grande escala.
• Harvey OS é um esforço para obter o código do Plano 9 trabalhando com gcc e clang.
• JehanneOS é um sistema operacional experimental derivado do Plano 9. Sua userland e módulos são principalmente derivados de 9front, seu sistema de compilação do Harvey OS, e seu kernel é um garfo do kernel Plan9-9k 64-bit Plan9.
• NIX é um garfo de Plan9 destinado a sistemas multicore e computação em nuvem.
• Node9 é um derivado scripted do Plan9/Inferno que substitui a linguagem de programação Limbo e a máquina virtual DIS com a linguagem Lua e a máquina virtual LuaJit. Ele também substitui o Inferno per-platform hospedado I/O com evento libuv de Node.js e I/O para hospedagem consistente e multiplataforma. É uma prova de conceito que demonstra que um sistema operacional distribuído pode ser construído a partir de namespaces por processo e elementos de nuvem genérica para construir uma imagem de sistema único de tamanho arbitrário.
• Plano B projetado para trabalhar em ambientes distribuídos onde o conjunto de recursos disponíveis é diferente em diferentes pontos no tempo.

Licença

A partir do lançamento da Quarta edição em abril de 2002, o código-fonte completo do Plan 9 da Bell Labs está disponível gratuitamente sob a Lucent Public License 1.02, que é considerada uma licença de código aberto pela Open Source Initiative (OSI), licença de software livre pela Free Software Foundation e passa pelas Diretrizes de Software Livre Debian.

Em fevereiro de 2014, a Universidade da Califórnia, em Berkeley, foi autorizada pelo atual detentor dos direitos autorais do Plan 9 – Alcatel-Lucent – a lançar todos os softwares do Plan 9 anteriormente regidos pela Lucent Public License, Versão 1.02 sob a GPL-2.0- apenas.

Em 23 de março de 2021, a propriedade do Plan 9 foi transferida da Bell Labs para a Plan 9 Foundation, e todas as versões anteriores foram licenciadas novamente para a licença do MIT.