文章通过两位内容创作者John和Zack的对话，探讨了自由职业与顾问工作中关于金钱、定价和客户关系的核心原则，主要观点如下：

1. 避免固定价格合同

• 固定价格会形成不良的激励结构：客户希望压低价格并榨取更多价值，而顾问则倾向于用最低成本完成工作，缺乏后续支持的动力。
• 推荐采用按小时收费的方式，并提供详细的时间估算。这既给予客户成本控制权，又能让顾问专注于交付价值，并允许客户在早期灵活终止合作。

2. 顾问应如“农夫”而非“猎手”

• “猎手”追求短期暴利，但长期会消耗精力并损害声誉；“农夫”则注重维护客户关系，通过持续提供价值获得长期业务。
• 重复业务优于不断寻找新客户，因为营销成本高且成功率低。建立良好口碑后，客户会主动上门。

3. 定价策略：敢于高定价

• 人们常低估自己的价值，导致定价过低。应采取“报出令自己尴尬的价格”作为起点，并随经验积累逐步提价。
• 高价具有“查尔斯·里格效应”：客户倾向于认为高价格代表高质量，并更重视高付费获取的建议。反之，低价可能让客户质疑专业能力。
• 不要谈判价格：寻求折扣的客户往往最苛刻，后续可能提出更多额外要求。除非生存必需，否则应婉拒此类客户。

4. 接受客户可能不采纳建议

• 有时客户因自身局限（如预算、内部政治）无法采纳顾问建议。此时无需争执，可提出“Bitfield顾问第一定律”：客户有时需要先体验不听建议的痛苦，才会真正尊重后续建议。

5. 核心心态：客户需要的是“安心”

• 客户支付高费用，本质是购买“将问题转交给专家”的安心感。顾问需在提供真实价值的同时，保持专业自信。
• 引用《顾问的秘诀》中的名言：“确保他们支付足够费用，这样他们才会听你的”——高价能增强建议的影响力。

总结：成功的顾问关系建立在公平定价、长期思维与双向尊重的基础上。顾问应通过专业价值赢得信任，避免因金钱压力妥协原则，最终实现可持续的合作。

英国战后糖热潮证实生命早期甜食饮食的危害

研究背景与契机

1953年，英国结束了二战期间实施的糖果和糖配给制度。随后一年内，该国糖消费量翻倍。这一人口层面的饮食剧变为研究生命早期糖摄入对长期健康的影响提供了独特的自然实验机会。

研究方法

研究人员结合1950年代的英国食品调查、糖销售数据，以及英国生物样本库中超过6万名1951-1956年出生成年人的医疗记录。分析聚焦于配给制结束前后受孕或出生的个体，对比其生命早期（从受孕到2岁，共1000天）糖暴露量的差异。

主要发现

1. 疾病风险关联：与1953年9月糖配给结束后受孕的个体相比，之前受孕（出生后经历糖配给）的个体患2型糖尿病的风险降低约15%，高血压风险降低约5%。
2. 剂量反应关系：在生命最初1000天内，经历糖配给的时间越长，后期健康获益越显著。在配给制结束前达到1.5岁的婴儿，其糖尿病风险降低高达40%，高血压风险降低20%。女性在糖尿病风险降低方面的表现比男性更明显。
3. 特异性验证：研究未发现糖配给结束对与糖无明显关联的疾病（如近视或主要由基因决定的1型糖尿病）产生影响，这增强了结果指向糖摄入的说服力。

潜在机制

研究者提出几种可能解释早期糖暴露导致后期疾病的途径：

• 子宫内糖暴露可能影响胎儿代谢系统的发育。
• 婴儿期高糖饮食可能培养对甜食的偏好，导致成年后摄入更多糖。研究团队已获得支持此机制的初步证据。

研究意义与局限

• 科学价值：该研究被认为是首个在人群中清晰展示生命早期糖摄入与成年后代谢疾病因果关联的“自然实验”，其“剂量反应”关系尤其具有说服力。
• 公共卫生启示：结果支持目前公共卫生建议，即生命最初1000天应避免添加糖。研究可能推动旨在改善母婴健康、预防慢性病的政策讨论，如税收、食品配方监管、标签和公众意识运动。
• 研究局限：英国生物样本库参与者以白人和高收入人群为主，可能限制结果的普遍性。同时，仍需注意1953年前后出生人群之间可能存在的其他未被识别的混杂差异。

社会环境背景

研究者强调，当前环境中，即使家长有意遵守健康指南，在充斥着含糖食品的环境中也非常困难，这种挑战从生命早期便已开始。因此，责任不应归咎于家庭个体。

项目概述

这是一个众包项目，旨在让人类集体读出最新发现的最大已知质数——梅森质数 M136279841（约4100万位数字）的所有数字。目标是创建一个YouTube播放列表，展示人类首次（可能也是最后一次）完整说出这个质数的视频，希望在下一个更大质数被发现前完成。

当前进度

• 总体完成度：0.341%

如何参与

1. 领取数字块：从项目网站预订一个419位的数字分块。
2. 录制视频：读出你的数字块（约需3.5分钟），并上传至YouTube，确保视频标记为“not for kids”。
3. 提交链接：返回项目网站提交视频链接，视频将被添加到官方播放列表中。

关键指导原则

• 视频要求：横向拍摄、确保声音清晰、良好照明；手机拍摄即可。
• 灵活性：可以露脸或不露脸；可多人参与（需获得许可）；允许错误和纠正；可编辑多个片段。
• 语言：不限英语，支持任何语言或手语。
• 速度建议：推荐每秒2位数字（120bpm），但可按个人节奏进行。
• 上传细节：视频可设为未列表状态，但需提供链接以供播放列表使用。

项目背景

• 目的：纯粹为了乐趣和挑战，体现“无意义但有趣”的集体努力。
• 质数信息：梅森质数 M136279841 由 Mersenne.org 发现，项目组织者提供了视频解释。
• 风险：若在完成前发现更大质数，项目可能失败。

组织者

项目由 Ayliean、Katie Steckles 和 Matthew Scroggs 运营，他们通过 Patreon 接受支持以资助类似项目。

Someday：开源Calendly替代方案（针对Gmail用户）

核心概述 Someday 是一个免费、开源的日程安排工具，专为 Gmail 用户设计，作为传统日程应用（如 Calendly、Cal.com）的替代品。它基于 Google Apps Script 构建，可免费托管，并通过 clasp 进行管理。

主要特性

• 免费托管：利用 Google Apps Script，通过您的 Google 账户免费托管。
• 完全开源：代码公开，欢迎社区贡献。
• 无缝集成：作为 Google Apps Script，与 Gmail 深度集成，方便在收件箱内管理日程。
• 开发者友好：采用 React、TypeScript、Shadcn/UI 和 Vite 等现代技术栈构建，易于定制和扩展。
• 可定制工作时间：可精确设置可用时段。
• 简洁预订流程：用户可选择日期和时段，并填写简单的表单（姓名、邮箱、电话、可选备注）。
• 隐私优先：数据仅在 Google 生态内处理，不与第三方共享。

技术栈与自托管

• 前端：React + TypeScript + Vite + Shadcn/UI。
• 后端/逻辑：Google Apps Script。
• 项目提供示例 HTML 文件（hosted-iframe-example.html），可自行托管以移除 Google Apps Script 的默认横幅，或通过 GitHub Pages 等服务嵌入 iframe。

快速开始

1. 定制化：修改后端文件（backend/src/app.ts）中的变量来自定义可用性设置，例如：主日历、时区、工作日、工作小时和时段时长。
2. 开发：进入前端目录（./frontend），运行 npm install 和 npm run dev。开发时，可使用 generateDummyData 函数生成模拟数据。
3. 安装与部署：
   • 环境准备：确保安装 Node.js，并全局安装 clasp (npm install -g @google/clasp@^2.5.0)。使用 clasp 登录 Google 账户，并启用 Apps Script API。
   • 创建与部署：使用 clasp create --type webapp 创建项目，然后使用提供的部署命令进行部署。
   • 关键授权步骤：部署后必须运行脚本中的 fetchAvailability 函数并进行授权，通过“高级”选项允许访问。

日历访问

• 默认使用用户的“主日历”。
• 可通过修改 CALEDAR 变量指定其他日历，需确保拥有相应权限。
• 支持多日历，需在 Apps Script 编辑器的“脚本属性”中添加一个名为 CALENDARS 的属性，其值为逗号分隔的日历 ID 列表。

常用命令

• npm run deploy：构建并部署。
• npm run build：仅构建。
• clasp open：打开脚本编辑器。
• 项目提供 undeployall.sh 和 deployments.sh 脚本用于管理部署版本和查看 Web 应用 URL。

贡献与许可 项目欢迎通过提交 Pull Request 或 Issue 进行贡献，包括错误修复、功能请求和文档改进。采用 MIT 许可证。

Cloudflare 错误 522：连接超时

错误详情

• 错误代码：522
• 发生时间：2026-05-29 02:23:56 UTC
• 原因：Cloudflare 网络与原始 Web 服务器之间的初始连接超时，导致网页无法显示。这意味着请求能连接到服务器，但未能完成。

解决方案

• 对于网站访问者：建议稍后重试。
• 对于网站所有者：
  • 联系托管提供商，告知 Web 服务器未完成请求。
  • 错误 522 通常由服务器资源占用过高引起，需要进一步排查。

技术信息

• Cloudflare Ray ID：a03209c31c47cb7a
• 用户 IP：153.3.251.216
• 性能与安全：由 Cloudflare 提供。

英伟达GeForce GPU发现安全漏洞，需立即更新驱动

主要漏洞概述

• 漏洞数量与严重性：共发现8个安全漏洞，均被标记为高危（High）。
• 潜在风险：攻击者可利用这些漏洞完全控制系统，从而在受感染的PC上植入并执行恶意代码，并读取、窃取个人数据。
• 影响范围：
  • 受影响产品：所有 NVIDIA GeForce GPU，同时影响 RTX、Quadro、NVS 和 Tesla 系列显卡。
  • 受影响系统：Windows 和 Linux 操作系统。

漏洞详情与响应

• 英伟达已在安全公告中发布了相关信息，但未明确说明这些漏洞是否已在外被实际利用。
• 鉴于漏洞波及所有GeForce显卡，其影响范围可能相当广泛。

紧急修复措施

用户需立即更新至指定版本的显卡驱动程序。

1. Windows 系统更新版本：

   • GeForce 驱动：版本号 566.03 或更新。
   • RTX / Quadro / NVS 驱动：版本号 566.03、553.24 或 538.95 或更新。

2. Linux 系统更新版本：

   • GeForce 驱动：版本号 565.57.01、550.127.05 或 535.216.01 或更新。
   • 部分分发商提供的安全更新版本可能为 565.92、561.03、556.35 或 553.05。

获取更新的途径

• 通过 NVIDIA Manual Driver Search 工具手动搜索并下载对应驱动。
• 在 NVIDIA App 或 GeForce Experience 应用程序中获取最新驱动更新。

Ractor – Rust Actor 框架概述

Ractor 是一个受 Erlang 启发的 Rust Actor 框架，旨在提供符合 Actor 模型的并发编程支持。

核心概念

• 消息传递方式：支持两种模式，借鉴 Erlang 命名。
  • cast：发送消息后立即返回（fire-and-forget）。
  • call：发送消息并等待回复（阻塞式远程过程调用）。

安装

在 Cargo.toml 中添加依赖：

[dependencies]
ractor = "0.13"

基础 Actor 示例（无状态）

1. 定义消息类型：枚举 MyFirstActorMessage，包含 PrintHelloWorld 变体。
2. 定义 Actor 结构体：MyFirstActor。
3. 实现 Actor trait：
   • 必需的类型关联：
     • State：Actor 状态类型，无状态时为 ()。
     • Msg：消息类型。
     • Arguments：启动参数类型。
   • 必需方法：
     • pre_start：Actor 启动前的初始化，返回初始状态。
     • handle：处理接收到的消息。
4. 运行：
   • 使用 Actor::spawn 创建 Actor，获得 ActorRef 和任务句柄。
   • 通过 actor.cast 发送消息。
   • 使用 actor.stop 停止 Actor 并等待任务完成。

带状态的 Actor 示例（使用 RPC）

1. 修改消息类型：增加 HowManyHelloWorlds 变体，包含一个 RpcReplyPort 参数用于接收回复。
2. 修改 Actor：
   • 将 State 类型改为 u16 以存储计数。
   • 在 pre_start 中初始化状态为 0。
   • 在 handle 中：
     • 处理 PrintHelloWorld 时增加计数并打印。
     • 处理 HowManyHelloWorlds 时通过 reply.send 发送当前计数。
3. 运行：
   • 发送多个 PrintHelloWorld 消息。
   • 使用 call_t! 宏进行带超时（100ms）的 RPC 调用，查询打印次数。

关键宏

• cast!：等效于 actor.cast，非阻塞发送消息。
• call!：等效于 actor.call，构建并等待 RPC 回复。
• call_t!：与 call! 类似，但带超时参数。

此示例展示了如何构建有状态的 Actor 并通过 RPC 机制进行请求-响应式通信。

文章标题：下一代带外垃圾回收

核心背景：
Shopify 之前优化了 Ruby 垃圾回收（GC）以减少主收集（major GC）对请求延迟的影响，但基于平均值的触发机制存在不足：需在延迟与容量间权衡，且无法完全避免请求周期内的主收集。

新方案构想：
2023年底，团队提出全新思路——在请求周期内完全禁用主GC，仅在请求外按需触发。理想情况下，除缓存等少数情况外，请求中分配的对象不应存活过长，否则可能是状态泄漏或应预加载。因此，避免在请求内将对象晋升到老年代，可减少无用的晋升开销。

Ruby 3.4 新增功能：
团队开发了 GC.config(rgengc_allow_full_mark: true/false) 方法，用于完全禁用/启用自动主收集。同时，GC.latest_gc_info(:needs_major_by) 可检查是否需要执行主GC。该功能已纳入 Ruby 3.4.0-preview2。

实施与效果：
Shopify 在50%的生产服务器上启用新实现，效果显著：

• 延迟大幅改善：p95/p99/p99.99 尾部延迟显著下降；中位数延迟意外提升。
• 整体服务优化：平均延迟降低5%，p99延迟降低10%。
• 容量影响有限：频繁部署时效果不明显，但部署间隔较长时，带外收集运行频率更低。

技术实现：
借助 Pitchfork 的钩子，实现极为简洁：

1. 工作进程 fork 后禁用主GC：GC.config(rgengc_allow_full_mark: false)。
2. 请求完成后检查是否需要主GC，并手动触发：GC.start。

后续计划：
在解决主GC后，团队将关注小GC（minor GC）优化。目标是利用 GC.stat 启发式规则，在带外预先触发小GC，使大部分请求完全无需经历GC。但预计收益较小，因小GC本身在大型单体应用中已较快。

谷歌数据中心网络25年演进：速度、规模与可靠性

谷歌网络基础设施历经25年发展，从最初相对简单的结构演变为技术先进、规模空前的系统。这一演进由指数级增长的用户和数据需求驱动，最终形成了当前第五代Jupiter数据中心网络架构，其二分带宽可扩展至13 Pb/s（相当于可为全球80亿人每人支持一个视频通话）。如今，全球部署了数百个Jupiter架构，同时支撑着数百项服务、数十亿用户、云客户以及大规模ML训练和推理基础设施。

指导原则 网络演进遵循几个核心原则：

1. 任何任务，任何地点：支持在拥有10万+服务器的同一网络架构内大规模部署任务，提升应用性能并消除内部碎片。
2. 可预测的低延迟：通过预留带宽余量、保持99.999%可用性以及主机与网络架构协作管理拥塞，确保性能一致并最小化尾延迟。
3. 软件定义与系统中心化：利用软件定义网络（SDN）实现灵活性，每两周在全球范围内发布数十项新功能。
4. 增量演进与动态拓扑：支持对网络进行分部件升级（而非整体停机），结合光电路交换（OCS）和SDN，实现物理层就地升级，并能在一个网络架构中支持多代硬件，动态适应工作负载变化。
5. 流量工程与应用中心化服务质量（QoS）：优化流量并根据应用需求定制网络服务。 这些原则共同构成了网络作为所有计算服务（从存储到AI）可靠性基础的基石。网络必须“最后失效且失效最少”。为此，谷歌严格定义并监控全球网络中每个集群和数百万端口上的每一个“坏分钟”（即网络流量出现超过阈值中断的分钟）。其自研、软件定义的Jupiter网络提供的可靠性比以往版本高出50倍。

网络能力里程碑

• 2015年 - Jupiter，首个Petabit网络：发布论文，展示了利用商用交换芯片、Clos拓扑和SDN将Jupiter网络扩展至1.3 Pb/s总带宽。此速率一度超过当时全球互联网的估计总IP流量。
• 2022年 - 实现6 Pb/s：通过深度集成光电路交换（OCS）、波分复用（WDM）和可扩展的Orion SDN控制器，将Jupiter网络扩展至6 Pb/s以上，支持了增量构建、性能提升、成本与功耗降低、动态流量管理和无缝升级。
• 2023年 - 13 Pb/s网络：进一步增强Jupiter，支持网络核心原生400 Gb/s链路速度。基本构建模块（聚合块）现包含512个400 Gb/s端口，提供204.8 Tb/s双向无阻塞带宽。支持64个此类模块，总二分带宽达13.1 Pb/s。该技术已应用于生产数据中心超过一年，驱动着AI、ML、网络搜索等数据密集型应用的发展。

面向AI时代的未来展望 在庆祝20多年创新的同时，谷歌正为AI时代规划下一代网络基础设施。例如，正在为即将推出的A3 Ultra VM（配备NVIDIA ConnectX-7网络，支持每服务器3.2 Tbps的GPU间非阻塞流量）以及基于NVIDIA GB200 NVL72的未来产品构建网络基础设施。 未来几年，将在网络规模、每端口及全网带宽方面取得重大进展。将继续推动主机集成（包括传输和拥塞控制栈）的边界，简化网络阶段以实现更低延迟和更紧的尾部延迟。实时拓扑工程、与计算和存储栈的更深层集成，以及主机负载均衡技术的持续改进，将进一步增强网络的可靠性和降低延迟。这些创新将确保网络继续作为支持全球用户变革性应用和服务以及内部和云产品突破性AI能力的基石。

文章摘要：Spann: 高效十亿级近似最近邻搜索

本文针对大规模数据库中内存近似近邻搜索（ANNS）算法成本过高的问题，提出了一种高效、低成本的内存-磁盘混合索引与搜索系统SPANN。该系统遵循倒排索引方法，将发布列表的质心点存储在内存中，而将较大的发布列表存储在磁盘上。

核心设计与挑战

SPANN的目标是同时保证磁盘访问的低延迟和搜索的高召回率。其核心挑战在于在利用磁盘存储海量数据的同时，有效控制磁盘访问次数并确保检索到的发布列表具有高质量。

关键技术创新

为实现目标，SPANN在索引构建和搜索两个阶段引入了关键创新：

1. 索引构建阶段：

   • 采用分层平衡聚类算法来平衡各发布列表的长度，避免某些列表过长导致磁盘访问效率低下。
   • 通过向每个发布列表添加其对应聚类闭包内的点，增强了列表，从而提升了召回率。

2. 搜索阶段：

   • 使用一种查询感知的动态剪枝方案，能够根据查询内容智能地跳过对不必要的发布列表的访问，从而大幅减少磁盘I/O操作。

实验结果

在三个十亿级数据集上的实验表明，SPANN的性能显著优于现有的最优磁盘ANNS解决方案DiskANN：

• 在相同的内存成本下，要达到90%的召回率，SPANN的速度是DiskANN的2倍。
• 仅需32GB内存，即可在约1毫秒内实现recall@1和recall@10达到90%。

结论

SPANN是一个简单而高效的内存-磁盘混合ANNS系统，通过在索引构建时平衡并增强发布列表，在搜索时动态剪枝不必要的磁盘访问，成功地在极低的内存开销下，为十亿规模数据集提供了高速、高召回率的近似最近邻搜索服务。

文章标题：使用JavaScript在浏览器中通过HackRF进行汽车重放攻击

项目背景：作者此前利用RTL-SDR在浏览器中实时接收飞机数据，为探索软件定义无线电（SDR），购入支持收发数据的HackRF One设备。目标是验证能否仅用JavaScript在浏览器中实现汽车黑客攻击，并成功开发了相关工具。

重要声明：本文仅用于教育目的。使用SDR设备需遵守当地法规，未经明确授权复制实验可能违法，作者不承担任何使用责任。

技术实现：

• 设备连接：通过WebUSB API在浏览器中连接HackRF设备。使用navigator.usb.requestDevice指定设备过滤器（供应商ID 0x1d50，产品ID 0x6089），通过device.open()、device.selectConfiguration(1)和device.claimInterface(0)完成连接。
• 参数设置：
  • 增益：使用controlTransferIn设置LNA增益，参考HackRF SDK和libusb文档，请求类型为HACKRF_VENDOR_REQUEST_SET_LNA_GAIN。
  • 采样率：使用controlTransferOut设置，请求类型为HACKRF_VENDOR_REQUEST_SAMPLE_RATE_SET。
  • 频率：使用controlTransferOut设置，请求类型为HACKRF_VENDOR_REQUEST_SET_FREQ。
• 数据接收：将设备设为接收模式（HACKRF_TRANSCEIVER_MODE_RECEIVE），通过transferIn获取实时数据，可用Canvas API可视化。
• 数据记录：使用File System Web API选择文件，将接收数据写入文件。
• 数据传输：加载记录文件，设置设备为传输模式（HACKRF_TRANSCEIVER_MODE_TRANSMIT），设置传输增益，通过transferOut发送数据。

Rolljam攻击原理：

• 汽车通常使用滚动码系统防止重放攻击，但rolljam攻击通过干扰汽车接收器同时记录钥匙信号，之后重放信号实现入侵。
• 实现需两台HackRF设备：一台记录信号，另一台发射干扰数据（随机数据传输）。
• 作者演示了在浏览器中运行此攻击，成功黑客汽车（经授权）。

应用场景：该方法可扩展用于门铃、车库门、无人机等任何RF遥控设备。

结论：项目验证了用JavaScript在浏览器中黑客汽车的可能性，技术部分仍在改进中，如数据二进制分析功能未完成。

《有限元法八十年发展综述》摘要

本文系统回顾了自1941年诞生至今的有限元法八十年发展历程，将其划分为四个主要阶段，并概述了其在科学与工程领域的深远影响及未来趋势。

一、发展历史分期

1. 诞生与早期（1941–1965）

   • 起源：1941年，Hrennikoff 和 Courant 的工作奠定了离散化与变分法基础。1950年代，Turner、Clough、Martin 和 Argyris 等人发展了矩阵刚度法。1960年，Clough 正式提出“有限元法”术语。
   • 关键进展：三角形单元的提出被视为“量子跃迁”。冯康在中国独立提出了基于变分原理的差分方法。此时期确立了方法基础，至1965年相关论文已超千篇。
   • 软件萌芽：Wilson 和 Clough 开发了早期有限元程序，Oden 与 Best 编写了包含多种单元的通用有限元代码。

2. 黄金时代（1966–1991）

   • 理论基础夯实：Aubin、Babuška 等数学家建立了严格的逼近理论，证明了最优收敛性。
   • 重要方法与技术突破：
     • 混合元与稳定性：Pian 提出假设应力元；Babuška-Brezzi (LBB) 条件为混合有限元提供了稳定性判据。
     • 动态与流体：发展了 Newmark-beta 等时间积分法；Belytschko 等发展了显式积分法，成为汽车碰撞分析的关键。Hughes 等发展了流线迎风/Petrov-Galerkin (SUPG) 等稳定化方法，以有效求解 Navier-Stokes 方程。
     • 几何非线性：Simo 等人发展了几何精确梁/壳理论和一致切线算子。
     • 流固耦合：任意 Lagrangian-Eulerian (ALE) 方法被提出用于解决移动边界问题。
     • 其他进展：随机有限元、形状优化、接触算法、混凝土损伤模型、应变软化与非局部模型的研究均取得显著进展。

3. 大规模工业应用与材料建模（1992–2017）

   • 误差估计与自适应：Zienkiewicz-Zhu 后验误差估计器推动了自适应网格细化。
   • 高阶与扩展方法：hp-FEM 实现了指数收敛；广义/扩展有限元法 (GFEM/X-FEM) 和相场法用于模拟断裂。
   • 无网格法：光滑粒子流体动力学 (SPH)、再生核粒子法 (RKPM)、无单元 Galerkin 法 (EFG) 等兴起，为解决网格畸变问题提供了新途径。
   • 多尺度与集成：等几何分析 (IGA) 实现了 CAD 与 FEA 的集成；计算均匀化方法用于多尺度材料模拟。
   • 材料本构：晶体塑性有限元法 (CPFEM) 和基于内变量的损伤模型得到发展。

4. 当前与未来（2018–）

   • 与机器学习融合：深度神经网络被用于求解偏微分方程（如物理信息神经网络 PINNs、深度 Ritz 法）。HiDeNN 等框架试图构建基于深度学习的有限元形函数。
   • 降阶模型：本征正交分解 (PGD)、超缩减等方法用于加速计算，以满足实时仿真与数字孪生需求。
   • 数据驱动计算：结合物理规律与数据的“机理数据科学”方法，以及自洽聚类分析 (SCA) 等用于高效多尺度模拟。

二、应用领域

有限元法已革命性地改变了科学建模与工程设计，广泛应用于：

• 固体力学与结构工程：航空航天、汽车、船舶、建筑、大坝分析。
• 流体力学：空气动力学、流固耦合。
• 多物理场：传热、电磁学、生物力学（如心血管疾病建模、手术规划）。
• 其他领域：半导体设计、增材制造、材料科学、可靠性分析。

三、关键贡献者

文章强调了众多先驱与学者的核心贡献，包括但不限于：Courant, Hrennikoff, Argyris, Clough, Zienkiewicz, Turner, Martin, Przemieniecki, Babuška, Hughes, Belytschko, Oden, Simo, Taylor, Liu 等。

四、结论

从离散化思想的萌芽，到理论的严密建立，再到工业软件的普及和与人工智能的深度融合，有限元法历经八十年发展，已成为工程与科学计算中不可或缺的核心技术。未来，其发展将继续与数据科学、机器学习及高性能计算紧密结合，向更智能、高效和集成的方向演进。

本文档是认证与授权领域的术语表，涵盖了核心概念、协议、流程和安全机制。主要内容可归纳为以下几个类别：

一、 访问控制机制

• 访问控制：定义并强制执行谁可以对何种资源执行何种操作的策略。
• 基于角色的访问控制 (RBAC)：通过角色（而非直接向用户）分配权限来管理访问权。
• 基于属性的访问控制 (ABAC)：利用用户、资源、环境等属性做出动态访问决策。
• XACML：用于表达ABAC策略的XML标准。

二、 认证机制与流程

• 单点登录 (SSO)：允许用户使用一套凭证访问多个系统。
• 多因素认证 (MFA)：要求用户提供两种或以上形式的证明。
• 无密码认证：不使用密码进行登录，例如通过魔术链接（一次性URL）或通行密钥。
• 设备流：适用于输入受限设备，用户通过另一台设备上的代码完成授权。
• 备份代码：当主要MFA方式不可用时使用的备用一次性代码。

三、 OAuth 2.0 与 OpenID Connect (OIDC) 授权流程

• 授权码流：安全的流程，应用通过交换授权码获取访问令牌。
• 隐式流：直接为客户端应用（如SPA）在URL片段中返回令牌（现已不推荐）。
• 混合流：结合授权码流和隐式流。
• 客户端凭据流：用于机器对机器通信，客户端直接使用自身凭据获取令牌。
• 授权请求 / 认证请求：分别用于OAuth 2.0授权和OIDC用户认证的起点。
• PKCE：增强OAuth 2.0安全性的扩展，防止授权码被截获滥用。

四、 令牌体系

• JWT：紧凑、自包含的令牌格式，用于在各方之间安全传输信息。
• JWK/JWKS：表示和管理加密密钥的JSON格式。
• JWS/JWE：分别用于签署和加密JWT的标准。
• 访问令牌：代表授权，用于访问受保护资源。
• 刷新令牌：长期有效的凭证，用于获取新的访问令牌。
• ID令牌：OIDC中向客户端证明用户身份的JWT。
• 不透明令牌：无意义的随机字符串，服务器用其查找实际数据。
• 范围：定义应用程序请求的访问权限级别。
• 声明：JWT中的名值对，携带特定信息（如用户ID、受众等）。

五、 身份管理与联合

• 身份与访问管理 (IAM)：管理数字身份和资源访问的完整流程与技术。
• 身份提供商 (IdP)：管理用户身份的服务，支持OIDC/OAuth。
• 服务提供商 (SP)：依赖IdP进行认证的应用或服务。
• SAML：在IdP和SP之间交换认证和授权数据的XML标准。
• OIDC发现：允许客户端自动发现OIDC提供者端点和配置的机制。
• 即时配置 (JIT)：用户首次登录时自动创建其账户。

六、 API与资源管理

• API密钥：用于验证客户端身份的密钥。
• 管理API：用于以编程方式管理IAM资源（如用户、应用）的API。
• Webhook：应用间实时通信的方法，用于响应特定事件。
• 资源指标：OAuth 2.0中用于指定资源服务器位置的扩展参数。
• 授权服务器元数据：标准化的服务器信息格式，用于客户端自动配置。
• 受保护资源元数据：关于受保护资源（资源服务器）的标准化信息。

七、 安全与协议考量

• 客户端凭据：用于验证客户端身份的密钥。
• 受众：令牌的预期接收者，确保令牌被正确服务使用。
• 令牌自省：客户端向授权服务器查询令牌有效性和元数据的OAuth扩展。
• 资源服务器：托管受保护资源并验证访问令牌的服务器。
• 资源所有者：可以授予对其资源访问权的实体（通常是用户）。
• CSRF防护：防止跨站请求伪造攻击的安全措施。
• 重定向URI：授权请求后用户代理被重定向到的URI。

八、 企业功能与治理

• 企业SSO：专为组织内员工设计的SSO。
• 多租户：单应用实例为多个租户（客户）提供服务并隔离数据的架构。
• 权限：定义角色中允许的具体操作。

Intel可能太大而不能倒

美国立法者正在悄悄讨论一系列后备方案，以在Intel财务状况恶化时提供帮助，这些讨论超出了《芯片与科学法案》（CHIPS Act）的范畴（该法案将在2024年底前授予Intel至少85亿美元）。尽管这仅是预防性的应急计划，且Intel在2024年第三季度财报中给出了强劲展望，但这些讨论凸显了华盛顿对Intel的高度重视，尤其是在美中争夺全球先进技术主导权的背景下。

Intel对美国至关重要，原因在于：

1. 核心制造能力：它是美国唯一一家同时设计和制造尖端芯片的公司。发言人强调，Intel是“美国唯一一家设计和制造领先芯片的公司，在推动全球竞争力的美国半导体生态系统中发挥着关键作用”。若Intel失败，美国将不得不依赖在美建厂但产能有限的台积电（TSMC）和三星，而这两家公司的总部所在地（台湾和韩国）因靠近中国而存在地缘政治风险。
2. 经济与安全支柱：Intel是美国顶级出口商，2023年出口收入超过400亿美元。此外，它还与美国国防部的“安全飞地”（Secure Enclave）计划合作，为军方制造尖端芯片，这对国家经济与安全都至关重要。即使计划裁员超过16,000人，其员工总数仍超过12万人，是主要雇主。

目前，政策制定者倾向于避免像2008年对克莱斯勒和通用汽车那样的直接巨额救助。他们考虑的一种解决方案是推动政府鼓励的私营部门合并，潜在对象可能是AMD或Marvell等竞争对手。此前已有传言称Arm和高通有意收购Intel部分或全部业务，但一些专家警告，拆分Intel可能对各方无益。

文章最后指出，Intel的18A芯片技术已展现希望，亚马逊等公司已承诺采用。若一切顺利，Intel有望自行恢复竞争力。尽管如此，美国政府为应对意外情况准备后备计划并无坏处。

文章标题： Making Pop Rocks from scratch (is complicated) [video]

视频基本信息：

• 标题： Making pop rocks from scratch (is complicated)
• 频道： NileBlue（经过认证，拥有346万订阅者）
• 播放量： 8,064,201次
• 点赞数： 337,403
• 发布时间： 2024年11月2日

内容概要： 该视频是NileBlue频道发布的一期科学实验内容，核心主题是尝试从头开始（from scratch）制作经典的碳酸糖零食——Pop Rocks（跳跳糖）。视频强调了这一过程的复杂性。创作者提到，此前他们曾尝试过一些简单的“家庭配方”，但最终决定采用真正的方法，而这种方法由于涉及高压和高温，不仅更加昂贵，而且具有潜在的危险性。视频中展示的实验使用了在线购买的专用高压机器，需要精确称量蔗糖、乳糖和玉米糖浆，并配合高强度热量和工业级调味剂，才能成功将二氧化碳气体困在糖粒中。视频描述中包含赞助商链接（Brilliant.org）以及创作者团队的相关产品（NileRed BZ反应套装）预售信息。

相关链接与社区信息：

• 主要频道： NileRed（NileBlue是其副频道）
• 社交媒体： Patreon、Discord、Facebook、Instagram、Twitter等链接均提供在描述中。
• 视频关联： 视频末尾链接了NileRed关于“化学很危险”的实验室安全讨论视频。
• 推荐内容： 页面侧边栏和结束画面推荐了同一频道及其他类似科技、化学主题创作者（如NileRed、styropyro、I did a thing等）的多个视频。

技术与页面结构说明（非视频内容，为页面元数据）：

• 此内容为YouTube视频页面的HTML源代码，包含了播放器初始化脚本、配置数据、实验特性标志、客户端上下文、大量UI组件（如按钮、菜单、面板）的结构化数据（JSON），以及用于页面渲染的CSS和JavaScript。
• 页面配置中包含多种播放器上下文（如观看页、频道页、短片等），并启用了大量实验性功能标志。
• 数据中还包括了用户交互相关的实体信息（如点赞状态、订阅状态）和视频的章节/标记数据（如热度图）。