《测谎仪的妄想》内容摘要

本文作者 Justin St. Germain 讲述了自己申请美国边境巡逻队工作时接受测谎仪测试的亲身经历，并由此展开对测谎仪历史、科学基础及其文化象征意义的深刻批判。

个人经历与测试过程

• 作者为寻求更稳定、高薪的工作，申请边境巡逻队，在经历笔试、体能测试、背景调查后，进入最后一环——测谎。
• 审查员凯文在一间无窗的审讯室中进行测试，其语气和行为充满操控性，营造高压氛围。
• 在关于过往药物使用的问题上，审查员施压，使作者最终接受一个模糊的“事实”（承认使用毒品6-8次），尽管作者内心清楚这并非精确记忆。
• 测试中，作者在高强度压力下产生“解离”心理体验，感觉自己脱离了身体。
• 最终，测谎仪判定作者在药物使用或资料填写问题上“存在欺骗”，未通过测试。

测谎仪的科学争议与历史

• 缺乏科学依据：作者指出，测谎仪测量的是生理反应（如血压、脉搏），但这些反应无法区分说谎与其他压力刺激。独立研究表明其准确率与抛硬币无异。
• 历史与发明：1921年由约翰·拉尔森发明，初衷是记录情绪反应，而非测谎。其商业推广者利昂纳德·凯勒将其命名为“测谎仪”并用于营销。
• 权威机构的否定：美国国家科学院、心理学协会、最高法院等均认为其不可靠；联邦法律禁止私营企业用其进行招聘筛查。
• 发明权争议：多人声称发明了测谎仪，反映出该设备更像一个文化神话，而非严谨科学工具。

测谎仪的真实用途与文化象征

• 迫使认罪而非发现真相：作者认为，测谎仪的本质功能是配合审讯技术（如莱德技术），通过制造压力和心理操控来获取口供，历史上导致多起冤案。
• 美国独有的迷思：美国政府是少数在招聘中大规模使用测谎仪的机构，这体现了对“绝对真相”可被机器检测的文化幻想。
• 与记忆和写作的类比：作者将测谎仪测试与回忆录写作类比——两者都并非“发现”真相，而是通过反复叙述和压力下的重构来“创造”真相。记忆本身具有可塑性，易受重述影响。
• 后真相时代的隐喻：文章结尾将测谎仪置于当代社会背景下，指出在虚假新闻和算法时代，人们对绝对、简单真相的渴望依然存在，但每个人都生活在自己构建的主观现实里。

核心结论

测谎仪并非可靠的测谎工具，而是一种象征权力的装置，它利用人们对“机器能探测谎言”的盲目信任，服务于强制性的认罪文化。其在美国社会的持久存在，反映了一种对简化、绝对真相的集体迷思，而这迷思往往与事实无关，只关乎信仰。

彼得·巴克斯顿：揭露塔斯基吉梅毒实验的举报者逝世

核心事件

• 人物：彼得·巴克斯顿，美国公共卫生举报者，86岁。
• 逝世：2023年5月18日因阿尔茨海默病在美国加州去世。
• 贡献：揭露美国历史上最臭名昭著的医学研究丑闻——塔斯基吉梅毒实验。

塔斯基吉实验背景

• 时间：1932年由联邦科学家启动。
• 对象：阿拉巴马州塔斯基吉地区400名感染梅毒的黑人男性。
• 性质：1940年代青霉素成为有效疗法后，联邦卫生官员故意不予治疗，旨在观察疾病自然病程。
• 现状：在1960年代前，该研究被医学界普遍接受，已有十余篇期刊论文发表，但无人质疑其伦理。

巴克斯顿的举报历程

• 发现：1960年代中期，巴克斯顿在旧金山担任联邦公共卫生雇员时，偶然听到同事谈论该研究。
• 内部举报：1966年致信疾病控制与预防中心（CDC）提出伦理质疑；1967年在亚特兰大会议上遭到官员严厉驳斥。
• 持续抗争：尽管离开公共卫生部门并进入法学院，仍持续关注此事。
• 公开揭露：1972年将研究文件提供给美联社记者伊迪丝·莱德勒，随后调查记者琼·海勒于7月25日发表报道。

揭露后的影响

• 研究终止：报道引发公众愤怒，国会听证，四个月后研究被叫停。
• 法律后果：集体诉讼达成1000万美元和解赔偿。
• 国家道歉：1997年克林顿总统正式道歉，称其为“可耻行为”。
• 政策改革：推动美国医疗研究伦理规范的根本性变革。
• 历史影响：该研究至今仍被视为部分非裔美国人不愿参与医学研究的原因之一。

巴克斯顿个人背景

• 生平：1937年生于布拉格，犹太裔；1939年为逃离纳粹占领移民美国，定居俄勒冈州。
• 职业经历：曾就读俄勒冈大学，服役期间担任战地医务员和精神科社工；1965年加入联邦卫生部门。
• 举报动机：自述对比了纳粹医学实验与塔斯基吉研究，认为两者同样“道德上无法辩护”。
• 后续生活：写作、演讲并获奖；周游世界，从事古董（尤其是军事武器、加州淘金时期赌博工具）收藏与交易；花二十余年追讨纳粹没收的家族财产，部分成功。

他人评价与自我认知

• CDC评价：CDC代表称其人生经历使其能迅速识别该研究的不道德性并寻求正义。
• 参与者后代：研究参与者之女感谢巴克斯顿的“诚实与勇气”。
• 朋友描述：被形容为“智慧、风趣、有风度、极度慷慨”，倡导个人自由，反对各种禁令。
• 自我定位：在2018年论坛上，被问及举报的道德力量时自嘲道：“那不是勇气，是愚蠢。”（演讲时常强忍泪水，从不以英雄自居）。

总结意义

巴克斯顿通过内部举报与媒体公开，终结了持续40年的非人道医学实验，重塑了美国研究伦理体系，其行动被视为公共卫生领域的关键道德里程碑。

药品定价中间商（Pharmacy Benefit Managers, PBMs）通过垄断和不透明操作大幅推高药价，即使专利过期的药物成本暴跌，患者支付的价格却未相应下降。以抗癌药格列卫（Gleevec）为例，其2015年专利到期后采购成本下降99%，但部分渠道价格仍高达数千甚至上万美元，差价被少数PBM攫取。联邦贸易委员会（FTC）报告指出，三大PBM（CVS Caremark、Express Scripts、Optum Rx）控制药品定价，通过隐秘回扣、垂直整合和价格歧视扭曲市场，导致医疗成本持续上涨。

PBM的起源与异化
PBM最初是类似信用卡的行政机构，负责处理药房账单和保险理赔。1987年后，美国立法允许PBM接受药企回扣，打破了其作为购买方代理的中立性。随后的反垄断诉讼和政策进一步合法化了选择性折扣，使PBM能对不同买家实行差异化定价。这种“价格歧视”与行业整合相互作用，形成了今天的垄断结构。

垄断与垂直整合
目前，前三大PBM所属的保险公司（UHG、CVS、Cigna）营收总和接近美国GDP的4%。它们通过横向和纵向整合，同时拥有保险公司、药房和PBM业务，例如CVS收购了保险公司Aetna，UHG雇佣了全美10%的医生。这种整合使PBM既能设定竞争对手的报销率，又能引导患者使用自家药房，形成利益冲突。例如，CVS通过子公司Cordavis生产生物类似药，并利用PBM地位优先推广自家产品，排挤其他更便宜的仿制药。

不透明定价机制
PBM系统使用多种复杂的价格基准（如平均批发价、最大允许成本等）和长达数月的追溯调整（如DIR费用），使实际成本无法透明化。药剂师常无法提前获知报销率，同一药物可能在不同时间、不同客户间存在数十种价格。这种不透明性掩护了PBM从药企获取回扣、同时向药房和患者收取额外费用的行为。例如，胰岛素Lantus的价格中63%作为回扣流向PBM，前提是该药被列为独家选择。

政策应对与行业抵制
各州和联邦层面已开始关注PBM问题。肯塔基州2021年退出大型PBM系统后节省了2.85亿美元；FTC在2022年发布政策声明，指PBM在胰岛素市场的回扣可能违法，并于近期发布调查报告，指出PBM隐瞒信息、抬高药价（如两款癌症药多收费16亿美元）。FTC表示可能起诉PBM，并计划举行国会听证。然而，PBM行业抵制调查，拖延提交资料至2025年，并利用其市场地位阻碍竞争。

系统性影响
PBM的垄断行为不仅直接推高药价，还抑制了创新。药企因生物类似药难以进入市场而减少投资，患者支付高昂费用，独立药房生存空间被挤压。改革呼声日益高涨，包括立法要求透明化定价、禁止垂直整合中的利益冲突，但废除“价格歧视”和回扣制度仍是关键难点。

Horizon 是一个注重隐私的文件托管服务，定位为 Imgur 的替代方案。其核心特性是通过静态加密确保文件安全，并特别提供了高级的 AES 加密选项。该加密功能设计得非常简单易用，用户只需通过一个开关即可轻松激活，从而为文件提供额外的安全保障。文章内容中展示了加密文件的示例数据，直观说明了其加密处理后的效果。

免疫疗法重塑癌症治疗：CAR-T细胞在胶质母细胞瘤中的突破

核心突破

麻省总医院的研究人员在一项针对胶质母细胞瘤的临床试验中取得历史性突破。通过将基因改造的T细胞直接注入患者脑脊液，前几名患者的脑部肿瘤在极短时间内几乎完全消失，这在以往被视为绝症的胶质母细胞瘤治疗中前所未有。

疾病背景与传统困境

胶质母细胞瘤是最常见且致命的恶性脑癌，中位生存期仅约一年。传统治疗（手术、放疗和化疗）效果有限，由于肿瘤极易浸润脑组织且高度异质，该疾病长期被称为“想法的坟墓”。

技术机制与创新

CAR-T细胞疗法通过提取患者T细胞，修改其DNA以表达嵌合抗原受体（CAR），再回输体内精准摧毁癌细胞。该疗法在白血病等液体肿瘤中已获成功，但在实体瘤中屡屡受挫。针对胶质母细胞瘤，研究团队进行了两项关键创新：

1. 给药途径：将CAR-T细胞直接注入脑脊液，提高肿瘤局部的细胞浓度。
2. 双重靶向：为应对肿瘤异质性，改造T细胞使其分泌双特异性T细胞接合器，同时靶向EGFRvIII和野生型EGFR两种蛋白，更全面地消灭癌细胞。

面临的挑战

尽管初期结果惊人，该疗法仍面临显著局限：

• 疗效持久性：输入的CAR-T细胞最终会被人体免疫系统清除，部分患者后续出现了肿瘤复发迹象。
• 成本与复杂性：CAR-T疗法定制化程度高、制备繁琐且极其昂贵（如白血病治疗成本高达62万美元），限制了临床可及性。
• 严格的试验标准：复杂的排除标准使得许多急需治疗的晚期患者无法参与临床试验。

未来展望与患者影响

这一早期突破为攻克其他顽固实体瘤打开了新大门。研究人员正探索体内直接基因改造T细胞或开发相关疫苗，以期降低成本并简化流程。专家预测该疗法有望在未来几年内获得FDA批准。 试验受试者Tom Fraser在经历短暂严重副作用后肿瘤显著缩小，生活质量大幅恢复。他的案例不仅为医学界提供了宝贵数据，也为绝望的癌症患者带来了实质性的希望。

《工程师深度学习指南：理解Transformer模型》内容摘要

文档背景与目的

当前正处于人工智能的第三个黄金时代，技术能力持续超越预期。2017年问世的 Transformer 模型最初用于机器翻译，现已广泛渗透至各个领域，成为现代工程师的必备知识。本文档旨在为工程师提供理解 Transformer 模型的“最短路径”，作为一份简明指南，提供恰到好处的学习内容。

核心内容与结构

文档注重理论与实践结合，主要提供以下资源：

• 可运行的 Python 代码示例：支持读者动手实践以加深理解。
• 扩展阅读参考资料：提供多种文档选项供读者进一步探索。

文档目录结构如下：

1. 第一部分：神经网络 - 介绍神经网络的基础概念。
2. 第二部分：循环神经网络（RNN） - 探讨 RNN 及其变体（包括 LSTM 和 GRU）。
3. 第三部分：自然语言处理（NLP）与注意力机制 - 阐述 NLP 核心原理，涵盖机器翻译与注意力机制。
4. 第四部分：Transformer - 深入解析 Transformer 模型。
5. 附录：基础知识 - 补充理解 Transformer 所需的 Python 和数学最低基础知识。

版权与使用条款

文档版权归 Hironobu SUZUKI 所有，具体使用条款如下：

• 免费使用：教育机构的师生可自由用于学习；非商业会议和讲座在注明网站链接和版权的前提下可免费使用。
• 商业使用：需签署收入分成协议（分享 20% 的相关销售收入），或支付 10,000,000 欧元进行全额买断（作者特别注明此买断选项为玩笑，且无意进行商业绑定）。
• 联系要求：联系作者需提供至少两个社交媒体地址进行身份验证，拒绝匿名联系（教育机构除外）。

作者简介

作者 Hironobu SUZUKI 是一位资深软件程序员与工程师，拥有信息工程硕士学位。他曾出版多本关于 PostgreSQL 和 MySQL 的技术书籍（如《The Internals of PostgreSQL》），并曾任日本 PostgreSQL 用户组主任，组织过多次大型技术研讨会。目前，他正在寻求将机器学习与人工智能技术应用于数据库管理系统（DBMS）的远程职位。其个人兴趣广泛，涉及历史、动物权利、宇宙学、社会与环境问题，同时热爱音乐（弹奏钢琴和吉他）并坚持素食主义。

三星半导体女工罢工事件概述

核心事件

• 罢工主体：全国三星电子工会（NSEU）组织的罢工，主要参与者为三星Giheung工厂8英寸半导体生产线的女性工人。
• 罢工时间：2024年7月8日开始，报道时已持续6天。
• 影响：罢工首日该生产线产能仅18%（正常为80%），这是三星电子55年历史上的首次大罢工。

工人恶劣的工作条件

1. 严重的职业健康问题：

   • 工人普遍出现手指变形、静脉曲张、足底筋膜炎、腰椎间盘突出等伤病。
   • 长时间站立工作，持续8小时搬运重达3-5公斤的晶圆盒。
   • 因生产线不停机，工人连用餐和如厕时间都紧张，导致膀胱感染等健康问题。
   • 心理压力大，多名工人确诊抑郁症。

2. 缺乏人性化管理：

   • 休假权受限：由于人手不足，员工实际上难以使用带薪假，甚至需抽签或猜拳决定休假资格。
   • 孕期与缺员问题：怀孕员工免加班后，公司不安排替补，导致同事工作量增加。

3. 生产线自动化程度低：

   • 8英寸生产线依赖人工搬运晶圆盒，而更先进的12英寸生产线已使用自动化OHT系统。
   • 该生产线曾于2024年5月发生X光辐射暴露事故。

工人的核心诉求

• 不被当作“可更换的零件”：工人强调加薪和休假不是首要诉求，更希望获得基本尊严和安全的工作环境。
• 改善过时的生产线条件：要求改变因设备落后导致的高强度人工操作。

三星公司的回应

• 声称遵守《职业安全健康法》，设有肌骨疾病预防中心。
• 否认8英寸生产线伤病率高于其他产线，并表示无相关工伤赔偿申请。
• 强调罢工期间仍能完成生产目标，并制定后续对策。
• 将员工对休假受限的投诉称为“个别员工的片面之词”。

罢工的深层原因

• 历史积怨：工人长期在落后生产线上承受高强度劳动，将罢工视为改变有害工作环境的“必要过程”。
• 工会支持：超过半数的8英寸生产线工人加入罢工，工会指出罢工源于员工“积累的失望与愤怒”。

数据来源：报道基于《韩民族日报》对多名工人的采访及工会提供的现场照片与数据。

Automerge：构建协作应用程序的数据结构库

Automerge 是一个拥有十多年历史的独立开源项目，由一支由工程师和计算机科学家组成的严肃且敬业的团队打造。团队成员包括 Heroku 的联合创始人，以及剑桥大学知名教授 Martin Kleppmann 等计算机科学家。该项目注重长期规划，着眼于未来十年的发展，而非短期融资。

团队致力于构建高性能、可靠的软件，力求成为开发者可信赖的基础。他们使用 Isabelle 等定理证明工具对设计进行严格的学术验证，并采用数据库领域的前沿性能技术进行实现。其标准是兼具速度与正确性。

该项目的持续发展得到了多方支持：

• 工业研究机构：Ink & Switch 提供了全职工程人员支持，包括主要维护者 Alex Good、Orion Henry、Brooklyn Zelenka 和 John Mumm。
• 开源赞助：来自 Fly.io 和 Prisma 等合作伙伴的赞助。
• 用户支持合同与功能开发资金：来自 GoodNotes 和 Bowtie 等用户的支持。
• 慈善资助：来自 NLNet、高级研究与发明局 (ARIA) 及 Endless Foundation 等组织的资助。

团队同样感谢社区中的所有成员，他们编写新的库和集成、为核心代码库做出贡献或分享使用 Automerge 构建应用的经验。项目维护着一份开源贡献者名单，并邀请更多人加入。

Exo：在本地日常设备上构建 AI 集群

项目简介

Exo 是一款将日常设备连接成 AI 集群的工具，旨在让用户在本地运行超出单台设备容量限制的前沿 AI 模型。通过原生支持 Thunderbolt RDMA 技术，集群在增加设备时能显著提升模型运行速度。

核心特性

• 自动发现与拓扑感知：设备自动组网无需手动配置；系统根据实时设备拓扑、资源和网络带宽自动进行最佳模型分割。
• RDMA over Thunderbolt：支持 Thunderbolt 5 RDMA，使设备间延迟降低 99%。
• 张量并行：支持模型分片，在多设备上实现显著加速。
• MLX 后端：采用 MLX 作为推理和分布式通信后端。
• 多 API 兼容：完全兼容 OpenAI、Claude 和 Ollama API，可直接使用现有客户端工具。
• 自定义模型与仪表盘：支持从 HuggingFace 加载自定义模型，并内置 Web 仪表盘用于集群管理与对话。

安装与运行环境

• macOS：支持源码编译（依赖 Xcode、Homebrew、uv、Node.js、Rust 等）或直接使用 macOS App（需 macOS 26.2+）。App 支持通过自定义命名空间隔离集群。
• Linux：支持源码编译（依赖 uv、Node.js、Rust），文件存储遵循 XDG 规范。注意：Linux 当前仅支持 CPU 推理，GPU 支持正在开发中。
• 配置选项：支持 --no-worker（仅作为协调节点）等运行参数，并提供丰富的环境变量（如 EXO_OFFLINE、EXO_MODELS_DIRS）以管理模型目录和运行模式。

macOS RDMA 配置

在配备 Thunderbolt 5 的 Mac 上启用 RDMA 需进入恢复模式终端执行命令。要求集群内设备全互联、使用 TB5 线缆，且所有节点的 macOS 版本（含 Beta 版本号）必须完全一致。

API 工作流

Exo 提供 RESTful API，标准使用流程如下：

1. 实例管理：通过 /instance/previews 获取模型部署方案，使用 /instance 异步创建实例并等待其就绪。
2. 推理请求：向 /v1/chat/completions 或 /v1/messages 等端点发送兼容主流格式的流式请求。
3. 模型操作：支持通过 API 添加 HuggingFace 模型、搜索模型及检查集群部署状态。

基准测试

内置 exo-bench 工具，用于测量不同部署配置下的模型预填充和 Token 生成速度。支持自定义 Prompt 大小、生成长度、最大节点数及分片策略，以输出详细的性能指标并优化集群表现。

Linux on Surface Pro 4 体验评测综述

背景与动机

作者于2016年购入一台搭载Intel Core m3-6Y30 CPU和4GB内存的Surface Pro 4，看中其2K高分屏、压感手写笔和平板电脑形态。多年后，出于对Linux平板的向往，决定在其上尝试安装Linux系统。

预期使用场景

• 网页浏览：主要访问自建的RSS阅读器。
• 媒体消费：观看本地Samba共享视频及在线视频。
• PDF阅读：仅需阅读，最好支持批注。
• 草图绘制：将头脑风暴或解决问题的草图数字化。
• 绘画创作：作为附加功能，可与AI图像生成结合。

安装过程

• 尝试的发行版：EndeavourOS（KDE桌面）和Fedora Workstation 40（GNOME桌面）。
• 安装方法：基于linux-surface项目提供的内核和工具，过程顺利。
• 整体易用性：若仅作笔记本使用，体验近乎完美；但作为平板使用时，问题显著。

功能实现情况

基本可用的功能

• 硬件支持：即使不使用linux-surface内核，Wi-Fi、蓝牙、键盘、电源管理、HiDPI缩放等均正常。
• 触控与笔：安装特定内核后，多点触控和压感笔“部分可用”。
• 续航表现：轻度使用约5-6小时，视频播放约3小时。
• 软件优化：
  • KDE：响应迅速，分离键盘后可自动进入平板模式，触控操作更友好。
  • GNOME：界面美观，类似移动设备布局，但资源占用较高。

关键问题与缺陷

1. 致命缺陷：触控识别不稳定

• 幽灵触控：屏幕会随机注册不存在的触摸，导致操作混乱。尝试多种解决方案均无法根治，问题具有随机性，重启或系统更新后可能复现或消失。
• 手掌误触：绘图时手掌误触严重，iptsd的防误触配置效果不佳。
• 键盘需求：磁盘加密时无虚拟键盘，必须连接物理键盘。

2. 其他通用问题

• 睡眠耗电：设备睡眠一夜电量下降约30%。

3. KDE（EndeavourOS）特有问题

• 虚拟键盘不稳定：时常不弹出或无法收起，影响登录和基本操作。
• 触控操作不便：长按不等同右键，窗口调整需精确触边，滚动不流畅。

4. GNOME（Fedora Workstation 40）特有问题

• 性能问题：默认启用swap和ZRam，即使禁用后仍比KDE慢，空闲时内存占用高（40-50%），频繁出现OOM（内存不足）终止进程。
• 操作错误：手势切换工作区时应用后台继续滚动，文件管理器滚动时意外弹出菜单。
• 虚拟键盘缺陷：退格键功能异常，需借助第三方插件修复，且旧键盘仍可能弹出。

最终结论与决策

触控识别问题（尤其是幽灵触控）严重破坏了平板体验，成为作者放弃Linux的主因。其他问题虽令人烦恼，但在触控功能正常的前提下尚可接受。

作者最终回归Windows 10，并放弃部分微软应用，转而使用：

• 浏览器：Firefox
• 文件同步：Nextcloud
• 视频分享：Samba
• PDF阅读：Drawboard PDF
• 绘图：Krita

尽管失望，但认为使用Windows 10总好过闲置设备。作者表示，待Windows 10停止支持（明年）后，可能会重新评估Linux的可行性。

OpenAI举报人向美国证券交易委员会（SEC）提交投诉，指控这家人工智能公司通过限制性保密协议，非法禁止员工向监管机构警告其技术可能对人类构成的严重风险，并要求SEC对此展开调查。

这篇文章介绍了作者如何运用运筹学方法参与梦幻足球联赛，旨在通过数学优化而非足球知识来组建高分阵容。

核心方法：背包问题建模 作者将梦幻联赛的选人问题抽象为经典的背包问题：在固定的预算（背包容量）下，选择总价值（球员预期得分）最高的11名球员（物品），同时满足阵容的构成约束。

实施步骤与解决方案

1. 数据获取：通过分析网站API接口，抓取了所有可用球员的数据，包括价格、位置、历史得分等。
2. 价值评估：采用球员最近5场比赛的平均得分作为其“预期价值”，这是一种简单但直接的预测方法。
3. 约束条件：定义了具体的阵容约束，如总预算上限、每个位置（门将、后卫、中场、前锋）的最少和最多人数。
4. 优化求解：使用Google的OR-Tools库中的CBC混合整数规划求解器来解决该优化问题。具体做法是：
   • 为每个球员定义一个0/1变量，表示是否选择。
   • 目标是最大化所选球员的总预期价值。
   • 添加预算约束和各位置人数约束。
   • 求解模型以获得最优阵容。

结果分析 作者使用此方法参与了从四分之一决赛到决赛的多个联赛。

• 在朋友联赛中：总积分排名第四（9人中），表现略高于平均，但未能夺冠。
• 在大型公开联赛中：表现不一，其中一个联赛的最终排名进入了前10%（1706/6345）。

结论与反思 虽然该算法未能让作者在朋友联赛中获胜，但在拥有数千参与者的公开联赛中表现出了竞争力，其成绩优于多数人类玩家。作者指出当前方案存在不足，并提出了改进方向：

• 价值预测过于简单：仅用近期平均分，未考虑球员状态、伤病和对手强弱。
• 未考虑风险：只追求高期望得分，忽略了得分的波动性。
• 忽略赛程信息：未能排除在特定轮次无法上场的球员。
• 忽略球员人气：未考虑通过选择冷门球员来实现差异化策略以竞争排名。

总体而言，文章展示了一个运用运筹学（特别是背包问题和整数规划）解决实际问题的可行框架，并验证了其基础有效性，同时也指出了现实应用中需要进一步细化的关键点。

Open Collaboration Tools 项目概述

核心产品介绍

Open Collaboration Tools 是一个开源项目，提供一系列库和工具，用于实现 IDE 内容的实时共享，旨在通过开放技术促进远程团队协作。其核心模式是：一位参与者作为主机会话发起人，邀请他人加入。IDE 扩展会分发主机的工作区内容，并高亮显示其他参与者的文本选择和光标位置。参与者可以在其常用的会议或聊天应用中同步讨论，实时查看他人的查看内容和编辑建议，从而减少沟通困惑并提升效率。

主要组成部分

• VS Code 扩展：可通过 Open VSX 和 VS Code Marketplace 获取。
• Eclipse Theia 扩展。
• 服务器应用：用于处理认证和协作会话，公共实例位于 api.open-collab.tools。
• 开放且可扩展的协议：提供 TypeScript 库，便于在不同环境中集成。
• 内置端到端加密和可扩展用户认证。
• 即将推出 Monaco Editor 集成：支持通过网页链接加入从完整开发环境启动的实时共享会话。

当前功能与未来规划

首个公开版本支持纯文本文档的协作（如任何编程语言的源代码、Markdown、配置文件等）。后续计划支持 Jupyter Notebooks、图表编辑器等更多内容类型。底层协议和基础设施可适配多种需要实时协作查看和编辑的场景。

开发动机

文章指出现有协作编辑工具存在局限性（见下表），无法满足特定需求，例如：

• 可插拔于任何流行 IDE（甚至跨 IDE）。
• 设计上可扩展，能以合理工作量添加自定义编辑器。
• 可本地部署以确保数据安全。
• 无供应商锁定，采用宽松许可证。

设计原则

为解决上述问题，Open Collaboration Tools 以以下核心原则设计：

• 无供应商锁定：支持潜在集成任何 IDE 甚至自定义 Web 应用。
• 绝对可扩展性：底层协议可扩展以支持任何编辑器类型的协作。
• 灵活部署：服务器基础设施可在本地、私有或云中运行。
• 开源许可：整个项目采用 MIT 许可证。

核心技术：Open Collaboration Protocol

该协议规定了 IDE 如何与协作服务器认证、创建或加入会话，以及用户间交换的数据类型。技术上采用 中心化对等机制：会话中的任何用户可向其他用户发送任意通知或请求，或通过广播机制向所有用户发送消息。从网络视角看，每个用户仅与中央服务器通信，服务器作为消息代理转发消息，因此服务器对实际消息内容一无所知。这种代理机制使协议具备无限可扩展性——只要通信客户端理解彼此的消息即可协作。协议已内置对基本文本编辑器的支持，未来将支持更多编辑器。

整体战略与展望

该项目符合 TypeFox 公司的战略：在宽松开源许可证下提供高度可定制的工具和框架。公司提供公共实例用于展示功能并支持开源社区，但建议企业根据自身安全需求部署私有实例。TypeFox 承诺持续投资该项目，逐步增加集成数量和深度。

该综述文章探讨了如何将几何、拓扑和代数结构应用于机器学习，以应对传统方法在非欧几里得数据上的局限性。核心内容包括：

问题背景：经典机器学习长期建立在欧几里得几何基础上，但现代应用中的数据常具有复杂的非欧几里得结构，例如时空曲率、神经元连接的拓扑复杂性或物理系统的代数对称性。

研究目标：受非欧几里得几何发展的启发，旨在将传统机器学习方法推广到具有几何、拓扑和代数结构的非常规数据类型上。

主要贡献：文章提供了一个易于理解的入门指引，并提出了一个图形化分类体系，将近年来的研究进展整合到一个直观的统一框架中。此外，还总结了当前面临的挑战，并展望了该领域未来的发展机遇。

文章版本：该文于2024年7月首次提交，并在2025年7月进行了更新。

系统设计需要的是系统设计工具，而非图表工具

核心问题：XY问题的陷阱

工程团队在管理软件系统时，常陷入“XY问题”的误区：他们实际要解决的是系统设计过程（问题X），却直接询问如何使用图表工具（解决方案Y）。这导致他们采用碎片化方法，使用多种工具（如绘图工具、Google Docs、Jira、Slack等）分别处理架构图、决策记录、API列表等任务，造成信息分散、维护成本高、效率低下。

系统设计 ≠ 画架构图

系统设计是一个持续的过程，涵盖系统高层概念结构、组件交互、需求、权衡和决策，而不仅是绘制静态图表。其产出包括需求文档、架构文档和架构图等。将系统设计简化为画图或文档，会忽略关键信息，导致技术债务累积和团队效率低下。

传统图表工具的局限性

现代软件系统复杂度急剧增加（如SaaS、API、遗留系统集成），传统图表工具已无法满足需求：

• 缺乏实时更新：图表是静态的，无法反映系统动态变化。
• 协作与版本控制困难：更新繁琐，难以维护统一版本。
• 无单一事实来源：图表通常不包含需求、决策等背景信息。
• 无法管理云资源：不能控制或生成基础设施代码（如Terraform）。
• 用户界面笨拙：调整和排列组件耗时费力。

真正需求：支持动态复杂系统的工具

工程团队需要拥抱复杂性的工具，这些工具应：

• 提供实时、准确的系统信息，支持动态演进。
• 支持深度探索，允许在抽象层与具体细节间切换（类似汽车检修）。
• 整合协作、决策记录和版本控制，形成单一事实来源。
• 区分不同类型的关系（如组织结构图与架构图），增强系统可观察性。

为何团队仍依赖图表工具？

1. 沉没成本谬误：已投入时间绘制图表，不愿放弃。
2. 抗拒改变：切换工具需时间培训，团队可能有其他优先级。
3. 问题定义不清：只说“需要更新图表”，而非“需要实时理解系统”。

结论

随着系统复杂度增长，传统图表工具的局限性日益凸显。团队需要能全面支持系统设计过程的工具，避免在静态图表、手动文档更新和信息搜集中浪费时间，从而专注于有价值的讨论和决策，推动系统持续演进。

Taim: 自动计时跟踪工具摘要

核心功能

• 自动计时跟踪：无需手动启动/停止计时器，软件自动记录工作时间。
• 会话管理：支持手动或自动记录会话，可随时编辑会话的时长、日期、项目等信息。
• 灵活控制：可选择会话是否计费与支付状态，便于生成发票。
• 高级过滤：按日期、状态、项目、标签等筛选跟踪记录。

操作与数据管理

• 应用流程：提供活动概览，允许用户选择记录内容、修改时间数据、添加可共享备注。
• 学习能力：随使用时间增加，可逐步实现自动记录会话。
• 导出功能：支持导出CSV、PDF、XLS格式的会话报告（如每周付费会话、上月计费会话）。

技术特点

• 资源高效：作为原生应用，CPU占用率仅5%-15%，功耗与存储需求低。
• 本地与云存储：个人版数据本地存储，团队版支持云存储。

定价模式

• 一次性购买：个人版支付一次即可永久使用，包含12个月免费更新。
• 团队版：按席位订阅，支持多设备与团队使用。

适用场景

• 针对自由职业者、项目团队，解决手动计时不准确、漏记或多收费等问题。
• 兼容个人项目与客户项目，支持自定义设置。

一位用户在 Hacker News 上发帖求助，描述其长期面临记忆力差与执行功能不足的困境。

• 核心问题：发帖人年近四十，意识到自身在构建事业、人脉和生活方面持续受阻，可能源于一种认知缺陷。具体表现为：丰富的经历未能转化为有效的心智模型，导致重复犯错，且难以有效规划以实现目标。
• 具体困难：无论是学习新知识/技能、进行人脉拓展、理解组织动态与人际关系，还是做出合理决策，都感到思维混乱，对现实世界“盲目”。自评在认知和情感上停滞于青少年阶段，存在情绪调节不佳、难以进行细致深入思考（总停留在表面）等问题。
• 目标与挫败感：渴望健身、阅读、提升技能、建立关系、创业等，但看到同龄人已在此方向努力多年，自觉既“没有拿到人生剧本”，也无力自行拼凑出一套有效方案。随着年龄增长却无改善，感到目标愈发遥远。
• 求助：询问社区成员是否有类似经历，是否能提供建议或推荐相关的辅导教练。

本文详细记录了使用LimeSDR软件定义无线电解码飞机DME（测距设备）导航系统的完整过程，包括系统原理、硬件搭建、软件配置及录音初步分析。

DME系统与目标 DME通过测量飞机发射的脉冲对与地面应答器转发脉冲对之间的往返时延来计算距离。系统工作在960-1215 MHz频段，通道间隔1 MHz，且空对地与地对空频率始终相差63 MHz。作者的目标是录制DME的双向通道信号，并通过分析验证飞机与地面站之间的时延与基于飞机位置计算的理论值相符。

技术挑战与解决方案 使用常见SDR同时录制两个相隔63 MHz的通道存在挑战。作者选用了LimeSDR，其核心芯片LMS7002M支持更高采样率，并且每个接收通道均内置了可独立配置的数控振荡器（NCO）和数字下变频（DDC）功能。作者最终采用的方案是：将本振（LO）频率设置在两个DME通道的中心频率，使用80 Msps的ADC采样率以确保两个通道均在数字信号中；随后，利用LimeSDR两个独立接收通道的RXTSP（接收信号处理链），分别通过NCO进行频率搬移，将两个DME通道独立下变频至基带，并经过抽取将输出采样率降至2.5 Msps，从而轻松实现双通道录制。

硬件配置

• 天线：自制了一个工作频段覆盖DME频段的四分之一波长接地平面单极子天线。
• 低噪声放大器：使用GALI-39 MMIC搭建的宽带LNA，以补偿后续分路损耗。
• 分路器：使用一个Wilkinson分路器将天线信号分给LimeSDR的两个接收通道。
• 系统搭建：所有设备安装于相机三脚架上，通过LiPo电池供电。

软件与设置

• LimeSDR配置：通过LimeSuiteGUI进行关键设置，包括ADC采样率（80 Msps）、LO频率（1175 MHz，为两个通道中心频率）、RXTSP中的HBD抽取比（2^5）和NCO频率（±31.5 MHz，分别用于上下变频）。作者指出RXTSP抽取比与LimeLight模块的时钟分频器需要匹配，以避免采样重复或丢失。
• GNU Radio流图：用于加载配置并录制数据。流图中加入了微小的直流偏移校正，并利用rx_time标签检测丢包。时间戳通过文件名和文件修改时间共同确定，精度约为1秒。

录音与初步分析 作者录制了科梅纳尔（CNR）VOR-DME站两小时的信号，并将数据集发布于Zenodo。初步分析显示：

• 地对空通道存在大量“杂散”脉冲对，这是地面应答器为维持恒定输出功率而自动产生的。
• 录制的脉冲对形状存在一些失真，可能源于多径或接收机硬件。
• 观测到了一个空对地脉冲对及其对应的地对空回复，两者间总延迟约70微秒，其中包含了50微秒的固定转发延迟和约15微秒的无线电信号传播时间。通过计算验证了飞机信号比地面站信号更早约5微秒到达接收机，与飞机位置相对于接收机和地面站的几何关系相符。
• 识别出地面站通过周期性发送码率为1350对/秒的规则脉冲对序列来发射摩尔斯电码识别信号。当用AM接收机解调时，这种规则脉冲序列听起来类似1350 Hz的音频信号。

资源 文中涉及的GNU Radio流图、Jupyter Notebook分析代码以及录制的原始数据集均已开源。

文章摘要：故事点无用，应度量队列

本文深入批判了软件开发中普遍使用的“故事点”估算方法，并提出了一个基于“度量队列”的替代方案。

故事点的核心问题

• 定义模糊且不一致：故事点试图综合衡量工作量、复杂性、风险和不确定性，但实际应用中，不同团队对其理解差异巨大，导致比较和聚合毫无意义。
• 与速度指标的矛盾：故事点按斐波那契数列设计（如1, 2, 3, 5, 8...），高数值代表一个范围而非精确值。将它们相加计算“速度”在数学上不成立（例如，一个13点故事与13个1点故事含义完全不同）。
• 事实上的时间转换：尽管声明“故事点不是时间”，但通过“速度”（平均点数/冲刺）的计算，它们已被默认转换为时间估算，而这正是其试图避免的。
• 引发行为扭曲：当速度成为目标（古德哈特定律），团队可能通过“点数膨胀”来游戏指标，或因害怕未完成承诺而降低目标，导致“竞次”现象。
• 过程浪费：为分配故事点而进行的估算会议耗时甚多，其产出（一个模糊的数字）价值有限，且随着时间推移会迅速过时。

已知问题与持续使用的原因

• 故事点的缺陷（如跨团队比较、可加性问题）已是行业共识。其创始人罗恩·杰弗里斯已公开表示后悔并批评其滥用。
• 然而，由于缺乏明显更优的替代方案，许多团队仍在沿用。即使改用T恤尺码（S, M, L）或直接估时，也会面临类似的相对性、准确性和范围变更问题。

解决方案：度量队列

受唐纳德·莱纳森《产品开发流原理》启发，作者提出以“队列”为核心进行估算和预测。

1. 核心概念：
   • 队列：即待办工作的清单（任务列表）。
   • 容量利用率：当系统接近100%容量时，队列长度会急剧增加，导致所有工作的可变性飙升（这是估算总不准的根本原因）。
2. 操作方法：
   • 团队协作分解：整个团队（而非个别专家）共同讨论功能，将其分解为具体的、细粒度的任务清单。此过程旨在识别并消除不确定性（通过“探针”或原型解决）。
   • 以任务数作为“作业大小”：功能所需的任务总数就是其“队列大小”或“作业大小”。例如，功能A有250个任务，功能B有50个任务。
   • 计算平均任务速率：跟踪团队每周完成的任务数（平均任务速率），取代模糊的“故事点速度”。
   • 动态调整与跟踪：当收到新信息或范围变更时，团队直接更新任务清单（增/删任务），而非重新进行模糊的点数估算。进度通过完成任务自然体现。
3. 优势：
   • 领先指标：队列大小是领先指标，能提前预警问题（如任务数激增意味着范围膨胀）。而速度、周期时间是滞后指标。
   • 更可靠的预测：基于任务数和平均任务速率，产品团队可自行计算预期时间（如功能A预计耗时250/40≈6.25周）。
   • 自然处理变更：范围变更直接反映在任务清单的修改上，无需纠结是否修改估算值，投影也随之自动更新。
   • 提升团队参与度与知识共享：集体分解任务的过程本身是深入的技术讨论和团队建设。
   • 减少估算压力：开发者无需直接提供令人尴尬的时间或复杂度承诺。

关键结论

文章认为，故事点从根本上就设计不当，会持续引发困惑和效率低下。而度量队列（聚焦于任务分解、队列大小和任务速率）是一种更可靠、透明且能真正支持业务优先级排序和容量规划的方法。它要求团队转变视角，从估算模糊的“点数”转向管理具体的工作“流”和“队列”。

Godotcaml 是一个早期阶段的开源项目，旨在将 OCaml 语言集成到 Godot 4.2 游戏引擎中。

选择 Godot 的原因：Godot 是一个成熟的免费开源游戏引擎，提供完整的 IDE，适合开发 2D/3D 游戏，能避免开发者陷入底层图形 API 的困境。

选择 OCaml 的理由：

1. 垃圾回收：默认带 GC，提升开发效率。
2. 函数式优先：OCaml 是函数式语言，语法利于编写游戏逻辑。
3. 默认及早求值：相比惰性语言，更易于推理运行时性能和调试。
4. 可控的副作用：在与 FFI（外部函数接口）交互时，比纯函数式语言更方便。
5. PPX 代码生成：利用 PPX 宏简化与 Godot 绑定所需的大量样板代码。

当前已实现的功能：

• 从 OCaml 调用 Godot 内置函数、方法和二进制运算符。
• 在 OCaml 中构造 Godot 值，并与 OCaml 对应类型进行数据编组。
• 在 OCaml 中定义新的 Godot 类（可继承现有类）。
• 大部分针对自定义引擎的代码生成。
• 通过模块包含（module inclusion）模拟类继承。
• 定义可从 GDScript 或其他语言调用的 OCaml 方法（体验仍在完善）。

待办事项与限制：

• 信号系统：用户自定义及内置信号支持不佳，待类型安全化。
• 垃圾回收：需解决 OCaml 对象被 GC 过早回收的问题。
• 方法支持：目前只能定义带一个参数（加 self）的方法，不支持静态/虚拟方法。
• 其他改进：包括构建系统集成、热重载、自定义运算符名称修饰、完成 C API 绑定、提升类型安全性、支持多原生类型大小配置、增加测试以及避免段错误等。

这是一个早期版本，作者警告不要用于生产环境。项目欢迎社区贡献，后续将发布更详细的设置指南。

NSCopyObject 的机制缺陷与防御策略

核心机制与缺陷

NSCopyObject 是一个古老的 Foundation 函数，主要通过内存拷贝（memcpy）复制对象。引入 ARC 后，系统通过 fixupCopiedIvars 尝试修复引用计数，但这仅对 ARC 管理的 Objective-C 实例变量（ivar）有效。对于非 ARC 管理的 ivar、C++ ivar 以及 Swift 存储属性，该机制无法正确处理，极易导致引用计数错误、内存损坏或程序崩溃。

隐式继承风险

开发者即使不直接调用 NSCopyObject，也可能因继承使用了该函数的父类（如 NSCell、NSAnimation、NSBitmapImageRep）而被动受害。若父类来自第三方或闭源库，此风险将更加隐蔽且难以控制。

防御策略

Objective-C

在 ARC 环境下，推荐的防御方法是：在拷贝后手动将对象的 ivar 清零，然后通过正式的属性 setter 重新赋值。对于非 ARC 管理的引用类型 ivar（如手动分配的内存缓冲区），仍需进行手动处理。

Swift

Swift 的内存安全机制使防御更为困难，直接将属性设为 nil 会触发错误的释放操作。

• 彻底方案：重写 copy(with:) 且不调用 super，完全重新创建实例（但对包含特殊复制逻辑的父类不适用）。
• 妥协方案：假设父类使用了 NSCopyObject，在调用 super.copy 后，利用 Unmanaged.passRetained 手动增加引用计数，以抵消浅拷贝带来的风险，防止崩溃。

苹果的矛盾行为与 NSCopying 协议缺陷

尽管苹果早在 2008 年就警告 NSCopyObject 极度危险，并于 2012 年将其正式废弃，但其自身的核心框架（如 AppKit 中的 NSCell、NSImage 等）至今仍在使用它，且这些类被明确设计为允许子类化。

此外，NSCopying 协议本身存在设计脆弱性：子类默认无法正确继承 copy 行为，且编译器不强制要求子类重写 copy(with:)，导致支持子类化的类在实现拷贝功能时极易出错。

Inkbase: 可编程墨水（2022）

项目愿景

该项目旨在创建一种可编程草图本，它结合了纸笔手绘的灵活性与电子表格等数字工具的计算能力。核心目标是支持渐进式丰富和即时编程，让用户能在绘制草图的同时添加动态行为，无需切换到专门的编程环境。

背景与灵感

• 电子表格的成功：因其网格界面、渐进式构建和即时反馈而成为成功的最终用户编程工具。
• 纸笔的持久价值：纸笔具有自由形式、即时性、亲密感、非正式性等优势，这些在数字工具中常被削弱。
• 数字纸笔的局限：现有平板/触笔工具在空间组织、分享、混合工具使用、低延迟等方面仍不如传统纸笔。

研究问题

1. 编程概念：适合手绘标记交互的心理模型或编程概念是什么？
2. 界面设计：如何在书写时设计即时编程的交互界面？
3. 应用场景：可编程草图本能用来做什么？

Inkbase 系统概述

Inkbase 是一个为 iPad 和 Apple Pencil 构建的原型应用程序，作为可编程草图本实现。

核心功能

1. 墨迹与选择：默认模式下触笔绘制，双指按住可选择对象。
2. 对象与属性：绘制的路径是实时矢量对象，具有动态属性（如颜色、位置、宽度），可通过属性检查器查看和编辑。
3. 动态行为：
   • 属性可以是静态值或表达式。
   • 使用类似 Lisp 的语言，支持响应式数据流。
   • 空间查询（如 query/inside、query/r）用于查询画布上的对象关系，并保持响应式更新。
   • 属性查找（?）和属性设置（!）用于读写对象属性。
   • 系统自动跟踪依赖关系，当相关属性变化时，依赖它的表达式会自动重新计算。

使用案例

项目通过以下示例探索工具的可能性：

1. 心理记账：例如习惯追踪器，通过空间查询标记完成的项目，并用动态括号高亮连续的“连胜”记录。
2. 模型构建：例如为受限的 OLED 屏幕设计 UI 布局，通过绘制和添加动态约束来探索不同尺寸和标签数量的设计。
3. 学习与认知动作：例如绘制和模拟逻辑门，通过组合基础门来理解 NAND 门的重要性，并通过交互加深对计算原理的理解。
4. 草图数学：
   • 物理：绘制弹跳球的轨迹图，通过识别三角形符号（导数算子）动态计算并绘制其导数（速度/加速度）图，帮助直观理解微积分概念。
   • 统计：演示卷积操作如何通过手绘图形直观地“涂抹”函数，并用于理解测量误差如何影响数据分布。

关键技术组件

1. 空间查询：是模型构建的核心。用于查询画布上的对象关系（如包含、相交、相对位置）。挑战在于需要更模糊的查询和处理负空间（如网格单元格）。
2. 识别：系统需要理解标记的意图以触发动态行为。项目探索了基于启发式的底部识别（如识别轴线）和通用笔画识别（如识别三角形）。在控制与可靠性之间存在权衡，建议结合明确分组和可塑性（如允许用户训练识别器）来改善体验。
3. 微世界：指预构建的组件库（如图表/导数运算符），可被用户创造性地组合使用。Inkbase 的响应式基础使得微世界能与用户编程的行为无缝交互，形成一个可扩展的生态系统。

发现与开放问题

• 与材料共事的感觉：使用墨水与响应式系统交互的感觉新颖且引人入胜。
• 动态注释的价值：少量的动态性（如注释、记账辅助）可以辅助思考，同时保持用户主导。
• 分组/复合对象：需要更好的方法来将多个笔画分组，以便进行有效的空间查询和行为封装。
• 编程模型：当前基于文本编辑的 Lisp 模型在平板上体验不佳，且隐藏了大部分程序逻辑。需要全新的、更直观的编程表达方式。
• 可重用性：通过复制工作区来重用“工具包”很容易，但需要更完善的机制来实现复杂的行为共享和封装。
• 响应式对象创建：在响应式模型中动态创建新对象是一个未解决的设计难题。

结论

Inkbase 展示了在一个统一环境中将手绘草图与动态编程相结合的巨大潜力。尽管在编程模型、识别可靠性和交互设计上仍面临重大挑战，但该项目提供了一个引人注目的愿景，并为未来创建更强大的“思维工具”指明了方向。

新高斯溅射查看器：支持运行时代码修改

项目简介
这是一个交互式3D高斯溅射查看器与编辑器，名为splatviz。它允许用户实时编辑高斯溅射点、并排比较不同场景、附加到训练运行中，并通过Python代码片段检查渲染数据。

核心功能

• 实时编辑高斯溅射对象
• 多场景对比
• 附加到正在进行的3DGS训练过程
• 通过Python代码动态修改渲染流程
• 提供视频小部件、外部编辑文本支持等最新特性

安装要求

• 需安装uv工具及对应版本的CUDA Toolkit（支持11.8、12.6、12.8、13.0）
• Windows系统可能需要安装Visual Studio 2022 C++构建工具

基本使用

1. 克隆仓库并同步环境：

   git clone https://github.com/Florian-Barthel/splatviz.git
   cd splatviz
   uv sync --extra cu118  # 根据CUDA版本选择
   

2. 安装光栅化器：

   uv pip install --no-build-isolation git+https://github.com/ashawkey/diff-gaussian-rasterization.git
   

3. 启动查看器并附加到训练进程：

   python run_main.py --mode=attach
   

   默认监听地址为127.0.0.1:6007，可通过--host和--port参数修改。

主要小部件

• Edit小部件：在渲染前运行Python代码，实时修改高斯对象
• Evaluate小部件：检查渲染变量并通过直方图可视化数值

版本更新摘要

• 1.3.0版（2026-05）：新增视频小部件、简化安装、支持外部编辑文本、可调整渲染窗口大小
• 1.2.0版（2025-09）：修复评估小部件、优化场景加载、GAN模式独立至ganviz项目
• 1.1.0版（2024-08）：引入训练小部件与实时附加模式、重构渲染并改进鼠标控制、新增多场景对比

技术参考

• 基于pyimgui、imgui_bundle构建GUI
• 受EG3D视觉化工具启发
• 集成3D高斯溅射技术与自组织高斯网格压缩方案
• 使用diff-gaussian-rasterization作为光栅化核心

Shapeshift 是一个 TypeScript 库，它利用键的向量嵌入来实现具有不同结构的 JSON 对象之间的智能映射。该库的核心思想是根据键名的语义相似性（而非完全匹配）来连接源对象和目标对象，从而支持灵活、自动化的数据转换。

主要特点：

• 基于语义的映射： 依据键名的语义相似度进行匹配，而非依赖相同的键名。
• 支持嵌套结构： 能够处理源对象和目标对象中的嵌套对象，实现深层次的结构转换。
• 多嵌入服务提供商： 支持 Cohere、OpenAI 和 Voyage 等主流嵌入模型服务。
• 高度可配置： 允许自定义使用的嵌入模型和相似度阈值（默认为 0.5）。
• 类型安全： 原生支持 TypeScript。

工作原理：

1. 展平： 将源对象和目标对象（包括其嵌套结构）展平为单级对象，并使用点表示法（如 address.street）保留原始的键路径信息。
2. 计算嵌入： 使用配置的嵌入提供商和模型，为展平后的所有键计算向量嵌入。
3. 语义匹配： 对于源对象中的每个展平后的键，在目标对象的展平键中通过余弦相似度找到语义最接近的键。
4. 条件映射： 若匹配到的键对相似度分数超过设定的阈值，则将源键的值赋予目标键。
5. 重构： 将映射后的结果取消展平，恢复成目标对象原有的嵌套结构。

使用方式： 通过实例化 Shapeshift 类并调用其 shapeshift 方法即可完成转换。需要提供嵌入服务的配置（客户端类型和API密钥）以及可选的配置项（模型、阈值）。

const shiftedObj = await shapeshifter.shapeshift(sourceObj, targetObj);

局限性：

• 映射质量高度依赖键名的语义相关性，键名差异过大时可能无法正确映射。
• 处理极深的嵌套结构可能会影响性能。

该项目采用 MIT 许可证。

Amiga 2000 – Codename: Tesseract 项目概述

该项目是一项从零开始完全定制一台Amiga 2000电脑的复杂工程，旨在构建全新的主板、机箱及配套硬件。

项目背景与目标

• 源于一次未完成的Amiga 1000 Phoenix升级项目，转而启动全新定制方案。
• 项目代号“Tesseract”，由作者与MrTrinsic协作完成，MrTrinsic负责采购并提供大部分硬件。
• 初期计划：制作一块可工作的Amiga 2000主板，并集成至定制机箱中。

主板构建过程

1. PCB获取：基于Floppie209逆向工程设计的新主板PCB。
2. 元件采购与焊接：
   • 作者从不同供应商采购元件，但建议从单一供应商采购以减少等待时间。
   • 使用3D打印工具弯曲元件，并用纸胶带固定组件以便焊接。
   • 焊接过程中遇到一些问题，但均已解决。
3. 电源模块（PSU）：
   • 初期计划使用ATX转Amiga适配器，需重新接线匹配A2000电源接口。
   • 详细说明了各线路对应电压（+5V、+12V、-12V等）。
4. 定制芯片安装：
   • 为便于更换石英谐振器，改造了DIP插座。
   • MrTrinsic希望配置2MB CHIP RAM，需修改FAT AGNUS芯片模块。
   • 问题：修改模块与新主板不兼容；拆焊过程中险些损坏主板。
   • 解决方案：改用标准PLCC插座和常规FAT AGNUS芯片进行测试。

测试与成功

• 在不安装定制芯片的情况下，首先对电源模块进行测试。
• 安装定制芯片后，系统成功启动，表明主板构建基本完成。

机箱改装

1. 机箱选择：采用TF5型机箱（曾由Karma Digital等公司销售）。
2. 改装工作：
   • 移除原为PC主板设计的螺柱。
   • 通过测量和切短螺丝顶端（节省2mm空间）优化布局。
   • 使用Dremel类工具移除其他障碍物。
3. 主板安装：
   • 制作硬纸板模板，切割聚乙烯板作为隔离层置于主板下方。
   • 将主板固定于机箱内。

项目进展与后续

• 目前已完成主板构建及初步机箱安装，配件和模块已部分就位。
• 项目仍在进行中，预计还需至少四篇后续文章详细说明更多改装与扩展内容。

附注

• 作者提醒仔细阅读相关文档和说明文件。
• 项目协作模式由MrTrinsic提供硬件，作者负责实施与调试，双方共同推进。

文章标题指向TechCrunch——一个曾主导创业新闻报道的网站——如何逐渐偏离其初衷。内容开篇追溯至2005年初，律师Michael Arrington与企业家Keith Teare共同创立了Archimedes Ventures基金。该基金旨在投资Web 2.0领域，即当时新兴的网络应用生态。在此期间，他们开发了多项产品，其中一个关键项目是名为Edge.io的在线分类广告服务，其目标是在各个网站上复制Craigslist的运营模式。提供的文本在此中断，完整文章需通过免费阅读或付费订阅方式获取后续内容。

Google索引策略的根本性转变：从全面索引到选择性收录

历史回顾：从快速索引到SEO军备竞赛

十年前，Google能迅速索引新发布的内容，几分钟内就使其可搜索。这体现了其“组织全球信息，使其普遍可及”的使命。然而，这种可预测性导致了低质内容泛滥、链接买卖等滥用行为，迫使Google推出Panda、Penguin等一系列算法更新来打击操纵性SEO，开启了与SEO行业长达数年的博弈。

“内容为王”理念的兴衰

在此背景下，行业兴起了“内容为王”的理念，认为优质内容能自然吸引链接并获得高排名。但这从未完全成立：一方面，许多优质内容并未获得应有排名；另一方面，谷歌算法也无法真正判断何为“优质”。该理念更多是行业的一个简化目标和谷歌面对复杂技术质疑时的一个便捷解释。

AI内容革命与谷歌的生存危机

2018年后，AI生成内容的兴起（如GPT）预示着无限量、类人内容的可能性，这直接冲击了谷歌的内容生态。谷歌的应对策略是双重的：

1. 推广E-A-T（专业性、权威性、可信度）概念：实践中，这倾向于青睐知名品牌和权威网站。
2. 放弃索引一切的使命：转向极端选择性索引。

当前现实：“默认不索引”与选择性收录

谷歌现在运营基于 “默认不索引” 的原则，只在认为“真正需要”时才收录内容。决定是否索引的因素包括：

• 极端内容独特性：内容需真正新颖或填补重大空白，仅话题覆盖少还不够。
• 感知的权威性：权威网站可能获得更广泛的索引，但仍无保证。
• 品牌知名度：知名品牌内容更易被索引，而小博主或未知网站面临极高门槛。
• 临时索引与取消索引：新内容可能被快速索引（以免错过突发新闻），但随后常被取消索引，且不再恢复。初始被索引不等于获得长期认可。

后果与影响

这一转变将谷歌从综合性搜索引擎变成了一个排他性目录。

• 对用户而言：大量有价值的信息可能因谷歌选择不收录而无法被发现。
• 对内容创作者而言：挑战巨大，尤其是小型创作者。关键不再仅仅是创作优质内容，而是要说服谷歌你的内容对其索引是“绝对必要的”。
• 值得注意的是：一旦内容成功跨越极高的索引门槛，其排名往往表现良好，仿佛索引本身已成为排名的主要障碍。但达到这一阶段已变得异常困难。

总结：谷歌已从追求“索引一切”的开放模式，转变为基于内容独特性、网站权威性和品牌影响力的高度选择性索引模式。这标志着其核心角色和使命的深刻变化。

Quartz：Go 语言的确定性时间测试库

解决不稳定测试的痛点

在开发中，不稳定测试危害极大，它使开发者失去对测试结果的信任，可能导致问题被掩盖并拖慢开发周期。测试依赖于时间的代码尤其困难，因为等待真实时间流逝不切实际。

传统方法是将时间值（如“晚上8点”或“30分钟”）在测试时设为可配置的短值。但这存在两个主要问题：

1. 可重复性：测试可能在不同时间运行，可能遇到夏令时等边缘情况，导致结果不一致。
2. 确定性：大幅压缩时间（如30分钟压缩到30毫秒）可能导致操作系统调度不确定性，使测试执行顺序不符合预期，从而产生“假阴性”或“假阳性”结果。

Quartz 库的核心设计

Quartz 是一个 Go 语言测试库，旨在通过模拟时间来解决上述问题。其设计受到现有库（如 benbjohnson/clock、tstest.Clock 等）的启发，但针对其局限性进行了改进。核心思想是提供一个 Clock 接口，在生产代码中使用真实时钟，在测试中使用模拟时钟，从而实现测试的可重复、确定性和快速执行。

关键创新：解决竞态条件

文章指出，先前的库在编写涉及 Ticker 的测试时容易出现竞态条件。Quartz 通过以下机制解决：

1. 同步的 TickerFunc：Quartz 鼓励使用 TickerFunc 函数，该函数在每次 tick 时被调用。当推进时钟时，Advance 方法返回一个对象，通过调用其 Wait() 方法，可以确保所有已触发的 tick 和 timer 处理完成后测试再继续，从而消除了处理顺序的竞态。
2. 陷阱机制：Quartz 允许为对时钟的调用（如 TickerFunc）设置“陷阱”。这使得测试代码可以确定性地控制这些调用的启动时机，确保后续的时钟推进操作产生可预测的效果。

应对复杂的时间依赖

对于测试中存在多个异步时间调用的情况（例如测量耗时、实现空闲超时），Quartz 利用陷阱功能允许测试在第一个时间调用完成后、第二个调用开始前，手动推进时钟，从而精确模拟时间间隔。此外，所有函数都支持标签，使得陷阱可以匹配特定的调用。

对应原则：清晰的测试时间流

Quartz API 设计遵循“对应原则”，力求使单元测试易于理解：

• 单调的时间流：测试代码从上到下执行时，模拟时间同步地、单向地向前推进。
• 明确的状态断言点：通过同步的 Advance/AdvanceNext 与陷阱机制结合，测试可以在被测代码处于确定、无竞态的状态时进行断言，避免使用轮询（Eventually）、Sleep 或 runtime.Gosched() 等非确定性手段。

当前状态与未来

• 版本：当前为 v0.1.0，表明在发布稳定的 v1.0 之前，API 仍有可能调整。
• 稳定性：已在 Coder 内部使用并认为其足够稳定，推荐公开试用。
• 行动号召：鼓励开发者试用、star 项目，并通过 GitHub issue 提出问题或功能请求。

研究背景与目的

月球表面已发现多个潜在的地下开口（月球坑），这些结构在科学研究和未来人类居住方面具有重要价值。然而，这些坑洞是否通向具有广阔地下空间的洞穴通道一直存在不确定性。本研究旨在通过雷达数据分析，验证月球坑洞下方是否存在可进入的地下洞穴，并评估其作为未来月球基地的潜力。

研究对象与数据来源

研究聚焦于宁静海坑（Mare Tranquillitatis pit, MTP），这是一个具有垂直或悬垂岩壁及倾斜坑底的椭圆形天窗。研究主要使用了2010年月球勘测轨道飞行器（LRO）搭载的Mini-RF仪器获取的雷达图像，并结合了LROC窄角相机（NAC）图像和数字地形模型（DTM）。

研究方法

研究团队利用3D雷达模拟技术，构建了包含不同几何参数（如通道屋顶与地板的坡度、通道宽度等）的MTP及其地下结构模型。通过将模拟生成的雷达反射信号与实际Mini-RF实验数据进行相关性分析和对比，反演出地下洞穴通道的特征。此外，研究还引入了西班牙兰萨罗特岛地球类似火山坑的X波段SAR图像及3D激光雷达扫描数据作为地面真实参考，以验证雷达模拟方法的准确性。

主要发现

分析结果表明，MTP产生的部分雷达反射信号无法仅由表面地形解释，而是源自一个长达数十米的地下洞穴通道。雷达数据反演和模拟结果证实，MTP不仅是一个表面凹陷，其下方确实连接着一个可进入的、具有相当规模的地下洞穴结构。

科学与应用意义

该研究为月球表面下方存在可进入的洞穴通道提供了确凿的雷达证据。这一发现凸显了MTP作为未来月球基地选址的巨大潜力。该地下洞穴能够为宇航员和设备提供天然庇护所，使其免受月球表面强辐射、微陨石撞击和极端温差等恶劣环境的影响，从而为人类的长期月球探索、驻留以及深空探测提供重要的基础设施支持。

KUtrace：低开销Linux内核跟踪工具

KUtrace 是一种极低开销的Linux内核跟踪工具，旨在完整观察多核处理器上所有核心的全部执行时间，且无需对以任何编程语言编写的用户程序进行修改。该工具已在实际的数据中心（x86处理器）和实时自动驾驶系统（ARM处理器）中使用，用于解决长期存在的性能难题。KUtrace的设计目标是揭示实时事务或数据库处理中意外延迟响应的根本原因，同时保持极低的开销，从而确保不会扭曲被测试的系统。

本文档对应2022年3月的更新，完全替代了之前2019年的代码仓库。该目录包含与Richard L. Sites 2022年著作《Understanding Software Dynamics》（ISBN 978-0137589739）相关的文件。

主要目录与文件说明：

• book-figures目录：包含书中100多个图表的HTML文件，便于浏览上下文或发现其他性能问题（推荐使用Chrome浏览器）。
• kutrace_user_guide.pdf：提供比书中第19章更详细和最新的使用说明，是充分利用HTML文件的关键。
• hello_world_trace.html：是对book-user-code目录中hello_world_trace.c程序的跟踪示例。
• book-user-code目录：包含书中使用的所有程序及编译脚本，可在x86和Rpi4机器上编译运行。
• linux_patches_installation_guide.pdf：提供构建补丁的简要指南。
• loadable-module目录：包含实现KUtrace主要功能的配套内核模块的源代码和Makefile，支持AMD/Intel x86机器及Raspberry Pi 4-B。
• *patches-文件：包含为三个不同Linux版本添加KUtrace的原始源文件和补丁后源文件对。其中patches-linux-5.10.46-rpi4文件夹提供了构建补丁内核或整合补丁的额外文档和脚本。注意： 代码仅支持64位Linux系统；32位移植虽可行但难度较大。

许可信息： 大部分代码以BSD三条款许可证开源。针对FreeBSD的特定代码使用BSD2许可证，针对RISC-V的特定代码使用GPL-2.0许可证。根据Linux内核要求，可加载模块必须采用GPL-2.0许可证。

Ly：基于控制台界面的显示管理器

Ly 是一个轻量级的 TUI（类似于 ncurses）显示管理器，专为 Linux 和 BSD 设计，注重可移植性，无需 systemd 即可运行。

核心特性

• 轻量级：基于终端用户界面（TUI）。
• 跨平台：支持 Linux 和多种 BSD 系统（如 FreeBSD）。
• 灵活：不依赖特定的初始化系统（如 systemd）。

依赖项

编译时依赖

• Zig 0.16.x（必须使用发布版本，不含 -dev 后缀）
• libc
• pam
• xcb（可选，默认需要，用于 X11 支持）

运行时依赖（默认配置）

• xorg
• xorg-xauth
• shutdown
• brightnessctl

不同发行版的安装命令示例如下（如 Debian、Fedora、FreeBSD）。

支持的会话环境

Ly 支持所有其他登录管理器可用的桌面环境。它还提供了 .xinitrc 和 shell 入口。

• 若未自动检测到已安装的环境，重启 Ly 服务或系统通常可解决。
• 桌面会话文件通常位于 /usr/share/xsessions 或 /usr/share/wayland-sessions。若缺失，可在 /etc/ly/custom-sessions 中创建仅 Ly 识别的 .desktop 文件。

日志位置

可通过 /etc/ly/config.ini 配置：

• 会话日志：~/.local/state/ly-session.log
• 系统日志：/var/log/ly.log

构建与安装

手动构建

$ git clone https://codeberg.org/fairyglade/ly.git
$ cd ly
$ zig build

可在终端模拟器中测试，但认证功能无效。建议启用服务并重启系统进行完整测试。

使用不同初始化系统安装

通过 -Dinit_system 参数指定初始化系统。通用步骤为：

1. 使用 Zig 构建并安装 Ly。
2. 禁用当前的显示管理器。
3. 启用 Ly 服务。
4. 禁用 Ly 将要使用的 TTY 的原有服务（如 getty@tty2）。

具体命令因初始化系统（systemd、OpenRC、runit、s6、dinit、sysvinit、FreeBSD）而异，详见原文。

更新 Ly

安装新版本时不覆盖现有配置文件：

# zig build installnoconf

配置与控制

• 配置文件：/etc/ly/config.ini（含详细注释和默认值）。
• 验证配置：$ ly --validate-config /etc/ly/config.ini
• 键盘操作：使用方向键切换字段（如用户名、桌面环境、信息行），信息行显示消息和错误。
• 快捷键：F1 关机，F2 重启；顶角显示 NumLock 和 CapsLock 状态。
• 注意：若 X 无法启动，检查 ~/.xsession 文件是否干扰。.xinitrc 必须是可执行的脚本（包含 shebang，如 #!/bin/sh）。

备注

• 项目名称 “Ly” 致敬游戏《雷曼》中的精灵。
• 感谢 oxodao 的测试和 ashametrine 对 Zig 重写及 v1.0.0 版本的贡献。
• 欢迎通过 Liberapay 进行捐赠。

让伊丽莎白时代戏剧易于阅读和理解

这个网站旨在首次为读者提供易于阅读、且带有详尽注释的伊丽莎白时代戏剧，希望能激励人们尝试阅读这些伟大剧作。

伊丽莎白戏剧的价值与背景

• 伟大的文学遗产：伊丽莎白时代的戏剧被赞誉为“世界上最伟大文学最伟大时期中最伟大的部分”。它涵盖了从1586年克里斯托弗·马洛的《帖木儿大帝》震撼问世，到1642年伦敦剧院因清教主义浪潮而关闭的整个时期。
• 超越莎士比亚：虽然莎士比亚广为人知，但他只写了约37部戏剧。实际上，从这一时期存世的戏剧超过600部，为英语语言爱好者提供了一生都读不完的享受源泉。

本网站的独特优势

与大多数仅提供原始扫描页面或纯文本的在线资源不同，本网站对戏剧进行了现代化编辑和注释，使其易于理解且令人满足。

1. 创新的旁注格式：注释直接出现在对应台词的旁边，提供了流畅、无干扰的阅读体验。这区别于其他网站需要点击图标或查看页脚注释的方式，大大降低了阅读的繁琐感。
2. 提供可制作的剧本：网站正在逐步提供各戏剧的剧本格式版本，目标是促进这些戏剧在现代得以制作和上演。所有剧本均包含行号。
3. 完全免费：网站上所有戏剧均可免费获取。

“伊丽莎白戏剧”的界定

尽管“伊丽莎白时代”严格意义上指女王伊丽莎白一世在位期间（1558-1603年），但为方便起见，本站所指的“伊丽莎白戏剧”也包括了之后詹姆斯一世和查理一世统治时期，直至1642年剧院关闭前所创作的戏剧。

网站创始人与资源

• 创始人背景：创立者拥有超过15年研究伊丽莎白戏剧的爱好，曾耗时数年为个人使用制作了莎士比亚戏剧的注释汇编，并阅读了超过250部同期戏剧。该项目于2016年构思并诞生。
• 其他资源：文章指出，除莎士比亚外，提供现代可读版本的伊丽莎白戏剧网站非常少。提供注释戏剧的网站更少，仅有以下几处：
  • shakespeare-navigators.com：提供13部莎士比亚戏剧，注释格式与本站类似，并配有插图链接。
  • Thomas Middleton 戏剧：由 Chris Cleary 在线提供。
  • Richard Brome Online：提供其全部编辑注释作品。
  • DivineDotComedy.org：提供约翰·德莱顿等多位剧作家的注释剧本，由 Jacob Rabinowitz 管理。
  • versemeter.wordpress.com：专注于伊丽莎白时期诗歌格律与韵律研究的专家博客，由 Keir Fabian 撰写。

文章摘要

本文探讨了自动化测试用例缩减的过程、原理与实践，核心是利用自动化工具替代繁琐的手动操作，以高效定位软件缺陷的根本原因。

自动化缩减的价值与原理

手动缩减测试用例是一个重复、机械且易出错的过程，涉及反复删除代码、运行命令并判断结果。自动化缩减器（如C-Reduce、Shrinkray）接管了这一过程。它们的基本“算法”与手动方法相同，但用启发式策略替代了人工的直觉判断，从而能更快地尝试大量删除（甚至并行执行）。自动化缩减器主要控制两个环节：选择要删除的部分（基于启发式的盲目猜测）和决定何时停止（当启发式无法再找到可安全删除的代码时）。剩下的核心环节是判断修改后的测试用例是否仍能复现缺陷，这需要用户提供一个兴趣测试脚本。

编写兴趣测试脚本

兴趣测试是自动化缩减的关键输入，它是一个脚本，用于检查当前版本的测试用例是否依然存在目标缺陷。根据约定，脚本在测试“有趣”（即存在缺陷）时应返回退出状态0，在“无趣”时返回非0状态。文章以使用Shrinkray缩减器调试一个解释器缺陷为例，详细展示了编写此类脚本时常见的挑战和四个核心技巧：

1. 技巧一：使用Shell取反操作符：当程序因缺陷崩溃（非0退出状态）时，需用!命令反转退出状态，以符合“有趣即0”的约定。
2. 技巧二：添加“非虚假”检查与set -e：在尝试触发缺陷前，应加入前置检查，确保测试输入本身是格式正确的。使用set -e可使脚本在任何命令失败时立即中止，表明“无趣”。例如，先通过一个无缺陷的参考解释器运行测试。
3. 技巧三：使用grep匹配特定错误信息：缺陷可能触发多种错误。用grep精确匹配目标缺陷的特有错误信息，可以避免缩减器聚焦于其他无关错误。grep的退出状态恰好可用于指示是否匹配。
4. 技巧四：偶尔提供手动帮助：当缩减器因测试脚本的限制而无法进一步缩减时，可手动调整测试代码（如将命令行参数替换为常量），为缩减器创造更优的条件。

实践结果

通过应用这些技巧，作者成功引导Shrinkray生成了一个高度缩减的测试用例，清晰地重现了目标缺陷。该用例与手动缩减的结果不同，但同样有效，甚至更易于在参考解释器中验证其预期行为。文章指出，若要进一步优化（如避免缩减后出现多重定义标签），可能需要补充更精细的“非虚假”检查。整个案例生动说明了自动化缩减的高效性及其对精确的兴趣测试脚本的依赖。