求科普https://www.kernel.org/内核版本Tag

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

Distributions

› Ubuntu

› Fedora

› CentOS

中文资源站

› 网易开源镜像站

这是一个创建于 4005 天前的主题，其中的信息可能已经有所发展或是发生改变。

---------------------------------------------
mainline: 3.10-rc5 2013-06-09
stable: 3.9.6 2013-06-13
stable: 3.8.13 [EOL] 2013-05-11
stable: 3.7.10 [EOL] 2013-02-27
longterm: 3.4.49 2013-06-13
longterm: 3.2.46 2013-05-30
longterm: 3.0.82 2013-06-13
longterm: 2.6.34.14 2013-01-16
longterm: 2.6.32.61 2013-06-10
linux-next: next-20130607 2013-06-07
---------------------------------------------
https://www.kernel.org/上于20130615显示的信息.
---------------------------------------------

stable: 3.9.6 2013-06-13
stable: 3.8.13 [EOL] 2013-05-11
---------------------------------------------
Q1： EOL 是End-of-life的意思吗? 3.8.13更新于2013-05-11
3.4.49更新于2013-06-13

longterm是long-term support的意思吗?
那为什么3.4.49长期支持,3.8.13就EOL了?

Q2: 2.6.34.14和2.6.32.61版本跨度不大的(不清楚实质区别大不大).
为什么不停止对低版本2.6.32.61的支持?

Q3: 自己编译内核的话是选择stable版还是选择longterm?
选择stable的话要不要选择EOL的? 从不折腾的角度出发.

Q4: 自己编译内核的话选择版本是不是越高越好呢(stable版范围内)?
比如有一些需要高版本内核才能带来的特性体验.
----------------------------------------------
不要提示"就点Latest Stable Kernel下载按钮".
想弄清楚这些tag区别.

不要提示"stable kernel rules".
劳烦用通俗易懂的白话翻译一遍.
来个精彩的类比就再好不过了.V2EX上很多风趣回复.

求科普.谢大伙了.

stable

15 条回复 • 1970-01-01 08:00:00 +08:00

Luzifer

2013-06-15 14:06:41 +08:00

唬. 在v2ex上把这些数字对齐还真不容易.

likuku

2013-06-15 14:10:25 +08:00

A1: 是
3.8 貌似只是个快速过渡版。如同freebsd 5.0，拖拉好几年，一直是个开发版，最后 5.3 直接出世成为5.X第一个稳定生产发行版。

A2: 2.6 的用户还不少，尤其RHEL等，旧发行版生命还未结束，至少安全更新还得继续。
版本号只是个数字，你得去看后面的 changelog

A3: 没理由选择EOL，除非你喜欢冰恋。

A4: 喜欢折腾，又不想轻易死掉，那就点「Latest Stable Kernel」就是了。
但最近两三年，最新Stable有时变化也不小，不小心也可能起不来，尤其牵涉设备和驱动大变化的时候。

Luzifer

2013-06-15 14:13:00 +08:00

顺便求教v2ex上发帖排版

Luzifer

2013-06-15 14:15:41 +08:00

@likuku 回复太迅速了. 赞.

Luzifer

2013-06-15 23:08:53 +08:00

@likuku 再扫盲下. ChangeLog 的 commit 是怎么排的？按时间顺序? 先提交应该在下面吧. 后提交的靠上吧. 比如这个 https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.4.49

Luzifer

2013-06-15 23:16:39 +08:00

commit 1bcf5bcf70fb6f316d4eba792d103af602cb3514
Author: Jan Beulich <[email protected]>
Date: Wed Feb 6 10:30:38 2013 -0500

按 “Date: ” 来看,时间并不是顺序. 修改时间不等于合并时间.

扫盲下. 是按什么时间排的? 是pull request时间还是request merged时间.

所以问上面的问题.

likuku

2013-06-15 23:19:35 +08:00

研究changelog里commit排序，这个有实际意义么？

Luzifer

2013-06-15 23:29:37 +08:00

@likuku 嗯, 我有kernel源码,但源码里没有".git" 所以不能 "git log kernel"

只能看文件的生成时间来推断原始出处.
按时间缩小大致范围. 然后查看commit,看我本地源码是否做出修改.

然后好确定需要合并哪些补丁.

likuku

2013-06-15 23:34:10 +08:00

@Luzifer 你是自己修改内核源码？维护一些自己改写的补丁？

Luzifer

2013-06-15 23:38:21 +08:00

@likuku 嗯啊. 直接 diff 和 patch 会有问题.

likuku

2013-06-15 23:39:21 +08:00

我猜自己装个git，或许就能从kernel.org匿名只读同步最新的git库，如此这般，要知道每一个commit就很容易了。

之前只用过svn来更新freebsd源码，
linux这边是否有提供类似途径我就不知道了。

Luzifer

2013-06-15 23:41:10 +08:00

@likuku 最理想的状态是只合并kernel的commit. 我的思路是不是笨了. 我大脑只有核桃那么大, 望指点.

Luzifer

2013-06-15 23:43:18 +08:00

按时间找到原始commit. 然后git checkout commit 大概就是我本地kernel源码的出处了.

likuku

2013-06-15 23:46:56 +08:00

参考： Kernel.org git repositories : https://git.kernel.org/cgit/

或许，你把你自己作补丁的部分给 git checkout 到本地一份，再 fork 出去一个自己的版本，或许就比较方便了。

Luzifer

2013-06-15 23:52:31 +08:00

@likuku 嗯, 现在算是知道了. 当时图简单.现在太苦逼.

不按规范来, 后续好麻烦. 又得做出无谓的浪费.

得理清一下.然后按你说的来. 分开commit. 然后合并.

谢谢了,谢谢你的回复, 早些休息吧.