In comp.dcom.lans.ethernet John Navas <spamfilter0@navasgroup.com> wrote in part:
> 18:08:21 GMT, Robert Redelmeier <redelm@ev1.net.invalid> wrote:
>>IMHO, a strong case can be made that IBM intended for
>>the original 5120 PC to be a flop. A sacrificial lamb.
>>They did everything against the proven IBM ways to success:
>>outsourced, open architecture, minimal testing/err chk.
>>And chose the i8088, arguably the worst CPU of the day.
>>
>>But, as time has shown, they failed at failure. The PC succeeded!
>
> That's a joke, right?

No. I'm surprised the tinfoil-hatted crowd hasn't seized on this.
The PC was an unexpected success. Perhaps it wasn't expected
to be a success at all! At least at senior levels. It was not
done using IBM's proven project methods. Large bureaucratic
organizations like IBM was at the time are far more likely to be
defensive (to the point of sacrifical lambs) than to be innovative.

-- Robert

>

In article <FK4bg.78304$H71.47443@newssvr13.news.prodigy.com> ,
redelm@ev1.net.invalid says...
> In comp.dcom.lans.ethernet John Navas <spamfilter0@navasgroup.com> wrote in part:
> > 18:08:21 GMT, Robert Redelmeier <redelm@ev1.net.invalid> wrote:
> >>IMHO, a strong case can be made that IBM intended for
> >>the original 5120 PC to be a flop. A sacrificial lamb.
> >>They did everything against the proven IBM ways to success:
> >>outsourced, open architecture, minimal testing/err chk.
> >>And chose the i8088, arguably the worst CPU of the day.
> >>
> >>But, as time has shown, they failed at failure. The PC succeeded!
> >
> > That's a joke, right?
>
> No. I'm surprised the tinfoil-hatted crowd hasn't seized on this.
> The PC was an unexpected success. Perhaps it wasn't expected
> to be a success at all! At least at senior levels. It was not
> done using IBM's proven project methods. Large bureaucratic
> organizations like IBM was at the time are far more likely to be
> defensive (to the point of sacrifical lambs) than to be innovative.

This is only half correct. IBM, at the time, was experimenting
with skunk-works types of projects to try to get around some of the
bureaucratic stodginess they'd built up. The PC was one of these
semi-autonomous projects. No, it wasn't expected to turn the world
on its ear, and likely would have been killed if anyone thought it
really would. Of course it wasn't done with IBM's "proven project
methods". That was the point of these independent projects (every
development lab had them).

--
Keith

Keith <krw@att.bizzzz> writes:
> This is only half correct. IBM, at the time, was experimenting with
> skunk-works types of projects to try to get around some of the
> bureaucratic stodginess they'd built up. The PC was one of these
> semi-autonomous projects. No, it wasn't expected to turn the world
> on its ear, and likely would have been killed if anyone thought it
> really would. Of course it wasn't done with IBM's "proven project
> methods". That was the point of these independent projects (every
> development lab had them).

they were suppose to be independent business units ... and they were
funded to be lean and mean. however, they frequently conserved costs
by being co-located at an existing corporate facility ... and had to
deal with various bureaucratic issues at those locations.

the frequent response to claiming that you weren't suppose to be
subject to some bureaucratic process ... was that those rules only
applied to other bureaucratic processes ... IT DIDN"T apply to THEIR
bureaucratic processes. when nearly all of the bureaucrats made such
assertions ... you found that you weren't funded and/or staffed to
handle such bureaucratic processes.

on a smaller scale in the 70s, most labs were supposed to set aside
some portion of their budget for advanced technology projects ... and
you found various labs sponsoring "adtech" conferences. however, going
into the late 70s, you found some number of sites heavily using their
"adtech" resources for fire fights in normal day-to-day product
operation. as a result there was a derth of internal adtech
conferences during the late 70s and early 80s.

i managed to run one in mar82 out of SJR ... but it had been the first
in a number of years. minor post mentioning the event and listing the
CFP
http://www.garlic.com/~lynn/96.html#4a

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

On 18 May 2006 11:35:39 -0700, "Le Chaud Lapin"
<unoriginal_username@yahoo.com> wrote:

>Actually, if Bluetooth had every feature one could imagine and there
>were zero bugs in it, I still would not want it. What I am complaining
>about is the mess.

The messier it is, the better it works. I think I invented that line
after dealing with far too many complaints about my lack of
"elligance" in radio design. If it works ship it. If you ship it,
it's already obsolete because the next two generations of replacement
products are already in the pipeline.

If elligance were a sellable commodity demanded by consumers and
OEM's, you would probably have your way. It results in products that
are full of compromises, band-aids, and marginal design. I don't buy
a Bluetooth headset because it's "elligant". I buy it because it
works adequately (and looks cool). If you don't like a product, just
wait about 3 months for the replacement. Welcome to the 21st century.

Also, please realize that what you consider to be a mess is the end
result of considerable wrangling, haggling, debates, yelling, and
minor violence on the part of the various standards committees,
consortiums, forums (fora?), and conspiracies in smoke filled hotel
rooms and overpriced restaurants. (I may have a photo somewhere of
the restaurant table cloth on which SNMP was first conceived). The
compromises involved are often not optimal for best design practices,
such as where some member of the consortium refuses to contribute a
patent or supply sane license terms. Of course, after the job is
done, there's *ALWAYS* someone who thinks it could have been done
better, but somehow didn't feel that it was important to either
participate or offer their brilliance at the time when changes would
have been possible. At that point, unless you found a fatal flaw or
major issue, it's done and ossified in stone.

>It is often the case that the
>"model", if there is one, is defective, and it's almost comical to see
>engineers attempting to speak intelligently about a something that is
>still in a state of a nothing.

Nifty. A plea for serial development, where each step of the process
from conception to deliver is performed one step at a time.
Conceptually, this is the most eligant way, resulting in the fewest
bugs and complications. Unfortunately, both paying customers and
boards of directors are rather impatient beasts. They want it *NOW*
and are not willing to wait for serial development. So, the product
development cycle degenerates into parallel development, where many
engineers and programs are working with vaporware, emulators, science
fiction technology, real-soon-now component deliveries, and impossible
schedules. Welcome (again) to the 21st century.

>> Ask yourself why TCP/IP won over OSI 7 layer (as implemented by 3Com),
>
>OSI, was more like a mood. I have never seen one line of OSI "code".

You haven't looked very hard. In the mid 80's, the OSI layer cake
model was conceived to replace the lack of eligance found in Unix. A
major problem with Unix was that networking was largely grafted into
the kernel and was a rather bad fit. OSI networking would solve that
by designing in the networking. It was largely conceived and
implimented by academics and institutions. There was minimal industry
participation. The design was de jure (in principle) instead of de
facto (in practice). In other words, there was little testing.

If you read the magazines of the day, everyone agreed that TCP/IP was
on its way out, was badly designed, was not sufficient scaleable to
survive much longer, and was going to be replaced by OSI model
networking. Surveys of potential large network customers revealed an
overwhelming interest in switching to an OSI model network.

The first product to arrive was by 3com. 3com 3+share, 3+mail,
3+remote, etc was the first OSI (DOS based) product. Slowest piece of
junk I've ever tried to sell and support. Here was the alleged answer
to all of TCP/IP's lack of eligance and it looked like a giant step
backwards.

The addition of X.400 email addressing and X.500 directory services
really made life miserable for the customers. Putting the routeing
and header information in the email address was considered clever at
one time. I guess none of the academics bothered to ask the users.
X.500 was even worse. Nobody could understand how it worked or how to
make it useful. It took LDAP and possibly AD to mostly clean up the
applications and user interfaces. X.500 is a great example of extreme
design elegance resulting in difficult implimentations.

I'm not going to go into what went wrong with OSI networking. Lots of
problems and corresponding allegations. It doesn't matter. What does
matter is the OSI didn't solve any of the real user problems and
didn't meet the market requirements. However, it wasn't a mess and
was rather eligant.

>I get the feeling it was "designed" by people who actually knew what
>they were talking about, but lost the ability to program computers
>(read implement their vague vision) several decades earlier.

Well, there's some truth in that. If you have a spare moment, try to
predict the applications and technology of perhaps 5 to 10 years from
now. Write it down on a piece of paper and seal it in an envelope to
be opened 5 to 10 years from now. I actually did that in about 1990
and found myself wrong on just about everything.

>But let's face it...if you were to apply the label "universal" to all
>of these protocols, it would only stick on TCP/IP, and not because
>everyone is using TCP/IP, but because TCP/IP is inherently more
>universal than the others. I think we are saying the same thing here.

Exactly. Broad applications support, extensibility, and the ability
to abuse the technology to make it do something it was never intended
to do, is what makes a winner. Oh yeah, the lack IP (intellectual
property) and licensing constraints.

>We should get away from attaching IP
>addresses to interfaces. That model alone causes a lot of problems.

Enlighten me. What problems does haveing individual IP's on each
interface port cause? It allows me to route between interfaces. It
allows me to virtualize interfaces as in VPN and devices as in iSCSI.
Failover is a bit tricky, but has been done with proper hardware
support to allow moving a MAC address. I kinda like that idea which
includes IPv6 attaching an IP address to everything including the
kitchen sink. If it's IP addressable, you can talk to it with TCP/IP.
I fail to see a problem.

--
# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
# 831-336-2558 jeffl@comix.santa-cruz.ca.us
# http://802.11junk.com jeffl@cruzio.com
# http://www.LearnByDestroying.com AE6KS

[POSTED TO alt.internet.wireless - REPLY ON USENET PLEASE]

In <FK4bg.78304$H71.47443@newssvr13.news.prodigy.co m> on Thu, 18 May 2006
20:25:09 GMT, Robert Redelmeier <redelm@ev1.net.invalid> wrote:

>In comp.dcom.lans.ethernet John Navas <spamfilter0@navasgroup.com> wrote in part:
>> 18:08:21 GMT, Robert Redelmeier <redelm@ev1.net.invalid> wrote:
>>>IMHO, a strong case can be made that IBM intended for
>>>the original 5120 PC to be a flop. A sacrificial lamb.
>>>They did everything against the proven IBM ways to success:
>>>outsourced, open architecture, minimal testing/err chk.
>>>And chose the i8088, arguably the worst CPU of the day.
>>>
>>>But, as time has shown, they failed at failure. The PC succeeded!
>>
>> That's a joke, right?
>
>No. I'm surprised the tinfoil-hatted crowd hasn't seized on this.
>The PC was an unexpected success. Perhaps it wasn't expected
>to be a success at all! At least at senior levels. It was not
>done using IBM's proven project methods. Large bureaucratic
>organizations like IBM was at the time are far more likely to be
>defensive (to the point of sacrifical lambs) than to be innovative.

You're apparently unfamiliar with the actual history. It was explicitly set
up outside of the IBM bureaucracy as a kind of "skunk works" project in order
to give it the best chance of success -- see
<http://en.wikipedia.org/wiki/IBM_PC>:

Rather than going through the usual IBM design process, which had
already failed to design an affordable microcomputer (for example the
failed IBM 5100), a special team was assembled with authorization to
bypass normal company restrictions and get something to market
rapidly. This project was given the code name Project Chess.

The team consisted of just 12 people headed by William Lowe. They
succeeded -- development of the PC took about a year. To achieve this
they first decided to build the machine with "off-the-shelf" parts
from a variety of different original equipment manufacturers (OEMs)
and countries. Previously IBM had developed their own components.
Second they decided on an open architecture so that other
manufacturers could produce and sell compatible machines -- the IBM PC
compatibles, so the specification of the ROM BIOS was published. IBM
hoped to maintain their position in the market by royalties from
licensing the BIOS, and by keeping ahead of the competition
..
--
Best regards, SEE THE FAQ FOR ALT.INTERNET.WIRELESS AT
John Navas <http://en.wikibooks.org/wiki/FAQ_for_alt.internet.wireless>

On Thu, 18 May 2006 14:21:08 -0400, Keith <krw@att.bizzzz> wrote:

>In article <pK2bg.78202$H71.34511@newssvr13.news.prodigy.com> ,
>redelm@ev1.net.invalid says...
>> In comp.dcom.lans.ethernet Rich Grise <richgrise@example.net> wrote in part:
>> > On Thu, 18 May 2006 13:20:43 +0000, Robert Redelmeier wrote:
>> >> "Satisficing". IBM PC architecture is horrible, x86 is
>> >> bletcherous, according to "experts". Yet both persist.
>> >
>> > BTW, I agree, and I have had a modicum of experience with processors. :-)
>>
>> IMHO, a strong case can be made that IBM intended for
>> the original 5120 PC to be a flop. A sacrificial lamb.
>> They did everything against the proven IBM ways to success:
>> outsourced, open architecture, minimal testing/err chk.
>> And chose the i8088, arguably the worst CPU of the day.
>
>The 5120 was pretty much a flop. The original PC was the 5150.
>;-)

The 5120 was not initially a flop. It was introduced in 1980 and sold
for about $10,000 per system (including the worlds biggest and
noisiest small office printer). It came with quite a collection of
transplanted Model 34/36/38 applications for what was at the time
considered a reasonable price.

However, one year later, in 1981, IBM introduced the 5150, also known
as the IBM PC for about $2,000 systems price. Sales of the 5120 came
to an immediate halt.

See:
http://www-03.ibm.com/ibm/history/exhibits/pc/pc_1.html (9 pages)
for a terse history on the various products.

As for the x86 architecture being "bletcherous", note that the various
8088/8086 segmented registers and architecture were optimized by Intel
to run Pascal, which was deemed to be the elegant language of the
period. According to the pundits, everyone would soon be programming
in Pascal because it is sooooooooo elegant. Didn't happen.


--
# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
# 831-336-2558 jeffl@comix.santa-cruz.ca.us
# http://802.11junk.com jeffl@cruzio.com
# http://www.LearnByDestroying.com AE6KS

[POSTED TO alt.internet.wireless - REPLY ON USENET PLEASE]

In <p50q62to45hncfnke7lhbklgohbck95hl8@4ax.com> on Thu, 18 May 2006 23:32:58
GMT, Jeff Liebermann <jeffl@comix.santa-cruz.ca.us> wrote:

>As for the x86 architecture being "bletcherous", note that the various
>8088/8086 segmented registers and architecture were optimized by Intel
>to run Pascal, which was deemed to be the elegant language of the
>period. According to the pundits, everyone would soon be programming
>in Pascal because it is sooooooooo elegant. Didn't happen.

That's not entirely true. Turbo Pascal (Borland) was an early hit that
greatly contributed to the success of the IBM PC. But for the Microsoft
juggernaut it might well have continued to be an important factor.

--
Best regards, SEE THE FAQ FOR ALT.INTERNET.WIRELESS AT
John Navas <http://en.wikibooks.org/wiki/FAQ_for_alt.internet.wireless>

Jeff Liebermann wrote:
> Enlighten me. What problems does haveing individual IP's on each
> interface port cause? It allows me to route between interfaces. It
> allows me to virtualize interfaces as in VPN and devices as in iSCSI.
> Failover is a bit tricky, but has been done with proper hardware
> support to allow moving a MAC address. I kinda like that idea which
> includes IPv6 attaching an IP address to everything including the
> kitchen sink. If it's IP addressable, you can talk to it with TCP/IP.
> I fail to see a problem.

I've been doing some thinking about how to solve the mobility problem,
and after much musing,I arrived at the conclusion that network
interfaces should be regarded as dumb. The protocol stack should query
each network interface for information at certain critical instances,
but beyond that, they should be regarded as means to get data from one
node to another in a frame, using one of the casting methodds (uni,
multi, broad, etc).

Then, if this is done, no IP address would ever be directly associated
with an interface. Instead, the routing table would maintain the
mappings. Then if nodes move, you simply update your routing table,
very rapidly of course, at stategic instances. This assumes an
assertion I made back in 1990: the day will come when almost all
computers are powerful enough to maintain routing tables, not just
routers. I think it is safe to say that that day has come.

(I also said the same thing about DNS trees, but that's a different
topic).

-Le Chaud Lapin-

On Thu, 18 May 2006 23:29:53 GMT, John Navas
<spamfilter0@navasgroup.com> wrote:

> The team consisted of just 12 people headed by William Lowe. They
> succeeded -- development of the PC took about a year.
(...)

As I recall, there were several IBM groups working on competitive
models of the IBM home computer in 1980. One was an Apple ][ clone.
Others were built in traditional IBM internal development models. The
whole process took about a year to the point where management met to
decide a single winner. When asked how long it would take to deliver
the product to manufacturing, the 5150 was the fastest because of use
of off the shelf parts and outsourced options (e.g. Epson printer).
Never mind elegance, just deliver it NOW.


--
# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
# 831-336-2558 jeffl@comix.santa-cruz.ca.us
# http://802.11junk.com jeffl@cruzio.com
# http://www.LearnByDestroying.com AE6KS

On 18 May 2006 17:11:02 -0700, "Le Chaud Lapin"
<unoriginal_username@yahoo.com> wrote:

>I've been doing some thinking about how to solve the mobility problem,
>and after much musing,I arrived at the conclusion that network
>interfaces should be regarded as dumb.

Brilliant. See:
http://en.wikipedia.org/wiki/Dumb_network
and David Isen's "Stupid Network" article:
http://www.isen.com/stupid.html

Incidentally, DHCP assumes that a network interface is dumb and feeds
it the numbers it needs to tell it how to act.

>This assumes an
>assertion I made back in 1990: the day will come when almost all
>computers are powerful enough to maintain routing tables, not just
>routers. I think it is safe to say that that day has come.

You're a bit late. Mesh networks have been around for quite a while.
Ricochet/Metricom had routeing in the pole tops in 1986 with Utilnet.
Rooftop Networks and many others have done the same with Wi-Fi. The
entire basis of mesh networking is an intelligent routeing mechanism,
which is often distributed into the nodes (poletops). Nothing new
here. Your day has arrived about 20 years late.

--
# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
# 831-336-2558 jeffl@comix.santa-cruz.ca.us
# http://802.11junk.com jeffl@cruzio.com
# http://www.LearnByDestroying.com AE6KS