我们需要视觉编程，但不是那种

视觉编程环境大多未被使用，因为它们试图替代代码语法和业务逻辑，而开发者实际上并不需要可视化这些。相反，开发者更关注可视化软件的隐式方面，如状态转换、内存布局或网络请求。如果视觉编程从这些开发者已习惯可视化的方面入手，将更可能成功。

视觉编程为何失败？

开发者声称需要“视觉编程”，但实际从未使用流程图来可视化简单代码逻辑。他们偏好文本表示来处理业务逻辑。观察发现，开发者会花费时间可视化代码的其他重要但难以理解的方面，例如：

• 代码库整体结构图
• 计算机网络连接图
• 内存中数据布局图
• 状态机转换图
• 请求/响应协议的泳道图

这些可视化帮助开发者应对复杂问题，如理解内存布局对性能的影响，或跟踪外部依赖。但现有工具中，只有少数如DOM检查器、火焰图和SQL表图被集成到开发环境中。

开发者实际需要的可视化类型

1. 代码库可视化

用于快速理解大型代码库的结构和复杂度。

• Treemap：以文件大小和颜色指标（如代码复杂度）展示代码库概览，帮助识别关键模块。
• Sourcetrail：开源工具，可视化类层次和依赖关系，支持代码与图表交互，但未集成到主流编辑器中。
• 代码保留图：通过颜色追踪代码演变，识别稳定和过时的代码部分。

2. 网络和服务拓扑图

展示服务间的连接和依赖，常见于云服务文档（如AWS）。这类图对团队新人尤为重要，能快速传达系统架构，但通常手动创建且易遗漏细节。

3. 内存布局图

帮助开发者理解数据在内存中的排列方式，对性能优化至关重要。

• 例如，Rust中Rc<T>指针的内存布局图，比代码描述更直观。
• Rust的所有权模型可通过树状图清晰展示，增强理解。

4. 状态机图

可视化状态转换，常用于复杂业务流程（如支付处理）。例如，Stripe的支付意图状态机图，将状态与UI关联，简化理解。Idris文档中的状态机图则辅助解释类型系统概念。

5. 泳道图

用于客户端/服务器请求架构，展示交互顺序和依赖。

• 例如，Stripe结账流程的泳道图，显示各方请求和响应。
• 分布式系统中，泳道图可诊断时序问题，如Jepsen分析中的数据一致性检查。

现状与改进

大多数可视化是临时制作（如手绘草图），未集成到开发工作流。作者建议从现有代码或测试自动生成图表，例如：

• 从Rust类型注释生成内存布局图或所有权树。
• 从gRPC服务定义生成网络拓扑图。
• 从端到端测试生成请求/响应泳道图。

总之，视觉编程应聚焦于开发者已自然可视化的软件方面，而非替代代码语法，从而真正提升开发效率和理解深度。

《机器人总动员》（WALL·E）电影通过其精细的视觉设计，构建了一个在消费主义反乌托邦与六十年代太空竞赛乐观主义之间取得平衡的独特未来。以下是文章对其设计细节的剖析：

1. 核心字体与名字解析

• 主角名字“WALL·E”中的分隔符是一个中间点（interpunct），而非连字符或项目符号。这是一种源自拉丁文和古希腊文的符号，在现代日语中也用于分隔标题和名称，契合其全称“Waste Allocation Load Lifter · Earth Class”（废物分配载货升降机 · 地球型）。
• WALL·E前板所使用的粗体宽字体是Gunship，由德克萨斯州的业余字体设计师丹·扎多罗兹尼创作。该字体广泛应用于地球和Axiom飞船上的机器人导向标识。

2. Buy n Large（BnL）公司的视觉形象

• 电影中的巨型企业Buy n Large的标志是Futura Extra Bold Oblique字体的高度斜体化定制版本，其标志性的红色配色方案与现实中的Costco公司标志惊人相似。
• 电影中出现了BnL的废弃纸币，面额高达千万美元，这暗示了在Axiom飞船离开地球（2105年）之前，人类经历了严重的恶性通货膨胀，与2008年津巴布韦的极端通胀情况相呼应。

3. 设计灵感与科幻参照

• 单轨列车系统：电影中的单轨列车设计灵感来源于迪士尼乐园的ALWEG单轨系统和西雅图为1962年世博会建造的单轨系统，象征着一种曾经乐观的未来主义。
• 宣传海报风格：一张展示WALL·E机器人工作的宣传海报具有明显的社会主义现实主义宣传风格，其构图和标语（如“Working to dig you out!”）与中、苏、朝的宣传海报相似，将共产主义价值观作为对消费主义的解药。
• 机器人HUD（平视显示器）：WALL·E的双眼HUD是科幻电影中常见的“机器人视角”呈现手法，此传统始于1973年的《西部世界》。WALL·E的HUD形状模仿其双筒望远镜眼睛，是皮克斯的惯用手法，旨在让观众感知机器人所想。

4. EVE与苹果设计哲学

• EVE的设计高度借鉴了苹果公司2000年代初的极简主义美学，尤其是2002年发布的iMac G4。导演曾表示，他希望EVE代表“高端科技、无缝且技术隐藏”，这促使皮克斯团队邀请时任苹果设计主管乔纳森·伊夫参与了EVE原型的咨询。

5. Axiom飞船的建筑与内部设计

• Axiom飞船的内部设计融合了多种灵感：
  • 经济舱：风格紧凑、棱角分明，色调以BnL的蓝、红、白为主，让人联想到1971年开业的迪士尼世界当代度假村的混凝土结构。
  • 头等舱：风格曲线、奢华、宽敞，酷似拉斯维加斯大道的霓虹景象，天花板是巨大的动画屏幕，模仿了凯撒宫商场和弗里蒙特街体验区的天幕。
  • 公共空间：其流畅、拱形的支撑结构受到建筑师圣地亚哥·卡拉特拉瓦作品的启发。
  • 交通系统：飞船内的“PeopleMover”（人员运送机）系统直接源于迪士尼乐园1967年推出的同名游乐设施，是华特·迪士尼对未来城市交通构想的体现。

6. 广泛的科幻电影致敬

• 《异形》与《异形2》：西格妮·韦弗为Axiom计算机配音，是对其饰演的瑞普利角色的巧妙致敬，尤其是在自毁倒计时和气闸舱场景中。
• 《2001太空漫游》：
  • 自动驾驶机器人AUTO的设计，特别是中央红色“眼睛”，明显致敬了HAL 9000。
  • WALL·E使用的救生舱外形借鉴了2001中的EVA舱。
  • 船长第一次站起来时的配乐是理查·施特劳斯的《查拉图斯特拉如是说》，与2001的里程碑时刻相呼应。
• 其他参考：电影中清洁机器人（VAQ-M, SPR-A, BUF-4）的组合与《第五元素》中的清洁机器人队列相似；Axiom的超空间跳跃效果模仿了《星际迷航：无限太空》中企业号的曲速航行。

7. 设计主题与评论 电影通过废弃的地球技术（如苹果iPod、VHS录像带）与Axiom上崭新而肤浅的未来形成对比，突出了WALL·E作为被遗弃科技的怀旧象征。其设计既是对消费主义和环境破坏的辛辣讽刺，也通过对复古未来主义（如迪士尼愿景）的运用，最终传递出一种重拾人类最初太空探索乐观精神的希望。

Zed编辑器现已支持Linux系统。要在大多数Linux发行版上安装Zed，请运行以下shell脚本。安装过程通过下载并执行一个远程脚本完成，具体命令为使用curl获取脚本并立即通过sh执行。该方法适用于快速部署Zed编辑器环境。

dut：Linux 磁盘使用计算器

dut 是一款用于 Linux 系统的快速磁盘使用计算器，具有以下核心特性：

• 精确的硬链接计数：输出受 NCDU 启发，能准确统计硬链接占用的空间。
• 兼容性：生成的 ASCII 树形图完全兼容 Linux 终端 (tty)。
• 可配置输出：可通过命令行参数简单调整显示的最大文件深度。

基本用法示例

默认情况下，dut 会输出当前目录下最大的目录树。

• dut -n 10：限制输出为前 10 行。
• dut -n 10 -d 1：同时限制显示深度为 1。

输出包含两列：

1. 第一列：条目在磁盘上实际占用的空间（可能包含指向目录外的硬链接，导致统计值偏高）。
2. 第二列：因硬链接而与其他目录条目共享的数据大小。 因此，一个条目的独有空间约等于第一列减去第二列。

完整选项可通过 dut -h 查看。

安装方法

通过 Git 克隆代码库并使用 Makefile 安装：

git clone https://codeberg.org/201984/dut.git
cd dut/
sudo make install

默认安装到 /usr/local/bin，可通过 PREFIX 变量自定义安装路径（例如 make install PREFIX=$HOME/.local）。

性能基准测试

dut 速度极快，但在不同场景下表现各异。测试环境：Intel i5-10500H，16GB RAM，Arch Linux。

测试对手：du (coreutils), dua (Rust), pdu (Rust), dust (Rust), gdu (Go)。

1. 磁盘缓存命中场景

数据在内存缓存中，不触及磁盘。

• 结果：dut 平均耗时 780ms，显著快于其他所有工具，比 du 快约 6.87 倍。

2. SSD 性能场景

每次运行前清除缓存，强制从 SSD 读取。

• 结果：pdu 表现最佳（7.86秒），dut（9.98秒）略慢，但仍快于 dua 和 du。

3. HDD 性能场景

在机械硬盘（2TB 5400rpm）上测试，目录结构庞大。

• 结果：dua 表现最佳（34.06秒），dut（36.42秒）紧随其后，远快于 du、pdu 和 dust。dust 耗时最长（86.75秒），可能因其使用 Rayon 进行多线程广度优先搜索，与硬盘友好的深度优先搜索模式不同。

总结

dut 是一个快速、精确且用户友好的 Linux 磁盘使用分析工具。其在缓存场景下优势巨大，在首次读取（冷缓存）场景下也极具竞争力，尤其适合频繁分析磁盘使用的场景。

科学家发现红斑狼疮病因及潜在逆转方法

西北大学医学院与布莱根妇女医院的研究团队在《自然》杂志上发表研究，揭示了系统性红斑狼疮（SLE）的一种分子缺陷，并证明逆转该缺陷有望治愈该疾病。

研究背景

红斑狼疮影响美国超150万人，可造成肾脏、大脑和心脏等多器官的致命损伤。此前该病病因不明，现有疗法主要依赖广泛的免疫抑制，不仅难以有效控制病情，还会削弱免疫系统抵抗感染的能力，带来严重的副作用。

核心发现与发病机制

研究人员发现了一条驱动狼疮发病的新分子途径。狼疮患者血液中的多种分子发生变化，导致芳香烃受体（AHR）途径激活不足。AHR通常负责调节细胞对环境污染物、细菌或代谢物的反应。AHR激活不足会导致体内产生过多的外周辅助T细胞（T peripheral helper cells），这些致病性免疫细胞会促进致病自身抗体的产生，从而引发并加剧病理性的自身免疫反应。

潜在治疗与逆转策略

研究表明，通过纠正这种免疫失衡可以有效抑制病理反应：

• 细胞重编程：在狼疮患者的血液样本中重新引入AHR激活分子，能够将致病细胞重编程为Th22细胞，后者可能有助于促进自身免疫疾病造成的组织损伤愈合。
• 减少致病细胞：使用小分子激活剂激活AHR途径，或限制血液中病理性的过量干扰素，均能显著减少致病细胞的数量。

研究意义与未来展望

该研究明确了狼疮患者免疫反应中的根本失衡，并定义了能够纠正这一失衡的特定介质。这为开发精准疗法提供了新方向，有望实现治愈且避免现有广泛免疫抑制疗法的副作用。研究团队下一步计划开发新型治疗方案，探索将这些分子安全、有效地递送给患者的具体方法。

Binance使用Quickwit构建100PB日志服务摘要

项目背景

币安（Binance）作为全球领先的加密货币交易所，每天处理约2100万条日志（相当于18.5GB/s，每日1.6PB）。此前依赖20个Elasticsearch集群处理日志，存在运维复杂、保留时间短（仅数天）、可靠性不足（无复制以节省成本）等问题。

Quickwit解决方案

Quickwit是一个分布式全文搜索引擎，旨在以比Elasticsearch低10倍的成本、更易管理的方式处理PB级数据。币安团队发现其具备以下优势：

• 原生Kafka集成：支持直接从Kafka摄入日志，确保精确一次语义，集群可快速重建。
• 内置VRL转换：无需额外Vector Pod处理日志转换。
• 对象存储为主：数据存储于对象存储（如S3），无需管理集群端存储。
• 更优压缩：压缩比比Elasticsearch高2倍，降低存储占用。

迁移成果

币安成功将多个PB级Elasticsearch集群迁移至Quickwit，实现：

• 索引规模：每日处理1.6PB日志，部署10个Quickwit集群，共700个Pod，使用约2800 vCPU和6TB内存。
• 搜索规模：管理100PB可搜索日志，仅需30个搜索Pod（1200 vCPU，3TB内存）。
• 数据压缩：100PB未压缩数据在S3上压缩后仅20PB。
• 成本节省：
  • 计算资源减少80%。
  • 存储成本降低20倍（相同保留期限下）。
• 可靠性提升：日志保留时间从数天延长至数月，增强了故障排查能力。

技术挑战与优化

• 集群稳定性：Quickwit的gossip协议在数百个Pod规模下不稳定，币安通过为高吞吐量主题部署独立索引集群解决。
• 负载不均：已知的Kafka工作负载分布问题，通过集群隔离缓解。
• 搜索统一化：为避免搜索资源分散，币安将多个索引集群的元数据复制到统一PostgreSQL数据库，实现集中式搜索集群。

未来改进

双方计划进一步优化数据压缩、多集群支持和Kafka数据源的工作负载分配。

总结

币安与Quickwit的合作在6个月内完成了大规模日志服务的迁移，显著降低了基础设施成本与运维复杂度，同时提升了日志处理规模与保留能力，验证了Quickwit在超大规模场景下的实用性。

高通Oryon核心：漫长等待的成果

高通Oryon核心的诞生源于2019年创立的芯片设计公司Nuvia。Nuvia由前苹果芯片架构师等知名人物领导，目标是打造能超越AMD、苹果、Arm和英特尔现有设计的高效能核心。2021年高通收购Nuvia后，其团队整合入高通内部CPU项目，最终催生了用于骁龙X Elite的Oryon核心，这距离Nuvia曝光已近五年。

骁龙X Elite的Oryon CPU采用非大小核的集群设计，包含三个四核集群，每个集群共享12 MB L2缓存，通过不同集群的最高频率来兼顾单线程与多线程性能。这种设计在核心间延迟测试中表现明显：集群内延迟较低，但跨集群延迟较高，尤其对于单芯片设计而言。相比之下，苹果M1同样使用四核集群和共享L2，延迟特性相似；而AMD Phoenix（8个Zen 4核共享L3）的核心间延迟则非常低。

Oryon的微架构继承了苹果Firestorm与高通早年Kryo的设计哲学，是一款8宽度解码器的核心，具有巨大的乱序执行能力。其重排序缓冲区高达680个条目，整数和浮点寄存器文件均为416个条目（含32个架构性条目）。调度器容量尤其突出，仅基本整数操作就有120个调度条目，浮点/向量操作则有192个条目，这为其提供了强大的指令级并行处理能力。与Zen 4（6宽度，较小缓冲区）和Redwood Cove相比，Oryon在宽度和调度容量上占优，但Zen 4可运行在更高频率（如5.1 GHz）。

在分支预测方面，Oryon拥有一个高性能的预测单元。其方向预测器表现优于Golden Cove但略逊于Zen 4。它采用了与指令缓存关联的BTB设计，允许在8 KB代码足迹内实现单周期延迟的分支。间接分支预测器条目为2048个，虽不及Zen 4的3072个，但行为不同。返回栈深度为48条目，与苹果M1（50条目）相似，深度足够。

缓存与内存子系统方面，Oryon采用了类似苹果的策略。其拥有一个巨大的192 KB L1指令缓存和96 KB L1数据缓存，远大于Zen 4（32/48 KB）和Redwood Cove。L2缓存延迟约20周期。它没有传统中层缓存，而是依赖一个6 MB的系统级缓存（SLC，延迟26-29 ns）。DRAM延迟约111 ns（使用LPDDR5X）。在内存带宽上，单个Oryon核心可从DRAM实现惊人的80 GB/s读取带宽，全核工作时L2缓存可提供近330 GB/s带宽，DRAM总带宽超过110 GB/s，显著领先于Phoenix和Meteor Lake。

性能测试显示，在原生应用（如Cinebench 2024）中，搭载12个Oryon核心的骁龙X Elite平台能以略高的功耗（约2%）领先于8核AMD Ryzen 7840HS（约8.4%）。然而，由于热设计和功耗限制，测试设备（三星Galaxy Book4 Edge）中Oryon核心的平均频率仅约2.71 GHz，而AMD的Zen 4核心平均可达3.75 GHz，这限制了理论优势的充分发挥。英特尔Meteor Lake（6P+8E+2LPE核）在相似平台功耗下性能仅略高于苹果M2。

尽管Oryon核心本身设计出色，但骁龙X Elite平台面临显著的市场挑战：

1. 兼容性与生态系统：x86 PC拥有悠久的软件兼容传统。Oryon依赖二进制翻译执行x86代码，存在性能损耗。此外，Arm设备存在严重的平台碎片化，操作系统镜像需为不同笔记本定制，无法像x86那样使用通用镜像。
2. 价格竞争力：当前骁龙X Elite设备价格高于同配置（甚至更高配置）的AMD Phoenix和英特尔Meteor Lake笔记本，性价比处于劣势。
3. 功耗与散热管理：测试设备在接通电源时CPU不进入空闲状态，导致即使在空闲时设备也明显发热，这影响了用户体验。

总结来说，高通Oryon是一个强大且创新的CPU微架构，成功融合了其自身传统与苹果的设计精华，在核心宽度、乱序能力和缓存容量上表现出色，为高通进军PC市场提供了迄今为止最有力的武器。然而，骁龙X Elite平台要在竞争激烈的x86主导市场中取得成功，仍需克服生态系统、价格和功耗管理等方面的障碍。

文章以作者家中AT&T光纤网络速度骤降为背景，描述了其尝试通过AI客服解决问题却遭遇挫折的经历。网络速度从1Gbps先降至100Mbps，后进一步跌至约8Mbps。作者启动AT&T的AI支持聊天机器人后，发现该机器人存在明显缺陷：错误地将“WiFi”等同于“互联网”，导致对话陷入循环约五分钟。经过多次尝试，作者通过重复输入请求转接人工客服的指令（如“connect me to a support rep”），最终排队等待20分钟后接入人工客服。然而，人工客服同样未能有效解决问题，忽略了作者先前提供的数据，转而建议切换WiFi频道（而作者设备的WiFi实际已禁用），令问题未能解决。

作者由此对AI聊天机器人作为未来客服解决方案的前景表示不满，并以讽刺语气反问是否应“欢迎AI霸主”，凸显了当前AI客服在概念理解、问题解决能力以及人机协作方面的不足。

基于 Zola、JSON Resume、Weasyprint 和 Nix 的自动化简历生成系统

项目目的

本项目旨在构建一个“过度工程化”的数据驱动简历生成系统。核心目标包括：实现内容与表现层分离、支持 Git 版本控制、支持多格式输出（PDF 和网页），并在弃用 LaTeX 的前提下，利用熟悉的 Web 技术实现优于常规模板的视觉排版，同时确保生成的 PDF 兼容 ATS（申请人跟踪系统）。

核心架构与数据流

系统通过一条完整的数据到 PDF 的流水线进行构建：

• 数据层：使用 resume.yaml 存储简历数据，遵循 JSON Resume 标准 Schema。结合 YAML 语言服务器，在编辑器中提供实时的数据验证与提示。
• 模板与渲染层：采用静态站点生成器 Zola 及其 Tera 模板引擎。模板读取 YAML 数据，将其渲染为语义化 HTML，并结合 CSS（参考 Simple.css）进行样式设计。部分内容支持 Markdown 解析以增强文本表现力。
• PDF 转换：使用 Weasyprint 将生成的 HTML 转换为 PDF，确保文本可被 ATS 正常提取。

本地开发体验

为消除环境配置和手动同步的繁琐，作者优化了本地开发工具链：

• 环境管理：利用 Nix (nix-shell) 和 direnv 自动加载项目依赖（如 Zola、Weasyprint 等），进入项目目录即可自动激活环境。
• 任务自动化：使用 just (justfile) 封装构建命令。结合 yq 工具动态解析 YAML 中的姓名来命名输出的 PDF 文件，避免硬编码。
• 实时预览：通过 inotifywait 监听文件系统的变更事件。当修改数据或模板时，自动触发重新构建并刷新 PDF 查看器，实现流畅的实时预览体验。

持续集成 (CI)

为避免将构建产物（PDF）纳入版本控制，项目引入了 GitHub Actions 进行自动化管理：

• 当代码推送至 main 分支时，CI 流程会自动利用 Nix 配置与本地一致的环境并执行渲染。
• 生成的 PDF 会作为 Artifact 上传并关联到特定的 Commit，确保随时可下载与源码完全同步的最新简历。
• 该架构具备良好的扩展性，未来可通过多分支策略为不同行业或岗位维护定制化的简历版本。

调查背景与范围

• 调查名称：国际消费者保护和执行网络（ICPEN）年度“暗黑模式”全球网络巡查。
• 时间：2024年1月29日至2月2日。
• 参与方：来自26个国家的27个消费者保护执法机构。
• 首次协作：与全球隐私执法网络（GPEN，包含80多个隐私执法机构）合作，凸显消费者保护与隐私保护的交叉。

核心定义与评估标准

• 暗黑模式定义：在线用户界面中引导、欺骗、胁迫或操纵消费者做出非最佳利益选择的常见做法。
• 评估依据：采用经济合作与发展组织（OECD）提出的六项暗黑商业模式特征指标。

主要调查发现

• 高普及率：检查了642家商家的网站和移动应用，发现75.7% 使用了至少一种暗黑模式，66.8% 使用两种或以上。
• 常见类型：
  1. 潜在隐藏行为（Sneaking Practices）：如消费者无法关闭订阅服务的自动续费。
  2. 界面干扰（Interface Interference）：例如将更有利于商家的订阅选项设计得更突出。

相关报告与意义

• ICPEN与GPEN均发布报告总结发现，旨在提升全球消费者与隐私保护水平。
• 调查强调暗黑模式对消费者选择自主权和隐私权的普遍干扰，呼吁跨领域协同监管。

构建金融系统的工程原则

基础财务定义

• 总账：公司主要的会计记录，汇总特定时期内的所有财务交易。
• 子账：包含与特定总账相关的所有单个详细交易信息。
• 财务记录：指总账和子账。
• 重要性：信息误述是否会影响利益相关者的决策，该阈值因业务规模而异。

会计系统的三大目标

1. 准确性：财务记录必须反映业务已知状态且完整。示例：10件单价$9.99的商品，记录必须为$99.90。聚合海量交易时需警惕加法或舍入误差。完整性要求子账和总账全面代表所有业务活动，并需明确数据何时完备。
2. 可审计性：便于利益相关者检测错误、评估业务表现，并满足税务等监管要求。
3. 及时性：根据业务需求（如月度结算或近实时监控）提供财务数据。关键是不必过度追求流处理，而应满足实际消费者的数据更新频率需求。

三大工程原则

1. 数据不可变与持久性：数据一旦记录在财务记录中便不可删除，任何更正必须以新的财务交易呈现。这为任何时间点的状态提供了清晰的审计追踪。
2. 以最小粒度表示数据：财务事件应以最细的粒度保存。这便于调试、重算及纠正错误，总账和子账应由此粒度数据聚合计算得出。
3. 代码幂等性：每个金融事件只能被处理一次，重复记录会导致明显的不准确。

最佳实践

• 金额表示：优先使用整数（如美分），严格避免浮点数。支持货币转换的业务可使用微单位（1美元 = 1,000,000微单位）或DECIMAL(19,4)等类型以保持精度。
• 舍入方法：在全系统中保持一致的舍入规则（如四舍五入或始终向上舍入），微小差异在大量交易下会累积成重大金额。建议为舍入和货币转换创建集中式库或服务。
• 货币转换：延迟货币转换直到计算最后阶段，以在聚合过程中保持本地货币精度。
• 时间表示：使用整数表示时间（如Unix时间戳或基于整数的UTC日期时间），以避免不同时区、夏令时及不同技术库解析带来的复杂性。

本文探讨了 X Window System 启动时经典的网状背景图案（技术上称为 Stipple 或 Root Weave）的文化意义、技术实现及历史演变。

文化意义与历史背景

在早期系统中，X Window 的配置文件（如 XF86Config）极为繁琐，且错误的显示器参数可能导致硬件损坏。由于当时计算机启动速度慢，启动时首先显示的 Stipple 图案成为了 X Server 基本配置成功的“冒烟测试”信号。它为开发者提供了关键的视觉反馈，并由此成为一代计算机从业者的怀旧符号。

图案的消失与恢复

2010年代初，该启动画面逐渐从主流 Linux 发行版中消失。技术溯源发现，2008年 X.Org server 的一次代码提交引入了 -retro 标志和 party_like_its_1989 全局变量，默认移除了 Stipple 和经典光标，以推动生态现代化并提升启动速度。 用户仍可通过传递 -retro 参数恢复该图案（如 startx -- -retro）。然而，针对 XDM、LightDM 等不同显示管理器，修改配置的方法各异，凸显了 X 生态系统在参数传递上的碎片化。

技术定义与起源追溯

Stipple 的正式名称为 "root weave"。它在系统中存在双重定义：一是作为 X BitMap (XBM) 文件存放在系统 include 目录下；二是在 X Window 源代码（dix/window.c）中作为内联字面量静态定义。系统启动时实际调用的是源码中的静态数据。 通过追溯 XFree86 和 Project Athena 的历史归档，确认 root weave 及其相关位图最早出现于 1984年6月（X1）至 1986年2月（X10R3）之间。

生态衍生与架构反思

系统内还内置了其他历史悠久的位图（如 cross weave 和用于测试代码回归的 woman 位图）。文章同时回顾了 XFree86、Solaris Xsun 以及早期商业 X Server（如具备超前自动硬件探测功能的 Metro-X）的衍生关系。 通过审视早期环境和 X Server 源码，作者指出 X Window 的架构自 1980 年代以来积累了大量历史包袱。尽管对 X 充满感情，但作者认同其代码架构已难以维护，理解了 Wayland 取代 X 的技术必然性，并对 X 生态的美学设计进行了趣味性的假设与探讨。

文章摘要：《Big Ball of Mud (1999)》

本文由 Brian Foote 和 Joseph Yoder 撰写，发表于 1999 年。文章探讨了软件开发中一种普遍存在但很少被正式讨论的实际主导架构——“大泥球”。

核心概念 “大泥球”是一种随意、甚至杂乱无章的软件系统结构。其组织更多地取决于权宜之计，而非清晰的设计。尽管如此，这种架构的持久流行表明它并非一无是处。文章旨在分析导致“大泥球”形成的各种力量，并探讨改善系统架构的途径。

形成“大泥球”的力量 多种因素共同促使开发者构建出“大泥球”系统：

1. 时间与成本压力：架构设计常被视为奢侈品，优先考虑快速交付和短期功能。
2. 经验与技能限制：开发者对问题领域的理解不足或技能差异会影响架构决策。
3. 可见性与复杂性：软件内部结构的不可见性使得低质量代码容易被忽视；系统可能只是真实世界复杂问题的直接映射。
4. 需求变化：不断变化的需求可能彻底颠覆最初的架构设计，导致为适应新需求而进行随意修改。
5. 规模效应：大型项目的管理挑战会掩盖技术架构问题。

相关模式 从“大泥球”这一核心模式中衍生出以下六个相关模式，共同描述了系统退化和维护的过程：

1. 废弃代码：指最初为快速原型或一次性使用而编写的“脏代码”，却因有用而被长期保留，最终融入系统。
2. 渐进增长：系统通过一系列局部、零散的更改和添加而有机增长，缺乏整体规划。
3. 保持运行：首要目标是确保系统持续工作，这虽然维护了基本功能，但可能阻碍大规模的架构改进。
4. 剪切层：系统中不同部分以不同速率演变和变化，自然形成的“分层”或抽象有助于隔离变化。
5. 掩盖问题：面对难以理解或修复的混乱代码，一种策略是将其隔离（“扫到地毯下”），并通过清晰的接口将其功能封装起来。
6. 重建：当系统退化到无法维护或理解时，有时唯一的解决方案是抛弃现有代码，基于积累的经验从头开始重建。

结论与观点 文章最终指出，“大泥球”并非单纯的“反模式”，而是软件开发中各种现实力量作用下的自然产物，具有其存在的合理性。然而，作者的目标是识别这些力量，并倡导通过持续的重构和有意识的架构演进（如遵循“剪切层”理念）来防止系统完全退化成不可维护的“泥潭”。关键在于在系统演进过程中，不断地从实践中提炼和固化架构知识，从而使软件能够更好地适应变化并保持长期活力。

根据Sapien Labs发布的一项全球研究报告，首次拥有智能手机的年龄越小，成年后报告的心理健康状况越差。这一关联在所有研究区域均存在，且对年轻女性的影响显著强于男性。

核心发现

• 研究方法：Sapien Labs通过其“全球精神健康项目”进行持续调查，本次分析涉及近30万名参与者。研究在2023年1月增加了询问“首次拥有智能手机或平板电脑年龄”的问题。
• 主要结果：数据显示，10岁前首次拥有智能手机的年轻成年人（18-24岁），其心理健康商数（MHQ） 得分平均最低。MHQ是基于47个问题的综合心理健康评分。延迟到青少年中后期获得智能手机的参与者，心理健康状况明显更好。
• 性别差异：该关联在女性中表现得更为强烈和持续。在9岁前拥有智能手机的Z世代女性平均得分甚至为负值。
• 六维度分析：在构成MHQ的六个心理功能领域中，社交自我、情绪与观点两个领域与首次拥有智能手机的年龄关联最为紧密，这与抑郁症和焦虑症等内化障碍的上升趋势相吻合。

机制与背景

• 累积效应：研究强调，这反映的是拥有智能手机和长期使用其众多应用所产生的累积影响，而非近期使用频率的影响。
• 时代背景：该发现与21世纪10年代初全球范围内（尤其英语国家）青少年心理健康急剧恶化的趋势相吻合，而正是在这一时期，青少年社交生活从功能手机转向了智能手机，使得持续访问社交媒体成为可能。
• 相关性说明：研究显示的是相关关系。尽管因果机制复杂，且可能存在如“宽容型教养方式”等第三方变量，但数据模式（全球性、性别差异显著、与特定时代转折点同步）强烈暗示智能手机是关键因素之一。

政策与行动启示

基于研究结果，报告对家长、学校和立法者提出了具体建议：

1. 延迟给予智能设备：强烈建议家长在高中（约15岁）以前不为孩子配备智能手机，可使用仅能通话和发短信的“功能手机”作为替代，以解决通讯需求。
2. 推行“无手机学校”：建议小学和初中实施严格的“无手机校园”政策，让学生入校后将手机存放于储物柜或锁定袋中，以减少干扰、促进面对面互动。
3. 强化年龄验证与立法：
   • 当前美国法律要求社交媒体最低使用年龄为13岁，但缺乏强制年龄验证。多个州和联邦提案（如《保护儿童社交媒体法案》、《儿童在线安全法案》）旨在强制实施年龄限制并要求公司进行年龄验证。
   • 立法重点应放在保护14岁以下的儿童和青少年上，因为数据显示该年龄段与早期获得智能手机的负面关联最为陡峭。

研究局限与展望

• 样本代表性：参与者为自荐或通过广告招募，并非随机全国样本，因此所得均值可能不代表真实国民均值，但适用于分析群体内部差异。
• 需进一步研究：呼吁更多研究区分智能手机与平板电脑的影响，探索具体有害的应用类型，并进行以学校为单位的随机对照实验，以验证“无手机政策”的效果。

总结：Sapien Labs的研究为全球青少年心理健康危机提供了新的实证视角，表明早期拥有智能手机是一个重要风险因素。虽然相关性需谨慎解读，但综合现有证据，采取预防性措施（如延迟智能设备使用、净化校园环境、加强立法监管）是合理且必要的。

物理学家创造最复杂的迷宫

研究概述

由英国布里斯托大学物理学家Felix Flicker领导的团队，结合分形几何与国际象棋策略，创建了迄今最复杂的迷宫。该迷宫基于准晶的原子排列结构生成，其数学原理源自国际象棋中“骑士巡游”的哈密顿回路概念，并应用在Ammann-Beenker瓷砖（一种非周期性平铺图案）上。

核心概念与原理

• 哈密顿回路：在地图或网格中，一条访问所有节点（如国际象棋棋盘的所有格子或晶体中的所有原子）仅一次并返回起点的闭合路径。
• 准晶：一种自然界罕见的物质形态，其原子排列有序但非周期性重复，介于有序晶体（如钻石）与无序非晶固体（如玻璃）之间。其结构可通过非周期性平铺（如Ammann-Beenker瓷砖）描述。
• 分形特征：生成的迷宫具有自相似性，局部结构与整体结构相似，且规模可无限扩展，形成指数级增长的复杂路径。

迷宫生成过程

研究团队在Ammann-Beenker瓷砖的顶点（代表准晶中的原子）上寻找哈密顿回路。骑士在国际象棋中“跳两格一斜”的移动方式，被转化为在瓷砖图案中访问每个顶点一次的路径。该路径连接所有顶点，不自相交，从而自然形成一个迷宫。由于图案可无限细分，迷宫尺寸与复杂性呈指数增长。

研究意义

1. 数学与计算应用：解决哈密顿回路问题具有广泛意义，可能帮助优化复杂路径规划（如物流路由）及蛋白质折叠等科学问题。
2. 材料科学与工业应用：
   • 准晶结构可能优于传统晶体用于吸附（如碳捕获）。柔性分子能沿准晶的非规则排列更紧密地附着，且准晶易碎，可形成高比表面积颗粒，提升吸附效率。
   • 研究表明准晶在吸附技术中具有潜在应用价值。
3. 拓展对准晶的理解：通过数学建模哈密顿回路，深化了对准晶原子排列规律的认识。

相关背景

• Penrose瓷砖与Ammann-Beenker瓷砖均为非周期性平铺的经典数学模型，用于描述准晶结构。
• 准晶于1982年首次被发现，相关研究曾获诺贝尔化学奖，其特殊物理化学性质持续受到关注。

结论

该研究通过数学与物理的交叉方法，不仅生成了具有艺术性的复杂迷宫，还为准晶的结构分析和实际应用提供了新视角，潜在影响涵盖数学优化、材料科学及工业吸附技术。

研究发表于《Physical Review X》。

美国参议员两党达成协议，拟禁止国会议员股票交易

核心提案内容：

• 由民主党参议员乔恩·奥索夫、杰夫·默克利、加里·彼得斯与共和党参议员乔什·霍利共同提出。
• 立即生效：禁止现任国会议员、总统和副总统购买股票及其他受监管投资。
• 出售期限：给予立法者 90天 时间出售其现有股票。
• 扩展范围（2027年3月起）：
  • 禁止议员的配偶和受抚养子女交易股票。
  • 要求总统、副总统及所有国会议员剥离所有受监管投资。
• 处罚措施：违反剥离规定的议员将面临罚款，金额为其月薪或违规资产价值的 10% 中的较高者。

立法背景与推动因素：

• 该提案是多年来限制议员股票交易努力的最新进展，也是首个获得参议院委员会（国土安全与政府事务委员会）正式审议的版本（定于7月24日进行）。
• 伦理专家指出，立法者获取的特定信息可能为其提供投资不公平优势。
• 推动力主要来源于新冠疫情初期多名参议员在获得机密简报后进行高利润股票交易的事件，曾引发FBI的内幕交易调查（但未提起指控）。
• 前众议院议长南希·佩洛西（其丈夫为活跃的股票投资者）在2022年中期选举前改变了反对立场，为该努力增加了动力。

提案核心观点：

• 参议员霍利强调：“国会不应成为牟利之地”，议员不应利用其独有的信息获利。

《纽约时报书评》（NYT Book Review）曾被视作品味的仲裁者，但其实际表现却背离了严肃文学批评应有的样子。本文深入剖析了该刊物存在的诸多问题及其对文学界产生的深远负面影响。

影响力与现状的落差 尽管《书评》及其畅销书榜单长期被视为权威，但其实际影响力已大幅下降。研究指出，即便是负面书评也可能促进销量，且如今媒体环境剧变，书评对图书销售的推动作用已不显著。然而，它仍在出版界和读者中维持着一定影响，其不良倾向渗透了整个“图书文化”。

内容质量与风格缺陷 《书评》的评论普遍枯燥乏味、缺乏锐气。评论员们似乎受制于《纽约时报》的“标准”，倾向于避免发表有力见解或尖锐批评，导致评论千篇一律、沉闷乏味。这种设计旨在维持一种虚伪的“政治中立”，却牺牲了评论的个性和洞察力。

助长出版业不公 《书评》长期专注于大型出版社，忽视独立出版社和自出版作品，从而强化了出版业的物质不平等。出版业利润高度集中于高管，而基层编辑和代理人薪资微薄，导致行业越来越依赖于依靠家庭财富支撑的从业者。《书评》未能审视或挑战这种剥削性结构，甚至其资深评论员也利用职位便利获得了大型出版社的合同，存在潜在的利益冲突问题。

种族与叙事问题 尽管表面上增加了多样性，但《书评》在本质上仍受“白人视角”主导。它常以刻板方式对待非白人作家，将其作品简化为特定文化的代表。评论中时有公开的种族主义言论（如将西班牙语人名嘲讽为“抗抑郁药”），而对非白人作家作品的评价也往往围绕陈旧的移民或创伤叙事，限制了多元故事的发展。这形成了一个闭环：评论只认可模式化的故事，迫使出版商和作者不断重复这类叙事。

作为阶级攀升的工具 《纽约时报》整体服务于上层阶级和渴望跻身其中的人群，《书评》则扮演了“文化侍酒师”的角色，指导读者应读哪些“好书”以及如何谈论它们，以此作为融入精英阶层的文化资本。其“畅销书榜单”的制作方法被揭露是基于编辑判断而非纯粹的销量数据，本质上是编辑偏好的反映。

存在的伦理问题 文章指出《书评》在伦理规范上存在漏洞。例如，批评家德怀特·加纳的妻子克里·勒费弗尔在《纽约时报》工作并撰写书评，她所创作或关联的产品在报纸上获得推荐时，两人的夫妻关系却未被始终清晰披露，这涉及潜在的利益关联。

对出版生态的扭曲 《书评》塑造了一种扭曲的出版生态：它推崇明星作者，制造对陈旧故事的需求，并迫使作者为了迎合其偏好而写作。它将书籍和作者偶像化，却忽视了写作的物质条件——许多作者面临经济困境，无法仅靠写作为生。

未来的方向 作者认为，与其改善《书评》，不如超越它。未来的书评文化应更关注出版业的经济学，将书籍置于物质世界中进行考察。需要更多考虑独立出版社的作品，减少对自出版的污名化，并敢于回顾旧作。评论应提供清晰、诚实的意见，并严格披露任何利益冲突。最终目标是建立一个支持作者创作自由、承认写作是劳动、并能真正容纳多样声音的出版生态系统，而非维持由少数特权者主导的现状。

总之，《纽约时报书评》作为一个存在已久却日益腐朽的体系，已无法承担真正的文学批评功能，其固有的偏见与不公持续损害着图书文化的健康发展。

文章标题：模型火箭历时三年成功实现垂直着陆

核心内容概述： 该文章报道了高中生 Aryan Kapoor 及其团队 JRD Propulsion 历时三年，成功研制出能够模仿 SpaceX 火箭进行垂直着陆的模型火箭。这一项目展示了业余火箭爱好者将前沿航天技术微型化应用的毅力与创造力。

主要技术细节与实现过程：

1. 项目历程：项目始于2021年，Aryan 从零基础开始，系统性地进行了开发，包括制作静态测试载具、低空跳跃测试飞行器，并重点攻克了推力矢量控制这一关键技术。
2. 火箭设计：
   • 动力系统：采用两个固体燃料发动机，分别用于上升段和下降/着陆段，上下堆叠安装。
   • 推力矢量控制：发动机组安装在一个3D打印的万向节支架中，由两个伺服器驱动，可在两个维度上提供正负七度的推力偏转，由自定义飞行计算机控制。
   • 传感器与控制：飞行计算机集成了气压高度计和惯性测量单元以感知状态。
   • 着陆装置：采用橡皮筋吸收冲击力，并巧妙使用注射器筒作为减震器。
3. 测试与成功着陆：视频展示了首次成功的低空测试飞行。尽管火箭下降时明显偏离垂直状态，但着陆发动机点火后迅速纠正了姿态，最终实现了平稳垂直着陆。文章解释了首次触地后的颠簸是由于上升段发动机未能及时弹出所致，但整个系统成功应对了额外的重量。

总结：该项目是业余航天领域的一次出色实践，体现了通过系统学习、迭代测试和巧妙的工程设计，可以将复杂的航天技术应用于小规模模型上。Aryan Kapoor 的坚持与最终的成功获得了赞扬。

论文摘要：《An Abundance of Katherines: The Game Theory of Baby Naming》

研究背景

本文探讨婴儿命名这一高度竞争性领域，运用博弈论框架进行分析。

核心模型与假设

研究构建了一个基于以下**三个“极其合理假设”**的命名选择模型：

1. 父母是短视的决策者（只关注当前选择，不预测长期趋势）
2. 父母是信息完全的参与者（知晓所有命名流行度数据）
3. 父母仅根据名称的独特性选择名字（追求避免重复）

该模型旨在同时具备可处理性、简洁性并能准确反映现实世界的命名行为。

方法扩展

研究通过以下方式扩展了基础模型分析：

• 数值实验：进行模拟计算以测试模型行为。
• 大型语言模型工具分析：利用LLM工具辅助研究。

结论与展望

论文总结了研究发现，并提出了未来研究的可能方向。

补充信息

• 作者：Kate Donahue
• 提交历史：自2024年3月至7月共提交三个版本（v1-v3），文件大小均为1840KB。
• 内容形式：提供PDF、HTML（实验性）和摘要供查看。

本文针对人类探索太阳系（如月球、火星等）的需求，提出了在月球及更远区域建立坐标时间的相对论框架。该框架基于爱因斯坦的相对论原理，指出标准钟的速率受其所在位置的引力势和相对运动影响。通过建立一个可追溯至空间某预定点理想钟的同步时钟网格，可以确立坐标时间参考系，从而比较由引力和运动学效应引起的本地时钟时间变化。

研究具体提出了用于月球的坐标时间框架，并确定了基于地球大地水准面和月球赤道上标准钟的地球与月球坐标时间之间的关系。关键发现是：月球赤道附近的钟比地球赤道附近的钟走得更快，在一个月球轨道周期内，每天累计快约56.02微秒。该框架还被用于计算地球-月球拉格朗日点的时钟速率。

文章强调，准确估算不同天体间坐标时间的速率差异，并利用在相对稳定的拉格朗日点运行的轨道器时钟作为时间传递链路进行比对，对于建立可靠的通信基础设施至关重要。这一认识也支撑着地月空间及天体表面的精确导航，对确保从地球延伸至月球乃至太阳系内层最远区域的各类定位、导航与授时系统的互操作性具有核心作用。

本文总结了作者初次深入使用 SQLite 时的体验，重点梳理了其与传统关系型数据库（如 PostgreSQL）相比存在的核心技术差异与限制。

核心 DDL（数据定义语言）限制

• 不支持修改列和删除约束：SQLite 不支持 ALTER COLUMN 和 DROP CONSTRAINT 操作。官方推荐的替代方案是创建一个新表并进行数据迁移。

独特的类型系统

• 列无数据类型：SQLite 的列本身不具备数据类型，数据类型（仅有 5 种）仅依附于具体的“值”。这意味着任何类型的数据都可以被插入到任意列中。
• 静默接受无效类型：在创建表时，若使用了不支持或不存在的类型（如 bigserial 或 jsonb[]），系统不会抛出错误或警告，而是默默接受。这极易导致开发者误以为 SQLite 支持这些高级类型。
• 严格模式（STRICT）：开发者可以通过在 CREATE TABLE 语句中添加 STRICT 关键字，强制限定列只能使用 5 种受支持的基础类型：integer、real、text、blob 和 any。

特定数据类型的处理机制

• JSONB：与 PostgreSQL 不同，SQLite 中的 jsonb 并非真正的数据类型，而是内置 jsonb* 函数的输入/输出格式。在底层持久化存储时，它被作为 5 大基础类型之一的 blob 处理。
• 时间与日期：系统缺少类似 timestamptz 的专用时间类型。日期和时间数据必须存储为 Unix 时间戳（整数）或 ISO8601 格式的字符串，并依赖内置函数进行解析和操作。

总体评价

尽管 SQLite 具备出色的流式处理（streaming）等高级功能，但其独特的类型系统和 DDL 限制使得初始开发者体验（DX）具有一定的挑战性和割裂感。文章最后指出，这些体验上的差异进一步印证了作者关于 PostgreSQL 仍是世界上最优秀数据库的观点。