lkml.org 
[lkml]   [2000]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Low Latency Patch
From
Date
Robert Dinse <nanook@eskimo.com> writes:

> On Mon, 3 Jul 2000, Khimenko Victor wrote:
> >
> > You are speaking from bitterness so I will forgive you but it's FAR from
> > true.
>
> I am bitter because some people here feel they have to resort to name
> calling, stupid, asshole, and other forms of verbal assualt rather than discuss
> something on it's merits. If there is a problem with an idea instead of a
> rational discussion of the problem it rapidly breaks down to personal attacks.
>
> I have been using Linux since .98 release of the kernel. Over that time
> I have seen a lot of major improvements in effeciency and functionality. I
> would love to see it displace Windows and overpriced commercial Unices.
>
> But I see some major impediments to that happening. On the desktop,
> people are not going to use an OS that can't decently handle multimedia
> applications and that is herky-jerky under moderate load.
>
> Ingo's patch addresses this issue. Perhaps it's not the right approach,
> but it fixes a serious glaring deficiency in Linux with respect to the Desktop
> market. By the time the "right" fix is developed and in place, if ever, that
> market may be lost. Microsoft isn't sitting idle while Linux is being
> developed.

It was discuted and *will be* fixed the *clean* way,
now instead of giving false argument, read the interesting thread
( the one that discuss about how to fix the problem the right way )
and help in the design / coding area if you can.

So your "why don't include the Ingo patch" argument isn't an
argument anymore.


>
> On the server front, Linux is not going to succeed if it isn't reasonably
> secure. Solar Designs patch is not a be-all and end-all for security, but it
> does provide some useful enhancements.

Talking about Non Executable stack (and *YES* i know that the patch
provide other interesting things ), it do not provide any security gain;

if you want to know why, I, and other who participated to this thread
about non exec stack will not repeat themselve 100 times, so just walk
throught the lkml archives and read mail containing LUID / General Security
in their subject.

here is a link :
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0004.2/index.html )

>
> Back in the early days of VCR's I bought a Beta machine. I loved how
> crisp the video was relative to the smeared washed-out video from VHS decks
> that my friends owned. I loved the quality of the Hi-Fi audio, it was and is
> truely awesome relative to VHS "Hi-Fi (not!)" audio. The rewind time was
> easily 1/3rd of most VHS decks, and the way you could shuttle the tape around
> instantly because it didn't have to load/unload from the drum each time was
> great.
>
> But you know what? It lost in the market place. VHS initially got two
> hours on a tape, Beta only one. You could get a full movie on one VHS tape, it
> took two of Beta. VHS came out with long play and extended play modes first.
> The quality was and is garbage, but they were first to the market. Today, Beta
> is dead, VHS is alive. Perhaps when DVD write becomes cheap enough it will be
> displaced. But the point is, being too late to the market kills a product.
>
> If Linux does not provide things needed for the desktop and server markets
> soon, it will lose the opportunity to dominate those areas. They you'll have a
> very maintainable kernel that nobody will use. Sure, there will be a few of
> you with Linux boxes doing some esoteric function in a herky-jerky insecure
> manner but easily maintainable manner, but the mainstream public will be using
> something else.
>
> I don't want to see Linux become a bloated unmaintainable piece of crap,
> nor do I want to see it die on the vine, which if latency, security, and
> stability issues are not addressed, it surely will do.
>
>

Theses things you're talking about are going to be done in a clean way
(and you'll maybe already know it if you was reading the interesting
mail (not this thread) ).

Maintaining this thread alive doesn't even brought any quality
discution about design / code thingies...

now help coding and stop maintaining this offtopic discutions.

This thread should die.

Ps : if you wish to continue this BS thread,
please remove the lkml address from the CC : it will, at least,
prevent to bloat the list with non existing and offtopic things,
and people CC'd will be free to not answer your email message.

--
-- Yoann, http://www.mandrakesoft.com/~yoann/
It is well known that M$ products don't call free() after a malloc().
The Unix community wish them good luck for their future developments.

-
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:57    [from the cache]
©2003-2011 Jasper Spaans