The Linux approach is to do the job right. That means getting the
interface right and so it works across all the interested parties
(or as close as we can get)...
This is the Linux way of doing things. It's like the GPL and being
shouted at by Linus. They are things you accept when you choose to
-- Alan Cox
The kernel history is full of examples where crappy solutions got
rejected and kept out of the kernel for a long time even if there
was a need for them in the application field and they got shipped
in quantities with out of tree patches (NOHZ, high resolution
timers, ...). At some point people stopped arguing for crappy
solutions and sat down and got it right.
-- Thomas Gleixner
The whole "no reason to tolerate broken apps" mindset is simply
misguided IMO, because it's based on unrealistic assumptions.
That's because in general users only need the platform for running
apps they like (or need or whatever). If they can't run apps they
like on a given platform, or it is too painful to them to run their
apps on it, they will rather switch to another platform than stop
using the apps.
-- Rafael Wysocki
NAK NAK NAK NAK! QAK! HAK! Crap code! Stop adding undocumented
interfaces. Just stop it. Now. Geeze.
How is anyone supposed to use this? What are the semantics of this
thing? What are the units of its return value? What is the base
value of its return value? Does it return different times on
different CPUs? I assume so, otherwise why does sched_clock_cpu()
exist? <looks at the sched_clock_cpu() documentation, collapses in
-- Andrew Morton
after one patch too many
"The more we prohibit, the safer we are" is best left to the likes
of TSA; if we are really interested in security and not in security
theatre or BDSM fetishism, let's make sure that heuristics we use
-- Al Viro
to post comments)