2024-09-12

38 篇热帖

1. Show HN: iFixit created a new USB-C, repairable soldering system (hackaday.com)

iFixit推出的FixHub便携式焊接系统是一个创新性的产品,旨在将便携性与专业工作站的功能相结合。该系统由两部分组成:智能焊笔便携式电源站。两者既可独立使用,也可组合以获得最佳体验。

智能焊笔是一款100W的USB-C设备,能在5秒内升温至工作温度,可适配任何功率足够的USB-C PD电源。其设计独特:没有显示屏或设置按钮,仅有一个物理滑动开关用于切断加热元件电源。状态通过握柄后方的发光指示灯环显示(蓝色表示通电但加热关闭,脉冲蓝色为加热中,橙色为达到设定温度)。它还具有基于加速度计的闲置/休眠功能。为方便携带,它配备了可耐热的磁性笔帽和防脱落的USB-C线缆锁紧环。笔尖易于拆卸,采用3.5mm TRS接口,iFixit计划提供多种规格的笔尖。

便携式电源站本质上是一个容量为5200mAh、支持100W输出的移动电源。当智能焊笔插入时,其正面的OLED屏幕和旋钮编码器可用于配置焊笔的详细设置。它最多可同时支持两支智能焊笔(共享100W功率)。单支焊笔使用时,电池续航预计可达8小时。电源站背面的USB-C口用于充电,可持续连接PD充电器作为传统工作站使用。

可修复性是该产品的核心设计理念。整个硬件设计模块化,易于拆解——无需胶水、隐藏螺丝或易碎卡扣。iFixit承诺将提供完整的拆解指南、详细电路原理图(含工程师手写注释)和备件清单,这在消费级产品中非常罕见。尽管并非开源硬件,但其文档支持水平极高。

连接与控制方式多样。除了通过电源站配置外,用户还可以将设备插入电脑,通过支持WebSerial的浏览器(如Chrome)进行设置和固件更新。更值得注意的是,它支持传统的串行命令行接口,为高级用户提供了更深层次的控制可能。

该系统价格不菲:智能焊笔单售79.95美元,与电源站组成的套装售价249.95美元。作者指出,市面上有更便宜的优质焊接站可选,但iFixit的产品旨在推动行业变革,支持维修权理念,其价值体现在对维修性和开放性的承诺上。

2. Why Haskell? (www.gtf.io)

Haskell 的优势总结

本文旨在反驳 Haskell "不实用"、"学术化" 的刻板印象,论证其作为通用编程语言(特别是用于构建如Web服务器等实际系统)的优势。作者认为,许多其他语言的新特性都深受 Haskell 影响。文章核心围绕 Haskell 如何通过其强大的类型系统纯函数式编程范式,在三个方面提升编程体验:减少错误提高生产力以及便于推理程序

一、 减少错误

Haskell 通过类型系统和纯函数式特性大幅降低了编写错误代码的风险,减少了测试负担。

  • 强大的类型系统

    • 无空值:不存在隐式空值,避免了 NoneType 相关的运行时错误。必须使用 MaybeEither 等类型显式处理可能失败的计算。
    • 显式处理失败Maybe 用于可能无结果的计算,Either 用于可能失败并附带错误原因的计算。类型系统强制程序员处理所有失败情况,否则无法编译。
    • 模式匹配与完备性检查:编译器确保处理了所有可能的模式,遗漏分支会导致编译错误。
    • 避免原始类型滥用:通过 newtype 可以为底层相同(如 String)但语义不同的值创建零成本包装类型,防止参数混淆。
  • 纯函数式编程

    • 数据不可变:消除了数据竞争和状态突变引发的一系列错误,尤其简化了并发编程。
    • 显式副作用:副作用被封装在 IO 等单子中。类型签名清晰表明函数是否具有副作用,防止意外引入副作用。结合类型类,可以精确限制函数允许执行的副作用范围(如只能发邮件,不能读数据库)。

二、 提高生产力

Haskell 的特性使得构建复杂程序更高效。

  • 声明式编程:程序描述“是什么”而非“怎么做”,代码更清晰,易于理解和重构。
  • 概念重用:生态系统围绕高度抽象的数学概念(如 FunctorMonoid)构建。理解一个概念即可广泛应用于不同库和数据结构,减少了学习新库的认知负担。
  • 强大的工具支持:如 Hoogle,允许通过类型签名(甚至是不完整的类型签名)搜索函数,极大提升了查找和使用代码的效率。
  • 无畏重构:强类型系统在重构时充当严格的合作者。通过“修改-编译”的循环,可以快速定位并修复所有由类型不匹配导致的错误,增加对重构正确性的信心。

三、 便于推理程序

Haskell 有助于编写更贴近问题域、复杂性更低的代码,从而更容易理解和验证其正确性。

  • 声明式与表达性:纯函数式和强大的类型系统(如代数数据类型、类型类、参数多态)使得代码能更精确地对问题领域建模。
  • 组合性:整个程序是一个由子表达式组成的单一表达式,无副作用使得子表达式意义明确且可组合。
  • 减少附带复杂性:通过高级抽象(如自定义代数数据类型和类型类)可以创建领域特定语言,专注于领域逻辑,而非底层实现细节。

结论

作者总结,Haskell 的独特之处在于其强类型系统纯函数式语义的紧密结合。这种组合在其他语言中难以完全复制。即使不将其用于生产环境,学习 Haskell 也能深刻改变一个人对编程的思考方式。

3. Techniques I use to create a great user experience for shell scripts (nochlin.com)

Shell脚本用户体验优化技术总结

本文总结了作者在“十亿行挑战”评估脚本中使用的6项提升用户体验的技术。

1. 全面错误处理与输入验证

  • 实施严格的输入验证,提供清晰的错误提示
  • 示例:当缺少参数时显示用法说明
  • 目的:帮助用户快速识别和解决问题

2. 清晰彩色输出

  • 使用ANSI颜色代码区分信息类型
  • 红色用于错误,黄色用于警告
  • 目的:视觉区分提升信息可读性

3. 详细进度报告

  • 实现print_and_execute函数,在执行前显示命令
  • 匹配Bash的set -x追踪格式但更可控
  • 目的:保持透明度,辅助调试

4. 策略性错误处理

  • 开头使用set -eo pipefail确保脚本错误退出
  • 在循环中使用set +e允许单个分支失败继续运行
  • 结束后重新启用set -e
  • 目的:精细控制错误处理流程

5. 平台自适应

  • 检测操作系统类型(Linux/macOS)
  • macOS下使用gtimeout替代timeout
  • 提供安装指导和警告信息
  • 目的:确保跨平台一致性体验

6. 时间戳文件输出

  • 使用date +"%Y%m%d%H%M%S"生成时间戳
  • 为每次运行创建独立结果文件
  • 合并并清理中间文件
  • 目的:支持多次运行而不覆盖历史结果

完整脚本

所有这些技术都集成在#1BRC仓库的evaluate.sh脚本中,旨在创建一个用户友好、信息丰富且健壮的Shell脚本体验。


作者欢迎讨论这些技术,并发布了后续文章补充更多技巧。

5. Show HN: Konty – A Balsamiq-alternative lo-fi wireframe tool for modern apps (konty.app)

Frame0是一款用于创建手绘风格低保真线框图的工具,旨在替代Balsamiq,帮助用户快速将创意转化为现代应用的可视化原型。其核心特点包括:

  • 手绘风格:避免了像素级精确的要求,鼓励快速构思和协作,便于收集反馈而不陷入视觉细节争论。
  • 丰富的UI组件与状态:提供涵盖桌面、移动端、手表和网页界面的组件库(如按钮、表单、导航栏等),许多组件支持可调节状态。
  • 草图风格图标:包含超过1500个基于Lucide图标库转换的草图风格图标,保持视觉一致性。
  • 镜像帧功能:支持创建主帧并重复使用,更新主帧时所有镜像自动同步,适用于保持页头等元素的一致性。
  • AI代理集成:可通过与AI对话在几秒内生成线框图,甚至转换为代码,支持OpenAI、Anthropic等API,也提供MCP服务器与Claude Desktop等工具集成。
  • 页面链接与演示模式:形状可链接到其他页面以展示用户流程,并支持以幻灯片形式进行演示。
  • 模板与导出功能:提供多种设备预设模板(Web、手机等),并可将交互原型导出为HTML或PDF文件便于分享。
  • 综合图表支持:支持绘制流程图、UML图和实体关系图等,便于整合项目文档。
  • 跨平台与辅助功能:适用于Windows、macOS和Linux,支持深色模式、锁定形状、自由绘图以及导出为多种图像格式。

该工具专注于快速、轻松地表达创意,无需在样式和布局上耗费过多时间。

6. Kolmogorov-Arnold networks may make neural networks more understandable (www.quantamagazine.org)

本文探讨了Kolmogorov-Arnold网络(KAN)作为传统神经网络(如多层感知机MLP)的一种更可解释的替代方案。MLP虽功能强大,但决策过程如同“黑箱”,难以理解其内部原理。KAN基于20世纪中期的数学定理重新设计,其核心创新在于将边权重替换为可学习的非线性函数,从而能更精确地拟合复杂函数,并可能完美表示某些目标函数。

研究团队突破了早期认为KAN不实用的限制,通过增加网络层数(如三层或更多)显著提升了性能。在纽结理论和安德森局域化等科学问题中,KAN不仅实现了预测,还能提供解释性的数学公式,这是MLP无法做到的。KAN的优势主要体现在可解释性上,特别适用于科学发现,能够从数据中提取简洁的数学规律。

然而,KAN在计算机视觉和音频处理等方面可能不如MLP。后续工作(如KAN 2.0)致力于提升其实用性。研究者认为,KAN代表了从“应用驱动”到“好奇心驱动”的科学范式转变,有望帮助研究者深入理解现象背后的物理规律,而不仅仅是解决问题。

7. Why Oxide Chose Illumos (rfd.shared.oxide.computer)

摘要

本文阐述了Oxide公司选择基于Illumos操作系统的原因,核心在于其采用的DTrace动态检测框架,能够满足在复杂、动态的生产环境中安全高效地调试疑难软件缺陷的严苛要求。

核心挑战与需求

  • 复杂缺陷的调试:许多严重的软件缺陷难以重现,依赖于特定环境下的瞬时状态。工程师需要能在运行中的生产系统上动态地提出并精炼问题,而无需更新或重启软件。
  • 安全与无副作用:任何检测工具必须绝对安全,不能导致系统崩溃、数据损坏或明显的性能下降。在不启用时,不应影响系统。甚至应能安全地应对“意外启用所有检测”的场景。
  • 高效与精确:面对海量事件,简单的“消防水管”式数据采集(后续再过滤)不实用。检测系统需在事件发生时进行高效、安全的过滤与聚合,以最小性能开销回答具体问题。
  • 跨层可观测性:系统通常涉及用户态进程和内核模块,检测工具需要能够干净地跨越多个进程和内核边界进行测量。

DTrace vs. eBPF:关键对比

文章将Illumos(及Solaris)的DTrace与Linux的eBPF进行了详细比较,突出了DTrace的优势:

  1. 安全性与可验证性

    • DTrace:其设计核心是绝对安全。编程模型受限(如无后向分支的指令集,确保无死循环),并通过在操作点直接进行安全检查。经过十年大规模生产验证,其健壮性已被广泛信任。
    • eBPF:其安全性主要依赖于一个复杂的验证器(verifier)。验证器的实现极其复杂(约8000行内核C代码),且已发现多起严重漏洞(如CVE-2020-8835)。其既要用于高性能数据路径,又要用于追踪,设计目标存在内在冲突,增加了验证难度。
  2. 编程模型与用户体验

    • DTrace:提供直观、符合习惯的探针命名和变量访问。可以轻松启用数万个探针进行聚合,响应迅速,用户体验流畅。
    • eBPF:工具链(如bpftrace)用户体验有待改善。探针命名不直观,变量访问不便。在尝试启用大量探针时可能触发系统挂起或验证器错误输出,存在使用限制(如探针数量上限)。
  3. 资源占用与轻量性

    • DTrace:工具链二进制大小轻量(约11MB),适合在资源受限或从固定内存映像启动的环境中使用。
    • eBPF:相关工具链(如bpftrace依赖BCC、Clang、LLVM库)体积庞大(约160MB),在需要精简系统镜像的场景下成为负担。
  4. 核心功能实现

    • DTrace能轻松满足前文列出的所有检测需求,包括调度事件、定时分析、系统调用与函数追踪、进程/线程生命周期、操作延迟分布等。
    • eBPF虽然功能强大,但在追踪与性能分析这一主要使用场景中,其复杂性、验证器风险和用户体验问题,使其在安全关键的生产环境中不如DTrace可靠和易用。

结论

Oxide选择Illumos(及Solaris),根本原因是DTrace框架完美契合了他们对系统检测工具的核心要求:在动态生产环境中绝对安全高性能、且能进行精确灵活的探索性调试。DTrace经过验证的约束设计、轻量高效的实现以及卓越的用户体验,使其成为构建高可靠性基础设施的理想选择,优于在安全性、实现复杂性和用户体验方面存在妥协的eBPF方案。

8. SpaceX Astronauts Begin Spacewalk, Putting New Spacesuits to Test (www.wsj.com)
9. My business card runs Linux and Ultrix (2022) (dmitry.gr)

我的名片运行Linux和Ultrix (2022) - 内容摘要

项目概述

该项目旨在创建一个以名片形式运行的Linux和Ultrix系统,是对2012年在一个8位AVR上运行Linux的项目的重大升级。目标是提高速度、易于组装、方便连接、便宜且紧凑。

核心设计决策

零件选择

  • 存储:使用microSD卡,选用易焊接的Amphenol 1140084168卡槽。
  • 内存:选用QSPI接口的PSRAM芯片(如AP Memory、ISSI的SOIC-8封装),因为它像SRAM一样易于使用,但由芯片内部管理刷新。
  • 稳压器:MIC5317-3.3YM5TR。
  • USB连接器:采用PCB板边直接作为USB-C接口的设计(需0.8mm板厚)。
  • 微控制器:受限于市场供应和易用性要求,选择了ATSAMDA1E16(ATSAMD21系列)。它虽速度慢(超频至90MHz)且有DMA等缺陷,但易焊接、可购买。

仿真目标选择

选择仿真MIPS R2000/R3000处理器(MIPS-I指令集),原因包括:RISC架构简化指令解码、无条件码(减少计算开销)、32位、工具链成熟。系统层面仿真DECstation 2100/3100,因为其结构相对简单且受Linux支持。

仿真器实现细节

CPU仿真

  • 首先用C语言编写了可测试的模拟器,后用ARMv6-M汇编重写了核心以优化性能。
  • 实现了延迟槽、条件陷阱和原子指令等现代编译器所需的扩展。

FPU仿真

  • 初期依赖Linux内核模拟,后自行实现完整的FPU模拟器。
  • 后期还实现了“最小FPU”模式(仅支持寄存器操作和加载/存储,数学运算交由内核模拟),以节省代码空间。

MMU仿真

  • MIPS的MMU是纯软件管理的TLB(无硬件页表遍历器)。
  • 为提高效率,使用虚拟地址哈希表来存储TLB条目,加速地址转换。

通信与超调用

  • 仿真了DECstation的串行端口控制器(DC7085),通过USB虚拟出两个CDC-ACM串口。
  • 定义了超调用机制,用于PROM与模拟器交互(如获取内存映射、调试输出、SD卡读写)。

启动流程

  1. ROM启动:位于0x1fc00000的微小ROM(32字节)将SD卡第一扇区加载到内存并跳转。
  2. MBR启动:SD卡第一扇区的MBR代码寻找类型为0xBB的分区,加载其中的“PROM”到内存。
  3. 加载器:“PROM”实现代码挂载FAT分区,查找并加载名为“VMLINUX”的内核文件,然后跳转执行。
  • 内核启动参数指定使用PROM早期打印和第三串口作为控制台。

性能优化

关键优化措施

  • 指令缓存:实现了一个小型、直接映射的虚拟地址指令缓存(命中率约95%)。
  • CPU超频:将ATSAMD21超频至90MHz(原标称48MHz)。
  • 内存带宽优化
    • 使用四路并行SPI PSRAM,将32字节数据的访问时间大幅减少。
    • 实现了一个2KB的L2数据缓存(命中率约91%),极大地提升了平均内存访问速度。
  • 针对Linux的优化:对内核TLB重填处理进行了本地代码加速;避免在延迟槽指令期间触发中断。
  • 底层代码优化:将关键路径(如内存访问)重写为汇编代码。

运行效果

  • 优化后,虚拟MIPS CPU有效速度约为1.2MHz。
  • 内核启动到shell提示符约需2-3分钟,命令响应即时或只需几秒。
  • 理论上,可以在设备上用数天时间重新编译内核。

版本迭代与支持Ultrix

硬件v1.3

  • 为解决原SPI控制器的缺陷,重新布线,通过GPIO位操作(bit-banging)实现更快速的四线SPI访问。
  • 重新支持了1、2、4种不同数量的RAM芯片配置。

支持Ultrix

  • 实现了更多硬件仿真以满足Ultrix的期望:
    • SCSI控制器(SII):仿真了磁盘和CDROM设备。
    • 网络控制器(LANCE):仿真了MAC地址(ESAR)和基本初始化,但未实现实际收发。
    • 图形帧缓冲器:支持单色和8位彩色模式。
    • 输入设备:仿真了键盘、鼠标和图形输入板。
  • 对Ultrix内核进行了二进制打补丁,以绕过缓存探测问题、优化延迟函数并降低时钟中断频率。
  • 改进了加载器架构,使其模块化(可组合不同的分区表、文件系统和二进制格式支持),从而能分别引导Linux、Ultrix和NetBSD。

固件更新

  • v2.1.1:优化了内存访问速度,并在启动时显示RAM配置。
  • v2.2.0
    • 支持了新的MCU型号(ATSAMD21E17A,主频72MHz,内存16KB),并据此增大了缓存。
    • 将L2缓存代码用汇编重写以提升性能。
    • 增加了将关键函数放入RAM执行的选项以获得额外速度提升。
    • 实现了基于LED的引导加载程序,支持通过SD卡更新固件。

构建与使用

  • 硬件:提供了PCB的Gerber文件和完整的物料清单。
  • 软件:提供了源代码、内核补丁和配置、以及预编译的磁盘镜像(包含BusyBox精简系统、Debian Wheezy和混合系统)。
  • 使用:插入SD卡,通过USB-C连接至电脑,使用串口终端即可连接。
10. Be a thermostat, not a thermometer (2023) (larahogan.me)

摘要:做恒温器,而非温度计

本文探讨了工作环境中人类情绪互动的模式,并提出了通过主动调节情绪氛围(即“做恒温器”)来改善团队动态的沟通技巧。

核心观点

1. 人类极易受他人情绪影响

  • 我们会无意识地通过他人的语调、肢体语言等“氛围信号”感知情绪变化。
  • 这种本能源于生存机制,大脑(特别是杏仁核)会持续扫描环境威胁。
  • 当感知到他人情绪变化时,大脑会尝试解释原因,甚至常默认对方是针对自己。

2. 情绪镜像效应

  • 人类会本能地模仿他人的情绪状态。一个人的负面情绪会通过非语言信号传递给他人,形成连锁反应。
  • 当一个人被“杏仁核劫持”(强烈情绪控制)时,这种情绪传染更为明显。

3. “温度计”与“恒温器”的隐喻

  • 温度计:被动感知他人的情绪温度(状态)。
  • 恒温器:主动设定并调节整个环境的情绪温度。
  • 目标是从被动的“温度计”转变为主动的“恒温器”。

如何成为“恒温器”

1. 识别信号,而非盲目镜像

  • 练习观察他人日常的行为模式,当出现变化(如用词、肢体语言、音量等)时,将其视为一种“数据”或信号,而非直接镜像对方的“怪异氛围”。
  • 尝试理解其背后可能的原因(如核心需求未被满足、睡眠不足等)。

2. 有意识地重置氛围

  • 命名变化:平静地指出你观察到的氛围变化(需谨慎使用,避免让对方感到被指责)。
  • 提出开放式问题:询问对方的感受或需求,而非猜测。
  • 选择你的语调和肢体语言
    • 以平静、开放的语调交谈。
    • 使用温和的眼神接触,身体微微前倾。
    • 通过点头、细微的语调调整(如对方激动时自己更平静)来引导对话氛围。
  • 目标:通过你的语言、语调和肢体语言,为对话树立一个积极、平静的榜样。

3. 提供暂停选项

  • 如果对方情绪极度激动(处于“杏仁核劫持”状态),理性思考难以进行,可以提议暂停对话,稍后继续。
  • 使用温和、非对抗性的措辞,例如:“我需要多一点时间思考,我们明天下午两点再继续讨论好吗?”

4. 承担责任与修复关系

  • 如果你自己的行为导致了氛围的紧张或恶化,主动承担责任至关重要。
  • 使用“我学到了……;我将要……”的模板进行反思和沟通,例如:“我学到了上一封邮件没能解释清楚变更,所以我将开设一个论坛让大家提问,CEO每周二会进行解答。”
  • 这能有效修复关系,重置双方的情绪温度。

结论

成为“恒温器”是一项需要练习的技能。关键在于意识到情绪传染的循环,并有意识地选择用平静、支持性的言行来设定和调节对话的氛围,从而引导双方进入更积极、高效的沟通状态。这不仅能化解紧张,还能建立更健康、更具韧性的团队关系。

11. Hi-Tech Bifocals Improved My Eyesight but Made Me Look Like a Dork (gizmodo.com)
12. SQLite on Rails: The how and why of optimal performance (fractaledmind.github.io)

SQLite在Rails中的性能优化指南

本文详细探讨了如何在Rails应用中优化SQLite的性能,通过一系列配置和调整,使其能够满足生产环境的需求。

核心问题与挑战

开箱即用的SQLite与Rails配合时存在性能瓶颈,主要问题包括:

  1. SQLITE_BUSY异常:SQLite使用全局写锁保证一次只有一个写操作,在高并发请求下,当多个连接尝试获取写锁时会抛出此异常。
  2. 延迟问题:随着并发请求增加,p99延迟急剧上升,达到超时阈值(默认5秒)后开始出现错误。
  3. 全局VM锁(GVL)阻塞:在等待数据库锁期间,Ruby的GVL未被释放,导致其他Puma工作进程无法并发处理请求。
  4. 长尾延迟:采用指数退避策略时,“老旧查询”更容易超时,导致性能曲线尾部延迟不断增加。

优化策略与解决方案

1. 启用立即事务模式

将SQLite事务模式从默认的deferred改为immediate,使事务在开始时就尝试获取写锁,从而能够排队等待而不是立即抛出异常。配置方式如下:

# database.yml
production:
  adapter: sqlite3
  default_transaction_mode: immediate

2. 设置busy_timeout

通过配置busy_timeout,允许SQLite等待指定毫秒数来获取写锁,采用指数退避重试机制。这有助于在并发环境下序列化写操作。

3. 自定义busy_handler释放GVL

为解决GVL阻塞问题,实现一个自定义的busy_handler,在等待期间使用sleep释放GVL,允许其他线程执行。新的实现采用固定的1毫秒重试间隔,避免了指数退避对老旧查询的惩罚,显著改善了长尾延迟。

4. 启用WAL模式

使用预写式日志(WAL)模式替代默认的回滚日志模式,支持多个并发读者,但仅允许一个写者。Rails 7.1已包含更优的SQLite默认配置。

5. 分离读写连接池

创建独立的读写连接池,避免写连接池饱和时阻塞读查询。利用Rails的多数据库支持,将读写连接指向同一数据库但使用不同的连接配置:

  • 读连接池:包含多个只读连接
  • 写连接池:仅包含一个连接 通过自动角色切换,请求默认使用读连接池,仅在执行写操作时切换到写连接池。

实践工具与建议

作者开发了两个gem来简化优化过程:

  • enhanced_sqlite3_adapter:提供优化的适配器
  • isolated_connection_pools(实验性):实现分离的读写连接池

性能提升效果

经过上述优化后,应用在并发负载下:

  • 显著减少SQLITE_BUSY异常
  • p99延迟大幅改善并趋于稳定
  • 长尾延迟(p99.99)曲线变平
  • 读请求吞吐量提升

结论

虽然SQLite在Rails中需要一定配置优化,但通过启用WAL模式、设置正确的事务模式和超时、释放GVL以及分离连接池等措施,可以构建出高性能、有弹性的生产就绪应用。Rails社区提供了丰富的工具和gem支持,使其成为与SQLite配合的最佳Web框架。

13. 1913: When Hitler, Trotsky, Tito, Freud and Stalin all lived in the same place (www.bbc.com)
14. We're not going to run out of new anatomy anytime soon (svpow.com)

解剖学新发现为何永无止境

本文探讨了为何在解剖学已有数千年研究历史的今天,新的解剖结构依然不断被发现。作者指出,无论是人类、常见实验动物还是化石,仍有大量未知领域,这主要受制于人为障碍与自然界的极端复杂性。

阻碍发现的人为因素

  1. 观察受限与时间紧迫:外科医生受限于微创要求和手术时间,无暇深入探索;医学生课业繁重,解剖以完成教学任务为主;解剖教师则需将精力集中于教学而非科研。
  2. 知识孤岛效应:比较解剖学、体质人类学和临床解剖学等领域各自为政,缺乏跨学科交流,导致某些解剖学事实在不同领域存在认知盲区或错误共识。
  3. 发表门槛高:临床人员和教师工作繁忙,难以抽出大量时间进行文献回顾、高质量图像采集、论文撰写及应对繁琐的同行评审。

自然界带来的客观挑战

  1. 生物体极其复杂:全面精细的解剖需耗费数百乃至上千小时,远超常规教学或屠宰所需的时间。
  2. 解剖变异极为普遍:几乎每个个体都存在显著的解剖变异,这种“大海捞针”的现象使研究者难以区分常见的个体变异与真正的全新结构。
  3. 结构干扰与伪装:新结构常与已知组织在位置和材质上高度相似(如膝关节前外侧韧带曾被长期忽视),极易被误认为已知结构。
  4. 部分部位难以观察:如鸟类气室或脊椎神经管内部,因死后塌陷或位置隐蔽,需借助注射、CT扫描等特殊技术才能有效研究。

应对策略与基础研究的价值

尽管无法开展理想中由顶尖专家主导的大规模解剖项目,但通过保持好奇心与警觉,并依赖医学生在日常解剖中的细致观察,解剖学知识仍将随时间不断积累。

作者特别强调了基础解剖学研究的长远价值。看似冷门的纯解剖研究(如鸽子尾部解剖)往往是未来生物力学、仿生学(如无人机控制、鲨鱼皮仿生材料)及新药研发的重要基石。相比于其他大型科学项目,解剖学研究成本极低。只要研究者保持敏锐,解剖学领域的新发现将永无止境。

15. A MiniGolf game for Palm OS (ctrl-c.club)

Palm OS 迷你高尔夫游戏摘要

游戏简介

开发者耗时约两个月完成了一款名为 "Captain's MiniGolf (v0.6)" 的全新Palm OS迷你高尔夫游戏。该游戏的核心特色是允许玩家自行创建和分享关卡包,增加了游戏的可玩性和社区互动性。

主要特点

  • 关卡创建功能:玩家可以设计自定义关卡,并将关卡包导出与其他用户分享。
  • 跨平台体验:无需实体Palm设备,可通过 Cloudpilot 模拟器直接在浏览器中试玩。
  • 开源发布:游戏源代码以 GPL3 许可证公开,旨在鼓励社区继续为Palm OS开发游戏。

开发挑战与经验

为Palm OS平台编程面临诸多挑战:

  • 缺乏现代编程语言的安全机制,容易导致内存泄漏和错误。
  • 调试困难,尤其是在处理多边形形状和运动轨迹时,开发了调试版本以可视化底层逻辑。
  • 文档匮乏,开发者主要参考了《Palm OS Programmer Companion》和《Palm OS Programming Bible》两本指南,以及GitHub上其他开发者分享的旧代码。

开发动机

开发者表达了对Palm OS设备的深厚感情,赞赏其在有限资源下实现高效能的简洁设计理念。他认为,资源限制反而激发了创造性思维和优化能力,这与现代设备性能过剩、开发者较少关注代码效率的现状形成对比。

已知问题与改进计划

  • 已知Bug:球可能卡在墙壁中;包含封闭多边形墙壁的关卡背景渲染异常。
  • 计划改进:增加关卡删除/移动功能、优化关卡包共享方式、支持基于屏幕尺寸的动态分辨率调整(当前固定为160x160或高分辨率设备320x320)。

其他信息

  • 文章草稿撰写于 Palm Zire 72 设备上。
  • 开发者通过 Mastodon 账号 @rxpz@social.linux.pizza 提供联系渠道。
16. Ask HN: Does anyone use sound effects in their dev environment?
17. USPS' long-awaited new mail truck makes its debut (apnews.com)

美国邮政新一代送货车正式亮相

美国邮政期待已久的新一代送货车于8月在佐治亚州雅典市首次投入邮路使用。尽管外形设计被评价为“高大笨拙”、“鸭嘴式引擎盖”且不够美观,但该车型获得了邮递员们的普遍好评。

新旧车辆对比

  • 旧车现状:当前服役的格鲁曼送货车(1987年设计)已严重超期服役,存在诸多问题:噪音大、油耗高(每加仑仅9英里)、维护成本高、夏季车内酷热、后视镜易错位,且去年近100辆旧车发生自燃事故,危及邮递员与邮件安全。
  • 新车改进:由奥什科什防务公司生产的新车注重实用性、安全性与舒适性:
    • 空间与安全:内部空间宽敞,邮递员可站立行走;配备安全气囊、360度摄像头、盲点监测、碰撞传感器和防抱死制动系统。
    • 舒适性:首次配备空调系统,极大改善高温地区工作环境。
    • 载货能力:货舱更大,可容纳更大包裹,减少邮递员弯腰需求。

采购计划与电动化转型

新车采购进程曾面临挑战。环保组织强烈反对邮政局长路易斯·德乔伊最初以燃油车为主的采购计划,并提起诉讼。德乔伊解释,高昂的电动车成本及配套充电设施升级费用导致其难以负担。

在与拜登政府环保顾问协商后,邮政获得联邦政府30亿美元资金支持,部分用于充电设施建设。采购计划随之调整:

  • 2028年前采购106,000辆新车,包括60,000辆新一代车辆(其中45,000辆为电动)及其他21,000辆电动车。
  • 2026年起,新增采购将全部转为电动车。

环保成效与奖项

邮政局预计,通过电动车推广、优化邮路及其他措施,到2030年将碳排放量减少40%。今夏,该局因在电动化转型方面的努力荣获“总统联邦可持续发展奖”,标志着其运营、财务及政策挑战的阶段性成功。

19. The first release candidate of FreeCAD 1.0 is out (blog.freecad.org)

FreeCAD 1.0 首个候选发布版 (RC1) 核心要点

  • 发布状态:FreeCAD 1.0 的首个候选发布版(RC1)构建包已正式发布并开放下载。
  • 发布目的:旨在将测试范围扩展至更广泛的用户群体,特别是那些通常避免使用不稳定软件,但愿意测试准正式版并反馈问题的用户。此前,每周构建版早期测试者的反馈已显著提升了软件的稳定性。
  • 项目进展与目标:目前仅剩 7 个阻碍发布的严重问题(release blockers)。团队期望通过 RC 阶段的测试发现更多潜在问题,这对于确保最终交付一个高度稳定的 1.0 正式版至关重要。
  • 用户测试建议:鼓励用户下载 RC1,尽量在真实项目中进行深度和高强度测试,并将发现的任何 Bug 提交至官方的问题追踪系统(issue tracker)。
  • 开发者贡献指南:欢迎有意贡献的开发者查阅问题报告列表,挑选并修复易于解决的问题,随后提交拉取请求(Pull Request)。团队每周一召开合并会议以审查当前开放的 PR 队列,欢迎开发者加入协作。
20. NASA Pulls Off Delicate Thruster Swap, Keeping Voyager 1 Mission Alive (gizmodo.com)
21. GAZEploit: Remote keystroke inference attack by gaze estimation in VR/MR devices (www.wired.com)

GAZEploit:通过VR/MR设备的视线估计进行远程键盘输入推断攻击

研究人员发现,苹果Vision Pro混合现实头显的虚拟化身(Persona)在视频通话中会泄露用户的视线追踪数据,攻击者可远程分析这些数据推断用户输入的密码、PIN码和消息。

攻击原理

  • Vision Pro的虚拟化身在Zoom、FaceTime等应用中会实时反映用户的眼球运动。
  • 攻击者无需接触头显,仅通过分析虚拟化身的视频流即可提取两种生物特征:眼纵横比(EAR)和视线估计。

攻击方法(GAZEploit)

  1. 识别输入状态:研究人员训练了一个循环神经网络,通过分析虚拟化身的视线移动模式来判断用户是否正在打字。打字时视线会在虚拟键盘的按键间规律移动,且眨眼频率降低。
  2. 推断按键内容:通过几何计算恢复虚拟键盘的位置和尺寸,结合视线轨迹预测用户按下的按键。

实验结果

  • 在五次猜测内,对消息输入的字母预测准确率达92.1%,密码为77%,PIN码为73%,电子邮件/网址为86.1%。
  • 攻击无需预先了解用户的打字习惯或键盘设置。

安全影响与修复

  • 研究人员于2024年4月向苹果报告该漏洞,苹果在7月底发布的visionOS 1.3更新中修复了该问题:当用户使用虚拟键盘时,将停止共享虚拟化身。
  • 漏洞编号CVE-2024-40865。该攻击虽在实验室环境中演示,但理论上可能被用于窃取账户凭据。

隐私启示

  • 该研究凸显了可穿戴设备生物识别数据(如视线、步态等)可能无意中泄露敏感信息的风险。
  • 随着眼镜、XR设备等可穿戴技术日益普及,其收集的行为数据带来的隐私隐患值得关注。
22. Ergo: Erlang-inspired event driven actor framework in Go (github.com)

Ergo:基于Go语言的Erlang风格事件驱动Actor框架

核心概述

Ergo框架是将Erlang的设计理念、技术和模式在Go语言中的实现,基于Actor模型和网络透明性构建,提供一套开箱即用的组件。它显著简化了复杂分布式解决方案的开发,同时保持高性能和高可靠性。

主要特性

  • Actor模型:隔离的进程通过消息传递通信,在独立邮箱中顺序处理消息(支持四优先级队列)。支持异步消息和同步请求-响应模式。
  • 网络透明性:本地和远程Actor交互方式相同。框架使用自定义序列化协议、连接池、压缩和类型缓存,实现高效的分布式通信。
  • 监督树:分层故障恢复机制,监督者监控子进程并在失败时应用重启策略。支持多种监督类型(一对一、全部重启、剩余重启、简单一对一)和重启策略。
  • 元进程:通过专用元进程桥接阻塞I/O与Actor模型,处理TCP、UDP、端口和Web协议,不影响常规Actor消息处理。
  • 分布式系统:支持服务发现、分布式发布/订阅事件(带授权和缓冲)、远程进程生成和跨节点应用编排。
  • 即用组件:核心包含Actor、监督者、Pool和WebWorker等;扩展库提供Leader、Metrics、WebSocket、SSE元进程、Observer工具等。
  • 灵活性:可定制网络栈、证书管理、压缩、消息优先级、日志、分布式事件和元进程。支持mTLS、NAT穿越、重要消息传递和Cron调度。

性能表现

在64核处理器上:

  • 本地消息处理:超过2100万消息/秒
  • 网络消息处理:近500万消息/秒 基准测试包括内存消耗、序列化性能对比(EDF vs Protobuf vs Gob)以及跨10个节点向100万订阅者分发消息的分布式Pub/Sub测试。

开发工具

  • Observer工具:用于检查节点、网络栈、运行的应用和进程。需Go 1.20+,可通过go install ergo.tools/observer@latest安装,也可嵌入节点。
  • ergo CLI工具:命令行实用程序,快速生成基于Ergo框架的项目样板代码,简化项目创建。

Erlang支持

从v3.0.0起,Erlang网络栈支持移至单独模块,版本3.1+采用MIT许可证。

系统要求

Go 1.20.x及以上版本。

主要更新(v3.2.0)

  • 新增mTLS支持、NAT穿透支持、进程生成超时控制、zip-bomb防护
  • 新增gen.Ref方法(超时跟踪)、gen.Node方法(进程解析、同步请求、检查等)
  • 新增gen.Process方法(延迟发送、重要响应)和gen.Meta方法(响应、优先级、压缩控制)
  • 改进监督者类型实现、内部目标管理和Pub/Sub机制
  • 改进ProcessInit状态,提供更多可用方法
  • 新增优雅关闭超时和pprof标签支持
  • 文档全面重写,新增项目结构、集群构建、消息版本化等指南
  • 扩展库新增Leader actor(分布式选举)和Metrics actor(Prometheus导出器)
  • 扩展库新增SSE元进程和分布式Pub/Sub基准测试

调试支持

  • 启用Go分析器:构建时添加--tags pprof,每个Actor协程标记PID,元进程标记别名
  • 可禁用panic恢复(--tags norecover)和启用内部跟踪日志(--tags trace

商业支持

联系support@ergo.services获取更多信息。

23. Officer who ignored NYPD's 'courtesy cards' receives $175K settlement (apnews.com)

事件概述

纽约市警察 Mathew Bianchi 因拒绝遵从纽约市警察局(NYPD)的“礼貌卡”(courtesy cards)潜规则而遭到上级报复,近日与市政府达成 17.5 万美元的和解协议。该和解协议并未对“礼貌卡”的使用方式作出实质性改变。

“礼貌卡”背景与争议

“礼貌卡”通常印有 NYPD 徽章和警察工会名称,由工会发放。虽未获警察局官方认可,但长期被视为警员福利。警员常将其分发给亲友,用于逃避超速或未系安全带等轻微违章处罚,甚至被用来换取服务折扣或在 eBay 上售卖。由于其涉嫌腐败,长期受到外界审查与质疑。

诉讼起因与职场报复

Bianchi 在诉讼中指出,现任和退休警员可获取数百张此类卡片。他因坚持给出示卡片的警员亲友开具罚单而多次受到上级训斥。2022 年夏,Bianchi 给 NYPD 最高级别制服官员 Jeffrey Maddrey 的朋友开具罚单,成为事件导火索。随后,他被迅速调离交通部门,贬至夜班巡逻岗位。

和解结果与当事人现状

纽约市政府确认了和解条款,表示解决此案对各方最为有利,而 NYPD 及最大警察工会均拒绝发表评论。目前,Bianchi 已调回白班,但他表示自己的职业发展因该诉讼严重受限,各项晋升和调动申请均被主管明确拒绝。

当事人态度与影响

Bianchi 坚称“礼貌卡”制度是一种腐败形式,呼吁加强对卡片发放数量的监督,并完善对吹哨人的保护。他表示不后悔提起诉讼,拒绝在未来向潜规则妥协。其律师表示,希望 Bianchi 顶住职业风险的勇气能鼓励 NYPD 内部更多人站出来揭露不当行为。

24. Unity is cancelling the runtime fee (unity.com)

Unity取消运行时费用并调整订阅定价

经过与社区、客户及合作伙伴的深入讨论,Unity宣布立即取消针对游戏客户的运行时费用(Runtime Fee)。此调整不影响非游戏行业的客户。

核心决策与背景

Unity强调其核心使命是“让游戏开发民主化”,但认识到此使命的推进必须基于与客户的信任伙伴关系。尽管客户理解适度涨价对Unity持续投资于技术进步的必要性,但运行时收费模式因新颖且引发争议而受到批评。因此,Unity决定回归传统的基于席位的订阅模式

具体定价调整(2025年1月1日生效)

Unity Personal(个人版):

  • 继续免费使用。
  • 收入和资金上限从10万美元翻倍至20万美元
  • Unity 6发布后,游戏启动画面(Made with Unity splash screen)将变为可选。

Unity Pro(专业版):

  • 订阅价格上涨8%,至每年每席位2200美元
  • 适用于总年收入和资金超过20万美元的客户。

Unity Enterprise(企业版):

  • 订阅价格上涨25%
  • 适用于总年收入和资金超过2500万美元的客户,并可能设定最低订阅要求。
  • Unity将为这些大型客户提供定制套餐并进行一对一沟通。

未来承诺

  • Unity计划仅在年度基础上考虑任何潜在的价格上涨。
  • 若编辑器软件条款的变更对用户产生影响,用户可继续在之前同意的条款下使用当前版本软件(前提是继续使用该版本)。

此系列调整旨在确保Unity能持续投资于改善游戏开发环境,同时重建与开发者的长期合作伙伴关系。

25. I give you feedback on your blog post draft but you don't send it to me (2021) (mango.pdf.zone)

博客写作建议总结

1. 吸引读者注意力

  • 标题至关重要:标题应准确反映文章内容,避免点击诱饵;使用描述性标题来吸引目标读者。
  • 使用大量标题和子标题:便于读者快速浏览和定位感兴趣的部分;先写标题有助于规划文章结构。
  • 保持内容有趣:通过讲故事、论证观点或教学方法来维持读者兴趣,避免冗长无关的细节。
  • 段落化写作:短段落可帮助读者跳过或深入阅读,避免大段文字墙导致读者关闭页面。

2. 确保读者理解内容

  • 避免行话和首字母缩写:除非受众熟悉,否则使用通俗语言解释概念;例如,用“保存供以后使用”代替“缓存”。
  • 使用图片或图表:视觉元素能更直观地传达信息,如地图或示意图,比纯文字更易理解。
  • 多举例子:具体例子能帮助读者理解抽象概念;例如,用例句解释介词比定义更有效。
  • 文章开头添加摘要:简要说明文章目标和受众,让读者快速决定是否继续阅读。
  • 直接表达观点:避免模糊语言,用口语化风格写作;可以大声朗读来检查流畅性。
  • 编辑和寻求反馈:至少编辑一次,删除不必要内容;让他人审阅以确保清晰、准确和连贯性。

3. 发布内容

  • 克服犹豫:发布是博客写作的关键一步;即使不完美,也应鼓励作者点击发布按钮。
  • 后期思考:决定写什么时,考虑受众是谁、发布原因(如分享知识、讲故事或娱乐),并避免只为“曝光”或广告目的发布。

整体建议

  • 博客写作的核心是让读者注意、理解并享受内容;通过优化结构、清晰度和吸引力,作者可以提升文章质量并增加发布信心。
26. Algorithmic Wage Discrimination (2023) (columbialawreview.org)

算法工资歧视

本文探讨了数据提取与处理技术的进步所引发的工作场所监控与隐私担忧,并指出其对低收入及少数族裔劳动力产生了更为深远却常被忽视的影响:这些技术正从根本上改变劳动体验,破坏经济稳定性和工作流动性。基于一项针对按需劳动者组织的多年民族志研究,文章分析了信息资本主义逻辑下工资计算、协调与分配方式的历史性断裂,即利用细粒度数据产生不可预测、可变且个性化的小时工资。

文章构建了一个新框架,以理解数字化可变薪酬实践的兴起,或从消费者场景移植到劳动场景的价格歧视——即算法工资歧视。这种实践涉及不透明操作,对工作的性质及其监管提出了根本性质疑:平台工作中的劳动报酬何为公平?算法工资歧视如何影响工作体验?法律应如何干预?

算法工资歧视违背了长期以来关于工资设定公平性的先例以及同工同酬法律的精神。对劳动者而言,这些做法对工作和报酬产生了令人不安的道德预期。文章提议对此类实践实施不可放弃的限制

背景与案例

  • 工作场所的技术监控已导致雇佣决策、行为影响、生产力提升甚至工资确定的自动化。
  • 现有政策关注主要围绕工人隐私、自主权、算法歧视及透明度,如美国《人工智能权利法案蓝图》倡导的安全、防歧视、数据控制等原则。
  • 以亚马逊配送服务为例:亚马逊通过其控制的配送服务提供商雇用司机,利用AI摄像头等监控工具和算法化的“评分卡”来决定“奖金”,实则将工资与不可预测的绩效指标挂钩。司机面临因系统误判而无法获得奖金的风险,且缺乏传统雇佣保障(如工伤赔偿、失业保险、最低工资保证等)。该案例揭示了算法工资歧视的核心——利用数据提取和数字化控制实现劳动力管理并规避雇佣法义务

算法工资歧视的定义与特征

  • 算法工资歧视:指企业使用不断变化的公式,基于地理位置、个体行为、需求供应等细粒度数据,为从事类似工作的个体工人计算不同的小时工资。这不仅包括完成工作的数字化报酬,更关键的是决定工作分配的数字化决策,这直接影响小时工资并成为企业控制的杠杆。
  • 与传统绩效工资不同,算法工资歧视源于信息资本主义,类似于消费者领域的“价格歧视”,旨在根据系统判定工人可能接受的最低水平支付报酬。
  • 其后果是:从事相同工作、具备相同技能、为同一家公司、在同一时间的工人可能获得不同的小时工资;工资由晦涩复杂的系统决定,工人难以预测或理解其持续变化且常下降的收入。

对劳动法与道德的挑战

  • 美国劳动监管在合同制度和管理优先权下,建立了最低工资法和反歧视法作为工资的道德基础,要求基于时间的工资底线和同工同酬。
  • 算法工资歧视侵蚀了这些文化及法律对公平报酬的期待。研究显示,尽管按需劳动者因渴望摆脱固定时间表的福特主义模式而被吸引,他们仍主要以小时工资概念来理解劳动。算法管理下的报酬体验则充满了不透明、欺骗与操纵
  • 经济上高度依赖此类收入的工人,常将算法工资歧视的经历比作赌博。考虑到按需劳动力主要由移民和少数族裔构成,这种有害的经济影响也必然具有种族化特征。

应对与局限

  • 劳动者及倡导者尝试利用数据隐私法(如欧盟GDPR及加州类似法律)来主张对数据及算法的权利,或创建数据合作社以增强透明度并主张对工作中收集数据的所有权。
  • 然而,文章认为,机器学习技术的不断变化及工作场所不对称的权力关系,削弱了这些透明度尝试的效果,可能无法减轻算法工资歧视的客观或主观危害。

结论与建议

  • 尽管文章聚焦于“按需”或“零工”行业中被视为“独立承包商”且缺乏保护的工人,但算法工资歧视的意义并不限于此。该实践已开始渗透至医疗、工程等行业,影响护理员、护士等职业的薪酬。
  • 如果不加以解决,它将在其他就业领域(包括零售、餐饮、计算机科学)继续被正常化,为低薪工作建立新的报酬文化规范
  • 因此,文章提议采取直接应对危害的方法:一项结构严谨、不可放弃的强制性禁令,以禁止此类实践。
29. How to Spot NASA's Solar Sail Demonstration Streaking Through the Night Sky (www.smithsonianmag.com)

如何观测NASA太阳帆演示卫星划过夜空

ACS3卫星基本概况

  • 发射与部署:NASA于2024年4月23日将名为“先进复合太阳帆系统”(ACS3)的设备送入近地轨道,其尺寸如微波炉大小,展开后帆面面积达860平方英尺(约80平方米),由四片超薄反射材料组成。
  • 当前状态:ACS3在发射初期曾经历一次失败的展开尝试,但于2024年8月底成功部署帆骨并完全展开帆面,目前运行在地球轨道上。

观测方法与亮度特征

  • 观测工具:NASA免费手机应用(适用于iOS和Android)已更新功能,可提供ACS3的本地可见时间表,并使用增强现实技术引导用户定位卫星。
  • 亮度表现:ACS3的反射帆面有时可达到与夜空中最亮的恒星“天狼星”相当的亮度。观测者报告称,当卫星经过织女星附近时,亮度曾短暂接近织女星(全天第五亮星)。

亮度变化的原因

  • 科学解释:观测者发现ACS3亮度周期性变化,表明卫星正在缓慢翻滚或摆动(变化周期约数分钟)。
  • NASA说明:该现象是因卫星在展开帆骨和帆面前按计划关闭了姿态控制系统(用于定向)所致。任务团队完成帆骨与帆面特性分析后,将重新启动姿态控制以稳定卫星。

太阳帆技术原理与优势

  • 工作原理:类似传统风帆,但利用阳光光子撞击帆面产生的动量推进,无需燃料。
  • 技术优势
    • 结构相对简单,无需昂贵沉重的推进剂。
    • 理论上可达到比现有航天器更高的速度。
    • 适合长期深空任务,成本较低。

未来计划

  • NASA将持续收集ACS3数据,评估其机动性能,并为未来太空任务扩大太阳帆技术应用规模进行验证。
30. The Minneapolis Street Grid: Explained (streets.mn)

明尼阿波利斯街道网格解析

明尼阿波利斯的街道布局基于密西西比河和赫宁大道等主要路线,形成了独特的方向性命名系统和编号规则。

基本划分原则

  • 密西西比河:是划分方向后缀的基础。河东区域使用 东北(NE)东南(SE) 后缀;河西区域使用 北(N)南(S) 后缀(隐含“西”为默认方向)。
  • 赫宁大道:在河东划分东北与东南区;在河西划分北与南区(直至与I-94交汇处)。
  • I-94以西:南北区的分界线由范怀特纪念大道、巴塞特溪和切斯特纳特大道共同构成。

街道(Streets)的走向与编号

  • 编号起源:大多数编号街道以市中心附近的密西西比河为起点。
  • 市中心:街道呈西北-东南走向,与河流平行,编号向南递增(如南部编号可达50s-60s)。
  • 北明尼阿波利斯:街道呈南北走向,从第一街北开始编号,第六街北后变为大道。
  • 东北明尼阿波利斯:街道呈南北走向,第一至第七街东北为编号街道,之后的街道按美国总统顺序命名(如华盛顿街东北、德拉诺街东北)。百老汇街以南,街道呈东西走向。
  • 东南明尼阿波利斯(如马西-霍姆斯区):街道呈西北-东南走向。

大道(Avenues)的走向与编号

  • 编号起源:以市中心的赫宁大道为起点;河东则以赫宁大道东为起点。
  • 市中心:大道呈东北-西南走向。
  • 南明尼阿波利斯(市中心以南):大道呈南北走向,西林代尔大道西的大道按字母顺序命名(如奥尔德里奇大道南、布莱恩特大道南等)。
  • 北明尼阿波利斯:编号大道呈东西走向,命名大道则为南北走向,延续南区的字母顺序。
  • 东北明尼阿波利斯:大道呈东西走向。
  • 展望公园:大道呈曲线形,以地形为导向命名(如莎朗大道东南)。
  • 大学园区:大部分道路不称为“大道”。

命名中的特殊情况

  • 方向后缀的一致性:在北、东北、东南区,同一交叉口的街道和大道可能共享相同的方向后缀(如第四大道东南与第四街东南),造成混淆。
  • 南明尼阿波利斯(市中心以南):大道保持“S”后缀,而街道则使用“E”或“W”后缀,以尼科莱特大道为东西分界线。
  • 无方向后缀的大道:存在于阿普顿区(如皮尔斯伯里大道)、市中心(如拉萨尔大道)及公园道路(如湖哈里特公园道)等区域。

例外与未解问题

  • 富兰克林大道:作为南区唯一的东西向大道,其走向与街道一致,原因不明。
  • 阿普顿区无方向后缀的大道群:其形成背景未得到解释。
  • 文章作者指出,以上解析基于观察,仍存在例外和未解答的细节问题。
31. Reader-LM: Small Language Models for Cleaning and Converting HTML to Markdown (jina.ai)
32. Mistral releases Pixtral 12B, its first multimodal model (techcrunch.com)

Mistral发布首个多模态模型Pixtral 12B

法国AI初创公司Mistral发布了其首个能够同时处理图像和文本的多模态模型——Pixtral 12B。

  • 模型概况:Pixtral 12B是一个拥有120亿参数、大小约24GB的模型。参数量大致对应模型的解决问题能力,通常参数越多,模型表现越好。
  • 功能特点:该模型基于Mistral的文本模型Nemo 12B构建,能够处理任意数量和大小的图像(通过URL或base64编码输入),并回答相关问题。理论上,它可以执行图像描述、计数物体等任务,功能类似于Anthropic的Claude系列和OpenAI的GPT-4o等其他多模态模型。
  • 获取与使用:模型已在GitHub和Hugging Face平台上通过种子链接提供下载,采用Apache 2.0许可证,允许用户无限制地下载、微调和使用。发布时暂无可用的网页演示,但Mistral开发者关系负责人Sophia Yang在X平台表示,该模型很快将通过公司的聊天机器人平台Le Chat和API服务平台Le Plateforme提供测试。
  • 训练数据背景:文章指出,不清楚Mistral用于训练Pixtral 12B的具体图像数据。许多生成式AI模型使用从网络上抓取的公开数据进行训练,这常涉及版权问题。部分供应商主张这属于“合理使用”,但众多版权持有者不同意,并已对OpenAI等公司提起诉讼。
  • 公司背景:Pixtral 12B的发布紧随Mistral完成由General Catalyst领投的6.45亿美元融资之后,该轮融资后公司估值达60亿美元。成立仅一年多的Mistral(微软持有少数股权)被许多人视为欧洲的OpenAI。其策略是发布免费的“开放”模型,通过提供这些模型的托管版本和企业咨询服务来盈利。
  • 许可证澄清:文章更新说明澄清,Pixtral 12B是在Apache 2.0许可证下提供的,而非Mistral通常对商业用途有限制的标准开发者许可证。
33. Show HN: How much is 13B euros? (howmuchis13billioneuros.com)

文章摘要

本文通过一系列“背后信封计算”来可视化130亿欧元(13B euros)的规模,将其转换为具体项目或物品的数量,以帮助理解这一金额的意义。计算基于爱尔兰的上下文,并以交互式方式呈现。

主要计算示例:

  • 国家儿童医院:可用于建造若干所国家儿童医院。
  • 自行车棚:假设每个自行车棚可停放一定数量自行车,130亿欧元可建造多个棚并容纳大量自行车。
  • 一次性礼物:可为爱尔兰每人提供多份礼物。
  • 房屋:可全额资助一定数量的房屋,按平均居住人数计算,足以覆盖爱尔兰人口的大部分。
  • 音乐会门票:可为爱尔兰每人购买多张Oasis乐队门票,甚至需要乐队在克罗克公园举行多场满容量演出来兑现。
  • 热泵补助金:可提供大量热泵补助金。

背景与上下文:

  • 文章指出,130亿欧元相当于爱尔兰2023年总支出的一部分,并占其国家债务的一定比例,强调其相对规模。
  • 计算使用calculang语言构建,这是一种专为结构化、灵活和易交流的数值计算设计的语言。用户可通过拖动数字(“可擦洗数字”)交互式修改公式,实现动态探索。

灵感与工具:

  • 交互设计受到Bret Victor工作的影响,特别是其关于模型驱动辩论的气候论文,提倡通过交互式模型促进讨论。
  • 作者Declan强调这是一个匆忙的练习,提醒用户不要将这些数字用于真实决策,仅供示意和教育目的。

总之,文章通过具体、可交互的例子,使抽象的大额资金变得直观易懂,并展示了计算语言在沟通复杂数据时的潜力。

34. If I could dissect a sauropod (svpow.com)

文章讨论了若有机会解剖泰坦巨龙(titanosaur)尸体时,作者马修·韦德尔(Matt Wedel)会优先检查的部位及其原因。以下是内容摘要:

核心关注点:肺/气囊系统
作者首选解剖蜥脚类恐龙的肺/气囊系统及其憩室,主要原因包括:

  1. 验证研究推论:作者花费近25年通过骨骼含气性模式推断蜥脚类呼吸系统,解剖可验证这些推论的准确性。
  2. 鸟类可能非进化顶峰:现存鸟类的呼吸系统未必代表蜥臀类进化的最佳状态,因为鸟类在K-Pg大灭绝中幸存主要因体型小,而非呼吸效率。作者推测其他恐龙可能发展出不同的气囊系统多样性。
  3. 泰坦巨龙的特殊性:泰坦巨龙在形态、多样性、地理分布和生长速率上表现突出,可能具备更极端或独特的呼吸适应。

具体解剖选择

  • 首选物种:拉佩托龙(Rapetosaurus),因其快速生长、高度含气的脊柱、奇特身体比例以及扩展的神经中枢关节等特征。
  • 其他候选:若解剖多个物种,作者列出前五名选择:
    1. BYU 9024标本(可能为超龙或巴洛龙,用于研究分类和体型)。
    2. 斯诺玛斯哈普洛龙(Snowmass Haplocanthosaurus),关注其尾部特殊结构。
    3. 蜀龙或新疆巨龙,代表非新蜥脚类的特化类群。
    4. 波塞东龙(Sauroposeidon),出于情感原因。
    5. 更基底蜥脚类如伊森龙或黑山龙,探索早期演化特征。

后续检查系统
在呼吸系统之后,作者会依次关注:

  • 脊髓及相关神经管特征。
  • 椎间关节。
  • 消化和生殖系统(虽在骨骼中痕迹少)。
  • 原生羽毛可能性(可通过外观检查,无需解剖)。

补充说明
文章提及《Inside Nature's Giants》电视节目作为现实解剖参考,并强调蜥脚类呼吸系统与鸟类的异同,如肋骨角度差异表明通风方式多样。作者通过化石证据推断气囊系统与鸟类基本相似,但具体运作可能不同。

35. Old Easter Island genomes show no sign of a population collapse (arstechnica.com)

旧复活节岛基因组研究显示无种群崩溃迹象

研究背景与目的

复活节岛(拉帕努伊岛)是世界上最偏远的有人居住岛屿之一,以巨型摩艾石像闻名。历史上,关于岛上人口来源(如是否来自南美)和生态崩溃是否导致种群减少的争论持续已久。本研究通过分析15具早于欧洲接触时期的原住民遗骸基因组,旨在解答这些争议。

关键发现

  1. 波利尼西亚起源确认:所有15个基因组均显示波利尼西亚起源,与现代复活节岛居民亲缘关系最近,否定了南美直接定居的假说。
  2. 美洲原住民DNA存在:约10%的基因组片段源于美洲原住民,这是波利尼西亚人群中观测到的最高比例。DNA片段大小分析表明,该基因流入时间约为1246年至1425年,与岛上定居时间(约1250年)吻合,可能源于波利尼西亚人与南美中部安第斯地区人口的早期接触。
  3. 无种群崩溃证据:基因组分析显示,岛上人口在定居后缓慢稳定增长,未出现与生态崩溃相关的遗传瓶颈。有效种群规模从未超过1,000,与欧洲人到来时估计的3,000总人口一致。数据不支持第二次瓶颈(如生态灾难)的模型。
  4. 欧洲接触前身份:尽管碳测年因记录问题出现矛盾(部分日期晚于欧洲接触),但基因组中欧洲血统不足1%,证实这些个体生活在欧洲人到达之前。

研究方法与数据

  • 遗骸来自法国国家自然历史博物馆,研究人员与拉帕努伊社区(如拉帕努伊发展委员会)合作,公开讨论研究目标,获得支持。
  • 基因组比较证实遗骸原产于复活节岛,为回归原籍工作提供科学依据。
  • 通过“同源性片段”分析推断历史种群大小,并与当代原住民基因组对比,建立人口扩张模型。

结论与意义

  • 研究明确解决了复活节岛历史的两大争议:人口起源于波利尼西亚扩张,且无生态崩溃导致的种群减少。
  • 美洲原住民基因流入时间与定居时间相近,暗示早期跨太平洋接触的可能性,但具体机制(如贸易或迁徙)需进一步探究。
  • 主要不确定性在于遗骸的精确生活年代,未来需更准确的测年技术或更多样本以完善时间线。

来源:Nature, 2024. DOI: 10.1038/s41586-024-07881-4

37. Remix's concurrent submissions are fundamentally flawed (dashbit.co)

Remix并发提交的根本缺陷

核心论点

作者认为Remix框架的提交-重新验证机制存在设计缺陷,其声称的并发提交安全保证在大多数应用中无法可靠实现,可能导致数据竞态条件和UI不一致。

主要问题分析

1. 双次往返延迟

  • 每次表单提交或数据变更需要两次服务器请求(提交操作 + 数据重新加载)
  • 即使如ChatGPT等不需要无JavaScript支持的应用也承担此开销
  • 缓存收益不足以抵消额外延迟成本

2. 并发提交的竞态条件

  • 关键错误假设:先完成重新验证的请求包含较早版本的数据
  • 实际数据库交互顺序不确定,导致:
    • 后续请求可能读取到比先前请求更新的数据
    • UI可能暂时显示已删除的数据(如表格行反复出现和消失)
  • 无法保证提交在服务器端的处理顺序,可能导致过期数据被持久化

3. 单次请求方案同样有问题

  • 虽然减少为单次请求,但加剧数据陈旧问题
  • 无法保证哪个提交读取到最新数据库状态
  • PostgreSQL等数据库不保证事务按启动顺序提交

4. 取消请求的风险

  • 只有幂等操作可安全取消,但框架默认此假设过高
  • 被取消的请求仍可能到达服务器并延迟处理
  • 可能导致用户立即看到过期数据(如订单项数量错误)

解决方案探讨

方案一:因果顺序

  • 提交需携带对前序提交的依赖信息
  • 服务器确保按逻辑顺序处理,客户端可忽略乱序响应
  • 局限:需要粘性会话或数据库锁,增加复杂性

方案二:持久连接(Phoenix LiveView方式)

  • 使用WebSocket保持连接,保证事件顺序处理
  • LiveView的长轮询实现通过Erlang分布式特性保持会话一致性
  • 优势:~450行代码实现可靠状态同步

作者观点

  • Remix未能兑现其文档中关于防止竞态条件的承诺
  • 框架应默认提供数据一致性保障,而非依赖应用层补偿
  • 提出因果顺序或持久连接作为改进方向

技术启示

  • 基于服务器状态驱动UI时,并发处理是主要挑战
  • 分布式系统中网络延迟和事件循环会影响请求处理顺序
  • 框架设计应避免在基础机制中引入难以解决的竞态条件