O que as distros baseadas em Arch mudam, camada por camada

Pergunte no subreddit do CachyOS se deve instalar CachyOS ou Omarchy e as duas respostas mais votadas não são recomendações. Uma diz «Asking this in related to CachyOS sub…bruh». A outra compara-o a entrar num fórum da Honda e perguntar se deve comprar um Accord ou um Camry.

Ambas as respostas estão certas, e a razão é mecânica e não de atitude. As diferenças entre distros baseadas em Arch resumem-se ao ponto em que cada projeto modifica o Arch de origem. Para as distribuições aqui comparadas, essas modificações caem sobretudo em cinco lugares: o instalador, o kernel e os alvos de compilação, os repositórios de pacotes, o shell do desktop e a configuração, e a política de atualização e reversão. CachyOS e Omarchy fazem as suas maiores mudanças em camadas diferentes.

A versão curta

• Para as distribuições aqui comparadas, as diferenças úteis caem sobretudo em cinco camadas: instalador, kernel e alvos de compilação, repositórios de pacotes, shell do desktop e configuração, política de atualização e reversão.
• Um projeto pode mudar uma camada e deixar as outras quatro intactas, e é assim que duas distribuições podem ser ambas «baseadas em Arch» e quase não partilhar nada.
• O CachyOS muda profundamente as camadas do kernel/compilação e dos repositórios, cuida do instalador e não impõe nenhum shell de desktop: escolhe o seu na instalação.
• O Omarchy muda profundamente as camadas do shell do desktop e da política de atualização, gere o seu próprio canal de pacotes e não faz alterações ao kernel ou aos alvos de compilação motivadas pelo desempenho.
• As camadas adotam-se separadamente: o CachyOS documenta como adicionar os seus repositórios a uma instalação Arch existente, e há quem tenha seguido esse caminho no Omarchy com resultados mistos.

O que este artigo não resolve

Três perguntas estão suficientemente próximas desta para serem confundidas com ela, e cada uma precisa de um tipo de prova diferente do que uma taxonomia consegue dar.

• Se o CachyOS é mais rápido em geral. Essa pergunta tem a sua própria base de evidência e o seu próprio artigo.
• Qual das duas deve instalar.
• Todas as derivadas de Arch que existem. Cinco são aqui nomeadas, e estas cinco camadas são um modelo de comparação para este grupo, não uma taxonomia exaustiva de todas as derivadas de Arch.

As cinco camadas que esta comparação acompanha

Para as derivadas aqui comparadas, cinco camadas explicam a maioria das diferenças relevantes: o instalador, o kernel e os alvos de compilação, os repositórios de pacotes, o shell do desktop e a configuração, e a política de atualização e reversão. Um projeto pode mudar uma delas e deixar as outras quatro exatamente como o Arch as entrega.

O instalador é o caminho do hardware nu até um sistema arrancado, e a camada em que um projeto decide quantas escolhas lhe entrega. O Arch de origem documenta um caminho de instalação manual e inclui também o instalador guiado archinstall na sua ISO live; uma derivada pode ainda assim substituir essa experiência pelas suas próprias predefinições guiadas. O que importa é o que esse instalador decide por si: sistema de ficheiros, gestor de arranque, cifragem, controladores, desktop. Cada predefinição é uma posição que alguém tomou.

A camada do kernel e dos alvos de compilação cobre três coisas que se confundem. Que compilação do kernel arranca. Para que conjunto de instruções da CPU os seus pacotes foram compilados. Que escalonador decide o que corre e quando.

Um alvo de compilação é o nível de microarquitetura para o qual um pacote foi construído. x86-64 é a base que todos os processadores x86-64 suportam. x86-64-v3 acrescenta funcionalidades como AVX, AVX2, BMI1, BMI2 e FMA, enquanto x86-64-v4 acrescenta requisitos de AVX-512 por cima da v3. Um pacote construído para qualquer um desses níveis não arranca num processador que não tenha o conjunto de funcionalidades exigido. O escalonador decide qual a tarefa pronta que recebe o processador a seguir, e os escalonadores pesam de forma diferente o débito e a capacidade de resposta interativa. Uma derivada pode mudar os três, um só ou nenhum.

A camada dos repositórios de pacotes é uma questão de proveniência: de quem é a compilação de um pacote que recebe, quão recente é e quem controla o canal por onde chega. O Arch de origem obtém binários de core, extra e multilib, com o AUR ao lado como receitas de compilação que o próprio utilizador compila. Uma derivada pode sobrepor o seu próprio repositório, colocar um atraso deliberado à frente dos do Arch, ou ambas as coisas.

A camada do shell do desktop e da configuração é o que aparece no ecrã e como está organizado, e é aqui que o vocabulário faz as pessoas tropeçar. Um ambiente de desktop como o KDE Plasma ou o GNOME é um pacote completo: gestão de janelas, painel, gestor de ficheiros, definições, aplicações. Um gestor de janelas em mosaico como o i3, ou um compositor Wayland em mosaico como o Hyprland, trata da colocação das janelas sem fornecer um conjunto de desktop completo, deixando a barra, o lançador, as notificações e o ecrã de bloqueio como peças separadas. Uma derivada pode impor um shell, oferecer um menu ou não tomar posição.

A camada de atualização e reversão cobre como o sistema avança e como volta atrás quando avança para um sítio mau. No Arch de origem ambas são suas: pacman -Syu quando decidir, recuperação através da cache de pacotes ou de um esquema de instantâneos que tenha montado. Uma derivada pode encapsular esse comando, bloqueá-lo ou deixá-lo em paz, e pode tornar a recuperação uma predefinição organizando o sistema de ficheiros de modo a que os instantâneos sejam baratos. É isso que um esquema de subvolumes Btrfs compra: um instantâneo é uma cópia pontual de um subvolume, e com integração no gestor de arranque uma derivada pode expor esses instantâneos como opções de recuperação.

O que o CachyOS muda

O CachyOS muda profundamente a camada do kernel e dos alvos de compilação e a camada dos repositórios de pacotes, cuida do instalador e não impõe nenhum shell de desktop. Fornece as suas próprias compilações do kernel e recompila os pacotes do Arch para níveis de funcionalidades de CPU mais recentes, deixando depois o que aparece no ecrã a quem o instala.

O seu instalador permite-lhe escolher desktop, sistema de ficheiros e kernel, além de pacotes e gestor de arranque, e uma ferramenta de deteção de hardware instala controladores para o que encontrar. As opiniões do projeto vivem abaixo do instalador, não dentro dele.

O kernel predefinido linux-cachyos é construído com Clang ThinLTO e perfilagem AutoFDO, e a família oferece BORE, EEVDF e BMQ como escalonadores selecionáveis. Separadamente, suporta o sched-ext, uma framework para carregar um escalonador BPF a partir do espaço de utilizador sem construir um novo kernel. As duas coisas são distintas: o sched-ext troca um escalonador em tempo de execução; não é uma quarta entrada nessa lista.

O CachyOS também recompila os pacotes do Arch para x86-64-v3, x86-64-v4 e Zen4+, e a sua wiki reivindica um ganho de 5% a 20% para x86-64-v3 face à base. É o número do CachyOS para o seu próprio trabalho, não uma medição independente. Os pacotes recompilados ficam num repositório CachyOS sobreposto a core, extra e multilib do Arch, em vez de os substituir. Sobrepor em vez de substituir mantém a proveniência legível: para qualquer pacote continua a poder dizer que canal o construiu.

O shell do desktop é a camada que o CachyOS não impõe. Escolhe o ambiente, embora várias opções venham com definições ou dotfiles mantidos pelo CachyOS. O seu instalador online oferece dezassete ou mais ambientes, incluindo KDE Plasma, GNOME, Hyprland, Niri, Sway e Xfce, e a escolha é sua. O CachyOS Hello e o Kernel Manager são utilitários de gestão do sistema, não um shell.

O CachyOS não exige o seu próprio invólucro de atualização: o pacman -Syu direto continua a ser um caminho documentado, a par de ferramentas opcionais como Shelly, Octopi e atualizações offline. Instalado em Btrfs, o CachyOS organiza subvolumes separados e usa o Snapper para instantâneos de recuperação; as configurações de gestor de arranque suportadas podem expor esses instantâneos para recuperação.

LER

O CachyOS é mesmo mais rápido? De onde vêm realmente os ganhos de desempenho

O que o Omarchy muda

O Omarchy muda profundamente a camada do shell do desktop e a camada da política de atualização, fornece o seu próprio canal de pacotes e não faz alterações motivadas pelo desempenho ao kernel ou aos alvos de compilação. Instala um único desktop fixo e assume o comando de atualização em vez de lhe deixar o pacman.

O Omarchy instala-se a partir da sua própria ISO, no disco inteiro ou no espaço livre ao lado de outro sistema operativo, e cifra o disco por predefinição. O instalador não faz nenhuma pergunta sobre o desktop, porque só há uma resposta.

A camada do kernel e dos alvos de compilação fica em grande parte intacta. O próprio manual do Omarchy descreve-o como uma distribuição baseada em Arch construída em torno do Hyprland e do Quickshell, e nas suas páginas de instalador, atualização, dotfiles e CLI não documenta nenhum kernel personalizado, nenhum alvo de compilação e nenhuma seleção de escalonador. Em hardware comum, o Omarchy corre os pacotes do kernel Arch de origem, que lhe chegam de um espelho do Arch como o resto do sistema. A única substituição de kernel que o manual documenta é para suporte de hardware: nos Mac Intel com chip T2, o instalador configura um kernel linux-t2 com patch.

A camada dos repositórios, essa, muda-a, mas ao longo de um eixo diferente do CachyOS. O Omarchy instala-se como pacotes pacman normais a partir do seu próprio Package Repository, e o seu canal stable predefinido segue um espelho do Arch um mês atrasado face ao mais recente, para que as incompatibilidades apareçam primeiro a montante. Outros três canais (RC, edge e dev) trocam essa margem por frescura.

O Hyprland e o Quickshell chegam juntos, sem possibilidade de recusa. O Hyprland é o compositor Wayland em mosaico; o Quickshell é o kit de construção com que são feitos a barra, o lançador, os menus, as notificações e o ecrã de bloqueio, e é por isso que o Omarchy consegue substituir todo o shell numa versão em vez de distribuir um tema. Essa separação dá ao Omarchy uma base reprodutível definida pelo projeto, mantendo separadas as suas próprias alterações. A configuração divide-se em duas: os seus dotfiles em ~/.config, as predefinições do projeto em /usr/share/omarchy, pertencentes ao pacote e substituídas na atualização. Tudo o que quiser que sobreviva a uma atualização pertence ao seu lado dessa divisão.

A política de atualização é onde a posição do Omarchy é mais vincada. O comando omarchy update executa as migrações pendentes e as atualizações de pacotes numa só operação, tirando primeiro um instantâneo; reverter significa escolher esse instantâneo no gestor de arranque. Recorrer antes ao pacman -Syu esbarra numa barreira: o Omarchy trava uma atualização direta do sistema e remete-o para o seu próprio comando, embora o manual diga que a barreira lhe indicará como a contornar para uma única transação. A questão é o acoplamento: as migrações viajam com as atualizações de pacotes.

LER

Por que o Omarchy é idolatrado e odiado pelos mesmos motivos

Porque é que as discussões de comparação nunca convergem

O CachyOS e o Omarchy tocam em várias das mesmas camadas, mas colocam as suas mudanças mais fortes em sítios diferentes. O CachyOS concentra-se no kernel, nos alvos de compilação e nas compilações de pacotes; o Omarchy concentra-se no shell do desktop e no fluxo de atualização. «Qual é melhor» esmaga essas perguntas separadas numa só.

Sobrepõem-se nas camadas do instalador, dos repositórios e da recuperação, mas não da mesma maneira. O repositório do CachyOS muda como os pacotes do Arch são construídos; o do Omarchy muda quando chegam. O CachyOS deixa disponíveis as atualizações diretas com pacman e acrescenta instantâneos à volta; o Omarchy acopla atualizações de pacotes, migrações e instantâneos atrás do seu próprio comando de atualização.

As duas respostas no topo daquela discussão do CachyOS comprimiam exatamente isto: um diagnóstico correto, entregue sem as cinco camadas por trás.

As camadas podem misturar-se

As cinco camadas adotam-se separadamente em vez de se excluírem mutuamente. O CachyOS publica um caminho documentado para adicionar os seus repositórios a uma instalação Arch, e para os remover de novo. O Omarchy é uma instalação Arch, portanto o mesmo caminho pode levar-lhe os repositórios otimizados do CachyOS.

Há quem o faça. Um comentador numa discussão no r/linux_gaming disse-o sem rodeios: «There's nothing stopping you from installing the cachyos kernel and repositories on omarchy». Alguém publicou um script de instalação para a combinação e partilhou-o no Hacker News.

Independência em princípio não é fiabilidade na prática. Numa discussão no r/omarchy sobre a passagem entre os dois, um comentador relatou que «All of the install scripts and such to do this are currently not working for many people», e que a intervenção manual também não o pôs a funcionar. É uma pessoa numa discussão, e o tipo de problema que vale a pena prever.

O segundo limite está no que a combinação vale. As comparações de desempenho publicadas mostram pouca separação nos FPS médios em jogos, enquanto os ganhos mais amplos do kernel, dos escalonadores e dos alvos de compilação do CachyOS continuam específicos da carga de trabalho em vez de automáticos.

Se o trabalho do CachyOS no kernel e nos alvos de compilação produz um ganho significativo de forma mais ampla, e para que classes de carga de trabalho, assenta numa base de evidência diferente, não na que este artigo resolve.

Construa num VPS Linux com acesso root, NVMe e o poder do AMD EPYC.

Ver planos Linux

Onde o EndeavourOS e o Manjaro se situam nas mesmas camadas

O EndeavourOS e o Manjaro caem nas mesmas cinco camadas com as suas próprias combinações, e é isso que torna o modelo mais valioso do que uma comparação entre dois projetos. O EndeavourOS muda sobretudo a camada do instalador, mas também usa o Dracut para gerar o initramfs e mantém um pequeno repositório para ferramentas e pacotes específicos do EndeavourOS. O Manjaro muda sobretudo a camada dos repositórios, um pouco o instalador, e nada a camada dos alvos de compilação.

O EndeavourOS descreve-se como um sistema Arch leve e centrado no terminal, e o que acrescenta é um instalador guiado, um pequeno conjunto curado de pacotes (Firefox, Yay, FirewallD, Pipewire) e a sua própria ferramenta para controladores de GPU e VM. Sem kernel personalizado, sem recompilação orientada à CPU dos repositórios gerais do Arch, sem desktop imposto: continua a ser a mais próxima do Arch de origem de todas as derivadas aqui nomeadas.

O enquadramento do Manjaro é uma abordagem de estabilidade em cascata. Os pacotes passam pelos ramos unstable, testing e stable nos repositórios do próprio Manjaro em vez de seguirem diretamente os do Arch, e é por isso que um pacote do Manjaro pode ser mais antigo do que o pacote do Arch com o mesmo nome. O seu instalador oferece uma escolha de desktop entre as edições oficiais Plasma, GNOME e Xfce, mais as compilações comunitárias Cinnamon, i3 e Sway.

Traz também uma ferramenta de kernel, e a distinção importa. O Manjaro Settings Manager adiciona e remove kernels, permitindo-lhe correr uma versão de kernel pré-compilada diferente. Escolher entre versões de kernel empacotadas não é a mesma operação que recompilar pacotes para um conjunto de instruções de CPU mais recente, embora ambas se situem na camada do kernel e dos alvos de compilação.

Esse modelo de ramos é também o que separa o Manjaro do mundo das versões fixas. O modelo rolling do Manjaro face ao Ubuntu é a mesma questão de repositórios e política de atualização colocada fora da família Arch. A mesma contabilidade funciona também para lá dessa família. O Ubuntu deriva do Debian e distingue-se dele na cadência de lançamentos, na política de empacotamento e no desktop predefinido.

A página inicial de uma nova derivada costuma dizer-lhe em quais destas camadas toca, e se muda algo fora deste modelo de cinco camadas.

Perguntas frequentes