“目前我查到的有这三种方法”……与其焦虑不如先去办办看。

@volvo007 如果只是要安装应用程序包，不自己 patch 内核的话，你可以用 image builder 自己做一个预先打包了你想要安装的包的 image 拿来刷机，不需要编译

用人的人的利益 vs 治人的人的利益

@vcn8yjOogEL 对的，除非要改内核开启不支持的特性或者树外设备，否则没必要自己编译。

当然是系统升个级就跟以前不兼容的绿联啦

日经日读，月经月诵

带外管理

带鱼屏放左侧，正常屏放底部

大家都抄 AWS ，你不抄、抄得不全、抄得不快，那你就是错的。

小店吃饭可以用八达通

晕，两头挨怼。我还是匿了吧。

@cnt2ex 我对你和 @Jirajine 的整个话题没有参与讨论的欲望，他说的因为 security critical 而一直升级的合理性我也不帮他辩护（事实上我也不同意）。

只是针对你说的“一个包 5.1.0 的版本存在严重安全漏洞，我只需要 5.1.1 的版本，或者是 5.2.x 的版本修复这个漏洞，不代表我就一定要更新到 6.8.1”这段。

你认为 5.1.0 有严重 security 漏洞，你升到 5.1.1 修复了，就不需要继续升级了。但如果上游的浏览器开发团队坚持 rolling 发布，过时的版本哪怕安全漏洞也不修，想要解决安全问题就要跟着它升到很信的版本呢？如果 5.1.0 里的某个严重安全漏洞过了很久才被人发现，这时上游发布的版本已经是 5.2.x 甚至 6.8.x 了，它只会在 6.8.x branch 里修这个漏洞，已经不管 5.2.x 了，你还想要一个 5.1.1 ，跟谁去要呢？浏览器团队已经不管这事了。那只能 distro 软对来做 backport……然后这么大一个软件，并不能指望 distro 团队的力量跟的上，即使能力有，也不能指望人家愿意往这上面投精力，毕竟这个“特定的”浏览器没有那么刚需，人家还有肯出 ESR 版的保底浏览器呢。

再重申一边，我不支持 @Jirajine 的观点。我同意你举的例子，很多服务器基础设施软件的安全更新行为足以证明“security critical 这一点，根本无法作为一个包"必须要一直升级的程序"的理由”。但是，回到某个“特定的”浏览器这事，人家上游怎么发版，是人家自己说了算的，人家就是要 rolling ，就是不管旧版本的 branch ，那么对这个“特定的”软件的“security critical”保障，那就只能靠追新来解决。说到底是 symver point release 的 distro 跟 rolling release 的应用程序之间维护方式的矛盾，只是个特例，咱们拿具体程序来讨论的时候就是说的这个特例。

@cnt2ex 他说的 backport 看来是作为一个通用词，不是说指 deb 系发行版里的`backports`这个 repo

不过“一个包 5.1.0 的版本存在严重安全漏洞，我只需要 5.1.1 的版本，或者是 5.2.x 的版本修复这个漏洞，不代表我就一定要更新到 6.8.1”这事不一定可行。虽然大部分基础设施类软件的上游一般都会在受支持的版本里仍然提供 critical fix ，但有一种情况，可能 distro 里打包的随着时间已经不受上游支持了，那就只能 distro 自己 backport 了；还有一种情况就是像 chromium 这样，上游一直在 rolling ，并不会维护特定的 LTS 版本，要安全补丁只能跟着更新，而且代码量又巨大，distro 做不来 backport 的。

上辈子加班狗猝死穿越过来的

Cannnical 历史上搞 upstart 搞 unity 最终都坚持不下去了……目测 snap 也火不起来。

比如赵公堤、花圃、乌龟潭之类，在杨公堤以西的一些地方。其实就连曲院风荷的西边都没那么多人。