Chromecast历史回顾与产品线更新

核心公告

谷歌宣布停止生产Chromecast，设备将在售完即止。此举标志着智能电视流媒体设备类别将进入由人工智能、娱乐和智能家居驱动的新时代。谷歌承诺对现有最新Chromecast设备继续提供软件和安全更新支持。新产品Google TV Streamer被定位为更高端的继任者，旨在整合娱乐与智能家居中心功能。

Chromecast的历史意义

Chromecast解决了2013年前流媒体电视应用稀缺、连接复杂、体验不可靠的问题。它提供了一种简单、经济的方式，将手机、平板或笔记本电脑上的在线内容投射到电视上。其小巧的外形（可隐藏在电视后）和亲民的价格使其迅速普及，并售出超过1亿台。其背后的核心技术——Google Cast，已被广泛嵌入包括Android TV在内的数百万台设备中。

Chromecast产品发展里程碑

• 2013年：初代Chromecast发布。它是一个可插入电视HDMI端口的小型便携棒，允许用户通过手机等设备无线投射应用内容（如YouTube）。
• 2015年：第二代Chromecast采用新设计（圆形糯狗），增加颜色选项（黄、红、黑），磁性背板和HDMI插头使其更易隐藏和安装。同年推出Chromecast Audio，可将任何传统音箱变为流媒体音频系统，支持3.5mm音频输出。
• 2016年：Chromecast Ultra发布。它是首款支持4K流媒体和以太网端口（确保稳定连接）的Chromecast设备，并首次支持杜比视界。
• 2018年：第三代Chromecast性能提升，播放更流畅，速度比前代快15%。新增对**杜比数字+**的支持，并与Nest智能音箱深度集成，支持“Hey Google”语音控制电视。
• 2020年：搭载Google TV的Chromecast（4K版）发布。它整合了所有娱乐内容，提供个性化推荐、个人片单和跨应用语音搜索功能，并首次引入了备受期待的实体语音遥控器。
• 2022年：推出搭载Google TV的Chromecast（HD版），主打高性价比，以1080p分辨率让更多用户体验Google TV系统，支持超过1万个应用。

X公司关闭旧金山总部并迁至南湾

搬迁决定与安排

• X公司（原Twitter）正式宣布将在未来几周内关闭其位于旧金山的总部办公室。
• 首席执行官琳达·雅卡里诺在内部邮件中确认，旧金山员工将被迁移至南湾地区。
• 工程团队将迁至帕洛阿尔托，与埃隆·马斯克旗下的另一家公司xAI共享办公空间。
• 其他员工将安排至圣何塞桑塔纳罗的现有办公室。
• 公司表示正在制定搬迁计划，包括为受影响员工提供交通方案，但未明确是否提供班车或通勤福利。

历史背景与税收优惠

• 旧金山曾于2011年推出税收减免政策，以吸引科技公司入驻陷入困境的中市场区。
• 该政策为符合条件的企业提供长达六年的1.5%工资税暂停优惠。
• X公司的前身Twitter成为该政策的代表企业，其入驻被视为带动地区商业发展的关键。
• 政策在2014年的评估中被视作成功，带动了区域商业增长和税收收入。

当前办公空间使用状况

• X公司位于1355 Market Street的总部拥有约80万平方英尺的办公空间，租约分别于2026年和2028年到期。
• 经历多轮裁员后，该总部超过一半的空间处于闲置或未使用状态。
• 公司上月已开始为该办公空间寻找转租方。

其他相关信息

• 埃隆·马斯克于2022年底收购Twitter后，要求本地员工全面返回办公室办公。
• 马斯克此前曾在社交平台宣布，因对加州跨性别者保护法案不满，计划将公司迁至德克萨斯州奥斯汀。
• 本次搬迁邮件未提及向奥斯汀迁移的计划。
• 自2019年税收优惠到期及远程办公普及后，该地区的早期乐观发展前景已逐渐消退。

本文是作者在癌症晚期的哥哥杰克离世前，前往亚利桑那州探望的经历与感怀。主要内容如下：

背景与现状

• 作者得知哥哥杰克因癌症将不久于人世，遂前往亚利桑那州探望。
• 杰克的妻子贝丝怀孕七个月，无力独自处理后事（计划火葬，并在纽约圣路易斯公园举行纪念活动）。
• 作者需为哥哥寻找殡仪馆，但过程冰冷而商业化，使其在悲伤中更感无助。

兄弟关系的转变

• 作者与杰克曾因缺乏情感成熟而长期疏离，作者沉溺于自我毁灭的生活方式，杰克则退隐于写作与阅读。
• 近两年，两人通过迷幻药探索自我与世界，并共同发现对烹饪的热爱（常用现代厨具和特殊香料），关系逐渐和解。

疾病带来的冲击

• 杰克病重至无法正常进食，仅靠管饲维持；家中食物匮乏，作者为贝丝采购补给。
• 杰克仍保留大量专业厨具和稀有香料（如埃及葫芦巴、尼日利亚发酵豆），但因身体状况无法烹饪异国料理。
• 作者为杰克做了简单菜肴（夏卡苏卡），却发现盐罐已空——这象征着杰克再也无法烹饪，盐作为基础调味品的消失隐喻生命的终结。

对生命与治愈的思考

• 作者强调每个人都需找到应对现实的方式（如迷幻药、心理治疗等），改变生活需主动行动。
• 文末再次呼应标题：盐的耗尽即代表杰克的离去，作者计划补充盐分为贝丝准备食物，以延续对哥哥的纪念。

情感核心

• 文章通过盐这一日常细节，刻画临终前兄弟间的温情与哀伤，展现烹饪作为情感联结与生命意义的象征。

三星与iFixit合作失败始末

两次失败的合作尝试

iFixit首席执行官Kyle Wiens回顾了与三星两次失败的合作经历。

第一次：Galaxy Upcycling计划（2017年）

• iFixit在创客大会上遇到三星C-Lab团队，该团队提出将闲置旧三星手机通过软件重置，转变为其他设备（如Ubuntu电脑、复古游戏机等）。
• Wiens非常支持这个理念，双方合作在三星开发者大会上高调宣布"Galaxy Upcycling"计划。
• 计划在发布后突然被三星无故搁置，团队失联，原因至今不明。Wiens推测可能是三星高层担心这会便于用户删除三星专有软件，引发公关问题或助长自定义ROM社区。

第二次：DIY维修合作伙伴关系（2022-2024年）

• 2022年初，三星主动联系iFixit，希望开展官方维修零件合作。
• 尽管有之前不愉快的经历，Wiens考虑到三星设备维修的巨大需求，决定再次合作。
• 合作于2022年5月正式宣布，但很快出现问题：
  • 零件限制：三星对维修店设定了极低的季度购买上限（7件），远不能满足实际维修需求。
  • 定价过高：三星零件价格显著高于其他品牌（如谷歌），且原因不明。
  • 捆绑销售：屏幕和电池等零件必须捆绑购买，即使只需更换其中一项，增加了不必要的成本。
  • 谈判僵局：iFixit提出多种改进方案均被三星拒绝，合作陷入停滞。
• 2024年5月，iFixit宣布终止合作，停止销售三星官方零件和共同制作维修指南。

三星手机维修的核心难题

Wiens指出三星手机长期以来维修性得分较低，主要原因包括：

1. 机械设计复杂：需要大量热量才能打开机身；屏幕和电池粘合在一起，难以单独更换；屏幕位于最内层，拆解步骤繁琐。
2. 与苹果设计对比：尽管苹果有"零件配对"等软件限制，但其近年机型的机械设计（如可从前后两侧打开）更便于维修。
3. 缺乏改进：三星手机的基本维修设计近十年变化不大，尽管这能降低其自身保修成本。
4. 政策矛盾：三星提供长达7年的软件支持，但硬件维修的困难和高成本却阻碍了设备长期使用，这与其宣传的环保理念相悖。

欧盟新规的影响与未来展望

• 欧盟未来要求智能手机必须易于维修，特别是电池需易于更换。Wiens指出当前三星设计不符合要求，期待其能超越基本标准进行创新。
• Wiens认为三星拥有顶尖的设计和工程能力，完全可以做出更易维修的手机（如Fairphone 5获得满分维修性评分），关键在于是否将其作为优先事项。

iFixit的立场与未来

• Wiens对两次合作失败感到失望，但并未完全排除未来与三星再次合作的可能。
• 前提是三星必须真正承诺延长产品使用寿命，并实质性支持独立维修生态系统。
• iFixit将继续致力于帮助用户修复设备，践行"永不接受损坏为答案"的使命，即使此次不得不向现实妥协。

摘要

本文主要探讨了使用窄带三色（RGB）光源扫描彩色负片（C-41）的优势，并对比了宽带（白光）光源的不足。核心观点是：RGB光源能更准确地还原胶片染料层的信息，产生高质量扫描结果，且无需复杂后期处理。

主要优势与原因

• 染料吸收特性：C-41胶片使用青、品红和黄色染料存储图像，这些染料吸收特定波长光谱（如黄染料吸收400-550nm光）。白光光源的宽光谱会导致波长重叠（例如580-620nm光仅被染料轻微吸收），干扰数字相机传感器的色彩通道。
• 传感器重叠问题：数字相机传感器的色彩通道（红、绿、蓝）存在光谱重叠（如580-600nm光同时被红和绿通道感知），加上胶片的橙色遮罩（由黄和品红正像组成），白光扫描会混入无用信息，降低动态范围和颜色精度。
• RGB光源优化：窄带RGB光源（理想波长：红>650nm，绿520-550nm，蓝<450nm）匹配染料吸收峰值，减少重叠，使反转过程简单化（直接反转颜色通道并调整白平衡），无需专用软件。

与白光扫描的对比

• 白光扫描需要专用软件进行复杂校正，且结果颜色无法通过后期调整完全匹配RGB扫描效果，因为光与胶片的相互作用本质不同。
• RGB扫描能最大化动态范围、最小化串扰，提供更接近专业扫描仪（如Fuji Frontier SP3000）的输出，并保留不同胶片的固有风格（如Kodak Ektar 100或Fuji 200的特性）。

LED选择与替代方案

• 理想LED波长：红>650nm，绿520-550nm，蓝<450nm，但商业产品较少，需自制光源。
• 实用替代：通用RGB LED（红620-630nm，蓝460-480nm）虽非最优，但仍显著优于白光。可搭配扩散材料均匀照明。
• 其他光源：OLED显示器优于白光但光谱较宽；LCD显示器效果取决于背光技术；白光仅适用于正片（幻灯片）扫描，因正片设计为宽带光观看。

扫描工作流程（RGB光源下）

1. 扫描：以RAW格式拍摄，固定白平衡和曝光，避免通道裁剪。
2. 导入：使用线性RAW配置文件，在软件中进行镜头校正和平场校正。
3. 最小密度平衡：中和未曝光区域颜色（通过白平衡或通道调整）。
4. 反转：使用色阶或曲线工具反转黑白点，设置亮度曲线。
5. 微调：应用相同调整到整卷胶片，手动优化黑白点和颜色平衡。

硬件与许可

• 作者设计了自定义RGB光源（如scanlight v4和big scanlight），设计文件发布于GitHub。
• PCB和3D文件采用CERN-OHL-W V2许可，软件和文本使用MIT许可，需授权使用文章内容。

示例对比

文章提供了多组扫描样本（如Kodak Ektar 100、Fuji 200），显示RGB光源在颜色还原、动态范围和细节上均优于白光扫描，且后期处理更少。

总之，RGB光源通过精准匹配胶片染料特性，简化了扫描流程，提升了输出质量，是数字化彩色负片的理想选择。

rqlite 9.0：通过“引用式快照”设计将磁盘使用量减半

rqlite 是一个基于 Raft 共识协议、使用 SQLite 作为存储引擎的轻量级开源分布式关系数据库。其 9.0 版本开发的核心目标是通过一次高层设计重构，将磁盘使用量减少约 50%。

当前磁盘使用量的主要来源 目前，rqlite 的磁盘空间消耗主要由三部分驱动：

1. Raft 日志：记录系统变更的日志，是 Raft 共识系统的核心。
2. 工作 SQLite 数据库：用于处理读写请求的活动数据库。成功提交到 Raft 日志的 SQL 语句会应用于此数据库。
3. 工作 SQLite 数据库的快照：为防止 Raft 日志无限增长，系统会定期生成工作数据库的时点副本（即快照）。获得快照后，可以截断 Raft 日志。此快照用于节点重启时的状态恢复，或在集群中节点追赶状态时传输。快照和日志截断是基于 Raft 系统的核心概念。

rqlite 9.0 的高层设计策略 减少磁盘使用量的核心策略是移除在 Raft 系统中存储工作数据库快照副本的需求。虽然 Raft 日志通过快照机制会被定期截断而停止增长，但工作 SQLite 数据库会随数据写入持续增长。由于快照副本的大小与工作数据库大致相同，它也会随之增长。因此，如果能消除快照副本，rqlite 的磁盘使用量将减少 50%。

然而，rqlite 节点在某些时刻仍需要快照副本。解决方案的关键在于 rqlite 的底层 SQLite 数据库运行在预写日志（WAL）模式下。在 9.0 的新设计中，工作 SQLite 数据库文件（不包括其关联的 WAL 文件）与 Raft 系统中存储的快照副本在逻辑上是相同的。利用这一事实，可以消除存储单独快照副本的需要。

新的快照方法：“引用式快照”

1. 快照与 WAL 检查点：在快照时刻，rqlite 将对工作 SQLite 数据库的 WAL 执行检查点操作。随后的所有新写入将导向一个新的 WAL 文件，从而使主 SQLite 文件在快照生成时保持不变。因此，在下次快照之前，主 SQLite 文件就代表了 Raft 快照存储所需的时点状态。这样，主 SQLite 文件结合 WAL 文件用于常规读写，而不变的主 SQLite 文件本身则作为 Raft 快照存储的数据集，无需再创建额外副本。
2. 向快照存储写入引用：rqlite 不再复制整个 SQLite 文件，而是向快照存储写入一个引用（例如校验和）。当需要快照数据时，此引用可用于验证主 SQLite 文件是否与快照存储引用的内容匹配（此检查可防范错误或磁盘损坏，但非严格必需）。
3. 从快照恢复：由于快照后的所有写入都指向 WAL 文件，主 SQLite 文件随时可用于快照恢复过程（例如节点重启或向其他节点传输快照）。换言之，主 SQLite 文件（忽略其关联的 WAL 文件）在逻辑上等同于如果 rqlite 创建了实际副本时所存储的内容。

附带优势 “引用式快照”还将带来几个显著改进：

• 更快的快照过程：只需向快照存储写入极少数据（主要是 WAL 检查点时间与校验和计算时间），无需每次快照时复制大量 SQLite 数据。考虑到 rqlite 在快照期间会阻塞写入，更快的快照过程优势明显。
• 更快的节点重启：即使是包含数 GB SQLite 数据的节点，重启速度也将大幅提升。目前重启时，rqlite 需从 Raft 快照存储中恢复工作数据库文件。新设计下，工作数据库文件在启动时已就位。rqlite 最多只需比较快照存储中的校验和与工作数据库的校验和。多 GB 的系统重启应在几秒内完成。

后续步骤 向 rqlite 9.0 的演进将是优化其效率的重要一步。通过实施“引用式快照”，预期将显著减少磁盘使用量、加快快照速度并改善节点重启时间。开发中还需完善诸多细节，包括 SQLite WAL 管理、从旧版本的无缝升级以及校验和的选择。

调试Illumos上rustc段错误的经验总结

在Oxide公司，我们使用基于Illumos（源自Solaris的Unix操作系统）的Helios作为云计算机的基础OS。Illumos提供了强大的调试工具，作者在同事的帮助下，利用这些工具跟踪了Rust编译器（rustc）的一个段错误（segfault）。本文面向对系统工作感兴趣的技术人员，详细介绍了调试过程。

问题描述

作者在Illumos上克隆了Rust仓库（修订版2d5a628），并尝试构建标准库。运行./x.py check时，rustc在编译cranelift-codegen v0.109.0时崩溃，输出rustc exited with signal: 11 (SIGSEGV)。该错误完全可重现，每次构建都失败。

调试过程

1. 初步定位

• 找到崩溃的rustc版本：通过find命令定位到./build/x86_64-unknown-illumos/stage0/bin/rustc，版本为1.80.0-beta.1。
• 独立复现：创建一个依赖cranelift-codegen的简单Cargo项目，使用rustc 1.80.0构建时也出现同样的段错误，确认问题与Rust工具链相关。

2. 核心文件分析

• 获取核心转储：使用Illumos的coreadm工具管理核心文件。在~/.cargo/registry/src/.../cranelift-codegen-0.109.0/目录下找到核心文件。
• 使用mdb检查：Illumos的模块化调试器（mdb）用于检查核心文件。启用符号反编译（$G）后：
  • 检查寄存器：%rip指向rustc_parse::parser::Parser::parse_path_segment+0x7b，表明崩溃发生在解析器中。
  • 检查调用栈：调用栈有1493行，显示递归解析器导致栈溢出。栈地址从低到高跳跃，表明使用了栈增长机制。

3. 内存和栈分析

• 检查地址空间：使用mdb的whatis命令和pmap工具。栈指针位于4 KiB的未分配内存区域，帧指针位于1028 KiB的读写区域。崩溃发生在尝试访问4 KiB的防护页时，导致段错误。
• 栈大小问题：Illumos上默认线程栈大小应为2 MiB，但实际只有1028 KiB。设置RUST_MIN_STACK环境变量无效，表明栈大小可能被覆盖。

4. 深入调查

• 栈增长库stacker：发现rustc使用stacker库来管理递归栈增长。stacker在Illumos上无法检测栈大小（guess_os_stack_limit返回None），因此总是创建新的1 MiB栈段，但这不足以解析大型文件。
• 触发崩溃的文件：通过truss系统调用跟踪（过滤open和openat），发现崩溃发生在解析生成的文件isle_opt.rs（由构建脚本产生）。该文件大且嵌套深，易导致栈溢出。
• 理论总结：栈耗尽是由于stacker无法检测Illumos的栈大小，且rustc解析器调用stacker不够频繁，导致1 MiB栈段不足。

解决方案和绕过方法

• 交叉编译修补的rustc：作者在Linux上使用Rust的CI Docker镜像构建了一个修补的rustc（基于阶段0编译器75ac3b633），用于Illumos上成功构建标准库。
• 禁用可选组件：建议在config.toml中禁用cranelift-codegen（可选组件），以避免崩溃。

经验教训与改进建议

1. rustc需要更频繁调用stacker：解析器部分未充分调用stacker，导致栈溢出。已提交问题rust-lang/rust#128422。
2. stacker在Illumos上需修复：应添加pthread_attr_get_np函数到libc，并更新stacker以检测栈大小。
3. 改进错误报告：stacker和Rust运行时应在栈耗尽时输出清晰信息。相关问题rust-lang/rust#128568和rust-lang/stacker#59。
4. 环境变量控制：stacker段大小应可通过环境变量（如RUST_MIN_STACK）配置。
5. CI支持Illumos：Rust的CI应支持Illumos测试，以提前捕获类似问题。
6. 工具改进：x.py可检测可选组件失败并建议禁用。

结论

这次调试充分利用了Illumos的强大工具（如mdb、truss），并综合分析了核心文件、调用栈和内存映射。问题根源是stacker和rustc解析器的交互缺陷。通过团队合作，作者不仅解决了当前问题，还提出了系统性改进建议，有助于未来避免类似情况。

Polars 重写了其字符串数据类型，以解决性能问题并改进与 Apache Arrow 的互操作性。此前，Polars 使用基于 Arrow2 crate 的默认字符串类型，该类型将字符串数据存储在单个连续缓冲区中，并通过偏移缓冲区索引位置。这种方式虽然紧凑，但过滤和收集操作的时间复杂度与字符串大小线性相关（O(n·k)），导致在处理大字符串数据时效率低下。

去年，Polars fork 了 Arrow2 的部分代码到 polars-arrow，获得了代码控制权。同时，Arrow 规范开始引入类似 Hyper/Umbra 数据库的字符串类型，Polars 采用了这种新设计。新类型将字符串表示为固定 16 字节的“视图”：小字符串（≤12 字节）直接内联存储，包括长度、前缀和剩余数据；大字符串则存储在辅助缓冲区中，视图包含长度、前缀、缓冲区索引和偏移。

这种新设计带来了显著优势：

• 小字符串内联，避免了间接访问开销。
• 过滤、收集等核心操作变为常数时间复杂度（O(n)），独立于字符串长度，大幅提升了性能。
• 大字符串可以被字典编码或缓存，节省空间。
• 固定宽度视图支持更高效的随机访问和内存管理。

缺点包括存储唯一字符串时可能占用更多空间，以及需要垃圾回收来清理未使用的缓冲区。基准测试显示，新类型在各种过滤操作中均优于旧类型，尤其在大字符串场景下，性能提升明显，完全消除了旧类型的瓶颈。

未来，Polars 将继续利用对代码的完全控制，优化内存缓冲区，预期更多性能改进将随之而来。用户只需升级到最新 Polars 版本即可享受这些改进。

Iso20022.js：三行代码创建支付

Iso20022.js 是一个 JavaScript 库，旨在简化与银行系统的交互。它通过标准化的 ISO20022 金融消息格式，允许开发者轻松创建和解析支付指令。

核心功能示例： 库的核心亮点在于其简洁性。例如，创建一笔美国即时支付（RTP）的代码仅需三行核心逻辑：

const payment = checking.createRTPCreditPaymentInitiation([...]);

开发者只需提供货币、金额、债权人信息（名称、账户、代理行路由号）和汇款附言等必要参数，即可生成符合银行规范的支付发起消息。

ISO20022 标准简介： ISO20022 是一套用于向银行发送指令的通用文件格式标准。公司发送“支付发起”消息以执行付款，并接收“现金管理”消息以跟踪余额和交易历史。该库使公司能够创建和解析这些消息，从而构建与银行交互的软件。一个典型的应用是生成 SEPA 支付指令。

主要特点与状态：

• 支持类型： 目前支持创建 RTP（实时支付）信用支付发起。SEPA（单一欧元支付区）和 ACH（自动清算所）等支付类型即将支持。
• 兼容性： 设计为可与全球主流银行系统无缝集成。
• 目的： 为开发者提供一个工具，用于构建能够处理标准化金融消息的支付软件，降低与银行 API 或文件系统对接的复杂度。

X公司将关闭旧金山总部并搬迁员工

核心事件 社交媒体公司X（前Twitter）计划在未来几周内关闭其使用十多年的旧金山总部办公室。CEO Linda Yaccarino在内部邮件中宣布了这一决定，并表示这是出于公司长远发展的正确选择。

搬迁地点与细节

• 实际安置：旧金山的员工将被转移至湾区现有的圣何塞（San Jose）办公室，以及位于帕洛阿尔托（Palo Alto）与XAl共享的新工程办公空间。
• 与马斯克此前言论的差异：马斯克上个月曾公开宣称公司总部将迁至德克萨斯州（其旗下SpaceX、Tesla等公司所在地），但Yaccarino的邮件中并未提及德州，而是明确向湾区的新主要办公地点过渡。

背景与影响

• 对旧金山的影响：此次搬迁对正努力振兴市中心和商业房地产市场的旧金山而言是一次挫折，尤其打击了该市将中市场街（mid-Market Street）地区打造为繁荣科技中心的努力。
• 公司历史与变动：Twitter于2012年将这座占地100万平方英尺的建筑作为全球总部。马斯克收购公司后进行了大规模裁员，关闭了该建筑的多层楼层及全球十几个办公室，拆除了所有Twitter时代的标志，并取消了弹性居家办公政策。此外，马斯克接手后曾因 alleged 拖欠租金被大楼业主起诉，该诉讼已于今年3月被撤销。

员工过渡计划 针对受影响的旧金山员工，公司管理层正在积极制定过渡计划，包括提供交通选项等支持措施。更多详细信息和后续步骤将在未来几周内进行沟通。

好的人生设计遵循一个共同的过程：通过持续观察、迭代与情境互动来“展开”自我。

核心思想： 成功的设计是形式与情境的契合。无论是婚姻、文章还是职业，好的设计不是凭空想象，而是从理解情境中自然生长出来的。

1. 设计过程（“展开”）

• 起点： 关注自己喜欢做的事并多做；让有趣的人容易找到自己并相处。
• 迭代： 持续关注情境，移除挫折感的来源，扩展让自己充满活力的事物。
• 结果： 生活最终会变得与最初想象不同，但完美契合自己。

2. 形式-情境契合

• 设计的成功在于形式是否适配情境（如手套适合手，关系适合双方个性）。
• 形式蕴含于情境之中。要找到好设计，应从情境出发（如从互动中发展关系），而非先定义形式再寻找。
• 情境比个人更聪明、蕴含更细微的信息，应与之合作。

3. “展开”的运作机制 这是一个你与情境之间的反馈循环：

1. 观察情境（如：喜欢什么任务、想和谁共处、市场如何等）。
2. 形成情境心智模型（关于下一步做什么的猜想）。
3. 用此模型决定下一个微小行动（如：邮件咨询、进行小项目、研究他人）。
4. 行动产生新信息，从而更新理解。
5. 重复以上步骤。

4. 如何改进“展开”过程

• 增加从情境获取信息的速率与分辨率：
  • 多对话、多实验（如：向幸福夫妻请教，尝试临时照看孩子）。
  • 减少预设过滤：通过“解耦”抽象概念（如将“职业”解耦为薪水、身份、关系、意义等），更细致地观察情境，发现更多可能性。
  • 克服社会恐惧：不害怕显得愚蠢或不被理解。
  • 避免过早决定方案：保持所有解决方案开放，不因感觉“怪异”或与预设愿景不符而排除选项。
  • 培养抽离心态：当情境否定你的想法时，以“有趣”回应，像科学家一样不强求现实符合期望。
• 提高基于情境行动的速度与精确度：
  • 加速行动与反馈（如：更快地写作、建模、征求意见）。提高速度能降低尝试成本，从而冒更多风险、获取更多信息。
  • 某些领域（如沟通理解）可通过提升技能来加速互动深度。

5. 长期结果 如果坚持这个反馈循环十年，最终将获得一个设计良好的生活。它可能不符合最初的想象，但会与你自然契合。过程中具体的实验和洞察或许会被遗忘，但设计的形式本身会承载这些经验。

维修机器的灵魂：施乐技师、非正式知识与Eureka系统的兴衰

核心发现：修理是门社会技艺

20世纪80年代，施乐复印机复杂多变，其维修技师的实际工作方式与公司管理层的设想大相径庭。人类学家朱利安·奥尔的研究表明，解决机器难题的核心并非遵循手册，而是依赖社会化知识网络。技师们通过共享午餐、持续对话来交流经验，尤其是通过讲述简短、技术密集的“战争故事”来传递诊断复杂故障的关键洞察。这些故事不仅是解决问题的工具，也是在社区内建立专业声誉和身份认同的方式。

维修工作的本质：三角关系中的即兴创作

• 复杂性：如重达一吨半的Xerox 9400，故障模式不断演变，无法仅靠标准流程解决。
• 用户角色：近半数问题由用户误操作引起，因此产生了“修理客户而非机器”的格言。技师需要将客户也纳入他们的“话语社区”。
• 工作方法：诊断是一个创造“连贯叙事”的过程，从零散信息中理出头绪。最有效的学习资源是同行，而非官方那套纯指令性、缺乏解释的维修手册。

Eureka系统：从草根智慧到全球知识库

基于奥尔的研究，施乐帕洛阿尔托研究中心（PARC）开发了Eureka系统，旨在将技师们的局部智慧转化为全球共享的资源。

• 设计哲学：抛弃了失败的AI专家系统思路，转而构建一个“为专家服务的系统”，由技师们生成、验证和评估解决方案提示。
• 关键特征：提示采用“问题-原因-解决方案”格式，通过同行评审确保质量。技师通过贡献优质提示获得同行认可，而非金钱奖励。
• 推广历程：
  • 法国试点（1994）：利用Minitel网络取得成功，服务效率显著提升。
  • 加拿大扩展（1997）：利用现有公告板系统，由“老虎”（资深专家技师）推动，同样证明有效。
  • 美国阻力与全球推行：遭遇总部官僚体系的抵制和不当的推广方式（“喷洒并祈祷”），但凭借技师的口碑最终推广至全球2.5万名技师，实现了10倍的投资回报。

深层启示与未竟的革命

• 实践社区 vs. 实践网络：Eureka创造了一个松散耦合的“实践网络”，但失去了原团队中紧密“实践社区”所蕴含的丰富人际互动和客户情境知识。
• 管理层的误读：尽管Eureka被表彰为知识管理典范，施乐仍始终将客服视为成本中心而非价值中心。技师们的时间和洞察并未获得正式回报，他们的知识也未能系统性地反馈到产品设计或销售策略中。
• 技能与认可：奥尔强调，有效的“实践社区”的核心在于重视并认可高超技能，通过同行间的良性竞争激励 mastery（大师水准）。这是社区保持活力的关键。
• 时代的回响：在社交媒体时代，虚拟实践社区（如汽车爱好者论坛）印证了奥尔的发现：深度互动、同伴认可和具体的“窍门”分享是社区价值的核心。

总结：施乐维修技师的案例深刻揭示了，一线工作者的默会知识、社交网络与即兴能力，是维持复杂技术系统运行的“灵魂”。任何试图用僵化流程和自上而下控制来取代这种有机知识的尝试，都会付出高昂代价。真正的知识管理必须赋能实践者，并正视其工作复杂的社会与技艺本质。

工具概述 Viking 是一个开源、简单的命令行工具，旨在简化远程物理服务器的管理和 SSH 密钥操作。它允许用户高效地与多台远程机器进行交互，实现命令执行、文件传输和密钥管理等功能。

核心功能与命令 该工具通过以下主要命令提供功能：

1. machine: 管理服务器列表。可以添加（add）机器，指定其名称、连接地址（IP/主机名:端口）以及可选的 SSH 密钥。
2. exec: 在已注册的机器上并行执行 Shell 命令。支持通过 --tty 选项交互式连接到单台机器（如进入 bash）。
3. copy (或 cp): 在本地与一台或多台远程机器之间并行复制文件或目录。
4. key: 管理 SSH 密钥。支持从文件添加（add）密钥、生成（generate）新密钥对，以及将公钥复制（copy）到剪贴板以便分发。
5. config: 显示当前配置目录的路径。

技术特性

• 并行操作：在多台机器上执行命令或复制文件时，操作是并行进行的，提高了效率。
• 灵活的连接：添加机器时，可以不指定密钥，此时将使用 SSH 代理进行连接。
• 本地配置：Viking 在本地保存配置数据，用户可以通过设置 VIKING_CONFIG_DIR 环境变量来自定义配置存储目录。
• 跨平台：提供适用于 Unix 和 Windows 系统的安装方法，可从预构建二进制文件或通过 Go 语言安装。

安装与许可 用户可通过发布页面获取预构建二进制文件，或使用 Go 命令在 Unix 和 Windows 环境下安装。该项目采用 MIT 许可证发布。

用Python编写瓦片服务器

本文描述了作者将其现有的、基于Mapnik和OpenStreetMap数据的批量瓦片渲染系统，改造为按需服务的瓦片服务器的过程、挑战及最终采用的非阻塞I/O解决方案。

现有渲染系统的核心特点

作者拥有一套成熟的批量瓦片渲染脚本，具备以下优化：

1. 多进程渲染：支持多进程并行处理，可指定渲染区域、边界框或特定瓦片。
2. 海洋瓦片优化：若检测到海洋元瓦片（例如缩放级别0的子瓦片），则跳过渲染其下属缩放级别更高的子瓦片，因地球表面约75%为水域，此举大幅节省渲染时间。
3. 操作系统缓存优化：假设渲染缩放级别N时所需数据与N+1级别相同，利用操作系统层面的文件/数据缓存（非Mapnik内置），在内存充足时避免重复从磁盘读取数据，提升渲染速度。

作者长期在本地高性能计算机上渲染，然后通过rsync同步至服务器，因其个人电脑性能优于服务器。

构建自定义瓦片服务器的动机

作者未采用现有的renderd等方案，主要基于以下原因：

• 存储方式：renderd存储8x8的元瓦片并从中提供单瓦片，以节省索引节点和减少碎片。而作者需要独立存储每个瓦片，以便于快速增量更新（直接同步单个瓦片文件）和灵活转换（如轻松导出为MBTiles格式用于离线手机地图）。同时，独立瓦片可通过简单的HTTP服务器直接提供服务。
• 已有渲染引擎：作者已拥有成熟的渲染核心，希望在其基础上增加Web前端。

渲染引擎架构与初步Web前端构想

现有的渲染引擎采用“主进程-渲染线程”模型：

• 渲染线程：预先加载庞大的Mapnik样式文件（耗时数秒），长期存在，通过工作队列接收元瓦片渲染请求。
• 主进程：管理一个工作队列（向渲染池下发任务）和一个信息队列（接收渲染完成及子元瓦片信息）。使用栈结构调度任务，以确保相关元瓦片（父子关系）的连续渲染，充分利用缓存。
• 采用“窥探”队列状态（而非阻塞或非阻塞选择）的循环来避免阻塞。

实现Web前端的挑战与框架选型失败

将上述系统转为Web服务需解决：结果计算耗时、渲染库非异步且线程不安全、渲染线程需预热、需管理客户端请求队列并在客户端断开时移除未处理请求。 作者尝试了多种Python Web框架均不理想：

• FastAPI：不支持在响应发送后执行长时间运行的异步任务。
• Flask：非异步，且无法在客户端断开时进行精细控制（如取消任务队列中的特定请求）。
• 其他异步框架（asyncio, aiohttp, tornado）：普遍存在类似问题，难以满足“从全局请求队列中移除特定请求”这一关键需求。
• Twisted：虽可能实现，但基于回调的API预示着“回调地狱”，且作者需深入事件循环集成主进程。

最终方案：自实现非阻塞I/O事件循环

作者最终决定直接使用底层selector API实现一个非阻塞循环，核心流程如下：

1. 创建监听套接字，注册读事件。
2. 接受连接，注册客户端读事件。
3. 当可读时，读取客户端请求，将渲染任务发送给主进程，然后取消注册读事件（防止重复读取）。若读取为空则表示客户端断开。
4. 步进主进程（调度渲染）。
5. 若主进程返回渲染结果，则为相关客户端生成响应并注册写事件。
6. 当可写时，使用sendfile()高效发送瓦片文件，然后关闭连接。
7. 循环继续。

此方案在约200行代码内实现了基本功能，并解决了核心难题：

• 支持长时间渲染：任务队列化，响应异步生成。
• 客户端断开处理：可取消该客户端在请求队列中的待处理任务。
• 资源共享：多个客户端请求同一元瓦片时，可关联到单个渲染任务。
• 性能优化：利用sendfile()实现零拷贝传输。

后续工作与总结

当前实现已扩展至约500行代码，支持多客户端并发查询同一区域。作者计划进一步：

• 集成真实的渲染线程和瓦片保存逻辑。
• 完善空瓦片与未渲染瓦片的检测机制。
• 考虑转向Twisted框架以更健壮地处理短读/写及HTTP/1.1持久连接。 作者对自实现方案的开发速度和效果感到满意，认为其比预期更简单高效。

Slingcode：单一HTML文件中的应用平台

核心概念 Slingcode 是一个完全包含在单一 HTML 文件中的个人计算平台。它允许用户直接在浏览器中创建、运行和分享 Web 应用，无需复杂的开发工具、服务器、托管服务或 SSL 证书。

主要特点

1. 完全离线与便携：应用存储在浏览器本地存储中，无需互联网连接即可运行。该 HTML 文件可保存在网站、U盘、笔记本电脑或手机上。
2. 无需基础设施：消除了对服务器、域名或部署工具的依赖。
3. 应用共享方式：
   • 点对点传输：通过内置的 WebTorrent 技术进行应用共享。
   • 文件交换：可将应用导出为 ZIP 文件，并在另一个 Slingcode 实例中导入。
   • 传统托管：也可将应用上传到常规的 Web 主机进行在线部署。
4. 隐私与控制：用户仅分享自己选择的内容，数据完全由用户控制。
5. 移动端友好：支持手机浏览器“添加到主屏幕”功能，方便随时访问应用库。

设计理念与目标

• 复兴编程乐趣：作者旨在摒弃复杂的现代开发工具链和依赖项，创造一个类似早期个人计算机（如 Apple IIe）的简单、直观的编程环境。
• 教育用途：专门为方便向儿童教学编程而设计，避免了复杂初始设置。
• 注重“情境软件”：借鉴了“小而精、松散连接”的软件开发理念，强调软件应贴合特定用户群体的需求，而非追求规模或通用性。
• 个人计算自主权：致力于恢复个人计算机作为“个人财产”的原始愿景，使用户能完全控制、理解并运行其设备上的软件。

技术实现

• 前端技术：基于 ClojureScript 构建，使用了 CodeMirror（代码编辑器）、React + Reagent（UI 渲染）、jszip（ZIP 文件处理）、WebTorrent（P2P 传输）等库。
• 辅助工具：包含本地存储（localforage）、二维码扫描（zxing）、加密（tweetnacl.js）等功能模块。
• 开发与贡献：项目欢迎参与，开发者需安装 Node 和 Java 环境，并使用 Make 工具进行构建。

背景与致谢

• 项目由 Chris McCormick 创建，灵感来源于对简单、自主个人计算环境的追求。
• 版权归属 Chris McCormick（2020），采用 MIT 许可证分发。
• 开发过程中得到了测试反馈，并依赖于众多开源技术。

华硕Zephyrus G15笔记本CPU液态金属更换指南

问题背景

笔记本电脑（尤其是游戏本）在狭小空间内集成高性能硬件，散热系统至关重要。华硕ROG Zephyrus G15的CPU部分原厂使用了液态金属作为导热界面材料（TIM）。液态金属导热性远优于传统硅脂，但存在导电性和流动性风险，可能因笔记本移动或热胀冷缩导致移位、溢出。

作者使用数年后发现CPU部分核心出现热节流，温度普遍升高，而GPU正常，判断是液态金属发生了泵出效应（因温度循环导致材料从接触面中心向边缘迁移）。

解决方案选择

作者决定不再使用液态金属，而选择霍尼韦尔PTM7950相变材料替代。PTM7950在室温下为固态，便于处理，在笔记本工作温度（约45°C以上）下变为液态，具备良好导热性，且不具备导电性，更安全稳定。

更换步骤概要

1. 准备工具：无尘纸、棉签、异丙醇、螺丝刀套件。
2. 拆机准备：
   • 取下底盖，断开电池连接以防短路。
   • 注意螺丝位置（非全部相同）。
   • 小心穿过散热铜管的无线网卡天线。
3. 拆卸散热模组：
   • 按照散热器上标注的顺序（通常为数字标注），拧下GPU侧3颗固定螺丝和CPU侧4颗螺丝。
   • 小心取下整个散热模组（与风扇分离）。
4. 清洁液态金属：
   • CPU侧：液态金属已明显移位，靠近硅脂屏障边缘。CPU芯片上有残留和染色。
   • 清洁难点：CPU芯片与硅胶屏障之间的液态金属液滴。方法是用纸巾角将其聚拢，再用棉签蘸取吸除。注意避免破坏CPU周围的硅胶屏障和下方元件。
   • 加热器铜板侧：液态金属导致镍镀层反应，用纸巾和异丙醇仔细擦拭。
5. 清洁GPU侧：
   • 使用常规硅脂（非液态金属），用异丙醇溶解并清除。
   • 重要：保留GPU核心周围显存颗粒上的蓝色导热垫（厂商专用），勿更换。
6. 应用新TIM（PTM7950）：
   • 将PTM7950置于冰箱冷冻5-10分钟，使其变硬，便于裁剪和操作。
   • 裁剪合适尺寸，覆盖CPU芯片，移除两面保护膜。
   • 轻放散热模组，确保一次性对准，避免摩擦移位PTM7950。
7. 复原与测试：
   • 按顺序拧回散热器螺丝，重新连接天线和电池，装回底盖。
   • 进行基准测试，确认温度改善。

最终效果

• CPU温度显著下降：不再出现热节流，最高温度从未超过87°C（原厂时常超过90°C）。
• GPU温度改善：比使用原厂干涸硅脂时降低约5°C。
• 系统稳定性提升，移动携带时因导热材料移位导致故障的风险降低。

经验总结

液态金属虽导热性能顶级，但在笔记本的移动和热循环环境下存在长期稳定性隐患。PTM7950等相变材料在安全性、易用性和长期稳定性方面是优秀的替代方案。更换过程需极度细心，特别是处理原有液态金属时，保护好CPU周围的精密元件和密封结构。

VisiCalc 早期发展回顾

参与与合作起源 1978年，作者通过Byte杂志编辑Carl Helmers结识了哈佛MBA学生、作家兼程序员Dan Fylstra。Fylstra的公司Personal Software当时正在为个人电脑分发软件，并将作者的Microchess纳入产品线。随后两人讨论并决定合并公司。不久，Fylstra向作者介绍了Dan Bricklin及其“电子计算账簿”的革命性想法。作者前往波士顿与Bricklin和Bob Frankston会面，并在中餐厅讨论产品命名，候选名称包括“Visible Calculator”和“Electronic Ledger”，但当时认为“VisiCalc”听起来像维生素而未采用。

开发与资金 Fylstra代表公司与Bricklin及Frankston谈判合同，核心争议在于版税比例和预付款。当时软件版税尚无标准，最终参考了Microchess的版税模式（约30%）。Frankston计划使用跨编译器和自制宏语言开发，预计月成本4000-5000美元。公司同意承担开发费用，但现金流紧张。作者同意推迟Microchess的应得版税，直至公司有能力支付。因此，Microchess的销售收入实质上资助了VisiCalc的早期开发。

公司迁移与早期演示 1979年初，公司将总部从波士顿迁至硅谷。作者在桑尼维尔寻找办公室并接触行业人士。期间，Microchess销售额已突破100万美元。作者曾向苹果公司主席Mike Markkula演示VisiCalc原型，展示了其快速制作利润表的能力，但Markkula当时更热衷于自己编写的支票程序，未能充分理解VisiCalc的潜力。1979年全年，作者向数百人演示VisiCalc，程序员群体反应热烈，而非技术背景者则普遍认为计算机本应具备此类功能。

技术贡献与产品完善 VisiCalc早期版本缺乏文件系统，作者利用自己反汇编Apple DOS时编写的底层磁盘驱动程序源码，协助Frankston集成到VisiCalc中。这优化了性能并最大化内存利用。产品发布后，这些技术也被用于开发拷贝保护机制。至1979年4月，VisiCalc已稳定可靠，作者甚至用其制作了世界上第一个用于税务计算的电子表格。

产品发布与行业影响 1979年5月，公司在旧金山West Coast Computer Faire展会上秘密演示VisiCalc，并邀请包括Steve Jobs、Adam Osborne在内的行业领袖体验。定价建议范围在25至400美元之间。同年8月，公司开始在《Byte》杂志投放广告，并采用了独特的棕色活页夹包装，提升了产品专业形象，不久后成为行业包装标准。10月17日，VisiCalc 1.37版正式发货，首月即售出1293套。

历史意义 作者总结了VisiCalc的三大影响：

1. 面向大众的编程：它将计算机的问题解决能力赋予了不会编程的用户，使用电子表格进行公式计算实质上是一种编程行为。
2. 模拟能力：用户可通过即时修改数据并查看结果，直观地探索各种可能性，深刻理解业务中的敏感因素，从而提升商业智能和决策质量。
3. 生产力提升：它量化地提高了个人生产力，甚至成为企业购买计算机的理由。

作者指出，VisiCalc与Microchess一同推动了Personal Software/VisiCorp连续五年成为最大软件公司。尽管作者自谦其贡献微小，但参与VisiCalc的诞生是实现个人使命的满足经历。文章末尾提及“spreadsheet”一词的流行与VisiCalc的推广密切相关，并引用了《牛津英语词典》的相关记录。