Hot Page – 图形化网站构建工具

Hot Page 是一个拖放式代码编辑器，旨在帮助用户无需编写复杂代码即可构建独特网站设计。该平台定位为“是代码”平台，解决了传统“无代码”工具的功能限制问题，让普通用户也能利用自由形式网页开发的强大能力。

核心功能与优势：

• 专业工具，简化流程： 用户可使用真实的 HTML、CSS 和 JavaScript 构建网站，同时借助可视化工具，无需处理复杂的部署和托管事宜。
• 免费起步： 提供免费计划，允许用户创建网站并使用自定义域名，仅在需要更多高级选项时才需升级。
• 开放平台，自由迁移： 平台具有高度开放性，用户可随时下载自己的网站代码，自行托管到任何地方，没有平台锁定风险。
• 强大的技术兼容性： 用户可以自由使用任何前端框架、自定义元素、开源代码片段或网络 API。平台鼓励利用现有开源资源来实现各种功能。
• 输出高效清洁代码： 生成简洁、语义化的代码，确保网站响应迅速、加载速度快，这对 SEO、用户体验和转化率至关重要。
• 学习与技能提升： 对于学习者，Hot Page 是一个在实际项目中学习和实践核心 Web 开发技能的工具，所学技能基于 Web 标准，具有长期价值。对于熟练开发者，它则是一个高效的设计与构建工具。

用户反馈摘要： 多位来自不同背景的用户（开发者、设计师、营销人员、爱好者、性能工程师）对 Hot Page 给予积极评价，主要称赞点包括：

• 让用户专注于页面构建的创意部分。
• 能够直接运用 CSS 的强大设计能力。
• 能快速构建和调整多个营销微站点。
• 能够使用最新的 CSS 特性和 Web 平台 API。
• 输出的网站性能优异，加载速度快。

平台还提供“HotFX”特效库，用于为网站添加色彩和动效。此外，用户可以注册新闻通讯以获取灵感和最新动态。

独立企业使用大通银行（Chase Bank）的警示与教训

事件概述

作者是一名AI顾问和小企业主，拥有十多年大通银行个人账户历史。在创办新业务并开设大通商业银行账户后，四个月内积累了约18万美元。然而，大通银行在无任何预警和解释的情况下突然冻结了该账户，导致作者无法支付员工工资，业务险些陷入停滞。

艰难的维权过程

事发时作者身处加拿大等待签证，初期沟通严重受阻，客服仅表示将邮寄本票但迟迟未兑现。作者随后多次飞往美国旧金山和纽约的分行处理，却遭遇推诿。银行不断更改借口（如质疑企业所有权、客户非美国人、存在可疑交易等），并要求提供重复且极其繁琐的证明材料，甚至要求提供所有打款人的详细个人信息。期间，该商业账户从网银中消失，作者被迫消耗个人储蓄、使用信用卡、出售股票并向朋友借款以维持公司运营和发放薪酬。

最终解决

在常规渠道失效后，作者通过联系大通银行高管办公室并在Twitter上求助，经过数月的反复交涉与行政团队的介入，最终收回了全部资金。但大通银行始终未说明冻结账户的真实原因。

给创业者的核心教训

1. 大银行并非绝对可靠：多年的客户忠诚度在银行的官僚体制和风控面前往往无济于事。
2. 分散银行业务：企业切勿依赖单一银行账户，必须设立备用账户以防范资金断裂风险。
3. 探索替代方案：随着企业发展，应积极寻找真正理解并支持小企业的金融机构。
4. 建立支持团队：在应对危机时，拥有得力且熟悉业务的助手（如美国籍行政助理）至关重要。
5. 防范突发风险：创业者需随时为包括银行系统在内的各种意外状况做好心理和财务准备。

替代方案推荐

经历此次事件后，作者转向了Mercury Bank。Mercury提供了顺畅的开户流程、透明的材料要求以及全面支持小企业的服务（如信用卡和发票管理），成为作者推荐给初创企业和小型企业的优质替代选择。

微软在支持文档中宣布正式弃用拥有39年历史的Windows控制面板，但随后修改了相关表述。

原始声明
上周微软在一份支持文档中明确表示：“控制面板正在被弃用，取而代之的是提供更现代化、更精简体验的‘设置’应用。”该声明指出控制面板长期以来作为集中查看和调整系统设置的功能，涵盖系统时间、硬件设置、网络配置等多项选项。

表述变更
在媒体报道引发广泛关注后，微软修改了该页面的措辞。当前版本改为：“控制面板中的许多设置正在逐步迁移到‘设置’应用，后者提供更现代化、更精简的体验。”目前尚不清楚这一调整是政策变化还是表述澄清。微软尚未回应是否改变了弃用计划。

实际迁移情况
自Windows 10和Windows 11推出以来，微软已持续将控制面板功能迁移至“设置”应用，并逐步移除部分旧版控制面板小程序（如显示设置、添加/删除程序及家庭组等已弃用功能）。尽管如此，Windows 11（包括即将发布的24H2版本）中仍保留大多数控制面板组件，且不会短期内全面移除。

提交信息

• 作者：Theo de Raadt
• 日期：2024年8月23日
• 代码库：OpenBSD CVS（/cvs 中的 src 模块）

文件变更详情

• 修改文件：
  • games/quiz/Makefile
  • games/quiz/datfiles/index
• 新增文件：games/quiz/datfiles/ship（关于帆船部件的问答数据）
• 删除文件：games/quiz/datfiles/greek（关于希腊的问答数据）

提交日志 本次提交替换了过于晦涩、无人能玩的“希腊”问答数据，新增了关于“帆船部件”的问答。此举标志着OpenBSD项目完成了用新代码替换所有原始文件的进程，此次替换的是自1995年10月18日OpenBSD原始代码导入以来最后一个未被修改的原始文件（版本1.1.1.1）。

核心意义 此次提交使OpenBSD达成了“忒修斯之船”（Ship of Theseus）式的里程碑：通过持续更替，项目的每个部分都已被替换，但其核心身份与延续性得以保持。这一“有趣的目标”由多人协助完成。

本文介绍了GoogleSQL团队在SQL语言中引入管道语法（piped data flow syntax）的研究与实践。SQL作为数据处理的事实标准语言，尽管极为成功，但因其年代久远，存在设计问题，导致学习、使用和扩展困难。以往有试图用新语言替代SQL的方案，但均因用户迁移障碍而未成功取代SQL。

GoogleSQL采取了不同的路径：通过扩展SQL来解决其问题。他们受到其他现代数据语言中有效模式的启发，在SQL中添加了管道语法。这种改进具有变革性效果：SQL在保持利用现有SQL生态系统和用户基础的同时，变成了一门更灵活、更易学习、使用和扩展的语言。从内部改进SQL允许逐步采纳新特性，无需数据迁移或学习新语言，是提升标准SQL效率的更有效方法。

该研究由Shannon Bales、Matthew Brown、Jean-Daniel Browne、Brandon Dolphin、Romit Kudtarkar、Andrey Litvinov、Jingchi Ma、John Morcos、Michael Shen、David Wilhite、Xi Wu和Lulan Yu共同完成，发表于《Proc. VLDB Endow. (2024)》。

Android 15 操作系统新增了对16KB页面大小的支持，为设备制造商提供了性能与内存使用的权衡选项。CPU内存管理单元（MMU）通常以页面大小为基础进行地址转换，将页面大小从4KB增至16KB可减少系统内部管理开销，从而带来5-10%的整体性能提升，但会增加约9%的内存占用。

为实现此目标，Android 15从底层重构以支持不同页面大小，使其与页面大小无关。主要操作系统变更包括：

1. 运行时获取页面大小：编译时PAGE_SIZE宏被getpagesize(2)替代。
2. 二进制对齐：所有操作系统二进制文件均按16KB对齐，并采用可分离的可加载段以确保内存区域可读。
3. 文件系统兼容：EROFS和F2FS文件系统及UFS存储层已适配16KB。对于4KB系统，因对齐导致的ELF可执行文件体积增大问题，通过稀疏文件系统优化和包管理器空间回收等方式缓解。
4. 内核适配：Linux内核与页面大小紧密绑定，需在编译时选定，而操作系统其他部分保持统一。
5. 内存管理优化：Linux页面缓存已修改，避免为对齐填充区域预读取不必要的数据。

应用程序兼容性：所有包含原生代码或依赖的应用程序需重新编译。开发者需按16KB对齐重新构建原生代码，并在16KB设备/模拟器上测试修复硬编码的页面大小假设。SDK和工具开发者应尽快添加16KB支持。

开发者工具支持：

• 设备选项：Android 15在Pixel 8等设备上提供开发者选项，允许在4KB与16KB模式间切换（需解锁引导程序并清除数据一次）。系统包含一个额外的内核切换机制。
• 模拟器支持：Android Studio提供16KB页面模拟器，可在x86_64主机上模拟16KB页面行为，方便开发者在没有ARM硬件的情况下进行测试。

该特性旨在为未来更高性能和效率的Android设备奠定基础，鼓励生态系统中的应用和SDK开发者立即开始适配准备。

核心观点

学习数学或计算机科学等复杂学科时遇到困难，并非因为智力不足，而是由于缺乏大量的先决知识（prerequisite knowledge）。理解上的障碍源于基础知识的断层，而非个人能力的缺陷。

形象比喻

• 游戏挑战：如同以1级新手状态去挑战《艾尔登法环》的高难度Boss，缺乏基础必然导致失败。
• 观影体验：就像在电影播放到一半时才入场，因错过开头而无法理解剧情发展。

应对策略与实践

• 重建基础：作者决定从底层重新构建数学技能，复习并巩固过去被忽略或误解的基础概念。
• 优化方法与练习：回溯更早期的学习材料，采用更有效的学习方法，并进行高强度的刻意练习。
• 循序渐进：这一过程虽然缓慢且需要保持谦卑，但每一个被掌握的基础概念都为后续学习更复杂的理论和解决复杂问题奠定了必要的基石。

最终感悟

作者坦言自己尚未成为“天才”，但通过填补先决知识的空白，正在稳步取得进步。文章借此提醒读者：在学习受挫时不要自我否定，你并不笨，只是需要补齐缺失的先决知识。

Clay (C Layout) 2D UI 布局库摘要

项目概述

Clay 是一个专为 C/C++ 设计的高性能 2D UI 布局库。它采用类似 React 的嵌套声明式语法和类似 Flexbox 的布局模型，能够以微秒级的性能处理复杂的响应式 UI 布局。

核心特性

• 极致性能与轻量：核心代码为 4.8k LOC 的单头文件 (clay.h)，零外部依赖（无标准库）。支持编译为 15KB 的 Wasm 文件在浏览器中运行。
• 内存管理：采用基于静态 Arena 的内存模型，无 malloc/free，内存开销极低。
• 渲染器无关：仅负责布局计算，输出排序后的渲染图元命令列表，可轻松集成到任何 3D 引擎或编译为 HTML。
• 丰富的 UI 能力：支持文本换行、滚动容器、宽高比缩放、过渡动画（Transition API）以及绝对定位（浮动元素）。

核心工作流程

1. 初始化：分配 Arena 内存，调用 Clay_Initialize 设置初始尺寸、文本测量回调和错误处理。
2. 渲染循环：
   • 状态同步：调用 Clay_SetLayoutDimensions、Clay_SetPointerState 和 Clay_UpdateScrollContainers 更新窗口、鼠标和滚动状态。
   • 布局声明：在 Clay_BeginLayout() 和 Clay_EndLayout() 之间，使用 CLAY() 等宏声明 UI 层级。
   • 渲染执行：遍历返回的 Clay_RenderCommandArray，根据命令类型（矩形、文本、图像、裁剪等）调用底层渲染 API。

关键功能

• UI 构建：通过 CLAY() 宏创建容器，支持嵌套及原生 C 语言控制流（如循环、条件判断），组件复用可通过普通 C 函数实现。
• 样式与布局：使用 Clay_ElementDeclaration 配置尺寸（固定、增长、百分比）、内边距、对齐方式、背景色和圆角等。
• 元素 ID 与交互：通过 CLAY_ID 分配唯一标识，用于查询元素边界、悬停状态（Clay_Hovered）及绑定事件回调（Clay_OnHover）。
• 滚动与浮动：通过 .clip 配置实现内容裁剪与滚动；通过 .floating 实现类似 CSS 绝对定位的浮动层（如 Tooltip），支持 Z 轴排序。
• 自定义与动画：支持通过 .custom 传递自定义数据（如 3D 模型）给渲染器；Transition API 允许对位置、尺寸、颜色等属性进行平滑的缓动动画插值。
• 多实例与调试：支持通过 Context 管理多个 Clay 实例；内置类似浏览器审查元素的 UI 调试工具。

API 与数据结构

• 生命周期函数：涵盖内存分配、文本测量绑定、状态更新及布局计算。
• 元素宏：提供 CLAY()、CLAY_TEXT()、CLAY_ID() 等便捷的声明式宏。
• 配置结构体：包含 Clay_LayoutConfig（布局）、Clay_ImageElementConfig（图像）、Clay_ClipElementConfig（裁剪）等，用于精细化控制元素行为与渲染输出。

欧洲汽车市场7月销量分析摘要

整体市场概况
2024年7月，欧洲28个主要市场新车注册量达103万辆，同比增长2%，年初至今累计注册量接近790万辆。市场增长呈现地区分化：波兰（+19%）、葡萄牙（+27%）和斯洛伐克（+12%）增长显著，英国、意大利和西班牙小幅增长；德国（-2%）、法国（-2%）、比利时（-7%）等市场则出现下滑。

SUV市场持续主导
SUV车型市场份额达到54%，创历史新高。7月共注册55.4万辆SUV，同比增长6%，年初至今累计420万辆。大众集团以26%的份额领跑SUV市场，现代-起亚（12%）和Stellantis（11.5%）紧随其后。细分市场中：

• C-SUV（紧凑型）需求最高，注册21.06万辆（+3%）；
• B-SUV（小型）增长显著，注册20.43万辆（+14%）；
• E-SUV（大型）和F-SUV（豪华型）分别增长23%和32%；
• D-SUV（中型）需求下降7%，注册10.65万辆。

分析师指出，车型选择多样化及低价SUV普及推动了消费者从传统车型转向SUV。

电动车市场短期承压
7月电动车市场份额从2023年同期的14.6%降至13.5%，注册量13.93万辆，同比下降6%。主要原因包括政策不确定性、消费者对残值的担忧以及缺乏明确激励措施。

品牌与车型竞争格局

• 宝马电动车表现突出：7月电动车销量同比增长35%，超过特斯拉（同比下滑16%）。iX1、i4、i5等新车型推动宝马在电动车市场领先于奔驰和奥迪。
• 特斯拉短期受挫：Model Y和Model 3虽仍居年初至今电动车销量前列，但7月Model Y从欧洲最畅销车型滑落至第九名。
• 畅销车型排名：达契亚Sandero以2.24万辆（+34%）成为7月最畅销车型，大众T-Roc位居第二。TOP10中包含五款SUV和五款两厢车。
• 电动车细分市场：沃尔沃EX30以约6600辆成为7月第二畅销电动车；MG3、菲亚特600、宝马i5、雷诺新Scenic等车型注册量均表现稳健。

总结
欧洲汽车市场呈现结构性转变：SUV持续领跑，电动车增长短期放缓但竞争加剧。宝马凭借电动车新品实现对特斯拉的销量反超，而传统燃油SUV与新兴电动车品牌共同塑造了市场格局。

Julius：凯撒大帝III的开源重新实现

Julius是一款完全可玩的开源《凯撒大帝3》版本。其游戏逻辑与原版完全一致，并增添了一些用户界面增强功能，支持多个平台运行。

核心目标与兼容性

• 运行Julius需要原版《凯撒大帝3》的游戏文件（可通过GOG、Steam购买数字版或使用原版光盘）。
• 项目目标是实现与原版《凯撒大帝3》完全相同的游戏逻辑、外观和感觉，这意味着存档文件与原版100%兼容。
• 为确保完全的存档兼容性，Julius也会保留原版《凯撒大帝3》中存在的游戏bug。

增强功能

• 支持宽屏分辨率。
• 支持32位桌面系统的窗口化模式。
• 包含大量游戏内的生活质量改进。
• 支持曾经在Sierra网站提供的高质量MP3音频文件。

支持平台

• Windows
• Linux (AppImage)
• MacOS
• PS Vita
• Nintendo Switch
• Android
• 任何兼容的浏览器（通过Emscripten）

关于Augustus分支 Julius本身不改变游戏玩法。另一个名为Augustus的分支项目实现了许多长期需求的玩法改变（例如路障功能）。

• Julius：提供更接近原版的视觉增强体验。
• Augustus：提供不同的游戏玩法体验。

存档兼容性说明

• Julius的存档与原始《凯撒大帝3》存档完全兼容。
• Augustus可以加载原版或Julius的存档。
• 但用Augustus保存的存档无法在Julius或原版《凯撒大帝3》中加载。

运行方法

1. 从官方渠道下载对应平台的游戏版本，或自行编译Julius。
2. 可将游戏文件复制到原《凯撒大帝3》文件夹中运行；或从独立文件夹运行，届时游戏会提示您指定原版游戏文件夹的路径。
3. 注意：必须对游戏数据目录有写入权限（用于保存存档）。
4. 原版游戏必须更新至1.0.1.0版本补丁才能运行Julius。若缺少补丁，Julius会进行提示。

Bug说明 为确保100%的存档兼容性，Julius刻意重现了原版《凯撒大帝3》中存在的许多bug和怪异行为。

Meta 已取消其正在开发的、旨在与苹果 Vision Pro 竞争的高端混合现实头显项目。

据《The Information》报道，Meta 在本周的产品评审会议（CEO 扎克伯格参与）后，通知员工停止该项目。该设备原计划于 2027 年推出，配备高分辨率 micro OLED 显示屏（与苹果 Vision Pro 相同），但因其成本过高，导致售价无法控制在 1000 美元以下。

Meta 现将继续开发 Quest 3 的继任者 Quest 4，预计可能于 2026 年发布，目标售价约为 500 美元。公司战略重心正从硬件转向软件，今年早些时候已宣布面向第三方硬件厂商的 Horizon OS 平台。

苹果 Vision Pro 的市场表现未达预期，也影响了 Meta 的决策。Vision Pro 发售初期反响平平，上市一个月后热度便开始下降，店内演示需求减少。苹果已于四月份削减出货量，预计2024年销量难以突破50万台。因此，苹果已停止开发第二代高端 Vision Pro，转而专注于打造功能精简、售价接近高端 iPhone 的更平价型号。

本文讲述了作者通过逻辑推理和技术手段，仅凭电话号码后四位成功找回AirPods失主的过程。

背景

作者的朋友捡到一副AirPods，连接手机后仅显示序列号和失主电话号码的后四位。为了找到失主，作者决定通过逐步缩小号码范围来进行精准寻找。

缩小号码范围的步骤

1. 限定区号：假设失主居住在波特兰都会区，将搜索范围限制在当地区号，将可能的号码数量缩小至999个。
2. 过滤前缀：通过中心局代码（前缀）进一步筛选，仅保留分配给无线运营商的号码，并排除000-199的保留代码，将可能号码减少至232个。
3. iMessage API 验证：假设失主使用iPhone并开启了iMessage，利用 iMessage Lookup API 过滤掉非iMessage号码，最终将目标名单缩减至84个。

执行与结果

• 批量发送信息：为了避免使用Twilio等短信服务产生过多噪音，作者使用MacBook上的脚本向筛选出的号码批量发送iMessage，询问对方是否丢失了AirPods。
• 成功匹配：作者非常幸运，在发送不到10条消息后就成功匹配到了真正的失主。
• 验证与归还：通过确认该手机能与捡到的AirPods成功配对，验证了失主身份，最终将耳机物归原主。

补充说明

• 尽管苹果设备自带“查找”（Find My）功能，但失主并不知道如何使用。
• 波特兰实际上有两个区号，但作者仅尝试了其中一个便幸运地找到了失主。
• 在群发信息的过程中，作者也收到了一些其他接收者的困惑回复。

Humble UI：Clojure桌面UI框架概述

Humble UI是一个专为Clojure设计的桌面UI框架，其核心特点是无需依赖Electron或JavaScript，完全基于JVM和原生代码构建。

核心目标

1. 构建高质量桌面UI：旨在提供超越当前Web应用的桌面应用体验，同时保持跨平台兼容性。
2. 发挥Clojure优势：利用Clojure语言的特性（如REPL驱动的交互式开发）来加速开发进程。

设计动机与背景

• 追求原生体验：用户通常偏好原生应用（具备常规快捷键、独立窗口、文件系统访问、系统通知等能力），但开发纯原生应用成本高昂。
• 克服现有方案的局限：
  • Electron方案：虽然具有里程碑意义，但JavaScript和Chrome引擎存在性能开销。
  • Java的“UI困境”：传统Java UI框架（如Swing）使用繁琐，且模仿原生外观和感觉的尝试效果不佳。
• 拥抱新范式：声明式UI（如React, Flutter, SwiftUI）的时代已经到来。Web和Electron已证明“非原生”外观被用户接受，Flutter则证明了构建全新UI栈的可行性。
• Clojure的理想性：Clojure性能足够、能充分利用计算机能力（如多线程），其交互式开发模式能提供极快的反馈循环。

与现有框架的差异

• 外观策略：不追求完全模仿原生系统外观，而是拥抱类似Web的“一次编写，处处运行”的外观。
• 系统集成：在操作系统集成层面积极拥抱平台差异。
• API设计：采用声明式UI API，与函数式编程风格契合。同时，既提供高级API也暴露低级API，允许用户以自己的方式解决复杂问题，无需使用hack手段。

技术架构

• 图形渲染：通过Skija库使用Skia，实现高性能的GPU加速图形绘制。
• 窗口管理：利用JWM（Java Window Manager）进行操作系统集成，其设计简单，并接受不同平台间的差异。

当前状态与资源

• 开发阶段：项目仍在开发中，没有正式文档，且框架每天都在变化。
• 社区与资源：
  • Slack频道：#humbleui（位于Clojurians Slack）。
  • 相关文章：包括关于框架思考、分解、布局和开发体验的系列文章。
  • 视频演示：展示了用Humble UI构建的Wordle游戏。
  • 示例应用：提供多个示例仓库（如tonsky/humble-ants、tonsky/humble-deck等），展示了框架的实际应用。

代码示例

框架提供简洁的声明式API来构建UI和启动应用：

(require '[io.github.humbleui.ui :as ui])

(ui/defcomp app []
  [ui/center
   [ui/label "Hello, world"]])

(defn -main [& args]
  (ui/start-app!
    (ui/window #'app)))

从零实现 React 摘要

本文详细记录了作者从零构建一个简化版 React 库的过程，旨在通过实践深入理解 React 的核心工作原理和设计动机。该实现基于虚拟 DOM 和协调等高层概念，但并非完全复制 React 团队的官方实现。

核心目标

作者设定了以下具体目标：

1. 核心渲染模型：确保组件树的重渲染行为与 React 一致。
2. 输出一致性：相同输入产生相同的 DOM 输出。
3. 实现核心 Hook：包括 useState、useRef、useEffect、useContext、useMemo、useCallback。
4. 精确的 DOM 更新：仅更新必要的 DOM 节点，而非每次重渲染都重建整个 DOM。

实现步骤与关键概念

1. 基础渲染

• 从 createElement 函数开始，将 JSX（或函数调用）转换为表示组件树的内部元数据（虚拟 DOM）。
• 实现了 applyComponentsToDom 函数，将虚拟 DOM 渲染到真实 DOM。
• 为了支持函数组件组合，需要执行函数并生成完整的视图树（通过 generateViewTree 函数递归遍历）。

2. useState Hook

• 实现难点：
  1. 识别组件实例：通过全局变量跟踪当前正在渲染的组件。
  2. 关联多次调用：依赖 Hook 的调用顺序来区分不同的 useState 调用（因此 React 规定 Hooks 不能条件调用）。
• 实现方式：在组件的视图节点中维护一个“Hook 状态”数组，按调用顺序存储状态。useState 返回当前状态值和一个更新函数（该函数修改状态并触发重渲染）。

3. 组件重渲染

触发重渲染（如 setState）时，执行以下步骤：

1. 重新生成视图树：从触发更新的组件开始，递归重新生成子树。
2. 修补现有视图树：找到旧树中对应节点的父节点，并用新生成的子树替换它（同时需转移状态）。
3. 更新 DOM：最初实现是销毁整个应用 DOM 后根据新视图树重建（效率极低，后续优化）。

4. 协调与依赖树（RenderTree）

• 问题：仅依赖视图树决定重渲染会导致不必要地重渲染兄弟组件（例如，父组件重渲染会触发其视图树中的所有子组件，即使某些子组件不依赖该父组件的数据）。
• 解决方案：引入依赖树。它根据组件之间的调用关系（createElement 被调用时的上下文）构建父子关系，而非视图层级。
• 重渲染策略：遍历视图树时，仅当组件在依赖树中依赖于触发更新的组件，或是首次渲染时，才重新执行该组件；否则缓存其先前的视图树输出。

5. 状态保持与视图节点协调

• 挑战：如何在重渲染时正确保持所有组件的状态，而非仅保持触发更新组件的状态。
• 方法：比较新旧两棵视图树。通过节点在树中的索引路径（以及组件名）来判断两个节点是否对应。相同路径的节点可转移状态；新路径的节点视为新节点，初始化状态；旧路径消失的节点则被清除。
• 条件元素处理：为了保持树结构的稳定（确保节点索引路径在条件渲染变化时不发生错位），将 null、false、undefined 表示为树中的“空槽”节点。这避免了因过滤掉这些值而导致的节点位置错乱。

6. 高效 DOM 更新

• 不再每次重渲染都重建整个 DOM。
• 优化策略：比较新旧视图树。
  • 匹配的标签节点：直接更新其 DOM 属性。
  • 仅存在于新树的节点：创建新 DOM 元素。
  • 仅存在于旧树的节点：删除对应 DOM 元素。
  • 空槽节点：相应地创建或删除 DOM 节点。

7. 其他 Hooks 实现

• useRef：绑定一个可变的引用对象到组件，其值的改变不会触发重渲染。
• useEffect：
  • 接受回调函数和依赖数组。依赖变化或首次挂载时执行回调。
  • 回调可返回一个清理函数，在下次执行前或组件卸载时调用。
  • 实现在渲染完成后，检查各 effect 的依赖是否变化，以决定是否执行。
• useMemo：接受计算函数和依赖数组。依赖未变化时返回缓存的计算结果，避免重复计算。实现与 useEffect 类似，但依赖变化时执行函数并返回新值。
• useCallback：本质是返回函数的 useMemo，用于缓存函数引用。
• useContext：
  • 用于读取由 Context.Provider 提供的数据。
  • createContext 创建一个特殊的 Provider 组件，该组件在内部元数据上存储要共享的数据。
  • useContext 在视图树中向上搜索，找到匹配的 Provider 并返回其数据；若未找到，则返回创建上下文时提供的默认值。
  • 它不创建状态，仅读取数据，因此可以条件调用。

结论与未来方向

作者认为，从头构建库是获得深入直觉和强大内部模型的最佳方式。尽管实现中存在一些因早期设计决策带来的复杂度，但核心思想得以阐明。未来可能扩展的方向包括：

• 服务端渲染（构建字符串而非 DOM，并实现客户端“注水”）。
• 支持不同渲染目标（如生成 UIView 而非 DOM）。
• 用 Swift 重写以支持 UIKit。

最终的代码库整合了状态管理、上下文、记忆化、副作用、条件渲染、列表渲染、深层组件通信和高效 DOM 更新等功能。

本文批判了几何代数（GA）文献中普遍存在的基础性缺陷，认为这些缺陷导致了不必要的复杂性和错误。作者Eric Lengyel以其超过十五年的研究经验为基础，重点剖析了三个相互关联的核心概念：内积、收缩和对偶，并以Dorst等人的《几何代数导论》（GA4CS）为主要参考文献。

1. 内积问题

• GA文献中常见的内积定义（如标量积、胖点积等）均不正确，属于“作者间相互抄袭错误想法”的产物。
• GA4CS定义了一个多余的“标量积”，其Gram行列式的列被无理由地反转。作者认为这完全是“胶带和橡皮筋”式的修补。
• 正确的内积应唯一地从度量张量导出，并通过外代数同构矩阵 G 扩展到整个多向量空间，即 A • B = Aᵀ G B。由此导出的范数自然且自洽。

2. 收缩问题

• GA4CS将收缩定义为一组公理性质，并非良定义。其中第四条性质存在缺陷，导致收缩退化为标量积而非内积。
• 作者认为收缩（作为内积）应能简化为内积。他提供了更简洁明确的定义：
  • 左收缩：A ⌋ B = A★ ∨ B
  • 右收缩：A ⌊ B = A ∨ B★ 其中 ★ 为Hodge对偶，∨ 为反楔积。这些定义使所有性质均可作为定理自然推出。

3. 对偶问题

• GA4CS将对偶定义为 A* = A ⌋ I⁻¹（或等价于 A I⁻¹），这导致方向不一致、正向体积产生负标量（在2D/3D中）、且依赖伪标量可逆性。
• 正确的对偶定义应基于扩展度量矩阵 G 和补集运算：A★ = G̅A（右对偶），其中 G̅ 表示右补。该定义具有：
  • 一致的方向性
  • 对所有维度正向体积产生正标量
  • 保持正交算子不变性
  • 在退化度量下仍有效
  • 满足Hodge对偶的定义性质 A ∧ B★ = (A • B) I

4. 效率谬误

• GA4CS声称转子组合在10维以下均比矩阵组合高效，但其计算存在根本错误（将 2^(n-1) × 2^(n-1) 误算为 2^n）。
• 正确计算表明，仅在三维情况下，转子组合（四元数乘法）比等价矩阵组合快约1.5倍，而非所称的4倍。在其他维度，转子无任何优势，且当包含平移时（如射影GA中的电机），矩阵组合明显更快。

5. 射影几何代数（PGA）的缺陷

作者对GA4CS续篇中关于PGA的论述提出了严厉批评：

• 范数：书中定义的范数 √(A * Ã) 在PGA中毫无意义，因其齐次表示下与具体距离无关。作者指出，PGA中已存在完善的“齐次幅值”理论，由两个互补内积诱导的两个半范数之和构成，而书作者对此显然一无所知。
• Hodge对偶：书中对Hodge对偶的理解和定义极其混乱，混淆了其与“右补”的区别。所给公式“完全是垃圾”，且未能体现Hodge对偶作为强度量运算的本质。
• 运动组合效率：声称电机组合比4×4矩阵组合更高效（48 vs 64次乘法）的说法具有误导性，因为忽略了等价的正交矩阵只需33次乘法的事实。

结论

作者总结指出，几何代数社区固守一个设计不佳的基础框架，并不断用“胶带和橡皮筋”进行修补，同时对任何质疑报以敌意。他强调，正是这些基础缺陷阻碍了几何代数获得更广泛的数学认可，并声称自己提出的、基于严格数学定义（特别是正确的内积、收缩和对偶）的体系，已在多个科学与工程领域被广泛接受为正确方案。

马斯克被迫公开X平台股东名单

埃隆·马斯克旗下的社交媒体平台X（原名推特）因一场前员工发起的诉讼，被加州联邦法官裁定必须公开其所有者名单。此前，X一直以“常规惯例和政策”为由，将投资者信息保密。

主要股东构成

名单揭示了近100位所有者，涵盖知名投资人和机构：

• 知名个人与机构投资者：

  • 比尔·阿克曼：通过“潘兴广场基金会”持股，阿克曼夫妇是其联合受托人。
  • 肖恩·“吹牛老爹”·康布斯：通过“Sean Combs Capital, LLC”持股。
  • 拉里·埃里森（甲骨文创始人）：通过“Lawrence J. Ellison Revocable Trust”持股。
  • 沙特王子阿尔瓦利德·本·塔拉勒：持股，其净资产近190亿美元。
  • 杰克·多西（推特联合创始人）：通过“Jack Dorsey Remainder LLC”持股，尽管他曾对马斯克的领导表示批评。
  • 马斯克本人：通过“Elon Musk Revocable Trust”持股，但文件未明确其投资占比。

• 投资机构：

  • 富达投资：通过近30家关联实体持股，是主要投资者之一。此前其投资报告显示，自马斯克接手以来，X的估值下降了72%。
  • 其他硅谷风投：包括8VC、Andreessen Horowitz和Sequoia等。
  • 加密货币交易所币安：也名列股东之列。

• 关联个人与公司：

  • 丹尼洛·川崎与罗斯·格伯：既是个人投资者，也是他们领导的财富管理公司Gerber Kawasaki的持股方。

背景与现状

马斯克于2022年以440亿美元收购推特并更名为X。自收购以来，平台一直面临广告主流失、大规模裁员以及对马斯克策略的批评等问题。此次股东名单的公开，源于前员工为追索收购后产生的仲裁费用而提起的诉讼。完整的股东名单已通过法院文件披露。

“Everything”是一款专为Windows设计的文件名搜索引擎。

与其他搜索引擎的主要区别：

• 安装包小：软件体积轻巧。
• 界面简洁：用户界面干净且简单。
• 索引与搜索速度快：文件索引建立迅速，搜索响应即时。
• 启动快速：程序启动耗时极短。
• 资源占用极低：运行时对系统资源消耗极少。
• 数据库小：在磁盘上存储的索引数据库体积很小。
• 实时更新：文件索引能够实时更新，确保搜索结果的时效性。

相关资源：

• 安装指南
• 使用说明
• 可下载离线版编译HTML帮助文件（.chm） 或 HTML帮助文件。

Rust 小字符串实现对比：smolstr vs. smartstring

本文通过实际解析案例与微基准测试，深入对比了 Rust 中三种字符串类型的内存表现与核心特性：标准库 String、smol_str (SmolStr) 和 smartstring (SmartString)。

测试方法与场景

作者实现了一个自定义的全局内存分配器（Tracing Allocator），用于精确记录内存分配与释放事件。测试场景为流式解析包含美国前1000大城市信息的 JSON 文件，并提取城市与州名字段。

内存表现对比

• String：每个字符串均在堆上分配，产生 2033 次内存事件，峰值内存 82.7 KB。
• &str（借用）：通过借用输入数据，分配事件降至 24 次。但需将整个文件读入内存，导致峰值内存飙升至 293.4 KB，且受生命周期限制。
• SmolStr：支持内联最多 22 字节的字符串（不可变）。分配事件大幅降至 42 次，峰值内存 73.9 KB。
• SmartString：支持内联最多 23 字节（可变）。表现最佳，分配事件仅 35 次，峰值内存 73.8 KB。

核心特性对比

• String：无内联，支持流式解析和修改，克隆复杂度为 O(n)。
• SmolStr：22 字节内联，不可变。长字符串底层使用 Arc<str>，克隆复杂度为 O(1)。典型应用场景为解析器标记（如 rust-analyzer）。
• SmartString：23 字节内联，支持修改，克隆复杂度为 O(n)。推荐用作 B 树等数据结构的键，以显著提升缓存局部性。

微基准测试结果

• 从 &str 构建：均为 O(n) 操作。对于长字符串，SmolStr 因使用 Arc 存在轻微的恒定开销。
• 克隆操作：短字符串 SmartString 更快；长字符串 SmolStr 凭借引用计数实现 O(1) 克隆，优势明显。
• 转换为 String：短字符串均需重新分配堆内存；长字符串转换时 SmolStr 存在额外的性能开销。

总结

SmolStr 和 SmartString 通过小字符串内联技术显著减少了堆分配次数与内存开销。在实际开发中，应根据是否需要修改、克隆频率以及缓存局部性要求来权衡并选择合适的字符串类型。

该页面是网站管理员为应对AI爬虫过度抓取而设置的防护措施。其核心是名为 Anubis 的系统，采用了类似 Hashcash 的 工作量证明 机制。

目的与原理：

1. 解决的问题：大量AI爬虫的激进抓取行为会消耗服务器资源，导致网站不稳定甚至对所有用户不可用。
2. 防护策略：Anubis 作为一项权宜之计，要求访问客户端（如浏览器）完成一个计算任务（Proof-of-Work）。对于单个用户，此计算开销微不足道；但对于大规模爬虫，累积成本将使其抓取行为变得极为昂贵。

技术实现与当前状态：

• 该机制借鉴了用于减少垃圾邮件的 Hashcash 方案。
• 目前这是一个临时解决方案，旨在为开发更高级的浏览器指纹识别技术（例如通过字体渲染方式辨别）争取时间。最终目标是仅为真实用户提供访问，而无需向其展示工作量证明页面。

注意事项：

• Anubis 依赖于现代JavaScript功能。用户需要禁用如 JShelter 之类的隐私保护插件，否则可能导致防护页面无法正常显示或访问受阻。

摘要

特斯拉已下架其2016年发布的说明文档，该文档曾声称其硬件具备全自动驾驶能力。在访问相关内容时可能遇到技术错误，系统提示某些隐私相关扩展可能导致问题，特别是在x.com上，建议禁用这些扩展并重试。

加密毁灭原则 (The Cryptographic Doom Principle)

核心原则

在设计安全协议时，如果在验证接收消息的MAC（消息认证码）之前必须执行任何加密操作（如解密），将不可避免地导致安全灾难。

MAC与加密的组合方式

1. Authenticate And Encrypt：计算明文MAC，加密明文，将MAC附加到密文后。通常不安全。
2. Authenticate Then Encrypt：计算明文MAC，然后加密明文和MAC。大多有效但违反毁灭原则，因为接收者必须先解密才能验证MAC。
3. Encrypt Then Authenticate：加密明文，然后附加密文的MAC。最优方案，接收者可首先验证MAC，不违反原则。

典型攻击示例

1. Vaudenay 攻击 (针对 CBC 模式)

• 漏洞成因：在“Authenticate Then Encrypt”模式下，接收者必须先解密以验证MAC。CBC模式解密需检查并移除填充（如PKCS#5），这会在验证MAC前产生“填充错误”或“MAC错误”。
• 攻击过程：攻击者篡改倒数第二个密文块的特定字节，影响最后一个块的填充字节。通过观察接收者的错误响应或时间差，攻击者可区分错误类型。当触发MAC错误（即填充有效）时，攻击者即可推算出明文字节。逐字节重复此过程可恢复完整消息。

2. SSH 明文恢复攻击

• 漏洞成因：SSH协议的消息长度字段被加密。接收者在验证MAC前，必须先解密第一个数据块以获取消息长度，从而确定需从网络读取的数据量。
• 攻击过程：攻击者将目标密文块作为首块发送。接收者解密并将前4个字节解析为长度，继续读取数据。攻击者逐字节发送后续数据，直到接收者因MAC校验失败断开连接。通过记录发送的字节数，攻击者可推断出接收者解析出的长度值，从而泄露该密文块的前4个字节明文。

结论

在验证MAC前执行加密操作（如解密、解析长度或检查填充）是危险的设计模式。即使特定情况看似安全，违背该原则最终必然导致各种形式的安全漏洞。协议设计应始终坚持“先加密后认证”以确保MAC验证的首要性。

代码防火墙：实现更细粒度的访问控制

传统代码访问控制通常只有“公开”与“私有”两种模式，缺乏灵活性。本文受网络防火墙启发，提出在代码层面实现更精细访问控制的思路，并介绍了一个基于文件系统结构的Node.js库firewall-js。

传统代码访问控制的局限

• 公开代码可被任意调用，私有代码访问由封装层控制。
• 缺乏介于公开与私有之间的细粒度权限机制。

多层架构中的访问规则

在典型的多层架构（如路由层、控制器层、服务层）中，代码调用通常遵循：

• 只能从上层调用下层。
• 同一层内模块可相互调用。
• 不允许从下层调用上层。

然而，仅靠架构约定难以强制执行这些规则，可能导致代码依赖混乱、维护困难和安全风险。

借鉴网络防火墙的思路

网络防火墙通过定义访问规则（如IP地址、端口）来控制资源访问，无需依赖封装、继承或接口。作者将这一理念应用于代码，通过文件系统目录结构来控制模块访问权限。

firewall-js 的实现与使用

该库利用JavaScript代理（Proxy）实现访问控制，允许开发者指定哪些目录或文件可以访问特定模块。

基本用法示例

在服务模块中，可以声明仅允许controllers和services目录下的代码访问：

// services/user.js
const firewall = require('firewall-js');
const userService = { /* ... */ };
module.exports = firewall.allow(['controllers', 'services'], userService);

若从其他目录（如routes）调用该服务，将抛出访问拒绝异常。

细粒度控制

可进一步限制到特定文件，例如仅允许controllers/userProfile.js访问：

module.exports = firewall.allow(['controllers/userProfile.js'], userService);

方案优势

1. 清晰的代码组织：目录自然对应架构层次，文件对应模块。
2. 易于理解：基于熟悉的文件系统结构，权限设置直观。
3. 减少维护问题：防止不相关模块间的意外依赖或耦合。
4. 增强安全性：限制未授权访问，降低安全风险。
5. 低侵入性：只需合理规划目录结构，并在模块导出时添加一行代码即可实现控制。

总结

该方法通过文件系统映射访问权限，为代码模块提供了一种简单、透明的细粒度访问控制机制，有助于改善多层架构的代码结构与安全性。

GitHub仓库：firewall-js
讨论来源：Hacker News

小行星采矿公司取得突破性进展

早期开发挑战与战略转型

• 横向集成策略失败：AstroForge公司最初采用横向集成模式（外包关键部件），但其“奥丁”（Odin）航天器在3月的振动测试中失败。
• 转向垂直集成：公司创始人Gialich承认原有策略错误，转而采用垂直集成模式（自主研发生产）。
• 应对时间压力：为保持年内发射计划，公司将原为第三次飞行任务开发的内部航天器提前用于“奥丁”任务，并必须在8月1日前完成新100公斤级“奥丁”的振动测试（已按时完成）。

第三项任务：“韦斯特里”（Vestri）计划

• 任务目标：前往同一颗金属小行星并与其对接，成为首个着陆月球以外天体的私人航天器。
• 创新对接设计：利用目标小行星富含铁元素的特性，采用磁铁吸附机制进行对接。
• 科学任务：搭载质谱仪，计划每周采样分析小行星成分，直至航天器失效。
• 发射安排：计划于2025年通过Intuitive Machines公司的另一次任务发射，尺寸约为“奥丁”的两倍。

小行星目标选择与行业背景

• 候选目标：公司正跟踪数颗直径约400米的近地小行星，最终决定将在未来几个月内作出。
• 保密措施：为避免竞争对手（如中国起源太空公司）获取信息，暂不公布具体目标。
• 资源潜力：科学家估计存在约1000万颗近地小行星，其中3%-5%富含金属，潜在采矿候选体达数十万颗。

Borland Turbo Pascal 7 历史回顾与技术总结

历史地位与背景

Borland Turbo Pascal (TP) 是史上最成功的编程工具之一，率先引入了集成源码级调试等技术。TP 7（即 Turbo Pascal for Windows 1.5）是该系列的巅峰与绝唱。它价格亲民，采用创新的“书本授权”模式（单份拷贝供多人轮流使用且无复制保护），最终被 Delphi 取代。

核心优势与技术特点

• 简化 Windows 开发：90年代使用 C 语言进行 Windows 编程需依赖繁琐的命令行工具和复杂的文本配置。TP 7 自动化并隐藏了底层复杂性，大幅降低开发难度。
• 面向对象与 OWL 库：TP 7 通过 Object Windows Library (OWL) 提供了优于微软早期的面向对象 C API 封装，使开发者能轻松构建美观的用户界面。
• 革命性的 IDE 体验：将图形化 UI 设计工具（如菜单和图标布局）无缝集成。开发者按 F7 即可构建运行程序，点击代码行即可设置断点，在当时极具开创性。
• 极致的编译性能：得益于 CP/M 时代的遗产，其编译器核心专为低内存和慢速 CPU 设计。采用高度优化的汇编语言，完全在内存中完成编译，避免磁盘 I/O 瓶颈，在早期 Windows 硬件上编译极快且毫无现代 IDE 的臃肿感。

历史影响

TP 7 极大降低了 Windows 编程门槛，帮助大量 MSDOS 开发者顺利过渡到 Windows 平台，对 Windows 在桌面 PC 的普及起到了重要的推动作用。

衰落原因

1. C 语言的行业惯性：随着拥有小型机和大型机背景的企业进入 PC 市场，他们带来了在科学和商业领域已根深蒂固的 C 语言偏好。
2. 微软官方工具的完善：微软推出了自己的 C 语言 IDE，并凭借对 Windows 平台的绝对控制权占据优势。
3. Visual Basic 的竞争：VB 以更低的学习门槛和无需独立编译的特性，吸引了大量小型和定制应用开发者。

现状与时代反思

如今早期 TP 版本已免费开放，但 TP 7 因无法在现代系统运行且缺乏复古吸引力而沦为“废弃软件”。它是硬件资源受限但市场需求庞大时代的产物。作者感慨，现代硬件性能的过剩掩盖了程序员底层技能的退化，导致软件开发逐渐“半熟练化”并催生了臃肿的软件，而 AI 的发展未必能完全弥补这一技能断层。

Firebuilder：完整的 Firefox 定制工具

核心功能：这是一个交互式命令行工具，通过生成配置文件并将其构建成一个完整的 Firefox 配置文件夹。

主要特性：

• 界面定制 (userChrome)：可从多种 CSS 调整选项中选择。
• 隐私与强化设置 (user.js)：应用 Firefox 强化设置，内置合理默认值，旨在保留所有功能的同时移除追踪。
• 从代码库安装：支持从任何 Git 仓库安装用户自定义样式、配置等，并可进行个性化调整。
• 安装 fx-autoconfig：用于支持浏览器的 .uc.js 脚本文件。
• 从代码库安装 .uc.js 脚本：示例可参见 examples/uc.js-scripts。
• 扩展现有配置文件：可以从现有的 Firefox 配置文件中复制书签、历史记录、密码、扩展和 Cookie。
• 自定义起点：可选择从合理的默认设置或纯净的 Firefox 开始定制。

开始使用：

1. 二进制安装：从 GitHub 发布页面下载对应平台的二进制文件。
2. 包管理器安装：可通过工具 justinstall 一键安装，命令为 justinstall explosion-scratch/firebuilder。
3. 从源代码运行：
   • 克隆仓库：git clone https://github.com/Explosion-Scratch/firebuilder
   • 进入目录：cd firebuilder
   • 运行交互式设置：bun cli.js
   • 或使用预置配置文件运行（例如）：bun cli.js examples/my-config/config.jsonc
   • （可选）直接启动：bun cli.js examples/my-config/config.jsonc --launch

参与贡献：详情参见项目中的 CONTRIBUTING.md 文件。基本流程是通过 JSON 或 JS 文件添加功能，并确保为其配备相应的处理器。如有功能需求，可通过创建 GitHub Issue 提出，开发者会尽力添加或接受 Pull Request。

军蚁建桥的简单算法

军蚁群拥有数百万个体，却没有固定家园，每晚迁移寻找新觅食地。在迁移过程中，它们展现出复杂的集体行为，例如用自己的身体搭建桥梁，而无需任何领导或中央协调。新研究揭示了这种行为背后简单规则，以及军蚁如何权衡建桥的成本与收益。

建桥过程与简单规则

从一只行进中的军蚁视角看：当遇到路径上的间隙时，它会减速。其他蚂蚁以每秒12厘米的速度从它背上踩踏而过。此时，两条简单规则被触发：

• 第一条规则：当蚂蚁感到其他蚂蚁从它背上走过时，它会冻结不动。只要有人踩踏，它就保持原位。
• 这个过程重复：后续蚂蚁同样减速、被踩踏并冻结，逐渐形成足够长的桥梁以跨越间隙。行进中的蚁群随后从桥梁上通过。

成本与收益权衡

建桥并非总是最优选择。例如，在V形间隙前，蚁群不会选择跨越最宽部分以最小化行走距离，因为建桥涉及权衡：被固定在桥梁上的蚂蚁无法执行其他任务（如觅食）。研究表明，有时多达20%的蚁群可被锁定在桥梁建设中。因此，当额外蚂蚁成本过高时，蚁群可能选择绕行而非建造更长桥梁。

第二条规则与适应性

个体蚂蚁无法感知整个蚁群的状况，但第二条规则解决了这个问题：每只蚂蚁对踩踏流量敏感。当交通流量高于阈值时，它们保持冻结；当流量下降（可能因过多蚂蚁投入建桥）时，它们解冻并重新加入行进。这允许蚁群动态调整建桥策略。

研究模型与预测

基于2014年在巴拿马丛林的实验，研究人员（如Simon Garnier）开发了一个模型，量化蚂蚁对脚部交通的敏感度，并预测蚁群何时建桥或绕行。模型旨在根据环境几何形状，预测蚁群的“抄近路”行为。

应用与挑战

进化为军蚁配备了高效的实时建桥算法。研究人员试图为简单机器人开发类似指令，但面临挑战：

• 自然界生产蚂蚁的成本更低、更可靠，而机器人电池寿命有限。
• 军蚁行为可能比仅有的两条规则更复杂，仍需进一步理解。

这项研究不仅解释了军蚁的集体智慧，也为群体机器人技术提供了启示，尽管完全模仿仍任重道远。

无障碍访问关乎所有人

本文介绍了残障人士（包括与年龄相关的障碍）如何使用网络，旨在帮助开发者、设计师、内容创作者等理解创建无障碍数字产品（如网站、应用、浏览器）的原因和方法。

主要内容分为以下几个部分：

• 网页用户故事（人物角色）：通过具体的人物角色，代表不同残障人士的网络使用经历。
• 多样化的能力与障碍：阐述能力的广泛多样性，并指出由于数字技术本身的无障碍性不足，给用户带来的具体障碍。
• 使用的工具与技术：介绍残障人士与数字技术互动时所使用的工具和技术方法。
• 无障碍原则：引入用于组织无障碍要求的四大原则（可感知、可操作、可理解、健壮性），并依据W3C网络无障碍倡议（WAI）的国际标准，提供各原则下的相关要求示例。
• 网页无障碍视角视频：提供一系列短视频，重点展示对残障人士至关重要、同时对所有人也都有益的无障碍功能。

本文的核心目标是阐释无障碍访问的深远影响和普遍益处。

Cumberland搬迁计划摘要

计划状态 Choose Cumberland搬迁计划的申请目前已暂停。该计划是一项人才引进举措，面向居住在马里兰州阿勒格尼县以外、从事远程工作或正在搬迁至Cumberland从事新工作或现有工作的个人。

核心补贴详情 该计划提供高达20,000美元的搬迁支持，具体包括：

• 10,000美元的搬迁现金。
• 另外最高10,000美元的等额配套资金，可用于位于Cumberland市界限内现有住房的批准翻新，或用于新建住房的首付款。

申请资格 申请者需满足以下条件：

• 年满18岁，有资格在美国工作。
• 拥有全职远程工作、本地现有工作，或接受该地区的新工作。
• 目前尚未与房地产经纪人签订购房合同。

住房与居住要求

• 申请被接受后，申请人必须在六个月内购买一套房屋。
• 必须将该房屋作为主要住所居住至少5年。
• 如果居住少于5年，需要将资金退还给Cumberland市政府。

申请方式与更多信息

• 申请将以滚动方式接受和审核，提交申请不保证被接受。
• 如有疑问，可发送邮件至 choose.ccrp@cumberlandmd.gov。

当地资源参考 文章列举了多个本地资源链接，包括Cumberland市政府、商会、艺术委员会、活动信息、房地产网站（如Redfin、Zillow）以及各类学校信息，供感兴趣的申请者进一步了解该地区。

Omi：开源AI可穿戴设备，用于捕捉对话

概述

Omi 是一款开源AI工具，旨在成为用户可信赖的"第二大脑"。它通过捕获屏幕和对话内容，实现实时转录、生成摘要与行动项，并提供拥有持久记忆的AI聊天功能。该产品支持桌面端、移动端及可穿戴设备，已被超过30万专业人士使用。

快速开始

• 命令行克隆与启动：

  git clone https://github.com/BasedHardware/omi.git && cd omi/desktop && ./run.sh --yolo
  

  该命令将构建 macOS 应用，连接至云端后端并启动，无需配置环境文件或本地后端。

• 环境要求：macOS 14+，Xcode（包含 Swift 和代码签名），Node.js。

完整安装与项目结构

1. 本地开发环境安装：

   • 需安装 Xcode 命令行工具和 Rust 工具链。
   • 从仓库克隆代码，并根据示例文件配置后端环境变量。

2. 移动端应用：

   • 位于 app/ 目录，使用 Flutter 开发，支持 iOS 和 Android。
   • 通过 setup.sh 脚本进行初始化。

3. 系统架构与组件： Omi 系统由以下核心组件构成，通过 BLE、HTTPS/WebSocket 等方式通信：

文档与开发资源

项目提供了全面的文档，涵盖：

• 入门指南：包括快速开始、各端应用（macOS、移动端、后端）的开发与配置。
• 应用开发：指导如何构建应用，并提供了如 GitHub、Slack 集成、OmiMentor 等示例，以及音频流应用和自定义聊天工具的开发。
• API 与 SDK：提供完整的 REST API 参考（用于管理记忆、对话、行动项）以及 Python、Swift、React Native SDK 的文档，还支持 MCP 服务器集成。
• 架构详解：深入介绍了后端、转录流水线、聊天系统、音频流协议和 BLE 协议。

硬件产品

• Omi 可穿戴设备：开源设计的AI硬件，可与移动应用配对，实现长时间连续捕捉。
• Omi Glass 开发套件：基于 ESP32-S3，集成摄像头和音频输入。
• 项目提供开源硬件设计、购买指南、设备构建与固件烧录说明。

许可证

项目采用 MIT 许可证开源。