2025 11 28 HackerNews

2025-11-28 Hacker News Top Stories #

  1. Zig 将主仓库从 GitHub 迁移到 Codeberg，保留旧库只读并鼓励通过 Every.org 转移赞助以增强项目自治。
  2. “Bring Back Doors” 呼吁酒店恢复可关闭的浴室门以保障住客隐私，通过数据库与“命名与羞辱”推动行业改进。
  3. Penpot 推出 2.0 作为开源的 Figma 替代品，支持开放标准与自托管，但有用户反映界面异常且反馈未获及时处理。
  4. Google 让 Pixel 10 可与启用 AirDrop 的苹果设备本地点对点互传文件（需 AirDrop 设为“所有人 10 分钟”），实现方式与兼容性细节仍存争议。
  5. 《The Kernel in The Mind》系列首章主张先读源码理解内核本质，讲解调度、系统调用和中断等核心概念并配有练习题。
  6. 文章警告不要下载商家原生 App，建议使用网页版或 PWA 以避免广泛数据收集、监视定价和不利法律条款。
  7. 游戏引擎 s&box 正式开源并采用 MIT 许可证，社区预期开源将加速修复、提升安全并推动生态发展。
  8. 一篇 2026 年版 DIY NAS 方案分享了紧凑高性能配置与权衡，但用户质疑其功耗数据和主板 PCIe 布局限制。
  9. 汇总了 30 条 Gemini CLI 使用技巧，旨在提升终端与 Gemini 模型协作的效率与可扩展性，并强调安全与文档化实践。
  10. 作者警示过度依赖大型语言模型会同质化个人“声音”，呼吁将 LLM 视为辅助手段以保护并培养独特表达。

Zig 项目宣布迁移到 Codeberg，因对 GitHub 近年工程文化衰退、性能下降及 GitHub Actions 严重问题感到失望 (Migrating the main Zig repository from GitHub to Codeberg) #

https://ziglang.org/news/migrating-from-github-to-codeberg/

Zig 项目宣布从 GitHub 迁移至 Codeberg，原因是对 GitHub 近年来工程文化衰退、性能下降以及 GitHub Actions 的严重问题感到失望。作者指出，GitHub 在被微软收购后，优先级转向 AI 推广，导致核心功能如 Actions 出现随机调度、无法手动干预等问题，严重影响 CI 流水线稳定性。

尽管 GitHub Sponsors 曾是 Zig 早期发展的重要资金来源，但随着关键负责人离职，该功能已逐渐被忽视。因此，Zig 软件基金会决定将项目迁移至 Codeberg，以摆脱对 GitHub 的依赖，并提升对开源社区的控制力。

迁移策略为：GitHub 上的 ziglang/zig 仓库已设为只读，主仓库新地址为 https://codeberg.org/ziglang/zig.git。原有 GitHub 的 Issues 和 Pull Requests 保持开放，不强制迁移，但未来所有新问题将从编号 30000 开始，确保编号清晰无歧义。

基金会呼吁现有通过 GitHub Sponsors 捐赠的用户转至非营利平台 Every.org，以支持项目可持续发展。同时，GitHub Sponsors 的专属权益将逐步取消，未来将在 Every.org 上提供等效回馈。

此次迁移也体现了非营利组织在平台资本化趋势下，维护开源“公共领域”的重要价值。

HN 热度 855 points | 评论 790 comments | 作者：todsacerdoti | 23 hours ago #

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

  • 使用 AI 编写代码在编程层面可以接受，但在软件工程层面需谨慎，不能完全依赖 AI，必须有人类的审查与干预。
  • AI 降低了编程门槛，让更多缺乏严谨性的人进入领域，可能带来更大风险，但类似编程语言普及时的情况，关键在于使用者的自律。
  • 软件工程中使用 AI 应是辅助手段，例如用 AI 生成草稿后由人类进行审查、重构和优化，而非直接提交 AI 生成的代码。
  • 无论代码由谁编写，开发者必须对每行代码负责，不能以 AI 为借口推卸责任，否则将对项目和业务造成负面影响。
  • AI 生成的代码常存在冗余、架构不佳等问题，反而增加系统复杂性和维护成本，可能带来净负价值。
  • 从企业或客户角度看，即使 AI 生成的软件质量不高，只要成本低且能快速交付，仍可能优于昂贵但低效的人工开发。
  • 过度依赖 AI 可能导致软件质量下降，但现实中许多人工开发的软件同样存在缺陷，且成本高昂，效率低下。
  • 社会若长期接受低质量产出，将导致高质量工作难以生存，最终损害整体社会福祉，应重视工作尊严与质量。
  • 将 AI 视为“免费的劳动力”或“低成本替代品”虽短期有利，但长期可能削弱技术进步与人才成长，不可持续。

把酒店浴室门还回来 (Bring bathroom doors back to hotels) #

https://bringbackdoors.com/

名为“Bring Back Doors”的个人项目，旨在呼吁酒店恢复浴室门的设置。作者表示，许多现代酒店为了追求“美学”和节省成本，移除了浴室门，导致住客隐私严重受损，甚至影响尊严。

网站的核心功能是帮助旅行者筛选出真正配备浴室门的酒店。作者通过邮件联系了数百家酒店，询问两个关键问题：浴室门是否能完全关闭？是否为玻璃材质？只有那些门能完全关闭且非玻璃材质的酒店才会被收录进数据库。

网站按城市和价格区间分类，提供可信赖的酒店推荐，确保住客拥有基本的隐私保障。同时，页面还提供“检查酒店是否有门”的功能，方便用户在预订前核实目标酒店是否曾被投诉缺少浴室门。

此外，网站鼓励用户主动举报那些没有浴室门的酒店，通过提交酒店名称和照片，让这些酒店被公开曝光，以推动行业改善。项目强调“命名与羞辱”机制，旨在保护未来旅行者的隐私与尊严。

该网站结合了实用信息、公众参与和倡导行动，是一个以旅行者隐私为核心诉求的网络倡议。

HN 热度 772 points | 评论 640 comments | 作者：bariumbitmap | 1 day ago #

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

  • 一些高端酒店设计将淋浴间置于两张床之间，使用全透明玻璃，缺乏隐私，引发对住宿体验的讨论。
  • 伦敦碎片大厦观景台的男厕设有玻璃墙，如在高空如厕，可俯瞰城市景观，带来独特体验。
  • 旧的洛德板球场媒体看台的尿池上方设有窗户，让记者在如厕时仍能关注比赛，兼具功能与趣味。
  • 有用户回忆在博茨瓦纳的野外厕所，虽无遮挡，但可欣赏 180 度草原风光，动物在附近自由活动，别具一格。
  • 智利圣地亚哥某酒店的淋浴间为全透明玻璃，早晨阳光直射，但马桶间有门，提供一定隐私。
  • 有用户回忆纽约某酒吧曾设有直接位于吧台下方的尿槽，方便饮酒者如厕，可能为历史遗留设计。
  • 一些老旧建筑中的尿槽可能曾被用作烟斗吐痰槽，兼具多种用途，历史背景复杂。
  • 高海拔地区的野外厕所无墙遮挡，天气晴朗时可俯瞰山谷甚至海洋，但隐私极差。
  • 野外厕所虽缺乏隐私，但视野开阔，成为一种独特的自然体验。
  • 有用户调侃称，这种将淋浴间置于两张床之间的设计，更像是“柏拉图式友谊”的现实体现。
  • 某些酒店的厕所使用磨砂玻璃，虽有一定遮蔽，但依然让人感到不适，尤其与伴侣同住时。
  • 有用户回忆苏联时期重点中学的宿舍厕所为开放式布局，四座马桶面对面，无任何隔断，体现集体主义设计思想。
  • 军用设施中的卫生间常无隐私，如空军基地或海军基地，习惯于共用空间，对隐私要求较低。
  • 有人分享父亲在酒店洗澡时，因未关门而被误入，反映军旅人员对隐私的淡漠。
  • 公共厕所无隔断的设计在古代罗马已有先例，当时采用环形坐便，体现开放交流理念。
  • 一些老旧宿舍或军营的卫生间为大通间，无任何隔断，虽无隐私，但已成习惯。
  • 有用户指出，厨房与卫生间合用的设计在现代可能已不符合法规，但某些地区仍存在类似布局。
  • 有用户提到索契冬奥会曾建造过类似开放式厕所，体现大型赛事对空间利用的特殊考量。
  • 有人指出“80-ies”应为“80s”，质疑英文表达的规范性。

Penpot：开源的 Figma (Penpot: The Open-Source Figma) #

https://github.com/penpot/penpot

Penpot 是一个开源的设计协作工具，专为设计师与开发者之间的无缝协作而打造。它将设计以代码形式表达，支持 SVG、CSS、HTML 和 JSON 等开放标准，实现从设计到开发的无手稿流程。

该工具提供强大的设计系统功能，包括设计令牌（Design Tokens）、组件（Components）和变体（Variants），确保设计与代码的一致性，提升团队协作效率。最新 2.0 版本引入了 CSS 网格布局、全新的用户界面以及组件系统，显著增强了设计灵活性与可维护性。

Penpot 支持浏览器使用或自托管部署，适用于个人、团队及企业。开发者可通过“检查模式”实时查看元素的 SVG、CSS 和 HTML 代码，加速开发流程。同时，它支持插件系统、Webhook 和 API，便于与现有开发工具链集成。

项目采用 MPL-2.0 开源协议，社区活跃，持续更新。Penpot 还举办年度盛会 Penpot Fest，2025 年活动将在西班牙马德里举行。官网提供用户指南、学习中心和丰富的社区资源，帮助用户快速上手。

HN 热度 684 points | 评论 169 comments | 作者：selvan | 22 hours ago #

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

  • 用户 supermatt 表示曾尝试使用 Penpot，但在导航页面时发现文档内容出现异常变化，因此放弃使用，尽管已向论坛提交问题并附有视频证据，但未获回应。
  • 有用户建议 supermatt 应在 GitHub 上提交正式的 bug 报告，并明确列出复现步骤、预期行为与实际行为，以提高问题被重视的可能性。
  • 另有用户指出，仅提供截图或视频不足以让维护者理解问题，必须清晰描述问题细节，否则容易被忽略。
  • 一些评论者认为，用户不应因未提交正式报告而被指责，批评开源项目中的“你为什么不提交 PR”式态度，强调用户反馈本身具有价值。
  • 有用户指出，问题在 8 个月后仍未修复，说明项目使用率可能较低，且维护者关注度不足。
  • 有人指出 imgur 链接存在大量广告和干扰弹窗，影响体验，建议避免使用此类平台分享内容。
  • 有用户在尝试后确认了 supermatt 描述的问题确实存在，包括按钮宽度变化等视觉异常，表明问题并非个例。
  • 有评论提到 Penpot 的视频链接因地区限制无法访问，但 supermatt 表示自己在欧盟地区可正常访问，问题可能并非地区限制所致。

谷歌宣布 Pixel 10 系列支持与苹果 AirDrop 互操作，用户可通过 Quick Share 向启用 AirDrop 的苹果设备发送文件 (The EU made Apple adopt new Wi-Fi standards, and now Android can support AirDrop) #

https://arstechnica.com/gadgets/2025/11/the-eu-made-apple-adopt-new-wi-fi-standards-and-now-android-can-support-airdrop/

Google 宣布其 Pixel 10 系列手机现已支持与苹果 AirDrop 的互操作，用户可通过 Android 的 Quick Share 功能向启用 AirDrop 的苹果设备发送文件。该功能仅在 Pixel 10 系列上启用，未来可能扩展至更多 Android 设备，但尚未公布具体时间表。支持的条件是 AirDrop 设置为“所有人 10 分钟”模式，而默认的“仅联系人”模式暂不兼容。

文件传输采用本地点对点 Wi-Fi 连接，不经过任何公司服务器，确保传输安全。Google 强调，这一功能的实现得益于 Android 系统中使用内存安全的 Rust 编程语言，有效防止了因恶意数据包引发的内存漏洞。

这一进展被认为与欧盟《数字市场法案》（DMA）有关。该法案要求苹果开放其专有技术，以促进市场竞争。AirDrop 依赖苹果自研的 Apple Wireless Direct Link（AWDL）协议，而 DMA 迫使苹果在合规框架下允许第三方设备接入其无线通信技术，从而促成 Android 与 AirDrop 的兼容。

目前，Google 与苹果尚未就“仅联系人”模式的兼容展开合作，但表示欢迎未来进一步协作。这一变化标志着跨平台生态互操作性的又一重要进展，尤其对混合使用 iPhone 和 Android 设备的用户群体具有实际意义。

HN 热度 574 points | 评论 297 comments | 作者：cyclecount | 1 day ago #

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

  • 有评论指出，尽管欧盟推动了新的 Wi-Fi 标准，但目前尚无确凿证据表明 Android 通过 Wi-Fi Aware 实现了与 AirDrop 的互操作，相关说法仍属推测。
  • 有人通过分析 Google 代码发现其中包含与 AWDL 相关的字符串，暗示其可能逆向实现了苹果的 AWDL 协议，而非使用 Wi-Fi Aware。
  • 有用户通过抓包工具 tcpdump 观察到，AirDrop 在与 macOS 设备传输时仍使用 awdl0 接口，表明仍在使用 AWDL 协议，而非 Wi-Fi Aware。
  • 评论提到，即使 Wi-Fi Aware 未被官方支持，macOS 系统中也存在与 Wi-Fi Aware 相关的框架文件，说明其底层可能已具备相关能力。
  • 有人指出，苹果的 AWDL 协议曾存在严重安全漏洞，谷歌 Project Zero 团队曾发现远程代码执行漏洞，说明谷歌具备逆向分析能力。
  • 有用户确认 AirDrop 在 iOS 15 上仍可与旧设备互通，说明 AWDL 并未被完全弃用，进一步质疑 Wi-Fi Aware 作为互操作基础的说法。
  • 评论认为，Google 实现 AirDrop 互操作更可能是出于对欧盟《数字市场法案》（DMA）监管压力的应对，而非技术驱动。
  • 有人提出，苹果和谷歌应像公共基础设施一样开放协议标准，实现真正互操作，避免用户被锁定在单一生态系统。
  • 有观点认为，当某种技术成为社会必需品（如汽车、手机），就应被视为公共基础设施，需接受公共监管和互操作性要求。
  • 评论指出，当前设备互操作性差的问题根源在于制造商不愿开放标准，仅在监管强制或市场压力下才妥协。
  • 有人强调，真正的互操作性应从公共政策层面立法保障，涵盖智能家居、汽车等所有联网设备，而不仅限于 AirDrop 这类功能。
  • 评论认为，随着设备生态高度垂直整合，用户应有权自由更换品牌设备，而不受数据或功能锁定的限制。
  • 有观点指出，开放标准不仅能提升用户体验，还能带来更大的市场透明度和公平竞争，避免厂商通过封闭生态获取超额利润。

第 1 章：理解 Linux 内核之前先理解代码 (Linux Kernel Explorer) #

https://reverser.dev/linux-kernel-explorer

该网页是《The Kernel in The Mind》系列学习资源的一部分，聚焦于理解 Linux 内核的核心概念。页面以“第 1 章：理解 Linux 内核之前先理解代码”为主题，强调内核并非普通进程，而是系统本身，是连接硬件与软件的永恒权威。它通过调度系统调用、中断和进程管理，为用户进程提供服务，构建了一个虚拟化、映射、隔离且受控的运行体系。页面提供了关键源码文件的链接，包括 init/main.c、kernel/fork.c、include/linux/sched.h 和 arch/x86/kernel/entry_64.S，便于深入学习。同时设置了三道知识检测题，帮助读者巩固对内核本质、服务方式及系统分层的理解。整体结构清晰，适合初学者建立对内核的正确认知。

HN 热度 523 points | 评论 79 comments | 作者：tanelpoder | 18 hours ago #

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

  • Linux 内核探索工具的界面设计让人联想到塔木德文献的排版，体现了多层注释与文本交织的特点。
  • 塔木德的页面布局是 16 世纪基督教印刷商所创，并非原始文本固有特征，其注释系统是印刷时代的产物。
  • 将塔木德比作早期“超文本”并不完全准确，它更接近法律文献，而卡巴拉才是更符合超文本概念的体系。
  • 塔木德的跨文本引用功能在数字时代可通过超链接实现，已有如 Al Hatorah 和 Sefaria 等平台提供此类功能。
  • Sefaria 等数字平台极大提升了经典文本的可访问性，其开放 API 为开发者提供了强大支持。
  • 数字化工具如 chavrutAI 利用 Sefaria API 构建了具有现代交互体验的塔木德阅读器。
  • 与已有内核源码浏览器（如 Elixir）相比，该工具在 AI 功能、依赖图谱或智能解释方面尚无明显突破。
  • 当前 AI 时代对代码导航工具的期待虽高，但实际进展仍停留在功能复刻层面，缺乏真正创新。
  • 项目因未认证的 GitHub API 请求导致速率限制问题，建议通过登录或使用代理/IP 伪装解决。
  • 缓存机制可有效缓解性能瓶颈，且在简单实现上叠加缓存比复杂实现更优。
  • 过度复杂的缓存层可能反而降低系统可维护性，简洁可靠的实现更具优势。

别下载应用程序 (Don’t Download Apps) #

https://blog.calebjay.com/posts/dont-download-apps/

商家频繁诱导顾客下载应用程序，甚至出现工作人员在顾客不注意时擅自安装应用的情况。作者提醒，切勿将手机交予他人，也坚决不要下载任何应用。

主要原因有两点：一是进入“监视资本主义”时代，企业通过收集用户数据实现“监视定价”，即根据个人消费能力、收入状况等动态调整价格。例如，刚领工资的人可能被收取更高价格，而长期未付款的人则可能获得优惠。这种定价机制使企业掌握货币价值的决定权，削弱了市场竞争的公平性。

二是应用的“服务条款”中常包含“强制仲裁”条款。一旦用户下载应用并同意条款，就可能在发生纠纷时被强制通过私人仲裁解决，而非进入司法系统。仲裁员由企业聘请，缺乏独立性，且用户需承担费用。案例显示，一名顾客因妻子在迪士尼乐园食物中毒去世，仍被要求通过仲裁解决，仅因曾注册过迪士尼 + 的免费试用。该案例最终因舆论压力才被撤销，但类似情况可能频繁发生。

作者预测未来几年内，类似事件将更加普遍：如使用 Uber Eats 导致车祸、特斯拉自燃、亚马逊员工工伤等，都可能因用户拥有相关平台账户而被强制仲裁。

因此，作者强烈建议：不要下载任何应用，保护个人数据和法律权利。

HN 热度 409 points | 评论 256 comments | 作者：speckx | 1 day ago #

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

  • 使用 PWA 替代社交应用能减少使用频率，因为 PWA 体验普遍较差，这反映出公司并不希望网页体验能媲美原生 App。
  • 某些网站的移动端版本功能缺失或体验糟糕，而桌面端响应式设计反而更完善，可能因为不同团队负责不同版本。
  • 在 Android 上通过 Firefox 设置为桌面模式并调整屏幕宽度，可改善网站使用体验。
  • 网站的移动端和桌面端由不同团队开发，导致移动端体验不一致，而桌面端因统一开发，体验更连贯。
  • 使用 uBlock Origin 过滤器可屏蔽“下载 App”提示，提升网页使用体验。
  • Firefox 的 about:config 中设置 browser.viewport.desktopWidth 可调整桌面模式显示宽度，但需注意设置可能重启后失效。
  • 启用 general.aboutConfig.enabled 可避免每次进入 about:config 时使用复杂 URL。
  • 社交媒体 App 通过 Cookie 跨站追踪用户行为，而 iOS 限制了 App 间直接追踪，但 App 仍可通过登录账户获取完整数据。
  • 网站无需登录即可被追踪，而 App 通常需要登录，因此 App 能更完整地关联用户行为。
  • App 常将外部链接在内部 WebView 中打开，便于全程追踪用户活动。
  • 即使未登录，Facebook 等平台也能通过第三方网站追踪用户浏览行为。
  • 通过浏览器可阻断 Cookie、屏蔽域名、修改 DOM、禁用追踪链接等，而 App 中这些能力受限。
  • 现代浏览器默认阻止第三方 Cookie，有效防止跨站追踪，但仍有指纹识别等其他追踪方式。
  • 应用可通过浏览器环境信息（如系统、硬件、语言等）进行指纹识别，与网页追踪方式类似。
  • 使用 VPN 或 Tor 可隐藏 IP 地址，防止服务器通过 IP 追踪用户，App 同样可借助这些工具隐藏 IP。
  • 一些 PWA 应用（如 Mastodon、Photoprism）性能优秀，甚至优于原生 App，说明 PWA 有潜力。
  • 有些 PWA 应用（如 Phanpy）在联邦网络中表现极佳，是目前体验最好的网页应用之一。
  • 现代“原生 App”很多实际上基于 Web 技术构建，与网页端共享相同 API，因此网页端不应更慢。
  • 普通用户不区分网页应用与原生 App，一旦添加到桌面就视为“App”，缺乏技术认知差异。
  • 优秀的跨平台 Web 应用存在，尤其在非社交或非监控类场景中表现更佳。

S&box 正式开源，采用 MIT 许可证发布 (S&box is now an open source game engine) #

https://sbox.game/news/update-25-11-26

s&box 于 2025 年 11 月 26 日发布更新 25.11.26，正式宣布项目开源，采用 MIT 许可证，开发者可自由查看、修改、复制代码，用于个人项目或维护独立分支。该引擎并非 Valve 的 Source 2 源码，而是基于 Source 2 底层系统构建，其上层功能如编辑器、网络、场景系统、UI 等均为 C#实现。

本次更新重点包括：

  • 地形系统优化：修复 LOD 过渡时的接缝问题，并引入纹理分段旋转技术，有效减少明显贴图重复（anti-tiling），提升视觉表现。
  • 网络功能增强：修复道具破碎时碎块仅在主机显示的问题，支持定义碎块为客户端独有，提升多人游戏体验。
  • 内存管理重构：完全重写 C++ 层内存分配机制，从 jemalloc 切换至 mimalloc，提升可维护性，并支持 Address Sanitizer 等调试工具。
  • Play Mode 重大修复：解决 VR 渲染、环境光贴图、交换链泄漏、文本输入框失效、光标卡顿、选择框异常等大量问题，同时恢复 GameEditorSessions 功能，实现编辑器与场景状态的精准同步。
  • UI 与工具改进：新增 UI 控件如 ColorControl、Label.Tokenize 选项、TextEntry 支持以#开头的字符串，优化控件渲染顺序和属性绑定。

此外，更新还修复了包括视频线程未及时终止、场景追踪错误、材质显示异常、菜单项目误加载等数十项问题，并移除了旧版软体节点和冗余文件。

社区反馈积极，普遍认为开源将加速问题修复、增强安全性，并推动 s&box 成为 Unity 和 Godot 的有力竞争者。开发者表示，此举源于对创作的热爱，旨在为游戏开发生态提供开放工具，实现共赢。

HN 热度 407 points | 评论 141 comments | 作者：MaximilianEmel | 1 day ago #

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

  • S&box 游戏引擎由 Facepunch 工作室开发，该工作室以 Garry’s Mod 和 Rust 等游戏闻名，虽不常受关注但年收入接近 1 亿美元，公司由创始人 Garry Newman 完全掌控。
  • Garry Newman 曾开发过 UI 库 GWEN，虽已多年未更新，但其技术影响仍在，如今他仍在推动创新。
  • S&box 的 UI 系统基于 HTML/CSS 与 Razor，但并非使用浏览器渲染，而是自研框架，提升了开发效率。
  • Rust 游戏与 Rust 编程语言常被混淆，但两者并无关联，Rust 游戏由 Facepunch 开发，而 Rust 语言是另一独立项目。
  • Rust 游戏最初源于对 Day Z 的改进，后因开发纠纷导致重写，最终发展为长期活跃且持续更新的热门游戏。
  • S&box 原基于 Unreal Engine 4，后因 Valve 提供 Source2 开发工具而迁移至 Source2，并构建了基于.NET 的开发框架，成为对 UE 和 Unity 的有力竞争者。
  • Source2 最初并非专为 VR 设计，而是用于 Dota 2、CS2 等项目，SteamVR 环境虽未完全成熟，但整体生态健康。
  • 当前游戏引擎生态丰富，包括 Godot、Stride、Unigine、O3DE、Flax 等，但多数仍沿用类似 UE 和 Unity 的通用 UI 设计，缺乏创新。
  • 有观点认为，游戏引擎应具备如 Emacs 或 Vim 般的独特哲学，但现实中多数开发者更关注快速交付而非工具哲学。
  • 多数开发者对引擎 UI 的不满源于长期积累的复杂性，而非 UI 本身，UE、Unity 和 Blender 等工具历经数十年才达到可用状态。
  • 批评引擎生态的人忽视了开发者付出的努力，许多引擎是免费且开源的，值得尊重。
  • 实际上，大多数开发者使用主流编辑器，对 UI 差异并不敏感，更关注开发效率和项目交付。
  • 代码应使用文本编辑器处理，3D 资产、动画、纹理等非文本内容可使用专业工具，无需依赖引擎 UI。
  • 计算着色器等技术虽标准化，但开发仍需借助特定工具或脚本语言，工具链仍需持续完善。

DIY NAS：2026 版 (DIY NAS: 2026 Edition) #

https://blog.briancmoses.com/2025/11/diy-nas-2026-edition.html

本文是作者 Brian Moses 关于 2026 年 DIY NAS（网络附加存储）构建的详细分享，延续了他自 2011 年起每年更新一次的 DIY NAS 项目传统。文章核心介绍了一台 8 盘位、支持 10GbE 网络、搭载 Intel N355 处理器、32GB DDR5 内存的紧凑型 NAS 系统，整体体积小于 20 升，适合办公空间有限的用户。

作者提出构建 NAS 的四大核心标准：小体积、至少 6 个硬盘位、低功耗集成 CPU、具备家庭实验室扩展潜力。他强调这些标准因人而异，建议每位构建者根据自身需求定制方案。

在硬件选型方面，作者选用 Topton N22 主板搭配 Intel Core 3 N355 CPU，该 CPU 拥有 8 核 8 线程、15W TDP，支持 Intel Quick Sync 视频加速，性能足以支撑媒体流、虚拟机、游戏服务器等扩展应用。主板配备 8 个 SATA 接口、2 个 M.2 NVMe 插槽、1 个 10GbE 网卡和 2 个 2.5GbE 网卡，扩展性出色。

机箱选用 JONSBO N4，支持 6 个 3.5 英寸和 2 个 2.5 英寸硬盘位，虽有部分硬盘位未连接背板导致更换不便，但价格仅为同类产品三分之一，性价比高。为解决原装风扇噪音问题，作者更换为 Noctua NF-A12x25 PWM 风扇，并接入主板 SYS_FAN 接口，实现 BIOS 调速，显著降低噪音。

内存方面，作者使用一条 32GB DDR5 4800MHz SODIMM，虽有意愿升级至 48GB，但因价格过高（约 250-300 美元）而放弃。他提醒读者当前内存价格高企，建议提前囤货。

存储部分，作者强调所有硬盘均为已有库存，未新增采购，体现其“趁便宜时囤货”的策略。他指出当前硬件价格普遍上涨，尤其是 CPU、内存和硬盘，预计未来可能更贵，因此决定不推迟发布，以免错过时机。

整体来看，这是一次兼顾性能、扩展性与成本控制的高性价比 NAS 构建，适合希望打造高效、安静、可扩展的家庭服务器的爱好者。

HN 热度 385 points | 评论 247 comments | 作者：sashk | 22 hours ago #

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

  • 该 NAS 在待机状态下的功耗高于用户整个网络设备（包括 UNAS Pro、Mac mini、4 个无线接入点和 4 个摄像头）的总功耗，引发对功耗数据真实性的质疑。
  • 用户指出，根据实际测量，其 UNAS Pro 配置的总待机功耗应低于 67W，而其他设备的功耗不可能低至 17W 以下，因此原帖数据存在明显错误。
  • 建议将 500W 电源更换为 250-300W 更小功率的电源，以提升低负载下的电源效率。
  • 用户表示其主要存储在云端，但并非完全依赖云服务，而是采用“3-2-1”备份策略，将工作副本放在云端，本地作为备份，同时通过自托管实现远程访问的可靠性。
  • 有用户指出，N 系列 CPU 主板在 PCIe 布局上存在限制，导致 NVMe 固态硬盘仅能以 1/8 的速率运行，对性能有显著影响。
  • 对于仅用于局域网存储的 NAS，N 系列 CPU 虽低功耗，但存在性能瓶颈，建议选择 AM4 平台以获得更好的 PCIe 扩展性和更高的性能。
  • 在 NAS 场景下，存储速度通常远超网络带宽，因此存储性能的提升意义有限，除非直接运行虚拟机等高负载应用。
  • 有用户强调，NAS 的核心组件应从可靠厂商购买，避免在 AliExpress 上购买主板等关键部件，以防买到翻新或假冒产品。
  • 针对 AliExpress 购买主板的争议，指出该主板来自官方店铺，与直接从厂商购买无异，但依然承认其售后体验可能不如其他渠道。
  • 建议跳过 TrueNAS，直接使用 FreeBSD 作为 NAS 操作系统，因其简单易维护。
  • 推荐使用 NixOS 作为 NAS 系统，支持声明式、可复现的配置管理，便于迁移和维护。
  • 认为 NixOS 虽然学习成本略高，但与 FreeBSD 相比，复杂度差异不大，取决于用户熟悉程度。

Gemini CLI 智能编程使用技巧指南 (Gemini CLI tips and tricks for agentic coding) #

https://github.com/addyosmani/gemini-cli-tips

这是一个关于 Gemini CLI 的使用技巧指南，旨在帮助开发者高效利用 Google 的 Gemini 模型在终端中进行智能编程和系统操作。Gemini CLI 是一个开源的命令行工具，能够通过自然语言与用户交互，执行多步骤任务，如代码生成、调试、文件编辑和系统配置，相当于一个智能的“编程搭档”。

指南共包含 30 条实用技巧，涵盖从基础设置到高级功能的各个方面。例如，使用 GEMINI.md 文件保存长期上下文，创建自定义快捷命令，扩展功能通过 MCP 服务器，利用记忆功能进行上下文召回，以及使用 /restore 恢复到之前的会话状态，相当于“撤销”操作。

用户可以通过 @ 符号引用文件或图片，实现多模态输入，让 AI 更准确理解需求。Gemini CLI 还支持动态创建工具，甚至能帮你编写辅助脚本。在系统调试、配置管理方面，它能自动分析问题并提出解决方案。

对于高级用户，提供了 YOLO 模式（自动批准操作，需谨慎使用）、后台运行模式（headless）、脚本化调用等能力。支持保存和恢复聊天会话，可在多个目录间切换工作空间，实现多项目管理。

还介绍了如何通过 settings.json 自定义行为，集成 VS Code 提供代码上下文和差异对比，结合 GitHub Action 实现自动化任务。同时建议开启遥测以获取使用数据，关注未来路线图中的“后台代理”等新功能。

此外，指南提到可通过扩展和插件增强功能，并隐藏了“Corgi Mode”彩蛋，增加趣味性。整体上，该页面为开发者提供了从入门到进阶的完整使用指南，强调安全、效率与可扩展性。

HN 热度 383 points | 评论 131 comments | 作者：ayoisaiah | 1 day ago #

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

  • 使用 AI 生成代码时应保持务实态度，避免过度依赖复杂工具如 MCP 服务器，因为其可靠性不足且容易过时。
  • 将 LLM 视为统计文档生成器，通过不断优化约束性提示词来实现快速迭代和精准输出。
  • 重视文档和规范的建立，将问题定义、计划和实现过程写入文档（如 dotMD），形成可复用的知识体系。
  • 与 AI 协作应像指导新员工一样，通过持续反馈和改进文档来提升 AI 输出质量，而非简单地放弃或手动重做。
  • 拒绝将 AI 拟人化，但也不应完全视其为机器，合理的心理模型是将其当作“有局限但可引导的助手”。
  • AI 不具备真正学习能力，重复指导无效，因此必须将关键指导信息固化在可持久访问的上下文中。
  • 与 AI 的交互应注重信息整洁和清晰表达，避免冗余内容干扰模型判断，提升沟通效率。
  • 在复杂任务中，AI 的生成能力受限于其训练数据和上下文窗口，需结合手动编写或代码补全工具提升效率。
  • 当前 AI 工具在复杂编码任务上表现不佳，尤其在工具调用和推理能力方面落后于其他模型（如 Claude Code）。
  • 通过构建可回溯的开发环境（如支持时间旅行、分支、克隆的系统），可以有效管理 AI 生成过程中的试错成本。
  • 生成式 AI 带来的最大价值在于快速原型和节省时间，但若陷入无休止的反馈循环，则反而成为效率负担。

我们正在失去自己的声音，被大语言模型所吞噬 (We’re losing our voice to LLMs) #

https://tonyalicea.dev/blog/were-losing-our-voice-to-llms/

本文探讨了在大型语言模型（LLM）盛行的时代，人们正在逐渐失去独特的个人声音。作者指出，社交媒体上越来越多的内容由 AI 生成，导致所有帖子的语气和风格趋同，缺乏个性。这种“统一声音”削弱了个体表达的独特价值。

作者强调，个人的声音是一种宝贵的资产，它不仅体现在内容本身，更体现在表达方式上。这种声音源于个人的生活经历、情感状态和成长历程，是独一无二的。长期坚持用自己真实的声音写作，能让他人产生认同感、信任感，甚至在职业发展中带来机会。

文章提醒，即使使用 LLM 辅助写作，也不应完全依赖 AI“模仿”自己的声音。因为真正的声音是动态变化的，会随着人生阶段和心境波动而发展。强行让 AI 复制，反而会抑制这种自然成长，导致表达能力退化。

最后，作者呼吁大家珍惜并主动培养自己的声音，不要因依赖技术而让思想变得平庸。写自己真正想说的话，才是最有力量的表达。

HN 热度 328 points | 评论 347 comments | 作者：TonyAlicea10 | 10 hours ago #

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

  • LLMs 并未真正导致“失去自我声音”，真正的问题在于此前网络内容就已趋向同质化，如短评、中等长度博客和企业化语气。
  • LLMs 可能反而推动人们回归独特表达，因为当前的“平庸”已成为默认背景，促使人们寻找差异化声音。
  • LLMs 通过标准化“HR 批准的平庸观点”加速了网络极端化，想显得像真人，反而需说出让安全团队震惊的内容。
  • 人们可使用非对齐或自托管的 LLM 生成激进言论，因此所谓“安全团队心碎”的说法并不成立。
  • 强调使用极端言论作为身份认同是一种群体性“邪教行为”，即使无意为之也具有类似特征。
  • Grok 等模型虽有争议性，但其语气仍显尴尬，未能真正代表反主流文化。
  • LLMs 如同“智力上的黑脸”，让思维迟钝者伪装成有见识者，以获取虚假的权威感。
  • 过度追求“反叛”却无实质内容，只会显得刻意模仿“文人”形象，反而暴露浅薄。
  • 算法驱动的内容生产机制（如短句、热梗、情绪煽动）正在让人类思维趋于机械化。
  • 个人写作即使亲手完成，若受制于流量、SEO 和职场规范，仍可能丧失真实声音。
  • 内容创作的同质化并非由 LLMs 造成，而是长期受商业利益驱动的结果，如今内容生产成本趋近于零。
  • LLMs 并未消灭内容创作，而是让内容生产更廉价，但真正有价值的内容仍需人类创造力。
  • 人们选择迎合算法和商业规范，主动放弃个性表达，这是主动选择的结果而非被动丧失。
  • 使用 LLM 生成内容并署名，等同于主动采纳一种“平庸企业化声音”，并非 LLMs 本身在抹杀个性。
  • 有效利用 LLM 的关键在于将其作为自我审视工具，而非直接采纳其修改建议，避免陷入语言同质化陷阱。

Hacker News 精彩评论及翻译 #

Migrating the main Zig repository from GitHub to C… #

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

it’s abundantly clear that the talented folks who used to work on the product have moved on to bigger and better things, with the remaining losers eager to inflict some kind of bloated, buggy JavaScript framework on us in the name of progress.

More importantly, Actions is created by monkeys

This writing really does not reflect well on Zig. If you have technical issues with Github, fine: cite them. But leave ad hominems like “losers” and “monkeys” out of it.

johnfn

很明显，过去曾负责该产品的天才们已经去追求更好的发展了，而剩下那群败类却打着进步的旗号，迫不及待地想把那种臃肿又满是 bug 的 JavaScript 框架强加给我们。

更重要的是，Actions 是由猴子们搞出来的。

这种写法对 Zig 的形象实在不好。如果你对 GitHub 有技术上的问题，没问题：就事论事地指出。但别用“败类”和“猴子”这类人身攻击。

Migrating the main Zig repository from GitHub to C… #

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

As a bonus, we look forward to fewer violations (exhibit A, B, C) of our strict no LLM / no AI policy,

Hilarious how the offender on “exhibit A” [1] is the same one from the other post that made the frontpage a couple of days ago [2].

[1] https://github.com/ziglang/zig/issues/25974

[2] https://news.ycombinator.com/item?id=46039274

quirino

此外，我们也期待违反我们严格的“禁止使用LLM/AI”政策的情况能有所减少（证据A、B、C）。 “证据A”中的违规者[1]就是前几天登上热榜的那篇帖子[2]里的同一个人，真是可笑。

Migrating the main Zig repository from GitHub to C… #

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

Amusingly, this post violates Zig’s own code of conduct: https://ziglang.org/code-of-conduct

Examples of behavior that contribute to creating a positive environment include:

  • Using welcoming and inclusive language.
  • Being respectful of differing viewpoints and experiences.
  • Showing empathy towards others.
  • Showing appreciation for others’ work.

ericpruitt

有趣的是，这篇帖子违反了 Zig 自己的行为准则：https://ziglang.org/code-of-conduct

有助于创造积极环境的行为示例包括：

  • 使用热情和包容的语言。
  • 尊重不同的观点和经历。
  • 对他人表示同理心。
  • 欣赏他人的工作。

Bring bathroom doors back to hotels #

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

Huh.. I’ve stayed in over 1,000 hotels and Airbnbs over the last 15 years and not once saw a bathroom with no door. Lots of bathroom windows, but always some kind of door.

rjdj377dhabsn

呃……过去15年我住过一千多家酒店和民宿，从未见过没有门的卫生间。卫生间倒是见过不少，但总归是有门的各种。

Bring bathroom doors back to hotels #

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

It’s not about saving a few bucks on a door. It’s about discouraging you and your friends from sharing a single room. Hotel sees the money they’re leaving on the table and will trade you for it for the low price of watching your buddies do their business.

akersten

问题不在于省下几块钱的门费，而在于阻止你和朋友们共用一间房。酒店看到了他们因此损失的收益，于是便用你们朋友在房间里的一举一动作为交换，来换取那笔钱。

Gemini CLI tips and tricks for agentic coding #

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

I am not doing any of this.

It becomes obsolete in literally weeks, and it also doesn’t work 80% of the time. Like why write a mcp server for custom tasks when I don’t know if the llm is going to reliably call it.

My rule for AI has been steadfast for months (years?) now. I write (myself, not AI because then I spend more time guiding the AI instead of thinking about the problem) documentation for myself (templates, checklist, etc.). I give ai a chance to one-shot it in seconds, if it can’t, I am either review my documentation or I just do it manually.

preommr

我才不干这些呢。

这些东西几周内就会过时，而且有80%的时候都不管用。比如说，我都不知道这个大语言模型能不能可靠地调用它，那我为啥还要为自定义任务写个MCP服务器呢？

我对AI的规则已经坚定了好几个月（甚至好几年了）。我自己写文档（是我自己写，不是AI写的，因为如果让AI写，我花在引导AI上的时间会比花在思考问题上的时间还多），也就是给自己写写模板、清单之类的东西。我会给AI一个机会，让它几秒钟内一次性搞定。如果它搞不定，我就要么重新审视我的文档，要么就干脆自己动手做。

Bring bathroom doors back to hotels #

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

I once stayed at a very boutiquey, avant-garde hotel with a platonic friend. We had booked a twin room with separate beds, but what I did not expect was that the shower cubicle, with clear glass on all three sides, would be placed between the beds.

decimalenough

我曾和一个柏拉图式的朋友住过一家非常时髦前卫的精品酒店。我们订的是一间有两张独立床铺的双床房，但我没想到的是，淋浴间装在了两张床之间，而且三面都是透明的玻璃。

We’re losing our voice to LLMs #

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

I deleted my Facebook account a couple of years ago and my Twitter one yesterday.

It’s not just LLMs, it’s how the algorithms promote engagement. i.e. rage bait, videos with obvious inaccuracies etc. Who gets rewarded, the content creators and the platform. Engaging with it just seems to accentuate the problem.

There needs to be algorithms that promote cohorts and individuals preferences.

Just because I said to someone ‘Brexit was dumb’, I don’t expect to get fed 1000 accounts talking about it 24/7. It’s tedious and unproductive.

ricardo81

几年前我删除了我的Facebook账户，昨天又删除了Twitter。

这不仅仅是大型语言模型的问题，更是算法如何提升用户参与度的问题。比如，为了引发争议而发布的煽动性内容、有明显错误信息的视频等等。最终获利的是内容创作者和平台本身。与这些内容互动只会让问题变得更糟。

我们需要能够促进社群和个体偏好的算法。

就因为我曾对某人说“脱欧很蠢”，我不希望自己会被24/7地推送上千个相关账户的信息。这既乏味又毫无益处。

Mixpanel Security Breach #

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

I hate how this is written. At no point does it disclose explicitly:

  • What systems were accessed

  • What information was potentially exposed

  • Just how “proactively” they’ve been about this (no timeline)

  • Numbers… The scale of any of it

Some comments from quoted portions of article

Mixpanel detected a smishing campaign …

Doesn’t give any details on who the companion targeted, or how, or how widespread.

We took comprehensive steps to contain and eradicate unauthorized access and secure impacted user accounts.

So there was definitely some sort of unauthorized access, but doesn’t say to which accounts or in what systems

Performed global password resets for all Mixpanel employees

So… definitely sounds like they expected compromise of Mixpanel employee credentials

cobertos

我非常讨厌这篇文章的写法。它从头到尾都没有明确披露：

  • 访问了哪些系统
  • 哪些信息可能已泄露
  • 他们所谓的“积极主动”到底有多到位（没有时间线）
  • 具体的数字……即任何事件的规模

以下是对文章引用部分的评论：

Mixpanel检测到了一场“网钓式短信”活动……

没有提供任何关于攻击目标、方式或波及范围的具体细节。

我们采取了全面的措施来控制和消除未授权访问，并保障了受影响用户账户的安全。

所以，确实发生了某种形式的未授权访问，但没说明是哪些账户，或在哪些系统中发生的。

为所有Mixpanel员工执行了全局密码重置。

所以……听起来他们显然预计Mixpanel员工的凭证已被攻破。

Show HN: Safe-NPM – only install packages that are… #

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

“Here, install my new 1-day old NPM package that doesn’t let you install packages younger than 90 days.”

Pardon me, I couldn’t help myself :D

sebmellen

“来，装一下我这个发布才一天的 NPM 包，它不允许你安装任何创建时间少于90天的包。”

不好意思，我实在是忍不住了 :D

Green card interviews end in handcuffs for spouses… #

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

A note that it’s easy to “overstay” a visa when waiting for a green card interview - the wait times are often in the 6-16 month range, and if you leave the country you’ll be considered to have abandoned your “petition to adjust status”. It’s a catch-22, and it looks like the only recourse is for an immigration lawyer to file a habeas corpus petition in federal court.

nxobject

请注意，在等待绿卡面试期间很容易“逾期滞留”——等待时间通常在6到16个月之间，而一旦离境，你就会被视为已“放弃调整身份的申请”。这是一个两难的困境，看来唯一的办法就是请移民律师在联邦法院提交人身保护令的请愿书。

Migrating the main Zig repository from GitHub to C… #

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

Calling the people who work on GitHub “losers” is not cool.

munchler

称GitHub上的工作人员为“失败者”可不好。

TPUs vs. GPUs and why Google is positioned to win … #

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

Google’s real moat isn’t the TPU silicon itself—it’s not about cooling, individual performance, or hyper-specialization—but rather the massive parallel scale enabled by their OCS interconnects.

To quote The Next Platform: “An Ironwood cluster linked with Google’s absolutely unique optical circuit switch interconnect can bring to bear 9,216 Ironwood TPUs with a combined 1.77 PB of HBM memory… This makes a rackscale Nvidia system based on 144 “Blackwell” GPU chiplets with an aggregate of 20.7 TB of HBM memory look like a joke.”

Nvidia may have the superior architecture at the single-chip level, but for large-scale distributed training (and inference) they currently have nothing that rivals Google’s optical switching scalability.

m4r1k

谷歌真正的护城河并非TPU芯片本身——这与散热、单芯片性能或超专业化无关——而是由其OCS互连技术所实现的巨大并行规模。

引用《The Next Platform》的话来说：“通过谷歌独有的光路交换互连技术连接的铁木集群，可动用多达9216颗铁木TPU，合计拥有1.77 PB的HBM内存……这使得基于144颗‘Blackwell’GPU芯片、聚合内存容量为20.7 TB的一整机架Nvidia系统，看起来像个笑话。”

英伟达在单芯片层面可能拥有更优越的架构，但在大规模分布式训练（及推理）方面，他们目前还无法与谷歌的光交换可扩展性相抗衡。

Migrating the main Zig repository from GitHub to C… #

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

As a bonus, we look forward to fewer violations (exhibit A, B, C) of our strict no LLM / no AI policy, which I believe are at least in part due to GitHub aggressively pushing the “file an issue with Copilot” feature in everyone’s face.

Also, the big part of that issue is people are incentivized to make their GitHub profile look good to have a higher chance of getting hired. Any non-mainstream platform is not as compelling to get social credits.

SoKamil

此外，这个问题的核心在于，人们为了有更高的求职几率，会受到激励去让自己的 GitHub 个人资料看起来更出色。任何非主流平台都不太能提供这种“社交信用”。

Bring bathroom doors back to hotels #

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

I don’t think that adds up.

“Staying in a hotel with a romantic partner and/or family” is at least as primary a use case for hotels as “staying in a hotel with a platonic friend” and is still a scenario where you want a door but is NOT a scenario where “just get separate rooms” is a logical conclusion. “Get the hell out of that hotel and complain about it to everyone you know,” on the other hand, is.

The much more specific way to target platonic buddies/coworkers from sharing a room would be eliminating rooms with two beds since the “couple” scenario would generally be perfectly happy with that still.

majormajor

我觉得这说不通。

“与伴侣和/或家人住酒店”至少和“与普通朋友住酒店”一样，是酒店的主要使用场景。在这两种情况下，你都想要一扇门，但后一种情况（与普通朋友同住）却得不出“直接开两个房”的合乎逻辑的结论。相比之下，“赶紧离开那家酒店，并向你认识的每一个人抱怨”才是更合理的。

要想更有针对性地避免普通朋友/同事合住，更好的方法是取消双床房，因为情侣们通常对双床房完全没有意见。

OpenAI needs to raise at least $207B by 2030 #

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

Unfortunately for OpenAI, they are not positioned to capture value from any of the “big margin” use cases that they highlight as key to their future. I think all of these are pretty unrealistic for them:

  • Revenue sharing from drug discovery (called out by OpenAI CFO): Why would a pharma company give away the upside to a commoditized intelligence layer? Why would OpenAI have a more compelling story than Google Deep Mind, which has serious accolades in this space?

  • Media generation for ads and other content: For ads, OpenAI is facing off against Google, Meta and Amazon, all of which have existing relationships with advertisers. For the foreseeable future, AI content will be a major discount product compared to humans. OpenAI will not get to charge $1M for an ad like a production company does. So the TAM of ad production (~$50B) shrinks below $1B because AI deflates prices so much.

  • Other agent use cases: OpenAI doesnt have a surface to build these on. Google has chrome, Microsoft has office, Apple has OS’s. The other use cases like coding will be a low-margin competition between model providers until some of them throw in the towel. The players with the best cash position win - and thats not OAI.

I think the place that they could win is retail (also called out by OAI CFO). They made deals with Etsy and other small retailers. I was fixing my guitar the other day and would have instantly bought the tools it had suggested that I would need. The problem is that they have to win against Amazon here, and there is zero chance of a partnership for obvious reasons.

liamconnell

对 OpenAI 来说不幸的是，他们无法从自己所强调的那些关乎未来的“高利润”用例中捕获价值。我认为他们提出的这些设想都相当不切实际：

  • 药物研发的收入分成（由 OpenAI 首席财务官提出）：制药公司为什么要将利润分给一个已被商品化的智能层？为什么 OpenAI 的故事会比谷歌 DeepMind 更有说服力？后者在这一领域拥有备受赞誉的卓越成就。

  • 广告和其他内容的媒体生成：在广告领域，OpenAI 正在与谷歌、Meta 和亚马逊等现有广告商关系稳固的公司竞争。在可预见的未来，AI生成的内容与人类内容相比将是一个低价产品。OpenAI 不可能像制作公司那样为一则广告收取 100 万美元。因此，广告制作的市场规模（约 500 亿美元）会因为 AI 大幅压低价格而缩减到 10 亿美元以下。

  • 其他智能体用例：OpenAI 没有可以构建这些用例的平台。谷歌有 Chrome，微软有 Office，苹果有操作系统。其他用例（如编程）将成为模型提供商之间的低利润竞争，直到其中一些玩家放弃。现金储备最雄厚的玩家才能胜出——而那不是 OpenAI。

我认为他们有可能赢得的领域是零售业（OpenAI 首席财务官也提到了这一点）。他们已经与 Etsy 等小型零售商达成了合作。前几天我在修理吉他时，就愿意立刻购买 AI 建议我需要的工具。但问题在于，他们在这里必须与亚马逊竞争，并且出于显而易见的原因，双方合作的可能性为零。

Voyager 1 is about to reach one light-day from Ear… #

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

Not that we would literally do this with Voyager, but it makes me wonder at the potential utility of a string of probes, one sent every couple of [insert correct time interval, decades, centuries?], to effectively create a communication relay stretching out into deep space somewhere.

My understanding with the Voyagers 1 and 2 is (a) they will run out of power before they would ever get far enough to benefit from a relay and (b) they benefited from gravity slingshots due to planetary alignments that happen only once every 175 years.

So building on the Voyager probes is a no-go. But probes sent toward Alpha Centauri that relay signals? Toward the center of the Milky Way? Toward Andromeda? Yes it would take time scales far beyond human lifetimes to build out anything useful, and even at the “closest” scales it’s a multi year round trip for information but I think Voyager, among other things, was meant to test our imaginations, our sense of possible and one thing they seem to naturally imply is the possibility of long distance probe relays.

Edit: As others rightly note, the probes would have to communicate with lasers, not with the 1970s radio engineering that powered Voyagers 1 and 2.

glenstein

我们当然不会真的用旅行者号探测器这么做，但这让我不禁思考，每隔（请填入正确的时间间隔，比如几十年、几个世纪？）发射一个探测器链，从而在深空某处建立一个有效的通信中继站，其潜在效用会是怎样的。

据我所知，旅行者1号和2号的情况是，（a）它们在飞到足以利用中继站的距离之前就会耗尽电力；（b）它们得益于行星排列产生的引力弹弓效应，而这种排列每175年才发生一次。

因此，在旅行者号探测器的基础上进行建设是行不通的。但是，向半人马座阿尔法星、银河系中心、仙女座星系发射能中继信号的探测器呢？是的，要建成任何有用的设施所需的时间尺度将远远超出人类的寿命，即便是在最近的距离上，信息的往返也需要数年时间。但我认为，旅行者号的意义之一，就是考验我们的想象力，以及对“何为可能”的认知，而它们似乎很自然地引出了长距离探测器中继网络的这种可能性。

编辑：正如其他人正确指出的那样，这些探测器必须使用激光进行通信，而不是像旅行者1号和2号那样使用1970年代的无线电工程技术。

I don’t care how well your “AI” works #

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

This is the culture that replaced hacker culture.

Somewhere along the lines of “everybody can code,” we threw out the values and aesthetics that attracted people in the first place. What began as a rejection of externally imposed values devolved into a mouthpiece of the current powers and principalities.

This is evidenced by the new set of hacker values being almost purely performative when compared against the old set. The tension between money and what you make has been boiled away completely. We lean much more heavily on where someone has worked (“ex-Google”) vs their tech chops, which (like management), have given up on trying to actually evaluate. We routinely devalue craftsmanship because it doesn’t bow down to almighty Business Impact.

We sold out the culture, which paved the way for it to be hollowed out by LLMs.

There is a way out: we need to create a culture that values craftmanship and dignifies work done by developers. We need to talk seriously and plainly about the spiritual and existential damage done by LLMs. We need to stop being complicit in propagating that noxious cloud of inevitability and nihilism that is choking our culture. We need to call out the bullshit and extended psyops (“all software jobs are going away!") that have gone on for the past 2-3 years, and mock it ruthlessly: despite hundreds of billions of dollars, it hasn’t fully delivered on its promises, and investors are starting to be a bit skeptical.

In short, it’s time to wake up.

mattgreenrocks

这就是取代了黑客文化的产物。

在我们信奉“人人皆可编程”的过程中，我们抛弃了最初吸引人们的价值观与审美。这场运动起初是对外部强加价值观的反抗，如今却沦为了当权者的传声筒。

新的一套黑客价值观与旧的一套相比，几乎只剩下表演性质。金钱与创造物之间的张力已完全消弭。我们更看重一个人曾在哪里工作（“前谷歌员工”），而非其技术实力——而后者（与管理一样）早已放弃了真正评估的尝试。我们常常贬低工匠精神，因为它不会向至高无上的“业务影响力”低头。

我们出卖了这种文化，从而为大型语言模型（LLM）掏空其内核铺平了道路。

但仍有出路：我们需要创造一种重视工匠精神、尊重开发者劳动的文化。我们需要严肃而坦率地讨论大型语言模型所造成的精神与存在性损害。我们需要停止助长那股正在扼杀我们文化的、充满必然性与虚无主义的毒雾。我们需要戳穿并无情地嘲弄过去两三年来层出不穷的胡言乱语和心理战（“所有程序员的工作都要消失了！”）：尽管投入了数千亿美元，它仍未兑现其承诺，投资者们也已开始感到怀疑。

简而言之，是时候醒醒了。

Tell HN: Happy Thanksgiving #

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

Sixteen years here, and the half-life decay of this community has been slower than anywhere else. That takes real, consistent work, and we have been lucky to have it. Through good times and rough ones, including the loss of Aaron Swartz (who I only knew of through HN), this has stayed a place for real conversation.

The grit, curiosity, and people building things have always been inspiring.

Thanks for all the discussions over the years.

Happy Thanksgiving!

jetsnoc

我在这里待了十六年，这个社区的衰变速率比任何其他地方都要慢。这需要真正持续不断的努力，我们很幸运拥有这一切。无论顺境逆境，包括在失去亚伦·斯沃茨（我仅通过HN知晓他）之后，这里始终是一个能进行真诚对话的地方。

这份坚韧、好奇心以及那些创造事物的人们，一直激励着我。

感谢这些年来所有的讨论。

感恩节快乐！