No ecossistema GNU/Linux contemporâneo, a quase totalidade das distribuições voltadas para usuários finais segue um roteiro previsível: seleciona-se uma base sólida de pacotes (como Debian, Arch ou Fedora), empacota-se um dos grandes ambientes de desktop consolidados — predominantemente GNOME ou KDE Plasma — e adiciona-se uma camada de temas e ferramentas de configuração. Quando algum projeto decide inovar na experiência de usuário, a escolha mais frequente costuma recair sobre frameworks baseados em Chromium ou Electron, trocando a agilidade do sistema por um custo de centenas de megabytes de memória RAM apenas para desenhar painéis e barras de tarefas.

Para romper com esse ciclo de dependências acumuladas e repensar as fronteiras de segurança entre aplicativos, interface e kernel, a iPERFEX — liderada pelos engenheiros Pablo Miranda e Federico Pereira — lançou a versão 0.8.6 Beta do LordOS (código-fonte aberto no GitHub).

Baseado no Debian 13 (Trixie) e disponível para computadores x86_64 de 64 bits e placas Raspberry Pi 5, o LordOS chama a atenção pela ambição de seu projeto de engenharia: ele não utiliza GNOME, KDE, X11, wlroots, libdrm, libinput, WebKit ou GTK/Qt em seu próprio núcleo. Em vez disso, a distribuição implementa um servidor de exibição e compositor Wayland próprio escrito inteiramente em C (lord-server), uma camada de interface em React executada sobre o motor JavaScript ultraleve QuickJS sem qualquer navegador embutido, e um firewall granular por aplicativo aplicado no nível do kernel Linux via eBPF.

O LordOS implementa dois temas de desktop completos trocáveis a quente em React: o padrão Flow e o Classic, ambos renderizados pelo mesmo motor gráfico nativo em C.

A anatomia das camadas: o que é próprio e o que é reutilizado

Uma das decisões de design mais honestas e transparentes do LordOS, detalhada em seu whitepaper técnico oficial, é a separação cirúrgica entre as fundações maduras que valem a pena manter e as camadas de interação do usuário onde a equipe decidiu construir suas próprias soluções:

  1. Kernel Linux: Fornece o subsistema DRM/KMS para comunicação direta com adaptadores de vídeo, evdev para captura de eventos de hardware, e os alicerces criptográficos e de isolamento: Landlock, seccomp-bpf, cgroups v2 e eBPF. No Raspberry Pi 5, o sistema utiliza um kernel próprio com Landlock habilitado.
  2. Userland Debian 13: Mantém o gerenciador de pacotes dpkg, os repositórios APT do Debian, o sistema de inicialização systemd, o servidor de áudio PipeWire, drivers Mesa para aceleração gráfica opcional e bibliotecas de apoio (libwayland, libxkbcommon).
  3. Servidor Gráfico e Compositor (lord-server em C): Responsável por configurar os modos de vídeo via ioctls do DRM do kernel sem passar pela libdrm, gerenciar periféricos de entrada diretamente do evdev sem a libinput, realizar a composição das janelas e implementar o protocolo Wayland para clientes nativos e de terceiros.
  4. Motor de Interface do Usuário: Executa componentes React sobre o QuickJS, com cálculo de layout Flexbox, rasterização vetorial 2D e renderização tipográfica desenvolvidos do zero em código C nativo.
  5. Aplicativos de Usuário: Divididos em três categorias: 31 ferramentas nativas da distribuição (que rodam no contexto do lord-server), aplicativos de terceiros isolados empacotados no formato .lpk, e aplicativos Linux convencionais (Firefox, Chromium, ferramentas GTK e Qt) que se conectam como clientes Wayland tradicionais.
+-------------------------------------------------------------------------+
|                  APLICATIVOS (Nativos, .lpk e Linux)                    |
|   Firefox, Terminal, Monitor, Arquivos, Clientes de IA, Apps GTK/Qt     |
+-------------------------------------------------------------------------+
                                    |
                                    v
+-------------------------------------------------------------------------+
|                  MOTOR DE INTERFACE DO LORDOS                           |
|      React 19 + react-reconciler sobre QuickJS (embutido em C)          |
|      Layout Flexbox próprio · Rasterizador 2D com Damage Tracking       |
+-------------------------------------------------------------------------+
                                    |
                                    v
+-------------------------------------------------------------------------+
|             COMPOSITOR WAYLAND E SERVIDOR DE EXIBIÇÃO                   |
|       lord-server em C (DRM/KMS direto sem libdrm; evdev direto)        |
|      Composição CPU (multi-thread) ou GPU (Mesa GBM/EGL/linux-dmabuf)   |
+-------------------------------------------------------------------------+
                                    |
                                    v
+-------------------------------------------------------------------------+
|                 SISTEMA BASE DEBIAN 13 E KERNEL LINUX                   |
|        dpkg, PipeWire, libwayland, Landlock, seccomp, eBPF, cgroups     |
+-------------------------------------------------------------------------+

Graças a essa arquitetura minimalista, as medições de desempenho registradas pelo projeto no hardware de teste (build 0.7.0 a 0.8.6) revelam que o sistema completo em repouso consome apenas entre 465 MB e 487 MB de memória RAM, dos quais o lord-server com todo o ambiente de desktop representa meros 32 a 36 MB, iniciando a primeira tela gráfica em cerca de 7,4 segundos após o início do kernel.

O compositor lord-server: DRM/KMS direto, multithreading na CPU e GPU sob demanda

Ao contrário de outros compositores Wayland que dependem da biblioteca auxiliar wlroots ou da camada de abstração libdrm, o lord-server abre diretamente os dispositivos /dev/dri/card* e emite os ioctls do kernel para consultar conectores, planos de hardware e CRTCs (kms.c). Ele detecta automaticamente qual placa possui saídas físicas conectadas — o que é indispensável em placas como a Raspberry Pi 5, onde a controladora de tela (vc4) e o acelerador 3D (v3d) são nós separados de hardware.

O gerenciamento de entrada de mouse, teclado e touchpads também dispensa a biblioteca libinput. O LordOS implementa seu próprio interpretador de eventos evdev com suporte avançado a múltiplos toques (server/src/tp), incluindo rejeição inteligente de palma da mão, rolagem cinética natural, gestos com três dedos e pinça, repassando os eventos via zwp_pointer_gestures_v1 para programas Linux comuns.

A geração de cada quadro na tela conta com duas rotas de renderização:

  • Pipeline de CPU (par.c): Desenvolvido para funcionar em qualquer circunstância — mesmo em placas sem aceleração gráfica ou em máquinas virtuais simples (simpledrm, bochs). O pipeline desenha os elementos de interface e janelas em um canvas de memória compartilhada. A partir da versão 0.8.5, quando o desenho de um quadro exige mais de 70% da taxa de quadros alvo, o renderizador ativa automaticamente um pool de até 8 threads em paralelo para calcular o desfoque de fundo (backdrop blur) e rasterizar faixas horizontais de pixels, garantindo fluidez sem gerar discrepâncias visuais. A variável LORD_GPU=0 força esse modo permanentemente.
  • Pipeline de GPU (server/src/gpu/gpu.c): Utiliza as APIs GBM, EGL e GLES2 da pilha Mesa. A interface é tratada como uma textura, onde apenas as áreas danificadas (damaged regions) sofrem upload. As janelas dos aplicativos não são redesenhadas desnecessariamente: a interface deixa "buracos transparentes" exatamente nas posições de cada janela, desenhando as texturas das aplicações por baixo. Programas com suporte a linux-dmabuf entregam buffers de GPU diretamente com zero cópias, e aplicativos em tela cheia realizam direct scanout no hardware.

Para compatibilidade legada com utilitários que ainda dependem do protocolo X11, o lord-server instancia o binário Xwayland do Debian sob demanda, em um namespace de rede isolado e escopo próprio de cgroup, atuando como gerenciador de janelas X11 nativo (xwm.c).

Interface em React sem Chromium: QuickJS e um rasterizador 2D nativo

O uso de tecnologias web para construir interfaces de desktop é frequentemente criticado devido ao peso exorbitante de motores completos como Chromium, WebKit ou Electron. No LordOS, os desenvolvedores adotaram a ergonomia de desenvolvimento declarativa do React 19.3.1, mas substituíram todo o restante da pilha web por código nativo em C.

No lugar de um navegador:

  • O interpretador JavaScript é o QuickJS (versão 2025-04-26 criada por Fabrice Bellard e Charlie Gordon), um motor minúsculo compatível com ES2023 incorporado como biblioteca estática ao lord-server.
  • O renderizador React (runtime/index.js, baseado em react-reconciler 0.34) não cria nós de DOM HTML (<div>, <span>), mas elementos nativos da árvore em C: View, Text e Image.
  • O posicionamento dos elementos é calculado por um motor Flexbox próprio (server/src/ui/layout.c) com suporte a textos invertidos (Right-to-Left, como árabe e hebraico).
  • A tipografia utiliza o rasterizador de glifos stb_truetype em conjunto com um motor próprio de formatação OpenType (otf.c), cobrindo substituições GSUB, posicionamento GPOS, emojis coloridos e algoritmos de bidi da especificação Unicode (alcançando 409 de 409 sentenças de teste idênticas ao HarfBuzz oficial).

Dessa forma, o bundle completo da interface com os 31 aplicativos integrados e o tema visual padrão ocupa apenas 1,9 MB em disco (560 KB comprimido), executando interações a 60 ou 120 fps sem as pausas típicas de coleta de lixo pesada.

Além disso, a segurança do runtime JavaScript é restritiva por design: o JavaScript do LordOS não possui nenhuma API para executar comandos de terminal arbitrários. Qualquer interação com o sistema ocorre por meio de módulos C especializados (lord.fs, lord.settings, lord.net, lord.fw), que impedem gravações fora dos diretórios de dados permitidos e rejeitam caminhos críticos do sistema operacional.

O Firewall Visível: monitoramento e contenção em tempo real com eBPF

Um dos diferenciais mais marcantes do LordOS é a integração do controle de tráfego de rede à experiência visual do usuário. Enquanto a maioria das ferramentas de segurança opera apenas com regras cegas de portas e endereços IP (via iptables ou nftables), o LordOS atua no nível de processos e aplicativos.

O Monitor de Rede exibe as conexões estabelecidas por cada software em um mapa global interativo, alimentado por programas eBPF rodando diretamente no kernel Linux.

Quando um programa é iniciado a partir do lançador do sistema, o lord-server solicita a criação de um escopo exclusivo no systemd e cgroups v2 (app-lordos-<id>.scope). Como a criação do escopo pertence ao usuário root, o aplicativo não tem permissão para se mover para outro grupo ou escapar de sua etiqueta.

Em seguida, um daemon do sistema (lord-netperm) carrega programas eBPF nos ganchos de rede do cgroup:

  • cgroup/connect4 e connect6 (interceptação de tentativas de conexão TCP/UDP de saída);
  • cgroup/sendmsg4 e sendmsg6;
  • cgroup/bind4 e bind6;
  • cgroup/dev (bloqueio de nós de hardware como /dev/video* para webcams ou /dev/snd para microfone);
  • socket_create via BPF LSM (para controle de módulos Bluetooth).
Nas configurações de privacidade, o usuário pode definir regras explícitas de acesso: permitir apenas rede local (LAN), bloquear totalmente a internet ou revogar permissões de hardware.

Sempre que uma aplicação tenta abrir uma conexão, o gancho eBPF consulta o cgroup de origem no kernel em microssegundos. Se o aplicativo estiver configurado como bloqueado nas preferências, a chamada de sistema retorna imediatamente o código de erro EPERM (Operation not permitted). Caso a conexão seja aceita, os contadores de bytes e pacotes são transmitidos por um ring buffer para o aplicativo Monitor, permitindo acompanhar em tempo real taxas de transferência, nomes de domínio consultados e localizações geográficas em um mapa-múndi estilizado.

Para aplicativos empacotados no padrão nativo .lpk e o cofre de senhas (lord-vault), o sistema aplica ainda uma camada adicional de sandbox com Landlock e filtros seccomp-bpf, impedindo chamadas a ptrace, montagem de volumes, criação de novos namespaces ou injeção de código em outros processos do usuário.

Loja de Aplicativos e ecossistema de ferramentas de IA

A partir da versão 0.8.5, a central de aplicativos do LordOS ganhou uma seção inteiramente dedicada a Inteligência Artificial, estruturada a partir de um catálogo curado em seu repositório oficial (apt/catalog.json).

A loja de aplicativos integra ferramentas de desenvolvimento orientadas a IA com verificação criptográfica de repositórios oficiais e compilações herméticas.

A distribuição facilita a instalação tanto de ferramentas executadas localmente quanto de ambientes baseados em nuvem:

  • Instalação direta de fontes oficiais assinadas: Softwares como Claude Code, Claude Desktop, Cursor e Visual Studio Code são instalados a partir dos repositórios APT oficiais de seus respectivos desenvolvedores. O LordOS exige a verificação das chaves públicas (Ed25519 ou RSA) e suas assinaturas InRelease, bloqueando modificações no sistema se o fingerprint da chave divergir do catálogo auditado.
  • Modelos e ferramentas locais herméticas: Aplicações de inferência local como llama.cpp (versão 0.7.0), whisper.cpp (1.9.5) e codex-cli (0.164.0, com assinatura sigstore/cosign verificada) são compiladas hermeticamente pelos mantenedores da distribuição dentro de contêineres limpos Debian Trixie. O llama.cpp inclui suporte automático a backend Vulkan quando detectado no hardware e suporte à flag -hf para baixar modelos diretamente do Hugging Face.
  • Suporte a WebAssembly 2.0: O lord-server inclui um interpretador WebAssembly completo em C (server/src/wasm), permitindo que aplicativos empacotados em .lpk incorporem módulos de alta performance compilados a partir de Rust, C, C++ ou Zig sem depender de compiladores adicionais na máquina do usuário.

Como testar o LordOS 0.8.6 Beta

O LordOS pode ser experimentado ou instalado de três maneiras distintas:

  1. Imagem Live ISO (x86_64): Permite inicializar um computador com suporte a BIOS ou UEFI diretamente a partir de um pendrive USB, oferecendo um instalador gráfico guiado que preserva discos com segurança.
  2. Imagem oficial para Raspberry Pi 5: Imagem gravável para cartões microSD ou unidades NVMe (lordos-0.8.6-rpi5-arm64.img.xz), incluindo controle de rotação da ventoinha através do serviço lord-fand e inicialização rápida pré-configurada.
  3. Instalação sobre o Debian 13 (Trixie): Em computadores que já executam a versão de testes do Debian 13, o ambiente completo pode ser instalado por meio do script oficial:
curl -fsSL https://lordos.org/install.sh | sh

O script baixa e valida a assinatura criptográfica Ed25519 do manifesto SHA256SUMS, confere a integridade dos pacotes .deb e adiciona o repositório assinado do LordOS ao sistema.

Ao combinar uma fundação robusta de pacotes Linux com uma reconstrução meticulosa das ferramentas de interface e controle de rede, o LordOS se posiciona como um dos projetos open source mais fascinantes dos últimos anos — provando que ainda há muito espaço para reimaginar o desktop livre sem abrir mão da leveza, da estética e da privacidade no kernel.