Language Selection

English French German Italian Portuguese Spanish

How not to piss off a kernel subsystem maintainer - part 5

Filed under
Linux

Heck, It's not like I haven't said all of this before, but it sure seems like no one learns from the past, or reads the documentation that we write for how to actually submit a patch for the kernel. Linux has one of the best documented procedures for how to do this, it's not like it's a secret or something...

Anyway, here's a list of patches that people have sent me in this week alone that have caused me major problems:

* patch was never even build tested, and of course, it breaks when you do build it.

* patch does build, but it was never tested because the patch does the opposite of what the submitter wanted to do.

* patch sent with no authorship

rest here




More in Tux Machines

Android/ChromeOS/Google Leftovers

Games: SC-Controller 0.4.2, Campo Santo, Last Epoch and More

Android Leftovers

Ryzen 7 2700X CPUFreq Scaling Governor Benchmarks On Ubuntu Linux

With this week's Ryzen 5 2600X + Ryzen 7 2700X benchmarks some thought the CPUFreq scaling driver or rather its governors may have been limiting the performance of these Zen+ CPUs, so I ran some additional benchmarks this weekend. Those launch-day Ryzen 5 2600X / Ryzen 7 2700X Ubuntu Linux benchmarks were using the "performance" governor, but some have alleged that the performance governor may now actually hurt AMD systems... Ondemand, of course, is the default CPUFreq governor on Ubuntu and most other Linux distributions. Some also have said the "schedutil" governor that makes use of the kernel's scheduler utilization data may do better on AMD. So I ran some extra benchmarks while changing between CPUFreq's ondemand (default), performance (normally the best for performance, and what was used in our CPU tests), schedutil (the newest option), and powersave (if you really just care about conserving power). Read more