Embaixo dessa história toda tem uma decisão que quase ninguém faz conscientemente: o filesystem. O Synology usava btrfs o tempo todo. O QNAP usa ZFS. E a sua máquina Linux, muito provavelmente, veio de fábrica com ext4 sem ninguém te perguntar nada. É sobre isso.

De onde vieram os dois

O ext4 é o final de uma dinastia de mais de três décadas. O ext (extended filesystem) nasceu com o próprio Linux, o ext2 virou padrão nos anos 90, o ext3 adicionou journal em 2001 pra não precisar de fsck épico depois de cada queda de energia, e o ext4 chegou em 2008 com extents, alocação atrasada e volumes de até 1 exbibyte. O objetivo de design sempre foi o mesmo: ser o filesystem padrão, rápido, simples e previsível. Ele é excelente nisso. E parou aí.

O btrfs nasceu em 2007, na Oracle, com o Chris Mason, com um objetivo completamente diferente: ser a resposta do Linux ao ZFS. Em vez de escrever dado por cima de dado, ele é copy-on-write: toda escrita vai pra um bloco novo e os ponteiros são atualizados em cascata na árvore. Essa decisão única é a mãe de tudo que interessa nele.

O que cada um entrega, na lista:

ext4:

• journaling (metadados consistentes depois de queda)
• extents e alocação atrasada (boa performance)
• maduro, estável, em todo lugar, qualquer ferramenta funciona

btrfs:

• copy-on-write em tudo
• checksum de dados e metadados em cada bloco
• snapshots instantâneos e baratos
• subvolumes independentes dentro do mesmo volume
• compressão transparente (zstd, lzo, zlib)
• RAID nativo e scrub (varredura de verificação)
• send/receive de snapshots pra backup incremental
• reflinks (cópias que não duplicam blocos)

A lista já responde a pergunta do título. Vamos por partes.

Até o NTFS e o APFS passaram o ext4

E se a comparação com o btrfs parece injusta, olha pro lado. O NTFS nasceu em 1993, com o Windows NT, já com journaling de metadados e ACLs, e ainda nos anos 2000 ganhou o log de todas as mudanças do volume e as cópias de sombra (o “Versões Anteriores” do Windows). O APFS, que a Apple lançou em 2017 feito pra flash, é copy-on-write como o btrfs: snapshots nativos (é o que o Time Machine usa pra restauração local), clones instantâneos de arquivo que compartilham blocos, volumes compartilhando o espaço do mesmo container e criptografia por arquivo.

Leia de novo a lista do ext4 e compare: sem snapshot, sem checksum de dados, sem CoW, sem compressão. O filesystem do Windows e o do Mac, que ninguém considera exemplos de sofisticação, protegem os seus dados melhor que o padrão do Linux, cuja última grande feature saiu em 2008. O btrfs é o que coloca o Linux na mesma geração dos outros dois, e não uma década atrás.

Por que o btrfs é muito superior

O que é copy-on-write, pra quem nunca parou pra pensar

Nos filesystems clássicos, a escrita é destrutiva por definição: atualizar um bloco significa gravar o conteúdo novo por cima do velho, no mesmo lugar do disco. Se a máquina morre no meio da escrita, o arquivo fica metade velho, metade novo. O journal do ext3/ext4 cobre isso para os metadados (a estrutura de diretórios não corrompe), mas o seu dado em si fica por conta da sorte.

Copy-on-write inverte a ordem: nada nunca é sobrescrito. Escrever num arquivo aloca um bloco novo, grava o conteúdo novo ali, e só quando está tudo seguro no disco o filesystem troca os ponteiros pra versão nova, de forma atômica. A qualquer instante, você tem ou a versão velha inteira ou a versão nova inteira. Nunca uma mistura das duas.

O que isso compra na prática:

• Snapshots quase de graça. Os blocos velhos já persistem por natureza do CoW; um snapshot é só o filesystem segurando o ponteiro de raiz daquele instante, pura contabilidade.
• Queda de energia não corrompe. Uma escrita interrompida deixa a versão anterior intacta, porque ela nunca foi tocada. Pra quem já perdeu imagem de VM ou banco de dados pra queda no meio da escrita, isso vale o filesystem inteiro.
• Verificação possível. Como cada bloco é escrito uma vez e nunca mexido, faz sentido guardar checksum dele pra sempre. É a base da proteção contra corrupção que detalho mais abaixo.

O custo existe e eu pago ele sabendo: arquivos de escrita aleatória intensa (disco de VM, banco de dados) fragmentam e duplicam bloco, porque cada reescrita vira um bloco novo. Pra esses casos se desliga o CoW por diretório com chattr +C, que precisa ser marcado antes do arquivo ser criado. No meu layout, a imagem de VM feita com o +C certo ficou saudável; a feita sem virou o caso de fragmentação de livro-texto.

Snapshots são a feature que muda a sua vida

Snapshot no btrfs é uma foto instantânea de um subvolume, e custa quase nada, porque o CoW já mantém os blocos velhos enquanto alguém referencia eles. Criar um snapshot é operação de segundo, não de horas. Na prática: antes de cada upgrade, o sistema tira uma foto. Se o upgrade quebrar, você não “desinstala pacote”: você boota de volta na foto anterior e pronto. A seção de recuperação de boot, mais abaixo, mostra isso acontecendo de verdade.

Subvolumes são o jeito certo de organizar o disco

Subvolume é um namespace independente dentro do mesmo filesystem, com política própria de snapshot. E tem uma propriedade matadora: snapshot não é recursivo. Um subvolume filho dentro de outro fica automaticamente de fora do snapshot do pai.

Eu uso isso pra tudo. No meu desktop, os diretórios de cache que dá pra baixar de novo (mise, rustup, npm, opencode, caches de IA) estão virando subvolumes aninhados dentro do @home: ficam no mesmo lugar pra qualquer programa, mas de fora de qualquer snapshot. Só essa separação tira 165 GiB de escopo de snapshot, e os caches grandes (Hugging Face, yay, uv, pip) já moram fora do volume do sistema, com symlinks apontando pra eles: menos 148 GiB de snapshot, parte já migrada e parte em andamento. O snapshot fica pequeno, o restore fica rápido, e o que pode ser rebaixado da internet nunca entra na foto.

O custo real, medido no QNAP novo (ZFS, mas a matemática de CoW é a mesma): 27 snapshots de hora em hora de uma pasta com quase 80 TB, e quase todos consomem megabytes, porque entre uma hora e outra quase nada mudou. Snapshot barato é o que permite essa rotina existir sem culpa.

Deduplicação por reflink

Antes, a ressalva que importa: o btrfs não tem deduplicação online nativa igual ao ZFS (que mantém uma tabela de dedup em RAM e cobra caro por isso). O que ele tem são duas coisas práticas: reflink e dedup offline. Reflink é cópia que compartilha blocos: cp --reflink=auto cria um arquivo novo que aponta pros mesmos blocos do original, instantâneo e de graça, e cada um passa a divergir só onde for escrito. Na era de dezenas de checkouts, worktrees e builds parecidos, isso economiza uma montanha de blocos. Pra dedup retroativo existem ferramentas de userspace como duperemove e bees.

Proteção contra corrupção de verdade

Todo bloco do btrfs, dado ou metadado, carrega checksum. Quando o filesystem lê e o checksum não bate, ele sabe que o bloco apodreceu, e se houver uma segunda cópia (RAID ou metadata DUP) ele se autocorrige. O ext4 não checa dado nenhum: bit rot passa silencioso até você abrir o arquivo anos depois.

Duas peças da minha configuração mostram o que isso compra na prática, e o que o ext4 simplesmente não oferece. A primeira é o metadado em modo DUP. Num ext4, cada estrutura do volume existe uma vez só: um setor ruim bem posicionado corrompe a tabela de diretórios e o disco inteiro deixa de montar. No btrfs, mesmo com um único disco, todo bloco de metadado existe duplicado. O setor ruim continua existindo, mas o checksum acusa o bloco podre na leitura e a segunda cópia responde no lugar, sem você perceber. É a diferença entre perder o volume e anotar um aviso no log.

A segunda é o scrub mensal. Um ext4 nunca relê nada pra conferir saúde: se um bloco apodrece, você descobre no dia em que alguém tenta abrir aquele arquivo específico, talvez anos depois, quando já não tem conserto. O scrub é uma varredura agendada que relê o volume inteiro validando checksums, e encontra a podridão enquanto ela ainda é pequena e recuperável. Quando o contador do btrfs device stats sai de zero, é a sirene pra trocar o disco antes do desastre, não depois.

Compressão transparente, medida

Todo mount do meu desktop usa compress=zstd:1. O nível 1 custa uns pontos percentuais de um núcleo de CPU, e o btrfs detecta o que não comprime (blob de modelo, vídeo) e grava cru, sem custo. O resultado, medido essa semana nos meus dois discos novos:

São 630 GB de espaço grátis em 2,2 TB: 15% a mais de disco, sem pagar nada. Na migração inicial o ganho foi ainda maior, 45% no volume de sistema, porque havia mais texto e menos binário. Repare nos detalhes da tabela: programas e bibliotecas comprimem bem, camadas de Docker comprimem melhor ainda (39%), log de texto comprime 4,5x, e peso de modelo de IA não comprime nada, o que é esperado e não custa nada. Código-fonte, que é o que mais produzimos na era da IA, comprime lindamente.

Synology usa btrfs, QNAP usa ZFS

Sendo justo com o ZFS: pra NAS grande ele é superior, e foi o que eu escolhi pro QNAP. Checksum e autocorreção nativos, RAIDZ maduro, send/receive excelente. O preço é complexidade e recurso: o ZFS quer RAM pro cache ARC (meu QNAP tem 7 GB pra um pool de 174 TB, e sinto a falta), a deduplicação online dele precisaria de uns 190 GB de RAM só pra tabela no meu volume, e o modelo de provisionamento dele me deu um susto de graça quando o snapshot foi recusado com 20 TB livres (a história do thick vs thin está no artigo do NAS).

O btrfs é o equilíbrio certo pra máquina de consumo. Leve, nativo no kernel, faz quase tudo que o ZFS faz sem exigir um administrador de storage. Desktop, notebook, homelab, NAS pequeno ou médio: btrfs. O Synology provou na prática, duas vezes: o volume btrfs sobreviveu legível com dois discos fora, e os snapshots dele salvaram 11 álbuns que eu deletei por engano no meio da limpeza, byte a byte.

NAS grande e sério, com RAM de sobra: ZFS. Todo o resto: btrfs. E pra máquina Linux de uso pessoal, não é nem discussão.

Recuperação de boot por snapshot

A feature que já me salvou de verdade, contada nas duas máquinas.

No desktop, o Omarchy configura o snapper pra tirar snapshot antes de cada update e o limine-snapper-sync publica cada snapshot como entrada de boot no Limine. Kernel novo não sobe? No menu de boot você escolhe o snapshot de ontem e a máquina volta como se nada tivesse acontecido. Na minha máquina a rotina agendada roda via Timeshift em cron (a cada boot e de hora em hora), com o snapper cobrindo os pontos de update: o mecanismo de retorno é o mesmo. (A gotcha: cada entrada de snapshot carrega a imagem do kernel junto, então ESP pequena enche rápido. A minha de 1 GB já recusou um update de kernel por falta de espaço; o sistema seguiu bootável no kernel velho, que é o comportamento certo.)

No servidor, que roda openSUSE MicroOS, é ainda mais forte: o sistema inteiro é btrfs transacional, e cada update é um snapshot novo. Semana passada, o kernel 7.2.9 derrubou o controlador NVMe em silêncio, duas vezes, no meio do backup noturno. O conserto foi um transactional-update rollback e um reboot de volta pro 7.2.6, que rodou a carga inteira (754 GiB de leitura de backup com download concorrente) sem um soluço. Regressão de kernel virou reboot agendado, não madrugada de recovery. Uma ressalva documentada: o /etc mora dentro do snapshot, então o rollback desfaz mudanças de configuração junto. Depois de qualquer rollback, confira de novo as suas units.

Manutenção não é opcional (e o arquivo deletado que não some)

Filesystem CoW moderno entrega muito, mas cobra duas rotinas que o ext4 nunca pediu.

A primeira é o scrub, que já apareceu aqui: reler tudo e conferir checksums, mensalmente, em todas as máquinas. Ele é o detector de bit rot em ação, e sem ele o checksum só te avisa da podridão quando você tentar ler o arquivo. O segundo ponto é mais sutil: snapshot prende bloco de arquivo deletado. Quando você apaga um arquivo dentro de um subvolume com snapshot, o espaço não volta, porque o bloco continua referenciado pela foto. Foi exatamente o que aconteceu no meu NAS: a limpeza de 2,14 TB que rodei no Synology só liberou espaço de verdade depois que os snapshots velhos foram removidos; até lá, os blocos ficaram presos.

O tratamento é rotina simples. A retenção tem que ser automática, com o snapper ou o Timeshift apagando os snapshots antigos conforme a política (no QNAP, a política de retenção do Snapshot Manager faz o mesmo papel). Espaço que não volta depois de deletar snapshot velho geralmente é chunk alocado demais: um btrfs balance start -dusage=50 devolve os pedaços pouco usados pro pool livre (aqui em casa eu não agendo balance cego, eu monitoro o espaço não-alocado e ajo quando aperta). E no lado do restic, forget sozinho só remove a referência do snapshot: o espaço do repositório só é recuperado com o prune junto, forget --prune.

A limpeza da casa na era do AI coding

Agora a parte que quase ninguém conecta com filesystem: a era do agente produz lixo em velocidade industrial. Eu sei porque medi.

• Rust é o maior poluidor de disco do mundo dev. Cada build deixa pra trás binários de teste de 100 a 180 MB, e eles se acumulam a cada edição. No meu desktop, os diretórios target/ somavam 920 GiB. Só o ai-memory respondia por 704 GiB. A ferramenta de higiene que eu usava é o cargo-sweep, semanal. Um leitor avisou que o projeto se declara sem mantenedor, e o próprio README manda pro cargo-clean-all, que faz diferente: em vez de podar artefato velho dentro de um target/, ele acha todos os projetos Rust abaixo de um diretório e apaga o target/ inteiro dos que você filtrar, por exemplo cargo clean-all --keep-days 7 ~ pra limpar só o que não compila há uma semana.
• Docker não fica atrás. Na minha máquina achei 1,26 TB de build cache mais 938 GB de imagens. Uma faxina única recuperou uns 600 GB. No servidor, a limpeza semanal recolhe de 0,6 a 4,5 GB todo domingo.
• Caches de IA e de pacotes incham quietos. O cache do Hugging Face tinha 86 GB até eu apagar três modelos mortos e ele cair pra 21. Pacman tinha 22 GB de pacotes superados. yay, uv e pip, mais 125 GB.
• E os agentes criam diretórios temporários sem pedir licença. Projeto complexo com várias branches significa worktrees, e cada worktree de release tem seu próprio CARGO_TARGET_DIR cheio de binário de teste. No ai-memory isso já estourou o disco, e virou regra obrigatória no AGENTS.md do projeto: depois de cada release, cargo clean em cada worktree criado e remoção dos worktrees terminados, sem exceção.

A solução é automatizar o varrimento. O meu exemplo mínimo, um timer de usuário que roda dia 1 e 15 de madrugada, com Nice e I/O idle:

• apaga diretórios target/ de projetos parados há mais de 14 dias
• limpa o cache do yay
• poda só o build cache do Docker com mais de 30 dias, nunca imagem ou volume

E a parte que virou padrão aqui em casa: instruir os agentes a limpar o que criam. Três regras reais dos meus projetos, pra você copiar:

No AGENTS.md do desktop: “Nunca rode limpezas amplas como docker system prune sem autorização explícita do usuário depois de um inventário read-only. Limpeza usa lista exata de IDs; parado, antigo ou sem referência não significa descartável.”

No CLAUDE.md do homelab: “Antes de terminar qualquer tarefa, remova as coisas temporárias que a tarefa criou, e só elas. Nunca delete o que você não criou ou não consegue atribuir à tarefa. Na dúvida, liste pro dono.”

No AGENTS.md do ai-memory: “target/ cresce sem limite: cada edição num crate compartilhado deixa pra trás uma cópia de cada binário de teste de 100-180 MB (visto a 157 GiB). cargo sweep --time 7 semanal, e cargo clean obrigatório depois de cada release.”

E o backup de verdade: restic

Snapshot mora no mesmo disco, então snapshot não é backup: se o disco morre, o snapshot morre junto. O último item do kit é o restic, que pra mim é o melhor sistema de backup do Linux hoje.

O restic é um binário único, open source, escrito em Go, que faz backup deduplicado, criptografado e versionado pra praticamente qualquer destino: outro diretório, outro NAS via SFTP ou REST, S3, Glacier. O truque central é o content-defined chunking: ele fatia cada arquivo em blocos de tamanho variável definidos pelo conteúdo, tira o hash de cada bloco e só grava no repositório os blocos que ainda não existem lá. Por isso o delta é barato: o backup de hoje carrega os blocos que mudaram desde ontem, não os arquivos que mudaram. Editar um banco de 100 GB no meio custa alguns megabytes de backup, não 100 GB de novo. Cada execução vira um snapshot do repositório, um ponto de restauração que você navega com restic mount como se fosse filesystem, e o restic check audita a integridade do repositório inteiro quando você pedir.

A configuração importa mais que a ferramenta, então vai a nossa, com os erros inclusos. No desktop, o repositório mora no NAS e a retenção é keep-daily 7, keep-weekly 4, keep-monthly 6, keep-yearly 1. No servidor, o backup roda diário de madrugada pro repositório no QNAP, cobrindo /etc, /usr/local/bin, /home e os volumes dos containers, com a senha fora da máquina e pg_dump antes dos bancos, porque snapshot de filesystem não garante consistência de banco escrevendo. A primeira carga completa foi 729 GiB em menos de uma hora, e o restic atravessou ileso, na base do retry, a janela em que a montagem NFS ficou read-only por engano durante a migração.

A parte mais importante da configuração é o que não entra no backup. As nossas exclusões, todas com motivo:

• caches de modelo de IA (Immich, Hugging Face, EasyOCR): se perder, baixa de novo;
• métricas do Prometheus: histórico que se regenera sozinho;
• o banco do Fulcrum: reindexa a partir do bitcoind;
• os pesos dos classificadores de decisão: rebaixáveis por hash de revisão (e o glob dessa exclusão vai entre aspas dentro do array do bash, porque sem aspa ele vira fonte de backup em vez de exclusão);
• node_modules, target/, registry do cargo, toolchains do rustup: build artifact puro.

E um aprendizado de retenção pra fechar. Quando encurtamos a política do servidor pra “ontem, 2 diários, 2 semanais e 1 mensal”, a tradução correta pros flags é --keep-daily 3 --keep-weekly 3 --keep-monthly 2, não 2/2/1: os níveis do restic se sobrepõem, e o snapshot de ontem também é o mais novo desta semana e deste mês, então cada número precisa ser um a mais que os pontos antigos que você quer guardar. O detalhe pegou a gente no contrapé: o script estava com 2/2/1 literal, e com ele o nível mensal nunca seguraria nada mais velho que a noite passada. Na prática, a intenção era guardar 5 pontos de restauração, e o 2/2/1 entrega só 3: ontem, mais um diário, mais um semanal. Erramos, medimos, corrigimos.

Uma nota de humildade vinda do desastre: os repositórios antigos ficaram no Synology por decisão minha (quase 2 TB de histórico abandonado, porque o conteúdo já estava re-coberto no QNAP novo). Repositório de backup também envelhece, e revisitar o escopo dele faz parte da higiene.

Conclusão: na era da IA, disco não é detalhe

Agentes codificando o dia inteiro mudam a matemática do armazenamento nas duas pontas. Na ponta do volume: builds, caches, worktrees e modelos enchem o disco muito mais rápido do que qualquer hábito humano enchia, e sem rotina de limpeza você descobre quando estoura. Na ponta da segurança: quanto mais código gerado, mais você precisa de ponto de retorno barato, porque nem toda mudança de agente é boa.

O btrfs cobre as duas. A compressão transparente devolve 15% de disco de graça, e código-fonte é exatamente o tipo de dado que mais comprime. Snapshots e subvolumes te dão volta atrás instantânea no sistema e isolamento do que não precisa de proteção. Checksums e scrub vigiam a saúde dos blocos que o ext4 simplesmente ignora. O ext4 teve seus 15 anos de reinado merecido. Em 2026, escolher ele num Linux novo é abrir mão de proteção que você vai precisar, cedo ou tarde. Escolha btrfs e configure a limpeza hoje.

Você paga pelo livro, mas só consegue ler onde a Amazon deixa. Não existe um aplicativo nativo decente pra Linux. Mudar pra outro leitor vira um exercício de arqueologia. Comprei um Xteink X4 novo e, claro, minha biblioteca não podia simplesmente ir junto. O arquivo estava “na minha conta”, mas não estava sob meu controle.

Durante anos, eu contornei isso pelo caminho oficial. Entrava no site da Amazon, usava Download & Transfer via USB, baixava o .azw dos livros que comprei e importava tudo no calibre. Com o plugin DeDRM configurado pro serial do meu Kindle, convertia pra EPUB e pronto.

Em 26 de fevereiro de 2025, a Amazon desativou essa opção. Sem anúncio decente, sem substituto que entregasse o arquivo e sem qualquer preocupação com quem queria manter um backup local. Desde então, meus livros mais novos ficaram presos no ecossistema deles. Voltei a tentar no ano passado, atualizei plugin, copiei arquivos do meu Kindle Paperwhite, coloquei o serial correto e nada.

Pra ser justo, em 20 de janeiro de 2026 a Amazon passou a permitir que compradores verificados baixem EPUB ou PDF quando o publisher confirma o livro como DRM-free. Ótimo. Só não resolve os livros protegidos, e a decisão continua nas mãos da editora. Títulos antigos sem DRM também precisam ser confirmados individualmente pelo publisher. Minha biblioteca não ganhou botão de download por causa disso.

Resolvi tentar de novo agora. A versão nova do DeDRM conseguiu lidar com o DRM atual, mas o processo mudou bastante. Dá trabalho, precisa de Windows numa das etapas e envolve uma ferramenta comunitária em pre-release. Funcionou. Recuperei 106 livros comprados, testei a conversão pra EPUB e agora posso ler no aparelho que eu quiser.

Este é o estado do jogo em 30 de julho de 2026 (atualizado em 19 de agosto). A Amazon pode mudar a criptografia ou o aplicativo amanhã. Não conte com tutorial antigo dizendo pra instalar Kindle for PC 1.17, desabilitar update e colocar o serial do aparelho no Calibre. Esse mundo já acabou.

E o óbvio precisa ser dito: estou falando dos livros que eu comprei. Não estou falando de baixar Kindle Unlimited, empréstimo de biblioteca ou livro dos outros. Leis sobre circumvention de DRM variam por país. Pesquise a legislação de onde mora e assuma responsabilidade pelo que faz.

Antes de tudo: não jogue Kindle velho fora

Amazon também não facilita reaproveitar Kindle antigo. O hardware continua bom, a bateria costuma ser substituível, a tela de e-ink dura uma eternidade, mas o software vai ficando cada vez mais fechado e limitado.

Pra quem quer ressuscitar esses aparelhos, recomendo o canal Dammit Jeff. Ele acompanha jailbreaks, KOReader, lojas alternativas e formas de manter Kindles úteis depois que a Amazon perde o interesse. Este vídeo sobre o AdBreak e os jailbreaks recentes é um bom começo. Leia também o guia atualizado do Kindle Modding antes de fazer qualquer coisa, porque firmware e método compatível mudam o tempo todo.

Jailbreak do aparelho e remoção de DRM do ebook são problemas diferentes. Você não precisa desbloquear o Kindle pra seguir o resto deste artigo. Estou mencionando porque ambos partem da mesma ideia: hardware e mídia que já pagamos deveriam continuar úteis sem pedir bênção eterna ao fabricante.

Crash course: AZW, EPUB e KFX

DRM e formato de arquivo não são a mesma coisa. O formato diz como texto, imagens, fontes, índice e metadados são empacotados. DRM adiciona uma trava criptográfica por cima e decide qual conta, aplicativo ou aparelho consegue abrir aquilo.

Os três nomes que importam aqui são:

A extensão sozinha pode enganar. Parte de um livro KFX pode aparecer como .azw, .azw.res, .voucher e outras variações. O plugin KFX Input existe justamente pra entender esse conjunto.

O EPUB é bem menos misterioso. A especificação EPUB 3.3 o define como um container de arquivo único pra conteúdo Web estruturado. É basicamente um pequeno site empacotado. Qualquer leitor minimamente decente consegue implementar suporte sem depender de uma chave secreta da Amazon.

Calibre e os dois plugins

calibre é o canivete suíço de ebooks. É software livre, roda em Linux, macOS e Windows, organiza biblioteca, baixa metadados, edita capas, transfere livros e converte dezenas de formatos. Existe desde 2006 e nasceu justamente porque o primeiro Sony Reader não funcionava direito no Linux.

No Omarchy ou qualquer Arch, basta instalar o pacote:

sudo pacman -S calibre

Em outras distribuições, veja o download oficial. Não invente de instalar um pacote aleatório de site de downloads.

Uma pegadinha específica de ambientes com mise: se o Calibre morrer com ModuleNotFoundError: msgpack ou BrokenPipeError, provavelmente um shim de Python entrou antes de /usr/bin. O pacote do Arch precisa do Python do sistema. Inicie assim:

env PATH="/usr/bin:$PATH" /usr/bin/python3 /usr/bin/calibre

Isso não tem relação com DRM nem com os plugins. É só o helper do Calibre chamando o Python errado. No meu desktop deixei um launcher permanente com esse PATH.

O Calibre sozinho não remove DRM. Precisamos de dois plugins:

1. DeDRM reconhece e remove as travas de vários ecossistemas durante a importação. Ele só roda quando o livro entra na biblioteca. Clicar em Convert depois não remove nada.
2. KFX Input entende os containers modernos da Amazon, reúne as partes de um livro e permite converter o resultado pra EPUB.

No momento deste artigo, estou usando DeDRM 10.0.28, publicado em 14 de julho no fork mantido por Satsuoni. É um pre-release. Baixe o asset chamado DeDRM_tools.zip, nunca um executável solto de algum mirror obscuro.

Atualização (agosto de 2026): o aplicativo do Kindle na Microsoft Store não para quieto, e cada versão nova dele exige uma versão nova da ferramenta. Desde a publicação deste artigo, o app saiu da 1.0.18632: a 10.0.29 adicionou suporte ao app 1.22326 e a 10.0.30 suporta o app 1.0.22920. A regra prática é uma só: o nome do executável carrega a versão do app que ele entende (MSIXKFXArchiverMobi1_22920.exe pra Store app 1.0.22920, e assim por diante). Antes de começar, confira sempre a página de releases do fork do Satsuoni e baixe o pre-release mais novo. Todo o resto do processo descrito aqui continua igual.

Eu descompactei tudo numa pasta que depois fica compartilhada com a VM Windows:

mkdir -p ~/Windows/Kindle-DeDRM/v10.0.28
unzip ~/Downloads/DeDRM_tools.zip -d ~/Windows/Kindle-DeDRM/v10.0.28

O SHA-256 do DeDRM_tools.zip que usei foi:

520cce704edf9ae26e43196efe2871daf9b25d6cb489aa56051626801c362947

Confira com sha256sum. Isso não transforma um binário comunitário em software magicamente seguro, mas pelo menos garante que está usando o mesmo arquivo que eu testei.

Dentro da pasta existe DeDRM_plugin.zip. Não descompacte esse segundo ZIP. No Calibre, abra Preferences → Plugins → Load plugin from file, escolha DeDRM_plugin.zip, aceite o aviso e reinicie o programa.

Depois volte em Preferences → Plugins → Get new plugins, procure por KFX Input e instale. Meu teste usou a versão 2.33.0. Reinicie de novo.

Por que copiar do Kindle pelo USB não resolveu

O caminho mais simples ainda seria ligar meu Kindle Paperwhite novo no cabo, copiar o livro e configurar o serial do aparelho no DeDRM. Foi o primeiro teste que fiz.

O arquivo entrou como KFX-ZIP, o plugin rodou, mas continuou criptografado. Abri o Calibre em debug e o log mostrou que esse livro usava a estratégia ACCOUNT_SECRET. O serial estava certo. O problema é que a chave necessária não vinha mais apenas do aparelho.

É por isso que muita gente segue tutorial antigo, tenta cinco serial numbers diferentes e conclui que o DeDRM está quebrado. Pra livros novos com esse DRM, precisamos do segredo que o aplicativo Kindle atual guarda no Windows. E esse segredo é protegido pelas APIs do TPM.

Um Windows descartável dentro do Omarchy

Eu não vou manter dual boot só pra baixar ebook. Também não vou fingir que Wine roda tudo. Felizmente, o Omarchy já vem preparado pra instalar e abrir uma VM Windows: ela aparece no próprio menu do sistema, abre por RDP e compartilha ~/Windows automaticamente com o guest. Não precisei montar essa integração do zero.

Por baixo, ele usa o dockur/windows. O dockur empacota QEMU/KVM num container e automatiza a instalação do Windows. Continua sendo uma máquina virtual de verdade, com disco e kernel próprios. O container só organiza a distribuição, configuração e ciclo de vida.

Pra instalar pelo terminal, rode:

omarchy-windows-vm install

Escolha RAM, CPUs e tamanho do disco. O instalador cria ~/.config/windows/docker-compose.yml, guarda o disco virtual em ~/.windows e compartilha ~/Windows com o guest. Dentro do Windows, essa pasta aparece como Shared, normalmente em Z:, e também fica acessível por \\host.lan\Data.

O detalhe que fez diferença no meu caso foi habilitar TPM 2.0. Edite o Compose gerado e acrescente TPM: "Y" no bloco environment:

services:
  windows:
    image: dockurr/windows
    environment:
      VERSION: "11"
      TPM: "Y"

Depois recrie o container. O disco do Windows continua no volume persistente:

omarchy-windows-vm stop
omarchy-windows-vm launch -k

O -k deixa a VM ligada quando você fechar o RDP. Também dá pra acompanhar pelo navegador em http://127.0.0.1:8006.

Baixando os livros pelo aplicativo certo

Dentro do Windows, abra a Microsoft Store e instale Amazon Kindle: Reading App, produto 9P8JQ0JJSTLL.

Preste atenção aqui. O instalador antigo de Kindle for PC encontrado em blogs não é o mesmo aplicativo. A ferramenta que usei procura o pacote AMZNKindle.AmazonKindleReadingApp da Microsoft Store. Com o programa legado, ela simplesmente responde No AmazonKindleReadingApp installation found.

Entre na sua conta e mande baixar localmente cada livro que quer preservar. Abrir a capa ou ver o título na biblioteca não basta. O conteúdo precisa estar disponível offline dentro do app.

Infelizmente, a parte mais chata continua manual. A Amazon sabe colocar botão de compra com um clique, mas não achou espaço pra um “baixe tudo que eu já paguei”.

Eu fiz isso em 106 livros. Sim, foi um saco.

Gerando os KFX-ZIP e a chave K4I

O DeDRM_tools.zip que descompactamos no Linux já está visível no Windows por causa da pasta compartilhada. Abra PowerShell e entre nela:

cd \\host.lan\Data\Kindle-DeDRM\v10.0.28
.\MSIXKFXArchiverMobi1_18632.exe

O banner ainda pode mencionar uma build antiga 1.0.15230. O executável versionado acima procura a Store app 1.0.18632 e foi o que funcionou comigo. O número no nome do arquivo precisa bater com a versão do seu app: se a Store já te entregou uma versão mais nova, baixe a release correspondente na página do projeto (veja a atualização na seção dos plugins).

Esse executável localiza o cache da versão atual da Microsoft Store, reúne os componentes de cada livro e gera duas coisas:

• archived_kfx/, com um .kfx-zip pra cada ebook baixado;
• oldbooks.k4i, o keyfile que o DeDRM precisa pra abrir aqueles arquivos.

Na minha máquina, o processo encontrou e arquivou 106 livros. O SHA-256 do executável que rodei foi:

0c78b45ccea2c36a5fbb01b9f66bdd9e5d5960a68a340ba2ee96e138f5cddf4a

Ele é um binário de 32 bits. Se reclamar que falta MSVCP140.dll, instale o Microsoft Visual C++ Redistributable x86 oficial. Não procure DLL avulsa no Google. Esse é um ótimo jeito de transformar backup de livro em backup de malware.

O oldbooks.k4i é sensível. Ele deriva do segredo da sua conta naquela instalação do Kindle. Não publique, não mande em issue do GitHub, não tire screenshot do conteúdo e não coloque em repositório aberto.

Configurando a chave no DeDRM

De volta ao Linux, abra o Calibre e siga:

Preferences → Plugins → DeDRM → Customize plugin → Kindle for Mac/PC ebooks → Import Existing Keyfiles

Selecione:

~/Windows/Kindle-DeDRM/v10.0.28/oldbooks.k4i

Use Import Existing Keyfiles. Não use o botão genérico Set Keyfile da tela principal. Ele grava outro tipo de candidato e não cadastra a chave K4I no lugar certo.

Feche a lista de chaves, clique em OK na configuração principal e reinicie o Calibre. Se fechar com Cancel, ele joga a alteração fora sem cerimônia.

Importando e convertendo pra EPUB

Antes de despejar cem arquivos na biblioteca, teste um.

Escolha um .kfx-zip dentro de:

~/Windows/Kindle-DeDRM/v10.0.28/archived_kfx/

Use Add books no Calibre. A ordem interna é esta:

1. KFX Input reconhece o pacote;
2. DeDRM tenta as chaves K4I durante a importação;
3. KFX Input monta o livro descriptografado como KFX;
4. Calibre passa a conseguir abrir e converter o resultado.

Se o formato continuar aparecendo como KFX-ZIP, deu errado. Não adianta apertar Convert dez vezes. Remova aquela entrada da biblioteca, corrija plugin ou chave e importe de novo. DeDRM só atua na entrada.

Quando o livro aparecer como KFX, abra no viewer e confira algumas páginas. Depois clique em Convert books, escolha EPUB como saída e teste o arquivo resultante no leitor onde pretende usar. Só depois disso faça a importação em lote.

No meu caso, o KFX abriu, converteu e o EPUB funcionou fora do Kindle. Com isso eu sabia que o caminho inteiro estava funcionando: Microsoft Store, TPM, archiver, K4I, DeDRM 10.0.28 e KFX Input 2.33.0.

Faça backup do que realmente importa

Depois da conversão, eu preservo três coisas:

• os EPUBs finais, que leio em qualquer aparelho;
• os KFX-ZIP originais, até conferir que todos os EPUBs estão íntegros;
• o oldbooks.k4i, criptografado e separado da biblioteca.

Meu keyfile em texto puro fica com permissão 0600. Também mantenho uma cópia criptografada com SOPS e age, enquanto a chave privada fica em outro backup. Não coloque oldbooks.k4i cru no Git só porque o repositório é privado. Repositório privado vaza também.

Os EPUBs entram na mesma estratégia que uso pros outros arquivos importantes: cópia local, NAS e backup off-site. Já expliquei essa paranoia em Protegendo e Recuperando Dados Perdidos e mostrei a mesma filosofia aplicada a filmes no meu Netflix Pessoal.

Não apague os arquivos do Kindle ou da VM no minuto em que a conversão termina. Abra os EPUBs, veja capa, índice, imagens, notas e algumas páginas. Backup que nunca foi testado é só torcida organizada.

Conclusão

Amazon já apagou livros remotamente, editoras atualizam capas e conteúdo, aplicativos antigos param de funcionar e formatos mudam. O próprio fim do download via USB mostrou que uma função disponível por dezoito anos pode desaparecer com uma linha num aviso.

O exemplo clássico continua inacreditável: em 2009 a Amazon apagou 1984 e Animal Farm, de George Orwell, dos Kindles de clientes. Depois vieram revisões de Roald Dahl, R.L. Stine e Agatha Christie empurradas pra cópias digitais que já tinham sido compradas. O artigo da Vice resume esses casos. O Dammit Jeff também bate muito nessa tecla: até a capa original que você escolheu pode virar pôster feio da adaptação do streaming porque publisher e loja decidiram atualizar sua “compra”.

Não importa se a alteração futura é censura, correção legítima, nova capa horrorosa de adaptação da Netflix ou apenas um bug. Eu comprei uma edição. Quero preservar a edição que comprei.

DRM não impede pirataria. Livro popular aparece em torrent no dia do lançamento. DRM só atrapalha o cliente que pagou, dificulta acessibilidade, prende hardware ainda bom e transforma uma compra em aluguel por prazo indefinido.

Calibre, DeDRM, KFX Input e uma VM descartável devolveram minha biblioteca. Agora posso colocar os EPUBs no Xteink, num Kobo, num tablet, no celular ou num leitor que ainda nem existe. Posso trocar de sistema operacional e posso desligar a internet. Os arquivos continuam comigo.

Se não está na sua máquina, não é seu.

O Ayub comentou no X que há todos os indícios típicos de bloqueio nacional determinado pela Anatel contra api.github.com. No mesmo contexto, o tweet citado por ele mostrava api.github.com resolvendo para 4.228.31.149, mas sem rota funcionando. O autor dizia ter testado por VIVO, Claro e Oracle, e que só funcionava via VPN de Miami. Ou seja: não parece “meu Wi-Fi caiu”. Parece bloqueio no caminho.

Segundo o Ayub, esse tipo de coisa costuma acontecer em ondas de bloqueios, muitas vezes em reuniões de quarta-feira com grandes operadoras, dentro desse mecanismo brasileiro de bloquear endereços sob pretexto de combater pirataria. O problema é o efeito colateral: em vez de derrubar só o alvo, derruba pedaço legítimo de infraestrutura. Hoje foi a API do GitHub. Amanhã pode ser qualquer outra coisa que seu trabalho depende.

E sim, eu confirmei daqui.

Como saber se você foi afetado

Primeiro, teste se o site principal abre:

curl -4 -I --connect-timeout 8 --max-time 12 https://github.com/

Aqui funcionou. Depois teste a API:

curl -4 -I --connect-timeout 8 --max-time 12 https://api.github.com/

Aqui deu:

curl: (28) Connection timed out after 8002 milliseconds

Agora veja pra qual IP seu sistema está resolvendo:

getent ahostsv4 api.github.com

No meu caso:

4.228.31.149    STREAM api.github.com
4.228.31.149    DGRAM
4.228.31.149    RAW

E o gh também depende dessa API. Então comandos como estes podem travar:

gh api rate_limit
gh pr list
gh issue list

Se você é desenvolvedor e de repente gh parou, seus scripts de release pararam, seu bot que lista PRs parou, ou aquele CLI que consulta issues começou a ficar pendurado, pode ser isso. Não é bug seu. É a sua rota até api.github.com sendo jogada no buraco.

Primeiro tente DNS 9.9.9.9

Algumas pessoas comentaram que trocar o DNS para Quad9, 9.9.9.9, poderia contornar. Faz sentido testar, porque alguns bloqueios são feitos via DNS: o provedor responde um IP errado, NXDOMAIN, ou manda para um buraco. Se o problema for só o DNS do seu provedor, trocar de DNS resolve.

Teste sem mudar nada no sistema:

dig @9.9.9.9 +short api.github.com A

No meu caso, não resolveu. O Quad9 também retornou:

4.228.31.149

E forçar esse IP no curl continuou dando timeout:

curl -4 -I --connect-timeout 8 --max-time 12 \
  --resolve api.github.com:443:4.228.31.149 \
  https://api.github.com/

Resultado:

curl: (28) Connection timed out after 8002 milliseconds

Então, no meu link, 9.9.9.9 não resolveu. Mas teste no seu. Se o seu provedor está apenas envenenando DNS, pode funcionar.

No Arch com NetworkManager, seria algo assim:

sudo pacman -S bind-tools curl

nmcli con show --active
sudo nmcli con mod "NOME DA SUA CONEXÃO" \
  ipv4.ignore-auto-dns yes \
  ipv4.dns "9.9.9.9 149.112.112.112"
sudo nmcli con down "NOME DA SUA CONEXÃO"
sudo nmcli con up "NOME DA SUA CONEXÃO"

No Ubuntu, a ideia é a mesma. Instale as ferramentas e ajuste pelo NetworkManager:

sudo apt install dnsutils curl
nmcli con show --active

Ou use a tela de rede do GNOME/KDE e coloque DNS manual 9.9.9.9 e 149.112.112.112 na conexão. Depois desconecte e conecte de novo.

Teste de novo:

dig +short api.github.com A
curl -4 -I --connect-timeout 8 --max-time 12 https://api.github.com/

Se funcionar, ótimo. Você terminou aqui.

Se continuar dando timeout, o bloqueio não está só no DNS. Aí precisa rotear a conexão por outro caminho.

Por que eu não gosto da gambiarra de IP fixo

Outra sugestão que vi foi colocar IPs manualmente no DNS local, tipo Pi-hole, Unbound, /etc/hosts, dnsmasq, essas coisas. Exemplo: “resolve api.github.com pra tal IP que funciona”.

Isso pode funcionar por algumas horas. Eu não gosto.

GitHub é infraestrutura grande. IP muda. Rota muda. Balanceamento muda. Região muda. O IP que funciona pra uma pessoa em Miami pode ser ruim pra você em São Paulo. O IP que funciona hoje pode cair amanhã. E se o bloqueio for por rota blackhole no provedor, trocar DNS para outro IP pode só trocar um buraco por outro.

Pi-hole é ótimo pra rede doméstica. Unbound é ótimo. /etc/hosts salva em emergência. Mas fixar IP de serviço grande como GitHub é pedir pra esquecer uma gambiarra invisível e perder duas horas daqui a um mês tentando entender por que só a sua máquina não funciona.

Use DNS alternativo como teste. Use IP fixo só como curativo temporário e documente onde mexeu.

Fallback: proxy SOCKS só para ferramentas do GitHub

Minha solução foi fazer o mínimo invasivo: um wrapper que sobe um SOCKS local via Tor e executa só o comando que eu quero por ele. Não roteia o sistema inteiro. Não mexe no navegador. Não altera pacote, Steam, banco, nada. Só gh, ou qualquer ferramenta que eu chamar explicitamente.

No meu caso, o wrapper está em ~/.config/zsh/bin/github-proxy e o alias em ~/.config/zsh/aliases faz:

alias gh='$HOME/.config/zsh/bin/github-proxy gh'

O wrapper é este:

#!/bin/bash
set -euo pipefail

proxy_host="127.0.0.1"
proxy_port="9050"
tor_dir="${XDG_RUNTIME_DIR:-/tmp}/github-proxy-tor"
tor_rc="$tor_dir/torrc"
tor_log="$tor_dir/tor.log"

if [[ $# -eq 0 ]]; then
  echo "usage: github-proxy <command> [args...]" >&2
  exit 2
fi

if ! ss -ltn "sport = :$proxy_port" | grep -q "$proxy_host:$proxy_port"; then
  mkdir -p "$tor_dir"
  : >"$tor_rc"
  tor -f "$tor_rc" --SocksPort "$proxy_host:$proxy_port" --DataDirectory "$tor_dir/data" >"$tor_log" 2>&1 &

  for _ in {1..60}; do
    if grep -q 'Bootstrapped 100%' "$tor_log"; then
      break
    fi
    if ! kill -0 "$!" 2>/dev/null; then
      echo "github-proxy: tor exited before bootstrap; see $tor_log" >&2
      exit 1
    fi
    sleep 1
  done

  if ! grep -q 'Bootstrapped 100%' "$tor_log"; then
    echo "github-proxy: timed out waiting for tor bootstrap; see $tor_log" >&2
    exit 1
  fi
fi

export HTTPS_PROXY="socks5h://$proxy_host:$proxy_port"
export HTTP_PROXY="socks5h://$proxy_host:$proxy_port"
export ALL_PROXY="socks5h://$proxy_host:$proxy_port"

exec "$@"

Repare no socks5h. Esse h importa. Ele faz a resolução DNS pelo proxy, não pela sua rede local. Se você usa socks5:// normal, dependendo da biblioteca, o DNS ainda pode acontecer localmente antes de passar pelo proxy. Com socks5h://, a ideia é: “leva o hostname até o outro lado e resolve lá”.

Instalando no Arch

No Arch:

sudo pacman -S tor github-cli iproute2
mkdir -p ~/.local/bin

Crie o script:

nano ~/.local/bin/github-proxy

Cole o wrapper acima e dê permissão:

chmod +x ~/.local/bin/github-proxy

Teste direto:

~/.local/bin/github-proxy gh api rate_limit --jq .resources.core.limit

Conta autenticada normalmente retorna:

5000

Foi o que aconteceu aqui. Direto dava timeout. Pelo wrapper, gh api rate_limit --jq .resources.core.limit retornou 5000.

Agora adicione um alias no seu shell.

ZSH:

echo "alias gh='$HOME/.local/bin/github-proxy gh'" >> ~/.zshrc
source ~/.zshrc

Bash:

echo "alias gh='$HOME/.local/bin/github-proxy gh'" >> ~/.bashrc
source ~/.bashrc

Teste:

gh api rate_limit --jq .resources.core.limit
gh pr list

Ubuntu

No Ubuntu, o pacote do Tor é fácil:

sudo apt update
sudo apt install tor iproute2 curl

Para o GitHub CLI, se o pacote gh estiver disponível na sua versão:

sudo apt install gh

Se não estiver, siga a instalação oficial do GitHub CLI para Ubuntu/Debian. O resto é igual: crie ~/.local/bin/github-proxy, dê chmod +x, e coloque o alias no .bashrc ou .zshrc.

Alternativas melhores que Tor

Tor funcionou e é conveniente, mas não é a única opção. Às vezes é lento. Às vezes algum serviço encrenca com saída Tor. Para gh api e listar PR, tudo bem. Para uso pesado, talvez você queira algo mais previsível.

Opções razoáveis:

• VPN normal: Proton, Mullvad, IVPN, WireGuard próprio. Roteia tudo ou usa split tunneling se você souber configurar.
• Tailscale com exit node fora do Brasil: limpo, se você tiver uma máquina confiável fora ou uma VPS.
• SSH SOCKS para uma VPS: ssh -N -D 127.0.0.1:9050 usuario@seu-vps. Depois use o mesmo HTTPS_PROXY=socks5h://127.0.0.1:9050.
• Proxy corporativo: se sua empresa tem saída fora do Brasil, configure só as ferramentas que precisam.

O cuidado aqui é não sair mexendo em tudo ao mesmo tempo. Primeiro prove que api.github.com direto falha. Depois prove que via outro caminho funciona. Só então automatize.

Ajustando ferramentas próprias: ghpending

Esse bloqueio me pegou também num utilitário meu: ghpending. Eu já falei dele no post “Criei um CLI pra Checar Pendências no Meu GitHub: ghpending”. Ele lista issues e pull requests abertos nos meus repositórios, pra eu saber onde tem gente esperando resposta.

O problema é óbvio: ele usa a API do GitHub. Se api.github.com cai no buraco, ele cai junto.

Então adicionei fallback de proxy. O ghpending agora lê GITHUB_TOKEN como antes, mas também tenta usar proxy SOCKS nesta ordem:

1. GHPENDING_GITHUB_PROXY, se você quiser forçar um proxy específico.
2. HTTPS_PROXY, https_proxy, ALL_PROXY ou all_proxy, se forem socks5:// ou socks5h://.
3. Um SOCKS local em 127.0.0.1:9050, se estiver escutando.
4. Se nada disso existir, tenta direto.

No README ficou assim:

GITHUB_TOKEN=$(gh auth token) ghpending

E, para proxy:

GHPENDING_GITHUB_PROXY=socks5h://127.0.0.1:9050 ghpending

Ou simplesmente rode pelo wrapper:

~/.local/bin/github-proxy ghpending

Meu wrapper sobe Tor em 127.0.0.1:9050; o ghpending detecta esse proxy e usa para chamadas à API. Se você não está bloqueado, ele continua funcionando direto. Se você está bloqueado, ele tem um caminho de fuga.

Isso é o tipo de fallback que agora todo dev brasileiro deveria considerar para ferramenta que depende de API estrangeira. Não porque é bonito. Porque a internet brasileira está ficando imprevisível.

O problema político

No fim da thread, o Ayub lembrou que, por causa desses bloqueios colaterais sigilosos, já haveria cerca de 250 milhões de endereços bloqueados na internet brasileira. Ele também linkou uma apresentação sobre o panorama dos bloqueios no Brasil. Em outro tweet do mesmo fio, ele diz que autoridades defendem sigilo como única alternativa para combater crimes.

Eu não compro essa desculpa.

Bloqueio sigiloso de infraestrutura crítica, sem transparência, sem contraditório público, sem lista auditável, sem explicação de escopo, é censura operacional. Na minha leitura, é ilegal justamente por fugir do rito público e auditável que deveria existir quando o Estado manda quebrar acesso à internet. Pode ter começado com pirataria de TV box. Pode ter discurso bonito. Mas o mecanismo está aí: alguém aperta botão, operadoras aplicam bloqueio, usuários legítimos descobrem só quando ferramenta de trabalho para.

Hoje, o efeito colateral bateu em desenvolvedor honesto tentando trabalhar com GitHub. Amanhã bate em pacote de Linux, registry de container, CDN, API de pagamento, serviço de autenticação. Aí todo mundo corre pra VPN, Tor, proxy, DNS alternativo, /etc/hosts, Pi-hole. Parabéns: estamos recriando, aos poucos, o manual de sobrevivência de uma internet censurada.

Não precisa exagerar na metáfora. Ainda não somos a China. Mas o cheiro é o mesmo: bloqueio centralizado, opaco, com dano colateral, e usuário comum tendo que aprender bypass pra trabalhar.

Se você foi afetado, documente. Rode os comandos. Salve outputs. Abra issue no seu provedor. Reclame com dados. Compartilhe workaround, mas não normalize. Bypass é curativo. O problema real é um Estado que se dá o poder de quebrar pedaços da internet em silêncio.

E se você só queria rodar gh pr list pra revisar um pull request: bem-vindo à infraestrutura brasileira de 2026.

E-mail sempre foi a parte mais chata desse exercício. Meu workflow antigo era abrir o Thunderbird, deixar ele puxar tudo de Gmail via IMAP, e fazer backup do diretório ~/.thunderbird. Funciona, mas é manual, chato (lembrar de abrir o Thunderbird de vez em quando), e preso ao próprio Thunderbird: se quero ler aqueles e-mails em outro cliente, eles estão num formato interno proprietário.

Depois de um tempo caiu a ficha: Linux tem suporte nativo a e-mail desde sempre. Os protocolos modernos (IMAP, SMTP) são padrão aberto. E o formato de armazenamento local, Maildir, existe e funciona muito bem desde os anos 90. Não precisa de Thunderbird pra nada.

O que é Maildir

Maildir foi criado pelo Daniel J. Bernstein (djb) como parte do qmail em 1995. A ideia era resolver os problemas de file locking do formato mbox, onde a caixa de e-mail inteira é um arquivo único e dois processos escrevendo ao mesmo tempo podiam corromper tudo. No Maildir, cada mensagem vira um arquivo separado numa estrutura de três subdiretórios:

• tmp/ — onde o e-mail é escrito enquanto chega
• new/ — mensagens novas, ainda não lidas
• cur/ — mensagens já vistas pelo cliente, com flags no nome do arquivo (:2,S = seen, :2,F = flagged, etc.)

A entrega é atômica: o MTA escreve a mensagem em tmp/, depois faz um rename() pra new/. rename() em filesystem POSIX é atômico, então não tem janela de corrupção. Sem locking, sem corrupção, e cada e-mail é só um arquivo de texto puro que você pode ler com cat, indexar com grep, versionar com git se quiser.

Trinta anos depois, ainda é o formato local padrão da maioria dos clientes de e-mail Linux. E é o formato que vou usar pra fazer o mirror do Gmail.

A ferramenta: mbsync (isync)

O que faz a ponte entre o IMAP do Gmail e o Maildir local é o mbsync, o binário do pacote isync. Ele lê uma config simples (~/.config/isyncrc), conecta no IMAP do Gmail, e copia as mensagens pro disco. A diferença pro offlineimap (alternativa mais conhecida) é que mbsync é escrito em C, é bem mais rápido em mailboxes grandes, e tem menos casos esquisitos com Gmail.

A config é direta. Resumo do que tem no meu ~/.config/isyncrc (sem senha, claro):

IMAPAccount minha-conta
Host imap.gmail.com
User you@example.com
PassCmd "/home/akitaonrails/.config/mbsync/bin/mbsync-password you@example.com"
TLSType IMAPS
CertificateFile /etc/ssl/certs/ca-certificates.crt
AuthMechs LOGIN

IMAPStore minha-remote
Account minha-conta

MaildirStore minha-local
SubFolders Verbatim
Path ~/.local/share/mail/mbsync/you.example.com/
Inbox ~/.local/share/mail/mbsync/you.example.com/INBOX

Channel minha-backup
Far :minha-remote:
Near :minha-local:
Patterns * !"[Gmail]/Trash" !"[Gmail]/Spam" !"[Gmail]/Drafts"
Create Near
Sync Pull New Flags
Expunge None
Remove None

Três pontos importantes nessa config:

1. Sync Pull: só puxa do servidor pro local. Nada que eu faça no Maildir vai propagar pro Gmail. Isso é proteção contra acidentes (se eu apagar um arquivo localmente, não some do Gmail).
2. Expunge None + Remove None: se uma mensagem some do Gmail (alguém apagou ou o Google decidiu mover pra lugar nenhum), ela continua no meu Maildir. O backup acumula histórico, não espelha o estado atual.
3. PassCmd em vez de senha em texto: a senha vai num script que faz secret-tool lookup no keyring do desktop. Nada de senha em arquivo de config no disco.

O bloco da senha

O mbsync-password é um wrapper minúsculo que isola o segredo:

#!/usr/bin/env bash
set -euo pipefail
account="${1:?usage: mbsync-password ACCOUNT}"
password="$(secret-tool lookup service mbsync account "$account" 2>/dev/null || true)"
[ -z "$password" ] && { echo "missing keyring secret for $account" >&2; exit 1; }
printf '%s' "$password"

Senha é armazenada uma vez com secret-tool store --label="mbsync gmail" service mbsync account you@example.com. O Gmail moderno exige uma app password específica (16 caracteres, gerada em myaccount.google.com/apppasswords) porque não aceita mais autenticação básica direta — você não cola sua senha do Google ali, cola uma chave gerada exclusivamente pro app, que dá pra revogar a qualquer momento sem mexer no resto da conta.

Automação com systemd user timer

Pra não ter que rodar o mbsync na mão, montei dois user units no systemd. Primeiro o serviço, que é só uma chamada do script wrapper:

# ~/.config/systemd/user/mbsync-backup.service
[Unit]
Description=Mirror Gmail accounts locally with mbsync
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=%h/.config/mbsync/bin/mbsync-run

E o timer que dispara o serviço periodicamente:

# ~/.config/systemd/user/mbsync-backup.timer
[Unit]
Description=Run mbsync periodically

[Timer]
OnBootSec=10m
OnUnitActiveSec=30m
Persistent=true
Unit=mbsync-backup.service

[Install]
WantedBy=timers.target

OnBootSec=10m espera 10 minutos depois do boot pra primeira execução (evita brigar com o network-online no início da sessão). OnUnitActiveSec=30m re-dispara 30 minutos depois de cada execução terminar. Persistent=true faz com que, se a máquina estava desligada na hora que seria pra disparar, ele compense rodando logo no próximo boot. O wrapper já pega flock pra não rodar dois mbsync em paralelo, então se uma sincronização demorar mais que 30min, a próxima só espera. Tudo loga em ~/.local/state/mbsync/mbsync.log.

Pra gerenciar o timer, os comandos básicos:

# Re-ler os arquivos depois de criar/editar
systemctl --user daemon-reload

# Ativar agora + habilitar pra subir no próximo boot
systemctl --user enable --now mbsync-backup.timer

# Conferir se o timer tá ativo e quando dispara da próxima vez
systemctl --user status mbsync-backup.timer
systemctl --user list-timers mbsync-backup.timer

# Disparar uma sincronização imediata sem esperar o intervalo
systemctl --user start mbsync-backup.service

# Acompanhar logs em tempo real
journalctl --user -u mbsync-backup.service -f

# Conferir status da última execução do serviço
systemctl --user status mbsync-backup.service

# Pra desligar tudo
systemctl --user disable --now mbsync-backup.timer

Pra que o timer continue rodando quando você não está logado (útil em desktop que fica ligado 24/7), habilite linger uma única vez: sudo loginctl enable-linger $USER. Sem isso, os user units só rodam enquanto você tem sessão ativa.

Ativa, confere o status uma vez pra ter certeza que tá verde, e esquece que existe.

Backup do Maildir com restic

Agora que o Gmail está espelhado em ~/.local/share/mail/, ele entra no mesmo pipeline de backup do resto do meu home. Eu uso o restic pra mandar snapshots criptografados pro NAS. O restic é incremental por content-addressable storage, então adicionar 100MB de e-mail no snapshot diário custa basicamente o delta — não os 100MB inteiros toda vez. Pra cópia off-site, meu NAS Synology já tem o pacote Glacier Backup nativo, que cuida de mandar snapshots criptografados pro AWS Glacier sem eu precisar configurar nada além do bucket e da chave. O Maildir entra junto no mesmo plano, então o backup off-site sai de graça em termos de configuração extra.

O Maildir é amigável a backup incremental por construção: cada e-mail é um arquivo imutável (nem o nome muda depois de baixado, exceto pela flag de seen/flagged). O restic deduplica perfeitamente. Snapshot de mailbox de 5GB tem custo marginal próximo de zero depois do primeiro.

A vantagem do formato aberto: muitos clientes

Aqui mora a parte que me convenceu de vez. Maildir é um padrão aberto, então qualquer cliente que entenda Maildir lê o mesmo backup. Eu posso:

• Abrir no mutt ou neomutt quando quero algo rápido no terminal.
• Abrir no aerc quando quero TUI mais moderna.
• Apontar o Thunderbird ou Claws Mail pra ~/.local/share/mail/... quando quero GUI.
• Migrar pra outro cliente no futuro sem ter que exportar/importar nada.

Os e-mails são meus. Vivem no meu disco. Em formato texto, legível por qualquer ferramenta.

Bônus: scripts e bots leem direto

A consequência menos óbvia disso é que, se eu quiser construir um filtro, um bot, um classificador, ou qualquer coisa que mexe nos e-mails, eu não preciso passar por OAuth do Gmail, criar projeto no Google Cloud, gerenciar refresh tokens, lidar com quota — nada. Eu leio direto do Maildir.

O Python tem suporte nativo a Maildir na biblioteca mailbox. Um exemplo bobo pra listar assuntos da inbox:

import mailbox
from email.header import decode_header

inbox = mailbox.Maildir("/home/akitaonrails/.local/share/mail/mbsync/you.example.com/INBOX")

for key, msg in inbox.iteritems():
    subject = msg.get("Subject", "")
    sender = msg.get("From", "")
    # decode_header lida com Subject em UTF-8 / latin-1 / etc
    decoded = "".join(
        part.decode(enc or "utf-8") if isinstance(part, bytes) else part
        for part, enc in decode_header(subject)
    )
    print(f"{sender[:40]:<40}  {decoded[:60]}")

Roda em milissegundos, não consome quota de API nenhuma, não tem rate limit, não precisa renovar credencial. É só leitura de arquivos. Se você quer fazer um pipeline mais sério (parser de anexos, classificação por LLM, regras automáticas), o mesmo princípio se aplica.

Resumo

A combinação que finalmente me deixou tranquilo:

• mbsync (isync) puxa do IMAP do Gmail pra Maildir local, automaticamente via systemd timer.
• Maildir preserva o formato aberto, cada e-mail é um arquivo, pull-only protege contra exclusão acidental.
• restic snapshota o Maildir pro NAS com deduplicação ridícula, e o Glacier Backup do Synology leva isso pra off-site cifrado.
• Cliente de e-mail livre — mutt, neomutt, aerc, Thunderbird, Claws, qualquer um lê.
• Automação leve — bot ou script lê direto do disco, sem OAuth, sem API.

O Gmail vira só uma interface web confortável pra ler e responder. A propriedade real dos e-mails está no meu disco, replicada no NAS, replicada em backup off-site cifrado. Se o Google fechar minha conta amanhã (já aconteceu com gente), perco a interface, mas mantenho a história inteira. Pra mim é o jeito definitivo de fazer isso. Recomendo.

Esse post inaugura um projeto experimental que tenho mexido nas últimas semanas: NW-Omarchy. A ideia é simples de explicar e razoavelmente teimosa de defender: pegar o look-and-feel opinativo e bonito do Omarchy (que é Hyprland, ou seja, Wayland) e levar tudo isso pro mundo X11, como uma sessão paralela que você escolhe no SDDM. Sua sessão Hyprland continua intocada. Quando quiser experimentar X11, escolhe nw-bspwm no login e cai num ambiente que parece o mesmo Omarchy só que com outras peças por baixo.

A pergunta óbvia é “por quê”. A Red Hat já comunicou em 2025 que o xorg-server upstream sai do RHEL 10, e o discurso oficial do mundo Linux corporativo virou “use Wayland e pronto”. Como sempre, em open source a gente não precisa concordar. Existe XLibre, um fork do xorg-server retomando manutenção ativa, e existe muita gente com hardware velho, driver legado ou software legado pra qual Wayland ainda não é caminho viável. NW-Omarchy é pra esse cenário: dar uma sobrevida elegante pra esse equipamento e, de quebra, deixar ele bonito.

O que é XLibre e por que ele importa

XLibre é um fork do xorg-server iniciado em 2025, depois que ficou claro que o upstream não tinha mais energia pra evoluir. O X.Org em si só recebia patches críticos de segurança, e o principal financiador histórico do desenvolvimento (Red Hat) comunicou que vai parar com o RHEL 10. XLibre pegou a base e voltou a fazer cleanup, security fixes, modernização e bumps de driver-ABI. A primeira release pública foi a XLibre 25.0, e o projeto vive em github.com/X11Libre/xserver.

A pegada técnica do XLibre é ser drop-in replacement pro xorg-server. Mesmo protocolo X11, mesma API client (libxcb/libx11), mesmo grafo de dependência no pacman. Seu xterm, seu Firefox, seu Steam, seu emulador favorito de fliperama dos anos 90, nada disso sabe que o servidor X mudou. Distros que já adotam XLibre como default ou tier-one:

• Artix Linux (2026.04+) usa como X server padrão.
• Fedora tem Change proposal aberta pra migrar.
• Arch Linux tem repo binário oficial em x11libre.net/repo/arch_based/. É exatamente esse que NW-Omarchy usa.

Comparando o que tá vivo:

Se o seu argumento pra ficar no X11 é qualquer um dos clássicos (driver proprietário antigo de Nvidia, GPU Intel vintage, laptop Optimus com muxing esquisito, dependência de xdotool/wmctrl/xprop/xinput pra acessibilidade ou ferramentas de remap, ssh -X pra rodar app remoto, clipboard sem prompt de permissão, screen reader que precisa ler input de qualquer janela), o XLibre é o caminho que mantém esse stack em manutenção ativa.

Por que esse projeto existe

Eu rodo Omarchy no meu Thinkpad T14 Gen 6 (escrevi sobre isso aqui) e gosto bastante. O DHH fez um trabalho de curadoria muito bem pensado: tema único e consistente em tudo (terminal, launcher, top bar, lockscreen), atalhos coerentes, distinções visuais que não cansam o olho. É opinativo do jeito certo, te tira da fadiga de configurar tudo do zero.

O problema é que Omarchy é Hyprland, Hyprland é Wayland-only, e Wayland tem cenários onde ainda não é a ferramenta certa. Máquinas mais velhas com driver Nvidia legado, ambientes que dependem de software com integração X11 profunda, situações onde você quer ssh -X e não quer aprender waypipe, ou simplesmente máquinas que você quer manter funcionando sem trocar metade do stack. Pra esses casos, eu queria a estética e o workflow do Omarchy, mas em cima do X11. Não existia. Então fiz.

O nome NW-Omarchy é abreviação de “Not Wayland Omarchy”. É deliberadamente um sidecar: roda em paralelo, não substitui. Você instala em cima de uma instalação Omarchy existente, ele cria uma sessão SDDM separada chamada nw-bspwm, e nada do seu Hyprland é tocado. Quer voltar pro Hyprland? Escolhe Hyprland no SDDM no próximo login. Quer desinstalar? Tem script de uninstall que reverte exatamente o que foi instalado, baseado num manifest que rastreia cada ação.

O que muda no stack (Wayland → X11)

Hyprland é compositor + WM no mesmo binário. No mundo X11 essas duas funções vêm em peças separadas, e cada uma tem um substituto bem-conhecido. O esforço de tradução foi mapear cada componente do Omarchy pro equivalente X11 e garantir que o atalho de teclado, o tema e o comportamento ficassem o mais próximos possível.

bspwm é tiling window manager minimalista. O WM em si só responde a comandos via socket, e o bspwmrc é literalmente um shell script. Atalho de teclado fica num daemon separado, sxhkd, que lê um arquivo de texto. Essa separação é típica do mundo X11: cada peça faz uma coisa só.

picom é o compositor que dá blur, sombra, cantos arredondados, fade-in/out e regras de opacidade por janela. NW-Omarchy usa o upstream v13 (release de fevereiro de 2026), não o fork antigo picom-ftlabs-git, abandonado desde 2024. Os efeitos visuais que o Omarchy tem no Hyprland (cantos arredondados, fade ao abrir/fechar, blur no rofi e no dunst) vêm todos do picom no NW-Omarchy.

polybar substitui o waybar. Mesma topologia visual: logo do Omarchy à esquerda, data no centro, indicadores de áudio/wifi/bluetooth/bateria à direita. Os ícones nerd-font são os mesmos. Click esquerdo abre os mesmos TUIs (wiremix, impala, bluetui), click direito as variantes GUI. Scroll no áudio ajusta volume, click do meio mute. Paridade prática.

rofi substitui o walker. super + space abre o launcher completo com todos os .desktop do sistema e ícones. super + shift + space abre uma cheat-sheet das aplicações fixadas, mostrando o atalho ao lado do nome. Útil pra lembrar “qual era o chord pro Signal mesmo”.

Pra usuário que não vai abrir o ~/.config pra customizar nada, a diferença entre as duas sessões é cosmética em níveis homeopáticos. Os mesmos atalhos do Omarchy (mais de 70 bindings) estão mapeados, os mesmos menus aparecem, o mesmo logo no canto da bar, os mesmos ícones nerd-font.

O sistema de temas é o mesmo

Essa parte foi a mais legal de implementar e a que mais surpreende quando você experimenta. O Omarchy tem um sistema de temas centralizado: cada tema vive em ~/.local/share/omarchy/themes/<nome>/, traz um colors.toml com paleta universal (accent, background, foreground, color0..15), e omarchy-theme-set <nome> re-renderiza configs de cada app pra refletir essa paleta. O tema ativo fica em ~/.config/omarchy/current/theme/, e cada app importa as cores de lá.

NW-Omarchy se encaixa nesse mesmo pipeline. Eu adicionei templates .tpl pra bspwm, polybar, rofi e dunst que seguem a mesma convenção do Omarchy, e o omarchy-theme-set-templates regenera tudo a cada troca de tema. O resultado é que os 19 temas que o Omarchy distribui funcionam tal e qual no NW-Omarchy, sem trabalho de portar. Catppuccin, gruvbox, kanagawa, nord, tokyo-night, todos funcionam. O wallpaper troca junto via um daemon inotify (nw-omarchy-bg-watch).

Olha alguns exemplos rodando:

Quando o Omarchy ganha um tema novo via omarchy-theme-update, NW-Omarchy pega ele de graça. Sem trabalho extra, sem rebuild, sem precisar republicar nada do meu lado.

Menu do sistema e TUIs

O menu de sistema do Omarchy (aquele super + alt + space que abre o menu hierárquico com Hardware, Setup, Update, etc.) tem porte 1-pra-1 no NW-Omarchy. Mesma árvore, mesma navegação. Onde o Omarchy chama walker --dmenu, eu chamo rofi -dmenu. O resto do código é idêntico, e a maioria dos helpers que o menu invoca (omarchy-pkg-add, omarchy-theme-set, omarchy-update, etc.) não tem nada de Wayland-específico e funciona direto no X11.

Os TUIs também: wiremix pra áudio, impala pra wifi, bluetui pra bluetooth, btop pra recursos do sistema. Todos abrem como janela flutuante centralizada, igual o Omarchy faz no Hyprland. O bspwm tem regra (bspc rule -a) que reconhece a classe org.nw-omarchy.<cmd> e aplica state=floating center=on rectangle=900x600 automaticamente.

O que tem e o que não tem

Honestidade primeiro: tem coisa do Hyprland que é Wayland-only e não volta. Fractional scaling per-monitor não rola, X11 só faz scaling inteiro por output, então setup com mix de DPI fica torto. HDR não existe no X11. Renderização tear-free por design exige Wayland; no X11 precisa de picom + vsync e GPU cooperativa, e mesmo assim fica perto da Wayland sem chegar igual. Workspace swipe com preview ao vivo durante o gesto também não rola, porque o bspwm não tem estado de switch em progresso, então o gesto dispara comando discreto só na conclusão (você vai pra próxima workspace, mas não vê o preview deslizando). E os daemons especificamente Wayland (voxtype, walker preview pane, hyprsunset, hypridle) viram redshift e xss-lock, sem preview pane no rofi.

Se qualquer um desses pontos é decisivo pra você, fica no Omarchy/Hyprland. SDDM escolhe entre as duas sessões a cada login, então dá pra coexistir sem ressentimento.

Em compensação, o que o X11 tem de bom continua valendo. xdotool, wmctrl, xprop e xinput continuam funcionando pra automação, key remap, screen reader, AutoKey, kanata, xkeysnail. xclip, xsel e clipmenu fazem clipboard plumbing direto, sem dialog de permissão. ssh -X segue funcionando: você roda Firefox numa máquina remota e a janela aparece local. Driver Nvidia legacy, Intel vintage e Optimus quirky são first-class no X11. O ecossistema de tiling WM é maduro (bspwm, i3, awesome, openbox, xmonad, dwm) e configs migram entre eles com pouca dor. E o modelo de input previsível, onde qualquer cliente lê qualquer evento, é ruim pra segurança mas ótimo pra acessibilidade e ferramenta de produtividade.

Pra hardware mais velho, isso pesa como diferença entre “máquina viva” e “máquina parada num canto”.

Instalação

Pré-requisito: Arch Linux com Omarchy já instalado. NW-Omarchy roda em cima dele, não substitui.

One-liner de instalação:

curl -fsSL https://raw.githubusercontent.com/akitaonrails/NW-Omarchy/master/boot.sh | bash

O boot.sh faz preflight (checa Arch, Omarchy, git), clona o repo pra ~/.local/share/nw-omarchy, e roda a pipeline de install completa: pacotes, sessão nw-bspwm, configs em ~/.config, e troca pro XLibre como último passo. Pede confirmação uma vez antes de tocar em qualquer coisa. Se você quer pular a confirmação:

curl -fsSL https://raw.githubusercontent.com/akitaonrails/NW-Omarchy/master/boot.sh | bash -s -- --yes

Quando termina, reboota. A troca do X server (xorg-server → XLibre) só vale na próxima sessão. No SDDM, você verá um picker de sessão. A gente também substituiu o tema do SDDM por uma versão com seletor, porque o tema vanilla do Omarchy tem o nome da sessão hardcoded no QML, sem UI pra trocar. Escolhe nw-bspwm e tá dentro.

Se você prefere clonar e rodar à mão pra inspecionar antes:

git clone https://github.com/akitaonrails/NW-Omarchy.git ~/.local/share/nw-omarchy
cd ~/.local/share/nw-omarchy
./install.sh           # dry-run, mostra o que faria
./install.sh --apply   # executa de verdade

Atualização

Quando sai release nova, o caminho é:

nw-omarchy-upgrade --check    # checa current vs latest, sai
nw-omarchy-upgrade            # yay -Syu, fetch latest tag, migrations, install

O script roda yay -Syu (ou pacman -Syu se você não tem yay), compara a tag local vs a remota, e se tiver release nova faz git fetch && git checkout v<latest>, roda as migrations entre a versão atual e a nova, e re-aplica install.sh --apply. Tudo idempotente. Re-rodar numa máquina já atualizada é no-op.

Desinstalação

Se experimentou e não gostou, desinstala assim:

~/.local/share/nw-omarchy/uninstall.sh --apply

O uninstaller lê ~/.local/state/nw-omarchy/manifest.tsv e replay reverso: remove só os pacotes que ele instalou (pkg-skip rows ficam intocadas; pacote que já existia continua no sistema), restaura configs originais a partir de ~/.local/state/nw-omarchy/backups/, deleta a session entry nw-bspwm, limpa o state dir. Sua sessão Hyprland continua funcionando como antes. Nada do ~/.config/hypr/ ou do ~/.local/share/omarchy/ é tocado em momento algum durante a instalação ou desinstalação.

Pra reverter especificamente o XLibre de volta pro xorg-server (sem desinstalar o resto), o pacman resolve sozinho:

sudo pacman -S xorg-server xorg-server-common xf86-input-libinput

Pacote provides/conflicts cuida do resto da troca atomicamente.

Status: experimental, feedback bem-vindo

A versão atual tá em 1.0 mas o projeto continua novo, em fase de polimento. Os itens grandes já estão de pé: paridade de bindings, paridade de menu, paridade de temas, paridade dos TUIs, doctor pra checar saúde da instalação, manifest pra uninstall limpo. Falta lapidar, descobrir edge cases, exercitar em hardware variado, ouvir feedback de quem rodar em máquina diferente da minha (Thinkpad T14 Gen 6).

Se você experimentar e bater em algo (coisa que não funciona, configuração que faltou, comportamento que difere do Omarchy de um jeito que quebra fluxo), abre issue lá:

github.com/akitaonrails/NW-Omarchy/issues

Reproduções, stack traces, output do nw-omarchy-doctor, qualquer coisa ajuda. PRs também são bem-vindos.

A defesa do X11 em 2026 é pragmática. A transição pro Wayland leva tempo, muito hardware e muito software ainda vivem confortavelmente do lado de cá, e a comunidade open source comporta mais de um caminho ao mesmo tempo. XLibre é a aposta de manter o X server vivo por mais alguns anos. NW-Omarchy é minha aposta de que dá pra fazer esse stack mais velho parecer tão bonito quanto o stack mais novo, sem comprometer nada do que faz X11 ainda valer a pena.

Se você tá em máquina nova, com GPU moderna, monitor 4K HiDPI, querendo HDR, fica no Omarchy/Hyprland. Se você tá numa máquina mais antiga, ou simplesmente prefere o ecossistema X11 por qualquer um dos motivos acima, dá uma chance pro NW-Omarchy.

No topo dessa lista estão dois monstros. Primeiro, Driveclub no shadPS4. É exclusivo de PS4, nunca foi portado, a Evolution Studios foi fechada, não tem remaster. Pra jogar fora do PS4 original, só via emulação, e emulação de PS4 ainda é a parte mais imatura da ecossistema hoje. Esse é de longe o mais difícil da lista.

Segundo, Forza Motorsport 4 com Project Forza Plus no Xenia Canary. FM4 é o GOAT da era Xbox 360, Project Forza Plus é a mod comunitária que consolida patches e conteúdo, e fazer os dois rodarem juntos no Xenia com gráfico decente, sem crash de áudio e sem shadow bug, levou horas sérias de trial and error.

Em torno desses dois eu organizei o resto do que eu já sabia que funcionava em algum nível, só faltava consolidar num setup repetível: Gran Turismo 4 com Retexture 3.0 e HD HUD, Gran Turismo 3 com HD textures e widescreen, Gran Turismo 2 na mod Spec II, os Gran Turismos de PS3 (GT5 e GT6), os Forza Horizon 1 e 2, os PGRs, Ridge Racer, Enthusia, Colin McRae. Esses eu tinha ideia de como fazer, só precisava consolidar num setup que não volta a quebrar na próxima vez que eu reinstalar o sistema.

Antes de entrar no detalhe, preciso esclarecer duas coisas.

Primeiro, sobre a infra: não vou repetir aqui o como o setup foi montado. Já escrevi isso em detalhe no artigo Distrobox de Emulação com Claude Code. Arch Linux num distrobox com --nvidia, 17 roles Ansible, todos os emuladores no AUR, ES-DE como frontend, configs per-game automatizadas, scripts Python pra PS3 update check e Xbox 360 title updates, Xenia via Wine. Lê lá. O repo tá em akitaonrails/distrobox-gaming pra quem quiser reproduzir. Aqui eu vou falar dos jogos.

Segundo, sobre o gosto: eu gosto de simcade de corrida. Gran Turismo é meu vício declarado desde o PS1, e escrevi sobre o resto no artigo do meu cockpit Formula FX1. Volante direct drive, pedal com load cell, triple monitor quando tô afim de sofrer. Esse é o tipo de corrida que eu gosto.

O aviso pra quem já tá de dedo no teclado

Sim, eu conheço iRacing e os outros sims e simcades atuais. Eu tenho 12 TB de ISO e ROM no NAS, provavelmente tenho algum que você ia lembrar de citar. Não é por falta de opção que eu tô focando em emulação hoje.

Aliás, dos jogos novos que eu realmente tô esperando: Forza Horizon 6 em Tóquio, Assetto Corsa EVO e Assetto Corsa Rally. Tô jogando as demos dos dois Assetto Corsa e gostando muito das campanhas single-player. Quando eles saírem em versão final, vão virar meus jogos principais de sim na rotina. Esse artigo aqui cobre um lado diferente da coleção, que é tirar do esquecimento os clássicos que ainda não têm remaster.

Hoje, aqui, eu estou interessado nesses jogos específicos que listei acima. Ponto. Você faz o que você quer, eu faço o que eu quero. Se você quer iRacing, abra um Steam e vá em paz. Esse artigo é sobre mexer com emulador, preservar jogo velho, e tirar essas pérolas do esquecimento num setup Linux. Quem tá procurando review de sim atual não vai encontrar aqui.

Agora vamos ao que interessa.

Observação sobre os vídeos: a maioria tá sem áudio porque eu esqueci de ligar a captura de som no OBS antes de gravar e fiquei com preguiça de re-gravar. O áudio funciona perfeito em todos os emuladores aqui, é falha minha no OBS, não do setup.

Settings globais por emulador

Antes dos jogos, vale consolidar as configs globais que valem pra tudo em cada emulador. Isso tá automatizado no repo, mas se você tá configurando na mão, aqui tá o resumo.

DuckStation (PS1)

• Renderer: Vulkan
• Internal Resolution Scale: 8x (8K render, downscalado pro monitor)
• Texture Filtering: JINC2 (preserva pixel art mas suaviza)
• PGXP: ligado (corrige wobble de vértice típico do PS1)
• Widescreen Hack: ligado como fallback, mas preferência por cheat widescreen per-game
• Aspect Ratio: 16:9 com widescreen cheat, 4:3 sem

PS1 hoje em dia sobe liso no DuckStation. É o emulador mais maduro da lista. A atenção vai pras escolhas per-game (alguns jogos precisam de cheat específico de widescreen).

PCSX2 (PS2)

• Renderer: Vulkan
• Upscale: 4x SSAA (1440p nativo → 4K interno)
• Anisotropic Filtering: 16x
• Post Processing: FXAA ligado, PCRTC antiblur ligado
• Deinterlacing: Automatic (alguns jogos precisam override)
• Controller: bindings Xbox-style (eu uso controle 8BitDo)

PCSX2 2.7.x é muito superior ao 2.6.3 que ainda tá no repo oficial do Arch. O AUR pcsx2-latest-bin tracka o 2.7.x e é onde mora o texture replacement, FXAA moderno e PCRTC antiblur. Se você tá em distro diferente e tá no 2.6.3, procure o AppImage oficial.

RPCS3 (PS3)

• Renderer: Vulkan
• Resolution Scale: 300% (geralmente) ou nativo (jogos com issue de upscale)
• Shader Precision: Ultra
• Force High Precision Z: ligado
• SPU XFloat: Accurate
• Multithreaded RSX: ligado
• Write Color Buffers (WCB) / Read Color Buffers (RCB): desligados por padrão (GT-series safety)

RPCS3 é onde mais tem armadilha. Cada jogo tem preset recomendado na DB de compatibilidade oficial. E atenção: configs per-game ficam em ~/.config/rpcs3/custom_configs/config_<SERIAL>.yml. Prefixo config_ obrigatório. Perdi tempo até descobrir isso, o RPCS3 aceita o YAML silenciosamente e depois ignora se o nome tá errado.

Xenia Canary (Xbox 360)

• Build: Canary (o master tá parado há meses, Canary é o que anda)
• Renderer: Vulkan
• Render Target Path: rtv por default, fsi pra jogos específicos (PGR4)
• User Profile: criado uma vez, persiste
• Wine Prefix: dedicado, gerenciado pelo Xenia Manager

Xenia no Linux roda via Wine, gerenciado pelo Xenia Manager. Não tem build nativo decente. Funciona bem, mas cada jogo pede ajuste específico, e Title Updates tem que ser puxado manualmente do archive.org (escrevi um script pra isso, detalhes no artigo anterior).

shadPS4 (PS4)

Esse merece a seção dedicada no final. Resumindo: funciona pra alguns jogos simples, pra Driveclub ainda não é confiável. Continua sendo um tiro no escuro.

PS1 no DuckStation

Gran Turismo (o primeiro, de 1997)

Esse aqui é puro sentimento. GT1 foi um dos primeiros jogos que eu comprei pro PS1, e joguei até rachar o CD. Na época, era outro patamar. Simulação real numa máquina de 128K de RAM de vídeo, física decente, 140 carros quando todo mundo tinha 15, trilha sonora memorável.

Mas sejamos honestos: não dá pra voltar hoje. A física do GT1 tem drift exagerado, o carro desliza mais do que deveria em qualquer curva acima de 80 km/h. É parte do charme de 1997 mas irrita em 2026. O modelo de controle foi muito refinado a partir do GT2, e tudo que veio depois só melhorou. Entre GT1 e GT2, GT2 vence em conteúdo (650+ carros vs 140) e principalmente em dirigibilidade.

Eu deixo o GT1 no ES-DE pra abrir em momentos de nostalgia, jogar uns 10 minutos em Trial Mountain e fechar. Pra gameplay sério da era PS1, vai de GT2.

Gran Turismo 2 (Spec II Mod)

O Gran Turismo original do PS1 é um marco histórico. Eu joguei muito na época. Hoje, pra jogar de novo? Não. GT2 existe, e GT2 é superior em tudo. Mais carros (650+), mais pistas, mais modos, e principalmente, um modelo de controle muito melhor. O GT1 tem aquele drift exagerado onde o carro desliza mais do que deveria, o GT2 ajustou isso pra algo mais próximo do que a série seria a partir do PS2. Entre jogar GT1 ou GT2, sempre GT2.

E o GT2 que eu rodo hoje é o GT2 Spec II Mod do Project A-Spec, um projeto comunitário que consolida as duas variantes regionais (Arcade + Simulation) num único jogo, traz de volta eventos que foram cortados no release final, corrige bugs de física, adiciona suporte a widescreen nativo e dá quality-of-life updates em menus. É o jeito definitivo de jogar GT2 em 2026. O projeto não mantém mais site próprio, as atualizações vêm pelo Twitter do autor.

Pra rodar:

O cheat de 8 MB RAM é importante pra pistas cheias (tipo Seattle em corridas populated) onde o áudio começa a estourar. Ele simula a expansão de memória da versão japonesa que nunca veio pro Ocidente.

Colin McRae Rally 1 e 2

Jogos icônicos do PS1. CMR1 tem aquela sensação áspera de rally primeiro-gen que tem seu charme. CMR2 é tecnicamente superior, física melhor, mais rallys, melhor grafia. Mas eu vou ser honesto: pra jogar CMR2 hoje, vale procurar a versão PC original. Resolução maior, 60fps nativo (a versão PS1 trava em 30), controle direto de teclado/volante. Existem repacks do Codemasters na internet, tem umas 40 segundos num search decente. Não vou linkar, você sabe onde procurar.

No PS1 via DuckStation eles rodam liso, nostalgia garantida, mas não é onde eu passo o tempo.

PS2 no PCSX2

Gran Turismo 3 A-Spec

GT3 foi um salto geracional. Saiu do mundo quadradinho do PS1 pra um mundo de shaders, environment mapping decente, modelos de carro com polígono sério, física que finalmente começou a parecer com física de verdade. A trilha sonora com Feeder de “Just a Day” abrindo o jogo ainda me dá arrepio.

O problema é que GT3 tem MENOS conteúdo que GT2. Polyphony foi mais cautelosa, cortou modos pra focar em qualidade. Licença A/B/S é menor, carros são menos, pistas são fewer. Mas o que tem é polido.

Em 2026 no PCSX2 2.7.x, GT3 fica muito bom. HD textures de comunidade, widescreen pnach, anti-aliasing via SSAA, 16x AF. Parece jogo relançado.

Caveat sobre o pack de retextura: quando ligado, tem cenas de mostruário de carro no garage onde o NFS stream causa um flicker momentâneo. Não incomoda em corrida. Se te irrita no menu, desliga.

Lembrete: pro widescreen pnach fazer efeito você ainda precisa entrar nas opções dentro do jogo e mudar o aspect ratio pra 16:9. O pnach libera a opção no menu, não aplica automaticamente.

Gran Turismo 4 (Spec II Mod)

GT4 é o meu GOAT da série. 700+ carros, 50+ circuitos, física ainda respeitável pra padrão 2026, e aquela trilha sonora que mistura rock alternativo, lounge japonês, e o infame “Sail Away” do Moby no menu principal. Foi o jogo que mais mexi em 2004, e é o que eu mais mexo hoje.

Igual o GT2, o GT4 que eu rodo hoje não é o disco original. É o Gran Turismo 4: Spec II mantido pelo TheAdmiester — uma mod comunitária massiva que é objetivamente o melhor jeito de jogar GT4 em 2026. Ela combina o disco final USA, a Beta prototype de 2003 e o release japonês original num único jogo, restaurando carros cortados (incluindo vários que nunca saíram fora do Japão), eventos cancelados, dezenas de faixas de trilha sonora faltantes, suporte a widescreen 16:9, mais de 30 cheats integrados como opções de menu (pro tuning, velocidade máxima, economia de combustível), opção de trocar entre idiomas Inglês/Japonês, e correções de bugs originais. O projeto é ativo, ainda recebe patches e tem instalador próprio que aplica sobre uma ISO USA limpa.

Na prática, Spec II é o que o GT4 deveria ter sido se a Polyphony tivesse tido mais seis meses pra polir. Quando você joga hoje, é GT4 com todo o conteúdo que ficou de fora + quality-of-life moderno. Pra qualquer um que gostou do original, é obrigatório.

Por cima disso vai o Retexture 3.0 da comunidade (pack de textura HD) e o HD HUD do Silentwarior112. Com essas três peças juntas (Spec II Mod + Retexture + HD HUD), GT4 roda a 1440p SSAA no PCSX2 2.7.x com 16x AF, FXAA, e uma cara que honestamente é indistinguível de um jogo novo em low-poly style. É o meu atual favorito pra sentar e jogar longo.

Quem tá usando o Spec II Mod precisa atentar pro CRC: os HD packs do GT4 vanilla foram feitos pro 77E61C8A (USA), então no Spec II com CRC 4CE521F2 eu linko os assets via symlink na pasta CRC-suffixed que o PCSX2 procura. O pnach de widescreen também foi renomeado pra bater com o CRC do Spec II. Sem esse cuidado, o jogo roda mas os mods não carregam.

Lembretes in-game: igual ao GT3, o widescreen pnach só libera a opção, você ainda precisa entrar em Options dentro do jogo e trocar pra 16:9. E importante: mude o modo de vídeo pra progressive 480p (também em Options). O default é interlaced 480i, que fica péssimo em tela moderna. O Spec II Mod tem suporte nativo a progressive, é só ligar.

Se eu pudesse recomendar um único GT da série pra alguém começar hoje, seria esse. Se você gosta de corrida e nunca jogou GT4 full, tá perdendo.

Enthusia Professional Racing

Enthusia é o jogo esquecido da Konami de 2005. Saiu na sombra do GT4 e morreu no balcão. É uma pena, porque a física do Enthusia era mais realista que a do GT4. Peso do carro, transferência de massa, comportamento em limite, tudo mais próximo do comportamento real. A comunidade sim-racing dos anos 2000 sabia disso e o jogo tem culto hoje.

O problema do Enthusia era o sistema de Enthusia Points: você ganhava pontos por andar limpo, perdia por bater, e a progressão do jogo dependia desses pontos. Muita gente achou punitivo. Eu achei perfeito. Forçava você a dirigir com cabeça.

Em PCSX2 com retexture e widescreen, o jogo fica muito bom. Recomendação forte pra quem quer algo diferente dos Gran Turismo.

Ridge Racer V

Ridge Racer é sua própria coisa. Não é simcade, é arcade puro. Drift tudo, colinha dinâmica, trilha sonora eletrônica, cores saturadas. Ridge Racer V foi o jogo de lançamento do PS2 no Japão e por isso tem aquele cheiro de “mostra o que o console pode fazer”, com cenários colossais e sensação de velocidade que GT nunca tentou.

No PCSX2 ele roda bem, com uma caveira: textura de carro às vezes flicka em hardware renderer (issues #3639 e #13729 do PCSX2). Software renderer resolve mas mata performance. Eu fico no hardware e aceito o flicker ocasional.

Colin McRae Rally 3, 4, 5 (PS2)

Versões de PS2 dos Colin McRae rodam bem no PCSX2 com configs default. CMR3 e CMR04 são bons. CMR05 (o último antes do rebrand pra Dirt) é o melhor dos três tecnicamente. Mas de novo: se você tá em PC, procura a versão nativa. Os ports de PS2 eram relativamente inferiores aos PC da época, rodavam em resolução menor, e o PC moderno com repack vai dar 144Hz fácil.

Fica o registro no PCSX2 pra completude da coleção.

PS3 no RPCS3

Gran Turismo 5

GT5 é controverso. Polyphony prometeu mundos e entregou um jogo meio fragmentado: modelos Premium lindos ao lado de Standard que eram basicamente carros do GT4 em HD, sistema de níveis que alguns amaram e outros detestaram, online que foi pra lama quando o serviço PSN desligou, modo Top Gear que era estranho. A crítica na época foi mista, e eu lembro de comunidades inteiras brigando sobre se o jogo era decepção ou genial.

Pra mim, é genial. GT5 tem o Course Maker (edita tua própria pista baseada em seções reais), o Nurburgring 24h real com chuva dinâmica, o Moon Rover (sim, modo de dirigir na Lua), Red Bull X-Challenge com Vettel, e a experiência de endurance single-player é ridiculamente grande. Quem entrou no jogo a fundo sabe que tem conteúdo pra ano inteiro.

No RPCS3 em 2026, GT5 roda muito bem. Estável, sem os bugs graves de anos passados. É o GT mais estável que eu tenho emulado hoje.

A combinação Shader Precision Ultra + Force High Precision Z mata o dithering típico do RSX que fazia GT5 parecer granulado em RPCS3 antigamente. Sem esses dois, o asfalto parece ter ruído constante. Com eles, o jogo fica limpo.

Gran Turismo 6

GT6 é um dos meus preferidos da série. Saiu em 2013 pra um PS3 no final de vida, enquanto a concorrência já olhava pra PS4. Vendeu mal. Muita gente não jogou. E é uma pena, porque GT6 pegou a base do GT5, cortou a gordura (Standards foram reduzidos), adicionou mais Premiums, sessões em circuito no Moon melhores, meteorologia dinâmica em mais pistas, refinamento de física. É basicamente o GT5 polido.

Em conteúdo, GT6 é comparável ao GT4. Muitos jogadores da velha guarda botam o GT4 acima por causa do charme da era PS2. Eu fico entre os dois e vou mais pro GT6 em dia normal, GT4 em dia nostálgico.

Em RPCS3, GT6 tem uma pegadinha grave: patches 1.06 em diante regridem visualmente. Superfícies pretas em carros no menu garagem, flicker em cockpit view, tela inteira piscando em certas pistas. A versão que funciona bem em 2026 é travada em v1.05. O script extract_ps3_dlc.py do repo tem um ceiling por título específico pra pinar GT6 em 1.05 mesmo quando o PSN cuspa 1.22 como “mais recente”.

Além disso, Force CPU Blit é mandatório. Sem ele, tem flicker de tela inteira em menu. O trade-off é que o retrovisor fica permanentemente preto. Eu prefiro perder o retrovisor a ter o flicker. Quem quer retrovisor pode ligar Write Color Buffers, mas aí a resolução cai pra 720p nativo.

Em 2026, com essas configs, GT6 tá no meu rodízio. Não é perfeito, mas é jogável o suficiente pra eu passar uma tarde fazendo endurance.

Ridge Racer 7

Ridge Racer 7 foi lançamento do PS3 em 2006 e é o último mainline da franquia. Arcade igual Ridge Racer V, drift-first, trilha sonora eletrônica, câmera cinemática. Pra PS3 da época era uma demo tecnológica bonita.

No RPCS3 ele roda, mas com caveats: requer Write Color Buffers ligado pra não ter problemas de iluminação, e o preset recomendado na compat DB é diferente do meu preset GT. Eu uso config per-game dedicada pra ele. Não é meu favorito, mas tá lá pra completude.

Sem vídeo pra esse, gravo depois.

Xbox 360 no Xenia Canary

Aqui tá a parte que mais me deu dor de cabeça nesse domingo. Xbox 360 no Linux é território hostil. Xenia roda via Wine, cada jogo tem tweaks específicos, title updates tem que vir do archive.org, e Forza Motorsport 4 especificamente tinha problemas sérios até pouco tempo atrás.

Forza Motorsport 4 (o GOAT)

FM4 é, pra muita gente, o melhor Forza Motorsport já lançado. Polyphony fez Gran Turismo, Turn 10 fez Forza, e FM4 é o pico da era 360. Modelos de carro belíssimos pra época, pistas bem construídas, física sólida sem ser simulador puro, Autovista mode com narração do Jeremy Clarkson, trilha sonora épica, e aquela sensação de Xbox 360 sendo usado no limite.

FM4 no Xenia era um pesadelo até recentemente. Shadow com artefato severo, texture pop-in constante no carro, textura de pista chiada e pixelada, céu com brilho completamente errado (ficava branco-estourado em vez do azul profundo original), e o pior: crash de áudio frequente, onde o XMA (codec proprietário do Xbox 360) travava e o som virava ruído agudo até congelar o jogo. Eu passei horas nesse domingo mexendo em config, testando builds, procurando issue no xenia-canary, testando diferentes title updates.

O que destravou:

• Build Xenia Canary mais recente (o master tá parado, Canary acompanha desenvolvimento ativo)
• Render Target Path: rtv (o default funciona bem pra FM4)
• Title Update 1.0.17.0 instalado via Xenia Manager (versão importa, mais velha dá regressão em sombras)
• GPU Vulkan com ICD NVIDIA forçado (no meu setup híbrido com AMD iGPU, tinha que forçar a 5090)

Depois disso, FM4 rodou. Não é perfeito. Ainda tem algum crash esporádico de áudio (xenia-canary issue #161 aberta). Mas é jogável, e eu passei umas duas horas do domingo no Top Gear Test Track só apreciando o Koenigsegg CCX. Valeu cada hora de debug.

Forza Motorsport 3

FM3 é uma das entradas boas da série, entre o charme áspero do FM2 e o pico técnico do FM4. Tentar emular foi surpreendentemente chato, porque eu tava usando a ISO errada.

Existem dois releases do FM3: o retail (disco original vendido em loja) e o Ultimate Edition (com todas as DLCs empacotadas num segundo disco). Eu tava tentando rodar o Ultimate, que combina dois discos numa ISO híbrida que o Xenia não parseia direito. Troquei pro retail padrão + DLCs instaladas separadamente via Title Update, e bingo, o jogo rodou na primeira.

Moral: se teu FM3 não tá rodando no Xenia, verifica se é retail. Ultimate dá problema.

Forza Motorsport 2

FM2 é da era 2007, primeira-gen do 360. Sistemas menos refinados, modelagem mais básica, mas aquele charme de Forza original que alguns preferem à sofisticação do FM4. No Xenia rodou praticamente out-of-the-box. Nenhum tweak especial.

Forza Horizon 2

FH2 foi o Forza Horizon mais polido da geração 360 (existe também a versão Xbox One, que é melhor tecnicamente, mas o 360 tem seu charme por causa do mapa menor e da progressão mais focada). Mundo aberto no sul da Europa, trilha sonora icônica, festival Horizon no seu pico.

No Xenia rodou sem pedir nada extra. Como o FM2.

Forza Horizon 1 (com XE Mod)

FH1 original roda OK no Xenia, mas tem uma comunidade que mantém o Forza Horizon 1 XE Mod, que melhora IA do tráfego, rebalanceia progressão, adiciona carros que ficaram de fora, corrige bugs conhecidos, e traz uns quality-of-life tweaks na UI. Eu testei o XE Mod nesse domingo e vale a pena. O jogo parece mais vivo e progressão mais justa.

Detalhes da instalação do XE Mod estão no site do projeto. Basicamente é patch sobre a ISO original + alguns title updates customizados.

Pra comparação, aqui é o FH1 sem o mod, rodando puro:

A diferença mais visível é no tráfego e na variedade de situações que aparecem, mas o XE Mod tem muita coisa que você só percebe depois de algumas horas.

Project Gotham Racing 3 e 4

PGR3 foi lançamento do 360 em 2005 e continua lindo hoje. Pistas urbanas (Nova York, Tokyo, Nurburgring, Las Vegas), kudos system, câmera cinemática. PGR4 adicionou clima dinâmico (chuva e neve) e motos (algumas pessoas adoram, eu prefiro fingir que não existe).

PGR3 no Xenia Canary roda razoavelmente bem com configs default. PGR4 precisa de tweak específico: render_target_path_vulkan = "fsi" no config. Sem isso, algumas pistas quebram com artefato visual severo (barras verdes atravessando a tela em corridas de neve).

E PGR4 no NVIDIA tem um bug conhecido de áudio: decoding XMA gera garbage intermitente (issue aberta no xenia-canary, sem resolução). Não é game-breaking, mas incomoda.

Ridge Racer 6

Ridge Racer 6 foi o Ridge Racer do 360, pula o 7 que ficou em PS3. Arcade puro, igual Ridge Racer V do PS2. No Xenia Canary roda com config default, sem tweak especial. É divertido pra sessão curta. Sem vídeo dele no artigo, mas tá no catálogo rodando.

PS4 no shadPS4: o estado do emulador

shadPS4 ainda não tem release estável. O projeto tá em desenvolvimento ativo, main branch muda várias vezes por semana, e “o que funciona hoje” pode regredir num rebase amanhã. Dito isso, muitos jogos já bootam e rodam bem o suficiente. Lista da comunidade tá no compatibility tracker e cresce toda semana.

A diferença entre shadPS4 e os outros emuladores desse artigo é o tipo de esforço. PCSX2, RPCS3, Xenia são projetos maduros onde cada jogo tem uma página de wiki razoavelmente atualizada. shadPS4 é o oposto: você lê um guia do Reddit, tenta reproduzir, descobre que o guia usa um fork específico (não o main oficial), ou um commit de dois meses atrás, ou um firmware com sys_modules linkados de jeito particular, ou patches XML aplicados numa ordem específica que o autor não documentou. Reproduzir setup de shadPS4 a partir de vídeo YouTube é tentar resolver Rubik’s Cube com venda.

Mas isso não significa que você não deve tentar. Significa que você precisa tratar shadPS4 como brincadeira, não como workflow. E se você tiver paciência, dá pra colher resultados impressionantes.

Driveclub: o impossível, finalmente possível

Driveclub é meu Moby Dick da emulação. É o único jogo de PS4 que eu quero muito rodar. Saiu em 2014 pela Evolution Studios, teve lançamento catastrófico (servers online colapsaram no dia 1), foi patchado durante dois anos até virar um dos melhores jogos de corrida da geração, e foi descontinuado pela Sony quando a Evolution foi fechada em 2016. Não tem port pra PC. Não tem remaster. Não tem sequel. Só existe no PS4.

E hoje, depois de muitas horas de debug, está rodando aqui. Menu principal carrega, intro roda, corridas começam, controle responde, áudio funciona, pistas de dia visíveis, pistas de noite com faróis iluminando pista. O vídeo acima é gameplay real, a 30 FPS estáveis, v1.28 com conteúdo DLC acessível.

Chegar até aqui exigiu desarmar várias armadilhas. Vale documentar, porque a maioria dos guias online não menciona nenhuma.

Armadilha 1: o FMOD loop error que não era FMOD

Quando você tenta bootar Driveclub no shadPS4 direto da PKG retail, o log estoura um loop infinito de:

/app0/audio/fmodstudio/masterbank.bank failed, file does not exist

A primeira reação é investigar FMOD. Tem gente na internet que passou horas mexendo em sceFont, libtbb, sceNgs2, convencidos que era problema de áudio ou lib HLE. Nada disso é a causa. O arquivo masterbank.bank literalmente não existe no disco, porque ele tá empacotado dentro dos arquivos gameNNN.dat num formato de archive customizado da Evolution Studios que o VFS do shadPS4 não sabe ler. A mesma história vale pra fontes, modelos, shaders. O conteúdo todo do jogo mora dentro dos .dat.

A única ferramenta pública que parse esse formato é o DriveClubFS do Nenkai. É uma app .NET que lê o game.ndx (o índice) e decomprime os .dat em arquivos soltos. Sem esse unpack, o shadPS4 não consegue abrir nada.

Detalhe de build: o projeto DriveClubFS tá em net9.0, e o Arch tem net8 e net10. Precisa retargetar o csproj pra net10.0 antes de buildar. O comando exato tá documentado no docs/driveclub-shadps4.md do repo.

Armadilha 2: v1.28 é patch, não instalador base

Como em qualquer PS4, update é patch que vai em cima de uma install base. A PKG do v1.28 traz o eboot atualizado, .dat com conteúdo novo e patch content (sce_sys/about/right.sprx), mas não traz param.sfo, disc_info.dat nem keystone. Esses metadata ficam na base de v1.00 — num PS4 real já estariam gravados do install original.

E tem mais: o game.ndx do v1.28 referencia tanto os .dat da base quanto os novos. Rodar o DriveClubFS contra só o v1.28 faz o índice apontar pra arquivos que não tão ali.

O sintoma mais cruel vem depois: o jogo boota, a Qt Launcher mostra o tile, você clica, a tela carrega. Aí o jogo decide que nenhum conteúdo “foi lançado ainda” e pede pra fazer download. Download obviamente não vai acontecer porque PSN pra PS4 não tá acessível. Você fica travado achando que é bug de rede, quando na verdade é metadata faltando.

O fluxo correto é tratar v1.28 como overlay sobre a base. Primeiro, extrai a PKG de v1.00 pra um dir dedicado (CUSA00003.v100-working-backup/ funciona bem, e dobra como snapshot de rollback se algum experimento quebrar a instalação viva). Depois extrai o v1.28 pra staging e linka os .dat de índice baixo da base dentro do staging pra o DriveClubFS enxergar o set completo. Roda o unpack. Sai com 8018 arquivos soltos, ~47 GB.

Move pra CUSA00003/ final, copia o eboot e conteúdo novo do v1.28 por cima, e puxa param.sfo, disc_info.dat e keystone da base de v1.00. O param.sfo da base já vem com APP_VER = 01.28 gravado (porque ela recebeu o patch original), então não tem conflito de versão. O eboot v1.28 lê esses arquivos e libera o conteúdo.

Armadilha 3: o patch XML de 60fps gera slow-motion

Tem um Driveclub.xml patch comunitário que faz o jogo renderizar a 60fps. Intuitivamente, parece ganho puro. Na prática, o patch reescreve o render rate mas não mexe no logic tickrate interno do jogo, que é fixo em 30fps. Num PS4 Pro real, o hardware reconcilia a diferença. No shadPS4, não.

Resultado: o jogo renderiza liso a 60fps, mas toda a física, AI, áudio, timing de corrida roda em câmera lenta. Você aperta acelerador e o carro leva dois segundos perceptíveis pra sair. Parece bug aleatório até você entender o mismatch.

Desabilitar o patch XML resolve (basta renomear o arquivo pra algo como .disabled). Sem o patch, o jogo fica a 30 FPS nativos, mesma velocidade do PS4 base stock. Que é o que a gente quer. Se alguém conseguir no futuro fazer um patch que mexa nos dois rates (render + logic), a gente religa.

Armadilha 4: pipeline cache precisa estar ligado

Default do shadPS4 vem com pipeline_cache_enabled = false. Num jogo grande como Driveclub, que tem centenas de shaders e pipelines Vulkan, isso significa que cada cold launch recompila tudo. Nos meus testes o primeiro launch contou ~864 shaders e ~590 pipelines sendo compilados em tempo real. O menu animava a 2-3 fps. Um minuto depois, com tudo compilado, saltava pra fluidez normal. Próximo launch, mesmo ciclo de compilação do zero.

Basta ligar "pipeline_cache_enabled": true no config.json global. Primeira sessão paga o custo único de compilação, sessões seguintes leem do cache e sobem direto.

Armadilha 5: TOML silenciosamente ignorado

O shadPS4 migrou de TOML pra JSON em config per-game em late 2025. Se você tem um CUSA00003.toml antigo na pasta custom_configs/, ele é silenciosamente ignorado, sem warning no log. Você pensa que sua config tá ativa, na prática tá rodando tudo default.

Deleta qualquer TOML e usa CUSA00003.json. As configs per-game que funcionam pra Driveclub são específicas e detalhadas, documentei todas no docs/driveclub-shadps4.md do repo.

Armadilha 6: controle não detectado sem hidapi hints

Qt Launcher do shadPS4 chama um Shadps4-sdl.AppImage interno. Sem env vars específicas do SDL hidapi, o controle (no meu caso 8BitDo Ultimate 2) não é detectado, mesmo funcionando em outros emuladores. O fix é wrapar o AppImage num shell que exporta SDL_JOYSTICK_HIDAPI=1 e variantes específicas por plataforma (PS4, PS5, Xbox), antes de executar o original.

Plugar o controle antes de abrir o Qt Launcher também ajuda. Hot-plug funciona durante o jogo, não antes.

Armadilha 7: pistas de noite ficam pretas no upstream

Esse aqui é o único que precisou de patch de código, não só config. No upstream do shadPS4, pistas de Driveclub à noite ficavam pretas. HUD aparecia em cima, mas pista, carro, tudo escondido num preto absoluto. Faróis do próprio carro não iluminavam nada.

Investigação apontou pro log repetindo 1325 vezes a mensagem ResolveDepthOverlap: Unimplemented depth overlap copy. A causa: o Driveclub usa renderer forward+, que escreve a profundidade da cena num buffer MSAA 4x D32Sfloat, depois lê esse mesmo buffer como R32G32B32A32Sfloat 1x pra efeitos tipo SSAO, volumetrics e iluminação dinâmica (faróis). O shadPS4 upstream tem caminho pra MSAA → MSAA e pra cor → cor como MSAA depth, mas não tinha caminho pra “MSAA depth de 4x vira color de 1x” nesse formato específico. Cai no else final, libera o buffer, e o shader lê lixo não inicializado — ou seja, preto.

Implementei no meu fork local do shadPS4 um ReinterpretMsDepthAsColor simétrico aos ReinterpretColorAsMsDepth que já existiam. É um fragment shader minúsculo (ms_depth_to_color.frag) que faz texelFetch da profundidade sample 0 e escreve como vec4(depth, 0, 0, 1) no attachment de cor. Plus um helper no BlitHelper e um novo else if no TextureCache::ResolveDepthOverlap. Com isso, pistas de noite iluminam corretamente, faróis dos oponentes aparecem, AO e volumetrics no dia também ficam mais precisos.

O fix tá num branch gamma-debug do meu fork, pronto pra virar PR upstream. Enquanto não mergeia, quem quer rodar Driveclub à noite no shadPS4 precisa buildar desse branch. Quem fica só em corridas de dia pode usar o upstream nightly direto.

O que finalmente funcionou

Tudo isso tá encapsulado no docs/driveclub-shadps4.md do repo, com o passo a passo exato de extração, config e wrapper. A investigação técnica completa (5 fases, engineering log detalhado) tá no driveclub-v128-investigation.md do fork.

Quão jogável tá hoje

Bom. O vídeo acima é gameplay real, a 30 FPS estáveis, com física respondendo, áudio sincronizado, HUD correto, v1.28 com DLC acessível. Corridas de dia e de noite funcionam (com o fork do MSAA depth pra noite). O que sobra de limitação:

• Brilho de dia um pouco abaixo do que o PS4 entregava. Não é bug do emulador. Passei horas testando tonemap, auto-exposure, gamma curves, ACES, vários shaders de post-processing, e no fim descobri que o jogo escreve SDR já correto no framebuffer. O que estava faltando era o pipeline de calibração de display que o firmware 4.0+ do PS4 aplicava por fora, e que o Linux não tem. O slider de brilho in-game (que no shadPS4 mapeia pra sceVideoOutAdjustColor) funciona, mas só vai até o ponto que o jogo pensou que seria complementado pelo firmware. A cena de 5 segundos escuros no início da corrida também é fade-in cinematográfico do jogo, não falha de emulador. Aceitei.
• 30 FPS nativos. Sem patch de 60fps viável (pelo motivo do logic tickrate fixo). Stock PS4 speed.
• MSAA depth fix ainda no fork. Tem PR candidate pronto, aguardando upstream mergear.

“Achievement Unlocked”. O jogo roda, com som, controle, jogabilidade, dia e noite, e eu completo corrida inteira sem crash. Isso é um marco pessoal. Eu passei anos tentando fazer esse jogo rodar no Linux e chegava num ponto onde simplesmente desistia. Agora é parte do meu ES-DE, atalho no desktop, tá lá esperando eu sentar pra jogar.

Se você quer replicar, o repo tá público. Boa sorte. Vai precisar de paciência.

“Achievement Unlocked”

Eu venho tentando fazer esses jogos funcionarem, em algum nível, desde que cada respectivo emulador saiu de alpha. GT2 eu tô rodando desde ePSXe. GT4 eu mexo desde PCSX2 0.9.6. FM4 eu tentei fazer rodar em Xenia duas vezes em anos anteriores e desisti nas duas. E Driveclub eu olhei pra cara do shadPS4 três vezes antes desse domingo e engoli em seco.

Hoje fechou. Os dois monstros que abriram esse artigo (Driveclub no shadPS4 e FM4 com Project Forza Plus no Xenia) estão rodando, junto com todo o resto da coleção de Gran Turismo, Forza, Ridge Racer, Colin McRae e Enthusia. Tudo num setup único, reproduzível, automatizado. Agora eu faço parte do grupo bem pequeno de pessoas que conseguiu brute force emular Driveclub no Linux, e isso sozinho já tornou o domingo inesquecível.

A frustração de anos não era falta de informação. Era o OPOSTO. Informação demais, mal indexada, espalhada em fóruns apagados, vídeos YouTube que ficaram datados, threads Reddit com soluções pra versão do emulador de dois anos atrás que não valem hoje, wiki de projeto desatualizada em metade das páginas, e mods com requisitos MUITO específicos de CRC, versão, patch, path, setting. Cada vez que eu sentava pra fazer um desses jogos rodar direito, eu ficava três horas lendo material conflitante antes de escrever a primeira linha de config. Pior ainda quando o material bom estava enterrado entre diagnósticos errados, tipo o FMOD loop do Driveclub que todo mundo investigava como se fosse problema de áudio quando na real era formato de archive proprietário da Evolution Studios.

O que mudou nesse último ano é que Claude Code consegue ser meu agregador. Eu peço pro Claude ir na issue tracker do Xenia, na wiki do PCSX2, no subreddit do RPCS3, nos PRs do shadPS4, comparar todas as informações com a versão atual do emulador instalada, cruzar com os logs que eu tô vendo, e me devolver a combinação que funciona hoje. Ele lê source code quando precisa, entende por que Force CPU Blit muda comportamento no GT6, acha qual title update do FM4 foi o que consertou o shadow bug, descobre que o DriveClubFS precisa de retarget pra .NET 10 antes de compilar. O que antes levava três fins de semana pesquisando agora leva uma tarde de execução assistida.

Esse domingo é o resultado consolidado de todo esse trabalho. distrobox-gaming é a versão desse conhecimento virada código, reprodutível, automatizada. Rodando numa máquina fresca, um ansible-playbook site.yml me põe de volta nesse estado em menos de duas horas. Menos de 10 comandos separam “Arch Linux vanilla” de “Driveclub rodando”.

Se alguém quiser contribuir, testar em outro hardware, reportar bug ou mandar config que ficou faltando, o repo tá aberto. Quanto mais gente testar em setups diferentes, mais resiliente o projeto fica. Se você melhorar a situação do Driveclub (mergear o MSAA depth fix upstream, patch de 60fps que também corrija o logic tickrate, dump de fontes que não precise hardware jailbroken), manda PR que eu abraço.

Por enquanto, eu vou fazer uma corrida na Islândia no Driveclub. Boa noite de domingo.

Comprei um Lenovo Thinkpad T14 Gen 6 e instalei Omarchy em cima. Não é minha máquina principal, nem pretende ser. É companion: um notebook pra abrir em cima da mesa do escritório de impressão 3D, dar um SSH no desktop, chamar Claude Code, acessar arquivos no NAS, debugar rede pelo ethernet sem ficar procurando adaptador USB e cabo longo. Esse artigo cobre a escolha do hardware, o setup de Omarchy em cima, as customizações específicas pra notebook e pra esse Thinkpad em particular, e as decisões de arquitetura que podem não ser óbvias.

Mini-review do Thinkpad T14 Gen 6

Vamos tirar do caminho: esse não é o notebook dos sonhos. Se eu fosse escolher por estética, pegaria um Asus Zenbook S 14 com tela OLED. Se fosse por portabilidade, o Thinkpad T14s com casca de alumínio, que é mais leve e muito mais bonito. O T14 regular tem tela IPS 1920x1200 de 14", 400 nits, 60Hz, sem HDR. Dá pro gasto, mas está longe da tela do Zenbook. A casca é de plástico com um acabamento emborrachado, o que deixa ele resistente a arranhão, mas não é premium. Revisões da NotebookCheck e da XDA Developers batem na mesma tecla: bom custo, boa conectividade, desempenho adequado pra escritório, mas a tela é datada.

O que compensa:

• Seleção de portas. HDMI full-size. Ethernet gigabit. USB-A, USB-C Thunderbolt 4, carrega pelo USB-C (não é carregador proprietário). Pra um companion de debug, isso é exatamente o que eu queria. O Zenbook S 14, por ser mais fino, corta portas.
• Sensor de digital funcional no Linux (Goodix MOC, funciona com libfprint em kernel 6.11+). Isso eu uso, detalho mais à frente.
• Teclado Thinkpad. Curso de tecla de 1.5mm, trackpoint, layout clássico. Não é o melhor teclado do mundo em 2026, mas é confiável e durável.
• Carcaça rugged. Vai cair, vai arranhar, vai viajar na mala. Se eu colocasse um Zenbook OLED ou um Macbook Pro em cima da mesa do escritório de impressão 3D, ao lado da impressora, com poeira de PLA voando, eu ficaria nervoso. O Thinkpad pode levar porrada.

Se eu quisesse máquina de jogo, pegaria um Asus Zephyrus G14, meu favorito de notebook gamer. Se eu quisesse máquina de trabalho criativo, pegaria o Asus Zenbook Duo (UX8406) com duas telas OLED verticais, ótimo pra edição de vídeo e modelagem 3D. Tenho grana pra qualquer Macbook Pro ou Mac Studio, e escolhi não ir por esse caminho. Explico melhor na próxima seção.

Meu caso de uso

Meu PC principal é um desktop com Ryzen 9 7950X3D, 96 GB de RAM, RTX 5090 de 32 GB. É onde eu trabalho, experimento com modelos locais, rodo containers, edito o blog. Pra jogo, tenho um mini-PC separado com RTX 4090. Esses dois atendem 100% do que eu preciso fazer em casa.

O notebook existe pra cobrir o 1% restante: sentar no sofá, levar no escritório de impressão 3D, levar na cozinha, levar em viagem curta. Não é pra substituir o desktop. É pra ter acesso remoto ao desktop quando eu estiver longe dele.

Na prática fica assim: abro o notebook, dou split no Hyprland, janela da esquerda dá SSH no desktop principal, janela da direita é o próprio notebook. Mesmo Omarchy nos dois, mesmos atalhos, mesmo bash. O notebook vira extensão do desktop, não um ambiente paralelo que eu tenho que reconfigurar na cabeça toda vez que alterno.

SSH fora de casa: Tailscale

Dentro da rede local, SSH é trivial, o notebook fala com o desktop via IP interno. Fora de casa é outra história. Meu IP doméstico é dinâmico, abrir porta 22 pra internet é péssima ideia, e mesmo com DDNS e port forwarding você está colocando SSH na cara da internet pra qualquer scanner achar.

A solução que uso é Tailscale. Pra quem não conhece: Tailscale é uma mesh VPN baseada no WireGuard, que cria uma rede privada entre seus dispositivos (o “tailnet”). Cada máquina roda o agente, autentica uma vez, e passa a ter um IP fixo na rede privada (tipo 100.x.y.z). O tráfego entre seus próprios dispositivos vai direto peer-to-peer, cifrado pelo WireGuard. Não passa por servidor central da Tailscale, eles só coordenam NAT traversal. Resultado: do meu notebook num café em qualquer lugar do mundo, eu dou ssh hal9000 e caio no desktop de casa como se estivesse na mesma rede.

Existem opções mais sofisticadas: Cloudflare Tunnel com Zero Trust pra expor serviços publicamente com autenticação SSO, headscale self-hosted, WireGuard cru com config manual, Nebula, OpenVPN. Cada uma tem seu caso de uso. Se você precisa expor serviços pra terceiros, controlar acesso granular por identidade, rodar a infraestrutura inteira em casa sem depender de terceiros, essas opções ganham. No meu caso, é só notebook falando com desktop, por períodos curtos (não é trabalho de uma semana inteira, é debug rápido de fim de semana), então Tailscale grátis resolve. O tier free aceita até 100 dispositivos e 3 usuários, muito mais do que eu preciso.

Setup é o mais simples possível:

# No Arch/Omarchy
sudo pacman -S tailscale
sudo systemctl enable --now tailscaled.service
sudo tailscale up --ssh

A flag --ssh ativa o Tailscale SSH, que faz autenticação via identidade da tailnet em vez de chave SSH local. Uma vez fez login via browser no tailscale, cada máquina registrada pode entrar nas outras com base em política de ACL definida no painel admin. Zero key management.

Repito no desktop, faço login com a mesma conta, e pronto. As duas máquinas aparecem no painel (hal9000 e hal9666 na screenshot acima, com SSH habilitado nas duas). Do notebook: ssh hal9000. Do desktop pro notebook: ssh hal9666. Sem port forward, sem IP público, sem expor porta 22 pra internet. Se o notebook for roubado, eu removo ele do tailnet num clique.

Um detalhe prático: como o tailnet dá nome estável, eu adicionei entradas no ~/.ssh/config pra usar esses nomes curtos:

Host hal9000
  HostName hal9000
  User akitaonrails

Assim ssh hal9000 funciona de qualquer lugar que tenha Tailscale conectado. É a solução mais próxima de “it just works” que já vi pra SSH remoto.

Por que não um Mac

Eu não tenho uso pro macOS. Como dev, eu vivo melhor em Linux nativo. Toda ferramenta que eu preciso tem versão Linux de primeira, e no macOS eu teria versão de segunda via Homebrew. Não faço iOS, então não preciso do XCode. Pra mobile uso Flutter ou Hotwire Native, que rodam em qualquer OS. iTerm2 e Ghostty no Mac são bons, mas Alacritty, Kitty e o próprio Ghostty no Linux me atendem igual. Todo software bom chega primeiro no Linux, daí é portado pros outros. Arch com AUR cobre tudo num único yay.

Pra trabalho criativo, faz anos que não faço profissionalmente. DaVinci Resolve Studio no Linux é superior ao Final Cut Pro. Krita ou Affinity Photo substituem Photoshop na maioria dos casos. Clip Studio Paint no Android é superior ao Procreate. Eu simplesmente não tenho um workflow que depende da Apple, e a App Store me irrita.

Pra jogo, Mac é terrível. Apple Silicon tem GPU boa pra algumas coisas, mas a biblioteca de jogo pro macOS nativo é pífia comparada com Windows ou Linux. Game Porting Toolkit existe, CrossOver existe, mas pra quem joga sério, não serve. Eu não vou jogar no Thinkpad, pra isso tenho o desktop principal e o mini-PC com RTX 4090, mas se um dia bater vontade de rodar um Hollow Knight ou um indie num trem, é só instalar Steam e deixar o Proton fazer o trabalho. Linux virou plataforma de jogo de verdade nos últimos anos, com Proton/DXVK rodando quase todo o catálogo da Steam (checa ProtonDB). Inclusive documentei recentemente como rodei minha biblioteca de emulação em distrobox sem poluir o sistema host. Com Mac, essas opções não existem.

Outro argumento que sempre aparece: “mas um Mac Mini M4 ou Mac Studio com 128GB de memória unificada roda modelos grandes localmente, é o substituto do ChatGPT”. Já testei essa tese e escrevi um benchmark detalhado. A conclusão: hardware local caro pra rodar LLM é hobby de fim de semana, não é ferramenta de produção. Os modelos open source que cabem não entregam a qualidade que o Claude Opus entrega. Eu tenho um home server com AMD Strix Halo e 96 GB de RAM unificada, rodei modelos por dezenas de horas, e no meu fluxo real de programação eles servem pra tarefas simples. Pras tarefas complexas, Claude Opus. Antes de gastar os $4000 num Mac Studio com a justificativa de rodar modelos locais, faça o teste de verdade. Você provavelmente vai voltar a pagar Opus depois.

Por que Omarchy

Eu uso Omarchy no desktop há meses e documentei o caminho numa série de artigos. O Omarchy 2.0 tem instalador próprio com LUKS, Btrfs, Limine, snapper e SDDM já configurados. Escrevi sobre usar a ISO oficial, sobre as customizações de ZSH com atuin, starship, secrets bem organizados, sobre Mise pra múltiplas linguagens, sobre LazyVim e LazyExtras, sobre SSH e Yubikeys, sobre TUIs modernas. Também tem o Omarchy 3 com dual GPU AMD + NVIDIA e o Crush como agente de coding.

Pra quem não conhece: Omarchy é Arch Linux puro com uma camada de cosmética em cima do Hyprland/Wayland. Pré-configurado com defaults sãos. Eu podia montar tudo isso do zero, já fiz isso várias vezes na vida, mas por que refazer trabalho que alguém já fez bem feito? Instalo Omarchy, faço os tweaks que são meus em cima, e tenho Arch customizado numa fração do tempo.

Um ponto que eu levanto toda vez que recomendo Omarchy: a documentação é excelente. Tem um manual oficial que cobre desde instalação até customização de tema, keybindings, Hyprland, Waybar, tudo. Se você vem de Ubuntu ou Fedora e tem receio de Arch, esse manual resolve o grosso das dúvidas. Pra quem nunca tocou em Hyprland, abre ele e vai tangenciando. Não é um README jogado no GitHub, é manual de verdade, com capítulos e índice.

A história desse artigo começa num fio anterior. Eu migrei meu home server recentemente, trocando um servidor Ubuntu antigo por um Minisforum MS-S1 com openSUSE MicroOS configurado com Claude Code. Esse foi o primeiro experimento sério de deixar o Claude Code guiar uma migração de infra inteira, com containers, NFS, serviços, networking. Deu certo. E deixou no ar a ideia: por que não usar a mesma abordagem pra configurar um notebook novo?

Foi o que fiz. Peguei o Thinkpad, baixei a ISO do Omarchy mais recente, gravei num pendrive, instalei por cima do Windows. Do zero ao desktop funcional, menos de uma hora. Dali pra frente, tudo é tweaking, que eu fui documentando conforme fazia.

Vou detalhar as duas camadas de customização: o que precisa pra um notebook qualquer, e o que é específico desse Thinkpad.

Configs específicos de notebook

Um notebook tem problemas que um desktop não tem: bateria, suspensão, tampa, brilho, trackpad. Essas são as partes que Omarchy default não cobre do jeito que eu quero.

Power management com TLP

O default do Omarchy vem com power-profiles-daemon. Troquei por TLP, que dá controle granular de CPU scaling, thresholds de bateria e perfil dinâmico baseado em AC vs bateria.

sudo pacman -S tlp tlp-rdw
sudo systemctl mask power-profiles-daemon.service
sudo systemctl enable --now tlp.service

O mask é necessário porque o upower traz o power-profiles-daemon de volta se você só der disable.

Thresholds de carga: 60% pra começar, 85% pra parar. O notebook fica a maior parte do tempo plugado na mesa do escritório, e manter a bateria em 100% 24/7 detona a capacidade ao longo do tempo. Com 60/85, a bateria passa a maior parte do tempo na faixa saudável de lítio e ainda sobra capacidade útil decente.

Perfis: balanced com balance_power na bateria, performance no AC. O low-power do TLP era agressivo demais no Core Ultra 5 235U, a resposta de janela e terminal ficava perceptível. Balanced dá a melhor relação consumo/responsividade pra uso normal.

Tem uma pegadinha: tlp auto depois de tlp ac nem sempre reaplica o perfil de bateria. Criei um pequeno script ligado ao Super+Ctrl+P que lê o estado atual e chama tlp bat ou tlp ac explicitamente:

#!/bin/bash
set -euo pipefail

profile=$(cat /sys/firmware/acpi/platform_profile 2>/dev/null || echo unknown)
on_ac=$(cat /sys/class/power_supply/AC*/online 2>/dev/null | head -1 || echo 0)

if [[ "$profile" == "performance" ]]; then
  if [[ "$on_ac" == "1" ]]; then
    sudo /usr/bin/tlp auto >/dev/null
    label="Plugged in — back to AC auto"
  else
    sudo /usr/bin/tlp bat >/dev/null
    label="On battery — normal profile"
  fi
  notify-send -t 2000 "Performance mode: off" "$label" 2>/dev/null || true
else
  sudo /usr/bin/tlp ac >/dev/null
  notify-send -t 2000 "Performance mode: on" "Forcing AC profile" 2>/dev/null || true
fi

No waybar, um módulo custom custom/perf mostra o estado atual (󰓅 PERF, 󰌪 ECO, ou vazio pra balanced) e aceita clique pra alternar. O script de output é bem curto:

#!/bin/bash
p=$(cat /sys/firmware/acpi/platform_profile 2>/dev/null)
case "$p" in
  performance) printf '󰓅 PERF' ;;
  low-power)   printf '󰌪 ECO'  ;;
  balanced|"") printf ''       ;;
  *)           printf '%s' "$p" ;;
esac

Suspend, hibernate, e tampa

Isso aqui é o que mudou em relação aos notebooks que eu usava em 2015. O T14 Gen 6 fecha a tampa, suspende, e acorda quando você abre de novo. Sem bug, sem delay estranho, sem precisar dar login de novo no meio da sessão gráfica. O hyprlock pega depois do suspend, aceita digital ou senha, e volta pro desktop em segundos. Isso é o comportamento que a gente tem na Apple há anos e que no Linux era uma aventura. Em 2026, em hardware moderno com kernel 6.11+, simplesmente funciona.

Mem sleep mode é s2idle (sem deep sleep). Hibernação habilitada via swapfile Btrfs de ~30 GB e resume=/dev/mapper/root resume_offset=... no kernel cmdline do Limine. Raramente uso, mas está lá.

O hypridle tem timeouts agressivos pra notebook:

• 2.5 min → screensaver
• 5 min → lock
• 5.5 min → DPMS off + keyboard backlight off

Depois de trancado, passa mais 5 min e a tela apaga de vez. No unlock, restaura brilho de tela e de teclado pro nível anterior. Essas timings são muito mais curtas que as do desktop (20-40 min lá). A diferença de bateria ao longo do dia é mensurável.

Brilho e backlight de teclado

brightnessctl controla os dois. Fn+Space alterna o backlight do teclado em três níveis. Hypridle salva o nível atual antes de apagar e restaura no retorno. Comando que uso no script:

brightnessctl -sd '*::kbd_backlight' set 0    # salva e desliga
brightnessctl -rd '*::kbd_backlight'          # restaura

Touchpad

No hypr/input.conf:

touchpad {
    natural_scroll = true
    clickfinger_behavior = true
    disable_while_typing = true
    scroll_factor = 0.4
}
gesture = 3, horizontal, workspace

clickfinger_behavior troca o clique de 2 dedos como botão direito (mais confortável que acertar a zona inferior direita). disable_while_typing é palm rejection básico. Três dedos horizontais alternam workspaces, o gesto mais útil no Hyprland.

Configs específicos do Thinkpad

Aqui entra o que é particular desse modelo. Algumas coisas o Linux moderno já cobre sozinho, outras exigem configuração específica.

Sensor de digital

Goodix MOC 27c6:6594, funciona com libfprint 1.94.9+ em kernel 6.11+. Pacote é fprintd.

sudo pacman -S fprintd
fprintd-enroll                        # dedo indicador direito por default
fprintd-enroll -f left-index-finger   # outro dedo

Pro sudo aceitar digital, adiciono auth sufficient pam_fprintd.so acima da linha do pam_unix.so em /etc/pam.d/sudo. Com sufficient, se a digital passar, autentica direto. Se falhar ou se eu digitar ESC, cai pro prompt de senha. Isso vale a pena de verdade: dezenas de vezes por dia, sudo pacman -Syu ou sudo systemctl restart algo, e é só encostar o dedo.

No hyprlock, uso a configuração nativa do próprio hyprlock, não o PAM:

auth {
    fingerprint {
        enabled = true
        ready_message = Scan fingerprint or type password
        present_message = Scanning...
        retry_delay = 250
    }
}

A razão é que o caminho PAM dá prompt duplo. Configurado nativo, o hyprlock aceita digital ou senha, o que vier primeiro desbloqueia.

No SDDM (login inicial), deixei senha apenas. O motivo: a senha de login destrava o keyring do GNOME, e a digital não consegue fornecer plaintext pra isso. Depois que o keyring está destrancado, o hyprlock pode usar digital sem problema.

Na prática, o sudo fica assim. Encosta o dedo, autentica, segue.

Teclado brasileiro do Thinkpad

O teclado brasileiro do Thinkpad tem uma peculiaridade chata. A tecla /? fica na posição que seria o Ctrl direito (keycode 97), não na posição AB11 tradicional do ABNT2 (keycode 89). Se você usar o layout padrão br(abnt2), essa tecla fica inacessível. Literalmente não imprime nada.

A solução é o variant br(thinkpad) que existe em /usr/share/X11/xkb/symbols/br:

xkb_symbols "thinkpad" {
    include "br(abnt2)"
    name[Group1]="Portuguese (Brazil, IBM/Lenovo ThinkPad)";
    key <RCTL> { [ slash, question, degree, questiondown ] };
};

No hypr/input.conf:

kb_layout = br
kb_variant = thinkpad
kb_model = thinkpad60

E system-wide pra TTY/X11:

sudo localectl set-keymap br-abnt2
sudo localectl set-x11-keymap br thinkpad thinkpad60

Escrevi um pequeno Python que lê scancodes brutos de /dev/input/event* pra diagnosticar essas esquisitices. Útil quando uma tecla decide não funcionar e você precisa descobrir se é hardware, kernel, ou xkb.

Input method: fcitx5

Junto com o layout eu instalo fcitx5. Input method, pra quem não conhece, é a camada que transforma sequência de teclas em caracteres. É onde entram deadkeys (til pra nasalizar, acento agudo, circunflexo), composição de caracteres que não estão no teclado (ç, Ç, letras acentuadas em maiúscula), suporte a emoji. Em app Qt ou GTK, o input method também cuida dos menus de contexto pra cedilha e acentos.

Pacotes:

sudo pacman -S --needed fcitx5 fcitx5-configtool fcitx5-gtk fcitx5-qt

E as variáveis de ambiente pros toolkits encontrarem o fcitx5. Criei ~/.config/environment.d/fcitx.conf:

INPUT_METHOD=fcitx
QT_IM_MODULE=fcitx
XMODIFIERS=@im=fcitx
SDL_IM_MODULE=fcitx

O environment.d do systemd é carregado antes das sessões gráficas, então Brave, Alacritty, VS Code e qualquer GTK/Qt pegam automaticamente. Habilito autostart no Hyprland:

exec-once = fcitx5 -d

Digitando ~a vira ã, 'e vira é, ç funciona como deveria em toda aplicação. Num teclado Thinkpad brasileiro, isso é a diferença entre conseguir escrever em português com naturalidade ou ficar catando letra.

Áudio SOF

Codec Realtek ALC3306/ALC287 via Sound Open Firmware. Sem o sof-firmware, o módulo de kernel carrega mas o DSP nunca boota e o PipeWire cai silenciosamente pra auto_null. Resultado: você acha que o alto-falante está no mudo, mas na verdade o PipeWire não tem device nenhum.

sudo pacman -S --needed sof-firmware alsa-ucm-conf pipewire pipewire-pulse wireplumber

Se precisar forçar SOF em vez do HDA legacy:

echo "options snd-intel-dspcfg dsp_driver=3" | sudo tee /etc/modprobe.d/alsa.conf

Reload sem reboot:

sudo modprobe -r snd_sof_pci_intel_mtl
sudo modprobe snd_sof_pci_intel_mtl
systemctl --user restart wireplumber pipewire pipewire-pulse

Firmware updates pelo fwupd

fwupdmgr update funciona, mas com Limine tem uma pegadinha: o fwupd tenta escrever em /boot/EFI/systemd/ ou /boot/EFI/arch/, que não existem. O workaround:

sudo mkdir -p /boot/EFI/arch
sudo fwupdmgr update -y --no-reboot-check
fwupdmgr get-history  # deve mostrar "Success"

HiDPI / fractional scaling

Painel 14" em 1920x1200 numa resolução do Hyprland livre. O auto 1.5x do Omarchy ficava chunky demais. Fixei em 1.333x:

env = GDK_SCALE,1
monitor=,preferred,auto,1.3333,vrr,2

Efetivo 1440x900. GTK com GDK_SCALE=1 renderiza 1:1 com o Hyprland (não magnifica duplo). VRR mode 2 só em fullscreen, porque painéis LCD tendem a cintilar em conteúdo estático com VRR ativa.

Flags do Brave e Chromium pra renderizar bem nessa escala:

--ozone-platform=wayland
--enable-features=WaylandFractionalScaleV1,UseOzonePlatform,VaapiVideoDecoder,VaapiVideoEncoder
--enable-gpu-rasterization

O VAAPI faz diferença real na bateria em YouTube.

Tunando Omarchy pra ser meu

Omarchy vem com defaults bons. O que eu ajusto é no topo deles, sem tocar em ~/.local/share/omarchy/ (que é clobbered pelo omarchy-update). Toda customização fica em ~/.config/.

Infra: Btrfs, snapshots, Snapper

Omarchy já vem com Btrfs e subvolumes separados:

@home separado significa que ~/.cache, ~/.config/BraveSoftware, etc. não incham snapshots do root. Snapshot é de sistema, não de perfil.

Swap: zram de 4 GB com prioridade 100 (hit primeiro), mais swapfile de 30 GB com prioridade 0 (habilita hibernação, dimensionado pra RAM).

O stack de snapshot: Snapper tira snapshot antes e depois de cada pacman -Syu via snap-pac. limine-snapper-sync escreve esses snapshots no menu do Limine, então dá pra bootar num snapshot anterior pra reverter. Se algo quebra depois de update, você segura uma tecla no boot, escolhe o snapshot pré-update, boota read-only pra verificar, e se estiver bom, faz snapper rollback.

Omarchy deixa o snapper-cleanup.timer e o snapper-boot.timer desabilitados por default. Habilitei os dois e configurei retenção pra caber num SSD de 1 TB sem explodir:

TIMELINE_LIMIT_HOURLY=10
TIMELINE_LIMIT_DAILY=0
TIMELINE_LIMIT_WEEKLY=1
TIMELINE_LIMIT_MONTHLY=1
NUMBER_LIMIT=50

Um detalhe que custa debug pra quem esquece: Docker e Ollama escrevem gigabytes em /var/lib/docker e /var/lib/ollama. Se isso cai dentro de @, os snapshots catastrofizam. Cada imagem Docker ou modelo Ollama baixado triplica em tamanho. Criei subvolumes aninhados pros dois, com chattr +C pra desligar CoW:

sudo btrfs subvolume create /var/lib/docker
sudo chattr +C /var/lib/docker
sudo btrfs subvolume create /var/lib/ollama

Isso tem que ser feito ANTES de o Docker ou Ollama escrever dados. Se já tem dados lá, precisa migrar.

NFS pro NAS Synology

Meu Synology expõe três volumes. No desktop, monto normal. No notebook, tem que ser mais defensivo. O notebook anda, esquece a rede, conecta em WiFi público. Fstab do notebook:

nfs4  _netdev,noauto,nofail,x-systemd.automount,x-systemd.idle-timeout=10min,x-systemd.mount-timeout=15s,noatime,nodiratime,nconnect=4,actimeo=10,soft,timeo=30,retrans=2

Diferença crítica em relação ao desktop: soft com timeouts curtos (não fica pendurado pra sempre), x-systemd.idle-timeout=10min (auto-unmount quando ocioso), sem network-online.target no require (não atrasa boot). Resultado prático: cd /mnt/gigachad em casa monta lazy, fora de casa falha rápido sem trancar shell.

Outro detalhe importante: meu user no notebook tem UID 1026, que bate com a permissão do share no Synology. O Linux default cria user em 1000, o Synology impõe identidade via UID no fio. Se os UIDs não batem, você não consegue ler os arquivos, ou ainda pior, escreve como nobody. Rodei de TTY (com usuário deslogado) os usermod/groupmod pra remapear o user pra 1026/1026 e fiz chown -R em /home.

Hardening de WiFi público

Notebook vai sair de casa. Num aeroporto ou café, eu não quero anunciar hostname, não quero MAC rastreável, não quero serviço escutando porta aberta.

/etc/NetworkManager/conf.d/00-macrandomize.conf:

[device]
wifi.scan-rand-mac-address=yes

[connection]
wifi.cloned-mac-address=stable
ethernet.cloned-mac-address=stable
connection.stable-id=${CONNECTION}/${BOOT}

ipv6.ip6-privacy=2
ipv6.addr-gen-mode=stable-privacy

MAC aleatório por scan (anti-fingerprinting passivo). MAC clonado estável por SSID (o portal cativo não te re-pergunta login toda vez) mas diferente entre redes. IPv6 com endereços temporários e interface ID derivado de segredo estável, não do MAC (sem vazar EUI-64).

/etc/systemd/resolved.conf.d/hardening.conf:

[Resolve]
LLMNR=no
MulticastDNS=no

Mata broadcast de hostname em LLMNR e mDNS. Também desabilito avahi:

sudo systemctl disable --now avahi-daemon.service avahi-daemon.socket

UFW firewall:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw --force enable

SSH server já é off por default no Omarchy. Nada escutando. Mesmo que o firewall vaze, não tem superfície.

Tudo isso entra num único ritual de setup inicial.

Persistência de SSH agent (keyring + keychain)

Se você usa SSH sério, quer digitar a passphrase uma vez por boot e ter ssh, git push, scp mudos pelo resto do dia. No Arch atual isso tem uma pegadinha: o gnome-keyring 50 deixou de oferecer componente SSH, e o substituto (gcr-ssh-agent) é um agente plain em memória, sem persistência de passphrase. A caixa “lembrar esta chave” que você viu em guias antigos simplesmente não existe mais.

A combinação que funciona tem três peças:

1. gcr-ssh-agent.socket gerenciado pelo systemd serve o SSH_AUTH_SOCK em $XDG_RUNTIME_DIR/gcr/ssh
2. pam_gnome_keyring no login SDDM destrava o keyring com a senha de login (usado por apps GUI tipo Brave, não pelo SSH)
3. keychain (wrapper) mantém um ssh-agent vivo entre logouts, sobrescreve o SSH_AUTH_SOCK pra apontar pra esse agent persistente, e cacheia o PID em ~/.keychain/<host>-sh

Primeiro, instalo o keyring:

sudo pacman -S --needed gnome-keyring seahorse keychain

Depois, edito /etc/pam.d/sddm pra o login password destravar o keyring automaticamente. Adiciono no topo:

-auth      optional    pam_gnome_keyring.so

E no final:

-session   optional    pam_gnome_keyring.so    auto_start

O hífen na frente (-auth, -session) marca como opcional, se o módulo não carregar, não quebra login.

Pino o SSH_AUTH_SOCK pra sessões gráficas e TTY via ~/.config/environment.d/ssh-agent.conf:

SSH_AUTH_SOCK=%t/gcr/ssh

O %t resolve pra $XDG_RUNTIME_DIR, tipo /run/user/1026. Habilito o socket do gcr e o linger do usuário (pra user daemons sobreviverem ao logout):

systemctl --user enable --now gcr-ssh-agent.socket
sudo loginctl enable-linger $USER

Por fim, no ~/.config/bash/init.sh o keychain inicia ou reusa o agent:

if command -v keychain &>/dev/null && [[ -r ~/.ssh/id_ed25519 ]]; then
  eval "$(keychain --eval --quiet ~/.ssh/id_ed25519)"
fi

--eval emite atribuições shell (SSH_AUTH_SOCK, SSH_AGENT_PID) apontando pro agent do keychain, que passa por cima do gcr setado pelo environment.d. --quiet cala o banner depois que a chave está carregada.

Fluxo na prática: boot → primeiro terminal → keychain pede passphrase uma vez → chave fica carregada. Logout → login de novo → novos shells re-atacham no mesmo agent (via ~/.keychain/<host>-sh) → zero prompt. ssh-add -l confirma que a chave está lá, echo $SSH_AUTH_SOCK confirma que está no caminho do keychain.

Quando você vai digitar a passphrase de novo: reboot, ssh-add -D, ou keychain --clear. Em uso normal, uma vez por dia.

Bash em vez de ZSH

No desktop uso ZSH. No notebook fui de Bash pra alinhar com o default do Omarchy, sem dupla de camadas modulares pra manter. ~/.bashrc é um symlink pra ~/.config/bash/bashrc, que faz source dos defaults do Omarchy primeiro e depois empilha as minhas customizações:

source ~/.local/share/omarchy/default/bash/rc
source ~/.config/bash/envs.sh
source ~/.config/bash/aliases.sh
source ~/.config/bash/mounts.sh
source ~/.config/bash/init.sh
source ~/.config/bash/secrets    # gitignored, chmod 600

envs.sh tem o que é meu: OpenRouter base URL, Ollama apontando pro GPU box da rede local (192.168.0.14), AWS region, analytics do Hugo, configs de zoxide e SSH agent. aliases.sh tem os atalhos de TLP, um alias pra shell-gpt via Docker, e functions pra hardenar o PATH quando rodo makepkg ou yay (prevenir injeção de binário via user config malicioso).

init.sh faz o trabalho de integração. Atuin com bind manual do Ctrl-R (pra deixar a seta pra cima com o history-search padrão do bash, que eu uso mais). Keychain carregando ~/.ssh/id_ed25519 uma vez por boot e reusando nos shells seguintes (sem ter que re-autenticar SSH toda hora). Blesh se estiver instalado (autosuggestion estilo ZSH pra Bash). E uma função que manda o PROMPT_COMMAND ajustar o título da janela com o pwd atual e o comando em execução:

__title_idle() { printf '\033]2;%s\007' "${PWD/#$HOME/~}"; }
__title_busy() {
  local cmd="${BASH_COMMAND}"
  [[ "$cmd" == "__title_"* || "$cmd" == *"PROMPT_COMMAND"* ]] && return
  printf '\033]2;%s — %s\007' "${PWD/#$HOME/~}" "$cmd"
}
if [[ -n "${PROMPT_COMMAND-}" ]]; then
  PROMPT_COMMAND="__title_idle; ${PROMPT_COMMAND}"
else
  PROMPT_COMMAND="__title_idle"
fi
trap '__title_busy' DEBUG

No idle, título mostra só o pwd. Com um comando rodando, trap DEBUG pega o BASH_COMMAND em execução e atualiza o título. Integra com o hyprland/window do waybar pra mostrar tudo lá.

Pro toolbelt Rust moderno, a lista:

sudo pacman -S --needed \
  eza bat fd ripgrep sd git-delta dust procs bottom duf tokei hyperfine \
  zoxide atuin tldr starship

eza substitui ls. bat substitui cat com syntax highlight. fd substitui find. ripgrep substitui grep. sd substitui sed. delta pluga no git pra diff side-by-side colorido. dust pro du visual. procs pro ps. btm (bottom) pro top. duf pro df. tokei conta linhas de código. hyperfine pra benchmark de comando. zoxide é cd com memória (muito útil). atuin é history do shell com sync criptografado (aponto pro meu home server via sync_address = "http://192.168.0.90:8888"). starship é o prompt. tldr é man page em 10 linhas.

O atuin key tem que ser backupeado offline. Se você perde, perde o histórico criptografado. Salvei no meu Bitwarden self-hosted (Vaultwarden), que eu documentei no artigo sobre Bitwarden self-hosted.

O git passa diff pelo delta:

[core]        pager = delta
[interactive] diffFilter = delta --color-only
[delta]       navigate side-by-side line-numbers hyperlinks, light=false
[merge]       conflictstyle = zdiff3

Hyprland e Waybar

Customizações visuais e de UX que fiz em cima do default.

No hypr/looknfeel.conf, gaps menores (2/5 vs 5/10 do default), animação de slide entre workspaces, VFR ligado (reduz consumo quando a tela está estática), allow_session_lock_restore (se o hyprlock crasha, volta pra tela de lock em vez de jogar pro desktop).

No hypr/bindings.conf:

No Waybar, três módulos custom que recomendo:

Título de janela: o módulo hyprland/window mostra o que tá focado. No bash, o PROMPT_COMMAND atualiza o título pra algo como “~/Projects/blog — hugo server”. Então no waybar aparece o diretório e o comando em execução, sem eu precisar olhar pro terminal.

"hyprland/window": {
    "format": "{title}",
    "max-length": 50,
    "rewrite": { "(.{47}).+": "$1…" }
}

Perf mode: o custom/perf executa um script que lê o estado do TLP e mostra um ícone:

"custom/perf": {
    "exec": "~/.config/scripts/perf-waybar.sh",
    "interval": 3,
    "format": "{}",
    "on-click": "~/.config/scripts/perf-toggle.sh"
}

Vazio em balanced, 󰓅 PERF em performance, 󰌪 ECO em low-power. Clique alterna. Útil pra ver rapidamente em que modo a máquina está.

Claudebar: integrei o claudebar num módulo custom que mostra a % de uso da sessão do Claude Code e o gasto extra inline no waybar. Sem ter que abrir outra janela.

O clock:

"clock": {
    "format": "{:L%A %d %B - %H:%M}",
    "format-alt": "{:L%A W%V %Y - %H:%M}"
}

Exibe “quinta 17 abril - 14:32” por padrão, clique alterna pra “quinta W16 2026 - 14:32” com número da semana do ano, útil pra planejar artigos e tarefas.

Atuin self-hosted

Atuin roda no meu home server em 192.168.0.90:8888. Criei uma conta separada pro notebook (akitaonrails-thinkpad), não misturo histórico com desktop de propósito. atuin sync roda a cada 5 minutos e todo histórico é criptografado antes de ir pro server. O server não vê os comandos, só vê bytes criptografados.

Conclusão: escolhendo notebook pra Linux

Se tem uma coisa que eu aprendi nessa jornada: escolher notebook pra rodar Linux confortavelmente não é trivial. Precisa checar a ArchWiki pelo modelo específico antes de comprar. A do T14s Gen 6 AMD, por exemplo, cataloga cada peculiaridade de hardware e como contornar. Sem essa referência, você descobre os problemas instalando.

Regra que sigo: nunca comprar modelo recém-lançado. Deixar passar uns 6 a 12 meses depois do lançamento. Isso dá tempo pra comunidade iron out os bugs, pros drivers entrarem no mainline, pra ArchWiki ter uma página decente, pra libfprint incluir o sensor de digital, pro kernel cobrir o WiFi e a câmera IR. Comprar de primeira é assumir o papel de tester beta.

Marcas com trilha Linux decente: Lenovo (especialmente Thinkpad, eles oferecem Ubuntu e Fedora pré-instalados), Dell (a linha XPS e Latitude), Asus (Zenbook e ROG têm suporte razoável), Framework (fábrica direto pra Linux). Mac qualquer geração recente é cortado do Linux mainline ou via Asahi com caveats.

O Thinkpad T14 Gen 6 não é o notebook mais bonito que eu podia ter comprado. Mas é rugged, tem as portas certas, o sensor de digital funciona, e a carcaça plástica aceita cair, arranhar, viajar na mala sem eu ficar nervoso. Pra servir de companion de debug remoto, é o que eu precisava. Se esse é o seu perfil de uso também, recomendo. Se você quer OLED e metal, vai de Zenbook ou de T14s. Cada premium tem seu compromisso, nenhum notebook Linux em 2026 é perfeito.

Tudo que descrevi aqui ficou versionado num repo privado meu. Se eu precisar reinstalar amanhã, rodo meia dúzia de passos em ordem e volto ao mesmo lugar. Esse é o ponto todo de manter configuração em Git: notebook é commodity, config é minha.

Hyprland não funciona bem com NVIDIA

Dá pra usar. Mas tem vários probleminhas, em particular com Hyprlock, em particular com DPMS onde eu deixo meu computador em idle, daí ele se bloqueia, e depois de um timeout desliga os monitores pra economizar energia, não ter burn in, etc.

Quando eu tento acordar do sleep, o Hyprlock crasheou e eu preciso ir pra outro TTY pra reiniciar, até fiz um script ~/.local/bin/hypr_unlock.sh assim:

hyprctl --instance 0 'keyword misc:allow_session_lock_restore 1'
hyprctl --instance 0 'dispatch exec hyprlock'

Mas aí desbloqueia e eu vejo que meu Brave crasheou também. A nvidia realmente não gosta que desliguem o monitor enquanto ele tá ativo. Disseram que isso acontecia no Hyprlock 0.9.1 mas eu já estou no 0.9.2 e continua crasheando. Tentei habilitar serviços como nvidia-suspend/resume/hibernate mas nada também.

No fim do dia resolvi que não vale a pena brigar com isso: eu tenho uma AMD 7850X3D e essa CPU tem uma iGPU (GPU integrada), uma AMD Raphael, que pra coisas como renderizar um gerenciador de janelas, é mais do que potente o suficiente.

Primeiro, detectar as GPUs:

❯ ls /dev/dri/by-path
Permissions Size User Date Modified Name
lrwxrwxrwx     - root 21 Jan 15:22   pci-0000:01:00.0-card -> ../card1
lrwxrwxrwx     - root 21 Jan 15:22   pci-0000:01:00.0-render -> ../renderD128
lrwxrwxrwx     - root 21 Jan 15:22   pci-0000:1a:00.0-card -> ../card2
lrwxrwxrwx     - root 21 Jan 15:22   pci-0000:1a:00.0-render -> ../renderD129

Pra saber qual é AMD e qual é NVIDIA só executar:

❯ lspci | grep -i vga
01:00.0 VGA compatible controller: NVIDIA Corporation GB202 [GeForce RTX 5090] (rev a1)
1a:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Raphael (rev c9)

Pronto, pelo ID de PCI sabemos que card1 é NVIDIA e card2 é AMD. Agora precisa configurar meu ~/.config/hypr/hyprland.conf:

....
# NVIDIA environment variables
env = NVD_BACKEND,direct
#env = LIBVA_DRIVER_NAME,nvidia
env = LIBVA_DRIVER_NAME,radeonsi
#env = __GLX_VENDOR_LIBRARY_NAME,nvidia

# Comment these out when using AMD as primary
#env = __NV_PRIME_RENDER_OFFLOAD,1
#env = __VK_LAYER_NV_optimus,NVIDIA_only

# card1=nvidia, card2=amdgpu (verify with: cat /sys/class/drm/card*/device/uevent)
# AMD first for iGPU primary:
env = AQ_DRM_DEVICES,/dev/dri/card2:/dev/dri/card1

env = ELECTRON_OZONE_PLATFORM_HINT,auto

Eu deixei as configurações específicas de NVIDIA comentadas, nenhuma delas pode estar ativa. Mas a linha mais importante é a do AQ_DRM_DEVICES que lista a ordem pro Hyprland pegar a GPU. Card2/AMD tem que estar primeiro. E pronto, só rebootar e recolocar os cabos HDMI na saída da iGPU.

Com isso eu posso escolher agora dar offload de somente alguns apps da NVIDIA usando Prime. Pra isso primeiro eu criei os script ~/.local/bin/nvidia-load.sh:

#!/bin/bash
__NV_PRIME_RENDER_OFFLOAD=1 __VK_LAYER_NV_optimus=NVIDIA_only __GLX_VENDOR_LIBRARY_NAME=nvidia "$@"

Finalmente, configurei alguns bindings em ~/.config/hypr/bindings.conf:

...
bindd = SUPER SHIFT, B, Blender, exec, ~/.local/bin/nvidia-load.sh blender
bindd = SUPER SHIFT, L, Bambu Studio, exec, ~/.local/bin/nvidia-load.sh bambu-studio
bindd = SUPER SHIFT, P, Blender, exec, ~/.local/bin/nvidia-load.sh plasticity
...

Desta forma, somente os apps Blender, Plasticity e Bambu Studio, que vão primariamente usar a NVIDIA pra renderizar 3D em real time. Todos os outros apps vão abrir na iGPU AMD.

Ferramentas de IA como ComfyUI, Ollama ou LM Studio automaticamente reconhecem a NVIDIA e escolhem lá. E com isso eu também tenho mais VRAM livre pra carregar LLMs.

Se for usar XLibre/X.org, dá pra ficar de boa em NVIDIA. Mas se for usar Wayland, nvidia ainda não é totalmente estável, em particular com Hyprland. Dá menos dor de cabeça colocar uma segunda GPU AMD só pra isso.

O problema é que pra serem eficientes, essas ferramentas precisam ter acesso ao seu sistema de arquivos pra vasculhar os arquivos do seu projeto, pra analizar o código. E mais: conseguir rodar ferramentas como compiladores, linters, e coisas mundanas como grep, sed, awk, ls, e outros comandos do seu sistema.

Eventualmente, uma LLM pode mandar executar um rm -Rf / aleatório e apagar coisas no seu sistema, por exemplo. O código em si, se por acidente apagar o que não devia, teoricamente você deveria estar seguro porque seu código já deveria estar, no mínimo, num repositório de Git (GitHub, GitLab, etc), então seria só reverter a mudança. Mas se o agente rodar um rm fora do diretório do seu projeto, pode criar todo tipo de problema.

Não é comum isso acontecer e todas as ferramentas costumam ter checagens pra isso, incluindo perguntar se você quer realmente executar o comando. Ao mesmo tempo, eles também tem a opção de permitir rodar qualquer comando durante a sessão, sem perguntar - porque uma hora começa a ficar tedioso dar “ok” pra cada comando individual. Todo mundo acaba ficando com preguiça e diz “foda-se, roda o que quiser”.

E vocês devem estar pensando “ah, minha ferramenta X é bem comportada, ele sempre pergunta antes de rodar qualquer coisa, então eu controlo”. Não esqueçam: ATAQUES DE SUPPLY-CHAIN existem. Toda hora alguma biblioteca open source é invadida com malware e os programas que usam essas libs acabam sendo infectados sem saber. Isso já aconteceu várias vezes, em várias libs de NPM por exemplo. Não tem como garantir que mesmo um software open source seja confiável. Sempre parta do princípio que tudo é inseguro até prova em contrário e trate esses programas dessa forma: com restrição máxima.

Pra garantir que esses agentes realmente não vão fazer nada fora do diretório do projeto, o melhor é criar um JAIL. E aqui vai o comando pra isso:

bwrap --ro-bind /usr /usr \
      --ro-bind /bin /bin \
      --ro-bind /lib /lib \
      --ro-bind /lib64 /lib64 \
      --dev /dev \
      --proc /proc \
      --bind $(pwd) $(pwd) \
      --chdir $(pwd) \
      --unshare-all \
      --share-net \
      bash

bwrap é o Bubblewrap um dos componentes que permitem a existência de coisas como Flatpak. Ele cria um sandbox. O Bash que vai rodar ao executar o comando acima está essencialmente em “jail”, ou seja, “preso”. Nele damos acesso somente de leitura a alguns diretórios do sistema caso precise de bibliotecas e ferramentas. Pra isso serve o --ro-bind.

Mas somente o diretório corrente pwd vai ter permissão de escrita. Qualquer comando que rodar dentro desse jail não tem permissão de escrever em nenhum outro lugar o seu sistema. Veja o exemplo na foto abaixo onde eu tento apagar um arquivo na minha $HOME:

Ele não consegue nem listar os arquivos na minha home. É tudo invisível dentro do sandbox. Essa é uma das vantagens de apps rodando com Flatpak: eles são muito mais isolados do que apps instalados direto.

Dentro desse bash em sandbox podemos agora executar opencode, crush, cursor ou qualquer outro agente e ter certeza que eles não vão fazer nenhuma besteira no seu sistema.

Pra facilitar, recomendo criar um script como ~/.local/bin/ai-jail:

#!/bin/bash

# ai-jail — bubblewrap sandbox for AI coding agents
# Mounts the project dir read-write, auto-discovers home dotfiles with a
# deny-list for sensitive dirs, and isolates namespaces.
#
# Usage: ai-jail [--map PATH]... COMMAND [ARGS...]
#        ai-jail claude
#        ai-jail bash

PROJECT_DIR=$(pwd)
TEMP_HOSTS=$(mktemp /tmp/bwrap-hosts.XXXXXX)

trap 'rm -f "$TEMP_HOSTS"' EXIT

# ── Mise discovery ─────────────────────────────────────────────
REAL_MISE_BIN=$(type -p mise 2>/dev/null || echo "")

# ── Localhost fix (Go resolver needs /etc/hosts) ───────────────
printf '127.0.0.1 localhost ai-sandbox\n::1       localhost ai-sandbox\n' > "$TEMP_HOSTS"

# ── Parse --map / --rw-map arguments ─────────────────────────
EXTRA_MOUNTS=()
while [[ "${1:-}" == --map || "${1:-}" == --rw-map ]]; do
    FLAG="$1"
    MAP_PATH="$2"
    if [ -e "$MAP_PATH" ]; then
        if [[ "$FLAG" == "--rw-map" ]]; then
            EXTRA_MOUNTS+=("--bind" "$MAP_PATH" "$MAP_PATH")
        else
            EXTRA_MOUNTS+=("--ro-bind" "$MAP_PATH" "$MAP_PATH")
        fi
    else
        echo "Warning: Path $MAP_PATH not found, skipping." >&2
    fi
    shift 2
done

# ── Mise init command ──────────────────────────────────────────
if [ -n "$REAL_MISE_BIN" ]; then
    MISE_INIT="$REAL_MISE_BIN trust && eval \"\$($REAL_MISE_BIN activate bash)\" && eval \"\$($REAL_MISE_BIN env)\""
else
    MISE_INIT="true"
fi

# ── Dotfile deny-list (never mounted — sensitive data) ─────────
DOTDIR_DENY=(.gnupg .aws .mozilla .basilisk-dev .sparrow)

# Subdirs of ~/.config to hide (tmpfs over rw config mount)
CONFIG_DENY=(BraveSoftware Bitwarden)

# Subdirs of ~/.cache to hide (sensitive browser/app caches)
CACHE_DENY=(BraveSoftware basilisk-dev chromium spotify nvidia mesa_shader_cache)

# Dotdirs requiring read-write access
DOTDIR_RW=(.claude .crush .codex .aider .config .cargo .cache .docker)

# ── Helper functions ───────────────────────────────────────────
is_denied() {
    local name="$1"
    for d in "${DOTDIR_DENY[@]}"; do [[ "$name" == "$d" ]] && return 0; done
    return 1
}

is_rw() {
    local name="$1"
    for d in "${DOTDIR_RW[@]}"; do [[ "$name" == "$d" ]] && return 0; done
    return 1
}

# ── Auto-discover dot-directories in $HOME ─────────────────────
# Only directories — regular dotfiles (e.g. .claude.json) are NOT mounted.
# The tmpfs $HOME is writable so tools can create dotfiles as needed.
DOTFILE_MOUNTS=()
for entry in "$HOME"/.*; do
    [ -d "$entry" ] || continue
    name=$(basename "$entry")
    [[ "$name" == "." || "$name" == ".." ]] && continue
    is_denied "$name" && continue

    if is_rw "$name"; then
        DOTFILE_MOUNTS+=("--bind" "$entry" "$HOME/$name")
    else
        DOTFILE_MOUNTS+=("--ro-bind" "$entry" "$HOME/$name")
    fi
done

# ── Explicit dotfile mounts (regular files) ────────────────────
[ -f "$HOME/.gitconfig" ] && DOTFILE_MOUNTS+=("--ro-bind" "$HOME/.gitconfig" "$HOME/.gitconfig")
[ -f "$HOME/.claude.json" ] && DOTFILE_MOUNTS+=("--bind" "$HOME/.claude.json" "$HOME/.claude.json")

# ── Hide sensitive subdirs inside ~/.config (after rw mount) ───
CONFIG_HIDE_MOUNTS=()
for denied in "${CONFIG_DENY[@]}"; do
    [ -d "$HOME/.config/$denied" ] && CONFIG_HIDE_MOUNTS+=("--tmpfs" "$HOME/.config/$denied")
done

# ── Hide sensitive subdirs inside ~/.cache (after rw mount) ──
CACHE_HIDE_MOUNTS=()
for denied in "${CACHE_DENY[@]}"; do
    [ -d "$HOME/.cache/$denied" ] && CACHE_HIDE_MOUNTS+=("--tmpfs" "$HOME/.cache/$denied")
done

# ── Override ~/.local subdirs as rw (parent .local is ro) ──────
LOCAL_OVERRIDES=()
[ -d "$HOME/.local/state" ] && LOCAL_OVERRIDES+=("--bind" "$HOME/.local/state" "$HOME/.local/state")
for rw_share in zoxide crush opencode atuin mise yarn flutter kotlin NuGet pipx ruby-advisory-db uv; do
    [ -d "$HOME/.local/share/$rw_share" ] && LOCAL_OVERRIDES+=("--bind" "$HOME/.local/share/$rw_share" "$HOME/.local/share/$rw_share")
done

# ── GPU device mounts (NVIDIA + DRM) ─────────────────────────
GPU_MOUNTS=()
for dev in /dev/nvidia* /dev/dri; do
    [ -e "$dev" ] && GPU_MOUNTS+=("--dev-bind" "$dev" "$dev")
done

# ── Docker socket ────────────────────────────────────────────
DOCKER_MOUNT=()
[ -S /var/run/docker.sock ] && DOCKER_MOUNT+=("--bind" "/var/run/docker.sock" "/var/run/docker.sock")

# ── Shared memory (Chromium needs large /dev/shm) ───────────
SHM_MOUNT=()
[ -d /dev/shm ] && SHM_MOUNT+=("--dev-bind" "/dev/shm" "/dev/shm")

# ── Display passthrough (X11 + Wayland) ─────────────────────
DISPLAY_MOUNTS=()
DISPLAY_ENV=()

# X11 / XWayland socket
[ -d /tmp/.X11-unix ] && DISPLAY_MOUNTS+=("--bind" "/tmp/.X11-unix" "/tmp/.X11-unix")
[ -n "${DISPLAY:-}" ] && DISPLAY_ENV+=("--setenv" "DISPLAY" "$DISPLAY")
[ -n "${XAUTHORITY:-}" ] && {
    DISPLAY_MOUNTS+=("--ro-bind" "$XAUTHORITY" "$XAUTHORITY")
    DISPLAY_ENV+=("--setenv" "XAUTHORITY" "$XAUTHORITY")
}

# Wayland socket (lives in XDG_RUNTIME_DIR, typically /run/user/UID)
if [ -n "${XDG_RUNTIME_DIR:-}" ] && [ -d "$XDG_RUNTIME_DIR" ]; then
    DISPLAY_MOUNTS+=("--bind" "$XDG_RUNTIME_DIR" "$XDG_RUNTIME_DIR")
    DISPLAY_ENV+=("--setenv" "XDG_RUNTIME_DIR" "$XDG_RUNTIME_DIR")
    [ -n "${WAYLAND_DISPLAY:-}" ] && DISPLAY_ENV+=("--setenv" "WAYLAND_DISPLAY" "$WAYLAND_DISPLAY")
fi

# ── Assemble and launch ───────────────────────────────────────
echo "Jail Active: $PROJECT_DIR"

bwrap \
  --ro-bind /usr /usr \
  --symlink usr/bin /bin \
  --symlink usr/lib /lib \
  --symlink usr/lib /lib64 \
  --ro-bind /etc /etc \
  --ro-bind "$TEMP_HOSTS" /etc/hosts \
  --ro-bind /opt /opt \
  --ro-bind /sys /sys \
  --dev /dev \
  "${GPU_MOUNTS[@]}" \
  "${SHM_MOUNT[@]}" \
  --proc /proc \
  --tmpfs /tmp \
  --tmpfs /run \
  "${DOCKER_MOUNT[@]}" \
  "${DISPLAY_MOUNTS[@]}" \
  --tmpfs "$HOME" \
  "${DOTFILE_MOUNTS[@]}" \
  "${CONFIG_HIDE_MOUNTS[@]}" \
  "${CACHE_HIDE_MOUNTS[@]}" \
  "${LOCAL_OVERRIDES[@]}" \
  "${EXTRA_MOUNTS[@]}" \
  --bind "$PROJECT_DIR" "$PROJECT_DIR" \
  --chdir "$PROJECT_DIR" \
  --die-with-parent \
  --unshare-pid \
  --unshare-uts \
  --unshare-ipc \
  --hostname "ai-sandbox" \
  "${DISPLAY_ENV[@]}" \
  --setenv PS1 "(jail) \w \$ " \
  --setenv _ZO_DOCTOR 0 \
  bash -c "$MISE_INIT && ${*:-bash}"

Esta versão é bem customizada, deem uma boa lida porque tem deny-list pra que só diretórios de que você realmente precisa dentro do Jail estejam disponíveis. Alguns são read-write porque um Claude precisa conseguir escrever em ~/.claude ou Codex precisa do ~/.codex; vários diretórios nunca devem ir pra dentro do Jail como repositório de senhas de um Brave ou BitWarden. O resto de que pode precisar deve ser tudo read-only. Esse script cuida de tudo isso.

Só fazer chmod +x ~/.local/bin/ai-jail. Agora podemos executar ele direto ou já passar o comando que queremos rodar no sandbox:

~/.local/bin/ai-jail crush

Nesta versão ele vai criar um diretório $HOME temporário, caso ele precise gravar algo temporário lá. E também mandei mapear o seu ~/.config pros agentes terem acesso às suas configurações. Se precisar de mais coisas como variáveis de ambiente e coisas assim, modifique pra mapear essas coisas também, mas isso é o mínimo pra conseguir montar um sandbox seguro.

Tome muito cuidado com programas que rodam comandos aleatórios no seu sistema. Nada é 100% seguro, especialmente uma LLM que pode halucinar a qualquer momento e decidir apagar coisas, ou ferramentas suspeitas que você baixou sem ter certeza da origem e pode ser um malware disfarçado. Sempre rode coisas realmente suspeitas somente numa VM ou, no mínimo, dentro de um jail como esse.

Isso não serve só pra agentes de IA, lógico. Toda vez que for rodar qualquer comando que tem dúvidas ou ache suspeito, rode dentro desse jail.

De bônus, note que eu também mapeio o Mise pra dentro do container. Se você usa Omarchy, deve estar usando Mise também.

Especificamente pra Claude Code, que eu mais uso, prefiro não deixar tudo autorizado no modo automático --allow-dangerously-skip-permissions, mas também não gosto de ter que ficar autorizando coisa besta como cada domínio que ele quer pesquisar na web (só pesquisar não tem problema nenhum) ou qualquer comando que só lista coisas como ls ou grep então dá pra melhorar configurando direto em ~/.claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(git add *)",
      "Bash(git commit *)",
      "Bash(git status *)",
      "Bash(git diff *)",
      "Bash(git log *)",
      "Bash(git branch *)",
      "Bash(git checkout *)",
      "Bash(git switch *)",
      "Bash(git stash *)",
      "Bash(git show *)",
      "Bash(git fetch *)",
      "Bash(git pull *)",
      "Bash(git merge *)",
      "Bash(git tag *)",
      "Bash(git remote -v*)",
      "Bash(git rev-parse *)",
      "Bash(git ls-files *)",
      "Bash(ls *)",
      "Bash(find *)",
      "Bash(grep *)",
      "Bash(wc *)",
      "Bash(cat *)",
      "Bash(head *)",
      "Bash(tail *)",
      "Bash(file *)",
      "Bash(which *)",
      "Bash(echo *)",
      "Bash(pwd)",
      "Bash(cd *)",
      "Bash(ps *)",
      "Bash(env *)",
      "Bash(printenv *)",
      "Bash(mkdir *)",
      "Bash(cp *)",
      "Bash(mv *)",
      "Bash(touch *)",
      "Bash(npm *)",
      "Bash(npx *)",
      "Bash(yarn *)",
      "Bash(pnpm *)",
      "Bash(bun *)",
      "Bash(node *)",
      "Bash(ruby *)",
      "Bash(bundle *)",
      "Bash(rails *)",
      "Bash(rake *)",
      "Bash(go *)",
      "Bash(cargo *)",
      "Bash(rustc *)",
      "Bash(python *)",
      "Bash(pip *)",
      "Bash(docker compose *)",
      "Bash(docker ps *)",
      "Bash(docker logs *)",
      "Bash(docker images *)",
      "Bash(make *)",
      "Bash(gh *)",
      "Bash(curl *)",
      "Bash(jq *)",
      "Bash(sed *)",
      "Bash(awk *)",
      "Bash(sort *)",
      "Bash(uniq *)",
      "Bash(diff *)",
      "Bash(* --version)",
      "Bash(* --help)",
      "WebSearch",
      "WebFetch"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(rm -r *)",
      "Bash(sudo *)",
      "Bash(chmod 777 *)",
      "Bash(git reset --hard *)",
      "Bash(git clean *)",
      "Bash(git push --force *)",
      "Bash(git push -f *)",
      "Bash(docker rm *)",
      "Bash(docker rmi *)",
      "Bash(docker system prune *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(git rebase *)",
      "Bash(git branch -D *)",
      "Bash(git branch -d *)",
      "Bash(rm *)",
      "Bash(kamal *)",
      "Bash(docker run *)",
      "Bash(docker exec *)",
      "Bash(docker stop *)"
    ],
    "defaultMode": "acceptEdits"
  },
  "enabledPlugins": {
    "gopls-lsp@claude-plugins-official": true,
    "typescript-lsp@claude-plugins-official": true,
    "pyright-lsp@claude-plugins-official": true,
    "rust-analyzer-lsp@claude-plugins-official": true,
    "github@claude-plugins-official": true,
    "pr-review-toolkit@claude-plugins-official": true,
    "frontend-design@claude-plugins-official": true
  },
  "alwaysThinkingEnabled": true
}

Pesquise a documentação (ou pergunte direto pro próprio Claude) sobre mais customizações que dá pra fazer nesse arquivo pra servir melhor pro seu tipo de projeto de fluxo de trabalho.

É basicamente assim que um container de Docker ou Podman funciona também. Eu expliquei isso no meu video sobre Docker. Se não assistiu ainda, recomendo ver.

Introdução

Quando eu me afasto do meu PC, o Hyprland vai usar as configurações em ~/.config/hypr/hypridle.conf pra saber em que timeout desligar o monitor e depois, quando colocar meu PC pra dormir (sleep). Podemos configurar o tempo que quisermos lá, como 10 min pra apagar a tela, 20 min sem atividade pra dormir.

Se tiver algum app que queira fazer alguma manutenção em background que demore mais que isso pra terminar, ele pode sinalizar pro sistema não dormir. Dá pra ver quais apps fazem isso usando o comando systemd-inhibit --list:

O Problema

Vira e mexe eu deixo copiando grandes quantidades de arquivos, por exemplo, do meu NAS pra um micro SD Card. Pode levar mais de 1 hora fácil (minhas cópias de ROMs pra emuladores):

O problema é que antes disso o hypridle vai entrar em ação e colocar meu PC pra dormir, pausando essa cópia. E normalmente eu queria deixar copiando, ir dormir, e estar pronto quando acordar. Só que sempre esqueço disso e quando acordo ainda não terminou. Bem inconveniente. Não sei porque o Nautilus já não sinaliza pra inibir sleep quando tem atividades assim acontecendo.

Pode ser que tenha alguma configuração de gsettings que eu não saiba? (se tiver algo assim, não deixem de mandar nos comentários).

A Solução

Enquanto não descubro algo melhor, só tem uma solução: ficar fazendo polling de iostat pra manualmente inibir.

Pra começar precisamos instalar estes dois pacotes no Arch:

sudo pacman -S sysstat bc

Agora, criar um script que cheque, vamos chamar de ~/.local/bin/io_inhibit.sh:

#!/bin/bash

# --- Configuration ---
# UTIL_THRESHOLD: Percentage of time the device is busy (%util) that must be exceeded to inhibit sleep.
# 10.0% is a safe low threshold to catch any continuous I/O.
UTIL_THRESHOLD=10.0

# CHECK_INTERVAL: How often (in seconds) to check I/O activity.
CHECK_INTERVAL=5

# File to track the PID of the systemd-inhibit process.
PID_FILE="/tmp/io_inhibit_pid"

# --- Functions ---

# Function to check if the inhibit process is currently running
is_inhibitor_running() {
    if [ -f "$PID_FILE" ] && kill -0 $(cat "$PID_FILE") 2>/dev/null; then
        return 0 # True
    else
        return 1 # False
    fi
}

# Function to get the maximum I/O utilization (%util) across all monitored devices
get_max_io_util() {
    # We use -x (extended stats) and monitor all devices.
    # The 'awk' script finds the column index for '%util' dynamically.
    iostat -x 1 2 | awk '
        BEGIN { max_util = 0.0; f = 0; util_col = 0; }
        
        # 1. Look for the header line (contains 'r/s' and 'util'). Set flag (f) to start processing.
        #    We only do this check in the second block.
        /avg-cpu:/ { if (f == 0) f = 1; else if (f == 1) f = 2; next }

        # 2. In the second block (f == 2), check for the header line to map columns
        (f == 2 && $1 == "Device") {
            # Find the column index for the "%util" header
            for (i=1; i<=NF; i++) {
                if ($i == "%util") {
                    util_col = i;
                    break;
                }
            }
            # Skip the header line after mapping
            next
        }

        # 3. Process data lines only after the column has been mapped
        (f == 2 && util_col > 0) { 
            # Match lines starting with a common device prefix
            if ($1 ~ /^(sd|nvme|loop|hd|dm|zram|mmc)/) {
                # Use the dynamically found column index
                util = $(util_col);
                if (util > max_util) {
                    max_util = util;
                }
            }
        }
        END { print max_util; }
    '
}

# --- Main Loop ---

while true; do
    # 1. Get current I/O activity
    MAX_UTIL=$(get_max_io_util)
    
    # Use 'bc' for floating-point comparison
    if (( $(echo "$MAX_UTIL > $UTIL_THRESHOLD" | bc -l) )); then
        
        # I/O is active and exceeds the %util threshold
        if ! is_inhibitor_running; then
            setsid systemd-inhibit --what=idle:sleep --why='Active I/O Detected (%util)' --mode=block sleep infinity &
            echo $! > "$PID_FILE"
        fi
        
    else
        
        # I/O is idle or below threshold
        if is_inhibitor_running; then
            kill $(cat "$PID_FILE") 2>/dev/null
            rm "$PID_FILE"
        fi
        
    fi

    # Wait before checking again
    sleep $CHECK_INTERVAL 
done

(sim, este script foi vibe coded e precisei ajustar algumas vezes até funcionar, as versões que o Gemini me dava não funcionavam kkkk).

O principal é o awk processando a saída do comando iostat -x 1 2. Meu micro SD card aparece como /dev/sda:

Note que no segundo bloco, quando estou copiando vários arquivos, ele mostra 99.61 e fica variando entre 90 a 100% de uso, que é o desejável: significa que está usando toda a banda disponível de IO pra ele.

Então, queremos que, enquanto estiver numa taxa acima de zero, tipo, maior que 10% de atividade, o HyprIdle não ative o sleep no timeout normal.

Com esse script, agora temos o seguinte quando listamos systemd-inhibit --list:

Agora apareceu uma nova linha dizendo:

• sleep infinity: Este é o nome do processo que iniciou meu script e segura o lock.

• sleep:idle: Esta é a parte crucial. Diz ao systemd e logind pra bloquear tanto sleep (system suspend) quanto idle (prevenindo timers de idle como do hypridle).

• Active I/O Detected (%util): Esta é a razão especificada no script.

E pronto, pra garantir que temos este script sempre rodando, basta alterar o ~/.config/hypr/autostart.conf pra ter esta linha:

exec-once = /home/akitaonrails/.local/bin/io_inhibit.sh &

Em teoria, agora posso deixar essas atividades longas de IO rodando e não me preocupar do meu Arch suspender e dormir.

Alguém conhece alguma solução mais simples do que essa? Se tiver idéias, mandem nos comentários.

As perguntas que eu mais recebo, literalmente todos os dias, são no formato: “Akita, devo fazer faculdade?, “Akita, o que você acha que eu devo estudar?” e variações dessas.

Velho, eu não te conheço, nunca vou saber nem me interessar em saber quem você é, o que almeja, quais suas aspirações, ambições, gostos, preferência. Nada. Nem eu, nem NINGUÉM. Só você sabe o que é melhor pra você. Se não sabe, trate de procurar saber. É isso que VIVER significa.

O que você não admite é que quer que alguém que considera mais importante ou relevante aprovando sua escolha e dizendo que está certo.

Nunca espere isso de mim, eu nunca vou te validar.

Sempre vou dizer: SE VIRA. Foi assim que eu me tornei quem eu sou. Eu nunca segui ninguém, nunca perguntei pra ninguém o que deveria fazer. Simplesmente ia lá e fazia. Quebrava a cara, caía, levantava, e tentava de novo. É a vida.

Deixa eu mostrar o que me INCOMODA mesmo:

Vamos ver no manual?

O DHH se deu ao trabalho de escrever um manual. Tem uma seção chamada “Security”. Se tivesse ido no Google, teria achado. Ou esta outra pérola:

Como quer ser “DEVOPS” (que tem que saber TUDO de Linux) começando assim. Já começou errado. Senta a bunda na cadeira, arregaça as mangas, e testa um por um, e aprende.

Linux pra Iniciante?

Isso dito, assista meu video. Mas como tenho falado bastante de Omarchy já digo que sim, este é o que eu uso no meu dia a dia e é único que vou recomendar no futuro próximo (depois posso mudar de idéia). Tendo usado distros desde que Linux foi inventado no começo dos anos 90, eu sei que existem dezenas de distros e nem eu tenho paciência pra experimentar todos.

Por que Omarchy?

Primeiro porque ele fez a escolha certa da distro base: Arch Linux. Considero que é a melhor distro que existe hoje por dois fatores: ele tem pouco “bloat” (não instala um monte de coisas que você nunca vai usar, como um Ubuntu, Fedora, Mint, Deepin ou qualquer outros desses “pra iniciantes”).

Segundo, Arch Linux tem o AUR, que é um repositório de pacotes feitos pro usuários que tem basicamente tudo. Não precisa ficar caçando repositórios de terceiros ou ter que instalar manualmente. Com um único comando, o yay, instala-se tudo. Não existe isso de apt-repository add ou ter que fazer make install nem nada disso. O AUR gerencia tudo pra você.

Terceiro, ele instala Hyprland (que eu já usava e gostava), com configurações muito boas, escolha de pacotes muito bons. Tudo que eu mesmo instalaria manualmente. Então é uma opção mil vezes mais fácil pra ter o que eu teria muito mais trabalho pra fazer sozinho. Veja minha série de posts sobre Omarchy pra ver essas opções.

Linux pra Iniciantes?

Iniciante em que?

Eu odeio essa pergunta. Se você é um usuário amador mesmo, não programador, talvez seja um contador, talvez seja só um adolescente gamer. A primeira pergunta que faço é: pra que você quer usar Linux??

Digamos que seja porque ouviu falar que é mais seguro (de fato é). Então tanto faz, qualquer distro serve. Instale Ubuntu, instale Manjaro, instale Garuda. Não faz diferença, porque você nunca vai lidar com nada por baixo dos panos. Vai abrir o Chrome, vai abrir o Steam, e é só isso. O resto vai ser web-apps.

Digamos que é só pra jogar, então instale Bazzite no seu mini-PC ou handheld. Ou só instale seus jogos num Windows separado só pra jogos como eu fiz. Tanto faz.

Ou fique no Windows ou MacOS mesmo. Se for totalmente amador, provavelmente vai usar a mesma senha fraca pra tudo, vai sair clicando em links do Whatsapp sem ver de quem é. Literalmente tanto faz qual OS vai usar. Nenhuma segurança de nenhum OS vai proteger seus maus hábitos e ignorância.

Se for iniciante em programação ou tecnologia, aí eu não tenho dó: aprenda Linux direito. Você quer ser um profissional, seja um profissional, aprenda do jeito certo: aprenda a ter 100% de controle sob sua própria máquina. Não tem passo a passo nem tutorial pra isso. É algo que você vai fazer continuamente pro resto da vida. Eu tenho mais de 30 anos na área e continuo aprendendo coisas novas todos os dias.

Hardware

O MAIOR problema que qualquer pessoa vai ter, com QUALQUER distro vai ser suporte a hardware. E eis porque você não deve só seguir o que alguém te recomenda:

Ninguém tem o mesmo PC que você.

Qual é seu notebook? Um Lenovo? Um Dell? Um Positivo? De que ano? Qual modelo?

Tudo vai variar: qual é o dispositivo de Wi-fi e bluetooth? qual é a placa gráfica? Qual firmware está rodando? Com que suportes de perfis de energia? Tem necessidade de dispositivos FIDO2 pra coisas como leitor de impressão digital? Hardware keys? Tem TPU na sua máquina? Vai precisar de Secure Boot?

Não sei. Você que tem que saber.

Um exemplo prático, eu tenho um notebook Asus Zephyrus G14 que uso com Windows porque serve só na minha oficina pra rodar Bambu Studio pra controlar minha Impressora 3D X1C. Ainda não parei pra instalar Omarchy nele, mas digamos que eu queira. Vai funcionar?

Felizmente existe uma página no ArchWiki dedicada a este modelo. Ao que parece, funciona tudo “out-of-the-box”. Mas se fosse a versão do ano anterior já teria que checar mais ítens extras. Tem problemas no Wi-fi, por exemplo.

Cada máquina diferente vai ter problemas diferentes.

Live Env e Ventoy

“O que eu faço então, me ph0di?

É por isso que praticamente toda boa distro oferece a ISO de instalação que vem com um ambiente vivo (Live Environment). Já vi que tem muita gente no Windows que tem dificuldade do que fazer com uma ISO. É muito simples.

O programa mais fácil de usar é o Balena Etcher Você baixa o arquivo com extensão .iso, seja do Ubuntu, Mint, Elementary, etc (SEMPRE DO SITE OFICIAL!!!!). Abre o Balena e só tem 2 passos: selecione a imagem (o arquivo ISO), selecione o drive (seu pen drive, cuidado pra não escolher seu HD!), e pronto.

Agora é só bootar seu PC e entrar na BIOS pra selecionar o pen drive pra bootar ou usar uma tecla como F12 (varia de BIOS pra BIOS) pro UEFI selecionar seu pen drive.

Isso vai bootar o Live Environment direto do pen drive.

A maioria das distros começa abrindo uma tela de “Bem Vindo” parecida com a de cima. Esse aplicativo de instalação se chama Calamares e todo mundo com instalação gráfica usa ele. Por isso é parecido em todos. É o mesmo passo a passo. Se instalou uma distro já instalou todas.

Só que você não precisa seguir o Calamares. Pode fechar ele. E agora está já no ambiente gráfico da distro que escolheu pra instalar. USE ELE. Tente configurar seu Wi-fi, tente parear seu fone ou mouse Bluetooth, tente ligar a WebCam, coloque um micro-SD card e veja se ele aparece. Tente navegar na web e sinta a performance.

Se nesse ponto conseguir fazer todas as coisas básicas, significa que as chances de tudo funcionar é grande. Se já neste ponto começar a ter problemas, como não conseguir conectar no seu Wi-fi, possivelmente essa distro vai te dar dor de cabeça. Comece indo no Google e veja se alguém já solucionou o problema pro seu modelo de notebook ou PC, antes de continuar com o Calamares.

Digamos que você decidiu tirar o dia pra testar várias distros pra ver qual roda melhor na sua máquina. Ótima decisão, mas já deve ter entendido que vai ser um enorme saco ter vários pen drives, um pra cada distro. Ou toda hora ter que voltar pro Windows e usar o Balena pra sobrescrever uma nova distro no seu único pendrive.

Não precisa fazer isso.

Basta baixar e instalar primeiro o Ventoy no seu pendrive. Veja a documentação no site deles, mas é ridiculamente simples.

Depois de instalar no seu pendrive, agora é só copiar TODAS AS ISOS que quiser de uma só vez no pendrive. Quando bootar por ele, vai entrar no menu do Ventoy, que vai deixar escolher qualquer uma das ISOs que copiou lá. Se não gostou da distro atual, só rebootar no Ventoy de novo, e escolher outra ISO. É assim simples.

Distrobox

Digamos que você é um programador, ou um devops, ou qualquer profissional na área de tecnologia. Sua preocupação não é tanto a interface gráfica (que dá pra testar com Ventoy), mas sim se a infra do OS vai funcionar com seus requerimentos de desenvolvimento.

Digamos que você use Fedora. Será que se eu for pro Mint, vai ter os pacotes pro K8S do jeito que eu preciso? Será que tem suporte à versão de Java que eu uso? Será que se eu buildar um pacote .deb no meu Fedora, vai instalar direitinho no Ubuntu?

Ter que fazer dual boot ou instalar uma VM parece pesado demais, trabalhoso demais, só pra testar 2 linhas de comando, por exemplo.

Pra isso existe Distrobox. Ele precisa do Docker ou Podman já instalado na sua máquina. Mas depois é só fazer:

distrobox create -n debian-test --init --image debian:latest --additional-packages "build-essential"

Uma vez criado o box é só entrar nele:

distrobox enter debian-test

Acabou, você está dentro do Debian, super rápido. Como é um container docker, tem como mapear diretórios na sua máquina local pra dentro do container, então fica tudo integrado. E o mais importante: carrega super rápido, porque é só um container Docker.

O guia Quick Start explica tudo isso e tem este video com um tour pra demonstrar como funciona:

Conclusão

Sério. Com Distrobox não tem desculpa pra não testar outra distro em 2 minutos. Não fique perdendo tempo mandando DM pra “influencer”. Veja você mesmo! Se não é capaz de fazer isso, talvez esteja na profissão errada.

Todo “dev” ou profissional de tecnologia, seja de devops, cybersec, data analyst, bla bla bla, seja lá qual título da moda hoje em dia, DEVE ter controle sobre sua própria máquina. DEVE saber lidar com segurança (por isso fiz posts sobre Vaultwarden, Cloudflare, SSH, etc).

É SUA RESPONSABILIDADE!

Não terceirize sua responsabilidade pros outros. Não procure validação. Seja promíscuo e teste quais distros quiser, e faça o que quiser nessas distros: é sua! Não existe “distro pra iniciante”, “distro pra dev”, “distro pra devops”. Distro é Distro. Linux é Linux. É tudo igual, o que varia é sua habilidade. Se não tem habilidade: conquiste! Aprenda! Quebre a cabeça! Vare noites tunando configs! Leia as documentações oficiais! Não perca tempo achando que vai aprender em rede social. Não vai.

Eu uso Linux desde o começo dos anos 90 e não fico usando Slackware só porque foi a primeira que aprendi e sinto necessidade de validar minha primeira escolha. Eu uso todas que quiser. Agora mesmo, eu tinha minha própria instalação de Hyprland, resolvi que quero aprender e usar Omarchy. Passei a semana quebrando cabeça, escrevi meia dúzia de posts no blog. E agora eu aprendi. Eu sei Omarchy: mais um pra coleção.

Só ir no site oficial e clicar em “ISO” pra baixar. Usar um Rufus ou Balena Etcher no Windows (ou Caligula em Linux) pra gravar num pen drive e bootar com ele. Dali em diante é seguir o passo-a-passo e em menos de 5 minutos vai ter tudo instalado.

Como expliquei no primeiro artigo eu fiz diferente: instalei o Arch Linux puro, tipo Desktop, com Hyprland + SDDM. Depois instalei Omarchy usando a linha de comando manual:

curl -fsSL https://omarchy.org/install | bash

Dá pra fazer dos dois jeitos, no segundo tem mais controle, mas depois de ganhar mais experiência e ler os scripts de install, eu recomendo que baixe a ISO do próprio Omarchy, vai ser mais fácil mesmo.

Limine vs Grub

O motivo de ter instalado da forma mais manual foi porque eu não tinha certeza se o Omarchy tinha suporte a dar rollback de BTRFS via snapshots. Eu tinha ouvido falar que o bootload Limine não suportava isso. Mas me enganei, o Omarchy instala Limine com suporte a Snapper (que é similar ao Timeshift que eu costumo usar). Leia no ArchWiki seção 6.2, portanto deve ser uma opção superior à minha instalação de GRUB+Timeshift que falei no primeiro artigo.

Como eu já instalei de forma manual, vou manter como está porque na prática é a mesma coisa. Mas se fosse instalar de novo, agora instalaria com Limine+Snapper pra experimentar.

Significa que existe suporte a snapshot do seu filesystem inteiro com BTRFS antes de um update de pacotes e, se algo der errado, é possível rebootar e dar rollback pra um snapshot anterior. Isso te dá segurança de não perder um dia inteiro tentando consertar alguma coisa, caso algum pacote importante do sistema venha com bugs ou corrompido. É o recurso mais importante.

SDDM vs UWSM

Outra coisa diferente que notei foi o login manager. No Arch puro, ele instala Hyprland por padrão com SDDM, que é o mesmo que o KDE usa.

Omarchy usa UWSM, que faz login automático com seu usuário no boot. Então não tem tela de login, ele já abre o Hyprland automaticamente.

“Mas isso não é inseguro??”

Não, porque a ISO do Omarchy pré-configura seu SSD com LUKS, antes do filesystem.

Pra quem não sabe, LUKS é o Linux Unified Key Setup, que dá suporte a encriptar seu disco inteiro. A vantagem dele em relação a um BitLocker do Windows, é que ele é agnóstico a filesystem. Ou seja, funciona com BTRFS ou EXT4 ou qualquer outro, porque na sequência de boot, depois do bootloader (seja Limine ou Grub), ele carrega antes do filesystem. É um encriptador em nível de blocos.

Portanto, quando você bootar seu sistema, primeiro vai pedir a senha de decriptar seu disco. Daí abre o filesystem e o kernel do Linux pode continuar o boot normal com o disco aberto. Então você é obrigado a sempre digitar a senha segura do seu usuário no boot pra decriptar o disco.

Portanto, ter que digitar senha novamente num login manager seria redundante e desnecessário, por isso imagino que escolheram usar UWSM em vez de SDDM.

Especialmente em notebook, ou em casos onde mais gente mora com você, é essencial garantir que seu disco esteja encriptado, não importa o sistema operacional. Digamos que saia pra trabalhar ou vá viajar e seu notebook é roubado. Sem encriptação, acabou, não importa se tem um login manager. Ele não protege seus dados. Basta tirar o SSD do seu notebook, plugar em outro computador e pronto, dá pra copiar tudo bootando como Root.

Com encriptação, sem a senha pra decriptar, é impossível acessar seus dados. Impossível mesmo, porque em qualquer computador modernos dos últimos 15 anos, a CPU vem com instruções aceleradas em hardware pra encriptar usando AES 256.

Sendo um pouco mais nerd, a chave de decriptação não é sua senha. Durante o processo de instalação vai ser gerada uma nova senha mais forte e segura usando um processo de derivação de chaves (KDF - Key Derivation Function), hoje em dia é com Argon2id, antigamente era com PBKDF2. Explico sobre isso neste video:

Portanto, quando digita sua senha, na verdade ele decripta essa chave segura, e é com essa chave segura que seu disco está encriptado. Por isso não dá pra decriptar seus dados na força-bruta.

Além disso AES 256 é outro algoritmo de criptografia que é quantum resistant. Mesmo se fosse possível um computador quântico (não é), nem ele conseguiria decriptar seu disco. Este é o nível de segurança.

“Mas não vai ficar mais lento?”

Não. É praticamente imperceptível, porque AES - como já disse - é acelerado via hardware pela sua CPU, não depende de software do seu sistema operacional. No dia a dia, dificilmente vai notar. A performance é praticamente a mesma. Não existe motivo pra não ativar encriptação, especialmente num notebook.

No meu caso pessoal, onde instalei num PC desktop, que eu mesmo controlo numa rede local segura - porque eu sei implementar segurança em rede, não tem problema. Os dados mais importantes pra mim ficam no meu NAS (que é encriptado), em backups (que são encriptados), eu não tenho dados sensíveis neste PC e o pouco que tenho está em arquivos encriptados pelo Veracrypt num sub-volume separado.

Por isso não habilitei LUKS no meu PC. Daí mantive o SDDM que o Arch puro instalou. Só que ele é BEM feio por padrão, então só fica uma pequena dica: instalar ou o tema sddm-sugar-dark ou o dark-arch-sddm. Eu prefiro esse segundo por ser mais minimalista e fica assim:

Eu customizei e troquei o logo do Arch pelo do Omarchy e pronto.

Conclusão

Vou repetir: só depois que instalei manualmente que vi como o Omarchy instala e hoje eu prefiro o jeito do Omarchy. Se fosse instalar do zero, usaria a ISO do Omarchy e deixaria com Limine+Snapper e Hyprland+UWSM com suporte a rollback de snapshot, encriptação total do disco, login automático pro Hyprland.

Dá pra ver que o pessoal fazendo o Omarchy tem experiência e já escolheu componentes que fazem sentido pra funcionar tudo junto da forma mais conveniente e segura possível. Eu tive receio que por ser uma distro nova talvez eles não tivessem se preocupado com isso, mas fico feliz de dizer que eu estava errado.

Usem a ISO oficial do Omarchy.

Todo programador precisa saber como gerenciar suas chaves SSH. No mínimo porque toda conta no GitHub exige uma chave.

Toda vez que fizer git push pra um repositório seu, ele vai pedir a passphrase dessa chave:

❯ git push origin master
Enter passphrase for key '/home/akitaonrails/.ssh/id_ed25519':

O que significa isso?

SSH é um conjunto de ferramentas tanto de cliente quanto servidor pra criar uma conexão segura, encriptada, pela internet. Ela tem diversas utilidades e eu expliquei como fazer Proxy SSH neste video:

O processo todo se inicia instalando SSH na sua máquina, e no Omarchy/ArchLinux é só fazer isso:

yay -S openssh

Se nunca criou um par de chaves (sim, é um par) é só executar este comando:

ssh-keygen -t ed25519 -a 100 -C "your_email@example.com" -f ~/.ssh/id_ed25519

ED25519 é um algoritmo de chave-pública, ou seja, cria um par de chaves: uma privada que jamais deve sair da sua máquina, e uma pública que pode ser exposta na internet aberta (a que você registra na sua conta no GitHub, por exemplo). Eu expliquei sobre chaves-públicas neste outro video:

ED25519 é um algoritmo mais moderno que o antigo RSA (que acho que ainda é o padrão no ssh-keygen se não fizer a escolha explícita - ela continua sendo segura, mas curva elíptica é ainda mais segura).

Ela é baseada em criptografia de curva elíptica (ECC). Pros paranóicos, sim, é inclusive considerada quantum-resistant, ou seja, mesmo se fosse possível fazer um computador quântico, ela não conseguiria quebrar uma chave ED25519.

Dois arquivos serão criados depois de rodar ssh-keygen:

.rw-------   464 akitaonrails 14 Nov  2017  󰌆 id_ed25519
.rw-r--r--   108 akitaonrails 14 Nov  2017  󰷖 id_ed25519.pub

Note as permissões desses arquivos. É importante que o diretório ~/.ssh e os arquivos de chave privada dentro sempre estejam com permissão 600 , ou seja, read-write somente pro seu usuário, e nenhuma permissão pra grupos ou qualquer outro usuário. Ninguém deve ser capaz sequer de listar o diretório se não for você mesmo.

Já os arquivos *.pub, que são as chaves públicas, tem permissão 644 que é read-write pra você e somente-leitura pra outros grupos e usuários. Como falei, a chave pública pode ser exposta publicamente. A minha, por exemplo, é esta:

❯ cat id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEWG5bHK02sMqilMiYu67xqdaBsk3TtCQ564bcJibDiO akitaonrails@Miner42.local

ED25519 tem outra vantagem, ela é ordens de grandeza mais segura que RSA e ainda oferece uma chave pública muito mais curta, o que facilita na hora de copiar e colar por aí.

Uma chave privada tem um envelope neste formato:

-----BEGIN RSA PRIVATE KEY-----
MIIEpA ...
...
XfI0X....
...
... nQ5w==
-----END RSA PRIVATE KEY-----

Repetindo: ESTE ARQUIVO JAMAIS DEVE SAIR DA SUA MÁQUINA. Nunca deixe largado num pen drive, por exemplo. E sempre garanta que a permissão é chmod 600 como expliquei.

Yubikey 5

A forma considerada mais segura e que muitas empresas até enforçam, é o uso de uma HARDWARE-KEY. A chave privada nunca é gravada na sua máquina local e sim gerada dentro de um hardware seguro, de onde é impossível tentar ler essa chave privada. Exemplos são Yubikey ou FIDO2.

Sobre Yubikey, cuidado, você quer os modelos mais novos Yubikey Series 5:

Se tiver o antigo - que normalmente é o de cor azul - ele é o Security Key v4.3.1 e só suporta U2F (FIDO U2F) mas não FIDO2/WebAuthn e não applets PIV/OpenPGP/OTP. Pra ter certeza, instale estes pacotes no seu Arch:

sudo pacman -S yubikey-manager libfido2

Daí cheque com este comando:

❯ ykman info
WARNING: PC/SC not available. Smart card (CCID) protocols will not function.
Device type: FIDO U2F Security Key
Firmware version: 4.3.1
Enabled USB interfaces: FIDO

Applications
Yubico OTP   Not available
FIDO U2F     Enabled
FIDO2        Not available
OATH         Not available
PIV          Not available
OpenPGP      Not available
YubiHSM Auth Not available

Veja como ele acha o Yubikey conectado via USB mas tudo está como “Not available”. Não é o correto, esse Yubikey só serve como Two-Factor Authentication em Websites. Não é inútil, mas pro nosso caso não funciona porque:

• não tem applet PIV então não serve de smartcard
• não tem applet OpenPGP então não consegue guardar chaves privadas GPG ou SSH
• não tem FIDO2 então não dá pra rodar ssh-keygen -t ed25519-sk.

Um novo, no Mercado Livre hoje, vai custar uns BRL 800. Se for usar pra trabalhar por política de segurança da empresa, eles tem que providenciar ou ressarcir pra você. Mas mesmo pra uso pessoal, recomendo investir um pouco mais na segurança.

Tendo um Yubikey 5, o procedimento é o seguinte. Comece garantindo que tem os pacotes na sua máquina:

sudo pacman -S yubikey-manager yubico-piv-tool opensc

Inicialize a aplicação PIV mudando o PIN:

ykman piv reset                # wipes PIV, careful
ykman piv access change-pin    # default PIN is 123456
ykman piv access change-puk    # default PUK is 12345678

Gere um novo par de chaves dentro do Yubikey:

ykman piv keys generate 9a pubkey.pem

Extraia somente a chave pública pro seu diretório local ~/.ssh:

ssh-keygen -D /usr/lib/opensc-pkcs11.so -e > ~/.ssh/id_yubikey.pub

O conteúdo desse arquivo ~/.ssh/id_yubikey.pub é que você vai adicionar no arquivo ~/.ssh/authorized_keys do seu servidor remoto que quer conectar via SSH. Pra abrir uma conexão SSH pra ele, conecte o Yubikey na porta USB e execute assim:

ssh -I /usr/lib/opensc-pkcs11.so seu-user@server

Ele vai pedir seu PIN e autorizar a conexão. Se não quiser ficar digitando esse -I toda vez, basta editar o ~/.ssh/config com isto:

# ~/.ssh/config
Host server
  PKCS11Provider /usr/lib/opensc-pkcs11.so
  User seu-user

PORÉM

Este procedimento vai usar o gerador de chaves de dentro da Yubikey, que só suporta RSA (1024–2048) ou ECC (P-256, P-384). Se quiser gerar uma chave ED25519, o fluxo é diferente, temos que executar assim:

ssh-keygen -t ed25519-sk -a 100 -C "you@example.com" -f ~/.ssh/id_ed25519_sk

Esse arquivo id_ed25519_sk que ele gera na sua máquina local não é a chave-privada é somente um “stub” que aponta pra sua Yubikey. Então a chave fica armazenada no hardware e nunca passa pela sua máquina.

Pra adicionar sua chave-pública no servidor remoto, basta manualmente adicionar no arquivo ~/.ssh/authorized_keys como fizemos antes ou rodar este comando pra logar com sua senha e ele vai adicionar a chave-pública pra você:

ssh-copy-id -i ~/.ssh/id_ed25519_sk.pub seu-user@server

Pra usar sua chave pra logar agora é só fazer:

ssh -i ~/.ssh/id_ed25519_sk seu-user@server

Isso só funciona porque a Yubikey 5 tem suporte a FIDO2. As antigas não tem, por isso não dá pra fazer isso.

Ah sim, no seu home server ou outro servidor, DEPOIS que adicionar sua chave no authorized_keys eu recomendo DESABILITAR a opção de login por senha (pra que nenhum bot fique tentando logar por força bruta). No servidor edite:

# /etc/ssh/sshd_config
PasswordAuthentication no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no
UsePAM no
...
PubkeyAuthentication yes

Ou seja, desligue todas as opções de login e deixe somente por chave pública. Agora só reinicie o serviço:

sudo systemctl restart sshd

SSH-Agent

Pra ficar claro: a forma considerada mais segura pra gerenciar chaves privadas é via um hardware de segurança externo, no caso a Yubikey 5.

Mas, não é obrigatório. Se você tem um PC exclusivo pra trabalhar, com seu Arch Linux ou Omarchy instalado, e você não fica instalando softwares suspeitos - como jogos pirateados - nem fica acessando sites suspeitos e clicando em qualquer link (risco de malware), não é completamente ruim ter suas chaves localmente na sua máquina. Eu mesmo uso assim faz anos e nunca tive problemas - porque eu sou paranóico com segurança da minha máquina.

Lembre-se, um dos tipos de malware mais comuns são que fazem upload dos seus arquivos ou que encripta seus arquivos e depois pedem resgate de criptomoeda pra devolver. O bom e velho RANSOMWARE:

Isso tem não só em Windows como Mac e Linux também. E navegadores web são o principal vetor, especialmente emails de phishing com links maliciosos que você sai clicando, ou links que vem em canais de Discord, Telegram ou Whatsapp.

NUNCA CLIQUE EM LINKS. Copie o link, cole num terminal e veja que tipo de link que é. Se não for um domínio obviamente oficial como “whatspp.com” ou “google.com”, não siga em frente.

isso tudo dito. Digamos que você criou suas chaves localmente e cadastrou no authorized_keys do seu servidor e na sua conta de GitHub. Agora, toda vez que fizer ssh ou git push ele vai pedir pra digitar sua passphrase (que, se você não for bobo, fez uma passphrase BEM LONGA).

Isso é extremamente inconveniente de ficar digitando o tempo todo. Por isso tem um recurso no SSH pra ajudar: cachear sua autenticação durante algum tempo fixo usando ssh-agent.

Comece criando este serviço de usuário pro systemd:

# ~/.config/systemd/user/ssh-agent.service
[Unit]
Description=SSH Agent

[Service]
Type=simple
Environment=SSH_AUTH_SOCK=%t/ssh-agent.socket
ExecStart=/usr/bin/ssh-agent -D -a $SSH_AUTH_SOCK

[Install]
WantedBy=default.target

Habilite com privilégios do seu user (sem sudo):

systemctl --user enable --now ssh-agent.service

Exponha isso no seu .bashrc ou .zshrc:

# ~/.zshenv (or ~/.profile)
export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/ssh-agent.socket"

Agora, toda vez que fizer login no seu sistema e começar a trabalhar, adicione sua chave de trabalho:

ssh-add -t 30m ~/.ssh/id_ed25519

Ele vai pedir sua passphrase uma vez, mas durante 30 minutos (que é essa opção -t 30m), não vai mais precisar re-digitar a passphrase e pode ficar acessando ssh ou fazendo git push de forma mais conveniente.

Se quiser remover o cache do agente, antes do timeout, pode fazer:

ssh-add -d ~/.ssh/id_ed25519

Se sua rotina de trabalho envolve usar ssh, em vez de manualmente fazer ssh-add pode adicionar a seguinte configuração no seu ~/.ssh/config:

# ~/.ssh/config
Host *
  AddKeysToAgent yes
  IdentitiesOnly yes
  IdentityFile ~/.ssh/id_ed25519

E toda vez que abrir o terminal, ele vai pedir pra digitar sua passphrase. E isso vai durar enquanto sua sessão estiver logada.

Por fim, o nome do arquivo nos exemplos é sempre id_ed25519 mas isso não tem relevância nenhuma, você pode renomear como quiser e inclusive criar múltiplas chaves pra usar em serviços separados, se quiser ser extra-seguro. Basta gerar chaves como heroku_id_ed25519 ou google_cloud_id_ed25519 e assim por diante. Crie quantas chaves quiser ou achar necessário. Isso vale tanto pra chaves locais quanto chaves na Yubikey 5.

Acho que estes são os aspectos que considero mais importante saber sobre chaves SSH, esqueci alguma outra coisa importante? Não deixe de mandar mais dicas nos comentários abaixo.

Os apps mais “modernos” são basicamente front-ends web enlatados dentro de um wrapper Electron. O problema? São PESADOS consomem RAM como se não houvesse amanhã. Comece a abrir Discord, Spotify, e vários desses e veja se seu notebook velho de 8GB de RAM vai aguentar.

Mas, especialmente se você é um programador, deveria dar mais atenção pra TUIs. Num primeiro momento alguns devem virar o nariz: “apps de terminal são feios, preto e branco, quadrados, blerg”

Se fosse 20 anos atrás, estariam certos. Mas é 2025 e hoje em dia terminais suportam 256 cores (mais que suficiente), suportam várias resoluções e, mais importante, suportam fontes, em particular Nerd Fonts, fontes que tem ícones dentro. É assim que funciona uma ferramenta como eza, que eu uso todo dia com alias pra ls e fica assim:

Não é só isso, existem bibliotecas modernas, pra diversas linguagens, como BubbleTea, que é um framework pra construir TUIs. Chequem o GitHub deles mas tem as ferramentas pra fazer interfaces assim:

E se quiser só um widget simples pra complementar um script Bash que está fazendo, eles tem o Gum, que permite interfaces assim:

E pra usar é só instalar o binário e no seu script fazer linhas assim:

# exemplos de Gum
gum choose "fix" "feat" "docs" "style" "refactor" "test" "chore" "revert"

gum input --placeholder "scope"

gum confirm "Commit changes?" && git commit -m "$SUMMARY" -m "$DESCRIPTION"

E se usa Omarchy eles ainda trazem uma funcionalidade extra pra TUIs. Basta clicar “SUPER+ALT+SPACE” pra trazer o menu principal, depois escolher “INSTALL” e “TUI”. Ou simplesmente abrir o terminal e executar:

$OMARCHY_PATH/bin/omarchy-tui-install

Ele vai pedir um nome pro App e a linha de comando pra executar. Dá pra escolher icones também no Dashboard Icons. Registrando dessa forma, quando chamar o launcher Rofi com “SUPER+SPACE” e digitar “lazy” vai aparecer o LazyDocker como se fosse um app normal:

E como em Hyprland não tem barra de título nem nada, apps TUI ou webapps (tem omarchy-webapp-install também) abrem como se fossem apps “nativos”:

Leiam as seções de TUIs e Web-Apps no manual do Omarchy.

Obviamente, isso é só se você é daqueles que prefere a sensação de estar executando “Apps”, mas é a mesma coisa se abrir um Terminal e simplesmente digitar o lazydocker na linha de comando - que é minha preferência. O que esses scripts do Omarchy fazem é criar um arquivo .desktop em ~/.local/share/applications. O exemplo do LazyDocker.desktop gera isto:

❯ cat ~/.local/share/applications/LazyDocker.desktop
[Desktop Entry]
Version=1.0
Name=LazyDocker
Comment=LazyDocker
Exec=alacritty --class TUI.tile -e lazydocker
Terminal=false
Type=Application
Icon=/home/akitaonrails/.local/share/applications/icons/LazyDocker.png
StartupNotify=true

Se não quiser mais este launcher é só apagar o arquivo ou chamar o script $OMARCHY_PATH/bin/omarchy-tui-remove.

Esse recurso é particularmente interessante no Hyprland porque diferente de GNOME ou KDE, a janela não tem barra superior de título, então não entrega que você está só abrindo um terminal ou navegador web. É assim que ele já vem pré-configurado com coisas como ChatGPT ou Grok parecendo que são apps “nativos”, mas na verdade são só janelas de Chromium abrindo direto as URLs de cada um:

Alguns TUIs que eu gosto

Na minha opinião, já que não tem Apps com GUIs bonitas pra Linux, é melhor mesmo usar os respectivos web-apps como Canva ou ChatGPT dessa forma, mas mais interessante é ter TUIs mesmo. Como falei, hoje em dia não é difícil fazer TUIs bonitas. Pra um programador, a vantagem é não tem que lidar, primeiro com frameworks de front-end, segundo, ter que fazer deploy em algum lugar na internet.

TUIs são leves, usam poucos recursos na máquina, são fáceis pra qualquer programador fazer, e você pode ter um home server ou um servidor num cloud qualquer, acessar via SSH e acessar a TUI, sem ter que lidar com X11 ou RDP ou qualquer coisa mais pesada só pra ter um GUI.

Alguns TUIs são óbvios, no post anterior já falei de LazyVim e como ele é um editor de textos tão competente e completo quando um VS Code, usando só uma fração dos recursos da máquina. Todo mundo deve conhecer ferramentas como HTOP ou BTOP. Além dos LazyGit ou LazyDocker também. Esses todos já vem no Omarchy.

Mas tem muito mais, por exemplo, dblab que é um TUI cliente de banco de dados como MySQL ou Postgres:

Outro similar é LazySQL, feito em Go:

Ou se você prefere ferramentas feitas em Rust, tem o rainfrog:

Pra quem não consegue usar CURL na linha de comando e prefere usar Postman pra chamar e explorar APIs, tem o TUI Posting que faz a mesma coisa:

Pra nós que rodamos muitos containers Docker, já falei do LazyDocker, mas tem também o oxker:

Se usar Discord, tem o discordo:

Quem faz muito ricing de Linux já teve que gravar ISOs em Pen Drives dezenas de vezes, pra isso tem o dd na linha de comando, mas tem um TUI mais legal que é o Caligula:

Se seu SSD está ficando cheio e você não sabe onde diabos que tá ocupando tanto espaço, tem várias ferramentas pra analisar e te mostrar, um deles é o gdu:

E o último que achei legal pela nostalgia é o sc-im, pense em Excel como TUI ou - pra nós que viemos dos anos 80 - pense Lotus 1-2-3 mas com key bindings de Vim:

Pra que abrir Google Spreadsheets só pra fazer um Todo list se dá pra fazer no Terminal?? TUIs são excepcionais!

Se quiser conhecer mais TUIs olhe o awesome-tuis no GitHub:

De novo: zero necessidade de front-ends web pesadas pra coisas simples. Nada supera a simplicidade de uma linha de comando. E com bibliotecas como BubbleTea ou Gum, está muito fácil pra qualquer um fazer um app bonito. E com Hyprland e Omarchy, fica tudo integrado lado-a-lado de qualquer outro app com GUI.

Filosofando um pouco, a história das GUIs começa com interfaces gráficas skeumorphic que tentam imitar objetos do nosso dia a dia, em particular parecendo pseudo-3D, como era um Windows 95. Chegou nos anos 2000 e começaram a migrar pra interfaces flat ou minimalistas, tirando completamente o skeumorphismo, deixando tudo plano. Foi a partir do Metro do Windows 8, principalmente. E eu acho que isso converge pra estilo mais de TUI, dando uma volta completa, voltando a como era nos terminais dos anos 70. Eu particularmente acho isso fascinante.

No meu caso, eu passei 10 anos usando Manjaro GNOME como meu daily driver. Manjaro que é um derivado de Arch. A razão era a instalação mais simples e configurações pré-prontas. Mas hoje em dia, com archinstall, acho que não vale mais a pena. Sei que existem outros derivados, mas é melhor ficar no original mesmo.

Pra quem é de Ubuntu ou derivados de Debian, Fedora, etc, vai ter uma pequena curva de aprendizado no gerenciador de pacotes, Pacman e Yay em vez de Apt ou Dnf, mas quando entenderem o AUR, nunca mais vão querer outra coisa. Tem literalmente tudo que você precisa, sem ter que lidar com repositórios de terceiros.

Demorei pra testar o Omarchy porque eu já usava Hyprland antes do Omarchy ter sido criado. O DHH já tinha o Omakub antes, que era um conjunto de scripts pra customizar um Ubuntu pra ser um bom ambiente de desenvolvimento. Eu gostava dele mas como preferia Manjaro, fiz um fork chamado Omakub-MJ. Depois disso resolvi desinstalar o GNOME e GDM e instalar um outro conjunto de scripts chamado ML4W, que deixa o Hyprland bem bonito também. Então o Omarchy não tinha tanta novidade, pra mim.

Só que eu uso o mesmo Manjaro já faz anos. Tinha um monte de configs e scripts velhos misturados. Meu Manjaro GNOME já não tinha mais GNOME. Meu Hyprland era Frankenstein. A única barreira era minha configuração de QEMU/Libvirt pra rodar Windows com GPU passthrough, que era o que eu usava pra editar videos quando ainda postava no meu canal do YouTube.

Mas como parei de editar videos, esse Windows também não é mais tão importante. Eu tinha outra máquina virtual Windows com GPU passthrough pra games. Mas atualmente tenho um mini-PC separado com Windows que uso só pra games. Também tinha outra VM com outro Linux só pros meus experimentos de I.A., mas desde então migrei pra rodar nativo isolando tudo com Docker. Ou seja, minhas VMs já não são mais importantes. Veja meus blog posts anteriores pra saber sobre I.A. em Docker.

Com o lançamento do Omarchy 2.0, parece uma boa hora pra reinstalar Arch do zero com Omarchy por cima e recomeçar com tudo limpo e bonito.

1 - Meu Setup

Cada caso vai ser diferente. Este post tem como principal função servir como minha referência pessoal pro futuro, se eu precisar reinstalar tudo de novo.

Não, não vou usar NixOS. Eu realmente não acho que compensa. Só vale a pena se você é administrador de sala de computador ou infraestrutura de servidores e seu dia a dia é ter que reconstruir setups idênticos de maneira confiável. Pra um usuário normal, que só vai reinstalar a cada 2 ou 3 anos, não vale nem um pouco a curva de aprendizado nem o trabalho de manutenção. É perda de tempo. Eu vou gastar dias aprendendo agora, terminar o setup, passar 2 anos e já vou ter esquecido tudo. Arch Linux sozinho já é estável o suficiente pra eu não precisar disso.

Meu setup ainda é o mesmo da época que estava editando videos pro canal. É um Ryzen 9 7850X3D com 16 cores, 32 threads, pico de 5Ghz. Ainda é um excelente CPU que tem poder de sobra pros meus usos, por isso não me vejo querendo atualizar tão cedo. São raras as vezes que eu consigo saturar tudo isso de core ao mesmo tempo nessas velocidades. Melhor ainda: ele tem GPU integrada AMD que torna instalar Linux mil vezes mais fácil do que se eu tivesse NVIDIA.

Mas, eu também tenho uma GPU discreta, separada, a NVIDIA RTX 4090 (não, não preciso de uma 5090, tem o mesmo tanto de VRAM). Ela vai ficar pra tarefas secundárias e não pra carregar meu ambiente gráfico. Coisas como render de Cycles no Blender, ou rodar LLMs com ollama da vida. Antes eu usava GPU passthrough pra uma VM em QEMU/Libvirt pra rodar Windows em parelelo ao Linux. Tanto pra editar video quanto pra games.

Como não edito mais videos, não preciso desse setup complicado então nem vou me preocupar mais em instalar Libvirt de volta. Se eu precisar de Windows, vou deixar em dual boot. Se precisar editar video, hoje em dia temos DaVinci Resolve Studio que roda nativo em Linux (mil vezes melhor que Adobe Premiere). Pra games eu tenho um mini PC separado com uma RTX 4060 ligado na minha TV. Melhor coisa é ter um PC totalmente separado pra games.

Então este setup é pra ser um Linux puro, com acesso ao meu NAS Synology DS 1821+ de 100TB. Única coisa extra que vou precisar é configurar mounts de NFS, como já detalhei neste outro post.

Um detalhe é que eu tenho 4 NVMEs neste PC. 2TB pro meu Linux antigo. 2 TB pro dual boot/VM de Windows. 2 TB só como drive de Steam e 1 TB pra coisas aleatórias. Como vou limar a VM de Steam, também não preciso mais dedicar um NVME inteiro só pra isso. Em vez disso vou fazer o diretório “/home” do novo Linux ser esses 2 TB inteiro.

Isso vai me permitir não me preocupar mais com Docker enchendo meu drive e travando meu sistema inteiro com falta de espaço. Da última vez eu tinha “resolvido” isso fazendo um drive remoto com iSCSI no meu NAS (que tem espaço infinito). Faz tirando minha VM de Steam vou ganhar 2TB então resolvo o problema localmente e com menos configurações.

RAM eu tenho de sobra, 96GB de DDR5. Com isso também não preciso me preocupar com partição de swap. Swap só é importante caso você tenha menos de 32GB de RAM, se estiver rodando muito Docker e ficar batendo no máximo de consumo de RAM muito rápido. Ou, se estiver usando notebook e quer ter a opção de hibernação (poder gravar a RAM em disco, dar power off completo na máquina e conseguir voltar depois exatamente de onde parou - que é diferente de suspender, que ainda usa energia).

Se quiser hibernar precisa ter um pouco mais do que o tamanho da sua RAM. Então se tem 32GB é bom deixar uma margem, uns 34GB ou mais de Swap. Como meu PC é desktop em casa, não preciso de hibernação, só ativar ZRAM pros raros casos onde tiver um pico acima de 96GB (que é ultra raro). Fora que é mais fácil eu simplesmente subir pra 128GB de RAM se precisar muito. Swap pra compensar RAM só vale a pena em notebooks que já não tem espaço pra mais RAM de verdade.

2 - Por que Omarchy?

Como falei, já sou usuário de Arch faz uma década e não vejo nenhum repositório de pacotes maior e mais completo do que o AUR. O único outro repositório que compete, de fato, é do NixOS. Mas como Nix está descartado pro meu caso de uso, o AUR continua imbatível.

Arch tem Pacman como gerenciador de pacotes. Pra acessar o AUR precisa de um segundo gerenciador. Existem vários como os antigos Pacaur, Paru e vários outros. Mas o melhor, na minha opinião, é o Yay. Ele tem exatamente a mesma sintaxe que o Pacman e substitui o Pacman. Na prática só usamos Yay pra tudo.

Pra procurar pacotes por nome é só fazer yay -Ss spotify.

Pra remover pacotes é só fazer yay -Rns spotify.

Pra atualizar todos os pacotes do sistema é só fazer yay -Syu

Pra remover pacotes órfãos que sobram ao longo do tempo é só fazer sudo pacman -Rns $(pacman -Qdtq)

E esses são os comandos que eu mais uso 99% do tempo.

Eu já usei tudo que é tipo de desktop manager, seja GNOME (que tem mais comportamento de Mac), KDE (que tem mais comportamento de Windows pra power users), XFCE (que baseado em GTK e é mais leve), Cinnamon (também baseado em GTK), i3 (que é sistema de tiling windows), Sway (como i3, também tiling mas se não me engano já foi feito pensado em Wayland).

Na prática, todo mundo usa aplicativos de dois jeitos: janela em tela cheia ou 2 janelas verticais dividindo o monitor no meio (editor de um lado, navegador do outro), ou 3 janelas (um editor vertical ocupando metade do monitor, um navegador ocupando 1/4 e um terminal ocupando outro 1/4). Daí organizamos mais apps abertos em desktops virtuais/workspaces. Esse é o jeito mais fácil de trabalhar.

Significa que poder arrastar janelas flutuantes é perda de tempo. Eu prefiro que as janelas já abram dimensionadas num desses layouts que falei acima. Dá pra configurar GNOME ou KDE pra fazer isso. Mas tem cheiro de gambiarra. Em vez disso realmente é melhor usar i3 ou Sway.

Deixando as controvérsias de lado (sim, tenho um pouco de pé atrás com Wayland e gosto da existência de XLibre). Mas é um fato que X11 ficou pra trás e é uma arquitetura muito velha e complicada. Wayland de fato tem um “appeal” melhor, apesar de ter demorado bastante pra arredondar coisas básicas como compartilhamento de tela (OBS, Zoom). Mas já faz alguns anos que uso Wayland sem ter dores de cabeça. Hoje em dia eu diria que está bem estável. Eu já usava GNOME sobre Wayland faz muito tempo. Eu não deixo de usar coisas por ter pé atrás: com tecnologia vou ser sempre absolutamente promíscuo e usar tudo.

Sabendo que vou usar Wayland e sabendo que quero layouts automáticos de janelas, e não preciso de janelas flutuantes, o melhor é um desktop manager com sistema de tiling windows (tiles são “azulejos” e estamos falando de azulejos ficarem lado a lado e nunca um em cima do outro), que organize as janelas lado a lado de forma inteligente e automática.

Nesse caso só temos 2 opções: Sway ou Hyprland (qualquer uma das duas é boa). O Hyprland, instalado do zero, é totalmente pelado, não tem absolutamente nada. Precisamos configurar tudo através de arquivos em .config/hypr. É até simples, mas dá trabalho.

A única opção boa que se tinha pra ter um Hyprland pré-configurado e bem feito era o ML4W, que eu já usava. Mas agora temos o Omarchy que justamente instala e pré-configura tudo pra funcionar redondo no Hyprland. Essa é a melhor opção que temos hoje em dia.

Além de já configurar Hyprland pra funcionar com Waybar, Rofi e outros componentes, ele tem um sistema próprio pra trocar temas e estilos e deixar o sistema com o “look and feel” que quiser (e todos que já vem nele são super bonitos), mas também já instala coisas que eu uso faz tempo como Neovim com o pacote LazyVim (na minha opinião, o jeito mais fácil de fazer o Neovim não deixar nada a desejar comparado a um VS Code), Mise (a melhor forma de organizar ambientes de desenvolvimento pra conseguir ter múltiplas versões da sua linguagem de programação favorita).

Se estiver instalando uma distro do zero, as únicas duas coisas que precisa ter são Mise e LazyVim. Além de Docker e LazyDocker. É o suficiente pra começar um ambiente de desenvolvimento produtivo. E o Omarchy já trás tudo isso pré-configurado. Ninguém “precisa” do Omarchy, mas ele já trás tudo integrado e bonito. Então, pra que me dar ao trabalho de fazer tudo do zero pra ficar quase igual?

Além disso, isso é Linux. Não gostou de 1 dos componentes? Só trocar.

3 - Faça Backup

A grande maioria de tudo que tenho já fica no servidor remoto, meu NAS Synology de 100TB. Isso já facilita muito. Mesmo assim ainda tem bastante coisa localmente no meu PC, então a primeira coisa a fazer é copiar tudo pro NAS. Se não tiver um NAS, então um HD externo. Qualquer coisa server, o importante é garantir que não vai perder nada antes de instalar um novo OS do zero.

Não esquecer diretórios como .config ou .local. Melhor fazer um rsync -avz --progress .config /mnt/nas/backup/, por exemplo, e copiar tudo. Mesmo o que achar que não vai precisar. Melhor copiar a mais do que faltar coisa. Via de regra, o ideal é copiar tudo que estiver na sua $HOME pra um drive externo ou NAS.

Só pra garantir que não vou esquecer nada importante, também vou gravar uma lista de todos os pacotes que tenho instalado no meu sistema antigo:

yay -Q > pacotes.txt
flatpak list > flatpak.txt

Também garantir que não vou perder configs velhas de serviços que eu fiz no systemd então também copiar tudo de /etc/systemd/system. Vale também gravar coisas como /etc/fstab. Também não esquecer de fazer backup de suas chaves de SSH com tar cvfz ssh.tgz ~/.ssh!!

Se como eu, usava QEMU/Libvirt pra VMs, é bom salvar as configs das máquinas virtuais que usava. Normalmente a ferramenta pra gerenciar VMs é o virsh então eu só fiz:

sudo virsh list --all
sudo virsh dumpxml <vmname> > <vmname>.xml

Se eu quiser recriar as máquinas no futuro, já vai estar tudo no backup. No meu caso mantenho todos os drives virtuais no meu NAS, mas caso os seus estejam locais, também precisa salvar esses arquivos que ficam em /var/lib/libvirt/images/

rsync -avh --progress /var/lib/libvirt/images/ /backup/libvirt-images/

4 - É difícil instalar Arch?

Arch, menos que um Gentoo, sempre teve reputação de ser a distro Linux mais brutal pra um iniciante instalar. Isso não é mentira, mas a verdade é que Arch é simultaneamente a distro mais difícil e também a mais fácil.

Baixe a ISO oficial e grave num pen drive (em Windows, usando Rufus ou Balena Etcher). Agora aperte F12 (depende da sua BIOS) ou configure na BIOS direto pra bootar do pen drive. Fazendo isso ele carrega o live environment do Arch que é literalmente cair numa linha de comando. Sem mais nenhuma ajuda.

A partir deste ponto tem que seguir o Wiki de Instalação do excelente ArchWiki e aprender a instalar um Linux do absoluto zero usando somente linha de comando, passo a passo, na tentativa e erro (mais errando do que acertando) e, ao final, você vai ter um “feeling” muito melhor de como uma distro Linux funciona de verdade.

Eu não fiz video de Arch mas fiz videos de Slackware pra explicar como um gerenciador de pacotes funciona. Também fiz um video de Gentoo pra mostrar como uma distro que compila tudo do zero funciona. E fiz um video de como o Boot do Linux Funciona pra entender onde fica a kernel e como ela é estruturada. Mas não fiz video de Arch porque sempre deixei como exercício pra iniciantes.

O jeito manual é viável, mas se está acostumado a um instalador gráfico, como o Calamaris, que tem na maioria das distros mais populares como Ubuntu ou Fedora, você vai ficar totalmente perdido. Mas aqui vem o bônus: não precisa passar por tudo isso pra ter um Arch Linux na sua máquina.

Pra isso existe o archinstall.

Quando bootar o pen drive do Arch e cair na linha de comando, basta digitar archinstall e pronto, só seguir o passo a passo que ele dá - que eu considero ainda mais simples do que Calamaris - e ele vai instalar e configurar tudo de forma automática pra você, do mesmo jeito que é instalar Fedora ou qualquer outra distro. Sério, não é pra demorar mais que 15 minutos.

O archinstall tem esta cara:

Basta entrar em cada um dos ítens da esquerda e preencher suas escolhas. Configure coisas como layout de teclado (normalmente eu escolho ‘us-acentos’). Edite o hostname da sua máquina. Escolha “NetworkManager” em configuração de rede (ele vai configurar tanto ethernet quanto wifi pra você), adicionar suporte a Bluetooth e Audio (escolha “Pipewire”). Escolha o tipo “desktop” em vez de “minimal” pra já ter os principais pacotes necessários pra um desktop. Escolha a timezone (“America/Sao_Paulo” no meu caso).

Recomendo também escolher a opção de Hyprland acho que em Applications ou Adicional Packages. Ele já vai instalar o SDDM pra ter um login gráfico.

Só tem duas opções que precisa de mais atenção: pra bootloader, muitos vão ficar tentados a usar um Limine, que é mais moderno e leve. Mas eu recomendo ainda usar GRUB, já explico porque.

A segunda opção importante é “Disk Configuration”. Não se preocupe, diferente de fdisk, ele é super intuitivo. Basta escolher o drive correto onde quer instalar (se tiver dual boot, cuidado pra não apagar seu Windows). Daí deixe ele fazer o layout automático das partições (só edite manualmente se tiver alguma necessidade muito especial). O mais importante, escolha BTRFS em vez do tradicional ext4.

Todo Linux sempre formata suas partições Linux com ext4, que é o mais antigo, mais estável e mais bem documentado file system. Hoje em dia eu recomendo BTRFS, é muito mais moderno, mais seguro (tem sistemas de proteção contra corrupção melhores), usa menos espaço (aprenda sobre CoW - Copy on Write), e o principal: tem suporte a snapshots baratos (pense o Apple Time Machine, só que melhor). Tem a maioria das funcionalidades de um sistema de arquivos dedicado pra servidor de arquivos mas muito mais simples e intuitivo de usar do que o monstro que é o ZFS (não recomendo pra usuários normais).

Ele tem algumas necessidades de manutenção que é bom ler no Wiki pra aprender. Mas no geral é plug and play, instala e esquece. Nas próximas seções vou mostrar algumas coisas que precisa saber, mas vai por mim: escolha BTRFS.

Eu sei que o Omarchy 2.0 tem opção de uma ISO pré-configurada que imagino que seja o Arch normal com archinstall e já o Omarchy por cima tudo de uma só vez. Mas eu não sei se eles permitem essa escolha por isso preferi ir direto no Arch puro antes. No final o efeito é o mesmo. Depois comentem abaixo se a ISO do Omarchy também tem as mesmas opções. Só garanta que no final tenha BTRFS. O futuro você vai te agradecer.

5 - HOME separada

Como expliquei antes, eu usava um dos meus 4 NVMEs pra ser o drive de Linux. Mas agora liberei outro NVME e quero mover minha $HOME pra lá e ter 2 TB dedicado só pra user space.

Não vou explicar como particionar e formatar esse outro drive. É simples: basta usar fdisk ou depois instalar Gparted que é a versão gráfica da ferramenta parted que dá pra usar pela linha de comando. São várias opções. O importante é só zerar minha partição antiga Windows e formatar também com BTRFS.

Cada um vai ter nomes de dispositivos e partições diferentes do meu. Pra saber quais são os seus use o comando lsblk. Veja o meu exemplo:

No meu exemplo nvme1n1 é o drive de 1TB pra coisas aleatórias. nvme2n1 é meu novo Arch Linux. nvme0n1 é o drive de dual boot de Windows antigo. nvme3n1 é o drive de Steam que formatei com BTRFS pra virar meu novo drive de HOME.

Se não entendeu, HOME é o diretório /home/akitaonrails. Ele vai ficar num drive separado. Depois que o archinstall terminar e eu bootar no novo Linux, é só fazer o seguinte:

sudo mount -t btrfs /dev/nvme3n1p1 /mnt
sudo btrfs subvolume create /mnt/@home
rsync -aAXHv /home/ /mnt/@home/
sudo umount /mnt

Isso vai montar a nova partição, daí usamos o comando “btrfs” pra criar um novo sub-volume chamado “@home” (de novo, leia o Wiki de BTRFS pra entender conceitos como sub-volumes).

Os comandos acima criam o sub-volume e copiam tudo que estava na HOME antiga pra nova. Agora precisamos que, no boot, o /home seja montado nessa nova partição. Pra isso precisamos saber o UUID dessa partição:

~ ❯ sudo blkid /dev/nvme3n1p1
/dev/nvme3n1p1: LABEL="HOME" UUID="84e9a1b7-a30e-...

O comando blkid devolve o UUID único de cada partição e, com isso, podemos editar o arquivo /etc/fstab usando sudo nvim ou sudo nano ou o editor que preferir:

# /etc/fstab
...
# /dev/nvme2n1p2
# UUID=da3aea43-...-aeaf8c7224d7 /home      btrfs      rw,relatime,ssd,discard=async,space_cache=v2,subvol=/@home 0 0

# /dev/nvme3n1p1
UUID=84e9a1b7-...-7a6a17fd0395 /home      btrfs      rw,relatime,ssd,discard=async,space_cache=v2,subvol=/@home 0 0
...

Veja como comentei a linha antiga que montava o /home e adicionei a nova linha com o novo UUID. O resto é tudo igual. E é só isso, basta bootar e a partir de agora meu /home vai montar no novo drive. Agora eu tenho 2 TB dedicados só pros meus downloads lixo kkkkkk 🤣

Mas não só isso, também tenho espaço pra coisas grandes como imagens de Docker ou modelos de LLM, sem correr o risco de encher o drive do sistema operacional e correr o risco dele não bootar mais por falta de espaço - como já me aconteceu várias vezes no passado. Sempre lembre de dar manutenção em Docker e LLMs e apagar coisas velhas.

Falando nisso, BTRFS tem suporte a snapshots. E um dos erros básicos é esquecer que diretórios de Docker ou LLM podem acabar nos snapshots e ficar ocupando espaço sem você saber. Pra evitar isso é melhor marcar esses diretórios pra não entrarem nos snapshots. Pra isso temos que dizer ao BTRFS pra ignorar esses diretórios.

A forma correta é criando subvolumes separados pra eles. Pra isso vou montar aquela minha mesma partição no drive separado onde montei minha $HOME:

~ ❯ sudo mkdir /mnt/temp
~ ❯ sudo mount -o subvolid=5 -t btrfs /dev/nvme3n1p1 /mnt/temp

~ ❯ ls /mnt/temp
 @home   timeshift-btrfs

~ ❯ sudo btrfs subvolume create /mnt/temp/@docker
Create subvolume '/mnt/temp/@docker'

~ ❯ sudo btrfs subvolume create /mnt/temp/@ollama
Create subvolume '/mnt/temp/@ollama'

~ ❯ sudo umount /mnt/temp

Agora é só editar o /etc/fstab pra montar corretamente igual fizemos com a HOME:

# /etc/fstab
...
# /dev/nvme3n1p1
UUID=84e9a1b7-...-7a6a17fd0395 /home      btrfs      rw,relatime,ssd,discard=async,space_cache=v2,subvol=/@home 0 0
UUID=84e9a1b7-...-7a6a17fd0395 /var/lib/docker      btrfs      rw,relatime,ssd,discard=async,space_cache=v2,subvol=/@docker 0 0
UUID=84e9a1b7-...-7a6a17fd0395 /var/lib/ollama      btrfs      rw,relatime,ssd,discard=async,space_cache=v2,subvol=/@ollama 0 0
...

Pronto, subvolumes limpos. Mais importante no meu caso: movi diretórios que tem tendência a crescer sem controle pra fora da partição do sistema operacional, tornando mais difícil acabar com um sistema inacessível por causa de falta de espaço. Faça a mesma coisa com outros diretórios parecidos com coisas como Kubernetes por exemplo. Qualquer coisa que fique baixando arquivos grandes, como imagens de sistemas.

Agora é só montar e trazer as coisas de volta:

# toda vez que edita o fstab, rode isso:
sudo systemctl daemon-reload

# crie os mount points
sudo mkdir /var/lib/docker
sudo mkdir /var/lib/ollama

# monte
sudo mount /var/lib/docker
sudo mount /var/lib/ollama

# copiar o conteúdo do diretório antigo de volta
sudo rsync -aHAX --inplace /var/lib/docker.old/ /var/lib/docker/
sudo systemctl start docker

Além de gerenciamento de espaço, qual a outra vantagem de fazer subvolumes separados? Porque a próxima seção vai ser pra tornar o sistema ainda mais robusto adicionando capacidade de snapshots e rollback pra snapshots do passado. E o ideal é tirar arquivos gigantes de snapshots que vão ficar no passado. Imagens de Docker são fáceis de recuperar: só dar docker pull de novo, não precisa fazer backup.

6 - Instalar Omarchy

Essa é a parte mais fácil. Quando terminar de instalar com archinstall, se escolheu a opção de Hyprland, vai aparecer o SDDM pra fazer login. E quando entrar você vai ficar chocado com quão cru é o Hyprland. Não dá pra fazer basicamente nada.

Pra isso não virar um dia inteiro de configuração na mão, usaremos o Omarchy. Clique “Super Enter” pra abrir o terminal e não ligue pra quão feio as coisas estão agora. Vai melhorar.

No terminal só faça isso:

curl -fsSL https://omarchy.org/install | bash

Só seguir as instruções na tela e deixar ele fazer o resto. E pronto, acabou, não tem próximo passo.

Recomendo MUITO que leia o MANUAL ONLINE DO OMARCHY que o DHH fez. É muito limpo, simples e direto. Todas as combinações de tecla, por exemplo, estão na seção HOTKEYS. Gaste uma hora lendo o básico pra conseguir operar. Mas a essa altura você já tem praticamente tudo que precisa: Alacritty como terminal, Chromium como navegador (pode instalar Brave se preferir, como é meu caso).

“Super Alt Space” abre o menu principal do Omarchy. “Super Space” abre o Rofi pra digitar o nome do app que quer abrir. “Super Enter” abre o terminal. “Super B” abre o navegador e assim por diante.

7 - Customizando Omarchy

O Omarchy é um Hyprland customizado. Podemos editar o que quisermos diretamente em ~/.config/hypr. E como eu estava acostumado com ML4W, resolvi mexer um pouco pra ficar bom pro meu setup. Seu setup vai variar dependendo das suas necessidades.

Logo que terminei de instalar Omarchy e tentei usar Gparted pra particionar aquele meu segundo NVME pra HOME, ele deu problema de autenticação. Não lembro se esta foi a solução mas é bom garantir que tenha Polkit instalado:

# make sure polkit + agent exist
sudo pacman -S --needed polkit polkit-gnome xorg-xhost

# Hyprland: export full env to systemd user bus once
dbus-update-activation-environment --systemd --all

Voltando, a primeira coisa que eu preciso resolver é que eu tenho 2 monitores. Um Asus 32" 1440p 144fps como principal e outro Samsung 24" 4K 60fps na vertical do lado esquerdo. A forma de configurar isso no Hyprland é editando um arquivo como ~/.config/hypr/monitors.conf que normalmente é carregado pelo ~/.config/hypr/hyprland.conf.

Em vez de fazer isso manualmente, prefiro instalar:

yay -S nwg-displays

Aqui eu configuro coisas como transform 90 graus pra girar o monitor vertical, scaling de resolução, suporte a 10-bits de cor, etc.

Ele vai salvar dois arquivos: ~/.config/monitors.conf e ~/.config/workspaces.conf. O Omarchy não carrega esse segundo arquivo então temos que editar em ~/.config/hypr/hyprland.conf pra ficar assim:

...
# Change your own setup in these files (and overwrite any settings from defaults!)
source = ~/.config/hypr/monitors.conf
source = ~/.config/hypr/workspaces.conf`
...

Já aproveitei pra adicionar algumas configurações extras nesse arquivo:

...
# animation
animations {
  enabled = yes
  bezier = easeOutQuint, 0.23, 1, 0.32, 1
  animation = workspaces, 1, 4, easeOutQuint, slide
  # optional extras:
  animation = specialWorkspace, 1, 4, easeOutQuint, slide
  animation = windows, 1, 4, easeOutQuint, popin 80%
  animation = fade, 1, 4, easeOutQuint
}

xwayland {
    force_zero_scaling = false # careful with mixing scaling wayland and x11
}

input {
  numlock_by_default = true
}

# dialogs/splash/utility ONLY
windowrulev2 = float,  xwayland:1, windowtype:^(dialog|splash|utility)$
windowrulev2 = center, xwayland:1, windowtype:^(dialog|splash|utility)$

# never center menus/tooltips
windowrulev2 = tile,   xwayland:1, windowtype:^(popup_menu|dropdown_menu|tooltip)$