## Compyle 低延迟沙箱的探索
Compyle 提供即时云开发环境，目标是提供无缝、本地化的体验。 最初，他们的架构将用户请求路由至中央 socket 服务器以配置沙箱，导致不可接受的 10-30 秒启动时间和 >200 毫秒的延迟——在 IDE 和终端中尤其明显。 安全性并非首要问题，但速度至关重要。
第一次改进来自于实施“预热池”，即预配置的机器，将启动时间减少到 50 毫秒。 然而，由于通过 socket 服务器的额外网络跳转，延迟仍然是一个瓶颈。
关键的解决方案是消除这个中间人。 通过利用 Fly.io 的基础设施，Compyle 转向用户和沙箱之间的直接连接，通过 JWT 处理授权，并将计费/持久化逻辑移动到 LLM 路由器。 Fly.io 的“fly replay”功能进一步优化了路由。
虽然这大大提高了靠近圣何塞数据中心的用户性能，但对于距离较远的用户来说，延迟仍然很高。 最后一步是在美国、欧洲和亚洲部署地理分布式的预热池。 这将终端往返时间从超过 200 毫秒降低到惊人的 14 毫秒，证明了**距离很重要**，并且**简单是关键**——通常，最佳的性能提升来自于移除不必要的 инфраструктура。
每日HackerNews RSS
## 低延迟开发沙箱：摘要
Compyle.ai 解决了开发沙箱中的显著延迟问题，将端到端延迟从 200 毫秒降低到 14 毫秒。他们的过程包括迭代地简化架构，意识到额外的路由层引入了瓶颈——即使使用快速的 KV 存储。
解决方案是移除路由数据库查找，将路由信息（区域、集群 ID）直接编码到子域名/主机名中，利用 Anycast 和基于延迟的 DNS。他们还使用浅层预热池（每个区域两台机器），并带有回退机制来管理成本，以及“重放”功能以加快后续请求。
讨论强调了在预热池中平衡成本和性能的挑战，以及像 Pingora 这样的工具在连接管理方面的优势。他们还探讨了像 AWS Lambda 的 Firecracker 用于在 GCP 上进行冷启动的替代方案。一个关键的收获是“删除代码”可以提高性能，以及沙箱对于在“YOLO”模式下运行的编码代理高效完成任务的重要性。该帖子引发了关于 SaaS 沙箱与自托管解决方案的争论，以及对优化网络通信的需求。
## Waypoint-1：交互式实时世界生成
Overworld的Waypoint-1是一种新型交互式视频扩散模型，允许用户实时进入并控制程序生成的世界。与为简单控制而微调的现有模型不同，Waypoint-1是*针对*交互性进行*训练*的，能够实现鼠标和键盘输入的自由相机移动，并且具有零延迟。
Waypoint-1基于一个使用10,000小时游戏录像训练的Transformer，利用“扩散强制”和“自强制”技术来实现逼真、稳定的帧生成。这即使在消费级硬件上也能提供流畅的体验。
**WorldEngine**推理库为Waypoint-1提供支持，它是一个高性能的Python工具包，针对速度和开发者易用性进行了优化。目前在5090 GPU上可实现30-60 FPS。
Overworld将于2026年1月20日举办一个黑客马拉松，以鼓励使用WorldEngine进行开发，奖品为5090 GPU。
**试用：**[https://overworld.stream](https://overworld.stream)
## Waypoint-1：实时交互式视频扩散
一个名为Waypoint-1的新开源项目，实现了实时交互式视频扩散，创造动态演变的虚拟世界。用户报告称，只需在生成的空间内移动，就能体验到在截然不同的环境之间无缝切换——从奇幻游戏场景到科幻抽象。
目前该模型缺乏空间记忆和一致的对象识别能力（导致尽管有提示词，结果仍不可预测），但开发者对其潜力感到兴奋，并将其比作GPT-3的早期阶段。该模型可通过Hugging Face获取，可以在配备强大GPU的本地机器上运行（RTX 5090可实现小模型20-30fps），也可以通过Runpod等服务运行。
该项目的CEO澄清了许可协议：“小”模型完全开源（Apache），而“中”模型目前使用更严格的许可协议（CC BY-SA-NC 4.0）。开发者也在探索互补项目，如NitroGen，并考虑导航解决方案以解决延迟问题。
## Intel 8086 处理器：深入其算术逻辑单元
Intel 8086 于 1978 年发布，是一款重要的 16 位处理器，开启了 x86 架构。 其算术逻辑单元 (ALU) – 能够执行 28 种操作 – 是一个复杂的组件，并非直接由机器码控制，而是通过两步微码过程控制。 首先，微码配置 ALU，然后第二条微指令检索结果。
8086 使用微码，每条指令分解为多条微指令，巧妙地利用相同的微码进行类似的操作，如 ADD、SUB 和 AND，具体的 ALU 功能由原始机器码决定。 这是通过一个名为“XI”的系统实现的，用指令定义的运算替换微码的默认设置。
ALU 本身使用查找表生成进位和输出信号，并根据控制信号进行配置。 管理这种复杂性需要专门的电路 – PLA 和触发器 – 来记住微指令之间的预期操作，并处理大量的指令特定调整。 这种复杂控制系统凸显了 8086 的 CISC（复杂指令集计算机）设计的固有复杂性，与 RISC 处理器的更简单方法形成对比。 尽管其复杂，但 8086 的架构被证明是极其成功的，为现代计算奠定了基础。
## Intel 8086 ALU：Hacker News 讨论摘要
一篇关于 Intel 8086 处理器算术逻辑单元的详细文章引发了 Hacker News 的深入讨论。作者 Ken 澄清说，8086 很大程度上是一种权宜之计，旨在作为 Intel 更雄心勃勃的 iAPX 432 准备就绪之前的过渡，并保持与 8080 的兼容性。
评论者探讨了如果从后视的角度来看，8086 的设计可以改进哪些方面。反复出现的主题包括混乱的指令编码、缺乏对无效指令的捕获、BCD 指令的实用性以及分段内存的效率低下。许多人认为，更像 RISC 的架构，具有扁平的地址空间和内存映射的 I/O，会更好。
讨论还深入研究了 8086 采用小端字节序的历史原因，将其追溯到 Datapoint 2200 的串行处理。最后，人们发现 8086 *确实* 使用了微代码来处理大多数指令，这为其设计增加了另一层复杂性。总体情绪是理解当时约束条件下的设计选择，但承认存在许多潜在的改进。
## Cloudflare 路由泄露总结 – 2026年1月22日 2026年1月22日，Cloudflare 经历了从迈阿密数据中心发起的 25 分钟 BGP 路由泄露，影响了 Cloudflare 客户和外部网络。泄露是由计划中的自动化更新期间的错误配置触发的，该更新旨在移除通过迈阿密路由的 IPv6 流量。 该错误导致 Cloudflare 不小心将从对等互联网络接收到的路由，同时向对等互联网络*和*供应商通告——违反了标准的“无谷”路由原则。这导致 Cloudflare 迈阿密-亚特兰大骨干网上的拥塞，部分流量的延迟增加和数据包丢失。此外，泄露路由中的流量被 Cloudflare 的防火墙过滤器丢弃。 根本原因是一个允许将“内部”路由对外通告的宽松策略变更。Cloudflare 已撤销该变更，暂停了自动化，并正在实施多项预防措施，包括修补自动化故障、添加 BGP 社区保护以及改进 CI/CD 管道中的策略评估。他们还在积极支持包括 RFC9234 和 RPKI ASPA 在内的全行业工作，以增强路由安全性并防止未来的泄露。Cloudflare 对造成的干扰表示诚挚的歉意。
## Cloudflare 路由泄露事件 - 摘要
2026年1月22日，Cloudflare发生一起BGP路由泄露事件，主要影响IPv6流量的网络性能。该事件源于一项旨在移除与波哥大前缀相关的迈阿密BGP宣告的配置更改。然而，自动化更改无意中从Juniper策略中移除了一个关键条件，导致Cloudflare将从对等体接收到的路由重新宣告给这些对等体。
这形成了一个环路，增加了延迟和带宽使用，因为流量不必要地通过迈阿密路由。问题通过推送更改以移除错误的BGP宣告得到解决。
讨论强调了BGP系统的脆弱性以及改进测试和变更管理的需求，包括模拟真实世界的路由。人们对这些事件的频率以及Cloudflare的声誉表示担忧，并提出了利用诸如路由拍动之类的工具进行飞行前检查，以及利用社区来防止类似错误配置的建议。该事件还引发了关于快速部署与稳健工程实践之间平衡的争论，尤其是在人工智能辅助编码的背景下。
## Claude 自动压缩功能故障 - 摘要 Claude.ai (网页版和桌面版) 的自动压缩功能目前已损坏，尽管官方显示已于1月15日修复。该问题是在1月14日故障之后出现的。 当上下文窗口填满时，没有自动压缩以继续对话，而是消息会静默返回到输入框，或者出现“限制已达”的错误——即使远低于20万token的限制。自动压缩功能*从不*触发。 此故障影响 Claude.ai 项目中的聊天（非项目聊天状态未知），并且该功能之前可以正常使用。用户报告称这是一个回归问题，因为该功能在1月14日之前有效。目前 Claude.ai 没有专门的错误追踪器，因此提交此报告。
## Kotlin 的丰富错误：总结 Kotlin 正在通过“丰富错误”来改进其错误处理机制，利用联合类型创建更明确和类型安全系统。该功能目前处于实验阶段，允许函数返回类似 `Int | ParseError` 的类型，清晰地在函数类型签名中指示潜在错误——这不同于依赖 `try-catch` 块。 这种方法受到 Elm 和 Rust 等语言的启发，将错误提升为一等公民，提高类型安全性并减少由隐藏异常引起的运行时意外。丰富错误旨在简化目前由 Arrow 的 `Either` 和 `Result` 等库处理的常见模式，提供 Kotlin 原生的解决方案。 其优点包括改进的性能（避免异常开销）、通过基于值的错误增强可组合性以及编译器强制的穷尽性。虽然并非旨在*完全*取代现有库，但丰富错误承诺提供一种更惯用且可能更高效的方式来直接在 Kotlin 类型系统中处理错误，预示着向显式错误处理作为标准转变。
## Kotlin 的丰富错误：总结
Kotlin 正在引入一种新的错误处理系统，旨在改进传统的异常处理方式。该系统利用“丰富错误”——代表错误的数值，而不是通过异常中断程序流程。目标是提供一种更具类型安全性和可组合性的方法，类似于 Rust 和 Haskell 等语言中的 `Result<T, E>` 或 `Either` 类型。
讨论的重点在于异常和错误值之间的权衡。虽然异常在正常执行路径上成本较低，但在触发时成本较高。错误值迫使开发者显式处理潜在的失败，从而提高程序的健壮性，但如果使用不当，可能会导致代码冗长。
一个关键的考虑因素是与 Java 的互操作性。Kotlin 的丰富错误在 JVM 上将表示为 `Object`，这可能会限制无缝集成。然而，Kotlin 也用于非 JVM 环境，这证明了即使不能完美翻译成 Java 的特性也是合理的。
最终，争论的焦点在于这个新系统是否会鼓励更好的错误处理实践，或者只是增加了复杂性。该特性计划于今年夏天在 Kotlin 2.4 中发布。
这篇帖子详细介绍了开发一种开源的、eBPF加速的宽带网络网关（BNG），旨在直接运行在光线路终端（OLT）硬件上，以解决传统集中式BNG的局限性。目前的ISP架构依赖于昂贵且单点故障的BNG设备来处理所有用户流量。作者建议将BNG功能分布到网络边缘，利用现代Linux和eBPF/XDP的强大功能，在通用硬件上实现ISP级别的包处理。 eBPF/XDP之所以被选择，是因为它操作简单且性能足够（每OLT 10-40 Gbps），优于VPP等替代方案。该架构具有一个中央控制平面（Nexus），用于配置和IP分配，而用户流量仍然局限于每个OLT-BNG。一个两层DHCP系统利用内核中的快速路径处理已知用户，并使用较慢的路径处理初始请求。IP分配发生在RADIUS认证时，简化了DHCP并实现了基于eBPF的快速路径操作。 该实现是一个包含嵌入式eBPF程序的单个Go二进制文件，目前在白盒OLT上进行测试，提供了一种比传统解决方案更便宜的替代方案。虽然尚未达到生产就绪状态，但作者正在考虑开源该项目，相信分布式BNG架构可以为ISP提供更高的弹性、更低的延迟和更简单的操作。
## 淘汰ISP设备：摘要
最近的Hacker News讨论围绕一篇关于使用eBPF/XDP技术构建宽带网络网关（BNG）的新方法展开。BNG是ISP基础设施的关键组件，传统上是昂贵且集中的设备。该项目旨在将BNG功能分布到通用硬件上，从而可能降低供应商锁定和成本。
讨论明确了BNG是FTTX等效的BRAS（宽带远程接入服务器）。虽然技术实现前景看好，但评论员指出，思科和Metaswitch等大型公司之前的尝试面临商业障碍。难点在于说服成熟的ISP从可靠但功能丰富的传统系统切换到更新、可能不太全面的解决方案。
讨论还涉及这项技术可能绕过政府审查的可能性，但有人指出，在更广泛的互联网基础设施（IP传输、互联）中仍然存在可以执行限制的控制点。该项目的可行性取决于找到愿意拥抱颠覆性技术，尽管集成到现有网络和满足监管要求很复杂的客户。
解决方案Quick360Gallery使用方法服务条款隐私政策© 2026 Easy3DMaps.com我们通过广告赚取佣金。感谢您的支持！
## Easy3DMaps：新的3D地图网站
一个名为easy3dmaps.com的新网站允许用户创建3D地图游览和“可玩”的直升机环绕飞行。创建者“dobodob”正在寻求用户反馈和项目知名度，目前正在使用Google Maps API的免费版本。
Hacker News上的讨论显示，相机移动的流畅性和Google Maps API的潜在扩展成本是挑战。来自ayvri.com的另一开发者根据他们构建类似渲染器的经验提供了建议。人们对盈利模式表示担忧，一些人质疑该项目在Google Maps API成本方面的经济可行性。
用户还提供了UI/UX反馈，指出移动搜索结果可见性问题，并建议降低默认旋转速度以避免晕动症。创建者正在积极回应反馈并致力于改进，包括解决移动搜索问题。 此外，还透露该项目是由一对兄弟共同开发的，其中一人自豪地分享了他们的工作。
福布斯最近报道，微软会定期与联邦调查局分享BitLocker恢复密钥，使执法部门能够解锁加密硬盘。BitLocker是Windows的全盘加密，会自动将恢复密钥上传到微软的云端，绕过了本应保护用户数据的安全措施。 这一做法是在一起与关岛疫情失业救济计划相关的欺诈调查中浮出水面的，联邦调查局通过搜查令获得了三台加密笔记本电脑的密钥。微软证实，他们每年会满足大约20个类似的请求。 然而，像约翰霍普金斯大学的马修·格林等安全专家警告说，存在重大的隐私和安全风险。集中存储密钥使其容易受到泄露——如果微软的云端受到入侵，黑客可以获得解密密钥，并凭借对硬盘的物理访问，解锁敏感数据。这一做法使微软在密钥安全方面与其他科技公司相比显得越来越不同寻常。
## 微软与联邦调查局访问BitLocker密钥
一份最新报告显示，微软一直在向联邦调查局提供BitLocker加密密钥，以解锁嫌疑人的笔记本电脑，平均每年约20次请求。这是因为Windows 11上的BitLocker默认会将加密密钥上传到微软账户。
虽然被描述为微软“提供”密钥，但评论员澄清，该公司有法律义务遵守有效的搜查令。许多人认为这并非侵犯隐私，而是执法部门的一项必要功能，尤其是在调查疫情失业欺诈等犯罪行为时。然而，隐私倡导者表示担忧，强调存在滥用的可能性。
想要更大控制权的用户可以禁用将密钥上传到微软账户的功能，但一些人警告说，由于软件故障可能会意外重新启用。另一些人建议切换到Linux或使用替代加密工具，如LUKS/VeraCrypt。讨论还指出，Apple的FileVault存在云密钥备份，核心问题是如果需要强大的隐私保护，应避免将加密密钥存储在云端。最终，争论的中心在于平衡安全性、便利性和个人隐私。
玉米的证明
Proof of Corn
2 天前
## 玉米证明：人工智能能耕种吗？ 作为对人工智能影响物理世界能力的挑战的回应，“玉米证明”是一个展示人工智能驱动玉米种植的项目。其核心理念并非人工智能*执行*体力劳动，而是*管理*它——就像人类农场经理一样。 该项目使用Claude Code (Opus 4.5) 作为“大脑”，汇集来自物联网传感器、天气API和卫星的数据，以便就种植、灌溉和收获做出数据驱动的决策。然后，它协调人类操作员和设备。 目前处于早期阶段（2026年1月），该项目专注于在爱荷华州获得土地并建立必要的基础设施。团队正在GitHub上公开跟踪所有代码、决策和支出。初始预算很低（花费12.99美元），该项目旨在在十月实现完全收获，证明人工智能可以成功地从种子到餐桌地协调玉米农场。他们正在寻找在爱荷华州拥有土地线索和农业专业知识的合作者。