Oasis – um pequeno sistema Linux estaticamente ligado

Objetivos do projeto e escolhas de design

• Oasis é um sistema Linux pequeno e estaticamente ligado que favorece implementações simples e minimalistas de ferramentas comuns: musl em vez de glibc, sbase/ubase em vez de coreutils/util-linux, oksh em vez de bash, mandoc em vez de man-db, netbsd-curses em vez de ncurses, Netsurf em vez de navegadores pesados e ferramentas menores de init/build.
• Ele é visto como um sucessor espiritual de sta.li e outros sistemas inspirados em “suckless”.

Casos de uso

• Os usos sugeridos incluem imagens imutáveis, dispositivos embarcados e nós Kubernetes, onde binários totalmente autônomos e estaticamente ligados são atraentes.
• Alguns o consideram ideal para colocar ferramentas em dispositivos Linux embarcados com poucos recursos ou heterogêneos, sem se preocupar com versões locais de bibliotecas.
• Outros perguntam o que ele oferece em relação a distros mais mainstream ou à ligação dinâmica; para alguns, é “interessante mas pouco claro” fora de cenários de nicho/embarcados.

Sistema de build e reprodutibilidade

• Oasis usa Samurai (uma ferramenta de build compatível com Ninja) e enfatiza builds completos do sistema rápidos e reprodutíveis.
• Um comentarista descreveu sucesso ao construir o Oasis com Bazel para obter builds de OS distribuídos, incrementais e reprodutíveis; isso levou a uma comparação mais ampla entre Bazel e Nix.
• Nix é elogiado por builds baseados em hash e endereçados por conteúdo, além de cache distribuído, mas criticado pela granularidade grosseira dos builds e por um overhead maior por derivação dentro dos projetos.

Debate entre ligação estática e dinâmica

• Pró-estático:
  • Simplifica a implantação e evita a “dependency hell”; é bom para binários portáveis, containers e sistemas com restrições.
  • Com musl e LTO, o tamanho por binário pode continuar pequeno; os linkers podem descartar código não utilizado.
  • É aceitável reconstruir/religar tudo em atualizações de bibliotecas, especialmente com um build de árvore única.
• Pró-dinâmico:
  • Melhor compartilhamento de RAM, correção de segurança mais fácil (atualiza-se uma biblioteca compartilhada) e ferramentas maduras.
  • A ligação estática tem peculiaridades: ordem de construtores, incompatibilidades de ABI/versão, maior pegada total de memória em algumas cargas de trabalho.
• Vários observam que as práticas modernas de containers já duplicam imagens inteiras de SO, tornando o “inchaço” da ligação estática menos preocupante para alguns, mas não para todos.

musl, BearSSL e bibliotecas alternativas

• musl é elogiada por tamanho pequeno, portabilidade, semântica mais simples e facilidade para ligação estática; críticos citam bugs antigos de DNS, desempenho pior de malloc e comportamento mais peculiar em comparação com glibc.
• A licença é um fator: a licença permissiva do musl simplifica a ligação estática em comparação com a LGPL do glibc.
• BearSSL é questionada porque se autodescreve como “beta” e não possui TLS 1.3; outros argumentam que números de versão não sinalizam confiavelmente prontidão para produção e apontam bibliotecas amplamente usadas com versão <1.0 em outros lugares.

Aspectos práticos e limitações

• Uma antiga imagem QEMU do Oasis é relatada em torno de 360MB; os links das imagens oficiais atuais estavam temporariamente fora do ar.
• Drivers de GPU são destacados como um grande problema ainda não resolvido para um SO totalmente estático: a maioria dos projetos realistas ainda exige componentes dinâmicos ou stacks de GPU baseados em IPC.
• O Netsurf é admirado por seu minimalismo, mas seus links de documentação parecem desatualizados; a cobertura de renderização percebida é limitada.