首页   注册   登录

marguerite

V2EX 第 3415 号会员,加入于 2010-12-03 04:34:17 +08:00
KDE 居然有语音助理了,叫 mycroft
Linux  •  marguerite  •  2017-03-17 11:08:11 AM  •  最后回复来自 mortal
10
疑似微信 bug 一枚
微信  •  marguerite  •  2015-11-11 15:18:59 PM  •  最后回复来自 lyric
11
你们过年发短信会不会给前女友?
情感问题  •  marguerite  •  2015-02-19 17:09:03 PM  •  最后回复来自 Lucius
41
建议加入一个 微信 节点
反馈  •  marguerite  •  2015-02-16 16:35:03 PM  •  最后回复来自 Kai
1
发现了微信 6.1.1 bug 两枚
分享发现  •  marguerite  •  2015-03-04 23:22:48 PM  •  最后回复来自 lyric
18
systemd 开发者 Lennart Poettering 在 G+ 喷 Linus 中英对照版
分享创造  •  marguerite  •  2014-10-09 16:37:51 PM  •  最后回复来自 jiang42
6
Baiduspider 不爬我的 phpbb 站怎么办?
站长  •  marguerite  •  2013-05-28 02:38:12 AM  •  最后回复来自 marguerite
20
openSUSE 中文论坛即将上线
openSUSE  •  marguerite  •  2013-03-30 03:58:21 AM  •  最后回复来自 gundamlh
6
marguerite 最近回复了
2017-04-01 00:40:00 +08:00
回复了 kangsgo 创建的主题 Linux 请问 Linux 运行一晚上第二天就卡死是怎么回事
肯定是 dde 的锅咯……
2017-03-31 08:22:52 +08:00
回复了 gaayyy 创建的主题 程序员 来围观一下三哥的奇葩需求吧~
这个做出来记得发淘宝链接,我要买一个,这外壳看着就洋气🤣🤣🤣
2017-03-17 08:33:30 +08:00
回复了 marguerite 创建的主题 Linux KDE 居然有语音助理了,叫 mycroft
@ivanchou 哈哈 我也是这个意思
2017-03-12 14:07:52 +08:00
回复了 okudayukiko0 创建的主题 Linux Linux 发行版的补丁更新速度?
楼主还不如关心关心镜像,就算 Debian 比 Fedora 早 5 小时,镜像是每六小时同时 rsync 取包,那有什么用……
2017-03-12 14:05:17 +08:00
回复了 okudayukiko0 创建的主题 Linux Linux 发行版的补丁更新速度?
@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 安全问题)。

所以你说的其实还是发行版的共性问题。
2017-03-10 14:09:23 +08:00
回复了 okudayukiko0 创建的主题 Linux Linux 发行版的补丁更新速度?
再来回答楼主的问题。

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

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

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

关于安全问题,我认为的第一梯队是 Debian 和企业版,第二梯队是基于企业版的发行版(因为有安全团队和 QA 双重保证),和独立包管理架构但人数很多的发行版比如 arch (应该提到第一梯队,但因为这类发行版的人数足以支撑运作独立的安全团队,却不足以让他们全职工作),第三梯队是基于第一,第二梯队的发行版,因为即使有 QA 和安全团队也还是天然的慢,不慢绝对是因为变相弯道超车,但可能把轮子跑丢,第四梯队是基于 Ubuntu 的发行版,和十分小众养不起安全团队的发行版,他们要么生死由命,要么只能在问题披露后才开始着手修复。 BSD 系列不了解不置喙
2017-03-10 13:27:51 +08:00
回复了 okudayukiko0 创建的主题 Linux Linux 发行版的补丁更新速度?
实名反对高票答案。但反对也没有用,因为我猜那是摘抄。还有我不是来给 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
发个图
关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2003 人在线   最高记录 5043   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.3 · 25ms · UTC 00:14 · PVG 08:14 · LAX 16:14 · JFK 19:14
♥ Do have faith in what you're doing.