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.

O problema de ter vários planos é acompanhar quanto já gastei de cada um. Eu vinha usando o claudebar, um widget de Waybar que mostra o uso do plano da Anthropic. Gosto dele, mas queria ver todos os meus vendors num lugar só, pra bater o olho e saber onde estou. E não queria encher minha Waybar de widget separado pra cada vendor. Então resolvi fazer o meu: o ai-usagebar.

É um port em Rust do claudebar, drop-in compatível, estendido pra quatro vendors: Anthropic Claude, OpenAI Codex/ChatGPT, Z.AI (GLM) e OpenRouter. Mantém os mesmos parâmetros (--icon, --format, --tooltip-format, etc.), o mesmo tooltip minimalista com borda Pango, e a mesma auto-detecção do tema do Omarchy. A diferença é que agora os quatro vendors aparecem no mesmo lugar, em vez de 865 linhas de bash cuidando de um só.

Como ele autentica em cada vendor

Essa é a parte que vale explicar, porque cada vendor faz diferente. Claude e Codex usam OAuth: os CLIs oficiais (claude e codex) já escreveram as credenciais no disco quando você logou, e o ai-usagebar lê esses mesmos arquivos. Não precisa de variável de ambiente nenhuma, o token até se renova sozinho.

Z.AI e OpenRouter usam API key, então pra esses você precisa setar uma chave (via env var ou inline no config).

A interface além da Waybar

Além do widget na barra, tem uma TUI com abas (ai-usagebar-tui) pra ver tudo de uma vez. Navega com Tab / h / l entre os vendors, atualiza a cada 60s. Dá pra abrir clicando no widget da Waybar, ou rodar direto no terminal (mais sobre isso na próxima seção).

A aba do OpenRouter mostra saldo de crédito, gasto de hoje / semana / mês e o tier:

E tem um overlay de settings pra escolher o vendor primário e colar as API keys sem editar o config na mão:

Não usa Omarchy nem Hyprland? Roda como TUI standalone

O widget de Waybar é opcional. Os dois binários são independentes, então se você não usa Omarchy, nem Hyprland, nem Waybar (ou simplesmente prefere checar o uso de vez em quando em vez de ter na barra o tempo todo), o ai-usagebar-tui funciona como app de terminal totalmente standalone:

ai-usagebar-tui    # abre no seu terminal atual

Roda em qualquer emulador de terminal (Kitty, Alacritty, Foot, Ghostty, etc.), funciona até numa sessão SSH pura, e não depende de compositor nem de feature de window manager. Todos os controles e o overlay de settings funcionam igual. Os mesmos quatro vendors, as mesmas abas:

Uso típico fora do Omarchy: uma checada rápida antes de começar uma sessão longa (“será que tô perto do limite semanal do Claude?”), um monitor num painel de tmux enquanto você programa, ou uma ferramenta só de shell em máquina remota (instala o binário e pronto, sem dependência de Waybar ou Hyprland). A TUI é a forma canônica de ver os quatro vendors de uma vez, independente de você configurar o widget ou não.

Instalação

No Arch tem pacote no AUR, dois sabores:

yay -S ai-usagebar-bin    # binário pré-compilado do GitHub Releases (~5s)
yay -S ai-usagebar        # compila do fonte (~30-60s)

Ou do fonte direto:

cargo build --release
sudo make install                  # → /usr/local/bin
# ou
make install PREFIX=$HOME/.local   # → ~/.local/bin

A config de Waybar recomendada é um único módulo com scroll pra ciclar entre os vendors, e clique pra abrir a TUI:

"custom/aibar": {
    "exec": "ai-usagebar --format '{vendor_short} {session_pct}% · {session_reset}'",
    "return-type": "json",
    "interval": 300,
    "signal": 13,
    "tooltip": true,
    "on-click": "ai-usagebar-tui",
    "on-scroll-up":   "ai-usagebar --cycle-next",
    "on-scroll-down": "ai-usagebar --cycle-prev"
}

Se preferir ver os quatro vendors ao mesmo tempo, dá pra usar um módulo por vendor. O README tem o detalhe completo de config, placeholders de formato, e as variações.

Por que fiz

Esse parecia um projetinho de sábado à noite, então resolvi só fazer. E foi: portar o claudebar pra Rust e adicionar os vendors extras que eu queria foi tranquilo. Saí de uma noite com um widget que faz exatamente o que eu precisava e ainda é mais confiável (testado, modular) do que o shell script original.

Se você usa outros vendors que eu não cobri, ou achar bug, manda issue ou pull request: github.com/akitaonrails/ai-usagebar. É MIT.

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.

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.

Felizmente, no mundo open source existem novas opções. O DHH resolveu trazer o OpenCode no Omarchy 3.x.

Depois que fiz o upgrade (rodar omarchy-update) vi que também veio a opção de instalar o que estou começando a usar agora, o CRUSH.

Crush é do mesmo pessoal que vem fazendo diversas bibliotecas pra facilitar desenvolvimento de TUIs (Terminal User Interface Apps), como o BubbleTea e Gum. Recomendo olhar esses repositórios também. É muito mais interessante fazer apps pra terminal, hoje em dia, especialmente ferramentas pra dev ou Linux em geral.

É um TUI muito bem feito. Essa é a cara dele:

Como primeira impressão, rodei no meu projetinho deste blog, que é um site estático gerado pelo Hugo.

Como eu já tenho variáveis de ambiente pra OpenRouter, nem precisei configurar nada. Só rodar crush no diretório do projeto.

A primeira coisa que fez foi analisar meu projeto. Como é pequeno, foi bem rápido. Não sei como lida com projetos gigantes. Mas sai vasculhando o código-fonte e no final anota tudo num arquivo AGENTS.md. E fiquei impressionado que fez um excelente trabalho em resumir o projeto, veja um trecho:

Eu nem sabia que tinha a opção de rodar scripts/dev.sh new-post pra automaticamente gerar o sub-diretório com timestamp pra um novo post. Eu estava fazendo manualmente toda vez 😅.

Eu sabia que meu script de scripts/generate_index.rb estava meio bagunçado então perguntei ao Crush se ele conseguiria refatorar:

No final ele refatorou bonitinho, sem introduzir novos bugs, sem reescrever coisas que não precisa. Melhorou muito mesmo refatorar só o que precisa. Mudou coisas como usar Dir.glob em vez de Find.find, trocou pra usar symbols em vez de strings (mais idiomático), etc.

Gostei que ele roda a versão modificada e checa se continua executando como deveria.

Segui pedindo pra fazer a mesma coisa com o scripts/dev.sh:

E nesse caso ele até encontrou um bug que eu não tinha percebido. Novamente, ele editou esse shell script pra deixar mais seguro, separou constantes, melhor checagem de erro, etc.

Este é o commit com as modificações. Dêem uma olhada. Ele realmente não colocou nenhum código desnecessário. Tudo continua funcionando como antes, mas agora está mais organizado. E ainda corrigiu um bug que eu não tinha visto.

Neste pequeno exemplo, escolhi usar o modelo Claude Opus 4.5. Todo o código foi gerado por ele. O Crush é só um Agente que usa o modelo e instrui com o contexto adequado.

Por enquanto só fiz coisas bestas e simples. Diz a documentação que ele integra com LSPs e MCPs pra ter ainda mais contexto sobre o código, mas não testei isso ainda.

De qualquer forma, resolvi fazer um post rápido só pra dizer que essas novas opções como Crush e OpenCode já estão muito boas pra usar no dia a dia. Vale a pena testar no seu projeto.

Segundo Teste

Como o Crush se deu bem com esse teste básico de web, resolvi pegar o desafio que fiz ano passado. Fiz um pequeno projeto de linha de comando que é um chat básico, feito do zero, usando direto a biblioteca llama.cpp, com CUDA, e em Zig - que é uma linguagem de baixo nível, ainda experimental e inacabada. Justamente o desafio é porque pouca gente usa, então tem pouca documentação e exemplos. A LLM vai ter que suar pra fazer funcionar.

Diferente de uma página Web com React e Tailwind - que tem milhares de posts em fóruns, tutoriais, blog posts e tudo mais, Zig não tem quase nada. O único app popular que eu conheço que usa Zig é o Ghostty.

Pra piorar, saiu versão nova recentemente, a 0.15, que muda bastante toda a API de IO (em preparação pra suportar melhor coisas como Async IO). Saiu versões novas de Llama, Cuda, etc. Então a idéia seria usar o Crush com Claude Opus pra ver se consegue refatorar, consertar bugs, atualizar as APIs e conseguir chegar até o ponto de compilar um binário que funciona.

Em resumo: conseguiu!

Na primeira rodada de refatoramento, consumiu só USD 5.64 de crédito da minha conta na Anthropic. Conseguiu pegar o macarrão monolítico (que eu fiz de propósito como desafio) em arquivos menores como chat.zig e llama.zig.

Conseguiu mapear as funções em C do Llama como funções no Zig. Conseguiu descobrir que coisas como ArrayList mudaram no Zig novo. Conseguiu descobrir que todas as APIs de IO mudaram no 0.15. E conseguiu modificar os lugares certos.

Ele foi rodando zig build, checando os erros e fazendo correções que fazem sentido, até conseguir gerar o binário final.

Vocês podem checar o Pull Request com tudo que ele fez. Foi uma mudança bem razoável e não deixou o projeto quebrado.

O fato dele ter conseguido consultar a documentação do Zig 0.15, também inferir corretamente quais funções novas do Llama.cpp deveria fazer extern, foi bem impressionante.

De qualquer forma, na primeira rodada, ele conseguiu chegar até o ponto onde compila. Mas não significa que funciona. E de fato, quando tentei executar, terminou com um segmentation fault:

Então pedi ao Crush pra executar e checar esse erro. Ele encontrou o bug e fez as modificações necessárias. Ele encontrou uma struct errada e ainda encontrou um problema de memory leak. Resolveu ambos os problemas e agora o programa roda como deveria:

Como disse antes, é um programinha besta de chat, que usa Llama.cpp direto pra carregar o modelo Qwen3 e abrir um chat pra eu conversar. É só um exercício porque um chat assim já existe, basta usar o Ollama. Mas eu queria fazer um do zero, em baixo nível, como exercício pra LLMs. Até ano passado nenhuma LLM que eu testei conseguiu finalizar esse programa de forma adequada. Mas agora foi.

E como podem ver, no final gastei quase 8 dólares pra refatorar, consertar os bugs, e fazer esse programa funcionar corretamente. Não foi barato, mas pelo menos não foram créditos jogados fora, como acontecia 1 ano atrás. Não testei com LLMs locais ainda, pra ver se o Crush consegue chegar em resultados semelhantes.

Mas se ele consegue lidar com uma linguagem obscura como Zig me deixa bem animado pra brincar mais com isso. Finalmente as ferramentas e LLMs chegaram num ponto que realmente é prático de usar. Não estou dizendo que resolve tudo, mas comparado com 1 ano atrás, foi um salto significativo.

Recomendo muito testar Crush com outros modelos. Eu só brinquei um pouco com o Opus mas outros modelos podem dar resultados diferentes dependendo do problema que está tentando resolver.

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.

Vou fazer somente este um artigo sobre isso e não pretendo cobrir mais do que a ponta do Iceberg. A idéia é servir pra quem está vindo de outros editores como Sublime Text ou VS Code e não consegue começar a navegar ou até mesmo quitar do Vim kkk 🤣.

Comandos Iniciais

Como falei no post anterior sobre LazyVim, vou assumir que já entendeu pelo menos como instalar suporte à sua linguagem com LazyExtras e já aprendeu a versionar usando Mise.

Sem nem entrar no LazyVim, a primeira coisa a saber é que ele instala todas as configurações relevantes no diretório ~/.config/nvim. Normalmente não precisa mexer nada lá. Deixa arquivos como lazyvim.json sem mexer. Notem que ele faz a mesma coisa quem um NPM da vida: tem um arquivo lazy-lock.json que declara a versão/commit de cada plugin instalado. O Lazyvim faz algo parecido com um npm install da vida. Só curiosidade pra você saber como ele se organiza.

Se precisar customizar algo, normalmente vai ser no diretório ~/.config/nvim/lua/config. Foi lá onde eu adicionei suporte a Mise, por exemplo:

~/.config/nvim
❯ cat lua/config/mise.lua
-- Prepend mise shims to PATH
vim.env.PATH = vim.env.HOME .. "/.local/share/mise/shims:" .. vim.env.PATH

Vão ser sempre scripts escritos em Lua. E nem precisa saber Lua a fundo. De bater o olho é uma linguagem muito simples, não muito diferente de um Python ou Javascript e qualquer programador deve ser capaz de ler qualquer trecho sem nenhum problema. Além disso, na maioria dos casos você vai copiar configurações que tirou da documentação, wiki ou chatgpt mesmo, então é só saber que as coisas vão nesse local.

Entenda que NeoVim tem o conceito de tecla “Leader”, é uma tecla que precede hotkeys pra outros comandos (também tem localleader que é barra invertida \). Isso é configurável mas no LazyVim o Leader é a tecla “Espaço/Space”. Em muita documentação vamos ver falando “apertem Leader-w”, que significa Espaço+w e agora você sabe o que isso significa.

Pra abrir um arquivo tem pelo menos 3 formas diferentes, 2 delas mostradas na foto acima:

Space+E abre o NeoTree que é esse sidebar na esquerda que se parece com o Windows Explorer. Dá pra navegar com teclado ou com mouse mesmo. Ache seu arquivo e pressione “Enter” pra abrir, daí “Space+E” de novo pra esconder o sidebar. Se quiser saber como criar um novo arquivo, um novo sub-diretório, renomear e tals, digite ? (tecla de interrogação) pra ver esta ajuda:

A terceira forma é manualmente com o comando :e seguida do nome do arquivo no diretório local. Tem auto-complete também, esse é o jeito mais rápido, se souber o que está procurando.

Sempre que quiser cancelar qualquer coisa ou fechar “floating windows” (pop-ups, dialog boxes). Só apertar “Esc”. Esc é fundamental no NeoVim.

Aberto um arquivo, ele fica no Buffer. Pense em Buffer como “Abas Abertas” no seu VS Code. Pra navegar por Buffer (tipo alt+tab entre seus arquivos já abertos) é simples:

• ]+b pra próxima “aba” (próximo Buffer)
• [+b Buffer anterior
• Space+bd pra “fechar a aba” (fechar o Buffer)
• Space+bo pra ficar onde está e fechar os outros buffers

Abra quantos arquivos quiser. Se um deles for um daqueles logs enormes que abriu por acidente, Space+bd pra fechar e pronto.

Falando em fechar, como que sai do NeoVim? Tem vários jeitos:

• Space+q
• :q
• :q!

A diferença: o primeiro é o jeito customizado no LazyVim. O Segundo é o jeito padrão usando o recurso de “comandos” que começa sempre com “dois pontos”. E o terceiro é se você modificou algo no arquivo mas cancelar, sair sem salvar nada, por isso a exclamação.

Normalmente eu uso :wq que significa “write” e “quit”. Então ele primeiro salva as mudanças no arquivo e depois já quita do programa. É útil quando estou só editando um arquivo de configuração rápido.

Navegação Básica

Agora tenho um arquivo aberto. Como navegar por ele? Primeiro, como ir até o fim do arquivo e depois voltar pro começo do arquivo? É uma coisa que uso bastante, só digitar Shift+g pra ir pro fim do arquivo e depois gg pra voltar pro começo. Simples assim.

Agora vamos aprender vários comandos de uma só vez:

• Digite v. Isso inicia o “modo de visualização” que, na prática, significa começar a selecionar a partir de onde se encontra seu cursor.
• Digite j. Que é o equivalente à “seta pra baixo” pra ir pra linha de baixo. Já deve ter ouvido falar que em Vim se navega com “hjkl” que são, respectivamente, pra esquerda, pra baixo, pra cima, pra direita.
• Digite x. Que é o equivalente a “cortar” e colocar o conteúdo no clipboard. Feito isso, digitando p você dá “paste”, que é colar.
• Digite u. Que é o comando que mais se usa: o de Undo ou desfazer a última modificação.

Isso tudo funciona no chamado “modo de comando”, que é o modo padrão que o Vim abre todo arquivo. Nesse modo não dá pra digitar nenhum texto. Como podem ver, cada letra sozinha é um comando, como “x” pra cut ou “p” pra paste.

Pra digitar, primeiro precisa digitar i (só a letra “i” em minúsculo), que daí muda do modo de comando pro “modo de edição”. Agora é só digitar seu texto normalmente, como em qualquer editor. Quando quiser algum comando, basta digitar ESC pra voltar pro modo de comando. Vamos fazer isso o tempo todo, por isso muita gente re-mapeia a tecla “caps lock” do teclado pra ser a ESC e ficar fácil só tocar com o mindinho esquerdo.

Combinando Comandos

Ainda no modo de comando, como navegamos pelo arquivo mais fácil?

Além das teclas “hjkl”, podemos navegar mais fácil usando b pra “palavra anterior” ou w pra palavra (word) posterior:

O modo de comando permite combinar comandos, portanto podemos fazer:

• dw pra apagar a próxima palavra
• db pra apagar a palavra anterior
• d4w pra apagar (delete) as 4 palavras (words) seguintes
• d4j pra apagar as 4 linhas pra baixo

O tutorial do Primeagen tem vários exercícios pra esse tipo de navegação, recomendo se exercitar. Num VS Code todo mundo está acostumado a primeiro pegar o mouse, marcar o bloco que quer apagar visualmente, depois apertar delete ou backspace. No Vim, olhamos onde está o cursor, apertamos ESC pra estar no modo de comando, e digitamos a operação e a localização. Teste todas as combinações que conseguir imaginar.

Esta é a mudança de paradigma que incomoda os preguiçosos. Mas uma vez aprendido isso, você vai achar incômodo um editor que te obrigado a usar mouse pra coisas básicas.

Agora fica mais interessante: e se em vez de apagar uma palavra, eu queira substituir a palavra onde meu cursor está pra outra palavra?

Num editor normal, você marcaria com o mouse (ou usando alguma combinação como “ctrl+shift+seta”), e digitaria por cima ou apagaria a palavra.

No LazyVim tem plugins configurados pra coisas mais interessantes. No video acima veja como estou substituindo palavras “in-place”. Isso se faz com o comando ciw.

• ciw apaga a palavra inteira embaixo do cursor e abre o modo de edição pra você digitar a substituição
• ce apaga a partir do cursor até o fim da palavra (preserva o começo da palavra) e também abre pra você digitar no lugar
• Shift-c (C maiúsculo) apaga tudo a partir do seu cursor até o fim da linha inteira e abre pra você digitar.

Mas isso ainda não parece tãaaaao legal. E se quiser mudar só a primeira letra de várias linhas ao mesmo tempo, por exemplo, no texto do video acima, quero mudar só o hífen ("-") de cada linha de tags?

Falei antes que apertando v no modo de comando ele começa o modo de visualização e dá pra selecionar a partir dali. Mas existe Ctrl+v que abre o modo de marcação de blocos verticais.

Nesse modo usamos as teclas “hjkl” normalmente, como j pra ir pra baixo, mas em vez de marcar a próxima linha inteira, ele marca só o caracter logo abaixo do seu cursor. Agora posso apagar com d e digitar Shift-i (“I” maiúsculo) pra entrar em modo de edição no começo do bloco e substituir pelo que quiser.

LazyVim tem plugins pra comentários, mas essa é outra alternativa se quiser adicionar “//” ou “#” no começo de várias linhas pra comentar, por exemplo. No caso, leia sobre o plugin ts-comments pra opções melhores pra comentário. Pra iniciar um novo bloco de comentário, digite gco pra adicionar um comentário abaixo.

“Modo de bloco” como mostrei acima, é uma das coisas que eu mais uso em código.

Mas só isso é muito pouco. E se quiser substituir TODAS AS PALAVRAS iguais do texto de uma só vez. No video de exemplo acima, quero substituir “domínio” por “DOMAIN” e “Cloudflare” por “AWS Amazon”, como faço? Isso é “Search and Replace” que tem em todo editor e em Vim é muito fácil:

Digitamos :%s/domínio/DOMAIN/.

Se você é programador já deve ter visto essa sintaxe antes. É a sintaxe de REGEX MATCH. Sim, tem que saber Regex (e não, não é nem PCRE e nem Unicode, é um dialeto de Regex do próprio NeoVim, mas é parecido).

Como falei antes, “dois pontos” abre o box de digitar comandos, "%s" inicia “search com regex” e entre as barras “//” primeiro vai o que procura e depois com o que quer substituir.

Mas esse é o jeito no NeoVim puro, no LazyVim, tem o plugin grug-far e se ativa com o comando SPACE+sr:

Agora sim, mais parecido com do VS Code, né? Use o que achar mais fácil.

Conclusão

Como falei, isto é somente a ponta da ponta do iceberg, o mínimo do mínimo suficiente pra pelo menos começar editando arquivos simples de configuração sem abrir Nano ou VS Code só pra isso.

Leia a documentação do LazyVim. Veja os keymaps pra descobrir outros comandos. Preste atenção em cada letra que aperta no modo de comando, o LazyVim mostra as opções disponíveis. Por exemplo, digamos que eu apertei g (goto), ele vai mostrar uma ajuda no canto inferior direito:

Assim você sempre pode descobrir novos comandos ou relembrar comandos que usa pouco. Por isso recomendo o LazyVim, que já vem bem configurado pra te ajudar. Quem faz essa funcionalidade é o plugin which-key, caso queira a mesma coisa num NeoVim que você configurou do zero.

Existem diversos Cheatsheets por aí com tabelas de combinações de comandos importantes. Vale explorar.

Mas não é só isso, LazyVim vem com dezenas de plugins pra formatação, linting, LSP integrado, GIT integrado, e muito mais. Não tem como eu documentar um a um aqui. Cada um deles tem sua própria documentação na página de plugins do LazyVim.org.

Novamente, não esqueça de chamar o :LazyExtras e instalar os plugins opcionais das suas linguagens.

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.

Mais importante: ter uma senha forte, aleatória, exclusiva e diferente para CADA site, app ou serviço que usa. Nunca, jamais, reusar uma senha. Por que? Porque todo dia um desses sites é invadido e as senhas são vazadas. Se você procurar por você mesmo no site Have I Been Pwned certamente vai achar contas suas que já vazaram. E se você compartilha essa mesma senha com 10 outros sites, alguém já deve ter entrado na sua conta a essa altura.

Assista meu video sobre segurança:

Ter preguiça de usar um gerenciador de senhas é só uma desculpa idiota de gente preguiçosa. E um programador sequer tem direito de usar essa desculpa.

Omarchy 1Password

Quem acompanha o DHH desde os primórdios de quando Macs eram a melhor plataforma pra desenvolvedores, lembra que ele sempre foi fã do 1Password, um dos que funcionava melhor em iPhones.

Eu migrei de volta pra Android e Linux muitos anos atrás, em 2015. Eu usava 1Password, mas em Android o app era tenebroso de feio de ruim de usar. Por isso desisti dele e fiquei migrando entre vários outros apps. Seja Google Authenticator, seja Lastpass (que não recomendo).

Sei que tem diversos outros open source que as pessoas preferem, mas eu acabei caindo no Bitwarden, que é BONITO tanto em Android como a extension pra navegadores. Além disso ele tem componentes abertos e permite self-hosting.

Mais do que isso, ele não dificulta que você exporte todos os dados da sua conta e importe em outro lugar. Diferente de apps como o Twilio Authy, que te bloqueia de tudo e por isso deixei de usar.

Bitwarden tem gerador seguro de senhas aleatórias, tem suporte a 2FA TOTP, dá pra armazenar anotações (tipo mini textos) seguras e muito mais. Os apps integram com biometria do celular, então é bem conveniente de usar.

Ainda mantenho meu Bitwarden dentro do Secure Vault da Samsung, o Samsung Knox Vault. Então são 2 níveis de segurança. E quando preciso andar em algum lugar suspeito, não levo meu celular principal, só um burner-phone sem nada de importante logado.

Olhem como é bonito. Eu gosto dele e uso já faz alguns anos. Minhas senhas variam entre 21 a 42 caracteres aleatórios, um diferente pra cada site. Eu atualizei todas as senhas de tudo mais de uma vez nos últimos anos, e todas as contas tem 2FA/TOTP cadastrado no Bitwarden também, assim consegui sair do Authy.

Instalando VaultWarden Self-Hosted

Mais importante, chegou a hora de hostear meu próprio servidor de Bitwarden, o vaultwarden que é uma alternativa open source, código aberto no GitHub, então você mesmo pode fuçar pra aprender ou até contribuir com ele. Novamente, subo tudo com Docker Compose no meu Home Server, então só precisei adicionar este trecho no meu arquivo:

  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://bitwarden.fabioakita.dev"
      SIGNUPS_ALLOWED: "false"          # set to true only to create first user
      WEBSOCKET_ENABLED: "true"
      ADMIN_TOKEN: "iA...Q9"  # for /admin
      # SMTP (recommended)
      SMTP_HOST: "smtp.gmail.com"
      SMTP_PORT: "587"
      SMTP_SECURITY: "starttls"
      SMTP_USERNAME: "boss@akitaonrails.com"
      SMTP_PASSWORD: "xxx"
      SMTP_FROM: "boss@akitaonrails.com"
    volumes:
      - /home/akitaonrails/vaultwarden/data:/data
    ports:
      - "9999:80"
    healthcheck:
      test: ["CMD", "wget", "-q", "-O", "-", "http://localhost/health"]
      interval: 30s
      timeout: 5s
      retries: 5

Importante:

• Crie um ADMIN_TOKEN longo e aleatório. Use o próprio Bitwarden pra isso, mantenha secreto.
• Mude SIGNUPS_ALLOWED pra true somente uma vez, entre no site local e crie sua nova conta. Depois mude no arquivo pra false, reinicie o container. Dessa forma ninguém mais poderá criar nenhuma nova conta.
• É recomendado configurar um GMAIL SMTP pra mandar emails de notificações. Pra isso precisa criar uma senha de aplicativo no Google.

Pra criar uma senha exclusivamente pro vaultwarden, acesse Google App Passwords e gere uma nova senha secreta exclusiva:

Ele só vai mostrar essa senha uma única vez. Copie e cole direto no yaml do docker compose. Configurando e-mail bonitinho, toda vez que alguém fizer login, ele manda um e-mail notificando. Isso é bom pra ter certeza que não tem ninguém suspeito mexendo no seu servidor:

Agora só preciso subir o container:

docker compose -f utils-docker-compose.yml up -d

Roteando túnel do Cloudflared

Como já mostrei no post de Cloudflared agora quero poder acessar remotamente, via túnel seguro, usando uma URL pública como https://bitwarden.fabioakita.dev. Pra fazer isso temos que editar aquele arquivo /etc/cloudflared/config.yml e adicionar no final dele assim:

  - hostname: bitwarden.fabioakita.dev
    service: http://192.168.0.200:9999
    originRequest:
      httpHostHeader: bitwarden.fabioakita.dev
      http2Origin: true
  - service: http_status:404

Depois temos que reiniciar o serviço e também adicionar a rota manualmente:

sudo cloudflared tunnel route dns homelab bitwarden.fabioakita.dev
sudo systemctl restart cloudflared

E pronto! Talvez demore até 5 minutos pros DNS sincronizarem e tudo mais, mas daí é só entrar no seu navegador e vai ver isto:

Se aquele SIGNUPS_ALLOWED estiver true também vai ter um link pra “Criar nova conta”. No meu caso eu já fiz isso e desliquei, então só tem login mesmo.

Importando seus Dados

Antes de continuar, vamos abrir a extension do Bitwarden - que continua logado na versão cloud em bitwarden.com e exportar todos os meus dados:

Basta se autenticar, daí na barra inferior de ícones vai ter “Settings”, depois “Vault Options” e, finalmente “Export vault”. Deixe o padrão no formato JSON mesmo (vai ser um JSON encriptado) e faça download desse arquivo pra algum lugar seguro.

Agora podemos logar de volta na nossa versão self-hosted em https://bitwarden.fabioakita.dev e seguir pelo mesmo menu, mas escolher “Import”:

E pronto! Agora minha versão self-hosted está idêntica à versão cloud que vinha usando até agora.

Logando no novo servidor self-hosted

Agora basta deslogar tanto do App mobile quanto da extension do navegador. Daí na tela de login vai ter a seguinte opção:

Na extension web a janela não deixa ver essa opção, use o scroll do mouse e scrole até o fim da janela e vai ter essa opção pequena. Escolha “self-hosted” e vai abrir uma janela pra digitar a URL https://bitwarden.fabioakita.dev e pronto!

A partir daqui o uso é exatamente o mesmo de antes. A interface é a mesma, as opções são as mesmas. Configure biometria, PIN, timeout pra lock e tudo mais pra deixar do jeito que você gosta.

Faça a mesma coisa no app mobile e pronto!

Nessa nova conta que criamos no servidor self-hosted, não esqueça de habilitar 2FA também, que é a opção “Authenticator App” em “Settings/Security”:

Pra todas as outras contas, podemos registrar o 2FA dentro do Bitwarden. Mas pra conta master do próprio Bitwarden/Vaultwarden, precisamos usar um segundo app só pra isso.

Não sei se é o melhor, mas eu tenho gostado de usar o Aegis Authenticator no meu Android:

É open source, o código está no GitHub, então parece minimamente confiável. Também deixo ele dentro do Samsung Knox Vault. Só preciso dele quando preciso re-logar no Bitwarden/Vaultwarden. Pra logar nos Google, Steam ou qualquer outra conta, o 2FA de cada uma está dentro do Vaultwarden mesmo:

Conclusão

Agora só faltou mesmo me logar com minha conta antiga em bitwarden.com, que é a versão “oficial” no cloud e deletar minha conta, pra garantir que ninguém mais tenha acesso.

E pronto, PERMANENTEMENTE APAGADO! Não existe mais minhas contas num servidor qualquer que eu não controlo, mesmo que fosse encriptado.

Estou bem contente com esta solução. Agora meu Vaultwarden está num container, os dados do home server tem backup automático pro meu NAS, tudo é encriptado e só tem acesso via túnel seguro da Cloudflare. O risco é bem baixo e ninguém tem chance de ter acesso aos meus dados, porque eles não estão mais no “cloud”.

Meus dados são somente meus.

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.

Mas não precisa usar estes menus. Vamos entender.

Num Arch Linux ou Ubuntu da vida, um amador instalaria ruby ou python fazendo algo assim:

# arch
yay -S ruby python3
# ubuntu
apt install ruby python3

Este é o jeito ERRADO.

Esses comandos vão instalar a versão mais nova de cada linguagens e toda vez que atualizar o sistema com yay -Syu ou apt upgrade, vai puxar as versões mais novas ainda.

Só que se você desenvolve projetos de verdade, não quer que as versões mudem.

A versão do deploy no servidor no cloud e a versão na sua máquina local TEM QUE SER AS MESMAS.

Se está usando Ruby v3.0.7 e Node.js 22.19.0, não pode ficar refém que quando atualizar seu sistema, do nada vai aparecer Ruby 3.4.5 e Node 24.7.0. Tudo vai começar a quebrar e você vai ficar super confuso sem saber porque. Esse é o erro mais primário que um júnior comete.

Pra evitar isso, cada projeto que está trabalhando PRECISA ESTAR TRAVADO EM VERSÕES FIXAS.

O jeito mais fácil de fazer isso em 2025 é usando MISE. Como falei, ele já vem instalado e ativado no Omarchy, mas se estiver usando outra distro basta instalar Mise manualmente:

yay -S mise

# .bashrc
eval $(mise activate bash)

Adapte isso pra ZSH, Fish ou outro shell que estiver usando, leia a documentação

Agora navegue pro diretório do seu projeto, por exemplo:

cd ~/Projects/AkitaOnRails.com

E trave as versões:

mise use ruby@3.2.3
mise use node@14.21.3

Isso vai criar o arquivo .tool-versions que você deve adicionar no git do seu repositório:

❯ cat .tool-versions
ruby 3.2.3
nodejs 14.21.3

❯ git add .tool-versions

E pronto, toda vez que fizer cd pro diretório, o Mise vai ativar exatamente a versão correta pra esse projeto. Veja:

AkitaOnRails.com [ master][$!?⇡][ v24.7.0][💎 v3.2.3]
❯ ruby -v
ruby 3.2.3 (2024-01-18 revision 52bb2ac0a6) [x86_64-linux]

AkitaOnRails.com [ master][$!?⇡][ v24.7.0][💎 v3.2.3]
❯ which ruby
/home/akitaonrails/.local/share/mise/installs/ruby/3.2.3/bin/ruby

Note que, se estiver usando o prompt Starship como expliquei no post anterior, com um preset como Pure Prompt, ele mostra no prompt as versões de cada linguagem pra que fique fácil de ver se estiver numa versão errada.

No caso, se leu com atenção, já deve ter notado que SIM, ESTOU NA VERSÃO ERRADA do Node.js. Olhem como no prompt ele fala que estou usando Node 24.7.0 mas no arquivo .tool-versions ele pede 14.21.3.

O motivo de estar “missing” é porque esta máquina é recém-instalada, mas o projeto é velho.

Então vamos checar:

AkitaOnRails.com [ master][$!?⇡][ v24.7.0][💎 v3.2.3]
❯ mise list
Tool    Version            Source                                              Requested
go      1.25.0             ~/.config/mise/config.toml                          latest
node    14.21.3 (missing)  /mnt/data/Projects/AkitaOnRails.com/.tool-versions  14.21.3
node    22.18.0
python  3.13.7
ruby    3.2.3              /mnt/data/Projects/AkitaOnRails.com/.tool-versions  3.2.3
ruby    3.4.5

Veja como na listagem de mise list ele fala que 14.21.3 está “missing”. Então vamos instalar:

AkitaOnRails.com [ master][$!?⇡][ v24.7.0][💎 v3.2.3]
❯ mise use node@14.21.3
mise /mnt/data/Projects/AkitaOnRails.com/.tool-versions tools: node@14.21.3

AkitaOnRails.com [ master][$!?⇡][ v14.21.3][💎 v3.2.3]
❯

Com o comando mise use podemos pedir pra instalar e usar uma versão em particular. Se já não estiver instalado, ele vai instalar. Note como depois disso o prompt do Starship mudou pra refletir que agora estamos usando 14.21.3. Esse é o jeito certo.

Se não estiver necessariamente num diretório de projeto com versões travadas, ainda assim é possível rodar comandos usando uma versão específica, assim:

mise exec ruby@3.2.1 -- ruby ...

Digamos que queira gerar um projeto de Rails numa versão específica de Ruby:

mise exec ruby@3.2.3 -- rails new todo-exercise

Mesma coisa vale pra generators em Node, como Next.js ou qualquer outro framework.

Não chequei se o LazyVim no Omarchy já vem configurado assim, mas caso não venha, pro NeoVim suportar Mise precisa adicionar isso:

-- Prepend mise shims to PATH
vim.env.PATH = vim.env.HOME .. "/.local/share/mise/shims:" .. vim.env.PATH

Basta colocar isso em ~/.config/nvim/lua/config/mise.lua que ele deve carregar o path correto. Pra integrar com outros editores, cheque esta documentação. Tem um MONTE de opções avançadas que é bom ler a respeito na seção de Dev-Tools mas o básico é o que listei aqui.

E bancos de dados??

O mesmo vale pra bancos de dados. Cada projeto deve estar travado numa versão específica idêntica à que está rodando no servidor de produção e nunca deve depender dos pacotes do sistema operacional. Dá pra usar mise pra isso mas o mais recomendado é usar Docker. Cada projeto DEVE ter um docker-compose.yml pra subir somente os bancos de dados. Não precisa subir containers pra linguagens, pra isso é melhor usar Mise.

Se não entende Docker, eu fiz videos ensinando:

Somando Mise + Docker Compose + LazyVim, é tudo que se precisa pra ser um desenvolvedor web produtivo, além de usar os recursos da sua máquina de maneira eficiente. Todo desenvolvedor PRECISA aprender este combo de opções. Omarchy já trás tudo pré-instalado, por isso tem sido minha recomendação pra todo iniciante.

Não precisa se preocupar: Arch Linux (com archinstall), é tão fácil de instalar quanto um Ubuntu ou Linux Mint e o Hyprland do Omarchy é muito mais bonito e fluido que um MacOS. O melhor dos mundos. Aprenda hoje!

Mesmo se não usa Omarchy, recomendo instalar LazyVim, só fazer isso:

# required
mv ~/.config/nvim{,.bak}

# optional but recommended
mv ~/.local/share/nvim{,.bak}
mv ~/.local/state/nvim{,.bak}
mv ~/.cache/nvim{,.bak}

git clone https://github.com/LazyVim/starter ~/.config/nvim

rm -rf ~/.config/nvim/.git

nvim

Pronto, é só isso. NeoVim, pra quem não sabe, é um fork mais moderno do antigo Vim (por isso o comando é nvim, reservando vim pro antigo). Ele troca o antigo VimScripts por scripts em Lua e tem várias otimizações e funcionalidades de qualidade de vida melhores. Hoje em dia, não tem porque usar o Vim antigo mais.

Usando Lua dá pra configurar o Nvim como quiser. Mas dá muito trabalho configurar tudo do zero. É um bom exercício, mas sendo prático, não compensa pro dia a dia. É melhor instalar um setup pré-configurado como os antigos LunarVim que eu usava antes e até recomendei em alguns videos de Linux do meu canal, ou o AstroNvim ou o LazyVim que atualmente é meu favorito. Qualquer um deles é um bom começo e vai ser preferência pessoal qual vai escolher.

Cada plugin que eles instalam tem diversas funcionalidades e combinações de teclas (hotkeys) próprias que precisa ler na documentação pra saber o que faz o que. Recomendo ir na seção plugins do site oficial e ler um por um. Tem muita coisa que você nem espera e todos são muito úteis.

LazyVim sozinho já ajuda bastante porque ele abre pop-ups documentando algumas das hotkeys. Por exemplo, o que se chama de comando Leader em LazyVim é a “barra de espaço”. Quando apertar, vai aparecer esse menu de contexto:

A partir daqui, se digitar, digamos “b”, vai aparece outro menu de contexto:

E se digitar “b” de novo, ele vai trocar pro próximo arquivo já aberto no Buffer. Buffer é o nome em Vim onde ficam os arquivos já abertos. Deletar do Buffer é o equivalente a “fechar o arquivo”.

Da próxima vez, não precisa olhar os menus, só digitar rápido de uma só vez: “Espaço+b+b”. E é assim que você vai decorando os comandos que mais usa.

Alguns comandos que vale a pena já saber são: Espaço+Espaço" (duas vezes), e vai abrir o menu que abre arquivos. digite algumas letras do nome do arquivo e vai filtrando dinamicamente:

Ou então “Espaço+e” pra abrir o Explorer NeoTree. Digite “?” pra abrir um popup com os comandos que pode usar pra criar novos sub-diretórios ou arquivos no subdiretório:

Quando aprender os demais comandos e plugins, vai notar que nem precisa abrir NeoTree, ele é mais pra quando quiser explorar visualmente mesmo. Mas pro dia a dia comando como “:e” devem ser suficiente. Aliás, “:” (dois pontos) é o comando pra executar funções do NeoVim. Por exemplo “:q” é quit, ou “:w” é write e “:wq” é write e quit ao mesmo tempo.

Se quiser aprender mais a fundo sobre NeoVim, recomendo o canal do YouTube do camarada Eustáquio Rangel que é veterano de Linux, Rails e Vim e ele ensina NeoVim do zero (sem LazyVim).

Agora, digamos que já aprendeu o básico de NeoVim e LazyVim, e agora quer começar a mexer nos seus projetos de PHP, Java, C#, Ruby, Python ou o que for. Vai notar que o LazyVim não tem nenhuma funcionalidade pra nenhuma delas.

O que fazer agora? Instalar VS Code?? NÃO!!

Isso porque você não executou :LazyExtras.

Digite exatamente assim e veja isto:

Essa janela parece complicada mas é só uma lista de plugins dividida em seções. No começo aparecem os plugins já instalados e habilitados. Caso não queira algum deles, basta usar as setas pra descer o cursor até uma delas e apertar “x” pra desmarcar. Mas deixe essa seção como está. Vamos descer até a seção de “Languages”:

É nesta seção que estão todas as linguagens que você pode habilitar o suporte. Basta descer com as setas e ir marcando com “x” quais quer instalar. E tem de tudo, desde Angular, Vue, Erlang, Elixir, Rust, Zig, Haskell e muito mais.

Ao lado de cada linguagem tem o grupo de plugins individuais que ele vai instalar. Pra saber o que cada uma faz, digite o nome delas no Google e ache a página com a documentação, onde vai ter hotkeys e configurações extras que pode fazer.

Com isso vai ganhar coisas como Linters, syntax highlighting, LSP, snippets e muito mais.

E se quiser instalar plugins a mais que não tem listado, dá pra adicionar manualmente. Leia a seção de Adding Plugins na documentação.

LazyVim + LazyExtras é 90% de tudo que precisa pro seu dia a dia de desenvolvimento de software. É mais leve e mais rápido que um VS Code, usando muito menos memória e vai ser muito melhor especialmente em máquinas mais antigas. Não tenha preguiça de aprender Vim, um programador de verdade não deveria ficar num VS Code só porque tem preguiça de aprender hotkeys extras.

Se quiser mudar pra ZSH, é fácil, só fazer isso:

yay -S zsh zoxide
chsh -s $(which zsh)

Logout, login e pronto. Mas agora seu shell vai estar vazio. Pra baixar minha config faça isso:

git clone https://github.com/akitaonrails/omarchy-zsh.git ~/.config/zsh
ln -s ~/.config/zsh/.zshrc ~/.zshrc 

Tem duas coisas que precisa modificar. Em .zshrc remova esta linha:

source ~/.config/zsh/mounts

Isso é só pra eu checar meus mounts de NFS pro meu NAS. Pra você não serve pra nada então pode tirar.

A segunda coisa é criar um novo arquivo para segredos:

touch ~/.config/zsh/secrets
chmod 600 ~/.config/zsh/secrets

É nele que vai colocar coisas como suas chaves de OpenAI ou Google Cloud ou qualquer coisa assim. Por exemplo:

# ~/.config/zsh/secrets
export OPENAI_API_KEY="sk-xx-v1-xxx...xxxxx"

Assim seus segredos ficam separados das suas configurações e podemos dar git push pra um repositório sem se preocupar que algo possa vazar no futuro. Sempre mantenha segredos, senhas, chaves, separados localmente. Isso já está no .gitignore então está seguro.

De bônus, no ~/.config/init adicionei suporte ao Atuin que é uma ferramenta que serve pra sincronizar todo histórico de comandos que fez no seu shell pra um repositório no “cloud” (leia a documentação, você pode criar seu próprio server local também). O repositório é encriptado, então não é inseguro, mesmo se seu histórico contenha chaves secretas nos comandos.

Instale assim:

yay -S atuin
atuin register -u <seu username> -e <seu email>
atuin import auto
atuin sync

Logo que registrar o Atuin vai gerar uma chave de encriptação aleatório. Garanta que guardou essa chave num lugar seguro como 1password, Bitwarden ou outro cofre seguro!! Sem ela não vai conseguir decriptar numa nova instalação. Se esquecer, ainda dá pra ver antes de reinstalar, por exemplo:

atuin key

Se reinstalar sua máquina ou instalar uma nova máquina e quiser seus históricos de volta, basta instalar o Atuin e fazer:

atuin login -u <seu username>
atuin sync

Ele vai pedir sua senha e chave de encriptação e trazer todo seu histórico de volta.

Segundo minha config, basta digitar Ctrl+R pra chamar a procura do histórico (que a partir de agora vai estar num sqlite na sua máquina). Leia a documentação pra mais funcionalidades.

O DHH configurou o prompt do Starship usando o jeito antigo de variável PS1. Mas o Starship já tem vários prompt bem bonitos fáceis de usar como “presets”. Eu escolhi o Pure Prompt, que eu gosto, mas tem vários outros. Se gostar de algo mais chamativo e colorido, tem este Pastel Powerline:

Escolha o de sua preferência na página de Presets e mude em ~/.config/zsh/prompt no lugar desta linha:

starship preset bracketed-segments -o ~/.config/starship.toml

Por fim, eu deixei alguns ENVs em ~/.config/zsh/envs que funcionam pros meus testes de Ollama e coisas assim, mas é bom você saber que estão lá pra não achar estranho se seu Ollama estiver se comportando estranho, edite o arquivo ~/.config/zsh/envs pra ter os envs de sua preferência:

# envs
export OPENAI_API_BASE="https://openrouter.ai/api/v1"
export DEFAULT_MODEL="o1-mini";
export OLLAMA_API_BASE=http://127.0.0.1:11434
export OLLAMA_HOME=http://127.0.0.1:11434
export OLLAMA_MODELS=/mnt/gigachad/ollama/models

Também modifique o arquivo ~/.config/zsh/aliases pra ter alias que você prefira:

# aliases
alias monhd="sudo ddcutil -d 1 setvcp 60 0x12"
alias mondp="sudo ddcutil -d 1 setvcp 60 0x0F"

alias sgpt='docker run --rm -e OPENAI_API_BASE=${OPENAI_API_BASE} -e OPENAI_API_KEY=${OPENROUTER_API_KEY} ghcr.io/tbckr/sgpt:latest txt '

alias git='nocorrect git'
git config --global alias.a 'add'
git config --global alias.ps 'push'
git config --global alias.pl 'pull'
git config --global alias.l 'log'
git config --global alias.c 'commit -m'
git config --global alias.s 'status'
git config --global alias.co 'checkout'
git config --global alias.b 'branch'

Os primeiros dois aliases são pro meu setup de 2 monitores onde um dos monitores recebe sinal tanto da entrada HDMI quanto da entrada DisplayPort (tenho 2 GPUs). Se não sabia, dá pra controlar isso usando o shell. Leia este post sobre ddcutil

Em seguida você ganha o comando sgpt. Omarchy já trás Docker instalado. Agora no shell você pode perguntar ao ChatGPT sem precisar ficar abrindo um navegador web pra isso:

sgpt "qual é a sintaxe de rsync pra sincronizar dois diretórios?"

Leia documentação do SGPT pra saber outras funcionalidades ou quais LLMs você pode escolher.

No final temos aliases pra Git. O Omarchy já tem alias pra fazer “g” ser “git” e com este que eu adicionei você pode fazer:

git add . # antigo
g a . # novo

git commit -m "initial commit" # antigo
g c "initial commit" # novo

git commit --amend -m "initial commit"
g ca "initial commit"

git push origin master
g ps origin master

git pull origin master
g pl origin master

git log
g l

# e assim por diante

Mais prático e menos verbose. Adicione mais aliases conforme seu workflow em ~/.config/aliases.

E acho que é isso, agora sim, meu Omarchy está organizado do jeito que eu gosto. Faça suas próprias configurações pra tudo ficar do seu jeito também!

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)$

Tem gente que não gosta mas eu gosto de ter uma animação rápida quando mudo de um workspace pra outro, por isso adicionei o bloco animations.

Quando se usa aplicativos feitos pra X11, eles vão rodar em cima do XWayland. Uma coisa chata é que alguns deles abrem “dialog boxes”, que são janelas flutuantes. E eles podem acabar em lugares difíceis de clicar, especialmente num setup com múltiplos monitores. Por isso adicionei blocos como xwayland e regras windowrulev2 pra forçar esses dialog boxes a sempre aparecerem centralizados na tela.

FInalmente, eu tenho um teclado numpad da 8bitdo conectado via Bluetooth, mas ele não liga com numlock carregado. Pra corrigir isso tem esse bloco input.

Voltando ao layout de monitor. Depois que o nwg-displays gerou os arquivos, ainda precisei modificar um pouco por meu caso, assim:

# ~/.config/monitors.conf
# Generated by nwg-displays on 2025-08-28 at 14:30:17. Do not edit manually.

#monitor=HDMI-A-3,2560x1440@143.97,1080x407,1.25,bitdepth,10
#monitor=DP-5,3840x2160@60.0,0x0,1.875,bitdepth,10
#monitor=DP-5,transform,1
#monitor=DP-1,0x0@60.0,-1x-1,1.0
#monitor=DP-1,disable

monitor=HDMI-A-3,2560x1440@143.97,2813x948,1.0,bitdepth,10
monitor=DP-5,3840x2160@60.0,1373x350,1.5,bitdepth,10
monitor=DP-5,transform,1
monitor = DP-1,disable

O arquivo de monitor não precisei mexer nada, na real, só lembrar de desabilitar esse DP-1 que aparece no meu monitor principal (acho que é a DisplayPort dele, mas eu uso HDMI, então tem que desabilitar a DP-1).

# ~/.config/workspaces.conf
# Generated by nwg-displays on 2025-08-28 at 13:07:02. Do not edit manually.

workspace=5,monitor:DP-5,persistent:true
workspace=1,monitor:HDMI-A-3,persistent:true
workspace=2,monitor:HDMI-A-3,persistent:true
workspace=3,monitor:HDMI-A-3,persistent:true
workspace=4,monitor:HDMI-A-3,persistent:true

Esta também não precisei mudar muito, no próprio nwg-displays eu disse quais workspaces eu quero em cada monitor. Na minha preferência pessoal prefiro deixar o monitor vertical somente com a workspace 5 e os outros no monitor principal. A diferença aqui foi que adicionei essas opções persistent:true em todas, pra garantir que vai tudo funcionar direito com as workspaces “pinadas” nos lugares corretos. Workspaces em Hyprland são bem dinâmicos, vale ler a documentação depois, caso queira casos mais complicados.

Isso resolve meu setup de dois monitors do jeito que eu prefiro. Experimente mexer em coisas como scaling até ficar tudo ok pro seu setup.

Na sequência eu precisava resolver as hotkeys (key bindings). Eu estou acostumado com algumas combinações que vinha no ML4W então resolvi copiar de lá direto em ~/.config/hypr/bindings.conf. Primeiro, trocar o chromium pelo Brave:

# Application bindings
$terminal = uwsm app -- alacritty
$browser = brave # omarchy-launch-browser
...

Daí adicionei um tanto de binds no final do mesmo arquivo:

unbind = SUPER, V
bind = SUPER, V, swapsplit
bind = SUPER, M, fullscreen, 1                                                           # Maximize Window
bind = SUPER, T, togglefloating                                                          # Toggle active windows into floating mode
bind = SUPER SHIFT, right, resizeactive, 100 0                                           # Increase window width with keyboard
bind = SUPER SHIFT, left, resizeactive, -100 0                                           # Reduce window width with keyboard
bind = SUPER SHIFT, down, resizeactive, 0 100                                            # Increase window height with keyboard
bind = SUPER SHIFT, up, resizeactive, 0 -100                                             # Reduce window height with keyboard

# Display
bind = SUPER SHIFT, mouse_down, exec, hyprctl keyword cursor:zoom_factor $(awk "BEGIN {print $(hyprctl getoption cursor:zoom_factor | grep 'float:' | awk '{print $2}') + 0.5}") # Increase display zoom
bind = SUPER SHIFT, mouse_up, exec, hyprctl keyword cursor:zoom_factor $(awk "BEGIN {print $(hyprctl getoption cursor:zoom_factor | grep 'float:' | awk '{print $2}') - 0.5}") # Decrease display zoom
bind = SUPER SHIFT, Z, exec, hyprctl keyword cursor:zoom_factor 1 # Reset display zoom

# Workspaces
bind = SUPER, 1, workspace, 1 on HDMI-A-3 # Open workspace 1
bind = SUPER, 2, workspace, 2 on HDMI-A-3  # Open workspace 2
bind = SUPER, 3, workspace, 3 on HDMI-A-3 # Open workspace 3
bind = SUPER, 4, workspace, 4 on HDMI-A-3 # Open workspace 4
bind = SUPER, 5, workspace, 5 on DP-5 # Open workspace 5

bind = SUPER SHIFT, 1, movetoworkspace, 1  # Move active window to workspace 1
bind = SUPER SHIFT, 2, movetoworkspace, 2  # Move active window to workspace 2
bind = SUPER SHIFT, 3, movetoworkspace, 3  # Move active window to workspace 3
bind = SUPER SHIFT, 4, movetoworkspace, 4  # Move active window to workspace 4
bind = SUPER SHIFT, 5, movetoworkspace, 5  # Move active window to workspace 5

bind = SUPER, Tab, workspace, m+1       # Open next workspace
bind = SUPER SHIFT, Tab, workspace, m-1 # Open previous workspace

bind = SUPER CTRL, 1, exec, $HOME/.config/hypr/moveTo.sh 1  # Move all windows to workspace 1
bind = SUPER CTRL, 2, exec, $HOME/.config/hypr/moveTo.sh 2  # Move all windows to workspace 2
bind = SUPER CTRL, 3, exec, $HOME/.config/hypr/moveTo.sh 3  # Move all windows to workspace 3
bind = SUPER CTRL, 4, exec, $HOME/.config/hypr/moveTo.sh 4  # Move all windows to workspace 4
bind = SUPER CTRL, 5, exec, $HOME/.config/hypr/moveTo.sh 5  # Move all windows to workspace 5

Note que o último bloco de scripts precisa de um script pra mover todas as janelas de uma só vez pra outro workspace. Eu copiei este moveTo.sh do GitHub do ML4W e coloquei em ~/.config/hypr direto. Não esquecer de dar permissão de execução com chmod +x moveTo.sh depois. Os vários de workspace abaixo é como eu prefiro mover workspaces e mover apps pra diferentes workspaces.

Omarchy já vem com “SUPER J” pra mudar a orientação das janelas, por exemplo, se está duas janelas na horizontal um em cima do outro, com SUPER J eles ficam verticais, mas faltava o “SUPER V” que adicionei pra “swapsplit” que é trocar as janelas de lugar.

Eu também gosto de “SUPER M” pra temporariamente fazer uma das janelas ficar em tela cheia, e “SUPER T” pra temporariamente fazer uma janela ficar flutuante (como uma calculadora, por exemplo). Tive que dar unbind no SUPER M anterior que abria o Spotify, mas eu quase não uso Spotify no desktop então não preciso dela. Quando quero abrir esse app, vou no SUPER SPACE pra abrir o Rofi e escrevo lá.

Se tiver dúvidas sobre as combinações padrão, o Omarchy tem “SUPER K” pra abrir uma janela com uma ajuda pra todas.

Ainda não modifiquei combinações pra aplicativos específicos. Os que vem no Omarchy já são muito úteis como SUPER A pra abrir o ChatGPT como se fosse um app separado ou SUPER CTRL A pra abrir o Grok numa janela separada. SUPER O pra abrir o Obsidian também é muito útil pra mim. Recomendo brincar com esses binds pra fazer bindings específicos e, de novo, ler o manual pra aprender tudo mais que já vem nele. Mas até aqui é o suficiente pra deixar o Hyprland do jeito que eu gosto de usar.

8 - Timeshift, Snapshots e GRUB

Lembram que eu falei pra escolher GRUB no archinstall? É pra agora. O objetivo: deixar o sistema fazer snapshots periódicos do sistema e, caso instale algum pacote corrompido ou faça coisas no seu sistema que impeçam ele de bootar, em vez de ter que recorrer a um pendrive pra tentar bootar e diagnosticar o erro, é mais fácil só bootar, escolher um snapshot logo antes da operação destrutiva e voltar intacto.

Antes de prosseguir, um ajuste que acho importante: meu monitor 4K faz o GRUB ficar com letras pequenas demais pra eu conseguir ler. Prefiro letras maiores. Felizmente o GRUB usa fontes bitmap então posso usar qualquer uma. Eu fiz o seguinte:

sudo grub-mkfont -s 48 -o /boot/grub/fonts/caskaydia48.pf2 /usr/share/fonts/TTF/CaskaydiaMonoNerdFont-Regular.ttf

Isso vai gerar uma fonte no formato que o GRUB consegue carregar. Escolha qualquer uma que gostar, o Omarchy já pré-instala várias muito boas como as da JetBrains. Se tamanho 48 for muito grande, diminua pra 32, experimente até ficar do jeito que gosta.

Daí é só editar /etc/default/grub pra, no final ter esta linha:

GRUB_FONT=/boot/grub/fonts/caskaydia48.pf2

E agora é só regerar o bootloader:

sudo grub-mkconfig -o /boot/grub/grub.cfg

Toda vez que o yay -Syu trouxer atualização de kernel ou drivers, o GRUB vai ser regerado com a mesma fonte. Olha como ficou pra mim, acho que está bem melhor (isso é um monitor 4K):

Agora a razão toda pra ter escolhido GRUB: permitir escolher snapshots de BTRFS pra poder bootar no passado, antes de alguma operação destrutiva, como mostra na foto acima. Pra isso precisamos do seguinte:

pacman -S timeshift grub-btrfs
yay -S timeshift-autosnap
systemctl enable --now grub-btrfs.service

Pronto. A partir de agora, toda vez que o GRUB for reconstruído, vai ter uma nova opção pra escolher snapshots. Só precisamos criar esses snapshots automaticamente e, pra isso, temos o app Timeshift. Abra e siga o passo a passo dele. O importante é escolher a opção de BTRFS (sim, dá pra usar RSYNC se estiver em ext4, mas isso ocupa muito espaço, porque ele vai literalmente ficar fazendo cópias dos arquivos do seu sistema inteiro. A beleza de BTRFS é que snapshots dele não duplicam arquivos).

Eu deixo ele fazendo snapshots e acumulando versões das últimas horas, últimos dias, últimas semanas e meses. Se lá na frente eu lembrar “puuuuts, tinha aquele arquivo que eu apaguei mês passado mas agora eu preciso” Basta abrir o Timeshift e explorar um snapshot do mês passado. Igual povo de Mac faz com Time Machine, mas ocupando quase nada de espaço extra.

Além disso, todo upgrade de pacotes vai gerar um snapshot antes. Assim, se por acaso vier um pacote corrompido ou que quebre alguma configuração sua importante, dá pra voltar exatamente como era antes da atualização. E se quebrar de forma catastrófica, onde seu Linux não boota mais, basta ir no menu extra do GRUB e bootar do snapshot anterior, que funcionava. E tudo volta igualzinho como estava antes.

Não existe nada mais importante pro seu sistema do ter snapshots automáticos e que não ocupam quase nada de espaço extra. Só isso já torna o BTRFS superior a qualquer outra alternativa.

Isso não substitui Backup externo!!

Esse rollback e capacidade de recuperar coisas de forma fácil é bom pra acidentes do dia a dia. Mas digamos que seu NVME quebre de alguma forma, ou seu PC quebre de alguma forma. Pra isso servem backups externos (seja HD externo, seja NAS, seja Cloud). Você quer ter certeza que, numa situação catastrófica, ainda seja possível recuperar seus arquivos.

Eu tenho todas as camadas de proteção: snapshots locais via BTRFS e Timeshift, backups feitos remotamente pro meu NAS, e backup de partes mais importantes do meu NAS na Amazon Glacier que, diferente de Amazon S3 é pra guardar backup, onde o custo de armazenamento é ultra baixo mas o custo de transferência é mais alto (S3 o armazenamento é mais caro mas a transferência é barata, por isso serve pra servir assets de websites).

Eu gosto de estar preparado pra, caso minha casa pegue fogo, eu não perca nada importante.

9 - NFS no NAS

Falando em NAS, uma coisa que configurei diferente - já que uso primariamente Linux em vez de Windows - foi habilitar servidor de NFS.

Mas cuidado que alguns NAS tem uma característica que pode incomodar: o seu usuário no NAS vai ter UID e GID diferente de 1000!

Quando se cria um usuário em qualquer Linux, o padrão é atribuir o UID 1000 pro primeiro usuário, 1001 pro segundo e assim por diante. Mas como no NAS Synology o primeiro usuário recebe UID 1026, se eu montar com NFS (que transparece as permissões de UNIX), vou ter problemas de autorização.

Existem duas soluções: tentar mudar o UID no NAS de 1026 pra ser 1000. Eu tentei isso e já adianto que é perda de tempo, você pode acabar quebrando as configurações do NAS de forma catastrófica.

É muito mais fácil mudar o usuário do seu novo Linux local pra ser 1026 e pronto. É bem fácil.

Primeiro, precisamos deslogar e sair do Hyprland e voltar pra tela de login do SDDM. Daí precisamos mudar pra outro TTY com CTRL + ALT + F3 (pra ir pra tty3, por exemplo). De lá temos que fazer login como root.

Agora rodamos: systemctl isolate multi-user.target pra rodar em modo de recuperação isolado, onde nenhum outro usuário tem processos rodando. Já que vamos mexer no usuário, ele não pode estar ativo.

usermod -u 1026 akitaonrails
groupmod -g 1026 akitaonrails
chown -R 1026:1026 /home/akitaonrails

Com os comandos acima mudamos de 1000 pra 1026 e acertamos as permissões nos arquivos locais pra refletir essa mudança. Agora sim, podemos editar o /etc/fstab pra montar os diretórios compartilhados no NAS com NFS:

# NFS
192.168.0.x:/volume1/GIGACHAD /mnt/gigachad nfs4 _netdev,noauto,nofail,bg,x-systemd.automount,x-systemd.requires=network-online.target,x-systemd.after=network-online.target,x-systemd.idle-timeout=60s,noatime,nodiratime,async,rsize=65536,wsize=65536,actimeo=1  0 0
192.168.0.x:/volume1/TERACHAD /mnt/terachad nfs4 _netdev,noauto,nofail,bg,x-systemd.automount,x-systemd.requires=network-online.target,x-systemd.after=network-online.target,x-systemd.idle-timeout=60s,noatime,nodiratime,async,rsize=65536,wsize=65536,actimeo=1  0 0

Não esquecer de criar os mount points:

mkdir /mnt/gigachad
mkdir /mnt/terachad

Pronto, só rebootar e tudo vai funcionar corretamente. As permissões dos arquivos no NAS - que estão pro UID 1026 e GID 1026 - vão ser acessíveis pro usuário local sem problemas.

10 - Utilitários

Aqui são as últimas dicas pequenas pra ficar tudo num lugar só. A primeira é substituir o comando ls pelo eza que oferece uma cara mais bonita, com ícones e tudo mais, assim:

Só fazer yay -S eza e adicionar isto no seu .zshrc ou .bashrc:

alias ls='eza --icons --color=auto --group-directories-first'
alias ll='eza -l --icons --color=auto --group-directories-first'
alias la='eza -la --icons --color=auto --group-directories-first'

Segunda dica é instalar Atuin. Pra quem mexe com infra, isso é extremamente importante: backup de toda o histórico de comandos que você usou no seu terminal até hoje.

Instale com yay -S atuin e faça:

atuin login
atuin sync

Leia o site oficial, mas primeiro precisa criar uma conta e uma chave de encriptação secreta - sim, você pode rodar localmente num servidor na sua casa, mas a opção cloud deles é bem cômoda e segura porque fica toda encriptada, então não tem problema se subir senhas do seu histórico.

Só precisa colocar isso no seu .zshrc:

export ATUIN_NOBIND=true
eval "$(atuin init zsh)"
bindkey "^R" atuin-search

# incremental history search with arrow keys
bindkey "^[[A" history-beginning-search-backward
bindkey "^[[B" history-beginning-search-forward]]

Se estiver usando ZSH, o auto-complete dele vai funcionar normalmente mas, se digitar CTRL+R, vai abrir o histórico do Atuin. Ele vai guardar todos os seus comandos num SQLite e sincronizar. Assim você pode sincronizar diversas máquinas e servidores que usa no dia-a-dia ou, como no meu caso, recuperar o histórico todo numa nova instalação.

E pra ficar melhor, podemos configurar ele pra auto-sincronizar:

mkdir -p ~/.config/atuin
sed -i 's/^#\?auto_sync.*/auto_sync = true/; s/^#\?sync_frequency.*/sync_frequency = "30m"/' ~/.config/atuin/config.toml 2>/dev/null || \
printf 'auto_sync = true\nsync_frequency = "30m"\n' >> ~/.config/atuin/config.toml

Terceira dica: como temos Docker já instalado e configurado, eu gosto de usar o SGPT na linha de comando pra quando quero lembrar a sintaxe de algum comando que uso pouco, em vez de abrir um app ou navegador. Basta adicionar isto no meu .zshrc:

export OPENROUTER_API_KEY="sk-or-v1-8b8...17"
export OPENAI_API_KEY="sk-or-v1-db...f3"
export OPENAI_API_BASE="https://openrouter.ai/api/v1"

alias sgpt='docker run --rm -e OPENAI_API_BASE=${OPENAI_API_BASE} -e OPENAI_API_KEY=${OPENROUTER_API_KEY} ghcr.io/tbckr/sgpt:latest txt '

Eu uso OpenRouter pra ter acesso a diferentes LLMs comerciais numa única API, mas você pode só usar sua chave da OpenAI. Feito isso eu usaria no terminal parecido com isto:

~ ❯ sgpt "what is the pacman command in Arch to find out if a particular file came from an installed package?"
To find out if a particular file came from an installed package in Arch Linux, you can use the following pacman command:

``bash
pacman -Qo /path/to/file
``

Replace "/path/to/file" with the actual path to the file you want to check. This command will show the package which owns the file, or report that the file does not belong to any package if that is the case.

Se quiser, ele suporta sessões, então vai lembrar da conversa a cada nova chamada. Leia o Github do projeto.

Como fiz backup do meu ~/.config antigo, coisas como abas abertas do meu navegador Brave abriram normalmente nessa nova instalação de Omarchy e posso continuar fazendo minhas coisas exatamente do ponto onde parei. Não perdi nada. Mesma coisa vale pra todos os outros apps como emails que faço backup local via Thunderbird. Não preciso mandar baixar tudo de novo.

Se como eu, você tem vários dispositivos de saída de áudio, é possível que logo que terminar de instalar note que parece que não tem som. Mas não é um problema porque pode ser só que a saída está apontando pro dispositivo errado ou no perfil errado. Use SUPER ALT SPACE pra abrir o menu do Omarchy, escolha SETUP e AUDIO pra abrir esse programa que é em modo texto (eu gosto de programas em modo texto).

No meu caso, uso um DAC Topping D70 pra processar meu áudio e o perfil “Default” não funciona mas mudando pra “Pro Audio” funcionou. Também cuidado que tem configuração de volume global e controle individual de volume por programa. No geral, graças ao Pipewire, tudo deve funcionar normalmente.

Eu testei apps como Discord, Blender, Bambu Studio, VLC e tudo funcionando perfeitamente bem. Só VLC que precisei instalar os codecs de um pacote separado:

yay -S extra/vlc-plugin-ffmpeg

Blender também, o melhor é instalar deste pacote:

yay -S blender-bin

Se usar o pacote “blender” normal, alguns add-ons dele não instalam direito. Eu tive esse problema com MACHIN3Tools e MESHMachine, por exemplo.

Falando em Blender, ele é um app X11. Wayland roda aplicativos X11 usando uma camada adaptadora chamada XWayland. Eu tive vários problemas com posicionamento de menus e dialog boxes, mesmo adicionando windowrule. Uma coisa que sei lá porque funcionou foi instalar Blender e Bambu Studio via Flatpak:

yay -S flatpak
flatpak install org.blender.Blender
flatpak install com.bambulab.BambuStudio

Finalmente, se você é novo em LazyVim, não esqueça de rodar o comando :LazyExtras pra instalar os plugins extras pras suas linguagens favoritas, como LSP, Linter, syntax highlight, snippets e mais. O LazyVim puro já é completo mas sem suporte a muitas linguagens pra não ficar pesado desnecessariamente, você precisa instalar separado depois.

Também aprenda a usar Mise-en-place. No menu do Omarchy tem uma opção pra instalar suporte a várias linguagens e ele vai usar Mise, que é a forma correta de gerenciar suas linguagens.

Mise é muito fácil, no geral, de dentro do diretório do seu projeto, é só fazer algo como:

mise use ruby@3.4.3

Com isso, só dentro do seu projeto vai estar disponível Ruby 3.4.3, mas fora pode estar outra versão global. Não esquecer de ativar no seu .zshrc:

eval "$(mise activate zsh)"

Impressões e Conclusão

Comparado ao meu Manjaro antigo, muita coisa que não precisei configurar mais. Por exemplo, por causa do tanto de espaço que Docker e LLMs precisavam, eu tinha configurado um drive iSCSI no meu NAS só pra isso. Mas como eu liberei 2 TB de NVME local, não preciso mais lidar com isso, basta usar os novos sub-volumes de BTRFS que criei acima.

Também não preciso mais configurar QEMU/Libvirt porque não preciso mais usar Windows junto com Linux lado a lado. Mantive o NVME com as partições Windows e posso fazer dual boot pra ela se precisar muito de alguma coisa. No geral nunca preciso, então é menos uma configuração complicada.

Eu passei meses usando apps via Flatpak, com o intuito de ser mais seguro e isolado do sistema. É como rodar apps via Docker. Mas é chato demais. Por ser isolado significa que ele não obedece os temas do sistema, no final sou obrigado a ficar abrindo permissões pros apps. E se for pra ficar abrindo, é mais fácil instalar nativamente via yay e tudo funciona perfeitamente.

Acho que isso completa minhas anotações de tudo que precisei fazer pra deixar o Omarchy exatamente do jeito que eu gosto. Como falei repetidas vezes, o que funciona pra mim não quer dizer que vai funcionar pra você. Pra isso existe documentações como o ArchWiki que é “O” melhor lugar pra aprender tudo que sobre Linux. Use e abuse dessa documentação.

Como podem ver, não teve tanta coisa assim que eu customizei no Omarchy, por isso eu gosto dele: 95% do caminho ele já fez pra mim, só precisei mexer em poucos ajustes pra deixar do jeito que eu preciso. E agora sem o tanto de lixo que foi acumulando no meu Manjaro velho. Recomendo que todo mundo instale Omarchy como primeiro Linux e aprenda a usar de verdade.