Odio los compiladores

Compilaciones reproducibles y determinismo del compilador

• Fuerte desacuerdo sobre cuán importantes son las compilaciones reproducibles.
  • Postura favorable: necesarias para verificar binarios de distribuciones (p. ej., xz), comprobar el cumplimiento de la GPL, apoyar a usuarios militares o de alta garantía que recompilan y comparan hashes, y dar a los auditores pruebas de que un binario entregado corresponde al código revisado.
  • Postura escéptica: considera que esto es en su mayoría teórico; prefiere firmas y trazabilidad de CI frente a resultados idénticos bit a bit; argumenta que los usuarios a quienes les importe deberían compilar desde el código fuente por sí mismos.
• Problemas concretos:
  • Comportamiento no determinista del compilador debido a estructuras de datos con orden de iteración basado en punteros o indefinido (p. ej., DenseMap de LLVM) y al ASLR que afecta al diseño interno; las correcciones sugeridas implican contenedores deterministas (MapVector) y tratar esto como errores del compilador.
  • Las marcas de tiempo y macros de compilación como __DATE__/__TIME__ se citan como formas “fáciles” de romper la reproducibilidad. Debate sobre si esto es un intercambio obvio e intencional o un fácil pie en falso accidental; algunos sostienen que esas macros no deberían existir en los compiladores.
• Nix/Guix:
  • Elogiados por sus entornos de compilación herméticos (p. ej., fijar la hora mediante SOURCE_DATE_EPOCH, hashing de entradas).
  • Otros señalan que no resuelven errores del compilador ni el no determinismo dependiente de la concurrencia.

LLMs, binarios y compiladores

• Una línea de discusión sugiere entrenar LLMs directamente con binarios para generar código máquina.
• La mayoría de las respuestas son escépticas:
  • Pequeñas perturbaciones en binarios rompen los ejecutables; no existe un binario “plausible”.
  • Los LLMs tienen dificultades con el conteo y la precisión fina (p. ej., offsets exactos de saltos), incluso si se desempeñan bien en tareas de alto nivel o vagas.
  • Cualquier arnés serio acabaría reintroduciendo estructura similar a la de un compilador/ensamblador.
• Debate lateral sobre tareas “difíciles” vs “fáciles” para humanos frente a LLMs y la relevancia de la paradoja de Moravec.

Entornos de bajo nivel vs alto nivel

• Una postura: el trabajo de bajo nivel es muy específico del entorno (hardware, generaciones de CPU, protocolos de proveedores), está lleno de supuestos ocultos; por tanto, los LLMs tienen más dificultades allí que en el “envoltorio” de alto nivel.
• Postura contraria: el código procedimental simple y con pocas dependencias es relativamente estable en comparación con frameworks web de rápido cambio; debate sobre qué cuenta como “bajo nivel” (C + librerías del SO frente a frameworks GUI/web).

Protección Anubis mediante prueba de trabajo

• Los críticos comparan los desafíos de PoW del lado del cliente con malware o mineros de criptomonedas: energía desperdiciada, problemas de accesibilidad y disuasión limitada frente a grandes empresas de IA con abundante capacidad de cómputo.
• Los partidarios lo presentan como una “opción nuclear” necesaria para frenar a scrapers abusivos y mantener manejables los costes de alojamiento, con la dificultad del desafío adaptada a señales del cliente (IP residencial, comportamiento).
• Algunos proponen hacer que el PoW realice “trabajo útil” (cripto, plegamiento de proteínas), pero otros temen que esto se perciba como algo similar a una botnet; se señalan obstáculos técnicos (tamaño de datos, coordinación).