@IgniteWhite 硬件兼容不是发行版的事，它属于内核+开发者+用户三者博弈的结果。没有任何一个发行版会把硬件支持多作为自己的卖点，即使支持也不是白支持的，rhel/suse 能在 s390 架构的硬件下跑我们谁也用不上。内核不支持就 github 魔改支持，github 魔改也支持不了用户就不要买这个硬件。你想用 KDE+Wayland 还非要买 N 卡哪个发行版也救不了。非要选的话，尽量选内核版本新的或者不新也要有 backport 能力的，然后买一些半新不旧的硬件，排除高端游戏硬件，你搞个外星人带显卡坞恐怕不行，搞个创新声卡恐怕也不行。Linux user 的电脑还是得跟内核走不要跑在它前面。一般三年前的主流配置现在才支持很正常。总之中规中矩的攒个电脑，CPU 落后一代，内存可以超级大，显卡选个 A 卡。挑个新一点的内核，多折腾折腾打包写码比找驱动强...毕竟没几个装 Linux 是想给它开发驱动的...

回答一下楼主的问题，我是 2008 年中成为 openSUSE 用户，2012 年成为社区 developer，今天是 2020 年的尾巴。已经 12 年了。我是经历过系统把硬件用到用不了的人，第一次重装系统是因为我的 IBM 本是 2007 年买的，到了 2016 年它本身已经无法使用也很难找到配件了。中国台湾的 swyear 入坑比我还早，我们社区跟 Debian 一样也是经历过成员逝世这种传说级事件的了。能发 RIP 的 Linux 社区现在还不多。你用不下去的时候可以想想有人用了 12 年，而且在论坛应该还能找到我。

早年我说过一些拿到现在会很不舒服的话，这里面有我个人原因，也有当时的环境原因。当时的环境是 Canonical 确实在做着一些老派 Linux User 看不惯的事情，有点 dirty 。我个人原因可能很多 Linux 用户都有，因为这种传承来自 Linus 和 RMS，就是比较喜欢 rant，尤其是刚接触开源的人，我也不例外。应该是伤害过很多人，抱歉。放在现在的环境应该是很不合适的，所以请不要再转引了。放在当时的环境可能还是合适的，因为当时的 Linux User 主要集中在 Twitter，很多 Ubuntu 社区的元老都有号，她们对我说的并没有明确提出过反对意见，当然可能是尊重我的言论自由，也可能觉得和我杠比较跌份，谁知道呢。我感觉应该是戳中了一些无法洗的痛点的，但毕竟商业行为和社区行为无关。如果你当时很不舒服，可能是你只是一个社区用户，并不 care 商业行为。这些年我看到了 Linux 社区的发展壮大，比如 Arch 和 SUSE 现在的耦合度已经非常高了。而商业行为比如阿里比如 Deepin 比如 Kingsoft 也已经找到了与开源并存的方式，我觉得未来我们关注的应该是如何保持社区一直有人而不要自然消亡。不需要那么排斥商业。因为野蛮生长的时代已经过去了。比如 Deepin 我只能说它码写的渣但绝不会再说它的路走的不对。所以黑铁时代的狂言大话就不要拿来影响黄金时代入坑的少年少女们了。谢谢🙏

0. 是文案。中文版本是我出的。maker’s choice 是造物主的选择。有点天择说的味道了，已经降了调了，不然怎么办？神之操作系统？ Linus 已经不用了...
1. 造谣一张嘴辟谣跑断腿。我跟 UbuntuTweak 的开发者本身是认识的，他本人这么多年应该没在任何场合说你说我的这些事，这就证明这本身就没有事。早年我写文的时间点是主席刚被 Canonical 招为居家开发。文章的意思是说 UbuntuTweak 的倒掉表明 Ubuntu 可能已经好到不需要 Tweak 了，同理招他的 point 已经没了，那么他应该转型干别的开发。这是职业发展的建议。请不要捕风捉影断章取义空穴来风。同样小白不要用也是有历史背景的，背景是 Ubuntu 中文社区很强大，openSUSE 中文社区刚起步，对小白不是很友好，应该先用 Ubuntu 入门再看情况转 openSUSE 。你总结为小白不要用放在这里是关公战秦琼。我跟 Ubuntu 社区的元老一叶、主席、shellexy 私交都可以，她们都给过我很多帮助，请不要在公告场合说这些分裂社区的话了。
2. Arch 的 IRC 是最活跃的 IRC，我们的论坛是最活跃的论坛，管理员除了我都是 Arch 的人，用户也有很多 用 Manjaro 的，之前 Down 的时候她们还说以为第二个 Linuxsir 没了。日活比 Debian 中文论坛高一些，应该还是不如 U 坛，不过 U 坛近几年在走下坡路，可能是没上 Discourse 的车，也可能是 V 坛太火了，谁知道呢，我已经很久不关注其它社区的发展了，因为身体条件不再允许熬夜了。

肯定是 dde 的锅咯……

这个做出来记得发淘宝链接，我要买一个，这外壳看着就洋气🤣🤣🤣

@ivanchou 哈哈 我也是这个意思

楼主还不如关心关心镜像，就算 Debian 比 Fedora 早 5 小时，镜像是每六小时同时 rsync 取包，那有什么用……

@okudayukiko0

我不是给 openSUSE 洗地的啊，慢就慢呗 :doge:

看了下那个 issue ，你也是会挑...那个 issue MySQL 自己都是偷偷补上的...SUSE 也是在一个大补丁集里补的， openSUSE 单独发了一个更新（这么看似乎还不错？）

另外比较企业版跟社区版也没意义啊… SLE 收费的。因为你已经是确定不想花钱了，那沉没成本就应该选择接受。

正确的解决你那个疑问的方式是，足够多的样本量（ 100 个重大安全事件？），社区版跟社区版比，看你日常使用的那个镜像的 update 通道里面那个更新的创建时间。 leaf （比如没人用的包）和组织结构（行政方式和松散管理）作为沉没成本抛开。

第一， openSUSE 的 mysql “可能”是个社区包， bug report 肯定会及时发，能不能及时更新是维护者的事情。 PS ：安全团队不是修安全问题，是发现通知审计安全问题。这对所有发行版都适用，包括 Debian ，你仔细找肯定会有别的发行版修了， Debian 落后几十小时的情况。人有三急，这都是半公开的秘密了。

第二，不是社区包，这十几个小时想想也正常，企业版维护者提交更新请求， review 和通过请求那人没起床呢。我不相信这种情况别人没有，至少看看 Fedora 也一样。那 Debian 肯定也跑不了。

至少我没见过：安全更新可以直接发布（因为那样所有的修复都会以安全更新的名义发出去），或者更新可以直接发布（看起来 Debian 似乎是这样？因为那样，质量无法保证。仅举一例：所有的问题都能通过更新解决，但发行版的更新策略决定了不是所有问题的修复都能够使用更新通道。所以至少要有同行评议或者一个主抓的人。如果 Debian 选择无脑相信，那就是它管理模式的弱点），或者安全团队直接更新有问题的软件（这会造成所有人都不 care 安全问题）。

所以你说的其实还是发行版的共性问题。

再来回答楼主的问题。

不同发行版差几十天的也有，比如社区发行版，维护者度假去了。

openSUSE 还有 SUSE 修了我不修的情况，因为我不认为受影响。比如 marked.js 问题，它是包含在 nodejs 里面用于编译时候创建 html 的，编译后的包里根本没有它。那它的代码的安全问题就不需要修复。这时候比如十几天后我闲得发慌就顺手补上这个谁也不会影响的安全漏洞，就会出现你说的那个情况。或者说我请求提交了，跟我对接的维护者没有实时做同行评审，这个在主流发行版也不全有，可以看成往自己 GitHub 灌 commit 跟提交 pull request 的区别。

流程上 Debian 应该比 RH 快，因为 RH 是企业版，强制 QA 。 Debian 不需要受这个限制。但现实中往往是企业版快，因为都有安全团队，一般都是修了自己再往上游交漏洞，正规军和游击队的区别。如果是外部发现，理论应该是 Debian 快，但绝大部分安全问题都是业内专家自己发现的，外部发现很少有告诉你的。

关于安全问题，我认为的第一梯队是 Debian 和企业版，第二梯队是基于企业版的发行版（因为有安全团队和 QA 双重保证），和独立包管理架构但人数很多的发行版比如 arch （应该提到第一梯队，但因为这类发行版的人数足以支撑运作独立的安全团队，却不足以让他们全职工作），第三梯队是基于第一，第二梯队的发行版，因为即使有 QA 和安全团队也还是天然的慢，不慢绝对是因为变相弯道超车，但可能把轮子跑丢，第四梯队是基于 Ubuntu 的发行版，和十分小众养不起安全团队的发行版，他们要么生死由命，要么只能在问题披露后才开始着手修复。 BSD 系列不了解不置喙

实名反对高票答案。但反对也没有用，因为我猜那是摘抄。还有我不是来给 openSUSE 洗地的。

安全问题是有静默期的。发现问题到上游收悉是第一阶段，上游收悉到上游修复是第二阶段，上游修复到通知所有主流发行版是第三阶段（前提发行版有安全团队，比如 Mint 和一些主打美观的发行版根本就没有这样的 team ，自己开发的桌面环境都没有安全审计），主流发行版发布更新和问题披露是第四阶段。

我们能看到的安全问题应该从披露那个时点开始。所谓发行版补丁速度应该是指第四阶段披露和更新这两个并行作业的时间差（如果你在短跑，你应该不会回头看别人）。

具体怎么研究我也不会，因为是事中不透明的。事后看发行版的 bug 创建时间是没用的，因为 Redhat 的创建时间比 Debian 整整早了 20 个小时。但考虑到创建时 bug 是不公开的，所有发行版的 bug report 也都是不公开的，我觉得这个时间点不能代表响应速度（因为可能有机器人）。

另外那个 4 月 6 日 0 时肯定是发现时间，只不过后来页面公开了，被误以为是披露时间。按照安全问题的标准流程，不可能不给下游留修复时间就披露，下游比披露时间普遍晚一天是不可能的。

看软件包发布时间也是没用的，因为 RPM 系一般都是企业版支撑，有 QA 的，甚至还需要测试整合度（防止安全问题修好了，生产环境却挂了）。 Fedora 我不是很熟悉，只拿 openSUSE 说，正确的比较是 openSUSE 的 submit request 创建时间跟 Debian bugzilla 上面的 release 时间比，这样才能剔除 QA/autoQA 的作用。至于要不要 QA ，至少大公司认为是要的。至少我觉得 RPM 系比 Deb 系全面落后不可能是因为领工资不干活的原因。

PS ：有人说 openSUSE 的安全补丁比 SLE 慢，确实慢。我参与过的几十个安全更新里面， Leap 跟 SLE 是同时修复（一个企业版的维护者管两个包）， Leap 因为有些包跟 SLE 不一样，所以单独再跑一遍整合度测试。另外 openSUSE bugzilla 上面那个机器人不是实时的，我经常遇到我修好了一个 bug ，机器人两天之后才去更新页面，具体原理因为不是我写的，所以我不能说可能考虑了镜像同步检测这种话，也许就是 cron job 定时跑有阻塞呢。

另外还要考虑修复的有效性。 Debian 的 bugzilla 上 4 月 9 日还有人说修复好像没啥用，或者刷不出更新的问题。

再说一下 RHEL ，我看到楼上说的那个修复时间就感觉不正常，主要怀疑一是 RH 的关系铁，维护者私下收邮件了，或者就是他们发现的；二是老版本根本没受影响 bug 关得快。但看到 4 月 8 日 RH 的 errata 刚出来我就放心了。关于 RH 的时间全部弄错了。所以对 Fedora 的指责也是无端的，至少根据 bug report ， Fedora 的 QA 确认时间比 RH 6 要早，那请问这十几个小时他们是睡大觉去了嘛。

再来说 Debian 和 Ubuntu ，前后就差三分钟，是无脑 forward 的吧？据我所知 Debian 和 Ubuntu 不是所有底层包都完全相同的， Debian 能用 Ubuntu 可以用，但不一定系统不挂，三分钟能做完这一切？ excuse me ？这种无脑 forward 的问题存在于全部 deb 链条， Debian 到 Ubuntu ， Ubuntu 到一水儿的基于 Ubuntu 的发行版，似乎都刻意忽略了自己实际上改过底层这件事。按照原理讲，基于某某应该意味着你比某某要慢几个小时，因为你有你的测试要做。实际看好像这里的问题所有人都选择不去细想。

基于这些，我觉得高票答案的结论没有一条是准确的，正确答案应该是绝大多数主流发行版都是在 4 月 8 日这天搞定这个问题的（参考 Arch Linux 的时间，应该是没有 QA 的发行版里面比较客观的平均时间，因为它不需要制作包，所以可视为发布即到达）。所有发行版都是在 7 号晚九点左右知悉（因为上游是统一通知），第二天早 8 点左右开始陆续修复，最快跟最慢前后不会超过 6 个小时，这里包含 QA 时间，也就是说发布一个更新，不同发行版有工序上的差别，单单一个快字根本不足以说明问题，至少我认为 centos 的 fix 应该是相当 solid 的不会出现辗转反复一修二修三修这种情况。

最后这只是一个独例的分析，不足以得出普遍性结论的。

关于安全问题，我的建议是除非你自己就是安全专家，非常熟悉这个行业，否则请相信你发行版的专业性。不然就会出现外行看内行，得到南辕北辙的结论的情况。

appimage

发个图

A 卡好像官方驱动被放弃了...

没有 security team 的，敢用？ best wishes...

@lyric

就是从黑名单拉出来后，它新的更新不推送

@choury 不是的，是之后你再也刷不出它的微信了，第二天都不行