Vision Pro: 苹果做对了什么，而Oculus做错了？

核心观点： 尽管存在明显的缺陷，苹果Vision Pro作为VR/AR行业的“北极星”产品，通过其强大的品牌和设计能力，成功将空间计算推向了主流视野，并为Meta等竞争对手设定了新的体验标准。

Vision Pro的即时魔力与优势

1. 无与伦比的“临场感”：通过高保真、低延迟的透视技术，Vision Pro让用户能清晰地看到现实世界（甚至手机屏幕），这是前所未有的体验，极大增强了与现实世界的连接感。
2. 革命性的交互范式：凝视与捏合：精准的眼动追踪与手势识别相结合，创造了如同“激光眼”般直觉化的UI操控能力。作者认为这是自iPhone多点触控以来最重要的交互革命，将成为行业事实标准。

硬件设计：一款精心过度设计的“开发套件”

• 传感器过多：Vision Pro搭载了远超必要的传感器（14个），这是典型的第一代产品策略，旨在确保体验稳定并探索开发者潜能，但也导致重量超过600克，佩戴舒适度差。
• 战略意义：苹果选择优先保证体验和设计的完整性，牺牲了舒适性。这款设备本质上是一个激发市场好奇、为开发者铺路的“开发套件”，为未来更主流的产品迭代奠基。

显示技术：设定新标准的妥协

• Micro-OLED的突破：Vision Pro首次在VR头显中实现了接近无纱窗效应的超高分辨率显示，像素密度远超现有设备，这是其存在和上市的关键。
• 有意为之的模糊：为掩盖残余的像素化并提升图形平滑度，苹果故意使显示略微失焦。这与Quest 3追求锐利的策略截然不同，体现了苹果独特的“品味”。

软件与内容：大胆反VR的定位及其局限

• 反VR立场：苹果将Vision Pro定位为“空间计算”，强调与现实的连接，有意忽略VR的沉浸式游戏内容，与Meta形成对立。
• 乏味的启动阵容：缺乏令人兴奋的AR应用和3D游戏，导致发布时的软件故事主要围绕将2D iPad应用和Mac作为虚拟大屏使用，被作者批评为“乏味且缺乏想象力”。
• 观影体验：虽然画质出色，但长期来看，VR并非观看2D影视的主流媒介，舒适度、启动摩擦和社交隔离问题将限制其使用。

未来潜力与转变性应用

• 沉浸式视频：苹果的“苹果沉浸式视频”格式（8K，180度，3D）提供了惊人的临场感，但超高写实度可能带来“恐怖谷”挑战。
• 现场体育直播：这被视为苹果的“秘密武器”。结合其广播技术（收购NextVR）和已有的体育版权（如MLS），苹果有望彻底重塑体育观赛体验，为硬核粉丝提供“场边座位”般的沉浸感，但需要巨大投入和社交功能创新。

Meta的机遇与策略建议

苹果Vision Pro的发布对Meta是绝佳的营销推动：它提升了VR的公众认知，设定了新的体验基准，并为Meta提供了定价空间和内部追赶动力。 作者为Meta Quest Pro 2提出建议：

1. 采用Micro-OLED显示，追赶Vision Pro的分辨率。
2. 重点解决舒适性，目标是连续佩戴2-4小时。
3. 透视质量必须全面超越Vision Pro，消除运动模糊等问题。
4. 将凝视与捏合交互提升到新水平，利用Meta在手势追踪上的研究成果。
5. 与微软合作，使Windows PC成为头显的一等公民。
6. 推出高度写实的Codec Avatars技术，用于化身。

结论：作者因高价格、舒适性、软件不成熟等原因退回了Vision Pro，但他认为这是VR/AR行业发展的重要催化剂。未来竞争的焦点将在于谁能率先解决舒适性、显示质量、交互革命以及杀手级应用（尤其是生产力与体育直播）等核心挑战。

事件摘要

• 核心声明：波音公司举报人约翰·巴尼特（又名米奇）的家族好友珍妮弗声称，巴尼特在去世前曾预感自己可能会死，并明确告诉她：“如果我出事了，那绝不是自杀。”
• 朋友立场：珍妮弗坚信巴尼特并非自杀，认为他“太热爱生活与家庭”，不可能自行了断。她推测可能有人因不满巴尼特的揭露而试图“让他闭嘴”，并将死亡伪装成自杀。
• 背景信息：巴尼特是波音公司任职30多年的质量经理，退休后搬回路易斯安那州照顾母亲。他此前对波音提出投诉，指控公司因他揭露不安全操作而对其进行报复。
• 死亡情境：巴尼特在查尔斯顿进行法律证词期间身亡。查尔斯顿县验尸官办公室已确认其死亡，但具体细节未公开。
• 案件进展：尽管巴尼特去世，其律师表示原定于6月的审判仍将继续推进。
• 波音回应：波音公司对巴尼特的去世表示哀悼，并向其家人朋友致以慰问。

Figma数据库扩展之路

自2020年以来，Figma的数据库规模增长了近100倍，这对技术架构提出了巨大挑战。最初，团队采用垂直分区作为快速且影响重大的扩展手段，将相关表分组到独立的数据库实例中（如“Figma文件”或“组织”相关表），从而获得了关键的喘息空间，并保持了领先于业务增长的余地。

然而，垂直分区有其局限性。随着数据量激增，某些表达到数TB和数十亿行的规模，导致PostgreSQL的清理（vacuum）操作影响可靠性，且高写入表的IOPS即将超出亚马逊RDS的限制。垂直分区以单表为最小单位，无法解决这些表级别的瓶颈。因此，团队需要更强大的解决方案——水平分片。

水平分片的目标与权衡 为应对挑战并支持长期增长，团队设定了明确目标：

1. 最小化开发者影响：尽量处理复杂的关联数据模型，让应用开发者专注于功能开发。
2. 透明化扩展：一次适配后，未来的物理扩片应对应用层透明。
3. 避免昂贵回填：鉴于表的大小，回填方案将耗时数月，不可接受。
4. 渐进式推进：增量 rollout，降低大规模故障风险，并在迁移过程中维护可靠性。
5. 避免不可逆迁移：保留回滚能力，以应对未知问题。
6. 保持强一致性：避免复杂的双写等方案，力求接近零停机时间。
7. 发挥现有优势：基于团队在RDS PostgreSQL上积累的专长和现有架构。

方案评估与自建决策 团队评估了CockroachDB、TiDB、Spanner和Vitess等分布式数据库方案，以及NoSQL数据库。但考虑到：

• 迁移新存储层的风险和重建领域知识的成本。
• 极其紧张的时间表（仅剩数月余量）。
• Figma复杂的关联数据模型不适合NoSQL。

团队决定在现有垂直分区的RDS PostgreSQL基础设施上构建水平分片解决方案。此举旨在利用现有技术栈，提供一个功能集更小、针对Figma特定架构优化的分片方案（例如，选择不支持原子跨分片事务，通过业务逻辑规避）。

独特的水平分片方法

1. 分片键与协同定位（Colos）：没有使用统一的复合分片键，而是为表选择了UserID、FileID或OrgID等少数几个键。相关表根据相同的分片键和物理布局组成“协同定位”组（Colos），简化了开发者的交互（组内支持跨表连接和完整事务）。
2. 逻辑与物理分片分离：
   • 逻辑分片：首先通过PostgreSQL视图实现。为每个逻辑分片创建一个视图，通过哈希范围过滤数据。在未物理分片的单个数据库上，应用层如同操作分片数据库。此阶段风险低，可通过特性标志逐步推出或秒级回滚。
   • 物理分片：在逻辑分片验证无误后，执行真正的物理数据分割和流量切换。将数据从一个数据库分发到N个数据库，并重新路由读写。
3. DBProxy查询引擎：构建了一个新的Go服务DBProxy，位于应用层和PGBouncer之间。其核心是一个轻量级查询引擎，负责解析SQL、提取分片键（逻辑规划）、将逻辑分片映射到物理数据库（物理规划），并重写/路由查询。它能处理单分片查询，并尽量将复杂查询“下推”到PostgreSQL；对于缺失分片键的查询，会执行“扇出-聚合”（scatter-gather），但会限制此类查询以保持性能。
4. 拓扑管理：构建了动态数据库拓扑库，实时映射表、分片键、逻辑分片和物理数据库的关系，能在一秒内更新状态，支持分片拆分等操作，并在非生产环境使用更少的物理数据库以节省成本。
5. 数据分布：为避免自增或雪花ID导致的热点，使用分片键的哈希值进行路由，确保数据均匀分布。

进展与未来 首个水平分片的表于2023年9月上线，过程顺利，仅主数据库有约10秒的部分可用性影响，无延迟或可用性回退。团队正在逐步分片高写入率的简单表。

未来计划包括：

• 支持水平分片的模式更新。
• 全局唯一ID生成。
• 关键业务场景的原子跨分片事务。
• 分布式全局唯一索引。
• 与分片无缝兼容的ORM模型。
• 全自动化的扩片操作。

团队将继续在自研RDS水平分片方案与评估成熟的开源或托管解决方案（如NewSQL数据库）之间权衡，以寻求最佳长期路径。

从900个最热门开源AI工具中学到的洞见

数据收集与范围

• 在GitHub上使用gpt、llm、generative ai等关键词搜索，筛选出896个至少拥有500星的仓库，其中845个是软件仓库（另有51个教程或列表）。
• 分析聚焦于基础模型（foundation model）生态栈，揭示了AI开发工具的现状与协作趋势。

AI技术栈三层结构

作者将AI栈分为三个核心层：

1. 基础设施层

• 包括模型服务（如vllm、Triton）、计算管理（如Skypilot）、向量搜索与数据库（如FAISS、Milvus）。
• 该层在2023年增长相对平缓，部分原因可能是基础设施产品较少开源。

2. 模型开发层

• 涉及模型构建与训练框架（如Transformers、PyTorch、DeepSpeed）、推理优化（如GGML）、数据集工程、评估等。
• 2023年重点在推理优化（如2-bit量化）和评估方法创新（如AI-as-a-judge）。

3. 应用开发层（AI工程）

• 2023年增长最快的领域，涵盖：
  • 提示工程：包括结构化输出、长期记忆管理等。
  • AI接口：如网页/桌面应用、浏览器扩展、聊天机器人（Slack、WhatsApp等）、插件（VSCode、Office）。
  • AI工程框架：多数围绕RAG，支持监控与评估。
  • 智能体（Agent）：结合提示工程、约束生成与工具集成。

其他分类

• 模型仓库：由公司或研究者发布的官方模型代码（如Stable Diffusion、LLaMA）。
• 应用：基于现有模型构建的程序，热门类型包括编码辅助、工作流自动化、信息聚合。

开发者生态与趋势

• 幂律分布：少数账号贡献大量仓库。前20个账号（多为组织）托管了23% 的仓库（195个），累计165万星。
• 个人开发者作用凸显：
  • 基础设施层多由组织构建，而超过一半的应用由个人发起。
  • 个人发起的应用平均获得更多星标，预示“一人公司”潜力。
• 中国开源生态崛起：
  • GitHub上存在大量面向中文用户的AI仓库（如Qwen、ChatGLM3）。
  • 前20账号中6个源于中国（如清华KEG、阿里QwenLM、上海AI实验室）。
  • 工具链适配微信、钉钉等本地平台。

发展趋势与观察

• 2023年爆发后趋于平缓：2023年工具数量激增，但2023年9月后增长曲线变平，可能因低垂果实已被摘取、行业热情减退。
• 仓库生命周期：部分项目快速崛起又快速衰落（18.8%仓库过去24小时无新增星标）。
• 协作规模：超过2万名开发者为845个仓库贡献了近100万次提交。

作者推荐的有趣方向

• 批处理推理优化（如FlexGen、llama.cpp）
• 快速解码技术（如Medusa、Lookahead Decoding）
• 模型合并工具（如mergekit）
• 约束采样工具（如outlines、SGLang）
• 专用高效工具（如einops、safetensors）

总结

开源AI生态在2023年后进入应用驱动阶段，中国贡献显著增长。虽然部分领域热度减缓，但工具链持续演进，个人开发者与小团队在应用创新中扮演关键角色。

美国联邦通信委员会（FCC）正式投票决定，将最低宽带速度标准从每秒25兆比特（Mbps）下载速度、3Mbps上传速度，提高至100Mbps下载速度、20Mbps上传速度。这一决定以3比2的投票结果通过。

此次调整旨在更准确地识别全国范围内哪些地区缺乏足够的互联网服务，尤其是低收入社区和农村地区，并有助于确定是否需要更多政府资金投入。FCC主席Jessica Rosenworcel称此举“姗姗来迟”，并指出仍有许多社区缺乏所需宽带服务。根据2022年12月的数据，约有4500万美国人无法获得100/20Mbps的固定服务或35/3Mbps的移动5G-NR服务。

此外，FCC还设定了长期目标，计划未来将标准进一步提升至1000Mbps下载速度、500Mbps上传速度。

然而，两位共和党委员投了反对票。委员Brendan Carr和Nathan Simington主要针对卫星互联网服务（尤其是SpaceX的Starlink）的排除标准提出异议。他们认为Starlink已能提供高速互联网，尤其在农村地区，速度接近或超过新标准，应允许其平等竞争联邦补贴。此前，SpaceX曾因未能获得8.86亿美元联邦资金以扩大农村Starlink覆盖而上诉失败。

Go 执行追踪功能增强

Go 运行时的 runtime/trace 包是一个强大的工具，用于理解和调试 Go 程序。它能够生成每个协程在一段时间内的执行轨迹，随后可通过 go tool trace 或第三方工具（如 gotraceui）进行可视化分析。执行轨迹的优势在于能清晰揭示其他分析方法难以发现的问题，例如多个协程在同一个通道上阻塞的并发瓶颈。

Go 开发者还可以通过任务（Tasks）、区域（Regions）和日志（Logs）来检测自己的程序，从而将高层关注点与底层执行细节关联起来。

历史问题

然而，历史上使用执行轨迹存在四个主要问题：

1. 开销高：运行时开销通常在 10–20% CPU，限制了其只能用于特定场景，无法像 CPU 分析那样持续使用。
2. 不具扩展性：轨迹文件可能变得过大，难以分析。几百 MiB 的轨迹可能需要数 GiB 的内存来分析。
3. 难以捕获特定问题：通常不清楚应在何时开始追踪以捕获特定的异常行为。
4. 缺乏公共解析工具：没有用于解析和解释执行轨迹的公开包，导致编程分析门槛很高。

主要改进（Go 1.21 和 1.22）

在最近的两个 Go 版本中，以上问题取得了重大进展。

1. 低开销追踪

通过对栈追踪效率的优化，执行轨迹的运行时 CPU 开销已大幅降低，对于许多应用程序而言，开销从 10–20% 降至约 1–2%。这使得持续追踪成为可能。

2. 可扩展的追踪

通过 分块（splitting） 机制，运行时可以周期性地拆分正在生成的轨迹。每个拆分点相当于同时禁用和重新启用追踪。之前的轨迹数据构成一个完整、独立的轨迹，新的轨迹数据则无缝衔接。这解决了事件乱序和分析时内存占用过高的根本问题。此改进于 Go 1.22 正式发布，并附带了 go tool trace 命令的改进。（注：go tool trace 仍会将完整轨迹加载到内存，但对于 Go 1.22+ 程序产生的轨迹，移除此限制现已可行。）

3. 飞行记录（Flight Recording）

这是一种“持续追踪，按需保存”的技术。由于低开销和可拆分追踪的实现，现在可以始终运行追踪并仅保留最近的轨迹数据。当特定事件（例如，耗时超过阈值的 RPC 请求）发生时，程序可以输出当时已记录的数据。该功能已作为实验性功能在 golang.org/x/exp/trace 包中提供。

以下是一个使用示例：当 HTTP 请求耗时超过 300 毫秒时，输出当前飞行记录器中的轨迹数据。

fr := trace.NewFlightRecorder()
fr.Start()

var once sync.Once
http.HandleFunc("/my-endpoint", func(w http.ResponseWriter, r *http.Request) {
    start := time.Now()
    doWork(w, r)
    if time.Since(start) > 300*time.Millisecond {
        once.Do(func() {
            var b bytes.Buffer
            _, err = fr.WriteTo(&b)
            if err != nil {
                log.Print(err)
                return
            }
            if err := os.WriteFile("trace.out", b.Bytes(), 0o755); err != nil {
                log.Print(err)
                return
            }
        })
    }
})
log.Fatal(http.ListenAndServe(":8080", nil))

4. 追踪读取器 API

为了便于程序化分析轨迹，提供了一个公共的 实验性追踪读取器 API，同样位于 golang.org/x/exp/trace 包。它旨在简化轨迹数据的解析，使得构建自定义分析工具更加容易。

以下是一个示例：计算因等待网络而阻塞的协程阻塞事件的比例。

r, err := trace.NewReader(os.Stdin)
if err != nil {
    log.Fatal(err)
}

var blocked int
var blockedOnNetwork int
for {
    ev, err := r.ReadEvent()
    if err == io.EOF {
        break
    } else if err != nil {
        log.Fatal(err)
    }
    if ev.Kind() == trace.EventStateTransition {
        st := ev.StateTransition()
        if st.Resource.Kind == trace.ResourceGoroutine {
            from, to := st.Goroutine()
            if from.Executing() && to == trace.GoWaiting {
                blocked++
                if strings.Contains(st.Reason, "network") {
                    blockedOnNetwork++
                }
            }
        }
    }
}
p := 100 * float64(blockedOnNetwork) / float64(blocked)
fmt.Printf("%.3f%% instances of goroutines blocking were to block on the network\n", p)

致谢与社区

这些工作的完成得益于诊断工作组（diagnostics working group）的帮助，该工作组一年多前由 Go 社区各方利益相关者合作发起并公开运作。文章特别感谢了 Felix Geisendörfer、Nick Ripley、Rhys Hiltner、Dominik Honnef、Bryan Boreham、thepudds 等社区成员的定期参与和贡献。

Skyvern是一个使用大型语言模型和计算机视觉自动化的浏览器工作流工具。它通过在Playwright SDK上添加AI功能，提供了一个兼容Playwright的SDK和无代码工作流构建器，使技术和非技术用户都能在任意网站上自动化手动工作流，取代脆弱或不可靠的自动化方案。

与传统浏览器自动化依赖定制脚本、DOM解析和基于XPath的交互不同，Skyvern利用视觉LLM来学习并交互网站，能够适应网站布局变化，无需预定义的XPaths或选择器。其灵感来源于任务驱动自主代理设计，并赋予了使用Playwright等库交互网站的能力。Skyvern采用代理集群来理解网站、规划并执行操作，具有以下优势：能在从未见过的网站上运行，通过视觉元素映射来完成工作流；对网站布局变化具有鲁棒性；能将单一工作流应用于大量网站。

Skyvern提供了多种快速开始的方式：云端版本Skyvern Cloud可免去基础设施维护；本地安装可通过pip安装或Docker Compose部署，并支持SQLite或PostgreSQL数据库。SDK方面，Skyvern是Playwright的扩展，添加了四个核心AI命令：page.act（使用自然语言执行操作）、page.extract（提取结构化数据）、page.validate（验证页面状态）和page.prompt（向LLM发送提示）。page.agent提供了更高级的命令，如run_task、login、download_files和run_workflow。所有标准Playwright操作都支持可选的prompt参数，用于AI驱动的元素定位，支持三种交互模式：传统Playwright、纯AI提示以及AI后备模式。

Skyvern支持通过UI或SDK（Python、TypeScript）运行任务，并允许控制本地Chrome浏览器或通过隧道连接云端。它支持定义输出数据模式、实况直播浏览器视口、表单填写、数据提取和文件下载。身份验证方面，支持多种2FA方法（TOTP、电子邮件、短信）和密码管理器集成（Bitwarden、1Password、LastPass等）。还支持模型上下文协议以及与Zapier、Make.com、N8N的集成。

在性能评估中，Skyvern在WebBench基准测试上达到64.4%的准确率，在写入任务（如表单填写、登录、文件下载）上表现最佳。实际应用案例包括在多网站上自动下载发票、自动化求职申请流程、制造业材料采购、政府网站注册/填表、填写联系表单以及检索保险报价等。

Skyvern支持多种LLM提供商，包括OpenAI、Anthropic、Azure OpenAI、AWS Bedrock、Gemini、Ollama、OpenRouter以及任何兼容OpenAI API格式的自定义端点。其开源代码基于AGPL-3.0许可，而反机器人措施等特性仅在托管云服务中提供。

文章标题： Quiet-STaR：语言模型可以教会自己在说话前思考

主要内容摘要：

本文提出了 Quiet-STaR，这是对自我教学推理器（STaR）的推广，旨在让语言模型（LM）学会在生成每个词元（token）时产生内部推理（rationale），以解释后续文本，从而改进其预测能力。

• 核心动机与背景：

  • 人类在书写和说话时常会停顿思考，推理隐含在几乎所有书面文本中（如证明中未言明的步骤、对话背后的心理理论）。
  • 现有的推理研究常局限于问答或代理任务，而先前方法STaR仅在特定问答设置中通过从少样本示例中学习推理。
  • Quiet-STaR的目标是让语言模型在更通用的任意文本中，学会推断未明示的推理依据。

• 关键挑战与解决方案：

  1. 计算成本：在每个词元处生成延续的代价高昂。通过词元级并行采样算法来解决。
  2. 模型初始能力不足：模型最初不知道如何生成或利用内部思考。引入可学习的词元来标记思考的开始和结束。
  3. 预测需求：需要预测超越单个下一个词元的内容。采用扩展的教师强制技术。

• 主要发现与结果：

  • 生成的推理能显著帮助模型预测难以预测的词元，并提升模型直接回答难题的能力。
  • 在互联网文本语料库上使用Quiet-STaR对语言模型进行持续预训练后，无需针对特定任务进行微调，在零样本设置下观察到显著提升：
    • GSM8K（数学推理）准确率：从5.9%提升至10.9%
    • CommonsenseQA（常识推理）准确率：从36.3%提升至47.2%
  • 在自然文本中困难词元上的困惑度也得到改善。

• 意义：Quiet-STaR是朝着使语言模型能够以更通用和可扩展的方式学习推理迈出的一步。

本周，哈佛商学院关于行为科学家弗朗西斯卡·吉诺的调查报告被公开，详细披露了该校如何认定该教授在一系列论文中存在学术不端行为。

这份近1300页的文件是在马萨诸塞州一名法官周二裁定后解封的，这是吉诺去年对哈佛大学、哈佛商学院院长以及三位最早向哈佛指出其四篇论文存在问题的商学院教授提起的诉讼案的最新进展。这四篇论文现均已撤回。

调查报告的公开使外界得以了解哈佛商学院内部调查的详细过程与依据，从而认定其教授吉诺存在研究不端行为。

Onerep.com自称为总部位于弗吉尼亚的数据隐私公司，帮助用户从近200个“人肉搜索”网站移除个人信息，服务费每月8.33美元起。其客户包括健康保险巨头Kaiser Permanente旗下的医生、美国警察部门，以及企业客户。官方网站强调与Nuwber.com（一个人肉搜索网站）无关联，但调查发现大量证据显示Onerep创始人兼CEO Dimitri Shelest实际上也是Nuwber的创始人，并涉足过几十个类似的人肉搜索项目。

注册调查显示，Shelest曾以多个邮箱（如dmitrcox@gmail.com与dmitrcox2@gmail.com）和白俄罗斯电话号码+375-292-702786注册至少179个域名，涉及全球（包括法国、德国、丹麦、意大利、日本等）各国的人肉搜索网站。例如：nuwber.fr、nuwber.at、nuwber.ch、nuwber.dk，以及pplcrwlr.in、peeepl.it等。其LinkedIn以及历史注册信息均显示Shelest来自白俄罗斯明斯克。

Onerep.com和Nuwber.com于2015年左右同时通过eNom注册并使用相同DNS服务。早期员工Dimitri Bukuyazau在LinkedIn自称曾在Onerep任产品经理，其与Nuwber关联线索也在其他博客和公司邮箱注册信息中得到印证。曾有隐私服务商PrivacyDuck指出，2015-2016年间，两网站内容、联系方式和数据处理方式高度相似，甚至“数据展示和隐私移除业务共存”，即用户需付费由Onerep移除包括Nuwber在内的其他网站的数据。

Shelest本人承认仍持有Nuwber股权，但否认与Onerep之间有信息交换，并称其他域名已不再由其运营。他表示创立Onerep源于对人肉搜索行业的深入了解，但过去未公开其关联背景，目前承诺未来将披露更多。

此外，Shelest的邮箱曾出现在2010年俄罗斯大型药品垃圾邮件联盟Spamit的泄露数据中，按分析其为Spamit的低产出推广成员。Shelest的Facebook帐号曾点赞大量其运营或与之相关的人肉搜索站点，也被证实用dmitrcox@gmail.com注册了诸多域名。

Onerep和Shelest未对其利益冲突作详细回应。业界人士（如360 Privacy首席增长官Max Anderson）对此表示担忧，强调“同时运营信息出售和移除服务是极不道德的”，并质疑此做法直接违背Onerep官方宣称“不应以用户隐私牟利”的原则。

Mozilla基金会（Firefox浏览器运营方）近期推出的Mozilla Monitor数据删除服务正与Onerep合作，Mozilla表示已评估其隐私原则，但会进一步调查Shelest有关背景，承诺优先保障客户隐私与安全。

文章还提及Radaris等其他背景复杂的数据经纪平台，这些平台的创始人与俄罗斯有深厚业务联系，部分与当前受美政府制裁的俄国媒体巨头存在合作。同时，作者拟持续追踪这些数据经纪行业内幕并邀请知情人士提供线索。

文章摘要

美国俄勒冈州南部一片广达250万英亩的区域已被正式命名为“俄勒冈奥特巴克国际暗夜保护区”，成为目前全球最大的暗夜保护区。该保护区位于莱克县东南部，包括哈特山、艾伯特湖和萨默湖等区域。未来计划将保护区扩展至哈尼县和马卢尔县，总面积达1140万英亩。

这一认证由致力于通过负责任的户外照明保护夜间环境和暗空的“暗夜天空国际”组织授予。该项目是“俄勒冈暗夜天空网络”多方合作的成果，该网络由州、地方及联邦官员、个人、企业主和旅游机构组成。南俄勒冈旅游局作为网络成员，称赞此举提升了目的地体验，为当地企业创造了机遇，并有助于居民以可持续的方式管理土地，为后代守护繁星夜空。

俄勒冈州此前已拥有两个获认证的暗夜地点：普林维尔水库州立公园（2021年获认证为暗夜公园）和桑里弗自然中心与天文台（2020年获认证为暗夜场所）。新设立的保护区是全球五大洲19个暗夜保护区中规模最大的，超越了明尼苏达州边界水域独木舟区荒野（2020年获认证，面积100万英亩）。

保护区所在区域人口稀少，最大城市莱克维尤人口不足2500人，大部分土地为私有财产或由土地管理局管理的公共土地。该地以清澈黑暗的夜空闻名，是观测流星雨和其他天文事件的理想地点。

暗夜天空国际表示，保护区的第一阶段扩展仅需少量当地批准和照明设施调整，预计将很快推进。该组织项目负责人称赞俄勒冈暗夜天空网络团队的奉献与合作，实现了保护夜空的里程碑，并期待第二阶段的景观尺度扩展。

高效矩阵乘法硬件加速器系统摘要

本文介绍了一个用于验证高效脉动阵列硬件架构的 GEMM 与深度学习硬件加速器系统。该系统通过在硬件中实现新型或低探索的矩阵乘法算法，以更少的硬件资源或执行时间完成相同的计算任务。

核心成果

• 性能提升：在相同计算平台上，CNN推理速度比最先进加速器快高达3倍。
• 计算效率：每个乘法器每个时钟周期的乘法操作数（mults/multiplier/clock cycle）超过2倍，突破了传统上限1。
• 硬件优势：具有面积小、时钟频率高的特点。

技术贡献

系统验证了以下发表研究中提出的脉动阵列架构：

1. 快速内积算法与架构（IEEE TC, 2024）
   提出了一种通过低比特宽度加法替换一半乘法操作的脉动阵列。该架构可无缝替换现有脉动阵列，在不改变系统其他部分的前提下使每个MAC单元的性能翻倍。

2. Karatsuba矩阵乘法（KMM）（IEEE TC, 2025）
   将Karatsuba乘法扩展到矩阵乘法，降低整数矩阵乘法复杂度。自定义硬件实现可改善面积或执行时间。

3. Strassen多脉动阵列架构（IEEE TVLSI, 2025）
   首次为Strassen快速矩阵乘法算法提供高效自定义硬件实现，在深度学习加速器中达到最先进性能。

4. 博士论文（2025）
   涵盖上述三种方法、深度学习加速背景、代数增强、系统设计及未来工作。

核心思想：提升每MAC单元性能

深度学习模型的主要计算负载可映射为矩阵乘法，即一系列乘积累加（MAC）操作。传统加速器的吞吐量受限于每个时钟周期可执行的MAC操作数量，导致乘法器和MAC单元成为硬件面积和性能的瓶颈。本研究通过代数层面减少工作量（重新排列计算模式以减少或简化硬件操作），在理论极限之上提升硬件加速器的性能-面积比。

系统特性与适用范围

• 应用场景：改进密集矩阵乘法加速，适用于全连接层、CNN、RNN、Transformer等可分解为矩阵乘法的DNN模型/层。
• 数据类型：主要针对定点数据类型和量化神经网络推理，输出与传统算法/架构完全相同，不改变数值稳定性。
• 硬件平台：结果在FPGA上验证，但架构通用，适用于定制集成电路和FPGA实现。
• 无缝集成：提出的架构均为脉动阵列，功能与接口与传统脉动阵列相同，可无缝替换到现有加速器系统中，无需系统其他部分修改或额外前后处理。

加速器系统架构

源码实现的完整深度学习推理加速器系统包含以下模块：

• 矩阵乘法单元（MXU）：脉动阵列架构，用于执行矩阵乘法。
• GEMM单元：包含MXU、SRAM及加法逻辑，支持任意大小矩阵的GEMM执行。
• 后GEMM单元：执行神经网络特有操作，如添加偏置、层间缩放、激活、填充和池化。
• 内存单元：控制片上SRAM和片外DDR DRAM，高效缓存与访问控制，将卷积原地映射为GEMM，采用内存分区方案以降低控制时钟频率、提升系统频率。
• 收发单元：PCIe主机接口。
• 指令单元：解码主机发送的加速器指令，支持单硬件设计加速任意层尺寸/核尺寸的ML模型。
• 编译器：解析Python模型描述为加速器指令。

源代码结构

• compiler：模型编译器与驱动接口。
• rtl：可综合的SystemVerilog加速器RTL。
• sim：仿真环境设置脚本。
• tests：UVM验证测试平台。
• utils：开发辅助工具。

系统参数可在rtl/top/define.svh和rtl/top/pkg.sv中配置（如脉动阵列类型、尺寸、输入比特宽度）。rtl/arith目录包含基线及部分提议脉动阵列架构（如FIP、FFIP）的RTL代码。

TextSnatcher：Linux桌面图片文字提取工具

核心功能

• 快速OCR识别：使用Tesseract OCR 4.x引擎，实现从图片中快速提取文字。
• 便捷操作：支持通过鼠标拖选图片区域，直接复制识别出的文字到剪贴板。
• 多语言支持：能够识别多种语言的文字内容。
• 简单易用：界面设计注重效率，操作流程直观。

项目状态

开发者正在为新的Linux电脑筹集资金，预计下个月将恢复项目更新，修复问题并推出改进。

技术依赖

运行时依赖：

• scrot（屏幕截图工具）
• tesseract-ocr 及对应语言数据包
• 在Arch Linux和Debian系发行版仓库中可获取

构建时依赖：

• Granite、GTK+ 3.0、GObject、GDK-Pixbuf 2.0
• Libhandy 1、Libportal 0.5

安装与构建步骤

1. 克隆代码仓库
2. 使用meson配置构建目录
3. 通过ninja编译并安装
4. 运行应用命令：com.github.rajsolai.textsnatcher

项目灵感来源

• 参考了Planner和Alcadica项目的README与应用结构设计
• 借鉴了macOS应用TextSniper的概念

附录说明

文章包含演示视频（英语和泰米尔语）及截图，用于展示实际使用效果。开发者提供了社交媒体（LinkedIn）链接，阐述创建该应用的初衷。应用采用GPLv3开源协议，为Linux桌面用心打造。

一、案件基本信息
本案为美国佛罗里达南区联邦地区法院受理的集体诉讼（案号：9:24-cv-80281-DMM）。原告罗密欧·奇科（Romeo Chicco）代表其本人及其他类似处境的消费者，起诉通用汽车有限责任公司（General Motors LLC）、安吉星有限责任公司（OnStar LLC）及律商联讯风险解决方案公司（LexisNexis Risk Solutions Inc.）。

二、原告诉讼请求与法律依据
原告主张被告在未获得其明确同意的情况下，收集、分享其驾驶行为数据（如急刹车、超速等），并导致这些数据出现在律商联讯的消费者报告中，进而影响其购买汽车保险（被拒或保费上涨）。原告依据以下法律提起诉讼：

1. 《公平信用报告法》（FCRA）：指控律商联讯作为消费者报告机构，违反了该法关于确保信息最大准确性和遵循合理程序的规定（15 U.S.C. § 1681e(b)）。
2. 《佛罗里达州欺骗性和不公平贸易行为法》（FDUTPA）：指控所有被告从事欺骗性和不公平的商业行为。
3. 佛罗里达州普通法隐私权侵权：指控被告公开披露私人事实及侵犯个人隐居安宁。

三、核心事实指控

1. 未告知的数据收集与共享：原告于2021年11月购买凯迪拉克XT6后，未主动注册安吉星（OnStar）服务，也从未同意“Smart Driver”驾驶行为数据收集计划。然而，其驾驶数据仍被收集，并通过通用汽车/安吉星系统分享给律商联讯。
2. 误导性与不充分的披露：购车协议、安吉星欢迎邮件及账单均未提及数据共享至第三方。安吉星的隐私政策条款含糊且隐藏，未清晰说明会向保险数据经纪商（如律商联讯）分享驾驶数据。
3. 不准确的消费者报告：律商联讯报告中包含的驾驶事件数据（如258条记录）缺乏背景说明，无法准确反映实际驾驶情况，却足以导致保险公司拒保或大幅提高保费。
4. 被告推诿与沟通无效：原告尝试联系各被告解决问题时，遭遇互相推诿，无法获得关于数据如何被收集与共享的明确解释。
5. 广泛影响与媒体报道：原告引用2024年3月11日《纽约时报》调查报道，指出类似情况在其他通用汽车车主中普遍存在，许多车主在不知情或未明确同意的情况下被追踪驾驶数据。

四、拟议的集体诉讼范围
原告请求代表以下三类集体：

1. FCRA集体：在过去两年内，未经其同意，其驾驶数据被收集并分享给律商联讯，且该数据出现在律商联讯消费者报告中的个人。
2. FDUTPA集体：在过去四年内，未经其同意，其驾驶数据被收集并分享给律商联讯的个人。
3. 隐私权侵权集体：在过去四年内，未经其同意，其驾驶数据被收集并分享给律商联讯，且该数据出现在至少一份律商联讯消费者报告中的个人。

五、诉讼请求（救济要求）
原告要求法院判决：

1. 金钱赔偿：依据FCRA、FDUTPA及普通法，判给实际损害赔偿、法定损害赔偿、惩罚性损害赔偿及律师费与诉讼成本。
2. 禁令救济：禁止被告未来在未获得消费者明确同意的情况下收集和分享驾驶数据。
3. 陪审团审判：要求由陪审团进行审理。

总结：本案核心争议在于汽车制造商（通用/安吉星）及数据经纪商（律商联讯）在未获消费者充分知情同意的情况下，收集与共享精细驾驶数据的行为，涉嫌违反联邦与州消费者保护法律及侵犯个人隐私，并对消费者造成实际经济与精神损害。原告代表潜在的数千名受影响消费者提起集体诉讼，寻求金钱赔偿与行为禁令。

PostgreSQL已超越简单的关系数据库角色，演变为一个具备吞噬整个数据库领域潜力的数据管理框架。“万物皆用Postgres”正成为主流实践。

分析型（OLAP）能力的关键突破
传统上，PostgreSQL在大规模分析性能上逊于专用数据仓库。在ClickBench基准测试中，未经优化的PostgreSQL性能极差（慢1050倍），优化后或借助生态扩展（如Hydra、TimescaleDB、Citus）可提升至第二梯队（慢42-262倍），但仍落后于ClickHouse等顶级OLAP系统（慢3-4倍）。ParadeDB的pg_analytics扩展将性能提升至第二梯队（慢10倍），而DuckDB（通过DuckDB FDW集成）则将分析性能推向极致（慢3.2倍），使PostgreSQL的分析能力跻身顶级行列。

数据库领域的范式转变
OLTP与OLAP的分离源于传统数据库无法满足分析场景的性能需求，催生了通过ETL将数据同步至专用分析系统的模式。然而，过去三十年遵循摩尔定律的硬件革新（多核CPU、大内存、高速NVMe SSD）已基本解决了数据规模和性能问题。同时，PostgreSQL、ParadeDB、DuckDB等软件的发展解决了访问方法问题。这使得“大数据”基础假设受到质疑——99%的场景现已能在单机上由PostgreSQL/DuckDB处理。数据库领域正从多样性分化回归聚合，朝向统一的多模型超融合数据库发展。

PostgreSQL：数据库领域的吞噬者
PostgreSQL凭借其极致可扩展性与繁荣的扩展生态，正渗透至时间序列、地理空间、文档、搜索、图、向量数据库乃至消息队列等所有细分领域。例如，PostGIS成为地理空间数据库的事实标准；pgvector让专用向量数据库相形见绌。其可扩展性允许开发者在极低复杂度下（仅需关注核心功能）利用数据库通用基础设施（如ACID、备份、高可用等）开发扩展。扩展的可组合性能产生1+1远大于2的协同效应（如TimescaleDB与PostGIS结合支持时空数据，全文搜索BM25扩展与pgvector结合提供混合搜索）。分布式扩展（如Citus）更能透明地将其他扩展功能分布式化。

游戏规则的改变者
PostgreSQL的出现改变了数据库领域的竞争范式。在硬件革命性突破出现前，开发全新的通用数据库内核可能性渺茫。任何细分数据库若想生存，通常需要在特定方面（通常是性能）超越PostgreSQL一个数量级，但PostgreSQL生态很快会通过开源扩展实现追赶。这使得PostgreSQL生态系统如滚雪球般积累优势，正朝着类似Linux内核在服务器操作系统中的垄断地位发展。“简单至上：只用Postgres”正成为简化技术栈、加速开发、降低风险的主流实践。

未来焦点与解决方案：Pigsty
数据库内核之争已尘埃落定，竞争焦点转向数据库扩展（内部可扩展性）和服务（外部可组合性），如同操作系统生态竞争集中于发行版。然而，PostgreSQL生态中许多扩展独立发展，缺乏整合者以发挥协同放大效应。即使是云服务商（如AWS RDS）也因各种原因（如许可证、多租户安全）无法纳入众多重要扩展，限制了生态潜力的释放。

Pigsty 正是为解决此问题而生的开源解决方案。它是一个全功能、本地优先的PostgreSQL发行版，旨在成为开源的RDS替代品，整合PostgreSQL生态扩展的力量，民主化生产级数据库服务。其核心价值主张涵盖可扩展的PostgreSQL、可靠基础设施、可视化图形、可用服务、可维护工具箱和可组合模块。在最新的v2.6版本中，Pigsty集成了DuckDB FDW和ParadeDB扩展，大幅增强了分析能力，目标是成为数据库领域的“Ubuntu”，将竞争前沿聚焦于扩展与服务的整合。

Sunlight：新一代证书透明度日志实现

项目背景与动机

Let's Encrypt推出了Sunlight，这是一个从零开始构建的证书透明度（CT）日志新实现，旨在应对现代Web PKI的增长与挑战。该项目由Filippo Valsorda主导设计与开发，并吸收了来自Google Chrome/TrustFabric团队、Sigsum项目及其他CT日志和监控运营者的广泛反馈。当前CT日志面临的核心挑战是证书数量急剧增长（例如Let's Encrypt每日颁发超过400万份证书），导致现有架构（如“Oak”日志）在存储、读写性能及运营复杂度上遇到瓶颈。

现有CT日志的瓶颈

• 数据库存储限制：现有日志使用关系型数据库，通过分片（如按年或半年）应对数据增长，但单个分片数据量已达5-10TB，存在技术限制（如MySQL的16TiB限制）且运维成本高。
• 读取扩展性问题：客户端大量读取请求易使数据库过载，强制限速又会降低CT作为快速证书滥用检测机制的效率。
• 写入复杂度：传统实现（如Trillian）依赖多节点协调和领导选举，增加了系统复杂性。

Sunlight的核心设计创新

1. 基于瓦片的静态读取路径

• 灵感来源：借鉴Go校验和数据库的高效数据发布格式，将二叉Merkle树数据分为一系列静态瓦片文件。
• 瓦片结构：每个瓦片文件包含256个元素，可以是树特定高度的哈希或叶节点的证书/预证书。
• 优势：
  • 无需动态API计算，可直接托管于对象存储（如S3）或CDN，实现低成本水平扩展。
  • 静态文件支持高效缓存，叶瓦片还可压缩存储，节省空间。
  • 解决了传统动态CT API（如get-proof-by-hash）缓存效率低的问题。

2. 简化的单节点写入架构

• 利用CT生态的分布式特性（客户端向多个日志提交），单个日志无需高可用领导选举。
• 采用简单的比较并交换（CAS）机制防止意外分叉，大幅降低运维复杂度。
• 相同计算资源下可运行更多独立日志，提升整体系统鲁棒性。

3. 消除合并延迟（Merge Delay）

• 传统CT日志为满足延迟承诺，采用“最大合并延迟”（通常24小时）机制，但常因日志故障而失效。
• Sunlight在提交后立即批量集成证书，完全消除合并延迟，虽略微增加提交延迟，但避免了因承诺违约导致的故障。
• 此设计还允许在SCT中嵌入最终叶索引，便于客户端直接验证Merkle树证明，并利用新的瓦片API获取包含证明。

生态系统影响与未来展望

• 资源发布：Sunlight软件和规范已公开，Let's Encrypt已运行基于Sunlight的CT日志。
• 生态协同：鼓励证书颁发机构（CA）向新日志提交测试，呼吁CT监控和审计程序支持消费Sunlight日志，推动浏览器CT项目信任该架构。
• 社区支持：Google TrustFabric团队表示支持，并计划将瓦片式日志及Sunlight API集成到Trillian中。
• 协作平台：通过ct-policy邮件列表和transparency-dev Slack的#sunlight频道进行设计讨论。
• 发展愿景：Sunlight旨在提升CT生态系统的健壮性、多样性和可靠性，未来有望被浏览器CT项目采纳，满足其日志要求。

文章核心论点：作者指出“让非机器人专家也能轻松编程机器人”是一个反复出现但错误的理念，称之为“神话般的非机器人专家”。他认为，由于机器人编程的内在复杂性（与真实、不确定的物理世界交互）无法被简化，试图通过简单API覆盖所有用例的框架注定会失败，甚至会将复杂性转嫁给用户。

关键问题分析：

1. 编程的双重困难：

   • 内在复杂性：机器人必须处理不完美的感知和执行，与一个全局可变的物理世界互动。找到有效解决方案极度依赖具体任务、硬件和环境，难度极高。
   • 偶发复杂性：源于系统搭建、驱动配置、通信、日志管理等“愚蠢的”繁琐技术问题。

2. “神话”的误区：

   • 针对模糊的“非机器人专家”群体设计工具，忽略了真正的用户就是机器人专家（无论背景如何）。
   • 试图用过度简化的API（如 grasp_object()）隐藏内在复杂性，导致API在实际应用中失效，无法覆盖具体场景的需求。
   • 设计者可能因认为用户不够聪明而拒绝增加必要的配置选项，进一步限制了API的实用性。

3. 正确的改进方向：

   • 不应降低内在复杂性：当前机器人技术性能尚无余地为易用性牺牲效能。
   • 应消除偶发复杂性：核心是减少编程中不必要的“愚蠢”麻烦，让开发者能更快地触及真正的机器人问题。
   • 设计原则：作者提出 “为和你一样聪明但更不能忍受愚蠢废话的人设计API”。应创造具有强大功能、良好默认值和灵活性的工具（例如，使用像Python那样的默认参数语法），让简单的事情简单，复杂的事情可行。

结论：机器人编程的困难本质与游戏开发等领域相似，并非无法企及。降低入门门槛的关键不是提供掩盖复杂性的魔法框架，而是通过优秀的工具设计，高效地帮助开发者（即真正的“机器人专家”）跨过偶发复杂性的障碍，从而专注于解决核心的、有意义的内在挑战。

项目概述

Richard 是一个用 C++ 和 Vulkan 编写的卷积神经网络分类器，不依赖任何机器学习或数学库。该项目最初作为个人学习机器学习的工具，现在是一个支持 GPU 加速的命令行分类应用。

核心功能与结构

• 支持层类型：包含全连接层、卷积层和最大池化层。
• GPU 加速：通过 Vulkan 计算着色器实现。
• 构建方式：支持 Linux、Windows 和 macOS，依赖 CMake、vcpkg 和 Vulkan SDK。
• 用法：提供 richardcli 命令行工具，支持 --train（训练）和 --eval（评估）模式，可通过 --gpu 启用 GPU 加速。

构建步骤

1. 安装依赖：各操作系统需安装 CMake、vcpkg、Vulkan SDK 及相应编译工具（如 Linux 需 CMake，Windows 需 Visual Studio）。
2. 生成与构建：使用 CMake 预设工作流，例如 Linux 调试构建可运行 cmake --workflow --preset=linux-debug。

使用示例

示例1：全连接网络手写数字分类

• 配置：定义数据形状（784 维）、类别（0-9），网络包含两个隐藏层（320 和 64 个神经元），输出层为 10 类。
• 命令：通过 --train 指定训练数据、配置文件和网络存储路径，--eval 进行评估。

示例2：卷积神经网络猫狗分类

• 配置：处理 100x100x3 形状的图像，网络包含两个卷积层、两个最大池化层和一个全连接层，输出 2 类。
• 命令：类似示例1，但使用 CNN 配置和对应数据集。

性能分析

• CPU 性能分析：在 Linux 上使用 Google perftools 工具。
• 步骤：
  1. 安装 google-perftools。
  2. 使用 linux-cpuprof 预设构建项目。
  3. 设置 CPUPROFILE 环境变量并运行程序，生成性能数据文件。
  4. 使用 google-pprof 生成文本或图形报告。
• 结果解读：文本报告展示函数耗时占比（如 computeCrossCorrelation 占用 41.3% 的时间），用于识别性能瓶颈。

IAM 是最糟糕的

核心问题

IAM（身份与访问管理）系统随着云服务的扩展变得过于复杂，导致管理困难、权限冗余，并带来安全隐患。作者通过清洁工的比喻说明，原本简单的“万能钥匙”被替换为繁琐的权限申请系统后，工作人员的钥匙串变得庞大而低效，许多权限实际上超出了所需范围。

AWS IAM 的困境

• 开发者需要为特定服务申请权限，但角色名称模糊（例如“datastore.viewer”与“datastore.keyVisualizerViewer”），难以准确选择。
• 经常出现权限不足的错误，需要反复调整角色并排查跨服务依赖。
• 最终常通过创建自定义角色解决，但其中包含了大量未使用的权限，形成安全风险。
• 权限审计困难，过度授权普遍。

GCP IAM 的问题

GCP 的系统被认为比 AWS 更复杂且不友好：

• 初始设计使用基础角色（viewer/editor/owner），但随着服务增加，这些角色权限过广。
• 预定义角色数量庞大（超过1600种），且角色权限会随新服务上线而频繁变更。
• 自定义角色需要手动列出具体权限，无法直接组合预定义角色。
• 角色版本（如ALPHA、BETA、GA）进一步增加了管理复杂性。

现实影响

• 团队难以确定正确的权限组合，依赖猜测和反复试错。
• 安全团队难以审核权限请求是否合理。
• 长期积累导致权限逐渐接近“万能钥匙”，违背最小权限原则。

作者提出的解决方案

作者认为现有系统的问题有明确的解决方法：

1. 基于实际使用数据调整权限：
   • 为用户和应用授予临时的宽泛权限（如服务账户的全面访问权限）。
   • 通过监控工具（如GCP的角色建议、AWS的访问分析）记录实际使用的权限。
   • 定期（如每90天）根据使用数据自动缩限权限，移除未使用的部分。
2. 临时权限授予机制：
   • 允许用户通过流程申请临时提权（如Slack机器人或自助网站），权限在几小时后自动失效。
   • 结合轮值状态（如on-call）自动扩展权限。
3. 数据驱动而非猜测：
   • 方案基于实际使用数据，避免团队间猜测或安全团队主观判断。

结论

IAM 从一个简单概念演变为复杂的噩梦，尤其在GCP上管理更困难。但解决方案是清晰的：云提供商应采用基于实际使用数据的自动化权限优化系统，取代当前繁琐、低效且易错的手动管理方式。虽然迁移至新系统会带来短期阵痛，但长期将提升安全性和可管理性。

Stashpad 推出无需登录即可使用的文档应用 Stashpad Docs，作为其原有笔记应用的转型产品。原笔记应用将继续以“Stashpad Lists”的名称维护。

新产品的主要特点包括：

• 无需登录，支持 Markdown 格式编辑。
• 以浏览器为主，文档历史记录存储在本地，用户可本地搜索文档，无需查询服务器。
• 目前暂不支持离线使用，但未来将增加此功能。
• 支持文档共享与协作，实时协作延迟低于50毫秒。
• 部分功能（如只读共享）需要登录，高级功能（如限制访问、优先支持）需订阅 Pro 计划（每月12美元或按年付费每月8美元）。

公司转向文档应用的原因是其原笔记产品增长未达预期，用户群体较窄。在为笔记应用开发多人协作功能时，创始人发现即使团队已使用 Confluence 或 Notion 等工具，用户仍广泛依赖 Google Docs 进行协作，存在对类似工具的更大需求。Stashpad 希望通过新产品吸引技术与非技术用户，并认为文档产品具有风险投资级别的市场机会。

公司迄今已筹集200万美元资金。

柏林电子音乐场景被正式列入德国非物质文化遗产名录，德国文化部及联合国教科文委员会此举旨在表彰其对城市文化认同的重要贡献。

柏林俱乐部委员会（Clubcommission）称此举是“柏林电子音乐制作人、艺术家、俱乐部经营者和活动组织者的又一里程碑”。该组织执行董事会成员指出，这一认定将有助于确保俱乐部文化作为值得保护和支持的宝贵领域得到认可。

经过十余年的倡导，非营利组织“Rave the Planet”于2022年11月提交了将电子音乐纳入名录的申请。该组织在社交媒体上表达了祝贺，称这是“整个文化的重要里程碑”。

虽然非物质文化遗产通常授予更传统的文化活动（如马拉维的Mwinoghe舞蹈或斯洛伐克风笛文化），但牙买加雷鬼音乐和印度大壶节此前获得联合国教科文组织全球名录的认可，这激励了柏林电子音乐社群争取自身的认可。需要说明的是，此次被纳入的是德国国内非物质文化遗产名录，而非联合国教科文组织的全球名录。

柏林电子音乐场景被视为该城市文化的基本组成部分。当地DJ和音乐制作人指出，柏林对更加前卫、实验性的音乐形式有着更高的接受度，并认为电子音乐为边缘群体提供了庇护，使柏林成为一个更具包容性的文化空间。

电子音乐场景是德国非物质文化遗产名录新增的六个项目之一，其他新增项目包括水果酒、登山运动以及巴伐利亚州的“Kirchseeoner Perchtenlauf”游行。