List of Archived Posts
2008 Newsgroup Postings (07/30 - 08/16)
- IBM-MAIN longevity
- IBM-MAIN longevity
- IBM-MAIN longevity
- IBM-MAIN longevity
- IBM-MAIN longevity
- IBM-MAIN longevity
- IBM-MAIN longevity
- IBM-MAIN longevity
- IBM-MAIN longevity
- IBM-MAIN longevity
- IBM-MAIN longevity
- recent mentions of 40+ yr old technology
- IBM-MAIN longevity
- IBM-MAIN longevity
- recent mentions of 40+ yr old technology
- Code Page 1047 vs 037 - Green card confusion
- IBM-MAIN longevity
- IBM-MAIN longevity
- recent mentions of 40+ yr old technology
- IBM-MAIN longevity
- IBM-MAIN longevity
- recent mentions of 40+ yr old technology
- dollar coins
- Memories of ACC, IBM Channels and Mainframe Internet Devices
- dollar coins
- dollar coins
- dollar coins
- dollar coins
- Verifying Verified By Visa - Registration breaks chain of trust
- Verifying Verified By Visa - Registration breaks chain of trust
- Verifying Verified By Visa - Registration breaks chain of trust
- Authentication in the e-tailer / payment gateway / customer triangle
- Authentication in the e-tailer / payment gateway / customer triangle
- Authentication in the e-tailer / payment gateway / customer triangle
- Authentication in the e-tailer / payment gateway / customer triangle
- Quality of IBM school clock systems?
- dollar coins
- dollar coins
- dollar coins
- dollar coins
- dollar coins
- dollar coins
- dollar coins
- recent mentions of 40+ yr old technology
- dollar coins
- z/OS BIND9 DNS Vulnerable to Cache Poisoning Attack Problem?
- z/OS BIND9 DNS Vulnerable to Cache Poisoning Attack Problem?
- Intel: an expensive many-core future is ahead of us
- Intel: an expensive many-core future is ahead of us
- Quality of IBM school clock systems?
- IBM manual web pages
- Monetary affairs on free reign, but the horse has Boulton'd
- Payments Security in RFS
- Quality of IBM school clock systems?
- dollar coins
- Intel: an expensive many-core future is ahead of us
- Intel: an expensive many-core future is ahead of us
- No offense to any one but is DB2/6000 an old technology. Does anybody still use it, if so what type of industries??
- Intel: an expensive many-core future is ahead of us
- Intel: an expensive many-core future is ahead of us
- recent mentions of 40+ yr old technology
- Osama bin Laden gets a cosmetic makevover in his British Vanity Passport
- Intel: an expensive many-core future is ahead of us
- Early commercial Internet activities (Re: IBM-MAIN longevity)
- Blinkylights
- Crippleware: hardware examples
- Blinkylights
- dollar coins
- Taxes
- Verifying Verified By Visa - Registration breaks chain of trust
- dollar coins
- md5
- Error handling for system calls
- Blinkylights
- Blinkylights
- Intel: an expensive many-core future is ahead of us
- squirrels
- Blinkylights
- Yet another squirrel question - Results (very very long post)
- Book: "Everyone Else Must Fail" --Larry Ellison and Oracle ???
- Book: "Everyone Else Must Fail" --Larry Ellison and Oracle ???
- Intel: an expensive many-core future is ahead of us
- Yet another squirrel question - Results (very very long post)
- old 370 info
- Yet another squirrel question - Results (very very long post)
- old 370 info
- Yet another squirrel question - Results (very very long post)
- Yet another squirrel question - Results (very very long post)
- Book: "Everyone Else Must Fail" --Larry Ellison and Oracle ???
- Fraud due to stupid failure to test for negative
IBM-MAIN longevity
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM-MAIN longevity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 30 Jul 2008 19:00:55 -0400
kkt <kkt@zipcon.net> writes:
I think you're misrepresenting Arpanet by the 1980s. Many, many US
universities were on it, not just a few. Of the universities I know
about, more were on Arpanet than on Bitnet. If you count individuals
with access, rather than nodes, Arpanet probably had more.
Also, it would be a mistake to ignore other networks. If you just
wanted e-mail and file transfer on a shoestring budget, there was
always UUCP. Probably more reachable hosts than Bitnet and Arpanet
put together.
re:
http://www.garlic.com/~lynn/2008k.html#85 IBM-MAIN longevity
the quote was from
lsoft's listserv history:
http://www.lsoft.com/products/listserv-history.asp#bitnet
you might cut him a little slack ... since it seems to be from
perspective of europe (and EARN).
note that a lot of the (non-bitnet) connectivity in the states was csnet
http://en.wikipedia.org/wiki/CSNET
from above:
It was a forerunner to NSFNet. CSNET operated autonomously until 1989,
when it merged with Bitnet to form CREN. By 1991 the growth of the
Internet had made the CSNET services redundant, and CREN discontinued
them.
... snip ..
CSNET supported a number of connectivity technologies as referenced
in this reference to connection between sjr and csnet in fall of '82
http://www.garlic.com/~lynn/98.html#email821022
in this old post
http://www.garlic.com/~lynn/98.html#59
nsfnet wiki site
http://en.wikipedia.org/wiki/NSFNet
my view of nsfnet was the rfp for T1 backbone; NSFNET program
announcement
http://www.garlic.com/~lynn/2002k.html#12
and NSFNET award announcement reference:
htpt://www.garlic.com/~lynn/2000e.html#10
... as opposed to the earlier 56kbit links mentioned here
http://www.garlic.com/~lynn/2008j.html#41 NSFnet -- 20 Years of Internet Obscurity and Insight
above has reference to:
NSF and the Birth of the Internet
http://www.nsf.gov/news/special_reports/nsf-net/textonly/index.jsp
that mentions the 56kbit links between the five NSF supercomputer
centers and NCAR.
the 56kbit link references make it sound much more like networking
interconnect of the five NSF supercomputer centers and NCAR.
a quote from the NSFNET award reference makes it sound much more like a
"backbone" providing internetworking of the 12 regional networks:
On November 24th, 1987 the National Science Foundation announced that
MERIT, supported by IBM and MCI was selected to develop and operate the
evolving NSF Network and gateways integrating 12 regional networks.
... snip ...
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
IBM-MAIN longevity
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM-MAIN longevity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 30 Jul 2008 21:29:18 -0400
kkt <kkt@zipcon.net> writes:
Also, it would be a mistake to ignore other networks. If you just
wanted e-mail and file transfer on a shoestring budget, there was
always UUCP. Probably more reachable hosts than Bitnet and Arpanet
put together.
re:
http://www.garlic.com/~lynn/2008k.html#85 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#0 IBM-MAIN longevity
following from an internet monthly status report:
The NSFnet is an internet originally designed to provide access to
NSF-funded supercomputers. Prospective supercomputer sites
initially proposed their own consortium networks. These access
networks were later augmented by a nationwide backbone which
interconnects the supercomputer sites. Additional proposals were
received and funded by the NSF to enrich the NSFnet infrastructure
by building new regional networks and attaching them to the
backbone, and by helping existing networks to attach.
The NSFnet backbone sites are located at Cornell University, the
University of Illinois (Urbana Campus), the John von Neumann Center
in Princeton, the National Center for Atmospheric Research, the
Pittsburgh Supercomputing Center and the San Diego Supercomputing
Center.
Regional/consortium networks currently existing or being
implemented are the Bay Area Regional Research network (BARRnet),
the consortium networks of the John von Neumann Center and the San
Diego Supercomputer Center and the network of the Pittsburgh
Supercomputer Academic Affiliates (PSCAAnet), WESTnet,
NORTHWESTnet, NYSERnet in New York State, MIDnet in the Midwest,
SESQUInet in the Houston area, SURAnet in the Southeast, and the
University SAtellite Network pilot project (USAN).
Pre-existing networks being connected include the Merit Computer
Network in Michigan, CSNET, and the ARPANET - which is being
augmented to include a number of NSF-specified sites.
Active collaboration and coordination between DARPA and NSF is
carried out under the terms of a Memorandum of Understanding signed
by the Director of each agency. The NSFnet has already a richly
connected infrastructure, building upon and partly using DARPA-
developed protocols and systems; DARPA's pioneering network
research has played an important role in the implementation of the
NSFnet, and many participants in the DARPA-funded efforts are also
active in helping the ambitious NSFnet program to succeed.
... snip ...
and arpanet was still being called arpanet:
ARPANET STATUS
The ARPANET experienced another period of extreme congestion
beginning in late January and lasting roughly through mid-February.
During this period service across gateways was particularly bad.
Over the past six months, transmission capacity in the ARPANET has
been critical, especially on the network's cross-country paths.
The congestion experienced in January and February was due
primarily to a modest increase in traffic that pushed the ARPANET
"over the edge".
... snip ...
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
IBM-MAIN longevity
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM-MAIN longevity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 30 Jul 2008 22:14:11 -0400
re:
http://www.garlic.com/~lynn/2008k.html#81 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008k.html#83 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008k.html#85 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#0 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#1 IBM-MAIN longevity
old quote from joe morris regarding number of nodes sometime in 1985:
http://www.garlic.com/~lynn/2002k.html#26 DEC eNet: was Vnet : Unbelievable
http://www.garlic.com/~lynn/2006t.html#50 The Future of CPUs: What's After Multi-Core?
BITNET 435
ARPAnet 1155
CSnet 104 (excluding ARPAnet overlap)
VNET 1650
EasyNet 4200
UUCP 6000
USENET 1150 (excluding UUCP nodes)
... snip ...
the following from CSnet history:
http://www.livinginternet.com/i/ii_csnet.htm
The history of the CSNET is a story of enterprising academic
entrepreneurship, and yet another example of TCP/IP's inexorable drive
to spread. In 1979, most U.S. universities weren't doing research with
the Department of Defence and so weren't connected to the ARPANET, but
were increasingly aware of the network's advantages and wanted to level
the research playing field. With seed funding and support from Kent
Curtis at the National Science Foundation, Larry Landweber at the
University of Wisconsin-Madison put together a proposal to build a
network to connect non-ARPANET computer science departments. The
proposal made its way to Dave Farber for review, who gave it to one of
his graduate students, Dave Crocker, who thought it was an interesting
idea but, like others, worried about the university's lack of networking
experience.
to provide networking connectivity to educational institutions not
involved with DOD (and allowed to have access to arpanet).
in that sense ... the number of bitnet nodes in 1985 being four times
larger than the non-DOD academic csnet nodes ... may support the
reference at the lsoft website by the listserv author
http://www.lsoft.com/products/listserv-history.asp#bitnet
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
IBM-MAIN longevity
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM-MAIN longevity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 30 Jul 2008 22:43:25 -0400
for something a little different:
Project to rebuild Internet gets $12M, bandwidth
http://news.yahoo.com/s/ap/tec_techbit_rebuilding_the_internet
from above:
A massive project to redesign and rebuild the Internet from scratch is
inching along with $12 million in government funding and donations of
network capacity by two major research organizations.
... snip ...
website:
http://geni.net/
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
IBM-MAIN longevity
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM-MAIN longevity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 31 Jul 2008 07:59:10 -0400
kkt <kkt@zipcon.net> writes:
I note that CSnet used TCP/IP and gatewayed to the Arpanet, NSFnet,
etc., without the user needing to be aware of which networks their
packets were travelling over. That's the central feature of the
Internet, regardless of whether it was before or after the name
change.
that is somewhat the periodic refrain that tcp/ip was the technology
basis for the Internet (i.e. internetworking), nsfnet was the
operational basis for the Internet, and CIX was the business basis for
the Internet.
http://www.garlic.com/~lynn/2008k.html#85 IBM-MAIN longevity
tcp/ip wasn't absolutely required for end-to-end operation ... but it
made it a lot easier. csnet was moving email (users didn't really care
about the underlying transport format) transparently across a variety of
different protocols ... prior to tcp/ip ... i.e. same reference
http://www.garlic.com/~lynn/2008k.html#85 IBM-MAIN longevity
references oct82 csnet connectivity announcement
http://www.garlic.com/~lynn/98.html#email821022
in this post
http://www.garlic.com/~lynn/98.html#59
which lists some of the different protocols in use by csnet ... prior to
the arpanet cutoff to tcp/ip on 1/1/83.
gateways of various flavors were needed for moving across protocol
boundaries prior to tcp/ip (and many continued in use after the arpanet
tcp/ip cutover on 1/1/83)
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
IBM-MAIN longevity
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM-MAIN longevity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 31 Jul 2008 08:08:32 -0400
Peter Flass <Peter_Flass@Yahoo.com> writes:
Maybe in your world, but only large universities could afford ARPANet
connections. Smaller colleges, and I was working at one, could easily
afford Bitnet connectivity. I would guess that in the State
University of New York system, possibly six or so sites would have hat
ARPANet connectivity for research - the four university centers
naturally, plus a couple of the larger four-year colleges. I believe
all 64 campuses had a Bitnet connection.
and as in the justification for starting csnet
http://www.garlic.com/~lynn/2008l.html#2 IBM-MAIN longevity
... was requiring some sort of DOD affiliation ... part of what kicked
this off was that the original IBM-MAIN thread was question about when
the IBM-MAIN (listserv) mailing originated (on BITNET) ... and
suggesting that the lsoft website &/or listserv author might know.
the lsoft website had some historical timeline ... including
the quote about BITNET (&/or EARN)
http://www.garlic.com/~lynn/2008k.html#85 IBM-MAIN longevity
and the comment may have been somewhat been a non-US centric
perspective
http://www.garlic.com/~lynn/2008l.html#0 IBM-MAIN longevity
since non-US educational institutions may had more difficulty with DOD
affiliations ... independent of the cost.
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
IBM-MAIN longevity
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM-MAIN longevity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 31 Jul 2008 08:33:11 -0400
kkt <kkt@zipcon.net> writes:
This seems really low and I haven't found the source of these
statistics in a reasonable look. Are they counting member
institutions instead of computers?
For comparison, the hosts.txt table that shows all the hosts directly
routable plus foreign networks and gateways as of 4 Feb. 1988 is
available from
http://pdp-10.trailing-edge.com/bb-ev83b-bm/01/new-system/hosts.txt.html
This must be about the last centrally maintained hosts.txt file from
SRI-NIC. My count is 807 networks, 223 gateways, and 5496 hosts.
Give or take one or two for comment lines.
re:
http://www.garlic.com/~lynn/2008l.html#2 IBM-MAIN longevity
after tcp/ip cutover on 1/1/83 ... there was fairly rapid growth. at
the time of the cut-over, arpanet had somewhere between 100 nodes and
250 hosts (different sources cite different counts ... it is possible
nodes were the network node IMPs which might have one or more
connected hosts?).
one of the reference posts
http://www.garlic.com/~lynn/2006t.html#50 The Future of CPUs: What's After Multi-Core?
BITNET 435
ARPAnet 1155
CSnet 104 (excluding ARPAnet overlap)
VNET 1650
EasyNet 4200
UUCP 6000
USENET 1150 (excluding UUCP nodes)
... snip ...
also had one of my old emails from 85
http://www.garlic.com/~lynn/2006t.html#email850625
complaining about cost of DES link encryptors for HSDT
project
http://www.garlic.com/~lynn/subnetwork.html#hsdt
and commenting about internal network approaching 2000 nodes ... and all
links requiring link encryptors. The HSDT links were T1 and higher
... so I was paying a lot more ... than the rest of the links which were
56kbits or slower.
anyway ... the reference
http://www.garlic.com/~lynn/2006t.html#50 The Future of CPUs: What's After Multi-Core?
also includes an old info.nets reference from 18feb89 quoting
BITNET 01/18/85 435 University/nonprofit/research network
Arpanet 01/22/85 1155 DoD related
... snip ...
which matches numbers provided by Joe.
also referenced was ... The December 1988 BITNET nodes file contains
2691 entries. This includes BITNET/NETNORTH/EARN nodes
also showing that the rate of increase in number of nodes was increasing
in 85-88 period.
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
IBM-MAIN longevity
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM-MAIN longevity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 31 Jul 2008 09:02:12 -0400
Anne & Lynn Wheeler <lynn@garlic.com> writes:
also includes an old info.nets reference from 18feb89 quoting
BITNET 01/18/85 435 University/nonprofit/research network
Arpanet 01/22/85 1155 DoD related
... snip ...
re:
http://www.garlic.com/~lynn/2006l.html#2 IBM-MAIN longevity
http://www.garlic.com/~lynn/2006l.html#6 IBM-MAIN longevity
the info.nets reference:
From: magill@eniac.seas.upenn.edu (Operations Manager)
Newsgroups: info.nets
Subject: "world net" size
Date: 17 Feb 89 19:32:42 GMT
Date-Received: 18 Feb 89 19:00:50 GMT
To: info-nets@Think.COM
> Does anyone have a current table of size estimates for the academic
> and research networks?
>
> Network as of count Description
> -------- -------- ----- -----------------------------------------------
> BITNET 01/18/85 435 University/nonprofit/research network
> Arpanet 01/22/85 1155 DoD related
The December 1988 BITNET nodes file contains 2691 entries.
This includes BITNET/NETNORTH/EARN nodes.
The growth of the Internet has been explosive.
... snip ...
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
IBM-MAIN longevity
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM-MAIN longevity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 31 Jul 2008 09:39:01 -0400
kkt <kkt@zipcon.net> writes:
This must be about the last centrally maintained hosts.txt file from
SRI-NIC. My count is 807 networks, 223 gateways, and 5496 hosts.
Give or take one or two for comment lines.
During the 80s, I use to shadow much of nisc.sri.com (actually was
shadowing 60-70 locations) ... automated process checking new/changed
files and fetching ... it was in large part oriented towards making sure
having all current RFCs ... but also some number of other files. then
the files moved to nnsc.nsf.net and then to "internic" ... and now RFCs
are at rfc-editor (aka isi).
old post (in thread similar to this one):
http://www.garlic.com/~lynn/2000e.html#20 Is Al Gore The Fater of the Internet?
I included a list of all domain names from the oct90 domain list.
i still have automated process to shadow RFCs at rfc-editor ... it is
part of maintaining rfc index
http://www.garlic.com/~lynn/rfcietff.htm
and in earlier versions of STD1, I provided section 6.10 that listed RFC
status inconsistencies.
past posts in this thread:
http://www.garlic.com/~lynn/2008k.html#81 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008k.html#83 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008k.html#85 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#0 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#1 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#2 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#3 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#4 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#5 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#6 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#7 IBM-MAIN longevity
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
IBM-MAIN longevity
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM-MAIN longevity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 31 Jul 2008 10:28:03 -0400
Roger Blake <rogblake10@iname10.com> writes:
A few of the man pages from my BSD 4.1 programmer's manual (circa early
1980s) reference the internet.
and as per the info.nets reference
http://www.garlic.com/~lynn/2008l.html#7 IBM-MAIN longevity
frequently the interconnected/gatewayed networks were referred to as
internet ... even when it wasn't all tcp/ip. in the info.nets reference
the comment is about the explosive internet growth with regard to the
485 bitnet nodes on 18jan85 and the 2691 nodes in dec88 (over 550%)
the reference to the modern internet ... my comments have been the
technology from tcp/ip protocol, operations from nsfnet, and business
from cix.
http://www.garlic.com/~lynn/2008k.html#85 IBM-MAIN longevity
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
IBM-MAIN longevity
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM-MAIN longevity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 31 Jul 2008 12:50:08 -0400
Peter Flass <Peter_Flass@Yahoo.com> writes:
It sounds like the trend lines crossed in the 1988-89 timeframe.
part of the issue in the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet
being larger than arpanet from just about the beginning until possible
mid-85 was that the technology used in the internal network effectively
had a form of gateway built into every node.
centralized control ... as either technology and/or business would
be a growth inhibitor.
that is past statements about arpanet being somewhere between 100 nodes
and 250 hosts at the time of the 1/1/83 switchover to tcp/ip (arpanet
was both centralized homogeneous protocol and operational control
... switch to tcp/ip improved homogeneous technology issues) ... at a
point when the internal network was approaching 1000. old reference to
internal network reaching 1000 nodes:
http://www.garlic.com/~lynn/99.html#112 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
http://www.garlic.com/~lynn/2003j.html#10 20th anv of 1000th node on internal network
internal network continued to grow in size thru the mid-80s with the
rapid growth in the number of internal mid-range mainframes. the
internal growth of mainframes then started to slack off in the mid-80s,
similar to shift in the customer market from mid-range machines &
departmental servers to workstations and larger PCs. This has been
frequently discussed here with regard to change in mid-range sales for
both 43xx machines as well as vax machines in the mid-80s.
externally ... there was still rapid growth because the environment 1)
had started much later with pervasive network introduction and 2)
increasing number of workstation and PC nodes.
this is a post that includes a list cities with internal locations that
added one or more new nodes during 1983 (it also includes a sample of
some of the new nodes added during 1983):
http://www.garlic.com/~lynn/2006k.html#8 Arpa address
a major paradigm change was migration of end-to-end networking protocols
into workstations and PCs ... which went a long way to exploding the
number of "internet" nodes. On the internal network, workstations and
PCs were still being dealt with using terminal emulation
http://www.garlic.com/~lynn/subnetwork.html#emulation
in fact, the communication division SAA strategy appeared to try and
constrain customer terminal emulation environments from moving to
client/server. in that time-frame, we had come up with 3tier networking
architecture and were out making customer executive presentations (and
taking some amount of hits from the communication division).
http://www.garlic.com/~lynn/subnetwork.html#3tier
other posts in this thread:
http://www.garlic.com/~lynn/2008k.html#81 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008k.html#83 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008k.html#85 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#0 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#1 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#2 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#3 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#4 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#5 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#6 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#7 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#8 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#9 IBM-MAIN longevity
there have been similar threads that have played out in this
n.g. in the past (from 2006):
http://www.garlic.com/~lynn/2006j.html#34 Arpa address
http://www.garlic.com/~lynn/2006j.html#45 Arpa address
http://www.garlic.com/~lynn/2006j.html#46 Arpa address
http://www.garlic.com/~lynn/2006j.html#49 Arpa address
http://www.garlic.com/~lynn/2006j.html#50 Arpa address
http://www.garlic.com/~lynn/2006j.html#53 Arpa address
http://www.garlic.com/~lynn/2006k.html#3 Arpa address
http://www.garlic.com/~lynn/2006k.html#8 Arpa address
http://www.garlic.com/~lynn/2006k.html#9 Arpa address
http://www.garlic.com/~lynn/2006k.html#10 Arpa address
http://www.garlic.com/~lynn/2006k.html#12 Arpa address
http://www.garlic.com/~lynn/2006k.html#40 Arpa address
http://www.garlic.com/~lynn/2006k.html#42 Arpa address
http://www.garlic.com/~lynn/2006k.html#43 Arpa address
or (from 2002):
http://www.garlic.com/~lynn/2000d.html#43 Al Gore: Inventing the Internet...
http://www.garlic.com/~lynn/2000d.html#56 Is Al Gore The Father of the Internet?
http://www.garlic.com/~lynn/2000d.html#58 Is Al Gore The Father of the Internet?
http://www.garlic.com/~lynn/2000d.html#59 Is Al Gore The Father of the Internet?
http://www.garlic.com/~lynn/2000d.html#63 Is Al Gore The Father of the Internet?
http://www.garlic.com/~lynn/2000d.html#67 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000d.html#70 When the Internet went private
http://www.garlic.com/~lynn/2000d.html#77 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000e.html#5 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000e.html#10 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000e.html#11 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000e.html#13 internet preceeds Gore in office.
http://www.garlic.com/~lynn/2000e.html#14 internet preceeds Gore in office.
http://www.garlic.com/~lynn/2000e.html#15 internet preceeds Gore in office.
http://www.garlic.com/~lynn/2000e.html#18 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000e.html#19 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000e.html#20 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000e.html#26 Al Gore, The Father of the Internet (hah!)
http://www.garlic.com/~lynn/2000e.html#28 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000e.html#31 Cerf et.al. didn't agree with Gore's claim of initiative.
http://www.garlic.com/~lynn/2000e.html#38 I'll Be! Al Gore DID Invent the Internet After All ! NOT
http://www.garlic.com/~lynn/2000e.html#39 I'll Be! Al Gore DID Invent the Internet After All ! NOT
http://www.garlic.com/~lynn/2000f.html#44 Al Gore and the Internet (Part 2 of 2)
http://www.garlic.com/~lynn/2000f.html#45 Al Gore and the Internet (Part 2 of 2)
http://www.garlic.com/~lynn/2000f.html#46 Al Gore and the Internet (Part 2 of 2)
http://www.garlic.com/~lynn/2000f.html#47 Al Gore and the Internet (Part 2 of 2)
http://www.garlic.com/~lynn/2000f.html#49 Al Gore and the Internet (Part 2 of 2)
http://www.garlic.com/~lynn/2000f.html#50 Al Gore and the Internet (Part 2 of 2)
http://www.garlic.com/~lynn/2000f.html#51 Al Gore and the Internet (Part 2 of 2)
http://www.garlic.com/~lynn/2002h.html#79 Al Gore and the Internet
http://www.garlic.com/~lynn/2002h.html#80 Al Gore and the Internet
http://www.garlic.com/~lynn/2002h.html#81 Al Gore and the Internet
http://www.garlic.com/~lynn/2002h.html#82 Al Gore and the Internet
http://www.garlic.com/~lynn/2002h.html#85 Al Gore and the Internet
http://www.garlic.com/~lynn/2002h.html#86 Al Gore and the Internet
http://www.garlic.com/~lynn/2002i.html#15 Al Gore and the Internet
http://www.garlic.com/~lynn/2002i.html#28 trains was: Al Gore and the Internet
http://www.garlic.com/~lynn/2002i.html#35 pop density was: trains was: Al Gore and the Internet
http://www.garlic.com/~lynn/2002i.html#36 pop density was: trains was: Al Gore and the Internet
http://www.garlic.com/~lynn/2002l.html#70 Al Gore and Fidonet [was: 10 choices]
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
recent mentions of 40+ yr old technology
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: recent mentions of 40+ yr old technology
Newsgroups: alt.folklore.computers
Date: Thu, 31 Jul 2008 13:49:10 -0400
Report: Microsoft prepares for end of Windows with Midori
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=009111018
from above:
July 29, 2008 (IDG News Service) With the Internet increasingly taking
on the role of the PC operating system and the growing prevalence of
virtualization technologies, there likely will be a day when the Windows
client operating system as it has been developed for the past 20-odd
years becomes obsolete.
According to published reports, Microsoft Corp. seems to be preparing
for that day with an incubation project codenamed Midori, which seeks to
create a componentized, non-Windows operating system that will take
advantage of technologies not available when Windows first was
conceived.
... snip ...
other recent posts in this (particular virtualization) thread
http://www.garlic.com/~lynn/2008k.html#45 recent mentions of 40+ yr old technology
http://www.garlic.com/~lynn/2008k.html#46 recent mentions of 40+ yr old technology
http://www.garlic.com/~lynn/2008k.html#52 recent mentions of 40+ yr old technology
http://www.garlic.com/~lynn/2008k.html#53 recent mentions of 40+ yr old technology
http://www.garlic.com/~lynn/2008k.html#55 recent mentions of 40+ yr old technology
http://www.garlic.com/~lynn/2008k.html#60 recent mentions of 40+ yr old technology
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
IBM-MAIN longevity
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM-MAIN longevity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 31 Jul 2008 14:01:22 -0400
Anne & Lynn Wheeler <lynn@garlic.com> writes:
one of the reference posts
http://www.garlic.com/~lynn/2006t.html#50 The Future of CPUs: What's After Multi-Core?
BITNET 435
ARPAnet 1155
CSnet 104 (excluding ARPAnet overlap)
VNET 1650
EasyNet 4200
UUCP 6000
USENET 1150 (excluding UUCP nodes)
... snip ...
re:
http://www.garlic.com/~lynn/2008l.html#6 IBM-MAIN longevity
R.I.P Usenet: 1980-2008
http://tech.slashdot.org/tech/08/07/31/1622251.shtml
R.I.P Usenet: 1980-2008
http://www.pcmag.com/article2/0,2704,2326848,00.asp
from above:
Child-porn investigations have doomed one of the last remnants of a
smaller, kinder Net.
... snip ...
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
IBM-MAIN longevity
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM-MAIN longevity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 31 Jul 2008 15:41:11 -0400
Roger Blake <rogblake10@iname10.com> writes:
The BSD 4.1 manual does reference and describe TCP/IP, probably the earliest
book in my possession that does.
One of the man pages I happened on just recently therein was a program or
function for looking up hostnames on a TCP/IP network. (The "bugs" section
complained that there was no central database for hostnames -- obviously
written pre-DNS.)
re:
http://www.garlic.com/~lynn/2008l.html#9 IBM-MAIN longevity
recent post with reference to inventor of DNS
http://www.garlic.com/~lynn/2008j.html#87 CLIs and GUIs
having worked at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech
for something a little different ... there was post in old thread about
CSRG being told that they couldn't do a tcpip/network implementation and
they went ahead and did it anyway:
http://www.garlic.com/~lynn/2000e.html#28 Is Al Gore The Father of the Internet?^
the reference in the above was
http://www.be.daemonnews.org/199909/usenix-kirk.html
from above:
He said (paraphrased) that every DARPA meeting ended up the same, with
the Military coming in and giving CSRG (at UCB, the group that worked on
BSD) a stern warning that they were to work on the Operating System, and
that BBN will work on the networking. Every time, Bob Fabry, then the
advisor of CSRG, would "Yes: them to death" and they'd go off and just
continue the way they were going. Much to the frustration of the DARPA
advisory board
... snip ...
I had done internet specific post archive from similar threads in 99
time-frame:
http://www.garlic.com/~lynn/internet.htm
one of the threads (in the internet archive):
http://www.garlic.com/~lynn/99.html#37a Internet and/or ARPANET?
http://www.garlic.com/~lynn/99.html#37b Internet and/or ARPANET?
http://www.garlic.com/~lynn/99.html#38a Internet and/or ARPANET?
http://www.garlic.com/~lynn/99.html#38b Internet and/or ARPANET?
http://www.garlic.com/~lynn/99.html#38d Internet and/or ARPANET?
http://www.garlic.com/~lynn/99.html#39 Internet and/or ARPANET?
http://www.garlic.com/~lynn/99.html#44 Internet and/or ARPANET?
http://www.garlic.com/~lynn/99.html#45 Internet and/or ARPANET?
http://www.garlic.com/~lynn/99.html#46 Internet and/or ARPANET?
http://www.garlic.com/~lynn/99.html#51 Internet and/or ARPANET?
http://www.garlic.com/~lynn/99.html#53 Internet and/or ARPANET?
some of the posts (both in 99.html archive and copies in internet.htm
archive) has extracts from IEN (internet engineering) documents on
issue with the development of IP and internetworking.
as per
http://www.garlic.com/~lynn/99.html#38d Internet and/or ARPANET?
http://www.garlic.com/~lynn/internet.htm#5 Internet and/or ARPANET?
internet was also referred to as multinetwork (in IEN-16, 20May77) and
catenet (in IEN-32, 28apr78). IEN-16 (also RFC 730) has some discussion
about the changes in the Host-IMP interface for extensible Field
Addressing ...
Multinetwork Systems
The prospect of interconnections of networks to form a complex
multinetwork system poses additional addressing problems. The new
Host-IMP interface specification has reserved fields in the leader to
carry network addresses [2]. There is experimental work in progress on
interconnecting networks [4, 5, 6]. We should be prepared for these
extensions to the address space.
... snip ...
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
recent mentions of 40+ yr old technology
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: recent mentions of 40+ yr old technology
Newsgroups: alt.folklore.computers
Date: Thu, 31 Jul 2008 15:53:21 -0400
Peter Flass <Peter_Flass@Yahoo.com> writes:
The article goes on to say "Midori is an offshoot of Singularity." I
was much less than impressed by Singularity.
re:
http://www.garlic.com/~lynn/2008l.html#11 recent mentions of 40+ yr old technology
but it does seem that they are attempting to catch the wave that has
been moving in the direction of virtual appliances (or what we started
out calling service virtual machines in the early 70s). past posts
mentioning the new virtual appliance genre:
http://www.garlic.com/~lynn/2006t.html#46 To RISC or not to RISC
http://www.garlic.com/~lynn/2006w.html#25 To RISC or not to RISC
http://www.garlic.com/~lynn/2006x.html#6 Multics on Vmware ?
http://www.garlic.com/~lynn/2006x.html#8 vmshare
http://www.garlic.com/~lynn/2007i.html#36 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007k.html#26 user level TCP implementation
http://www.garlic.com/~lynn/2007k.html#48 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007m.html#67 Operating systems are old and busted
http://www.garlic.com/~lynn/2007m.html#70 Is Parallel Programming Just Too Hard?
http://www.garlic.com/~lynn/2007o.html#3 Hypervisors May Replace Operating Systems As King Of The Data Center
http://www.garlic.com/~lynn/2007q.html#25 VMware: New King Of The Data Center?
http://www.garlic.com/~lynn/2007s.html#4 Why do we think virtualization is new?
http://www.garlic.com/~lynn/2007s.html#26 Oracle Introduces Oracle VM As It Leaps Into Virtualization
http://www.garlic.com/~lynn/2007s.html#35 Oracle Introduces Oracle VM As It Leaps Into Virtualization
http://www.garlic.com/~lynn/2007u.html#39 New, 40+ yr old, direction in operating systems
http://www.garlic.com/~lynn/2007u.html#41 New, 40+ yr old, direction in operating systems
http://www.garlic.com/~lynn/2007u.html#81 IBM mainframe history, was Floating-point myths
http://www.garlic.com/~lynn/2007v.html#75 virtual appliance
http://www.garlic.com/~lynn/2007v.html#80 software preservation volunteers ( was Re: LINC-8 Front Panel Questions)
http://www.garlic.com/~lynn/2008.html#59 old internal network references
http://www.garlic.com/~lynn/2008b.html#39 folklore indeed
http://www.garlic.com/~lynn/2008b.html#52 China's Godson-2 processor takes center stage
http://www.garlic.com/~lynn/2008c.html#2 folklore indeed
http://www.garlic.com/~lynn/2008c.html#55 Kernels
http://www.garlic.com/~lynn/2008e.html#11 Kernels
http://www.garlic.com/~lynn/2008e.html#15 Kernels
http://www.garlic.com/~lynn/2008h.html#47 Microsoft versus Digital Equipment Corporation
http://www.garlic.com/~lynn/2008h.html#97 Is virtualization diminishing the importance of OS?
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Code Page 1047 vs 037 - Green card confusion
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Code Page 1047 vs 037 - Green card confusion
Newsgroups: bit.listserv.ibm-main
To: <ibm-main@bama.ua.edu>
Date: Thu, 31 Jul 2008 17:59:16 -0400
shmuel+ibm-main@PATRIOT.NET (Shmuel Metz , Seymour J.) writes:
No, I'm referring to the 1403 line-printer Universal Character Set buffer,
since the context was the 1416. That was a wrapper around an array of code
points the same size as the band[1], chain[2] or train.
The 3800 and 3900 were very different, because you could actually define
the pixel layout of each character.
[1] Not applicable to the 1403
[2] I don't recall whether there was an S/360 model of the 1403 that
used a chain
i saw both 1403-7 (600lpm) and 1403-N1 (1100lpm) in use on 360-30.
IBM 1403 Printer train
http://www-03.ibm.com/ibm/history/exhibits/attic3/attic3_024.html
from above:
The "chain" printer for computers was introduced with the IBM 1401
computer in 1959. Improving both speed and reliability, the IBM 1403
printer's "chain-loop" of characters traveled horizontally at 90 inches
a second and printed 600 lines a minute as it was struck by 132 hammers
positioned across the paper. The last IBM 1403 -- of more than 23,000
shipped to U.S. customers -- was delivered in 1983
... snip ...
the above title says *train* and then description talks about *chain*
1403-2 & 1403-7 printers
http://www-03.ibm.com/ibm/history/exhibits/supplies/supplies_5404PH09.html
i think should be "chain" printers (600lpm) ... above says "-7" was 120
print positions and could be used with 360s & 370s; "-2" was 132 print
positions and could be used with 360, 370, & s/3 model 10
This reference:
The evolution of printers and displays
http://www.research.ibm.com/journal/sj/253/ibmsj2503a4N.pdf
says that 1403 used chains with train introduced in later 1403N1
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
IBM-MAIN longevity
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM-MAIN longevity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 31 Jul 2008 18:42:14 -0400
Anne & Lynn Wheeler <lynn@garlic.com> writes:
also had one of my old emails from 85
http://www.garlic.com/~lynn/2006t.html#email850625
complaining about cost of DES link encryptors for HSDT
project
http://www.garlic.com/~lynn/subnetwork.html#hsdt
and commenting about internal network approaching 2000 nodes ... and all
links requiring link encryptors. The HSDT links were T1 and higher
... so I was paying a lot more ... than the rest of the links which were
56kbits or slower.
re:
http://www.garlic.com/~lynn/2008l.html#6 IBM-MAIN longevity
I've mentioned before that in this period that there were comments
that over half of all the link encryptors in the world were on
the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet
looking at some of the nsfnet status reports ... i also found this
inclusion ... ref (bay area regional research network) BARNET T1s (from
'87):
Proteon routers with Ethernet and full T-1 interfaces (SBE boards)
have been bench tested at Stanford with Avanti Accupak 1.5 data
formatters (DSX-1 interface w/o CSUs). Appears that with the CSU
(Avanti's internal "ISU") the effective thruput will be limited to
1.344Mb/s by the Avanti because it uses straight bit-stuffing to
meet the telco connect requirements. As a result, we have started
testing Verilink units which use an algorithm for maintaining the
telco T-1 bit density requirements that appears to avoid the loss
of the 192kbps. Will also test Phoenix microsystems units which
purport the same in their reformatter/CSUs and have a better
physical configuration (8 packs, formatter or CSU to a 19in rack)
and a built-in BERT in CSU.
... snip ...
HSDT first telco T1s (some in the bay area) were "clear-channel". Then
telcos started insisting that T1s conform to ones density requirement
... and we initially used the Avanti (UltraMuxes) bit-stuffing described
in the above status report. We had already been using Avanti with a
separate 56kbit subchannel dedicated to continous bit-error-test
(FireBerd).
HSDT did get some Phoenix boxes a couple yrs later in the fall of '86.
for other link encryptor and hsdt topic drift:
http://www.garlic.com/~lynn/2008h.html#87 New test attempt
http://www.garlic.com/~lynn/2008i.html#86 Own a piece of the crypto wars
http://www.garlic.com/~lynn/2008j.html#43 What is "timesharing" (Re: OS X Finder windows vs terminal window weirdness)
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
IBM-MAIN longevity
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM-MAIN longevity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 01 Aug 2008 05:12:01 -0400
Anne & Lynn Wheeler <lynn@garlic.com> writes:
HSDT first telco T1s (some in the bay area) were "clear-channel". Then
telcos started insisting that T1s conform to ones density requirement
... and we initially used the Avanti (UltraMuxes) bit-stuffing described
in the above status report. We had already been using Avanti with a
separate 56kbit subchannel dedicated to continous bit-error-test
(FireBerd).
HSDT did get some Phoenix boxes a couple yrs later in the fall of '86.
re:
http://www.garlic.com/~lynn/2008l.html#16 IBM-MAIN longevity
... past hsdt posts
http://www.garlic.com/~lynn/subnetwork.html#hsdt
this was all well before SNMP; The FireBerds and UltrMux did have
rs232 output that could be hooked to hardcopy terminals. so i
configured PC/XTs with 4-port async cards ... and hooked the rs232 to
the PC/XTs. I wrote a turbo pascal program to emulate hardcopy
terminal on all the ports ... would log the output to the harddisk as
well as scan for various alert conditions and raise alarms.
SNMP rfc was:
http://www.garlic.com/~lynn/rfcidx3.htm#1067
1067 -
Simple Network Management Protocol, Case J., Davin J., Fedor M.,
Schoffstall M., 1988/08/01 (33pp) (.txt=67742) (Obsoleted by 1098)
(See Also 1065, 1066) (Refs 768, 1028, 1052) (Ref'ed By 1089, 1095,
1156, 1704)
....
I had a PC/RT with megapixal display at Interop '88 ... misc. past posts
http://www.garlic.com/~lynn/subnetwork.html#interop88
it was in the NSC booth ... which was at the end of a row. Case was in
the Sun booth which was at the end of a row at right angles to the NSC
booth ... and got Case to come over and install their SNMP on the PC/RT.
Part of the reason that I was in the NSC booth ... was that I had
also done RFC 1044 support ... misc. past posts
http://www.garlic.com/~lynn/subnetwork.html#1044
re:
http://www.garlic.com/~lynn/rfcidx3.htm#1044
1044 -
Internet Protocol on Network System's HYPERchannel: Protocol
Specification. K. Hardwick, J. Lekashman. February 1988. (Format:
TXT=100836 bytes) (Also STD0045) (Status: STANDARD)
for mainframe tcp/ip product. The product had been implemented in
pascal/vs ... but wasn't very optimized ... getting about 44kbytes/sec
using a full 3090 processor. In some RFC1044 tuning testing at Cray
Research (between cray and 4341-clone), I got 1mbyte/sec (4341 channel)
using only a modest amount of the 4341 (nearly 3 orders of magnitude
improvement in bytes transferred per instructions executed).
... and turbo pascal snippet from somewhere long ago and far away:
{$V+,R+,B-,C-,U-} {note: the C- & U- aviods losing type-ahead}
(*
FIREBERD
minimize ERROR entries in cases of prolonged
high-error rate conditions. Calculate ERRORs/sec
Make no more than one entry in ERROR per 15 minutes
unless ERRORs/sec change by more than 50%.
minimize ERROR entries for sync lost/sync acquired
loops.
ULTRAMUX
recognize alarm messages
define status flags for various alarm messages
when sync. is lost, include fireberd information in screen
COM2 asynch interrupt
check for Asynch card interrupt
... if not asynch, restore status/regs and
goto saved IRA (i.e. cascaded IRQ4 interrupt routines)
... snip ...
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
recent mentions of 40+ yr old technology
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: recent mentions of 40+ yr old technology
Newsgroups: alt.folklore.computers
Date: Fri, 01 Aug 2008 09:39:29 -0400
Virtual Sprawl Hits Wall Street
http://www.financetech.com/featured/showArticle.jhtml;jsessionid=51O3U4P5UN4M0QSNDLOSKH0CJUNN2JVN?articleID=209900669
from above:
Having implemented virtualization software to conquer "server sprawl"
(or, more specifically, to perform more work on fewer servers and thus
minimize the proliferation of servers), many Wall Street firms are now
in the throes of "virtual sprawl".
... snip ...
one of the issues ...
Further, software vendors increasingly are policing their customers,
auditing how many instances of their programs a company is really
running versus the number of licenses it purchased and then asking the
client to cough up the difference, which can run into millions of
dollars.
... snip ...
this has also come up in the past with the proliferation of multi-core
chips ... initially starting out with license priced proportional to
number of cores. virtualization might result in hundreds of software
"instances" all on a single (physical) server.
past posts in thread:
http://www.garlic.com/~lynn/2008j.html#85 recent mentions of 40+ yr old technology
http://www.garlic.com/~lynn/2008k.html#45 recent mentions of 40+ yr old technology
http://www.garlic.com/~lynn/2008k.html#46 recent mentions of 40+ yr old technology
http://www.garlic.com/~lynn/2008k.html#52 recent mentions of 40+ yr old technology
http://www.garlic.com/~lynn/2008k.html#53 recent mentions of 40+ yr old technology
http://www.garlic.com/~lynn/2008k.html#55 recent mentions of 40+ yr old technology
http://www.garlic.com/~lynn/2008k.html#60 recent mentions of 40+ yr old technology
http://www.garlic.com/~lynn/2008l.html#11 recent mentions of 40+ yr old technology
http://www.garlic.com/~lynn/2008l.html#14 recent mentions of 40+ yr old technology
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
IBM-MAIN longevity
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM-MAIN longevity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 01 Aug 2008 09:57:36 -0400
Anne & Lynn Wheeler <lynn@garlic.com> writes:
ULTRAMUX
recognize alarm messages
define status flags for various alarm messages
when sync. is lost, include fireberd information in screen
re:
http://www.garlic.com/~lynn/2008l.html#16 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#17 IBM-MAIN longevity
one of the issues related to comment about internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet
having over half of all the link encryptors in the world ... as well
as my annoyance with what I had to pay for link encryptors for T1 and
higher speed links (resulted in working on design for some hardware
that would handle encryption with a lot more function, at much higher
rates, and built at much lower cost) ... was that encryption was very
sensitive to bit-errors and sync loss ... and if there was some
latency with ultramux recovery ... there was significantly longer
delay getting the encryption units back in sync after bit-error or
sync loss.
so besides looking at issues on how to better do encryption ... the
other technology (somewhat driven by also having to do encryption) was
having much better forward-error-correcting. There was a company up in
Berkeley (Cyclotomics) that had specialized in reed-solomon ... and
(among other things) had gotten involved in cdrom (encoding) standard
... that we started working with. Cyclotomics was soon after bought by
Kodak. misc. past posts mentioning cyclotomics (and/or reed-solomon):
http://www.garlic.com/~lynn/2001.html#1 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
http://www.garlic.com/~lynn/2002p.html#53 Free Desktop Cyber emulation on PC before Christmas
http://www.garlic.com/~lynn/2003e.html#27 shirts
http://www.garlic.com/~lynn/2004f.html#37 Why doesn't Infiniband supports RDMA multicast
http://www.garlic.com/~lynn/2004o.html#43 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2005n.html#27 Data communications over telegraph circuits
http://www.garlic.com/~lynn/2007.html#29 Just another example of mainframe costs
http://www.garlic.com/~lynn/2007j.html#4 Even worse than UNIX
http://www.garlic.com/~lynn/2007v.html#82 folklore indeed
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
IBM-MAIN longevity
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM-MAIN longevity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 01 Aug 2008 13:08:34 -0400
Lars Poulsen <lars@beagle-ears.com> writes:
This was a good thing. The first network code we ran at ACC was
a BBN enhancement to the version 7 unix on our PDP-11/70, and
it was atrocious: Badly designed, badly implemented.
When we finally got a VAX with 4.2BSD, life got a lot better
(and we crashed a lot less). A while after that, we got the
Wollongong Group (later TGV) version of SRI's port of the BSD
code to VMS, and that seemed at the time to be the best of
many OS/network combinations.
for a short senior moment, I translated ACC to ACSC (another company in
the LA area).
when we were doing ha/cmp product ... some past posts:
http://www.garlic.com/~lynn/subtopic.html#hacmp
and working on scaleup ... some old email from the period:
http://www.garlic.com/~lynn/lhwemail.html#medusa
we had been part of turning LLNL's Lincs into Unitree commercial product
... and we were paying ACSC to do some of the work.
slightly related to previous post about doing rfc1044 support (and doing
performance tuning tests at cray research):
http://www.garlic.com/~lynn/subnetwork.html#1044
From: Brick Verser <BAV%KSUVM>
Forum: IBMTCP-L DIGEST
Date: Wed, 24 Feb 88 13:31:00 CST
Subject: Re: If you had to do it over again...
We just received an ACC ACS9310 to use with the FAL software.
ACC has a software driver for the 9310 for version 1.0 of FAL,
but it looks like it will need some work to get it to run on 1.1.
We are currently waiting for the VS PASCAL compiler to arrive so
we can start work on it (with the new release of FAL, PASCAL/VS
no longer works, grumble, grumble).
The 9310 is cabled into the channel, and I've written a little
assembler routine which does its own channel programming to simply
read packets from the controller. It seems to do that just fine.
But I can't say anything about throughput until we actually get
VS PASCAL and can recompile and relink the driver into FAL.
The 9310 is built like a tank. It is also a single integrated box,
unlike the 8232 which is an AT with add-on hardware. I'm sure it
will work out well once we get the driver installed. ACC has been
building ARPANET stuff for ages and got into the commerical game only in
the last few years. The 9310 is the box of choice for MVS sites, it
seems, and ACC finally has the software driver to make the 9310 work
with FAL. The retail price of the 9310 is something like $29K, but
until December 31, 1987 they were letting them go to NSFNET sites for
$19K. That made it cheaper than the 8232, and I suspect it is faster
and more reliable as well.
... snip ...
note that 8232 was an industrial, rack-mount pc/at ... and numerous in
the corporation wanted to sell them a lot closer to cost.
past posts in this thread:
http://www.garlic.com/~lynn/2008k.html#81 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008k.html#83 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008k.html#85 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#0 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#1 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#2 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#3 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#4 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#5 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#6 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#7 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#8 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#9 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#10 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#12 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#13 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#16 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#17 IBM-MAIN longevity
http://www.garlic.com/~lynn/2008l.html#19 IBM-MAIN longevity
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
recent mentions of 40+ yr old technology
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: recent mentions of 40+ yr old technology
Newsgroups: alt.folklore.computers
Date: Sat, 02 Aug 2008 09:18:40 -0400
jmfbahciv <jmfbahciv@aol> writes:
When will the security issue of sprawling to automatically to an
insecure virtual server start to matter?
re:
http://www.garlic.com/~lynn/2008l.html#18 recent mentions of 40+ yr old technology
standard security processes are KISS and partitioning ... and/or
partitioning helps with KISS; partitioning is also used to limit scope
of breach. at least the more serious attackers have some sense of ROI
... going after the most return for the least effort. partitioning tends
to at least maintain the level of the attackers effort while trying to
drastically reducing the return.
also, vulnerabilities tend to be proportional to complexity.
virtualization provides quite a bit for effective partitioning and helps
to contribute to KISS.
from an economic justification it has been reducing (and simplifying)
number of physical components by an order of magnitude or more. there
are attempts to leverage virtualization further by increasing the
partitioning (i.e. virtual appliance).
part of the issue can be some level of administration based on pure
physical things ... w/o actually understanding the operation of those
things. I would claim that this is also related to issue with *orange
book* security didn't deal well with interconnected components
(networking) ... looking mostly at demonstrating security compliance
within a disconnected operation.
A decade ago I gave a talk on electronic commerce for USC/ISI graduate
student seminar and IETF RFC editor group ... where I claimed that much
of the (tcp/ip) networking that evolved during the 80s and 90s was not
*industrial strength* (also involved security related issues).
included was various compensating processes that we had to invent
and/or mandate for the operation of the "payment gateway"
http://www.garlic.com/~lynn/subnetwork.html#gateway
one of the examples was about the time we were doing the payment
gateway aspect of electronic commerce ... the largest online
service provider was having internet related failures. this went on
for two months (while they had some significant number of experts in
the field in to look for solution). One of the people then flew out to
the west coast and bought me a hamburger after work. While I ate the
hamburger, he explained the symptoms. I then gave him a Q&D fix
that he applied later that night.
I explained that it was one of the areas that we had identified during
the ha/cmp product effort
http://www.garlic.com/~lynn/subtopic.html#hacmp
as part of ha/cmp, we had done detailed vulnerability studies
... including tcp/ip ... which involved both detailed review of
standards (and RFCs) as well as detailed review of code (to both
understand what the code was doing as well as what the standards were
saying). Part of the issue were cracks/gaps that would be standard
consideration as part of any real industrial strength (and/or
business critical) effort.
Over the next several weeks, I approached the major vendors about
needing to address the specific and related issues ... but there was
no interest (possibly in part because the largest online service
provider had no interest in publicizing the situation). Almost exactly
a year later (to the date when somebody bought me a hamburger after
work), the problem hit the press (at some other service provider)
... and then over the next month ... most of the vendors were publicly
patting themselves on the back on how quickly they were patching the
problem.
misc. past posts mentioning situation:
http://www.garlic.com/~lynn/2005c.html#51 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2006e.html#11 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006i.html#6 The Pankian Metaphor
http://www.garlic.com/~lynn/2008b.html#34 windows time service
for other drift ... past posts mentioning fraud/attackers ROI
http://www.garlic.com/~lynn/aadsm10.htm#bio6 biometrics
http://www.garlic.com/~lynn/aadsm14.htm#4 Who's afraid of Mallory Wolf?
http://www.garlic.com/~lynn/aadsm17.htm#2 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
http://www.garlic.com/~lynn/aadsm17.htm#47 authentication and authorization ... addenda
http://www.garlic.com/~lynn/aadsm17.htm#60 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm18.htm#45 Banks Test ID Device for Online Security
http://www.garlic.com/~lynn/aadsm19.htm#13 What happened with the session fixation bug?
http://www.garlic.com/~lynn/aadsm19.htm#17 What happened with the session fixation bug?
http://www.garlic.com/~lynn/aadsm19.htm#26 Trojan horse attack involving many major Israeli companies, executives
http://www.garlic.com/~lynn/aadsm19.htm#45 payment system fraud, etc
http://www.garlic.com/~lynn/aadsm23.htm#34 Chip-and-Pin terminals were replaced by "repairworkers"?
http://www.garlic.com/~lynn/aadsm26.htm#35 Failure of PKI in messaging
http://www.garlic.com/~lynn/aadsm28.htm#60 Seeking expert on credit card fraud prevention - particularly CNP/online transactions
http://www.garlic.com/~lynn/aadsm28.htm#73 "Designing and implementing malicious hardware"
http://www.garlic.com/~lynn/99.html#172 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#44 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2003o.html#35 Humans
http://www.garlic.com/~lynn/2004.html#29 passwords
http://www.garlic.com/~lynn/2004b.html#39 SSL certificates
http://www.garlic.com/~lynn/2005i.html#1 Brit banks introduce delays on interbank xfers due to phishing boom
http://www.garlic.com/~lynn/2005p.html#25 Hi-tech no panacea for ID theft woes
http://www.garlic.com/~lynn/2006h.html#26 Security
http://www.garlic.com/~lynn/2007.html#5 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#11 Decoding the encryption puzzle
http://www.garlic.com/~lynn/2007l.html#40 My Dream PC -- Chip-Based
http://www.garlic.com/~lynn/2007o.html#27 EZPass: Yes, Big Brother IS Watching You!
http://www.garlic.com/~lynn/2008e.html#69 independent appraisers
http://www.garlic.com/~lynn/2008g.html#27 Hannaford case exposes holes in law, some say
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
dollar coins
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: dollar coins
Newsgroups: alt.folklore.computers
Date: Sat, 02 Aug 2008 09:46:33 -0400
jmfbahciv <jmfbahciv@aol> writes:
One of their last actions was to OK more millions for
the Mass. Turnpike Authority to borrow. The intention
is to sell bonds so they can pay off the bonds that
have a high interest rate. Do you really believe
that those bonds will get retired? I don't. It's
not clear that the legislation that was passed
made it impossible to not use the funds for something
else.
i thot that reason for toll on mass. turnpike was to pay off the
original construction bonds. when that happened, i understood that they
decided to continue the tolls to cover maintenance costs so they
wouldn't need additional bonds.
when i 1st moved to mass., i heard jokes about use of water soluble
asphalt, effectively as part of ongoing subsidy to road construction
companies. recent reference
http://www.garlic.com/~lynn/2008k.html#73 Cormpany sponsored insurance
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Memories of ACC, IBM Channels and Mainframe Internet Devices
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Memories of ACC, IBM Channels and Mainframe Internet Devices
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 02 Aug 2008 10:11:51 -0400
Lars Poulsen <lars@beagle-ears.com> writes:
A different group developed the ACS-9310, which was based on an
already existing Versabus chassis developed for a government contract,
and for which we had a MC68000 CPU board with an ethernet jack,
as well as a BBN-1822 board. For this project we did a 360-channel
interface board, and an embedded software project called VIA-FD
(Versabus Internet Access Feasibility Demonstration). I think the
customer for this was in fact IBM Federal Systems Division.
recent post about doing 360-channel interface board ... possibly
two decades earlier
http://www.garlic.com/~lynn/2008k.html#65 Crippleware: hadware examples
as part of doing a plug-compatible/clone controller ... other past posts
http://www.garlic.com/~lynn/subtopic.html#360pcm
this was written up, blaming four of us for the plug-compatible/clone
controller business.
this post
http://www.garlic.com/~lynn/2008d.html#16 more on (the new 40+ yr old) virtualization
cites reference
http://www.ecole.org/Crisis_and_change_1995_1.htm
attributing much of the motivation for the (failed) future system effort
was the plug-compatible/clone controller business
http://www.garlic.com/~lynn/submain.html#futuresys
this older post
http://www.garlic.com/~lynn/2001f.html#33 IBM's "VM for the PC" c.1984?
has reference to Morris/Fergus book about the failure of the future
system effort having long-term detrimental effects on the company. It
possibly also wasn't career enhancing, that at the time, I had poked fun
at the effort drawing comparisons with a cult film playing down the
street in central sq.
i've also made recent references
http://www.garlic.com/~lynn/2008i.html#18 Microsoft versus Digital Equipment Corporation
http://www.garlic.com/~lynn/2008k.html#21 IBM's 2Q2008 Earnings
that it appeared much of John's motivation for 801/risc appeared to be
something that was the exact opposite in hardware complexity to what
went on in the future system effort. misc. past posts mentioning
801/risc
http://www.garlic.com/~lynn/subtopic.html#801
i've also made past posts that when we were doing hsdt project
http://www.garlic.com/~lynn/subnetwork.html#hsdt
we got involved in doing a "clone" controller with significant
more feature/function (but from within the company) ... old
reference:
http://www.garlic.com/~lynn/99.html#67 System/1 ?
http://www.garlic.com/~lynn/99.html#70 Series/1 as NCP (was: Re: System/1 ?)
which drew the ire of the communication's division. The above started
out with an implementation currently running on a Series/1 ... but the
product plans involved quickly moving it to 801/risc (significantly
increasing the thruput and price/performance).
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
dollar coins
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: dollar coins
Newsgroups: alt.folklore.computers
Date: Sat, 02 Aug 2008 10:24:46 -0400
jmfbahciv <jmfbahciv@aol> writes:
All of a sudden, the Turnpike Authority is billions in debt
and in a fiscal crisis. The governor, a Democrat, is trying
to put back all the toll booths that the Republican governors
eliminated. What a wonderful idea. Install more stops and
traffic snarls and backups and traffic blocks so that more
gas can be burned sitting in state-imposed parking lots, a.k.a.
roads.
re:
http://www.garlic.com/~lynn/2008k.html#73 Cormpany sponsored insurance
http://www.garlic.com/~lynn/2008l.html#22 dollar coins
there was serious business news show commentary yesterday that the
reason that the transportaion infastructure is in such a bad state
(i.e. 30 yrs or so of not doing adequate maintenance) is because that
since May, driving is down and so for the past couple months, the
governments haven't been collecting as much fuel taxes. they seem to
be tying it in with the 1yr anniversary of the collapse of the
interstate bridge (and possibly the reduction in fuel taxes for the
last couple months somehow contributed to the bridge collapse).
my 1st exposure to the mass. turnpike was a winter x-country drive from
the west coast ... and running into masspike speed limit reduced to
30mph because of "frost heaves" ... which was something that wasn't
found in western county mountain roads (i.e. western state county roads
built to higher standards than interstate in mass)
misc. past posts mentioning frost heaves on massspike:
http://www.garlic.com/~lynn/99.html#22 Roads as Runways Was: Re: BA Solves Y2K (Was: Re: Chinese Solve Y2K)
http://www.garlic.com/~lynn/2002i.html#28 trains was: Al Gore and the Internet
http://www.garlic.com/~lynn/2002i.html#35 pop density was: trains was: Al Gore and the Internet
http://www.garlic.com/~lynn/2002i.html#36 pop density was: trains was: Al Gore and the Internet
http://www.garlic.com/~lynn/2002j.html#42 Transportation
http://www.garlic.com/~lynn/2002j.html#68 Killer Hard Drives - Shrapnel?
http://www.garlic.com/~lynn/2003j.html#11 Idiot drivers
http://www.garlic.com/~lynn/2006h.html#45 The Pankian Metaphor
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
dollar coins
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: dollar coins
Newsgroups: alt.folklore.computers
Date: Sat, 02 Aug 2008 10:57:37 -0400
Anne & Lynn Wheeler <lynn@garlic.com> writes:
there was serious business news show commentary yesterday that the
reason that the transportaion infastructure is in such a bad state (i.e.
30 yrs or so of not doing adequate maintenance) is because that since
May, driving is down and so for the past 3 months, the governments
haven't been collecting as much fuel taxes. they seem to be tying it in
with the 1yr anniversary of the collapse of the interstate bridge (and
possibly the reduction in fuel taxes for the last three months somehow
contributed to the bridge collapse).
re:
http://www.garlic.com/~lynn/2008l.html#24 dollar coins
some of this might also be considered a side-effect of not accurately
pricing/charging based on costs.
past posts have mentioned that basic road design (and much of
construction cost) is predicated on projected heavy truck (18 wheeler)
axle-loads and nearly all wear&tear (also therefor maintenance costs is
based on heavy truck (18 wheeler) axle-loads.
however, significant portion of funds comes from fuel road-use tax paid
by vehicles that aren't heavy trucks (i.e. use by vehicles which don't
contribute to road design/contrustion costs and/or contribute to road
wear&tear maintenace costs).
my conjecture is that majority of the reduction in fuel use and therefor
drop in road-use taxes are from vehicles that aren't heavy trucks. The
issue is that while that is a significant hit to funds for road
construction & maintenace ... it doesn't affect the heavy truck
axle-loads which is the basis for construction and maintenance costs.
conjecture in thread (in this n.g.) from couple years ago on the
subject ... was when the source of funding wasn't directly
proportional to use ... such discontinuity/disconnect could result in
all sorts of subsequent problems (i.e. current situation when there is
significant drop in funds w/o a corresponding significant drop in the
use that result in the majority of costs).
past posts mentioning heavy truck axle/load as the major
factor in road construction and maintenance costs:
http://www.garlic.com/~lynn/2002j.html#41 Transportation
http://www.garlic.com/~lynn/2006g.html#5 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#6 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#10 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#12 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#15 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#19 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#24 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#26 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#32 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#35 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#46 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#48 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#49 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#50 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#51 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#52 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#53 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#54 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#56 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#57 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#59 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#60 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#61 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#62 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#0 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#5 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#6 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#11 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#23 The Pankian Metaphor
http://www.garlic.com/~lynn/2006p.html#2 Overweight truckers stopped by tech checks
http://www.garlic.com/~lynn/2007n.html#97 Loads Weighing Heavily on Roads
http://www.garlic.com/~lynn/2008b.html#55 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008e.html#48 fraying infrastructure
http://www.garlic.com/~lynn/2008k.html#68 Historian predicts the end of 'science superpowers'
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
dollar coins
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: dollar coins
Newsgroups: alt.folklore.computers
Date: Sat, 02 Aug 2008 13:35:51 -0400
CBFalconer <cbfalconer@yahoo.com> writes:
I think you will find that the crucial factor in frost-heaves is
the water content of the soil. I suspect there is a large
difference between Mass. and the west in this. The temperature has
little to do with it (apart from being below freezing).
frost heaves come from having water in the soil ... frequently
underground streams and/or run-off (as opposed to things like humidity).
whether a road actually has frost heaves is whether it has been designed
to handle forst heaves (aka things like drainage and sufficient road bed
as countermeasure to damp/freezing underground).
there was some joke/speculation by the people in mass. wasn't that the
soil moisture under the road bed was different ... it was whether
drainage and road bed was adequately prepared.
Actually some of the jokes about mass pike were a little more caustic
... possibly hiring a farmer to plow a swath ... and then running
asphalt paving machine over the plowed ground (which is obviously a
scenario where if the underlying soil got wet and froze ... there would
be frost heaves)
as in previous post
http://www.garlic.com/~lynn/2008l.html#24 dollar coins
past posts mentioning frost heaves and there are road construction
road bed standards to prevent frost heaves from affecting the road:
http://www.garlic.com/~lynn/99.html#22 Roads as Runways Was: Re: BA Solves Y2K (Was: Re: Chinese Solve Y2K)
http://www.garlic.com/~lynn/2002i.html#28 trains was: Al Gore and the Internet
http://www.garlic.com/~lynn/2002i.html#35 pop density was: trains was: Al Gore and the Internet
http://www.garlic.com/~lynn/2002i.html#36 pop density was: trains was: Al Gore and the Internet
http://www.garlic.com/~lynn/2002j.html#42 Transportation
http://www.garlic.com/~lynn/2002j.html#68 Killer Hard Drives - Shrapnel?
http://www.garlic.com/~lynn/2003j.html#11 Idiot drivers
http://www.garlic.com/~lynn/2006h.html#45 The Pankian Metaphor
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
dollar coins
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: dollar coins
Newsgroups: alt.folklore.computers
Date: Sat, 02 Aug 2008 13:43:54 -0400
CBFalconer <cbfalconer@yahoo.com> writes:
I think you will find that the crucial factor in frost-heaves is
the water content of the soil. I suspect there is a large
difference between Mass. and the west in this. The temperature has
little to do with it (apart from being below freezing).
re:
http://www.garlic.com/~lynn/2008l.html#26 dollar coins
other caustic remarks were about western state county roads being built
to better standards than mass. interstate ... but that also went along
with the jokes about the use of water soluble asphalt.
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Verifying Verified By Visa - Registration breaks chain of trust
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Verifying Verified By Visa - Registration breaks chain of trust
Newsgroups: uk.finance,comp.security.misc
Date: Sat, 02 Aug 2008 15:14:41 -0400
David Woolley <david@ex.djwhome.demon.co.uk.invalid> writes:
Note. A similar problem arises with many e-commerce sites which use
an unknown service (their ISP?) for credit card processing, but the
main risk there tends to be that authentication doesn't guarantee the
company is trustworthy.[C]
we were brought to consult with small client/server company that wanted
to do payment transactions on their server and had this technology they
had invented called SSL they wanted to use ... the result is now
frequently referred to as electronic commerce. Part of what was done was
something called a payment gateway ... and we mandated some amount of
the useage interface between the webservers and the payment gateway
... including implementing something called "mutual authentication"
(which didn't exist at the time). misc. past posts mentioning
payment gateway for electronic commerce
http://www.garlic.com/~lynn/subnetwork.html#gateway
we also did detailed protocol and business process walk thru of SSL,
digital certificates and these new businesses calling themselves
certification authorities.
for the payment gateway process, SSL mutual authentication evolved to
the point where it was apparent that digital certificates were redundant
and superfluous ... and there use was just a side-effect of using the
existing SSL software library ... aka the payment gateway had table of
all authorized webservers and each webserver had table with details about
the payment gateway (so obtaining the corresponding public key from a
digital certificate was superfluous).
also, at the time, the use of SSL domain name authentication ... by
clients were based on some business process assumptions ... in order
to result in:
the webserver that a client is interacting with ... is the
webserver that they think they are interacting with
aka
1) the client understood that relationship between the server they
wanted to talk to and the server's URL
2) the client supplied the URL to the browser
3) the browser validated the digital certifcate obtained from the
server
4) the browser validated the URL corresponded with the URL in
the (validated) digital certificate
misc. past posts mentioning SSL domain name digital certficates
and/or domain name digital certification
http://www.garlic.com/~lynn/subpubkey.html#sslcerts
Almost immediately electronic commerce webservers discouvered that SSL
cut their thruput significantly and they dropped back to using SSL just
for payment/checkout. This created a large disconnect in the assumption
about the SSL business process and the associated integrity/security
that it provided. No longer was SSL being used to validate the URL
provided for initial contact.
The payment/checkout paradigm has the (typically completely unvalidated)
webserver making claims about a button that is clicked on. The client
clicks on a button which results in the webserver supplying a URL to the
browser (not the client). This now typically creates a huge disconnect
between the webserver that a client thinks they are talking to and the
associated URL.
Since the browser is only validating that the authenticated supplied
digital certificate corresponds to the supplied URL (not by the client
but by the webserver that hasn't been authenticate) ... SSL typical is
now
the webserver that a client is interacting with ... is the
webserver that the webserver claims to be
There is a huge difference between validating that the webserver is the
webserver the client believes it to be vis-a-vis validating that the
webserver is the webserver that it claims to be.
This is also at the root of phishing vulnerabilities ... an email has
verbage saying clicking on a button takes the client to a banking
webserver ... the actual URL is for some webserver under control of an
attacker ... who has applied for and obtained a valid domain name
digital certificate for that webserver (proving that the webserver is the
valid webserver for that URL).
The critical issue in the original SSL deployment was that the client
knew & understood the relationship between the webserver they
believed they were talking to and that webserver's (SSL validated)
URL. That has become increasingly rare in the current environment.
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Verifying Verified By Visa - Registration breaks chain of trust
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Verifying Verified By Visa - Registration breaks chain of trust
Newsgroups: uk.finance,comp.security.misc
Date: Sat, 02 Aug 2008 15:41:51 -0400
Anne & Lynn Wheeler <lynn@garlic.com> writes:
This is also at the root of phishing vulnerabiilties ... an email has
verbage saying clicking on a button takes the client to a banking
webserver ... the actual URL is for some webserver under control of an
attacker ... who has applied for and obtained a valid domain name
digital certificate for that webserver (proving that the webserver is the
valid webserver for that URL).
re:
http://www.garlic.com/~lynn/2008l.html#28 Verifying Verified By Visa - Registration breaks chain of trust
an email phishing countermeasure has been if the area to be clicked on
(i.e. between the ">" after the href URL and the "</a>") looks to be a
URL ... then the email client checks if the purported claimed URL
matches the actual URL in the href. A simple work-around/countermeasure
(by the attackers) is to not display anything that resembles a URL
... so there is nothing to match on.
However, i've seen cases (for at least some email clients) ... where
they take the hostname from what appears to be a displayed URL ... and
do a string compare against the hostname in the actual href URL ... and
it is treated as valid, even if the attackers are using a much longer
hostname (that just has a prefix part that matches the hostname part of
what is displayed).
the URL may or may not be a HTTPS/SSL connection. However, even if it is
a SSL connection ... all the attackers need to have done is to obtain a
SSL digital certificate proving that the actual provided URL (in the
HREF, not what is displayed) is a valid URL.
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Verifying Verified By Visa - Registration breaks chain of trust
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Verifying Verified By Visa - Registration breaks chain of trust
Newsgroups: uk.finance,comp.security.misc
Date: Sat, 02 Aug 2008 15:59:18 -0400
David Woolley <david@ex.djwhome.demon.co.uk.invalid> writes:
Which is why banks should be encouraging people to challenge any
unexpected domain name, rather than making unannounced domain name
switches themselves (but they also use other bad practices, like using
scripting)
re:
http://www.garlic.com/~lynn/2008l.html#28 Verifying Verified By Visa - Registration breaks chain of trust
http://www.garlic.com/~lynn/2008l.html#29 Verifying Verified By Visa - Registration breaks chain of trust
then you probably aren't going to like:
Huge rise in fraud against UK banks
http://www.vnunet.com/vnunet/news/2222850/fraud-against-uk-banks-rise-kpmg
Bank fraud rockets in wake of credit crunch
http://www.inthenews.co.uk/money/manchester-united/features/bank-fraud-rockets-in-wake-credit-crunch-$1233892.htm
Banks hardest hit by fraudsters in 2008
http://www.channelweb.co.uk/crn/news/2222802/banks-hardest-hit-fraudsters
Major fraud against banks soars
http://www.computerweekly.com/Articles/2008/07/29/231676/major-fraud-against-banks-soars.htm
US Web Banking Full of Security Flaws - Three out of four financial
institutions have security related issues
http://news.softpedia.com/news/US-Web-Banking-Full-of-Security-Flaws-90860.shtml
Study Claims Majority of Web Banking Sites Insecure
http://www.epaynews.com/index.cgi?survey=&ref=browse&f=view&id=1217276924837016561&block=
UK banks hit by record fraud levels
http://www.finextra.com/fullstory.asp?id=18791
e-banking cybercrime
http://www.securitypark.co.uk/security_article261863.html
Security shocker: 75% of US Bank websites have flaws
http://www.theregister.co.uk/2008/07/25/bank_sites_insecure/
Three in Four Banks Exposed to Fraud Online: U Mich study
http://www.financetech.com/news/showArticle.jhtml?articleID=209601142
e-banking not yet secure
http://attrition.org/pipermail/dataloss/2008-July/002565.html
Study on Bank Site Security Design Flaws
http://bankwebsecurity.blogspot.com/
Banks warned of computer 'super bug' that can change identity
http://business.scotsman.com/bankinginsurance/Banks-warned-of-computer-39super.4328710.jp
Web banking security flaws 'widespread'
http://www.vnunet.com/vnunet/news/2222561/security-flaws-widespread-web
It's reality: legitimate websites are no longer safe (security breach)
http://www.securecomputing.net.au/News/117708,its-reality-legitimate-websites-are-no-longer-safe.aspx
Design flaws, besides vulnerabilities, hurt banking sites
http://www.networkworld.com/news/2008/072308-design-flaws-besides-vulnerabilities-hurt.html
Study finds bank websites vulnerable to hackers
http://www.latimes.com/business/la-fi-bankweb24-2008jul24,0,1619927.story
Design flaws impair security at banking sites
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9110549&source=NLT_AM&nlid=1
Online Banking: Widespread Security Flaws Revealed
http://www.livescience.com/technology/080723-online-banking.html
Three out of four banking websites have serious security flaws - study
http://www.tgdaily.com/content/view/38553/108/
Widespread Flaws In Online Banking Security Found
http://www.redorbit.com/news/technology/1491509/widespread_flaws_in_online_banking_security_found/index.html
Online Banking Security Flaws
http://www.technologynewsdaily.com/node/10099
Security flaws in online banking sites found to be widespread
http://www.physorg.com/news136023039.html
Summary Box: Study sees online banking flaws
http://news.yahoo.com/s/ap/20080723/ap_on_hi_te/tec_banking_security_summary_box
Studies: Banking Web sites, corporate computers are insecure
http://news.yahoo.com/s/cnet/20080723/tc_cnet/830110093999810683
Study: Online banking possibly dicier than assumed
http://news.yahoo.com/s/ap/tec_banking_security
Most Bank Websites Are Insecure
http://it.slashdot.org/it/08/07/24/1227230.shtml
Design Flaws, Besides Vulnerabilities, Hurt Banking Sites
http://www.pcworld.com/businesscenter/article/148790/design_flaws_besides_vulnerabilities_hurt_banking_sites.html
Design Flaws, Besides Vulnerabilities, Hurt Banking Sites
http://news.yahoo.com/s/pcworld/20080723/tc_pcworld/148790
Researchers Find Security Flaws In Online Banking Sites
http://www.consumeraffairs.com/news04/2008/07/online_banking.html
Design flaws impair security at banking sites
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9110549
Most Bank Sites Are Insecure
http://www.informationweek.com/news/internet/security/showArticle.jhtml?articleID=209600041
Study: websites of financial institutions insecure by design
http://arstechnica.com/news.ars/post/20080723-study-websites-of-financial-institutions-insecure-by-design.html
Study: Online banking possibly dicier than assumed
http://www.sfgate.com/cgi-bin/article.cgi?f=/n/a/2008/07/23/financial/f120506D22.DTL
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Authentication in the e-tailer / payment gateway / customer triangle
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Authentication in the e-tailer / payment gateway / customer triangle
Newsgroups: uk.finance,comp.security.misc
Date: Sat, 02 Aug 2008 17:14:17 -0400
David Woolley <david@ex.djwhome.demon.co.uk.invalid> writes:
What you haven't said, but must be the case, is that, if they don't
have public keys, they must have shared-secrets. preferably a bit
stronger than the last transaction number, and information that is
secure by obscurity.
re:
http://www.garlic.com/~lynn/2008l.html#28 Verifying Verified By Visa - Registration breaks chain of trust
http://www.garlic.com/~lynn/2008l.html#29 Verifying Verified By Visa - Registration breaks chain of trust
http://www.garlic.com/~lynn/2008l.html#30 Verifying Verified By Visa - Registration breaks chain of trust
I didn't say they didn't have public keys ... i claimed that the digital
certificates were redundant and superfluous.
for some topic drift ... the original public key draft for Kerberos
was certificate-less ... with digital certificate specification added
later (kerberos is a widely used authentication infrastructure available
on mainly platforms, including windows)
http://www.garlic.com/~lynn/subpubkey.html#kerberos
there have also been certificate-less public key implementations dones
for RADIUS ... a widely used authentication mechanism used by
ISPs and corporate intranets ... frequently the mechanisms found
at the server end of PPP connections
http://www.garlic.com/~lynn/subpubkey.html#radius
misc. posts mentioning public key & digital signature authentication
w/o requiring digital certificates
http://www.garlic.com/~lynn/subpubkey.html#certless
in the certification authority model ... a public key is generated and a
certification authority does some validating about the entity associated
with the public key and other information associated with the entity.
it then issues a digital signed digital certificate (including the
entity's public key and the associated information).
this is part of the process that we long ago and far away audited
... when the organizations calling themselves certification authorities
were new & young.
however, for this to work ... a browser (or other application) has a
built-in table of public keys (belonging to certification authorities)
that are used to validate/authenticate the (certification authorties)
digital signature on the digital certificate ... as the step where the
browser/application "validates" the digital certificate (before
trusting/making use of the public key included in the digital
certificate).
so the payment gateway provides its public key directly to the
webservers as part of all the other stuff that the payment gateway
provides to the webserver for correct operation. each webserver provides
their public key to the entity operating the payment gateway (as part of
a whole lot of other information that they need to provide). the
exchanged public keys are kept in tables in much the same way that
browsers keeps a table of (trusted) certification authority public keys.
involving an independent (redundant and superfluous) 3rd party
certification authority in the process, is redundant and superfluous and
the digital certificates that they issue are then also redundant and
superfluous.
the digital certficate scenario is the electronic analogy to letters of
credit/introduction from the sailing ship days when the relying party
had first time encounter with complete stranger and had no other
recourse to information about the stranger they were dealing with.
the digital certificate design point is the offline email paradigm from
the early 80s; the electronic postoffice is dialed, email exhanged,
connection is broken ... and there is first-time communcation between a
complete stranger. In the absence of any other mechanism for information
about the stranger, a digital certificate can be better than nothing.
after having realized that digital certificates were redundant and
superfluous in situations where the parties already have information
about each other and/or have online access to information about each other
... which was part of setting up payment gateway for electronic commerce
http://www.garlic.com/~lynn/subnetwork.html#gateway
we were brought in to the x9a10 financial standard working group
that had been given the requirement to preserve the integrity of the
financial infrastructure for all retail transactions ... which resulted
in the x9.59 financial standard
http://www.garlic.com/~lynn/x959.html#x959
some of the other financial transactions efforts going on in that period
(that also involved public key) ... were heavily steeped in digital
certificates. a serious roadblock for them was that the digital
certificate paradigm increased the typical payment transaction size by a
factor of 100 times as well as increasing the processing overhead by a
factor of 100 times. misc. past posts mentioning the enormous bloat that
(redundant and superfluous) digital certificates represented for payment
transactions
http://www.garlic.com/~lynn/subpubkey.html#bloat
the x9a10 financial standard working group had been given the
requirement to preserve the integrity of the financial infrasturcture
for ALL retail transactions ... and so we had a lot of payload size,
transaction processing overhead and protocol chatter constraints that
other efforts simply ignored.
for other topic drift ... recent posts in crypto mailing list regarding
certificate-less public key in the DNSSEC scenario and a hypothetical
superfast SSL "lite"
http://www.garlic.com/~lynn/2008k.html#48 The PKC-only application security model
http://www.garlic.com/~lynn/2008k.html#49 The PKC-only application security model
http://www.garlic.com/~lynn/2008k.html#51 The PKC-only application security model
http://www.garlic.com/~lynn/2008k.html#54 The PKC-only application security model
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Authentication in the e-tailer / payment gateway / customer triangle
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Authentication in the e-tailer / payment gateway / customer triangle
Newsgroups: uk.finance,comp.security.misc
Date: Sat, 02 Aug 2008 17:38:51 -0400
David Woolley <david@ex.djwhome.demon.co.uk.invalid> writes:
Note that, because the internet is vulnerable to man in the middle
attacks, you cannot safely negotiate session keys without
simultaneously authenticating, even though I believe the SSL libraries
allow this. That authentication can be done with symmetric keys, and
in the extreme case, authentication can simply be the result of using
the master key without negotiating a session key.
re:
http://www.garlic.com/~lynn/2008l.html#28 Verifying Verified By Visa - Registration breaks chain of trust
http://www.garlic.com/~lynn/2008l.html#29 Verifying Verified By Visa - Registration breaks chain of trust
http://www.garlic.com/~lynn/2008l.html#30 Verifying Verified By Visa - Registration breaks chain of trust
http://www.garlic.com/~lynn/2008l.html#31 Authentication in the e-tailer / payment gateway / customer triangle
for other topic drift, lots of past posts discussing man-in-the-middle
attacks
http://www.garlic.com/~lynn/subintegrity.html#mitm
one of the scenarios about certificate-less operation
http://www.garlic.com/~lynn/subpubkey.html#certless
is that the table of trusted (certification authorities) public keys
preloaded in browsers and PGP tables of trusted public keys are
effectively the same mechanism ... they are directly trusted public
keys.
certification authorities and digital certificates provide a mechanism
for indirect trust (ala letters of credit/introduction model from
sailing ship days) when there is no other source for the information.
for other topic drift ... part of recent thread in crypto mailing list
and (uk) financial crypto blog about historical pgp (and certificate-less
public key)
http://www.garlic.com/~lynn/2008i.html#86 Own a piece of the crypto wars
http://www.garlic.com/~lynn/2008i.html#87 Historical copy of PGP 5.0i for sale -- reminder of the war we lost
there is archeological reference/copy of old email from '81
http://www.garlic.com/~lynn/2006w.html#email810515
for a (certificate-less) pgp-like implementation ... approx. decade
before pgp.
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Authentication in the e-tailer / payment gateway / customer triangle
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Authentication in the e-tailer / payment gateway / customer triangle
Newsgroups: uk.finance,comp.security.misc
Date: Sat, 02 Aug 2008 18:00:16 -0400
David Woolley <david@ex.djwhome.demon.co.uk.invalid> writes:
It is also important that significant information about the
transaction is reconfirmed in the authenticated part of the
transaction - in particular transaction value (as a limit on risk) and
delivery address, although the details of the order are also a good
idea.
re:
http://www.garlic.com/~lynn/2008l.html#28 Verifying Verified By Visa - Registration breaks chain of trust
http://www.garlic.com/~lynn/2008l.html#29 Verifying Verified By Visa - Registration breaks chain of trust
http://www.garlic.com/~lynn/2008l.html#30 Verifying Verified By Visa - Registration breaks chain of trust
http://www.garlic.com/~lynn/2008l.html#31 Authentication in the e-tailer / payment gateway / customer triangle
http://www.garlic.com/~lynn/2008l.html#32 Authentication in the e-tailer / payment gateway / customer triangle
there is overlap in this area between x9.59 financial transaction
standard (usable with certificate-less public key) ... references
http://www.garlic.com/~lynn/x959.html#x959
and the EU FINREAD standard ... misc. past posts discussing
issues and objectives of the EU FINREAD standard
http://www.garlic.com/~lynn/subintegrity.html#finread
... i.e. how do you know that the transaction being digitally
signed is really the transaction that you think it is.
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Authentication in the e-tailer / payment gateway / customer triangle
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Authentication in the e-tailer / payment gateway / customer triangle
Newsgroups: uk.finance,comp.security.misc
Date: Sat, 02 Aug 2008 20:13:04 -0400
David Woolley <david@ex.djwhome.demon.co.uk.invalid> writes:
Further topic drift: there are other flaws in the certificate system
in that, by default, browsers come with all certificates enabled, but
some represent higher levels of verification than others. As the
level of trust for some interactions may differ from that for others,
one would really need to check the issuer on every access needing more
than minimal authentication. That's mainly dumbing down, but it has
been suggested that you can basically buy the right to have a root
certificate in a browser. I think very few browser users realise that
not all certificates are alike.
there have been several discussions over the past decade on the
vulnerabiilty of the infrastructure when all certification authorities
are treated the same. simplest scenario is that if the probability of
any particular certification authority is X/year and there are 100
loaded certification authority public keys ... then a compromise of any
specific one (compromising the whole infrastructure) is 100*x/year.
One issue raised is what happens if a certification authority goes out
of business, what is the assurance of the associated private keys.
as discussed in this scenario
http://www.garlic.com/~lynn/2008k.html#48 The PKC-only application security model
http://www.garlic.com/~lynn/2008k.html#49 The PKC-only application security model
http://www.garlic.com/~lynn/2008k.html#51 The PKC-only application security model
http://www.garlic.com/~lynn/2008k.html#54 The PKC-only application security model
mentioned in earlier post
http://www.garlic.com/~lynn/2008l.html#32 Authentication in the e-tailer / payment gateway / customer triangle
is the ssl domain name certification authority catch-22
http://www.garlic.com/~lynn/subpubkey.html#catch22
Basically, some number of the SSL domain name certification
authorities were supporting DNSSEC operation ... for a couple of
reasons.
1) the original SSL domain name digital certificates were, in part,
justified based on perceived weaknesses in the domain name
infrastructure. However, the SSL domain name certification authorities
rely on the integrity of the domain name infrastructure as to the "true"
owner of a domain (when validating requests for SSL domain name digital
certificates). Part of the DNSSEC scenario would include having domain
name applicants to register a public key as part of registering a domain
name. Then future communication would be digitally signed (authenticated
with the on-file public key), minimizing vulnerabilities like domain
name hijacking. This improves the trust that certification authority
can correctly identify the true owner of a domain .... and validating
that the true owner is applying for an SSL domain name digital
certificate i.e. a fundamental basic trust issue for ssl domain name
digital certificate resides in whether the domain name infrastructure
correctly maintains the true owner of the domain name.
2) the current SSL domain name digital certificate process requires the
certification authority to perform the expensive, time-consuming, and
error-prone process of verifying that the digital certificate applicant
is the same as the owner on-file with the domain name infrastructure.
With an on-file public key, the certification authorities, can require
that SSL digital certificate applications be digitally signed. They
then could do a real-time retrieval of the on-file public key and turn
an error-prone, time-consuming, and expensive verification process into
a much simpler, less-expensive and reliable authentication process.
this creates the catch-22, since if the certification authorities can do
real-time retrieval of on-file public key ... then it is possible that
the rest of the world could also.
the scenario is that a standard DNS host->ip-address lookup would
optionally piggy-back a (on-file) public key (and potentially other
crypto negotiation options) in the responseresponse. Then an extremely
lightweight SSL ... has the client generating the random secret key,
encoding it with the server's public key and encrypting the initial
communication ... from the start (bypassing all the SSL protocol setup
chatter).
For additional topic drift ... in the 80s ... we had been involved in
both the NSFNET backbone activity ... some old email
http://www.garlic.com/~lynn/lhwemail.html#nsfnet
and various posts
http://www.garlic.com/~lynn/subnetwork.html#nsfnet
and we were also on the XTP technical advisory board ... which was
looking at a highly efficient reliable protocol ... that would support
both efficient reliable transaction operation (minimum packet exchange
of 3 packets ... compared to minimum packet exchange of 7 packets for
TCP) as well as multicast and some number of other features. There was
also an attempt to get (ASC) X3S3.3 (us chartered organization for
standards involving the area around level 3 & level 4 in the OSI
networking model) ... misc. past posts
http://www.garlic.com/~lynn/subnetwork.html#xtphsp
So in XTP terms (having access to the server's public key, either
cached from some previous interaction and/or piggy-backed on recent
name->ip-address response), a full reliable transaction SSL-lite
could be done in the 3-packet minimum exchange ... piggybacking the
first packet with the public key encoded random secret
(session/transaction) key on the encrypted transaction.
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Quality of IBM school clock systems?
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Quality of IBM school clock systems?
Newsgroups: alt.folklore.computers
Date: Sat, 02 Aug 2008 20:34:17 -0400
krw <krw@att.bizzzzzzzzzz> writes:
Indeed. At my CPOE (for another week) I'm surprised we're allowed
to have them; classified contracts and all. Cameras aren't
permitted (except cell phones, but we're admonished not to use the
cameras [*]) but I can swipe an entire project on a stick. At the
PPOE, the entire PowerPC 970 design easily fit on a stick. Some
did carry it around in their pocket. I just carried my piece
(Instruction Sequencing Unit). ;-)
FBI: Flash drive used to steal Countrywide customer data
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9111438
from above:
Using his computer at work, he saved the customer data onto his own
flash drives to remove it from the office, the FBI alleges.
... snip ...
... he was arrested for stealing the customer data and then selling it.
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
dollar coins
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: dollar coins
Newsgroups: alt.folklore.computers
Date: Sun, 03 Aug 2008 00:34:59 -0400
ArarghMail808NOSPAM writes:
And the last time I was on I-70, in Ohio, it would have done a roller
coaster proud, with all the broken up pavement.
as past posts, nearly all of this is heavy truck useage ... modulo not
doing basic design and engineering for things like frost heaves.
http://www.garlic.com/~lynn/99.html#22 Roads as Runways Was: Re: BA Solves Y2K (Was: Re: Chinese Solve Y2K)
http://www.garlic.com/~lynn/2002i.html#28 trains was: Al Gore and the Internet
http://www.garlic.com/~lynn/2002i.html#35 pop density was: trains was: Al Gore and the Internet
http://www.garlic.com/~lynn/2002i.html#36 pop density was: trains was: Al Gore and the Internet
http://www.garlic.com/~lynn/2002j.html#42 Transportation
http://www.garlic.com/~lynn/2002j.html#68 Killer Hard Drives - Shrapnel?
http://www.garlic.com/~lynn/2003j.html#11 Idiot drivers
http://www.garlic.com/~lynn/2006h.html#45 The Pankian Metaphor
http://www.garlic.com/~lynn/2008l.html#24 dollar coins
http://www.garlic.com/~lynn/2008l.html#26 dollar coins
highways have to be heavily engineered to handle projected heavy truck
axle-load i.e. each axle-load from heavy truck causes damage (with cars
and lighter weight trucks having negligible effect). highway basically
is engineered to survive the damage from projected number of heavy truck
axle loads (and requiring rebuilding highway roadbed and payment
infrastructure).
doubling the daily heavy truck axle-loads (over projected) can
approx. cut the useful hig