作者完成了LT6502的“b”版本，采用鲜艳的半透明橙色外壳。其厚度为原版的一半，并配备更大的10.1英寸1024×600 IPS屏幕，对比度更好，文本行数更多。电池续航应相近，速度从8MHz提升到10MHz，并增加了SID模拟器和WiFi调制解调器，但为更简洁的设计取消了扩展槽。计划改进包括更强的热压嵌件支撑、Caps Lock指示灯、更好的WiFi调制解调器和扬声器、更快的ROM到RAM操作、基于18650的电池、灵活的USB-PD供电、更好的音频芯片，以及CF卡上的FAT16支持。代码和文件在Codeberg上。
每日HackerNews RSS
**摘要：** 一篇 Hacker News 帖子讨论了 Paula Maddox 打造的 DIY 笔记本电脑，基于 65C02 CPU（10MHz），配有 46KB RAM、EhBASIC、Compact Flash 存储、10.1 英寸 1024×600 256 色显示屏、WiFi 调制解调器和声音。评论者争论为何只有 48K RAM 而非 64K（ROM 占用地址空间；可进行 bank switching），以及高分辨率显示屏如何工作——LCD 使用带内置 SDRAM 的 RA8889 TFT 控制器而非 CPU 驱动的帧缓冲。用户将其与 Commodore SX-64、Apple IIc 等复古便携设备比较，并讨论了 6502 的限制（无硬件乘法、bank switching）。有人认为更简单的 CPU 足以应对实际工作负载，另一些人则指出 TLS 和渲染等现代需求。鉴于分立芯片和大尺寸 LCD 功耗显著，电源效率受到质疑。该项目反映了 Maddox 对复古计算和教育硬件的兴趣。
第四阶段通过反向扫描检查释放后使用，跟踪三个事件：USE、MUTATE 和 DECLARE。扫描从函数末尾向上移动时，它维护一个待处理变量列表，这些变量稍后会被使用且必须保持有效。USE 将变量加入待处理列表；MUTATE 检查没有待处理变量被失效；DECLARE 将变量从待处理列表中移除。在示例中，`buff` 指向 `e.buffs[0]`，然后 `e.add_buff()` 修改了 `e`，这在 `buff` 使用前使其失效。编译器检测到这种不匹配并报告编译错误，从而防止释放后使用。
一篇 Hacker News 帖子链接到一篇文章，提出一种新的反向借用检查方法，该方法是在探索编译期代际引用之后开发的。作者 verdagon 描述了一个艰难的过程，并希望这个想法能站住脚。评论称赞工程实现，并推测 Rust 为何使用生命周期。讨论涉及语言设计权衡、人体工程学约束与语法导向算法、分组借用和失效标注。一位评论者将反向推理与 Hoare 风格验证进行比较，但警告编译器性能和回溯问题。其他人提到优化可能性、Vine 的逆运算符，以及对手写内容的赞赏。总体而言，该帖子讨论了一种实验性的借用检查替代方案及其对语言设计的潜在影响。
1989年，Eric Gullichsen在Autodesk的研究实验室从事早期虚拟现实工作。朋友兼合作者Timothy Leary给实验室起了“Cyberia”的绰号。当Autodesk申请“cyberspace”商标时，Leary告诉Gullichsen，William Gibson很生气。Gullichsen给Gibson写了一封和解信；Gibson的律师作出了回应。Leary随后散布了一个恶作剧谣言，称Gibson正在通过注册“Eric Gullichsen”商标进行报复，这个故事后来被John Perry Barlow添油加醋，被Rudy Rucker放大传播。1990年，离开Autodesk加入Sense8后，Gullichsen参加了在巴塞罗那举行的Art Futura，终于见到了Gibson。在卡瓦酒和塔帕斯的陪伴下，他们放下了争端，并参观了高迪的桂尔公园，公园中的蜥蜴出现在Gibson的《Count Zero》中。事实上，Autodesk确实申请了“cyberspace”商标，Gibson也确实提出了异议，但称Gibson试图注册“Eric Gullichsen”商标的说法是Leary的恶作剧，并非事实。
该帖围绕一篇关于威廉·吉布森与“赛博空间”商标注册的文章展开。发帖人 Eric Gullichsen 回忆 Autodesk 1989 年的 VR 项目及其试图注册“赛博空间”商标，导致收到吉布森的停止侵权函。他说 Autodesk 的信中引用了吉布森的话“街道会找到自己的用途”，吉布森回应道“Autodesk 不是街道”。商标申请后来被放弃。评论者还讨论迷幻文化可能对赛博空间的影响、蒂莫西·利里、受利里启发的 LLM/AI 项目、VR/CAD 的局限、《神经漫游者》的世界，以及包括“赛博朋克”在内的更广泛商标问题。其他人 debate 是否公司应该感谢或署名作者创造的术语，并反思科幻如何塑造技术。
1990年代，Unix sendmail可能返回令人困惑的邮件错误“User unknown: Not a typewriter.”这是因为sendmail将收件人名称转为小写，所以“MWichary”变成不存在的“mwichary”，然后追加了系统错误。“Not a typewriter”（ENOTTY）历史上表示后台进程缺少终端输入/输出，源自打字机/电传接口。冒号让它听起来像是用户应该是一台打字机。它后来被改名为“Inappropriate ioctl for device”，不过ENOTTY仍保留。
一个标题为“Traditional, but Puzzling”的 Hacker News 帖子链接到 aresluna.org，并收集关于令人困惑或措辞出人意料的信息的评论。用户讨论 Unix 错误 ENOTTY 的词源、一个停车场系统显示“Payment Declined: Exit permitted”、一条温馨的英国停车机信息“change possible”，以及 Linux 的“lp0 on fire”打印机错误。有一位评论者开玩笑说把标题误读为“traditional butt puzzling”。总体而言，该帖子收集了技术或服务信息含糊、有趣或历史上令人费解的例子。
OmniPTY（原名 Oxide）是一个用 Rust 编写的原生 macOS/Linux 终端，集成了终端与类似 tmux 的分屏/标签页/工作区、vim 驱动的文件树、复制模式、git/SSH 状态以及实时重载的 TOML 配置。它使用 GPU 渲染的 GPUI 和 Alacritty 的 PTY/VT 模拟，支持真彩色、图片、滚动历史搜索、命令历史、Markdown/图片预览和启动命令。除更新检查外无账户/AI/遥测；更新已签名。0.9.0 版本重命名；已安装的 Oxide 副本会自动迁移。macOS 通过 Homebrew/DMG 安装（macOS 12+，Apple Silicon/Intel）；Linux x86_64 通过 tarball/PKGBUILD 安装（glibc 2.35+、Vulkan、notify-send）。内置 JetBrainsMono Nerd Font。支持 zsh/bash 提示集成；其他 shell 也可用。配置位于 ~/.config/omnipty/config.toml；包含主题、键位映射、光标、窗口选项。可从 Rust/Xcode（macOS）或 Linux 依赖构建。限制：无 IME/死键组合输入，无图片动画，Linux 不支持原地自更新。MIT 许可，依赖 GPUI/alacritty_terminal。
Hacker News 上关于 Show HN OmniPTY（一个有强烈观点的 macOS/Linux 终端模拟器）的帖子。评论持怀疑态度：有人说 README 看起来像 AI 生成，且未清楚说明未解决的问题。另一人认为终端/tmux 生态的可组合性和向后兼容性很重要，警告不要只是重建终端模拟器，并建议更深层的创新，例如结构化 shell 输出，比如命令输出 HTML。后续评论开玩笑说把这条评论喂给 Claude；作者同意设计很重要，但喜欢 HTML 工具的想法。另一名评论者称终端+shell 是需要新的高级用户工作空间想法的老古董，同时承认 OmniPTY 看起来不错但缺乏资历。总体来说，该帖子质疑另一个终端模拟器是否提供有意义的新功能。
whatsapp-mcp 是一个自托管的 Cloudflare Worker，允许 AI 代理通过 MCP 读取和搜索你的 WhatsApp 消息，且不发送任何内容。它像 WhatsApp Web 一样一次性链接到你的手机，将消息存储在 Cloudflare Durable Object 内的 SQLite 中，并仅短暂连接以同步排队的更新。设置需要 Cloudflare Workers 付费计划、Node 20+、克隆仓库、创建 KV 命名空间、设置密码、部署、扫描二维码，然后将 MCP 客户端指向 `/mcp`。代理可以列出聊天、读取消息、跨聊天搜索、总结活动、识别未命名的电话号码聊天，并保存联系人名称。媒体显示为标签而非下载。它是非官方的，使用 Baileys，并违反 WhatsApp 的条款，但只读个人使用下的实际风险较低。一个部署支持一个账号和一个所有者。大型历史导入可能需要付费计划更高的 CPU 限制。名称最初可能显示为号码，直到从联系人映射。
Hacker News 的讨论围绕一个 Show HN 项目 WhatsApp MCP 展开，该项目让个人 AI（Claude）通过 Cloudflare 访问个人 WhatsApp 消息，并使用 Google 联系人以改善搜索。作者还推出了托管版本。评论者提出隐私与伦理担忧：将私人对话提供给第三方 AI 可能会暴露从未同意的其他人，不过有些人认为隐私早已被邮箱/SaaS 破坏，WhatsApp 仍保持端到端加密。其他人警告使用非官方 WhatsApp 自动化可能违反服务条款并导致账号被封，引用了过去的封号案例。技术要点包括元数据未加密、备份加密，以及 Telegram、Signal、本地模型或 Matrix 等替代方案。总体而言，该讨论在 AI 辅助个人上下文的兴奋与对同意、隐私和账号安全的担忧之间取得平衡。
气候研究员Colleen Golja参加了一场在伦敦举行的模拟太阳辐射修正全球治理的战争推演，太阳辐射修正技术通过反射阳光来冷却地球。此次演习汇聚了代表政府、非政府组织、原住民群体和技术公司的专家，以对应对措施进行压力测试。尽管其冷却效果已获认可，该技术仍存在不确定且不均衡的风险，包括撒哈拉以南非洲的干旱和更强的北大西洋风暴；停止使用可能引发快速的回弹式变暖。曾是小众想法的太阳地球工程正日益获得关注：一家初创公司筹集了6000万美元，埃隆·马斯克也对此表示支持。前联合国顾问Cynthia Scharf表示，未来十年内将需要做出治理决策。
Hacker News的讨论围绕一篇《连线》文章，该文章关于模拟太阳地球工程的推演，参与者探讨了遮蔽太阳以冷却地球。评论者指出，此类推演依赖于游戏设计和参与者个性，而非预测，并争论其政治现实性。有些人认为，鉴于变暖惯性与当前排放，地球工程可能是必要的；而其他人强调风险、怀疑以及政治和产业的影响。还有评论讨论了太阳周期、云播种、监管和阴谋论担忧。总体而言，该讨论串反映了关于大规模遮蔽太阳是否可行、安全或在政治上可管理的混杂看法。
VMAF 是 Netflix 获得 Emmy 奖的感知视频质量评估算法，以 libvmaf（C）和 Python 封装形式分发。它包含 PSNR、PSNR-HVS、SSIM、MS-SSIM、CIEDE2000 以及带状伪影检测器 CAMBI。该软件包提供命令行工具、用于训练和测试模型的 Python 工具、FFmpeg 集成、Docker 支持和 Windows 构建。最近的更新包括 VMAF v1 模型、带优化和移除已弃用 API 的 libvmaf v3.0.0、CAMBI 增强、v2.0.0 SIMD 加速以及便于编解码器评估的 NEG 模式。VMAF 被 AOM CTC 使用，并采用 BSD+Patent 许可证。文档涵盖常见问题、模型、用法和贡献。
Hacker News 上的一篇帖子链接到 Netflix 的 VMAF，这是一种基于多方法融合的感知视频质量评估工具。评论者讨论了 VMAF 的局限性以及 SSIMULACRA2、CVVDP 和 Butteraugli 等替代方案，其中一位用户评估了更新的 v1.0 模型。其他人争论流媒体与实体介质，认为流媒体压缩会在优质显示器上明显降低画质，而部分观众对伪影不太敏感。该帖还包含一个指向 Netflix 技术博客关于 VMAF v1 的链接。
关于 新闻 版权 联系我们 创作者 广告 开发者 条款 隐私 政策与安全 YouTube 工作原理 测试新功能 © 2026 Google LLC
一个 Hacker News 帖子讨论了一个 DIY 16 位磁芯存储器项目。评论者将磁芯存储器与现代非易失性 RAM 进行比较：FRAM 提供几乎无限的读写周期，用于高采样电机控制器和 N64 记忆卡，容量可达 16 Mb（2 MB），尽管读取可能比写入慢。MRAM 和相变存储器（Intel XPoint）被引用为未来或高耐久度的替代方案，而闪存可能停滞不前。其他人提到 Core64 套件、Dataram 磁芯平面和磁芯的微小尺寸。视频中的设备为 16 位和 128 字节（1024 位），每个环存储一位。该帖还涉及存内/PIM 计算和磁逻辑。
作者创建了 KillSwitch，一种深奥的编程语言，旨在挑战 LLM 和编程代理，测试它们是真正理解代码还是仅记忆片段。它结合了新颖的规范与对抗性特性：隐藏的谎言、隐含推断、字符计数规则、触发安全机制的短语、嘈杂的基于故事的脚本，以及按行号引用的字面量，同时仍是一种熟悉的基于栈的语言，具有函数、变量和条件语句。基准测试显示模型表现不均衡：Opus 5 表现最佳，像 Fable 5.1 和 Gemini 4 Argon 这样对安全敏感的模型表现较差，MiMo-V2.6-Pro 是最佳开源权重模型。最高分仅为 66.8。任务很简单，因此作者认为成功并不证明理解，尽管性能与其他基准测试相关。如果更新的模型掌握这些，可能会推出更复杂的任务。
Dom96 推出了 KillSwitch，一种旨在让 LLM 难以处理的深奥编程语言。其规范包括陷阱、触发安全过滤器的对抗性短语、字谜、字母计数规则和误导性指令。在基准测试中，配有解释器二进制文件的编程代理得分最高约 66.8–68.8%，表明部分成功但未完全理解。
评论者争论这是否证明 LLM 缺乏理解，还是仅显示对抗性提示。一些人认为前沿模型能从文档学习新语言，而另一些人说它们依赖模式匹配并在新任务上失败。许多人指出人类也觉得该语言困难，引发公平性疑问。建议的替代方案包括 esolang、栈语言、图形语言和混淆。用户还指出 LLM 可通过转译器、逆向工程编译器或辅助脚本绕过它。作者承认这些限制，并希望获得让语言对 LLM 更难但仍便于人类使用的想法。