Eu odeio compiladores

Builds reproduzíveis e determinismo do compilador

• Forte discordância sobre quão importantes são os builds reproduzíveis.
  • Lado favorável: necessários para verificar binários de distribuições (por exemplo, xz), checar conformidade com a GPL, dar suporte a usuários militares ou de alta garantia que recompilam e comparam hashes, e fornecer a auditores prova de que um binário distribuído corresponde ao código revisado.
  • Lado cético: vê isso como algo em grande parte teórico; prefere assinaturas e rastreabilidade de CI em vez de saídas bit a bit idênticas; argumenta que usuários que se importam deveriam compilar a partir do código-fonte por conta própria.
• Problemas concretos:
  • Comportamento não determinístico do compilador devido a estruturas de dados com ordem de iteração baseada em ponteiros ou indefinida (por exemplo, DenseMap do LLVM) e ASLR afetando o layout interno; as correções sugeridas envolvem contêineres determinísticos (MapVector) e tratar isso como bugs do compilador.
  • Marcas de tempo e macros de tempo de compilação como __DATE__/__TIME__ são citadas como formas “fáceis” de quebrar a reprodutibilidade. Há debate sobre isso ser um tradeoff óbvio e intencional ou uma armadilha fácil e acidental; alguns argumentam que tais macros não deveriam existir em compiladores.
• Nix/Guix:
  • Elogiados por ambientes de build herméticos (por exemplo, fixando o tempo via SOURCE_DATE_EPOCH, hashing de entradas).
  • Outros observam que eles não resolvem bugs do compilador nem não determinismo dependente de concorrência.

LLMs, binários e compiladores

• Uma linha de discussão sugere treinar LLMs diretamente em binários para gerar código de máquina.
• A maioria das respostas é cética:
  • Pequenas perturbações no binário quebram executáveis; não existe um binário “plausível”.
  • LLMs têm dificuldade com contagem e precisão fina (por exemplo, offsets exatos de saltos), mesmo que se saiam bem em tarefas de alto nível ou vagas.
  • Qualquer estrutura séria de execução acabaria reintroduzindo estrutura semelhante à de compiladores/assembladores.
• Debate paralelo sobre tarefas “difíceis” vs “fáceis” para humanos versus LLMs e a relevância do paradoxo de Moravec.

Ambientes de baixo nível vs alto nível

• Uma visão: trabalho de baixo nível é altamente específico ao ambiente (hardware, gerações de CPU, protocolos de fornecedores), cheio de suposições ocultas; portanto, LLMs têm mais dificuldade ali do que em “wraps” de alto nível.
• Visão contrária: código procedural simples e com poucas dependências é relativamente estável em comparação com frameworks web de rápida mudança; discussão sobre o que conta como “baixo nível” (C + bibliotecas do SO vs frameworks de GUI/web).

Proteção Anubis por prova de trabalho

• Críticos comparam desafios de PoW do lado do cliente a malware ou mineradores de criptomoedas: energia desperdiçada, preocupações de acessibilidade e dissuasão limitada contra grandes empresas de IA com muito poder de computação.
• Defensores enquadram isso como uma “opção nuclear” necessária para limitar scrapers abusivos e manter os custos de hospedagem sob controle, com a dificuldade do desafio ajustada a sinais do cliente (IP residencial, comportamento).
• Alguns propõem fazer o PoW produzir trabalho “útil” (cripto, dobramento de proteínas), mas outros temem que isso seja visto como algo semelhante a botnet; também são observados obstáculos técnicos (tamanho dos dados, coordenação).