No artigo anterior sobre Omarchy, eu bati bastante na crítica de que o projeto seria só "Arch com uns dotfiles".

  Na época eu já achava essa descrição incompleta. Depois da notícia de 3 de setembro, ela ficou ainda mais difícil de defender.

  A Omacom Foundation anunciou sua primeira contratação em tempo integral: Krzysztof Wilczyński, desenvolvedor do kernel Linux. Ele vai liderar o Omarchy Kernel e integrar
  o Omarchy Core.

  O nome pode induzir ao erro se você lê rápido.

  Omarchy não está criando um kernel novo para substituir Linux. Não existe anúncio de scheduler novo, gerenciamento de memória próprio, rede reescrita, drivers próprios ou
  uma arquitetura de sistema operacional feita do zero.

  O que está sendo formalizado é outra coisa: uma variante do kernel Linux mantida para as necessidades da distribuição.

  Parece detalhe semântico, mas não é.

  Criar um kernel novo seria assumir tudo. Scheduler, memória, drivers, segurança, ABI, networking, manutenção de hardware antigo, hardware novo, bugs estranhos de BIOS de
  notebook e todo o resto.

  Manter uma variante do Linux significa assumir responsabilidade por:

  - versão usada;
  - .config;
  - patches;
  - backports;
  - quirks;
  - hardening;
  - compatibilidade de hardware;
  - regressões;
  - e, idealmente, mandar correções de volta para upstream.

  É isso que Omarchy está fazendo.

  E a parte mais interessante é que eles já estavam fazendo antes de dar um nome para o problema e contratar alguém para cuidar dele.

  

  O caso Panther Lake praticamente explica sozinho por que essa vaga existe.

  Quando Intel e Dell começaram a trabalhar com Omarchy em máquinas Panther Lake, o kernel entregue normalmente pelo Arch ainda não tinha toda a cadeia de suporte necessária para aquele hardware.

  A resposta foi o linux-ptl, uma build modificada do Linux voltada a Panther Lake.

  No release 3.6, Omarchy registra uma build customizada do Linux 6.19.13, com patches para Panther Lake e trabalho trazido de versões posteriores do kernel. A nota também fala em colaboração contínua com Intel e Dell, além de backports da linha 7.0 para melhorar compatibilidade e eficiência.

  Não era só uma questão de fazer a máquina dar boot.

  A release cita idle perto de 2 W no Framework 13 Pro com painel IPS e aproximadamente 2,2 W no Dell XPS OLED de 16". Também vieram correções para display, Thunderbolt, energia e outros componentes.

  É nesse ponto que uma distro deixa de ser apenas uma seleção de pacotes.

  Instalar Hyprland é fácil.

  O trabalho começa quando você precisa garantir que um notebook lançado agora:

  - inicialize;
  - reconheça o display;
  - tenha áudio;
  - conecte no Wi-Fi;
  - suspenda;
  - acorde;
  - não fique torrando bateria parado;
  - funcione direito com monitor externo.

  É uma camada bem diferente de responsabilidade.

  

  Arch entrega software recente muito bem.

  Mas software recente não é a mesma coisa que suporte antecipado para todo hardware que acabou de sair da fábrica.

  São problemas diferentes.

  Imagine um notebook novo com uma implementação nova de áudio, GPU recente e alguma mudança em PCIe.

  A correção para cada problema pode existir em lugares diferentes:

  - uma está em linux-next;
  - outra já foi aceita para a próxima versão;
  - uma terceira ainda está em revisão.

  Para quem desenvolve kernel, isso é normal.

  Para quem acabou de ligar um notebook de US$ 2.000, não importa muito. A máquina precisa funcionar agora.

  É para isso que existe backport.

  Linux futuro
      │
      ├── correção A
      ├── correção B
      └── suporte novo
            │
            ▼
        backport
            │
            ▼
  kernel atual da distribuição

  No desenho parece simples.

  No código, não.

  Um patch pode depender de outro commit. Esse commit pode depender de uma mudança de API. A mudança de API pode pressupor uma alteração feita semanas antes em outro subsistema.

  Trazer uma correção de uma versão futura nem sempre é fazer git cherry-pick e seguir a vida.

  É aqui que o perfil da contratação chama atenção.

  Krzysztof Wilczyński trabalha no subsistema PCI do Linux. Ele está ligado a PCI Endpoint, drivers de host bridge e endpoint, além de revisões de trabalho envolvendo PCI e Rust.

  Isso fica muito perto da camada onde hardware novo costuma começar a quebrar.

  PCIe não é um assunto distante para quem usa desktop ou notebook. É por ali que passam, ou se relacionam, dispositivos como GPU, NVMe, rede, controladores e outros periféricos da máquina.

  CPU
   │
   └── PCIe
        ├── GPU
        ├── NVMe
        ├── Network
        ├── Controllers
        └── outros dispositivos

  E junto vêm problemas de enumeração, gerenciamento de energia, ASPM, hotplug, bridges e peculiaridades de plataforma.

  Não é contratar alguém para baixar o source do kernel e rodar:

  

make menuconfig
make -j $(nproc)

  É contratar alguém que já participa do processo upstream do Linux.

  Para o que Omarchy pretende fazer, essa diferença é grande.

  

  Omarchy resume a proposta do kernel em três palavras: performance, compatibilidade e segurança.

  As três fazem sentido. Mas não estão no mesmo estágio de definição.

 
Performance


  Eu não esperaria um "Omarchy Scheduler" revolucionário.

  Pelo histórico de Panther Lake, o trabalho parece mais próximo do que realmente importa em notebook:

  - gerenciamento de energia;
  - runtime PM;
  - P-states e C-states;
  - dispositivos entrando em idle corretamente;
  - GPU consumindo o necessário;
  - suspend e resume;
  - tempo de boot;
  - eficiência energética.

  Os números apresentados com Panther Lake apontam exatamente nessa direção.

  Em desktop, é fácil reduzir performance a benchmark.

  Em notebook, gastar 2 W parado em vez de 5 W também é performance. Só aparece em outra métrica.

 
Compatibilidade 


  Para mim, essa é a parte mais importante.

  Existe uma diferença grande entre "Linux suporta o dispositivo" e "instalei e funcionou".

  Quem usa Linux conhece a história:

  - o driver existe, mas falta firmware;
  - Wi-Fi funciona, Bluetooth não;
  - suspend funciona, resume não;
  - monitor externo só funciona depois de adicionar parâmetro de kernel;
  - GPU funciona, mas uma economia de energia específica causa flicker.

  É esse monte de detalhe pequeno que forma a experiência real do sistema.

  Uma distro que vende first-boot experience em hardware recente precisa assumir responsabilidade por isso. E é o que Omarchy parece estar começando a fazer.

 

  Tem um detalhe nos releases recentes que eu achei mais interessante que a simples criação de uma árvore customizada.

  No release 3.8.3, Omarchy informa que somente o Dell XPS ainda precisava do linux-ptl. Outros sistemas Panther Lake passaram a receber o kernel vanilla 7.0.3.

  Isso é um bom sinal.

  O fluxo parece ter sido este:

  hardware novo
      ↓
  mainline ainda incompleto
      ↓
  linux-ptl + backports
      ↓
  upstream avança
      ↓
  kernel vanilla resolve
      ↓
  linux-ptl deixa de ser necessário

  É exatamente assim que eu gostaria de ver o futuro Omarchy Kernel funcionando.

  Não manter patch porque ele virou "patch do Omarchy".

  Manter porque ele é necessário.

  Quando upstream resolve o problema, remover.

  

  Um kernel de distribuição pode seguir dois caminhos.

  O caminho saudável é este:

  Linux upstream
        │
        ▼
  pequeno patchset
        │
        ▼
  Omarchy

  O caminho caro é este:

  Linux upstream
        │
        ├───────────────┐
        ▼               │
   centenas             │
   de patches           │
        ▼               │
  mais patches          │
        ▼               │
  mais divergência      │
        ▼               │
  kernel praticamente
  mantido sozinho

  APIs internas do Linux mudam. Drivers mudam. Um patch novo mexe na mesma área. Sai uma CVE. A próxima versão quebra um backport.

  Aí vêm conflitos, regressões e versões paralelas porque um hardware funciona melhor em uma e outro hardware funciona melhor na seguinte.

  É daí que vem o custo real.

  Então um indicador simples de qualidade para o Omarchy Kernel será o tamanho e a idade do patchset fora do upstream.

  Trinta patches que entram e saem conforme upstream absorve correções é uma coisa.

  Três mil patches acumulados por anos é outra.

  

  Dos três objetivos anunciados, segurança é o menos documentado.

  "Security" aparece na proposta, mas ainda não existe especificação técnica sobre:

  - opções CONFIG_* de hardening;
  - LSM usado;
  - política de CVE;
  - kernel LTS ou latest;
  - prazo de atualização;
  - patches externos;
  - política de lockdown;
  - diferenças em relação ao config do Arch.

  Dizer que haverá foco em segurança é intenção.

  Para virar decisão técnica, precisa aparecer o .config, os patches e a política de release.

  Até lá, eu deixaria essa parte em aberto.

  

  A contratação veio menos de duas semanas depois da criação da Omacom Foundation.

  Quando escrevi o artigo anterior, ela tinha acabado de chegar a US$ 10 milhões. Agora são US$ 14 milhões comprometidos, entre Founding Patrons, Distinguished Patrons e patrocinadores corporativos.

  DHH também anunciou que o plano é gastar o dinheiro arrecadado neste ano ao longo dos próximos três, em vez de formar um endowment.

  Com US$ 13 milhões, isso dá mais de US$ 4 milhões por ano em 2027, 2028 e 2029, antes de qualquer nova entrada.

  Até agora, o dinheiro foi para Hyprland, Quickshell, mise, artistas, infraestrutura, competições e plugins. A fundação confirma que já é patrocinadora exclusiva do Hyprland e premier sponsor de Quickshell e mise.

  A contratação de alguém para kernel muda um pouco o modelo.

  Antes, era financiar dependências que Omarchy usa.

  Agora, também existe engenharia interna para integrar Linux ao hardware.

  

  A contratação é interessante, mas ainda faltam respostas para entender se o Omarchy Kernel será bom tecnicamente.

  Qual será a base? Arch linux? Mainline? Stable? LTS?

  Vai existir algo como linux-omarchy e linux-omarchy-headers? O linux-ptl continuará existindo como árvore específica?

  Qual é o critério para trazer um backport? E principalmente: qual é o critério para removê-lo?

  Alterações genéricas vão para upstream? Existe política formal? Quem acompanha os patches depois que eles são enviados?

  Também quero ver o básico:

  PKGBUILD
  .config
  patches/
  CI
  reproducibility

  E quero ver a matriz de hardware.

  Dell XPS? Framework? ThinkPad? AMD? Intel? NVIDIA?

  O projeto fala tanto de hardware novo quanto de máquinas antigas. Em algum momento vai precisar dizer claramente onde testa e o que promete suportar.

  

  O ponto não é que cada etapa dessa sequência seja revolucionária. Não é.

  O ponto é a responsabilidade acumulada:

  dotfiles
     ↓
  post-install
     ↓
  ISO
     ↓
  repositório
     ↓
  updates
     ↓
  hardware enablement
     ↓
  Dell / Intel
     ↓
  linux-ptl
     ↓
  kernel developer full-time
     ↓
  Omarchy Kernel

  É por isso que "só Arch com dotfiles" vai ficando uma descrição tecnicamente cada vez menos útil.

  Omarchy continua usando Arch. Continua usando Linux. Continua usando Hyprland. Continua usando centenas de projetos que não criou.

  Como qualquer distribuição.

  A diferença é a quantidade de responsabilidade que começou a assumir para fazer essas peças funcionarem juntas.

  

  A notícia não é "DHH está criando um kernel".

  Não está.

  A notícia é menos espetacular e bem mais relevante: Omarchy está criando capacidade própria para manter uma variante do Linux.

  E já existe um problema real que justifica isso.

  O linux-ptl apareceu porque Panther Lake precisava de código que ainda não chegava pelo caminho normal do Arch. Quando o kernel vanilla passou a atender parte dessas máquinas, Omarchy começou a retirar a dependência do kernel customizado.

  Esse histórico é a melhor pista de como o Omarchy Kernel pode funcionar.

  Daqui para frente, eu vou acompanhar quatro coisas:

  patchset
  rebase
  upstream
  hardware matrix

  Se o patchset permanecer pequeno, se as correções genéricas subirem para Linux e se os patches forem removidos quando upstream resolver o problema, é uma arquitetura saudável.

  Se a divergência permanente começar a acumular, a avaliação muda completamente.

  Por enquanto, a contratação mostra que Omarchy identificou um problema real de distribuição Linux: software recente não basta. Alguém precisa cuidar do espaço entre o kernel upstream e o hardware que o usuário comprou hoje.

  Agora tem alguém pago para fazer isso.