[opensuse] the kernel version
Ok, I am confused. The last thread talked about the kernel being used in Leap 15 that is coming out, as being kernel 4.12. Then this website that was linked on the thread: http://news.softpedia.com/news/linux-kernel-4-12-reached-end-of-life-users-a... talks about how kernel 4.12 has reached end of life and everyone should move to 4.13. So I looked on my desktop running 42.3 with all the latest updates, and this is my kernel:
uname -r 4.4.120-45-default
Then I looked on my laptop running 42.3 with all the latest updates as of a week ago, which uses the kernel:stable repository, and this is the kernel it is using:
uname -r 4.15.15-1.g4904fc3-default
So if 4.12 has reached end of life, then 4.4 (which is what is available in the distribution repos for 42.3) must be really old. But 4.15, which is available from the kernel:stable repository, is far out in the future and not yet being really developed. My conclusions there must be wrong, but why? Is there something to the way they number the kernels that I am missing here? Does openSUSE have a different numbering scheme than the rest of the linux world? -- George Box: 42.3 | KDE Plasma 5.8 | AMD Phenom IIX4 | 64 | 32GB Laptop #1: 42.3 | Gnome 3.20 | AMD FX 7TH GEN | 64 | 32GB Laptop #2: 42.3 | Gnome 3.20 | Core i5 | 64 | 8GB -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-04-09 02:50, George from the tribe wrote:
Ok, I am confused. The last thread talked about the kernel being used in Leap 15 that is coming out, as being kernel 4.12.
Yes.
Then this website that was linked on the thread:
http://news.softpedia.com/news/linux-kernel-4-12-reached-end-of-life-users-a...
talks about how kernel 4.12 has reached end of life and everyone should move to 4.13.
Remember that the Leap kernel, being the same as the SLE kernel, is heavily patched. Quite different than the upstream kernel of the same number.
So I looked on my desktop running 42.3 with all the latest updates, and this is my kernel:
uname -r 4.4.120-45-default
Heavily patched.
Then I looked on my laptop running 42.3 with all the latest updates as of a week ago, which uses the kernel:stable repository, and this is the kernel it is using:
uname -r 4.15.15-1.g4904fc3-default
So if 4.12 has reached end of life, then 4.4 (which is what is available in the distribution repos for 42.3) must be really old. But 4.15, which is available from the kernel:stable repository, is far out in the future and not yet being really developed.
My conclusions there must be wrong, but why? Is there something to the way they number the kernels that I am missing here? Does openSUSE have a different numbering scheme than the rest of the linux world?
I doubt that 4.12 is EOL. Then you must know that SLES, and thus Leap, can not use the latest kernel. A decision is made, then thoroughly tested during many months in an expensive process. Thus the version is not changed. You have to think in terms of "why does SLE use the kernel it uses", not in terms of openSUSE. We simply use the same kernel that they decide to use, whichever it is. That's a fundamental characteristic of Leap. -- Cheers/Saludos Carlos E. R. (testing openSUSE Leap 15.0, at Minas-Anor) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/09/2018 09:03 AM, Carlos E. R. wrote:
On 2018-04-09 02:50, George from the tribe wrote:
Ok, I am confused. The last thread talked about the kernel being used in Leap 15 that is coming out, as being kernel 4.12.
Yes.
Then this website that was linked on the thread:
http://news.softpedia.com/news/linux-kernel-4-12-reached-end-of-life-users-a...
talks about how kernel 4.12 has reached end of life and everyone should move to 4.13.
Remember that the Leap kernel, being the same as the SLE kernel, is heavily patched. Quite different than the upstream kernel of the same number.
So I looked on my desktop running 42.3 with all the latest updates, and this is my kernel: > uname -r 4.4.120-45-default
Heavily patched.
Then I looked on my laptop running 42.3 with all the latest updates as of a week ago, which uses the kernel:stable repository, and this is the kernel it is using: > uname -r 4.15.15-1.g4904fc3-default
So if 4.12 has reached end of life, then 4.4 (which is what is available in the distribution repos for 42.3) must be really old. But 4.15, which is available from the kernel:stable repository, is far out in the future and not yet being really developed.
My conclusions there must be wrong, but why? Is there something to the way they number the kernels that I am missing here? Does openSUSE have a different numbering scheme than the rest of the linux world?
I doubt that 4.12 is EOL.
Then you must know that SLES, and thus Leap, can not use the latest kernel. A decision is made, then thoroughly tested during many months in an expensive process. Thus the version is not changed.
You have to think in terms of "why does SLE use the kernel it uses", not in terms of openSUSE. We simply use the same kernel that they decide to use, whichever it is. That's a fundamental characteristic of Leap.
Ok, makes sense now. Thanks. -- George Box: 42.3 | KDE Plasma 5.8 | AMD Phenom IIX4 | 64 | 32GB Laptop #1: 42.3 | Gnome 3.20 | AMD FX 7TH GEN | 64 | 32GB Laptop #2: 42.3 | Gnome 3.20 | Core i5 | 64 | 8GB -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/08/2018 06:03 PM, Carlos E. R. wrote:
I doubt that 4.12 is EOL.
I posted the link to a web page of that announcement. But here it is directly from Greg Kroah-Hartman (Maybe you've heard of him?) http://lkml.iu.edu/hypermail/linux/kernel/1709.2/02589.html What proof do you require? A personal visit from Linus Torvalds himself? -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-04-09 03:20, John Andersen wrote:
On 04/08/2018 06:03 PM, Carlos E. R. wrote:
I doubt that 4.12 is EOL.
I posted the link to a web page of that announcement.
But here it is directly from Greg Kroah-Hartman (Maybe you've heard of him?) http://lkml.iu.edu/hypermail/linux/kernel/1709.2/02589.html
What proof do you require? A personal visit from Linus Torvalds himself?
Well, see Simon Lees explanation. -- Cheers/Saludos Carlos E. R. (testing openSUSE Leap 15.0, at Minas-Anor) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/04/18 09:20 PM, John Andersen wrote:
On 04/08/2018 06:03 PM, Carlos E. R. wrote:
I doubt that 4.12 is EOL.
I posted the link to a web page of that announcement.
But here it is directly from Greg Kroah-Hartman (Maybe you've heard of him?) http://lkml.iu.edu/hypermail/linux/kernel/1709.2/02589.html
What proof do you require? A personal visit from Linus Torvalds himself?
I'm unclear what point you are trying to make here, John. that posting is 7 months old, yes, but it also seems contradictory. On the one hands it says
I'm announcing the release of the 4.12.14 kernel. All users of the 4.12 kernel series must upgrade.
and on the other it says
Note, the 4.12.y kernel series is now end-of-life, there will not be any more updates. Please move to 4.13.y at this point in time.
If 4.12.y is EOl what the point of announcing a new realise of 4.12.y and recommending upgrading to it? If this is the clarity of Linux kernel communication then I'm not surprised George is confused. I certainly am by this. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/04/18 09:03 PM, Carlos E. R. wrote:
So I looked on my desktop running 42.3 with all the latest updates, and this is my kernel: > uname -r 4.4.120-45-default
Heavily patched.
Indeed. I've never been quite sure where to draw the line between 'patching' and 'changing'. it's all very well to say that earlier version have patches, but that begs the question: why stay with the earlier version rather than upgrade? Somewhere along the like some organizational and structural changes are made to the kernel. I don't regularly read the kernel blogs, but on the occasions I have I see notes about changes in that second number that do more than just clear up minor as well as 'interesting' bugs. I've seen changes in buffering, changes in network performance that have come about by non-trivial changes. Can these be back-patched to 4.4? I'm sure they can, but why? There is kernel:stable.
date; uname -r Thu Apr 12 09:57:49 EDT 2018 4.16.1-1.gfc6541a-default
https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.16-Released leads to .. https://www.phoronix.com/scan.php?page=article&item=linux-416-changes&num=1 <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'. https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.16-Best-Features And eventually to https://www.phoronix.com/scan.php?page=news_item&px=Seven-For-Linux-4.17 https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.17-Idle-Loop-Power -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2018-04-12 at 10:25 -0400, Anton Aylward wrote:
On 08/04/18 09:03 PM, Carlos E. R. wrote:
So I looked on my desktop running 42.3 with all the latest updates, and this is my kernel: > uname -r 4.4.120-45-default
Heavily patched.
Indeed.
I've never been quite sure where to draw the line between 'patching' and 'changing'. it's all very well to say that earlier version have patches, but that begs the question: why stay with the earlier version rather than upgrade?
Again, it is the SLE kernel, You have to think in terms of SLE. Remember, SLE doesn't go for the latest. Why don't they change kernel? Because this one is already tested, it does what it is asked, and testing another costs a huge lot of money. Basically. <https://en.opensuse.org/Portal:Leap/Leap_kernel_version> - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlrPn/wACgkQtTMYHG2NR9WlKACfeXOZLpMoxfizzf+pU8pQdNe9 rFkAnAn/39I4ZbghCsPAApw0WmUEfdG7 =VApF -----END PGP SIGNATURE-----
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2018-04-12 at 15:08 -0500, David C. Rankin wrote:
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
But this is not so, not any longer. We take the core packages from SLE to Leap (say 1/3), so they have tested them before than us, not the other way round. For the rest of the packages (say 2/3), we take them from Tumbleweed, and some years later maybe SLE get them. But this applies to KDE, for instance, and SLE has no KDE. Ie, those package that are tested in Leap are not part of SLE, so we are no longer their testbed. - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlrPwSUACgkQtTMYHG2NR9V/NwCfQaxs+I3gfNOym021GrZyMObi CwsAn2rRDvZgyqIGWTA6UHW3q0HzR7gM =InLH -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/12/2018 04:27 PM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday, 2018-04-12 at 15:08 -0500, David C. Rankin wrote:
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
But this is not so, not any longer.
We take the core packages from SLE to Leap (say 1/3), so they have tested them before than us, not the other way round.
For the rest of the packages (say 2/3), we take them from Tumbleweed, and some years later maybe SLE get them. But this applies to KDE, for instance, and SLE has no KDE. Ie, those package that are tested in Leap are not part of SLE, so we are no longer their testbed.
But this thread is only about the kernel. Mark -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2018-04-12 at 16:30 -0400, Mark Hounschell wrote:
On 04/12/2018 04:27 PM, Carlos E. R. wrote:
On Thursday, 2018-04-12 at 15:08 -0500, David C. Rankin wrote:
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
But this is not so, not any longer.
We take the core packages from SLE to Leap (say 1/3), so they have tested them before than us, not the other way round.
For the rest of the packages (say 2/3), we take them from Tumbleweed, and some years later maybe SLE get them. But this applies to KDE, for instance, and SLE has no KDE. Ie, those package that are tested in Leap are not part of SLE, so we are no longer their testbed.
But this thread is only about the kernel.
Ok, in that case, we are not the test bed for SLE, rather the other way round. The kernel is a core package, so inherited. - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlrPw6QACgkQtTMYHG2NR9UsSACeNfYUqJBxrnVHtB8tqVYNiKHI 9ykAoITVPfdZx0yLI/vUk6kRl/TnGkhm =j33V -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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
On 09/04/18 10:20, George from the tribe wrote:
Ok, I am confused. The last thread talked about the kernel being used in Leap 15 that is coming out, as being kernel 4.12. Then this website that was linked on the thread:
http://news.softpedia.com/news/linux-kernel-4-12-reached-end-of-life-users-a...
talks about how kernel 4.12 has reached end of life and everyone should move to 4.13.
So I looked on my desktop running 42.3 with all the latest updates, and this is my kernel:
uname -r 4.4.120-45-default
Then I looked on my laptop running 42.3 with all the latest updates as of a week ago, which uses the kernel:stable repository, and this is the kernel it is using:
uname -r 4.15.15-1.g4904fc3-default
So if 4.12 has reached end of life, then 4.4 (which is what is available in the distribution repos for 42.3) must be really old. But 4.15, which is available from the kernel:stable repository, is far out in the future and not yet being really developed.
My conclusions there must be wrong, but why? Is there something to the way they number the kernels that I am missing here? Does openSUSE have a different numbering scheme than the rest of the linux world?
openSUSE uses the same kernel numbering scheme as the rest of the world, but kernel naming schemes can be deceptive. SUSE has its own team of kernel maintainers so while 4.12 is no longer maintained upstream openSUSE isn't running the upstream kernel its running the upstream kernel with a series of patches by SUSE kernel developers. Some of these maybe features but most are fixes or support for additional drivers taken from newer kernels. So while upstream has stopped supporting kernel 4.12 SUSE developers will continue to backport fixes and drivers into SUSE/openSUSE's version of the kernel. You may for example have a new fancy device that wasn't originally supported in upstream kernel 4.12 but is supported in kernel 4.15, there is a reasonable chance that a SUSE engineer somewhere may have already ported support for that device into SUSE/openSUSE's version of kernel 4.12, so in this way and many others including security fixes just looking at the kernel number is wrong without also looking at which source "tree" the kernel has been built from. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 04/09/2018 09:14 AM, Simon Lees wrote:
On 09/04/18 10:20, George from the tribe wrote:
Ok, I am confused. The last thread talked about the kernel being used in Leap 15 that is coming out, as being kernel 4.12. Then this website that was linked on the thread:
http://news.softpedia.com/news/linux-kernel-4-12-reached-end-of-life-users-a...
talks about how kernel 4.12 has reached end of life and everyone should move to 4.13.
So I looked on my desktop running 42.3 with all the latest updates, and this is my kernel:
uname -r 4.4.120-45-default
Then I looked on my laptop running 42.3 with all the latest updates as of a week ago, which uses the kernel:stable repository, and this is the kernel it is using:
uname -r 4.15.15-1.g4904fc3-default
So if 4.12 has reached end of life, then 4.4 (which is what is available in the distribution repos for 42.3) must be really old. But 4.15, which is available from the kernel:stable repository, is far out in the future and not yet being really developed.
My conclusions there must be wrong, but why? Is there something to the way they number the kernels that I am missing here? Does openSUSE have a different numbering scheme than the rest of the linux world?
openSUSE uses the same kernel numbering scheme as the rest of the world, but kernel naming schemes can be deceptive.
SUSE has its own team of kernel maintainers so while 4.12 is no longer maintained upstream openSUSE isn't running the upstream kernel its running the upstream kernel with a series of patches by SUSE kernel developers. Some of these maybe features but most are fixes or support for additional drivers taken from newer kernels. So while upstream has stopped supporting kernel 4.12 SUSE developers will continue to backport fixes and drivers into SUSE/openSUSE's version of the kernel.
You may for example have a new fancy device that wasn't originally supported in upstream kernel 4.12 but is supported in kernel 4.15, there is a reasonable chance that a SUSE engineer somewhere may have already ported support for that device into SUSE/openSUSE's version of kernel 4.12, so in this way and many others including security fixes just looking at the kernel number is wrong without also looking at which source "tree" the kernel has been built from.
Ok, that would explain why the original kernel in 42.2 didn't support the wireless card in my laptop but the kernel in the kernel:stable repo had the patch necessary to support it. Thanks, that makes sense now. -- George Box: 42.3 | KDE Plasma 5.8 | AMD Phenom IIX4 | 64 | 32GB Laptop #1: 42.3 | Gnome 3.20 | AMD FX 7TH GEN | 64 | 32GB Laptop #2: 42.3 | Gnome 3.20 | Core i5 | 64 | 8GB -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-04-09 03:18, George from the tribe wrote:
On 04/09/2018 09:14 AM, Simon Lees wrote:
On 09/04/18 10:20, George from the tribe wrote:
openSUSE uses the same kernel numbering scheme as the rest of the world, but kernel naming schemes can be deceptive.
SUSE has its own team of kernel maintainers so while 4.12 is no longer maintained upstream openSUSE isn't running the upstream kernel its running the upstream kernel with a series of patches by SUSE kernel developers. Some of these maybe features but most are fixes or support for additional drivers taken from newer kernels. So while upstream has stopped supporting kernel 4.12 SUSE developers will continue to backport fixes and drivers into SUSE/openSUSE's version of the kernel.
You may for example have a new fancy device that wasn't originally supported in upstream kernel 4.12 but is supported in kernel 4.15, there is a reasonable chance that a SUSE engineer somewhere may have already ported support for that device into SUSE/openSUSE's version of kernel 4.12, so in this way and many others including security fixes just looking at the kernel number is wrong without also looking at which source "tree" the kernel has been built from.
Ok, that would explain why the original kernel in 42.2 didn't support the wireless card in my laptop but the kernel in the kernel:stable repo had the patch necessary to support it. Thanks, that makes sense now.
Well, that's precisely an example of the system not working :-) But if the kernel in 42.3 supports it, that would be a match. -- Cheers/Saludos Carlos E. R. (testing openSUSE Leap 15.0, at Minas-Anor) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Simon Lees wrote:
SUSE has its own team of kernel maintainers so while 4.12 is no longer maintained upstream openSUSE isn't running the upstream kernel its running the upstream kernel with a series of patches by SUSE kernel developers. Some of these maybe features but most are fixes or support for additional drivers taken from newer kernels. So while upstream has stopped supporting kernel 4.12 SUSE developers will continue to backport fixes and drivers into SUSE/openSUSE's version of the kernel. To be honest, I do not find any suitable openSUSE Kernel series for my needs (production, development, desktop). Each kernel series has some downsides:
1. The distribution kernel series for Leap and SLES: * old * sometimes unmaintained from the Kernel developers * new hardware sometimes does not run perfectly, even if some drivers are backported by the SuSE developers 2. Kernel_stable repository: * bleeding edge, but in rare cases the system can become unstable * often problems with proprietary drivers (like the Nvidia graphics driver) 3. Vanilla kernel repository: * I do not find a good documentation about the openSUSE patches * it's unclear, if some patches (e.g. form Apparmor) are important 4. Tumbleweed kernel: * similar to Kernel_stable kernels, but more stable * there is no easy way to use the Tumbleweed kernels in Leap and SLES Fortunately each user can create his own kernels. Depending on the hardware and applications I build my own kernels. Currently I use Kernel 4.15.16. I created this Kernel from the Tumbleweed kernel 4.15.13 and patched it to 4.15.16 with upstream patches. Kernel 4.16.0 is currently no option for my desktops, because the Nvidia drivers fails with kernel 4.16.0. The latest longterm kernel series (4.14.x) would be also an option for me. I would wish an openSUSE kernel series, which uses the latest longterm Kernels, with SuSE patches and with full testing for the supported distributions. Greetings, Björn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/11/2018 10:42 AM, Bjoern Voigt wrote:
Simon Lees wrote:
SUSE has its own team of kernel maintainers so while 4.12 is no longer maintained upstream openSUSE isn't running the upstream kernel its running the upstream kernel with a series of patches by SUSE kernel developers. Some of these maybe features but most are fixes or support for additional drivers taken from newer kernels. So while upstream has stopped supporting kernel 4.12 SUSE developers will continue to backport fixes and drivers into SUSE/openSUSE's version of the kernel. To be honest, I do not find any suitable openSUSE Kernel series for my needs (production, development, desktop). Each kernel series has some downsides:
1. The distribution kernel series for Leap and SLES: * old * sometimes unmaintained from the Kernel developers * new hardware sometimes does not run perfectly, even if some drivers are backported by the SuSE developers 2. Kernel_stable repository: * bleeding edge, but in rare cases the system can become unstable * often problems with proprietary drivers (like the Nvidia graphics driver) 3. Vanilla kernel repository: * I do not find a good documentation about the openSUSE patches * it's unclear, if some patches (e.g. form Apparmor) are important 4. Tumbleweed kernel: * similar to Kernel_stable kernels, but more stable * there is no easy way to use the Tumbleweed kernels in Leap and SLES
Fortunately each user can create his own kernels. Depending on the hardware and applications I build my own kernels. Currently I use Kernel 4.15.16. I created this Kernel from the Tumbleweed kernel 4.15.13 and patched it to 4.15.16 with upstream patches. Kernel 4.16.0 is currently no option for my desktops, because the Nvidia drivers fails with kernel 4.16.0. The latest longterm kernel series (4.14.x) would be also an option for me.
The 340-106 nvidia builds and works fine against the vanilla 4.16.0 kernel. There are patches for the 304-137 nvidia driver that work against the 4.15/4.16 kernel also.
I would wish an openSUSE kernel series, which uses the latest longterm Kernels, with SuSE patches and with full testing for the supported distributions.
I wish they would have used at least the 4.14 long term kernel. I have seen at least one out of kernel driver that would not build against the Leap-15 4.12 kernel because it has some things that the vanilla 4.14 kernel has and this out of kernel driver uses ifdefs around the kernel version. If less than 4.14 it does one thing else another thing. The Leap-15 kernel has some changes that in the vanilla 4.14 kernel causing the ifdefs to incorrectly choose what to do. Mark -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/11/2018 07:42 AM, Bjoern Voigt wrote:
4. Tumbleweed kernel: * similar to Kernel_stable kernels, but more stable * there is no easy way to use the Tumbleweed kernels in Leap and SLES
Fortunately each user can create his own kernels.
Is this because of the patches inserted in Tumbleweed? You mentioned you couldn't find documentation on the suse patches inserted to the vanilla kernel. It would seem that some if not all of these are tied to making that kernel run in the suse/opensuse environment, rather than actually fixing bugs. I'm at a point where I will probably have to abandon Vmware (paying customer for multiple copies for over 10 years) because of 4.12 in Leap 15. I'm probably switching to VirtualBox, since it will run Vmware images directly. Someone at Suse should look at Manjaro's Settings Manager (MSM) which lets you switch kernels with one click. https://wiki.manjaro.org/index.php?title=Manjaro_Settings_Manager https://wiki.manjaro.org/index.php?title=Manjaro_Kernels Note: I fully understand that SLES choosing 4.12 is strictly a business decision but its unfortunate this affects OpensSuse so strongly. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
You mentioned you couldn't find documentation on the suse patches inserted to the vanilla kernel. It would seem that some if not all of these are tied to making that kernel run in the suse/opensuse environment, rather than actually fixing bugs. Sorry, I didn't meant the openSUSE patches in Vanilla kernel. I meant
John Andersen wrote: the openSUSE patches, which are not in the openSUSE Vanilla kernel, but that could be important for some low-level functions like Apparmor. In general the documentation for users, who want to build custom kernels is a bit outdated:
From /usr/share/doc/packages/kernel-source-4.16.0-1/README.SUSE (openSUSE Tumbleweed): WORKING WITH THE SUSE 2.6.x and 3.x KERNEL SOURCES [...] Michal Marek <...>, SUSE Labs, 2010 [...]
* no examples for building kernel RPM packages * no DKMS * Lilo bootloader, but no Grub bootloader * no real-world examples for building external kernel modules (Nvidia driver, VirtualBox drivers ...) Greetings, Björn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/04/18 09:14 PM, Simon Lees wrote:
You may for example have a new fancy device that wasn't originally supported in upstream kernel 4.12 but is supported in kernel 4.15, there is a reasonable chance that a SUSE engineer somewhere may have already ported support for that device into SUSE/openSUSE's version of kernel 4.12, so in this way and many others including security fixes just looking at the kernel number is wrong without also looking at which source "tree" the kernel has been built from.
Since many of us don't read code and aren't interesting in pulling down the code and doing a 3-way comparison to see what in 4,15 has been back-ported by SUSE engineers into the SUSE 4.12 and how it differs from stock 4.12, where does SUSE document all these back-port, by date, high level description, change order number, testing and such? Right now, it hardly seems worth it if I'm not under SLES/SLED contract and am using openSUSE so I'll stick to kernel:stable. George seems happy with that for his laptop. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/12/2018 10:41 PM, Anton Aylward wrote:
On 08/04/18 09:14 PM, Simon Lees wrote:
You may for example have a new fancy device that wasn't originally supported in upstream kernel 4.12 but is supported in kernel 4.15, there is a reasonable chance that a SUSE engineer somewhere may have already ported support for that device into SUSE/openSUSE's version of kernel 4.12, so in this way and many others including security fixes just looking at the kernel number is wrong without also looking at which source "tree" the kernel has been built from. Since many of us don't read code and aren't interesting in pulling down the code and doing a 3-way comparison to see what in 4,15 has been back-ported by SUSE engineers into the SUSE 4.12 and how it differs from stock 4.12, where does SUSE document all these back-port, by date, high level description, change order number, testing and such?
Right now, it hardly seems worth it if I'm not under SLES/SLED contract and am using openSUSE so I'll stick to kernel:stable. George seems happy with that for his laptop.
Yes, I am happy with kernel:stable. I still have one thing I need to work on, a bug fix in my newer laptop for the touchpad, but I haven't had time to get everything reported on that yet. Hopefully this summer. In any case, all very interesting discussions. The flat tire analogy is interesting, but I think there are so many more complexities with a kernel than a tire that it probably doesn't really apply so well. I see the point in thinking that newer is better, but I think all the work suse does to make a good working kernel patched for the best possible coverage and minimal bugs, even if it is quite a bit older, probably works out best for the majority of people. And I expect that is what they are aiming for. -- George Box: 42.3 | KDE Plasma 5.8 | AMD Phenom IIX4 | 64 | 32GB Laptop #1: 42.3 | Gnome 3.20 | AMD FX 7TH GEN | 64 | 32GB Laptop #2: 42.3 | Gnome 3.20 | Core i5 | 64 | 8GB -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (8)
-
Anton Aylward -
Bjoern Voigt -
Carlos E. R. -
David C. Rankin -
George from the tribe -
John Andersen -
Mark Hounschell -
Simon Lees