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?

2 members found this post helpful.

On second thought, as now gcc has been upgraded in -current, kernels for 14.2 will still need to be compiled specifically. As as aside I will have to compile kernels for Slint as well from now on.

1 members found this post helpful.

The lack of support for modern hardware would be a major problem.

1 members found this post helpful.

Yeah...pretty much anyone with modernish hardware would have to stay on 4.19. I don't think the Ryzen is supported at all with 4.4?

Take this with a grain of salt - i never maintained too much of a user base:

1. hardware dropping backward compatibility is a real concern due to particular security fixes as of late.
2. we might be facing times not allowing the luxury of maintaining the kernel's minor version over Slackware's release life time.
3. so far, Slackware was proven exceptionally able to run stable on upgraded kernel versions - be it to LTS or some of the more volatile branches.
4. the other option is to streamline either full releases, or introduce "sub releases" (15.0.1 or 15.0b) with updated kernel, gcc and glibc core with the other patches just laid over the release tree from the /patches directory?

Or what else could we do?

I just fail to see using -current to install on recent hardware being the optimal option for the future?

1 members found this post helpful.

I suppose some of the other options are:

1. If GKH is going to do these mini EOL releases, Pat or some of the Slackware core team would start maintaining these kernels themselves past the official EOL.

2. 15.0 either has to be 4.19 or 5.4, no two ways about it. Seeing as we're very close to 5.4, I would imagine that should be the kernel for 15.0 and then Slackware releases would have to be closer together with newer kernels. This would mean that 15.0 had a short time till EOL, but so be it.

3. More focus is put into -current with updates first put into /testing and then new software released into the main -current distro when Pat and the community see it as being sufficiently stable.

It looks like something is going to have to change though, these luxurious waits between stable releases may soon be a thing of the past.

1 members found this post helpful.

Kernel update 3.16.73 is now available at

https://www.kernel.org/

The change log,
https://cdn.kernel.org/pub/linux/ker...ngeLog-3.16.73

Or Slackware could not provide kernel updates past the point when a kernel is EOL'd from kernel.org. I know Pat and team are smart, but I don't know if they have the capability to keep up with patching security issues within the kernel. There's a lot of software in Slackware that doesn't really see updates. Now, with the importance of the kernel, I imagine something will be done to make sure the latest stable release isn't stuck on an EOL'd kernel, but who knows what that will be.

But this is all speculation without knowing what future releases are going to do. Based on Pat's posts, it looks like he's working on something relatively big that has yet to land in -current. This could be the reason for this release taking so long. 15.1 might be released in less than 2 years. I'm sure Pat is going to take a gander at the current state of Linux software and use that to help decide how quickly he wants to put out a new release. He may decide to go with longer release dates between stable releases, which might require him to figure out what he wants to do when a kernel release used on the latest stable Slackware is EOL'd.

If it were me (since I'm certainly not smart enough to patch a kernel), I'd leave the latest version of that EOL'd kernel in the patches/ tree and then offer newer kernel versions in the testing/ tree. This allows those that want to ensure stability to stick with older releases and those that want the security (and hardware) updates can get them officially from Pat.

Then there's those of us who just compile their own newer kernels who don't really care what the latest release is in the stable version of Slackware.

That is already the case for Slackware 14.1 and older; in 14.2 the kernel (and compilation tools) had to be UPgraded just to supply a newer kernel (and that was just within the 4.14.* series). So yes, indeed, it is very difficult to maintain an EOL kernel (I know at least Red Hat, with their commercial update support, can do it).

In my post, I was mainly referring to the latest stable release of Slackware. I think Pat tries to do what he can with previous releases, but his hands are often tied from upstream, which may end up happening with the latest stable release at some point.

Hope that GKH will extend the support of 5.4, or I'd rather move forward to the next LTS when 5.4 comes to its end.
Bcache was reported broken before 4.19. There are also random PCIe problems with my old i7-2670qm.
Version 4.14 seems to be the most broken LTS kernel ever.

1 members found this post helpful.

It is very difficult to keep the current version model ,stable and current, while using kernels by kernel.org. It seems that two paths open:

1- Follow kernel.org but convert Slackware into a rolling distribution. This would complicate the work of slackbuilds.org a lot.

2- Leave kernel.org and use someone's kernel that can include/adapt patches for kernels that become EOL. I think only CentOS (RedHat) and Ubuntu can do that (not sure if there is some more).

If it helps

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.

1 members found this post helpful.

Another round of updates has been scheduled for release on Saturday evenning, GMT.

If no problems are found while testing the release candidates, they might be available late Friday
or early Saturday (depending on your time zone).

The 5.2.10 update will accommodate 135 patches.
http://lkml.iu.edu/hypermail/linux/k...8.2/06617.html

The 4.19.68 update will have 85 patches.
http://lkml.iu.edu/hypermail/linux/k...8.2/06860.html

The 4.14.140 update will contain 71 patches.
http://lkml.iu.edu/hypermail/linux/k...8.2/06807.html

The 4.9.190 update will include 103 patches.
http://lkml.iu.edu/hypermail/linux/k...8.2/07032.html

Lastly, the 4.4.190 update will incorporate 78 patches.
http://lkml.iu.edu/hypermail/linux/k...8.2/07107.html

3 members found this post helpful.

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?

1 members found this post helpful.