本文详细介绍了在 Thunderbird 中实现原生 Microsoft Exchange Web Services (EWS) 支持的技术历程，重点阐述了为将 Rust 集成至 Thunderbird 基于 C++ 的 XPCOM 架构而构建的基础设施。 由于项目初期缺乏现成的 Rust 基础设施，团队构建了一个框架，旨在连接 Rust 原生的 `async/await` 语法与 Thunderbird 中高度依赖回调的 C++ 网络层 (Necko)。其中包括用于处理 HTTP 请求的 `AsyncChannelOpener`，以及一个名为 `xml_struct` 的自定义库，用于管理复杂的 SOAP/XML 序列化，从而避免了标准库中常见的冗余代码问题。 通过保持 C++ “胶水”代码与 Rust 协议客户端的清晰分离，团队成功在 Thunderbird 145 版本中推出了电子邮件支持。目前，工作重心已转向支持 Microsoft Graph API。得益于既定架构的高度可重用性以及共享库，团队显著加快了开发速度，在四个月内完成了原本需要十一个月的工作。这种模块化方法不仅保障了 Thunderbird 未来对 Exchange 的支持，也为集成 JMAP 等未来潜在协议提供了蓝图。
每日HackerNews RSS
抱歉。
MapComplete – 贡献 OpenStreetMap MapComplete: Maps about various topics which you can contribute to
19 天前
长毛象
抱歉。
Nextcloud Hub 26 Spring：共建共享，着眼未来 Nextcloud Hub 26 Spring: Built together, designed for the future
19 天前
**Nextcloud Hub 26** 的发布在 Hacker News 上引发了关于该平台实用性、维护难度及其定位演变的激烈讨论。
用户对 Nextcloud 的实用性评价褒贬不一。许多长期支持者认为它是 Google Drive 或 Dropbox 的理想替代品，能够免费、自主地托管日历、联系人和文件。然而，另一些用户则指出其存在严重的性能问题、界面迟缓，以及功能堆砌导致的体验不佳，且在更新过程中偶尔会出现稳定性故障。
部署方式是争议的一大焦点。虽然部分用户选择裸机部署，但社区大多推荐使用 Docker 环境，特别是“一体化（all-in-one）”容器以降低复杂度。即便如此，许多人仍强调必须严格执行安全措施，例如将实例置于 VPN 或反向代理之后，以减少暴露风险。
此次讨论还反映出用户对该平台版本命名混乱的不满，以及对其移动端客户端多 Bug 的诟病。尽管竞争对手（如基于 Go 语言的 ownCloud "Infinite Scale"）常被提及作为性能更优的替代方案，但对于致力于自主托管数字生活的用户而言，Nextcloud 依然是目前占据主导地位、尽管存在瑕疵的标准选择。
**Open R1** 是一个社区驱动、完全开源的项目，致力于复现 DeepSeek-R1 流水线。该计划旨在提供必要的工具、数据和训练方案，助力社区构建、微调及评估先进的推理模型。
项目分为三个关键阶段：
1. **蒸馏 (Distillation)：** 使用高质量推理轨迹复现 R1-Distill 模型。
2. **纯强化学习 (Pure RL)：** 使用大规模数学、代码和推理数据集复现 R1-Zero 强化学习流水线。
3. **多阶段训练 (Multi-Stage Training)：** 从基础模型过渡到经过强化学习调优的系统。
**主要特性：**
* **工具支持：** 提供用于监督微调 (SFT) 和组相对策略优化 (GRPO) 的模块化脚本，并利用 `vLLM` 实现高性能训练与推理。
* **数据集：** 提供如 *Mixture-of-Thoughts*（35 万条轨迹）和 *CodeForces-CoTs*（10 万个解决方案）等精选数据集，并配备使用 E2B 或 Morph 沙盒进行代码任务验证的工具。
* **可复现性：** 包含针对 AIME 2024、MATH-500 及其他竞赛任务的基准测试综合指南，其结果与 DeepSeek 公布的性能高度一致。
* **灵活性：** 支持多种硬件配置，从单 GPU 到大规模 Slurm 集群均可使用，允许贡献者针对不同的基础模型和自定义训练配置进行实验。
哈斯克尔免费图书馆和歌剧院是一处具有地标意义的社区机构，于 1904 年特意跨越加拿大和美国边境而建，旨在让邻里间共享书籍与演出。该机构近日开辟了一个仅供加拿大民众使用的出入口。此前，特朗普政府限制了从加拿大入境的人员，禁止他们使用位于美国佛蒙特州境内的图书馆原始主入口。一个多世纪以来，来自两国的人们可以自由穿过这栋建筑，跨越地板上一条黑色胶带标记的国际边境线。然而，美国更严格的安全规定实际上在 2025 年 10 月关闭了这一历史悠久的共享入口。新入口由加拿大一侧原先的紧急出口改建而成，该项目耗资巨大，部分资金来自社区募捐。视频由埃洛伊丝·阿兰娜制作。
帖子
登录
注册
帖子
Amazon Web Services @awscloud
更多
AI 生成的代码并不会让你的团队更快，反而可能会拖慢你们的速度。
晚上 8:49 · 2026年6月9日
600万次浏览
609
2400
1.9万
3900
阅读 609 条回复
初次使用 X？
立即注册，获取专属时间线！
使用 Google 账号注册
使用 Apple 账号注册
创建账号
注册即表示你同意《服务条款》和《隐私政策》，包括 Cookie 使用。
相关人物
Amazon Web Services @awscloud
关注
热门趋势
服务条款 | 隐私政策 | Cookie 政策 | 无障碍访问 | 广告信息 | 更多
© 2026 X Corp.
不要错过正在发生的事情
X 用户总是第一时间了解动态。
登录
注册
抱歉。
Glean 工作人工智能研究所的一份新报告揭示了职场中的“生产力悖论”：尽管 87% 的员工都在使用人工智能，但许多人却深陷于“机器人看管”（botsitting）的泥潭中。白领员工平均每周要花费 6.4 小时——几乎相当于一个完整的工作日——来纠正错误、提供背景信息以及管理各种互不兼容的 AI 工具。 尽管员工反馈个人生产力有所提高，但公司整体的绩效改善却停滞不前。研究人员将这种“机器人看管”描述为枯燥、令人筋疲力尽且大多未获认可的工作，这正严重影响员工士气。事实上，那些背负繁重 AI 维护任务的员工离职的可能性高出 73%，因为他们感到自己被迫将工作中最有价值的部分自动化，同时还要充当低效系统的“高级技术支持”。 该报告指出，成功的组织不仅仅是部署更多的人工智能，还在于投入资金建设其配套基础设施。那些实现真正增长的公司，重点在于提供更好的背景信息、对员工进行高效 AI 使用培训，并为人类判断建立明确的标准。如果缺乏此类支持，企业将面临因员工对自己自动化工具带来的“善后工作”感到沮丧而流失顶尖人才的风险。
访问被拒绝。美国劳工统计局（BLS）致力于及时并按照既定时间表提供数据。自动检索程序（通常称为“机器人”或“bots”）可能会导致延迟，并干扰其他用户及时获取信息。因此，禁止不符合BLS使用政策的机器人活动。对于造成的不便，我们深表歉意。如果您认为我们出现了错误，请与我们联系。请将错误代码提供给您的管理员：0.dd62c17.1781186498.814a6236
抱歉。
推测解码（Speculative Decoding）曾被视为密集型 Transformer 的“免费”性能提升方案，但随着混合专家模型（MoE）和注意力压缩技术（如 DeepSeek 的 MLA）等现代架构的转变，它正面临新的经济现实。 此前，推测解码利用了密集模型“内存受限”的特性，即验证 token 的成本几乎为零。然而，以下两个因素改变了这一局面： 1. **MoE 的代价：** 与密集层不同，MoE 的路由机制意味着算术强度取决于隐藏状态输入。在小批次场景下，新 token 会激活“新”的专家，从而产生显著的权重传输成本。因此，被拒绝的 token 不再是“免费”的，而被接受的 token 带来的相对价值也随之降低。 2. **注意力压缩：** 多头潜在注意力（MLA）等技术减少了此前可用于推测 token 的内存余量。验证过程现在往往受限于计算而非内存，这意味着每一个推测出的 token 都带有不可忽略的成本。 **结论：** 推测解码已不再是通用的优化手段。由于拒绝惩罚和验证成本的增加，系统性能现在取决于针对最优推测长度（$\gamma^*$）的动态、引导式决策。工程师们必须仔细权衡草稿模型的开销与已验证 token 的边际效用，以维持系统效率。
对不起。
软件行业衡量开发者成功的方式已发生转变，从关注可靠性、营收和客户价值等实际成果，转向依赖“AI虚荣指标”。诸如“AI生成代码比例”或“AI成熟度阶梯”等新基准，仅仅是追踪采用强度的产量指标，而非衡量业务影响。
尽管关于AI生产力的研究依然复杂且结论往往相互矛盾，但业界共识认为组织获得的收益相当有限（约10%）。然而，企业正越来越多地利用模糊的生产力叙事来证明大规模裁员的合理性，以武断的产量数据取代严谨的绩效评估。
这种趋势十分危险，因为这些指标会影响预算和人力规划。我们已经拥有经受过“实战考验”的工程健康状况追踪方式，例如DORA指标和有意义的业务增长。虽然采用AI工具对于保持竞争力至关重要，但企业必须抵制以肤浅的AI产出统计数据取代循证绩效评估的诱惑。归根结底，领导层应将AI视为提升价值的工具，而非取代既定问责制的理由。核心挑战依然在于：区分AI驱动的产出量与实际业务成果。
这篇 Hacker News 讨论批判了在 AI 生成代码时代，将“代码行数”（LoC）作为软件生产力主要衡量指标的现代趋势。
讨论中的主要观点包括：
* **“代码行数谬误”：** 参与者认为代码行数是衡量价值的糟糕指标，将其比作通过重量而非性能来衡量飞机制造。许多人指出，代码是负债而非资产，大量生成“垃圾代码”会给人类工程师带来长期的维护负担。
* **激励机制错位：** 评论者认为，领导层往往只关注代码行数，因为这是一种易于追踪的指标，却忽视了软件工程中真正的瓶颈：系统设计、领域理解和维护。一些人猜测，管理层利用 AI 将“效率”作为裁员的公关策略，而非追求真正的生产力提升。
* **AI 工具的现实：** 虽然一些工程师发现 AI 对特定任务（如测试生成或样板代码）有所帮助，但许多人反映，AI 产生的是大量、脆弱且难以维护的代码。
* **对炒作的怀疑：** 许多贡献者认为，“不采用 AI 就会被淘汰”的论调是人为制造的。他们指出，成功的公司依靠的是高质量、稳定的软件，而非快速、自动化生产未经核实的功能。