Re: "obsolete" hardware

Edward S. Marshall (
Wed, 11 Jun 1997 13:09:24 -0500 (CDT)

On Wed, 11 Jun 1997, yuri mironoff wrote:
> 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.

Give *me* a break; percentage-wise be damned, I'm using linux in a heavy
routing situation here, and you're insane if you think I want to toss my
current equipment next year when NEXT YEAR'S latest and greatest causes
advocates like you to throw out support for THIS YEAR'S hardware.

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

Are you the one doing development? If a maintainer chooses to maintain
backwards compatibility, are you in a position to stop them? No. This is
the beauty of collaborative, free development; noone dictates to Solar
Designer how he designs his non-executable stack patch, noone dictated to
Alan and Co. when they were redesigning the networking code for 2.0.

> 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).

The 386 still has a great deal of uses, especially considering the cost of
equipment. Most specifically, it has exceptional uses in routing, terminal
serving, and other networking applications.

One of the more popular terminal servers among ISPs, the Livingston
Portmaster 2E, runs on a 386. Their newest design, the PM3, which came to
market about 4-6 months ago, runs on a 486. This is *new* hardware being
designed with old chips, because it is cost-effective to do so, and
because they realize that there is a great deal of life left in those

Just because you are a bleeding-edge bigot, do not force it on the rest of
us who choose not to upgrade every time Intel decides to release a new

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

Actually, we use 386s in a few applications, and 2940UWs in others. For
basic networking functionality, firewall management, bridging, etc, you
don't NEED more horsepower than a 386. Anything better is overkill for 9
out of 10 applications (the remainder would include networks needing
ATM-inside switching equipment, etc).

> 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".

Ah, threats. Welcome to Linux. You know, a *free development cycle*, with
people working on this because they love it, not because they're
necessarily making money doing it. We have, because of this, one of the
most finely crafted UNIX variants in existance. (Whoa, I'm starting to
sound like someone on comp.os.linux.advocacy...)

Yes, commercial acceptance is a goal. It's just not an overriding one. I
would hope that general design goals would take precedence. And this
operating system has worked just fine on the 386 architecture for a long
time. There's no reason to cease all work on the architecture (ala
Microsoft; does the PowerPC and MIPS platforms ring a bell?) just because
someone feels that they need work done on their problem faster.

In the end, neither of these arguments is going to matter; it's going to
be in the hands of the core developers who decide whether they care if "it
works on a 386". I think we've already heard from a few of them as to
where they stand.

| Edward S. Marshall <> | CII Technical Administrator,     |
|         | Vice-President, Common Internet  |
| Finger for PGP public key.               | Inc, and Linux & LPmud (ab)user. |