lkml.org 
[lkml]   [1999]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: 2.2.2: 2 thumbs up from lm
Date
Alan Cox writes:

>> I'd say this is a general human problem. I've seen it on linux-kernel
>> before, and I hate it. It makes developers quit. Why bother hacking
>> Linux if you know that your patches will just be shot down?
>>
>> I suppose the following could be my .sig file. The net has long
>> abandoned the 4-line .sig rule, and the patch is no worse than
>> the ugly hunks of PGP data that many people attach.
>
> With due respect there is a difference between the technical argument
> about the right way to do real time, and to clean up or improve the
> scheduler (which is undoubtedly possible since Ingo did for 2.2.0)

Yeah, my patch was 100% harmless.

> and continually posting a broken patch because you cannot grasp the
> concept of where the standards API/user app interface point is in Linux.

That layer can not be built properly:

Normal systems dump core on 11 signals.
Linux dumps core on only 6 signals.

This can not be fixed really. Maybe just change 5 random signals?
Nobody can know which ones may be changed. The kernel source contains
no hint beyond the existing signals. I do not ever expect glibc to
define the signals, since the potential for conflict is great.

-----

I've seen plenty of people wonder if they should bother hacking, since
they are afraid that thier patches will be rejected. This is bad.
I have a feeling that a UNIX v6 filesystem would be rejected, so why
would I bother to write it?

In many parts of the world, conflict is not tolerated well. There people
are totally excluded. It is as if patch submission required violence.

The shy are not welcome here. They may be great hackers, but hey,
they suck dude! Right? Nobody likes them anyway.

I'm sick of seeing behavior on linux-kernel that looks like Slashdot
behavior. (http://slashdot.org) Such behavior is harmful.

> There are two very real camps about the real time type stuff in Linux
>
> 1 is the "its either real time or its not". Thats things like rtlinux. If you
> say 71uS you get 71uS even if netscape is loading. And for the code modules
> that are critical to latency you pay in flexibility and API tools.
>
> 2 is the "most is good enough" argument. Thats not generally coming from
> the 'if we miss the building blows up' department of real time computing
> but from the 'I dont want my MP3 files to jump' school - where perfection
> isnt the aim.

The distinction is arbitrary. There is a risk-cost tradeoff to be made
for everything. We might not like to admit it, but even when human life
could be lost... there are finite financial resources.

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.132 / U:2.308 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site