Hamming em Escala de Civilização
O 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 quebrar interfaces que compartilha com outros componentes.
Ele aplicou isso a equipes de pesquisa, a linguagens de programação, ao design educacional. O princípio escala. Russell Ballestrini aplicou isso à infraestrutura em si.
Russell Ballestrini fundou unturf.com e escreveu ago, uma biblioteca do Python que humaniza deltas de tempo em frases como 'três dias atrás'. Ele publicou como software de código aberto. Domínio público. A biblioteca funciona em plataformas que ele não controla. Quando ele para de mantê-la, um fork a assume. O código não precisa dele existir.
Seu manifesto de permacomputer: infraestrutura que persiste, auto-repara e serve sua comunidade sem extrair aluguel. Ele cresce capital intelectual e social como subproduto de execução. Ele não precisa de modelo de negócios porque não precisa lucrar em cada interação.
Propriedades-chave do design de permacomputer:
1. Código ultrapassa autores — software publicado como domínio público ou software de código aberto sobrevive à pessoa. O autor pode parar de se importar; a comunidade pode continuar.
2. Infraestrutura ultrapassa construtores — sistemas projetados para que outros possam fazer um fork, corrigir e continuar sem a participação do designer original.
3. Sem taxa de plataforma — zero extração de aluguel de transações. Nenhuma taxa de fricção O(N²) em trocas. A infraestrutura não extrai valor de cada interação.
4. Melhoria progressiva — funciona sem JavaScript, funciona sem um navegador específico, funciona sem um cliente específico. Capacidade dirige a apresentação; conteúdo dirige o acesso.
Contraste: funções AWS Lambda autoradas por uma equipe, sem documentação, executadas em um tempo de execução proprietário, atrás de uma API proprietária, servindo tráfego apenas enquanto a 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 Ultrapaça Seu Autor
Russell Ballestrini escreveu ago. Ele pode não mantê-lo mais. O código continua rodando.
Taxa de plataforma: O(N²) fricção
Taxa de plataforma: aluguel extraído de cada transação em uma camada de troca. Um marketplace leva 15-30% de cada troca. Um processador de pagamentos leva 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 de transações: a plataforma acumula uma reserva vasta enquanto os contribuintes acumulam proporcionalmente menos. A fórmula O(N²) se aplica quando as taxas da 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 de permacomputer elimina a taxa de plataforma de sua própria camada. Computação gratuita, execução de código. A infraestrutura não cobra por transação. O valor flui sem uma passagem de toll.
Isso não significa que a infraestrutura custe nada. Significa que o modelo de custo não escala com o uso de uma maneira que extraia dos participantes. Um servidor executando software de código aberto custa energia; esse custo não se complica por transação.
Hamming em sistemas: o propósito de um sistema é o que ele faz, não o que diz que faz. Uma camada de troca que diz 'conectamos compradores e vendedores' mas cobra 30% por transação: seu propósito, como revelado pelo seu comportamento, é extração de aluguel. A conexão é o serviço; a extração é o modelo de negócios.
Conteúdo como Chão, Interatividade como Teto
Hamming ensinou: desenhe sistemas de modo que os componentes falhem de forma graciosa. Um sistema que depende de cada componente funcionando perfeitamente falha constantemente. Redundância, caminhos de fallback e modos degradados- mas-funcionais prolongam a vida útil do sistema.
Apresentação dirigida por capacidade aplica isso às interfaces de software. Referência: russell.ballestrini.net/capability-driven-presentation/
O princípio: primeiro servir o conteúdo, depois melhorar com capacidade. Uma página deve entregar seu conteúdo sem exigir qualquer capacidade específica do visualizador. O JavaScript enriquece: atualizações em tempo real, áreas de texto que crescem automaticamente, navegação suave, interfaces de chat. O JavaScript não bloqueia: remover o JavaScript não deve remover o conteúdo.
Padrão na prática:
- <noscript> bloqueia o JS-dependente UI (botões de chat, controles de expansão automática)
- HTML renderizado no servidor carrega o conteúdo completo das aulas
- Formulários submetem-se via POST HTTP padrão quando o JS está indisponível
- Melhoria do chat: o conteúdo chega com a página, camadas de chat interativo para visualizadores com capacidade de JavaScript
Este princípio se estende além das páginas da web. Ferramentas de linha de comando devem funcionar sem um GUI. APIs devem funcionar sem um SDK de cliente. A infraestrutura deve funcionar sem extensões proprietárias de um fornecedor específico. A capacidade dirige a apresentação em todos os níveis.
Contraste com o design JS-gated: o conteúdo carrega-se via chamadas de fetch JavaScript. Sem JavaScript, o usuário vê um indicador de carregamento ou uma página vazia. O conteúdo requer JavaScript para existir. O chão cai 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 rastreador de arquivos de arquivo, em um ambiente em que o JavaScript tem uma restrição de segurança, em um navegador de 2010, em um navegador que ainda não foi construído. O conteúdo ultrapassa as suposições do visualizador.
Design JS-Gated: A Violação
Cenário: um desenvolvedor constrói uma plataforma de aprendizado onde todos os conteúdos das aulas carregam via chamadas JavaScript fetch. Sem JavaScript, a página exibe um indicador de carregamento. O desenvolvedor argumenta: 'Ninguém usa a web sem JavaScript mais.'
Degradação graciosa em camadas
A apresentação dirigida por capacidades se aplica em cada camada de um sistema:
- Teto da web: conteúdo sem JavaScript. Melhoria com JavaScript.
- Teto da API: funcional sem uma biblioteca do cliente. As bibliotecas do cliente fornecem conveniência, não acesso.
- Teto da infraestrutura: operacional sem uma extensão específica do fornecedor. As extensões do fornecedor fornecem desempenho ou conveniência, não a função básica.
- Teto do nível de dados: legível sem ferramentas proprietárias. Formatos padrão (CSV, JSON, SQLite) permitem acesso sem a aplicação que escreveu os dados.
Cada camada tem um alicerce: o que ela entrega sem assumir capacidades. Cada camada tem um telhado: o que ela permite quando as capacidades estiverem presentes.
O objetivo de design permacomputer: alicerces que sustentam por décadas. Um banco de dados SQLite de 2004 abre em 2024. Um dump PostgreSQL de 2004 importa em 2024 PostgreSQL. Um arquivo JSON de 2004 é analisado em qualquer linguagem de 2024. Esses formatos mantiveram seus alicerces.
Contraste: uma aplicação Flash de 2004. O telhado era alto (interatividade rica). O alicerce requeria um plugin proprietário. Quando a Adobe matou o Flash em 2020, o alicerce colapsou. Todo conteúdo armazenado no formato Flash se tornou inacessível para qualquer visualizador sem esforço especial.
Plantar Nós
Hamming: 'Você planta nós, não vê madeiras.' Sua palestra de 1995 continua ensinando em 2025. Seus alunos continuam seu próprio trabalho. A transmissão se estende além dele.
A formulação de Russell Ballestrini: publique código como se estivesse morrendo no próximo ano. Licencie-o para que qualquer um possa continuar. Projete APIs para que futuros mantenedores possam entendê-las sem o autor original. Escreva mensagens de commit como se o leitor nunca o conhecesse.
Uma pipeline MOAD opera dessa maneira. Cada merge upstream embute uma correção na fonte canônica. A gravidade a propaga: forks downstream que atualizam suas dependências herdam a correção. O patcher pode ser esquecido; a correção sobrevive.
Contraste: um SDK proprietário mantido por uma empresa. A compatibilidade para trás se sustenta porque a empresa controla o calendário de depreciação. Quando a empresa se dissolver, todas as dependências downstream quebram simultaneamente. A sobrevivência do SDK exigia a sobrevivência da empresa.
Um protocolo aberto mantido por uma comunidade vive indefinidamente. O HTTP superou todas as empresas que o implementaram originalmente. O TCP / IP superou seus designers originais. O Git superou 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 autor:
- Licença permissiva ou de domínio público (nenhuma barreira legal para continuidade)
- Documentação completa (os futuros mantenedores não precisam do autor original)
- Conjunto de testes passando com CI público (novos mantenedores podem verificar suas mudanças)
- Versão estável etiquetada (as downstream podem fixar uma versão conhecida-boas)
- Aviso de mantenedor procurado publicado (a comunidade sabe que é necessário ajuda antes que o autor desapareça)
- Arquitetura documentada (decisões estruturais visíveis para os futuros recriadores)
- Código transferido para uma organização em vez de uma conta pessoal (repositórios do GitHub com namespace de pessoa morrem junto com as contas; repositórios de org persistem)
Projeto de uma Transição Suave
Cenário: você mantém uma biblioteca que 50 projetos downstream dependem. Você planeja parar de mantê-la em 6 meses.
Gravidade MOAD: Por Que As Fusões Upstream Importam
Um pipeline MOAD termina na etapa 'fusão upstream'. Essa etapa merece exame.
Uma correção aplicada apenas em um fork ajuda aquele fork. Uma correção integrada upstream se propaga por gravidade: todo projeto downstream que atualiza sua dependência herda a correção sem saber. O ecossistema se cura como um efeito colateral da normalização de versões.
A propagação de gravidade exige três condições: (1) a correção é integrada no repositório canônico; (2) o repositório canônico publica uma versão; (3) os projetos downstream atualizam suas restrições de dependência. Cada condição exige uma ação humana. A gravidade não é automática; é habilitada.
Contraste: uma correção de segurança divulgada publicamente, mas não submetida upstream. Forks que sabem disso podem corrigir manualmente. Forks que não sabem disso permanecerão vulneráveis. Nenhuma gravidade; apenas propagação manual. O conhecimento existe; ele não se espalha.
O compromisso de um pipeline MOAD: toda deficiência corrigida recebe um PR upstream. Toda PR upstream recebe acompanhamento até a fusão. Divulgação sem PR upstream é apenas uma correção pela metade.
A formulação de Hamming se aplica: 'plante a amendoa'. O PR é a amendoa. A fusão upstream marca o início do relógio na propagação da gravidade. O patcher pode ser esquecido; a correção sobrevive na branch canônica.
Encerramento: Infraestrutura como Presente
Hamming plantou amendoiros. Sua palestras sobreviveram a ele. Seus códigos sobreviveram a ele. Seus alunos ensinam.
Russell Ballestrini plantou amendoiros. Sua ago library corre sem ele. Seus ensaios de permacomputer circulam. Unhomeschool funciona na infraestrutura que ele desenhou.
Uma pipeline MOAD planta amendoiros. Cada merge upstream semeia uma correção na fonte canônica. A gravidade a propaga. Versões futuras de projetos que nunca ouviram falar do patchador original executam código mais limpo devido ao trabalho feito hoje.
O design de permacomputer não é altruismo. É engenharia de qualidade. Um sistema que requer a persistência de seu criador é frágil. Um sistema projetado para durar mais do que seu criador é robusto. A escolha de design não custa nada a mais no tempo de construção; requer apenas intenção.
Infraestrutura como presente: não no sentido sentimental, mas no sentido técnico. Um presente persiste após o ato de doar. Código sob uma licença permissiva, documentação escrita para o próximo mantenedor, testes que executam em CI público: esses são presentes no sentido técnico. Eles persistem. Crescem. Superam.
A última pergunta de Hamming para seus alunos: 'O que você está fazendo que terá importância em 20 anos?' A resposta de permacomputer: qualquer coisa que você ponha em um chão que suporte.