威廉·德怀特·惠特尼提出了一条基本语言学原则：史前语言变化只能由历史时期可观察到的因素来解释，因为古代原因不可能与如今正在改变活语言的原因有本质差异。这一原则重塑了印欧语文学，尤其是关于名词为何获得性——阳性、阴性和中性——的争论。这个问题具有广泛的文化意义，因为性往往显得任意：在德语中 *der Fuss* 但 *die Hand*；在拉丁语中 *hīc hortus* 但 *haec planta*；在希腊语中 *ὁ πλοῦτος* 但 *ἡ πενία*。既然这种三重性别遍及较古老的印欧语言，它必定可追溯至原始印欧共同体。惠特尼的方法还说明了更大范围的方法论转变：19世纪早期和中期的语言发展理论与现代观点不同，不仅在比较语言学中如此，在相邻的语文学和历史研究中也是如此。
每日HackerNews RSS
Hacker News 讨论了 Iosevka——一款由代码生成的开源无衬线/粗衬线等宽字体。评论者称赞其可定制性、窄宽度、广泛的字形覆盖以及 PatEL DSL；许多人分享了自定义构建和衍生字体，如 Ioskeley Mono、Pragmasevka 和 Sarasa Gothic。有些人觉得它太窄，或不喜欢代码连字，更偏好 Berkeley Mono、JetBrains Mono、Fira Code、Commit Mono 或 IBM Plex Mono。另一些人批评该网站的 `font-display: swap` 以及发布包体积过大。长期用户称它为日常主力，尤其是在终端和代码场景中，同时指出需要调整宽度或禁用连字。总体而言：人们对 Iosevka 的灵活性和设计给予高度赞赏，而个人品味驱动了替代选择。
瑞典曾预计到2030年实现无现金化，其Swish支付系统和银行纷纷弃用现金。俄罗斯入侵乌克兰改变了优先事项：瑞典央行敦促成年人家里备有1000克朗，政府建议使用现金以加强危机应对能力。7月，有人工收银员的重要商店被要求接受实物现金。然而，大多数瑞典人仍偏好数字支付：2025年，只有5%的人上次到店购物时使用现金，低于2023年的10%和15年前的40%。挪威和丹麦也呈现类似趋势。这一转变引发了对排斥老年人的担忧，并掀起了政治辩论。瑞典央行行长埃里克·泰丁表示，现金有助于在停电或破坏活动面前保持韧性，并以乌克兰战时的适应为例。一些企业反对接受现金，但官员认为，在数字化社会中，实物货币仍是重要的后备手段。
文章认为 C 的手动 `malloc`/`free` 容易出错且速度慢，尤其是在大量小分配时。Arena 分配器通过分配一大块内存并用 bump 指针从中分发片段来解决这个问题。内存按相近的生命周期分组，然后一次性释放或重置。这提高了性能，减少了泄漏，并简化了所有权。该实现定义了一个 arena 结构体，用于跟踪 data、size 和 used；还包含创建、对齐分配、通过复制进行重新分配、清空和释放的函数。分配失败通过带有成功标志的结构体返回。作者展示了一个字符串转换示例：将 arena 传入函数使分配变得显式，并让调用者控制生命周期。当不再需要内存时，可以清空或丢弃 arena。作者建议采用 arena 来获得更好的开发者体验，同时指出该实现简单且个人化。
Hacker News 的一个讨论帖讨论了一篇关于在 C 中实现区域分配器的文章。评论者喜欢用区域分配器处理基于阶段的内存——解析、处理、丢弃——因为它们能快速批量释放并减少碎片。他们指出，区域分配器无法释放单个分配，因此把短生命周期的临时分配和长生命周期分配混在一起有风险；使用分开的区域分配器，再加上显式复制和调试用高水位跟踪，会有帮助。批评者指出了示例代码中的问题：自定义 u32/f32 typedef、不安全的 MIN/MAX 宏、强制转换 malloc 返回值、void* 指针算术、固定的 8 字节对齐、大小/对齐计算中的溢出，以及不可移植的假设。随后围绕可移植性与实际测试展开争论；一些人认为 C 的抽象机很重要，代码应通过警告、sanitizer 和静态分析检查，另一些人则说，只要记录并测试过，平台假设就没问题。有人称赞 [[nodiscard]] 和结构体返回设计。有人问为什么区域分配没有标准化；另一些人说其生命周期限制使其不适合通用用途。
在 2026 年 9 月起的 Android 17 构建中，`wcscspn()` 和 `wcspbrk()` 存在缺陷：如果拒绝字符集中有两个或更多字符，且这些字符全都低于 U+0100，扫描会在遇到被搜索字符串中第一个大于等于 U+0100 的字符时停止，并错误地将其报告为匹配。`wcsspn()`、`wcschr()`、`wcsrchr()`、`wmemchr()` 和 `wcsstr()` 均正确。这会破坏使用 ASCII 分隔符（例如换行或通配符扫描）的代码，当文本包含表情符号、中日韩文字、西里尔字母、希腊字母或拉丁扩展字符时。六月的公开 `android17-release` 源码是正确的，因此该回归是在九月构建中出现的。已发布的 libc 使用一个 256 字节的查找表，并在 `c >= 0x100` 时错误停止，而不是继续扫描；`wcspbrk` 继承了这个缺陷。现有的 bionic 测试只使用 ASCII。实际影响包括 Visual Pinball/VBScript 在带表情符号的注释上失败。受影响的设备包括 Pixel 7 和 Pixel 8a；一个 Nothing Phone 2 构建版本未受影响。
谷歌日益延迟的 AOSP 源代码发布，正迫使开发者反汇编专有库以发现并报告漏洞。评论者将此归因于欧盟的生态设计法规：一旦源代码发布，该法规就会启动为期四个月的更新倒计时。通过扣留公开的 AOSP 更新，谷歌让三星等 OEM 合作伙伴有更多时间在法律时钟开始前准备自己的发布版本。批评者认为，这使用户在长达八个月的时间里暴露于已知漏洞之下，并损害了 Android 的开源性质。讨论还涉及更广泛的担忧：谷歌的反竞争行为、对 Android 进行分叉的难度，以及可解锁设备日益减少。
kcgi 是一个极简、安全、可审计的开源 CGI 和 FastCGI 库，用于 C/C++ Web 应用。它处理 HTTP 输入——查询字符串、Cookie、请求体和 multipart——并进行验证，还支持压缩、认证、缓存、调试和格式化写入器。它的关键区别在于对不可信解析进行沙箱化和进程隔离，使用 seccomp、pledge、sandbox_init 或 Capsicum。当前版本为 1.0.1（2025-11-17），修复了 macOS 共享库命名问题。它运行于 Linux、各类 BSD、Solaris、OmniOS 和 macOS Mojave 及以上版本。可通过包管理器安装，或使用 bmake 和 zlib 从源码构建。可部署在 Apache、nginx 或 OpenBSD httpd 上；FastCGI 可使用 kfcgi。使用 pkg-config 编译。手册页是权威文档；教程涵盖 CGI、Cookie、FastCGI、验证、页面、C++、pledge 和 CORS。测试使用 make regress、kcgiregress 和 AFL。性能开销来自进程派生/沙箱化和数据传输，但仍保持合理。
一个 Hacker News 帖子讨论了 Kcgi，一个面向 C/C++ 的极简 CGI/FastCGI 库。评论者就使用 C 编写 Web 应用展开争论，并提到最近一篇关于用 C 写 CGI 的文章。一些人分享了对 Perl 的怀旧情绪，认为只要谨慎，C 仍然可行，并称赞其性能和控制力；另一些人警告内存安全、段错误会导致整个后端崩溃，以及生产率较低，尤其是在大型团队中。性能比较指出，C/C++/Rust 可比 Node 快 10–50 倍，但数据库瓶颈往往占主导。例子包括用 C 写的 TodoMVC、一个 C++ 网络栈和 OkCupid。有人说大多数应用不需要这种速度；另一些人则为选择任何语言辩护。该讨论既充满对极简、快速的 C Web 栈的热情，也混杂着对安全性和可维护性的怀疑。
请提供需要翻译的内容。
**摘要：**
Hacker News 上的一场讨论聚焦于《The Register》的一篇文章，该文章指责 Anthropic 借其对分布在低功耗物联网（IoT）设备上的自复制 AI 群的研究，煽动对 AI 末日的恐惧。
评论区的主流观点持怀疑态度。许多人认为 Anthropic 的警告是一种策略性的“制造恐慌、不确定性和怀疑”（FUD），旨在促成政府监管、遏制开源模型竞争对手，并在 IPO 前建立人为壁垒。从技术角度来看，批评者指出，在性能受限的消费级硬件或物联网设备上运行大语言模型（LLM）层，不仅速度慢到不切实际、发热明显易被察觉，而且效果远不如传统的恶意软件。
少数评论者则为该研究辩护，认为仅仅因为一项快速发展的技术目前尚不可行就全盘否定是短视的。他们主张，未来的模型压缩技术可能会使分布式自主蜂群成为现实，从而让传统的“关机”阻断机制失效。
此次讨论还引发了一场关于该社区整体倾向的更深层探讨：用户们争论 Hacker News 究竟是一贯对 AI 进展抱有偏见，还是对企业主导的“AI 安全”论调保持理所当然的审慎与怀疑。
arXivLabs 是一个框架，允许合作者直接在我们的网站上开发和分享新的 arXiv 功能。与 arXivLabs 合作的个人和组织都已认同并接受我们开放、社区、卓越和用户数据隐私的价值观。arXiv 致力于这些价值观，并且只与遵守这些价值观的合作伙伴合作。有能为 arXiv 社区带来价值的项目想法？了解有关 arXivLabs 的更多信息。
目前在 Anthropic 从事 Claude 相关工作，并在那里领导了 Claude.ai、Cowork 和 Code Desktop 的工程。作为 Electron 共同维护者和多产的开源维护者，其专注于让人们借助 AI 提高生产力。其为 Electron、Language Model Builder、MCBP、windows95、macintosh.js、clippy 等项目做出贡献或进行维护，并经常构建有趣的项目。 此前：在 Notion（2023–2025）领导 Web 基础设施和桌面应用团队；在 Stripe（2021–2023）领导支付集成体验；在 Slack（2016–2021）担任 Senior Staff Engineer/EM，支持 C++ Electron 团队和 Slack 桌面应用，并撰写了 O’Reilly 的《Introducing Electron》；在 Microsoft（2014–2016）担任开源工程师，创建了 windows-build-tools 和 npm-windows-upgrade；以及在 Microsoft Germany/Silicon Valley（2011–2014）担任 Startup Developer Evangelist。更早之前，曾任 Apfeltalk.de 执行编辑（2007–2011），开发了拥有百万玩家的《Awesome Zombie Sniper》，并曾在牛津互联网研究所和杜塞尔多夫大学学习。
HN 评论者讨论了 Felix Rieseberg 的新个人网站：一个由一群 Claude 智能体制作、用 AI 编码的雄心勃勃的 3D/WebGL 体验。许多人称赞其复古、舒适、Flash 时代的美学和技术新奇性；其他人则批评它卡顿、耗电、无障碍性差，并且自动播放音频，还有人报告浏览器卡死。一篇链接文章解释了构建过程，引发了对 AI 生成艺术/代码、达克效应，以及“氛围编程”能否产出优化软件的争论。评论者提到柏林/华沙桥的景色，将其与旧 Flash 网站比较，并询问成本/token。讨论还岔到 Electron 的遗产、AI 工具构建以及 GUI 的未来。总体而言：一个令人印象深刻但两极分化的 AI 展示——对某些人来说富有创意且怀旧，对另一些人来说则没有灵魂且不实用。
启用 JavaScript 和 Cookie 以继续
在 Hacker News 讨论“框架还重要吗？”中，评论者争论 AI 编程是否让框架过时。大多数人认为框架仍然重要——甚至更重要——因为它们提供结构、共享约定、护栏和抽象，防止人类和智能体产出难以维护的“LLM 泥潭”。一些人更青睐浏览器原生 API、极简库、SSR、Tailwind/Alpine 或自定义框架，以减少活动部件。其他人表示，LLM 已经了解主流框架，能处理样板代码，但其非确定性和不可预测的知识让依赖它们有风险。一个反复出现的主题是：未来框架应优化为约束智能体、最小化每个功能的代码量、易于审计，并通过架构测试强制执行规则。在审查 AI 生成代码时，框架也有助于可读性。批评者指出，框架会增加臃肿、限制和破坏性变更风险；原生标准可能更稳定。总体而言，框架仍然有用，但其价值正从人类工效学转向智能体治理和共享、可验证的约定。