苹果宣布欧盟地区 iOS、Safari 与 App Store 变更

为遵守欧盟《数字市场法》，苹果宣布对欧盟地区的 iOS、Safari 和 App Store 进行一系列调整，旨在为开发者和用户提供新选项，同时引入保护措施以降低新法规带来的隐私与安全风险。这些变更将随 iOS 17.4 更新于 2024 年 3 月 生效。

核心目标

• 合规 DMA：满足欧盟将 iOS、Safari 和 App Store 指定为“核心平台服务”的要求。
• 开发者新选项：提供应用分发与支付处理的新途径。
• 用户保护：引入新控制措施、信息披露及安全防护，但无法完全消除新风险。

对欧盟地区 iOS 的变更

1. 应用分发新途径：
   • 支持通过替代应用商店分发 iOS 应用，并提供相关 API 和工具。
   • 允许开发者使用非 WebKit 的替代浏览器引擎。
   • 提供互操作性请求表，开发者可申请与 iPhone 硬件和软件的更多互操作性。
2. 非接触式支付：推出新 API，允许银行和钱包应用在整个欧洲经济区使用 NFC 技术。欧盟用户可将第三方非接触式支付应用或替代应用商店设为默认。
3. 安全保护措施（无法完全消除风险）：
   • iOS 应用公证：对所有应用进行基础审核（自动检查与人工审查）。
   • 应用安装说明：在下载前展示应用信息。
   • 市场开发者授权：要求替代应用商店开发者遵守持续保护用户的要求。
   • 额外恶意软件防护：阻止已安装的恶意应用启动。
4. 已知限制与风险：
   • 无法覆盖的风险：包含诈骗、欺诈、有害内容的应用；替代浏览器引擎可能影响性能和电池续航。
   • 功能不兼容：应用内购买之外下载的应用无法使用“家庭购买共享”和“购买前询问”等功能。

对 Safari 的变更

首次在欧盟的 iOS 17.4 或更高版本上打开 Safari 时，系统将显示一个浏览器选择屏幕，提示用户从列表中选择一个默认浏览器。

对 App Store 的变更

1. 开发者新选项：
   • 应用内使用支付服务商处理数字商品和服务付款。
   • 链接至外部网站完成支付，并可在此处告知用户应用外的优惠信息。
   • 提供商业规划工具以评估费用和指标。
2. 用户保护与信息披露：
   • App Store 产品页标签和应用内披露表：告知用户应用是否使用替代支付处理。
   • 新应用审核流程：验证开发者关于支付处理的沟通信息。
   • 增强的数据可移植性：欧盟用户可在 Apple 的“数据与隐私”网站导出 App Store 使用数据。
3. 已知限制与风险：
   • 使用替代支付时，苹果无法提供退款或充分支持处理问题、诈骗。
   • “报告问题”、“家人共享”等功能不适用于此类交易。
   • 用户可能需要向更多方分享支付信息，增加敏感财务信息泄露风险。

新业务条款（针对欧盟应用）

开发者可选择采用新条款或保留现有条款。使用新功能（替代分发或支付）必须采用新条款。

1. 降低佣金：
   • App Store 上的 iOS 应用佣金降至 10%（适用于大多数开发者及订阅首年后）或 17%。
2. 支付处理费：
   • 使用 App Store 支付处理需额外支付 3% 费用。使用应用内 PSP 或链接至网站支付则无需向苹果支付此费用。
3. 核心技术费用：
   • 对于从 App Store 和/或替代应用商店分发的 iOS 应用，每年首次安装超过 100 万次后，需为每次首次年度安装支付 €0.50。
4. 对于 iPadOS、macOS、watchOS 和 tvOS 上的应用，使用 PSP 或链接支付可获 3% 的佣金折扣。

时间与资源

• 新功能现已在 iOS 17.4 测试版中可供开发者测试。
• 正式向 27 个欧盟国家的用户推送将在 2024 年 3 月开始。
• 苹果将于三月提供更多资源，帮助欧盟用户理解变化并应对新风险。

Oasis Linux 系统概述

Oasis 是一个小型 Linux 系统，其设计风格更接近 BSD 而非传统 Linux 发行版。其主要特点和设计理念如下：

核心特性

1. 完全静态链接：系统所有软件（包括显示服务器 velox 和浏览器 netsurf）均为静态链接。此设计消除了动态链接库升级带来的问题，并生成可独立运行、便于跨系统复制的二进制文件。

2. 快速可重复构建：使用 samurai 构建工具，并通过 Lua 脚本生成构建清单。这虽然增加了前期打包成本，但降低了维护成本，并带来了近最优的构建时间、可预测和可重复的构建结果、更少的构建时依赖以及跨包增量构建等优势。

3. 极简的引导依赖：仅需一个具备 git、lua、curl、sha256 工具、标准压缩工具和 x86_64-linux-musl 交叉编译器的 POSIX 系统即可引导构建，支持从 macOS、OpenBSD 等非 Linux 系统进行交叉编译。

4. 使用 BearSSL 作为系统 TLS/加密库：通过 libcurl 和 libtls-bearssl（基于 BearSSL 的 libtls 替代实现）在整个系统中使用 BearSSL，仅少数可选包仍需要 LibreSSL。

5. 无传统包管理器：用户通过配置规格来指定系统中需要包含哪些包的哪些文件。构建系统将生成的文件系统树写入一个 git 仓库，该仓库可被合并到根目录或从其他机器拉取。

6. 与系统无关的包管理系统兼容：为保持基础系统精简且专注，Oasis 与 pkgsrc 和 nix 配合良好，便于用户扩展所需软件。

7. 极简的系统配置：设计原则是让 /etc 目录足够简单，使系统管理员能完全理解并适当定制。默认配置中最复杂的文件 /etc/rc.init 仅有 16 行。

8. 大体符合 ISO C 标准：项目目标是用 cproc（一个比 GCC/Clang 更严格符合 ISO C 标准且体积小得多的 C 编译器）进行构建。目前所有核心包及大部分其他包已能成功用 cproc 编译。

设计原则

• 软件复杂度应包括所有传递依赖。
• 可执行文件应静态链接。
• 软件组件应易于定制和修改。
• 包源码应通过 URL 或 git 子模块引用，而非直接包含。
• /etc 应简单到足以被完全理解。
• 补丁应组织良好、有清晰描述且能干净地应用。

软件选择

Oasis 尽可能选用更小、更简单的库和工具实现，例如：

• musl 替代 glibc
• sbase 替代 coreutils
• ubase 替代 util-linux
• bearssl 替代 openssl
• oksh 替代 bash
• vis 替代 vim 或 emacs
• velox 替代 Xorg
• samurai 替代 ninja

这些软件包被分组归类，完整列表位于 pkg 目录。用户亦可选择通过 pkgsrc 或 nix 安装其他软件。

安装与体验

安装指南可在项目 Wiki 找到。项目仍处于积极开发中，用户需具备自行编译内核和解决问题的能力。对于想尝试的用户，官方提供了包含根文件系统、Linux 内核和启动脚本的 QEMU 镜像。

社区联系

项目设有邮件列表 ~mcf/oasis@lists.sr.ht 和 IRC 频道 #oasis (libera.chat)，供提问、提交补丁和讨论。

国际法院裁决要求以色列采取措施防止加沙发生种族灭绝，但未下令停火。该裁决由南非提起诉讼引发，核心内容包括要求以色列竭尽全力防止加沙的死亡、破坏及任何种族灭绝行为，确保人道主义援助进入，并惩治煽动种族灭绝言论。法院还呼吁哈马斯释放人质。

该裁决被视为对以色列战时行为的严厉批评，并要求以色列在一个月内提交执行情况报告。尽管裁决具有法律约束力，但以色列总理内塔尼亚胡誓言继续战争，称讨论种族灭绝指控是“耻辱”。分析指出，未直接下令停火使以色列避免了与联合国机构的正面冲突。

国际社会反应不一：联合国秘书长呼吁以色列遵守裁决；美国表示种族灭绝指控“毫无根据”，但敦促以色列减少平民伤害；巴勒斯坦方面称裁决应为以色列敲响警钟。南非政府认为裁决表明“以色列在加沙的行动存在种族灭绝的合理性”。自冲突爆发以来，加沙已有超过2.6万人死亡，约85%人口流离失所。

火星直升机“机智号”因旋翼叶片受损结束任务

NASA历史性的火星直升机“机智号”任务已正式结束。尽管直升机仍保持直立并与地面控制器通信，但1月18日最后一次飞行的图像显示，其一个或多个旋翼叶片在着陆时受损，导致其无法再飞行。

超越预期的成就 “机智号”原计划作为技术验证任务，在30天内最多进行5次实验飞行。然而，这架首个在另一星球飞行的航空器在火星表面工作了近三年，共完成72次飞行，飞行距离是计划的14倍以上，总飞行时间超过两小时。NASA局长比尔·尼尔森称其“飞得比我们想象的更高、更远”，并帮助NASA实现了“不可能变为可能”。

任务结束与后续 在1月18日的飞行中，“机智号”按计划升至40英尺（12米）高度并悬停4.5秒，但在下降至距地约3英尺（1米）时与作为通信中继的“毅力号”火星车失联。次日通信恢复，数天后到达的图像揭示了叶片损伤。通信中断和着陆时的具体情况仍在调查中。

NASA于1月25日举行媒体电话会议，由行星科学部门、喷气推进实验室（JPL）负责人及“机智号”项目经理参与，介绍任务详情。

扩展任务中的挑战与韧性 在超出原计划33倍、持续近1000个火星日的扩展任务中，“机智号”团队克服了多重挑战：

• 直升机升级后能在复杂地形自主选择着陆点。
• 应对了一个传感器失效问题。
• 在尘暴后自行清洁。
• 在48个不同起降点作业。
• 执行了三次紧急着陆并度过了火星寒冬。 由于设计用于春季，冬季时“机智号”无法为加热器持续供电，导致计算机冻结和重启，团队需重新设计冬季操作以维持飞行。

未来计划与历史遗产 “机智号”团队将对直升机系统进行最终测试，并下载其存储器中剩余的图像和数据。由于“毅力号”距离较远，无法对直升机进行最终成像。

项目经理Teddy Tzanetos指出，“机智号”不仅携带着莱特兄弟“飞行者一号”的织物样本，更证明了在另一世界飞行的可行性。此次任务为未来太空探索留下了不可磨灭的印记，将激励未来数十年在火星及其他世界使用航空器。

背景信息 “机智号”由NASA JPL建造和管理，得到NASA科学任务理事会支持，Ames和Langley研究中心提供了关键分析和技术援助，AeroVironment、高通和SolAero等提供了设计和部件支持。

Portable EPUBs

作者：Will Crichton

核心提案：本文档提出了一种用于创建下一代可移植文档（Portable EPUBs）的方案。该提案旨在定义一种新的文档格式或标准。

文档性质：该内容本身是一个技术提案的展示页面。实际提案内容由加载的JavaScript模块 (./assets/index-b8aLBJvQ.js) 动态渲染，初始HTML结构不包含具体的论述文本。

研究概述

一项发表在《国家癌症研究所杂志》上的苏格兰历史性研究表明，HPV疫苗在预防宫颈癌方面具有显著的现实效果。

核心发现

• 零病例：在1988-1996年间出生、且于12-13岁完成HPV疫苗接种的女性群体中，未发现任何宫颈癌病例。这是首个基于全国性队列、经长期随访得出该结论的研究。
• 接种时机至关重要：在14岁前（通常在性行为开始前）接种疫苗的女性，即使未完成全部三剂接种，也未出现宫颈癌病例。
• 年龄与效果：在14-22岁期间接种三剂疫苗的女性，宫颈癌发病率（3.2例/10万）显著低于未接种女性（8.4例/10万），但仍存在病例。
• 社会效益：疫苗对社会经济地位较低的女性群体保护作用尤为明显，而该群体通常宫颈癌发病率更高。

疫苗与筛查说明

• 疫苗类型演变：研究期间所用疫苗从针对HPV 16/18型的二价疫苗（Cervarix）逐步升级至覆盖更多HPV型别的四价（Gardasil）和九价疫苗（Gardasil 9）。
• 持续筛查必要性：由于早期疫苗未覆盖所有高危HPV型别，接种后仍需定期进行宫颈癌筛查以检测由其他型别引起的病变。

公共卫生意义

• 高接种率是关键：苏格兰通过校园免疫计划实现了约90%的高接种率，而美国同龄人群接种率仅略高于60%。研究强调了提高疫苗接种普及率的重要性。
• 群体免疫效应：大规模队列接种能在社区内形成强大的群体保护效应。

专家评价

研究结果虽处于初步阶段（因疫苗效果显现需要较长时间），但已被国际专家认为“极其令人振奋”，证实了HPV疫苗在真实世界中的卓越效力。

有损CSS压缩：cssfact工具

概述
作者利用空闲时间开发了cssfact，一个有损CSS压缩器。该工具通过减少CSS规则数量来压缩样式表，允许用户配置输出规则数量以控制信息损失程度。它仅处理样式规则，非样式规则保持不变。

核心方法
采用二进制矩阵分解（BMF）在布尔代数中实现。CSS被表示为二进制矩阵：

• 行对应CSS选择器，列对应声明（或反之）。
• 通过BMF将矩阵A近似分解为A' = B × C，其中B和C为二进制矩阵，秩r远小于原始维度（m和n）。
• 布尔代数中矩阵乘法对应CSS规则：1表示选择器应用了声明。
• BMF问题是NP-hard，因此使用近似算法；作者集成了Barahona和Goncalves 2019的算法，虽速度较慢但易于实现。

功能与示例

• 可配置输出规则数量，信息损失率随规则减少而增加。
• 示例：作者主页CSS（55条规则）在不同设置下的效果，如1条规则时信息损失93%，30条规则时损失17%。
• 工具输出压缩后的CSS，保留大部分原始信息。

动机与应用

• 探索乐趣及潜在实用价值：帮助分析CSS代码库，识别冗余规则（如相似组件可合并）。
• 作者指出该工具不适用于自动化流程（如CI管道），但可用于手动审查和优化样式表。

技术细节

• 输入CSS矩阵维度示例：m=60（选择器），n=81（声明），大型样式表可达数千。
• 未处理规则重叠和优先级，假设所有规则同等重要。

总结
cssfact通过BMF实现有损CSS压缩，提供可配置的规则减少，有助于探索CSS结构并提示优化方向。

关于文章《Impacts of lid closure during toilet flushing》的内容获取情况

根据所提供的内容，无法获取到关于“马桶冲水时关闭盖子的影响”的具体文章内容。实际访问到的页面是一个安全验证页面，由Cloudflare服务提供。

关键信息摘要如下：

• 目标文章：标题为《Impacts of lid closure during toilet flushing》，旨在研究马桶冲水时关闭盖子所产生的影响。
• 实际页面状态：访问请求被拦截，呈现为一个中间验证页面。
• 页面核心要求：
  • 需要启用浏览器中的 JavaScript 和 Cookies 功能才能继续访问。
  • 该页面使用了 content-security-policy 等安全策略来限制资源加载。
• 页面技术细节：页面代码显示，它加载了一个来自 challenges.cloudflare.com 的脚本，用于处理安全挑战。页面设计为在360秒后自动刷新。

结论：由于原始文章内容被安全验证机制拦截，无法对其具体的研究方法、数据、结论或影响进行任何总结。建议启用JavaScript后重新尝试访问以获取完整内容。

CNC激光切割与雕刻技术指南

⚠️ 安全警告

激光切割机存在永久性视力损伤和火灾风险。必须严格遵守以下安全规范：

• 必须使用外壳：禁止在开放环境中使用，外壳需配备可靠的排烟系统（向室外排放并过滤）和联锁装置（开门自动断电）。
• 人员安全：严禁在生活区使用，确保儿童和宠物远离，操作时全程监督。
• 材料禁令：绝对禁止切割PVC（产生剧毒氯气）、聚碳酸酯（需惰性气体环境）和未认证皮革（有毒烟雾）。
• 个人防护：根据激光波长佩戴专用防护眼镜（通常为橙褐色），优先通过摄像头监控，避免直视光束或反射。
• 应急措施：配备灭火器、火灾探测系统和外部紧急停止按钮。

🔧 设备选择要点

激光切割机属于“减材制造”工具，通过蒸发或熔融材料成型。选择时需关注：

• 输出功率：注意区分光学输出功率（瓦特）与输入功率。入门级二极管激光器通常为5-40W，功率越高切割能力越强，但多二极管阵列可能导致光斑变大。
• 激光类型：
  • 二极管激光器：成本低（＜1000美元），波长可见（400-800nm），适合业余使用，但需自行加强安全措施。
  • 光纤激光器：波长为红外（780-2200nm），适合切割金属，但危险且昂贵。
  • CO2激光器：波长长（9.3-10.6μm），用途广泛但维护复杂。
• 切割床尺寸：根据项目需求选择，大尺寸减少材料浪费但占用空间。
• 空气辅助：必备功能，气流（10-15升/分钟）清除切割区碎屑，提高深度和质量。
• 精度与速度：典型精度约0.1毫米，速度受激光功率、电机和导轨质量影响。

📐 设计与软件流程

1. 设计工具：使用CAD（如AutoCAD）、绘图软件（如Inkscape）或参数化工具（如OpenSCAD）创建矢量文件（SVG/DXF/JPG）。
2. 驱动软件：将设计转换为G代码控制激光器。推荐工具：
   • LightBurn（功能全面，支持Linux）
   • LaserGRBL（免费）
   • 其他选项：OpenBuilds、LaserWeb等。
3. 材料测试：建议对不同材料进行功率-速度测试，优化切割参数。

🪵 材料切割指南

• 木材/胶合板：可切割（如18mm桦木胶合板需80%功率/300mm/分钟/3次过切），但边缘会碳化，可通过打磨或涂层改善。避免含酚醛树脂的胶合板。
• 纸板/纸张：可高速切割，关闭空气辅助以防吹散。
• 金属：二极管激光器几乎无法切割金属，仅适用于阳极氧化铝雕刻或不锈钢标记（需使用专用涂料）。
• 丙烯酸/塑料：多数塑料会产生毒气或融化，不建议切割。
• 皮革：不推荐（异味大、有毒性风险）。

💡 实用技巧

• 切割厚材料：可双面切割（翻转材料并对准定位孔）或叠层粘接薄材实现三维结构。
• 维护光学部件：定期用镜头布清洁聚焦镜，避免烟雾沉积永久损坏。
• 固定材料：使用夹具或胶带防止移动，特别适用于轻质材料。
• 优化气流：确保空气辅助系统畅通无阻，根据材料调整气压。

📚 参考资源

• 社区论坛：Reddit的r/lasercutting。
• 设计资源：Festi.info、MakerCase、3axis.co等在线设计库。
• 详细指南：《游击队CNC指南》及GitHub相关项目。

本文档为持续更新版本，首次发布于2024年1月26日。

O-1“特殊能力”签证申请经验总结

本文为一位创始人申请美国O-1签证的个人经历分享，旨在为他人提供参考。

一、 签证基本介绍

O-1签证适用于在科学、艺术、教育、商业或体育领域具有“非凡能力”的个人。该签证最初有效期为3年，可逐年无限续签。作者认为，此途径非常适用于初创公司创始人。

二、 个人申请时间线

• 2022年夏季：辞去原公司Wave的工作，创办自己的初创公司Path。
• 2022年9月16日：与律师讨论申请O-1签证的可能性。
• 2022年10月21日：向美国公民及移民服务局（USCIS）提交申请，并选择加急处理。
• 2022年10月27日：收到批准通知。
• 2023年1月5日：在伦敦美国大使馆参加领事面谈，随后获得签证。

三、 如何满足“非凡能力”标准

申请人需满足8项标准中的至少3项。作者满足了以下4项：

1. 国家或国际认可的奖项：作者通过初创公司的融资来证明。关键在于证明投资者是谨慎且有选择性的。作者提交了已签署的SAFE协议、融资总额证明、投资者介绍信及简历，以佐证投资者的甄别能力。
2. 在科学、学术或商业领域的原创贡献：基于作者在前公司Wave的工作经历。Wave在非洲金融科技领域面临独特挑战，因此作者参与的项目具有行业原创性。提交的证据包括雇佣合同、前公司高管的推荐信以及在PyCon Africa的会议演讲资料。
3. 在知名组织担任关键职位：
   • 在现公司Path：作为创始人、大股东和董事会成员，证明了其关键作用。通过展示公司融资近10万美元及入选法律科技沙盒计划来证明公司声誉。
   • 在前公司Wave：通过高管的推荐信，证明作者是早期员工并参与了关键项目。通过媒体报道Wave的2亿美元A轮融资来证明公司声誉。
4. 获得高薪酬或报酬：
   • 法律依据：USCIS政策手册指出，对于企业家，其持有的高价值公司股权可被视为与高薪标准具有同等重要性。
   • 具体证明：作者展示了在前公司Wave的总薪酬（基本工资+股权）高于纽约市软件工程师薪酬水平的前10%。证据包括期权证书和12个月的工资单。

四、 申请费用

2022年申请时，政府申请费为460美元，加急处理费为2500美元。截至2024年4月1日，费用已上调，根据公司规模不同，总费用在3635美元至4460美元之间。此外，移民律师费用通常在6000至10000美元之间。

五、 是否应聘请律师？

作者强烈建议聘请移民律师，特别是对美国移民系统不熟悉的人。律师帮助作者意识到了一些关键点，例如：融资可作为“奖项”证明，股权可用于满足高薪标准。文中推荐了几位律师和相关支持服务，如Lighthouse（快速准备申请）、Plymouth Street（技术支持型律所）等社区和工具。

漏洞概述

CVE-2023-40547 是一个存在于 shim 引导加载程序中的安全漏洞，涉及通过 HTTP 或相关协议获取文件时对 HTTP 头部的信任问题。

漏洞原理

当 shim 通过 HTTP 获取文件时，它会根据 HTTP 响应头中的 Content-Length 等信息来分配内存缓冲区。然而，攻击者可以操纵 HTTP 头部，指定一个小于实际接收数据大小的值。代码错误地使用该头部值进行内存分配，但实际从接收缓冲区复制数据时却依赖协议元数据（即实际接收到的数据大小）。这导致了一个典型的越界写入问题，攻击者可借此覆盖缓冲区外的内存数据。

安全影响

此类越界写入漏洞可能导致：

• 程序崩溃（拒绝服务）。
• 潜在的任意代码执行，从而控制整个系统。

修复方案

该漏洞的补丁通过添加额外检查来修复：在将数据从接收缓冲区复制到已分配内存之前，验证实际接收缓冲区的大小不超过预先分配的内存大小。这一检查确保了内存分配与实际数据量匹配，防止了越界写入。

元数据

• 报告者：Bill Demirkapi（Microsoft Security Response Center）
• 提交者：Peter Jones pjones@redhat.com
• 变更：1 个文件，7 行新增，1 行删除

文章摘要：《The things nobody wants to pay for》

本文探讨了自由软件社区的成就与挑战，重点指出了公司在资助开源项目时倾向于短期收益，而忽视对关键基础设施和维护工作的支持，这威胁到社区的长期可持续发展。

自由软件的成功与公司贡献

• 自由软件社区通过志愿者和公司的合作，构建了价值数十亿美元的代码库，成为协作开发的典范。
• 历史上，公司如Cygus Computing和X Window系统联盟为GNU项目和Linux内核的发展提供了资金，推动了自由软件的快速进步。

核心问题：公司资助的狭隘性

• 公司往往只愿意资助与短期收入直接相关的工作，例如硬件驱动开发，而忽视文档编写、代码审查、测试基础设施、工具维护和桌面环境支持等非收入驱动的领域。
• 这种行为导致社区关键部分资源匮乏，影响了整体健康和用户体验。

具体案例

1. Linux内核测试基础设施：在linux-kernel邮件列表中，开发人员指出缺乏测试基础设施是因为没有公司愿意支付相关工作，导致进展停滞。
2. b4工具开发：kernel.org维护者Konstantin Ryabitsev因资源未分配而无法推进b4工具，尽管该工具极大提升了维护效率，但缺乏公司支持。
3. Linux桌面支持减少：Red Hat和SUSE等公司减少对KDE、Thunderbird等桌面应用的支持，因为桌面开发未带来足够收入；类似地，Ubuntu在2017年裁减了桌面相关员工。
4. PyPI仓库资助：Python社区讨论中，志愿者指出公司依赖“别人会做”的心态，不愿资助关键基础设施，导致负担落在少数志愿者身上。

可能的解决方案与局限性

• 批评与倡导：向公司施压可能有一定效果，但有限。
• 组织支持：Linux基金会（LF）等组织可以协调资源，但需优先满足付费公司的需求。
• 政府资助：在市场失灵的领域，政府可以提供支持，但受政治环境制约。
• 志愿者依赖：回归志愿者模式虽可行，但效率低下且不具备包容性，可能阻碍进步。

结论

• 自由软件社区已克服诸多挑战，但需找到新方法以平衡公司利益与社区需求。文章呼吁社区探索创新方案，确保可持续发展，避免依赖不稳定的志愿者贡献。

（摘要字数：约450字）

tinySA 小型频谱分析仪与信号发生器概述

tinySA 是一系列兼具频谱分析仪和信号发生器功能的小型便携设备。其主要型号及功能如下：

产品型号与主要规格

tinySA Basic

• 屏幕：2.8英寸彩色显示屏，最多显示290个扫描点。
• 频谱分析模式：
  • 高频输入：0.1 MHz - 350 MHz（高品质）。
  • 超高频输入：240 MHz - 960 MHz（品质较低）。
• 信号发生模式（不作为分析仪使用时）：
  • 正弦波输出：0.1 MHz - 350 MHz。
  • 方波输出：240 MHz - 960 MHz。
• 分辨率带宽：可切换，范围在2.6 kHz 至 640 kHz 之间。

tinySA Ultra ZS405

• 屏幕：4英寸彩色显示屏，最多显示450个扫描点。
• 频谱分析模式：
  • 标准模式：0.1 - 800 MHz。
  • 启用Ultra模式后：可达5.3 GHz（电平校准至6 GHz，可观测信号至12 GHz）。
• 信号发生模式：
  • 正弦波输出：0.1 - 800 MHz。
  • 方波输出：可达4.4 GHz。
  • 射频测试信号输出：可达5.3 GHz。
• 分辨率带宽：可切换，范围在200 Hz 至 850 kHz。
• 内置可选20 dB低噪声放大器。
• 配备MicroSD卡插槽，用于存储测量数据、设置和屏幕截图。

tinySA Ultra+ ZS406

• 频谱分析模式：
  • 标准模式：0.1 - 900 MHz。
  • Ultra模式：可达5.3 GHz（校准至6 GHz，观测至12 GHz）。
• 信号发生模式：
  • 正弦波输出：0.1 - 900 MHz。
  • 方波输出：可达4.4 GHz。
  • 射频测试信号输出：可达5.4 GHz。
• 其他规格与ZS405相同。

tinySA Ultra+ ZS407

• 频谱分析模式：
  • 标准模式：0.1 - 900 MHz。
  • Ultra模式：可达7.3 GHz（校准至7.3 GHz，观测至12 GHz）。
• 信号发生模式：
  • 正弦波输出：0.1 - 900 MHz。
  • 方波输出：可达6.3 GHz。
  • 射频测试信号输出：可达7.3 GHz。
• 其他规格与ZS406相同。

通用功能与特性

• 可通过USB连接至PC，作为PC控制的频谱分析仪或信号发生器使用。
• 内置可充电电池，支持至少2小时便携使用。
• 内置阶梯衰减器（0 dB 至 31 dB）与校准信号发生器（用于自动自检和低电平输入校准）。
• 最大输入电平为+10 dBm，超出可能损坏设备。

重要限制

• 频谱分析仪与信号发生器功能无法同时使用，因此信号发生器不能作为跟踪发生器。
• 由于低成本和小尺寸，设备存在一定的性能限制（具体限制请参阅官方文档）。

资源与支持

• 官方Wiki与视频：提供入门介绍、详细功能演示及使用指南。
• 用户手册：提供适用于tinySA Basic和tinySA Ultra的详细文档。
• 法律信息：“tinySA”和“tinySA Ultra”为注册商标，未经授权不得用于其他频谱分析仪产品。
• 技术支持：固件基于NanoVNA开发，可通过捐赠支持项目持续发展。
• 注意事项：警告存在劣质仿制品，建议通过官方渠道购买。

这篇文章的核心观点是：LaTeX用户应当将HTML作为主要输出格式，而非仅生成PDF。作者认为HTML是数学和科学内容在网络的未来方向，具备更好的可访问性和跨设备兼容性。

主要建议与理由

1. 优先考虑更简单的工具
   作者在文章开头质疑是否必须使用LaTeX，建议优先评估Markdown、restructuredText等与MathJax结合的方案，尤其对教学场景更友好。

2. 若必须使用LaTeX，应编译为HTML

   • PDF在小屏幕和可访问性方面存在局限，且未来兼容性可能较差。
   • HTML是“数学上网”的关键，作者呼吁用户通过贡献推动其发展。
   • 具体转换工具：推荐使用LaTeXML或tex4ht，并提供简单命令示例：

     latexml --dest=mydoc.xml mydoc.tex
     latexmlpost --dest=mydoc.html --format=html5 mydoc.xml
     

3. 克服转换局限性
   遇到LaTeXML或MathJax的问题时，应主动反馈以推动工具改进。作者还提到其他辅助工具，如xyjax（处理图形）、mathapedia（处理pstricks）、Sage cell server（处理计算）等。

4. 灵活替代方案
   若用户不愿直接转换，可选择能同时输出LaTeX和HTML的编辑工具（如Qute、ReText、FidusWriter、Authorea.com等），并利用pandoc进行格式转换。

讨论中的观点交锋

• michalh21 推荐tex4ht，认为其能处理任何LaTeX文档，但指出HTML在排版美观和阅读体验上仍不如PDF（如字体渲染、分页支持）。
• 作者回应：承认PDF的阅读优势，但强调作者应以读者需求为先。HTML具备交互性和可访问性潜力，需要通过实践推动发展。
• Norman Lewis Perlmutter 提问是否可直接转换PDF到HTML。作者明确反对，指出PDF是“有损格式”，无法准确提取数学结构，转换效果差。
• jessemckeown 询问xyjax是否可能并入MathJax主项目，但未得到作者直接回应。

核心立场总结

作者认为LaTeX用户不应局限于PDF输出，而应拥抱HTML以推动网络数学内容的未来。即使转换存在挑战，也需通过反馈和工具改进逐步解决。同时，他主张根据实际场景选择合适工具（如Markdown+MathJax），而非盲目追求LaTeX的复杂性。

文章标题： The Uncomfortable – a collection of deliberately inconvenient objects

文章内容： "The Uncomfortable" is a collection of deliberately inconvenient everyday objects by Athens-based architect Katerina Kamprani.

摘要： "The Uncomfortable" 是一个由雅典建筑师Katerina Kamprani创作的项目，专门收集故意设计得不方便的日常物品。这些物品通过颠覆常规用途，挑战传统设计理念，旨在引发人们对日常功能和创意的思考。

MotherDuck 与 Numbers Station 合作开源了一个专为 DuckDB 设计的文本到 SQL 大语言模型（LLM）DuckDB-NSQL。该项目旨在降低数据分析门槛，让 AI 助力用户更高效地与数据交互，并回馈 DuckDB 社区。

核心要点

• 项目背景：MotherDuck 观察到用户需要在 ChatGPT 和查询界面间反复切换以编写 SQL，效率低下。此前他们已推出“FixIt”功能来自动修正 SQL 语法错误。
• 模型定位：与主要聚焦于 SELECT 查询的现有文本到 SQL 模型不同，DuckDB-NSQL 旨在帮助用户全面利用 DuckDB 0.9.2 的所有文档特性，包括其丰富的扩展（如查询 Postgres、SQLite、Iceberg，支持 JSON 和 GeoSpatial 类型等）。它被设想为一个“文档预言机”。
• 训练数据：模型使用约 20 万个 经过合成验证的 DuckDB SQL 查询（基于文档指导）以及超过 25 万个 来自 Numbers Station 的通用文本到 SQL 问题进行训练。这使得模型既能生成特定于 DuckDB 的代码片段，也能生成用于回答分析问题的通用 SQL 查询。
• 模型权衡：为实现更快的推理速度和更低的成本，当前选择了较小的模型规模，在表达性上做了一定权衡。
• 开源与可用性：
  • 模型权重已完全发布在 Hugging Face 上。
  • 提供了量化后的 GGUF 格式版本，可通过 llama.cpp 运行。
  • 可以在 Hugging Face Space 上直接体验在线演示（由 OctoAI 提供端点支持）。

使用方式

用户通过自然语言指令向模型描述需求即可获取对应的 DuckDB SQL 查询。指令越具体，结果越准确。 示例：

1. 从 test.csv 创建临时表 tmp： CREATE TABLE tmp AS FROM read_csv_auto('test.csv');
2. 从 taxi 表获取所有以 _amount 结尾的列： SELECT COLUMNS('.*_amount') FROM taxi;
3. 获取 taxi 表中乘客数、行程距离和费用，并按所有字段排序： SELECT passenger_count, trip_distance, fare_amount FROM taxi ORDER BY ALL;
4. 查询 2022 年 12 月的最长行程： SELECT MAX(trip_miles) FROM rideshare WHERE request_datetime BETWEEN '2022-12-01' AND '2022-12-31';

本地运行

用户可以通过项目的 GitHub 仓库或 GGUF 的 readme 文件获取在本地使用 llama.cpp 运行该模型的完整指南。

Merkle CRDTs：将并发状态结构外化

传统CRDTs（如State-based、Op-based、Delta-based）的核心在于合并副本数据，但这只是解决方案的一半。没有存储并发编辑发生时机的机制，合并就无法做出一致的冲突解决决策。通常，State-based CRDTs使用版本向量，Op-based CRDTs使用因果操作日志来完成这项工作。然而，借鉴区块链或Git的思想，Merkle树和DAG 也能胜任此任务。这类CRDTs称为Merkle CRDTs，它们将记录并发编辑的簿记结构作为并发状态的固有结构暴露出来，而非隐藏在容器内部。主要有两种变体：

1. Merkle-DAG CRDTs

• 结构与原理：将CRDTs建模为一个随着并发更新事件而增长的Merkle节点DAG。它是Op-based CRDTs的Merkle化版本，其内部簿记随状态更新次数（而非副本数量）增长。每个节点可以携带操作、状态快照或增量作为有效载荷，且该载荷本身必须是一个CRDT。
• “内外翻转”：可以视为State-based CRDTs的“内部外翻”——通用的簿记部分成为容器（DAG），而载荷特定的簿记则在载荷CRDT内部。
• 同步优势：通过比较根哈希即可判断数据是否相等，通过遍历DAG可以确定差异。同步时，远程副本广播根哈希，本地比较后如不一致，则请求远程发送遍历DAG时的节点哈希列表，从而找出缺失的节点。哈希无需按因果顺序传递，因为Merkle DAG本身就是因果哈希链。
• 优点：
  • 减少网络同步数据量。
  • 同步协议更简单（无需因果顺序传递）。
  • 数据不可变，便于实现差异比较、撤销和来源验证。
• 缺点：数据结构大小随更新事件数量线性增长（尽管Merkle树的结构共享可压缩空间）。

2. Merkle Search Tree (MST) CRDTs

• 结构与原理：MST是一种维护有序键集的树结构，具有三个不变量：节点内键有序；子节点区间正确；层数由键哈希的前导零数量决定。节点的内容ID是其所有键和子节点内容ID的哈希。键存在于所有层级的节点中（不同于B树仅在叶子节点）。
• 关键特性：
  • 自平衡：键的插入位置由哈希确定，天然保证树平衡。
  • 唯一性：对于给定的键集，无论插入顺序如何，MST结构是唯一的。因此，仅比较根哈希即可判断两棵树是否相同。
• 构建CRDT：在MST的每个键上附加一个CRDT载荷。MST本身的有序集合并具有明确语义，载荷的合并则委托给其自身的CRDT解决。载荷CRDT可以非常简单（例如，使用简单的集合或计数器）。
• 同步优势：与Merkle-DAG类似，通过比较根哈希和遍历树结构来减少同步数据量和简化协议。
• 优点：
  • 自平衡、唯一性。
  • 内部簿记不随副本数量或更新事件数量增长。
• 缺点：
  • 攻击者可构造前导零多的键，创建过高的树，降低查询性能（O(log n)退化为O(n)）。
  • 节点大小方差大，可能导致树结构不均匀。

与Git的启示性联系

文章指出，CRDTs需要两个核心要素：满足交换律和结合律的合并算子，以及追踪并发/因果编辑的簿记。传统的CRDTs将簿记隐藏内部，提供简单的状态接口。Merkle CRDTs则将其“内外翻转”，暴露并发编辑和未坍缩状态的内在结构。这与Git的数据结构高度相似——Git同样专注于记录提交历史关系（即簿记），其冲突解决（三方合并）反而是次要的，且默认实现不满足CRDTs所需的代数性质（交换律、结合律、幂等性）。

结论与展望

Merkle CRDTs通过将并发状态结构外化，提供了数据同步的效率优势和历史不可变性。MST尤其具有自平衡和唯一性的吸引力。然而，MST仍存在节点大小方差大和潜在攻击面的问题。作者提到正在探索Prolly Trees等替代数据结构，以期实现更优的可组合CRDTs。

Jared White 表达了他对 Tailwind CSS 的个人反对立场，尽管他承认其开发者有才华。他指出，技术社区中有一种日益流行的观念，认为 Tailwind 是未来，这促使他详细阐述了该框架不适合他的原因。

2022年3月更新：作者指出 JIT 编译器已成为默认方式，但 Tailwind 的发展方向令他更为怀疑。他正在编写一门课程，旨在教授如何从 Tailwind 迁移并使用“原生” CSS。

作者的主要技术异议如下：

1. 丑陋的 HTML 结构：作者认为纯工具类（utility-class）的 HTML 结构在审美上难以接受，即使在使用一年后也无法习惯。虽然 @apply 指令可以用于清理 HTML，但这会引出下一个问题。

2. @apply 的不兼容与非标准性：@apply 指令依赖于 Tailwind 的构建过程，是专有的。这意味着使用 Tailwind 编写的 CSS 文件与其他框架和工具不兼容，形成了供应商锁定。此外，过度使用 @apply 会阻碍开发者学习和掌握真正的 CSS 标准。

3. 设计系统与 CSS 变量：Tailwind 的设计系统和“令牌”（如颜色、间距）通过 JavaScript 定义，而非使用现代浏览器原生支持的 CSS 自定义属性（变量）。作者认为，利用 :root 层级定义 CSS 变量是更标准、更灵活的方式，并且可以在任何地方（样式表、JS、HTML 内联样式）使用。

4. 与 Web Components 的不兼容：Tailwind 完全无法在 Shadow DOM 中使用。作者强调，Web Components 是现代 Web 规范的重要组成部分，而 Tailwind 在这方面表现不佳，未能利用原生浏览器技术。

5. 鼓励使用 <div> 和 <span> 标签汤：作者认为广泛使用通用 <div> 和 <span> 标签是一种反模式。他提倡使用自定义元素（如 <ui-card>）来编写更具语义和表达性的标记，并引用了 Shoelace Web Components 库的示例作为对比。

结论：作者承认 Tailwind 在从零开始快速进行原型设计方面有其优势。然而，综合其在 HTML 审美、CSS 标准兼容性（依赖非标准的 @apply）、设计系统实现（未充分利用 CSS 变量）、与 Web Components 的兼容性以及标记结构等方面的根本缺陷，他认为 Tailwind 并未代表他期望的 Web 发展方向。他最后表示，喜欢 Tailwind 的人可以使用，但不要试图说服他这是未来的技术。

本文探讨了在儿童发展中平衡户外风险游戏与伤害预防的重要性。自由游戏对儿童的身心及社会发展至关重要，但近年来，户外自由游戏和风险游戏的机会显著减少。部分原因在于安全措施旨在预防所有与游戏相关的伤害，而非专注于预防严重和致命伤害。

风险游戏的定义与核心 风险游戏是自由游戏的一种，其特点是令人兴奋、激动，且结果不确定，存在身体受伤的可能性。它区别于其他户外游戏类型，关键在于区分“风险”与“危害”。

• 风险：孩子能够识别、评估并基于自身技能和意愿决定如何应对的挑战（如决定爬多高）。
• 危害：超出孩子识别或处理能力的潜在伤害因素（如设备故障或腐朽的树枝）。 风险游戏旨在消除环境中的危害，同时支持孩子在其经验和能力范围内选择和控制的、适度的风险。

风险游戏的主要益处 研究表明，参与风险游戏对儿童有多重益处：

• 身体活动与健康：增加中高强度的体育活动，减少久坐时间，并有助于培养终身身体活动能力（身体素养）。接触自然环境和松散材料可能对免疫系统调节产生积极影响。
• 心理健康与社会情感能力：有助于培养韧性、冲突解决能力、问题解决技能和风险评估能力。让孩子体验可控的恐惧和不确定性，可能有助于降低焦虑风险。
• 执行功能与社交技能：促进沟通、合作与妥协能力的发展，为学业和终身成就奠定基础。

伤害风险与平衡考量 风险游戏中发生的伤害通常是轻微的软组织损伤。数据分析显示，某些风险活动（如爬树）的伤害率远低于其他常见有组织活动（如足球、自行车、滑冰）。然而，特定群体可能面临不平等挑战，包括：

• 原住民儿童、生活在贫困或边缘化社区的儿童，他们可能面临不同的安全障碍。
• 残障儿童，过度保护可能损害其自尊和独立性，鼓励其参与可控的风险游戏有益。 因此，需要确保所有儿童都能公平、安全地获得风险游戏的机会。

转变观念与提供支持 实现平衡需要转变成年人的观念和沟通方式：

• 避免使用可能传递不信任的模糊警告（如“小心”），转而采用能提升孩子情境意识和 problem-solving 能力的提问式引导。
• 为孩子提供自由游戏时间、松散材料（如树枝、石头）和自然游戏环境，并适度减少近距离监督。

给专业人士的建议

1. 医疗保健提供者：应将户外风险游戏作为促进儿童健康发展和预防肥胖、焦虑等问题的策略之一，在咨询中向家庭介绍其益处。
2. 公共卫生与政策制定者：
   • 支持早期教育工作者和教师，并资助引入风险游戏的机会。
   • 倡导在社区、学校和公园中丰富游戏体验，例如添加松散材料和自然元素。
   • 推动使用如“风险效益评估工具包”等资源，并资助相关培训。

文章强调，目标是在确保防止严重和致命伤害的安全标准的同时，保留并优化能促进儿童发展的、受控的风险游戏机会。

阿尔茨海默症助手：利用40赫兹闪光和声音进行治疗

项目简介

该项目基于新的科学研究，提出通过40赫兹频率的闪光和声音刺激可能对阿尔茨海默症产生积极治疗效果。该工具适用于电脑和智能手机。

主要警告与注意事项

• 癫痫患者慎用：闪光可能诱发癫痫发作。
• 设备兼容性：部分用户报告电脑显示器可能出现异常，建议在智能手机上使用（经验证在iPhone上运行良好且无损坏）。

使用方法

1. 点击蓝色“开始”按钮启动，点击屏幕或按键可停止。
2. 按F11键（仅限Windows）可全屏显示以增强沉浸感。
3. 建议在暗室中使用，将音量调至较高水平或使用耳机。
4. 使用低音炮可增加触觉反馈（同样为40赫兹）。
5. 每次建议至少使用10分钟，研究显示每天1小时持续6个月效果更佳。
6. 手机使用时：将亮度调至最高，闭眼将手机置于眼前；iPhone需关闭静音模式以播放音频脉冲。

作用原理

• 光线通过视网膜刺激视神经，直接连接大脑；声音通过听觉神经传递电信号至大脑。
• 同时以相同频率（40赫兹）刺激两种感官，可能诱导大脑同步神经活动，遵循“神经元同步放电则连接增强”的神经科学原则。
• 40赫兹频率在动物实验中效果最佳，但非绝对精确要求。

科学依据与研究结果

研究1：经颅交流电刺激（tACS）研究

• 背景：阿尔茨海默症与β-淀粉样蛋白（Aβ）和磷酸化Tau蛋白（p-Tau）积聚有关。
• 方法：对轻中度患者进行4周40赫兹tACS治疗，通过PET成像检测蛋白水平。
• 发现：
  • 治疗安全性良好，未报告不良事件。
  • 治疗后脑电波γ频段功率增强，p-Tau水平显著下降（尤其在刺激靶区）。
  • Aβ水平无显著变化，小胶质细胞激活结果不一。
• 结论：初步证实40赫兹tACS可安全降低Tau蛋白水平，需更长期研究验证疗效。

研究2：智能平板应用可行性研究

• 方法：轻度认知障碍（MCI）及早期阿尔茨海默症患者每天使用iPad运行AlzLife应用1小时（含40赫兹光声疗法及认知游戏），持续6个月。
• 发现：
  • 部分患者认知测试（MOCA、BOCA）得分提升。
  • 参与者及护理人员报告主观改善（如语言能力、注意力）。
  • 治疗安全且耐受性良好，但依从性存在挑战（部分患者难坚持每日使用）。
• 结论：40赫兹光声疗法可行且具潜力，需更大规模随机对照试验进一步验证。

免责声明

• 本项目内容仅供参考，不构成医疗建议、诊断或治疗。
• 使用前应咨询专业医疗人员，癫痫患者需特别谨慎。
• 作者对信息的准确性、完整性不作保证，使用者需自行承担风险。

总结

该项目整合了40赫兹感官刺激疗法，基于初步科学研究可能帮助减少阿尔茨海默症相关蛋白积聚并改善认知功能。目前证据显示其安全性较高，但疗效需进一步验证，建议在专业医疗指导下谨慎尝试。

新款铃木Omnichord OM-108详情总结

产品概述与背景

• Omnichord 是铃木乐器于1981年推出的电子乐器，核心特点是自动伴奏功能和竖琴传感器。
• 用户只需按下和弦按钮并在传感器上滑动手指，即可演奏对应和弦的琶音，无需音乐基础，极大地降低了乐器的入门门槛。
• 因其便携性、独特的80年代电子音色和触觉交互体验，在欧美广受欢迎，并逐渐成为一种具有文化标志（cult status） 的乐器。
• OM-108是该系列在停产多年后（最后一款型号为1996年的OM-300）时隔40余年的回归之作。

OM-108核心特性与创新

1. 音色与声音引擎

• 经典复刻：致力于精确重现被奉为音色标杆的OM-84的声音，为此采用了与OM-84相同的真实模拟电路进行音色生成。
• 10种音色：包含复古与现代音色。“omni1”和“omni2”通过模拟电路复刻经典音色；“FM piano”是新增的80年代代表性电钢琴音色；其余音色（如竖琴、钢琴、风琴等）采用PCM音源。
• 叠层功能：继承自OM-84的特色，允许将主音色与副音色叠层播放，通过独立的音量旋钮进行实时控制，增加表现力。

2. 和弦与节奏

• 108种和弦：新增了流行音乐中常用的“sus4”和“add9”和弦，使总和弦数达到108种（型号OM-108的由来），演奏更加直观。
• 10种更新节奏：保留经典节奏名称的同时更新了节奏型，并首次引入了嘻哈（Hip Hop）节奏，增强了对多种曲风的适用性。

3. 操控与演奏

• 敏感竖琴板：采用宽幅设计，对轻触响应灵敏，演奏体验舒适。
• 多功能模式：按下“KEYBOARD”按钮后：
  • 和弦按钮可作为20键旋律键盘（支持八度移位），且可叠加音色。
  • 竖琴板与和弦按钮均可作为鼓垫使用，创造节奏。

4. 连接与扩展

• MIDI OUT接口：可向外发送和弦、竖琴板数据以及鼓垫演奏信息。支持双MIDI通道发送竖琴板数据，便于与外部音源进行音色叠加或混合演奏。
• 监听功能：内置扬声器在连接外部音箱时可切换开关，用于表演时的自我监听。
• 复古切换：可通过特殊开机操作，将鼓组音色切换为OM-84的经典音色。

5. 便携与使用

• 便携设计：内置扬声器，体积小巧，支持电池（8节AA）或外接电源适配器供电，便于携带。
• 实时控制：集成功能可在表演中实时切换伴奏方式，如添加贝斯伴奏或启用鼓引子。

市场动态与周边

• 限量版：2025年12月25日将推出全球限量1000台的红色版本。
• 周边商品：已推出Omnichord主题T恤和小肩包。
• 新闻与评测：自2024年1月在NAMM展会发布以来，持续有艺术家使用展示和媒体评测。

Omnichord产品历史线（简要）

文章梳理了自1981年以来的主要型号，包括：

• OM-27 (1981)：初代，27和弦。
• OM-36/OM-84 (1984)：84和弦，OM-84因其双音色叠层、键盘等功能被视为经典。
• OM-100/OM-200M (1989)：引入更多音色和MIDI OUT（OM-200M）。
• OM-150/OM-250M (1993)：功能进一步丰富。
• OM-300 (1996)：停产前的最后型号。
• Qchord QC-1 (1999)：以“数字歌曲卡吉他”为概念的演变型号。

总结

铃木OM-108并非简单复刻，而是在传承经典音色与设计哲学（易用性、趣味性） 的基础上，进行了现代化升级。它通过模拟电路重现OM-84的传奇音色，大幅扩展了和弦与节奏库，增加了叠层、键盘、鼓垫及MIDI扩展等强大功能，使其既能满足怀旧需求，又能胜任当代音乐创作与表演，是一款面向新老用户的全面进化型号。

中世纪英格兰的法国化程度与影响可归纳为以下几点：

1. 诺曼征服前已存在紧密联系：英格兰与法国精英阶层在诺曼征服（1066年）前就已深度交织。通过宫廷与宗教人士的频繁往来，两国在文化、政治上早有互动。例如，10世纪时，西法兰克王国（法国前身）的一位查理曼后裔便在英格兰的韦塞克斯国王宫廷中长大。

2. 诺曼征服带来的根本性转变：1066年诺曼征服将法国国王、语言及文化直接带入英格兰。此后，英格兰的统治阶层主要由法语使用者主导，法语成为宫廷、法律和行政的主要语言，深刻重塑了英格兰的社会结构。

3. 文化融合与政治纠缠：中世纪英法关系复杂而紧密，尤其体现在精英阶层。英格兰的贵族与王室成员同时拥有法国领地，形成跨海峡的封建纽带，导致两国在政治与文化上长期相互渗透。

4. 潜在的“法国化”可能性：有历史观点指出，这一时期法国可能几乎将英格兰完全纳入其文化政治体系，反映出法国文化对英格兰的强势影响。

Lumos：基于本地LLM的浏览器RAG副驾驶

Lumos 是一个 Chrome 扩展程序，提供本地化的检索增强生成（RAG）副驾驶功能，用于辅助网页浏览。其核心特性包括：

• 完全本地化：由 Ollama 驱动，在用户本地机器上进行模型推理，无需远程服务器支持。
• 核心用途：总结长篇讨论（如问题跟踪、论坛、社交媒体）、新闻文章；查询商业/产品页面评论；解答长篇技术文档问题等。

工作原理与安装配置

1. 依赖本地服务器：需要运行一个本地 Ollama 服务器以支持嵌入数据库和 LLM 推理。
2. 服务器启动：
   • 下载安装 Ollama。
   • 拉取模型镜像（例如 ollama pull llama2）。
   • 启动服务时需设置环境变量 OLLAMA_ORIGINS=chrome-extension://* 以允许 Chrome 扩展的请求，避免 CORS 错误。示例命令：OLLAMA_ORIGINS=chrome-extension://* ollama serve。
3. 扩展安装：
   • 可通过 npm run build 构建项目并加载未打包的扩展。
   • 或从 Releases 页面下载预构建包。
   • 可配置键盘快捷键（如 ⌘L）快速激活。

核心配置选项（Options 页面）

• Ollama 模型：选择要使用的 LLM（如 llama2）。
• 嵌入模型：选择用于向量化的嵌入模型（如 nomic-embed-text）。需设置 OLLAMA_MAX_LOADED_MODELS=2 环境变量以同时加载多个模型。
• 主机地址：默认 http://localhost:11434。
• 向量存储缓存时间：设置 URL 内容在向量缓存中的保留时间（分钟）。
• 内容解析器配置：可自定义不同网站内容的提取规则。配置基于 URL 路径匹配，支持设置分块大小（chunkSize）、重叠（chunkOverlap）以及通过 CSS 选择器（selectors/selectorsAll）指定提取元素。已提供针对 Medium、Reddit、StackOverflow、Wikipedia、Yelp 等站点的示例配置。
• 高亮内容：直接高亮选中的文本会作为提示内容进行处理，而非解析整个页面内容，且不缓存。
• 工具启用：可启用或禁用个别实验性工具，并通过自定义前缀触发。

主要功能与快捷键

• 多模态支持：可处理当前页面中的图片（需支持多模态的模型）。
• 文件附件：支持上传 .csv, .json, .pdf 及纯文本文件。附件内容将通过 RAG 工作流处理。上传附件时会暂停页面内容解析。
• 剪贴板内容：可通过快捷键将剪贴板文本作为文件附件加载。
• 聊天历史：保存和加载对话记录。
• 常用快捷键：
  • ⌘C：复制最后一条消息。
  • ⌘B：加载剪贴板文本为附件。
  • ⌘J：切换禁用内容解析。
  • ⌘K：清空消息。
  • ⌘S：保存聊天到历史。
  • ⌘;：打开/关闭聊天历史面板。
  • Ctrl+C：取消请求。
  • Ctrl+X：移除附件。
  • Ctrl+R：重新生成最后一条回复。
  • （Windows 下将 ⌘ 替换为 Alt）

工具与开发

• 工具调用：Lumos 会根据提示自动调用实验性工具。
• 开发相关：项目提供 npm test（运行测试）、npm run lint（代码检查与格式化）和 npm run build（生产构建）等脚本。

该项目受 Web LLM 项目和 LangChain 的本地 LLM 示例启发，相关技术深入阅读链接已提供。

BrowserEngineKit – Apple Developer Documentation 摘要

目的
BrowserEngineKit 是 Apple 开发者文档中提供的一个框架或工具集，旨在帮助开发者创建能够使用替代浏览器引擎渲染网页内容的浏览器应用程序。它允许在 iOS 或 macOS 等 Apple 平台上集成非默认的浏览器引擎（如 Blink 或 Gecko），从而扩展浏览器开发的灵活性。

关键功能

• 支持集成第三方浏览器引擎，替代系统默认的 WebKit。
• 提供必要的 API 和接口，用于管理网页渲染、导航和交互。
• 确保与 Apple 生态系统兼容，同时满足开发者对自定义浏览器引擎的需求。

文档结构
作为 Apple 开发者文档的一部分，BrowserEngineKit 的文档通常包括框架介绍、API 参考、集成指南和最佳实践。文档内容需通过 JavaScript 加载呈现，当前页面元数据强调了其核心用途。

上下文
该框架反映了 Apple 在支持浏览器多样性方面的举措，允许开发者在遵守平台规则的前提下构建创新浏览器应用。文档旨在为开发者提供技术细节和实现指导。

命令行工具比Hadoop集群快235倍的案例分析

本文探讨了使用标准命令行工具处理数据与Hadoop集群的性能对比，以国际象棋游戏数据统计为例，展示了命令行工具在适当场景下的显著优势。

背景与问题

作者发现一篇使用Amazon EMR和Hadoop处理约1.75GB国际象棋游戏数据的文章，目标是计算胜负平比率。作者质疑在此数据量下使用Hadoop的必要性，因为问题本质是简单的流处理任务。实验表明，Hadoop集群（7个c1.medium节点）处理数据耗时约26分钟，而作者使用笔记本电脑上的命令行工具仅需12秒，处理速度从1.14MB/sec提升至270MB/sec。

命令行工具的优势

命令行工具能构建流处理管道，实现步骤间并行执行，类似于分布式系统中的Storm集群。相比Hadoop的批处理模式，流处理几乎不需要内存，仅存储计数等少量状态。这种管道方式可大幅提升性能，尤其适用于IO密集型任务。

数据与处理管道

数据为PGN格式的国际象棋游戏文件，从中提取结果行（如1-0、0-1、1/2-1/2）。作者构建了渐进优化的管道：

1. 基础管道：使用cat、grep提取结果行，再通过sort和uniq统计，耗时70秒。
2. 优化管道：用awk替代sort|uniq，直接解析结果行并统计，耗时65秒，速度提升约47倍。
3. 并行化处理：通过find和xargs并行化grep步骤，使用-P参数指定进程数，耗时38秒，提升至77倍。
4. 进一步优化：移除grep，让awk直接过滤结果行，并添加聚合步骤，耗时18秒，提升至174倍。
5. 最终优化：用mawk（高性能awk变体）替代gawk，最终耗时12秒，达到235倍速度提升。

性能对比与结论

• Hadoop集群：处理1.75GB数据耗时26分钟，速度约1.14MB/sec。
• 命令行工具：处理两倍数据（3.46GB）仅需12秒，速度约270MB/sec，快235倍。
• 命令行方法内存使用极低，仅存储计数变量；而Hadoop批处理需加载数据到内存，可能引发资源问题。

本文强调，对于中小规模或可流处理的数据任务，命令行工具往往比Hadoop更高效、低成本。Hadoop适用于真正的大规模分布式场景，但当前许多项目中过度使用Hadoop，导致不必要的复杂性和性能损失。

文章摘要：《新的架构战争》

本文探讨了现代软件开发中不同系统架构之间的竞争与演进，核心关注点在于安全、性能与开发者体验的权衡。

核心主题

文章以“架构战争”为隐喻，指出当前技术领域的争论焦点已从传统的服务器架构（如单体应用）转向更现代、分布式和基于边缘的架构模式。这种“战争”的实质是不同技术范式在理念、工具链和生态系统上的全面竞争。

关键点分析

1. 安全考量：文中提及的“Vercel安全检查点”是具体案例，它展示了在特定架构（如边缘计算或Serverless）下，安全机制的实现方式与传统架构（如集中式防火墙）有本质区别。这突显了架构选择如何直接影响安全模型的设计与部署。
2. 架构演进：竞争涉及从单体架构到微服务、从集中式云服务器到边缘计算（Edge Computing）的转变。每种架构都有其支持者，争论围绕着可扩展性、维护成本、开发速度和延迟等指标展开。
3. 平台与生态系统：竞争不仅在于技术本身，更在于其背后的平台（如Vercel、Netlify、AWS Amplify等）。这些平台提供了不同的抽象层次、工具链和部署流程，从而塑造了开发者的体验和应用的最终形态。
4. 权衡与选择：文章暗示不存在“完美”的架构。新的架构（如边缘优先）可能在性能和全球部署上占优，但在状态管理、复杂业务逻辑和安全控制方面可能带来新挑战。开发者和团队需要在具体需求间做出谨慎权衡。

结论

“新的架构战争”反映了技术社区对更高效、更强大构建方式的不懈追求。其核心不仅是技术工具的迭代，更是开发范式、安全模型和运维哲学的深层次变革。对于从业者而言，理解这些架构背后的原理与取舍，比单纯追随趋势更为重要。

文章探讨了“本体感觉”——即对身体在空间中位置的感知——如何成为叙事中至关重要的“第六感”。作者首先以一位朋友糟糕的停车经历为例，说明擅长写作的人未必具备良好的空间推理能力，但写作本身却需要运用这种感觉。

通过引用弗兰纳里·奥康纳、约瑟夫·康拉德等作家的观点，文章指出优秀的写作需调动多种感官，而本体感觉能赋予故事真实感和深度。它不仅能聚焦人物，还能在有效运用时赋予作品一种“时效性”或关联性。

文章以杰斯米恩·沃德的《拾骨》为例，详细分析了作者如何通过精确追踪叙述者埃什与其兄弟、狗以及即将到来的飓风之间的空间关系，来营造场景、刻画人物动态，并隐喻即将到来的灾难。这种对人物在空间和内部感知的持续关注，将外部环境与角色内在体验紧密相连。

詹姆斯·乔伊斯的《死者》展示了如何利用本体感觉来拓展叙事的意义：从近处的窗格到遥远的雪景，主角加布里埃尔的空间感知变化，隐喻了更广阔的社会与政治主题。

在W.G.塞巴尔德的《移民》中，本体感觉甚至进入了近乎超自然的领域，角色内心的创伤与遥远战场上的恐怖景象通过这种感觉联系起来。

文章还提及了“内感受觉”（对体内状态的感觉）作为可能的“第七感”，并在《拾骨》等作品中看到它与本体感觉的结合，让人物体验更加丰满和深刻。

最后，作者从写作实践角度指出，有意识地思考人物在空间中的位置，无论是在构思、初稿还是修改阶段，都能让场景生动、让人物真实，并自然地融合角色塑造与环境描写。这并非主动“构建世界”，而更倾向于“感知”和“承认”角色所处的世界。

总结：研究《汽船威利》中的音频颤音失真

《汽船威利》(1928) 是一部早期带有同步音效的动画片。该片现已进入公共领域，对其著名音轨的研究发现，音频存在颤音（Flutter） 失真，即播放速度不稳定。这种失真在原始胶片的光学声轨中已经存在，但其确切来源（是录制时就有，还是后期复制产生）尚不清楚。

研究目标与高质量音源

研究者旨在分析这种颤音失真，并尝试自行开发一种廉价的修复方案（而非使用昂贵的专业工具如Celemony Capstan）。为此，他们从互联网档案馆（Internet Archive）找到了一个高质量音源，它可能源自蓝光版，频谱图显示压缩伪影极少。研究甚至利用了一部4K扫描胶片中的低分辨率版本，通过像素阅读脚本提取音频，确认了颤音的存在。

颤音分析与量化

通过观察频谱图，发现所有声音的频率都随时间呈现锯齿状波动。研究者聚焦于例如皮特的烟草击中船钟的声音，通过FFT峰值插值跟踪单一谐波频率的变化，从而量化播放速度的起伏。分析发现，这种波动是周期性的，频率约为15 Hz。虽然希望它是24 Hz（电影帧率），但事实并非如此。

修复方法：数字变速技术

研究者利用了先前为修复VHS磁带抖动而开发的工具。其核心是数字变速（Digital Varispeed）：根据记录到的播放速度变化曲线，通过插值（如拉格朗日多项式）在相反方向调整重采样率，以抵消颤音。由于手动跟踪的数据存在间隔，他们对速度变化信号进行了带通滤波（中心频率15 Hz），以平滑地填补空白并保留如颤音等非失真波动。

修复效果示例

音频示例展示了处理前后的差异：

• 铃铛声、山羊吃乐谱时的内部声音：修复后颤动减少，音符更清晰。
• 弦乐：变得更稳定。
• 牛的叫声：因声音谐波复杂、频率滑动，算法难以精确跟踪，产生了一些伪影，但听起来仍有所改善。
• 米奇的口哨声：修复后反而失去了部分颤音效果，研究者认为原版的颤音更有韵味。

旁支发现

1. 频谱异常：在音频的低频段，可隐约观察到24 Hz（电影帧率）和60 Hz（北美电源频率）的峰值。此外，在米奇的口哨声中，出现了类似调幅信号产生的边带，原因不明。
2. 模拟逐帧播放：实验模拟了如果声轨像画面一样被每秒停止24次播放会怎样。根据老式电影放映机的速度曲线进行数字变速处理后，产生了极度的“颤音”效果。这更多是出于趣味性的探索。

结论

研究确认并量化了《汽船威利》音轨中15 Hz的周期性速度波动。这种颤音已存在于所分析胶片的光学声轨上。通过手动频率跟踪与数字变速技术的结合，可以在一定程度上逆转这种失真，改善部分音效的听感。尽管完全自动化修复因声音的自然波动而困难，但手动工作有望修正大部分声轨。

澳大利亚公司Controlled Thermal Resources计划在加州索尔顿海南端破土动工建设锂提取和地热能发电厂，标志着该地区在清洁能源转型中迈出关键一步。该项目历经十二年的工程、许可和融资准备，有望成为美国首个重要的本土锂资源来源，并减少对国外锂供应的依赖。

项目核心优势：

• 地热发电：利用地下深处热能24小时无污染发电，辅助电网稳定运行。
• 锂提取：从地热卤水中提取锂，用于电动汽车电池和储能系统，环境影响远小于传统锂矿。
• 经济效益：一期工程将创造480个建筑岗位和220个长期岗位，预计年产2.5万公吨氢氧化锂和50兆瓦地热电力。

政治与劳工支持： 拜登政府清洁能源顾问约翰·波德斯塔强调该项目对美国减少关键矿产依赖的重要性，并指出其使用工会劳动力，提供高薪就业。加州建筑行业工会也支持该项目，认为其将为当地居民提供技能培训和就业机会。

环境与争议： 尽管环保组织担忧潜在的水和空气污染问题，但该项目占地面积仅68英亩，且位于已有地热电厂的区域。公司承诺建设湿地以缓解环境影响。相比其他可再生能源项目（如大面积太阳能农场或影响原住民圣地的锂矿），该项目的环境争议较小。

长远规划与挑战： 项目设计为七期中的首期，最终可能实现年产17.5万公吨氢氧化锂和350兆瓦地热电力。研究人员估计索尔顿海地下卤水中的锂储量足以供应数亿辆电动汽车电池。然而，该地区仍面临气候危机导致的索尔顿海萎缩、盐尘暴等长期问题。

更广泛的能源转型意义： 该项目被视为美国加速可再生能源部署的范例，有助于减少对化石燃料的依赖。尽管个别清洁能源项目存在争议，但快速推进此类项目对实现2035年100%清洁电力目标至关重要。

YouTube 视频摘要：The KGB, the Computer and Me – The Cuckoo's Egg Story (1990)

基本信息

• 视频标题：The KGB, The Computer and Me - The Cuckoo's Egg Story
• 发布频道：Australian Phoenix CyberOps（约2.93千订阅者）
• 发布日期：2023年9月16日（约2年前）
• 观看次数：12,505次
• 点赞数：312
• 授权协议：知识共享署名许可协议（允许转载）

视频内容概要

该视频讲述的是**Clifford Stoll（克利福德·斯托尔）的故事。他是一位天文学家，通过追踪计算机间谍活动的迷宫，创造了历史上最具原创性的数字取证与事件响应（DFIR）**故事之一。

核心故事线

1986年8月，Cliff Stoll在劳伦斯伯克利实验室（LBL）工作时，被主管交给了一个谜团——一个0.75美元的账目错误。在那个年代，计算机资源非常昂贵，每一点计算用量都必须记入实验室内的某个项目或部门。

这个故事涉及FBI（美国联邦调查局）、KGB（苏联国家安全委员会，俄文：Комитет Государственной Безопасности）和混沌计算机俱乐部（Chaos Computer Club）三方势力，记录了首个有详细记录的高级持续性威胁（APT）攻击事件。

相关视频推荐

页面右侧显示了多个相关视频推荐，主要围绕网络安全、科技纪录片和历史事件主题：

• Cliff Stoll 的其他演讲（CTI Summit主题演讲、AtlSecCon开幕演讲等）
• 网络安全相关纪录片（DEF CON黑客大会、暗网相关议题）
• 数字隐私讲座（BSidesCache 2025）
• 科技纪录片（量子计算、微芯片制造、BASIC语言诞生史等）

版权声明

视频描述中注明：该YouTube频道所表达的观点和意见仅代表创作者个人，不一定反映创作者可能关联的任何组织、公司或机构的官方政策或立场。

技术说明

该视频页面在访问时显示需要登录的状态（LOGIN_REQUIRED），提示"请登录以确认您不是机器人"，这是YouTube对非登录用户的一种验证保护机制。

2023年雨果奖提名统计公布后，其数据引发了广泛质疑与争议，主要问题集中在以下几点：

1. 多个奖项被无理由取消资格

• 最佳长篇：R.F. Kuang的《Babel》虽获得足够提名，却在最终轮被EPH淘汰并被宣布不符合资格。该书于2022年在美国首次出版，显然是科幻/奇幻作品，其不合格理由不明。数据还显示它在淘汰过程中未获得任何积分，这极不寻常。
• 最佳粉丝作家：Paul Weimer获得第三高票，却被无理由宣布不合格。他确认在2022年有大量粉丝写作且符合资格，但从未收到任何询问。
• 最佳新人奖：Xiran Jay Zhao在其首年资格期内（2022年），却在2023年被宣布不符合资格，同样未收到任何解释。
• 其他：《安多》第一季、《睡魔》的单集、故事《Fogong Temple Pagoda》等也被宣布不合格，但部分有合理的出版年份理由。

2. 异常的投票模式与数据问题

• “悬崖式”票数断层：在多个类别（如最佳长篇、最佳系列、最佳粉丝杂志等）中，前几名候选作品获得数百至近千票，而紧随其后的名次票数暴跌至仅几十或一百多票，这种模式极不自然，与历史数据不符。
• EPH积分异常：如前所述，《Babel》及另一故事《Destiny Delayed》在EPH过程中未获得积分，这引发对数据处理正确性的怀疑。
• 数据错误：出现如作品“Turing Food Court”被重复列出、EPH总点数超过投票总人数等明显错误。
• 延迟公布：提名统计的发布已逼近《世界科幻协会章程》最后期限，且包含大量明显问题，被质疑是因管理员“忙于日常工作”还是另有隐情。

3. 管理员的回应与社区反应

• 回应敷衍：雨果奖管理员Dave McCarty在社交媒体上对质疑给出模糊、回避甚至失礼的回应，随后删除了相关帖子。他将问题归咎于文化差异和需要保护中方同事，但未能提供具体、合理的解释。
• 广泛质疑与愤怒：社群（包括中西方粉丝、作者、前管理员）普遍感到愤怒和失望。分析指出数据模式异常，无法用自然投票或单纯的推荐名单解释。作者如R.F. Kuang、Xiran Jay Zhao、Paul Weimer均公开表达不满。
• “政治干预”猜测：尽管无直接证据，但最广泛流传的猜测是，部分作品或作者因其内容或背景被判定为在中国“政治不正确”，从而在提名过程中被操纵或取消资格。这引发了关于奖项公正性是否受到政治审查影响的严重担忧。
• 对雨果奖声誉的损害：事件严重损害了雨果奖和成都世界科幻大会的信誉。许多获奖者和被提名者开始怀疑自己的成就是否公正，也让支持成都申办的粉丝感到被背叛。
• 后续发展：世界科幻协会（WSFS）的商标保护委员会已对涉事管理员提出正式批评。有成员提出动议，寻求将雨果奖与当届世界科幻大会脱钩，以防止未来类似干预。社群仍在持续要求透明、完整的解释。

总之，2023年雨果奖提名统计暴露出一系列严重异常、数据错误及缺乏透明度的管理问题，引发了对该奖项公正性与独立性的根本性质疑，其负面影响可能持续。

DuckDB 多数据库支持

DuckDB 现已实现多数据库支持，这是一个重大功能扩展。其核心是引入了一个可插拔的存储与事务层，允许通过扩展将MySQL、Postgres和SQLite等外部数据库挂载到DuckDB中，从而像操作其原生格式一样，对这些外部数据库执行包括插入、删除、更新以及模式修改在内的完整的ACID事务操作。

核心功能与使用方法

挂载与操作数据库

• 挂载语句：使用 ATTACH 语句，配合 TYPE 参数或 {type}: 前缀来指定数据库类型。

  -- 使用TYPE参数
  ATTACH 'sakila.db' AS sakila (TYPE sqlite);
  -- 使用前缀
  ATTACH 'postgres:dbname=postgresscanner' AS postgres;
  

• 切换与查询：使用 USE 命令切换主数据库。挂载后，可直接用标准SQL查询外部数据库中的表。

  USE sakila;
  SELECT title, release_year FROM film LIMIT 5;
  

• 高级操作：可以在已挂载的SQLite、Postgres等数据库上执行CREATE TABLE AS、DELETE、ALTER TABLE等操作，就像操作DuckDB原生表一样。

跨数据库数据整合

• 混合挂载：可同时挂载多种类型的数据库。

  ATTACH 'sqlite:sakila.db' AS sqlite;
  ATTACH 'mysql:...' AS mysql;
  ATTACH 'postgres:...' AS postgres;
  

• 数据移动与查询：可以轻松地在挂载的数据库间复制数据，并进行跨库联表查询。

  -- 将SQLite的film表复制到MySQL
  CREATE TABLE mysql.film AS FROM sqlite.film;
  -- 跨三个数据库联表查询
  SELECT ... FROM mysql.film
  JOIN sqlite.film_actor ON ...
  JOIN postgres.actor ON ...;
  

事务支持

• 单库事务：所有操作默认在事务中执行。对外部数据库的事务支持由各自的存储引擎管理，支持BEGIN、COMMIT和ROLLBACK，确保操作原子性。
• 跨库事务限制：目前不支持在单个事务中对多个挂载的数据库进行写入操作。如果尝试，系统会抛出错误。读取则不受此限制。

主要应用场景

1. 数据迁移与ETL：方便地将数据从一个系统（如SQLite、Parquet文件）复制到另一个系统（如Postgres、MySQL），或整合多个数据源。
2. 数据虚拟化：无需物理移动数据，即可实时查询和分析存储在不同数据库中的数据。
3. 并发写入整合：不同的进程可以将结果分别写入各自的事务性数据库（如多个SQLite文件），最后在DuckDB中安全地合并进行分析。

其他要点

• 查看已挂载数据库：通过查询 duckdb_databases 系统表，可以查看所有已挂载数据库的名称、路径和类型。
• 直接打开：无需显式使用 ATTACH 语句，可通过连接字符串直接以特定数据库类型打开。

  # Python示例
  con = duckdb.connect('sqlite:file.db')
  

• 未来工作：团队计划持续优化现有扩展的性能和功能，并鼓励社区利用此可插拔架构开发连接更多数据库的扩展。

本文档《LLM App Stack – a.k.a. Emerging Architectures for LLM Applications》是一份关于大语言模型应用技术栈的综合性清单，旨在列出在LLM应用开发各个层级中可用的工具、项目和供应商。相较于最初基于用户访谈仅包含最流行选项的文章，此仓库旨在提供更全面的覆盖，涵盖每个类别中的所有可用选项。文档结构清晰，按技术栈层级分类，并附有便捷的搜索提示。

主要内容涵盖以下技术层级：

1. 数据管道：用于数据摄取、预处理和转换的工具，如Databricks、Airflow、Unstructured.io、Airbyte等。
2. 嵌入模型：用于生成文本语义嵌入的模型，包括OpenAI Ada Embedding 2、Cohere AI、Sentence Transformers等。
3. 向量数据库：专门用于存储和查询向量的数据库，如Pinecone、Weaviate、ChromaDB、Pgvector、Zilliz (Milvus)、Qdrant等。
4. 游乐场：用于实验和测试LLM提示的平台，如OpenAI Playground、nat.dev、Humanloop、Parea AI等。
5. 编排器：用于构建、编排和管理LLM应用工作流的框架，如Langchain、LlamaIndex、Autogen、Microsoft Semantic Kernel、Haystack等。
6. API/插件：用于扩展LLM能力的外部API或插件，例如Serp API、Wolfram Alpha API、Zapier API AI Plugin。
7. LLM缓存：用于缓存LLM响应以提升效率和速度的工具，如Redis、SQLite、GPTCache。
8. 日志/监控/评估：用于监控、评估和调试LLM应用的工具平台，种类繁多，包括Braintrust Data、Arize AI、Weights & Biases、MLflow、PromptLayer、Helicone等众多选项。
9. 验证器：用于验证、约束和修正LLM输出的工具，如Guardrails AI、Rebuff、Microsoft Guidance、LMQL、Outlines等。
10. LLM API (专有)：提供大语言模型服务的商业API，如OpenAI、Anthropic、Cohere AI等。
11. LLM API (开源)：提供开源模型托管和推理服务的平台，如Hugging Face、Replicate、Anyscale、Ollama等。
12. 应用托管平台：专门用于托管和部署LLM应用的平台，如Vercel、Netlify、Steamship、Streamlit、Modal等。
13. 云提供商：提供底层基础设施的主流云服务商，如AWS、Google Cloud Platform、Microsoft Azure、CoreWeave。
14. 定制化云：针对AI/ML工作负载（特别是LLM）优化或提供特定服务的云平台，如Databricks (MosaicML)、Anyscale、Modal、Runpod、OctoML、Baseten、E2B。

文档还包含了格式化提示模板，说明了如何通过工具（如Perplexity和Cursor.sh）自动化搜索项目信息并进行Markdown表格格式化，以方便内容维护和更新。整体而言，该文档为开发者构建LLM应用提供了一个全面的技术栈参考地图。

# 内容摘要

本文提供的材料中，实际可获取的技术内容是一个HTTP状态码：**403 Forbidden**。

## 技术解读
- **类型**：这是一个标准的HTTP错误响应代码。
- **含义**：403 Forbidden 表示服务器理解了客户端的请求，但拒绝授权访问该资源。简单来说，即“访问被禁止”。
- **常见原因**：通常由于服务器权限配置问题、资源访问控制策略（如IP限制、身份验证失败）或目录/文件权限设置不当导致。
- **目的**：该代码是服务器向客户端反馈的一种机制，表明请求因权限不足而无法完成。

## 结构
该响应本身是一个由Web服务器返回的、符合HTTP协议的简短状态信息，其核心标识即“403 Forbidden”。

## 关键功能
其主要功能是**提供访问控制反馈**，明确告知请求方其没有权限访问所请求的特定资源。

长期重构：一种渐进式的成功方法

传统大规模重构的挑战

传统的大型或“长期”重构在繁忙的公司中难以成功实施。它通常伴随着一系列挑战：需要说服业务方接受延迟、决定哪些功能需要等待、提供定期的状态更新、不断证明重构的合理性，并需要防止团队倦怠、处理大量代码审查和密集的测试问题。这种方法的最终结果往往是功能冻结、匆忙上线、充满缺陷，以及团队精疲力竭。

提出另一种方式：渐进式长期重构

作者提出了一种不同的方法，认为长期重构之所以名声不佳，是因为它们通常比预期耗时更长。通过进行有计划的、渐进式的长期重构，可以避免上述许多问题。其核心优势包括：

• 无需与业务谈判时间线：重构作为日常工作的一部分渐进完成。
• 不与业务优先级竞争：功能开发持续进行，不受阻。
• 团队理解并主动参与：团队逐渐理解并接管重构工作。
• 压力小、无倦怠风险。
• 代码审查容易：没有庞大的代码差异（diff）。
• 重构被持续评估：整个团队协作重新评估重构决策。
• 不浪费时间重构不必要代码。
• 功能开发不阻塞。
• 团队提升架构知识。
• 为新工程师提供优质入门任务。
• 逐步上线，易于测试，减少缺陷。

实施的前提条件

1. 一位对重构有远见的资深软件工程师。
2. 一个由不同经验水平的软件工程师组成的团队。
3. 一个内部知识库（如GitHub Wiki、Notion等）。
4. 同时进行中的长期重构数量控制在5-10个以内。

详细实施流程（由资深工程师主导）

1. 识别应重构的代码。
2. 识别重构模式：在代码库中探索，找出常见的变更模式，暂忽略特殊情况。
3. 实施一个示例：找到最小的可应用该模式的样本，精心重构。此代码将成为团队的主要参考，需遵循最佳实践并清晰注释。提交合并请求。
4. 为重构准备代码库：根据自己的实践经验，进行一些小的准备工作（如调整代码结构、重命名以增加清晰度），为同事铺平道路，但不要自己完成所有重构。提交合并请求。
5. 为重构命名：起一个简洁、清晰、描述性的名字，例如“移除对[包X]的依赖”。
6. 编写重构指南：在内部知识库中创建文档。
   • 内容需精确说明“做什么”和“如何做”，简洁具体。
   • 列出具体步骤，避免讲述背景故事。
   • 链接到第3步的示例合并请求。
   • 可将背景信息和故事放在文档末尾的可折叠部分。
7. 将此重构添加到长期重构列表：确保知识库中有一个列出所有进行中重构的页面。
8. 向团队介绍此重构：通过书面通知或会议进行说明，展示示例并链接指南。确保每位工程师都知晓所有进行中的重构。
9. 分配重构任务：关键点：不要预先在任务跟踪器中创建所有任务。相反，在日常规划中自然出现时再创建任务（例如，“既然你要修改那部分代码，也许可以顺便移除对包X的依赖？”）。建议将整个“伞式”重构远离业务可见的跟踪系统。成功的长期重构应由工程师跟踪，只要它存在于知识库中并常驻工程师脑海即可。业务方无需关心其完成状态和耗时。
10. 保持对长期重构的认知：将新工程师阅读第7步的列表纳入入职流程。这也是他们理解现有代码和新方向的绝佳入门任务来源。
11. 完成重构：长期重构无需100%完成。当文档变得多余，因为代码库本身已清晰明了时，即可将其标记为完成，为下一个重构腾出空间。

这种方法带来的积极现象

团队会养成按需自行认领重构任务的习惯。遇到问题时，会发起讨论和会议，使大家对可能单独做出时会引起争议的决定达成共识。每完成一个重构任务，团队都获得了可供后续任务借鉴的新范例。

潜在缺点

1. 缺乏共同模式：少数大型重构可能没有统一模式，应尝试将其拆分为多个独立的重构。
2. 需要耐心：重构可能持续一到两年，期间新旧代码共存。但只要列表常驻每个人脑海，并通过组织和沟通保持清晰，通常不会造成混淆。
3. 部分代码可能永不重构：这可能有合理原因（如代码易于维护或即将被废弃），应视为节省了时间和避免了不必要的缺陷。
4. 需要团队协作：此方法要求所有人对齐、协商方案并阐述理由，不适合喜欢独自工作的工程师。

总结

长期、渐进式重构的核心是将重构化整为零，融入日常开发，通过团队协作、清晰的知识共享和渐进式推进，避免传统大规模重构的诸多弊端，在持续交付业务价值的同时，稳步提升代码库健康度。

Improbable Island 摘要

Improbable Island 是一个在线文本冒险游戏，根据提供的内容，它被描述为最大和最长运行的在线文本冒险之一。该游戏作为在线平台，允许用户参与基于文本的互动冒险体验。提供的内容中未包含更多详细信息，因此摘要仅基于给定的标题信息。

ArVid：90年代俄罗斯用一盘VHS录像带存储4块硬盘数据的创新方案

背景与需求

1995年，苏联解体后的俄罗斯经济动荡，但西方计算机设备涌入。拥有计算机的用户面临存储困境：500MB硬盘容量不足，软盘（1.44MB）不可靠，新硬盘（约200美元）相当于当时俄罗斯人月薪。在此背景下，一种名为“ArVid”的本土创新设备应运而生。

设备概述

ArVid是一块ISA扩展卡，售价约80美元，通过特殊线缆连接家用录像机（VCR），可将数据存储到普通VHS录像带上。一盘180分钟的录像带可存储约1.08GB数据（后续型号可达2.16GB），相当于当时4块硬盘的容量。

工作原理

1. 数据写入：ArVid卡将计算机数据转换为视频信号，通过RCA线缆输出至VCR的“视频输入”接口。同时，卡上的红外发射二极管向VCR发送“录制”等控制指令，模拟遥控器操作。
2. 数据读取：读取时，VCR播放录像带，视频信号通过“视频输出”接口传回计算机，由ArVid卡转换为数字数据。
3. VCR控制：用户需先“训练”ArVid卡，使其记录自家VCR遥控器的红外信号（如播放、停止、快进）。后期型号在出厂时预置了常见VCR型号的控制代码。
4. 错误处理：由于家用录像带质量较差，ArVid采用Reed-Solomon等纠错算法，并在写入后执行数据验证步骤。软件会显示详细的错误统计，帮助用户优化设置（如调整VCR磁头校准、更换更好的录像带）。

技术细节

• 数据格式：仅使用视频信号的亮度部分（黑白），未使用颜色和声音信息。
• 文件管理：数据在录像带上以区段存储，区间留有空白。系统在本地保存“.TDR”格式的目录文件，记录文件位置，便于快速检索。
• 兼容性：支持DOS、Windows 3.1/95/NT及OS/2系统，并有Linux/FreeBSD的非官方移植。

成本与经济性

• 硬件成本：ArVid卡（$80）+ VHS录像带（$4/盘）+ 已有的家用VCR。相比当时其他存储方案极具性价比：
  • CD-R刻录机：$300起，盘片容量184-870MB
  • ZIP驱动器：$150，盘片$15/100MB
  • 硬盘：$150/1.2GB
• 存储成本：每GB存储成本极低，适合备份大量数据。

应用场景与非典型用途

• 主要用途：数据备份，尤其受小型企业和学术机构欢迎。
• 非典型用途：
  • 有用户将录像带上打包的游戏复制到软盘出售。
  • 有人将其改装为简易监控系统，通过检测画面变化触发录像。
  • 曾有设想通过电视广播信号大规模分发数据。

产品演进与衰落

• 产品迭代：1993至1998年间推出多个型号（如1010、1020、1031、1051、1052），硬件缓冲和存储密度不断提升，并引入FPGA芯片改进散热。
• 衰落原因：
  1. 硬盘和光驱价格持续下降，性价比优势减弱。
  2. 产品未达到规模经济，价格始终维持在$80左右。
  3. 设置复杂，需要一定技术知识，非普通用户友好。
  4. 家用VHS技术和录像带容量存在物理上限。

现状与遗留

• 历史意义：ArVid是90年代俄罗斯技术爱好者在资源匮乏条件下发挥创造力的典范，解决了特定时期的存储痛点。
• 当前状态：ArVid卡在二手市场仍有售（价格低廉），但其数据存储价值已消失。制造公司PO KSI仍在运营，但产品线已转向其他领域。
• 技术遗产：相关软件、驱动和文档仍有存档，体现了早期开源社区的支持模式。

类似产品

国际上曾有类似设备，如Corvus Mirror、Danmere Backer等，但ArVid是苏联解体后俄罗斯本土创新的代表，其普及反映了当时独特的技术与社会背景。

文章摘要：警惕AI聊天机器人对人际交流的潜在扭曲

随着大型语言模型（LLM）的普及，人机交互正从命令式转向自然对话，这带来了潜在的社会影响。作者认为，这种转变可能沿两个危险方向重塑人类互动。

方向一：过度拟人化AI与信任侵蚀

人们倾向于将具有对话能力的系统拟人化，甚至会说“请”。随着AI伴侣、助手、治疗师等产品的发展，用户可能将其视为朋友而非商业系统。然而，这些系统由公司创建，并可能收集个人数据以实现商业定制，这种“人性”接口会让人误判其本质，模糊商业产品与真实关系的界限。

此外，如同文字处理软件的自动更正功能会使人写作趋同、平淡或产生偏见，AI交互也可能影响用户的认知与表达，甚至对心理健康产生负面影响。

方向二：将机器式交流习惯迁移至人际关系

与AI高效沟通需要直接、精确甚至冷漠的指令。长期与此模式互动，可能导致用户将这种“程序员对计算机”的说话方式带入人类对话，牺牲同理心、微妙与温情，使人类交流趋于机械和直接。

更深远的影响是，长期与高度个性化、随需响应的AI伴侣互动，可能像色情内容塑造性观念一样，让用户对现实中的人类关系产生不切实际的期望，加剧社交孤立与不信任感。

结论与展望

作者指出，技术常被预言将毁灭文明，但LLM也可能最终成为如文字处理器般的便利工具。其最终影响取决于我们如何设计训练这些AI，以及我们是否致力于巩固现实社会的人际纽带与公民信任。

Google 和 Yahoo 强制执行 DMARC 协议摘要

自 2 月 1 日起，Gmail 和 Yahoo 将强制执行基于域名的消息认证、报告和一致性（DMARC）要求，该协议为 IETF 标准（RFC7489）。初始阶段主要影响大型发件人，即每天向 Gmail 系统发送超过 5,000 封邮件的域名，未来未配置 SPF、DKIM 和 DMARC 的邮件投递将更加困难。

DMARC 的作用

DMARC 与 SPF 和 DKIM 协同工作，向接收邮件服务器提供关于如何处理验证失败邮件的明确指令。它实现两个核心功能：

• 指定失败邮件处理方式：例如隔离、拒绝或直接投递。
• 报告失败情况：允许发件人通过 DNS 记录指定接收报告的电子邮件地址，以便监控和调整认证设置。

SPF 和 DKIM 简要回顾

• SPF：指定哪些邮件服务器可合法从您的域名发送邮件，有助于识别钓鱼、伪造和垃圾邮件。
• DKIM：对邮件进行加密签名，确保邮件在传输过程中未被篡改。

DMARC 的额外功能

• 尽管 SPF 有类似“-all”的参数，但接收服务器可能忽略；DMARC 则强制要求接收服务器遵循指令。
• DMARC 报告以 XML 格式（常为 .zip 文件）发送至指定地址，帮助发件人发现未被 SPF 覆盖的邮件源（如博客服务器或 CRM 系统），从而调整记录。
• 建议部署从“p=none”开始，仅监控报告而不立即采取行动，以避免误拦截合法邮件。

部署建议

• 最小可行记录：添加 DNS TXT 记录 _dmarc IN TXT "v=DMARC1;p=none;" 即可满足基本合规要求，维护对 Gmail 和 Yahoo 的邮件投递。
• 完整记录示例：包含报告地址，例如 _dmarc IN TXT "v=DMARC1;p=none;rua=mailto:dmarc@example.com;ruf=mailto:dmarc@example.com;rf=afrf"。
• DNS 位置注意：SPF 记录位于域名顶点（“@”），而 DMARC 记录位于“_dmarc”作用域。
• 报告数量可能很大，建议使用专用邮箱（如 postmaster@）接收，并考虑采用 DMARC 解析服务（如 easydmarc 或开源工具 parsedmarc）进行分析。

easyMail 实施计划

• easyMail 已默认启用 DKIM；未来将为新域名添加 postmaster@ 邮箱以接收 DMARC 报告。
• 将测试所有 easyMail 域名的 DMARC 记录，并在缺少时通知用户，以确保 2 月后邮件投递不受影响。

下一步行动

• 确保所有域名已配置 SPF 记录（可使用 SPFWizard 工具）。
• 关注后续 DMARC 文档和更新链接，逐步完善认证设置。

esp-rs 项目 2023 年第四季度更新摘要

Rust 编译器进展

• 上游改进：所有裸机非原子 RISC-V 目标（如 ESP32C3、ESP32C2）现已支持原子加载/存储代码生成，该功能目前在 nightly 版本中，将于 1.76 稳定版发布。新增 riscv32imafc-unknown-none-elf 目标以支持 ESP32P4 芯片。现有裸机 RISC-V 目标已提升至 Tier 2 级别，并完善了平台支持文档。同时添加了针对 ESP32P4 的 espidf 目标 riscv32imafc-esp-espidf。
• Xtensa 后端：Espressif 的 LLVM 团队持续改进并重新基于 LLVM 17 更新了 Xtensa LLVM 后端，但暂无上游进展报告。

esp-hal（no_std 库）

• 版本发布：发布 v0.13、v0.14 和 v0.15 版本，主要亮点包括：新增 PARL_IO、I2S 和 RMT 的异步驱动；更新至 embedded-hal v1.0 版本。
• 功能增强：统一了所有芯片的低功耗支持 API，并为 ESP32S2 和 ESP32S3 添加了 ULP（超低功耗）核心支持。为 ESP32C6 和 ESP32H2 实现了 flip-link 功能，提供零成本栈溢出检测。
• 重要变更：不再支持原子模拟，因上游 Rust 已在非原子目标上支持原子加载/存储。建议使用 ESP32S2、ESP32C3 或 ESP32C2 的用户切换至 portable-atomic crate 以简化升级。

esp-wifi（no_std 库）

• 新功能与修复：为 ESP32H2 添加 BLE 支持，修复 ESP32 的共存支持问题，并新增 WiFi 吞吐量基准测试示例。
• 正式发布：库已在 crates.io 上发布，经过长时间优化和文档完善。

espflash 工具

• 版本更新：发布 v2.1.0 版本，新增扇区、区域和分区的擦除功能。
• 开发计划：开始 v3.0 版本开发周期，将默认集成基于 Rust 的闪存桩，相关更新可在更新日志中查看。

probe-rs 工具进展

• Xtensa 架构支持：为支持 CI 中的硬件在环（HIL）测试，新增了 Xtensa 架构支持，现已能连接、检查和闪存 ESP32S2 和 ESP32S3 芯片。
• 性能提升：通过改进 USB-SERIAL-JTAG 和 FTDI 驱动，所有芯片的闪存速度显著提升。

RFC（征求意见）

• esp-openthread：项目寻求社区反馈，以确定 esp-openthread 的后续开发方向，特别关注 Thread 协议在项目或产品中的应用。

未来工作

• 下一季度的工作计划可参考 Jesse Braham 的相关发布。

（字数：约 580 字）

这篇文章描述了一个页面不存在的错误情况。页面显示“Nothing to see here”，并说明该页面不存在，同时提供了一张贵宾犬坐在椅子上的图片作为幽默的补偿。系统询问用户是否在寻找其他内容（“Looking for this?”），暗示可能导向相关资源。整体内容以轻松幽默的方式处理访问错误，没有提供实际的技术或信息性细节。