SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Has anyone approached GKH, explained the conundrum, and asked if he'd be willing to extend 5.4 support? Or asked what kind of assistance might make such an extension tractable for him?
GKH has mentioned that he's willing for longer support if he's provided the infrastructure and people are willing to use them.
Quote:
Normally I say I will support LTS releases for only 2 years, but if Google and Linaro and others give me the proper testing infrastructure and support, I am willing to support them for longer, ONLY IF people actually use the updated kernels in their devices. It is no good if I keep doing kernel updates and no one ever actually picks them up in their devices
it doesn't matter about the length of a LTS release at all, you can just update to the next major LTS release each year and all is fine. That's the safest and best thing to do, you never want to be running older LTS kernels
It looks similar to the approach Slackware uses for Firefox.
Well, nuts. It sounds like the infrastructure GKH wants is a bunch of different models of Android smartphones on which to test the kernel, which is problematic.
It also sounds like he would take a dim view of Slackware's methodology, which is exactly "running older LTS kernels", though of course that's up to Patrick.
I have a few friends at Google but they're all SREs and SWEs, so unlikely to provide help or insights, but I'll ask around anyway and see if they have a notion of what it would take to get GKH what he needs. Maybe they know someone.
Anyone else think it would make sense to go back to a 4.14 kernel (EOL Jan 2024) for Slackware 15.0? The 4.14 kernel is only 2 years newer than 4.4 but support is projected to run 2 years past 5.4. Or could GKH be persuaded to extend the 5.4 EOL?
This has never been a new issue for Slackware. I doubt Patrick will want to go back that far just for longer kernel LTS support.
If the LTS kernel selected for 15.0 goes EOL, Patrick will simply have to backport patches for critical CVE's manually. Patches will likely become available in any event as other LTS distros will surely have adopted whatever Patrick chooses for 15.0 to their respective distros at the applicable time.
If the LTS kernel selected for 15.0 goes EOL, Patrick will simply have to backport patches for critical CVE's manually. Patches will likely become available in any event as other LTS distros will surely have adopted whatever Patrick chooses for 15.0 to their respective distros at the applicable time.
Well, this is true if the CVE patch is simple enough for Slackware developers to do so. If, on the other hand, the patches are very complex (like the series of problems in the Intel processors) it is possible that the Slackware developers cannot apply the solution.
OpenBSD follows the same model as Slackware, stable and current, but the time between two stable versions is approximately constant, about 6 months. This period that seems short is for not to accumulate too many changes between stable versions. Openbsd also maintains thousands of packages (compiled applications) from ports (the equivalent of slackbuilds). OpenBSD developers have full control of the kernel, libc and compilers. Only two stable versions, the current one and the previous one, are maintained. There is a documented procedure to update from one to another without installing from scratch.
I've love pledge(4) and unveil(4) here in #slackware
I remember the 2.2 to 2.4 era and thereafter the 2.v to 3.x transition era
That where the nightmares...
I'm glad we had a single kernel for a release - it makes stuff consistent and more likely a "stray" package or tarball to built.
I'm more than certain that PV and the team are just as experienced and as competent to pick the best option down the road.
Still I can't help but worry what will it be, because it has to be some sort of trade off. As i stated before, I'm afraid we are gone past that golden age of open source and free software and things will get progressively harder for some time ahead.
Iām doing a (free) operating system (more than just a hobby) for 486
AT clones and a lot of other hardware. This has been brewing for the
last 28 years, and is still not done. Iād like any feedback on any
bugs introduced this release (or older bugs too, for that matter).
Linus
PS. Yes, it's 28 years today since that original announcement
paraphrased above. The shortlog below is obviously just for the last
week, though.
Nothing particularly surprising from the last week - most of the patch
is drivers, with networking and rdma being most noticeable, but
there's various other things in there too. I wish it was smaller than
it is, but it's not _huge_.
Bit if things don't calm down during the upcoming week, though, I may
have to do an rc8.
---
Last edited by cwizardone; 08-25-2019 at 02:30 PM.
So I have an interesting question and looking for advice from the Slackware guru's, if I might ask on this thread, which announces the latest releases of kernels. If this should be a separate thread, moderator feel free to move to new title "Should Slackware stable have a new kernel?"
BACKGROUND: PV is building 4.19.y with -current and 4.4.y for stable. It seems PV is following GHK's advice to use "Latest longterm LTS" for the -current release, but not for the Slackware stable releases. Maybe this is good for stable since 4.19.y EOL is January 2020 (four months from now) and 4.4.y EOL is Feb 2022.
QUESTION: Has PV ever upgraded a stable release's kernel from 4.x.y to 4.x+n.y? I ask because GKH says that older longterm LTS releases "may not" get updates, including security updates unless the kernel is regularly being used by many. So it would seem to me that PV should be upgrading to at least 4.14.y for stable while the next stable release is being developed.
I DO NOT believe that PV or the core team should start to "support" a special kernel for stable releases. While I'm a stable 14.2 user, I have locally built both 4.9, 4.14, and 4.19, I'm currently running 4.19.67, because 4.14.139 was dropping my wireless network connection every three to four hours. I need to try 4.14.140 for the network REVERT of tcp actions and to not be stuck fallingn back from 4.19.y EOL in four months.
SECOND QUESTION: Is my thought that 4.14.y will become the latest longterm "LTS" when 4.19.y reaches EOL in January?
I could see this going either way, though of course it's ultimately up to PV.
I've been upgrading my 14.1 systems with 14.2's 4.4.x kernels with excellent results, so at least in my narrow experience changing to a new LTS kernel within a stable Slackware release lifecycle seems viable.
Before taking that plunge, though, I installed 4.4.x on a non-critical 14.1 system and tested it thoroughly for a while. In the distant past, the kernel would change its interfaces in incompatible ways, but perhaps it has since firmed up and will remain stable.
On the other hand, as someone else has already pointed out, there are likely other distributions which will opt to use 5.4.x beyond its EOL, so perhaps we could consolidate efforts and share the burden of back-porting necessary patches.
If I remember rightly GKH used to always advocate using the latest 'stable' kernel, not LTS.
I believe you are right on that remembrance, that he first advocates for latest 'stable', but he then advocates that if stable can't be used due to tools missing then use the latest longterm release. I was thinking in particular of the situation for 14.2 which doesn't have a compatible gcc for the 5.x kernels (longterm or stable). While the current gcc 5 used in 14.2 meets the requirements to build all the 4.x kernels. Thus my first question asking if PV has ever considered simply upgrading to a latest longterm kernel, such as maybe 4.14, since 4.19 will be EOL shortly.
I do see that the 5.4 kernel will be the next LTS, to be released hopefully in 2019, but its life span is very short Dec 2021, two years, compared to 4.14 which is January 2024.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
