De volta ao Linux depois de 13 anos: Omarchy no desktop e o widget escrito por um agente open source

Treze anos, três sistemas

Até 2013 o Ubuntu era o meu sistema principal. Saí por um motivo chato e concreto: o trabalho passou a exigir SQL Server e SSMS o tempo todo, e o SSMS é Windows-only. Não tinha contorno razoável, então o Windows virou o sistema e o Linux virou hóspede.

De 2013 a 2016 foi assim: VirtualBox dentro do Windows. Linux rodando de verdade, com fricção de VM, sem nunca ser o SO principal.

Em 2016 a Microsoft anunciou o WSL no Build e soltou o beta em agosto com o Windows 10 1607 — na época ainda com o nome "Bash on Ubuntu on Windows" e só Ubuntu. Isso não me trouxe de volta ao Linux como sistema principal, mas tirou a VM do caminho. Passei quase uma década assim: Windows no chão, Linux dentro dele para desenvolver.

Voltei agora. O Omarchy é o meu SO principal, num laptop de especificação modesta: um Ryzen 7 com 32 GB de RAM. Não é máquina de benchmark, e é justamente por isso que vale registrar que tudo o que este post descreve roda nela sem cerimônia — o shell inteiro em Quickshell, o agente de código, o modelo, os testes.

A parte interessante não é a volta em si. É que cada virada dessas teve um motivo técnico específico — e a última virada tem uma causa que não existia nas anteriores.

O Omarchy, e por que não é "mais um Arch"

O argumento padrão contra o Omarchy é que ele seria "só dotfiles de bom gosto". Foi uma crítica justa por muito tempo, mas ela parou de valer em 14 de agosto de 2026, quando saiu a versão 4.0 — a Quattro.

O que a Quattro fez foi trocar oito peças soltas por uma só. Barra, launcher, menus, notificações, OSDs, painéis de controle, tela de bloqueio e agente polkit saíram de Waybar, Walker, Mako, SwayOSD, hyprlock, hypridle, swaybg e polkit-gnome e passaram a viver dentro de um único processo de shell de longa duração, escrito em Quickshell, com arquitetura de plugin. O Omarchy também migrou as próprias entranhas de git para pacotes de sistema, o que separa o que é do projeto do que é modificação sua.

Isso importa para quem usa, mas importa muito mais para quem escreve código para ele: se o shell é um processo único com plugins, existe um lugar definido onde o seu código mora.

E a Quattro levou isso a sério. Ela traz um sistema de plugins de barra em que widgets de terceiros — e até barras de substituição inteiras — se instalam direto de um repositório git:

omarchy plugin add <git-url>

Existe inclusive um marketplace comunitário, o omarchyplugins.com, cujo repositório é MIT e cujo conteúdo é curado pela comunidade, não pelo projeto. Isso é um detalhe que vale deixar claro: passar pelo marketplace não é endosso de quem faz o Omarchy.

Um parêntese que quase todo texto sobre o Omarchy erra: o README oficial diz que ele é "uma distribuição Linux bonita, divertida e agentic, do DHH", e o projeto hoje vive na organização Omacom, com uma fundação própria em omarchy.org/foundation. Os blogs costumam creditar à 37signals, o que não é o que a fonte oficial diz. E repare na palavra que a própria organização escolheu para se descrever: agentic, não "para desenvolvedores".

E tem uma segunda coisa na Quattro que, para este post, é o ponto todo. Nas notas de release, entre os destaques, está escrito assim:

Omarchy no longer picks a coding agent for you — it asks.

O Omarchy parou de escolher o seu agente de código por você. Ele pergunta. O manual oficial trata o assunto assim: "Omarchy treats AI coding agents as first-class citizens, but it doesn't pick a favorite for you." São doze agentes pré-ligados como launchers preguiçosos — claude, codex, opencode, agy (Antigravity), copilot, crush, grok, pi, omp (Oh My Pi), ori, hermes e muse. Nada é baixado até você rodar o primeiro. Depois disso, SUPER + SHIFT + CTRL + A invoca o seu agente numa janela própria, e a faz o mesmo em qualquer terminal — já aberto em ~/Work, porque agente não guarda confiança no diretório home.

Um sistema operacional colocar "escolha o seu agente de código" como destaque de release é a coisa mais sintomática deste ano.

O que eu queria: um widget de vento no bar

A origem do plugin não é estética, é uma viagem de moto pela Patagônia.

Vento lá não é item de conforto na previsão — é a variável que decide se você anda ou fica parado. Foi por isso que o Windy virou a minha principal fonte de consulta: ele trata vento como assunto sério, e é onde eu passei a confiar para decidir o dia. Usando tanto, descobri a segunda parte: ele também é bem mais preciso nos outros indicadores, não só no vento.

Aí entra o detalhe que fecha a motivação. O widget de clima que o Omarchy já traz — a própria Quattro adicionou um — monta a consulta em cima do wttr.in. Serve para saber se está chovendo agora, e não tem nada de errado com isso. Mas não é a mesma coisa que a Point Forecast API do Windy, que traz escolha entre modelos de previsão e vento por nível de pressão. Eu não queria um widget de clima. Eu queria o Windy na barra.

O que eu construí: um widget de barra chamado Windy (io.github.minholi.windy, versão 1.0.2, MIT), em cima da Windy Point Forecast API. Ele mostra a condição atual e a temperatura na pílula da barra — opcionalmente também a seta de vento girando e a velocidade — e abre um painel com previsão horária de 8 pontos e previsão de 4 dias. A localização é a mesma do widget padrão: os dois leem e escrevem o mesmo weather.json, então não existe dois lugares para manter a cidade certa.

E tem uma configuração que provavelmente não existe em nenhum widget de clima genérico: o nível de pressão do vento — superfície, 850h, 700h, 500h ou 300h. É uma setting que só faz sentido para quem passou a olhar vento do jeito que o Windy mostra. Ela está ali porque foi isso que eu passei a precisar.

O tamanho do que saiu: 3.056 linhas em cinco arquivos.

opencode e DeepSeek V4.1 Flash

O agente é o opencode, open source. O modelo foi o DeepSeek V4.1 Flash, via OpenCode Go — uma assinatura de US$ 10/mês cujo posicionamento oficial é literalmente "limites generosos e acesso confiável aos modelos open source mais capazes".

O pacote saiu inteiro, e a conclusão que me interessa não é o tamanho dele — é o que ele não fez. Não levantou a questão de segurança por conta própria. Isso precisou de uma pessoa.

A decisão que fez o agente funcionar

Se eu tivesse que apontar uma coisa só que fez esse plugin sair, seria esta: todo o miolo ficou em lógica pura, fora do QML.

Isso não é invenção minha — é a convenção do próprio Omarchy, e é o que permite testar. O Model.js não sabe o que é Quickshell: ele recebe dado e devolve dado. O QML ficou com o desenho. E aí node --test roda 260 asserções contra essa lógica sem precisar de Omarchy, Wayland, Qt, sessão gráfica ou servidor. Em menos de 100 ms, na própria máquina.

Essa é a diferença entre um agente que escreve código que parece certo e um agente que verifica o próprio trabalho. Enquanto a verificação depende de você abrir a máquina, olhar o painel e julgar se está bonito, o agente está adivinhando. Quando ela é um comando que devolve verde ou vermelho, ele itera sozinho até acertar — e é ali que as coisas andam rápido.

Repare que isso não tem nada a ver com o modelo ser bom. Tem a ver com o custo de falhar ser zero. O Omarchy é MIT, o QML é aberto, o agente é aberto, o modelo é aberto: essa pilha toda não pede licença para ninguém e roda de graça na sua máquina. Quando testar de novo não custa nada, você testa de novo — e é a única coisa que de fato melhora o resultado.

O que o agente não viu

Aqui é onde eu não quero vender a história melhor do que ela é.

O plugin passou pela validação estrutural e pelo baseline de segurança automático do marketplace. Depois um revisor humano — HANCORE-linux — fez uma revisão manual e achou o que nenhum dos dois pegou: a chave da API do Windy ia como argumento de linha de comando em cada requisição, legível em /proc/<pid>/cmdline, e o mesmo caminho usava o curl resolvido pelo PATH, com o ambiente herdado e sem teto de tamanho na resposta.

O fix saiu no commit 7c5a7d4, a revalidação passou, e a submissão ficou com os rótulos submission e validated.

A lição não é "o agente não presta". É que existiu um revisor humano, e ele era o gargalo que importava — o trabalho mecânico foi do agente, o julgamento de segurança foi de uma pessoa. E é assim que eu quero que continue sendo.

Todo agente, no fim, roda Linux

Eu escrevi este plugin inteiramente com opencode e DeepSeek V4.1 Flash. Mas o ponto do post não é o plugin. É onde o trabalho rodou.

Vale seguir o rastro de como os agentes de código realmente executam as coisas quando você deixa eles soltos.

O Claude Code, da Anthropic, isola os comandos de Bash assim: no Linux e no WSL2 usa o bubblewrap; no macOS usa o Seatbelt da Apple. O Codex CLI, da OpenAI, faz a mesma escolha de fundo — Seatbelt no macOS, e no Linux/WSL2 ele exige o bubblewrap, pedindo que você instale pelo gerenciador de pacotes antes de qualquer coisa. E o Codex hospedado, segundo o anúncio da própria OpenAI, "opera inteiramente dentro de um container isolado e seguro na nuvem".

O bubblewrap é um projeto da organização containers — a mesma do Podman — que constrói o sandbox em cima de recursos do próprio kernel Linux. É software livre, e o usuário mais conhecido dele é o Flatpak.

Ou seja: para decidir o que um agente pode ou não tocar na sua máquina, dois dos agentes fechados mais usados do mundo dependem de uma primitiva de segurança aberta, escrita para Linux e mantida por comunidade. Não é uma peça periférica — é a fronteira em si, o que define o limite do que o agente consegue alcançar.

E não para na segurança. Lembra do loop de verificação da seção anterior? Ele só existe porque há um lugar onde o agente pode rodar comando, instalar dependência, compilar e testar. Na nuvem, esse lugar é um container Linux. Na sua máquina, é o seu Linux — ou o WSL2, que é Linux de novo.

E o harness também

Um nível acima do modelo tem a peça que o Omarchy chama de agente e o resto do mundo chama de harness: o programa que lê o seu projeto, conversa com o modelo, executa ferramenta e devolve o resultado.

Esse é o ponto onde o opencode se destaca, e não é por acaso que foi o meu escolhido. Ele é agnóstico de provedor por construção: você troca o modelo embaixo sem trocar o agente. Na minha experiência ele entrega tão bem quanto o harness da Anthropic, com a diferença de que o modelo não vem amarrado.

Quem leva essa separação ao extremo é o Ori, da OpenRouter, que está na mesma lista de agentes do Omarchy: ele roda os outros harnesses contra o catálogo de modelos da OpenRouter. ori claude, ori codex, ori opencode — o harness de um, o modelo de outro, à sua escolha.

E essa camada não tem um dono só. O opencode (MIT), o Pi do Mario Zechner (MIT), o Oh My Pi (MIT) e o Hermes da Nous Research (MIT) são projetos independentes, de gente diferente, em linguagens diferentes — e todos abertos de verdade.

É isso que o Omarchy está comprando ao não escolher um favorito: uma camada onde a competição é aberta e o modelo é substituível.

E vale registrar uma coisa que eu descobri checando isso, porque ela não é boa notícia. Nem todo agente que se apresenta como aberto é aberto no sentido OSI — existe projeto popular nessa lista usando licença source-available, com restrição de uso competitivo e conversão para MIT só depois de um período. É código visível, não é software livre. Não vou nomear, porque o ponto aqui não é esse fornecedor: o ponto é que a diferença existe, é verificável no arquivo LICENSE, e vale mais do que o rótulo que o projeto usa para se descrever.

Por que pagar por isso

Levo o argumento até o fim, porque acho que ele aguenta.

Se hoje dá para desenvolver software muito rápido — contando com a base de código aberto que já existe — então customizar um software ou desenvolver um praticamente do zero ficou muito mais simples do que era. E isso corrói o valor do software proprietário.

O meu caso é a prova mais boba possível: existia um serviço de previsão em que eu já confiava, um sistema operacional aberto com sistema de plugins, e uma dor específica minha. Deu um widget com 3.056 linhas, 260 asserções e uma revisão de segurança aprovada. Se eu tivesse que justificar isso como compra, num mercado, a resposta honesta é que esse mercado não existe: é pequeno demais para alguém vender — e agora é pequeno demais e barato demais para eu ignorar.

Mas preciso ser preciso, senão o argumento cai.

O que ficou barato foi escrever. Não ficou barato operar. A conta do software nunca foi só o código. Sempre foi suporte, SLA, conformidade, responsabilidade civil, integração, migração e alguém para atender às 3 da manhã. Nada disso ficou mais fácil. Se eu desaparecer amanhã, esse widget não tem quem atenda. É por isso que empresa continua pagando por coisas que ela tecnicamente conseguiria construir.

O mesmo argumento funciona na direção contrária. Se ficou rápido para mim, ficou rápido para quem vende. Velocidade de desenvolvimento não é vantagem exclusiva de quem compra; ela só reduz o fosso quando o produto é o código — e onde o produto é o código, o preço já estava errado antes.

E o formato do problema importa. Um widget de barra é um problema fechado: uma API pública, nenhum dado meu, nenhuma rede. Um sistema com efeito de rede, uma licença regulatória, um volume de dados que ninguém mais tem — esses continuam valendo exatamente o que valiam, porque nunca foi o código que sustentou esse valor.

Onde o argumento fica indiscutivelmente certo é na consequência, e ela é maior do que parece: a linha do "não vale a pena construir" mudou de lugar. Existe uma faixa inteira de software que nunca teve fornecedor porque era específica demais, nichada demais, pequena demais para fechar a conta de alguém. Essa faixa agora tem dono: quem precisa dela. E é justamente a faixa que o software proprietário nunca ia atender, porque nunca ia fechar a conta.

O valor não evaporou — migrou. Saiu de "escrever o programa" e foi para "operar o programa, garantir o programa e responder pelo programa". Quem vende software e acredita que está vendendo código está com o preço no lugar errado.

E o modelo também

Vale checar o mesmo argumento um nível abaixo, no preço do modelo. Aqui os números são públicos nas duas pontas, então não precisa de opinião. Preço de saída por 1M de tokens, nas tabelas oficiais:

• DeepSeek V4.1 Flash — US$ 0,60 a 1,20
• gpt-5.6-luna, o degrau mais barato da família OpenAI — US$ 6,00
• gpt-5.6-sol, o topo da família OpenAI — US$ 30,00
• gpt-5.5-pro — US$ 180,00

Na saída, que é onde o token pesa de verdade: o V4.1 Flash custa 5 a 10 vezes menos que o degrau mais barato da fronteira e 25 a 50 vezes menos que o topo dela. Contra o gpt-5.5-pro a razão passa de 150. Falar em "um décimo do preço" é conservador.

Um degrau de honestidade: Flash de um lado e Pro do outro não são a mesma categoria de capacidade, e o topo ainda pertence aos fechados. Mas aí vem o detalhe que vale mais que qualquer benchmark, e está nas notas da própria DeepSeek: eles escreveram que o V4.1 Flash superou de forma abrangente o V4 Pro em desempenho, custo, velocidade e tempo total — e por isso vão aposentar o V4 Pro, roteando todas as requisições dele para o Flash e cobrando preço de Flash. O modelo barato engoliu o caro do mesmo fornecedor, e o fornecedor anunciou isso com orgulho.

Isso é commoditização acontecendo dentro de uma única empresa, em três linhas de release notes. Quando o preço cai uma ordem de grandeza e o vendedor aposenta o próprio produto premium porque o barato ficou melhor, a capacidade deixou de ser o que se vende. O que se vende é acesso, conveniência e confiança — a mesma migração de novo, agora no insumo.

O software vira commodity. Quem entende o processo, não

Tem uma segunda consequência nisso tudo, e para quem trabalha com software ela é a mais desconfortável.

Se escrever software ficou barato, e se a forma principal de interagir com sistemas passa a ser um agente — você diz o que quer e ele opera —, então o código deixa de ser o diferencial. Ele vira commodity: infraestrutura, como energia elétrica. Essencial, invisível e com preço caindo.

E se o código vira commodity, o gargalo muda de lugar. Ele vai para quem consegue descrever o processo.

Repara no que aconteceu neste plugin e me diz se o agente teve alguma iniciativa sobre o que construir. Não teve. A motivação veio de uma viagem de moto. A escolha do Windy veio de anos consultando ele para decidir se dava para andar no vento da Patagônia. A decisão de expor o nível de pressão veio de eu ter aprendido a olhar vento desse jeito. A definição de "pronto" — condição, temperatura, chuva, seta girando — veio de eu saber o que eu olho quando acordo de manhã.

O agente executou. Executou muito bem, e sem ele nada disso existiria. Mas ele executou a minha especificação, e a especificação já estava inteira antes de ele chegar.

A revisão de segurança tem a mesma forma. O valor do HANCORE-linux naquele comentário não foi digitar código — foi saber que aquilo importava. Julgamento. Foi exatamente a parte que eu mais gostaria que um agente tivesse dado conta, e ele não deu.

Então a habilidade que fica escassa não é programar. É entender o processo de verdade — não a versão de apresentação, mas a versão com as exceções, os casos de borda e o que ninguém documentou — e conseguir traduzir isso em algo que um agente possa executar e verificar. Quem faz essa ponte fica mais importante, não menos.

Conclusão

Treze anos atrás eu saí do Linux porque uma ferramenta me obrigou: sem o SSMS no Windows, o trabalho parava. Voltei porque ninguém mais me obriga a nada — e no caminho descobri que o meu agente de código também não me obriga.

Acho que o aberto venceu, e o motivo tem nome: a evolução dos agentes de IA capazes de operar computadores e ferramentas. Não foi adoção por convicção nem ideologia de ninguém. Foi que, no momento em que o software passou a precisar executar código por conta própria — ler arquivo, rodar comando, instalar dependência, compilar, testar e se corrigir —, o único chão que servia já era aberto, e continuou sendo. O Hermes é um exemplo disso, mas não é exceção: é a regra ficando visível.

O fechado não perdeu na capacidade bruta, e é honesto dizer isso: o topo da capacidade ainda mora nos modelos fechados. Só que capacidade bruta não é onde o trabalho acontece. O trabalho acontece na execução, e a execução já é aberta. O jeito mais difícil de reverter uma vitória é ela ter acontecido por baixo.

E se isso estiver certo, a consequência é maior do que uma disputa de licenciamento. O software vira commodity, escrever código deixa de ser o diferencial, e o que sobra escasso é quem entende o processo e sabe fazer a ponte entre ele e o agente.

Isso não é uma notícia ruim. É uma notícia ruim para quem confundia o preço do código com o valor do problema.

Por isso um widget de vento, que não vale um real de mercado, é o melhor exemplo que eu tenho do que mudou. Treze anos atrás eu escolhia entre o que existia e o que eu queria. Hoje eu construo o que eu quero — e o que determinou a qualidade do que saiu não foi o agente. Foi o quanto eu sabia o que eu queria.

O plugin está em github.com/minholi/omarchy-windy:

omarchy plugin add https://github.com/minholi/omarchy-windy.git --enable

Precisa de uma chave gratuita da Windy Point Forecast em https://account.windy.com/keys.