2024-07-02

36 篇热帖

1. Why is Chile so long? (unchartedterritories.tomaspueyo.com)

智利拥有惊人的地理长度,堪比美国与加拿大的总和,或横跨从挪威到摩洛哥的欧洲距离。其超长且狭窄的形状主要由安第斯山脉决定,该山脉是纳斯卡板块与南美洲板块碰撞形成,构成了智利东侧的天然屏障,使其成为海岸与山脉之间的一条狭长地带。

智利的长度也意味着拥有多样化的气候。然而,其南北两端并不适合大规模人口居住:南部过于寒冷,北部(阿塔卡马沙漠)则极度干旱。因此,大多数智利人居住在气候温和的中部地带。

北部干旱地区因富含鸟粪和硝石(曾为重要化肥和火药原料)等资源,在19世纪引发争夺,智利在太平洋战争中战胜秘鲁和玻利维亚,获得了该地区的控制权。

这种极端的地理隔离——西临太平洋,东靠安第斯山脉,南接冰原,北邻沙漠——也深刻影响了智利的文化。它使得智利的西班牙语与其他西语国家差异显著,被描述为“难以理解”,主要原因包括与西班牙本土距离最远、地理孤立导致交流有限、历史上并非帝国核心区域,以及受到了德国、意大利等移民语言的影响。

为什么没有其他国家像智利如此狭长?文章指出,这需要同时满足几个地理条件:位于海洋板块与大陆板块俯冲带之间、呈南北走向、远离赤道以保证气候显著变化、且人口不过度密集。在环太平洋地区,类似条件仅在南美洲西海岸形成了智利这样的狭长国家,其他地区(如北美西海岸或西太平洋岛屿)因地质结构、历史进程(如快速征服或殖民整合)不同,未能形成类似的独立实体。

2. Supreme Court rules ex-presidents have immunity for official acts (apnews.com)

最高法院裁定前总统对官方行为享有豁免权

美国最高法院于周一作出历史性裁决,首次明确前总统对其在任期间的“官方行为”享有广泛的刑事起诉豁免权。这一裁决以6比3的保守派多数通过(包括特朗普任命的三位大法官),实质上进一步推迟了针对前总统唐纳德·特朗普的华盛顿刑事案件审判,并基本排除了在11月大选前对其进行审判的可能性。

裁决核心内容:

  • 分类豁免: 首席大法官约翰·罗伯茨代表多数意见撰文指出,前总统对其“在其决定性的、排他性的宪法权力范围内的行为”享有“绝对豁免权”。对于所有其他“官方行为”,至少享有“推定豁免权”。而对于“非官方行为”,则不享有任何豁免权。
  • 案件具体影响:
    • 特朗普被指控与司法部讨论以推翻选举结果的相关行为,被认定享有绝对豁免。
    • 特朗普被指控向时任副总统迈克·彭斯施压,要求其拒绝认证选举结果的行为,被认定至少享有推定豁免权。但检察官可以尝试论证这部分行为仍可纳入案件。
    • 对于指控中涉及“假选举人”计划的部分,法院要求下级法院进行进一步的事实认定,以确定该行为是否属于官方行为。
    • 裁决进一步限制了检察官:禁止他们在起诉总统的非官方行为时,将任何官方行为作为证据使用(例如,不能在起诉受贿案中提及总统做出的官方任命)。

各方反应:

  • 特朗普 在社交媒体上称此为“对我们宪法和民主的巨大胜利”。
  • 拜登总统 表示,该裁决开创了“一个危险的先例”,并认为这实际上意味着“对总统可以做什么几乎没有任何限制”。
  • 异议意见: 大法官索尼娅·索托马约尔代表法院三位自由派大法官发表强烈的反对意见,称该裁决“嘲弄了无人可以凌驾于法律之上的基本原则”,使总统“在使用每一项官方权力时,都成为凌驾于法律之上的国王”。
  • 国会与法律界: 参议院多数党领袖查克·舒默称裁决“可耻”,并损害了最高法院的信誉。法律专家对豁免范围的广泛性表示担忧,认为这可能为未来寻求留任的总统提供“路线图”。

后续发展:

  • 具体的审判安排将交由地区法官坦尼亚·丘特坎处理。
  • 然而,分析普遍认为,鉴于复杂的法律程序,该案件几乎不可能在大选前开庭。
  • 如果特朗普未能赢得2024年大选,他可能将在大选后受审。若他赢得大选,则可能任命司法部长撤销此案,甚至可能尝试自我赦免(但无法赦免纽约州法院的定罪)。
  • 该裁决是最高法院本季的最后判决,自听证以来已过去两个多月。特朗普否认所有不当行为,并称相关起诉出于政治动机。

背景与争议:

  • 特朗普仍面临其他多项联邦和州指控,包括佛罗里达州的机密文件案和佐治亚州的相关案件。
  • 本案审理时,最高法院包括特朗普任命的三位大法官(戈萨奇、卡瓦诺、巴雷特),以及两位因潜在利益冲突问题受到关注而未回避的大法官(托马斯和阿利托)。
3. Ladybird Web Browser becomes a non-profit with $1M from GitHub Founder (lunduke.locals.com)

GitHub创始人Chris Wanstrath与SerenityOS及Ladybird浏览器创始人Andreas Kling合作成立了“The Ladybird Browser Initiative”,这是一个专注于从头构建全新网页浏览器的美国非营利组织。该组织已获得100万美元资助,目标是在2026年准备好全功能的“Alpha”版本。

当前主流浏览器引擎均受Google广告体系资助(如Chrome、Edge、Brave使用Chromium;Safari与Firefox也与Google有财务协议)。Ladybird旨在成为唯一不将用户作为“产品”的浏览器,完全依靠赞助和无限制捐赠运营,拒绝企业交易或广告收入,并明确不出售董事会席位以保持独立。

目前Ladybird已拥有4名全职开发者,另有3名即将加入。尽管正式发布尚需时日,但当前开发版本已能处理部分日常浏览(如GitHub操作、Hacker News评论)。团队强调专注于浏览器本身,不追逐技术潮流或替代收入来源,致力于构建一个免费、独立的网页浏览器。

4. Welcome to Ladybird, a truly independent web browser (ladybird.org)

Ladybird 浏览器项目介绍

项目定义
Ladybird 是一个从零开始构建的全新浏览器引擎,并非基于现有引擎(如 Blink、WebKit、Gecko)的分支。它由一个 501(c)(3) 非营利组织支持,致力于创建一个真正独立、无用户变现(如默认搜索引擎协议、加密代币等)的网络浏览器。

核心特点

  • 真正独立:基于网络标准全新开发,避免利益冲突。
  • 专注单一目标:专注于构建浏览器,无其他商业化分散。
  • 无用户变现:不通过数据收集、广告或搜索交易盈利。

开发状态与目标

  • 当前处于积极开发阶段。
  • 目标是在 2026 年 发布首个 Alpha 版本,初期支持 Linux 和 macOS,面向开发者和早期用户。
  • Windows 平台支持已列入计划,将在后续阶段实现;移动端(Android/iOS)待桌面版本稳定后再推进。

技术进展(截至 2026 年 6 月)

  • 采用 Rust 语言作为 C++ 的后续语言,逐步移植子系统。
  • 重要功能更新包括:
    • 通过 Cloudflare Turnstile 验证
    • 异步滚动、媒体源扩展、WebAssembly JIT
    • 原生内容拦截、HTML 解析器迁移至 Rust
    • CSS 容器查询、子网格、锚点定位等新特性支持
    • 性能优化(如 YouTube、Reddit 场景)

开源与社区参与

  • 项目开源,代码托管在 GitHub(LadybirdBrowser/ladybird)。
  • 鼓励社区通过提交 Bug 报告、测试网站、提供技术反馈等方式参与。
  • 开发社区通过 Discord 交流。

资金支持

  • 完全依赖捐赠和赞助,无商业广告或数据收集。
  • 赞助分为五个级别:铂金($100,000)、金($50,000)、银($10,000)、铜($5,000)、铜($1,000),赞助期一年。
  • 个人可通过 Donorbox 进行一次性或月度捐赠。

常见问题摘要

  1. 发布计划:2026 年发布 Linux/macOS 的 Alpha 版本。
  2. 团队规模:目前由小型全职工程团队开发,依靠社区协作。
  3. 独立性保障:赞助为无条件捐赠,赞助方不影响技术方向或产品路线。
  4. 跨平台支持:Windows 支持已进入测试阶段,移动端为远期目标。
  5. 技术栈演进:初始基于 C++,现已引入 Rust 并逐步迁移。
6. With fifth busy beaver, researchers approach computation's limits (www.quantamagazine.org)

第五个忙碌海狸数:计算极限的突破

经过数十年的探索,一个由程序员和研究者组成的国际合作团队成功证明了“忙碌海狸数” BB(5) 的精确值为 47,176,870。这项成果标志着人类在理解计算的固有极限方面达到了一个新的里程碑。

背景:什么是忙碌海狸游戏?

  • 起源:该游戏由数学家蒂博尔·拉多于1962年提出,旨在将图灵机的停机问题简化为一个更易理解的数论问题。
  • 规则:给定一组具有固定规则数(n)的图灵机,从一个全为空白带开始运行。其中必然存在一个机器,在最终停止前运行的步骤数最多。这个最大步骤数就是忙碌海狸数 BB(n)。
  • 核心挑战:确定 BB(n) 不仅需要找到运行时间最长的停机机器,还必须证明所有其他未停机的机器将永远运行(不会停止)。后者等价于解决特定图灵机的停机问题,这是一个在一般情况下已被证明不可判定的问题。

漫长的探索历程

  • 早期成果:BB(1)、BB(2) 和 BB(3) 较早被确定。1974年,艾伦·布雷迪经过长期努力,最终证明了 BB(4) = 107。
  • BB(5) 的征途:1989年,研究者海纳·马克思和于尔根·邦特洛克发现了一个运行 47,176,870 步后才停止的5规则图灵机,这成为了第五个忙碌海狸数的有力候选。然而,证明没有其他5规则机器运行时间更长且所有剩余机器均永不停止,成了困扰数学界30多年的难题。
  • 个人与团体的努力:多年来,研究者如乔治·伊万诺夫·格奥尔基耶夫(网名“Skelet”)曾取得部分进展,将未解决的机器缩减到43台,但个人能力的极限使问题难以完全攻克。

协作革命与最终突破

  • 忙碌海狸挑战:2020年左右,研究生特里斯坦·斯特林发起了“忙碌海狸挑战”项目,通过在线论坛和Discord平台,汇集了全球超过20名贡献者(包括专业学者和业余爱好者),以协作方式攻克难题。
  • 关键技术与证明方法
    1. 系统化筛选:运用布雷迪的“家族树”方法等计算机程序,系统性地模拟和排除了大量冗余或已知会停止的机器。
    2. 分析永动机:对于剩余的数千万台机器,团队运用了包括“封闭磁带语言”在内的多种数学和计算技术,分析其模式,以证明它们将无限运行。
    3. 形式化验证:为了确保证明的绝对严谨性,团队采用了Coq证明助手。这是一种允许以代码形式编写和验证数学证明的软件,可以消除人为推导错误。
  • 攻克“怪物”机器:在剩余的机器中,被称为“Skelet #1”和“Skelet #17”的两台机器行为异常复杂。经过团队成员(如肖恩·利戈基、帕维尔·克罗皮茨、克里斯·徐等)分别攻破后,最终由一位名为 mxdys 的神秘贡献者,将所有结果整合成一个约40,000行的Coq证明文件。

结果与意义

  • 确证:Coq证明确认,马克思和邦特洛克在30多年前发现的、运行47,176,870步的图灵机,确实是第五个忙碌海狸。
  • 科学与协作的胜利:该项目不仅解决了一个长期的数学难题,更展示了现代在线协作和形式化验证工具在复杂研究中的巨大潜力。它吸引了来自不同背景的人才,体现了“业余数学爱好者”的贡献价值。
  • 未来的边界:在庆祝成功的同时,团队已开始探索 BB(6)。然而,他们发现一个6规则图灵机的停机问题与数学中著名的考拉兹猜想相关,这暗示解决 BB(6) 可能需要数学理论上的根本性突破。这使得 BB(5) 有可能成为人类已知的最后一个忙碌海狸数。

总而言之,第五个忙碌海狸数的确定,是一个融合了历史传承、个人才华、集体智慧以及形式化验证技术的科学故事,它深刻揭示了确定性计算过程中所能隐藏的复杂性与不可预测性。

7. Show HN: Doggo – A powerful, human-friendly DNS client for the command line (doggo.mrkaran.dev)

Doggo:强大且对人类友好的命令行 DNS 客户端

项目简介

Doggo 是一款功能强大且对用户友好的命令行 DNS 客户端,旨在提供高效、灵活的 DNS 查询体验,并全面支持跨平台使用。

核心功能与特性

输出与交互体验

  • 人类可读输出:提供彩色编码和表格格式的输出,同时支持 JSON 格式以便于脚本编写和数据解析。
  • Web 界面:提供在线 Web 界面(doggo.mrkaran.dev)供用户使用。
  • 命令行增强:支持 zsh 和 fish 的 Shell 自动补全,并内置调试模式以方便故障排除。

协议与网络安全

  • 多传输协议:全面支持 DNS over HTTPS (DoH)、DNS over TLS (DoT)、DNS over QUIC (DoQ)、TCP、UDP 以及 DNSCrypt。
  • 网络层支持:同时支持 IPv4 和 IPv6。
  • EDNS 扩展支持:包括 EDNS 客户端子网 (ECS) 用于地理位置感知响应、名称服务器标识符 (NSID)、增强安全性的 DNS Cookies、保护隐私的 EDNS 填充 (Padding) 以及扩展 DNS 错误 (EDE)。

查询与解析能力

  • 多解析器支持:允许配置多个解析器,并提供可定制的查询策略。
  • 配置兼容:支持从 resolv.conf 文件或命令行参数中读取 ndotssearch 配置。
  • 高级查询选项:支持反向 DNS 查找、国际化域名 (IDN) 的自动 punycode 转换、附加部分(如 glue records 等补充数据)支持,以及灵活的 DNS 标志设置(如 AA, AD, CD, DO 等)。
  • 性能监测:内置 DNS 响应时间测量功能。

跨平台兼容性

  • 支持在多种操作系统上运行,包括 Linux、macOS、Windows、FreeBSD 和 NetBSD。

开源与支持

Doggo 是一个开源项目。开发者鼓励用户通过 GitHub Sponsors 成为赞助者,以支持该项目的持续开发与维护,并共同促进惠及整个社区的免费开源软件生态的建设。

8. GraphRAG is now on GitHub (www.microsoft.com)

GraphRAG 现已在 GitHub 上开源

GraphRAG 是一种基于图的检索增强生成(RAG)方法,旨在对私有或未知数据集进行高效问答。该方法现已在 GitHub 上开源,并提供配套的 Azure 解决方案加速器,支持无代码快速部署。

核心技术与特点

GraphRAG 利用大语言模型(LLM)自动从文本集合中提取丰富的知识图谱。其关键特性包括:

  • 层次化社区检测:以分层方式识别图中密集连接的节点“社区”,从高层主题到低层话题进行多级划分。
  • 自动生成摘要:通过 LLM 对每个社区进行总结,形成数据的层次化摘要,无需预先知道具体问题即可把握数据集全貌。
  • 支持全局查询:能够回答涉及整个数据集的问题(如“数据集的主要主题是什么”),这是传统 RAG 方法难以处理的场景。

工作流程

GraphRAG 采用基于社区摘要的 Map-Reduce 方法进行全局问答:

  1. 将社区报告按 LLM 上下文窗口大小分组。
  2. 对每个组应用问题以生成社区级答案。
  3. 将所有相关答案合并为最终的全局答案。

评估结果

在对比评估中,GraphRAG 显示出明显优势:

  • 使用任何层级的社区摘要时,在回答全局问题的全面性多样性上以 70%–80% 的胜率优于传统 RAG。
  • 中间和低级社区摘要在保持更优质量的同时,查询 token 成本仅为传统方法的 20%–70%。
  • 高级社区摘要在 token 成本极低(2%–3%)的情况下,性能与层次化源文本摘要相当。

研究展望与未来方向

当前研究重点在于:

  • 降低成本:自动优化 LLM 提取提示以适应特定领域,减少前期定制工作。
  • 提高可访问性:探索基于 NLP 的近似方法,以较低的索引成本模拟完整图谱构建过程。

GraphRAG 的开源旨在推动基于图的 RAG 方法在需要全局数据理解的场景中得到更广泛应用。

9. Show HN: Adding Mistral Codestral and GPT-4o to Jupyter Notebooks (github.com)

Pretzel:增强AI功能的Jupyter分支项目

项目简介

Pretzel是Jupyter的一个分支版本,旨在通过集成AI功能来提升Jupyter的能力。它添加了AI代码生成与编辑、内联代码补全、侧边栏聊天及错误修复等功能,并计划持续扩展更多特性。从Jupyter切换到Pretzel非常简单,因为它本质上是Jupyter的改进版,所有原有配置、设置、键绑定和扩展均可直接使用。

主要功能

  • AI代码生成与编辑:在任意单元格中点击“Ask AI”或按Cmd+K(Mac)/ Ctrl+K(Windows/Linux)触发AI提示框,输入指令即可生成或编辑代码。
  • 内联代码补全:在单元格中输入时,等待1秒即可触发基于AI的代码补全建议。
  • AI侧边栏聊天:通过Ctrl+Cmd+B(Mac)/ Ctrl+Alt+B(Windows/Linux)打开侧边栏,可进行聊天、生成代码、搜索现有代码或询问问题。
  • 变量与上下文感知:使用@符号可引用会话中的变量和数据框,AI会自动接收当前笔记本中的相关代码作为上下文。
  • 代码插入与错误修复:支持在现有代码中间插入新代码(通过“inject”或“ij”指令),并提供“用AI修复错误”按钮来快速处理报错。

安装方式

  1. 通过pip安装

    • 运行pip install pretzelai,然后执行pretzel lab启动Web界面。
    • 也可使用免费托管版本:pretzelai.app
  2. 通过Docker运行(适用于安装困难的环境):

    • 提供标准Dockerfile和运行命令,支持本地目录映射和版本更新。
  3. 安装问题排查

    • 若安装时遇到依赖构建错误(如PyStemmer),需根据操作系统安装相应的构建工具(如Windows的Microsoft Build Tools、Ubuntu的build-essential等)。

使用教程

  • 内联补全:直接输入代码,等待触发。
  • AI提示:使用快捷键或“Ask AI”按钮输入指令,支持提示历史循环。
  • 侧边栏:用于更复杂的交互,如修改函数、查找代码片段、解释代码或基于变量生成可视化代码。
  • 配置AI模型
    • 默认使用GPT-4o(对话)和Mistral Codestral(内联补全)。
    • 支持配置其他AI服务(如OpenAI、Anthropic/Claude、Ollama、Groq),需在设置中启用并填写API密钥或URL。
    • 推荐使用GPT-4级别模型以获得最佳性能。

隐私与数据政策

  • 不收集个人数据,仅对AI功能进行基础遥测(如事件计数),并关联匿名ID。
  • 可选择关闭提示遥测,但项目方鼓励开启以改进功能。
  • 不存储任何代码:即使使用Pretzel云端AI服务,代码也不会被保存。
  • 托管版本会根据邮箱创建用户,数据将在最后一次登录30天后自动删除,用户也可手动申请删除。

常见问题

  • 为何选择AGPLv3许可:为防止第三方未经贡献就将代码商业化,确保衍生作品保持开源。
  • 为何分叉Jupyter而非直接贡献:为降低用户迁移成本,并快速迭代功能(其开发速度可能超出Jupyter主仓库的接受范围)。
  • 商业模式:计划通过向企业销售托管版本(含企业级功能如数据访问控制、仪表板共享等)盈利,个人版本将保持免费。
  • 未来规划:包括原生AI代码编辑、实时协作、SQL支持、可视化分析构建器、类VSCode编辑体验等。

反馈与支持

总结

Pretzel通过集成AI功能显著增强了Jupyter的代码编写与调试体验,提供便捷的安装和使用方式,注重用户隐私,并采用开放源码模式持续发展。它适合希望提升数据科学工作效率的开发者和数据分析师使用。

10. Show HN: SQL Explorer – Open-source reporting tool that Just Works (github.com)

SQL Explorer 开源报告工具

项目概述

SQL Explorer 是一款基于 Django 的开源(MIT 许可证)报告与商业智能(BI)工具,旨在让数据在人员之间的流转更加快速、简单且无混淆。它既可以无缝集成到现有的 Django 网站中,也可以作为独立的 BI 工具使用。项目注重简洁性、直观性、稳定性和“最少意外”原则。

架构与部署

  • 技术栈:后端基于 Django 构建,前端配备 Vite 开发服务器并支持热重载。
  • 快速启动:内置完整的测试项目,用户只需运行 docker compose up 即可快速启动服务并进行体验。

数据源支持

  • 关系型数据库:原生支持所有 Django 兼容的 SQL 数据库。
  • 文件与本地库:允许用户直接上传并即时查询 CSV、JSON 文件或 SQLite 数据库。
  • 多连接管理:支持管理员统一配置或用户自行提供的多个数据库连接。

核心功能特性

  • 智能 SQL 编辑:提供简洁易用的 SQL 编辑器,支持编写、共享查询,并设有用于快速执行临时查询的 Playground 区域。
  • AI 驱动助手:支持接入 OpenAI 等 LLM API,提供 AI SQL 助手。该助手会自动将相关上下文和数据库 Schema 注入提示词中,辅助用户编写和调试查询。
  • Schema 辅助:提供数据库 Schema 信息的快速访问与自动补全功能,大幅降低查询门槛。
  • 浏览器内数据分析:内置快速统计、数据透视表和散点图功能,用户无需导出到 Excel 即可完成基础数据分析。
  • 参数化查询 UI:支持参数化查询,并能自动为不懂 SQL 的用户生成友好的前端交互界面。
  • 数据快照与追踪:支持按计划定期快照查询以捕获数据变化,同时提供完整的查询历史记录和系统日志。
  • 结果分发与 API 暴露:支持通过电子邮件发送查询结果;保存的查询还可根据需要快速暴露为简易的 JSON API。
11. Getting the World Record in Hatetris (2022) (hallofdreams.org)

HATETRIS 世界纪录打破历程摘要

游戏背景与挑战

HATETRIS 是一款确定性的俄罗斯方块变体,其核心机制是通过单步前瞻的 min-max 算法,始终为玩家提供当前局面下“最不利”的方块。由于缺乏随机性,传统的俄罗斯方块策略在此完全失效。

早期策略与机器学习尝试

早期玩家通过“伪循环”策略将最高分推至30分。2021年,玩家 knewjade 利用启发式束搜索(Heuristic Beam Search)将纪录大幅提升至66分。受此启发,作者最初尝试构建基于蒙特卡洛树搜索(MCTS)和 AlphaZero 的机器学习模型。然而,受限于消费级硬件算力、训练数据匮乏及模型调参困难,该机器学习项目最终被放弃。

模拟器极致优化

转向传统算法后,作者使用 Rust 重写了游戏模拟器,并进行了多轮极致优化:

  • 状态预计算与自定义哈希:预生成空白区域的状态图,并使用二进制编码替代传统哈希算法,大幅提升了状态检索速度。
  • 波形(Waveforms)缓存技术:将方块在特定高度内的可达位置抽象为“波形”,结合表面(Surface)切片进行缓存。该技术避免了重复计算,将单步计算时间从最初的数百毫秒压缩至48微秒。

启发式函数与参数优化

为了指导束搜索,作者融合了两种启发式评估函数:

  1. Knewjade 启发式:评估井的整体形状,惩罚洞孔和封闭洞孔,奖励可消除性和当前得分。
  2. 图论启发式:基于 Ford-Fulkerson 方法,逐行评估方块的“可消除性”与“渗透性”。 作者利用 Simple(x) 全局优化算法,在数十万次较小宽度的束搜索中自动寻找最佳的参数权重组合。

最终运行与打破纪录

在修复了“可消除性”计算顺序的严重逻辑错误后,作者租用 AWS 72核云实例运行宽度为2500万的束搜索。经过56小时的运算与后续耗时的关键帧逆向生成,程序成功规划出一条长达247步、得分86分的完美路径,打破了世界纪录。

核心经验教训

  • 性能分析至关重要:通过 Flamegraphs 发现并移除了占据大量运行时的无用错误日志格式化代码。
  • 数据结构选择:使用 BTreeSet 替代 Vector 进行动态排序,将插入操作的时间复杂度从 O(n) 降至 O(log n),解锁了大规模束搜索。
  • 硬件与算法的权衡:深度学习在缺乏庞大算力集群时难以奏效,极致的工程优化和启发式搜索在有限资源下更具可行性。
12. Booting Linux Off of Google Drive (ersei.net)

本文详细记录了作者受朋友启发,尝试挑战从Google Drive启动Linux系统的完整技术过程。核心目标是利用FUSE(用户空间文件系统)在initramfs阶段挂载Google Drive作为根文件系统,从而实现整个启动过程。

技术原理与实验基础 作者首先概述了Linux启动流程:固件→引导程序→内核→initramfs临时文件系统→切换到真实根文件系统。关键突破点在于利用initramfs阶段,通过Dracut工具构建包含网络支持和FUSE工具的定制化initramfs。初始概念验证基于本地S3存储桶进行。

遇到的主要挑战与解决方案

  1. 根文件系统切换失败:使用switch_root命令失败后,作者通过手动绑定挂载(mount --rbind)和chroot命令成功切换到S3上的根文件系统。
  2. 网络与DNS问题:系统启动后DNS解析失败,作者通过直接写入/etc/resolv.conf配置公共DNS服务器临时解决。
  3. 迁移到Google Drive的障碍:使用google-drive-ocamlfuse挂载Google Drive后,面临一系列严重兼容性问题:符号链接(尤其是相对链接和指向不存在目标的链接)和硬链接无法正常工作、文件权限属性丢失、操作极其缓慢等。作者不得不采用rsync并辅以脚本手动修复失败的符号链接。
  4. 启动过程具体问题
    • 依赖库链接错误:由于符号链接问题,/sbin/init看似“未找到”,实则是链接库路径错误。通过在initramfs内创建/sysroot/sysroot并绑定挂载来解决。
    • 设备超时:通过创建systemd设备单元覆盖文件,设置JobTimeoutSec=infinity解决了串行设备超时。
    • 登录超时:修改/etc/login.defs中的LOGIN_TIMEOUT值。

最终实现与延伸 经过反复调试,作者成功在虚拟机和真实硬件(笔记本电脑)上实现了从Google Drive启动Linux系统。在真实硬件上,需要适配正确的网卡驱动(如r8169)并调整网络设置。

总结与思考 该项目是一个富有挑战性的技术实验,展示了Linux启动流程的灵活性和FUSE的强大能力。作者指出,尽管实用价值有限,但此思路可延伸至从SSH、Git仓库等启动系统。文章以幽默口吻提及了商业化“云原生计算”的构想,并计划继续探索下一步(如安装NixOS)。

13. GPU-Friendly Stroke Expansion (arxiv.org)

GPU-Friendly Stroke Expansion 总结

本文介绍了一种在GPU上高效执行矢量图形笔画扩展的技术,旨在解决描边路径渲染中的挑战。以下是主要内容和关键点:

目的与背景

  • 矢量图形的主要原语包括填充路径和描边路径。虽然填充路径在GPU上已有多种渲染技术,但描边路径的渲染更具挑战性,因为它涉及全局问题,需要保证连续性和正确性。
  • 本文提出一种笔画扩展方法,通过生成代表输入路径描边的轮廓,实现GPU友好型渲染。

核心技术与算法

  • 并行算法:实现了一个完全并行的算法,适合在GPU计算着色器中执行,预处理步骤极少,从而提高效率。
  • 输出格式:方法输出为线段或圆弧段,两者均适合GPU渲染,且生成的段数量最少,优化了性能。
  • 新技术引入
    • 一种适合并行处理的矢量图形原语编码方式,简化了GPU上的数据处理。
    • 基于欧拉螺旋的方法,用于计算平行曲线和渐屈线的近似,确保笔画扩展的准确性。

关键优势

  • 解决了描边路径在GPU渲染中的难题,提供了一种高效、准确的解决方案。
  • 输出格式兼容GPU渲染管线,减少计算开销,适用于实时应用。

提交历史

  • 论文最初于2024年4月30日提交,后于2024年6月29日更新,反映了持续优化过程。

本文通过创新算法和编码技术,显著提升了GPU上矢量图形笔画扩展的性能和适用性。

14. Pharma firms stash profits in Europe's tax havens (www.investigate-europe.eu)

制药公司通过欧洲避税天堂转移巨额利润,导致患者难以及时获得救命药物。以爱尔兰患者米里亚姆·斯汤顿为例,她因黑色素瘤术后无法及时获得免疫治疗药物Opdivo,直至癌症进展至四期才获批使用,而同期法国等欧盟国家已将其纳入医保。

避税天堂的利润转移 调查揭示,15家欧美制药巨头在避税天堂及低税地区设立了超过1300家子公司。这些地区包括爱尔兰、荷兰、瑞士、卢森堡及美国特拉华州。在2019-2023年间,这些公司累计税后利润达5800亿欧元,超过同期5720亿欧元的研发投入。利润主要分配给股东,股息和股票回购总额达5580亿欧元。

典型避税结构与案例

  • 百时美施贵宝:在爱尔兰子公司Swords Laboratories采用类似“双爱尔兰”避税结构。该公司2022年营收172亿美元,但通过专利持有公司将专利收入转移至瑞士纳税实体,实现有效税率仅4.7%。
  • 辉瑞:通过荷兰有限合伙企业CPPI CV转移全球四分之三收入,该企业具有“税务透明”特性,允许股东免税获取利润。
  • 艾伯维:被指通过百慕大知识产权持有结构避税,并利用“常青”策略为修美乐申请94%的附加专利以延长垄断期。

行业借口与现实的矛盾 制药公司常以高昂研发成本为由维持高药价,但数据显示其研发支出与利润基本持平。部分企业如艾伯维、强生等支付股东回报的金额甚至超过研发投入。

对患者和医疗系统的影响

  • 药物可及性延迟:爱尔兰因药价谈判缓慢,新药上市平均延迟超过两年。2024年政府一度未批准新药资金,后迫于压力拨款2000万欧元。
  • 医疗系统负担:荷兰审计机构指出部分获批药物成本效益不足,建议政府争取更大折扣。公益组织已就艾伯维滥用市场支配地位提起诉讼,指控其14年内在荷兰牟取12亿欧元超额利润。

公司回应与争议 涉事企业均声称遵守税法。赛诺菲辩称低税地区子公司符合当地患者需求;拜耳指出作为德国企业需就离岸利润纳税。但活动人士认为,避税行为导致医疗投资减少,尤其对发展中国家造成负面影响。

结论 制药行业通过复杂的跨境税务安排积累巨额利润,却以研发成本为借口推迟药物普及,加剧医疗资源分配不公。监管机构与法院正面临平衡创新激励与公共健康需求的挑战。

15. Code reviews do find bugs (two-wrongs.com)

代码审查确实能够发现缺陷——针对一篇认为“代码审查不能发现缺陷”的微软研究论文的反驳与澄清。

该文章指出,微软2015年的研究论文《Code Reviews Do Not Find Bugs》的结论具有误导性。其数据表明,审查员只有约15%的评论指出可能存在的缺陷。但文章作者认为,这一统计并不能证明审查在发现缺陷方面效率低下,它只能说明审查员还会提出大量关于其他方面(如代码可维护性)的评论。实际上,结合先前研究可知,代码审查能在仅增加15%时间投入的前提下,额外发现约60%的缺陷。

文章进一步强调了代码审查的高效性。研究表明,在每天最初的60分钟审查时间内,只要审查速度控制在每10分钟不超过50行代码,审查员平均能每10分钟发现一个缺陷。这种效率在手动测试甚至某些自动化测试中都难以实现。

代码审查在促进知识共享和团队学习代码库方面价值巨大。微软论文数据显示,审查员对同一代码部分的审查经验积累极快:首次审查时,其评论被代码作者认为有用的比例仅为33%;到第三次审查时,这一比例已上升至约67%;到第四次即接近项目的长期平均水平。文章估算,仅需约1-2小时的审查就能让开发者熟悉一个全新的代码库部分。这打破了“知识共享”与“开发速度”之间的传统矛盾,让新手能通过审查快速学习,同时几乎不拖慢资深开发者的进度。

此外,微软论文中提到的其他发现,例如50%的评论关乎代码长期可维护性、变更大小与审查效用负相关、开发者每周花费约6小时审查等,文章作者认为这些并非缺陷,反而是代码审查带来的积极影响或应优化的环节(如控制变更大小、确保审查量合理)。

最后,文章指出微软论文可能暴露的真正问题在于审查轮转时间过长(其中位数为24小时)。作者结合自身经验(中位数6小时已觉缓慢)强调,遵循最佳实践(包括保持较小的变更规模和较短的审查响应时间)是确保代码审查高效的关键。因此,问题可能不在于代码审查本身,而在于实践中未能遵循最佳实践。

16. Diff-pdf: tool to visually compare two PDFs (github.com)

diff-pdf:PDF视觉比较工具

基本信息

  • 注意:该仓库按原样提供,代码不再积极开发。欢迎提交改进建议,但不提供功能支持或错误修复。
  • 适用人群:开发者或愿意自行调试的用户。

功能与用途

diff-pdf 是一个用于视觉比较两个 PDF 文件的工具。它接受两个 PDF 文件作为参数,并输出以下内容:

  • 返回码:默认情况下,如果无差异则返回 0,有差异则返回 1。
  • 差异高亮 PDF:使用 --output-diff 选项可生成一个 PDF 文件,其中差异被可视化高亮显示。
  • GUI 查看:使用 --view 选项可打开一个简单图形界面,支持逐页查看、细节缩放,并可通过 Ctrl+方向键 平移页面以识别仅位置差异,或使用 Ctrl+</Ctrl+> 切换查看左右文档。

获取方式

预编译二进制文件

  • Windows:可从发布页面下载 ZIP 归档,或使用 Chocolatey 安装。
  • macOS:通过 Homebrew 或 MacPorts 安装。
  • Linux
    • Fedora/CentOS 8:使用 dnf 安装。
    • openSUSE:可从构建服务下载预编译包。

从源码编译

依赖项

  • 需要 Unix 或类 Unix 环境(如 Cygwin 或 MSYS)。
  • 必需库:wxWidgets >= 3.0Cairo >= 1.4Poppler >= 0.10
  • 各系统安装依赖的示例命令:
    • CentOS:通过 yum 安装开发工具和库。
    • Ubuntu/Debian:使用 apt-get 安装依赖。
    • macOS:通过 Homebrew 或 MacPorts 安装。
    • Windows:需通过 MSYS2 环境安装,依赖较多(如 fontconfig、freetype 等)。

编译步骤

  1. 运行 ./bootstrap(仅当从版本控制构建且缺少 configure 时)。
  2. 执行 ./configure
  3. 运行 make
  4. 可选执行 make install(Unix 系统)。

Windows MSYS2 编译

  1. 安装 MSYS2 环境。
  2. 在 MSYS2 MinGW 终端中安装所需组件:pacman -S automake autoconf pkg-config make zip pactoyspacboy -S gcc:p poppler:p wxWidgets:p
  3. 按上述通用步骤编译,可运行额外命令生成包含所有 DLL 的 ZIP 归档。

安装

  • Unix 系统:使用 make install
  • Windows:无需安装,直接复制文件(如使用 ZIP 归档则已包含所有必要文件)。
19. How random are TOTP codes? (shkspr.mobi)

本文探讨了TOTP(基于时间的一次性密码)生成的双因素认证(2FA)验证码的随机性,验证了其是否存在对特定数字的偏差。

起因

作者怀疑其银行的TOTP应用生成的验证码偏向于数字“8”,并思考这是否只是人类大脑在随机数据中强行寻找规律所产生的错觉。由于TOTP算法底层依赖HMAC和SHA-1,作者决定通过实际采样和数据分析来验证其输出的随机性。

验证过程与结果

作者使用Python(结合 pyotpnumpymatplotlib 库)编写脚本,生成并统计TOTP验证码中0-9各个数字的出现频率,并绘制分布直方图:

  • 10次采样:数字“8”的出现频率异常高,表面上看似证实了存在偏差的猜测。
  • 100次采样:数据中存在较多噪音,但数字“8”的突出程度已明显下降。
  • 10,000次采样:数字分布的偏差基本消失,各数字的出现频率趋于均匀,呈现出良好的随机分布。

结论

  • 随机性确认:TOTP代码每30秒更新一次,一年大约会生成100万个代码。在充足的样本量下,TOTP代码不会对特定数字表现出明显的偏差,证明其底层算法生成的验证码是真正随机的。
  • 验证方法的意义:虽然审查TOTP的源代码可以确认其安全性,但通过实际测量和统计输出来验证随机性,同样是一种直观且令人安心的有效方法。作者最初在小样本中观察到的对数字“8”的“偏好”,仅仅是小样本偏差和人脑模式识别错觉所致。
20. When RAND made magic in Santa Monica (asteriskmag.com)

兰德公司(RAND)在二战后至1960年代的二十年间,是全球最具影响力的研究机构,为美国的科学、军事战略和外交政策做出了奠基性贡献。其成功源于独特的组织文化、顶尖人才和稳定的资金支持,但后来的转型导致其影响力逐渐衰退。

成立背景与初期优势
兰德公司最初作为美国空军的研究分支成立于1945年,由前试飞员富兰克林·科尔博姆提出构想,并得到空军将领亨利·阿诺德的支持。通过未动用的战争资金和福特基金会的资助,兰德获得了稳定的财务基础。其早期成功依赖于吸引顶尖的跨学科科学家(包括诺贝尔奖得主),并营造了一种鼓励创新、跨领域协作和高度自治的文化。研究人员平均年龄低于30岁,团队在开放竞争环境中推动了跨学科突破。

黄金时代的核心成就
1945至1960年间,兰德在基础科学和战略分析上取得了一系列里程碑式成就:

  • 战略与军事领域:重新定义了美国核战略,提出了卫星概念、系统分析和防御经济学基础。其研究迫使空军多次调整关键防御政策,例如阿尔伯特·沃尔斯泰特1954年的报告揭示了战略空军基地的脆弱性,推动了“失效安全”机制的建立。
  • 科学技术创新:兰德学者奠定了博弈论、线性规划和蒙特卡洛方法的基础,提出了广义人工智能概念,开发了分组交换技术(网络数据传输的前身),并建造了全球最早的计算机之一。
  • 工作模式:公司资金大部分来自空军合同,但超过三分之一的产能用于自由的基础研究,形成“应用推动基础,基础增强应用”的良性循环。

转型与衰退的原因
自1960年代起,兰德逐渐从一个聚焦军事和尖端科技的研究中心转变为更广泛的社会政策智库,其影响力随之减弱:

  • 资金多元化与管理挑战:空军预算缩减和双方矛盾促使兰德拓展客户(如NASA、国防部其他部门等)。资金来源多元化增加了管理复杂性,降低了工作效率,并削弱了原本专注、自由的研究文化。
  • 政治与舆论压力:兰德的研究多次与空军教条冲突,引发了内部阻力。1958年《战略投降》论文因被政治曲解而引发国会抗议,使公司更加谨慎,避免敏感议题。
  • 战略重心转移:1960年代,在新任领导下,兰德大幅增加社会科学研究比例,至1972年近半数项目涉及社会科学。虽然此举扩大了公司范围,但挤占了原有的尖端科学研发资源,应用数学、物理学等基础研究在1990年代后基本停滞。
  • 外部环境变化:随着冷战背景和军事直接资助模式的改变,兰德早期的特殊条件(如巨额空白支票式的资助)不再可复制。

现状与启示
如今的兰德公司仍是一家成功的智库,年收入超3.5亿美元,其研究生院也是全美最大的公共政策学院之一。但其现代成就未能重现早期的政策和科学根本性影响力。兰德的兴衰表明,顶尖人才、创新文化和智力自由是研究突破的关键,但其早期特定历史条件(如单一军事资助、冷战紧迫性)难以重现。

23. Switzerland mandates software source code disclosure for public sector (joinup.ec.europa.eu)

瑞士颁布了《联邦使用电子手段履行政府任务法》(EMBAG),立法强制要求联邦当局公开其自行开发或委托开发的软件源代码,除非受第三方权利限制。这一举措旨在提升政府运营的透明度、安全性和效率。

  • 核心要求与倡导者:该法律被视为“公共资金,公共代码”原则的典范,由伯尔尼应用科学大学公共部门转型研究所所长Matthias Stürmer教授等关键人物推动。Stürmer教授长期倡导开源软件在提高数字透明度和减少对商业软件依赖方面的益处。
  • 法律细节与条款:法律第九条规定,公共机构可提供与支持、集成或IT安全相关的附加服务,但需以覆盖成本的报酬提供,以确保公平竞争,避免市场扭曲。
  • 立法历程与挑战:立法过程历经挑战,最初面临来自议会成员和政府机构的阻力,涉及知识产权和安全等问题。经过数字可持续性议员小组等组织的持续游说,最终达成妥协。
  • 范围与展望:目前该法律仅适用于联邦层面,不包括各州和市镇。瑞士此举有望成为其他国家类似立法的榜样,旨在促进数字主权、创新与合作,并充分发挥开源软件在安全、成本和信任方面的优势。
24. The History of Machine Learning in Trackmania (hallofdreams.org)

机器学习在《Trackmania》中的发展历程摘要

《Trackmania》(2020版)是一款由Nadeo开发、Ubisoft发行的赛车游戏,其核心赛事“每日杯”(CotD)要求玩家在15分钟内学习新地图并争夺最快时间,综合考验玩家的探索、优化与稳定性能力。文章的目标是构建一个能在无先验经验、单台PC、实时速度下赢得CotD顶级分区的自主程序。

机器学习项目的演进

过去数年间,多个团队尝试通过强化学习等技术让AI自主驾驶《Trackmania》,主要项目及特点如下:

  1. 监督学习阶段:Rottaca(2017)使用卷积神经网络(CNN)根据游戏画面学习按键操作,但因缺乏动力学理解和数据不足导致效果有限。
  2. 无监督学习与基础框架:TMRL项目(Yann Bouteiller等人)引入无监督学习,结合CNN和LIDAR(激光雷达)简化输入,大幅降低计算需求。尽管性能未达人类水平,但构建了重要的开源框架。
  3. 信息与算法优化
    • Laurens Neinders借鉴《GT赛车》的Sophy系统,为TMRL增加了赛道曲率前瞻信息,使AI能规划多弯道,显著提升成绩。
    • AndrejGobeX测试了多种算法(如PPO、TD3),并成功将程序移植到现实遥控车上,展示了技术的迁移潜力。
  4. 泛化能力的探索:PedroAI通过深度Q学习,让一个神经网络在数百张地图上交替训练,首次证明了AI具备跨地图学习的可行性,尽管训练长期停滞,成绩有限。
  5. 高性能专精项目
    • Bluemax666(2019-2021)采用变分自编码器处理游戏画面,在特定地图上达到了接近世界纪录的成绩,是早期高性能的代表。
    • Yosh(2020年起)尝试了几乎所有主流方法,并创新性地引入“训练轮”技巧:先通过额外奖励教会AI高阶操作(如新滑行),再移除奖励让其自行优化使用场景,有效结合了专家知识。
    • Linesight(2024年初)代表了当前公开项目的最高水平。其CNN系统在真实高难度地图“Hockolicious”上,经过约80小时(9倍速)训练后,成绩达到人类玩家历时六年才突破的水平,位列全球榜单前列,证明了强化学习可实现接近专业玩家的竞技水平。

作者的目标与动机

文章作者团队旨在超越上述项目,实现一个能像人类一样在15分钟内掌握新地图的顶尖AI。他们强调,当前主流机器学习依赖海量数据和算力,而他们的项目追求的是:

  • 数据与算力的极限:在无法获取无限数据、仅用单台PC的条件下,应用前沿技术达成实际目标。
  • 探索性而非模仿性:不使用工具辅助或加速游戏(如TMNF的TAS工具),而是让AI以实时速度学习。
  • 宏大的愿景驱动:以“取代人类在赛车电竞中的地位”这种看似不切实际的目标为驱动力,克服长期研发中的枯燥与挫折,逐步将理想转化为可行的技术方案。

综上所述,《Trackmania》机器学习的发展展示了从监督学习到无监督学习、从单一地图到泛化、从基础操作到高性能竞技的技术演进路径。当前最先进的项目已能通过强化学习在复杂真实地图上达到专业级水平,为作者团队实现其最终目标奠定了重要基础。

25. Cutting Board Designer (www.cuttingboarddesigner.com)

Cutting Board Designer

Cutting Board Designer 是一款免费的辅助工具,旨在帮助用户更快速、更轻松地设计并制作出外观精美的砧板。

26. A Git story: Not so fun this time (blog.brachiosoft.com)

Git的诞生源于Linux内核开发中的实际问题。1998年,随着Linux社区扩大,创始人Linus Torvalds面临代码管理瓶颈,个人成为提交流程的瓶颈。开源领袖Eric Raymond和开发者Larry McVoy察觉其倦怠迹象,McVoy提议使用分布式版本控制系统,并推荐了自己开发的BitKeeper。

BitKeeper的背景与采用 BitKeeper源于McVoy在Sun Microsystems优化内部工具NSE的经验,其前身NSElite和随后商业化的TeamWare是早期分布式版本控制系统的代表。1998年底,McVoy邀请Torvalds等人讨论解决方案,BitKeeper逐渐成型。2002年,为减轻Torvalds负担,Linux内核开发者开始免费使用BitKeeper,但其附带条款(如禁止开发竞争工具、强制日志记录)引发社区争议。

冲突与Git的快速诞生 2005年,开发者Andrew Tridgell开发了兼容BitKeeper的免费客户端SourcePuller,引发BitMover(BitKeeper所属公司)不满。McVoy随后撤销了Linux内核的免费使用许可,导致Torvalds愤怒且急需替代方案。在尝试Monotone等工具后,Torvalds于2005年4月7日仅用两周时间编写了Git的初始版本(约1000行C代码)。其设计借鉴了Monotone的SHA-1哈希和“内容寻址”思想,但采用极简的Unix哲学,通过多个底层命令(如init-dbcommit-tree)管理文件快照。

早期发展与贡献者 Git发布后迅速吸引开发者关注。捷克开发者Petr Baudis创建了用户友好界面Cogito(后演变为“porcelain”层),并搭建了早期主页git.or.cz和代码托管服务repo.or.cz。关键人物Junio Hamano于2005年加入,与Torvalds合作改进合并算法,三个月后接任Git维护者,至今仍在Google主导项目发展。Git 1.0.0于同年12月发布。

GitHub的推动与主流化 尽管Git在技术社区受认可,但真正使其普及的是GitHub。2007年,Tom Preston-Werner和Chris Wanstrath受Ruby社区启发(当时Git通过Rails框架传播),创建了GitHub——首个社交化代码托管平台。2008年上线后,Rails迁移至GitHub,推动了Git在Web开发社区的爆发。GitHub通过文档(如Scott Chacon的《Pro Git》)、活动和友好的用户体验,弥补了Git与早期核心开发者社区之间的鸿沟。

结局与影响 BitKeeper因无法与Git竞争,于2016年开源退出市场。Git凭借其分布式模型、高性能和社区支持,在2022年Stack Overflow调查中占据94%份额,成为事实标准。其成功离不开Torvalds的初始设计、Hamano的长期维护,以及GitHub的生态推动。正如BitKeeper创始人McVoy所言,Git虽设计简单,却适应了全球开发者的需求。未来版本控制系统可能融合AI等新技术,但Git的崛起故事已成为开源协作的经典案例。

28. 8cc.vim: Pure Vim script C Compiler (github.com)

8cc.vim:纯 Vim 脚本 C 编译器

8cc.vim 是一个基于 ELVM 构建的、完全用 Vim 脚本编写的 C 编译器。

核心概念

  • 8cc:一个为 x86_64 Linux 设计的、支持 C11 标准的小型 C 编译器。
  • ELVM(Eso Lang Virtual Machine):一个特殊虚拟机架构。它首先将 8cc 重定向,使其输出 ELVM 的中间表示(EIR)。然后,利用这个重定向后的 8cc 作为前端,将 C 代码编译为 EIR,最后通过后端将 EIR 转换为多种目标语言(如 Python、Ruby、C、Brainfuck 等)。
  • 8cc.vim 的由来:作者为 ELVM 新增了一个“Vim 脚本”后端,并利用它将 8cc 的 C 源代码翻译成 Vim 脚本。因此,8cc.vim 本身由纯 Vim 脚本构成,包含一个定制的前端(8cc)和一个后端(ELC)。

功能与特性

  • 主要功能:可以在 Vim 环境中将 C 代码编译成 Vim 脚本代码,并且 Vim 可以直接执行生成的脚本。
  • 运行环境:由于虚拟机运行在 Vim 脚本之上,8cc.vim 理论上可在 Linux、macOS 及 Windows 上工作。
  • 项目性质与性能:这是一个实验性的玩具项目,运行速度极其缓慢。编译一个最简单的 putchar() 程序在测试机器上需要约 824 秒(约 14 分钟)。

安装与使用

  • 安装:可以通过克隆仓库并使用 Vim 的包管理功能 (:packadd),或使用 vim-plugdein.vim 等插件管理器安装。
  • 主要命令与函数
    • :EccCompile / eightcc#compile():编译当前缓冲区中的 C 代码,生成包含 Vim 脚本的新缓冲区。
    • :EccRun / eightcc#run():直接编译并运行 C 代码,可跳过中间步骤查看结果。
  • 示例流程:在缓冲区输入 C 代码(如“Hello world”程序),执行 :EccCompile。生成的 Vim 脚本会被保存并可通过 SetupVM() 函数创建虚拟机实例来运行。

许可证

该项目采用 MIT 许可证。

总结

8cc.vim 是一个概念验证项目,它巧妙地利用 ELVM 架构,将完整的 C 编译器移植到了纯 Vim 脚本环境中。虽然实用性因其缓慢的速度而受限,但它证明了在 Vim 中实现复杂工具链的可能性。

30. Working Title (Insurance) (www.bitsaboutmoney.com)

美国产权保险:一个高成本、低赔付的体系解析

作者通过在芝加哥购买房产的经历,揭示了美国产权保险行业的问题。与许多国家(如日本)由政府机构直接提供清晰的产权登记不同,美国的产权系统并非直接记录“谁拥有什么”,而是通过汇总历史交易记录来推断当前所有权。这种推断存在不确定性,因此产生了“产权保险”来应对潜在风险。

产权体系与保险的起源

  • 美国产权记录模式:政府机构(如库克县档案处)主要记录私人的产权交易(如买卖、抵押),当前所有权需通过分析这些历史交易链来推断。这类似于区块链通过交易历史计算余额。
  • 不确定性:“很可能拥有”与“绝对拥有”存在区别。未记录在案的潜在权利主张(如未披露的婚姻、历史遗留问题)可能颠覆交易,这被称为“非记录瑕疵”。
  • 产权保险的作用:为应对这些风险,产权保险应运而生。它承诺,如果产权存在未被发现的缺陷,将承担昂贵的补救费用,甚至全额退还购房款。由于贷款方通常强制要求购买,该保险几乎成为交易的必备部分。

行业问题:高昂成本与极低赔付率

  • 损失率异常低:产权保险的损失率(赔付额占保费收入的比例)仅约5%,远低于其他保险类别(如房主保险82%、汽车责任险76%)。
  • 定价与销售机制
    • 捆绑服务:保费中很大一部分(在伊利诺伊州高达80-85%)作为佣金支付给了产权代理(通常是产权检查机构或律师)。
    • 缺乏比价:买家通常直接接受卖家律师推荐的保险公司,不会比价。律师因能从该保险中获得高额佣金,有动力维持现状。
    • 利益共同体:本地房地产行业是一个关系紧密的生态系统,律师、代理人之间存在长期合作关系,通常不会质疑彼此推荐的服务费用。
  • 产权检查的价值:对交易记录的检查通常很有限(例如仅查看过去24个月的记录),其高昂费用主要被解释为涵盖了代理方在承保过程中承担的“风险转移”和“担保”,但实际因此产生的赔付几乎为零。

隐私保护与系统挑战

  • 土地信托:作者指出,一些买家会使用土地信托(如自己案例中的安排)来持有房产,以在一定程度上保护个人财务信息(如抵押贷款详情)不被公开记录。但这并不能解决产权保险本身的问题。
  • 系统性难题:改变该行业面临巨大政治经济阻力。房地产行业组织完善、资金充足、与社区联系紧密,且能有效游说。产权保险带来的高成本虽对消费者是“分散的负担”,但对从业者是“集中的利益”,这使得改革动力不足。

结论

美国的产权保险体系是一个因历史路径依赖和利益固化而形成的、对消费者成本高昂的系统。它提供了应对独特产权风险的服务,但其定价与赔付严重脱节,且市场机制失灵(缺乏价格竞争)。尽管理论上存在被颠覆的可能,但由于强大的既得利益群体,短期内该体系难以发生根本性改变。

31. The history of Alt+number sequences (devblogs.microsoft.com)

Alt+数字序列的历史

Alt+数字序列起源于IBM PC BIOS时代,用户可通过Alt键+数字键盘输入十进制码值来输入键盘上没有的字符。例如输入ñ对应Alt+164,该码值对应BIOS使用的Code Page 437字符集。

Windows系统在美国采用Code Page 1252(称为ANSI字符集),但为兼容MS-DOS,Alt+数字序列仍默认查询OEM字符集(即旧BIOS字符集)。因此,Alt+164仍输出ñ(尽管其在Code Page 1252中码值为241)。

为输入ANSI字符集中存在但OEM字符集中没有的字符(如©),用户需在数字前加0前缀,例如Alt+0169。此时系统查询ANSI码值。

若输入数字大于255,Windows和BIOS默认对其取模256(例如Alt+259等价于Alt+3,对应Code Page 437中的♥)。然而,某些控件(如RichEdit控件)会覆盖默认行为,改为取模65536。这导致在同一系统中,Alt+序列的行为可能因输入控件而异。

例如,Alt+9731在默认控件中输出♥(9731 mod 256=3),但在RichEdit控件中输出Unicode雪花符号☃(9731 mod 65536=9731)。曾有用户误认为Windows更新破坏了此功能,实则是控件差异所致。目前尚无系统支持对Alt+值取模2097151以直接输入基本多文种平面之外的码点。

32. The case against morning yoga, daily routines, and endless meetings (andrewchen.substack.com)

反对早晨瑜伽、日常惯例与无尽会议

本文批判了以习惯为核心的成功范式,提出“10倍工作”才是职业成就的关键。

核心矛盾

当前“奋斗文化”推崇机器般的高效执行:清晨瑜伽、冥想、健身、频繁会议与待办清单。但作者认为,职业生涯由少数高影响力时刻定义,而非完美执行日常惯例。

10倍工作的特征

  • 高杠杆:极少数任务驱动绝大部分成果,符合幂律分布
  • 非常规性:通常随机出现,依赖快速决策,在几天/周内展开
  • 高风险高回报:成果巨大或灾难性,且往往不可逆
  • 非累积性:日常惯例(1倍或0.5倍工作)再多也无法叠加成10倍成果

常规工作的局限

  • 过度关注防御性优化(如取消会议、屏蔽时间)只是必要不充分条件
  • 勤奋与懒惰的产出差异仅3倍,但顶尖工作者可实现100-1000倍差距
  • 清单管理易导致对非重要工作的过度投入

创造10倍工作环境

  1. 走向知识前沿:在技术边界(如AI、VR、web3)工作,那里机会多且等级未固化
  2. 主动制造变化:通过换工作、启动项目、跨地域移动等注入风险与新信息
  3. 掌握主动权:基于自身目标规划工作,避免陷入反应式循环
  4. 拥抱随机性:主动连接有趣的人、举办活动、公开分享想法、随机探索
  5. 构建累积资产:打造随时间复利的项目(如公开内容、网络活动),增加表面接触面积
  6. 接受技能考验:投身高成败概率的项目,对结果负责
  7. 培养比较优势:成为某一领域顶尖,或在多个领域达前25%水平

比较优势策略

  • Scott Adams理论:成为顶级艺术家几乎不可能,但结合绘画(前25%)与幽默(前25%)则创造稀缺价值
  • Naval补充:在多个领域达顶尖5%比单一领域登顶更易,组合技能大幅降低竞争度
  • 目标是在经验、学习、网络等方面向“单项顶尖”或“多领域前25%”发展

10倍工作计划

  1. 长尾工作:删除/委托/自动化低于1倍影响的任务
  2. 中等价值工作:持续执行,但尽量与个人规划对齐
  3. 高杠杆工作
    • 制定总体计划并坚定方向
    • 增加随机接触、深入技艺、积极投入
    • 在10倍机会出现时快速配置资源(时间、人力、资本)

关键理念

  • 10倍工作无法优化预测,常源于随机想法、偶然会面或随手推文
  • 技能积累与随机性结合时产生突破(如Steve Martin所言:“好到让人无法忽视”)
  • 作者提倡:拒绝核心循环、检查清单与邮件泥沼,拥抱随机性
33. What Happened to Perl 7? (2022) (blogs.perl.org)

Perl 7 计划现状总结(2022年)

背景与演变

  • 两年前曾宣布 Perl 7 计划,旨在通过默认启用常用模块减少代码样板,但会破坏部分向后兼容性。
  • 此举引发社区广泛争议,最终促使 Perl 建立了新的治理结构。

现行治理与决策机制

  • Perl Steering Council (PSC) 作为三人委员会,拥有 Perl 未来方向的最终决策权。
  • PSC 由核心团队每年选举产生(与 Perl 年度版本发布周期挂钩)。
  • Perl 5 Porters (p5p) 邮件列表仍是主要讨论平台,以寻求共识为首要目标。

新的核心策略

  1. 向后兼容性优先:确保编写合理的现有 Perl 5 代码能在未来版本中运行(安全漏洞修复等特殊情况除外)。
  2. 加速语言发展:通过 RFC 流程(任何人可提出)引入新特性。
  3. 推动新特性采用:通过技术手段降低新特性的使用门槛。

关键技术机制

  • 特性防护(Feature Guards):用于保护不向后兼容的新特性,需显式启用(如 use feature 'say')。
  • 无防护特性(Unguarded Features):引入全新语法(在旧版中会报错),无需防护即可直接使用。
  • 实验性特性(Experimental Features):处于试验阶段,可能变更或移除,使用时会产生警告。
  • 版本捆绑(Version Bundles)
    • 作用:通过 use v5.36; 这样的单行声明,一次性启用该版本所有稳定的、非实验性新特性及推荐编译指令(如 strict, warnings)。
    • 优势:大幅减少样板代码,并明确标示代码所针对的 Perl 版本基准。

Perl 7 的未来定位

  • 当前路径:继续在 5.xx 系列中逐步引入新特性并解决实验性特性。
  • 未来可能:当累积的新特性集构成足够大的飞跃时,PSC 可能决定将版本号提升至 7.0
  • 兼容性保证:即使未来出现 Perl 7,默认也将向后兼容 Perl 5;需通过 use v7; 来启用全部新特性。
  • 版本号意义:版本号的重大跳跃(如7.0)将保留用于标志重大里程碑,以吸引社区关注,而非仅表示渐进式更新。随意更改会削弱该信号的价值。

总结

Perl 社区放弃了原计划中可能破坏兼容性的激进 Perl 7 方案,转而采用基于 PSC 治理RFC 流程版本捆绑 的渐进式创新策略。Perl 7 将作为未来重大升级的潜在版本号,而非一个迫在眉睫的、带有破坏性变更的独立版本。核心目标是推动语言现代化的同时,维护现有的代码基础和开发者信心。

34. Fiwix: Unix-like kernel for the i386 architecture (github.com)

Fiwix 是一个从零开始编写的、基于 UNIX 架构的操作系统内核,主要面向 i386 硬件平台。它是一个业余操作系统项目,同时也用于教育目的,因此内核代码力求简洁。其体积小(少于5万行代码),并兼容大量现有的 GNU 应用程序。

主要特性:

  • 核心与架构: 使用 ANSI C 编写(仅在必要部分使用汇编)。符合 GRUB Multiboot v1 规范。是一个完整的 32 位保护模式、非抢占式内核,但支持抢占式多任务。主要针对 i386 及更高兼容处理器。
  • POSIX 兼容性: 大部分兼容 POSIX,支持进程组、会话和作业控制。
  • 进程间通信: 支持管道、信号、UNIX 域套接字以及 UNIX System V IPC(信号量、消息队列、共享内存)。
  • 文件与存储: 支持 BSD 文件锁定机制。支持 EXT2(1KB/2KB/4KB块)、Minix v1/v2、ISO9660(含 Rock Ridge 扩展)、Linux-like PROC(只读)和 PIPE 等文件系统。提供虚拟内存分割(用户/内核空间可选3GB/1GB或2GB/2GB)、需求分页和写时复制功能。
  • 兼容性与格式: 大部分兼容 Linux 2.0 i386 ABI 系统调用。支持 ELF-i386 可执行格式(静态和动态链接)。调度算法基于轮询(目前无优先级)。
  • 硬件支持: 支持 PCI 局部总线、PS/2 鼠标、串行端口、并行端口打印机、软盘、IDE/ATA 硬盘和 ATAPI CD-ROM。支持 VESA VBE 2.0+ 帧缓冲区设备和控制台、QEMU/Bochs 图形适配器、UN98 伪终端和虚拟控制台(最多12个)。
  • 其他功能: 支持 Kexec、初始 RAM 磁盘、SVGAlib 应用和伪随机数生成器。

编译与安装: 编译内核只需执行 make clean ; make,会生成内核文件 fiwix 和符号表 System.map.gz。编译前可修改配置文件进行定制。该内核本身不独立运行,需要用户空间环境(如 FiwixOS 提供)来测试和使用。

安装可通过启动光盘或软盘进行,需运行 install.sh 脚本。最低硬件要求为:标准 IBM PC-AT 架构、i386 处理器(带浮点单元)、4MB RAM(推荐128MB)、IDE/ATAPI CD-ROM 或 3.5 英寸软驱、1GB ATA 硬盘。

重要提示: 该内核处于早期开发阶段,可能存在未发现或未解决的严重错误和功能缺陷,使用风险自担。

许可与信息: Fiwix 是自由软件,采用 MIT 许可证,由 Jordi Sanfeliu 创建。

35. Ask HN: How do you find a "boring" tech job?
36. Using SIMD for Parallel Processing in Rust (nrempel.com)

Nicholas Rempel 个人简介

Nicholas Rempel 是一名软件工程师,居住在加拿大不列颠哥伦比亚省的维多利亚市。他目前任职于 Foxglove 公司,负责构建用于机器人和自主系统的开发者工具。此前,他曾在 Shopify 和 Instant Domain Search 工作。

他的兴趣领域广泛,包括 Rust、TypeScript、基础设施、AI/ML、系统编程、分布式系统、开发者体验、开源软件以及猫。

Nicholas 在多个社交媒体平台保持活跃,提供了以下个人链接:

  • GitHub:github.com/nrempel
  • LinkedIn:linkedin.com/in/nbrempel
  • X / Twitter:x.com/nrempel
  • Bluesky:bsky.app/profile/nrempel.com