LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 09-04-2018, 08:03 AM   #31
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 982

Rep: Reputation: 514Reputation: 514Reputation: 514Reputation: 514Reputation: 514Reputation: 514

@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.
 
Old 09-04-2018, 09:18 AM   #32
Petri Kaukasoina
Member
 
Registered: Mar 2007
Posts: 402

Rep: Reputation: 256Reputation: 256Reputation: 256
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.
 
Old 09-04-2018, 02:11 PM   #33
kjhambrick
Senior Member
 
Registered: Jul 2005
Location: Round Rock, TX
Distribution: Slackware64 14.2 + Multilib
Posts: 1,483

Original Poster
Rep: Reputation: 916Reputation: 916Reputation: 916Reputation: 916Reputation: 916Reputation: 916Reputation: 916Reputation: 916
Quote:
Originally Posted by abga View Post
@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.
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
 
Old 09-04-2018, 03:53 PM   #34
55020
Senior Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 1,307
Blog Entries: 4

Rep: Reputation: Disabled
Quote:
Originally Posted by Petri Kaukasoina View Post
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.
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.
 
Old 09-04-2018, 04:33 PM   #35
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 982

Rep: Reputation: 514Reputation: 514Reputation: 514Reputation: 514Reputation: 514Reputation: 514
Quote:
Originally Posted by kjhambrick View Post
abga --

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
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).

Quote:
Originally Posted by kjhambrick View Post
abga --
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
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.
 
Old 09-06-2018, 03:19 PM   #36
brobr
Member
 
Registered: Oct 2003
Location: uk
Distribution: Slackware
Posts: 552

Rep: Reputation: 148Reputation: 148
Quote:
Originally Posted by abga View Post
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.
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.
 
Old 09-06-2018, 03:36 PM   #37
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 982

Rep: Reputation: 514Reputation: 514Reputation: 514Reputation: 514Reputation: 514Reputation: 514
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.
 
Old 09-06-2018, 05:21 PM   #38
brobr
Member
 
Registered: Oct 2003
Location: uk
Distribution: Slackware
Posts: 552

Rep: Reputation: 148Reputation: 148
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Updated to the latest Intel microcode, but still vulnerable to one variant. john2x Slackware 21 08-09-2018 05:38 PM
Apply new Intel microcode- no microcode.dat file Naks110 Linux - Kernel 2 06-12-2018 05:20 PM
LXer: Intel's Microcode Update for Spectre Makes a Comeback in Ubuntu's Repositories LXer Syndicated Linux News 0 04-02-2018 05:33 AM
[SOLVED] Is it possible to update intel microcode using kernel-huge and grub2, without initrd? lagavulin16 Slackware 5 01-03-2018 09:27 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 11:13 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration