O projeto Redox OS, o sistema operacional escrito do zero em Rust, publicou um ambicioso roadmap para 2025 e 2026. Os planos detalham uma estratégia de três frentes para levar o Redox ao uso no mundo real: como um runtime seguro para web services, como um sistema para servidores de edge e nuvem, e como um desktop para o dia a dia com o moderno COSMIC Desktop. Em paralelo, o time mira marcos técnicos que definem maturidade de um SO — de auto-hospedagem (“Building Redox on Redox”) à segurança baseada em capability-based security, passando por Wayland, aceleração de GPU e melhorias de performance. É uma narrativa clara: primeiro provar valor rapidamente, depois escalar, e por fim tornar o Redox uma opção viável para o usuário final.
Hosted Redox: a rota rápida para uso prático
Imagine vestir um colete balístico no seu serviço web — é a ideia por trás do Hosted Redox. Aqui, o Redox roda dentro de uma VM (via QEMU/KVM) em um servidor Linux. O host cuida da compatibilidade de hardware e das ferramentas de gestão; o Redox oferece o “ambiente seguro” para rodar aplicações: servidor web, banco de dados, microserviços WASM/WASI e serviços customizados. Por que isso importa? Porque é a forma mais curta de colocar o Redox em produção sem esperar por drivers e utilitários de um ecossistema inteiro.
Quais são as peças que faltam para esse cenário ganhar tração? Um stack de rede mais rápido (com ring buffers), VirtioFS para compartilhar arquivos entre host e convidado, virglrenderer para aceleração gráfica virtualizada, além de polimento em IPC/memória compartilhada, ferramentas de gerenciamento e builds reprodutíveis. A meta não é “rodar tudo”, mas o suficiente para validar o Redox como plataforma segura de serviços — e aprender rápido com uso real.
Redox Server: do edge ao multi-tenant
Se o Hosted Redox é a pista de decolagem, o Redox Server é o voo de cruzeiro. O objetivo é oferecer isolamento leve para serviços (web, banco, aplicações) e evoluir para contêineres “pesados” no futuro, possibilitando ambientes multi-tenant. O plano vem em fases: primeiro bare metal single-tenant (ótimo para edge e servidores privados), depois multi-tenant com contêineres leves (especialmente para WASM), e por fim contêineres completos para workloads arbitrários.
O recado para data centers é simples: menos superfície de ataque, mais previsibilidade. E como o Redox controla recursos por design (mais adiante falaremos de capability-based security), a visão é levar o conceito de “mínimo privilégio” para dentro do próprio kernel e das interfaces de sistema — algo que contêineres tradicionais precisam compensar com camadas adicionais.
Redox Desktop: rumo ao daily driver com o COSMIC
O COSMIC Desktop — construído majoritariamente em Rust — é a aposta para a experiência “daily driver”. Hoje, o Redox já suporta apps-chave do ecossistema COSMIC (Terminal, Files, Editor, Reader, Store), mas falta Wayland e o compositor COSMIC para fechar o círculo. Com Wayland no lugar, entram acessibilidade, i18n/l10n e toda a coesão visual e de UX que o COSMIC promete.
Um detalhe saboroso: a equipe quer experimentar “sandboxing por padrão” no desktop. Em bom português, cada app só acessa o que precisa — e quando pedir algo a mais, o sistema deve comunicar e negociar essa elevação de privilégio de modo consistente e transparente. Dá para ter segurança forte sem atrapalhar o usuário? Eis um dos testes de fogo do Redox Desktop.
O sonho da auto-hospedagem: compilando Redox no Redox
Construir um SO dentro dele mesmo é o rito de passagem de qualquer projeto que se leva a sério. É aqui que a meta de auto-hospedagem entra: editar, compilar e executar no Redox, sem ficar cruzando builds com o host. No curto prazo, a rotina será dentro de VMs em Linux/Windows/macOS, com repositório remoto como “área segura”. A chegada do VirtioFS deve destravar a ergonomia (compartilhando diretórios) e, com o tempo, a equipe quer usar o Redox FS de forma confiável como armazenamento persistente.
Os obstáculos? Rede mais rápida (ring buffers também no stack de rede), consolidar o uso do compilador Rust “upstream”, estabilizar cargo/rustc no Redox, refinar o sistema de build, revisar fluxo de trabalho e… encarar a realidade de que compiladores e builders são maratonistas de processos e arquivos. Se o Redox aguentar essa maratona, ele aguenta muita coisa.
Compatibilidade e ferramentas de desenvolvimento
O Redox não busca 100% de POSIX nem “bug-for-bug” com Linux, mas quer chegar “perto o bastante” para facilitar portabilidade. Agora, além de portar apps, o time adiciona suítes de conformidade para descobrir divergências cedo (ex.: terminal control, timers/alarms, entre outros). No ecossistema Rust, a ideia é testar a compatibilidade da std e crates populares dentro do próprio Redox.
Quanto a linguagens, Rust e C/C++ estão confortáveis; já runtimes como Python “oficial”, JavaScript e Go exigem ganchos específicos na relibc e esforço de portabilidade. Há progresso com RustPython, motores JS e planos para Go. No mundo das ferramentas, shell scripts, GNU Make e utilitários comuns estão razoáveis — mas cada build system traz suas idiossincrasias.
Performance que destrava casos reais
Depois de ganhos grandes em filesystem e I/O (RedoxFS, kernel e stack de disco evoluíram), o foco agora é tirar gargalos remanescentes sem “milagres”: ring buffers no disco e na rede, comutação direta de processos para drivers (pulando o scheduler onde fizer sentido), melhorias de scheduler (EEVDF), lapidação contínua do RedoxFS e métricas sérias de benchmarking. Para desktop e Hosted Redox, hardware-accelerated graphics entra em cena — primeiro via Virtio/virglrenderer, depois GPUs reais.
A ambição é pragmática: ao final do ciclo, performance não deve ser impeditivo para casos realistas. Não é sobre bater recordes sintéticos; é sobre reduzir a fricção para que o Redox seja adotável.
Um futuro seguro com “capability based security”
Aqui está a peça mais ousada. O Redox quer substituir, ao longo dos próximos 12 meses, o modelo tradicional de descritores de arquivos por capabilities — referências de acesso que carregam, nelas mesmas, o que você pode ou não fazer. Pense em um crachá com permissões embutidas, em vez de uma chave mestra para abrir tudo.
Primeiro passo: criar e transferir capabilities entre processos; tornar referências a arquivos relativas a uma capability (na linha do openat(2)); rodar cada programa em um namespace de recursos restrito; e oferecer caminhos POSIX apenas como camada “por cima” do sistema de capabilities. A seguir, a inspiração em Capsicum (BSD) e mecanismos de elevação solicitada, sempre com uma máxima: segurança forte precisa ser usável. Se o usuário não entende o que está acontecendo, a segurança vira ficção.
Hardware e drivers: foco no que importa
Com centenas de mantenedores, o Linux consegue cobrir “tudo”; o Redox, não. A estratégia é selecionar hardware recomendado e, para servidor, buscar parcerias com poucos vendors (x86_64, AArch64 ou RISC-V), mirando drivers de disco, rede, aceleração e gerenciamento. Para desktop/laptops, suportar poucas máquinas bem escolhidas que se traduzam no maior alcance possível.
Tecnicalidades no radar: reescrever o suporte a ACPI com a nova geração de parsers/abstrações em Rust; desenhar o boot/init para firmwares não-ACPI (ex.: IEEE-1275); encarar Wi-Fi (um projeto inteiro por si só); ampliar USB (teclado/mouse/disk já existem, mas o mundo real é mais selvagem); trazer I2C; implementar IOMMU e virtualização para blindar contra hardware/drivers hostis. E há uma ideia experimental ousada: portar QEMU para o Redox e rodar um Linux mínimo dentro dele, expondo drivers de dispositivos menos comuns por uma interface segura — um “hospedeiro de drivers”.
Wayland, GPU e acessibilidade: lapidando a experiência
Para fechar o ciclo do COSMIC Desktop, o Wayland é prioridade; com ele, o compositor COSMIC passa a ser viável e, junto, aceleração via virglrenderer (em VMs) e, depois, GPUs reais (começando por Intel; AMD/NVIDIA dependem de informação e colaboração). Em userland, faltam algumas peças na relibc (ex.: timerfds) e um D-Bus completo em Rust que seja portável para o Redox.
Em i18n/l10n, o objetivo é alinhar-se ao POSIX onde fizer sentido (layouts de teclado além do US, tipografia não latina, fusos/formatos LC_*). Em acessibilidade, há um esforço nascente — inclusive um leitor de tela em desenvolvimento — e um convite claro a quem tem experiência para moldar expectativas e padrões desde cedo. Um desktop moderno que não seja acessível, afinal, não é moderno.
Como contribuir (e por que isso importa agora)
O plano é grande porque o momento é certo. Há bolsas (NGI Zero, NLnet), uma vaga aberta para desenvolvedor(a) de kernel/core, iniciativas de verão de código, e uma comunidade que prefere “mão na massa” a promessas vagas. Se você é bom(a) de Rust, gosta de sistemas e se interessa por runtime/languages (Python/JS/Go), relibc, ptrace/debugging, IOMMU, ACPI, D-Bus, Wayland e companhia, há um backlog significativo esperando por donos.
No fim, a história do Redox para 2025/26 é menos sobre “reinventar o sistema operacional” e mais sobre selecionar batalhas certas: começar protegido (Hosted), provar arquitetura (Server), conquistar corações e mãos (Desktop). Com capability-based security como espinha dorsal e auto-hospedagem como prova de maturidade, o projeto tenta responder à pergunta que importa: dá para ter um SO moderno, seguro por design e — ainda assim — agradável de usar? O roteiro está na mesa. Agora, é executar.
