## Z80-μLM：微型AI，为老式硬件而生 Z80-μLM是一个令人惊讶的实用对话式AI，设计在仅有64kb RAM的古老Z80处理器上运行。该项目展示了AI可以变得多么小，同时仍然表现出“个性”的迹象，这通过一个40kb的.com二进制文件实现。 它通过独特的方法逐字符生成文本：输入通过三元语法哈希转换为“标签云”（允许容错），权重被大量量化为仅2位。推理依赖于高效的16位整数运算，避免浮点运算。 虽然无法进行复杂的推理，Z80-μLM包含预训练的示例，例如一个简单的聊天机器人和一个20个问题游戏。它擅长简洁、细微的回复，迫使用户提出互动、探究性的问题。项目提供了使用Ollama或Claude等LLM训练自定义模型的工具。 该项目突出了在受限硬件上运行AI的可能性，证明了即使在重大限制下，也能实现功能甚至一丝魅力。
每日HackerNews RSS
## Z80-μLM：一种适用于复古硬件的微型AI
一位开发者创建了Z80-μLM，这是一种字符级语言模型，令人惊讶的是，它能放入一个40KB的.COM文件中——可以在Z80处理器和64KB RAM上运行，甚至可能在原始硬件上运行！该项目探索了在保持功能的同时，语言模型尺寸的极限。
虽然它无法执行复杂的任务，如撰写电子邮件，但该模型可以被训练用于简单的交互，例如一个精简版的“20个问题”游戏，并展现出独特的个性。实现这一目标需要大量的优化，包括2位权重量化、三元组哈希和仔细的数据操作。一个关键的创新是量化感知训练，确保模型在学习过程中适应其局限性。
该项目引发了关于在受限设备上运行LLM的讨论，并与现有的浏览器CP/M模拟器和Z80集成游戏开发项目建立了联系。它突出了即使在历史上有限的硬件上，也能实现令人惊讶的强大AI，并提出了关于实际应用中“最小可行”LLM的问题。
Meshtastic 是一种利用低功耗 LoRa 无线电的长距离、点对点消息传递系统，无需蜂窝塔或卫星即可通信。作者通过一篇博文发现了它，并开始使用 Heltec V3 无线电进行实验，很快了解到天线质量和 GPS 功能至关重要。
最初的设置包括刷新固件并使用 Meshtastic 应用程序进行配置。起初只能在两台设备之间通信，但作者很快发现芝加哥地区有一个蓬勃发展的本地网络（“ChiMesh”），覆盖范围超过 40-50 英里。弱天线限制了双向通信，直到升级解决了这个问题。
然后，作者与当地创客空间成员合作，建立了一个中继节点以扩展网络覆盖范围。他们利用 Meshtastic 站点规划工具优化节点位置以获得更好的覆盖范围。未来的计划包括改进天线并探索 Meshtastic 的传感器集成功能，例如构建一个离网气象站。
Meshtastic 的力量在于社区发展；用户越多，网络就越强大、越有用。
## Meshtastic 网络讨论总结
这个Hacker News 帖子讨论了关于 Meshtastic 的体验和担忧，Meshtastic 是一个 DIY 网状网络平台。一个主要的争议点是 **FCC 合规性**：Meshtastic 网络在美国常用的默认无线电设置违反了带宽规定。用户面临着合法运行和与已建立的本地网状网络连接之间的选择。
多位用户报告了 **可靠性问题**，尤其是在超过单跳的网络中，提到了聊天碎片化和“喋喋不休”的协议。经常与 **MeshCore** 进行比较，一些人声称 MeshCore 提供更好的可扩展性，而另一些人则为 Meshtastic 的开源许可（GPLv3 与 MeshCore 的 MIT）辩护。存在关于 Meshtastic 社区是否不公平地审查 MeshCore 讨论的争论。
人们对 **协议设计** 提出了担忧，特别是泛洪路由和缺乏端到端确认，这会影响网络性能。一些人建议改进，例如频率多样化和解决电池状态垃圾信息。**加密** 默认启用，可能与业余无线电规则冲突。
最后，讨论涉及使用 **MQTT** 来桥接网状网络和报告数据，以及网络内的潜在商业应用（以及对广告的担忧）。多位用户指出诸如 [https://www.austinmesh.org/learn/meshcore-vs-meshtastic/](https://www.austinmesh.org/learn/meshcore-vs-meshtastic/) 之类的资源来进行比较。
正在验证您的浏览器。网站所有者？点击此处修复。 Vercel 安全检查点 | sin1::1766990047-cEC3yIrypkqPhrflch6KegK1haJZdf7N 启用 JavaScript 以继续。 Vercel 安全检查点 | sin1::1766990047-cEC3yIrypkqPhrflch6KegK1haJZdf7N
这个Hacker News讨论围绕着glthr.com上一篇文章，探讨荷马史诗《伊利亚特》和《奥德赛》中的“公式分隔符”——重复的短语。用户很快将其识别为“惯用语”，一种经过充分研究的诗歌技巧，并链接到相关资源，特别是米尔曼·帕里（Milman Parry）的研究，他发现了这些与口头诗歌传统和韵律的联系。
对话进一步探讨了这些分隔符如何作为口头叙事的“指示牌”发挥作用，弥补了纯听觉媒介中缺乏重读性的不足。一场辩论由此展开，讨论写作是否由于其能够实现复杂、嵌套的结构——类似于语法树——而本质上是“二维”的，而这些结构更难通过口头方式传达。
一个特别有见地的评论将这些古老的诗歌技巧与现代软件工程原则（如模块化和“不要重复自己”）相提并论，认为吟游诗人本质上是在为人类大脑有限的记忆“编码”。 许多用户推荐进一步阅读，包括罗伯特·费格尔斯（Robert Fagles）翻译的《奥德赛》以及相关的学术分析。
二进制文件
Huge Binaries
3 天前
## 2GiB 二进制障碍 在博士研究期间，作者在发表仅在极大型代码库（如谷歌）中出现的问题的研究时遇到了困难，原因是缺乏公开的可引用证据。一个关键问题是二进制文件大小的增长，由于静态链接以提高启动速度和简化部署，导致其达到 25GiB 以上。 这导致了“2GiB 障碍”。x86_64 架构使用 32 位相对偏移量进行函数调用。这限制了跳转距离约为 2GiB。当函数距离更远时，链接器会失败，导致“重定位溢出”错误。 存在解决方案，例如切换到“大型代码模型”，它使用绝对跳转而不是相对跳转。然而，这会由于更长的指令而增加二进制文件的大小，并给 CPU 寄存器带来压力。作者暗示将探索更多策略来克服这一障碍，并在大型项目中保持高效的代码大小，并承诺在未来的文章中提供更多细节。
## 大型二进制文件：黑客新闻讨论总结
最近黑客新闻上出现了一场关于意外巨大的二进制文件大小的讨论，有些甚至超过25GB，尤其是在谷歌等公司。核心问题不一定是代码*数量*，而是其打包方式——静态链接的二进制文件包含大量的调试信息。
虽然静态链接提供了部署的简便性和更快的启动速度，但巨大的体积会带来问题：构建/部署时间缓慢，以及潜在的扩展性问题。讨论的解决方案包括去除调试信息（或压缩它）、使用分离的调试文件，以及采用代码稀疏化和thunking等技术来优化代码布局。
许多评论员强调了谷歌历史上偏爱静态二进制文件的原因——在硬件故障（如宇宙比特翻转）面前的基础设施稳定性，以及简化的依赖管理。然而，许多人认为应该更早地实施限制，并且动态链接，尽管其复杂性较高，可能是一种更具扩展性的解决方案。讨论还涉及了二进制文件大小、性能和调试能力之间的权衡，承认谷歌的决策通常受其独特的规模和运营需求驱动。
资深战地记者约翰·辛普森回顾2025年，认为那是一个格外令人担忧的年份，特点是全球冲突加剧和地缘政治格局转变。乌克兰、加沙（据报道超过7万巴勒斯坦人死亡）和苏丹的战争持续，但乌克兰局势构成了最大的威胁——可能升级为第三次世界大战。 在普京的领导下，俄罗斯正在表现出日益增长的侵略性，通过网络攻击和实际探测来测试北约的防御，并公开讨论与欧洲发生冲突的准备。这加剧了人们对特朗普总统领导下的美国对欧洲安全的承诺减弱的担忧，他的政府对欧洲的未来提出质疑，并优先考虑美国利益。 辛普森强调了美国朝着孤立主义的危险转变，让人联想到20世纪30年代，以及普京对这种转变的利用。与此同时，中国对台湾的野心正在增长，这源于避免在国内显得软弱的愿望。作者凭借数十年的经验，包括亲眼目睹天安门广场起义，强调了中国对国内异见的敏感性。 展望2026年，辛普森预见那将是专制主义可能蓬勃发展的一年，可能会通过战略行动和国际合作的削弱来分裂西方联盟，而不是通过直接的核交换。
## Tor 在 2025 年对抗日益增长的审查 2025 年对 Tor 的反审查工具提出了前所未有的挑战，伊朗和俄罗斯的互联网限制日益加强。Tor 团队通过监控审查环境——利用区域内的观察点获取准确数据——并调整其技术以维持用户的连接性来应对。 在**伊朗**，面对几乎完全的互联网关闭，重点集中在加强 **Snowflake**，这是一种流量混淆工具，通过升级其网络扩展、NAT 检查和用于强大测试的暂存服务器来实现。新的可插拔传输 **Conjure** 被开发出来，以利用未使用的 ISP 地址空间来对抗桥接封锁。 **俄罗斯** 出现了越来越多的白名单和地址封锁审查。**WebTunnel** 将流量融入常规网络活动，证明至关重要，并获得了 SNI 模仿等改进。分发策略从直接桥接转向 Telegram 平台，证明更能抵抗审查。 **rdsys**，Tor 的桥接分发系统，现在具有暂存功能以进行稳定性测试，是这些调整的关键。团队强调社区反馈和志愿者贡献在识别有效解决方案中的关键作用。 展望未来，Tor 计划推出 Conjure，继续改进 WebTunnel，并为 Snowflake 应对未来的审查事件做好准备。用户可以通过运行 Snowflake 代理或 WebTunnel 桥接来做出贡献，帮助他人访问自由开放的互联网。
一个黑客新闻的讨论集中在一个新的快速GPU互连方法上，使用无线电波——具体来说，是波导管代替传统的铜缆。链接的IEEE文章详细介绍了这项技术，旨在克服带宽限制。
用户质疑为什么这项技术尽管一些相关公司已经开发多年，却没有获得进展。主要障碍似乎是**大规模精密制造**，因为将高速电路集成到波导管中需要极其严格的公差。
对话还涉及辐射技术中的“太赫兹间隙”，以及与现有解决方案（包括仍然用于以太网的直连铜缆）的比较。虽然具有创新性，但其经济可行性取决于克服这些制造挑战，并可能与当前方法的功率效率竞争。
## 列扫描列车摄影：深入研究
本文详细介绍了使用列扫描相机捕捉和处理图像的过程，主要用于拍摄列车。与传统相机不同，列扫描相机使用单行像素扫描图像，当主体移动经过时，从而产生透视畸变最小且潜在分辨率极高的图像（超过10万像素宽）。
该过程涉及大量的图像处理。作者使用Alkeria Necta N4K2-7C相机，保存原始16位数据。一个关键挑战是从静态背景中区分移动物体，通过基于图像梯度的“能量函数”来实现。准确的速度估计至关重要；最初通过目测完成，作者现在采用一种比较相机Bayer阵列的两个绿色通道的方法来计算主体速度。
后期处理包括通过样条插值校正速度不准确性，并使用迭代加权最小二乘法解决由时钟抖动和传感器不一致引起的垂直条纹。降噪是通过基于补丁的匹配来实现的，利用图像内的自相似性。最后，颜色校准和DNG输出允许在Darktable等软件中进行进一步的优化。作者指出，AI辅助效果不一，通常会生成效率低下的代码，但对于动态数据加载和Matplotlib语法等任务很有帮助。他们从Adam Magyar等艺术家以及kr64.seesaa.net上展示的大量作品中获得灵感。
黑客新闻 新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
线扫描相机图像处理 (lawrence.lu)
61 分，vasco 发表于 23 小时前 | 隐藏 | 过去 | 收藏 | 3 条评论
gnabgib 发表于 21 小时前 | 下一个 [–]
讨论 (449 分，4 个月前，81 条评论) https://news.ycombinator.com/item?id=44996938 回复
shrx 发表于 17 小时前 | 上一个 [–]
垂直条带是否由于相机无法配置固定的曝光增益？还是仅仅由于不稳定振荡器频率导致的采样时间略有差异？
dllu 发表于 15 小时前 | 父级 [–]
增益是固定的。我认为柱状变化源于不稳定的振荡器频率，以及像素之间可能存在一些电气错误/串扰。不太确定。
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
## RepDL：深度学习的位级可重复性 RepDL 是一个旨在确保深度学习训练和推理在不同硬件上获得位级相同的库。这对于学术研究和可靠部署至关重要。安装过程包括克隆 GitHub 仓库 ([https://github.com/microsoft/RepDL](https://github.com/microsoft/RepDL))，并在安装 PyTorch 和 CUDA 后使用 `pip install .`。 现有的 PyTorch 模型可以通过 `repdl.from_torch_module(model)` 实现可重复性。RepDL 通过在 `repdl.ops` 中提供可重复的等效项，解决了标准 PyTorch 运算（如 `torch.mm`、`torch.div`、`torch.sqrt`）中固有的不可重复性。它还在 `repdl.nn` 中提供兼容的函数和模块。 该项目欢迎贡献，鼓励开发者添加自定义的可重复运算、函数和模块。项目提供了详细的实现指南，强调 IEEE-754 合规性和准确的舍入。贡献者需要在提交拉取请求时通过机器人同意贡献者许可协议 (CLA)。该项目遵守 Microsoft 开源行为准则。 （引用：Xie, P., Zhang, X., & Chen, S. (2025). *RepDL: Bit-level Reproducible Deep Learning Training and Inference*. arXiv:2510.09180）
黑客新闻 新的 | 过去的 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
一个位可重现的深度学习框架 (github.com/microsoft)
38 分，由 noosphr 发表于 23 小时前 | 隐藏 | 过去的 | 收藏 | 1 条评论
nemoniac 发表于 14 小时前 [–]
有什么迹象表明这可能会带来性能损失吗？回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
启用 JavaScript 和 Cookie 以继续。
## Steam Deck LCD 停产总结
讨论的中心是Valve决定停止生产原版Steam Deck LCD型号，重点在于其背后的原因和影响。一个主要理论是Valve耗尽了最初为Magic Leap 2设计的AMD APU供应，现在重新订购在OLED型号已经存在的情况下，在成本上不再划算。
许多评论员认为这是Valve对其产品线进行战略简化，避免内部竞争并简化供应链。LCD型号曾作为入门级产品，但Valve似乎有信心转向利润更高的OLED版本以及未来的硬件，例如“Steam Machine”。
用户分享了Steam Deck多功能性的积极体验——包括游戏模拟、桌面使用，甚至运行Windows——并讨论了频繁硬件更新的必要性，将其与快节奏的手机市场进行对比。人们对失去一个经济实惠的入门点以及对销售额的潜在影响表示担忧，而另一些人则强调为游戏开发者提供稳定的硬件目标的重要性。最终，这一举动表明Valve致力于将OLED作为新标准，并专注于未来的项目。