Secluso：开源私人家庭安防摄像头系统

Secluso 是一个为树莓派（Raspberry Pi）设计的私人家庭安全摄像头系统。它允许用户通过手机观看实时视频、接收警报和打开录像记录，而无需将视频数据交给云服务提供商。

核心特性

• 端到端加密的远程访问：所有视频流和录像均经过端到端加密，确保只有用户本人可以解密和查看。
• 5分钟快速设置：通过其部署工具“Secluso Deploy”，在理想条件下，可在约5分钟内完成系统镜像生成、设备配对和中继设置。
• 完全开源：代码完全公开，允许用户自行审查、自托管或参与贡献。
• 完全可重复的构建：系统发布的运行时二进制文件、部署工具、Android 移动应用和 Secluso OS 均可对照公开源代码进行验证，确保没有未披露的代码或后门。

硬件与软件要求

• 树莓派：需使用 Raspberry Pi Zero 2W。
• 摄像头：兼容 Raspberry Pi Camera Module V1/V2 或任何使用 OV5647 或 IMX219 索尼传感器的摄像头。
• 中继服务器：需要用户自己的 Linux VPS 登录凭证，或可在测试期间通过邮件向项目方申请免费的 beta 版中继托管服务。
• 手机：需要 Android 或 iPhone 用于设备配对、接收警报和回放录像。

快速设置流程（5分钟）

1. 从最新发布版本中下载“Secluso Deploy”工具。
2. 在本地生成个性化的 Secluso OS 镜像和摄像头密钥二维码。
3. 让“Secluso Deploy”通过 SSH 配置您的中继服务器（或申请免费 beta 中继）。
4. 启动树莓派，并在移动应用中完成配对。

详细的硬件选择和 VPS 设置指南可在“Build Your Own Guide”中找到。

移动应用

设置完成后，用户可通过移动端应用进行远程查看、回顾近期事件以及打开加密的视频片段。应用已提供 iOS 和 Android 版本。

安全模型

系统的完整安全模型（包括不可信中继设计、前向保密性和后入侵安全性）详见项目中的 WHITE_PAPER.md 文件。漏洞报告流程见 SECURITY.md 文件。

项目团队与联系

Secluso 由 Secluso, Inc. 开发，联合创始人包括加州大学尔湾分校的计算机安全与隐私专家 Ardalan Amiri Sani 教授，以及开源和隐私爱好者、具备自动化、系统和AI经验的 John Kaczman。

如有其他问题，可通过 secluso@proton.me 联系。

免责声明

• 该项目使用了加密技术，使用前请确认当地法律法规。
• 使用风险自负，项目作者不提供任何隐私或家庭安全方面的保证。

该内容是一个完整的HTML文档，主要包含两大部分：Tailwind CSS核心库的压缩生产代码以及一个简单的页面结构。文档并非关于“Honeycrisp苹果品质下降”的文章正文，而是其所属网页的完整前端代码。

核心总结如下：

1. 内容实质：提供的内容是一个网页的源代码，其中嵌入了庞大的Tailwind CSS工具链代码。尽管HTML标签中存在标题“Honeycrisp apples went from marvel to mediocre”，但在提供的代码片段中并未找到对应的文章正文文本。代码本身是技术性的。

2. 技术结构与目的：

   • 核心库：代码主体是一个高度压缩和混淆的JavaScript实现，构成了Tailwind CSS的核心。这包括CSS-in-JS工具（如postcss）、配置解析器、类名生成器（Te， ur）、值处理器、以及用于扫描源文件以提取使用的工具类的机制（Yo, as）。
   • CSS处理流程：代码实现了完整的CSS处理流程：从输入的Tailwind CSS指令（如@tailwind utilities）开始，通过解析、配置合并、类名匹配与生成，最终输出压缩后的实用程序CSS。
   • 插件与配置系统：包含了定义默认主题（颜色、间距、字体等）、核心插件（yh对象）和变体（se对象）的逻辑。这展示了Tailwind的高度可配置性和扩展性。
   • 构建工具集成：代码中包含与PostCSS、Browserslist等构建工具集成的模块，用于处理浏览器兼容性、CSS转换和优化。
   • 示例页面：代码末尾包含一个使用Tailwind CSS类的简单HTML页面结构（如bg-white, min-h-screen, flex），并内嵌了Inter字体的多个子集@font-face规则。

3. 关键功能：从代码结构可推断，该代码集负责按需生成CSS。它只输出在源代码中实际检测到的实用程序类对应的CSS，从而极大减小最终CSS文件的大小。它支持主题定制、插件、暗黑模式、响应式设计等Tailwind的核心特性。

结论：该内容并非一篇叙述性文章，而是一个技术实现包。其核心是一个功能完整的Tailwind CSS生产环境构建，旨在通过智能扫描和按需生成的方式，高效地为网页提供原子化的CSS utility类。页面标题与代码主体内容不匹配。

OpenWrt One 发布：首款专为 OpenWrt 设计的路由器

核心特点

OpenWrt One 是首款以软件自由和维修权为核心理念设计的无线路由器。它具有永久不锁定和防变砖特性，用户拥有对设备的完全控制权，可自由选择、修改和维修软件。

技术规格

• 价格：含外壳完整套装售价 89 美元
• 合作制造：与 Banana Pi 合作生产
• 处理器：MediaTek MT7981B SoC
• 无线芯片：MT7976C
• 内存：1 GiB DDR4 RAM
• 存储：128 MiB SPI NAND + 4 MiB SPI NOR 闪存
• 网络接口：2.5 GbE 和 1 GbE 两个以太网口
• 扩展接口：USB 主机口、M.2 2042 插槽（支持 NVMe SSD）、mikroBUS 扩展头
• 供电方式：支持通过 2.5 GbE 口供电（PoE）或 USB-C 口 12V USB-PD 供电
• 调试接口：内置 USB 串口接口，方便查看启动信息
• 防变砖设计：通过物理开关可独立刷新 NOR 和 NAND 闪存部分

开源合规与法规认证

该设备从一开始就提供完全符合 copyleft 许可证的源代码。它已通过 FCC 合规测试，证明开源合规性、软件维修权与法规要求可以在同一产品中实现。

销售信息

• 即日起 可通过指定链接和其他销售渠道购买。
• 预计 2024 年 12 月 22 日前 可在大多数国家送达。
• 每售出一台 OpenWrt One，将向 软件自由保护协会 的 OpenWrt 专项基金捐赠 10 美元。

意义

OpenWrt One 展示了硬件设计与制造商优先考虑用户软件维修权的可行性，为家庭网络带来了真正的软件控制自由。

Kyawthuite：全球仅存一颗的稀世矿物

• 极度稀有：Kyawthuite是全球已知最稀有的矿物，迄今为止在全世界范围内仅发现过一个样本。
• 发现与鉴定：该矿物于2010年由宝石学家Kyaw Thu在缅甸的一个市场购得。最初被误认为是钨矿石，经加工后发现异常。随后送至美国宝石学会（GIA）实验室鉴定，确认其化学式为Bi³⁺Sb⁵⁺O₄（铋锑酸盐），这是一种在自然界中从未发现过的矿物组合。
• 物理特性：样本重约0.33克（1.61克拉），尺寸为5.8 x 4.58 x 3毫米。外观呈饱和的橙色，带有红色色调，条痕为白色。其内部含有因剪切应力形成的管状内含物（称为“阶梯状脉”），证实了其天然形成过程。
• 成因推测：地质学家认为它可能起源于火成岩，是常见于发现地区的伟晶岩（一种成分类似花岗岩的火山岩）中的包裹体。其含有的钛、铌、钨和铀等微量元素与伟晶岩形成条件相符。实验室实验表明，铋锑酸盐晶体在岩浆冷却的高温条件下形成，但其如此稀有的具体成因机制尚不明确。
• 价值与保存：目前，Kyawthuite被列为“无价之宝”。作为参照，世界上第二稀有的宝石矿物painite每克拉价值约5万至6万美元。这颗全球唯一的Kyawthuite样本现被安全收藏于洛杉矶县自然历史博物馆。

Ntfs2btrfs 工具总结

核心功能
Ntfs2btrfs 是一款可将 Microsoft 的 NTFS 文件系统原地转换为开源 Btrfs 文件系统的工具，其工作原理类似于 btrfs-convert 对 ext2 的处理。转换后，原始 NTFS 镜像以 reflink 副本保存在 image/ntfs.img，确认无需回滚后可删除以释放空间。

适用系统与用法

• Windows：需以管理员身份运行命令 ntfs2btrfs.exe D:\，不支持转换系统启动盘或含正在使用的页面文件的驱动器。
• Linux：以 root 权限执行 ntfs2btrfs /dev/sda1。
• 注意：若配合 WinBtrfs（Windows 的 Btrfs 驱动）使用，需先清除镜像卷的只读标志方可删除。

安装方式

• Windows：从 Releases 页面下载压缩包或使用 Scoop 安装。
• Linux：支持通过包管理器安装于 Arch、Fedora、Gentoo、Debian、Ubuntu、openSUSE 等发行版，其他系统需自行编译（依赖 libfmt 及可选的压缩库 zlib、lzo、zstd）。

功能支持与限制

• 正常转换：文件、目录、符号链接、安全描述符、备用数据流、DOS 属性及 LXSS 元数据。
• 支持回滚至原始 NTFS 镜像。
• 不支持转换：旧版扩展属性、大于 16KB 的备用数据流、大小写敏感标志、非 4KB 簇大小及加密文件。
• 附加功能：支持 Btrfs 压缩（zlib/lzo/zstd）、多种哈希算法（xxhash/sha256/blake2）及 NTFS 压缩数据处理。

版本更新（摘要）

• 2021年后：增加压缩与哈希算法支持、回滚功能，修复元数据写入顺序、缓冲区溢出等问题。
• 2024-2025年：适配新版 GCC 编译环境。
• 早期：初步支持 NTFS 压缩、WOF 数据，改进错误处理。

相关项目与致谢

• 配套 Windows 驱动 WinBtrfs。
• 感谢 Eric Biggers 对 Windows 10 “WOF 压缩数据”的逆向工程贡献。

编译说明
Windows 下使用 MSVC 编译 CMakeLists.txt；Linux 下通过 cmake 和 make 构建，需安装 libfmt 及压缩库（可选禁用）。

扩展问题
能否从 Btrfs 启动 Windows？理论上可行，但需依赖第三方项目 Quibble 实现。

免责声明
作者提示工具虽已稳定，但使用风险需自行承担。

• 事件背景：电子设计自动化（EDA）社区中出现了一些质疑，认为谷歌提出的AlphaChip芯片设计方法并未达到其在《自然》期刊论文中所声称的效果。
• 官方回应：谷歌AI负责人Jeff Dean与研究员Anna Goldie和Azalia Mirhoseini共同撰写了一份技术回应，旨在澄清这些质疑。
• 核心内容：回应的标题为“That Chip Has Sailed: A Critique of Unfounded Skepticism”（船已启航：对无端质疑的批判），其主旨是针对EDA业界的质疑进行反驳和辩护，以维护AlphaChip研究成果的可信度。

摘要：Bill Franklin 博客网页模板

目的

这是一个HTML网页模板，用于Bill Franklin的个人博客网站。Bill Franklin是一位伦敦的软件工程师，该博客专注于软件开发相关内容。模板定义了网页的基本结构和配置，为动态内容加载提供基础。

结构

• 文档类型：HTML5文档，以<!DOCTYPE html>开头。
• 头部（head）：
  • 设置字符集为UTF-8。
  • 包含网站图标链接（/bill.png）。
  • 配置viewport以实现响应式设计。
  • 定义网页标题为“Bill Franklin”。
  • 添加元描述：“Hi, my name is Bill. I’m a software engineer based in London. This is a blog about software development.”。
  • 支持深色模式：通过CSS媒体查询动态切换背景颜色（浅色模式为#f2f2f2，深色模式为#181818）。
  • 链接外部JavaScript文件（/assets/index-wSF_v8p5.js）和CSS文件（/assets/index-D6wnP8Hu.css）。
• 正文（body）：
  • 仅包含一个id为“app”的div元素，没有静态内容，表明这是一个单页应用（SPA），依赖JavaScript框架动态加载内容。

关键功能

• 动态内容加载：通过外部JavaScript文件（可能基于Vue.js或其他前端框架），实现客户端渲染，正文div作为应用容器。
• 响应式设计：viewport设置确保网页在移动设备上正确显示。
• 深色模式支持：CSS媒体查询自动检测用户系统偏好，并调整背景颜色。
• 资源管理：外部样式和脚本文件引用，便于前端构建和优化。

该模板提供了一个轻量级、可扩展的基础，适用于软件开发博客，支持现代Web应用特性。

根据提供的文章标题“手写而非打字导致大脑广泛连接”，结合神经科学研究的常见方向，可推测该内容可能探讨了手写与打字这两种输入方式对大脑神经网络连接的不同影响。通常此类研究会通过脑成像技术（如fMRI）对比两种活动期间大脑区域的激活与连接模式，可能发现手写能够引发更广泛、更整合的神经连接，而打字则倾向于激活更局部、更机械化的脑区。研究结果可能支持手写在认知发展、学习记忆或大脑可塑性方面的潜在优势。

AMD 禁用 Zen 4 的循环缓冲区

循环缓冲区位于 CPU 前端，用于保存少量先前预取的指令。小型循环可被包含在其中，随后在关闭部分前端阶段的情况下执行，从而节省功耗并可能通过绕过前端限制来提升性能。这是一种古老但流行的技术，曾被 Intel、Arm 和 AMD 的核心使用。

AMD 的 Zen 4 是首个拥有循环缓冲区的高性能核心。其《处理器编程参考》将其与操作缓存和解码器一同列为微操作分发来源。根据性能计数器的实验，在单线程运行时，该缓冲区有 144 个条目；当两个超线程（SMT）活跃时，会被静态分区，每个线程获得 72 个条目。循环内的调用和返回会阻止其被 Zen 4 的循环缓冲区捕获。AMD 的 Zen 4 优化指南未提及此缓冲区，仅建议将热点代码区域保持在操作缓存的容量内。

在 Hot Chips 2024 上与 AMD 员工的讨论表明，该缓冲区主要是一项功耗优化。AMD 从未在其他场合讨论过它，很可能是因为从性能角度看，它并不重要。操作缓存提供的带宽已经超过了核心下游重命名/分配阶段的消费能力。

作者在更新 ASRock B650 PG Lightning 主板 BIOS 至 3.10 版后，硬件性能监控显示前端不再从循环缓冲区派发任何微操作。回退到旧 BIOS 后，该功能重新激活。AMD 在 BIOS 更新（AGESA 1.0.0.6 到 1.2.0.2a）中未经任何公告地禁用了循环缓冲区。

测试显示，禁用循环缓冲区对性能影响甚微。SPEC CPU2017 的整数和浮点套件总分差异小于 1%。SMT 性能增益也未受影响。这符合预期，因为操作缓存的带宽已足够。性能计数器数据表明，即使启用循环缓冲区，它也只输送了少部分微操作；禁用后，操作缓存承担了更大部分的工作。

在 SPEC CPU2017 的浮点套件中，如 544.nab 等测试原本有约四分之一的微操作来自循环缓冲区，但禁用后其得分甚至略有上升。总体而言，禁用循环缓冲区使 Zen 4 从“绝大多数”代码运行在操作缓存上，转变为“压倒性多数”代码运行在操作缓存上。

循环缓冲区的主要目标并非提升性能，而是允许核心适时关闭大部分前端（包括操作缓存）以节省功耗。通过性能计数器的阈值掩码功能，可以估算核心关闭前端的频率。数据显示，在大部分测试中，前端空闲（因后端延迟等原因）的时间比例很高，而循环缓冲区能提供显著节省的机会并不多。

在游戏《赛博朋克2077》的测试中，结果出现矛盾。将游戏运行在配备 3D V-Cache 的 CPU die 上时，禁用循环缓冲区基本无影响；但在非 V-Cache die 上则出现了约 5% 的性能损失，原因不明。性能计数器显示该游戏中循环缓冲区覆盖了约 22% 的指令流，禁用后操作缓存工作负担增加，但平均 IPC（每时钟周期指令数）较低（约 0.89），表明前端带宽并非瓶颈。

关于功耗的测试尝试产生了矛盾且难以解释的结果。使用旧 BIOS 时，从操作缓存和循环缓冲区运行代码的功耗数据似乎不符合预期。作者认为这可能与 AMD 的功耗建模方法或不同 BIOS 版本之间的建模差异有关。由于缺乏物理功耗测量硬件，无法深入探究。

作者推测，AMD 禁用循环缓冲区的可能原因包括：

1. 硬件缺陷：首次在高性能核心实现此功能可能存在验证困难的 bug，AMD 可能出于谨慎而选择禁用。
2. 实验性质：该功能从未被宣传或文档化（仅在《处理器编程参考》中提及一行），影响有限，禁用可能不会引起注意。

结论：AMD 禁用 Zen 4 循环缓冲区是一个有趣的举动，但由于其原始容量低、存在限制（如不支持 CALL/RET 指令），且操作缓存性能充足，对性能和功耗的影响预计很小且难以察觉。AMD 从未提供基于此缓冲区的优化建议，这表明它更像一个低风险、低影响的工程实验。

这篇文章是关于电影《攻壳机动队》中的地图用户界面（UI）设计信息。其核心内容包括：

• 作品性质：这是为《攻壳机动队》电影所设计的“地图UI”（用户界面）。
• 版权归属：该设计涉及多方版权持有者，明确列出了士郎正宗、讲谈社，以及Bandai Visual和Manga Entertainment。
• 定位：这是一个与《攻壳机动队》这一特定作品（推测为电影）相关的、具体的视觉设计组件。

文章标题： 《统计学》（弗里德曼、皮萨尼与珀维斯著，2017年）书评

内容概述： 提供的文本片段主要是一个网站页面的框架与导航元素，而非书评的具体内容。页面显示了网站名称“cadlag dot org”，主导航菜单（Home, Blog, Tags, RSS）以及一个设计元素（一个颜文字表情符号）。实际的书评正文并未在此次提供的文本中出现。

因此，基于现有信息，无法对《统计学》一书的书评内容进行总结。仅能确认该片段指向一个博客或个人网站页面，其主题或某篇博文可能与对该教材的评论相关。

Oscilloscope Music: N-Spheres EP 摘要

《N-Spheres》是 Oscilloscope Music 项目历时六年（自2018年宣布）打磨完成的新 EP。Oscilloscope Music 的核心概念是使用同一音频信号同时驱动扬声器发声和模拟示波器绘制绿色线条图形，左右声道分别对应图像的水平和垂直轴。通过精心设计的参数函数，创造出视听同步的几何图形，风格兼具复古实验室美感与未来感。其难点在于确保生成的图像悦耳动听，反之亦然，这需要创新的声音合成与混音母带处理方法。

如果说首张专辑《Oscilloscope Music》是概念验证，那么《N-Spheres》则是该概念的目的地与升华。EP 名称“N-sphere”指代 n 维空间中的球面推广。本作品声音更粗粝、直接，更具舞池感，且复杂性达到了全新高度。EP 包含5首曲目（Function、Intersect、Attractor、Flux、Core），总时长约30分钟。

限量实体版与技术特点 EP 推出了限量500套编号的 3.5英寸软盘 实体版（售价40欧元），附带丝网印刷封套和24页小册子。软盘内除了音视频文件，还包含实时可执行程序及代码片段。选择软盘作为载体，是因为 Oscilloscope Music 基于参数函数驱动，生成音频和视频的程序文件极小（例如曲目 Function 仅约41KB），足以将适用于 Windows/macOS 的完整可执行文件存放在1.44MB的软盘中。软盘盒采用矢量机器绘图艺术品制作。

购买与交付 购买实体版或下载版（10欧元）后，用户可立即下载首支单曲《Function》的4K/1080p 50fps 视频、高质量音频及测试版可执行文件。完整 EP 的下载码将通过邮件后续发送。实体订单将在一周内发货。

配套软件更新 与 EP 同步开发的新版软件 OsciStudio 7 引入了多项功能增强，包括大幅改进的时间线与剪辑功能、支持更复杂操作的实时编程示例、撤销/重做功能、改进的渲染能力，以及对 WickedLasers 投影仪的内置支持。

DynaSaur: 超越预定义动作的大型语言模型智能体

核心问题

现有的基于大语言模型（LLM）的智能体系统通常在每个步骤中从固定的预定义动作集合中进行选择。这种方法在封闭、范围狭窄的环境中有效，但在真实世界的开放式场景中面临两大挑战：

1. 能力受限：显著限制了LLM智能体的规划和执行能力。
2. 构建成本高：需要大量人力来枚举和实现所有可能的动作，在具有大量潜在动作的复杂环境中不切实际。

解决方案

为应对上述局限，本文提出了一个名为 DynaSaur 的LLM智能体框架，其核心思想是让智能体能够动态地创建和组合所需动作。

• 交互机制：该框架通过生成并执行通用编程语言编写的程序来与环境进行交互。
• 动作累积：动态生成的动作会随着时间的推移被累积起来，以供未来重用，从而构建一个不断增长的动作库。

实验与结果

在多个基准测试上的大量实验表明，该框架：

• 显著提升了灵活性，优于依赖固定动作集的先前方法。
• 具备适应与恢复能力：能够在预定义动作不足或因未预见边缘情况而失效的场景中，使LLM智能体能够自适应地处理问题。

资源与提交信息

• 代码：项目代码已公开。
• 论文提交历史：最新的更新版本（v3）提交于2025年9月4日。

OrioleDB beta7 版本基准测试总结

OrioleDB 简介

OrioleDB 是一个为 PostgreSQL 设计的存储扩展，利用了 PostgreSQL 的可插拔存储系统。它旨在作为现有 Heap 存储的直接替代品，以克服可扩展性瓶颈并充分利用现代硬件能力。通过与 PostgreSQL 无缝集成，它在保持 PostgreSQL 固有的健壮性和可靠性的同时，提供了更高的性能、效率和可扩展性。

beta7 版本发布

OrioleDB beta7 版本的发布，标志着其在为 Postgres 用户提供高性能、下一代存储引擎的道路上迈出了重要一步。该版本专为挖掘现代硬件潜力而设计。

核心设计选择

OrioleDB 的设计从零开始，旨在利用现代硬件、减少维护需求并增强分布式能力。关键的技术决策包括：

• 消除缓冲区映射与无锁页读取：内存页直接链接到存储页，消除了缓冲区映射及其瓶颈。内存页读取无需原子操作，实现了无锁访问，显著提升了 PostgreSQL 的垂直可扩展性。
• 基于 UNDO 日志的多版本并发控制：采用基于 UNDO 日志的 MVCC 机制。旧版本的元组被驱逐到 UNDO 日志中（形成 UNDO 链），而非在主存储中造成膨胀。页级 UNDO 记录允许系统快速回收已删除元组占用的空间。结合页合并机制，可在大多数情况下消除膨胀，从而无需对表进行专门的 VACUUM，移除了常见的性能下降和数据库中断根源。
• 写时复制检查点与行级 WAL：利用写时复制检查点，始终提供结构一致的数据快照。这种方法对现代 SSD 友好，并支持行级预写式日志。行级 WAL 易于并行化（已实现）、紧凑，且适用于计划中的主动-主动多主配置。

基准测试：OrioleDB 与 PostgreSQL Heap 对比

为展示 OrioleDB 的性能特点，我们使用了模拟真实数据库工作负载的 TPC-C 基准测试。

• 100 个仓库：主要凸显了 WAL 插入瓶颈。OrioleDB 测试速度比 Heap 快 2.3 倍。（测试于 64 核虚拟机 c7g.metal，分配 20GB 内存作为共享缓冲区）
• 500 个仓库：主要凸显了共享内存缓存瓶颈。OrioleDB 测试速度比 Heap 快 5.5 倍。（测试硬件同上）
• 1000 个仓库：OrioleDB 实现了索引组织表，在数据不适应操作系统内存缓存时，相比 PostgreSQL 默认的堆组织表提供了更好的数据局部性，通过减少磁盘 I/O 提高了吞吐量。OrioleDB 测试速度比 Heap 快 2.7 倍。（测试于 64 核虚拟机 c7gd.metal，分配 20GB 内存作为共享缓冲区）

其他优化

其他重要的 OrioleDB 改进（未在本次基准测试中涵盖）包括：

• 内置压缩，在典型情况下可将存储空间占用减少高达 5 倍。
• UNDO 日志避免了膨胀，消除了 VACUUM 需求。
• 消除了子事务风险。

如何尝试

• 安装：可通过 GitHub 源码构建、使用 Docker 或在 Supabase 平台（公开 Alpha 版本）上运行。
• 使用：在建表语句中添加 USING orioledb，或设置 default_table_access_method = 'orioledb' 将其设为默认存储引擎。
• 测试：欢迎使用您自己的工作负载或知名基准测试工具（如 go-tpc、HammerDB）进行测试。

未来愿景

• 成为 PostgreSQL 的默认存储引擎。
• 通过 S3 集成实现存储与计算解耦的“无底”存储。
• 保持完全开源和 PostgreSQL 许可证，提供快速、无服务器、可自托管且纯正的 Postgres 引擎。
• 引入列式索引，以支持混合 OLTP/OLAP 工作负载。
• 支持多主复制，以增强可用性和容错性。

当前限制 (beta7)

• 仅支持 B-tree 索引，尚不支持其他索引类型（如 pg_vector 的 HNSW 索引）。
• 涉及 OrioleDB 表的事务不支持准备事务。
• 不支持对 OrioleDB 表的索引使用 REINDEX CONCURRENTLY。 （这些限制计划在 2025 年 GA 发布前完成解决）

参与社区

团队邀请用户试用 OrioleDB，并通过 GitHub Issues 和 Discussions 分享体验与期望。同时欢迎 PostgreSQL 提供商联系合作，成为设计合作伙伴。

本文从传输协议（特别是TCP）的角度分析了Starlink卫星互联网服务的特性。文章首先对比了地球同步卫星（GEO）与低地球轨道卫星（LEO，如Starlink）系统。GEO卫星轨道高（约35,786公里），导致高延迟（往返时间约660毫秒），对TCP的反馈机制和缓冲区管理带来挑战。而LEO卫星轨道低（Starlink约550公里），显著降低了基础传输延迟（最低约3.7毫秒），但引入了新的复杂性。

Starlink服务为TCP协议带来了四大主要挑战：

1. 变化的信道容量：由于卫星相对地面高速移动（约27,000公里/小时），用户终端与卫星的信号强度和质量（信噪比SNR）持续波动。服务通过动态调整信号调制编码方案来适应SNR变化，导致链路容量实时变化。
2. 变化的延迟与抖动：卫星的移动和切换导致延迟和抖动水平很高。用户终端每约15秒切换一次卫星，每次切换都可能伴随延迟跳变（例如从30毫秒升至80毫秒）和丢包。
3. 卫星切换导致的丢包：定期卫星切换是丢包的一个主要原因，这种丢包通常与网络拥塞无关。
4. 共享介质的争用：Starlink是共享无线介质，与其他用户竞争时隙资源，也会引起性能波动。

这些特性违背了传统TCP控制算法（如Reno、CUBIC）所依赖的几个关键假设：稳定的路径容量、低抖动、以及将丢包主要归因于网络缓冲区溢出的拥塞。因此，传统TCP在Starlink环境下可能表现保守或效率低下，例如CUBIC协议在高峰期平均吞吐量仅约45Mbps，远低于链路峰值容量。

文章测试了两种主要的TCP拥塞控制算法：

• CUBIC：这是一种基于丢包的算法。在Starlink环境下，它倾向于保守地降低发送速率以响应非拥塞性丢包，因此在高峰期性能受到较大限制，但其公平性较好。
• BBR：这是一种基于拥塞（检测队列形成）而非丢包的算法。它通过主动探测来估算链路带宽和最小RTT，并试图维持在队列开始形成的临界点上。测试显示，BBR在Starlink环境下表现优异，平均吞吐量可达200Mbps以上，因为它能更好地容忍周期性延迟跳变和随机丢包，维持较高的发送速率。这主要是因为BBR在探测时使用最小RTT值，而Starlink在每个卫星跟踪周期内的最小RTT相对稳定。

结论与展望： 较新的TCP协议（如CUBIC）凭借选择性确认（SACK）等特性，比传统协议更能适应Starlink。然而，最有效的似乎是像BBR这样旨在探测队列形成而非单纯应对丢包的协议。未来优化方向可能包括：

1. 针对Starlink的15秒卫星切换周期调整BBR（或CUBIC）的探测时机，避免在切换期间进行激进的速率调整。
2. 使用显式拥塞通知（ECN）。如果在Starlink的路由设备上启用ECN，它可以为终端提供明确的网络拥塞信号，从而区分真正的队列形成与卫星切换等事件引起的延迟变化和丢包，实现更精准的拥塞控制。

摘要：递归诅咒——在生成数据上训练导致模型遗忘

核心问题：随着大型语言模型（如GPT系列）的普及，网络上模型生成的内容将日益增多。本文探讨了未来当模型训练数据大量源自模型自身生成的内容时会发生什么。

关键发现：

• 模型崩溃现象：使用模型生成的内容作为训练数据，会导致后续模型产生不可逆的缺陷，表现为原始数据分布的“尾部”信息逐渐消失。这一现象被作者称为模型崩溃。
• 普遍性：模型崩溃并非局限于某一类模型。研究证实，它在变分自编码器、高斯混合模型和大型语言模型中均会发生，表明这是所有学习型生成模型的一个普遍挑战。
• 理论与现实意义：论文构建了该现象背后的理论直觉，并指出其对当前依赖大规模网络爬取数据训练的范式构成了严重威胁。要维持从网络数据中训练的益处，必须认真对待此问题。

重要启示：

• 在充斥着LLM生成内容的互联网数据中，来源于真实人类交互的数据价值将急剧上升。这些数据对于避免模型崩溃、维持模型多样性和保真度至关重要。

结论：递归地使用模型生成数据进行训练存在根本风险，可能导致模型性能退化并丧失对真实世界数据的覆盖。未来模型训练需更加审慎地评估数据来源，优先保障数据中包含足够比例的真实人类生成内容。