Por dentro do Frevo
Quase toda distribuição Linux é uma combinação: um sistema-base, um ambiente de desktop pronto (KDE, GNOME, XFCE…) e um tema por cima. O Frevo é uma aposta diferente, e esta página explica a aposta, o que ela custou até agora e o que ainda falta pagar.
A ideia em uma frase
O pecado do Electron não é o navegador ser pesado — é cada app embarcar o seu próprio. No Frevo o motor é um só, compartilhado pelo sistema inteiro, e um app é um pacote de JavaScript de poucos KB.
Todo o desktop — painel, menu, tela de login, tela de bloqueio, Configurações, Feira, instalador — é escrito em React e desenhado por um único motor web, o WPE WebKit (o mesmo que a LG usa no webOS das TVs). Não há um Chromium por app; há um motor por sistema. E há um compositor gráfico nosso, em Rust, que faz o que um motor web não faz: janelas, teclado, mouse, monitor, bloqueio de sessão.
As peças
A base: Arch Linux
Rolling release, pacman, systemd — e os serviços que toda distro séria usa: NetworkManager, PipeWire, BlueZ, UPower, UDisks2. O Frevo não reinventa rede, som ou energia; ele põe a própria cara em cima. O gerenciador de pacotes se chama passo, mas é um invólucro fino: tudo que ele recebe vai para o pacman sem tradução. Quem já sabe Arch já sabe Frevo.
O compositor: frevo-comp (Rust + Smithay)
É o programa que “é” a tela: fala Wayland com os apps, desenha as decorações de janela (as três bolinhas, a vermelha fecha), o ponteiro do mouse, o volume na tela e o indicador de carregamento. Escrito em Rust com a biblioteca Smithay — a mesma do COSMIC, da System76. Roda em DRM/KMS direto no hardware, com libinput para teclado e mouse.
O motor: WPE WebKit
Um WebKit feito para dispositivos embarcados, sem a casca de navegador. O Frevo o usa como runtime único: cada superfície do shell é uma página que ele desenha numa janela Wayland. Um pequeno programa em C, o frevo-appman, embute o motor e faz a ponte entre o JavaScript e o sistema — arquivos, rede, som, pacotes, notificações, polkit.
O instalador: frevo-installd
Em vez do Calamares (o instalador genérico de muitas distros), um daemon nosso em Rust, com 78 métodos D-Bus tipados e 392 testes que rodam sem root e sem disco. A tela é React, como tudo; o trabalho pesado é do sgdisk, cryptsetup, pacstrap e bootctl do Arch. Faz dual boot preservando o Windows, disco criptografado com LUKS2, Btrfs com instantâneos — e instalação desatendida por receita .json, pensada para um laboratório de escola com quarenta máquinas iguais.
A mídia
A ISO é construída com o archiso, o mesmo do Arch, e leva dentro um repositório de pacotes próprio: o sistema instala completo sem internet. Boota por UEFI e por BIOS legado, grava com dd ou funciona como imagem no Ventoy.
Por que React?
Três motivos, do mais prático ao mais ambicioso.
- Quem sabe React já sabe fazer app para o Frevo. Não precisa aprender Qt, GTK ou uma linguagem nova. Um app do sistema é um componente React que usa a biblioteca de componentes e o SDK
@frevo-os/sdkpara falar com a máquina. - A biblioteca já existia. A cosmemilton-ui, com 130 componentes e 11 temas, é do autor do Frevo. O desktop é a biblioteca, com um tema chamado “frevo”: grafite, vidro e papel, o vermelho como único acento.
- O contrato é a API da biblioteca, não o motor. Hoje o motor é web (a “Trilha 1”). O plano tem uma “Trilha 2”: um renderizador React nativo, com layout, texto e desenho em Rust — e os apps não precisariam ser reescritos, porque nunca dependeram do DOM. É a parte mais arriscada do projeto, e ainda não começou.
Os desafios até aqui
Fazer um desktop do zero é descobrir tudo o que o KDE e o GNOME resolveram há vinte anos e que ninguém mais nota. Alguns dos bugs que marcaram os primeiros dias, contados como aconteceram:
O ponteiro que clicava no lugar errado
Na máquina virtual havia dois ponteiros na tela — e o clique caía longe de onde o ponteiro aparecia, cada vez mais longe conforme se afastava do canto superior esquerdo. A primeira suspeita foi o compositor: no Linux direto no hardware, ninguém desenha o ponteiro por você, e o frevo-comp tinha acabado de aprender a desenhar o seu.
A prova veio de uma medição: injetando o mouse em 0%, 50% e 100% da tela pelo monitor do QEMU, o compositor calculava 0, 640 e 1280 pixels num modo de 1280 — exato. A culpa era do host: a janela do QEMU desenhava o ponteiro do Windows por cima e, ao mesmo tempo, escalava a imagem do sistema para caber. Uma escala tem ponto fixo em (0,0); por isso os dois cursores divergiam proporcionalmente à distância do canto. Dois parâmetros na linha de comando da VM, e o Frevo ganhou também uma seta desenhada dentro do próprio binário, para nunca mais subir sem ponteiro.
A tela de login que precisava de internet
As páginas do shell carregavam o React e a biblioteca de componentes de uma CDN. Funcionava na bancada. Numa máquina sem rede, a distro era uma tela preta — e a única forma de ter rede era o módulo de Wi-Fi das Configurações, que precisava de rede para renderizar. Um deadlock literal.
A solução óbvia — empacotar tudo localmente — quebrou três vezes de três jeitos (duas cópias do React na mesma página, exports que somem na conversão, require onde só cabe import) antes de funcionar na quarta. Hoje é regra da casa: nenhuma página do sistema toca a internet para existir. Provado com a CDN bloqueada no /etc/hosts.
O bit de execução que sumia em silêncio
Primeira ISO: tudo “ativo” no systemd, e tela preta. Nada no log. O construtor da mídia copia os arquivos descartando as permissões — o compositor chegava no disco sem o direito de ser executado. Semanas depois, a mesma classe de erro por outro caminho: scripts editados do Windows, pelo compartilhamento do WSL, perdem o bit de execução na travessia, e o git registrou a perda no commit. Resolveu-se com uma verificação no build que falha em dois segundos em vez de entregar uma tela preta depois de vinte minutos.
O teclado preso em “us” — o bug mais caro
A sessão gráfica subia sem herdar o layout de teclado. Parece detalhe, até se juntar com o disco criptografado: a pessoa define a senha do cofre no instalador com um ç que, no boot seguinte, não existe — e o disco fica inacessível para sempre. Hoje os scripts de sessão derivam o layout da mesma fonte que o boot usa. E descobriu-se, de brinde, que o WPE não linkava a tabela de acentos: as teclas mortas morriam em toda página do shell. O compositor ganhou o próprio servidor de entrada de texto, validado com “çá” digitado por script e conferido em foto.
Trezentos e cinquenta e nove testes verdes, três bugs reais
A primeira instalação de verdade achou o que a suíte não podia achar: um nome de pacote do Debian no meio da lista do Arch; o cache do pacstrap indo para a RAM do live em vez do disco de destino; e um systemctl enable que, ao não achar um serviço, derruba a chamada inteira e leva a rede junto. Lição registrada: o teste prova que o comando sai como o plano diz, não que o comando funciona na máquina de destino.
O clique no menu que caía num buraco
Abrir o menu e clicar em “Instalar” não fazia nada — só no primeiro boot, quando tudo está frio. O menu pedia tela inteira ao compositor, mas até o motor confirmar o novo tamanho a superfície ainda tinha 40 pixels de altura; o clique passava pelo menu desenhado e caía no wallpaper. Consertou-se nas duas pontas: a página só desenha o menu depois de crescer de verdade, e o compositor trata o menu como modal desde a intenção, não desde o commit.
Miudezas que custaram horas
O banco do repositório de pacotes é um link simbólico, e link simbólico não viaja para dentro de uma ISO. O boot levava 106 segundos por um impasse de cinco serviços esperando um ao outro. O splash piscava na troca para o login porque dois modos de vídeo “iguais” não eram a mesma struct. O motor web escolhia a placa de vídeo errada quando havia duas — como em todo notebook híbrido. E a tela final do instalador mandava tirar o pendrive antes de reiniciar, com o sistema live rodando de cima dele.
O que ainda falta
Muita coisa — e a lista é pública. Os itens grandes, na ordem em que precisam acontecer para existir uma versão testável:
- Hardware de verdade. Tudo até aqui foi provado em máquina virtual. Placa de vídeo real, Wi-Fi real, notebook híbrido, tela 4K: cada um vai trazer os seus bugs.
- Os módulos do cotidiano. Bluetooth, energia, teclado, mouse, contas, data e idioma, acessibilidade — as Configurações hoje têm rede, som, tela, personalização, impressoras, firewall e atualizações.
- Segurança para apps de terceiros. Hoje a ponte entre o JavaScript e o sistema não tem portão: qualquer página do shell pode listar janelas, ler notificações ou pedir a senha do Wi-Fi. Isso é aceitável enquanto todo app é nosso e inaceitável no dia em que não for. Sandbox e manifesto de permissões vêm antes de qualquer loja aberta.
- O canal de atualização. Um repositório assinado em
repo.frevo-os.orge o pacote de chaves — sem isso, quem instala fica órfão. - Arestas visíveis. A tela de login será redesenhada; Ctrl+C ainda não copia nas páginas do shell (o motor não publica a seleção para o Wayland); o Arquivos ainda não abre pendrive — o sistema monta e avisa, mas nunca executa nada sozinho, por decisão.
- A Trilha 2 — o renderizador nativo — fica para depois da versão testável.
Como é desenvolvido
Por uma pessoa, com agentes de código (Claude Code) como par de programação: o autor decide, aprova mockups e veta; os agentes escrevem, testam e documentam — e cada decisão estrutural tem data e motivo anotados. O primeiro commit é de 5 de agosto de 2026; onze dias depois a ISO instalava e caía no desktop. A bancada é um WSL2 sem placa de vídeo, então o hardware é simulado numa VM QEMU, e boa parte dos testes é literalmente fotografar a tela da VM e conferir a foto.
pacstrap fica à vista enquanto instala.
Quer os detalhes? O código é público, e cada pacote do repositório tem o seu próprio guia, com o que funciona, o que não funciona e por quê.