Estive estudando um sistema operacional pouco conhecido chamado Plan 9. E, antes que alguém pergunte que Linux é esse, convém esclarecer: ele não é Linux. Também não é um BSD disfarçado nem uma tentativa de substituir diretamente FreeBSD ou OpenBSD. O Plan 9 nasceu na Bell Labs como um sucessor conceitual do Unix, feito pelas pessoas que conheciam muito bem as qualidades e os limites do sistema anterior.

O ponto que mais me chamou a atenção não foi sua aparência, nem o fato de ser um sistema raro. Foi a tentativa de levar até o fim algumas ideias que o Unix havia apenas começado. No Plan 9, rede, arquivos, dispositivos, processos e interfaces foram pensados como partes do mesmo ambiente distribuído. Isso muda a maneira de enxergar o computador. 

Um sucessor conceitual do Unix

O desenvolvimento do Plan 9 começou no fim da década de 1980, no Computing Sciences Research Center da Bell Labs, o mesmo ambiente de pesquisa de onde saíram o Unix e a linguagem C. Nomes como Rob Pike, Ken Thompson, Dave Presotto e Phil Winterbottom aparecem ligados ao projeto. A proposta não era remendar o Unix indefinidamente, mas imaginar como ele poderia ter sido se redes, estações gráficas e servidores já fossem parte central do projeto original.

O Unix foi criado em um mundo no qual vários terminais acessavam uma máquina central. Depois, as redes locais se tornaram comuns, as estações ganharam interfaces gráficas e diferentes computadores passaram a dividir tarefas. Em muitos sistemas, cada novidade trouxe sua própria API, seu próprio protocolo e sua própria forma de administração. O Plan 9 tentou reduzir essa coleção de exceções.

É importante não romantizar essa história. O Plan 9 não tomou o lugar do Unix, não construiu um ecossistema comparável ao Linux e hoje continua sendo um sistema de nicho. Ainda assim, várias de suas ideias continuam interessantes porque obrigam a pensar em distribuição, identidade e composição de uma maneira muito limpa.

Quase tudo pode aparecer como arquivo

A frase mais repetida quando se fala em Plan 9 é tudo é arquivo. Ela ajuda, mas também simplifica demais. A ideia mais precisa é que quase qualquer recurso pode ser apresentado por meio de uma árvore de arquivos, esteja ele na própria máquina ou do outro lado da rede. Com isso, ler, escrever, listar e montar deixam de ser operações restritas aos arquivos tradicionais e passam a servir como uma linguagem comum para conversar com o sistema.

Em vez de ensinar cada programa a lidar com dezenas de interfaces diferentes, o Plan 9 tenta apresentar cada serviço de uma forma que as ferramentas comuns já entendem. Uma pilha de rede aparece em /net. Informações sobre processos aparecem como arquivos. Recursos fornecidos por outra máquina podem ser montados dentro do namespace local. Para o programa, tudo isso se parece com uma árvore coerente.

O protocolo 9P

O protocolo que sustenta essa organização é o 9P. Em uma primeira aproximação, ele lembra um NFS exótico: um protocolo usado para acessar arquivos pela rede. A comparação é útil para começar, mas fica curta rapidamente. O 9P não serve apenas para abrir uma pasta remota. Ele é o mecanismo usado para apresentar serviços inteiros dentro do namespace do usuário.

·    Menos interfaces fundamentais. Há menos modelos diferentes para aprender e implementar.

·    Serviços combináveis. Recursos podem ser montados e reorganizados sem obrigar cada aplicação a carregar bibliotecas específicas.

·    Inspeção com ferramentas comuns. Comandos de arquivo ajudam a observar e experimentar serviços que, em outros sistemas, dependeriam de clientes próprios.

Observação. Uma abstração uniforme não elimina latência, falhas de rede, concorrência ou diferenças de desempenho. O recurso remoto pode parecer parte da árvore local, mas continua sujeito à realidade de uma rede.

Namespaces que mudam por processo

No Unix tradicional, normalmente pensamos em uma árvore de arquivos compartilhada por todo o sistema. O Plan 9 trata o namespace como algo que pode ser montado de forma diferente para cada processo ou grupo de processos. O mesmo caminho pode apontar para origens distintas dependendo do ambiente em que o programa foi iniciado.

Isso permite entregar a um programa apenas a rede, os dispositivos e os diretórios de que ele precisa. Também permite unir diretórios vindos de lugares diferentes para que apareçam juntos. Não é somente uma curiosidade acadêmica: é uma forma bastante concreta de controlar contexto e compor recursos sem obrigar cada aplicação a entender a topologia inteira.

Uma arquitetura realmente distribuída

Uma instalação clássica do Plan 9 pode ser dividida em funções. O terminal executa a interface e os programas interativos; o CPU server oferece processamento; o file server mantém os dados; e o auth server participa da autenticação. Essas funções podem estar na mesma máquina, mas foram pensadas para trabalhar separadas pela rede.

Na prática, um usuário poderia se sentar diante de um terminal modesto, executar o trabalho pesado em um CPU server e acessar dados mantidos por outro servidor. O resultado não deveria parecer uma coleção evidente de sessões remotas. Os componentes seriam reunidos no namespace do usuário e apresentados como um único ambiente de trabalho.

As ferramentas que dão personalidade ao Plan 9

O Plan 9 não chama atenção pela quantidade de programas. Ele chama atenção pela forma como poucas ferramentas se combinam. Algumas parecem estranhas no primeiro contato, sobretudo porque nasceram em uma cultura muito diferente da interface gráfica atual. Depois de algum tempo, fica claro que há uma lógica comum entre elas.

O Acme é provavelmente a melhor porta de entrada para quem deseja sentir a filosofia do sistema sem instalar uma máquina inteira. Ele transforma texto em interface. Um nome de arquivo pode ser aberto, uma palavra pode executar um comando e a saída desse comando pode aparecer em outra janela. Em vez de uma coleção de botões desenhados para cada tarefa, o ambiente usa texto, seleção e composição.

Drawterm e acesso remoto

O Drawterm é um cliente para Windows, Linux e outros sistemas. Ele se conecta aos serviços de CPU e autenticação de uma instalação Plan 9, fornece teclado, mouse e exibição e ainda pode exportar um diretório local para o namespace remoto. É uma forma prática de usar uma instalação distante sem transformar a máquina principal em um terminal Plan 9 dedicado.

Também existe uma diferença importante quando se fala em SSH. O 9front atual possui um cliente SSH2, além de ferramentas como sshfs e sshnet. Isso permite sair do 9front para acessar um servidor Debian ou montar arquivos remotos. Para entrar no 9front, porém, o caminho natural é usar Drawterm e rcpu, não tratar a máquina como mais um servidor OpenSSH comum.

# No 9front, abrir uma sessão SSH em um servidor remoto

ssh usuario@servidor.example

 # Montar uma pasta SFTP remota em modo somente leitura

sshfs -R -m /n/remoto usuario@servidor.example

Segurança e identidade

A Quarta Edição do Plan 9 consolidou uma arquitetura de segurança centrada em autenticação distribuída e na separação entre protocolos e segredos. O factotum atua como agente de autenticação: mantém chaves e executa protocolos em nome das aplicações sem entregar diretamente os segredos a cada programa. O secstore pode armazenar material privado de forma protegida.

A ideia lembra, em espírito, o uso moderno de um agente SSH. A aplicação pede que determinada autenticação seja realizada, enquanto um componente especializado controla o acesso à chave. Isso não significa que os dois sistemas sejam equivalentes, mas a analogia ajuda a entender por que o Plan 9 trata identidade como parte da arquitetura e não como um detalhe acrescentado depois.

Primeiro projeto Acme no Linux

O começo mais simples é instalar o plan9port em uma máquina Linux com interface gráfica e usar o Acme durante uma semana. Eu escreveria rascunhos do meu digital garden, abriria diretórios de projetos e experimentaria a ideia de usar texto como interface. O objetivo não seria substituir imediatamente meu editor atual, mas entender o que muda quando comandos, arquivos e anotações vivem no mesmo espaço.

Segundo projeto Uma estação Plan 9 em uma VM

Depois eu criaria uma pequena VM 9front em um hipervisor doméstico, com poucos recursos e acesso restrito à rede privada. Dois processadores virtuais, 2 GB de memória e 16 GB de disco são suficientes para estudar com folga. O acesso seria feito por Drawterm através da rede local ou de uma rota privada controlada. Nada de abrir a máquina diretamente para a internet no primeiro dia.

Terceiro projeto Um painel do homelab em 9P

Este é o projeto que melhor combina a filosofia do Plan 9 com um homelab doméstico. Um pequeno servidor 9P no Debian poderia apresentar o estado das máquinas como uma árvore: /srv/homelab/servidor/status, /virtualizacao/vms e /radio/ouvintes. Ler um arquivo mostraria a informação atual. Não haveria painel web, framework de frontend nem uma API cheia de endpoints para esse primeiro experimento.

/srv/homelab/

├── servidor/status

├── servidor/temperatura

├── virtualizacao/vms

├── radio/agora

└── radio/ouvintes

Eu começaria em modo somente leitura. Nada de arquivos chamados restart ou delete controlando serviços de produção. Primeiro, o sistema precisa provar que é útil para observar. Só depois faria sentido discutir comandos de administração.

Quarto projeto Um catálogo fotográfico pessoal

Outro experimento interessante seria expor metadados das fotografias como arquivos. Cada imagem poderia ter caminhos como camera, receita, data e nota. Uma busca deixaria de depender de um banco de dados fechado e poderia ser feita com as próprias ferramentas do ambiente. O objetivo não seria substituir o catálogo principal, mas construir uma visão experimental e navegável do acervo.

Quinto projeto Um console somente leitura para uma rádio web

Uma rádio web também renderia um bom laboratório. Um serviço poderia publicar a música atual, o número de ouvintes, a fila e o estado dos componentes de transmissão como arquivos. Acme, rc ou qualquer cliente 9P conseguiria consultar essas informações. Mais uma vez, eu manteria o primeiro protótipo somente leitura. O Plan 9 seria uma lente sobre a rádio, não o sistema responsável por mantê-la no ar.

Vale a pena experimentar

Sim, desde que a expectativa esteja correta. O Plan 9 não é uma substituição prática para Debian, OpenBSD ou Windows no meu ambiente. Também não é a melhor escolha para hospedar um serviço público que precisa de atualizações previsíveis, integrações modernas e uma comunidade grande. Usá-lo dessa maneira seria criar dificuldade sem receber uma vantagem proporcional.

Como laboratório, porém, ele é excelente. Poucos sistemas deixam tão visível a relação entre nomes, arquivos, rede, identidade e composição. Instalar o 9front, entrar por Drawterm, trabalhar no Acme e publicar um serviço 9P pequeno é uma forma de estudar sistemas distribuídos colocando a mão em algo concreto.

É isso que me interessa no Plan 9. Não a fantasia de abandonar tudo o que funciona, mas a oportunidade de olhar para meus sistemas atuais com outra cabeça. Depois de algum tempo usando Plan 9, até uma pasta, uma conexão de rede ou uma ferramenta de texto começa a parecer menos óbvia. Para um sistema operacional que nunca conquistou o mercado, já é um resultado bastante respeitável.