[SOLVED] Kernel versions (kodi unrelated)
#1
Thumbs Up 
Q: is "v4.4" of a kernel actually earlier or later than "v4.17"..?

Each time I do updates, I download newer kernels but I'm not convinced I'm actually using them. A quick list of the packages I have are:

Code:
linux-headers-4.17.2-041702
linux-headers-4.4.0-138
linux-headers-4.4.0-138-generic
linux-headers-4.4.0-139
linux-headers-4.4.0-139-generic
linux-headers-generic
linux-image-4.4.0-138-generic
linux-image-4.4.0-139-generic
linux-image-extra-4.4.0-138-generic
linux-image-extra-4.4.0-139-generic
linux-image-generic
linux-image-unsigned-4.17.2-041702-generic
linux-modules-4.17.2-041702-generic

"uname -a" gives: 4.17.2-041702-generic #201806160433 SMP

So... am I downloading updates but not actually using them?  Sorry if this sounds a bit of a dim question, but I'm not certain which version number indicates "later".

Thanks to all that can shed some light!
Reply
#2
4.17 is newer than 4.4

It installs the 4.4 for you as this is the kernel YOUR ubuntu ships and updates. the 4.17.2 was manually installed by you from e.g. ubuntu mainline.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#3
Thumbs Up 
(2018-11-15, 22:48)fritsch Wrote: the 4.17.2 was manually installed by you from e.g. ubuntu mainline.
 True - you generously compiled it for me to solve a bug that caused a lockup some time back.

So it's more a case of 4.17 is later than "4.04", rather than "4.40" newer than "4.17".  I was kinda worried the versioning numbers went that way, but thanks for confirming.

Should I add another repo in to get updates for 4.17, or am I okay with newer 4.4s coming down with an "apt upgrade"...?  Everything seems pretty stable so far, so reluctant to perform too many tweaks but just concerned my poor knowledge in this area could mean I'm still chugging away on older packages and not getting the full benefit of later stuff.

(Ubuntu 16.04.5 LTS, by the way...)
Reply
#4
There is no 4.40 kernel.  Currently 4.19.2 is the latest stable and 4.20-rc2 is the mainline.  See: https://www.kernel.org/

EDIT: the 4.17 series has been EOL'ed... what distro are you running that ships an unsupported kernel?
EDIT2: Ah, I see you edited... Ubuntu 16.04.5 LTS.  From what I googled, they should be shipping a 4.15.x series kernel?  Again, EOL'ed.  I don't know, perhaps they patch it with backports or something.
Need help programming a Streamzap remote?
Reply
#5
(2018-11-15, 23:42)graysky Wrote: There is no 4.40 kernel.  Currently 4.19.2 is the latest stable and 4.20-rc2 is the mainline.  See: https://www.kernel.org/

EDIT: the 4.17 series has been EOL'ed... what distro are you running that ships an unsupported kernel?
EDIT2: Ah, I see you edited... Ubuntu 16.04.5 LTS.  From what I googled, they should be shipping a 4.15.x series kernel?  Again, EOL'ed.  I don't know, perhaps they patch it with backports or something.
16.04 ships with 4.4 out of the box
18.04 ships 4.15 while it is EOLed by mainline ubuntu devs do mantain their own kernels which will be supported while the os release itself is supported , they will backport the necesary fixes themselves

ubuntu is not like arch (which uses vanilla kernels), they do mantain their own, slightly patched kernel trees ...
Reply
#6
(2018-11-15, 23:11)Preacher Wrote: Should I add another repo in to get updates for 4.17, or am I okay with newer 4.4s coming down with an "apt upgrade"...?  Everything seems pretty stable so far, so reluctant to perform too many tweaks but just concerned my poor knowledge in this area could mean I'm still chugging away on older packages and not getting the full benefit of later stuff.

(Ubuntu 16.04.5 LTS, by the way...) 
 For 16.04.x the maximum version you can get oficially is 4.15 from HWE stack https://wiki.ubuntu.com/Kernel/LTSEnablementStack
However if 4.17 patched by fritsch works for you - "don't fix it if it ain't broke" .
Reply
#7
(2018-11-15, 23:42)graysky Wrote: There is no 4.40 kernel. 
I was trying to illustrate that v4.17 is later than v4.4 (should be read as 4revision17), whilst mathematically 4.17 is smaller than 4.4 - i.e.: version numbers don't necessarily follow a decimal progression.
 
(2018-11-16, 01:14)asavah Wrote: However if 4.17 patched by fritsch works for you - "don't fix it if it ain't broke" .
Yup - that's pretty much the message I'm receiving. I think I just needed justification that doing bugger all was the right approach!
Reply
#8
(2018-11-16, 23:09)Preacher Wrote:  I was trying to illustrate that v4.17 is later than v4.4 (should be read as 4revision17), whilst mathematically 4.17 is smaller than 4.4 - i.e.: version numbers don't necessarily follow a decimal progression.
Of course they don't.
This is called semantic versioning, https://semver.org/
It's not a decimal number. Major.Minor.Patch
Not all software packages follow this scheme, but semver is supposed to be the standard.
Even the kernel itself does not follow semver philosophy to the full extent,
kernel 4.0 should have been 3.20, but Linus felt like bumping major was a good idea at that point of time.
Reply
#9
Knew it had a name!  Okay, going to mark thread solved as the question has been answered.

Thanks to all that helped out with invaluable knowledge!
Reply

Logout Mark Read Team Forum Stats Members Help
[SOLVED] Kernel versions (kodi unrelated)0