《凯尔斯之书》是中世纪欧洲最著名的插图手稿之一，被视为爱尔兰最重要的文化瑰宝。该书以其精美艺术作品和丰富插图著称，全书共680页，远超同时期其他手稿。每年有近百万游客前往都柏林参观这部手稿，成为不可或缺的文化地标。

该手稿采用希伯诺-撒克逊（Hiberno-Saxon）艺术风格，原作据信于公元806年在苏格兰爱奥那岛编写，后因维京袭击而转移到爱尔兰梅斯郡的凯尔斯修道院。内容主要包括新约四福音书的抄本及标准对照表（canon tables），创作目的偏重展示而非朗读，因此插图极为繁复精细，文字则常有遗漏或重复段落。

作为仪式性文物，《凯尔斯之书》的艺术复杂性极大激发观者想象力。爱尔兰三一学院教授Rachel Moss与Fáinche Ryan指出，只有亲眼见过《凯尔斯之书》，才能算真正了解爱尔兰。现在，随着数字化技术的发展，公众无需亲赴都柏林，即可在三一学院图书馆的在线收藏中看到完整的高分辨率扫描图像。这些图像最近利用先进成像技术重新扫描，极大提升了细节呈现，仅次于实物观赏体验。

《凯尔斯之书》的特质让它成为“爱尔兰性”的象征，其图案甚至出现于爱尔兰货币及纹身等多种媒介。关于其独特意义，学者认为无法用单一答案概括。他们通过免费的在线课程，介绍手稿历史及其对不同社群的意义。对爱尔兰人而言，该书体现民族自豪，是连接历史辉煌与独特艺术的实物纽带。

尽管《凯尔斯之书》代表了现代爱尔兰文化身份，它的制作材料和技术却源自数百年前，曾遍及欧洲、中东及北非。三一学院图书馆保护员John Gillis在相关视频中介绍，此书采用古老的“书卷”形式制作，使用牛皮羊皮纸，皮面甚至保留动物本身的结构痕迹。

该手稿保存状况较佳，主要归功于精心维护，但历史上曾多次重新装订（约五次）。最初版本更厚更大，随着岁月推移已有30页丢失，19世纪一次重新装订更导致边缘严重修剪。即便如此，《凯尔斯之书》仍被誉为插图手稿时代最令人印象深刻的作品之一，被部分学者称为“世界上最著名的手稿”。

公众可通过三一学院图书馆在线平台浏览完整的数字化手稿图片，并参考专家的解读课程了解其历史与艺术。对于希望拥有实体精美印刷本的人士，可参考《The Book of Kells: Reproductions from the manuscript in Trinity College, Dublin》。

相关阅读还包括： 免费在线学习《凯尔斯之书》的相关课程；探索《贝里公爵的极富盛名时辰书》等其它中世纪插图手稿；欣赏中世纪僧侣的手稿素描本；英国图书馆与法国国家图书馆提供的800部中世纪插图手稿免费下载资源；以及关于中世纪插图手稿边缘中出现“坏兔子”图案的探究内容。

在Apple Silicon上虚拟化iOS的技术探索

项目背景与动机

作者长期投入 vma2pwn 项目，该项目可创建可修改的 macOS 虚拟机启动链。随着 Apple Silicon Mac 的推出以及 Mac Catalyst 的出现，iOS 与 macOS 系统架构前所未有地趋近。受此启发，作者尝试探索是否能在 Apple Silicon Mac 上虚拟化 iOS。

核心发现与策略

1. 关键突破：发现 Apple Virtualization.framework 中一个未公开的私有函数 _setProductionModeEnabled(false)。该函数可将虚拟机置于“非生产/非安全”模式。在此模式下，Apple 的签名服务器（TSS）会为虚拟机签署任意固件，从而极大简化了启动链的修改过程。
2. 基本策略：复用一套完整的 macOS 12.0.1 启动链，仅将其系统镜像、mtree、root_hash 和 trustcache 文件替换为 iOS 15.0.2 (iPhone XR) 的对应文件。选择 iPhone XR 构建版是因为其为 arm64e 架构（与 vma2 内核兼容）且分辨率较低。
3. 工具链：使用自行修改的 super-tart 来管理虚拟机并调用私有 API，以及修改版的 idevicerestore 进行恢复。需要关闭系统完整性保护（SIP）。

核心技术挑战与解决方案

项目的主要工作在于解决 macOS 内核与 iOS 用户态组件之间的各种不兼容问题，需要进行大量二进制补丁。

内核补丁

• 绕过签名验证：对 vma2 内核中多个函数（如 _apfs_extract_root_hash_arm、_img4_firmware_evaluate 等）进行补丁，使其返回成功。
• 绕过平台检查：iOS 二进制文件会被内核以“平台错误”为由终止。通过将 XNU 内核中检查 PLATFORM_IOS 的条件分支 (B.NE) 改为无条件跳转 (B) 来解决。
• 解决 IOMFB 兼容性问题：iOS 系统框架与 macOS 内核之间传递的 IOMFB 结构体大小不匹配，会导致内核恐慌。通过补丁移除 IOMobileFramebufferUserClient::swap_submit 中的大小检查来解决。
• 系统键袋：iOS 与 macOS 内核对系统键袋的处理不兼容，导致设备停留在 PreBoard.app 而无法进入正常设置。通过补丁 ipc_make_system_keybag 函数来绕过错误检查（目前仅为部分解决方案）。

系统（用户态）补丁

1. 恢复盘修改：
   • 补丁 restored_external 二进制，跳过创建系统键袋时的错误检查。
   • 修改 asr 二进制，绕过镜像签名验证。
2. iOS 系统卷修改：
   • 文件系统布局：将系统卷中大部分文件移动到 /System/Library/Templates/Data 目录，以匹配 macOS 的启动方式。
   • 修改 launchd：
     • 修改其内嵌的配置 plist，添加与 macOS launchd 兼容的字段（如 PerformAfterUserspaceReboot），并调整数据保护部分的设置。
     • 补丁以跳过因用户空间重启导致版本不匹配而引发的内核恐慌。
   • 处理 keybagd：该服务因键袋不兼容而失败。临时方案是用一个直接返回 0 的简单程序替换它。
   • 替换 mount 命令：iOS 的 mount 不支持 macOS APFS 卷。直接用 macOS 的 mount 二进制替换，并修改其元数据以在 iOS 上运行。
   • 修改 DYLD 共享缓存：
     • 将 iOS 的 IOCoreSurfaceRoot 驱动引用重命名为 macOS 内核期望的 IOSurfaceRoot。
     • 此操作会破坏 DSC 的代码签名哈希（cdhash）。需要通过内核调试找到旧的 cdhash，并在 DSC 文件中定位并替换为新的哈希值。
3. 激活绕过：
   • 补丁 lockdownd 和 mobileactivationd，强制设置 ShouldHactivate 为真，以在开发环境中绕过正常的 iOS 激活限制。

未解决的问题与未来展望

• 系统键袋：这是阻止 iOS 完全启动的核心障碍，需要更深入的理解和更多补丁。
• 触摸功能：尚不确定触摸是否可用。文章提供了使用 Virtualization.framework 未公开触摸 API 的示例代码框架。
• 作者希望社区能在此基础上进一步探索，突破 PreBoard.app 的限制。

AI阻碍web开发学习

背景

作者作为JumboCode（Tufts大学一个由180名学生组成的俱乐部，为非营利组织构建软件）的工程主管，观察到大多数开发者从零开始学习web开发（如TypeScript、React），几乎没有编程经验。在俱乐部中，大型语言模型（LLMs）的使用非常普遍。

LLMs的能力与问题

LLMs擅长生成web开发代码，例如描述前端组件后能输出像样的React组件。然而，作者在审查代码时发现大量代码看起来像LLM生成，表现为注释过多、不协调，甚至存在严重错误。

具体错误示例

在一个Next.js项目中，出现了以下问题：

• 一个页面使用HTML和原生JavaScript编写，放在public/目录下，完全脱离Next.js + React系统。
• 通过dangerouslySetInnerHTML加载并执行文件系统API中的原生JavaScript。
• 服务器端API端点之间进行localhost:3000调用，而不是直接导入函数调用。

这些错误表明开发者对工具和web平台有根本误解，而非典型的初学者错误。LLMs会顺从地提供解决方案，但如果你缺乏基础知识，就无法发现请求偏离正轨。

使用LLMs阻碍学习

LLMs是完成作业的捷径，但在此过程中几乎学不到东西。学习需要通过挣扎、尝试不同路径、拼凑信息来形成心智模型。LLMs允许跳过这一步骤，直接获得结果，但在需要验证代码架构合理性时，你会缺乏心智模型。LLMs适合已有良好心智模型的人，但从零开始学习时具有破坏性。

建议与现状

向人提问（如技术主管或JumboCode董事会成员）是更好的学习方式，他们能在需要的上下文中解释，且人类通常比LLMs提供更简洁、合适水平的解释。然而，由于提问困难且需要勇气，许多人仍会使用LLMs生成代码。作者认为，如果依赖LLMs完成整个任务，参加JumboCode可能不如不做，因为通过LLM生成交付物的过程不值得时间投入。

附录：作者的LLM使用

作者自己使用LLMs（如Cursor AI代码编辑器），但庆幸在LLMs普及前学习了web开发基础。这为作者带来了巨大回报，而如果早期依赖LLMs生成工作，可能无法真正学会web开发。

数据可视化目录是一个指南，旨在帮助用户根据其分析或沟通需求，选择恰当的图表类型。该目录主要按照图表的数据可视化功能或其期望传达的信息进行分类。

尽管将每个图表精确地归入特定功能类别并非完美的系统，但它仍然作为一个实用的参考工具，帮助用户基于想要展示的内容来筛选图表。

该目录包含以下主要分类：

• 比较：用于展示数据间的差异。
• 比例：用于显示各部分占比。
• 关系：用于揭示变量之间的联系。
• 层次：用于表现组织或结构关系。
• 概念：用于解释抽象想法或流程。
• 位置：用于地理或空间数据展示。
• 部分与整体：用于显示组成部分与整体的关系。
• 分布：用于展示数据的分布状态。
• 工作原理：用于解释系统或机制。
• 流程与方法：用于描述步骤或过程。
• 移动或流动：用于表示运动或传输。
• 模式：用于识别数据中的规律或趋势。
• 范围：用于显示数值的变化区间。
• 随时间变化的数据：用于跟踪数据随时间的变化。
• 分析文本：用于对文本内容进行分析。
• 参考工具：作为查找图表的索引。

用户可以通过点击相应的分类图标，进入更具体的图表推荐页面，从而找到最适合其数据可视化目标的方法。

WiLo 技术：结合 Wi-Fi 与 LoRa 实现长距离无线通信

核心概念：研究人员提出了一种名为 WiLo 的混合技术，旨在结合 Wi-Fi 的普及性与 LoRa 的长距离、低功耗特性，从而在不增加额外硬件的情况下，于现有设备上实现远程物联网（IoT）通信。

技术背景与动机：

• Wi-Fi 的局限：覆盖范围有限且功耗较高。
• LoRa 的优势：专为低功耗广域网设计，具备长距离通信能力，常用于物联网。
• 目标：融合两者优势，创建一种更高效、可扩展的无线通信方案，适用于农业传感器、智慧城市等需要长距离连接的物联网应用。

关键技术实现：

• 硬件基础：实验使用了市售的 Semtech SX1280 LoRa 收发器（工作在 2.4 GHz 频段，与 Wi-Fi 共享频谱但协议不兼容）。
• 核心算法：通过操纵 Wi-Fi 的正交频分复用（OFDM） 信号，使其模拟 LoRa 的线性调频扩频（CSS） 信号。这使得标准 Wi-Fi 设备能够与 LoRa 网络直接通信，无需额外的网关或桥接硬件。
• 优势：降低了部署成本、系统复杂性和潜在故障点。

实验与成果：

• 在室内（实验室、走廊）和室外环境中进行了测试，最远通信距离达 500 米。
• 数据传输成功率达到 96%。

当前局限性：

• 功耗增加：Wi-Fi 设备在同时处理通信与信号模拟时，会消耗更多能量。

未来发展方向：

1. 性能优化：提高能效、数据速率以及抗干扰能力。
2. 系统完善：进行软件开发、跨环境测试，确保符合行业标准并集成安全机制。
3. 商业化准备：通过进一步优化推动技术落地。

研究来源：相关研究成果已发表于《IEEE 通信汇刊》。

Postgres表结构优化可显著提高存储效率。文章指出，仅通过调整表的列顺序，就能减少约20%的表与索引空间占用，主要原因在于Postgres的数据对齐（Alignment）机制，而不是数据本身的大小。核心要点如下：

Postgres数据行与对齐机制

• 一行数据的最小存储空间为24字节，加入不同类型的列后，空间理论应直接叠加各类型字节数。
• 然而，实际存储大小受列顺序影响。例如，(int, smallint)与(smallint, int)同样的数据，后者因数据对齐要求需加入填充字节，导致空间膨胀。
• 具体类型对齐需求：bool无需对齐（char alignment），int2需2字节对齐，int4需4字节对齐，int8需8字节对齐。对齐时，Postgres将在列前插入padding，保证每个字段按指定边界起始。
• 可通过查询pg_type表查看各类型的typalign与typlen属性。

对齐对表和索引的影响

• 列顺序对齐不佳的表和索引，实际存储空间膨胀显著。实验中，10百万行的三列表，（int4, int8, int4）结构占498MB，而优化为（int4, int4, int8）只需422MB。对应索引空间分别为386MB与300MB，节省率分别为15%与22%。
• 对表空间的影响同时带来性能提升：行小则每页可存更多行，访问磁盘页次数下降，缓存页内数据量提升。

何时关注对齐

• 对齐优化在初创阶段并非首要，但建议在表设计、尤其索引设计阶段优先关注对齐。索引顺序调整较易，表结构调整难度大（涉及迁移历史数据与应用层查询模式）。
• 建议采用“按数据类型字节降序排列”原则：大型数据类型（如int8、float8、timestamp）优先，小型类型靠后。

TOAST机制对变长字段的影响

• 对于如varchar、text等字段，Postgres采用TOAST机制，将过大数据拆分存储并仅存指针于主表。单字节指针无需对齐，四字节指针需4字节对齐，带来额外空间节省。

其他数据库对齐情况

• SQLite不进行内部对齐，所有数据紧凑存储，节省空间但访问需更多CPU处理。
• MySQL：
  • NDB存储引擎采用4字节对齐，小于4字节字段有padding。
  • InnoDB主要对定长CHAR类型进行填充，但未见严格对齐所有字段的机制。
• 实践建议：在MySQL等数据库中，表或索引的对齐优化影响可能不及Postgres明显。

总结要点

• 数据对齐影响Postgres表与索引空间与性能，应优先关注列排序，尤其针对大表与索引。
• 索引重构需要与应用查询模式同步调整，表列顺序更改则可迟后进行。
• 变长字段（TOASTed值）及特殊类型（如uuid）对齐影响有限。
• 其他数据库对齐行为因引擎不同存在差异，需具体分析。

经验法则

• 列顺序按类型大小降序排列，先放大类型再放小类型，有效降低填充空间。
• 索引设计阶段优先优化对齐，后期数据模型调整更易执行。

字节跳动被指滥用免费的视频下载服务 Cobalt，进行大规模的数据爬取活动。该服务原本旨在为用户提供免费的视频下载便利，但字节跳动的行为被认为超出了合理使用范围。

HPy：Python 的更优 C 扩展 API

HPy 是一套用于以 C 语言扩展 Python 的全新 API，旨在替代传统的 #include <Python.h>，改用 #include <hpy.h>。

核心优势

• CPython 零开销：使用 HPy 编写的扩展在 CPython 上运行速度与传统扩展相同。
• 在替代实现上更快：在 PyPy、GraalPy 等 Python 实现上，性能显著提升。
• 通用二进制：基于 HPy 通用 ABI 构建的扩展，无需修改即可在 CPython、PyPy、GraalPython 等多种解释器上运行。
• 迁移路径：支持将旧式 C API 调用与 HPy API 调用混合使用。完成全部迁移后，扩展可编译为通用二进制，兼容各版本 CPython、PyPy 及 GraalPy。
• 调试模式：可在运行时激活调试模式，用于检测内存泄漏、对象生命周期无效及 API 误用（如忘记 Py_INCREF 或 Py_DECREF）等常见问题。
• 更优的 API 设计：旨在克服旧标准 Python/C API 的局限性，设计更一致，有助于生成更高质量的扩展并减少错误引入。
• 可演化性：传统 Python/C API 暴露了大量内部实现细节，阻碍了 API 的演进（参见 PEP 620）。HPy 通过隐藏所有内部细节解决了此问题。

当前状态

HPy 正处于积极开发阶段，最新版本为 0.9.0 alpha，正致力于推出稳定版本。项目认为其 ABI 已足够稳定，可兑现向后和向前二进制兼容性的承诺，且 API 已覆盖足够多用例，能够移植重要软件包（例如 numpy）。

实验性 HPy 兼容扩展

项目已对多个扩展进行移植试验，包括：

• ultrajson-hpy：首个移植到 HPy 的真实世界模块。
• piconumpy：一个定义了自定义类型（类似 ndarray）的极简 numpy 风格模块。
• numpy：目标是将 numpy 移植到 HPy，该移植已接近通过测试套件。
• matplotlib：由于依赖 numpy，其向通用模式的迁移尚未完全完成，目前使用 HPy 的旧版兼容 API。
• kiwi-solver：matplotlib 的依赖项，已完全移植到通用模式。

基准测试表明，HPy 移植对 CPython 性能影响甚微，并能为完全使用 HPy 的模块（如 kiwi-solver）在 GraalVM Python 上带来接近 CPython 的性能。

需要帮助的领域

由于资源有限，项目在以下方面寻求社区贡献：

1. 文档：部分文档尚不完整。
2. 宣传推广：需要吸引更多软件包开发者关注和使用 HPy。
3. 工具开发：例如自动化迁移工具，用于将包从 C API 迁移到 HPy API 时处理模板代码。
4. 打包问题：涉及通用扩展如何打包并发布至 PyPI、HPy 自身如何打包、以及如何与 setuptools、mesonpy 等构建系统集成等。
5. 网站与标志设计。

更多信息

• 发音：/eɪtʃ-paɪ/（即 “h-pie”）。
• 资源：项目提供文档、博客、GitHub 仓库、Discord 服务器、邮件列表及 IRC 频道。

Magic Kernel Sharp 图像缩放算法总结

核心定义与重要性

Magic Kernel Sharp（MKS）是目前图像缩放领域的“黄金标准”算法，自2013年起用于Facebook所有图片缩放，2015年起用于Instagram。它能够产生清晰、几乎无伪影的缩放结果，且计算效率高于传统的Lanczos核。

历史发展

1. 起源（2006年）：作者在IJG JPEG库的“fancy upsampling”功能中发现一个简单的插值核（权重1/4和3/4），用于色度通道上采样。该核能多次放大图像且效果良好，但结果略有模糊。
2. 推广（2011年）：将上述核推广为可处理任意尺寸缩放的“Magic Kernel”，并分析其数学性质。
3. 算法形成（2013年）：在Facebook工作期间，为解决硬件库缩放质量问题，将Magic Kernel与一个简单的三抽头锐化滤波器（Sharp）结合，形成Magic Kernel Sharp。该算法被部署到Facebook后端，提升了图像质量和计算效率。
4. 进一步优化（2015年）：分析了MKS的傅里叶特性，发现其在采样频率的整数倍处具有高阶零点，这解释了其优异的抗混叠性能。同年，为满足Instagram对“更锐利”图像的需求，开发了“Magic Kernel Sharp+”变体。
5. 数学深化（2021年）：推导出Magic Kernel是矩形窗函数自卷积两次的结果（即三次sinc函数），并认识到MKS是基本缩放核序列中的第三个。同年，推出了数学上更精确的“Magic Kernel Sharp 2021”版本，在理论上不模糊也不锐化图像（精确到至少9位精度）。

算法原理与特性

• Magic Kernel：具有有限支撑、非负、连续且一阶导数连续的插值核，形状类似高斯函数，是单位分解。
• Sharp步骤：一个简单的锐化滤波器，用于补偿Magic Kernel引入的轻微模糊。
• 傅里叶特性：MKS在采样频率的整数倍处具有高阶零点，能显著抑制低频混叠伪影，这是其视觉效果优于Lanczos核的关键。
• 优势：缩放结果清晰、无伪影；计算效率高于Lanczos核；避免了Lanczos核在放大时可能产生的像素化问题和在缩小时可能产生的“拍频”问题。

主要版本与应用建议

1. Magic Kernel Sharp 2013：
   • 特点：包含轻微锐化，视觉上更“生动”，计算效率更高。
   • 应用：适用于大多数实际应用场景，Facebook和Instagram使用此版本。
2. Magic Kernel Sharp 2021：
   • 特点：理论上频谱更平坦，几乎不改变图像锐度，但可能引入更多“吉布斯振铃”，且计算效率略低。
   • 应用：适用于对频谱平坦性有严格要求的场景（如某些mipmap算法）。

实现与部署

• 分解实现：通常分为两个独立步骤：1) 使用Magic Kernel缩放；2) 应用Sharp滤波器。此方式计算效率最高。
• 单核实现：也可组合成单个缩放核，但通常效率略低。
• 采用情况：已被众多主流库和平台集成，包括ImageMagick、libvips、Pillow（Python）、PyTorch、Rust库等。
• 代码与资源：作者提供了参考ANSI C实现（MIT-0许可证）以及详细的实现指南和测试工具。

附注

该算法最初是为了解决Facebook海量图片缩放的实际质量问题而诞生的，其数学原理经过多年探索才完全阐明。作者鼓励开发者使用该算法，并提供支持。

CoRncrete：一种基于玉米淀粉的建筑材料

核心概念
CoRncrete是一种新型建筑生物材料，由玉米淀粉、沙子和水混合制成。其利用了淀粉的天然聚合物特性，具备可再生和可降解的优势。

材料特性与制备工艺

• 自密实性：湿态混合物具有自密实特性，便于浇注成型。
• 成型方法：将混合物倒入模具后，通过微波或烤箱加热。
• 硬化原理：加热引发淀粉的糊化过程，使材料硬化。
• 力学性能：硬化后的CoRncrete压缩强度可达26 MPa。

关键研究内容
研究重点分析了影响CoRncrete强度的因素，包括：

• 含水量
• 沙子骨料尺寸
• 加热工艺

可持续性与局限性

• 论文阐述了材料的降解特性及可持续性潜力。
• 同时也讨论了其在实际应用中可能存在的局限性。

储物间盗窃事件总结与经验教训

文章作者讲述了其存储老式计算机和收藏品的储物间两次被盗的经历，重点总结了从事件中吸取的教训，为同类收藏者提供了实用建议。

事件概述

• 第一次盗窃：发生在约二十年前一家安全措施极差的连锁储物设施。设施门为胶合板材质，铰链外露，无监控摄像头。窃贼通过拆卸铰链进入，盗走了松下VHS摄像机、奥林巴斯数码相机、Fisher-Price PXL2000摄像机和备用Mattel Intellivision等物品。仅Intellivision被追回，作者支付了60美元赎回。保险索赔因缺乏购买凭证被拒。
• 第二次盗窃：发生在2024年8月，当前使用的设施安全措施较好（有卷帘门、安全插销和监控），但外门曾为普通门锁。窃贼用撬棍破坏门锁，并钻开圆盘锁（作者曾使用）。盗走了Atari Portfolio、Agenda VR3 PDA套装和Titanium PowerBook G4等物品。第二单元因内部货架阻碍未能完全进入，但造成硬盘损坏。保险索赔过程繁琐，最终以折旧价值（ACV）赔付了部分金额。

核心经验教训

1. 设施安全至关重要：选择安全措施完善的储物设施能有效预防盗窃。高质量设施更可能与合理的保险公司合作。
2. 存放可替代物品：避免在储物间存放真正珍贵或不可替代的物品。盗窃风险外，还需警惕管理不善导致的物品被拍卖。
3. 使用圆盘锁：比普通挂锁更安全，且多数保险公司会因此减免免赔额。建议购买储物设施认可的品牌。
4. 布置策略增加盗窃难度：将高价值物品放在后方，用大件重物遮挡。将包装精美的物品放入普通纸箱并模糊标记，可降低被窃概率。
5. 保险索赔需主动跟进：索赔过程可能繁琐且结果不确定，需持续跟进。物品照片和详细清单可能不足以证明所有权，保险公司常要求购买凭证。
6. 预期管理：几乎不可能获得全额赔偿。保险通常按物品折旧价值赔付，而非实际或替换价值。

设施改进措施

作者所在储物设施在盗窃事件后采取了改进措施：

• 安装了带死栓的密码锁（之前仅为门闩式）。
• 逐步将卷帘门更换为防盗圆筒锁，取代传统挂锁。
• 提供锁具防护罩，增加破坏难度。

最终建议

对于存储老式计算机的收藏者，应优先考虑储物设施的安全性，妥善规划物品存放布局，使用推荐锁具，并对保险索赔保持现实预期。作者强调，物品终究是身外之物，应避免存放无法承受损失的关键收藏。

这篇文章介绍了一张二战时期Smith-Corona打字机公司的回购海报及其历史背景。

海报内容 海报号召美国公民出于爱国精神，将闲置的打字机卖回给政府。由于二战期间打字机生产线转为军用，导致军队急需超过50万台标准打字机用于战地、舰船和指挥部。Smith-Corona公司承诺按1941年的标准折价回购1935年后生产的机器，并呼吁民众保养好现有打字机。

公司历史 Smith-Corona（LC Smith & Corona打字机公司）至今仍在运营。公司曾是大型打字机与计算器制造商，在20世纪60年代扩张为多元化工业集团。70年代计算器业务被电子计算器取代，80年代打字机业务因个人电脑普及而崩溃。公司此后转向生产文字处理打字机，并于2010年进入工业标签和热转印色带市场，目前不再生产打字机。

历史背景与起源

• 时代背景：海报发布于1942年9月28日的《生活》杂志第91页，正值二战期间。美国工业产能全面转向军需生产，导致民用打字机短缺。
• 行业情况：当时美国三大打字机厂商（Underwood、Smith-Corona、Royal）均已停产民品，转而进行战争生产。三家公司都推出了类似的打字机回购计划，以支援政府。
• 政策依据：根据1942年8月价格管理局（OPA）的文件《配给：原因与方法》，打字机制造厂已转产枪械零件，加上战争对金属的需求，打字机生产于1942年初削减并很快完全停止。政府于7月启动了收购50万台二手机器的计划，并对打字机实施配给制度。

后续发展与配给制度

• 1942年12月，价格管理局修订规定，禁止向平民出售所有标准打字机（过时型号除外），并将非便携式打字机的租赁限制为1935年前生产的型号。
• 打字机消费配给一直持续到1944年4月。价格管理局于1944年4月20日宣布，经销商手中的二手和新打字机不再需要配给，但制造商手中的新机器仍受战争生产委员会控制。此举是因为当时库存改善，加上政府收购计划结束，缓解了需求压力。

• awk的惯用法强调简洁和高效，主张充分发挥条件语句的“条件 {动作}”结构；许多初学awk的程序会显得冗长，不懂这些惯用法。

• 如果只想根据条件（如正则匹配）打印行，不需要写完整的if结构，无需显式print $0。比如：

  • awk '{if ($0 ~ /pattern/) print $0}'可简化为awk '/pattern/'。
  • 仅写条件时，匹配时awk自动执行默认的print $0。
  • 任何恒为真的条件（如1）都会打印全部行，可以用于处理每行后继续输出：如awk '{sub(/pattern/,"foobar")} 1'实现对所有行做sub替换并输出，功能类似sed 's/pattern/foobar/'。

• 常见条件表达式举例：

  • awk 'NR%6'：打印除6,12,...外的所有行
  • awk 'NR>5'：打印第6行及以后（类似tail -n +6）
  • awk '$2=="foo"'：打印第二列为“foo”的行
  • awk 'NF>=6'：打印字段数大于等于6的行
  • awk '/foo/ && /bar/'：同时包含foo和bar的行
  • awk '/foo/,/bar/'：打印从出现foo到bar的所有行（包括两者）
  • awk 'NF'：只打印非空行
  • awk '!a[$0]++'：去重行
  • awk '$0=NR" "$0'：行首加行号

• awk的条件兼动作的灵活应用：

  • 赋值（如ORS=NR%5?FS:RS）可作为条件，借此实现紧凑输入列排列。例如：seq 1 30 | awk 'ORS=NR%5?FS:RS'实现5列分组输出。
  • ORS, FS, RS等特殊变量可配合三目运算符应用，调整输出格式。
  • 若行数不是5的倍数，尾部自动处理换行可用END块解决。

• 关于字段分隔符替换：

  • 仅用-v FS=';' -v OFS=',' 1 不会修改分隔符，awk只有在某字段被修改后才重组$0。因此，需要强制让awk以为字段被修改：如{$1=$1}1。
  • 赋值作条件写法（$1=$1）亦成立，这样awk会重建$0并自动输出。
  • 变量定义可跟在命令末尾，利用“有=的参数视为变量赋值”。

• 构造分隔字符串（如连接、转置矩阵）时常用“哨兵”变量法：

  • 如：string = string sep somedata; sep=";"，第一次sep为空，后续补分号。
  • 转置矩阵时一行为for(i=1;i<=NF;i++) r[i]=r[i] sep $i; sep=FS，在END时打印r[i]即可。

• 两文件处理惯用法：

  • NR==FNR在读取第一个文件时为真，常与next联用。
    • 第一遍处理file1,如建立a[$0]散列表，用于后续判断。
    • 第二文件处理时，a已被填充，可判定$0 in a等。
  • 常用例子：
    • 求两文件交集：awk 'NR==FNR{a[$0];next} $0 in a' file1 file2
    • file1独有行：awk 'NR==FNR{a[$0];next} !($0 in a)' file2 file1（注意参数顺序）
    • 利用map文件转换替换内容：awk 'NR==FNR{a[$1]=$2;next}{$3=a[$3]}1' map.txt data.txt
    • 同文件的两遍处理（如最大值差分）：awk 'NR==FNR{if($0>max)max=$0;next}{$0=max-$0}1' file.txt file.txt

• 注意：

  • 两文件惯用法在第一个文件为空时行为异常，应NR==FNR再加FILENAME等进一步判定。
  • 许多awk惯用法依赖默认动作、变量行为、赋值当条件等特性，熟悉它们可写出更短小、语义清晰的awk脚本。

EE 364B LaTeX 风格指南概要

1. 写作与排版风格

• 英语写作：严格遵循语法、用词、标点、拼写与表达，参考经典写作指南如 Strunk and White [SW57]。
• 以读者为中心：明确读者水平，确保内容流畅、易于跳过复杂公式，注重解释和衔接，不堆砌公式。
• 精确定义：避免模糊用语，若结果非唯一则用“a solution”，避免用“solving an expression”等语句。
• 避免被动语态：合理使用编辑性“we”，但不滥用，句子应简洁明了。
• 公式标点和排版：
  • 公式属于语句的一部分，需在合适位置添加标点。
  • 不以符号开头书写句子。
  • 用文字分隔不同公式元素，避免视觉和语义混淆。
  • 仅对重要且被引用的公式编号，使用 \label 和 \ref 引用，不用具体数字。
• 引用规范：
  • 外部引用用 BibTeX，保持源文件正确。
  • 强制大写用花括号，页面范围使用 en dash。
• 数学模式下排版：
  • 数学符号用 math mode，英文下标或上标非斜体（如 fbest），单字母除外。
  • 特殊函数用专用命令如 sin(x)、log(x)。
  • 空行用于结束段落，公式与文本间无多余空行，公式内缩进可选但对源码可读性有益。
• 符号与术语应用：
  • 同一内容用统一符号，不同内容不同符号，特别是索引符号。
  • 所有符号须在首次出现时定义，必要时可后置定义并指出。
  • 采用常规命名：大写表示集合，希腊字母表对偶变量等。
  • 记号要具备记忆性（如 xc 表示中心点）。
  • 避免过度使用下标，特别是集合元素命名。
  • 不用 ∀、∃、⇒ 等逻辑符号，使用对应英文。
  • 不要将符号赋给不需反复引用的概念。
• 文章结构：
  • 使用 section、subsection 等结构，避免手动换行或分页，标题首字母和专有名词大写。
• LaTeX 专用命令：
  • 规范表示如 ‖x‖、{x ∈ ℝ | x ≥ 0}，用 \left 和 \right 包裹高表达式。
  • 省略号上下点视环境选择 \ldots 或 \cdots。
  • 标准数学对象按课程约定书写（如 ℝ 表实数），用 \argmin、\argmax。
• 优化问题写法：
  • 明确变量和数据定义，区分问题、算法、最优值，不用“问题收敛”等表述。
• 标点与引用：
  • 指定句号是否为句子结束期，逗号位置随数学环境调整。
  • 图、表均须有说明，用 label 引用。
• 图中数学符号：
  • 图形中数学符号优先用 LaTeX 排版（如 matplotlib 支持），eps 格式配合 psfrag 包。
• 术语与领域差异：
  • 避免领域专有术语，若使用需定义；变量、矩阵采用标准符号，除非必要。

2. 源码示例

• 展示如何在文档中插入代码（如 Matlab/Octave 代码），建议代码段适量独立展示，提高可读性。
• 极短代码可用 quote 环境包裹。

3. 报告内容结构建议

1. 开头简述背景及问题，吸引读者。
2. 迅速转至数学问题表述，适于一般数学读者理解。
3. 描述总体方法，不混淆问题定义与求解方法。
4. 讨论方法性质（如收敛性、实现细节、用到的机/软件）。
5. 数值实验报告，详细说明数据、参数及相关指标，与基线方法对比。
6. 若有领域背景，注意解读数学结果对应领域意义。
7. 最后总结高层次要点。

参考文献

• 引用课程中大量经典教材与论文，涵盖凸优化、算法、信息论、统计学习、数学写作、计算机程序设计及数学分析等。

WiFi4EU倡议与免费公共Wi-Fi应用摘要

WiFi4EU倡议概述

• 目标：在欧洲公共空间（如公园、广场、公共建筑、图书馆、健康中心、博物馆）提供免费Wi-Fi。
• 规模：已部署超过93,000个热点，由超过7,200个获得代金券的市政当局运营。
• 背景：倡议由欧盟委员会推动，旨在促进数字包容和连接性。

WiFi4EU应用功能

• 主要用途：帮助用户轻松定位并连接到免费WiFi4EU热点。
• 地图界面：使用直观地图快速显示附近热点，支持搜索市政当局或缩放导航。
• 连接方式：在热点位置，连接到统一SSID "WiFi4EU"。
• 兼容性：支持iOS和Android设备。

应用优势

• 免费与无广告：应用完全免费下载和使用，无广告干扰。
• 隐私保护：不跟踪或收集个人数据，确保用户隐私安全。
• 广泛覆盖：连接欧盟境内超过93,000个热点，涵盖大城市和小村庄。

常见问题解答要点

• 费用：应用免费，连接热点无成本。
• 安全性：数据安全，应用不存储个人信息。
• 信息来源：更多倡议详情可在WiFi4EU网站查看，由HaDEA机构实施。
• 显示问题：地图仅显示获得代金券的市政当局热点；未显示的市政当局可能未参与倡议。

其他信息

• 倡议是欧盟委员会更广泛数字包容努力的一部分。
• 应用可在App Store下载（Google Play和App Store标志为各自所有者的商标）。

该应用旨在简化公共Wi-Fi访问，支持旅行者和本地居民享受无缝网络连接。

首次使用供体细胞的CAR-T疗法使自身免疫疾病患者进入缓解期

核心摘要：一项开创性的临床治疗首次利用来自健康供体的工程化免疫细胞，成功使三名患有严重自身免疫疾病的患者（一名女性和两名男性）的病情进入缓解期。这一突破标志着用于治疗自身免疫疾病的CAR-T细胞疗法向规模化、普及化迈出了关键的第一步。

主要进展与细节：

1. 技术路径革新：

   • 此次治疗使用的是经过生物工程改造和CRISPR基因编辑技术修饰的免疫细胞（CAR-T细胞）。
   • 最关键的区别在于，这些治疗性细胞并非采集自患者本人，而是由健康供体的细胞制备而成。这是全球首例使用异体（供体）CAR-T细胞治疗自身免疫疾病的案例。

2. 临床意义：

   • 这种“现成型”或“通用型”CAR-T疗法具有革命性潜力。与传统的、需要为每位患者单独定制的自体CAR-T疗法相比，使用预先制备的供体细胞可以大幅降低成本、缩短治疗等待时间，并有可能实现大规模生产，从而使更多患者受益。

3. 研究背景与未来展望：

   • CAR-T细胞疗法此前已在某些血液癌症治疗中取得成功，近年来正逐步探索用于治疗严重的自身免疫疾病。
   • 本次成功案例发表于权威期刊《细胞》（Cell），验证了异体CAR-T细胞在自身免疫疾病领域的安全性和有效性。
   • 研究人员指出，这是实现此类疗法大规模制造的“第一步”，但仍需更大规模的临床试验来进一步验证其长期效果与安全性。

总结：这项发表于2024年10月的研究报道，通过使用基因编辑的供体来源CAR-T细胞，成功治疗了三名自身免疫疾病患者，实现了疾病缓解。这一“世界首次”的成功不仅为患者带来了新希望，更重要的是为开发成本更低、可及性更高的“现成型”细胞疗法奠定了基础，是细胞治疗领域迈向工业化应用的重要里程碑。

摘要：地球曾拥有的环系统假说

行星环在太阳系中并不罕见，土星、木星、天王星、海王星以及几颗小型冰行星都拥有环系统。一项发表于《地球与行星科学通讯》的新研究提出，地球在约4.66亿年前的奥陶纪中期可能也曾拥有一个环系统，用以解释当时一系列异常的地质与气候事件。

证据与异常现象：

• 撞击事件激增： 奥陶纪中期，地球上的撞击坑形成速率急剧上升，已发现21个直径数公里至50公里的撞击坑。
• L球粒陨石富集： 该时期沉积岩中与L球粒陨石（一种常见的陨石类型）相关的元素浓度增加了100至1000倍。
• 全球性气候与生态剧变： 撞击事件高峰期间，全球温度下降了约10摄氏度（“赫南特期全球冰室”事件），并伴随地震和海啸活动加剧，导致约85%的海洋物种灭绝。随后温度回升。

环系统假说的提出： 研究团队通过计算机模型“回溯”大陆板块运动，发现已知的撞击坑在数亿年前的实际发生位置均集中于地球的赤道带。计算表明，这种分布随机产生的概率极低（约两千五百万分之一）。为解释这一现象，他们提出：

1. 环的形成： 一颗L球粒陨石母体小行星在极度接近地球时（仅距地表数千公里，近乎掠过大气层），因潮汐力被撕裂（潮汐瓦解），碎片被地球捕获。
2. 环的结构与沉降： 碎片最终沉降在地球赤道平面，形成环系统。环中的尘埃持续降落到地球表面（解释了沉积岩中的元素富集），较大的碎片则偶尔撞击地球，且主要落在赤道附近（解释了撞击坑的分布）。
3. 环对气候的影响： 环产生的阴影会投向冬季所在的半球，产生净冷却效应，并可能被大气中的尘埃放大，从而导致了奥陶纪末期的全球剧烈降温，并可能与大灭绝相关。当环系统消散后，温度回升。

更广泛的启示： 研究人员指出，如果地球经历过一次环系统阶段，那么它很可能经历过多次。其他岩石行星也可能有类似历史。行星环阶段通常持续数百万年，可能对行星的地质、气候乃至生命演化产生重大影响。目前，该团队正在寻找更多证据，以探寻地球过去是否经历过其他环系统阶段。

文章核心总结

本文通过一个虚构但基于真实经历的事故故事，探讨了在分布式系统中添加重试机制可能引发的风险及相应的解决方案。

背景与初始问题

在一个拥有800个微服务的出租车应用系统中，开发者Ben为解决因定价服务超时导致的500错误，为订单服务添加了重试逻辑。起初，他采用简单重试循环，但在代码审查后，采纳了同事Alex的建议，引入指数退避 和抖动 以预防重试风暴和客户端同步问题。模拟测试验证了该方案的有效性，相关重试逻辑也被抽取为公共库，初期问题得以解决。

事故与根本原因分析

三年后，一次订单服务的新版本发布引发了长达一小时的全站故障。根本原因是Redis超时导致的段错误。然而，恢复时间异常漫长 的关键原因被忽略了。

• 负载放大现象：监控显示，在恢复期间，订单服务承受了9倍于正常的负载。
• 根本原因：同事John指出，指数退避仅能延迟（而非消除）负载放大。在长时间停机场景下，指数退避会失效，导致大量重试请求集中涌入，形成“元稳定故障状态”。
• 机制解释：同事Jessica阐明，重试会导致系统在触发因素（如故障发布）被移除后，无法立即恢复。恢复时间与涌入服务器的请求量呈非线性增长，形成恶性循环：更多请求 → 更多超时/错误 → 更多重试 → 请求进一步增加。

关键教训与解决方案探讨

本次事故揭示了“遇到瞬时错误就加重试”这一做法的风险。团队随后探讨并评估了多种优化策略：

1. 重试预算：允许重试，但设定上限（如重试请求不超过成功请求的10%）。当服务出现故障时，额外负载受限。
2. 重试电路断路器：当错误率超过阈值时，客户端完全停止重试。
3. 请求电路断路器：当错误率超过阈值时，停止向服务发送所有请求（包括首次请求）。
4. 截止时间传播：客户端设置请求截止时间，服务端超时后可立即终止执行，部分缓解重试放大。

通过模拟对比，团队得出以下结论：

• 重试预算和重试电路断路器均能有效控制负载放大，加速恢复。重试预算在部分故障场景下对客户端可用性更优。
• 指数退避与抖动仍是必要的基础，应与重试预算结合使用。
• 纯粹的请求电路断路器风险较高，可能因局部故障而过度惩罚所有请求。
• 截止时间传播是一种有效的补充手段，能缩短服务端请求队列，但无法完全替代重试预算。

最终方案与结果

基于以上分析，团队最终采纳了重试预算（10%阈值） 作为核心改进方案，并辅以指数退避、抖动、请求电路断路器和截止时间传播等机制。实施后，在后续一年的其他事故中，未再观察到由重试引发的负载放大问题。

核心启示：重试机制是一把双刃剑。设计时必须考虑系统在故障及恢复阶段的整体行为，单纯依赖指数退避是不够的，需要引入如重试预算等反馈控制机制来约束重试负载，从而确保系统的稳定恢复能力。

Gokapi：轻量级自托管的 Firefox Send 替代方案

Gokapi 是一个用 Go 语言编写的现代、自托管的文件共享解决方案，可作为 Firefox Send 的替代品。它旨在让用户完全掌控文件共享过程，并集成了强大的功能。

核心特性

• 过期文件分享：文件可在设定的下载次数或天数后自动删除。
• 用户与权限管理：支持基于角色的细粒度权限控制，仅注册用户可上传文件。
• 文件请求功能：生成可分享的URL，允许外部用户上传文件，这些文件仅对URL创建者可见。
• 文件去重：相同的文件不会占用额外的存储空间。
• 云存储支持：可选支持 AWS S3 或兼容S3的服务（如 Backblaze B2）。
• 内置加密：支持端到端加密上传。
• OpenID Connect 集成：可与 Authelia 或 Keycloak 等身份提供商对接。
• REST API：便于自动化和集成到其他系统。
• 可定制界面：支持通过自定义 CSS 和 JavaScript 调整外观。

部署与使用

Gokapi 支持多种运行环境：

• 裸金属部署：适用于 Linux、macOS 和 Windows 系统。
• Docker 部署：提供快速部署方案。

用户可以通过 Docker 命令快速启动一个实例：

docker run --rm \
  --name gokapi \
  -v gokapi-data:/app/data \
  -v gokapi-config:/app/config \
  -p 127.0.0.1:53842:53842 \
  -e TZ=UTC \
  docker.io/f0rc3/gokapi:latest

随后访问 http://localhost:53842/setup 并按照设置向导操作即可。

系统要求

• 最低要求：1核 CPU，256 MB 内存，100 MB 可用存储（加文件存储空间），支持 Linux/macOS/Windows。
• 推荐配置：2核及以上 CPU，512 MB 或更多内存，强烈建议使用 SSD 存储。

开发与构建

项目支持从源代码构建。开发者可以克隆仓库后使用 make build 进行构建，使用 make test 运行测试，或使用提供的 Dockerfile 构建本地镜像。

许可证与致谢

该项目采用 AGPL3 许可证。项目感谢所有贡献者，并欢迎通过代码贡献、问题报告或财务捐赠的方式进行支持。

“foo”和“bar”在代码示例中的使用历史

“foo”和“bar”作为元语法变量的流行化主要归功于麻省理工学院（MIT）和数字设备公司（DEC）。最早的引用见于1964年及以后的LISP、PDP-1和Project MAC相关工作中。

起源与早期记录

• 技术圈内的首次记录：1959年MIT科技模型铁路俱乐部（TMRC）的《TMRC语言词典》中，“foo”被定义为“神圣的音节”，仅用于灵感迸发时与神交流。其使用早于1958年俱乐部成员Pete Samson加入之时。
• MIT学生出版物中的更早记录：
  • 1937年：MIT报纸《The Tech》的读者来信中提及虚构的“Phi Omicron Omicron”兄弟会（常被称为“Foo”）。
  • 1938年：同份报纸的文章讨论了“Foo-ism”现象，并引用了课堂黑板上出现“FOO”字样的轶事。
• 变体“baz”的来源：据TMRC成员回忆，其灵感来源于《Pogo》漫画中角色Albert the Alligator的喊叫“Bazz Fazz!”或“Rowrbazzle!”。

流行文化与可能影响

• “foo”和“bar”（乃至“baz”）在20世纪早期的流行文化（如《Smokey Stover》和《Pogo》漫画）中广为人知，TMRC成员很可能接触过这些作品。
• 军事术语FUBAR（“Fouled Up Beyond All Recognition”或其更粗俗的变体）也可能促进了这些词的流行。

在代码中的早期使用

• 1963年/1964年：在MIT Project MAC的LISP相关文档中，“foo”作为示例变量名出现（如1963年6月编写、1964年2月发布的《Programming Language LISP》）。
• “foo”与“bar”同时出现：最早的记录之一是1966年MIT Project MAC的AIM-098号报告（《PDP-6 LISP》），其中包含示例 (EXPLODE (QUOTE FOO/ BAR))。
• DEC公司的角色：有证言指出，早在1966年加入DEC时，“foobar”就已被普遍用作临时文件名。DEC系统手册在1960年代和1970年代初可能传播了“foobar”。PDP-6系统支持六字符文件名，这可能促使“fubar”演变为“foobar”。

回忆与佐证

• 个人回忆：多位早期计算领域的从业者（包括PDP-1程序员）回忆称，他们在1960年代初或中期已在MIT或DEC环境中使用“foo”、“bar”和“foobar”。
• 其他早期引用：
  • 1964年：IBM 7070汇编语言中使用“FOO”和“BAR”作为变量名。
  • 1965年：MIT《Tech Engineering News》中出现“foo”。
  • 1971年：UCLA-NMC的RFC 269文档中使用了“FOO BAR”。
  • 1970年代早期：DEC手册和人工智能相关文献中多次出现。

结论

“foo”和“bar”作为代码示例中的占位符变量名，其历史根源可追溯至MIT的校园文化（特别是TMRC）和早期计算实践，并通过DEC等公司的使用得以在编程社区中广泛传播。其流行是流行文化、军事俚语和技术社区内部传统共同作用的结果。

路由器安全摘要

本文全面介绍了路由器安全的重要性、配置方法及长期维护策略，旨在帮助用户保护网络免受威胁。

一、为何关注路由器安全

路由器是家庭网络的核心，一旦被入侵或感染恶意软件，用户很难察觉，且没有专门的防病毒软件。近年来大量路由器漏洞影响了数百万设备，因此提升路由器安全至关重要。

二、安全配置要点

文章提供了简短和详细两级配置建议：

简短清单（快速提升安全）

1. 更改默认密码：包括路由器管理密码和Wi-Fi密码，使用强密码（至少16字符）。
2. 更改默认网络名称（SSID）：避免透露个人信息。
3. 使用强加密：选择WPA2（配合AES）或WPA3。
4. 关闭高危功能：WPS和UPnP。
5. 启用并保护访客网络：用于隔离访客和物联网设备。
6. 确认远程管理已关闭。
7. 检查并禁用端口转发：除非绝对必要。
8. 考虑关闭IPv6（除非必需）。
9. 定期检查固件更新：当设备长期无更新时，应考虑更换。

详细清单（深入加固）

1. 网络隔离：使用访客网络，并进阶使用VLAN对设备进行分组隔离，防止一台设备被攻破后波及其他设备。
2. 远程管理：彻底禁用通过云服务或移动App的远程访问。如需远程管理，应严格限制来源IP并使用HTTPS。
3. 关闭未用功能：如SNMP、Telnet等，以减少攻击面。
4. DNS安全：
   • 选择可靠的DNS提供商：避免使用ISP默认DNS，可选择提供隐私和恶意软件过滤的服务。
   • 使用加密DNS协议：如DoH或DoT，防止ISP窥探。
5. 无线安全细节：启用管理帧保护（针对WPA2），并考虑降低发射功率以减少信号外泄。
6. 配置备份：完成设置后备份配置文件，便于恢复。
7. 物理安全：防止他人物理接触并重置路由器。

三、长期维护与防御

1. 定期更新固件：路由器停止提供更新（EOL）后，应计划更换。
2. 定期重启：有助于清除可能存在的非持久性恶意软件。
3. 监控连接设备：定期检查路由器管理界面中的已连接设备列表，识别未知设备。
4. 验证DNS设置：通过第三方网站定期检查路由器的DNS服务器是否被篡改。
5. 检查日志：如路由器支持，定期查看日志以发现异常活动。

四、怀疑被入侵时的措施

• 检查迹象：异常的CPU或带宽占用。
• 立即行动：
  • 重启路由器（拔电源更佳）。
  • 如果曾备份配置，可恢复出厂设置后导入备份。
  • 更改路由器及Wi-Fi密码。
  • 最坏情况是固件被感染，需从制造商官网下载固件，通过另一台路由器连接后刷新。

五、选择安全的路由器

• 避免：运营商提供的路由器和大多数普通消费级路由器。
• 推荐：考虑更注重安全性和功能的专业路由器品牌（如文中推荐的Peplink）。

宾夕法尼亚大学沃顿商学院教授伊森·莫利克（Ethan Mollick）在其新书《协同智能：与人工智能共处共工》中，探讨了如何有效利用人工智能。他本人虽日常使用AI工具，但强调应避免将其作为“拐杖”，而是作为增强人类能力的“协同智能”。

核心观点：避免依赖，注重协同

• 莫利克明确指出，将AI当作拐杖会导致学习缺失，因为它阻碍思考。学生若如此使用将一无所获。
• 他建议所有人投入至少10小时，将AI应用于所有任务，以真正理解并善用这些系统。
• 使用AI应是有策略的，设定哪些事务不应让渡给AI，主动管理其影响，避免重蹈社交媒体带来不良社会调整的覆辙。

对AI与教育的启示

• 莫利克支持AI驱动的个性化辅导，认为这是教育变革的一部分。
• 他批评传统授课模式，倡导主动学习课堂，让学生参与解决问题，并利用AI辅导填补知识缺口。
• 当前教育的“作业危机”提供了一个重新思考学习方式的机会。

社会调整与误解澄清

• 莫利克对比了互联网与社交媒体的历程，认为社会需要更审慎地适应AI这一通用技术，因为其影响将深刻而广泛。
• 他澄清了人们对AI的主要误解：一是认为AI缺乏原创性，他指出AI能基于训练创建新内容；二是将AI与谷歌简单对比，他认为AI在谷歌擅长的方面可能较弱，但在其他更多方面表现更佳。
• 对于AI可能让人更懒惰的担忧，他类比计算器，认为关键在于有策略地利用技术捷径，同时保留必要的人类技能（如手动笔记）。

未来展望

• 莫利克认为，未来的顶尖专家将是善用AI者。尽管AI技术令人不安，甚至对某些职业构成威胁，但它目前并不会取代专业人士，需要理性看待硅谷的鼓吹。
• 他提到OpenAI的新模型（如ChatGPT-o1）开始展现自主性和AI代理的雏形，这可能改变工作方式。但他指出，当前模型缺乏在遇到问题时主动提问的交互性，而有价值的互动往往需要这种来回对话。

个人使用与隐私

• 在组织中，人们不愿公开使用AI，一方面是担心被认为不够聪明，另一方面是怕暴露岗位冗余或增加工作量。
• 莫利克强调，关于AI如何应用，并非仅由政府或企业决定，个人和集体也需做出选择，尤其是在涉及道德、伦理和价值观的“唯我任务”（如育儿）中，应保留人类的决策权。

Starmoon 开源实时AI可穿戴设备总结

项目状态

注意：该项目已被弃用。 Starmoon 已不再积极维护。其后续开发工作已转移至 ElatoAI 项目，该项目在WiFi和双向语音AI音频可靠性、全球可用性及生产就绪架构方面有所改进。

项目简介

Starmoon 是一个完全开源、紧凑型的对话式AI设备，用户可以与自定义的AI角色进行交谈。它旨在以低成本实现，便于携带，并提供情感支持与个性化学习辅助。

核心特点

• 成本效益高：使用廉价、现成的组件自行组装。
• 语音情感智能：能实时理解并分析对话中透露的情绪，做出富有同理心的回应。
• 完全开源：支持本地部署和自托管，确保用户数据隐私。
• 设备紧凑：体积仅略大于苹果手表，方便随身携带。
• 减少屏幕使用：作为一种屏幕外的AI伴侣方案，旨在让用户眼睛得到休息。

硬件要求

需要以下组件自行组装（成本受地区税费和运费影响）：

• 主控板：Seeed Studio Xiao ESP32S3 或其他ESP32-S3开发板。
• 音频输入：INMP441麦克风。
• 音频输出：MAX98357A放大器 + 3525微型扬声器（或兼容型号）。
• 交互部件：RGB LED灯、按钮。
• 结构与工具：PCB原型板或定制PCB、3D打印外壳、28AWG电线、焊接工具套件及助焊剂。

软件与设置流程

软件前提：需使用VSCode及PlatformIO插件进行固件烧录，并拥有Starmoon API密钥。

设置步骤：

1. 获取代码：克隆项目仓库。
2. 硬件配置：
   • 根据使用的具体ESP32-S3板型号（如Seeed Studio XIAO ESP32S3或普通ESP32-S3），按照提供的引脚图连接组件。
   • 若使用普通ESP32-S3芯片，需在配置文件和PlatformIO设置中启用对应选项。
3. 固件烧录：
   • 在VSCode中打开PlatformIO，选择项目固件文件夹。
   • 编译并上传固件到设备。
4. 设备使用：
   • 开机，待LED亮起。
   • 用移动设备连接设备发出的“Starmoon-xxx” WiFi网络（仅支持2.4GHz）。
   • 按照网页指引设置互联网连接，并输入Starmoon API密钥和邮箱完成配置。

开源许可

该项目采用 GPL-3.0 许可证。

本地开发是高效软件开发的关键，能够实现更快的迭代、更好的调试，并确保本地与生产环境之间的一致性。

良好的开发者体验（DX）能够提高生产力、减少认知负担并提升开发者的满意度，从而带来更高的代码质量、更快的新人上手速度以及更好的人才保留率。一个易于使用的本地开发环境可能是实现良好DX的基础。文章引用了George Hotz关于Twitter的一个观点：无法在本地运行Twitter，而Facebook的整个系统都可以在一台笔记本电脑上运行，这种在特定数据中心配置外无法运行的特性使得在Twitter上构建新功能变得极其困难。这凸显了本地开发环境的重要性。

开发者体验的重要性似乎与项目参与人数相关。对于独立开发者而言，搭建一个定制的环境相对简单，因为配置仅由个人掌握。作者在博士期间的研究中大部分时间也是独立开发者，这可能使得其此前忽略了开发者体验（除了自己的体验）。人们通常会在添加新工具或功能时考虑技术债务，但文章认为“开发者体验债务”（DX-debt）的概念同样重要，却未得到充分讨论。

如今，诸如Draft、Skaffold、Tilt或Garden等工具使得在本地启动整个集群或提供伪本地开发环境变得更加容易。提供优质开发者体验从未如此简单。