告别ChatGPT：研究人员为何开始在笔记本电脑上运行小型AI

研究人员正在改变使用人工智能的方式，从依赖云端大型模型转向在本地设备上运行小型、开放的AI工具。这一趋势源于对数据隐私、成本和访问控制的多重考量。

核心动机与优势

• 隐私与安全：本地运行AI意味着数据无需上传至云端，完全保留在用户设备上，这对处理敏感研究数据（如基因序列、未公开研究结果）至关重要。
• 降低依赖与成本：减少了对互联网连接和付费API服务的依赖，可以离线使用，长期来看可能降低运营成本。
• 可定制化与可控性：研究人员可以完全控制模型和数据流，根据特定任务微调模型，而不受第三方平台的限制。

如何实现本地AI

实现本地AI主要依赖一系列开源工具和框架：

• llama.cpp：一个关键工具，能让大型语言模型在普通消费级硬件（如笔记本电脑）上高效运行。
• 模型仓库：如Hugging Face提供了大量可下载的预训练模型。
• 专用应用：出现了如Ollama和GPT4All等用户友好的应用程序，简化了本地模型的部署和交互流程。

实际应用案例

文章以生物信息学家Chris Thorpe为例，他在笔记本电脑上运行本地LLM，用于将免疫系统蛋白质（MHC分子）数据库中的复杂数据（如结构图像、氨基酸序列）自动转换为可读的文本摘要，展示了本地AI在专业科研任务中的实用性。

面临的挑战与局限

• 技术门槛：设置本地AI环境需要一定的技术知识，尽管工具在简化，但仍比使用在线服务复杂。
• 硬件要求：运行强大的模型需要相当的计算资源（如大量内存和强劲的GPU），这可能限制其在较旧或较低端设备上的应用。
• 性能与输出质量：本地运行的小型模型在推理能力、知识广度和输出质量上通常无法与前沿的云端超大模型（如GPT-4）匹敌。

未来趋势

随着开源社区的快速发展和工具的不断易用化，在本地设备上运行定制化、领域专用的AI模型正变得越来越普遍。这标志着AI应用模式从集中式云服务向分布式、自主可控的个人或实验室计算环境转变，特别在注重数据隐私和研究自主性的学术界受到青睐。

通过景观图像可视化天气预报

传统气象站通常以原始数字数据显示传感器读数，解读这些仪表盘需要用户费力定位、理解并有效可视化特定参数，过程可能令人压力重重。而观看景观图像对人眼而言是自然而放松的体验，观察景观元素能减轻压力且几乎无需费力。

本文介绍了一种方法，展示了如何将天气信息编码进景观图像中，从而减少或无需依赖数字数据。

编码原理

图像描绘了森林中的一座小屋。图像的水平轴代表24小时时间线：左侧从当前时刻（以小屋标记）开始，延伸至右侧次日的状况。垂直轴上分布的景观元素象征天气事件与状况。事件离当前越远，在图像中就越靠右。

可在景观图像中编码的信息包括：

• 时间标记：日出、日落、正午、午夜，用于简化时间线导航。
• 天气预报信息：风向与风力、温度波动、最高与最低气温、云量、降水。
• 当前天气状况：温度、大气压。
• 非天气事件：生日、节假日等。

实现方式

图像生成代码使用Python和Pillow库编写，基于OpenWeather的数据。图像专为296x128的E-Ink显示屏设计，已在Python 3.9上测试通过。

景观元素与事件的对应关系：

• 日出/日落：太阳升起或落下。
• 云量：天空中的云朵。
• 当前时间位置：通过小屋或其他标记指示。
• 正午/午夜：太阳位于天空最高点或最低点。
• 风向：树木倾斜方向（如南风、东风、西风、北风）。
• 降水：雨滴或雪花。
• 大气压：通过特定图案（如高压、正常、低压）表示。
• 非天气事件：如生日蛋糕等图标。

编码示例：

• 树木越高，预示风力越强。
• 森林中树木种类混合，表示中间风向。

图像示例与描述

• 场景一：时间约为正午，天空晴朗有少量云。预计夜间会出现中等强度北风。气温目前上升，但日落后开始下降，在日出前达到最低点。期间风向预计转为东北。
• 场景二：日出时分，将是炎热晴朗的白天，伴有轻微东南风。日落后气温仍将保持较高，风向转为东风，并在夜间增强。
• 场景三：全天及夜间寒冷多雨。南风将在夜间转为西北风。别忘了明天是某人的生日。

代码运行与环境准备

1. 环境准备（Linux/Windows）：
   • 激活虚拟环境（source .venv/bin/activate）。
   • 在secrets.py中更新OWM_KEY变量为你的OpenWeather API密钥。
   • （可选）在secrets.py中修改坐标为你所在的位置。
2. 图像生成与测试：
   • 运行代码后，在"tmp"文件夹中查找生成的图像。
3. 启动服务器：
   • 运行服务器脚本后，可通过浏览器访问服务器页面查看生成的图像数量。

硬件与应用扩展

• 硬件设置：使用ESP32开发板和2.9英寸E-Ink显示屏模块。目前设置仅从互联网获取并显示图像，每15分钟更新一次。尚不确定图像生成代码是否能适配ESP32上的MicroPython。
• 手机应用：测试中生成了黑白图像（用于E-Ink模块）和彩色图像（可用于手机主屏幕）。对于Android设备，可使用Web Image Widget应用创建显示互联网图像的小部件。启动仓库中的服务器脚本后，添加指向生成图像的小部件即可使用。

文章总结了作者对Makefile的偏好及其在项目管理中的应用。作者最初接触Makefile时视其为传统工具，但随着时间推移逐渐欣赏其简洁与实用性。

Makefile的优势与用法

• 约定俗成的命令：Makefile通常遵循常见命令（如make、make build、make install），使陌生项目能快速构建与安装，同时提供操作指引。
• 项目管理便利性：作者在不同技术栈项目（如Jekyll、Hugo、Python框架）中使用Makefile统一管理任务，通过make dev等命令快速启动开发环境，无需记忆各技术特定的命令。
• 编排工具的能力：即使项目涉及Docker或Gulp等工具，作者仍用Makefile协调它们，例如make build可触发Docker镜像构建。

Makefile的设计特点

• 简洁性：作者避免使用复杂特性，大部分任务（targets）仅包含简单的shell命令。
• 常用任务示例：个人项目通常包含dev（启动开发服务器）、build（构建项目）、deploy（部署项目）等基础目标，有时添加watch（监控文件变化）。
• 案例说明：文章展示了两个Makefile示例：
  1. 极简版（仅含dev任务）；
  2. 复杂版（涵盖开发、构建、监控、部署及加密）。

Makefile的实用价值

• 广泛可用性：GNU Make在多数系统（如Linux、macOS）中预装，依赖少，在受限环境中更易使用。
• 手动执行的可能性：即使Make不可用，用户仍可手动执行Makefile中的命令，而其他工具（如Gulp）则依赖特定运行环境。

作者的结论
虽然作者积极接纳新兴构建工具，但Makefile因其命令标准化和低依赖特性，始终作为编排各类项目的通用工具。

本文介绍了如何在Linux、macOS和Windows上使用Container Desktop作为Docker Desktop的替代方案，并概述了其核心功能。

核心目标

提供一种跨平台（Linux、macOS、Windows）的容器管理方案，替代Docker Desktop，并支持Docker和Podman引擎，提供一致的用户界面。

各操作系统安装与配置指南

1. Linux

• 优势：原生体验，速度快，无需虚拟化。
• 快速安装：
  • 更新系统并安装必要依赖。
  • 安装 Docker Engine（非Docker Desktop）和 Podman。
  • 将用户添加到docker组并设置Docker服务开机自启。
• Podman兼容模式：启动Podman服务并监听/var/run/docker.sock，可使Podman模拟Docker功能。
• 连接Container Desktop：通过设置DOCKER_HOST环境变量与Container Desktop共享连接。

2. macOS

• 要求：需要虚拟化支持，推荐使用Homebrew简化安装。
• 快速安装：
  • 安装 Colima 作为容器运行时。
  • 使用colima start命令启动虚拟机（建议使用--vm-type=vz以获得更好性能）。
  • 安装Docker CLI及插件（非Docker Desktop），并配置插件目录。
• Podman最佳体验：可安装 LIMA 以分别管理Podman和Docker虚拟机。
• 替代方案：Colima提供完整的Docker兼容性，是替代Docker Desktop的简易方案。

3. Windows

• 要求：强烈推荐使用 WSL（Windows Subsystem for Linux）。
• 快速安装：
  • 启用并安装WSL及推荐的Ubuntu发行版。
  • 在WSL内参照Linux指南安装Docker或Podman引擎。
  • 可选安装Windows原生的Docker CLI和Podman客户端。
• 最佳体验：所有容器操作在WSL内的Linux环境中直接进行。
• 性能优化：建议配置WSL使用cgroups v2并禁用IPv6以提升兼容性。

Container Desktop 核心功能

1. 跨平台一致性：在Windows、Mac和Linux上提供相同的图形用户界面。
2. 多引擎支持：
   • 原生支持Linux。
   • 通过虚拟化（LIMA/WSL）支持Mac和Windows。
   • 同时支持 Podman 和 Docker 引擎。
3. 全面的资源管理：
   • 容器：查看日志、环境变量、端口映射、监控数据，并执行启停、重启等操作。
   • 镜像：查看镜像详情、从镜像创建容器、拉取/推送镜像。
   • 网络与卷：创建和管理网络、存储卷。
   • Pod与机器：管理Pod（Podman）和虚拟机（Podman Machine）。
   • 安全：检查镜像漏洞，提升系统安全性。
   • 秘密：管理应用程序的密钥和凭证。
4. 学习工具：是学习和使用Podman命令行的优秀图形化辅助工具。

总结

该文档提供了一套完整的指南，指导用户在三大主流操作系统上通过安装开源容器引擎（Docker或Podman）并搭配Container Desktop图形界面，来替代Docker Desktop，从而获得更轻量、灵活且功能强大的容器开发和管理体验。

AnySkin触觉传感器概述

核心目的：
AnySkin旨在解决触觉传感领域长期存在的挑战，包括通用性、可替换性和数据重用性，以促进其在机器人任务中的广泛应用。

设计特点：

• 基于ReSensor的简化设计，通过将传感电子设备与传感界面解耦，实现快速集成，类似于安装手机壳和连接充电器。
• 采用无粘合剂、耐用且易于替换的磁性设计，简化了制造和维护流程。

关键创新：
AnySkin是首个具备学习操纵策略的跨实例泛化能力的触觉传感器，允许在一个实例上训练的模型直接应用于新实例，提升了部署灵活性和数据效率。

三大贡献：

1. 制造与工具：引入了简化的制造过程和专用设计工具，用于创建高效、可替换的触觉传感器。
2. 性能表征：详细分析了AnySkin在滑动检测和策略学习任务中的表现，验证其精确性和可靠性。
3. 泛化能力：通过实验展示了模型在不同AnySkin实例间的泛化效果，并与主流触觉解决方案（如DIGIT和ReSkin）进行了对比，突出了其优势。

研究摘要

研究背景

Omega-3多不饱和脂肪酸（包括EPA和DHA）是人体必需脂肪，需通过食物摄入，对大脑功能和心血管健康至关重要。既往研究提示其具有抗炎特性并可能缓解抑郁和焦虑症状。

研究目的

本研究旨在探讨在饮食中添加Omega-3脂肪酸能否预防或减轻由慢性压力诱发的抑郁和焦虑样行为，并阐明其潜在机制。

实验方法

• 动物模型：使用40只1月龄C57BL/6雄性小鼠，分为四组（每组10只）：
  1. 对照组：正常饮食，无压力。
  2. 压力组：接受为期21天的不可预测超声波频率暴露以模拟慢性压力，无特殊饮食补充。
  3. Omega-3组：正常饮食并补充Omega-3（每日0.55 mg/kg EPA和DHA），无压力。
  4. 压力+Omega-3组：接受压力暴露的同时补充Omega-3。
• 评估指标：压力暴露后，通过多项行为测试（蔗糖偏好测试、新笼测试、明暗箱测试、旷场测试）评估抑郁和焦虑样行为。实验后采集血液和脑组织，检测压力激素（皮质酮）水平及炎症相关基因（TNF和IL-1β）的表达。

主要发现

1. 行为变化：仅接受压力暴露的小鼠表现出明显的抑郁和焦虑样行为（如蔗糖摄入减少、探索行为降低）。同时补充Omega-3的小鼠则未出现这些显著行为变化，且在行为测试中表现更接近正常。
2. 生化与分子变化：压力组小鼠的皮质酮水平以及脑部TNF和IL-1β基因表达均显著升高，表明存在应激反应和神经炎症。补充Omega-3显著降低了这些压力组小鼠的皮质酮水平和炎症标志物。
3. 保护作用：未受压力但补充Omega-3的小鼠，其焦虑样行为也比对照组更少，提示Omega-3本身可能具有普遍的抗焦虑益处。

研究结论

Omega-3脂肪酸（EPA和DHA）补充剂能有效对抗慢性压力（本研究中以超声波模型模拟）诱导的小鼠抑郁和焦虑样行为。其保护作用可能主要源于其抗炎特性，有助于减轻压力引起的大脑炎症。

重要提示

本研究结论基于小鼠模型。尽管小鼠与人类在生理上有诸多相似之处，但两者存在显著差异。这些在小鼠身上观察到的效果未必能直接应用于人类患者，需要进一步研究来确认Omega-3补充剂在人体中是否具有相同的益处。

论文信息

该研究论文题为《Omega-3 alleviates behavioral and molecular changes in a mouse model of stress-induced juvenile depression》，已发表于《Neurobiology of Stress》期刊。

Kamal Proxy 是一款轻量级 HTTP 代理工具，专为实现零停机部署而设计。它通过在 Web 应用前运行，允许在不中断现有连接的情况下进行更新部署，且无需应用本身做特殊适配。

主要功能与用途

• 专为零停机部署设计，能协调新旧实例的流量切换。
• 作为 Kamal 部署工具套件的一部分，也可独立使用。
• 无需配置文件，通过命令行选项运行和管理。

基本使用

1. 启动代理：使用 kamal-proxy run 命令，可通过 --http-port 等选项自定义端口（默认80）。
2. 部署应用实例：使用 kamal-proxy deploy <服务名> --target <主机:端口> 将应用实例注册到代理。代理会立即对其进行健康检查（默认每秒向 /up 发送 GET 请求，期望 200 响应）。健康检查通过后，所有新流量将切换到该实例，并等待旧实例的已有连接排空后再移除旧实例，从而实现零停机。

高级配置

• 自定义健康检查：可通过 --health-check-path、--health-check-port、--health-check-timeout 和 --health-check-interval 参数调整。
• 主机路由：通过 --host 参数指定域名，使同一服务器上的多个应用可共享一个代理实例，互不冲突。
• 路径路由：通过 --path-prefix 参数将不同路径前缀的流量导向不同服务。默认会去除前缀转发，可通过 --strip-path-prefix=false 保留原始路径。
• TLS 配置：
  • 自动 TLS：部署时添加 --tls 参数，代理会自动申请和更新证书（需指定主机）。
  • 手动 TLS：可通过 --tls-certificate-path 和 --tls-private-key-path 指定自定义证书和私钥文件。

运行配置 kamal-proxy run 的选项可通过环境变量设置，例如 HTTP_PORT=8080。为避免冲突，可使用 KAMAL_PROXY_ 前缀（如 KAMAL_PROXY_HTTP_PORT=8080）。

构建与尝试

• 可在本地 Go 环境中构建，或通过提供的 Dockerfile 构建为容器。
• 项目中的 example 文件夹提供了 Docker Compose 示例，便于体验。

苹果发布 iPhone 16 与 iPhone 16 Pro 系列维修手册

苹果公司在新款 iPhone 16 机型发布后，分享了适用于 iPhone 16、iPhone 16 Plus、iPhone 16 Pro 和 iPhone 16 Pro Max 的维修手册。该手册提供了更换苹果正品部件的技术指导，其目标用户是具备必要知识、经验和工具的“独立技术人员”。

主要维修性改进

1. 电池更换更便捷：

   • iPhone 16 与 16 Plus：采用了电力式电池拆卸流程。根据单独的支持文档，可通过连接一个9伏电池和电池夹来释放固定电池的粘合剂，使拆卸过程更为简化。
   • iPhone 16 Pro 与 Pro Max：仍使用传统粘拉片，需小心拉出以释放电池。
   • 所有型号的电池更换指南都涉及昂贵的专业设备（如iPhone电池压机）。

2. 其他部件可维修性提升：

   • Face ID摄像头：支持在设备上进行配置。
   • LiDAR扫描仪：现已可维修。
   • TrueDepth摄像头模块：支持在iPhone 16与iPhone 16 Pro机型之间互换使用。

目标受众与成本考量

苹果的维修手册及所需工具和原装零件成本较高，使得自行维修的费用几乎接近于前往苹果零售店或授权服务提供商进行维修。因此，这些手册实际上更适用于独立维修店，而非普通个人消费者。

内部结构揭示

维修手册还首次披露了新iPhone的一些内部设计细节：

• iPhone 16 Pro：电池采用了金属外壳，此设计出于散热考虑。
• 两款Pro机型：均采用了新的外壳结构，以改善散热效果。

注：文章后续提及的iOS 27、iPhone 18 Pro电池容量及macOS 27兼容性等内容与维修手册主题无关，未包含在此摘要中。

美国联邦通信委员会（FCC）提出新规，要求所有手机在激活后60天内必须解锁，即使设备仍在付款计划中且有未结清余额。该提案已获FCC五名委员一致批准，但正式实施仍需时间。

主要运营商反应不一：

• AT&T和T-Mobile明确反对。AT&T认为这可能影响其提供平价设备的能力；T-Mobile态度更为强硬，质疑FCC是否有权推行此类变更，并暗示这可能导致公司放弃设备分期付款计划。T-Mobile援引最高法院2022年的一项裁决，主张此类“具有重大政治经济影响”的问题需国会明确授权。
• Verizon表示支持，因其早年与FCC达成协议，已在60天内解锁手机。支持新规有助于消除竞争对手在eSIM试用方面的优势，创造更公平的竞争环境。

目前，该政策仍在推进阶段，AT&T和T-Mobile预计将利用资源阻止新规，并可能推动国会介入。尽管面临阻力，FCC已通过收购协议等方式（如收购Mint Mobile时要求T-Mobile实施类似规则）展现其推动更短解锁期限的决心。长期来看，新规可能最终落地，但短期内仍将面临激烈争论。

扩展线性规划：PDLP 求解器总结

背景与动机

线性规划（LP）是运筹学和计算机科学的基础，但传统的单纯形法和内点法因依赖矩阵分解，在处理超大规模问题时面临内存溢出和难以利用 GPU 及分布式系统等现代硬件的瓶颈。一阶方法（FOMs）主要依赖矩阵-向量乘法，内存需求低且高度兼容现代计算架构，成为解决大规模 LP 问题的理想替代方案。

PDLP 简介

PDLP 是 Google 在 OR-Tools 中开源的基于 FOM 的 LP 求解器。它通过矩阵-向量乘法替代矩阵分解，大幅降低内存消耗并提升扩展性，该项目荣获了 2024 年计算优化领域的权威奖项 Beale–Orchard-Hays 奖。

核心算法：重启 PDHG

标准原始对偶混合梯度（PDHG）算法在求解 LP 时可靠性不足。PDLP 采用重启 PDHG（Restarted PDHG） 算法，利用双循环结构，在触发条件时计算迭代平均值并从该点重启。此策略利用 PDHG 的螺旋轨迹特性有效缩短收敛路径，在理论和实践中均显著提升了收敛速度与可靠性。

关键功能与改进

PDLP 在核心算法基础上进行了五项关键增强：

1. 预处理（Presolving）：检测并消除冗余与不一致，简化问题以降低复杂度。
2. 预条件处理（Preconditioning）：重新缩放变量和约束，优化数值条件以加速收敛。
3. 不可行性检测：利用迭代信息，在无额外计算成本的情况下检测问题的不可行性或无界性。
4. 自适应重启：智能决定最佳重启时机，加速高精度求解。
5. 自适应步长：根据问题特征动态调整步长，减少手动调参需求。

实际应用

PDLP 的扩展能力解锁了多个超大规模应用场景：

• 数据中心流量工程：已在 Google 生产环境部署，实现全局网络流量路由优化，大幅节省机器资源。
• 集装箱航运优化：求解超大规模多层多商品流问题的线性松弛，有效评估启发式算法的质量。
• 旅行商问题（TSP）：成功求解约束矩阵包含高达 120 亿个非零元素的 TSP 下界 LP 实例，超越了当前最先进的商业求解器。

广泛影响

PDLP 在工业界和学术界产生了深远影响。其 GPU 实现 cuPDLP.jl 已开源，并被商业求解器 Cardinal Optimizer 和开源求解器 HiGHS 集成。学术界也基于 PDLP 在 PDHG 理论分析、条件数理论以及向二次规划和半定规划的扩展等方面展开了持续研究，不断推动计算优化领域的发展。

文章总结：档案包装的“盒子之战”

本文探讨了档案工作者如何包装（或“存放”）纸质文档以实现长期保存，重点比较了加拿大与英国两种常见的标准化包装方法，并解释了其背后的原理与实践差异。

核心概念与动机

• 标准化包装：档案工作者普遍使用特制的酸性纸或纸板容器（文件夹和档案盒）来存放“手部尺度”的文档（即大多数可手持的纸质及照片记录）。
• 目的：标准化包装能提供长期保护（防尘、防潮、防物理损坏）、便于空间管理和快速检索，并与档案著录系统相联。
• 比较动机：文章旨在打破人们对档案库房的刻板印象（如电影中杂乱无章的景象），展示真实的、有序的档案保存实践，并满足公众与专业人员对保存技术的好奇。

两种主要包装风格

1. 加拿大（及北美）的垂直式包装

• 基本工具：
  • 文件夹：带标签的折叠式酸性纸文件夹。
  • 档案盒：主要使用“霍林格盒”（小型立式盒）和“银行家盒”（较大），尺寸通常适配法律尺寸文件（8.5x14英寸）。
  • 辅助材料：内部使用纸或无酸塑料封套、衬纸等进一步稳定文档。
• 配置方法：
  • 文件夹：文件竖立放置于盒中，文件夹底部需调整以适应内容厚度。
  • 装盒：文件夹在盒中紧密竖立排列，用泡沫等填充物确保文件不倾倒。
  • 上架：档案盒单层平放于专用货架上，便于取阅。
• 优点：便于快速取放单个文件；文档边缘得到较好保护；文件标签一目了然；空气流通良好。
• 缺点：填充不当易导致文档卷曲；文件可能倾倒散落。

2. 英国（及部分欧洲国家）的水平式（平放）包装

• 基本工具：
  • 文件夹/封套：常用带有翻盖的四折或两折文件夹、大型无酸纸封套，或直接用无酸纸包裹。
  • 档案盒：通常为浅口盒，带可拆卸盒盖。
  • 辅助材料：常用棉或麻质档案带捆扎文件夹，并使用“国库标签”（一种穿孔绑带）固定成册文件。
• 配置方法：
  • 文件夹：文件夹用档案带捆扎后平放。
  • 装盒：文件夹平叠于盒中，较厚或较重的放于底部。
  • 上架：档案盒在货架上多层叠放。
• 优点：重力均匀作用于文档，利于保持平整；文件夹完全闭合，防尘防光效果好；可混合存放不同尺寸的文件夹。
• 缺点：取用特定文件时可能需要移动多个文件夹或盒子；重新捆扎带子可能被忽略；捆绑过紧可能损伤文件边缘。

共同原则与灵活实践

• 共同目标：两种方法均旨在控制、保护和访问档案，核心是平衡保存需求与实用效率。
• 灵活性：
  • 两种方法存在交叉（如北美对大型文件使用平放盒，英国对某些记录使用垂直存放）。
  • 面对特殊载体（如地图、照片、音视频资料）或脆弱文物时，档案工作者会定制特殊包装。
  • 实践中常需在理想包装与资源限制之间做出妥协，优先处理最具破坏性的原有包装（如生锈回形针）。
• 哲学视角：垂直存储与办公文化的历史发展相关，而平放存储则被部分从业者视为赋予档案“特殊地位”的象征。

结论

档案包装并无绝对优劣，其差异主要源于历史传统与地域实践。无论采用何种方式，档案工作者均致力于运用标准化包装作为“武器”，对抗时间的侵蚀，以保存人类记忆。文章通过大量实例图片展示了针对各种特殊材料的创新包装解决方案，体现了全球档案界在保护使命上的共同追求。

Furnace：史上最庞大的多系统芯片音乐追踪器

Furnace 是一款开源、跨平台的芯片音乐（Chiptune）创作与播放软件，以其支持的声卡芯片数量和种类之多而被誉为“史上最大的多系统芯片音乐追踪器”。

核心特性

1. 广泛的硬件模拟支持：

   • FM合成芯片：支持众多雅马哈FM芯片，如YM2151、YM2612（世嘉Genesis）、YMF262（OPL3）等。
   • 方波/PSG芯片：如AY-3-8910、TI SN76489、PC Speaker、SID（Commodore 64）等。
   • 采样芯片：支持SNES、Amiga、SegaPCM、QSound等多种采样音频硬件。
   • 波表芯片：如PC Engine的HuC6280、Konami SCC/SCC+等。
   • 现代/幻想硬件：如Commander X16 VERA、PowerNoise等。
   • 其他经典系统：包括NES（含多种扩展音频）、Game Boy、Atari POKEY、Game Boy Advance、Nintendo DS等。

2. 强大的创作功能：

   • 混合与匹配：允许在一个项目中组合使用多种声卡芯片（最多32种芯片或128个通道）。
   • 预设库：提供超过200个来自真实电脑、游戏机、街机的预设。
   • 兼容性：能够加载和保存DefleMask的.dmf模块文件，并兼容其.dmp乐器和.dmw波表文件，可作为模块降级工具。
   • 波表合成器：为支持波表的芯片提供易于使用的波表合成工具。
   • 导出选项：支持导出为VGM、ZSM、SAP等多种芯片音乐格式，以及音频文件（整首曲目、按芯片或按通道）。
   • 高级编辑功能：包含FM宏、负八度、高级琶音宏、任意音高采样、可调采样循环点、内置采样编辑器、可视化器等。

3. 用户友好性：

   • 模块化布局：界面可自定义调整。
   • MIDI输入支持。
   • 多平台支持：提供Windows、macOS和Linux的发布版本，也可通过源代码编译。

社区与支持

• 开源协议：基于GPLv2或更高版本/GPLv3开源。
• 文档与帮助：提供快速入门指南、详细文档、常见问题解答。
• 社区渠道：拥有官方的讨论区（Discussions）和Discord服务器。
• 包管理：已可通过Flathub（Flatpak）以及在Arch Linux、FreeBSD、Nix、openSUSE等发行版的官方或社区仓库安装。

开发者信息

Furnace 提供了详细的从源代码构建指南，包括：

• 依赖项：CMake、Git、C/C++编译器。
• 平台特定指南：分别针对Windows（MSYS2/MinGW或Visual Studio）、macOS（Xcode命令行工具）和Linux/Unix-like系统提供了开发环境设置说明。
• 编译步骤：清晰列出了获取源代码、使用CMake配置、进行编译的命令。
• CMake选项：提供大量构建选项以控制功能，如是否构建GUI、启用MIDI支持、使用特定的音频后端或依赖库版本等。
• 故障排除：针对编译过程中可能出现的常见错误提供了详细的解决方案。

总结而言，Furnace 是一个功能极其全面、高度模块化且对硬件模拟还原度高的芯片音乐创作平台，既适合音乐创作者使用，也因其开源和详细的开发者文档而利于社区参与和扩展。

文章讲述了1970年代初，日本Busicom公司为开发先进计算器而与初创企业Intel合作，最终意外催生了首款商用微处理器Intel 4004的历史故事。

背景与起因： Busicom是一家技术冒险的日本计算器公司，为开发型号为141-PF的打印计算器，工程师岛正利设计了一个基于“计算机系统”方案的复杂集成电路需求。与此同时，Sharp公司的高管佐佐木对Busicom提供支持，并促成了其与Intel的合作。

方案的转折： Intel工程师Ted Hoff认为Busicom原方案过于复杂，提出了一个更简化的方案：采用一套标准化的芯片组（包括中央处理单元、内存和移位寄存器），通过软件程序实现不同功能。这一方案虽然更简单，但当时Intel内部兴趣不大。

关键决策与诞生： 1969年10月，Busicom高管访问Intel，意外地选择了Hoff的简化方案。随后，Intel招募了芯片设计专家Federico Faggin负责实现。Faggin与岛正利、Stanley Mazor合作，于1971年初完成了著名的MCS-4芯片组的研制，其核心正是4位的4004微处理器，以及配套的ROM、RAM和移位寄存器芯片。岛正利用此芯片组成功组装了141-PF计算器。

意外的商业化： Busicom因财务困难试图降低芯片采购价。Intel借此机会谈判，使Busicom同意放弃芯片组的独家采购权，从而Intel可以自由地将这套名为MCS-4的芯片组向市场销售。尽管初期销量有限，但市场反响热烈，证明了微处理器作为通用组件的潜力。Intel随后推出了更强大的8008等后续产品。

影响与结局： 微处理器的诞生加速了数字革命，从工业控制到个人电脑（如后来的Intel 8086和IBM PC）。Federico Faggin后来离开Intel创立了Zilog公司，设计了更成功的Z80微处理器。 反观Busicom，其微处理器计算器并未成功。Mostek为其开发的“计算器单芯片”方案更经济，但公司终因激烈的市场竞争于1974年倒闭。

专利轶事： Intel未为4004申请专利。得州仪器（TI）曾获得微处理器专利，但后来有发明者声称更早的设计，该专利后因技术不可行而被宣布无效。

Inngest 1.0：开源持久化工作流平台

Inngest 是一个开源的持久化工作流平台，旨在帮助开发者构建可靠的产品，而无需处理复杂的基础设施管理。

核心价值与定位

• 聚焦产品，而非基础设施：平台让用户无需编写工人进程、重构代码或构建监控工具，即可实现应用可靠性。
• 技术栈兼容性：支持在本地从现有技术栈开始开发，并能部署到任意云平台。

关键功能特性

1. 开发体验

• 步骤化工作流：通过SDK提供简单的构建块（如 step.run），每个步骤自动重试并确保一次成功执行，实现代码级事务管理。
• 状态自动管理：函数状态在步骤间自动保持，实现容错。
• 一键安装与开发：通过单个命令安装CLI并启动本地开发服务器。
• 即时调试与追踪：提供结构化日志和实时追踪（包括AI提示/响应对），便于快速调试。

2. 工作流管理与可靠性

• 自动化重试与恢复：自动处理错误重试，并通过节流、批处理和优先级保证高效运行。故障后能从断点恢复。
• 深度可观测性：内置实时追踪和指标监控，无需自行构建。
• 规模扩展：平台设计可扩展，每月处理数十亿工作流。

3. 资源与流程控制

• 动态资源分配：支持基于键的并发控制、节流等功能，确保所有用户获得良好体验。
• 公平资源分布：消除“噪声邻居”问题，随用户增长高效扩展。

4. 恢复工具

• 问题快速识别与处理：通过云端告警和指标快速定位问题，并支持批量重放和取消操作。
• 批量故障恢复：可批量重试失败的工作流，替代传统的死信队列方案。

企业级特性

• 安全与合规：符合SOC 2标准，提供端到端加密、单点登录（SSO）和SAML支持。
• 高性能设计：支持每秒超过10万次执行，具备低延迟特性。
• 数据协议支持：可提供HIPAA业务关联协议（BAA），以处理敏感数据。

Inngest 已被全球众多软件公司采用，帮助企业专注于产品构建而非基础设施维护。

本文探讨了在运行时使用不同glibc版本的问题，反驳了必须依赖容器的观点，并详细解释了相关技术原理与解决方案。

核心问题
工作讨论中认为，为运行针对现代glibc的测试，需要在开发机器上设置容器，理由是通过LD_LIBRARY_PATH加载不同glibc不可行，静态链接glibc也不可能。但作者认为，运行不同于系统默认版本的glibc是常见需求，glibc开发团队在容器出现前必然有其他测试方法。

技术原理

1. 静态与动态链接二进制：
   • 静态二进制（如Go程序）包含所有代码，直接加载到内存执行。
   • 动态链接二进制（如C程序）代码不完整，需在运行时由动态链接器（如ld-linux-x86-64.so.2）加载共享库并完成重定位（填补代码“缺口”）。
2. 动态链接器与glibc的耦合：
   • 动态链接器由glibc提供，与libc.so.6紧密耦合。仅替换libc.so.6而使用系统链接器可能导致崩溃。
   • 实验证明：设置LD_LIBRARY_PATH指向新glibc目录运行程序会崩溃，但显式调用新glibc附带的动态链接器（如/tmp/sysroot/lib/ld-linux-x86-64.so.2 ./hello_c）则成功，且无需设置LD_LIBRARY_PATH。

实用方法

1. 显式指定动态链接器：
   在运行命令前添加新glibc的动态链接器路径。
2. 构建时设置解释器：
   通过编译器链接参数-Wl,--dynamic-linker=/新路径/ld-linux-x86-64.so.2，使二进制文件内置指定链接器。
3. 修改已有二进制：
   使用patchelf --set-interpreter /新路径/ld-linux-x86-64.so.2修改现有二进制文件。

版本兼容性限制
glibc的兼容性是单向的：旧版构建的程序可在新版运行，但新版构建的程序可能无法在旧版运行。这导致开发与生产环境升级glibc时需协调。

版本化sysroot方案
为解决兼容性问题，可创建版本化的sysroot目录（如/usr/sysroot/v1/），确保：

• 所有生产二进制均基于特定版本sysroot构建和测试。
• 新版sysroot（如v2/）先部署至所有环境，再重建依赖它的二进制。
• sysroot目录保持不可变且在环境中同步，以保证确定性。

结论
容器并非解决此类系统问题的最佳选择。Unix系统本身提供了更轻量、便携的解决方案（如动态链接器的显式调用和sysroot管理）。应避免过度依赖容器，以减少开发工具和部署的复杂度。

文章总结：利用YouTube窃取文件的安全研究

本文描述了一种通过Google Slides嵌入YouTube视频的漏洞，结合路径遍历、开放重定向和点击劫持技术，最终实现未授权访问Google Drive文件的攻击链。

攻击原理与步骤

1. 初始入口：Sliders的YouTube嵌入功能

   • Google Slides允许通过视频ID嵌入YouTube视频，生成指向www.youtube.com/embed/{VIDEOID}的iframe。
   • 研究人员通过将VIDEOID替换为../进行路径遍历，成功将iframe定向到YouTube主页。尽管YouTube主页因防点击劫持策略无法直接嵌入，但发现其他资源路径（如/s/下的资源）可能被嵌入。

2. 关键重定向漏洞

   • 寻找可在iframe中使用的开放重定向。YouTube视频描述中的链接重定向（/redirect端点）需要会话令牌，且设置了X-Frame-Options: SAMEORIGIN，无法利用。
   • 发现**/signin端点存在漏洞：其next参数允许重定向到任何YouTube子域名**（如www.youtube.com, music.youtube.com），无需验证令牌。
   • 进一步发现**accounts.youtube.com/accounts/SetSID端点**，其continue参数允许重定向到更广泛的Google自有域名，包括docs.google.com。

3. 绕过服务器端限制

   • 直接通过跨域重定向访问docs.google.com/file/d/{ID}/edit页面会被服务器基于Sec-Fetch-Dest和Sec-Fetch-Site头阻止（返回403）。
   • 通过链式重定向绕过：先重定向到docs.google.com/a/a/...（一个遗留的、会重定向的旧格式URL），实现同域内的二次重定向，从而欺骗服务器的安全检查。

4. 实施点击劫持窃取权限

   • docs.google.com/file/d/{ID}/edit页面即使嵌入在iframe中，其**“分享”按钮仍保持可用**。
   • 通过测试发现，向该URL添加?userstoinvite=attacker@email.com参数，会自动在分享对话框中填充攻击者的邮箱。
   • 攻击者将包含此参数的文档URL，通过前述的accounts.youtube.com和youtube.com/signin重定向链包装，并最终通过Sliders的路径遍历漏洞嵌入到幻灯片中。

5. 最终攻击载体

   • 将嵌入的真实分享对话框用伪装成Google表单的HTML元素覆盖，仅露出“发送”按钮。
   • 受害者被诱导点击按钮后，会立即将目标文件/文件夹的编辑者权限授予攻击者指定的邮箱。
   • 攻击者可通过将幻灯片URL中的/edit改为/present来直接向受害者展示此恶意幻灯片。

结论与结果

• 该攻击链综合了Sliders的路径遍历、YouTube的认证重定向漏洞、Google Docs的框架化和权限管理漏洞，最终实现了只需一次点击即可窃取云存储文件访问权限的高级点击劫持攻击。
• 漏洞于2024年7月1日报告给谷歌，同日确认。谷歌于7月11日授予总计**$4133.70**的漏洞赏金。
• 研究人员在BSides Tallinn 2024等安全会议上进行了相关演讲。

文章总结

本文探讨了成人社会交往中“主动发起对话”的实用技巧，旨在帮助读者在新环境（如新工作、新班级）或日常互动中建立良好的第一印象。核心观点包括：

1. 成人社交的复杂性：相较于儿童，成人建立友谊更为复杂，需要策略性练习。
2. 为何要与陌生人交谈：尽管在某些文化或地区（如美国大城市）与陌生人搭话可能被视为冒犯，但在多数场合（如小镇、排队时），这是一种友好行为。更重要的是，这有助于练习在关键场合（如职场、课堂）给人留下好印象的必要技能。
3. 如何开始对话：
   • 问候与认可：可以从非语言认可（短暂眼神接触、微笑、点头）或简单问候（“你好”）开始，逐步发展为更长的对话。
   • 发表安全正面的评论：在适当时机（社交距离内），对周围环境、天气，或对方的服饰（如运动队标志、T恤标语）发表简短、轻松的正面评论。目的是试探对方是否愿意互动，而非传递信息。
   • 避免敏感话题：初期应避免评论对方外貌、透露过多个人信息，以及讨论宗教、政治、性等易引发争议的话题。
   • 共同抱怨（需谨慎）：就共同的不便（如恶劣天气、排长队）进行善意的、带微笑的抱怨，可以拉近距离，但需避免显得过于负面。
   • 观察反应与适时放弃：如果对方仅以非语言方式回应或未回应，可以尝试一次。若对方仍无互动意愿或表现出不悦，应停止，避免纠缠。
4. 解读对方发出的社交信号：
   • 眼神接触与微笑：对方先进行短暂眼神接触并微笑，通常是友好、愿意交流的信号。
   • 个人距离：美国人与朋友交谈的舒适距离约为1.5-4英尺。对陌生人，4-12英尺较为合适。若对方后退，表明不想交谈。
   • 身体语言：“开放”的身体姿态（身体朝向对方）可能表示愿意互动；“封闭”的姿态（交叉手臂、身体侧转）则相反。
   • 非言语行为：若对方专注于阅读、手机等活动，可能不愿被打扰。一些无意识的自我安抚行为（如轻摆头发）可能暗示对方感到无聊，愿意交谈。但一些剧烈或非常规的自我刺激行为则可能让人回避。
5. 是否及何时自我介绍：文章提及这是一个常见问题，但未给出明确结论，建议参考相关研究。

总之，成功的社交开场需要观察环境、解读非语言信号、使用安全话题开启互动，并尊重他人的边界。反复练习这些策略有助于提升在各种社会场景中的交往能力。

引力热灾难

1962年，V. A. Antonov的模拟表明，在牛顿力学中，引力系统可违反常规热力学规则，无法达到平衡而持续升温。假设将大量恒星置于一大球体内，它们作为点质量仅通过引力相互作用，且为弹性碰撞（无真实碰撞），系统总能量（动能与势能之和）为负，即引力束缚。

若球体半径 ( R ) 满足 ( R < 0.335 GM^2/(-E) )（其中 ( M ) 为总质量，( E ) 为总能量，( G ) 为引力常数），系统将近似达到均匀密度的气体平衡。

但若球体更大，部分恒星会向中心聚集形成致密星团。该星团持续收缩并急剧“升温”（恒星运动加速）：部分高速逸出，其余则补充进入，导致所有恒星速度持续增加，球壁压力不断上升，此现象即为 引力热灾难。

能量守恒未被破坏：星团收缩使负势能增加，平衡了恒星动能的增长。系统因任意大的负势能可无限将势能转为动能，从而违反常规热力学规则，类似于球体沿无限斜坡滚动。

为防止球体因内部压力上升而爆炸，增大球体可暂时缓解，但中心星团持续加热，压力最终仍将上升。唯一终止失控升温的方法是缩小球体，以对抗内部气体压力。当球体缩小至接近中心星团大小时，系统似乎回归平衡，但温度和压力远高于初始状态。

即使平衡态也是亚稳态：随机形成的微小致密星团可再次触发引力热灾难。D. Lynden-Bell 和 Roger Wood 的论文（1968）详细描述了这一过程，尤其生动阐述了如何应对此失控现象。

文中“恒星”指代大质量点粒子，但该研究有助于理解现实引力系统（如球状星团）。在球状星团中，中心密度极高时可能发生恒星碰撞并形成黑洞，例如 Messier 15 星团所示。后续观测可能更为复杂。

文章作者描述了在两年前取消Dropbox订阅后，公司持续进行“挽回”营销活动的个人经历。

• 背景：作者在取消订阅时，曾从帮助论坛得到保证，其留下的超过1TB数据将不会被删除。
• 发展：随后两年，Dropbox开始发送大量（超过50封）挽回邮件。邮件内容从友好提醒逐渐升级，使用“超出限额100倍”、“情况紧急”、“必须立即打开”等措辞，并辅以随意的标点符号和表情符号。
• 威胁升级：当常规方式无效后，Dropbox违背了最初的承诺，开始发送一系列倒计时邮件，最终威胁要在15天内删除作者的文件，并设定了具体日期。
• 结果：设定的删除日期过后，作者的文件并未被删除。尽管一封邮件链接到的支持文章声称如果超限最终会删除数据，但原始搜索结果仍显示不会删除的旧答案。此后，Dropbox又回到了建议升级的旧策略。
• 现状：作者登录网页版时，仍会看到提示其存储空间不足并要求升级的警报，但所有文件依然存在。
• 作者的思考：文章最后，作者质疑是否应该相信企业的承诺，并认为为非付费客户永久托管文件的商业模式存在缺陷。他好奇这场“数字对峙”将持续多久，以及文件最终是否会被删除。

这篇文章探讨了如何将 Unix 系统功能集成到 Common Lisp 环境中，主要通过具体的数据处理示例对比了 POSIX Shell 与 Common Lisp 的实现方式。

核心概念：文章通过一个实际的数据处理任务（分析 SSH 日志以找出失败登录的用户）来展示方法。POSIX Shell 通常依赖一系列文本流处理命令（如 grep, sed, sort, uniq），而 Common Lisp 则利用其函数式编程、结构化数据处理和宏能力来完成类似工作。

主要对比点：

1. 函数与宏：例如，Shell 中的 mcd 函数（创建目录并进入）在 Lisp 中可被定义为一个宏。
2. 数据获取与管道：
   • Shell：ssh server journalctl | grep sshd | ...
   • Lisp：可通过类似 (pipe journal (grep sshd) ...) 或更 Lisp 风格的 filter 与 lambda 表达式实现。
3. 中间结果处理：
   • Shell 可能依赖临时文件。
   • Lisp 则可利用 REPL 变量（如 *, **）或 def 将结果直接绑定到变量，便于后续使用。
4. 数据转换与分析：
   • Shell 使用 sed 进行正则匹配提取，sort | uniq -c 进行统计。
   • Lisp 使用 cl-ppcre 进行正则匹配，并推荐处理结构化的列表和数字，例如使用 frequencies 函数统计频率，生成关联列表（alist），再用 sort 和 subseq 获取前十结果。
5. 最终输出：
   • Shell 使用 awk 和 paste 生成逗号分隔列表。
   • Lisp 使用 mapcar 和 string-join 对结构化数据进行更清晰的转换。
6. 聚合计算：在汇总数据时，Lisp 可以直接对关联列表中的数值使用 reduce 进行求和，避免了 Shell 中通过字符串操作构建数学表达式的复杂方式。
7. 参数传递：文章最后给出了一个管理 Rust 工具链的例子，展示如何用 Lisp 函数生成待卸载的工具链列表，并将其作为参数传递给命令，体现了 Lisp 处理命令行参数的能力。

结论：文章旨在说明 Common Lisp 能够像 Unix Shell 一样方便地执行系统级脚本和数据处理任务，且在处理复杂逻辑和结构化数据时，其代码通常更清晰、更具表达力，避免了 Shell 中常见的“魔法字符串操作”。它通过具体的代码片段，演示了如何将 Unix 的管道、过滤和文本处理思维“移植”到 Lisp 的函数式和宏编程范式中。