科勒最近推出的售价600美元以上的“Dekota”智能马桶承诺通过数据收集提供肠道健康信息，但其隐私声明正受到质疑。科勒大力宣传用户数据采用“端到端加密”，导致许多人认为只有用户才能访问数据。然而，该公司承认他们*可以*解密收集的数据——这意味着它并非真正的端到端加密。 相反，科勒使用标准的HTTPS加密进行数据传输和“静态”加密，以及内部安全措施。至关重要的是，科勒保留了访问数据的权限，并打算将其用于超越个人用户利益的目的，包括训练人工智能模型。 虽然科勒表示用于人工智能训练的数据是“去标识化”的，但其隐私政策允许更广泛的数据使用以及与第三方共享用于商业目的。营销宣传与实际情况之间的这种差异引发了对用户隐私以及这款新型设备数据收集范围的担忧。
每日HackerNews RSS
科勒公司可以访问来自“端到端加密”马桶摄像头中的图片。
Kohler Can Access Pictures from "End-to-End Encrypted" Toilet Camera
2 天前
StutterZero：为口吃转录和矫正的语音转换
StutterZero: Speech Conversion for Stuttering Transcription and Correction
2 天前
## StutterZero & StutterFormer：用于口吃问题的端到端语音转换 这项研究介绍了StutterZero和StutterFormer，两种新颖的端到端人工智能模型，旨在直接将口吃语音转换为流畅语音，*同时*进行语音转录。当前的方法在准确处理不流利语音方面存在困难，通常依赖于复杂的多阶段流程。这些新模型绕过了这种复杂性。 StutterZero利用卷积-双向LSTM架构，而StutterFormer采用双流Transformer。两者均在合成和真实的口吃语音数据上进行训练。 在未见过说话者上的评估表明，与现有的Whisper-Medium模型相比，有了显著的改进：StutterZero实现了24%的转录错误减少（WER）和31%的语义相似度提升，而StutterFormer则进一步将这些结果提升至28%和34%。 这项工作展示了直接、端到端口吃校正的潜力，为更具包容性的语音技术、改进的语音治疗工具和易于访问的人工智能系统铺平了道路。
一篇名为“StutterZero”的新研究论文，专注于语音转换，以改善口吃患者的转录和校正。该项目在Hacker News上分享，引人注目的是，它是由一名高中生创建的。
讨论强调了口吃患者在使用现有语音技术（例如自动转录服务，如Google Meet）时面临的当前困难，这些技术对他们来说通常效果不佳，而对其他人却很好。用户表达了各种反应，从觉得这些系统无法使用到在使用语音技术时感到焦虑。
评论者希望这项研究能够更好地整合到现有模型中，甚至可以启发辅助设备——可能是一种助听器功能，在口吃发作期间提供音频支持，帮助控制呼吸和声音发音。
Zenroom是一个微小、安全、完全隔离的开源虚拟机，可在任何平台运行，甚至可以在芯片或网页上运行。它在多个曲线上执行密码学（签名、哈希、zkp、同态、后量子[…])，实现区块链互操作性和通用计算。Zenroom可以使用无代码的类英语语言Zencode进行编程。
Hacker News 新闻 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
Zenroom – 无代码加密虚拟机 (zenroom.org)
13 分，smartmic 1 天前 | 隐藏 | 过去 | 收藏 | 4 条评论
cornstalks 1 天前 | 下一个 [–]
> Zenroom 使用类似英语的无代码语言 Zencode 编程。这不就是代码吗？人们在哪里划定无代码和代码之间的界限？回复
geoah 1 天前 | 上一个 | 下一个 [–]
不幸的是，主页上没有示例，并且“在浏览器中尝试”在 iOS Safari 上似乎永远无法加载完成。回复
amingilani 23 小时前 | 上一个 | 下一个 [–]
示例在这里：https://github.com/dyne/Zenroom/tree/master/docs/examples 回复
sirjaz 1 天前 | 上一个 [–]
没有 C# 支持，他们需要修复这个问题。回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
这篇帖子详细介绍了一项关于经典游戏《DOOM》的有趣发现。虽然《DOOM》以其针对专用声卡的声卡驱动程序而闻名，但它也包含一个很大程度上未使用的PC扬声器驱动程序——即使在更快的486处理器上，也常常被认为对音乐播放来说资源消耗过大。 一位开发者挑战了这一假设，并创建了“PC Speaker sndserver补丁”来启用通过PC扬声器的音乐。该补丁利用一种新设计的“pcsp”文件格式来高效播放旋律，成功地将音乐集成到《DOOM》中，而没有明显的影响性能。 目前，只有E1M1的配乐被实现，开发者计划在公开发布之前，完善sndserver以实现与现代Linux的兼容性。这个项目证明了PC扬声器*可以*处理《DOOM》中的音乐，为游戏解锁了一种以前未被探索的音频可能性。
## DOOM 与 PC 扬声器：复古技术探索
最近在 Hacker News 上的一场讨论探讨了 *DOOM* 是否可以使用朴素的 PC 扬声器来播放音乐，尽管最终选择了更高级的声音解决方案。尽管看似简单，PC 扬声器却能够产生令人惊讶的丰富音频——像 *Star Control II* 这样的游戏和 tracker 软件甚至在较旧的硬件上展示了 4 声道 MOD 音乐播放。
这次讨论强调了 Access Software 的 RealSound™ 等技术，它调制 PC 扬声器以提高音质，以及爱好者们 DIY 的“Covox”扬声器替代品。然而，在 *DOOM* 中实现 PC 扬声器音乐面临挑战。现代实现展示了潜力，但会中断游戏以播放音效，这与声霸卡混合音频不同。
许多评论员认为 id Software 的决定并非懒惰，而是为了避免“廉价”且可能令人不快的音频体验。开发团队在开发期间面临巨大压力，并优先考虑与游戏氛围相符的音质。最终，技术障碍和审美问题很可能超过了在 *DOOM* 中使用 PC 扬声器音乐的好处。
## 运行转换 (OT) 与无冲突复制数据类型 (CRDT) – 摘要 本文探讨了协作编辑的两种主要方法：运行转换 (OT) 和无冲突复制数据类型 (CRDT)。两者都没有明确的“最佳”选择；它们都涉及复杂性、分布和功能的权衡。 OT 较早发展，通过转换操作（插入、删除等）来维持一致性，以应对并发编辑。这种转换非常复杂，尤其是在多个用户的情况下。CRDT 是一种较新的方法，它使用特殊的数据类型和操作，无论操作顺序如何，都能保证最终一致性，从而简化了分布式处理。 虽然 CRDT 在理论上*看起来*更简单，但实际实现会引入复杂性，例如高效的数据查找以及在 CRDT 操作与用户界面编辑器操作之间进行转换。OT 虽然概念上更难，但最初的实现可能更简单。然而，OT 的撤销功能以其复杂性和低效率而闻名。 基本的 OT 算法涉及一个转换函数和一个控制算法，用于管理操作上下文和顺序。OT 和 CRDT 都需要仔细考虑空间和时间复杂度。当前现实世界的编辑器，如 Google Docs，主要使用基于 OT 的解决方案，但对这两种方法的研究仍在继续。作者强调 OT 资源匮乏，并鼓励进一步探索相关论文和资源。
一个黑客新闻的讨论围绕着一篇提供操作转换（OT）实用介绍的博客文章，OT是一种协作编辑技术。核心争论在于OT和无冲突复制数据类型（CRDT）之间的关系。
一位关键评论员澄清说，根本区别不在于ID与位置，而在于系统*是否必须*在点对点（P2P）环境中工作。CRDT由P2P功能定义，所有CRDT也是OT，反之则不然。OT可以基于ID，而CRDT不一定需要ID。
另一位用户分享了一个相关的理论，称为“坍缩时间机器”，而其他人则称赞了博客的设计和排版，指出作者甚至创建了一种自定义字体。最后一条评论质疑了博客关于OT撤销比CRDT撤销更复杂的说法。
## 大型 HTML 文档：摘要
虽然大多数 HTML 文档都很小，但有些网站却会加载数兆字节的 HTML，这通常不是由于内容过多，而是由于嵌入的资源。常见的罪魁祸首包括 **Base64 编码的图片和字体**，它们消除了单独的请求，但会妨碍缓存并可能导致加载优先级错误。**内联 CSS**，通常包含背景图片，以及深度嵌套的选择器也会显著增加文件大小。
现代 JavaScript 应用程序会加剧这个问题，因为存在 **水合状态**——嵌入在 HTML 中的数据，用于在无需额外 API 调用即可启用客户端交互。这种状态可能会变得很大，尤其是在包含大量数据（如产品列表和图片）的 JSON 数据中，甚至嵌套在其他 JSON 中！其他原因包括大型脚本、Figma 元数据和大型巨型菜单。
大型 HTML 会通过增加下载和解析时间，并阻止有效缓存来影响页面速度。虽然快速连接可以缓解一些问题，但仍然可能导致渲染延迟。虽然不总是关键问题，但识别和解决不必要的大型 HTML（可能通过 CI 构建检查）可以带来快速的性能改进。GZIP/Brotli 压缩至关重要，并且应考虑避免嵌入像图片这样的资源。
一个 Hacker News 的讨论围绕着 perfplanet.com 的一篇文章，探讨了处理大型 HTML 文档和网页性能的技术——具体来说，它似乎是第 17 届年度网页性能 Advent Calendar 的一部分。
用户们讨论了将小型 CSS 和脚本直接嵌入 HTML 以方便原型设计，并指出当这些文件变大时，需要分离成独立文件的权衡。一个关键点是 SVG 样式的困难，尤其是在用作背景图像时，尽管在某些情况下可以使用 CSS 定位其中的 ID。
perfplanet Advent Calendar 的维护者 ssttoo 确认了它的持续进行，并欢迎今年的投稿。这次对话突出了实用的网页开发流程以及在保持灵活性的同时优化性能的挑战。
本文详细介绍了 GitHub 仓库 “farant/rhubarb”。这是一个公开的个人项目，拥有 1 个星标，没有分叉。该仓库包含大量的 C 代码（97.8%），以及少量的 Objective-C 和其他语言的代码。
项目结构包括命令、数据、文档、剧集、头文件、库、项目规范、工具和 Vim 配置目录。关键文件包括 README.md、CLAUDE.md、INTENTIONS.md，以及多个以 SABAW 编号的 markdown 文件，表明该项目可能具有迭代或实验性质。
仓库中存在用于编译库、Sputnik 和测试的脚本。它还包含与 UI（“rhubarb-ui.md”）和图形文件浏览器相关的文件。目前，没有发布版本或已发布的软件包。在检索文档时，仓库出现加载错误。
一位开发者在Hacker News分享了“Rhubarb”项目，该项目使用**零依赖**构建C89库，起因是最近的供应链问题。独特的亮点是什么？代码完全用**拉丁语**编写！
作者使用C预处理器定义来翻译关键字（例如，4096 变为 MMMMXCVI），并包含拉丁语错误信息和注释。虽然承认拉丁语方面很大程度上是为了娱乐，但开发者强调了通过编写自己的标准库来拥有整个软件堆栈的价值——灵感来自Eskil Steenberg的作品。
评论者对此感到着迷，回忆起80年代用希腊语进行的类似实验，并指出该项目“疯狂”但令人愉悦的特性。作者还维护着另一个项目Aquinas OS，并包含了一些有趣的文件，如“RELAX.md”、“SABAW1.md”和“CLAUDE.md”，详细介绍了对Claude等AI模型的实验。
必须启用 JavaScript 才能使用 Notion。请启用 JavaScript 以继续。
## Hacker News 上关于 AI 生成字体的讨论
最近一篇 Hacker News 帖子展示了一款使用 Nano Banana 创建的 AI 生成字体，引发了关于 AI 在排版领域的新颖性和影响的活跃讨论。尽管被宣传为“世界第一”，评论员很快指出了该领域的先前工作，包括 2024 年 6 月的 Python 脚本，以及 tom7 和 gwern 等人早在 2021 年的项目。
对话扩展到字体设计的挑战，一位用户建议 AI 在尝试创作之前应该“玩转”排版规则。许多用户尝试了链接的工具，发现即使对于设计经验有限的人来说，它也令人惊讶地易于上手。
讨论的很大一部分集中在版权问题上。美国法律并不保护字体设计本身，只保护字体文件作为软件。关于 AI 模型本身的版权能力也产生了进一步的争论，涉及转化性作品与机械性编译的论点。AI 和版权相关的潜在法律纠纷被强调，尤其是在模型训练方面。
最终，尽管一些人认为生成的字体“很糟糕”，但该帖子点燃了人们对 AI 在创意领域不断发展的能力的兴趣。
## EmacsConf 2025：总结
EmacsConf 2025，一个致力于GNU Emacs和Emacs Lisp的在线会议，将于2025年12月6日和7日举行。本次会议继续致力于自由软件，使用完全自由的软件基础设施进行直播和运营。
EmacsConf 欢迎社区参与，帮助本次活动取得成功！感兴趣的人士可以贡献并传播信息。
有关讨论，请加入公开的`emacsconf-discuss`或组织`emacsconf-org`邮件列表。公开联系组织者请发送邮件至`[email protected]`，私下联系请发送邮件至`[email protected]`。你也可以在Libera.Chat IRC的`#emacsconf`频道与社区联系，可以通过IRC客户端或访问[chat.emacsconf.org](chat.emacsconf.org)进行连接。
## EmacsConf 2025 - Hacker News 讨论总结
一个 Hacker News 帖子讨论了即将到来的 EmacsConf 2025 会议。与会者和长期关注者都在赞扬组织者 Amin 和 Sacha 继续举办活动。会议安排在周末，这使得一些人更容易参加。
讨论延伸到 Emacs 与 Lem 等替代编辑器之间的优劣，Lem 是用 Common Lisp 构建的。一些用户强调了 Lem 的潜力，因为 CL 是一种通用语言，与被认为是一种较弱的 Lisp 方言的 Elisp 形成对比。
对话的很大一部分围绕着对自由软件基金会 (FSF) 的批评，一位用户表达了对其教条主义和实践的强烈负面意见。 还有关于 Emacs 社区对新技术的抵制，并将过去对 tree-sitter 等工具的怀疑与当前的 AI 辩论进行类比。