From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Fri, 25 May 2007 16:57:12 -0600Charlton Wilbur <cwilbur@chromatico.net> writes:
so one of the ideas behind public/private key business process ... is that the relying-party/recipient has a local repository of trusted public keys. any communication they get that has been digitally signed, the recepient verifies the digital signature with a public key from their local trusted public key repository.
the PKI certification authority industry expanded this for the scenario where 1) you have first time communication with stranger you have never communicated with before, 2) you don't have their public key in your trusted public key resposotory, and 3) you have no way of doing timely, online direct communication with a trusted certification institution to obtain information about this stranger.
so your trusted public key respository is preloaded with the public keys of a bunch of trusted "certification authorities" ... these certification authorities, certify the public keys of "strangers", and issue than a digitally signed certificate (representing that certification). now relying-party/clients can verify the digital signature on a certificate (using certification authority public key from their local trusted public key repository) ... and then trust the public key included in the digital certificate. This is basically a one-level indirection from the basic design where you have trusted public keys of the entities you are directly communicating with ... now you have trusted public keys of the certifying authorities ... which indirectly get you trusted public keys of the strangers that you are having first time communication.
So one of the first vulnerabilities ... is all the public keys in your local trusted public key repository are treated equally. You don't have to subvert the public key of a particular certification authority, all you have to do is subvert any of the possibly 40-50 public keys (in the repository) belonging to any certification authority. Another attack is a virus/trojan that is able to add a new public key to the respository. The way the mechanism work is that there just has to be at least one compromised public key in the client's trusted public key repository.
Another successful attack scenario is things like domain name hijacking. Part of the whole original SSL stuff was to address some perceived vulnerabilities in the domain name infrastructure. The issue is that the certification of a domain name (represented by a digital certificate) is countermeasure to perceived weaknesses in the domain name infrastructure.
The problem is that all the domain name certification authorities have to check with the domain name infrastructure as to the true owner of a domain ... when they are processing an application for a SSL domain name digital certificate. This is a time-consuming, error prone, and expensive identification process to match the SSL domain name digital certificate applicant with the information on file with the domain name infrastructure as to the owner of the domain name. Now an interesting fact, the effective "trust root" for SSL certificates ... is the domain name infrastructure ... the very same domain name infrastructure that has integrity issues justifying the existance of SSL certificates. Any problem in any domain name infrastructure and/or any certification authority might result in the issuing of a valid SSL digital certificate to an incorrect/fraudulent party.
So there is something of a catch-22 for the SSL domain name
certification authority industry ... lots of past discussions
https://www.garlic.com/~lynn/subpubkey.html#catch22
Part of DNSSEC to improve the integrity of the domain name infrastructure is for things like requiring domain name owners to have an onfile public key with the domain name infrastructure. Improving the integrity of the domain name infrastructure is both
1) in the interests of the certification authority industry because it lessons the probability of domain name hijacking and crooked applicant being issued a valid digital certificate
2) not in the interest of the certification authority industry because improvements in the domain name infrastructure integrity negates the original justification for having SSL domain name certificates.
Another part of the catch-22 is if the domain name infrastructure can require all communication to be digitally signed (which they can verify with the "onfile" public key; direct public key, no digital certificate required) .... then it is possible that the certification authority could also. Requiring all SSL domain name certification applications to be digitally signed means that the certification authority can do a real-time, online retrieval of the onfile public key to verify the signature (no digital certificate required) and change a time-consuming, expensive, and error prone identification processing into a significantly simpler, less expensive, and more reliable authentication process.
The problem is that if both the domain name infrastructure and the
certification authority industry can start using real-time, online
retrieval of certificate-less public keys ... then the rest of the world
might be able to also. Some discussions of certificate-less public key
operation
https://www.garlic.com/~lynn/subpubkey.html#certless
Improving the integrity of the domain name infrastructure goes a long way of negating the original justification for having SSL domain name certification (and the associated digital certificates). Being able to do trusted real-time, online retrieval of public keys then finishes making the SSL domain name digital certificates obsolete, redundant and superfluous.
A big part of the problem is that the certification authority industry
are dependent on the integrity of the domain name infrastructure as to
the true owner of the domain name (in determining who will and will
not be issued digital certificates for a domain). However, the
certification authority industry is also dependent on the lack of
integrity of the domain name infrastructure as the justification for
having SSL domain name certificates. lots of past SSL and/or
SSL digital certificate posts
https://www.garlic.com/~lynn/subpubkey.html#sslcert
recent posts on the subject:
https://www.garlic.com/~lynn/aadsm27.htm#0 H6.2 Most Standardised Security Protocols are Too Heavy
https://www.garlic.com/~lynn/aadsm27.htm#1 H6.2 Most Standardised Security Protocols are Too Heavy
https://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#16 dnssec?
https://www.garlic.com/~lynn/aadsm27.htm#17 dnssec?
https://www.garlic.com/~lynn/aadsm27.htm#19 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#20 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#21 307 digit number factored
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The top 10 dead (or dying) computer skills Newsgroups: alt.folklore.computers Date: Fri, 25 May 2007 19:51:44 -0600Steve O'Hara-Smith <steveo@eircom.net> writes:
pink floundered ... although some of the object oriented technology lived on for awhile in taligent. instead apple moved to the (CMU) MACH microkernel (also had been used in NeXT).
spring also foundered ... although i've had some discussions about whether some of it influenced JAVA (i.e. spring had a small footprint interpreter for client machines supporting efficiency of downloading applications). at one point we got polled if we would be interested in heading up a project to do the industrial strength stuff to get spring out the door.
old posts mentioning pink, spring, taligent, etc
https://www.garlic.com/~lynn/2000.html#10 Taligent
https://www.garlic.com/~lynn/2000e.html#42 IBM's Workplace OS (Was: .. Pink)
https://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)
https://www.garlic.com/~lynn/2000e.html#46 Where are they now : Taligent and Pink
https://www.garlic.com/~lynn/2000e.html#48 Where are they now : Taligent and Pink
https://www.garlic.com/~lynn/2001j.html#32 Whom Do Programmers Admire Now???
https://www.garlic.com/~lynn/2001j.html#36 Proper ISA lifespan?
https://www.garlic.com/~lynn/2001n.html#93 Buffer overflow
https://www.garlic.com/~lynn/2002i.html#60 Unisys A11 worth keeping?
https://www.garlic.com/~lynn/2002j.html#76 Difference between Unix and Linux?
https://www.garlic.com/~lynn/2002m.html#60 The next big things that weren't
https://www.garlic.com/~lynn/2003d.html#45 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
https://www.garlic.com/~lynn/2003d.html#47 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
https://www.garlic.com/~lynn/2003e.html#28 A Speculative question
https://www.garlic.com/~lynn/2003e.html#51 A Speculative question
https://www.garlic.com/~lynn/2004c.html#53 defination of terms: "Application Server" vs. "Transaction Server"
https://www.garlic.com/~lynn/2004p.html#64 Systems software versus applications software definitions
https://www.garlic.com/~lynn/2005b.html#40 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005e.html#14 Misuse of word "microcode"
https://www.garlic.com/~lynn/2005f.html#38 Where should the type information be: in tags and descriptors
https://www.garlic.com/~lynn/2005i.html#42 Development as Configuration
https://www.garlic.com/~lynn/2007g.html#69 The Perfect Computer - 36 bits?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Sat, 26 May 2007 07:38:04 -0600jmfbahciv writes:
there are other issues. normal business practices has some sort of contractual relationship/obligation between two parties ... i.e. the relying party ... that is receiving a digital signature (with an appended digital certificate) and the party generating the digital signature (and has appended the digital certificate).
the term relying party, comes from the party that is relying on the "certified" information contained in a digital certificate.
many standard PKI and digital certificates ... essentially violate standard business model and business practices ... because there is frequently no contractual and/or business relationship between the relying party and the certification authority (no exchange of value or money) ... and therefor any basis for establishing reliance and/or liability.
the federal government PKI has gotten around the problem of lack of any normal business practices by having the GSA (representing the federal gov. as the relying party) sign a contract with each of the authorized certification authorities. The certification authorities then certify various individual information and place that certified information in a digitally signed digital certification. When individuals digitally sign communication sent to the federal gov and attach a digital certificate, the relying party (the federal gov.) has a valid contract and business justification to "rely" on the certified information.
The normal practice with SSL domain name certificates ... has at least an implied contract between merchant webservers and certification authorities ... since the webserver has paid money to the certification authority. However, clients that use SSL to connect to the webserver ... and are therefor the relying party for the presented digital certificate ... have no explicit, implicit and/or implied contract with the certification authority ... and therefor no "grounds" for estalishing any legal reliance or obligation between the certification authority and the clients as relying parties. This is in addition to any disclaimers by certification authorities with reqard to liability and/or obligation ... aka there is no legal reason for clients (as relying parties) to believe that they can rely on the information in such digital certificates (since there is no business or legal obligation to base such a claim). In general, most "trusted 3rd party" PKI operations don't conform to any standard, traditional business and/or legal practices.
There is another issue, that there frequently appears to be semantic
confusion because the term human signature and the term digital
signature both contain the word signature ... which can create the
impression that a digital signature can somehow be analogous to a
human signature. We had been brought in to help word smith the
cal. state electronic signature legislation (and later the federal
electronic signature legislation). some posts discussing the activity
https://www.garlic.com/~lynn/subpubkey.html#signature
There was some lobbying attempting to have gov. mandates that electronic signatures were digital signatures and would have required appended digital certificates from a designated/authorized certification authority. However, some of the business lawyers present pointed out that both standard digital signature process and any possible appended digital certificates failed to meet requirement for human signatures involving indidication that a human had read, understood, agrees, approves, and/or authorizes what has been "signed".
Neither digital signatures ... and/or any appended digital certificate (which may have generated at some point far in the past, along with any certifying operations) carried with it any implication of human intent ... and/or the action of having read, understood, agrees, approves, and/or authorizes.
basic "digital signature" provides "authentication" and "integrity" business processes ... but fails to satisfy any conditions related to human intent and/or having read, understood, agrees, approves, and/or authorizes.
There is further possible compromises/exploits when digital signatures get confused with having read, understood, agrees, approves, and/or authorizes. In most cases, a human hasn't actually physically examined the bits for which a digital signature may get generated (i.e. fails to even meet "read/understood" requirement).
A typical scenario is a PKI digital signature "authentication" protocol (which might be used in place of userid/password scenario). The server sends the client some "random data" (as countermeasure to login replay attack) to be digitally signed. The client's computer would typically digitally sign the transmitted data (random and changes on every use ... so attacker couldn't evesdrop the exchange and replay it later) and returns the digital signature to the server. The server then can "authenticate" the client by validating the digital signature with the client's public key.
Now, if there ever was the mischance of also confusing digital signature with human signature ... and having individuals digital sign something ... creating obligation that the individual has read, understood, agrees, approves, and/or authorizes what had been digitally signed ... there is a dual-use attack opening. Somebody compromises some server, somplace in the world ... and substitutes valid transactions and/or contracts for the authentication protocol "random data" ... and starts to collect large number of legal, digitally signed contracts/obligations.
Misc. past posts discussing dual-use attacks ... and possibly
countermeasures.
https://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#56 two-factor authentication problems
https://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm19.htm#43 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm20.htm#0 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm21.htm#5 Is there any future for smartcards?
https://www.garlic.com/~lynn/aadsm21.htm#13 Contactless payments and the security challenges
https://www.garlic.com/~lynn/aadsm23.htm#13 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
https://www.garlic.com/~lynn/aadsm26.htm#60 crypto component services - is there a market?
https://www.garlic.com/~lynn/aadsm26.htm#63 Public key encrypt-then-sign or sign-then-encrypt?
https://www.garlic.com/~lynn/aadsm26.htm#65 Public key encrypt-then-sign or sign-then-encrypt?
https://www.garlic.com/~lynn/aadsm27.htm#4 Public key encrypt-then-sign or sign-then-encrypt?
https://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#21 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2005.html#14 Using smart cards for signing and authorization in applets
https://www.garlic.com/~lynn/2005b.html#56 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005e.html#31 Public/Private key pair protection on Windows
https://www.garlic.com/~lynn/2005g.html#46 Maximum RAM and ROM for smartcards
https://www.garlic.com/~lynn/2005m.html#1 Creating certs for others (without their private keys)
https://www.garlic.com/~lynn/2005m.html#11 Question about authentication protocols
https://www.garlic.com/~lynn/2005o.html#3 The Chinese MD5 attack
https://www.garlic.com/~lynn/2005q.html#23 Logon with Digital Siganture (PKI/OCES - or what else they're called)
https://www.garlic.com/~lynn/2005s.html#52 TTP and KCM
https://www.garlic.com/~lynn/2005v.html#3 ABN Tape - Found
https://www.garlic.com/~lynn/2006d.html#32 When *not* to sign an e-mail message?
https://www.garlic.com/~lynn/2006s.html#34 Basic Question
https://www.garlic.com/~lynn/2007i.html#73 public key password authentication
https://www.garlic.com/~lynn/2007i.html#74 public key password authentication
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Sat, 26 May 2007 07:57:52 -0600Anne & Lynn Wheeler <lynn@garlic.com> writes:
disclaimer ... although we no longer have any affiliation with the
patents, ... we did some work on how to establish an infrastructure
where operations performed by a device generating digital signatures
could meet the requirements for human signature ... aka
demonstration of intent, having read, understood, agrees,
approves, and/or authorizes.
https://www.garlic.com/~lynn/x959.html#aads
other posts having been brought in to help word-smith electronic
signature legislation.
https://www.garlic.com/~lynn/subpubkey.html#signature
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Sat, 26 May 2007 08:33:38 -0600jmfbahciv writes:
BIOS settings selects order in which devices are tested for booting.
BIOS will look and boot from specific hard disk partition based on settings on the hard disk
software is available to reorganization existing filesystems and hard disk partititions; changing which partition that BIOS should boot from, shrinking/enlarging existing partitions, making new partitions, etc. aka if there isn't unallocated/spare partition, shrink an existing windows partition (assuming it isn't full) and create new partition from the freed up space. alternative might be to add new hard disk to the system and change BIOS boot order specification.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM Unionization Newsgroups: alt.folklore.computers Date: Sat, 26 May 2007 08:47:09 -0600Anne & Lynn Wheeler <lynn@garlic.com> writes:
....
National Institute for Literacy
https://web.archive.org/web/20100413134230/http://www.nifl.gov/nifl/facts/facts_overview.html
NSF Science and Engineering Indicators 2006
http://www.nsf.gov/statistics/seind06/
Chapter 1: Elementary and Secondary Education
http://www.nsf.gov/statistics/seind06/c1/c1h.htm
note that the above is mostly just gauging whether US instituations have changed over time ... it isn't comparing them with institutions in other industrial nations (where US currently is ranking at the bottom or near the bottom).
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Sat, 26 May 2007 13:20:09 -0600jmfbahciv writes:
aka to establish a business obligation between a trusted third party certification authority and the "client" relying parties ... the "client" relying parties would have to sign some sort of contract with each the 40-50 different certification authorities that may be represented in typical browser trusted public key respository (as opposed to the contractual obligation that exists between trusted 3rd party certification authorities and webservers ... when the merchant pays the certification authority for some certification and receives a certificate representing that certification).
this is the work-around that the Federal Gov. PKI project achieved by having GSA sign a contract with each of the authorized certification authorities, representing the Federal Gov as relying party ... and creating a legal obligation between the federal gov relying parties and the certification authorities ... aka the certification authorities sold certification to parties wishing to deal (electronically) with the federal gov ... but w/o the GSA contract there was no obligation that would have existed between the certification authorities and any federal agencies relying on that certification.
In the SSL domain name certification authority ... since it is individual clients ... it possibly means each of the billion or so possible clients in the world ... which may use SSL and rely on a SSL domain name certification ... would have to sign contracts with each of the 40-50 or so certification authorities ... say fifty billion contracts in aggregate (with the client paying each certification authority some amount of money). It is no wonder that the majority of certification authorities have disclaimers disavowing all responsibility and liability ... since they have none (implied or otherwise) to the entities that would be relying on the certification (and the digital certificates).
lots of past posts about SSL digital certificates ... including their
"comfort" characteristics (i.e. they don't supply any actual business or
financial responsibility ... just the appearance of comfort).
https://www.garlic.com/~lynn/subpubkey.html#sslcert
and as noted ... there was some lobbying effort seen to get electronic
signature legislation to mandate digital signatures along with
"digital certificates" issued from authorized certification
authorities. however, that didn't actually happen. If fact, the
contracts and business type legal people pointed out that digital
signatures don't even meet the "intent" requirement for human
signatures as having read, understood, agrees, approves, and/or
authorizes. misc. past posts mentioning work on electronic
signature legislation
https://www.garlic.com/~lynn/subpubkey.html#signature
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Sat, 26 May 2007 14:51:33 -0600pechter@i4get.(none) (William Pechter) writes:
the office products division was looking to use 801/romp in a displaywriter follow-on product ... when that was killed ... the group look around for something else to use it for and came up with unix workstation. they hired the group that had done at&t unix port for pc/ix to do a port to romp ... and that was released as pc/rt and "AIX" v2. RIOS was follow-on to romp for rs/6000 and AIX V2 was enhanced into AIX V3.
separate from that ... the palo alto group had been formed to do
a port of BSD unix to mainframe ... recent reference with little
topic drift ...
https://www.garlic.com/~lynn/2007k.html#67 Non-Standard Mainframe Language?
before it shipped, the effort got redirected to port to pc/rt
... eventually offering "AOS" for the pc/rt as an alternative to AIX V2.
https://www.garlic.com/~lynn/subtopic.html#801
the palo alto group had also gotten involved with UCLA and Locus ... and eventually did a port of Locus to both the mainframe and 386 ... which was announced as AIX/370 and AIX/PS2.
Numerous of the (mainframe) unix ports (both ibm and others) tended to be deployed under vm370 ... the issue was that mainframe field service organization had extensive requirements for error analysis, error retry/recovery, and error logging/reporting. To implement a "native" version of such in unix would have been a significantly larger total effort than the effort doing the straight-forward port to the mainframe. Running unix in vm370 virtual machine allowed unix to get a free ride with regard to such requirements (since vm370 already had it built in).
an idea of the mainframe requirements is a story i periodically tell about having done a driver for channel extension operation around 1980. Several yrs later ... a year after the 3090 had started shipping, the 3090 product administrator tracted me down over a really, really big problem. The 3090 had been design was such that they were expecting 3-5 total 3090 channel errors to be recorded for all installed 3090s in a years operation. After a yrs operation, they had found that around 15 total 3090 channel errors had been recorded (this wasn't 15 errors per channel in a yr, or 15 errors per 3090 in a yr, this as a total of 15 errors for all installed 3090 in a yr). This represented a really, really big problem. After some analysis, they tracked it down to the choices I had made in the driver i had done. The channel extension would work over a T1 telco line. If i got a unrecoverable telco error ... i would simulate a "channel check" operation ... which would then invoke some amount of "higher level" retry logic ... but would also record that a "channel check" had occurred. Fiften total errors across all installed machines for a yr of operation instead of 3-5 total errors represented a really significant problem. So after a little investigation, I figured I could simulate an "interface control check" (IFCC) instead of "channel check" (CC) ... and for all intents and purposes the same retry/recovery logic would be invoked.
So I was giving a keynote at this NASA reliable computer workshop
https://web.archive.org/web/20011004023230/http://www.hdcc.cs.cmu.edu/may01/index.html
and i told the story about having redone the I/O supervisor for the disk
engineering lab. They had been attempting to do development hardware
testing in operating system environment ... and found that a single
"testcell" would result in a 15min MTBF for MVS operating system. I
undertook to rewrite the I/O infrastructure so that it would never
result in an operating system failure ... so they could do "on demand"
testing of several concurrent "test cells" w/o operating system problems
(as opposed to having to stick with their "stand alone" dedicated
testing schedules). lots of past posts about getting to play in the disk
engineering and disk product test labs
https://www.garlic.com/~lynn/subtopic.html#disk
I also described some of the stuff we had done for our
High Availability Cluster Multi-Processing product
https://www.garlic.com/~lynn/subtopic.html#hacmp
for other topic drift ... some past litany of working on ha/cmp
scale-up
https://www.garlic.com/~lynn/lhwemail.html#medusa
... and finally did a short rendition of the 3090 channel check story. Part of the story is that there has been this commercial service that collects the error logs from customer shops ... somewhat anonymizes the data and publishes monthly statistics.
Now, most of the major vendors were represented at the workshop ... so I asked how many of the vendors collected all error/incident activity from all installed machines and had detailed information about every error from every installed machine? There was no responses. If there had been, I was going to ask how many would have been willing to have detailed published public reports of the information. In fact, all of the vendors stated that divulging the information they did have would require a NDA.
misc. past posts mentioning the 3090 channel check "problem"
https://www.garlic.com/~lynn/2005e.html#13 Device and channel
https://www.garlic.com/~lynn/2006n.html#35 The very first text editor
https://www.garlic.com/~lynn/2006y.html#43 Remote Tape drives
https://www.garlic.com/~lynn/2007f.html#53 Is computer history taught now?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Sun, 27 May 2007 06:52:20 -0600Steve O'Hara-Smith <steveo@eircom.net> writes:
... and AADS
https://www.garlic.com/~lynn/x959.html#aads
the security acronym "PAIN"
i.e. in the mid-90s, the x9a10 financial standard working group had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments. the resulting x9.59 financial standard no longer needs to "hide" transactions, account numbers, etc ... in order to preserve the integrity of the infrastructure.
this is somewhat discussed in the naked transaction/payment metaphor,
i.e. security/protection is exceedingly difficult attempting to protect
naked transactions. the other way of viewing it is that x9.59 "armors"
each, individual transaction
https://www.garlic.com/~lynn/subintegrity.html#payments
and then individuals are no longer dependent that every business process along the processing path have absolutely perfect security (as countermeasure to fraud).
the other part in the mid-90s was that there were some claims that the complement to high-security was hardware tokens ... but the state-of-the-art at the time was that the really secure hardware tokens were too expensive for everyday operations. so we semi-facetiously said that we would take a $500 mil-spec part, aggresively cost reduce it by 2-3 orders of magnitude while improving the security and integrity.
from 3-factor authentication paradigm
https://www.garlic.com/~lynn/subintegrity.html#3factor
The overall infrastructure cost reduction then is 2-3 orders of magnitude reduction in cost of each individual secure token and 2-3 orders of magnitude reduction in the number of secure tokens that an each individual would have to carry (for an overall 4-6 orders of magnitude total infrastructure cost reduction for a secure token oriented environment).
misc. past posts mentioning work on being able to transition to
person-centric operation (with highly secure tokens):
https://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA)
https://www.garlic.com/~lynn/aadsm19.htm#14 To live in interesting times - open Identity systems
https://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm19.htm#47 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm20.htm#41 Another entry in the internet security hall of shame
https://www.garlic.com/~lynn/aadsm22.htm#12 thoughts on one time pads
https://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#7 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#42 Why security training is really important (and it ain't anything to do with security!)
https://www.garlic.com/~lynn/aadsm26.htm#35 Failure of PKI in messaging
https://www.garlic.com/~lynn/aadsm26.htm#48 Governance of anonymous financial services
https://www.garlic.com/~lynn/2003e.html#22 MP cost effectiveness
https://www.garlic.com/~lynn/2003e.html#31 MP cost effectiveness
https://www.garlic.com/~lynn/2004e.html#8 were dumb terminals actually so dumb???
https://www.garlic.com/~lynn/2005g.html#47 Maximum RAM and ROM for smartcards
https://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
https://www.garlic.com/~lynn/2005m.html#37 public key authentication
https://www.garlic.com/~lynn/2005p.html#6 Innovative password security
https://www.garlic.com/~lynn/2005p.html#25 Hi-tech no panacea for ID theft woes
https://www.garlic.com/~lynn/2005t.html#28 RSA SecurID product
https://www.garlic.com/~lynn/2005u.html#26 RSA SecurID product
https://www.garlic.com/~lynn/2006d.html#41 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006o.html#20 Gen 2 EPC Protocol Approved as ISO 18000-6C
https://www.garlic.com/~lynn/2006p.html#32 OT - hand-held security
https://www.garlic.com/~lynn/2006q.html#3 Device Authentication - The answer to attacks lauched using stolen passwords?
https://www.garlic.com/~lynn/2007b.html#12 Special characters in passwords was Re: RACF - Password rules
https://www.garlic.com/~lynn/2007b.html#13 special characters in passwords
https://www.garlic.com/~lynn/2007d.html#12 One Time Identification, a request for comments/testing
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Sun, 27 May 2007 08:17:56 -0600Anne & Lynn Wheeler <lynn@garlic.com> writes:
in the heat of the early 90s and x.509 identity digital certificates ... before the spreading realization of the enormous privacy and liabiilty problems ... there were certification authority business cases being floated that the industry would be a $20B/annum operation ... certifying and issuing renewable identity digital certificates for every person at $100/annum.
initially there was some conjecture that this cost would be underwritten by the financial industry. however (besides the realization regarding the enormous privacy and liability issues), the financial institutions realized that they already had the information regarding their clients ... why then would the financial institutions want to contribute $20B/annum to a certification authority industry ... for certification of information that the financial institutions already possessed?
this possibly then was some of the motivation behind the lobbying
efforts in the electronic signature legislative activity
... attempting to get legislation effectively mandating individuals to
have identity digital certificates from officially sanctioned
certification authorities ... recent reference:
https://www.garlic.com/~lynn/2007l.html#2 John W. Backus, 82, Fortran developer, dies
misc. past posts discussing the $20B/annum business case scenario for
the certification authority industry
https://www.garlic.com/~lynn/aadsm7.htm#rhose4 Rubber hose attack
https://www.garlic.com/~lynn/aadsm14.htm#29 Maybe It's Snake Oil All the Way Down
https://www.garlic.com/~lynn/aadsm18.htm#52 A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
https://www.garlic.com/~lynn/aadsm23.htm#29 JIBC April 2006 - "Security Revisionism"
https://www.garlic.com/~lynn/2005i.html#36 Improving Authentication on the Internet
https://www.garlic.com/~lynn/2007h.html#27 sizeof() was: The Perfect Computer - 36 bits?
in this period, one such example was a proposal to a large financial institution by a certification authority ... where the financial institution would purchase and register public key hardware tokens for each of their accounts. then the financial institution would transmit to the certification authority, the institution's master account file (containing all the pertinent account information as well as the registered public key). the certification authority then would fiddle the bits in each account record ... creating a digitally signed digital certificates (representing each account record). For each such "certified" account record, the certification authority would charge the financial institution only $100/account. the master account file had tens of millions of records ... so in return for this bit of bit fiddling operation, the financial institution would only be charged several billion dollars (in addition to the cost of the hardware token they would be buying for each account).
slightly related post on person-centric paradigm
https://www.garlic.com/~lynn/2007l.html#8 John W. Backus, 82, Fortran developer, dies
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Sun, 27 May 2007 08:47:49 -0600Charlton Wilbur <cwilbur@chromatico.net> writes:
clone controllers showed up in the 60s ... in fact as an undergraduate,
I helped develope a "clone controller" out of interdata/3 and reverse
engineering the channel interface and building channel interface board.
this got written up blaming the four of us for the clone controller
business ... misc. past posts
https://www.garlic.com/~lynn/submain.html#360pcm
supposedly the clone/compatible controller business then was the primary
motivation for the future system project in the early 70s:
https://www.garlic.com/~lynn/submain.html#futuresys
a reference about the motivation (that i've used numerous times):
https://www.ecole.org/en/session/49-the-rise-and-fall-of-ibm
https://www.ecole.org/en/session/49-the-rise-and-fall-of-ibm
from above:
IBM tried to react by launching a major project called the 'Future
System' (FS) in the early 1970's. The idea was to get so far ahead that
the competition would never be able to keep up, and to have such a high
level of integration that it would be impossible for competitors to
follow a compatible niche strategy. However, the project failed because
the objectives were too ambitious for the available technology. Many of
the ideas that were developed were nevertheless adapted for later
generations. Once IBM had acknowledged this failure, it launched its
'box strategy', which called for competitiveness with all the different
types of compatible sub-systems. But this proved to be difficult because
of IBM's cost structure and its R&D spending, and the strategy only
resulted in a partial narrowing of the price gap between IBM and its
rivals.
... snip ...
I've also conjectured that the FS project distraction (and subsequent failure) contributed to providing the opening for clone processers (i.e. while FS was going on, development in 370 product line was being neglected ... which help open opportunities for clone processors).
misc. recent posts
https://www.garlic.com/~lynn/2007e.html#48 time spent/day on a computer
https://www.garlic.com/~lynn/2007f.html#26 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007f.html#28 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007f.html#53 Is computer history taught now?
https://www.garlic.com/~lynn/2007f.html#57 Is computer history taught now?
https://www.garlic.com/~lynn/2007f.html#67 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007g.html#44 1960s: IBM mgmt mistrust of SLT for ICs?
https://www.garlic.com/~lynn/2007g.html#56 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007i.html#31 Latest Principles of Operation
https://www.garlic.com/~lynn/2007j.html#70 Using rexx to send an email
https://www.garlic.com/~lynn/2007k.html#26 user level TCP implementation
https://www.garlic.com/~lynn/2007k.html#60 3350 failures
for a little other topic drift ... various litigation in the 60s also
led to the 23jun69 "unbundling" announcement where lots of ("free")
stuff started to be separately charged for ... services, software,
etc. However, the logic was used that "kernel" software should
continue to be "free" (bundled) since it was required for the
operation of the machine.
https://www.garlic.com/~lynn/submain.html#unbundle
the appearance of the clone processors in the mid/late 70s ... then motivated the transition to charging for kernel software (i.e. not only did the clone manufacturers have to do less hardware R&D ... they could get by w/o having to do any operating system R&D for the machines).
this was just about the time i was going to ship my "resource manager"
... and it got tagged to be the guinea pig for charging for kernel
software. As a result ... i got to spend some amount of time with
business and legal people working out policy and practices for kernel
software charging/pricing. misc. collected posts mentioning various
operating system performance work
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Mon, 28 May 2007 08:23:31 -0600Frank McCoy <mccoyf@millcomm.com> writes:
360 conventions were to use string fields that provided string length with infrastruction conventions that length field was always managed and dealt with (implicitly in libraries and even low-level system call and/or explicit with inline code) ... and this convention permeated the infrastructure, assembler, pli, cobol, pascal, etc. as a result, the frequency of buffer overflows was significantly lower in 360 environments (even involving strictly assembler) than in any of the C language environments.
the implicit length convention in C and little or no infrastructure convention for handling length contributed greatly to the large number of buffer overflows compared to many other environments (including 360 assembler).
lots of past posts discussing buffer and length related problems
permeated infrastructures implemented in C language.
https://www.garlic.com/~lynn/subintegrity.html#overflow
up through end of last century ... buffer overflows related issues tended to account for majority of exploits. more recently, this has dropped to around twenty percent ... not so much because the number of buffer overflow exploits and declined but because of the large increase in exploits involving malicious executables arriving from the internet and phishing exploits.
when i was doing dumprx
https://www.garlic.com/~lynn/submain.html#dumprx
some recent mention:
https://www.garlic.com/~lynn/2007i.html#44 latest Principles of Operation
https://www.garlic.com/~lynn/2007j.html#26 Even worse than UNIX
https://www.garlic.com/~lynn/2007j.html#27 Even worse than UNIX
https://www.garlic.com/~lynn/2007k.html#64 Even worse than UNIX
... one of the things i did was extensive study of types of vm370 and cms failures (all involving code completely implemented in assembler) ... in part looking for telltale signatures that i could provide automated diagnostic aids for identifying. the incidents of buffer overflow was almost non-existent. i asset that is primarily because of length handling conventions that permeated the infrastructure (lacking in conventional C language programming) and had little or nothing to do with language used ... since the conventions tended to permeate all the assembler code as well as the higher level languages.
the original mainframe tcp/ip implementation was done in vs/pascal ... and i know of no buffer length exploits as part of that implemention. Now it could be claimed that it was related to language characteristics of pascal ... but i also claim that it was primarily because the whole infrastructure (regardless of language implementation) had a much more sensible length convention.
minor digression, that base tcp/ip implemention would get about aggregate 44kbytes/sec sustained thruput using full 3090 processor. i had done the changes to support rfc1044 and in some testing at cray research was getting 1mbyte/sec sustained thruput between cray and 4341-clone ... only using modest amount of the 4341 processor (around 500 times improvement in bytes transferred per instruction executed).
as before ... one of the few buffer related items is found in this
reference regarding some local mods in cp67 kernel (also done all in
assembler)
https://www.multicians.org/thvv/360-67.html
as undergraduate, one of the modifications i had done for cp67 was add tty/ascii terminal support (to existing 1052 and 2741 support) ... which was picked up and shipped in standard product. I had done some optimization and was using a one-byte length field. In the above referenced story, somebody had done a local change (MIT USL) to increase the max. TTY/ascii line length to something like 1200 bytes (I believe it was to support some sort of tty/ascii plotter device located at harvard) ... but hadn't change the code that was using one-byte values for length field.
the above story is notable in that it was one of the extremely rare buffer overflow related incidents over several decades ... in code that was purely assembler.
for other drift ... in adding the tty/ascii support to cp67 ... i had tried to be consistent with the existing cp67 terminal support that provided for automatic terminal identification ... i.e. that any terminal could be located on any line ... and the kernel would correctly identify and operate. this involved use of the 2702 terminal controller "SAD" command ... that allowed dynamic association of different line-scanners with each line/port. I thot it was pretty nifty and thot that it could even work with a common dial-up pool for all terminals. That was when the local IBM hardware engineer explained that they had taken short-cut in 2702 implementation and while it was possible to dynamicall associate the line-scanner ... they had hard-wired oscillators for line baud rate. 1052 and 2741 could share same dial-up pool (since while they were different line-scanners, they shared same baud rate).
this was large part of what motivated univ. to do the clone controller
project ... reverse engineering the mainframe channel interface,
building our own channel board for interdata/3. misc. past references
https://www.garlic.com/~lynn/submain.html#360pcm
and mentioned in recent post (about results of clones)
https://www.garlic.com/~lynn/2007l.html#10 Re: John W. Backus, 82, Fortran developer, dies
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: My Dream PC -- Chip-Based Newsgroups: alt.folklore.computers Date: Mon, 28 May 2007 08:59:34 -0600Greg Menke <gdmnews@toadmail.com> writes:
one of the issues is still the computational overhead of public/private key algorithms and the continued dependence on "secret" key algorithms.
one of the places this shows up is things like large transit systems and the encoding of transit passes. using a "secret" key algorihtm ... there has to be an infrastructure wide "secret" in use at all the transit gates and devices in the system. This creates an enormous systemic risk ... for even brute force attacks on the key. To mitigate that risk they typically will use a system-wide "secret" key with a "one-way" algorithm to produce an account/card/ticket specific key for the encryption of actual data. The system "secret" key is computational changed using some sort of account/card/ticket identification/serial number ... which is then used as actual key for encrypting data in each transit pass. Brute force on the transit pass ... only recovers the transit pass specific key ... but is nearly impossible to brute force the original system secret key.
There is still systemic risk involving the individual transit gates (attempts to extract the system-wide master "secret" key) ... but they tend to be heavily armored.
This is one of the reasons in the 90s ... we put out a call with
requirement for public/private key implementation that 1) could be done
by contactless/proximity chip (draws its power thru the air when near a
reader ... and therefor has power profile limitations) and 2) could be
used in transit applications (transit gate transaction requirements
typically have elapsed time requirement on the order of 100-200
mills). some old "AADS" references, including AADS chip strawman
https://www.garlic.com/~lynn/x959.html#aads
that was in conjunction about previous semi-facetious comment about also
being able to take a $500 mil-spec part and aggresively cost reduce it
by 2-3 orders of magnitude while increasing its security.
https://www.garlic.com/~lynn/2007l.html#8 Re: John W. Backus, 82, Fortran developer, dies
aka ... AADS chip strawman was to 1) super secure, 2) dirt cheap, 3) contactless, 4) public/private key, 5) meet transmit elapsed time requirements
one of the alternative chip public/private approaches in the 90s was to implement 1100-bit math operations ... in attempt to drastically reduce the elasped time for prevailing public/private key operations. However, this typically resulted in drastically increasing the power draw (not practical in proximity chip operation). also because of the significant computational intensity for the prevailing public/private key operations ... the private key was vulnerable to things like differential power attacks. part of AADS chip strawman was to get away from all that.
for other topic drift ... the circuits for the 1100-bit operations tended to significantly increase chip size (in addition to significantly increasing power draw) ... which cut the number of chips per wafer ... increasing the per chip cost.
part of the AADS chip strawman aggresive cost reduction was KISS ... and cutting chip size where ever possible (w/o sacrificing integrity/security). Chip manufacturing is somewhat fixed cost per wafer ... the more chips you get per wafer ... the lower the per chip cost (this is also behind things like the move from 8in to 12in wafers).
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: My Dream PC -- Chip-Based Newsgroups: alt.folklore.computers Date: Mon, 28 May 2007 09:12:13 -0600Anne & Lynn Wheeler <lynn@garlic.com> writes:
minor footnote ... one of the problems we were starting to get into with AADS chip strawman was that conventional slicing and dicing a wafer was starting to take over half the wafer area ... this is also something that the "RFID" chips (i.e. super small/cheap chips with target market as inventory control and next generation UPC ... i.e. bar-code replacement) have had to deal with.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Superconductors and computing Newsgroups: comp.arch,alt.folklore.computers Date: Mon, 28 May 2007 10:14:06 -0600jgd@cix.co.uk (John Dallman) writes:
Date: 10/05/81 14:11:45
To: wheeler
Hi Lynn !
I don't know if you remember me. You helped me find a place to live
this summer at Yorktown which worked out very well. Well, after that
example of successful networking I thought I would give it another try
I've just got back from my stint at Yorktown and am trying to get back
into the swing of things here. After spending all summer playing with
Josephson junction devices, and seeing the state of that project, I've
decided that software is where it's at for me ! I will be finishing off
my Masters in EE/CS at Stanford shortly, and am continuing towards the
Phd. I'm very interested in combining a work project and a dissertation
topic. Topics within A.I., graphics, networking, interactive education,
distributed processing are all very interesting to me. What I really
need is a supportive environment for learning, and hopefully producing
truly creative software products. My programming background so far
includes experience to varying degrees in: PLS, 370 assembler, VM
(REX,EXEC2,etc) APL, Pascal, and LISP.
Finally comes the question, Do you know of anyplace in IBM (preferably
Palo Alto, or San Jose Research) for someone like me ? Put the
question another way, Is creative software being produced, or
supported anywhere locally within IBM ? If so, who should I talk to ?
Thanks much !
... snip ... top of post, old email index
the way i remember it, one of the last things that eric did as head of east fishkill was shutdown josephson junction effort.
minor reference here
http://www-03.ibm.com/ibm/history/exhibits/builders/builders_bloch.html
and for other archeological drift: Contact Info for the Stretch
Reunion, Sept. 28-29, 2002
http://users.bestweb.net/~collier/sh/arch/contact.html
of course, eric shows up later as head of NSF for much of the '80s
... minor old email references here working with eric on NSFNET and
fighting/loosing internal battles
https://www.garlic.com/~lynn/lhwemail.html#nsfnet
i.e. some corporate members stepped in and started canceling our
outside meetings ... and then tried to get "SNA" substituted (for
tcp/ip) in nsfnet backbone ... example from (another) old email
https://www.garlic.com/~lynn/2006w.html#email870109
in this post
https://www.garlic.com/~lynn/2006w.html#21 SNA/VTAM for NSFNET
Eric writing letters copying ceo didn't even help (actually made the situation worse). We did get a letter from NSFNET audit of what we had already deployed (internally) that what we had running was at least five yrs ahead of all (NSFNET backbone) bid submissions to build something new ... aka while tcp/ip is the technology basis for the modern internet, NSFNET backbone was the operational basis for the modern internet.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Mon, 28 May 2007 12:19:12 -0600Charlton Wilbur <cwilbur@chromatico.net> writes:
a lot of the infrastructures have been built on serial batch (frequently cobol) processing. in the 80s, some of this started being front-end with online stuff for transaction origination ... but they typically continued to feed into (overnight) serial batch process to actually finalize/settle the operation.
in the 90s, one of the big (bottleneck) issues for these infrastructures became the overnight batch window ... globalization contributed to both increasing the amount of workload (that eventually had to be funneled thru the overnight batch window) and the decreasing size of the batch window (i.e. downtime when there was little or no other activity going on).
for several yrs an issue is how to leverage various kinds of parallelism to implement (real-time) straight-through processing. Foreys into this a decade ago found that they were running into scale-up problems ... aka they had "toy" demos of (real-time) straight-through processing ... but when they went to try real deployments, they were finding that the "parallelization" technologies were resulting in 100-fold overhead increase (compared to the legacy serial batch implementations) ... which adversely affected any deployment (to show actual capacity increase with straight-through processing methodologies ... you needed something like 200-300 times the computing processing that the overnight batch windows were currently using. The intial realization was real-time was much less efficient than serial batch ... so you needed a lot more resources, to get a lot more resources required moving to parallel ... however (at least standard COTS) parallelization technology also soaked up huge amounts of resources (resulting in the 100-fold increase). There were a whole litany of major straight through projects in the 90s that went down in flames over the issue.
this issue of parallelization is again coming to the forefront with all
the multi-core stuff ... as well as blade stuff. in the case
of the blade stuff ... it is sort of natural evolution of the ha/cmp
https://www.garlic.com/~lynn/subtopic.html#hacmp
scale-up work we had been doing
https://www.garlic.com/~lynn/lhwemail.html#medusa
the original cluster scale-up found big niche in the numerical intensive market segment. blades were somewhat motivated by physical packaging and getting more and more (commodity) computing into smaller and smaller footprint. some of the initial foreys into trying to move all that technology into more commercial sector has been things like trading houses using vast array of blades in support of (near) real-time trading analytics.
more recently some of the blade movement into commercial has been in combination with virtualization and server/application consolidation ... getting huge numbers of corporate servers into more manageable (and cost effective) configurations.
however, lurking in the background continues to be the issue about
(re)tackling the straight-through processing (and real-time settlement)
holy grails ... possibly with contribution of combining multi-core and
blades (i.e. combining both "tightly" coupled multiprocessing and
massive "loosely" coupled multiprocessing). although old posts
mentioning shared-memory/symmetric/tightly-coupled multiprocessing,
building smp kernels and/or compare&swap instruction
https://www.garlic.com/~lynn/subtopic.html#smp
however, one of the constant refrains over the post couple yrs (around the movements to multi-core) is needing a qualitative improvement (and/or paradigm change) in application parallelization technology.
misc. past posts mentioning various kinds of straight through
processing efforts:
https://www.garlic.com/~lynn/aadsm17.htm#12 A combined EMV and ID card
https://www.garlic.com/~lynn/aadsm19.htm#46 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm20.htm#20 ID "theft" -- so what?
https://www.garlic.com/~lynn/2001b.html#27 HELP
https://www.garlic.com/~lynn/2005l.html#12 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005l.html#13 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005l.html#14 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005l.html#17 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005l.html#21 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005l.html#37 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2006c.html#45 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006s.html#40 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2007b.html#26 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007e.html#10 A way to speed up level 1 caches
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Mon, 28 May 2007 12:43:02 -0600Charlton Wilbur <cwilbur@chromatico.net> writes:
for another perspective on the subject ... X9
http://www.x9.org/
is the US financial industry standards body (and chair of ISO international finanical standards).
X9 committees include both X9A, for retail financial business standards and X9F for security and cryptographic standards.
For quite awhile nist
http://www.nist.gov/
had been use to writing/developing federal cryptographic standards from scratch. sort of one of the x9f milestones was when nist changed its policy and directly cited X9F work for federal standards.
I've periodically mentioned work on X9.59 financial industry standard
https://www.garlic.com/~lynn/x959.html#x959
in the X9A10 working group. a couple somewhat related recent posts
https://www.garlic.com/~lynn/2007l.html#8 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#12 My Dream PC -- Chip-based
https://www.garlic.com/~lynn/2007l.html#12 My Dream PC -- Chip-based
now, most of X9.59 standardization activity involved a lot of cryptographic oriented work ... and previously the standard activity would have been done in one of the X9F (cryptographic) working groups. However, the decision to instead put the work in a X9A (retail business) working group was in part motivated by wanting to see the technology aligned with the business processes. Previously, it had been possible for X9F to preduce a technology standards that might have little or no alignment with financial industry business processes.
One slightly related hot button was when we kept pointing out that
X9.59 transactions would be secured with digital signatures ... w/o
requiring any digital certificates ... some certificate-less related
posts
https://www.garlic.com/~lynn/subpubkey.html#certless
and mentioning that some of the payment transaction specifications
being done elsewhere involving appending digital certificates
represented was causing a factor of 100 times increase in the size of
a typical payment transactions ... misc. past posts mentioning the
enormous bloat that (obsolete, redundant and superfluous) digital
certificates would cause in payload size (as well in computational
requirements for payload processing)
https://www.garlic.com/~lynn/subpubkey.html#bloat
this possibly contributed to new work item in X9F for standards work on "compressed" digital certificates ... potentially getting the enormous payload bloat down from 100 times to possibly only 5-10 times (appending obsolete, useless, redundant and superfluous digital certificate)
one of the compression techniques being looked at was eliminating all digital certificate fields that were common/identical across all of the institutions digital certificates. I took it a step further ... and pointed out that all fields that were already in the possession of the institution (and would be normally accessed in an account record as part of standard processing) could also be eliminated from digital certificates ... allowing the digital certificates to be compressed to zero bytes (i.e. it was trivial to show that all fields that might be in a digital certificate were already in the possession of the institutions). This approach was an alternative to having certificate-less digital signature operations ... instead, zero byte digital certificates could be mandated for every transaction.
for other drift ... some other recent posts mentioning digital certificates
https://www.garlic.com/~lynn/2007i.html#5 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#28 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#51 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#63 public key password authentication
https://www.garlic.com/~lynn/2007i.html#73 public key password authentication
https://www.garlic.com/~lynn/2007j.html#67 open source voting
https://www.garlic.com/~lynn/2007k.html#32 SSL Security
https://www.garlic.com/~lynn/2007k.html#55 My Dream PC -- Chip-Based
https://www.garlic.com/~lynn/2007k.html#79 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#0 Re: John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#2 Re: John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#6 Re: John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#9 Re: John W. Backus, 82, Fortran developer, dies
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Linux: The Completely Fair Scheduler Newsgroups: alt.folklore.computers Date: Mon, 28 May 2007 19:34:02 -0600Walter Bushell <proto@oanix.com> writes:
was in the mainframe channel board attachment to 360/67 channel ...
recent reference
https://www.garlic.com/~lynn/2007l.html#10 John W. Backus, 82, Fortran developer, dies
one of the first "bugs" was 360/67 "red lighted" (i.e. machine check
and stopped). the problem was that 360/67 had high-speed interval
timer ... which required updating location 80 in main memory on every
timer tic. the timer would attempt to obtain the memory bus to update
location 80 ... and if the timer "tic'ed" again while there was
already a pending update ... the machine would "red light" and
stop. the problem was that our clone channel adatper board wasn't
releasing the interface frequently enuf (in order to allow the timer
to update location 80). misc. past posts mentioning early hardware
bug in clone controller project:
https://www.garlic.com/~lynn/2003.html#25 vax6k.openecs.org rebirth
https://www.garlic.com/~lynn/2005o.html#36 Penn Central RR computer system failure?
https://www.garlic.com/~lynn/2006c.html#21 Military Time?
https://www.garlic.com/~lynn/2006g.html#18 TOD Clock the same as the BIOS clock in PCs?
standard location 80 timer was 32bits ... lower-end 360s would tic the 8th bit every 1/300th second. high speed timer option would tic 256 times more frequently (about 13microseconds).
other (unrelated) posts in this thread
https://www.garlic.com/~lynn/2007h.html#77 Linux: The Completely Fair Scheduler
https://www.garlic.com/~lynn/2007i.html#1 Linux: The Completely Fair Scheduler
https://www.garlic.com/~lynn/2007i.html#2 Linux: The Completely Fair Scheduler
https://www.garlic.com/~lynn/2007i.html#46 Linux: The Completely Fair Scheduler
https://www.garlic.com/~lynn/2007j.html#76 Linux: The Completely Fair Scheduler
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Non-Standard Mainframe Language? Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Mon, 28 May 2007 20:34:30 -0600gilmap@ibm-main.lst (Paul Gilmartin) writes:
x-over post on the subject from today in another fora
https://www.garlic.com/~lynn/2007l.html#11 John W. Backus, 82, Fortran developer, dies
lots of posts on the subject of exploits/failures related to the
characteristic
https://www.garlic.com/~lynn/subintegrity.html#overflow
i had been monitoring some of the statistics thru the 90s ... but more recently there were much fewer ... so i had to do some analysis myself ... looking at some of the exploit databases. part of the problem (that I complained about) was that many of the descriptions were somewhat freeform and could be ambiguous ... which i complained about a number of times. there were some more recent announcements that they would be attempting to better classify/categorize exploits.
old posts with some attempts at classification/categorization based
on analysis of some of the exploit databases
https://www.garlic.com/~lynn/2004e.html#43 security taxonomy and CVE
https://www.garlic.com/~lynn/2004j.html#58 Vintage computers are better than modern crap !
https://www.garlic.com/~lynn/2005b.html#43 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005c.html#32 [Lit.] Buffer overruns
and this one mentions an article in early 2005 quoting a NIST
study that came up with similar statistics that I had come up
with nearly a year earlier:
https://www.garlic.com/~lynn/2005b.html#20 [Lit.] Buffer overruns
note part of the mentioned efforts was in support of my merged
security taxonomy and glossary ... some notes here:
https://www.garlic.com/~lynn/index.html#glosnote
past posts in this thread:
https://www.garlic.com/~lynn/2007k.html#65 Non-Standard Mainframe Language?
https://www.garlic.com/~lynn/2007k.html#67 Non-Standard Mainframe Language?
https://www.garlic.com/~lynn/2007k.html#73 Non-Standard Mainframe Language?
https://www.garlic.com/~lynn/2007k.html#74 Non-Standard Mainframe Language?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Tue, 29 May 2007 00:16:52 -0600Anne & Lynn Wheeler <lynn@garlic.com> writes:
recent item along these lines:
Is Parallel Programming Just Too Hard?
http://developers.slashdot.org/developers/07/05/29/0058246.shtml
Intel: Software needs to heed Moore's Law
http://news.com.com/Intel+Software+needs+to+heed++Moores+Law/2100-1012_3-6186765.html
recent posts mentioning the multi-core & parallel programming paradigm issue:
https://www.garlic.com/~lynn/2007.html#3 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2007g.html#3 University rank of Computer Architecture
https://www.garlic.com/~lynn/2007i.html#20 Does anyone know of a documented case of VM being penetrated by hackers?
https://www.garlic.com/~lynn/2007i.html#78 John W. Backus, 82, Fortran developer, dies
and lots of past posts mentioning cluster/loosely-coupled (parallel)
support
https://www.garlic.com/~lynn/subtopic.html#hacmp
and somewhat related posts about distributed lock manager work in support
of the above:
https://www.garlic.com/~lynn/2007i.html#50 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#61 John W. Backus, 82, Fortran developer, dies
misc. posts mentioning my wife got con'ed to doing stint in POK
in charge of loosed-coupled multiprocessor architecture
https://www.garlic.com/~lynn/submain.html#shareddata
some old email related to cluster scale-up work
https://www.garlic.com/~lynn/lhwemail.html#medusa
misc. pasts mentioning (parallel) tightly-coupled multiprocessor
work
https://www.garlic.com/~lynn/subtopic.html#smp
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Tue, 29 May 2007 08:52:17 -0600Anne & Lynn Wheeler <lynn@garlic.com> writes:
some cross-over from this "cobol" thread
https://www.garlic.com/~lynn/2007k.html#66 The top 10 dead (or dying) computer skills
https://www.garlic.com/~lynn/2007k.html#69 The top 10 dead (or dying) computer skills
there was follow-up mention of "cobol":
You can't kill a skill; How even a Cobol expert can find career gold
http://www.itbusiness.ca/it/client/en/home/News.asp?id=43656
and for even more drift ... a recent reference to doing some performance
tuning on one such large cobol (450k lines) application that ran on over
40 mainframe "CECs" (that were something in excess of $30m/per) ... and
was able to get something like 15percent improvement:
https://www.garlic.com/~lynn/2007f.html#47 Is computer history taught now?
https://www.garlic.com/~lynn/2007f.html#48 Is computer history taught now?
https://www.garlic.com/~lynn/2007f.html#51 Is computer history taught now?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Non-Standard Mainframe Language? Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Tue, 29 May 2007 11:00:07 -0600Dan Espen <daneNO@MORE.mk.SPAMtelcordia.com> writes:
when i was undergraduate, i had added tty/ascii terminal support to cp67
... in the process of doing that ... came up with some difficiencies in
the 2702 terminal controller ... that somewhat prompted project to build
our own clone controller out of interdata/3 ... which had somewhat
360-like instruction set. recent post making reference:
https://www.garlic.com/~lynn/2007l.html#11 John W. Backus, 82, Fortran developer, dies
there was some article blaming us (at least in part) for the clone
controller business. lots of past posts mentioning clone controllers
https://www.garlic.com/~lynn/submain.html#360pcm
all the references I've seen regarding redoing C & UNIX for portability make mention of (later) interdata machines (again 360-like)
The First Unix Port
http://www.usenix.org/publications/library/proceedings/usenix98/invited_talks/miller.ps
Version 6 Unix - Wikipedia, the free encyclopedia
https://en.wikipedia.org/wiki/Version_6_Unix
Interdata_v6
http://minnie.tuhs.org/UnixTree/Interdata_v6/
Anecdotes
http://doi.ieeecomputersociety.org/10.1109/MAHC.1989.10025
The Daemon, the GNU and the Penguin - Chapter 2 and 3
http://www.icims.csl.uiuc.edu/~lheal/doc/dgp/chapter02_03.html
of course these machines were quite a bit after interdata/3
Interdata 7/32 and 8/32
https://en.wikipedia.org/wiki/Interdata_7/32
in the above ... references to perkin-elmer having bought interdata and quite a bit of success in "defense and aerospace" industries. people i've talked to since, have said that a lot of the sales involved attaching to ibm mainframe ... and the channel attach board didn't appear to have been redesigned since our original (still wire-wrap).
Interdata Simulator Configuration
http://simh.trailing-edge.com/interdata.html
from above:
Interdata was founded in the mid 1960's. It produced a family of 16b
minicomputers loosely modeled on the IBM 360 architecture.
Microprogramming allowed a steady increase in the functionality of
successive models.
* Interdata 3
• Interdata 4 (autoload, floating point)
* Interdata 5 (list processing, microcoded automatic I/O channel)
• Interdata 70, 74, 80
• Interdata 6/16, 7/16
• Interdata 8/16, 8/16e (double precision floating point, extended memory)
In the early 1970's, Interdata was purchased by Perkin-Elmer. In 1974,
it introduced one of the first 32b minicomputers, the 7/32. Several
generations of 32b systems followed:
• Interdata 7/32
* Interdata 8/32
• Perkin-Elmer 3205, 3210, 3220
* Perkin-Elmer 3250
Interdata was spun out of Perkin-Elmer as Concurrent Computer
Corporation.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: U.S. Cedes Top Spot in Global IT Competitiveness Newsgroups: alt.folklore.computers Date: Wed, 30 May 2007 08:38:12 -0600new item in ongoing thread:
Asia leads in IT innovation
http://www.zdnetindia.com/zdnetnew2007/index.php?action=article&prodid=6725
from above:
Entitled "IT Investments, performance and priorities in Southeast Asia's
major economies", the survey polled 48 CIOs and CTOs from Malaysia (33
percent of respondents), Singapore (37 percent) and Indonesia (30
percent). The study is part of Accenture's global high-performance IT
research covering 500 CIOs from the world's largest and public sector
organizations in 22 countries.
... snip ...
recent posts in thread::
https://www.garlic.com/~lynn/2007g.html#6 U.S. Cedes Top Spot in Global IT Competitiveness
https://www.garlic.com/~lynn/2007g.html#7 U.S. Cedes Top Spot in Global IT Competitiveness
https://www.garlic.com/~lynn/2007g.html#34 U.S. Cedes Top Spot in Global IT Competitiveness
https://www.garlic.com/~lynn/2007g.html#35 U.S. Cedes Top Spot in Global IT Competitiveness
https://www.garlic.com/~lynn/2007g.html#52 U.S. Cedes Top Spot in Global IT Competitiveness
https://www.garlic.com/~lynn/2007g.html#68 U.S. Cedes Top Spot in Global IT Competitiveness
https://www.garlic.com/~lynn/2007i.html#13 U.S. Cedes Top Spot in Global IT Competitiveness
recent posts in related threads:
https://www.garlic.com/~lynn/2007h.html#42 Experts: Education key to U.S. competitiveness
https://www.garlic.com/~lynn/2007i.html#24 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#79 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007j.html#31 IBM Unionization
https://www.garlic.com/~lynn/2007j.html#51 IBM Unionization
https://www.garlic.com/~lynn/2007j.html#80 IBM Unionization
https://www.garlic.com/~lynn/2007j.html#85 IBM Unionization
https://www.garlic.com/~lynn/2007k.html#10 IBM Unionization
https://www.garlic.com/~lynn/2007k.html#30 IBM Unionization
https://www.garlic.com/~lynn/2007k.html#34 IBM Unionization
https://www.garlic.com/~lynn/2007k.html#42 IBM Unionization
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Wed, 30 May 2007 08:46:43 -0600Anne & Lynn Wheeler <lynn@garlic.com> writes:
Getting much, much more per x86 rack
http://weblog.infoworld.com/yager/archives/2007/05/getting_much_mu.html
from above:
We squeeze 40 servers into a full-height rack. For isolation and
fine-grained load balancing of a .Net e-commerce solution, we want to
split our rack into as many Windows Server virtual machines as
possible. Our response time tests led us to allocate three virtual
servers per rack unit, yielding 120 VMs per rack.
... snip ...
note that medusa (from 91) ... was squeezing 32 "servers" into
full-height rack (todays blades are able to get even higher
density)
https://www.garlic.com/~lynn/lhwemail.html#medusa
of course, virtual machines is the latest, new 40+yr old technology.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Is Parallel Programming Just Too Hard? Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Wed, 30 May 2007 09:40:55 -0600howard@ibm-main.lst (Howard Brazee) writes:
there has been lots of stuff in multiprogramming and multithreading in the same processor complex (single processor and/or shared-memory multiprocessor).
multiprogramming was managing lots of independent & different tasks on the same processor complex.
multithreading was program managing different tasks.
application implementation of multithreading isn't necessarily very pervasive. some number of DBMS implementation have used things like transaction model ... to provide "independent" operations ... that they multithread. In this sense, DBMS kernels are somewhat more like operating system kernels ... highly specialized ... and not a lot of end-users implementing their own DBMS kernels.
in a lot of multiprocessor kernel support ... a "global" kernel lock was used ... which only allowed a single thread to be executing in the kernel at a time. it was somewhat painful experience for a lot of kernel implementations to make the transition from single thread (at a time) executing in a multiprocessor kernel to multiple concurrent threads executing in same parts of the kernel.
long ago and far away, this was one of the battles getting the compare&swap instruction into 370 architecture. test&set had been around in the 60s and was used fro 360/65 multiprocessor support with global kernel spin-locks (set the lock and everybody else spins, untill the lock is cleared).
at the science center
https://www.garlic.com/~lynn/subtopic.html#545tech
Charlie had been doing a lot of work in fine-grain lock for the cp67
kernel and invented the compare&swap instruction (mnemonic chosen
because "CAS" are charlie's initials). misc. past posts mentioning
SMPs and/or compare&swap
https://www.garlic.com/~lynn/subtopic.html#smp
somewhat implicit in a lot of compare&swap uses is that there can be concurrent threads executing in the same instruction sequences simultaneously. the inital forey into POK attempting to get compare&swap justified was unsuccessful, in large part because the favorite son operating system felt that test&set was just fine for multiprocessor support (the 360/65 smp global spin lock paradigm). the challenge was to create justification for compare&swap instruction that was applicable to single processor deployment. Thus was born the programming notes that can be found in principles of operation describing how the "atomic" characteristics of comapre&swap can be leveraged in single processor environment for multithreaded applications (like DBMS) ... these aren't necessarily concurrent multithreads ... but multiple threads that might be interrupted and so atomic operations can be applied to both simultaneous concurrent multithread operation as well as possibly non-simultaneous (but interrruptable) multithreaded operation.
the advances in concurrent, parallel technology into loosely-coupled/cluster deployments is even more limited than the proliferation in tightly-coupled environments.
we had done a scallable distributed lock manager in support of
our ha/cmp product
https://www.garlic.com/~lynn/subtopic.html#hacmp
and the "medusa" cluster-in-a-rack activity ... old email
https://www.garlic.com/~lynn/lhwemail.html#medusa
and somewhat referenced in these postings about old meeting
https://www.garlic.com/~lynn/95.html#13
https://www.garlic.com/~lynn/96.html#15
... but again ... it tended to be directly used by a very limited amount of specailized code ... there wasn't a huge number of different applications directly implementing semantics of highly parallel operation (for either tightly-coupled or loosely-coupled configurations).
a couple recent posts in another thread/fora on the subject
https://www.garlic.com/~lynn/2007l.html#15 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#19 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#23 John W. Backus, 82, Fortran developer, dies
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Computer tube production years Newsgroups: alt.folklore.computers Date: Wed, 30 May 2007 10:29:36 -0600hancock4 writes:
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Is Parallel Programming Just Too Hard? Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Wed, 30 May 2007 10:41:16 -0600Anne & Lynn Wheeler <lynn@garlic.com> writes:
misc. past posts mentioning smp and/or compare&swap instruction
https://www.garlic.com/~lynn/subtopic.html#smp
in the mid-70s i was working on a 5-way SMP implementation it involved
one of the lower-end 370 processor designs ... and was moving lots of
features into microcode. for one reason or another that project got
killed, misc. past posts discussing the effort
https://www.garlic.com/~lynn/submain.html#bounce
shortly after that got killed, there was another project started for 16-way smp involving higher-end processors. we even co-opted the spare time from some of the processor engineers furiously attempting to complete the 3033. in general, most people that looked at it thought it was a really great idea ... until it came to the attention of the head of POK that it would possible be decades before the POK favorite son operating system would be able to support the machine. At which time, the 3033 engineers were instructed to get their noses back to the grindstone and some people were invited to never show up in POK again.
misc. past references:
https://www.garlic.com/~lynn/95.html#5 Who started RISC? (was: 64 bit Linux?)
https://www.garlic.com/~lynn/95.html#6 801
https://www.garlic.com/~lynn/95.html#11 801 & power/pc
https://www.garlic.com/~lynn/98.html#40 Comparison Cluster vs SMP?
https://www.garlic.com/~lynn/2000.html#86 Ux's good points.
https://www.garlic.com/~lynn/2001e.html#5 SIMTICS
https://www.garlic.com/~lynn/2001h.html#33 D
https://www.garlic.com/~lynn/2002i.html#82 HONE
https://www.garlic.com/~lynn/2003.html#4 vax6k.openecs.org rebirth
https://www.garlic.com/~lynn/2003.html#5 vax6k.openecs.org rebirth
https://www.garlic.com/~lynn/2004f.html#21 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004f.html#26 command line switches [Re: [REALLY OT!] Overuse of symbolic
https://www.garlic.com/~lynn/2004j.html#45 A quote from Crypto-Gram
https://www.garlic.com/~lynn/2004m.html#53 4GHz is the glass ceiling?
https://www.garlic.com/~lynn/2005k.html#45 Performance and Capacity Planning
https://www.garlic.com/~lynn/2005m.html#48 Code density and performance?
https://www.garlic.com/~lynn/2005p.html#39 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2006c.html#40 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006l.html#30 One or two CPUs - the pros & cons
https://www.garlic.com/~lynn/2006n.html#37 History: How did Forth get its stacks?
https://www.garlic.com/~lynn/2006r.html#22 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006t.html#7 32 or even 64 registers for x86-64?
https://www.garlic.com/~lynn/2006t.html#9 32 or even 64 registers for x86-64?
https://www.garlic.com/~lynn/2007g.html#17 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007g.html#44 1960s: IBM mgmt mistrust of SLT for ICs?
https://www.garlic.com/~lynn/2007g.html#57 IBM to the PCM market(the sky is falling!!!the sky is falling!!)
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Wed, 30 May 2007 12:52:07 -0600kkt <kkt@zipcon.net> writes:
in the 90s we spent some time talking to the national library of medicine ... which had online catalog providing world-wide access. The two original developers were still there and were still running BDAM implementation that they had first done about the same time I was doing stuff for the university library.
misc. past posts mentioning NLM (for one reason or another):
https://www.garlic.com/~lynn/94.html#26 Misc. more on bidirectional links
https://www.garlic.com/~lynn/2001c.html#67 What ever happened to WAIS?
https://www.garlic.com/~lynn/2001i.html#27 History of Microsoft Word (and wordprocessing in general)
https://www.garlic.com/~lynn/2001j.html#1 Off-topic everywhere [was: Re: thee and thou
https://www.garlic.com/~lynn/2001m.html#51 Author seeks help - net in 1981
https://www.garlic.com/~lynn/2002g.html#3 Why are Mainframe Computers really still in use at all?
https://www.garlic.com/~lynn/2002h.html#0 Search for Joseph A. Fisher VLSI Publication (1981)
https://www.garlic.com/~lynn/2002l.html#53 10 choices that were critical to the Net's success
https://www.garlic.com/~lynn/2002l.html#68 10 choices that were critical to the Net's success
https://www.garlic.com/~lynn/2002o.html#45 XML, AI, Cyc, psych, and literature
https://www.garlic.com/~lynn/2002o.html#50 XML, AI, Cyc, psych, and literature
https://www.garlic.com/~lynn/2004e.html#53 c.d.theory glossary (repost)
https://www.garlic.com/~lynn/2004f.html#0 c.d.theory glossary (repost)
https://www.garlic.com/~lynn/2004f.html#1 c.d.theory glossary (repost)
https://www.garlic.com/~lynn/2004l.html#52 Specifying all biz rules in relational data
https://www.garlic.com/~lynn/2004m.html#61 RISCs too close to hardware?
https://www.garlic.com/~lynn/2004n.html#47 Shipwrecks
https://www.garlic.com/~lynn/2004o.html#67 Relational vs network vs hierarchic databases
https://www.garlic.com/~lynn/2004p.html#0 Relational vs network vs hierarchic databases
https://www.garlic.com/~lynn/2005.html#23 Network databases
https://www.garlic.com/~lynn/2005c.html#41 Oldest active information system
https://www.garlic.com/~lynn/2005d.html#57 Thou shalt have no other gods before the ANSI C standard
https://www.garlic.com/~lynn/2005j.html#45 Where should the type information be?
https://www.garlic.com/~lynn/2005j.html#47 Where should the type information be?
https://www.garlic.com/~lynn/2006e.html#34 CJ Date on Missing Information
https://www.garlic.com/~lynn/2006l.html#31 Google Architecture
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Wed, 30 May 2007 13:16:09 -0600"Charlie Gibbs" <cgibbs@kltpzyxm.invalid> writes:
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Wed, 30 May 2007 14:27:27 -0600Anne & Lynn Wheeler <lynn@garlic.com> writes:
or "fold, spindle or mutilate" ... quick use of search engine
http://www.lileks.com/institute/compupromo/4.html
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: tab browsing Newsgroups: alt.folklore.computers Date: Wed, 30 May 2007 16:18:55 -0600i frequently do a lot of tab browsing ... not uncommon to have 50-150 tabs open ... recent test with firefox 3, I opened over 900 tabs (at one time). i also do some stuff bookmarking collections of tabs in tab folder ... and then copying them out of bookmark file into other places. firefox 3 just recently moved their bookmark file to sqlite ... which presented a little of a issue
however, with little help with shell and command line sqlite processor ... the following sql statement gets me all the bookmark URLs from the most recent tab folder (all in one line):
select moz_bookmarks.title,url from moz_bookmarks join moz_places on moz_bookmarks.fk = moz_places.id where moz_bookmarks.parent = (select max(id) from moz_bookmarks where parent = 2);
i.e. "parent = 2" is bookmark folder (from bookmark table) ... and max(id) gets the most recent one, then all the bookmarks that have that folder as parent ... joined with the foreign key to the places (URL) table.
misc. past posts about original relational/sql implementation
https://www.garlic.com/~lynn/submain.html#systemr
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Wed, 30 May 2007 16:21:15 -0600Lawrence Statton <yankeeinexile@gmail.com> writes:
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Virtual private networks Newsgroups: comp.protocols.tcp-ip Date: Wed, 30 May 2007 17:14:09 -0600kaja_love160 writes:
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Thu, 31 May 2007 06:32:04 -0600jmfbahciv writes:
semi-related item from today:
Security analogies: the key to educating laymen
http://www.theregister.com/2007/05/31/security_analogies/
and for other drift ... the "naked" payment/transaction analogy
https://www.garlic.com/~lynn/subintegrity.html#payment
and couple past posts mentioning the "after-market" security analogy
https://www.garlic.com/~lynn/2002h.html#39 Oh, here's an interesting paper
https://www.garlic.com/~lynn/2007b.html#10 Special characters in passwords was Re: RACF - Password rules
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Is Parallel Programming Just Too Hard? Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Thu, 31 May 2007 08:26:47 -0600Quadibloc <jsavard@ecn.ab.ca> writes:
some amount of parallelism has to do with degree/frequency of synchroniziation & serialization ... this can somewhat seen in loosely-couple/cluster configurations ... the degree of synchronization frequently involves the bandwidth of the communication mechanism, the latency of the communication mechanism and the overhead of the communciation (high-overhead & high-latency would contribute to strategies involving less frequent synchronization).
out-of-order execution tends to have to do with (relative) high cache-miss memory latency (stalling current instruction) ... but along with relatively large cache resulting in decent probability that subsequent instructions might not have cache miss.
problem is that current serial programming paradigm has relatively high instruction-to-instruction synchronization. hardware supporting out-of-order execution somewhat is attempting to dynamically discover places where there might not be instruction-to-instruction synchronization. this is somewhat chip design being forced into attempting to compensate for the serial programming paradigm.
i've mentioned before one of the early efforts (that wasn't released) for multi-threading was 370/195 project in the 70s to add 2nd thread to the machine. peak thruput was around 10mips ... but most codes ran around 5mips because of branches stalling pipeline operation. Idea was that adding a second thread (simulating multiprocessor operation) had chance of keeping processor resources operating at 100% utilization (for minimal extra hardware) ... providing some additional "decoupled" instruction-to-instruction serialization.
holy grail changing the software paradigm is to achieve potentially orders of magnitude more parallelism ... leading to higher aggregate thruput (and/or being able to have results in much shorter elapsed time) ... both "tightly-coupled" single chip operation as well as large numbers of "loosely-coupled" chips (some of the uptake of large GRID configurations is now by trading houses attempting to do calculations for nearly "real-time" trades).
By comparison some of the current chip design approach is attempting to devote more and more hardware resources to (dynamically) discover smaller and smaller incremental thruput in strictly serial execution.
most past posts mentioning 70s project for multi-threaded,
dual-istream 370/195:
https://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ???
https://www.garlic.com/~lynn/2002p.html#58 AMP vs SMP
https://www.garlic.com/~lynn/2003f.html#33 PDP10 and RISC
https://www.garlic.com/~lynn/2003j.html#41 Of what use 64-bit "General Purpose" registers?
https://www.garlic.com/~lynn/2003p.html#3 Hyperthreading vs. SMP
https://www.garlic.com/~lynn/2004o.html#18 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2006c.html#29 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006d.html#10 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006r.html#2 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006t.html#41 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2007.html#36 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007i.html#45 IBM System/360 Model 85: The Bashful Computer
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: My Dream PC -- Chip-Based Newsgroups: alt.folklore.computers Date: Fri, 01 Jun 2007 11:26:25 -0600Greg Menke <gdmnews@toadmail.com> writes:
part of the key issue in x9.59 financial standard
https://www.garlic.com/~lynn/x959.html#x959
& aads
https://www.garlic.com/~lynn/x959.html#aads
... is that the transaction is armored with digital signature ... which
changes on every transaction. that eliminates evesdropping attacks
(harvesting, skimming, data breaches, security breaches, etc) involving
previous transactions for replay attacks. it also eliminates having to
actually encryption of the transaction to hide its contents ... since
the contents of previous transactions are no longer useful in (replay
attacks) in future fraudulent transactions.
https://www.garlic.com/~lynn/subintegrity.html#harvest
the current infrastructure with "cards" ... is a something you have
operation ... from 3-factor authentication
https://www.garlic.com/~lynn/subintegrity.html#3factor
• something you have
• something you know
• something you are
however, the "proof" of the something you have is the contents of the
magstripe on the card ... which is "static" data ... which can be
skimmed/harvested (obtained from previous transactions) and relatively
trivially used to generate counterfeit cards.
even some of the card "chip-based" infrastructures have also relied on
"static data" verification ... which is also vulnerable to
skimming/harvesting exploits and the creation of counterfeit cards
... some specific discussions
https://www.garlic.com/~lynn/subintegrity.html#yescard
digital signatures is dynamic data that uses public/private key
technology. the private key is kept confidential and never divulged.
the public key is openly registered ... and is used to verify the
digital signature. the public key can't be used for originating a
digital signature. some recent posts
https://www.garlic.com/~lynn/2007b.html#12 Special characters in passwords was Re: RACF - Password rules
https://www.garlic.com/~lynn/2007b.html#13 special characters in passwords
https://www.garlic.com/~lynn/2007d.html#12 One Time Identification, a request for comments/testing
https://www.garlic.com/~lynn/2007l.html#8 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#9 John W. Backus, 82, Fortran developer, dies
it is not usefual in (secret key) impersonation attacks (like passwords
and pins) ... where the same value is used for both originating
an authentication and verifying an authentication (and therefor
the verifying value is vulnerable to attacks/insiders using it
for impersonation)
https://www.garlic.com/~lynn/subintegrity.html#secrets
the "private key" is actually known (like in the case of pins/passwords for something you know) ... but is kept encapsulated in some device that actually performs the digital signature (and therefor becomes something you have authentication). however, it is vulnerable to divulging and counterfeiting (analogous to current card magstripe).
the issue then becomes the degree of armoring provided by the device
that holds the "private key". in the 90s the claim was the really
expensive chips that provided such armoring and countermeasures for
divulging (the private key) were way to expensive for common use. that
was one of our semi-facetious comments about taking a $500 mil-spec
piece and aggresively cost reducing it by 2-3 orders of magnitude while
not sacrificing any of the armoring and countermeasure technologies
... aka the aads chip strawman
https://www.garlic.com/~lynn/x959.html#aads
the exploits then shifts away from data breaches (mostly someplace in
the merchant infrastructures, not only from external attackers but also
long term stats are that "insiders" are typically involved in approx.
70percent of the incidents) ... being able to harvest details on
40million accounts out of previous electronic transactions ... account
having to physically steal each (account) token. this is somewhat
the old post on security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61
Such a shift drives up the per account fraud cost to the attacker enormously. The other issue is that lost/stolen "reports" have been an effective countermeasure to limiting the amount of fraud. In the skimming/harvesting (and data breach) scenarios, awareness that something has been stolen is signficiantly delayed (until after fraud is starting to happen). Shifting the thefts back to physical objects ... there is much higher probability that the theft will be noticed and reported before significant amounts of fraud has occurred.
if an aads digital signature token is augmented with some sort of PIN that additional drives down the fraud exposure. normally multi-factor authentication is considered more secure when the different factors have different vulnerabilities ... i.e. PINs (something you know) have been considered countermeasure to "lost/stolen" card/tokens (something you have). However, that assumption may be invalidated in some of the skimming/harvesting attacks ... where the "static" magstripe data (as evidence of something you have) and the "static" PIN data can be skimmed/harvested in a common operation. With the x9.59/AADS scenario, a PIN operation is vulnerable to skimming ... but the ("unique") token isn't. The token is still vulnerable to physical theft ... but the countermeasures can be both a something you know PIN (and/or a something you are biometric) as well as lost/stolen reports (you become aware that you no longer have a physical object, as opposed to some piece of information related to you has been stolen/compromised; which is significantly harder to discover and rectify).
part of the current infrastructure is that US financial infrastructures
are reported to make nearly 40percent of their bottom line off payment
operations. part of this is the "interchange fees" (charged merchants)
which can be considered (at least partially) a type of fraud insurance
(spread across all the merchants) ... since so much of the current fraud
can arise from exploits in the merchant infrastructure. x9.59/aads
eliminates many of those vulnerabilities (which potentially might be
used as an excuse for drastically reducing "interchange fees"). recent
posts mentioning interchange fees:
https://www.garlic.com/~lynn/2007.html#27 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#38 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007h.html#56 T.J. Maxx data theft worse than first reported
https://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#47 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#59 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#72 Free Checking
Part of this dates back to the mid-90s when the x9a10 financial standard
working group was given the requirement to preserve the integrity of the
financial infrastructure for all retail payments. This, in turn, led to
detailed end-to-end theat, vulnerabiilty and exploit analysis ... and
attempting to formulate cost-effective countermeasures for those
threats, vulnerability, and exploits ... and was behind of much of
the motivation in the x9.59 financial standard
https://www.garlic.com/~lynn/x959.html#x959
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Questions to the list Newsgroups: bit.listserv.ibm-main To: <ibm-main@bama.ua.edu> Date: Fri, 01 Jun 2007 11:34:57 -0600Tom.Schmidt@ibm-main.lst (Tom Schmidt) writes:
there is some balance between answering questions where the askee has actually made some attempt to learn something ... or is using the list in lieu of having to learn anything.
misc. past posts mentioning homework issue:
https://www.garlic.com/~lynn/2000.html#28 Homework: Negative side of MVS?
https://www.garlic.com/~lynn/2000.html#32 Homework: Negative side of MVS?
https://www.garlic.com/~lynn/2001.html#70 what is interrupt mask register?
https://www.garlic.com/~lynn/2001b.html#38 Why SMP at all anymore?
https://www.garlic.com/~lynn/2001c.html#11 Memory management - Page replacement
https://www.garlic.com/~lynn/2001c.html#25 Use of ICM
https://www.garlic.com/~lynn/2001k.html#75 Disappointed
https://www.garlic.com/~lynn/2001l.html#0 Disappointed
https://www.garlic.com/~lynn/2001m.html#0 7.2 Install "upgrade to ext3" LOSES DATA
https://www.garlic.com/~lynn/2001m.html#32 Number of combinations in five digit lock? (or: Help, my brain hurts)
https://www.garlic.com/~lynn/2002c.html#2 Need article on Cache schemes
https://www.garlic.com/~lynn/2002f.html#32 Biometric Encryption: the solution for network intruders?
https://www.garlic.com/~lynn/2002f.html#40 e-commerce future
https://www.garlic.com/~lynn/2002g.html#83 Questions about computer security
https://www.garlic.com/~lynn/2002l.html#58 Spin Loop?
https://www.garlic.com/~lynn/2002l.html#59 Spin Loop?
https://www.garlic.com/~lynn/2002n.html#13 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002o.html#35 META: Newsgroup cliques?
https://www.garlic.com/~lynn/2003d.html#27 [urgent] which OSI layer is SSL located?
https://www.garlic.com/~lynn/2003j.html#34 Interrupt in an IBM mainframe
https://www.garlic.com/~lynn/2003m.html#41 Issues in Using Virtual Address for addressing the Cache
https://www.garlic.com/~lynn/2003m.html#46 OSI protocol header
https://www.garlic.com/~lynn/2003n.html#4 Dual Signature
https://www.garlic.com/~lynn/2004f.html#43 can a program be run withour main memory ?
https://www.garlic.com/~lynn/2004f.html#51 before execution does it require whole program 2 b loaded in
https://www.garlic.com/~lynn/2004f.html#61 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004h.html#47 very basic quextions: public key encryption
https://www.garlic.com/~lynn/2004k.html#34 August 23, 1957
https://www.garlic.com/~lynn/2005h.html#1 Single System Image questions
https://www.garlic.com/~lynn/2005m.html#50 Cluster computing drawbacks
https://www.garlic.com/~lynn/2006.html#16 Would multi-core replace SMPs?
https://www.garlic.com/~lynn/2006b.html#2 Mount a tape
https://www.garlic.com/~lynn/2006h.html#40 Mainframe vs. xSeries
https://www.garlic.com/~lynn/2006l.html#54 Memory Mapped I/O Vs I/O Mapped I/O
https://www.garlic.com/~lynn/2007f.html#16 more shared segment archeology
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Friday musings on the future of 3270 applications Newsgroups: bit.listserv.ibm-main,alt.folklore.computers To: <ibm-main@bama.ua.edu> Date: Fri, 01 Jun 2007 12:00:03 -0600rsmrcina@ibm-main.lst (Rich Smrcina) writes:
this contributed to significant install base of 3270 terminal and terminal emulation products.
in the later part of the 80s ... were had come up with 3-tier
architecture (as an enhancement to client/server)
https://www.garlic.com/~lynn/subnetwork.html#3tier
and were out doing some amount of customer executive presentations ... and taking a lot of heat from the T/R and SAA forces(to some extent SAA could be viewed as attempting to help preserve the terminal emulation paradigm and inhibit the spread of client/server ... and especially this new fangled 3-tier stuff).
we also were taking some amount of heat working with organizations
around the nsfnet backbone effort (i.e. tcp/ip is considered the
technology basis for the modern internet but nsfnet backbone would be
considered the operational basis for the modern internet). some old
email from the period on the topic
https://www.garlic.com/~lynn/lhwemail.html#nsfnet
and after starting to cancel our meetings with outside entities
... then there was suggestion that they should start proposing
SNA/VTAM as the basis for nsfnet backbone ... specific old email
reference
https://www.garlic.com/~lynn/2006w.html#email870109
in this post
https://www.garlic.com/~lynn/2006w.html#21 SNA/VTAM for NSFNET
one of the side happenings in all this was we did get an NSF audit of
high-speed backbone we had running internally
https://www.garlic.com/~lynn/subnetwork.html#internalnet
which concluded that what we had running was at least five yrs ahead of all NSFNET backbone bids (to build something new)
and for some topic drift ... tagential reference here
https://www.garlic.com/~lynn/2007l.html#14 Superconductors and computing
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Is Parallel Programming Just Too Hard? Newsgroups: bit.listserv.ibm-main,alt.folklore.computers To: <ibm-main@bama.ua.edu> Date: Fri, 01 Jun 2007 12:07:53 -0600re:
recent news items
Intel Pledges 80 Core Processor in 5 Years
http://hardware.slashdot.org/hardware/06/09/26/1937237.shtml
Intel shows off 80-core processor
http://news.com.com/Intel+shows+off+80-core+processor/2100-1006_3-6158181.html
Next Windows To Get Multicore Redesign
http://developers.slashdot.org/article.pl?sid=07/05/31/1257231
part of the issue is that a lot of the parallel processing has been limited to high-end market ... where highly skilled programming could be used to manage large amount of shared resources ... effectively concurrently working on different activity from independent sources.
as parallel hardware has started to move downstream into standard consumer market ... issues in the past couple yrs is how to change the (mostly) sequential programming paradigm to better utilize the independent/parallel hardware resources that are available.
the hardware technology motivation is that as components are shrinking ... things like signal latency and synchronized, serial operation are starting to represent a significant limiting factor ... going to asynchronous operation ... even across the distances involved in a typical chip ... can contributed to significant thruput increases.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: My Dream PC -- Chip-Based Newsgroups: alt.folklore.computers Date: Fri, 01 Jun 2007 13:24:59 -0600Frank McCoy <mccoyf@millcomm.com> writes:
have you seen things like differential power analysis?
have you ever peeled a chip ... and used an electron microscope for looking at chip operation?
... slight topic drift ... los gatos vlsi lab was one of the first in using electron microscope in analysing chip operation ... although it was for debugging purposes ... not as an attack/exploit.
in general, if it is sufficiently valuable ... the resources can be spent to obtain the information. part of the issue in x9.59/aads was to eliminate any single (or small number) of key vulnerabilities that might represent a systemic risk for the whole infrastructure. Each key applied to potentially a single (or small number of accounts) ... limiting the risk exposure related to that specific key. then in the lost/stolen scenario ... have the chip protection such that the key extraction was likely to cost more than the value in the accounts (and/or take longer than the typical lost/stolen report that would result in invalidating the key). as i referred to in the previous post ... this was a detailed end-to-end systemic analysis of threats, vulnerabilities, exploits, etc. It wasn't just limited to simple, single point considerations ... nearly all possible attacks/exploits had to be considered and appropriate countermeasures planned for.
in the aads chip strawman
https://www.garlic.com/~lynn/x959.html#aads
i was able to get an (common criteria) EAL4+ evaluation ... in some cases using nearly identical chip that others were getting an EAL5+ evaluation.
part of the issue here was in the aads chip strawman ... everything is manufactured into the chip silicon (it wasn't possible to load any applications after manufacturing ... part of aggresive infrastructure cost reduction) ... even the (ECC) crypto ... so a an EAL5+ evaluation requires a semi-formal definition of the crypto to evaluate against (and at the time, NIST had just pulled its reference critera for ECDSA).
The EAL5+ evaulations on similar chips were scenarios where they allowed post-manufacturing loading (aka the chip could be evaluated w/o any applications, since the crypto and other stuff went on afterwards).
We claimed that the ability to load, was in fact a vulnerability ... and so the aads chip strawman EAL4+ actually represented higher integrity than the EAL5+ and EAL6+ evaluations of similar chips.
one of the issues in the whole x9.59/aads security proportional to risk ... was being able to have original chip integrity characteristics as well as possibly integrity characteristics that the digital signing was occurring in ... to allow things like dynamic risk assessement on transaction by transaction basis ... aka do things like taking in a specific chips integrity characteristics (and attack countermeasures) when evaluated whether a specific transaction should be approved (i.e. where there might be a broad range in the value of the transactions and the integrity level of individual chips ... all supported by a single infrastructure).
there has been some discussions about something you have and
something you know authentication ... but there is also attack,
threat, exploit, vulnerability issues related to the environment that
a digital signature occurs ... some of this is discussed in a series
of posts mentioning the EU FINREAD ("financial reader") terminal
standard
https://www.garlic.com/~lynn/subintegrity.html#finread
quicky use of search engine for some misc. references to various
chip attacks, threats, vulnerabilities, etc
http://www.cryptography.com/resources/whitepapers/DPA.html
https://en.wikipedia.org/wiki/Power_analysis
http://citeseer.ist.psu.edu/kocher99differential.html
http://www.research.ucla.edu/tech/ucla04-155.htm
in general, to really defend ... you also have to be able to think like an attacker ... in order to anticipate the types of attacks that you are defending from. one of our past jokes about some defenses/countermeasures being equivalent to placing a 6ft thick bank vault in the middle of an open field ... with no sides, ceilings, floor, etc. the other scenario in security proportional to risk ... is that it is difficult to justify costs of anti-fraud measures that are significantly larger than the fraud that is supposed to be prevented.
some past posts mentioning EAL4+, common criteria, chip attacks, etc:
https://www.garlic.com/~lynn/2002c.html#15 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002j.html#86 formal fips186-2/x9.62 definition for eal 5/6 evaluation
https://www.garlic.com/~lynn/2002k.html#35 ... certification
https://www.garlic.com/~lynn/2002m.html#44 Beware, Intel to embed digital certificates in Banias
https://www.garlic.com/~lynn/2002m.html#72 Whatever happened to C2 "Orange Book" Windows security?
https://www.garlic.com/~lynn/2003c.html#39 DOD 5200.28-STD capable OS?
https://www.garlic.com/~lynn/2003k.html#51 Linux gets sensitive government use approval
https://www.garlic.com/~lynn/2003l.html#19 Secure OS Thoughts
https://www.garlic.com/~lynn/2004i.html#27 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004j.html#2 Authenticated Public Key Exchange without Digital Certificates?
https://www.garlic.com/~lynn/2004m.html#41 EAL5
https://www.garlic.com/~lynn/2006t.html#38 Vulnerability Assessment of a EAL 4 system
https://www.garlic.com/~lynn/2007b.html#30 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007b.html#47 newbie need help (ECC and wireless)
some past posts mentioning that various parts of the current
infrastructure contributes to attackers being able to outspend the
defenders potentially by a factor of 100:1
https://www.garlic.com/~lynn/aadsm26.htm#58 Our security sucks. Why can't we change? What's wrong with us?
https://www.garlic.com/~lynn/aadsm27.htm#3 Solution to phishing -- an idea who's time has come?
https://www.garlic.com/~lynn/2007e.html#26 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007f.html#75 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007g.html#20 T.J. Maxx data theft worse than first reported
https://www.garlic.com/~lynn/2007h.html#56 T.J. Maxx data theft worse than first reported
https://www.garlic.com/~lynn/2007i.html#64 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007j.html#15 John W. Backus, 82, Fortran developer, dies
for lots of drift ... various past posts mentioning los gatos vlsi lab:
https://www.garlic.com/~lynn/2000.html#16 Computer of the century
https://www.garlic.com/~lynn/2000c.html#65 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2001h.html#29 checking some myths.
https://www.garlic.com/~lynn/2002q.html#19 Beyond 8+3
https://www.garlic.com/~lynn/2002q.html#45 ibm time machine in new york times?
https://www.garlic.com/~lynn/2003h.html#52 Question about Unix "heritage"
https://www.garlic.com/~lynn/2003o.html#16 When nerds were nerds
https://www.garlic.com/~lynn/2003o.html#21 TSO alternative
https://www.garlic.com/~lynn/2004f.html#7 The Network Data Model, foundation for Relational Model
https://www.garlic.com/~lynn/2004f.html#42 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004o.html#25 CKD Disks?
https://www.garlic.com/~lynn/2004q.html#35 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005c.html#1 4shift schedule
https://www.garlic.com/~lynn/2005c.html#6 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005e.html#0 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2006.html#29 IBM microwave application--early data communications
https://www.garlic.com/~lynn/2006u.html#31 To RISC or not to RISC
https://www.garlic.com/~lynn/2007b.html#27 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007d.html#27 modern paging
https://www.garlic.com/~lynn/2007h.html#41 Fast and Safe C Strings: User friendly C macros to Declare and use C Strings
https://www.garlic.com/~lynn/2007j.html#24 Newbie question on table design
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: My Dream PC -- Chip-Based Newsgroups: alt.folklore.computers Date: Fri, 01 Jun 2007 13:40:05 -0600re:
it isn't if or can they ... it is how much is it going to cost and how long will it take ... 1) make it more expensive than any expected benefit to the attacker (i.e. security proportional to risk) and/or 2) make it so expensive to attack (and the resulting fraud ROI so small) that they go somewhere else (that is easier)
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: My Dream PC -- Chip-Based Newsgroups: alt.folklore.computers Date: Fri, 01 Jun 2007 16:58:54 -0600Frank McCoy <mccoyf@millcomm.com> writes:
so destroy the original ... and then replace it with a copy-chip that does a good enuf job of emulation ... call it a doppleganger ... question is how long does the whole process take. or some other really advanced nonintrusive techniques that don't even have to destroy the original (it is somewhat a constant ongoing battle with new attacks requiring new countermeasures).
note that the YES CARD chip exploit is similar but different
https://www.garlic.com/~lynn/subintegrity.html#yescard
two issues ... is can i use the process/equipment against a large number of different tokens (justifying the cost) or are there tokens that represent particular specific vulnerabilities (aka some people might do $20 transactions and others might do $1m transactions) and/or overall systemic risks, that might justify the effort.
the EU FINREAD standard
https://www.garlic.com/~lynn/subintegrity.html#finread
has to do with whether the transaction that you think you are approving/authorizing (displayed by the terminal) is actually the transaction that you are approving/authorizing (by using the something you have token to generate a digital signature). another kind of exploit/vulnerability that doesn't require direct compromise of your chip/token.
one of the issues in doing aads
https://www.garlic.com/~lynn/x959.html#aads
and the financial industry standard
https://www.garlic.com/~lynn/x959.html#x959
in some quarters there is automatic kneejerk reaction that if you say public key ... there are automatic assumptions about certification authorities and PKI operations.
this was avoided in basic aads/x9.59 work because of perceived
systemic risks ... so a certificate-less public key operation is
defined
https://www.garlic.com/~lynn/subpubkey.html#certless
and old email reference discussing certificate-less public key operation
https://www.garlic.com/~lynn/2006w.html#email810515
in this post
https://www.garlic.com/~lynn/2006w.html#12 more secure communication overthe network
so, in this recent thread there is some discussion about PKIs and
certificate-based operations ... especially around its application to
SSL
https://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#16 dnssec?
https://www.garlic.com/~lynn/aadsm27.htm#17 dnssec?
https://www.garlic.com/~lynn/aadsm27.htm#19 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#20 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#21 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#22 A crazy thought?
aka ... we had been called into consult with this new client/server
startup that wanted to do payment transactions on their servers ...
and they had some technology they called SSL ... minor reference
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
and lots of other posts mentioning SSL and SSL related infrastructure
https://www.garlic.com/~lynn/subpubkey.html#sslcert
one of the issues in PKI infrastructure ... it isn't the use of a specific private key in digital signatures representing something you have authentication ... it is what a "digital certificate" says about you and the "public key" (that is paired with your "private key").
as mentioned in the above referenced thread ... typical browser might have 40-50 different public keys (in the trusted public key repository) ... and compromise against any particular (certification authority) key ... is sufficient to compromise the whole infrastructure (systemic risk) ... aka extract a specific private key (w/o leaving traces) ... and then be able to use that extracted/compromised private key to generate "valid" digital certificates for everybody (somewhat like some of spy stories about stealing valid plates, paper, & ink in order to print your own counterfeit money) ... specifying public/private keys in the possession of the attackers ... aka ... they don't have to find out your private key ... they just have to "print" a valid digital certificate that says it applies to you ... and specifying a public key that they control.
lots of posts about various kinds of fraud, threats, vulnerabilities,
exploits, etc
https://www.garlic.com/~lynn/subintegrity.html#fraud
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: My Dream PC -- Chip-Based Newsgroups: alt.folklore.computers Date: Fri, 01 Jun 2007 17:25:28 -0600for the fun of it ... a little x-over between the recent "authentication" and "integrity" subthread
and the "Is Parallel Programming Too Hard?" thread
https://www.garlic.com/~lynn/2007l.html#24 Is Parallel Programming Just Too Hard?
https://www.garlic.com/~lynn/2007l.html#34 Is Parallel Programming Just Too Hard?
https://www.garlic.com/~lynn/2007l.html#38 Is Parallel Programming Just Too Hard?
besides multi-core ... lots of past multiprocessor related posts
https://www.garlic.com/~lynn/subtopic.html#smp
... the other parallel programming venue is the massive GRIDs ... even
further scale-up than what we had started for ha/cmp
https://www.garlic.com/~lynn/subtopic.html#hacmp
... old email references
https://www.garlic.com/~lynn/lhwemail.html#medusa
a lot of the medusa "cluster-in-a-rack" (with potentially large number of racks) was physical packaging placing higher and higher density of commodity computing components in smaller & smaller footprint. A current generation of that physical packaging (in large part originally done for GRID) is called blades ... and you are seeing the vendors trying to move the technology out of the purely numerical intensive environments and more & more into various commercial sectors.
in any case, there is a reference here to an "authentication" &
"integrity" talk that i gave at an annual GRID conference:
https://www.garlic.com/~lynn/index.html#presentation
one scenario being what if an attacker could compromise a very large GRID installation, turning it into a massive "botnet"
another "authentication" talk I gave was at an assurance panel in the TPM (trusted process module) track at an Intel Developer's conference. I've joked before that the guy running the TPM effort was in the front row ... and that I quipped it was nice to see that over the previous couple years the TPM chip definition had started to look more and more like the AADS chip strawman. He quipped back ... that I didn't have a committee of a couple hundred helping me with chip design.
A recent post mentioning have looked at a solution with some of the
TPM characteristics when the original PC came out
https://www.garlic.com/~lynn/aadsm27.htm#9 Enterprise Right Management vs. Traditional Encryption Tools
a couple past posts mentioning the talk in the TPM track at an
Intel Developer's forum
https://www.garlic.com/~lynn/2001d.html#58 Very CISC Instuctions (Was: why the machine word size ...)
https://www.garlic.com/~lynn/2006h.html#31 Intel vPro Technology
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: My Dream PC -- Chip-Based Newsgroups: alt.folklore.computers Date: Fri, 01 Jun 2007 17:41:50 -0600Frank McCoy <mccoyf@millcomm.com> writes:
the issue is whether the private key extraction is invasive or not ... there are some techniques that are destructive and require a doppleganger to hide the fact that it has happened (and there are some number of noninvasive/nondestructive techniques). the issue is somewhat like all the data breaches ... there is significantly more fraud potential if the victims are kept unaware of the compromise for as long as possible.
this somewhat flows over into the previous discussion mentioning institutional centric tokens vis-a-vis person-centric tokens. one of the infrastructure issues in the institutional centric operations is the extremely high security (and the associated costs) that has to be maintained between the chip fab and any personalization (software loading, key loading, etc) that must occur before final delivery of the token to the individual.
the claim frequently was that the extremely high (& costly) security (before final delivery) was necessary to make sure that copy/counterfeit chips hadn't been introduced into the supply chain. the effort for enabling a transition from institutional centric operation to a person-center paradigm ... was to provide some high assurance mechanism that a person "presented" token (for use at an institution) would be just as good as any institution provided token.
not only did it eliminate the high/costly (post chip-fab) security (part
of the aads chip strawman aggresive per token cost reduction) ... but
any really "successful" institutional centric effort would mean that
individuals would have a token in place of every (physical) key,
password, and PIN (potentially a hundred or more per person). part of
any successful aads chip strawman effort, not only significantly reduced
the (total end-to-end, fully loaded) per token related costs ... but
also enabling the person-centric paradigm would also significantly
reduce the total number of tokens that would be needed (i.e. 2-3 orders
of magnitude in per token fully loaded costs and potentially another 2-3
orders of magnitude in the total number of tokens ... possibly overall
reduction of 4-6 orders of magnitude) ... recent reference
https://www.garlic.com/~lynn/2007l.html#8 John W. Backus, 82, Fortran developer, dies
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: internet game history Newsgroups: alt.folklore.computers Date: Fri, 01 Jun 2007 18:01:49 -0600late 70s(?) ... a multi-user "space war" game was done that ran on the internal network (written by the author of rexx) ... you had to put up server and then ran client application in each private cms (cms clients could be time-shared on the same real machine as the game server and/or on other real machines networked to the machine running the game server) ... the client application then was responsible for sending moves to the server and receiving "screen" updates (from the server) and displaying them.
within a couple weeks client "bots" had been created (in place of the standard client app) that would beat all the human players (mostly because their reaction time for moves/actions was much faster).
then the game/server was retrofitted with adjustment that as the interval between individual moves/actions dropped below a (human reaction) threshold ... there was non-linear increase in energy used. bots weren't disallowed ... but the non-linear increase in energy used was to somewhat level the playing field between humans playing and the bots.
so one thing interesting aspect of multi-user networked game history was when/where did game bots put in their appearance.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: internet game history Newsgroups: alt.folklore.computers Date: Sat, 02 Jun 2007 03:20:19 -0600re:
previous post
https://www.garlic.com/~lynn/2005u.html#4 Fast action games on System/360+?
with small snippet from MFF client source (circa summer 1980)
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: My Dream PC -- Chip-Based Newsgroups: alt.folklore.computers Date: Sat, 02 Jun 2007 03:37:55 -0600some posts that reference a risk digest with an item on "nothing succeeds like failure" ...
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: My Dream PC -- Chip-Based Newsgroups: alt.folklore.computers Date: Sat, 02 Jun 2007 04:00:41 -0600Anne & Lynn Wheeler <lynn@garlic.com> writes:
for other topic drift ... los gatos lab also worked on ibm's original atm
(cash) machine (also makes reference to early PIN-block vulnerability)
https://www.garlic.com/~lynn/2006q.html#5
https://www.garlic.com/~lynn/2006u.html#40
https://www.garlic.com/~lynn/2006x.html#9
and news item from today ...
Would you credit it? The debit card turns 20
http://www.silicon.com/financialservices/0,3800010322,39167351,00.htm?r=1
which would make it 1987 ... however the previous posts have references for the 2984 as 1972 (15 yrs earlier), 3614 in 1973, and the 3624 in 1979 aka they must be making some distinction "debit" cards and ATM machine "debit" cards
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: My Dream PC -- Chip-Based Newsgroups: alt.folklore.computers Date: Sat, 02 Jun 2007 09:36:32 -0600Frank McCoy <mccoyf@millcomm.com> writes:
which then flows into the observation that (for the scenario involving
credit card accounts), attackers can afford to outspend the defenders by
possibly as much as 100:1. recent posts mentioning attackers
can outspend defenders by possibly 100:1
https://www.garlic.com/~lynn/aadsm27.htm#3 Solution to phishing -- an idea who's time has come?
https://www.garlic.com/~lynn/2007e.html#26 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007g.html#20 T.J. Maxx data theft worse than first reported
https://www.garlic.com/~lynn/2007h.html#56 T.J. Maxx data theft worse than first reported
https://www.garlic.com/~lynn/2007i.html#64 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007j.html#15 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#39 My Dream PC -- Chip-Based
one of the upswings in the early to mid 90s was a class of extremely skilled and highly technical criminal attackers ... something that many had been claiming would never possibly occur ... i.e. criminals were frequently assumed to be bumbling bank robbers with guns and lacking a high school education.
re:
https://www.garlic.com/~lynn/2007l.html#43 My Dream PC -- Chip-based
so for PKI & certification authority related infrastructure ... it turns out to not be necessary to even attack the individual account hardware tokens ... it would only be sufficient to attack the hardware token of a certification authority ... since in a PKI infrastructure ... it isn't what is onfile about you ... but what a valid digital certificate claims about you. you obtain the private key of any of the valid trusted certification authorities ... possibly by destructive process, substitute the doppleganger, and then start minting your own digital certificates for all your friends ... which make claims about existing accounts but specifies their own public keys (not the real account holders public keys).
one of the reasons that the detailed, end-to-end threat & vulnerability
analysis (as part of the x9.59 financial standards work) that PKI &
certification authority infrastructures were treated as systemic risks
https://www.garlic.com/~lynn/x959.html#x959
... as well as treating digital certificates as obsolete and adding
enormous redundant and superfluous payload and processing bloat in the
case of payment transactions
https://www.garlic.com/~lynn/subpubkey.html#bloat
including a few recent threads/discussions
https://www.garlic.com/~lynn/aadsm27.htm#1 H6.2 Most Standardised Security Protocols are Too Heavy
https://www.garlic.com/~lynn/aadsm27.htm#21 307 digit number factored
https://www.garlic.com/~lynn/2007j.html#67 open source voting
https://www.garlic.com/~lynn/2007l.html#16 John W. Backus, 82, Fortran developer, dies
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Drums: Memory or Peripheral? Newsgroups: alt.folklore.computers Date: Sun, 03 Jun 2007 09:17:03 -0600Peter Flass <Peter_Flass@Yahoo.com> writes:
in disk form factor, cylinder refers to the arm position and head refers to the specific head on the arm. however, there are also references to TTR and the number of tracks per cylinder (i.e. number of surfaces).
"BB" was used in 2321 data-cell ... where there were multiple "bins" of data strips ... the bins were formed into somewhat physical cylinder configuration that rotated (somewhat like washing machine) the desired bin (collection of data strips) under head position.
picture of both 2303 drum, 2321 datacell, and 2311 disk
http://www.beagle-ears.com/lars/engineer/comphist/c20-1684/fig043.jpg
2301 & 2303 were physically similar ... except 2301 read/writes four heads in parallel ... for four times the data transfer rate of 2303
RPS (rotational position sensing) was introduced with 3330 DASD ... there were 20 surfaces ... but only 19 addressable track/heads ... the 20th head/track was used to keep "track" of the rotational position.
in cp67 and vm370, especially for paging ... there was a lot of optimization related to attempting to transfer as much data per revolution. queued/pending requests might include some number of requests for the same cylinder (arm position) but different tracks. building the channel programs so that order of page transfers selected corresponding to the sequential rotational position ... even if located on different tracks.
the original cp67 installed at the university when i was an
undergraduate had purely FIFO single request transfer at a time. For
2301, this would peak out at about 80 page transfers/second under
heavy load. I rewrote the code so that it would build chained I/O of
pending requests, ordered so as to maximize transfers per revolution
... being able to hit 300 page transfers/second (under heavy load)
... which was the theoretical maximum for the 2301. For disks, I also
replaced the FIFO (cylinder) request order ... with
ordered-seek-queueing ... and for paging requests ... would chain
together all requests at the same arm positioning ... again reordering
them to attempt to achieve maximum transfers per
revolution. Non-paging disks requests ... like for cms filesystem, etc
... then weren't subject to the ordered-seek queueing rewrite ... but
different requests would be reordered for the same arm position ... I
did "correct" this a couple years later when i did page-mapped
implementation for the cms filesystem (in the early 70s)
https://www.garlic.com/~lynn/submain.html#mmap
a few recent posts mentioning ordered seek queueing
https://www.garlic.com/~lynn/2007e.html#33 IBM S/360 series operating systems history
https://www.garlic.com/~lynn/2007e.html#40 FBA rant
https://www.garlic.com/~lynn/2007g.html#12 University rank of Computer Architecture
https://www.garlic.com/~lynn/2007k.html#17 John W. Backus, 82, Fortran developer, dies
some recent posts mentioning 2321 data cell
https://www.garlic.com/~lynn/2007e.html#38 FBA rant
https://www.garlic.com/~lynn/2007e.html#51 FBA rant
https://www.garlic.com/~lynn/2007e.html#63 FBA rant
https://www.garlic.com/~lynn/2007e.html#64 FBA rant
https://www.garlic.com/~lynn/2007f.html#0 FBA rant
https://www.garlic.com/~lynn/2007f.html#3 FBA rant
https://www.garlic.com/~lynn/2007f.html#5 FBA rant
https://www.garlic.com/~lynn/2007f.html#12 FBA rant
https://www.garlic.com/~lynn/2007f.html#64 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007j.html#9 Newbie question on table design
other recent posts mentioning 2301 (drums)
https://www.garlic.com/~lynn/2007e.html#38 FBA rant
https://www.garlic.com/~lynn/2007e.html#64 FBA rant
https://www.garlic.com/~lynn/2007g.html#31 Wylbur and Paging
https://www.garlic.com/~lynn/2007g.html#33 Wylbur and Paging
https://www.garlic.com/~lynn/2007k.html#16 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007k.html#17 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007k.html#38 John W. Backus, 82, Fortran developer, dies
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Scholars needed to build a computer history bibliography Newsgroups: alt.folklore.computers Date: Sun, 03 Jun 2007 09:29:28 -0600Louis Krupp <lkrupp@pssw.nospam.com.invalid> writes:
there was period in the early/mid 90s ... where there was some fashion to refer to it ... related to the literacy studies/comparisons from the period (common phrase was the dumbing of america) ... predicting that things would go out more with a wimper than a bang ... somewhat more analogous to the fall of rome.
recent posts/threads discussing the literacy issue
https://www.garlic.com/~lynn/2007g.html#7 U.S. Cedes Top Spot in Global IT Competitiveness
https://www.garlic.com/~lynn/2007i.html#24 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#79 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007j.html#31 IBM Unionization
https://www.garlic.com/~lynn/2007j.html#51 IBM Unionization
https://www.garlic.com/~lynn/2007j.html#58 IBM Unionization
https://www.garlic.com/~lynn/2007j.html#80 IBM Unionization
https://www.garlic.com/~lynn/2007j.html#82 IBM Unionization
https://www.garlic.com/~lynn/2007j.html#85 IBM Unionization
https://www.garlic.com/~lynn/2007k.html#10 IBM Unionization
https://www.garlic.com/~lynn/2007k.html#30 IBM Unionization
https://www.garlic.com/~lynn/2007k.html#34 IBM Unionization
https://www.garlic.com/~lynn/2007k.html#42 IBM Unionization
https://www.garlic.com/~lynn/2007l.html#5 IBM Unionization
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Scholars needed to build a computer history bibliography Newsgroups: alt.folklore.computers Date: Sun, 03 Jun 2007 09:44:10 -0600Larry__Weiss <lfw@airmail.net> writes:
however, I "lost" quite a bit from the 60s and 70s ... when almaden tape
library was experiencing some operational problems ... i.e. operators
apparently were randomly selecting tapes to be mounted as "scratch"
... and i lost stuff that had been replicated on three different sets of
tapes. a few past refs:
https://www.garlic.com/~lynn/2000.html#43 Historically important UNIX or computer things.....
https://www.garlic.com/~lynn/2000.html#44 Historically important UNIX or computer things.....
https://www.garlic.com/~lynn/2003j.html#14 A Dark Day
https://www.garlic.com/~lynn/2004b.html#59 A POX on you, Dennis Ritchie!!!
https://www.garlic.com/~lynn/2006w.html#42 vmshare
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Drums: Memory or Peripheral? Newsgroups: alt.folklore.computers Date: Sun, 03 Jun 2007 20:12:37 -0600Quadibloc <jsavard@ecn.ab.ca> writes:
... or possibly lower-capacity? modulo some factor.
the 2303 & 2301 were fixed head drums ... they appear to be physically the same with same total capacity. however 2301 had 1/4th the number of tracks, each one four times larger ... i.e. 2301 read/wrote 4 heads in parallel for four times the data transfer rate (of 2303)
2305-1 & 2305-2 were fixed head disks. they appear to be nearly physically the same ... with the same number of heads ... however 2305-1 had half the number of tracks and half the data capacity, but twice the data transfer rate and half the rotational delay ... aka two heads on each track, offset 180degrees, heads read/wrote in parallel on the same track. setup each track with half the track as odd bytes and the other half as even bytes ... offset heads read/wrote even/odd bytes and switched roles every half revolution.
thin-film floating heads lowered the flying height, increased the data density and reduced the inter-track spacing (for 3380 disk drives). i've posted before story about moving the air-bearing simulation (for design of thin-film floating heads) application off the 370/195 in bldg. 28 (sjr) to the newly installed 3033 in bldg. 15 (product test lab).
then there is this old email referencing the 16+2 proposal (wide
thin-film head that could read/write 18 closely spaced tracks, by person
responsible for 801/risc)
https://www.garlic.com/~lynn/2006s.html#email871230
in this post
https://www.garlic.com/~lynn/2006s.html#30 Why magnetic drums was/are worse than disks ?
other old email in the same post, discussing 3380 inter-track spacing in
original 3380s and "double density" 3380s
https://www.garlic.com/~lynn/2006s.html#email871122
more recent reference:
https://www.garlic.com/~lynn/2007k.html#21 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007k.html#38 John W. Backus, 82, Fortran developer, dies
misc. posts about getting to play disk engineer
https://www.garlic.com/~lynn/subtopic.html#disk
other posts in the thread from last fall
https://www.garlic.com/~lynn/2006s.html#23 Why magnetic drums was/are worse than disks ?
https://www.garlic.com/~lynn/2006s.html#30 Why magnetic drums was/are worse than disks ?
https://www.garlic.com/~lynn/2006s.html#31 Why magnetic drums was/are worse than disks ?
https://www.garlic.com/~lynn/2006s.html#32 Why magnetic drums was/are worse than disks ?
https://www.garlic.com/~lynn/2006s.html#33 Why magnetic drums was/are worse than disks ?
https://www.garlic.com/~lynn/2006s.html#45 Why magnetic drums was/are worse than disks ?
https://www.garlic.com/~lynn/2006s.html#59 Why magnetic drums was/are worse than disks ?
https://www.garlic.com/~lynn/2006t.html#18 Why magnetic drums was/are worse than disks ?
past references to the air-bearing simulation application as part
of designing 3380 thin-film floating heads:
https://www.garlic.com/~lynn/2001n.html#39 195 was: Computer Typesetting Was: Movies with source code
https://www.garlic.com/~lynn/2002j.html#30 Weird
https://www.garlic.com/~lynn/2002n.html#63 Help me find pics of a UNIVAC please
https://www.garlic.com/~lynn/2002o.html#74 They Got Mail: Not-So-Fond Farewells
https://www.garlic.com/~lynn/2003b.html#51 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003b.html#52 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003j.html#69 Multics Concepts For the Contemporary Computing World
https://www.garlic.com/~lynn/2003m.html#20 360 Microde Floating Point Fix
https://www.garlic.com/~lynn/2003n.html#45 hung/zombie users ... long boring, wandering story
https://www.garlic.com/~lynn/2004.html#21 40th anniversary of IBM System/360 on 7 Apr 2004
https://www.garlic.com/~lynn/2004b.html#15 harddisk in space
https://www.garlic.com/~lynn/2004o.html#15 360 longevity, was RISCs too close to hardware?
https://www.garlic.com/~lynn/2004o.html#25 CKD Disks?
https://www.garlic.com/~lynn/2005.html#8 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005f.html#4 System/360; Hardwired vs. Microcoded
https://www.garlic.com/~lynn/2005f.html#5 System/360; Hardwired vs. Microcoded
https://www.garlic.com/~lynn/2005o.html#44 Intel engineer discusses their dual-core design
https://www.garlic.com/~lynn/2006c.html#6 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006d.html#0 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006d.html#13 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006d.html#14 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006l.html#18 virtual memory
https://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006t.html#41 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006x.html#27 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006x.html#31 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2007e.html#43 FBA rant
https://www.garlic.com/~lynn/2007e.html#44 Is computer history taught now?
https://www.garlic.com/~lynn/2007f.html#46 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007j.html#13 Interrupts
https://www.garlic.com/~lynn/2007j.html#64 Disc Drives
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Drums: Memory or Peripheral? Newsgroups: alt.folklore.computers Date: Sun, 03 Jun 2007 20:41:03 -0600re:
for other topic drift ... somewhat related to 3380, thin-film, floating
heads, etc. ... a couple recent posts mentioning los gatos vlsi lab
https://www.garlic.com/~lynn/2007l.html#39 My Dream PC -- Chip-base
https://www.garlic.com/~lynn/2007l.html#47 My Dream PC -- Chip-base
one of the first chips that los gatos used electron microscope on was blue iliad ... first 32-bit 801 chip ... which never shipped in product.
los gatos lab also did jib-prime ... which was the microprocessor used in the 3880 disk controller.
los gatos also did the LSM (los gatos state machine, but written up in external documentation as the logic simulation machine). it was rated at doing chip design logic simulation at something like 50,000 times faster than 3033 processor. one of the things that set the LSM apart from the later machines (like EVE ... endicott verification engine) was provisions for timing (i.e. later machines would assume a synchronous clock) ... allowing it to handle chips with asynchronous clocks and digital chips with analog circuits (things like new generation of disk heads).
besides being allowed to play disk engineer in bldgs 14&15 ... i was allowed to play with chip grp in bldg 29 (los gatos lab) ... they let me have a couple labs and a suite of offices.
I also did some stuff in implementation of a new/different kind of
experimental database ... being done somewhat as joint project between
the VLSI tools grp in bldg. 29 and some of the people in STL (bldg. 90,
now called silicon valley lab) ... at the same time I was doing some of
the stuff for system/r in research ... some past mention of original
relational/sql
https://www.garlic.com/~lynn/submain.html#systemr
misc. past posts mentioning LSM
https://www.garlic.com/~lynn/2002d.html#3 Chip Emulators - was How does a chip get designed?
https://www.garlic.com/~lynn/2002g.html#55 Multics hardware (was Re: "Soul of a New Machine" Computer?)
https://www.garlic.com/~lynn/2002g.html#77 Pipelining in the past
https://www.garlic.com/~lynn/2002g.html#82 Future architecture
https://www.garlic.com/~lynn/2002j.html#26 LSM, YSE, & EVE
https://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
https://www.garlic.com/~lynn/2003.html#31 asynchronous CPUs
https://www.garlic.com/~lynn/2003k.html#3 Ping: Anne & Lynn Wheeler
https://www.garlic.com/~lynn/2003k.html#14 Ping: Anne & Lynn Wheeler
https://www.garlic.com/~lynn/2003o.html#38 When nerds were nerds
https://www.garlic.com/~lynn/2004j.html#16 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2004o.html#25 CKD Disks?
https://www.garlic.com/~lynn/2004o.html#65 360 longevity, was RISCs too close to hardware?
https://www.garlic.com/~lynn/2005c.html#6 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005d.html#33 Thou shalt have no other gods before the ANSI C standard
https://www.garlic.com/~lynn/2005q.html#17 Ethernet, Aloha and CSMA/CD -
https://www.garlic.com/~lynn/2006.html#29 IBM microwave application--early data communications
https://www.garlic.com/~lynn/2006q.html#42 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006r.html#11 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2007f.html#73 Is computer history taught now?
https://www.garlic.com/~lynn/2007h.html#61 Fast and Safe C Strings: User friendly C macros to Declare and use C Strings
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Newbie question on table design. Newsgroups: alt.folklore.computers Date: Mon, 04 Jun 2007 06:49:19 -0600Brian Inglis <Brian.Inglis@SystematicSW.Invalid> writes:
some other perspectives ... from nsfnet series of old email
https://www.garlic.com/~lynn/lhwemail.html#nsfnet
that after they got us out of the way ... then some thot the
way was clear to push sna/vtam into nsfnet
https://www.garlic.com/~lynn/2006w.html#email870109
in this post
https://www.garlic.com/~lynn/2006w.html#21 SNA/VTAM for NSFNET
for other drift, recent reference
https://www.garlic.com/~lynn/2007l.html#14 Superconductors and computing
the original mainframe tcp/ip product had been implemented in vs/pascal
(for vm/cms). for whatever reasons it had rather high overhead
... getting about 44kbytes/sec aggregate thruput using approx. full 3090
processor. i then added rfc 1040 support and in some testing at cray
research ... was able to get 1mbyte/sec aggregate thruput (hardware
limit) between a cray and 4341-clone (about factor of 500 times
improvement in terms of byte transferred per instruction executed).
https://www.garlic.com/~lynn/subnetwork.html#1044
it was also eventually ported to mvs by providing a "diagnose" (i.e. vm kernel api) emulator in mvs
for other drift ... old folklore later about tcp support eventually
being added to vtam:
https://www.garlic.com/~lynn/2000b.html#79 "Database" term ok for plain files?
https://www.garlic.com/~lynn/2005r.html#2 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2006l.html#53 Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
https://www.garlic.com/~lynn/2006u.html#44 waiting for acknowledgments
https://www.garlic.com/~lynn/2006w.html#29 Descriptive term for reentrant program that nonetheless is
for even more drift ... mainframe pascal had originally been
done at los gatos lab ... by the vlsi tools group and used for a lot
of different applications ... including a number of vlsi chip design
applications and experimental database implementation ... recent
los gatos lab references
https://www.garlic.com/~lynn/2007l.html#49 Drums: Memory or Peripheral?
https://www.garlic.com/~lynn/2007l.html#52 Drums: Memory or Peripheral?
https://www.garlic.com/~lynn/2007l.html#53 Drums: Memory or Peripheral?
other recent vs/pascal references
https://www.garlic.com/~lynn/2007b.html#12 Special characters in passwords was Re: RACF - Password rules
https://www.garlic.com/~lynn/2007c.html#21 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007c.html#29 Being "Open" (Was: Mainframe vs. "Server")
https://www.garlic.com/~lynn/2007h.html#8 whiny question: Why won't z/OS support the HMC 3270 emulator
https://www.garlic.com/~lynn/2007h.html#41 Fast and Safe C Strings: User friendly C macros to Declare and use C Strings
https://www.garlic.com/~lynn/2007h.html#61 Fast and Safe C Strings: User friendly C macros to Declare and use C Strings
https://www.garlic.com/~lynn/2007j.html#14 Newbie question on table design
https://www.garlic.com/~lynn/2007j.html#16 Newbie question on table design
https://www.garlic.com/~lynn/2007j.html#70 Using rexx to send an email
https://www.garlic.com/~lynn/2007k.html#26 user level TCP implementation
https://www.garlic.com/~lynn/2007l.html#11 John W. Backus, 82, Fortran developer, dies
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Scholars needed to build a computer history bibliography Newsgroups: alt.folklore.computers Date: Tue, 05 Jun 2007 09:05:54 -0600Peter Flass <Peter_Flass@Yahoo.com> writes:
from threads on prevalence of buffer overflows in C language programming
environments
https://www.garlic.com/~lynn/subintegrity.html#overflow
some recent posts on the subject:
https://www.garlic.com/~lynn/2007g.html#49 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#14 conformance
https://www.garlic.com/~lynn/2007h.html#41 Fast and Safe C Strings: User friendly C macros to Declare and use C Strings
https://www.garlic.com/~lynn/2007l.html#11 John W. Backus, 82, Fortran developer, dies
... for other drift ... multics (on the 5th flr of 545 tech sq) and the
virtual machine operating system (cp40/cp67 at the sci center on the 4th
flr of 545 tech sq) ... somewhat both grew out of mit's ctss project.
old folklore can be found in melinda's
https://www.leeandmelindavarian.com/Melinda/
https://www.leeandmelindavarian.com/Melinda#VMHist
history paper that covers much of the period .. VM and the VM Community:
Past, Present, and Future
https://www.leeandmelindavarian.com/Melinda/25paper.pdf
lots of posts mentioning sci center
https://www.garlic.com/~lynn/subtopic.html#545tech
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Scholars needed to build a computer history bibliography Newsgroups: alt.folklore.computers Date: Tue, 05 Jun 2007 09:32:10 -0600re:
and for some relational/SQL DBMS ... there is
http://www.mcjones.org/System_R/index.html
and
http://www.mcjones.org/System_R/SQL_Reunion_95/
with lots of early remembrance ... not just system/r ... but a lot of DBMS activity going on in the period, some of the people, things like data base machines, etc. Nearly all of the System/R had also been done on virtual machine operating system implementation.
misc. past posts mentioning system/r
https://www.garlic.com/~lynn/submain.html#systemr
some recent postings with old email from some of the period:
https://www.garlic.com/~lynn/2007.html#1 "The Elements of Programming Style"
https://www.garlic.com/~lynn/2007.html#2 "The Elements of Programming Style"
https://www.garlic.com/~lynn/2007.html#13 "The Elements of Programming Style"
https://www.garlic.com/~lynn/2007d.html#17 Jim Gray Is Missing
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: How would a relational operating system look like? Newsgroups: comp.databases.theory Date: Tue, 05 Jun 2007 11:21:18 -0600Thomas Gagne <tgagne@wide-open-west.com> writes:
the reunion mentiond some of the "database machines" and the people involved. my impression from the period was that the inception of sybase (at least partially) involved moving off proprietary hardware and building on "more" COTS platforms
teradata specific reference:
http://www.mcjones.org/System_R/SQL_Reunion_95/sqlr95-Teradata.html#Index447
note that AT&T has since spun off NCR and NCR has announced spinning off
Teradata.
http://www.teradata.com/updates
misc past posts mentioning relational, sql, system/r
https://www.garlic.com/~lynn/submain.html#systemr
for total other archeological drift ... in the system/r timeframe,
Luther Woodrum was doing some amount on index structures ... both on
disk and in memory. some of that eventually showed up in mainframe
instructions supporting "in-memory" index structures (written up for
sorting)
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/A.7
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Scholars needed to build a computer history bibliography Newsgroups: alt.folklore.computers Date: Tue, 05 Jun 2007 11:41:20 -0600Joe Walker <joeNOSPAM@joewalker.org> writes:
slightly different language x-over ... multics was on the 5th flr of 545
tech sq., the (ibm) cambridge science center was on the 4th flr of 545
tech sq., and the (ibm) boston programming center was on the 3rd flr of
545 tech sq. ... misc. past posts mentioning 545 tech sq
https://www.garlic.com/~lynn/subtopic.html#545tech
rochester, sammet (and some number of other people) were on the 3rd flr at the boston programming center. as cp67 effort grew and morphed into vm370, the dev. effort took over the boston programming center (on the 3rd flr) and absorbed most of the (ibm) people on the 3rd into the vm370 product effort (before outgrowing 3rd flr, tech sq and moving out to the old SBC bldg. in burlington mall) ... with some others joining the science center (i.e. the vm370 development grp and the science center had split into two separate organizations by that time)
wiki reference mentioning Nat Rochester
https://en.wikipedia.org/wiki/Timeline_of_programming_languages
and reference here in article about the 701 team
http://www-03.ibm.com/ibm/history/exhibits/701/701_team.html
and a rochester "audio"
http://www-03.ibm.com/ibm/history/exhibits/701/audio/rochester_enh.wav
and wiki reference mentioning Jean Sammet
https://en.wikipedia.org/wiki/Jean_E._Sammet
a few past posts mentioning nat rochester, jean sammet and/or some of
the other people at the boston programming center.
https://www.garlic.com/~lynn/2000d.html#37 S/360 development burnout?
https://www.garlic.com/~lynn/2000f.html#66 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
https://www.garlic.com/~lynn/2001m.html#47 TSS/360
https://www.garlic.com/~lynn/2002h.html#59 history of CMS
https://www.garlic.com/~lynn/2002j.html#17 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002o.html#76 (old) list of (old) books
https://www.garlic.com/~lynn/2002o.html#78 Newsgroup cliques?
https://www.garlic.com/~lynn/2003c.html#0 Wanted: Weird Programming Language
https://www.garlic.com/~lynn/2003c.html#1 Wanted: Weird Programming Language
https://www.garlic.com/~lynn/2003k.html#55 S/360 IPL from 7 track tape
https://www.garlic.com/~lynn/2004.html#20 BASIC Language History?
https://www.garlic.com/~lynn/2004b.html#14 The BASIC Variations
https://www.garlic.com/~lynn/2004d.html#42 REXX still going strong after 25 years
https://www.garlic.com/~lynn/2004m.html#54 Shipwrecks
https://www.garlic.com/~lynn/2005.html#8 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005k.html#44 Book on computer architecture for beginners
https://www.garlic.com/~lynn/2006j.html#44 virtual memory
https://www.garlic.com/~lynn/2006m.html#21 The very first text editor
https://www.garlic.com/~lynn/2006m.html#28 Mainframe Limericks
https://www.garlic.com/~lynn/2006s.html#1 Info on Compiler System 1 (Univac, Navy)?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Scholars needed to build a computer history bibliography Newsgroups: alt.folklore.computers Date: Tue, 05 Jun 2007 12:59:11 -0600Anne & Lynn Wheeler <lynn@garlic.com> writes:
above wiki programming language timeline reference mentions apl ... so for a little more x-over ... the (ibm) phili science center had apl\360, the camb. science center took apl\360 and ported it to cp67/cms ... along the way could eliminate the embedded (apl\360) scheduler, dispatcher, swapper, terminal handler, etc ... which were needed to compensate for the primitive interactive facilities in the base os/360 platform (i.e. for cms\apl, features all provided by cp67). In addition, the storage allocation and storage garbage collection had to be redone as part of moving from the (apl\360) small, real-storage, apl workspaces, to the (relatively 10-100 times) large virtual memory workspaces available with cp67/cms.
lots of past posts mentioning HONE &/or APL ... i.e. HONE was an
internal, online, interactive (initially cp67, later moving to vm370)
service supporting world-wide sales, marketing, and field personal
where majority of the applications were written in apl (initially
cms\apl, but morphing thru the generations of apl\cms, apl\sv, vs\apl,
etc).
https://www.garlic.com/~lynn/subtopic.html#hone
misc recent posts mentioning cms\apl
https://www.garlic.com/~lynn/2007b.html#32 IBMLink 2000 Finding ESO levels
https://www.garlic.com/~lynn/2007d.html#64 Is computer history taugh now?
https://www.garlic.com/~lynn/2007g.html#31 Wylbur and Paging
https://www.garlic.com/~lynn/2007g.html#39 Wylbur and Paging
https://www.garlic.com/~lynn/2007g.html#43 Wylbur and CRBE
https://www.garlic.com/~lynn/2007g.html#48 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#62 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007i.html#20 Does anyone know of a documented case of VM being penetrated by hackers?
https://www.garlic.com/~lynn/2007i.html#77 Sizing CPU
https://www.garlic.com/~lynn/2007j.html#13 Interrupts
https://www.garlic.com/~lynn/2007j.html#17 Newbie question on table design
https://www.garlic.com/~lynn/2007j.html#19 IBM Unionization
https://www.garlic.com/~lynn/2007j.html#65 Help settle a job title/role debate
https://www.garlic.com/~lynn/2007k.html#65 Non-Standard Mainframe Language?
https://www.garlic.com/~lynn/2007k.html#67 Non-Standard Mainframe Language?
https://www.garlic.com/~lynn/2007k.html#73 Non-Standard Mainframe Language?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Is Parallel Programming Just Too Hard? Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Wed, 06 Jun 2007 08:16:59 -0600a couple recent items:
The death of single threaded development
http://blogs.zdnet.com/Ou/?p=519
Google Acquires Multicore Programming Startup PeakStream --
Multithreaded Programming
http://www.informationweek.com/news/showArticle.jhtml?articleID=201001607
Intel updates compilers for multicore era
http://arstechnica.com/news.ars/post/20070605-intel-updates-compilers-for-multicore-era.html
Sun Updates Studio For Multi-core Development
http://itmanagement.earthweb.com/entdev/article.php/3681151
Sun stresses multicore chips, Linux with dev tool
http://news.yahoo.com/s/infoworld/20070604/tc_infoworld/89028
Scots firm demonstrates parallelizing compiler at MPF
http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=199700792
recent posts on the subject:
https://www.garlic.com/~lynn/2007.html#3 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2007g.html#3 University rank of Computer Architecture
https://www.garlic.com/~lynn/2007i.html#20 Does anyone know of a documented case of VM being penetrated by hackers?
https://www.garlic.com/~lynn/2007i.html#78 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#15 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#19 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#24 Is Parallel Programming Just Too Hard?
https://www.garlic.com/~lynn/2007l.html#26 Is Parallel Programming Just Too Hard?
https://www.garlic.com/~lynn/2007l.html#34 Is Parallel Programming Just Too Hard?
https://www.garlic.com/~lynn/2007l.html#38 Is Parallel Programming Just Too Hard?
https://www.garlic.com/~lynn/2007l.html#42 My Dream PC -- Chip-Based
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Wed, 06 Jun 2007 13:23:30 -0600Peter Flass <Peter_Flass@Yahoo.com> writes:
when i did the cms page mapped file system on cp67 ... there was some
extra status bits available and i could play more games with in this
area ... but in the morph from cp67 to vm370 they used up available
status bits in the available status byte.
https://www.garlic.com/~lynn/submain.html#mmap
so i had to play some other kinds of status management.
in transition from mainframes to more personal computers ... the variety of "DASD" devices were reduced ... so there was possibly little or no discrepancy between the "best" paging device and the "worst" filesystem device.
early on i had done additional stuff in cp67 about moving "active" pages "UP" (from slower speed devices to higher speed devices) ... but it wasn't until the resource manager that I shipped code in the product that would also do the reverse (move less active pages from higher speed devices to slower speed devices) ... as well as better quantify what was met by "higher/better" and "slower/worse".
while the cms page mapped file system support didn't ship in standard product (outside lots of internal installations), i did ship it in the xt/370 & at/370 in the early to mid 80s ... where frequently the same (PC) harddisk was used for all activity (cms filesystem, cp paging, etc) ... over time there is less and less possible benefit from moving unmodified executable pages from one location to another location on disk.
also as relative sizes of real memory started to significantly increase ... compared to available disk space ... sometimes the alternative between "duplicate" and "no-duplicate" stategies could be come significant (i.e. reducing amount of disk space taken up by replicas of the same data).
misc. past posts mentioning "page migration"
https://www.garlic.com/~lynn/94.html#9 talk to your I/O cache
https://www.garlic.com/~lynn/94.html#49 Rethinking Virtual Memory
https://www.garlic.com/~lynn/95.html#12 slot chaining
https://www.garlic.com/~lynn/2000b.html#43 Migrating pages from a paging device (was Re: removal of paging device)
https://www.garlic.com/~lynn/2001e.html#45 VM/370 Resource Manager
https://www.garlic.com/~lynn/2003f.html#3 Alpha performance, why?
https://www.garlic.com/~lynn/2003f.html#5 Alpha performance, why?
https://www.garlic.com/~lynn/2003p.html#46 comp.arch classic: the 10-bit byte
https://www.garlic.com/~lynn/2004g.html#18 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004l.html#6 Xah Lee's Unixism
https://www.garlic.com/~lynn/2005n.html#21 Code density and performance?
https://www.garlic.com/~lynn/2006.html#19 DCSS as SWAP disk for z/Linux
https://www.garlic.com/~lynn/2006c.html#8 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006i.html#24 Virtual memory implementation in S/370
https://www.garlic.com/~lynn/2006i.html#41 virtual memory
https://www.garlic.com/~lynn/2006s.html#59 Why magnetic drums was/are worse than disks ?
https://www.garlic.com/~lynn/2006t.html#18 Why magnetic drums was/are worse than disks ?
https://www.garlic.com/~lynn/2006v.html#36 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006w.html#7 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2007.html#23 How to write a full-screen Rexx debugger?
https://www.garlic.com/~lynn/2007c.html#0 old discussion of disk controller chache
misc. past posts mentioning xt/370, at/370, washington, etc
https://www.garlic.com/~lynn/94.html#42 bloat
https://www.garlic.com/~lynn/96.html#23 Old IBM's
https://www.garlic.com/~lynn/2000.html#5 IBM XT/370 and AT/370 (was Re: Computer of the century)
https://www.garlic.com/~lynn/2000.html#29 Operating systems, guest and actual
https://www.garlic.com/~lynn/2000.html#75 Mainframe operating systems
https://www.garlic.com/~lynn/2000e.html#52 Why not an IBM zSeries workstation?
https://www.garlic.com/~lynn/2000e.html#55 Why not an IBM zSeries workstation?
https://www.garlic.com/~lynn/2001c.html#89 database (or b-tree) page sizes
https://www.garlic.com/~lynn/2001f.html#28 IBM's "VM for the PC" c.1984??
https://www.garlic.com/~lynn/2001i.html#19 Very CISC Instuctions (Was: why the machine word size ...)
https://www.garlic.com/~lynn/2001i.html#20 Very CISC Instuctions (Was: why the machine word size ...)
https://www.garlic.com/~lynn/2001k.html#24 HP Compaq merger, here we go again.
https://www.garlic.com/~lynn/2002b.html#43 IBM 5100 [Was: First DESKTOP Unix Box?]
https://www.garlic.com/~lynn/2002b.html#45 IBM 5100 [Was: First DESKTOP Unix Box?]
https://www.garlic.com/~lynn/2002d.html#4 IBM Mainframe at home
https://www.garlic.com/~lynn/2002f.html#44 Blade architectures
https://www.garlic.com/~lynn/2002f.html#49 Blade architectures
https://www.garlic.com/~lynn/2002f.html#50 Blade architectures
https://www.garlic.com/~lynn/2002f.html#52 Mainframes and "mini-computers"
https://www.garlic.com/~lynn/2002i.html#76 HONE was .. Hercules and System/390 - do we need it?
https://www.garlic.com/~lynn/2003f.html#8 Alpha performance, why?
https://www.garlic.com/~lynn/2003f.html#56 ECPS:VM DISPx instructions
https://www.garlic.com/~lynn/2003h.html#40 IBM system 370
https://www.garlic.com/~lynn/2004h.html#29 BLKSIZE question
https://www.garlic.com/~lynn/2004m.html#7 Whatever happened to IBM's VM PC software?
https://www.garlic.com/~lynn/2004m.html#10 Whatever happened to IBM's VM PC software?
https://www.garlic.com/~lynn/2004m.html#11 Whatever happened to IBM's VM PC software?
https://www.garlic.com/~lynn/2004m.html#13 Whatever happened to IBM's VM PC software?
https://www.garlic.com/~lynn/2004o.html#9 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2005f.html#6 Where should the type information be: in tags and descriptors
https://www.garlic.com/~lynn/2005f.html#10 Where should the type information be: in tags and descriptors
https://www.garlic.com/~lynn/2006.html#10 How to restore VMFPLC dumped files on z/VM V5.1
https://www.garlic.com/~lynn/2006f.html#2 using 3390 mod-9s
https://www.garlic.com/~lynn/2006j.html#36 The Pankian Metaphor
https://www.garlic.com/~lynn/2006m.html#56 DCSS
https://www.garlic.com/~lynn/2006n.html#5 Not Your Dad's Mainframe: Little Iron
https://www.garlic.com/~lynn/2006n.html#14 RCA Spectra 70/25: Another Mystery Computer?
https://www.garlic.com/~lynn/2006y.html#29 "The Elements of Programming Style"
https://www.garlic.com/~lynn/2006y.html#30 "The Elements of Programming Style"
https://www.garlic.com/~lynn/2007.html#1 "The Elements of Programming Style"
https://www.garlic.com/~lynn/2007c.html#14 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007c.html#23 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007d.html#7 Has anyone ever used self-modifying microcode? Would it even be useful?
https://www.garlic.com/~lynn/2007d.html#25 modern paging
https://www.garlic.com/~lynn/2007e.html#5 Is computer history taugh now?
https://www.garlic.com/~lynn/2007j.html#41 z/VM usability
misc. past posts mentioning dup/duplicate vis-a-vis no-dup/no-duplicate
allocation strategies
https://www.garlic.com/~lynn/93.html#12 managing large amounts of vm
https://www.garlic.com/~lynn/93.html#13 managing large amounts of vm
https://www.garlic.com/~lynn/94.html#9 talk to your I/O cache
https://www.garlic.com/~lynn/2000d.html#13 4341 was "Is a VAX a mainframe?"
https://www.garlic.com/~lynn/2001i.html#42 Question re: Size of Swap File
https://www.garlic.com/~lynn/2001l.html#55 mainframe question
https://www.garlic.com/~lynn/2001n.html#78 Swap partition no bigger than 128MB?????
https://www.garlic.com/~lynn/2002b.html#10 hollow files in unix filesystems?
https://www.garlic.com/~lynn/2002b.html#16 hollow files in unix filesystems?
https://www.garlic.com/~lynn/2002b.html#19 hollow files in unix filesystems?
https://www.garlic.com/~lynn/2002b.html#20 index searching
https://www.garlic.com/~lynn/2002e.html#11 What are some impressive page rates?
https://www.garlic.com/~lynn/2002f.html#20 Blade architectures
https://www.garlic.com/~lynn/2002f.html#26 Blade architectures
https://www.garlic.com/~lynn/2003f.html#5 Alpha performance, why?
https://www.garlic.com/~lynn/2003o.html#62 1teraflops cell processor possible?
https://www.garlic.com/~lynn/2004g.html#17 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004g.html#18 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004g.html#20 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004h.html#19 fast check for binary zeroes in memory
https://www.garlic.com/~lynn/2004i.html#1 Hard disk architecture: are outer cylinders still faster than inner cylinders?
https://www.garlic.com/~lynn/2005c.html#27 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005m.html#28 IBM's mini computers--lack thereof
https://www.garlic.com/~lynn/2006c.html#8 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006e.html#45 using 3390 mod-9s
https://www.garlic.com/~lynn/2006f.html#18 how much swap size did you take?
https://www.garlic.com/~lynn/2006i.html#41 virtual memory
https://www.garlic.com/~lynn/2006j.html#11 The Pankian Metaphor
https://www.garlic.com/~lynn/2007c.html#0 old discussion of disk controller chache
https://www.garlic.com/~lynn/2007e.html#60 FBA rant
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Friday musings on the future of 3270 applications Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Wed, 06 Jun 2007 22:21:24 -0600patrick.okeefe@WAMU.NET (Patrick O'Keefe) writes:
As undergraduate at the univ, I had done TTY/ascii terminal support for
cp67 ... and attempted to make the 2702 do something that it couldn't
quite do. that somewhat prompted a univ. project to build our own clone
controller (originally using an Interdata/3). This was subsequently a
writeup ... blaming us (at least in part) for clone controller business
(interdata was subsequently bought by perkin-elmer and the box was sold
under PE logo well thru the 80s ... apparently with the same channel
interface card that was designed at the univ. in the 60s)
https://www.garlic.com/~lynn/submain.html#360pcm
the clone controller business was supposedly a major motivation behind
the future system project
https://www.garlic.com/~lynn/submain.html#futuresys
... recent FS reference/post (with some quotation by one of
the executives involved in FS)
https://www.garlic.com/~lynn/2007l.html#10 John W. Backus, 82, Fortran developer, dies
one might claim that when FS was killed, that SNA attempted to still meet some of the FS objectives with the PU4/PU5 interface for advanced terminal control infrastructure.
in the same time that SNA was starting, my wife co-authored peer-to-peer
networking (AWP39) ... that defined real networking ... rather than
complex terminal control. Possibly there was some amount of semantic
confusion lingered on because the term "SNA" contained the word
"network". Later, when my wife was con'ed into going to POK to be in
charge of loosely-coupled architecture, she created peer-coupled shared
data architecture (... and except for IMS hot-standby, didn't see a lot
of uptake until sysplex)
https://www.garlic.com/~lynn/submain.html#shareddata
she had lots of battles with the SNA organization over peer-coupled shared data ... eventually there was temporary truce with my wife being able to specify Peer-Coupled operation as long as it was within the walls of the same/single machine room (datacenter) ... but SNA was mandated if it "crossed" the walls of the machine room.
much later, APPN was specified in AWP164 and when there was an attempt to announce/release APPN, the SNA organization non-concurred (at the time, the person responsible for APPN and I reported to the same executive). The APPN announcement was escalated and eventually the announcement letter was carefully rewritten to not imply that APPN had any relationship at all to SNA.
misc. past posts mentioning AWP39 and/or AWP164:
https://www.garlic.com/~lynn/2004n.html#38 RS/6000 in Sysplex Environment
https://www.garlic.com/~lynn/2004p.html#31 IBM 3705 and UC.5
https://www.garlic.com/~lynn/2005p.html#8 EBCDIC to 6-bit and back
https://www.garlic.com/~lynn/2005p.html#15 DUMP Datasets and SMS
https://www.garlic.com/~lynn/2005p.html#17 DUMP Datasets and SMS
https://www.garlic.com/~lynn/2005q.html#27 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005u.html#23 Channel Distances
https://www.garlic.com/~lynn/2006h.html#52 Need Help defining an AS400 with an IP address to the mainframe
https://www.garlic.com/~lynn/2006j.html#31 virtual memory
https://www.garlic.com/~lynn/2006k.html#9 Arpa address
https://www.garlic.com/~lynn/2006k.html#21 Sending CONSOLE/SYSLOG To Off-Mainframe Server
https://www.garlic.com/~lynn/2006l.html#4 Google Architecture
https://www.garlic.com/~lynn/2006l.html#45 Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
https://www.garlic.com/~lynn/2006o.html#62 Greatest Software, System R
https://www.garlic.com/~lynn/2006r.html#4 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006r.html#9 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006t.html#36 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006u.html#28 Assembler question
https://www.garlic.com/~lynn/2006u.html#55 What's a mainframe?
https://www.garlic.com/~lynn/2007b.html#9 Mainframe vs. "Server" (Was Just another example of mainframe
https://www.garlic.com/~lynn/2007b.html#48 6400 impact printer
https://www.garlic.com/~lynn/2007b.html#49 6400 impact printer
https://www.garlic.com/~lynn/2007d.html#55 Is computer history taugh now?
https://www.garlic.com/~lynn/2007h.html#35 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#39 sizeof() was: The Perfect Computer - 36 bits?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Is Parallel Programming Just Too Hard? Newsgroups: bit.listserv.ibm-main,alt.folklore.computers To: <ibm-main@bama.ua.edu> Date: Thu, 07 Jun 2007 08:01:48 -0600ibm-main@ibm-main.lst (Shane) writes:
multi-threaded tends to be used in conjunction with tightly-coupled,
shared-memory multiprocessing (and the current buzzword
"multi-core"). lots of past posts mentioning shared-memory
multiprocessing and/or compare&swap instruction
https://www.garlic.com/~lynn/subtopic.html#smp
compare&swap instruction had been invented by Charlie (CAS are
Charlie's initials) at the science center ... working on fine-grain
multiprocessor locking for cp67
https://www.garlic.com/~lynn/subtopic.html#545tech
in order to get the instruction justified for 370, had to come up with
the description of its use in multi-threaded/multi-programming
operation, which was included (originally) in the (370) principles of
operation ... a more recent version
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr003/A.6?DT=20040504121320
parallel has been used in reference to both (tightly-coupled) multi-threaded operation, as well as loosely-coupled &/or cluster multiprocessing operation
misc. past posts mentioning doing high availability, cluster
multiprocessing product
https://www.garlic.com/~lynn/subtopic.html#hacmp
some old email references about working on cluster scale-up
https://www.garlic.com/~lynn/lhwemail.html#medusa
a couple old posts specifically about working on applying distributed
lock manager and cluster scale-up to parallel oracle
https://www.garlic.com/~lynn/95.html#13
https://www.garlic.com/~lynn/96.html#15
recent post mentioning my wife had been con'ed into going to POK to be
in charge of loosely-coupled architecture
https://www.garlic.com/~lynn/2007l.html#62 Friday musings on the future of 3270 applications
a lot of the "blades" stuff has been physical packaging originally done for (numerical intensive cluster) "GRIDs" (getting more & more computing into smaller and smaller footprint). some amount of GRID/blades are now being pitched into commercial sector. some of it isn't strictly loosely-coupled/cluster operation ... but it is also being used (frequently in combination with virtualization) for server consolidation.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Thu, 07 Jun 2007 15:10:35 -0600blmblm@myrealbox.com <blmblm@myrealbox.com> writes:
It becomes somewhat less meaningful in the context of a personal computer (when theoretically there is only a single individual).
another argument has to do with privilege escalation concept ... where doing more privileged operations requires re-authentication for each such operation (over and above initial individual authentication for session involving basic system access). part of countermeasure to privilege escalation (as used in attacker attempting to compromise a system) will involve multiple stages of privileges and/or compartmentalization (not necessarily strictly hierarchical).
for a little topic drift ... recent discussion trying to differentiate
authentication, authorization, identification, and identity
https://www.garlic.com/~lynn/aadsm27.htm#23 Identity resurges as debate topic
and plug for our merged security taxonomy and glossary (recently
prompting to update identity concepts) ... see authentication,
authorization, and identity in the initial "concepts" section
https://www.garlic.com/~lynn/index.html#glosnote
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: mainframe = superserver Newsgroups: bit.listserv.ibm-main Date: Thu, 07 Jun 2007 17:15:30 -0600jackadama writes:
mentioning that blades are also being sold into commercial market, frequently in combination with virtualization, for server consolidation
and another mention here ... in slightly older thread/post:
https://www.garlic.com/~lynn/2007h.html#2 The Mainframe in 10 Years
and mention in this thread
https://www.garlic.com/~lynn/2007k.html#22 Another "migration" from the mainframe
https://www.garlic.com/~lynn/2007k.html#23 Another "migration" from the mainframe
some references from above thread
CIO Challenge: Energy Efficiency
http://www.wallstreetandtech.com/showArticle.jhtml?articleID=192202377
IBM Unveils New Energy-Efficient Blades
http://www.hpcwire.com/hpc/1379801.html
IBM to focus on energy efficiency
http://www.bladewatch.com/2007/05/10/ibm-to-focus-on-energy-efficiency/
Blade innovations highlight energy efficiency opportunities
http://www.it-director.com/business/content.php?cid=9135
IBM defends blades' energy efficiency
http://green.itweek.co.uk/2006/10/ibm_defends_bla.html
IBM Data Center and Facilities Strategy Services - high density
computing data center readiness assessment
http://www-935.ibm.com/services/us/index.wss/offering/its/a1025605
Lots of Blade Server articles
http://www.eweek.com/category2/0,1874,1658862,00.asp
IBM Grid Computing Solutions - financial industry
http://www-03.ibm.com/grid/solutions/by_industry/financial.shtml
Grid Computing for Financial Services 2007
http://www.iqpc.com/cgi-bin/templates/genevent.html?topic=233&event=12603&
Grid computing: Accelerating the search for revenue and profit for financial markets
http://www-03.ibm.com/industries/financialservices/doc/content/landing/973028103.html
the previously mentioned scale-up activity was in large part about
physical packaging and issues like power and cooling
https://www.garlic.com/~lynn/lhwemail.html#medusa
but the server consolidation is now frequently blades/grid technology
in combination with virtualization .... curtesy of science center
from mid-60s, first with cp40 and then when 360/67 became available,
morphed into cp67 (precursor to vm370) ... misc past posts mentioning
science center
https://www.garlic.com/~lynn/subtopic.html#545tech
besides virtualization and virtual machines being invented at the
science center ... compare&swap instruction for
multi-thread/multi-processor was also invented at the science center
https://www.garlic.com/~lynn/subtopic.html#smp
and also GML (later morphed into sgml, html, xml, etc)
https://www.garlic.com/~lynn/submain.html#sgml
and most of the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet
which was also seen outside in deployments like bitnet and
earn
https://www.garlic.com/~lynn/subnetwork.html#bitnet
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: BAH's Point of View Newsgroups: alt.folklore.computers Date: Fri, 08 Jun 2007 01:08:39 -0600bv@wjv.com (Bill Vermillion) writes:
some past posts with similar references
https://www.garlic.com/~lynn/2000g.html#26 Who Owns the HyperLink?
https://www.garlic.com/~lynn/2002o.html#45 XML, AI, Cyc, psych, and literature
https://www.garlic.com/~lynn/2002o.html#47 XML, AI, Cyc, psych, and literature
https://www.garlic.com/~lynn/2003j.html#59 Ted Nelson, of Project Xanadu
https://www.garlic.com/~lynn/2005s.html#12 Flat Query
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: nouns and adjectives Newsgroups: alt.folklore.computers Date: Sat, 09 Jun 2007 04:22:20 -0600Morten Reistad <first@last.name> writes:
the (academic) csnet, bitnet, earn, etc from early 80s was much more
traditional networking of nodes. misc. posts mentioning bitnet/earn
https://www.garlic.com/~lynn/subnetwork.html#bitnet
in fact (at least) csnet and bitnet predate the 1/1/83 transition to
internetworking technology ... and the nsfnet backbone for operational
support for internetworking of networks wasn't until late 80s. earn
came after the 1/1/83 transition ... but was the bitnet expansion
to europe ... post
https://www.garlic.com/~lynn/2001h.html#65
with old email from person setting up EARN
https://www.garlic.com/~lynn/2001h.html#email840320
NSFNET "backbone" in the late 80s was the operational basis for the modern internet ... i.e. tcp/ip was technology basis with support for "internetworking" ... i.e. interconnection of networks ... as opposed to just the more straight forward networking of nodes.
my ietf index has some references in the "archeological" section
https://www.garlic.com/~lynn/rfcietf.htm
also lots of past posts mentioning various aspects of NSFNET backbone
https://www.garlic.com/~lynn/subnetwork.html#nsfnet
and old email related to some of the stuff leading up to NSFNET backbone
https://www.garlic.com/~lynn/lhwemail.html#nsfnet
as well as more general posts related to general internet
https://www.garlic.com/~lynn/subnetwork.html#internet
some of the stuff related to acceptable use policies of NSFNET backbone traffice was gov. funded, tax-free operation. however, there was a separate undercurrent of commercial interests. the commercial network & telco interests had significant amounts of unused capacity (including lots of "dark fiber" that had been going in all thru the 80s). They faced a significant chicken & egg situation ... they needed sufficient revenue flow to cover their fixed costs. Their revenue flow was based on usage charges. If they dropped their usage charges by a couple orders of magnitude to promote development of new, high bandwidth hungry applications, (to utilize the enormous unused capacity), there would be several yr transition period where income wouldn't cover their fixed costs (as the new high bandwidth applications evolved). So something like four times the NSF funded resources were contributed to NSFNET backbone (as paid for by NSF) by commercial interests (which presumably also came with tax write-off).
The result was that the commercial interests got something of a testbed incubator that would encourage the development of the new generation of bandwidth hungry applications ... but in a strictly limited environment w/o loosing a lot of their existing commercial revenue. Trying to grapple with this transition period was not a trivial thing ... trying to maintain sufficient revenue ... to cover very high fixed costs from a usage based fee paradigm ... while trying to transition to paradigm that would use a couple orders of magnitude more bandwidth (from 9.6k & 56k to 1.5m and higher). If you just cut all the fees per bit by two orders of magnitude, before the usage and bandwidth hungry applications had evolved ... the total revenue would drop by two orders of magnitude (at least for several yrs during transition period) ... which would be insufficient to cover fixed operating costs. However, w/o an environment where bandwidth was free or nearly free ... the new generation of bandwidth hungry applications wouldn't be likely to evolve.
The whole idea of commercial interests contributing significant resources to NSFNET backbone (on the order of four times the direct NSF funding) ... would be a non-permanent situation. As soon as the (NSFNET) "free" incubator had spawned the bandwidth hungry applications ... it would be possible for the commercial interests to start the transition of managing the usage price/bit transition to much higher bandwidth usage ... while still keeping total revenue such that it covered their high fixed operating costs.
Some of the somewhat unrelated silly stuff that went on in the late 80s and early 90s were some gov. mandates to eliminate the internet and move to OSI networking. The problem here was that OSI was a straight-forward networking of nodes paradigm from the 60s/70s. The whole idea behind the evolution of "internetworking" technology was the recognition that simple straight-forward networking paradigm wasn't going to be able to scale to spanning multiple networks and organizations. In that sense, the original arpanet and OSI were similar in being networking of nodes paradigm (aka any elimination of the internet and transition to OSI would have been reverything to the arpanet networking paradigm of the 70s ... aka lacking any technology or operational support for internetworking).
The 1/1/83 transition from arapnet networking technology to internetworking technology ... was the technology basis for the modern internet. It then required the NSFNET backbone to (also) evolve the operational issues supporting internetworking of networks. Then there was the transition in the early 90s evolving numerous of the business issues supporting internetworking of networks.
I would claim that the commercial interests in CIX weren't "battling" the NSFNET backbone ... since the NSFNET backbone had been so heavily subsidized/supported by the commercial interests. The transition from NSFNET backbone to commercial operation could be considered part of planned agenda from the start (but not something that the commercial interests had worked out how it was actually going to happen; kick it in motion and hopefully be able to ride out the turmoil).
One of the possible business issues ... was if the majority of the NSFNET backbone resources was contributed by commercial interests ... for which they got a tax writeoff, the tax writeoff might be compromized if it had commercial use. This was separate from the whole issue of providing the resources to NSFNET, and keeping it totally disjoint and separate ... so as to not impact their commercial revenue flow.
This is also separate from some of the other technology issues necessary
for the operations of a (NSFNET) backbone for interneworking networks
... we were heavily involved in backbone operations ... both deployed
technology on the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet
and dealing with many of the organizations that would become NSFNET
backbone participants. however, along the way, we got involved in some
internal politics and were prevented from bidding NSFNET backbone
... even tho we had heavy backing/lobbying from NSF and at one point an
NSF audit that claimed what we already had running was at least five yrs
ahead of all NSFNET backbone bids (to build something new). recent post
with lots of topic drift
https://www.garlic.com/~lynn/2007l.html#14 Superconductors and computing
and other posts including old email specifically on the topic
https://www.garlic.com/~lynn/2005d.html#13 Cerf and Kahn receive Turing award
https://www.garlic.com/~lynn/2006s.html#50 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006t.html#6 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006w.html#43 IBM sues maker of Intel-based Mainframe clones
https://www.garlic.com/~lynn/2007.html#19 NSFNET (long post warning)
https://www.garlic.com/~lynn/2007d.html#47 Is computer history taugh now?
for other topic drift ... the above referenced "EARN" email from 84 was
also inquiring about "computer conferencing". I had (also) been doing
some semi-automated stuff starting in the late 70s. There was a period
in the early 80s that it came to the attention of top corporate
executives that such stuff might be going on over the internal network
... and I somewhat got blameed for it. There was something of turmoil
during this period about how to treat this emerging new phenomena. One
of the results (again more topic drift) was that a researcher was paid
to study how I communicated ... they sat in the back of my office for
something like nine months and took notes on my conversations, and also
got logs of all my instant messages and copies of all my incoming and
outgoing email. Besides an internal research report ... the study was
also the basis for a stanford phd thesis and some number of papers and
books. some collected posts on computer conferencing ... with some
discussion of the subject
https://www.garlic.com/~lynn/subnetwork.html#cmc
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: nouns and adjectives Newsgroups: alt.folklore.computers Date: Sat, 09 Jun 2007 04:41:07 -0600re:
for other topic drift ... we were called in to consult with
a small client/server startup that wanted to do payment
operations on their server ... a couple references
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
they had this technology called SSL and were working on this thing
called a commerce server ... it is all now frequently referred to as
electronic commerce. this thing called a payment gateway was
developed and deployed
https://www.garlic.com/~lynn/subnetwork.html#gateway
which we periodically (also) claim to be the original "SOA".
it turns out that two of the people running the commerce
server effort, we had previously worked with on our ha/cmp product
https://www.garlic.com/~lynn/subtopic.html#hacmp
and were present at this meeting mentioned in these posts
https://www.garlic.com/~lynn/95.html#13
https://www.garlic.com/~lynn/96.html#15
now the entity to deploy the first commerce server and also provided
funding for a significant portion (possibly all?) of the commerce server
development effort ... was also one of the major backers and resource
contributors to the NSFNET backbone effort.
https://www.garlic.com/~lynn/subnetwork.html#nsfnet
aka they were (apparently) expecting that they would eventually benefit significantly more from the evolving bandwidth hungry applications ... than whatever they were providing in upfront funding.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: nouns and adjectives Newsgroups: alt.folklore.computers Date: Sat, 09 Jun 2007 05:34:06 -0600Anne & Lynn Wheeler <lynn@garlic.com> writes:
in part because we had T1 & higher-speed support deployed, we like to think that all our work with the players in NSFNET backbone activity led to the NSFNET backbone RFP specifying T1 link (rather than some much smaller multiple of 56kbit).
We weren't allowed to bid ... however the winning bid didn't actually install T1 links ... what they installed for the NSFNET backbone was T1 circuits .. and then used IDNX multiplexers to split the bandwidth and actually deployed 440kbit links.
then for NSFNET-II (upgrade to T3), for whatever reason, we were asked to be the red team for one of the bid responses ... possibly believing the blue team, with a couple dozen people from half dozen labs around the world would thoroughly trounce us. At the review, I presented first and then the blue team presented. Before 10 mins into the blue team presentation, the executive running the process, got up, pounded on the table and declared that he would lie down in front of a garbage truck before he would allow any but the blue team proposal to go forward (apparently it was too readily apparent that the blue team had failed to trounce us). At that time, my wife and I got up and left the room (as well as a couple others) ... as it happens the blue team proposal was winning bid for NSFNET-II (and we had much better technology/operation than winning bids for both NSFNET-I and NSFNET-II).
misc. past posts mentioning garbage truck comment
https://www.garlic.com/~lynn/2000d.html#77 Is Al Gore The Father of the Internet?^
https://www.garlic.com/~lynn/2005d.html#13 Cerf and Kahn receive Turing award
https://www.garlic.com/~lynn/2005u.html#53 OSI model and an interview
https://www.garlic.com/~lynn/2006e.html#38 The Pankian Metaphor
https://www.garlic.com/~lynn/2006u.html#56 Ranking of non-IBM mainframe builders?
other posts mentioning nsfnet
https://www.garlic.com/~lynn/subnetwork.html#nsfnet
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: nouns and adjectives Newsgroups: alt.folklore.computers Date: Sat, 09 Jun 2007 06:09:55 -0600re:
for total different "noun" drift ... the word identity; a couple days
ago, I got asked by one of the identity management players about
upgrading my merged security taxonomy and glossary
https://www.garlic.com/~lynn/index.html#glosnote
with a lot more stuff related to identity and various identity
activities. i also mentioned it in this recent long-winded post
https://www.garlic.com/~lynn/aadsm27.htm#23 identity resurges as a debate topic
so i plowed thru several sources and managed to integrate some stuff. part of the churn and swirl is that in the past, identity has been mostly associated with authentication ... and separate from authorization. a lot of the current churn appears to be around providing sufficient personal information that a relying party can make some sort of authorization decision (approve something, grant permissions, etc) about a total stranger.
something similar went on in the early 90s with x.509 identity certificates ... tending to grossly overload the identity certificates with lots of personal information ... so that a relying party might be able to make some autherization decision about a total stranger ... purely based on the contents of the certificate. this was straying from the more common use of identity as characteristic of authentication ... and moving way into the domain of authorization. (in addition to who are you, are you allowed/permitted to do something?)
part of the tension is also similar to events of the mid-90s when lots
of parties started to realize that x.509 identity certificates, grossly
overloaded with personal information, represented significant privacy
and liability issues ... which then resulted into retrenching to
relying-party-only certificates ... carrying little or no information
https://www.garlic.com/~lynn/subpubkey.html#rpo
i've tried to capture some of that sense (the difference in using
identity with respect to authentication
and authorization) in the additions to the merge security
taxonomy and glossary ... see concepts section
https://www.garlic.com/~lynn/secure.htm
some recent news articles some of the identity churn
Computer Expert Urges identity Verification Safeguards for Employee
Eligibility Systems
http://newswire.ascribe.org/cgi-bin/behold.pl?ascribeid=20070607.071237&tim
Who Are You? ID Purveyors to Collaborate
http://itmanagement.earthweb.com/article.php/3681961
Vendors Debate ID Protocols
http://www.pcworld.com/article/id,132613-c,unresolvedtechstandards/article.html
Who Are You? ID Purveyors to Collaborate
http://news.earthweb.com/security/article.php/3681941
Who Are You? ID Purveyors to Collaborate
http://www.internetnews.com/security/article.php/3681941
Who Are You? ID Purveyors to Collaborate
http://itmanagement.earthweb.com/secu/article.php/3681961
Vendors seek unity on identity protocols
http://newsvac.newsforge.com/newsvac/07/06/06/2011211.shtml
Vendors seek unity on identity protocols
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9023619
Vendors seek unity on identity protocols
http://www.infoworld.com/article/07/06/06/Vendors-seek-unity-on-identity-protocols_1.html
Vendors seek unity on identity protocols
http://www.networkworld.com/news/2007/070607-credit-card-thieves.html
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM 360 Model 20 Questions Newsgroups: alt.folklore.computers Date: Sat, 09 Jun 2007 16:13:18 -0600Quadibloc <jsavard@ecn.ab.ca> writes:
basically coming out of the os/360 heritage of "small" real memories there was extensive use of pointer-passing convention. in the transition to current descendants of os/360 ... that involved adding virtual memory ... to minimize any discontinuity ... it required all the standard "called" routines to be in the same address space as the (calling) application. even with the transition from SVS to MVS ... where each application got its own address space ... the 370 limitation of 24bit (16mbyte) virtual address space got to the point where some installations only had 2-3mbytes left for an application to run in ... i.e. the rest of each 16mbyte virtual address space was occupied by standard librarcies, operating system services, kernel image, etc.
coming out of the cancellation of future system project:
https://www.garlic.com/~lynn/submain.html#futuresys
there was crash program to turn out "811" architecture ... the general architecture defined 31-bit virtual address support as well as "program call" and "access registers". however, such a crash program was still going to take nearly a decade ... and so 3033 was sort of an intermediate (370) stop-gap effort. they did manage to fit in dual-address space mode into 3033 (sort of a subset of the more general access register stuff).
dual-address space was somewhat for semi-privileged system services (some of the services are somewhat analogous to demons) that reside in their own virtual address space. applications call them with pointer passing paradigm ... the kernel does virtual address space switch ... and now the subsystem service is sitting with a passed pointer to data in the original applications virtual address space. dual-address space support allows the subsystem service to simultaneously access both its own virtual address space as well as the calling application's virtual address space.
the later, more general "access register" and "program call" support allowed for a hardware defined table where the program call resulted in controlled changing of the virtual address space pointers by the program call (and program return) instruction (w/o having to pass thru kernel code) ... as well as expanding the number of simultaneous, concurrent different virtual address spaces that could be addressed.
a few past posts mentioning dual-address space, access register, and/or
program call
https://www.garlic.com/~lynn/2007g.html#39 Wylbur and Paging
https://www.garlic.com/~lynn/2007g.html#59 IBM to the PCM market(the sky is falling!!!the sky is falling!!)
https://www.garlic.com/~lynn/2007k.html#14 Some IBM 3033 information
https://www.garlic.com/~lynn/2007k.html#27 user level TCP implementation
https://www.garlic.com/~lynn/2007k.html#28 IBM 360 Model 20 Questions
