## 无代码：一个Python包，用于…什么也没有 “无代码”Python包可以将你的Python代码转换为功能上等效的“无代码”——本质上，一个仍然*运行*你的程序但看起来像是空代码的文件。 安装需要Python 3.10+和一个虚拟环境（使用`pip install git+https://github.com/lemonyte/no-code`）。核心命令`no_code <文件名>`将Python文件转换为其“无代码”等效版本，并在顶部标记为`# coding: no`。运行这个“无代码”文件会执行原始程序。 你可以使用`yes_code <文件名>`恢复。该包还包括函数`no_code.nothing()`和`no_code.something()`，用于在“无”和“有”状态之间转换数据。它也接受通过stdin的输入。 本质上，它是一个受类似JavaScript项目启发，展示了一种独特的代码表示方法的趣味工具。
每日HackerNews RSS
无代码
No Code
30 天前
一个黑客新闻的讨论围绕着 GitHub 项目“No Code”（github.com/lemonyte），它巧妙地允许用户“不提交任何更改”。该项目因其巧妙的概念而受到关注，一位评论员指出它的艺术价值而非技术难度。
几位用户指出它受到了 Kelsey Hightower 早期“nocode”仓库的启发，该仓库在其 issue 区包含了一些幽默的互动。然而，这个版本将 Python 转换为可运行的空白字符。该项目自动在云端运行，并使用零宽度 UTF 字符巧妙地编码代码，导致一些人最初怀疑它什么也没做。
讨论还涉及向此类项目贡献的挑战，即在不增加不必要的复杂性的情况下进行贡献，并且也分享了一个 Perl 的等效版本。最终，它被呈现为一个轻松有趣的个人项目。
## Rouille：法语中的 Rust
“Rouille”是一个有趣的项目，允许开发者使用法语关键词和表达方式编写 Rust 代码。它被设计作为未来法国主权操作系统的一种潜在语言，旨在为编程带来“法国风情”。
该语言与标准 Rust 完全兼容，能够混合使用法语和英语代码。关键的 Rust 概念，如 `trait` 和 `impl`，分别被翻译为 `convention` 和 `réalisation`，其他关键词也随之调整。
Rouille 很大程度上是一个幽默的尝试，其许可证（“Publique Rien à Branler” - WTFPL 的法语翻译）和包含的法语俚语函数都证明了这一点。该项目欢迎通过 pull request 提交到“principale”分支的贡献，但劝阻使用脏话。项目以开玩笑的方式向法语国家政府征求捐款。
## 锈蚀：法语中的 Rust - Hacker News 讨论摘要
最近一篇 Hacker News 文章介绍了“Rouille”项目，该项目将 Rust 关键字翻译成法语。这场讨论引发了一场关于用母语编程的诡异感的热烈争论，尤其对于那些习惯于基于英语编程的人来说。
许多评论者，包括以英语为母语的人，都注意到在遇到非英语代码时会产生一种奇怪的脱节感，而另一些人则觉得它出乎意料地直观，特别是如果他们最初是用母语学习编程概念的话。 几个人指出了针对其他语言的类似项目（德语的“Rost”，日语等），以及像 Apple 的法语 BASIC 这样的本地化编程语言的历史先例。
对话还涉及翻译的挑战、潜在的幽默（在 Rouille 的例子中是故意的），以及更广泛的问题：考虑到潜在的协作和可读性问题，编程语言*是否应该*本地化。 最终，该项目被视为对语言和编码规范的一种有趣的探索，而不是试图取代英语作为主导编程语言的严肃尝试。
## Brash：Chromium浏览器严重DoS漏洞
Brash是一个影响Chromium浏览器（Chrome、Edge、Brave等）的严重拒绝服务（DoS）漏洞，影响超过30亿用户。它利用了Blink渲染引擎中的一个缺陷——`document.title`更新缺乏速率限制。通过快速注入数百万次标题更改，浏览器的主线程会被压垮，导致在15-60秒内完全崩溃。
该攻击易于执行，并且在众多浏览器和操作系统上均可有效演示。它不依赖于复杂的漏洞利用，而是通过饱和浏览器的资源来实现。除了立即崩溃之外，Brash还可以被武器化，进行延迟或计划执行，从而在关键时刻发起针对性攻击——从金融市场开盘到手术过程。
由于使用了不同的渲染引擎，Firefox和Safari不受影响，但Chromium的广泛使用使得这成为一个重大威胁。该漏洞凸显了一个根本性的架构缺陷，而不仅仅是一个简单的错误，需要核心设计变更来解决。作者提供了用于受控测试的工具，并强调仅用于安全研究的负责任使用。
针对基于Chromium的浏览器（如Chrome）的潜在拒绝服务（DoS）攻击已被报告，利用了`Document.title`属性。攻击涉及快速更新浏览器标题，导致进程间通信（IPC）泛滥，并可能导致整个浏览器崩溃，耗尽系统内存。
然而，许多评论员怀疑报告中的“攻击”是人工智能生成的垃圾信息，理由是其写作模式类似于大型语言模型，并且使用了不必要的十六进制表示法。
值得注意的是，Firefox、Safari和Pale Moon似乎不受影响或漏洞较小，这可能是由于它们不同的浏览器架构（单进程或后期采用多进程）。Pale Moon和Firefox表现出较慢的性能下降，但仍然可用，而Chrome则完全崩溃。问题源于Chromium的一个已知问题（自Chrome 49以来就有记录），即过多的IPC消息会使任务调度器不堪重负。
用户已经成功测试了该漏洞，并观察到不同浏览器之间的影响程度各不相同。一些人回忆起较简单的DoS方法在较旧的浏览器（如Internet Explorer）上有效。
## Quibbler：针对编码代理的自动化代码审查工具 Quibbler 是一款旨在自动评估和纠正编码代理的工具，可防止常见问题，例如捏造结果、跳过测试以及偏离编码风格或用户意图。它在后台运行，随着时间的推移学习项目模式并强制执行规则。 **两种集成模式：** * **MCP 模式：** 兼容所有代理，Quibbler 使用模型上下文协议。代理在更改后调用 `review_code` 工具，提供用户指令和修改计划。 * **Hook 模式：** 专为 Claude Code 设计，它利用通过钩子的事件驱动监控，被动观察操作并直接注入反馈。 **主要特点：** * **自动纠正：** 当代理重复犯错或忽略规范时进行干预。 * **上下文学习：** 维护项目上下文，建立理解并在 `.quibbler/rules.md` 中保存规则。 * **自定义：** 允许通过配置文件调整提示和模型。 * **持续审查：** 持续验证更改是否符合意图，检查幻觉并验证测试。 Quibbler 旨在通过自动化代码审查过程并确保一致遵守项目标准来提高代码质量和代理可靠性。它通过 pip 或 uv 提供，并为两种集成模式提供详细的设置说明。 [演示视频](demo.mp4)
## Quibbler：一个代码代理批评者
一个名为**Quibbler**的新工具（github.com/fulcrumresearch）已发布，旨在提高代码代理的可靠性。它充当这些代理的“批评者”，学习用户偏好，并在无需持续监督的情况下，帮助在较长任务中执行意图。
该工具旨在防止代理捏造结果或偏离预期目标。讨论强调需要 Anthropic API 密钥，这可能是在现有订阅之外的额外成本，但有人建议使用 Claude Code 子代理作为替代方案。
评论者们有趣地探讨了“Quibbler 堆栈”的概念——使用多个 Quibbler 来互相纠正，甚至设想了一个用于基于共识审查的“Quibbler 委员会”。对话还涉及管理代理及其批评者日益复杂的难题，从而引出关于需要“代理的代理”的幽默观察。创建者 etherio 可以在 Hacker News 上回答问题。
我们检测到您的浏览器已禁用 JavaScript。请启用 JavaScript 或切换到受支持的浏览器以继续使用 x.com。您可以在我们的帮助中心查看受支持的浏览器列表。帮助中心 服务条款 隐私政策 Cookie 政策 版权信息 广告信息 © 2025 X Corp.
消息： 控制元素：JFK 元素类型：APT ADL 时间：0124Z 停飞时间：31/0114Z - 31/0230Z 累积计划时间：30/1613Z - 31/0359Z 受影响的起飞设施：(手动) ZTL ZDC ZJX ZMA ZME ZID 之前的总延误/最大延误/平均延误：6796 / 549 / 227 新的总延误/最大延误/平均延误：7920 / 609 / 264 延误延长可能性：中等 影响因素：人员配备 / 人员配备 说明：
## Swift 编译器表达式类型检查改进 – 总结 本文详细介绍了为改进 Swift 编译器中表达式类型检查的速度和可靠性所做的持续努力，解决了令人沮丧的“无法类型检查”错误。 核心问题源于*基于类型的重载*的算法复杂度——当编译器必须根据类型在具有相同名称的多个函数之间进行选择时。 Swift 通过将类型检查转换为*约束求解*问题来解决这个问题。 然而，由于*析取约束*（本质上是类型的“或”选择），这可能会变得指数级缓慢。 编译器限制处理时间和内存使用量以防止无限期挂起，但这通常会导致无用的错误消息。 最近在 **Swift 6.2** 中的改进侧重于分析和优化现有算法，从而产生适度的速度提升。 **Swift 6.3** 引入了重大变化，包括优化的*析取选择*（首先选择最有希望的类型进行检查）和改进的*约束求解器竞技场使用*（减少内存消耗）。 未来的计划包括完善*绑定子系统*（编译器处理未知类型的方式）、删除性能“技巧”以及探索受 SAT 求解器启发的先进约束求解技术。 该团队还在考虑较小的语言更改，例如完善运算符查找和多态字面量，以进一步简化该过程。 这些努力旨在使 Swift 的类型检查更快、更健壮，并提供更可操作的诊断信息。
最近的ICE突击行动在纽约等城市引发了数字抵抗，居民通过手机摄像头和社交媒体记录特工活动。这种记录旨在揭露ICE的行动——促使特工戴上面具——并催生了象征反抗的病毒式模因。虽然让人想起社交媒体在过去运动（如阿拉伯之春和“黑人的命也是命”）中的作用，但当前的浪潮却带有一种孤注一掷的感觉。 然而，互联网是一把双刃剑。特朗普政府和右翼势力也在利用社交媒体来*识别*突击目标，例如一位油管博主的视频影响了运河街的搜查。ICE正在积极监控在线活动，利用Zignal Labs和Palantir等人工智能监控工具来追踪和分析潜在目标。 作为回应，ICEBlock、Red Dot和Eyes Up等反监控应用程序出现，允许用户分享ICE活动并记录潜在的滥用行为。然而，这些应用程序面临审查，在政府压力下从应用商店中被移除，凸显了一个日益增长的“政治全景监狱”，在线活动可能被用于对付个人。
## Kimi Linear：高效长文本注意力机制
Kimi Linear 是一种新颖的混合线性注意力架构，专为卓越的性能和效率而设计，尤其是在处理长序列时。它利用 **Kimi Delta 注意力 (KDA)** – 一种改进的门控 Delta 规则 – 来优化内存使用和速度。
测试表明，在较短的文本中（MMLU-Pro），Kimi Linear 的速度与全注意力机制相当，而在极长的文本中（RULER，128k tokens），速度提升了 **3.98 倍**。与传统的 MLA 相比，处理 1M tokens 的速度快 **6.3 倍**。
主要优势包括 **将 KV 缓存大小减少高达 75%** 和将解码吞吐量提高高达 **6 倍**。该模型在 5.7T tokens 上训练，在各种基准测试中表现优于全注意力机制，包括强化学习任务。
Kimi Linear 可通过 Hugging Face Transformers 获取，并可与 vLLM 部署以提供与 OpenAI 兼容的 API。KDA 内核已在 FLA 中开源。
## Kimi Linear：一种新的AI效率方法
Moonshot AI 发布了 Kimi Linear，一种新的语言模型架构，旨在提高处理长文本和对话的效率。其核心创新是“混合线性注意力”方法，在大部分处理中使用更快的“线性注意力”捷径，同时保留一些传统的“全注意力”以保证准确性。
这减少了所需的内存（“KV 缓存”）——减少了 75%——从而实现了 100 万字的大型上下文窗口。基准测试表明，Kimi Linear 在保持与现有模型相当的质量（MMLU-Pro 上为 51.0）的同时，响应生成速度快高达 6 倍，并且在较长文本上速度明显更快（在 128k 字的 RULER 上为 84.3）。
该模型利用 480 亿个参数，但一次只激活 30 亿个，进一步提高了效率。讨论的重点在于这种方法是否以牺牲准确性为代价来换取速度，以及运行这些模型的实用性——至少需要 48GB 的 VRAM 或利用云计算资源。 此次发布引发了关于 AI 开发未来、中国模型的数据隐私问题以及性能与效率之间平衡的争论。
这个Hacker News讨论围绕着佐恩引理，一个数学的基础原理。最初的帖子链接到一篇2008年的博客文章，解释如何使用该引理。
用户们争论其强度与选择公理的相对性。一位评论者认为佐恩引理只是在超限归纳过程中进行任意选择的能力的一种形式化表达——一种常见的教学方法。然而，另一位指出佐恩引理专门关注*有序*集合中的极大元素，比无限制的选择显得更受约束。
最终，共识是佐恩引理和选择公理在标准集合论假设下是等价的。 进一步的问题是，*没有*任意选择的超限归纳是否有意义，暗示核心公理可能仅仅是超限归纳本身的有效性。