Quotes of the week

From LinuxReviews
Jump to navigationJump to search

The LinuxReviews Quote of the week is some free software related quote which is shown on the front page of this website. What quote is used is typically random and everything goes as long as it's somehow related to free software or computers or anything else remotely relevant. The same quote will sometimes stay up one week, sometimes four. The quotes have so far been thrown away when they have been replaced. That may be a waste so this page was created to collect them when they are thrown away.

Week 40, 2019

"The purpose of a non-free program is to subjugate people. And typically that leads to malicious functionalities. Many of the most widely non-free programs are MALWARE. Now, note that malware is totally different issue, a different consent. The difference between free software and proprietary software is a matter of how the program is distributed to users, on what conditions for instance it's distributed. And the same code, any code, could be distributed as free software, any code could be distributed as proprietary software. Sometimes the same code is distributed both ways in parallel. It's a matter of how the code is distributed. It is not a technical issue, it is not a technical distinction between free and proprietary. Technical distinctions are things like what features does the program have, how does it work, how was the code written? Those are all technical things. This is a social, ethical and political distinction which is why it is so important."

Week 41, 2019

"No System Is Safe!"

慕冬亮 (Dongliang Mu) on the Linux Kernel Mailing List on September 26th, 2019

Week 45, 2019

"Please do not stick defines into a function body. That's horrible."

Thomas Gleixner on the Linux Kernel Mailing List August 27th, 2019

Week 46, 2019

"These processors are buggy as hell, and some of these bugs don't just cause development/debugging problems, but will *ASSUREDLY* be exploitable from userland code."

Week 49, 2019

"I can't help but point out that if we do this, then we're forcing everyone to pay a price in terms of runtime performance and codesize -- even if they're on a processor where this doesn't matter."

Jeff Law on the binutils mailing list addressing Intel proposals to make a performance-hampering firmware update which works around a design flaw in their CPUs look slightly less bad.

Week 50, 2019

"Quite frankly, this is f*cking moronic. The whole thing seems to be designed around stupid interfaces, for completely moronic reasons. Why should we do this?"

Linus Torvalds on the LKML. February 12st, 2013

Week 51, 2019

"Yes, doing it in the kernel is "more robust". But don't play games, and stop the lying. It's more robust because we have maintainers that care, and because we know that regressions are not something we can play fast and loose with. If something breaks, and we don't know what the right fix for that breakage is, we *revert* the thing that broke."

Linus Torvalds on the LKML. October 3rd, 2012

Week 52, 2019

"I have zero confidence that we understand the real problem, but we do need to do something with this."

Bjorn Helgaas on the Linux Kernel Mailing List
November 19th, 2019

Week 1, 2020

"So the code in question is pure garbage. You can't do spinlocks like that. Or rather, you very much can do them like that, and when you do that you are measuring random latencies and getting nonsensical values, because what you are measuring is "I have a lot of busywork, where all the processes are CPU-bound, and I'm measuring random points of how long the scheduler kept the process in place".

And then you write a blog-post blamings others, not understanding that it's your incorrect code that is garbage, and is giving random garbage values."

Linus Torvalds on a Google Stadia employees blog post about the Linux kernels Linux Scheduler, January 3rd, 2020

Week 4, 2020

"this: (..) is just complete gibberish. And I have no idea what problem you're trying to solve how. (..) So what you're doing is, mark the CPU 'idle' when the MPERF/TSC ratio < 1%, and then frob the vruntime such that it will hopefully preempt. That's pretty disgusting."

Peter Zijlstra in a message regarding
"sched/fair: Penalty the cfs task which executes mwait/hlt" patch
on the Linux Kernel Mailing List, January 8th, 2020

Week 5, 2020

"You're weasel-wording, and making up arguments that aren't valid."

Linus Torvalds, January 31 2006
in a message titled "GPL V3 and Linux - Dead Copyright Holders" on the LKML

Week 5-6, 2020

"It's too late for this, sorry :(

Code needed to be in my tree usually for a week before the merge window opens before I can add it to that merge window. This got no testing in linux-next or anywhere else, so I can't take it."

Greg KH on the LKML, January 27th, 2020

Week 7, 2020

"> KVM: nVMX: Emulate MTF when performing instruction emulation

This was committed today, and it's complete and utter garbage:

CommitDate: 7 hours ago

It doesn't even compile. Just in the patch itself - so this is not a merge issue, I see this:

+static void vmx_skip_emulated_instruction(struct kvm_vcpu *vcpu)
+ return skip_emulated_instruction(vcpu);
..
- .skip_emulated_instruction = skip_emulated_instruction,
+ .skip_emulated_instruction = vmx_skip_emulated_instruction,

ie note how that vmx_skip_emulated_instruction() is a void function, and then you have

return skip_emulated_instruction(vcpu);

in it, and you assign that garbage to ".skip_emulated_instruction" which is supposed to be returning 'int'.

So this clearly never even got a _whiff_ of build-testing. The thing is completely broken.

Stop sending me garbage.

You're now on my shit-list, which means that I want to see only (a) pure fixes and (b) well-tested such. Nothing else will be pulled."

Linus Torvalds on the LKML
February 12th, 2020

Week 8

"This isn't the library routine, it is only used in the kernel. as such, we don't care about years<1970 etc, but assume everything is ok. Similarly, TZ etc is happily ignored. We just do everything as easily as possible."

mktime.c in Linux 0.01

Week 9

"This isn't the library routine, it is only used in the kernel. as such, we don't care about years<1970 etc, but assume everything is ok. Similarly, TZ etc is happily ignored. We just do everything as easily as possible."

mktime.c in Linux 0.01

Week 10

"From experience I just know that every time we extended the futex interface we opened another can of worms which hunted us for years if not for more then a decade. Guess who has to deal with that. Surely not the people who drive by and solve their real world usecases. Just go and read the changelog history of futexes very carefully and you might understand what kind of complex beasts they are.

At some point we simply have to say stop, sit down and figure out which kind of functionality we really need in order to solve real world user space problems and which of the gazillion futex (mis)features are just there as historical ballast and do not have to be supported in a new implementation, REQUEUE is just the most obvious example."

Thomas Gleixner on the LKML
February 29th, 2020

Week 11, 2020

"The Loongson 7A1000 bridge chip has been released for several years since the second half of 2017, but it is not supported by the Linux mainline kernel while it only works well with the Loongson internal kernel version. When I update the latest version of Linux mainline kernel on the Loongson 3A3000 CPU and 7A1000 bridge chip system, the boot process failed and I feel depressed.

(..)

This patch series adds the basic support for the Loongson 7A1000 bridge chip, when apply these patches based on linux-5.6-rc5, the boot process is successful and we can login normally used with the latest firmware and discrete graphics card, the next work to do is power management and some other controller device drivers."

Loongson developer Tiezhu Yang
on the LKML, March 9th, 2020

Week 13, 2020

"All the infrastructure seems to be there to control the low gain / high gain control but it's not actually hooked up.

The driver currently just applies that number as a multiplier without changing the state of the chip to match.

Let's leave it there, but at somepoint would be good to dig out some hardware and actually make this work as expected. I 'might' get to this at somepoint."

Jonathan Cameron on the Linux Kernel Mailing List
March 21st, 2020

Week 14, 2020

"sorry, my bad."

Week 15, 2020

"yes, using the floating point calculations in the display code has been a source of numerous problems and confusion in the past.

The calls to kernel_fpu_begin() and kernel_fpu_end() are hidden behind the DC_FP_START() and DC_FP_END() macros which are supposed to hide the architecture depend handling for x86 and PPC64.

This originated from the graphics block integrated into AMD CPU (where we knew which fp unit we had), but as far as I know is now also used for dedicated AMD GPUs as well.

I'm not really a fan of this either, but so far we weren't able to convince the hardware engineers to not use floating point calculations for the display stuff."

AMD kernel developer Christian König
on the LKML April 2nd, 2020

Good onces

"Would you really merge a bunch of huge cleanups that would potentially break tons of stuff in subtle ways because coding style is that important? I'm done with that myself. I've merged too many half-baked cleanups and new features in the past and ended up spending way more time fixing them than I would have otherwise for relatively little gain."

Current

The current "Quote of the week" is put in place using template:Quote of the week. That template is currently showing:

"yes, using the floating point calculations in the display code has been a source of numerous problems and confusion in the past.

The calls to kernel_fpu_begin() and kernel_fpu_end() are hidden behind the DC_FP_START() and DC_FP_END() macros which are supposed to hide the architecture depend handling for x86 and PPC64.

This originated from the graphics block integrated into AMD CPU (where we knew which fp unit we had), but as far as I know is now also used for dedicated AMD GPUs as well.

I'm not really a fan of this either, but so far we weren't able to convince the hardware engineers to not use floating point calculations for the display stuff."

AMD kernel developer Christian König
on the LKML April 2nd, 2020


avatar

Anonymous user #1

3 months ago
Score 1 You
why not also quote Lenin or Stalin ?
Add your comment
LinuxReviews welcomes all comments. If you do not want to be anonymous, register or log in. It is free.