关于按住版权联系我们创作者广告开发者条款隐私政策和安全性YouTube的工作原理测试新功能© 2026 Google LLC
每日HackerNews RSS
关于按住版权联系我们创作者广告开发者条款隐私政策和安全性YouTube的工作原理测试新功能© 2026 Google LLC
## 美联储与政治压力 - Hacker News 总结
美联储主席杰罗姆·鲍威尔发表声明，可在美联储网站上找到 ([https://www.federalreserve.gov/newsevents/speech/powell20260...](https://www.federalreserve.gov/newsevents/speech/powell20260...))，引发了 Hacker News 的讨论。鲍威尔谈到了政治干预货币政策的令人担忧的可能性，特别提到了因抵制总统对利率的偏好而可能面临的“刑事指控”。
对话显示出对机构独立性受到侵蚀的广泛担忧。许多评论员对总统干预经济政策的想法表示震惊，担心这会导致不稳定，并将短期政治利益置于健全的经济原则之上。
讨论范围从指责“香蕉共和国”情景到关于特朗普动机和对美国治理的更广泛影响的辩论。一些人认为特朗普只是想要更低的利率，而另一些人则怀疑他有一个更深层的策略，以指责现任政府的政策。 还有一种对政治体系的幻灭感，一些人质疑两党的诚信。
## 使用文件系统沙箱化智能体：一种新方法
智能体AI的最新进展利用具有shell和文件系统访问权限的沙箱环境，模仿大型语言模型（LLM）编码任务中使用的技术。这种方法具有优势，例如与基于RL的编码训练对齐，并通过单个强大的Bash接口简化工具集。文件系统还能够实现自然模式，例如计划/草稿文件和高效的长上下文处理。
然而，将其应用于现有应用程序会带来挑战：确定何时以及如何在应用程序的数据库和沙箱文件系统之间同步数据，以及管理人工编辑。一个关键的解决方案是**FUSE（用户空间文件系统）**，一个允许在内核之外创建文件系统的框架，将任意数据暴露为文件。
该示例演示了使用FUSE构建一个AI驱动的电子邮件平台智能体。该智能体与镜像电子邮件结构（收件箱、已发送等）的文件系统交互，而FUSE将文件系统操作（如`ls`或`mv`）转换为数据库查询。这种抽象允许智能体使用熟悉的命令直观地管理电子邮件。
完整的实现可在GitHub上找到，未来的工作可以探索将这种方法与传统的智能体循环进行评估，并通过沙箱提供商API简化FUSE集成。最终，虚拟文件系统为智能体AI的人体工程学上下文工程提供了一条有希望的途径。
## LLM 代理的 FUSE：摘要
最近 Hacker News 的讨论集中在使用 FUSE（用户空间文件系统）为语言模型（LLM）代理提供数据和工具的访问权限。jakobemmerling 提出的核心思想是将各种数据源（如数据库、电子邮件或 API）表示为文件系统，为 LLM 提供熟悉且直观的接口。
一些人认为这种方法有价值，尤其对于 Google Drive 或 Notion 等文件交互自然存在的平台。另一些人则认为这是不必要的间接操作。批评者认为，LLM 可以使用现有工具和权限直接与 API 和数据库交互，从而避免 FUSE 层的开销和潜在的许可问题。人们对性能（通过 API 调用进行缓慢的文件访问）和准确地将现实世界数据映射到文件系统抽象的复杂性表示担忧。
讨论中的替代方案包括利用现有的 API、使用存储组合器，以及探索诸如 `git-snap-fs`（将 Git 仓库暴露为文件系统）和 SQLite 扩展以进行文件 I/O 之类的工具。一个关键的争论点是“沙箱”的定义，一些人认为容器和虚拟机*是*沙箱，而另一些人则强调真正的沙箱化需要严格控制系统调用和资源访问。最终，这场讨论凸显了 LLM 与外部系统之间有效接口的持续探索。
## 服务器管理：SSH访问 vs. 可观测性 的争论
一篇博客文章引发了 Hacker News 的讨论，内容是关于放弃服务器的 SSH 访问，转而支持使用“可观测性堆栈”进行管理。作者有意在新服务器上禁用 SSH，拥抱更自动化、以容器为中心的方法。
这引发了争论。一些人认为 SSH 对于诊断*未知*问题仍然至关重要——连接调试器、检查系统值，以及通常理解意外行为——这些是可观测性工具难以处理的。他们担心失去深入调查超出预定义指标的问题的能力。
另一些人则支持可观测性，认为追踪和分析等工具对于常见问题来说更快、更高效。他们设想一个未来，仪表盘和自动化洞察将取代手动 shell 访问。然而，有人担心仅仅依赖预构建的工具，以及当这些工具无法提供答案时调试的困难。
这场对话涉及“宠物”服务器（单独管理）和“牲畜”（易于替换）之间的权衡、不可变基础设施的好处，以及基本系统管理员技能的重要性。最终，这场讨论凸显了服务器管理理念的转变，一些人拥抱自动化和可观测性，而另一些人则坚持直接访问和深入系统理解的价值。
这个项目详细介绍了贪吃蛇游戏（小于16KB）的创建，该游戏设计为原生运行在Windows、Linux和Web浏览器上——所有这些都来自单个源文件。受到Justine Tunney的libc项目的启发，作者旨在实现跨平台兼容性，同时保持较小的二进制文件大小。 游戏具有标准的贪吃蛇游戏玩法，包括计分、关卡和不同的水果价值。它被实现三次：C语言用于Windows（使用WinAPI和压缩stub），C语言用于Linux（使用clang和X11，并使用lzma解压缩），以及JavaScript用于浏览器（HTML5 Canvas）。 这种多语言方法的关键在于巧妙地将每个实现打包在同一个文件中。每个平台的操作系统识别并执行其对应的代码，忽略其余部分作为良性数据。这是通过shell脚本、不寻常的PE头以及浏览器对初始垃圾数据的容忍来实现的，最终生成一个13.7KB的可执行文件。
## 小游戏，大影响：一个13KB的多语言程序
一个13KB的单个文件因其能够在Windows、Linux和网页浏览器上运行而备受关注。该文件包含一个可玩的游戏，展示了令人印象深刻的编码技巧，引发了关于早期游戏开发资源利用率的讨论。评论者惊叹于如此少量的代码能够创造出如此引人入胜的体验，并提到了经典游戏如初代《塞尔达传说》（128kB）和Commodore 64游戏的小文件大小。
讨论强调了用于克服限制的巧妙技术——基于瓦片的图形、基于代码的音乐，甚至操纵程序头以挤入更多数据。分享了在不同系统上运行文件遇到的挑战（特别是Windows需要DEP调整，Linux需要`xz`软件包），以及相应的解决方案。
这篇帖子引发了关于“多语言”文件和创建真正通用二进制文件的潜力的更广泛讨论，并提到了Cosmopolitan和js13kgames等项目。直接从HTML文件运行应用程序的能力，以及浏览器安全功能施加的限制也被探讨。最终，该文件提醒我们，在资源受限的情况下，创造力和效率是多么的可行。
```
>CODEPUNS Python, Django, Javascript, AngularJS, HTML, CSS LinkedIn 邮箱</> CODEPUNS
2026年1月9日
我想告诉你一个UDP笑话……但你可能收不到。推特← 更多双关语
有代码双关语要分享吗？发送到 ^*[email protected]
```
这个Hacker News讨论围绕网络协议笑话展开，起因是链接到[codepuns.com](https://codepuns.com/)。最初的帖子包含一个冗长且故意令人沮丧的“TCP笑话”，模仿了协议的握手过程，最终超时。
用户分享了相关的笑话，特别是关于UDP的一个流行笑话：“我想告诉你一个UDP笑话……但你可能收不到。” 几位评论者讲述了在面试或工作中尝试这些笑话的经历，结果好坏参半。
话题蔓延到其他技术相关的幽默，包括SQL、DNS、ICMP、HTTP，甚至编程范式。许多用户还分享了类似笑话的集合链接，例如一个包含40多个协议的笑话集和一个基于协议的文字双关语文件。这次对话突显了技术领域人士所欣赏的特定幽默，以及依赖专业知识讲笑话所面临的挑战。
## 2026：自托管变得普及的一年
乔丹·富尔加姆预测2026年将是自托管普及的一年，这得益于经济实惠的硬件和强大的AI工具的结合。 过去一项复杂的任务，运行自己的家庭服务器现在对于具备软件知识的用户来说是可行的，*无需*成为全职系统管理员。
关键是什么？迷你电脑（如Beelink Mini N150，价格约为379美元+存储）与CLI代理（如Claude Code）结合使用。 这些代理可以自动化服务器设置和管理——只需*告诉*服务器你想要什么（例如，“设置Docker，安装Vaultwarden”）而无需与代码和配置作斗争。
富尔加姆成功地自托管了密码管理（Vaultwarden）、媒体（Plex）、照片存储（Immich）和稍后阅读应用程序（ReadDeck）等服务，所有这些都在低功耗、安静的设备上完成。 Tailscale等工具简化了网络，而Lazydocker和Glances提供了简单的监控。
这种方法提供了所有权、控制权和令人惊讶的愉快体验——将重点从*维护*基础设施转移到*使用*你需要的服务。 它非常适合那些熟悉终端、已经为SaaS付费并且好奇事物如何运作，但又想避免传统服务器管理的复杂性的人。
macOS Tahoe 戏剧性圆润的窗口角，作为一种设计选择，正在导致可用性问题。用户发现可靠地调整窗口大小出奇地困难，这是以前很少遇到的问题。
问题源于微小而精确的调整大小“抓取区域”——窗口角落附近的一个19x19像素区域。 以前，该区域的大部分都在窗口边界*之内*。 然而，大的圆角将该区域的75%转移到窗口*之外*，这意味着用户会本能地点击无响应的区域。
本质上，要成功调整大小，用户必须点击视觉角落的*外部*，这是一种违反直觉的操作，导致频繁出错。 这凸显了审美变化如何对基本的用户交互产生负面影响，即使在数十年的既定计算机使用模式之后。
## CommonMark Markdown 渲染问题 CommonMark 规范中长期存在的缺陷导致 Markdown 渲染不正确，尤其是在加粗 (** ) 方面，而 LLM 生成的内容暴露了这个问题。问题源于 CommonMark 的“分隔符连续”规则，该规则旨在简化解析，但未能考虑到实际使用情况，尤其是在韩语、日语和中文 (CJK) 等语言中。 这些规则规定，强调标记必须仅根据紧邻的字符（空格或标点符号）是“左侧相邻”还是“右侧相邻”。当标点符号（如括号）紧随在闭合加粗标记之前，后跟一个字母时，就会出现问题，从而导致无法正确渲染。 虽然该规则旨在支持嵌套强调，但它在很少使用空格且标点符号经常集成在单词中的CJK语言中造成了很大的困扰。作者认为，嵌套强调的好处并不值得由此带来的不便，尤其是由于 LLM 现在广泛输出反映自然语言使用的 Markdown，从而突显了此前潜在的问题。
黑客新闻 新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
Markdown CJK 强调问题：分析 CommonMark 的分隔符规则 (hackers.pub)
12 分，birdculture 1 天前 | 隐藏 | 过去 | 收藏 | 1 评论
keybored 1 天前 [–]
现在有了 LLM，这是一个紧迫的问题。
解决方案似乎很明显？
我不明白为什么 Markdown/CommonMark 的细节会成为工具/操作员的绊脚石，这才是问题的关键。回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：