RD> I would be happy to argue the merits or lack thereof of including this in
RD> the main kernel tree.
Yeah ? So far I've seen only loud screams about how great it feels and such.
I've NOT seen analysus of TECHNICAL part of said patches. And THAT part is
completely unacceptable as it is now. NOT ultimate goal (low latency is good
thing, no doubt here) but WAY to achive that goal. It's just WRONG WAY(tm).
RD> I've read Linus's letter; and I understand it's his puppy and ultimately
RD> he makes the decisions.
What you do NOT undertood is HOW decisions are made.
RD> However; I don't see how that justifies abuse on your part and it's not
RD> conducive to an intelligent discussion.
Yes, of course. I'm saying only for myself and my viewpoint is not necessary
Linus's viewpoint.
RD> If the Linux development community is not responsive to the end user
RD> community, refusing to incorporate necessary functionality on the basis of
RD> aesthetics, then that community will abandon Linux in favor of something else.
No problem to me.
RD> Is that really what you want?
I want good OS and not pile of crap like Windows or IRIX. And THE BEST and
FASTEST way to get pile of crap is to add one small feature, then another,
then yet another. And in just few years you'll have huge slow pile of crap
without clear way to clean thing.
RD> The reason for my original post is that I wanted people to realize this
RD> had utility even for people without special applications that require low
RD> latency; it makes the system operate considerably more pleasantly under load.
RD> I suspect if more people try it, more people are going to find it worthwhile.
Perhaps. But if you think that it can change Linus's decision then you just
NOT understood HOW Linus make such decisions. He stated it quite a few times:
it DOES NOT matter how many peoples want to add some crappy feature to kernel.
Till he has no explanation why there are NO way to solve problems in saner
style he'll not add thing to linux.
Just like Hans's constant screams "Yura, run the benchmarks" did not help
reiserfs acceptance your screams will not change Linus's mind on low latency
patch.
RD> I avoided products from M$ because of attitudes like yours. If this
RD> becomes the norm for Linux as well, then I guess I'll need to start looking at
RD> different OS's, again. But I think you just represent a vocal abusive
RD> individual, and not the mainstream development community.
You can start to find other OS right now. Linux adoptes features based
SOLELY on technical merit. ONLY if there are NO known way to solve some
problems. For short: "Good enough" is not good enough for Linus. Solution
must be "right" or better to leave problem in place. From Linus's almost
two year old mail:
-- cut --
Finally, even if the above isn't true, I often reject bug-fixes.
Bug-fixes are _often_ worse than the bug they fix, even with serious bugs.
Because a lot of bug-fixes are "band-aid" - not fixing the bug properly.
And band-aid is BAD. It's worse than even a crashing machine. Because
band-aid never goes away, and nobody cleans it up.
I prefer to have a known bug that will eventually get fixed than an ugly
solution that will hide it forever.
-- cut --
It explains everything clan enough, doesn't it ?
>> It's your opinion, not Linus's opinion. I'm REALLY glad Linus has more deep
>> understanding what's crap and what's not. Oh, I forgot: you just want
>> benefits of said patches, you will NOT maintain kernel. Yeah, of course in
>> SUCH case for YOU this patches are very appealing and non-intrusive: all
>> problems caused by hem will be Linus's problems not yours problems. BTW do
>> not mix Solar Designer patch and low latency patch. As Linus said quite a few
>> times some parts of Solar Designer patch like non-executable stack are just
>> "Wrong Things to do"(tm). Some other parts are integrated in kernel...
RD> Linus certainly has a more deep understanding of the OS he created, but
RD> with respect to what is crap and what is not; that is subjective NOT objective.
And still it's main decision rule. Yes, we have NO objective rule to know if
we need to include something in kernel. If we had we do not needed Linus in
first place.
RD> Part of the reason for making the post again is that I think if people
RD> realized the more general utility of this, yourself included, they would
RD> realize it's not just for ME that the patch is very appealing.
You mixing two things: GOAL of patch is REALLY appealing. TOOLS used by patch
looks like a band-aid solution even for patch's AUTHOR ! Let alone Linus.
RD> I think most anybody appreciates a system that responds smoothly and
RD> rapidly even under extreme load, rather than hurky-jerky which more
RD> generally characterizes Linux under load.
Of course it'll be nice earning. Just not by THAT price.
RD> As far as not mixing the two? Why not; both are of really more general
RD> utility than you apparently realize, or are willing to acknowledge. Both have
RD> been rejected mainly on asthetic grounds despite their obvious utility.
Like you or not but aesthetic ground is THE ONLY decision ground for Linus.
If you did not like it - switch to other OS. Or make a fork if you wish.
Stuff GUI in kernel like NT, make different page mapping for threads like IRIX.
Do anything you want, have fun. Just not sugget this to Linus, please.
>> Certainly both of these things affect MUCH more intimate parts of linux
>> kernel then packet radio hacks. And MUCH more dangerous (preemption point in
>> wrong place can easily freeze kernel due to deadlock and non-executable
>> stack... it was beaten to the dead already many times).
RD> They certainly EXPOSE races and deadlock conditions. But the proper
RD> approach is the FIX those problems rather than attempting to mask them by
RD> avoiding calling broken code too often.
Unfortunatelly it NOT just expose races. It can CREATE races where otherwise
there were no races. And it's HARD to track down. THUS it's hard to maintain,
not since it'll add few KiBs to kernel sources. About Solar Designer's patches
you can scan lklm archives - it was investigated quite deep few times and
conclusion was that non-executable stack it CAN break some things and (more
important) it DOES NOT help to protect system in long terms.
>> RD> Personally, I would be thrilled if Linux were just stable on Sparc-32 SMP
>> RD> platforms but that's another issue.
>>
>> And patches like mentioned above is way to make it LESS stable on you great
>> Sparc-32 SMP platform, not more stable.
RD> This is true, they do; but again, fixing the broken code rather than avoid
RD> calling it too frequently is the proper approach.
See above. If you even not understood HOW low latency patch can create new
races then why you are discussing it here at all ? You obviously do not
understood what this patch does good enough so you can not convince Linus
that said patch is not peice of crap. And it's ONLY thing that matters.
Benchmarks do not matter. Loud screams from thousands of users do not matter.
The only thing that IS matter is simple fact: is it considered a piece of crap
or not. Yes, it's subjective. Thus Linus CAN accept things initially considered
like a crap. It happened. But "public campaighn" like yours will make things
LESS appealing to Linus, not more. Just like it's with ReiserFS: Hans's whining
made reiserfs acceptance almost impossible for 2.4 even if initially developers
thought about it's inclusion in 2.4 ...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/