ShotSpotter：监听社区的枪声检测系统

核心概述 ShotSpotter（现公司更名为SoundThinking，但系统仍用原名）是一个户外声学枪声检测系统，通过在城市部署声学传感器，利用签名匹配检测枪声并运用飞行时间原理定位可能来源。该系统为美国多个执法机构提供服务，但其运作方式和影响引发了广泛争议和批评。

主要争议点

1. 高度保密性：公司将传感器位置信息视为机密，甚至不向作为客户的执法机构披露。这引发了外界无法独立验证其声称的效能、以及该公司试图压制对其产品民权影响研究的指控。
2. 证据争议：ShotSpotter传感器录制的对话已两次作为证据被引入刑事审判（一次被法庭允许，一次未被允许），存在用于未来证据的潜在可能。此外，有令人信服的证据表明，该公司会为了迎合检察官的叙述而操纵对证据的“解释”，即便其原始分析与此矛盾。
3. 准确性存疑：尽管公司声称效果显著，但主动抵制独立评估。一份关于芝加哥的报告显示，仅11.3%的ShotSpotter报警被确认为枪声。阿尔伯克基警方则称，通过该报告识别出数百名嫌疑人或受害者。

数据泄露与实地调查

• 一份包含传感器位置的电子表格被泄露给《连线》杂志。尽管该杂志的地图经过模糊处理，但作者成功从其网络数据中提取了精确坐标。
• 在阿尔伯克基市，传感器外观为“无害的米色盒子”，通常夹在路灯臂上。

阿尔伯克基市的部署与模式

• 规模与密度：全市现有721个传感器，覆盖面积约为190平方英里的部分区域。密度虽低于芝加哥（每平方英里20-25个），但依然显著。
• 不平等分布：传感器覆盖区域与种族和阶级高度相关：
  • 覆盖密集区：河流谷地（城区内部分）、西区、国际区、内东北区（大致以高速路为界）以及市中心核心地带。历史悠久的西班牙裔社区（如Barelas）和非裔社区（如South Broadway）被严密监控（仅Barelas中心一英里内就有31个传感器）。
  • 覆盖稀疏/空白区：较富裕的东北部大部分地区（从UNM北校区到山麓）、Nob Hill住宅区、老城、Four Hills等。传感器分布与家庭收入呈正相关：越富裕，受监控越少。
• 具体案例：传感器安装在发生过枪击事件的华盛顿中学门口、发现尸体的沃尔玛后巷等地点。富裕区域（如Heights）最近的传感器位于城市边缘的峡谷。
• 背景：阿尔伯克基警方（APD）对ShotSpotter信息不透明，且该市本身已拥有一个庞大的实时犯罪中心视频监控网络和自动车牌读取器系统，整体处于缺乏公众监督的泛在监控状态。

结论 文章揭示了ShotSpotter系统在阿尔伯克基市的部署呈现出明显的针对低收入和少数族裔社区的过度监控（overpolicing） 模式，结合其运作保密性、证据使用争议以及准确性疑问，引发了严重的公民自由和公平性担忧。该系统是城市中更广泛、监管不足的监控技术网络的一部分。

这篇文章介绍了作者用Go语言解决“十亿行挑战”的过程，从最初耗时1分45秒的简单方案，通过九次迭代优化，最终将处理时间缩短至3.4秒。

挑战背景：任务是处理一个包含十亿行数据的文本文件（约13GB），每行包含一个气象站名称和温度。需要计算每个气象站的最低、平均和最高温度。

核心优化路径：

1. r1（基础方案）：使用标准库bufio.Scanner、strings.Cut和strconv.ParseFloat，耗时1分45秒。
2. r2（指针优化）：将map[string]stats改为map[string]*stats，减少哈希计算，耗时1分31秒。
3. r3（手动解析温度）：放弃strconv.ParseFloat，手动解析温度字符串，耗时55.8秒。
4. r4（定点整数）：使用定点整数（如34.5表示为345）代替浮点数进行计算，耗时51.0秒。
5. r5（优化分割）：从行尾向前寻找分号;，避免扫描整个站名，耗时46.0秒。
6. r6（自定义读取）：弃用bufio.Scanner，自行用1MB缓冲区读取文件块并处理，耗时41.3秒。
7. r7（自定义哈希表）：实现基于FNV-1a哈希和线性探测的自定义哈希表，在解析时同步计算哈希，并存储字节切片以避免字符串分配，耗时22.1秒，性能大幅提升。
8. r8（并行化基础方案）：将文件分块，并行执行r1方案，最后合并结果，耗时22.6秒。
9. r9（最终方案）：结合r7的所有优化与r8的并行化，耗时3.4秒。

关键技术总结：

• 减少内存分配：使用指针、字节切片、自定义哈希表存储键，避免不必要的字符串分配。
• 简化解析：手动解析固定格式的温度，使用定点整数运算。
• 优化I/O与处理：自行管理文件读取缓冲区，避免逐行扫描的开销。
• 并行计算：将任务分块给多个Goroutine处理。
• 使用性能分析：作者使用Go的CPU profiler（go tool pprof）指导优化，识别出map操作、字符串分配和解析等热点。

结果对比：

• 作者的最终方案（r9）耗时3.4秒。
• 当时已知最快的Go方案（AY）耗时2.90秒。
• 原始挑战中最快的Java方案（TW）在作者机器上仅耗时0.953秒。

结论：作者指出，虽然对于一次性任务，基础方案已足够，但在数据处理流水线等场景中，显著的性能提升能带来巨大的成本节约和体验改善。这类优化既实用又充满乐趣。

CS 6120：高级编译器：自学在线课程摘要

课程概述

CS 6120 是康奈尔大学 Adrian Sampson 教授开设的一门博士级别的编译器课程。它既涵盖通用的编译器主题（如中间表示、数据流分析、“经典”优化），也涉及更具研究性的主题（如并行化、即时编译、垃圾回收）。

课程工作主要包括阅读论文和开源实践任务，实践中使用 LLVM 以及为此课程专门设计的教育用中间表示（IR）。

课程形式与进度

该页面为希望在“想象的大学”里自学这门课程（修4个想象学分，无成绩）的人列出了课程大纲。课程内容以线性时间线呈现，将课程与论文阅读交错进行。

每节课都包含视频和书面笔记，部分课程设有实践任务。任务都是开放式的，旨在通过将抽象概念转化为实际代码来巩固理解。视频中指定了建议的视频观看与论文阅读的顺序。

与实际 CS 6120 课程的主要区别在于：

• 自学版本没有任务截止日期。
• 无法参与课程的 Zulip 讨论区。
• 实际课程期末有课程项目；在自学版本中，期末作业是“通过编译器的魔力改变世界”。

课程资源与开源

讲师在视频制作方面是新手，因此早期课程的制作水平请见谅。CS 6120 项目在 GitHub 上开源，鼓励在发现问题时提交错误报告。完成课程后，请填写反馈表格。

课程大纲与内容

课程按以下顺序展开，每部分包含核心主题及配套阅读的论文：

1. 欢迎与概述

   • 阅读论文: 《不执行明显错误操作却产生错误数据！》 (ASPLOS 2009) 及 SIGPLAN 经验评估指南。

2. 程序表示

   • 学习表示程序的方法。
   • 开始使用 Bril（课程专用的教育IR）。

3. 局部分析与优化

   • 简单的死代码消除。
   • 局部值编号。

4. 数据流分析

   • 学习数据流分析理论。
   • 完成相关实践任务。

5. 全局分析

   • 全局分析与优化。
   • 阅读论文: 《高效的路径性能剖析》 (MICRO 1996)。

6. 静态单赋值形式

   • 学习 SSA。

7. LLVM

   • 介绍 LLVM。
   • 编写一个 LLVM Pass。
   • 阅读论文: 《基于 Alive 的可证明正确的窥孔优化》 (PLDI 2015)。

8. 循环优化

   • （视频内容）

9. 过程间分析

   • （视频内容）
   • 阅读论文: 《基于类型的别名分析》。

10. 别名分析

    • （视频内容）
    • 阅读论文: 《垃圾收集的统一理论》 (OOPSLA 2004) 及《快速的保守垃圾收集》 (OOPSLA 2014)。

11. 内存管理

    • （视频内容）
    • 阅读论文: 《SELF 语言的高效实现》 (OOPSLA 1989) 及《动态语言的基于追踪的即时类型特化》 (PLDI 2009)。

12. 动态编译器

    • 学习动态编译器。
    • 学习基于推测的追踪。
    • 阅读论文: 《超优化器：审视最小程序》 (ASPLOS 1987) 及《Chlorophyll：用于低功耗空间架构的合成辅助编译器》 (PLDI 2014)。

13. 程序综合

    • （视频内容）
    • 阅读论文: 《线程不能作为库来实现》 (PLDI 2005)、《利用多媒体指令集开发超字级并行性》 (PLDI 2000)、《确定性并行 Java 的类型与效果系统》 (OOPSLA 2009) 及《一个现实编译器的形式化验证》 (CACM 2009)。

14. 并发与并行

    • （视频内容）

在Windows平台上使用MSVC编译器时，std::shared_mutex（其底层基于Windows Slim Reader/Writer锁）出现了一种非预期的死锁行为。该问题在MinGW或其他平台上不会发生。

问题场景如下：

1. 主线程获取独占锁。
2. 主线程创建N个子线程。
3. 每个子线程尝试获取共享锁，并等待直到所有子线程都成功获取共享锁后，再释放共享锁。
4. 主线程释放独占锁。

在大多数情况下此流程能正常工作，但约每1000次运行中会出现一次死锁。死锁时，恰好一个子线程成功获取了共享锁，而其余子线程则永久阻塞在lock_shared()调用上。如果已获取共享锁的那个子线程释放锁，其他子线程便会解除阻塞，但若设计要求必须等待所有读取线程就绪，则会导致无限等待。

该问题可通过直接使用SRW锁函数或C++标准库中的std::shared_mutex/std::shared_lock复现。用户提供了可重现问题的代码示例。

用户认为，当不存在独占锁时，lock_shared()函数不应永久阻塞，这应被视为一个bug。此bug仅出现在Windows MSVC的SRW锁实现中。尽管有观点（如Raymond Chen 2017年的一篇博文）暗示这可能属于使用错误，但用户倾向于认为这是SRW锁实现本身的缺陷或需要更明确的文档说明。

目前，社区已在StackOverflow上确认此行为，但需要语言标准专家或微软官方明确这是“按设计”还是一个bug。

文章讲述了作者在2005年经历的一次令人难以置信的演示事件。作者是一位独立性能顾问，同时也是DTrace工具的重要开源贡献者（开发了DTraceToolkit）。当时，Sun Microsystems邀请了一位来自美国的“重要人物”到悉尼演示基于DTrace的新产品。

在演示过程中，作者发现演示的工具虽然被包装在Sun的GUI中，但功能上并无新意。当他要求查看其中一个socket追踪工具（socketsnoop.d）的源代码时，震惊地发现该脚本正是自己一年前编写的开源版本，且存在已知缺陷。

更令人气愤的是，作者发现演示中的所有工具都源自自己的开源DTraceToolkit，但所有脚本中的作者署名、版权声明和开源许可证（如GPLv2或CDDL）均被移除，并替换为Sun Microsystems的版权信息。当作者指出这一点时，在场的澳大利亚同事也直言“你不能这样做”。那位美国VIP对此显得困惑和不知所措，声称自己可能从他人处获得了这些工具。

作者事后分析，这种现象部分源于Sun当时的一种文化：认为只有Sun自身才能善用其技术，外部创造的东西被视为次等。因此，当员工发现优秀的外部作品时，容易误认为其源于Sun内部，从而放心地进行复用和重新包装。

文章还提到，类似事件并非孤例。例如，苹果在OS X中使用作者的工具时保留了署名和许可证，Oracle和FreeBSD社区也是如此。作者也指出，自己的火焰图（Flame Graph）算法因已成熟稳定，重写问题不大，但对于仍在持续发展的BPF工具，他建议其他开发者基于现有库构建，而非重写，以保持版本更新和工程资源集中。

最终，这次“世界级演示”展示的并非想象中革命性的新产品，而是作者自己被挪用的开源代码。作者认为，虽然开源代码被重新品牌化并不罕见，但这种“开发者因自己的代码而获得世界巡演，并向原作者演示”的情形颇为特殊。

服务器投掷世界锦标赛概要

本文介绍了由世界服务器投掷协会（WSTA）主办的服务器投掷运动，该运动此前为荷兰云社区组织的地下活动，如今首次进入主流视野，作为CloudFest活动的一部分面向整个云社区开放。

核心赛事信息

• 性质：一项将服务器尽可能远掷的强度运动，强调力量、平衡、技巧与专注力，对所有性别和能力水平开放。
• 赛程安排：
  • 预赛：3月24日17:30-19:00，分男子组和女子组。每位选手有两次投掷机会，取最远成绩，前三名晋级。
  • 决赛：3月25日17:00-18:30，预赛晋级者将与西班牙、荷兰资格赛获胜者及上届冠军同场竞技。获胜者将佩戴WSTC冠军腰带。
• 举办地点：CloudFest Village的服务器投掷竞技场。

参与要求

• 参赛资格：仅限已注册CloudFest的与会者申请，名额有限。申请阶段现已结束，所有名额已满。
• 服务器标准：所有比赛用服务器均带有WSTA卓越印章，表示其经过重量和空气动力学测试并获准投掷。

活动背景与配套

• 历史渊源：文中戏称该运动有“古老根源”，类比古典希腊的“铁饼”（“discus”被戏称为“服务器”的古词）。
• 票务信息：参与CloudFest需购买门票，包括标准通票、VIP通票、供应商通票及供应商VIP通票，各通票附带不同权益（如场地访问、活动参与、交通服务、餐饮等）。媒体代表有单独通道。

合作伙伴与宣传

• 文章列出了WSTC的合作伙伴，并提及一段来自CloudFest 2025的服务器投掷宣传片，鼓励观众获取CloudFest通行证以亲临现场。

本文介绍了一款用于SD WebUI（通过Forge）的扩展，旨在利用Stable Diffusion SDXL和SD1.5模型生成透明图像和图层。该扩展的核心是原生透明扩散技术，能够在潜在空间处理透明度，从而生成包括透明玻璃、半透明发光效果、精细毛发等简单背景去除方法无法实现的复杂细节。

核心技术与模型

扩展自动管理模型下载，主要提供以下模型文件：

• 透明图像生成LoRA：如layer_xl_transparent_attn.safetensors（针对SDXL）和layer_sd15_transparent_attn.safetensors（针对SD1.5），用于将模型潜在分布转换为可解码透明度的“透明潜在空间”。
• 图层生成偏移模型：如layer_xl_fg2ble.safetensors、layer_xl_fgble2bg.safetensors等，用于在前景、背景和混合图层之间进行条件生成。
• 专用VAE模型：包括编码器（vae_transparent_encoder.safetensors）和解码器（vae_transparent_decoder.safetensors），以及针对SD1.5的版本，用于在像素空间和潜在空间之间提取或解码透明信息。这些模型经过轻量化设计以减少显存占用。
• 联合生成模型（主要针对SD1.5）：如layer_sd15_joint.safetensors，可在一次扩散过程中同时生成前景、背景和混合图像（批次大小需为3的倍数）。

主要功能与工作流程

1. 生成透明图像：可单独生成带透明通道的PNG图像。
2. 同时生成前景与背景：
   • SD1.5（一步流程）：使用联合模型一次性生成前景、背景和混合图。
   • SDXL（两步流程）：目前需分步生成，例如先生成背景条件下的混合图，再基于此生成背景；或先生成前景，再生成背景。文章提到未来将发布SDXL的一步模型。
3. 独立图层提示词：允许为不同图层（前景、背景、混合）设置独立的文本提示，以精细控制内容，避免全局提示相互干扰。
4. 条件生成：
   • 背景条件生成前景：根据提供的背景图像生成合适的前景。
   • 前景条件生成背景：根据提供的前景图像生成匹配的背景。

使用与验证

扩展提供了详细的完整性检查（Sanity Check） 设置，包括具体的模型版本、提示词、采样器、参数等，以帮助用户验证安装和设置是否正确，确保能复现示例结果（如苹果、头发杂乱的女性、玻璃杯、发光魔法书等）。

注意事项

• 批次大小要求：生成多图层时，批次大小必须为生成图层数的倍数（例如，同时生成3张图则批次需为3的倍数），否则输出将为噪声。
• 采样器选择：在部分SDXL的工作流中，建议使用Euler A或UniPC等采样器，而非DPM++系列，这可能是由于训练与推理框架差异导致。
• 模型状态：部分模型（如SDXL的联合模型、较轻量的条件模型）仍处于研究或优化阶段，未来可能会更新。

Google SRE Book (2017) 内容总结

本书系统阐述了Google的网站可靠性工程 (Site Reliability Engineering, SRE) 理念、原则与实践。SRE的核心是运用软件工程方法来解决运维问题，旨在通过自动化、系统化手段构建和维护大规模、高可靠性的分布式系统。

第一部分：介绍

本部分定义了SRE角色及Google的生产环境。SRE是兼具软件开发和系统运维技能的工程师，其目标是保障服务的可靠性。Google的生产环境是一个高度复杂、全球分布的系统，包含基础架构、物理层、存储系统、网络及各类服务。

第二部分：原则

这部分奠定了SRE工作的理论基础。

• 拥抱风险：可靠性并非100%最好，需通过量化风险（如错误预算）来平衡可靠性与创新速度。
• 服务水平目标 (SLO)：SRE的核心是定义、测量和保障SLO，它是驱动技术决策和运维工作的北极星。
• 消除琐事：系统性地识别和自动化重复性、手动的运维工作（“琐事”），以释放工程师时间进行有持久价值的工程工作。
• 监控分布式系统：提出了监控的“四个黄金信号”（延迟、流量、错误、饱和度），强调监控应聚焦于症状而非原因。
• 自动化演进：阐述了Google自动化从手动到全自动的演进路径及其价值。
• 发布工程：强调可靠、可重复、快速的发布流程是保障服务可用性的关键。
• 简洁性：倡导通过简洁的系统设计来提升可靠性，避免不必要的复杂性。

第三部分：实践

本部分详尽介绍了SRE的具体技术实践与流程。

• 值班与应急响应：描述了SRE的轮值制度、有效的故障排查方法论、紧急响应流程及事故管理（Incident Management）的规范步骤。
• 事后复盘：倡导建立免责的事后复盘文化，专注于系统性改进而非追责，是学习失败、防止复发的核心机制。
• 可靠性测试：通过各类测试（如压力测试、混沌工程）主动发现系统弱点，验证系统在故障下的行为。
• 前端与数据中心负载均衡：介绍了在系统入口和内部进行高效、可靠负载均衡的策略与技术。
• 处理过载与级联故障：提供了应对流量洪峰、防止资源耗尽以及阻断级联故障的多种技术和架构模式（如熔断、降级）。
• 管理关键状态：深入探讨了在分布式系统中实现可靠分布式共识（如Paxos）的原理与应用。
• 数据完整性与处理流水线：强调数据是命脉，介绍了保障数据在采集、处理、存储全链路中不丢失、不损坏的实践，以及可靠的数据处理框架。
• 可靠的大规模发布：阐述了在Google规模下，如何通过严格的协调和检查清单来管理新功能或新服务的发布。

第四部分：管理

本部分关注SRE团队的组织、协作与持续改进。

• SRE培养：描述了将新工程师培养为合格SRE的系统化路径。
• 中断处理：探讨了如何管理工作中不可避免的中断，保护工程时间。
• 嵌入式SRE：介绍了一种SRE深度介入产品开发团队的模型，旨在帮助团队从过度的运维负担中恢复。
• 沟通与协作：强调了在分布式团队和跨团队项目中有效沟通的重要性。
• SRE参与模型的演进：说明了SRE与产品开发团队的合作模式并非一成不变，会根据需求动态调整。

第五部分：结论与附录

结论部分总结了SRE的核心理念，并从其他行业借鉴了高可靠性组织的经验。附录提供了极具实用价值的参考资料，包括可用性数值表、生产服务最佳实践集、事后复盘示例、发布协调清单和生产会议记录示例等。

总体而言，Google SRE Book不仅是一本技术手册，更是一套完整的方法论体系。它倡导了一种基于风险量化、自动化和持续改进的可靠性工程文化，为构建和运维大规模分布式系统提供了权威的指导。

David Holladay：盲文技术先驱逝世

盲文软件领域的早期创新者 David Holladay 于2024年2月15日（星期四）因家中意外事故在医院去世。他是癌症幸存者，在生命的最后五年里一直勇敢地与多种健康问题作斗争。

David Holladay是盲文技术的先驱。1981年，他与妻子 Caryn Navy 共同创立了 Raised Dot Computing（后更名为 Braille Planet）。他在 Apple II 计算机上的早期工作具有开创性，通过语音以及将盲文输入转换为盲文和印刷品的方式，为视障用户提供了无障碍支持。之后，他的工作还拓展到支持从 Nemeth 码数学盲文生成印刷体数学内容。在 Raised Dot Computing 的后期，他推出了创新产品 MegaDots，该产品在支持盲文格式方面无可匹敌。

1999年，David 和 Caryn 加入了 Duxbury Systems 公司，并一直作为团队的重要成员。在 Duxbury 的工作主要集中在将 DBT（Duxbury Braille Translator）软件推广到全球众多国家和语言上。尽管在生命的最后几年卧床不起，David 对盲文的热情从未消退，一直工作到生命的最后一天。

葬礼信息：葬礼定于美国东部时间2月19日（星期一）中午12点在马萨诸塞州Chelmsford的Congregation Shalom举行，并于下午1点在Beth El Cemetery下葬。David的妻子Caryn表示，葬礼仪式将提供在线直播（可通过 congregationshalom.org/worship-2/ 观看）。

Duxbury Systems 社区认为，整个盲文界将与公司同仁一样，深切怀念 David Holladay。

2024年2月21日，美国最大的医疗支付处理商UnitedHealth集团的子公司Optum遭勒索软件攻击，导致其运营的Change Healthcare网络服务中断。该网络是全国医疗服务提供商管理支付和保险理赔的核心平台。系统瘫痪持续长达9天，严重影响全国药房和医疗机构处理处方药的能力，许多患者无法及时获得救命药物。

攻击者与模式：

• 攻击由名为AlphV（又称Black Cat）的俄罗斯语勒索软件团伙实施。
• 该团伙采用“勒索软件即服务”模式运作：附属黑客入侵受害者系统，使用AlphV的基础设施加密文件并勒索赎金，事后分成。

事件影响：

• 由于无法计算保险覆盖费用，药房被迫采用备用服务或离线方式处理处方。
• 此事件被描述为美国医疗系统遭遇的最严重网络安全事件之一。

执法背景与现状：

• 2023年12月，美国FBI等国际执法机构曾查封AlphV部分基础设施，但该团伙迅速恢复运营。
• 此次攻击表明，尽管遭受打击，AlphV仍对美国关键基础设施构成持续威胁。

服务恢复：

• Optum于2024年3月1日表示，经过与技术伙伴及零售药房的测试，已恢复Change Healthcare服务，全部客户已于中部时间下午1点重新启用相关功能。

弗拉·毛罗世界地图数字化项目摘要

这是一个关于15世纪弗拉·毛罗世界地图的综合性在线研究与展示项目，旨在提供一个可缩放、带有多语言翻译的数字化版本，并对其进行深度解读。

项目核心

项目的核心是对《弗拉·毛罗世界地图》的数字化呈现与研究。该地图由威尼斯卡马尔多利修会修士弗拉·毛罗于约1450年完成，是中世纪晚期最重要的世界地图之一。项目提供了该地图的高分辨率可交互图像，并配以大量注释（地图注记）的翻译与解释。

主要内容与结构

项目的解说内容按主题组织，主要涵盖以下几个方面：

1. 历史背景：介绍了地图制作的时代背景，特别是15世纪威尼斯的政治、经济、贸易状况，以及奥斯曼帝国对地中海封锁等事件对探索活动的影响。
2. 制图师弗拉·毛罗：详细介绍了弗拉·毛罗的生平、所在的圣米凯莱修道院，以及他作为宇宙学家的工作。还提及了他所参考的其他航海图（如威尼斯藏航海图）。
3. 地图深度解读：
   • 宇宙学空间：解释地图所体现的中世纪宇宙观，包括天界、月下世界、元素、伊甸园等概念。
   • 地理空间：逐一解析地图上的各类地理元素，如注记、风玫瑰图、王国、省份、城市、山脉、河流、岛屿、船只等。
   • 世界各部分：对地图上描绘的各个区域进行具体说明，包括古代世界、“罗西亚”、非洲、埃塞俄比亚、锡兰（Taprobana）、中国（Cathay和Mangi）、日本（Cipango）、印度洋等，并特别标注了马可·波罗所提及的地点。
4. 资料来源与影响：分析了地图的多种信息来源，包括古典文献（如托勒密）、方济各会等修会传教士的报告（如柏朗嘉宾、鲁布鲁克）、商人与旅行者的见闻（重点是马可·波罗）、以及其他航海图和伊斯兰资料。同时，也追踪了地图的后世接受史，包括为葡萄牙国王制作的副本、洛伦佐·德·美第奇的收藏，以及后世的复制与研究情况。
5. 相关知识：项目还扩展了相关领域的知识，包括：
   • 中世纪航海技术：介绍了航海图、天文导航、定位方法、航海仪器及船舶。
   • 制图学背景：解释了托勒密的地图投影法、世界大小的观念，并将弗拉·毛罗的地图与其他中世纪“世界地图”进行了比较。

互动与探索

项目提供了交互式探索功能，允许用户通过数字地图进行缩放和浏览。此外，还包含一个“数字图书馆”板块，可能汇集了相关的图像与文献资料。

项目价值

该项目不仅是一次对重要文物的数字化保存，更是一个立体的学术框架，将地图置于其广阔的历史、政治、商业和思想背景下进行阐释，揭示了15世纪欧洲对世界认识的深度与广度，以及威尼斯在全球探索网络中的关键角色。它综合了历史学、地图学、地理学和文化研究的多维度视角。

Hancho 是一个轻量级构建系统，以单个 Python 文件形式分发，无需依赖或安装。它旨在结合 Ninja 的执行速度与 Bazel 的表达性语法，专注于快速执行构建命令，同时提供易于编写的构建脚本。项目适用于中小型项目。

核心特点：

• 极简部署：仅需一个 Python 文件 (hancho.py)，复制至项目中即可使用。
• 无依赖：无需额外安装，直接运行。
• 混合优势：兼具 Ninja 的高效执行与 Bazel 的 Python 式语法灵活性。
• 轻量替代：相比 Bazel（安装包超过 200MB）更为轻便。
• 原生 Python：构建脚本可使用任意 Python 代码。

基本使用：

1. 通过 wget 获取 hancho.py 文件并赋予执行权限。
2. 构建脚本（如 build.hancho）中使用 hancho.Tool 定义工具（如编译命令），通过 {模板} 动态生成参数，其中以 in_* 和 out_* 命名的字段用于标识输入输出文件，以追踪依赖。
3. 使用 hancho.Task() 创建任务，任务之间可相互引用以建立依赖关系，Hancho 会自动构建依赖图并并行执行独立任务。

示例说明： 示例展示了如何定义 C++ 编译和链接任务：

• compile_cpp 工具定义了将 .cpp 编译为 .o 的命令。
• 通过 hancho.Task 创建具体的编译任务（如 main_o），指定源文件。
• link_cpp_bin 工具定义链接命令，其任务引用了先前的编译任务对象，从而形成依赖。
• Hancho 会并行执行独立的编译任务，在全部完成后自动触发链接任务。

项目状态：

• 当前版本为 v0.4.0，API 已趋于稳定。
• 文档与教程仍在完善中，提供了示例目录和针对 C++、WASM 等的构建工具样例。

苹果Lisa开发团队访谈摘要（1983年）

本文是《Byte》杂志在1983年2月对苹果公司Lisa项目三位核心成员（Wayne Rosing、Bruce Daniels、Larry Tesler）的采访。采访揭示了Lisa电脑开发的幕后故事，尽管Lisa因价格高昂未获巨大商业成功，但它为次年更成功的Macintosh奠定了基础。

团队组建与协作

Lisa项目软件团队主要由具备多年经验的专业人员组成，平均拥有9年软件开发经验。项目早期用了约一年时间建立团队，确保成员拥有共同愿景并能高效协作。团队强调沟通是关键，需平衡硬件、操作系统、应用软件、用户界面手册等多方面的并行开发。

项目管理与挑战

项目进度估算困难，因为存在大量相互依赖的条件（如硬件就绪、操作系统冻结等）。团队坚持“产品完整性不为进度妥协”的原则，宁可接受延误也不牺牲质量。许多技术挑战前所未有（如高密度软驱、图形打印），耗时远超预期。

用户界面设计

用户界面设计是项目最困难且影响最广的部分。团队在项目初期花费六个月制定了一份35页的《用户界面标准》文档。通过引入“天真用户”（如新员工）进行大量可用性测试，基于客观数据做出设计决策（如键盘布局、Apple键的引入）。界面设计需平衡培训、出版、营销等多方意见。

技术决策与创新

• 硬件：选用当时较新的Motorola 68000处理器，看中其架构潜力；采用自研软驱技术（通过改变转速提升容量）和微步进算法以提高可靠性；决定不使用NEC 7220图形芯片，而是通过软件实现更灵活、功能更强的位图图形处理。
• 软件：自行开发操作系统以满足图形界面、窗口管理、数据可靠性等特定需求；构建了丰富的基础软件架构（源码约10MB，目标码约500KB），支持图形、多字体、打印等高级功能。
• 集成与规划：从一开始就计划将核心应用集成到系统软件中；硬件与软件协同设计，例如为优化用户界面多次修改硬件设计。

未来展望

团队认为Lisa奠定了一个强大的基础（“应用机器”），未来将聚焦于：深化应用集成、推出开发工具包、加强网络通信功能、增加数据库能力。他们期待在已构建的团队和基础上继续创新。

项目概述

ambient.garden 是一个算法生成的音频景观项目，通过交互式界面让用户探索动态的音频环境。

主要功能

• 导航方式：支持拖动查看周围环境、点击移动到特定位置。
• 自动驾驶：可随时切换自动驾驶模式，提供速度控制选项。

交互细节

• 用户通过直观操作（如拖动和点击）控制视角和移动。
• 自动驾驶功能允许自动导航，增强用户体验。

这款名为Minimal的手机旨在回归基础，减少智能设备带来的干扰，结合了黑莓手机的物理键盘和电子墨水屏的特点。

核心特点：

• 显示屏： 采用背光单色电子墨水（E-ink）屏，搭配电容式触摸层，护眼且极其省电。
• 键盘： 配备全尺寸QWERTY物理键盘，以提供更准确舒适的输入体验。
• 电池： 内置4000mAh电池，官方宣称可支持长达4天的使用，并支持快速充电。
• 设计： 采用环保材料制造，最终尺寸确定为120 x 72 x 10毫米。
• 操作系统： 运行名为MnmlOS的系统，该系统基于最新版Android，但会最大限度减少干扰。
• 应用与功能： 出厂预装应用严格筛选，仅包含电话、短信、邮件以及少量“现代生活必需”的第三方应用（如出行、导航），以及日历、笔记等生产力工具。娱乐功能被简化，专注于放松，可通过YouTube和本地存储播放音乐，并配备耳机孔。未来计划支持5G、Android Auto和非接触式支付。相机功能正在开发中。
• 隐私承诺： 公司表示用户数据仅用于手机功能，不会用于广告目的，并承诺频繁的安全更新和至少五年的设备支持。
• 计划与价格： 设计已最终确定，由一家“领先制造商”负责生产。计划于明年二月初在众筹平台开启预售，预计零售价约为400美元，早期支持者可享折扣。目前可通过官网加入等待名单。

Bob Heil，呼号 K9EID，于2024年3月1日因癌症去世，享年83岁。他是一位定义了现场摇滚乐声音的音响工程师，也是将音频工程原理带入业余无线电主流应用的先驱。他是ARRL终身会员及ARRL Maxim Society成员。

Heil于1966年创立了Heil Sound公司，为感恩而死乐队、谁人乐队、Joe Walsh和Peter Frampton等音乐家设计了现代音乐会音响系统的模板。标志性的现场专辑《Frampton Comes Alive!》中使用的Talk Box即出自其手。他的音频工程产品曾入选摇滚名人堂，并于2007年获得Parnelli音频创新奖，以表彰其对现场音响行业的影响。Bob Heil曾表示：“我的一生致力于追求卓越的声音，无论是在音乐会舞台还是在业余无线电世界。”

在商业和艺术成就之外，Heil对业余无线电同样充满热情。他将音频工程专业知识与对无线电的热爱相结合，创立了Heil Ham Radio，专门为业余无线电爱好者生产麦克风、耳机等设备，并注重高音频质量。

Heil以乐于指导他人、帮助他们在业余无线电中取得成功而闻名。他还是业余无线电组织的慷慨捐赠者，包括ARRL，最近还向W1AW纪念电台捐赠了大量新音频设备。

ARRL发展总监Kevin Beal（K8EAL）称赞Heil是一位在许多领域的巨匠，他时间慷慨、见解深刻，具有慈善家的胸怀。Heil热衷于AM操作，并多年担任Ham Nation播客的出镜主持人。

ARRL主席Rick Roderick（K5UR）表示，Bob Heil将高质量音频引入业余无线电的技术成就，与他慷慨助人的精神相比相形见绌。他长期以来乐于指导和教导，对这项爱好的影响将长久持续。他的离世是一个重大的损失。

Scaleway 推出全球首款 RISC-V 云服务器

Scaleway 推出了其 EM-RV1 服务器，这是全球首个基于 RISC-V 架构的专用云服务器产品，标志着服务器行业的重要里程碑。

核心规格

• 处理器：搭载 T-Head 1520 SoC，其中 C910 CPU 为 RV64GC 架构，4 核心，主频 1.85 GHz。
• 内存与存储：16 GB LPDDR4 内存，128 GB eMMC 存储。
• 网络：100 Mbit/s 以太网卡，包含公网 IPv4 和 IPv6 地址。
• 能效：每核平均功耗仅为 1.3W。
• 操作系统支持：Debian、Ubuntu、Alpine Linux。
• 其他单元：集成 GPU（支持 OpenCL、OpenGL ES、Vulkan）、VPU（支持 H.265/H.264/VP9 编解码）及 NPU（4 TOPS@INT8，支持 TensorFlow、ONNX 等框架）。

价格与供应

• 型号：EM-RV1-C4M16S128-A
• 价格：每小时 0.042 欧元（不含税），或每月 15.99 欧元（不含税）。
• 可用区域：仅限 fr-par-2 区域。

设计与研发意义

EM-RV1 是 Scaleway 经过数月密集研发的成果，旨在克服硬件供应有限和软件生态尚不成熟的挑战，将 RISC-V 引入云环境。其设计体现了从供应商迭代、电子元件焊接、专用固件开发到 3D 打印机箱制造的 手工艺式迭代过程。

公司认为，RISC-V 作为一种 开放的指令集架构（ISA），其现代设计提供了可替代 x86 和 ARM 的潜力，能够促进处理器设计标准的开放化，并可能帮助各国实现对处理器制造的自主控制。此次发布旨在激活和加速 RISC-V 生态系统的发展与普及。

服务状态与注意事项

• 该服务目前被归类为 “Labs”（实验室） 服务，其服务等级协议（SLA）在测试版服务的特殊条款中定义，SLA 为 0%。
• 安全更新：默认安装的内核已修复了 GhostWrite 漏洞。在 2024 年 6 月 6 日之前安装的系统可能受影响，需按指南更新内核。
• 技术支持：服务器支持通过 SSH 访问串行控制台以安装更多操作系统。源代码可在指定路径获取。
• 故障处理：若因配置错误导致网络访问丢失，可尝试重启、重启至救援镜像或重新安装系统。

与 Kubernetes 集成

尽管 RISC-V 尚未获得 Kubernetes 官方支持，但 Scaleway 提供了预构建二进制文件，允许用户通过其 Kosmos 服务和 Elastic Metal RV1 服务器快速部署 RISC-V 容器。用户需拥有一个 Kosmos 集群（版本 1.29.1）和一个 Elastic Metal RV1 服务器，并按照指南进行配置。