Re: "obsolete" hardware

yuri mironoff (yuri@buster.rgti.com)
Wed, 11 Jun 1997 10:22:40 -0400 (EDT)


On Wed, 11 Jun 1997, Martin Mares wrote:

> (2) Linux is certainly meant to offer much more than running CPU-eating
> X applications. Those other capabilities (including network routing and
> bridging) require only little CPU power and a quad P7 won't noticeably
> improve their performance, so why buy it instead of using an old 386 and
> saving $6000. Well written applications seldom need lots of CPU time.

Give me a break - how many people are running Linux routers??? And
before there is a slew of "I do"s - percentage wise! MOST of the time
you want horsepower - not the ability to route.

>
> (3) We were talking about things like FPU emulation which don't need much
> time to maintain -- just to keep them consistent with the rest of the kernel.
> And using FP in the kernel is of a small value, it would also mean saving
> and restoring them on every syscall or take care of saving/restoring at every
> use.

You're missing the point. I'm not talking about taking it out. I'm not
even talking about the 386 specifically.

Again my point is not to waste time developing for obsolete
hardware.

If you so love the 386 - its your prerogative. As far as I'm concerned
it is deceased - it RIP - it is a dead parrot (oops chip).

I am more concerned about the current situation with the "can't
get a free page", SMP lockups and the Adaptec timeouts - I'm experiencing
all of the above. I know there are people spending their precious time
fixing this - but I would hate to hear that any of this would wind up
on the backburner because of 386 support. I would be willing to
bet quite a bit of money that there are more AIC7XXX in use out there
than 386s. The same for goes for SMP machines.

Let me also put it in a financial perspective. Our company is
developing a distributed IDE. It so happens that Linux is the target
platform. I would hate to explain to my boss that the bright side of
the situation is that "Linux works on a 386".

Regards,

Y.