Cranelift代码生成器引入Rust

概述 Cranelift是一个Apache-2.0许可的代码生成后端，最初作为Wasmtime WebAssembly运行时的一部分开发。自2023年10月起，它作为可选组件被引入Rust的nightly工具链中，允许用户在Rust项目的调试构建中将其用作代码生成后端。

设计与特点

• 核心目标：与现有编译器（如LLVM）相比，Cranelift通过精简设计优先考虑编译速度，而非生成代码的优化程度。
• 通用架构：虽然最初为Wasmtime设计，但其通用架构使其可集成到其他项目中（如Rust，尽管SpiderMonkey已决定暂不使用）。
• 工作流程：接收自定义中间表示CLIF，并直接为目标架构生成机器代码。不依赖解释器回退机制，适合非WebAssembly项目。

优化技术

• 等价图（E-graphs）：使用基于E-graphs的优化管线，将优化识别与最终表示选择分离。优化顺序不影响结果，通过“等价饱和”过程直至无新匹配。
• 权衡：E-graphs可能占用更多内存，且提取最优表示是NP完全问题。Cranelift使用启发式方法快速提取“足够好”的表示，而非最优解。
• 优化范围：包括常量传播、位操作简化、向量化、浮点优化等，但优化数量远少于LLVM（96个）和GCC（372个）。死码消除通过E-graph表示隐式完成。
• 性能对比：2020年研究显示，Cranelift编译速度比LLVM快一个数量级，但生成的代码在某些基准测试中慢约两倍。

集成至Rust

• 开发历程：自2018年开始开发，由Rust编译器团队成员bjorn3主导（贡献约4000次提交中的3000多次）。2023年被认为足够稳定，纳入nightly工具链。
• 技术实现：需要额外库将Rust的中层IR转换为CLIF格式。
• 使用方法：通过rustup添加组件，设置环境变量CARGO_PROFILE_DEV_CODEGEN_BACKEND=cranelift，并使用cargo +nightly build -Zcodegen-backend命令构建。

实际效果

• 编译时间：在编译Cranelift自身时，使用Cranelift后端比LLVM快约20%（挂钟时间），CPU时间减少40%。增量构建速度也更快（66ms vs 90ms CPU时间）。
• 现状与展望：目前作为调试构建的可选后端，旨在缓解Rust用户对编译时间过长的担忧，初始迹象积极。它展示了编译器设计的一种不同方法。

巴黎自行车使用量一年内翻倍

核心数据

• 时间范围：2022年10月至2023年10月
• 增长幅度：巴黎街头自行车使用量实现翻倍增长

背景与意义

• 这一增长不仅是一个数据变化，更反映了巴黎社会向可持续出行和城市更新的广泛转变。
• 巴黎副市长David Belliard（欧洲生态-绿党）指出，自行车在巴黎已超越“时尚潮流”，成为城市身份认同的基本组成部分。
• 尽管近期巴黎天气恶化，但自行车出行仍创下新纪录，显示其韧性。

政策与投资驱动

• 成功源于长期且大规模的基础设施投资：
  • 2015年启动：市长Anne Hidalgo推行巴黎自行车计划，投资1.5亿欧元，目标是将自行车道数量翻倍，构建关键基础设施网络。
  • 后续追加投资：旨在填补设施缺口，将巴黎打造为“100%自行车城市”。
• Belliard强调，自行车使用增长的关键在于供给驱动（基础设施扩大），而非单纯的需求拉动。

文化与社会影响

• 巴黎自行车文化呈现多样性：从沿塞纳河的休闲骑行到繁忙街道的通勤，自行车已成为巴黎人日常生活的组成部分。
• 城市持续投资于扩展自行车道和创新公共自行车共享计划，优化骑行环境。

全国层面展望

• 巴黎的自行车热潮预计将影响整个法国。
• 2023年报道：法国计划在未来四年内投资20亿美元（约18亿欧元） 全国范围内推广自行车使用，表明这一趋势将进一步巩固和扩展。

Nanofont3x4：最小可读的3x4字体（含小写字母）

概述

Nanofont3x4是世界上最小的可读3x4字体，包括可读的小写字母。其设计涵盖大写字母（3x3加1像素前导，故称3x4）、部分2x2小写字母以及所有ASCII符号。

实用性

该字体可用于游戏内书籍页面渲染，避免乱码显示，或作为打印预览的准确文本替代模糊的占位像素，提升可读性。

动机

• 挑战极限：作者旨在探索字体设计的最小极限，尤其是创建可读的2x2小写字母（据2015年信息，这是唯一实现此类设计的字体）。
• 本质探索：通过缩小字体尺寸，分析字形的“本质”，思考如何在极小网格中保持可读性，从而推动排版艺术的创新。

设计细节

• 大写字母：基于3x3网格解决，加1像素前导，符合3x4命名。
• 小写字母：尝试将26个小写字母适配到2x2网格，但仅有9个字母（a、c、e、i、o、r、s、x、z）能放入2x2单元；其余字母（如b、d、f等）需要更大空间。
• 2x2网格限制：2x2有16种排列，许多因与标点符号冲突或错误字距而不可用。例如，某些排列被选为特定字母（如“s”对应.x x.），但存在歧义（如c、o和x使用相同模式）。
• 问题单词：包含“co”或“x”的单词（如exercise）可能难以阅读，但整体可读性经实践后可达“基本可读”水平。

输出示例

• 提供纹理图集展示所有字形。
• 支持不同输出模式：强制大写（nanofont -u）、正常大小写、不同前导像素（如1px、2px）。
• 可手动实现伪粗体（通过调暗字体和加亮区域），但未提供代码；斜体需灰度抗锯齿处理，未实现。

相关工作

• 其他小型字体项目包括：Simon Whitechapel的3x3字体（小写但中线不稳）、Anders de Flon的大写3x3字体、Ken Perlin的4x6字体（无源码）、Domenico Mazza的Zepto 3x5字体、以及小型十六进制数字字体和Miniwi字体。
• 批评：研究人员未公开代码和数据，阻碍独立验证。

致谢

感谢像素字体爱好者的分享和激励，推动边界探索。

PLANKA：一款优雅的开源自托管项目追踪工具

项目概述

PLANKA 是一个功能丰富的开源项目管理工具，提供类似 Trello 的看板体验，支持自托管部署，允许用户完全掌控自己的数据。

核心功能特性

• 协作看板：通过直观的拖拽界面管理项目、看板、列表和卡片任务。
• 实时更新：所有用户的操作即时同步，无需手动刷新页面。
• 丰富的 Markdown 支持：内置强大的 Markdown 编辑器，便于编写格式美观的卡片描述。
• 灵活的通知系统：支持通过 100 多种通知提供商发送警报，并可完全自定义。
• 无缝认证集成：支持 OpenID Connect 单点登录。
• 多语言支持：具备完整的国际化功能，方便全球用户使用。

部署与配置

PLANKA 提供多种便捷的安装方式，具体细节可参考其安装指南。项目的环境配置和相关设置说明可查阅配置章节。此外，官方网站也提供托管版或专业版（Pro）的定价信息。

附带应用：笔记 App

项目目前提供了一个测试版的笔记应用，可在多个平台使用：

• iOS：用户可通过 TestFlight 参与测试。
• Windows 与 Android：应用可在此处下载。

社区支持与联系方式

• 安全问题：请勿在 GitHub 上公开提交，应通过邮件 security@planka.group 私下报告。
• 支持渠道：项目不提供公开的邮件技术支持。获取帮助、分享想法或参与贡献，请使用 GitHub 或加入官方 Discord 社区。

许可模式

PLANKA 采用公平代码许可模式分发，主要包括：

• 源码可用：源代码始终保持公开。
• 可自托管：用户可自由选择部署和托管环境。
• 可扩展：支持自定义功能开发。
• 企业许可：提供企业版许可以获取额外功能和支持。 详细的许可信息可查阅许可指南。

参与贡献

欢迎通过贡献指南了解如何报告错误或提交功能请求。如需在本地搭建开发环境，请参阅项目中的开发章节。项目感谢所有贡献者的付出。

蜱虫杀灭药片在人体试验中取得积极成果

• 试验方法与结果：在二期临床试验中，31名健康成人分别接受Tarsus公司药片的高剂量、低剂量或安慰剂治疗。研究人员将无菌蜱虫置于受试者手臂上，24小时后测量蜱虫死亡率。

  • 短期效果：服药24小时后，高剂量组97%的蜱虫死亡，低剂量组为92%，而安慰剂组仅5%。
  • 长期效果：单次服药30天后，两个剂量组均能杀死约90%的蜱虫。
  • 安全性：报告未出现严重不良事件，也没有参与者因副作用退出。

• 药物特性与优势：该药物直接针对蜱虫本身，而非引起莱姆病的特定细菌。这意味着它可能对多种蜱媒疾病（如巴贝斯虫病和无形体病）提供防护，这些疾病随着气候变化和鹿群数量增加正在美国范围内扩散。

• 应用前景与研发阶段：

  • 研究人员认为，这种药片可能成为一种无需持续关注的“暴露前预防”措施，适用于计划徒步、露营或在蜱虫多发地区活动的人群。
  • 当前局限：目前尚未证明该药片能实际预防莱姆病。这需要在高风险人群中进行更大规模（数百人）的试验。
  • 潜在价值：预防莱姆病及其可能导致的长期持续性症状，被认为具有重要意义。

• 总结：该药物在早期人体试验中展现出快速、长效杀灭蜱虫的效果，安全性良好，并具有预防多种蜱媒疾病的潜力，但仍需进一步研究以验证其对莱姆病的预防作用。

2600.network拨号服务是一个在线平台，为用户提供连接到其网络的资源，支持拨号式公告板系统（BBS）的访问和运营。网页结构由多个功能部分组成，每个部分对应关键服务或资源：

• 电话号码：列出区域、免费和专用电话号码，供用户拨号接入2600.network。
• 登录凭证：提供不同公告板系统的登录信息，由telnetbbsguide.com贡献，便于用户访问BBS。
• 信息指南：包括教程、提示和故障排除内容，指导用户如何找到电话线、设置调制解调器以及理解网络工作原理。
• 统计数据：展示连接的实时性能指标和历史图表，监控所有用户的网络活动，帮助用户评估连接状态。
• 捐赠：列出最需要的贡献方式和简便帮助途径，以维持网络线路开放和设备运行，支持服务可持续性。
• 注册：提供自动注册或手动批准的选项，让用户快速启动并开始拨号连接。
• 服务条款和隐私政策：定义网络使用规则和隐私保护措施，要求用户在连接前阅读，以确保网络对所有人可用。
• 联系方式：用于提交问题、评论或报告问题，管理者会回复处理，特别注明排除恶意行为。

该服务旨在通过整合这些资源，促进用户参与拨号网络，并维护BBS系统的长期运作。

对软件开发未来的思考

文章探讨了大型语言模型对软件开发行业的影响，并提出了多个分析框架。

软件开发能力等级框架

作者借鉴自动驾驶的分级概念，将AI辅助软件开发分为三个等级：

1. 无AI参与：传统的纯人工开发。
2. AI辅助开发（当前阶段）：开发者使用ChatGPT或GitHub Copilot等工具，用于编写测试、样板代码、理解错误等，但AI无法自主执行完整开发流程。
3. AI代理开发：如Devin演示所示，AI可以接收需求、编写代码、调试并部署产品，目前仍处于简单任务阶段，但未来可能进步。

作者强调，说“AI将取代开发者”需要AI在需求沟通、技术设计、部署、故障处理等所有任务上都具备能力，而不仅仅是写代码。

外包开发模式框架

作者将AI编码器类比为外包软件供应商。无论团队构成如何（纯内部、内部为主、外包为主或纯外包），都需要一个内部团队来监督工作，确保产出符合组织的长期目标。同样，即使AI编码器可以像云服务一样按需使用，拥有一个内部开发团队来监督其工作仍然是有益的。

软件开发是管理复杂性

作者以Excel和低代码工具为例，指出尽管这些工具降低了入门门槛，但复杂的业务工作流仍需要访问控制、集成、可测试性等特性。软件开发的本质是将现实世界的问题转化为数字模型并管理其复杂性。就像木工棚与十层建筑的区别一样，使用AI工具构建复杂逻辑的人，实际上仍是在进行软件开发，只是使用了不同的工具。

市场规模框架

许多焦虑基于一个假设：软件开发市场大小不变，AI将抢夺人类的市场。但作者认为，“解决业务问题”的市场规模远大于当前的软件开发市场，因此软件开发职业不会很快消失。

形式化业务逻辑定义框架

业务逻辑必须以无歧义的格式定义。编程语言、Excel公式或低代码流程都具有严格定义。未来，即使AI能根据自然语言对话生成软件产品，其底层也必然存在一个形式化的业务逻辑定义，这本质上类似于“代码”。只要AI还不能确定性地从自然语言生成这些定义，就需要能够理解和修改其生成代码的人——即软件开发者。

结论

作者总结认为，在可预见的未来，软件开发市场仍会存在，但工作性质和使用的工具将发生显著变化。

文章标题为"Show HN: Let's Build AI"，内容指出该网站可通过GitHub进行编辑，并欢迎用户贡献。同时，网站声明不使用cookies，且不收集任何个人数据。

将任意SQL转换为PostgreSQL方言

本文探讨了将各种SQL方言转换为标准PostgreSQL SQL方言的技术方法与工具。这一过程通常被称为SQL转译（SQL Transpilation），在应用程序迁移、多数据库支持或统一查询接口等场景中至关重要。

核心挑战

不同的数据库系统（如MySQL, SQL Server, Oracle）都有自己的SQL方言扩展，包括：

• 函数差异：如日期处理、字符串操作函数命名与参数不同。
• 语法差异：如分页查询（LIMIT/OFFSET vs. ROW_NUMBER）、数据类型定义语法等。
• 特性支持：如特定的存储过程语法、递归查询写法等。

手动转换这些差异工作量大且易出错。

解决方案思路

实现自动化转换通常依赖以下两种主要方法：

1. 基于解析器的转换工具：

   • 使用SQL解析器（如ANTLR、JSQLParser）将源SQL解析为抽象语法树（AST）。
   • 在AST层面上遍历和修改节点，将其映射到PostgreSQL的对应结构。
   • 最后从修改后的AST重新生成PostgreSQL格式的SQL代码。

2. 基于规则的转换引擎：

   • 定义一系列从源方言到目标方言的转换规则（例如，将 IFNULL() 替换为 COALESCE()）。
   • 通过文本模式匹配或轻量级解析来应用这些规则。

工具与实践

社区和商业领域存在多种工具，如 sqlglot、sql-translator 等，它们支持多种SQL方言之间的相互转换，其中PostgreSQL是常见的转换目标。使用这些工具的基本流程包括：

• 指定源方言和目标方言（PostgreSQL）。
• 输入待转换的SQL语句或脚本。
• 工具输出转换后的、兼容PostgreSQL的SQL代码。

重要注意事项

• 功能等价性：自动转换无法保证100%的语义完全等价，尤其对于复杂的业务逻辑或数据库特定函数。
• 性能考量：转换后的SQL在PostgreSQL上可能需要额外的索引优化或查询计划调整。
• 测试验证：转换后的SQL必须经过严格的测试，以确保其正确性和性能。

总之，将SQL转译到PostgreSQL方言是一个涉及语法解析、规则映射和代码生成的过程。借助现有工具可以大幅提高效率，但仍需结合人工审查与测试，以确保迁移的可靠性。

核心问题：macOS Sonoma 14.4 正式版中存在一个缺陷，会导致 Java 进程意外终止。

影响范围：

• 受影响版本：从 Java 8 起的所有版本，包括当前的早期访问版本。
• 不受影响：使用 GraalVM Native Image 提前编译的 (AOT) 应用程序本身，但其创建新镜像的过程可能受到影响。

官方状态与临时方案：

• 甲骨文 (Oracle) 已确认该缺陷，并已通知 OpenJDK 合作伙伴、客户及苹果公司。
• 目前没有临时解决方案 (workaround)。
• 该缺陷在 macOS 14.4 的测试版中未出现，仅存在于最终发布版中。

用户应对建议：

• 对于依赖 Java 的 Mac 用户，建议暂缓更新至 macOS Sonoma 14.4。
• 已升级的 Apple Silicon Mac 用户，因无法轻松回退系统，只能等待苹果发布修复更新。
• 若用户拥有之前系统完整配置的克隆副本，可通过该副本继续使用 Java。

其他背景信息：

• 该问题对大多数普通 Mac 用户影响较小，因为 Java 在 Mac 上早已被弃用 (2012年)。
• 除 Java 问题外，macOS 14.4 更新还引发了其他不相关的兼容性问题，例如部分第三方显示器扩展坞停止工作，以及某些打印机驱动程序被移除或损坏。

维生素D毒性故事（2022）摘要

本文通过一个临床案例，探讨了维生素D补充剂的潜在风险，并主张应将其视为需要谨慎使用的药物，而非普通膳食补充剂。

核心案例：Shannon的经历

• 38岁的Shannon原本健康，2018年秋季开始出现言语困难、心悸、失眠、焦虑和认知障碍等症状。
• 其血钙水平持续轻度至中度升高（最高达11.1 mg/dl，正常上限为10.2 mg/dl），但初期医生未重视这一线索。
• 经多次会诊无果后，作者（甲状腺疾病专家）介入分析。
• 根本原因：Shannon自2013年起因骨质减少，每日服用5000 IU非处方维生素D。五年后其血液维生素D水平升至79 ng/ml（作者认为安全范围应为30-60 ng/ml）。
• 高剂量维生素D导致高钙血症，进而引发全部神经系统和全身症状。
• 2018年10月停用维生素D后，症状在数月内逐渐缓解，至2019年5月基本恢复正常。

维生素D的药物属性

• 本质：维生素D是类固醇激素，与性激素、皮质醇等同类，作用于多个器官，微量即可产生显著生理效应。
• 类比处方药：如同降压药美托洛尔需医生处方一样，维生素D也应根据个体血液指标（钙和维生素D水平）由医生指导使用剂量。
• 风险被低估：人们常认为补充剂“可能有益且无害”，但高剂量维生素D可导致严重高钙血症，引发疲劳、失眠、心悸、神经精神症状、肾结石、心律失常等。

现状与作者观点

• 常见误区：非处方维生素D常无明确警示标签，导致患者低估其风险。作者在临床中见到多例因服用推荐剂量维生素D而中毒的案例，反驳了“维生素D毒性极少见”的说法。
• 正确使用原则：
  • 维生素D缺乏应治疗，但需基于检测结果个性化给药。
  • 长期高剂量补充需定期监测钙和维生素D水平。
  • 应赋予维生素D与处方药同等的尊重和谨慎态度。
• 作者澄清：本文并非否定维生素D的价值，而是强调补充剂与药物同等重要，均存在风险与收益，需知情使用。

总结

文章警示公众和医疗工作者：维生素D作为激素，过量补充可能导致严重毒性。建议将维生素D视为药物，在医生指导下根据生化指标合理使用，并提高对非处方补充剂风险的认知。

微软再次通过弹窗广告干扰Chrome用户

微软再次在Windows 10和Windows 11操作系统中，通过桌面弹窗广告骚扰使用Google Chrome浏览器的用户，旨在推广其Bing搜索引擎及集成了GPT-4的Bing Chat平台。

• 用户反应与微软确认：部分收到广告的用户因其像素化的外观而误以为是恶意软件。微软已向媒体证实，这些弹窗是合法的，并称其为“一次性的通知”，旨在给予用户将Bing设为Chrome默认搜索引擎的选择，用户也可以选择关闭该通知。
• 触发条件与广告内容：该弹窗广告被认为是在用户打开Chrome浏览器且默认搜索引擎设置为Google时显示。广告内容称“在Chrome上免费与GPT-4聊天”，并提示点击“是”会将Chrome的默认搜索引擎更改为Bing并安装Bing服务。
• 后续操作与Chrome的应对：据WindowsLatest报道，点击“是”会手动安装名为“Microsoft Bing Search for Chrome”的扩展程序，该程序会更改地址栏和新标签页的默认搜索引擎至Bing。Chrome浏览器本身具有防止恶意扩展劫持搜索引擎的安全功能，当检测到扩展程序更改了默认搜索引擎时，会弹出确认对话框。此时，Bing扩展会显示信息，恳求用户不要将其更改回去，否则将无法使用Bing搜索和壁纸功能。
• 历史背景与行业竞争：这并非微软首次通过弹窗广告针对Chrome用户，2023年7月曾有类似的广告推广Bing Chat。历史上，谷歌和微软曾在搜索引擎、应用程序乃至操作系统中使用相互竞争的广告。例如，2020年至2021年间，双方都曾投放广告推广各自的浏览器。文章预计，未来两家公司围绕控制用户数据、浏览习惯和广告市场的竞争仍将持续。

SatCSS 是一个通过语义保持重构实现 CSS 文件最小化的工具。它可以对样式规则进行合并，前提是不会影响最终渲染效果，例如可以将多处相同声明但不同选择器的样式合并；但如果合并会改变某些元素的实际样式（如选择器组合影响优先级），则不会进行重构。此外，SatCSS 能检测两个选择器是否可能在某些 DOM 节点上同时匹配，也可作为工具/库，用来构建 CSS 文件的抽象表示，即以(选择器, 声明)对和排序（反映覆盖顺序）建模。

工具需要 Python 3.7 或兼容版本，并依赖如下包：

• cssselect 1.2.0
• docopt 0.6.2
• lxml 4.9.2
• tinycss2 1.2.1
• toposort 1.10
• z3-solver 4.12.2.0

部分代码借鉴和修改自 cssselect 0.9.1。推荐使用 Poetry 作为构建系统，经过测试的版本为 1.7.0。外部还需保证 Z3 SMT 求解器可用，建议在 satcss/main.py 同目录下建立指向 Z3 的符号链接，工具最后测试的 Z3 版本为 4.12.2.0。

项目支持两种运行方式：

1. 使用 Poetry：在根目录执行安装并运行相关命令（如 poetry run satcss benchmarks/xxx.css），可输出精简后的 CSS 文件。
2. 不用 Poetry：直接用 main.py 和 test.py，需手动安装 requirements.txt 中依赖，然后用 Python 3.7+ 执行。

SatCSS 还包含特定版本标记（TOPLAS-Release），对应 TOPLAS（编程语言系统领域顶级期刊）论文中的实现。

2023年12月，位于弗吉尼亚州汉普顿锚地的兰利空军基地经历了持续数周的神秘无人机群入侵事件。该基地部署有F-22猛禽战斗机，是北美防空司令部和北方司令部保卫美国本土（包括首都华盛顿特区）的关键节点，附近还密集分布着诺福克海军基地等大量重要军事与民用设施。

美国空军已向《战区》确认了这些入侵事件的发生。基地发言人表示，入侵始于12月6日晚，并贯穿整个12月。入侵的无人机数量和型号各异，尽管未表现出敌对意图，但闯入限制空域对飞行安全构成威胁。事件严重程度促使美军调动了全政府范围内的先进资产进行响应，包括一架来自NASA的WB-57F高空研究飞机。该飞机于12月中下旬在兰利上空执行了“影像支援”任务。

北美防空司令部和北方司令部新任司令格雷戈里·吉洛特空军上将在美国参议院军事委员会作证时，首次公开承认了这些事件。他指出，无人机入侵已成为其90天评估的核心内容，并坦言“我未预料到会看到如此多的入侵事件”。他强调新兴的无人机能力已经超出了现有作战框架，需要采取更多措施。

《战区》的调查与长期报道表明，此类事件并非孤例。兰利基地及其他美军基地、关键民用基础设施、舰艇乃至核电厂，都曾遭遇过神秘的无人机群飞越。这揭示了无人机系统对军事与关键民用基础设施构成的持续且日益增长的威胁。文章指出，即使是没有武装的小型商用无人机群，也能监视、干扰飞行操作，甚至可能利用简单的攻击手段对停机坪上的高价值目标（如F-22战斗机）造成毁灭性打击。随着武器化门槛的降低和自主性的提高，此类威胁正变得愈发严峻。此次兰利事件将这些长期存在的关切推向了前台，凸显了美军在反制无人机能力方面存在的明显不足。

神经网络图像压缩技术综述

JPEG 压缩基础

JPEG 利用人类视觉对低频信息（如边缘）更敏感、对高频细节不敏感的特点，通过离散余弦变换（DCT）将图像像素转换到频率域，再经量化（丢弃部分高频系数）实现有损压缩。量化表经过精心设计，其结构与神经网络结构有相似之处，这启发了神经网络压缩的研究。

神经网络压缩的发展

自编码器与比特嵌入

早期方法尝试使用自编码器将图像压缩到低维瓶颈表示（如二进制向量），并直接序列化为比特流。这种方法支持自适应码率控制，但因其未显式降低潜变量的熵，压缩率并非最优。

端到端训练与速率-失真权衡

2017年的突破性工作提出了端到端训练框架，直接优化速率-失真权衡。其核心是采用损失函数 (L = R + \lambda D)，其中 (R) 为比特率，(D) 为失真度（如均方误差），(\lambda) 为权衡系数。通过训练一个概率模型估计量化后潜变量 (\hat{y}) 的熵来近似比特率，并结合自适应算术编码，实现了优于 JPEG/JPEG2000 的压缩效果。

超先验与自回归先验

• 超先验：通过额外传输一个量化通道 (\hat{z}) 来为潜变量 (\hat{y}) 提供图像特定的概率分布参数（如高斯分布均值与方差），从而改进熵估计，提升压缩率。
• 自回归先验：在解码时，以前已解码的局部潜变量为条件递归预测后续潜变量的概率分布，进一步利用图像内部相关性。虽然压缩性能优异，但逐像素解码计算成本极高，后续改进（如棋盘格上下文模型）提升了效率。

变量速率控制

传统方法需为每个码率点训练单独模型。通过引入可学习的“增益”单元及其逆操作，并在训练中随机使用不同 (\lambda) 及对应的增益向量，可实现单一模型支持多种压缩质量，类似 JPEG 的质量因子。

感知损失函数

均方误差（MSE）损失可能导致低码率下纹理模糊等问题。改进包括：

• 加权MSE（结合显著性图）
• 感知损失（如LPIPS，通过预训练网络比较深层特征相似性）
• 风格损失
• GAN损失：结合判别器训练，使压缩结果在主观评价上更优（如HiFiC模型在相同比特率下优于BPG）。

当前挑战与未来展望

• 性能对比：最佳神经网络压缩器与传统编解码器（如VTM、AV1、BPG）在率失真性能上已接近，但神经网络方法计算复杂度通常高出一到两个数量级。
• 混合方法：目前实践中，结合传统编解码器与神经网络后处理（如环路滤波）的混合方法常更有效。
• 长期趋势：随着专用神经硬件的普及，结构更简洁、适合通用神经硬件的端到端神经网络编解码器有望成为主流，但短期内计算效率仍是关键瓶颈。未来的压缩系统很可能包含可学习组件。

Suno：AI音乐生成器

核心功能与技术 Suno是一家成立约两年的初创公司，开发了一款强大的AI音乐生成工具。用户仅需提供简单的文本提示（如“一首关于悲伤AI的独奏声学密西西比三角洲蓝调”），其AI模型便能在短时间内（如15秒）生成完整的、包含逼真人声和乐器伴奏的音乐作品。该技术与大型语言模型（如ChatGPT）类似，将音频视为连续信号并将其离散化处理，但面临更复杂的技术挑战（如高采样率带来的数据量）。为实现逼真的人声，模型还会从语音录音中学习。

团队背景与起源 公司由四位机器学习专家（Mikey Shulman、Keenan Freyberg、Georg Kucsko、Martin Camacho）共同创立，他们此前曾在Kensho Technologies共事。团队最初从文本转语音程序Bark起步，但根据用户反馈转向开发音乐生成器。创始人中有音乐爱好者，公司氛围也体现出对音乐的热爱。

愿景与定位 Suno的愿景是让音乐创作大众化，目标是吸引全球十亿用户每月支付一定费用来创作音乐。创始人认为，这不会取代人类艺术家，而是通过让更多人参与音乐创作和培养审美，最终使整个音乐行业受益。他们将Suno定位为一款极易使用的“乐器”，类比相机手机之于摄影的民主化作用。

市场反应与潜力 Suno生成的音乐（如示例歌曲《Soul of the Machine》）因其高度逼真和富有感染力而令人震惊，甚至让部分开发人员也感到不安。这标志着AI在音频生成领域取得重大突破，超越了以往常见的“媚俗”AI艺术。有观点认为，这种技术可能首先对广告、电视节目等需要定制配乐的商业领域产生冲击，因为它能减少这些机构对授权人类创作歌曲的依赖。

挑战与争议

1. 版权与法律风险：Suno未详细透露训练数据来源，这引发了潜在的版权问题。投资者承认存在被唱片公司起诉的风险，但认为这是早期发展必须承担的。
2. 行业影响：音乐行业人士担忧AI可能自动化本应由人类通过艰辛努力获得的艺术创作。特别是，AI生成蓝调这种与人类历史创伤紧密相关的音乐体裁，被指出具有潜在问题性。
3. 与行业的沟通：Suno声称尊重艺术家和知识产权，其工具不允许用户模仿特定艺术家的风格或使用真实艺术家的声音。公司表示正与主流唱片公司沟通，态度上并非敌对，但尚未达成正式协议。

竞争与现状 目前其竞争对手包括谷歌的“Dream Track”，但后者获得的反响不如Suno强烈。公司计划扩张，目前拥有约12名员工。尽管技术先进，公司内部仍保留录音室并享受非AI的传统音乐创作。

总结 Suno代表了AI生成式技术在音乐领域的重大飞跃，展示了通过简单文本提示生成高质量音乐的惊人能力。其目标是 democratize 音乐创作，但这同时引发了关于版权、行业结构变化以及艺术创作本质的深刻讨论与潜在法律挑战。

Vector：高性能可观测性数据管道

Vector 是一个高性能、端到端的开源可观测性数据管道，支持作为代理（Agent）或聚合器（Aggregator）部署，帮助用户控制自身的可观测性数据。它能够收集、转换和路由所有日志与指标数据，发送到任意目标平台，实现成本降低、数据增强和数据安全。

核心特性与优势

• 可靠性：基于 Rust 开发，以可靠性为首要设计目标。
• 端到端平台：统一处理日志、指标（测试版）和即将到来的追踪数据。
• 高性能：性能测试显示，Vector 的数据处理速度最高可达同类工具的 10 倍。
• 开源与厂商中立：完全开源，避免厂商锁定，支持灵活切换数据目标。

主要应用场景

• 降低可观测性总体成本。
• 无缝迁移至新供应商而不中断工作流。
• 提升数据质量与洞察力。
• 整合代理，减少运维复杂度。
• 提高可观测性系统的整体性能与可靠性。

社区与采用

Vector 被众多初创公司与企业采用，包括 Atlassian、T-Mobile、Discord 等。日下载量超过 10 万次，其最大用户每日处理数据超过 500TB。项目拥有超过 500 名贡献者，并由 Datadog 的社区开源工程团队维护。

性能对比

基于基准测试，Vector 在多项关键指标上表现突出：

功能完整性对比

Vector 是唯一同时支持代理与聚合器、统一处理日志/指标/追踪、并具备内存安全与交付保证的端到端平台。其功能对比摘要如下：

• 端到端支持：是（唯一同时支持代理与聚合器）
• 数据类型：日志、指标、追踪（开发中）
• 开源与中立：是
• 可靠性：内存安全、交付保证、多核优化

文档与资源

所有文档可通过 vector.dev/docs 访问。项目提供行为准则、贡献指南、安全策略及版本管理政策。

htmx 2.0.0-beta1 版本发布摘要

版本性质

• 这是 htmx 2.0 的首个 Beta 测试版，不建议用于生产环境。
• 发布目的是为了在实际场景中进行最终测试，鼓励用户试用并报告问题。

重要变更与注意事项

1. 移除已弃用属性：hx-sse 和 hx-ws 属性已被移除，需改用对应的扩展（这些扩展在 1.x 版本中已可用）。
2. DELETE 请求变更：DELETE 请求现在使用参数（parameters）而非表单编码（form encoded）的请求体来传输负载，这符合相关规范。
3. IE 浏览器兼容性：htmx 2.x 将不再兼容 IE，但 1.x 版本将继续为 IE 用户提供支持。
4. 迁移指南：完整的升级指南可参考《htmx 1.x -> 2.x 迁移指南》。

安装方式

• 包管理器：安装版本号为 2.0.0-beta1。
• CDN 链接：

  <script src="https://unpkg.com/htmx.org@2.0.0-beta1/dist/htmx.min.js"></script>
  

• 直接下载：可从指定地址下载。

扩展（Extensions）变更

• 扩展已从主代码库中移出，现托管于独立的 GitHub 仓库：https://github.com/bigskysoftware/htmx-extensions/tree/main/ext。
• 扩展可在 https://extensions.htmx.org 网站获取。
• 重要：SSE 扩展有破坏性更新，必须使用新版扩展：https://github.com/bigskysoftware/htmx-extensions/blob/main/ext/sse.js。

新增功能

• 新增配置选项，可忽略嵌套的 out-of-band (oob) 交换，而非处理它们。
• 新增 textContent 交换样式。
• 完善了 htmx.js 中的 JSDoc 注释并生成了 TypeScript 定义文件。
• 完成了扩展官方网站的建设。
• 新增了 htmx 1.x 兼容性扩展。

# 关于图书馆日益无法承担期刊价格的信函总结

## 核心问题
本文档为一封公开信，核心议题是**学术图书馆面临的预算危机**。由于期刊订阅价格持续大幅上涨，远超图书馆的预算增长能力，导致图书馆被迫大幅削减订阅数量，威胁到学术研究和教育的信息获取。

## 问题详述
### 1. 预算与价格趋势
- **预算紧缩**：自1980年代末至2003年，图书馆预算面临巨大压力。
- **价格飞涨**：科学、技术和医学（STM）领域的期刊价格涨幅远高于通货膨胀率。例如，Springer出版社旗下的《数学与物理学档案》杂志，在1990年至2003年间，价格从约1,800美元飙升至超过16,000美元，涨幅近800%。
- **出版商策略**：大型商业出版商（如Springer，现为Springer Nature；以及Elsevier）通过捆绑销售（“Big Deals”）、合并以及提高定价，显著增加了图书馆的财务负担。

### 2. 对图书馆的影响
- **被迫削减**：图书馆不得不取消大量期刊订阅，尤其是那些价格昂贵且使用率相对较低的刊物。
- **转向替代方案**：越来越多地依赖馆际互借（ILL）来获取被取消订阅的期刊文章。文中指出，斯坦福大学图书馆的馆际互借请求中，有相当比例指向了《物理评论》和《物理评论快报》等基本物理学文献。
- **资源不平等**：价格上涨加剧了研究机构之间的资源不平等，经费较少的图书馆和机构处于劣势。

## 论点与证据
- **数据支撑**：信函中引用了具体数据，如期刊价格涨幅、预算削减比例（例如，某图书馆预算被削减了近50%）以及馆际互借的增长数据，以论证问题的严重性。
- **结构性矛盾**：指出问题根源在于学术出版模式本身。商业出版商以营利为目标，而学术研究成果主要由公共资金资助的学者无偿提供，出版商再将成果高价卖回给公共资助的图书馆。
- **批评出版商**：信中批评了某些出版商的定价策略缺乏透明度，并质疑其高额利润率的合理性。提到Springer在1999年的利润率。

## 提出的解决方案与呼吁
1.  **推动开放获取（Open Access）**：倡导学术成果以开放获取模式出版，使研究成果能被免费、无障碍地获取。信中提到了Budapest Open Access Initiative等早期开放获取运动。
2.  **集体行动与谈判**：鼓励图书馆、学者和学术团体联合起来，与出版商进行集体谈判，争取更合理的定价和许可条款。
3.  **改变学术评价体系**：呼吁学术界（特别是终身教职评审委员会）改变过度依赖在商业高影响力期刊上发表论文的评价标准，支持在开放获取期刊或非商业渠道发表。
4.  **支持非营利出版**：鼓励支持学术学会等非营利机构的出版活动，它们通常以更低的价格和更符合学术界利益的方式运营。
5.  **直接呼吁学者行动**：信末直接呼吁收到此信的学者（特别是杰出学者）采取行动，例如：
    *   向其所在领域的期刊编辑部和出版商写信，表达对价格问题的关注。
    *   在审稿、编辑和担任编委时，考虑期刊的定价政策。
    *   优先在定价合理的期刊上发表论文。

## 结论
这封信函系统地揭露了21世纪初学术出版生态系统中图书馆、学者和出版商之间的深刻矛盾。它不仅是罗列问题，更是发出了行动号召，旨在动员学术界的关键成员共同应对这场由商业模式驱动的“期刊危机”，为知识的自由流通和学术的可持续发展寻求出路。

文章概述

本文作者Richard J. Kinch以工程师身份，详细记录了自己在2002年如何独立研究并成功更换车库门扭转弹簧的过程。文章旨在揭示通常被认为“仅供专业人士”操作的技术细节，帮助读者理解其原理、风险与可行性，以便自行操作或在聘请专业人员时做出明智判断。

核心要点

1. 工作性质与风险：

   • 扭转弹簧用于平衡车库门的大部分重量，其储存的能量巨大，若控制不当释放，可能造成严重伤害甚至死亡。作者强调这是一项危险但可管理的工作，风险可类比于换汽车轮胎或爬屋顶清理水槽。
   • 成功的关键在于理解技术、遵守安全规程、使用合适且完好的工具，并时刻保持专注和谨慎。即使专业技术人员也偶尔受伤。

2. 获取零件的挑战：

   • 弹簧制造商和分销商通常“只对行业内销售”，不直接零售给公众，这形成了一个反竞争的市场体系，导致维修服务价格虚高。
   • 作者认为这种行业保护主义缺乏正当理由，并指出互联网的出现使消费者能够找到愿意零售的网上供应商。

3. 技术关键步骤与知识：

   • 精确测量旧弹簧：必须在松弛状态下测量线径（使用卡尺）、内径、总长度和缠绕方向（左旋或右旋）。这些是订购匹配替换件的绝对必要数据。
   • 理解匹配原理：替换弹簧必须根据车库门的精确重量（需在5磅误差内）来选型，而非简单复制旧弹簧尺寸。弹簧的线径、直径和长度可以相互权衡以匹配扭矩特性。
   • 工具准备：需要一对18英寸、1/2英寸直径的钢制缠绕棒（可自制）、3/8英寸方头套筒扳手或开口扳手、活动钳口钳等。工具必须与缠绕锥的插槽紧密匹配。
   • 安全操作流程：
     • 断开电动开门器电源并将门锁定在关闭位置。
     • 仔细松开旧弹簧的固定螺丝，准备应对突然的扭矩释放。
     • 使用缠绕棒按正确方向（通常是向上推）为新弹簧加载扭矩。每次操作一个四分之一圈，并始终保持一个工具在锥体中。
     • 根据门高和卷扬鼓轮尺寸确定缠绕圈数（例如7英尺高的门通常需要约7.5圈），并通过实际称重测试平衡效果。
     • 佩戴护目镜，并确保站在稳固的梯子或平台上，身体避开弹簧和缠绕棒可能飞出的“杀伤区”。

4. 行业陷阱与消费者建议：

   • 文章详细列举了维修服务中常见的过度收费和欺诈伎俩，如“电话诱饵转换”、“开放式工作单”、“不必要的零件推销”、“伪装成技术人员的推销员”等。
   • 建议消费者坚持索要被更换下的旧零件，并在工作单上明确注明，这是防止不必要更换的最佳方法。
   • 提供了公平维修价格的参考范围（约100-150美元），并警告消费者警惕远高于此的报价。

5. 补充资源与计算：

   • 文章末尾列出了一些网上弹簧供应商的参考名单。
   • 提供了工程公式，用于计算弹簧的扭矩常数、应力及预期寿命，帮助理解如何通过选择更粗的线径来大幅提高弹簧寿命（即使成本略高）。
   • 强调了在门处于关闭位置时安装并缠绕弹簧是唯一安全可行的方法。

总结 本文是一份详尽的DIY指南和行业剖析，既传授了更换车库门扭转弹簧的完整技术知识，又深刻揭露了相关服务市场的商业操作，赋予消费者以知识和判断力。作者鼓励有能力的个体通过严谨研究自行操作，同时为选择专业服务的读者提供了识别陷阱、争取公平交易的工具。

BOINC 分布式计算平台项目动态摘要

[LHC@home] 数据库维护

• 维护时间：2026年6月4日（周四）
• 影响：项目服务器将因数据库清理操作而间歇性不可用。

[YAFU] 序列计算完成

• 项目类型：因数分解（Aliquot序列）计算。
• 完成事件：
  • 序列 3701208 已于2026年6月3日（周三）计算完成。
  • 序列 3488232 已于2026年5月30日（周六）计算完成。

[LODA] 计划维护

• 维护阶段：
  1. 第一阶段：停止创建新的计算任务（workunits），等待大部分进行中的任务完成。
  2. 全面维护：BOINC服务器将在此期间离线。
• 预计时间：未来几周内。
• 进度更新：项目方将在 LODA 语言官网 (https://loda-lang.org/) 发布最新动态。

其他信息

更多志愿者计算新闻，可访问 Volunteer Computing News。

Intel Core i9-14900KS 处理器评测摘要

核心特性与定位

• 最高频率：Intel Core i9-14900KS 特别版处理器拥有目前桌面处理器的最高时钟频率，双核加速频率可达 6.2 GHz。
• 高昂售价：定价为 689 美元，是 Intel 主流平台中最昂贵的处理器。
• 竞争格局：主要竞争对手为 AMD 的 Ryzen 7000X3D 系列处理器，后者在游戏性能方面仍保持领先，但差距正在缩小。
• 最终版本：这将是最后一款 Core i9 处理器，Intel 未来将采用新的品牌命名方案。
• 特别版性质：采用最高品质的芯片，旨在以尽可能低的电压实现最高频率，产量有限。

规格与性能概览

• 规格对比：与标准版 Core i9-14900K 基本相同，均为 8 个性能核（P-core）与 16 个能效核（E-core），共 24 核 32 线程。主要区别在于：
  • P 核的 Thermal Velocity Boost 频率比标准版高 200 MHz（达 6.2 GHz）。
  • P 核和 E 核的标准睿频分别提高 100 MHz。
• 游戏性能：
  • 在 1080p 和 1440p 分辨率下的综合游戏性能仅比标准版 14900K 快约 1.7% - 2.5%。
  • AMD Ryzen 7 7800X3D 仍是综合游戏性能最强的处理器，比 14900KS 快约 6%-14%（取决于内存配置），且价格更低。
  • 在部分特定游戏（如《微软飞行模拟器》、《杀手3》）中，AMD X3D 处理器的优势巨大。
• 应用程序性能：
  • 单线程性能比标准版 14900K 提升约 3.8%。
  • 多线程性能提升约 1.5%。
  • 在多线程负载中，其性能与 AMD Ryzen 9 7950X 相当，但在单线程性能上领先明显。

功耗、散热与系统要求

• 功耗巨大：为实现峰值性能，其功耗极高。在测试中峰值功耗达到 325W，在“极限功率配置”下可达 320W 和 400A。
• 散热要求严苛：尽管使用了 360mm 一体式水冷散热器，在重负载下温度仍频繁达到 100°C。这是由于其 自适应加速技术 旨在充分利用热余量以获取最大性能。
• 配套成本高：需要搭配高端 Z790/Z690 主板、大功率 电源 以及高端 散热解决方案，进一步增加了总体拥有成本。

结论与价值评估

• 为极客而生：这款处理器是面向追求极致频率和顶级硅片品质的发烧友及极限超频玩家的利基产品。
• 性价比低：相较于标准版 14900K，其性能提升微乎其微，但价格高出 25%（约140美元），且对系统其他组件要求极高，整体性价比很低。
• 游戏王座未易主：尽管频率登顶，但在游戏性能上仍无法撼动 AMD Ryzen 7000X3D 系列的地位。
• 最后的荣光：作为 Core i9 系列的收官之作，它创造了频率纪录，但微小的性能提升难以支撑其高昂的价格，象征意义大于实际价值。

Pine64 三月更新摘要

新产品开发

PineVox 家庭助理智能音箱

• 基于 BL606P 芯片，旨在为 Home Assistant 等软件提供语音交互的社区解决方案。
• 核心特点包括：
  • 硬件麦克风开关：物理断开麦克风时钟，确保隐私安全。
  • 外部调试功能。
  • 针对语音应用优化的扬声器设计。
• 目前少数开发者种子单元已分发，固件开发中。

骨传导耳机

• 采用与 PineBuds Pro 相同的 BES2300 芯片组。
• 计划在量产前扩展 OpenPineBuds 项目以支持此设备。
• 社区征名：产品尚未命名，邀请社区在 Reddit 和 Mastodon 上建议名称，获胜者将获赠一台。

Allwinner 合作与新 SoC

• PINE64 与 YuzukiHD 合作，将生产销售搭载以下芯片的新单板计算机：
  • Allwinner H618
  • Allwinner V851S
  • 全新 Allwinner A527 SoC：
    • CPU：4x Cortex-A55 @1.8GHz + 4x Cortex-A55 @1.4GHz
    • GPU：Mali-G57 MC2
    • 支持 eDisplayPort、PCIe 2.1（与 USB 3.0 共享，不可同时使用）
    • 内存限制：最高 4GB RAM
    • 详细信息见 linux-sunxi.org。

IronOS（Pinecil 烙铁固件）

• 版本 2.22 已发布，2.23 开发中。
• 主要改进：
  • Pinecil v2 温度稳定性提升。
  • 启动自定义 Logo 功能（通过 blisp 工具刷入 .dfu 文件）。
• 温度控制：回归使用旧 PID 控制器并调优，适用于所有烙铁头。

桌面与移动应用

• 跨平台 Flutter 应用（Android & iOS）由 Aguilaair 开发，已在 App Store 和 Google Play 上架。
• 其他应用：
  • iOS 原生应用：PineTool（Lachlan Bell）
  • 桌面端：PineSAM（Builder555）、BLE 浏览器 API（Joric）
  • Home Assistant 集成（T3chguy）

PineTime 智能手表

• InfiniTime 1.14 发布：
  • 内存优化、抬腕唤醒算法改进、新的低功耗睡眠算法。
  • Simple Weather Service：重新设计的天气服务，修复内存和崩溃问题，已集成于 Amazfish 和 Gadgetbridge。
• 编译时配置：开发者可自定义构建固件中包含的应用程序和表盘。
• GopherWatch：基于 Go 语言的固件，字体渲染流畅，支持屏幕旋转，续航长达一个月。

PineTab2 平板

• 当前状态：
  • 摄像头不可用（等待主线 Rockchip ISP 驱动）。
  • 无 USB-PD 驱动。
  • 新 BES Wi-Fi/蓝牙驱动已加入内核但默认禁用（注意：测试版，不支持休眠/挂起）。
• Danct12 正在制作新 Arch 镜像并开发首次设置界面。

PineNote 电子纸设备

• 已在 FOSDEM 展示。
• 软件状态：Debian/Gnome 环境已成熟，但开源驱动仍存在伪影问题，正在持续改进。
• 基于 Debian Trixie，蓝牙状况改善。
• 呼吁开发者协助测试。

社区服务集群故障与恢复

• 事件：2024年1月20日，集群存储节点 SSD 故障导致服务中断。
• 恢复：
  • 临时迁移至 VPS，主要服务已恢复：
    • 主网站：采用 Hugo 静态网站生成器，持续完善中。
    • Wiki：已恢复但设为只读，未来可能由文档站点替代。
    • 论坛：运行正常，但邮件功能待修复。
    • 文件：基本文档已恢复，大型文件（如SDK）待后续提供。
    • IRC 服务器：已迁移至 Docker 容器，使用 MySQL 后端，并实施反垃圾邮件措施。
• 未来计划：
  • 重建集群，计划使用 Kubernetes 管理。
  • 新设计 PCB 用于电源管理、通信和日志记录。

社区互动

• 更新频率：计划定期发布更新，具体频率待定。
• Q&A 活动：将于 2024年3月22日 CET 19:00 通过 Discord Stage 举行，并在 YouTube 直播。问题收集渠道为 Reddit 和 Mastodon。

总结基于原文内容，涵盖了所有主要产品更新、技术进展及社区服务状态。

《优越性》（1951）摘要

阿瑟·克拉克的短篇小说《优越性》以第一人称叙述，通过一位前军事指挥官的战后陈述，揭示了一场技术占优的文明如何因自身的战略与组织失误而惨遭失败。

故事背景设定在一个星际战争期间。叙述者的文明最初在舰队规模、武器（如远程自导鱼雷、可控球状闪电、克利东光束）及军事科学研究上均占据明显优势。然而，在战争初期的一次关键战役后，新任研究主管诺登教授提出了激进变革。他认为现有武器已无提升空间，应全力研发革命性新武器。

第一个新武器是**“湮灭球”**，能在一定半径内完全分解物质。但其致命缺陷是会摧毁自身复杂的生成设备，故只能搭载于制导导弹，而非直接装备于战舰。指挥层决定暂停攻势，全面改装舰队以适配新武器。然而，改装过程远比预期漫长且问题频出（如雷达意外触发、为提升威力而反复修改），导致生产停滞，前线武器短缺。

敌人趁机发起进攻，收复了部分失地。指挥官们指责诺登追求新武器导致数量优势丧失，但诺登转而推出第二个新武器——“战斗分析仪”，意图通过电子计算取代操作团队，倍增舰队作战效率。然而，该设备需要近百万个真空管和五百名技术人员维护，安装繁琐，且人员培训遭遇严重障碍（高精神崩溃率、低合格率）。仅部署了两个单元，其中一个的技术人员运输船被敌方水雷摧毁。另一个虽取得战术胜利，但其伴随后勤船的存在被敌方情报部门察觉。随后，敌方集中优势兵力摧毁了分析仪及其支援船，导致舰队指挥系统瘫痪，丧失此前所有战果。

面对败局，诺登推出了第三个也是最终的武器——“指数场”。该场能扭曲空间，使飞船在敌方眼中距离趋向无穷，实现“隐形”或突然出现在敌阵中心。初步测试看似完美。然而，在决定性的艾顿星系保卫战中，舰队发现该武器存在根本性缺陷：每次开关指数场，由于舰载设备在场作用下的微观物理变化（滞后效应），会引发不可逆的累积性空间畸变。这导致所有精密的测距与通信设备逐渐失准且与其他舰船完全不兼容。舰队陷入无法协调、互不信任的混乱状态。

最终，尽管装备了指数场的舰船在物理上仍近乎无敌，但已丧失协同作战能力。敌人凭借数量庞大但技术陈旧的舰队，轻松击败了这支因自我技术滥用而瘫痪的先进技术力量。叙述者文明战败投降。

故事的结尾极具讽刺：战后的叙述者向法庭陈述这一切，既非为了博取同情，也非为了减刑，而是为了驳斥外界对舰队官兵的污蔑，并揭露失败的真正根源——对技术“优越性”的盲目追求与不当组织管理。他最后提出的唯一请求，是不要再与“罪魁祸首”诺登教授关押在同一间牢房。

核心主题：小说通过这个故事探讨了“技术决定论”的误区，指出在军事竞赛中，过度追求尚未成熟、且会颠覆现有体系的革命性技术，同时忽视数量维持、后勤保障与组织适应能力，可能导致灾难性的反效果。真正的“优越性”需要平衡创新、可靠性、可生产性与组织韧性。

Nomadic Identity：ActivityPub联邦宇宙中的身份管理革新

核心概念
Nomadic Identity 是由联邦宇宙资深开发者 Mike Macgirvin 提出的去中心化身份管理概念，旨在解决联邦社交系统中 权限管理、身份验证和数据可移植性 三大问题。该机制已应用于 Friendica、Hubzilla 等软件，并正在被引入 ActivityPub 协议。

三大组件

1. OpenWebAuth（原 Magic Auth）

   • 实现无缝跨站点身份验证：用户在浏览器中通过 cookie 中的 token 自动验证身份，获得已授权站点的访问权限，无需反复登录。

2. Channel Relays（通道中继）

   • 允许用户通过公共 ID 将网络中的多个账户关联起来，形成中继网络。
   • 特性：
     • 网络弹性：主账户宕机时，可通过关联账户继续发布内容与关注者互动。
     • 抗审查：分布式身份存储降低单点封禁风险。
     • 简化迁移：账户间可同步状态、复制内容。

3. 数据迁移

   • 基于前两项技术，用户可自由切换主账户，所有关联账户自动更新会话线程、评论的作者信息，并实现数据复制，大幅降低迁移成本。

重要性与现状

• 当前 ActivityPub（如 Mastodon）的迁移机制较脆弱，仅能转移关注者引用，缺乏完整的数据导出能力。
• Nomadic Identity 通过成熟机制增强用户对身份和数据的控制权，尤其在大型平台（如 Threads）加入联邦宇宙的背景下，对维护去中心化网络的用户自主性至关重要。

未来进展

• Mike 正在研究如何将 Nomadic Identity 适配至 ActivityPub。
• 相关草案阶段的联邦宇宙增强提案（FEP）包括：
  • FEP-ef61（可移植对象）
  • FEP-521a（表示 actor 的公钥）
  • FEP-8b32（对象完整性证明）
  • FEP-61cf（OpenWebAuth 协议）

总结
Nomadic Identity 通过分布式身份管理、跨站点中继与无缝数据迁移，解决了联邦社交系统中的核心痛点，为 Activity 注入更强的用户主权与网络韧性，是联邦宇宙进阶发展的关键方向。

文章摘要

本文描述了因 Firebase 安全规则配置错误，导致数百个网站发生大规模数据泄露的调查过程与结果。

核心发现

• 根本原因：Firebase 平台允许用户轻松配置安全规则，且缺乏有效警告，导致广泛的安全配置错误。
• 影响范围：约 900 个网站受影响，总计泄露约 1.25 亿条用户记录，数据包含明文密码及敏感的账单信息。

调查过程

1. 扫描开发：最初使用 Python 编写的扫描器因内存溢出失败，后改用 Go 语言重写扫描器。
2. 扫描执行：扫描约 550 万个域名，耗时 2-3 周。
3. 数据验证：手动检查初期结果后，开发了名为 Catalyst 的自动化工具。该工具能自动检测对 Firebase 数据集合的未授权读取权限，并通过采样评估数据泄露的规模与影响。

泄露数据统计 总计超过 1.246 亿条记录，具体包括：

• 姓名：8420 万条
• 电子邮箱：1.063 亿条
• 电话号码：3355 万条
• 明文密码：2018 万条
• 账单信息（银行账户、发票等）：2748 万条

（注：实际数字可能更高）

主要受影响网站示例

• Silid LMS（学习管理系统）：泄露约 2700 万用户数据（姓名、邮箱、电话）。
• 在线赌博网络（9 个同架构网站）：泄露大量银行账户登录信息（800 万条）和明文密码（1000 万条），并被发现在抽奖机制上存在欺诈行为。
• Lead Carrot（潜在客户生成工具）：泄露约 2200 万用户信息。
• MyChefTool（餐饮管理应用）：泄露1400 万条姓名及1300 万条电子邮箱地址。

后续沟通与修复情况 团队向受影响的网站所有者发送了 842 封警示邮件：

• 85% 的邮件被成功送达。
• 仅 24% 的网站所有者修复了配置错误。
• 仅 1% 的网站所有者给予了回复。
• 仅 0.2%（2 个） 的网站所有者提供了漏洞赏金。

项目概述 LoRaBridge 项目旨在通过集成 LoRaWAN 远距离无线通信技术，扩展 Zigbee 传感器网络的通信范围。该项目开发了一套软硬件系统（包括桥接器和网关设备），用于将 Zigbee 网络中的传感器数据通过 LoRaWAN 网络进行远距离传输和集成。该 GitHub 组织（lorabridge）已被存档，自 2025 年 4 月 23 日起不再维护。

核心架构与组件 系统主要由两部分组成：

1. 桥接器：部署在 Zigbee 网络端，负责收集本地 Zigbee 传感器数据。
2. 网关：部署在 LoRaWAN 网络端，负责接收来自桥接器的数据，并将其转发至云平台（如 Home Assistant）。

主要软件仓库功能

• bridge-lorawan_tx (C)：核心项目仓库，实现桥接器的 LoRaWAN 数据传输功能。
• bridge-forwarder (Python)：用于在桥接器上转发来自 zigbee2mqtt 的数据。
• bridge-lcd-ui (Python)：为桥接器提供 LCD 显示界面。
• bridge-device-sse (TypeScript) 与 bridge-device-interface (Svelte)：提供设备接口和实时事件推送功能。
• gateway-forwarder (C)：在网关上负责转发 LoRaWAN 数据包。
• gateway-converter (Python)：网关端的协议转换软件。
• gateway-device_manager 与 gateway-ha_integration (Python)：分别负责设备管理和与 Home Assistant 的集成。
• gateway-home-assistant (Dockerfile)：用于构建与 Home Assistant 相关的容器。
• Ansible setup：为 LoRaBridge 设备提供自动化配置部署脚本。

技术栈与许可证 项目涉及多种编程语言（C、Python、TypeScript、Svelte、Shell）和技术（LoRaWAN、Zigbee、Docker、Ansible）。所有仓库均采用 GPL-3.0 许可证。