2024 12 06 HackerNews

2024-12-06 Hacker News Top Stories #

  1. Diátaxis 是一种系统化的技术文档编写方法，通过了解文档用户的需求，提出内容、架构和形式的方法。
  2. Outerbase Studio 是一个轻量级、基于浏览器的 SQL 数据库管理 GUI，支持连接到多种数据库。
  3. 原生双范围输入控件是一种使用两个原生 HTML range 输入控件的方法，保留了原生的交互和可访问性功能。
  4. 美国俄勒冈州一名男子因涉嫌拥有儿童性虐待物品而被捕，警方通过更换 iPhone 的电路板和重新安装固件，使其能够开机并进行搜索。
  5. AI 帮助研究人员通过旧地图找到失踪的油气井，使用人工智能技术扫描 45 年来美国地质调查局（USGS）的地图。
  6. 软件工程师的四种类型：骗子、信徒、勤奋者和懒人，每种类型都有其优点和缺点，了解这些类型可以帮助我们更好地与同事合作。
  7. 将 K/V 上下文量化带到 Ollama，Ollama 中的 K/V 上下文缓存量化功能可以显著减少 VRAM 使用量。
  8. Waymo 宣布将其自动驾驶出行服务 Waymo One 扩展到迈阿密，提供更安全、更便捷的出行方式。
  9. 向量搜索的高效存储：VectorChord，VectorChord 是一个新的 PostgreSQL 扩展，旨在高效地进行向量搜索。
  10. Gitingest 是一个将 GitHub 仓库转换为简单文本的工具，可以将任何 GitHub 仓库的代码库转换为文本形式。

Diátaxis – A systematic approach to technical documentation authoring #

https://diataxis.fr/

Diátaxis 是一种系统化的技术文档编写方法。它是一种思考和做文档的方式，通过了解文档用户的需求，提出内容、架构和形式的方法。Diátaxis 识别出四种不同的需求和四种相应的文档形式：教程、如何指南、技术参考和解释。它将它们放在系统化的关系中，并提议文档应该围绕这些需求的结构组织。

Diátaxis 解决了文档内容（写什么）、风格（如何写）和架构（如何组织）相关的问题。除了为文档用户提供服务外，Diátaxis 还为文档创建者和维护者提供价值。它是一种轻量级、易于理解和应用的方法，不会施加实现约束。它为文档带来了一个积极的质量原则，有助于维护者有效地思考自己的工作。

本网站分为两个主要部分，以帮助应用和理解 Diátaxis。

第一个部分是“应用 Diátaxis”，它包括以下内容：

  • 教程
  • 如何指南
  • 技术参考
  • 解释
  • 指南
  • 工作流程

第二个部分是“理解 Diátaxis”，它更深入地探讨了 Diátaxis 的理论和原则，并阐述了其背后的需求理解。它包括以下内容：

  • 基础
  • 地图
  • 质量
  • 教程和如何指南
  • 技术参考和解释
  • 复杂的层次结构

Diátaxis 在实践中已经被证明是有效的。其原则已经被成功应用于数百个文档项目。

HN 热度 459 points | 评论 109 comments | 作者：OuterVale | 19 hours ago #

https://news.ycombinator.com/item?id=42325011

  • 认识到不需要只用一种方式来表达信息，给不同读者提供不同的示例可以减少语言的模糊性。
  • 重复信息有助于记忆，但必须确保信息的准确性，避免过时的信息导致误解。
  • 采用清晰的结构和顺序（如快速入门、使用方法、参考资料和解释内容）能够提升文档的可读性和易用性。
  • 演示文稿应作为视觉辅助工具，而非替代演讲内容，避免仅仅朗读幻灯片内容。
  • 技术文档的创作应考虑不同用户的需求，可能需要在多个平台上重用内容，进行 UX 研究是确保有效沟通的关键。
  • 过于教条化的方法可能会导致在实际应用中不灵活，重要的是根据实际情况调整和适应。
  • 文档的质量直接影响使用效果，应该在项目早期就纳入考虑，确保其作为一项重要内容。
  • 应当注重内容的精简和信息的准确性，以免因冗余或错误信息使读者失去兴趣。
  • 在技术写作中，基本原则如引言 - 正文 - 总结仍然适用，但要确保各部分在内容上有不同的视角和信息。
  • 文档的维护和更新需要良好的记录，以避免信息的不一致性导致用户困惑。

Show HN: Outerbase Studio – Open-Source Database GUI #

https://github.com/outerbase/studio

Outerbase Studio 是一个轻量级、基于浏览器的 SQL 数据库管理 GUI，旨在简洁和通用。最初为 LibSQL 和 SQLite 构建，现在支持广泛的数据库，包括 SQLite、Turso/LibSQL、SQLite（本地文件）、Cloudflare D1、rqlite、StarbaseDB、Val.town、MySQL（测试版，功能有限）和 PostgreSQL（测试版，功能有限）。

Outerbase Studio Desktop 是一个轻量级的 Electron 包装器，用于 Outerbase Studio 网页版本。它支持不适合浏览器环境的驱动程序，例如 MySQL 和 PostgreSQL。

Outerbase Studio 的特点包括：

  • 查询编辑器：具有自动完成和函数提示工具提示的用户友好查询编辑器。它允许您同时执行多个查询并高效地查看结果。
  • 数据编辑器：具有强大的数据编辑器，允许您暂存所有更改并预览它们，然后提交。数据表格高度优化且轻量级，能够高效地渲染数千行和列。
  • 模式编辑器：允许您快速创建、修改和删除表列，只需点击几下即可，无需编写 SQL。
  • 连接管理器：具有灵活的连接管理器，允许您在浏览器中本地存储连接。您还可以将它们存储在服务器上并在多个设备上共享连接。

Outerbase Studio 是一个轻量级的数据库 GUI，支持连接到 Postgres、MySQL 和 SQLite。它提供了一个用户友好的界面，用于管理和编辑数据库，包括查询编辑器、数据编辑器、模式编辑器和连接管理器。

HN 热度 328 points | 评论 138 comments | 作者：burcs | 1 day ago #

https://news.ycombinator.com/item?id=42320032

  • 许多人对高质量的浏览器数据库工具感到困惑，因为市场上缺乏这样的产品，虽然本地工具如 DBeaver 和 DataGrip 具有良好的功能，但缺乏浏览器版本的同类产品。
  • 市场上缺乏对数据库浏览器的商业模式的支持，导致很多开发者无法盈利，产品发展受限。
  • 一些开发者认为数据库浏览器只是功能，而不是完整产品，可能需要与其他工具结合使用才能创造价值。
  • 尽管许多开发者热衷于构建数据库工具，但市场需求相对较小，导致许多项目无法持续。
  • 对于用户界面的设计，许多人希望拥有更紧凑的界面，以最大化信息展示，而不是过多的空白空间。
  • 有评论提到，缺乏数据库权限管理功能是一大缺陷，尤其是在需要多人协作维护数据的情况下。
  • 一些用户希望添加类似报表和仪表板的 “终端用户” 功能，以便于数据分析和可视化。
  • 一些者认为，现有的桌面应用提供的用户体验远胜于浏览器应用，认为这是一个重要的差距。
  • 有人建议将产品打包为 Homebrew Cask，增强易用性。
  • 尽管有多种工具和产品，许多开发者仍然期待更强大、更全面的数据库管理解决方案。

Native dual-range input #

https://muffinman.io/blog/native-dual-range-input/

本文介绍了一个名为 @stanko/dual-range-input 的 JavaScript 库，它实现了一个原生的双范围输入控件。控件使用两个原生的 HTML range 输入控件，保留了原生的交互和可访问性功能。库的作者认为，这种方法是“原生的”，因为它不需要重新实现拖动和可访问性功能。

库的工作原理是，当两个输入控件中的任一个发生变化时，库会计算两个选中值之间的中点，然后更新两个输入控件的宽度和最小值属性，以使它们在中点处相遇。库还提供了一个调试模式，可以更容易地看到中点的位置。

库的样式使用 CSS 实现，包括对轨道和拇指的样式化。库还提供了几个变量，可以用于主题化。库的作者还使用 CSS 渐变来绘制选中范围，在两个输入控件中都使用了渐变。

总的来说，本文介绍了一个原生的双范围输入控件库，它使用原生的 HTML range 输入控件，保留了原生的交互和可访问性功能，并提供了样式化和主题化的功能。

HN 热度 248 points | 评论 46 comments | 作者：Wolfr_ | 1 day ago #

https://news.ycombinator.com/item?id=42320516

  • 许多人对新的双范围输入控件表示赞赏，认为这种控件能更好地处理数值范围，特别是在产品筛选等应用场景中。
  • 有用户发现该控件在某些浏览器中存在 bug，比如在 Safari 中无法正确触发焦点事件。
  • 也有评论提到，虽然控件使用了原生 HTML 范围输入，但仍需 Javascript 以实现某些功能，这引发了对 “原生” 定义的讨论。
  • 某些用户认为，虽然滑块在视觉上直观，但在需要精确输入时却不如数字输入框方便。
  • 有人提到在银行业务中使用滑块可能会造成用户无法精确输入金额，从而影响用户体验。
  • 还有观点认为，当前的 HTML 表单控件设计欠缺，缺少展示当前值的功能，且在刷新页面时丢失输入值的问题需要解决。
  • 一些用户提到用 CSS 可能实现无需 Javascript 的动态输入控制，但维护成本较高，且可能不够稳定。
  • 最后，有人建议进行设计竞赛，以提升 HTML 表单的用户体验和功能。

https://www.techdirt.com/2024/12/04/federal-court-says-dismantling-a-phone-to-install-firmware-isnt-a-search-even-if-was-done-to-facilitate-a-search/

美国俄勒冈州一名男子因涉嫌拥有儿童性虐待物品而被捕，警方在其住所搜查并扣押了 52 台设备，包括一台 iPhone 和一台 iPad。由于 iPhone 无法开机，iPad 被密码保护，警方无法立即检查设备。警方将设备保留了一年多，期间多次申请延长搜索令，最终在 2023 年 5 月获得了新的搜索令。随后，警方通过更换 iPhone 的电路板和重新安装固件，使其能够开机并进行搜索。警方在 iPhone 和 iPad 中发现了涉嫌儿童性虐待物品的证据。

被告人认为，警方的行为违反了第四修正案，要求法院驳回证据。法院驳回了被告人的请求，认为警方的行为是合法的。法院认为，警方的行为是为了恢复设备的正常功能，而不是进行新的搜索。法院还认为，第四修正案并不禁止警方对扣押的设备进行修复或维护。

这起案件引发了人们对警方在调查中使用技术手段的讨论。一些人认为，警方的行为是合理的，因为他们是在执行搜索令，而不是进行新的搜索。另一些人则认为，警方的行为是违法的，因为他们是在未经法院许可的情况下对设备进行了修改。

HN 热度 240 points | 评论 115 comments | 作者：hn_acker | 8 hours ago #

https://news.ycombinator.com/item?id=42329005

  • 文章标题可能引起误解，实际的数据获取是在获得搜查令的情况下进行的，修复和固件更新是在两个搜查令之间的空档期完成的。
  • 读者可能难以理解标题的含义，法律文章的标题往往难以简化到普通读者可以轻松理解的程度。
  • 自我辩护者（pro se）在法庭上的表现常常被误解，但一些人确实能够成功进行自我辩护。
  • 主张 “金边国旗” 与法庭管辖权相关的说法是错误的，金边旗帜主要是装饰性的。
  • “主权公民” 运动者的行为不一定与智力水平相关，他们可能是由于错误的教育而持有错误的法律信念。
  • 一些人参与 “主权公民” 活动是为了寻求社群感和对生活的控制感，这反映了一种心理健康问题而非精神疾病。
  • 媒体在报道法律决策时应更准确，以避免误导公众，特别是在涉及复杂法律概念时。
  • 文章中提到的设备修复是否真正属于 “搜索” 存在争议，政府在没有明确授权的情况下进行修复和固件更新可能不合适。
  • 法律及技术报道的记者应具备足够的专业知识，以便有效传达给普通读者。

AI helps researchers dig through old maps to find lost oil and gas wells #

https://newscenter.lbl.gov/2024/12/04/ai-helps-researchers-dig-through-old-maps-to-find-lost-oil-and-gas-wells/

美国有数十万口未记录的油气井，可能会泄漏化学物质，包括甲烷，一个强大的温室气体。研究人员使用人工智能技术，扫描 45 年来美国地质调查局（USGS）的地图，找到了加利福尼亚州和俄克拉荷马州的许多未记录的油气井。专家们估计，美国有数十万口未记录的油气井，这些井没有正式的记录或所有者。这些未记录的孤儿井（Undocumented Orphan Wells，简称 UOWs）可能会泄漏油和化学物质到附近的水源或释放有毒物质到空气中，包括甲烷，一个强大的温室气体。

为了找到这些未记录的井，研究人员使用现代工具，包括无人机、激光成像和传感器套件。然而，美国的陆地面积超过 300 万平方英里，要找到这些井需要大量的工作。研究人员使用人工智能技术，扫描 45 年来 USGS 的地图，找到了加利福尼亚州和俄克拉荷马州的许多未记录的油气井。研究人员使用地图上的符号，包括空心黑圈，来标记油气井。他们使用人工智能算法，扫描地图，找到了 1301 口潜在的未记录的孤儿井。研究人员已经通过卫星图像和现场调查，确认了其中的 29 口井。

研究人员使用卫星图像和历史航空照片，来确认井的存在。如果没有明显的迹象，研究人员会使用磁力仪，来检测井的位置。一旦找到井，研究人员会记录井的位置，拍照，记录 GPS 坐标，并检查甲烷泄漏。研究人员发现，未记录的井通常位于预测位置的 10 米范围内。这个项目是更大项目的一部分，旨在解决未记录的油气井问题。该项目由洛斯阿拉莫斯国家实验室领导，包括来自伯克利实验室、劳伦斯利弗莫尔国家实验室、国家能源技术实验室和桑迪亚国家实验室的研究团队。

HN 热度 225 points | 评论 99 comments | 作者：gnabgib | 1 day ago #

https://news.ycombinator.com/item?id=42319969

  • 这种 AI 技术可以应用于发现和管理澳大利亚的废弃矿井，以提高安全性。
  • 卡尔曼滤波器可以用于处理噪声数据，帮助识别潜在的矿井位置。
  • 德国也面临废弃矿井导致的安全问题，常发生塌陷和形成沉降坑。
  • 许多老矿井在地理信息图上并不明确标注，实际寻找可能需要结合社区资源。
  • 油气公司可能因处理旧井和环境问题而面临财务困难，国家化可能是解决方案之一。
  • 确认和处理漏油井的成本极高，但从长远看，这项工作是必要的。
  • 遗产和财富来源于犯罪行为的后代应承担道德责任。
  • 需要对环境风险进行量化评估，以争取修复工作的资金支持。
  • 过去的矿业行为留下的问题仍需现代技术与责任感来解决。
  • 解决历史遗留问题涉及复杂的法律和道德考量，没有统一答案。
  • AI 可以帮助挖掘老旧项目的历史数据，以指导现代开发和风险评估。

Grifters, believers, grinders, and coasters #

https://www.seangoedecke.com/programmer-archetypes/

软件工程师们为什么总是互相争吵？我认为很多程序员的争论最终都是因为不同类型的工程师之间的文化冲突：信徒 vs 骗子，或者说是懒人 vs 勤奋者。我认为好的公司通常会有这四种类型的工程师的健康混合，因此了解如何与他们合作是很重要的。

尽管这些名字听起来不太好，但我认为骗子和懒人也可以像信徒和勤奋者一样擅长他们的工作。我之所以这样命名，是因为这些是你在抱怨同事时会用的名字，而这篇文章主要是为了让人们更了解他们工作中的同事。我自己主要属于骗子和懒人，我认为我在工作中做得很好。下面是一个很好的图表：

这些不是你个性的不可改变的方面。它们更多的是你对软件工程工作的态度的类别——你会因为各种原因而改变你的工作方法，随着你对工作的态度的变化而变化。

骗子 骗子们玩游戏是为了赢。他们仔细考虑如何向领导层展示自己的形象，他们在绩效周期中做出战术决策，他们也很擅长使用组织的语言。他们尊重公司的使命，但他们真正重视的是公司领导层真正关心的东西。尽管名字听起来不太好，骗子们并不是骗子。在一个奖励优质代码和客户满意度的组织中，骗子们会写出优质的代码并让客户满意。但是如果组织奖励其他行为，他们不会牺牲自己的利益来写出优质的代码和让客户满意。

骗子们在大型组织中很擅长完成工作。你希望一个骗子领导一个复杂的工程项目，因为骗子们了解大型组织中的权力杠杆和如何使用它们。但是如果没有骗子的参与，项目往往会因为缺乏买入而神秘地停滞不前。然而，骗子们在改变组织文化方面并不是很擅长。他们倾向于顺应潮流。如果你只有骗子，组织文化可能会自然地退化成一种最低限度的文化。骗子们在做重要但不受奖励的工作方面也不是很擅长。在大多数软件公司中，你真正希望有一些工程师一直关注像可访问性、安全性和性能这样的问题，即使组织作为一个整体并不关心这些问题。那些人可能不是骗子。

信徒 信徒们只想做好工作。他们认为做战术决策和“管理上游”是肮脏的，他们不会这样做。他们真正重视公司的使命，否则他们就不会在那里工作。通常他们在产品决策中投入很大，并将用户体验置于利润之上。信徒们往往被低估，或者是因为疏远领导层，或者只是没有投入足够的精力来晋升。他们不是傻瓜——他们知道通过拒绝玩游戏而付出的政治成本。他们愿意为自己的价值观付出这个代价。

信徒们在保持组织对客户的关注方面很擅长。他们在那里走路，谈论话语，向新员工灌输这样的理念：在这家公司，我们做得很好。他们在保持代码质量和关注需要长期维护的问题（如性能）方面也很擅长。然而，当组织的重点发生变化时，他们可能会挣扎。在我的经验中，当公司成长并更多地进入企业市场时，通常有一群被疏远的信徒，他们变得非常不快乐。如果你的整个组织都是信徒，你将非常擅长执行，但没有灵活性。你会坚持信徒们相信的使命，即使这会让组织直接走向毁灭。

懒人 懒人很放松。他们工作得足够完成任务，但通常不会超过——他们最重要的是避免看起来不必要的工作。他们通常会做很多“吊床时间”：在后台思考工作问题的非工作活动（这对于高级工程师来说尤其如此）。他们仍然认真对待工作：当他们工作时，工作会得到他们的全部关注。但是当他们真的不想做的时候，他们不会强迫自己写代码。为什么要花很多精力去推出中等水平的工作，而不是稍后回来做得更好？

懒人在保持团队的平静和安全环境方面很擅长。他们对有很多最后一刻请求或问题的团队也很有帮助，因为懒人有“系统中的松弛”：他们很少会被特定任务完全占据。然而，对于有很多明确定义的工作排队的团队来说，他们并不是最好的选择——对于那种情况，你想要一个勤奋者。软件工程组织可以在没有懒人的情况下幸存，但当压力增加时，有一些勤奋者在身边会更容易。

勤奋者 勤奋者们全神贯注。总是有一些需要做的事情，勤奋者准备好做。他们只是喜欢这份工作的机制——写代码、审查 PR、回答 Slack 上的问题——或者至少他们喜欢被有用。他们总是专注于一个问题，有时会因为看不到森林而迷失在树林中。然而，如果你需要快速完成一些事情，就交给勤奋者吧。

勤奋者的优点是显而易见的：他们做了很多工作。缺点也很明显：当勤奋者烧毁时，他们会烧毁得很厉害。在我的经验中，勤奋者往往很紧张，因为长时间的高强度工作会对整个系统造成压力。我不认为以勤奋者作为一般的工作方式是可持续的（当然，我会这么说，因为我天生就是一个懒人）。我遇到过很多初级工程师是勤奋者，但很少有高级工程师是勤奋者。我认为这不是偶然的。你要么在前 5-10 年学会放松，要么你会在行业中完全燃烧掉。

总结 如果你是一个骗子，你需要弄清楚如何与信徒合作，因为一个只有骗子的公司不是你想工作的地方。

如果你是一个信徒，你不需要弄清楚如何与骗子合作，但你可能需要非常挑剔地选择你工作的公司。

如果你是一个勤奋者，你需要弄清楚如何与懒人合作，因为你可能会在某个时候成为懒人（或者至少你的很多同事会）。

如果你是一个懒人，你应该尝试理解为什么勤奋者会四处奔波，让每个人都很紧张。你之所以能够懒散，是因为有人愿意偶尔勤奋。

如果你在一个非常和谐的团队中工作，并且不认为这是真的，请去阅读 Hacker News 上一篇随机文章的评论。

HN 热度 219 points | 评论 118 comments | 作者：rbanffy | 1 day ago #

https://news.ycombinator.com/item?id=42319997

  • 作者提到，个人在软件工程中的不同角色并不是固定不变的，而是根据工作方式的变化而变化。
  • 对于不同角色的描述，涉及到信念者、磨坊工、滑行者和诈骗者的阶段性变化。
  • 四象限分析法被广泛应用于商业文本中，通过不同的轴线讲述不同的故事。
  • 典型的四象限图如艾森豪威尔矩阵，强调时间和重要性之间的关系。
  • 有些人认为在工作中可能会经历不同的状态，取决于任务的明确性和方向感。
  • 对于在工作中以 50% 投入度完成任务的看法，有人认为在环境不佳的情况下仍然可以取得成果。
  • 一些人对标签化人们持反对态度，认为这可能会产生消极影响。
  • 有人批评一些理论和思想与科学的距离过远，认为这些是伪科学的表现。

Bringing K/V context quantisation to Ollama #

https://smcleod.net/2024/12/bringing-k/v-context-quantisation-to-ollama/

本文介绍了 Ollama 中的 K/V 上下文缓存量化功能，该功能可以显著减少 VRAM 使用量，允许用户在现有硬件上运行更大的模型或使用更大的上下文大小。文章首先解释了 K/V 上下文缓存量化的重要性，包括运行更大的模型、扩展上下文大小和减少硬件利用率等好处。

然后，文章提供了一个交互式 VRAM 估算器，帮助用户了解 K/V 上下文缓存量化对 VRAM 使用量的影响。估算器允许用户调整模型大小、上下文大小和量化级别，以查看这些因素如何影响内存需求。

文章接着介绍了如何在 Ollama 中启用 K/V 上下文缓存量化，包括构建最新版本的 Ollama、启用 Flash Attention 和设置 K/V 缓存量化级别。文章还讨论了实现限制，包括无法在模型文件中设置量化级别、无法设置 K 和 V 缓存的不同量化级别以及无法通过 Ollama API 或命令行请求量化级别。

随后，文章解释了 K/V 上下文缓存量化的原理，包括 K/V 上下文缓存的概念、量化的定义和 K/V 上下文缓存量化的工作原理。文章还讨论了量化对性能和质量的影响，包括 Q8_0 和 Q4_0 量化级别的性能和质量影响。

最后，文章提供了一些注意事项，包括在嵌入式模型、视觉/多模态模型和高注意力头模型中使用 K/V 上下文缓存量化的潜在问题。

HN 热度 213 points | 评论 30 comments | 作者：mchiang | 22 hours ago #

https://news.ycombinator.com/item?id=42323953

  • 感谢 Ollama 团队及社区的支持，贡献到这个项目令人兴奋。
  • 使用 Ollama 时，可以通过 tuns.sh 建立 SSH 隧道，方便手机访问。
  • 许多 UI（如 OpenWebUI）支持局域网共享，使用 GPU 时仍可通过手机访问。
  • 对于移动平台的 LLM 应用仍然缺乏，期望有更好的 iOS 原生客户端。
  • LibreChat 是个不错的开源选择，支持多种 API 并可以进行身份验证。
  • 在 Windows 上运行 LLM 较难，但 Mac 的表现更佳。
  • Android 本地运行 LLM 的应用如 “pocketpal” 可尝试，但不确定是否与 Ollama 兼容。
  • 集成 K/V 上下文缓存量化到 Ollama 花费了 5 个月，虽然感觉进展慢，但作者解释了原因。
  • Ollama 与 llama.cpp 的整合难度较大，开发者需要克服许多技术挑战。
  • Ollama 不仅是 llama.cpp 的包装器，还提供了热加载模型和自动并行化等功能。
  • Ollama 和 llama.cpp 是不同工具，各有优缺点，不能简单比较。

Next stop: Miami #

https://waymo.com/blog/2024/12/next-stop-miami/

Waymo 宣布将其自动驾驶出行服务 Waymo One 扩展到迈阿密。Waymo 的自动驾驶技术将为迈阿密居民和游客提供更安全、更便捷的出行方式。2025 年初，Waymo 将开始在迈阿密的街道上测试其自动驾驶汽车，预计 2026 年将正式推出服务。

Waymo 与 Moove 合作，将在凤凰城和迈阿密提供自动驾驶出行服务。Moove 将负责管理 Waymo 的车队运营、设施和充电基础设施，而 Waymo 将继续负责验证和操作 Waymo Driver 自动驾驶系统。

Waymo 的自动驾驶技术已经在凤凰城、洛杉矶、旧金山和奥斯汀提供超过 150,000 次出行服务，每周。Waymo 的自动驾驶汽车都是电动汽车，符合环保标准。

迈阿密市长 Francis X. Suarez 表示，Waymo 的自动驾驶技术将为市民提供更安全、更便捷的出行方式，并且符合市政府的可持续发展目标。Waymo 的自动驾驶服务将通过 Waymo One 应用程序提供，用户可以预订自动驾驶出行服务。

HN 热度 206 points | 评论 261 comments | 作者：ra7 | 8 hours ago #

https://news.ycombinator.com/item?id=42328971

  • 迈阿密的夏季暴雨来得快且短暂，自动驾驶汽车应能适应这种天气。
  • 雷达和激光雷达在降雨中受到影响，雨滴的占有率和体积对其性能有直接影响。
  • 道路的维护和排水系统对车辆在雨天的表现影响很大，特别是在大雨后可能形成的大水坑。
  • 自动驾驶汽车在暴雨等极端天气下的反应可能与人类驾驶者相似，可能会选择停下等待天气好转。
  • 如果自动驾驶技术广泛应用，城市居民可能会失去驾驶能力，面对紧急情况时可能会产生道德和实际问题。
  • Waymo 的传感器和摄像头主要在外部，不需要车内的雨刷器来提升能见度，这可能是为了乘客的舒适体验。
  • Waymo 逐步将运营外包给其他公司，目的是专注于软件开发而非资本密集型的运营管理。
  • 在迈阿密等地，暴雨和潮汐洪水会对自动驾驶的安全性和可靠性构成挑战。
  • Waymo 的业务模式正在向更可扩展的方向转变，借助合作伙伴减少资本支出。
  • 自动驾驶的商业化进程需要在车辆维护、地图更新等方面考虑更多的成本因素。

VectorChord: Store 400k Vectors for $1 in PostgreSQL #

https://blog.pgvecto.rs/vectorchord-store-400k-vectors-for-1-in-postgresql

VectorChord 是一个新的 PostgreSQL 扩展，旨在高效地进行向量搜索。它允许用户以极低的成本存储大量向量，例如 400,000 个向量仅需 1 美元。与其他向量数据库或扩展相比，VectorChord 在成本和性能方面具有显著的优势。

VectorChord 的优势在于它使用了 IVF（Inverted File Index）和 RaBitQ 量化技术，这使得它能够快速、可扩展和准确地进行向量搜索。这种方法通过压缩 32 位向量到紧凑的位表示形式，大大减少了计算需求。同时，通过适应性重新排序阶段，VectorChord 保持了高召回率和速度。

与传统的 HNSW（Hierarchical Navigable Small World）方法相比，VectorChord 的 IVF 方法具有更好的性能和可扩展性。虽然 HNSW 在小规模数据集上表现良好，但是在大规模数据集上，它的索引构建时间和内存需求会显著增加。相比之下，VectorChord 的 IVF 方法可以更快地构建索引，并且可以处理更大的数据集。

VectorChord 还支持外部索引构建，这使得用户可以使用更强大的机器进行 KMeans 聚类，然后将索引导入到数据库中。这种方法可以显著加快索引构建时间，并且可以支持更大的数据集。

在 benchmark 测试中，VectorChord 表现出了出色的性能和成本优势。例如，在 LAION 5M 数据集上，VectorChord 的 QPS（每秒查询数）比其他数据库高出 2 倍以上。在 LAION 100M 数据集上，VectorChord 在单机上实现了 16.2 QPS @ recall 0.95 的性能，并且可以线性扩展到多线程环境中。

总之，VectorChord 是一个高效、可扩展和低成本的向量搜索扩展，适合于大规模数据集的应用场景。

HN 热度 151 points | 评论 36 comments | 作者：gaocegege | 22 hours ago #

https://news.ycombinator.com/item?id=42324059

  • VectorChord 与 Datastax 的 AstraDB 在存储成本上相似，但 AstraDB 进行 3 倍数据复制。
  • VectorChord 在性能和更新速度上优于 Elasticsearch 和 OpenSearch，特别是在处理大规模数据集时。
  • IVF 索引不进行重聚类，数据增长后查询速度仍然可接受，但最佳方案是重建索引。
  • VectorChord 正在努力实现与 pgvecto.rs 的功能兼容，并计划停止支持 pgvecto.rs。
  • 多向量嵌入（如 ColBert）在 Postgres 中的索引处理存在挑战，Vespa 可能会造成召回率损失。
  • 对于以文本为主的报告，文本嵌入效果更好，但在特定场景下多向量方法也有其价值。
  • 对于处理数据的预处理和分块策略，社区呼吁分享经验与建议。
  • 向新用户传达产品信息和背景是重要的，尤其在产品页面上提供清晰的指引。

Show HN: Replace “hub” by “ingest” in GitHub URLs for a prompt-friendly extract #

https://gitingest.com/

Gitingest 是一个将 GitHub 仓库转换为简单文本的工具，可以将任何 GitHub 仓库的代码库转换为文本形式，这样就可以方便地将代码库输入到任何大型语言模型（LLM）中。这个工具可以帮助开发者更好地利用 GitHub 上的开源代码。

该工具支持将 GitHub 仓库转换为文本形式，目前已经支持多个示例仓库，包括 Gitingest、Ollama、Flask、TailwindCSS 和 Langchain NextJS 等。这些仓库都是开源的，开发者可以自由地使用和学习。

Gitingest 的开发者是 @rom2，开发者使用 ❤️ 表示对这个工具的热爱。这个工具的出现可以帮助开发者更好地利用 GitHub 上的开源代码，提高开发效率和质量。

HN 热度 146 points | 评论 36 comments | 作者：cyclotruc | 8 hours ago #

https://news.ycombinator.com/item?id=42329071

  • 对代码质量的担忧，认为可能是由 AI 生成的，缺乏开发经验的开发者所写。
  • 提到代码中获取 GitHub 星标数量的部分过多。
  • 质疑使用特殊的 unicode 字符来展示文件结构的有效性，认为其可能会导致解析困难。
  • 对于工具的设计提出建议，希望能直接生成纯文本内容，而不是在富文本页面中。
  • 认为能够将 URL 从 github.com 转换为 gitingest.com 并返回纯文本内容是一个不错的功能。
  • 赞扬工具的简洁性，认为其可以快速将公共代码库的内容提取为 TXT 格式。
  • 询问是否使用了为 Go 语言开发的 txtar 格式，并分享了自己的使用经验。
  • 提出应有过滤功能，以避免不必要的文件占用处理资源。
  • 对工具的稳定性表示关心，鼓励用户反馈问题。
  • 有用户尝试使用工具生成 README 文档，并询问未来的扩展计划。
  • 提到提示长度限制问题，认为大多数项目的代码量过大，不适合直接放入提示中。
  • 讨论构建本地版本以根据文件依赖关系提供更多上下文的想法。
  • 对于 API 作为领域的想法表示赞赏，认为未来将成为一个巨大的超级计算机。