设计受迪特·拉姆斯启发的iPhone支架

设计动机与背景

作者长期寻找经典的Braun DN 40闹钟，但发现其床头柜空间已被手表托盘、iPhone MagSafe充电器等物品占据，显得拥挤且使用不便。受一个介绍iPhone“待机模式”（Standby Mode）的YouTube视频启发，他尝试了现有类似DN 40的3D打印支架设计，但仍觉得体积过大、仍需单独托盘且充电器安装不便。

灵感来源与核心理念

作者注意到Braun近年推出的新产品BC21闹钟，其设计融合了经典元素与现代功能，既是闹钟也是无线充电板。这激发了他将床头托盘、无线充电器和闹钟/时钟功能整合到一个单一设备中的想法，旨在节省空间、提升整洁度和便利性。

设计过程与关键技术细节

1. 初始原型与迭代：从基于DN 40灵感的设计开始，作者经历了大量CAD建模和3D打印迭代，不断优化外形比例。
2. 关键设计考量：
   • 精准适配：参考Apple配件设计指南，确保支架的圆角曲率（G2曲率）与iPhone及官方保护壳完美匹配。
   • 多功能整合：设计中包含一个皮革内嵌托盘，用于安全放置手表等物品，与3D打印的粗糙表面形成保护。
   • 美学借鉴：最终形态受到Braun BC21以及经典产品如Braun 550吹风机的启发，并参考了《Soft Electronics》一书中的复古电子产品美学，使设计更圆润、手感更舒适。
3. 实用优化：解决了充电线缆管理的难题，通过结构设计优化了MagSafe充电器线材的固定与走向。

最终成果与分享

作者完成了一个一体化的iPhone待机支架。该设计整合了MagSafe无线充电、手表保护托盘，并受到Dieter Rams及Braun经典设计语言的影响。他使用PLA材料3D打印成品，并感叹家用CAD软件与3D打印机带来的创造自由。最终，他将该设计的3D模型文件免费公开分享，并在Gumroad上提供付费下载选项，供支持者自愿贡献。

摘要

Cloudflare 宣布计划在未来一年内推出一个在线市场，允许网站所有者向 AI 模型提供商收取费用，以换取对其网站内容进行抓取的权限。此举是 Cloudflare 首席执行官 Matthew Prince 赋予发布者更大控制权，以管理 AI 机器人抓取其网站方式的最终步骤。

作为该计划的第一步，Cloudflare 已于本周一推出了名为 AI Audit 的免费可观测性工具。该工具为网站所有者提供一个仪表盘，用以分析 AI 模型为何、何时以及多频繁地抓取其网站信息。同时，用户只需点击一个按钮，即可阻止 AI 机器人访问其网站。发布者可以选择屏蔽所有使用 AI 的抓取程序，也可以选择性地允许某些抓取程序通过（如果他们有协议或认为抓取行为有益）。

该举措旨在解决 AI 行业面临的一个核心问题：当用户转向 ChatGPT 等服务而非直接访问网站时，小型发布者将如何生存？目前，AI 模型提供商每天从大量未获得补偿的小型网站抓取内容以训练其大型语言模型。虽然一些大型出版商已与 OpenAI 等公司达成了内容许可协议，但大多数网站一无所获。这种状况可能破坏众多网站的商业模式，减少其至关重要的流量。

此前，AI 驱动的搜索初创公司 Perplexity 被指控无视网站通过 Robots Exclusion Protocol 表示的禁止抓取意愿，引发业界不满。此外，过度的 AI 机器人抓取行为不仅令网站所有者困扰，还可能耗尽其云计算预算并影响服务。

AI Audit 工具能够识别访问网站的每个抓取程序的来源，并提供窗口显示来自 OpenAI、Meta、亚马逊等不同 AI 提供商的抓取频率。这解决了网站所有者希望有选择性地控制哪些 AI 模型可以访问其内容的需求，而非完全一刀切地屏蔽所有爬虫。

Prince 指出，即使是与 OpenAI 签订了许可协议的大型出版商（如《时代》周刊、康泰纳仕、《大西洋月刊》），也对其内容被抓取的规模和细节知之甚少，这可能影响他们评估许可协议是否合理。

Cloudflare 计划在明年推出的市场平台，旨在让小型发布者也能与 AI 模型提供商达成交易。其愿景是让所有网站都能设定访问和获取其内容用于 AI 系统的价格。虽然具体商业模式尚不清晰，但可能涉及根据抓取频率收费，或要求 AI 公司支付货币费用或提供服务抵扣。尽管 AI 公司可能不愿为目前免费获得的内容付费，但 Prince 认为这对 AI 生态的长期可持续发展至关重要，因为当前 AI 公司无偿使用内容的模式难以持久。

伦敦超低排放区（ULEZ）的意外收益：儿童通勤方式更趋活跃

研究背景与核心发现

限制高排放车辆进入城市区域不仅能改善空气质量，还能带来额外的社会效益。伦敦拥有全球最大的超低排放区（ULEZ）。剑桥大学和伦敦玛丽女王大学的研究人员于2018年开展了一项自然实验，对比了伦敦市中心与北部小城卢顿（对照组）6至9岁儿童的健康与活动情况。

研究结果显示，在ULEZ实施一年后，伦敦研究组中五分之二（40%）的学生将上学方式从“被动”（由父母开车接送）转变为“活跃”（步行、骑自行车、滑板车或乘坐公共交通）。相比之下，对照组卢顿仅有五分之一的儿童转向活跃通勤，且有同等比例的儿童转向了被动通勤。在伦敦的ULEZ内，改为开车接送的情况极为罕见。

活跃通勤的健康与社会效益

儿童采用活跃的通勤方式具有多重直观且重要的益处：

• 身心健康：增加日常体力活动有助于预防全球日益严重的儿童肥胖问题，促进身体发育和心理健康。
• 心理与学业：步行或骑车上学比直接乘车更令人平静，有助于提高注意力和潜在的学业表现。
• 综合效益：对儿童、家庭和环境均有积极的整体影响。

转变原因与未来研究方向

目前尚不清楚父母放弃开车接送的具体原因。未来的研究将试图厘清这一转变是由于ULEZ每天12.50英镑（约16.50美元）的通行费增加了经济负担，还是因为道路上车辆减少使父母认为让孩子步行上学更安全，亦或是两者的结合。

美国面临的障碍与政策启示

尽管排放控制区效益显著，但美国因联邦法律的立法障碍，难以复制伦敦的ULEZ模式。例如，加州圣莫尼卡的零排放配送区试点短暂且属自愿性质，而纽约市的拥堵收费区计划也被州长叫停。

针对这一现状，专家提出以下建议与洞察：

• 改善基础设施：美国城市可通过建设对行人友好的基础设施和保护性自行车道，鼓励人们采用活跃的交通方式，从而减少总体驾驶量并实现气候目标。
• 政策干预的有效性：研究表明，相较于单纯建设基础设施（“胡萝卜”政策），采取措施限制或抑制汽车出行（“大棒”政策）往往能更有效地促使人们转向健康的交通方式。

结论

减少城市街道上的汽车数量、鼓励步行等活跃交通方式，不仅最符合儿童的健康利益，也能造福社区与地球。活跃交通即可持续交通，推动儿童通勤方式的活跃化与可持续化具有深远的综合效益。

文章标题：Uber对账户内有信用额度的用户收取更高费用

核心发现

两位用户在使用Uber服务时发现，当其Uber账户内存在余额（如信用卡赠送的月度额度或礼品卡充值金额）时，相同路线的打车价格显著高于正常水平，也高于竞争对手Lyft的报价。

具体案例

案例一（文章作者）：

• 作者账户中拥有每月15美元的American Express Uber信用额度。
• 请求叫车时，显示的车费已扣除该信用额度（而非显示原价后在支付环节再抵扣）。
• 抵扣后的实际费用仍高于平常价格，且远高于Lyft的报价。
• 作者假设Uber可能因为用户账户有“被困住”的信用额度（必须用于Uber服务），而认为用户愿意支付更高价格，从而故意提高报价。
• 后续作者将该信用额度用于Uber Eats，则未发现定价异常。

案例二（读者Charles）：

• Charles经常在固定时间、固定地点预约Uber行程，价格通常稳定在20美元左右，略低于Lyft。
• 他在Costco购买了面值8折的Uber礼品卡并充值。
• 充值50美元后，一切正常；当他再充值200美元并准备预约机场行程时，发现了两个异常：
  1. 支付限制：系统不允许使用这种充值方式的余额支付提前预约的行程。
  2. 价格飙升：同一行程的价格从约20美元突然涨至30美元。
• 他进行对比测试：用另一部未登录、无余额的手机查询同一行程，Uber显示的价格仍是正常的20美元。

分析与推测

1. 差异化定价：证据强烈表明，Uber可能在对账户内有余额或信用额度的用户实行更高的动态定价。
2. 测试假设：作者推测这可能是Uber对部分用户进行的测试，旨在研究当用户的“实际”现金支出减少时（因为信用额度会抵扣部分费用），他们对更高价格的接受程度。
3. 商业策略背景：文章将此现象联系到Uber在CEO Dara Khosrowshahi（来自Expedia）领导下的变化趋势：
   • 司机收入可能降低（尽管引入了小费）。
   • 对消费者而言整体费用变得更昂贵。
   • 传统的“ surge pricing”（动态加价）透明度下降，变成直接收取更高费用而不明确告知。
4. 用户困惑与质疑：作者及读者均对这种不透明、可能针对特定用户的定价策略感到不满，认为这不符合以客户为中心的做法，并邀请其他用户分享类似经历以验证这一模式。

低成本CO₂传感器对比：光声式与非分散红外式

本文对室内与室外CO₂监测的不同应用场景进行了说明，并重点比较了两种主流低成本CO₂传感技术：非分散红外传感器（NDIR） 与光声传感器。

测量原理概述

• 基于TVOC的估算（eCO₂）：不可靠，易受其他挥发性有机物干扰，不推荐使用。
• NDIR与光声传感器：均基于气体对特定波长光的吸收原理。CO₂吸收峰在约4.26微米波长处。
  • NDIR：通过红外光源照射气室，测量接收端光强度的衰减来计算CO₂浓度。部分型号具备双通道以提高精度。
  • 光声式：CO₂吸收红外光后产生声波，通过麦克风检测该声波来反推浓度，无需光学路径，故体积可更小。

规格参数对比

除尺寸和接口外，各传感器规格相近，成本也相当（10-25美元）。

室内测试结果

在典型室内环境中进行为期两周的测试，SenseAir S8（NDIR） 与 Sensirion SCD40（光声） 表现相似，均能提供可靠读数。S8对高浓度变化的响应略更敏感。

室外测试表现

室外监测面临更大挑战：温度湿度变化范围更宽，CO₂浓度范围通常较低（400-550 ppm）。与参考仪器对比测试发现：

1. 一致性差异：
   • 两台SenseAir S8（NDIR）之间的相关性（R²=0.90）远高于两台Sensirion SCD41（光声）的相关性（R²=0.36）。
2. 与参考值的相关性：
   • SenseAir S8与参考仪器的R²值为0.64-0.69。
   • Sensirion SCD41与参考仪器的R²值仅为0.16-0.24。
3. 图形分析：NDIR传感器的数据点更贴近参考值的1:1拟合线，而光声传感器数据点较为分散。

结论

• 光声传感器（如Sensirion SCD4x）在正常室内条件下可提供与NDIR相当的精度，且体积更小。
• NDIR传感器（如SenseAir S8）在室内及尤其在室外环境下表现更稳定、一致性更好，与参考仪器相关性更高，更适合用于户外监测或环境波动较大的场景。

《艾伦·图灵1950年曼彻斯特Mark I电子计算机操作手册》摘要

文档概述

该文档为一份珍贵的历史技术文献，即艾伦·图灵（Alan Turing）于1950年编写的曼彻斯特Mark I电子计算机（Manchester Mark I）的操作与编程手册。文档格式为PDF，共计115页。

元数据信息

• 文件格式：PDF 1.4版本
• 创建工具：Adobe Acrobat 7.08及其图像转换插件
• 创建与修改时间：文件创建于2007年3月24日，并于同日进行过修改。这表明当前的PDF文件是2007年对原始文档进行数字化扫描和转换的产物。
• 文档标识：文件具有唯一的UUID标识符，用于数字文档管理。

内容结构

手册正文内容按页码顺序组织，从第1页至第115页。提供的资料仅包含目录页码列表，未提供各页的具体文本内容。

核心意义

1. 历史价值：该手册是计算机科学与工程史上的关键文献之一。曼彻斯特Mark I是世界上最早的存储程序电子计算机之一，而图灵作为其核心思想贡献者，这份手册直接反映了早期计算机的编程思想、操作方法和架构细节。
2. 内容推测：作为操作手册，其内容可能涵盖计算机的硬件组成说明、指令集架构、机器语言编程方法、输入输出设备操作、存储管理以及基本的故障排查等。
3. 作者与时代：由阿兰·图灵本人编写，使其不仅是一份技术说明，也是理解图灵计算思想在实践中应用的重要窗口，对研究计算机科学起源具有不可替代的价值。

总结：此文档是1950年由阿兰·图灵编写的曼彻斯特Mark I计算机手册的数字化版本，共115页。它是一份奠基性的技术文件，对于研究早期电子计算机的实现和图灵的贡献具有重要历史意义。当前可访问的仅为文档结构（页码列表），完整内容需参阅原始PDF文件。

核心事件

根据 SteamDB 的泄露数据，Valve 正在 Steam 平台上测试对 ARM64 架构和 Android 系统的支持，这暗示了其未来可能推出基于 ARM64 架构的新硬件设备。

技术细节

• 测试项目：在代号为“ValveTestApp3043620”的未知应用更新中，包含了《求生之路2》、《Garry's Mod》、《坎巴拉太空计划》及《中土世界：暗影魔多》等热门游戏。
• Proton 兼容层：上述游戏新增了 proton-arm64、proton-arm64e、proton-arm64ec 以及 proton_experimental 等实验性构建标签。这表明 Valve 正与 CodeWeavers 合作，积极测试专为 ARM64 系统设计的 Proton 版本（使 Windows 游戏能在 Linux 上运行的兼容层）。
• Android 支持：更新中提及了 Waydroid（一款在 Linux 上运行 Android 应用的工具），暗示 Valve 平台有望兼容更广泛的 Android 软件生态。

战略意图与硬件猜测

• 潜在新硬件：支持 ARM64 架构意味着 Valve 计划推出搭载 ARM 处理器的便携式硬件。外界推测这可能是为传闻中的 Valve 独立 VR 头显，或是基于 ARM64 的新版 Steam Deck 做准备，未来这些设备或可同时支持 VR 与非 VR 游戏。
• 跨平台生态扩展：更新列表中还出现了《瘟疫公司：进化》和《冰汽时代》等游戏。结合 Valve 此前暗示将为第三方游戏掌机提供官方 SteamOS 支持，表明公司正致力于为消费者打造更灵活的跨平台游戏体验。

项目概述

该项目名为“Coffee Stats – Maximize Caffeine Intake and Get to Bed at Night”，旨在帮助用户决定是否再喝一杯咖啡，基于睡前咖啡因水平的统计数据。用户可以自定义咖啡因摄入量和睡眠时间，以优化咖啡因摄入并确保夜间睡眠质量。

主要功能

• 统计数据提供：计算用户在预定睡眠时间的咖啡因水平。
• 自定义输入：允许用户输入具体的咖啡因摄入量和睡眠时间。
• 目标用户：适用于希望管理日常咖啡因摄入、避免影响睡眠的健康个体。

技术假设

脚本基于以下一般性假设，这些假设在实现中未完全考虑个体差异：

1. 用户是健康人。
2. 用户具有典型基因（例如，对咖啡因不敏感）。
3. 咖啡因被立即消费。
4. 用户了解自身的咖啡因耐受性。

兼容性与构建

• 项目使用Python 3.12.5版本构建。
• 包含一个咖啡因半衰期函数，用于计算咖啡因在体内的衰减。

致谢

• 感谢Aman Kharwal提供的编程模板。
• 标题图像由Freepik提供。

Redwood Cove架构摘要

Intel的Redwood Cove是Meteor Lake移动处理器的P核（性能核）架构，属于对前代Raptor Cove（2022年）和Golden Cove（2021年）架构的小幅迭代优化。其主要改进集中在前端、内存子系统及微操作效率方面，而后端执行单元变化有限。

主要改进：

1. 前端优化：

   • 分支预测：提升了准确性和速度，识别更长的分支模式，并降低了平均误预测恢复延迟。分支目标缓冲区（BTB）延迟从3周期降至2周期。恢复了对0x3E（taken hint）分支提示前缀的支持。
   • 指令缓存：L1指令缓存容量从32 KB翻倍至64 KB，提升了指令带宽和能效。
   • 微操作队列：指令解码队列（IDQ）容量从144条目增加到192条目（单线程模式），可作为更大的循环流缓冲器（LSD），有助于在循环中关闭前端以省电。
   • 指令融合：增强了宏融合能力，支持寄存器-寄存器MOV与后续算术指令的融合（MOV+OP），以及内存加载与依赖算术指令的融合（LD+OP），提升了指令吞吐效率和后端资源利用率。

2. 内存子系统：

   • 缓存：客户端产品的L2（中级缓存）容量提升至2 MB（与Raptor Lake一致）。L3缓存延迟较高（超过75周期）。
   • 预取器：新增了LLC页面预取器，可主动将后续两个4KB页面的数据预取到L3缓存，以降低延迟并避免污染L1/L2。新增了数组指针（AOP）预取器，用于识别并预取指针数组模式的数据。
   • 带宽与队列：L2未命中跟踪队列从48个增加到64个，旨在通过支持更多未完成请求来提升内存带宽。

3. 执行单元：

   • 后端结构大小基本与Golden Cove保持一致。
   • 浮点单元：将浮点乘法的延迟从4周期降低到3周期（历史上Broadwell为3周期，Skylake回归4周期）。

4. 超线程（SMT）：

   • 继承并优化了SMT实现。多数资源采用“水印”共享方式，允许单线程在闲置时占用大部分资源。
   • 在SPEC CPU2017测试中，双线程相比单线程在整数测试中提升约17.6%，在浮点测试中提升约4.2%，效率优于前代。

与竞品对比： 与AMD Zen 4相比，Redwood Cove在L3缓存延迟上处于劣势，但凭借更大的微操作队列和改进的指令融合，在部分工作负载中可能实现更高的指令吞吐。然而，在内存带宽方面，受制于Meteor Lake的平台特性（如较低时钟频率），其表现可能不及桌面级Golden Cove或Zen 4。

总结： Redwood Cove是一个针对系统级革新（如Meteor Lake的分离式模块设计）的稳健、低风险演进。它通过前端细微优化、缓存层次调整和预取策略增强来提升效率和性能，但在核心结构尺寸和IPC（每周期指令数）方面的提升相对温和。与近年来AMD架构的大幅跨越相比，Intel的这一步显得更为谨慎。

特斯拉在2024年Hot Chips大会上宣布开源Tesla Transport Protocol over Ethernet (TTPoE)，并加入了超以太网联盟，旨在推动一个面向AI/ML/数据中心的高速低延迟、标准化、非专有的网络协议。

TTPoE 设计与核心特性：

• 设计哲学：协议基于基础原理设计，以简单、直接为目标。核心思想是以太网传输应仅受物理限制，而非软件执行时间。对于超大规模集群，去中心化的分布式拥塞控制是关键，每个端点都应具备弹性和自我管理能力。
• 工作原理：与TCP类似，允许丢包和重传，但保证最终传输完成。
• 硬件部署：最初在特斯拉Dojo v1超级计算机上部署，协议完全在硬件中执行，无需CPU或操作系统参与，连接了数万个并发端点。
• 兼容性：旨在实现低成本，并使用标准以太网II帧格式。

TTPoE 传输头部结构： 协议头部紧跟TSH之后，为一个16字节的结构，包含以下关键字段：

• opcode (8位)：操作码，用于标识数据包类型。
• vc (8位)：虚拟通道标识。
• tx/rx (8位)：分别表示发送和接收端点标识。
• epoch (16位)：用于时间同步或状态区分。
• congestion (8位)：拥塞状态信息。
• tx-sequence / rx-sequence (各32位)：发送和接收的序列号，用于确保传输的可靠性和顺序。
• 其他保留字段和扩展字段。

软件模型与实现： GitHub仓库（https://github.com/teslamotors/ttpoe_sw）提供了匹配v1.5规范的Linux内核参考软件模型。

1. TTP 内核模块 (modttpoe.ko)：

   • 提供了内核模块，加载时需要配置参数，如网络设备(dev)、目标MAC地址(dest_mac)、是否使用网关(use_gw)等。
   • 通过/proc/net/modttpoe/文件系统提供状态查看、标签管理和事件日志等调试接口。
   • 包含一套完整的单元测试（基于Python的unittest框架），用于验证基本功能（如序列号管理、标签分配、数据包收发、流量测试等）。
   • 文档提供了一个完整的双主机（node-01与node-02）会话建立、数据发送和接收的示例，详细展示了模块加载、连接建立、数据传输以及通过noc_debug接口交互的过程。

2. TTP 网关模块 (modttpip.ko)：

   • 用于连接TTP网络和IP网络。
   • 加载时需配置参数，例如网关IP地址列表(gwips)、网络设备(dev)等。
   • 提供了查看网关接口(intfs)、设备(edevs)和MAC地址表(mactbl)的参数。
   • 文档给出了一个网关模块加载和网关地址解析的日志示例。
   • 目前尚无针对该模块的单元测试。

Brainfuck Enterprise Solutions (BES) 提供一系列专注于企业级韧性和高性能的产品与工具，其核心围绕 Brainfuck 编程语言构建，旨在满足现代企业计算需求。

主要产品与解决方案：

• 企业级操作系统： 一款新一代高性能操作系统，专注于提供企业级韧性。
• 集成开发环境： 一个功能无限可配置的集成 IDE 和文本编辑器。
• 核心解释器： 一款尖端、超快的可嵌入式 Brainfuck 元解释器，是其韧性刀片服务器的核心。
• 字符串操作库： 在 Brainfuck 中对高效字符串处理进行的重新构想与实现。
• 文档格式： 一套全面的文档格式规范，原为 BES 内部使用。
• 代码风格指南： 为适用于中大型代码库和多样化工程师团队而设计的先进风格指南。

这些组件共同构成了一个完整的生态系统，旨在支持从底层系统运行到开发、维护和团队协作的整个企业应用生命周期。

本文探讨了“公开构建”（build in public）这一在独立开发者（indie hacker）社群中盛行的做法，并对其当前状况提出了质疑。作者观察发现，虽然“公开构建”旨在透明、开放地分享公司成长故事，但实践中出现了一些问题。

对“公开构建”的质疑：

1. 是否过度使用？ 社交媒体（如 Twitter/X）上充斥着大量“公开构建”的帖子，其中约半数以上集中于分享收入里程碑（如月收入突破），辅以类似“三个月销售额增长100倍”的成就展示。作者认为，过度分享此类成就，尤其是重复性展示，可能更接近于炫耀或博取点击，而对关注者或产品的最终用户缺乏实质价值。相比之下，作者更希望看到关于产品功能迭代、长期规划等更具实质性的内容。
2. 是否依然有效？ 作者指出，“公开构建”的早期践行者（如 @levelsio）因其新颖性获得了大量关注并取得成功。然而，如今独立开发者社群已极为庞大（例如多个相关线上社群成员数以万计），导致这种策略变得普遍。作者犀利地指出：“当每个人都在公开构建时，就等于没有人真正通过公开构建脱颖而出。” 这意味着，在当下环境中，仅依靠“公开构建”来获取注意力和构建社群的难度已大大增加。

核心观点：

• 产品才是根本： 作者强调，无论是否采用“公开构建”策略，最终决定成功的仍是产品本身。他举出多个例子（如 PopClip 和 OrbStack 的开发者），这些出色的软件创造者很少公开构建或分享收入，但依然获得了成功。这说明“公开构建”并非必要或唯一的路径。
• 消除压力： 作者呼吁独立开发者不应因为没有跟随“公开构建”的潮流而感到压力，应根据自身情况选择合适的策略。

结论： 作者对“公开构建”的现状提出了反思，认为其过度普及可能导致效果减弱，并重申了优秀产品本身的重要性。他坦言自己仍在探索中，本文旨在提出问题而非提供终极答案。

Android 平板电脑桌面窗口（Desktop Windowing）功能摘要

核心目的

Android 推出桌面窗口功能（现处于开发者预览阶段），旨在通过允许用户同时运行多个应用并自由调整窗口大小，提升平板电脑的多任务处理能力和生产力，提供类似桌面的使用体验。

主要功能与用户交互

• 界面特性：支持多应用并排运行；提供固定的任务栏（Taskbar）以快速访问和固定应用；每个窗口顶部新增带有窗口控件的标题栏（Header bar），应用可对其进行自定义。
• 模式切换：应用默认全屏打开。用户可通过长按并拖动顶部窗口句柄、点击菜单或使用快捷键（Meta+Ctrl+Down）进入桌面窗口模式。退出该模式可通过关闭所有窗口、将窗口拖至屏幕顶部或使用快捷键（Meta+H）恢复全屏。

开发者优化指南

为适配桌面窗口，开发者需重点关注以下技术优化：

• 自由缩放与自适应布局：锁定方向的应用也可自由缩放（未来不可缩放的应用将保持比例进行 UI 缩放）。应用需利用窗口大小类（Window size classes）适配最小 386dp x 352dp 的窗口尺寸。
• 状态管理：窗口缩放会触发配置更改，应用需妥善处理这些更改，或在系统重建时保留应用状态，并确保兼容运行时的屏幕密度变化。
• 多任务与多实例支持：添加拖放手势以支持跨应用内容共享；确保应用在失去焦点时正常运行，并优雅处理相机或麦克风等独占资源的丢失。通过设置多实例（Multi-instance）属性允许应用多开，并注意新任务会在新窗口中打开。
• 输入方法与 Insets 处理：优化键盘、鼠标和触控板等外设输入体验，利用快捷键 API 发布应用快捷键。处理 Insets 时需适配新增的标题栏（Caption bar），API 35 引入了使其透明的选项，允许应用在内部绘制自定义内容。

测试与体验

开发者现可通过将 Pixel Tablet 更新至 Android 15 QPR1 Beta 2，或在 Android Studio Preview 中使用 Pixel Tablet 模拟器（选择 Android 15.0 目标）进行测试。在“开发者选项”中启用“Enable freeform windows”即可体验桌面窗口环境，从而为未来 Android 生态中普及的自由窗口模式做好应用适配准备。

这篇文章介绍了在为.NET平台开发Rust编译器后端（rustc_codegen_clr）时，如何实现Rust的panic机制（具体为栈展开）。

核心目标与架构

该项目是一个替换Rust编译器最终代码生成阶段的后端。它不使用LLVM生成本地代码，而是将Rust的中间表示（MIR）转换为.NET的公共中间语言（CIL），并封装在.NET程序集中。编译后的Rust代码从.NET运行时的角度看类似于不安全的C#，从而实现与.NET生态的互操作。最终目标是实现Rust与C#/F#之间的无缝互操作。

Panic 与 栈展开

• Panic：是Rust语言特性，通过panic!宏触发，用于表示程序逻辑错误。类似于异常。
• 栈展开：是panic的一种特定实现方式。当panic发生时，调用栈会逐级向上展开，沿途丢弃（drop）每个栈帧上分配的数据，直至遇到一个catch_unwind点。

MIR基本块与清理块

Rust编译器通过MIR（中级中间表示）来管理控制流。函数由一系列基本块组成，每个块包含顺序执行的语句和一个可能改变控制流的终止指令（如函数调用、跳转）。

• 清理块：是一种特殊的MIR基本块，其唯一目的是在栈展开期间负责清理（丢弃）当前栈帧中的数据。它们由编译器在需要的地方生成，类似C#中的finally或using块，但仅在栈展开（异常）时被调用。
• Drop标志：在某些情况下，变量可能未被初始化，编译器会引入额外的布尔变量（drop标志）来告知清理块是否需要执行drop操作。

实现挑战与优化

作者在将Rust清理块实现为.NET异常处理程序时遇到了性能问题。一些基准测试显示极高的性能开销，部分原因在于生成了大量、有时无效的异常处理代码。

问题根源：MIR优化与“幽灵drop”

• MIR优化的目的：主要是为了加速编译，而非直接优化生成代码的性能。通过在编译早期对泛型代码进行优化，可以减少后续LLVM优化阶段的工作量。
• 局限性：对于某些类型，编译器无法在泛型阶段进行优化（例如Clone类型可能带有副作用）。
• 幽灵drop：当被清理的类型本身无需任何操作（如i64）时，对应的drop操作为空（DropGlue为None）。这导致生成的异常处理程序中包含大量实际为空的逻辑和无用变量，形成“幽灵drop”。

对.NET JIT的影响

.NET的JIT编译器（RyuJIT）使用启发式方法（如基本块数量、字节码大小）来估算优化成本和内联收益。作者生成的臃肿CIL代码包含大量基本块（因为需要为每个可能引发异常的位置复制清理块，且.NET中不能跨异常处理程序跳转），这使得JIT认为函数过于复杂，从而放弃了内联等关键优化。

优化策略

作者实施了优化来移除无效的异常处理程序：

1. 检测与简化：识别仅包含无副作用操作（如局部变量赋值）和rethrow指令的处理程序。
2. 保守移除：如果整个处理程序没有任何可观察的副作用，则将其移除。
3. 效果：经过此优化及其他CIL优化后，生成的代码规模显著减小，复杂度降低，为JIT编译器进一步优化创造了条件。虽然仍有优化空间，但性能已得到改善。

结论

文章详细探讨了在.NET平台上实现Rust panic（栈展开）的复杂性，重点分析了MIR清理块的机制及其在.NET异常处理中的映射挑战。核心发现是，由于MIR优化策略和类型特性导致的“幽灵”清理代码，会生成臃肿的CIL，从而阻碍.NET JIT编译器的有效优化。通过简化和移除无效异常处理程序，可以在一定程度上缓解此性能问题。文章是系列的第一篇，后续将探讨标准库层面的panic实现及.NET异常捕获等问题。

• LinkedIn在2024年9月18日开始使用用户数据训练其生成式AI工具，但事先未更新服务条款，且用户默认参与（opt-in）。
• 该公司决定排除欧盟、欧洲经济区（冰岛、列支敦士登、挪威）、瑞士以及后来加入的英国用户，不将其数据用于AI训练。英国信息专员办公室（ICO）于9月20日确认LinkedIn已停止对英国用户进行AI训练。
• 此前，Meta和X（原Twitter）也曾试图用欧洲用户数据训练AI模型，但因欧盟隐私监管机构的强烈反对和GDPR（通用数据保护条例）的严格规定而被迫暂停。Meta因爱尔兰数据保护局（DPA）的要求暂停了对欧盟/EEA用户数据的使用；X则在爱尔兰消费者组织投诉后同意永久停止收集欧盟用户数据训练其Grok AI。
• 隐私专家欢迎欧盟的积极监管态度，认为其隐私框架是全球唯一有效的保护措施。有观点指出，科技公司默认启用（auto opt-in）的做法缺乏透明度，应让用户主动选择加入（opt-in）。
• 对于非欧洲用户，若不想让LinkedIn使用其数据训练AI，必须手动选择退出（opt-out）。操作路径为：进入设置菜单，选择数据隐私选项卡，关闭默认开启的“用于生成式AI改进的数据”功能。但此操作仅对未来数据有效，已收集的数据无法撤销。

本文探讨了跨架构程序移植中常见的问题，指出即使使用高级语言，移植性也非易事。文章基于在Gentoo的经验，列举了在32位系统上可能遇到的挑战以及其他架构相关的通用问题。

32位系统的核心问题：

1. 地址空间限制：32位指针仅能寻址约4GiB内存。即使物理内存充足，进程也可能因无法分配足够的虚拟地址空间而失败，尤其在程序进行大量内存分配但未完全使用时。
2. 大文件支持（LFS）：传统的off_t（文件大小/偏移）和ino_t（inode号）为32位，导致无法处理大于2GiB的文件或具有高位inode号的文件。通过定义_FILE_OFFSET_BITS=64可解决，但全局切换会影响库的ABI。
3. Y2K38问题：time_t为32位有符号整数，无法表示2038年后的时间戳。可定义_TIME_BITS=64获得64位时间支持，但同样面临ABI兼容性挑战，且对旧有二进制或文件格式无效。

其他跨架构通用问题：

1. 字节序（Endianness）：在实现二进制文件格式或网络协议时，未处理字节序转换会导致在不同架构（如大端PowerPC与小端x86）上数据读取错误。此问题也存在于UTF-16等文本编码中。
2. char类型的符号性：C标准未明确规定char是有符号还是无符号。某些架构（如x86, SPARC）默认为有符号，而其他架构（如MIPS, PowerPC）默认为无符号。假设错误会导致算术运算产生意外结果。
3. 严格对齐要求：某些架构（如SPARC）要求特定类型（如int32_t）的内存地址必须是其大小的整数倍。未对齐的内存访问在这些平台上会导致SIGBUS错误崩溃，在其他平台可能仅影响性能。
4. 栈大小差异：递归深度或栈帧大小在不同架构上差异显著（如x86的8-16字节 vs. s390x的160-176字节），且默认线程栈大小因C库而异（glibc的2-10 MiB vs. musl的128 KiB）。这容易导致栈溢出。

浮点数相关问题：

1. x87 FPU与SSE运算差异：32位x86默认使用80位精度的x87指令，可能因中间计算精度更高而产生与64位SSE运算不同的舍入结果，影响依赖精确值比较的程序（如测试套件）。
2. 不同指令集的影响：即使在同一架构上，启用FMA（乘加融合）指令集也会因中间计算精度和舍入方式不同，导致浮点结果与预期不符。
3. long double类型的不一致性：该类型在不同架构上实现各异，可能是双精度、80位扩展精度、双精度对或128位四精度，导致精度和值不同。

总结与启示：

• 移植问题并非C语言独有，它们同样影响构建在C运行时之上的Python等高级语言（如地址空间限制、时间戳溢出）。
• 当前许多问题源于仅在64位系统上测试，却在32位架构上出现回归。
• 尽管受影响的架构可能用户较少，但确保可移植性有助于编写更健壮的代码，并可能预防未来的重大安全问题。
• 测试时，应了解不同架构的特性以推断问题根源，例如，在PowerPC大端上失败可能是字节序、char符号性或栈大小问题。

Media Hoarder v1.4.0 更新摘要

核心新功能

1. 电视剧集支持：完整支持管理电视剧集，包括配置剧集来源路径、浏览和筛选剧集，以及点击进入单个剧集查看其分集列表。
2. 剧集评分热力图：在剧集详情中，通过点击评分可查看基于IMDB评分的剧集热力图，直观展示每一集的评分情况，并支持点击单集查看详情或播放。
3. HDR格式识别：视频质量筛选与展示中新增对HDR10、HDR10+、DV、HLG等HDR格式的检测与分类。

其他重要改进

1. 增强的重新扫描汇总：
   • 扫描后可显示新增、更新或删除的电影、剧集及分集数量。
   • 可查看详细变更报告，精确到单个文件。
   • 在设置中可回顾历史扫描记录。
   • 仪表盘显示收藏库大小。
2. UI与交互优化：
   • 在剧集和分集的对话框中新增“w2wTV”按钮，可直接跳转到 whattowatchon.tv 网站并预选该剧集。
   • 在搜索数据等对话框中，会显示人物或公司的具体角色。
   • 在各种列表（如导演作品列表）中点击任意媒体项目，可直接查看详情并播放。
3. 功能增强：
   • 允许用户自定义音频和字幕语言。
   • 所有对话框现在都支持显示电影和剧集。

技术细节与修复

• 数据库迁移：引入了新的迁移机制和表（tbl_DB_Migrations）。
• IMDB抓取器改进：
  • 优化了剧集扫描时的IMDB条目识别逻辑，优先匹配电视剧条目。
  • 修复了获取类型信息的问题。
  • 改进了GraphQL查询的URL管理（imdb-graphql-urls.json）和错误报告机制。
  • 在检测到无效的IMDB代码（tconst）时会自动停止抓取。
• UX与错误修复：修复了多个界面问题，包括排序、筛选器加载与切换、对话框层级、分集显示、搜索范围以及预告片播放时的卡顿等。

这是一个关于 数据科学代理与代码转换 的研究项目，其核心是探索一种名为 “多代理混合系统” 的方法。

• 核心问题：该项目研究的核心问题是，由多个专注于不同领域的、甚至可能相互“争论”的专家代理组成的群体，在解决问题的能力上，是否能够超越一个单一的、更庞大的通用智能体。
• 项目状态：目前，该项目仍处于 原型开发 阶段。
• 时间规划：该原型预计于 2026年2月 完成。