[opensuse] Ancient OS and software
LS, As is custom with previous releases of opensuse, leap 15 also has a unsupported and in linux terms ancient os embraced. I just wonder, why not use a LTS linux instead of an OS the opensuse developers have to maintain themself? Of course there is more ancient software like old gcc software etc. Okay, it is tried and stable and it compiles software which does not compile under 8.1 without modification due to syntax errors. A lot of old other stuff too. I do use TW when developing and in all those years it turns out as quite stable except for some glitches happening once a year. It feels like it is good enough for day to day office work, but if you want a little more... Frans. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am Samstag, 28. Juli 2018, 10:59:05 CEST schrieb Frans de Boer:
LS,
As is custom with previous releases of opensuse, leap 15 also has a unsupported and in linux terms ancient os embraced. I just wonder, why not use a LTS linux instead of an OS the opensuse developers have to maintain themself?
Of course there is more ancient software like old gcc software etc. Okay, it is tried and stable and it compiles software which does not compile under 8.1 without modification due to syntax errors. A lot of old other stuff too.
I do use TW when developing and in all those years it turns out as quite stable except for some glitches happening once a year.
It feels like it is good enough for day to day office work, but if you want a little more...
Frans.
I have no idea what you are talking about... -- Mathias Homann Senior Systems Engineer, IT Consultant. IT Trainer Mathias.Homann@openSUSE.org http://www.tuxonline.tech gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
On 2018-07-28 10:59, Frans de Boer wrote:
LS,
As is custom with previous releases of opensuse, leap 15 also has a unsupported and in linux terms ancient os embraced. I just wonder, why not use a LTS linux instead of an OS the opensuse developers have to maintain themself?
I don't understand what you are talking about. The kernel version, perhaps? Yes, the kernel used by Leap is intentionally old. That's a feature. If you want new versions, use Tumbleweed instead. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 28/07/18 07:40 AM, Carlos E. R. wrote:
On 2018-07-28 10:59, Frans de Boer wrote:
LS,
As is custom with previous releases of opensuse, leap 15 also has a unsupported and in linux terms ancient os embraced. I just wonder, why not use a LTS linux instead of an OS the opensuse developers have to maintain themself?
I don't understand what you are talking about. The kernel version, perhaps?
Yes, the kernel used by Leap is intentionally old. That's a feature. If you want new versions, use Tumbleweed instead.
Or add the Kernel_Stable repository to your set of active repositories http://download.opensuse.org/repositories/Kernel:/stable/standard/ I'm currently running # uname -r 4.17.10-3.gf604b8a-default -- 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 28.07.2018 10:59, Frans de Boer wrote:
LS,
As is custom with previous releases of opensuse, leap 15 also has a unsupported and in linux terms ancient os embraced. I just wonder, why not use a LTS linux instead of an OS the opensuse developers have to maintain themself?
Of course there is more ancient software like old gcc software etc. Okay, it is tried and stable and it compiles software which does not compile under 8.1 without modification due to syntax errors. A lot of old other stuff too.
I do use TW when developing and in all those years it turns out as quite stable except for some glitches happening once a year.
It feels like it is good enough for day to day office work, but if you want a little more...
Frans.
Hi Frans, The reasons why Leap 15 has a 4.12 custom kernel and not the 4.14 LTS kernel were explained on a talk at oSC18 (https://events.opensuse.org/conference/oSC18/program/proposal/1954) and in a wiki artikle (https://en.opensuse.org/Portal:Leap/Leap_kernel_version). For other packages like GCC there is a deadline until new verions can get into a release. After that date only bugs get fixed to have a stable release. This takes a few months for Leap and a few days on Tumbleweed. So packages in Tumbleweed are newer but not this stable like in Leap. You have to choose what you need in your case. If you realy need a newer package version on Leap you can install it via an additional repository (https://en.opensuse.org/Additional_package_repositories) Thomas -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/28/2018 03:04 PM, Thomas Heijligen wrote:
On 28.07.2018 10:59, Frans de Boer wrote:
LS,
As is custom with previous releases of opensuse, leap 15 also has a unsupported and in linux terms ancient os embraced. I just wonder, why not use a LTS linux instead of an OS the opensuse developers have to maintain themself?
Of course there is more ancient software like old gcc software etc. Okay, it is tried and stable and it compiles software which does not compile under 8.1 without modification due to syntax errors. A lot of old other stuff too.
I do use TW when developing and in all those years it turns out as quite stable except for some glitches happening once a year.
It feels like it is good enough for day to day office work, but if you want a little more...
Frans.
Hi Frans,
The reasons why Leap 15 has a 4.12 custom kernel and not the 4.14 LTS kernel were explained on a talk at oSC18 (https://events.opensuse.org/conference/oSC18/program/proposal/1954) and in a wiki artikle (https://en.opensuse.org/Portal:Leap/Leap_kernel_version).
For other packages like GCC there is a deadline until new verions can get into a release. After that date only bugs get fixed to have a stable release. This takes a few months for Leap and a few days on Tumbleweed. So packages in Tumbleweed are newer but not this stable like in Leap. You have to choose what you need in your case.
If you realy need a newer package version on Leap you can install it via an additional repository (https://en.opensuse.org/Additional_package_repositories)
Thomas
Unlike a few who don't know how to react properly - some of them are notorious offenders -, I did read also some useful tips which I will follow. Thanks for that. Regards Frans. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/28/2018 03:59 AM, Frans de Boer wrote:
As is custom with previous releases of opensuse, leap 15 also has a unsupported and in linux terms ancient os embraced. I just wonder, why not use a LTS linux instead of an OS the opensuse developers have to maintain themself?
Frans, I have never understood this myself. LTS is at 4.14.56 or so, and would work fine. I think the only reason suse spends about a billion man-hours with backports on monkeying with the kernel -- it that gives them complete version control. Meaning, they are not automatically forced to 4.16 when LTS moves there. That's just a guess. I've never understood the benefit of directing the immense amount of resources suse/opensuse does to a kernel that just could just as well be an off-the-shelf LTS kernel with a few custom config settings. -- 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
On 2018-07-29 05:09, David C. Rankin wrote:
On 07/28/2018 03:59 AM, Frans de Boer wrote:
As is custom with previous releases of opensuse, leap 15 also has a unsupported and in linux terms ancient os embraced. I just wonder, why not use a LTS linux instead of an OS the opensuse developers have to maintain themself?
Frans,
I have never understood this myself. LTS is at 4.14.56 or so, and would work fine. I think the only reason suse spends about a billion man-hours with backports on monkeying with the kernel -- it that gives them complete version control. Meaning, they are not automatically forced to 4.16 when LTS moves there. That's just a guess. I've never understood the benefit of directing the immense amount of resources suse/opensuse does to a kernel that just could just as well be an off-the-shelf LTS kernel with a few custom config settings.
It has been explained many times. openSUSE uses the SUSE (SLES) kernel, and this one, once a candidate version is chosen, undergoes a period of testing with paying customers to verify that it works with them. This process takes months, thousands of man-hours and on sites. They are not going to repeat the costly process just because there is a new kernel upstream. An off the shelf kernel can not be used unless upstream does that costly testing (certification) procedure. <https://en.opensuse.org/Portal:Leap/Leap_kernel_version> -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 07/29/2018 08:01 AM, Carlos E. R. wrote:
It has been explained many times.
openSUSE uses the SUSE (SLES) kernel, and this one, once a candidate version is chosen, undergoes a period of testing with paying customers to verify that it works with them. This process takes months, thousands of man-hours and on sites. They are not going to repeat the costly process just because there is a new kernel upstream.
An off the shelf kernel can not be used unless upstream does that costly testing (certification) procedure.
That was the point, if 4.0.4 worked, then those capabilities would still be in 4.14, they wouldn't disappear? By the time a kernel is a year old, it is one on the most tested pieces of software world wide. There is nothing that makes suse customer machines any different from redhat customer machines. Further, there would be no need for the massive back-porting of new capabilities and security fixes to the old kernel, and customers with new hardware are supported out-of-the-box. Personally, it doesn't make any difference to me, I don't have a dog in that fight, but from a basic business 101 standpoint, if I can reduce the cost of my inputs by 90% -- that's 90% I'm losing now.... Obviously, it has worked for suse, but it has always been one of those curiosities... which I would wager if suse pulled LTS and pushed it out in SLE with the normal SLE config -- it would be seamless, and it would have been done with a savings of 999,999,995 man-hours from the original billion based on the functionality and security fixes already in LTS that would otherwise be part of the massive backport-and-tweak effort. To each, his own... I guess. -- David C. Rankin, J.D.,P.E.
Отправлено с iPhone
29 июля 2018 г., в 20:39, David C. Rankin <drankinatty@suddenlinkmail.com> написал(а):
An off the shelf kernel can not be used unless upstream does that costly testing (certification) procedure.
That was the point, if 4.0.4 worked, then those capabilities would still be in 4.14, they wouldn't disappear? By the time a kernel is a year old, it is one on the most tested pieces of software world wide. There is nothing that makes suse customer machines any different from redhat customer machines.
You obviously do not have the slightest idea what kernel redhat enterprise distribution is using. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/29/2018 12:54 PM, Andrei Borzenkov wrote:
suse customer machines any different from redhat customer machines.
You obviously do not have the slightest idea what kernel redhat enterprise distribution is using.
Your point? -- 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
On 2018-07-29 19:39, David C. Rankin wrote:
On 07/29/2018 08:01 AM, Carlos E. R. wrote:
It has been explained many times.
openSUSE uses the SUSE (SLES) kernel, and this one, once a candidate version is chosen, undergoes a period of testing with paying customers to verify that it works with them. This process takes months, thousands of man-hours and on sites. They are not going to repeat the costly process just because there is a new kernel upstream.
An off the shelf kernel can not be used unless upstream does that costly testing (certification) procedure.
That was the point, if 4.0.4 worked, then those capabilities would still be in 4.14, they wouldn't disappear? By the time a kernel is a year old, it is one on the most tested pieces of software world wide. There is nothing that makes suse customer machines any different from redhat customer machines. Further, there would be no need for the massive back-porting of new capabilities and security fixes to the old kernel, and customers with new hardware are supported out-of-the-box.
They would still have to re-certify the new kernel. You say it works, the client want that in written with a contract that pays so many millions if something happens to not work for whatever reason. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 07/29/2018 01:16 PM, Carlos E. R. wrote:
They would still have to re-certify the new kernel. You say it works, the client want that in written with a contract that pays so many millions if something happens to not work for whatever reason.
Thank makes more sense. If suse has contracted to provide kernel X -- then that's the reason... -- David C. Rankin, J.D.,P.E.
On 2018-07-30 02:47, David C. Rankin wrote:
On 07/29/2018 01:16 PM, Carlos E. R. wrote:
They would still have to re-certify the new kernel. You say it works, the client want that in written with a contract that pays so many millions if something happens to not work for whatever reason.
Thank makes more sense. If suse has contracted to provide kernel X -- then that's the reason...
Suse contracts to provide a certified kernel. Which means tested with those big clients. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
participants (7)
-
Andrei Borzenkov -
Anton Aylward -
Carlos E. R. -
David C. Rankin -
Frans de Boer -
Mathias Homann -
Thomas Heijligen