Code: Select all
hallvor@debian-ultrabook:~$ uname -a
Linux debian-ultrabook 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u1 (2016-09-03) x86_64 GNU/Linux
Code: Select all
hallvor@debian-ultrabook:~$ uname -a
Linux debian-ultrabook 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u1 (2016-09-03) x86_64 GNU/Linux
Point releases are normal, and released on a standard schedule. There's always bugs, minor or otherwise, being found and fixed with every point release. Why did you feel the need to publicize this one over all the others?Jimmyfd wrote:It seems there were some error in kernel 4.8 final - The kernel team have released kernel 4.8.1 generic:
http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D
Code: Select all
bester@hall:~/scripts$ uname -a
Linux hall 4.7.6-040706-generic #201609300531 SMP Fri Sep 30 09:33:47 UTC 2016 x86_64 GNU/Linux
bester69 wrote:STOP 2030 globalists demons, keep the fight for humanity freedom against NWO...
Actually they sort of were for a bit:stevepusser wrote:Point releases are normal, and released on a standard schedule. There's always bugs, minor or otherwise, being found and fixed with every point release. Why did you feel the need to publicize this one over all the others?Jimmyfd wrote:It seems there were some error in kernel 4.8 final - The kernel team have released kernel 4.8.1 generic:
http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D
BTW--the Ubuntu kernel team is not the Debian kernel team, nor the main upstream kernel developers, though nothing keeps them from sharing personnel.
https://bits.debian.org/2014/07/kernel- ... essie.htmlWill Linux 3.16 get long term support from upstream?
The Linux 3.16-stable branch will not be maintained as a longterm branch at kernel.org. However, the Ubuntu kernel team will continue to maintain that branch, following the same rules for acceptance and review, until around April 2016. Ben Hutchings is planning to continue maintenance from then until the end of regular support for 'jessie'.
bester69 wrote:STOP 2030 globalists demons, keep the fight for humanity freedom against NWO...
Bester69, priorities differ. A kernel is much more than performance and driver compatibility. Many uses require extremely well tested kernels.bester69 wrote:The question is, what gain do you get by using 3.16 kernel insteed of newers or latest kernel?
,At least it has to be with performance or drivers compatibilities i dont understand your point!.
Old kernels must be for old computers,
for regular users??,for critical factory envirovments purposes, or financials computers or maybe even just productions servers companies where there is too much in risk,i understand a driver may failt causing a drop down so you would go for the most tested kernel, but for desktop computer i dont see the point...., ive never seen nothing wrong with any kernel i tried in my computer.edbarx wrote:Bester69, priorities differ. A kernel is much more than performance and driver compatibility. Many uses require extremely well tested kernels.bester69 wrote:The question is, what gain do you get by using 3.16 kernel insteed of newers or latest kernel?
,At least it has to be with performance or drivers compatibilities i dont understand your point!.
Old kernels must be for old computers,
bester69 wrote:STOP 2030 globalists demons, keep the fight for humanity freedom against NWO...
Other reasons are clearly explained above if you try to read it once again.Old wood best to burn,
old wine to drink,
old friends to trust,
old kernel to enjoy experience and maturity.
and old authors to read. -- Athenaeus
Nili wrote:Other reasons are clearly explained above if you try to read it once again.Old wood best to burn,
old wine to drink,
old friends to trust,
old kernel to enjoy experience and maturity.
and old authors to read. -- Athenaeus
bester69 wrote:STOP 2030 globalists demons, keep the fight for humanity freedom against NWO...
I get the same results as you, different kernels behave differently. My rule of thumb is the highest LTS kernel with the best EOL date available (in repos) for my 3 installed distros, without insane backporting, etc. Newer, stable and well tested kernels have better bug fixes and hardware compatibility. The highest version isn't always the best, anything above long-term is beta to me.bester69 wrote:I think differents versions's kernel behave differente in each computer, or, at least i felt that way,
in my case, i recentlly tried 4.7 bpo debian's kernel and 4.8 ubuntu's kernel, and i fell they performance worse than ubuntu's 4.7.6,
this last kernel --> 4.7.6 ubuntu's its working great in my computer, i fell it quicker and smoother, i tried two times others kernel (4.7bpo and 4. to see if it was placebo, and i feel they both dont performance as well as 4.7.6 ubuntu's in my laptop, so its kind of extrange, my final conclusion is that every kernel behave different in the same computer.
Now, im pretty happy with kernel's ubuntu 4.7.6
ill try 4.9 when it comes to see if it give me some gain, and i can keep moving onCode: Select all
bester@hall:~/scripts$ uname -a Linux hall 4.7.6-040706-generic #201609300531 SMP Fri Sep 30 09:33:47 UTC 2016 x86_64 GNU/Linux
Virtualbox linux 3.16 kernel headers support.bester69 wrote:The question is, what gain do you get by using 3.16 kernel insteed of newers or latest kernel?
,At least it has to be with performance or drivers compatibilities i dont understand your point!.
Old kernels must be for old computers,
My experience with Virtualbox, is that is better to install from official page, that package has kernel embedded headers or so, so you dont't need dkms packages, I usually update virtualbox with no problem for any kernel. I got into troubles when i try virtualbox from repositories..Innovate wrote:Virtualbox linux 3.16 kernel headers support.bester69 wrote:The question is, what gain do you get by using 3.16 kernel insteed of newers or latest kernel?
,At least it has to be with performance or drivers compatibilities i dont understand your point!.
Old kernels must be for old computers,
You can try even you built 4.7,4.8,4.9++ kernel & headers it won't work with virtualbox.
Even you run /etc/init.d/vboxdrv setup it's not gonna work.
bester69 wrote:STOP 2030 globalists demons, keep the fight for humanity freedom against NWO...
Code: Select all
mycojones@hall:~$ uname -a
Linux hall 4.8.2-040802-generic #201610161339 SMP Sun Oct 16 17:41:46 UTC 2016 x86_64 GNU/Linux
bester69 wrote:STOP 2030 globalists demons, keep the fight for humanity freedom against NWO...
Code: Select all
$ uname -a
OpenBSD OpenBSD.lan 6.0 GENERIC.MP#0 amd64
Code: Select all
OpenBSD 6.0-current (GENERIC.MP) #0: Sun Oct 16 18:57:06 MDT 2016
Code: Select all
Linux kernel 3.16.0-4-686-pae #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) i686 GNU/Linux
First of all, 4.8.1. was released immediately thereafter effectively removing "buggy crap". It is now at 4.8.3 and likely much more stable.Innovate wrote:Oh my, I'm glad I read this news about 4.8
http://www.theregister.co.uk/2016/10/05 ... _linux_48/
I'll just skipped to 4.9 or 5.0 when it comes or stay back on 3.16, 4.7
Second, the next kernel after 4.9 is 4.10.https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.8.1 wrote:commit 0b09f2d43201472327b80f9978cd768b46353a34
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Mon Oct 3 21:03:48 2016 -0700
Using BUG_ON() as an assert() is _never_ acceptable
commit 21f54ddae449f4bdd9f1498124901d67202243d9 upstream.
That just generally kills the machine, and makes debugging only much
harder, since the traces may long be gone.
Debugging by assert() is a disease. Don't do it. If you can continue,
you're much better off doing so with a live machine where you have a
much higher chance that the report actually makes it to the system logs,
rather than result in a machine that is just completely dead.
The only valid situation for BUG_ON() is when continuing is not an
option, because there is massive corruption. But if you are just
verifying that something is true, you warn about your broken assumptions
(preferably just once), and limp on.
Fixes: 22f2ac51b6d6 ("mm: workingset: fix crash in shadow node shrinker caused by replace_page_cache_page()")
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Miklos Szeredi <miklos@szeredi.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>