Kagi 搜索引擎批评要点总结

一、财务问题

• 资金使用不当：Kagi 在 670k 融资中，将约三分之一用于在德国建立 T 恤印刷公司，免费发放 2 万件印有吉祥物（无品牌名称）的 T 恤，被质疑资金管理混乱。
• 税务疏忽：公司近两年未缴纳销售税，后期被迫调整价格补缴，暴露财务管理漏洞。
• 可持续性存疑：员工仅约 16 人（半数全职），同时运营搜索引擎、AI 工具、浏览器 Orion 及规划中的邮箱服务，资源分散且多数项目未盈利。

二、产品方向争议

• AI 优先策略：Kagi 原为 AI 公司，后转向搜索，但持续投入 AI 工具（如 FastGPT、即时摘要、侧边栏助手等）。创始人 Vlad 坚信 AI 是搜索未来，与部分用户逃避 AI 的需求冲突。
• AI 质量问题：FastGPT 被指提供错误信息（如影视剧细节错误），且 AI 生成答案常不准确，削弱搜索可靠性。
• 隐私承诺与实践矛盾：Vlad 对隐私问题态度轻视，认为电子邮箱不属于个人信息，对 GDPR 等法规缺乏重视，且用户数据使用政策模糊。

三、创始人管理风格

• 决策专制：Vlad 对外部批评回应封闭，坚持己见，不接受不同意见（如拒绝添加自杀求助链接，认为“有偏见”）。
• 不当沟通行为：作者发布批评文章后，Vlad 要求电话沟通，遭拒后仍发送长篇反驳邮件，被认为具有威胁性且不专业。
• “去政治化”立场：Vlad 强调“避免政治”，但其对偏见的定义被指主观（如认为三星评价“天然无偏见”），并推崇用 AI“过滤新闻偏见”。

四、核心质疑

• 隐私真实性：Kagi 宣称注重隐私，但创始人淡化数据风险，且公司可能利用搜索数据训练 AI 模型。
• 商业模式可持续性：过度依赖 AI 战略与有限资源矛盾，财务透明度低，长期运营能力存疑。
• 用户知情权：许多用户未察觉 Kagi 的 AI 深度投入，作者呼吁知情者自行评估风险。

五、后续事件

• 作者因批评文章收到 Vlad 邮件骚扰，公开邮件记录后引发社区讨论，部分用户因此退出 Kagi。
• 作者重申初衷并非鼓动弃用 Kagi，而是为关注隐私与 AI 问题的用户提供决策信息。

OptiGap是一种新型传感器系统，主要应用于软体机器人领域，用于实现“弯折定位”——能够准确检测沿其长度弯折的位置。OptiGap传感器利用柔性光管内的空气间隙，通过对光传输的编码，实现位置感知。其名称融合了“光学”（optical）与“间隙”（gap）的核心原理。

研发过程始于作者在光管弯折实验中发现，贴有电工胶带的透明3D打印TPU（热塑性聚氨酯）丝材在弯折点光传输显著衰减。进一步实验验证了这一假设，奠定了OptiGap传感器的原理基础。随后，作者改进了结构，采用切割丝材并用硅胶套重新连接，形成小空气间隙，发现弯折时光信号强度变化可与位置关联。

OptiGap的工作原理为：光管切面在空气间隙处发生位移时，光传输量减少，弯折角度越大，光能丢失越多。据此制作一系列空气间隙，形成可编码的光信号模式，并采用朴素贝叶斯分类器对位置进行解码。其本质类似于线性编码器，用编码模式绝对定位弯折点。

编码方案中，OptiGap采用“逆格雷码”（Inverse Gray Code）：连续的数值在二进制下相差最大位数，便于区分不同弯折位置。丝材通过对应代码切割形成不同模式空气间隙，原型采用3比特编码，支持8种弯折位置。

系统原型使用3根透明TPU丝材，各自按照不同空气间隙模式布设，通过光学合束器汇聚信号。为减小体积和提升柔韧性，后续采用PMMA（聚甲基丙烯酸甲酯）光纤（500、750、1000微米），最终确定500微米适用。

在信号读取硬件方面，作者从复杂的VL53L0X飞行时间传感器转为更简单的光电二极管与红外LED，整体系统以STM32微控制器为核心，实现数据读取与处理。为实现实时位置判别，将朴素贝叶斯分类器集成到STM32，结合ARM CMSIS-DSP库，提升效率与准确率。

数据处理流程包括先将传感器输出信号按各空气间隙模式拟合高斯分布（利用Python和scikit-learn GNB建模），预处理后计算分类概率，保存为头文件用于嵌入式端。信号过滤采用两级方案：移动平均滤波和卡尔曼滤波，进一步减少噪声提升判别精度。

文章包含多阶段动图与原理仿真展示，从TPU丝材传感器组装、光信号衰减、数据拟合到最终分类、实际操作、支持水下应用。此外，OptiGap已集成至EneGate模块化驱动与传感系统，并开发了对应的微型PCB，验证了在实际软体机器人结构中的应用（将在RoboSoft论文中详述）。

作者提及OptiGap的商业化进程，并展示了与自研EneGate PCB系统集成的成果。研究详细过程与技术文档已在论文中公布。主要技术规格、材料推荐及后续研究方向（如更复杂的微型光学接口和系统集成）亦有所介绍。

OptiGap代表了一种利用3D打印丝材和光学编码，实现弹性结构弯折定位的新型传感器解决方案，面向软体机器人、动态结构监测等领域。

该网页展示了一个热泵性能数据共享与比较的开源平台界面，主要包含以下内容：

核心功能

• 数据共享与比较：平台允许用户分享其热泵系统的性能数据，便于比较分析。
• 系统列表：以表格形式展示用户分享的系统数据，包含系统ID、用户名、共享状态（共享/私有）、发布状态（已发布/待审核/未发布）以及查看链接。

关键数据指标

• 性能统计：页面底部显示所选系统的总计信息，包括：
  • 系统数量。
  • 基于用户选择的时间范围（如“最近365天”），展示平均性能指标（SPF或COP）。
  • 基于总制热量与总耗电量计算得出的平均性能指标（COP）。

界面元素

• 筛选与加载：页面包含数据筛选工具（如电价选择）、数据浏览器，并显示“正在加载系统...”状态。
• 共享与审核机制：系统具有共享设置（公开/私有）和发布审核流程。

EXODUS: 在用户空间运行的TempleOS移植版

核心概述

EXODUS是一个将TempleOS内核移植到用户空间运行的项目，支持x86_64架构的Linux、Windows和FreeBSD系统。它允许用户无需虚拟机即可体验TempleOS，提供了完整的图形界面（GUI）和命令行界面（CLI）模式。

主要功能

• 宿主文件系统集成：T:/ 对应系统根目录，Z:/ 对应EXODUS启动目录。
• 完整GUI：基本保持原版TempleOS的图形界面。
• CLI模式：可用于自动化运行网络服务器及编译EXODOS内核本身。
• 网络支持：内置网络功能，相关代码位于 T:/Community 和 T:/Server 目录。
• 内置文档：位于 T:/Server，通过本地网页（localhost:8080）访问。
• 社区软件：包含第三方应用程序和游戏（如 Satania-buddy, BlazeItFgt2）。
• 快捷键：CTRL+ALT+P 切换深色模式。

与原版TempleOS的差异

• 用户空间运行：在Ring 3下执行，上下文切换比虚拟机或原生硬件慢，但不影响一般性能。
• 内核级操作限制：Ring-0指令（如HLT）和相关例程不可用，执行会引发错误。
• 寄存器使用调整：FS和GS寄存器改为指向CTask/CCPU结构体指针，而非原版的结构体映射。
• 键位修改：Windows键功能被替换为Alt键。
• 网络支持：原版因代码行数限制未实现网络功能，但EXODUS支持网络，这符合其设计者关于“理想PC需要网络”的理念。

构建说明

Linux/FreeBSD

1. 安装CMake和SDL2开发头文件。
2. 执行以下命令：

   mkdir build && cd build
   cmake ..
   make -j$(nproc)
   

   生成的exodus二进制文件位于目录中。构建过程中的警告（WARNs）通常不代表失败。

Windows

1. 安装MSYS2，并使用MINGW64环境。
2. 安装依赖包：

   pacman -Sy git mingw-w64-x86_64-{gcc,SDL2,cmake}
   

3. 克隆仓库后，在项目目录执行：

   mkdir build && cd build
   cmake ..
   ninja
   

   生成的exodus二进制文件位于目录中。

故障排查

若构建后运行卡住，可在启用调试标志（-DBUILD_HCRT=0）后使用gdb/lldb获取回溯信息，并提交至项目问题追踪器。

运行方式

• 启动：./exodus
• CLI模式及其他选项：./exodus -h

贡献与依赖

• 开发参考项目文档。
• 内置简明的HolyC语言参考。
• 第三方依赖：argtable3、dyad、map、vec、isocline等。
• 主要贡献者：nrootconauto（负责Wiki及T:/目录的大量工作）。

DNS over Wikipedia 是一个利用维基百科验证并重定向域名的系统。当用户输入以 .idk 结尾的域名时，系统会自动查询维基百科上对应网站的文章，从其信息框中提取官方URL进行重定向。

核心功能与优势：

• 基于权威来源：维基百科收录了热门网站的官方链接，相较于可能被审查或存在虚假结果的搜索引擎（例如谷歌搜索 "Piratebay" 可能显示虚假网站），维基百科能提供更准确、更新的链接。
• 示例：在浏览器地址栏输入 scihub.idk/，系统会将其重定向至 https://sci-hub.tw（以撰写时为例）。
• 工作原理：系统通过查询维基百科文章来获取正确网址，避免了直接使用搜索引擎可能遇到的审查或误导性结果。

安装选项：

• Chrome 扩展
• Firefox 扩展
• 可选的 Rust 重定向脚本

Rabbit Telepoint基站：地铁站里的三十年技术遗迹

位于伦敦七姐妹地铁站（Seven Sisters tube station）内的Rabbit Telepoint基站，是上世纪90年代初一项短命移动通信技术的遗留产物。该设备已闲置超过30年，每天被数千名乘客忽略，却默默见证了一段技术历史。

Rabbit服务的背景与技术特点

• 起源：1989年，英国政府颁发了四张Telepoint服务牌照，旨在通过低成本服务与当时昂贵的移动网络（Cellnet和Vodafone）竞争。预计用户数可达700万。
• 运营商：Rabbit由香港企业集团和黄（Hutchison）推出，它收购了一家持有牌照的公司。其他三家竞品（Mercury Callpoint、Ferranti’s Zonephone、BT’s Phonepoint）在Rabbit上线前已倒闭。
• 功能限制：Rabbit手机只能在距离基站100码（约91米）内拨打电话，且无法接听来电（可通过寻呼机通知回拨）。
• 核心优势：
  • 费用低廉：通话费约每分钟20便士，远低于当时手机的每分钟50便士。
  • 家用功能强：Rabbit手机可配家用基站，作为数字无绳电话使用，音质远优于当时常见的模拟无绳电话，且机身更小巧。

商业历程与突然关闭

• 上线与扩张：Rabbit于1992年5月上市，销售初期强劲，吸引点不仅在于移动通话，更在于其作为优质家用电话的功能。基站覆盖从曼彻斯特迅速扩展至全国。
• 突然终止：1993年11月5日，和黄电信宣布关闭Rabbit服务。因该公司已获得新一代移动网络（即后来的Orange，现EE）牌照，决定放弃Telepoint业务。
• 关闭后的意外：
  • 尽管提供了退款和未来折扣，许多用户因手机家用功能不受影响而拒绝归还设备。
  • 关闭后，手机销量反而上升，因人们继续用作家用电话。
  • 基站最终在1993年12月彻底停运。

遗迹存留

尽管服务早已终止，但类似市政设施，其移除往往滞后。七姐妹地铁站维多利亚线扶梯旁的Rabbit基站，便是典型例子。此外，在沃特福德枢纽站（Watford Junction）7/8站台的候车室内，还保存着一个状态更好的同类设备。

这段历史展现了通信技术发展中的一个短暂篇章：Rabbit曾因低成本和家用优势被寄予厚望，却因全移动网络的兴起而迅速淘汰。其遗留硬件，成为技术迭代中偶然存留的见证。

组织 OpenStreetMap 测绘派对的经验与建议

这篇文章分享了作者组织测绘派对的经验和不断调整的建议，旨在帮助社区组织者吸引参与者并提供良好体验。

组织流程要点

1. 场地选择：应选择安全、适宜步行的区域（如市场），避免室内商场。可提前远程绘制建筑物和街道作为参考。
2. 宣传与邀请：需提前至少两周在OSM日历、邮件列表、论坛、本地社区、FOSS圈子及社交媒体发布公告。务必收集参与者的电话号码以便可靠沟通。
3. 沟通平台：强烈推荐使用Jabber/XMPP以保护社区隐私和自由，而非Telegram/Discord/WhatsApp等专有平台。
4. 设备准备：建议参与者携带充电设备。组织者应备用手机、笔记本电脑、充电宝、数据线、水和零食。强烈建议携带胡椒喷雾以防万一。
   • 测量工具：卷尺（裁缝用、木工用）或激光测距仪对于测量路宽、护柱间隙、限高等物理属性（maxwidth:physical）非常有用。
5. 集合与教学：在测绘区域附近的公园集合。必须严格遵守时间安排，不等待迟到者。教学应避免信息过载，提前规划课程，并预先讲解常见问题（如不要复制其他地图、地址字段含义、电话号码格式等）。
6. 测绘执行：将参与者分成2-3人小组，分配区域并约定汇合时间（如一小时后），随后一起审核更改。

编辑器与应用的选择策略

这是作者反复权衡的核心问题。策略从最初推荐新手使用Organic Maps/OsmAnd，转向了推荐更富趣味性的专门编辑器，认为这可能更利于长期参与。

• Organic Maps：仍应作为入门推荐，因其离线、免费、可即时查看自己的贡献。但不作为主要编辑器。
• OsmAnd：提及为高级用户的选项（如增量更新、GPS轨迹、多模式路由），但非教学重点。
• StreetComplete：具有游戏化特性（任务、计分），但任务由应用决定，不适用于需要集中测绘特定要素的派对。
• iD、Vespucci、Go Map!!：允许用户“绘制”方式（如道路、建筑物），这个过程可能比“添加节点并填表”更有趣。支持室内、远程及实地移动测绘等多种形式。
  • Vespucci：虽然学习曲线陡峭，但通过良好的教学可以克服。学习一门技能本身能驱动长期参与。
• Every Door（作者的首选）：
  • 优点：跨平台；界面相对简单；是能添加带细节的建筑节点（如building:levels用于3D地图）的唯一“简单”移动编辑器；原生支持航空影像，适用于欠测绘区域；有提高效率的自动应用标签、便捷的定向添加接口；自动生成变更集注释。
  • 缺点：缺少罗盘指示（最新版显示行走路径有所缓解）；旋转地图后无指示且复位不便；不支持印度地址常用标签（如addr:block），需变通方案；无暗色模式。
  • 尽管有缺陷，但因其功能和易用性的平衡，成为作者最近移动测绘派对的主力工具。
• openstreetmap.org：应在测绘结束后向参与者介绍，以便他们查看编辑历史、参与讨论。

总结与反思

组织测绘派对是一个不断学习和优化的过程。作者强调，选择编辑器应权衡参与者乐趣、学习曲线和长期参与度。虽然存在挑战（如地区分布不均、参与者技能差异），但通过精心策划和合适工具的引入，可以有效地壮大社区并改善地图数据。文章最后提到相关讨论在Hacker News上获得了积极反响。

为什么推荐 Renovate 而非其他依赖更新工具

本文作者是 Renovate 的忠实用户，基于约5年的使用经验（包括自托管和托管服务），并与 Dependabot、Snyk 等工具进行比较后，认为 Renovate 是依赖更新领域的最佳选择。

核心优势

1. 高度可配置性与可共享配置

• 可共享的配置预设：Renovate 支持创建可扩展的配置预设。团队可以定义统一的更新策略（如AWS SDK更新频率、PR标签），各仓库只需extends该预设即可保持一致，极大简化了跨仓库配置管理。
• 对比 Dependabot：Dependabot 需要为每个仓库手动编写详细的 dependabot.yml，配置调整需逐一修改，流程繁琐且不易自动化。

2. 优秀的默认设置与轻松上手

• 自动检测：Renovate 能自动识别仓库使用的生态系统并提交更新 PR，无需大量手动配置。
• 内置最佳实践：提供 config:best-practices 等预设，帮助团队轻松遵循社区最佳实践。

3. 灵活的更新分组

• 可将多个依赖更新合并到一个 PR 中（如将所有 AWS SDK 更新或所有补丁更新分组），显著减少 PR 噪音。
• 对比 Dependabot：Dependabot 的类似分组功能近期才推出，而 Renovate 已拥有多年。

4. 支持一次性命令行执行

• Renovate 是开源工具，可在命令行单独运行，便于执行全组织范围的特定版本升级或低频更新。

5. 广泛的生态系统支持

• 支持的包管理器和生态系统更全面：不仅限于 GitHub 平台，也支持 GitLab CI、CircleCI 等。
• 支持自定义依赖管理：通过regexManagers，可以管理非标准依赖，如 Makefile 中通过 curl 安装的工具版本、Dockerfile 中的 ARG 定义或公司内部配置文件中的版本号。

6. 依赖仪表盘

• 提供一个中央视图，集中展示所有检测到的依赖、待处理的 PR、失败的更新等信息，便于一目了然地掌握项目更新状态。
• 支持通过仪表盘手动批准重大版本升级等操作，实现更精细的更新控制。

7. 开源与社区

• 开源性质：Renovate 采用 AGPL3 许可证，确保平台托管方必须开源其修改，保障用户权益。其公司 Mend 持续投入开发，保证了项目的可持续性。
• 活跃的社区与维护：社区贡献活跃，维护团队响应迅速，项目运行良好。
• 对比：Snyk 是闭源商业软件；Dependabot 现已更改为 MIT 许可证。

8. 出色的文档

• 文档质量高，包含详细的与其他工具的对比表和升级最佳实践指南，任务指引清晰。
• 复杂问题可通过社区讨论解决，并有机会反哺文档。

总结

作者认为，凭借其卓越的可配置性（通过共享预设实现团队一致性）、智能的默认设置、强大的更新分组功能、广泛的生态和自定义支持、实用的依赖仪表盘、开源的本质以及出色的文档，Renovate 在综合体验上远超 Dependabot 和 Snyk 等其他依赖更新工具。无论是自托管、使用托管服务还是偶尔在命令行使用，Renovate 都能显著提升工程团队的依赖管理效率。

总结

背景与问题 Lago，一个开源的用量计费平台，在扩展过程中面临数据库性能瓶颈。随着每分钟需要处理数百万事件，单一的PostgreSQL（OLTP数据库）堆栈导致严重的负载和性能下降，无法满足其事件引擎的扩展需求。

解决方案：混合数据库架构 Lago 采用了混合数据库策略：

• 保留 PostgreSQL：用于存储所有其他业务关键数据（如收费、发票、优惠券等），利用其事务原子性和一致性。
• 引入 ClickHouse：专门用于处理和分析海量的流式事件数据。ClickHouse 是一个OLAP数据库，擅长高吞吐量写入和复杂分析查询。

OLTP vs. OLAP 核心区别

• OLTP（如PostgreSQL）：面向事务处理，支持读写、更新、删除，强调原子性和一致性，适合需要精确数据一致性的场景。
• OLAP（如ClickHouse）：面向分析处理，擅长处理大批量写入和复杂聚合查询（如求和、平均），能近似快速地返回结果，但在数据修改和删除方面表现不佳。其列式存储结构使得按列扫描和聚合操作非常高效。

选择 ClickHouse 的关键特性 ClickHouse 凭借以下特性成为理想的OLAP解决方案：

1. 动态物化视图：能在新数据摄入时自动高效刷新，无需手动快照更新。
2. 专用引擎：为特定数学函数（如求和、平均）提供了优化的计算引擎。
3. 向量化查询执行：利用硬件并行处理（SIMD）加速查询。

Lago 的 ClickHouse 实施细节

• 用途：仅用于存储和处理原始的、可计费的事件流数据。架构简单，主要包含 raw_events_queue（来自 Kafka 的事件流）、events_raw_mv（物化视图，将JSON元数据转换为字符串数组）和 raw_events（使用 MergeTree 引擎的最终存储表，适合高写入吞吐）。
• 数据流：事件通过 Apache Kafka 流入 raw_events_queue，经物化视图处理后存入 raw_events 表。
• 查询：业务代码通过特定的服务类直接查询 raw_events 表来进行计费指标的聚合。
• 部署：未使用 ClickHouse Cloud，而是选择在现有的 Kubernetes 集群中通过 Altinity Operator 部署和管理 ClickHouse，以获得更好的灵活性、成本效益和维护便利性。

行业验证与其他案例 类似地，PostHog 和 GitLab 等开源项目也在扩展过程中从 PostgreSQL 迁移到了 ClickHouse，以处理海量事件流和分析任务，这验证了混合OLTP/OLAP架构在扩展事件驱动型应用中的普遍性和有效性。

结论 没有万能的单一数据库能够满足所有扩展需求。对于事件密集型应用如Lago，采用基于 PostgreSQL（OLTP）和 ClickHouse（OLAP）的混合架构，是应对海量事件处理和分析需求的有效策略。虽然并非所有团队都需要从一开始就采用此架构，但应为此做好准备。

DwarFS：去重高速高级只读文件系统

DwarFS 是一个专为 Linux、FreeBSD、macOS 和 Windows 设计的高速高压缩率只读文件系统。其核心是将一个目录打包成一个可挂载的镜像文件，无需解压即可像普通文件夹一样快速访问，特别适合处理具有大量相似或重复内容的大规模数据集合。

核心技术与特性

1. 去重与相似性聚类：通过相似性哈希函数对文件进行聚类，有效利用文件边界之外的冗余数据，实现极高的压缩比。
2. 智能分类框架：可以对文件甚至文件片段进行分类，并为不同类别应用最优的压缩算法（如对 PCM 音频使用 FLAC 压缩），避免对不可压缩数据浪费时间。
3. 多线程优化：文件系统创建工具和 FUSE 驱动程序均高度多线程化，能充分利用多核 CPU。
4. 快速挂载与随机访问：挂载镜像通常在毫秒级完成，支持高效随机读取，性能远超传统压缩包（如 .tar.gz, .zip）。

显著优势与性能对比

DwarFS 在压缩比、创建速度和运行时性能上显著优于其他方案：

• vs SquashFS：在包含 1139 个 Perl 安装的 47.5 GiB 数据集测试中，DwarFS 创建速度快 6 倍以上，压缩比高达 0.9%（SquashFS 为 9.3%），挂载时间从分钟级降至毫秒级，随机读取吞吐量提升数十倍。
• vs 其他格式：相比 lrzip、zpaq、wimlib 等工具，DwarFS 通常在压缩率或速度上至少有一项优势明显，且能直接挂载使用。
• 通用性能：在各类测试中（如 CI 构建产物、游戏音频资源、Boost 源码），DwarFS 展现出平衡的快速压缩和优异的压缩比，挂载后访问速度极快。

平台支持与用例

• 跨平台：支持 Linux, FreeBSD, macOS (通过 macFUSE), Windows (通过 WinFsp)。Windows 版本功能齐全但存在一些限制（如大小写敏感性、符号链接权限）。
• 典型用例：
  • 天文学摄影：高效压缩大量 FITS 图像，速度比传统工具 fpack 快约 2.5 倍，压缩率更优。
  • 数据存档与访问：将项目版本、数据集等打包为单一镜像，节省存储空间且便于快速访问。
  • 容器与分发：用于打包应用程序环境（如 Conty, Tebako），实现便携式运行。

使用与构建

• 快速入门：
  • 创建镜像：mkdwarfs -i /输入目录 -o /输出镜像.dwarfs
  • 挂载镜像：dwarfs /镜像文件.dwarfs /挂载点
  • 提取内容：dwarfsextract -i /镜像文件.dwarfs -o /输出目录
• 构建：使用 CMake 构建，依赖项清晰。提供预编译二进制文件和适用于旧系统的通用二进制文件。支持静态构建（尽管不推荐）。
• 库接口：提供多个 C++ 库（dwarfs_common， dwarfs_reader， dwarfs_extractor， dwarfs_writer， dwarfs_rewrite），支持程序化读写镜像。

其他特性

• 性能监控：内置性能监视器，可收集 FUSE 操作等组件的延迟指标。
• 高级选项：支持设置工作线程 CPU 亲和性、指定文件系统偏移量以挂载合并镜像等。
• 数据完整性：虽无内置恢复信息，但可通过 par2cmdline 等工具生成恢复文件以应对位衰减。

总之，DwarFS 是一个专注于高性能和高压缩率的只读文件系统，通过先进的去重和聚类技术，在需要快速访问大量相似数据的场景中，提供了远优于传统压缩方案和现有只读文件系统的用户体验。

事件概述： 一名26岁男子于2024年3月17日，试图从盐湖城偷乘达美航空航班前往奥斯汀。他原本持有一张西南航空的“伙伴通行证”（一种候补机票），但因该航班满员而无法成行。随后，他转向达美航空的登机口，实施了一项颇具创意的偷乘计划。

作案手法：

1. 窃取登机牌信息：该男子在登机口区域，用手机偷拍了其他乘客的登机牌，获取了其上的条形码。
2. 冒用信息登机：他使用偷拍得来的条形码，成功通过了登机口扫描，登上了飞机。
3. 躲避与等待：他并未坐在对应登机牌的座位上，而是直接躲进了机上洗手间。计划是等待所有乘客登机完毕后，再出来寻找空座位坐下。

结果：

• 当航班所有座位都已坐满后，该男子从洗手间出来，飞机开始滑行。
• 乘务员随即发现异常，飞机返回登机口。
• 警方登机将其逮捕。男子承认自己“犯了错”，并称只是想回家。
• 该航班因此延误了约30分钟。该男子目前被关押在盐湖城大都会监狱，面临联邦拘留。

视频证据： 美国广播公司《早安美国》节目公布了监控视频，显示该男子在航站楼内与其他乘客搭讪、偷拍其登机牌并随后登机的过程。

分析与评价：

• 计划的巧妙之处：作者指出，该男子的计划在技术上相当周密。在美国国内航班，登机时通常只扫描条形码而不核对证件，这给了他可乘之机。他提前于登机牌主人登机，并躲进洗手间，避免了直接冲突。
• 失败原因：计划的唯一漏洞是未能事先确认航班是否有空座位。由于航班满员，他无处可坐，导致暴露。
• 警示：尽管该男子展现了“创意”，但偷乘飞机行为不道德、风险高且收益低。此类事件时有发生，原因各异，但均不可取。

Tyde - 使用 Go 语言构建的 Linux 桌面环境

概述 Tyde 是一个遵循 Material Design 风格、易于使用的 Linux/Unix 桌面环境。它基于 Fyne 工具包开发，旨在提供良好的易用性与可开发性。项目采用 Go 语言编写，欢迎社区贡献与反馈。

技术依赖与编译

• 编译依赖：与 Fyne 工具包相同。
• 运行时依赖（推荐）：
  • arandr：用于修改显示设置。
  • xbacklight 或 brightnessctl：用于调整笔记本屏幕亮度。
  • connman-gtk：当前用于配置 Wi-Fi 网络设置。
  • 虽然不安装这些工具也能运行，但用户体验会受到影响。

安装与启动

1. 快速安装（预览模式）：

   go install fyshos.com/tyde/cmd/tyde@develop
   

   安装后，可将 tyde 作为普通 Fyne 应用运行，但此时并非作为窗口管理器启动。
2. 设置为默认桌面环境：

   git clone https://github.com/fyshos/tyde
   cd tyde
   make
   sudo make install
   

   完成后，在登录管理器（如 LightDM）的桌面选项列表中即可选择 Tyde。

调试与测试

• 可以使用 Xephyr 工具在嵌入式 X 窗口环境中调试窗口管理器组件。
• 若在已有窗口管理器或不支持 WM 的系统（如 Windows/macOS）上运行，应用会启动为 UI 测试模式，但无法实际控制窗口。

稳定性工具 项目提供了 tyde_runner 工具来管理意外事件，增强测试版的稳定性。

go install fyshos.com/tyde/cmd/tyde_runner@develop

使用 Runner 启动桌面，如果发生崩溃，它通常能恢复到崩溃前的状态，避免应用数据丢失。

设计与分发

• 设计概念与抽象壁纸由 Jost Grant 贡献。
• 建议在发行版中打包 Tyde 时，同时提供与之风格匹配的配套应用（例如 fin 显示管理器）。
• 开发者鼓励打包者通知他们，以便在项目页面添加链接。

这篇文章列出了众多NVIDIA GPU的PCI设备ID和对应的型号名称。其核心目的是展示通过修改驱动以启用P2P（点对点）功能后，所支持的NVIDIA显卡范围。

主要内容概述：

1. 核心功能：文章标题点明了主旨，即针对NVIDIA GeForce RTX 4090显卡的驱动进行了修改（Hacked driver），目的是启用P2P功能。P2P通常用于GPU间直接通信，在深度学习、高性能计算等多卡协同任务中能提升效率。
2. 支持的硬件范围：文章主体内容是一个详尽的NVIDIA GPU列表。该列表涵盖了从较旧的GTX 16系列到最新的RTX 40系列消费级显卡，以及专业显卡（如Quadro RTX、RTX A系列）、数据中心卡（如A100、H100、L40）等。列表通过“设备ID - 子系统ID”和对应的GPU型号名称来标识。
3. 列表结构：每行以“设备ID”开头，后接可选的“子系统ID”，最后是对应的GPU型号名称。例如，“1E02”对应“NVIDIA TITAN RTX”，“2684”对应“NVIDIA GeForce RTX 4090”。
4. 涵盖的显卡系列：列表包括但不限于以下系列：
   • GeForce消费级：GTX 16系列、RTX 20系列、RTX 30系列、RTX 40系列。
   • 专业/工作站级：Quadro RTX系列、RTX A系列（A2000至A6000）、RTX Ada系列（RTX 2000 Ada至RTX 6000 Ada）。
   • 数据中心/加速计算：T4、A10、A100、A800、H100、H200、L4、L40、L20等。
   • 移动版GPU：大量带有“Laptop GPU”、“Max-Q Design”标识的型号。
   • 其他：包括CMP系列矿卡、T1000/T400/T600等小型专业卡。

总结：这篇文章本质上是一份通过修改NVIDIA驱动以启用P2P功能的兼容性支持列表，展示了该技术可能适用于极其广泛的NVIDIA GPU产品线，从消费级游戏卡到高端数据中心计算卡。文章未详细说明驱动修改的具体技术方法。

亚马逊几乎终止Alexa技能开发努力

• 开发动力与资金缺失：亚马逊已缺乏动力和资金继续扩大其曾设想的Alexa技能生态。语音助手业务已成为“烧钱”的无底洞，Alexa部门近期经历了裁员，正为生存和 relevance 而战。
• 技能生态疲软：Alexa技能长期被批评为“无用”。目前排名前列的技能主要是问答游戏和冥想类应用，并未出现能大幅提升Alexa使用率的“杀手级应用”。亚马逊寄望于生成式AI成为Alexa的新突破口，但这本身也充满挑战。
• 开发者难以盈利：第三方开发者发现很难通过Alexa技能赚钱，绝大多数开发者收入甚微，仅有极少数能获得数千美元收入。2018年，亚马逊曾斥资数百万美元激励开发者，但到2020年已大幅削减支付给开发者的款项，因为这些应用并未给亚马逊带来可观收益。
• 现状与未来：亚马逊并未正式宣布终止技能开发，开发者目前仍可通过应用内购买获得微薄收入。但公司在通知中虽感谢开发者的“关键作用”，业界普遍认为一旦亚马逊的生成式AI聊天机器人准备就绪（预计2024年6月），亚马逊对待剩余开发者的方式以及技能生态的优先级将面临考验。

Vortex是一个基于RISC-V ISA扩展的开源硬件和软件项目，旨在支持通用图形处理单元（GPGPU）。该项目目前兼容OpenCL编程模型，并可在FPGA（现场可编程门阵列）上运行。Vortex平台具有高度可定制和可扩展性，提供完整的开源软件栈，包括编译器、驱动程序和运行时，以促进GPU架构的相关研究。近期相关出版物涵盖了RISC-V向量扩展在Vulkan图形内核中的分析、在软核GPU上运行CUDA的方法，以及将稀疏操作转换为密集操作用于图形工作负载的优化。

如何准备技术会议演讲（2022）

作者认为，大多数现场技术演讲效果不佳，更喜欢在线录制的版本，因为可以调整速度。演讲者常专注于自我表达，而非听众需求。作者的核心理念是以听众为中心，打破传统建议，专注于提供实用价值。以下是关键准备策略：

1. 减少自我介绍，快速引入“钩子”

• 自我介绍容易被遗忘，且通过资历建立合法性不总是有效。作者快速进入“钩子”部分，用惊喜点吸引听众注意力，例如揭示常见误解或新见解。
• 示例：在关于技术债务的演讲中，开场就挑战“技术债务等于坏代码”的假设，引发好奇。

2. 避免强调“为什么听我讲”，而是通过故事和示例

• 不花费时间说服听众听讲的重要性，而是假设他们已经关注。通过具体故事和示例传达观点，因为人类大脑更擅长从故事中提取模式。
• 示例：讲述发射塔设计的故事来说明工程师设计决策的重要性，而非抽象定义。

3. 少用表情包、GIF、双关语或文化引用

• 这些元素可能不具普遍吸引力，且常被用作内容薄弱的掩护。作者专注于提供工具和实用框架，如流程图式结构。
• 演讲主体应基于对比现有知识的树状结构，帮助听众关联和记忆信息。

4. 不担心眼神接触，注重肢体语言和交付时机

• 在大型会场，眼神接触效果有限。作者更关注舞台表现，如肢体移动和说话时机。交付时机对概念吸收至关重要，需练习在关键时刻停顿。
• 示例：在演讲中自信掌控舞台，甚至宣布将使用全部时间，体现权威感。

5. 尽量不展示代码，专注于音频友好内容

• 代码在投影中常太小或太多，难以阅读和吸收。作者用图表、简洁表示或省略代码，专注于可引用、列表化或树状图的内容。
• 当需要教授代码时，采用博客或视频等视觉格式。演讲更侧重于新视角和灵活框架。

6. 不假设编程技能等于演讲技能

• 会议演讲是独立技能，需准备、沉着和外交能力。常见错误包括时间管理不当、抱怨设备或侮辱听众。
• 作者考虑听众、会议组织者和志愿者的体验，专注于提供清晰、难忘、无干扰的内容，以实现教学、行为影响或个人品牌目标。

总结：作者的目标是确保听众带着新技能和见解离开，而非展示自我。通过以听众为中心、使用故事、提供工具和注重交付，技术演讲可以更有效、更实用。

Ripl（发音为“ripple”）是一个JavaScript库，提供用于浏览器中2D图形渲染（Canvas和SVG）的统一API，专注于高性能和交互式数据可视化，同时包含实验性的3D渲染包。它通过统一API解决了开发者必须在Canvas（底层但复杂）和SVG（直观但有缺陷）之间做出选择的问题，允许通过更改一行代码轻松切换渲染器。该库目前处于测试阶段。

主要特性包括：

• 跨Canvas、SVG和实验性3D上下文的统一渲染API。
• 类似CSS的视觉属性级联继承和类似DOM的事件系统（冒泡、委托、传播）。
• 场景和渲染器管理，具有O(n)渲染性能和自动requestAnimationFrame循环。
• CSS类选择器查询元素。
• 所有形状元素上的边界框检测、变换支持（平移、缩放、旋转）以及路径裁剪。
• CSS渐变解析、自动插值（数字、颜色、日期等）、高性能可取消动画与关键帧支持。
• 11种缩放类型（连续、离散、时间等），18种预建图表类型。
• 丰富的内置2D形状图元（圆形、矩形、路径等）和实验性3D图元（立方体、球体等）。
• 完全模块化、树摇优化，使用TypeScript严格类型定义，无运行时依赖。

项目结构： Ripl采用Yarn 4 monorepo结构，分为多个包：

• @ripl/web：浏览器主要入口点。
• @ripl/core：核心渲染库。
• @ripl/canvas 和 @ripl/svg：分别实现Canvas和SVG渲染上下文。
• @ripl/charts：提供预建图表组件。
• @ripl/3d 和 @ripl/webgpu：实验性的3D渲染上下文。
• @ripl/terminal 和 @ripl/node：用于终端和Node.js环境的渲染上下文。
• @ripl/dom 和 @ripl/utilities：共享的实用工具。

使用示例：

• 创建元素（如圆形）并渲染到Canvas或SVG上下文，切换上下文只需更改导入源。
• 支持元素分组和属性继承。
• 使用类似DOM的方法或CSS选择器查询元素。
• 通过createScene和createRenderer管理场景和动画循环。
• 基于任务的过渡动画，支持关键帧和缓动函数。
• 每个元素支持CSS类变换（旋转、缩放等）。
• @ripl/charts提供可开箱即用的图表（如柱状图、折线图等），支持数据更新动画和内置组件（坐标轴、图例等）。
• 提供11种缩放类型用于数据映射。

性能优化：

• 场景元素被提升到平面缓冲区以优化渲染遍历。
• 渲染器在空闲时自动停止以节省CPU。
• 提供调试叠加层可视化FPS和边界框。

开发： 通过Yarn安装依赖、构建、测试和 lint。项目采用MIT许可证。