Quotes of the week

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

Richard Stallman: Freedom in your computer and in the net (2014-12-29) (10m40s)

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

Theo de Raadt Intel CPUs on Jun 27, 2007

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

Johannes Berg on breaking Wifi for all Intel Wifi Chipset users in Linux kernel 5.6 (and 5.6.1

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

Week 30, 2020

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

Alexander Deucher on DRI-devel, December 9th, 2016

Week 31, 2020

"Vulkan sure is bad. I can't think of anything good about it, other than "is not GL". For some reason vulkan.h may even pull in xrandr headers"

wm4 in #mpv-devel July 22nd, 2020

Week 32, 2020

"(unconfirmed source) usa embassy in china selling stuff (furniture...) now

Lol stk 1.2 may release when usa declare war on china!"

Anonymous Asia-based SuperTuxKart developer, August 3rd, 2020

Week 33, 2020

"We must be kind to each other and respect each other when our good faith arguments differ, in order to produce the best solutions together. I pledge to support honest dialog and emerging leaders in the quest to secure the future for free software for generations to come, and not to alter the tenets of the free software vision."

Geoffrey Knauth on becoming President of the Free Software Foundation

Week 35, 2020

"Linux. It's not just an OS, it's an ADVENTURE"

Sauvin on #Linux
August 24th, 2020

Week 36, 2020

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

Linus Torvalds on Intel processors on the LKML January 3rd, 2018

Week 37, 2020

""Honestly, I think those emails are more about Debian culture than they are about me, and you should probably ask the Debian people about them rather than me,""

Linus on Debian developers complaining that he violated their "Code of Conduct", September 2020

Week 39, 2020

"The chances of a random photon from the sun hitting your scene is tiny"

Jason Ekstrand presenting the Vulkan ray-tracing API
at the X.Org Developers Conference 2020

Week 40, 2020

"But while I do now know of any remaining gating issues any more, the fixes came in fairly late. So unless I feel insanely optimistic and/or a burning bush tells me that everything is bug-free, my plan right now is that I'll do another rc next Sunday rather than the final 5.9 release. And btw, please no more burning bushes. We're kind of sensitive about those on the West coast right now."

Linus Torvalds announcing Linux 5.9-rc7. Sunday September 27th, 2020

Week 41, 2020

"Of course I added a hidden segfault specifically to annoy Chaekyung, which was the entire goal of this commit, and which is why it will never be fixed. Read() fails and the negative value is added to len, so of course that'll crash."

mpv developer wm4
explaining his reasoning behind mpv commit 602384348e71 which introduced a segfault

Week 42, 2020

"There was no centralized server management what so ever. Basically there was just a bunch of servers, in some cases quite literally in someone else's bathroom and there was no term called "DevOps" or a Arch Linux DevOps team"

Sven-Hendrik Haaase on how Arch Linux servers were "managed" in the past.

Week 43, 2020

"Let's fight to keep education technology open. We need to, and I think if we don't, there's possibilities for the very large companies to start taking over the education space and once they do that they will also take over the future of the planet and I don't think that's what we want."

Martin Dougiamas

Week 44, 2020

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

Richard Stallman: Freedom in your computer and in the net (2014-12-29)

Current

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

"Let's fight to keep education technology open. We need to, and I think if we don't, there's possibilities for the very large companies to start taking over the education space and once they do that they will also take over the future of the planet and I don't think that's what we want."

Martin Dougiamas

Enable comment auto-refresher