2026-07-14

27 篇热帖

1. Japan develops a method to recover up to 90% of lithium from used EV batteries (tech.supercarblondie.com)

日本开发出废旧电动汽车电池锂回收率高达90%的新技术

日本科学家研发出一项突破性技术,可从废旧电动汽车电池中回收高达90%的锂,远超过传统方法不足50%的回收率。这一进展不仅为应对日益增长的电动汽车废旧电池处理压力提供了更智能的方案,也可能在未来数年间改变电池的制造与再利用模式。

技术原理与环保优势

该工艺的核心在于关键的化学调整:研究团队使用回收的氢氧化锂(一种白色粉末)替代传统回收中使用的氢氧化钠,从而将被称为“黑块”(black mass)的电池废料转化为高纯度锂,这些锂可重新用于生产新电池。

研究人员指出,这一工艺不仅在材料回收效率上实现巨大飞跃,还具有显著的环保效益——与传统回收技术相比,新方法可减少约40%的碳排放。

战略与经济意义

锂是电动汽车电池最关键的成分之一,全球需求正急剧攀升,而原生锂矿开采不仅成本高昂、能源密集,还常涉及复杂的地缘政治问题。日本目前几乎所有电池矿物都依赖进口,因此在国内实现高比例锂回收,能够显著降低对进口资源的依赖,稳定供应链,并增强本国的经济安全保障。

现存挑战与未来规划

尽管技术前景广阔,日本在废旧电池收集方面仍面临较大挑战。目前全国仅约14%的废旧锂离子电池进入官方回收系统,这意味着回收基础设施亟需大规模升级。

根据规划,研究团队目标在2027年前进一步强化生产能力,并计划到2035年实现每年提取数万吨材料的规模。若该技术能够在全球范围内得到推广应用,不仅有助于减少日本的废弃物,也可能对全球资源循环和电池产业的可持续发展产生深远影响。

2. Apple's new SpeechAnalyzer API, benchmarked against Whisper and its predecessor (get-inscribe.com)

苹果于 iOS 26 和 macOS 26 中推出全新的本地语音识别 API SpeechAnalyzer(及 SpeechTranscriber),取代了旧版 SFSpeechRecognizer。为验证其真实性能,开发者在相同设备和生产代码路径下,使用 LibriSpeech 基准测试集对新旧 Apple 引擎与三款本地 Whisper 模型(Tiny、Base、Small)进行了横向对比。

核心结果

在 Apple M2 Pro(macOS 26.5.1)上完全本地运行的测试显示,SpeechAnalyzer 在准确率和速度上均领先:

引擎 test-clean WER test-other WER 模型大小
Apple SpeechAnalyzer 2.12% 4.56% 系统内置
Whisper Small 3.74% 7.95% ~460MB
Whisper Base 5.42% 12.51% ~140MB
Whisper Tiny 7.88% 17.04% ~40MB
Apple SFSpeechRecognizer(旧版) 9.02% 16.25% 系统内置

WER(词错误率)越低越好。SpeechAnalyzer 在干净语音和嘈杂语音下的错误率均低于所有参测的 Whisper 模型,同时处理速度约为 Whisper Small 的 3 倍;而旧版 SFSpeechRecognizer 的表现甚至不如 40MB 的 Whisper Tiny。

迁移建议:从 SFSpeechRecognizer 升级

数据明确建议开发者迁移。新 API 在相同音频上将词错误率降低了约 3.5 到 4 倍:干净语音从 9.02% 降至 2.12%,嘈杂语音从 16.25% 降至 4.56%。此外,SpeechAnalyzer 输出的是带大小写和标点的规范文本,而旧版输出较为粗糙。

与 Whisper 的对比

surprises 在于,对于英语语音识别,Apple 内置引擎已超越以往在本地平台被视为“自动首选”的 Whisper。Whisper 仍有两项优势:支持 100 多种语言(SpeechTranscriber 仅约 30 个语言区域),以及可在非 Apple 平台上运行。因此,开发者提供商 Inscribe 已将产品默认策略调整为:在 SpeechAnalyzer 支持的语言上优先使用该引擎,其余语言回退到 Whisper,全部本地运行。

速度表现

五款引擎在 M2 Pro 上的处理速度均远超实时(约 12 倍至 40 倍),即一小时的音频在本地仅需约 1.5 到 5 分钟即可转录。SpeechAnalyzer 在准确率优于 Whisper Small 的同时,速度约为其三倍。更精确的计时数据将在独立空闲机器测试后更新。

方法论与可复现性

为应对“销售方自测”的可信度问题,测试团队采取了多重验证手段:

  1. 与 OpenAI 官方数据对齐:选用 LibriSpeech 正是因为 OpenAI 公布了 Whisper 的 WER。本次测试的三款 Whisper 模型在干净/嘈杂语音上的结果与官方数据高度一致(偏差仅 +0.11% 至 +0.42%),说明测试框架可靠。
  2. 公开原始转录文本:所有 Apple 引擎的逐句转录、参考文本及逐句 WER 均可下载,供第三方重新评分。
  3. 严格的测试细节
    • 使用与生产环境完全一致的核心代码路径,非实验室专用环境。
    • 文本归一化流程相同(处理大小写、标点、数字转单词、缩写),避免“格式漂亮却被扣分”。
    • 采用 语料级 WER(总错误词数 ÷ 总参考词数),防止短句过度加权。
    • 强制所有 Apple 引擎完全本地识别,默认禁用云端回退,确保符合隐私定位。
    • 转录失败按 100% WER 计入,不隐藏异常。

意外发现

构建基准测试的过程中,团队还发现了自身产品的一个已发布 Bug:在调用 SpeechAnalyzer 进行文件导入时,音频流关闭后未调用 finalizeAndFinishThroughEndOfInput(),导致最终段结果无法输出、任务挂死。Because 产品此前默认使用 Whisper,该问题长期未被发现,并在当天修复。

局限与注意事项

  • 仅限英语:LibriSpeech 为英语朗读语音,结果无法推广到超过 100 种语言的 Whisper 支持范围。
  • 场景单一:测试为朗读式有声书语音,而非带口音的远场会议或多说话人场景,后者需进一步验证。
  • 单一硬件:测试仅在 M2 Pro 上完成,Apple Silicon 间的准确率应可迁移,但速度会随芯片变化。
  • Whisper 版本:使用的是 WhisperKit CoreML 量化版本,与参考 GPU 实现可能存在微小差异。

结论

对于在最新 iPhone 或 Mac 上寻求高质量英语本地语音转录的用户而言,操作系统内置的 SpeechAnalyzer 已成为当前可测的最强选项,且无需在隐私与准确率之间妥协。若应用目前仍在使用 SFSpeechRecognizer 处理长音频,迁移至新 API 在准确率层面已毫无争议。

4. Show HN: Super Dario (superdario.pawb.de)

该内容为 Hacker News 上一则 "Show HN" 类别的帖子提交,标题为 《Super Dario》

帖子正文部分未提供任何补充信息,包括:

  • 项目描述或目的
  • 技术细节或实现方式
  • 功能特性说明
  • 相关链接或演示地址

因此,除了标题所示的展示类提交身份外,无进一步可归纳的内容细节。

5. The git history command (lalitm.com)

git history 是 Git 核心发行版中新增的实验性命令(在 2.54 和 2.55 版本中分阶段引入),目的是让开发者在不迁移到 jj(Jujutsu)等替代工具的情况下,也能获得现代化、安全改写提交历史的能力。它直接内置于 Git,无需额外安装。

该命令包含三个子命令:fixuprewordsplit

fixup

git history fixup <commit> 用于修复历史提交中的错误。用户先以常规方式 git add 暂存修补内容,再执行该命令,系统会将暂存区的改动折叠进目标提交,并自动变基所有包含该提交的本地分支(而不像普通变基那样只移动当前操作范围内的引用)。操作完成后,相关分支指针会跟随到新历史。不过,该子命令目前不适用于合并提交场景。

reword

git history reword <commit> 用于修改历史提交的提交信息。执行后编辑器会打开该提交的现有信息,保存后系统自动重建其上的整个提交栈,并让相关分支跟随移动。由于仅改动提交元数据,它不会触碰索引或工作目录,因此即使目标提交位于未检出的分支上,也能直接修改。

split

git history split <commit> 用于将单个提交拆分为两个。系统会以交互式、逐块(hunk)的形式展示该提交的差异;开发者选择保留的内容构成第一个提交,其余落入第二个提交,随后自动重建后续历史。这避免了传统 git rebase -i 配合 git add -p 所需的繁琐操作。

核心设计与限制

这三个子命令的共同关键特性是原子性:它们拒绝任何可能产生冲突的操作,因此绝不会将仓库留在半损坏状态。这与 jj 将冲突作为一等公民处理的方式相比能力更保守。官方文档也指出,一旦 Git 未来支持“一等冲突”机制,该限制有望被解除。

jj 的关系

git history 并未完全覆盖 jj 的全部优势(例如操作日志与简易撤销、把工作副本建模为提交、在变基过程中携带冲突等),但它已集成在日常使用的 Git 中,提供了无需切换工作流即可享受的多分支自动变基、安全的原子化历史改写等能力,并有望在未来版本继续增强。

6. Building and shipping Mac and iOS apps without opening Xcode (scottwillsey.com)

无需打开 Xcode 构建并发布 Mac 与 iOS 应用

核心观点:只需一次性完成配置,即可通过命令行工具链全程构建、签名、公证并部署 Mac 与 iOS 应用,无需打开 Xcode GUI,也完全可由 LLM 代理(如 Claude Code)代劳。

前提条件与一次性配置

  • 必须安装 Xcode,因其包含 xcodebuildnotarytoolstaplerdevicectl 等必要工具。需确保命令行工具链指向 Xcode:
    sudo xcode-select -s /Applications/Xcode.app/Contents/Developer
    
  • 使用 XcodeGen:通过 project.yml 自动生成 .xcodeproj,避免项目文件频繁变动带来的 Git 管理问题。

仅需一次完成的交互式设置:

  1. 接受 Xcode 许可并安装附加组件(也可通过 xcodebuild 命令完成)。
  2. 在 Xcode 设置中登录付费 Apple Developer 账号。
  3. 创建 Developer ID Application 证书(用于 Mac 应用分发签名),证书与私钥存入登录钥匙串;私钥不可重新下载,务必备份。
  4. 在终端存储公证凭据:
    xcrun notarytool store-credentials App-Name --apple-id "..." --team-id ...
    
    需使用 Apple ID 的应用专属密码(非 Apple ID 密码),并按应用命名配置。确认可用后,后续构建完全自动化。
  5. 创建 Local.xcconfig 存放 DEVELOPMENT_TEAMBUNDLE_PREFIX,并加入 .gitignore

自动化发布脚本

核心是一条 scripts/release.sh,完成如下流水线:

  • xcodegen generate 重新生成工程;
  • xcodebuild archive 构建 Release 归档;
  • xcodebuild -exportArchive 自动以 Developer ID 导出并签名;
  • xcrun notarytool submit --wait 提交公证;
  • xcrun stapler staple 附加公证票据;
  • spctl 验证 Gatekeeper 放行;
  • 安装至 /Applications 并再次验证。

脚本使用 set -euo pipefail,任一环节失败立即退出;预检环节确保 xcodegen 与公证配置文件存在后,才开始耗时构建。

日常开发工作流

  • 快速编译与测试swift test 可纯 SPM 运行单元测试;xcodebuild ... CODE_SIGNING_ALLOWED=NO 可快速编译 macOS 或 iOS Simulator 版本,适合 CI/本地检查。但 Ad-hoc 构建无法绑定 iCloud、App Group 等需团队前缀的权限。
  • Mac 发布:执行 ./scripts/release.sh 一键完成签名、公证与安装;可通过环境变量覆盖默认的公证配置名。
  • iOS 真机部署:无公证步骤,先 xcodebuild archive 并以 Apple Development 身份签名(配合 -allowProvisioningUpdates 自动获取描述文件),再用 xcrun devicectl device install 安装到已连接设备。

签名机制与安全

  • 私钥签名:Developer ID 证书的私钥保存在登录钥匙串,codesign(由 xcodebuild 调用)自动读取;证书链随应用嵌入供验证。
  • 自动签名signingStyle: automatic 模式下,xcodebuild 通过 Team ID 匹配身份并自动获取描述文件,无需将描述文件存入仓库。
  • 权限绑定.entitlements 中的沙盒、iCloud KVS、App Group 等权限仅在以真实团队身份签名时才真正生效,这也是 Ad-hoc 构建不能正式分发的另一原因。
  • 公证独立:签名证明“谁构建的”,公证是苹果对签名应用的恶意软件扫描;stapler 将票据附加到应用,使离线 Gatekeeper 可信。
  • 密钥不落地:签名私钥与公证密码均保存在钥匙串(或 1Password),绝不进入代码仓库。

AI 代理的集成

作者建议为代理创建 CLAUDE.md(或 AGENTS.md),明确写入生成工程、测试、不同构建模式与发布脚本的命令。代理随后在普通非交互式 Shell 中直接调用 xcodegenxcodebuildxcrun 等标准工具,无需特殊插件。唯一的交互点仅是首次配置公证凭据;此后全过程可完全自动化。首套环境搭建约一至两小时,之后即可通过一句话指令完成构建与发布。

7. Samsung Health app threatens data deletion if users opt out AI training (neow.in)

Samsung has started showing Samsung Health users a controversial notice requiring them to consent to their data being used for AI training if they want to keep their data from being deleted.

8. Telegram's t.me domain has been suspended (www.whois.com)

Telegram 域名 t.me 暂停事件与 WHOIS 记录摘要

根据提供的内容,即时通讯平台 Telegram 使用的短域名 t.me 被指已遭暂停。随文附带的原始 WHOIS 数据披露了该域名的注册详情与当前状态。

域名 t.me 注册于 2010 年 5 月 20 日,注册有效期至 2035 年 5 月 20 日,注册商为 GoDaddy.com, LLC。注册人信息通过 Domains By Proxy, LLC 进行隐私保护,注册地位于美国亚利桑那州。

根据 WHOIS 记录,该域名当前处于以下四项注册商级别的限制状态:

  • clientDeleteProhibited(禁止删除)
  • clientRenewProhibited(禁止续费)
  • clientTransferProhibited(禁止转移)
  • clientUpdateProhibited(禁止更新)

上述状态表明注册商已禁止对该域名执行删除、续费、转移及注册信息更新等操作。

DNS 设置方面,该域名当前指向 Google Domains 提供的四组权威名称服务器:

  • ns-cloud-b1.googledomains.com
  • ns-cloud-b2.googledomains.com
  • ns-cloud-b3.googledomains.com
  • ns-cloud-b4.googledomains.com

记录还显示该域名 未启用 DNSSEC。WHOIS 数据库最后更新时间为 2026 年 7 月 15 日 01:04:23 UTC,而域名注册信息的更新时间为 2026 年 7 月 14 日 12:21:17 UTC

综上,内容标题指称 t.me 已被暂停,而附带的 WHOIS 数据则呈现该域名仍处于有效期内,由 GoDaddy 管理,并被设置了多重客户端保护锁定,名称服务器仍定向至 Google Domains。

9. Codex starts encrypting sub-agent prompts (github.com)

问题概述

Codex CLI 在合并 PR #26210(Encrypt multi-agent v2 message payloads,2026-06-05)后,MultiAgentV2 的 spawn_agentsend_messagefollowup_task 的工具入参被整体加密。InterAgentCommunication 在加密路径下仅保存 encrypted_content,而人类可读的 content 字段被置空。这导致父级本地的 rollout 历史、trace 缩减、审计与调试界面中,子代理任务或消息内容变为不可读的密文,严重影响事后排查与可审计性。

根因分析

源代码层面存在以下关键行为:

  1. 构造时丢弃明文InterAgentCommunication::new_encrypted() 在创建加密通信时,将 content 初始化为空字符串,仅写入 encrypted_content
  2. 模型输入仅输出密文to_model_input_item() 在检测到 encrypted_content 存在时,直接向模型提供加密负载,不再附带可读文本。
  3. 工具层无伴随明文字段send_messagefollowup_task 的反序列化结构仅提取 target 与加密的 message,随后通过 communication_from_tool_message() 原样传入,全程没有可供本地审计的明文副本。
  4. 持久化与日志回退到密文record_inter_agent_communication() 将包含密文的 ResponseItem 写入历史;结构化通信日志在 content 为空时,也只能回退输出 encrypted_content

因此,加密交付虽保护了传输隐私,却连带消除了本地人工审计所需的明文视图。

修复方案

目标是在不 revert 加密交付的前提下,恢复本地可读审计轨迹:

  • 保持加密交付不变message 字段仍作为加密负载传递给接收方子模型;to_model_input_item() 的模型侧行为保持不变。
  • 添加强制明文审计字段:为 spawn_agent 引入必填的 task_message,为 send_message/followup_task 引入统一的明文审计字段(如 task_messagemessage_text)。
  • 双字段构造通信:在工具处理边界校验明文字段非空且长度受限后,构造 InterAgentCommunication,使 encrypted_content 承载密文、content 承载明文审计副本。
  • 持久化与展示使用明文:父级 rollout/history、trace edges、通信日志与 resume/replay 均读取 content 中的明文审计值,绝不将密文回填到面向用户的可读文本字段。
  • 匹配与关联仍基于密文/ID:tool call 与已交付子代理项的关联继续依赖加密负载或标识,而非明文内容,防止审计元数据干扰交付身份。

目前已有原型提交(ignatremizov@df9a7c4)完成了 spawn_agent 侧的改造,包括:schema 定义、非空校验、双字段通信构造、以及 trace 缩减中将审计内容与交付匹配逻辑分离。剩余工作是将同一模式应用到 send_messagefollowup_task,并确保所有用户可见的历史/回放/调试界面都读取明文审计字段。

验收标准

  • 父级 rollout/history 中,spawn_agentsend_messagefollowup_task 均展示可读文本。
  • 子模型在加密启用时仍仅接收加密交付负载。
  • 结构化 rollout-trace 的交互边携带受长度限制的明文 message_content
  • 通信日志在有明文审计内容时优先使用明文,不将密文当作可读消息文本展示。
  • 恢复与回放保留审计副本,但不将其注入子模型上下文。
  • 现有明文 v1 通信行为保持不变。
  • 回归测试覆盖全部三种 v2 工具,同时断言“本地审计明文可读”与“接收模型侧加密交付”两项契约。
10. An Englishwoman who sketched India before photography took hold (www.bbc.com)

艾米莉·伊登(Emily Eden)是19世纪英国才华横溢的艺术家与作家,出身显赫政治世家。1836年至1842年间,她陪同担任印度总督的兄长乔治·伊登(奥克兰伯爵一世)旅居印度,以异常好奇且精确的视角,用素描和水彩记录了北印度形形色色的民众、服饰、建筑与风物。

伊登于1836年3月抵达加尔各答,初期因湿热、蚊虫、文化隔阂而深感思乡,整整三周不曾动笔。但随行的家人、仆役与宠物逐渐慰藉了她,而旅途中遭遇的多元文化也拓宽了其视野。此后六年,她的创作不再局限于英式风景,转而聚焦于陌生人、传统衣饰与异域地貌。她曾沿恒河航行至贝拿勒斯(今瓦拉纳西)与拉姆纳加尔,也曾深入锡克帝国宫廷,为兰季特·辛格大王及其侍从留下肖像,捕捉其王朝末期与维多利亚时代黎明交汇的历史瞬间。她还描绘了流亡印度的阿富汗酋长多斯特·穆罕默德·汗与家人、阿卡利·尼昂武士、喜马拉雅商旅家庭、穆斯林学生、总督府的印度管家,以及猎豹、猎鹰与猎犬等动物。

伊登同时也是文风活泼幽默的作家,其印度书信日后结集为《Up the Country》(1866)与《Letters from India》(1872)。她的画作曾在西姆拉慈善集市热销,赢得在印英国人与印度本地画家的赞赏。艺术史学家玛丽·安·普赖尔(Mary Ann Prior)认为,伊登的印度素描堪称摄政与维多利亚时代英国女性艺术家最杰出的作品之一,堪与夏洛特·坎宁和玛丽安·诺思比肩。1844年,二十余幅她的画作被制成手工上色石版画,以《Portraits of the Princes and People of India》为名出版。这些作品如今正于德里DAG画廊的“Princes & People”展览中完整呈现,由普赖尔策展。

然而,伊登的敏锐观察始终伴随着对英国“文明教化使命”的认同,她将印度岁月视为“为更高目标而忍受的磨难”。1842年返英后,她作画渐少,题材回归英伦风景;印度经验则主要通过文字触及更广泛读者。她于1869年去世。尽管早年声望多与家族卷入第一次阿富汗战争相连,但最终确立于她自身作为作家与艺术家的卓越成就。

11. Australian energy retailers must provide three hours of free daytime electricity (lenergy.com.au)

澳大利亚“太阳能共享优惠”计划:2026年7月起每日提供三小时免费日间电力

自2026年7月1日起,新南威尔士州、南澳大利亚州及昆士兰东南部地区的能源零售商必须向家庭提供每日至少三小时的免费日间电力。该计划名为“太阳能共享优惠”(Solar Sharer Offer),无需安装太阳能电池板,也无需拥有房产。用户只需配备智能电表并通过零售商选择加入,即可享受这一政策。

计划背景与覆盖范围

澳大利亚拥有超过430万户屋顶太阳能装置,晴朗午间时常因发电量过大导致批发市场价格走低甚至降为负值,但普通家庭的电费账单从未反映这一收益。新计划将午间太阳能发电的低价优势直接传导至用户,免费时段通常安排在11时至14时或12时至15时之间,具体由零售商根据当地情况确定。

2026年7月首批覆盖地区为:

  • 新南威尔士州
  • 昆士兰东南部
  • 南澳大利亚州

上述地区由联邦默认市场报价(Default Market Offer)框架管辖。维多利亚州正在磋商中,预计可能于2026年10月加入,其他州有望2027年跟进。目前,部分零售商(如AGL、Red Energy、GloBird Energy、OVO Energy)已自愿推出类似的免费日间用电方案。

关键调整:每日24千瓦时合理使用上限

该计划于2025年11月公布后进行了公众咨询,最终方案增加了一项重要限制:每日免费电量上限为24千瓦时。政府称此举旨在确保零售商财务可持续及电网公平。24千瓦时约为五口之家的日均总用电量。对于运行洗衣机、烘干机、洗碗机、空调及热水系统的家庭,该限额虽较宽松,但并非无法触及。大多数日常家庭不会超出此上限。

对不同类型用户的影响

对于已安装屋顶太阳能的家庭,上限通常影响甚微,因为白天太阳能已覆盖大部分用电需求。仅在冬季阴天、同时通过电网为大型家用电池和电动汽车充电、或系统容量较小却高负荷运行时,才可能接近限额。超出部分将自动按标准日间费率计费,不收取额外罚款,且日间电价仍低于晚间峰值电价。

对于无太阳能系统的家庭,若试图在免费时段大量为大型电池充电,则会受到该上限约束。该计划的设计初衷并非支持此类用途。

节省潜力与最佳适用人群

根据气候变化、能源、环境和水资源部(DCCEEW)的模型估算,节省金额取决于用户将多少用电负荷转移至免费时段:

  • 转移10%的日常用电(例如每日一台大电器):每年节省约100至190澳元
  • 转移20%(增加烘干机或设定日间加热水):每年节省约300至790澳元
  • 转移25%至30%(加入泳池泵、电动汽车充电等):每年节省约400至1,100澳元

拥有电池和电动汽车的家庭受益最为显著。免费时段内可从电网免费为家用电池充电,以应对傍晚高价时段;电动汽车若在白天居家,也可利用该窗口免费补电。具备自动调度功能的能源管理系统(如Sigenergy平台)可进一步简化这一过程。

该计划尤其适合日间在家者(远程办公者、退休人员、日间看护)、拥有可定时智能电器的家庭,以及此前难以享受太阳能红利的租房者和公寓住户。

参与方式与提前准备

2026年7月1日计划正式启动后,用户需联系能源零售商申请加入。在此之前,建议完成两项准备:

  1. 确认家中是否已安装智能电表;若未安装,可联系零售商免费申请。
  2. 检查高耗能电器(热水器、泳池泵、洗衣机、电动汽车充电桩等)是否支持定时运行。

能否最大程度节省电费,关键在于主动将用电需求安排至每日免费窗口,而非仅完成注册即可。

12. Fundamentals of Wireless Communication (2005) (web.stanford.edu)

《无线通信基础》(2005年版)是由剑桥大学出版社出版的研究生教材,面向具备概率论与数字通信基础的读者,系统阐述物理层无线通信的理论进展及其在系统中的实现原理。

全书共10章及2个附录。主要内容包括:无线信道特性;点对点通信中的检测、分集与信道不确定性;蜂窝系统的多址接入与干扰管理;无线信道容量;多用户容量与机会通信;MIMO通信的空间复用、信道建模、容量与多路复用架构;分集-复用折中与通用空时码;以及多用户MIMO通信。附录涵盖加性高斯噪声中的检测与估计,以及信息论基本原理。各章均配有习题。

本书以统一视角解析无线通信核心概念,重点涵盖MIMO、空时编码、机会通信、OFDM与CDMA等关键技术,并结合GSM、IS-95(CDMA)、IS-856(1xEV-DO)、Flash OFDM及ArrayComm SDMA等系统实例,强调概念设计与工程实现之间的紧密联系。书中包含大量图表与习题,适用于电气与计算机工程专业研究生课程,也可供工程实践人员参考。

配套资源方面,教师可索取部分习题解答与PowerPoint课件;出版社提供截至2010年2月的勘误表。此外,作者基于本书开设2天12小时的短期课程,曾在全球多所知名高校与机构讲授。该书已被加州大学伯克利分校、麻省理工学院、清华大学、香港中文大学等50余所院校采用。

在线PDF版本与纸质书受同等版权保护,需使用Adobe Acrobat Reader 7.0或更高版本阅读。

13. What will be left for us to work on? (www.normaltech.ai)

Arvind Narayanan在ICML 2026上发表题为《What will be left for us to work on?》的演讲,回应AI社区对未来的焦虑。他提出三大核心论点:第一,除非发生递归自我改进等突变,“AI作为正常技术”(AI as Normal Technology)框架是理解AI影响的正确方式;第二,即便认真对待递归自我改进,也没有某个实验室里程碑会突然导致人类集体失业;第三,未来工作将发生根本性改变,人类需要大量适应,最终走向人类与AI的“共同超级智能”(co-superintelligence)

“AI作为正常技术”框架借鉴创新扩散理论,将AI影响分为四个阶段:方法/能力、产品/应用、早期采用和适应/结构转型。作者以电力革命类比,强调最后一阶段最慢,需要数十年组织、制度和人力资本的重组,而非简单的“即插即用”。目前,这一适应过程尚未真正开始。

针对“AI即将取代所有工作”的叙事,Narayanan指出,近期前沿模型的能力(准确率)快速提升,但可靠性(一致性、鲁棒性、校准、操作安全)增长缓慢。当前AI在可验证任务上表现优异,但在不可验证的创造力等维度上仍远逊人类。因此,协作型智能体自动化智能体更现实;在高风险场景中,通用、自动且可靠的代理目前难以兼得。

以软件工程为例,工作被重构为**“决策-执行-交付”三明治**:AI压缩了中间的编码层,但需求理解与规划(决策层)、责任承担与系统集成(交付层)并未被压缩,甚至扩展。知识工作者的角色将更像起重机操作员——机器承担重体力劳动,人类保持控制与判断。历史上,ATM增加了银行柜员、AI辅助提升了放射科医生的需求,这说明**“劳动总量谬误”**不成立:效率提升往往创造更多需求。

对于递归自我改进(RSI),作者认为应将其与类人性、经济变革性、超级智能四个维度区分看待,它们互不蕴含。短期内实现的RSI更可能是“高级超参数搜索”,而非替代全人类研究社区的创造力。经济变革的真正障碍在下游(可靠性、系统集成、领域隐性知识、监管),这些不会在实验室里被下一个模型版本解决,而需数十年逐步推进。至于超级智能,许多任务的瓶颈本就不在人类生物学限制,而在于学习与工具;AI作为工具实际上正在提升人类智能。

展望未来,纯技术技能将贬值,努力将从“构建”大规模转向**“评估”。评估不仅是技术问题,更是引导AI社区航向的“舵”。科学的目的不是绕过人类理解的自动解题,而是在利用AI的同时提炼人类理解。企业和研究者需警惕“黑箱陷阱”和依赖螺旋**:应先掌握任务再使用AI增强,在提升生产力的同时保持控制,将节省的时间再投资于长期技能成长。

最终愿景是:AI成为**“心灵的起重机”**,将人类潜力放大到前所未有的高度。在可预见的未来,人类不会无事可做,而是会与AI协同,成为掌控方向的“共同超级智能”。

14. The real prices of frontier models (playcode.io)

前沿AI模型的真实成本不能仅通过价目表上的$/Mtok直接比较,因为token并非固定文本单位,不同厂商的分词器会将相同内容切分为差异极大的片段数量。文章通过实测16种真实文件(涵盖英文、HTML、代码、JSON、中文等),使用各厂商官方计数端点交叉验证,揭示了分词器差异对实际账单的深刻影响。

Anthropic新分词器暗涨约30% Anthropic的Sonnet 5、Opus 4.8与Fable 5启用了新分词器,而Opus 4.6与Sonnet 4.6使用旧分词器。实测显示,在相同的系统提示、工具架构与代码文件上,新分词器产生的token数平均增加约32%,其中英文散文与代码涨幅显著,中文几乎不变。由于标价未调整,这意味着实际成本同步上升:Opus 4.8标价为$5/$25,等效成本约为**$7.50/$37.50**;Sonnet 5在优惠期结束后恢复$3/$15,等效成本约为**$4.50/$22.50**,比Sonnet 4.6高约三分之一。

跨厂商差距:代码最甚,TypeScript达1.73倍 以GPT的o200k为基准(1.00x),Claude新分词器在各类内容上产生1.36x至1.73x的token数。其中散文、HTML和JSON约为1.36–1.42x;代码类最高,JavaScript 1.52x、Rust 1.58x、Python 1.50x,TypeScript达1.73x。原因在于GPT对TypeScript等Web前端代码的压缩效率极高,而Claude的分词密度相对一致。相比之下,Grok 4.5与GPT接近(约1.03–1.11x),Gemini 3 Flash略高(约1.09x),但仍保持最低的等效价格。

输入token之外的成本变量 文章强调,上述测量仅针对输入tokenization。实际代理任务的总成本还受输出冗长度、推理token(thinking)、工具调用频率及缓存读写价格影响。新分词器不仅提高输入费用,还会因token数增多而使缓存读写同步变贵。有生产实测显示,相同构建任务下GPT-5.6 Sol的输入token比Claude Opus 4.8少约35%。

比较模型价格的建议

  1. 使用自有内容实测:不同语言与文件类型决定分词倍率,运行代表性样本后再参考价目表。
  2. 将分词器变更视为价格变更:同标价下若分词器改变,实际已涨价。
  3. 以“美元/完成任务”为最终基准:该指标融合了分词、输出长度、推理与缓存,比$/Mtok更能反映真实支出。

结论是,$/Mtok只能作为初步参考,跨模型比较必须换算成分词器差异后的等效价格,或直接衡量端到端的单任务成本。

15. YouTrackDB is a general-use object-oriented graph database (github.com)

YouTrackDB 是由 JetBrains 开发并已在内部生产环境中使用的通用面向对象图数据库。它结合了图数据模型与面向对象特性,旨在提供高性能、强一致性且易于集成的数据持久化方案。

核心特性

  • 高性能数据处理:链接(Link)遍历的复杂度为 O(1),消除了昂贵的运行时 JOIN 开销。
  • 面向对象 API:在数据库层面原生实现继承与多态,支持构建丰富的图和面向对象数据模型。
  • 事务隔离:默认采用快照隔离级别,每个事务都能看到一个稳定的、事务开始时刻的数据库快照,从而避免脏读、不可重复读和幻读。
  • 图查询与 TinkerPop 生态:内置支持 Apache TinkerPop API 与 Gremlin 查询语言;GQL(Graph Query Language)与 Gremlin 的无缝集成正在开发中。为获得最佳查询性能,官方建议使用 YQL 进行初始数据预取。
  • YQL(YouTrackDB Query Language):一种基于 SQL 并扩展了图功能的查询语言。它使用直观的点符号(dot notation)进行链接遍历以替代 JOIN,支持强大的 MATCH 图模式匹配语句,并能自动利用索引优化查询执行计划。
  • 灵活的 Schema 模式:支持无模式(schema-less)、混合模式(schema-mixed)和全模式(schema-full)开发工作流。
  • 安全与静态加密:具备基于用户、角色和谓词的安全策略体系,并可选对磁盘上的静态数据进行加密。

安装与使用

YouTrackDB 可在任何平台上直接运行,无需额外配置。

  • 快速体验:可通过 Docker 运行交互式 REPL 控制台(youtrackdb/youtrackdb-console)。
  • 嵌入式部署:在 Maven 或 Gradle 中添加 io.youtrackdb:youtrackdb-embedded:0.5.0-SNAPSHOT 依赖即可。该构件为 shaded uber-jar,已将 Guava、Jackson、Groovy 等第三方依赖重定位至 com.jetbrains.youtrackdb.shade 包下,避免与应用程序的依赖版本冲突。由于当前为快照版本,需额外配置 Sonatype Central Portal Snapshots 仓库。
  • 服务器部署:通过 Docker 镜像(youtrackdb/youtrackdb-server)启动,需暴露 8182 端口,并挂载 secretsdatabasesconflog 四个目录;root 密码需预先写入 secrets/root_password 文件中。

环境要求方面,运行时至少需要 JDK 21。官方提供了入门指南以及涵盖服务器与嵌入式部署场景的 Java 示例项目

社区与贡献

项目维护公开的问题跟踪器(JetBrains YouTrack),并在 Zulip、Bluesky、Medium 和 Reddit 上设有社区频道。开发流程严谨,所有非重大变更都需经过研究、设计、计划评审、分阶段实现与代码评审。新贡献者可参考仓库中的开发工作流手册,了解如何按此流程参与贡献。

16. European "age verification" "app" forcing everyone to use Android or iOS (github.com)

对欧洲年龄验证机制强制依赖Android或iOS生态的批评声中,数字身份方案Yivi常被视作更具隐私优势的替代标杆。但技术审查显示,其NFC护照验证流程存在显著的中心化依赖,并非“零依赖”。

根据privacybydesign/go-passport-issuer源码,用户注册护照时,原始NFC数据组会被上传至中央签发服务器。其中DG1(完整MRZ)与DG2(面部图像)为必填项,服务器据此解析姓名、证件号码、国籍、出生日期及性别。面部匹配则通过第三方服务Regula的API完成。

因此,Yivi的身份真实性保证需以两项外部依赖为前提:将用户的完整MRZ与面部生物特征提交至中央服务器,并经由第三方生物识别服务商核验。Yivi声称数据暂态处理且签发端可自托管,但架构上仍属于信任集中于发行方与外部服务商的模式。这与设备认证(如强制使用Android/iOS)是不同形态的信任集中,且在隐私风险上未必更小。

综上,Yivi的隐私承诺需审视其实际技术路径:其NFC护照流程涉及原始敏感数据外传与第三方API调用,用户在将其视为隐私干净的基准时应充分意识到这些依赖。

17. The Economics of Recursive Self-Improvement [pdf] (elasticity.institute)

递归自我改进(RSI)的经济学:模型、校准与评估

本文构建了一系列理论模型,以评估人工智能递归自我改进(RSI)的可信度及其潜在影响。作者将RSI重新界定为“AI能力在没有外生投入(如人力、训练算力)增长的情况下实现自我持续加速”,并提出了判断自我持续加速的核心条件。

理论框架与模型结构 文章以有向图表示AI进步的反馈循环网络,节点为生产函数的产出变量,边的强度表示弹性。若某变量对自身的总弹性(所有反馈路径上弹性乘积之和)大于1,则该变量呈现自我持续加速。作者依次推进模型:

  • 基础模型:基于Jones(1995)的创新模型,算法效率(A)的改进依赖研发劳动(L)与现有技术水平。若算法改进对当前技术存量的弹性ε_{Ȧ,A}>1,则实现自我加速。
  • 基准RSI模型:引入AI能力(C)与训练算力(T),形成“核心反馈循环”:算法效率→AI能力→算法改进。自我加速条件扩展为总弹性 E_{Ȧ,A} = ε_{Ȧ,A} + ε_{Ȧ,C}·ε_{C,A} > 1。
  • 瓶颈模型:加入人力、实验算力、推理算力、数据、训练算力等投入。虽然总弹性公式不变,但这些瓶颈可能降低核心弹性 ε_{Ȧ,C},从而削弱循环。
  • 狭义与广义能力:区分“狭义能力”(促进算法优化的能力)与“广义能力”(产生经济价值的能力)。狭义加速未必传导至广义经济产出,除非算法效率向广义能力的传导弹性(或超弹性)足够高。
  • 特定优化能力与增长突刺:AI可能仅擅长改进部分子算法,导致暂时性“增长突刺”而非持续加速;若未优化的子算法成为瓶颈,整体效率提升将停滞。
  • 经济反馈循环:放宽算力与数据恒定的假设,纳入经济产出(Y)对算力与数据投资的反哺。自我加速条件进一步扩展,需考虑“核心循环”“间接经济循环”(通过训练算力与数据)及“直接经济循环”(通过实验与推理算力)三通道弹性之和。

数据需求与实证校准 为给模型提供实证基础,作者列出AI企业可公开的关键数据清单,包括算法效率增速、研发支出结构、AI对技术进步的独立贡献度等。基于现有文献,文章将核心条件拆解为三项乘积:研发回报率 × 研发努力对AI能力的弹性 × AI能力对算法效率的弹性。

  • 算法效率年增速约3倍,综合研发努力增速亦约3倍,故研发回报率≈1;
  • Epoch能力指数(ECI)估计能力对算力弹性约6.5;
  • 由此推算,自我持续加速要求每增加1单位ECI,研发努力至少提升约15%。 然而,基于近期AI辅助研发生产力的粗略估算(如编码代理带来的工程师效率提升),该回报目前约为9%,尚未跨越阈值,但呈上升趋势。

评估与启示 模型与数据表明,当前反馈循环尚不足以支撑自我持续加速,但正迅速增强。支持加速的证据包括AI系统已实质贡献于算法研发、前沿实验室内部推理算力投入激增;反对证据则包括算力与数据瓶颈、算法改进的边际递减、政治监管与社会部署阻力。若自我持续加速发生,将带来转型成本激增、制度滞后、领域间进展不对称、企业与国家间权力失衡以及对齐风险下降时间不足等深远影响。文章呼吁持续监测上述关键弹性,并建议AI企业公开更多可测量的实证数据,以服务于公众对RSI风险的研判。

18. Claude Code plugin that plays a Mr. Meeseeks voice line whene Claude is waiting (github.com)

Claude Code 插件:Mr. Meeseeks 语音提示

这是一个为 Claude Code 设计的插件,当 Claude 真正在等待用户输入或操作时,会播放来自《瑞克和莫蒂》角色 Mr. Meeseeks 的标志性语音片段。

核心功能

  • 完成提示:当 Claude 完成任务并等待用户输入下一条指令时(触发 idle_prompt 通知),插件会从 audio/done/ 文件夹中随机播放一条完成类语音(如 "All done!")。
  • 询问提示:当 Claude 需要用户批准或输入时(触发 permission_prompt 通知),插件会从 audio/asking/ 文件夹中随机播放一条询问类语音(如 "Can you help me?")。
  • 智能静默:插件仅响应特定的通知事件(通过 notification_type 过滤)。后台代理、自动接受运行、身份验证刷新等自主活动不会触发语音,保持安静。
  • 非阻塞播放:语音播放以独立进程运行,不会阻塞 Claude Code 的交互界面。

安装方法

  1. 通过插件市场安装
    /plugin marketplace add thephw/claude-meseeks
    /plugin install mr-meeseeks@claude-meseeks
    
  2. 从本地克隆安装
    /plugin marketplace add /path/to/claude-meseeks
    /plugin install mr-meeseeks@claude-meseeks
    
    安装后,重启或重新加载 Claude Code 即可生效。

系统要求与依赖

  • 需要系统 PATH 中有一个音频播放器。插件会按顺序自动检测:afplay (macOS)、ffplaympg123paplayaplay 或 Windows PowerShell 的 Media.SoundPlayer
  • macOS 开箱即用。Linux 用户通常需要安装 ffmpeg (提供 ffplay) 或 mpg123
  • 使用插件无需安装 Go 语言工具链。预构建的二进制文件已包含在 bin/ 目录中。

工作原理

插件通过钩子注册事件。当收到 NotificationUserPromptSubmit 事件时,执行脚本调用一个名为 meeseeks 的小型 Go 程序。该程序:

  1. 读取事件数据(JSON 格式)。
  2. 根据 hook_event_namenotification_type 决定播放哪个类别的语音。
    事件类型 播放类别
    UserPromptSubmit (用户提交提示) feedback (反馈)
    Notification + idle_prompt (Claude 完成,轮到用户) done (完成)
    Notification + permission_prompt (需要批准) asking (询问)
    其他事件 (如代理完成、认证成功) 静音
  3. 从嵌入在二进制文件中的音频提取出对应类别的随机一个 .mp3 文件到缓存。
  4. 启动一个独立的系统播放器进程来播放该音频文件。

所有路径都会正常退出,因此钩子不会阻塞或导致 Claude Code 会话出错。

配置与管理

  • 查看状态/mr-meeseeks:statusmeeseeks status
  • 静音类别/mr-meeseeks:mute <类别> (可选 doneaskingfeedbackall) 或 meeseeks disable <类别>
  • 取消静音/mr-meeseeks:unmute <类别>meeseeks enable <类别>
  • 切换状态meeseeks toggle <类别> 设置会保存在 ~/.config/claude-meseeks/state.json 中并立即生效。

自定义语音

用户可以通过修改 audio/ 目录下的文件来自定义语音:

  • audio/done/:完成提示音。
  • audio/asking/:询问提示音。
  • audio/feedback/:用户提交提示时的反馈音。 只需替换或添加 .mp3 文件(文件名不能包含撇号 '),然后运行 ./scripts/build.sh 重新生成包含新音频的二进制文件即可。

设计理念:Mr. Meeseeks 与会话目标

插件选择 Mr. Meeseeks 主题不仅是趣味,也蕴含了工作理念:

  • 单一目标:Mr. Meeseeks 被创造来完成一项任务。类似地,一个 Claude Code 会话最好聚焦于一个明确、具体的单一目标(如“完成这个端点”、“修复这个失败测试”)。
  • 及时结束:任务完成后,应结束会话。为新任务开启新会话比长时间维持一个旧会话更有效率。
  • 警惕长期会话:让一个会话承载多个无关目标会导致上下文堆积、注意力分散,如同让 Mr. Meeseeks 处理无限目标会引发混乱一样,降低工作质量。

音频来源说明

所有语音片段均来自《瑞克和莫蒂》中的 Mr. Meeseeks 角色,由 jayuzumi.com 的 Mr. Meeseeks 音效板提供,仅用于个人、非商业的趣味目的。其版权归相应权利所有。在公开重新分发此插件或替换为自己音频时,请考虑相关版权。

19. Satellite Tracker – Live Map of Starlink and 30k Satellites (satellitemap.space)

卫星追踪器 – 星链及3万余颗卫星的实时地图
该网站是一个在线卫星追踪工具,主要功能是实时追踪并可视化显示来自星链、GPS及其他星座的卫星位置。
它自2019年上线运营,采用现代WebGL技术进行渲染,以确保在展示大量卫星数据时的流畅性和视觉效果,性能经过优化。
网站鼓励用户通过内置的反馈按钮提交错误报告和建议,并邀请用户向对太空感兴趣的朋友分享该工具。

20. Indian scientists produce most detailed 3D atlas of the human brainstem (www.bbc.com)

印度科学家团队成功创建了目前最详细的人脑干三维图谱,标志着神经科学领域的一项重要进展。该图谱名为“Anchor”(Atlas of Neurochemical Characterisation of the Human Brainstem with 3D Reconstruction),由印度理工学院马德拉斯分校的苏达·戈帕拉克里希南脑中心完成。

核心成果与方法

  • 图谱构建:该图谱结合了来自胎儿、儿童和成人脑的500多个组织切片。与昂贵的分子技术不同,它基于高分辨率显微镜图像构建,成本更低且具有可推广性。
  • 高分辨率细节:图谱以细胞分辨率构建,识别出超过200个脑细胞簇和神经通路,并利用8种化学标记区分不同细胞类型,提供了对该关键脑区前所未有的清晰描绘。
  • 填补关键空白:脑干虽体积小,却控制呼吸、心跳、睡眠等基本生命功能。其结构密集复杂,此前始终缺乏详细的测绘。该图谱旨在填补这一神经科学的重大空白。

革命性意义:连接宏观与微观

  • 融合两大领域:Anchor的核心创新在于将传统的医学成像(如MRI,展示大脑整体结构)与细胞病理学(揭示单个细胞)这两个长期分离的世界连接起来。
  • 无缝导航:用户可以从MRI扫描看到的整体脑干,无缝放大到单个神经元,并始终维持其精确的空间位置关系。这解决了病理学家以往只能检查少量组织样本、无法窥见器官全貌的局限。
  • 开放获取:该图谱已在线免费公开,旨在成为全球神经科学家、神经学家和神经外科医生的参考工具。

潜在应用与未来展望

  • 疾病研究:通过对比健康与病变组织的图谱,有望更深入地理解帕金森病、中风、阿尔茨海默病乃至婴儿猝死综合征等疾病的机制。
  • 临床辅助:为神经外科医生在脑干这一极度敏感的区域进行手术提供更精确的导航,提升安全性。中风案例的分析表明,它甚至有助于识别虽已受损但尚未不可挽回的脑组织。
  • 方法优势:该方法利用死后脑组织薄片的高分辨率图像,实现了经济可行的细胞级别详细测绘,使得大规模绘制成为可能。
  • 后续计划:团队计划未来拍摄超过100个完整人脑,覆盖不同生命阶段和神经系统疾病(包括阿尔茨海默病和痴呆),构建一个能够揭示疾病如何逐个细胞重塑大脑的参考库。

结论 Anchor图谱本身或许无法解开人脑的所有谜题,但通过提供一幅远为详尽的地图,它有望帮助科学家提出并最终回答更关键的问题。该项目也体现了现代神经科学日益依赖工程技术与计算方法的趋势。

21. Linux 0.11 rewritten in idiomatic Rust, boots in QEMU (github.com)

linux-0.11-rs 是一项用现代 Rust 从零重写的 Linux 0.11 内核项目。它在保留原版系统语义的前提下,利用强类型、清晰模块边界与地道抽象重新组织代码,可在 QEMU 模拟的 i386 硬件上启动,并运行自托管的 Unix 风格用户态(init → shell → coreutils)。

核心功能

内核层面 复现了 Linux 0.11 的主要能力,包括进程管理、支持按需分页与写时复制(CoW)fork 的虚拟内存、Minix v1 文件系统、ATA 磁盘驱动、VGA/PS/2 控制台、8250 串口控制台、TTY 层、信号机制以及完整的系统调用表。

用户空间 提供 user_lib 库,其公开 API 模拟 Rust 标准库的 std::{fs, io, path, env, process, time},使上层程序像普通 Rust 代码一样编写,无需直接进行系统调用封装。用户态包含 80 余个 coreutils 与一个手写 POSIX 子集 shell(sh),支持管道、控制流、函数、通配符、命令/算术替换、交互式行编辑、Tab 补全及历史记录。

构建与配套工具 通过 tools/build-disk.sh 可一键编译所有用户程序,按 Unix 风格布局 /etc/dev/bin 等目录并打包为可启动磁盘镜像。独立的 mbrkitminiximg crate 分别用于处理 MBR 与 Minix v1 镜像,亦可单独用于其他项目。

开发、测试与仓库结构

项目内置 Devcontainer 配置,可在 VS Code 中直接打开容器化环境运行 make run。外部开发需 Rust nightly(由 rust-toolchain.toml 固定)、qemu-system-i386 与 x86 交叉工具链,并可通过 tools/install-tools.sh 安装本地工具。

端到端测试由 ktest 框架驱动 QEMU 串口控制台,使用 .ktest 脚本执行;支持运行全部用例、仅运行指定套件或单测,并可选复用同一 QEMU 实例跳过重启。

仓库主要目录包括:kernel/(内核)、user_lib/user_lib_macros/(用户空间库及其过程宏)、user_program/(coreutils 与 shell)、ktest/(测试运行器)、mbrkit/miniximg/(镜像处理工具)、tools/(开发脚本)、tutorial/(mdbook 教程,初稿)以及 rootfs/(磁盘镜像内容模板)。

项目状态

内核相对于 Linux 0.11 已实质性功能完备(软盘支持除外),主要工作转向打磨与工具链完善;用户库已覆盖 shell 与 coreutils 的当前需求;用户态可支持真实交互使用。长期计划是完成一份从零构建的完整 mdbook 教程。

22. Germany set to restrict its Freedom of Information Act (www.dw.com)

德国议会夏季休会前批准了一系列改革,其中一项对现行《信息自由法》(IFG)的大幅修改引发巨大争议。该法自2006年生效,赋予每个人获取联邦机构官方信息的权利,是记者、环保组织等要求政府快速、免费提供数据的关键法律依据(情报等安全信息除外)。

执政的联盟党(基民盟/基社盟)与社民党认为,在网络威胁时代,政府数据需高度保密。其计划的核心限制包括:可能将申请权仅限于“自然人”,排除协会或组织;大幅提高申请费用;为保护公务员免受“敌意和威胁”,未来可隐去其姓名;更受争议的是,政府正研究将此权利仅限于“德国公民和居住在德国的欧盟公民”的合法性,并对涉及关键基础设施、反间谍和反恐等领域的信息实行更严格保护。

此举被批评为以安全为名,实质削弱政府透明度。反对党绿党议员指责这是“对来之不易的公民权利的严重倒退”。包括国际特赦组织、绿色和平、透明国际在内的110个民间组织联名呼吁政府停止计划,指出这些措施将“实质上废除信息自由”。绿色和平组织专家警告,这将妨碍监督和公众参与,损害对气候保护等项目的信任。

批评声浪甚至出现在执政联盟内部。社民党在联邦议院相关委员会的专家发表联合声明,称“绝不允许削弱公民、媒体和民间社会现有的信息获取权”,并明确表示社民党议会党团不会批准任何废除现行透明度水平的改革。

文章援引数据显示,2015年至2022年间,德国当局共收到约10.5万份信息申请,其中大多数获批,仅约1.62万份被部分拒绝,约9000份被完全拒绝。批评者担忧,拟议的改革可能会逆转这一趋势。

23. Linux on the Sega 32X. Who needs hardware synchronization primitives anyway? (cakehonolulu.github.io)

本文记录了作者在世嘉32X游戏机附加模块上成功移植并运行Linux操作系统的详细过程。

作者动机与背景 作者旨在通过此类项目提升底层硬件移植技能。其兴趣源于早期在联发科处理器手机上逆向工程并成功运行Android 5.0的经历,享受从硬件文档研究到系统启动的全过程。

世嘉32X硬件挑战 世嘉32X作为世嘉MD/Genesis的附加模块,硬件规格显著高于基础主机:

  • CPU:搭载两颗日立SH2 32位处理器(23MHz),而基础主机仅有一颗摩托罗拉68000(7.6MHz)。
  • 内存:系统RAM仅256KB(附加模块)加主机的64KB,视频RAM为256KB。有限的内存是移植的首要障碍。

移植解决方案

  1. 内存扩展:利用Krikkz公司的闪存卡,通过配置将ROM空间映射为可写入的RAM,从而获得总共约4MB的内存。作者将其中一部分(约540KB)保留用于存放Linux内核及initramfs二进制文件,其余用作RAM。
  2. 编译与初始化
    • 构建了SH2交叉编译器。
    • 解决了编译器内部错误。
    • 编写了早期串口驱动,通过基础主机(68000)的UART输出调试信息。
    • 修复了内核中ashlsi3ashrsi3等辅助函数的寄存器使用错误,以及checksum.S中的非法指令问题。
    • 为SH2的自由运行定时器编写驱动以完成时钟校准。
    • 使用ELF FDPIC格式构建根文件系统,并借助musl工具链简化工作。

实现对称多处理 在单核Linux运行成功后,作者进一步尝试启用双SH2处理器的SMP支持。主要难点在于硬件缺乏同步原语和缓存一致性:

  • 软件同步:借鉴SPARC32的经验,使用Peterson算法纯软件实现cmpxchg等原子操作所需的同步原语。
  • 缓存一致性:通过禁用缓存或使用非缓存映射来存储同步变量,避免数据过时问题。
  • CPU识别与中断
    • 利用SH2的硬件除法寄存器作为CPU标识符。
    • 扩展68000的功能,使其作为总线仲裁器和中断路由器,负责将核间中断路由到指定的SH2处理器。
  • 尽管性能不佳(存在严重的总线争用),但最终成功启动了第二个CPU,实现了SMP。

总结与资源 项目整体面临内存极小、缺乏硬件同步支持等挑战,但通过创新的软件方案得以克服。作者已公开相关的内核配置文件、Busybox配置和初始化脚本,供他人参考。

24. The infinite scroll may become endangered if controversial Calif. law passes (www.sfgate.com)

加州众议员Josh Lowenthal提出的AB 1709法案旨在限制社交媒体对青少年的成瘾性设计。该法案最初提议直接禁止16岁以下儿童使用具有“危险成瘾性设计”的社交平台,但经过立法辩论后进行了重大修订。

修订后的法案转而要求包括Meta和Reddit在内的科技公司,为未成年用户提供一个替代性的、成瘾性较低的信息流界面。若公司未能在2028年前做到这一点,则16岁以下的用户将无法在其平台注册账号。法案将“成瘾性功能”定义为“旨在最大化用户参与度、可预见地会导致强迫性使用的心理剥削性功能”,具体范围包括“成瘾性信息流”、“自动播放”以及由州总检察长认定的其他功能。

立法过程考虑了多项批评意见:直接禁令可能孤立青少年(尤其是性少数群体),年龄验证可能侵犯数据隐私,并可能触及言论自由问题。因此,法案将责任重心从用户转向了科技公司,要求其移除相关成瘾性功能。科技游说团体TechNet表示欣赏这些修订。

支持者认为,此举能保护青少年免受算法推送、无限滚动等设计的伤害,而美国在此方面立法滞后。目前,该法案已提交至加州参议院拨款委员会进行进一步审查。

25. Just Let Me Write Digits (gendx.dev)

瑞士政府登录系统AGOV(自2024年起部署,已拥有160万账户,用于申请失业保险、报税、苏黎世公民身份申请等)出现了一个严重的无障碍性缺陷。作者在注册时无法输入6位邮箱验证码。

问题现象:验证输入框为6个独立的文本框,但输入数字后焦点不会自动跳至下一框,且已输入的数字会变红报错。手动切换焦点后,表单仍提示“字段必填”错误。作者尝试了多种浏览器(Firefox、Chromium、Chrome、Safari)与操作系统(Linux、macOS)组合,问题依旧,仅在使用英文键盘布局的工作电脑上成功。

排查与发现

  1. 支持渠道失效:官方支持仅通过网络表单提供,而提交表单本身需要先通过此验证,形成“死循环”。
  2. 代码调查:由于源代码按法律要求将于2026年底才发布,作者只能分析已部署的压缩代码。通过搜索关键字符串,定位到处理键盘事件的JavaScript函数。
  3. 根本原因:该函数错误地将“Shift”键识别为修饰键而直接忽略其后续键入。作者使用的是法语AZERTY键盘布局,其数字键位于Shift层(需按Shift+数字键组合才能输入数字)。因此,在这种布局下输入任何数字都会被拦截,导致无法填写验证码。
  4. 验证与解决:切换至英语QWERTY或瑞士法语QWERTZ键盘布局(数字键无需Shift)后,问题消失。

系统设计缺陷反思

  • UI与逻辑实现:使用复杂的多输入框和纯JavaScript键盘事件拦截,而非单一原生输入框配合CSS样式,导致了脆弱性和不可访问性。
  • 支持系统设计:将唯一的用户支持渠道(工单系统)的访问权限与存在故障的登录流程绑定,无法接收问题反馈。
  • 身份验证问题:注册过程仅验证邮箱存在性和第二因素设备(安全密钥或官方APP),并不验证用户填写的姓名、生日等身份信息的真实性,引发了作者对系统威胁模型和实用性的质疑。
  • 开源与透明度:系统在被强制部署使用前,其源代码未按承诺提前公开,阻碍了用户自行排查问题。

此事件凸显了在政府关键数字服务中,对国际化键盘布局支持不足以及系统设计缺乏韧性所带来的严重问题。

26. Show HN: I implemented a neural network in SQL (github.com)

An experiment to query Xarray datasets with SQL. Contribute to xqlsystems/xarray-sql development by creating an account on GitHub.

27. Show HN: YouTube Guitar Tab Parser (github.com)

YouTube吉他谱解析器

一个命令行工具,可将YouTube吉他教学视频转换为PDF格式的吉他谱。

主要功能

通过以下流程将视频教程转为PDF:

  1. 下载视频:使用yt-dlp下载指定YouTube视频。
  2. 提取帧:使用ffmpeg按设定的时间间隔(默认2秒)提取视频帧。
  3. 定位谱面区域
    • 在采样的几帧(默认6帧)上绘制网格,并使用Claude视觉模型识别谱面所在的行列区域,通过取各样本的中位数得到粗略定位框。
    • 然后通过图像掩码(基于乐谱通常为浅色背景上的深色内容)将裁剪框精确对齐到谱面的纸张边缘。
  4. 裁剪与去重
    • 将每一帧精确裁剪到定位出的谱面区域。
    • 进行两阶段去重以提高效率:首先使用感知哈希快速去除高度相似的连续帧;然后使用Claude模型读取每行开头的小节编号,仅保留每个小节编号首次出现的清晰谱面图像,自动丢弃非谱面内容(如标题卡、介绍部分)。
  5. 生成PDF:将去重后按视频顺序排列的谱面图像垂直拼接,输出为A4尺寸的PDF文件。视频标题会作为文件名、首页标题和PDF文档元数据。

使用示例

从“Game of Thrones - Guitar Lesson + TAB”视频生成的PDF已包含在示例中。

环境与配置要求

  • 系统要求:Node.js ≥ 20,需要在系统PATH中安装yt-dlpffmpeg
  • API密钥:需要Anthropic API密钥。
  • 安装:克隆仓库后执行npm installnpm run build,并配置.env文件。
  • 使用:基本命令格式为node dist/cli.js "<视频URL>"。结果输出到out/<视频标题>.pdf

可配置选项

提供多个可选参数以控制行为,例如:

  • --interval:截图间隔(秒)。
  • --model:指定Claude视觉模型。
  • --sample:用于区域检测的采样帧数。
  • --dedup-threshold:感知哈希的预去重汉明距离阈值。
  • --max-height:限制下载视频的分辨率(默认720p)。
  • --keep-temp:保留中间生成的帧和裁剪图像。

所有选项均有合理默认值,通常只需提供视频URL即可运行。