Quotes of the week

It wouldn't be the first time lockdep & ftrace live locked the system. Or made it so unbearably slow. Lockdep and ftrace do not play well together. They both are very intrusive. The two remind me of the United States congress. Where there is two parties trying to take control of everything, but nothing ever gets done. We end up with a grid/live lock in the country/computer.

I can see some vindictive programmer doing that, while thinking "I'll show these people who pointed out this bug in my code, mhwhahahahaa! I'll fix their test-case while still leaving the real problem unaddressed", but I don't think compiler people are quite *that* evil. Yes, they are evil people who are trying to trip us up, but still..

In that way, my philosophy of ext4 is that it should be like the Linux kernel; it's an evolutionary process and central planning is often overrated. People contribute to ext4 for many different reasons, and that means they optimize ext4 for their particular workloads. Like Linus for Linux, we're not trying to architect for "world domination" by saying, "hmm, in order to 'take out' reiserfs4, we'd better implement features foo and bar".

You're making the assumption that users are informed and knowledgable, and all filesystem developers should know this is simply not true. Users repeatedly demonstrate that they don't know how filesystems work, don't understand the knobs that are provided, don't understand what their applications do in terms of filesystem operations and don't really understand their data sets. Education takes time and effort, but still users make the same mistakes over and over again.

Looks like there are more dragons and hidden trapdoors in the drm release path than actual lines of code.