美国政府正在权衡是否在一项具有里程碑意义的反垄断案件中拆分谷歌。此举针对这家科技巨头的市场主导地位，可能对全球科技行业格局产生深远影响。该案件是美国监管机构应对大型科技公司垄断问题的重要举措之一。

内容描述了一个网站或服务出现错误的情况，并提供了简单的故障排除建议。主要点包括：发生了一个未指定的问题；一些隐私相关的扩展程序可能导致在x.com平台上出现兼容性或加载问题；建议用户禁用这些扩展程序后重试操作，以尝试解决问题。整体内容简洁，聚焦于技术问题和用户操作指导。

Transmit 将移除 Google Drive 支持

Panic 公司宣布，其文件传输应用 Transmit 及其新应用 Nova 将在未来的更新中移除创建 Google Drive 连接的功能。现有已认证的连接在失效前将继续可用，其他连接类型不受影响。

移除原因：无法持续满足 Google 的新政策要求

决策源于 Google 针对访问用户 Google Drive 文件的应用推出的新安全审查政策。该政策要求应用必须通过昂贵且耗时的年度安全审查，这对小型独立开发商 Panic 而言难以维持。

审查过程的具体困难：

1. 流程漫长且反复：自2019年起，Google 加强了审查，Transmit 的访问权曾一度被暂停。尽管在2020年通过审查恢复了访问，但过程极其缓慢。
2. 2023年底审查升级：Google 要求 Transmit 通过“云应用安全评估 (CASA)”审查。此次审查虽未发现安全漏洞，但耗时近一个月，给工程师带来了巨大负担。
3. 审查成本剧增：2024年3月，Google 再次更改要求，取消了开发者自行扫描代码的选项，强制要求由 Google 认证的商业合作伙伴进行付费审查。费用高昂且无上限，对 Panic 这样的小公司构成显著经济压力。

最终决定与展望

考虑到审查流程的不稳定性、高昂的时间和金钱成本，以及第三方工作区方案可能使用户账号面临风险，Panic 决定放弃续期 Google Drive 访问权限。公司将继续专注于 Transmit 和其他产品的其他功能开发。如果 Google 未来调整政策使其更易于小型开发商遵守，Panic 将重新评估支持 Google Drive 的可能性。

公司对由此给用户带来的不便表示歉意。

攻击概述

ESET研究人员发现一个针对欧洲政府组织的网络攻击活动，攻击者通过自定义工具成功入侵了物理隔离（气隙）系统。该活动由网络间谍组织GoldenJackal发起，时间跨度从2022年5月持续至2024年3月。研究还追溯到该组织2019年对白俄罗斯一处南亚大使馆的类似攻击。

攻击者画像：GoldenJackal

• 活跃时间：至少自2019年起。
• 目标领域：主要针对欧洲、中东和南亚的政府及外交机构。
• 知名工具：已知其使用C#编写的间谍工具集，包括JackalControl（后门）、JackalSteal（文件窃取）、JackalWorm（USB传播）等。

攻击目标

1. 欧洲联盟某国政府组织：2022年5月至2024年3月间被反复攻击。
2. 白俄罗斯南亚大使馆：2019年8月及2021年7月被攻击。
3. 中东和南亚的其他政府与外交实体（卡巴斯基此前报告）。

核心攻击手法：突破气隙隔离

为攻击通常不联网的高价值气隙系统，GoldenJackal开发了两套专用工具集，利用USB驱动器作为数据桥梁。

第一套工具集（2019年攻击使用）

• GoldenDealer：核心组件。监控USB插入，在气隙PC和联网PC间传递可执行文件和窃取的数据。
• GoldenHowl：模块化后门（Python编写），功能包括文件列表、文件窃取、SSH隧道、网络扫描等。
• GoldenRobo：文件收集器，自动复制指定格式的文档并通过C&C服务器窃取。

第二套工具集（2022-2024年攻击使用）

攻击手法高度模块化，组件分工明确：

• 收集组件：
  • GoldenUsbCopy：监控USB插入，根据配置窃取特定类型文件并加密暂存。
  • GoldenUsbGo：类似GoldenUsbCopy的简化版，针对特定受害者定制。
• 传播组件：
  • GoldenAce：通过USB驱动器传播恶意负载（轻量版JackalWorm）并回收暂存数据。
• 处理组件：
  • GoldenBlacklist / GoldenPyBlacklist：处理收集的电子邮件附件，过滤出有价值内容。
• 窃取组件：
  • GoldenMailer：通过Outlook SMTP服务器以邮件附件形式窃取文件。
  • GoldenDrive：将文件上传至Google Drive窃取。

技术要点

• C2通信：主要使用自建服务器（如83.24.9[.]124），部分攻击利用了被入侵的合法网站。
• 规避技术：广泛使用加密（XOR、Fernet、AES）、文件隐藏、伪装（如使用文件夹图标）、删除痕迹。
• 归因线索：GoldenHowl的C2协议命名为“transport_http”，此命名惯例与Turla等组织有关，可能指向俄语背景开发者。

结论

GoldenJackal是一个资源充足、技术熟练的威胁行为者，能在五年内成功构建并部署两套专门用于突破物理隔离网络的工具集，显示其对高价值目标持续的间谍企图和适应能力。

更多信息与入侵指标（IoCs）请参阅原始报告。

这篇文章介绍了如何利用可微分自动机近似地“反向演化”康威生命游戏（Conway's Game of Life）的配置。

核心思想
直接精确反转生命游戏配置（称为“祖先搜索”）是一个计算上不可行的离散搜索问题。作者将问题转化为一个连续的优化问题，利用梯度下降来寻找一个初始配置，使其经过一步生命游戏演化后，能接近目标图像（如康威的肖像）。

可微分生命游戏
生命游戏原本基于离散规则，不可微。作者将其转化为连续版本：

1. 将细胞状态视为0（死亡）到1（存活）之间的实数。
2. 细胞的邻居数可通过卷积计算。
3. 用窄高斯函数近似原始的生死规则（例如，用中心在2.5和3附近的高斯函数分别近似“存活”和“诞生”条件）。
4. 通过线性插值和双曲正切（tanh）函数将输出约束在[0, 1]区间，从而得到一个可微分的单步演化函数。

优化过程
使用PyTorch实现该可微分函数，并随机初始化一个初始配置（b）。计算b经过一步演化后的结果（b'），计算b'与目标图像t之间的误差（例如，绝对差值之和）。然后，对该误差关于b求导，并使用梯度下降法更新b，以使演化结果逐步接近目标图像。

实验结果与观察
作者以白色矩形为目标图像进行实验，几秒钟内梯度下降过程开始学习。优化过程中初始配置演变出复杂、迷宫般的图案。作者将这些图案与大河豚鱼皮肤上的斑纹相类比，推测其形成可能与对称性破缺有关，并联想到图灵（Alan Turing）提出的反应扩散模型及其图灵斑图，暗示了生命游戏这类细胞自动机与生物形态发生之间的潜在联系。

总结
该方法避免了传统祖先搜索的计算爆炸问题，通过可微分近似和梯度下降，将离散的逆向问题转化为易于优化的连续问题，并在实践中展示了其可行性与有趣的图案生成结果。作者提供了相关的Python程序代码供进一步探索。

两套前所未见的工具来自同一组织，用于感染气隙设备

安全研究人员发现了一个可能是来自俄罗斯的国家级黑客组织 GoldenJackal，在过去五年中开发并部署了两套独立的复杂工具集，专门用于窃取存储在气隙设备上的敏感数据。气隙设备是指刻意与互联网或其他网络隔离，以防止恶意软件感染的设备。

主要发现与攻击目标

• ESET 安全公司发现了这两套工具。其中一套自 2019 年起被用于攻击白俄罗斯的一个南亚大使馆。
• 三年后（2022年），该组织使用了另一套大致不同的工具集，感染了欧盟的一个政府组织。
• 根据工具组件的重叠情况，ESET 认定这些攻击均与 GoldenJackal 组织有关，该组织去年曾被另一家安全公司卡巴斯基披露。

工具演进与攻击流程

第一代工具（2019年）

攻击流程大致如下：

1. 首先通过未知方式感染一台联网设备。
2. 被感染的计算机会感染任何插入的外部USB驱动器。
3. 当受感染的驱动器被插入气隙系统时，会收集并存储感兴趣的数据。
4. 最后，当该驱动器再次插入联网设备时，数据会传输到攻击者控制的服务器。

第一代工具提供了一套完整功能，包括：

• GoldenDealer：通过USB驱动器向气隙系统传送恶意可执行文件。
• GoldenHowl：一个包含多种模块的后门，具备多种恶意功能。
• GoldenRobo：一个文件收集器和数据渗出工具。

第二代工具（2022年）

在攻击欧盟政府组织时，GoldenJackal 开始使用一套新的定制工具包。新方法更具模块化和专业化：

• 工具使用 Go、Python 等多种编程语言编写。
• 不同类型的受感染设备被分配执行不同的任务，例如有些用于渗出文件，有些用作本地服务器来接收和分发文件，还有些专门用于收集间谍文件。
• 新工具集包含大量模块，可以根据目标情况混合搭配，提高了灵活性和隐蔽性。如果某个模块被检测到，攻击仍能持续。

新工具包的主要组件包括：

• GoldenUsbCopy：监控USB驱动器插入，并将文件复制到加密容器。
• GoldenUsbGo：GoldenUsbCopy的升级版本。
• GoldenAce：用于传播其他恶意可执行文件并从USB驱动器检索文件的分发工具。
• GoldenBlacklist / GoldenPyBlacklist：下载加密档案，筛选感兴趣（例如邮件中的）信息并打包。
• GoldenMailer：将窃取自气隙设备的文件附加到电子邮件中，发送至攻击者邮箱进行渗出。
• GoldenDrive：将文件上传到Google Drive进行渗出的单独工具。

威胁归属与背景

• 研究人员尚未最终确定GoldenJackal所属的具体国家，但发现了一些线索。GoldenHowl 中使用了一个名为 transport_http 的命令与控制协议，该协议同样存在于已知为俄罗斯联邦安全局（FSB）工作的黑客组织 Turla 的恶意软件中。
• 其高度模块化的方法也被认为与2013年发现的、针对全球数十个国家的复杂间谍平台 Red October 有相似之处。
• 卡巴斯基此前记录了该组织攻击中东国家，ESET的新发现则显示其目标已扩展到欧洲。

总结

GoldenJackal 是极少数能够成功开发并部署针对气隙系统专用攻击工具的威胁组织之一。在五年内开发出两套此类工具，凸显了该组织的资源丰富性和技术持续进化。最新工具集通过高度模块化的设计、多语言编写和多种数据渗出机制，旨在尽可能保持隐蔽并适应各种复杂环境，以窃取极难获取的敏感数据。这些发现对于负责保护大使馆、政府机构及其他高价值目标的安全人员具有重要参考价值。

boring：一个轻量级 SSH 隧道管理器
用 Go 语言编写的简单命令行工具，用于高效管理 SSH 隧道。

核心功能

• 轻量快速：资源占用低，启动迅速。
• 多样转发：支持本地、远程及动态（SOCKS5）端口转发。
• 配置兼容：可读取 SSH 配置文件及 ssh-agent，支持 Unix 套接字。
• 稳定连接：具备自动重连与保活机制。
• 灵活配置：使用人类可读的 TOML 格式配置文件。
• 跨平台支持：适用于 macOS、Windows 和 Linux。
• 智能补全：为 Bash、Zsh 和 Fish 提供命令补全。

使用方法

• 列出隧道：boring list
• 打开隧道：boring open（可匹配名称模式或分组）
• 关闭隧道：boring close
• 编辑配置：boring edit

配置详解

• 配置文件默认路径：macOS/Windows 为 ~/.boring.toml，Linux 为 $XDG_CONFIG_HOME/boring/.boring.toml。可通过环境变量 $BORING_CONFIG 自定义。
• 隧道参数包括：
  • name：隧道别名（必需）
  • local/remote：本地与远程地址（支持网络地址或 Unix 套接字）
  • host：SSH 主机别名或实际主机名（必需）
  • mode：转发模式（local/remote/socks/socks-remote，默认为 local）
  • user/identity/port：SSH 连接参数（可省略，自动读取配置）
  • group：分组管理，便于批量操作
  • keep_alive：保活间隔（默认 120 秒）

环境变量控制

• $BORING_CONFIG：配置文件路径
• $BORING_LOG_FILE：日志文件位置（默认 /tmp/boringd.log）
• $BORING_SOCK：套接字位置（默认 /tmp/boringd.sock）
• $DEBUG：启用详细日志

安装方式

• Homebrew 安装：brew install boring
• 预构建二进制：从发布页面下载后放入系统路径。
• 源码构建：克隆仓库后执行 make（Windows 需使用 build_win.bat）。

Shell 补全配置
若通过 Homebrew 安装通常自动启用，否则需在 Shell 配置中添加：

• Bash：eval "$(boring --shell bash)"
• Zsh：source <(boring --shell zsh)"
• Fish：boring --shell fish | source

项目链接

• 源码仓库：github.com/alebeck/boring
• Go 文档：pkg.go.dev/github.com/alebeck/boring
• 测试覆盖率：Coveralls

文章标题：My first game with Carimbo, my homemade engine
文章发布日期：2024年10月8日
视频链接：https://youtu.be/nVRzCstyspQ

作者决定重启自制游戏引擎（Carimbo）的开发工作，并为儿子制作了一款游戏。作者选择从零编写所有内容，认为自制代码如同自制意面，更具乐趣，这让他回忆起父亲为自己手工制作玩具的童年。游戏可通过浏览器（借助WebAssembly技术）运行，玩家使用A和D键移动，空格键射击。游戏美术由Aline Cardoso（@yuugenpixie）设计。游戏源代码与引擎源代码均已公开。

技术实现概要：

• 引擎与脚本：引擎使用C++17编写，游戏逻辑完全由Lua脚本实现。引擎将基本功能暴露给Lua虚拟机，由Lua协调整个游戏。
• 引擎初始化：通过EngineFactory设置标题、分辨率等参数创建引擎实例。
• 资源管理：采用懒加载（lazy loading）策略进行资源预取，避免影响游戏主循环。
• 实体与消息系统：借鉴Erlang语言的“邮局服务”概念，实现了一种实体间的消息传递机制。例如，子弹在碰撞章鱼时会发送“命中”消息，章鱼接收消息后更新状态。
• 对象池：为优化资源管理，实现了对象池（最多3颗子弹），子弹击中目标后会被回收重置位置并返回池中。
• 游戏逻辑：
  • 每帧通过on_update回调更新实体状态。
  • 章鱼实体接收“命中”消息后，会触发动画、切换至攻击模式并减少生命值。生命值归零时，播放死亡动画并延迟3秒后销毁所有游戏实体、清理资源、切换到游戏结束场景并触发垃圾回收。
  • 玩家实体根据键盘输入（左/右方向键）设置速度和动画（移动或待机），按下空格键时从子弹池中取出子弹，在玩家附近随机位置发射并播放音效。

趣味结尾：作者的儿子对游戏提出了一些修改要求，例如将射击的子弹改为公主精灵，射击目标改为玩家，而射击者改为绿色章鱼。

2024年诺贝尔化学奖由瑞典皇家科学院授予，奖项一半颁给美国华盛亚大学及霍华德·休斯医学研究所的大卫·贝克（David Baker），表彰其在“计算蛋白质设计”领域的贡献；另一半由谷歌DeepMind的Demis Hassabis及John Jumper共享，表彰其在“蛋白质结构预测”方面的成就。

蛋白质是生命的关键化学工具，驱动并调控所有生命化学反应，同时也是激素、信号分子、抗体及各种组织的基本组成部分。蛋白质通常由20种不同的氨基酸组成，这些氨基酸长链通过折叠形成复杂的三维结构，决定蛋白质功能。蛋白质的多样性和精巧结构是生命现象赖以存在的基础。

贝克于2003年首次使用氨基酸“积木”创造出一种完全不同于所有已知蛋白质的新型蛋白。这一突破开启了计算设计全新蛋白质的时代，此后其研究团队相继生成创新蛋白质，包括可用于药物、疫苗、纳米材料和微型传感器。

自1970年代以来，科学界一直致力于从氨基酸序列预测蛋白质结构，这被认为是极其困难的问题。2020年，哈萨比斯和Jumper推出AI模型AlphaFold2，攻克这一难题。AlphaFold2能够预测几乎所有已被识别的2亿种蛋白质的结构，这项技术已被全球190个国家的超过200万人使用。AlphaFold2极大提升了抗生素抗药性研究、酶的塑料降解机制及蛋白质功能的理解，也为科学应用提供了新工具。

此次获奖研究不仅实现了蛋白质结构预测的50年梦想，还推动了人工合成蛋白质的能力，赋予人类在医学、生物技术及材料科学等领域广阔的发展前景。

获奖者如下：

• David Baker：1962年生于美国西雅图，1989年获加州大学伯克利分校博士学位，现为华盛顿大学教授及霍华德·休斯医学研究所研究员。
• Demis Hassabis：1976年生于英国伦敦，2009年获伦敦大学学院博士学位，现为谷歌DeepMind首席执行官。
• John Jumper：1985年生于美国阿肯色州小石城，2017年获芝加哥大学博士学位，现为谷歌DeepMind高级研究科学家。

本年度奖金总额为1100万瑞典克朗，一半颁给David Baker，另一半由Demis Hassabis和John Jumper共享。

作者信息
Arnaldur 是一名计算机科学家，目前从事软件开发顾问工作。

网站概述
该网站是 Arnaldur 的个人网络主页，用于展示其文章和联系信息。

文章列表
网站列出了作者撰写的以下文章：

• "An n-ball Between n-balls"，发布于 2024 年 10 月 1 日，获得 242 分。
• "Large Language Model Reasoning"，发布于 2024 年 5 月 28 日，获得 14 分。

联系方式
作者提供了电子邮箱：a.arnaldur+be@gmail.com，可供任何原因联系。

网站技术细节

• 网站使用 SolidStart 框架从零构建。
• 采用静态渲染方式。
• 托管在 AWS 上，并使用 SST（Serverless Stack Toolkit）进行辅助部署。
• 样式基于 matcha.css，提供了美观和便利的基础。
• 网站中隐藏了一个复活节彩蛋。

媒体播放器Web重构项目概述

这是一个展示如何将Winamp等经典媒体播放器使用Web Components技术重建为Web版本的项目。项目基于Media Chrome构建视频和音频播放器主题，旨在为各种Web播放器和Web应用框架提供可重用的解决方案。

核心特点

• 技术栈：采用Web Components和Media Chrome技术，确保播放器主题具有良好的封装性和跨框架兼容性。
• 适用范围：支持多种Web播放器和Web应用框架，如React、Vue、Angular等，方便开发者集成到不同项目中。
• 易用性：提供简单三步操作流程：1. 选择喜欢的播放器主题；2. 挑选对应的播放器和应用框架；3. 复制代码并粘贴到项目中，即可快速部署。
• 自定义灵活性：允许使用纯HTML和CSS对播放器用户界面（UI）的任意细节进行自定义，无需复杂编程，提升开发效率。

项目价值

该项目简化了Web媒体播放器的开发过程，通过预构建主题和模块化设计，降低了技术门槛，同时保持高度可定制性，适用于需要快速集成媒体播放功能的Web应用。

文章摘要：

本文作者以第一人称叙述了其被诊断出巨大脑肿瘤后的医疗经历，并反思了医疗知情同意与治疗现状的不足。

核心事件：

• 诊断与手术压力： 作者因脑部肿瘤（后被怀疑为胶质母细胞瘤）入院，被直接告知必须手术，且仅有两种手术方案（活检或切除），未被给予“不手术”的选项。当作者询问不手术的后果时，医生断言将在三个月内死亡。
• 信息缺失与误解： 作者指出医生未明确告知肿瘤的具体类型及预后，也未说明手术后的实际情况。作者在恐惧中误以为手术能使其回归正常生活，但事实是，对于疑似恶性程度极高的胶质母细胞瘤，手术本身无法改变“终末期诊断”的结局。
• “通往虚无的桥”比喻： 作者提出，对于胶质母细胞瘤患者，肿瘤切除手术犹如一座“通往虚无的桥”。手术只是起点，桥的另一端是未完成的道路——即当前标准治疗的无力与破碎。手术可能短暂延长生命（中位生存期约12-18个月），但后续的放化疗等治疗无法治愈疾病，患者将始终与疾病共存直至死亡，并可能承受巨大痛苦。

核心批评与呼吁：

• 知情同意不充分： 批评医疗过程中缺乏坦诚、全面的沟通。医生没有清楚解释手术的实际效果（仅为姑息、延长有限生存期）、术后的治疗路径及可能面临的苦难，导致患者在信息不对称的情况下做出决定。
• 掩盖基本事实： 尽管医疗团队倾向于强调临床试验等后续选择，但回避了“手术是通往虚无的桥”这一残酷现实。作者认为，每年约有1.5万美国患者面临相似处境，他们理应获得真相。
• 呼吁透明与尊重： 作者强烈主张，医疗专业人员应将患者视为有能力的成年人，完整告知诊断、预后及治疗局限性的全部事实，包括手术后的不完整图景和姑息治疗的本质。患者需要基于真实信息权衡利弊，而非在被隐瞒关键事实的情况下匆忙接受手术。

文章总结

本文探讨了在Python代码中过度依赖字典（dict）作为主要数据结构所带来的问题，并给出了现代Python中的替代解决方案。

一、 字典的主要问题

1. 不透明性：接受字典的函数难以扩展和维护。由于缺乏明确的结构定义，数据结构的变更需要追溯到其创建源头，容易在多条调用路径中引发不一致。
2. 可变性：随意修改字典的值或结构（如增删字段、改变类型）是一种不良实践，这会使数据逻辑与应用的工作流程紧密耦合，破坏数据的完整性。

二、 核心建议：将字典视为“线路格式”

应将字典视为一种序列化/反序列化的中间格式（如JSON API响应），仅在从外部输入时使用。获取后应立即转换为具有明确语义的内部领域模型。这一过程类似于领域驱动设计中的防腐层模式，能够隔离外部结构，保障业务逻辑的清晰与稳定。

示例对比：

• 不良实践：函数直接返回API响应的原始字典，结构不明确且包含大量无关字段。
• 良好实践：定义GitHubRepo类，函数获取原始字典后，仅提取所需字段来实例化该类。这样结构清晰，且解耦了外部API与内部逻辑。

三、 现代替代方案

为简化类的定义，可以使用以下工具：

1. 数据类：Python标准库中的dataclasses模块可以自动生成__init__等方法，减少模板代码。建议常使用frozen=True创建不可变实例，以增强代码的可靠性。
2. Pydantic：一个功能更强大的第三方数据验证库。它支持序列化/反序列化、自动类型转换和自定义验证器，特别适合处理复杂的JSON数据。
3. 类型提示字典：对于无法全面重构的遗留代码，可以使用TypedDict为字典添加类型注解。这能在IDE中提供自动补全和错误检查，改善开发体验。
4. 映射类型：当字典被用作键值对类型一致的纯存储时，建议使用typing.Mapping或MutableMapping进行类型注解。这明确表明了数据的用途（存储映射），并可以通过类型检查器防止误操作（如对Mapping进行赋值）。

结论

文章最后强调，应警惕字典的滥用。尽早引入合适的数据结构（如类、数据类）来替代原始字典，可以有效控制技术债务，提升代码的可维护性、可读性和健壮性。延迟解决这一问题只会增加后续重构的复杂度。

文章分析了2023年2月28日美国财政部收到的一笔70亿美元遗产及赠与税款，指出这是现代历史上最大的一笔类似税款，金额远超以往记录。作者首先回顾了财富测算的模糊性，指出富豪身份和资产难以准确统计。以往诸如大卫·科赫等知名亿万富翁去世时尚未出现如此巨额税单，令人困惑此次为何出现如此特例。

按照平均遗产税税率推算，这笔款项对应的遗产总额大约在175亿到400亿美元之间，相当于全球最富的100人之列。由于遗产税通常需在去世后9个月内缴纳，判断这位神秘富豪应于2022年去世。在该年逝世的数位美国富翁（如科勒家族、托尔地产创始人、富达基金家族成员）公开财富数据均无法完全对应。另一候选人赌场大亨谢尔登·阿德尔森2021年去世且富有，但也无法排除卷入IRS（国税局）争议导致缴税延后两年。

一位知情金融行业人士匿名致电作者，透露这位神秘富豪可能是Fayez Sarofim——一名长期低调的休斯顿投资大亨，2022年5月逝世。Sarofim是埃及土地拥有者之子，20世纪50年代移民美国，在德州投资管理领域深耕六十余年，专注为富豪家族和机构打理资产，被誉为“斯芬克斯”。其生前曾管理逾300亿美元资产，是NFL休斯顿德州人队的小股东，同时还是知名艺术收藏家。高估值NFL球队和多样化投资加之长期复利，有可能形成远大于他公开报道的15-30亿美元身家。

作者查证Sarofim利用信托安排财产，并向慈善基金会捐款近4亿美元。尽管Sarofim生前担忧税负影响投资，但知情人称Sarofim主动纳税出于对美国移民机遇心怀感激，无意躲避。这符合部分观念上的“无所谓纳多少税”心态，属于少见类型。此外根据财政部后续数据显示，70亿美元确实来自德克萨斯州，而该州2022年并无其它巨富去世。

公众和媒体无法精确追踪Sarofim财富，原因包括海外继承、私有投资结构（不同于上市公司高管须公开信息）、长期持有高成长蓝筹股等。传统估算方法低估了通过非上市渠道实现长期财富积累的现实。

也有税务律师猜测此税款可能是部分活着的亿万富翁为节省未来（特朗普2017年减税到期后）潜在更高税负，提前以赠与及特殊遗产安排缴纳税费。这解释了款项为“遗产及赠与税”，也对应富人避税策略的调整。

文章最后指出，美国遗产税历史悠久，但对国家财政贡献已十分有限，更多充当政治象征意义。未来税制改革或与大选结果有关，但此类巨大一次性税收仍可能仅为偶发现象。

公司现状与潜在风险

• DNA分析公司23andMe近期陷入困境：2023年遭遇数据泄露，今年9月整个董事会因与CEO安妮·沃西基存在分歧而集体辞职。
• 公司CEO曾表示接受第三方收购提案，但近期又改变立场，声称公司目前不出售，但未来走向不明，引发对用户数据命运的担忧。
• 若公司被收购，新所有者可能继承全部用户数据。类似案例在2020年MyHeritage收购另一家DNA分析公司Promethease时已发生。

当前数据使用情况

• 用户数据可能已被共享：若用户曾同意参与研究，其“去标识化”数据（剥离姓名等个人信息后的遗传数据）可能已提供给研究机构和制药公司。
• 公司通过数据许可协议盈利，例如与GSK（葛兰素史克）合作，授权其使用23andMe数据库进行药物靶点发现等研究。此类协议是公司商业模式的核心部分。

删除数据的影响

• 删除账户意味着你的数据将不会用于未来的研究项目，但无法撤回已用于研究中的匿名化数据。
• 公司会保留部分记录（如删除请求记录）以遵守法律要求，并可能销毁你之前存储的生物样本。

操作步骤与潜在障碍

1. 备份数据（可选）：登录账户，进入“用户设置”页面，点击“23andMe数据”卡片下的“查看”。系统将要求输入出生日期以验证身份，通过后即可下载数据。
2. 删除账户：在同一页面找到删除选项。
3. 常见问题：
   • 验证可能失败：如果注册时使用了虚假出生日期，网站会提示联系客服，客服可能要求提供身份证明，导致操作受阻。
   • 已有用户报告此过程存在障碍，建议提前确保验证信息准确。

关键总结

• 当前公司动荡增加了数据未来的不确定性。
• 数据删除是控制个人信息的最后手段，但无法完全清除历史研究痕迹。
• 操作前务必尝试备份数据，并做好应对验证环节困难的准备。

• 文章批评了Htmx在实际团队项目中出现的复杂性，指出其看似简单的理念在多种场景下存在局限。
• Htmx属性继承是设计上的失误。属性继承在代码中往往是隐含且让人意外，与Htmx作者强调的“行为局部性”相悖，类似动态绑定。不同属性继承行为不一致（如hx-delete不继承，但hx-confirm和hx-ext继承），导致开发者不得不全部显式声明属性，继承反而失去意义。
• 大多数有趣的Web应用无法批量替换DOM元素，因为DOM元素中常有浏览器本地状态（如
  开/关状态、输入、下拉菜单开关等），这些状态用outerHTML直接替换会丢失。即使使用morphdom，也会覆盖掉某些预期保留的内容，需要修补代码以保留输入和details元素状态。
• Htmx存储请求队列于DOM元素本身，这一方式在批量替换元素时消除队列，但若使用morphdom保留元素，则队列也会保留，导致未定义行为，使Htmx设计遭到破坏。
• 默认请求队列模式很不合理。默认情况下，同一队列（元素）若触发多次请求，会取消正在进行的请求，导致工作丢失，非常不直观。
• 事件触发器是非局部影响，和属性继承类似难以管理。虽可通过服务端语言的DSL缓解，但感觉回到早期JS基于回调的编程方式。
• 组件状态难以维护。如果页面有多个带独立状态的区块，状态同步变得复杂。Htmx对此无良好方案，只能用查询参数、隐藏表单、事件触发器等，均有弊端。React和Halogen等则提供父组件“props”和内部状态的机制，易于组件状态管理。但团队发现React与Htmx难以协作控制状态和DOM，直接桥接React组件或用WebComponents都效果不佳。Alpine也冗余于已有React代码库。
• 服务器端语言直控界面是明显优势：省去前端类型与数据库类型的序列化、无数据泄漏，也无需GraphQL；可用更强抽象，且表单验证逻辑只需写一次（与后端共用）。
• 但上述Htmx缺点依然存在。
• 作者提出“Htmx-in-React”的未来方向：用React重实现Htmx思想——服务器仅发JSON，React转成虚拟DOM。这样能解决组件状态问题、无需特殊桥接React组件、避免Htmx的请求队列和morphdom/DOM状态问题（这些在React中已解决），保留Htmx优势，去掉依赖，适合有预算时重构。

PEP 760: 不再允许裸except

概述：PEP 760 是一个Python增强提案（Python Enhancement Proposal），旨在禁止在Python代码中使用裸except语句。裸except指的是不指定异常类型的except:语句，例如except:而不是except SomeException:。

当前状态：该PEP已被撤回。

撤回原因：根据共识，该提案的收益不足以证明其实施成本。这意味着Python社区认为禁止裸except的益处不值得为此付出的开发和维护代价。

关联：该提案在内容中被称为PEP 758的“邪恶双胞胎”（evil twin），暗示它可能与PEP 758（允许except和except*表达式的提案）形成对比，但提供的细节不完整，无法进一步阐述具体关系。

关键细节：提案标题直接反映了其核心目标——消除裸except的使用，以提升代码的明确性和错误处理的精确性。然而，由于成本效益考量，该提案最终未被采纳。

文章核心观点： 本文作者对心理学研究的实质进展提出深刻质疑，认为该领域在五个关键维度上仅在“推翻直觉认知”方面取得显著成就，而在其他四个方面（实战效果、应用工具、范式转移、理论深度）均表现不佳，并提出两条可能推动真正进步的路径。

详细总结：

1. 心理学的核心成就：推翻直觉认知

   • 心理学研究的主要贡献在于揭示人类“民间心理学”（folk psychology）的谬误，例如认知偏见、错误记忆、道德衰落的错觉等。
   • 这类研究类似于其他科学领域（如伽利略推翻地心说）早期的“祛魅”工作，但尚未促成系统性理论突破。

2. 进展不足的四个维度

   • 实战对抗弱势：心理学知识在实际应用中并未显著优于普通直觉。例如：
     • 减少政治对立的干预措施效果不及啤酒广告；
     • 专业心理治疗师与未受训练的友善人士疗效相当；
     • 大五人格理论在预测生活结果时，与未经学术验证的人格测试（如MBTI、九型人格）相比优势微弱。
   • 应用停滞：
     • 精神疾病治疗成效五十年来未显著改善，DSM手册中无任何疾病被“治愈”；
     • “助推”等行为干预手段效果不稳定，专家预测干预效果的能力常低于随机水平。
   • 缺乏可封装的实用工具：除少数应用（如间隔重复软件Anki、储蓄计划“明天多存点”）外，心理学未能产生可交由非专家直接使用的成熟工具。
   • 未发生范式转移：心理学领域内并存多种相互矛盾的理论体系（如弗洛伊德学说与认知行为疗法），缺乏像现代医学取代“体液说”那样的根本性世界观变革。

3. 对学科现状的反思

   • 心理学可能仍处于早期发展阶段，而非成熟科学。其进步缓慢的原因并非研究对象过于复杂，而可能源于缺乏足够积累以触发“科学革命”。
   • 当前研究倾向于在模糊理论框架内不断添加修补（类似托勒密天文学中的“本轮”），而非彻底重构。

4. 未来可能的路径

   • 继续解构民间心理学：系统检验并推翻人们对心理过程的错误直觉。
   • 发起根本性革新：
     • 采用“异域思维”，质疑现有文献与范式；
     • 聚焦于显而易见却无法解释的“谜题”（如电视娱乐的吸引力、创造力的来源、药物的矛盾反应），从基础现象出发重建理论。

结论： 作者认为心理学若仅满足于“推翻直觉”的成就，将难以实现质变。学科需主动引发理论危机，或通过对未解之谜的突破性研究，方能在理解人类心智的宏大工程中取得实质进展。

LibreDrive 技术概述

核心定义

LibreDrive 是一种光驱（DVD、Blu-ray 或 UHD）的运行模式，可直接访问光盘数据，无需固件施加任何限制或转换。兼容 LibreDrive 的驱动器永远不会拒绝读取光盘数据或自行“吊销”访问权限，且是读取 UHD 光盘的必要条件。

技术背景：光驱的演进

1. 初始阶段（CD 时代）
   光驱作为“原始”设备，仅负责通过激光扫描光盘表面，并将数据传递给电脑软件。数据格式多样，但本质是定位激光、读取数据。
2. 限制引入（DVD 的 CSS 保护）
   光盘被分区，访问特定区域需软件掌握密钥。此机制（CSS）用于版权管理及区域价格锁定（例如，欧洲锁区驱动器无法读取东南亚廉价版光盘）。
3. 限制强化（蓝光）
   数据分区及访问规则变得更加复杂。现代光驱固件内嵌复杂规则，决定在何种条件下可访问光盘的哪些区域。

问题本质

光驱在技术上完全有能力读取所有数据，但嵌入式软件（固件）充当了“警察”，依据规则限制访问。

LibreDrive 的实现原理

光盘数据以螺旋轨道上的凹坑编码。理论上可通过显微镜等物理方式直接解码，但成本高、耗时长。
更可行的方法是修改光驱固件，将其恢复为“原始”设备：仅负责定位激光、读取并解码数据，移除所有访问限制功能，从而将完整数据直接传递给用户。

核心价值

LibreDrive 通过绕过固件限制，实现了对光盘数据的无限制、直接访问，是读取 UHD 光盘的关键。

可靠软件设计的实践

核心实践

基于构建高性能内存缓存的经验，总结出八项关键设计实践：

1. 优先使用现成方案
   只要不是核心价值组件，首选现成解决方案（如Redis），避免重复造轮子。

2. 成本与可靠性优先于功能
   构建廉价可靠的系统比功能丰富的系统更重要。通过前期分析简化需求，采用最少功能快速部署。

3. 快速将想法投入生产
   以最小功能集部署，通过生产环境实际反馈确定真正需要的功能，避免预设不必要的需求。

4. 采用简单数据结构
   避免使用复杂数据结构，因其易误用导致性能和bug问题。例如在缓存中使用数组+哈希表，用最小堆管理过期项。

5. 提前预留资源
   预先分配所需资源（如索引数组），便于早期发现资源不足问题，同时简化容量规划和性能分析。

6. 设置各项上限
   为算法操作设置迭代限制（如哈希碰撞探测次数），为系统资源设置容量上限，防止最坏情况影响系统。

7. 简化测试流程
   设计接受命令行输入的接口，允许通过文本文件和管道执行测试协议，加快开发迭代速度。

8. 嵌入性能计数器
   内置各类累积指标（如读写耗时、缓存未命中次数、资源分配量），通过监控这些指标了解系统运行状况和压力来源。

核心思想

这些实践共同强调：通过简化设计、提前验证、快速反馈和持续监控，在保证系统可靠性的同时，高效地满足实际需求。

核心问题

大型神经网络的计算主要消耗在浮点张量乘法上，其能耗远高于整数加法。

核心方案

本文提出 L-Mul 算法，其核心思想是利用整数加法运算来近似浮点数乘法，从而大幅降低计算能耗。

算法优势与能效

• 高精度、低能耗：L-Mul 相比于 8 位浮点乘法，以显著更低的位级计算成本实现了更高的精度。
• 理论能效提升：由于整数加法比浮点乘法能耗低得多，在张量处理硬件中应用 L-Mul，理论上可节省高达 95% 的逐元素张量乘法能耗和 80% 的点积运算能耗。

理论与实验验证

• 理论分析：作者计算了 L-Mul 的理论误差期望。
• 精度对比：
  • 4 位尾数的 L-Mul 可达到与 float8_e4m3 乘法相当的精度。
  • 3 位尾数的 L-Mul 精度超过 float8_e5m2。
• 广泛评估：在文本、视觉和符号任务（如自然语言理解、结构推理、数学、常识问答）上的实验与理论误差分析相符。
• 模型应用：
  • 直接将 L-Mul 应用于注意力机制几乎无精度损失。
  • 在 Transformer 模型中，将所有浮点乘法替换为 3 位尾数 L-Mul，在微调和推理中均能达到与使用 float8_e4m3 进行累加精度相当的性能。

Lunar Lake的iGPU：英特尔Xe2架构首次亮相

核心架构改进

• Xe2架构是英特尔对移动及离散GPU架构的进化，旨在提升效率并更好地适配工作负载，将应用于Lunar Lake移动平台及未来的“Battlemage”独立GPU。
• 模块化设计：集成显卡由Xe核心构建（类似AMD的WGP或Nvidia的SM）。Lunar Lake的iGPU包含8个Xe核心，分为两个渲染切片，每个切片包含4个Xe核心及固定功能硬件（如光栅化器、ROP）。
• 向量引擎重组：将Meteor Lake中成对的8宽度向量引擎合并为16宽度向量引擎，减少了指令控制开销，提升了效率，同时保持了每周期的FP32吞吐量。此变化也简化了分支发散惩罚的处理。
• 缓存层级优化：
  • 层级Z缓存容量增加50%（至6KB），用于早期剔除被遮挡几何体。
  • 颜色缓存容量可能增加33%。
  • L2缓存容量翻倍至8MB（目前笔记本iGPU中最大），但延迟有所增加。
• 矩阵单元回归：每个向量引擎配备XMX单元（2048位），支持低至INT2的精度，特别适用于升采样等任务，在笔记本中尤为重要。
• 光线追踪单元升级：每个Xe核心的RTU拥有3条遍历管线，每周期可进行18次包围盒测试和2次三角形测试，提升了光线追踪性能。

性能与效率分析

• 计算吞吐量：与Meteor Lake的iGPU（同为8个Xe核心）相比，Lunar Lake的峰值时钟略低（1.95GHz vs 2.25GHz），但架构优化在部分场景中带来性能提升。然而，在常见FP32操作上，AMD Strix Point（RDNA 3.5） 仍拥有显著吞吐量优势（得益于更高的WGP规模和频率）。
• 带宽与延迟：
  • L1缓存与本地内存（SLM）共用192KB，Lunar Lake在本地内存分配效率上有所改进。
  • L2缓存带宽与Meteor Lake相似，但远低于AMD Strix Point。
  • DRAM带宽：Strix Point带宽需求最高，平均功耗也更大（约50W vs Lunar Lake的43W）。Lunar Lake通过更大的缓存减少了高功耗的DRAM访问，提升了能效。
• 实际应用表现：
  • 游戏：在1080P低画质下，Lunar Lake较Meteor Lake有巨大性能提升，可流畅运行《赛博朋克2077》。但仍略低于当前代Strix Point，部分原因是功耗分配差异（Lunar Lake将更多功耗预算留给GPU）。
  • 计算任务（如FluidX3D流体模拟）：Lunar Lake优于Meteor Lake，但略逊于上代AMD Phoenix。
• CPU-GPU交互：集成显卡共享内存控制器，数据交换更快，但Lunar Lake的DMA引擎性能有所下降。

效率策略与市场定位

• 英特尔策略：专注于通过架构优化和缓存增强来提升同规模GPU的效率，而非单纯扩大规模。这有助于在轻薄笔记本的有限功耗下实现更好性能。
• AMD策略：Strix Point采用更大规模GPU和更高频率，追求极致性能，但代价是更高的带宽和功耗消耗。
• 未来意义：Xe2架构为英特尔未来的“Battlemage”独立GPU奠定了基础，展示了其在GPU领域持续投入的决心。集成显卡作为移动游戏的重要载体，将继续为英特尔的独立显卡发展提供支撑。

总结

Lunar Lake的iGPU通过Xe2架构的多项改进（向量引擎重组、缓存增大、矩阵与光追单元增强），在能效和特定场景性能上取得进步，尤其注重降低功耗敏感的内存访问。尽管在绝对计算吞吐量和峰值性能上仍面临AMD的竞争，但其优化策略更适合功耗受限的轻薄笔记本环境，并为英特尔独立显卡的未来架构铺平道路。

论时间的本质：一种计算观点

时间是人类经验的核心特征，但其本质是什么？传统科学常将其视为空间般的坐标，但这只是数学描述，未揭示其内在本质。从计算视角看，可将世界状态序列视为通过逐步应用计算规则而推导生成，由此可将时间进程与“宇宙进行中的计算过程”等同起来。

时间的计算本质与计算不可约性

• 时间即计算：时间并非简单的“时间坐标”，而是宇宙通过应用规则逐步计算新状态的过程。
• 计算不可约性：关键现象在于，对于许多系统，没有比逐步运行其演化步骤更优的方法来确定未来状态。这赋予了时间一种稳健性：无法“跳过”时间，唯一方式是逐步经历不可约的计算步骤。
• 计算等价原理：表明宇宙充满计算不可约性，这从根本上定义了稳健的时间进程概念。

观察者的关键角色

我们体验时间的根本原因，在于我们作为计算有界观察者与宇宙底层计算不可约性的相互作用。

• 为何未来“逐步展开”：若系统具有计算不可约性，预测其未来需要无限的计算工作。而计算有界的我们无法完成此工作，只能与系统同步计算，无法大幅“预见未来”，只能体验其逐步展开。
• 时间的方向性（第二定律）：我们感觉时间单向流动（易于记忆过去而非预测未来），这同样是上述相互作用的结果。底层物理定律可能可逆，但计算不可约性力量更强。它会将有序初始状态“加密”成计算有界观察者无法辨认的无序状态。因此，我们感知到从有序（可准备的过去）到无序（观察到的未来）的明确流动，从而定义了“过去”与“未来”。

时间与空间结构

在作者的物理项目中，宇宙的底层状态由表示空间关系的超图表示，时间则对应于该超图的逐步重写。

• “时间原子”：即基本的“重写事件”。事件间的依赖关系构成因果图。
• 时空与参考系：将因果图解析为一系列“同时性切片”并无唯一方式，导致存在不同的参考系（如相对论所示）。时间进程始终与一系列“相互构建”的事件选择相关。
• 感知时间的成因：我们的日常感知（如神经信号处理速度与光速的差异）使我们自然地将世界解析为一系列在连续时间点上存在的空间状态序列，但这不影响时间本身的计算本质。

多重时间线与分支空间

底层而言，时间实际上是多线程的，存在许多不同的“历史路径”，这源于量子力学。

• 多路图与分支空间：所有可能历史路径可合并为多路图。我们可以将其切片，得到的不再是普通空间状态，而是分支空间的状态。分支空间由影响不同历史分支的事件“编织”而成。
• 为何感知单一时间线：我们作为计算有界的观察者，必须将大部分细节等价化。就像在气体中感知不到单个分子运动，而只能感知流体动力学特征一样，我们的“心智”跨越许多分支，只能采样其聚合特征，从而在第一近似下感知到单一的、聚合的历史线程。客观现实的一致性源于我们（不同观察者）在分支空间中彼此非常接近。

时间在规则空间中的终极视角

• 规则空间：它由遵循所有可能计算规则构成，是所有计算过程纠缠的极限，是一个单一、独特的抽象结构。
• 时间源于探索：从外部看，规则空间是一个完整的、无时间的抽象对象。但关键是我们嵌入其中并通过计算有界性的“透镜” 观察它。我们无法一次性了解整个规则空间，只能通过逐步应用有界计算来“穿越规则空间”进行探索。正是这种逐步探索的过程，赋予了我们时间的概念。

结论：时间究竟是什么？

归根结底，从计算范式来看，时间的本质很简单：时间就是应用计算规则时的进程。但其关键在于：

1. 稳健性源于计算不可约性：时间作为线性进程的稳健性，是因为计算有界观察者无法“超越”不可约的计算步骤，只能沿直线前进。
2. 普适性源于计算等价原理：不同系统遵循不同不可约规则时，它们都在以相同方式“累积计算效果”，使得时间进程具有普适性，可独立于具体“基质”来定义。
3. 依赖于观察者：稳健的时间概念依赖于计算有界的观察者。若我们非计算有界，则可能打破第二定律，跳跃时间或追随不同时间线。但对于像我们这样的观察者，时间几乎必然呈现为单一、一维的线程。

最终，计算不可约性赋予了时间一种坚硬、可触的特性，它阻止我们“预测未来”，要求我们“经历”时间的流逝，这正是时间之意义与价值所在。

FinetuneDB 平台摘要

FinetuneDB 是一个 AI 微调平台，旨在帮助用户利用自有数据快速、低成本地创建定制化的大语言模型（LLM）。

核心价值与功能：

• 快速与经济：用户可以在几分钟内（而非数周）用自有数据训练 AI 模型，并获得更优性能与更低成本。
• 无缝集成：其 SDK 与 OpenAI SDK 完全兼容，开发者只需进行少量修改即可开始记录请求数据，快速集成。
• 多样化的数据摄取方式：
  • 提供 Python 和 JavaScript/TypeScript 的类型化 SDK，可异步捕获生产数据。
  • 提供 Web API 供用户进行更自主的集成和日志摄取。
  • 提供 Langchain 集成，通过添加回调处理器即可在 5 分钟内获取完整的执行跟踪。
• 安全与合规：
  • 数据在传输过程中使用 TLS 1.2+ 加密，静态数据使用 AES 256 加密。
  • 支持严格的用户角色与权限管理，变更可立即生效。
  • 平台正在积极致力于实现 SOC 2 合规，以确保系统的安全性与可靠性。

核心发现：17世纪米兰发现古柯使用证据

意大利研究人员通过分析17世纪米兰Ca' Granda医院地下墓穴中的两具木乃伊脑组织，发现了古柯使用的化学证据。这是在南美洲以外检测到的最早的古柯使用记录，将古柯出现在旧大陆的文献证据提前了近两个世纪。

关键概念澄清：古柯 ≠ 可卡因

文章强调了许多报道（包括《纽约时报》）的标题存在根本性错误。古柯（coca）是原产于南美洲的植物，其叶子作为温和的兴奋剂和食欲抑制剂已被使用了数千年。而可卡因（cocaine）是一种强效生物碱，直到1855年才首次由德国化学家从古柯叶中分离出来。17世纪时，可卡因尚未存在，因此该发现记录的是古柯植物的使用，而非现代毒品可卡因。

历史背景与意义

1. 药物工业化的分水岭：区分古柯和可卡因至关重要。从古柯（植物形式）到可卡因（工业化提取物）的转变，是19世纪药物工业化的体现。这如同“工厂对药物的影响，堪比罐头对蔬菜”，使得药物更廉价、更易获得、效果更强烈，开启了现代成瘾药物的新纪元。
2. 米兰的地理因素：17世纪的米兰是西班牙帝国的一部分，也是国际大都市。因此，古柯叶通过帝国贸易网络（可能由探险家、医生、商人或旅行者）从南美传入米兰是完全合理的。
3. 使用性质推测：分析表明两位使用者可能在去世前不久使用了古柯。这提示其使用可能不仅限于精英阶层的实验，或许已触及更普通的住院病人，暗示了比以往认知更广泛的知识或传播。
4. 未解的问题与方法突破：此发现引出了新的历史问题：17世纪欧洲的古柯使用是孤立的个别现象，还是更普遍却未被文献记录的模式？研究展示了对历史文物（如木乃伊组织）进行毒理学分析的新方法，将物质记录与文献记录相结合，为医学史和药物史研究开辟了新途径。

JavaScript Structs 提案摘要

该提案处于 Stage 2 阶段，旨在为 JavaScript 引入固定布局对象和共享内存多线程相关的基础特性。其核心是四项逻辑功能：

1. Structs (非共享结构体)

• 定义：固定布局的对象，行为类似类实例，但限制更严格，以利于优化和静态分析。
• 关键特性：
  • 密封完整性：布局固定，不能添加新属性，原型不可更改，所有声明字段均具有 writable、enumerable、non-configurable 属性。
  • 一次性初始化：实例在可访问前，所有字段（包括父类）已初始化为 undefined。
  • 构造函数：this 立即可用，不支持返回值覆盖（return 无效）。
  • 继承限制：只能继承其他 structs。
  • 方法非泛型：this 值必须是该结构体或子类的实例。

2. Shared Structs (共享结构体)

• 定义：在 Structs 基础上进一步受限，使其可在多个代理（Agent）间共享与并行访问。
• 额外限制：
  • 原型为 null。
  • 不能包含实例方法。
  • 字段只能引用基本类型或其他 Shared Structs，不能指向非共享值。
  • 不可冻结（形状必须不可变以适应共享）。
  • 实例可直接跨代理传递，无需复制。
• 共享数组：作为特例，SharedArray 是长度固定的共享结构体，所有元素初始化为 undefined。

3. 同步原语

• 内存模型：默认字段访问无序。可通过扩展的 Atomics 静态方法进行顺序一致（seq-cst）访问。
  • 新方法包括：Atomics.load、Atomics.store、Atomics.exchange、Atomics.compareExchange。
  • 重要保证：共享结构体的字段访问永不撕裂（即读取总是看到完整的单个写入值）。
• Atomics.Mutex：非递归互斥锁。
  • 通过 Atomics.Mutex.lock / lockIfAvailable 获取锁。
  • 通过 UnlockToken 对象解锁（支持 using 语法），旨在减少误用（如双重解锁）。
• Atomics.Condition：条件变量。
  • 提供 wait、waitFor、notify 等方法，用于线程间更复杂的同步。

4. 设计原则与开放问题

• 设计原则：
  • 看起来原子性的语法应是原子性的（如点操作符访问不撕裂）。
  • 共享对象不能引用非共享对象（堆分离，引用单向）。
• 开放问题：当前共享结构体无实例方法（因函数不可共享），正在探索通过“每领域原型对象”和“跨代理关联机制”来附加行为。

5. 未来工作

• 异步锁定与等待（lockAsync、waitAsync）。
• 与 WasmGC 提案的互操作性，使共享结构体成为 JS 中反映 WasmGC 对象的良好基础。

6. 实施指导与范围

• 实施要点：
  • 引擎应为固定布局对象创建不可变形状以优化。
  • 共享结构体字段需指针宽度并对齐以支持原子操作。
  • 字符串共享是难点，可能需复制或无锁原地修改。
  • 同步原语需兼容移动式垃圾回收器（如通过固定对象或用户态实现）。
• 明确排除：值语义/不可变性、复杂类型系统、二进制数据覆盖视图等。

该提案旨在通过提供受限但高性能的固定布局对象和共享内存原语，解锁 Web 上的多线程能力，并为未来更高级的并行抽象奠定基础。

此页面是WordPress.org的登录界面，用于用户登录其账户以参与WordPress社区活动，如贡献代码、在支持论坛寻求帮助，或对主题和插件进行评级和评论。登录表单包含用户名或电子邮件地址和密码的输入字段，并提供“记住我”选项以便自动登录。页面还设有“忘记密码”和“创建账户”的链接，方便用户恢复密码或注册新账户。顶部有一个语言选择器，允许用户切换界面语言。标题中提及“I am not affiliated with WP Engine in any way”，强调该登录页面与WP Engine公司无关。

这篇文章讲述了作者偶然发现两张葡萄牙穿孔卡片后，如何通过逐步调查解密其内容的过程。卡片上印有"In Es Me"标识和神秘数字序列。

主要线索与发现：

1. 卡片数据：第一张卡为"M000015 JOAO A. FERNANDES 150000190"，第二张为"1000015 100170476"。作者首先推测数字可能是葡萄牙税号（NIF），但通过编写验证代码排除了这种可能。

2. 机构追溯：通过"In Es Me"标识，作者查明这是1960-70年代里斯本的一家计算机培训机构"Instituto de Estudos Mecanográficos"。该机构在广告中宣传计算机是"现代且有利可图的职业"。

3. 教材关键：作者购买了该机构推广的教材《计算机导论》，在其中发现与书中完全相同的穿孔卡作为示例，并找到了对卡片格式的详细解释：

   • 第一张卡（M开头）：包含员工编号（000015）、姓名、时薪（15葡萄牙埃斯库多/小时）和每周扣款（0.190埃斯库多）。
   • 第二张卡（1开头）：记录员工000015在1970年1月10日那周的工时（47.6小时）。

4. 剩余疑问：尽管卡片内容已解密，但教材实际制作机构"ENIASA"的信息仍不明确。

整个过程体现了从技术谜题出发，通过代码验证、历史资料查找和实物比对，最终解开数字含义的完整推理链。

MIQT：Go 语言的 MIT 许可 Qt 绑定

概述

MIQT 是一个为 Go 语言提供的 Qt 绑定库，采用 MIT 许可证。它通过 CGO 直接绑定 Qt 5.15 / Qt 6.4+ 的 API。使用该绑定需要一个可用的 Qt C++ 开发工具链。

该绑定于 2024 年 8 月启动，已对多个 Qt 模块提供了完整的绑定支持，包括 QtCore、QtGui、QtWidgets、Qt SQL、QtMultimedia 等，并支持子类化以及 uic/rcc/lupdate 工具实现。但其在某些方面可能尚不成熟。

支持平台

MIQT 已确认支持以下平台：

• Linux：x86_64、ARM64 架构，支持静态或动态链接。
• Windows：x86_64 架构，支持静态或动态链接。
• Android：ARM64 架构，支持动态链接（打包在 .apk 中）。
• FreeBSD：x86_64 架构，支持静态或动态链接。
• macOS：x86_64 和 ARM64 架构，支持静态或动态链接。

许可证

MIQT 自身遵循 MIT 许可证。用户同时必须遵守 Qt 的相关许可义务（例如使用动态链接以符合 LGPL，或购买 Qt 商业许可进行静态链接）。

关键技术特点与 API 差异

• 容器类型映射：Qt 的 QString、QByteArray、QList<T>、QMap<K,V> 等类型映射为 Go 的 string、[]byte、[]T、map[K]V。需要使用 Go 的等效方法进行操作。
• 字符串处理：Go 字符串内部通过 UTF-8 转换为 QString，必须确保字符串为 UTF-8 编码。
• 内存管理：对于按值返回的 Qt 对象，绑定可能将其移至堆上，并在 Go 中用指针表示。Go 的终结器会自动清理这些堆对象。
• 信号与槽：连接语法从 C++ 的 connect(source, signal, target, slot) 转换为 target.onSourceSignal(func()...) 的 Go 风格。
• 类指针：Qt 类继承在 Go 中通过嵌入结构体实现。例如，*QLabel 可以通过 .QWidget 嵌入字段传递给接受 *QWidget 的函数。
• 多线程：调用 qt.NewQApplication 后，Go 运行时会通过 runtime.LockOSThread() 锁定到固定的操作系统线程。从其他 goroutine 访问 Qt 对象时，应使用 (qt6/mainthread).Wait() 或 Start() 以确保在 Qt 主线程执行。
• Android 特殊路径：QFileDialog 可能返回 content://... 形式的路径，需要通过 qt.QFile 的句柄传递给 Go 的 os.NewFile。

常见问题解答 (FAQ) 摘要

• 二进制大小：可通过编译参数 -ldflags "-s -w" 及工具 upx 进行压缩。
• 编译时间：首次使用时编译较慢，之后会很快。Go 1.26 版本编译速度显著提升。
• 与其他绑定的比较：MIQT 是独立开发的绑定。相较于其他主要 Go Qt 绑定（如 therecipe/qt、kitech/qt.go），MIQT 同时支持 Qt 6 和 MIT 许可。
• 使用 Qt Designer：MIQT 提供了自定义的 miqt-uic 和 miqt-rcc 工具，可配合 go generate 命令使用。
• 自定义 Qt 安装路径：通过设置 PKG_CONFIG_PATH 环境变量指向 Qt 库的 .pc 文件目录。
• 从 Qt 5 升级到 Qt 6：主要更改 Go 包的导入路径，例如从 github.com/mappu/miqt/qt 改为 github.com/mappu/miqt/qt6。

构建指南

构建前需在目标平台安装对应的 Qt 开发依赖和 Go 工具链。

• Linux (原生)：通过包管理器（如 apt, dnf, pacman）安装 Qt 5 或 Qt 6 的开发库，然后运行 go build。
• Windows：支持多种方式：
  • Docker：使用 miqt-docker 工具进行交叉编译。
  • 原生：需配置 Qt 工具链、GCC/Clang 编译器及 pkg-config 环境变量。
  • MSYS2：可在 UCRT64 环境下进行动态或静态链接。
• macOS：可通过 Homebrew 安装 Qt 和 Go，或使用 Docker 进行交叉编译。
• Android：通过 miqt-docker 工具执行 android-qt5 或 android-qt6 命令生成 .apk 文件。

LUPINE - 基于IP的虚拟GPU技术摘要

核心概念

LUPINE是一个GPU over IP桥接技术，允许将远程机器上的GPU附加到仅配备CPU的机器上。它通过提供CUDA驱动和NVML的透明 shim 库，使应用程序能够通过网络使用远程GPU资源，就像使用本地GPU一样。

主要功能与演示

1. 托管演示

• 提供免费托管演示服务器，连接Tesla T4 GPU。
• 通过Docker容器运行命令即可验证：nvidia-smi -L
• 提供付费托管GPU服务的可能性（需联系邮箱）。

2. Mac演示

• 支持在macOS（如Darwin arm64）上运行PyTorch等CUDA程序。
• 示例：连接远程RTX 4090 GPU并执行张量运算。
• 客户端自动设置LD_LIBRARY_PATH=/opt/lupine/lib，通过shim库透明重定向CUDA调用。

3. 快速开始

• 使用预构建的Docker镜像（ghcr.io）。
• 服务器端：在GPU机器上运行镜像，暴露端口14833。
• 客户端：在无GPU机器上运行镜像，通过环境变量LUPINE_SERVER指定服务器地址。
• 客户端自动使用LUPINE的libcuda.so.1和libnvidia-ml.so.1 shim库。

4. 多GPU跨服务器支持

• 客户端支持逗号分隔的LUPINE_SERVER列表。
• 设备以服务器顺序暴露为本地序号列表（例如：第一个服务器的所有GPU，然后是第二个服务器的GPU）。
• 示例：从两台服务器列出两个远程RTX 4090 GPU。
• 限制：不支持跨服务器的点对点访问和设备间拷贝。同一服务器的操作通过句柄所有权路由。

5. 镜像版本

• 提供特定CUDA版本标签（如cuda-12.4.1-ubuntu22.04）。
• 客户端镜像有默认版（包含CUDA运行时库）和-slim版（仅包含LUPINE shim、运行时依赖和nvidia-smi）。

6. 为怀疑者提供的慢速开始

• 提供基于PyTorch的详细示例，明确展示CPU客户端与GPU服务器的分离。
• 步骤：创建PyTorch客户端Dockerfile、构建镜像、分别运行服务器和客户端容器，执行训练测试。

本地开发

构建要求

• 需要先运行代码生成（codegen），读取CUDA依赖头文件以生成RPC调用。
• 需要安装CUDA Toolkit及cuBLAS、cuDNN、NVML等包。
• 代码生成命令：cd codegen && python3 ./codegen.py

构建与运行

• 使用CMake构建：生成libcuda.so.1（驱动shim）、libnvidia-ml.so.1（NVML shim）和lupine_driver_server（服务器）。
• 服务器必须先启动。
• 客户端通过LD_PRELOAD加载构建的shim库，或设置LUPINE_SERVER环境变量。

常见问题

1. LUPINE代表什么？ 无特定含义，仅为视觉美观的大写形式。
2. 支持认证/TLS吗？ 间接支持。它是普通HTTP/2服务器，可前置任何TLS/认证服务器。
3. 由AI生成？ 部分是，主要是自动生成繁琐的API桩代码。
4. 延迟问题？ 数据传输（如设备传输）可能因网络瓶颈变慢，但模型训练/推理一旦模型在GPU上，主机数据传输少，可能比预期更快。
5. 支持远程视频编解码？ 不推荐，因为对PCIe链路需求高。理论可行，但需要极高速网络（如1 Tbps）。

先前技术

受现有专有解决方案启发，包括ThunderCompute、Juice Labs和RCUDA。

该文档是Reddit社区 r/ChatGPT 的版规概要，旨在为成员制定明确的互动与发帖准则。主要内容如下：

一、 核心行为规范

• 善意交流：要求用户以善意进行沟通，避免恶意曲解或散布虚假信息。
• 禁止无价值内容：移除纯水贴或低质量帖子，例如反复询问“ChatGPT是否宕机”。
• 限制自我推广：帖子需与ChatGPT或大语言模型主题直接相关，禁止仅为推广其他同类服务而发。

二、 主题边界规定

• 政治讨论：允许讨论与AI相关的政治议题，但禁止涉及无关的政治争论。
• 禁止NSFW内容：这是一个无不当内容的子版块，违规者可能面临封禁。

三、 针对特定议题的规则

• 产品变更反馈：对从GPT-4o切换至GPT-5的不满，应反馈至专设的置顶汇总帖。
• AI艺术内容：允许发布，但必须具有独特性、技术探讨价值或不寻常之处。纯粹为了获取点赞的通用梗图或低质量图片将被移除。版主对此保有最终裁量权。

四、 社区扩展平台

• 文档末尾提供了该社区的 Discord 和 Telegram 群组加入链接。

总之，这份版规明确了社区的互动边界，强调内容质量与主题相关性，并为AI生成艺术等特定内容设定了审核标准，旨在维护一个专注于ChatGPT及相关技术讨论的有序环境。

Mozilla 总裁 Mark Surman 发表文章，强调互联网的免费开放不应以牺牲用户隐私为代价。Mozilla 致力于维护互联网的自由和可访问性，但需同时解决创造者报酬、付费门槛、隐私权普及等问题。目前，在线广告是支撑互联网运作的主要方式，但现有广告行业存在以商业利益优先、侵犯隐私、竞争受限等弊端。Mozilla 不仅关注这些问题，还积极参与改造广告生态，推动隐私保护和公平竞争。

Mozilla 提出改造在线广告的理论框架，包含三个相互关联且可持续推进的方向：

1. 政策与监管：Mozilla 长期推动广告行业隐私保护和消费者权益，包括在英国参与 Google 隐私沙盒相关政策讨论，支持美国州级隐私法中的通用选择退出机制。今年有望在欧盟广告监管、新一轮美国联邦隐私立法等领域进一步推进。这一方向强调，技术手段无法独立解决系统性问题，必须与立法协同治理，赋予用户对数据的实质控制权。

2. 技术标准制定： Mozilla 在互联网标准制订领域具有影响力，致力于打造开放、竞争、公正且保护隐私的网络环境。公司参与 IETF、W3C 等组织，推动隐私保护广告技术（如 Interoperable Private Attribution、PATCG），目标是识别合法、无害的广告场景，并提出技术机制严格限制“第三方跨站 Cookie”等最具侵扰性的广告行为。

3. 产品创新： Mozilla 通过实际开发产品以验证理论和假设。旗下产品长期采用 Total Cookie Protection、Enhanced Tracking Protection 等功能，坚决摒弃隐私侵害型广告技术。公司还在研究通过 Anonym 等方案，帮助其他企业在实现广告价值时兼顾用户隐私，计划建立可行的商业模式示范，证明广告可以不以损害隐私为基础支撑互联网创作者与企业收入。

Mozilla 正在三个方向上同步开展工作，未来将深化与监管机构、社会团体、消费者、开发者、广告商、出版商、平台的交流合作，持续举办研讨活动、分享研究成果，共同探索平衡商业与公共利益的新路径。Surman 表示，在线广告作为互联网内容创作者和发布者收入的重要来源不会消失，但希望广告业能在尊重用户隐私与维护互联网公开、公正的基础上持续发展。他呼吁业界、政府、民间、技术各方共同参与生态改革。

文章标题：使用SVG Emoji作为网站图标（2022）

本文介绍了Lea Verou提出的一个巧妙想法：使用表情符号（Emoji）作为网站图标（Favicon）。这一想法的可行性基于浏览器对SVG格式图标的最新支持。其核心方法是将一个Emoji字符嵌入到SVG的<text>元素中，并将整个SVG作为图标使用。

实现方法： 文章提供了一个单行代码示例，直接在HTML中通过内联的Data URI实现：

<link rel="icon" href="data:image/svg+xml,<svg xmlns=%22http://www.w3.org/2000/svg%22 viewBox=%220 0 100 100%22><text y=%22.9em%22 font-size=%2290%22>🎯</text></svg>">

演示与兼容性： 作者创建了一个演示项目来展示该技术。兼容性方面，此方法在Firefox和Chrome浏览器中有效，但在Safari中不支持，因为Safari对SVG图标采用“遮罩”风格，可能会导致显示问题。作者鼓励用户自行尝试Safari的兼容性。

相关扩展思路：

1. 动态徽章：Ada Rose Cannon扩展了这一想法，制作了一个可以递增的徽章图标。
2. 开发环境标识：Taylor Hunt分享了一种方法，利用当前Git分支名称来动态生成不同的SVG图标，这与“为开发环境使用不同图标”的思路相关。
3. 深色模式适配：理论上可以在SVG内部嵌入prefers-color-scheme媒体查询来为深色模式做特殊处理，不过由于Emoji在任何背景下通常都表现良好，此步骤可能并非必需。

Windows 11 与 Ubuntu 24.10 在 Intel Core Ultra 7 Lunar Lake 上的性能对比

该文章通过一系列基准测试，比较了 Windows 11 和 Ubuntu 24.10 操作系统在搭载 Intel Core Ultra 7（Lunar Lake）处理器的 ASUS Zenbook S 14 笔记本电脑上的 CPU 性能。

主要测试结果：

• 渲染类基准测试（仅CPU）： 在 Blender（BMW27、Junkshop、Fishy Cat）、IndigoBench（Bedroom、Supercar）、Sunflow Rendering System 以及 Chaos Group V-RAY 等多个以 CPU 为主的渲染测试中，Ubuntu 24.10 均比 Windows 11 表现出更快的速度。文章指出，这符合此前在其他硬件上观察到的 Linux 在 Blender 渲染中通常优于 Windows 的规律。
• 综合性能： 在所有测试结果的几何平均值中，Ubuntu 24.10 的整体性能平均比 Windows 11 快约 14%。

结论与对比：

• 在CPU 性能方面，Ubuntu 24.10 明显优于 Windows 11。这与在其他 Intel Core 和 AMD Ryzen 硬件上观察到的趋势一致，即 Ubuntu 在多种 CPU/系统基准测试中通常能胜过 Windows。
• 尽管 Lunar Lake 的 Xe2 显卡在 Linux 上的性能不如 Windows（这是一个已知问题，正在与 Intel 协同调查），但本次测试表明，在 CPU 方面 Linux 表现非常出色，排除了 Lunar Lake 存在根本性 Linux 兼容性问题的可能性。

文章最后表明，Phoronix 将继续发布更多关于 Intel Lunar Lake 的 Linux 基准测试。