作者认为，Rivian 拒绝支持 Apple CarPlay 是一种固执且损害消费者的姿态，这正在令其流失潜在客户。在最近的一次采访中，Rivian 首席软件官 Wassym Bensaid 声称，CarPlay 倾向于“接管”车载屏幕，这与他们所追求的用户体验相冲突。 作者从多个角度反驳了这一观点。首先，CarPlay 并不需要占用整个显示屏，许多现有的车辆都能将其与原生 UI 元素成功整合。其次，即使它是全屏显示的，CarPlay 也是一项可选功能；如果 Rivian 的软件确实更出色，驾驶者自然会比苹果的界面更青睐前者。通过拒绝提供 CarPlay，Rivian 实际上是阻断了用户使用那些原生不支持、但又是必需的第三方应用程序（如播客或导航工具）的途径。 最终，作者断言 CarPlay 的支持已成为现代购车者的基本需求。尽管他们很欣赏 Rivian 的汽车，但在该公司放弃这一教条式的立场之前，他们拒绝购买。作者敦促 Rivian 将客户偏好置于公司管控之上，并表示如果添加 CarPlay 支持，他们会立刻成为 Rivian 的准客户。
每日HackerNews RSS
这篇 Hacker News 帖子讨论了人们对 Apple CarPlay 日益增长的需求。许多用户赞同作者 Casey Liss 的观点，即拒绝购买不具备该功能的车辆。苹果公司提供的数据显示，79% 的美国购车者将 CarPlay 视为“必备”要求。
虽然一些用户认为特斯拉或 Rivian 等车企的原生界面功能尚可，但大多数讨论者认为，与车企自有的软件相比，CarPlay 在导航、语音转文字和媒体集成方面表现更佳。
讨论还触及了汽车制造商与科技巨头之间的矛盾。一些参与者认为，车企刻意回避 CarPlay 是为了保护自家的软件架构，或强迫消费者进入基于订阅的生态系统。相反，也有评论者质疑苹果和谷歌的主导地位，主张政府应进行干预以强制推行开放标准，防止科技垄断企业对汽车行业施加过度控制。最终，对大多数用户而言，CarPlay 带来的便捷性远胜于车企自主设计的仪表盘所提供的优势。
请启用 JavaScript 和 Cookie 以继续。
Hacker News
最新 | 过往 | 评论 | 提问 | 展示 | 招聘 | 提交
登录
关于地方智能的权利 (righttointelligence.org)
11 分，由 thoughtpeddler 发布于 1 小时前 | 隐藏 | 过往 | 收藏 | 3 条评论 | 帮助
Catloafdev 4 分钟前 | 下一条 [-]
我没看到关于具体发生了哪些法律或行动的信息。哪里有更多信息吗？
回复
SilverElfin 0 分钟前 | 上一条 | 下一条 [-]
鉴于当前的交易型政治现状，我认为 Anthropic 和 OpenAI 很可能会贿赂……噢等等，是“游说”……以禁止开源。否则他们那虚构的万亿级估值就毫无意义了。
回复
vjulian 24 分钟前 | 上一条 [-]
总有一天，投票会变得愚蠢且无效。
回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
正在加载…
GitHub 发起了一项半开玩笑的宣传活动，允许用户申请将其公开仓库刻录在 CD-ROM 上。该活动由微软官方托管，似乎是在讽刺索尼近期宣布停止 PlayStation 游戏实体媒介支持的决定。
Hacker News 对此反应不一。一些用户欣赏其中的幽默感，认为这是对软件分发历史的怀旧致敬；但另一些用户则持怀疑态度。批评者指出，这些 CD 并非压制生产，而是通过刻录制成，寿命仅约十年左右，这使得它们作为存档工具的实用性远不及 GitHub 真正的“北极代码库”（Arctic Code Vault）项目。此外，部分用户还表达了隐私顾虑，质疑该提交表单是否是以营销噱头为掩护的数据收集手段。
总的来说，该活动被普遍解读为微软的一次巧妙、限时的“钓鱼”行动，旨在嘲讽竞争对手向全数字生态系统的转型。
您没有提供需要翻译的内容。请将您想要翻译的文本粘贴在这里，我会为您将其翻译为通顺的中文。
高盛最近的一份报告援引了麻省理工学院经济学家达龙·阿西莫格鲁（Daron Acemoglu）和尼尔·汤普森（Neil Thompson）的观点，探讨了“人工智能引发就业末日”的可能性。尽管有人担心本世纪末之前会出现大规模失业，但专家们认为这种灾难不太可能发生，尽管他们对转型性质的看法各不相同。
高盛的约瑟夫·布里格斯（Joseph Briggs）预计会出现暂时性的岗位流失，随后会创造出新的角色；而尼尔·汤普森则认为人工智能更像是一种渐进的“涨潮”，而非破坏性的巨浪。相反，达龙·阿西莫格鲁警告称，如果人工智能投资继续优先考虑取代工人而非增强能力，将可能对劳动力市场产生长期的负面影响。
报告强调，人工智能对企业劳动力和收益的最终影响仍存在高度不确定性。这种不确定性也反映在网络讨论中，怀疑论者指出，智能自动化在本质上不同于以往的工业变革。批评人士认为，人工智能推动就业创造的支持者未能具体说明这些新角色将是什么样子，或者为什么人工智能最终不会也将这些职位自动化。归根结底，这场辩论的关键在于人工智能是作为辅助人类工人的工具，还是作为使其过时的力量。
**deptrust** 是一款本地命令行工具（CLI）和 MCP 服务器，旨在防止 AI 智能体（Agent）使用存在漏洞或过期的软件包版本。它支持多种生态系统，包括 npm、PyPI、Cargo、Go modules、RubyGems、NuGet、Maven 和 GitHub Actions。 deptrust 无需托管服务，直接查询公共注册表和漏洞数据库（OSV 及 GitHub Advisory Database）。它通过分析软件包，根据已知的 CVE 和风险信号（如近期发布的版本），提供明确的建议——**拦截、审查或允许**。 主要功能包括： * **安全检查：** 根据已知的安全公告核实软件包版本。 * **智能推荐：** 当所选版本存在漏洞时，建议使用最安全、最新的版本。 * **智能体集成：** 作为 MCP 服务器或 Codex 技能运行，允许 AI 智能体在安装或更新建议前自动验证依赖项。 * **风险可视化：** 提供风险评分和分类，帮助用户和智能体做出明智决策。 * **多功能性：** 提供人类可读的 CLI 输出格式以及适合自动化智能体工作流的精简 JSON 格式。 通过执行这些检查，deptrust 可以防止意外采用受损或不安全的软件依赖，从而确保 AI 驱动的开发过程安全可靠。
抱歉。
尽管 Sinclair 和 Acorn 在英国计算机历史上占据主导地位，但 Apricot Computers 依然是一个引人入胜且常被忽视的案例。1990 年 BBC 的《麻烦解决者》（*Trouble Shooter*）节目曾深入报道过该公司，约翰·哈维-琼斯爵士（Sir John Harvey-Jones）在节目中罕见地剖析了该公司的内部困境。
到 1989 年，Apricot 曾是行业先驱，它因率先向市场推出基于 486 处理器的个人电脑而闻名，并坚持在英国本土进行设计与制造。然而，该公司面临着严峻挑战：高昂的运营成本、横跨 AT 和微通道（Microchannel）架构的臃肿产品线，以及来自亚洲低成本制造带来的巨大压力。
哈维-琼斯指出，Apricot 的硬件部门入不敷出，而其软件和维护业务才具有真正价值。由于无法与全球行业巨头竞争，该公司最终被迫转型。1990 年，Apricot 将其硬件业务出售给三菱。剩余实体 ACT 后来与一家大型软件公司合并。归根结底，Apricot 的故事反映了在 80 年代末维持独立本土个人电脑制造的艰巨挑战，它在市场迅速大宗商品化的过程中，留下了一个雄心勃勃却难以为继的创新者遗产。
Hacker News
最新 | 过往 | 评论 | 提问 | 展示 | 招聘 | 提交
登录
Apricot Computers：一个被低估的英国品牌 (dfarq.homeip.net)
giuliomagnifico 发布于 2 小时前，15 点 | 隐藏 | 过往 | 收藏 | 5 条评论
帮助
jnaina 20 分钟前 | 下一条 [-]
过去曾销售过 Apricot 电脑。Apricot 和 Grid 的个人电脑在设计上非常出众，与当时其他那些丑陋的米色机箱形成了鲜明对比。
回复
le-mark 6 分钟前 | 父评论 | 下一条 [-]
它们当时真的买得到吗？感觉这些电脑和其他机型的供应总是断断续续的。
回复
jaggs 1 小时前 | 上一条 | 下一条 [-]
并没有。它们其实很烂。:)
回复
nonamesleft 1 小时前 | 上一条 | [还有 2 条]
呃，那个页面只返回给我 activitystream 的 json 数据？
回复
nonamesleft 1 小时前 | 父评论 [-]
看来它自己恢复了。
回复
准则 | 常见问题 | 列表 | API | 安全 | 法律 | 申请加入 YC | 联系
搜索：
**ctx** 是一款基于 Rust 开发的开源命令行工具，旨在通过检索过往会话内容，帮助编程智能体（Coding Agents）找回“记忆”。智能体在执行任务时往往倾向于从零开始，这导致它们经常重复之前的错误或忽略既定的决策。**ctx** 通过将本地的智能体记录（包括讨论内容、失败尝试和执行指令）索引到私有、高性能的 SQLite 数据库中，有效解决了这一问题。
**主要功能包括：**
* **高效性：** 通过将数据结构化为会话、事件和元数据，实现了精准检索，其 Token 利用效率比直接搜索原始记录高出 50 倍。
* **隐私性：** 所有索引和搜索操作均在本地完成。数据不会上传至云端，也无需任何 API 密钥。
* **无缝集成：** 支持 Cursor、Claude Code 和 Codex 等主流智能体平台。它允许智能体通过自然语言搜索历史记录，从而查找特定的决策、被否决的方案或针对文件的更改。
* **开发者友好：** 该工具提供强大的命令行界面，用于检查已索引的会话、通过 SQL 进行查询，并通过 SDK 集成到各种编程环境中。
通过使用 **ctx**，开发者可以确保智能体能够基于过往工作持续进步，而非重复劳动，从而显著提高生产力和上下文保持能力。
**ctx** 是一款基于 Rust 的新型命令行工具，旨在通过将现有的本地智能体（agent）会话记录和日志编入结构化的 SQLite 数据库，为编程智能体提供“长期记忆”。
与依赖复杂的图数据库或托管式记忆服务不同，*ctx* 使智能体能够对其过往会话进行排名文本搜索。这让智能体在开启新任务前可以调研以往的工作，从而识别常见问题（例如已知的磁盘空间错误）并沿用已验证的解决方案。
该项目强调本地隐私与实用性，允许开发人员生成整洁的会话记录以共享给团队成员，或通过递归分析识别软件开发生命周期中的瓶颈。开发者认为，随着智能体使用率的增长，业界需要一套标准化的日志和记录格式，以确保不同工具间的互操作性，从而避免形成彼此孤立的“记忆孤岛”。
一款特别的无无线功能尼康相机首次公开发售 A Special Wireless-Free Nikon Camera Is Publicly Available for the First Time
5 小时前
尼康悄然推出了一款特殊的 Z6 III 相机版本，该版本去除了所有无线连接功能，包括 Wi-Fi 和蓝牙。虽然标准版 Z6 III 是一款高性能机型，但这款“无无线”版本专为有严格安全要求的政府及工业环境而设计。
尽管相机的功能减少，价格却反而更高——其售价为 3,079.95 美元，而标准版为 2,696.95 美元。尼康对此解释称，高成本源于小批量的专业化制造。为了移除特定的硬件和软件组件而对装配线进行定制，比标准的大规模生产需要投入更多资源。
此前，这些专业相机仅通过企业直接渠道销售。尼康目前正通过 B&H 等合作伙伴测试零售渠道，以评估那些仅需有线数据传输的高端专业用户的需求。对于普通摄影师而言，该机型并无必要，但对于在禁止无线信号的高安全环境下工作的用户来说，它是一项至关重要且易于获取的工具。
尼康发布了一款特殊的“无无线连接”版 Z6 III 相机，该版本移除了所有的 Wi-Fi 和蓝牙功能。这款小众产品专为禁止无线传输的高安全性环境而设计。
Hacker News 上的讨论强调了有关该机型的几个要点：
* **目的：** 它旨在满足在禁止使用标准相机的安全设施中工作的专业人士的需求。
* **技术设计：** 用户推测该机型的无线硬件是否从子板上被移除，以及固件是否经过修改以避免软件报错。
* **批评：** 评论者指出，“精简版”机型定价反而更高存在讽刺意味，同时失去 GPS 等功能也可能带来不便，因为 GPS 从理论上讲可以作为仅接收信号的技术而无需传输数据。
* **易用性：** 一些用户表示，鉴于“SnapBridge”应用程序以往的表现，失去该连接功能并不会造成太大影响。
总之，尽管该机型满足了特定的安全需求，但其高昂的价格和有限的功能让一些观察者对其面向普通消费者的价值主张存疑。
Rhombus 是一门作为 Racket 项目一部分开发的新编程语言，旨在弥合 Lisp 强大的元编程能力与更易于上手的类 Python 语法之间的鸿沟。通过利用成熟的 Racket 运行时，Rhombus 能够使用已有的生态系统、优化编译器以及高效的数据结构，同时避免了常令潜在用户望而却步的“括号堆砌”风格。 Rhombus 的核心在于其对“面向语言编程”的深度投入。它具备先进的宏系统，允许开发者扩展语言的语法、类型系统和循环结构。这些宏默认是卫生（hygienic）的，并带有丰富的元数据，从而确保了实用的错误提示以及与开发工具的无缝集成。 虽然 Rhombus 提供的性能水平更接近 JavaScript 或 Ruby，而非 Rust 这类系统级语言，但其真正的价值在于其可扩展性。它允许开发者创建特定领域的微型语言来解决复杂问题，而无需从零构建传统编译器。随着 1.0 版本的发布，Rhombus 旨在成为专业人士的实用工具，满足他们在需要深度语言定制的同时，也能享有现代、易读的语法以及详尽的学术级文档的需求。
Hacker News
最新 | 过往 | 评论 | 提问 | 展示 | 招聘 | 提交
登录
使用 Rhombus 进行灵活的元编程 (lwn.net)
16 点，由 spdegabrielle 发布于 1 小时前 | 隐藏 | 过往 | 收藏 | 1 条评论
帮助
dang 34 分钟前 [–]
相关内容。还有其他吗？
Rhombus 语言 1.0 - https://news.ycombinator.com/item?id=48633473 - 2026年6月 (113 条评论)
2026年夏季 Rhombus 图片竞赛 - https://news.ycombinator.com/item?id=48546270 - 2026年6月 (3 条评论)
Rhombus 语言 - https://news.ycombinator.com/item?id=43394881 - 2025年3月 (158 条评论)
Rhombus：宏的新尝试 (2023) - https://news.ycombinator.com/item?id=42041070 - 2024年11月 (1 条评论)
Rhombus：基于 Racket 构建的具有传统语法且支持宏扩展的语言 - https://news.ycombinator.com/item?id=41151439 - 2024年8月 (97 条评论)
Rhombus（编程语言）现状 - https://news.ycombinator.com/item?id=30314109 - 2022年2月 (17 条评论)
回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 加入 YC | 联系
搜索：
为了实现 FoundationDB 宏大的性能和可扩展性目标，团队开发了 **Flow**，这是一种针对 C++11 的领域特定扩展。Flow 引入了基于 Actor（角色）的并发机制，旨在结合 Erlang 等高级语言的开发效率与原生 C++ 的原始速度及 I/O 效率。 Flow 的功能类似于预处理器/编译器，它将异步的“actor”函数转换为 C++11 类，并通过回调机制来防止阻塞。其关键原语包括： * **Promises/Futures（承诺/未来）：** 促进异步数据交换，甚至可以跨网络进行。 * **wait()：** 暂停当前 actor，同时允许其他并发任务继续执行。 * **ACTOR：** 定义异步工作单元的标签。 * **state：** 管理跨多个异步等待点的变量作用域。 * **Streams（流）：** 实现多路复用和可靠的消息传递。 除了性能之外，Flow 还是 FoundationDB 测试策略的核心，能够对大规模、易出错的集群进行确定性仿真。虽然 Flow 代码在变量作用域和 IDE 集成方面需要格外注意（需使用特定宏以保持与 C++ 编辑器的兼容性），但它使开发人员能够以远少于传统 C++ 方法的样板代码和复杂性来实现复杂的异步协调逻辑。
Hacker News
最新 | 过往 | 评论 | 提问 | 展示 | 招聘 | 提交
登录
FoundationDB 的 Flow——为 C++11 引入基于 Actor 的并发机制 (apple.github.io)
23 点，由 sourdecor 发布于 2 小时前 | 隐藏 | 过往 | 收藏 | 3 条评论 | 帮助
pjmlp 1 小时前 | 下一条 [–]
这看起来有点过时了，尤其是考虑到我们目前最新的批准标准是 C++23，而且自 C++20 起，协程（co-routines）会是更好的方案。另外，之前提到的用 Swift 重写的进展如何？
回复
jen20 1 小时前 | 上一条 [–]
之前的讨论：https://news.ycombinator.com/item?id=46191763
回复
dang 37 分钟前 | 父评论 [–]
谢谢！宏观扩展：Flow：用于 C++ 的 Actor 语言，由 FoundationDB 使用 - https://news.ycombinator.com/item?id=46191763 - 2025 年 12 月（53 条评论）
回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：