From: Nick Maclaren on

In article <4558e6f4$1(a)darkstar>, eugene(a)cse.ucsc.edu (Eugene Miya) writes:
|>
|> >This is getting boring. If you can provide evidence for the above claims,
|> >please do so.
|>
|> Gee Nick, that's commonly asked of you, and you never seem to provide either.

I do agree that I often don't respond to people who ask rudely, which
is why you have often not had a a response.

But, excluding that, why don't YOU provide evidence for YOUR claim?
You have been asked to do so often enough, and have never responded with
more than insults.


Regards,
Nick Maclaren.


From: Eugene Miya on
In article <ejc3ht$nn9$1(a)gemini.csx.cam.ac.uk>,
Nick Maclaren <nmm1(a)cus.cam.ac.uk> wrote:
>|> >This is getting boring. If you can provide evidence for the above claims,
>|> >please do so.

In article <4558e6f4$1(a)darkstar>, eugene(a)cse.ucsc.edu (Eugene Miya) writes:
>|> Gee Nick, that's commonly asked of you, and you never seem to provide either.
>
>I do agree that I often don't respond to people who ask rudely, which
>is why you have often not had a a response.

Zaldans do not like shallow expressions of courtesy.

Like I keep pointing out: it
It's not merely me but also Gombosi, desJardins, and others.

>But, excluding that, why don't YOU provide evidence for YOUR claim?

Sure I do. Easily grepped from old posts using refer (%[A-Z]).

>You have been asked to do so often enough, and have never responded with
>more than insults.

See prior sentence.
Your excuse now?

--
From: Terje Mathisen on
Nick Maclaren wrote:
> In article <4qq5elFof9pgU1(a)individual.net>,
> "Del Cecchi" <delcecchiofthenorth(a)gmail.com> writes:
> |> Performance can be provided. As the hot rodders say, performance costs
> |> money. How fast do you want to go?
>
> Yup. Fast, cheap, reliable. Pick any two.

Only in a perfect world: Often you're reduced to picking just one of
those. :-(

Terje
--
- <Terje.Mathisen(a)hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
From: Nick Maclaren on

In article <xdSdnZ_Ga_NiI_3YnZ2dnUVZ8tidnZ2d(a)giganews.com>,
Terje Mathisen <terje.mathisen(a)hda.hydro.com> writes:
|> Nick Maclaren wrote:
|> > In article <4qq5elFof9pgU1(a)individual.net>,
|> > "Del Cecchi" <delcecchiofthenorth(a)gmail.com> writes:
|>
|> > |> Performance can be provided. As the hot rodders say, performance costs
|> > |> money. How fast do you want to go?
|> >
|> > Yup. Fast, cheap, reliable. Pick any two.
|>
|> Only in a perfect world: Often you're reduced to picking just one of
|> those. :-(

Or even the best approximation to one that you can find :-(

But I have a great deal of sympathy for designers who are told that
their product must be fast, cheap, reliable, ready by tomorrow, with
specifications to be finalised next week. It is scarcely surprising
that the result usually fails on all its targets ....


Regards,
Nick Maclaren.
From: Anne & Lynn Wheeler on
eugene(a)cse.ucsc.edu (Eugene Miya) writes:
> Over lunch I did get the story of IBM's dumping of AI research in
> 1955-1956 from McCarthy (until the mid-80s). I wonder if it will
> appear in Wikipedia and history books? I think we want to go a
> little beyond the chewing gum walking stage. We can barely get a
> car to go 100 miles w/o a driver.

There was a development group in Menlo Park in the late 80s. I think
it grew to a couple hundred people and some number of people from
Stanford worked/consulted there.

My vague recollection was that the whole thing was eventually shutdown
.... again it is from fading memory, but I believe the reason was over
patent issues.

old email from somebody in the menlo park knowlege based group.

To: wheeler
Date: 16 February 1988, 13:33:42 PST

Lynn,

I am looking for pathlength guidelines for the interactive frontend
(scrolling, window moving etc) for the knowledge based systems
project. We currently think the pathlength for a scrolling operation
may be as much as 40-50K instructions, and are concerned that will
result in very sluggish operation on what we assume will be a loaded
system (the knowledge processing itself should be compute bound and
non-interactive.) Do you have any rules of thumb I can pass on to our
developers?

Thanks for your help,

.... snip ...

While the mvs/vtam pathlength may have been on that order ... the VM
issue was different (the actual scroll pathlength was significantly
less). A terminal I/O would have "boosted" the processing into the
"interactive" queue ... where it would get around 100K instruction
execution.

The long ago, original CP67 scheduler ... and the initial VM370
schedulers ... would just give absolute interactive priority "boost".

The fair share scheduler that I did as an undergraduate in the 60s for
CP67 would change the granularity of the execution bursts based on
interactive or background gueue ... however, the actual priority was
based on recent resource utilization vis-a-vis target (the scheduler
label came because the default "target" was fair share) ... aka a
particular process's execution rate would be based on competition for
the processor.

This was later re-introduced as the Resource Manager product for
vm370.
http://www.garlic.com/~lynn/subtopic.html#fairshare
which also included a bunch of other features related to performance,
like paging
http://www.garlic.com/~lynn/subtopic.html#wsclock

for some completely other drift ... the 23jun69 "unbundling"
announcement started charging for application software (somewhat in
response to various litigatioin by the gov. and others). however, the
system/kernel software was still free ... based on the argument that
it was required as part of operating the hardware (which the customer
would have already paid for).

however, by the time it came along to release my resource manager ...
attitudes was starting to change ... in part because of clone
processors being able to take advantage of free kernel software. the
resource manager was chosen to be the guinea pig for kernel software
charging. misc. past posts mentioning unbundling and starting to
charge for kernel software
http://www.garlic.com/~lynn/subtopic.html#unbundle

and for something completely different:

II03052: RERUN MAY CAUSE THE TERMINAL TO HANG WHEN USING A VCNA TERMINAL ON VM.
http://www-1.ibm.com/support/docview.wss?uid=isg1II03052

the Resource Manager actually had a bunch of (other) code having to
do with reliability and eliminating all known cases of hung/zombie
users .... some related posts here having to do with stress testing
of the Resource Manager in preparation for product ship
http://www.garlic.com/~lynn/subtopic.html#bench

however, various later kernel work introduced new hanging problems.

actually there was some amount of work involving Sowa (when he was at
IBM) and semantic networks in the 70s.
http://www.jfsowa.com/

and for other drift ... a page by sowa referencing john boyd
http://www.jfsowa.com/talks/challenge.htm

and then of course some number of past boyd posts
http://www.garlic.com/~lynn/subboyd.html#boyd
and various other boyd URLs from around the web
http://www.garlic.com/~lynn/subboyd.html#boyd2