AT&T 客户数据泄露事件总结

事件概述

美国电信巨头 AT&T 确认发生大规模数据泄露事件，约 1.1 亿名（即“几乎所有”）客户的电话记录遭网络犯罪分子窃取。AT&T 已设立专门网站通知受影响用户，并向监管机构提交了披露文件。

泄露数据详情

• 被窃取的数据：
  • 蜂窝网络和固定电话用户的电话号码。
  • 2022年5月1日至10月31日期间（少数 unspecified 客户包含2023年1月2日的数据）的通话和短信元数据（包括通信双方号码、通话/短信总次数、通话时长）。
  • 依赖 AT&T 网络的其他移动运营商客户的通话记录。
  • 部分记录包含基站识别码（Cell site IDs），可用于推断通话或发送短信时的大致地理位置。
• 未被窃取的数据：
  • 通话或短信的具体内容。
  • 通话或短信的具体日期和时间。

泄露原因与攻击背景

• 泄露源头：被盗数据来自云数据公司 Snowflake。这是近期针对 Snowflake 客户（如 Ticketmaster 等）的系列数据窃取事件之一。安全响应公司 Mandiant 指出，约有 165 家 Snowflake 客户的大量数据被盗。
• 安全漏洞：Snowflake 将数据失窃归咎于客户未启用多因素认证（MFA），而 Snowflake 此前并未强制要求其客户使用该安全功能。
• 黑客组织：Mandiant 将此次攻击归因于一个名为 UNC5537 的黑客组织。该组织以经济利益为动机，成员分布在北美及至少一名在土耳其。
• 数据现状：AT&T 表示，目前认为这些被盗数据尚未在公开网络上发布。

官方响应与调查进展

• 事件发现：AT&T 于 4 月 19 日获悉此次泄露，并确认该事件与今年 3 月发生的另一起安全事件（涉及客户账户加密密码泄露）无关。
• 执法合作与逮捕：AT&T 正与执法部门合作抓捕网络罪犯，目前已逮捕至少一名嫌疑人（该嫌疑人非 AT&T 员工）。
• 延迟通知：FBI 证实，在 AT&T 报告此事后，AT&T、FBI 和美国司法部（DOJ）曾两次推迟向公众和客户发布通知，原因是考虑到“对国家安全或公共安全的潜在风险”。在此期间，各方共享了关键威胁情报以协助 FBI 调查和 AT&T 的事件响应工作。

Tau: 开源PaaS平台概述

Tau 是一个开源的、基于Git的平台即服务（PaaS），旨在用于构建、部署和扩展应用程序。它将基础设施定义直接置于Git中，从而消除了对API调用的依赖。作为一个完全可自托管的解决方案，Tau提供了与Vercel、Firebase和Cloudflare相当的功能，并内置了AI特性。

核心功能与工作流程

Tau 的核心工作流程围绕三个主要阶段：

1. 开发环境：提供开发和测试应用程序所需的工具和环境。
2. 构建应用：支持应用程序的构建过程。
3. 部署与运行：负责将应用部署到目标环境并确保其运行。

快速开始与部署方式

Tau 提供了多种上手和部署途径：

• 本地运行：最快捷的体验方式是使用 dream 工具启动本地环境。
• 部署到服务器：支持部署到自有的服务器或虚拟机，提供两种方式：
  • 手动部署
  • 使用 Spore Drive 进行自动化部署。
• 视频教程：提供名为“Tau的搭便车指南”的视频系列，包含引导式讲解和演示。

社区与参与

• 保持更新：在GitHub上为项目加星，即可接收新版本发布的通知。
• 贡献：欢迎社区通过修复错误、添加功能、改进文档或指导他人来参与贡献。贡献流程通常是从主分支（main）创建分支，进行更改，测试后提交拉取请求（PR）。新贡献者可以寻找标记为“good first issue”的任务开始参与。

许可证

该项目采用 BSD-3-Clause 许可证。

Windows NT for Power Macintosh 项目摘要

项目目的

本项目旨在为Power Macintosh系统提供运行Windows NT操作系统的支持，通过开发ARC固件及其加载器来实现。

支持的系统

Gossamer架构（MPC106 "Grackle" 内存控制器）

• Power Macintosh G3 (beige)
• PowerBook G3 Series "Wallstreet"/"PDQ"
• iMac G3 (tray-loading)
• Power Macintosh G3 (Blue & White) "Yosemite"
• PowerBook G3 Bronze Keyboard "Lombard"
• Power Macintosh G4 PCI "Yikes!"

Mac99架构（Uni-North/Intrepid 控制器）

• PowerBook G3 Firewire "Pismo"
• iBook G3
• iBook G4（注意：2025年中款iBook G4内部使用USB鼠标，鼠标暂不支持）
• PowerBook G4（注意：2005年初及之后型号使用USB键盘和鼠标，目前不实用支持）

理论支持但未实用系统（缺乏USB驱动）

• iMac G3 (slot-loading)
• iMac G4
• Power Macintosh G4 (AGP "Sawtooth"及后续)

驱动程序和功能

ARC固件中驱动程序

• Cuda和PMU支持
• ADB键盘
• 平面32bpp视频帧缓冲（支持ATI和nVidia硬件，部分nVidia GPU暂不工作）
• Mac I/O内部IDE控制器（从OpenBIOS分支，无PCI IDE驱动）
• ATA-6控制器支持（LBA48未支持）
• MESH SCSI控制器（仅限pre-Mac99系统）
• USB OHCI（从OpenBIOS分支，在pre-Mac99系统中损坏且未工作）

NT系统驱动程序

• HAL for Gossamer芯片组：包括启动帧缓冲、超级I/O中断控制器、Grackle PCI总线、Cuda/PMU（含低层ADB）、串口调试
• HAL for Mac99芯片组：包括启动帧缓冲、MPIC中断控制器、三PCI总线支持、PMU（含低层ADB）、串口调试
• Mac I/O IDE和ATA-6控制器驱动（从NT4 DDK的atapi.sys分支）
• 通用HID/存储驱动（当前仅实现ADB键盘/鼠标和ramdisk作为软驱安装驱动）
• 平面32bpp视频帧缓冲迷你端口驱动

软件兼容性

• 支持NT 3.51 RTM及更高版本
• NT 3.51 beta（构建944及以下）需内核补丁
• NT 3.5不兼容（仅支持PowerPC 601）

安装过程

1. 准备：从发布页面获取系统对应二进制文件；Gossamer/Grackle系统需烧录到光盘（注意区分Old World和New World镜像）；Mac99系统可写入USB驱动器。
2. 分区磁盘：
   • 从启动介质进入ARC固件菜单，选择"Run firmware setup" → "Repartition disk for NT installation"。
   • 设置NT分区大小（最大8030 MB），超过2GB格式化为NTFS；注意早期版本NTFS与NT 3.51不兼容。
   • 可创建额外Mac分区，完成后选择"Finish partitioning and install"。
3. 安装NT：
   • 对于Gossamer系统，确保加载驱动程序ramdisk。
   • 弹出光盘，插入NT 4或NT 3.51光盘。
   • 运行"cd:\ppc\setupldr"启动NT安装程序。
   • 选择硬件：系统类型选择对应HAL（halgoss或halunin）；加载存储驱动（Mac I/O IDE控制器和PowerMac通用HID &存储）；选择视频驱动（Open Firmware Frame Buffer，根据NT版本选择）。
   • 在文本设置中，键盘选择"XT, AT or Enhanced Keyboard"，指向设备选择"No Mouse or Other Pointing Device"。
   • 选择C:分区格式化，完成安装。

已知问题

Gossamer/Grackle系统

• 笔记本系统可能需要移除电池以实现关机。
• 可能发生PMU硬关机，需PMU重置。
• Old World系统启动问题，可按住Esc跳过ARC固件设备。

Mac99系统

• USB驱动未工作，仅支持笔记本系统。
• 当前驱动仅为最小运行需求。

双启动注意事项

• 创建的Mac分区需在OS X 10.1+或OS 9中格式化。
• 存在MBR冲突：OS X安装程序或OS 8/9启动时需从ARC固件菜单选择"Reboot to OSX install or OS8/OS9"；新版本固件已优化，但更新驱动程序分区后仍需此操作。
• 格式化HFS分区时需注意MBR存在。

构建说明

• 需要devkitPPC工具链和powerpcle架构的libgcc.a。
• 设置DEVKITPPC环境变量。
• 构建步骤：编译大端序libc（baselibc），构建ARC加载器（arcloader_grackle或arcloader_unin），编译小端序libc，构建ARC固件本身。
• 替换发布镜像中的stage1.elf和stage2.elf（注意大小限制：stage1.elf ≤16KB，stage2.elf ≤224KB）。
• 重建镜像需创建混合HFS+ISO镜像。

致谢和依赖

• 使用baselibc、libogc、OpenBIOS（IDE和USB驱动适配）、lib9660、Petit FatFs等库。
• ELF加载器和构建文件适自The Homebrew Channel。

Physics-Based Deep Learning Book (v0.3) 摘要

定位与核心：这是一本专注于物理模拟领域中深度学习的实用、全面的指南（版本 v0.3，GenAI 版）。其核心强调实践应用，而不仅仅是理论：每个概念都配有可交互的 Jupyter notebook，让读者能够快速上手。

涵盖范围与方法：书中内容超越了传统的监督学习，深入探讨了：

• 物理损失约束。
• 可微分模拟。
• 用于概率生成式人工智能的基于扩散的方法。
• 强化学习。
• 先进的神经网络架构。

这些基础正在为下一代科学基础模型铺平道路。

v0.3版本新增内容：

1. 生成建模章节：涵盖了去噪、流匹配、自回归学习、物理集成约束和基于扩散的图网络等技术。
2. 神经架构专门章节：专为物理模拟设计。
3. 代码更新：所有代码示例已更新，以利用最新的框架。

核心方法论：书中将按集成紧密程度递增的顺序介绍不同的基于物理的深度学习方法，并讨论各种方法的优缺点及适用场景。

实践特色：

• 可执行代码：专注于 Jupyter notebook，所有代码示例可即时在浏览器中执行。读者可以修改代码并立即查看结果。
• 交互与探索：支持“文字编程”，鼓励读者动手实验。

应用场景示例：

• 使用扩散建模训练神经网络预测机翼周围的流体流动（概率代理模型）。
• 利用模型方程作为残差来训练表示解的网络，并通过可微分模拟改进约束。
• 与完整模拟器更紧密地交互以解决逆问题（例如，利用训练循环中的模拟器来规避标准强化学习的收敛问题）。
• 探讨选择正确网络架构的重要性（全局/局部交互、连续/离散表示、结构化/非结构化图网格）。

项目信息：

• 由慕尼黑工业大学基于物理的模拟小组维护。
• 是一个数字文本和代码示例的集合。
• 鼓励用户通过电子邮件提供反馈和建议。
• 包含一个相关最新研究论文的链接集合。

致谢与引用：

• 项目得到了多位贡献者的帮助。
• 提供了标准的引用格式（BibTeX）。

核心观点： 在管理层眼中，员工是可替代的。文章通过近期科技行业的裁员潮及相关案例，阐述了这一现实。

关键论据与案例：

1. 裁员与公司业绩无关： 即便公司盈利或超出投资者预期，裁员仍会发生。

   • 例如： Shopify在财报超预期后裁员20%。

2. 盈利公司照常裁员： 许多财务状况良好的公司也会进行裁员，而正是被裁员工曾为公司创造了这些利润。

   • 例如： 微软对多个成功游戏开发团队（如贝塞斯达、《光环：无限》团队）进行大规模裁员。

3. 高管薪酬与员工待遇脱节： 公司在裁员、削减员工福利或冻结薪酬的同时，高管却继续获得巨额报酬。

   • 例如： 谷歌在裁员1.2万人并削减福利后，其CEO仍获得2.26亿美元薪酬。
   • 例如： 微软在宣布冻结员工薪酬后，CEO却将其描述为公司的“里程碑之年”。

4. 员工贡献不被看重： 无论员工为公司创造了多少价值、产生了多大影响或服务了多少年，其职位都可能随时被取消。

   • 例如： 一位在通用汽车工作了38年的员工仅通过一封凌晨5点的邮件就被解雇。

5. 高管心态： 部分高管公开表达对员工“可替代性”的看法。

   • 例如： 富豪蒂姆·古纳（Tim Gurner）曾表示，需要“提醒人们，他们是在为雇主工作，而不是相反”，并建议需要提高失业率来纠正员工态度。

结论： 文章总结道，喜欢自己的工作和雇主是正常的，但作为员工，必须清醒地认识到自己在组织眼中是可替代的。这一现象不仅限于科技行业，而是普遍存在于各个领域。

FlashAttention-3 是针对 Transformer 架构中注意力机制计算瓶颈的加速算法，旨在充分利用 NVIDIA Hopper 架构 GPU 的新硬件特性，显著提升计算效率和精度。

核心技术创新

1. 异步计算与操作重叠：利用 Hopper GPU 张量核心与 TMA（张量内存加速器）的异步特性，通过 Warp 专业化 和 “乒乓”调度，将矩阵乘法（GEMM）与 Softmax 等非矩阵操作重叠执行，隐藏延迟。
2. 低精度处理与误差抑制：支持 FP8 低精度计算以获得更高吞吐量（接近 1.2 PFLOPS），并采用 非相干处理（如随机符号哈达玛变换）来“分散”激活值中的异常值，将量化误差降低 2.6 倍，在速度与精度间取得平衡。
3. 硬件新特性利用：充分利用 Hopper 的 WGMMA（高吞吐量张量核心指令）和 TMA（自动处理数据搬运与索引），相比 FlashAttention-2，基础重写即可大幅提升性能。

性能提升

• 速度：相比 FlashAttention-2，在 FP16 精度下实现 1.5-2.0 倍 加速，前向传播可达约 740 TFLOPS。
• 硬件利用率：将 H100 GPU 的理论最大 FLOPS 利用率从约 35% 提升至 75%。
• 低精度潜力：在 FP8 精度下，性能接近 1.2 PFLOPS，同时保持远高于基线的精度。

影响与意义

• 提升 GPU 效率：大幅提高 H100 等高端 GPU 的利用率，加速大语言模型的训练与推理。
• 支持更长上下文：通过加速注意力计算，直接促进了 LLM 上下文长度的扩展（从 2-4K 至 128K 乃至 1M）。
• 成本与能效优化：FP8 支持及更高的吞吐量有助于降低大规模 AI 运算的内存需求和计算成本。

FlashAttention-3 已开源，并计划集成至 PyTorch 未来版本。

谢莉·杜瓦尔逝世

美国女演员谢莉·杜瓦尔于2024年7月11日在得克萨斯州家中去世，享年75岁。其伴侣丹·吉尔罗伊证实，她在睡梦中因糖尿病并发症离世。

杜瓦尔以在斯坦利·库布里克执导的经典恐怖片《闪灵》中饰演杰克·尼科尔森的妻子温迪而闻名，该角色因需要长时间表演恐惧与崩溃而极具挑战性。她亦参演过多部罗伯特·奥特曼导演的作品，包括为其赢得戛纳电影节最佳女演员奖和英国电影学院奖提名的《三女性》，以及《纳什维尔》和《大力水手》。

在1977年的《安妮·霍尔》中，她饰演一位与伍迪·艾伦约会的《滚石》记者，给观众留下深刻印象。她独特的外貌与表演风格——擅长演绎表面快乐实则悲伤、看似浮躁实则深刻的角色——使她成为极具辨识度的演员。

杜瓦尔在1980年代创立了自己的制作公司，并主持了广受欢迎的儿童电视节目《童话剧院》。然而，她的演艺事业在1990年代逐渐减少，于2002年基本淡出银幕。她曾将这种淡出归咎于电影行业的反复无常，称其经历了从备受追捧到被突然抛弃的转变。

2016年，她因在《菲尔博士》节目中表现出健康问题而引发公众关注。其伴侣透露，当时她处于“偏执和妄想”的状态。在淡出20年后，她于2023年的电影《森林小丘》中重返银幕。今年早些时候，她谈及复出时表示“想再次演戏”。

英国《卫报》曾称她为“终极电影明星”，赞誉其表演才华。

CHARMs：一种沉默疾病基因的新型表观遗传编辑工具

本文介绍了由怀特黑德研究所Jonathan Weissman实验室与博德研究所Sonia Vallabh、Eric Minikel实验室合作开发的一种名为CHARMs（Coupled Histone tail for Autoinhibition Release of Methyltransferase）的新型分子工具。该工具旨在通过表观遗传编辑技术沉默致病基因，为朊病毒疾病（如致死性家族性失眠症）及其他神经退行性疾病提供潜在疗法。

研发背景与动机

• 紧迫性：研究者Vallabh本人携带致病性朊蛋白基因，面临必然发病的命运，因此研发具有强烈的个人时间压力。
• 疾病机制：朊病毒疾病由错误折叠的朊蛋白引发，导致蛋白质聚集和神经元死亡。目前无有效疗法。
• 治疗思路：靶向致病基因本身，通过沉默朊蛋白基因从源头阻止有害蛋白产生。

CHARMs的工作原理与技术创新

CHARMs通过在不修改DNA序列的前提下，向目标基因添加甲基化标签来长期、稳定地关闭基因表达。相比传统蛋白质靶向药物，CHARMs可能实现一次性治疗，疗效持久。

为克服早期工具CRISPRoff在尺寸、毒性和递送方面的局限，团队进行了关键创新：

1. 缩小尺寸：用更小的锌指蛋白替代较大的Cas9，使其能被腺相关病毒载体包装，并可能减少免疫反应。
2. 利用细胞自身机制：不再递送外源甲基转移酶，而是通过工程化结构招募细胞自身的DNMT3A，以沉默目标基因，避免毒性并节省载体空间。
3. 提高安全性：引入自毁机制，使CHARMs在完成基因沉默后自行关闭，降低长期表达带来的脱靶风险。

实验进展与协同合作

• 动物测试：在小鼠大脑中，CHARMs能消除超过80%的朊蛋白表达（已知21%的降低即可改善症状）。
• 递送突破：合作团队开发了能高效穿过血脑屏障的AAV载体，利用大脑的铁转运途径，为CHARMs的脑内递送提供可行方案。
• 模块化设计：CHARMs已设计为模块化结构，便于未来针对不同疾病靶点进行快速改造。

未来前景与挑战

CHARMs已从基础研究工具快速演变为有潜力的治疗候选方案，但仍需进一步优化以提高效率、安全性并实现规模化生产，以进入临床试验。团队正持续推进小鼠治疗实验，目标是尽快将这一技术转化为临床可用的疗法，尤其针对Vallabh所面临的朊病毒疾病，以及可能具有类似蛋白质聚集机制的其他神经退行性疾病（如亨廷顿病、帕金森病、ALS和阿尔茨海默病）。

值猜测技巧：超越L1缓存的数据依赖

本文介绍了一种称为“值猜测”的底层优化技巧，通过利用CPU的分支预测器来猜测链表中下一个节点的内存地址，从而打破循环中的数据依赖，提升指令级并行度，最终显著提高遍历连续内存中链表的性能。

背景与问题

现代CPU具备指令级并行处理能力，但数据依赖会限制这种并行性。在遍历链表的循环中，每次迭代都需要等待前一次迭代完成对 node->next 的读取（mov指令），因为下一次迭代的计算（add和mov）依赖于这个地址。即使节点在内存中连续存放且完全命中L1缓存，一次读取操作仍需约4个CPU周期，这使得循环的吞吐量被限制在约1个指令/周期，远低于处理器设计的4指令/周期吞吐量上限。

核心技巧：值猜测与分支预测

由于测试中链表节点在内存中顺序分配，作者提出了一个猜测：下一个节点地址可能就是当前节点地址加一（即内存中的下一个连续位置）。实现方法是在循环中，用猜测的地址（node++）替代通过读取 node->next 获得的真实地址，并通过一个条件分支（if (node != next)）来验证猜测。

• 如果猜测正确：分支预测器会预测该分支不被跳过，从而避免等待真实地址的读取，消除了数据依赖，使CPU能更充分地并行执行循环体内的指令。
• 如果猜测错误（如链表末尾或节点非连续）：CPU会回滚并纠正，但引入约15-20个周期的惩罚。因此，该技巧在链表大部分连续时收益最大。

实现与编译器挑战

文章展示了三个优化版本：

1. sum2：使用内联汇编（asm("" : "+r"(predicted_next));）阻止编译器优化掉看似无用的猜测代码。但此法在GCC下效果不佳。
2. sum3：手动编写汇编代码，将循环体优化至5条指令，并利用逻辑避免了额外的 test 指令，达到了接近最优的指令组合。
3. sum5：最后提供了一个对编译器友好且高效的纯C版本，它通过嵌套循环来实现相同的值猜测逻辑，在GCC和Clang下均能良好工作。

性能结果

在Intel Xeon E5-1650 v3处理器上的测试表明，该技巧带来了显著性能提升：

• 当数据完全在L1缓存中（16kB数据集）：
  • 原始sum1：约14 GB/s，3.91周期/元素。
  • 优化后sum3：提升至约45 GB/s，1.24周期/元素，吞吐量提升超过200%。
• 当数据在L2/L3缓存（128kB/5MB数据集）：吞吐量也有大幅提升。
• 当数据超出所有缓存（~4GB数据集）：瓶颈转移至RAM读取速度，sum3能达到约14-15 GB/s，接近单线程顺序读取RAM的物理极限。

结论

“值猜测”技巧通过打破L1缓存访问引入的数据依赖，极大地提高了特定循环的指令级并行度。虽然它并非普遍适用于所有性能瓶颈，但清晰地揭示了CPU分支预测器和数据依赖交互作用的内部机制，是理解现代处理器微架构的一个优秀范例。

使用 llm.c 复现 GPT-2 (1.6B) 模型总结

本文介绍了使用 llm.c 项目（一个纯 C/CUDA 实现）在单个 8xH100 GPU 节点上，在 24 小时内以约 672 美元的成本复现 OpenAI 的 GPT-2 1.6B 参数模型的过程。这相较于 2019 年需要整个团队的大规模项目，如今在计算硬件（H100 GPU）、软件（CUDA、cuDNN、FlashAttention）和数据集（如 FineWeb-Edu）的进步下成为可能。

项目概述与意义

• 目标：使用 llm.c（约 5000 行 C/CUDA 代码）直接训练完整的 GPT-2（15.58 亿参数），避免 Python、PyTorch 等复杂依赖。
• 成果：模型能够生成连贯文本，质量与 GPT-2 相当。在 HellaSwag 评估上，约在 25K 步时超越原版 GPT-2。
• 局限性：llm.c 尚未完全优化和稳定（偶见损失尖峰），评估不够全面（未仔细评估多语言、代码、数学能力），工作仍在进行中。

训练配置与流程

训练过程简洁高效，主要配置如下：

• 硬件：推荐 8xH100 节点（如 Lambda Labs）。也支持更少 GPU（单 GPU 需约 8 天）或多节点（16 GPU 约 12 小时）。
• 数据集：使用 FineWeb-Edu（约 100B token 的教育网页数据）。
• 关键超参数：
  • 微批大小 (-b 16)，序列长度 (-t 1024)，总批大小 (-d 1048576，约 1M token/步)。
  • 最大学习率 (-l 0.0006)，余弦调度，权重衰减 (-c 0.1)。
  • 总步数 (-x 32000)，处理约 33.6B token。
• 内存优化：可通过调整微批大小、重计算设置 (-r) 等在内存较小的 GPU 上运行。
• 启动命令：提供了从安装依赖、下载数据到编译训练的完整命令序列。

代码特点与优势

llm.c 具有以下优势：

• 轻量高效：仅需基本 CUDA 依赖，代码简洁（C/CUDA），编译快速。
• 内存稳定：训练开始时一次性分配所有 GPU 内存，运行中内存占用恒定。
• 性能优异：模型 FLOPs 利用率 (MFU) 接近 50%。与 PyTorch 实现相比，内存占用减少约 29%，每步迭代速度提升约 19%。
• 确定性与可复现：训练过程是位确定性的，支持断点续训。

模型评估与对比

• 评估：在 FineWeb-Edu 验证集损失和 HellaSwag 准确率上进行跟踪。模型在 HellaSwag 上的表现优于同参数规模的 GPT-2，接近 GPT-3 同规模模型。
• 与 PyTorch 对比：提供了等效的 PyTorch 训练脚本作为参考。llm.c 在内存和速度上更具优势，部分归功于如融合分类器等特定优化。
• 模型导出：训练后的模型可导出为 Hugging Face Transformers 格式，便于使用其生态进行推理和评估。

延伸尝试与挑战

• 更长训练尝试：尝试训练 420B token（超过 GPT-3 同规模模型的 300B），模型在 HellaSwag 上达到约 61% 后变得不稳定。
• 未来方向：包括优化超参数、提高训练稳定性、支持 FP8 训练、添加推理能力（如 KV 缓存）、支持微调（SFT, RLHF）以及集成更多现代架构（如 Llama）。

常见问题

• 推理：目前在 llm.c 中推理效率不高，推荐使用导出的 Hugging Face 模型。
• 聊天：仅为预训练，非聊天模型。
• 硬件支持：目前仅支持 NVIDIA GPU（通过 CUDA），存在活跃的社区分支（如 AMD 支持）。

致谢与资源

• 核心贡献者包括 @ngc92、@ademeure、@gordicaleksa、@rosslwheeler 等。
• 感谢 Lambda Labs、NVIDIA 和 Ubicloud 提供 GPU 和 CI 支持。
• 提供了训练日志、模型权重文件及 Hugging Face 转换版本的链接。

eCapture：无需CA证书捕获Linux SSL/TLS明文

eCapture是一个基于eBPF的工具，可在无需CA证书的情况下捕获SSL/TLS通信明文。

支持范围

• 操作系统：Linux和Android（不支持Windows和macOS）。
• 架构：x86_64（内核4.18+）和aarch64（内核5.5+）。
• 权限要求：需要ROOT权限或特定的Linux capabilities。

核心功能

1. SSL/TLS明文捕获：支持多种加密库，包括OpenSSL、LibreSSL、BoringSSL、Gnutls和NSS/NSPR。
2. GoTLS支持：可捕获使用Go语言TLS库编写的程序的加密通信。
3. 安全审计：
   • Bash/Zsh命令审计：用于主机安全监控。
   • MySQL查询审计：支持MySQL 5.6/5.7/8.0及MariaDB。
   • PostgreSQL查询审计：支持PostgreSQL 10+。

工具模块

eCapture包含8个子命令模块，可通过 ecapture -h 查看。主要模块包括：

• tls：核心模块，用于捕获OpenSSL等库的TLS/SSL明文。
• gotls：捕获Go程序的TLS明文通信。
• bash/zsh：审计终端命令。
• mysqld/postgres：审计数据库查询。
• gnutls/nss：捕获对应库的加密文本。

部署与使用

下载方式

1. ELF二进制文件：下载发行版压缩包，解压后使用 sudo ecapture --help。
2. Docker镜像：

   docker pull gojue/ecapture:latest
   docker run --rm --privileged=true --net=host -v ${HOST_PATH}:${CONTAINER_PATH} gojue/ecapture ARGS
   

   （注意：生产环境建议遵循最小权限原则）

OpenSSL模块捕获模式

tls模块（主要针对OpenSSL）支持三种输出模式：

• pcap/pcapng模式：将捕获的明文数据包保存为pcap-NG文件，可用Wireshark分析。
• keylog/key模式：保存TLS握手密钥到文件，可配合tcpdump/Wireshark实时解密。
• text模式：直接打印或输出明文内容到文件。

示例命令：

# pcap模式，保存数据包
sudo ecapture tls -m pcap -i eth0 --pcapfile=ecapture.pcapng tcp port 443

# keylog模式，保存密钥
sudo ecapture tls -m keylog --keylogfile=openssl_keylog.log

# text模式，直接输出明文
sudo ecapture tls -m text

图形界面：eCaptureQ

eCaptureQ是基于Rust + Tauri + React的跨平台GUI客户端，可视化eBPF捕获能力。支持两种模式：

• 集成模式：在Linux/Android上统一执行。
• 远程模式：Windows/macOS/Linux客户端连接远程eCapture服务。

其他信息

• 安全与运维：包含安全策略、最小权限配置、性能基准测试等文档。
• 编译与配置：支持自定义编译（如设置静态编译OpenSSL的偏移地址），运行后可通过HTTP API动态修改配置。
• 事件转发：支持将事件转发至Burp Suite等抓包软件。
• 协议：使用Protobuf定义日志格式。

Mazeppa：面向按值调用函数式语言的现代超级编译器

Mazeppa 是一个专为按值调用（call-by-value）函数式语言设计的现代超级编译器。超级编译是一种深度程序转换技术，通过符号化执行程序来发现并合成执行模式，从而生成更高效的残差程序。其转换能力涵盖了函数去嵌套（deforestation）和部分求值（partial evaluation），并展现出自动定理证明的某些特性。

核心特性与目标

Mazeppa 旨在成为函数式语言的编译目标，并具备以下关键特性：

• 提供完整的原始数据类型以支持高效计算。
• 通过 GNU C11 编译为原生机器代码。
• 支持手动控制函数展开。
• 转换过程完全透明。
• 从设计之初就注重效率。

安装与使用

安装可通过 opam 包管理器或从源码仓库手动克隆完成。建议使用支持 Flambda 优化的 OCaml 编译器进行构建以获得更好性能。项目提供了一个 playground 脚本，允许在不正式安装的情况下快速试用和可视化转换过程。

超级编译的力量：通过示例理解

Mazeppa 的能力通过一系列示例得以展示，这些示例涵盖了超级编译的核心应用场景：

1. 函数去嵌套（Deforestation）：一个计算列表平方和的程序，原本先通过 mapSq 生成中间列表再由 sum 消费。Mazeppa 将其转换为一个单次遍历的函数 f0，消除了中间内存分配和二次计算。

2. 部分求值（Partial Evaluation）：一个实现快速幂算法的函数 powerSq，当指数是编译期常量时，Mazeppa 能完全消除该递归函数，生成直接表达幂运算的代码，并共享了中间计算结果。

3. 算法合成：这是超级编译超越简单优化能力的体现。

   • KMP算法合成：一个朴素的字符串匹配算法（复杂度 O(|p|*|s|)）被自动转换成了经典的Knuth-Morris-Pratt算法（复杂度 O(|s|)）。这是其他转换技术（如部分求值或去嵌套）在不修改源代码的情况下难以实现的。
   • 元系统转换（Metasystem Transition）：通过超级编译一个基于环境模型的lambda演算归一化器程序，Mazeppa 直接将Church数乘法的求值结果（一个Church数）合成为残差程序，从而“消除”了整个解释器。这体现了超级编译可以折叠任意多层的解释层级。

挑战与控制：@extract 注解

超级编译的强大也带来了不可预测性，例如可能将程序空间指数级膨胀（如处理SAT公式）。为解决此问题，Mazeppa 提供了 @extract 函数注解。当标记了该注解的函数调用出现在复杂的上下文中时，超级编译器会将其“提取”出来单独处理，从而控制优化范围，防止代码和编译时间爆炸。这被视为当前对不可预测性问题的一种实用但非完美的解决方案。

设计决策与技术创新

Mazeppa 采用了一系列精心设计的技术以提高效率和实用性：

• 一阶代码：避免高阶函数带来的复杂开销。
• 惰性构造函数：函数求值保持严格（按值调用），但构造函数不立即求值其参数，从而自然支持去嵌套，同时保持原始程序语义。
• 无项的过程图：转换过程中生成的过程图不包含具体的项，节省内存并使分析更清晰。
• 二维配置分析：同时使用祖先历史和已完全转换节点的历史，兼顾终止保证与代码共享优化。
• 函数生产力分析：在超级编译前分析函数调用的模式，自动决定是在上下文中优化还是提取处理，有效防止无意义的特化爆炸。
• 智能历史与红署名：使用更精细的历史比较和红署名技术，提高终止检查效率并避免过度泛化。
• 优化的同态嵌入：通过缓存机制加速终止检查中计算成本高昂的同态嵌入测试。
• 展开期间的归一化：在函数展开时进行常量折叠和代数简化，减少后续工作量。
• 实现语言：使用 OCaml 实现，结合了函数式和命令式编程风格。

语言、评估与生态

文章详细定义了 Mazeppa 的语法、原始操作符和求值规则（大步环境机器）。它支持作为 OCaml 库被调用，以及将 Mazeppa 程序翻译为 GNU C11 代码，并进一步编译为可执行程序，演示了如何通过 FFI（外部函数接口）与 C 代码交互。

使用建议与总结

文章最后给出了实用建议，如使用 Flambda 优化编译、避免对整个用户程序进行超级编译、注意递归函数的结构递减性以确保终止等。虽然 Mazeppa 尚未达到生产就绪状态，但其结合的多项技术创新使其成为比前辈更具实践潜力的超级编译器替代方案。

使用S3作为容器注册表

本文作者分享了一个发现：可以利用Amazon S3对象存储服务充当容器注册表，实现docker pull操作。其核心原理是docker pull本质上是一系列HTTP请求（HEAD和GET），而S3存储桶配置为静态文件服务后，能够响应这些请求并返回正确的文件与头部信息。

动机与优势

作者团队为追求构建速度，开发了自定义容器镜像构建器。他们发现，将镜像层上传到S3比上传到传统容器注册表如AWS ECR快8倍。基准测试显示，上传198 MiB数据：

• S3：最高吞吐量190 MiB/s（约1秒完成）
• ECR：最高吞吐量28 MiB/s（约7秒完成）

性能差距的主要原因是S3支持并行分块上传，能充分利用带宽；而ECR遵循OCI分发规范，要求顺序上传层块，限制了吞吐量。

工作原理

1. 镜像存储：将容器镜像的清单（manifest）、层（blobs）等文件，按OCI标准路径结构上传至S3存储桶。
2. 访问配置：将S3桶配置为静态网站托管，并确保对各类文件（如清单、层文件）设置正确的Content-Type（通常为application/vnd.docker.distribution.manifest.v2+json或application/octet-stream）。
3. 拉取操作：执行docker pull <S3桶URL>/<镜像名>:<标签>时，Docker引擎会向S3端点发送HTTP请求获取所需文件，从而完成拉取。

示例与演示

作者将一个运行cowsay的镜像镜像到了Cloudflare R2（与S3 API兼容），成功通过docker run从该R2存储桶URL拉取并运行。

局限性与注意事项

• 实验性：此方法处于早期探索阶段，尚未经过生产环境验证。
• 功能缺失：传统容器注册表提供的安全扫描、身份验证、镜像有效性校验、精细权限管理等功能，在此模式下需额外实现或缺失。
• 仅限拉取：该方法仅支持docker pull，不支持标准的docker push。
• 速度优势有前提：S3的高速得益于并行上传；测试显示，若采用顺序上传，其速度与ECR相当。

结论与展望

使用S3作为容器注册表提供了一种极具潜力的高速、低成本的镜像分发方案，特别适用于对拉取速度敏感的场景（如大规模部署、CI/CD流水线）。尽管存在功能上的局限性，但结合如Cloudflare R2等提供免费出口流量的服务，此方法在托管公开镜像方面可能具有吸引力。作者表示将继续研究，并邀请社区反馈。

Korvus：单一查询的 RAG 搜索 SDK

Korvus 是一个开源、高性能的搜索 SDK，其核心是将整个 RAG 流程统一到单一的数据库查询中。它基于 PostgreSQL 构建，并提供 Python、JavaScript 和 Rust 等语言的 SDK。

核心定义

Korvus 是一个面向 PostgreSQL 的一体化 RAG 解决方案。它将 LLM、向量记忆、嵌入生成、重排、摘要和自定义模型等能力整合到一条 SQL 查询中，旨在最大化性能并简化搜索架构。

主要优势与特性

• 原生Postgres RAG：直接在数据库内执行复杂的 RAG 操作，消除了对外部服务的依赖，大幅降低了延迟和架构复杂性。
• 单查询效率：从嵌入生成到文本生成的整个 RAG 流程，均可通过一条 SQL 查询完成，简化架构并提升性能。
• 可扩展性与性能：继承了 PostgreSQL 优秀的可扩展性和性能特性，能够随数据增长而扩展。
• 关键特性包括：简化架构、高性能、开源、多语言支持（Python, JS, Rust）、统一管道、基于强大的 PostgreSQL。

系统架构

Korvus 利用 pgml 和 pgvector 这两个 PostgreSQL 扩展，将整个 RAG 管道压缩到数据库内部运行。

快速开始

1. 前提条件：需要一个安装了 pgml 和 pgvector 扩展的 PostgreSQL 数据库。可选择自托管或使用托管服务。
2. 安装与初始化：
   • 通过 pip install korvus 安装。
   • 设置 KORVUS_DATABASE_URL 环境变量。
   • 初始化一个 Collection 和定义处理管道 Pipeline（例如配置文本分割器和语义搜索模型）。
3. 操作流程：
   • 通过异步函数将管道添加到集合。
   • 向集合中插入文档。
   • 调用 rag() 方法执行 RAG 查询，该查询指定了上下文检索（通过向量搜索）和聊天生成（使用如 Llama-3 等模型）的配置。

SQL 的力量

尽管提供了高级语言 API，Korvus 的核心操作是基于优化的 SQL 查询构建的。这为用户带来了透明性（可审查底层查询）、可定制性（可通过修改 SQL 扩展能力）和高性能（受益于 PostgreSQL 的查询优化）。

资源与社区

Korvus 由 PostgresML 维护，提供官方文档、教程和最佳实践指南。用户可以通过 Discord 和 Twitter 加入社区获取帮助和交流。

GE航空成功研发并测试新型高超声速双模态冲压发动机

核心成就

GE航空（GE Aerospace）宣布成功研发并测试了一款新型高超声速双模态冲压发动机（Dual-Mode Ramjet）。该项目从启动设计到开始测试仅耗时不到11个月，标志着其在高超声速项目组合中取得了最新的重要里程碑。

测试细节与性能突破

• 测试环境：2024年3月，在俄亥俄州Evendale的清洁空气、连续流高速推进测试设施中进行了首次测试。
• 关键性能：测试结果超出预期，发动机运行稳健。与以往经过飞行测试的高超声速技术验证机相比，该新型双模态冲压发动机的气流量（Airflow）提升了三倍。

技术应用与未来规划

• 应用目的：该技术有望使多种多任务飞行器实现高速飞行并具备更远的航程。
• 后续开发：其稳健的性能表现为下一阶段开发铺平了道路。未来将专注于持续的测试与技术验证，以推进集成高速推进解决方案的发展路线图。

研发协作

此次在极短时间内的成功研发，得益于以下三方的紧密合作：

1. GE航空工程师团队
2. Innoveering（GE航空于2022年收购的企业，专精于高超声速推进技术）
3. GE航空研究中心（GE Aerospace’s Research Center）

公司背景

GE航空（NYSE: GE）是全球航空推进、服务和系统的领导者，拥有约44,000台商用和26,000台军用飞机发动机的装机基础。公司拥有52,000名全球员工，致力于通过持续创新定义未来飞行。

Intel 第13和14代CPU缺陷问题总结

核心问题

Alderon Games（《Path of Titans》开发商）指出，Intel第13和14代处理器存在严重的稳定性缺陷，表现为频繁崩溃、系统不稳定和内存/SSD损坏。尽管Intel发布了相关微代码和固件更新，但根本问题未解。测试表明，初期正常的CPU会在3至4个月内逐渐恶化直至失效，故障率接近100%。此外，用户常会收到“显存不足”的误导性错误提示。此问题已引起媒体及Epic Games（Fortnite）、RAD Game Tools等业界的广泛关注。

故障影响领域

该缺陷在以下五个主要领域引发了严重问题：

1. 终端客户：崩溃报告工具记录了数千次玩家端的CPU崩溃事件。
2. 官方游戏服务器：持续崩溃导致整个官方服务器宕机。
3. 开发团队：开发过程中频繁遭遇系统不稳定，甚至引发硬件数据损坏。
4. 服务器提供商：托管社区服务器时出现持续性崩溃。
5. 基准测试工具：与游戏无关的解压缩和内存测试同样宣告失败。

开发商应对措施

为防止游戏生态受到进一步破坏，Alderon Games采取了以下行动：

• 服务器迁移：将所有官方服务器替换为AMD平台，其崩溃率比存在缺陷的Intel CPU低100倍。
• 托管建议：强烈建议游戏服务器托管商避免购买或使用Intel第13和14代CPU。
• 游戏内通知：在游戏内添加弹窗，提醒使用受影响处理器的玩家注意该问题及崩溃的真实原因。

2024年10月更新与售后建议

• 更新局限性：Intel发布的微代码和BIOS更新仅为缓解方案，无法解决根本原因，且受影响的CPU很可能已经发生不可逆的物理损坏。用户仍需确保BIOS更新至最新版本。
• 退换货（RMA）：建议用户将CPU退回Intel申请免费更换或退款。若Intel拒绝合理售后，用户可通过Alderon Games提供的渠道寻求协助并向Intel施压。
• 召回呼吁：开发商呼吁Intel全面召回缺陷CPU并为消费者退款，同时声明发声并非为AMD等竞品背书，旨在向公众澄清游戏崩溃的真实源头。

圆周率计算新世界纪录：超过202万亿位

StorageReview实验室团队成功将圆周率（π）计算到202,112,290,000,000位（超过202万亿位），打破了此前由该团队保持的105万亿位世界纪录。这一成就展示了现代高性能计算与优化硬件平台的卓越能力。

关键技术与硬件配置

• 计算硬件：采用Dell PowerEdge R760服务器，搭载双路Intel Xeon 8592+ CPU与1TB DDR5内存。
• 存储系统：使用28块Solidigm P5336 61.44TB NVMe SSD，总原始存储容量达1.72PB，实际使用中写入数据约82.7PB。
• 软件算法：运行y-cruncher v0.8.3.9532，基于快速收敛的Chudnovsky算法进行计算。
• 计算时间：总计算耗时100.673天（约85天），电源消耗峰值约2.4kW。

计算挑战与优化

• 存储需求：由于大数乘法需要大量临时存储空间，计算位数与所需存储的比例约为1:4.7。例如，计算100万亿位需要约470TB存储空间。
• 性能瓶颈：现代计算中，圆周率计算的主要瓶颈已从CPU算力转向存储I/O性能。此次采用的NVMe SSD阵列通过高聚合带宽满足了大规模数据交换需求。
• 硬件设计：通过定制Dell PowerEdge R760，集成24个NVMe前置槽位与4个后置U.2 SSD槽位，实现了全NVMe本地存储，避免了外部存储设备的性能损耗与故障点。
• 电源管理：28块SSD与双CPU的峰值功耗较高，系统采用2400W电源但曾接近供电极限，建议未来升级至2800W电源。

准确性验证

通过Bailey–Borwein–Plouffe（BBP）公式对结果进行交叉验证。该公式可直接计算π的十六进制特定位数，无需计算所有前置数字。团队进行了多次验证，确保了计算结果的可靠性。

技术意义与启示

• 存储密度突破：在单台2U服务器内实现了1.72PB NVMe存储，体现了高密度存储在降低总拥有成本（TCO）方面的优势。
• 能效与散热：系统在峰值负载下功耗仅2.4kW，远低于传统HPC集群，支持自然风冷，为中小型数据中心提供了可持续的计算方案。
• 应用前景：相关优化技术可用于密码学、科学模拟等计算密集型领域，推动高性能计算的普及化。

致谢

团队感谢Solidigm、Dell Technologies、Intel及y-cruncher开发者Alex Yee的支持。

Floppy8：软驱内的微型计算机

项目概述

Floppy8 是一个将现代微型计算机和卡带系统集成于复古软盘驱动器外壳内的 DIY 硬件项目。作者出于对实体媒体的怀旧情结，购入一款旧软驱，在不破坏原始外壳的前提下掏空内部并重新设计，打造出一台兼具复古美学与现代实用性的桌面设备。

核心功能

• 多媒体与游戏：支持流畅播放 4K 视频及运行复古游戏模拟器。
• 自定义实体卡带：采用类似红白机的卡带设计，插入后标签部分可见。
• 电动弹出与状态指示：前面板按钮可安全卸载并电动弹出卡带；RGB 指示灯实时显示等待、挂载、运行和错误等设备状态。
• 无线控制：配备改装的米色无线 NES 克隆手柄。

硬件设计与结构

• 计算核心：因树莓派性能不足，选用 LattePanda 3 Delta 单板计算机。其内置 Arduino，性能足以应对 4K 播放，且尺寸刚好适配狭小的软驱空间。
• 卡带与读卡器：受限于软驱插槽仅 4mm 的高度，卡带外壳由 3D 打印制成，内嵌 Micro SD 卡并配有定制标签。内部采用极小的 USB-C 读卡器，通过定制短接线连接主板。
• 机械与电子结构：
  • 弹出机制：使用微型舵机结合齿轮实现卡带物理弹出，并通过 0.4A 保险丝保护主板免受电流峰值损害。
  • 散热设计：利用软驱金属外壳作为散热器，配合主板自带风扇即可满足散热需求。
  • 3D 打印支架：使用 Tinkercad 设计了 11 个核心内部支撑部件（如卡带仓、舵机支架、后盖等），历经 200 多次 STL 文件迭代以确保公差与适配。

软件架构

系统控制软件基于 Node.js 开发（通过 firmata 与 Arduino 硬件通信），以处理复杂的硬件事件信号。

• 状态检测：利用 dmesg 读取内核日志，在卡带挂载前即可识别插入动作并更新 LED 状态。
• 自动化逻辑：每个卡带包含 autostart.sh 和 autokill.sh 脚本，实现内容的自动启动，并在按下弹出键时安全或强制终止程序、卸载驱动器并触发物理弹出。

外设与细节打磨

为提升用户体验，作者对无线手柄进行了深度改装：替换了官方十字键，并在内部增加轴承配重以提升质感；使用热缩管处理手柄 LED 漏光问题。此外，重新设计了卡带槽的物理结构以解决原热熔胶固定受热融化的问题，确保卡带插拔的顺滑与稳定。

纪尧姆·勒蒂埃的人生堪称史诗：他生于奴隶家庭，却在法国现代史上最动荡的时期登顶艺术界。如今，一场震撼人心的新展览正在美国率先展出其作品，随后将巡展至卢浮宫。勒蒂埃的故事如此非凡，即使狄更斯或大仲马（后者曾在他葬礼上致悼词）恐怕也会觉得难以置信。

Daminik 简介

Daminik 是一个简单、可扩展的数字资产管理工具，其核心特点是内置了内容分发网络（CDN），旨在成为您所有数字资产的唯一事实来源。

主要特性与优势

• 开源：项目代码在 GitHub 上公开。
• 性能：描述为“闪电般快速”。
• 合规性：符合欧盟《通用数据保护条例》（GDPR）。
• 技术栈：使用 PHP 构建。
• 架构：简单且可扩展。

当前状态

• 托管版本：目前已禁用（不可用）。

其他信息

• 项目链接：代码托管在 GitHub。
• 所属实体：由 Asterios Digital GmbH 开发维护，公司地址位于德国科隆。

文章摘要

本文以星巴克咖啡馆为研究案例，探讨了“第三空间”对社区创业活动的影响。核心研究内容与结论如下：

研究主题 文章研究“第三空间”（即家与工作场所之外的社交聚集地）如何促进社区创业。星巴克咖啡馆作为典型的第三空间，其存在可能通过多种机制影响周边社区的创业活力。

核心发现与机制 研究发现，星巴克咖啡馆的开业与社区内新企业创立率的上升存在关联。其主要作用机制可能包括：

1. 社交网络构建：咖啡馆为居民、创业者和潜在投资者提供了非正式的相遇与交流场所，有助于信息和知识的流动。
2. 降低协调成本：为商业会面、洽谈合作提供了方便的中立场所。
3. 促进思想碰撞：相对轻松的环境可能激发创业想法和创意。

研究意义 该研究为理解城市社区经济活力的微观基础提供了实证依据，表明鼓励发展类似星巴克的第三空间，可能成为促进本地创业和经济发展的一种途径。

局限性 研究主要基于相关性分析，未来需要更深入的工作来严格验证因果机制。此外，星巴克的特定商业模式和品牌效应可能使其影响具有独特性，结论对其他类型第三空间的普适性有待进一步检验。

“古代世界的统治者”测量工具项目总结

项目概述

“古代世界的统治者”（Rulers of the Ancient World）是一个结合计量学、设计与制造的项目，旨在复刻多个古代帝国的标准测量工具。该项目通过结合传统手工技艺与CNC数控铣削技术，重现古代测量系统，让使用者在物理触觉上体验历史，并展示工具制造中的工艺之美。

核心工艺与材质

• 材质选择：注重地理与历史的准确性，选用各文化对应的代表性木材（如硬枫木、火焰枫木、欧洲梧桐木、日本雪松、非洲黑木等）。
• 制作工艺：木材经手工刨平、法式抛光并打蜡。刻度采用高精度CNC雕刻（0.1mm刀头）或传统手工雕刻，随后手工填充印度墨水。

主要产品系列

• 法国 Roubo 系列：包含 Fathom (Toise) 和 Foot (Pied du Roi) 尺。基于18世纪公制前的法国“国王之脚”及 André Roubo 的经典木工著作。Fathom 采用火焰枫木并全手工雕刻；Foot 采用欧洲梧桐木并结合CNC雕刻。
• 古埃及 Cubit 与 Span 尺：基于公元前1500年新王国时期的“肘尺”文物。以“手指”（Djeba）为基础单位，前14个手指包含独特的复杂分数细分，展现了古埃及的数学水平。
• 日本 Kanejaku (Shaku) 尺：基于江户时代及1891年标准化的木匠尺（约303mm）。采用现代数字方案并重新绘制日文汉字，致敬该单位在传统寺庙建筑中的延续。
• 古罗马 Cubitus 尺：基于公元前1世纪左右的罗马测量系统。以“脚”（Pes）为基础，特色在于同时展示了12进制（Uncia）和16进制（Digiti）的双重细分系统。
• 吠陀 Aratni 尺：源自公元前2500年的印度河流域文明。以“手指”（Angula）为基础，采用天城体梵文数字，并包含“握弓”和“拳加拇指”等特色身体测量单位。

限量版套装

限量10套的典藏版包含三款尺子，极致还原历史材质与文化：

1. 罗马 Cubitus：采用古罗马著名的欧洲梧桐木。
2. 日本 Shaku：采用日本雪松（杉木），呼应其在神社寺庙建筑中的应用。
3. 埃及 Span：采用非洲黑木（乌木），重现古埃及法老御用的珍贵木材。

Xata 的 PostgreSQL 免费层具有以下特点：数据库不会因闲置而暂停，无冷启动，持久化存储，且内置高可用性（包含一个写入实例和两个只读副本）。它提供 15 GB 的免费存储，并自动将数据复制到 OpenSearch 集群，从而也提供了免费的搜索功能。

免费层的经济逻辑在于将其视为获取客户的营销成本。免费用户可能发展为付费客户，或通过口碑推广带来价值。关键在于将不活跃数据库的成本最小化，并为转化和推荐提供良好的体验。

Xata 通过共享集群模式实现低成本运营。多个免费数据库被放置在同一个强大的 PostgreSQL 集群（以及配套的 OpenSearch 集群）上。这种方法的主要挑战是“噪声邻居”问题。Xata 通过速率与并发限制、按需垂直扩容以及在不同集群间迁移数据库来应对。迁移过程无需更改连接字符串且几乎无停机时间，使得他们能够隔离噪声数据库并优化集群密度。

成本结构分析：

1. 活跃但使用率低的数据库：一个标准 PostgreSQL + OpenSearch 集群的月成本约为 630 美元。在默认密度下，一个集群可托管约 2000 个数据库，使每个数据库的计算成本降至约 0.32 美元/月。加上其他开销，每个此类数据库的总成本约为 1 至 2.5 美元/月。
2. 不活跃数据库（30 天无访问）：使用专用的、禁用搜索且支持自动扩缩容的集群。一个基础成本约 180 美元/月的集群可托管多达 20,000 个不活跃数据库，使得每个不活跃数据库的成本仅为几美分。当不活跃数据库变得活跃时，系统会自动扩容并将其迁移至活跃集群。
3. 存储成本：免费提供 15 GB 存储，成本最高为 1.5 美元/月，但实际中平均值远低于此。

这种技术架构不仅适用于免费层，也为企业级用例带来了价值，例如：

• 每客户独立数据库：加强租户隔离或地理分布。
• 微服务架构：每个服务拥有独立数据库，可从共享集群轻松迁移至专用集群。
• 开发分支与预览部署：为每个 PR 快速创建轻量级数据库分支。

总结而言，Xata 通过共享集群与数据库动态迁移的结合，在技术上实现了可持续的免费层。与其他方案（如 Supabase 的自动暂停、Neon 的即时扩缩容）相比，Xata 的方式避免了冷启动和暂停，提供了更连贯的免费体验，同时该架构也适用于需要管理大量小规模数据库的生产场景。

文章概述了JFrog安全研究团队发现并报告的一个严重安全事件：一个在公共Docker容器中泄露的GitHub访问令牌，该令牌对Python、PyPI和Python软件基金会（PSF）的GitHub仓库拥有管理员权限。此泄露若被恶意利用，可能引发大规模的软件供应链攻击。

核心发现与过程

• JFrog团队在扫描公共Docker Hub仓库时，通过其秘密检测引擎在一个已编译的Python字节码文件（__pycache__/build.cpython-311.pyc）中发现了泄露的“经典”GitHub个人访问令牌（PAT）。
• 该令牌授予了对python、pypa、psf、pypi等多个GitHub组织下共200余个仓库的管理员访问权限。
• 泄露原因是开发者曾临时在源代码中添加该令牌用于运行脚本，脚本被编译为.pyc文件后，开发者虽从源代码中移除了令牌，但未清理编译生成的二进制文件，并将两者一同推送到Docker镜像中。
• JFrog团队立即向PyPI安全团队报告，后者在17分钟内吊销了令牌，并经调查确认未发现可疑活动。

潜在危害 攻击者若获得该令牌，可进行多种破坏性供应链攻击，例如：

1. 在CPython核心库中注入恶意代码，影响全球数百万台安装Python的机器。
2. 侵入PyPI的Warehouse代码库，篡改热门Python包，植入恶意代码或直接替换合法包。

关键教训与建议

1. 秘密检测需覆盖二进制文件：仅扫描源代码和文本文件不足以防泄露。构建和打包工具生成的二进制产物（如.pyc文件、Docker镜像中的文件）也应纳入秘密扫描范围。
2. 采用新版GitHub令牌格式：建议弃用旧式40字符十六进制令牌，使用以ghp_为前缀、包含校验和的新格式令牌，以便秘密检测工具更准确、轻松地识别。
3. 使用细粒度令牌遵循最小权限原则：应避免使用权限过大的“经典”令牌，而是利用GitHub的细粒度令牌功能，严格限定令牌仅能访问应用程序所需的资源和仓库。

解决方案示例 JFrog的秘密检测引擎因其能够同时扫描文本文件和二进制文件，并涵盖开发（左移）和生产（右移）环境，从而成功发现了此次泄露的令牌。其检测基于不断更新的特定凭据类型列表和通用秘密匹配器，旨在提供全面覆盖。

AWS Secrets Manager Agent 摘要

AWS Secrets Manager Agent 是一个客户端 HTTP 服务，用于在 AWS Lambda、Amazon ECS、Amazon EKS 和 Amazon EC2 等环境中标准化从 AWS Secrets Manager 获取机密的操作。它通过在本地内存中缓存机密，使应用程序能够直接从本地主机（localhost）读取，而非每次都调用远端的 Secrets Manager。

核心特性与功能

• 只读缓存代理：仅支持读取机密，不能修改。通过本地 HTTP 服务器（默认端口 2773）提供机密。
• 工作原理：使用您环境中提供的 AWS 凭证调用 Secrets Manager 获取机密并缓存。缓存会定期刷新（默认 TTL 为 300 秒，可配置），但不支持缓存失效。若机密在缓存有效期内轮换，代理可能返回旧值。
• 安全特性：
  • 内置防服务器端请求伪造（SSRF） 保护，每次请求必须包含有效的 SSRF 令牌。
  • 默认优先使用后量子 ML-KEM 密钥交换。
• 可配置性：通过 TOML 配置文件可调整日志级别、端口、TTL、缓存大小、最大连接数、SSRF 头部名称、最大承担角色数等。
• 可选特性：可编译为包含 FIPS 合规的密码套件。

主要能力

• 强制刷新：通过在请求 URL 中添加 refreshNow=true 参数，可绕过缓存，强制从 Secrets Manager 获取最新机密值并更新缓存。
• 角色链（跨账户访问）：支持通过在请求中指定 roleArn 查询参数，使用 IAM 角色承担来访问其他 AWS 账户或不同权限下的机密。代理会为每个角色 ARN 维护独立的缓存客户端。
• 预取：支持在代理启动时，根据配置的明确机密 ID/ARN 或通过标签发现，将机密预先加载到缓存中，避免首次访问延迟。

部署与使用

1. 构建：需在支持 Rust 的环境中，根据目标系统（RPM、Debian、Windows 或交叉编译）构建二进制文件。
2. 安装：根据计算环境选择不同方式：
   • Amazon EC2：通过安装脚本部署，并配置应用程序用户读取 SSRF 令牌文件。
   • 容器侧车：可与应用程序容器共享网络命名空间运行。
   • AWS Lambda：可打包为 Lambda 扩展层使用。
3. 获取机密：应用程序通过向本地代理端点发送 GET 请求（包含机密 ID 和 SSRF 令牌头）来获取机密。支持 curl 和 Python 示例。

安全与日志

• 安全域：代理的信任域（能访问代理端点和 SSRF 令牌的范围）通常与运行它的主机相同。对于安全要求极高的应用，建议考虑使用 AWS SDK 或专用缓存方案。
• 日志：默认将日志写入本地文件 logs/secrets_manager_agent.log（也支持标准输出）。日志记录本地调用，但代理对 Secrets Manager 的 API 调用会记录在 CloudTrail 中。

集成测试

提供完整的集成测试套件，用于验证缓存、安全、配置、版本管理和错误处理等功能。测试需要具备相应 AWS 权限的凭证和 IAM 角色。

WildGaussians: 3D Gaussian Splatting in the Wild

该论文提出了一种名为WildGaussians的新方法，旨在提升3D高斯溅射（3DGS）技术在处理“野外”场景数据时的性能。传统上，3DGS因其高质量的实时渲染能力而在3D场景重建领域备受关注，但其主要适用于受控良好的场景。当面对现实世界（野外）数据中存在的遮挡、动态物体和光照变化等挑战时，其表现不佳。相比之下，神经辐射场（NeRF）虽能通过为每张图像嵌入向量的方式相对容易地适应此类条件，但3DGS由于其显式表示和缺乏共享参数而难以处理。

为解决这一问题，WildGaussians结合了鲁棒的DINO特征，并在3DGS架构中集成一个外观建模模块。该方法使得3DGS能够有效应对遮挡和外观变化。论文证明，WildGaussians在保持3DGS原有实时渲染速度的同时，在处理野外数据方面取得了优于原始3DGS和NeRF基线方法的先进性能，且整体架构简单。