我讨厌编译器

可复现构建与编译器确定性

• 对可复现构建有多重要存在强烈分歧。
  • 支持方：需要它来验证发行版二进制（例如 xz）、检查 GPL 合规性、支持会重新编译并比较哈希值的军方或高保障用户，并为审计人员提供证据，证明发布的二进制对应于经过审查的代码。
  • 怀疑方：认为这些大多只是理论上的；更倾向于使用签名和 CI 可追溯性，而不是逐位相同的输出；认为在意这些的用户应当自己从源码构建。
• 具体问题：
  • 编译器由于带有基于指针或未定义迭代顺序的数据结构（例如 LLVM 的 DenseMap）以及 ASLR 影响内部布局，而出现非确定性行为；建议的修复包括使用确定性容器（MapVector），并将其视为编译器 bug。
  • 时间戳和构建期宏如 __DATE__/__TIME__ 被引用为破坏可复现性的“简单”方式。争论在于这究竟是显而易见且有意的取舍，还是一个容易踩中的意外陷阱；有人认为这类宏就不该出现在编译器里。
• Nix/Guix：
  • 因其封闭式构建环境而受到称赞（例如通过 SOURCE_DATE_EPOCH 固定时间、输入哈希）。
  • 也有人指出，它们不能解决编译器 bug 或与并发相关的非确定性。

LLM、二进制与编译器

• 有一条讨论线索建议直接用二进制训练 LLM，以生成机器码。
• 大多数回应都持怀疑态度：
  • 二进制的微小扰动就会破坏可执行文件；不存在“看起来合理”的二进制。
  • LLM 在计数和细粒度精度方面表现不佳（例如精确的跳转偏移），即使它们在高层或模糊任务上做得不错。
  • 任何严肃的框架最终都会重新引入类似编译器/汇编器的结构。
• 还有关于“对人类难”与“对 LLM 难”的任务，以及莫拉维克悖论相关性的旁支争论。

低层 vs 高层环境

• 一种观点：低层工作高度依赖环境（硬件、CPU 代际、厂商协议），充满隐藏假设；因此 LLM 在这类场景下比在高层“包装”工作中更难发挥作用。
• 反对观点：简单、依赖较少的过程式代码相较于快速迭代的 Web 框架更稳定；讨论什么算“低层”（C + 操作系统库 vs GUI/Web 框架）。

Anubis 工作量证明防护

• 批评者把客户端 PoW 挑战比作恶意软件或加密货币挖矿：浪费能源、带来可访问性问题，而且对拥有充足算力的大型 AI 公司威慑有限。
• 支持者把它描述为遏制滥用爬虫、保持托管成本可控的必要“核选项”，并可根据客户端信号（住宅 IP、行为）自适应调整挑战难度。
• 有人建议把 PoW 设计成“有用的工作”（加密货币、蛋白质折叠），但也有人担心这会被视为类似僵尸网络；同时也指出了技术障碍（数据规模、协调）。