On 04/12/2018 04:08 PM, David C. Rankin wrote:
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?
Amen David. I agree %100. But as someone else has already said, some contributor has probably paid them more than the cost of that new tire just to patch the old one that they recognize. As long as uname says 4.12 they are happy and probably have no idea what it actually takes to patch that tire. They have made it financially irresponsible for SuSE not to package the kernel they want, I'm sure. That contributor is the one that will just "freak out" when their tire appears to be new instead of patched. I think SuSE should at least provide a "currently stable" maybe even "vanilla" kernel package along with their "paid for" version. At least for us unwitting testbeders of Leap. Regards Mark -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org