Quotes of the week, 2020
Week 1, 2020[edit]
"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."
Week 4, 2020[edit]
"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."
"sched/fair: Penalty the cfs task which executes mwait/hlt" patch
on the Linux Kernel Mailing List, January 8th, 2020
Week 5, 2020[edit]
"You're weasel-wording, and making up arguments that aren't valid."
in a message titled "GPL V3 and Linux - Dead Copyright Holders" on the LKML
Week 5-6, 2020[edit]
"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."
Week 7, 2020[edit]
"> 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."
Week 8[edit]
"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."
Week 9[edit]
"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."
Week 10[edit]
"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."
February 29th, 2020
Week 11, 2020[edit]
"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."
on the LKML, March 9th, 2020
Week 13, 2020[edit]
"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."
March 21st, 2020
Week 14, 2020[edit]
"sorry, my bad."
Week 15, 2020[edit]
"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."
on the LKML April 2nd, 2020
Week 30, 2020[edit]
"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."
Week 31, 2020[edit]
"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"
Week 32, 2020[edit]
"(unconfirmed source) usa embassy in china selling stuff (furniture...) now
Lol stk 1.2 may release when usa declare war on china!"
Week 33, 2020[edit]
"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."
Week 35, 2020[edit]
"Linux. It's not just an OS, it's an ADVENTURE"
August 24th, 2020
Week 36, 2020[edit]
"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."
Week 37, 2020[edit]
""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,""
Week 39, 2020[edit]
"The chances of a random photon from the sun hitting your scene is tiny"
at the X.Org Developers Conference 2020
Week 40, 2020[edit]
"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."
Week 41, 2020[edit]
"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."
explaining his reasoning behind mpv commit 602384348e71 which introduced a segfault
Week 42, 2020[edit]
"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"
Week 43, 2020[edit]
"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."
Week 44, 2020[edit]
""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.""
See also: Quotes of the week
