On 04/12/2018 09:25 AM, Anton Aylward wrote:
<quote> As of writing this morning, the Linux 4.16 merge window has brought changes to 11,329 files with 490,486 lines of code added and 304,188 lines of code deleted. In other words, the Linux 4.16 kernel will be heavier by about 186 thousand lines of code. </quote> That seems a lot to have to 'backport'.
And that is just the 4.15 -> 4.16 transition. There is a ballpark equal number of lines per-minor version update, so to backport all the niceties to 4.12 would require about 1/2 million lines of code. (not to mention the security fixes incorporated therein, and the device support added for the new gadgets and chipsets that have hit the market in that period of time) I've rather marveled at SuSE's use of one kernel. If you can tumble a kernel with tumbleweed, no reason you can't do that with community. But for the primary product, for which we are the witting testbed, as long as security backports are made, and backports of the handful of new desktop/server chipsets that appear, then there is a lot of certainty gained in sticking to a known/tested kernel. Other than those who rush out and buy the latest touch-screen tri-fold pocket-sized computer, not much changes. After close to 2 decades with SuSE and 1 decade with Arch, (all other distros fall somewhere in between), there is a certain appeal the Arch model of kernel maintenance provides. Unlike other libraries or packages, the kernel doesn't depend on Version X of some library or soname y. It is the beginning of the chain. There is rarely, if ever, something that isn't backwards compatible with the kernel (within the sane universe of things). Rolling the kernel requires nothing more that packaging it and insuring no issues crop up and it provides, natively, all the security enhancements and device support that otherwise would have to be backported. Backporting on the otherhand, creates an additional layer of potential problems integrating current changes with an older kernel. From a manpower standpoint it always struck me as being much more burdensome to backport than to simply tweak and package the current kernel. For end users who don't have the latest touch-screen tri-fold pocket-sized computer, it doesn't really matter which way you go. The kernel works. The Achilles' heel of the current SuSE approach of backporting fixes, is the circumstance where new security improvements are built on features not yet backported. In that case it probably takes ten-times the effort to backport the fix than it would to simply tweak and package the new kernel. There is always kernel:stable -- but beware any driver incompatibilities with a non-standard kernel. And, what "alternative kernel I could install" is not really the point. The point is "what do I get when I 'zypper up'?" The kernel that comes with the distro. Like I said before, either way works, so it really boils down to how many times do you want to patch a flat-tire before you finally decide to buy a new one. SuSE is free to spend $1000 patching a $200 tire if they want, the result will always be an old patched $200 tire compared to a new $200 tire -- and which do you think you will get the most mileage from? -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org