专为局域网聚会打造的房屋

整体概念

这栋位于德克萨斯州奥斯汀的房屋由Kenton Varda与妻子Jade Wang从零开始设计并建造，核心目标是优化局域网聚会体验。房屋于2023年完工，融合了游戏空间、家庭生活区与先进技术设施。

核心游戏区域

• 地下室游戏室：内嵌12台电脑于墙壁，配备可折叠游戏站。地板集成了跳舞机垫。
• 楼上办公室：可通过会议桌转换为6个游戏站，并有2个升降桌作为个人工作站。
• 机械室：容纳20台完全相同的游戏主机，通过网络从共享磁盘映像启动，并配有专用空调系统。

技术细节

• 硬件配置（2023年）：游戏机使用Intel Core i5-13600 CPU、32GB RAM、GeForce RTX 4070显卡及带有板载10G网卡的主板（文中指出该主板不稳定，不建议购买）。
• 网络：全屋铺设六类网线，包括35个墙盒、7个PoE无线接入点、8个PoE安全摄像头和3个PoE对讲机，全部使用UniFi设备。拥有2Gbps光纤互联网。
• 系统管理：所有游戏机通过网络启动，基于单一磁盘映像，采用写时复制叠加层技术实现个性化与重置。
• 线缆管理：视频和USB线缆通过管道连接，采用长距离光纤线缆以减少延迟。

房屋其他特色

• 生活空间：包含客厅、猫走道、儿童房（带阁楼床和猫门）、电话会议室、客房和屋顶平台。
• 宠物设施：专为猫设计了猫门、猫砂盆空间和攀爬架。
• 能源与舒适：配备了高效热泵和太阳能电池板。游戏室主机侧有专门的“冷侧”进气口和“热侧”排气口。

设计理念与常见问题解答

• 为何采用内置电脑而非自带：减少了设置麻烦，使聚会更易组织和频繁举行。
• 座位布局（背对背）：节省空间，便于将游戏室转换为其他活动区域（如跳舞、VR游戏），且便于旋转椅子交流。
• 常用游戏：偏好合作或团队游戏，如《Deep Rock Galactic》、《求生之路2》和《虚幻竞技场2004》。
• 隐私与访问：聚会不对外公开，仅限受邀者。
• 资金来源：主要源于Kenton在谷歌早期股票收益、帕洛阿尔托原有房产增值、在Cloudflare上市前加入以及Jade的早期投资。
• 声学考虑：游戏时不使用耳机，以保持社交互动性，团队对抗时会分隔到不同房间。

技术问答摘要

• 键鼠选择：使用最便宜的型号，因认为高端外设并无显著优势，且欢迎访客自带。
• 配线板错误：房主反思了未使用配线板进行网络布线的做法。
• 线缆延迟：长距离光纤线缆引入的延迟可忽略不计。
• 虚拟化方案否决：认为为多个用户构建单台高性能主机成本更高、性能更差且更复杂。
• 家庭自动化：尽量避免依赖云，使用UniFi Protect摄像头系统和自制的婴儿监控器。
• 电力消耗：主要能耗来自供暖制冷而非偶尔运行的电脑。

《半条命2》20周年更新摘要

核心更新内容

• 扩展内容整合：《半条命2：第一章》和《第二章》已直接内置到游戏中，可通过主菜单访问并连续游玩。
• Steam创意工坊支持：游戏内新增创意工坊入口，玩家可直接浏览、安装和游玩社区创作的内容（如战役、武器替换等）。
• Steam游戏录制功能：集成Steam的游戏录制系统，自动标记游戏中的关键时刻，方便玩家记录与回放。

游戏内容全面更新

• 地图与Bug修复：由Valve关卡设计师逐一检查并修复了所有地图的长期Bug，包括物体消失、穿模、光照不一致等问题。
• 视觉效果提升：
  • 重新平衡了全局光照，支持HDR开关下的视觉效果。
  • 新增径向雾，使地平线过渡更平滑。
  • 全面提高光照贴图分辨率。
  • 修复了G-Man开场模型的眼睛反光效果，并移除了错误的绿光。
• 新增图形设置选项：
  • 可在主游戏中选择经典版或扩展版的血液与火焰特效。
  • “高画质”模式下强制使用最高细节模型。
  • “极高着色器细节”下启用双三次光照贴图过滤，实现更平滑的阴影。
• 操作与硬件适配更新：
  • 手柄控制方案已更新，与《半条命1》周年版保持一致。
  • 瞄准辅助系统重制，提供更多自定义选项（可针对手柄或键鼠分别设置，强度可调）。
  • Steam Deck主菜单已适配新功能，并在PC的“大屏幕模式”下同样生效。

开发历史资料公开

• 早期演示视频：首次以高清晰度公开了三段重要历史演示：
  • E3 2003：首次向世界公布《半条命2》及Source引擎的演示。
  • E3 2002：原计划参展E3但最终未展示的早期版本。
  • SIGGRAPH 2000：在初代《半条命》发布后不久展示的技术演示，被称为“免费电视”演示。
• 《Raising the Bar》新版本：这本记录《半条命2》开发历程的书将于2025年推出扩展版，加入《第一章》《第二章》及从未公布的《第三章》概念艺术与设计资料。

主要Bug修复与改动列举

• 新增内容：增加了3.5小时的开发者评论；将《半条命2：迷失海岸》加入“额外”菜单。
• 技术性修复：
  • 修复了大量光照、阴影、模型显示及地图过渡问题。
  • 解决了特定场景下的崩溃问题（如运河中直升机追击部分）。
  • 修复了众多NPC行为、动画及音效Bug。
  • 优化了UI字体渲染与缩放支持，并替换系统字体为新字体GorDIN。
• 多人游戏与工具更新：
  • 修复了《半条命2：死亡竞赛》的地图与道具问题。
  • 更新了Hammer编辑器，提高了多项数据限制，并修复了错误。
• 版本存档与独立版本调整：旧版本游戏已存档至公开的Beta分支“steam_legacy”。内置扩展包后，独立版本的《第一章》《第二章》在Steam商店的可见度将降低，但仍保留在库的“工具”分类中。

免费附加内容

• 原声带：《半条命2》及《第一章》《第二章》的原声带已可免费串流或下载。
• 主题壁纸：提供适用于桌面和手机的20周年纪念壁纸。

Bluesky 社交网络现状分析

当前并非去中心化或联邦化

Bluesky 常被宣传为去中心化或联邦化平台，但作者认为它目前两者都不是。其底层 AT 协议 (atproto) 架构包含三个主要部分：

1. 个人数据服务器 (PDS)：用户可自行托管，存储身份密钥和内容，类似于自建网站。目前仅 Bluesky 服务器能有效读取并利用这些数据。
2. 中继器 (Relay)：聚合来自 PDS 的数据，并将其提供给协议生态系统。自建中继器成本高昂（需约 4.5 TB 存储空间，数据每日增长数十 GB）。
3. 应用视图 (App View)：将中继器抓取的数据转化为用户可交互的内容（如 Bluesky 社交网络界面）。目前仅为 Bluesky 官方实现。

此外，DID:PLC（分布式标识符） 和 私信 (DMs) 两项关键功能也由 Bluesky 公司直接控制，并未纳入协议规范。作者认为 Bluesky 团队正努力推动去中心化，但进展有限，实现真正的去中心化仍需数年努力且成本极高。

开放性与财务疑虑

• 极度开放：网络数据（除私信外）完全开放，易于导出，任何人可抓取全量数据流。
• 财务可持续性存疑：平台目前免费，仅通过域名转售盈利。CEO 曾获得加密货币投资者融资，而当前技术架构导致运营成本高昂，盈利模式不明确。

产品功能不足

作者指出两项主要功能缺陷：

1. 转发控制：无法单独屏蔽某个用户的转发内容。
2. 编辑帖子：因 Merkle 树数据结构限制，目前无法实现帖子编辑。

值得肯定的优点

1. 域名用户名：支持使用个人域名作为用户名，便于自我认证。
2. 可组合的审核与算法：提供审核和算法自定义功能，用户可选择时间线或自定义信息流。
3. 入门包 (Starter Packs)：方便新用户快速关注一整套推荐账户。

不同平台的体验差异

不同用户群体在不同平台上的体验和互动度差异很大，例如 Bluesky 在艺术家和特定社群中较受欢迎。作者认为没有统一标准，用户应根据自身情况选择平台。

结论

尽管 Bluesky 可能在用户迁移潮中暂时“获胜”，但作者保持理性态度，主张将内容发布在自己的网站，并聚合到感兴趣的社交平台，同时对任何平台保持警惕，随时准备离开。

根据iSeeCars对2017-2022年美国致命事故分析报告系统（FARS）数据的研究，在2018-2022车型年的所有汽车品牌中，特斯拉车辆的致命事故率最高。数据显示，特斯拉每十亿英里行驶里程的致命事故率为5.6起，高于起亚（5.5）和别克（4.8）。而美国所有汽车的平均致命事故率为每十亿英里2.8起。

具体车型方面，特斯拉Model S的致命事故率是平均水平的两倍多，达每十亿英里5.8起；全球畅销车型Model Y的致命事故率则高达10.6，几乎是平均值的四倍，在总体车辆排名中位列第六。整体事故率最高的车型是现代Venue，达13.9。

研究作者明确指出，这些结果并不表明特斯拉车辆本身不安全或存在设计缺陷。事实上，特斯拉车辆搭载了大量安全技术，例如2024款Model Y就获得了美国公路安全保险协会（IIHS）的“顶级安全之选+”奖项。榜单上许多其他车型也获得了IIHS和美国国家公路交通安全管理局的高安全评级。

那么，为何特斯拉及其他看似安全的车型会涉及这么多致命事故？iSeeCars的执行分析师卡尔·布劳尔在报告中解释：“榜单上的车型可能反映了驾驶行为和驾驶条件的综合影响，导致事故和致命事件增加。一位专注、警觉的驾驶员，以合法或谨慎的速度行驶，且未受毒品或酒精影响，无论驾驶何种车辆，都最可能安全抵达目的地。”

Netflix直播体育赛事遭遇严重技术故障，引发观众不满

在Netflix直播Jake Paul与Mike Tyson拳击赛期间，大量观众遭遇了缓冲问题、画面卡顿和“黑屏死机”等流媒体故障。问题从比赛开始前就持续存在，并在整个晚间不断加剧，导致观众在社交媒体上表达强烈不满。

尽管技术问题频发，Netflix仍报告了较高的收视数据：6000万家庭观看了Paul与Tyson的主赛事，5000万家庭观看了副赛中Katie Taylor与Amanda Serrano的对决，后者被Netflix称为“美国历史上收视最高的职业女子体育赛事”。

观众反馈显示，故障包括加载屏幕漫长、画面冻结和音频丢失等问题。随着观看人数增加，服务器压力可能进一步加剧了这些问题。部分观众因直播中断而转向其他平台，如前NFL球员Antonio Brown在X（原Twitter）上从比赛现场进行的直播，吸引了高达640万观众。

此次事件引发了对未来体育直播质量的担忧，尤其是Netflix计划在圣诞节期间直播两场NFL比赛。观众已对平台能否稳定支撑大型体育赛事直播表示质疑。

Yggdrasil Network 摘要

Yggdrasil 是一个新的实验性紧凑路由方案，旨在成为当前互联网常用结构化路由协议的未来导向、去中心化替代方案，并为未来大规模网状网络提供使能技术。其核心特性包括：

• 可扩展：支持大型、复杂或互联网规模的网络拓扑。
• 自愈：网络能快速响应连接故障或移动事件。
• 加密：所有网络流量均实现端到端完全加密。
• 点对点：设计为完全点对点，无内置集中化节点。
• 跨平台：支持 Linux、macOS、Windows、iOS、Android 等多种操作系统。

当前实现是一个轻量级用户空间软件路由器，易于配置，适用于广泛平台。它提供网络中所有参与者之间的端到端加密 IPv6 路由。节点间的对等连接可通过 TCP/TLS 连接配置，支持局域网、点对点链路或互联网。尽管路由基于 IPv6，但对等连接可在 IPv4 或 IPv6 网络上建立。

该项目仍处于 alpha 阶段，未来可能有破坏性更改，但整体已足够稳定，可用于日常使用，并有少量用户进行重度使用和压力测试。若要参与，用户可在自己的计算机或路由器上安装并配置 Yggdrasil 以加入网络。

Llama-OCR：文档转Markdown

这是一个由 llama-ocr 与 Together AI 驱动的工具，旨在将文档图像（未来将支持PDF）转换为结构化的Markdown格式。

主要功能与用法：

1. 图像转Markdown：核心功能是上传图像，将其转换为Markdown。
2. 使用方式：
   • 网页界面：支持直接上传图片或拖放操作。
   • 代码调用：提供了Node.js代码示例，通过导入llama-ocr库并调用ocr函数实现，需要提供文件路径和TOGETHER_API_KEY环境变量。
3. 输出：处理结果为Markdown格式。
4. 未来计划：即将支持PDF文档的处理。

本文批评了YC对大型语言模型（LLM）在芯片设计领域应用的观点，指出其提案存在根本性误解。作者认为，YC高估了LLM的能力，并忽略了芯片设计的实际挑战。

核心反驳点：

1. LLM无法实现突破性创新：YC认为LLM能设计出性能提升100倍的芯片，但文章指出，现代加速器芯片的性能提升主要依赖新颖的架构设计，而非简单的代码编写。LLM目前只能生成质量平庸的Verilog代码，无法进行创造性的架构设计。

2. 历史前车之鉴：高级综合（HLS）的失败：YC认为LLM能降低芯片设计成本。文章指出，业界早在1998年就尝试过类似理念的工具——高级综合（HLS），其目标是将高层次语言（如C++）自动转换为硬件描述语言（如Verilog），以降低门槛和成本。然而，HLS在实际应用中效果不佳：它无法产生与手动优化RTL（寄存器传输级）设计相媲美的性能与效率，因此在高性能、高价值的芯片（如AI加速器）市场中未能普及，仅在小众、低产量的领域（如基因组学、计算流体动力学）的FPGA加速中取得有限成功。

3. LLM可能重蹈覆辙：文章认为，用LLM生成低质量Verilog代码来降低设计成本，本质上与HLS面临同样的困境。如果某个应用尚未因性能需求而采用专用硬件加速，通常意味着其市场规模有限，对于初创公司而言并非理想的商业目标。因此，试图用LLM为这些低价值市场开发硬件加速器，是一条“失败者之路”。

LLM在芯片设计领域的真正价值：

文章承认LLM在芯片产业中确实有用武之地，但并非作为主要设计者，而是作为辅助工具：

• 节省工程师时间：帮助工程师编写小段简单代码。
• 解决人才短缺：当前行业严重缺乏验证工程师（理想比例是每名设计工程师配两名验证工程师）。LLM若能在芯片验证领域发挥作用，将极具价值。但这要求LLM能真正理解复杂且不完整的芯片规格书，并建立芯片预期内部状态的模型，技术难度很高，目前相关初创公司的做法尚显天真。

结论：

LLM将使芯片设计更便宜，但这主要惠及三类公司：大型半导体公司（可减少验证人力）、传统芯片初创公司（可精简团队）以及销售LLM工具的EDA软件公司。LLM不会打造出性能100倍的芯片，也无法通过硬件加速来激活那些本就不存在的市场，因为经济逻辑不成立。YC的提案忽略了芯片设计的核心挑战和历史教训。

卡西欧发布标志性手表形态的戒指

卡西欧宣布推出数字戒指手表CRW-001-1JR，以庆祝其进入数字手表业务50周年。该产品旨在与上月天美时推出的可穿戴戒指手表竞争，并提供更多功能。

产品功能与设计

• 显示与操作：戒指表壳尺寸不足一英寸，但配备了复古六段LCD屏幕，可显示时、分、秒。通过三个功能按钮，用户可控制日期显示、不同时间区的时间及秒表功能。
• 实用特性：屏幕具备背光功能，闹钟通过闪烁提示而非声音。手表防水，由单节电池供电，续航约两年，且电池易于更换。
• 制造工艺：为精准还原经典数字手表的设计细节，戒指采用金属注射成型工艺，以金属粉末制造为单体结构。
• 尺寸与适配：戒指为固定美国10.5码尺寸。若用户手指较小，卡西欧提供垫圈改善佩戴；若手指较大，则无法适配。

上市信息

• 价格：在日本上市售价为19,800日元（约合128美元）。
• 上市时间：计划于12月在日本开售。

背景

去年，卡西欧曾推出一系列灵感源自其经典数字手表的戒指手表，但均无实际功能。此次CRW-001-1JR是首款具备完整功能的戒指手表。文章最后展望，未来可能推出更复杂功能（如计算器）的戒指手表产品。

这是一个免费的抵押贷款分析工具，旨在帮助借款人避免在交易结算成本和利率上吃亏。

主要功能：

• 智能文档分析：用户可上传抵押贷款文件，工具将即时分析以揭示隐藏费用。
• 多方贷方比较：一站式接入20多家贷方的利率信息，便于比较和选择。
• 实时利率查看：提供其贷方网络中的实时抵押贷款利率（但利率会变动，取决于借款人批准、信用状况和贷方条款）。

工具成效声明： 该工具声称已帮助发现超过1000万美元的潜在节省金额（在抵押贷款结算成本和不良利率方面），平均每笔贷款可为购房者节省约8000美元。

低成本消费Bluesky firehose指南

本文介绍了如何以低于每月2.50美元的成本消费Bluesky的firehose实时数据流，Bluesky是一个拥有1500万用户且快速增长的社交网络平台，所有数据均为公开状态。

获取Bluesky firehose的方式

• 使用Jetstream作为websocket JSON feed连接firehose，可以实时接收网络上所有活动。
• 操作简单易上手，例如可以从浏览器中免费获取每个帖子的一个随机词。

低成本应用示例

作者开发了一个小应用，运行在Fly平台上，每月成本低于2.50美元：

• Fly机器配置：共享CPU-1x，256MB RAM，每月1.94美元。
• 存储：2GB持久卷，每月0.30美元。
• 该应用监听网络上的删除事件，并匿名显示被删除的文本，但由于用户数量增加，可能已过时。

应用功能细节

应用主要执行以下操作：

1. 接收来自app.bsky.feed.post集合的所有新创建帖子事件。
2. 过滤空帖子，并对提及和链接进行编辑（redactions）。
3. 将清洁的文本内容缓存在pebbledb存储卷中，键为did+rkey。
4. 每几秒钟执行一次范围删除，清除超过48小时的旧文本。
5. 对于每个删除帖子事件，尝试从缓存中获取文本，如果找到，则广播给所有当前观察者。

结论

尽管更复杂的应用可能无法以如此低的成本运行，但本文表明消费Bluesky firehose可以非常经济实惠，适合初学者或小型项目。

一项在英国开展的大规模随机对照试验表明，以“KiVa”为核心的低成本、结构化反欺凌计划能有效改善小学社交环境，减少欺凌事件发生。

主要发现：

• 在英格兰和威尔士118所小学进行的为期一学年的试验中，参与KiVa计划的学校学生报告遭受欺凌的可能性比采用常规做法的学校低13%。
• 该计划在经济社会背景各异的学校以及不同规模的学校中均显示出有效性。
• 经济分析显示，KiVa是一项低成本的干预措施，这对于预算有限的学校尤为重要。

KiVa计划的核心与实施：

• 核心理念：该计划起源于芬兰，其核心是将欺凌视为“所有人的问题”，特别强调旁观者在改变社会动态中的关键作用，旨在减少欺凌行为的社会奖励。
• 实施措施：学校为学生开设双周课程，教导他们识别和应对欺凌；举行全校集会、张贴海报、向家长提供信息；教师在课间休息时穿着醒目背心；发生欺凌事件时，工作人员遵循KiVa指南，与涉事学生进行讨论，并要求欺凌者承诺采取具体行动支持受害者，而非简单的指责和惩罚。
• 效果影响：实施KiVa的学校报告称，学生对受害者更有同理心，同伴间的问题也有所减少。

研究背景与意义：

• 这是英国迄今为止关于KiVa计划的最大规模试验，由班戈大学领导，多所大学和机构参与，涉及超过11,000名学生。
• 研究者指出，欺凌是儿童期及之后出现心理健康问题的最大风险因素之一。
• 尽管英国的试验结果（13%的减少）低于芬兰等国早期研究的数据，但研究人员认为这可能受到了COVID-19疫情期间课堂中断和缺勤率较高的影响。
• 许多参与试验的学校正在继续使用KiVa计划，因为该计划旨在嵌入学校的日常运作中。
• 研究成果强调了基于证据评估学校反欺凌项目的重要性。

苹果M4 MacBook Pro采用量子点薄膜替代红色KSF磷光膜

主要技术变更

• 苹果最新发布的MacBook Pro（M4型号）首次采用量子点（Quantum Dot, QD）薄膜技术，取代了此前使用的红色KSF磷光膜。
• 这是苹果在显示技术上的重大更新，标志着其首次在产品中集成量子点技术。

技术背景与对比

• 过去，苹果选择KSF磷光膜解决方案，主要基于两个优势：
  1. 更高的能效：KSF方案在显示效率方面表现更优。
  2. 环保特性：KSF薄膜不含镉（Cadmium, Cd），减少了有害物质的使用，符合环保标准。
• 现在，苹果转向量子点薄膜，表明该技术在性能、色彩表现或其他方面可能提供了改进，以满足最新MacBook Pro的显示需求。

关键点总结

• 首次应用：这是苹果在设备中首次采用量子点技术，可能用于提升屏幕的色域、亮度或能效。
• 技术迭代：从KSF磷光膜到量子点薄膜的转变，反映了显示技术的演进，量子点通常能提供更广的色彩范围和更高的色彩准确性。
• 潜在影响：这一变更可能旨在增强MacBook Pro的显示质量，同时平衡效率与环保因素，尽管量子点薄膜的具体优势（如是否含镉或性能提升）未在内容中详细说明。

内容来源

• 该信息来自社交媒体平台X（原Twitter）上用户Ross Young (@DSCCRoss)的发布，内容聚焦于苹果显示技术的新闻。

Django扩展实用指南

本文档总结了在生产环境中扩展Django应用程序的实践方法，其核心思想是：真正的扩展并非应对假设的海量用户，而在于随着业务增长系统性地消除瓶颈。

一、 识别瓶颈（按常见顺序）

性能瓶颈通常按以下顺序出现：

1. 数据库查询
2. 模板渲染
3. Python处理
4. 缓存未命中
5. 文件I/O
6. 网络延迟

原则：只在瓶颈真正成为问题时才进行优化。

二、 核心优化技术

1. 数据库优化

• 查询优化：避免N+1查询，使用select_related和prefetch_related一次性获取关联数据。
• 数据库索引：为常用查询条件（如组合字段）添加索引。
• 查询集优化：
  • 使用values()只加载必要字段。
  • 处理大型查询集时使用iterator()避免内存溢出。

2. 缓存策略

• 视图级缓存：使用@cache_page装饰器缓存整个视图响应。
• 模板片段缓存：使用{% cache %}模板标签缓存复杂或耗时的模板部分。
• 低级缓存API：使用django.core.cache进行更精细的数据缓存。

3. 异步处理

• 异步视图：使用async def视图配合aiohttp等库处理需要并发网络请求的场景，提升I/O密集型任务效率。

4. 后台任务

• 使用Celery等任务队列（如通过@shared_task）将耗时操作（如发送邮件）移至后台，避免阻塞请求-响应周期。

5. 负载均衡与数据库扩展

• 读写分离：配置数据库读副本，将读请求导向副本库。
• 静态文件分离：将静态文件和媒体文件存储在云存储（如Amazon S3）和CDN上，减轻应用服务器压力。

三、 现实世界的扩展检查点

• 100 请求/秒：
  • 实施基本缓存。
  • 添加数据库索引。
  • 将静态文件移至CDN。
• 1,000 请求/秒：
  • 添加数据库读副本。
  • 实施模板片段缓存。
  • 使用托管的Redis/Memcached作为缓存后端。
• 10,000 请求/秒：
  • 考虑数据库分片。
  • 实施服务级缓存。
  • 将重操作拆分为微服务。

四、 扩展检查清单

在增加复杂性之前，确认已完成以下基础优化：

• 优化数据库查询（使用select_related, prefetch_related）。
• 添加了合适的数据库索引。
• 实施了视图和模板缓存。
• 将静态/媒体文件迁移至CDN。
• 设置了监控和告警。
• 配置了连接池。
• 为耗时操作实施了后台任务。
• 为高读负载添加了读副本。
• 建立了日志记录和错误跟踪。

结论

Django在优化得当的情况下，能处理比大多数人想象中更大的负载。最佳的扩展策略并非一味增加资源，而是消除现有资源中的浪费。应从简单开始，度量一切，并仅针对确实需要扩展的部分进行扩展。

美国联邦贸易委员会（FTC）将对微软的云业务展开调查。调查重点包括微软向用户收取数据迁移费用，以及提供最低消费合同（该合同以折扣形式换取客户承诺特定消费水平）。这些做法可能阻碍客户选择其他云服务提供商。

类似监管审查也出现在国际层面。英国竞争与市场管理局正在调查微软和亚马逊，此前英国通信管理局发现客户抱怨被“锁定”在单一提供商，这些提供商通过排他性提供折扣，并对客户离开收取高额“数据传输费”。在欧盟，微软于7月与一组竞争对手云提供商达成数百万美元的协议，从而避免了对其云业务的正式调查。

FTC在2022年曾试图阻止微软以750亿美元收购游戏开发商动视暴雪，担心该交易会损害其Xbox游戏机和云游戏业务的竞争对手。法院驳回了FTC的阻止尝试，该决定正在上诉中。经过修订的交易版本在去年获得了英国竞争与市场管理局的批准后完成。

云基础设施和服务已成为科技巨头最赚钱的业务之一，企业正将其数据存储和计算外包到线上。近年来，人工智能模型训练和运行对处理能力的需求进一步推动了这一市场的发展。2023年云服务支出飙升至5610亿美元，市场研究机构Gartner预测今年将增长至6750亿美元，2025年将达到8250亿美元。

在全球云市场中，微软的市场份额约为20%，落后于市场领导者亚马逊网络服务（31%），但几乎是谷歌云（12%）的两倍。这三家巨头及更小的提供商之间竞争激烈。上个月，微软指控谷歌进行“影子活动”，通过秘密资助敌对游说团体来破坏其在监管机构中的地位。微软还声称，谷歌试图通过向欧盟云提供商提供5亿美元现金和信贷来破坏其和解协议，要求它们拒绝协议并继续诉讼。

FTC和微软均拒绝对此置评。

# 内容摘要

提供的内容是一个安全检查点标识符，具体为“Vercel Security Checkpoint | sfo1::1780024823-H4Um2Ryrpv2xw7CroozUF064aKTkkdhS”。这看起来像是Vercel（一个云平台）的安全验证字符串。

- **目的**：可能用于安全访问控制或会话验证，确保对Vercel服务的安全交互。
- **结构**：由文本“Vercel Security Checkpoint”和一个编码的标识符（sfo1::1780024823-H4Um2Ryrpv2xw7CroozUF064aKTkkdhS）组成，标识符可能包含时间戳、会话ID或其他安全参数。
- **关键功能**：作为安全检查点的一部分，用于识别和验证用户或请求，防止未授权访问。

开源车库门开启器OpenGarage的安装与体验

背景与动机

作者拥有一个由Genie/Aladdin系统控制的车库门，但其官方应用不兼容首选的智能家居系统Home Assistant。尽管Genie曾承诺发布官方集成，但因许可问题撤回，导致自动化功能受限，如无法在开门时触发灯光或发送警报。在参考同事的ratgdo方案后，作者选择了更适配的OpenGarage设备（50美元加运费），因为它完全开源，且能绕过公司API限制。

OpenGarage设备介绍

OpenGarage是一个基于ESP8266的开源硬件项目，集成了超声波距离传感器和电路继电器。其设计、固件、应用代码和API均公开，支持通过网页浏览器、移动应用、IFTTT、MQTT和电子邮件进行控制与监控。设备小巧，安装简便，适用于大多数车库门系统，但Security+ 2.0型号可能需要适配器。

安装过程

安装OpenGarage通常需将其固定在车库屋顶，使超声波传感器能检测门的开合状态。关键步骤包括：

• 定位：选择合适位置，确保传感器视野覆盖门和车辆（可选），避开障碍物，并靠近电源和接线。
• 接线：将设备的接触线连接到车库开启器的螺丝端子，与原有墙壁按钮线路并联。作者使用Genie开启器，通过暴露电线并连接OpenGarage的螺丝端子完成。
• 固定：使用螺丝和胶带固定设备与电线，确保整洁。安装虽非专业，但功能正常。

功能与优势

安装后，OpenGarage提供了一个网页界面，显示车库门状态、车辆存在（如果配置）以及连接状态。其核心优势包括：

• 开源自由：无需依赖企业API，避免官方集成中断。
• 多平台集成：支持Blynk、OpenThings.io云服务，以及IFTTT和MQTT，便于扩展自动化。
• 警报系统：可设置门开启超时或特定时间后的电子邮件提醒。
• 本地控制：通过网页界面或设备密钥安全操作，无需外部依赖。

与Home Assistant集成

作者将OpenGarage成功集成到Home Assistant中，实现了以下自动化：

• 在开门时自动开启车库顶灯五分钟。
• 在仪表板添加长按按钮控制开门。
• 计划更复杂的自动化，如垃圾日提醒（例如周一晚上10点未开门则通知）或NFC标签控制（考虑安全性）。

开源项目与开发者

OpenGarage由Ray Wang和Samer Albahra共同开发，基于OpenSprinkler项目的开源精神，采用ESP8266平台和3D打印技术。其开源性质鼓励DIY爱好者参与和定制，提升了设备的透明度和灵活性。

作者总结

作者对OpenGarage的体验非常满意，认为它恢复了家庭自动化的自主权，并激发了更多创意想法。设备安装简单、功能强大，且开源社区支持使其成为替代商业解决方案的理想选择。

Scooter 是一个交互式的终端查找替换工具应用。

核心功能

• 交互式操作：支持固定字符串或正则表达式搜索，用户可交互式地选择要替换的具体实例。
• 安全替换：若自搜索后目标文本已变更（如切换了代码分支），则该处替换不会执行，最终会汇总显示所有此类情况。
• 灵活输入：默认递归搜索当前目录，也可处理来自标准输入（stdin）的文本流。
• 搜索模式：默认逐行搜索，可通过 -U 标志或运行时按 Alt+M 启用多行搜索模式。
• 转义序列：替换文本中的 \n 等默认为字面值，使用 -e 选项可使其被解释为真正的换行符等。
• 语法高亮：支持自定义语法高亮主题。
• 遵循规则：搜索时默认遵循 .gitignore 和 .ignore 文件。
• 捕获组：支持在正则搜索中使用捕获组，并在替换文本中引用（如 ($2) "$1"）。
• 编辑器集成：在结果列表中按 e 可用配置的编辑器（如 vi）在对应文件和行号打开。
• 高级正则：默认使用性能优化的正则引擎子集，需使用 -a 标志启用完整功能（如否定前瞻）。
• 文件过滤：默认忽略隐藏文件（--hidden 标志可包含），可通过“包含文件”和“排除文件”的 glob 模式精确控制搜索范围。

使用方式

1. 文件模式：在终端运行 scooter 即可启动，可指定搜索目录。
2. 管道模式：支持管道输入，如 echo "hello" | scooter。结果默认输出到 stderr；使用 --no-tui (-N) 模式则输出到 stdout。
3. 搜索字段：启动后提供搜索文本、替换文本、是否固定字符串、全词匹配、大小写匹配、包含/排除文件模式等多个配置字段。
4. 命令行预填充：可通过 --search-text, --replace-text 等标志预填充搜索字段，并可使用 --immediate-search 跳过界面直接搜索。

性能

在 Linux 内核代码上进行“before”替换为“after”的基准测试中，Scooter 表现出色，速度快于许多常见工具组合（如 ripgrep + sd）。其高性能部分得益于使用了 ripgrep 的文件遍历组件。

安装

提供多种安装途径：

• 包管理器：Homebrew (macOS/Linux), Nix, AUR (Arch Linux), Winget (Windows), Scoop (Windows), NetBSD 官方源。
• 预编译二进制：在 GitHub Releases 页面提供适用于 Linux (x86_64/ARM64)、macOS (Apple Silicon/Intel)、Windows (x64) 的二进制文件。
• Cargo：cargo install scooter。
• 源码构建：克隆仓库后使用 cargo install --path scooter --locked。

配置

配置文件默认位于 ~/.config/scooter/config.toml (Linux/macOS) 或 %AppData%\scooter\config.toml (Windows)。主要配置项包括：

• [editor_open]：设置打开结果文件的编辑器命令及是否退出 scooter。
• [preview]：配置预览窗口的语法高亮（主题、换行）。
• [style]：设置是否使用真彩色。
• [search]：设置是否禁用预填充字段、是否解释转义序列等搜索行为。
• [keys]：自定义所有界面下的键绑定，支持定义不同修饰键（C- Ctrl, A- Alt, S- Shift）和键名。

编辑器集成

详细介绍了如何将 Scooter 集成到 Helix 和 Neovim 编辑器中，实现从编辑器内直接启动、搜索选中文本、以及在 Scooter 中打开文件时自动跳回编辑器对应位置。

查询优化器是分析型数据库系统中至关重要的组件，尽管它通常不如性能、易用性或可靠性那样引人注目。优化器通过重写和优化查询计划，能带来显著的性能提升，甚至超越手动优化的查询，并能适应数据状态的变化。

优化器工作在SQL查询被解析和验证之后、执行之前。解析器生成的原始查询计划可能非常低效，优化器则由一系列优化规则组成，通过逻辑等价的操作重排、插入或删除来创建更高效的计划。

文章通过使用纽约出租车数据集的实验直观展示了优化器的强大效果。一个简单的查询在禁用优化器时，因产生笛卡尔积而导致需要处理数万亿行中间数据，运行时间超过24小时。启用优化器后，运行时间缩短至0.769秒。这主要归功于三个关键规则：

1. 过滤器下推：将过滤条件（如 Borough = 'Manhattan'）尽可能下推到表扫描阶段，提前减少数据量。
2. 连接顺序优化：识别等值连接条件，重排扫描和连接操作以消除低效的笛卡尔积。
3. TopN优化：当查询包含 ORDER BY 和 LIMIT 时，用TopN操作符替代，仅维护前N个值，避免全量排序，降低时间复杂度。

手动编写优化SQL（例如显式指定连接顺序和提前过滤）虽然可以得到相近的执行计划（运行时间约0.926秒），但存在缺点：代码冗长、易出错，且优化仅针对当前数据状态。随着数据变化（例如订单表增长），手动优化的假设可能失效，导致性能下降。而启用优化器后，系统能根据数据统计信息自适应调整计划，保持高性能（例如当订单表达1亿行时，运行时间仅为未优化情况的约1/10）。

此外，有些优化规则是手动无法实现的，例如连接过滤器下推。该规则在哈希连接中，利用构建侧键值的最小和最大值，将过滤器下推到探测侧的表扫描，从而大幅减少扫描数据量。

文章总结了DuckDB采用的一系列优化规则：

• 表达式重写：简化查询中的表达式（如常量折叠、算术简化），利用引擎特性提升计算效率。
• 过滤器上拉与下推：下推过滤器以减少数据扫描量；上拉过滤器并在等值条件下将其传播到多个表，进一步过滤数据。
• IN子句重写：将小列表的 IN 转换为 =，将大列表的 IN 转换为高效的哈希连接（MARK连接）。
• 连接顺序优化：重新排列连接顺序以最小化中间结果集的大小。
• 统计信息传播：利用列统计信息（如最小/最大值）和连接条件，动态生成新的过滤器。
• 过滤器重排：按执行效率对多个过滤条件进行排序，先执行快速过滤。

总而言之，一个完善的查询优化器能自动应用多种优化规则，显著提升查询性能（可能达100倍以上），并能灵活适应数据变化。虽然手动优化在极少数特定场景下可能有效，但难以维护且不具备通用性。因此，在选择分析系统时，应充分考虑其优化器的能力。

Tsugaru OS 项目概述

Tsugaru OS 是一个旨在创建无版权问题的 FM Towns 操作系统的项目。其目标是让用户能够运行免费游戏、复刻版游戏或新开发的 FM Towns 应用程序，而无需担心侵犯原版 Towns OS 的版权。

当前进展

目前，Tsugaru OS 已经能够运行三款知名的免费游戏：《Panic Ball 2》、《VSGP》和《Sky Duel》。虽然音效存在细微差异，但游戏已基本可玩。此外，项目还成功测试了《Planet Attacker》、《Tactical Air Wing》和《Ground Attack》等游戏。

使用方式

用户可以通过多种方式启动 Tsugaru OS：

1. 软盘镜像：使用 release/FDIMG.bin 或 release/FDIMG_USEROM.bin（后者使用ROM中的系统文件）。
2. 硬盘镜像：将 release/HDIMG.h0 挂载到 SCSI ID 0 即可启动。该系统不依赖CMOS设置，会自动为找到的第一个SCSI分区分配驱动器号。
3. 光盘启动：将 CDISO.ISO 刻录到 CD-R，可在连接了SCSI光驱的真实 FM Towns 实机上启动。

构建说明

构建 Tsugaru OS 需要准备以下环境和工具：

• Windows 环境：Python（运行构建脚本）、Netwide Assembler (NASM)、Visual C++（2019版）、以及 Tsugaru 模拟器运行环境。
• FM Towns 环境：High-C Multimedia Kit、FM Towns 386ASM 汇编工具包，以及“フリコレ9”中包含的 MAKE.EXE 工具。 构建时需将相关工具复制到指定目录，并在 tgbios 子目录下运行 makedisk.py 脚本，最终生成 HDIMG.h0、FDIMG.bin 和 FDIMG_USEROM.bin 三个二进制文件。

主要功能与组件

1. TOWNS_CD 驱动：支持将内部CD驱动器重定向到外部SCSI CD驱动器，并可通过命令控制重定向的启用、暂停、恢复及指定目标SCSI ID。
2. FAKENSDD.SYS 驱动：模拟了原版 Towns OS 的 NSDD（Native System Device Driver）机制和 COCO 内存管理，以兼容依赖 FORRBIOS 的程序（如 F-BASIC 386 和 High-C 编译的程序）。
3. RAMDRIVE.SYS：提供内存盘功能，可在 CONFIG.SYS 中配置盘符和大小。
4. REPLACE.SYS：用于解决兼容性问题。可配置为在特定程序（如 RUN386.EXE）被调用时，转而执行另一个程序（如 FREE386.COM），从而无需为 Tsugaru OS 单独修改游戏批处理文件。

外部组件

项目中使用了以下外部组件并致谢：

• ORICON：由 MIYAZAKI 和 YAMAZAKI 开发的控制台模拟器。
• Free386：由 nabe 开发的 PharLap 兼容 DOS 扩展器，用于替代 RUN386。
• YAMAND.COM 和 YSDOS.SYS：来自项目作者的另一个开源项目 TOWNSROM。

项目历史

• 2024年8月27日：项目启动。
• 2024年9月6日：开始支持 TGDRV 和 ORICON，实现部分中断功能。
• 2024年10月4日：在社区贡献下，使《VSGP》、《Panic Ball 2》和《Sky Duel》可玩。
• 2026年1月25日：新增 REPLACE.SYS 以支持 RUN386 到 FREE386 的重定向。

Pex：Python可执行文件生成工具

概述

Pex 是一个用于生成 .pex（Python EXecutable）文件的库，这些文件是可执行的 Python 环境，其理念与虚拟环境类似。它扩展了 PEP 441 中提出的思想，使 Python 应用的部署变得像复制文件一样简单。.pex 文件甚至可以包含多个平台特定的 Python 分发包，这意味着单个 .pex 文件可以跨 Linux 和 macOS 平台运行。.pex 文件可以使用 pex 工具构建，Pants、Buck 和 {py}gradle 等构建系统也直接支持构建 .pex 文件。

安装

可以通过 pip 安装 Pex。此外，也可以使用 uv 在 git 克隆中从源代码构建 Pex：

• uv run dev-cmd package
• 然后将生成的 dist/pex 复制到 $PATH 中（例如 ~/bin）。

这种方法的优点是保持 Python 环境尽可能干净，并且更符合 Pex 的哲学。

简单示例

1. 启动包含依赖的解释器：pex requests flask 'psutil>2,<3'
2. 保存 Pip 依赖：通过 pip freeze 生成 requirements.txt 并创建 .pex 文件，之后可在任何地方执行：
   • pex $(pip freeze) -o my_virtualenv.pex
   • 退出虚拟环境后，直接运行 ./my_virtualenv.pex。

临时环境

• 在包含 flask 的环境中运行 webserver.py 脚本：pex flask -- webserver.py
• 使用 Sphinx 的入口点 sphinx:main 启动 Sphinx 的临时 Pex 环境：pex sphinx -e sphinx:main -- --help

使用入口点

对于在配置中指定了 console_scripts 入口点的项目，可以为这些入口点构建独立的可执行文件。例如，构建一个运行 pex-tools 控制台脚本的独立可执行文件：

• pex "pex>=2.1.35" --console-script pex-tools --output-file pex-tools-executable.pex

指定特定解释器

可以构建使用特定解释器类型的 .pex 文件，例如指定 PyPy 解释器：

• pex "pex>=2.1.35" -c pex-tools --python=pypy -o pex-tools-pypy-executable.pex

大多数 Pex 选项可以组合使用，并且提供了等效的简写选项。完整选项列表可通过 pex --help 查看。

文档

关于 Pex、构建 .pex 文件及其工作原理的更多文档可在 https://docs.pex-tool.org 获取。

开发

Pex 使用 uv 配合 dev-cmd 进行测试和开发自动化。安装 uv 后，可通过 uv run dev-cmd 运行测试套件。dev-cmd 提供了许多有用的选项，详细说明见 https://pypi.org/project/dev-cmd/ 。常用命令包括：

• 格式化代码：uvrc format（推荐使用 uvrc 别名代替 uv run dev-cmd）
• 运行 MyPy 类型检查：uvrc typecheck
• 运行特定测试（支持传递参数给 pytest）：uvrc test-py37-integration -- -k test_reproducible_build
• 直接从源代码运行 Pex：python -m pex

NumPyro 概述 NumPyro 是一个轻量级的概率编程库，为 Pyro 提供 NumPy 后端。它依赖 JAX 实现自动微分（autograd）和即时编译（JIT），可高效运行于 GPU、TPU 和 CPU 上。该库仍在积极开发中，API 可能发生变化。

核心特性

• Pyro 原语支持：模型代码可使用 Python/NumPy 以及 Pyro 的 sample、param 等原语，与 Pyro 模型结构相似。
• 推理算法：
  • MCMC：重点支持汉密尔顿蒙特卡洛（HMC）及无回车采样器（NUTS），并提供了 MixedHMC（处理离散潜变量）、HMCECS（数据子集计算似然）等变体。通过 JIT 编译 Verlet 积分器和 NUTS 树构建阶段来加速。
  • 变分推断（VI）：提供基本实现及多种自动生成导引（guides），如用于 ADVI 的 AutoNormal、AutoDiagonalNormal 等，支持离散潜变量（TraceGraph_ELBO， TraceEnum_ELBO）。
• 分布模块：numpyro.distributions 提供分布类、约束和双射变换，API 与 torch.distributions 高度兼容。也支持直接使用 TensorFlow Probability (TFP) 的分布。
• 效果处理器：通过 numpyro.handlers 模块，可以为 sample 等原语提供非标准解释，便于实现自定义推断工具。

示例：八所学校模型 该示例展示如何构建分层模型并进行贝叶斯推断。

1. 模型定义：使用 numpyro.sample 和 numpyro.plate 定义均值 mu、标准差 tau 和各学校效应 theta。
2. MCMC 推断：使用 NUTS 采样器进行后验采样。
   • 首次尝试使用中心化参数化（theta ~ Normal(mu, tau)），结果显示存在较多发散转移和较低的有效样本量，表明链未收敛。
   • 改用非中心化参数化（通过 TransformReparam 效果处理器和 TransformedDistribution，使 theta 基于 Normal(0,1) 变换而来），有效解决了收敛问题（无发散，有效样本量高）。
3. 预测：使用 Predictive 类，基于后验样本对新学校进行预测。

推理算法概述

• MCMC：除 NUTS/HMC 外，还支持处理离散潜变量的 MixedHMC、适用于大数据的 HMCECS、无梯度的 SA（适用于低维模型）以及结合 Gibbs 更新的变体（如 HMCGibbs）。
• 嵌套采样：提供 NestedSampler 封装 jaxns。
• 随机变分推断：提供多种变分目标（如 Trace_ELBO）和自动生成导引（AutoNormal, AutoDiagonalNormal, AutoDAIS 等），适用于不同模型结构。

安装与平台 可通过 pip 安装，支持 CPU、GPU（CUDA）和 Cloud TPU 环境。默认优先使用 GPU。也支持从源码或 conda 安装。

常见问题

• 随机数生成：在推理上下文外调用 numpyro.sample 需显式提供 PRNG 键，或使用 seed 处理器。
• 从 Pyro 迁移：主要差异包括需将 PyTorch 操作改为 JAX 操作、无全局参数存储、需将 PyTorch 网络模块改为 JAX 框架（如 Stax/Flax）以及编写更函数式的代码以利于 JIT 编译。pyro-api 可实现后端无关的模型编写。

未来工作与引用 计划改进推断鲁棒性、支持更多 pyro-api 功能、增加需要二阶导数的算法、与 Funsor 集成等。使用 NumPyro 建议引用相关论文。

Kyanos是一款基于eBPF的网络问题分析工具，能够快速捕获和分析HTTP、Redis、MySQL等网络请求，无需复杂的抓包和分析步骤即可定位网络异常。

核心功能特性：

• 强大的流量过滤：支持基于进程/容器ID、IP/端口、L7协议信息、请求/响应字节大小、延迟等多维度进行精细过滤。
• 高级分析能力：与仅提供细粒度抓包的tcpdump不同，Kyanos支持对捕获的网络包指标进行多维度聚合分析，能快速给出对排查最关键的统计数据。
• 内核级延迟深度分析：提供从网络请求/响应到达网卡、到内核套接字缓冲区的内核跟踪点，并以可视化形式展示，精确定位延迟发生在哪个阶段。
• 轻量无依赖：几乎零依赖，仅需一个二进制文件和一条命令，所有结果在命令行中显示。
• 自动SSL流量解密：所有捕获的请求和响应均以明文呈现。

使用示例：

• ./kyanos watch http：捕获HTTP流量及延迟详情。
• ./kyanos watch redis：捕获Redis流量及延迟详情。
• ./kyanos stat --slow --time 5：统计过去5秒内最慢的请求。
• kyanos stat http --bigresp：快速分析哪个远端IP发送了最大的HTTP响应。

详情视图：选择一条记录进入后，分为“延迟详情”和“详细的请求与响应内容”两部分。延迟详情以流程图形式展示数据包从进程发送到网卡、响应拷贝到套接字缓冲区、再由进程读取的全过程及每步耗时。

系统要求：支持内核版本3.10（3.10.0-957起）和4.14及以上。

获取与使用：从发布页面下载对应架构的二进制包，解压后以root权限运行./kyanos watch即可开始捕获支持协议的所有流量。支持使用方向键或j/k键浏览记录。

项目路线图（1.6.0版本计划）：支持PostgreSQL、HTTP/2、DNS协议解析以及GnuTLS。

反馈与联系：问题可提交至GitHub的issue追踪器。

GDB与DDD调试技巧摘要

GDB前端选项

GDB默认提供命令行界面，可通过以下四种方式增强可视化：

1. TUI模式：使用-tui命令开启基于Curses的窗口界面，支持源码、寄存器等显示，但缺乏变量监控、鼠标交互等高级功能。
2. 配置脚本：通过~/.gdbinit自定义界面，推荐gdb-dashboard或gef等项目。
3. 图形前端：使用DDD等工具，通过GDB机器接口或屏幕抓取与GDB交互。

DDD配置技巧

DDD作为GDB图形前端，需针对性配置：

• 启动冻结修复：在~/.ddd/init中强制设置提示符：

  Ddd*gdbSettings: \unset extended-prompt\n\set prompt (gdb) \n
  

• 尊重gdbinit：删除~/.ddd/init中除提示符外的所有Ddd*gdbSettings，并设置Ddd*saveOptionsOnExit: off。
• 深色模式：设置资源更改文本/背景颜色，如Ddd*graph_edit.background: #333333。
• UTF-8渲染：改用XFT字体（如Inconsolata），通过修改渲染表实现，但数据窗口仍限传统字体。
• 远程GDB：使用ssh -t配置远程命令，通过--host参数连接远程调试。

GDB实用命令

• 执行控制：finish（执行至当前函数返回）、until（执行至指定行）、start（在main处临时断点）。
• 批处理模式：用于自动化分析，如转储核心文件的栈回溯：

  gdb --batch -ex "set print frame-arguments all" -ex "thread apply all bt full" ./program core
  

• 自定义命令：可定义复杂调试流程，例如ktrace命令通过ktrace跟踪系统调用。
• 钩子：hook-stop等钩子可在断点触发时自动执行命令，如显示所有局部变量。

GDB Python API

• 辅助函数：可在.gdbinit中嵌入Python代码，如ftrace命令用于跟踪函数调用。
• 美化打印：通过Python自定义值显示，例如将ICU库的UChar数组渲染为UTF-16字符串。需配置自动加载路径和模块化组织。

DDD特色功能

• 历史值跟踪：通过设置带continue命令的断点记录变量历史值，可用graph history查看或绘图。
• 快捷键：
  • Control+双击：设置临时断点或原地解引用。
  • 拖拽断点移动。
  • Esc键充当临时断点。
  • 直接在源码窗口输入命令。
  • Control+↑/↓快速切换栈帧。

进一步阅读

• Debugging with GDB 官方文档
• DDD手册
• Debugging: The 9 Indispensable Rules（通用调试方法论）