数字通信是基础设施的基石，但我们却将其视为一系列专有的“围墙花园”。虽然隐私倡导者通常偏爱 Signal 或 Element 等工具，但这些平台缺乏真正的互操作性，使用户容易陷入对单一供应商的依赖。仅靠开源代码是不够的，数字主权需要真正的**开放标准**。 作者认为，我们必须重现早期互联网的韧性，那时不同的硬件和服务可以通过标准化协议实现互通。尽管 Matrix 等一些现代项目声称能提供这种功能，但它们往往表现为单一供应商平台，控制权依然高度集中。 相比之下，**可扩展消息与出席协议（XMPP）**提供了一个经过 25 年验证的去中心化通信框架。该协议由 XMPP 标准基金会管理，运作方式如同一个真正的标准组织，需要达成共识并支持多种独立实现。通过强制推行开放标准而非采购专有软件，社会可以确保数字工具像道路和电网等实体基础设施一样，具备可替换性和韧性。XMPP 证明了通往主权独立数字未来的道路，或许不在于重新发明轮子，而在于拥抱既定且可互操作的基础。
每日HackerNews RSS
这篇 Hacker News 的讨论回顾了 XMPP（Jabber）25 年的发展历程，重点探讨了它作为一种稳健的去中心化协议的地位，以及在当今用户采用率和实现碎片化方面所面临的困境。
支持者赞扬 XMPP 带来的数字独立性，并指出它在军事指挥、物联网和个人代理编排等专业领域仍有持续应用。他们认为，作为一个成熟的开放标准，XMPP 避免了与 Matrix 或 Telegram 等中心化替代方案相关的“厂商锁定”风险。用户强调，像 Prosody 或 Snikket 这样的现代服务器已经很大程度上解决了早期的配置难题。
然而，批评者指出了糟糕的用户体验，认为不同客户端对 XEP（扩展协议）的支持不一致，导致了加密（OMEMO）、文件共享和通知等方面的问题。许多人认为，“一切皆扩展”的模式导致了碎片化，使得用户难以像使用 Telegram 或 Slack 那样稳定地获得基础功能。
虽然 Matrix 常被视为更“现代”的竞争对手，并优先考虑持久化历史记录和社区功能，但 XMPP 的倡导者认为，对于那些真正重视去中心化和轻量化运行的用户来说，其核心的简洁性仍然是一项优势。
一位安全研究员在 Beam Living 的公寓租赁门户网站中发现了一个严重的漏洞，该门户网站被纽约市多个大型住宅区所使用。通过利用 GraphQL API 的缺陷，任何拥有申请人电子邮箱地址的人都可以获取其敏感个人信息，包括部分社会安全号码、出生日期、家庭住址、电话号码和信用评分。
研究员发现，该平台的 API 仅凭电子邮件地址即可获取敏感的用户数据，而无需进行会话身份验证。这一漏洞可能导致所有曾向 Beam Living 旗下房产提交过申请的人员的隐私记录面临泄露风险。
此次漏洞的披露过程存在明显问题。尽管研究员在数周内多次尝试联系该公司，但并未收到任何来自正式安全团队的回复。在通过租赁中介和运营人员升级反馈后，该漏洞最终被静默修复。虽然问题现已解决，但研究员强调，该公司在处理此次严重数据安全事件时，存在沟通不畅和缺乏透明披露流程的重大失误。
对不起。
从 Firefox 157 版本开始，JPEG XL 解码功能将在所有平台上默认开启。该功能由基于 Rust 的 `jxl-rs` 库提供支持，此前一直处于 `image.jxl.enabled` 配置项的开发阶段。 原型设计阶段最初引发的性能担忧已通过集成多线程解码得到解决，基准测试显示其性能与 Safari 的实现方案具有竞争力。虽然 JXL 在处理较小文件时的性能略逊于其他图像格式，但它与 Blink 的实现保持了功能对等，支持动画和渐进式显示。尽管 HDR 图像目前会以 SDR 格式渲染，但该实现提供的色调映射效果优于其他格式。 目前已进行了全面的测试，包括用于验证正确性的 WPT 测试，以及针对分块解码、动画和损坏处理的 Gecko 特定测试。此外，解码器还经过了严格的安全模糊测试。此次发布符合 ISO/IEC 18181 标准，并建立在既有的中立标准立场和“有保留地满意”的 TAG 审查基础之上。
抱歉。
推理工程是一个快速发展的领域，专注于通过降低延迟和成本来优化生产环境中的大语言模型（LLM）。从业者通过 GPU 内核调优、量化、KV 缓存管理和分布式服务等技术实现这一目标。 **InferQuest** 是一个免费、全面且开源的平台，旨在帮助用户掌握这些技能。课程分为两条主要路径： 1. **推理工程：** 涵盖 Transformer 内部机制、CUDA/Triton 内核编写以及引擎管理（例如 vLLM）。 2. **模型训练：** 教授构建大语言模型的全生命周期，从预训练、数据整理到 SFT（监督微调）、LoRA 以及基于 RL（强化学习）的后训练。 InferQuest 不发放传统的证书，而是采用一套严格的、基于里程碑的验证系统。进度通过实时端点探测、自动化 GPU 评分提交以及向开源仓库贡献代码来进行跟踪，从而为工程师提供招聘方所看重的实实在在的作品集。 该学习路线内容详尽，对于有经验的软件工程师而言，大约需要 6 到 12 个月的业余时间完成。虽然大多数任务可以在云端笔记本中运行，但针对特定的 GPU 内核工程模块，需要现代 NVIDIA 硬件支持。
抱歉。
长期以来，荷兰一直依赖大规模的疏浚工程来维护其重要的水道基础设施，而这项任务目前正消耗着大量的化石燃料。然而从历史上看，荷兰人曾通过智慧和体力劳动来应对不断的泥沙淤积。
在现代吸泥船（每分钟可清除100立方米淤泥）出现之前，疏浚工作是由成千上万的劳工使用手持式“疏浚袋”完成的。随着需求增长，技术不断演进，出现了利用链斗挖掘深水区的人力及畜力“疏浚磨”。荷兰人还利用自然力量，使用“刮泥器”（通过水流、风力或马匹牵引的耙子）来松动沉积物。在弗里斯兰等地区，设计者选择进行结构适应，建造了被称为 *skûtsjes* 的浅吃水船，以尽量减少对加深运河的需求。
随着疏浚行业面临燃料密集型维护所带来的环境挑战，这些前工业时代的方法提供了一个引人深思的历史视角。“人力发电厂”项目甚至探讨了回归人工方法的可能性，并提出了一个问题：现代社会能否在不完全依赖化石燃料机械的情况下，可持续地维护重要基础设施。
抱歉。
本报告概述了 Emmanuel Nyarko 的 2026 年 Google Summer of Code 项目，该项目旨在增强 NetBSD 的 RAIDframe 磁盘管理模块。通过实现两项主要功能，该项目解决了现有 RAID 配置中的关键局限： 1. **N-way RAID 1**：此扩展改进了传统的 RAID 1（镜像），允许在单个阵列中使用超过两块磁盘。通过使用一块主磁盘和多块辅助磁盘，用户可以显著提高数据冗余性和针对驱动器故障的保护能力。其实现包括物理磁盘地址的动态映射以及更新后的有向无环图（DAG）执行，以处理多个奇偶校验磁盘。 2. **RAID 清洗（RAID Scrubbing）**：此功能引入了一种健康检查机制，可扫描任何 RAID 级别下的磁盘扇区以发现读取故障。用户可通过 `raidctl` 发起完整或部分清洗，以识别并报告潜在的数据完整性问题。 这些改进通过包括重建和热备用模拟在内的大量测试得到了验证。这项工作增强了 NetBSD 的存储可靠性，并为未来改进奠定了基础，例如用更稳健的 N-way RAID 1 框架取代现有的 RAID 1 实现。
这篇 Hacker News 讨论聚焦于 NetBSD 2026 年谷歌编程之夏（GSoC）的一个旨在改进 RAIDframe 的项目。
评论者指出，RAIDframe 目前缺乏对 RAID-6 的支持，随着硬盘容量的增加以及重建过程中 UER/BER（不可恢复错误/位错误）风险的上升，这一点变得愈发重要。一些人建议，由于 NetBSD 现在支持 ZFS，RAIDframe 可能更适合用于启动或根分区等特定场景，而非高容量存储阵列。
讨论也转向了 NetBSD 在生态系统中的独特地位。用户称赞该项目始终支持广泛的传统和利基架构（例如 Dreamcast 和 Sharp x68000），而这些架构早已被其他主流内核所放弃。参与者总结认为，尽管 Linux 和 FreeBSD 专注于追求性能和现代特性，但 NetBSD 通过为旧硬件和稀有硬件提供稳定、可靠且现代的操作系统，发挥着极其宝贵的价值。
许多 USB-C 设备无法充电或连接，是因为设计者遗漏了 C-to-C 通信所必需的两个 5.1K CC 电阻。为了解决这一问题，Adafruit 开发了这款 **USB Type-C CC 电阻修复器**。 这个小型 PCB 组件像一座桥梁，为设计不佳的端口或线缆补充了缺失的电阻及一个“电源正常”指示灯。它能够透传电源和数据线路，从而强制连接生效。请注意，由于缺乏边带和高速引脚连接，它不支持高速数据传输或特殊协议。它仅用于标准的 USB 充电和同步任务，适用于设备无法正常协商电源的情况。
抱歉。
正在检查您的浏览器……需要启用 JavaScript
抱歉。
为了应对 HBM 日益增长的功耗和面积限制，三星正将其基础裸片（base die）从 DRAM 工艺转向 4nm 逻辑工艺。这一转变提供了更高的设计密度，使三星能够探索三个阶段的创新，旨在将 HBM 从一种“笨拙”的存储组件转变为更智能、耦合更紧密的子系统。 **第一阶段**专注于将内存控制器集成到基础裸片上，以减少 PHY 面积和能耗。这将允许使用能与 CPU 网格（mesh）直接通信的定制协议，尽管这需要全行业的深度集成。该阶段还包括增加基于 SRAM 的重映射功能，通过更灵活地修复整个堆栈中的缺陷单元来提高良率。 **第二阶段**利用基础裸片剩余的面积进行高级遥测、自检、通过外部 IO 实现内存扩展，以及用于数据预处理的“内存内”计算。 **第三阶段**探索“zHBM”，即直接将 HBM 堆叠在计算芯片上。虽然这可以通过用 3D TSV 取代 2D 接口来显著提高带宽和效率，但它面临着巨大的散热挑战。归根结底，尽管这些创新面临标准化难题，但它们代表了向更集成、高性能内存架构发展的战略性转变。
抱歉。
本文认为，过度依赖人工智能编程助手会产生一种危险的“熟练协调者悖论”：这些工具虽然要求使用者具备专业知识才能有效发挥作用，但同时又规避了构建这种专业知识所必需的摩擦和试错过程。 包括 JetBrains 和宾夕法尼亚大学在内的多项近期研究表明，过度依赖 AI 的新手往往会产生一种“能力错觉”，他们跳过了关键的规划阶段，也无法掌握底层的运作机制。他们变得依赖这些工具来修复工具自身引入的错误。相比之下，那些将 AI 作为苏格拉底式导师——优先考虑认知投入而非代码生成的人——能够获得显著更好的学习成果。 作者警告称，编程不仅仅是生成代码行，更是通过解决问题来培养“品味”和直觉的过程。开发者如果选择即时答案而非攻克复杂的挑战，往往会累积“认知债务”而非掌握技能。通往长期成功的道路在于将 AI 作为教学辅助工具而非拐杖，确保开发者保持必要的批判性思维能力，去审计、验证和理解他们所构建的系统，而不是离开订阅服务后便束手无策。
以下内容摘自 Hacker News 上关于人工智能对软件工程影响的激烈辩论。讨论的核心在于：过度依赖 AI 是会导致编程专业知识的终结，还是仅仅代表了该行业的一次必要演进。
**核心观点：**
* **能力退化论：** 批评者认为，“情绪化编程”（vibe coding）——即在缺乏深刻理解的情况下通过大语言模型生成代码——阻碍了“开发者直觉”（品味）的培养。他们认为，通过跳过手动解决问题的“摩擦”，工程师会丧失调试、架构或验证系统的能力，从而导致代码库变得臃肿、难以管理且存在安全隐患。
* **进化论：** 支持者将 AI 视为一种高级抽象，类似于从汇编语言向高级语言的转变，或是数学中计算器的出现。他们认为编程只是达到目的的手段；重点应转向系统架构、需求获取和验证 AI 输出，而非编写代码这一机械动作。
* **折中方案：** 许多经验丰富的工程师建议采用“引导式编程”。他们主张将 AI 作为处理模板代码和重复性任务的工具，同时保持人工干预，以确保代码质量、安全性和架构完整性。
最终，各方的共识是：尽管敲击代码这一“行为”正在被商品化，但“工程”角色——即管理复杂性、制定策略和做出判断——依然至关重要，只是目前正因缺乏严格的培训而面临威胁。