@kjhambrick

On your effort with the script looking after the kernel changes - my appreciation!

However, I do believe that a better/simpler/safer approach will be for Patrick to get privately in touch with Greg KH and ask him what exactly is wrong with 4.4.y as it is the stable kernel Slackware is providing. IMO, in both occasions, Greg KH used some ambiguous wording when referring to 4.4.y, I'm not sure if he relates also to the actual release or just pointing to future releases when he tells it's not safe to use.

Slackware 14.0, 14.1, and 14.2 are the supported Slackware versions. Upgraded 14.0 uses kernel 3.2.98, 14.1 uses 3.10.107, and 14.2 uses 4.4.153. I don't speak for P.V. but you can guess the reason. It's probably not because 3.2.98, 3.10.107, and 4.4.153 are so good and secure but because 14.0 started at 3.2.29, 14.1 started at 3.10.17, and 14.2 started at 4.4.14.

Slackware 14.0 got some Spectre/Meltdown fixes with 3.2.98 but 14.1 did not get the fixes because of the 3.10.x kernel. Slackware 14.2 kernel has lots of fixes, but it does not use 4.4.x kernels because of their superiority but because 14.2 started with 4.4.x.

A cursory look at the changelogs gave me the impression that the latest stable kernels receive more fixes against potential exploitation of Spectre than longterm kernels.

abga --

I wrote the script a while back when I was seeking CVE- References in the Kernel Logs.

It was for my info only but I thought I would share it here when Petri Kaukasoina ran the `grep <<xxx>> |wc` commands.

I wrote it because simple grep commands against the complex 1::M - Header :: Detail Structure of the ChangeLog Files don't work very well.


I rarely make ( hmmm ... I am not sure I have ever made ) any recommendations to Pat and the Team for updating Slackware Packages.

I always imagined that Pat and the Slackware Team communicated in some fashion with the Kernel People -- they have always seemed to release the right one in the nearly daily churn of Kernel Versions

I am happy with 4.4.y on my work laptop being the only user and given that I am not running any public services ...

I may bump the Kernel on my BackUp Server ( or not ) ... it is only open on my LAN so I am not too worried about that either.

The dust from the S&M Mess will eventually settle.

Until that time, chasing 'the best kernel version', especially for Slackware Stable Versions is fruitless.

No one, and least of all Intel, AMD, etc, knows what the next disclosure will reveal about their CPUs so what we believe to be secure today is very likely not secure -- we just don't know what the undisclosed bugs are.

-- kjh

That's not necessarily true. Code that was developed over multiple changesets in a mainline or stable kernel can be backported to longterm kernels as a single commit.

On the communication - I hope that's true, I really do. I don't believe it hurts to be collaborative and suggestive, that's why we gather here. You raised a valid and very important issue, catching GKH the second time discouraging the use of the 4.4.y kernels.
I'm also fine with Slack 14.2 stable - 4.4.153 and never ran -current on x86, apart from occasions where I needed to test something, but only on ARM as I don't have a choice (armv7).

I don't believe it'll settle soon, it just started These CPUs have become almost uncontrollably complex and it looks like the specialists that designed them have difficulties to remember what's inside there anymore.
Might be these new agile principles that are hot&sexy these days and some people are trying to apply them in every field:
http://agilemanifesto.org/ - the first two are the most nocive, organizational destruction guaranteed.

"chasing 'the best kernel version'" starts to be fruitful after noticing GKH twice "urinating" on the actual.

Best advice is to trust nothing, that'll drive you to design solid systems/architectures that'll fail well/safely.

Are we not talking hardware-issues here, for which we get software solutions? I do not think one can put the finger on the 17 year old agile software-development here. That would justify anyone blaming a hammer for not getting any screws in.

Indeed, I don't know what you're talking about. I was talking about the agile principles that are promoted/imposed on scales and domains where they don't belong. That was my reply to kjhambrick, public I must admit.

Yes, I saw that. But the "on scales and domains where they don't belong"; i.e. hammering in a screw, is much more informative and precise than 'principle'. The tool is actually irrelevant if one applies this where it doesn't fit. But in conjunction with 'principle' blame of malpractice rubs off on to the tool. I found that a bit unfair.