2025-11-05

纽约市 mayoral 大选结果：Zohran Mamdani 胜出，并对特朗普发出挑战

概述:

2025年11月4日，民主党人Zohran Mamdani 赢得了纽约市市长选举，击败了前州长Andrew Cuomo，Curtis Sliwa （共和党候选人）落后。Mamdani 的胜利标志着纽约市政治格局的重大转变，他以民主社会主义者的身份，获得了进步派的支持，但也引发了前总统Donald Trump 和部分民主党温和派的强烈反对。

关键细节:

• **选举结果：**Mamdani 以大约 9 个百分点的优势击败了 Cuomo，Sliwa 远落后。前市长 Eric Adams 曾在九月份退出竞选，并支持 Cuomo。
• **胜利演讲：**Mamdani 在胜选演讲中将自己定位为特朗普的直接对立面，并呼吁纽约市成为“政治黑暗中的光明”。他发表了具有挑战性的言辞，直接向特朗普喊话，并表示他的胜利不仅能阻止特朗普，也能阻止未来的类似人物。
• **政策主张：**Mamdani 承诺将推出自 Fiorello LaGuardia 时代以来，纽约市最雄心勃勃的议程，包括冻结受租户的租金、实施全民儿童保育、创建免费公交计划以及启动城市运营的杂货店。
• **政治生涯：**Mamdani 从一位鲜为人知的州议员迅速崛起，成为纽约市的领导者，他击败了纽约政治世家的一位继承人。
• **选民构成：**Mamdani 在各个种族群体中都赢得了支持，特别是年轻选民（45岁以下），对 Cuomo 的支持率高出 43 个百分点。教育背景也是一个重要因素。
• **争议话题：**Mamdani 对巴勒斯坦的积极倡导成为竞选中的一个关键议题。犹太选民以 60%对31% 的比率支持 Cuomo。
• **特朗普的介入：**特朗普在选举前夕公开支持 Cuomo，试图将 Sliwa 的选票转移给 Cuomo，从而削弱 Mamdani 的优势。
• **Cuomo 的态度：**Cuomo 在败选后感谢了多位支持者，并表示这次竞选是为了挑战民主党未来的哲学。

影响:

Mamdani 的胜利预计将对纽约市和全国产生影响。他的崛起将为其他民主党人提供借鉴，了解如何在社会媒体上进行有效沟通，以及如何关注可负担性问题。与此同时，共和党可能会将 Mamdani 的左翼政策作为在其他地区的竞争性选举中的一个议题。

总结:

Zohran Mamdani 的纽约市市长选举胜利，标志着纽约市政治版图的重大变化。他以进步主义者的政策和对特朗普的直接挑战，赢得了年轻选民和多元化选民的广泛支持。他的未来执政将面临着团结 Albany 和市议会、推进其雄心勃勃议程的挑战，同时也将对全国范围内的政治格局产生影响。

总结：对 Excel 中 Copilot 的担忧

这段 TikTok 内容（作者 Ada James，@belligerentbarbies）表达了对将 Copilot 集成到 Excel 中的担忧。主要观点如下：

• Brenda 的重要性： 视频强调了“Brenda”这一角色——存在于每个企业财务部门的、经验丰富的普通员工——在现代经济中的核心作用。Brenda 掌握着 Excel，并凭借精湛的技能支撑着资本主义的运转。她能够熟练编写复杂的公式并生成财务报告。
• AI 的潜在风险： 视频担心，Copilot 的引入会导致管理者错误地认为 AI 比 Brenda 更聪明，从而直接使用 AI 修改 Brenda 编写的报告。
• AI 幻觉问题： 作者认为，AI（如 Copilot）可能会出现“幻觉”，产生错误的结果，而管理者由于自身对 Excel 的理解不足，无法识别这些错误。
• Brenda 的可靠性： 与 AI 相比，Brenda 的技能是可靠的，不会出现幻觉。视频暗示，依赖 Brenda 这种经验丰富的员工，比依赖可能出错的 AI 更为安全可靠。

总而言之，这段内容的核心是担忧 AI 在 Excel 中的应用，认为它可能会取代或贬低经验丰富的财务人员（如 Brenda），并造成因 AI 错误而带来的潜在问题。

OpenPCC 概要

OpenPCC 是一个开源框架，旨在实现可证明的私有 AI 推理，灵感来自 Apple 的 Private Cloud Compute，但完全开放、可审计，且可在您自己的基础设施上部署。它允许用户运行开源或自定义 AI 模型，而无需暴露提示、输出或日志，通过加密流、硬件认证和不可链接请求来强制隐私。

OpenPCC 的设计目标是成为 AI 数据隐私的透明、社区管理的标准。

主要特点：

• 可证明的隐私: 使用加密流、硬件认证和不可链接请求来保护 AI 推理过程中的数据隐私。
• 开放和可审计: 框架完全开源，允许社区进行审查和贡献。
• 灵活部署: 可以在用户自己的基础设施上部署。
• 支持多种模型: 支持开源和自定义 AI 模型。
• 透明度: 旨在成为 AI 数据隐私的透明标准。

相关资源：

• Whitepaper: https://github.com/openpcc/openpcc/blob/main/whitepaper/openpcc.pdf

Managed Service (托管服务)

Confident Security 提供基于 OpenPCC 标准的完全托管服务，名为 CONFSEC。 更多信息和注册请访问：https://confident.security

OpenPCC Client (客户端)

该仓库包含 OpenPCC 兼容的 Go 客户端代码，以及用作 Python 和 JavaScript 客户端基础的 C 库。还包含一些内存服务，可用于测试客户端。

OpenPCC Compute Node (计算节点)

计算节点的实现请参考：https://github.com/confidentsecurity/confidentcompute

Go Usage (Go 使用示例)

cmd/test-client/main.go 文件包含一个本地开发示例。 连接到生产服务时，代码示例如下：

import (
    "context"
    "fmt"
    "net/http"
    "os"
    "strings"

    "github.com/openpcc/openpcc"
    "github.com/openpcc/openpcc/inttest"
    "github.com/openpcc/openpcc/transparency"
)

func makePCCRequest() error {
    // ... (省略部分代码) ...

    // 示例请求体，使用 OpenAI API generate 格式
    body := "{\"model\":\"qwen3:1.7b\",\"prompt\":\"why is the sky blue?\"}"

    // 添加标签，将请求路由到运行指定模型的计算节点
    req.Header.Add("X-Confsec-Node-Tags", "qwen3:1.7b")

    // ... (省略部分代码) ...
}

配置说明：

• APIURL: OpenPCC API 的 URL，例如 https://app.confident.security。
• APIKey: API 密钥，从环境变量 <APIKEY_ENV_VAR_NAME> 获取。
• TransparencyIdentityPolicy: 透明度身份策略，用于验证请求的来源。
• X-Confsec-Node-Tags: 请求头，用于将请求路由到特定计算节点。

Development (开发)

开发命令使用 Go 工具 mage 执行。

可以使用 go tool mage [cmd] 直接运行命令，也可以安装 mage 以减少按键次数：go install github.com/magefile/mage@latest

mage 会打印可用命令列表（命令源文件位于 /magefiles/\* 文件夹中）。

要使用内存服务进行开发测试，请运行 mage runMemServices 启动所有内存 OpenPCC 服务。 然后运行 mage runClient 发送测试请求。

iOS 26.2 将在日本开放第三方应用商店

核心要点： 苹果预计将在 12 月发布 iOS 26.2，该版本将允许日本用户安装第三方应用商店，例如 AltStore PAL 和 Epic Games。

详细信息：

• 首次测试： 开发人员已经收到了 iOS 26.2 的首个测试版，初步显示日本用户可以在其设备上安装第三方应用商店。
• 日本法律推动： 这一变化是由于 2024 年 6 月日本议会通过的法律，要求苹果允许第三方应用商店和支付提供商。该法律旨在限制苹果等大型科技公司的市场主导地位。
• 日本公平贸易委员会： 2025 年 8 月，日本公平贸易委员会发布了《移动软件竞争法指南》，进一步明确禁止平台运营商（如苹果和谷歌）阻止或限制第三方应用商店和支付系统的可用性。该指南将于 2025 年 12 月 18 日生效。
• Epic Games 计划： Epic Games 已经宣布计划在 2025 年底之前将 Fortnite 和其游戏商店平台带到日本的 iOS 设备上。
• 欧盟先行： 在 iOS 17.4 和 iPadOS 18 中，苹果已经允许欧盟地区的 iPhone 和 iPad 用户安装第三方应用商店，以遵守《数字市场法》。此前，仅限欧盟地区。
• 发布时间： iOS 26.2 预计将于 2025 年 12 月之间发布，时间可能在 12 月 9 日至 12 月 16 日之间。

其他相关新闻：

• 黑五促销： 苹果和各大零售商正在推出黑五促销活动，包括对 Disney+、Hulu、Apple TV+ 等流媒体服务的折扣，以及 AirPods、iPad 等 Apple 产品的优惠。
• iOS 27： iOS 27 预计将重点关注质量改进和新的 AI 功能。
• iOS 26.2 新功能： iOS 26.2 测试版还包含新的锁定屏幕时钟 Liquid Glass 滑块和 Apple Music 的离线歌词功能。
• CNN 退出 Apple News： CNN 已经从 Apple News 中撤出了其内容，双方正在就新的条款进行谈判。
• 可折叠 iPhone： 据报道，苹果的可折叠 iPhone 预计将于 2026 年推出，并且解决了折痕问题。

Nest Thermostat 自定义固件设置 (Nest Thermostat Firmware Setup) 总结

该项目旨在为 Nest Thermostat 设备提供自定义固件的刷写工具和固件，利用 OMAP DFU (设备固件更新) 接口。以下是主要内容：

警告：实验性软件

• 该项目处于 实验/测试阶段。
• 不建议在关键供暖或制冷需求的关键设备上使用此固件。刷写可能会损坏设备或导致意外行为。
• 仅在您有备用设备或能够承受设备失效的情况下再继续。

项目背景

• 开发者坦诚该项目是快速开发的，仍在进行中。
• 欢迎支持项目，可以通过 “Buy Me A Coffee” 链接进行捐赠，以支持代码维护和开发。
• 提供 自托管开源解决方案 (open-source-prototype 分支)，但建议谨慎使用，避免潜在的bug。
• 硬件方面，可以参考 https://sett.homes 获取 PCB 替换方案。

工作原理

• 自定义固件通过修改启动加载程序 (bootloader) 和内核 (kernel) 组件，将原本与 Nest/Google 服务器的通信流量重定向到指定的服务器。
• 该服务器托管了一个逆向工程的 Nest API 副本，使恒温器能够独立运行，并提供对设备数据和设置的完全控制。
• 恒温器认为它正在与官方 Nest 基础设施通信，实际上连接到 NoLongerEvil 平台。

快速上手步骤

1. 克隆仓库: git clone --recurse-submodules https://github.com/codykociemba/NoLongerEvil-Thermostat.git
2. 安装依赖:
   • Linux (Debian/Ubuntu): sudo apt-get update && sudo apt-get install build-essential libusb-1.0-0-dev gcc pkg-config
   • macOS: 安装 Xcode Command Line Tools 和 libusb (使用 Homebrew)。
3. 构建 omap_loader 工具: chmod +x build.sh && ./build.sh
4. 启动固件安装程序:
   • Linux/macOS: chmod +x install.sh && ./install.sh (macOS 可能需要授予 USB 权限)
5. 将 Nest 设备置于 DFU 模式:
   1. 确保设备电量充足 (至少 50%)。
   2. 从墙壁上取下恒温器。
   3. 使用 micro USB 数据线连接恒温器到电脑。
   4. 确保 install.sh 脚本正在运行。
   5. 按住显示屏 10-15 秒，直到设备重新启动。
6. 等待设备启动: 启动后，显示屏上会显示 NoLongerEvil 的 logo。
7. 注册账户: 在浏览器中访问 https://nolongerevil.com，注册或登录账户。
8. 链接设备: 在恒温器上获取条目码 (Settings → Nest App → Get Entry Code)，然后在 NoLongerEvil 仪表板上输入该代码。

刷写内容

• x-load.bin: 第一阶段启动加载程序 (X-Loader for OMAP)。
• u-boot.bin: 第二阶段启动加载程序 (Das U-Boot)。
• uImage: Linux 内核镜像。

安全考虑事项

• 仅在您拥有的设备上使用。
• 不正确的固件可能损坏设备。

致谢

• 感谢 grant-h / ajb142 的 omap_loader 工具。
• 感谢 exploiteers (GTVHacker) 的 Nest DFU 攻击研究。
• 感谢 FULU 以及所有支持 Nest 学习恒温器 Gen 1/2 赏金项目的人。

开源承诺

• 致力于透明度和设备维修权。
• 固件镜像和后端 API 服务器代码将很快开源。

适用设备

• 仅适用于 Nest 第一代和第二代恒温器 (背面有绿色气泡水平仪)。
• 不支持第三代设备 (背面为蓝色气泡水平仪)。

重要提示

• 刷写此固件后，设备将不再连接到 Nest/Google 服务器，而是连接到 NoLongerEvil 平台。

安娜档案：版权方发起的巨大清理行动仍无法阻止其存在

摘要：

安娜档案（Anna's Archive）是一个影子图书馆的元搜索引擎，允许用户搜索盗版书籍和其他相关资源。自 2022 年秋季推出以来，它迅速成为版权方的重点打击目标。

主要内容：

• 大规模的 URL 清理： 版权方，包括 Penguin Random House 和 John Wiley & Sons 等出版商，已要求 Google 从搜索结果中移除安娜档案的 7.49 亿个 URL，占 Google 历史上所有 URL 清理的 5%。
• 持续的运营： 尽管面临法律压力和大规模的 URL 清理，安娜档案（包括 .org、.li 和 .se 域名）仍然在运营。
• 对 AI 领域的影响： 安娜档案积极为希望利用其图书馆进行模型训练的 AI 研究人员提供支持，并呼吁对版权进行改革以保护国家安全。
• 打击策略： 由于无法直接针对安娜档案，版权方通过 Google 等第三方中介机构发起清理行动，试图降低其在搜索结果中的可见度。
• 清理规模： 安娜档案的清理规模远远超过了像 The Pirate Bay 这样的盗版网站，每周新增的清理 URL 约为 1000 万。
• 效果有限： 尽管清理行动显著影响了安娜档案在 Google 搜索结果中的排名，但该网站仍然可以通过搜索其名称轻松找到。
• 法律诉讼： 安娜档案因从 WorldCat 抓取数据而被美国起诉。

总而言之， 版权方正在对安娜档案发起一场大规模的清理行动，但该网站仍然能够生存并保持一定程度的可访问性，这表明清理行动的效果有限。

YouTube 平台简介总结 (YouTube Platform Summary)

YouTube 是一款视频和音乐平台，用户可以在此观看、上传和分享内容。 总结如下：

• 核心功能: 允许用户观看喜爱的视频和音乐，上传原创内容，并与朋友、家人以及全球用户分享。
• 关键链接: 平台提供了多个关键链接，方便用户了解更多信息：
  • 关于 (About): 提供平台相关信息。
  • 新闻 (Press): 提供新闻稿和媒体资源。
  • 版权 (Copyright): 关于版权相关政策。
  • 联系我们 (Contact us): 用户可以联系平台获取支持。
  • 创作者 (Creators): 针对内容创作者的服务和资源。
  • 广告 (Advertise): 广告投放信息。
  • 开发者 (Developers): 面向开发者的 API 和工具。
  • 条款 (Terms): 平台使用条款。
  • 隐私 (Privacy): 隐私政策。
  • 政策与安全 (Policy & Safety): 平台政策和安全措施。
  • YouTube 工作原理 (How YouTube works): 详细解释平台运作方式。
  • 测试新功能 (Test new features): 允许用户参与新功能测试。
  • NFL Sunday Ticket: 提供 NFL Sunday Ticket 服务信息。
• 版权信息: © 2025 Google LLC，表明该平台由 Google LLC 拥有。

总而言之，YouTube 是一个由 Google LLC 运营的，旨在为用户提供观看、上传和分享视频及音乐内容的平台，并提供丰富的资源和信息链接。

pg_lake: PostgreSQL 与数据湖集成

pg_lake 将 Iceberg 和数据湖文件集成到 PostgreSQL 中。通过 pg_lake 扩展，您可以将 PostgreSQL 作为独立的湖仓系统使用，支持 Iceberg 表的事务和快速查询，并可以直接处理对象存储（例如 S3）中的原始数据文件。

主要功能：

• 创建和修改 Iceberg 表： 直接从 PostgreSQL 创建和修改 Iceberg 表，并提供完整的事务保证，可以从其他引擎查询这些表。
• 查询和导入数据文件： 在对象存储中查询和导入 Parquet、CSV、JSON 和 Iceberg 格式的数据文件。
• 导出查询结果： 使用 COPY 命令将查询结果导出回对象存储，格式为 Parquet、CSV 或 JSON。
• 读取地理空间格式： 支持 GDAL 提供的地理空间格式，如 GeoJSON 和 Shapefile。
• 使用内置的 map 类型： 用于半结构化或键值数据。
• 混合查询： 在同一 SQL 查询和修改中组合堆、Iceberg 和外部 Parquet/CSV/JSON 文件，并提供完整的事务保证，且没有 SQL 限制。
• 自动推断类型： 从外部数据源（如 Iceberg、Parquet、JSON 和 CSV 文件）自动推断表列和类型。
• 利用 DuckDB 查询引擎： 在 PostgreSQL 中实现快速执行，无需离开 PostgreSQL。

设置 pg_lake：

有两种设置 pg_lake 的方法：

• 使用 Docker： 适用于简单的、开箱即用的测试环境。
• 从源代码构建： 适用于手动设置或开发使用。

两种方法都包含 PostgreSQL 扩展、pgduck_server 应用程序以及设置 S3 兼容存储。

使用 pg_lake：

• 创建 Iceberg 表： 使用 USING iceberg 在 CREATE TABLE 语句中创建 Iceberg 表。
• COPY 命令： 使用 COPY 命令在 Parquet、CSV 或 JSON 格式之间导入或导出数据。
• 创建外部表： 可以直接从文件或文件集合创建外部表，无需指定列名或类型。

架构：

pg_lake 实例包含两个主要组件：PostgreSQL 与 pg_lake 扩展 和 pgduck_server。

用户连接到 PostgreSQL 以运行 SQL 查询，pg_lake 扩展与 PostgreSQL 的钩子集成，以处理查询计划、事务边界和执行的整体编排。

在底层，查询执行的 部分 通过 pgduck_server 委托给 DuckDB。 pgduck_server 是一个独立的、多线程的进程，它实现了 PostgreSQL 协议（本地），并在其下方使用 DuckDB 执行查询。

主要组件：

• pg_lake_iceberg： 实现 Iceberg 规范的 PostgreSQL 扩展。
• pg_lake_table： 实现外部数据封装器，用于查询对象存储中的文件的 PostgreSQL 扩展。
• pg_lake_copy： 实现 COPY 到/从数据湖的 PostgreSQL 扩展。
• pg_lake_engine： 不同的 pg_lake 扩展的通用模块。
• pg_extension_base： 其他扩展的基础构建块。
• pg_extension_updater： 用于在启动时更新所有扩展的扩展。
• pg_lake_benchmark： 用于在湖表上执行各种基准测试的 PostgreSQL 扩展。
• pg_map： 通用的地图类型生成器。
• pgduck_server： 一个独立服务器，将 DuckDB 加载到同一服务器机器上，并通过 PostgreSQL 协议暴露 DuckDB。
• duckdb_pglake： 添加缺失的 PostgreSQL 函数到 DuckDB 的 DuckDB 扩展。

历史：

pg_lake 的开发始于 2024 年初，目标是将 Iceberg 引入 PostgreSQL。 随后，Snowflake 收购了 Crunchy Data，Snowflake 决定将该项目作为 pg_lake 开源。

文档：

完整项目文档可在 docs 目录中找到。

许可证：

版权所有 (c) Snowflake Inc. 保留所有权利

FuzzyGraph：一种非二元方程可视化方法总结

本文介绍了FuzzyGraph，一种新的方程可视化方法，它与传统的“二元模式”图表不同，后者仅显示方程精确相等的位置。FuzzyGraph 采用“模糊/非二元模式”，显示方程精确相等、接近相等和远离相等（误差高）的位置，从而揭示了传统图表无法看到的数学“阴影”。

核心概念：

• 二元模式 (Binary Mode): 传统图表，仅显示方程精确相等的区域，其余区域空白。
• 模糊模式 (Fuzzy/Non-Binary Mode): FuzzyGraph 采用的模式，显示方程误差的大小，揭示隐藏的数学细节。
• 阴影 (Shadows): 在 FuzzyGraph 中可见的，传统图表中不可见的区域，代表高误差区域或接近解的区域。

示例：

文章通过几个示例展示了 FuzzyGraph 的优势：

• Slash Dot Equation: FuzzyGraph 显示了一个传统图表无法看到的“黑洞”，代表高误差区域。
• Quasar Equation: FuzzyGraph 揭示了传统图表隐藏的“眼睛”形状特征。
• 简单星和黑洞: 通过对比 \( x^2 + y^2 = 0 \) 的传统图表（单个点）和 FuzzyGraph (模糊粒子) 展示了 FuzzyGraph 可以显示更丰富的细节。
• Shadow Line: 通过组合和反转两条直线方程，展示了如何产生“阴影线”，并说明 FuzzyGraph 比传统图表更准确地可视化该方程。
• Phi Equation: 通过将圆和直线方程结合并反转圆的方程，展示了“阴影圆”在传统图表中不可见。
• Underwater Islands: 揭示了低误差区域，即接近解的区域，这些区域在传统图表中不可见，但在 FuzzyGraph 中表现为“水下岛屿”。通过微调方程，可以使这些水下岛屿浮出水面，在传统图表中可见。

技术细节：

• FuzzyGraph 的计算方法是对方程进行修改，计算 \( |left-right|^{fuzzyLevel} \)，生成误差图。
• 作者认为，传统图表也对方程进行修改，其逻辑类似于 "如果方程左侧等于右侧，则绘制黑色；否则绘制白色"。

总结:

FuzzyGraph 是一种强大的工具，它通过非二元模式可视化方程，揭示了传统图表无法看到的数学细节，为数学研究和可视化提供了新的视角。它不仅仅是一个方程的图表，更是一个“误差分歧图”的热图。

https://news.ycombinator.com/item?id=45823234

美国国税局终止“Direct File”免费在线报税服务

主要内容：

美国国税局（IRS）已通知25个州，其免费在线报税服务“Direct File”将在2026年的报税季不再可用。该服务于2024年首次推出，允许纳税人直接向IRS在线提交税表，受到了大量用户的好评。

关键细节：

• 服务终止： IRS在发送给各州的邮件中表示，“Direct File”将在2026年的报税季停止服务，目前尚未确定未来重启日期。
• 用户反馈： 2024年和2025年，超过29.6万用户使用了“Direct File”，并对其给予了高度评价。
• 反对声音： 共和党和商业税务准备公司长期以来反对“Direct File”的继续实施，并进行了游说活动。
• 政策背景： 特朗普政府通过的税收和支出政策法案，要求IRS成立任务小组，探索通过公私合作的方式替代“Direct File”。
• Free File计划： IRS长期依赖名为“Free File”的公私合作计划，为大多数美国人提供免费报税方式，但该计划的利用率一直很低，只有3%的符合条件的纳税人使用。一些参与公司被发现有引导用户购买付费产品的行为。
• 各方反应：
  • 经济安全项目副总裁Adam Ruben： 指责特朗普政府在税务准备公司游说的推动下破坏了“Direct File”。
  • 参议员Elizabeth Warren： 表示斗争并未结束，大型税务准备公司庆祝，而美国纳税人将不得不花费更多的时间和金钱来报税。
• IRS： 未对评论请求做出回应。

总结：

“Direct File”的终止标志着IRS在免费在线报税服务上的政策转变，也反映了来自政治和商业利益的压力。尽管该服务受到用户欢迎，但由于政策变化和利益集团的游说，其未来面临不确定性。IRS正在探索新的公私合作模式来替代“Direct File”，但这一转变可能对美国纳税人的报税成本和便利性产生影响。

美国国税局终止“Direct File”免费在线报税服务

核心内容：

美国国税局（IRS）宣布其免费在线报税服务“Direct File”将于2026年报税季停止服务，此前该服务在2024年首次推出，并受到用户好评。

关键信息：

• 服务终止时间： 2026年报税季起，“Direct File”服务将不再可用。
• 用户数量及满意度： 2024年和2025年，超过29.6万用户使用该服务，并给予了积极评价。
• 反对声音： 共和党议员和商业税务准备公司一直反对“Direct File”的实施。
• 政策背景： 特朗普政府的新法案要求IRS探索以公私合作模式替代“Direct File”。
• Free File计划： IRS长期依赖“Free File”计划提供免费报税服务，但利用率低，仅3%的符合条件纳税人使用。部分参与公司被指责误导用户购买付费产品。
• 各方评论：
  • Adam Ruben（经济安全项目）： 批评特朗普政府在税务准备公司游说的影响下破坏了“Direct File”。
  • Elizabeth Warren参议员： 表示将继续争取，并认为大型税务准备公司获利，而美国纳税人将承担更多报税成本。
• IRS： 未就此事发表评论。

总结：

“Direct File”的终止反映了IRS在免费在线报税服务上的政策调整，以及来自政治和商业利益的压力。尽管该服务受到用户欢迎，但未来面临不确定性。IRS正在寻求新的公私合作模式，这可能会影响美国纳税人的报税成本和便利性。

微软承认无法完全保护欧盟数据免受美国监控 - 法国参议院调查揭示

主要内容：

微软法国公共与法律事务主管安东·卡尼奥在法国参议院关于公共采购在促进数字主权中的作用的调查听证会上，承认无法保证法国公民数据在未经法国明确授权的情况下永远不会被传输给美国当局。

关键细节：

• 无法保证： 卡尼奥明确表示，他无法保证法国公民数据不会被传输给美国当局。
• 美国《云法》： 他解释说，根据美国的《云法》，美国公司即使数据存储在其他国家（例如欧盟），也可能被迫向美国政府提供数据。即使数据存储在欧盟或英国服务器上，或者存在 “受信任的合作伙伴关系”，这些都无法改变这种现实。
• 从未发生： 卡尼奥声称这种情况尚未发生。
• 项目“Bleu”： 调查围绕微软、Orange 和 Capgemini 之间的合作项目“Bleu”展开。参议院成员对医疗研究平台“健康数据中心”（Health Data Hub），该平台托管在 Microsoft Azure 上，表示担忧，无法确定这两个平台是否足够隔离，以及敏感的医疗数据是否会被共享。
• 数据主权担忧： 卡尼奥的承认加剧了欧盟对依赖大型美国云服务提供商（如微软和 AWS）的担忧，即便他们声称提供主权云服务。
• 市场份额： 一份最近的欧洲议会报告显示，美国公司在欧洲云基础设施市场中占据 69% 的份额，而欧盟供应商仅占 13%。
• 行业呼吁： 云服务提供商 Civo 的首席执行官马克·布斯特评论称，法国参议院的行动为英国和欧洲提供了机会，也应追究问责。他认为，已经出现向构建本土解决方案，以支持真正的数据主权而非数据驻留的转变。

总结：

法国参议院的调查揭示了美国公司（如微软）在数据主权问题上的潜在风险。微软的承认表明，即使数据存储在欧洲，美国法律也可能强制其向美国政府提供数据。这引发了对欧盟过度依赖美国云服务提供商的担忧，并促使人们呼吁发展本土解决方案，以增强欧洲的数据主权。

XDP 用于外发流量：突破 Linux 的限制 (XDP for Egress Traffic: Breaking the Linux Limitation)

TL;DR: XDP (eXpress Data Path) 是 Linux 中最快的包处理框架，但仅适用于入站 (ingress) 流量。 Loophole Labs 发现了一种利用 Linux 内核确定数据包方向方式的漏洞，从而使 XDP 适用于外发 (egress) 流量。 这种技术比现有解决方案快 10 倍，与现有的 Docker/Kubernetes 容器兼容，并且无需修改内核。

背景

Loophole Labs 致力于实时迁移容器、虚拟机和网络连接。 为了实现跨云迁移速度达到数百 Gbps，需要能够以线速处理数据包。 XDP 是 Linux 中实现线速包处理的黄金标准，它在数据包到达网络驱动程序时就拦截数据包，从而实现大多数环境中的线速。 然而，XDP 的主要限制是它只能处理入站流量。

问题：XDP 的局限性

XDP 只能处理入站流量，这使得它在需要处理外发流量的网络环境中（例如 Loophole Labs 的网络平面，需要在同一计算节点上运行工作负载）无法使用。 现有的外发流量处理方法，如 Traffic Control (TC)，虽然基于 eBPF，但性能瓶颈明显，无法满足 Loophole Labs 的需求。 TC 运行在网络堆栈的后期阶段，导致 CPU 周期浪费。 此外，TC 使用 socket buffers (struct sk_buff)，这些 buffers 的分配和内存复制会带来额外的性能开销。

解决方案：利用 veth 接口

Loophole Labs 的工程师深入研究了 Linux 内核源代码，发现了一个关键的漏洞：Linux 内核并非真正地对包进行分类，而是基于数据包到达物理网络接口时写入 RX 环形缓冲区的方式来确定数据包的方向。

他们利用了 Virtual Ethernet (veth) 接口的特性。 veth 接口是一对网络接口，它们之间形成一个直接的隧道。 当数据包通过 veth 对的一端传输时，只是将数据包的内存指针移动到另一端的 RX 队列中，因此从另一端的接口来看，数据包如同从物理网络接口接收一样，从而被视为入站流量，XDP 程序可以运行。

实现细节

1. 数据包流向： 数据包通过 veth 对的一端发送，另一端的接口将其视为入站流量。
2. XDP 程序运行： XDP 程序在 RX 队列上运行，可以对数据包进行检查、修改和重定向。
3. 绕过内核： 使用 XDP_REDIRECT 可以将数据包直接路由到物理接口的 TX 队列，从而绕过 Linux 内核的网络堆栈。
4. Checksum 和 ARP 解析： 由于绕过了内核，需要手动计算 checksum 并进行 ARP 解析。
5. Native XDP 驱动： 使用 Linux 4.19+ 引入的 Native XDP 驱动可以进一步提高性能。

性能测试

Loophole Labs 使用 iPerf3 在两台 200Gbps EC2 实例之间进行了性能测试，对比了以下三种路由策略：

• iptables（默认）
• Traffic Control (TC)
• XDP (使用 Native XDP 驱动)

测试结果表明，XDP 性能显著优于 iptables 和 TC，达到近线速（约 194Gbps），是 iptables 的 12.4 倍，是 TC 的 9.2 倍。

应用场景

• 容器网络加速： 通过 XDP 替代 iptables，实现容器网络吞吐量翻倍，降低 CPU 占用。
• Live Migration： Loophole Labs 利用该技术构建了 Architect 平台，实现跨云的实时迁移。

未来展望

Loophole Labs 计划开源 Docker 网络插件，方便用户在自己的基础设施上实现 XDP 外发流量处理。 同时也欢迎加入 Discord 社区，深入探讨技术细节。

纽约卡多佐高中智能手机禁令：变化与挑战

概述:

纽约市皇后区卡多佐高中在今年实施了智能手机禁令，旨在改善学习环境和促进学生之间的互动。该禁令是纽约州范围内一项更广泛的趋势，目前已有31个州及华盛顿特区实施了类似政策。

主要内容:

• 禁令内容: 禁止学生在学校期间使用所有具备上网功能的电子设备。但对残疾学生、英语学习者以及教师允许课堂使用的设备有例外。
• 执行方式: 卡多佐高中要求学生将手机放入具有磁性锁定的袋子中，其他学校则采取储物柜或将手机保存在背包中的方式。
• 学生反应:
  • 积极反馈: 许多学生认为禁令促进了学生之间的互动，结交了新朋友，并减少了学生用手机“躲避”社交的情况。
  • 消极反馈: 一些学生认为禁令侵犯了他们的权利，缺乏对学生的信任，并表达了对无法使用手机的不满。
• 教师和管理人员的看法: 教师普遍对禁令带来的积极影响表示满意，认为学生更专注、互动更多，课堂效率和参与度都提高了。数据显示，89%的学校教职员工认为新政策改善了学校环境，76%的人认为学生更积极参与课堂。
• 影响:
  • 学习方式转变: 学生被迫减少对人工智能工具的依赖，转而进行更深入的研究。
  • 阅读习惯改变: 更多学生开始阅读纸质书籍。
  • 社交方式回归: 纸质便条、棋牌游戏、甚至宝丽来相机等传统活动重新流行起来。
• 挑战:
  • 违规行为: 一些学生试图通过使用“备用”手机或破坏手机袋来规避禁令，学校每天查获约30部违规手机。
  • 管理问题: 学校采取了递进式的惩罚措施，包括没收手机，但不能因为违反禁令单独停课。
  • 基本技能缺失: 助理校长发现学生不识时钟，甚至考虑开设时钟教学课程。

总结:

卡多佐高中的智能手机禁令虽然面临一些挑战，但总体上带来了积极的变化，改善了课堂环境，促进了学生之间的交流和互动，并促使学生重新拾起传统学习方式和社交活动。然而，如何平衡学校管理与学生权利，以及如何帮助学生适应这种新的学习环境，仍然是需要持续关注的问题。

Windsurf Codemaps：AI驱动的代码理解工具 (Windsurf Codemaps: An AI-Powered Code Understanding Tool)

本文介绍了Cognition公司推出的Windsurf Codemaps，一种全新的AI驱动的代码理解工具，旨在帮助工程师更好地理解和掌控代码，而非简单地将代码编写任务外包给AI。

核心问题与解决方案：

• 问题： 现代代码库日益复杂，工程师在理解、查找和记忆代码方面花费大量时间，导致生产力下降。新手工程师需要3-9个月才能完全上手，资深工程师每周损失5小时以上用于他人入职。
• 传统AI工具的局限性： 现有的AI编码工具（如Copilot, Claude Code, Codex, Windsurf Cascade）主要通过聊天方式提供代码建议，未能有效解决代码理解和导航的问题。
• Windsurf Codemaps的解决方案： Codemaps通过AI生成结构化的代码地图，帮助工程师快速理解代码结构、数据流和依赖关系。它基于SWE-1.5和Claude Sonnet 4.5技术，提供“即时映射”功能，可以根据任务需求生成特定代码区域的地图。

Codemaps 的主要功能：

• 可视化地图： 生成可视化的代码地图，直观展示代码结构和关系。
• 可扩展的“Trace Guide”： 提供可展开的“Trace Guide”，对代码片段进行更详细的解释和说明。
• 与Cascade集成： 允许在Cascade中引用Codemaps，为AI提供更具体的上下文信息，从而提高代码生成和理解的准确性。
• 多种模型支持： 提供“快速” (SWE-1.5) 和 “智能” (Sonnet 4.5) 模型选择，以满足不同的需求。

核心理念：

• AI应增强而非取代工程师的能力： 强调AI工具应帮助工程师更好地理解代码，而不是简单地生成代码，从而提高工程师的责任感和对代码质量的掌控能力。
• 对抗“Vibeslop”： 警惕过度依赖AI生成代码，导致工程师对代码理解不足，最终降低代码质量。
• 工程师的角色转变： 从“代码编写者”转变为“代码责任人”，需要理解AI生成的代码，确保其安全可靠。

未来展望：

• 进一步探索Codemaps在提升Devin和Cascade等AI代码代理性能方面的潜力。
• 定义开放的.codemap协议，方便其他代码代理和工具使用。
• 探索Codemaps的连接和注释功能。

总结：

Windsurf Codemaps旨在通过AI辅助工程师理解代码，提升生产力，并确保代码质量。它强调了工程师在AI时代的重要性，即从代码编写者转变为代码责任人，确保对AI生成代码的理解和掌控。

总结：追寻TIFF发明者的故事 (Summary: The Story of Finding the TIFF Inventor)

本文讲述了作者John Buck为撰写《未来发明家》(Inventing the Future)一书，追寻音频文件格式AIFF和图像文件格式TIFF发明者的故事。作者花费超过10,000小时，通过访谈、查阅资料，力求还原发明过程的真相。

主要内容：

• AIFF的诞生: AIFF (Audio Interchange File Format) 由两位Apple程序员 Steve M. 和 Mark Lentczner 共同构建，旨在解决当时MIDI市场混乱的问题，并方便音乐工作者使用。该格式的开发工作得益于Apple Sound Chip和MIDI Manager的早期研究。
• 追溯TIFF的起源: 为了更深入地了解AIFF，作者追溯到其基础——TIFF (Tag Image File Format)。TIFF最初是为桌面出版物设计的图像标准，支持单色、灰度和彩色图像，并包含元数据。
• 寻找TIFF的创造者: 尽管AIFF的发明者相对容易找到，但TIFF的创造者却难以寻觅。作者发现，最初的搜索指向了公司Aldus，但无法找到具体的工程师姓名。
• 艰难的追踪过程: 作者历经数日，查阅了大量MacWeek的过往资料，最终找到了 Steve Carlson的名字。然而，由于拼写错误和信息不全，追踪过程异常艰难。作者最终通过下载TIFF规范文档，并使用搜索功能发现了Carlsen的名字。
• 联系与确认: 经过一系列尝试，作者通过邮寄信件最终联系到了Stephen Carlsen。Carlsen确认了自己是TIFF的创造者，并解释了其在Aldus推广TIFF标准的过程。
• 令人唏嘘的结局: 在作者完成书稿后两年，Carlsen的妻子 Peggy 告知作者，Carlsen已于今年过世。作者随后在维基百科上更新了TIFF的描述，将TIFF的创造者归功于 Stephen Carlsen，而非仅仅是公司 Aldus。
• 对创作者的致敬: 文章表达了对所有发明者的敬意，强调了追寻真相和致敬创造者的重要性。作者还推荐了Nathan Carlsen的播客节目“Inquisitive Pontification”，其中包含关于TIFF发明者家庭的访谈。

核心要点：

• 发明过程往往充满挑战和不确定性。
• 记录和致敬那些默默无闻的创造者至关重要。
• 即使在信息时代，寻找历史人物也需要耐心和细致的调查。
• 对历史真相的追求和尊重，是作者创作的动力源泉。

中文关键词: AIFF, TIFF, 发明者, 桌面出版, 图像文件格式, 苹果, Aldus, 历史, 研究, 采访

Carice TC2：100% 电动复古跑车

Carice TC2 是一款全新的 100% 电动汽车，设计灵感来源于经典的复古车型，旨在提供独特而愉悦的驾驶体验。目前已开放下一批次的预订，名额有限。

主要特点：

• 外观设计： Carice TC2 拥有醒目的外观，结合了复古风格与现代设计元素，极具辨识度。
• 轻量化车身： 车身重量仅为 590 公斤（包括电池），赋予其卓越的操控性和低能耗。
• 纯电动动力： 零排放，环保节能。
• 驾驶体验： 设计理念旨在简化驾驶，让驾驶者能够放松身心，享受纯粹的驾驶乐趣。
• 个性化定制： 提供多种颜色选择，包括车身、内饰和顶篷，可根据个人喜好进行定制。
• 工艺精湛： 由荷兰的汽车设计和开发团队打造，注重细节，追求卓越品质。

技术规格：

• 尺寸： 长度 3540 毫米，宽度 1580 毫米，高度 1220 毫米。
• 电池： 标准配置续航里程 200 公里，大容量电池续航里程 300 公里。充电至 80% 大约需要 2.7 小时。
• 驱动方式： 后轮驱动。
• 悬挂： 前悬挂采用双叉臂，后悬挂采用拖臂。
• 制动系统： 盘式制动，配备再生制动功能。

价格和交付：

• 起售价为 44,500 欧元（不含税），含 21% 荷兰增值税为 53,854 欧元。
• 目前生产批次已售罄，但仍有少量名额可供下一批次预订。
• 预订需要支付 75% 的购买价格作为定金。

适用地区：

符合欧洲法规，可在欧盟国家以及瑞士、英国、摩纳哥和挪威等采用欧洲法规的国家/地区行驶。

关于 Carice：

Carice 是一家总部位于荷兰的公司，由一群热爱经典汽车的人士创立。公司致力于将 21 世纪的技术与过去汽车的经典外观和感觉相结合，打造出独特而富有艺术感的电动汽车。 更多信息请访问 caricecars.com/blog。

Bluetui: Linux 蓝牙管理 TUI 总结

Bluetui 是一个基于 Linux 的终端用户界面 (TUI) 工具，用于管理蓝牙设备。以下是其主要功能和细节的总结：

功能概述:

Bluetui 旨在提供一个易于使用的 TUI 界面，方便用户管理 Linux 系统的蓝牙连接。它允许用户扫描、配对、连接、断开连接、信任和重命名蓝牙设备。

先决条件:

• 需要安装 Linux 操作系统。
• 需要安装 bluez 软件包，这是 Linux 系统上的蓝牙协议栈。
• 建议安装 Nerd Fonts 以正确显示图标。

安装方式:

Bluetui 提供了多种安装方式：

• 二进制发布: 从 GitHub 上的发布页面下载预编译的二进制文件。
• crates.io: 使用 Cargo 包管理器安装 bluetui (推荐): cargo install bluetui
• Arch Linux: 通过 extra 仓库安装: pacman -S bluetui
• Gentoo: 通过 lamdness Gentoo Overlay 安装。
• x-cmd: 使用 x-cmd 安装: x install bluetui
• 从源代码构建: 克隆 GitHub 仓库，然后使用 Cargo 构建: cargo build --release。构建后的可执行文件位于 target/release/bluetui。

使用方法:

Bluetui 提供了直观的键盘快捷键来控制蓝牙设备的各种操作：

• 全局操作:
  • Tab 或 l: 向下滚动不同部分。
  • Shift+Tab 或 h: 向上滚动不同部分。
  • j 或 Down: 向下滚动。
  • k 或 Up: 向上滚动。
  • s: 启动/停止扫描。
  • Ctrl+C 或 q: 退出应用程序。
• 适配器管理:
  • p: 启用/禁用配对。
  • o: 开启/关闭适配器电源。
  • d: 启用/禁用发现模式。
• 已配对设备管理:
  • u: 断开设备配对。
  • Space 或 Enter: 连接/断开设备连接。
  • t: 信任/取消信任设备。
  • e: 重命名设备。
• 新设备管理:
  • Space 或 Enter: 配对设备。

配置:

Bluetui 的配置信息存储在 $HOME/.config/bluetui/config.toml 文件中。用户可以自定义快捷键和布局。 可配置的选项包括：

• layout: 窗口布局方式，例如 "SpaceAround"、"SpaceBetween" 等。
• width: 窗口宽度，可以是 "auto" 或一个正整数。
• toggle_scanning: 扫描快捷键。
• esc_quit: 是否使用 Esc 键退出。
• 适配器和已配对设备的操作快捷键。

其他信息:

• Bluetui 的作者推荐使用 impala 来管理 WiFi 连接。
• Bluetui 使用 GPLv3 许可证。
• Bluetui 的 logo 由 Marco Bulgarelli 设计。

Radiant：重新构想个人计算的愿景 (Radiant: A Vision for Reimagining Personal Computing)

Radiant 旨在探索从“首要原则”出发，个人计算的全新可能性。该项目认为当前个人计算的发展趋势正导致一个更加不自由的世界，只有根植于人类尊严和创造力的全新计算运动才能改变这一趋势。

Radiant 是一个从零开始重新设计的计算机，摆脱了现代系统所受的“历史负担”以及大型科技公司的影响。其设计目标是帮助用户学习、创作、娱乐和探索，回归计算的简单乐趣，即用户与想法之间的直接互动。

当前计算的困境:

• 商业模式导向: 现在的计算机设计围绕着“参与度”和“监控”的商业模式，而非用户需求。应用商店充斥着广告软件，平台优先收集数据而非用户自主权，社交媒体算法则优化了成瘾性。大型科技公司将计算从赋能人类的工具转变为大规模数据收集系统。
• 软件质量问题: 软件通常运行缓慢、臃肿且存在缺陷。尽管硬件效率提高了数个数量级，但构建可靠、快速且易于使用的软件仍然极具挑战性，大多数软件未能达到这一标准。
• 开发环境的挑战: 开发人员在不知晓软件最终运行硬件的情况下进行编码，导致测试和质量保证几乎不可能。这导致软件无法满足用户期望，也无法高效且负责任地利用硬件。
• 安全与隐私不足: 现有系统缺乏友好性，也不够安全，对隐私不重视，且不尊重用户自由。这些问题无法通过在不具备这些设计理念的平台上进行后期改造来解决。

Radiant 的愿景:

Radiant 提出了一个替代的计算愿景：一个垂直整合的系统，其中硬件和软件协同设计。

• 全新系统: Radiant 不预装网页浏览器，而是拥有一个类似于早期互联网的网络，没有社交媒体、脚本和跟踪器。它是一个从头开始构建的系统，不追随现有操作系统的脚步，代表了一种全新的个人计算范式。
• 开放与可理解: Radiant 是一个完全开放的计算机，从硬件到软件，都可被单个开发者理解。
• 赋能软件开发: Radiant 旨在创造优秀软件的可能性，并保护用户自由。
• 代码为核心: Radiant 强调代码的重要性，并提供易于访问的编程环境，让任何人都能进行软件创作。所有应用程序和界面都以代码形式存在，用户可以阅读、编辑和扩展。
• 用户自主权: Radiant 致力于让用户真正拥有和修改自己的系统，并重新点燃计算的乐趣。

核心理念:

Radiant 旨在构建一个更人性化的未来：一个欢迎好奇心，鼓励实验，并让用户感觉拥有自己的计算机。这是一个面向下一代的个人计算平台。

更多信息:

• 系统：https://radiant.computer/system
• 设计原则：https://radiant.computer/principles
• 准则：https://radiant.computer/principles/tenets

联系方式:

• 邮箱: [email protected]
• Bluesky: @radiant.computer

项目进展:

Radiant 是一个正在进行中的个人计算研究项目。 更多信息请访问：log 或 notes。

© 2025 Radiant Computer

卢比及其邻居：Smalltalk

这篇文章探讨了 Smalltalk 对 Ruby 的影响，尽管 Smalltalk 的语法对 Ruby 的影响很小，但其对象的工作方式受到了 Smalltalk 的深刻启发，包括将所有数据视为对象系统的一部分。

Smalltalk 的历史

Smalltalk 起源于与发明了窗口界面、以太网和激光打印机等技术的 Xerox PARC 团队相同。Smalltalk 经历了几个版本，其中 Smalltalk-80 是第一个发布到更广泛世界中的版本。在 20 世纪 80 年代和 90 年代的大部分时间里，Smalltalk 是一种编程语言和环境，公司为其付费使用。它在航空业和大型工资项目中被广泛使用，对 Smalltalk 程序员的需求也很高。

Smalltalk 的环境

Smalltalk 与大多数现代编程语言不同，它没有受到 Unix 或 C 的影响。它的开发环境是其吸引力的关键部分，包括：

• 工作区 (Workspace): 类似于 REPL 会话，允许输入和执行代码。
• 浏览器 (Browser): 用于编写代码，提供类、协议和消息的组织视图。

Smalltalk 的代码全部存在于“图像”中，这使得修改系统代码成为可能，尽管这需要谨慎。代码共享通过“变更集”进行，允许团队成员交换代码差异。

Smalltalk 的语法

Smalltalk 的语法非常简单：

• 所有变量都是对象。
• 每个表达式都是发送给对象的消息。
• 所有消息都返回一个值。
• 语法主要包括 unary message, binary message, 和 keyword message.
• 代码从左到右评估，不考虑运算符优先级。

Smalltalk 的对象模型

Smalltalk 的对象模型与 Ruby 相似，包括：

• 所有内容都继承自 Object 基类。
• 实例变量是私有的。
• 方法查找发生在调用点。
• 类是 Class 类的实例。
• 存在一个称为“元类 (Metaclass)” 的概念。

Smalltalk 的影响

尽管 Smalltalk 在现代计算中没有广泛使用，但它对 Ruby 的影响主要体现在对象模型上，特别是“一切皆对象”的概念。Ruby 将这种理念转化为一种更熟悉 C/Perl/Java 的语法，鼓励创建小型类。作者认为，Smalltalk 的环境和风格对 Ruby 的编程方式产生了深远的影响。

总结：伯里对英伟达和思节同盟下注做空，市场反应不一

核心观点： 价值投资者迈克尔·伯里（“大空头”）通过其基金Scion Asset Management，对英伟达（Nvidia）和思节同盟（Palantir）做出了巨额看空期权投资，总价值分别为1.87亿美元和9.12亿美元。

关键细节：

• 投资组合： Scion Asset Management购买了约500万股思节同盟和100万股英伟达的看跌期权。
• 市场背景： 这发生在两家公司股价大幅上涨的背景下：英伟达今年上涨50%，市值突破5万亿美元；思节同盟今年上涨176%，连续九个季度盈利超预期，并提高了全年营收指导至近44亿美元。
• 市场反应： 伯里的看空押注以及对高估值的担忧，导致思节同盟股价下跌6.86%，英伟达股价下跌1.8%。
• 伯里的警告： 上周，伯里在X平台上警告市场存在“泡沫”，并建议“有时候，最好的策略是不参与”。
• 其他投资： Scion Asset Management还持有辉瑞、哈里伯顿、露勒蒙等公司的看涨期权。
• Broadcom 受益： Google的Gemini 3模型基于自家TPU芯片，这可能会让Broadcom受益，并可能促使其他AI开发者考虑采用定制芯片，从而可能影响英伟达的市场份额。Broadcom还与OpenAI合作，共同开发AI加速器。
• Oklo 获利： 市场分析师对Oklo的未来表示乐观，认为该公司在核反应堆许可、放射性燃料供应和融资等方面均取得进展，目标价从68美元上调至95美元。

总而言之， 伯里的看空押注反映了对当前科技股估值过高的担忧，与市场对英伟达和思节同盟的乐观情绪形成对比。同时，Broadcom凭借Google的Gemini 3模型受益，而Oklo也在核能领域展现出增长潜力。

Chrome 将弃用并移除 XSLT 支持：迁移指南 (Chrome to Deprecate and Remove XSLT: A Migration Guide)

发布日期： 2025 年 10 月 29 日

本文档详细介绍了 Chrome 将弃用并移除 XSLT 的计划，并提供了在 2026 年底移除前迁移代码的指导。

核心要点：

• 弃用内容： Chrome 将移除浏览器中实现的两个 XSLT API：
  • XSLTProcessor 类 (例如 new XSLTProcessor())
  • XML 样式表处理指令 (例如 <?xml-stylesheet … ?>)
• 时间线：
  • Chrome 142 (2025 年 10 月 28 日): 添加 Chrome 浏览器中的早期警告控制台消息。
  • Chrome 143 (2025 年 12 月 2 日): 官方弃用 API - 控制台和 Lighthouse 中开始显示弃用警告消息。
  • Chrome 148 (2026 年 3 月 10 日 Canary): Canary、Dev 和 Beta 版本开始默认禁用 XSLT，作为早期警告。
  • Chrome 152 (2026 年 8 月 25 日): Origin Trial (OT) 和企业策略 (EP) 启动，允许网站和企业在移除日期后继续使用该功能。
  • Chrome 155 (2026 年 11 月 17 日): XSLT 在稳定版本中停止工作，适用于所有用户，除非参与 Origin Trial 或企业策略。
  • Chrome 164 (2027 年 8 月 17 日): Origin Trial 和企业策略停止工作。XSLT 对所有用户禁用。
• XSLT 简介： XSLT (可扩展样式表语言转换) 是一种用于转换 XML 文档的语言，通常将其转换为 HTML 等其他格式。它使用 XSLT 样式表文件定义转换规则。
• 移除原因：
  • 安全风险： XSLT 使用的底层库 (如 libxslt) 复杂且陈旧，容易受到安全漏洞的影响，包括缓冲区溢出等，可能导致任意代码执行。
  • 现代替代方案： 现代 Web 开发依赖于更安全、更灵活的 JavaScript API (如 Fetch API, DOMParser) 和框架 (如 React, Vue, Svelte) 来处理数据和渲染 DOM。
  • 使用率低： 目前，只有约 0.02% 的网页加载使用 XSLT，表明其在 Web 平台中的作用已经式微。
• 其他浏览器： Firefox 和 WebKit 项目也计划从其浏览器引擎中移除 XSLT。
• 迁移方案：
  • JSON： 将 XML API 端点迁移到 JSON 格式，并在客户端使用 JavaScript 进行渲染。
  • 客户端 XSLT JavaScript 库： 使用 Saxonica 等 JavaScript 库实现客户端 XSLT。
  • Polyfill： 使用 Polyfill 兼容现有代码，无需修改。
  • Chrome 扩展： 使用 Chrome 扩展来应用 Polyfill，保持现有功能。

具体用例：

• RSS 和 Atom Feed： 使用 Polyfill 或将服务器端转换 HTML。
• 嵌入式设备 API 输出： 尽可能更新设备代码，或使用扩展程序。
• 懒惰模板： 使用 Polyfill 或服务器端转换。

Chrome 平台状态： Chrome Platform Status entry 提供最新更新。

总结： Chrome 计划移除 XSLT 以提高安全性并简化 Web 平台。开发者应尽快迁移代码，以避免在 2026 年 11 月 17 日后出现问题。

Deepnote 开源：面向未来计算标准的深度解析 (Deepnote Open Source: A Deep Dive into the New Computational Standard)

Deepnote 团队近日开源了其平台，并获得了社区的积极响应，包括 Hacker News 的热门趋势、GitHub 星标激增以及 LinkedIn 社区的广泛参与。为了回应社区对开源原因的强烈反馈，Deepnote 团队发布了一篇技术深度分析，阐述了开源的动机、对现有 notebook 标准的挑战，以及新标准的构建过程。

现有局限：Jupyter Notebook 的挑战

Jupyter Notebook (最初为 IPython Notebook) 自 2011 年发布以来，极大地推动了交互式计算笔记本的发展。Jupyter 团队在 2014 年发布了第四版 .ipynb 格式，已广泛应用于数百万工作流程。然而，该格式在设计之初并未充分考虑云计算、协作以及人工智能的需求，存在以下问题：

• 协作困难： 缺乏评论、评审和权限管理功能。
• JSON 格式导致差异难以区分： 即使是微小的修改也会产生大量的 JSON 数据，使得代码评审变得困难。
• 缺乏项目结构： 每个 notebook 都是孤立的，即使它们属于同一个分析项目。
• 缺乏上下文信息： 输出结果嵌入在 JSON 中，进一步增加了代码评审的难度。
• 扩展性有限： Jupyter 初始仅支持 Markdown 和代码两种 cell 类型，而更丰富的文本块、交互式输入和 SQL 块等功能缺失。
• 无法安全存储敏感信息。

Deepnote 的解决方案：项目为核心

Deepnote 改变了传统的 notebook 为核心的模式，将 项目 (Project) 作为最小工作单元。一个项目可以包含多个 notebook、共享的集成以及环境设置。这种设计类似于包含多个标签的工作表，每个标签负责不同的任务，例如数据清洗、特征工程和结果可视化。项目级别的元数据存储了集成、权限等信息，从而更好地组织和管理工作。

Deepnote 采用了 YAML 格式的 .deepnote 文件来将多个文件绑定到一个统一的、可读性强的文档中，保证了人类可读性和版本控制友好性。

.deepnote 格式的核心特性

.deepnote 格式的设计遵循以下原则：

• 人类可读的 YAML 格式： 避免使用机器优化的 JSON 格式。
• 支持安全连接数据源和集成： 方便连接各种数据源。
• 支持多 notebook 项目： 允许在同一个项目中包含多个 notebook。
• 可扩展的 block 类型： Deepnote 已经支持 23 种 block 类型，包括 SQL、图表、输入和 KPI 等。
• 可验证的 schema： 确保元数据的完整性和向前兼容性。
• 语言无关性： 支持 Python、SQL、TypeScript 等多种编程语言。

.ipynb 与 .py 的区别

Deepnote 团队尝试在 .ipynb 格式上进行改进，但最终发现其局限性难以克服。因此，他们选择了构建全新的格式。

• 为什么不使用 .ipynb？ Deepnote 团队认为 .ipynb 格式无法满足其对 notebook 的愿景，原有的设计理念与 Deepnote 的新功能不兼容。
• 为什么不使用 .py？ 尽管 Python 是目前的主流语言，但 Deepnote 认为 notebooks 的用途已经超越了简单的 Python 脚本，需要支持 SQL、TypeScript 等多种语言以及交互式可视化等功能。.py 无法满足这些需求。

面向未来的 notebook：AI 驱动、云原生

Deepnote 团队认为，未来的 notebooks 将会是 AI 智能代理和人类共同创作的产物，需要具备以下特性：

• AI 原生： 支持类型化的 block、稳定的 ID 和依赖关系图，方便 AI 代理进行代码分析和验证。
• 云原生： 能够在本地 IDE 和云端环境之间无缝切换，支持项目级别的设置，实现可重复的运行。
• 数据应用、定时任务和 API 端点： 将 notebook 转化为数据应用、定时任务和 API 端点，无需重新编写代码。

Deepnote 开源了 .deepnote 格式，并提供了将 .ipynb 转换为 .deepnote 的工具，旨在为社区提供一个开放的标准，用于构建下一代计算平台，支持人类与 AI 智能代理之间的协作。

肯塔基路易斯维尔发生UPS飞机坠毁事件，至少13人死亡

概述:

2025年11月4日，一架UPS货机在肯塔基州路易斯维尔国际机场起飞后不久坠毁，造成至少13人死亡，另有十余人受伤。事故发生在当地时间下午5:15左右，飞机载有三名UPS机组人员（机长理查德·瓦特南堡、副驾驶李·特鲁伊特和国际救援官丹娜·钻石），他们均被认为遇难。

主要细节：

• 伤亡情况: 除机组人员外，至少9人失踪，预计搜救工作已结束，目前改为善后处理。16个家庭报告了失踪的亲人。当地医院接诊了15名伤者，其中两人情况危急，其余已出院。据报道，遇难者中可能包括一名儿童。
• 飞机信息: 坠毁的飞机是1991年制造的麦道格尔MD-11型三引擎飞机，机上载有约38,000加仑的燃料和约20,000个包裹，重约233,000磅。初步数据显示，飞机起飞后短暂升至175英尺高度。
• 事故原因: 调查显示，飞机的左引擎在起飞过程中脱离飞机，可能导致飞机无法产生足够的升力。目击者视频显示飞机着火并冲下跑道。
• 调查进展: 美国国家运输安全委员会（NTSB）和联邦航空管理局（FAA）已介入调查。NTSB已回收了黑匣子，尽管受到火灾影响，但专家预计能够读取相关数据。
• 现场情况: 飞机坠毁地点约有一半英里长的碎片散落区。事故影响了两个企业，包括一个石油回收设施和一个汽车零部件企业。石油进入水域，汽车零部件企业存在大量金属废料，给搜救工作带来困难。
• 应急响应: 超过200名救援人员赶赴现场，路易斯维尔国际机场于11月5日恢复运营，但部分跑道仍关闭。
• 后续影响: UPS暂停了Worldport设施的包裹分拣操作，Second Day Air的特快运输服务暂停。居民被要求避免接触碎片，并避免在坠机现场飞行无人机。肯塔基州州长宣布进入紧急状态，并设立了紧急救济基金。UPS计划逐步淘汰MD-11飞机，更换为更节能的二引擎货机。

其他：

• 当地学校已于11月5日关闭，但已于11月6日重新开放。
• 目前正在恢复电力供应，确保饮用水安全。
• 由于政府关门，调查工作不受影响。

来源： CBS News

YouTube 删除了巴勒斯坦人权组织的频道，受到美国政府的压力

主要内容：

YouTube 在 2024 年 10 月份秘密删除了三个巴勒斯坦人权组织（Al-Haq、Al Mezan Center for Human Rights 和 Palestinian Centre for Human Rights）的官方频道，这些频道共包含超过 700 个视频。这一举动是响应美国政府的一项行动，旨在压制对以色列在加沙和西岸可能犯下的战争罪行的问责。

背景：

• 视频内容： 这些频道记录和展示了以色列政府涉嫌违反国际法的情况，包括针对巴勒斯坦平民的袭击事件。视频内容涵盖了调查报告（如对美国记者 Shireen Abu Akleh 被以色列杀害事件的分析）、被以色列军队折磨的巴勒斯坦人的证词，以及纪录片（如关于在加沙海滩被以色列袭击的儿童的纪录片“The Beach”）。
• 国际刑事法院 (ICC)： 在国际刑事法院对以色列总理内塔尼亚胡和前国防部长约阿夫·加兰特发出战争罪嫌指控逮捕令后，特朗普政府加大了对以色列的支持力度，并对 ICC 官员和与该法院合作的个人及组织实施制裁。
• 美国制裁： 2025 年 9 月，特朗普政府对这三家巴勒斯坦人权组织实施制裁，理由是它们与 ICC 合作处理针对以色列官员的战争罪指控。这些制裁冻结了这些组织的美国资产，并禁止制裁人员前往美国。

YouTube 的回应：

YouTube 承认删除了这些频道，原因是遵守美国国务院的制裁。YouTube 的政策规定，受到贸易制裁限制的实体和个人不能使用其发布平台。

人权组织的反应：

这些组织谴责 YouTube 的行为，认为这是一种压制言论自由和阻碍问责制行为。他们担心其他美国公司也会效仿，进一步压制巴勒斯坦的声音。

后续影响：

• 一些视频已通过互联网档案馆 (Wayback Machine) 或其他平台（如 Facebook 和 Vimeo）保存。
• 这些组织正在考虑使用位于美国以外的公司来托管其内容，以避免未来的审查。
• 类似情况也发生在了邮件服务提供商 Mailchimp 上，该平台也已删除 Al-Haq 的账户。

总结：

YouTube 的频道删除事件反映了美国政府对以色列的支持以及对国际刑事法院的抵制，同时也引发了对科技公司审查和压制人权组织声音的担忧。

内容摘要

本文表达了作者对于理想公司和软件产品的期望，强调了细节关注和用户体验的重要性。

核心观点：

• 理想的公司文化： 作者希望加入一家能够创造值得为其签名、对人们的生活产生积极影响，并且拥有谦逊聪明的同事的公司。
• 用户体验至上： 软件应感觉像是用户能力的延伸，以熟悉和易于接近的方式与用户沟通，关注每个用户的具体需求，而非泛泛的“所有用户”。
• 避免粗心大意： 作者用厨师的例子来比喻，强调即使在细节上，也要精益求精，避免出现不合逻辑、缺乏关怀的设计。
• 重视细微之处： 作者举例说明了即使是显示剩余时间的词汇（“分钟”或“minutes”）的细微差异，也应该注意，因为这些细节反映了工程团队的用心程度。 即使支持国际化，也应该付出额外的努力来确保用户体验的完整性。
• 对作品负责： 作者强调，如果自己是团队成员，就必须对最终产品负责，因此对产品质量有着极高的要求。

关键细节：

• 作者通过 5 item(s) loading、Uploading 3 image(s)、1 user(s) added、15 minute(s) remaining 等示例，说明了在软件开发中，即使是看似微不足道的细节，也需要精心处理。
• 作者提供了一段代码示例，演示了如何根据剩余时间的数量正确使用单复数形式： (minutes == 1) ? "minute" : "minutes" 或 Minutes remaining: ${minutes}。
• 图片暗示了忽略细节会导致产品被用户直接否定。

总结：

总而言之，作者希望加入一家重视用户体验、精益求精、注重细节，并让员工为自己的工作感到自豪的公司。 产品的质量不仅仅体现在核心功能上，更体现在每一个细节的处理和对用户的尊重。

IncusOS 概述

IncusOS 是一款专为安全可靠地运行 Incus 而设计的不可变操作系统。它利用现代安全特性，如 UEFI 安全启动和 TPM，提供安全的启动体验以及无缝的全盘加密。

主要特点：

• 启动安全： 使用 UEFI 安全启动和 TPM 2.0 测量，确保启动过程的安全。
• 全盘加密： 基于 TPM 的 LUKS 和 ZFS 加密，保护存储数据的安全性。
• 不可变性： 采用 A/B 分区方案，所有 OS 分区均为只读且已签名，防止未经授权的修改。
• 严格锁定： 不提供本地或远程 shell，仅通过认证的 REST API 管理 Incus 和 OS。
• 现代硬件支持： 适用于现代 Intel/AMD 或 ARM 系统。

核心功能：

• 存储：
  • 自动创建本地 ZFS 池。
  • 支持在额外磁盘上创建复杂的 ZFS 池。
  • 支持光纤通道、多路径、NVME-over-TCP、iSCSI 等存储协议。
  • 支持集群 LVM (基于光纤通道、NVME-over-TCP 或 iSCSI)。
  • 支持 Ceph 软件定义存储（Linstor 将会推出）。
• 网络：
  • 自动 VLAN 感知桥接，方便将实例连接到任何接口。
  • 支持链路聚合 (主动和协商)。
  • 支持 LLDP。
  • 支持企业代理服务器（包括 Kerberos 认证）。
  • 强大的 NTP 支持。
  • 通过 syslog（UDP、TCP、TLS）提供远程日志记录支持。
  • 支持 OVS/OVN 软件定义网络。
  • 原生支持 Tailscale (Netbird 即将推出)。
• 管理：
  • 通过 Operations Center 进行集中管理。
  • 支持 OS 配置和应用程序数据的备份/恢复。
  • 支持对整个 OS 或单个应用程序进行恢复出厂设置。
  • 灵活的更新管理。

技术细节：

IncusOS 基于 Debian 13 构建，并包含自定义的 Incus 和内核构建。除了运行 Incus 之外，IncusOS 还可以作为 Operations Center 和 Migration Manager 的底层 OS，从而实现从 VMware 等环境轻松迁移到 Incus。

IncusOS 广泛使用 systemd 的现代 OS 功能来构建镜像、处理更新以及处理诸如首次启动分区和 TPM 加密的等操作。

更新和发布节奏：

IncusOS 提供两个更新通道：

• 稳定 (stable): 默认通道，通常每周至少更新一次，以获取最新的 Linux 内核稳定错误修复版本以及相关的安全问题。
• 测试 (testing): 构建频率更高，通常每天一次。

系统默认每 6 小时检查更新，并会自动更新 Incus（运行实例有短暂的 API 下线），并将 OS 更新分阶段准备好在重启时启动。

可以通过配置更改更新频率或完全禁用自动更新，以及指定计划的停机时间来应用应用程序更新。

贡献：

IncusOS 的开发在 Github 上进行：https://github.com/lxc/incus-os。

该项目由驱动 mkosi 的配置文件和自定义的 Go 代码（用于 OS 管理守护进程和相关工具）组成，用于构建镜像。

所有代码均以 Apache 2.0 许可发布。

Hypothesis 简介及文档概览 (Hypothesis 简介及文档概览)

Hypothesis 是一个用于 Python 的基于属性的测试库。其核心思想是，您编写测试，测试应该对您描述的范围内所有输入都通过，然后让 Hypothesis 随机选择这些输入进行检查，包括您可能没有考虑到的边界情况。

主要特点:

• 基于属性的测试: 允许您定义函数的预期行为，而不是仅仅提供具体的输入输出示例。
• 随机输入生成: Hypothesis 会自动生成各种各样的输入，以寻找导致测试失败的边界条件和错误。
• 简化测试过程: 帮助开发者更全面地测试代码，减少手动构造测试用例的工作量。

文档结构：

Hypothesis 的官方文档主要包含以下几个部分：

• 教程 (Tutorial): 针对新用户的入门指南，详细介绍 Hypothesis 的基本概念和使用方法。建议新用户从这里开始学习，或者参考更精简的快速入门指南。
• 快速入门 (Quickstart): 更加简洁的入门指南，适合快速了解 Hypothesis 的核心功能。
• How-to 指南 (How-to guides): 提供一系列实践指南，展示如何在特定场景下应用 Hypothesis。
• 解释 (Explanations): 旨在加深用户对 Hypothesis 的理解，提供更深入的解释和原理说明。
• API 参考 (API Reference): 包含 Hypothesis 的技术 API 参考文档，详细描述了各个函数和模块的使用方法。

总而言之，Hypothesis 旨在通过属性驱动的随机测试，帮助 Python 开发者更有效地发现和修复代码中的错误，提高代码质量。

数字图像抖动 (Dithering) 简要概括

本文解释了数字图像抖动 (dithering) 的原理和演变，以及它从技术需求到复古美学的转变。

背景与目的:

• 早期计算机内存有限，无法存储大量的颜色信息。为了减少颜色数量，需要进行颜色量化 (quantization)，即使用有限的调色板或低位深颜色。
• 量化会导致颜色出现硬边缘，破坏平滑的渐变效果。抖动技术应运而生，旨在通过添加噪声来模拟更多的颜色，欺骗人眼。

抖动原理:

• 抖动利用了人眼的空间平均特性，即眼睛会将小区域内的颜色进行平均。
• 通过将相邻颜色交错排列，抖动算法能够欺骗眼睛，使其在两个颜色之间感知到平滑的过渡，类似于低通滤波器。

抖动算法:

本文介绍了两种主要的抖动算法：

1. 有序抖动 (Ordered Dithering):
   • 使用预定义的阈值映射 (threshold map) 来决定像素的颜色。
   • 通常使用 Bayer 矩阵，例如 2x2 矩阵，将矩阵值缩放到 0-255 范围，作为阈值。
   • 将图像划分为小块 (例如 2x2 像素块)，并根据像素值与阈值比较结果来确定像素的颜色（黑或白）。
   • 矩阵大小影响可显示的灰度级数。更大的矩阵提供更精细的细节。
   • 缺点：容易产生可识别的图案。
2. 错误扩散抖动 (Error Diffusion Dithering):
   • 以 Floyd-Steinberg 算法为例，使用单个阈值（例如 128）进行比较。
   • 计算原始像素值与量化后的像素值之间的误差 (error)。
   • 将误差扩散到相邻像素，根据预定义的权重矩阵进行分配。 误差是有符号的，可以为正或负。
   • 通过补偿相邻像素的亮度来减少量化误差。

当前状况:

• 由于现代计算机拥有高位深颜色，抖动技术已经不再是必需的技术手段。
• 如今，抖动主要被用作一种复古美学风格。

总结:

抖动技术最初是为了解决早期计算机颜色显示限制而产生的，通过欺骗人眼来模拟更多的颜色。 虽然现在已经不再是必需，但它仍然是一种有用的技术，并且被广泛应用于各种图像处理和图形设计领域。

(Note: This summary aims to be concise and accurate, reflecting the information presented in the original text. It avoids personal opinions and extraneous details.)

互联网臃肿问题及“512KB俱乐部”简介 (互联网臃肿问题及“512KB俱乐部”简介)

互联网现状日益臃肿，大型JavaScript库、大量客户端请求以及复杂的前端框架变得司空见惯。例如，像《纽约时报》这样的知名网站，其资源大小已经达到了数MB，其中近一半是JavaScript，这引发了对网站规模膨胀的担忧。

为了应对这一问题，出现了一个名为“512KB俱乐部”的倡议，旨在鼓励创建轻量级网站。

“512KB俱乐部”的要求：

• 网站必须包含合理的信息量，而不仅仅是几个链接。
• 网站的未压缩资源总大小不能超过512KB。

俱乐部分类:

• 绿色团队 (<100KB): 包含资源量极小的网站，例如 ctrl-c.club (2.02KB) 和 smalltictactoe.dpdns.org (2.50KB)。
• 橙色团队 (<250KB): 资源量较小的网站，例如可访问性和功能性都较好的网站。
• 蓝色团队 (<512KB): 满足俱乐部所有要求的网站。

俱乐部列表:

俱乐部网站提供了详细的成员列表，按照资源大小进行分类。绿色团队网站的资源大小从2.02KB到100.00KB不等，蓝色团队网站的资源大小从250.16KB到508.22KB不等。

支持俱乐部:

俱乐部运营需要志愿者支持，欢迎大家通过购买咖啡等方式提供支持。

总结:

“512KB俱乐部”旨在通过推广轻量级网站的设计和开发，解决互联网资源臃肿的问题，并鼓励开发者关注性能优化。

Ars Technica 简介与信息汇总

Ars Technica 是一家拥有超过 25 年历史的科技媒体平台，专注于从信息噪音中提炼关键信号。其特点在于结合了技术专长和对科技艺术与科学的广泛兴趣，致力于提供可信赖的技术信息来源。Ars Technica 强调读者无需了解所有信息，只需掌握重要的内容。

主要信息点：

• 定位： 可信赖的科技信息来源，专注于过滤噪音，提供关键信息。
• 历史： 运营超过 25 年。
• 特点： 结合技术专长和广泛的科技兴趣。
• 核心理念： 读者只需掌握重要的信息，无需了解所有信息。

网站其他信息：

• 关于我们： https://arstechnica.com/about-us/
• 团队成员： https://arstechnica.com/staff-directory/
• 新闻邮件订阅： https://arstechnica.com/newsletters/
• 常见问题解答： https://arstechnica.com/general-faq/
• 发帖指南： https://arstechnica.com/ars-technica-posting-guidelines-v3-0/
• RSS 订阅： https://arstechnica.com/rss-feeds/
• 联系方式： https://arstechnica.com/contact-us/
• 广告合作： /cdn-cgi/l/email-protection#5332373a3d22263a213a362013303c3d37363d3220277d303c3e
• 版权声明： © 2025 Condé Nast. 版权所有。 网站使用或注册构成对用户协议、隐私政策及相关补充协议的接受。
• 其他政策： 包含用户协议、隐私政策、加州隐私权利声明、联盟链接政策等，并提供广告选择选项。 网站内容未经 Condé Nast 书面许可，不得复制、分发、传输、缓存或其他使用。

退出云端：降低成本 10 倍，提升性能

作者最近将所有项目从 AWS 迁移到自建服务器，成功将每月 AWS 账单从 1400 美元降低到 120 美元以下，同时提升了 2 倍的性能。 这篇文章分享了他的经历和原因，并引发了关于云服务的讨论。

主要观点：

• 成本大幅降低: 通过切换到 Hetzner 等公司，作者将服务器成本降低了 10 倍。 例如，80 核服务器每月只需 190 美元，而 AWS 同等配置的服务器每月价格在 2500-3500 美元之间。
• 服务器并非昂贵: 作者认为，服务器本身并不昂贵，购买自己的服务器甚至在长期来看更划算。
• 云服务并非必需: 许多开发者过度依赖云服务，而实际上，对于小型项目来说，简单的 Linux 服务器就足够。
• 云服务的“专家”可能存在利益冲突: 许多批评作者做法的人，在 "devops"、"云工程师" 等领域工作，可能因为职业原因而对云服务持有偏见。
• 学习服务器管理并非困难: 借助 AI 工具（如 Claude 和 ChatGPT），学习服务器管理变得更加容易。
• 安全问题可控: 通过使用 Cloudflare 等工具，可以有效提升服务器安全性。

解决方案：

• 选择合适的服务器提供商: Hetzner 和 Digital Ocean 是作者推荐的选择。
• 考虑购买自己的服务器: 在长期来看，购买自己的服务器可能更经济。
• 利用 AI 工具: 使用 AI 工具来学习和管理服务器。
• 加强服务器安全: 使用 Cloudflare 等工具来保护服务器安全。

作者建议：

开发者不要盲目追随云服务潮流，应该根据自身需求选择最合适的解决方案。 降低成本，摆脱供应商锁定，并提升服务质量，是每个开发者都应该考虑的目标。

额外信息：

作者正在开发 RailsFast，一个基于 Ruby on Rails 的 SaaS 模板，旨在为 AI 应用提供安全稳定的基础。

Grayskull 图像处理库总结 (Summary of Grayskull Image Processing Library)

Grayskull 是一个极简、无依赖的计算机视觉库，专为资源受限设备，如微控制器设计。它专注于灰度图像处理，提供实用且高效的算法，代码量仅需几千字节。

核心特点 (Key Features):

• 单文件头 (Single-Header Design): 整个库包含在一个单独的头文件内，简化了集成和部署。
• 纯 C99: 使用标准的 C99 语言，保证了可移植性和兼容性。
• 无依赖 (No Dependencies): 不依赖于任何外部库，方便在嵌入式系统中使用。
• 无动态内存分配 (No Dynamic Memory Allocation): 避免了动态内存分配带来的开销和潜在风险，更适合资源有限的环境。
• 无 C++: 只使用 C 语言，降低了复杂性。

功能 (Functionality):

Grayskull 提供了以下图像处理功能：

• 图像操作 (Image Operations): 复制 (copy)、裁剪 (crop)、调整大小 (resize, 使用双线性插值)、降采样 (downsample)。
• 滤波 (Filtering): 模糊 (blur)、Sobel 边缘检测、阈值化 (global, Otsu, adaptive)。
• 形态学操作 (Morphology): 腐蚀 (erosion)、膨胀 (dilation)。
• 几何操作 (Geometry): 连通域 (connected components)、透视变换 (perspective warp)。
• 特征检测 (Feature Detection): FAST/ORB 关键点和描述符，用于目标跟踪。
• 局部二值模式 (Local Binary Patterns - LBP): LBP 分级级联，用于人脸、车辆等目标的检测。
• 实用工具 (Utilities): PGM 图像格式的读取/写入。

快速上手 (Quickstart):

使用方法如下：

#include "grayskull.h"

struct gs_image img = gs_read_pgm("input.pgm");
struct gs_image blurred = gs_alloc(img.w, img.h);
struct gs_image binary = gs_alloc(img.w, img.h);

gs_blur(blurred, img, 2);
gs_threshold(binary, blurred, gs_otsu_threshold(blurred));

gs_write_pgm(binary, "output.pgm");
gs_free(img);
gs_free(blurred);
gs_free(binary);

API 接口 (API Reference):

• 图像结构体 (Image Structure): gs_image { unsigned w, h; uint8_t *data; }
• 矩形结构体 (Rectangle Structure): gs_rect { unsigned x, y, w, h; } (ROI)
• 点结构体 (Point Structure): gs_point { unsigned x, y; } (角点)
• 主要函数 (Key Functions):
  • gs_get, gs_set: 获取和设置像素值。
  • gs_crop, gs_copy, gs_resize, gs_downsample: 图像操作。
  • gs_histogram, gs_threshold, gs_otsu_threshold, gs_adaptive_threshold: 阈值处理。
  • gs_blur, gs_erode, gs_dilate, gs_sobel: 滤波操作。
  • gs_blobs, gs_blob_corners, gs_perspective_correct, gs_trace_contour: 连通域和轮廓分析。
  • gs_fast, gs_compute_orientation, gs_brief_descriptor, gs_orb_extract, gs_match_orb: FAST/ORB 特征检测与匹配。
  • gs_integral, gs_lbp_window, gs_lbp_detect: LBP 特征和检测。
  • gs_alloc, gs_free, gs_read_pgm, gs_write_pgm: 内存管理和图像 I/O。

许可 (License):

Grayskull 采用 MIT 许可证，允许在研究、产品和嵌入

Phrack 杂志第七期第三篇文章摘要：黑客宣言

作者： The Mentor

发布日期： 1986年1月8日

核心内容：

这篇文章，名为《黑客良心》（The Conscience of a Hacker），是作者在被捕后写下的“黑客宣言”。文章旨在阐释黑客的动机和行为，并对社会对黑客的指责进行反驳。

主要观点：

• 对教育体系的批判： 作者认为传统的教育体系无法满足其求知欲，学校提供的知识枯燥乏味，并对表现出高于平均水平的学生不屑一顾。
• 对黑客世界的认同： 作者描述了发现计算机后，黑客们通过电话线建立联系，形成社群的经历，并强调了在黑客世界中找到归属感。
• 对社会的反驳： 作者认为黑客的行为并非出于恶意，而是出于对知识的渴望，对现有系统的探索，以及对社会不公的反抗。他们利用现有服务，探索技术，不受种族、国籍和宗教的限制。
• 对自身身份的声明： 作者承认自己是罪犯，但认为自己的罪行在于好奇心，在于独立思考，以及在于智胜社会。
• 对未来的展望： 作者坚信，虽然可以逮捕某个黑客，但无法阻止整个黑客群体的发展，因为他们拥有共同的价值观和目标。

总结：

《黑客宣言》表达了黑客们对社会规范和价值观的挑战，以及对自由探索和知识追求的渴望。文章以一种充满激情和批判性的口吻，试图解释黑客行为的深层原因，并为黑客群体辩护。文章的结尾，作者表达了对未来黑客群体发展的乐观预期。

美国国土安全部拟大幅扩大移民申请中的生物识别数据收集

核心要点： 美国国土安全部 (DHS) 计划通过其下属机构美国公民及移民服务局 (USCIS) 大幅扩大其收集生物识别数据的范围，覆盖移民申请人，甚至与案件相关的美国公民。 此举旨在验证身份并防止欺诈，但实际范围远超身份验证。

主要内容：

• 扩大数据收集范围： DHS 计划不再仅限于某些申请和执法行动，而是要求几乎所有与移民申请相关的个人（包括申请人、申诉人、担保人、支持者、受益人、依赖人，以及美国公民）提交生物识别数据，除非获得豁免。 此外，还规定对被 DHS 逮捕、拘留或接触到的任何外国人也必须收集生物识别数据。
• 扩大生物识别数据定义： DHS 拟将“生物识别”定义为“个体可测量的生物学特征（解剖、生理或分子结构）或行为特征”，从而为未来收集新型生物识别数据提供更广阔的空间。
• 新增数据类型： 新规则允许 DHS 使用包括眼部图像、语音指纹和 DNA 等新型生物识别技术。 特别是，DHS 将拥有要求、征求或接受原始 DNA 或 DNA 检测结果的权限，例如用于证明或反驳生物学性别，以影响福利资格。
• **数据用途：**收集到的数据将用于身份注册、验证和管理移民生命周期、国家安全和犯罪历史检查、制作安全身份证明文件、证明家庭关系以及执行其他行政职能。
• 公众反馈： 目前公众对该提案的反馈普遍负面，认为该计划构成政府过度干预，并将其与中国等国家的做法相提并论，认为其违反了宪法中反对无理搜查和扣押的保障。公众可在 1 月 2 日前提交意见。

风险提示： 文章指出，生物识别技术，特别是面部识别技术，容易被滥用且存在错误识别的风险，尤其对非白人个体。 新型生物识别数据，如语音记录，也容易受到 AI 仿真的影响。DHS 对此提案的回应有限，未针对该提案发表具体声明。

马萨诸塞州警察局的GPS追踪系统：漏洞与更新政策

马萨诸塞州警察局每月花费近7万美元维护一套先进的GPS追踪系统，旨在提高问责制和公共安全。然而，调查显示该系统存在一个漏洞：数百辆警车都配备了“静默开关”，允许追踪功能被禁用。

追踪系统与漏洞：

• 系统部署： 2019年，州警察局开始在其所有车辆上安装自动车辆定位（AVL）技术，初期成本为22.5万美元。当时州警察局长强调该系统是提高问责制的关键工具，此前曾发生过大规模加班欺诈事件。
• 系统目的： AVL系统的目标是提高问责制、运营效率和警员安全，通过交叉核对位置数据进行考勤审核和内部审计。
• 静默开关： 为了回应一些地区检察官办公室对追踪调查人员位置可能危及人员安全的担忧，州警察局在部分车辆（主要是不带警徽的调查车辆）上安装了第二物理设备，即“静默开关”，允许操作员暂时禁用AVL。
• **覆盖范围：**截至2025年9月5日，共有418辆州警察警车，约占该部门3000辆警车的14%，配备了静默开关。
• **利用案例：**前州警察侦探Michael Proctor的事件揭示了静默开关的潜在滥用。 Proctor因在Karen Read谋杀案审判中曝光的违规行为而被解雇。调查记录显示，Proctor和Canton警察局侦探Kevin Albert声称前往Cape Cod调查“悬案”，期间在Treehouse Brewery喝啤酒，并在返回途中的Hanover享用晚餐和更多酒水。Albert后来声称相关短信是玩笑，但Proctor的GPS记录显示，当天的车辆行驶仅持续了八秒，从未离开Canton，其余时间均未被记录，因为追踪设备已被关闭。
• 其他滥用案例： 2021 年的内部事务报告显示，前警员Dwayne Correia 在饮酒后因枪支被盗而故意关闭了追踪器，以“掩盖”他的行踪。

更新政策与监管：

• 政策更新： 当前州警察局长Geoffrey Noble已实施更新政策，旨在加强对静默开关使用的监管。
• 新的监管措施： 新政策赋予了主管更直接的监督权，特别是对暂时禁用系统的请求，以保护警员、受害者和证人的安全。
• 使用限制： 新政策明确规定，在日常活动中AVL应保持运行状态，只有在“有限的、特殊的紧急情况下”，成员才能按照结构化的流程申请禁用系统，并详细说明任务、预计时长以及支持禁用系统的安全理由。
• 部门承认： 州警察局承认，对静默开关的使用方法在部门内存在差异。

总而言之，马萨诸塞州警察局的GPS追踪系统虽然旨在提高问责制，但静默开关的存在以及潜在的滥用，对该系统的有效性和透明度构成了挑战。新的政策旨在加强监管，限制静默开关的使用，以平衡安全需求和问责制目标。

马萨诸塞州警察局的GPS追踪系统：漏洞与更新政策 (中文)

马萨诸塞州警察局每月花费近7万美元维护一套先进的GPS追踪系统，旨在提高问责制和公共安全。然而，调查显示该系统存在一个漏洞：数百辆警车都配备了“静默开关”，允许追踪功能被禁用。

追踪系统与漏洞：

• 系统部署： 2019年，州警察局开始在其所有车辆上安装自动车辆定位（AVL）技术，初期成本为22.5万美元。当时州警察局长强调该系统是提高问责制的关键工具，此前曾发生过大规模加班欺诈事件。
• 系统目的： AVL系统的目标是提高问责制、运营效率和警员安全，通过交叉核对位置数据进行考勤审核和内部审计。
• 静默开关： 为了回应一些地区检察官办公室对追踪调查人员位置可能危及人员安全的担忧，州警察局在部分车辆（主要是不带警徽的调查车辆）上安装了第二物理设备，即“静默开关”，允许操作员暂时禁用AVL。
• **覆盖范围：**截至2025年9月5日，共有

总结：使用 HackRF Pro 和 Teewee 天线接收 WWVB 时间信号

本文介绍了作者利用 HackRF Pro 和自制的 Teewee 天线成功接收并分析美国国家标准与技术研究院 (NIST) 广播的 WWVB 时间信号的过程，并探讨了其在频率校准和研究中的应用。

主要内容：

• WWVB 信号的优势： WWVB 广播提供了一种稳定且免费的频率参考源和时间码，可以用于校准实验室频率标准，甚至替代昂贵的原子钟。相比于 GPSDO，WWVB 具有室内接收、设计简单、不受 Kessler 综合症影响等优点。
• HackRF Pro 的优势： HackRF Pro 内置的 TCXO (温度补偿型晶体振荡器) 相较于 HackRF One 具有更高的频率准确性，能更可靠地测量无线信号的频率误差。
• Teewee 天线的设计与实现： 由于 60 kHz 信号的波长非常长，作者设计并制作了 Teewee 天线，这是一种小型的、基于环形天线和放大器的有源天线，使用 HackRF Pro 成功接收到了 WWVB 信号，即使距离 WWVB 广播站超过 1000 英里。
• 信号分析： WWVB 信号采用振幅移键控 (ASK) 调制，每秒钟开启和关闭一次。作者还观察到了自 2012 年以来引入的二相移键控 (BPSK) 调制，并利用 Inspectrum 工具进行分析。
• 多普勒效应测量： 作者在飞机上使用 Teewee 接收 WWVB 信号，成功观察并测量了由于飞机运动引起的频率多普勒效应，并通过 ADSB 飞行数据验证了测量结果，并利用该数据校准了 HackRF Pro 的 TCXO。
• 项目开源： 作者将 Teewee 天线的设计公开，供他人参考和使用。

核心技术与细节：

• HackRF Pro: 作为软件定义无线电 (SDR) 设备，用于接收和分析 WWVB 信号。
• Teewee 天线: 一种小型的、基于环形天线和放大器的有源天线，用于提高对 WWVB 信号的接收灵敏度。
• WWVB 信号调制: ASK (振幅移键控) 和 BPSK (二相移键控) 调制。
• Inspectrum: 用于信号分析和频谱显示的工具。
• TCXO: HackRF Pro 内置的温度补偿型晶体振荡器，用于提高频率准确性。
• 多普勒效应: 飞机运动对 WWVB 信号频率的影响。

总而言之，本文详细描述了作者利用开源硬件和自制天线成功接收和分析 WWVB 时间信号的经验，展示了 WWVB 作为频率参考源的实用性，并提供了一个有趣且富有教育意义的无线电项目。

慕尼黑艾斯巴赫河冲浪波消失：一代传奇的谜团

慕尼黑艾斯巴赫河（Eisbach）冲浪波，因其冰冷的温度而被称为“冰溪”，长期以来被认为是淡水冲浪的诞生地，并且吸引了全球冲浪爱好者。然而，在数十年的稳定流动后，这处著名的静止波突然消失，令冲浪者们感到困惑。

艾斯巴赫波的背景：

• 起源： 艾斯巴赫波的冲浪运动起源于20世纪70年代初，当时一些大胆者开始尝试在自然形成的波浪上冲浪。
• 形成机制： 艾斯巴赫波最初被认为是由砾石形成的，后来冲浪社区安装了木板，以人为方式稳定波浪。这种静止波通常由水流流过混凝土结构形成，创造出永久性的波浪。
• 旅游意义： 艾斯巴赫波已经成为巴伐利亚州首府慕尼黑的一大旅游景点。
• 季节性变化： 波浪在冬季最大，冰雪融化可以将波浪推至1米高。
• 管理： 河流受到官方管理，每年进行一次排水清理和河床检查。

消失的谜团：

• 事件： 在上周五清理后，水被重新释放回运河，但艾斯巴赫波没有像往常一样形成，取而代之的是不稳定的白水激流。
• 调查： 当地政府正在调查波浪消失的原因，包括清理工作的影响或水量的不足。 官方声明表示，在清理过程中没有对艾斯巴赫波或其河岸进行任何结构性改变，并且现场检查也没有发现任何损坏。
• 应对措施： 慕尼黑市长Dieter Reiter表示，市政府正在与水务局和冲浪者合作，寻求快速解决方案，尽快恢复艾斯巴赫波的正常状态。 官员计划将更多的水导入运河，希望能够使艾斯巴赫波再次出现。

其他河浪冲浪的例子：

文章提到了其他地方的河浪冲浪现象，例如：

• 英国的塞文河（River Severn），冲浪者在潮汐波浪中冲浪。
• 夏威夷，冲浪者通过在河流和海洋之间挖掘沟渠，使水流过沙子形成波浪。

安全问题：

今年早些时候，艾斯巴赫波曾因一名33岁的慕尼黑女子在夜间被困在水下而关闭数月。重新开放后，禁止夜间冲浪。

总而言之，慕尼黑艾斯巴赫河冲浪波的突然消失令人们困惑，当地政府正在积极寻找原因并努力恢复这处著名的水上景观。

工程师离职的真相：信息流动、信任与经济效益

2018年，一家年营收4000万美元SaaS公司的资深工程师花费了六个月的时间，试图指出拟定的数据库架构无法扩展。产品团队希望尽快发布，工程领导也同意了，但没有反对产品团队的意见。最终的决定是：先发布，后续再重构。这位工程师当周就开始了面试。并非因为技术决策本身——这些事情经常发生，而是因为他的判断不被重视。八个月后，系统出现了每日性能问题。十八个月后，公司失去了五位资深工程师，并聘请了一位兼职CTO来诊断原因。

诊断结果很简单：高层管理人员直到工程师离职才得知他们对工作不满意。离职面谈中，工程师们提到“更好的机会”和“有竞争力的薪酬”。CEO为留任工程师们批准了15%的加薪，但更多的人还是离职了。真正的根源并非薪酬问题，而是组织层级结构阻碍了信息向上流动。问题在到达高层管理人员时，已经演变成了几个月前做出的离职决定。

层级结构过滤了坏消息

组织创建层级结构是为了管理复杂性。然而，一个意想不到的后果是信息被过滤在每一层。例如，初级工程师向资深工程师指出一个技术决策可能存在问题。资深工程师会告诉工程经理。工程经理会决定这是否会让他看起来不靠谱，或者是否值得升级。工程副总裁收到的是一个经过过滤的版本，如果有什么的话。CTO听到的是“我们正在处理”。CEO听到的是“一切都在正轨”。

每一层都会消除细节和紧迫性。当问题最终到达高层管理人员时，要么已经变成危机，要么已经被完全过滤掉了。这种过滤并非恶意行为。中层管理者认为他们正在尽职尽责地“在自己的层面上处理问题”。他们将升级视为失败。他们汇报解决方案，而不是问题。这看起来像专业精神，但实际上是信息压制。

一家拥有120名工程师的软件公司就是一个很好的例子。前端团队在3月份发现了新仪表盘的性能问题。到了4月份，工程师们在代码评审中公开讨论这个问题。工程经理在5月份就知道了，并开始调查解决方案。工程副总裁在6月份听到了这个消息，但被描述为“我们正在优化仪表盘性能”。CTO在7月份得知“正在进行一些性能工作”。到了8月份，公司的最大客户抱怨仪表盘无法使用。高层管理人员将此视为突然出现的危机，需要紧急响应。工程师们已经在前五个月就知道了。

结果是，做出资源分配决策的人员所依据的信息已经滞后了几个月，并且系统性地过滤掉了坏消息。工程师们在8月份就知道数据库无法扩展，经理们在10月份就知道工程师们感到沮丧，副总裁们在12月份就知道存在士气问题，CTO在2月份才得知工程师们正在辞职。每个团队都认为他们正在妥善处理问题，但他们没有意识到他们正在创造信息滞后，从而使问题无法解决。

方便的指挥链虚构

许多组织认为直接与几层下属工程师进行沟通（跳层沟通）是不合适的。反对的理由一致：这会削弱中层管理者的权威，破坏指挥链，产生不信任感，或者代表着微观管理。这些担忧被认为是组织健康问题，但实际上是组织抗体，保护中层管理者免于承担责任。

一个与初级工程师直接沟通的CTO会听到事情的真相。一个依赖过滤报告的CTO会听到管理层希望他听到的话。禁止跳层沟通确保了后者。中层管理者更喜欢这种安排，因为他们可以控制信息流。他们可以呈现他们已经解决的问题，并压制那些反映他们自身表现不佳的问题。组织为此付出了代价，信息滞后将小问题变成了危机。

跳层沟通的经济论证

许多人认为，跳层沟通会浪费高管的时间，应该专注于战略问题。但当战略决策基于系统性错误的信息时，这种逻辑就失效了。CTO花几小时每周与不同级别的工程师沟通，可以了解问题的真相，了解哪些地方阻塞了生产力，以及哪些工程师正在精神上脱离工作。这些信息具有直接的战略价值。它可以揭示如何分配资源，哪些管理者有效，哪些技术赌注失败了。相反，依赖经过三到四层过滤的报告，虽然每小时成本更低，但会做出更昂贵的错误决策。

时间投入不必太大。每周分配几个

总结：关于x.com隐私扩展问题

这段内容主要提示用户在使用x.com (原Twitter) 时可能遇到的问题，并提供了解决方案。

核心要点：

• 问题： 使用x.com时可能出现问题。
• 原因： 某些隐私相关的浏览器扩展程序可能导致这些问题。
• 解决方案： 建议用户禁用这些隐私扩展程序，然后再次尝试。

总结：

简单来说，如果在使用x.com时遇到问题，请检查并禁用你的浏览器隐私扩展程序，这可能是问题的根源。

YouTube 频道因系统故障被错误终止事件总结

事件概述:

2025年11月，拥有超过35万订阅者的知名科技YouTuber Enderman 及其附属频道 "Andrew" 因系统错误被YouTube永久终止。YouTube的自动系统错误地将Enderman的频道与一个受到版权侵权指控的日本频道关联，导致了这一错误终止。Enderman本人坚称与该日本频道没有任何关联。

事件细节:

• 终止原因: YouTube发送邮件通知Enderman，其附属频道 "Andrew" 因与一个被版权侵权指控并被终止的日本频道关联而被永久移除，并警告其主要频道也将面临同样的命运。
• Enderman的回应: Enderman 在YouTube上发布了一条告别视频，随后该视频及其整个账号都消失了。视频备份已上传至Odysee平台。
• 影响扩大: 随后发现，Enderman的遭遇并非个例，其他多位创作者也因类似的系统故障而被错误终止频道。
• 历史问题: Enderman自2021年以来，曾多次因其视频内容（例如Windows激活教程和AI工具互动视频）被YouTube移除。但此次终止的范围和后果更为严重。
• 公众反应: 事件引发了广泛讨论，许多用户在观看Enderman视频时目睹了他的频道被封禁。评论者们批评YouTube过度依赖AI审核，却未能有效解决平台上的诈骗和垃圾信息问题。

YouTube的回应与后续:

• 申诉流程: YouTube的申诉流程涉及提交表格，但许多创作者报告申诉成功率较低。YouTube声称使用“自动化系统和人工审核相结合”的方式进行内容决策，但自动化程度似乎更高。
• Odysee的邀请: 竞争平台Odysee已向Enderman发出邀请，提供内容发布平台。
• 问题解决: 在事件发生后，YouTube开始纠正错误，并逐步恢复被错误终止的频道，包括Enderman的频道。其他受到影响的用户也陆续表示YouTube已恢复了他们的频道。

总结:

此次事件突显了YouTube算法强制执行措施可能造成的负面影响，以及对创作者生计的潜在威胁。尽管YouTube正在努力纠正错误，但该事件引发了人们对平台审核机制的担忧，并强调了人工审核在内容管理中的重要性。

人工智能革命与版权法的转变：科技巨头权力演变总结

本文探讨了人工智能革命背景下，科技巨头对美国版权执法和政府干预的控制权逐渐增强的现象，以及由此引发的道德和法律困境。

核心要点：

• 过去：打击盗版，维护软件巨头利益： 自九十年代中期以来，以微软为首的软件巨头积极在全球范围内打击版权侵权和网络盗版。他们通过商业软件联盟（BSA）等组织，推动更严厉的处罚措施，并游说联邦调查局（FBI）对涉嫌非法内容共享服务器的国外主机采取行动。微软曾将打击数字盗窃描述为一场针对“有组织犯罪集团”的斗争。
• “阿伦·斯瓦茨”事件： 2011年，美国司法部因阿伦·斯瓦茨未经授权下载JSTOR学术论文库而对其提起刑事诉讼，最终斯瓦茨选择自杀，该事件标志着当时版权执法的严厉程度。
• 现在：人工智能训练数据争夺，盗版成为常态： 随着人工智能的兴起，科技巨头（Meta、Anthropic、Microsoft、Google、xAI、OpenAI等）正竞相收集海量数据，用于训练人工智能模型。这些数据中，大量受版权保护的材料（如学术文章、小说和非小说书籍）成为最宝贵的资源。
• 政府态度转变： 过去对版权侵权行为严厉打击的政府，现在似乎对科技巨头大规模利用盗版内容的行为不感兴趣，执法权更多地依赖于民事诉讼。
• 科技巨头的“双标”： 曾经将点对点和暗网盗版视为对经济造成数十亿美元损失的“生存威胁”的微软，现在被指控利用与非法论坛相同的方式获取大量受版权保护的学术文章、小说和非小说书籍。
• 公开承认盗版行为： 科技巨头实际上已经承认，他们的大部分先进模型都是通过利用大规模盗版数据开发的。例如，Meta承认使用Library Genesis（一个托管在俄罗斯服务器上的盗版书籍库的镜像）来训练其生成式人工智能系统，并有内部沟通记录显示，该行为已获得CEO马克·扎克伯格的批准。

总结：

文章揭示了科技巨头权力演变，以及人工智能发展带来的版权困境。过去，科技巨头积极游说政府打击盗版，保护自身利益；如今，他们却利用盗版内容训练人工智能模型，而政府监管趋于宽松。这种现象突显了科技行业对美国治理的影响力，以及在人工智能时代版权保护面临的挑战。

文章标题：Optimism associated with exceptional longevity (2019)（乐观与非凡长寿相关）

内容摘要： 提供的文本未包含与标题相关的实质性文章或研究内容。正文仅显示了一句系统账户提示语，说明如果输入的地址与现有账户匹配，用户将收到一封包含检索用户名说明的电子邮件。由于缺乏实际的论文文本，无法从中提取关于乐观情绪与非凡长寿之间关联的任何科学细节或结论。

汉明林的故事：一个童话传说背后的真实历史？

摘要： 这篇文章探讨了关于汉明林镇的“魔笛吹手”的传说，以及它与该城镇的真实历史之间的联系。虽然格林兄弟和罗伯特·勃朗宁等作家将这个故事改编成艺术作品，但越来越多的证据表明，这个传说可能源于13世纪的一次真实事件。

主要内容：

• 汉明林镇与魔笛吹手： 汉明林镇（德国下萨克森州）每年都会有扮演魔笛吹手的迈克尔·博耶尔带领游客参观，并讲述这个著名的传说。这个传说讲述了一个被雇来消灭老鼠的吹笛手，在被拒绝支付报酬后，用他的音乐引诱了汉明林镇的130名儿童离开了城镇，从此失踪。
• 悠久的历史渊源： 魔笛吹手的传说在文学和艺术中留下了深刻的印记，例如歌德的诗歌、格林兄弟的童话和勃朗宁的诗歌。
• 历史证据： 汉明林镇的真实历史与传说之间存在着令人惊讶的联系。
  • 铭文： 位于“魔笛吹手”住宅的石墙上刻有铭文，日期为1284年6月26日，详细描述了130名儿童在卡尔瓦里附近跟随一位穿着彩色衣服的吹笛手消失的事件。
  • 城镇记录： 汉明林镇的城镇记录中记载，1384年当地居民哀叹：“距离孩子们离开已经100年了。”
  • 教堂玻璃： 圣尼古拉斯教堂的彩色玻璃窗（虽然在17世纪被毁）据称描绘了魔笛吹手带领一群白色幽灵般的儿童。
  • 古老文献： 15世纪的吕讷堡手稿和其他历史记忆诗歌都记录了1284年6月26日130名儿童或年轻人在跟随魔笛吹手前往卡尔瓦里或科潘地区消失的故事。
• 可能的历史解释： 历史学家提出了多种解释来解释这个谜团：
  • 移民： 魔笛吹手可能是一个“定位者”或“招聘者”，负责组织德国人向东欧移民。
  • 舞蹈狂热： 类似于13世纪在其他地区爆发的舞蹈狂热现象，孩子们可能因某种原因集体离开城镇。
  • 宗教冲突： 孩子们可能在参加中夏节庆祝活动时遭到当地基督教势力的袭击或绑架。
• 普遍的恐惧： 传说之所以能经久不衰，是因为它触及了人们对失去孩子和终结的普遍恐惧。
• 文化遗产： 魔笛吹手的传说已成为一个全球性的文化遗产，被翻译成多种语言，并在世界各地的艺术和文学中得到体现。

总结： 汉明林镇的魔笛吹手传说不仅仅是一个童话故事，它可能根植于13世纪的真实历史事件。虽然具体发生了什么仍然是一个谜，但这个传说仍然提醒着人们对失去和未知的恐惧，并连接了世界各地的人们。

SimpleText 代码修改总结 (Summary of SimpleText Code Modification)

本文记录了作者修改 SimpleText 程序，使其在启动时打开一个更小的文本窗口的过程。最初作者认为修改很简单，但实际操作却遇到了许多挑战，并从中学习到不少经验。

核心问题与解决方案：

• 目标： 修改 SimpleText 启动时窗口大小。
• 挑战： 无法直接修改常量，需要更复杂的代码注入。简单的代码插入会导致后续代码跳转错误。
• 解决方案：
  • 代码注入： 作者通过在代码资源末尾注入自定义代码来解决问题，并通过跳转指令将程序流程引导到自定义代码。
  • 代码替换： 在注入代码中，作者只保留了获取菜单栏高度 (MBarHeight) 的部分功能，并将结果返回，避免了原始代码中的窗口调整逻辑。
  • 结果存储： 为了在后续的代码中判断是否需要应用新的窗口大小，作者将第一次子例程的结果存储起来，并在后续调用时进行检查。
  • 代码存储： 由于无法添加全局变量，作者在代码资源本身中存储了变量。

技术细节：

• 工具： 使用 Apple developer CDs 中的代码编辑器和 ResEdit。
• 目标代码： 修改 CODE 资源，搜索 \_SizeWindow (A91D) 或相关系统调用。
• 代码结构： 修改主要集中在 Anon48 例程中。
• 代码技巧：
  • 寄存器使用： 使用 D0-D2, A0-A1, FP0-FP3 寄存器传递参数给 C 函数。
  • JSR 替代 BSR： CodeWarrior 不支持 BSR 指令，使用 JSR 代替。
  • 代码顺序： 被调用的例程必须位于调用例程之前，以生成短相对跳转。
  • 代码位置： 将自定义代码放置在 CODE 资源末尾的字符串常量之后。
  • 资源定义： 添加了一个 TMPL 资源，用于方便地重新定义窗口大小。

其他注意事项：

• ResEdit 问题： 作者在使用 ResEdit 2.1.3 时遇到了数据损坏问题，可能存在 bug。
• GetHandleSize： 避免使用 CodeWarrior 的库，直接调用系统 GetHandleSize。
• 调试： 将原始子例程编写为真正的 C 函数，并将寄存器到 C 函数的转换编写为包装器，以方便调试。

**总而言之，**作者通过巧妙的代码注入和跳转技术，成功地修改了 SimpleText 的窗口大小，并分享了在修改过程中遇到的技术挑战和解决方案。 虽然这些信息可能对大多数人没有用处，但对于那些尝试修改旧软件的人来说，也许可以避免一些令人沮丧的问题。

微软 Z-80 SoftCard：Apple II 上的 CP/M 体验

微软 Z-80 SoftCard 是一款用于 Apple II 电脑的扩展卡，旨在使其能够运行 CP/M 软件。 值得注意的是，它也是微软的第一款硬件产品，在 1980 年是该公司最大的收入来源。

技术背景与挑战：

Apple II 使用 6502 处理器，而 CP/M 则运行在 8080 处理器上。 为了在 Apple II 上运行 CP/M，SoftCard 采用了 Zilog Z80 处理器，它在性能上优于 8080。 然而，如何让 Z80 和 Apple II 原有的 6502 处理器协同工作，成为了一个挑战。

处理器协同工作机制：

理想情况下，应该关闭 6502 处理器，但由于一些任务仍需要它来处理，因此无法完全关闭。 SoftCard 通过让 6502 认为它正在执行 DMA（直接内存访问）操作，使其暂停并等待 DMA 完成。 然而，暂停时间过长会导致 6502 寄存器失效。

为了解决这个问题，SoftCard 利用了 Z80 的 REFRESH 信号，该信号指示 Z80 处理器当前未访问内存，这使得外部内存刷新电路能够运行，从而保持 RAM 数据的刷新。 Apple II 的视频电路负责内存刷新，SoftCard 利用该信号让 6502 处理器执行少量指令（通常是循环等待），以维持其寄存器的刷新。 当 SoftCard 需要 6502 执行实际工作时，它会更新内存，指示 6502 退出循环并执行任务，完成后再返回。

内存映射和地址重映射：

Z80 和 6502 处理器都将内存的前 256 字节视为特殊区域，并希望用于不同的目的。 此外，CP/M 程序通常从地址 $0100 加载，而 6502 处理器将 CPU 堆栈硬编码在 $0100-$01FF 范围内。 Apple II 的内存映射中还存在其他冲突，例如系统监视器使用 $0200-$02FF 作为键盘输入缓冲区，中断向量存储在 $03F0-$03FF 范围内，以及文本视频帧缓冲区从 $0400-$07FF 开始。

为了解决这些问题，SoftCard 采用了地址重映射技术，将 Z80 请求的地址重新映射到物理内存。例如，Z80 请求地址 $0000 时，实际获取的是物理内存 $1000。 这种重映射安排确保了 Apple II 的所有特殊预留地址都被移动到 Z80 内存映射的末尾，而 Apple II 的正常 RAM 则在 Z80 内存映射中占据连续地址空间，起始于 $0000。

内存映射表：

| | 6502 | | Physical | | Z80 | | | | ----------------------------------------- | ----------- | -------- | ----------- | ------------------------------------- | ----------- | ----------------------------------------- | | Special use | $0000–$0FFF | ↘ | $1000–$1FFF | | $0000–$0FFF | normal RAM(contiguous,up toinstalled RAM) | | normal RAM(contiguous,up toinstalled RAM) | $1000–$1FFF | ↗ | $2000–$2FFF | | $1000–$1FFF | | | $2000–$2FFF | $3000–$3FFF | | $2000–$2FFF | | | | | $3000–$3FFF | $4000–$4FFF | | $3000–$3FFF | | | | | $4000–$4FFF | $5000–$5FFF | | $4000–$4FFF | | | | | $5000–$5FFF | $6000–$6FFF | | $5000–$5FFF | | | | | $6000–$6FFF | $7000–$7FFF | |