慕尼黑地方法院对谷歌下达了一项临时禁令，裁定该公司对其人工智能搜索摘要所生成的虚假诽谤性内容承担直接责任。 法院驳回了谷歌关于其仅作为中立搜索引擎的辩护，认定人工智能摘要是由谷歌算法生成的“独立、全新且实质性的陈述”，而非仅仅是指向第三方内容的索引。由于谷歌控制着人工智能的结构与内容，法院将其定性为内容提供商而非中介机构，从而剥夺了其作为搜索引擎通常享有的责任豁免权。 此外，法院还驳回了谷歌关于“用户应自行核实人工智能声明”的主张，指出该功能呈现时具有权威性，且往往缺乏可追溯的来源。裁决强调，由于该人工智能在原始资料并不存在的情况下虚构了企业与欺诈活动之间的联系，受害者别无其他法律救济途径。这一裁决开创了重要先例：如果该裁决维持原判，将标志着人工智能提供商——而不仅仅是它们抓取数据的来源方——必须对其模型合成内容的准确性和合法性承担法律责任，这可能会对全球各大人工智能开发者产生深远影响。
每日HackerNews RSS
德国裁定谷歌需对 AI 概览中的错误回答承担责任 German ruling declares Google liable for false answers in AI Overviews
2 天前
德国法院近期裁定，Google 需为其 AI 概览（AI Overviews）所生成的诽谤性言论承担责任。不同于主要呈现第三方内容且历来享有法律保护的传统搜索结果，法院认定由 AI 生成的摘要属于 Google 创作并发布的“原创内容”。由于这些摘要常将信息合成新的叙事——有时会捏造关联或虚构源材料中不存在的事实——法院结论认为，Google 承担相应的编辑责任。
Hacker News 社区对此裁决意见分歧严重。许多用户认为，如果 Google 选择为了自身利益“重写”网络内容，就必须承担其输出结果带来的法律后果，尤其是当这些输出损害他人声誉时。然而，该裁决的批评者担心，对非确定性的 AI 模型施加严格责任会扼杀创新，导致 AI 服务撤出欧洲，甚至实际上禁绝此类技术。多位评论者指出，这一裁决凸显了大型语言模型（LLM）的“幻觉”问题，即该工具的核心功能——生成概率性文本——与法律对事实准确性的要求存在根本性冲突。
确实，莱尼格尔接受该提议后，仅雇佣了少数几名员工。其中包括几位动画师、一位负责记录拍摄帧数的助理，以及负责操控摄影机的莱尼格尔的丈夫。除了担任导演，莱尼格尔还亲自制作剪影木偶，用硬纸板和铅片裁剪出角色，并用金属丝铰链固定它们的关节。她还构思了电影的剧本，将多个中东童话故事融合成一个完整的故事——《阿赫迈德王子历险记》。
Container machine 为 macOS 提供了一个轻量级、持久且高度集成的 Linux 环境。它基于标准的 OCI 镜像构建，允许开发者运行完整的 Linux 发行版（如 Ubuntu、Debian 或 Alpine），并与宿主机实现无缝集成。 主要功能包括： * **统一的工作流程：** 您的 macOS 主目录和配置文件会自动挂载到容器中，使您能够使用原生 macOS 工具编写代码，同时在 Linux 环境中进行构建和测试。 * **系统级能力：** 与标准容器不同，这些机器运行 `init` 系统（如 `systemd`），使您能够管理长期运行的后台服务，并在模拟生产的环境中测试应用程序。 * **简便的管理：** 通过直观的命令行工具，您可以管理多个特定发行版的机器、调整资源（CPU/内存），并可在不同 Shell 之间即时切换。 * **无需复制步骤：** 由于容器机器与宿主机共享文件系统，Mac 上的分析器和调试器等工具可以直接与 Linux 产物进行交互，无需在不同环境间移动文件。 无论您是需要跨不同发行版进行测试，还是需要一个持久的 Linux 工作空间，Container machine 都能提供快速、集成且灵活的开发体验。
那是死亡。 It's death
2 天前
一个平凡的清晨迅速演变成荒诞的闹剧：一系列灾难性的意外——因为炉灶断了一只手、盯着太阳把自己弄瞎、在挑选网飞剧集时意外虚度了十年——最终导致他经济破产，并被压垮的信件意外砸死。 主角发现自己置身于一片无限的虚无黑夜中，遇见了一位披着斗篷的身影，对方是来往生之路的冷漠引路人。面对自己一生虚度这一沉重的事实，叙述者问道自己是否活错了人生。那个身影给了他片刻的宽慰，建议他原谅自己，因为人生本就是在信息不全的情况下度过的。那身影离去后，留下他独自徘徊在凄凉空旷的虚无中，叙述者开始向虚空深处走去，独自沉思这段经历的荒诞与悔恨的沉重。
抱歉。
**Nucleus** 是一款为高性能 AI 智能体和生产服务设计的 Linux 安全增强型声明式容器运行时。与 Docker 不同，Nucleus 摒弃了守护进程、镜像仓库和 OCI 镜像管理的开销，转而采用“Nix 原生”方案。
### 核心功能
* **完全声明式**：服务使用 NixOS 模块和 TOML 进行定义，确保部署过程可复现、可审计且具备版本控制。
* **零开销隔离**：利用 Linux 内核原语（cgroups v2、命名空间、Landlock、seccomp）实现近乎裸机的性能（例如 12 毫秒的启动时间）。
* **强化安全**：特性包括不可逆的策略执行（seccomp、Landlock）、出口流量过滤、可选的 gVisor 集成（以实现更强的沙箱保护）以及根文件系统认证。
* **三种运行模式**：
* **智能体模式 (Agent Mode)**：用于 AI 工作负载的瞬态、快速启动沙箱。
* **严格智能体模式 (Strict Agent Mode)**：针对不可信瞬态任务的故障安全隔离。
* **生产模式 (Production Mode)**：具备健康检查和 systemd 集成的声明式长驻服务。
* **Nix 集成**：利用 Nix 闭包（closures）替代可变的宿主机绑定挂载，从而创建最小化、锁定化的服务环境。
对于相比标准 OCI 镜像仓库的便捷性，更看重深度隔离、可复现性和可审计性的运维人员而言，Nucleus 是理想的选择。
这篇文章探讨了“Molly Guard”（防误触保护装置）在硬件和软件中的演变。
作者列举了多种实例，从工业级 IBM 打字机上的物理屏障，到 SD 卡槽旁用于警示用户避免过早弹出的指示灯等巧妙设计。一些机械结构（如软驱杠杆）通过直观的锁定方式防止操作失误。
在软件方面，作者审视了现代用户界面。虽然有些保护机制能有效防止数据丢失（例如 macOS Finder 在大量打开文件时的确认提示），但另一些则差强人意。作者批评了谷歌 Chrome 的“按住以退出”功能，认为其视觉设计糟糕且缺乏反馈，并将其与早期 iTunes 中直观且具拟物化风格的“刻录光盘”保护机制进行了对比。
文章最后追溯了该术语的起源，展示了“Molly”（激发这一概念的工程师之女）与其父亲的历史合影。文章总结道，防误触设计的初衷是防止错误，而成功的实现依赖于直观的逻辑，而非仅仅依靠令人沮丧的设计。
在最近于维尔纽斯举办的一次黑客马拉松中，我和队友将一台旧式转盘电话改造成了一位人工智能音乐管家。通过将树莓派接入电话硬件，我们集成了 ElevenLabs 和 Spotify API，让用户可以通过带有约克郡口音的对话式人工智能来点播各类小众音乐播放列表。值得一提的是，我们整个项目没有编写一行代码，而是利用人工智能驱动的工具专注于系统架构而非语法。 这次经历凸显了黑客马拉松的一个转变：随着软件开发变得日益“已解决”且自动化，真正的挑战在于物理硬件的集成。我相信黑客马拉松的未来在于复古技术的复兴——将废弃设备改造为荒诞、复杂且“道德上令人困惑”的机器。 现代黑客马拉松应摆脱平庸、以风投为导向的网页应用，转而投向那些突破界限的物理“电线方尖碑”。无论是情感收银机还是支持社交媒体的传真机，目标都应是通过人工智能与怀旧硬件的融合，创造出荒谬、过度设计的项目，从而挑战我们对现实的认知。
最近 Hacker News 上的一篇讨论“软件黑客松已死，硬件黑客松万岁”的文章，凸显了人们对现代黑客松活动的日益失望。参与者认为，软件类活动已经演变成了“推介比赛”，其中华丽的展示、模拟数据和人工智能生成的“垃圾内容”被置于真正的技术问题解决之上。
许多用户感叹，黑客松最初的协作与实验精神已被企业挪用，沦为潜在客户挖掘或免费劳动力的工具。随着人工智能降低了软件项目的准入门槛，批评者认为，黑客松核心的“黑客”精神——即克服技术局限的努力——正在消失。
作为回应，许多人转向了硬件黑客松，因为现实世界的约束（如焊接、物理传感器、3D 打印）使得单纯依靠人工智能或幻灯片来伪造功能变得极其困难。虽然一些用户认为人工智能最终会掌握硬件，但另一些人则认为，硬件项目本身保留了软件活动所丧失的“人在回路”的必要性。归根结底，大众共识认为，黑客松的价值应在于在有限时间内构建出实用功能带来的个人挑战，而非对“金牌”的竞争性追求。
**摘要**
所提供的文本包含一家本地新闻媒体（WSOC-TV）的综合网站导航菜单，涵盖新闻、体育、天气和社区活动等类别。然而，该网站对用户不可访问。“451 法律原因无法访问”的错误信息显示，该网站仅限位于美国境内的用户访问。因此，国际访客无法查看其内容。
最近一起涉及人工智能人脸识别技术的错误逮捕案件在 Hacker News 上引发了激烈讨论。一名叫贾利勒·理查森（Jalil Richardson）的男子因佛罗里达州的一起犯罪被监禁了数月，尽管他持有明确的不在场证明——包括证明他当时身处 400 英里之外的考勤记录，且他从未去过该州。
评论者强调，这一事件凸显了人工智能不准确性之外的系统性失败。虽然人工智能提供了最初的调查线索，但后续流程依赖于有缺陷的警方排队辨认，以及受害者所称的种族定性。参与讨论者认为，执法部门往往将人脸识别视为绝对正确，但它并不具备构成“相当理由”（probable cause）所需的可靠性。
更广泛的讨论反映出人们对司法系统因程序疏忽而摧毁他人生活感到深深的沮丧。批评人士指出，检察官和警察部门受到豁免权的保护，这使得受害者在因这类错误失去家园、工作和家庭后，几乎无法寻求正义或赔偿。舆论共识是，当技术与存在偏见且行动迟缓的体制惯例相结合时，其结果就是不公正现象的危险放大。
### 摘要：关于电子邮件验证的真相
电子邮件地址验证常常导致不必要的复杂性和技术债务。尽管人们普遍认为开发者应使用复杂的正则表达式来“清理”用户输入，但作者认为这是一种反模式，往往会疏远用户，并且会在不断演变的规范面前失效。
主要结论：
* **不要过度验证：** 电子邮件规范（RFC）深受历史影响，其宽容程度远超大多数开发者的想象。许多被认为是“无效”的地址（如带有加号标签、非 ASCII 字符或非常规域名结构的地址）实际上是有效的。
* **优先考虑用户体验（UX）：** 不要使用限制性的正则表达式，而应使用简单的检查来防止明显的拼写错误。你的目标应该是协助用户，而不是限制他们。
* **验证，而非校验：** 真正“验证”电子邮件的唯一方法是发送一封邮件。依靠验证码或链接，而不是执行耗费资源的服务器端检查或 MX 记录查询。
* **谨慎处理身份信息：** 存储电子邮件时，应避免使用破坏性的大小写归一化（如 `UPPER()`），因为这可能会导致国际字符出错。应使用数据库原生解决方案（如 `citext`）或适当的排序规则来妥善处理不区分大小写的匹配。
**总结：** 保持简单。停止试图将电子邮件地址强行塞入僵化且过时的框架中。
这次讨论强调了开发人员在处理电子邮件地址时常见的技术陷阱和误区。
许多开发人员过度设计验证方式，使用复杂的正则表达式，却往往无意中拒绝了有效但不常见的电子邮件格式（例如带有多个句点或非常规顶级域名的地址）。贡献者们认为，严格的验证适得其反；最有效的方法是进行最基础的检查（例如验证是否包含“@”符号），并依靠发送验证邮件来确认有效性。
辩论的很大一部分集中在开发人员对电子邮件的“自欺欺人”上：
* **电子邮件是人性化的**：与严格的数字协议不同，邮件投递在历史上具有很强的韧性，但现代网络表单往往缺乏这种灵活性。
* **验证就足够了**：虽然邮件确认是行业标准，但批评者指出，不做任何预先验证可能会因为过高的退信率而导致公司被主要服务商列入黑名单，从而损害声誉。
* **用户了解电子邮件**：许多用户记不住自己的地址，且一些服务商（如 Gmail）会忽略句点，这导致了普遍的困惑。
最终，各方一致认为，开发人员应停止设置过高的门槛，优先考虑以用户为中心的验证流程，以避免将合法用户拒之门外。