Minha tese: isso era verdade gerações atrás, quando decodificar x86 custava uma fatia relevante da pastilha (o die). Hoje o x86 é, na prática, uma camada de tradução pra micro-instruções — e o que separa Apple, Qualcomm e Intel nunca foi o conjunto de instruções. A crise da Intel foi gerencial e de fábrica, não arquitetural. E é por isso que a volta dela, agora, faz sentido.

O que os reviews mostram

Os laptops Panther Lake (Core Ultra série 3, lançados na CES em 5 de janeiro e à venda desde 27 de janeiro) entregam números que a era Meteor/Arrow Lake não sonhava. Começando por bateria — Dell XPS 14 2026 (Core Ultra X7 358H) contra MacBook Air 15 (M5):

Leitura honesta: em uso leve, o Dell empata ou passa; em carga sustentada, a Apple continua imbatível. E o DHH publicou que seu XPS 14 rodando Omarchy Linux passa de 16 horas de uso real, com consumo em repouso de 1,4W — a Dell fez questão de suporte a Linux desde o dia um.

Na CPU, o topo de linha Core Ultra X9 388H contra o M5 (dados da Notebookcheck):

Single-core continua território da Apple, que faz o mesmo trabalho com um terço da energia. Mas em multi-core moderado, a Intel encostou. Contra a AMD (Ryzen AI 9 465) o 388H ganha em tudo; contra o Snapdragon X Elite de primeira geração também; o X2 Elite Extreme, que chegou em 2026, já devolveu a coroa de CPU Windows pra Qualcomm (+24% em single-core). Honestidade acima de tudo.

Na GPU, o veredito é mais misto que o marketing da Intel sugere:

O resumo da Ars Technica é o mais justo: “o melhor CPU de laptop da Intel em muito tempo” — com a ressalva de que a Intel precisa provar que isso é o novo normal, não uma aberração.

Pra guardar: bateria de MacBook num laptop x86 aconteceu — em uso leve. Em single-core e sob carga pesada, a Apple ainda dita o ritmo.

A crença: “pra ser eficiente tem que ser ARM”

Todo programador já ouviu a explicação: ARM tem conjunto de instruções simples, de tamanho fixo, elegante. O x86 é uma quimera acumulada desde 1978, com instruções de tamanho variável, modo real, segmentação, décadas de bagunça. “Portanto” ARM é inerentemente mais eficiente, e o caminho pra qualquer um chegar na eficiência da Apple ou da Qualcomm é migrar pra ARM64.

Tem verdade aí: o x86 carrega entulho histórico, e decodificar instrução de tamanho variável é objetivamente mais chato que decodificar instrução fixa de 32 bits. O erro está na conclusão. Essa diferença importava quando a lógica de decodificação ocupava uma fração significativa do chip. Isso faz muito tempo.

Pra guardar: a diferença entre ISAs importava quando a decodificação ocupava uma fração relevante da pastilha. Isso acabou há gerações.

O x86 virou camada de tradução em 1995

O Pentium Pro, de novembro de 1995, já não executava x86 diretamente: ele traduzia cada instrução CISC pra micro-operações internas estilo RISC e executava essas. A AMD fez o mesmo com o K5 em 1996 (as “ROPs”). Ou seja: faz trinta anos que “executar x86” significa “traduzir pra outra coisa e executar a outra coisa”. O x86 é uma interface de compatibilidade, uma camada de tradução sobre um motor RISC. E os números mostram o quanto essa camada ficou barata:

Quando o cache de micro-ops acerta, o hardware de busca e decodificação fica literalmente desligado. A conclusão do estudo da Hirki é seca: “o conjunto de instruções x86-64 não é um obstáculo relevante pra produzir um processador energeticamente eficiente”. E o estudo acadêmico definitivo — Blem, Menon e Sankaralingam, HPCA 2013, medindo ARM contra x86 de verdade — concluiu: contagem e composição de instruções são independentes do ISA em primeira ordem, as diferenças de performance vêm de microarquitetura, e “o consumo de energia é, novamente, independente do ISA”.

O Jim Keller — o cara que desenhou o Zen da AMD e os chips A4/A5 da Apple, alguém que morou nos dois lados — foi ainda mais direto numa entrevista à AnandTech: a decodificação de tamanho variável “não está dominando a pastilha, então não importa tanto”. O que limita performance hoje, segundo ele, é previsibilidade de branch e localidade de dados.

E tem o detalhe que derruba o mito de vez: ARM moderno faz a mesma coisa. O Cortex-A77 tem cache de micro-ops. A Samsung adicionou um no Exynos M5 explicitamente pra economizar energia de busca e decodificação. O A64FX da Fujitsu — o ARM dentro do supercomputador Fugaku — decodifica a instrução SVE FADDA em 63 micro-ops. Sessenta e três. A fantasia do “ARM é uma instrução por ciclo, simples e pura” não existe mais em nenhum ARM de alto desempenho.

Uma nuance honesta antes de seguir: o comprimento variável do x86 realmente dificulta fazer decodificadores muito largos — a Apple decodifica até o dobro de instruções por ciclo que um x86. É uma dificuldade de engenharia real. Só que ela se paga em área de lógica, que é barata, e não em consumo proporcional ao trabalho — que é o que define bateria.

Pra guardar: faz trinta anos que nenhum x86 executa x86 — tudo vira micro-operação estilo RISC. O ISA virou interface de compatibilidade.

A conta dos transistores

Pra entender por que o peso da decodificação evaporou, olha a evolução:

Em 2000, cada bloco de lógica era um orçamento apertado, e a bagunça do x86 custava caro. Conforme os transistores ficaram infinitos pra todo fim prático, o custo fixo do decodificador virou troco. No meio do caminho, duas mudanças importantes:

• A escala de Dennard morreu por volta de 2005. Vazamento de corrente impediu que os clocks continuassem subindo, a Intel cancelou o Tejas em 2004 e o mundo virou multicore. Clock parou nos 1-4GHz e nunca mais saiu dali.
• A lei de Moore virou economia, não física. O custo por transistor parou de cair no 28nm: uma fab de ponta hoje custa US$20 a 30 bilhões, e uma máquina High-NA EUV da ASML custa US$350 milhões.

E o que ocupa pastilha e consome energia num chip moderno? Caches gigantes, branch predictors, dezenas de execution ports, GPU, NPU, motores de mídia. O decodificador de x86, na fila do pão, nem aparece.

E a história dá a prova empírica perfeita: de 2015 a 2021, a Intel ficou presa em 14nm — Skylake e seus derivados, seis anos de processo estagnado por falha de fábrica. Mesmo assim, esses cores velhos em 14nm trocavam soco com o Zen 2 da AMD, fabricado em 7nm pela TSMC. Se o x86 fosse o problema, isso seria impossível. O gargalo era a fábrica. Era a fábrica o tempo todo.

Pra guardar: seis anos presa em 14nm, e mesmo assim a Intel competia com chips em 7nm da TSMC. O gargalo era a fábrica, nunca o ISA.

O que realmente faz a Apple ser eficiente

O M1 não é eficiente “porque é ARM”. A Apple tem licença arquitetural da ARM desde o A6, em 2012: ela desenha os próprios cores do zero e só o conjunto de instruções é ARM. Quando a AnandTech dissecou o core Firestorm do M1, o contraste com o x86 contemporâneo era de escolhas de engenharia, não de instruções:

Na prática: o dobro de decodificação por ciclo, quase o dobro de buffer de reordenação, seis vezes o cache de instruções. Some a isso a memória unificada soldada no pacote e o processo TSMC de última geração. É microarquitetura agressiva, cache enorme, integração vertical e processo de ponta — tudo caro, tudo deliberado, e nada disso vem de graça com o ISA.

Aliás, a recíproca também é verdadeira: dá pra fazer ARM ruim. O mercado está cheio de ARM medíocre. Eficiência é escolha de engenharia e de processo, não certidão de nascença do ISA.

Pra guardar: o M1 é eficiente por microarquitetura, cache, processo e integração vertical — não “porque é ARM”.

Suas instruções favoritas não são x86 nem ARM

E tem outra coisa que quase ninguém menciona nesse debate: boa parte do que uma CPU moderna executa não pertence ao conjunto “clássico” de nenhum dos dois lados. Olha o que roda fora dele:

• Vídeo. Na Intel, a decodificação fica no Quick Sync, hardware de função fixa que existe desde Sandy Bridge — um bloco separado que nada tem a ver com o legado x86. É por causa dele que a Frandroid mediu o Snapdragon X2 58% mais lento que o Panther Lake em exportação de vídeo.
• Criptografia. AES-NI existe desde 2010, extensões de SHA desde 2016 — instruções dedicadas, acrescentadas décadas depois do “x86 velho”.
• IA e matrizes. AVX-512, depois AVX10, e o AMX, um acelerador de tiles de matriz. O lado ARM tem os equivalentes: NEON, SVE, SME.

A Chips and Cheese fez o experimento perfeito: no mesmo encode HEVC 4K, um Ampere ARM levou mais de doze vezes o tempo de um Zen 2 com o ffmpeg padrão; usando assembly NEON, o tempo do ARM caiu mais de 60%. A diferença nunca foi ARM contra x86 — era extensão vetorial bem usada contra extensão vetorial ignorada. No mundo real, o trabalho pesado mora nas extensões e nos aceleradores, e esses são ortogonais ao ISA base.

Pra guardar: o trabalho pesado moderno — vídeo, cripto, IA — roda em extensões e aceleradores dedicados, ortogonais ao ISA base.

A queda foi gerencial, não arquitetural

Aqui a parte que me convence de vez. Olha a linha do tempo e tenta achar “o x86 era uma limitação fundamental” em algum ponto:

• 2005-2006: a Intel recusa fabricar o chip do iPhone — o Otellini admitiu o arrependimento em entrevista de saída à The Atlantic: “o mundo teria sido muito diferente”. E o detalhe tragicômico: a Intel tinha uma divisão ARM (a XScale) — e vendeu pra Marvell em 2006 por US$600 milhões. Não foi falta de tecnologia; foi falta de visão.
• 2013-2021: três CEOs. Krzanich sai em 2018 por escândalo interno. Entra Bob Swan, um CFO de finanças, pra comandar uma empresa de engenharia no momento mais delicado da história dela.
• 2018-2020: o 10nm vira piada (Cannon Lake só em tiragem limitada) e em julho de 2020 a Intel anuncia atraso no 7nm — a ação cai 16% num dia. Em abril de 2019, abandona o modem 5G de smartphone; a Apple compra o negócio por US$1 bilhão. Em novembro de 2020, o M1.
• 2021-2024: Gelsinger volta com o plano IDM 2.0, “cinco nós em quatro anos”. Em dezembro de 2024 é empurrado pra “aposentadoria” — ultimato do conselho, segundo Reuters e Bloomberg. O ano fecha com prejuízo de US$18,8 bilhões, 15 mil demissões, dividendo suspenso e a Intel expulsa do Dow Jones depois de 25 anos — substituída pela Nvidia, que naquele momento valia mais de 30 vezes a Intel. Até outubro de 2025, a conta de demissões acumuladas chegava a 35.500.

Nada nessa lista é arquitetura. É produto perdido, fab atrasada, decisão errada atrás de decisão errada. O x86 estava lá, competente, enquanto a empresa desmontava ao redor dele.

Pra guardar: iPhone recusado, XScale vendida, 10nm quebrado, três CEOs, US$18,8 bilhões de prejuízo — a queda da Intel foi decisão atrás de decisão, não limitação do x86.

O resgate improvável

E aí 2025 acontece. Lip-Bu Tan assume em março. Em agosto, Trump exige a cabeça dele no Truth Social por laços com a China — e poucos dias depois, após uma reunião na Casa Branca, vira fã do cara. No dia 22 de agosto, o governo americano compra 9,9% da Intel: 433,3 milhões de ações a US$20,47, US$8,9 bilhões no total, convertendo subsídios do CHIPS Act em participação acionária, sem assento no conselho. A SoftBank coloca US$2 bilhões. E a cereja surreal: a Nvidia — a mesma que a expulsou do Dow — investe US$5 bilhões e fecha parceria pra colocar chiplets RTX em CPUs x86.

O resultado financeiro começou a aparecer: Q1 2026 com receita de US$13,6 bilhões (+7% ao ano), Q2 com US$16,1 bilhões (+25%), sétimo trimestre seguido acima das projeções. A ação que o governo pagou US$20,47 chegou a mais de seis vezes esse valor em maio, quando a Bloomberg noticiou conversas pra Intel fabricar chips da Apple — reportagem preliminar, produção a anos de distância, mas o mercado pirou. Mesmo depois de esfriar, a posição do governo americano segue valendo cinco vezes o que custou. O contribuinte dos EUA é, hoje, sócio lucrativo da Intel. Vai entender.

Pra guardar: governo dos EUA, SoftBank e Nvidia como sócios, e a ação cinco vezes acima do preço que o governo pagou — a Intel virou causa nacional, e o mercado comprou a volta.

A volta, com os pés no chão

O Panther Lake é o primeiro produto grande do 18A — RibbonFET (transistor gate-all-around) mais PowerVia (alimentação pelo verso do wafer), saindo da Fab 52 em Chandler, Arizona. Tem ironia deliciosa aqui: o tile de GPU de 12 núcleos do topo de linha ainda é fabricado pela TSMC. E o aproveitamento do 18A (a fração de chips bons por wafer), segundo a Tom’s Hardware, só deve chegar ao padrão da indústria em 2027 — a rampa é lenta e a Ars Technica acerta na dúvida: é o novo normal ou uma aberração?

Mas o ponto deste artigo não é torcida organizada. É que o Panther Lake encerra empiricamente um debate que era teológico. Um x86-64 em processo competitivo entrega bateria de MacBook, empata multi-core com o M5 e ganha da concorrência Windows em vários cenários. Se o ISA fosse o fator decisivo, isso não aconteceria nunca, em nenhum processo. O que derrubou a Intel foi gestão; o que a traz de volta é fab e foco; e o que separa Apple, Qualcomm, AMD e Intel é microarquitetura, cache, processo e integração — exatamente como o Jim Keller e a literatura sempre disseram.

Torço pela volta dela. Não por nostalgia de quem montou PC com Pentium, mas porque o mercado de laptops eficientes estava virando duopólio confortável — e duopólio confortável é inimigo de preço e de inovação. Que a briga continue.

Pra guardar: o Panther Lake encerra um debate teológico: x86 competitivo existe quando a fábrica é competitiva. O jogo nunca foi sobre instruções.

Toda vez que menciono harnesses de coding agent, aparece alguém perguntando: “mas por que você não usa Pi?” ou “por que não Oh-My-Pi?”

E eu odeio essa pergunta desse jeito.

Não porque eu tenha alguma coisa contra Pi. Não tenho. O problema é que quase ninguém explica o porquê. Qual é o benefício objetivo? Que problema ele resolve melhor que Claude Code ou OpenCode? Em que caso de uso ele é claramente superior? Qual limitação concreta ele remove?

Normalmente não vem nada. Só vem nome de ferramenta. Isso me cheira a duas coisas: fanboy querendo validação da escolha que já fez, ou gente querendo terceirizar a lição de casa. “Akita, testa aí e me diz se minha ferramenta favorita é boa.” Não é exatamente o tipo de incentivo que me faz querer largar o que estou fazendo.

Mas testei mesmo assim. E, como eu esperava, não explodiu minha cabeça.

Antes de entrar em Pi, OpenCode e Oh-My-Pi, preciso alinhar vocabulário. Já expliquei isso em posts anteriores, especialmente em “RANT: IA acabou com os programadores?”, mas vale repetir porque muita gente ainda mistura tudo.

O que é um harness de coding agent

Uma LLM pura não edita seu projeto. Ela recebe texto e devolve texto. Só isso.

Quando você abre Claude Code, Codex, OpenCode, Oh-My-Pi, Crush ou qualquer coisa parecida, você não está falando diretamente com “o modelo” de forma crua. Você está falando com um programa no meio. Esse programa monta o ambiente de trabalho da LLM.

Esse programa é o que eu chamo de harness. Em inglês, harness é arreio, correia, a coisa que prende e direciona um cavalo. A metáfora é boa: o modelo bruto é forte, mas sem arreio sai correndo pra qualquer lado.

O harness faz várias coisas:

• monta o system prompt, com as regras de comportamento;
• lê arquivos de contexto como AGENTS.md, CLAUDE.md, regras locais, skills e documentação do projeto;
• define quais tools a LLM pode chamar;
• executa essas tools: ler arquivos, pesquisar texto, editar, rodar shell, rodar testes, abrir navegador, consultar LSP, chamar MCP;
• coleta o resultado das tools e devolve pro modelo como novo contexto;
• gerencia permissões, sandbox, confirmação de comandos perigosos;
• controla plano de execução, lista de tarefas, subagentes em paralelo;
• detecta contexto enchendo e dispara compaction;
• tenta preservar memória entre turnos ou sessões;
• decide como interromper, retomar ou redirecionar o agente quando você muda de ideia no meio do trabalho.

Por isso dois CLIs usando o mesmo modelo podem se comportar diferente. Não é só “GPT 5.5 vs Opus 4.7”. É modelo mais harness. O harness decide que informação o modelo vê, que ferramentas ele sabe que existem, que formato de patch ele usa, como ele confirma ações, quando ele sumariza, quando ele chama subagente, quando ele para.

É essa camada que separa um chat com copy-paste manual de uma ferramenta que consegue mexer num projeto real.

O problema dos planos subsidiados

Eu já bati nessa tecla várias vezes: pra quem usa agentes muitas horas por dia, os planos subsidiados da Anthropic e da OpenAI são muito mais interessantes que pagar token avulso.

Pagar API direto é caro. Muito caro. Se você faz Agile Vibe Coding de verdade, deixa o agente rodando testes, lendo código, refatorando, compilando, reescrevendo, revisando, ele queima token como se fosse churrasco de fim de semana.

Plano mensal muda a conta. Você paga um valor fixo, ganha uma cota grande, e consegue trabalhar sem ficar calculando cada tool call como se fosse taxímetro.

O problema é que a Anthropic é bem rígida sobre onde esses planos podem ser usados. A própria documentação de Legal and compliance do Claude Code diz que OAuth dos planos Free, Pro e Max é pra Claude Code e aplicações nativas da Anthropic, e que desenvolvedores terceiros devem usar API key via Claude Console ou cloud provider. Também diz explicitamente que a Anthropic não permite terceiros oferecerem login Claude.ai ou rotearem requests usando credenciais Free, Pro ou Max dos usuários.

Ou seja: existe hack pra fazer OpenCode, OpenClaw e outras ferramentas usarem o plano da Anthropic? Existe. O vazamento do Claude Code ajudou muita gente a entender como a autenticação e o transporte funcionavam. Escrevi sobre isso em “O código fonte do Claude Code vazou. O que achamos dentro.”.

Mas eu não recomendo.

Pelo que tenho visto, a Anthropic continua aplicando a política. Você pode conseguir fazer funcionar hoje e amanhã tomar bloqueio. Pior: você pode perder uma conta que usa todo dia. Pra mim não vale o risco. Se quer usar Opus com plano Anthropic, use Claude Code. Ponto.

E, pra ser justo, Claude Code é um dos melhores harnesses que existem. Depois de centenas de horas usando, eu consigo elogiar sem dó:

• o modo de planejamento é bom;
• a lista de tarefas é clara e o agente segue passo a passo;
• dá pra interromper e redirecionar sem destruir a sessão;
• dá pra injetar prompt enquanto ele trabalha;
• a memória e a compaction são bem mais sofisticadas que as alternativas;
• depois do vazamento, deu pra ver que não é só uma sumarização besta, tem várias camadas de gerenciamento de contexto.

Expliquei a parte de memória com mais calma em “Memória de Agentes IA: Karpathy LLM Wiki e agentmemory na Prática”. O ponto lá: Claude Code investe muito em preservar o que importa quando o contexto enche. Codex e OpenCode fazem o suficiente. Claude Code vai além.

Codex é o problema, não o GPT

OpenAI tem o Codex CLI pra usar com seus modelos. E aqui vou ser direto: Codex é um harness inferior.

Não estou dizendo que GPT 5.5 é ruim. Pelo contrário. O modelo é excelente. O problema é o arreio em volta dele.

O modo de plano do Codex é fraco perto do Claude Code. A interrupção é ruim: muitas vezes significa parar tudo, perder o fluxo e continuar manualmente. A organização de tarefas é mais frouxa. Mais de uma vez ele não terminou o que prometeu até eu mandar explicitamente “termina isso direito”. Parece ferramenta que ainda não decidiu se quer ser chat, executor, planner ou assistente de terminal.

É usável? Claro. Dá pra trabalhar? Dá. Mas a experiência é pior do que deveria ser.

A boa notícia é que não somos obrigados a usar Codex pra usar GPT. OpenCode existe. E, na prática, usando GPT 5.5 por OpenCode, eu sinto o modelo muito menos nerfado. O harness deixa o modelo trabalhar melhor.

OpenCode também documenta que dá pra conectar provedores e usar assinaturas em alguns casos. Na página de Providers, eles mesmos avisam que Anthropic proíbe uso de Claude Pro/Max em terceiros, mas listam assinaturas como ChatGPT Plus, GitHub Copilot e GitLab Duo como suportadas no OpenCode. A interface muda de versão pra versão, às vezes você vê /connect, às vezes o pessoal fala em /login, mas a ideia é a mesma: OAuth do plano é diferente de API key. API key é crédito por token. OAuth é usar a assinatura.

Então minha recomendação prática hoje é simples:

• Quer usar Opus 4.7 subsidiado? Use Claude Code.
• Quer usar GPT 5.5 subsidiado? Use OpenCode.
• Quer usar GPT 5.5 via Codex? Pode, mas na minha opinião está nerfando o modelo com um harness pior.

Se a OpenAI fosse esperta, eu sinceramente largaria Codex CLI e adotaria OpenCode como base. Ou pelo menos copiaria sem vergonha o que OpenCode faz bem. Codex não tem nenhuma vantagem objetiva pra mim hoje.

E onde entra Pi?

Agora sim, Pi.

Pi é um harness minimalista. Dá pra usar sozinho, mas pra mim é como abrir NeoVim sem plugin nenhum. Sim, funciona. Sim, tem gente que ama montar tudo do zero. Sim, você aprende bastante fazendo isso.

Mas eu não recomendo como ponto de partida pra quem só quer trabalhar.

Oh-My-Pi é um fork baseado em Bun, com “baterias inclusas”. E, claro, já existe polarização: extremista de Pi diz que Oh-My-Pi é inchado, que o certo é usar Pi puro, montar suas ferramentas, compor sua própria distro, configurar tudo no braço.

Isso me lembra NeoVim. Eu gosto de NeoVim. Mas eu não quero gastar minha vida escolhendo plugin de statusline, configurando LSP na unha, ajustando keymap de árvore de arquivos e comparando 12 fuzzy finders. Instalo LazyVim e pronto. Quando eu quiser estudar internals, estudo. Quando quero entregar trabalho, uso o pacote que funciona.

Pra mim, Oh-My-Pi ocupa esse lugar. Se você tem curiosidade por Pi, comece pelo Oh-My-Pi. Se gostar, se sentir vontade, aí vá pro Pi minimalista e construa sua própria distribuição. Vai fundo. Só não finja que isso é objetivamente melhor pra todo mundo.

Minha primeira impressão do Oh-My-Pi é que ele funciona. Não é ruim. Também não me fez dizer “nossa, como vivi sem isso até hoje?”

Out of the box achei verboso demais. Tenho certeza de que dá pra customizar, mas aqui mora a toca do coelho. Eu não quero passar a tarde tunando prompt, tema, modo de exibição, tamanho de painel, política de tool e sei lá mais o quê. Deixei default.

Em uso normal, ele lembra bastante OpenCode. Ambos conseguem trabalhar com plano, tarefas, tools, subagentes, LSP, compaction, interrupção e steering. Ambos são superiores ao Codex como harness. Isso já basta pra eu levar a sério.

Mas OpenCode parece mais coeso. Mais produto. Mais polido. O Oh-My-Pi parece mais laboratório de gente que gosta de ferramenta poderosa e cheia de knobs. Isso pode ser elogio ou crítica, dependendo do tipo de pessoa que você é.

O que eu fui checar no código

Pra não ficar só em impressão visual, pedi uma análise comparando OpenCode, Pi e Oh-My-Pi, e depois conferi partes do código-fonte.

O resultado bate com a intuição.

Pi upstream

O Pi original é pequeno. O conjunto de tools embutidas é basicamente:

• read
• bash
• edit
• write
• grep
• find
• ls

Isso é limpo. Eu gosto de código limpo. Mas como harness moderno pra programação pesada, sozinho, não compete com OpenCode ou Oh-My-Pi.

De novo: não quer dizer que é inútil. Quer dizer que é base minimalista. Se você quer montar sua própria distribuição de agente, ótimo. Se quer abrir e trabalhar hoje, é pouco.

OpenCode

OpenCode tem o kit normal e competente pra programação:

• shell;
• read;
• glob;
• grep;
• edit/write ou apply_patch;
• task/subagentes;
• todo;
• web fetch/search;
• skills;
• LSP opcional;
• plugins e MCP.

O read dele cobre o que eu espero num projeto de código: arquivo-fonte, diretório, imagem suportada e PDF. Tem LSP. Tem task. Tem todo. Não tenta ser o canivete suíço de todo artefato possível.

Pra software normal, isso resolve. Pra um projeto que mistura banco SQLite, planilhas, notebooks, PDFs, arquivos compactados e páginas web, aí começa a aparecer a diferença.

Oh-My-Pi

Oh-My-Pi vem com mais tools. Bem mais. No registry dele aparecem coisas como:

• read
• bash
• edit
• ast_grep
• ast_edit
• ask
• debug
• eval
• find
• search
• lsp
• inspect_image
• browser
• task
• job
• recipe
• irc
• todo_write
• web_search
• write
• ferramentas de memória/hindsight

A vantagem mais clara é o read.

No Oh-My-Pi, uma única tool read entende arquivos, diretórios, archives (.tar, .tar.gz, .tgz, .zip), SQLite, imagens, documentos (PDF, DOCX, PPTX, XLSX, RTF, EPUB), notebooks Jupyter (.ipynb), URLs em modo reader, e URIs internas como skill://, agent://, artifact://, memory://, rule://, local://, mcp://.

Aqui ele ganha de verdade quando o trabalho depende desses formatos.

Exemplo: projeto Rails com SQLite local. Em OpenCode, o agente provavelmente vai tentar usar sqlite3 via shell, ou escrever script, ou você vai ter que instruir. No Oh-My-Pi, o próprio prompt da tool ensina:

• file.db lista tabelas e contagem de linhas;
• file.db:table mostra schema e amostras;
• file.db:table:key pega uma linha por chave primária;
• file.db:table?limit=50&offset=100 pagina;
• file.db:table?where=status='active'&order=created:desc filtra;
• file.db?q=SELECT ... roda SELECT read-only.

Isso importa. Claro que um humano consegue fazer com shell. Mas o modelo não precisa inventar o comando, não precisa depender de sqlite3 instalado, não precisa errar escaping, não precisa despejar 30 mil linhas no contexto. O caminho certo já está descrito dentro da tool, visível pro modelo.

Mesma coisa pra ZIP, PDF, planilha, notebook. Se seu projeto é só TypeScript, Ruby, Go e Markdown, tanto faz. Se seu projeto é data science, investigação, auditoria, análise de documentos, migração de banco, parsing de artefatos, aí Oh-My-Pi começa a fazer mais sentido.

A vantagem em código-fonte puro é menor

Pra source code comum, a diferença existe, mas não é gigantesca.

Oh-My-Pi tem algumas conveniências boas:

• leitura de código com resumo estrutural quando o arquivo é parseável;
• leitura por múltiplos ranges numa chamada só;
• anchors com hash de linha, que deixam edição textual mais segura;
• roteamento mais agressivo pra LSP;
• tools de AST (ast_grep e ast_edit);
• prompt de sistema insistindo pra usar a ferramenta especializada em vez de cair no shell.

A parte de AST merece explicar.

grep e rg procuram texto. AST procura estrutura sintática. Em vez de buscar a string console.log, você pode procurar uma chamada console.log($$$) e ignorar espaços, quebra de linha, comentários, formatação. Em vez de fazer replace textual de import, você pode reescrever um nó de import. Em vez de caçar foo && foo() como texto, pode transformar estruturalmente em foo?.() garantindo que o mesmo metavariável aparece dos dois lados.

Isso é útil em codemod. É útil quando você quer alterar chamadas de função, imports, declarações, padrões de erro, sem pegar falso positivo em string, comentário ou documentação.

Mas não é mágica. AST pattern é sensível. O modelo pode errar o formato. Às vezes precisa ajustar a query. Pra refactor grande, LSP rename ainda é mais correto que AST se a linguagem suporta. AST é uma ferramenta a mais, não uma religião.

OpenCode não fica indefeso sem isso. Ele tem grep, edit, apply_patch, LSP opcional, task, todo. Pra 90% das tarefas comuns de código, isso resolve.

Minha leitura, depois de olhar o código, é simples: quando o trabalho envolve SQLite, notebook, documento, archive, imagem, URL ou artefato interno, Oh-My-Pi tem uma vantagem real. Em código-fonte puro, a vantagem aparece mais em refactor grande, navegação por tipo, busca estrutural e codemod. Pra edição normal de código, OpenCode continua tão bom quanto e costuma ser mais agradável.

Prompt também é ferramenta

Uma coisa que muita gente ignora: não basta existir tool. A LLM precisa saber quando usar.

O prompt do Oh-My-Pi é bem explícito. Ele manda usar ferramentas quando melhoram corretude, paralelizar chamadas quando fizer sentido, preferir LSP pra operações de símbolo, preferir AST pra busca estrutural e codemod, preferir read/search/find em vez de shell, delegar pra subagentes quando o trabalho é decomponível.

Isso ajuda modelos grandes. Opus e GPT 5.5 obedecem bem esse tipo de instrução quando a descrição da tool é clara.

O OpenCode não fica devendo no básico. Ele ensina Read, Glob, Grep, Edit, Write, Bash, Task, patch. Dá conta do fluxo normal. A diferença é que ele não empurra LSP e ferramentas avançadas com a mesma insistência do Oh-My-Pi.

Pi upstream é minimalista também no prompt. Lista tools, dá guidelines, mas não faz roteamento pesado. De novo: bom pra quem quer base pequena. Menos bom pra quem quer harness cheio de conveniência pronta.

Memória, plano, interrupção

Aqui Oh-My-Pi e OpenCode ficam mais parecidos.

Ambos têm compaction de contexto. Ambos têm algum modo de plano/todo. Ambos conseguem spawnar subagentes. Ambos permitem steering, isto é, você não precisa tratar a lista de tarefas como escritura sagrada. Se o agente começou a fazer besteira, você interrompe, injeta novo prompt, muda direção.

Isso é obrigatório pra Agile Vibe Coding. Sem steering decente, a ferramenta vira esteira rolante: começou errado, continua errado até bater na parede. Claude Code é muito bom nisso. Oh-My-Pi e OpenCode chegam perto o bastante. Codex, na minha experiência, não.

No Oh-My-Pi, olhando configuração, existem knobs explícitos pra steeringMode, interruptMode e compaction.strategy. Essa é a cara dele: expor comportamento do harness como configuração. Poderoso, mas também mais uma toca de coelho.

OpenCode tende a esconder mais disso e entregar um produto mais fechado. Eu gosto desse trade-off pro dia a dia.

Mas o Pi não tem mais agentes?

Outro argumento que aparece: “mas no Pi dá pra spawnar muito mais agentes”.

E daí?

Ter mais agentes disponíveis não significa que a tarefa ficou mais paralelizável. Programação é difícil de paralelizar pelo mesmo motivo que gerenciar time de programadores é difícil: quase sempre existe um caminho crítico. Você consegue dividir alguma coisa, claro, mas logo chega num ponto em que uma decisão depende da anterior, que depende de um detalhe que só apareceu depois de rodar o teste, que muda a arquitetura, que invalida metade do plano original.

LLM com subagente sofre da mesma física. Agente A precisa saber o que agente B decidiu. Agente C implementa em cima de uma API que agente A ainda está mudando. O agente principal precisa consolidar tudo, detectar conflito, pedir correção, reler diff, rodar teste, mandar outro patch. A partir de certo ponto, você não está paralelizando. Está inventando gerência.

Eu já demonstrei isso no post “LLM Benchmarks: Vale a Pena ($$) Misturar 2 Modelos?”. Rodei variações com planner forte, executor barato, delegação livre, delegação forçada, orquestração manual. O resultado foi chato: em coding agent contínuo, o overhead de coordenação come o ganho. Quando não forcei delegação, os modelos Tier A simplesmente não delegaram. Quando forcei, a qualidade caiu ou o tempo aumentou. No melhor caso, empatou custando mais coordenação.

Isso não é bug. É bom senso do modelo.

Numa tarefa coesa, o modelo bom percebe que precisa manter o raciocínio no mesmo contexto. Design e implementação se misturam. Você planeja, escreve, testa, descobre que uma premissa estava errada, ajusta, volta, simplifica. Separar isso artificialmente em 10 agentes só cria mais borda pra dar ruim.

Tarefas realmente paralelizáveis existem. Traduzir um arquivo enorme de strings pra 10 idiomas? Beleza. Um agente por idioma. Converter 200 imagens pra WebP? Pode paralelizar. Aplicar o mesmo refactor mecânico em 50 arquivos independentes? Talvez. O resultado de um item não muda o outro.

Mas quantas tarefas do seu dia a dia são assim?

Eu não vi o Oh-My-Pi paralelizar mais que OpenCode ou Claude Code em programação normal. E isso é o correto. Se ele saísse abrindo agente pra tudo, eu desconfiaria. Ia gastar tempo, contexto e token consolidando trabalho duplicado.

Então não: misturar modelos, misturar agentes ad hoc, aumentar o número mágico de workers, nada disso resolve programação difícil. Resolve lote independente. E lote independente é a parte fácil.

Mas o Pi não economiza mais tokens?

Outro mito: como Pi é mais customizável, você controla system prompt de cada componente, então dá pra minimizar tudo e economizar tokens contra OpenCode, Codex ou Claude Code, que começam com prompts maiores.

Você está economizando centavos e perdendo dólares.

O prompt inicial não é onde a maior parte do gasto acontece num coding agent sério. O gasto vem do trabalho: ler código, escrever código, rodar teste, receber stack trace, ler log, reler arquivo, aplicar patch, rodar teste de novo. Um ou dois logs verbosos já comem a janela inteira de um modelo local pequeno com 30K tokens. Um bundle exec, um npm test, um build de frontend cuspindo warning, pronto: lá se foi sua economia heroica de system prompt.

Minha regra pessoal: eu não tentaria usar coding agent sério com menos de 200K tokens de contexto. Abaixo disso, o harness precisa compactar memória toda hora. Compaction ajuda, mas sempre perde detalhe. Perde o warning que apareceu antes do erro. Perde a decisão tomada meia hora atrás. Perde o trecho do stdout que parecia ruído mas era a pista.

Com menos de 100K, pra mim, é basicamente inutilizável pra sessão longa de programação. Você não consegue deixar o agente ler log grande, output de teste, stdout de build, diff comprido. Volta pro trabalho idiota de ficar escolhendo manualmente o que cabe no contexto. Isso é o oposto de produtividade. É você virando assistente do assistente.

Por isso eu recomendo frontier models. Opus e GPT têm janelas na faixa de 1 milhão de tokens, e isso importa em sessão longa. Dá pra deixar o harness trabalhar sem tratar cada log como contrabando. Dá pra manter detalhes recentes por mais tempo antes da próxima compaction. A resposta melhora porque o modelo ainda tem os fatos na frente dele.

Esse é um motivo grande pra eu não recomendar LLM open source local pra programação séria. Não é só qualidade do modelo. É KV cache. Não existe GPU de consumidor com VRAM sobrando pra contexto gigante em modelo grande. Mesmo num Mac Studio parrudo, na prática, você mal chega perto de algo como 300K antes de começar a sacrificar memória e desempenho. Ainda está longe de 1 milhão.

Nesse ponto, a comparação de preço muda. Mesmo pagando por token, muitas vezes compensa. E se quiser economizar, use um modelo cloud de geração anterior, tipo Kimi K2.6. No meu benchmark, ele continua muito melhor que qualquer open source local que testei. Sai barato e você não precisa fingir que 30K de contexto é ambiente sério de desenvolvimento.

Pior: se você tenta economizar token manualmente, você quebra o fluxo certo.

O jeito errado é deixar o harness sugerir comando, copiar pro seu terminal, rodar você mesmo, pegar só um pedaço do output, colar de volta no chat e torcer pra ter escolhido o pedaço relevante. Isso economiza token e destrói contexto. O modelo fica cego justamente na parte que importa: o erro inteiro, a ordem dos eventos, o warning anterior, o path real, a diferença entre stdout e stderr, o comando exato que rodou.

O jeito certo é deixar o harness rodar. Sim, ele vai mandar output pro contexto. Sim, custa. Mas é assim que o modelo tem informação suficiente pra escolher o próximo passo. Quanto mais contexto real e verificável ele tem, melhor a chance de corrigir certo na próxima iteração.

É por isso que eu insisto nos planos subsidiados. Se você paga por token avulso, fica tentado a dirigir com o freio de mão puxado. Se você está num plano Pro/Max/Plus, use a ferramenta direito. Deixa rodar teste. Deixa ler log. Deixa abrir arquivo. Deixa o agente trabalhar.

E, por favor, não perca tempo tentando transformar Qwen local no seu programador principal porque “é grátis”. Eu já testei isso no benchmark canônico “Benchmark de LLMs pra Coding: DeepSeek, Kimi, MiMo, GPT”. Os modelos open source locais ficaram Tier C ou pior. Qwen local é legal pra laboratório, demo, curiosidade, estudo. Pra programação séria com tool calling longo, contexto grande, testes e refactor, ainda não é substituto pra Claude ou GPT.

Se você não consegue pagar US$100 por mês numa ferramenta que pode multiplicar sua produtividade por 5 ou 10, o problema não é token. É ROI. É carreira. É o tipo de trabalho que você está fazendo.

Ficar tunando Pi pra economizar migalha de token não é seu ticket pra ganhar melhor. Entregar mais, com mais qualidade, usando ferramenta boa, é.

Pi é melhor que OpenCode?

Eu tentei uma comparação prática. Peguei o mesmo PR, akitaonrails/ai-memory#10, e pedi review pra três combinações:

• Oh-My-Pi com GPT 5.5;
• OpenCode com GPT 5.5;
• Claude Code com Opus 4.7.

Mesmo PR. Mesmo tipo de pedido. Mesma intenção: achar problemas reais antes de merge.

Nenhum achou tudo.

Pra simplificar, imagine que os problemas do PR eram A, B, C e D. Oh-My-Pi achou A e B. OpenCode achou B e C. Claude achou C e D. Não foi exatamente essa a matriz, mas a ideia é essa: cada um pegou uma parte. Cada um perdeu uma parte.

Isso é o que eu vivo repetindo: não confie em uma única LLM pra auditar nada importante. Ela vai achar alguns problemas. Talvez bons problemas. Talvez problemas que você não viu. Mas não existe garantia de cobertura completa. Depende do contexto que ela leu, de como você perguntou, de que arquivos ela abriu, de que tool ela decidiu usar, do caminho que o raciocínio tomou.

O detalhe interessante: o mesmo GPT 5.5 deu respostas diferentes em dois harnesses diferentes. Oh-My-Pi e OpenCode não viraram clones só porque usaram o mesmo modelo. O harness muda prompt, tools, formato de contexto, ordem das coisas, pressão pra usar LSP ou AST, tudo. Isso muda o caminho.

Nesse caso específico, eu diria que Oh-My-Pi e OpenCode empataram. Ambos acharam problemas reais. Ambos deixaram passar problemas reais. Claude ficou um pouco pior porque em uma passagem chegou mais perto de dizer que o PR era mergeável quando ainda tinha coisa faltando. Mas isso também não prova que Claude é pior. Numa segunda passada, com prompt diferente, poderia inverter.

O ponto não é coroar vencedor. É matar a fantasia.

Pi não tem uma magia escondida que transforma review em auditoria perfeita. Oh-My-Pi é um harness muito bom. OpenCode também. Claude Code também. Todos erram. Todos dependem do modelo, do contexto e do pedido. Por isso eu não sei se preferiria Oh-My-Pi a OpenCode ou Claude Code como ferramenta principal. Ele entra na mesma prateleira: excelente, útil, mas não milagroso.

Mais uma anedota, sem virar prova de nada. Enquanto eu editava este post no Oh-My-Pi, pedi uma mudança localizada. Com Claude Code e OpenCode, quando peço isso num post bilíngue, normalmente eles alteram o trecho em PT-BR e o trecho equivalente em EN, só naquele range. O Oh-My-Pi fez metade certo: editou o PT-BR no lugar certo. Mas no EN decidiu retraduzir o arquivo inteiro do zero. Não sei por quê.

É só um caso. Não prova incompetência. Mas é curioso porque justamente derruba a fantasia de que Pi sempre economiza token. Nessa rodada, ele gastou muito mais. Eu nunca vi Claude Code ou OpenCode retraduzirem o post inteiro quando eu pedi uma edição pequena; eles costumam ser bons em mexer só no pedaço pedido.

Minha primeira impressão é que o OMP realmente tem mais tools e se esforça pra usá-las. Talvez até demais. Às vezes eu fico com a sensação de que ele força tooling em tarefa onde OpenCode e Claude Code seriam mais diretos ao ponto, e isso quase começa a piorar a resposta em vez de ajudar. Pode ser só impressão inicial, mas a sensação até aqui é essa: o OMP às vezes tenta demais pro próprio bem.

Então qual eu usaria?

Se o assunto é programação normal, eu continuaria alternando entre Claude Code e OpenCode.

Claude Code quando quero usar Opus e o plano Anthropic. OpenCode quando quero usar GPT 5.5 e não sofrer com Codex. Simples.

Oh-My-Pi eu colocaria na caixa de ferramentas, não como substituto obrigatório. Eu escolheria Oh-My-Pi quando o projeto tivesse muita coisa fora de source code:

• PDFs que precisam ser lidos;
• planilhas;
• SQLite;
• notebooks Jupyter;
• ZIPs e tarballs;
• imagens;
• páginas web que precisam virar texto;
• artefatos internos de outras execuções;
• necessidade de AST codemod com mais frequência.

Talvez em projeto de data science ele brilhe mais. Talvez em investigação de dados. Talvez em auditoria, migração, pesquisa com documentos, ferramenta interna cheia de SQLite e CSV e XLSX. Nesses cenários, a tool read universal é muito conveniente.

Pra CRUD Rails, backend Go, frontend TypeScript, CLI Rust, blog Hugo? OpenCode é tão bom quanto e mais polido.

E Pi puro? Eu só usaria se minha diversão fosse montar o harness em si. Nada errado com isso. Só não vou fingir que é o caminho pra quem quer terminar trabalho hoje.

Minha recomendação atual

Se você quer uma resposta curta:

• Use Claude Code com Opus 4.7 se você quer o melhor harness proprietário e pode ficar dentro do ecossistema Anthropic.
• Use OpenCode com GPT 5.5 se você quer usar o plano da OpenAI sem se prender ao Codex.
• Use Oh-My-Pi se você quer um harness mais flexível, com mais tools, especialmente pra projetos com arquivos e artefatos variados.
• Evite Codex se você tem alternativa. O modelo é bom. O harness atrapalha.
• Use Pi puro se você gosta de montar sua própria distro. Como ferramenta de trabalho imediata, eu começaria pelo Oh-My-Pi.

A analogia com Linux ajuda. Eu não uso Linux porque é “grátis”. Uso porque, pra mim, é a melhor ferramenta pro trabalho. As alternativas não chegam perto no meu fluxo. Mas isso não quer dizer que todo iniciante deveria largar Windows ou macOS amanhã e montar Arch na unha.

Mesma coisa com editor. NeoVim é tecnicamente fantástico. Eu adoro. Mas existe um motivo pra ele não ser tão mainstream quanto VS Code: não é produtivo no primeiro dia, a não ser que você já tenha experiência e tenha aprendido aos poucos. Se você precisa de produtividade agora, usa a ferramenta mais fácil que funciona out of the box. VS Code, Cursor, Windsurf, JetBrains, o que for. Entrega primeiro. Tweaka depois.

E olha que eu nem sou o cara de ficar fazendo rice de NeoVim o dia inteiro. Eu prefiro NeoVim porque as capacidades de edição são superiores às do VS Code, e porque gosto de ficar 100% no terminal. Editor GUI como VS Code ou Zed não me dá esse fluxo. Uso o mesmo editor localmente ou via SSH, combino com Tmux ou Zellij, rodo tudo em terminal moderno tipo Kitty, Ghostty ou Alacritty, e sou produtivo assim.

Nesse ponto, harness de LLM combina comigo. Oh-My-Pi, OpenCode e Claude Code já são terminal-based. Qualquer um deles encaixa bem no meu fluxo.

Pi cai nessa categoria. É NeoVim. Tecnicamente ótimo, elegante pra quem gosta de montar a própria oficina, mas não é a escolha certa pra todo mundo. É ferramenta pra quem gosta de tunar, entende o custo disso, e aceita passar tempo ajustando o harness como parte do hobby ou do trabalho. Pra maioria, comece pelo pacote que funciona.

Ou seja: Oh-My-Pi e OpenCode são bons. Escolha um e trabalhe. Não tem religião aqui.

O que me irrita é fanboy vendendo nome de ferramenta como se fosse argumento. “Usa Pi” não significa nada. Me diga o que ele resolve melhor. Me diga onde economiza tempo. Me diga que bug real ele evita. Me diga que fluxo fica impossível no Claude Code ou no OpenCode e trivial no Pi.

Aí sim temos conversa.

Até agora, minha leitura é chata: pra desenvolvimento de software normal, Oh-My-Pi e OpenCode performam parecido quando usam o mesmo modelo. Oh-My-Pi tem mais ferramentas e é mais flexível. OpenCode é mais coeso e polido. Claude Code continua sendo a régua quando o assunto é Opus. Codex continua sendo a opção que eu só usaria se não tivesse escolha.

Ferramenta ajuda. Harness importa. Mas quem ganha ainda é processo: prompt pequeno, escopo claro, teste rodando, revisão cuidadosa, commit frequente, engenharia de verdade.

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.

A proposta é forte. É um modelo multimodal de geração de vídeo que aceita simultaneamente texto, até 9 imagens de referência, 3 clipes de vídeo de referência e 3 trilhas de áudio numa mesma chamada. Em cima disso, ele gera saída de até 15 segundos com áudio sincronizado nativo (diálogo, efeitos, música ambiente), suporta extensão de vídeo, edição pontual de personagens e objetos, e tem planejamento de câmera dirigido por prompt. A ByteDance posiciona o modelo pra publicidade comercial, vídeos explicativos, produção de filme, e-commerce e gaming. Ou seja: pra criador de conteúdo que quer escapar do estágio “meme aleatório” e começar a entregar peça com uso profissional.

Pra quem quer ver o modelo em ação antes de continuar lendo, recomendo essa visão geral feita pelo Stefan, do canal Stefan 3D AI Lab, que eu já tinha indicado lá no post sobre modelagem 3D com IA:

A interface principal é o “Photo Studio” da Dreamina, onde você escolhe o modo de geração e empilha as referências. Por enquanto eu testei só o modo de multi-referência padrão.

Teste 1: lip-sync com áudio do podcast

Meu primeiro teste foi simples. Peguei alguns segundos do bumper de abertura do meu podcast The M.Akita Chronicles, que é gerado com IA via pipeline ElevenLabs v3, passei o meu novo avatar em estilo anime como imagem de referência, e pedi pro Seedance fazer o personagem sincronizar boca e gesticular em cima daquele áudio.

O resultado é decente. Saiu tudo de uma imagem fixa só. O lip-sync acompanha a fala razoavelmente bem, a expressão tem alguma vida, o gesto da mão entra no momento certo. Mas é o tipo de coisa que rende clipinho curto pro YouTube ou Instagram. Não é animação que você usaria como abertura de um vídeo profissional.

A função que de fato importa: vídeo de referência

E aqui eu chego no que eu considero o único uso de verdade desses modelos pra trabalho sério: usar vídeo como referência. Texto sozinho nunca vai ser preciso o suficiente. Você pode descrever a cena com o vocabulário que quiser, mudar adjetivo, especificar lente, ângulo, framing, e ainda assim cada geração vai te dar algo um pouco diferente. É loteria. Bom pra meme, péssimo pra produção.

A maioria dos amadores se impressiona com qualquer clipe aleatório que sai bonito de primeira, e enche o feed do X e do Instagram com isso. Só que aquilo não é controle. É sorte. Pra cinema, pra publicidade, pra abertura de programa, pra qualquer coisa onde a próxima cena precisa casar com a anterior, você tem que conseguir dizer pro modelo: “faça exatamente esse movimento, com exatamente essa câmera”. E é aí que o vídeo de referência muda o jogo, porque ele substitui horas de modelagem 3D, rigging, animação e renderização que custariam fortunas em estúdio.

Pro meu teste, eu reciclei o modelo que já tinha gerado lá no post sobre AI 3D com Hunyuan e Nano Banana, onde testei o quanto dá pra modelar 3D do nada com prompt e ainda imprimir em 3D. Mas pra uma referência mais cinematográfica eu queria algo com animação pronta. Baixei do Sketchfab o modelo Darth Talon, que tem uma sequência curta de movimento bem feita, só porque achei legal.

Importei o FBX no Blender, montei câmera e luz básica, e fiz uma renderização rápida no Cycles. Nada bonito, é só um esboço pra servir de referência de movimento e enquadramento.

Subi pro Seedance esse render como vídeo de referência junto com três imagens em t-pose do personagem (frente, costas, lado esquerdo) pra dar consistência visual:

Primeira tentativa, com prompt genérico:

Não ficou ruim. O personagem mantém identidade, a iluminação melhorou bastante em cima do meu render bruto, e o vídeo é coerente. Só que o movimento e a posição de câmera divergiram bastante da referência. O modelo entendeu “ali tem um personagem parecido com esse fazendo algo parecido com aquilo”, e improvisou o resto.

Lembrei do tutorial do Stefan: o truque é colocar literalmente no prompt algo como Follow exact motion and camera from reference video. Tentei de novo:

Bem melhor. Está claramente seguindo a coreografia da referência, o ângulo de câmera bate em vários momentos, e a aparência do personagem ficou mais polida que tudo que eu poderia renderizar à mão num esboço de Cycles. Mas ainda assim não é cópia exata do meu render. Em alguns frames o modelo ainda toma liberdade com timing, posição e enquadramento. Existem outras técnicas de prompting e parâmetros pra ajustar, mas eu parei aqui pra registrar essas primeiras impressões enquanto o lançamento está fresco.

ComfyUI, Runway e o resto do ecossistema

O Seedance 2.0 também já saiu como nó do ComfyUI na nuvem, o que ajuda muito quem quer encaixar a geração dentro de pipeline maior sem ficar pulando entre interface web. Pra quem já tem pipeline de geração de imagem montado em ComfyUI, isso é bem prático.

E pra quem quer um caminho com volume sem pensar em crédito por geração, a Runway está oferecendo o Seedance 2.0 dentro do plano Unlimited, que sai por volta de US$ 76/mês no anual ou US$ 95/mês no mensal. “Unlimited” no caso significa sem cobrança por geração, mas com prioridade de fila menor em horários de pico e cota de armazenamento de saída. Pra quem precisa iterar muito, esse modelo de assinatura faz bem mais sentido que crédito avulso.

A questão do preço

A precificação direta do Seedance é em crédito. O plano Standard sai por US$ 24,90/mês no anual ou US$ 49,90/mês no mensal, e te dá 2500 créditos por mês. Cada 10 segundos de vídeo gerado consome 6 créditos.

A conta é cruel. Com 2500 créditos no Standard, dá pra rodar cerca de 416 gerações de 10 segundos por mês. Parece muito, mas lembra do meu próprio teste: foram pelo menos duas tentativas pra chegar perto do que eu queria, e mesmo assim não foi cópia exata do que pedi. Na prática, pra cada cena que você quer entregar bem, é razoável assumir 3 a 5 regerações. Isso derruba o número útil pra algo na faixa de 80 a 140 cenas curtas por mês. Pode até dar pra um criador solo fazendo conteúdo curto. Não dá pra produção que precisa de minutos contínuos de vídeo polido.

Os planos superiores escalam linearmente o número de créditos, mas o problema continua: no preço de hoje, o Seedance 2.0 ainda é ferramenta pra clipe curto e meme bem-feito, ou pra prototipagem de cena antes de mandar pra estúdio de verdade. Não substitui produção profissional contínua. Pra esse perfil, na prática a Runway com Unlimited sai mais em conta. Confira a tabela de preços completa aqui.

O que ninguém quer falar: restrição e deepfake

Tem dois pontos que eu não quero deixar de fora. O primeiro: o Seedance 2.0 demorou a chegar pro grande público em parte porque a ByteDance está sendo bem mais conservadora que a concorrência na hora de moderar. O modelo bloqueia geração com referência de pessoas reais (celebridades, políticos, figuras públicas) e filtra personagens com IP forte de Disney, Marvel/DC, Nintendo e marcas registradas em geral. Quem quiser detalhe sobre o que passa e o que não passa, e por que a empresa optou por essa postura, tem esse artigo da MindStudio explicando os limites. Faz sentido: a ByteDance opera em dezenas de jurisdições, está sob escrutínio regulatório global, e ainda tem o tema espinhoso de Hollywood pressionando o setor inteiro com ações de copyright sobre uso de material protegido em treinamento e geração. O lançamento atrasou e veio com filtro pesado justamente por isso.

Segundo ponto, e mais importante: pra você, leitor comum, a mensagem é que deepfake deixou de ser hipótese. Foto na internet já não vale como prova há um bom tempo, porque modelos de imagem como Nano Banana, Hunyuan e congêneres entregam realismo que engana qualquer um. Agora vídeo está na mesma categoria. O que a gente acabou de ver acima, onde com algumas referências e dois prompts dá pra gerar uma cena animada coerente em minutos, é só o começo. A pessoa comum, sem treino, não vai mais conseguir distinguir vídeo gerado de vídeo real só batendo o olho. E os filtros do Seedance só barram o uso aberto e legal. Quem quer fazer mau uso vai sempre encontrar caminho com modelo open source, com workaround, com plataforma menos rígida. Esse é o mundo real agora, e quanto antes a gente assumir isso socialmente, melhor.

Não, isso não substitui artista de verdade

Já vou cortar o discurso de sempre antes que ele apareça nos comentários. Não, o Seedance não substitui artista de VFX, diretor, editor, nada disso. Isso aqui é martelo. A ferramenta é a mesma pra todo mundo. O que sai do outro lado depende inteiramente de quem está segurando ela.

Quem estudou enquadramento, ritmo, continuidade, direção de arte, edição, cor, composição, vai usar o Seedance pra acelerar 10 vezes o trabalho que já sabia entregar. Quem não estudou nada disso vai produzir 10 vezes mais rápido o mesmo meme de Instagram que já produzia. A IA reflete quem você é. Se você é bom artista, a ferramenta multiplica. Se você só acha que é bom, a ferramenta multiplica a mesmice. Não tem milagre.

E é por isso que essa onda de “agora todo mundo vira diretor de cinema com IA” é a mesma ladainha que ouvimos com câmera digital, com Photoshop, com After Effects, com Premiere e com qualquer ferramenta poderosa que apareceu nos últimos 30 anos. A barreira técnica cai, a barreira de gosto, repertório e estudo continua exatamente onde estava. Quem é bom fica mais produtivo. Quem não é continua precisando de gente de verdade pra fazer trabalho de verdade.

Onde isso vai parar

Seedance 2.0 é claramente um passo na direção certa, mas ainda não é a ferramenta que substitui produção profissional. Texto sozinho continua impreciso, vídeo de referência ajuda mas ainda escapa, e o preço por minuto útil de saída polida é alto pro que entrega. A boa notícia é que a história se repete: Google já tem o Veo, Runway está com modelo próprio e ainda revendendo Seedance, Kling e Hailuo da China continuam puxando, e os modelos open source vão ganhando tração. A OpenAI tinha o Sora, mas descontinuou. Conforme a competição aperta, qualidade sobe e preço cai. Em um ou dois anos a gente deve estar olhando pra esse post e achando primitivo o que acabei de mostrar. Como sempre.

Esse é o episódio do dia 6 de abril do podcast do The M.Akita Chronicles, já gerado com a nova pipeline da ElevenLabs v3. Assina o canal no Spotify pra não perder episódio novo desses.

Quando o Qwen3 TTS foi lançado, pelos idos de janeiro desse ano, todo mundo no Twitter/X e nas newsletters de IA gritou “ElevenLabs killer”. Tem artigo no Medium dizendo que é a primeira ameaça open source real à ElevenLabs. Tem post da byteiota dizendo que a clonagem de voz em 3 segundos bate a ElevenLabs. Tem análise no Analytics Vidhya falando que é o TTS open source mais realista já lançado. O consenso da internet entusiasta era: finalmente temos open source que faz frente à ElevenLabs, o jogo virou, é só questão de tempo.

Eu resolvi testar no meu próprio fluxo de produção, como de costume. Montei um pipeline inteiro em cima do Qwen3 TTS 1.7B pra gerar o podcast semanal do The M.Akita Chronicles, e documentei os bastidores no post sobre servir IA na nuvem. Quem quiser ver o detalhe de tempo de partida a frio, clonagem de voz, parâmetros de sampling que mudam de um modo pro outro, dá uma olhada nesse link que eu não vou repetir tudo aqui.

A pergunta desse post é diferente. Depois de quase dois meses rodando essa configuração em produção, com episódio indo ao ar toda segunda-feira, ontem à noite eu finalmente desliguei o Qwen3 e passei tudo pra ElevenLabs v3. Vou contar por quê.

O que não funcionou no Qwen3

Entre 15 de fevereiro e 30 de março eu fiz dezenas de commits ajustando o fluxo do podcast: prompts, parâmetros de sampling, ordem de geração, silêncios de referência na amostra de clone de voz, normalização de volume, pronúncia de siglas técnicas. Corrigir a voz do Marvin que cortava a primeira sílaba porque o áudio de referência começava sem silêncio inicial. Afinar a voz do Akita pra ela soar mais confiante e assertiva. Adicionar crossfade entre jingles de seção. Resolver a pronúncia errada de “podcast” pra ela não sair como “pódcast”. Mandar o gerador de roteiro preferir português a anglicismo gratuito pro TTS não engasgar. Cada um desses ajustes foi uma sessão de horas escutando áudio, gerando de novo, ajustando parâmetro.

O resultado ficou aceitável. “Aceitável” no sentido de que eu consegui publicar todo episódio sem ter que regravar nada à mão. Mas escutando com atenção, a voz do Qwen3 tem aquele jeito inconfundível de IA gerando áudio. Intonação meio morta, ritmo uniforme. Em trechos longos, você sente que é máquina falando. Serve pra ir pro ar, mas tá a quilômetros do que você escuta num podcast profissional feito por gente.

O problema pior foi a pronúncia em inglês. Meu podcast cobre notícias de tecnologia, então termos como “MCP”, “RAG”, “Claude Opus”, “GPT-5”, “open source” aparecem em toda conversa. O Qwen3 pegava esses termos e pronunciava eles com sotaque brasileiro, tipo “ó-péne-ssourssê”, coisa assim. Ficava ilegível pro ouvinte. A solução que eu tive que implementar foi mapear manualmente no prompt do LLM que gera o roteiro quais palavras em inglês trocar por equivalente em português. O prompt hoje tem uma seção inteira dividida entre “manter em inglês” (nomes próprios, marcas, termos já incorporados ao brasileiro) e “traduzir pro português” (anglicismo gratuito), mais ou menos assim:

**REPLACE with Portuguese** (common English words that have natural
Brazilian Portuguese equivalents):
- "update" → "atualização"
- "release" → "lançamento"
- "feature" → "recurso/funcionalidade"
- "deploy" → "implantação" or just "colocar em produção"
- "trade-off" → "dilema" or "escolha"
- "performance" → "desempenho"
- "default" → "padrão"
- "insight" → "percepção/sacada"
- "skills" → "habilidades"
- "approach" → "abordagem"
- "highlights" → "destaques"

Chamam isso aqui em casa de “limpar anglicismo pra o TTS não engasgar”. Engraçado porque eu não queria esse nível de restrição no meu roteiro. Queria que a voz simplesmente pronunciasse “update” quando o contexto natural fosse “update”. Como o modelo não consegue, tive que mutilar o vocabulário do podcast pra o resultado final ficar escutável. É uma solução paliativa, daquelas que você adiciona torcendo pra poder remover depois quando a tecnologia amadurecer.

A experiência com a ElevenLabs v3

Ontem à tarde abri uma conta na ElevenLabs, comprei o plano Pro (US$99/mês), e comecei a experimentar com o modelo eleven_v3, que saiu em fevereiro desse ano. Trinta minutos depois eu tinha uma prova de conceito rodando, e umas duas horas depois o sistema inteiro do podcast migrou. A diferença de esforço é abissal.

Os detalhes técnicos da migração ficaram documentados num doc interno do projeto, então vou resumir aqui o quadro comparativo que importa:

Repara no último ponto. O Qwen3 custa menos de dez centavos de dólar por episódio. A ElevenLabs custa quase trinta vezes mais. E mesmo assim vale a pena. Os outros pontos do quadro resolvem problemas que sugavam horas da minha semana. Eu não preciso mais escrever código pra escalar GPU na nuvem, não preciso esperar a máquina ligar toda vez, não preciso ficar de babá do modelo nem reconstruir a imagem Docker quando o peso muda. A operação virou uma linha de configuração.

E o mais interessante: as tags de emoção no meio do texto. O modelo v3 aceita marcadores tipo [sighs], [sarcastically], [dryly], [excited], e muda a entonação de acordo. Isso funciona em mais de 70 idiomas, incluindo português do Brasil. Isso transformou a geração do roteiro porque agora eu posso pedir ao LLM que monta o roteiro pra colocar tags emocionais nos momentos certos, o que dá uma vivacidade que o Qwen3 não conseguia entregar nem de longe. Um exemplo concreto do que sai no roteiro depois:

AKITA: Isso é simples. [dismissive] Quem ainda acredita que Bitcoin
vai morrer não tá prestando atenção.
MARVIN: [sighs] Mais uma semana, mais uma leva de devs confiando
cegamente em pacotes npm. Previsível.

Eu tenho até duas paletas separadas de tags, uma pro Akita (expressivo mas controlado, usa [excited], [dismissive], [emphatic]) e outra pro Marvin (estóico, só [sighs], [sarcastically], [tired], [dryly]). Isso tá tudo codificado nos prompts de geração do roteiro pro LLM saber que personagem pode usar o quê.

Sobre a voz do Marvin

Pros ouvintes que já se acostumaram com a voz do Marvin, fica tranquilo: eu fiz o clone dele na ElevenLabs usando a mesma amostra de áudio que eu já tinha usado pra treinar no Qwen3. É a mesma voz. Só que agora ela soa ainda melhor, porque o modelo da ElevenLabs captura nuance e prosódia que o Qwen3 não conseguia entregar.

Escuta aí e me conta

Pra provar que o papo é real, aqui tá o episódio de segunda-feira, dia 6 de abril, já gerado com a nova pipeline:

Se você já é ouvinte do podcast no Spotify e escutou os episódios anteriores feitos com Qwen3, compara e me diz nos comentários se você nota a diferença ou se pra você tanto faz. Eu tô curioso de saber quanto é percepção treinada minha escutando horas de áudio de TTS e quanto é diferença óbvia pra ouvinte casual.

A partir da próxima semana, todos os episódios do podcast serão gerados pela ElevenLabs v3. A newsletter já tá ligada na nova pipeline, os jobs agendados de pré-aquecer a GPU na RunPod foram desativados, e o código legado do Qwen3 fica no repositório como plano B caso um dia o v3 dê problema crônico. Em duas edições de arquivo eu volto pra ele. Provavelmente nunca vou ter que voltar.

A parte de dublar os vídeos do YouTube

Agora o gancho pra segunda metade desse post. No artigo de aniversário que eu publiquei mais cedo hoje, contei que o Claude Code traduziu quase metade do meu blog pra inglês num fim de semana. No mesmo espírito, fui atrás de dublar os vídeos do canal Akitando.

O canal tem 146 episódios, algo como 96 horas de conteúdo técnico em português, e mais de 500 mil inscritos. Eu já tinha as legendas traduzidas (um .srt curado por episódio), e o YouTube até oferece dublagem automática em inglês. Mas o resultado é tipo Google Translate de 2015: entende, passa a ideia, mas ninguém quer ouvir por muito tempo.

Testei as três abordagens de voz da ElevenLabs e só uma servia. Speech-to-Speech converte voz mas não traduz. A API de Dubbing traduz mas cria a voz sozinha, sem deixar forçar um clone específico. Só a Text-to-Speech resolvia: pegar meu .srt em inglês, mandar cada bloco pro endpoint TTS com a minha voz clonada, e montar o áudio alinhado com o vídeo original.

Só que ter o .srt traduzido não basta. Tradução crua de legenda não sobrevive ao TTS. Trechos com código-fonte, URLs, hashes hexadecimais, listas de comandos shell — o modelo entra em modo soletrar e o áudio sai com o dobro da duração esperada. Traduções longas demais estouram a janela de tempo e precisam ser condensadas pra a voz não ficar atropelada. SRTs truncadas precisam ser completadas. E a cada correção, rodar a pipeline de novo, escutar, achar o próximo problema, corrigir, repetir. O processo inteiro foi um ciclo de interrupções, correções manuais e re-runs — longe do “aperta o botão e sai dublado” que a gente imagina antes de meter a mão.

O grande desafio era o sotaque. Minha voz clonada foi treinada em português brasileiro, então quando tenta falar inglês o sotaque puxado aparece. A ElevenLabs tem a tag [American accent] que funciona em v3, mas em cima de uma voz treinada em outra língua ela é fraca — o sotaque brasileiro ainda saía por baixo. A saída foi treinar uma segunda voz minha, só em inglês. Gravei uns minutos no meu melhor sotaque americano, subi como Instant Voice Clone separado na minha conta, batizei de “Akita English”, e configurei o pipeline pra usar essa voz por padrão. O resultado sai mais natural, sem precisar de tag nenhuma, e a identidade de voz continua sendo a minha.

O teto honesto de qualidade da minha voz em inglês

Vamos ser francos. Eu sou brasileiro falando inglês, não sou nativo, e não tenho tempo nem paciência pra treinar pronúncia por horas. O clone só consegue ser tão bom quanto a amostra original — se a amostra é um não-nativo lendo um roteiro, o clone herda as imperfeições. Nenhum clone vai me fazer soar como “Fabio falando inglês perfeito”, porque esse som não existe pra o modelo imitar.

Pra chegar na versão que tá rodando, gravei cinco amostras de treino diferentes ao longo do dia, cada uma com ritmo e roteiro diferentes, e rodei um A/B ao vivo comparando com o original em português. Nenhuma soou como nativo, e nunca foi esse o objetivo. A meta realista era mais modesta: soar reconhecivelmente como eu, ler conteúdo técnico sem tropeçar, e aguentar um episódio inteiro sem cansar o ouvinte. O vencedor acabou sendo a primeira iteração, a “Akita English” original. Longe de perfeito, mas suficiente pra colocar no ar. Trocar no futuro é literalmente uma linha no arquivo de configuração.

O que mais me surpreendeu no caminho foi perceber que o ritmo da amostra importa mais que o timbre. O clone aprende a cadência de quem gravou: a iteração 5 ficou 25% mais lenta que a iteração 2 lendo exatamente o mesmo texto, só porque eu gravei aquela amostra mais devagar. Pra dublagem de vídeo tech, o alvo certo é ritmo de explicação de YouTube, vivo, uns 150 palavras por minuto. Nada de ritmo de audiobook.

Como eu alinho o áudio com o vídeo original

Um ponto não óbvio: texto em inglês tende a ser mais longo ao falar do que o português equivalente. Se você simplesmente gera o áudio de cada legenda e cola no tempo original, o dub vai se acumulando. Com 30 minutos de vídeo, você já tá vários segundos fora de sincronismo.

Minha abordagem foi atacar o problema em camadas. A primeira versão dividia o SRT em blocos menores, chamados de “chunks”. Cada chunk tinha no máximo 700 caracteres (pra v3 não alucinar) e só podia cortar em fim de frase, nunca no meio. Um algoritmo simples acumulava legendas num buffer até chegar perto do teto, depois voltava procurando a última legenda do buffer que terminava com ponto, exclamação ou interrogação, e fazia flush só até ali. O resto das legendas já acumuladas ficava pra compor o próximo chunk. Cada chunk guardava o timestamp de início e fim das legendas que cobria, pra a montagem saber exatamente onde posicionar aquele pedaço de áudio depois.

# Pra cada nova legenda que chega, checa se adicionar ela
# estouraria o limite do chunk atual.
for cue in cues:
    projected = buffer_char_len(buf) + len(cue.text)
    if projected > max_chars and buf:
        # Procura a última legenda do buffer que termina
        # com pontuação final ('.', '!', '?', '…').
        sentence_end = last_sentence_end_index(buf)
        if sentence_end is not None:
            buf = flush(buf, sentence_end, chunks)
        else:
            # Run-on maior que max_chars sem fim de frase.
            # Raro, mas acontece. Avisa e corta mesmo assim.
            log.warning("run-on sentence > %d chars — "
                        "splitting mid-sentence as a last resort",
                        max_chars)
            buf = flush(buf, len(buf), chunks)
    buf.append(cue)

    # Soft-break: se o buffer já tá pelo menos 60% cheio E
    # a legenda atual terminou uma frase, esvazia agora.
    # Mantém os chunks balanceados em torno de 60 a 100% do max.
    if cue.ends_sentence and buffer_char_len(buf) >= max_chars * 0.6:
        buf = flush(buf, len(buf), chunks)

Tecnicamente, esse foi o ponto de virada: em vez de deixar a estrutura da dublagem seguir a estrutura visual da legenda, o chunker passou a seguir a estrutura real dos parágrafos do roteiro. Não vou repetir aqui toda a novela de como cheguei nisso e por que isso acabou forçando rerender em massa, porque volto nessa história mais abaixo, na parte dos problemas que só apareceram depois do primeiro upload. O ponto técnico aqui é simples: quando a janela passou a representar um parágrafo falado de verdade, o áudio começou a soar natural e o alvo de stretch pôde subir de 92% pra 95%.

Feito isso, ainda sobra o problema do inglês ser mais longo ao falar que o português equivalente. Aqui a sacada é prever se um chunk vai estourar a janela alvo antes de gerar o áudio. Se a razão caracteres / 16 caracteres-por-segundo já passa da duração alvo com uma margem, a pipeline manda o parâmetro speed direto pra API da ElevenLabs, pedindo pro modelo gerar o áudio nativamente mais rápido. Isso preserva a prosódia muito melhor do que comprimir depois. O teto é 1.15× (acima disso a voz começa a soar atropelada).

# antes de chamar a API, prevê se vai estourar
expected_sec = char_count / EXPECTED_CHARS_PER_SEC  # 16 chars/s
predicted_ratio = expected_sec / target_sec

voice_speed = 1.0
if predicted_ratio > PREEMPTIVE_SPEED_THRESHOLD:   # 1.05
    voice_speed = min(predicted_ratio * 0.98,
                      PREEMPTIVE_SPEED_MAX)         # cap em 1.15
    voice_settings["speed"] = voice_speed

Mesmo com o speed preventivo ligado, às vezes o áudio gerado ainda fica um pouquinho mais longo do que a janela alvo. Pra isso existe uma segunda rede de proteção: medir o áudio real com ffprobe depois de gerado, comparar com a janela alvo, e aplicar o filtro atempo do ffmpeg pra comprimir no pós-processo se passou de 2% de tolerância, com teto de 1.20×. A combinação do speed nativo (1.15×) com o atempo (1.20×) dá uma compressão efetiva de até 1.38×, suficiente pra caber naturalmente mesmo nos casos mais extremos sem quebrar qualidade.

# depois de gerar o chunk
actual = ffprobe_duration(chunk_path)
ratio = actual / target_sec

if ratio > FIT_TOLERANCE:       # 1.02
    # comprime o áudio sem mexer no pitch
    ffmpeg_atempo = min(ratio, FIT_MAX_ATEMPO)   # 1.20
    apply_atempo(chunk_path, ffmpeg_atempo)

Quando um chunk gerado fica mais curto que a janela alvo, o pipeline estende o áudio levemente (sem afetar pitch) pra reduzir o silêncio feio depois que ele termina. O objetivo não é preencher a janela inteira, uma pausa natural entre frases é boa, mas suavizar os casos mais gritantes de silêncio que dariam a impressão de “áudio cortado”.

Num episódio grande, 95 minutos, 194 chunks, o desvio cumulativo total ficou em -0,7%. Uns 43 segundos de drift ao longo do episódio inteiro, imperceptível enquanto você assiste.

O que salvou o orçamento nessa arquitetura é que cada chunk fica salvo individualmente no disco como um .mp3 separado. A pipeline mantém um manifesto com o texto normalizado de cada chunk, e antes de chamar a API da ElevenLabs, compara o texto atual com o cache. Se o texto não mudou, reutiliza o áudio já gerado sem gastar crédito nenhum. Se eu reescrevo uma cue problemática, só os chunks afetados por aquela cue são regenerados — o resto do episódio fica intacto.

Isso é o que viabilizou as iterações. Eu rodava o batch, escutava trechos, identificava um problema (tradução longa demais, snippet de código que o TTS não conseguia pronunciar, chunking que cortou num ponto ruim), corrigia o SRT ou ajustava os parâmetros do chunker, e rodava de novo. Cada re-run consumia uma fração dos créditos e do tempo do run original, porque só os chunks alterados eram regenerados. Sem esse cache, cada iteração teria custado quase o mesmo que a primeira rodada, e o custo total do batch teria sido duas ou três vezes maior.

Essa mudança de chunking também teve impacto pesado no cache e no custo, mas deixo essa parte pro trecho mais abaixo onde explico a sequência de retrabalho. Aqui basta dizer que, do ponto de vista técnico, era a mudança certa.

Quando o atempo não salva: reescrevendo cue antes do TTS

Nem tudo é questão de alinhamento de janela. Tem um tipo de cue que quebra o pipeline inteiro, onde nem speed preventivo nem atempo no pós-processo resolvem, e eu só esbarrei nisso quando comecei a rodar o batch nos episódios mais técnicos do canal.

O problema é o seguinte. O v3 lê a uns 16 caracteres por segundo quando você entrega texto normal de conversa. Mas quando você entrega uma cue recheada de URL literal, hash hexadecimal, string binária, uma lista de números ordenados ou um bloco de código shell, o modelo entra em modo “soletrar letra por letra” e despenca pra uns 9 caracteres por segundo. Uma cue de 500 caracteres que devia virar 30 segundos de áudio vira 55. A checagem de sanidade derruba (porque passou de 1.8×), o retry automático tenta de novo com os mesmos 500 caracteres, os cinco retries falham seguidos, e o chunk fica preso.

E isso não aconteceu por acaso. Eu escrevia desse jeito porque sabia que esses mesmos roteiros depois virariam post no blog, então fazia sentido deixar a URL crua, o comando completo, o hash inteiro, o detalhe técnico todo mastigado pro leitor. Em português isso funcionava bem porque era exatamente o meu fluxo original: gravar o vídeo e depois publicar o texto correspondente no blog. O que eu nunca tinha preparado era a etapa seguinte, de transformar esse mesmo material em dublagem automatizada pra inglês. Eu só fui perceber esse conflito quando a pipeline começou a falhar de verdade.

Peguei isso primeiro no ep052, o guia de Ubuntu pra devs iniciantes, onde duas cues traziam URLs do github.com, URLs hkp://keyserver.ubuntu.com e um hash GPG de 40 caracteres. Tentar resolver no pós-processo seria perda de tempo. O teto de 1.20× do atempo nunca vai comprimir 55 segundos em 30, e mesmo se conseguisse ia sair num chipmunk ilegível. A saída é atacar antes, no texto.

A solução foi reescrever a cue dizendo o que o comando faz, em vez de mostrar o comando literal:

- Rode: apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 \
-   --recv-keys 0A6A3E7F79F93EF8AAB9E92BAEBB74C8B5A1E44D
+ Rode o comando completo que tá na descrição do vídeo pra importar
+ a chave de assinatura do repositório do keyserver do Ubuntu.

A legenda em inglês no vídeo continua mostrando o comando inteiro na tela, então quem lê a legenda vê o que precisa digitar. O áudio dublado descreve a intenção em linguagem falada, que é o que o TTS entrega sem engasgar. A instrução pro ouvinte fica intacta, e o caractere-por-segundo volta pros 16 esperados, então o áudio gerado cabe na janela original sem precisar esticar nem comprimir nada no pós.

Saí caçando cue assim em todos os episódios do batch. Varri do ep052 ao ep146 procurando cues com densidade alta de caractere “duro” (dígitos, colchetes, operadores, URLs longas, binário, hex) e acabei reescrevendo umas 30 cues em 13 episódios:

• ep052 Ubuntu pra devs: URLs do GitHub e hash GPG de 40 caracteres
• ep091 Hello World em C: exemplos binários
• ep095 Memória 640kB: wrap de endereço, segment-offset
• ep106 CodeMiner: endereço de e-mail soletrado
• ep113 Compressão: strings de binário puro, 75% de caractere duro
• ep115 SQL Server: lista longa de números ordenados
• ep120 Internet: endereços IP com pontos
• ep121 Sockets: dois blocos de código JavaScript
• ep122 Proxies: headers User-Agent do Chrome
• ep123 Rede segura: one-liners shell, flags do Docker
• ep126 Gentoo: demo de chroot em C
• ep136 Containers: URL de release do GitHub
• ep144 Criptografia: endereço de signing key

O padrão foi sempre o mesmo: mantém a legenda exibindo o código, a URL ou o hash na íntegra, e reescreve o texto pro narrador descrever o que aquilo faz. Eu podia ter automatizado a reescrita, deixando um LLM ler a cue e propor uma substituição no voo, só que achei mais seguro revisar tudo manualmente. É exatamente o tipo de coisa onde o modelo resolve “melhorar” um comando pra deixá-lo mais limpo e sai com shell errado. A varredura manual levou umas duas horas. A automática teria custado o mesmo tempo em revisão, com o bônus da ansiedade de ter deixado passar algum comando mutilado.

Teve também um caso estrutural esquisito no ep146, sobre Docker Compose. Duas cues ficaram grudadas por causa de uma linha em branco faltando no SRT, e o pysrt tratava as duas como uma única cue gigante. O TTS nem chegava a processar, o chunker engasgava antes. Corrigi à mão adicionando a linha em branco que faltava. Fix de um caractere, meia hora pra rastrear.

Reconstruindo SRTs truncadas

Outra armadilha apareceu quando fui rodar o batch completo: três episódios tinham legendas em inglês curtas demais em relação à duração real do vídeo. O ep056, sobre Rails, era o caso mais absurdo. Dezenove minutos de legenda pra um vídeo de 80 minutos. Sessenta e dois minutos de conteúdo sem legenda nenhuma. O ep057 (WSL 2) tinha 14 minutos faltando, e o ep068 (Git Direito) tinha 2.

Isso é rastro do meu fluxo de tradução antigo. Em algum momento eu comecei a revisar a legenda manualmente, parei no meio, e o arquivo .en.srt ficou salvo truncado no ponto onde eu parei. Não dá pra dublar um vídeo de 80 minutos com legenda de 19. O chunker gera áudio até onde consegue ler e simplesmente não sabe o que fazer com o resto do vídeo.

A solução virou um script novo. Ele faz diff entre o .en.srt truncado e o .pt-orig.srt (o auto-caption bruto do YouTube, que sempre cobre o vídeo inteiro), pega as cues que existem só em português, manda pro Claude Sonnet 4.6 com um schema JSON rígido pedindo tradução cue a cue, e cola o resultado de volta no fim do arquivo em inglês. O schema é o detalhe que importa. Quando eu tentei pedir a resposta em texto no formato N|texto, o Claude deixava cair umas 20% das cues no caminho. Com um schema JSON estrito, a taxa de drop caiu pra zero nos três reparos.

O resultado em números:

• ep068 Git Direito: +50 cues / 2 minutos reconstruídos
• ep057 WSL 2: +368 cues / 14 minutos
• ep056 Rails: +1445 cues / 62 minutos (e ainda drop de 5 cues falsas que o tradutor antigo tinha inventado no fim pra tampar a saída)

Depois dos reparos, os três episódios entraram no batch normalmente e foram dublados como qualquer outro. Tipo de ferramenta que você espera nunca precisar, só que quando precisa, compensa escrever uma vez e resolver o problema inteiro de uma vez.

Tags de emoção automáticas

Enquanto eu tava testando, resolvi adicionar mais um passo no pipeline: um “emotion tagger” que lê o SRT em inglês antes de mandar pro TTS e insere tags tipo [sarcastic], [thoughtful], [emphatic], [deadpan] em pontos onde um narrador humano naturalmente mudaria o tom. A ideia é imitar o que um ator profissional faria, colocar ênfase nos momentos certos, sem transformar o vídeo num teatro de emoções exageradas.

Essa parte é delicada por dois motivos. O primeiro: deixar um LLM solto editando o SRT tem risco real de ele “melhorar” o texto (trocar uma palavra aqui, reescrever uma frase ali) e você acabar com uma dublagem que não bate com a legenda. O segundo: LLM adora exagerar. Se você pedir pra marcar emoção, ele vai colocar tag em toda segunda frase. Pra evitar os dois, eu fixei uma lista pequena de tags permitidas e rodo uma validação de round-trip depois que a resposta do Claude chega:

ALLOWED_TAGS: frozenset[str] = frozenset({
    "[sarcastic]", "[thoughtful]", "[emphatic]",
    "[deadpan]", "[serious]", "[amused]",
    "[sighs]", "[exasperated]", "[confident]",
    "[matter-of-fact]",
})

def validate_tagged(original, tagged):
    """Garante que o SRT com tags preserva o original sem drift."""
    if len(original) != len(tagged):
        raise TagValidationError("cue count mismatch")

    for o, t in zip(original, tagged):
        # O index e o timestamp têm que bater byte a byte.
        if o.index != t.index or o.timestamp != t.timestamp:
            raise TagValidationError(f"cue {o.index}: header drift")

        # Qualquer tag fora da whitelist invalida tudo.
        bad = find_disallowed_tags(t.text)
        if bad:
            raise TagValidationError(f"cue {o.index}: {bad}")

        # O texto sem as tags tem que ser idêntico ao original.
        # Se o LLM trocou uma palavra, reescreveu algo, a
        # validação quebra e a resposta é rejeitada.
        if strip_tags(o.text) != strip_tags(t.text):
            raise TagValidationError(f"cue {o.index}: text drift")

Quando a validação quebra, a pipeline ignora a resposta e reemite o request (ou, se falhar muito, sobe o SRT sem tags mesmo). Sobre a quantidade de tags, o prompt que vai pro Claude diz explicitamente: mira em N/10 tags pra um SRT de N legendas, chão de 1 tag a cada 12, teto de 1 tag a cada 7, distribuição equilibrada entre os quatro quartos do episódio, nunca duas tags adjacentes a menos de 4 legendas uma da outra. Esse conjunto de regras foi a sexta iteração — as cinco anteriores ou enchiam tudo de tag ou concentravam no começo do vídeo.

Não deixe a v3 alucinar

Um detalhe crítico que só aparece em produção: a ElevenLabs v3 tende a alucinar quando você manda blocos de texto muito longos. Já peguei blocos onde o texto tinha uns 1.500 caracteres e o modelo gerou um áudio com nove minutos quando o esperado era um minuto e meio. O modelo simplesmente resolve continuar falando sozinho, inventando conteúdo.

A documentação oficial da ElevenLabs recomenda manter cada chamada abaixo de 800 caracteres pra evitar isso. Eu fui mais conservador e cortei em 700, sempre em fim de frase (nunca no meio de uma sentença, porque o corte no meio soa horrível quando concatena). Depois disso, subi o parâmetro stability pra 0.9 (modo Robust, mais estável porém menos responsivo a tags de emoção), liguei o apply_text_normalization pra o modelo pronunciar números e siglas direito, e adicionei uma verificação de sanidade que rejeita qualquer áudio gerado que passe de 1.8× da duração esperada.

DEFAULT_VOICE_SETTINGS = {
    "stability": 0.9,          # modo Robust
    "similarity_boost": 0.95,
    "style": 0.0,
    "use_speaker_boost": True,
}

EXPECTED_CHARS_PER_SEC = 16.0
CHUNK_SANITY_MAX_FACTOR = 1.8   # rejeita se actual > 1.8× esperado

Depois dessas mitigações, um episódio de 95 minutos (194 blocos) rodou do começo ao fim sem nenhuma alucinação. Exatamente um bloco falhou por erro 502 transitório da API, que o retry automático pegou na tentativa seguinte.

Masterização pro YouTube

O YouTube não publica número oficial, mas o consenso da indústria é que a normalização de volume dele na hora da reprodução mira em -14 LUFS. Se você entregar áudio mais alto que isso, o YouTube baixa; se entregar mais baixo, ele deixa como tá. Pra bater o alvo exato, o pipeline roda o filtro loudnorm do ffmpeg em duas passadas. A primeira mede o áudio inteiro e imprime as estatísticas (input_i, input_tp, input_lra, input_thresh) em formato JSON no stderr. A segunda passada lê essas estatísticas de volta e aplica um ganho estático linear pra pousar exato em -14 LUFS, -1.5 dBTP:

# Passada 1: medir
ffmpeg -i final_en.mp3 \
  -af "highpass=f=80,loudnorm=I=-14:TP=-1.5:LRA=9:print_format=json" \
  -f null -

# Passada 2: aplicar ganho linear com os valores medidos
ffmpeg -i final_en.mp3 \
  -af "highpass=f=80,loudnorm=I=-14:TP=-1.5:LRA=9\
:measured_I=-18.3:measured_TP=-3.1:measured_LRA=5.4\
:measured_thresh=-28.7:offset=1.2:linear=true" \
  -ar 48000 -ac 2 -c:a pcm_s16le final_en_mastered.wav

Duas passadas em vez de uma porque o modo de passada única roda em compressão dinâmica e acaba “bombeando” o ganho em trechos com muito silêncio. Com linear=true na passada 2, o ganho fica estático em cima das medições da passada 1, então não tem bombeamento. O resultado pousa dentro de ±0.1 LU do alvo, que é praticamente inaudível. O filtro highpass=f=80 na frente derruba rumble de ar-condicionado e hum de rede elétrica abaixo de 80 Hz, que o ouvido humano não escuta mas mexe nas medições de pico.

O ponto em que eu achei que estava pronto. E não estava.

Aqui entra a parte mais chata, e mais educativa, do projeto.

Eu realmente achei que tinha acertado a mão na primeira grande rodada. A pipeline fechou os 146 episódios, eu subi tudo, e parecia resolvido. A duração batia, os arquivos estavam todos lá, o processo inteiro tinha finalmente atravessado o lote completo de quase 96 horas de vídeo. Só que foi justamente depois do upload que comecei a perceber problemas que eu simplesmente não tinha antecipado.

O primeiro susto foi a situação dos jingles. Eu já sabia que muitos episódios do Akitando começam com aquele jingle instrumental curto antes de eu começar a falar, mas subestimei o problema. O .srt do YouTube praticamente não ajuda nisso, porque jingle não é fala. Às vezes ele marca como [Música], às vezes não marca nada útil, às vezes a janela fica torta. Na primeira montagem, teve episódio onde o jingle sumiu, episódio onde ele entrou duplicado, e episódio onde o source-fill do áudio original já trazia o jingle certo e o meu splice vinha por cima, empurrando todo o resto pra frente. Foi o tipo de bug que só aparece quando você para pra escutar a master final de verdade, não quando olha só pra duração total.

A solução foi abandonar a esperança de que a legenda me diria onde estava o jingle e ir direto pra fonte. Montei um detector usando os próprios áudios originais dos vídeos e jingles de referência, com auditoria e repair pass em cima dos masters já gerados. Isso acabou virando um mini-sistema próprio: detector, auditoria, reassemble por cache, correção por janela exata. No fim dessa novela, o batch de episódios alterados caiu num conjunto de reupload bem definido e o problema dos jingles ficou finalmente sob controle. Foi um daqueles casos clássicos de produção: a primeira solução parecia suficiente até bater no acervo inteiro.

Só que aí veio a segunda pancada, e essa foi mais cara: eu tinha esquecido de um detalhe fundamental sobre legendas de YouTube. SRT é feita pra ser lida na tela, não pra virar roteiro de fala. Então uma ideia que no meu texto original era um parágrafo inteiro aparecia quebrada em várias cues pequenas, cada uma com sua microjanela de tempo. Na primeira versão da pipeline eu estava usando essas cues como unidade de geração na ElevenLabs. Resultado: o TTS gerava áudio em blocos coerentes localmente, mas a montagem introduzia silêncios artificiais no meio da frase. Tecnicamente alinhado, humanamente esquisito.

O conserto foi doloroso porque exigiu voltar várias casas. Em vez de respeitar a estrutura das cues do SRT, precisei voltar pros meus textos originais e reconstruir o chunking com base nos parágrafos que eu realmente li quando gravei os vídeos. Quase todo episódio do Akitando tem o post correspondente com a seção ## Script, e isso salvou o projeto. Como eu fui meticuloso na época em que produzi os vídeos — escrevendo os roteiros antes, lendo exatamente aquilo na gravação e arquivando tanto os vídeos quanto os scripts — eu tinha a fonte de verdade. Então deu pra mapear os parágrafos do script aos timings do .pt-BR.srt, reagrupar o .en.srt em cima disso e regenerar os chunks no formato certo.

O problema é que essa mudança destrói o cache anterior. Mesmo quando o texto quase não muda, se a fronteira do chunk muda, a chamada ao TTS muda junto: muda contexto, muda prosódia, muda começo, muda fim. Então não era um retoquezinho. Era uma regeneração completa de tudo de novo. Foi aí que o custo começou a sair do meu controle inicial.

E quando eu achei que agora sim tinha terminado, veio a terceira paulada: os clipes externos. Muitos vídeos do canal têm trechos inseridos de outras fontes. No episódio de Ruby on Rails, por exemplo, tem 37signals, Apple, comerciais, pedaços externos no meio da narrativa. O .srt do YouTube não sabia lidar direito com isso. Em alguns pontos ele simplesmente alucinava texto, em outros os timings ficavam completamente tortos, em outros a fala original não tinha nada a ver com a legenda que eu estava usando de base. De novo: olhando só pra automação parecia tudo bem; escutando a master final, não estava.

A correção, mais uma vez, foi sair da legenda e voltar pro material original. Montei um detector de janelas de clipe externo a partir de gaps de alinhamento entre transcript, .pt-BR.srt, cues sem fala útil e chunks que atravessavam essas janelas. Depois, em vez de tentar dublar o que não fazia sentido dublar, o processo passou a recuperar o áudio original do vídeo exatamente nesses trechos e preencher a master com o source correto. Foi isso que consertou os casos de 37signals, Apple Education, comercial de Mac vs PC e outros inserts parecidos que eu tinha esquecido que existiam.

Esse foi o aprendizado mais importante dessa segunda metade do projeto: automação te leva muito longe, mas o acervo completo sempre tem mais cantos escuros do que você imagina no primeiro passe.

Os números do batch de dublagem (e por que doeu mais do que eu imaginei)

Eu preciso me corrigir de novo. Não errei só a primeira conta. Errei também o grau de confiança que eu tinha depois da primeira rodada.

Quando subi pro plano Business da ElevenLabs, eu achei que finalmente estaria com folga. Na prática, não fiquei. O screenshot mais recente do dashboard mostra 10.046.279 créditos consumidos de um limite de 11.000.000, sobrando 953.721:

Em português claro: eu torrei mais de 91% do limite do workspace Business. E isso ajuda a entender o que “10 milhões de créditos” realmente significa nesse contexto. Não é só “renderizei 146 episódios uma vez”. É renderizar 146 episódios, descobrir um problema estrutural, voltar, corrigir, regenerar chunks, descobrir outro problema estrutural, voltar, reconstruir masters, auditar jingles, reparar janelas de clipes externos, reupar de novo. Cada rodada a mais custa. E quando a mudança invalida o cache, custa muito.

O custo também não para na ElevenLabs. Todo o trabalho de curadoria das legendas, reescrita de cues problemáticas, reconstrução de SRTs truncadas, auditorias de jingle, detector de clipes externos e o resto rodou via Claude Code no plano Claude Max 20×. Somando isso com a tradução em massa do blog pra inglês que eu descrevi no artigo de aniversário, o limite semanal do Claude Max 20× bateu 100%, com gasto extra acima de R$ 300. Pra quem acha que IA generativa vira grátis depois que você assinou o plano, os boletos discordam.

Mesmo assim, continuo achando que vale a pena. Estamos falando de 146 episódios, quase 96 horas de conteúdo técnico, mais de 5 anos de acervo do canal. Fazer isso manualmente em estúdio, com ator, direção, pickup e revisão humana em tudo, custaria uma ordem de grandeza completamente diferente.

O que mudou foi minha visão do projeto. No começo eu tava olhando pra isso como “um batch grande”. No fim, era outra coisa. Era mexer num acervo inteiro, achar exceção escondida, consertar ferrugem antiga, refazer master, rerender, reouvir.

O primeiro batch completo levou pouco menos de dois dias e me fez pensar que eu tinha resolvido tudo. Não tinha. A segunda rodada, com chunking por parágrafo, já foi cara. A terceira, com os reparos de jingle e os consertos de masters, mais cara ainda. E a quarta pancada veio dos clipes externos que eu não tinha modelado direito na primeira automação.

Mas agora, finalmente, eu acho que acabou. Ou melhor: eu espero que tenha acabado. Tudo foi enviado de novo, pela última vez. Não está perfeito no sentido absoluto da palavra. Está tão bom quanto eu consigo deixar com script, auditoria e automação, sem entrar num inferno de intervenção manual vídeo por vídeo.

E se isso tudo foi possível, é porque anos atrás eu tive a disciplina de produzir os vídeos do jeito certo: escrever primeiro, ler o roteiro quando gravava, e arquivar os materiais depois. Sem os vídeos originais e sem os scripts originais, eu não teria como descobrir onde o .srt mentia, onde o timing estava torto, onde o clipe externo entrava, onde o parágrafo original começava e terminava. Essa organização antiga foi o que permitiu consertar o projeto agora.

Então sim: a dublagem dos 146 episódios está pronta. Não perfeita. Mas fechada. Pelo menos, eu sinceramente espero que agora sim esteja.

O primeiro teste, assista

Fiz um vídeo teste pra provar que funciona. Dois avisos antes: primeiro, o embed abaixo já carrega com a legenda em inglês ligada por padrão, então esse lado dá pra resolver via URL. Segundo, o áudio é chato: o YouTube removeu o seletor de faixa de áudio dos players embedados lá por março desse ano. Então dentro do embed você não vai encontrar essa opção no menu de engrenagem mesmo, só roda em português. Pra ouvir a dublagem em inglês de verdade, clica em assistir direto no YouTube, que a página principal do YouTube ainda tem o seletor de faixa de áudio no menu de engrenagem.

Se você tá acostumado com a dublagem automática do YouTube ou com as dublagens de IA de TikTok, compara. A diferença é gritante. A voz é a minha, com sotaque americano trabalhado, e a sincronização com o vídeo original fica dentro de 1 a 2% de desvio cumulativo, praticamente imperceptível em 95 minutos de vídeo.

E o que faltava: traduzir as thumbnails

Quando eu estava fechando esse post, me caiu a ficha de que tinha deixado uma ponta solta. As 146 thumbnails do meu canal estão em português, muitas com título em caixa alta grande tipo “9 DICAS PARA PALESTRANTES” ou “7 RECOMENDAÇÕES DE SHOWS PARA PESSOAS DE TECH”. De nada adianta áudio em inglês perfeito se a imagem que aparece na busca é um bloco de texto ilegível pra quem não lê português. O YouTube permite subir uma thumbnail alternativa por idioma, então eu precisava gerar versões em inglês, mantendo o resto da arte idêntico, trocando só o texto.

A ferramenta usa duas peças. yt-dlp é o fork moderno do antigo youtube-dl, uma CLI em Python que baixa qualquer coisa do YouTube (vídeos, áudios, legendas, thumbnails) sem precisar de API key. Nano Banana Pro (nano-banana-pro-preview na API) é o modelo de edição de imagem mais recente do Google Gemini — aceita uma imagem de entrada com um prompt e devolve a imagem editada, preservando o resto da composição quando você pede pra mexer só numa parte.

O pipeline tem dois passos. Passo 1: yt-dlp pega a thumbnail em .jpg, sem baixar o vídeo:

yt-dlp --skip-download \
       --write-thumbnail \
       --convert-thumbnails jpg \
       -o "thumbnails/originals/<slug>/<video_id>" \
       "https://www.youtube.com/watch?v=<video_id>"

Passo 2: mandar cada imagem pro Gemini Nano Banana Pro com um prompt que é um contrato rígido de requisitos duros, não só um “traduz isso”:

TASK:
Detect every piece of Portuguese text visible on this image and
translate it to clear, natural American English. Replace the
Portuguese text with the English translation in the same visual
position.

STRICT REQUIREMENTS — follow every one:
- Preserve EVERY non-text element identically: face, pose,
  expression, background, color palette, lighting, icons, logos,
  decorative shapes, borders, layout. Only the text changes.
- The English translation must be IDIOMATIC and CONFIDENT — not
  a literal word-for-word rewrite. It's a YouTube thumbnail for a
  tech audience, so use punchy phrasing a native English-speaking
  tech YouTuber would write.
- Match the original text's font family, weight, size, color,
  stroke outline, drop shadow, and any decorative treatment.
- If there is no Portuguese text at all on the image, return the
  original image unchanged.

A cláusula “return the original image unchanged” é o que salva os primeiros episódios do canal, que não têm texto na thumbnail, só minha cara. Sem ela, o modelo invariavelmente ia “melhorar” a composição, trocar a iluminação, etc.

Olha o resultado em dois exemplos (episódios 10 e 11):

Original (PT)

Traduzida (EN)

Original (PT)

Traduzida (EN)

Repara no detalhe do episódio 10. O modelo não traduziu “7 Recomendações de Shows para Pessoas de Tech” literal pra “7 Show Recommendations for Tech People”, que seria a versão tradutor automático. Ele reformulou pra “7 TV Shows You Must Watch If You’re In Tech”, como um tech YouTuber americano de verdade escreveria. O resto da imagem fica idêntico pixel a pixel. No episódio 11, “9 DICAS PARA PALESTRANTES: venda sua caneta” vira “9 TIPS FOR SPEAKERS: sell your pen”, com fonte, caixa alta e posição preservadas. Se você não soubesse que o original era em português, não dava pra adivinhar que é uma edição automática feita por IA.

Custo do lado Gemini: alguns centavos por imagem, poucos dólares totais pro batch inteiro. Trivial perto dos $1.500+ do dub. Com a thumbnail resolvida, a conversão do canal pra inglês fica fechada — áudio clonado pela ElevenLabs v3 em cima das legendas curadas em .srt, e a imagem editada pelo Nano Banana Pro pra o título bater com o resto.

A conclusão, que é o título desse post

Quando o Qwen3 TTS saiu, o hype dizia que era “ElevenLabs killer”. Passei semanas tentando viver com essa premissa na prática, com conteúdo real no ar toda semana. E o que eu descobri é que open source de TTS ainda tá muito longe da ElevenLabs. A diferença é grande, e ela aparece justamente quando você sai do tweet de demo de 5 segundos e coloca o modelo pra rodar um podcast semanal de 30 minutos de verdade.

Na prática, o Qwen3 nem bate o modelo v2 da ElevenLabs. O v3, que é o atual, fica um degrau acima do v2 ainda. A prosódia sai melhor, as tags de emoção no meio do texto funcionam em português e em inglês sem esforço, e a API fica de pé sem você precisar manter servidor nenhum. O custo por caractere é um pouco mais alto, mas pro meu volume atual ele fica confortavelmente dentro do orçamento e me devolve horas que eu gastava cuidando de GPU.

A lição aqui é a mesma que a galera de LLMs tá aprendendo devagar. Demo de tweet de 30 segundos é uma coisa, produção é outra coisa completamente diferente. Open source tem seu nicho, principalmente quando você tem dado sensível que não pode sair de casa, ou quando você tem muita GPU ociosa e pouco orçamento recorrente. Só que pra uso sério de TTS em produto comercial, aqui em abril de 2026, a ElevenLabs segue imbatível. O Qwen3 não matou ninguém.

E não esquece: assina o The M.Akita Chronicles no Spotify pra não perder episódio novo desses, feito com a nova pipeline.

Eu comprei um Minisforum MS-S1 Max com o novo chip AMD Ryzen AI Max+ 395 por um motivo específico: esse chip suporta até 128GB de RAM unificada, e eu posso alocar 96GB como VRAM pro iGPU. Isso me dá mais VRAM do que qualquer placa gamer comercial, incluindo a RTX 5090 (32GB). E isso muda o que eu consigo rodar localmente.

Por que trocar o Intel NUC

O NUC serviu bem como servidor Docker por dois anos. Mas a limitação era clara: sem GPU com VRAM suficiente, eu não conseguia rodar LLMs localmente de forma usável. O Frank Yomik, meu sistema de tradução automática de mangás, precisava de OCR via CPU (lento) e conectava remotamente no Ollama do meu desktop (AMD 7950X3D + RTX 5090) pra tradução. Funcionava, mas significava que meu desktop precisava estar ligado pro servidor funcionar.

Com o Minisforum, o Frank Yomik roda inteiramente no servidor. O worker agora usa ROCm pra OCR com a iGPU, e o Ollama roda local com 96GB de VRAM. Zero dependência do desktop.

Na foto dá pra ter uma ideia do tamanho. O NUC é aquele cubinho pequeno na esquerda. O Minisforum é maior, mas ainda é um mini-PC. Cabe na prateleira do rack embaixo do Synology NAS sem problema.

As specs

O chip é o AMD Ryzen AI Max+ 395: 16 cores / 32 threads Zen 5, com iGPU Radeon 8060S integrada e 128GB de LPDDR5X unificada. No BIOS, eu configurei UMA Frame Buffer Size pra 96GB, o que deixa ~30GB de RAM pro sistema operacional e containers. Mais os parâmetros de kernel pra TTM (sem eles, o ROCm só enxerga 15.5GB mesmo com a alocação do BIOS).

O sistema operacional é openSUSE MicroOS (mais sobre isso no próximo post). O consumo de energia da máquina inteira fica abaixo de 100W, o que é absurdo pra quem está acostumado com GPUs dedicadas que puxam 450W+ sozinhas.

Minisforum vs meu desktop: benchmarks

Eu rodei um conjunto de benchmarks comparando o Minisforum com meu desktop (AMD 7950X3D, 96GB DDR5, RTX 5090 32GB GDDR7). Os resultados são claros.

CPU

Resultados mistos. O AI Max+ 395 é melhor em paralelismo puro (sieve multi-core), provavelmente por conta da latência menor na arquitetura de memória unificada. O 7950X3D ganha em float e crypto por causa dos clocks mais altos e do 3D V-Cache.

Inferência de LLMs (modelos que cabem nos dois)

Aqui é onde a coisa fica interessante. Pra modelos que cabem nos 32GB da RTX 5090, a comparação é puramente de bandwidth de memória:

A RTX 5090 é ~7x mais rápida. A explicação é simples: GDDR7 tem ~1.792 GB/s de bandwidth. LPDDR5X tem ~256 GB/s. A razão (7x) bate quase exatamente com a diferença de velocidade medida (6.7x). Inferência de LLM é um problema dominado por bandwidth de memória. Quem lê pesos mais rápido, gera tokens mais rápido.

E o prompt processing?

Prompt processing é ainda pior: 7-11x mais lento. Faz sentido, porque o prompt precisa ser processado inteiro antes de gerar o primeiro token, e é uma operação ainda mais bandwidth-intensiva.

Onde o Strix Halo ganha: modelos grandes

Agora vem a razão pela qual eu comprei esse PC. Modelos que não cabem na RTX 5090:

O qwen3.5:122b com 81GB de pesos rodando a 19 tok/s. Num mini-PC. Isso simplesmente não é possível numa RTX 5090. Na placa da NVIDIA, esse modelo teria que fazer offload de camadas pra RAM do sistema, caindo pra 2-3 tok/s. Na prática, inutilizável.

A diferença entre modelos MoE e densos é brutal. O qwen3.5:35b roda a 43 tok/s porque, apesar de ter 35B de parâmetros totais, só ~4B ficam ativos por token. Um modelo denso de 72B como o qwen2.5:72b precisa ler 40GB+ de pesos por token, e a 256 GB/s de bandwidth, o máximo teórico é ~6.7 tok/s. Os 4.5 medidos representam ~67% de eficiência, que é o esperado pra iGPU (overhead de bus compartilhado e drivers).

Resumo: quando usar cada máquina

Um bug de ROCm que ainda existe

Nem tudo funciona. Modelos como deepseek-r1:70b, llama3.3:70b e llama4:scout crasham com um bug no ggml (GGML_ASSERT(ggml_nbytes(src0) <= INT_MAX) failed). O tensor de embedding desses modelos excede 2GB e o kernel de cópia do ROCm usa inteiro de 32 bits pro tamanho. No CUDA (NVIDIA) já foi corrigido, mas no ROCm ainda não. Esperando o fix no Ollama 0.20.0+.

LPDDR5X vs GDDR7: por que essa diferença

A pergunta que vem é: por que a LPDDR5X é tão mais lenta?

GDDR7 é memória dedicada de GPU. Ela fica soldada na placa de vídeo, conectada por um barramento largo (384 ou 512 bits na RTX 5090) com clocks altos. O único trabalho dela é alimentar a GPU com dados. LPDDR5X é memória unificada que serve pra tudo: sistema operacional, aplicações, e GPU ao mesmo tempo. O barramento é mais estreito e compartilhado.

Na prática: GDDR7 entrega ~1.792 GB/s dedicados pra GPU. LPDDR5X entrega ~256 GB/s que ainda precisam ser divididos entre CPU e GPU. Inferência de LLM é basicamente “leia todos os pesos do modelo da memória, multiplique pelo token atual, gere o próximo token, repita”. Quem lê mais rápido, gera mais rápido. Não tem atalho.

A vantagem do Strix Halo não é velocidade. É capacidade. 96GB de VRAM num chip de 100W que custa uma fração de uma GPU profissional. A RTX 5090 é 7x mais rápida, mas trava em 32GB. Modelos que não cabem, não rodam.

As alternativas: quem mais faz isso?

Se 96GB não é suficiente ou se você quer mais velocidade, as opções são poucas.

O Framework Desktop usa o mesmo chip AI Max+ 395 com até 128GB de RAM. Mesma plataforma, mesma performance, mas com o diferencial de ser modular e reparável (é o Framework, afinal). Na prática é equivalente ao Minisforum em specs e preço.

Acima disso, a alternativa é o Mac Studio com M3 Ultra. O chip M3 Ultra suporta até 512GB de memória unificada, com bandwidth de ~819 GB/s (mais de 3x o Strix Halo). A Apple fabrica os chips de memória no package, então a latência e a bandwidth são superiores. Você poderia potencialmente alocar ~400GB como VRAM e rodar modelos que não cabem em lugar nenhum fora de servidores com GPUs profissionais.

O NVMe interno da Apple também é outro nível: ~7.4 GB/s de leitura sequencial no M3 Ultra, comparado com ~14 GB/s do Crucial T700 (PCIe 5.0). O T700 é mais rápido em throughput bruto, mas a latência do NVMe da Apple tende a ser menor em I/O aleatório por causa da integração com o SoC.

O preço no Brasil é o elefante na sala. A configuração máxima do Mac Studio custa $9.999 nos EUA. Com impostos de importação (~60% + ICMS estadual), passa dos R$ 110.000. O Minisforum com 128GB sai por R$ 12.000-15.000. A diferença de quase 8x no preço compra muita coisa.

Se você precisa de mais de 96GB de VRAM pra modelos realmente enormes (DeepSeek-V3 com 671B parâmetros cabe em ~400GB Q4, por exemplo), o Mac Studio com 512GB é a única opção consumer. A alternativa seria GPUs profissionais NVIDIA A6000 (48GB VRAM, ~$6.000 cada, e você precisaria de várias em NVLink). Pra tudo que cabe em 96GB, o Minisforum faz o trabalho por uma fração do custo.

E projetos que prometem rodar LLMs grandes em GPUs pequenas?

Existe o conceito de “layer offloading” que projetos como llama.cpp já suportam. A ideia é: se o modelo não cabe inteiro na VRAM, mantém algumas camadas na GPU e o resto na RAM do sistema. A GPU processa as camadas que estão nela, transfere pro CPU processar o resto, e volta.

Na prática, não funciona bem. O gargalo é o PCIe: a velocidade de transferência entre RAM do sistema e VRAM da GPU é de ~32 GB/s (PCIe 5.0 x16). Cada token gerado precisa transferir dados ida e volta. O resultado é que você cai de 150 tok/s (tudo na VRAM) pra 2-8 tok/s (offload parcial). É lento demais pra uso interativo.

A VRAM é a limitação fundamental porque inferência de LLM é memory-bandwidth-bound, não compute-bound. A GPU tem compute sobrando. O que falta é capacidade de ler os pesos do modelo rápido o suficiente. Quando parte dos pesos está em RAM via PCIe, o pipeline inteiro espera pela transferência.

É por isso que memória unificada (como no Strix Halo ou no Apple Silicon) faz diferença. Não tem PCIe no meio. CPU e GPU acessam a mesma memória física. Os 256 GB/s do Strix Halo são lentos comparados com GDDR7, mas são 8x mais rápidos que ficar fazendo offload via PCIe.

Avanços em otimização de LLMs (até 2026)

Pra entender por que alguns modelos rodam tão melhor que outros no Strix Halo, precisa entender o que mudou no ecossistema nos últimos dois anos.

Mixture of Experts (MoE)

Se você roda modelos locais, MoE é o avanço que mais importa. Um modelo MoE tem parâmetros totais altos (ex: 122B no qwen3.5:122b), mas ativa apenas uma fração deles por token (ex: ~4B). Os pesos inativos ficam na VRAM mas não são lidos a cada token, o que reduz drasticamente a bandwidth necessária.

Nos benchmarks do Strix Halo, modelos MoE rodam 3-10x mais rápido que modelos densos do mesmo tamanho. O qwen3.5:35b (MoE, ~4B ativos) roda a 43 tok/s enquanto o qwen2.5:72b (denso, 72B ativos) roda a 4.5 tok/s.

DeepSeek e a otimização de treinamento

O DeepSeek V3 (dezembro 2024) mostrou que era possível treinar modelos de 671B parâmetros com custo uma ordem de magnitude menor que o previsto. Eles combinaram MoE com quantização FP8 durante o treinamento (não só na inferência), treinamento multi-estágio com curriculum learning, e várias otimizações de comunicação entre GPUs. O impacto: todo mundo copiou. Qwen, GLM, MiniMax, todos adotaram variações dessa técnica.

Quantização: de FP16 pra Q4 sem perder muito

Quantização comprime os pesos do modelo de 16 bits (FP16) pra formatos menores: 8 bits (Q8), 4 bits (Q4), ou até 2 bits. Um modelo de 70B que ocuparia ~140GB em FP16 cabe em ~40GB em Q4_K_M. A perda de qualidade existe, mas nos formatos modernos (GGUF Q4_K_M, AWQ, EXL2) é pequena o suficiente pra uso prático.

O GGUF (formato do llama.cpp) se tornou o padrão pra inferência local. AWQ e GPTQ são alternativas com calibração mais sofisticada, mas o ecossistema convergiu pro GGUF porque ele funciona em CPU, CUDA e ROCm sem recompilação.

Destilação: modelos menores que sabem mais

Destilação é treinar um modelo pequeno usando as respostas de um modelo grande como professor. O Phi-4 da Microsoft (14B) foi treinado com destilação do GPT-4 e compete com modelos de 70B em vários benchmarks. O Qwen3 fez o mesmo: o qwen3:14b é surpreendentemente capaz pro tamanho.

Flash Attention e KV Cache otimizado

Flash Attention (Tri Dao, 2022) mudou como attention é computada: em vez de materializar a matriz inteira de attention na memória, processa em blocos mantendo os dados no SRAM on-chip da GPU, reduzindo consumo de memória de O(n²) pra O(n). Sem isso, contextos de 128K+ tokens seriam impraticáveis. Já passou pelas versões 2 e 3, com otimizações pra FP8 e operações assíncronas no H100. O PagedAttention (vLLM, UC Berkeley) fez o mesmo pro KV cache durante serving: aplica conceitos de memória virtual ao cache, eliminando fragmentação e melhorando throughput 2-4x.

No Ollama, eu configurei OLLAMA_FLASH_ATTENTION=1 e OLLAMA_KV_CACHE_TYPE=q8_0 no servidor. O primeiro ativa flash attention, o segundo usa KV cache em 8-bit em vez de fp16, cortando a bandwidth necessária pela metade por token. São otimizações que custam zero em hardware e melhoram throughput mensurável.

O que Qwen, Kimi, MiniMax e GLM estão fazendo

O Qwen (Alibaba) tem sido consistentemente o melhor custo-benefício em modelos open source. O Qwen3:14b é denso e forte; o Qwen3.5:122b é MoE e roda surpreendentemente bem em 96GB. O GLM-4.7 (Zhipu AI) é notável por oferecer versões bf16 full precision que rodam inteiras em 96GB. O MiniMax experimentou com contextos longos (até 4M tokens). O Kimi (Moonshot AI) focou em context windows grandes com arquiteturas lineares.

O que roda bem em 96GB de VRAM

Com 96GB no Strix Halo, os modelos que funcionam bem pra uso diário:

Modelos densos de 70B+ (deepseek-r1:70b, llama3.3:70b) ainda estão bloqueados pelo bug do ROCm que mencionei. Quando for corrigido, devem rodar a ~4-6 tok/s, usáveis pra batch mas não pra chat interativo.

Conclusão

Eu comprei o Minisforum pra rodar modelos que não cabem em GPU gamer nenhuma. Pra isso, funciona. Não é rápido. 19 tok/s num modelo de 122B não é a experiência que você tem com Claude ou ChatGPT. Mas é local, é privado, e roda na minha prateleira consumindo menos energia que uma lâmpada antiga.

Pra quem pergunta sobre o Mac Studio: se você tem orçamento, é a melhor máquina pra rodar LLMs locais. 512GB de memória unificada, 819 GB/s de bandwidth, ecossistema Metal/mlx maduro. Dá pra rodar DeepSeek-V3 inteiro em Q4. Mas no Brasil, com importação, passa dos R$ 110 mil. O Minisforum com 128GB por R$ 12-15 mil é a opção realista.

E pra quem acha que dá pra contornar a limitação de VRAM com offloading de camadas: não dá. PCIe é lento demais. O modelo precisa caber inteiro na VRAM pra inferência ser usável. É o motivo pelo qual GPUs gamers com 32GB de GDDR7 ultra-rápida continuam limitadas em tamanho de modelo, e por que a memória unificada do Strix Halo e do Apple Silicon mudou a equação.

No próximo post eu conto como migrei todo o home server pro Minisforum usando Claude Code, os problemas que encontrei, e como o openSUSE MicroOS se comporta como sistema operacional de servidor Docker.

Se não assistiu, recomendo que assista a trilogia de videos depois:

• Entendendo Teclados Mecânicos | Minha coleção - Parte 1
• Teclados Mecânicos Exóticos | Minha coleção - Parte 2
• Caminho pro Melhor Teclado do Mundo!

Primeiro Aviso: antes que os chatos comentem. Sim, teclados mecânicos são caros. MUITO CAROS. Sim, dá pra escrever livros inteiros num teclado de 50 reais da Multilaser comprado na Kalunga. Não precisa ter switches mecânicos, não precisa de tecla PBT double-shot. Não precisa mudar de layout, qwerty staggered tradicional funciona muito bem. Não precisa de unibody de alumínio. Não precisa de RGB. Não precisa gastar R$ 2.500 num modelo topo de linha. Definitivamente não precisa. Quem faz a obra-prima é o autor e não o teclado.

Isso dito, sim, dá pra ir de São Paulo pra Bahia num Fusca. Ele vai servir sua função de levar do ponto A ao ponto B, como meu pai faria quando era jovem, como meu avô faria na época dele. Funciona perfeitamente bem. Mas, alguns de nós preferem fazer o mesmo trajeto com ar-condicionado, poltronas ergonômicas, som de qualidade, mais velocidade e mais segurança. Nada disso é obrigatório. Ir do ponto A ao ponto B pode ser feito de várias formas diferentes. Se pra você isso não inclui investir em carros caros, não precisa. Use seu Fusca e seja feliz. Este artigo é somente pra quem gosta de Porsche e vê valor nisso.

Segundo Aviso: a maioria das fotos que mostro no artigo estão em alta resolução original. Pra ver mais detalhes, botão direito e “abrir imagem e nova aba”. Faz bastante diferença.

Terceiro Aviso: sim, o artigo é SUPER longo, por isso dá pra navegar pras seções principais usando os links abaixo:

• Layouts e QMK
• Treinamento
• Soluções DIY
• Ortolineares - GK6
• Ortolineares - Q15
• Meu Teclado Favorito - Voyager
• Ortolinear vs Colunar
• O Futuro - Framework

Fim dos avisos. No terceiro video eu começo a explicar a diferença pro melhor tipo de teclado do mundo: os ortolineares ou colunares. Não vou explicar tudo de novo, mas em resumo, eles se livram do legado histórico do layout limitado pelas máquinas de escrever mecânicas e repensam o que seria o melhor layout pensando na posição de verdade dos seus dedos, inclusive levando em conta que você tem dedos mais longos e dedos mais curtos (os colunares pensam nisso, os ortolineares não).

Naquele video eu tinha acabado de migrar pra um ZSA Moonlander. Até hoje ainda é um dos melhores teclados que eu já experimentei. Mas tem dois problemas fundamentais: primeiro que é extremamente caro, faixa de USD 400. Pra nós, brasileiros, é pior ainda porque vai incidir quase 100% de impostos mais transporte, então estamos falando de um teclado de pelo menos USD 800, mais caro que um PS5, quase o preço de um iPhone 16 Pro comprado nos EUA, faixa de preço de um notebook completo.

Mesmo se dinheiro não for um empecilho pra você, o segundo problema, é que ele é fisicamente gigantesco. Ocupa um espaço absurdo na mesa. Mesmo que tenha uma mesa espaçosa, ele vai ser um “trambolhão”, olha só como é:

Mas como disse, a construção da ZSA é de extrema qualidade, os materiais usados incluem metais como alumínio, portanto é tudo muito firme. Os plásticos também são de ótima qualidade. Os switches são removíveis então você pode experimentar um conjunto silencioso como Reds lineares ou barulhentos como Brown ou Blue.

Note também como ele tem inclinação (tenting), que faz o meio ser mais alto, pra evitar pronação dos seus pulsos (um dos maiores ofensores em LER ou tendinite), e por isso também tem apoio pros punhos embaixo. É de longe o mais ergonômico. Além disso tem buraco pra parafuso padrão igual de câmera fotográfica, o que permite encaixar em tripés, caso queira experimentar estilos mais exóticos de postura.

O canal do Ben Vallack explica melhor isso. Lembrando que o canal dele é extremo, não é pra todo mundo, precisa de muita dedicação pra conseguir se acostumar ao estilo dele, mas é legal ter com referência o que é possível fazer pra casos especiais.

Portanto sim, se pra você o tamanho e o preço não importam, este é de longe o teclado mais customizável, ergonômico e de melhor qualidade possível. Muitos vem me perguntar de modelos como o Kinesis - que também é gigante - mas eu prefiro o Moonlander, nessa categoria. Se formato do Kinesis, em particular, for importante, no final vou falar dele rapidinho.

Layouts e QMK

Mas o Moonlander tem um problema praqueles que querem mesmo cruzar a linha da ergonomia extrema: digitar sem tirar os dedos da “home row” a linha do meio, onde ficam as teclas “F” e “J”. O ideal é ter apenas 3 linhas, uma linha pra cima e outra pra baixo da “home row”, mas o Moonlander tem 2 linhas acima e 2 linhas abaixo, além de dois thumb-clusters enormes de 4 teclas cada, o que garante que, se tentar usar todas as teclas, vai acabar movendo a mão pra cima e pra baixo mais do que deveria, perdendo o ritmo e velocidade e, principalmente, a ergonomia.

Este passo não é pra todo mundo, mas depois de muito treinar e experimentar, acabei concordando que o formato mais “balanceado” pra maioria das pessoas que tem intenção de otimizar pra melhor, é o Corne colunar staggered 40%.

Se trata de um teclado colunar, ou seja, as teclas estão alinhadas verticalmente, em vez de zig-zaguear entre as linhas, como num convencional. Também são staggered, mas na vertical, ou seja, segue mais ou menos a proporção vertical de comprimento dos dedos. A coluna do meio vai mais pro alto porque o dedo médio é mais longo. Ortolineares são colunares que não são staggered. Já falo mais deles na próxima seção.

Um Corne 40% tem 40% das teclas que um teclado grande convencional - que costuma ter por volta de 103 teclas. Portanto umas 42 teclas. Como são split, divididas no meio, 21 teclas pra cada lado. Alguns preferem remover as duas últimas colunas de teclas nos dois lados mais extremos do teclado, onde ficam “tab” ou “ctrl”, reduzindo o total pra 18 teclas de cada lado, ou 36 teclas. E tem alguns como o Ben Vallack que conseguem ir ainda abaixo disso, mas já acho extremo demais e pouco prático pra maioria das pessoas.

Mas como usa um teclado com tão poucas teclas? Como faz pra caber tudo? E esse é o ponto: não faz. Em vez de tentar ter todas as teclas, divide-se em camadas virtuais, com uma tecla modificadora que muda a função de cada tecla. Por exemplo, a maioria dos firmwares de teclados bons hoje são baseados em padrões como QMK ou ZMK. Não quero entrar em detalhes, veja o repositório no GitHub do QMK Firmware, mas podemos usar sites como o QMK Configurator pra editar o arquivo JSON de layout, visualmente. Por exemplo:

Este é o layer 0, sem fazer nada, se só sair digitando no meu teclado, são essas as teclas configuradas por padrão. Aqui nada de novidade, mas note embaixo, no “thumb cluster”, onde fica o dedão, tem uma tecla dizendo “MO(1)” que significa “Momentarily Turn Layer On”, ou seja, se deixar essa tecla apertada, enquanto estiver apertada, ele vai mudar pro layout na camada 1, que está configurada assim:

Tá vendo? É assim que, no meu caso, eu tenho acesso a teclas como “page up” ou “page down” ou setas de direção. Quem é de NeoVIM deve ter notado que é a configuração de setas de VIM. Se eu tirar o dedão daquela tecla “MO(1)”, volta pra camada 0 anterior, e lá, tem outra tecla modificadora, a “MO(2)” que muda pro seguinte layout:

É nesta camada que tenho acesso a caracteres especiais como “@” ou “&”, sem precisar esticar meu mindinho até o shift no canto, como se faz num teclado convencional. Uso meu dedão. E com o dedão também tenho acesso a acentos e pontuações. Isso é muito subjetivo e cada um pode configurar como quiser, mas preferi fazer meu dedão trabalhar mais. Num teclado convencional, o dedão esquerdo serve pra dar espaço, mas o dedão direito não serve pra nada. E eles são os dedos mais fortes da sua mão. Por outro lado os dois mindinhos ficam encarregados por shift, acentos, pontuação e, em português, é ainda pior que em inglês, porque temos muito mais acentos.

Digitar em português é, na média, mais lento do que em inglês por conta de acentos e palavras mais longas. Mas no meu caso, dividi melhor e dei mais trabalho pro dedão. Veja meu thumb cluster, na camada 0:

Além de barra de espaço, que coloquei na direita, os dedões ainda tem a função das teclas modificadoras “MO(1)” e “MO(2)” além de delete, backspace e enter. Isso tira muito trabalho dos mindinhos, e me parece uma divisão de trabalho mais justa, que leva em conta a força dos dedos. Essa é a principal vantagem de usar um teclado customizável com firmwares como QMK.

Existem dezenas de sugestões de outros layouts, mas leve em consideração que português, por ter acentos, não pode ser igual aos recomendados por norte-americanos. Onde você vai configurar acentos, vai mudar a velocidade e quantidade erros de sua digitação.

O problema é que precisa ter a mente aberta. Aceite que sua memória de teclados convencionais vai ser inutilizada e vai precisar treinar do zero. Então, em vez de tentar colocar teclas onde já está acostumado, pense em mudar pra onde faz mais sentido pro seu workflow. Por exemplo, alguém de data science ou contabilidade, pode querer colocar as teclas numéricas no formato de calculadora, como num teclado convencional grande, e isso pode ser feito numa das camadas extras. Eu tinha uma camada virtual somente com combinações de teclas pra Da Vinci Resolve, pra acelerar meu workflow de editar videos. O mesmo pode ser feito pra programar específicos como Photoshop ou Premiere.

Treinamento

Pra aprender, não tem outro jeito, precisa treinar, horas e horas, dias e dias. Ajustar as teclas em cada camada não é uma coisa que se faz uma só vez. É um processo. Você muda, começa a treinar e vê se realmente está numa posição adequada. Se não estiver, muda, regrava o firmware, e treina mais algumas horas. Até ficar bom pras suas mãos. Esse processo leva dias. Não tente só copiar layouts de outras pessoas. Use de inspiração, mas pense no seu uso particular.

E treinar não é usar 1 hora e acabou. Migrar de teclado staggered convencional, pra colunar, e com layout diferente, vai levar no mínimo 40 horas de treino. Se você vai dividir 8 horas de treino por 5 dias ou 20 horas de treino em 2 dias, não importa, mas ninguém consegue ficar bom em menos de 40 horas. Pra maioria das pessoas, pense mais em torno de 50 a 100 horas.

Eu digo isso porque muitos usam só alguns minutos e já falam “ah, isso não é pra mim, nunca vou conseguir”. Lógico, alguns minutos não é suficiente. Só depois de umas 10 horas você começa a sentir se quer ou não continuar, antes disso é pura frescura e preguiça.

No começo, logo que migrei, não conseguia digitar mais que 20 palavras por minuto. Treinando mais de 20 horas em 2 dias, num fim de semana, consegui subir pra 70 palavras por minuto e ao final da primeira semana, consegui voltar à minha média antiga de 90 a 100 palavras por minuto (wpm).

E eu tenho mais de 40 anos. Não tem nada a ver com idade. Tem a ver com dedicação em treinar. Isso dito, como treinar? Recomendo os mesmos sites que todo mundo, começando pelo bom e velho Monkey Type.

Esse site é excepcional, dá pra treinar em quase todas as línguas do mundo. Em inglês dá pra treinar com vocabulário simples e evoluir pra dicionários de palavras bem mais avançadas, dá pra mudar o layout de teclado, cores, temas, tudo. Vale fuçar bastante as opções dele.

Outro site bem conhecido é o KeyBr que é parecido com o MonkeyType mas não sei porque, parece que sempre vou mais lento aqui. Também tem bastante customização e vale fuçar. É bom quando estiver cansado de olhar pra cara do MonkeyType e quiser novos ares pra variar.

E quando estiver se sentindo confortável (especialmente quando conseguir achar posições rápidas pra teclas de acento), experimente competir com outros usuários no bom e velho Type Racer:

Diferente do MonkeyType e KeyBr, que não se preocupam tanto com textos que façam sentido e nem pontuação, aqui eles usam trechos de livros e artigos online. Então são trechos de textos de verdade. Também dá pra escolher diversas línguas diferentes. Inicia uma corrida, espera outros usuários aparecerem, e depois de uns 10 segundos já começa a competir.

Em inglês normalmente se fala em WPM ou “palavras por minuto”, que é uma métrica que eu não gosto muito, porque palavras em inglês são muito mais curtos que em português, então 100 wpm em português é muito mais rápido do que 100 wpm em inglês. Já o TypeRacer usa “CPM” que é “caracteres por minuto”, que eu já acho mais justo.

E mesmo assim, em português, parte dos caracteres requerem duas teclas, uma pro acento e outro pra sílaba. Uma palavra como “coração” tem 7 caracteres, mas precisou de 9 toques no teclado pra escrever. Lembrem-se disso se forem treinar mais em português.

Finalmente, existem vários jogos gratuitos pra navegador, em javascript, pra treinar digitação e na Steam tem dois jogos pagos que recomendo pra brincar:

Epistory é bem bonitinho, uma aventura pra relaxar, dá pra crianças jogarem de boa e vai servir pra incentivar a aprender a digitar direito. Já o The Typing of the Dead Overkill é um clássico que tinha nos arcades japoneses (e tinha teclado no arcade!!) e teve versão pra Dreamcast, com um teclado pro console, feito pela Sega e agora dá pra jogar no seu PC. É levinho e divertido e tem muito gore, então não é pra todo mundo. Ambos são baratinhos, por isso recomendo.

Soluções DIY

Infelizmente, teclados ortolineares, colunares, mecânicos no geral, são muito caros. Por isso já explico: não, usar um teclado desses não vai fazer ninguém digitar 10 vezes mais rápido, nem nada disso. É uma opção de conforto, você tem que se importar com isso pra investir. Se pra você um tecladinho genérico da Multilaser já atende, e não sente vontade de mudar, tá ótimo. Continue lendo só pra saber que existem opções, mas não se sinta mal por não estar mudando hoje. Quem sabe mais pra frente.

Pra quem realmente quer mudar mas quer gastar o mínimo possível de dinheiro, precisa gastar mais tempo pesquisando. Lógico, tudo que custa mais caro está embutido o preço da conveniência, já vem tudo montado, bonitinho, é só ligar e usar. Mas quem quer gastar pouco, tem que aprender a opção “DIY” (Do It Yourself) e montar o seu.

Faz algum tempo que eu recomendo as redes sociais do Felipe/Tupinikeebs, tanto no X quanto no Instagram. Ele manja tudo sobre montagem de teclados, sabe como e onde pedir todas as peças e, se pagar um extra, faz o serviço todo de encomendar, montar e te mandar já montado. Nas redes sociais dele dá pra achar tudo que é tipo de modelo diferente e exótico.

Segue ele, dá uma pesquisada no que já postou, e se quiser encomendar, manda DM. O cara é gente boa. Não incomoda com bobagem, por favor, ele tem mais o que fazer.

Na foto anterior temos 3 modelos similares. Dois Cornes e um Hillside (que é tipo um Corne com espaço pra um Rotary, que é aquele cilindro que dá pra girar, como pra volume).

Os dois primeiros usam teclas de impressora 3D, acho que de resina na verdade, uma com perfil mais de Cherry, mais alto e gordo. O segundo mais low profile e fino. O terceiro são teclas Choc low profile comerciais mesmo. Apesar de todos serem bons, eu realmente prefiro teclas industrializadas, de preferência PBT double shot. Não entendeu nada? É porque não assistiu os videos do meu canal (!!)

Só o do meio fui eu que montei meio que do zero, o primeiro e o terceiro foram o Felipe quem me mandou. Você pode tentar assistir tutoriais no YouTube e pesquiser em sites como o BoardSource. Daí comprar diretamente todos os componentes pra montar. Tem que ficar de olho porque nem sempre tem estoque de todos os componentes.

O primeiro e segundo Corne da foto acho que usam o controlador Nice!Nano 2.0 e o terceiro, o Hillside, usa controlador RP2040, que é mais novo e mais avançado. Eu não sou especialista em todos os modelos, mas isso é importante porque varia o tipo de firmware que suportam. Modelos mais parrudos aguentam firmwares mais complexos, com mais customizações. Por isso é bom pesquisar a respeito. O Hillside, por exemplo, tem os rotary, daí precisa ter suporte a tecla que rotaciona.

Quando faz clone do projeto QMK Firmware do GitHub, tem um diretório “keyboards” com todos os modelos conhecidos. No meu caso, fui em “keyboards/hillside/48/keymaps/akitaonrails” e editei o “keymap.c” pra ter este trecho:

/* The encoder_update_user is a function.
 * It'll be called by QMK every time you turn the encoder.
 *
 * The index parameter tells you which encoder was turned. If you only have
 * one encoder, the index will always be zero.
 *
 * The clockwise parameter tells you the direction of the encoder. It'll be
 * true when you turned the encoder clockwise, and false otherwise.
 */
bool encoder_update_user(uint8_t index, bool clockwise) {
  /* With an if statement we can check which encoder was turned. */
  if (index == 0) { /* First encoder */
    /* And with another if statement we can check the direction. */
    if (clockwise) {
      /* This is where the actual magic happens: this bit of code taps on the
         Page Down key. You can do anything QMK allows you to do here.
         You'll want to replace these lines with the things you want your
         encoders to do. */
      tap_code(KC_PGDN);
    } else {
      /* And likewise for the other direction, this time Page Down is pressed. */
      tap_code(KC_PGUP);
    }
  /* You can copy the code and change the index for every encoder you have. Most
     keyboards will only have two, so this piece of code will suffice. */
  } else if (index == 1) { /* Second encoder */
    if (clockwise) {
      tap_code(KC_UP);
    } else {
      tap_code(KC_DOWN);
    }
  }
  return false;
}

O código não é importante agora, só pra vocês terem uma idéia. Isso foi neste caso específico. Na maioria dos casos mais simples, só precisa editar um JSON, e ajuda ter um editor visual como o QMK Configurator via Web que falei antes. Daí coloca o JSON no diretório do seu modelo de teclado e segue a documentação pra compilar o binário do firmware. Não quero ter que explicar passo a passo aqui, mas tem tutorial em todo lugar, depois dêem uma fuçada no Google e YouTube.

Na dúvida, hoje em dia acho que o padrão é comprar Pro Micro e só se não tiver o Nice!Nano v2.0. Esses chips são o que na foto aparecem no centro de cada teclado. É onde fica o cérebro que controla tudo, onde se conecta o cabo USB e o cabo de áudio P1 que conecta as duas metades. Também é onde se ligaria Wi-fi e bateria em alguns modelos. Aí faz mais diferença porque quanto mais potente, mais bateria gasta, menos tempo dura. Então precisa balancear se realmente precisa do chip mais potente.

Olha o meu acima, é wireless, e tem bateria pequena instalada embaixo, acho que é uma Nice!Nano. O acabamento dos fios não ficou grande coisa. Está usando tanto switches Choc quanto teclas low profile estilo Choc, são lineares red, bem finos. Tem gente que prefere um teclado mais alto, eu prefiro mais baixo quanto possível.

Olha essa que o Felipe montou pra mim, com case feito em impressora 3D, bem mais grosso, com switches e teclas de tamanho normal, bem mais alto. O certo é ter apoio de pulso ou acostumar a digitar sem encostar os pulsos na mesa, senão vai dar tendinite rapidinho com essa altura. E tem esses dois buracos na direita onde dá pra colocar parafusos altos, pra fazer “tenting”, que nem expliquei no Moonlander. Então é boa opção pra quem não quer ou não pode pronar os pulsos (que é justamente onde “pinça” o nervo e dá tendinite).

Essa Hillside, na verdade, tinha vindo com as teclas low profile pretas. A minha de antes era que estavam com as teclas brancas low profile Choc, mas fiquei trocando pra experimentar (maus Felipe!! kkkk). Na real, esse conjunto de teclas brancas são as que mais gosto. Note o case mais “lean” roxo que o Felipe fez pra esse board, e o principal, o botão giratório rotary. Dá pra programar pra muita coisa, no momento é só volume, mas acho que dá pra customizar em apps como Photoshop ou edição de video e coisas assim. Eu mesmo não cheguei a tentar, mas pra quem tem essa necessidade, é uma ótima opção.

Ortolineares - GK6

Moonlander, Corne, Hillside e outros são todos teclados colunares, staggered, e split. Eu recomendo fortemente acostumar a usar split. Primeiro porque não precisa aproximar as duas mãos, elas podem ficar afastadas, que é o mais natural.

Segundo, pra aprender a fazer cada mão usar as teclas corretas de cada metade, sem uma mão ficar invadindo a metade da outra. Novamente, faz parte do treino forçar isso. É outra vida quando cada dedo aprende a usar a tecla certa. Muito menos esforço, muito menos cansaço, muito menos dores e ainda aumenta velocidade e diminui quantidade de erros. Só tem vantagem.

Na época que fiz meu video, só tinha um modelo ortolinear que era razoável, o Planck. Planck acho que é o nome do layout, mas tinha mais de um fabricante, como a Drop (antiga MassDrop) e a própria ZSA.

Se quiser comprar as peças separadas pra montar você mesmo, compre a versão Drop + OLKB. E acho que vai ser a única opção porque a ZSA anunciou em Agosto de 2023 que vai parar de fabricar os Planck EZ, o que é uma pena. Parece que não vendia o suficiente pra justificar continuar fazendo.

A única vantagem dele frente aos outros que mostrei até agora, é a mobilidade. Ele é todo de plástico. É muito bem feito e bem construído, não tem cara de plástico barato. Mas por isso é bem leve, e super compacto. De dimensões, se compara a um Nintendo Switch, só mais grosso. Então é muito fácil de carregar numa mochila.

Assim como seu irmão maior, o Moonlander, mas diferente dos Cornes e outros modelos mais baratos, o Planck EZ tinha LEDs coloridos em cada tecla. Parece bobagem, mas agora que você entendeu que dá pra configurar diversas camadas, imagine como é mais intuitivo de encontrar o que procura se, quando apertar um modificador como o “MO(1)”, acender em cores customizadas que te ajudam a lembrar o que era o que.

Por exemplo, no video acima, dá pra ver uma camada que acende parecendo uma calculadora. Veja como acendem embaixo dos 9 números principais, daí 3 teclas na direita e 3 na esquerda com funções como adição, multiplicação, etc, igual à configuração que fiz no Oryx abaixo, entenderam a utilidade?

O problema é que uma vez que se acostuma com split, voltar pra um monolito como esse é muito chato. Trazer as mãos pra perto e ter que angular os pulsos é cansativo. É exatamente o cansaço que se tem todo dia num teclado convencional. Seus pulsos não foram feitos pra serem nem dobrados e nem rotacionados. Um teclado convencional faz exatamente tudo que seus pulsos odeiam.

A solução é tenting e split. Mesmo se tenting ocupar muito espaço, no mínimo split já vai fazer muita diferença. Mas enfim, existe esse meio do caminho entre teclado convencional e teclado colunar, que não exige se acostumar ao split logo de cara. É esse layout ortolinear, que é um colunar não-staggered, ou seja, onde linhas e colunas estão perfeitamente alinhadas, ortogonais e alinhadas (orto-linear, entenderam?), sem levar em consideração o diferente comprimento de cada dedo.

Nessa categoria existem dois modelos que gostei muito. O primeiro é da Gizmo Engineering, o GK6. No meu caso, o modelo Imperial Panda. Todo fã de anime dos anos 2000 gosta do esquema de cor de Panda, como em Initial D.

Na foto coloquei embaixo do Moonlander, pra demonstrar o que falei antes: uma das desvantagens do Moonlander é ser um trambolho na mesa, e não é exagero. Agora, esse GK6, é extremamente bem construído, uma obra de arte na mesa.

O case dele é um unibody de alumínio, nível Apple de qualidade. Internamente tem espuma pra “dampening” do som (não vir aquele “ping” oco), as teclas são de extrema qualidade, dá pra sentir nos dedos a diferença. Cada posição de switch na placa mãe tem LED RGB. O único problema é que esses materiais todos são pesados. No final o teclado tem mais de 800g, quase 1 quilo, e dá pra sentir. Pra carregar na mochila já dá pra sentir bem mais pesado. É quase o dobro do peso do antigo Planck EZ que era quase todo de plástico.

Em termos de layout, comparado com o Corne que é 40%, este é 60%, tem 59 teclas, porque a barra de espaço ocupa dois espaços - dá pra tirar o estabilizador e dividir em duas teclas, se quiser. A diferença principal pro Corne é que tem uma linha a mais no topo, a linha de teclas numéricas. Pra quem está acostumado a usar teclados Tenkey-less (teclado convencional sem teclado numérico, como da maioria dos notebooks), tende a não ter tanto problema pra se adaptar a este layout.

É possível usar assim, mas recomendo mudar as teclas de lugar. Como um bom teclado moderno, o GK6 tem firmware que podemos customizar. Está tudo documentado nesta página no site deles e, claro, é baseado em QMK, então podemos mudar coisas que não fazem sentido, como o “backspace” que fica no canto superior direito e jogar, por exemplo, pra uma das teclas do dedão, economizando seu mindinho direito. Tem gente que não gosta de fazer isso, mas recomendo tentar. Mesma coisa o enter/return, mudar pra um dos dedões.

O maior problema do GK6 é que sempre está fora de estoque, e o preço é bem salgado: USD 250, sem contar transporte nem impostos. Tem várias cores muito boas pra escolher, então, fiquem de olho pra quando voltar o estoque.

Sério, olha essa foto, a traseira deste teclado é mais bonita do que a frente da grande maioria dos teclados comerciais. Isso é unibody de alumínio com o nome do teclado esculpido em relevo baixo.

Ortolineares - Q15

Mas se não tem paciência e tem dinheiro sobrando, sempre tem a opção da Keychron, que se estabelece com a marca de teclados com a maior variedade de todas. Pense num estilo, eles tem. De todos os tamanhos, de todas as qualidades, mas todos muito caros. Pelo menos, sempre costuma ter estoque.

E na linha ortolinear, temos que ver o Keychron Q15 max que tem no Brasil mas está a bagatela de nada menos que R$ 2.229,00, quase USD 400 dólares. É BEM caro.

Mesma coisa, comparando o tamanho com o monstruoso Moonlander. Mas veja que também é compacto. Em termos de dimensões é muito próximo do Gizmo GK6. Mas muito mais pesado, em vez de 800g, esse tem 1.2 quilo. É 50% mais pesado e dá pra sentir carregando. Este, definitivamente seus ombros vão chorar quando carregar na mochila. É literalmente o peso de um Macbook Air inteiro!

Ele é mais caro e mais pesado porque realmente tem muito mais material. Faz o GK6 parecer teclado de hobbista. Também tem case em unibody de alumínio, múltiplas camadas, design double-gasket, espuma de dampening, camada de latex, etc. Olha isso, direto do site deles:

Além disso tem dois rotary, um em cada canto superior, que nem o Hillside que o Felipe tinha montado pra mim, mas este tem acabamento bem profissional. Serve não só pra controlar volume, mas é muito desejável em workflows de Photoshop, Premiere, Da Vinci Resolve. Toda vez que precisar lidar com timelines, gradientes, coisas que modificam ranges de valores com precisão. Pra isso esses rotary são muito melhores do que só mouse ou combinação de teclas.

Além disso, notem como tem teclas duplas e triplas. Ele vem com teclas extras, e essas teclas maiores tem estabilizadores, dá pra tirar e dividir em mais teclas menores. Dá pra customizar de vários jeito diferentes e, pra variar, também tem firmware baseado em QMK e um aplicativo visual pra ficar mais fácil de mudar o layout só com mouse, em vez de ter que editar um arquivo JSON.

Eu elogiei a traseira do GK6, mas o Q15 Max não fica atrás. Novamente, unibody de alumínio. Parafusos de bronze, se não me engano. Textura impecável. É uma obra de arte também. E dá pra ver a grossura extra desse teclado, é um pouco mais alto no topo, então é um pouco inclinado em vez de totalmente reto com o GK6. Este teclado já começa a exigir um apoio de pulso.

Agora, esse peso todo, e tantas camadas, também resultam num som muito mais encorpado e robusto, ouçam só:

Ouviram o barulho do peso do Q15 no chão? E conseguem entender a diferença nos sons? O Q15 não ecoa nada, o “dampening” dele é muito bom. O som é grave e encorpado. O GK6 também é muito bom, mas tem menos camadas. Em comparação dá pra sentir um pouquinho de eco no fim. Já os últimos dois são mais ocos por dentro, sem espuma, com materiais menos robustos, aí já tem um barulho um pouco mais agudo e ecoado. O ideal é o som do Q15. Nenhum deles é particularmente ruim, mas o Q15 é superior mesmo.

O exemplo acima é do próprio site da Keychron, mostrando como eles tem um aplicativo visual pra editar os layouts, parecido com o Oryx da ZSA também. Apesar de ser bom ter a liberdade de fazer o que quiser no nível da linguagem C com o QMK, pra teclados, eu realmente prefiro que exista uma opção visual assim. Nem todo mundo que vai comprar é programador e vai saber configurar terminal, python, git, etc. O ideal é ter as duas opções, mas o default ser plug-and-play, só plugar na USB, o aplicativo sobe o firmware e já era.

Meu Melhor Teclado - Voyager

Apesar de todos os elogios que vim fazendo a todos os teclados anteriores, eu não uso nenhum deles hoje em dia. Na verdade, recebi o Q15 Max e não tinha nem tirado da caixa até ter que tirar as fotos pra este artigo. Um dos problemas desse tipo de teclado é que já me acostumei ao meu layout, com minhas próprias camadas customizadas, então todo novo teclado, preciso passar pelo cansativo processo de editar layouts tudo de novo. Aí não tive paciência e acabei nem usando.

Se nenhum dos modelos comerciais existisse, o teclado ideal seria alguma variação de Corne. São pequenos e compactos, não ocupam quase nenhum espaço na mesa. Somado a switches e teclas Choc, ficam bem low profile. O PCB (placa controladores) não exige uso de case, pode ficar direto na mesa porque não tem nada embaixo que dá curto. Isso o torna extremamente “flat” na mesa, não precisando usar nenhum tipo de apoio de pulso.

Além disso, é colunar staggered, que leva em consideração comprimento diferente dos dedos, e é split, que permite deixar as duas mãos bem separadas, evitando rotações desnecessárias. Finalmente, é totalmente customizável via QMK, onde posso colocar todas as camadas do jeito que eu quero. Ou seja, é o teclado perfeito.

Mas a ZSA, fabricante do descontinuado Planck EZ e do monstruoso Moonlander, resolveu criar um novo modelo, o Voyager. Eu acho que muito desse modelo veio do feedback de pessoas com o Ben Vallack. Sério, maratonem os videos do canal dele onde mostra passo a passo a pesquisa que fez pra determinar como o teclado perfeito deveria ser. E até vai além do ponto, ao extremo de criar um teclado com nada menos do que míseras 18 teclas (!!)

Não é prático, mas é ultrapassando os limites que sabemos onde está o limite:

Ele começou a fazer os protótipos usando o Moonlander como base, removendo teclas, fazendo experimentos. E chegou à conclusão que o Moonlander seria ainda mais ergonômico e muito mais produtivo se fosse muito menor e com muito menos teclas. E a ZSA ouviu.

Ele tem mais ou menos as mesmas dimensões do GK6 ou Q15, mas em formato “split”, dividido ao meio, o que possibilita mais flexibilidade e ergonomia. Note que a cor branca vai encardindo com o tempo. Ainda não sei o que é melhor pra limpar, mas o meu já está amarelando de tanto usar. Recomendo comprar a versão preta.

O Voyager é o Moonlander 2.0, um Corne comercial. É um pouco maior do que um Corne 40% porque tem a linha superior numérica. Eu acho que nem precisaria, mas não chega a atrapalhar. Ao contrário do meu Corne montado de forma caseira, o Voyager é “slick”, com cara de algo que a Apple construiria. Plásticos duros de alta qualidade, placa de metal atrás dando suporte, peso e rigidez, mas sem aumentar demais o peso total. Espessura fina, usando switches e teclas low profile, parecidas com as Choc que falei que gosto, e ainda com LEDs RGB em cada tecla. Tem tudo que gosto no Corne e mais um pouco.

Claro, assim como tudo nessa categoria, o Voyager também é bem caro. USD 365, sem contar transporte nem impostos. É a mesma faixa de preço do Q15 Max. Por isso falei: se preço menor for importante, um Corne montado manualmente faz a mesma coisa, e pode custar metade do preço ou menos! Falem com o Felipe!

Em comparação com o Corne, tem 2 teclas a menos em cada thumb-cluster. Isso foi um pouquinho chato no começo de me acostumar, mas hoje eu acho que foi a decisão certa: cada dedão não precisa de mais do que duas teclas. Este é um caso onde limitações são libertadoras. O senso-comum diz que ter mais teclas é melhor, mas os dedos precisam se mexer mais e é mais fácil de errar.

Isso vale a pena explicar. Vamos revisar o layout do meu Corne:

Aqui cada dedão precisa lembrar a posição de 3 teclas. As mais usadas são backspace e barra de espaço, por isso coloco mais na ponta. Assim eu sempre sei que precisa esticar o dedão e nunca vou errar. Já “delete” e “enter¨ se usa um pouco menos, deixo no meio, onde é só abaixar o dedão, sem esticar. Era assim que eu usava no Moonlander, Planck, Corne e outros.

Mas o Voyager só tem 2 teclas em cada dedão, como faz?

Esta é a camada 0 (zero) do meu Voyager. Tem só backspace e espaço nas teclas maiores do thumb-cluster, mas note que acima tem as teclas “hold”, que é a mesma coisa que o “MO(1)” e “MO(2)” do QMK, lembram? Servem pra deixar apertado e mudar pra outra camada virtual. Se apertar esse “hold 1”, vai virar o seguinte:

Agora sim, com o “hold 1” apertado na esquerda, posso apertar “enter” com dedão direito.

Por outro lado, se deixar apertado “hold 2” com dedão direito, agora o backspace vira “delete” na esquerda. E com isso as mesmas funções estão disponíveis, mesmo tendo fisicamente menos teclas. É só aprender isso de camadas.

Mais do que camadas, tem coisas não uso tanto, com “tap-to-hold”. Você Dá pra apertar rápido uma vez e depois segurar a mesma tecla, e isso dá gatilho em outro evento. No caso da ferramenta de configuração Oryx, da ZSA, tem opções de configurar o que acontece só quando aperta e tira o dedo (“held”), ou quando aperta rápido duas vezes (“double-tapped”), ou quando aperta rápido uma vez e aperta de novo (“tapped and then held”) e deixa segurando. Ou seja, dá pra configurar no mínimo 3 ações diferentes em cada tecla, em cada camada, e dá pra ter múltiplas camadas! São centenas de opções!

Assim como a Keychron, a ZSA também tem um aplicativo visual via web. É muito mais cômodo do que editar um arquivo JSON. Ele tem já embutido botão pra compilar o firmware e, quando conectar seu teclado no modo de upload, o navegador consegue detectar e é plug-and-play pra subir o firmware. Não precisa instalar nada extra na sua máquina. É esse tipo de poimento comercial que uma opção mais barata como Corne não vai ter. O mais próximo é o QMK Configurator.

E diferente do Corne, o Voyager também tem LEDs RGB. Tá vendo no Oryx como tem opção de “set color”? Assim fica muito mais fácil pra lembrar onde que tá qual tecla, em qual camada. Até pra saber em que camada estamos neste momento. Muito melhor do que ter que memorizar tudo e não ter feedback nenhum. Acho muito importante o hardware ter alguma forma de comunicar seu estado atual.

Portanto, a experiência do software me faz querer experimentar mais com o Voyager ou Moonlander do que o GK6 que é QMK puro, por exemplo.

Novamente, olhem na minha mão como é fino. Cada metade tem pouco mais de 200g. Com os cabos, o total é menos de 700g. É próximo do GK6, metade do Q15, mas parece ainda mais leve. O balanço do peso é muito bom.

A traseira do Voyager não chega a ser tão elegante quanto do GK6 ou Q15, mesmo assim é bonito o suficiente e funcional, uma vibe mais industrial, com metal e parafusos à mostra e pontos de montagem pra anexar em suportes, caso queira usar em tripé, braço de cadeira ou em “tenting”. Eu não tentei nenhuma dessas opções, prefiro reto na mesa mesmo.

Mas tem sub-reddits com projetos de impressão 3D e coisas assim pra quem quiser experimentar tenting no Voyager. Veja um exemplo de lá:

Tem esta outra opção usando um tripé chamado “Manfrotto”:

Essa é uma opção que me vejo usando. E tem mais opções. Eu gosto de tenting, é a única coisa que só o Moonlander faz de fábrica. Eu sentiria mais falta se ainda precisasse digitar muito todos os dias, mas como não preciso mais, prefiro o Voyager puro pra ser mais bonito e ocupar menos espaço na minha mesa.

Esta é minha mesa em Outubro de 2024 e como tem sido por pelo menos 1 ano. Eu troco por outros teclados pra testar, mas sempre acabo voltando nesta configuração, por tudo que já expliquei antes. Eu uso o mouse na mão esquerda (porque minha mão direita dói mais, então me acostumei a usar com a esquerda pra doer os dois igual kkkk). Tenho um Apple Touchpad na direita pra coisas que exigem “scrolling” (dói muito menos do que “scroll-wheel” de mouse). E note como uso as duas metades do teclado bem afastados. Essa é uma distância boa, mas dá pra abrir bem mais se quiser.

Ortolinear vs Colunar

Pra ficar claro, achei melhor ilustrar o que significa esse papo todo de pulso. Veja como ficam suas mãos num teclado de uma única peça, um monolito:

Está claro? Quando o teclado não é split, somos obrigados a trazer as duas mãos super pra perto. Obviamente a única forma de posicionar assim é dobrando os pulsos de uma forma não-natural. Somado à rotação (por não ser tenting), estamos pinçando os nervos e causando micro-lesões, todas as vezes.

Sim, pra quem usa pouco, esporadicamente, não faz diferença mesmo. Isso é pra nós, programadores, escritores, pessoas que digitam horas seguidas. Se você não for essa pessoa não me venha comentar “ain, eu não sinto isso”. Lógico, você digita pouco.

Se a intenção for construir um teclado monolito pelo fato de ser mais fácil de carregar na mochila ou algo assim, no mínimo, as duas metades deveriam estar num ângulo, como na foto acima. Dessa forma as mãos teriam que continuar próximas, mas não seria necessário dobrar os pulsos.

Claro, o ideal é split: duas metades que podem ser afastadas. Assim seus braços podem permanecer numa posição natural, reta, sem precisar dobrar nada, sem fazer esforço desnecessário. Isso permite ficar horas digitando sentindo pouca ou nenhuma dor. Se somar a um suporte embaixo, pra elevar o meio do teclado, criando tenting, aí sim, os braços ficam na posição mais neutra possível. E é por isso que eu prefiro este tipo de teclado: split-colunar-staggered.

O Futuro - Framework

Este artigo foi só porque eu estava com esses teclados parados aqui. E não, não adianta mandar no comentário pra sortear, vender, nem nada disso. São parte da minha coleção, eu deixo na minha prateleira porque acho bonito e posso usar quando der na telha. Não vou me desfazer de nenhum. Não insistam!

Mas se tem uma coisa que me frustra são notebooks. Nenhum tem opção ortolinear. Então sempre preciso conectar um externo via USB ou então digitar mais devagar usando o layout convencional. Mas minhas esperanças aumentaram quando surgiu a empresa Framework.

Eles só tem dois modelos, o Laptop 13 e o Laptop 16. Meu ideal seria um 14” com formato 3:2 como os Surface, mas o de 13" é mais que suficiente. Eu conheci eles pelo canal Linus Tech Tips, pois o Linus Sebastian se tornou um dos primeiros patrocinadores/sócios do projeto.

A ideia parece simples, mas até hoje ninguém conseguiu fazer algo que não só funcione, mas dure anos. Esse laptop é todo modular. E não só nas coisas triviais como trocar uma porta HDMI externa por uma porta Ethernet ou USB 4. Mas também fazer upgrade de memória, e até de placa-mãe, GPU, monitor e … teclado!!

Jack at @OrtholinearKB prepared a mockup of an ortholinear keyboard module for the Framework Laptop 16! Modularity opens up some incredible possibilities. pic.twitter.com/hKqT3AMU7t

— Framework (@FrameworkPuter) April 18, 2023

Olha só isso. Parece que já faz pelo menos um ano que estão trabalhando numa opção ortolinear! Isso seria meu sonho de consumo! Um teclado de notebook não é mais que um teclado com USB interno. Deveria ser simples de trocar, é mais uma questão de design industrial do que de tecnologia.

Eu estou quase já comprando um Framework Laptop 13 quando for pros EUA este ano, e quando sair o teclado, posso importar só ele (vai custar impostos, óbvio, mas pelo menos vai ser só o teclado). Aí eu terei o notebook definitivo pra digitadores profissionais!!

Esta é a última coisa que falta. Espero que realmente lancem logo e inspirem outros fabricantes a pensar em opções assim: destacáveis e modulares.

Como expliquei nos meus videos, em particular no primeiro video da trilogia, até hoje usamos layouts de teclados absolutamente ruins pras nossas mãos, pulsos e braços. Muitos que trabalham o dia todo digitando vão sofrer com LER e tendinite, mais cedo ou mais tarde. Tudo porque todo mundo tem preguiça de aprender coisas modernas.

Todos acham que é muito difícil, mas é só preguiça mesmo. Eu aprendi com mais de 40 anos. Não precisa ser um adolescente pra aprender essas coisas. É só parar de achar que não vai conseguir e fazer, sem pensar nas consequências. Melhor: se conseguir, a consequência é que vai digitar mais rápido, com menos erros e sem forçar suas mãos, evitando dores e doenças ortopédicas.

A Apple, o ápice do que usamos como referência quando pensamos em tecnologia moderna, só tem uma parte que tem fedor de velho: o teclado. Se ela fosse realmente corajosa, como Phil Schiller achava que era, o Macbook tinha que ser assim:

Isso sim, seria um Macbook do século 21, deixando as limitações do layout de máquina de escrever do começo do século 20 pra trás. Por agora, já me dou por satisfeito com meu ZSA Voyager, que é meu “daily-driver” e faz tudo exatamente do jeito que preciso. Não pretendo descer abaixo dos 40% e ficar fazendo malabarismo.

Eu falei de “Corne”, mas é só porque é o nome mais popular. Falei que o Felipe me fez um Hillside que é um Corne com rotary, mas existem dezenas de variações como Lily58, Skeletyl, CRKBD, Scylla, Sofie, Totem e muito mais.

Sabe onde consegue ver várias delas? No perfil de Instagram do amigo Felipe/Tupinikeebs. Ele sempre posta um keeb novo por lá, então fique de olho, leve em consideração tudo que falei sobre tamanho, peso, mobilidade, bateria, layouts, 60% vs 40% vs 30%, tenting, split, e encontre a combinação que faz mais sentido pro seu uso particular.

Modelos diferentes existem porque cada pessoa tem usos diferentes. Um escritor de livros é diferente de um programador que é diferente de um contador que é diferente de um cientista de dados e assim por diante. Não existe um teclado universal que funciona perfeitamente pra todo mundo. Sem contar a estética, cores, RGB, tipos de switch, materiais de teclas, etc. Não seja limitado, seja aberto às opções.

Novamente, praqueles que vão insistir em comentar sobre o lendário Kinesis, ele é diferente de todos que já mostrei. Eu sei. Tem o formato de uma bacia no centro de cada metade, É uma outra forma de otimizar pra comprimentos diferentes em cada dedo. Em vez de Corne, o que vocês querem é o Scylla. Adivinha quem já postou sobre isso? O Felipe:

E por hoje é isso aí, espero que tenham gostado. Não deixem de assistir os videos da trilogia onde explico muito mais detalhes de tudo isso. Só depois pensem em mandar perguntas nos comentários!

Como video de fim de 2022, vou participar de uma corrente chamada “Top 3 Distros Linux”. Vou eleger 3 distros Linux que gosto e depois falar sobre distros Linux em geral.

E aqui vão os “summon” pra participar da corrente:

@HackerVilela @pikuma @ManualdoCodigo

Conteúdo

• 00:00 - Intro
• 00:49 - As Regras da Corrente dos Top 3
• 02:04 - Número 3
• 03:28 - Número 2
• 05:38 - Número 1!
• 08:34 - Como eu enxergo Distros Linux
• 12:56 - Recomendação pra Iniciantes?
• 15:11 - Summon 1: Vitor
• 15:55 - Summon 2: Pikuma
• 16:59 - Summon 3: Douglas
• 17:56 - Bloopers

Links

• https://diolinux.com.br/video/top-3-distro-linux.html
• http://toastytech.com/guis/mkde.html
• https://batocera.org/
• https://en.wikipedia.org/wiki/Mandriva_Linux
• https://www.redhat.com/en/about/press-releases/press-redhat42

SCRIPT

Olá pessoal, Fabio Akita

Normalmente eu não participaria de correntes, mas por acaso o assunto bateu com alguns dos meus videos mais recentes então decidi participar. Ainda mais porque fui “sumonado”, praticamente intimado pelo Diolinux no video dele de “Top 4 Distros de Todos os Tempos”, que por sua vez foi “sumonado” pelo Slackjeff e assim por diante. A idéia é falar sobre as 3 distribuições Linux que mais me impactaram mas não vale falar da distro que estou usando neste momento. E no final tem que provocar mais pessoas pra continuar a corrente. Este video vai ser curtinho, só pra fechar o ano, então vamos lá!

(…)

Ironicamente, não pode falar da distro que estou usando neste momento. O problema é que estou usando 4 distros ao mesmo tempo. Deixa explicar, o principal é o Manjaro Gnome, que uso no PC de casa, e é minha máquina de trabalho. Mas tenho vários ambientes virtuais. Quem me acompanha no Instagram sabe disso, e vai ser tema de um próximo video que já estou escrevendo. Mas como ambiente pra retrogames eu tava usando o Garuda Linux numa máquina virtual. Assim como o Manjaro é derivado de ArchLinux também, mas vem mais estilizado e pré-configurado pra gamers. É uma distro bem pesada, feita pra máquinas mais parrudas.

Também tenho um Ubuntu 22 virtualizado pra alguns testes então não vou falar dele e tenho o Windows Subsystem for Linux, ou WSL rodando ArchLinux em cima, que uso no meu notebook porque lá o OS principal é Windows mesmo. Alguns modelos de notebook aceitam Linux de boa, alguns nem tanto, e esse Zephyrus G14 dá probleminhas com coisas como Bluetooth então decidi ficar no Windows mesmo já que uso mais pra viajar.

Então nada de Manjaro, nem Garuda, nem Ubuntu e nem Arch. Pois bem, vou falar primeiro o tema da corrente, as Top 3 distros que acho mais interessantes e depois o que acho que todo mundo realmente queria saber que são as distros que eu usaria como minha principal mesmo. Vamos lá, começando pelo número 3.

A número 3 é a distro que mais usei nos anos 90, e foi a francesa Mandrake Linux que depois se fundiu com a brasileira Conectiva e virou Mandriva, que começou em 1998 e morreu em 2011. Mandrake pra mim sempre pareceu um RedHat mais amigável, mais ou menos como um Ubuntu nasceu como um Debian mais amigável, só que quase uma década antes.

Mandrake vinha com KDE por padrão, e o principal é que tinha um instalador gráfico muito mais interessante que a versão em ncurses padrão dos RedHats. E pra quem não sabe o que é a distro RedHat, depois ele virou CentOS que é mais usado em servidores de empresas e o Fedora que é a versão mais usada em desktops. Além disso tinha o Mandriva Control Center, meio parecido com a proposta do Yast do OpenSuse de ter um painel de controle completo pra configurar o sistema em vez de ter que fazer muita coisa pelo terminal.

O gerenciador de pacote não lembrava o nome, mas pesquisando achei que era o “urpmi” que funciona como um wrapper pra RPM. Eu jurava que ele usava direto RPMs, que é o formato de pacotes RedHat Package Manager, que ainda é usado no CentOS e Fedora e gerenciado pela ferramenta “DNF”. O Mandrake, Conectiva e depois Mandriva foi onde realmente comecei a aprender Linux, aprender a programar com Perl, PHP, aprender sobre servidores web, configurar Apache e coisas assim. Eu usei outras distros daquela época, mas sempre voltava pro Mandrake.

O Top 2 acho bacana pra quem só conhece Ubuntus da vida porque é largamente usado e ninguém sabe disso, o Alpine Linux. Se você lida com infraestrutura, principalmente se é devops de Kubernetes e outras plataformas de containers, deve usar Alpine ou Debian. A idéia do Alpine é o oposto de um Fedora ou Ubuntu. Enquanto distribuições pra desktop tentam colocar um monte de software pra tornar a máquina mais fácil de usar, um Alpine tem como objetivo ser o mais leve e o mais seguro possível, vindo só com realmente o mínimo necessário pra um container funcionar.

Acho que tem louco que tenta usar Alpine como desktop, mas ele não foi feito pra isso. Dá? Dá, mas não tem vantagem em desktop, só em containers. Ele deriva de uma linhagem anterior de distros como o antigo LRP ou Linux Router Project ou “Linux on a Floppy”, cuja idéia era ter uma distro tão pequena que caberia num disquete antigo. Esse tipo de distro é útil pra bootar coisas como roteadores ou firewalls.

Sabe o modem de internet que você tem aí na sua casa? É um Linux dessa família, não necessariamente o Alpine, mas parecido. Ele vem com o kernel, os drivers mínimos pra coisas como placa de rede, nenhum tipo de interface gráfica pesada como KDE, e só um servidor web como Apache pra fornecer uma aplicação web que você acessa pelo navegador do seu PC ou via um app no celular.

Pra quem sobe Docker ou Podman, normalmente puxa imagens cuja base original era um Alpine. Por exemplo, este é repositório onde tem o Dockerfile que gera a imagem de Postgres que você usa nas suas aplicações. Ele tem duas versões, uma gerada a partir de Debian e outra a partir de Alpine. Se olharmos o repositório da imagem de python, o Dockerfile dele também começa com a opção de Alpine e depois Debian.

Debian ainda é bem usado pra essas coisas por causa da sua reputação lendária de estabilidade e maturidade. Mas o Alpine tá lá pau a pau. Diferente de Ubuntu ou Debian que usa a ferramenta “apt” pra gerenciar pacotes, Alpine usa “apk” e hoje em dia tem apk pra tudo que precisamos no mundo de servidores ou sistemas embarcados. Como programador, é importante aprender como o Alpine funciona e quais as diferenças com outras distros mais antigas como Debian.

E agora, meu Top 1 é pra dar uma troladinha, mas só pra sair do comum. Acho que é válido falar do Batocera. Quando falamos em distros pra gamers, muitos pensam no PopOS, ou Garuda ou mesmo o meu Manjaro, mas a maioria esquece do Batocera.

Eu uso Batocera num Raspberry Pi ligado neste setup que tenho em casa. Eu sempre quis um arcadezão de madeira que nem tinha antigamente, mas na prática, no meu apartamento pequeno, seria um trambolhão ocupando muito espaço. Daí resolvi repensar o conceito e ter um arcade minimalista. Eu já tinha um raspberry pi sobrando, tinha comprado este joystick de arcade da 8bitdo, que não é nem de longe bom pra competir numa EVO da vida, mas pra jogar casual é excelente. Daí comprei esse monitor portátil, super fino e leve. Tão leve que coloquei fita dupla face da 3M atrás e grudei na parede.

No Raspberry Pi antigamente instalava o RetroPie, que é outra distro dedicada a retrogaming, mas o Batocera acho evoluiu mais rápido e tem o melhor acabamento. Você baixa a imagem dele, instala num SD Card, coloca no Raspberry e já era, tudo funciona. Olha só o boot dele. Já vem com emuladores como RetroArch configurado, já vem com o front-end EmulationStation configurado pra ficar bonito que é esse que estou mostrando, já tem todos os perfis de controles de arcade e gamepads, então é tudo plug and play, não precisa abrir terminal pra ficar gambiarrando nada. Só copiar os arquivos de ROMs dos jogos e jogar. É excelente pra máquinas fracas ou raspberry pra virar central de games antigos.

Eu particularmente gosto muito desse novo mercado de consoles portáteis pra retrogames, como os feitos pela Ambernic ou Retroid. Este é meu Ambernic RG552, e dá pra instalar Batocera nele também. Este é meu Miyoo Mini, mas nesse o recomendado é instalar o Onion OS que é mais configurado pra este hardware em particular. E este é meu Aya Neo Next Pro que tá com Windows mesmo, mas esse é potente demais e seria meio desperdício usar Batocera nele. É basicamente a performance de um notebook. Se eu ligar um teclado e mouse, posso substituir meu notebook em viagens.

Se quiserem reviews de consoles portáteis, como configurar Batocera, Onion e muito mais, assinem os canais Retro Game Corp, Taki Udon, ETA Prime e Retro Dodo, que são os que eu assisto. Eles tem falado de Steam Deck, Aya Neo, Ayn Odin, e muito mais.

Pronto, terminei minha missão: os Top 1 e Top 2 foram pra abrir a curiosidade de vocês em ir conhecer distros Linux especiais pra usos específicos que não só desktop. Acho esse assunto bem mais fascinante do que ficar discutindo tema mais bonitinho de KDE ou GNOME. E agora que terminei meus Top 3 da corrente, deixa eu fazer alguns comentários sobre o que acho de outras distros.

Pra mim o mundo de distros se divide assim. Primeiro tem as distros OG, as originais ou derivadas das originais. Coisas como Slackware, que foi minha primeiro distro, ou Gentoo, que poderíamos dizer que é o menos velho dessa categoria. Mas são as distros que exigem que você tenha mais intimidade com a máquina e com baixo nível da kernel e configurações mais cabeludas. Não foram feitas pra serem amigáveis, foram feitas pra quem sabe o que está fazendo. Debian pra mim se encaixa nesse grupo. Se quiserem ver como é Slackware e Gentoo eu fiz um video pra cada recentemente, dêem uma olhada depois.

Daí existe a RedHat, que nos anos 90 despontou como a melhor solução de Linux comercial, oferecendo garantias, suporte técnico e tudo mais. Em paralelo apareceu a alemã Suse que hoje é OpenSuse e foi competidor de outros comerciais como Caldera Linux da Novell ou VA Linux que foi o primeiro IPO de Linux no meio da bolha da Internet do fim dos anos 90. RedHat junto com a Suse foram os únicos que sobreviveram. Dela derivam Fedora e CentOS que se usa até hoje.

Na virada do século nasce o Ubuntu, que é derivado de Debian e usa o mesmo formato de pacotes DEB e o mesmo gerenciador de pacotes apt. Ubuntu é o Debian menos estável, porque trás pacotes mais novos. Normalmente em servidor ou embarcado você não quer os pacotes mais novos, você quer os mais testados, estáveis, maduros e livres de bug.

Parte da popularidade do Ubuntu se deve a ele ter sido mais pragmático. Debian segue a filosofia de software livre mais à risca. Nada de binários sem código-fonte ou código que não tenha licença realmente livre. Já Ubuntu preferiu ser mais amigável e incluiu coisas como codecs de mp3, de video, drivers binários de hardware como NVIDIA e tudo mais. Isso facilita a vida do usuário médio, mas já não segue mais a idéia de software livre. Muitas distros hoje fazem a mesma coisa.

Em desktop não tem tanto problema instalar um pacote com bug e esperar alguns dias pra aparecer a correção. Mas em embarcado ou servidor, isso é um grande problema. Imagina um bug que é automaticamente instalado em centenas de servidores e causa crash pra todos os usuários. Seria uma catástrofe. Por isso um Debian da vida oferece pacotes mais “velhos” mas que sabemos que funcionam sólidos.

Tem gente que não curte o Ubuntu da Canonical. Seja porque não gosta de laranja, seja porque não gosta de Snap ou seja lá o que for, seja porque não curtem Unity ou GNOME. Daí surgiram dezenas de distribuições derivadas de Ubuntu. Nessa categoria temos o PopOS, Linux Mint, Elementary, Zorin OS, Budgie, Feren, Lubuntu, KDE Neon e vários outros. O que muda é a interface gráfica, quais pacotes já vem pré-instalados, configurações e tuning do sistema. Mas pra mim é tudo Ubuntu.

Tem uma coisa que eu não curto em APT, que é o gerenciador de pacotes que todos usam, e ter que instalar e configurar PPAs pra instalar pacotes de terceiros. Acho um saco, acho manual demais, acho bugado. Por isso passei a preferir derivados de ArchLinux pra desktop. Arch é o oposto de Debian: o mais instável possível porque ele instala tudo que sai de novo. E eu sou o tipo de cara que gosta de novidades o quanto antes.

ArchLinux funciona no sistema de rolling updates. Não tem isso de upgrade de Ubuntu 20 pra 21, de 21 pra 22, ele vai só se atualizando constantemente. O problema disso é que quase todo dia tem atualização. Quem se incomoda com isso vai odiar. E também por causa disso, vira e mexe pode vir uma novidade pouco testada que causa bugs.

E pra piorar ainda temos o AUR que é o Arch User Repository, onde qualquer um pode subir qualquer pacote de qualquer coisa. A vantagem disso é que todo software que imaginar provavelmente alguém subiu lá e tá fácil pra instalar. A desvantagem é que todo mundo pode subir qualquer coisa e vira e mexe sobe mal feito e mal testado: você instala e dá pau.

Essa não é uma distro pra amadores. Vira e mexe vai ter que consertar alguma coisa na não. Por isso existem derivados de Arch que tentam estabilizar um pouco mais as coisas e aí chegamos no meu Manjaro. Em vez de liberar pacote novo toda hora, o Manjaro dá uma segurada pra dar tempo da comunidade testar um pouco mais, subir correções e só depois eles liberam tudo de uma vez só.

Ele atualiza com menos frequência e quando vem atualização não quebra catastroficamente. E Manjaro passou a oferecer o sistema de arquivos BTRFS já na instalação, em vez de ext4, então temos suporte a snapshots, que oferece outra camada de proteção caso a gente instale um pacote bugado. Vou falar disso em outro video.

Isso tudo dito, pra um iniciante que não sabe bem que distro usar, posso recomendar ou Manjaro, seja KDE ou GNOME, ou PopOS que acho que é um dos derivados de Ubuntu mais bem feitinhos. Ou direto o próprio Ubuntu. A vantagem é que a maioria dos posts de blog e tutoriais documentam como fazer as coisas em Ubuntu. Raramente você vai achar um post que ensina como fazer as coisas em Gentoo ou Slackware, mas pra Ubuntu é mais fácil. Por isso que falamos que é mais indicado pra iniciante: porque tem mais chances de achar documentado como resolver um problema específico.

ArchLinux e Gentoo tem outra coisa legal: o Wiki deles são a melhor documentação de Linux ever. Sério, tudo que imaginar tem documentado lá. Se não tiver na Wiki do Arch, vai ter na Wiki do Gentoo. Se não tiver mesmo lá, parabéns, você achou alguma coisa que ninguém no mundo viu ainda. Mas esse Wiki pode intimidar os iniciantes, porque é bem detalhado.

Mas na prática o que todo mundo quer mesmo saber é qual interface gráfica usar, independente da distro por baixo. KDE que você gasta algum tempo configurando temas e plugins, costuma ser o mais bonito, mas também meio pesadão. Recomendo brincar com gerenciadores de tiling window, onde as janelas ficam automaticamente uma do lado da outra em vez de uma em cima da outra. Quem popularizou isso foi o i3, o próprio PopOS trás essa funcionalidade de forma opcional que é legal pra começar, mas pra ser mais hardcore tentem usar o Sway ou XMonad.

Sway é mais ou menos a mesma coisa que o i3 mas feito pra rodar em Wayland. Se tiver GPU que não seja NVIDIA, provavelmente é a que vai rodar melhor. E o mais avançado acho que é XMonad. São interfaces gráficas feitas pra operar sem mouse. É pra programador hardcore de Vim ou Emacs que não tira os dedos das teclas pra nada. Eu já usei, e se minha rotina ainda fosse só programar, certamente usaria um dos dois. Mas como não é mais, fico no GNOME, que é o mais simples, não precisa customizar muito, e se comporta mais parecido com os antigos MacOS.

No geral é isso, por hoje é só. Diferente fazer um video curto assim. Pra continuar a corrente, preciso dar summon em outros canais pra passar o bastão. Eu realmente não assisto muitos canais de programação nem Linux no YouTube, então vou chamar dois que já interagi pelo Twitter e um terceiro que me indicaram. Eles fazem coisas bacanas que vocês vão gostar.

O primeiro é o Vitor Vilella. O moleque é hardcore, ele pega binários de ROMs de jogos de Super NES que tem problemas de lentidão, como Gradius III, por exemplo, e ativa chips de aceleração do Super NES como o SA-1. Ele faz assembly de chip de Super NES, e a ROM resultante dá até pra gravar num chip de cartucho de verdade e jogar no hardware original.

Encontrei ele por causa do projeto de Super Mario World em widescreen. Sério, ele ajustou o jogo todo pra ter mais espaço na direita e na esquerda e dar pra ver mais da fase ao mesmo tempo, sem quebrar nada. Só baixar um emulador como o BSNES que tem suporte a esse tipo de hack e jogar. Eu assino o Patreon dele. Dêem uma olhada. O canal de YouTube ainda é pequeno mas vale a pena.

O segundo que me veio à cabeça é o Pikuma … paikuma? pikuma? Eu acho que ele é professor brasileiro que trabalha na Inglaterra. Ele vende cursos online. E eu sei, logo eu anti-curso recomendando curso é foda, e já deixando claro que ele não me pagou pra dizer isso, mas os temas dos cursos dele são interessantes.

Segundo o site dele, o objetivo é ensinar as fundações da programação de verdade, que eu sempre falo que ninguém ensina, como álgebra linear, trigonometria, matemática discreta e análise numérica, cálculo. Só que em vez de serem aulas teóricas chatas, ele faz isso aplicando na construção de um motor de jogos 2D em C++, ou programando em assembly do antigo Atari VCS, ou replicando o sistema de raycasting usado nos primeiros jogos de tiro como Wolfenstein.

Eu não cheguei a assistir nenhum dos cursos, estou chutando que sejam bons pelo tema e pelos capítulos que li. Claro que não dá pra explicar a ciência da computação inteira só nesses cursos, mas com aplicações reais e divertidas, deve incentivar o pessoal a procurar se aprofundar depois. Vocês podem me dizer nos comentários se gostaram.

O terceiro canal me foi recomendado pelo Twitter e esbarrei no Manual do Código do Douglas. Esse cara tem centenas de videos de temas interessantes de programação. Ele deveria ter muito mais seguidores. Vão lá dar uma moral pra ele. Assim como o Pikuma, também fala de programação de videogames antigos, tem javascript, tem python, tem megadrive, tem muita coisa pra quem curte programação.

E é isso aí, agora é com vocês, claro que é opcional participar da corrente, mas acho que foi uma boa oportunidade pra falar de outros canais aqui do Brasil que tão fazendo mais do que repetir as mesmas coisas cansadas de Python ou Javascript. Quem conhecer outros canais parecidos e quiser recomendar, não deixem de postar nos comentários abaixo. Se curtiram o video mandem um joinha, assinem o canal e compartilhem o video com seus amigos. E você assistindo, mesmo não tendo sido intimado aqui, faça um video de Top 4 distros também e compartilhem. Boas Festas, Feliz Natal e a gente se vê em 2023, Feliz Ano Novo!

Finalmente vamos tentar instalar e configurar uma das distros Linux mais trabalhosas de todas. O lendário Gentoo foi pensado pra você tirar o máximo proveito do seu hardware, customizando e compilando tudo do zero especificamente pra sua máquina. A primeira parte do video vai cobrir um pouco o que significa instalar uma distro assim. E na segunda e última parte vamos discutir se vale a pena todo o trabalho.

== Errata

Os capítulos 9 e 10 aparecem errado no video mas está correto no índice de tempo abaixo.

== Conteúdo

• 00:00 - Intro
• 01:03 - CAP 1 - Mesma coisa que Slackware - Instalando Gentoo
• 06:22 - CAP 2 - CHROOT - Quebrando a Prisão
• 11:32 - CAP 3 - Depois do Stage3 - Terminando a instalação
• 17:59 - CAP 4 - Compilando a Kernel - Customizando seu Gentoo
• 25:34 - CAP 5 - Resolvendo seu Primeiro Problemão - Não boota!
• 29:24 - CAP 6 - Tentando Instalar GNOME - Mais um Problemão
• 35:49 - CAP 7 - GDM, WebKit, Reflexões - Final da Instalação
• 37:35 - CAP 8 - Mais um Problema de SystemD - OpenRC
• 39:33 - CAP 9 - Por que e Quando usar Gentoo? É pra mim?
• 42:52 - CAP 10 - Qual a Melhor Distro? Eu sei “Linux”?
• 45:57 - Bloopers

== Links

• Gentoo AMD64 Handbook (https://wiki.gentoo.org/wiki/Handbook:AMD64/pt-br)
• Quick Installation Checklist (https://wiki.gentoo.org/wiki/Quick_Installation_Checklist#UEFI.2FGPT)
• GNOME/Guide (https://wiki.gentoo.org/wiki/GNOME/Guide)
• GNOME/GNOME without systemd/Gentoo (https://wiki.gentoo.org/wiki/GNOME/GNOME_without_systemd/Gentoo)
• GCC optimization (https://wiki.gentoo.org/wiki/GCC_optimization)
• Gentoo Cheat Sheet (https://wiki.gentoo.org/wiki/Gentoo_Cheat_Sheet)
• Upgrading Gentoo (https://wiki.gentoo.org/wiki/Upgrading_Gentoo#Updating_packages)

SCRIPT

Olá pessoal, Fabio Akita

Vamos continuar a saga de Linux por baixo do capô e como prometido, desta vez o video vai ser mostrando o lendário Gentoo. Mesmo quem nunca tentou instalar acho que já ouviu falar dele. A distro onde todo o sistema é compilado na sua máquina em vez de baixar pacotes binários pré-compilados.

Não é a distro mais difícil, mas certamente é chatinha, talvez ainda mais chatinha que o Slackware, e muito demorada, vocês vão ver. Só pra ter uma idéia, num ambiente controlado que é uma máquina virtual, mesmo assim eu recomecei a instalação do zero múltiplas vezes e ainda tive que fazer muita tentativa e erro até conseguir bootar.

(…)

O projeto original do Gentoo se chamava Enoch Linux, lá no começo deste século, e o objetivo era criar uma distro customizável que não instalava nenhum binário e sempre compila tudo direto na sua máquina. Consigo imaginar as vantagens disso. Mesmo assim, ainda não recomendo pra todo mundo. Esperem até o final que vou explicar porquê.

Sem mais delongas, mesma coisa que Ubuntu ou Slackware, vamos no site, baixar a ISO pra gravar no pendrive e bootar o instalador. No caso do Gentoo tem uma peculiaridade. Não esquece de baixar esse arquivo chamado stage3 aqui embaixo. Se quiser uma instalação pra servidor, ou seja, sem interface gráfica, baixe um dos dois primeiros arquivos. Se quiser instalar em desktop com gerenciador gráfico de janelas, escolha o profile de desktop. Em ambos os casos, você pode escolher se prefere usar systemd ou openrc.

Já expliquei um pouco sobre init systems e o systemd no episódio anterior de Slackware, mas de novo, se já está acostumado a usar uma distro mais popular como Ubuntu ou Fedora, eles usam systemd e talvez você prefira instalar systemd aqui também, pra não ter que reaprender muita coisa. Por outro lado, justamente porque estamos já tendo o trampo de instalar e configurar Gentoo, por que não usar OpenRC? Já que é uma das poucas distros que tem a opção de não usar systemd. Experimentar coisas novas e diferentes sempre vai agregar, no mínimo você vai ter outra perspectiva.

Eu resolvi escolher o stage3 de profile desktop com openrc por padrão. De resto, mesma coisa, colocamos a ISO no CD-ROM virtual da máquina virtual, bootamos e deixamos carregar. E diferente do Slackware, que cai no login em modo texto, aqui caímos em modo gráfico abrindo KDE. A tela está pequena porque não carregou serviço das ferramentas de guest da vmware pra ajustar resolução. Depois resolvemos isso.

Mas meio que tanto faz pra agora, porque vamos abrir o terminal e fazer tudo dele de qualquer jeito, já que Gentoo também não usa o instalador gráfico Calamares e nos obriga a configurar tudo na mão, bem old school mesmo, e por isso escolhi falar dele pra mostrar algumas coisas que não expliquei na instalação de Slackware.

Uma das grandes vantagens do Gentoo é que o site deles é muito bem documentado. Tem um wiki bem completo que, embora não seja do tamanho do wiki do Arch Linux, mesmo assim consegui encontrar quase tudo que queria. Vale a pena experimentar Gentoo só como desculpa pra estudar a wiki e aprender mais sobre Linux em geral. Em particular, como estou instalando dentro do VMWare, vou precisar usar a página de Wiki específica sobre VMWare, que também é meio válido pra VirtualBox. Então lembrem de ler caso queiram experimentar no VirtualBox de vocês.

Eu vou seguir primariamente esta página que é o “Quick Installation Checklist”. Como disse no episódio passado, este video não é um tutorial pra seguir passo a passo. Vou usar a instalação como desculpa pra explicar conceitos de Linux e também uma parte do processo de tentativa e erro normal. Assistam tudo primeiro, depois leiam as páginas da wiki, e depois se aventure a instalar direto na sua máquina ou num VirtualBox.

E não se preocupe, você não vai acertar na primeira vez. Eu mesmo tiver que reinstalar umas três ou quatro vezes na minha máquina virtual até conseguir terminar, foi um dia inteiro de tentativas e erro. Errar e recomeçar faz parte do aprendizado. Se quiser uma instalação fácil que acerta tudo de primeira, e não aprender nada, baixa Ubuntu.

Enfim, a wiki já começa sendo legal com você. Se sua máquina for muito antiga, de mais de 10 anos pra trás, pode ser que tenha BIOS em vez de UEFI e só suporte boot com MBR. Se for um pouco menos velha talvez seja BIOS com GPT, e se for mais moderna vai ser UEFI e GPT. Já falei disso no video passado e na minissérie sobre armazenamento. Assistam depois. Se tiver assistido, já sabe a diferença de BIOS e UEFI e MBR e GPT. No meu caso vou escolher UEFI e GPT, só garantir que na minha máquina virtual selecionei UEFI também, por padrão ele simula uma BIOS antiga, cuidado com isso.

O resto é a mesma coisa que já mostrei no video de Slackware. Uso cfdisk pra particionar o HD e depois comandos como mkfs.ext4 e mkswap pra formatar as partições. A única diferença é que no video de Slackware fui preguiçoso e só criei 3 partições, 1 de boot efi, 1 de swap e a principal. Esse wiki manda criar 4, que é mais correto, 1 partição separada pro mount point de “/boot”, outra pra “/boot/efi” dentro, daí as mesmas de swap e outra pra principal.

Não vou explicar linha a linha tudo de novo. Veja o episódio anterior pra detalhes disto. Mas é esta sequência de comandos aqui do lado. Primeiro estas, depois do cfdisk, pra formatar as partições e depois esta outra sequência pra montar as partições dentro de “/mnt/gentoo”, que vai ser a raíz da instalação.

Agora vem a hora daquele Stage3 que falei no começo, o zipão de 500 megas. O wiki manda entrar no diretório “/mnt/gentoo” e usar wget pra baixar o zipão. É o jeito mais fácil mesmo se o LiveCD detectou seu wifi ou sua rede cabeada e tá conectado na internet. Se não estiver, baixa em outro computador, coloca num pendrive, e copia do pendrive pra dentro desse diretório.

No meu caso, abro o firefox, e na página de download seleciono o stage3 pra desktop com openrc. Agora é descompactar com o comando tar xpf stage3*. Vai parecer que travou, mas é porque o arquivo é grandão e leva alguns minutos pra descompactar tudo, paciência.

Pronto. Se der um ls, olha só, tem os diretórios que você já deve ter visto em qualquer instalação de Linux, o “/usr”, “/etc”, “/bin”, “/var” e tudo mais. Tecnicamente o Gentoo já tá instalado, agora vem a parte mais complicada, que é configurar tudo antes de bootar. E a próxima seção do Wiki se chama “Chroot”. Então chegou a hora de fazer uma tangente pra explicar o que é isso.

Deixa eu bootar meu Ubuntu em outra máquina virtual e abrir um terminal. Agora vou criar um diretório qualquer e chamar de “jail” ou “prisão” mesmo. Tenha paciência que vou executar vários comandos que podem não fazer sentido, mas vai fazer. Lembra que executáveis de Linux costumam ter dependência de outros objetos binários ou bibliotecas compartilhadas? Que nem em Windows que você tem DLLs?

Lembra também quando falei sobre PATH? Quando executamos ls, onde que realmente tá esse executável? Podemos saber usando o comando which ls e descobrimos que o caminho completo é “/usr/bin/ls”. Fazemos a mesma coisa pro shell Bash, que é a linha de comando onde estamos. which bash e tá em “/usr/bin/bash”. Beleza, vou precisar desses binários.

Uma ferramenta que nunca tinha mostrado é o ldd. Ela analisa um binário e lista as bibliotecas compartilhadas que depende. Fazemos ldd /usr/bin/bash e ldd /usr/bin/ls. Estes são os objetos binários que eles precisam. Agora vem a parte estranha. Recriamos esses diretórios dentro do “jail” com mkdir -p jail/bin depois mkdir -p jail/lib/x86_64-linux-gnu, mkdir -p jail/lib64. Copiamos os binários do bash e ls pra “jail/bin” e depois, um a um, copiamos as bibliotecas pra dentro de “jail/lib” e “jail/lib64”. Trabalhinho. Já entenderam o que vou fazer?

Pronto, listando com ls jail, temos todos os bits necessários pra rodar bash e ls. Mas qual o objetivo de duplicar essas coisas? Agora vem o truque: rodamos sudo chroot jail /bin/bash. E olha só, abriu um shell de bash. Duh, grande bosta. Mas presta atenção, estamos rodando o bash que copiamos dentro do diretório “jail”.

Fazendo ls / pra listar a raíz, cadê meu Ubuntu, cadê todos os outros diretórios? Estou preso dentro do jail, enxergando como se esta prisão fosse a raíz do sistema. Parece uma máquina virtual né? Só que não é. chroot literalmente quer dizer “change root” ou “mude a raíz”. Ele faz o sistema operacional mentir pro meu usuário achar que a raíz do drive agora é só isso. A grosso modo, é como se eu tivesse bootado pra dentro de outra máquina, sem realmente ter feito um boot de verdade.

Eu chamei o diretório de “jail” porque neste momento meu usuário está preso dentro dessa cadeia. Ele acredita que meu HD de verdade é o que está dentro da cadeia. Por isso copiei as bibliotecas do bash e ls pra dentro, senão eles nem iam conseguir executar. Se der exit, pronto, voltamos ao normal. ls / agora lista minha partição de verdade.

Sei que é um pouco confuso isso, mas vocês tem que perder a noção de associar a raíz do sistema com seu HD físico. A raíz do sistema é um ponto de montagem, por acaso eu associo “/” com a partição usando o sistema de arquivos ext4, é o que tá configurado no arquivo “/etc/fstab”. Mas posso mudar isso dinamicamente mesmo depois do boot. Linux é um sistema dinâmico, não pense nele como algo congelado e fixo.

Chroot é bem útil pra várias aplicações, mas um uso errado é segurança. Se procurar no Google vai achar tutoriais, por exemplo, pra fazer um usuário se conectando via SSH cair dentro de um chroot. Alguns pensam que é uma boa forma de evitar que o usuário consiga enxergar o sistema de arquivos de verdade da máquina por baixo. Uma forma de segurança. Mas chroot nunca foi projetado pra ser usado pra segurança.

Antigamente, coisa de mais de 20 anos atrás, a gente usava chroot em processos como servidor web Apache, na esperança que se o apache fosse invadido, o invasor ia cair dentro de um chroot e não ter acesso à partição toda do servidor. De novo, chroot não é mecanismo de segurança. Deixa eu provar com o tiro pode sair pela culatra. Chroot é executado como root e permanece com o setuid de root dentro. Vamos tentar estourar essa prisão. Nada nessa manga, nada nessa outra. Minto na verdade eu tenho um programinha feito em C que achei no Google. Esse aqui.

`#include <sys/stat.h>

include <stdlib.h>

include <unistd.h>

//gcc break_chroot.c -o break_chroot

int main(void) { mkdir(“chroot-dir”, 0755); chroot(“chroot-dir”); for(int i = 0; i < 1000; i++) { chdir(".."); } chroot("."); system("/bin/bash"); }`

Vou compilar, copiar esse binário pra dentro do diretório jail/bin, entro no chroot de novo, estou preso, tá vendo? Não enxergo nada fora. Agora é só executar e .. boom, olha só, não só estourei pra fora do jail como invadi o usuário de root dessa máquina. Isso que se chama escalação de privilégios.

O que ele faz é simples. Esse programinha poderia ter sido feito em python, shell script ou o que quiser. Ele só cria um novo diretório com mkdir, dentro dele faz um loop com equivalente a cd .. mil vezes, e sabemos que “..” é pra voltar pro diretório anterior. Mas ele explora algum bug do chroot que ao fazer isso um tanto de vezes e depois criar outro chroot dentro desse chroot, ele estoura pra fora e mantém os privilégios do usuário que criou o primeiro chroot, que foi o root.

Enfim, essa tangente foi só apresentar chroot e pra ilustrar o ponto que apesar de parecer um mecanismo de segurança ao isolar o usuário num diretório mais limitado, na realidade não é, é uma conveniência que serve justamente pra coisas como instalar de Linux, que é justamente o que o tutorial do wiki do Gentoo vai nos mandar fazer no próximo passo.

Veja que na página de Wiki a próxima seção se chama justamente “Chroot”. Entramos no diretório cd /mnt/gentoo que foi onde descompactamos aquele arquivão stage3 e instalamos todos os arquivos do sistema. Criamos pontos de montagem pra diretórios virtuais especiais de Linux usando parâmetros especiais do comando mount. Pra proc, sys, dev e run, tudo dentro do /mnt/gentoo.

Com tudo montado, no final copio o “/etc/resolv.conf” que tem configuração de DNS e faço um chroot pro diretório corrente, executando o /bin/bash que tá dentro desse chroot. A partir de agora, pro meu usuário, o novo “/” é o que tem no diretório “/mnt/gentoo”, sacaram? Estou dentro do meu gentoo recém instalado, sem precisar bootar. Saí da partição do LiveCD e entrei na partição do novo Linux instalado no meu HD. Assim posso mexer lá dentro sem ter que bootar ainda. E nem daria pra bootar, porque essa instalação ainda não tem kernel e nem bootloader configurado, que é o que fazemos agora.

De novo, a partir deste ponto é como se eu já estivesse no novo Gentoo instalado no meu HD de verdade, sem ter precisado bootar. Isso é um jeito super rudimentar e incompleto de container, como um Docker. Você já está num Linux funcionando, a gente só muda a raíz do usuário pra outra raíz em outra partição e de lá de dentro é um Linux com ferramentas diferentes, embora usando a mesma kernel que já tava carregada. Ainda não é hoje que vou falar de containers, mas pra chegar lá achei útil explicar que chroot existe, e apesar de ter um efeito parecido, não é usado em containers de verdade.

Agora que estamos dentro do nosso novo Linux, o que todo mundo sempre fala pra fazer logo que instala um Linux novo? Atualizar os pacotes com o repositório online pra ver se tem pacotes novos pra instalar. Num Ubuntu da vida, no terminal, é só executar apt update && apt upgrade. Mas Gentoo não usa Apt e sim Portage e o comando é emerge. Gentoo não instala software, ele “emerge” software .. Enfim, o equivalente ao apt update é emerge-webrsync. Pra aprender outros comandos de emerge, a wiki tem outra página com um cheat sheet, explicando as principais opções. Vou deixar o link na descrição abaixo.

Feito isso, até agora só temos o usuário de root funcionando, mas sem senha. Então precisamos criar uma senha forte pro root com o comando passwd. Por acaso a política de senhas do Gentoo é mais restrita que de um Ubuntu, ele exige senhas um pouco mais fortes, então cuidado aqui. Depois disso, só criar um usuário normal não-administrador com o comando useradd e mudar a senha dele também.

Precisamos editar alguns arquivos de configuração, então próximo passo é instalar um editor de textos de linha de comando decente. Por isso emerge -vq vim. Se ainda não sabe usar vim, tudo bem, usa um nano da vida, qualquer editor serve, mas você precisa aprender a usar um editor de linha de comando. VSCode não vai te ajudar quando precisar dar SSH num servidor. Depois disso precisamos editar o arquivo “/etc/fstab”, que já expliquei no video passado, é onde declaramos os pontos de montagem principais, ligando partições como “/dev/sda1” com pontos de montagem como “/boot”.

Como expliquei no começo, o conceito todo do Gentoo é baixar pacotes de código-fonte dos softwares e compilar na hora de instalar. Significa que temos que configurar o compilador com parâmetros de compilação e a configuração global do Portage fica no arquivo “/etc/portage/make.conf”. Lendo as páginas de instalação do Wiki, mantenho tudo igual e só no final adiciono as seguintes variáveis de ambiente:

ACCEPT_LICENSE="*" GRUB_PLATFORMS="efi-64" USE "-qt5 -kde X gtk gnome" VIDEO_CARDS="vmware" INPUT_DEVICES="libinput synaptics"

De novo, isto não é pra ser um tutorial completo de instalação, certamente tem mais configurações importantes que eu não vi, então faça sua pesquisa. Pra mim, nesse cenário de máquina virtual, isso foi o suficiente. E no meu caso vou instalar GNOME como gerenciador de janela, por isso tem “-qt5 -kde”, pra priorizar opções em gtk e gnome.

Vale a pena explicar é esse Accept License pra asterisco. Acho que o emerge restringe instalar pacotes de softwares com licenças não livres, daí ele mascara esses pacotes e eu tive problema de não conseguir instalar por causa disso. Mas dizendo pro Portage aceitar as licenças, daí consigo instalar. E veja também em Video Cards que isso é necessário no meu caso porque estou num Vmware. Se você tiver placa de video NVIDIA teria colocado “nvidia” ou se fosse AMD seria “amdgpu” e assim por diante.

Além disso, o grande lance do Gentoo é baixar pacotes de código fonte e compilar, por isso nesse arquivo tem CFLAGS e CXXFLAGS, que são opções pro compilador GCC. Tem outra página no Wiki explicando essas e outras flags que eu recomendo que vocês leiam e não saiam só copiando e colando coisa aqui sem saber porque. Por exemplo, o flag “-O2” é o nível de otimização que o compilador vai usar. “-O1” é o mais básico e “-O3” é o máximo. Tem gente escrevendo em fórum que conseguiu um executável mais rápido usando um “-O9” da vida. É mentira, não existe esse nível, o máximo é 3.

Tem gente recomendando usar flags como “-funroll-loops” pra otimizar mais, e de novo, como o Wiki explica, o próprio manual do GCC fala pra não usar isso, porque você vai acabar com um binário maior e mais lento. Flags agressivas devem ser usadas só pro programadores que realmente sabe o que elas fazem, em software que foi escrito pra tirar vantagem disso. Não devem ser usadas em pacotes aleatórios e muito menos pro sistema inteiro. Se ficar usando flags aleatórias, vai acabar com binários mais pesados, mais lentos e mais instáveis e seu sistema vai ficar uma bosta. E a culpa não é o Gentoo, é você que sai copiando e colando coisa sem saber.

Seguindo nosso guia do Wiki, tem configurações opcionais que vou passar acelerado. É só seguir o que diz no Wiki. Mas seria configuração de locale, hostname, keymap, timezone. Nenhum detalhe importante pra agora…. E finalmente chegamos na parte importante que diferencia o Gentoo dos demais, na minha opinião, a seção de customização da Kernel agora na instalação. Na real, você pode customizar kernel em qualquer distro, mas no Gentoo isso faz parte do processo de instalação.

Pra isso precisamos do código-fonte. Executamos emerge -av sys-kernel/gentoo-sources sys-kernel/linux-firmware. Note que pacotes em Gentoo são organizados em namespaces como “sys-kernel”. Enfim, quando terminar, entramos no diretório de código-fonte que é o “/usr/src/linux” e a versão.

Se nunca teve a oportunidade de fuçar o código fonte da kernel do Linux, eis sua chance. Depois abra um editor de textos qualquer e perca algumas horas vasculhando o código, talvez aprenda algo. Não tenha medo de código só porque parece complicado. Justamente porque parece complicado é que deveria ser fascinante. Na prática, uma boa parte do código vai ser de drivers de dispositivos.

Apesar do código fonte do Linux ser um enorme monolito, tudo organizado num mesmo repositório, o binário em si é mais ou menos modular. Existem vários drivers que são compilados estaticamente no mesmo binário da kernel. Acho que o driver do sistema de arquivos ext4, por exemplo, fica dentro do binário da kernel. Porém existem drivers que não são carregados imediatamente no boot. São compilados separadamente, como objetos ou bibliotecas, e podem ser carregados depois, com comandos como modprobe.

Sem mais delongas, do diretório de código fonte, vai ter um Makefile, como mostrei no episódio passado, lembram? Todo programador de C sabe lidar com Makefiles e aqui não é diferente. Vai ter uma tarefa chamada menuconfig, que carrega com make menuconfig. Abre esse programa interativo em modo texto, acho que usando ncurses. É uma lista de categorias de módulos de kernel.

Tudo que tá desmarcado, é porque não vai ser compilado. O que estiver com “*” vai ser compilado e linkado estaticamente, ou seja, vai estar dentro do binariozão da kernel. E o que estiver com “M” vai ser compilado e mantido desativado num arquivo separado até ser carregado por comandos como modprobe. Você quer manter o máximo de pacotes desmarcados, se possível.

Por exemplo, sei lá porque, por padrão vem marcado suporte pra PCCards, padrão PCMCIA ou Cardbus. Eu nunca mais vi esse tipo de dispositivo nos últimos 20 anos. Pra quem não sabe, antes de ter conectores como Thunderbolt ou USB, uma das formas de adicionar um hardware externo num notebook dos anos 90, era com cartão PCMCIA. Eram coisas como essas. Até imagino que deva ter hardware especializado em alguma indústria que ainda precise disso, mas pra pessoas normais como eu ou vocês aí, nunca vamos precisar disso. Não faz sentido a kernel sempre carregar esse driver e ficar ocupando espaço na RAM. Posso desmarcar.

Na real, vamos sair e fazer outra coisa antes. Note que estamos ainda no ambiente de LiveCD do pendrive. E tá tudo funcionando bonitinho, ou seja, a detecção automática de hardware funcionou até que bem. Seja lá quais drivers foram carregados, tá fazendo nossa máquina funcionar. Então, por que não selecionar os mesmos drivers que já estão carregados? Pra isso podemos rodar o comando make localyesconfig pra atualizar o arquivo .config com esses drivers. E aí sim, voltamos pro make menuconfig e tiramos suporte a PCMCIA e outras coisas que sabemos que não vamos precisar.

Podemos sair tirando mais coisas, como suporte a hardware de Chromebooks, ou suporte a notebooks Surface da Microsoft. Normalmente o que você mais vai mexer é a categoria de Device Drivers. Nas outras opções, a menos que tenha certeza absoluta, não mexa, especialmente em categorias como Criptografia, Gerenciamento de Memória. Isso é bom pra você fuçar se estiver pesquisando sobre sistemas operacionais mais a fundo. Mas pra usuários iniciantes, o ideal é mexer bem pouco.

No meu caso, agora entra aquela outra página de Wiki que falei no começo, que lista alguns módulos específicos pro caso onde estou numa máquina virtual VMWare. Então eu gostaria de carregar drivers de Vmware. Por exemplo, em Device Drivers, Network device support, preciso selecionar o driver VMware VMXNET3 ethernet. Nessa página tem essa listinha sugerindo módulos pra checar e ativar. Depois que terminar, só selecionar lá embaixo a opção de “Save” e sair.

De volta à linha de comando, agora é hora de compilar a kernel. Vamos compilar com o comando make -j4. No tutorial ele sugere “-j2”. Essa opção “j” significa “jobs” ou trabalhos em paralelo, que é quantos arquivos vai compilar ao mesmo tempo. “j2” é o mínimo, vai usar só duas threads da sua CPU. No meu caso, eu dei 2 cores da minha CPU de verdade com 2 threads cada, então posso rodar com “-j4”.

Se estivesse nativo no meu AMD Ryzen 9 de 32 threads, eu poderia rodar com “-j32”. Quanto mais cores tiver pra gastar, mais rápido vai ser a compilação, porque vai tudo em paralelo. Porém, quanto mais rodar em paralelo, mais RAM precisa ter. Se for agressivo demais em jobs paralelos e tiver 4 giga ou menos de RAM, provavelmente vai crashear, então cuidado.

Esse arquivo vmlinuz que gera no final é o binário da kernel. Se nunca viu um Linux de verdade na sua frente, muito prazer, este é “O” Linux que todo mundo tanto fala mas ninguém nunca viu. E não só isso, esse é um kernel feito sob medida especialmente pra você, sem carregar muita coisa desnecessária. Numa distro normal como Ubuntu ou Manjaro, vem com uma kernel mais genérica que precisa suportar os mais diferentes tipos de hardware, então eles tentam manter mais drivers ativos do que realmente é necessário, consumindo mais RAM.

Esse é o custo da comodidade. Um usuário normal não quer ter que configurar sua própria kernel do zero, então se contenta em desperdiçar um pouco de RAM e um pouco até de processamento, carregando uma kernel mais gorda do que precisa, só pro caso de um dia precisar de um hardware mais exótico. Mas a filosofia do Gentoo é justamente compilar tudo do zero pra termos a oportunidade de escolher tirar tudo que sabemos que não vamos precisar.

Agora que temos a kernel, precisamos colocar na partição de boot junto com um bootloader. Lembram de dois episódios atrás que expliquei sobre boot? Vamos instalar o bootloader com emerge --ask sys-boot/grub. Uma vez instalado, como estamos num ambiente EFI, rodamos grub-install --target=x86_64-efi --efi-directory=/boot/efi pra instalar o bootloader na partição de boot. E instalamos a kernel com grub-mkconfig -o /boot/grub/grub.cfg.

E pronto. Pra terminar, só instalar o suporte a rede pra no próximo boot conseguir carregar wifi, rodar dhcp e tudo mais. O wiki sugere essa linha de comando grandão aqui, mas como estou numa máquina virtual, sei que não vai ter wifi, porque estou simulando uma rede cabeada na máquina virtual, por isso só rodo emerge --ask sys-apps/iproute2 net-misc/dhcpcd. E acabou a parte do LiveCD. Saímos com exit e damos um reboot de uma vez.

E que estranho. Cadê a opção da kernel que acabamos de bootar? O menu do Grub tá vazio. Ele entra no menu UEFI da máquina. Bom, obviamente fiz alguma coisa errada, mas por aqui podemos bootar de novo pelo LiveCD no CD-ROM virtual. Vamos voltar pro ambiente que estávamos antes. Lembra que eu falei que o LiveCD serve pra diagnosticar e resolver problemas caso o boot falhe? Vamos ver isso na prática.

De volta àquele KDE do LiveCD, abrimos o terminal e vamos criar os pontos de montagem das nossas partições de novo. Pra não ficar repetitivo é essa sequência igual tá no começo da página de wiki. Ir criando os diretórios, daí mount de coisas como proc, run, sys e finalmente o chroot de novo. E enquanto fazia isso que me toquei. Eu terminei de compilar a kernel e logo depois fui instalar o Grub, mas esqueci de instalar a kernel. Vamos voltar pro diretório “/usr/src/linux”. Faltou rodar make modules_install e make install. Burro.

Sempre que compila e instala uma nova kernel, tem que lembrar de atualizar o Grub. Só rodar grub-mkconfig -o /boot/grub/grub.cfg. Pronto, podemos dar exit pra sair e reboot. Esperamos alguns segundos e agora sim, temos a opção do nosso Gentoo novinho. Escolhemos ele, começa a sequência de boot do sistema init. E … caraca, que porra é essa?

A mensagem diz que a CPU foi desabilitada e a máquina parou de bootar. Literalmente ou a kernel deu crash ou deu uma instrução HLT de halt and catch fire. Nunca tinha visto isso em nenhuma outra instalação de Linux. Certamente fizemos alguma coisa errada na hora de compilar a kernel que agora ela não boota. Isso vai acontecer bastante nas primeiras vezes que você tentar compilar sua própria kernel e acabar desabilitando coisa que não devia.

E eu estou deixando esses erros aparecer no video de propósito pra vocês saberem que sim, esses erros acontecem o tempo todo. E sim, em videos como esse todo youtuber corta fora as partes de erro. Por isso parece que no video tudo é perfeito e só você que deve ser ruim porque no seu dá erro. Mas pra todo mundo dá erro, a gente corta senão o video ia ficar muito cansativo.

Temos que resetar à força de novo, escolher o menu da UEFI no Grub pra poder escolher bootar pelo LiveCD. E lá vamos nós outra fez, cair no KDE do LiveCD, abrir o terminal, refazer os pontos de montagem e dar chroot … Alguma coisa eu fiz errado quando desmarquei coisas do kernel. Vamos abrir o menuconfig outra vez … (5 min later …)

Se olharmos a página de Wiki sobre Vmware, fala que preciso checar se estes módulos aqui estão selecionados, e eu vi que estão. Muito estranho. Selecionei de volta tudo que lembro que tinha tirado. Vamos compilar de novo com make -j4 …. (5 min later), pronto, agora é fazer outra vez make modules_install e make install e grub-mkconfig.

Pra garantir, acho que não faz diferença pra agora, mas vamos aproveitar pra instalar o pacote open-vm-tools, que é a versão open source do antigo pacote proprietário vmware-tools, as ferramentas da Vmware pra Guests. Ele configura coisas como resolução da tela, rede, clipboard compartilhado com o host, sincronia da hora com o host. Talvez tenha algum driver que falta. Pra instalar é só fazer emerge --ask app-emulation/open-vm-tools.

Se fosse systemd como num Ubuntu, precisaria fazer systemctl start vmware-tools mas como escolhi o stage3 com OpenRC precisamos fazer rc-service vmware-tools start e olha só, dinamicamente carregou o driver de video da Vmware e ajustou a resolução da máquina. Bom sinal. Pra garantir que vai carregar no próximo boot, só fazer rc-service add vmware-tools. Mas tá vendo, systemd ou openrc, pro usuário final, é mais diferença de sintaxe entre os comandos systemctl e o rc-service.

Podemos sair, rebootar e … Caraca, mesma coisa. Crash. Vamos bootar outra vez pelo LiveCD .. (5 min later) .. pronto. Tudo que a gente modifica naquela tela interativa do menuconfig no final é gravado no arquivo .config. Deixa eu abrir direto ele. Comparando com a Wiki, ele fala NET_VENDOR_AMD, vamos procurar e sim, tá yes. AMD8111_ETH, tá yes também. Vamos checar um a um (5 min later), FUSION … ué, tá comentado. Mas eu juro que no menuconfig o Fusion MPT que é driver de Scsi Host, tava habilitado. Estranho, vamos descomentar e dar yes.

Gravamos e damos make -j4 de novo. E olha só, ele vai me dando opção de configurar outras opções novas, como Fusion SPI, que também precisa estar habilitado. Vamos lá então. Vai continuar a compilação como antes. No final, repetimos a mesma sequência, module_install, install, grub-mkconfig … saímos com exit, e reboot com dedos cruzados.

Máquina rebootando … e caraca, agora passou!! Como eu mexi mais coisas além do Fusion SPI, não sei se foi isso que resolveu ou não, mas pqp. Fiquem espertos, talvez vocês rodem num Vmware também e não tenham problema nenhum, talvez tenham problemas diferentes, mas enfim, vai ter problemas desse tipo e vai ter que ficar indo e voltando como eu fiz. Agora sim, termina o boot e chega até a o prompt de login em modo texto, ou seja, runlevel 3 de multi-user. Vamos instalar uma interface gráfica pra gente.

Entramos com sudo su pra continuar como root. Gentoo tem conceito de profiles, sets e coisas assim que ainda não sei muito bem os detalhes. Mas segundo o Wiki, preciso me certificar que estou no profile de desktop gnome com openrc. Pra isso posso ver os profiles disponíveis com eselect profile list. Seleciono o certo com eselect profile set default/linux/amd64/17.1/desktop/gnome/systemd. Pronto.

Antes de continuar, vamos mexer na configuração do Portage em “/etc/portage/make.conf”. Tinha faltado INPUT_DEVICES. Colocamos libinput e synaptics que é pra touch pads. E no final configuramos o parâmetro USE pra ignorar qt5 e kde e prioriza X, gtk e gnome. E é isso. Pra instalar o gnome é só fazer emerge --ask gnome-base/gnome.

Mas, já temos um erro. No caso um erro de dependência circular. Vira e mexe vai esbarrar nisso em Gentoo e não tem uma resposta automática. Nesse caso tem dois sistemas de áudio concorrentes e ele não sabe qual instalar. Mas como falei antes, leia a porra do erro. Já diz que é ou pra escolher “minimal” ou “pulseaudio”. Pra corrigir basta mudar o comando pra USE="minimal" emerge --ask gnome-base/gnome.

Só que deu erro de novo. Leia com atenção, é um erro diferente. Agora fala que não consegue instalar o pacote x11-base/xorg-server. Gnome, Kde, Xfce e qualquer gerenciador de janelas roda em cima do servidor gráfico X11, ou em distros mais novas, em cima do Wayland. Então precisa instalar o X11, só que o erro diz que ele não consegue instalar com essa flag “minimal” que acabamos de colocar. Uma das formas de resolver é instalar o xorg-server sozinho com emerge --ask x11-base/xorg-server. Não sei se é a melhor forma mas, é isso, tá instalando. Temos que esperar alguns minutos porque o X11 é bem grandinho e compilar leva tempo … (5 min later)

Com o xorg instalado, podemos tentar instalar o gnome de novo com o mesmo comando de antes e agora passa! Baixa o código fonte, começa a compilar e pode ir almoçar, vai na academia, vai ler um livro. Sério. Um gerenciador de janelas, Gnome, Kde ou qualquer um é composto por dezenas de pacotes, milhões de linhas de código, e o Gentoo vai compilar tudo do zero.

Eu configurei esta máquina virtual com 2 cores e 2 threads e 8 giga de RAM, uma configuração bem fraquinha. Se estivesse nativamente no meu Ryzen 9 de 32 threads com 64 giga de RAM, ia acabar em poucos minutos, mas numa máquina fraca dessas, vai levar mais de 2 horas fácil. Nem tô brincando … Até logo, a gente se vê mais tarde

(1 year later …)

Ufa, parece que agora terminou. Caraca, sério, é muito tempo. Nem tô brincando. Vamos no wiki ver o que falta fazer. Ele manda atualizar as variáveis de ambiente com env-update && source /etc/profile. Daí manda colocar nosso usuário no grupo plugdev com getent group plugdev primeiro pra checar, e sim, tá lá. Então gpasswd -a akitaonrails plugdev.

Finalmente, precisamos habilitar o DM, no caso o GDM. E o GDM precisa do elogind no boot. Opa, falei grego, eu sei. Que diabos é DM? É acrônimo pra Display Manager ou, mais corretamente, Login Manager ou gerenciador de Login. É aquela primeira tela gráfica que pede seu login e senha depois do boot. É ele que se encarrega de carregar o GNOME propriamente dito. Por padrão o X carrega o XDM, então precisamos trocar pro GDM porque o XDM não consegue carregar Gnome.

Pra isso primeiro precisamos configurar o serviço elogind pra carregar antes no boot com rc-update add elogind boot. Agora precisamos instalar o serviço que inicia o display manager com emerge --ask --noreplace gui-libs/display-manager-init e editamos o arquivo /etc/conf.d/display-manager com vim. Tá vendo? Lá embaixo o padrão é “xdm” então trocamos pra “gdm” e salvamos.

Por fim, configuramos o serviço pra iniciar automático, colocando no runlevel padrão com rc-update add display-manager default. Teoricamente é só isso, só rebootar agora … e … falhou, por alguma razão ainda tá tentando carregar o XDM, que não existe, e sai fora. E lá vamos de novo investigar. (5 min later) Fiquei fuçando aqui e checando se aquele arquivo de configuração tá com “gdm” mesmo, o serviço elogind também carregou normalmente, tá difícil.

Mas achei estranho que também não encontrei o gdm. Uma hipótese é que inicializador tenta carregar o GDM, não acha, e como alternativa tenta carregar o XDM, que também não tá instalado. Imaginei que o pacote “gnome-base/gnome” já automaticamente instalava, mas pelo jeito não, ou deu algum erro que eu passei batido e não vi, então vamos instalar com emerge --ask gnome-base/gdm. De novo, hora de mais um café, porque esse também demora pra compilar … (1 year later)

(levanta .. CONTINUA … volta …)

Dessa vez estou cortando fora as várias horas que eu levei apanhando do GDM. Na real, da dependência do GDM e do GNOME que é o webkit-gtk. Puta pacote bosta. Ele ficava dando erro, eu tentava de novo e nada. Rechequei configuração, flags de compilação e gastei um tempo lendo fóruns que achei no Google, até num deles tive um insight. Lembra que falei que se tentar compilar muito agressivo, numa máquina fraca, pode faltar RAM? Acho que foi isso, o compilador crasheava por falta de memória, dava erro e parava. Só que o compilador não diz que faltou memória, ele fala que deu erro numa linha de um script que voltou false.

Mas sim, voltou false porque deu crash. Aumentei pra 16 giga e vamos compilar de novo. Nos vemos em duas horas … (2 hours later) …

Será que agora vai? Opa, sem erro na deteção do GDM e … e … ha! Carregou o GDM!! Vamos logar … opa, senha errada … de novo. Pronto! Caraca, um dia inteiro pra no fim descobrir que era falta de memória. Vai se fuder. E olha só, isso é um GNOME zerado, sem nenhuma opção extra, sem nenhum aplicativo pré-instalado. Agora eu posso instalar exatamente só os programas gráficos que eu quiser, e não ter que ficar com aquele monte de lixo que toda distro já pré-instala pra mim. Eu não preciso de cliente de email, não preciso de gerenciador de foto. Nesse sentido, eu gosto disso de poder instalar minhas próprias coisas.

A moral da história é: não tente instalar um gerenciador de janela pesado como GNOME numa máquina fraca com menos de 8 giga de RAM. Provavelmente tinha flags de GCC que eu podia ficar mexendo, mas na prática só ia deixar a compilação ainda mais lenta. E sério, puta componente lento de compilar. Toda vez que tentava de novo era fácil mais de 1 hora até terminar em crash. Configurar um Gentoo não é pros fracos. E se você tem máquina fraca, escolha um gerenciador de janela mais leve, como XFCE. Apesar que a culpa nem foi do GNOME, foi do webkit. De curiosidade, vocês sabem o que é Webkit?

Webkit é o framework de navegadores, a engine de HTML, CSS que roda por trás do Safari de Mac e que inicialmente estava nos Chrome. Acho que o Chrome é meio que um fork ou rewrite de Webkit e evolui separado. Mas o Webkit não é o navegador, ele é usado dentro de navegadores como o Konqueror, e todo aplicativo desktop que exibe HTML, como cliente de email. Justamente por isso é provavelmente o componente mais pesado que você vai instalar na sua máquina. Sério, olha o tanto de hora que leva pra compilar essa porra. Uma engine de web não é um troço pequeno, porque a web hoje é desnecessariamente complicada. Valeu Apple e Google, por tornar a web pior.

Aliás, falei que não veio nenhum aplicativo instalado aqui. Inclusive não tem nem loja de aplicativos e nem terminal. Como que eu instalado um terminal sem ter o terminal? Lembrem dos meus videos anteriores, vocês tem 5 segundos pra adivinhar. 4, 3, 2, 1 … vamos mudar pro runlevel 3. Ctrl + Alt + F3. Pronto, de volta pro console em modo texto. Agora daqui eu posso instalar qualquer aplicativo de terminal que eu quiser, como o Alacritty, que é meu preferido. E quando terminar, volto pro modo gráfico com Ctrl + Alt + F5.

Enfim, finalmente, temos GNOME bootando bonitinho neste Gentoo quentinho saído do forno, configurado com OpenRC em vez de systemd pra gente ter um ambiente pra estudar melhor OpenRC e se é melhor mesmo do que o Systemd. Falando nisso, tem essa outra página no Wiki que fala de GNOME sem Systemd. Lá explica que antes dava pra carregar GNOME sem problemas tanto com systemd quanto openrc. Mas isso mudou.

Como expliquei no episódio anterior, o systemd faz mais do que só gerenciar resolução de dependências e start de serviços. Agora gerencia também coisas como economia de energia e outras atividades do sistema, inclusive gerenciar o diretório /dev de dispositivos, lembra dele? Por causa disso surgiram dois projetos que extraem essas coisas do systemd, projetos como elogind que instalamos antes e eudev. Assim é possível usar só essas partes do systemd e substituir por OpenRC e conseguir subir o Gnome.

Essa é outra das críticas do systemd: que ele faz muito mais do que deveria. Um sistema de init deveria só gerenciar inicialização. Software pra controlar “/dev” deveria ser separado, em outro pacote, de tal forma que desse pra instalar um, sem instalar o outro. Mas o systemd é um código-fonte monolito, ou compila tudo junto, ou nada funciona.

Pra extrair projetos como elogind e eudev, dá um puta trampo, porque toda vez que o systemd atualiza e muda as coisas, esses outros projetos precisam extrair de novo o que mudou pra nada quebrar. É realmente uma grande perda de tempo e consigo entender porque muitos desenvolvedores de Linux estão putos com isso.

De qualquer forma, pra gente que contribui no desenvolvimento de distros, é bom saber que essa discussão existe e se tiver interesse depois procura fóruns de desenvolvimento pra ver como as coisas estão evoluindo. Eu pessoalmente não tenho muito interesse porque não contribuo com software livre, mas quem contribui precisa entender essa novela. No mínimo é um bom estudo pra saber como a comunidade lida com conflitos assim.

Sobre o Gentoo em si. É um excelente exercício se desafiar em controlar essa besta selvagem. É o extremo oposto de instalar um Ubuntu da vida. Você realmente vai perder muitas horas, muitos dias, em tentativas e erros, lendo muita documentação no Wiki deles, e no mínimo serão horas de muito estudo e aprendizado que uma hora vai ser útil em outras distros de Linux. Todo mundo que tem alguma vontade de brincar no mundo de devops, esse é o hello world do hello world. Se não consegue nem se virar com a instalação de um Gentoo, que tem documentação bem organizada, imagina clusters de servidores mais avançados ou sistemas embarcados mais restritos.

Porém, sobre a filosofia de sempre compilar tudo do zero, acho que é uma faca de dois gumes. Pensando exclusivamente no meu caso. Eu tenho uma máquina parruda, um Ryzen 9 com 64 giga de RAM e todo o espaço em disco que eu precisar no meu NAS de 10 gigabits, com velocidade superior a SSDs. Pra fazer os últimos episódios instalei dúzias de máquinas virtuais de teste. No final, o Gentoo é o que realmente dá sensação de mais responsivo, um pouco mais rápido, e isso provavelmente se deve a ter compilado tudo exclusivamente pra minha máquina, eliminando muita gordura no processo.

Mas como falei antes, instalar X11, Gnome, GDM, na verdade o pacote webkit, custou literalmente umas 3 horas, a CADA tentativa, e até eu descobrir o problema, foram VÁRIAS tentativas. Foi quase um dia inteiro repetindo esse processo até resolver o erro. Enquanto ficava esperando, escrevi quase o script inteiro desse episódio, com tempo sobrando pra revisão. Não tô brincando, é muito tempo. Tudo bem que foi numa máquina virtual. Se fosse no meu hardware nativo, num dual boot, teria sido ordens de grandeza mais rápido. Mas é justamente esse o ponto.

Quem tem hardware parrudo como o meu, não se importa tanto se tá ganhando 1 milissegundo a mais de performance por ter compilado tudo nativo. Os milissegundos que vou ganhar, não compensam a espera em compilar tudo do zero toda hora. Minha máquina já é rápida o suficiente. Mesmo se o binário for mau feito e pesado, vai rodar de boas. Quem realmente precisa da otimização é quem tem máquinas mais lentas ou antigas. Só que agora a compilação também vai ser ordens de grandeza mais lento, nessa faixa de levar mais de 3 horas pra conseguir instalar um simples GNOME.

Ou seja, quem mais precisa da performance extra, vai toda hora perder muita produtividade quando precisar instalar pacotes, porque todo novo software, precisa baixar o código fonte e esperar compilar tudo. Nem sempre é demorado assim, a maioria dos softwares são pequenos. Mas imagina agora quero instalar Firefox, lá se vai mais uma ou duas horas. Agora preciso instalar Ruby, ou Python, mais 1 hora. Você tem que ser disciplinado de não tentar instalar nada grande no meio do expediente, senão acabou o dia pra você. Sério. É meio duvidoso até onde tem vantagem.

O benefício de um Gentoo vem quando você tem uma máquina fraca que não vai ficar usando no dia a dia. Por exemplo, um PC fraco que quer usar como servidor multimídia, ou um roteador de rede, ou um NAS. Uma máquina com um único propósito, idealmente sem nem precisar de interface gráfica, que é a compilação mais pesada. Por isso falei em aplicações de sistemas embarcados, ou IoT. Aí sim, você precisa economizar o máximo de recursos, e quando terminar de instalar, não vai ficar adicionando mais nada. Um Gentoo é perfeito pra isso.

Outro objetivo dos exercícios dos últimos videos é mostrar o seguinte: qual é a melhor distro? Não existe essa resposta. Todas são boas, e em todas roda praticamente todos os mesmos software, é tudo software livre. Em alguns dá mais trabalho ou menos trabalho instalar esse ou aquele software, mas na prática dá no mesmo. Se tiver um dispositivo periférico muito exótico, no final vai ter que compilar kernel na mão de qualquer jeito, e em qualquer distro pode fazer isso. Não é só em Gentoo que pode customizar kernel. No Ubuntu também dá. Só baixar o código fonte, subir o menuconfig, compilar e mandar o grub configurar no boot.

Pra quem é iniciante, povo recomenda instalar Ubuntu ou PopOS da vida porque são triviais, por causa do Calamares, e por serem populares, tem documentação de tudo na internet. Tem fóruns de discussão ativos. Tem salas de chat com gente discutindo a respeito. Vai ser mais fácil de achar solução pra qualquer problema neles. Por outro lado, se usar um distro dessas, não vai aprender nada sobre Linux. Clicar com mouse e arrastar janela não te ensina absolutamente nada. Esquece colocar no currículo “Sei Linux” só porque instalou um Ubuntu. Sabe bosta nenhuma. Só sabe abrir o Chrome e navegar. Isso você faz em Windows ou Mac igual.

Saber Linux é no mínimo estar confortável com tudo que eu fiz nos últimos videos. Saber o que é chroot, o que são pontos de montagem, o que é escalonamento de privilégios, como se customiza a kernel, como configura um bootloader, como diagnostica dependências de binários, como monta um pacote. Olha só tudo que a gente viu até agora. Isso minimamente “saber Linux”, e o que mostrei até agora, foi só o hello world, os conceitos básicos. Começa a ler a Wiki do Gentoo ou Arch. Aí você vai ver o quanto ainda falta pra realmente “saber Linux”.

Por isso, sim, tente instalar Slackware, tente instalar Gentoo, tente instalar Arch. Esse é o exercício que todo aprendiz de Linux precisa passar. O fim de semana inteiro varando noite de sábado pra domingo, saindo de uma mensagem de erro pra outra mensagem de erro, até ter a satisfação de ver tudo bootando e funcionando no final. Aí sim você sabe que aprendeu alguma coisa de verdade.

Aliás, eu até entendo porque no final tem um grupo de pessoas que defente um Gentoo com unhas e dentes, porque depois de tantas horas e dias dedicado em fazer tudo funcionar na sua máquina, horas e horas esperando tudo compilar e tendo que repetir tudo de novo quando dá erro. Dá muita dó jogar fora e mudar de distro. É meio que síndrome de Estocolmo, já sofreu tanto, agora fica com ele. Mas eu sou um psicopata altamente funcional. Gastei dias configurando tudo, no final jogo tudo fora e pulo pra outra coisa. Quem consegue desapegar de coisas que investiu horas em cima, sempre vai ter mais vantagem, pense nisso.

E o assunto ainda não chegou ao fim, o próximo video vai ser mais conceitos de Linux que você não sabe. Então, se ficaram com dúvidas mandem nos comentários abaixo, se curtiram o video deixem um joinha, assinem o canal e compartilhem o video com seus amigos. A gente se vê, até mais!

DESCRICÃO

Continuando sobre minha coleção de teclados mecânicos, agora quero mostrar alguns dos meus ítens mais exóticos. Mais do que isso vou falar sobre ergonomia e ainda quero aproveitar o gancho pra contar uma história sobre UNIX e Linux que muitos nem sabem ainda!

Mas pra quem estava esperando por isso também vou mostrar o que eu elegi como melhor custo-benefício. Assistam até o final!

De novo, como o video tem muitos itens diferentes, vou deixar um bookmark das seções pra ficar fácil voltar depois:

• 01:34 - Keychron K2
• 04:52 - Drop Ctrl
• 08:18 - Um pouco sobre Ergonomia
• 15:31 - Ultimate Hacking Keyboard
• 20:33 - QwerkyWriter S
• 23:42 - SURPRESA 1 (sem spoilers aqui)
• 26:46 - Um pouco de história
• 33:53 - Um pouco de UNIX
• 39:34 - SURPRESA 2

Links:

• QWERKYWRITER® S (https://www.qwerkywriter.com/collections/frontpage/products/qwerkywriter-s-typewriter-inspired-mechanical-keyboard)
• Keychron K2 Wireless Mechanical Keyboard (https://www.keychron.com/products/keychron-k2-wireless-mechanical-keyboard?variant=31063869620313)
• MASSDROP CTRL MECHANICAL KEYBOARD (https://drop.com/buy/68551)
• Dave Lee - I found the perfect keyboard (https://www.youtube.com/watch?v=ADEh9F0Lidc)
• Best ergonomic keyboard 2020 (https://www.t3.com/features/best-ergonomic-keyboard)
• Ultimate Hacking Keyboard (https://ultimatehackingkeyboard.com/)
• Unicomp Model M (https://www.amazon.com/Unicomp-Classic-Buckling-Spring-Keyboard/dp/B01MSNM6YG?ref_=fsclp_pl_dp_1)

Pra Aprender a digitar certo:

• Type Club (https://www.typingclub.com/)
• KeyBR (https://www.keybr.com/)
• Game: ZType (https://zty.pe/)

SCRIPT

Olá pessoal, Fabio Akita

No episódio anterior eu comecei explicando o que é essa história de teclados mecânicos e mostrei metade da minha coleção pessoal. Não precisa ter assistido a parte 1 pra entender o video de hoje mas seria bacana se visse depois pelo menos. Hoje eu vou terminar o assunto com os exemplos mais interessantes de teclados e na segunda metade vou usar de gancho pra ensinar algumas coisas básicas de programação que eu sei que até mesmo alguns programadores que se dizem com experiência desconhecem.

(…)

No episódio anterior eu falei mais de teclados de notebooks, modelos de marcas comerciais reconhecidas como Corsair, Cooler Master, Razer e Logitech. Daí mostrei dois exemplos de marcas mais de nicho como Matias e RealForce. Essa categoria tem marcas mais de nicho, normalmente voltada pra entusiastas mesmo. E de novo repito a recomendação que fiz no video anterior de visitar canais que falam sobre esse tipo de teclado em mais detalhes como o canal do Random FrankP ou Tae Keyboards.

Duas marcas que eu ainda não tenho são a Anne e Ducky, tanto o Anne Pro 2 ou o Ducky One 2 Mini tem recebido excelentes reviews mas eles não são baratos, na faixa dos 100 dólares que é parecido com a faixa da Corsair ou Cooler Master. Porém você necessariamente vai precisar importar, diferente de uma Corsair que você acha um pouco mais fácil no Brasil.

Na categoria abaixo de 100 dólares eu acho bem mais difícil achar teclados bem construídos, mas existem, e um excelente exemplo é a Keychron. Eu mencionei o modelo K1 low profile que compete com o Cooler Master SK630. Mas eu atual favorito em termos de custo-benefício é o modelo K2.

O K2 da Keychron que eu tenho é um 75%, mas o layout dele é muito melhor que o do Matias que eu mostrei no video anterior porque ele tem teclas individuais pra page up, page down, home e end numa linha vertical, além das teclas de setas que estão bem posicionadas. Além disso os keycaps são PBT doubleshot de excelente qualidade. O chassi também é todo de metal e tem zero problema de torção ou afundar no meio. A construção inteira é uma das mais sólidas e rígidas. A única pequena reclamação é que ele é um pouco mais alto que todos os outros que mostrei até agora, incluindo o Matias e o RealForce que já são um pouco mais altos que o normal.

Por isso se você comprar eu recomendo que adicione um palm rest pra apoiar os pulsos. Eu comprei o de madeira da própria Keychron mas qualquer outro serve. Os da Razer são bem confortáveis por exemplo. Vale lembrar que o jeito certo de digitar é sempre com as mãos flutuando um pouco acima do teclado. De preferência evitar que o pulso fique apoiado na mesa pra evitar dores.

De qualquer forma, o custo benefício desse teclado é excepcional. A versão mais básica e que tem até backlight branco custa 70 dólares e lógico, isso sem contar frete. Além disso é importado e todo eletrônico que vem de fora sempre vai estar sujeito a cair em tributação, e todos sabemos que a porcaria das taxas aqui vão de 60% até 100% de imposto, o que é uma estupidez.

A versão que eu tenho custou 90 dólares porque tem backlight RGB com o frame de aluminío, então não sei dizer se a versão que não é de alumínio é tão sólida quando esta, mas vamos ouvir um pouco pra vocês terem uma noção, e comparar com o Corsair de 100 dólares que é o mais próximo em preço.

(keychron comparado corsair)

Não sei se conseguem notar a diferença da qualidade de som de um e de outro. É subjetivo, mas eu realmente prefiro bem mais o som mais sólido e assertivo do Keychron do que o som mais barato do Corsair. Os switches são Gateron Red. A Gateron é uma que faz clones de Cherry. Em termos de especificação é praticamente um Cherry MX Red então é um switch linear. Diferente de switches proprietários como da Razer e Logitech significa que você pode encaixar keycaps compatíveis com Cherry nesse teclado, como aqueles da Corsair que eu mostrei mais no começo.

Outra coisa é que este Keychron é um dos únicos teclados wireless que eu tenho. Dizem que ele tem uma das maiores baterias de todos, de 4000 miliamperes, o que justifica ele ser tão mais alto que os outros. Eu mesmo não uso em modo wireless porque ele fica na minha mesa em casa e eu ligo num desktop então pra mim realmente tanto faz ser wireless. Mas pra quem carrega entre casa e escritório ou viaja bastante, esse é sem dúvida um dos mais portáteis sem comprometer usabilidade.

Falando em switches compatíveis com Cherry, outro exemplo é a empresa Kaihua que faz os switches Kailh e eu queria testar o Kailh Silver linear deles que é parecido com o Cherry Speed Silver, por isso algum tempo atrás eu comprei o Massdrop Ctrl depois que vi no canal do Dave Lee, vale conferir o video dele.

Em termos de estética este é sem dúvida o teclado que eu acho mais bonito. Vocês vão notar que o frame inteiro dele é de alumínio, com uma camada no meio de leds RGB. E como os switches ficam expostos o led reflete no alumínio. Aliás, a Massdrop é uma das poucas marcas que produzem teclados de alta qualidade e onde você consegue trocar os switches sem precisar desmontar nem soldar nada. Como eu disse, eu escolhi o meu com switches Kail Silver e, de fato, em termos de velocidade ele se compara com o Razer Yellow ou o Romer G linear que mostrei antes. Vale a pena ouvir um pouco ele comparado com o Blackwidow por exemplo.

(comparação ctrl - blackwidow yellow)

Como eu já expliquei o barulho total não vem só do switch, depende muito da qualidade do keycap, da construção do chassi, se o switch fica exposto ou não. É muito difícil determinar como vai ser o barulho final sem testar um do lado do outro mas esse é um dos menos barulhentos que eu tenho, menos ainda que o Keychron, mais próximo do Blackwidow.

Mas diferente do Blackwidow, apesar de teoricamente a força de acionamento ser os mesmos 45 gramas, não sei se os keycaps são mais densos, mas me dá impressão desse Drop Ctrl ser um pouquinho mais pesado pra acionar. Ou seja, apesar dos switches terem praticamente as mesmas especificações de força de acionamento e key travel, a diferença na construção muda bastante a sensação quando digita. Minha tese é a textura dos keycaps da Massdrop serem um pouco mais ásperas, o que dá sensação que “segura” mais o dedo na hora de digitar se comparado com os da Razer que são um pouco mais lisas.

Por outro lado, assim como os switches da Gateron, os da Kaihua também são clones de Cherry e por isso eu poderia trocar os keycaps por qualquer outro kit que seja compatível com Cherry, o que pode ser interessante se eu quiser mudar a aparência no futuro. Porém, é difícil recomendar este teclado porque o preço de saída dele é 200 dólares, sem contar frete nem imposto. É um dos teclados mais caros que eu tenho e muito disso é a escolha de materiais e engenharia que de fato são excelentes. É basicamente um bloco gigante de alumínio, tipo um macbook.

Se tem uma coisa que me incomodou é que ele não tem pernas atrás como os outros pra controlar a altura. Em vez disso ele veio com duas peças magnéticas que grudam atrás. Só que como é magnético não é difícil perder essas peças e adivinhem, eu perdi transportando e nunca mais achei. Na prática, você paga um premium por ser bonitão, mas por preço realmente não compensa porque por 50 dólares a menos que isso você compra um Blackwidow Chroma V2 que tem basicamente a mesma performance e solidez. 200 dólares é um valor compatível com os materiais desse teclado, o custo benefício não compensa a menos que você seja um entusiasta como eu.

Antes de continuar, vale e pena uma tangente pra falar sobre teclados ergonômicos e talvez um mínimo de ergonomia. Pra variar, valem os famosos disclaimers: eu não sou especialista em ergonomia mas falando de anos e anos digitando nos mais variados ambientes, o maior problema que eu sempre encontrei não foram tanto teclados e sim uma combinação de cadeira e mesa que permita que eu sente ereto, com os pés encostados no chão e que eu consiga ficar com os braços verticais pra baixo e os antebraços em 90 graus, sem forçar os ombros pra cima que é o que normalmente resulta em parte das dores no pescoço.

Eu tenho 1 e 72 de altura, meu peso médio é 76 a 77kg. Pra mim uma mesa comum de escritório que costuma ter 75 centimetros é alto demais. Pra ficar na posição correta eu sou obrigado a usar uma cadeira que levanta, mas aí meus pés não alcançam direito o chão, e depois de meses usando um apoio vou dizer que isso incomoda. Monitor eu coloco alguma coisa embaixo pra que eu consiga olhar reto pra frente sem inclinar a cabeça nem pra baixo demais nem pra cima demais.

Por isso aqui pra minha casa eu comprei esta mesa Genius Desk, que fabrica e entrega no Brasil aliás. Uma das funcionalidades é que eu posso trabalhar de pé também pra não ficar sentado o dia inteiro. Daí eu subo a mesa pra ficar com 1 metro de 4 centímetros e fica perfeito pra eu trabalhar de pé na postura certa das costas e dos braços. Só que ela é hiper cara e se o objetivo for só trabalhar de pé eu recomendo procurar por suportes articulados pra notebook que você facilmente encontra no mercado livre na faixa dos 200 reais.

Mas mais importante que isso é que essa mesa também ajusta até o mínimo de 66 centímetros que é a altura ideal pra eu sentar numa cadeira com os pés alcançando firmes no chão e manter minha postura correta como eu expliquei antes. A recomendação pra quem está sentindo problemas como tendinite, dor nas costas, nos ombros ou qualquer coisa assim não é trocar teclado, primeiro é ajustar altura da cadeira e mesa pra ficar na postura correta, depois procurar teclados especiais.

Com tudo isso ajustado o outro problema que causa dor é digitar errado. Se você for do tipo que a gente falava antigamente que cata milho pra digitar, ou seja, que não consegue digitar com todos os dedos das mãos, significa que seu braço precisa se movimentar muito mais por todo o teclado pra alcançar as teclas só com o dedo indicador e dedo médio. Antes de botar a culpa no teclado eu recomendo pegar aulas online e se exercitar digitando dúzias e dúzias de textos usando os dedos nas posições corretas. Eu mesmo não vou dizer que digito perfeitamente, o meu dedo mindinho e anelar da direita até hoje eu uso mal.

Outra coisa é que digitar em português é sempre mais devagar que digitar em inglês porque temos que ficar buscando acentos o tempo todo. Eu me acostumei a usar o formato americano US international. Eu detesto o formato ABNT2 não só por que tem a tecla de cedilha onde eu normalmente encontro o ponto e virgula mas porque diversas outras teclas mudam de lugar, em particular isso incomoda pra programar porque colchetes, sinais de maior e menor, backtick, barra invertida, tudo muda de lugar. Aqui meio que independente qual você vai escolher contanto que fique só com um layout.

Ficar mudando derruba a produtividade. Tudo que é importado vai ser formado americano, e se comprar fabricados no Brasil vai acabar sendo ABNT2. E falando em layout eu já disse no video anterior que tentar aprender Dvorak ou Colemak com objetivo de ser mais veloz eu acho que não compensa. E se o outro motivo for pra evitar dores, eu também acho que faz pouca ou nenhuma diferença. O que faz diferença é digitar errado e postura errada, independente do layout.

Se você já consertou tudo, mas digita muito rápido corretamente e tem tendinite, temos os teclados ergonômicos que talvez ajudem. Até onde eu sei não existe um consenso de qual é o melhor estilo mas em princípio você quer evitar mexer seu pulso o máximo possível. O problema é que todo teclado é totalmente horizontal, só que suas mãos não ficam naturalmente na horizontal. Você precisa girar os pulsos. Além disso você precisa trazer as duas mãos mais pra perto uma da outra, mas teoricamente o natural seria elas estarem mais separadas. Quanto maior você for mais isso é verdade.

Por isso a maioria dos teclados considerados ergonômicos primeiro não vão ser horizontais e sim inclinados de tal forma que você não precise girar os pulsos, mantendo o centro do teclado mais pro alto e as extremidades laterais pra baixo. Além disso eles vão dividir o teclado em duas partes e separar de tal forma que você não precisa aproximar tanto suas mãos. Tudo pra forçar menos tanto o pulso quanto todas as articulações do seu braço até os ombros. Muita gente ignora, mas sempre note se você está fazendo força com os ombros, isso causa dor.

Nessa categoria você encontra teclados como o Microsoft Sculpt ou similares da própria Microsoft como o Natural Ergonomic ou Surface Ergonomic, alguns mais genéricos como os da Logitech e algumas mais famosos hoje em dia como os da Kinesis, onde você tem tanto o monstruoso Advantage2 ou o Freestyle.

O principal problema que a maioria das pessoas vai ter com teclados desses eu diria que é até um ponto positivo, na real, porque você vai ser obrigado a aprender a digitar corretamente. Porque não tem como você digitar teclas que seria da mão esquerda com a a mão direita ou vice versa porque agora tem um espaço bem maior entre as duas metades.

Mas pra mim o problema era outro. Primeiro porque eu sempre achei teclados ergonômicos feios e com materiais de baixa qualidade. Isso felizmente mudou porque um Microsoft Sculpt é bem construído e até fico com vontade de experimentar. Segundo porque a maioria era full-size, ou seja, tinha teclado numérico e aí meu problema era dor no braço por usar o mouse tão afastado pra direita. De novo, o Sculpt é 75% então seria perfeito e apesar de ainda não ter experimentado eu recomendaria porque até o preço é razoável a 60 euros. Ele provavelmente não é mecânico, mas entre ter dor e usar um teclado rubber dome de boa qualidade, eu escolheria não ter dor.

Obviamente existem opções mecânicas como os da Kinesis. O Advantage2 usa switches Cherry Brown ou Red mas eu acho monstruoso demais, mas uma coisa que eu gosto dele é que tem boas opções de teclas extras perto dos dedões. Em vez de um espaço fixo no meio das duas metades do teclado, tem o Freestyle que você pode ajustar quanto espaço quer. O Freestyle normal é de membrana e rubber dome mas o Freestyle Pro tem opção também com switches Cherry Brown ou Red, mas eu nunca parei pra pedir. Mas pra variar, esses modelos são super caros com os Freestyle Pro na faixa dos 180 dólares e os Advantage2 na faixa dos 350 dólares. Os mais baratos de 100 dólares não são nem mecânicos.

Talvez um dia eu tente os modelos da Kinesis mas recentemente eu esbarrei em alguns vídeos mostrando um novo teclado, o Ultimate Hacking Keyboard. O conceito é muito bacana e eu recomendo ver os vídeos de review mais detalhado dele. Porém, assim como a Massdrop este daqui também é caro, mais caro ainda aliás, começando em nada menos que 275 dólares, sem contar frete e sem contar que no meu caso quando chegou aqui, a porcaria da receita federal me taxou em 100% do valor do produto. Bando de filho da p …

Aham, enfim. Agora que está aqui o que eu posso dizer é que assim como o Kinesis Freestyle, você tem o teclado fisicamente dividido em duas metades, o que facilita ajustar a distância no meio o quanto quiser, diferente dos da Microsoft por exemplo. Você também pode unir as duas metades se preferir e usar como se fosse um teclado normal. Quando faz isso o mecanismo de junção é um híbrido de encaixes físicos e ímãs que mantém as duas metades bem firmes no lugar, realmente é muito bem construído.

O chassi é de metal mas o frame ao redor é de plástico, mas é um plástico rígido de boa durabilidades, e não um molenga barato então não tem torção aparente e não afunda em nenhum lugar. Você pode parafusar os pés dele pra ficar em posição de tenda, levantando mais o meio, que é como todo ergonômico faz. Ou você pode escolher usar do jeito tradicional levantando mais a frente ou até fazer inclinação negativa colocando pra trás que eu não gosto muito.

Os keycaps foram minha maior decepção porque eles não chegam a parecer que são de ABS mas não parecem PBT também. Talvez um ABS melhor produzido. Não é doubleshot então as letras são todas impressas, o que significa que daqui algum tempo vai começar a sumir também. Por outro lado é um teclado com switches Kaihua, que são compatíveis com Cherry, o que significa que eu sempre posso trocar os keycaps por um kit de PBT doubleshot no futuro. Mas como o teclado já custa 275 dólares, eu esperaria keycaps melhorzinhos.

Mas o preço é caro assim por causa do circuito integrado e do software customizado. Esse teclado foi feito pra aceitar módulos que colocam controles extras ao alcance do seu dedão. Eu pedi os módulos de touchpad pro dedão direito e um grupo de teclas customizáveis extras pra ficar no dedão esquerdo. Se o touchpad funcionar resolve um dos meus problemas de ritmo que é ter que tirar a mão direita do teclado pra pegar no mouse. Com touchpad no dedão, não preciso tirar a mão do lugar, que é uma das coisas que sinto falta dos macbooks.

E o grupo de teclas pro dedão esquerdo vai ser importante porque esse teclado só tem layout de 60% que eu disse lá atrás que eu não gosto. Significa que qualquer tecla de navegação como page up, home e tudo é uma combinação de duas teclas. Imagina pra fazer coisas como shift + control + end pra marcar o texto até o fim da linha. Isso vira um malabarismo de apertar shift com o dedo anelar, control com o mindinho, mod com o dedão e “O” do outro lado. Eu até acho que com algumas semanas me forçando eu vou criar memória muscular, mas isso é bem inconveniente.

Pior ainda é que como não tem a linha de teclas de função em cima da linha de números, não existe a tecla Esc. Ela precisa ser uma combinação de duas teclas. Felizmente deu pra mapear a tecla que seria caps lock e que nesse teclado é um modificador pra controlar o mouse via teclado, mas mesmo assim minha memória muscular joga meu anelar esquerdo lá pra cima toda vez que quero Esc. Mas com o tal módulo pro dedão esquerdo eu conseguiria mapear coisas como esc, ou delete pra não ser uma combinação de teclas.

O problema é que esses módulos ainda não foram lançados. Eu comprei na pré-venda a 60 dólares cada módulo e eles só vão lançar em junho deste ano ainda. Me acompanhem no Instagram porque eu só vou mostrar esses módulos lá depois. De qualquer forma, o nome realmente resume bem o que é esse teclado, o Ultimate Hacking Keyboard. Falando nisso notem que a maioria dos teclados que eu falei até agora podem ser customizados e remapeados via software, mas tá fora do escopo deste video eu ficar falando disso, mesmo porque eu nunca remapeio teclas ou fico fazendo macros.

De novo, eu não sou gamer então não tenho tanta necessidade de customizar. E mesmo pra ambiente de programação eu prefiro não ficar criando macros porque eu uso teclados diferentes em cada lugar, então não vale a pena eu me acostumar com macros se vou usar 3 ou 4 teclados diferentes toda vez. Mas, sendo realista, este teclado é completamente fora de mão em termos de custo. Seriam 275 dólares só o teclado, mais 120 dólares por dois módulos, mais 75 dólares o palm rest de madeira que parafusa nas duas metades. Então o conjunto completo são nada mais, nada menos que 470 dólares sem contar frete nem imposto.

E falando em teclado caro, chegou a hora de eu mostrar o esteticamente mais diferente da minha coleção. Este é o QwerkyWriter S, e é querky com “K”, não confunda com o layout “qwerty”, obviamente que foi um trocadilho de propósito. Esse é outro que me custou nada menos que 300 dólares quando eu comprei em 2018. Não lembro se comprei em pré-venda ou algo assim porque fui ver na Amazon esses dias e esse mesmo modelo estava uns 500 dólares. Se for isso mesmo, esse é de longe meu teclado mecânico mais caro de todos e justamente por causa disso eu não recomendo pra ninguém que não seja entusiasta mesmo.

Esse foi o único que eu comprei exclusivamente pela aparência mesmo. Como podem ver o objetivo dele foi tentar se aproximar da aparência de uma máquina de escrever antiga. E sim, todos os apetrechos que você está vendo funcionam. A alavanca na esquerda realmente age como um return. Os botões de girar na esquerda e na direita que tentam parecer como se fosse pra puxar uma folha de papel se fosse uma máquina de escrever agem como botão de volume na direita e seta pra cima e seta pra baixo na esquerda, o que é bem legal porque é quase mesmo como puxar papel.

Ele é caro assim porque a construção e escolha de materiais é bem superior. Ele é um dos mais pesados, mais sólidos e mais rígidos, o que é absolutamente necessário pra passar mesmo a sensação de uma máquina de escrever. Ironicamente ele também é wireless com suporte a conectar até 3 dispositivos por bluetooth. E vem com um apoio atrás onde você pode colocar um tablet ou mesmo seu smartphone de pé. A intenção é que assim fica parecendo mesmo que você tá teclando num pedaço de papel, só que digital.

Aliás, uma dica se você conectar um teclado bluetooth num smartphone como iPad ou qualquer Android. Você vai ter dificuldade pra acentuar as coisas. Mas não precisa mudar o layout ou configurar nada. Por alguma razão o teclado em Android aceita combinações semelhantes ao do layout de teclados Mac. Por exemplo, pra acento agudo use alt e “e” e daí a sílaba. Pra acento com crase faça alt e “i” e daí a sílaba. Pra til é a mesma coisa só que com “n”, pra crase com backtick e pra cedilha é só alt e “c”. Alt em Mac é a tecla Option.

Esteticamente o que faz esse teclado evocar a aparência correta é porque assim como no Massdrop Ctrl ou Cooler Master SK630 que eu mostrei, os switches ficam expostos e, claro, os keycaps são mais altos. O que sai caro nesse teclado são justamente os keycaps que não são só plástico injetado. Cada um deles tem esse detalhe prateado ao redor. Em termos de acabamento e estética realmente se destaca de todos os outros na atenção a detalhes. Pra ficar mais próximo possivel de uma máquina de escrever, ele precisa ser barulhento, por isso vem com switches Cherry MX Blue. A própria batida da tecla no chassi complementa um som mais alto que o normal. Mesmo assim não é exatamente a mesma coisa.

Pra provar isso, temos que ver o verdadeiro teclado 100% mecânico. A boa e velha máquina de escrever. Pra mostrar aqui no canal eu resolvi comprar esta Olivetti Lettera 82, primeiro porque ela é bem menor do que a Olivetti que meu pai tinha ou as gigantonas britânicas Remington. Pense que isso aqui poderia ser como um jornalista iria em campo pra escrever matérias. Pensa como seria abrir um troço desses num Starbucks. Uma máquina dessas tem mecanismos que mapeiam cada tecla com um martelo num tambor na parte do meio. E a nitidez das letras vai ser proporcional à força que você marreta a tecla. Lembram que eu tava reclamando da diferença entre os 45 gramas de força de um Cherry Speed Silver contra os 78 gramas de um Thinkpad? Ha, essa aqui deve precisar pra lá de 100 gramas de força, fácil.

Mesmo se você nunca viu ou usou uma máquina dessas provavelmente entende o princípio de que tem um tambor com martelos de metal com letras em relevo no inverso, e quando você bate uma tecla ele movimenta um desses martelos batendo numa fita de tinta contra o papel. Daí por puro movimento mecânico a máquina mexe um espaço pra esquerda e assim você vai batendo uma letra atrás da outra.

Essas máquinas são a melhor coisa pra treinar digitar corretamente. Primeiro porque você literalmente vai fazer musculação nos mindinhos tentando marretar uma tecla pesada dessas, especialmente nas máquinas maiores. Segundo porque você realmente precisa fazer cada dedo bater no meio de cada tecla com precisão. Se escorregar e seu dedo bater duas teclas de uma só vez, os martelos podem enroscar e aí você tem que manualmente desenroscar, o que vai diminuir muito sua velocidade. Pior ainda se escorregar e seu dedo cair no meio das teclas. Embaixo são barrinhas de metal que vou te falar que dependendo de como você bater, pode machucar os dedos. Essa máquina é pra quem cresceu na época que mertiolate ardia.

Comparado com uma máquina de mesa essa pode ser considerada até leve, mas é no mínimo o peso de uns dois notebooks normais um em cima do outro. Eu não pesei mas me parece mais pesado que um saco de arroz de 5kg. As de mesa acho que era quase o dobro do peso. Ela é pesada demais pra carregar numa mochila mas leve demais a ponto de quando você tá datilografando e marretando teclas, ela fica escorregando na mesa se for muito lisa. Pra poder gravar eu tive que prender na mesa com fitas pra não ficar balançando pra tudo que é lado.

Eu não comprei junto mas antigamente a gente podia fazer múltiplas cópias ao mesmo tempo, bastava colocar papel carbono entre duas folhas e bater mais forte. Lembram o episódio do Diário de Henry Jones? Era assim que eu passava muitos dos meus dias:

(demonstração - lettera)

Achei interessante que tem vários modelos que você vai achar até que fácil em sites de usados como mercado livre, custando na faixa de uns 200 ou 300 reais. E tem até fitas novas sendo vendidas a meros 10 reais. Então, pra quem tiver curiosidade, tá super acessível. Obviamente os modelos mais raros vão ser mais caros, mas essa Lettera 82 hoje em dia tá fácil de achar.

Falando em carbono, quero aproveitar pra fazer uma tangente. Tem muita coisa do nosso dia a dia que os jovens, na faixa aí dos 20 anos ou menos não tem muita idéia e também nunca pararam pra questionar. Vou dar alguns exemplos: o mais óbvio é o famoso ícone em muitos programas pra opção de Salvar que ainda hoje é representado por um disquete. Eu usei muito disquete mas a nova geração nunca viu um ao vivo, e só sabe porque todo mundo já repetiu sobre isso em algum canal de YouTube. Outro exemplo que eu testei alguns meses atras foi sobre cartões de crédito. Alguma vez vocês já se questionaram porque cartões tem dados como o número, nome, data em relevo?

A maioria dos jovens primeiro nunca notou isso. Os que notaram acham que é puramente por estética. Porém a resposta é bem mais simples. Cartões de crédito são usados desde o meio do século XX. As maquinetas de cartão tipo as Cielo ou Stone que tem em toda loja hoje são invenções recentes que só começaram a se difundir no século XXI. E mesmo quando elas foram inventadas a internet móvel era super instável e em muitas regiões podia nem existir, então como fazia em lugares sem internet ou quando a internet caía? A gente tinha outra opção e eram máquinas manuais.

Nessas máquinas você colocava o cartão num espaço especial, daí colocava tipo um boleto com múltiplas folhas e carbono entre elas, daí puxava esse troço grandão que aplicava pressão contra o cartão. Daí o número, nome e data eram impressos no papel por causa da pressão da máquina contra o carbono e o cartão e voilá, tinha uma cópia pro lojista, outra pra administradora e um recibo pra você. Daí de tempos em tempos uma cópia era recolhida pela administradora que daí emitia fatura pra você e pagava o lojista. Basicamente processo parecido com o de hoje só que analógico. E quando começaram a surgir as maquinetas eletrônicas, elas podiam falhar ou ficar sem sinal ou mesmo a luz cair, e nesses casos os caixas tinham a contingência de usar essas máquinas manuais.

Voltando pra máquina de escrever. Elas são invenções bem antigas, acho que do fim do século XIX. No começo do século XX elas foram evoluindo. Resumindo bastante a história nós passamos por Graham Bell, por Thomas Edison, e criou-se a malha de comunicação e de eletricidade. Primeiro a gente tinha telégrafos, depois pulou pra telex. De forma simplificada podemos trafegar dados digitais encodados em ondas analógicas que podem viajar tanto pelo ar via rádio ou via cabo. Numa ponta ele precisa encodar a mensagem como um binário de zeros e uns, transformar isso em onda, transmitir e na outra ponta reverter da onda pra binário.

Muitos iniciantes tem dificuldade de entender isso. Mas pense na máquina de escrever. Cada tecla mapeia pra um martelo de metal no tambor. E se em vez disso ele mapear pra um código? Por exemplo, a letra “A” poderia ser 0 0 0 1 1, a letra “B” poderia ser 1 1 0 0 1 e assim por diante. E de fato era assim que as primeiras máquinas de telex funcionavam. Essa tabela de conversão era o baudot code inventado em 1870 e implementado em 1901. Telex significa Teleprinter Exchange e era usado uma máquina parecida com a de escrever mas em vez de ser só mecânica passou a ser eletromecânica pra fazer a conversão e modulação do sinal analógico.

Essa tabela de conversão Baudot era de 5 bits. E se você fez a conta de cabeça significa que é possível ter 2 elevado a 5 combinações diferentes, o que dá 32 combinações únicas. Como o alfabeto tem 26 letras e 10 números isso sem contar símbolos como de mais ou igual, significa que em 5 bits não cabe tudo. Pra isso você tinha dois códigos especiais pra mudar pra uma tabela de letras e outro código pra mudar pra uma tabela de números. Então o mesmo código pra letra “A” que eu falei também era do símbolo de “menos” se usasse antes o código de figuras. O da letra “B” era a figura de interrogação. No começo do século XX cada bit a mais era caro de processar porque eram processos mecânicos. O transistor só viria a ser inventado quase 50 anos depois.

Hoje em dia encodamos letras, números e símbolos usando convenções como UTF-8 onde a maiorias das letras e números em binário coincidem com a antiga tabela ASCII que era limitada em 127 combinações, porque é um esquema de 7-bits. Lembrando que você precisa se acostumar a pensar em binário e hexadecimal. Isso é matemática de primário, onde cada bit a mais que você adiciona duplica a quantidade possível de combinações. É uma exponencial de base 2. O ASCII antigo definia as primeiras 127 combinações. As próximas 128 combinações num esquema de 8-bits variavam bastante como no charset 1252 do Windows ou Mac Roman. De qualquer forma, strings e principalmente Unicode é um assunto bem cabeludo que fica pra outro dia. O importante era só lembrar que foi assim que tudo começou e que em computadores tudo é binário e como isso mapeia pra letras é uma convenção.

Falando em encoding de texto de Windows, vocês que são de Mac ou Linux devem ficar irritados toda vez que baixa um texto vindo de editores Windows antigos, porque o equivalente a uma nova linha que a gente em programação costuma simbolizar com “\n”, se vier de Windows, vai ter um caracter estranho aparecendo que é o símbolo “\r”. Mesmo em Git de Windows tem até a opção pra filtrar fora esse caracter inútil. Editores modernos como VS Code fazem certinho e não usam mais o \r.

Deixa eu mostrar pra vocês de onde vem o \n que significa New Line e o \r que significa Carriage Return. Vamos lá:

Isto é um New Line ou nova linha E isso é um Carriage Return ou retorno do carro, e carro é esse cilindro onde passa a folha de papel.

(carriage return maquina de escrever)

Lembram que eu falei que as máquinas de Telex eram basicamente máquinas de escrever mais sofisticadas? Elas recebiam comandos e automaticamente batiam os martelos numa folha e precisavam receber os dois comandos pra fazer a coisa certa. Se recebesse um TXT moderno que só tem \n, não haveria o retorno do carro pro começo da nova linha. Esse era o motivo.

Aliás, outra coisa antiga que você talvez tenham se dado conta agora é que talvez já tenham ouvido falar de bauds quando lidam com modens. Muita gente confunde bauds com bits e de fato antigamente 1 baud era um 1 bit. Então um modem de 1200 bauds transmitia 1200 bits por segundo. Porém baud é um termo de telecomunicações e eletrônica que significa um símbolo ou mais corretamente um pulso por segundo. Num pulso você pode empacotar muitos bits, então um model de 1200 bauds com pacotes mais compactos de 8 bits por pulso na verdade transmitiam 9600 bits por segundo. E de onde vem Baud? Vem de Émile Baudot que criou a tabela de 5-bits usado nos telex que eu falei agora pouco.

Pra terminar a tangente, tem outra coisa que você provavelmente também já viu e não tem idéia do que é. Mas pense assim, depois da era do Telex começou a era da computação, principalmente depois dos anos 50 quando o transistor começou a popularizar. No fim dos anos 60 apareceram os primeiros UNIX. Mas os computadores de antigamente eram gigantes que nem um armário. Não era que nem um desktop que você coloca embaixo da mesa. Mais do que isso, eles eram recursos compartilhados porque não dava pra ter um computador gigante por pessoa. Por isso nasceu o conceito de rodar jobs assíncronos em paralelo de várias pessoas e depois timesharing pra ser possível ter múltiplas pessoas usando o computador ao mesmo tempo com o processador dividindo o tempo entre diferentes processos. Eu explico um pouco disso no meu video do ano passado que está na Playlist de Programação para Iniciantes, na de concorrência e paralelismo.

Então, por necessidade, precisava dar um jeito de compartilhar o mesmo computador, mesmo remotamente. Por isso existiam os terminais remotos. E os primeiros terminais sequer precisavam ter monitores, pense que eles eram máquinas de Telex conectadas no computador e as respostas eram impressas em papel. A vantagem disso era que você podia ter esse teleprinter do lado do computador ou remotamente. Então o que chamamos hoje de STDIN ou Standard Input era uma máquina tipo essa minha de escrever mas adaptada pra ser uma teleimpressora como na era do Telex. E o STDOUT ou Standard Output poderia ser um monitor de fósforo verde ou âmbar de antigamente ou mesmo a impressora em papel.

Quando a saída eram monitores remotos eles eram chamados de Video Terminals ou VTs. Com o tempo, além das letras e números mapeados na tabela ASCII que eu falei, começaram a criar comandos de escape especiais pra mover o cursor em posição X e Y na tela bem como mudar cores e coisas do tipo, e um conjunto ficou mais conhecido e é usado até hoje, o conjunto VT-100, que são combinações de caracteres que escapam de serem impressos, normalmente começando com o código binário pra Esc, abre colchete e algum código. Um dos grandes problemas do console de linha de comando antigo do Windows, o conhost é que ele sequer suportava esses escape codes então imprimia tudo errado. Isso foi corrigido com o novo Windows Terminal que tá quase saindo de versão Preview e você pode ver mais sobre isso no episódio que eu fiz sobre o WSL 2.

Mas, voltando onde quero chegar. Esses teleprinters são o que chamamos de dispositivos de entrada, input devices. E foi no UNIX que se criou o conceito de lidar com tudo, incluindo devices, como se fossem arquivos. Por isso existem os arquivos /dev/tty que vai de tty0 até tty63, ou seja, num Linux moderno daria pra ligar até 64 dispositivos. Toda vez que você abre o programa de Terminal, como o que vem nas distros ou outros como um Tylix da vida ele se registra como um dispositivo de entrada virtual, um pseudo-TTY ou PTY.

Vamos fazer um teste abrindo aqui meu bom e velho Manjaro de guerra. Se eu abrir um Terminal e digitar o comando tty ele vai devolver em qual estou conectado. Note que não é um /dev/tty1 ou algo assim e sim /dev/pts/0. PTS são Pseudo Terminal Slaves, associados a um PTY, que serve pra conectar terminais falsos ou emuladores de terminal como é o caso de um programa como xterm ou Tylix que não é um teleprinter de verdade e nem mesmo um hardware moderno como teclado ou mouse. Se eu abrir outra janela ou mesmo dividir essa janela em duas, a segunda vai se conectar em outro pts diferente. Eu posso fazer um script besta na primeira janela pra esperar alguma coisa, por exemplo um programinha de uma linha de Ruby com o comando gets, que vai ficar esperando alguma coisa vir pelo STDIN, por exemplo pelo teclado.

Agora, do segundo terminal eu posso dar o comando echo de qualquer string direto pro /dev/pts/0 e ele vai direto pro script Ruby. Mas agora, quem se liga nos TTY de verdade do sistema além de teclado e mouse? Podemos dar um comando ps aux pra listar todos os processos rodando e dar um grep por tty e de fato vemos que o X.org e o GDM que é o gerenciador de janelas gráficas do GNOME é que estão pendurados lá. Note que eles estão no TTY2. Se eu der Ctrl + Alt + F3 eu vou pular pro TTY3, de onde eu posso dar login normalmente. E se der de novo ps com grep em tty pra filtrar, vemos que no tty3 está o Zshell que é onde estou neste momento. E se eu der Ctrl + Alt + F2 eu posso voltar pra sessão gráfica do X.

Em muitos casos, se por acaso seu X travar por alguma razão, pode ser possível destravar sem precisar bootar a máquina. Tente fazer primeiro Ctrl + Alt + backspace que é um hard restart do X. Se isso não funcionar, você pode tentar ir pra outros TTY e de lá dar um kill forçado no X por exemplo.

E agora vem o interessante, eu ainda não falei o que significa TTY. Máquina de escrever em inglês é typewriter. Um typewriter adaptado pra Telex é um TeleTypeWriter e daí vem TTY. Agora você sabe. Este assunto de TTY é muito importante que todo programador que usa Linux ou derivados de UNIX tem obrigação de saber. Por isso vou deixar linkado nas descrições abaixo um artigo que eu achei faz tempo e que é bem completo chamado TTY Demystified.

Voltando pro assunto de teclados, já que falei do avô dos teclados, podemos finalizar pulando algumas décadas e cair nos anos 80 pra falar do último da minha coleção. Diferente de máquinas de escrever que você encontra até que barato, este teclado é caro. Eu paguei uns 1400 reais no mercado livre num anúncio que estava lá pegando poeira fazia alguns anos. Aliás, quando eu abri a caixa veio pó com cheiro dos anos 90 nele, sério.

É este IBM Model M, uma das primeiras versões. Este em particular é da série que chegou a ser montado na Zona Franca de Manaus. E não é como os porcaria que vinha nos IBM Aptiva de 1994 em diante. Este Model M é de dez anos antes, 1985. Se quiserem entender a história dos Model M, por acaso, tem um video curto e bem feito do canal Linus Tech Tips que explica as diferentes versões, então vou deixar o link nas descrições abaixo também.

Os model M são tanques de guerra. Este em particular, é um que provavelmente se ligava num Terminal remoto, num VT. Isso porque ele é a versão que ainda não tem as luzes de caps lock ou num lock na direita. E fora isso o conector dele é anterior à existência do padrão PS2. O cabo é serial com conector RJ-45 que é o mesmo que se usa em cabow de rede Ethernet. Ou seja, eu preciso de um adaptador especial que não é o mesmo adaptador de redes pra USB que se encontra por aí, o circuito é totalmente diferente. Por isso eu encomendei um que achei no eBay mas ele não chegou até o dia de gravação desse video então eu não pude testar de verdade esse teclado. Mas vamos ver como ele se parece digitando.

(digitando model M)

Como deu pra ouvir, o barulho é alto, irritante e extremamente satisfatório. Esse barulho faz o click dos Cherry MX Blue parecer brincadeira de criança. Se a máquina de escrever que mostrei é o avô dos teclados mecânicos, este Model M é o paizão de todos. Porém, diferente dos mecanismos modernos, este tem switches que chamamos de Buckling Springs. Na prática, dentro tem uma mola que quando você vai pressionando ele vai se deformando até acumular força pra empurrar a peça da base e pressionar um rubber dome em cima de uma membrana, registrando a tecla. Ou seja, este é provavelmente um dos melhores teclados de membrana ou rubber dome, com a diferença que não é a resistência do domo de borracha que segura a tecla e sim a mola entre a tecla e o domo. Por isso a sensação é bem diferente e única.

Assim como o Cherry Blue, ele tem um click bem nítido de quando a mola quebra a tensão, soltando o barulho de click. Além disso os keycaps neste modelo são diferentes. Eles são, entre aspas, double mas não é double shot, são literalmente duas cascas de tecla uma em cima da outra mas não grudados. Parece que a tecla que se conecta no switch é tudo do mesmo tamanho, daí em cima dela tem outra que tem os formatos diferentes de cada tecla. Então são teclas mais pesadas do que você tá acostumado. Some a isso este frame e chassi que é grande, denso, robusto e bem rígido. Esse teclado é um tanque de tão pesado. Eu poderia chutar que é metade do peso da máquina de escrever. Por isso você pode bater com a força que quiser que esse monstro aqui não se mexe.

Não dá pra usar a medida de força de acionamento oficial porque estamos falando de um mecanismo com molas que são mais velhas que a maioria de vocês assistindo, provavelmente com 30 anos ou mais de idade. As patentes originais foram sendo passadas pra frente e hoje estão com a empresa Unicomp que faz Model M novos usando os mesmos mecanismos mas com peças novas e você pode encomendar na Amazon americana por uns 95 dólares, o que eu diria que vale a pena. Eu só não gosto porque eles só fazem tamanhos full-size, com o teclado numérico que eu não preciso.

Mas a sensação de digitar é bem diferente do que todos os outros teclados. Eu diria que ele precisa de pouca coisa mais de força do que os Cherry MX Blue. Mas é um pouco menos do que os switches Topre da RealForce. O Topre vocês vão lembrar que eu disse que sinto que tem uma resistência maior logo no começo da tecla, este tem uma resistência um pouco maior mais pro fim, no ponto em que a mola faz o clicky e é amortecido pelo domo de borracha da membrana. Não dá pra dizer se ele é melhor, mas certamente a sensação é bem diferente. Eu pessoalmente gosto bastante desse switch e queria ver modelos modernos. Talvez eu encomende um Unicomp. O problema é que ele é um dos mais barulhentos então eu definitivamente não recomendo usar num escritório com outras pessoas.

Com este Model M eu senti que tenho uma coleção com as principais variações de switches e qualidades de construção. Assim que chegar o adaptador pra esse conector RJ-45 eu falo mais sobre ele no Instagram, então não deixem de me seguir lá, que aliás é onde vou mostrar qualquer outro novo teclado que comprar. Mas depois de tudo isso, qual o teclado que eu gosto mais? Isso varia muito, depende do dia e do meu humor mesmo. Tirando o baratinho que mostrei no começo do video anterior de propósito, todos os outros são bons e eu gosto e não pretendo me desfazer de nenhum. Na prática, não precisa comprar nenhum de 200 dólares ou mais porque não vão ser tão diferentes dos de 100 dólares. Vai variar mais em funcionalidades, tamanho, portabilidade, extensões e outras coisas, mas pra digitação em si muda muito pouco.

Por isso eu falei no começo deste video que o melhor custo-benefício são os da Keychron. Começando abaixo de 100 dólares, é difícil competir. No Brasil talvez seja mais fácil achar os Corsair ou Razer, então ficaria de olho neles também. Ambos até tinham quiosques de demonstração em alguns shopping centers. Se você for entusiasta e tiver dinheiro pra gastar existe um ecossistema enorme onde você pode comprar todas as peças separadamente e você mesmo programar seu firmware, soldar sua própria placa com os switches que quiser e muito mais. Só de keycaps você vai encontrar dezenas de qualidades, cores e estilos bem diferentes. E sim, vai ter que importar, basicamente inexiste um mercado de peças de boa qualidade fabricadas no Brasil pra entusiastas.

No final, não, você não precisa e nem deve procurar teclados caros achando que isso vai afetar sua produtividade de alguma forma, porque não vai. Da mesma forma que não adianta sair comprando Nikes de corrida se você não consegue correr nem um quilômetro sem morrer. O equipamento só ajuda quem já é treinado. Sim, teclados baratinhos daquela faixa dos 100 reais pode atrapalhar, porque seus dedos vão escorregar em teclas de baixa qualidade, o amortecimento de domos de borracha porcaria vai dar falsos registros de tecla ou nem registrar, as membranas podem ter mal contato e te levar a erros mais frequentes e tudo mais. Mas na faixa dos 70 dólares pra cima é mais difícil de errar. Acho que com os teclados que mostrei deu pra dar uma noção de porque alguns cobram mais caro que outros. E é muito mais pelo luxo do que pela produtividade.

Inclusive, outra pergunta que muita gente deve ter na cabeça é por quê eu tenho esta coleção. E a resposta é muito simples, pelo mesmo motivo que qualquer pessoa faz uma coleção: porque eu quero. Tem gente que coleciona quadros, tem gente que coleciona miniaturas, tem gente que coleciona tampinhas de garrafa ou sei lá, eu gosto teclados e ponto. É mais barato que colecionar carros e tem a diferença que teclado é de longe o equipamento que eu mais uso todos os dias. Eu passei os anos 90 e os anos 2000, quase 20 anos usando teclados de membrana com plástico barato porque era o que dava pra comprar. Hoje eu posso comprar um bom mecânico. Dependendo do seu estilo de vida, um bom teclado desses sai mais barato que muito show ou balada por aí.

Cada seção onde eu falo de cada teclado deste episódio e do anterior eu escrevi usando o teclado certo, então estes episódios foram escritos com todos os 16 teclados, com exceção da Olivetti Lettera e do IBM Model M que ainda não dá pra ligar. Mas o que eu mais usei no geral foi mesmo meu Keychron K2. E com isso encerro o assunto de teclados mecânicos, aproveitem pra ajudar o povo com dúvidas nos comentários, se curtiram o video mandem um joinha, assinem o canal e cliquem no sininho pra não perder os próximos episódios. E não deixem de compartilhar o video pra ajudar o canal. A gente se vê, até mais.

DESCRICÃO

Finalmente consegui compilar a primeira metade do vídeo sobre minha coleção de teclados mecânicos. Neste episódio você vai entender as principais características de teclados mecânicos, algumas das principais marcas e modelos e, claro, as combinações que mais me agradam.

Também vamos comparar com alguns notebooks e o que diferencia os mecânicos dos “normais” e pra isso também vou contar sobre a controvérsia dos switches butterfly da Apple.

Como o video é longo, segue um bookmark das principais seções do video pra ficar mais fácil voltar depois:

02:06 - velocidade de digitação e um resumo inicial 05:54 - switches butterfly da Apple 08:33 - Surface Book 2 e Thinkpad Extreme 12:27 - o mau exemplo: Bright 16:26 - Das Keyboard 1 20:07 - Corsair K65 Vengeance 24:34 - Cooler Master SK630 29:38 - Razer Blackwidow Chroma V2 33:12 - Logitech G PRO 36:04 - Matias Mini Quiet Pro 37:53 - Tamanhos de Teclados 42:09 - RealForce 87U

Links:

• Click, Clack (https://tedium.co/2018/07/19/cherry-mx-keyboard-history/)
• Cherry MX Switch Comparison - KeyMouse (https://www.youtube.com/watch?v=zlSPH3HvxhQ)
• An introduction to Kailh switches, including Speed & Box (https://www.keyboardco.com/blog/index.php/2017/11/an-introduction-to-kailh-switches-including-speed-box/)
• MK’s official mechanical keyswitch guide (https://mechanicalkeyboards.com/switches/)
• THE BEST MECHANICAL KEYBOARD KEYCAPS (https://blog.wooting.nl/what-are-the-best-mechanical-keyboard-keycaps/)
• ABS vs. PBT Keycaps (https://gearbroz.com/abs-vs-pbt/)
• Full-size, TKL, 60% and more: a guide to mechanical keyboard sizes (https://www.keyboardco.com/blog/index.php/2017/08/full-size-tkl-60-and-more-a-guide-to-mechanical-keyboard-sizes/)
• Why Are Apple’s Butterfly Keyboards So Bad? (https://www.maketecheasier.com/why-apples-butterfly-keyboards-so-bad/)
• Razer Blackwidow Chroma V2 (https://www.razer.com/gb-en/gaming-keyboards-keypads/razer-blackwidow-chroma-v2)
• Matias Mini Quiet Pro (https://matias.ca/miniquietpro/pc/)
• REALFORCE TKL SA / R2TLSA-US4-IV (https://www.realforce.co.jp/products/R2TLSA-US4-IV/index.html)
• Realforce 87U Tenkeyless 55g (Black) (https://www.amazon.com/gp/product/B00MV84Y2Y/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1)

SCRIPT

Olá pessoal, Fabio Akita

Finalmente resolvi falar um pouco sobre minha coleção de teclados mecânicos. Depois de mais de um mês em quarentena sem ver uma pessoa já já vou estar conversando com meus teclados isso sim. No total são uns 16 teclados mas vou cobrir metade hoje e dividir alguns itens especiais pra falar só no próximo episódio. E pra ficar fácil encontrar qual, também vou deixar um bookmark com o tempo de cada um nas descrições abaixo. Parece que o interesse por teclados mecânicos cresceu bastante recentemente. Eu venho colecionando bons teclados faz uns 5 anos já. Então vamos lá que tem bastante coisa só pra hoje.

(…)

Antes de mais nada, eu não pretendo explicar tudo que existe sobre cada teclado. Vou focar só no que é importante pra mim. Existem canais inteiros dedicados só pra falar de teclados, incluindo DIY pra quem quer construir um teclado customizado. Três exemplos de canais que eu assisto são o Random FrankP, o Hardware Canucks e o Tae Keyboards. Em cada video eles vão em muitos detalhes sobre cada teclado, os keycaps, switches, testes de som, desmontagem pra ver o chassi, chipset e muito mais. Se você tem curiosidade sobre um teclado em particular, veja se eles já não falaram a respeito.

Vamos tirar algumas coisas do caminho primeiro. Muita gente ainda pensa que teclados mecânicos é só coisa pra gamers. E isso não está totalmente errado. Muitas das melhores tecnologias de teclado de fato estão nos modelos pra gamers profissionais, em marcas como Razer. Mas não se engane, só porque tem RGB não quer dizer que é pra gamer. Aliás, tem muito xing ling por aí que enfia LED em teclado porcaria achando que vai atrair gamers. Só se forem os amadores mesmo. De qualquer forma, muitas das tecnologias de verdade pra gamers como switches confiáveis e rápidos, anti-ghosting, baixo input lag e tudo mais já existem em teclados sóbrios que não são só pra gamers e sim pra touch typists, ou seja, povo que sabe digitar rápido com todos os dedos.

Falando em velocidade, existem diversos sites e ferramentas disponíveis pra quem quiser treinar digitar corretamente. Muita gente acaba usando o 10fastfingers, e como passatempo é divertido. Mas a configuração padrão dele é extremamente fácil, com palavras simples de 3 ou 4 letras. Então não é difícil eu ficar entre 95 a 105 palavras por minuto, algo em torno de 400 toques por minuto. Mas isso é velocidade de competição, onde eu preciso estar focado em copiar muito rápido sem pensar se o que estou digitando faz qualquer sentido. Ninguém consegue manter esse ritmo num trabalho de programação ou dissertação durante horas sem parar. Isso é velocidade de pico e não média. A média de trabalho seria muito abaixo, mais pra 40 palavras por minuto ou menos, porque o certo é você parar pra pensar no que tá escrevendo. Tirando trabalho de digitador mesmo, ninguém fica apostando corrida.

Mas claro, se num site como 10fastfingers você está abaixo das 70 palavras por minuto eu realmente recomendo que treine muito mais. Apesar de gostar de me considerar um touch typist mesmo eu estou ciente que tenho defeitos em alguns dedos, em particular meu dedo anelar da mão direita eu uso muito mal. Os verdadeiros touch typists vão acima de 150 palavras por minuto. Já em código só dá pra ir rápido assim se você estiver digitando algo que já repetiu dezenas de vezes antes, e nesse caso eu tomaria cuidado: porque você tá repetindo tantas vezes o mesmo código em tantos lugares e ainda não extraiu em uma biblioteca ou algo assim?

Na prática, se eu realmente me concentrar, em silêncio, com palavras simples, fico na faixa das 90 e poucas palavras. A maioria dos teclados que eu vou mostrar consegue me manter na faixa entre 80 e 90 sem atrapalhar. E aqui já vou resumir: o teclado faz um pouco de diferença se e somente se, você já for um digitador rápido. Se você tiver estatura média e mãos pequenas como as minhas, prefira switches lineares, especialmente os semelhantes aos Cherry MX Speed Silver que eu vou explicar mais na frente. Eles exigem na faixa de 45 gramas de força. Agora, se você for maior, com mãos grandes tipo jogador de basquete, aí talvez faça mais sentido switches com mais resistência como os Cherry MX Blue ou Black que exigem uns 60 gramas de força. Teclados de notebook são mais rasos mas também são mais pesados, exigindo uns 70 gramas de força. Em notebooks eu tendo a ir mais devagar e fico abaixo das 80 palavras por minuto, por exemplo.

Uma pergunta que muita gente vai fazer é se deveria treinar layouts diferentes do tradicional qwerty como Dvorak ou Colemak. Eu não vou entrar nesse assunto nestes videos mas meus dois centavos é que vale a pena experimentar se você tem tempo ou interesse nessas coisas. Mas pra maioria da população não, é perda de tempo. Não vai drasticamente aumentar sua velocidade e nem diminuir dores magicamente. Melhorar sua postura vai fazer muito mais diferença. Não quer dizer que sejam ruins, só que não tem nenhum milagre neles. E isso vai limitar suas opções também porque só vai poder usar alguns tipos de teclados e toda vez que for usar maquina de outra pessoa vai ter que incomodar instalando layouts diferentes. É muito pouco prático por isso não me interessa.

Outra pergunta que já sei que todo mundo vai fazer é sobre custos, eu realmente não tenho muitos teclados baratos. E cuidado com os baratos demais, que como eu vou mostrar já já, é comprar gato por lebre. Os parâmetros que eu diria é procurar marcas que ofereçam switches Cherry, Gateron ou Kaihua que são mais fáceis de encontrar, de preferência o tipo linear como Cherry Red ou Speed Silver. Também prefira os que ofereçam keycaps PBT doubleshot. E fique com tamanhos que vão do TKL até no máximo 65% se não quiser sofrer muito. Vou explicar tudo isso em mais detalhes neste video, mas esses são os parâmetros. O meu recomendado de custo benefício mesmo vai ficar pra Parte 2, então aguardem pra ver.

Como eu estava dizendo, teclados mecânicos viraram moda ultimamente, o assunto virou notícia nos últimos anos não só por causa do aumento da comunidade de gamers profissionais, mas também por causa do fracasso homérico da Apple com os famigerados switches butterfly que sempre quebram e foram alvo de muita crítica até finalmente eles resolverem voltar pros antigos switches scissor que era o padrão até 2015.

Pra quem não acompanhou, por muitos anos os notebooks e magic keyboards da Apple usavam o design de switches que ficou conhecido como scissors porque as peças são conectadas no meio e sobem e descem parecendo uma pequena tesoura, conseguindo manter uma tecla fina e estável por cima. Era um design simples, feito com peças comoditizadas, testadas ao longo de anos e muito confiáveis. Raramente você ouvia falar de alguém reclamando disso.

Mas por volta do fim de 2015 a 2016 a Apple resolveu mudar esse design pro que ficou conhecido com switches butterfly ou borboleta porque as peças se movem parecendo as asas de uma borboleta. O objetivo era diminuir o que chamamos de key travel que é a distância entre a tecla em seu estado de repouso até ele encostar no final. O que chamamos de actuation ou acionamento do circuito da tecla em si costuma acontecer no meio do caminho antes de bater no final. Em notebooks é um espaço bem pequeno, na casa de 1 milímetro.

Teoricamente, com key travel menor você consegue trabalhar o frame, ou o casco do notebook pra ficar mais fino, coisa que sempre foi uma prioridade no design industrial da Apple. Porém, esse design tem pelo menos dois grandes problemas: diferente dos switches scissors, os butterfly usam peças mais frágeis e por causa do key travel super curto, o espaço embaixo da tecla quando sobe funciona como uma pequena sucção, atraindo sujeira pra baixo dela. Qualquer grão de poeira no lugar errado é suficiente pra travar a tecla. E isso foi tão comum que todo novo modelo de macbook lançado já vinha com reportagens das teclas estarem travando.

Umas 2 ou 3 revisões diferentes foram feitas, inclusive adicionando uma membrana fina de silicone ou algo assim ao redor do switch, mas mesmo assim as teclas continuavam com alto grau de defeitos. Depois de uns 4 anos tentando e toda vez fracassando, finalmente no fim do ano passado eles decidiram reverter pros switches scissor originais e até agora não vimos mais relatos desastrosos como os de antes. Mas apesar das más notícias no mundo Apple nesses últimos anos, também precisamos reconhecer que foi por causa dela que desde o ano 2000 as demais marcas tiveram que evoluir e oferecer teclados melhores.

Hoje em dia, dentre as principais marcas de notebooks, meus dois preferidos são os da linha Surface da Microsoft, em particular o teclado do Surface Book 2 que eu uso faz uns 3 anos e o lendário teclado dos Thinkpad, como desse Thinkpad Extreme que eu tenho faz quase um ano. O que mais varia em notebooks é o layout das teclas, em particular as da direita que tem as setas e navegação como page up ou home. Em termos das teclas em si, nenhum é excepcionalmente bom porque o próprio tamanho dos notebooks não permite teclas muito maiores. Em notebooks baratos demais o teclado é o menor dos problemas, mas dentre aqueles que começam na faixa dos mil dólares é mais questão de gosto mesmo.

Vamos ver como é o teclado do Surface Book 2 por alguns segundos pra vocês verem. São os que mais se assemelham aos da Apple na minha opinião.

(teclado Surface Book 2 - demonstração)

Agora vamos ver como é o do Thinkpad. Ele tem o lendário mamilo vermelho mas eu realmente nunca precisei dele em nenhum modelo que já testei. Considero bem inútil porque os touchpads hoje são bons o suficiente. Aliás, em termos de touchpad nada supera os da Apple, mas os notebooks premium tem touchpads competentes já. Mas vamos voltar pro Thinkpad.

(teclado Thinkpad - demonstração)

O que eu gosto dos dois primeiro é o chassi. Um dos grandes problemas de notebooks baratos é que eles usam chassis de plástico pouco resistentes e quando você aplica só um pouco de pressão no meio eles flexionam. Eles não são rígidos. Eu vou mostrar isso já já com outro teclado. No caso do Surface Book, ele tem mais key travel que os macbooks com switches butterfly e mesmo assim já estão no que eu considero o limite, de 1.2 milímetro de key travel e são um pouco mais resistentes que a maioria, requerendo uns 70 gramas de actuation force. Ou seja, você precisa aplicar 70 gramas de força pra tecla descer 1.2 milímetros e fechar o contato do circuito pra registrar a tecla.

No caso do Thinkpad Extreme, ele tem um key travel maior de generosos 1.7 milímetro. Meio milímetro pode não parecer muito mas faz bastante diferença pra um notebook de menos de 2 centímetros de espessura. Porém eu acho as teclas um pouco mais cansativas pra digitações longas porque precisa de 78 gramas de actuation force. Por isso eu disse antes que minha velocidade de pico fica na casa das 80 palavras por minuto e é bem mais difícil pra mim alcançar os 100.

No caso dos famigerados switches butterfly da Apple, eles eram tão rasos que estamos falando de um key travel de 0.7 milímetro, ou seja, menos de um milímetro. E pelas specs oficiais ele precisa de 70 centiNewtons de força ou aproximadamente 71 gramas de força. Portanto em termos de força é parecido com o Surface mas como o key travel é 1 milímetro menor, eu sempre senti como se estivesse batendo meus dedos na mesa. É muito cansativo pra longas sessões de digitação.

Vale lembrar que praticamente todos os principais notebooks usam switches scissor, não só a Apple como os modelos que eu mostrei acima. As patentes são dos anos 80 e eu não sei se os fabricantes precisam pagar royalties hoje em dia, e se sim isso também explica porque a Apple tentou um design diferente pra fugir de ter que pagar licença. Mas pelo visto switches scissor estão na ativa dos anos 80 até hoje porque passaram pelo teste de confiabilidade do tempo. Outra coisa que muitos não sabem é que esse switch usa um rubber dome ou domo de borracha no meio, que é o que dá a resistência do switch e que levanta a tecla pra posição original depois, ou seja, não é um mecanismo mecânico com molas. É a própria resistência do domo de borracha que levanta a tecla de volta.

Eu cito isso porque muita gente acredita que as diferenças em switches de teclado são basicamente os que tem rubber dome e os que não tem. Mas é um pouco mais complicado que isso como eu vou mostrar mais pra frente. Vamos pular de notebooks pra desktops e começar com um tecladinho bem vagabundo, hiper barato da faixa de 50 reais que eu comprei anos atrás só pra ligar temporariamente num raspberry pi que eu tava testando na época que eu só usava Macs e não usava teclados externos. Essa belezinha aqui de marca genérica chamada Bright.

(intro Bright)

É muito mais fácil falar de teclados bons começando por um bem fuleira que mostra tudo que tem de errado nos teclados baratos demais. Pra começar, o chassi inteiro e o frame são totalmente de plástico e dos mais vagabundos, olha como eu consigo torcer ele inteiro e como se eu aplicar só um pouco de força no meio ele afunda inteiro. Agora olhem também como ele tem zero estabilização nas teclas maiores como a barra de espaço. Quando se digita, você tem a sensação de estar afundando o dedo num pedaço de borracha escolar, e é praticamente isso que tem embaixo das teclas. É tudo meio molenga e ele faz você errar bastante enquanto digita. Mesmo assim eu resolvi fazer o teste de velocidade nele, mas foi super irritante.

(digitacao bright)

As teclas em si são provavelmente de ABS ou pior, PVC. Parece aqueles kits de brinquedo de plástico que tem tudo grudado numa grade e você vai recortando as peças e fica aquelas pontas de plástico. Tudo é meio folgado, todas as teclas balançam um pouco. Além disso veja meio inclinado que as letras e símbolos parecem algum tipo de adesivo, e teclas baratas assim normalmente tem as letras impressas por cima mesmo, que com o tempo apagam.

Lembram que eu falei que no caso do switch butterfly da Apple tinha key travel de menos de um milímetro e parecia que eu tava batendo os dedos numa mesa dura? Isso porque o chassi da Apple é de alta qualidade, rígido e de alumínio. No caso dos baratos de plástico que nem esse aqui, parece que eu tô escorregando os dedos por cima de plástico liso em cima algo molenga. Não tem firmeza nenhuma. Às vezes parece que você teclou e a tecla não registrou, ou você escorrega pro lado. A grande maioria dos teclados da faixa abaixo de 100 reais vai ser alguma coisa lastimável assim. Pra achar um razoável nessa faixa tem que pesquisar bastante, eu mesmo não conheço nenhum.

No mundo desktop, o normal nas últimas décadas são os teclados de membrana porque são os mais baratos de fabricar. Basicamente imagine uma placa grande embaixo, com uma matriz onde os cruzamentos seriam as teclas. Nesses cruzamentos tem traços, que estão abertos, ou seja, não fecham o circuito. Em cima dessa placa coloca-se uma manta de silicone ou borracha, que é a tal membrana. Essa membrana é impressa com o layout de onde fica cada tecla e nessas posições tem os rubber dome, ou domo de borracha, com um material condutor que quando você pressiona o domo pra baixo, ele encosta na placa e fecha o circuito daquela tecla. Finalmente, você fecha o teclado com uma frame ou corpo de plástico e encaixa as teclas nos buracos. Pronto, esse é o tipo de teclado mais barato e mais difundido.

Esse tipo de teclado é super porcaria. O que mantém as teclas pra cima é a resistência desse material borrachudo. Claro, a qualidade dos materiais vai variar de fabricante pra fabricante. No caso dos notebooks, a maioria não usa mais membranas, daí os domos de borracha são individuais em cada tecla, mas o conceito é parecido. Mas você vê que a maioria dos notebooks de 1000 dólares pra cima tem chassis mais rígidos, teclas mais estáveis, estabilização adequadas em teclas maiores como barra ou return e, principalmente, a qualidade do domo de borracha que não faz parecer que você tá apertando uma borracha escolar porcaria.

Na faixa acima dos 50 dólares eu acredito que a maioria das marcas mais conhecidas como a Logitech fazem teclados suficientemente bons. Não vão ser mecânicos como os que vou mostrar, nada excepcional, mas melhores que a porcaria que eu acabei de mostrar. A tal porcaria aliás é mais pro segmento de quem quer ligar um teclado numa smart TV pra achar um filme no Netflix mais fácil ou coisas bem curtas assim, não pra digitações longas. Dai qualquer coisa vai ser melhor que ficar usando as setinhas do controle remoto pra digitar num teclado virtual na TV.

Agora que falamos do mais porcaria, vamos pros modelos mecânicos que vocês querem ver. Este aqui foi um dos meus primeiros teclados mecânicos da última década. Importei faz uns 5 anos e este teclado é da faixa de uns 150 dólares. E como podem ver, este eu usei até que bastante. A marca na lateral já quase desapareceu e a impressão de várias teclas quase apagou. Esta versão 1.0 nem vende mais, o mais próximo seria o modelo 4C mas ele vem com teclas PBT e o meu provavelmente são teclas ABS ainda. Já já vou falar sobre PBT mas normalmente você sabe que as teclas são o mais barato ABS porque com o tempo ele vai ficando com essa aparência glossy brilhante de gordura ou sei lá.

Este Das Keyboard é alemão e parece uma construção alemã mesmo. Ele é sóbrio, super sólido, o chassi é de metal e tem zero flexionamento. Dá aquela impressão que se você bater com um martelo periga de trincar o martelo. Se você ver um teclado acima dos 100 dólares com chassi de plástico, fique longe. Aliás, eu não recomendo nenhum teclado dessa faixa de preço que tenha keycaps ABS. Mas como esse teclado é de uns 5 anos atrás, quando essa moda de mecânicos nem tinha começado, vou dar um crédito. Agora vamos ouvir um pouco essa belezinha.

(demonstração - daskeyboard - digitando)

Falando em alemão, claro, você ouviu bem: estes são os famosos switches Cherry MX Blue. Os mais barulhentos de todos, sendo tactile e clicky. A empresa Cherry existe desde os anos 50 mas foi na última década que ela se tornou internacionalmente famosa por causa dos seus switches. Vamos ver o raio X de um switch Cherry Blue. Ele requer 60 centinewtons que é quase 61 gramas de força pra descer os primeiros 2.2 milímetros pra fechar o circuito de um total de 4 milímetros de key travel. Ou seja, na teoria você não precisa descer os 4 milímetros. Eu não sou, mas sei que existem digitadores velozes que digitam super leve, só relando de leve nas teclas o suficiente pra descer os 2.2 milímetros sem marretar até o fim.

Na prática, eu diria que em switches Blue é bem difícil digitar leve assim porque 60 gramas é uma força considerável, pelo menos pros meus dedos, e o bump que dá esse clicky dificulta só relar na tecla de leve. Olhem com calma de novo, eu bem devagar, indo os primeiros 2 milímetros até o clicky e depois os 2 milímetros finais até o fim, notem como tem a primeira resistência até atingir os 60 gramas.

(das keyboard - 1 tecla devagar)

De qualquer forma o Blue é considerado um dos switches mais satisfatórios justamente por causa desse barulho. Eu pessoalmente já enjoei do barulho, que tem esse pitch mais agudo. Os switches Brown são tactile, com um leve bump mas sem esse click, e por isso o barulho é pouco mais grave e um pouco menos irritante. Vai de gosto, mas eu recomendo testar o Brown em vez de ir direto pra Blue se o barulho preocupa. Se você trabalha sozinho, em home office, e não tem mais ninguém do seu lado, tanto faz, mas é 100% de certeza que todo mundo vai se irritar com os Blue.

Dos switches que são tactile, os Blue são os que tem o som mais característico agudo. Daí você tem o Brown. Não só o som é diferente mas ele requer menos força, de 55 centinewtons em vez dos 60 do Blue pra chegar no acionamento ou actuation aos 2 milímetros em vez de 2.2 do Blue, embora ambos tenham os mesmos 4 milímetros totais de key travel pra bater as teclas até o final. Pra quem gosta de barulho mas também quer cansar menos em sessões longas de digitação, eu diria que o Brown é mais confortável. E é uma questão de gosto mas eu prefiro o som um pouco mais grave dos Brown do que o agudo dos Blue.

Saindo da categoria tactile você tem os lineares. E aí são vários modelos. O mais comum são os Cherry MX RED. Um exemplo razoável em custo benefício talvez seja como este meu Corsair K65 Vengeance. Esse é da faixa de 100 dólares e tem mais baratos como o K55 de 50 dólares mas também é um teclado de membrana e não mecânico. O meu K65 usa switches Cherry RED que são lineares. A diferença com o Blue é que ele não tem um ponto de acionamento com um bump, ele desce linearmente dos 2 milímetros do acionamento até o total de 4 milímetros. Vamos ouvir primeiro:

(digitação - Corsair K65)

Agora vamos ouvir bem devagar pra vocês verem que o switch em si não faz clicky. Só quando eu bato com força vocês ouvem.

(devagar - Corsair)

Este Corsair não é nada de excepcional mas é bem competente. O chassi dele é razoavelmente rígido, ou seja, você não consegue torcer ele e mesmo tentando apertar no meio, ele não afunda. Mas o que entrega pra mim que ele é da categoria um pouco mais barata são os keycaps. Notem que eles parecem de ABS, com os símbolos impressos por cima e que com o tempo vão ficar com aquela aparência de engordurado e com letras apagadas. Mas uma das vantagens de se usar switches Cherry MX é que eles meio que se tornaram um padrão, então você consegue encontrar kits de keycaps e escolher não só cores mas materiais melhores como PBT. E, por acaso, eu tenho aqui justamente um kit da própria Corsair com keycaps PBT doubleshot.

Agora é uma boa hora pra explicar a diferença. Pra começar eu fico falando keycaps mas tecla seria mais ou menos a mesma coisa. Enfim, keycaps ABS vocês já viram em todos os teclados que mostrei até agora. Tem mais porcaria que ABS, existem teclados super baratos que usam PVC, e eu ficaria longe desses. De qualquer forma ABS e PBT são acrônimos pro tipo químico diferente de plástico. ABS quer dizer em português Estireno de acrilonitrila-butadieno e PBT quer dizer Tereftalato de polibutileno. Na prática, são tipos diferentes de plástico, só que PBT é um de melhor qualidade, mais caro, mas tem o que engenheiros chamam de estabilidade dimensional, o que quer dizer que deforma menos sob pressão do que ABS ou PVC. E como basicamente você vai querer marretar essas teclas todos os dias, você gostaria de um material de maior qualidade.

Mais do que isso, muitos kits de keycaps PBT são também double shot, ou seja, eles são feitos com duas camadas de PBT e você pode ver olhando por baixo. Isso normalmente quer dizer que a camada de cima é vazada onde tem a letra e a camada branca de baixo preenche esse vazado. Ou seja, a letra nunca vai sumir porque não é uma impressão de tinta por cima e sim a segunda camada de PBT por baixo. E normalmente esse PBT debaixo é semi-transparente, daí muitos fabricantes colocam LED no switch e com isso você tem backlight que ilumina a letra.

Por causa desse processo você entende que maior qualidade significa usar switches melhores como os da Cherry, com keycaps doubleshot, com chassi de metal, e vão custar naturalmente mais caro. Mais do que isso, ABS e PVC tem um barulho diferente de PBT. ABS tem um som mais de “plástico barato” mesmo e PBT é um som mais cheio e mais robusto, um pouco mais grave também, parte por ser mais denso e mais pesado. Compare os dois lado a lado, o mesmo teclado da Corsair com os keycaps ABS originais ….. e agora trocando pras teclas PBT doubleshot.

(som - corsair trocando teclas)

Eu acho que teclas PBT tem som mais assertivo, a estabilidade das teclas um pouco mais pesadas é melhor, eles costumam ter uma textura diferenciada que não dá sensação dos dedos escorregarem, e no geral a sensação é bem mais satisfatória, só que agora ele deixou de ser um teclado de 100 dólares e pulou pra categoria de 150 dólares. Então de fato você recebe o que paga.

De qualquer forma, não quer dizer que as teclas ABS sejam totalmente ruins. Muitos notebooks caros usam teclas de ABS. Além disso você sempre pode começar com um teclado com um bom chassi e bons switches e depois pagar 50 dólares ou menos e pedir um kit de keycaps PBT doubleshot como nesse exemplo que mostrei agora. Assim você inicia investindo 100 dólares e depois consegue dar um upgrade.

Nessa mesma faixa dos 100 dólares da Corsair costuma estar outra marca que por alguma razão eu tendo a colocar na mesma categoria, que é a Cooler Master. E por causa da história dos switches bugados butterfly surgiram modelos de diversas marcas tentando trazer um pouco do perfil mais low profile de teclados como os antigos magic keyboards. Se você já usou um teclado da Apple da era de 2015 pra trás, vai lembrar que os de desktop eram muito parecidos com os dos macbooks. Low profile quer dizer frame menos espesso, teclas achatadas tipo chiclete, com pouco key travel, na faixa de 1 milímetro ou menos.

Daí eu vi a Cooler Master lançando o modelo SK630 que usa switches Cherry MX low profile que é um switch um pouco diferente dos demais porque tem o menor key travel de todos, com apenas 1.2 milímetro. E por cima disso a Cooler Master construiu keycaps flat, retos e finos com espessura da ordem de meio centímetro. Então esse SK630 parece uma versão mecânica dos antigos magic keyboard da Apple. Se você gosta desse estilo de keycaps finos e retos talvez esta seja uma boa alternativa. Esses switches parecem Red mais finos que precisam de 45 centiNewtons de força. Os keycaps em si parecem ser PBT doubleshot e acho que vale comparar o barulho dele com o Corsair com os novos keycaps PBT lado a lado também.

(comparação cooler master - corsair pbt)

Diferente do Corsair o material do frame é um pouco pior. Ele tem um pouco de torção e inclusive não é perfeitamente horizontal, dá impressão que tem uma leve curvatura. Se você procura o um teclado mecânico mais fino, com uma cara mais de Mac, esse é um candidato. E diferente do Corsair, este tem até RGB. Pelo mesmo preço eu diria que é algo a se considerar. No começo eu não gostei muito das teclas retas, mas é rápido de se acostumar e dá pra digitar rápido nela também. Mas tem um grande porém, se o objetivo for um teclado verdadeiramente low profile, esta primeira tentativa da Cooler Master talvez não seja a melhor. Eu não tenho, mas a Keychron tem o modelo K1 que é tecnicamente mais low profile do que este então vale a pena conferir no site deles.

Note que até aqui eu só estou comparando os materiais e qualidade de construção. Numa discussão de teclados, existem mais características como as que eu mencionei no começo do video, incluindo customização de macros, baixo input lag, anti-ghosting ou n-key rollover e mais. Isso faz mais diferença pra gamers profissionais que treinam pra serem competitivos em campeonatos. Um jogador profissional de Starcraft consegue fazer de 500 a 800 comandos por minuto; obviamente pra ele faz diferença um input lag milissegundos menor e que as teclas registrem corretamente sem ghosting, ou seja, você pode apertar várias teclas ao mesmo tempo e todas elas vão ser registradas corretamente.

Agora a realidade, pra mim, ou pra maioria de vocês que digitam textos normais como e-mails ou código de programação, dificilmente vão notar um teclado que não tenha todas as funcionalidades de gamers. Teclado gamer não é só RGB como eu já disse. De jeito nenhum, se o input lag for alto ou se tiver ghosting, ele não presta pra gamers. Mas pra digitação normal, você não vai notar tanto assim.

Mas uma funcionalidade que pra mim faz diferença apesar de não ser gamer é a qualidade do switch. Pra um gamer é importante o switch ser mais leve e com ponto de acionamento mais curto, portanto um key travel menor, pra que você possa registrar mais comandos, mais rápido e a tecla ter uma distância menor pra voltar pra posição de reset. E por isso dizem que switches lineares como os Cherry MX Red são mais voltados pra gamers. Por outro lado, pelas mesmas razões eu considero os lineares melhores pra mim que costumo digitar razoavelmente rápido. Eu disse que gamers profissionais fazem de 500 a 800 comandos por minuto? Digitadores velozes conseguem chegar em 400 toques por minuto ou mais, então estão perto da mesma faixa.

Recapitulando, eu disse que switches Blue tem força de acionamento de 60 centinewtons e 2.2 milímetros de pre-travel do total de 4 milímetros até bater no final. Já os Cherry MX RED requerem 25% menos força, ou seja, 45 centinewtons e tem pre-travel de 2 milímetros. Por si só, switches lineares são mais silenciosos que os Blue ou Brown. O switch em si não faz nenhum barulho, só a tecla batendo no chassi que faz. Além deles existem as variantes Silent Red e Speed Silver, ambos requerem os mesmos 45 centinewtons de um Red mas o pre-travel de um Speed Silver cai quase pela metade, pra 1.2 milímetro com key travel total de 3.4 milímetros em vez dos 4 do Blue. Na prática eu não conseguiria distinguir um Red de um Silent Red, mas um Speed Silver já dá pra sentir diferença.

Esse key travel curto começa a entrar no território de um notebook Thinkpad, mas precisando só de cerca de metade da força. Mas não existem só switches da Cherry. Diversos fabricantes começaram a desenvolver seus próprios switches pra se diferenciar e realmente otimizar o caso de uso de gamers. Um bom exemplo é a Razer, marca que é comumente associada com gamers. Os teclados de fato são bons. Não vou dizer o mesmo dos fones de ouvido mas eu acho que gamers não precisam de nenhuma Senheiser, B&O ou Bose pra jogar Fortnite, eles só precisam de microfones pra dar uma xingada em alto e bom som. Mouses eu prefiro os da Logitech como o G502.

Por acaso, eu tenho dois modelos de Blackwidow da Razer. Um com switches Green que são semelhantes aos Cherry Blue e os Yellow que são lineares similares aos Cherry Red. Pois é, a Razer não quis deixar super óbvio com as cores. Vamos colocar ambos lado a lado pra vocês verem a diferença de novo de um switch tactile e outro linear do mesmo fabricante, no mesmo modelo de teclado.

(comparativo - razer green e yellow)

Vocês vão notar que ambos os teclados tem praticamente as mesmas especificações técnicas. Os chassis são de metal, os keycaps são PBT doubleshot, eles tem backlighting RGB customizáveis, e a única coisa diferente são os switches mesmo. Diferente da Corsair ou mesmo meu antigo Das Keyboard é que você imediatamente sente que tá digitando em uma construção super sólida. Nada nele balança, é tudo firme.

De novo, depende muito do seu gosto pelo som clicky do Razer Green ou menos barulho no caso do Razer Yellow. Quando eu uso o Green dá pra ouvir constantemente o distinto clicky agudo semelhante ao do Cherry MX Blue. Porém quando se usa o Yellow linear, você sente mais o barulho do keycap mais denso de PBT contra um chassi rígido quando a tecla chega até o fim. Em termos de switches, pode parecer heresia mas eu diria que prefiro a configuração da Razer mais que os Cherry originais.

O Green da Razer, comparado ao Blue da Cherry, requer menos força de acionamento, em vez dos 60 centinewtons ele precisa só de 50, então é um pouco mais leve até do que o Cherry Brown. E em vez de ter que descer 2.2 milímetros pra acionar, o Green precisa só de 1.9 milímetros. Exatamente porque a Razer foca em gamers, ele refinou o estilo tactile clicky de um Cherry Blue pra precisar de menos força. Já o Yellow da Razer é parecido com o Speed Silver da Cherry precisando dos mesmos 45 centinewtons de força de acionamento e tendo um pre-travel curto de 1.2 milímetro que é quase metade do Cherry Blue. Ou seja, são switches que de fato são mais voltados pra competição, focando em conseguir registrar mais comandos por minutos exigindo menos força e menos key-travel do que os Cherry.

Repetindo, eu não sou gamer competitivo, mas eu acho que os switches lineares com key travel menor que 2 milímetros são melhores pra digitadores rápidos e nesse caso o Razer Yellow é muito mais próximo do Cherry MX Speed Silver do que do Red. Digitar no Corsair com switches Cherry Red é bem rápido pra mim, mas o Blackwidow com switches Yellow da Razer são uma boa competição. Ambos são bons e rápidos mas a construção mais robusta da Razer pra mim é mais satisfatória.

Falando de switches diferentes, um concorrente que eu diria que é pau a pau com essa solidez do Razer Blackwidow é o Logitech G Pro. Pra começar, ele é um pouco mais barato que o Blackwidow Chroma V2 que custa hoje uns 140 euros e o G Pro custa 130 euros. E essa diferença de 10 euros é perceptível. Na ponta dos dedos me dá a impressão dos keycaps da Razer serem mais sólidos, mas isso talvez seja porque no G Pro quando você bate a tecla até o fim o som é levemente mais abafado e no Blackwidow você tem um som um pouco mais metálico no fim. Na prática o G Pro é mais silencioso do que o Blackwidow. Se colocarmos lado a lado você deve sentir a diferença:

(compare blackwidow vs g pro)

A Logitech tem alguns conjuntos de switches diferentes. A mais próxima da Cherry é a série GX que tem GX Blue, Brown e Red que mais ou menos se aproximam do Cherry Blue, Brown e Red respectivamente. Diferente da Razer a Logitech preferiu seguir as mesmas cores. Mas o que eu tenho aqui é o Romer-G Linear. Comparado aos GX ele requer menos força de acionamento de 45 gramas e um pre-travel de só 1.5 milímetros. Portanto ele também é quase comparável a um Cherry Speed Silver ou Razer Yellow.

Pra usar no escritório eu tenho preferido o G Pro justamente por ser um pouco mais silencioso no geral que o Corsair K65 ou o Razer Blackwidow. A construção do chassi e dos keycaps parecem mais balanceados pra abafar barulho. Ele não chega a ser totalmente silencioso, mas em comparação ele é bem mais suave e o que menos incomoda pessoas ao redor. O Cooler Master que mostrei antes também é silencioso mais ou menos no mesmo nível do G Pro.

Mesmo se você escolher um switch linear que, por si só praticamente não faz barulho no acionamento da tecla, ainda assim a ação de bater a tecla até o fim faz barulho. Daí depende muito do material dos keycaps e da construção do chassi. Ser de metal ajuda na rigidez mas também pode aumentar o barulho. Se você escolhe um switch tactile clicky como o Cherry Blue, isso só adiciona som extra. Em qualquer dos casos, você pode escolher diminuir o som do switch e dessa batida da tecla usando um O-Ring. São super baratos e basicamente são pequenos anéis de borracha que você coloca embaixo do keycap, então ele ao mesmo tempo serve de amortecedor pra diminuir o som da batida e também diminui o key travel, fazendo com que ele seja mais curto. Se estiver usando o Cherry Blue ainda vai ter um clicky mas ele vai ser menos irritante e o som no geral vai ser menor. Então é outra opção que talvez você queira experimentar.

Enfim, depois que eu migrei pra switches lineares um colega me falou de uma marca que eu nunca tinha ouvido falar, a Matias e o teclado Matias Quiet Pro que, segundo seu website clama, é o teclado mais silencioso do mundo. O design dos switches é mais inspirado nos switches Alps do que na Cherry e, de fato, é um teclado silencioso, ouçam comparado com o G Pro:

(matias comparado com G Pro)

O switch deles tem 60 gramas de força de acionamento e key travel total de 3.5 milímetros, o que coloca ele em território dos Cherry Brown. De fato, se eu for simplesmente pelo mais silencioso esse é de longe um dos mais quietos, mesmo se comparado com o G Pro que eu acabei de dizer que é bem silencioso.

Porém a 130 dólares não dá pra recomendar. Pra começar o corpo do teclado é de plástico e não um que me inspira muita confiança. Diferente da Cooler Master que pelo menos tenta ser mais fino, esse ainda é gordão. Não é algo que você consegue torcer fácil nem afundar, mas ao digitar você sente que tá digitando em cima de algo que parece mais oco e menos rígido. Os keycaps também são de ABS, com as letras impressas em cima, ou seja, é questão de tempo até ele ficar glossy e as letras apagarem. Fora isso, não tem backlight. Eu não faço questão de RGB mas uma luz branca faz falta especialmente porque eu gosto de digitar a noite com pouca luz. E esse teclado é um 75% o que significa que tem muitas teclas importantes com funções duplicadas, por exemplo, o Home é o Page Up com a tecla de function, o End é o Page Down com a tecla function.

Aliás, é uma boa hora pra falar de tamanhos de teclado. O tamanho grande ou full-size é aquele mais parecido com o layout original de um IBM antigo, com a coluna do meio com teclas de navegação como home, end, page up e down e a terceira coluna da direita com o teclado numérico, que eu imagino que nenhum contador consiga viver sem. Eu comecei como programador num teclado full-size dos anos 90 mas eu nunca fui particularmente rápido no numérico e com o passar dos anos eu nunca precisei gastar muitas horas preenchendo planilhas ou algo assim, então pra mim não faz falta.

Mais do que isso, quando eu uso um teclado centralizando só a parte das letras com o meio da tela, significa que meu braço vai ter que esticar muito pra direita pra usar o mouse, e isso cansa mais o braço. Eu prefiro ter o mouse mais próximo. Por isso também teclados de gamers tendem a ser pelo menos tenkey-less, sem numérico, pra ter mais espaço pra fazer movimentos longos de mouse. Em particular pra gamers de FPS, quanto mais espaço tiver na direita pro mouse melhor, por isso existem até teclados que são só a metade da esquerda que é onde normalmente você mapeia navegação, strafe e outros comandos e você raramente usa as teclas do lado direito. Assim você duplica o espaço pra movimentar o mouse.

Se eu quiser ir ao extremo existem os layouts 60% ou até mesmo 40% que, como os nomes dizem são 60% ou 40% do tamanho de um full-size. O 60% não tem a segunda coluna de teclas de navegação, então coisas como seta, page up e tudo mais precisa apertar uma combinação de function e alguma outra tecla. Pior, não existe a linha de teclas de função em cima das teclas de número, as teclas F1 a F12, então muitas vezes a tecla Esc que fica no começo dessa linha tem que descer e ficar do lado da tecla 1, e com isso a tecla que normalmente fica lá que é til e backtick não existe e você precisa usar uma combinação de teclas.

Pra digitar português onde você acaba precisando do til, isso é extremamente cansativo. Navegar usando combinação de teclas também é cansativo. Eu realmente não recomendo. Na dúvida eu ficaria num tamanho abaixo do full-size que é o chamado TKL ou tenkey-less, ou seja, é um teclado full-size sem a parte numérica da direita. Todos os teclados que mostrei até agora, incluindo o Blackwidow, G Pro, Corsair foram Tenkeyless.

Porém este Matias Quiet Pro que estou mostrando é um tamanho abaixo disso, de 75%, ou seja, ele retém a linha de teclas de função que tem o Esc no lugar certo, mas retém só metade das teclas de navegação, onde algumas precisam ser combinações de teclas, mas no mínimo tem as setas. Se você digita num editor de programação como Sublime, VS Code ou Vim, consegue remapear facilmente pra outras teclas como “h j k l” e não chega a ser totalmente ruim, mas se como eu precisa navegar por telas de Word ou Google Docs, ou mesmo no caso de editar vídeos, realmente é desconfortável sem ter setas ou um home e end. Por isso só recomendo layouts abaixo de 75% se você realmente passar 90% do seu tempo só em código ou games.

Existe até layouts absurdos como 40% que se livra da linha de teclas de número em cima do qwerty. Mas pra mim isso já é mais exibicionismo e tem zero praticidade no dia a dia. De novo, se o que você mais faz é games, talvez não faça diferença. Como uma curiosidade, um segundo teclado pra brincar ou algo assim, pode ser legal. Se o objetivo for um teclado que seja fácil de transportar na mochila, pra trabalhar de verdade, então no máximo um 65% wireless é mais que suficiente. E sim, eu sei, alguns poucos entusiastas se forçam a gostar desses layouts minúsculos, mas eu acho que pra maioria das pessoas não compensa o esforço pra ganhar alguns poucos centímetros na mochila.

O Matias Quiet Pro é um teclado realmente silencioso como diz a propaganda mas cujos materiais não condizem com o preço. Se ele custasse menos de 100 dólares talvez, mas a 130 eu prefiro já ir pro Blackwidow ou G Pro que tem materiais e acabamentos muito superiores por uma diferença pequena de preço.

O último switch diferente que eu queria mostrar hoje é uma peça que você precisa importar da Ásia, e são os switches Topre. O original é da marca RealForce e o modelo que vocês estão vendo é o RealForce 87 U fabricado no Japão. Só por causa disso eu não posso recomendar esse modelo porque dependendo do frete o preço final pode chegar a absurdos 500 dólares, nos Estados Unidos. Você consegue achar outros fabricantes como a Leopold da Coréia do Sul ou a Ducky de Taiwan que dentre outros switches também oferece modelos com Topre. Aliás, a grande maioria dos teclados que estou mostrando hoje e no próximo video são importados, então varia frete e impostos. Marcas mais famosas como Corsair, Razer e Logitech você tem mais chance de encontrar por aqui. Vai variar caso a caso então só pesquisando mesmo. Fucem Mercado Livre e Aliexpress antes.

Eu comprei o meu pela Amazon e em 2018 já custou salgados 270 dólares mais o frete pra cá e por sorte não caiu em tributação quando chegou, se não me engano. E vai custar caro mesmo, porque vem do Japão. Se comparado ao Matias ele é beeem melhor construído. Mas a qualidade de construção da Razer ou Logitech ainda é superior. O layout é tenkeyless o que torna ele bem mais confortável pra usar no dia a dia. Uma coisa que me incomoda nele é que além de não ter backlight o design é letras escuras em cima de keycaps pretos, então se for comprar recomendo a versão clara.

O correto de fato é digitar sem olhar e normalmente eu faço isso mesmo. Comparado ao Matias que é um 75% isso me incomoda menos aqui porque eu não preciso ficar lembrando quais combinação de teclas que é home ou end, mas por esse preço eu ia gostar de ter um backlight. De qualquer forma a motivação toda pra se comprar um RealForce são os switches.

Tecnicamente os switches Topre não são mecânicos. Na realidade eles são rubber dome. Lembra o que eu expliquei no começo sobre domos de borracha? A diferença é que debaixo do domo existe uma mola também, o que oferece uma resistência e retorno melhor. Diferente de um rubber dome ou mesmo membrana, o Topre você não precisa bater até o fim pra registrar. Mas diferente dos Cherry o ponto de acionamento é bem mais alto, mais no começo da batida em vez de ser no meio. Então dá sensação que você faz uma força inicial maior com um acionamento no alto e depois disso a resistência do domo é mais leve do que nos mecânicos e você vai até o fim rápido. O meu requer 55 gramas de força mas como o acionamento é bem mais no começo, me dá impressão de estar digitando num switch mais pesado que o Cherry Blue ou Black.

Eu falei no começo sobre o teclado do Thinkpad que é um scissor switch normal mas com um key travel maior de 78 gramas de força de acionamento. Tanto o Thinkpad quando este RealForce são os que mais cansam meus dedos em sessões longas. É importante notar que eu estou mais acostumado com switches lineares de 45 gramas, por isso a diferença é muito gritante e é mais uma questão de adaptação. Também depende da sua mão. Mãos maiores que as minhas vão ter bem menos problema com switches mais pesados como esses.

Em termos de barulho, os switches em si são silenciosos. Ele tem o bump de um switch tactile como o Brown e assim como ele não tem o clicky de um Blue. De novo, o barulho maior é da tecla batendo até o fim no chassi e não do switch em si. O som geral é levemente mais emborrachado, mais contido e suave, lembrando mais o Matias. Mas diferente dos de membrana normais, ele é assertivo o suficiente pra ser satisfatório e não parece que você tá apertando uma borracha escolar em cima de plástico barato.

Falando em plástico, os keycaps são bem duros encaixado nos switches e eu não consegui tirar nem com a pinça, também preferi não forçar porque não sei se o mecanismo quebra se forçar, mas pela aparência, pela textura que não escorrega e aparente rigidez, me parece que são keycaps de PBT. Então, se você por acaso estiver pela Ásia, procure por teclados com switches Topre, no mínimo vale testar porque a sensação é muito diferente dos mecânicos normais.

E por hoje chegamos ao fim. Ainda tem mais teclados, vou guardar os mais interessantes pra Parte 2. Resumindo, em termos de switches você tem os Cherry MX, Blue e Brown se quiser uma tecla com um bump na hora de apertar e um clicky no caso do Blue ou os lineares como Red ou Speed Silver se quiser algo mais leve e mais rápido. Switches Gateron ou Kaihua são bons clones compatíveis e vou mostrar exemplos no próximo episódio.

Marcas mais mainstream como Razer Blackwidow ou Logitech G Pro são ótimas opções na faixa dos cento e pouco dólares se quiser algo com uma construção mais sólida e switches resistentes e confiáveis como os da Cherry, mas mais voltados pra velocidade e gamers, que eu pessoalmente prefiro. Modelos igual ou acima do K65 da Corsair podem ser uma opção um pouco mais barata e igualmente satisfatórios mas um pouco mais barulhentos pelos materiais usados.

Como sempre, não façam perguntas simples que um Google pode responder. Eu achei todos esses teclados sem ler um único fórum, foi aos poucos, pesquisando sobre cada switch, sobre cada marca, um a um ao longo de 5 anos. E lembrando que dos quase 30 anos de carreira só nesses últimos 5 eu comecei a comprar esse tipo de teclados. Quer dizer que nos primeiros 10 a 15 anos eu usei teclados de membrana mais porcaria que tinha porque era o que dava pra comprar. E nem por isso eu programei pior ou mais devagar. Assim como um carro de corrida, primeiro você precisa aprender a ser piloto pra tirar o máximo que o máquina pode entregar. Antes disso qualquer coisa serve. De qualquer forma não deixem de mandar um joinha se curtiram o video, assinem o canal e cliquem no sininho pra não perder a parte 2. Compartilhem o video pra ajudar o canal. A gente se vê na parte 2, até mais!

Descrição no YouTube

The Last Jedi é um assunto que vai ser eternamente controverso, mas hoje não vou entrar na discussão mas sim elencar o que nós fãs não gostamos e ir um passo além, mostrar como os fãs estão consertando esse e outros erros da história de Star Wars.

Links:

• Harmy’s Star Wars: Despecialized Edition - History & Sources Documentary (extended version) (https://www.youtube.com/watch?v=mGrXO2RDzLg)
• Star Wars Despecialized Edition is Awesometacular! (https://www.youtube.com/watch?v=ZTRbkIBn2j0)
• How Star Wars was saved in the edit (https://www.youtube.com/watch?v=GFMyMxMYDNk)

Script

Olá pessoal, Fabio Akita

Esta semana o tema é geek. Terça eu falei sobre como consertar Justice League e hoje o tema é o hiper controverso The Last Jedi. Vamos ver como consertar esse erro.

(…)

Star Wars é uma enorme dor de cabeça. O maior problema é que dependendo da sua idade você vai ter opiniões muito diferentes. Por exemplo, se você só começou a assistir recentemente, talvez a partir de Force Awakens, não vai entender tanto porque tantos fãs odiaram The Last Jedi.

Talvez você tenha começado pelos Prequels e séries de TV como Clone Wars e Rebels. Nesse caso sua base de comparação já fica diferente. Aqui você talvez fique em cima do muro com relação à nova trilogia.

Mas se você é da geração que começou com a trilogia original e veio assistindo a evolução desde o começo, é onde a nova trilogia realmente vai começar a irritar. Eu sou dessa geração, eu tenho memórias de quando Return of Jedi tava nos cinemas. Eu fiquei horas sentado na fila do cinema quando Phantom Menace foi lançado, tendo esperado de 1983 até 1999, a expectativa era grande e o filme foi uma grande decepção. Maldito Jar Jar Binks. Mas pelo menos gastei boas horas em corridas de pod racing com o game de PC Episode I: Racer.

Attack of the Clones melhorou bastante. Finalmente ganhamos o que queríamos ver: uma história um pouco melhor, muitas lutas de lightsabers, embora a parte do romance tenha sido bem ruim na época e continua sendo agora. Revenge of the Sith é o melhor dos filmes dessa trilogia, de longe. Apesar de várias inconsistências pra ligar com a trilogia original, poder ver o nascimento de Darth Vader era o que queríamos ver e isso ficou até que bom, tirando o famigerado “nooooo” no final.

Isso foi em 2005, daí tivemos a série de TV The Clone Wars e em 2012 a Disney compra a Lucas Film. George Lucas sai de cena e entra Kathleen Kennedy na liderança. A primeira bola dentro foi trazer J.J. Abrams pra iniciar uma nova trilogia. J.J. é realmente bom, eu gosto muito do trabalho dele. Nunca fui fã de Lost mas o soft reboot que ele fez em Mission Impossible 3 eu gostei bastante. Pra quem não lembra, MI:2 foi o pior filme da franquia e é no 3 que se cria a estrutura que vai evoluindo em Ghost Protocol, Rogue Nation e agora Fallout. Eu também gostei muito do reboot de Star Trek nos cinemas. Eu nunca fui um trekkie nem nunca tentei aprendi Klingon, mas J.J foi extremamente bem sucedido em tornar Star Trek acessível de novo pra uma nova geração. E quando eu vi Force Awakens eu não fiquei muito impressionado mas pelo menos não fiquei decepcionado, a última coisa que eu Não queria era ter de novo a mesma sensação de Phantom Menace. Todo mundo sabe que ele preferiu jogar seguro, seguiu beat por beat os pontos de A New Hope e mandou até que bem em criar novos personagens que atiçaram a curiosidade sobre o que poderia vir a frente com Finn, Rey, Snoke, Kylo.

Mas aí a direção passou pra mão de Rian Johnson e The Last Jedi sofre por 2 razões: J.J. deixou muitas arestas soltas que provavelmente não tinha uma visão maior por trás. Ou seja, ele deixou muitas expectativas pra resolução. Rian herdou esses problemas. E em cima disso quis colocar muitas tangentes que arrastam a narrativa do filme. No geral, depois de 1 ano, eu meio que já engoli a maioria dos pontos que eu não gostei de imediato. Eu acho que o maior problema é justamente porque tecnicamente falando The Last Jedi é a melhor produção de um filme Star Wars que já foi feito. A sequência do sacrifício de Holdo o ataque surpresa na velocidade da luz é de longe um dos melhores momentos no cinema, ponto. Foi perfeito. E aí você tem pontos horrorosos como Canto Bight. Esse desbalanço que destrói o filme. Eu também fui um dos que passou os últimos 2 anos especulando sobre Snoke e os pais de Rey. E não ter essas respostas até que não foi tão ruim assim tanto quanto Canto Bight , Maz Kanata fazendo um call no meio de uma luta aleatória qualquer só pra soltar uma informação que não serve pra nada. Casting de um Benicio Del Toro num personagem que na prática não serviu pra nada. Repetir o erro de Force Awakens de não fazer nada de útil com a capitã Phasma e desperdiçar o personagem de novo. Não fazer nada de útil com o Finn e no final cortar o climax do nada sem motivo. Eu fui um dos que mudei de opinião e até entendo melhor a idéia do Luke cínico anti-herói nesse filme. Mas o arco principal da história ser a perseguição mais lenta da galáxia com as piadas mais forçadas arrebentou esse filme.

Procure no YouTube e vai encontrar centenas de vídeos descrevendo item a item tudo que não funciona nesse filme, e é uma pena porque se ele passasse por uma segunda revisão de edição acho que ele ficaria bem aceitável. E aí vem a recomendação de hoje, o canal do YouTuber Ivan Ortega. Ele é um mexicano-americano que resolveu consertar o problema. Faz alguns meses que ele pegou o filme e vem reeditando no Adobe Premiere todos os pontos que todo mundo odiou no filme.

O cara tá fazendo mágica nessa edição. Ele consertou literalmente TODOS os pontos do filme que dava pra mudar com edição. E vocês vão ficar surpresos como edição é fundamental num filme. Quem conhece a história de Star Wars sabe que o primeiro corte do A New Hope original fez o filme ficar ruim. Ninguém gostou, Spielberg não gostou, De Palma não gostou. Aliás Brian De Palma ajudou a reescrever o texto de introdução do filme, que originalmente era longo demais. Mas quem salvou o filme foi a mulher de George Lucas, Marcia Lucas que voltou pra mesa de edição e fez um novo corte do mesmo filme. A edição de Marcia transformou um filme que era objetivamente horroroso num dos maiores clássicos da história do cinema. E é uma excelente lição para lembrar que juntar um monte de partes boas num saco não faz o saco ficar bom. Por isso saber o que cortar fora, mudar a ordem das coisas, pode fazer toda a diferença e isso vale pra filme, pra música, pra dissertações e textos em geral, e até mesmo pra código - que é um dos motivos de porque making of de filmes me atraem tanto.

Ivan Ortega parece entender bem isso e ele vai além. Me preocupa um pouco como vai ficar no final mas ele vai redublar algumas falas do filme com pessoas que conseguem imitar as vozes de personagens como Luke. Ele tá treinando uma coreografia de pra ele mesmo fazer uma pequena tomada extra da luta entre Kylo Ren e Luke e ele parece que conseguiu mesmo trocar Holdo da icônica tomada do sacrifício e trazer ninguém menos que o General Ackbar, que aos olhos de muitos incluindo eu, foi totalmente desperdiçado nesse filme.

Só dele conseguir diminuir e diluir a longa e cansativa cena de Canto Bight já é um enorme ganho. Ele conseguiu reverter a piada do Luke jogando o light saber fora. Ele conseguiu reverter um monte de coisa só na edição. O cara é bom. E ele acabou de lançar um teaser trailer pra indicar que finalizou o corte final. Assinem o canal dele pra saber quando sai o filme reeditado completo.

Essa não é a primeira vez que os fãs fazem algo assim. No anos 90 George Lucas resolveu reeditar os filmes da trilogia original. Ele adicionou um monte de computação gráfica muito ruim e mudou coisas importantes dos originais como a famigerada cena onde Han Solo atirou primeiro. Esses foram os Special Edition. O problema é que hoje você só tem acesso a essas versões adulteradas. Não existe mais a versão original da trilogia. Eu assisti a original em VHS e em DVD antes das Special Edition. Alguns anos atrás um grupo de fãs se juntou pra procurar as versões originais e fazer o processo de “remasterização” que significava limpar frame a frame do filme pra preservar como era a versão original. Acho que o projeto era Star Wars Revisited e tem Empire Strikes Back Revisited. Eu não achei mais os links do projeto original mas coloquei na descrição os links que encontrei, se alguém tiver links melhores não esqueça de compartilhar com a gente.

E tudo isso são evidências de como o Head Honcho da Marvel Studios Kevin Feige tá fazendo um trabalho hercúleo. Nem a Lucas Film da própria Disney, nem a Warner Bros tão conseguindo criar e manter um universo coeso. O que Feige conseguiu fazer, desde Iron Man em 2008 até Infinity War esse ano é um acontecimento histórico. Mas o que eu queria mostrar nesse vídeo também é um pequeno gosto da comunidade geek.

Diferente de áreas mais explicitamente artísticas como quadrinhos ou filmes, como programador eu também me considero de uma profissão criativa. Criatividade não é copiar e colar as coisas, é aprender o máximo possível de gente talentosa pra inspirar a melhoria nas nossas próprias técnicas. No mínimo, todo geek de verdade tem como característica comum a dedicação em cima do que gosta. Quando eu penso em código, penso da mesma forma como Nando reimaginando a estrutura de um filme ou Ivan reeditando um blockbuster nas madrugadas. É assim que nós geeks fazemos.

E aí, gostaram desse vídeo? Discutam os temas de hoje nos comentários abaixo. Mande um joinha, assinem o canal e não deixem de clicar no sininho pra não perder os próximos episódios. A gente se vê na próxima, até mais.

Descrição no YouTube

Esta semana vamos pra temas geek. Hoje vamos olhar um pouco a trajetória de Justice League até ele implodir e em vez de só criticar mostrar soluções que outros geeks youtubers chegaram pra resolver esse problema.

Links:

• Batman v Superman: What Went Wrong? – Wisecrack Edition (https://www.youtube.com/watch?v=467ehoaGDaE)
• Civil War v Justice League: Dawn of Character Development (Video Essay) (https://www.youtube.com/watch?v=nVEatk78mQQ)
• Justice League Reshoots: Every Change Whedon Made To Snyder’s Film (https://screenrant.com/justice-league-movie-reshoot-changes-explained-snyder-whedon/5/)

Script

Olá pessoal, Fabio Akita

Esta semana vamos mudar um pouco os temas. Quero falar um pouco sobre filmes. Dois em particular, Justice League hoje e o espinhoso The Last Jedi na quinta. Dois dos mais controversos filmes do ano passado, duas das principais decepções em termos de blockbusters.

Vocês já devem ter ouvido e assistido todo tipo de crítica em torno desses filmes. Com os rumores da negociação com Henry Cavill alguns dias atrás colocando em risco a continuidade do Superman. E o cancelamento da nova trilogia Star Wars que o Rian Johnson ia iniciar - graças aos céus …

No episódio de hoje quero falar um pouco sobre Justice League e como consertar essa bagunça.

(…)

Esse filme estava fadado a dar errado. Todo mundo acompanhou o stress durante as filmagens. Zack Snyder fez um filme que todo mundo gosta, os 300 adaptado da obra homônima de Frank Miller. Provavelmente a adaptação de um graphic novel que entregou as melhores frases feitas na história dos blockbusters. Pra mim ainda é o melhor papel de Gerard Butler e foi a primeira vez que prestei atenção em Lena Hedley antes dela virar Cersey em Game of Thrones.

Snyder foi um passo além e fez uma adaptação até que não tão ruim do lendário Watchmen de Alan Moore. É outro filme que não foi tão bem nas bilheterias mas eu particularmente gosto como filme. Em particular pontos pelo casting de Jeffrey Dean Morgan como The Comedian e em manter o tema do “Big Joke” e isso deve ser por causa do screenplay de David Hayter, que como bônus de curiosidade, pra quem gosta da série de games Metal Gear do lendário Hideo Kojima, todos sabem que David Hayter é a eterna voz de Solid Snake.

Com boas credenciais, Snyder ganhou as chaves do universo DC e começou com Men of Steel que não foi completamente ruim, tem idéias que eu até gosto, em particular a caracterização de um Superman menos perfeito. O problema disso é a sequência em Batman v Superman, onde um Superman humanizado fica muito próximo do Batman e isso acaba com o propósito da história em si, ao contrário do tema da graphic novel The Dark Knight Returns de Frank Miller, que serviu de inspiração pra muitas das cenas, e onde a lendária batalha entre Batman e Superman é uma batalha filosófica entre individualismo e coletivismo, como bem analisou o canal Wisecrack, que você pode assistir clicando no link acima.

Então entramos em Justice League. A pressão em cima da Warner Bros tava no máximo. Muito stress interno. O script original de Snyder, com ajustes de Geoff Johns não tava bom. Foi quando trouxeram Joss Whedom pra reescrever cenas inteiras. E tudo isso com a produção em andamento. Fora acontecimentos aleatórios como o famigerado Mustache-gate por conta das refilmagens que acontecerem ao mesmo tempo que Missão Impossível 6. Curiosidade pra quem não lembra, todo mundo tirou sarro que tiveram que tirar a barba do Henry Cavill em pós-produção via computação gráfica porque a Paramount não queria deixar ele tirar a barba pras refilmagens. Mas aí depois disso um dos stunts do Tom Cruise deu errado e ele se machucou feio e as filmagens ficaram paradas um tempão de qualquer jeito. No final ia dar tempo do Cavill tirar a barba, refilmar o Superman pro Justice League e esperar a barba crescer de novo até o Cruise se recuperar. Coisas de Hollywood. Aliás, se você não assistiu MI:6 assista, é o melhor filme da série e de longe um dos melhores blockbusters de ação da atualidade.

Enfim. No frigir dos ovos o filme Justice League virou uma bagunça. A história ficou ruim. A direção ficou ruim. Acabaram usando muito mal todos os personagens. Whedom mudou tanto o filme original que muitos clamam para o lançamento do cut original do Snyder. Eu não esperaria muito desse cut também depois de Batman v Superman.

A Warner teve um tiro de sorte com Wonder Woman, que apesar de ser um filme mais ou menos, com um 3o ato bem ruim e um desperdício de vilão principal, conseguiu uma boa diretora em Patty Jenkins que acertou na química entre Gal Gadot e Chris Pine, sem o qual o filme também teria sido esquecível.

Os próximos filmes, pelo menos pelos trailers, parece finalmente estar acertando. O filme do Aquaman de James Wan parece perfeito nos trailers, ponto positivo pra personagem Mera de Amber Heard. Wan que aliás vem fazendo filme bom atrás de filme bom, desde Saw, Insidious, Conjuring, Furious 7. E claro o novo filme Shazam também parece muito promissor no trailer, com David Sandberg também tendo filmes de horror no currículo, como o último Annabelle: Creation e Lights out. Eu definitivamente não sou fã de filmes de horror, pelo fato de que 99% são muito mal feitos. Mas Wan e Sandberg eu mantenho na minha lista de interesse. Aliás, significa também que em 2019 vamos ter 2 filmes de Capitães Marvel. O original que é Shazam e a Capitã Marvel, da Marvel.

Isso tudo dito, o que fazer com Justice League? Aqui vem a graça do YouTube. Muita gente já tentou ajustar o filme de alguma forma, mas o que eu mais gostei até agora é a recente série do canal Nando v Movies. Uma das melhores coisas que o Nando faz no canal é reimaginar a história de filmes. Em particular eu gosto como ele se atém à fundação da arte de escrever um screenplay. Até o momento em que estou gravando este episódio ele lançou 3 vídeos da série “Justice League Rewrite”. Ele está se atendo em dividir a história nos 3 atos clássicos. E dando mais atenção ao 2o ato, que ele dividiu em 2 partes, tradicionalmente chamados de 2A e 2B separado pelo que chamam de “midpoint” o meio do filme. Por exemplo, o Nando lembra como os filmes da Marvel seguem exatamente essa estrutura e como eles tem midpoints muito bem definidos, em First Avenger, Steve Rogers salta do avião e se torna Capitão América exatamente no meio do filme, em Winter Soldier Steve Rogers e Natasha descobrem que a Hydra infiltrou a Shield e encontram Zola no meio do filme e assim por diante.

Esse cara é muito talentoso, a forma como ele explica as razões pra cada uma das mudanças, a forma como ele encaixa as peças no framework clássico de um bom filme, e como tudo faz sentido, faz você assistir essa nova versão na cabeça como se fosse um filme de verdade. O cara é assim bom. Pra dar um gosto, um dos maiores problemas da história é Steppenwolf, que é um dos vilões mais fracos de todos os filmes de heróis ever. Então ele faz um twist, ele inicia com a Liga dos Vilões, trazendo Clayface, Deathstroke, Copperhead, Weather Wizard e cria um sub-arco no 1o ato que vai ligar no twist do novo midpoint. E à medida que ele reajusta a história também reajusta o relacionamento dos personagens, criando uma das coisas que falta no filme de verdade: uma conexão entre todos os membros da Liga. Por exemplo, copiando o graphic novel de Frank Miller eles colocam vários easter eggs na batcaverna, incluindo o uniforme do 2o Robin, provavelmente, Jason Todd. Mas eles não aproveitam o medo de Bruce em trazer pra equipe um moleque como o atual Flash, Barry Allen e não explorar o trauma de poder repetir o que aconteceu com Robin de novo. Nando corrige isso na sua versão.

Falando no Flash, me lembrou um video essay de outro canal, o HiTop Films que ainda tá no começo mas eles fazem análises muito boas de pontos específicos em alguns filmes, em particular um de 6 meses atrás onde eles comparam a introdução e recrutamento do Flash em Justice League comparado com uma cena muito similar em Civil War onde o Stark vai recrutar o Peter Parker, no que é a primeira aparição do homem aranha no universo marvel atual. Colocando lado a lado é gritante como as cenas são idênticas mas porque o da Marvel é eficaz e o da DC perde a oportunidade.

Dêem uma olhada na versão do Nando e mandem nos comentários o que acharam das mudanças que ele fez. E se vocês conhecem algum YouTuber que imaginou uma versão ainda melhor, também mandem pra eu ver.

Não tem coisa mais divertida pra um geek do que reimaginar as coisas. Acho que uma das coisas que separam os geeks dos não-geeks é que a maioria das pessoas assiste filmes mas não pensa muito a respeito, são aquelas 2 horas, dá uma risada e amanhã já era. A gente que é geek é estranho mesmo, anos depois ainda estamos falando em detalhes dos filmes, defeitos técnicos, cenas deletadas, histórias dos bastidores, versões alternativas. Mas essa é a parte que eu acho mais divertido.

E aí, gostaram desse vídeo? Discutam os temas de hoje nos comentários abaixo. Mandem um joinha, assinem o canal e não deixem de clicar no sininho pra não perder os próximos episódios. A gente se vê na próxima, até mais.

Quando decidi voltar do macOS para o Linux, não queria simplesmente retornar ao velho Ubuntu (sim, fico entediado fazendo as mesmas coisas por tempo demais). Então experimentei o Fedora 25 e fiquei impressionado com a evolução do Gnome 3.22.

Comparado ao Ubuntu, os padrões do Fedora pareciam melhores. Na prática, dá para forçar qualquer distro a ser o que você quiser, mas prefiro não brigar com os padrões. O Ubuntu é fortemente customizado para o Unity e eu realmente, realmente não gosto. Parece mais um brinquedo do que um ambiente sério para trabalhar.

O Fedora 25 fica bonito com o Gnome 3, mas ainda me deu algumas dores de cabeça. Uma coisa que não funcionou de jeito nenhum foi o Gnome Online Accounts. O GOA coleta tokens de autenticação depois que você faz login nos seus serviços sociais como o Google. Aí aplicativos compatíveis como Evolution e o Calendário integrado conseguem usá-los. Mas os tokens expiravam o tempo todo, então a integração era inútil. E configurar o Evolution manualmente para o Google não é nada agradável.

A surpresa: no Arch Linux, escolhi o Gnome 3.22 como desktop e instalei manualmente o pacote gnome-online-accounts. Fiz login nas minhas contas Google e posso afirmar com satisfação que os tokens não expiram e tudo “simplesmente funciona”! É esse tipo de polimento que espero de uma distro grande, não a roubada que o Fedora rotula como “estável”.

Por que Arch Linux?

A maioria das distros importantes se divide entre “estável” (mas com pacotes muito antigos) e “instável” (mas com o que há de mais recente). Se você instala as versões Long-Term Support (LTS), está condenado a ter só pacotes velhos de alguns anos atrás. Se instala os repositórios instáveis, está condenado a ter coisas explodindo na sua cara sem explicação e perdendo horas garimpando no Stackoverflow.

O Arch parece ter encontrado o nível exato de equilíbrio entre estável e cutting-edge. Ele continua empurrando as versões mais recentes dos softwares sem quebrar tudo o mais o tempo todo. No Ubuntu 16.04 e no Fedora 25, se eu quero instalar o Postgresql, fico preso no 9.4 ou 9.5, mas no Arch consigo acessar o 9.6 direto dos repositórios principais do Pacman. (A propósito, “Pac"kage “Man"ager é o nome mais óbvio possível.)

É só fazer pacman -Sy postgresql e pronto.

E se você está no Ubuntu 14.04 e agora quer o 16.04, boa sorte fazendo dist-upgrade. É mais fácil começar do zero.

A filosofia do Arch parece ser ter a versão mais recente de verdade de todo software sem quebrar o sistema. Não existe aquele upgrade big bang a cada 6 meses que quebra tudo. Em vez disso, você tem um sistema de upgrade rolling constante, sempre na última versão, sem precisar esperar mais um ano pelo próximo LTS grande.

Toda distro grande tem repositórios “não suportados” para binários proprietários (codecs, por exemplo) ou software de terceiros. No Arch existe o Arch User Repository (AUR): uma coleção de pequenos repositórios Git de usuários que mantêm simples arquivos de texto PKGBUILD.

O AUR é inteligente. Se você vem do macOS e conhece o Homebrew, vai entender na hora: parece Casks e Formulas. Um arquivo PKGBUILD pode descrever uma receita para baixar um pacote DEB ou tarball disponível, desmontá-lo e reconstruí-lo como um pacote compatível com o Pacman. Ele pode descrever as dependências necessárias e tornar o processo de instalação extremamente tranquilo.

Por exemplo, o Sublime Text só tem a opção de baixar um pacote DEB ou um tarball com os binários. O mesmo vale para Spotify, Franz, etc. Às vezes dá para registrar Personal Package Archives (PPAs) e instalar via apt-get. Mas você ainda precisa que alguém construa, mantenha e distribua esses pacotes direito. Dá muito trabalho.

Manter um repositório Git simples com um arquivo PKGBUILD simples é muito mais fácil. O makepkg faz o trabalho pesado de construir o pacote que você precisa, na sua máquina, e então o pacman cuida de instalá-lo como qualquer outro pacote. Chega de ficar baixando tarballs com wget e configurando tudo na mão!

Talvez eu finalmente consiga só fazer pacman -Syu e ter tudo “de verdade” atualizado sem precisar me preocupar com o próximo LTS grande que eventualmente vai me forçar a reinstalar tudo do zero.

Arch Linux é perfeito para “Iniciantes”

Faz um bom tempo que ouço falar do Arch e seus usuários são muito entusiastas em tentar convencer outras pessoas a aderir. Quando você vê uma base de fãs tão leal assim, alguma coisa interessante deve estar escondida por baixo. Upgrades rolling, Pacman, AUR são razões realmente valiosas.

Depois de apenas um dia usando, percebi que o Arch é bom para usuários avançados, mas também para iniciantes. Não porque é fácil. Pelo contrário: porque é difícil do jeito certo.

A maioria dos “usuários Linux” hoje em dia só pega uma distro trivial de instalar, como Ubuntu ou Elementary, e não faz ideia do que acontece por baixo. Ficam clicando cegamente em “próximo” nos instaladores gráficos.

A maioria das pessoas não sabe o que são TTYs. Que você pode sondar dispositivos USB com ferramentas de linha de comando como lsusb, ou que precisa usar ferramentas como fdisk para particionar e depois mkfs.ext4 para formatar. Que arquivos de swap de memória são partições com um formato especial. Não conhecem as opções de LVM para particionamento flexível, nem que o LVM existe. Que o “negócio” que você escolhe o kernel no menu de boot se chama Grub e que dá para tunear.

Montar uma distribuição Linux completamente funcional tem muito envolvido. Mas os instaladores gráficos escondem a maior parte. O Arch Linux te força a ir passo a passo e realmente sentir que você é dono da sua máquina, e não o contrário.

Se você é um “iniciante”, eu realmente te encorajo a instalar uma distro como o Arch algumas vezes, em diferentes configurações de máquinas, para entender de verdade como um sistema operacional funciona.

A Arch Wiki é um repositório de informações muito abrangente e detalhado sobre tudo que você precisa saber para instalar e manter cada componente de um sistema Linux adequado. Você vai aprender muito no processo.

Mas se você é como eu, e passou por tudo isso em meados dos anos 90 e início dos 2000 (puxa, eu tive que aprender Slackware 1.0 na marra, ainda me lembro de usar disquetes de boot e root e estragar meus HDs sem entender cilindros e setores no fdisk), pode pular essa parte. Para você, usuário avançado/experiente, eu recomendo o Arch Linux Anywhere.

Ele instala o Arch de forma customizada mas com automação suficiente para não desperdiçar muito tempo em ter uma instalação Arch devidamente configurada e funcionando, sem bloatware.

Pacaur - a melhor forma de lidar com o AUR

Os usuários de Arch são rápidos em elogiar o Pacman. Na maior parte do tempo, você basicamente faz:

sudo pacman -S chromium

E é isso. Depois pode fazer sudo pacman -Syu para atualizar os pacotes instalados. Esse é o básico que você precisa saber.

Se você é desenvolvedor, recomendo instalar também os pacotes de desenvolvimento básicos:

sudo pacman -Sy --needed base-devel

Você pode instalar pacotes do AUR manualmente. Pode ir ao site deles e buscar por “terminix” (um substituto bem interessante para o Terminal, parecido com o iTerm2 do Mac), por exemplo. Vai chegar a esta página e precisará fazer manualmente o seguinte:

git clone https://github.com/gnunn1/terminix.git
cd terminix
makepkg -si

Parece simples, mas dá para fazer melhor instalando o Pacaur, um wrapper em cima do Pacman. Se você estiver usando um terminal gráfico como Terminal ou Terminix, NÃO ESQUEÇA de editar o perfil para “Run command as login shell”, caso contrário haverá um problema de PATH e o Cower vai falhar na instalação.

sudo pacman -S expac yajl --noconfirm
gpg --recv-keys --keyserver hkp://pgp.mit.edu 1EB2638FF56C0C53
git clone https://aur.archlinux.org/cower.git
cd cower
makepkg -si
cd ..
git clone https://aur.archlinux.org/pacaur.git
cd pacaur
makepkg -si
cd ..

Em resumo, o Pacaur pode ser usado não só como complemento para instalar pacotes do AUR, mas também se você quiser usar uma única ferramenta para gerenciar tanto o AUR quanto os pacotes oficiais do Pacman. Todos os comandos -S são comandos do Pacman. Então em vez de fazer sudo pacman -Syu para atualizar todos os pacotes, você pode substituir por pacaur -Syu. Todo o resto basicamente “funciona”.

Quando você tenta instalar um pacote com -S, ele primeiro procura nos repositórios oficiais; se não encontrar, tenta o AUR. Tem até uma GUI bem bacana se quiser:

pacaur -S pamac-pacaur

Para instalar o mesmo Terminix agora, basta fazer:

pacaur -Sy terminix

Ele vai fazer perguntas simples de sim/não como “Quer editar o arquivo de build?” Responda “n” para essas e confirme “y” quando perguntar se quer instalar as dependências ou o pacote gerado.

E é isso! Você pode buscar nos repositórios do AUR com:

pacaur -s spotify

Vai te dar várias opções, por exemplo:

$ pacaur -s spotify
aur/spotify 1.0.47.13-1 (1037, 36.09) [installed]
    A proprietary music streaming service
aur/playerctl 0.5.0-1 (127, 11.33)
    mpris media player controller and lib for spotify, vlc, audacious, bmp, xmms2, and others.
aur/blockify 3.6.3-3 (106, 5.61)
    Mutes Spotify advertisements.
...

Bom senso, pessoal. Leia, interprete, escolha. O Arch exige que você seja uma pessoa inteligente, e por “inteligente” quero dizer: que sabe ler! A maioria das pessoas pula a leitura e fica clicando em tudo como idiota.

Agora que você sabe o nome exato do pacote que quer, instale normalmente assim:

pacaur -S spotify

O Pacaur é um dos muitos AUR Helpers. Inicialmente fui atraído pelo Yaourt, mas depois de pesquisar, você percebe que deve experimentar apenas aurutils, bauerbill ou pacaur. Prefiro este último porque é mais fácil de falar.

pacaur -Syua

Isso mantém o seu sistema atualizado, tanto os pacotes oficiais quanto os do AUR.

Asdf - o último gerenciador de versões de linguagens que você vai precisar

Se você é Rubyist, conhece RVM, rbenv, chruby. Se vem do Node.js, conhece o NVM inspirado no RVM para gerenciar diferentes versões do Node. Cada nova linguagem hoje em dia precisa de um gerenciador de versões porque evoluem rapidamente e porque se você trabalha com projetos de clientes vai eventualmente precisar usar uma versão antiga para lidar com software legado.

Então, mesmo que você possa instalar o Ruby 2.3.3 estável atual só fazendo pacman -S ruby ou pacaur -S ruby, vai eventualmente precisar voltar para Ruby 2.1 ou mais antigo para algum projeto de cliente.

Instala RVM? Ou rbenv? E como lidar com diferentes versões de Clojure, Go, Rust, Elixir?

Isso soa como mais um pesadelo de manutenção para encarar. Mas alguém decidiu resolver esse problema de forma elegante. Entra o asdf - e se você por acaso conhecer Akash Manohar, dê um abraço nele.

Vamos instalá-lo (do README do projeto):

git clone https://github.com/asdf-vm/asdf.git ~/.asdf --branch v0.2.1

Depois edite seus arquivos de configuração de shell:

# Para Ubuntu ou outras distros Linux
echo -e '\n. $HOME/.asdf/asdf.sh' >> ~/.bashrc
echo -e '\n. $HOME/.asdf/completions/asdf.bash' >> ~/.bashrc

# OU para Mac OSX
echo -e '\n. $HOME/.asdf/asdf.sh' >> ~/.bash_profile
echo -e '\n. $HOME/.asdf/completions/asdf.bash' >> ~/.bash_profile

# Para o Fish shell
echo 'source ~/.asdf/asdf.fish' >> ~/.config/fish/config.fish
mkdir -p ~/.config/fish/completions; and cp ~/.asdf/completions/asdf.fish ~/.config/fish/completions

# Se, como eu, você gosta de ZSH com YADR (precisa instalar o YADR antes disso)
touch ~/.zsh.after/asdf.zsh
echo -e '\n. $HOME/.asdf/asdf.sh' >> ~/.zsh.after/asdf.zsh
echo -e '\n. $HOME/.asdf/completions/asdf.bash' >> ~/.zsh.after/asdf.zsh

Essa ferramenta é bem auto-explicativa. Vamos começar instalando um monte de plugins (tabela completa de links no arquivo README):

asdf plugin-add clojure https://github.com/vic/asdf-clojure.git
asdf plugin-add elixir https://github.com/asdf-vm/asdf-elixir.git
asdf plugin-add erlang https://github.com/asdf-vm/asdf-erlang.git
asdf plugin-add golang https://github.com/kennyp/asdf-golang.git
asdf plugin-add ruby https://github.com/asdf-vm/asdf-ruby.git
asdf plugin-add rust https://github.com/code-lever/asdf-rust.git
asdf plugin-add nodejs https://github.com/asdf-vm/asdf-nodejs.git

Se você é como eu, deve estar super animado porque já sabe o que vamos fazer a seguir:

sudo pacman -Sy jdk8-openjdk # precisa de Java para Clojure

asdf install clojure 1.8.0
asdf global clojure 1.8.0
mkdir ~/bin
wget https://raw.githubusercontent.com/technomancy/leiningen/stable/bin/lein -O ~/bin/lein
chmod +x ~/bin/lein
export PATH=$PATH:~/bin
# echo "PATH=$PATH" > ~/.zsh.after/binpath.zsh # se usar YADR+ZSH
lein

asdf install erlang 19.0
asdf global erlang 19.0

asdf install elixir 1.4.0
asdf global elixir 1.4.0
mix local.hex
mix local.rebar

asdf install golang 1.7.4
asdf global golang 1.7.4

asdf install ruby 2.4.0
asdf global ruby 2.4.0
gem install bundler

asdf install rust 1.14.0
asdf global rust 1.14.0

asdf install nodejs 7.4.0
asdf global nodejs 7.4.0
npm -g install brunch phantomjs

Pronto! Agora temos todas as linguagens que precisamos instaladas e prontas para uso! E se eu precisar do Ruby 2.3.1 para um projeto de cliente?

asdf install ruby 2.3.1
asdf local ruby 2.3.1

E agora tenho o 2.3.1 localmente (posso mudar para o padrão do sistema usando global).

A maior parte do esforço de manutenção se resume a isso:

asdf plugin-update --all # atualiza os plugins individuais
asdf list-all [linguagem] # lista todas as versões disponíveis

E é basicamente isso! Você tem quase tudo que precisa para desenvolver software.

Software Útil para Instalar

Agora, como de costume, deixa eu recomendar alguns softwares:

# garanta que está atualizado
sudo pacman -Syu

# instale codecs multimídia
sudo pacman -Sy gstreamer0.10-plugins
sudo pacman -Sy exfat-utils fuse-exfat a52dec faac faad2 flac jasper lame libdca libdv gst-libav libmad libmpeg2 libtheora libvorbis libxv wavpack x264 xvidcore gstreamer0.10-plugins flashplugin libdvdcss libdvdread libdvdnav gecko-mediaplayer dvd+rw-tools dvdauthor dvgrab pulseaudio-equalizer-

# se precisar de fontes japonesas como eu
sudo pacman -Sy adobe-source-han-sans-otc-fonts otf-ipafont

# alguns componentes que você vai precisar
sudo pacman -Sy fuse-exfat 

# gosto do tema Numix e ícones Breeze, mude-os com o Tweak Tool
sudo pacman -Sy numix-themes breeze-icons 

# instale mais fontes com boa aparência
sudo pacman -Sy ttf-dejavu 
pacaur -S ttf-ms-fonts ttf-vista-fonts ttf-liberation adobe-source-sans-pro-fonts ttf-ubuntu-font-family

# Firefox e plugin Java
sudo pacman -Sy icedtea-web firefox

# para devs
sudo pacman -Sy zsh the_silver_searcher gvim imagemagick htop
pacaur -Sy ttf-hack

# Wrapper nativo para apps Web como Slack, Hangout, etc
pacaur -Sy franz-bin

# Melhor cliente nativo de Twitter para Linux
pacaur -Sy corebird

# Dispensa explicação
pacaur -Sy spotify
pacaur -Sy sublime-text-dev # instale estes plugins http://www.hongkiat.com/blog/sublime-text-plugins/

# Se você gosta de ler RSS
pacaur -Sy feedreader-beta

# se precisar de suporte tipo Office
sudo pacman -Sy libreoffice-fresh

# se precisar de suporte tipo Photoshop
sudo pacman -Sy gimp
sh -c "$(curl -fsSL https://raw.githubusercontent.com/doctormo/GimpPs/master/tools/install.sh)"

# se quiser um editor de vídeo realmente bom
sudo pacman -Sy frei0r-plugins dvdauthor vlc
pacaur -Sy kdenlive

# isso pode fazer softwares que consomem muito CPU se comportarem melhor e garantir melhor experiência de uso
pacaur -Sy ananicy-git

# dropbox é o software mais horrível do mundo, mas pode ser que você precise:
pacaur -Sy dropbox dropbox-cli nautilus-dropbox

Como sempre, gosto de substituir o Bash pelo Zsh e configurar o Vim com YADR:

sh -c "`curl -fsSL https://raw.githubusercontent.com/skwp/dotfiles/master/install.sh`"
touch ~/.vimrc.before
touch ~/.vimrc.after
echo "let g:yadr_using_unsolarized_terminal = 1" >> ~/.vimrc.before
echo "let g:yadr_disable_solarized_enhancements = 1" >> ~/.vimrc.after
echo "colorscheme gruvbox" >> ~/.vimrc.after

Para instalar e configurar o Postgresql 9.6:

sudo pacman -Sy postgresql
sudo -u postgres -i
initdb --locale $LANG -E UTF8 -D '/var/lib/postgres/data'
exit

# não faça isso em máquinas de Produção
sudo sed -i.bak 's/ident/trust/' /var/lib/postgres/data/pg_hba.conf
sudo systemctl start postgresql
sudo systemctl enable postgresql

sudo -u postgres -i
createuser --interactive # crie com seu nome de usuário e papel de superuser
createdb youruser
exit
sudo systemctl restart postgresql

Se quiser instalar o Docker:

sudo pacman -Sy docker
sudo usermod -aG docker $USER
sudo systemctl start docker
sudo systemctl enable docker
logout

Sempre precisamos de Redis, Memcached, então vamos instalá-los:

sudo pacman -Sy redis memcached
sudo systemctl start redis
sudo systemctl enable redis
sudo systemctl start memcached
sudo systemctl enable memcached

Depois de instalar e remover muito software, você pode acabar com pacotes desnecessários ocupando espaço em disco. Dá para limpar com:

sudo pacman -Rns $(pacman -Qtdq)

E como disse antes, a Arch Wiki é super útil para continuar ajustando o sistema, então leia artigos como esta página “Improving Performance”.

Kernels para Desktop

Uma coisa importante sobre a maioria das distros Linux é que o kernel geralmente é compilado para ser mais otimizado para Servidores.

Hardware moderno, especialmente com bastante RAM e equipado com SSD, “deveria” funcionar bem o suficiente. Mas nem sempre: você pode ter alguns “engasgos” ou até total falta de resposta.

Há muitas razões, mas os 2 principais culpados são a memória da aplicação sendo paginada para o swap em disco e o escalonador de I/O do kernel Linux.

Num cenário de servidor, você quer que os processos tenham uma fatia justa dos recursos, por isso um escalonador de processos como o CFS - Completely Fair Scheduler - e o CFQ - Complete Fairness Queueing - para I/O, são fantásticos.

Mas no Desktop a história é completamente diferente. Você está disposto a trocar alto throughput por baixa latência para ter responsividade. Ninguém quer ter a UI e o ponteiro do mouse congelados enquanto copia arquivos grandes para drives USB, ou enquanto espera aquele terrível make -j9 terminar de compilar o seu igualmente terrível gcc-gcj. Pode terminar com a UI congelada por horas! Simplesmente inaceitável!

O que você quer para uso em Desktop, com dezenas de processos aleatórios fazendo operações aleatórias, é uma configuração quase de “soft real time”. Uma preempção mais agressiva onde o Kernel devolve algum controle para a UI para que você possa fazer outras coisas - embora mais devagar. Baixa latência é a chave para uma experiência de usuário fluida.

Para aumentar a responsividade, a primeira e mais importante coisa a fazer é configurar isto:

sudo tee -a /etc/sysctl.d/99-sysctl.conf <<-EOF
vm.swappiness=1
vm.vfs_cache_pressure=50
vm.dirty_background_bytes=16777216
vm.dirty_bytes=50331648
EOF

Reinicie. Se quiser saber o que são essas configurações, leia isto.

Você pode querer instalar um Kernel customizado com um Scheduler diferente. Existem 3 opções atualmente: Zen, Liquorix e CK.

Ainda não tenho 100% de certeza sobre qual é o melhor; todos têm algumas preocupações de manutenção.

Dos 3, você vai querer ficar com o Zen (que é basicamente o Liquorix), pois é mantido nos repositórios oficiais em formato binário (acredite, você não quer esperar um kernel customizado compilar, leva uma eternidade).

sudo pacman -Sy linux-zen
sudo grub-mkconfig -o /boot/grub/grub.cfg

Reinicie.

A principal mudança é provavelmente o I/O Scheduler, passando do CFQ padrão para o BFQ. Se você usa HD mecânico vai querer usar o BFQ melhorado (que o Zen habilita por padrão). Se usa SSD vai querer ‘deadline’ em vez disso.

NÃO INSTALE ESSES KERNELS EM SERVIDORES DE PRODUÇÃO! Eles são destinados apenas ao uso em desktop!

De modo geral, o Zen pode ter o melhor equilíbrio entre estabilidade e conjunto de ajustes. Vale usá-lo, especialmente em hardware mais antigo. Hardware moderno, como disse, pode não notar muita diferença.

Conclusão

Não sei se são os mantenedores do Arch que estão fazendo um trabalho excelente ou se são a RedHat e a Canonical que estão estragando tanto as distros deles em comparação.

Quer dizer, Ubuntu, Fedora, OpenSuse, Elementary são todas distros decentes que, na maioria das vezes, “simplesmente funcionam”.

Mas para uma distro que muitos consideram voltada a “usuários avançados”, o Arch é muito mais polido. Não consigo entender o porquê.

No mesmo hardware, a experiência com o Gnome 3 no Arch é visivelmente melhor do que o mesmo Gnome 3 no Fedora. Comparado ao Unity no Ubuntu, está milhas à frente. É rápido, fluido, com boa aparência, e os padrões todos funcionam bem.

E de repente percebo que não preciso mais me preocupar com grandes atualizações. Os upgrades rolling contínuos para o mais recente me trazem mais uma camada de confiança.

O Arch me faz sentir que estou no controle novamente sem exigir que eu perca horas ajustando coisas ao meu gosto. Os padrões são sólidos e consigo fazer pequenas melhorias quando preciso.

Parabéns aos mantenedores do Arch: esta é a melhor distro Linux que já tive o prazer de usar. Espero que essa sensação continue enquanto eu a usar como meu sistema principal. Mas até agora estou convencido de que esta é a escolha certa.

Meu time, meus clientes, todos nós usamos Slack felizes por mais de 2 anos, como acredito que muitos times pelo mundo também usaram. Apesar de ninguém nunca ter reclamado, eu sempre me incomodava com pequenos detalhes. Em primeiro lugar, como tudo que tem valor, custa. Ou pago USD 6.67/mês/usuário, ou aceito as restrições do plano gratuito. E, como a maioria dos outros times, fui levando com as restrições enquanto deu.

Por exemplo, para me livrar dos avisos para fazer upgrade porque batemos no limite de uploads, criei uma pequena ferramenta chamada slack_cleanup (primeiro em Elixir e depois em Crystal, só por exercício). Isso ajudou por um tempo.

Nosso time foi crescendo, de forma constante e frequente, assim como os clientes. Quanto mais usuários adicionamos, mais conversas, mais rápido batemos nas restrições. Histórico se perde com mais frequência, precisamos limpar uploads com mais frequência. Isso cansa muito rápido.

Uma coisa que valorizo acima de tudo é conhecimento. Como pequeno exemplo, eu mesmo mantenho múltiplos backups de todos os meus emails, todos os meus projetos, todos os assets que produzi nos últimos 20 anos. Caramba, tenho um sistema Drobo de 6 TB em Raid-5 bem na minha mesa de casa e mais 3 HDs externos de 1TB para backup. Perdi muito pouco ao longo dos anos.

Realmente me incomoda quando perco informação.

• Gmail Business, DropBox, buckets do AWS S3, por serem serviços externos, não me preocupam, pois mantenho cópias de tudo offline. Então, se essas contas forem comprometidas de uma hora para outra, tenho múltiplas cópias.

• GitHub me incomodava um pouco porque, embora eu tenha múltiplas cópias dos repositórios, perderia todo o histórico de Pull Requests e Issues. Esse é um dos motivos pelos quais migrei para o meu próprio GitLab e ajudei a ajustar o processo de import para puxar esse histórico de Pull Requests.

• O Slack me incomoda muito pelos motivos já mencionados, e por isso na semana passada testamos primeiro o MatterMost e depois subimos o Rocket.chat.

There, and Back Again

Saímos do Slack para o Rocket.chat e, alguns dias depois, estamos migrando de novo, agora para o Mattermost.

Sim, isso foi trabalhoso. Meu time não ficou muito feliz em deixar o Slack. O Slack é realmente elegante, completo, bonito, redondinho, um produto web de verdade para esta geração. Qualquer alternativa precisa ser pelo menos quase tão bonita e ter funcionalidades sem bugs, incluindo webhooks.

O Mattermost atende quase perfeitamente, mas a Team Edition open source carecia de uma funcionalidade importante para mim: a possibilidade de impedir que membros comuns renomeiem e/ou apaguem grupos privados. Sim, esperamos que adultos se comportem, mas quando você tem times remotos, clientes remotos, usuários externos sem nenhum compromisso com a empresa, isso vira uma dor de cabeça.

Sim, eu poderia, e provavelmente deveria, usar a Enterprise Edition paga. Mas só por essa pequena funcionalidade, achei caro demais. Isso me motivou a deixar pra lá e instalar o Rocket.chat. Movi todo o meu time pra lá (quase 50 pessoas, porque ainda não migrei os clientes). Esse seria o fim da história.

Mas o Rocket.chat tem uma infraestrutura complexa para lidar (você precisa ter no mínimo 3 máquinas, ou pagar a mais por um SaaS de Mongodb decente). Aliás, no meu post anterior expliquei por que vocês, pessoal de MEAN, não devem ser desleixados ao lidar com Mongodb. Resumindo: Mongodb não foi pensado para rodar em uma única instância, você precisa ter um replica set. Se você tem um Mongodb em instância única, está fazendo errado.

E o mais problemático: o client-side é simplesmente pesado demais. Frequentemente faz a CPU disparar em máquinas não tão potentes. É notavelmente, e mensuravelmente, mais lento de navegar na UI, comparado ao Slack. A UI do MatterMost era muito mais rápida e muito mais responsiva.

Eu estava quase disposto a relevar a falta de uma suíte de testes decente. Estava disposto a tentar conviver com Meteor e CoffeeScript. Estava disposto a lidar com a manutenção complexa do MongoDB.

Mas a lentidão na resposta atingindo vários membros do meu time é um show-stopper, um problema gigante. Desligamos a feature beta de videochat (já que ela sempre dispara picos de CPU em todos os usuários), mas vários membros ainda tinham uma experiência ruim com uma UI lenta demais e devoradora de recursos.

O MatterMost, baseado em React, escrito em ES6, devidamente estruturado, com suítes de teste client-side suficientemente boas, era um candidato mais adequado. Então decidi pensar de verdade no problema original e cheguei a uma solução simples: adicionar uma função PLPGSQL simples para ser disparada sempre que alguém tentasse apagar um canal. Funcionou direitinho. E isso me motivou a chamar meu time de novo e propor essa nova mudança: acredito que todo mundo embarcou, já que o MatterMost estava muito mais rápido nas máquinas deles.

Sei que estou soando muito duro com o Rocket.chat, e essa não é minha intenção. Se não tivéssemos outras opções, ainda iríamos para o Rocket.chat. Mas como o Mattermost provou ser a melhor escolha, foi decisão fácil.

Instalação do MatterMost

Como sempre, não vou cansar você com instruções já disponíveis online. Se quiser instalar tudo manualmente, siga este tutorial, mas uma opção melhor seria o deployment via Docker. Você pode até instalar/atualizar junto com o GitLab.

Garanta que você tenha NGINX na frente do servidor e que tenha tanto um domínio ou subdomínio devidamente registrado, quanto SSL - use Let’s Encrypt.

Como quero continuar mexendo e experimentando com o codebase em uma instalação ativa, instalei tudo manualmente e tenho esta estrutura de diretórios:

-rw-r--r--  1 mattermost mattermost     6504 Aug 13 20:11 config.json
drwxrwxr-x  5 mattermost mattermost     4096 Aug 13 20:30 data
lrwxrwxrwx  1 mattermost mattermost       33 Aug 13 20:13 mattermost -> mattermost-team-3.3.0-linux-amd64
drwxr-xr-x  9 mattermost mattermost     4096 Aug 13 20:28 mattermost-team-3.2.0-linux-amd64
-rw-rw-r--  1 mattermost mattermost 19968308 Jul 14 16:37 mattermost-team-3.2.0-linux-amd64.tar.gz
drwxr-xr-x 11 mattermost mattermost     4096 Aug 13 20:28 mattermost-team-3.3.0-linux-amd64
-rw-rw-r--  1 mattermost mattermost 20241448 Aug 12 20:41 mattermost-team-3.3.0-linux-amd64.tar.gz
drwxrwxr-x  3 mattermost mattermost     4096 Aug 13 20:23 platform-dev-3.3.0
-rw-r--r--  1 mattermost mattermost 18060203 Aug 13 20:22 platform-dev.tar.gz

Tenho um usuário sudo restrito chamado mattermost e tenho um diretório principal mattermost apontando para os pacotes binários que você encontra na página oficial de download.

Note que tenho uma cópia de mattermost/config/config.json no diretório home. Deixo lá para que, toda vez que eu baixe uma nova versão e refaça o symlink para mattermost, eu possa simplesmente fazer:

rm -Rf ~/mattermost/config/config.json
cd ~/mattermost/config
ln -s ~/mattermost/config.json

Garanta também que você ajuste pelo menos o seguinte na config:

...
"FileSettings": {
    "MaxFileSize": 83886080,
    "DriverName": "local",
    "Directory": "/home/mattermost/data",
...

Se quiser, você pode mandar os uploads de arquivos para algum bucket S3 que você tenha, e só preencher os detalhes da AWS. Mas se escolher tê-los localmente, mude o diretório para algum lugar fora da pasta mattermost, já que a cada upgrade você vai trocar a pasta. Tanto com AWS EC2 quanto com Digital Ocean você sempre pode escolher adicionar um volume secundário que sobreviva às VMs, então mesmo se chegar a um ponto de ter centenas de usuários simultâneos e quiser escalar horizontalmente, pode ter todas as máquinas apontando para um volume compartilhado (AWS EFS, por exemplo).

Por falar nisso, nessa configuração, atualizar seria assim:

sudo service mattermost stop
wget https://releases.mattermost.com/x.y.z/mattermost-team-x.y.z-linux-amd64.tar.gz
tar xvfz mattermost-team-x.y.z-linux-amd64.tar.gz
mv mattermost mattermost-team-x.y.z-linux-amd64
ln -s mattermost-team-x.y.z-linux-amd64 mattermost
rm -Rf mattermost/config/config.json
rm -Rf mattermost/data
cd mattermost/config
ln -s ~/config.json
cd ..
ln -s ~/data
sudo service mattermost start

A razão de eu querer dessa forma é poder ajustar o código e empurrar as alterações manualmente.

Para sua máquina de desenvolvimento, você deve seguir estas instruções. Se você está em OS X e escolhe usar o Docker Toolbox, lembre que você não precisa mais do VirtualBox, pois ele vai usar o hypervisor nativo do OS X agora. Na minha máquina, tive que adicionar dockerhost manualmente no meu /etc/hosts porque o boot2docker estava falhando em obter meu IP.

Aí você pode simplesmente clonar o código do Github:

mkdir mattermost
cd mattermost
git clone https://github.com/mattermost/platform
git checkout -b v3.3.0 v3.3.0

Lembre-se de sempre fazer checkout da versão estável correta (v3.3.0 na época em que postei este artigo originalmente) que você tem instalada no seu servidor. De novo, não vou cansar você com o que já está documentado nos links acima, mas você precisa ter Go 1.6(.3), Docker, Docker-Composer, Docker-Machine, tudo já instalado.

Você pode executar make run e, depois que terminar (e, como sempre, o npm vai garantir que isso demore muito), pode abrir http://localhost:8065 para brincar localmente.

Mais importante: você pode mexer nos componentes JSX do React em platform/webapp/components, por exemplo, no channel_header.jsx, e adicionar coisas assim:

// linha 493 da v3.3.0
if(isAdmin || isSystemAdmin) {
    dropdownContents.push(
        <li
            key='rename_channel'
            role='presentation'
        >
            <a
                role='menuitem'
                href='#'
                onClick={this.showRenameChannelModal}
            >
                <FormattedMessage
                    id='channel_header.rename'
                    defaultMessage='Rename {term}...'
                    values={{
                        term: (channelTerm)
                    }}
                />
            </a>
        </li>
    );

    if (!ChannelStore.isDefault(channel)) {
        dropdownContents.push(deleteOption);
    }
}

E sabe o que isso faz? Remove as opções “Rename Group” e “Delete Group” do menu do canal se o usuário não for um system admin. Agora, como colocar isso no seu servidor?

Antes de mais nada, você tem que editar o Makefile nesta seção:

@# Make osx package
@# Copy binary
cp $(GOPATH)/bin/darwin_amd64/platform $(DIST_PATH)/bin
@# Package
tar -C dist -czf $(DIST_PATH)-$(BUILD_TYPE_NAME)-osx-amd64.tar.gz mattermost
@# Cleanup
rm -f $(DIST_PATH)/bin/platform

@# Make windows package
@# Copy binary
cp $(GOPATH)/bin/windows_amd64/platform.exe $(DIST_PATH)/bin
@# Package
tar -C dist -czf $(DIST_PATH)-$(BUILD_TYPE_NAME)-windows-amd64.tar.gz mattermost
@# Cleanup
rm -f $(DIST_PATH)/bin/platform.exe

@# Make linux package
@# Copy binary
cp $(GOPATH)/bin/platform $(DIST_PATH)/bin
@# Package
tar -C dist -czf $(DIST_PATH)-$(BUILD_TYPE_NAME)-linux-amd64.tar.gz mattermost
@# Don't cleanup linux package so dev machines will have an unziped linux package avalilable
@#rm -f $(DIST_PATH)/bin/platform

Note que o desenvolvedor que fez esse arquivo provavelmente usa Linux. Isso porque esse arquivo gera o binário Linux-ELF como bin/platform, enquanto o binário OS X Mach-O fica em bin/darwin_amd64/platform. Agora, se como eu você está em OS X, tem que inverter isso e fazer a versão Linux apontar para bin/linux_amd64/platform, senão os pacotes vão ter o binário errado.

Aí você vai notar que existe esta seção bem no fim:

setup-mac:
    echo $$(boot2docker ip 2> /dev/null) dockerhost | sudo tee -a /etc/hosts

Se você está nas versões mais recentes do Docker-Toolbox, não precisa mais do boot2docker, ele vai usar o docker-machine. Então essa linha não funciona, e a forma mais fácil de fazer o make test rodar é trocar o dockerhost por localhost na configuração de PostgreSQL do config/config.json.

Se os testes estão todos passando, você pode rodar make package para gerar todos os pacotes, e então enviar o dist/mattermost-team-edition-linux-amd64.tar.gz para o seu servidor e descompactar no local correto.

Como nota pra noobs em Go como eu, eu tinha meu GOPATH apontando para /Users/akitaonrails/.go e meu projeto estava em /Users/akitaonrails/codeminer42/mattermost/platform. Me disseram que isso está incorreto e foi a fonte de muitas horas de frustração minha. O projeto PRECISA ESTAR DENTRO DO GOPATH.

Então mudei meu GOPATH para /Users/akitaonrails/Sites/go e o projeto para /Users/akitaonrails/Sites/go/src/github.com/mattermost/platform e agora funciona. Provavelmente eu também teria feito symlink do caminho do projeto para dentro do GOPATH. Mas agora tudo compila e roda direitinho.

É assim que vou continuar experimentando por enquanto, até me sentir confortável o suficiente para automatizar todo o processo depois. Isso deve funcionar bem para meu time por ora.

É claro, o snippet acima é apenas um dirty hack, não tente contribuir assim. Uma implementação adequada exigiria que eu pelo menos criasse uma nova configuração no config.json, por exemplo TeamSettings.MembersCanManageChannel como false, e mudasse o api/context.go por volta da linha 347 para algo como:

func (c *Context) HasPermissionsToTeam(teamId string, where string) bool {
    if c.IsSystemAdmin() {
        return true
    }

    if !utils.cfg.TeamSettings.MembersCanManageChannel {
        return false
    }
    ...

Depois mudar o componente webapp/channel_header.jsx no front-end React (junto com testes unitários decentes em webapp/tests/client_channel.test.jsx), garantir que o make test passa, e finalmente abrir um feature request para o core team.

Mas a ideia aqui era só mostrar que não foi tão difícil resolver o show-stopper para o meu cenário particular, tanto usando o trigger SQL para proteger o banco quanto o hack para arrumar a Web UI.

Conclusão

Mas e a feature mais importante de todas? Suporte a RightGIF? Ainda não existe nada tão simples quanto um comando rightgif do Slack. Felizmente, dá pra compensar a maior parte dessas pequenas faltas instalando um servidor Hubot, e ligando a um usuário para que você possa conversar com o bot e fazer ele fazer coisas pra você (programar um alarme, buscar um gif, traduzir texto, etc). Como ressalva, o adaptador do hubot exige o uso do mattermost-client, que precisa ser sincronizado com as releases da plataforma do servidor para funcionar direito, então tome cuidado ao atualizar.

No geral, o Mattermost é uma ótima escolha. Também não é para amadores; o ambiente de desenvolvimento exige que você domine seu Docker. Exige que você saiba configurar Go-lang direito. Exige que você siga os procedimentos adequados para contribuir, como deveria ser. O projeto em si é um único codebase dividido em aproximadamente 2 aplicações, uma API HTTP em Go e um front-end em React para consumir as APIs. Tudo no projeto é automatizado através do uso adequado de imagens Docker (para mysql, postgresql, instâncias openldap) e Makefiles para rodar a suíte de testes, criar pacotes, etc.

E ele tem algumas conveniências do Slack que o Rocket.chat ainda não tem, como um atalho simples para trocar de canal (Cmd-K), a capacidade de responder mensagens e organizá-las como threads, suporte a Markdown adequado e mais completo. No geral, as funcionalidades são redondas e bem acabadas. O que está lá é sólido e funciona; é sempre ruim ter funcionalidades pela metade.

Com esses hacks em mente, posso recomendar fortemente que você use Mattermost. E como já disse em posts anteriores, isso vai além de uma questão de custo. Se você é um time pequeno, sem desenvolvedores internos ou alguém que possa manter sua própria instalação, definitivamente deveria pagar pelo suporte Enterprise do Mattermost; é acessível e bem mais barato que o Slack.

Por enquanto, é a melhor escolha, tanto em termos de acabamento geral, funcionalidades completas, UI simples e responsiva, qualidade de código e o cuidado geral com a engenharia.

Uso o Pivotal Tracker desde 2010 até 2015, e isso porque eu acredito que ele é muito superior ao Trello e outras listas de tarefas glorificadas por aí.

O Dilema do Custo

Como em todos os outros relatos, vou começar pelo argumento do custo. O Pivotal Tracker tem preço baseado na quantidade de usuários.

Se você tem um time pequeno e poucos clientes externos, um plano básico de 10 usuários já resolve, e você vai pagar apenas USD 420 por ano. Simplesmente pague e pronto.

Se você tem até 25 usuários, ainda continua barato, e sai por USD 1.800 por ano. Vale muito a pena.

Mesmo se você tiver 50 usuários, o plano máximo, você vai pagar USD 3.600 por ano. Acima disso, precisa entrar em contato direto com eles.

O custo está longe de ser proibitivo e, se você puder pagar, meu conselho é que pague.

No meu caso, a estratégia é ter controle total sobre nossos dados e conhecimento, e por isso prefiro ter a propriedade do serviço.

E como o Fulcrum estava “quase” bom o suficiente, resolvi testar e ver se conseguíamos evoluí-lo com o tempo. Acredito que, mesmo estando ainda muito longe do Tracker completo, o que temos hoje já atende à maior parte dos nossos projetos.

Deixa eu repetir: provavelmente você não vai ganhar nada com isso se seu time for pequeno. O Pivotal Tracker continua sendo, até hoje, a melhor ferramenta de gestão de projetos para times de desenvolvimento de software, e você deveria testá-lo primeiro, se acostumar com o fluxo dele (como vou explicar abaixo), e só depois decidir se quer assumir o controle e instalar a alternativa open source.

Tem o fator custo, claro, mas ele não é o incentivo principal para essa mudança.

As Funcionalidades Importantes

Pesquisando um pouco, encontrei o projeto Fulcrum. É um projeto Rails muito simples, muito bare-bone, que imita as funcionalidades mais importantes do Tracker.

Qualquer ferramenta competente de gestão de projetos precisa ter, no mínimo, 4 pilares:

• Stories (com threads de discussão, upload de arquivos, tags, organização em Epics e busca)
• Estimativa numérica adequada (story points, tamanho proporcional para as stories)
• Sprints com time-box (períodos curtos e fixos de tempo)
• Velocity (a produtividade real de um determinado time em um determinado projeto)

Qualquer ferramenta que tenha todos os itens acima já é útil.

O próprio Fulcrum tem quase tudo. Fizemos um fork interno do projeto e começamos a adicionar algumas das funcionalidades que faltavam. Já estamos usando ele há mais ou menos 1 ano e tem sido bom o suficiente para nossa rotina. Ainda há alguns bugs e funcionalidades faltando que pretendemos incluir.

Se você se interessar, estou disponibilizando esse fork publicamente para cumprir a licença Affero GPL.

Qualquer contribuição é bem-vinda.

Sobre Gestão Ágil Adequada

Desviando um pouco do assunto, quero explicar por que esse tipo de ferramenta (no estilo Tracker) é a melhor opção quando comparada ao que chamei de “listas de tarefas glorificadas”.

Os princípios são muito simples:

• Todo projeto precisa começar com o backlog mais completo possível (a incerteza está no seu pico no começo, e vão faltar detalhes, mas é importante ter uma visão do que significa “minimamente completo” e a ordem de importância de cada story, uma “prioridade” adequada).
  • O nível de detalhe em si não importa. Uma story precisa ter informação suficiente para que qualquer desenvolvedor do time consiga implementar as tarefas necessárias. Caso contrário, ela deve ser marcada como “bloqueada”, para que o Product Owner saiba que precisa adicionar mais detalhes, e nenhum desenvolvedor encosta nela até que a tag seja removida.
• Todas as stories precisam ser estimadas (falo mais sobre isso na próxima seção). A unidade realmente não importa. Você pode pensar em horas, em frações de um dia ou no que ela realmente é: uma proporção. Uma story de tamanho “2” deveria ter aproximadamente metade da complexidade de uma story de tamanho “4”. É só isso. Até stories “bloqueadas” devem receber tamanho.
• Projetos precisam ser divididos em Sprints com tempo fixo e duração fixa, para que o time tenha a oportunidade de reavaliar frequentemente. É aqui que a estimativa pode ser refinada, onde mais níveis de detalhe nas stories devem ser exigidos.
• Bugs não podem ter estimativa numérica. Eles servem justamente para puxar a velocity do time para baixo, e são um indicativo de entregas mal feitas.
• Velocity é a quantidade real de story points entregues até o fim de uma Sprint.
  • O total de story points de todas as stories do backlog do projeto dividido pela velocity do time dá uma “Data de Término” estimada por alto. Isso é importante, porque é assim que você sabe quando determinados grupos de funcionalidades serão entregues ao longo do tempo, e é isso que o Product Owner precisa saber para priorizar stories, simplificar stories ou até cortar funcionalidades desnecessárias.
  • A única responsabilidade do Product Owner é prestar contas pelo Retorno sobre o Investimento das funcionalidades implementadas. E a única forma de medir custo-benefício é saber “quanto” uma funcionalidade vai “custar” em termos de story points divididos pela velocity.

O que a ferramenta vai expor:

• Se um backlog tem muitas stories “bloqueadas” ou muitas stories entregues sem aceitação, isso é sintoma de um Product Owner que não está fazendo o trabalho dele.
• Se a velocity varia demais entre sprints, isso é sintoma ou de stories mal escritas (e portanto desenvolvedores com dificuldade de entender o que fazer), ou de desenvolvedores sem concentração no trabalho e entregando resultados inconsistentes.
• Velocities inconsistentes com muitos bugs a cada sprint são sintoma de desenvolvedores que não estão fazendo código com qualidade adequada (testes automatizados para evitar regressões, por exemplo).
• Um “bug” não é a mesma coisa que o Product Owner mudar de ideia sobre uma story e rejeitá-la. O time não deve implementar mudanças não documentadas. A aceitação está amarrada ao que a story diz. O Product Owner precisa mudar de ideia antes da story ser implementada ou criar uma nova story para adicionar a mudança (e, portanto, adicionar mais custo ao projeto; não existe almoço grátis).
• Stories no “Chilly Bin” (no Fulcrum, ou “Ice Box” no Tracker) são “lista de desejos” e nunca serão implementadas até o Product Owner movê-las para o backlog.
• A velocity deveria ser aproximadamente a mesma entre sprints. Picos ou vales na velocity são sintoma de um problema que precisa ser atacado na próxima sprint. É assim que um projeto evolui para melhor ao longo do tempo.

Sobre Estimativa

Muita gente se preocupa demais com “estimativa correta” a ponto de criar tanta tensão que os desenvolvedores começam a gritar por “no estimates”. Isso é loucura. Por isso “estimativa” é uma palavra diferente de “previsão”: uma é incerta, um chute de grosso calibre, a outra é exata.

Não existe estimativa “correta”.

Eu diria que em muitos projetos, se as stories estiverem minimamente descritas (ou seja, um desenvolvedor consegue implementar o que está escrito), poderíamos estimar todas como tamanho “1” e esquecer disso.

Rodamos 2 ou 3 sprints (normalmente uma sprint deveria ser uma semana de trabalho - 5 dias de no máximo 8 horas, nem mais, nem menos) e medimos quantas stories foram entregues. E essa é a velocity.

Agora podemos ver quantas stories temos até o fim do projeto e dividir por essa velocity. E esse é o número de semanas que vamos levar para terminar o projeto.

Não há necessidade de estimativa por consenso.

Consenso em estimativas normalmente é desperdício de tempo. Estimativa é apenas a constatação de que é difícil escrever cada story no exatamente mesmo tamanho, e por isso adicionamos proporções a elas (uma story tamanho 2 é metade do tamanho de uma story tamanho 4).

Mas se um projeto tem 3 meses ou mais, menos as proporções importam (a menos que você caia na anti-prática de ter stories muito desproporcionais, algumas tamanho 1 e muitas tamanho 5, 8 ou até 10, por exemplo). Mas se você ficar abaixo de tamanho 5 para toda story, então quanto maior o projeto, menos as estimativas individuais importam. A velocity vai diluir as diferenças ao longo do tempo.

A tarefa do Project Manager, do Product Owner, do time em geral, é ficar de olho no total de pontos dividido por essa velocity, de onde sai a data estimada de término do projeto. E todos podem negociar, com antecedência, quais stories podem ser feitas, quais não podem, mudar prioridades, remover stories ou simplificar stories.

Não perca tempo tentando criar fórmulas para derivar consenso de estimativa.

Se você administra a Velocity, então você administra o projeto inteiro. Esse é o cerne de toda metodologia Ágil adequada. Todo o resto é acessório a essa finalidade.

Tentar aumentar a velocity artificialmente é um dos vários pecados. Você não consegue. É melhor investir tempo adicionando mais detalhes a uma story, ou simplificando uma story, ou decidindo que algumas stories simplesmente não são necessárias para entregar um produto decente no final.

Simulações de Monte Carlo, técnicas Six Sigma, conceitos de Kanban, nada disso importa. Todas as técnicas da indústria tradicional foram pensadas para linhas de produção de fábricas, onde o tempo de cada tarefa é bem definido e você administra a variância, a exceção. É um mundo Gaussiano, Normal.

Em projetos de software, ou qualquer trabalho artesanal e de pesquisa, você administra expectativas sobre resultados com base em marcos e cortando excessos e incertezas. É um mundo Pareto, onde não existe “média”, não existe meio, não existe variância.

Em um mundo Pareto, tudo está interconectado, e nada é estatisticamente independente (um requisito para Gaussianas). É portanto 80/20: onde 20% do projeto rende 80% dos resultados, onde 20% do escopo pode ser cortado.

Qualquer coisa que não seja “estatisticamente independente” (como jogar uma moeda) não pode ser tirada a média, não cabe em uma distribuição Normal. Provavelmente é uma Pareto, Power Law, Zipf, Exponencial, ou até uma Poisson, mas não uma Gaussiana. As partes de um software estão todas entrelaçadas em uma rede, elas não são eventos independentes, não podem ser reorganizadas aleatoriamente, elas não são facilmente intercambiáveis.

Conclusão

Este artigo é bem curto e eu posso expandir cada item acima em seu próprio artigo, bem longo. Me diz nos comentários se eu devo, e quais pontos levantam mais dúvidas.

Venho refinando essas técnicas ao longo dos últimos 10 anos, e pelo menos 5 deles dentro das restrições de uma ferramenta como o Tracker. E acredito que consegui chegar ao conjunto mínimo de princípios que levam a uma gestão adequada, longe de superstição, fantasia ou ilusão que você vê por aí hoje em dia.

Projetos sofrem quando as recomendações acima não são seguidas:

• Product Owners não cumprem suas responsabilidades: falham em adicionar detalhes às stories, negligenciam funcionalidades entregues e não as testam direito, não participam.
• Backlogs estão incompletos, com falta de detalhe, falta de estimativa, falta de priorização.
• Desenvolvedores não começam nem terminam suas tarefas direito, com qualidade de código adequada.
• Tempo é desperdiçado em bikeshedding em vez de entrega.

Nosso fork do Fulcrum, chamado “Central”, está longe de ser perfeito, mas funciona bem o suficiente e nos dá controle para continuar adicionando funcionalidades que tornam nossa rotina mais confortável, e estamos apenas começando.

Espero que essa técnica e essa ferramenta sejam úteis para mais times, e adoraria ouvir o feedback de quem se interessar.

In my previous post I forgot to mention minimal firewall and SSL configuration, but you can check it here.

One of the most difficult pieces to move away from is Slack. Don’t get me wrong, it’s a great tool and it gets the job done. The free-tier is really competent but I really want some of the payed features such as history of all conversations with search capabilities and uploads without limit.

The Cost Conundrum

But then you have to commit to pay USD 8/month per user (USD 6.67 if you pay ahead of time). If you’re a small team (around a dozen people) it’s well worth it and you should definitely pay and get over with.

If you have more than 20 people then it starts to become a conundrum. On my GitLab cost calculations, some people argued that saving USD 15k yearly is not such a big deal, and they’re not wrong.

If you’re from outside of the US coastal cities, specially from countries in South America, Asia where currency can be more than 3 times devalued, than it quickly starts to become a big deal.

Apart from that, we are currently offloading a whole lot of out IPs and knowledge into the care of companies we don’t really know and where we don’t hold any real stakes.

If you’re a medium to big company it really starts to make sense to want to have more control over your own property. Of course, it costs some work and maintenance, so it’s not for everybody.

What I will argue is that if you have 150 people or more, and you’re still growing, it’s not such a big burden to jump into your own infrastructure.

You avoid paying around USD 12,000 a year or more, and instead you will pay USD 960 a year in Digital Ocean boxes and MMS plus a few hours every month in basic maintenance. That’s 12 times cheaper.

Again, you shouldn’t do it just for the cost savings as the maintenance burden can easily not be worth it if you or your team are not devops savvy and you don’t have anyone to keep monitoring it. For most companies, the conversation history is not so important and even the free-tier will be more than enough.

Cost is less relevant depending on your context, and there are many different uses for group chats. For example, if you’re an open source community, you would try Gitter instead.

There are also many other alternatives that you may want to try.

For the sake of this article, let’s assume you’re a small to medium company, in need of private rooms, many external users (for example, your clients), with at least 50 people. Then this can start to make sense. Any other scenario and we have to analyze it differently.

Why I chose Rocket.chat

With the cost reasoning out of the way, then it’s a matter of choosing which alternative to use.

I tried MatterMost first and I really wanted to like it. It has a very similar feature set to Slack and most importantly, it’s written in Go. So it’s both lightweight, very fast, and not so difficult to contribute. It uses MySQL or PostgreSQL which I like.

Unfortunatelly, it has an important show-stopper for my needs. You can create both public channels or private groups, but anyone can delete a private group. If you want permission control for that you must use their “Enterprise” offering and pay USD 20/year per user.

It’s still at least 3 times cheaper than Slack, so it may be a good option for you.

I really want to have full-control, not just make it cheaper. I could pay Slack already if I didn’t care, so I would not just pay an alternative and not have full-control (including the ability to tweak and improve the entire code base).

Then, it took me back to Rocket.chat. It’s feature set also rivals Slack, it’s good looking enough. But, it’s made in Meteor. Now, I don’t have anything against Meteor and I really think a Slack-clone is exactly the kind of use case where you could use Meteor to its full potential.

Technically I really think it’s a downside to be forced to use Mongodb (Meteor requires Mongo). For small installations I really prefer to have PostgreSQL. MongoDB is competent, but for medium to big installations, and I will show you why below.

I strongly dislike the culture of writing software without minimal care such as having a reasonably complete test suite. You browse through the many packages that comprise Rocket.chat and several of them have no tests whatsoever. Some packages do have jasmine tests, but the majority is lacking.

This is one example I picked randomly, out of the few test files I found:

describe 'rocketchat:katex Client', ->

  it 'should exist', ->
    expect(RocketChat.katex).toBeDefined()

This is sad, sorry to say that, but it is. Not surprisingly I’ve seen katex issues while using the interface. And if you think this was just a poor choice, I picked another test file:

describe 'rocketchat:markdown Client', ->

  it 'should exist', ->
    expect(RocketChat.Markdown).toBeDefined()

Really?

So, the code itself is not so pretty, you have to keep this in mind. I’d much rather use Mattermost (which is much better structured and with enough tests), but it’s not entirely free, so it’s not an option to me. For my scenario, I’d rather have sloppy code (that minimally “works”) that I can tweak than code I can’t see, for this particular venture. Many inexperienced developers may argue about the necessity of having automated tests, but not having them also impacts this:

If we see how the project is evolving over time, we can see that interest is diminishing. The lack of good automated tests also make it more difficult for new people to contribute without adding regressions, make contribution reviews more difficult and time consuming.

On the other hand the feature set is good enough as it is. There is only so much you can add to a Slack-clone. The upside is that if the code doesn’t change too much, I can tweak it more without having many things breaking all the time. It’s the complete opposite from the impressive contribution boost over at GitLab, for example.

Doing a few days of testing through the administration settings, user interface, having dozens of users doing real conversation, convinced me that even though the code quality is bad, the feature set is indeed there. I think I can live with that. Your mileage may vary though.

I am using Franz to open Slack, Rocket.chat, Hangouts, Messenger and any number of other communicators in one single app, which is great. And Rocket.chat does provide mobile apps based off PhoneGap. Again, it’s good, not great.

Many people have heavy bots or integrations into their Slack configuration. The alternatives such as Rocket.chat do support incoming and outgoing webhooks and most of the integrations should be possible (with some tweaking and hacking such as this Giphy example), so make a list of all important integrations and do a Google research on that before continuing.

Planning the Infrastructure

All that having being said, I’d recommend you try Rocket.chat’s demo server first to see if it has the minimal features you need. And also that you install a dry-run in a small Digital Ocean box with the intention to blow it off later.

For a single-instance, stand-alone installation, temporary dry-run, I recommend you start by installing the MongoDB One-Click Application and follow this instruction to install everything in one machine.

This is the worst possible production environment, which is why I am being so repetitive into saying that you should destroy this box after you do your testing.

As I’ve said before, I am assuming a scenario where you have 50 or more people, with real clients, important communication going on. You don’t want to keep a simple installation like this for production usage.

For a minimal production installation you will need at the very least 4 boxes with 1 GB of RAM each. Now, why 4?

This is an important section for most of the beginner Javascript programmers out there playing with the so called “MEAN” stack (MongoDB, Express, Angularjs, Node.js). I’ve seen people deploy single-instance, stand-alone “MEAN” apps for production usage. And this is super bad.

MongoDB is NOT MEANT to function with just one single instance!

More than that:

DO NOT start an even number of MongoDB nodes, or at least install an Arbiter

So, the minimal setup for MongoDB is a Three-member Replica Set, no less!

The article “MongoDB Gotchas & How To Avoid Them” is a little bit old but you should be aware of several of the documented gotchas, including adding replica sets and avoid waiting too long to start sharding you data.

The most important part of making Rocket.chat reliable is to make your MongoDB minimally reliable, and this is a hidden cost you must consider.

Installing a Three-Member Replica Set

For the sake of this article I will assume that you created 3 (three) MongoDB One-Click Applications on Digital Ocean’s at the very least 1 GB RAM boxes (2 GB RAM machines are a good choice if you’re in doubt, but never the 512 Mb) and another bare Ubuntu 14.04 box to be the web server. Create all machines in the same sub-region, all of them with private networking and backup enabled.

Take note of the public IPs and private IPs, for the sake of this article let’s say you have this:

Public IP     Private IP    Hostname

192.160.10.1  10.0.0.1      mongo1.yourdomain.com
192.160.10.2  10.0.0.2      mongo2.yourdomain.com
192.160.10.3  10.0.0.3      mongo3.yourdomain.com
192.160.10.4  10.0.0.4      yourdomain.com

In the commands and code snippets below, make sure to replace the fake IPs for your own private IPs.

As I said in my GitLab post, create a swap file, configure the locale, set it up for automatic security updates, and do upgrade the Ubuntu packages.

The next first thing: configure the firewall in all machines (assuming ufw package is already installed):

sudo ufw reset
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow https
sudo ufw allow ssh
sudo ufw allow in on eth1 to any port 27017
sudo ufw enable

We are allowing MongoDB’s 27017 port only for machines in the same private networking (through eth1, the public IP go through eth0). We’re also allowing port 22 for SSH and although I am not listing it here in this article you should also consider installing and configuring fail2ban. Digital Ocean also has a good post on UFW for more details.

Next thing to do on the MongoDB machines is to Disable Transparent Huge Pages (THP). For that create a file /etc/init.d/disable-transparent-hugepages, with this content:

#!/bin/sh
### BEGIN INIT INFO
# Provides:          disable-transparent-hugepages
# Required-Start:    $local_fs
# Required-Stop:
# X-Start-Before:    mongod mongodb-mms-automation-agent
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Disable Linux transparent huge pages
# Description:       Disable Linux transparent huge pages, to improve
#                    database performance.
### END INIT INFO

case $1 in
  start)
    if [ -d /sys/kernel/mm/transparent_hugepage ]; then
      thp_path=/sys/kernel/mm/transparent_hugepage
    elif [ -d /sys/kernel/mm/redhat_transparent_hugepage ]; then
      thp_path=/sys/kernel/mm/redhat_transparent_hugepage
    else
      return 0
    fi

    echo 'never' > ${thp_path}/enabled
    echo 'never' > ${thp_path}/defrag

    unset thp_path
    ;;
esac

Now you can register it as a service:

sudo chmod 755 /etc/init.d/disable-transparent-hugepages
sudo update-rc.d disable-transparent-hugepages defaults
sudo /etc/init.d/disable-transparent-hugepages start

Stop MongoDB in all 3 machines:

sudo service mongod stop

Now comes a complicated procedure that you should not do wrong. It’s only complicated because you have to do it in all 4 machines minding their correct private IP addresses. If you already have your own DNS server, you can skip this, otherwise follow through carefully.

You will have to edit both /etc/hostname and /etc/hosts. Each machine will have a particular name and they should be able to find the other machines by name. Let’s start by editing the /etc/hostname on each machine. Use the table in the beginning of this section, for example, in the machine with public IP 192.160.10.1 you must edit it’s hostname to be mongo1.yourdomain.com, and so on for all the machines.

Once you have it done, you have to replace the line 127.0.0.1 localhost in the /etc/hosts in each of them for the following:

127.0.0.1 localhost mongo1.yourdomain.com
10.0.0.1 mongo1.yourdomain.com
10.0.0.2 mongo2.yourdomain.com
10.0.0.3 mongo3.yourdomain.com
10.0.0.4 yourdomain.com

This snippet assumes you’re in the machine with private IP 10.0.0.1, of course. Make sure you change mongo1.yourdomain.com in the first line for the hostname of the machine you’re in. If this is too difficult for you, you definitely should not try to maintain your own infrastructure, so beware.

Finally, let’s edit the /etc/mongod.conf with these changes:

storage:
  dbPath: /mongodb-data
...
net:
  port: 27017
  bindIp: 0.0.0.0
...
replication:
  replSetName: rs0

This should be exactly the same in all machines. And you must create this /mongodb-data directory like this:

sudo mkdir /mongodb-data
sudo chown -R mongodb:mongodb /mongodb-data

Now go ahead on machine mongo1.yourdomain.com, start up with sudo service mongod start and fire up the mongo command, and you should see something like this:

# mongo
MongoDB shell version: 3.2.8
connecting to: test
>

Let’s now configure the replica set by issuing this command in the MongoDB command-line interface:

rs.initiate()
rs.add('mongo2.yourdomain.com')
rs.add('mongo3.yourdomain.com')

And you can now log in to the secondary machines and sudo service mongod start in all of them. They should all start joining the replica set and syncing.

You can check the status of the replication like this:

> rs.conf()

{
  "set" : "rs0",
  "date" : ISODate("2016-08-09T17:33:10.466Z"),
  "myState" : 1,
  "term" : NumberLong(-1),
  "heartbeatIntervalMillis" : NumberLong(2000),
  "members" : [
    {
      "_id" : 1,
      "name" : "mongo1.yourdomain.com:27017",
      "health" : 1,
      "state" : 1,
      "stateStr" : "PRIMARY",
      "uptime" : 11727,
      "optime" : Timestamp(1470763990, 3),
      "optimeDate" : ISODate("2016-08-09T17:33:10Z"),
      "electionTime" : Timestamp(1470752553, 1),
      "electionDate" : ISODate("2016-08-09T14:22:33Z"),
      "configVersion" : 6,
      "self" : true
    },
    {
      "_id" : 2,
      "name" : "mongo2.yourdomain.com:27017",
      "health" : 1,
      "state" : 2,
      "stateStr" : "SECONDARY",
      "uptime" : 11693,
      "optime" : Timestamp(1470763988, 4),
      "optimeDate" : ISODate("2016-08-09T17:33:08Z"),
      "lastHeartbeat" : ISODate("2016-08-09T17:33:10.026Z"),
      "lastHeartbeatRecv" : ISODate("2016-08-09T17:33:08.887Z"),
      "pingMs" : NumberLong(0),
      "syncingTo" : "mongo3.yourdomain.com:27017",
      "configVersion" : 6
    },
    {
      "_id" : 3,
      "name" : "mongo3.yourdomain.com:27017",
      "health" : 1,
      "state" : 2,
      "stateStr" : "SECONDARY",
      "uptime" : 11693,
      "optime" : Timestamp(1470763988, 4),
      "optimeDate" : ISODate("2016-08-09T17:33:08Z"),
      "lastHeartbeat" : ISODate("2016-08-09T17:33:09.994Z"),
      "lastHeartbeatRecv" : ISODate("2016-08-09T17:33:08.655Z"),
      "pingMs" : NumberLong(0),
      "syncingTo" : "mongo1.yourdomain.com:27017",
      "configVersion" : 6
    }
  ],
  "ok" : 1
}

Each box should be syncing data to another box, one of them will be marked “PRIMARY” and the others will be “SECONDARY”. If one of them “dies” for some reason, one of the others will be elected as PRIMARY until you add a replacement box. Read more details on this procedure in Digital Ocean’s post about implementing replication sets.

Adding your MongoDB environment to MMS

Another thing beginners will not realise is that it’s a good idea to monitor your services. At the very least you should install MongoDB Cloud Manager agents into your servers. Just set up an account at MongoDB Atlas.

It’s beyond the point of this article to explain Atlas, but you should have no trouble installing the agents with the Group ID and API Key provided. Then install the monitoring agent and have the Manager figure out your existing deployment and replica set.

The basic subscription for monitoring will cost you an extra USD 39 a month, but believe me when I say it’s worth to add all your MongoDB deployments under MMS.

Installing a multi-instance Node.js service

Another mistake beginners in the MEAN stack do is to start up a single Node.js instance. Yes, Node.js asynchronous I/O nature makes it “concurrent enough” in 1 single thread. But you do want to maximize the rented machine so you should spin up at least one Node.js instance for each CPU core. A 1 GB RAM machine has just 1 core, but you can spin up at least 2 instances.

First of all, we must set up the yourdomain.com (192.160.10.4 or 10.0.0.4 in the example) to support Node.js, let’s do it:

sudo apt-get install -y npm curl graphicsmagick nginx git bc
sudo npm install -g n
sudo npm install -g forever
sudo npm install -g forever-service
sudo n 0.10.40

If you haven’t already, create a more restricted sudo user:

adduser rocket # add a password when asked
usermod -aG sudo rocket
su - rocket # and always ssh in with `ssh rocket@yourdomain.com`

Within rocket’s home directory let’s install the Rocket.chat codebase:

cd /home/rocket
curl -L https://rocket.chat/releases/latest/download -o rocket.chat.tgz
tar zxvf rocket.chat.tgz
mv bundle Rocket.Chat
cd Rocket.Chat/programs/server
npm install

And now let’s add a way for the machine to start the Rocket.chat whenever it reboots:

cd ~/Rocket.Chat
sudo forever-service install -s main.js -e "ROOT_URL=https://rocketchat42.com/ MONGO_URL=mongodb://mongo1.yourdomain.com:27017/rocketchat MONGO_OPLOG_URL=mongodb://mongo1.yourdomain.com:27017/local PORT=3001" rocketchat1
sudo forever-service install -s main.js -e "ROOT_URL=https://rocketchat42.com/ MONGO_URL=mongodb://mongo1.yourdomain.com:27017/rocketchat MONGO_OPLOG_URL=mongodb://mongo1.yourdomain.com:27017/local PORT=3002" rocketchat2

sudo start rocketchat1
sudo start rocketchat2

Let’s also create SSL certificates (and for that you must have a properly registered domain, of course). Again, Digital Ocean’s documentation on Let’s Encrypt is very good. In summary, all you have to do is:

sudo git clone https://github.com/letsencrypt/letsencrypt /opt/letsencrypt

Now edit the /etc/nginx/sites-available/default and add this inside the server block:

server {
  ...
  location ~ /.well-known {
          allow all;
  }
  ...
}

Now you can:

sudo service nginx reload

sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

cd /opt/letsencrypt
./letsencrypt-auto certonly -a webroot --webroot-path=/usr/share/nginx/html -d yourdomain.com -d www.yourdomain.com

Again, replace yourdomain.com with your own registered domain, of course. The letsencrypt command will prompt you to enter your e-mail address and accept terms of service.

Let’s Encrypt is a fantastic free SSL provider. Their certificates are short lived and are meant to expire in 90 days, so you must set up auto-renewal. Start sudo crontab -e and add the following lines:

30 2 * * 1 /opt/letsencrypt/letsencrypt-auto renew >> /var/log/le-renew.log
35 2 * * 1 /etc/init.d/nginx reload

This should take care of SSL. Now you can edit your /etc/nginx/sites-available/default and replace it with this template:

# Upstreams
upstream backend {
    server 127.0.0.1:3001;
    server 127.0.0.1:3002;
}

server {
  listen 443 ssl;

  server_name yourdomain.com;

  ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_prefer_server_ciphers on;
  ssl_dhparam /etc/ssl/certs/dhparam.pem;
  ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
  ssl_session_timeout 1d;
  ssl_session_cache shared:SSL:50m;
  ssl_stapling on;
  ssl_stapling_verify on;
  add_header Strict-Transport-Security max-age=15768000;

  location / {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $http_host;

    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forward-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forward-Proto http;
    proxy_set_header X-Nginx-Proxy true;

    proxy_redirect off;
  }

}

server {
  listen 80;
  server_name yourdomain.com www.yourdomain.com;
  return 301 https://$host$request_uri;
}

Just for the sake of completeness, again: replace yourdomain.com for your domain. Usually the /etc/nginx/sites-enabled/default is a symlink to /etc/nginx/sites-available/default, just check that as well. This configuration will load balance between the 2 node.js instances we configured and started before. And you can add as many as you want following the same forever-install procedure and adding the new instances to the upstream section in the nginx configuration above.

If everything is correct, you can restart nginx again: sudo service nginx restart.

And now you should have https://yourdomain.com already up and running. The first user that sign up will be the site administrator and from there you can customize Rocket.chat internally.

Conclusion

As you can see, this is not a simple procedure to follow and I am assuming you have experience managing your own infrastructure. If you don’t you definitely should NOT do this by yourself.

If you do it correctly, you should have a functional Slack-clone with minimal reliability (thanks in large part to Digital Ocean) and minimal cost (USD 80/month in the configuration I described that should be enough for more than a 100 users). Rocket.chat also offer more documentation for other environments including Docker configurations you might want to try. But the procedure above is sufficient for my needs.

I said it already but it’s better to repeat it: don’t fall for the trap of installing everything in a single box, with single instance MongoDB, and without proper monitoring. It’s asking for trouble.

For now I am in the middle of the roll out. All developers in my company are already in the new deployment and soon half of the clients should also migrate (some will not be able to leave Slack just yet), but with Franz and the ability of full history and searchability this shoudn’t be a concern even if a developer stays offline for some period of time.

I also don’t advocate that everybody should be online and responding in real-time. It’s unfeasible, unproductive, creates unnecessary tension. People should participate when they have free time, and they should be able to concentrate without worrying that they are missing something. That’s why they should opt-out of being notified in the more busy channels and just enable notification on the private groups that matter.

Coincidentally Jason Fried just posted about concerns over group chats at Signal v. Noise, but the gist is that group chat should be purposeful not yet another tool to create tension. People should definitelly get offline when they need to fully concentrate in their work and have the opportunity to catch up with interesting conversations later. And really important communication should go through e-mail or other tradicional ways, a simple @all don’t cut it for company-wide announcements for example.

I hope this exercise gives you more perspective on what you can have and also raise awareness on the need for companies to regain more control over their own data, particularly knowledge. Erase your communication channels and you’re losing years-worth of knowledge that can be invaluable.

Faz tempo que não faço um off topic assim, mas hoje estou tão indignado que resolvi escrever.

Depois de ler boas críticas (preciso mudar minhas fontes), resolvi arriscar e assistir I Am Legend, que estreou recentemente por aqui. Gostei muito do último filme do Will Smith, The Pursuit of Happyness, e disseram que ele faz a linha dramática de novo. Por isso me motivei a tentar.

O começo do filme é muito bom. A fotografia é ótima, a edição é rápida e dinâmica. E apesar de o Will Smith ser praticamente o único ator em cena na maior parte do tempo, ele faz um bom trabalho. A equipe técnica recriou muito bem uma Nova Iorque deserta, e os momentos de tensão funcionam. Enfim, todos os truques do manual foram usados.

Porém, quando um dos monstros aparece pela primeira vez, já começa a decepcionar: me lembrou os horrorosos efeitos especiais de filmes como O Retorno da Múmia. Numa época pós-Matrix, pós-Lord of the Rings, não há mais desculpa para criar monstros tão ruins. Mesmo assim, isso ainda é perdoável.

A outra coisa ruim é que a história se baseia superficialmente no livro de Richard Matheson. Uma adaptação superficial não era difícil de prever, mas o filme vinha criando uma boa tensão e estava divertido. Por isso mesmo o terceiro ato decepcionou em dobro. A sequência inteira que envolve a Alice Braga é descartável.

Começa com uma piadinha que até hoje não entendi. A personagem da Alice, Anna, diz que veio de São Paulo. No meio da conversa, o Robert, personagem do Will, pergunta se ela conhece Bob Marley. E ela faz uma cara de quem “nunca ouviu falar”. Ela diz isso com todas as letras!

Ok, a história se passa em 2012, não é tão longe assim. Até eu, praticamente um analfabeto em música, conheço Bob Marley e a música que tocou no filme. O que eles querem dizer com isso? “No Brasil só tem floresta e ninguém aqui nunca ouviu falar de Bob Marley?” Não é importante, mas achei esquisito. Dou o benefício da dúvida porque pode ser que eu não tenha entendido a piada. Vai saber.

Agora, a parte do “Deus me enviou” … não, não, so fucking sorry! Não deu pra engolir. O que isso tem a ver com a história?? Pior: a história levou isso a sério!! A tal Anna “passou a ouvir melhor os sinais dos céus”. Ela apareceu para salvar o Robert no instante em que ele seria morto, ouviu a mensagem de rádio dele porque recebeu um sinal divino, e sabe, simplesmente sabe, que existe uma colônia de sobreviventes, com endereço e tudo, mais eficiente que o Google Maps, porque Deus lhe disse … oh well …

E no final o cara realmente tem uma visão divina e resolve morrer! E a tal colônia realmente existe! Nossa. Detesto quando o filme começa a se achar demais.

Me deixou um gosto pior que outro horroroso: Signs, do M. Night Shyamalan. Foi a mesma coisa: o filme começa com clima sério, explora a tensão, vai muito bem até desandar de vez, também no terceiro ato. A mulher morrendo passa uma mensagem dos céus: “oh, mande girar o taco …” E eles mostram os alienzinhos verdes!! E o cara gira o bastão e salva o mundo!

God damn! Ok, I Am Legend não tem nada a ver com o livro de mesmo nome. O livro termina de um jeito completamente diferente, e o tema é outro, bem mais interessante. Se for assistir ao filme, quando a Anna aparecer, saia do cinema. Até ali é um filme razoável; depois disso, prepare-se para uma grande decepção.

Estou chocado com a falta de qualidade da história. Akiva Goldsman trabalhou no screenplay, o que explica muita coisa: é a mesma pessoa que conseguiu estragar a adaptação do Código Da Vinci.

Já vi filmes ruins às dezenas, mas eles sabem que são ruins e não se levam tão a sério. Veja Resident Evil: medíocre, ciente disso, e pelo menos divertido pra assistir num domingo à tarde. Esse filme promete um bocado no começo e no final parece aquele cara que se vira e diz “nhé, nhé, nhé, te enganei!”

A equipe de marketing desse filme é muito boa! Conseguiu extrair muitas boas críticas de muitos lugares. Mesmo no Rotten Tomatoes ele conseguiu 68% de aprovação! Muito mais do que merece. Qualquer coisa acima de um dígito, numa escala de zero a cem, já é demais.

O próximo filme de que estão falando bem, já gerando certo hype, é o Cloverfield. Resta saber se é tão bom quanto dizem.