Como o Grok Build me ajudou a usar o Linux de verdade
27 de junho de 2026, Ubuntu 26.04 LTS, notebook Acer Nitro com GTX 1050 Ti
Eu não comecei essa história porque queria “descobrir o Linux”. Na verdade, Linux nunca foi novidade para mim. Usei Linux desde a época do Kurumin, testei várias distribuições e cheguei a usar Ubuntu no tempo em que a Canonical enviava CDs pelo correio. Ao mesmo tempo, venho do Windows desde o 3.11. Minha relação com sistemas operacionais nunca foi superficial.
O ponto é outro. Durante anos, o Windows foi mais prático para o meu uso diário. Não porque fosse tecnicamente mais elegante, mas porque resolvia mais coisas com menos atrito. O Linux sempre me pareceu poderoso, flexível e interessante, mas também excessivamente verboso. Para muita coisa básica, ele exigia terminal, pesquisa, tentativa, erro, logs, permissões, dependências e uma paciência que eu nem sempre queria gastar.
Sou desenvolvedor, pesquisador, professor, trabalho com tecnologia e inteligência artificial. Mas isso não significa que eu queira brigar com o computador para fazer tarefas simples. Uma coisa é gostar de tecnologia. Outra é ter que caçar bug para abrir um programa, montar uma pasta, configurar um atalho ou fazer um aplicativo enxergar um arquivo que está exatamente onde deveria estar.
A situação mudou quando meu SSD de 1 TB, com Windows 11 instalado e criptografia ativa, entrou em modo somente leitura depois de uma sequência de problemas. O sistema começou a falhar com a tela verde da imagem acima, exibindo o erro REGISTRY_ERROR (0x51).
Esse erro indicava um problema grave ligado ao registro do Windows, possivelmente corrupção de arquivos, falha de I/O no disco ou problema de hardware. Tentei o caminho normal: recuperação do Windows, reinicializações forçadas para acessar o ambiente avançado, reparo de inicialização e testes para entender se o problema era sistema, disco ou criptografia.
Mas havia uma questão mais urgente: eu precisava continuar trabalhando.
Foi aí que o Ubuntu deixou de ser uma alternativa técnica e virou necessidade prática.
E foi aí que o Grok Build mudou a experiência. Não como um chat para me mandar comandos, mas como um agente executor. Ele lia meu sistema, rodava comandos, interpretava erros, ajustava arquivos, testava de novo e seguia em frente.
Este post é sobre isso: como uma pane no Windows acabou virando uma migração prática para Linux, assistida por um agente capaz de fechar o ciclo entre intenção, erro e correção.
O problema nunca foi “não saber Linux”
O problema nunca foi exatamente “não saber Linux”. Eu já conhecia o Linux. Já tinha instalado, testado, quebrado, corrigido, abandonado e voltado várias vezes. O problema era outro: o custo operacional.
No Windows, muita coisa vinha pronta ou era resolvida por instaladores gráficos. No Linux, mesmo quando a solução existia, ela frequentemente vinha espalhada em fóruns, wikis, issues do GitHub, posts antigos e respostas que dependiam da distribuição, da versão do kernel, do ambiente gráfico ou do gerenciador de pacotes.
Um tutorial fala do driver. Outro fala do systemd. Outro explica AppImage. Outro menciona locale. Outro fala de .desktop. Outro manda instalar ffmpeg. Outro diz para criar um venv. Outro supõe que você já sabe onde fica o arquivo de configuração.
Quando você está explorando por curiosidade, isso pode até ser divertido. Quando seu Windows acabou de falhar, seu SSD está em modo somente leitura e você precisa trabalhar, isso vira atrito.
O Grok Build reduziu esse atrito porque funcionou como uma camada operacional sobre o Linux. Eu dizia o que precisava, ele verificava o estado real da máquina, rodava comandos, lia logs, corrigia e testava. A diferença não foi “aprender um comando novo”, mas parar de ser o intermediário manual entre uma resposta genérica da internet e o estado real do meu computador.
Meu ponto de partida
O ambiente era este:
Sistema: Ubuntu 26.04 LTS
Notebook: Acer Nitro
GPU: NVIDIA GTX 1050 Ti com 4 GB de VRAM
RAM: 32 GB
CPU: Intel Core i7, 8 núcleos
Locale: pt_BR.UTF-8
Windows: SSD de 1 TB com Windows 11, criptografia ativa e falha de inicialização
Outro disco: SSD de 500 GB também com Windows 11 e criptografia ativa
Erro: REGISTRY_ERROR (0x51)
A situação era delicada porque o SSD do Windows não era apenas uma partição qualquer. Ele estava criptografado. Em alguns momentos, ao tentar acessar, o sistema pedia senha. Em outros, o disco aparecia com comportamento de somente leitura.
Isso me colocou numa posição curiosa: eu ainda tinha o hardware, ainda tinha Linux, ainda tinha GPU, ainda tinha internet, mas precisava reconstruir a experiência de uso. Não era “instalar Linux para brincar”. Era fazer o Linux assumir o papel de máquina principal.
Primeiro passo: ambiente de desenvolvimento
Antes de falar em IA, eu precisava de uma máquina de desenvolvimento. Pedi ao Grok Build uma lista de aplicações necessárias para desenvolver aplicações no Ubuntu. Depois pedi para salvar em um .txt, marquei o que queria instalar e percebi que faltava PHP.
Ele instalou e validou uma stack completa:
PHP 8.5.4
Composer 2.9.5
Node.js 22.23.1
npm 10.9.8
uv 0.11.24
pytest 9.1.1
ruff 0.15.20
mypy 2.1.0
Starship 1.25.1
Também instalou extensões importantes do PHP:
curl
gd
intl
mbstring
pdo_mysql
pdo_pgsql
pdo_sqlite
zip
Isso parece detalhe, mas não é. Quem desenvolve em PHP sabe que “ter PHP instalado” não significa muita coisa se faltar pdo_mysql, mbstring, intl ou zip. Um projeto Laravel, um sistema legado ou uma aplicação própria pode quebrar por uma extensão ausente.
O Grok Build não apenas instalou. Ele validou. Esse foi o primeiro sinal de que o Ubuntu poderia mesmo virar meu ambiente principal.
Ollama com GPU: IA local no Linux
Depois veio o Ollama. Minha primeira pergunta foi simples:
Faça uma análise no meu Linux e verifique se o Ollama já está como serviço no systemd.
O Grok Build verificou o serviço, testou a API local e confirmou que o Ollama estava ativo.
Mais importante: explicou que o systemd não inicia um modelo específico. Ele apenas sobe o servidor:
ollama serve
Os modelos só entram em memória quando eu chamo:
ollama run nome-do-modelo
Isso respondeu uma dúvida prática: “qual modelo ele inicia?”. Nenhum. Ele inicia a API.
Depois pedi a instalação com GPU. O agente detectou a GTX 1050 Ti, validou o driver NVIDIA, CUDA e testou o uso real com tinyllama. O nvidia-smi mostrou processo llama-server usando a GPU.
Não foi uma promessa de suporte.
Foi evidência.
Escolher modelo não é seguir hype
Com apenas 4 GB de VRAM, a escolha do modelo importa muito. Perguntei se o gemma4:e2b era bom para meu hardware. O Grok Build testou no meu ambiente e comparou com alternativas.
O resultado foi mais útil do que qualquer recomendação genérica.
O gemma4:e2b usou cerca de 1,7 GB de VRAM e chegou a 26 tok/s. Era bom para multimodal, mas mais lento para carregar.
O phi4-mini usou cerca de 3 GB de VRAM e entregou uma experiência melhor no uso diário.
O tinyllama era leve, mas limitado. Serviu para testar se tudo estava funcionando, não para virar meu modelo principal.
O tinyllama respondeu corretamente qual era a capital do Brasil, mas alucinou completamente quando perguntei quem era Elzo Brito. Isso foi útil. Mostrou que modelo pequeno pode servir para teste, estudo e experimentação, mas não necessariamente para uso real.
Depois adicionamos o phi4-mini. Em teste de programação, ele foi bem mais prático para o dia a dia. No meu hardware, respondeu em cerca de 12 segundos em um desafio em que o gemma4:e2b levou aproximadamente 49 segundos.
A lição foi simples: em IA local, o melhor modelo não é o maior. É o maior que sua máquina aguenta com conforto.
Whisper GPU: instalar não é o mesmo que funcionar
Depois perguntei:
Uma dúvida, o Whisper GPU está instalado?
A resposta honesta foi: não. Não havia ambiente virtual dedicado, nem faster-whisper, nem PyTorch com CUDA configurado, nem comandos expostos corretamente no PATH.
O Grok Build instalou faster-whisper, openai-whisper, PyTorch com CUDA, ffmpeg, um ambiente virtual em ~/.local/share/whisper-gpu/venv e comandos como faster-whisper-gpu e whisper-gpu.
Esse foi outro ponto importante da migração. No Windows, muitas vezes eu instalo um programa e ele aparece no menu. No Linux, especialmente com IA, a instalação real envolve várias camadas: driver, CUDA, Python, ambiente virtual, biblioteca, binário, PATH e teste de sanidade.
Sem isso, você acha que instalou, mas na hora de usar não funciona.
Meu projeto de download do YouTube
No diretório ~/desenvolvimento, eu tinha um projeto para baixar vídeos do YouTube. Pedi para o Grok Build verificar o que faltava para ele rodar.
Ele auditou dependências Python, yt-dlp, ffmpeg, configuração de cookies do Edge e integração com transcrição. Quando testei, o download funcionou, mas a transcrição falhou. O log mostrava:
Erro na transcricao:
[Errno 2] No such file or directory:
~/desenvolvimento/whisper.cpp/build/bin/whisper-cli
Ou seja, o problema não era o download. O pipeline baixava o áudio. A falha estava na etapa de transcrição, porque o projeto esperava um whisper-cli compilado em um caminho que não existia.
Sem olhar log, eu provavelmente diria: “o programa não funciona”. Com o Grok Build, a conclusão foi mais precisa: o download funciona, mas a transcrição quebra por caminho incorreto do Whisper. Essa diferença economiza tempo.
Também ajustamos a parte de cookies do navegador Edge para uso com yt-dlp, porque alguns downloads exigiam autenticação ou sessão. Depois veio uma necessidade simples, mas essencial: criar um ícone para clicar e abrir o programa.
O Grok Build criou um arquivo .desktop, configurou ícone, permissão de confiança e integração com o GNOME. Essa foi uma virada importante: o programa deixou de ser “algo que roda no terminal” e virou “algo que posso abrir como aplicativo”.
Pequenos hábitos do Windows
Migrar para Linux não é só substituir programas grandes. É substituir hábitos.
No Windows, eu usava Win + V para abrir o histórico da área de transferência. Perguntei se havia equivalente no Linux. Também testei notificações e alertas de conclusão para fluxos longos com agentes. A ideia era simples: quando uma ferramenta como Claude Code, OpenCode ou equivalente terminar uma etapa e precisar de mim, ela toca um som.
Um script em Node.js resolvia isso usando paplay ou aplay no Linux. Parece detalhe, mas não é. Agentes que executam tarefas podem ficar vários minutos trabalhando. Se eles precisam da minha intervenção, é muito melhor receber um alerta do que ficar olhando a tela.
Esse tipo de ajuste faz parte da experiência real.
ESAA e conversation-esaa: registrar a própria migração
Durante a sessão, percebi que tudo aquilo não deveria se perder. Eu já vinha trabalhando com ESAA e conversation-esaa. Então pedi para o Grok Build ler o ESAA-Core, guardar o contexto, reconhecer o esaa-codex-plugin, ler o conversation-esaa e iniciar um .conversation-esaa em /home/elzobrito.
A ideia era registrar conversas que não pertenciam a um projeto fixo. Cada projeto pode ter seu próprio histórico, mas meu ambiente Linux também merecia um log operacional.
Isso criou uma camada interessante: enquanto o Grok Build configurava o sistema, o conversation-esaa registrava o processo. A migração virou uma trilha de eventos. Não era só “instalei um programa”. Era intenção, ação, erro, correção, validação e registro.
Essa lógica combina muito bem com o Linux, porque Linux, no fundo, é infraestrutura pessoal. E infraestrutura precisa de rastreabilidade.
Bambu Studio: o caso mais Linux possível
Tenho uma impressora da Bambu Lab. Pedi para instalar o Bambu Studio. Parecia simples: baixar AppImage, dar permissão e abrir. Não foi.
O Grok Build baixou a versão oficial, colocou em ~/.local/opt, criou launcher, extraiu ícone, registrou atalho no menu e na área de trabalho. Parecia resolvido, mas o AppImage começou a falhar por certificado SSL:
/etc/ssl/certs/ca-certificates.crt
O launcher precisou exportar variáveis como:
SSL_CERT_FILE
CURL_CA_BUNDLE
REQUESTS_CA_BUNDLE
Depois veio o problema do locale. O Bambu Studio exigia en_GB, mas meu sistema tinha pt_BR.UTF-8. Os sintomas eram estranhos: o AppImage abria e morria, o comando locale -a não listava en_GB e a chamada newlocale("en_GB") falhava.
O Grok Build tentou várias estratégias: criou locale local, fez alias de en_GB para en_GB.UTF-8, criou wrapper de locale, fez bypass do AppRun e ajustou variáveis de ambiente para evitar o crash.
Depois atualizei o AppImage para uma versão nova. A atualização quebrou a inicialização de novo. Mais tarde, ao tentar resolver duplicidade de ícones no menu, um ícone antigo foi removido. Só que o ícone removido não era o problemático.
Eu cliquei no menu do Ubuntu e apareceu erro porque o atalho apontava para um caminho antigo. Minha reação foi direta: “você aparentemente removeu o ícone errado”.
A correção final envolveu restaurar o .desktop, criar um redirecionamento no caminho antigo, manter um único ícone visível e deixar uma nota explicando qual caminho usar.
Essa parte foi a mais “Linux real” de todas, porque o problema não era instalar. Era integrar. AppImage, GNOME, locale, SSL, cache de menu, favorito na dock, caminho absoluto e atualização manual estavam todos envolvidos no mesmo problema.
A lição foi clara: no Linux, “abre pelo terminal” e “abre pelo ícone” podem ser problemas diferentes.
Google Drive, OneDrive e rclone
Depois veio outra necessidade de máquina principal:
O Google Drive tem suporte ao Linux?
A resposta prática foi usar rclone. Instalamos e configuramos. Depois criei atalho no menu. Em seguida, apareceu outra dúvida: por que a pasta parecia vazia ou demorava para carregar?
A resposta estava no modelo de montagem. Com rclone, muitos arquivos aparecem sob demanda. O cache influencia a experiência. Desmontar e montar não necessariamente exige login novamente. Trocar conta exige reconfigurar remote ou criar outro.
Também pedi sincronização com OneDrive e depois precisei trocar de conta. Foi mais um exemplo de como o Linux resolve, mas resolve de outro jeito.
No Windows, você instala o aplicativo oficial e ele decide quase tudo. No Linux, você entende e controla mais partes do processo. Isso dá mais poder, mas também exige mais cuidado.
Android, Xbox e os limites da migração
Também perguntei sobre coisas que vinham do ecossistema Windows, como Xbox Game Bar, jogos do Xbox, integração com Android e possibilidade de rodar aplicativos Android no Linux.
Essas perguntas são importantes porque uma migração real não é só produtividade. É cotidiano. Algumas coisas têm alternativa. Outras funcionam parcialmente. Outras continuam melhores no Windows. A questão não é fingir que Linux substitui tudo perfeitamente, mas saber onde ele substitui bem, onde exige adaptação e onde ainda vale manter outro caminho.
O Grok Build ajudou justamente nisso: separar possibilidade real de expectativa irreal.
O que o Grok Build fez diferente de um chat comum
A diferença principal foi o fechamento de loop.
Um chat tradicional diria para eu rodar systemctl status ollama.
O Grok Build rodou e interpretou a saída.
Um chat tradicional diria que talvez fosse driver.
O Grok Build verificou nvidia-smi, CUDA e processo na GPU.
Um chat tradicional sugeriria instalar um modelo menor.
O Grok Build testou modelos no meu hardware.
Um chat tradicional mandaria configurar o Whisper.
O Grok Build criou o venv, instalou dependências e validou comandos.
Um chat tradicional diria para usar ffmpeg.
O Grok Build identificou onde o pipeline quebrava.
Um chat tradicional mandaria criar um .desktop.
O Grok Build criou launcher, ícone e integração com GNOME.
Um chat tradicional diria que talvez fosse locale.
O Grok Build criou locale local, wrappers e fallback.
Um chat tradicional mandaria ver o log.
O Grok Build leu log, ajustou e testou de novo.
Um chat tradicional recomendaria rclone.
O Grok Build instalou, configurou, montou e ajustou cache.
Um chat tradicional sugeriria documentar.
O Grok Build registrou o processo no conversation-esaa.
A diferença não é apenas velocidade. É confiança. Quando um agente executa, observa, corrige e valida, o usuário deixa de ser o intermediário manual entre a sugestão e o sistema.
A verdadeira mudança
No começo, eu tinha um problema: um SSD de 1 TB com Windows 11, criptografia ativa, erro em tela verde e comportamento de somente leitura. No fim, eu tinha um Ubuntu capaz de sustentar meu trabalho.
Com Ollama, GPU, Whisper, PHP, Node, Python, Bambu Studio, rclone, atalhos no GNOME, scripts e registros no conversation-esaa, o Linux deixou de ser apenas um ambiente alternativo. Virou um ambiente que eu podia moldar.
Essa foi a mudança real. Eu não migrei para Linux porque queria sofrer no terminal. Também não migrei porque desconhecia Linux e queria experimentar algo novo. Eu migrei porque precisei continuar trabalhando quando o Windows deixou de ser confiável.
Com o Grok Build, o Linux deixou de ser uma coleção de tutoriais espalhados e virou uma infraestrutura pessoal em construção.
Volto para o Windows?
O erro REGISTRY_ERROR (0x51), naquela tela verde do Windows, foi o começo da história. Mas não foi o tema principal. O tema principal foi autonomia.
Eu já conhecia Linux havia muitos anos. Usei Kurumin, testei distribuições, acompanhei a época dos CDs do Ubuntu enviados pela Canonical e sempre soube que o Linux era poderoso. Mas também sempre senti que ele exigia um tipo de paciência muito específico: a paciência de caçar bug, interpretar erro obscuro, ajustar arquivo de configuração e resolver manualmente coisas que, em outros sistemas, simplesmente aparecem prontas.
Dessa vez foi diferente, não porque o Linux ficou magicamente simples, mas porque eu não estava sozinho no ciclo de tentativa e erro. O Grok Build não substituiu o Linux. Ele reduziu a fricção entre o que eu queria fazer e o que o sistema exigia de mim.
Cada erro virou evidência, cada log virou pista, cada comando virou uma etapa e cada correção virou parte da infraestrutura. O SSD em modo somente leitura foi o empurrão. O Grok Build foi a ferramenta que transformou esse empurrão em migração prática.
Talvez essa seja a melhor definição de usar Linux de verdade no meu caso: não foi decorar comandos, nem provar superioridade técnica, nem fingir que o terminal é sempre prazeroso. Foi conseguir transformar o sistema em uma extensão do meu fluxo de trabalho.
Foi assim que uma tela verde do Windows acabou me levando a uma estação Linux com IA local, desenvolvimento, transcrição, impressão 3D, nuvem e registro operacional.
No fim, eu não apenas “usei Linux”. Eu comecei a construir meu próprio ambiente.
E, sinceramente, depois dessa experiência, não parece que eu volto para o Windows tão cedo.