加载失败
讨论基于一篇把约 125,000 条内核漏洞与提交记录关联起来的分析（相关数据与脚本可见于 kernel-archaeology 这类 GitHub 项目），作者试图按提交者、组织与子系统统计漏洞分布和存续期。评论主要围绕方法学和可操作性展开质疑：缺乏统计显著性检验、未按提交规模或代码复杂度归一化，以及未充分区分子系统的部署与维护差异。关于 CAN（Controller Area Network，一种汽车/工业总线）子系统被标为高漏洞存续期，评论提出多重解释：Linux 中的 CAN 驱动多用于测试，整车实时逻辑常由 SoC 处理，维护者稀少或遥测不足都可能延长漏洞暴露时间。部分讨论同时批评了文章的写作语气（被称为像 Claude/LLM），并讽刺性地警告这些指标可能被误用为人事决策依据而非用于真正的质量改进。
多位评论者质疑这篇分析的可操作性与表述风格，指出文章“读起来像 Claude 写的”，由此降低了信任感。评论中有人具体询问作者是否在建议对特定提交信息（commit messages）或提交模式进行更密集的扫描，以及如何把统计结论转为明确的改进措施。有人警告这些表面化指标可能让决策者“看到了地图却忽略了领土”，担心数据驱动结论会被用来支持既有叙事。对文章带有 LLM-tone 的质疑被认为会影响结论的可采纳性，要求更清晰的行动建议。
评论普遍抱怨原文缺乏统计显著性检验，认为许多较小的百分比差别可能是随机波动而非真实差异。有人按公司/作者自行计算了漏洞占比（例如列出 Intel、Google、Linaro 等的相对份额），并质疑为何文章没有展示按提交或按行数归一化的比较。评论强调需要区分代码复杂度与提交类型，因为公司通常提交大型驱动或模块而个人更多是小修补，这会显著影响按绝对漏洞数的比较。评论建议补充回归分析、置信区间或对潜在混杂变量的控制，以避免误导性结论。
关于 CAN（Controller Area Network）子系统漏洞严重性的争论集中在使用场景与维护生态差异上。有人解释 Linux 的 CAN 驱动更多用于测试/诊断，整车常由 SoC 的实时单元处理 CAN 逻辑，因此内核中的实现可能在真实车载环境中覆盖较少并且更难被发现。另一种可能是维护者稀少、部署多样性低或遥测不足，使得缺陷长期潜伏未被报告，从而拉长漏洞存续期（bug lifetime）。也有人提出高质量的初始提交会把易察觉缺陷剔除，剩下的多为微妙难查的问题；每种成因对应不同的改进策略，因此不能单一解读数据。
有评论者按数据汇总后认为企业贡献者在绝对漏洞数上占比较高，并据此提出多种解释。一个合理的解释是企业往往提交体量更大的功能（如完整驱动或子系统），因此缺陷面更大；独立开发者多做小补丁，按绝对数比较会偏向企业。该评论还提出作者可能因担忧报复或敏感性而回避对公司与个人差异的深入分析，并有人极端化地推测可能存在恶意后门，但这些说法并无严格证据。评论者自己也承认缺乏完整统计检验，因而主张在更多控制变量下再下结论。
多位评论以讽刺方式警告将漏洞计数当作绩效指标或裁员依据会带来荒谬后果。有人戏谑地建议“把引入漏洞最多的人解雇”，并以是否要把 Linus 也开除来凸显这种思路的荒唐性；回复里还有把个体当异常值或用夸张例子嘲讽这种做法。这些评论用幽默与夸张揭示了单一量化指标被滥用的风险，强调应结合背景、统计方法与代码复杂度来制定改进策略，而非做简单榜单式的人事操作。
CAN（Controller Area Network）: 一种广泛用于汽车与工业控制器间通信的串行总线标准；Linux 内核中的 CAN 驱动负责与该总线交互，使用场景与维护生态会显著影响漏洞的发现率与严重度。
SOC（System on Chip）: 将 CPU、GPU、外设控制器等集成在一块芯片上的系统；在汽车中常把实时 CAN 处理放在 SoC 的专用核或 MCU 上，而不是由 Linux 直接处理。
Linux kernel driver（内核驱动）: 运行在操作系统内核空间、负责与硬件或协议交互的代码模块；驱动通常体量大且权限高，缺陷可能导致严重的安全或可靠性问题。
bug lifetime（漏洞存续期）: 从漏洞引入到被发现并修复所经历的时间长度，用于衡量不同子系统中缺陷被暴露与处理的速度。
LLM（Large Language Model）: 大型语言模型（如 Claude、ChatGPT 等）；评论中有人将文章语气比作由 LLM 生成，以此质疑分析深度与可信度。