Hamming em Escala Civilizacional [BLOCK_TYPE SECTION/STEP]
Princípio de engenharia de sistemas de Richard Hamming: otimize o sistema, não os componentes. Um componente otimizado isoladamente degrada o desempenho do sistema ao romper interfaces que compartilha com outros componentes. [BLOCK_TYPE SECTION/STEP]
Ele aplicou isso a equipes de pesquisa, linguagens de programação e design educacional. O princípio escala. Russell Ballestrini aplicou-o à própria infraestrutura. [BLOCK_TYPE SECTION/STEP]
[BLOCK_TYPE SECTION/STEP]
Russell Ballestrini fundou unturf.com e escreveu ago, uma biblioteca Python que humaniza intervalos de tempo em frases como 'três dias atrás'. Ele a publicou como código aberto. Domínio público. A biblioteca roda em plataformas que ele não controla. Quando ele parar de mantê-la, um fork a assume. O código não exige que ele exista.
Seu manifesto do permacomputador: infraestrutura que persiste, se auto-repara e serve sua comunidade sem extrair aluguel. Ela cresce capital intelectual e social como subproduto de seu funcionamento. Não precisa de um modelo de negócios porque não precisa lucrar com cada interação.
Propriedades-chave do design de permacomputador:
1. Código sobrevive aos autores — software publicado como domínio público ou código aberto sobrevive ao indivíduo. O autor pode parar de se importar; a comunidade pode continuar.
2. Infraestrutura sobrevive aos construtores — sistemas projetados para que outros possam fazer fork, corrigir e continuar sem o envolvimento do designer original.
3. Sem taxa de plataforma — extração de aluguel zero em transações. Sem cobrança de atrito O(N²) em trocas. A infraestrutura não extrai valor de cada interação.
4. Aprimoramento progressivo — funciona sem JavaScript, funciona sem um navegador específico, funciona sem um cliente específico. A capacidade direciona a apresentação; o conteúdo direciona o acesso.
Contraste: funções AWS Lambda criadas por uma equipe, sem documentação, executadas em um runtime proprietário, atrás de uma API proprietária, servindo tráfego apenas enquanto essa equipe paga a conta. Quando a equipe se dissolve, a função desaparece. A computação foi alugada, não construída.
Código Que Sobrevive ao Seu Autor
Russell Ballestrini escreveu ago. Ele pode não mais mantê-lo. O código continua funcionando.
Taxa de Plataforma: Fricção O(N²)
Taxa de plataforma: aluguel extraído de cada transação em uma camada de troca. Um marketplace cobra 15-30% de cada troca. Um processador de pagamentos cobra 2,9% + $0,30. Um provedor de nuvem cobra por cada chamada de API. Nenhuma dessas taxas representa novo valor criado; elas representam extração da troca.
Em pequena escala: invisível. Em N=1.000.000 transações: a plataforma acumula uma reserva vasta enquanto os contribuidores acumulam proporcionalmente menos. A formulação O(N²) aplica-se quando as taxas de plataforma se acumulam: um contratado em uma plataforma dentro de um marketplace dentro de um processador de pagamentos paga três camadas de aluguel.
A infraestrutura Permacomputer elimina o imposto de plataforma da sua própria camada. Computação gratuita, execução de código gratuita. A infraestrutura não cobra por transação. O valor flui sem pedágio.
Isso não significa que a infraestrutura não tenha custo. Significa que o modelo de custo não escala com o uso de forma a extrair valor dos participantes. Um servidor executando software de código aberto consome eletricidade; esse custo não se multiplica por transação.
Hamming sobre sistemas: o propósito de um sistema é o que ele faz, não o que ele diz que faz. Uma camada de troca que afirma "conectamos compradores e vendedores" mas cobra 30% por transação: seu propósito, revelado pelo comportamento, é a extração de renda. A conexão é o serviço; a extração é o modelo de negócio.
Conteúdo como Piso, Interatividade como Teto
Hamming ensinava: projete sistemas para que os componentes falhem de forma graciosa. Um sistema que depende de cada componente funcionar perfeitamente falha constantemente. Redundância, caminhos alternativos e modos degradados, mas funcionais, prolongam a vida útil do sistema.
A apresentação orientada por capacidades aplica isso às interfaces de software. Referência: russell.ballestrini.net/capability-driven-presentation/
O princípio: sirva o conteúdo primeiro, melhore com capacidade. Uma página deve entregar seu conteúdo sem exigir nenhuma capacidade específica do visualizador. JavaScript enriquece: atualizações em tempo real, áreas de texto que crescem automaticamente, navegação suave, interfaces de chat. JavaScript não bloqueia: remover o JavaScript não deve remover o conteúdo.
Padrão na prática:
- Blocos <noscript> ocultam a interface dependente de JS (botões de chat, controles de expansão automática)
- HTML renderizado no servidor carrega o conteúdo completo da lição
- Formulários são enviados via HTTP POST padrão quando o JS não está disponível
- Aprimoramento de chat: o conteúdo chega com a página, chats interativos sobrepostos para visualizadores com suporte a JS
Este princípio vai além das páginas web. Ferramentas de CLI devem funcionar sem uma GUI. APIs devem funcionar sem um SDK de cliente. Infraestrutura deve funcionar sem extensões proprietárias de um fornecedor específico. A capacidade direciona a apresentação em todas as camadas.
Contraste com design dependente de JS: o conteúdo é carregado via chamadas fetch em JavaScript. Sem JavaScript, o usuário vê um spinner ou uma página vazia. O conteúdo exige JavaScript para existir. O piso caiu abaixo da acessibilidade.
Por que isso importa para o permacomputer: uma página que funciona sem JavaScript funciona no Lynx, em um leitor de tela, em um crawler de arquivamento, em um ambiente onde o JavaScript tem restrição de segurança, em um navegador de 2010, em um navegador que ainda não foi construído. O conteúdo sobrevive às suposições do visualizador.
Design Dependente de JS: A Violação
Cenário: um desenvolvedor constrói uma plataforma de aprendizagem onde todo o conteúdo das lições é carregado via chamadas fetch em JavaScript. Sem JavaScript, a página exibe um spinner. O desenvolvedor argumenta: 'Ninguém mais usa a web sem JavaScript.'
Degradação Graciosa Entre Camadas
A apresentação orientada por capacidades se aplica em todas as camadas de um sistema:
- Camada web: conteúdo sem JavaScript. Aprimoramento com JavaScript.
- Camada de API: funcional sem uma biblioteca de cliente. Bibliotecas de cliente oferecem conveniência, não acesso.
- Camada de infraestrutura: operacional sem extensões específicas de um fornecedor. Extensões de fornecedores oferecem desempenho ou conveniência, não a função principal.
- Camada de dados: legível sem ferramentas proprietárias. Formatos padrão (CSV, JSON, SQLite) permitem acesso sem o aplicativo que gravou os dados.
Cada camada tem um piso: o que ela entrega sem pressupor capacidades. Cada camada tem um teto: o que ela possibilita quando as capacidades estão presentes.
O objetivo de design do permacomputador: pisos que se sustentem por décadas. Um banco de dados SQLite de 2004 abre no SQLite de 2024 sem migração. Um dump do PostgreSQL de 2004 importa no PostgreSQL de 2024. Um arquivo JSON de 2004 é analisado em qualquer linguagem de 2024. Esses formatos mantiveram seus pisos.
Contraste: um aplicativo Flash de 2004. O teto era alto (interatividade rica). O piso exigia um plugin proprietário. Quando a Adobe encerrou o Flash em 2020, o piso desabou. Todo o conteúdo armazenado no formato Flash tornou-se inacessível a qualquer visualizador sem esforço especial.
Plantando Bolotas
Hamming: 'Você planta bolotas, você não vê carvalhos.' Suas palestras de 1995 continuam ensinando em 2025. Seus alunos continuam seu próprio trabalho. A transmissão vai além dele.
A formulação de Russell Ballestrini: publique código como se fosse morrer no próximo ano. Licencie-o para que qualquer pessoa possa continuar. Projete APIs para que futuros mantenedores possam compreendê-las sem o autor original. Escreva mensagens de commit como se o leitor nunca tivesse te conhecido.
Um pipeline MOAD opera dessa forma. Cada merge upstream incorpora uma correção na fonte canônica. A gravidade a propaga: forks downstream que atualizam suas dependências herdam a correção. O autor do patch pode ser esquecido; o patch sobrevive.
Contraste: um SDK proprietário mantido por uma empresa. A compatibilidade retroativa se mantém porque a empresa controla o cronograma de descontinuação. Quando a empresa se dissolve, toda dependência downstream quebra simultaneamente. A sobrevivência do SDK exigia a sobrevivência da empresa.
Um protocolo aberto mantido por uma comunidade vive indefinidamente. O HTTP sobreviveu a todas as empresas que o implementaram originalmente. O TCP/IP sobreviveu aos seus projetistas originais. O Git sobreviveu a dezenas de sistemas de controle de versão concorrentes. O protocolo se torna infraestrutura; a infraestrutura se torna invisível; a infraestrutura invisível se torna permanente.
O que faz o código sobreviver ao seu autor:
- Licença permissiva ou de domínio público (sem barreira legal para continuação)
- Documentação abrangente (futuros mantenedores não precisam do autor original)
- Suíte de testes aprovada com CI público (novos mantenedores podem verificar suas alterações)
- Versão estável etiquetada (downstream pode fixar uma versão conhecida e confiável)
- Aviso de "mantenedor procurado" publicado (a comunidade sabe que ajuda é necessária antes que o autor desapareça)
- Arquitetura documentada (decisões estruturais visíveis para futuros reconstrutores)
- Código transferido para uma organização em vez de uma conta pessoal (repositórios no namespace pessoal do GitHub morrem com as contas; repositórios de org persistem)
Designing a Graceful Handoff
Cenário: você mantém uma biblioteca da qual 50 projetos downstream dependem. Você planeja parar de mantê-la em 6 meses.
Gravidade MOAD: Por que os merges upstream importam
Um pipeline MOAD termina em 'merge upstream'. Esse passo merece exame.
Um patch aplicado apenas em um fork ajuda apenas esse fork. Um patch mesclado upstream se propaga por gravidade: todo projeto downstream que atualiza sua dependência herda a correção sem saber. O ecossistema se cura como efeito colateral de atualizações normais de versão.
A propagação por gravidade requer três condições: (1) a correção é mesclada na fonte canônica; (2) a fonte canônica publica uma release; (3) os projetos downstream atualizam seus pins de dependência. Cada condição requer ação humana. A gravidade não é automática; ela é habilitada.
Contraste: uma correção de segurança divulgada publicamente, mas não enviada para o repositório principal. Forks que conhecem a correção podem aplicá-la manualmente. Forks que não conhecem permanecem vulneráveis. Sem gravidade; apenas propagação manual. O conhecimento existe; ele não se espalha.
O compromisso de um pipeline MOAD: todo defeito corrigido gera um PR upstream. Todo PR upstream é acompanhado até o merge. Divulgação sem PR upstream é apenas meio patch.
A estrutura de Hamming se aplica: 'plante o carvalho.' O PR é o carvalho. O merge upstream inicia o relógio da propagação por gravidade. O autor do patch pode ser esquecido; a correção sobrevive no branch canônico.
Encerramento: Infraestrutura como Presente
Hamming plantou bolotas. Suas aulas sobrevivem a ele. Seus códigos sobrevivem a ele. Seus alunos ensinam.
Russell Ballestrini plantou bolotas. Sua biblioteca ago funciona sem ele. Seus ensaios sobre permacomputador circulam. Unhomeschool roda na infraestrutura que ele projetou.
Um pipeline MOAD planta bolotas. Cada merge upstream semeia uma correção no código-fonte canônico. A gravidade a propaga. Versões futuras de projetos que nunca ouviram falar do autor original do patch executam código mais limpo graças ao trabalho feito hoje.
O design de permacomputador não é altruísmo. É boa engenharia. Um sistema que exige que seu criador persista é frágil. Um sistema projetado para sobreviver ao seu criador é robusto. A escolha de design não custa nada extra no momento da construção; requer apenas intenção.
Infraestrutura como presente: não no sentido sentimental, mas no sentido técnico. Um presente persiste após a doação. Código sob licença permissiva, documentação escrita para o próximo mantenedor, testes que rodam em CI público: estes são presentes no sentido técnico. Eles persistem. Eles crescem. Eles sobrevivem.
A pergunta final de Hamming aos seus alunos: 'O que você está fazendo que importará daqui a 20 anos?' A resposta do permacomputador: qualquer coisa que você coloque em um piso que se sustenta.