Diversity Strike Linux 5.0 Kernel Performance Sucks

Jackson Cruz
Jackson Cruz

When looking at the geometric mean across the dozens of tests carried out, Linux 5.0 Git is clearly slower than its predecessors. With this box going back to Linux 4.12, keep in mind between Linux 4.14 and 4.15 is when Spectre/Meltdown came to light and began introducing in-kernel mitigations like PTI and Retpolines. But Linux 5.0 Git is clearly coming in as slower, which has been a similar outcome on other systems tested.

For a wide look at the kernel performance I have been running dozens of different benchmarks on each system, with some of the boxes going as far back as Linux 4.12 or the better part of two years ago. I've also taken the geometric mean of all tests successfully run on all tested kernel combinations and that's where it's clear Linux 5.0 is running slower than previous kernels...

I'll be running more tests through the weekend on more hardware and at least now having a few tests like Apache (with load via Siege), Sockperf, PostgreSQL, and others where they appear to be measurably slower on the new kernel for bisecting the issue to gain more insight on the Linux 5.0 performance. But overall there doesn't appear to be any very major, focused regression like we've seen in some of the past kernel series as a result of introducing new Spectre/Meltdown mitigations and other changes. Though with many of these apparent slowdowns being quite subtle could explain why the slower Linux 5.0 kernel performance has yet to be rectified unless it was another case like Linux 4.20 with STIBP where its original performance drop was sort of intentional albeit not properly communicated. Stay tuned for more tests.

phoronix.com/scan.php?page=article&item=linux-50-sliding&num=6

tldr of this extensive benchmark is that linux 5.0 is performing worse in almost every metric. it's not substantial, but it's measurable.
<linus is letting garbage in now.
instead of calling people idiot's and telling them to fix their shit he's just letting it slide. linux will have a slow and painful death.

Other urls found in this thread:

reddit.com/r/Amd/comments/7o2i91/technical_analysis_of_spectre_meltdown/
blog.fefe.de/?ts=a4ac7405
lkml.org/lkml/2012/12/23/75
lkml.org/lkml/2012/12/24/125
github.com/torvalds/linux/blob/master/drivers/media/v4l2-core/v4l2-ioctl.c
en.wikipedia.org/wiki/Not_a_typewriter
phoronix.com/scan.php?page=article&item=linux50-spectre-meltdown&num=1
googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
lkml.org/lkml/2018/1/3/797
connect.linaro.org.s3.amazonaws.com/sfo17/Presentations/SFO17-417-SEL4.pdf
genode.org/
opensource.com/article/19/2/cla-problems
esr.ibiblio.org/?p=8139
zdnet.com/article/linux-kernel-gets-another-option-to-disable-spectre-mitigations/
github.com/speed47/spectre-meltdown-checker
kernel.org/doc/html/v4.20/admin-guide/kernel-parameters.html
phoronix.com/scan.php?page=article&item=linux50-spectre-meltdown&num=2
kernel.org/doc/html/latest/admin-guide/index.html
kernel.org/doc/html/latest/search.html?q=retpoline
kernel.org/doc/html/latest/admin-guide/kernel-parameters.html
kernel.org/doc/html/latest/admin-guide/l1tf.html

Aaron Nguyen
Aaron Nguyen

Fug

Thomas Gonzalez
Thomas Gonzalez

How long until they break userspace?

Dominic Jackson
Dominic Jackson

kek

Kayden Ward
Kayden Ward

Linux 5 is slower thanks to new spectre/meltdown patches. That's it.
If you truly believe the only reason Linux is a quality kernel is that Linus said bad words on the mailing list you're a retard. If you think there are new "le sjw nigger tranny dindu nufin" devs you're a super retard. Absolutely nothing has changed in the dev cycle and there are no new maintainers.

Luke Lopez
Luke Lopez

WHAT HAPPENED TO THE PERFORMANCE

Hunter Williams
Hunter Williams

If it's spectre/meltdown then AMD64 CPUs should be hit less because they mitigated some issues in hardware (which makes them slower in the first place tho).

Daniel Gomez
Daniel Gomez

Everyone in this thread is blaclisted and blocked from commenting or contributing on Linux. Except for this good goy

Nicholas Ortiz
Nicholas Ortiz

they mitigated in hardware
That's not how you write "they didn't have this fault".

Andrew Cruz
Andrew Cruz

Linux 5 is slower thanks to new spectre/meltdown patches. That's it.
THIS
Get fucked incels

Isaac Thompson
Isaac Thompson

Get fucked incels
/reddit/

Asher Price
Asher Price

AMD does have some spectre/meltdown problems, they don't have some others and some they do have but they're harder to exploit.

The problem doesn't just magically disappear when using their chips.
Here's some reddit thread:
reddit.com/r/Amd/comments/7o2i91/technical_analysis_of_spectre_meltdown/
And here's fefe:
blog.fefe.de/?ts=a4ac7405

Jonathan Taylor
Jonathan Taylor

Linux is just a kernel, there is no userspace in it.
This.
AMD processors are partially affected too.

Nathan Barnes
Nathan Barnes

That still doesn't make not having a particular flaw into a mitigation for being flawed. Retardation with speculative execution is not some fact of life that you have to mitigate.

Sebastian Reed
Sebastian Reed

This. /thread.

This is a variant of other weird criticisms of non-reality:
<Illegals get free university!
<The governments gives poor people free houses
<Linux excepts any commit from ((((diversity)))

Okay man, but no one knows your a nigga on the internet when you submit your pull request..

Brayden Phillips
Brayden Phillips

Linux is just a kernel, there is no userspace in it.
Lol you're retarded. Of course userspace isn't in the kernel. When you accidentally drop something fragile and it breaks, do you say, "I couldn't have broken that, it wasn't a part of me."

If system calls stop working like they used to, userspace stops working like it used to. User applications and the kernel interface. That's the whole point of a kernel; it controls what all otoher programs can and cannot do. It's the reason another old school name for kernel is "supervisor," and by extension why a program that manages multiple kernels is a "hypervisor."

Here's part of Linus' own take on breaking userspace:
lkml.org/lkml/2012/12/23/75
On Sun, Dec 23, 2012 at 6:08 AM, Mauro Carvalho Chehab
<[email protected]> wrote:
>
> Are you saying that pulseaudio is entering on some weird loop if the
> returned value is not -EINVAL? That seems a bug at pulseaudio.

Mauro, SHUT THE FUCK UP!

It's a bug alright - in the kernel. How long have you been a
maintainer? And you *still* haven't learnt the first rule of kernel
maintenance?

If a change results in user programs breaking, it's a bug in the
kernel. We never EVER blame the user programs. How hard can this be to
understand?

To make matters worse, commit f0ed2ce840b3 is clearly total and utter
CRAP even if it didn't break applications. ENOENT is not a valid error
return from an ioctl. Never has been, never will be. ENOENT means "No
such file and directory", and is for path operations. ioctl's are done
on files that have already been opened, there's no way in hell that
ENOENT would ever be valid.

> So, on a first glance, this doesn't sound like a regression,
> but, instead, it looks tha pulseaudio/tumbleweed has some serious
> bugs and/or regressions.

Shut up, Mauro. And I don't _ever_ want to hear that kind of obvious
garbage and idiocy from a kernel maintainer again. Seriously.

I'd wait for Rafael's patch to go through you, but I have another
error report in my mailbox of all KDE media applications being broken
by v3.8-rc1, and I bet it's the same kernel bug. And you've shown
yourself to not be competent in this issue, so I'll apply it directly
and immediately myself.

WE DO NOT BREAK USERSPACE!

Seriously. How hard is this rule to understand? We particularly don't
break user space with TOTAL CRAP. I'm angry, because your whole email
was so _horribly_ wrong, and the patch that broke things was so
obviously crap. The whole patch is incredibly broken shit. It adds an
insane error code (ENOENT), and then because it's so insane, it adds a
few places to fix it up ("ret == -ENOENT ? -EINVAL : ret").

The fact that you then try to make *excuses* for breaking user space,
and blaming some external program that *used* to work, is just
shameful. It's not how we work.

Fix your f*cking "compliance tool", because it is obviously broken.
And fix your approach to kernel programming.

Linus

It does my heart glad to see him dicking down redhat. Too bad those days are over.

If you truly believe the only reason Linux is a quality kernel is that Linus said bad words on the mailing list you're a retard.
Not the user you're replying to, and while it may not have been the only reason, it definitely was one of the reasons. It certainly seemed to be effective. I think the above post from the lkml is evidence of that.

Adam Gomez
Adam Gomez

tfw linus btfoed the redhat clowns so bad that they dedicated their lives to subverting and destroying linux

Carter Jackson
Carter Jackson

This is more of the Bloatware is Proprietary phenomenon. You must accept whatever "fixes" are forced on you even if they suck. If you fork the code, you need to keep fixing bugs yourself. When code is 15 million lines, porting the bug fixes is as hard as fixing them all yourself. This is why nobody made a version of Linux that handles out of memory correctly but microkernels have all kinds of forks and reimplementations that take different directions.

That's actually a fundamental problem with the UNIX "philosophy" of files. UNIX presents the illusion that every device is a PDP-11 tape drive or typewriter, depending on whether you can seek. Instead of having APIs that reflect the behavior of the actual device, UNIX weenies shove all functionality that doesn't look like a tape drive into ioctl so they can have a "simple and elegant" and "small and consistent" interface with only hundreds of system calls instead of thousands. All of these ioctls are separate functions on other operating systems.

lkml.org/lkml/2012/12/24/125
Because there are other error codes that can be returned by other
drivers when this specific ioctl (VIDIOC_QUERYCTRL) is called.

Let me take one step back and explain what this patch were
trying to do.

What happens is that the V4L2 API is very complex (~80 ioctls).
In practice, that means that two drivers implementing the API
might behave a little different than the others, with causes
troubles on userspace. We're working to fix it, by testing all
of them using userspace testing tools.

github.com/torvalds/linux/blob/master/drivers/media/v4l2-core/v4l2-ioctl.c
An example of how much ioctl sucks is that functions like "VIDIOC_ENUM_FMT" and "VIDIOC_G_JPEGCOMP" are treated as ioctls, which were originally for controlling serial typewriter-like terminals. "Not a typewriter" originally meant the ioctl was invalid. On a real OS, the purpose of a driver is to translate abstract operations into actual commands and data for the device. Instead of pretending video devices are a weird kind of typewriter, the OS would have a class of drivers for all kinds of video devices.

en.wikipedia.org/wiki/Not_a_typewriter
This error originated in early UNIX. In Version 6 UNIX and earlier, I/O control was limited to serial-connected terminal devices, typically a teletype (abbreviated TTY), through the gtty and stty system calls.[1] If an attempt was made to use these calls on a non-terminal device, the error generated was ENOTTY. When the stty/gtty system calls were replaced with the more general ioctl (I/O control) call, the ENOTTY error code was retained.

Subject: Small And Consistent Interface, Bah!


So I'm doing this tcp/ip implementation and my advisor and I
agree that we should be binary compatible with bsd syscalls
[this is kind of a traditional move around here otherwise
people tend to ignore your work because recompiling is too
difficult]. "How are you going to handle ioctl's?" he asks.
"Hmm," I say, "I mapped out how I'd handle every socket
syscall except the ioctl's but how hard could that be?" Heh
heh heh.

Not only do you have to handle ioctl's which get called
using the ioctl syscall. You also have to handle the
ioctl's that get called via the fcntl syscall and the
setsockopt syscall. Oh yeah, and then there are some fcntl
ioctl's that can be called by the dupx syscalls. [Let me
guess, they named these syscalls dup and dup2 because they
are (a) completely redundant and (b) you are one if you use
them.]

Did I forget anything?

Colton Davis
Colton Davis

Nobody asked for your opinion. Fuck off.

Caleb Ross
Caleb Ross

<Of course userspace isn't in the kernel.
It's a bug alright - in the kernel.
If a change results in user programs breaking, it's a bug in the
kernel.
WE DO NOT BREAK USERSPACE!
As far as I understand this, Linus means, that if something doesn't work, it's because they fucked up the kernel.
So they can't break userspace directly. Userspace can still work fine, with other kernel, like the Hurd, or a kernel of *BSD. So again, they can't break the userspace directly - thats what I meant.

Mauro, SHUT THE FUCK UP!
Shut up, Mauro. And I don't _ever_ want to hear that kind of obvious
garbage and idiocy from a kernel maintainer again. Seriously.
What a merit, congratulations. Even if someone is wrong, he shouldn't throw shit at them like a monkey. You could be a great programmer and just make one mistake that Torvalds don't like and he will treat you like an animal. That's just mobbing like corporations do. No wonder they CoCked him.

This is more of the Bloatware is Proprietary phenomenon.
Yeah, disgusting monolithic desing can be a problem too.

Colton Lopez
Colton Lopez

lol mauro on suicide watch

this is what made linux great
this is what linus is not doing anymore.

Are there new patches in 5.0 that can be blamed that are not in 4.20? Does this explain why 5.0 is clearly slower than 4.20?
<But overall there doesn't appear to be any very major, focused regression like we've seen in some of the past kernel series as a result of introducing new Spectre/Meltdown mitigations and other changes.

There's a benchmark here that show's the clear performance to be gained from disabled all these patches, but it doesn't compare 5.0 to 4.20 or anything prior.
phoronix.com/scan.php?page=article&item=linux50-spectre-meltdown&num=1

Justin Roberts
Justin Roberts

What a merit, congratulations. Even if someone is wrong, he shouldn't throw shit at them like a monkey. You could be a great programmer and just make one mistake that Torvalds don't like and he will treat you like an animal. That's just mobbing like corporations do. No wonder they CoCked him.
<you can't call out someone who not only fucks up but blames someone else for their fuckup
That's just mobbing like corporations do.
These "corporations" try to sneak in all kinds of bullshit into the kernel all of the time. That's why they probably dug up some dirt on linus and are blackmailing him with it now to get this shit in. Remember the original spectre patch from intel intentionally fucked AMD's processors too to make it look like it wasn't just Intel's fuckup. There's an lkml from for that if I can find it, I can only find linus destroying intel for other reasons at the moment.

Chase Martin
Chase Martin

There's an lkml from for that if I can find it, I can only find linus destroying intel for other reasons at the moment.
I think this is it, but I thought there was one that was more specific that directly mentions there should be a switch to not apply the patch to amd processors.


On Wed, Jan 3, 2018 at 3:09 PM, Andi Kleen <[email protected]> wrote:
> This is a fix for Variant 2 in
> googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
>
> Any speculative indirect calls in the kernel can be tricked
> to execute any kernel code, which may allow side channel
> attacks that can leak arbitrary kernel data.

Why is this all done without any configuration options?

A *competent* CPU engineer would fix this by making sure speculation
doesn't happen across protection domains. Maybe even a L1 I$ that is
keyed by CPL.

I think somebody inside of Intel needs to really take a long hard look
at their CPU's, and actually admit that they have issues instead of
writing PR blurbs that say that everything works as designed.

.. and that really means that all these mitigation patches should be
written with "not all CPU's are crap" in mind.

Or is Intel basically saying "we are committed to selling you shit
forever and ever, and never fixing anything"?

Because if that's the case, maybe we should start looking towards the
ARM64 people more.

Please talk to management. Because I really see exactly two possibibilities:

- Intel never intends to fix anything

OR

- these workarounds should have a way to disable them.

Which of the two is it?

Linus

lkml.org/lkml/2018/1/3/797

Zachary Jones
Zachary Jones

GNU/Hurd WHEN?!

Dominic Reyes
Dominic Reyes

what if you disable the shitty patches? its all useless crap if you arent a vps provider

Joshua Williams
Joshua Williams

Never.
Hurd is dead.
Genode is the future
connect.linaro.org.s3.amazonaws.com/sfo17/Presentations/SFO17-417-SEL4.pdf
genode.org/

Isaiah Kelly
Isaiah Kelly

When development effort is invested into drivers. It should be easier to do because drivers are supposed to be distinct userspace binaries. It's too bad that the investment effort is so small.

Alexander Allen
Alexander Allen

Nobody asked for yours, either. Go do the same.

Wyatt Green
Wyatt Green

It's 2019, but not yet we see GNU/Hurd OS. GUN always insists that it's "Gnu/Linux" not "Linux" but actually they can't develop any OSes. They are just third-party programmers. THE REAL OS PROGRAMMERS are Linux developers.

Colton Perez
Colton Perez

GPL is revocable.

Luis Carter
Luis Carter

When is has more than 12 part-time developers.
Ba dum tssshhh
When debugging driver servers becomes as easy as debugging monolithic kernel code.
Ba dum tssshhh

Hurd hasn't been released because A) it's garbage, and B) no one supports compiling to it, not because it is vaporware.

Liam Stewart
Liam Stewart

opensource.com/article/19/2/cla-problems
License revocation: Some CLA advocates warn of the prospect that a contributor may someday attempt to revoke a past license grant. To the extent that the concern is about largely judgment-proof individual contributors with no corporate affiliation, it is not clear why an Apache-style CLA provides more meaningful protection against this outcome compared to the use of an open source license. And, as with so many of the legal risks raised in discussions of open source legal policy, this appears to be a phantom risk. I have heard of only a few purported attempts at license revocation over the years, all of which were resolved quickly when the contributor backed down in the face of community pressure.

Notice how they hand-wave it.
"Guy backed down, don't look behind this curtain"
You can revoke. Their only power against you is getting you fired/blackballed. If you do not give a shit about their "industry" you C A N fuck them completely. You have revoke and sue, and you really want to do so in a bloc with like minded, once you get the ball rolling, it's the doom of the project.

Camden Foster
Camden Foster

Is there a kernel option for it? Like, I can't actually flash my bootloader without booting with iomem=relaxed so maybe there's something similar for these? Unfortunately speculative execution is actually a performance necessity sometimes.

I do not want that legal precedent. Ever.

esr.ibiblio.org/?p=8139

Parker Hall
Parker Hall

It doesn't matter if you don't want it, has been US law since the beginning of the US.

Gratuitous licenses have always been revocable at will.

Kayden Harris
Kayden Harris

Is there a kernel option for it
everything is a configuration option at compile time, and it looks like most can be disabled at boot even if it's enabled to compile time

For example, since Linux Kernel 4.15, administrators can disable the kernel's built-in mitigations for the Spectre v2 vulnerability (CVE-2017-5715) with the "nospectre_v2" kernel command line parameter.

Since Linux Kernel 4.17, administrators can disable all mitigations for Spectre v4 (CVE-2018-3639) with the "nospec_store_bypass_disable" command line parameter.

Similarly, a way to disable mitigations for Spectre v1 (CVE-2017-5753) has been added in the Linux Kernel 4.19, with the addition of the "nospectre_v1" parameter.

These three parameters were added despite the kernel already featuring the "spectre_v2" and "spec_store_bypass_disable" options for months, parameters that let system administrators control the complexity level of the Spectre-class mitigations, options which also included an "off" mode.
zdnet.com/article/linux-kernel-gets-another-option-to-disable-spectre-mitigations/

the fact that I had to find this shit on a zdnet article and couldn't find any official documentation is a joke. this shit is all over the place.

reddit of all places has a decent one liner to pass to the kernel at boot

noibrs noibpb spectre_v2=off spec_store_bypass_disable=prctl spec_store_bypass_disable=off nospectre_v1

this seems to be the go to to check that these patches have been applied and enabled
github.com/speed47/spectre-meltdown-checker
you could use this in reverse to make sure this is disabled.

if there's an actual official documentation page with all these options someone please link it

Dylan Richardson
Dylan Richardson

kernel.org/doc/html/v4.20/admin-guide/kernel-parameters.html

it's listed here, atleast the command line options, but there needs to be a dedicated page with "here are the security options that will cut your performance in half and here is the config option in the kernel config and the boot parameter to disable it at boot"

Isaiah Kelly
Isaiah Kelly

This fucker just never gives up; he just constantly posts usenet and mailing list quotes from three decades ago. What a sad, pathetic autist.

William Hernandez
William Hernandez

I like him

Michael Peterson
Michael Peterson

He's better than 99% of the posters here

Oliver Thompson
Oliver Thompson

Nobody asked for your asskissing either. Fuck off, brown-nose nigger.

Jackson Hall
Jackson Hall

tfw still using long term release kernel
tfw hyper autists on this very board used to screetch all the time at me for using gentoo without the latest kernel
ADHD Niggers get told

Attached: auschlitz.jpg (34.52 KB, 720x693)

Henry Gray
Henry Gray

t. unix weenie

Ethan Perry
Ethan Perry

no u

Liam Martin
Liam Martin

Still better than the autist whose entire purpose in life is to complain about him. You are really obvious, mate.

Gavin Nguyen
Gavin Nguyen

Oh boy, can't wait for my 11 year old computer to be even fucking slower unless I just go back to Windows XP again. And it will still be more usable than Windows 10 and the BSDs. With this level of competition, I wonder how nothing good is ever made.

You can't break what has always been broken.

And you keep complaining about him. Thanks for that, I'm going to screenshot all of his posts and they will become my wallpaper when I stop being lazy. It will be especially hilarious on my Linux PC, if I can ever get it to work, because Linux is objectively shit and I only use it because the first version of Windows 7 is slightly outdated and also breaks occasionally. He will never give up, because of balls of steel, or severe autism that I can relate to, or both.

Luke Sanders
Luke Sanders

based

kys

wrong

Thx for making a compilation of his posts <3

based

Noah Gray
Noah Gray

based

Owen Moore
Owen Moore

in half
I thought the impact of those mitigations was mostly in specific workloads and not largely typical desktop tasks. Benchmarks are welcome though.

Eli Jones
Eli Jones

Linux 5 is slower thanks to new spectre/meltdown patches. That's it.
Idk if that's true but it might definitely be it.

Just try updating Windows Vista, Windows 7, 8.1, Server 2008R2 or Server 2012R2 with the spectre hotfix, and if you're running it on a toaster or a vm, watch as the system turns noticeably more sluggish and unresponsive after reboot.

Linux is objectively shit and I only use it because the first version of Windows 7 is slightly outdated and also breaks occasionally.
What do you mean by "first version" of Windows 7? Are you talking about Pre-SP1 Windows 7?

Liam Flores
Liam Flores

GPL is revocable, and Unix-Hater is correct in his opinions.

Jeremiah Gonzalez
Jeremiah Gonzalez


wrong

Nope, even RedHat half-heartedly admits it:

opensource.com/article/19/2/cla-problems

License revocation: Some CLA advocates warn of the prospect that a contributor may someday attempt to revoke a past license grant. To the extent that the concern is about largely judgment-proof individual contributors with no corporate affiliation, it is not clear why an Apache-style CLA provides more meaningful protection against this outcome compared to the use of an open source license. And, as with so many of the legal risks raised in discussions of open source legal policy, this appears to be a phantom risk. I have heard of only a few purported attempts at license revocation over the years, all of which were resolved quickly when the contributor backed down in the face of community pressure.

Notice how they hand-wave it.

"Guy backed down, don't look behind this curtain"

You can revoke. Their only power against you is getting you fired/blackballed. If you do not give a shit about their "industry" you C A N fuck them completely. You have revoke and sue, and you really want to do so in a bloc with like minded, once you get the ball rolling, it's the doom of the project.

Daniel Moore
Daniel Moore

Why do you shill?
The text says the opposite of what you proclaim.
Why do you shill and does your family know about it?

Levi Hill
Levi Hill

KYS, Mikee.

Dominic Bailey
Dominic Bailey

The text says the opposite of what you proclaim.

Nope, it's tacit approval of my stance. That is why they then say "oh but we've delt with this extra-legally, no worries".

The fact is other lawyers do caution that without a copyright transfer, the copyright owner can revoke the license at will.

Read it again. That is: even RedHat agrees that this is a legal possibility, but in it's press release hand waves it away with some "we'll we'll just get the guy fired" bullshit. Yes you lay people cannot separate the legal language from the bullshit language, but we lawyers can.

opensource.com/article/19/2/cla-problems

License revocation: Some CLA advocates warn of the prospect that a contributor may someday attempt to revoke a past license grant. To the extent that the concern is about largely judgment-proof individual contributors with no corporate affiliation, it is not clear why an Apache-style CLA provides more meaningful protection against this outcome compared to the use of an open source license. And, as with so many of the legal risks raised in discussions of open source legal policy, this appears to be a phantom risk. I have heard of only a few purported attempts at license revocation over the years, all of which were resolved quickly when the contributor backed down in the face of community pressure.

Let's go through it line by line

License revocation: Some CLA advocates warn of the prospect that a contributor may someday attempt to revoke a past license grant.
<Some lawyers point out that a gratis license is revocable at the will of the grantor and you're a moron if you don't get a copyright transfer like the FSF has always demanded

To the extent that the concern is about largely judgment-proof individual contributors with no corporate affiliation,
<Redhat does not refute this concern, the people that are threatening to revoke currently do not work in the field and have no money (that's what judgement proof means: even if someone sued you they'd get fuck-all)

And, as with so many of the legal risks raised in discussions of open source legal policy, this appears to be a phantom risk.
<No one can sue us for legal malpractice if we put the word "appears" in here. We are saying that no one has revoked yet in the opensource world and then sued violators, if someone does... well it isn't a "phantom" risk anymore: it's a clear-and-present danger at that point, but we did say "appears"...

I have heard of only a few purported attempts at license revocation over the years,

all of which were resolved quickly when the contributor backed down in the face of community pressure.
<The community convinced the person not to sue anyone, largely by not having any money, and the lawyer advising the person wasn't going to do it for free, the lawyer also pointed out that because the plaintif didn't register his copyright /before/ people violated his recision, statutory damages and attorney's fees would be unavailable, only damages. The community was pennyless at that time and wasn't using the code in any meaningfully profitable way so this would be difficult case to make any money off of it
<Now we will just black ball anyone who revokes the license
<we would like to say they cannot do it, and if they could not do it we would say it
<but we can't, because they can, legally
<all we can do is try to fuck them for it

Brandon Bailey
Brandon Bailey

KYS, Mikee.

Why? I'm right you know. And more and more people are realizing that.

Camden Cooper
Camden Cooper

more (((backdoors)))
trannies/sjw shit is how deep state gets inside

Noah Russell
Noah Russell

And you keep complaining about him. Thanks for that, I'm going to screenshot all of his posts and they will become my wallpaper when I stop being lazy. It will be especially hilarious on my Linux PC, if I can ever get it to work, because Linux is objectively shit and I only use it because the first version of Windows 7 is slightly outdated and also breaks occasionally. He will never give up, because of balls of steel, or severe autism that I can relate to, or both.
this compilation should be made the background of Zig Forums

I thought the impact of those mitigations was mostly in specific workloads and not largely typical desktop tasks. Benchmarks are welcome though.
this is propaganda by intel. there are measurable performance drops across the board. there's a wide variety of benchmarks available for these patches already.
phoronix.com/scan.php?page=article&item=linux50-spectre-meltdown&num=2
20% I/O performance drop
17% compile performance drop
23% socket performance drop
30-78% network performance drop
9% across the board anything using glibc performance drop
4% gimp performance drop
22% memcached performance drop
22% nginx performance drop
19% apache performance drop
<Of 57 benchmarks tested on these three systems with the Linux 5.0 kernel, the Core i9 7980XE performance was down by about 13% based upon the geometric mean of all the test results. The Intel Core i7 8086K performance was down by 17% with these out-of-the-box protections for Spectre and Meltdown. The AMD Ryzen 7 2700X performance with its default Spectre mitigations was lower by just 3%.
(((specific workloads)))
anything that needs to make a kernel syscall ( which is everything, reading a file, memory alloc, etc ) get's fucked.

this benchmark did reveal additional kernel configuration options to disable all this shit. this is what he used to run the "non mitigated" benchmark

pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier

linus is never going to create a global off switch for all this because everyone wants the goyim to get used to shit performance, instead your going to have to crawl through the kernel config and documentation and piece together 50 different off switches yourself.

Carson Gutierrez
Carson Gutierrez

older processors which Zig Forums is prone to use in an effort to escape the botnet are prone to get fucked much harder according to the benchmarks.

He didn't test core2-duo, i'd love to see how hard that get's fucked.

i would bet anything these vulnerabilities were included intentionally as a planned obsolesce thing from intel and glowniggers in general to be used once the majority of exploits for the previous version of the botnet were used up, discovered and mitigated, so they could force everyone to upgrade to botnet 2.0 with a whole new set of fresh 0-days.

John Flores
John Flores

You faggots don't compile your own kernel? It's fucking easy to configure if you know what hardware you have and when you throw all the shit out you don't need it compiles fast too and you can optimize a little. There are a bunch of switches for spectre/meltdown and also other stuff you can disable that doesn't apply to your computer and will bring in a bit of performance. It's all well laid out and documented in the kernel configuration menu.

I swear to god, Zig Forums is full of zoomer larpers these days.

Camden Young
Camden Young

abloo-bloo I'm literally helpless if I can't get the kernel configuration switches off google and reddit. lmao

Zachary Fisher
Zachary Fisher

literally juts installed 5.0

Landon Lewis
Landon Lewis

I recently learned KASLR does literally nothing and is still exploitable. I also learned that kernel devs are retards that won't implement security featues. For example grsecurity's specter and meltdown mitigations come at no cost to performance. But the linux kernel's mitigations have huge performance impacts. (((Why))) is that?

Brody Mitchell
Brody Mitchell

There are a bunch of switches for spectre/meltdown and also other stuff you can disable that doesn't apply to your computer and will bring in a bit of performance.
that would be great if that was, but it isn't.
kernel.org/doc/html/latest/admin-guide/index.html
tell me where all the spectre and meltdown patch documentation is and how I can easily locate it in the kernel config

tell me exactly where in the kernel config spectre mitigations are without resorting to a search engine.

Symbol: RETPOLINE [=y]
Type : bool
Prompt: Avoid speculative indirect branches in kernel
where does it say this is going to result in a 30% performance penalty? Where does it even suggest if this should be enabled or disabled? Where is the documentation?
<Avoid speculative indirect branches in kernel
this is the only documentation available
kernel.org/doc/html/latest/search.html?q=retpoline
ONE RESULT
kernel.org/doc/html/latest/admin-guide/kernel-parameters.html
and this only references retpoline in relation to the spectre_v2= boot configuration flag, apparently there's no way to actually turn this shit off in the kernel config, you have to do it at boot, but there's still no explanation of retpoline.
...
spec_store_bypass_disable=
tell me big brain where is this configuration option in the kernel? where is it documented aside from a paragraph on the kernel parameters page?

this shit is a mess and you know it.
the only way to properly configure the kernel is to rely on a third party configuration guide and search blindly all over the place to figure out exactly what the fuck any of this does.

Logan Ward
Logan Ward

to be fair there is a slightly more elaborate two sentence explanation on the config option
Compile kernel with the retpoline compiler options to guard against kernel-to-user data leaks by avoiding speculative indirect branches. Requires a compiler with -mindirect-branch=thunkextern support for full protection. The kernel may run slower.

how much slower?
there's not even a suggestion "enable if unsure" etc that's common on some of these options. As far as I can tell, this two sentence explanation of retpoline is the extent of linux kernel documentation regarding retpoline.

Jason Baker
Jason Baker

not only that, it isn't listed under security, it's listed under processor type and features, despite not having anything to do with enabling any actual processor features for specific types.

Logan Price
Logan Price

There was a nice little blurb here
kernel.org/doc/html/latest/admin-guide/l1tf.html
The Linux kernel provides a sysfs interface to enumerate the current L1TF status of the system: whether the system is vulnerable, and which mitigations are active. The relevant sysfs file is:
/sys/devices/system/cpu/vulnerabilities/l1tf

turns out there's also:
l1tf meltdown spec_store_bypass spectre_v1 spectre_v2
cat on any of these in >/sys/devices/system/cpu/vulnerabilities/ gives a little blurb about what is mitigating these or not,
BUT WHERE IS THE FUCKING DOCUMENTATION

the only thing I can find is this l1tf documentation which only covers l1tf. what about other 4, meltdown spec_store_bypass spectre_v1 spectre_v2?? how do I know what possibilities there are for what this can spit out?

the point remains that the kernel documentation is scattered all over the fucking place, and 9/10 significant research is required to figure out what is what. i'll bet after the research the only documentation I'll find on this shit is some random lkml from a patch somewhere, and that'll have to do it because the only alternative is what some faggot said on reddit somewhere.

Brody Ortiz
Brody Ortiz

this is why redhat is so popular and destroying linux in the process. no company is going to want to deal with this shit, they are much happier to pay $5000/mo and pick up a phone and get an explanation that redhat has dealt with it in their last kernel update and don't worry about it.

Henry Gomez
Henry Gomez

(((Why))) is that?
the same reason linus sat on it for a fucking year while intel did nothing and still scrambled at the last minute when the (((embargo))) expired.

These embargo's are ultimate jewry. They exist only to protect the financial interests of the jew.

Nathan Green
Nathan Green

Linux kernel is dead, Microsoft will be taking over in 2021

Gabriel Perez
Gabriel Perez

And India will become a nuclear superpower by 2020

And Hillary will become president in 2020

And the UK will repeal article 50 and remain the EU in 2020

Jacob Thompson
Jacob Thompson

I recently learned KASLR does literally nothing and is still exploitable. I also learned that kernel devs are retards that won't implement security featues.
They are retarded faggots who oppose men having child brides, what do you expect. Good people want what's best for their fellow man and what's worst for their not-fellow woman-enemy.

Linixarians used to be like this, 15 years ago, then they let in the women. Now they do NOT let in security.

For example grsecurity's specter and meltdown mitigations come at no cost to performance. But the linux kernel's mitigations have huge performance impacts. (((Why))) is that?

I pointed this out awhile ago, I was told I was lying and PROOFS!

It's because Spengler and PaX team know how the underlying hardware works. Linus _DOES NOT_. He is a stupid fuck that married a dog ugly woman.

Jack Jackson
Jack Jackson

No response ofcourse.

Easton Davis
Easton Davis

Line by line again. Redhat does not refute that the GPL is revocable, tacitly shows agreement.

License revocation: Some CLA advocates warn of the prospect that a contributor may someday attempt to revoke a past license grant.

<Some lawyers point out that a gratis license is revocable at the will of the grantor and you're a moron if you don't get a copyright transfer like the FSF has always demanded

To the extent that the concern is about largely judgment-proof individual contributors with no corporate affiliation,

<Redhat does not refute this concern, the people that are threatening to revoke currently do not work in the field and have no money (that's what judgement proof means: even if someone sued you they'd get fuck-all)

And, as with so many of the legal risks raised in discussions of open source legal policy, this appears to be a phantom risk.

<No one can sue us for legal malpractice if we put the word "appears" in here. We are saying that no one has revoked yet in the opensource world and then sued violators, if someone does... well it isn't a "phantom" risk anymore: it's a clear-and-present danger at that point, but we did say "appears"...

I have heard of only a few purported attempts at license revocation over the years,

all of which were resolved quickly when the contributor backed down in the face of community pressure.

<The community convinced the person not to sue anyone, largely by not having any money, and the lawyer advising the person wasn't going to do it for free, the lawyer also pointed out that because the plaintif didn't register his copyright /before/ people violated his recision, statutory damages and attorney's fees would be unavailable, only damages. The community was pennyless at that time and wasn't using the code in any meaningfully profitable way so this would be difficult case to make any money off of it

<Now we will just black ball anyone who revokes the license

<we would like to say they cannot do it, and if they could not do it we would say it

<but we can't, because they can, legally

<all we can do is try to fuck them for it

Thomas Morgan
Thomas Morgan

Intel, MS, Google, and IBM own Linux. There is no "community."

Grayson Cruz
Grayson Cruz

if you actually know how to program then you too can get your code in linux. its just that most here do not know so they just post that kind of shit instead of actually doing something useful.

John Watson
John Watson

if you actually know how to program then you too can get your code in linux
[citation needed]
show me the last commit to the linux kernel that wasn't by a (((big tech))) employee or someone otherwise officially employed to work on linux.

Brayden Harris
Brayden Harris

Linux supports highly obscure devices simply because there are programmers willing to maintain drivers for them. Anybody can write anything as long as Linus approves of how your specific system integrates into Linux. Linus rejected the systemd's team for kdbus not because he hates systemd (he doesn't) but because he disapproved the way the kdbus system integrated into Linux.

Liam Thompson
Liam Thompson

Linus is a very practical guy, he doesn't really have any convictions either way, he just cares about the quality of the kernel.

Angel Morris
Angel Morris

he doesn't really have any convictions either way, he just cares about the quality of the kernel.
<doesn't raise his daughter
<cucks to his daughter after sending her to sjw indoctrination camp and her riding a mile of nigger dicks.
<implement the most controversial CoC imaginable and caves to SJW culture with a pathetic apology saying he promises he'll be on his best behavior and stop being mean.
<next kernel release shows performance degradation and 5.1 isn't going to be any better.
(((pure coincidence)))

Owen Miller
Owen Miller

Do you want your Intel machine to support Spectre based attacks? It seems like that you'd rather prefer for Linux to support spectre attacks over proper security.

Kevin Hall
Kevin Hall

which spectre mitigations does 5.0 have that 4.X doesn't?
I thought they were all backported.

Aiden Hall
Aiden Hall

The reason why there is a spectre exploit in Intel (and AMD) is because Intel were making use of parallel processing techniques to increase the performance of the chips. The flaw with these performance techniques means that people are able exploit the chip and control it. The Linux software fix to prevent the spectre exploit from working is what caused the performance drop. If you're not allowed to use the functions that support high performance, you're going to lose the performance benefits of that feature.