List of Archived Posts

2004 Newsgroup Postings (08/21 - 09/04)

Correction to Univac 494 description on web site

Losing colonies

Linguistic Determinism

Correction to Univac 494 description on web site

Correction to Univac 494 description on web site

Losing colonies

Losing colonies

A quote from Crypto-Gram

FAST TCP makes dialup faster than broadband?

FAST TCP makes dialup faster than broadband?

Losing colonies

Losing colonies

FAST TCP makes dialup faster than broadband?

FAST TCP makes dialup faster than broadband?

I am an ageing techy, expert on everything. Let me explain the

I am an ageing techy, expert on everything. Let me explain the

FAST TCP makes dialup faster than broadband?

FAST TCP makes dialup faster than broadband?

FAST TCP makes dialup faster than broadband?

FAST TCP makes dialup faster than broadband?

Vintage computers are better than modern crap !

Vintage computers are better than modern crap !

Public key authentication defeats passwd age warning

US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of

Timeless Classics of Software Engineering

Timeless Classics of Software Engineering

Timeless Classics of Software Engineering

Vintage computers are better than modern crap !

Vintage computers are better than modern crap !

CDC STAR-100

Internet turns 35, still work in progress

capacity planning: art, science or magic?

Frontiernet insists on being my firewall

US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of

August 23, 1957

Big Bertha Thing blogs

Vintage computers are better than modern crap !

Wars against bad things

Adventure

August 23, 1957

Vintage computers are better than modern crap !

Vintage computers are better than modern crap !

65nm news from Intel

Vintage computers are better than modern crap !

Wars against bad things

August 23, 1957

Xah Lee's Unixism

Xah Lee's Unixism

Xah Lee's Unixism

Xah Lee's Unixism

Xah Lee's Unixism

Xah Lee's Unixism

slashdot drift on 360 clone by rca

US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of

Xah Lee's Unixism

Losing colonies

Xah Lee's Unixism

US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of

Xah Lee's Unixism

IBM 360

Xah Lee's Unixism

Xah Lee's Unixism

Xah Lee's Unixism

Xah Lee's Unixism

Xah Lee's Unixism

Xah Lee's Unixism

Question About VM List

Correction to Univac 494 description on web site

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Correction to Univac 494 description on web site
Newsgroups: alt.folklore.computers
Date: Sat, 21 Aug 2004 16:21:04 -0600

jsavard@excxn.aNOSPAMb.cdn.invalid (John Savard) writes:

But I also do remember that, when speaking about the Cray-1, Seymour
Cray was quoted as saying - to applause - that although he finally
surrendered and switched to a 64 bit word from the 60 bit word of
the 6600, he still had the computer's software use octal notation,
rather than hexadecimal, when displaying binary information was
called for.

Thus, there apparently was some desire not to march to IBM's drum...

wasn't there something about that was all the bits there were ... no
parity at all and ibm had 9bit bytes ... 8bit data plus parity bit

later sometime late '80s, i have some recollection of reading the
mainframes using 64+16 ecc (detect 16 bit errors, correct 15 bit
errors) ... instead of 8+1 (detect 1 bit errors)

... aka what you see, isn't necessarily all there is.

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

Losing colonies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Losing colonies
Newsgroups: alt.folklore.computers
Date: Sat, 21 Aug 2004 17:59:26 -0600

Giles Todd writes:

The ability to solve problems is not constrained by language (e.g.
psychologists challenge rats to solve problems and the rats
frequently succeed, but not even a psychologist would claim that
rats can speak).  If you suggest that it is then you also need to
deal with all the contradictions (some of which I have already
suggested in previous posts) that such a hypothesis imposes.

... however, one could claim that the ability to solve problems may be
constrained by knowledge (say give a post-doc sub-atomic particle
problem to kindergarten kids).

so what, if any portion of knowledge in specific domains, have some
language aspect i.e. language being one of the tools for representing
knowledge; aka would the incremental difficulty of implementing an
array oriented problem in assembler vis-a-vis APL ... result in lower
percentage of assembler people correctly solving the problem
(especially if the assembler people had never been exposed to array
oriented problems in the past).

so there is some assertions in non-knowledge oriented domain spaces
that correct and/or appropriate tools can improve the quality of work.
in the programming field ... programming languages frequently
represent the domain solving tools. is it impossible for people to not
solve problems with really inappropriate tools ... and is language a
tool

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

Linguistic Determinism

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Linguistic Determinism
Newsgroups: alt.folklore.computers
Date: Sun, 22 Aug 2004 10:44:49 -0600

jsavard@excxn.aNOSPAMb.cdn.invalid (John Savard) writes:

The problem, therefore, is not that the Whorf-Sapir hypothesis is absurd
on its face - yes, language does influence how one thinks, and the first
solution one may attempt for a problem. But if that attempted solution
doesn't work, people can still manage to break out of the box, and learn
new concepts from Nature. Instead, the trouble is that it is being used
to argue for discarding what is obviously not that badly broken.

so that seems to be that (capital) L-D doesn't allow for knowledge
outside of learned language ... which then concludes that language
can't evolve(?); which in turn would imply that going back enuf years
into history ... before language ... it wouldn't have been possible to
evolve from a non-language state to a language state(?)

the issue from my original post was can specific computer language
influence how one handles complex tasks (as well as the quality of any
solutions) .... say a lower case l-d ... rather than upper case L-D.

... for that matter any semanticly meaningful construct ... aid
in handling complex tasks ... and/or influence the quality of
handling complex tasks. at a much more fundamental level ...
i would assert that CAS's invention of compare&swap instruction
... at the cambridge science center
http://www.garlic.com/~lynn/subtopic.html#545tech
... was a much improved semantic construct for addressing
multiprocessor environments
http://www.garlic.com/~lynn/subtopic.html#smp

and back to my original assertion ... the semantic construct(s)
related to implicit lengths in conventional c-programming has
significantly affected the quality of c-based solutions
... specifically in large part responsible for the enormous increase
in buffer overflow related exploits.

so can we evolve the language ... and given the adverse connotation of
upper case L-D ... coin a term that connotes the influence that
language quality/features has on ability and quality of (possibly
domain-specific) problem solving.

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

Correction to Univac 494 description on web site

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Correction to Univac 494 description on web site
Newsgroups: alt.folklore.computers
Date: Sun, 22 Aug 2004 11:28:56 -0600

jsavard@excxn.aNOSPAMb.cdn.invalid (John Savard) writes:

Well, IBM mainframes switched from using 8+1 to using 64+8, and this
allowed correcting 1 bit errors and detecting 2 bit errors, because
it provided a Hamming distance of 4 between valid
symbols. Present-day home microcomputers can use this kind of error
correction as well with ECC RAM modules, or they can do without,
IIRC.

did try search engine for my vaguely remembered mainframe memory
reference (64/80 ... the 8/10 ecc ratio scaled directly to 64bits)

didn't find what i vaguely remember ... but found two from ibm
reserach ... one from 2002 describing memory (140, 128) ecc
... 128bits data, 12 error correcting code; and earlier one describing
(76, 64) and mentioning (78, 64) ... 64bits data and either 12 or 14
bits of error correcting. the latest generation of memory appears to
have doubled the error correcting memory unit from 64bits to 128bits
... while keeping the amount of error correctings bits at 12.

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

Correction to Univac 494 description on web site

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Correction to Univac 494 description on web site
Newsgroups: alt.folklore.computers
Date: Sun, 22 Aug 2004 12:16:16 -0600

the artical mentions (76, 64) and (78, 64) and talkes about g1-g5,
this mentions four bit error correct (S4EC/DED)
http://www.research.ibm.com/journal/rd/435/spainhower.html

the article mentioning (140, 128) for z900
http://www.research.ibm.com/journal/rd/464/alves.html

... after this paragraph it talks about (144, 132) design.

The memory (L3) consists of up to four cards per server. Each card has
a memory controller. The memory card contains up to eight rows of 144
synchronous DRAM chips. Data is stored into one row at a time, two
bits per chip, and is organized as two 144-bit data words. To protect
the data, z900 uses a (140, 128) ECC with 128 data bits and 12 check
bits. The code corrects any single-bit failure as well as any
single-symbol failure (i.e., 2-bit failure within the same
chip). Therefore, if a DRAM is completely broken and the bits coming
from that chip are unpredictable, the hardware is able to correct the
bits and calculate the proper data without replacing the chip. If two
of the 72 DRAMs in the same row/same data word are broken, the ECC
logic is able to detect errors in the data fetched from these broken
chips. Since there are only 140 bits in an ECC data word and there are
144 bits in the bus, the four additional bits are stored in two spare
chips. These chips can be used to spare any two of the 70 chips
normally used for the data. There are up to 32 spare chips per card as
compared to four for G5/G6

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

Losing colonies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Losing colonies
Newsgroups: alt.folklore.computers
Date: Sun, 22 Aug 2004 13:59:32 -0600

another possible observation ... is that the majority of the
population tend to spend a lot of time within the context of 1) their
past experience and 2) the provided semantic tools ... and that the
invention of new semantics (like charlie's invention of compare&swap
for multiprocessor semantics) is not a frequent and everyday occurance
... although once invented ... it can be adopted by the rest of the
population ... making all participants more efficient.

in the buffer overflow case ... one hypothesis is whether the downside
costs of the great increase in buffer overflows significantly exceeds
any possibly cost benefit of having implicit length semantics.

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

Losing colonies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Losing colonies
Newsgroups: alt.folklore.computers
Date: Sun, 22 Aug 2004 16:47:52 -0600

somewhat additional drift for semantic meaning/knowledge .... from the
buffer overflow thread ... i mentioned looking at the cve database as
part of adding additional stuff to the worked i've done on merged
security taxonomy and glossary
http://www.garlic.com/~lynn/index.html#glosnote

specificallly from a different thread
http://www.garlic.com/~lynn/2004j.html#58 vintage computers are better than modern crap!

the same tool, i originally started using for maintaining information about
the IETF RFC documents and capturing rules about the IETF standards
process. i also use it for generating the rfc index
http://www.garlic.com/~lynn/rfcietff.htm

when i first started out with the rules stuff ... it identified a
whole slew of RFCs that were listed by STD1 as documenting something
in the standards process but also happened to have been
obsoleted. this information for a time was carried in section 6.10 of
std1 ... but as things were cleaned up ... was eventually dropped. i
still generate the information in the index:
http://www.garlic.com/~lynn/rfcietf.htm#obsol

for quite a while ... the obsoletes and updates information has been
carried as tagged information ... and in the knowledge tool i use ...
full bi-directional relationships are created .... so when i generate
the rfc index information .... the listing of which RFCs
obsolete/update other RFCs is generated along with the listing of
which RFCs are obsoletedby/updatedby is also generated.

several years ago ... a new tag was generated ... "See Also" .... which
was used originally primarily to reference RFCs that were part of
collections. Since that time, "See Also" tag seems to have changed to
being used primarily to reference other forms of an RFC ... i.e. STD
http://www.garlic.com/~lynn/rfcdoc.htm#STDdoc
BCP
http://www.garlic.com/~lynn/rfcdoc.htm#BCPdoc
FYI
http://www.garlic.com/~lynn/rfcdoc.htm#FYIdoc
and RTR
http://www.garlic.com/~lynn/rfcdoc.htm#RTRdoc

In theory, the original "See Also" was strictly symmetrical ... all
RFCs in a group/collection, all used See Also for all other RFCs in
the same  group/collection.

What I put off doing for a long time ... was writting some code that
scanned the contents of RFC files .... identifying the References
section and extracting the RFC reference information. References would
tend to be asymmetrical relationship ... RFCs would have a list of
RFCs that they Reference .... but in turn, RFCs would also have a list
of RFCs that they were ReferencedBy.

So last week .... somebody at Crypto 2004 (where they had papers and
lots of discussions about MD5 and other hashing exploits) asked me if
i had a dependency tree of RFCs related to MD5. I didn't, but I
quickly created a summary list of all RFCs that mention MD5 ....
http://www.garlic.com/~lynn/2004j.html#56 RFCs that reference MD5

and then started on some awk scripts to scan RFCs ... attempting to
recognize "References" sections .... and extracting from those
sections ... references to other RFCs. the scripts are in some amount
of flux because there are some number of special cases

Another issue is that the original (symmetric) "See Also" semantics
hasn't been consistently followed ... to tie-together RFC
group/clusters .... and RFCs frequently just reference each other
using the asymmetrical References/ReferencedBy relationship.

For MD5 specifically, it gets more convoluted since the early MD5 RFC
(1321) is informational and some subsequent standards process RFCs may
or may not reference the RFC (even tho they reference MD5 in the body
of the RFC). So now there is

1) keyword listing ... i.e. at
http://www.garlic.com/~lynn/rfcietff.htm
and select Term (term->RFC#) in the RFCs listed by section and
then "MD5" in the Acronym fastpath. That gives the list of RFCs
that had "md2", "md4", "md5", and/or "message digest" in the RFC title
and/or the RFC abstract.

2) the list of all RFCs that condtain the characters "md5" anywhere

3) the summary for RFC 1321 which lists all RFCs that it is referenced
by (some, but not all of the RFCs that mention MD5 ... list 1321 in
the reference list, for example rfc 2440, OpenPGP doesn't list 1321 as
a reference).

And for another twist ... there is a recent collection of RFCs on
S/Mime, CMS, and some other security issues; 3850, 3851, 3852, 3853,
3854, 3855, 3859, 3860, 3861, 3862 and 3863
http://www.garlic.com/~lynn/rfcidx12.htm

3852 obsoletes 3369; 3852 also references 3851

3853 references 3369 (obsoleted by 3852) and 3851 (but doesn't
reference 3852 which obsoletes 3369)

3859 and 3860 references 3852

3851 and 3850 reference each other ... which in theory would imply a
"See Also" symmetrical relationship.

=======

so an obvious rule ... would be to convert situations where two RFCs
mutually reference each other ... from a References/ReferencedBy
asymmetrical relationship to a SeeAlso symmetrical
relationship. Similarly to 3850/3851 mutual referencing ... also
1320/1321 mutually reference (i.e. 1321/md5 references 1320/md4 and
1320/md4 references 1321/md5).

a less obvious rule would involve converting References to an
obsoleted RFC ... to the RFC that obsoleted it.

and to the question from crypto 2004 last week .... other than RFCs
that have the string "md5" ... there are no obvious list of IETF
standards that are dependent on MD5 (which might need reviewing based on
talks/papers at last weeks crypto 2004).

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

A quote from Crypto-Gram

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A quote from Crypto-Gram
Newsgroups: sci.crypt
Date: Sun, 22 Aug 2004 17:54:04 -0600

"Stephen Sprunk" writes:

Why?  Intel has the same feature, much more conveniently documented
for those who wish to abuse the feature.  People have also hacked
Transmeta's code morphing engine, and that is much easier to abuse.
I wouldn't be surprised if VIA and others producing mass-market
chips didn't have the same mechanism as AMD and Intel.

You're screwed no matter who you buy from.

aka introduce "copy" chip into gray market channels ... that has
somewhat the look and feel of more familiar chip ... but w/o any of
the integrity features.

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

FAST TCP makes dialup faster than broadband?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: FAST TCP makes dialup faster than broadband?
Newsgroups: comp.protocols.tcp-ip
Date: Mon, 23 Aug 2004 10:40:36 -0600

Craig Partridge writes:

Indeed, the usual problem on a dialup link is TCP trying to drive them
too hard (rather than underutilizing them), causing high loss.
[Consider that with a round-trip delay of 250ms, at 56Kb, you want
a TCP window size of about 16KB -- most systems come with the
TCP window size configured larger).

i think that the same month that the slow-start presentation was made
at IETF meeting ... there was a paper in acm sigcomm that showed that
window-based congestion flow control was non-stable in real-world
environments. one problem was that acks could bunch on return ...
resulting in effectively opening the whole window ... and then closing
it again ... when one objective was to trying and achieve a controlled
dribble across the rount-trip-delay. a packet drop scenario is window
opens completely up .... sending a slew of packets ...  and
intermediate hops get hit with multiple back-to-back packets (one
objective of congestion control could be considered to spead out
packet arrival at various nodes along the way ... instead of having
high packet arrival bursts).

the scenario at that time was some sort of rate-based pacing ... which
could be implemented as explicit control over the inter-packet
transmission interval (i.e. which would tend to explicitly control
back-to-back packet arrival at intermediate nodes). possibly one of
the issues at the time ... was a lot of the low-end machines had
relatively privmitive timer facilities ... making explicit control of
inter-packet transmission intervals difficult.

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

FAST TCP makes dialup faster than broadband?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: FAST TCP makes dialup faster than broadband?
Newsgroups: comp.protocols.tcp-ip
Date: Mon, 23 Aug 2004 10:52:52 -0600

.... oh yes, some past threads mentioning fast tcp

http://www.garlic.com/~lynn/2003j.html#1 FAST - Shame On You Caltech!!!
http://www.garlic.com/~lynn/2003j.html#2 Fix the shuttle or fly it unmanned
http://www.garlic.com/~lynn/2003j.html#10 20th anv. of 1000th node on internal network
http://www.garlic.com/~lynn/2003j.html#46 Fast TCP
http://www.garlic.com/~lynn/2003l.html#42 Thoughts on Utility Computing?
http://www.garlic.com/~lynn/2003o.html#68 History of Computer Network Industry
http://www.garlic.com/~lynn/2003p.html#15 packetloss bad for sliding window protocol ?
http://www.garlic.com/~lynn/2004c.html#47 IBM 360 memory
http://www.garlic.com/~lynn/2004g.html#8 network history

.... and for something a little different ... i finally am adding
references to my rfc index
http://www.garlic.com/~lynn/rfcietff.htm

recent post discussing some of the issues
http://www.garlic.com/~lynn/2004k.html#6

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

Losing colonies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Losing colonies
Newsgroups: alt.folklore.computers
Date: Mon, 23 Aug 2004 10:59:32 -0600

"Charlie Gibbs" writes:

But it won't necessarily be adopted.  During one conversion from
a Univac 9400 to a 90/30 I added a BXLE instruction (which the 9400
didn't support) to one of the programs.  I came in one morning to
find assembler reference manuals laid open all over a desk, which
was surrounded by people who were trying to figure out exactly
what this newfangled instruction did.  These people didn't
appreciate my disturbing their precious spaghetti code - especially
since one of them, now the programming manager, originally wrote
it years before (before he was mercifully moved up to a safe
distance away from working code).

in my youth ... i would do various kinds of performance optimizations
... one was implementing features in no instructions ... i would
re-arrange a whole bunch of other stuff so that the feature would
automagically happen as side-effect of other things being done in
specific way.

in a couple cases, ten years later ... i would get call that some
kernel fix had stopped things working (and possibly the next release
can't ship) ... the problem was that some feature was occuring as an
"implicit" side-effect of other things. it wasn't just a matter of
figuring out what a new instruction did ... it was trying to figure
out how it worked when there were no instructions being executed at
all.

one of the lessons learned was that implicit ... may be purely local
optimization and usually turns out to always be bad in the long term.

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

Losing colonies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Losing colonies
Newsgroups: alt.folklore.computers
Date: Mon, 23 Aug 2004 14:23:21 -0600

Brian Inglis writes:

I was not stereotyping the French, far from it, just pointing out
that maybe they're just as self-conscious about using other
languages as the rest of us, and it's not arrogance.

long ago and far away ... i was attending a business meeting in paris
... and the person making the presentation was from the south of
France ... he was interrupted every couple minutes by somebody from
Paris to have his French corrected.

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

FAST TCP makes dialup faster than broadband?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: FAST TCP makes dialup faster than broadband?
Newsgroups: comp.protocols.tcp-ip
Date: Tue, 24 Aug 2004 10:02:10 -0600

Craig Partridge writes:

Pacing has its own problems -- subtle errors in round-trip time estimation
can cause you to pace the packets too widely or too closely and each causes
woes.

It is known that pacing during the initial slow start allows you to open the
window much faster.

but rate-based pacing can be simply translated into inter-packet
transmission delay ... and instead of using window count/size as
slow-start mechanism ... vary the inter-packet transmission delay. the
transmission activity is then a lot more stable ... since it is
insensitive to vaguries of things like ACK patterns.

you don't even have to take into account the round-trip time
estimation ... any more than you have to take in the round-trip time
estimation for window count/size pacing.

if you analyse congestion as packet arrival ... window size/count only
indirectly controls packet arrival ... and because it only indirectly
controls packet arrival (other than upper limit an maximum that would
happen at one time) ... there tends to be a great deal more variance
... leading to less predictable behavior. translating rate-based
pacing into inter-packet transmission delay can much more predictably
control packet arrival (which has much higher correlation with
congestion) because it has much more predictable control on packet
production.

including round-trip time estimation ... might be useful for initial
guess for slow-start. however one source of woes is conflicting
control objectives ... aka 1) maximizing propagation delay masking
against 2) congestion control.

i contend that (proper) rate-based pacing mapped into inter-packet
transmission delay can be designed to perform no worse than window
packet/size implementation ... if the weighting of the control
objectives are the same ... and typically should be much better since
the packet production rate will be more stable.

one of the woes is possibly since round-trip time estimation is a time
value ... and a rate-based pacing implementation with inter-packet
transmission delay is also a time value ... that some advantage can be
taken because they are both time values.

the problem is the round-trip time estimation is a time value that
isn't associated with congestion. so a dynamic adaptive feed-back
control algorithm that is attempting to compensate for congestion ...
is in trouble if it gives too much weight to characteristic that has
nothing to do with congestion ... aka possibly under the mistaken
belief that because the congestion mechanism has switched from
max. window size to a time-based paradigm ... and that round-trip time
is also a time-based paradigm ... that the dynamic adaptive feed-back
control algorithm give undo consideration to things that have nothing
to do with congestion.

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

FAST TCP makes dialup faster than broadband?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: FAST TCP makes dialup faster than broadband?
Newsgroups: comp.protocols.tcp-ip
Date: Tue, 24 Aug 2004 15:50:32 -0600

so the original ack&window model came from end-to-end links
.... where the receiving node had some number of buffers ... and the
link was potentially faster than the ability of the receiving node to
process the packets. the receiving number pre-allocated some number of
packet buffers ... and ack'ed when a packet had been succesfully
received and processed (freeing up the packet buffer) for additional
incoming packets. this tended to have the effect of packet buffers
being idle for rount-trip-time. some optimization could be done by the
receiving node on ack'ing before the buffer was cleared ... to
minimuze idle buffer time.

moving into complex store&forward network with intermediate nodes ...
it was possible if the packets arrived at the intermediate nodes
... the buffers would be overrun, packets would be dropped and there
would be congestion. the intermediate nodes had no immediate way of
acking to pace packets to available buffers. however a congestion
queueing model could be used to represent congestion and
non-congestion situations. congestion occured when the packet arrival
rate exceeded the intermediate rate of processing &/or forwarding.  in
a no-congestion scenario ... clients could send packets as fast as the
media would handle them. as intermediate node congestion increased,
the objective would be to slow down the client packet transmit rate.
One way of profiling that is by increasing inter-packet transmission
delay ... from zero for no congestion ... to some arbritrarily large
value ... depending on the congestion level at intermediate nodes.

the issue in such an intermediate node congestion queueing model ...
it is totally independent of anything to do with individual client
round-trip-times .... it is solely related to how fast the clients are
injecting packets into the network.

so modifications of ack&window model was attempted to addressing the
intermediate node congestiom problem. the direct (intermediate node
congestion) problem is how fast is the client injecting packets into
the network ... and in the ack&window model ... the first problem
appears is that the client gets to inject a full window's worth of
packets immediately (as fast as media accepts the bits). right off the
bat, this has high probability of saturating an intermediate node (in
the congestion model) ... unless it is purely the no-congestion case
and packets can be injected into the network as fast as the media will
take it. So one of the things that slow-start can do is eliminate the
startup problem of a injecting a full window worth of packets ... as
fast as the media will take them. So, if you open up the window ... it
isn't directly controlling the inter-packet injection interval into
the network (which is the direct problem that is contributing to
intermediate node congestion) ... just the total number of bits in any
round-trip-time (and the client round-trip-time can be totally
unrelated to the packet transmit/arrival rate causing intermediate
node congestion). So the magic in slow-start is to try and coerce ACK
(and keep fingers crossed) arrival interval back to the client to have
some uniform distribution (and somewhat related to round-trip-time and
the number of outstanding ACKs).

so a couple ACK down-sides

1) there is no mechanism that directly guarentees uniform arrival
intervals of ACKs back to the client ... i.e. can slow-start avoid the
startup congestion problem inherent with window/ack paradigm ... and
then can it subsequently achieve any sort of steady-state interval
between ACKs arriving back to the client. In theory, ACKs can have a
relatively random return intervals back to the client .. in part
because there is nothing directly controlling ACK return intevals.

2) the claim for intermediate node congestion model is that the packet
arrival rate at the intermediate node leading to congestion is
independent of any client's round-trip-time. in theory, the best
control that a purely window/ack can achieve is an interval between
acks equal to the round-trip-time. however, there is nothing
preventing intermediate node congestion requiring client packet
transmittion rates to be less than one per round-trip-time (which
can't be done with purely ACK based implementation).

there is an ACK up-side

ACK return intervals can be pretty random ... which may tend to
average to round-trip-interval divided by packet-window-size. the
randomness of the return can be less than client packet transmission
interval and result in client transmitting back-to-back packets
resulting in congestion. however, bursty congestion spikes can result
in temporarily stopping ACK returns ... which stops client packet
transmission. This would be considered a faster dynamic adaptive
backoff mechanism (compareable to almost immediately seeing
simultaneous transmission collisions on enet). A purely
rate-based pacing implementation might possibly continue to transmit
for several packets (continuing to contribute to congestion spike)
after a pure ACK implementation would have stopped.

so a dynamic adaptive rate-based pacing algorithm could use a number
of early ACKs to possibly slowly reduce the inter-packet transmission
delay ... but would quickly increase inter-packet transmission delay
if it saw late ACKs.

Part of the issue from control theory standpoint is that ACK frequency
can be affected by a lot of factors (like round-trip-time) which can have
absolutely nothing to do with intermediate node congestion and packet
arrival rates (at intermediate nodes). The one possible possitive
correlation with ACKs and congestion ... is that busrty spike
congestion can cause late ACK arrival ... so a rate-based pacing
algorithm might take late ACK arrival as part of feedback
consideration.

If you take the model of intermediate node congestion being caused by
aggregate packet arrival rate ... then any client round-trip-time can
be totally unrelated to any intermediate node packet arrival
rate. then with an objective of slowing down the aggregate packet
arrival rate at intermediate nodes by slowing down the individual
client packet transmission rates. The possible values of client packet
transmission rates to achieve this (unrelated to round-trip-times) can
even be less than one packet per round-trip-time (or interpacket
transmission delay greater than round-trip-time) ... which can't occur
in the traditional window/ack paradigm.

An only slightly related analogy is that the back-off times for
ethernet collisions doesn't have a lot to do with ethernet
transmission elapsed times.

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

I am an ageing techy, expert on everything. Let me explain the

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: I am an ageing techy, expert on everything. Let me explain the
 Middle East
Newsgroups: alt.folklore.computers
Date: Tue, 24 Aug 2004 17:46:18 -0600

"Charlie Gibbs" writes:

In 1976, Robert L. Glass, writing under the pseudonym Miles Benson,
published the best of a series of columns he had written for
Computerworld.  "The Universal Elixir and Other Computing Projects
Which Failed" is a collection of amusing, interesting, and,
ultimately, educational stories.  The final section is titled
"Thoughts on Failure Itself", and goes into the philosophical
aspects of failure.

There's something terribly wrong with a society that refuses to
allow people to fail.  That's a lot of learning that never gets
done, and unfortunately we're starting to see the consequences.

it may even be worse ... i've run across a saying that if you have
never failed ... then it is only because you've never attempted
anything.  the implication that it not only inhibits learning ... but
in fact, can stifle progress and change. this may be a more
interesting societal objective as opposed to people failing.  once
long ago and far away, i was advised that "they" would have forgiven
me for being wrong but they could never forgive me for being right.

which then reminds me of  boyd
http://www.garlic.com/~lynn/subboyd.html#boyd

some number of retellings of a boyd story about why large organizations
became more & more rigid, less adaptable and less agile in the 70s
and 80s.
http://www.garlic.com/~lynn/2001d.html#45 A beautiful morning in AFM.
http://www.garlic.com/~lynn/2001m.html#16 mainframe question
http://www.garlic.com/~lynn/2002q.html#33 Star Trek: TNG reference
http://www.garlic.com/~lynn/2003c.html#65 Dijkstra on "The End of Computing Science"

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

I am an ageing techy, expert on everything. Let me explain the

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: I am an ageing techy, expert on everything. Let me explain the
 Middle East
Newsgroups: alt.folklore.computers
Date: Tue, 24 Aug 2004 20:44:26 -0600

Stanford Business School: Studying business successes without also
looking at failures tends to create a misleading or entirely wrong
picture of what it takes to succeed. A faculty member examines
undersampling of failure and finds companies that fail often do the
same things as companies that succeed.

http://www.newswise.com/articles/view/506559/

with respect to another point in the above article ... I was once told
that all succesful startups in silicon valley shared (at least) one
thing in common ... they had all changed their business plan at least
once since starting .... implying adaptability and agility may be one
of the most important characteristics.

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

FAST TCP makes dialup faster than broadband?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: FAST TCP makes dialup faster than broadband?
Newsgroups: comp.protocols.tcp-ip
Date: Wed, 25 Aug 2004 11:45:48 -0600

Craig Partridge writes:

That's not true.

There's plenty of evidence that the size of the queue in the intermediate
node is a function of the round-trip times of the end systems.

For one, intuitive, way to think about it.  The end systems can only learn
about the congestion state of their respective paths by measuring the
experience of their packets during the round-trip (or by some other
mechanism that collects data from each hop in their path -- same results,
as the last hop is still a full-rtt to get to and back).

So each end system has a reactive time that is, at its fastest, tied
to the RTT.  Thus, the experience of the intermediate system is tied to the
RTT (unless you sample less often).

so I would assert that may mean that first order arrival rate of
packets at any intermediate node is independent of the RTT
.... however, per my comment about "ACK up-side" ... i.e. sending
nodes will re-act and stop sending packets sooner due to late ACKs
... than if it is based on pure rate-based pacing. in fact, you may be
able to improve on long full-rtt by statistically tracking late ACKs
... and increasing inter-packet transmit delays ... as there is a
statistical increase in late ACKs. You still don't actually have to
know what the RTT is ...  you just have know that packets are being
transmitted at a certain rate ... and the ACKs should be returning at
approximately the same rate ... and if there is a burp in the return
rate ... it would be indicative of congestion spike. this would make
the production rate of outgoing packets and the arrival rate of
incoming ACKs still independent of RTT.

so if an intermediate node could exert direct direct back-pressure
.... then the propagation delay of that signal to the packet producer
is an issue. so worst case propagation delay for late ACKs is an early
intermediate node on the upstream packet side ... all the ACKs already
in the stream will arrive at the sending node on "time" and the
sending node won't observe the late ACK until something less than
full-RTT ... and be able to take corrective action.

So the earliest possible indication of congestion spike at some
intermediate node is a late ACK ... which is behind a full stream of
ACKs already in the stream. The duration of non-late ACKs preceeding
the late ACK is the propagation delay from the intermediate node to
the receiving node and then the receiver back to the sender.  So RTT
is related to the earliest that a sending node can see the earliest
indication of a congestion spike and take some corrective action.
Then there is the latency of packets already in flight ... and the
intermediate node won't see a fall-off because of the sender's
reaction to the late ack ... which makes it a full RTT at the
intermediate node for senders to adjust to increased congestion
because of late ACK indication at the sender.

so the re-action delay of senders to intermediate node congestion
based on late ACK indications is a full RTT ... which is the earliest
indication of burps in the congestion.

so back to my comment about simple control theory saying that the
production rate of packets by senders is independent of the RTT
... and based on calculating the production rate of packets by senders
as being dependent on the congestion along the way (and not based on
RTT). your comment is that reaction time to change packet production
rate-based on congestion along the way .... is based on RTT. However,
my original comment is that in a rate-based pacing scenario ... the
calculation of the packet production rate should correlate to
congestion and that RTT is independent of congestion (other than its
affects on reaction time to changes in congestion). So if packet
production rate is calculated based purely on congestion ... and if
control of packet production rate is achieved via inter-packet
transmission delays ... then the inter-packet transmission delays
calculation should be based purely on congestion. Is the calculation
is based purely on congestion ... then it can't be based on RTT.

The second order effects is that re-action latency to changes in
congestion is related to RTT.

So what would control theory have if it was to consider RTT as part of
calculating packet production rate (instead of solely considering
congestion). It would seem that it would need some predictive measure
of downside effects of reaction latency ... and the size of reaction
latency.

my original claim is that the cause of congestion is packet production
rate ... and that the sending nodes should be calculating their packete
production rate-based solely on congestion (and independent of RTT).

Furhtermore that ACK/windowing algorithms try and approximate packet
production rate by assuming that it is possible to achieve some sort
of homogeneous disitribution of ACKs arrivals back to the sender ...
and that by changing the value of number of packets in flight based on
RTT ... and there being a logical one-for-one between packets and ACKs
... that RTT/number-of-packets will result in ACKs arriving at
approximately that interval. However, the assertion is that RTT
divided by number-of-packets is only second order control ... since
there is no direct control over the ACK arrival rate back to the
sender ... and therefor no direct control of the resulting packet
transmission rate.

However, if you use direct rate-based pacing with something like
explicit control over inter-packet transmission interval ... you
eliminate any calculation involving RTT ... and make the inter-packet
transmission interval (and therefor the packet production rate) based
solely on congestion ... and independent of RTT.

so RTT does have second order effects on the re-action time in dealing
with changes in congestion. So control theory would say that you
calculate downside of congestion reaction latency and the probability
of congestion spikes ... so how would that manifest itself in
calculating the packet production rate? Traditional control theory
leaves excess capacity in the system for handling resource spikes when
latency re-action is more costly (there are more packets lost of
adjusting to congestion spikes than lost to leaving some transmission
idle). that translates into decreasing the packet production rate
calculation by some percentage ... which would translate into
increasing the inter-packet transmission delay. Basically you are
looking at the cost of packet loss due to congestion spikes ... the
probability of congestion spikes per unit time ... and the nominal
congestion re-action delay ... which in aggregate translates into
probability of total packet loss because of congestion spikes and
reaction delay (where RTT is sort of 2nd order factor). You then
somewhat assume that backing off packet production rate, leaving
excess capacity can compensate for congestion spikes (and there are
fewer packets loss to packet production back-off than there would be
to congestion spikes ... and the reaction delay).

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

FAST TCP makes dialup faster than broadband?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: FAST TCP makes dialup faster than broadband?
Newsgroups: comp.protocols.tcp-ip
Date: Wed, 25 Aug 2004 12:08:31 -0600

so we go back to the original premise ... control theory results in
packet producers calculating packet production rate solely on
congestion.  if all the packet producers are calculating packet
production rate solely on congestion ... they aren't calculating it
based on anything else ... including RTT. If the packet arrival rate
at intermediate nodes is based on the packet production rate of the
individual senders ... and if all the senders are using congestion as
the sole factor in calculating packet production rate ... then to
first order appoximation, the packet arrival rate at intermediate
nodes is based on sender packet production rate ... packet production
rate is independent of RTT ... then intermediate node packet arrival
rate is independent of RTT.

so in real life, intermediate nodes are seeing traffic spikes which
require packet production rate adjustments at the senders ... and that
RTT affects the reaction time.

one of the original statements that w/o direct control over ACK
arrival intervals ... ACK arrival patterns may result in opening up a
large portion of a window at a single moment, resulting in several
back-to-back packets being transmitted ... which would could appear as
transient congestion at intermediate node ... requiring re-active
adjustments. I believe this is one of the non-stable scenarios in
early papers.

so one conjecture is explicit control of packet production rate may
significant mitigate the occurance of such transient congestions (and
also mitigate needing to be aware of RTT adjustment delay affects to
transient changes).

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

FAST TCP makes dialup faster than broadband?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: FAST TCP makes dialup faster than broadband?
Newsgroups: comp.protocols.tcp-ip
Date: Wed, 25 Aug 2004 12:22:04 -0600

and small footnote

control algorithms will tend to adjust the rate of change proportional
to the feedback latency (driving cars, martian rovers, etc).

while congestion may be the sole factor used in producers calculating
their packet production rate (independent of RTT) ... the feedback
latency is proportional to RTT ... so the frequency that increases in
packet production rate is done should be proportional to the RTT
feedback interval. So the rate of packet production is solely based on
congestion and independent of RTT ... but the rate of increases in
packet production can be proportional to the RTT feedback interval.

however, as per previous ... conjecture about non-stable nature of
ACK-based infrastructures for handling congestion ... may in fact be a
significant cause behind spikes in intermediate node congestion
... requiring significant changes in packet production rate by the
producers (where RTT becomes significant factor in the reaction delay
of the infrastructure).

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

FAST TCP makes dialup faster than broadband?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: FAST TCP makes dialup faster than broadband?
Newsgroups: comp.protocols.tcp-ip
Date: Wed, 25 Aug 2004 14:38:50 -0600

and getting really carried away ... some comments on dynamic adaptive
feedforward control algorithms ... as well as non-stable negative
feedback effects.

if the congestion control mechanism was going to include predictive
congestion (as well as past congestion) ... i contend, something with
high correlation is number of intermediate nodes ... not RTT elapsed
time; aka I could have a direct double-hop satellite link with no
intermediate nodes and therefor no intermediate node congestion
... with a significantly higher RTT elapsed time than a 30-hop
terrestial path.  So a dynamic adaptive feedforward congestion control
algorithm could figure in not only past congestion behavior for
controlling packet transmit rate ... but also use likely hop-count as
a probability indication of possibly future congestion (but not RTT
elapsed time as probablity of congestion ... although as stated RTT
elapsed time does affect feedback latency ... and therefor should be a
factor in control algorithm deciding on rate of change ... as opposed
to pure rate).  RTT elapsed time may have some correlation with number
of intermediate nodes ... but would be considered only a second order
effect of predicting congestion potential (since you can actually have
very high RTT elapsed time with no intermediate node congestion
issues).

so, one of the conjectures about ACK-based being non-stable and
possibly even having negative feedback. The assertion is that the
transmission of multiple back-to-back packets, possibly when a full
window opens, can result in a spike in congestion and slow-down at an
intermediate node. So the observation is that any spike in congestion
and slow-down at an intermediate node can result in some number of
ACKs backing up at the congested intermediate node. Then if the
congestion decreases ... any backed up ACKs may be released in
bunches.

The release of bunched, backed up ACKs (from an intermediate node that
saw transient congestion spikes) means that the arrival of bunched
ACKS at the sending node will open up multiple packets in the sending
window ... resulting in the sending node being able to send multiple
back-to-back packets ... which in turn, can result in transient
congestion spikes at intermediate nodes. The issue then is that any
cause of transient congestion spike at intermediate nodes ... may
result in ACK return bunching ... which then results in a lull in
packet transmission at the sender ... followed by multiple
back-to-back transmission at the sender. The intermediate nodes then
could get into negative feed-back, non-stable oscillation of packet
transmission lulls followed by packet transmission peaks. From a
control algorithm standpoint for ACK characteristic, this non-stable
oscillation may continue until eventually packets are dropped and
sending nodes go into some sort of back-off ... until the congestion
builds up and it starts the cycle all over again.

There are some second order effects as number of intermeidate nodes
increase ...  random perturbation in large number of intermediate nodes
in the same path ... can have a dampening effect on any strong
negative feedback oscillations caused by ACK bunching. On the other
hand ... unless the random perturbations are really significant ...
multiple intermediate nodes might result in amplifying the negative
feedback oscillations.

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

Vintage computers are better than modern crap !

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Vintage computers are better than modern crap !
Newsgroups: alt.folklore.computers
Date: Thu, 26 Aug 2004 08:56:02 -0600

jmfbahciv writes:

[puzzled emoticon here]  It's a law that all buffers are going
to be too small.  Part of the programming job is to include this
eventuality.

when we were working with this small client/server startup in menlo
park that wanted to do payment transactions on the server ... one of
the things we mentioned was that it can take ten times the effort and
4-10 times the programming to take a well crafted and well tested
application and turn it into a service.

misc. stuff about this thing now called e-commerce
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

other posts about effort for  application -> service
http://www.garlic.com/~lynn/2001f.html#75 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2001n.html#91 Buffer overflow
http://www.garlic.com/~lynn/2001n.html#93 Buffer overflow
http://www.garlic.com/~lynn/2002b.html#59 Computer Naming Conventions
http://www.garlic.com/~lynn/2002n.html#11 Wanted: the SOUNDS of classic computing
http://www.garlic.com/~lynn/2003g.html#62 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003j.html#15 A Dark Day
http://www.garlic.com/~lynn/2003p.html#37 The BASIC Variations
http://www.garlic.com/~lynn/2004b.html#8 Mars Rover Not Responding
http://www.garlic.com/~lynn/2004b.html#48 Automating secure transactions

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

Vintage computers are better than modern crap !

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Vintage computers are better than modern crap !
Newsgroups: alt.folklore.computers
Date: Thu, 26 Aug 2004 10:22:38 -0600

Alan Balmer writes:

You don't, but you can put it on a short, visible cable, or not
allow it to be used. You can't prevent a braindead operator from
pasting his password on the wall, either. The solution is still the
same - security is not something that is magically implanted in a
computer system by installing some wonderful program. It's an entire
process, involving the system, its peripherals, its connectivity,
and the people who use it. So, if it's insecure, don't do it.

Anyway, this is getting to be quite a stretch from the issue of
printing more of a user task's buffer than expected.

a lot of security has to do with authentication. the long time
scenario has been something you know authentication; possibly really
shared-secrets (like passwords) ... but may be something simple like
mother's maiden name.

the shared-secret password scenario for a long time has been that each
security domain wanted unique password (different passwords at your
employer, your bank, and your local operation in a garage ISP). part
of the problem is that each security domain appeared to think they
were the only-one ... discounting the fact that a person now may have
to manage scores of unique passwords ... which are difficult to
remember and possibly change every month. that has led to problems
like people having to write down their passwords and possibly store
them close to where they might use them. old joke
http://www.garlic.com/~lynn/2001d.html#52 A beautiful morning in AFM

another issue is that possibly 1/3rd of exploits involve social
engineering .... getting people to give-up information that they
shouldn't (like passwords and/or other authentication code).

one of the issues of going to two-factor authentication ... say some
form of hardware tokens ... is it makes social engineering task more
difficult since it now involves convincing somebody to give up a
physical object ... in addition to just information.

... there is this old saying about there not being any truely hard
technical problems ... i.e. all the really hard problems typically
arise from some form of people issues.

random passed social engineering posts
http://www.garlic.com/~lynn/aadsm3.htm#cstech10 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#kiss8 KISS for PKIX
http://www.garlic.com/~lynn/aadsm8.htm#softpki3 Software for PKI
http://www.garlic.com/~lynn/99.html#235 Attacks on a PKI
http://www.garlic.com/~lynn/aadsm14.htm#9 "Marginot Web" (SSL, payments, etc)
http://www.garlic.com/~lynn/aadsm14.htm#32 An attack on paypal
http://www.garlic.com/~lynn/aadsm14.htm#33 An attack on paypal
http://www.garlic.com/~lynn/aadsm14.htm#35 The real problem that https has conspicuously failed to fix
http://www.garlic.com/~lynn/aadsm16.htm#2 Electronic Safety and Soundness: Securing Finance in a New Age
http://www.garlic.com/~lynn/aadsm16.htm#7 The Digital Insider: Backdoor Trojans ... fyi
http://www.garlic.com/~lynn/aadsm17.htm#47 authentication and authorization ... addenda
http://www.garlic.com/~lynn/aadsm17.htm#58 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/2002g.html#82 Future architecture
http://www.garlic.com/~lynn/2002j.html#40 Beginner question on Security
http://www.garlic.com/~lynn/2003i.html#1 Two-factor authentication with SSH?
http://www.garlic.com/~lynn/2003j.html#8 A Dark Day
http://www.garlic.com/~lynn/2003l.html#2 S/360 Engineering Changes
http://www.garlic.com/~lynn/2003m.html#25 Microsoft Internet Patch
http://www.garlic.com/~lynn/2003m.html#51 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003o.html#9 Bank security question (newbie question)
http://www.garlic.com/~lynn/2003o.html#50 Pub/priv key security
http://www.garlic.com/~lynn/2003o.html#57 Pub/priv key security
http://www.garlic.com/~lynn/2004.html#30 Threat of running a web server?
http://www.garlic.com/~lynn/2004f.html#31 MITM attacks
http://www.garlic.com/~lynn/2004j.html#37 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004j.html#38 Vintage computers are better than modern crap !

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

Public key authentication defeats passwd age warning

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Public key authentication defeats passwd age warning.
Newsgroups: comp.security.ssh
Date: Fri, 27 Aug 2004 09:31:05 -0600

dtucker@dodgy.net.au (Darren Tucker) writes:

It would be possible to generate the messages for non-password auths
too but I'm not sure it makes sense.  If you're not using the
password at all, is it relevant that it's expired?  And what do you
do if it is?  Deny the login even though the credentials used for
the authentication (ie the public key) are perfectly fine?  Or
generate a message of the form "your password expired X days ago"?

the basic premise of passwords is that they are shared-secrets and
vulnerable to all sorts of attacks ... where obtaining knowledge of
the passwords can lead to exploits. password expires supposedly bounds
the duration of any such exploits.

public keys can be substituted in place of passwords ... put them in
the table entry and identify digital signature as the method of
authentication (instead of password compare). if the system
authentication file supported that ... then ssh could stuff the public
key there in lieu of password ... instead of needing its own table.

since knowledge of public key isn't subject to the same sort of
exploits as passwords ... the requirement for frequent changes is
severely mitigated as means of bounding (undiscovered) exploits.

there are however possibly two completely different issues here

1) confusing that digital credentials are equivalent to public key.
public keys can easily be done like ssh ... which just registers the
authentication material ... however, it registers a public key for
performing authentication instead of registering a password for
authentication & maintains the same business process. because of the
vaguries of current "password" oriented authentication files ... ssh
resorts to its own registration file. note that this is a completely
different business process for authentication material than the
typical digital credential business process. while the ssh-like method
preserves the business process for the relying party to register the
authentication material ... the digital credential model originated so
that the registration process could be outsourced to 3rd parties.

2) there are still exploits on public/private key that are compariable
to password-based infrastructure exploits. part of the expiry process
is to bound the life of a specific password exploit (because of its
vulnerability to being learned). a lot of the public key
credentialling infrastructures distract attention by focusing on the
strength of public key operations and/or the credentialling
registration process.  however, a direct equivalent to attackers
acquiring password is attackers acquiring the private key. if you were
looking at the use of expiring as a method of bounding an exploit
... you would compare the probability for an attacker to obtain a
password (via all possible mechanisms) compared to the difficulty that
it might take an attacker to obtain a private key (via all possible
mechanisms). If you determined that it was four times harder for an
attacker to obtain a user's private key ... you might then choose to
make the validity period for a registered public key ... four times
that of a registered password (however, if it was a 20 times harder
for an attacker to obtain a private key ... you might make a public
key validity period 20 times longer). A simple password harvesting
attack might be to obtain the file where the user stores all their
passwords. A possibly equivalent attack on private key is to obtain
the file where the user stores their private key(s)). If the ease of
performing such attack is roughly equivalent and such attack
represents major vulnerability ... then it could be that the
expiration of a password and the expiration of a public key would be
similar.

one possible issue in ssh vis-a-vis password ... if major password
exploit is evesdropping the authentication process ... and password
authentication is no longer used (because ssh is using digital
signature) ... then a major factor in needing password expiring for
bounding exploits is eliminated (and the artifact that ssh
registration of public key for authentication hasn't been integrated
into overall system infrastructure of registration business process of
authentication material). however, if the major vulnerability is
acquisition of client stored files containing authentication material
(either password or private key) ... then there could be a need for
more consistent expiring for both passwords and private keys.

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

US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of
 ASCII,Invento
Newsgroups: alt.folklore.computers
Date: Fri, 27 Aug 2004 13:24:12 -0600

mwojcik@newsguy.com (Michael Wojcik) writes:

And as for DEC, Prime, DG, and so forth: nothing lasts forever, and
it's quite a stretch to blame their demise on state taxes without
rather strong evidence.

i've constantly attributed the big rise in minicomputers during (at
least) the late 70s and early 80s ... being the cost of computing drop
below some threshold, opening up a huge new market .... and that
market started moving to large workstation servers and large PCs in
the mid-80s. since that market segment appeared to have opened up in
the late 70s because of price sensitivity ... it wouldn't be a
surprise that it continued to be somewhat price sensitive. this was
possibly the start of customers ordering systems in multiple hundreds
at a time.

the cp67/vm370 development group split off from the science center and
then when they outgrew available space in 545 tech sq, the group moved
out to the old SBC bldg. in burlington mall (sbc having been
transferred to cdc).

in the mid-70s, the group was told that there would be no more vm/370
product (for customers), that burlington mall was being shutdown
... and that everybody had to move to POK to work on the internal-only
vmtool in support of mvs/xa development ... which saw some number of
the vm/370 development group going to dec and prime (i don't remember
any going to dg).

misc. past posts about departmental servers and that market segment
explosion.
http://www.garlic.com/~lynn/96.html#16 middle layer
http://www.garlic.com/~lynn/96.html#33 Mainframes & Unix
http://www.garlic.com/~lynn/2001m.html#15 departmental servers
http://www.garlic.com/~lynn/2001n.html#23 Alpha vs. Itanic:  facts vs. FUD
http://www.garlic.com/~lynn/2001n.html#79 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)
http://www.garlic.com/~lynn/2002.html#2 The demise of compaq
http://www.garlic.com/~lynn/2002.html#7 The demise of compaq
http://www.garlic.com/~lynn/2002d.html#4 IBM Mainframe at home
http://www.garlic.com/~lynn/2002h.html#52 Bettman Archive in Trouble
http://www.garlic.com/~lynn/2002i.html#30 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002j.html#4 HONE, ****, misc
http://www.garlic.com/~lynn/2002j.html#7 HONE, ****, misc
http://www.garlic.com/~lynn/2002j.html#34 ...killer PC's
http://www.garlic.com/~lynn/2002j.html#66 vm marketing (cross post)
http://www.garlic.com/~lynn/2002n.html#66 Mainframe Spreadsheets - 1980's History
http://www.garlic.com/~lynn/2003c.html#23 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003d.html#64 IBM was: VAX again: unix
http://www.garlic.com/~lynn/2003n.html#46 What makes a mainframe a mainframe?
http://www.garlic.com/~lynn/2003o.html#13 When nerds were nerds
http://www.garlic.com/~lynn/2003o.html#24 Tools -vs- Utility
http://www.garlic.com/~lynn/2003p.html#38 Mainframe Emulation Solutions
http://www.garlic.com/~lynn/2004.html#46 DE-skilling was Re: ServerPak Install via QuickLoad Product
http://www.garlic.com/~lynn/2004d.html#56 If there had been no MS-DOS
http://www.garlic.com/~lynn/2004f.html#39 Who said "The Mainframe is dead"?
http://www.garlic.com/~lynn/2004j.html#37 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004j.html#57 Monster(ous) sig (was Re: Vintage computers are better

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

Timeless Classics of Software Engineering

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Timeless Classics of Software Engineering
Newsgroups: comp.arch,comp.databases.theory,comp.software-eng,comp.lang.c++,comp.ai.philosophy
Date: Fri, 27 Aug 2004 14:24:46 -0600

eric.nospam.hamilton@hp.com (Eric Hamilton) writes:

Thanks for a stimulating topic.

I heartily agree that Mythical Man Month is essential reading for
anyone who wants to understand large scale software projects.

The other essential on my book case is Lakos' "Large Scale C++
Software Design".  It's applicable to any language and has enough
rationale that's grounded in real development practices and the
problems of large scale projects that I think it's relevant to the
original topic.

A few years ago, I happened to reread Brooks and wrote up a
collection his insights that resonated with me.  I've attached it
below in hopes of whetting the appetite of anyone who hasn't already
read it and as a reminder for those who haven't reread it recently.
I encourage everyone to (re)read the full book.

one of boyd's observation about general US large corporations starting
at least in the 70s was rigid, non-agile, non-adaptable operations.
he traced it back to training a lot of young people received in ww2 as
how to operate large efforts (who were starting to come into positions
of authority) ... and he contrasted it to Guderian and the blitzgreig.

Guderian had a large body of highly skilled and experienced people
... who he outlined general strategic objectives and left the tactical
decisions to the person on the spot .... he supposedly proclaimed
verbal orders only ... in the theory that the auditors going around
after the fact would not find a paper trail to blame anybody when
battle execution had glitches. the theory was the the trade-off of
letting experierenced people on the spot feel free to make decisions
w/o repercusions, more than offset any possibility that that they
might make mistakes.

boyd contrasted this with the much less experienced american army with
few really experienced people which was structured for heavy top-down
direction (to take advantage of skill scarcity) ... the rigid top-down
direction with little local autonomy would rely on logistics and
managing huge resource advantage (in some cases 10:1).

part of the issue is that rigid, top-down operations is used to manage
large pools of unskilled resources. on the other hand, rigid top-down
operations can negate any advantage of skilled resource pool (since
they will typically be prevented from exercising their own judgement).

so in the Guderian scenario .... you are able to lay out strategic
objectives and then allow a great deal of autonomy in achieving
tactical objectives (given a sufficent skill pool and clear strategic
direction).

random boyd refs:
http://www.garlic.com/~lynn/subboyd.html#boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2

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

Timeless Classics of Software Engineering

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Timeless Classics of Software Engineering
Newsgroups: comp.arch,comp.databases.theory,comp.software-eng,comp.lang.c++,comp.ai.philosophy
Date: Fri, 27 Aug 2004 15:10:59 -0600

eric.nospam.hamilton@hp.com (Eric Hamilton) writes:

Harlan Mills proposed "surgical team" approach.  [Not applicable everywhere.]

Conceptual integrity:
- Analogy to architectural unity of Reims cathedral vs. others that were
"improved" inconsistently.

- "I will contend that conceptual integrity is the most important
consideration in system design.  It is better to have a system omit
certain anomalous features and improvements, but to reflect one set of
design ideas, than to have one that contains many good but independent
and uncoordinated ideas."

- The purpose of a programming system is to make a computer easy to
use. [We may modify purpose to be to make it easy to do the things that
our customers need done.]
- Ratio of function to conceptual complexity is the ultimate test of
system design.
- For a given level of function, that system is best in which one can
specify things with the most simplicity and straightforwardness.

i was at a talk that harlan gave at the 1970 se symposium ... that
year it was held in DC (which was easy for harlan since he was local
in fsd) ... close to the river on the virginia side (marriott? near a
bridge ... I have recollections of playing hooky one day and walking
across the bridge to the smithsonian).

is was all about super programmer and librarian .... i think the super
programmer was re-action to the large low-skilled hordes ... and the
librarian was to take some of administrative load of the super
programmer.

i remember years later somebody explaining that managers tended to
spend 90% of their time with the 10% least productive people ...  and
that 90% of the work was frequently done by the 10% most productive
people; it was unlikely that anything that a manager did was going to
significantly improve the 10% least productive members .... however if
they spent 90% of their time helping remove obstacles from the 10%
most productive ... and even if that only improved things by 10%
... that would be the most benefical thing that they could do.  This
was sort of the librarian analogy from harlan ... that managers
weren't there to tell the high skilled people what to do ... managers
were to facilitate and remove obstacles from their most productive
people.

this is somewhat more consistant with one of boyd's talks on the
organic design for command and control.

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

Timeless Classics of Software Engineering

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Timeless Classics of Software Engineering
Newsgroups: comp.arch,comp.databases.theory,comp.software-eng,comp.lang.c++,comp.ai.philosophy
Date: Fri, 27 Aug 2004 20:00:22 -0600

Anne & Lynn Wheeler writes:

i was at a talk that harlan gave at the 1970 se symposium ... that
year it was held in DC (which was easy for harlan since he was local
in fsd) ... close to the river on the virginia side (marriott? near
a bridge ... I have recollections of playing hooky one day and
walking across the bridge to the smithsonian).

this marriott has bug'ed my memory across some period of posts
http://www.garlic.com/~lynn/2000b.html#20 How many Megaflops and when?
http://www.garlic.com/~lynn/2000b.html#24 How many Megaflops and when?
http://www.garlic.com/~lynn/2000b.html#25 How many Megaflops and when?
http://www.garlic.com/~lynn/2000c.html#64 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2001h.html#48 Whom Do Programmers Admire Now???
http://www.garlic.com/~lynn/2002i.html#49 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002q.html#51 windows office xp
http://www.garlic.com/~lynn/2003g.html#2 Share in DC: was somethin' else
http://www.garlic.com/~lynn/2003k.html#40 Share lunch/dinner?
http://www.garlic.com/~lynn/2004k.html#25 Timeless Classics of Software Engineering

so doing some searching ... this is a picture of approx. what i remember
http://www.hostmarriott.com/ourcompany/timeline_twin.asp?page=timeline

this lists a ieee conference at twin bridge marriott, washington dc in '69
http://www.ecs.umass.edu/temp/GRSS_History/Sect6_1.html

this lists first marriott motor hotel, twin bridges, washington dc
http://www.hrm.uh.edu/?PageID=185

and this has a reference to the site of the former Twin Bridges Marriott
having been razed several years ago
http://www.washingtonpost.com/wp-srv/local/counties/arlngton/longterm/wwlive/crystal.htm

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

Vintage computers are better than modern crap !

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Vintage computers are better than modern crap !
Newsgroups: alt.folklore.computers
Date: Sat, 28 Aug 2004 07:43:30 -0600

... from not so long ago and far away .... notice that official
organizations would be issuing (public) keys

For Immediate Release

Secure NCSA Mosaic Establishes Necessary Framework for Electronic
Commerce on the Internet

PALO ALTO, Calif., April 12, 1994 -- Enterprise Integration
Technologies (EIT), the National Center for Supercomputing
Applications (NCSA) at the University of Illinois and RSA Data
Security today announced agreements to jointly develop and distribute
a secure version of NCSA Mosaic, the popular point-and-click interface
that enables easy access to thousands of multimedia information
services on the Internet.

The announcement was made in conjunction with the launch of
CommerceNet, a large-scale market trial of electronic commerce on the
Internet. Under the agreements, EIT will integrate its Secure-HTTP
software with public key cryptography from RSA into NCSA Mosaic
Clients and World Wide Web (WWW) servers. WWW is a general-purpose
architecture for information retrieval comprised of thousands of
computers and servers that is available to anyone on Internet. The
enhancements will then be made available to NCSA for widespread public
distribution and commercial licensing.

Jay M. Tenenbaum, chief executive officer of EIT, believes secure NCSA
Mosaic will help unleash the commercial potential of the Internet by
enabling buyers and sellers to meet spontaneously and transact
business.

"While NCSA Mosaic makes it possible to browse multimedia catalogs,
view product videos, and fill out order forms, there is currently no
commercially safe way to consummate a sale," said Tenenbaum. "With
public key cryptography, however, one can authenticate the identity of
trading partners so that access to sensitive information can be
properly accounted for."

This secure version of NCSA Mosaic allows users to affix digital
signatures which cannot be repudiated and time stamps to contracts so
that they become legally binding and auditable. In addition, sensitive
information such as credit card numbers and bid amounts can be
securely exchanged under encryption. Together, these capabilities
provide the foundation for a broad range of financial services,
including the network equivalents of credit and debit cards, letters
of credit and checks. In short, such secure WWW software enables all
users to safely transact day-to-day business involving even their most
valuable information on the Internet.

According to Joseph Hardin, director of the NCSA group that developed
NCSA Mosaic, over 50,000 copies of the interface software are being
downloaded monthly from NCSA's public server -- with over 300,000
copies to date. Moreover, five companies have signed license
agreements with NCSA and announced plans to release commercial
products based on NCSA Mosaic.

"This large and rapidly growing installed base represents a vast,
untapped marketplace," says Hardin. The availability of a secure
version of NCSA Mosaic establishes a valid framework for companies to
immediately begin large-scale commerce on the Internet."

Jim Bidzos, president of RSA, sees the agreement as the beginning of a
new era in electronic commerce, where companies routinely transact
business over public networks.

"RSA is proud to provide the enabling public key software technology
and will make it available on a royalty-free basis for inclusion in
NCSA's public distribution of NCSA Mosaic," said Bidzos. RSA and EIT
will work together to develop attractive licensing programs for
commercial use of public key technology in WWW servers."

At the CommerceNet launch, Allan M. Schiffman, chief technical officer
of EIT, demonstrated a working prototype of secure NCSA Mosaic, along
with a companion product that provides for a secure WWW server. The
prototype was implemented using RSA's TIPEM toolkit.

"In integrating public key cryptography into NCSA Mosaic, we took
great pains to hide the intricacies and preserve the simplicity and
intuitive nature of NCSA Mosaic," explained Schiffman.

Any user that is familiar with NCSA Mosaic should be able to
understand and use the software's new security features. Immediately
to the left of NCSA's familiar spinning globe icon, a second icon has
been inserted that is designed to resemble a piece of yellow
paper. When a document is signed, a red seal appears at the bottom of
the paper, which the user can click on to see the public key
certificates of the signer and issuing agencies. When an arriving
document is encrypted, the paper folds into a closed envelope,
signifying that its information is hidden from prying eyes. When the
user fills out a form containing sensitive information, there is a
'secure send' button that will encrypt it prior to transmission.

Distribution of Public Keys

To effectively employ public-key cryptography, an infrastructure must
be created to certify and standardize the usage of public key
certificates. CommerceNet will certify public keys on behalf of member
companies, and will also authorize third parties such as banks, public
agencies, industry consortia to issue keys. Such keys will often serve
as credentials, for example, identifying someone as a customer of a
bank, with a guaranteed credit line. Significantly, all of the
transactions involved in doing routine purchases from a catalog can be
accomplished without requiring buyers to obtain public keys. Using
only the server's public key, the buyer can authenticate the identity
of the seller, and transmit credit card information securely by
encrypting it under the seller's public key. Because there are far
fewer servers than clients, public key administration issues are
greatly simplified.

Easy Access to Strong Security

To successfully combine simplicity of operation and key administration
functions with a high level of security that can be accessible to even
non-sophisticated users, significant changes were necessary for
existing WWW security protocols. EIT developed a new protocol called
Secure-HTTP for dealing with a full range of modern cryptographic
algorithms and systems in the Web.

Secure-HTTP enables incorporation of a variety of cryptographic
standards, including, but not limited to, RSA's PKCS-7, and Internet
Privacy Enhanced Mail (PEM), and supports maximal interoperation
between clients and servers using different cryptographic
algorithms. Cryptosystem and signature system interoperation is
particularly useful between U.S. residents and non-U.S.  residents,
where the non-U.S. residents may have to use weaker 40-bit keys in
conjunction with RSA's RC2 (TM) and RC4 (TM) variable keysize
ciphers. EIT intends to publish Secure-HTTP as an Internet standard,
and work with others in the WWW community to create a standard that
will encourage using the Web for a wide variety of commercial
transactions.

Availability

EIT will make Secure NCSA Mosaic software available at no charge to
CommerceNet members in September and NCSA will incorporate these
secure features in future NCSA Mosaic releases.

Enterprise Integration Technologies Corp., of Palo Alto, Calif., (EIT)
is an R&D and consulting organization, developing software and
services that help companies do business on the Internet. EIT is also
project manager of CommerceNet.

The National Center for Supercomputer Applications (NCSA), developer
of the Mosaic hypermedia browser based at the University of Illinois
in Champaign, Ill., is pursuing a wide variety of software projects
aimed at making the Internet more useful and easier to use.

RSA Data Security, Inc., Redwood City, Calif., invented Public Key
Cryptography and performs basic research and development in the
cryptographic sciences. RSA markets software that facilitates the
integration of their technology into applications.

Information on Secure NCSA Mosaic can be obtained by sending e-mail to
shttp-info@eit.com.

Press Contact:

Nancy Teater
Hamilton Communications
Phone:  (415) 321-0252
Fax:  (415) 327-4660
Internet: nrt@hamilton.com

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

Vintage computers are better than modern crap !

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Vintage computers are better than modern crap !
Newsgroups: alt.folklore.computers
Date: Sat, 28 Aug 2004 07:53:09 -0600

and at:

ARPA HIGH PERFORMANCE COMPUTING AND COMMUNICATIONS SYMPOSIUM
March 15-18, 1994
Radisson Plaza Hotel at Mark Center
Alexandria, Virginia

Sponsored by:   Advanced Research Projects Agency
                Computing Systems Technology Office

...
there was the following session

INFORMATION INFRASTRUCTURE SERVICES
Chair:  Dr. Randy Katz, CSTO

Prof. David Gifford, MIT
Connecting the NII to the U.S. Financial System
A payment system is central to NII commerce,
and it would be highly desirable to allow NII
commerce to be conducted with existing
financial instruments such as demand deposit
accounts and credit cards.  We will discuss the
technical issues and fraud risks of
directly connecting the NII to existing
banking systems.

Prof. David Patterson, UCBerkeley
"TeraBYTES are more important than TeraFLOPS"
Processors are getting faster while disks
getting smaller rather than faster.  This talk
first describes the results of the RAID project
(Redundant Arrays of Inexpensive Disks), which
offers much greater performance, capacity, and
reliablity from I/O systems. We then look at
utilizing small helical scan tapes, such as
video tapes, to offer terabytes of storage for
the price of ten desktop computers.  I believe
a factor of 1000 increase in storage capacity
available will have a much greater impact on
society than a factor of 1000 increase in
processing speed for a gaggle of scientists.

Prof. Daniel Duchamp, Columbia
DYNAMIC APPLICATION PARTITIONING
Portable computers can move, with little or no
warning, from one network attachment to another.

If the attachments provide substantially different
bandwidth, then one design challenge is how to
"cut" the overall system into client and server
halves.  Since the network bandwidth between client
and server is highly variable, it is tempting to
make the cut variable, so that at different times
different partitions -- requiring different
bandwidths -- prevail. We describe present techniques
and future possibilities for dynamic application
partitioning in support of mobile computing.

Dr. Clifford Neuman, USC-ISI
Information, Payments, and Electronic
Commerce on the NII
This presentation will describe information
and payment services that must be provided to
support the provision of for-hire
services on the NII.

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

CDC STAR-100

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CDC STAR-100
Newsgroups: alt.folklore.computers
Date: Sun, 29 Aug 2004 09:46:10 -0600

jsavard@excxn.aNOSPAMb.cdn.invalid (John Savard) writes:

Apparently it was James Thornton who designed the STAR; Cray worked
on the 8600 instead during the early portion of STAR development
before he left.

The Cray-1, unlike the STAR, had vector registers, and stride -
according to some sources, but others credit the STAR with
scatter-gather capabilities in hardware.

thornton left later than cray ... with some number of other people to
form network systems corp.

random past ref:
http://www.garlic.com/~lynn/2002i.html#13 CDC6600 - just how powerful a machine was it?

for lot more drift, about same time as above post, post here in
a.f.c. on putting up scan of thornton's book
http://groups.google.com/groups?q=%2Bthornton+%2Bcdc+%2Bscan&hl=en&lr=&ie=UTF-8&selm=d266ec61.0206040856.4527dd4e%40posting.google.com&rnum=3

network systems did high speed and heterogeneous internconnect

long time later, when i had done rfc 1044 support ... i got involved
in tuning at cray research .... somewhat in conjunction with hsdt ...
hsdt collection (things like rate-based pacing, dynamic adaptive
control, optimal thruput, etc)
http://www.garlic.com/~lynn/subnetwork.html#hsdt

the original VPN ... i saw in a guy's house (he worked for nsc) ... it
was for secure link to work ... he then introduced it at ietf router
working group and it is now called VPN.

random past rfc 1044 posts:
http://www.garlic.com/~lynn/93.html#28 Log Structured filesystems -- think twice
http://www.garlic.com/~lynn/96.html#14 mainframe tcp/ip
http://www.garlic.com/~lynn/96.html#15 tcp/ip
http://www.garlic.com/~lynn/96.html#17 middle layer
http://www.garlic.com/~lynn/98.html#34 ... cics ... from posting from another list
http://www.garlic.com/~lynn/98.html#49 Edsger Dijkstra: the blackest week of his professional life
http://www.garlic.com/~lynn/98.html#50 Edsger Dijkstra: the blackest week of his professional life
http://www.garlic.com/~lynn/99.html#36 why is there an "@" key?
http://www.garlic.com/~lynn/99.html#123 Speaking of USB ( was Re: ASR 33 Typing Element)
http://www.garlic.com/~lynn/2000.html#90 Ux's good points.
http://www.garlic.com/~lynn/2000c.html#59 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000f.html#30 OT?
http://www.garlic.com/~lynn/2001d.html#63 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001d.html#65 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001e.html#52 Pre ARPAnet email?
http://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001h.html#44 Wired News :The Grid: The Next-Gen Internet?
http://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2002.html#11 The demise of compaq
http://www.garlic.com/~lynn/2002i.html#43 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#45 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002j.html#67 Total Computing Power
http://www.garlic.com/~lynn/2002k.html#31 general networking is: DEC eNet: was Vnet : Unbelievable
http://www.garlic.com/~lynn/2002n.html#58 IBM S/370-168, 195, and 3033
http://www.garlic.com/~lynn/2002o.html#51 E-mail from the OS-390 ????
http://www.garlic.com/~lynn/2002q.html#27 Beyond 8+3
http://www.garlic.com/~lynn/2003.html#67 3745 & NCP Withdrawl?
http://www.garlic.com/~lynn/2003b.html#29 360/370 disk drives
http://www.garlic.com/~lynn/2003b.html#44 filesystem structure, was tape format (long post)
http://www.garlic.com/~lynn/2003c.html#28 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003c.html#77 COMTEN- IBM networking boxes
http://www.garlic.com/~lynn/2003c.html#79 COMTEN- IBM networking boxes
http://www.garlic.com/~lynn/2003d.html#33 Why only 24 bits on S/360?
http://www.garlic.com/~lynn/2003d.html#35 Why only 24 bits on S/360?
http://www.garlic.com/~lynn/2003d.html#37 Why only 24 bits on S/360?
http://www.garlic.com/~lynn/2003d.html#59 unix
http://www.garlic.com/~lynn/2003i.html#43 A Dark Day
http://www.garlic.com/~lynn/2003j.html#2 Fix the shuttle or fly it unmanned
http://www.garlic.com/~lynn/2003k.html#26 Microkernels are not "all or nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2003n.html#40 Cray to commercialize Red Storm
http://www.garlic.com/~lynn/2003p.html#2 History of Computer Network Industry
http://www.garlic.com/~lynn/2004g.html#37 network history

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

Internet turns 35, still work in progress

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Internet turns 35, still work in progress
Newsgroups: alt.folklore.computers
Date: Sun, 29 Aug 2004 13:17:13 -0600

Internet turns 35, still work in progress
http://seattlepi.nwsource.com/business/aptech_story.asp?category=1700&slug=Internet%27s%20Birthday

and it was only last year that we had the stuff about internet turning
20 ... with the switch over from arpanet protocol to internetworking
protocol on 1/1/83.

and i've repeatedly claimed that the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

was larger than the arpanet/internet for most of the period; possibly
in large part because most of the internal net nodes had gateway like
function ... which didn't show up until the 1/1/83 great switch-over
... and help contribute to the internet passing the internal network
in number of nodes .... sometime in '85.

misc. past references to 1/1/83 ...
http://www.garlic.com/~lynn/2001c.html#4 what makes a cpu fast
http://www.garlic.com/~lynn/2001e.html#16 Pre ARPAnet email?
http://www.garlic.com/~lynn/2001l.html#35 Processor Modes
http://www.garlic.com/~lynn/2001m.html#48 Author seeks help - net in 1981
http://www.garlic.com/~lynn/2001m.html#54 Author seeks help - net in 1981
http://www.garlic.com/~lynn/2001n.html#5 Author seeks help - net in 1981
http://www.garlic.com/~lynn/2001n.html#6 Author seeks help - net in 1981
http://www.garlic.com/~lynn/2001n.html#87 A new forum is up! Q: what means nntp
http://www.garlic.com/~lynn/2002b.html#53 Computer Naming Conventions
http://www.garlic.com/~lynn/2002b.html#58 ibm vnet : Computer Naming Conventions
http://www.garlic.com/~lynn/2002g.html#19 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002g.html#30 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002g.html#35 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002g.html#40 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002g.html#71 Coulda, Woulda, Shoudda moments?
http://www.garlic.com/~lynn/2002h.html#5 Coulda, Woulda, Shoudda moments?
http://www.garlic.com/~lynn/2002h.html#11 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002h.html#48 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002h.html#79 Al Gore and the Internet
http://www.garlic.com/~lynn/2002.html#32 Buffer overflow
http://www.garlic.com/~lynn/2002j.html#64 vm marketing (cross post)
http://www.garlic.com/~lynn/2002k.html#19 Vnet : Unbelievable
http://www.garlic.com/~lynn/2002l.html#48 10 choices that were critical to the Net's success
http://www.garlic.com/~lynn/2002o.html#17 PLX
http://www.garlic.com/~lynn/2002q.html#4 Vector display systems
http://www.garlic.com/~lynn/2002q.html#35 HASP:
http://www.garlic.com/~lynn/2003c.html#47 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003d.html#59 unix
http://www.garlic.com/~lynn/2003e.html#36 Use of SSL as a VPN
http://www.garlic.com/~lynn/2003f.html#0 early vnet & exploit
http://www.garlic.com/~lynn/2003g.html#18 Multiple layers of virtual address translation
http://www.garlic.com/~lynn/2003g.html#44 Rewrite TCP/IP
http://www.garlic.com/~lynn/2003g.html#51 vnet 1000th node anniversary 6/10
http://www.garlic.com/~lynn/2003h.html#7 Why did TCP become popular ?
http://www.garlic.com/~lynn/2003h.html#16 Why did TCP become popular ?
http://www.garlic.com/~lynn/2003h.html#17 Why did TCP become popular ?
http://www.garlic.com/~lynn/2003i.html#32 A Dark Day
http://www.garlic.com/~lynn/2003j.html#1 FAST - Shame On You Caltech!!!
http://www.garlic.com/~lynn/2003l.html#0 One big box vs. many little boxes
http://www.garlic.com/~lynn/2003m.html#25 Microsoft Internet Patch
http://www.garlic.com/~lynn/2003n.html#44 IEN 45 and TCP checksum offload
http://www.garlic.com/~lynn/2003o.html#68 History of Computer Network Industry
http://www.garlic.com/~lynn/2003p.html#38 Mainframe Emulation Solutions
http://www.garlic.com/~lynn/2004d.html#13 JSX 328x printing (portrait)
http://www.garlic.com/~lynn/2004e.html#12 Pre-relational, post-relational, 1968 CODASYL "Survey of Data Base Systems"
http://www.garlic.com/~lynn/2004e.html#30 The attack of the killer mainframes
http://www.garlic.com/~lynn/2004f.html#30 vm
http://www.garlic.com/~lynn/2004f.html#32 Usenet invented 30 years ago by a Swede?
http://www.garlic.com/~lynn/2004f.html#35 Questions of IP
http://www.garlic.com/~lynn/2004g.html#7 Text Adventures (which computer was first?)
http://www.garlic.com/~lynn/2004g.html#8 network history
http://www.garlic.com/~lynn/2004g.html#12 network history
http://www.garlic.com/~lynn/2004g.html#26 network history
http://www.garlic.com/~lynn/2004g.html#30 network history
http://www.garlic.com/~lynn/2004g.html#31 network history
http://www.garlic.com/~lynn/2004g.html#32 network history
http://www.garlic.com/~lynn/2004g.html#33 network history
http://www.garlic.com/~lynn/2004.html#44 OT The First Mouse

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

capacity planning: art, science or magic?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: capacity planning: art, science or magic?
Newsgroups: alt.folklore.computers
Date: Sun, 29 Aug 2004 14:00:58 -0600

Capacity Planning: Art, Science or Magic?
http://itmanagement.earthweb.com/erp/article.php/3400851
recend thread x-posted to ibm-main & a.f.c;
history books on the development of capacity planning (SMF and RMF)
http://www.garlic.com/~lynn/2004j.html#53
history books on the development of capacity planning (SMF and RMF)
http://www.garlic.com/~lynn/2004j.html#55

and slightly related: ... using the mathematical technique of
regression to predict ...
http://abcnews.go.com/sections/SciTech/WhosCounting/bush_victory_whoscounting_paulos_math_040829-1.html

in the early 70s ... there were sort of three techniques being used at
the science center for performance.

1) modeling/simulation
2) instruction sampling
3) multiple regression analysis

very early in cp/67 development ... a cms application was created that
was originally called DUSETIMR (delta use time) ... which woke up
every 5-10 minutes and went digging around the cp kernel for all sorts
of counters, statistics, times, etc and logged the information. many
shops ran it and/or something similar and eventually years of
operational information was accumulated.

the huge amount of accumulated information across years of operation
of large number of different systems was used in both calibrating the
"1" modeling work as well as "3" input for the regression calculations.

The logged information was also used for developing workload and
system profiles ... which were used in the defintion of synthetic
workloads and benchmarks (which then were also calibrated against huge
amount of observed data). The combination of the huge amount of
observational data, models, synthetic workload and benchmarks also
contributed to the emerging defintion of capacity planning and
performance predictor. as mentioned before the benchmark and modeling
stuff
http://www.garlic.com/~lynn/submain.html#bench

that were part of the extensive calibration of the resource manager
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock

and the predictor was made available on HONE as a marketing tool
http://www.garlic.com/~lynn/subtopic.html#hone

the instruction sampling and the regression work was used to identify
"hotspots" that would be worth while of performance work ... the
instruction sampling for direct instruction hotspots and the
regression for functional hotspots.

the regression work was also useful in identifying long term trends
(across the years & years of accumulated operation statistics).

the instruction sampling was also used in identitying kernel features
to be migrated to microcode in virgul/tully (aka 370
138/148). Endicott came to cambridge with a comment that the machines
would have 6k bytes of microcode space for kernel assists. instruction
sampling was used to sample instruction location and then identify the
highest used 6k bytes of kernel code ... that was approximately
translated on byte-for-byte into microcode
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist

misc. other mcode posts
http://www.garlic.com/~lynn/subtopic.html#mcode

a few years ago ... i had an opportunity to use regression to pick out
functional hotspot on an extremely large and heavily used application
(scores of dedicated large mainframes) that had been studied and
optimized to death with instruction sampling ... and regression turned
up a functional hotspot accounting for nearly 30% of total utilization
... that wasn't showing up in instruction hotspot analysis.

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

Frontiernet insists on being my firewall

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Frontiernet insists on being my firewall...
Newsgroups: comp.security.firewalls
Date: Sun, 29 Aug 2004 14:50:18 -0600

ibuprofin@painkiller.example.tld (Moe Trin) writes:

As to "why block pings" - I can think of two reasons. First, it has
been abused and there _used_ to be a simple way to kill a windoze
box with a single ping (I'm relatively sure that few people are
still using versions that were vulnerable).  But at least one resent
worm/trojan targeting windoze boxes this Spirng was using a ping as
a precursor of the attack, and hosts that ignored pings were not
being attacked by that _particular_ worm/trojan.  Remember, the
Internet is not the same place that it was in the early 1990's.
When microsoft invented the telephone (or whatever) in August 1995,
they introduced 87 Bazzillion people to networking, and 99.999% of
those people shouldn't be trying to use something as complicated as
a digital watch, nevermind a VCR (which is _still_ blinking '12:00')
or a computer.

one might claim that home computer is more complex than driving a car
and therefor should have more training and licensing; the internet of
the 80s was more like the wild west wagon trails before speed limits,
traffic signals, traffic laws, etc.

when we were doing this thing for sever payment transactions and
payment gateway with small client/server startup
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

we could dictate a number of things like multiple a-record support
(for server to gateway interactions) ... recent related post
http://www.garlic.com/~lynn/2004k.html#20

however, the people doing the client were another matter, claiming
that things like multiple a-record support was way too advanced.

on the other hand at m'soft developers conference, jan, 1996 at
moscone, the tcp/ip developers from redmond that i tracked down all
understood readily about multiple a-record support (and said of course
their browswer supported it). on the other hand ... the constant
repeated refrain/theme at the conference was "protect your investment"
(i.e. all the vs/basic programmers weren't going to have to learn
something different).

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

US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of
 ASCII,Invento
Newsgroups: alt.folklore.computers
Date: Sun, 29 Aug 2004 18:39:13 -0600

Anne & Lynn Wheeler writes:

i've constantly attributed the big rise in minicomputers during (at
least) the late 70s and early 80s ... being the cost of computing
drop below some threshold, opening up a huge new market .... and
that market started moving to large workstation servers and large
PCs in the mid-80s. since that market segment appeared to have
opened up in the late 70s because of price sensitivity ... it
wouldn't be a surprise that it continued to be somewhat price
sensitive. this was possibly the start of customers ordering systems
in multiple hundreds at a time.

another indication was that there were at least half dozen to a dozen
companies making 4341 clones in the era .... able to run off-the-shelf
ibm operating systems.

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

August 23, 1957

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: August 23, 1957
Newsgroups: alt.sys.pdp10,alt.folklore.computers
Date: Mon, 30 Aug 2004 09:55:50 -0600

iddw@hotmail.com (Dave Hansen) writes:

Last I heard, ISO Pascal still requires all source code to reside in
one file.  If true, I would venture to say the Pascal is not
suitable for programming anything but student homework problems.
For which I concede is is quite good.

If not true, I think I still would prefer Modula-2 for real-world
(including, but not limited to, machine OS) programming.

long ago and far away i did a port of 50k-60k statement vs/pascal
application (multiple source modules) to other platforms. i don't
think these other platforms had ever seen a 50k-60k statement pascal
program. complicating it, one of the vendors had outsourced their
pascal to a organization on the other side of the world.

early mainframe tcp/ip product implementation was also done in
vs/pascal ...  which i had to deal with when doing rfc1044 support
... recent topic drift:
http://www.garlic.com/~lynn/2004k.html#29 CDC STAR-100

random past posts mentioning vs/pascal:
http://www.garlic.com/~lynn/2000.html#15 Computer of the century
http://www.garlic.com/~lynn/2001b.html#30 perceived forced conversion from cp/m to ms-dos in late 80's
http://www.garlic.com/~lynn/2002n.html#66 Mainframe Spreadsheets - 1980's History
http://www.garlic.com/~lynn/2002q.html#19 Beyond 8+3
http://www.garlic.com/~lynn/2002q.html#27 Beyond 8+3
http://www.garlic.com/~lynn/2003b.html#33 dasd full cylinder transfer (long post warning)
http://www.garlic.com/~lynn/2003b.html#44 filesystem structure, was tape format (long post)
http://www.garlic.com/~lynn/2003c.html#77 COMTEN- IBM networking boxes
http://www.garlic.com/~lynn/2003h.html#52 Question about Unix "heritage"
http://www.garlic.com/~lynn/2003k.html#63 SPXTAPE status from REXX
http://www.garlic.com/~lynn/2003o.html#16 When nerds were nerds
http://www.garlic.com/~lynn/2003o.html#21 TSO alternative
http://www.garlic.com/~lynn/2004c.html#25 More complex operations now a better choice?
http://www.garlic.com/~lynn/2004f.html#42 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#19 HERCULES
http://www.garlic.com/~lynn/2004g.html#27 Infiniband - practicalities for small clusters

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

Big Bertha Thing blogs

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Big Bertha Thing blogs
Newsgroups: alt.folklore.computers
Date: Mon, 30 Aug 2004 15:46:15 -0600

dgriffi writes:

"Big Bertha" was originally a huge artillery piece produced by
Germany during WW2.  Since then, the term "Big Bertha" has been
applied to other things.  What readily pops into mind is a
particular model rocket kit made by Estes.

earlier ...

http://www.firstworldwar.com/atoz/bigbertha.htm

Although the name was commonly applied to a whole variety of
large-calibre German artillery guns the "Big Bertha" ('Dicke Berta')
actually referred to a single siege gun, at that time the world's
largest and most powerful.

Produced by the German firm of Krupp the Big Bertha was a 42cm
howitzer, model L/14 designed in the aftermath of the Russo-Japanese
War of 1904 on behalf of the German Army.  It was initially used as a
means of (successfully) demolishing the fortress towns of Liege and
Namur in August 1914, the war's first month (and subsequently as
Antwerp).  It was thereafter used to similarly reduce other enemy
strong-points as the need arose.

....

http://www.worldwar1.com/heritage/bbertha.htm

Big Bertha was the the 420mm (16.5-in.) howitzer used by German forces
advancing through Belgium in 1914. They were nicknamed for the Krupp
arms works matriarch Bertha Krupp von Bohlen. Transported in pieces,
moved by rail and assembled in place, they proved devastating in
destroying Belgian forts. They were somewhat less effective against
French Forts of sturdier design. The howitzers were also used as siege
weapons on the eastern front. By 1917, less accurate due to wear on
the barrels and extremely vulnerable to counter battery fire once
located, they were phased out of operation. The term "Big Bertha" is
sometimes applied to the Krupp manufactured artillery piece of
completely different design that shelled Paris in 1918 from the
phenomenal range of 75 miles. This later weapon, however, is more
commonly known as the "Paris Gun".

....

also
http://www.firstworldwar.com/battles/antwerp.htm
http://www.greatwar.co.uk/westfront/ypsalient/secondypres/prelude/ypbombbertha.htm
http://www.worldwar1.com/arm002.htm

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

Vintage computers are better than modern crap !

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Vintage computers are better than modern crap !
Newsgroups: alt.folklore.computers
Date: Tue, 31 Aug 2004 08:06:37 -0600

K Williams writes:

Sure, moons ago I had a PL/I-like construct (IF/THEN/ELSE/ENDIF,
WHILE, UNTIL, SELECT/WHEN,...) macro library for M$ MASM.  When I
took my first C course (20ish years ago) I thought, "wow another
macro assembler".  Apparently I wasn't the only one to see it.  ;-)

in the early 70s, i wrote a pli program that input assembler listing
and did code flow construction, register use analysis, and attempted
to spit out high-level representation using if/then/else/do-while/etc
psuedo language ... and somewhat trying to do goto-less ... slightly
related mention of harlen mills presentation i attended in
the early 70s (recent comp.arch thread):
http://www.garlic.com/~lynn/2004k.html#24 Timeless Classics of Software Engineering
http://www.garlic.com/~lynn/2004k.html#25 Timeless Classics of Software Engineering
http://www.garlic.com/~lynn/2004k.html#26 Timeless Classics of Software Engineering

on of the problems there were some relatively straight-forward branch
constructs from modest assembler source that would nest 10 or more
levels deep. i finally had put in limit to not next more than 5-6
levels deep.

i have vague recollection that the slac mods to the h-assembler (late
70s, early 80s) included marco package for if/then/else code (as
opposed to if/then/else constructs for conditional code generation)
... but the quick search engine use only turns up references to actual
assembler enhancements ... not related macro package.

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

Wars against bad things

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Wars against bad things
Newsgroups: alt.folklore.computers
Date: Tue, 31 Aug 2004 08:54:30 -0600

Peter Flass writes:

But of course these 40K virtual penguins weren't actually *doing*
anything.

but they got thru boot .... part of the issue was showing that you
could aggregate a lot of relatively low-useage "machines" into single
hardware complex and share resources ... while still keeping
separation and partitioning. has since somewhat been used for
web-hosting where you can do use the aggregation to help with capacity
planning.

the customer installation issue was then number & mix of machines with
regard to their cpu cycles needed.

there was some talk at recent share meeting that ibm started to really
take notice of the linux phenomena after somebody did a report on the
number of customer mainframes running it (which appeared to be all new
mainframe business ... apparently displacing otherwise non-ibm,
non-mainframe business) ... aka it was a customer driven reaction.

at the time, there was some referernce to the test was with vm running
in a "test lpar" i.e. the vm system doing the 40k linux test ... was
running in a subset of the machine.

some time ago ... a subset of the vm function was migrated into the
hardware and referred to as logical partitions (or LPARs). it is
similar to function provided by virtual machine operating system
... except they do some optimization ... like partitioning real memory
so that LPAR memory is dedicated ... no support for moving pages
back&forth to disk. the configuration of lpar is done in the
"microcode" or service processor ... specifying the amount of real
memory, which i/o devices, and how-many &/or what percentage of
processors.

on the real "bare" machine &/or in an partition of a LPAR configurated
machine it is then possible to boot a vm (virtual machine) operating
system ... which then provides more granular resource allocation (than
is nominal used in LPAR operation).

lots of LPAR references:
http://www.garlic.com/~lynn/98.html#45 Why can't more CPUs virtualize themselves?
http://www.garlic.com/~lynn/98.html#57 Reliability and SMPs
http://www.garlic.com/~lynn/99.html#191 Merced Processor Support at it again
http://www.garlic.com/~lynn/2000.html#8 Computer of the century
http://www.garlic.com/~lynn/2000.html#63 Mainframe operating systems
http://www.garlic.com/~lynn/2000.html#86 Ux's good points.
http://www.garlic.com/~lynn/2000b.html#50 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000b.html#51 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000b.html#52 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000b.html#61 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000b.html#62 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000c.html#8 IBM Linux
http://www.garlic.com/~lynn/2000c.html#50 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#68 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#76 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000f.html#78 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000g.html#3 virtualizable 360, was TSS ancient history
http://www.garlic.com/~lynn/2001.html#34 Competitors to SABRE?
http://www.garlic.com/~lynn/2001b.html#72 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001d.html#67 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001e.html#5 SIMTICS
http://www.garlic.com/~lynn/2001e.html#61 Estimate JCL overhead
http://www.garlic.com/~lynn/2001f.html#17 Accounting systems ... still in use? (Do we still share?)
http://www.garlic.com/~lynn/2001f.html#23 MERT Operating System & Microkernels
http://www.garlic.com/~lynn/2001h.html#2 Alpha:  an invitation to communicate
http://www.garlic.com/~lynn/2001h.html#33 D
http://www.garlic.com/~lynn/2001l.html#24 mainframe question
http://www.garlic.com/~lynn/2001m.html#38 CMS under MVS
http://www.garlic.com/~lynn/2001n.html#26 Open Architectures ?
http://www.garlic.com/~lynn/2001n.html#31 Hercules etc. IBM not just missing a great opportunity...
http://www.garlic.com/~lynn/2001n.html#32 Hercules etc. IBM not just missing a great opportunity...
http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
http://www.garlic.com/~lynn/2002c.html#53 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than   It Can Chew?)
http://www.garlic.com/~lynn/2002d.html#31 2 questions: diag 68 and calling convention
http://www.garlic.com/~lynn/2002e.html#25 Crazy idea: has it been done?
http://www.garlic.com/~lynn/2002e.html#75 Computers in Science Fiction
http://www.garlic.com/~lynn/2002f.html#6 Blade architectures
http://www.garlic.com/~lynn/2002f.html#57 IBM competes with Sun w/new Chips
http://www.garlic.com/~lynn/2002n.html#6