4
Oletros
3 min de leitura ·

Como um agente autônomo de IA (claude) compilou uma uma distribuição Linux do zero (LFS)

Quem já tentou montar o Linux From Scratch (LFS) sabe o rito de passagem que ele representa. São centenas de páginas de manual, dezenas de pacotes tarball para baixar, compilação cruzada de toolchain (GCC, Binutils, Glibc), ajuste fino de variáveis de ambiente, entrada em ambiente chroot, compilação do Kernel e configuração manual de bootloader. Um único erro de flag ou dependência circular e você passa horas caçando logs de erro no terminal.

O canal do Eli Rigobelli publicou um experimento fascinante: deixar um agente autônomo de IA (Claude Code) rodando em uma VPS encarregado de seguir o LFS e compilar um sistema operacional funcional do zero, sem intervenção humana no código ou nos comandos.

O resultado foi o Sagui Linux, uma distro Live bootável tanto em UEFI quanto BIOS, primeiro em modo texto e depois estendida via BLFS (Beyond Linux From Scratch) com Xorg, XFCE e Firefox.

Aqui está um raio-x de como a arquitetura do agente foi estruturada, os desafios contornados e o que isso revela sobre o estado atual dos agentes autônomos.

Saude e Sucesso !

A Arquitetura do Experimento

Para evitar que a IA se perdesse em loops infinitos de contexto ou alucinações de terminal, o fluxo foi montado com regras operacionais bem rígidas:

  1. Host e Persistência de Sessão: Uma VPS robusta (8 vCPUs, 32 GB RAM) rodando Ubuntu com tmux. O tmux garantiu que o agente continuasse operando em background ininterruptamente caso caísse a conexão SSH local.

  2. PRD (Product Requirement Document) Estruturado: Em vez de dar comandos vagos ("crie um Linux"), foi fornecido um documento dividindo todo o LFS 12.4 em 13 marcos técnicos (H01 a H13) — desde checagem do host, download e validação por hash MD5 dos fontes, montagem do toolchain temporário, chroot, compilação do sistema base até a geração da imagem ISO híbrida.

  3. Loop de Execução e Autonomia: O agente recebeu ordens para operar em loop autônomo: ler o erro, inspecionar logs, corrigir variáveis/dependências e seguir adiante sem intervenção humana.

  4. Auto-Documentação e Dashboard: A cada passo, o agente atualizava:

  • status.md: porcentagem concluída e marco atual.

  • docs/decisoes.md: justificativas de parâmetros de compilação adotados.

  • docs/erros.md: causa raiz de falhas e correções aplicadas.

  • Um mini dashboard estático em HTML/JSON para monitoramento visual via navegador/FTP.

Onde a IA se destacou (e onde tropeçou)

  • Resolução de conflitos de dependências: Ao longo das compilações, o agente lidou com falhas típicas de permissão de diretório, checagem de bibliotecas em caminhos incorretos ($PATH e $LIBRARY_PATH) e pacotes fora do livro oficial necessários para o initramfs do sistema Live. Em todos os casos, ele mesmo identificou o log, baixou o patch ou dependência ausente e reexecutou os comandos.

  • Custo e Consumo de Tokens Surpreendentemente Baixo: Esperava-se um estouro rápido nos limites da API. No entanto, o agente gastou apenas cerca de 4% a 11% das cotas semanais. Por quê? A maior parte do tempo de um build LFS é gasta pela CPU rodando ./configure, make -j e testes unitários. Quando o agente aprende a esperar o término do processo em vez de floodar chamadas de contexto, o consumo de tokens cai drasticamente.

  • O gargalo do mundo real: O agente testou e validou a ISO internamente via QEMU na própria VPS. Porém, ao gravar no pen drive real com o Rufus no modo ISO padrão, o initramfs não encontrou a label do sistema live montada. A IA diagnosticou o sintoma e recomendou o uso de ferramentas de gravação direta em bloco (dd ou Etcher), resolvendo o boot no notebook físico.

Para quem quiser conferir o experimento completo e ver o boot na máquina:

Carregando publicação patrocinada...
4

Isso é muito legal. E acho que abre possibilidades que muita gente ainda não percebeu.

Linux, Windows e praticamente todos os sistemas operacionais que usamos são projetados para propósito geral. Precisam funcionar razoavelmente bem em milhares de hardwares e cargas de trabalho completamente diferentes. E isso implica uma infinidade de compromissos de engenharia.

Só que o melhor sistema operacional para rodar um banco de dados não é o melhor para executar um jogo, um servidor HTTP ou uma aplicação de processamento numérico.

Esquece aquela discussão de qual é mais rápido, Linux ou Windows. A pergunta certa qual política de escalonamento, gerenciamento de memória e I/O é melhor para a minha carga de trabalho?

Experimentar diferentes políticas. Rodar benchmarks, analisar os resultados e iterar.

Boa parte disso já é feito para certas aplicações. O problema sempre foi o custo de engenharia necessário para explorar todas as possibilidades.

E nem precisamos parar na configuração do Kernel. Com agentes de IA podemos explorar modificações no próprio kernel, kernels especializados, unikernels e arquiteturas que até ontem eram economicamente inviáveis.

A IA não vai acabar com o software. Vai tornar possível um nível de especialização que hoje mal conseguimos imaginar. E, eventualmente, até o hardware entra nessa história

2

Meus 2 cents,

Pois eh, as possibilidades de customizacao do S.O. por funcao ficam bem interessantes.

No passado, quando iamos montar um firewall baseado em Linux e em hardware limitado, um dos passos era identificar o hardware com exatidao e compilar o kernel apenas com os modulos necessarios e escolher a dedo quais os programas que iam ser instalados (slackware feelings), tanto para otimizar o processamento quanto para diminuir a superficie de ataque disponivel.

Com o avanco do hardware e amplo acesso a memoria, disco e CPU, conheco poucos DevOps que ainda fazem este tipo de customizacao.

Mas como voce colocou, pode ser o retorno a este tipo de perfil, juntando ainda a questao de necessidade do S.O. ter acesso rapido a correcoes zero-day.

Imaginemos: um unikernel ou imagem hiperespecializada sem sequer ter shell, fork, exec ou ferramentas de rede genericas para um atacante explorar apos um exploit de memoria.

Ou uma instancia de banco de dados rodando direto sobre drivers de I/O com escalonadores feitos sob medida para concorrencia daquele engine especifico, eliminando camadas inteiras de overhead de troca de contexto de OS generico (o que arranhamos com uso de containers, da para ir a locais inimaginados)

Obrigado pelo comentario !

PS: Fazia tempo que nao via teus comentarios por aqui - que bom voltar a le-lo !

Saude e Sucesso !

Este post foi favoritado via extensão TABNEWS FAVORITOS

Tem curiosidade sobre IA ? Da uma olhada no meu LIVRO: IA PARA ENGENHEIROS