如何查找任何S3存储桶的AWS账户ID

本文介绍了一种用于查找任何（包括私有和公有）S3存储桶所属AWS账户ID的技术方法，该方法基于Ben Bridts在2021年提出并广为人知的技术，并进行了重要扩展。

核心原理

该技术依赖于三个关键要素的结合：

1. 向请求应用IAM策略：通过使用S3的VPC接口端点，可以在请求上应用IAM策略。
2. 推断策略是否允许了请求：由于目标存储桶为第三方私有存储桶，任何请求都会收到AccessDenied响应。但我们可以通过检查我们自己的AWS CloudTrail日志来推断VPC端点策略是允许还是拒绝了请求：
   • 若请求出现在CloudTrail中，表示VPC端点策略允许了请求（但被存储桶策略拒绝）。
   • 若请求未出现在CloudTrail中，表示VPC端点策略拒绝了请求。
3. 在s3:ResourceAccount条件键上使用通配符匹配：VPC端点策略支持使用StringLike通配符匹配s3:ResourceAccount条件键，从而可以逐位、逐步地探测账户ID，将搜索空间从万亿级降低到百级。

详细步骤

1. 确定存储桶区域：通过向存储桶端点发送HTTP请求（如curl），查看响应头x-amz-bucket-region获取其所在区域。
2. 部署基础设施：在确定的区域内，创建一个专用的VPC和一个接口类型的S3 VPC端点。
3. 启动EC2实例：在该VPC内启动一个EC2实例，确保其S3请求通过VPC端点。
4. 编写VPC端点策略：策略中使用Condition块，对s3:ResourceAccount应用StringLike通配符匹配。例如，要测试账户ID是否以0开头，策略条件为"s3:ResourceAccount": "0*"。
5. 发起S3请求：通过EC2实例向目标存储桶发送一个“管理”请求（如GetBucketAcl），该请求预期会被拒绝。
6. 检查CloudTrail：等待几分钟后，检查是否在CloudTrail中找到了该请求事件。根据结果判断账户ID的第一位数字。
7. 迭代与推导：根据上一步结果，修改VPC端点策略条件（例如，第一位是0则测试"00*"，第一位是1则测试"10*"），重复步骤5-6，逐步推导出后续每一位数字。
8. 自动化脚本：作者编写了Python脚本find-s3-account.py来自动化上述迭代过程。

性能优化

上述逐步探测的方法速度较慢（可能需要数小时），因为每次测试都需要等待策略生效和CloudTrail日志记录。为此，作者提出了一个并行测试的优化方案：

• 在单个VPC端点策略中编写120条语句（对应12位账户ID中每一位的0-9数字可能性）。
• 通过在STS AssumeRole调用中指定不同的RoleSessionName参数（例如0-----------, 1-----------等），将特定请求与策略中特定的条件语句关联。
• 这样，一次发出多个不同会话名称的请求，然后批量检查CloudTrail日志，即可在不到10分钟内确定完整的账户ID。

备注与影响

• 作者在发布前已咨询AWS安全团队。
• 该技术还可能适用于其他支持类似资源条件键的服务，或用于发现存储桶的其他条件键信息。
• 技术可行性归因于能够在策略中对s3:ResourceAccount使用StringLike通配符匹配。
• 对于被VPC端点策略拒绝的请求，若能在CloudTrail中记录可能更为有益。
• 该技术展示了即使存储桶是私有的，通过巧妙地结合IAM策略、VPC端点行为和日志分析，仍可能推断出敏感元数据。

波音公司安全文化缺失关键要素：FAA报告核心摘要

美国联邦航空管理局（FAA）的一份报告指出，波音公司在安全文化方面存在关键要素的缺失。以下为相关内容的综合摘要：

核心发现：波音安全文化缺陷

FAA报告的核心结论是，波音公司的安全文化体系未能涵盖所有必要元素，这影响了其整体安全表现。

行业安全倡议与研究

• 风险预警工具开发：某保险公司开发了低空危险预警工具，其应用程序可通过热力图显示直升机飞行区域的风险。
• 第一季度安全数据：美国国家公务航空协会（NBAA）第一季度审查报告强调了实施稳定进近的必要性，期间涉及公务机的15起事件和25起事故被记录在案。
• 安全文化驱动品牌与活力：航空安全基金会（ACSF）专家强调，企业应审视自身及周围环境的安全文化，认为文化是驱动品牌和行业活力的核心。

技术改进与安全措施

• 新型空速传感器：英国和加拿大的技术可提供更稳定的空速数据，其微传感器能抵御振动和皮托管堵塞的影响。
• 湿跑道安全：美国国家运输安全委员会（NTSB）聚焦湿跑道安全问题，在分析2008年至2022年间11起冲出跑道事故后提出了建议。
• 鸟类撞击预防：南非部署了鸟类撞击预防雷达，可提供360度覆盖、15公里范围的监测。

事故调查与监管进展

• 无证活动警示：报道指出飞行员资质和经验的疏漏导致了两起致命事故。
• FAA执行NTSB建议：针对NTSB就KDCA事件提出的建议，FAA正在推进，但大部分工作仍处于进行中，已落实的建议较少。

英国萨里大学领导的一项研究发现，城市中的绿色和蓝色基础设施能显著降低气温。研究综合分析了27000多篇论文中的202篇，评估了各类城市绿色空间的降温效果。

主要降温效果排名：

• 植物园：平均降温 5°C
• 湿地：降温 4.7°C
• 雨水花园：降温 4.5°C
• 街道树木：降温 3.8°C
• 城市公园：降温 3.2°C

作用原理： 树木和植物通过遮荫减少阳光直射，并通过蒸发作用向空气中释放水分。水体通过蒸发、蒸散作用、反照率效应等方式冷却环境，并可作为热沉储存热量。绿色屋顶和墙壁能为建筑隔热，减少热量吸收，植被还可作为风障促进自然通风。

研究意义： 该研究指出，在城市热浪日益频繁的背景下（如2022年英国破纪录的40.3°C高温及欧洲与热浪相关的死亡事件），将自然重新引入密集和扩张中的城市至关重要。研究认为所有类型的城市绿色-蓝色-灰色基础设施都具有降温效益，应抓住一切机会增加地面、露台、墙面和屋顶的植物覆盖。

注意事项： 研究同时强调，没有放之四海而皆准的解决方案。在选择具体干预措施前，必须评估当地环境条件、可用资源和预算，以确保其长期有效性并避免潜在弊端。各机构需根据社区特点进行针对性研究和投资。

该研究为应对城市高温提供了多种基于自然的解决方案参考，相关论文已发表在《The Innovation》期刊上。

F-35C是联合攻击战斗机的舰载型号，专为美国海军的弹射起飞/拦阻着舰航母设计，其拦阻着舰依赖于尾钩勾住甲板拦阻索。然而，F-35C的尾钩在最初设计上存在重大缺陷。

问题根源与初期测试失败：

• 尾钩的设计依赖于一个计算机模型来模拟拦阻索的动态，但该模型存在错误，未能准确预测拦阻索在飞机轮胎压过后的实际行为。
• 模型预测拦阻索会从甲板上弹起，但实际上拦阻索会平贴在甲板上。这导致尾钩无法勾住绳索，并且钩头会以极高的角加速度回弹，损坏了测试仪器。
• 2011年在莱克赫斯特海军航空站进行的初期地面测试几乎全部失败，测试团队甚至在飓风来临前被迫中止了令人沮丧的试验。

设计修正与后续问题：

• 尾钩因此进行了重大重新设计，包括加强阻尼器、改进钩鞋形状以更好捕捉低垂的拦阻索等。
• 尽管设计改进后取得了一些进展（2013年成功完成首次拦阻），但问题并未完全解决。尾钩的俯仰枢轴销磨损过快，寿命远低于要求，导致维护工作繁重，工程师们不得不频繁更换并开发快速校准方法以提高效率。

测试中的惊险事件：

• 2016年，在一次追求偏心拦阻的测试中，由于助降系统（菲涅尔透镜光学着舰系统）设置错误，飞机以过高的下降率、近乎水平的姿态重击跑道，所有起落架被压到底，情况如同从约6米高空坠落。这次严重事件导致飞机被扣留进行漫长检查，并最终促使项目决定停止追求极端的偏心拦阻测试。

总结： F-35C尾钩的测试历程充满了挑战。它始于一个基于有缺陷模拟模型的初始设计，导致了反复的测试失败。经过重大的硬件重新设计后，又遇到了部件可靠性问题和一次严重的测试事故。整个过程凸显了飞行测试中模型验证的重要性，以及在面对复杂工程问题时持续调试和适应的必要性。最终，受限于实际条件和风险，部分极端的测试目标被放弃。

为什么时间似乎随着年龄增长而过得更快

时间感知的变化

• 36岁时，一年感觉比童年或青少年时更短，这似乎不公平，因为寿命减少但时间飞逝更快。

原因分析：大脑的进化机制

• 大脑是进化出的高效存储设备，主要功能是构建世界模型以预测未来，从而增加生存和繁殖优势。
• 大脑专注于预测现象（如寻找伴侣、赚钱等），以实现控制和权力。

效率与记忆存储

• 大脑只关注和记忆新颖、令人惊讶的事物，避免冗余存储以提高效率。
• 童年时，世界充满新奇，大脑大量更新记忆（如生日、假期、学校日子），时间感觉丰富而漫长。
• 成年后，新事件只是对旧记忆的小更新，记忆和注意力的保真度降低，时间感知变粗糙。

时间感知与记忆的关系

• 回忆时，童年记忆密集，成年记忆稀少，导致时间感觉在过去积累，近期却飞逝。

可预测性是关键

• 时间飞逝的主要原因是可预测性：生活越可预测，感觉时间越短。
• 例如，稳定工作可预见未来，而未知活动（如读梵文博士）则不可预见，时间感觉更充实。

应对策略：打破可预测性

• 减缓时间感的唯一方法是主动计划让自己大吃一惊，探索未知领域。
• 进化障碍：年龄增长后，大脑倾向于利用已知世界，避免探索和冒险，但这正是时间飞逝的原因。
• 反思生活意义：选择“感觉长”的一生而非单纯“长”的一生更重要。

解决方案与启示

• 解决方案不是无聊，而是全身心投入未知领域（身体或心理旅行）。
• 人类擅长识别模式，一旦预测结局就会失去兴趣，存在主义危机如同生活剧透。
• 激进变化是关键：变化越小，记忆越少，时间感越模糊；保持大脑活跃需要 radically different 生活。

一款由作者开发的AI配音工具，可将任何视频内容以用户选择的语言进行配音与观看，适合扩大受众群体。主要功能包括：

• 语音克隆：能将原视频中的声音通过AI迁移到其他语言，实现同样声音的多语言表达。
• 时间同步：AI自动调整用词和语速，保证译制语音与原视频时间一致。
• 文字游戏与成语处理：通过精细调校，AI能恰当地将原视频的文字游戏和成语译为目标语言。
• 支持16种以上输出语言，包括英语、普通话、西班牙语、阿拉伯语、法语、俄语、德语、意大利语、韩语、波兰语和荷兰语等。
• 多说话人翻译：针对多人物场景（如访谈、纪录片等），能为每位说话者分别配音。
• 自动生成高精度逐字字幕，方便学习与理解。
• 可选原声降噪：使用可选的ducking功能，可完全替换原声音或在背景中保留，提升透明度。

该工具适用于媒体制作、商业、团队协作和教育等多种场景，旨在实现多语言内容的即时转换与传播。

纽约阿尔伯特·爱因斯坦医学院宣布，在获得93岁退休教授鲁思·戈特斯曼博士捐赠10亿美元后，将取消学生学费。这笔捐赠来自戈特斯曼博士，她是该校前教授，其已故丈夫大卫·戈特斯曼是华尔街知名投资者和伯克希尔·哈撒韦的早期投资者。这是美国学校历史上最大的捐赠之一，也是医学院有史以来最大的捐赠。

布朗克斯区是纽约市最贫困的区，也被列为纽约州最不健康的县。学院院长表示，这笔“变革性”捐赠将彻底改变学校吸引致力于其使命的学生的能力，而不仅仅是能负担学费的学生。学院每年学费近59,000美元，学生常背负沉重债务。

从2024年春季学期起，最后一年学生将获得学费报销；自8月起，所有学生包括在读生，均可享受免费学费。这将减轻学生经济负担，让他们能自由追求原本因成本过高而无法实现的项目。

戈特斯曼博士自1968年起在该校工作，专注于学习障碍研究、扫盲项目，并开发了广泛使用的筛查和评估协议。她表示，希望资助学生免费接受教育，并已故丈夫留下的伯克希尔·哈撒韦股票组合提供了足够资金以永久支持此项目。

学生人口统计显示，约50%的一年级学生来自纽约，60%为女性。医学学生中约48%为白人，29%为亚裔，11%为西班牙裔，5%为黑人。戈特斯曼博士认为，该校培养的医生为布朗克斯及全球社区提供优质医疗服务，并希望丈夫会支持这一捐赠。

SpaceX于11月18日进行的星舰（Starship）最近一次发射任务中，火箭的上面级和下面级（超重助推器）均在飞行过程中失联。美国联邦航空管理局（FAA）已完成对此次事故的调查，并于周一宣布结束调查。

调查结论与后续步骤
FAA接受SpaceX提交的事故报告，确认了事故的根本原因及17项纠正措施。SpaceX必须在下次发射前实施所有整改，并获得FAA修订的许可证，该许可证需涵盖安全、环境及其他所有适用的监管要求。FAA商业航天运输负责人Kelvin Coleman表示，许可证审批流程预计在明年3月初至中旬完成，之后SpaceX将很快尝试进行第三次发射。

事故过程解析
SpaceX首次详细说明了11月18日发射失败的具体情况：

1. 超重助推器表现：发射初期一切正常，33台猛禽（Raptor）发动机全部成功点火，助推器按计划完成了持续燃烧和级间分离。
2. 热分离操作：上面级在部分助推器发动机仍在工作时成功执行了“热分离”操作，与助推器脱离。
3. 故障发生：在随后为返回墨西哥湾软着陆而进行的初次再入点火中，助推器计划启动13台发动机。点火期间，多台发动机接连关闭，其中一台发动机发生剧烈故障，迅速导致助推器解体。事故发生时，火箭已飞行超过3分半钟，高度约90公里。

Rapier 物理引擎概述

Rapier 是一套使用 Rust 编程语言编写的 2D 和 3D 物理引擎。

核心定位与目标

• 目标应用：面向需要实时物理模拟的应用，例如视频游戏、动画制作和机器人学。
• 设计原则：注重高性能、稳定性，并可选支持跨平台确定性。

主要功能

引擎的功能集包括：

• 刚体碰撞与力的模拟。
• 关节约束系统。
• 接触事件和传感器系统。
• 快照功能。
• 可选的跨平台确定性。
• 提供 JavaScript 绑定。

开源与开发信息

• 许可协议：免费且开源，基于 Apache 2.0 许可证发布。
• 开发方：由 Dimforge 开源公司开发维护。
• 支持方式：可通过 GitHub Sponsors 进行赞助。

《关于光、颜色、混合颜料与数值优化》内容摘要

本文介绍了作者为微缩模型绘画开发的虚拟颜料混合工具及其背后的理论原理与实践方法。

核心目标与工具

作者结合其游戏图形工程师的专业背景，创建了一个虚拟颜料混合工具。该工具允许用户选择目标颜色（如从照片中取色），并通过数值优化算法，从一组基础颜料中计算出能最接近该颜色的混合配方。工具现已有网页版本（www.paint-mixing.com），使用WebAssembly在浏览器中运行。

技术基础：光、反射与颜色感知

1. 光：以光谱功率分布描述，不同光源（如标准光源D65）有特定的SPD。
2. 反射：对于亚光颜料，主要关注漫反射。物体的颜色由其光谱反射率决定，即物体将不同波长的光反射回空间的比例。
3. 人眼与色彩：人眼通过L、M、S三种锥状细胞感知颜色。通过色彩匹配实验，建立了XYZ色彩空间，将连续的光谱信息转化为三个数值，便于计算。所有现代色彩空间（如sRGB）均由此衍生。

颜料混合模型：Kubelka-Munk理论

颜料混合并非简单的颜色线性相加。作者采用了工业上常用的Kubelka-Munk理论（一种双通量模型）进行建模：

• 该理论将光线在颜料层中的行为简化为吸收和散射两个过程，并用系数K和S来表征。
• 关键特性：颜料混合时，混合物的K和S系数是其组成颜料K、S系数的线性加权平均。这使得混合计算变得可行。
• 通过测量不透明白色颜料（假设其S=1）的反射率，可计算其K值。再测量其他颜料及其与白色混合物的反射率，即可解出每种颜料的K和S系数。

实践与测量

• 颜料选择：作者选用Kimera颜料，因其为单色素、颜料浓度高、一致性好，适合精确建模。
• 测量工具：使用自制的手持分光光度计（核心为滨松C12666MA传感器）测量颜料样品的光谱反射率。
• 测量流程：
  1. 制备所有基色的不透明涂层样本。
  2. 将每种颜色与白色以已知重量比混合，制备混合样本。
  3. 测量各纯色样本及其白色混合物的反射率，计算每种颜料的K和S系数。

求解优化与工具功能

• 优化算法：给定目标sRGB颜色，求解器会尝试1至4种颜料的所有组合，使用L-BFGS-B-C算法优化混合权重，以最小化预测颜色与目标颜色在sRGB空间中的L2损失函数。
• 工具界面（Python/PyQt）：
  • 展示颜料库及其光谱、色彩信息。
  • 提供虚拟混合面板，可直观调整比例并查看光谱与色度图变化。
  • 包含配方求解器，可拾取屏幕颜色并计算配方，结果按1-4种颜料组合列出。

测试结论与局限性

• 工具预测的颜色在大多数情况下与实际混合结果接近，验证了Kubelka-Munk模型的有效性。
• 主要误差来源是某些高透明度颜料（特别是黄色）的测量困难，导致其K/S系数不准确。
• 模型未考虑桑德森修正系数（表面镜面反射的影响），是未来的改进方向。
• 工具提供的配方是数值优化结果，在实际手工混合时需作为比例参考，而非精确处方。

Blazer：简化的商业智能工具

Blazer 是一款开源商业智能工具，允许团队通过 SQL 探索数据、轻松创建图表和仪表板，并进行共享。它提供 Docker 镜像，已在 Instacart 经过实战检验。

主要功能

• 多数据源支持：兼容 PostgreSQL、MySQL、Redshift 等众多数据库。
• 变量：支持在查询中使用变量，便于动态调整参数。
• 检查与警报：可设置数据质量检查，异常时通过邮件或 Slack 通知。
• 审计跟踪：记录所有查询操作。
• 安全性：可与现有认证系统集成，支持生产环境访问控制。

安装与配置

通过 Gemfile 添加 gem，运行安装和迁移命令，并在路由中挂载引擎。生产环境需配置数据库 URL。安全建议使用只读数据库用户。

检查功能配置：

• 需要设置邮件主机以接收通知。
• 通过 cron、Solid Queue 等调度任务定期运行检查。
• 可配置 Slack 通知。

认证方式：

• 支持基本认证（环境变量）、Devise 及自定义方法。

查询功能

• 变量：在查询中使用 {variable} 语法，支持时间范围变量。
• 智能变量：通过配置将 ID 映射为可读标签。
• 链接列：将查询结果中的列设置为可点击链接。
• 智能列：自动关联其他表的值，无需手动 JOIN。
• 缓存：可自动缓存慢查询或所有查询结果。

图表与可视化

Blazer 根据查询返回的列类型自动生成图表：

• 折线图：基于时间戳和数值列。
• 柱状图：基于字符串和数值列。
• 散点图：基于两个数值列。
• 饼图：基于字符串和数值列（最后一列需命名为 pie）。
• 地图：支持经纬度或 GeoJSON 数据（需 Mapbox 令牌）。
• 目标线：使用名为 target 的列绘制基准线。

仪表板

可将多个查询组合成仪表板，自动展示图表或表格。若查询包含变量，会在仪表板上显示相应输入控件。

高级功能

• 检查：创建查询识别数据异常，设置邮件或 Slack 通知。
• 队列分析：通过 /* cohort analysis */ 注释生成用户队列分析。
• 异常检测：支持 Prophet、Trend 或 AnomalyDetection.rb 三种方法。
• 预测：对时间序列数据使用 Prophet 或 Trend 进行预测。
• 上传：通过 CSV 文件创建数据库表（仅限 PostgreSQL）。

数据源

支持数十种数据源，包括：

• 关系型数据库：PostgreSQL、MySQL、SQLite、SQL Server 等。
• 数据仓库：Redshift、BigQuery、Snowflake、Athena 等。
• 大数据系统：Hive、Spark、Presto/Trino、Druid 等。
• NoSQL 及搜索引擎：MongoDB、Cassandra、Elasticsearch、OpenSearch 等。
• 其他：Salesforce、Socrata (SODA) 等。

每个数据源可通过 config/blazer.yml 配置 URL 和适配器，并支持创建自定义适配器。

权限与安全

• 查询权限：未命名查询为未列出；以 # 开头的查询仅创建者可见；以 * 开头的查询仅创建者可编辑。
• 查询归档：可归档超过 90 天未查看的查询。
• 内容安全策略：若视图加载异常，需检查 CSP 设置。

性能

默认同步运行查询，可通过配置启用异步执行（需配合集中式缓存如 Memcached 或 Redis）。

其他资源

• 提供 SQL 学习资源链接。
• 使用多种开源项目构建，如 Rails、Vue.js 等。
• 欢迎贡献代码、文档或功能建议。

本文介绍了作者在计算机视觉课程中针对漫画分镜分割问题的改进方案。传统启发式方法（如Max Halford的算法）基于边缘检测和边界框拟合，虽有效但存在局限：无法处理任意多边形分镜，且难以识别“负空间”分镜（即由相邻分镜边界定义的区域）。

为解决这些问题，作者采用基于分割模型SAM的方法，并通过程序化生成合成数据进行微调。具体做法包括：

• 使用随机生成的布局模拟漫画页面，分镜形状可自定义（多边形或负空间）
• 从Danbooru数据集中采样图像填充分镜，并通过CLIP编码器确保风格一致性
• 生成的合成数据集完整覆盖多种分镜类型，解决了真实标注数据稀缺的问题

模型方面，作者基于SAM进行修改：

• 利用SAM的图像编码器提取特征
• 轻量化解码器改为预测分镜的角点坐标，而非原始像素级掩码
• 训练时随机选择分镜内一点作为查询提示，要求模型输出对应分镜的四个角点
• 训练技巧：需统一角点顺序以避免收敛问题；采用L1损失优于L2损失

评估结果显示：

• 在真实漫画《Pepper and Carrot》上，本方法IoU达0.88，PCK@0.1达0.98，接近传统方法（Halford方法IoU为0.93），且显著优于原始SAM（IoU仅0.42）
• 在合成数据集上本方法表现最佳（IoU 0.88，PCK@0.1 0.99）
• 支持交互式查询和批量预测两种模式，适用于真实漫画场景

作者指出方法仍存在局限，对复杂拥挤页面可能失效，但认为通过改进数据比设计新启发式规则更易实现，且神经网络通常能获得可靠结果。相关代码、模型及标注数据集已开源。

这种名为 Danionella cerebrum 的微型鱼类，体长仅约12毫米，却能发出超过140分贝的声响，强度堪比枪声、救护车警报或气锤。研究由柏林夏里特大学团队完成，发表于《美国国家科学院院刊》。

传统鱼类发声主要依赖鱼鳔及相关肌肉振动，但该物种拥有已知脊椎动物中最小的大脑，其发声机制一直成谜。研究发现，它们拥有一套独特的发声系统：一块鼓状软骨、特化的肋骨和抗疲劳肌肉。当特殊肌肉将紧邻鱼鳔的肋骨拉向软骨，肋骨释放后击打鱼鳔，从而产生响亮的脉冲声。

雄性个体肋骨更坚硬，因此仅雄性可发出声音，雌性则无法发声。研究指出，这种非凡的适应性机制拓展了对动物运动和物种多样性的认识。目前发声原因尚未完全明确，研究者推测可能用于在浑浊水域中导航，或是雄性警告竞争者的一种攻击策略。

Blender Open Movies 是一个标志性的开放电影项目，提供完整的制作资源，包括所有生产文件、资产、艺术作品，以及从未公开过的内容。

Ryzen Z1 的微型集成显卡分析

华硕 ROG Ally 提供两种配置：搭载 AMD Ryzen Z1 Extreme 和 Ryzen Z1。本文聚焦于 Ryzen Z1 的集成显卡（iGPU）Radeon 740M，它与 Z1 Extreme 的 Radeon 780M 及 Steam Deck 的 iGPU 进行了详细对比。

核心配置差异

• Radeon 740M：仅配备 2 个 RDNA 3 工作组处理器（WGP）。
• Radeon 780M：拥有 6 个 RDNA 3 WGP，计算规模更大。
• Steam Deck iGPU：采用 4 个 RDNA 2 WGP，架构较旧。

尽管规模最小，但 Radeon 740M 利用了 RDNA 3 架构的新特性（如 FP32 双发射能力）并运行在更高时钟频率下，使其在特定场景下具备竞争力。

性能关键点

1. 计算吞吐量：

   • RDNA 3 的双发射能力可倍增理论 FP32 吞吐量。在利用此特性的测试中（如 wave64 模式），Radeon 740M 的 FP32 性能超越了 Steam Deck 的 iGPU。
   • 当双发射未被利用时（如特殊函数计算），两者性能接近。
   • 整数指令性能方面，740M 依靠高主频同样接近 Steam Deck 的 iGPU。
   • Ryzen Z1 Extreme 的 780M 在所有类别中大幅领先 Z1 的 740M。

2. 缓存与延迟：

   • RDNA 采用三级缓存层次结构。Radeon 740M 虽小，但得益于更高时钟，其向量和标量内存路径的延迟均低于 Steam Deck 的 iGPU。
   • Z1 Extreme 的 780M 拥有更大的 2MB L2 缓存，而 740M 和 Steam Deck 的 iGPU 均为 1MB。

3. 内存带宽：

   • 740M 依靠高时钟实现了与 Steam Deck iGPU 相近的缓存带宽。
   • 两款 iGPU 均受益于 LPDDR5 内存提供的高带宽。与 Z1 Extreme 的大型 iGPU 相比，740M 的计算规模较小，因此其显存带宽与计算吞吐量的比率更优，不易受内存带宽限制。

4. CPU-GPU 数据交互：

   • 作为集成显卡，三者（Z1, Z1 Extreme, Steam Deck）在主机与设备内存间传输数据时，都绕过了 PCIe 的瓶颈，带宽远超 PCIe 4.0 x16。
   • 但在使用计算着色器进行数据复制时，Z1 的较小着色器阵列因可并行任务较少，延迟隐藏能力较弱，表现稍逊。

功耗与定位分析

• 功耗受限优势：在电池供电等功耗受限场景下，Radeon 740M 的小型设计能维持高时钟频率，与大型 iGPU 的性能差距会缩小。
• 插座供电场景：当设备接通电源（如涡轮模式），允许 Z1 Extreme 的 iGPU 发挥全部性能时，两者差距显著拉大。
• 芯片面积分配：Ryzen Z1 芯片面积约 137mm²，其 iGPU（2 个 WGP）仅占约 5.1mm²，而 CPU 核心占 17.2mm²。与 Steam Deck 的 Van Gogh APU（GPU 占 17.7mm²）相比，Ryzen Z1 的 GPU 规模明显更小。

总结与评价

Ryzen Z1 的 Radeon 740M 展示了小规模 GPU 通过高时钟和先进架构挖掘性能的潜力。其强项在于：

• 功耗受限时保持高性能。
• 具备优秀的显存带宽与计算平衡比。
• 继承了 RDNA 3 的架构优势。

然而，对于 “游戏优先”的设备，其 2 个 WGP 的配置显得规模过小。作者认为，Ryzen Z1 非常强劲的 CPU（2 个 Zen 4 核 + 4 个 Zen 4c 核）结合相对孱弱的 GPU，使其更适用于生产力优先、游戏次之的设备，例如小型超极本或变形本，而非以游戏为核心的手持设备。尽管华硕将其用于 ROG Ally 并无不妥，但该芯片的特质在后者中并未得到最佳发挥。

Berlin TYPE 是柏林市的官方字体，由设计公司 Jung von Matt 主导设计，旨在为德国首都塑造全新的、统一的城市视觉形象。

该字体的设计深受柏林独特历史与多元文化的影响。设计师通过深入研究，从城市的公共空间中汲取灵感：

1. 地铁站字体：不同年代建造的地铁站展现出从新艺术风格到战后现代主义等多种字体样式，其中几何构造和非常规字形（如对角线末端的“t”和宽大的“z”）被融入设计。
2. 街道标牌：历史上东、西柏林的标牌制作工艺不同（丝网印刷 vs. 分层塑料铣刻），后者带来的圆角特征被继承到新字体中，为其增添了温和友好的气质。
3. 建筑与广告：从二十年代装饰艺术风格的霓虹灯字体（体现为字母中极高或极低的“腰部”），到五六十年代手动绘制、风格鲜明的广告字体，这些充满个性的历史痕迹均为字体注入了柏林特有的风味。

在设计实现上，Berlin TYPE 结合了传统影响与现代理解：

• 技术精细：基于精密的网格绘制，进行光学微调，确保在不同尺寸下均保持优秀的可读性和舒适的阅读节奏。
• 关键特征：拥有较大的x-height以提升易读性；所有字符带有微妙的圆角；独特的扁平化字母A设计能避免油墨堆积。
• 功能全面：目前包含常规体和粗体，支持所有欧洲语言，并配备丰富的排版符号（如公共建筑所需的箭头、货币符号等），还通过OpenType功能提供替代字符（如用于小尺寸的双层结构“a”）。

Berlin TYPE 旨在代表柏林的现代形象，应用于印刷和数字媒体。其常规体和粗体可免费下载，供公众在柏林市的宣传活动和公共界面中使用，体现了其作为城市公共财产的属性。

开源项目商业化经历总结

作者分享了将开源项目EmailEngine（原名IMAP API）转变为全职业务的历程，反映了从理想主义开源到务实商业化的观念转变。

早期开源理念

• 激进态度：15年前开始发布开源软件时，只使用MIT、BSD等宽松许可证，追求使用范围最大化。
• 拒绝赞助：曾拒绝一家大型交易邮件服务商的捐赠，以避免偏向性。
• 关键转折：看到一家使用其开源库Nodemailer的公司以5亿美元被收购，而自己未获得任何回报（无代码贡献、捐赠或致谢），引发了商业化的思考。

商业化初期尝试

• 许可证策略：发布新项目EmailEngine时采用AGPL许可证（Copyleft），同时提供可选的MIT许可证版本（需订阅）。
• 订阅制失败：设定年费250欧元，期望企业为避开Copyleft限制而付费。结果仅获得少量订阅（总收入750欧元），且订阅者似乎未实际使用产品。
• 强制许可模式：重新设计产品后，改为商业许可证，并实施许可证密钥验证系统（无密钥则15分钟后停止工作）。源代码仍公开在GitHub上，但不再符合开源定义（改为“源码可见”）。

商业化成功与调整

• 定价策略：保持初始250欧元年费后，首个半月即售得1750欧元，远超此前收入。随后逐步提价至895欧元，客户数量未减少，收入稳步增长。
• 当前业绩：月经常性收入（MRR）达6100欧元，足以支持作者在爱沙尼亚全职开发。
• 辅助开源工具：仍发布MIT许可证的小型工具（如ImapFlow库），用于为主产品引流，每月带来约100次访问，偶有转化。

关键反思

• CLA作用：早期要求贡献者签署贡献者许可协议（CLA），确保了许可证变更的合法性。
• 赞助局限性：GitHub赞助收入不稳定（月均50-750美元），企业客户付费更可靠。
• 核心教训：早该更早转向商业化，而非长期提供免费开源软件。企业用户对小额订阅费用不敏感，持续的产品迭代和专业形象比开源理想主义更能保障收入。

ingestr 开源数据复制工具摘要

核心功能

ingestr 是一个开源的命令行应用程序，用于在不同数据源和目标之间复制数据。其主要特点是无需编写任何代码，用户仅通过命令行标志（flags）即可完成数据迁移。

主要特性

• 简易数据复制：从任意数据源复制数据到任意目标位置。
• 增量加载支持：支持追加（append）、合并（merge）或删除后插入（delete+insert）等增量加载模式。
• 便捷安装：提供单命令安装，可通过curl脚本或pip进行安装。

安装与使用

1. 安装：
   • 通过curl脚本：curl -LsSf https://getbruin.com/install/ingestr | sh
   • 或使用pip：pip install ingestr
2. 快速入门示例：

   ingestr ingest \
       --source-uri 'postgresql://admin:admin@localhost:8837/web?sslmode=disable' \
       --source-table 'public.some_data' \
       --dest-uri 'bigquery://<your-project-name>?credentials_path=/path/to/service/account.json' \
       --dest-table 'ingestr.some_data'
   

   该命令将从PostgreSQL数据库的 public.some_data 表复制数据到BigQuery数据仓库的 ingestr.some_data 表中。

支持的数据源与目标

ingestr 支持广泛的数据源和目标，主要分为两大类：

1. 数据库：

   • 支持为源和目标：AWS Athena、Redshift、Cassandra、ClickHouse、CrateDB、Databricks、DuckDB、DynamoDB、Elasticsearch、Google BigQuery、Microsoft Fabric、Microsoft SQL Server、MongoDB、MotherDuck、MySQL、PostgreSQL、SQLite、Snowflake、Trino、Azure Data Lake Storage Gen2、Google Cloud Storage (GCS)、S3。
   • 仅支持为源：Couchbase、GCP Spanner、IBM Db2、InfluxDB、Kafka、Oracle、RabbitMQ、SAP Hana、Socrata。
   • 仅支持为目标：Microsoft OneLake、Synapse。

2. 平台与服务：

   • 支持从众多SaaS平台和API作为数据源，例如：Adjust、Airtable、Facebook Ads、Google Ads、Google Analytics、GitHub、HubSpot、Jira、Mailchimp、Salesforce、Shopify、Stripe、TikTok Ads等。
   • 部分平台也支持作为数据目标，如Azure Data Lake Storage Gen2、Google Cloud Storage、S3。

社区与贡献

• 提供Slack社区供用户交流。
• 欢迎Pull Requests，但建议先通过Issue讨论计划变更。开发时需运行make setup安装githooks。

许可证

ingestr 采用 Functional Source License 1.1 开源，未来将转为 Apache 2.0 许可证。允许在内部生产、开发、测试、教育、研究和专业服务中自由使用，但禁止用于提供竞争性的商业数据摄取、ELT、连接器或托管数据管道产品/服务。每个版本在发布两年后将转为Apache 2.0许可证。

Mountaineer 框架总结

Mountaineer 🏔️ 是一个用于便捷构建 Python 后端 和 React 前端 Web 应用的框架。它旨在提升开发者体验与生产效率，让熟悉这两种语言的开发者能快速上手。

核心特点

1. 全栈类型提示：在前端、后端及数据库层均支持类型提示，增强代码可靠性。
2. 简化的通信：客户端与服务器之间的通信、数据绑定及函数调用非常简便。
3. 优化的服务端渲染：提升应用的可访问性（Accessibility）和SEO。
4. 静态分析验证：对网页进行静态分析，确保链接有效性、数据访问等强验证。
5. 简化部署：无需单独搭建API服务器或Node.js服务器来服务前端客户端。

快速开始

创建新项目

使用内置的项目生成器快速搭建基础项目：

pipx run create-mountaineer-app

执行后，将生成一个名为 my_webapp 的标准项目结构：

• /controllers：存放路由控制器（如 home.py），每个文件对应一个路由。
• /models：定义数据模型。
• /views：React前端项目根目录，采用基于磁盘的路由结构（如 app/home/page.tsx），包含 package.json 和 tsconfig.json。
• app.py 和 cli.py：分别为应用入口和CLI命令定义文件。
• pyproject.toml：项目配置文件。

开发与运行

1. 数据库准备：推荐使用PostgreSQL，可通过项目附带的Docker Compose文件快速启动：

   docker compose up -d
   uv run createdb
   

   也可在项目根目录的 .env 文件中配置现有数据库。
2. 启动开发服务器：
   • 使用 uv run runserver 命令启动开发服务器，预览前端并自动构建依赖文件。默认在 http://127.0.0.1:5006 运行。
   • 或使用监视模式，仅监控源码变化并让前端获取后端API定义，而不启动服务器。

文档资源

项目提供完整的文档，包括教程、设计哲学、核心概念和API参考。