GPT-4o是OpenAI发布的最新旗舰多模态模型，能够实时处理并生成文本、音频、图像和视频的组合。其名称中的“o”代表“omni”（全能），旨在实现更自然的人机交互。该模型对音频输入的响应时间最快可达232毫秒，平均320毫秒，接近人类对话反应速度。

核心改进与架构 与以往使用多个独立模型（如语音转文本、文本处理、文本转语音）的流水线模式不同，GPT-4o是首个在文本、视觉和音频上进行端到端训练的单一神经网络。这使得模型能够直接感知语气、多人对话、背景声音等信息，并输出笑声、歌唱或情感表达，避免了传统流程中主模型丢失多模态信息的问题。

性能表现 在文本、推理和代码智能方面，GPT-4o达到了GPT-4 Turbo的水平，同时在多语言、音频和视觉能力上创下新高。其文本处理效率显著提升，尤其在非英语语言中表现更优，使用新的分词器后，多种语言（如古吉拉特语、泰卢固语、泰米尔语等）的标记数量大幅减少。该模型速度比GPT-4 Turbo快两倍，API价格降低50%，且速率限制提高五倍。

安全与评估 GPT-4o内置了安全性设计，包括训练数据过滤和后期行为优化。根据OpenAI的准备框架评估，该模型在网络安全、CBRN（化学、生物、放射性、核）、说服力和模型自主性等风险类别中，均未超过“中等”风险级别。此外，模型经过70多位外部专家在社会心理学、偏见与公平、错误信息等领域的红队测试，以识别和缓解新模态引入的风险。

音频等模态因其新颖性存在一定风险。因此，发布初期仅开放文本和图像输入及文本输出，音频输出将限于预设声音并遵守现有安全策略。完整的多模态能力将在后续系统卡中详细说明。

发布与可用性 GPT-4o的文本和图像功能已在ChatGPT中逐步推出，免费用户和Plus用户（享有五倍消息上限）均可使用。未来几周，ChatGPT Plus将推出基于GPT-4o的新版语音模式测试版。开发者可通过API访问其文本和视觉模型，音频和视频能力将在未来几周内向小范围可信合作伙伴开放。

OpenAI将持续收集反馈以改进模型，并致力于通过技术基础设施、后期训练和安全性工作，逐步释放全部模态能力。

苹果与谷歌合作推出了一项针对蓝牙追踪器的行业规范——“检测不需要的位置追踪器”（Detecting Unwanted Location Trackers），旨在跨平台（iOS 和 Android） 向用户发出警报，以防范此类设备被滥用进行追踪。

主要实施与功能：

• 苹果已在 iOS 17.5 中集成此功能。
• 谷歌已开始面向运行 Android 6.0 及以上版本的设备推出此功能。
• 当用户的设备检测到一个未知的蓝牙追踪器在一段时间内与其一同移动时，无论该追踪器与哪个平台配对，用户都会收到一个 “[物品]在你附近移动” 的警报。
• 在 iOS 设备上，收到警报后，用户可以查看追踪器的标识符、触发其播放声音以协助定位，并获取禁用它的说明。

合作意义与厂商支持：

• 此举旨在缓解专为寻找物品而设计的蓝牙追踪器被误用的风险。
• 苹果强调其 AirTag 等产品从设计之初就注重隐私与安全，并通过此次行业首创的跨平台合作（吸纳了社区和行业意见）进一步加强对消费者的保护。
• 该规范为制造商提供了构建追踪警报功能的指导和最佳实践。
• 包括 Chipolo、eufy、Jio、Motorola 和 Pebblebee 在内的多个蓝牙标签制造商已承诺其未来产品将兼容此规范。

未来规划： 苹果和谷歌将继续通过 互联网工程任务组（IETF） 下的“检测不需要的位置追踪器”工作组合作，推动该技术的正式标准制定。

Mozilla致力于创新与隐私保护并重，为更好理解用户如何使用Firefox，正采用新方法优化产品。此次更新主要围绕搜索数据收集方式的调整，旨在提升搜索体验（如Firefox Suggest功能），同时严格遵守隐私优先原则。

核心变化：

• 针对美国桌面版Firefox用户，引入新的搜索活动衡量方式：将搜索结果分类到高层级类别（如旅行、健康、科技等，共20类）。
• 该数据不与个人身份关联，并通过OHTTP技术匿名化处理，确保无法与用户IP地址链接。
• 例如，用户搜索“巴塞罗那酒店”会被归类为“旅行”类别，并累加统计该类别搜索次数。

隐私保护措施：

• 仅分类搜索结果所属类别，不收集具体搜索内容。
• 敏感话题（如医疗健康）仅归入宽泛类别（如“健康”或“社会”），与其他数据同等保密。
• 用户可选择退出数据收集（提供操作指南），且在隐私浏览模式下不收集分类数据。

目的与影响：

• 通过理解搜索类别分布，优化产品功能（如Firefox Suggest）和用户体验。
• 不改变用户浏览体验，仅用于后台产品改进。
• Mozilla强调此举延续其25年来“让互联网更安全、更符合用户需求”的使命，同时坚守隐私原则。

mRNA癌症疫苗在恶性脑瘤治疗中取得突破性进展

研究概况
佛罗里达大学开发的新型mRNA癌症疫苗在首次人体临床试验中，成功快速重编程免疫系统以攻击最具侵袭性的脑瘤——胶质母细胞瘤。该疫苗基于与COVID-19疫苗相似的mRNA技术，但进行了两项关键创新：使用患者自身肿瘤细胞制备个性化疫苗，以及采用新型多层脂质纳米颗粒递送系统（类似“洋葱结构”的颗粒簇）。

核心发现

1. 快速免疫激活：静脉注射疫苗后，免疫反应在48小时内被触发，将肿瘤微环境从免疫“冷”状态（免疫细胞少、反应弱）转变为免疫“热”状态（免疫反应活跃），为后续抗肿瘤免疫应答奠定基础。
2. 跨物种一致性：疗效在10只自发脑瘤宠物犬（中位生存期从常规的30-60天延长至139天）和4名成人患者中均得到验证，患者生存期或无病生存期均超出预期。
3. 技术机制：从手术切除的肿瘤中提取RNA，扩增为mRNA模板，包裹在新型脂质纳米颗粒中形成个性化疫苗，使肿瘤细胞在免疫系统中被识别为“外来威胁”，从而激发特异性免疫攻击。

临床意义与未来方向

• 该研究为治疗难治性癌症提供了新范式，特别是胶质母细胞瘤（中位生存期仅15个月）。
• 下一步将开展I期临床试验（纳入最多24名成人和儿童患者），验证安全剂量；随后计划开展II期试验（预计25名儿童参与），与多家儿童医院合作推广个性化疫苗制备。
• 研究局限包括对免疫系统调控和副作用控制的进一步优化，但疫苗有望与现有免疫疗法协同，形成组合治疗方案。

学术影响
该成果历时7年，从临床前小鼠模型、宠物犬试验推进至人体试验，展现了mRNA技术在癌症免疫治疗中的独特潜力。研究团队已获得相关专利，并由衍生公司iOncologi Inc.进行技术转化。

Pipecat：开源的实时语音与多模态AI代理框架

Pipecat 是一个用于构建实时语音与多模态对话式AI代理的开源Python框架。它简化了音频、视频、AI服务、传输协议和对话流水线的编排，使开发者能够专注于创建独特的代理功能。

主要功能与特点

• 语音优先：原生集成语音识别（STT）、文本转语音（TTS）与对话处理。
• 可插拔与可组合：支持众多第三方AI服务与工具，并通过模块化组件构建复杂行为。
• 多代理就绪：支持构建单一代理或完整的多代理系统，代理间可通过交接、并行扇出、副车或分布式部署等方式协调。
• 实时交互：支持通过WebSocket或WebRTC等多种传输协议实现超低延迟交互。

可构建的应用

Pipecat 适用于构建多种应用，包括：

• 语音助手与AI伴侣（教练、会议助手）
• 多模态交互界面（融合语音、视频、图像）
• 交互式叙事、业务代理（客服机器人、引导式流程）及复杂对话系统。

丰富的生态系统

Pipecat 拥有完善的生态支持：

• 客户端SDK：提供JavaScript、React、Swift、Kotlin、C++等平台的官方SDK。
• 工具与组件：包括用于管理复杂对话状态的 Pipecat Flows、用于快速构建UI的 Voice UI Kit、CLI部署工具、实时调试器 Whisker 以及终端仪表板 Tail。
• 广泛的服务集成：集成了大量服务，类别涵盖：
  • 语音转文字：如AssemblyAI、Deepgram、Google、OpenAI Whisper等。
  • 大语言模型：如OpenAI、Anthropic、Mistral、Ollama等。
  • 文字转语音：如ElevenLabs、Deepgram、OpenAI等。
  • 传输协议：支持Daily、LiveKit、WebRTC、WebSocket等。
  • 其他还包括视频、内存、视觉/图像、音频处理等服务。
• 社区与支持：拥有活跃的Discord社区、文档、X平台联系渠道以及Pipecat TV频道。

快速开始

1. 安装：推荐使用 uv 包管理器。

   # 创建新项目并添加依赖
   uv init my-pipecat-app
   cd my-pipecat-app
   uv add pipecat-ai
   # 可添加特定服务支持，例如：
   uv add "pipecat-ai[openai]"
   

2. 文档与资源：提供从基础片段到完整应用的代码示例，以及详尽的服务文档。

贡献指南

Pipecat 欢迎社区贡献（Python >= 3.11）。开发者可以克隆仓库，使用 uv 安装开发和测试依赖。项目鼓励通过报告问题、提交功能讨论或代码Pull Request等方式参与。

新型凝胶可在体内分解酒精

核心研究：瑞士苏黎世联邦理工学院的研究人员开发出一种基于蛋白质的凝胶，能在胃肠道内分解酒精，且不损害身体。该凝胶未来或可帮助人们减少酒精的有害和致醉影响。

技术原理与成分

• 基础材料：凝胶由普通乳清蛋白制成。研究人员将其煮沸数小时，形成长而薄的纤维，再通过加盐和加水使其交联成凝胶。
• 催化机制：凝胶的核心催化剂是单个铁原子，它们均匀分布在蛋白纤维表面，能与酒精反应。反应需要微量的过氧化氢来触发，而过氧化氢由预先嵌入凝胶的金纳米颗粒和葡萄糖通过上游反应产生。金作为催化剂是因为它不会被消化，能在消化道中保持更长时间的活性。
• 作用过程：这一多级酶促反应系统在酒精进入血液循环之前，就能在肠道内将其快速、高效地转化为无害的醋酸。与肝脏代谢酒精不同，此过程不会产生有毒的中间产物乙醛。

动物实验结果

研究人员在小鼠身上测试了凝胶的效果：

• 单次饮酒实验：在给药30分钟后，预防性使用凝胶可使小鼠血液酒精浓度降低40%；5小时后，与对照组相比，血液酒精浓度降幅可达56%。同时，有害的乙醛积累更少，肝脏应激反应显著降低。
• 长期饮酒实验：在连续10天饮酒的小鼠中，每日使用凝胶不仅能降低酒精浓度，还产生了持久的治疗效果：体重减轻更少，肝脏损伤更小，肝脏脂肪代谢更好，血液指标更佳，其他器官（如脾脏、肠道）的组织损伤也明显减轻。

应用前景与局限

• 预期用途：该凝胶未来可能通过口服方式，在饮酒前或饮酒期间使用，以防止血液酒精浓度升高和乙醛对身体的损害。它针对的是酒精危害的根本原因（即酒精本身），而非仅仅缓解症状。
• 主要局限：
  1. 凝胶只在酒精仍在胃肠道内时有效，一旦酒精进入血液，其作用便非常有限，因此无法用于治疗已发生的酒精中毒。
  2. 它并非旨在帮助人们减少整体的酒精消费量。
• 研究人员认为，该凝胶对于不愿完全戒酒、但又不想给身体造成负担且不主动追求酒精效果的人群可能特别有益。

后续进展

研究人员已为该凝胶申请了专利。尽管在应用于人体之前仍需进行多项临床测试，但他们对此表示信心，因为构成凝胶基础的乳清蛋白纤维已被证明是可食用的。

Pico: 面向生产环境的开源 Ngrok 替代方案

Pico 是一个反向代理服务器，提供安全的隧道服务，用于连接那些无法通过公共网络直接访问的服务。它的工作方式是：上游服务主动与 Pico 建立仅出站的连接（隧道），随后 Pico 通过这些已建立的连接将流量转发给这些服务。

核心设计目标 Pico 有两个关键设计目标：

1. 为生产流量设计：通过以节点集群的方式运行，实现故障容忍、水平扩展和零停机部署。
2. 易于在 Kubernetes 上部署：可以作为集群（如 StatefulSet）运行，并能够轻松地部署在 HTTP(S) 负载均衡器或 Kubernetes 网关之后。

因此，Pico 可作为 Ngrok 的开源替代品，适用于暴露客户网络内的服务、BYOC（自带云）服务或连接用户设备等场景。

与传统反向代理的区别 在传统反向代理中，你需要配置路由规则将流量导向可发现且暴露端口的上游服务。而 Pico 的工作方式则相反：上游服务主动向 Pico 服务器发起仅出站的连接，并声明其监听的端点（Endpoint）。Pico 随后将传入的流量通过该连接转发给正确的上游服务。这使得你的服务可以在任何地方运行，只要它们能够连接到 Pico 服务器即可。

端点与流量转发

• 端点：上游服务在特定的端点上监听流量。Pico 负责管理传入连接和请求，将其路由到监听目标端点的上游服务。如果多个上游监听同一端点，请求将在它们之间进行负载均衡。
• 端点无需静态配置：上游可以自由选择监听任何端点。
• 监听方式：
  • 使用 Piko Agent（支持 HTTP 和 TCP）。
  • 在应用程序中直接使用 Go SDK（通过标准 net.Listener）。

支持的协议

• HTTP(S)：Pico 充当透明的 HTTP(S) 反向代理。它通过请求的 Host 头部或 x-piko-endpoint 头部来确定目标端点。
  • 例如，使用 Host 头部时，foo.piko.example.com 会路由到端点 foo。
  • 也可以使用 x-piko-endpoint: foo 请求头来指定端点，从而避免配置通配域名。
• TCP：支持代理 TCP 流量。由于原始 TCP 连接无法标识目标端点，因此需要使用 Piko Forward 或 Go SDK 来将本地 TCP 端口映射到目标端点。
  • 例如，piko forward 3000 my-endpoint 会在本地监听 3000 端口，并将连接转发到端点 my-endpoint。

如何工作（集群模式） Pico 服务器以节点集群形式运行，以实现容错、水平扩展和零停机部署。关键机制如下：

• 当上游服务连接到某个节点（例如 Node N）并声明监听端点 E 时，Node N 会通知集群中的其他节点。
• 集群中任何节点收到针对端点 E 的传入流量，都会将其路由到 Node N，再由 Node N 转发给上游服务。
• 如果 Node N 失效，上游服务会重新连接到另一个节点，集群会更新路由信息。

可观察性 Pico 提供 Prometheus 端点、访问日志和状态 API，便于监控部署和调试问题。

部署与支持

• 设计为在 Kubernetes 上简单部署，支持渐进式发布。
• 社区支持通过 GitHub Discussions 进行。
• 项目采用 MIT 许可证。

Postgres 应用中的通知器模式

Postgres 的 LISTEN/NOTIFY 是一个强大但常被低效使用的功能。本文介绍了“通知器模式”，旨在优化其使用，减少连接消耗并处理故障场景。

基本概念与问题

LISTEN/NOTIFY 允许客户端订阅主题并接收来自其他客户端的消息。然而，在应用中直接使用存在以下问题：

• 每个订阅占用一个连接：朴素的实现中，每个监听主题都需要一个独立的 Postgres 连接，导致连接资源快速消耗。
• 忽视故障处理：缺乏对连接中断或订阅失败的有效管理。

通知器模式核心思想

该模式的目标是每个进程仅使用一个 Postgres 连接来处理所有 LISTEN/NOTIFY 操作。其关键优势在于：

• 连接最小化：无论应用中有多少组件订阅多少主题，都共享单一连接，极大节省连接资源。
• 集中管理：由一个“通知器”组件统一处理订阅、接收通知和分发消息。

实现关键细节

1. 订阅管理：

   • 订阅使用缓冲通道（如 make(chan string, 100)）和非阻塞发送，防止处理延迟拖累整个系统。
   • 多个组件订阅同一主题时，仅需执行一次 LISTEN，内部通过主题索引管理订阅列表。

2. 可中断接收：

   • 由于 WaitForNotification 是阻塞的，需要定期中断以处理新订阅。实现方式是为等待设置超时（如30秒），并通过取消函数立即中断以添加新订阅。

3. 连接健康与容错：

   • 健康监控至关重要，因为单连接故障会影响所有订阅。
   • 文章建议两种策略：尝试重新连接并恢复订阅，或采用“让它崩溃”策略——对于极罕见的连接不可恢复问题，直接重启程序。

4. PgBouncer 兼容性：

   • LISTEN 需要会话级连接池。通知器模式允许应用为 LISTEN/NOTIFY 专用一个会话连接，而其他部分可使用事务或语句级连接池，最大化连接效率。

总结

通知器模式通过共享连接、缓冲通知和智能连接管理，优化了 Postgres LISTEN/NOTIFY 在应用中的使用。它减少了连接开销，增强了系统健壮性，并兼容连接池解决方案，是处理实时通知的有效实践。

本文内容为一个名为 neuviemeporte 的个人技术博客简介。

• 博主声明其博客主要关注 16位系统逆向工程、编程中的古怪问题（WTFs） 以及 对IT行业的泛泛吐槽。
• 博客风格偏向个人日志与技术记录，邮箱地址为 neuviemeporte@outlook.com。

注：当前提供的文本未包含关于DOS游戏 “F-15 Strike Eagle II” 的具体逆向工程或重构的详细内容，仅呈现了博客的自我介绍部分。

本文探讨了在数据验证库中使用链表优化JSON路径跟踪性能的实践。核心目标是记录验证错误在输入JSON中的具体位置（如/location/country），同时最小化性能开销。

初始状态：库验证JSON输入是否符合Schema，但最初不跟踪路径。基准测试建立了性能基线。

优化过程：

1. 朴素Vec克隆：在递归验证时传递并克隆路径向量。此方法因频繁的堆内存分配和数据复制导致性能急剧下降，成为最差方案。
2. 复用可变Vec：改为传递一个可变向量引用，通过push和pop操作复用同一内存。性能相比克隆方案有显著提升，但仍有优化空间。
3. 链表方案：利用函数调用栈，将路径段存储在栈帧中，通过链表节点（JsonPointerNode）连接。仅在报告错误时（to_vec）才进行堆分配以收集完整路径。此方案对有效输入的验证速度提升巨大，因为正常验证路径无需任何堆分配。
4. 后续优化：
   • 精确内存分配：在to_vec中预先计算所需容量，避免动态向量的重新分配，进一步提升了无效输入场景的性能。
   • 避免临时Vec：直接构建目标类型（Vec<String>）而非先构建Vec<&str>再转换，减少了一次分配和拷贝。
   • 结构体大小优化：提及可通过移除Option包装来减小JsonPointerNode结构体的尺寸，从而降低栈操作开销。

结果：相较于基础方案（复用可变Vec），链表方案对有效和无效输入分别实现了约1.9倍和1.3倍的性能提升。最终的路径跟踪功能为无路径版本的验证增加了约18%（有效输入）和95%（无效输入）的时间开销。

核心结论：

• 选择合适的数据结构（此处为链表）可以利用栈内存，避免不必要的堆分配。
• 性能优化应从分析瓶颈开始，并通过基准测试驱动。
• 优化策略包括：复用内存、精确分配、减少数据拷贝和缩小频繁传递值的尺寸。

Pi-C.A.R.D：基于树莓派的本地语音助手

项目概述 Pi-C.A.R.D（Raspberry Pi – Camera Audio Recognition Device）是一个完全在树莓派上运行的AI语音助手项目。它旨在提供一个完全离线、本地运行的对话式AI体验，具备标准大语言模型（LLM）的对话能力。如果配备摄像头，助手还可以拍照、描述图像内容并回答相关问题。项目强调在低成本硬件上实现本地化运行的效率探索，目前仍处于积极开发中。

核心功能与工作原理

1. 启动对话：支持两种方式：
   • 唤醒词：运行main.py后，系统监听自定义唤醒词（默认为"raspberry"、"barry"、"razbear"）。触发后进入连续对话模式，无需重复唤醒词，直至说出“stop”、“exit”或“goodbye”等结束词。
   • 物理按钮：通过面包板和GPIO按钮启动对话或打断助手响应，被认为交互更顺畅。
2. 对话管理：助手具有可配置的短期对话记忆（可在config.py中调整），允许延续上下文或重复信息。
3. 工具集成：借助经过微调的BERT模型（tool-bert）判断何时调用外部工具服务，需在.env.example中配置相关密钥。
4. 视觉功能（当前暂停）：曾支持摄像头功能，可拍照并进行描述和问答。由于llama.cpp不再积极支持视觉模型，此功能被临时移除。配置时需将config.py中的vision_model设为vlm并下载Qwen2-VL-2B-Instruct模型。

技术栈与性能 为确保本地运行效率，项目优先采用C++实现的组件：

• 语音识别：使用whisper.cpp进行音频转录。
• 语言模型与视觉模型：使用llama.cpp加载和运行语言及视觉模型。
• 性能优化：通过缩小输入图像尺寸以加快视觉模型推理速度，并计划测试超频、优化whisper处理时间等以提升整体响应速度。

硬件要求

• 核心：树莓派5 Model B。
• 输入/输出：USB麦克风、扬声器。
• 可选：摄像头及专用摄像头连接器（适配树莓派5的新端口）、用于按钮交互的面包板、导线和按钮。

设置与部署

1. Docker（推荐）：可通过docker-compose build和docker-compose up命令在容器中运行，但目前仅支持唤醒词版本，GPIO按钮在容器内的访问可能存在问题。
2. 手动设置：需克隆whisper.cpp和llama.cpp仓库，并按照其指南完成模型下载与配置。将仓库路径添加到项目的config.py文件中。

开发路线图

• 已实现：基本对话、摄像头功能（暂时禁用）。
• 计划中：基准测试响应时间、测试超频、优化whisper速度、实现助手打断功能、使用定制化模型、改进教程与视频、优化外部服务模型（tool-bert）、测试便携电源、完善Docker化以支持更多设备、多语言测试、增加更多外部服务。项目使用Notion看板跟踪进度。

项目特点与目标 该项目定位为一个有趣的实验性助手，旨在探索在树莓派这类相对廉价硬件上实现完全离线AI助手的可行性与效率极限。作者认为，随着小型LLM模型的持续进步，项目的能力也将随之提升。项目鼓励社区参与，欢迎提交问题、合并请求或进行自己的修改。

标题： Snapdragon X Elite Linux Kernel 上游支持

描述： 文章介绍了高通 Snapdragon X Elite 处理器获得上游 Linux 内核支持的情况。主要内容聚焦于探索支持的关键领域，并指出了通过上游化支持为基于骁龙的 Linux 设备释放新潜力的可能性。

iPadOS系统基础问题总结

本文作者原计划评测新款iPad Pro硬件，但转而系统性地总结了其在长达12年的iPad使用中所遇到的iPadOS系统根本性缺陷。作者旨在为改进平台提供参考，澄清批评者并非只想在iPad上运行macOS，并为读者提供上下文以理解iPadOS的局限性。以下是文章概述的核心问题：

一、应用程序缺失与不完善

iPadOS长期缺乏一些基础原生应用，如计算器（直至iPadOS 18才计划添加）、TextEdit（简易文本编辑器）、Preview（强大的图片/PDF查看编辑工具）和Journal（日记应用）。此外，即使已有的“桌面级”应用，其实现也远不如macOS版本，功能严重缩水。例如：

• 邮件不支持智能邮箱。
• Safari无法像Mac版那样自定义工具栏。
• 快捷指令在iPad上不支持窗口控制，与Mac版功能脱节。
• 文件应用缺乏智能文件夹功能。

二、文件应用是根本性缺陷

作者将Files应用（文件管理器）评为一个设计拙劣、性能糟糕的产品，需要彻底重构。主要问题包括：

• 不可靠且缓慢：复制、移动操作常卡顿或失败，尤其是大文件和外接驱动器。
• 与Mac的Finder相比功能残缺：不显示传输速度、不支持可自定义的快速操作、无法与快捷指令集成以操作当前所选文件。
• 集成问题：对iCloud Drive的缓存清理过于激进，导致文件时而不可用。
• 无法设置默认应用：这是最荒谬的限制，用户无法指定用哪个应用打开特定文件类型，所有文件默认使用Quick Look预览。

三、音频系统的多重限制

iPadOS的音频子系统存在两个根本性问题：

1. 无法同时播放多个音频流：例如，无法在静音看视频的同时播放音乐。
2. 无法在VoIP通话时录制本地音频：这严重影响了播客录制等工作流程，因为无法同时录制麦克风音频和通话。

四、多任务处理：不一致且功能不全

iPadOS的多任务界面历经多次（2-3年一次）彻底重做却从未完善，是“不均衡发展”的典型。最新的Stage Manager虽经修复但仍问题重重：

• 硬性限制最多同时显示4个窗口（Mac版无此限制）。
• 无法保存常用的窗口组合预设。
• 存在窗口激活焦点错误、键盘输入错乱的bug。
• 缺乏系统级的快速创建新窗口或预览当前工作区所有窗口的快捷方式。 作者对比了Android折叠屏手机更先进的多任务UI，认为苹果有能力做得更好，但iPadOS的实现远未达到“专业”水准。

五、Spotlight搜索不可靠且无法替换

iPadOS的Spotlight搜索存在性能慢、结果不一致的问题，常找不到已知存在的应用或文件。有时还会卡住，无法响应键盘输入。最关键的是，系统不允许安装第三方Spotlight替代品（如Mac上的Raycast、Alfred），用户只能忍受这个不完善的启动器。

六、缺乏真正的后台进程与系统工具

iPadOS至今不支持长时间运行的后台复杂任务。即使是苹果自己的Final Cut Pro导出视频，只要切换应用或误触通知，任务就会立即取消。这导致：

• 阻止了专业类应用（如视频编码器、自动化工具、AI照片编辑器）在iPad上实现完整功能。
• 系统级的实用工具（如剪贴板管理器、快速捕获窗口、自定义表情选择器）无法存在。
• 应用大多仍是iPhone应用的放大版，未能充分利用iPad的性能和屏幕。

七、其他累积性低效问题

作者列举了众多“小事累积成大问题”的例子：

• 缺乏备份工具：没有类似Time Machine的备份方案，也没有第三方备份API，专业用户只能依赖iCloud或手动备份。
• 无法以“合盖模式”使用：连接外接显示器时，iPad必须保持打开和解锁状态，无法合盖将外接显示器作为主屏使用。
• 主屏幕布局仍不自由。
• 浮动键盘按钮常遮挡输入。
• Magic键盘指针偶尔卡死需重启。

八、结论与期望

作者重申热爱iPad，正是其模块化、触控与键盘结合的体验吸引了他。他撰写本文并非希望在iPad上运行macOS，而是因为iPadOS在基础计算任务上仍未达标，其软件的发展速度完全跟不上卓越的硬件。他批评了那些为iPadOS缺陷辩护的声音，并感到厌倦于“硬件很好，但软件……”这个循环。作者希望苹果能正视问题，从根本上改进iPadOS，否则将浪费其创造的最佳计算机形态的潜力。

Unitree G1 人形机器人摘要

核心规格

• 机械尺寸：包含站立与折叠状态的高度、宽度及厚度参数。
• 自由度：
  • 全身总自由度：未具体列出，但涵盖腿部、腰部、手臂及手部。
  • 单腿：基础自由度 + 可选增加2个腰部自由度。
  • 单臂：7个自由度（可选三指灵巧手力控）+ 2个可选腕部自由度。
  • 手部：采用 Dex3-1 三指灵巧手，拇指3个主动自由度，食指和中指各2个主动自由度；可选配触觉传感器阵列。
• 关节运动范围（示例）：
  • 腰关节：Z轴 ±155°；髋关节：P轴 ±154°、R轴 -30°+170°、Y轴 ±158°；膝关节：0°165°；腕关节：P/Y轴 ±92.5°（具体范围因关节和配置而异）。

关键技术与性能

• 核心部件：
  • 采用工业级交叉滚子轴承（高精度、高负载）。
  • 驱动电机为低惯量高速内转子永磁同步电机（响应快、散热好）。
• 动力：全身关节最大扭矩各异，以膝关节为例（数据待确认），且强调动力强劲。
• 电气特性：
  • 全关节中空电气走线。
  • 供电为13串锂电池。
  • 计算核心为8核高性能CPU。

主要配件

• 高算力模块。
• 智能电池（支持快拆）。

重要说明与提醒

1. 参数与配置：以上参数可能因场景和配置不同而变化，以实际为准。
2. 产品状态：
   • 产品外观可能变更，以最终产品为准。
   • 部分展示功能仍在开发测试中，未来开放。
3. 行业与使用警告：
   • 全球人形机器人产业处于早期探索阶段，强烈建议个人用户在购买前充分了解其局限性。
   • 该产品为民用机器人，严禁进行任何危险改装或用于危险场景。
   • 机器人结构复杂且动力强大，务必与人保持充足安全距离，谨慎使用。
4. 法律与合规：用户需遵守宇树科技官网的相关条款政策及所在地法律法规。价格不含税和运费。
5. 详细文档：更多信息（如二次开发、保修条款）请参阅专用手册。

Claude 已登陆欧洲

Anthropic 宣布其AI助手 Claude 现已面向欧洲地区用户开放，旨在提升个人与企业的生产力和创造力。

可用产品与服务

• Claude.ai：基于网页的下一代AI助手。
• Claude iOS应用：提供免费版本，体验与移动端网页一致。
• Claude Team计划：为企业团队提供安全访问Claude先进AI能力及Claude 3模型家族的最佳方案。

此次发布延续了今年早些时候在欧洲推出的Claude API，后者允许开发者将Anthropic的AI模型集成到自己的应用、网站或服务中。

语言与使用体验

Claude 能够流畅地理解和使用法语、德语、西班牙语、意大利语等多种欧洲语言，支持用户用多种语言进行交流。其直观、用户友好的界面便于任何人将先进的AI模型无缝整合到工作流程中。

定价与订阅

• 免费版：Claude.ai和Claude iOS应用均可免费使用。
• Claude Pro：月费18欧元（含增值税，或当地货币等价），可解锁所有模型，包括市场领先的Claude 3 Opus模型。
• Team计划：每用户每月28欧元（含增值税，或当地货币等价），最低需购买5个席位。

Anthropic表示致力于打造以人为本的AI系统，并期待将Claude 3模型家族的独特能力带给更多欧洲用户。

本文支持以法语、德语、意大利语或西班牙语阅读。

研究发现贝多芬头发中铅、汞、砷含量高

研究人员在德国作曲家路德维希·凡·贝多芬的头发中发现了高浓度的铅、砷和汞，这可能为他的部分健康问题提供了线索。这项研究以信件形式发表于《临床化学》杂志。

• 研究发现： 对两束经鉴定的贝多芬头发样本分析显示，其铅含量分别为380微克/克和258微克/克，而正常水平约为4微克/克或更低。砷含量是正常水平的13倍，汞含量是正常水平的4倍。研究人员指出，如此高的铅含量水平“是我见过最高的”，并认为这很可能加剧了他的胃肠道问题和耳聋。
• 铅的可能来源： 研究者提出了几种可能的解释。贝多芬爱喝葡萄酒，而当时廉价葡萄酒中常添加有甜味的醋酸铅以降低酸度和澄清。葡萄酒的生产过程（如使用铅焊接的器皿、用铅盐处理的软木塞）以及贝多芬可能使用的铅玻璃杯也会增加铅摄入。此外，他使用的许多药膏和药物（一度多达75种）可能含铅，他常吃的多瑙河受污染鱼类也是潜在来源。
• 研究局限与补充： 研究承认一个局限性：头发中的铅含量是否及如何准确反映血液中的铅水平尚不确定。外部污染或个人特质（如发色）可能影响检测。但研究人员表示，如此高的头发铅浓度已被证明与肾脏和肝脏疾病相关，且他们在测试前已采取最佳实践去除可能的外部污染物。这项新发现建立在2023年一项DNA研究的基础上，该研究揭示了贝多芬有肝病遗传倾向和乙肝感染。重金属研究为理解其健康问题增添了新的层面。
• 历史背景： 贝多芬本人饱受疾病困扰，并曾在1802年请求医生在他死后研究其疾病和耳聋的原因。研究者认为，这些发现是拼图中的重要一块，有助于历史学家、医生和科学家更好地理解这位伟大作曲家的病史。贝多芬的才华与其无法亲耳聆听自己所作壮丽音乐的悲剧，继续引发公众的浓厚兴趣。

摘要

文章标题揭示，Discord公司正在采用机器学习（ML）技术来识别和确定其部分用户的性别与年龄。这一做法可能涉及用户数据分析以推断人口统计信息，但具体技术细节、应用场景或隐私影响未在提供内容中详细说明。

文章内容部分仅显示为一个错误提示信息，表明在访问x.com时出现了技术问题，可能与隐私相关浏览器扩展有关，建议用户禁用扩展后重试。该内容与标题主题无关，未提供关于Discord使用ML的进一步信息，如实施方式、用户数据来源、伦理考虑或相关调查结果。

基于现有内容，无法评估Discord ML实践的具体范围、目的或潜在后果，且文章正文缺失，导致关键细节不足。

Dockerfile中ARG指令的使用陷阱

核心问题

在Dockerfile中，ARG指令定义的变量与FROM指令存在特殊关系，导致在FROM之后的构建阶段无法访问FROM之前声明的ARG变量，即使这些变量在FROM指令中被使用。

问题示例

以下简化的Dockerfile展示了此问题：

ARG DEBVER="10"
ARG CAPVER="7.8"
FROM debian:${DEBVER}

RUN printf "DEB=${DEBVER}\nCAP=${CAPVER}\n" > /tmp/log

构建后检查容器内/tmp/log文件，发现变量值为空：

• 即使未通过--build-arg指定值，变量也为空
• 即使通过--build-arg指定了值（如DEBVER=11和CAPVER=7.9），FROM指令能正确使用DEBVER（容器基于Debian 11），但后续RUN指令中两个变量均为空

原因分析

Docker官方文档在FROM指令参考部分说明：

"在FROM之前声明的ARG位于构建阶段之外，因此不能在FROM之后的任何指令中使用。"

这意味着在FROM之前声明的ARG变量仅在FROM指令本身中有效，不能在后续构建步骤中引用。

解决方案

修改Dockerfile结构，将需要在FROM之后使用的ARG变量声明移到FROM之后：

# syntax=docker/dockerfile:1

ARG DEBVER="10"
FROM debian:${DEBVER}
ARG DEBVER          # 重新声明以在后续步骤中使用
ARG CAPVER="7.8"    # 在FROM之后声明

RUN printf "DEB=${DEBVER}\nCAP=${CAPVER}\n" > /tmp/log

此修改确保：

1. DEBVER在FROM指令中可用，并在后续步骤中通过重新声明也可用
2. CAPVER直接在FROM之后声明，在整个构建阶段有效

验证结果

使用修改后的Dockerfile构建：

• 默认构建：变量值为DEB=10、CAP=7.8
• 使用--build-arg指定值：变量值正确更新为DEB=11、CAP=7.9

结论

在Dockerfile中使用ARG时需注意：

1. 在FROM之前声明的ARG仅可用于FROM指令本身
2. 若变量需要在FROM之后的构建步骤中使用，必须在FROM之后重新声明或首次声明
3. 这一行为容易被忽略，因为ARG看起来像常规变量，但实际作用域受FROM指令限制

文章探讨了软件的本质，提出了三个相互关联的关键因素：

1. 软件处于临界状态：软件介于物理世界的硬约束（如有限的内存、CPU速度）和幻想世界的“软约束”之间。开发者需要人为添加软约束（如限制输入文件数量）来简化问题，但这些约束的合理性难以量化，且常受到继承的约束（如库或操作系统的影响）、对问题领域的不完全理解以及历史偶然性的影响。区分真正的硬约束和可调整的软约束对软件开发至关重要。

2. 循环规范问题：明确软件需求往往需要先构建软件，因为抽象规范通常与构建软件本身一样复杂，甚至更复杂。这使得软件开发同时成为需求定义的过程，导致误解和沟通困难。尽管通过将软件类别封装为库或领域特定语言可以提高规范的清晰度，但对定制软件的需求也在同步增长，使得规范能力与软件目标之间可能始终存在差距。此外，非功能性需求（如性能、内存使用）往往难以明确规范。

3. 观察者效应：软件投入使用后，开发者或用户对软件的期望会因实际观察而改变。用户可能以开发者未预料的方式使用软件，导致需求变更。组织中程序员与用户之间的距离会加剧这一效应。忽视观察者效应或试图通过拒绝变更来避免额外工作，通常会导致糟糕的软件结果。

这三个因素相互影响：循环规范问题为观察者效应创造了机会，观察者效应也可能引发循环规范问题。理解这些因素有助于改善软件开发中的沟通与规划，例如通过区分硬约束和软约束、接受迭代开发中的摩擦、以及重视用户实际观察等方式。最终，作者希望通过明确这些深层因素，促进对软件挑战的更深入讨论。

Deblur-GS：从运动模糊图像重建清晰3D高斯场景

本文介绍了 Deblur-GS，这是一种利用3D高斯溅射技术，从相机运动模糊的图像中重建出清晰、锐利的三维高斯场景的新方法。

该技术的核心目标是直接处理因相机运动导致图像模糊的输入，并输出一个细节丰富的3D高斯场景表示。这避免了传统流程中可能需要预先进行图像去模糊的步骤，或对模糊图像进行显式建模的需求。

基本背景

• 论文标题：Deblur-GS: 3D Gaussian Splatting from Camera Motion Blurred Images
• 作者：Wenbo Chen, Ligang Liu
• 发表信息：该论文发表于2024年的交互式3D图形技术会议（I3D 2024），收录于《ACM计算机图形与交互技术会刊》。
• 出版信息：由ACM Press出版，会议于美国宾夕法尼亚州费城举行。

这项工作将计算机图形学中的高质量实时渲染技术（3D Gaussian Splatting）与运动模糊这一常见的图像退化问题相结合，旨在从退化的观测中直接恢复高质量的3D表示。

Fugaku-LLM 发布摘要

核心成果

由东京工业大学、东北大学、富士通、理化学研究所、名古屋大学、CyberAgent和Kotoba Technologies组成的日本团队，基于日本旗舰超级计算机 Fugaku 成功开发并发布了具有增强日语能力的大型语言模型 Fugaku-LLM。

模型特点

• 参数与规模：拥有 130亿参数，大于日本广泛开发的70亿参数模型，在性能与资源需求间取得较好平衡。
• 日语能力优化：在日本MT-Bench基准测试中平均得分 5.5，在使用日本原创数据训练的开源模型中性能最高；尤其在人文与社会科学任务中得分高达 9.18。
• 训练数据与方法：使用CyberAgent提供的专有日语数据，结合英语、数学和代码等数据，从零开始训练（非持续学习），共训练 3800亿 token。约60%的训练数据为日语，确保了模型对日语（包括敬语等特性）的深度理解。
• 开源与许可：源代码在GitHub公开，模型在Hugging Face发布，允许研究和商业用途（需遵守许可协议）。

关键技术创新

为充分利用Fugaku（使用富士通生产的CPU而非GPU），团队进行了多项优化：

1. 计算性能提升：将深度学习框架 Megatron-DeepSpeed 移植到Fugaku，并针对Transformer加速了密集矩阵乘法库，使计算速度提升 6倍。
2. 通信性能优化：结合三种并行化技术（优化通信性能）并加速了 Tofu interconnect D 上的集体通信，使通信速度提升 3倍。
3. 分布式训练：使用Fugaku的 13,824个节点 进行大规模分布式训练，解决了GPU全球短缺下利用CPU超算训练大模型的挑战。

意义与前景

• 技术意义：证明了在非GPU架构的Fugaku上训练大模型的可行性，为日本半导体技术复兴和下一代计算基础设施设计提供了宝贵经验。
• 应用前景：模型开源将促进更多研究者参与改进，推动创新应用发展，例如：
  • 科学模拟与生成式AI的结合（AI for Science）
  • 包含数千个AI的虚拟社区社会模拟
• 产业合作：各参与机构分工明确，共同推动了日本本土大语言模型的发展，以应对全球AI竞赛。

未来计划

研究团队将公开研究结果，鼓励社区进一步开发。Fugaku-LLM自2024年5月10日起也通过富士通研究门户向用户提供。

根据提供的内容，无法生成实质性摘要。所提供的文本仅包含网站页脚信息，包括版权信息、项目支持方、社交媒体链接和新闻订阅提示，但未包含与文章标题“New work extends the thermodynamic theory of computation”相关的任何实质内容、论述或数据。因此，无法基于给定内容总结出主要观点或关键细节。

文章摘要：《在数秒内推导整个x86-64指令集》

本文介绍了一种创新的方法，利用现代Intel处理器的投机执行（speculative execution）机制和硬件性能计数器，快速、安全地发现并分析几乎全部的x86-64指令集，包括未公开的指令。整个过程仅需数秒。

核心方法与原理

1. 微架构基础：
   • 指令解码由微指令翻译引擎（MITE） 处理简单指令，微代码序列器（MS） 处理复杂指令。
   • 利用Intel性能计数器MITE.UOPS（MITS）和MS.UOPS（MS），可以区分指令是由MITE还是MS解码，从而推断其复杂性和特性。
2. 投机执行作为安全探针：
   • 直接执行未知指令风险极高（可能导致系统重置、修改关键状态等）。
   • 方法的核心是让目标指令在投机路径上执行，但在架构层面通过后续控制流反转使其效果被撤销。具体实现是通过一个精心构造的CALL指令序列，使目标指令在子程序调用返回前被投机执行。
3. 精确的数据收集：
   • 为避免中断干扰，通过循环检测IA32_MSR_SMI_COUNT并重试来确保测量过程未受系统管理中断（SMI）影响。
   • 在每次测量前，通过使缓存失效（CLFLUSH）和内存屏障（SFENCE）来清除译码流缓冲区（DSB/iCache） 的影响，确保指令每次都由MITE/MS重新解码。

实验过程与数据处理

1. 测试流程：
   • 对大量可能的指令编码（包括各种前缀0x0F, 0x66, 0xF2, 0xF3和后缀）进行测试。
   • 每条指令后跟15个NOP和一个必定引发#UD异常的0xCE字节，以终止投机执行并提供基准。
   • 通过测量MITS和MS计数器的值，记录每条指令的微指令解码情况。
2. 结果缩减：
   • 通过对比基线（仅NOP和仅#UD）的计数器值，初步过滤掉无效结果。
   • 识别并移除冗余前缀（如0x66、0xF2对指令行为无影响时）和冗余后缀，将数万条候选结果精简至约1700条，这些是真正具有独立行为的指令或指令变体。

行为推导与关键发现

基于简化的计数器值，可以推断指令的诸多行为：

1. 序列化与投机屏障：
   • 如果指令的MS值低于NOP基准，表明其中断了控制流（如分支或异常）。
   • 结合MITS值，可判断指令是否是序列化指令（serializing）或是否构成投机屏障（speculation fence）。例如，mov ss和int3既是序列化指令也是投机屏障，而cli则不是。
2. 投机执行能力：
   • 通过在投机路径中插入一个不会在正常路径执行的除法指令（divps），并检查其计数器是否非零，可以判断哪些指令允许后续指令继续投机执行（“投机友好”）。
   • 结果发现，像xchg, loopne, bsf, cld等指令是投机友好的，而insb, ret, hlt, mov ss等则会阻止投机执行。

有趣的指令级发现

1. 未记录的指令：作者在其i7-6850K处理器上发现了一系列未公开的“彩蛋”指令。
2. 特定指令行为分析：
   • mov cr2, reg 并非序列化指令，而 mov cr3, reg 和 mov cr0, reg 是序列化的。
   • int1 比 int3 和 int imm8 在微代码中可能包含更多逻辑。
   • lss 是投机屏障，而 lgs 不是。
   • 一些通常认为敏感的操作（如读取CR3, CR0，执行rdtsc）在投机路径上是可以执行的，这可能对侧信道安全有影响。

总结

该方法巧妙利用了处理器的推测执行特性，结合性能计数器，实现了一种非侵入性、快速且全面的指令集探测与分析技术。它不仅可用于发现未记录指令，更能深入揭示微架构级别的指令行为特性，对处理器安全研究和逆向工程具有重要价值。