| Author |
Message |
Nick Maclaren
Guest
|
 Posted:
Tue Oct 04, 2005 12:15 am Post subject:
Re: Intel strikes back with a parallel x86 design |
|
|
In article <XMg0f.155$AY4.48@newssvr24.news.prodigy.net>,
Bill Davidsen <davidsen@deathstar.prodigy.com> wrote:
| Quote: |
I didn't mention it, because it wasn't relevant. Back in the days
of the 80386, no serious company used an IBM PC for that! Intel's
second success was breaking into that market, but that came after
the PowerPC had failed.
Clearly the market was small, but actually the lowly XT, running UNIX
(PC/IX) was able to support a small office very well, far better than
the Z80 M/PM systems I was selling in the 70's ;-)
|
Well, the one I used lost characters because it couldn't keep up
with a two-fingered typist - but you may reasonably blame Willy G.
for that :-)
My main point about serious companies not touching those things for
the sales, inventory, payroll etc. wasn't the performance but the
reliability. The early IBM PCs had virtually no error checking,
and were very prone to giving wrong answers with no diagnostics.
Regards,
Nick Maclaren. |
|
| Back to top |
|
 |
Colonel Forbin
Guest
|
| Posted:
Tue Oct 04, 2005 12:15 am Post subject:
Re: Intel strikes back with a parallel x86 design |
|
|
In article <m3irwezl5e.fsf@lhwlinux.garlic.com>,
Anne & Lynn Wheeler <lynn@garlic.com> wrote:
| Quote: |
"gerard46" <gerard46@rtt.net> writes:
After ten years of mediocore response time, I suppose anybody can
get used to anything. But once you get on a system with subsecond
response times (say, 1/3 second), anything over a second seems long,
and when it gets over two seconds, it seems intolerable. It all
boils down to what you get used
to. _______________________________________________Gerard S.
there was actually a study about human factors and response time
... and unpredictable response time turned out to be a significant
factor ... if people got use to 2 second response time ... they would
change their behavior to accomodate the infrastructure. however, if
there was significant variability between 1 second and 3-4 seconds,
they might do something based on expecting 1 second ... and then have
to wait until it was really ready. this degraded human performance by
a factor of twice the difference between the expected and the actual.
|
This is something I went to great lengths to engineer around at a former
place of employment. These folk had been victims of what seems to have
been a kickback scheme between high level executives and a sleazy VAR
which left them with having paid list price for a bunch of already
obsolete HP PA-RISC gear which had every expansion slot stuffed the day
it rolled in the door. This was to support SAP R/3 SD and similar work.
In the mean time, the company went through a series of mergers and
acquisitions which escalated the user base by a factor of four above
the design target for the hardware.
Naturally, replacing "new" hardware was not a popular topic, yet the
company was bleeding profit both from inability to process the workload
as well as losing top sales personnel who were frustrated by the inability
to invoice sales in a timely and efficient fashion.
In addition to optimizing the load balance of a RAID storage solution,
I dissected the kernels of Oracle and SAP R/3 and used the HP-UX realtime
scheduler class to force preemption of user processes by important parts
of the applications kernels.
This changed the interactive behavior of the system from a "bursty"
unpredictable response time for transactions caused by deadlocks to a
smooth decay of response time which still delivered slightly subsecond
response with four times the design workload, at a Unix load average of
around 27 on a 4-way database server. The end result was predictable
latency barely within SAP best practices guidelines.
This permitted the company to continue operations while contemplating
what course of action to take. I proposed two options, either a high
RAS hardware upgrade from a different vendor, or simply service outsourcing
the whole mess. Unfortunately, I ended up leaving shortly of my
own volition after top management refused to end their love affair
with the VAR who sold them this junk at full list (remember how inflated
HP's list prices used to be). |
|
| Back to top |
|
|
Del Cecchi
Guest
|
| Posted:
Tue Oct 04, 2005 5:21 am Post subject:
Re: Intel strikes back with a parallel x86 design |
|
|
"Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message
news:dhsb48$362$1@gemini.csx.cam.ac.uk...
snip
| Quote: |
My main point about serious companies not touching those things for
the sales, inventory, payroll etc. wasn't the performance but the
reliability. The early IBM PCs had virtually no error checking,
and were very prone to giving wrong answers with no diagnostics.
Regards,
Nick Maclaren.
|
In contrast to the current PC desktop and laptop machines which have
.........virtually no error checking or diagnostics. But people love them
anyway. RAS is apparently over rated :-(
del |
|
| Back to top |
|
|
Nick Maclaren
Guest
|
| Posted:
Tue Oct 04, 2005 1:32 pm Post subject:
Re: Intel strikes back with a parallel x86 design |
|
|
In article <3qe081FecdthU1@individual.net>,
Del Cecchi <dcecchi.nospam@att.net> wrote:
| Quote: |
"Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message
news:dhsb48$362$1@gemini.csx.cam.ac.uk...
My main point about serious companies not touching those things for
the sales, inventory, payroll etc. wasn't the performance but the
reliability. The early IBM PCs had virtually no error checking,
and were very prone to giving wrong answers with no diagnostics.
In contrast to the current PC desktop and laptop machines which have
........virtually no error checking or diagnostics. But people love them
anyway. RAS is apparently over rated :-(
|
Very true. But even my employer doesn't run its payroll software on
such systems, and I rather suspect yours doesn't, either :-)
I fully agree that few companies analyse the potential for data
corruption and loss as the information passes through the 'desktop'
systems. But the context was in that of the business/commercial
market, which is what senior managers perceive it to be.
Regards,
Nick Maclaren. |
|
| Back to top |
|
|
Nick Maclaren
Guest
|
| Posted:
Tue Oct 04, 2005 4:15 pm Post subject:
Re: Intel strikes back with a parallel x86 design |
|
|
In article <PQw0f.1436$xD7.592@newssvr29.news.prodigy.net>,
Robert Redelmeier <redelm@ev1.net.invalid> writes:
|> In comp.sys.ibm.pc.hardware.chips Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:
|> > Yes, but that is in response to relatively coarse interactions,
|> > such as individual commands. A 100 millisecond delay on
|> > character deletion is a real pain, and it makes many GUI
|> > operations (such as drag to position) extremely stressful
|> > and slow. With such things, the maximum delay you can tolerate
|> > without irritation is down in the 10-20 millisecond range.
|>
|> I've found long feedback delays (multi-second) are perfectly
|> acceptable so long as they occur when the human can confidently
|> type-ahead or is satisfied to wait (complex command executing).
|>
|> Delays become irritating when the visual feedback is required
|> (another cursor keypress?) especially when they are inexplicable.
Precisely, on both counts. A 3 second delay between complex
commands is vastly less irritating than a 0.1 second delay between
characters or in responding to a cursor drag.
|> > This is one reason that I stick with the Bourne shell in
|> > Unix; it is the only one that uses cooked mode, and therefore
|> > line building is done in the kernel. From choice, I use an
|> > environment where it is done locally (i.e. on my desktop or
|> > equivalent) when executing commands obeyed on a remove system.
|>
|> I do not believe SSH has any such line-by-line protocol
|> as TELNET does.
No, and I wish that it did. However, I mean to investigate why
it works as well as it does, some day when I have plenty of time.
But you can still build lines locally and execute them remotely
when writing scripts that use SSH.
Regards,
Nick Maclaren. |
|
| Back to top |
|
|
Edward Wolfgram
Guest
|
| Posted:
Tue Oct 04, 2005 4:15 pm Post subject:
Re: Intel strikes back with a parallel x86 design |
|
|
Anne & Lynn Wheeler wrote:
| Quote: | there are lots of jokes among customers about TSO being too slow to
use for interactive (even some recent threads in ibm-mainframe group).
basically TSO was slightly better than using a keypunch.
when we were arguing with product group about being able have
subsecond response with the new 3274 display control units ...
effectively TSO came down on the side of the 3274 group ... since they
never had subsecond response ... even with the faster 3272 controller.
Basically 3274 group defined their target market (what is cause and
what is effect?) as data entry (previously done on keypunches) which
don't have any issues with system performance and response.
reference to old report with numbers comparing 3277 & 3274:
http://www.garlic.com/~lynn/2001m.html#19 3270 protocol
from above:
hardware TSO 1sec. CMS .25sec. CMS .11sec
3272/3277 .086 1.086 .336 .196
3274/3278 .530 1.530 .78 .64
...
|
Tsk tsk. Really, this TSO bashing has got to stop. Uninformed lurkers
here will think there is something wrong with TSO, and by extension,
perhaps even MVS and mainframes!
There is absolutely nothing structurally inherent in TSO that makes bad
response time inevitable. There is nothing hard about providing
subsecond response time under TSO: I've experienced- and designed-
systems and applications with subsecond response time under TSO for more
than a quarter century. I've also experienced (heh heh) horrendous TSO
response time (as well as horrendous response time on CMS and VMS and PC
and UNIX....).
That said, response time under TSO, especially in wide area network
(SNA) configurations, will have a great number of components any one of
which can contribute to poor response time. Not least among them are the
tuning parameters for the communications controllers and the TSO
subsystem itself under MVS.
Perhaps Lynn's anecdote concerns hardware and software components that
have fatal flaws that predate my experience, but I think that's highly
unlikely.
Edward Wolfgram
(resp limited to comp.arch) |
|
| Back to top |
|
|
Robert Redelmeier
Guest
|
| Posted:
Tue Oct 04, 2005 4:15 pm Post subject:
Re: Intel strikes back with a parallel x86 design |
|
|
In comp.sys.ibm.pc.hardware.chips Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:
| Quote: | Yes, but that is in response to relatively coarse interactions,
such as individual commands. A 100 millisecond delay on
character deletion is a real pain, and it makes many GUI
operations (such as drag to position) extremely stressful
and slow. With such things, the maximum delay you can tolerate
without irritation is down in the 10-20 millisecond range.
|
I've found long feedback delays (multi-second) are perfectly
acceptable so long as they occur when the human can confidently
type-ahead or is satisfied to wait (complex command executing).
Delays become irritating when the visual feedback is required
(another cursor keypress?) especially when they are inexplicable.
| Quote: | This is one reason that I stick with the Bourne shell in
Unix; it is the only one that uses cooked mode, and therefore
line building is done in the kernel. From choice, I use an
environment where it is done locally (i.e. on my desktop or
equivalent) when executing commands obeyed on a remove system.
|
I do not believe SSH has any such line-by-line protocol
as TELNET does.
-- Robert |
|
| Back to top |
|
|
Nick Maclaren
Guest
|
| Posted:
Tue Oct 04, 2005 4:15 pm Post subject:
Re: Intel strikes back with a parallel x86 design |
|
|
In article <43429df6$1@ibixwebf.ibi.com>,
Edward Wolfgram <Edward_Wolfgram@ibi.com> writes:
|>
|> Tsk tsk. Really, this TSO bashing has got to stop. Uninformed lurkers
|> here will think there is something wrong with TSO, and by extension,
|> perhaps even MVS and mainframes!
:-)
|> There is absolutely nothing structurally inherent in TSO that makes bad
|> response time inevitable. There is nothing hard about providing
|> subsecond response time under TSO: I've experienced- and designed-
|> systems and applications with subsecond response time under TSO for more
|> than a quarter century. I've also experienced (heh heh) horrendous TSO
|> response time (as well as horrendous response time on CMS and VMS and PC
|> and UNIX....).
Actually, yes, there was - in its original MVT incarnation. You
could create multiple TSO 'slots', but no TSO session could change
slot and only one could be swapped in at once in a slot. If one
session did something slow, such as heavy I/O or (worse) calling
privileged code that did heavy I/O or waited on something even
slower (e.g. WTOR), all users with sessions in that slot had to wait
until it finished.
|> That said, response time under TSO, especially in wide area network
|> (SNA) configurations, will have a great number of components any one of
|> which can contribute to poor response time. Not least among them are the
|> tuning parameters for the communications controllers and the TSO
|> subsystem itself under MVS.
We actually got pretty good response, even under MVT, by such tuning.
But we had to lock out many types of use and threaten users with
orchidectomy if they used certain facilities - of the sort that caused
the trouble I mentioned above.
|> Perhaps Lynn's anecdote concerns hardware and software components that
|> have fatal flaws that predate my experience, but I think that's highly
|> unlikely.
Try a 370/165 and MVT 20.6 :-)
Regards,
Nick Maclaren. |
|
| Back to top |
|
|
Robert Redelmeier
Guest
|
| Posted:
Tue Oct 04, 2005 9:36 pm Post subject:
Re: Intel strikes back with a parallel x86 design |
|
|
In comp.sys.ibm.pc.hardware.chips Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:
| Quote: | No, and I wish that it did. However, I mean to investigate why
it works as well as it does, some day when I have plenty of time.
|
SSH does work remarkably well. Perhaps not better than TELNET.
I see a couple of good reasons: short packets often have
lower latency (explore with ping). A good host OS will give
SSH priority (Linux credits processes it deems "interactive",
and also unblocks processeses immediately).
| Quote: | But you can still build lines locally and execute
them remotely when writing scripts that use SSH.
|
Or cut-n-paste using `gpm`.
-- Robert |
|
| Back to top |
|
|
Guest
|
| Posted:
Tue Oct 04, 2005 9:58 pm Post subject:
Re: Intel strikes back with a parallel x86 design |
|
|
keith <krw@att.bizzzz> writes:
| Quote: | On Fri, 30 Sep 2005 08:42:06 -0500, MSCHAEF.COM wrote:
In article <5odqj15j2orkbduu9hb6jvofbl4rg5jn66@4ax.com>,
chrisv <chrisv@nospam.invalid> wrote:
Nick Maclaren wrote:
A question for all you omniscient ones out there - what were the
worst computers of all time?
Coleco Adam?
Apple ///?
Lisa?
|
The Lisa was only ever a `proof of concept' machine for the `new one'
that was to follow, what we know as the Mac.
--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
comp.os.vms,- The Older, Grumpier Slashdot
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be. |
|
| Back to top |
|
|
Anne & Lynn Wheeler
Guest
|
| Posted:
Tue Oct 04, 2005 11:08 pm Post subject:
Re: Intel strikes back with a parallel x86 design |
|
|
Edward Wolfgram <Edward_Wolfgram@ibi.com> writes:
| Quote: | Tsk tsk. Really, this TSO bashing has got to stop. Uninformed lurkers
here will think there is something wrong with TSO, and by extension,
perhaps even MVS and mainframes!
|
it didn't start out to be TSO bashing ... the long wandering thread
sort of started out that terminal emulation contributed to some
signifcant product uptake for the ibm/pc ... but later, efforts to
protect the installed terminal emulation business contributed
significantly to opposing moving on to better solutions
http://www.garlic.com/~lynn/subnetwork.html#emulation
that SAA was part of the effort to help circle the wagons around the
installed terminal emulation business ... attempting to stuff the
client/server genii back into the bottle. we caused them heartburn at
the time ... out doing customer executive presentations on 3-tier
architecture
http://www.garlic.com/~lynn/subtopic.html#3tier
the 3274/3278 ref. was going back to some pre-ibmpc history (of the
communication division). there had been some hardware hacks to the
(3272/)3277 terminal ... that made it almost tolerable for interactive
computing. the 3274/3278 was a regression from the basic 3272/3277
.... and because they moved a lot of the electronics (that had been in
the 3277 terminal) back into the 3274 controller (cutting down on 3278
manufactoring costs), it made similar hardware hacks to the 3278
impossible.
complaining about how poor the 3274/3278 was for interactive computing
.... got us a response back from the product group ... that the
3274/3278 wasn't intended for the interactive computing market segment
.... it was for the data entry market segment ... and was better than
keypunches. The TSO product group came down on the 3274/3278 side
.... effectively taking the position that TSO had never been intended
for the interactive computing market segment and/or never been
intended to have better than 1 second response (and that was for
strictly non-SNA, local, channel attached controllers).
that doesn't mean you couldn't do some tweaks and control the
environment to improve on TSO operation ... but it was trying to use
it for something that it was intended for.
in the 1980 time-frame the standard TSO design-point was so well known
.... that startups could get VC money for 3274-clones that did TSO
offload ... attempting to provide a reasonably tolerable human
interfacw where TSO was involved (by pre-handling some interactions in
the 3274 controller clone ... as opposed to going all the way back to
TSO).
now, up until about mid-85 ... the internal network was larger than
the arpanet/internet ... from just about the beginning ...
http://www.garlic.com/~lynn/subnetwork.html#internalnet
and the majority were non-MVS for various reasons ... in part because
internal development made extensive use of non-MVS interactive
computing ... even when MVS related development was involved (so a
preponderance of internal systems were non-MVS). Another was that
nearly all of the internal MVS systems were built with JES2 ... and
used JES2 for MVS networking support ... and JES2 networking support
had enormous limitations. a few, somewhat related postings
http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005q.html#0 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005q.html#7 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005q.html#15 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005q.html#16 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005q.html#19 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005q.html#30 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005q.html#32 HASP/ASP JES/JES2/JES3
as an aside ... as an undergraduate ... I had modified an MVT/HASP
system ... incorporating 2741 & TTY support into HASP and implementing
HASP interactive interface ... borrowing CMS editor syntax for part of
the design. This provided a lot of TSO-like functionality for doing
program creation and submission. lots of past posts mention all sorts
of HASP references
http://www.garlic.com/~lynn/subtopic.html#hasp
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ |
|
| Back to top |
|
|
Klaus Fehrle
Guest
|
| Posted:
Wed Oct 05, 2005 3:51 pm Post subject:
Re: Intel strikes back with a parallel x86 design |
|
|
Bernd Paysan schrieb:
| Quote: | Jim Brooks wrote:
AMD has only a fraction of the resources that Intel has,
so AMD will have a hard time catching up
Under the assumption that having more resources makes you faster. Another
Brooks (Fred) thought differently. There's a lower limit of a project to
finish, depending only on the number of people involved (not on the
inherent complexity - maybe an overstaffed team can complete before by
delivering a skunkwork project instead of the planned one). The complexity
only gets exposed when you have an understaffed team (and even then, half
the people doesn't mean twice the time).
Read in isolation, the comment makes as much sense as saying "these guys
from Kenia have only a tiny fraction of the resources all the first world
people have, they'll have a hard time to catch up on the New York city
marathon." If you look at the list
(http://www.mistupid.com/sports/nymarathon.htm), you'll see that since
1982, no US American won, and for the last decade, Kenia has five wins out
of ten.
To do a job in a short time, three things are necessary:
* Excellence (If you can't run, you can't win)
* The necessary resources (You can win the NYC marathon bare foot - it has
been done - but sneakers help)
* Knowing the direction (If you get lost on the way, you'll never win)
The last item may be least important for the NYC marathon, but it's most
important for chip development. And here, despite of the resources, Intel
is years behind AMD.
While I like this analogy and agree in most of what you say, I suggest a |
different understanding of the latter: Staying in the picture, I see
AMDs runner winning the laurel wreath and gold-medal long before I see
Intels runner arriving - just in time before the bank closes to deposit
what he carried all the way in a large bagpack - laughing, you know. :-)
K. |
|
| Back to top |
|
|
Maynard Handley
Guest
|
| Posted:
Thu Oct 06, 2005 12:15 am Post subject:
Re: Intel strikes back with a parallel x86 design |
|
|
In article <87hdbxxlr1.fsf@prep.synonet.com>, prep@prep.synonet.com
wrote:
| Quote: | keith <krw@att.bizzzz> writes:
On Fri, 30 Sep 2005 08:42:06 -0500, MSCHAEF.COM wrote:
In article <5odqj15j2orkbduu9hb6jvofbl4rg5jn66@4ax.com>,
chrisv <chrisv@nospam.invalid> wrote:
Nick Maclaren wrote:
A question for all you omniscient ones out there - what were the
worst computers of all time?
Coleco Adam?
Apple ///?
Lisa?
The Lisa was only ever a `proof of concept' machine for the `new one'
that was to follow, what we know as the Mac.
|
That was the way it played out, but that was not the official corporate
strategy. |
|
| Back to top |
|
|
keith
Guest
|
| Posted:
Thu Oct 06, 2005 7:18 am Post subject:
Re: Intel strikes back with a parallel x86 design |
|
|
On Mon, 03 Oct 2005 00:12:11 -0400, George Macdonald wrote:
| Quote: | On Sat, 01 Oct 2005 11:02:48 -0400, keith <krw@att.bizzzz> wrote:
On Fri, 30 Sep 2005 17:45:43 -0400, George Macdonald wrote:
On 29 Sep 2005 11:50:02 GMT, nmm1@cus.cam.ac.uk (Nick Maclaren) wrote:
In article <vb6mj1l5h6oqrm90dfibkl0lmi3o2f3h0s@4ax.com>,
George Macdonald <fammacd=!SPAM^nothanks@tellurian.com> wrote:
snip
Sigh. The distinction I was using is the one that was used at the
time by IBM, Intel and others - and to a great extent still is.
"Business/commercial" (or "commercial", for short) includes everything
that is used in most offices etc. The fact that a lot of that was used
in academia longer before and still is (e.g. Email, text processing)
seems to have escaped the marketdroids and bean counters.
"Scientific/technical" includes most conventional programming, as well
as applications like Spice. It was and is regarded as much less
important by the marketdroids and bean counters, partly because it was
and is a much smaller market.
Grunt. I'm afraid your pigeon-holes are much too highly delineated - the
results are obvious. While there are marketroids who have to think in such
terms, fortunately their policies get bypassed by people who know better
and there are users who appreciate the lateral thinking. Besides that
distinction is not really that important in terms of whether the 68K,
PowerPC or whatever was competent/competitive to go up against the 386/486
in the market.
The fact of the matter (whether you like it or not) is that Intel
established itself as the chip maker for the IBM PC, which was never
intended by IBM to be used as much more than a programmable terminal.
You can presume whether I like something or not; that was a minor time
slice in the PC evolution. It did not take long for even IBM to get the
msg that a 327x was not going to hack it for the "user experience" in the
brave new world of spreadsheets, word processing and... graphics, which IBM
did not even make a PC card/monitor for to begin with.
While I agree with your sentement, there wasn't any lack of a graphics
card. The CGA card and monitor were announced and shipped with the 5150.
I had a CGA card (couldn't afford the monitor) on my "first day order"
5150. ...along with the monochrome card and monitor.
Oh come on - CGA? Most folks got a Hercules monochrome card for business
use from what I saw... until EGA came along.
|
I don't know where some of my posts have gone....
Yes, CGA. There was no "Hercules" when the PC came out. At a month's
salary (perhaps a tad more) the other half wasn't too much interested in
investing more either. Though she and her dad did ratehr like Adventure.
;-)
My brother went with a Herc, but that was a year or so later (he grabbed
my employee discount and then added the Herc for the second monitor).
We've had dual monitors longer than people thougt it was possible. ;-)
| Quote: | OTOH, contrary to Nick's point, the 5150s did not ship with a 3270
emulator card. Those came later (IIRC IBM wasn't even first), as it
became obvious the PC was a better and cheaper 3270. Saying that the
The PC was originally intended to be a 3270 replacement is "new
history", at best.
Did what I said come out sounding like that?... sorry.
|
Nope. It was just part of the conversation (note the "OTOH" part).
<snip>
| Quote: | It was supposed to be. ;-) Remember, RISC was the savior, CISC was
dead-end. Oops.
There *had* been some horrible CISC machines when that was in fashion.:-)
|
Like x86 and /370? ;-)
--
Keith |
|
| Back to top |
|
|
keith
Guest
|
| Posted:
Thu Oct 06, 2005 7:19 am Post subject:
Re: Intel strikes back with a parallel x86 design |
|
|
On Wed, 05 Oct 2005 00:58:10 +0800, prep wrote:
| Quote: | keith <krw@att.bizzzz> writes:
On Fri, 30 Sep 2005 08:42:06 -0500, MSCHAEF.COM wrote:
In article <5odqj15j2orkbduu9hb6jvofbl4rg5jn66@4ax.com>,
chrisv <chrisv@nospam.invalid> wrote:
Nick Maclaren wrote:
A question for all you omniscient ones out there - what were the
worst computers of all time?
Coleco Adam?
Apple ///?
Lisa?
The Lisa was only ever a `proof of concept' machine for the `new one'
that was to follow, what we know as the Mac.
|
More revisionist history.
--
Keith |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in