List of Archived Posts
2006 Newsgroup Postings (05/18 - 05/30)
- Passwords for bank sites - change or not?
- Hey! Keep Your Hands Out Of My Abstraction Layer!
- Hey! Keep Your Hands Out Of My Abstraction Layer!
- Arpa address
- Passwords for bank sites - change or not?
- Value of an old IBM PS/2 CL57 SX Laptop
- Hey! Keep Your Hands Out Of My Abstraction Layer!
- Impossible Database Design?
- Arpa address
- Arpa address
- Arpa address
- Hey! Keep Your Hands Out Of My Abstraction Layer!
- Arpa address
- The Pankian Metaphor
- The Pankian Metaphor
- Passwords for bank sites - change or not?
- Value of an old IBM PS/2 CL57 SX Laptop
- Hey! Keep Your Hands Out Of My Abstraction Layer!
- Value of an old IBM PS/2 CL57 SX Laptop
- Hey! Keep Your Hands Out Of My Abstraction Layer!
- Hey! Keep Your Hands Out Of My Abstraction Layer!
- Sending CONSOLE/SYSLOG To Off-Mainframe Server
- Encryption for Powerpoint?
- Value of an old IBM PS/2 CL57 SX Laptop
- Value of an old IBM PS/2 CL57 SX Laptop
- Can anythink kill x86-64?
- Value of an old IBM PS/2 CL57 SX Laptop
- PDP-1
- Hashes and Passwords
- PDP-1
- PDP-1
- PDP-1
- PDP-1
- Password Complexity
- PDP-1
- PDP-1
- PDP-1
- PDP-1
- PDP-1
- PDP-1
- Arpa address
- PDP-1
- Arpa address
- Arpa address
- virtual memory
- Hey! Keep Your Hands Out Of My Abstraction Layer!
- Keylogger resistance
- Hey! Keep Your Hands Out Of My Abstraction Layer!
- Hey! Keep Your Hands Out Of My Abstraction Layer!
- Value of an old IBM PS/2 CL57 SX Laptop
- TSO and more was: PDP-1
- other cp/cms history
- Keylogger resistance
- Hey! Keep Your Hands Out Of My Abstraction Layer!
- Hey! Keep Your Hands Out Of My Abstraction Layer!
- 5963 (computer grade dual triode) production dates?
- Hey! Keep Your Hands Out Of My Abstraction Layer!
- virtual memory
Passwords for bank sites - change or not?
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Passwords for bank sites - change or not?
Newsgroups: alt.computer.security
Date: Thu, 18 May 2006 19:41:06 -0600
TwistyCreek writes:
They're no more or less secure than anything else if mishandled, or
if the protocols are breakable. That's the big bitch about PIN
numbers these days, not writing them on the card. The hardware
that's supposedly secure is crackable, and whether or not you use a
4 digit PIN, your fingerprint, or a retinal scan combined with a 100
character random password is meaningless.
re:
http://www.garlic.com/~lynn/2006j.html#42 Passwords for bank sites - change or not?
http://www.garlic.com/~lynn/2006j.html#52 Passwords for bank sites - change or not?
from the three factor authentication model
http://www.garlic.com/~lynn/subintegrity.html#3factor
• something you have
• something you know
• something you are
the card is a something you have and the PIN is something
you know. the nominal assumption in multi-factor
authentication is that the different factors are subject to
different vulnerabilities.
however the well established skimming activity has been able to
harvest magstripe information (static data that supposedly represents
the card, something you have) and the PIN (static data
something you know) at the same time (at compromised and/or
counterfeit terminals or devices) ... invalidating assumption about
multi-factor authentication having independent vulnerabilities.
http://www.garlic.com/~lynn/subintegrity.html#harvest
some recent posts about yes card and recent chip&pin skimming:
http://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#21 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#25 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#26 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#39 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#41 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm23.htm#16 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm23.htm#17 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm23.htm#19 Petrol firm suspends chip-and-pin
http://www.garlic.com/~lynn/aadsm23.htm#20 Petrol firm suspends chip-and-pin
http://www.garlic.com/~lynn/aadsm23.htm#25 Petrol firm suspends chip-and-pin
http://www.garlic.com/~lynn/aadsm23.htm#26 Petrol firm suspends chip-and-pin
http://www.garlic.com/~lynn/aadsm23.htm#27 Chip-and-Pin terminals were replaced by "repairworkers"?
http://www.garlic.com/~lynn/aadsm23.htm#30 Petrol firm suspends chip-and-pin
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Hey! Keep Your Hands Out Of My Abstraction Layer!
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hey! Keep Your Hands Out Of My Abstraction Layer!
Newsgroups: sci.electronics.design,comp.dcom.lans.ethernet,comp.protocols.tcp-ip,alt.cellular.bluetooth,alt.internet.wireless
Date: Thu, 18 May 2006 20:23:42 -0600
"Wrolf" writes:
Why did TCP/IP win over OSI?
1) As I understand it, RFCs needed two interoperating implementations
before becoming standards. ISO standards were set first by well meaning
individuals, then implementations were attempted.
2) Many participants in OSI meetings were there to learn, not
contribute.
3) OSI standards were therefore pie in the sky - you only learned after
the standards were set that performance or reliability or other killer
problems had been baked in, or that there was an overwhelmingly simpler
way that any successful implementation would have uncovered.
4) The 7 layer model proved too complex, leading to many inefficiencies
and complexities (including multiple buffer to buffer copies).
there were also organization issues ... ISO had a "rule" that you
couldn't have standards work on protocols that didn't confirm to the
osi model.
we had taken high-speed protocol proposal to x3s3.3 (ansi iso
chartered body repsonible for networking and transport layer). it
would go directly from transport to mac ... including support for
internetworking. it was rejected because
1) lan mac interface sits in the middle of layer 3, going directly
from transport to mac interface violated osi model by bypassing
layer 3/4 interface.
2) osi has no provisions at all for supporting internetworking ... so
anything that supported internetworking violates osi model
3) lan mac interface in the middle of layer 3 violates osi model,
so anything that interfaces to lan mac violates osi model.
http://www.garlic.com/~lynn/subnetwork.html#xtphsp
in some sense, osi was similar/analogous to the arpanet,
pre-internetworking ... having relatively homogeneous operation w/o
gateway and internetworking support.
i've frequently asserted that the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet
was larger than the arpanet/internet (from just about the beginning
until possibly mid-85) because the internal network had a kind of
gateway support in every node ... which arpanet didn't get until the
great switch-over to internetworking on 1/1/83.
misc. recent postings on the subject:
http://www.garlic.com/~lynn/2006i.html#17 blast from the past on reliable communication
http://www.garlic.com/~lynn/2006j.html#34 Arpa address
http://www.garlic.com/~lynn/2006j.html#45 Arpa address
http://www.garlic.com/~lynn/2006j.html#46 Arpa address
http://www.garlic.com/~lynn/2006j.html#49 Arpa address
http://www.garlic.com/~lynn/2006j.html#50 Arpa address
http://www.garlic.com/~lynn/2006j.html#53 Arpa address
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Hey! Keep Your Hands Out Of My Abstraction Layer!
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hey! Keep Your Hands Out Of My Abstraction Layer!
Newsgroups: sci.electronics.design,comp.dcom.lans.ethernet,comp.protocols.tcp-ip,alt.cellular.bluetooth,alt.internet.wireless
Date: Thu, 18 May 2006 22:12:30 -0600
"Wrolf" writes:
It is robust enough that HTTP/HTTPS just uses it without provoking any
need for further optimization. As does SMB/CIFS. NFS turned out to be
a big performance loser in WAN applications because the designers
decided to bypass TCP and use UDP - but only tuned it for LAN
applications, losing out on all the then current and future
optimizations.
tcp has minimum 7 packet exchange, vmtp (rfc1045) has minimum
5 packet exchange, xtp has 3 packet exchange for reliable
communication
http://www.garlic.com/~lynn/subnetwork.html#xtphsp
most tcp implementations assumed relatively few long running
sessions. http totally changed all that. as some of the webservers saw
increased load, some of them started finding 95+ plus processor cpu
being spent running FINWAIT list ... checking for dangling packets on
termination. it was crisis period for some webservers and required a
bit of rework to handle the situation.
we were called in to consult with this small client/server startup
that wanted to do payments on the server. we worked with them creating
and deploying a payment gateway and webservers communicating with the
payment gateway to do financial transactions
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
this small client/server startup had this technology called https.
the way that https was suppose to work for e-commerce was that the
client typed in a host name url. the browser contacted a the server.
the server returned a ssl domain name digital certificate. the
browser verified the digital certificate and then cross checked that
the domain name (in the url typed in by the user) is the same as the
domain name in the returned digital certificate. if they matched, then
there was some assurance that the webserver that the person thot they
were talking to ... was in fact the webserver they were talking
to. this was a countermeasure to webserver impersonation/spoofing.
so what happened? relatively quickly, webservers found that https
reduced their processing capacity by 80-90percent ... that webservers
could support to 5-6 times more load if they just used http instead of
https.
so webservers changed to use plain http for the shopping experience
and saved https for the checkout/pay experience. the webserver
provides a button to click for checkout/pay that invokes https.
the issue here is that the button now provides the url for invoking
the https process. now it means that the url domain name provided
in the button from the webserver is matched against the domain
name in the digital certificate provided by the webserver. misc
past posts on ssl certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert
the process was suppose to check that the domain name provided by the
user matches the domain name provided by the webserver digital
certificate. now the processes checks that the domain name provided by
the webserver matches the domain name in the digital certificate
provided by the webserver. if it were really a fraudulent webserver
... it would be an incompetent crook that wouldn't specify a domain
name in their checkout button that didn't correspond to the domain
name in the certificate they supply.
misc. postings discussing the change in SSL process negating the
original assumptions about what integrity was provided by SSL.
http://www.garlic.com/~lynn/aadsm19.htm#26 Trojan horse attack involving many major Israeli companies, executives
http://www.garlic.com/~lynn/aadsm20.htm#6 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#9 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#31 The summer of PKI love
http://www.garlic.com/~lynn/aadsm21.htm#22 Broken SSL domain name trust model
http://www.garlic.com/~lynn/aadsm21.htm#36 browser vendors and CAs agreeing on high-assurance certificates
http://www.garlic.com/~lynn/aadsm21.htm#39 X.509 / PKI, PGP, and IBE Secure Email Technologies
http://www.garlic.com/~lynn/aadsm21.htm#40 X.509 / PKI, PGP, and IBE Secure Email Technologies
http://www.garlic.com/~lynn/2003n.html#10 Cracking SSL
http://www.garlic.com/~lynn/2005m.html#0 simple question about certificate chains
http://www.garlic.com/~lynn/2005m.html#18 S/MIME Certificates from External CA
http://www.garlic.com/~lynn/2005o.html#41 Certificate Authority of a secured P2P network
http://www.garlic.com/~lynn/2005u.html#20 AMD to leave x86 behind?
http://www.garlic.com/~lynn/2006f.html#33 X.509 and ssh
http://www.garlic.com/~lynn/2006h.html#34 The Pankian Metaphor
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Arpa address
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Arpa address
Newsgroups: alt.folklore.computers
Date: Thu, 18 May 2006 23:08:50 -0600
ref:
http://www.garlic.com/~lynn/2006j.html#49 Arpa address
from
http://www.garlic.com/~lynn/internet.htm#0
CSNET (Computer Science NETwork) is funded by NSF, and is an attempt
to connect all computer science research institutions in the U.S. It
does not have a physical network of its own, but rather is a set of
common protocols used on top of the ARPANET (Department of Defense),
TeleNet (GTE), and PhoneNet (the regular phone system). The
lowest-cost entry is through PhoneNet, which only requires the
addition of a modem to an existing computer system. PhoneNet offers
only message transfer (off-line, queued, files). TeleNet and ARPANET
in allow higher-speed connections and on-line network capabilities
such as remote file lookup and transfer on-line, and remote login.
... snip ...
from
http://www.garlic.com/~lynn/internet.htm#22
from the 83 file .... 1000 mainframes on the internal worldwide
network 6/10/83.
• Date Sent 6-14-83
• Node Connected Machine DIV WHERE OPERATOR
• To/How Type NUMBER
+ CPHVMCE * CPHVM1/9 4341/VM EMEA Copenhagen, Denmark
- CPHVMEC * CPHVM1/9 4341/VM EMEA Copenhagen, Denmark
• I have just received word that CPHVMEC, the 1000th node that
• appeared 6/10/83 was the incorrect node name due to some misunder-
• standing in Copenhagen. CPHVMCE is the correct name.
couple more samples from the 83 file
• Date Sent 7-29-83
• Node Connected Machine DIV WHERE OPERATOR
• To/How Type NUMBER
+ BPLVM * PKMFGVM/9 4341/VM DSD Brooklyn, N.Y. 8-868-2166
+ FRKVMPF1 * STFFE1/9 4341/VM CSD Franklin Lakes, NJ 8-731-3500
+ FUJVM1 * FDLVM1/4 3033/VM AFE Fujisawa, Japan
+ GBGMVSFE * GBGVMFE3/C GUEST/MVS FED Gaithersburg, Md. 8-372-5808
+ LAGVM5 * LAGM3/9 168/VM CPD La Gaude, France
+ LAGVM7 * LAGM1/9 3032/VM CPD La Gaude, France
+ MVDVM1 * BUEVM1/2 4341/VM AFE Montevideo,Uruguay 98-90-17
+ RALVMK * RALVMA/C 4341/VM CPD Raleigh, N.C. 8-441-7281
+ RALVMM * RALVS6/C 4341/VM CPD Raleigh, N.C. 8-227-4570
+ RALVMP * RALVM2/C 3081/VM CPD Raleigh, N.C. 8-442-3763
+ RCHVM1PD * RCHVM1/C 4341/VM SPD Rochester, Mn.
+ RCHVM2 * RCHVM1/C 4341/VM SPD Rochester, Mn.
+ RCHVM3 * RCHVM1/C 4341/VM SPD Rochester, Mn.
+ SJMMVS16 * SNJMAS2/9 4341/MVS GPD San Jose, Ca. 8-294-5103
+ SJMMVS17 * SNJMAS1/9 4341/MVS GPD San Jose, Ca. 8-276-6657
+ TUCVMJ * TUCVMI/5 148/VM GPD Tucson, Arizona 8-562-7100
+ TUCVMN1 * TUCVM2/C 4341/VM GPD Tucson, Arizona 8-562-6074
+ UITECVM1 * UITHON2/9 4341/VM EMEA Uithoorn, Netherlands
• Date Sent 12-15-83
• Node Connected Machine DIV WHERE OPERATOR
• To/How Type NUMBER
+ ADMVM2 * ADMVM1/9 4341/VM EMEA Amsterdam, Neth. 20-5133034
+ BOEVMN * BOEVM1/9 4361/VM SPD Boeblingen, Ger. 49-7031-16-3578
+ BRMVM1 * MTLVM1/9 4341/VM AFE Bromont, Canada 514-874-7871
+ DUBVM2 * RESPOND/4 3158/VM EMEA Dublin, Ireland 785344 x4324
+ ENDVMAS3 * ENDCMPVM/C 3081/VM GTD Endicott, N.Y. 8-252-2676
+ KGNVME * KGNVMN/C 3081/VM DSD Kingston, N.Y.
+ KISTAINS * KISTAVM/9 4341/VM EMEA Stockholm, Sweden
+ MDRVM2 * MDRVM1/9 3031/VM EMEA Madrid, Spain 34-1-4314000
+ MSPVMIC3 * MSPVMIC1/9 4341/VM FED Minneapolis, Minn. 8-653-2247
+ POKCAD1 * PKDPDVM/9 4341/VM NAD Poughkeepsie, N.Y. 8-253-6398
+ POKCAD2 * POKCAD1/C 4341/VM NAD Poughkeepsie, N.Y. 8-253-6398
+ SJEMAS5 * SNJMAS3/S 4341/MVS GPD San Jose, Ca. 8-276-6595
+ TOKVMSI2 * FDLVM1/9 3031/VM AFE Tokyo, Japan
... snip ...
and from
http://www.garlic.com/~lynn/2000e.html#18
Date: 30 Dec 1982 14:45:34 EST (Thursday)
From: Nancy Mimno <mimno@Bbn-Unix>
Subject: Notice of TCP/IP Transition on ARPANET
To: csnet-liaisons at Udel-Relay
Cc: mimno at Bbn-Unix
Via: Bbn-Unix; 30 Dec 82 16:07-EST
Via: Udel-Relay; 30 Dec 82 13:15-PDT
Via: Rand-Relay; 30 Dec 82 16:30-EST
ARPANET Transition 1 January 1983
Possible Service Disruption
---------------------------------
Dear Liaison,
As many of you may be aware, the ARPANET has been going through the
major transition of shifting the host-host level protocol from NCP
(Network Control Protocol/Program) to TCP-IP (Transmission Control
Protocol - Internet Protocol). These two host-host level protocols
are completely different and are incompatible. This transition has
been planned and carried out over the past several years, proceeding
from initial test implementations through parallel operation over the
last year, and culminating in a cutover to TCP-IP only 1 January
1983. DCA and DARPA have provided substantial support for TCP-IP
development throughout this period and are committed to the cutover
date.
The CSNET team has been doing all it can to facilitate its part in
this transition. The change to TCP-IP is complete for all the CSNET
host facilities that use the ARPANET: the CSNET relays at Delaware and
Rand, the CSNET Service Host and Name Server at Wisconsin, the CSNET
CIC at BBN, and the X.25 development system at Purdue. Some of these
systems have been using TCP-IP for quite a while, and therefore we
expect few problems. (Please note that we say "few", not "NO
problems"!) Mail between Phonenet sites should not be affected by the
ARPANET transition. However, mail between Phonenet sites and ARPANET
sites (other than the CSNET facilities noted above) may be disrupted.
The transition requires a major change in each of the more than 250
hosts on the ARPANET; as might be expected, not all hosts will be
ready on 1 January 1983. For CSNET, this means that disruption of
mail communication will likely result between Phonenet users and some
ARPANET users. Mail to/from some ARPANET hosts may be delayed; some
host mail service may be unreliable; some hosts may be completely
unreachable. Furthermore, for some ARPANET hosts this disruption may
last a long time, until their TCP-IP implementations are up and
working smoothly. While we cannot control the actions of ARPANET
hosts, please let us know if we can assist with problems, particularly
by clearing up any confusion. As always, we are <cic@csnet-sh>
or (617)497-2777.
Please pass this information on to your users.
Respectfully yours,
Nancy Mimno
CSNET CIC Liaison
... snip ...
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Passwords for bank sites - change or not?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Passwords for bank sites - change or not?
Newsgroups: alt.computer.security
Date: Fri, 19 May 2006 07:24:35 -0600
Jim Watt <jimwatt@aol.no_way> writes:
Its certainly about time a standard PC came with a smartcard reader
to add another layer of authentication. However simple passwords
are not enough for anything sensitive.
ref:
http://www.garlic.com/~lynn/2006j.html#42 Passwords for bank sites - change or not?
http://www.garlic.com/~lynn/2006j.html#52 Passwords for bank sites - change or not?
http://www.garlic.com/~lynn/2006k.html#0 Passwords for bank sites - change or not?
part of the issue is that static data authentication are vulnerable to
skimming/evesdropping/harvesting and replay attacks.
there is issue with just straight-forward hardware token interface.
this is one of the reasons for the EU FINREAD terminal specs.
http://www.garlic.com/~lynn/subintegrity.html#finread
it has been well recognized for a long time that PCs have a large
number of vulnerabilities. FINREAD terminal was to isolate with
relatively high integrity ... 1) the hardware token interface, 2) the
PIN-entry interface, and 3) the display interface (for transaction
authentication, was the value displayed for the transaction being
authenticated, really the value in the transaction being
authenticated).
this was attempt to minimize that a compromised PC (with
virus/trojans) being able to a) skim the PIN, b) perform interactions
with the token w/o the owners knowledge, c) display one set of values
for a transaction but perform a totally different transaction.
the x9a10 financial standards working group had been given the
requirement to preserve the integrity of the financial infrastructure
for all retail payments.
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959
one of the things done in resulting x9.59 financial standard was that
it provided for the "authenticating" environment for also
authenticating transactions ... i.e. the EU FINREAD standard call for
a special high-integrity terminal ... but w/o the terminal also
authenticating the transaction, there is no proof to the relying party
that a EU FINREAD terminal is being used for the transaction ... aka
the transaction might be done purely from the PC w/o a special
terminal or might be done with a counterfeit terminal. the transaction
is authenticated ... but the environment that the transaction is
performed in is also authenticated.
one of the other things that x9.59 did was recognize that current
infrastructure has overloaded the account number ... it is required to
be exposed for use in a large number of different processes ... but
can be sufficient information for a crook to perform a fraudulent
transaction. x9.59 defined that account numbers used for x9.59
transactions can't also be used in unauthenticated transactions. this
was a recognition that with the large number of business processes
requiring the account number to be exposed ... that even burying the
planet under miles of information hiding crypto ... it would be still
be impossible to prevent account number data breaches and account
number skimming.
there is also the issue that numerous studies have continued to find
that something like 70percent of breaches resulting in various kinds
of identity and account fraud have involved insiders. this somewhat
relates to my old post of security proportional to risk
http://www.garlic.com/~lynn/2001h.html#61
there are also a large variety of man-in-the-middle attacks against
session oriented protocols ... that to eliminate the possibility,
require that transactions are explicitly authenticated, in addition to
any session oriented authentication (aka authentication performed
separately and independent of explicitly authenticated actual
operations).
lots of past posts about exploits, vulnerabilities, attacks, and
fraud
http://www.garlic.com/~lynn/subintegrity.html#fraud
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Value of an old IBM PS/2 CL57 SX Laptop
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Value of an old IBM PS/2 CL57 SX Laptop
Newsgroups: alt.folklore.computers
Date: Fri, 19 May 2006 07:40:19 -0600
KR Williams writes:
Yes, this is called "check-21" and is coming to a supermarket near
you. Several retailers already scan checks then hand them back to
you. You will get an image of the check back, if your bank still
does such things. It doesn't add anything to the (in)security of
the pull system. It's always been the case that someone with your
bank routing information (the numbers you freely give to everyone on
the bottom of every check) can just reach in and help themselves.
This (check-21) is no worse.
e-check is variation which requires the transaction to be
authenticated, typically with digital signature.
the x9a10 financial standards working group was given the requirement
to preserve the integrity of the financial infrastructure for all
retail payments. this included all ... as in point-of-sale, internet,
face-to-face, non-face-to-face, as well as ach, check, debit, credit,
stored-value ... all.
part of x9.59 financial standard
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959
was to require that account numbers (including from micr off checks)
used in x9.59 transactions could not be used in non-authenticated
transactions. early in work on x9.59 standard it was recognized that
account numbers have been overloaded ... that they are required to be
exposed in a large number of different business processes and the
knowledge of the number is frequently sufficient for attackers to
perform fraudulent transactions. that you could bury the planet under
miles of information hiding cryptography and it still wouldn't be
possible to prevent account number leakage.
http://www.garlic.com/~lynn/subintegrity.html#harvest
a somewhat related, recent post
http://www.garlic.com/~lynn/2006k.html#4 Passwords for bank sites - change or not?
misc. collected posts on vulnerabilities, threats, exploits, fraud
http://www.garlic.com/~lynn/subintegrity.html#fraud
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Hey! Keep Your Hands Out Of My Abstraction Layer!
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hey! Keep Your Hands Out Of My Abstraction Layer!
Newsgroups: sci.electronics.design,comp.dcom.lans.ethernet,comp.protocols.tcp-ip,alt.cellular.bluetooth,alt.internet.wireless
Date: Fri, 19 May 2006 08:23:51 -0600
"Le Chaud Lapin" writes:
OSI, was more like a mood. I have never seen one line of OSI "code".
And trust me, I searched long and hard for it. When I read about OSI,
I get the feeling it was "designed" by people who actually knew what
they were talking about, but lost the ability to program computers
(read implement their vague vision) several decades earlier.
late 80s ... OSI was all the range ... possibly half the booths
at interop 88 had various osi implementations on dipslay.
misc. past posts mentioning interop 88
http://www.garlic.com/~lynn/subnetwork.html#interop88
the fed. gov. (as well as some number of organizations) was mandating
elimination of the internet and tcp/ip and moving everything to
osi. some of this can be seen in GOSIP .. misc. recent postings
mentioning gosip
http://www.garlic.com/~lynn/2006f.html#26 Old PCs--environmental hazard
http://www.garlic.com/~lynn/2006i.html#19 blast from the past on reliable communication
http://www.garlic.com/~lynn/2006i.html#20 blast from the past on reliable communication
http://www.garlic.com/~lynn/2006j.html#34 Arpa address
minor ref:
GOVERNMENT OPEN SYSTEMS INTERCONNECTION PROFILE (GOSIP)
The Federal Information Processing Standard (FIPS) describing the
Federal government's policy, including the DoD transition from TCP/IP
to ISO international protocols.
... snip ...
there have been some claims that OSI was primarily worked on by telco
oriented individuals reflecting the copper wire, point-to-point,
homogeneous service, enterprise/institutional oriented networks of the
60s and 70s.
there was no concept of cross organizational and/or internetworking
involving different and/or heterogeneous operations (aka instead some
sort of telco or other operation was provide a homogeneous service to
all its participants and/or subscribers). this is somewhat the 70s,
pre-internetworking (1/1/83) ARPANET design. the whole concept
of LANs and WANs also didn't exist.
ISO compounded the problem with rules about not considering
standardization of protocols that violated OSI. recent post
in this thread
http://www.garlic.com/~lynn/2006k.html#1 Hey! Keep Your Hands Out Of My Abstraction Layer!
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Impossible Database Design?
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Impossible Database Design?
Newsgroups: comp.databases.theory
Date: Fri, 19 May 2006 09:11:05 -0600
"David Cressey" writes:
Back in the 1980s, I used to teach database programming and design
in an industrial setting. The course was product specific, (DEC
Rdb/VMS), but many of the concepts were not. I used to use the
ariline reservation system as a classic example of why atomicity in
a transaction was important. In my example, if your transactions
can't be atomic, you can't prevent overbooking.
Then one time, I got someone as a student who had been on the SAABRE
project. He told me that they never did solve that poblem, but
management decided that it was a feature and not a bug! I don't
know whether I believe it, but it's an interesting fable anyway.
More to the point, back in that time frame, the number of fare
changes was about 10,000 per day. I expect it's much greater now.
recent post referencing rewriting major portion of one the airline
res. systems (about a decade ago)
http://www.garlic.com/~lynn/2006j.html#6 The Pankian Metaphor
part of the issue was the paradigm had been established in the 60s and
while things like scale-up had been done ... there hadn't really been
any re-examination of the various design decision trade-offs
established in the 60s ... and whether advances in technology might
result in making other kinds of design decision trade-offs.
lets say there are around half-million take-off/landings a day (flight
segments) and for round numbers there are 50 passengers per flight
segment ... so you could have on the order of 25million updates per
day (independent of changes in fares and schedules). that is besides
possibly similar number of inserts of new PNR records for reservations
and then similar number of deletes for old PNR records.
part of the issue is that there has been some amount of bookings where
the person is no-show. somewhat as a result there tends to be some
fine tuning of capacity planning attempting to get every seat filled,
despite some percentage of no-shows.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Arpa address
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Arpa address
Newsgroups: alt.folklore.computers
Date: Fri, 19 May 2006 10:09:02 -0600
eugene@cse.ucsc.edu (Eugene Miya) writes:
Lynn's problem in this is that he had access to fairly good resources in
his part of IBM. Other friends in IBM had to weigh net access for what
they did and didn't see the value of access.
IBM placed more value in cute demos and Lotus notes than what the
outside world which passed some of it away. Microsoft has learned from
some of this; some other firms have benefitted from IBM's bureaucracy.
I thot we were talking about events leading up to 1983 and the
size of the networks in 1983.
lotus was an 1995 purchase ... more than a decade later:
http://www.dbmsmag.com/fred9508.html
at one point there were supposedly well over 400k employees around the
world ... it would not be unusual that some employees in some places
of the world might have access to more resources than other employees
in the world. it probably also held true for various people from
around the world in universities, academia and other institutions.
re:
http://www.garlic.com/~lynn/2006k.html#3 Arpa address
http://www.garlic.com/~lynn/internet.htm#22
http://www.garlic.com/~lynn/99.html#112
however from even the little indication in the above frequently
referenced network nodes in 1983 ... it would appear that the
internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet
(frequently reposted from the above ...) show at least small
indication that one may conclude that the internal network had a
fairly extensive world-wide presence (not limited to a few score or
few hundred):
• Date Sent 6-14-83
• Node Connected Machine DIV WHERE OPERATOR
• To/How Type NUMBER
+ CPHVMCE * CPHVM1/9 4341/VM EMEA Copenhagen, Denmark
- CPHVMEC * CPHVM1/9 4341/VM EMEA Copenhagen, Denmark
• I have just received word that CPHVMEC, the 1000th node that
• appeared 6/10/83 was the incorrect node name due to some misunder-
• standing in Copenhagen. CPHVMCE is the correct name.
couple more samples from the 83 file
• Date Sent 7-29-83
• Node Connected Machine DIV WHERE OPERATOR
• To/How Type NUMBER
+ BPLVM * PKMFGVM/9 4341/VM DSD Brooklyn, N.Y. 8-868-2166
+ FRKVMPF1 * STFFE1/9 4341/VM CSD Franklin Lakes, NJ 8-731-3500
+ FUJVM1 * FDLVM1/4 3033/VM AFE Fujisawa, Japan
+ GBGMVSFE * GBGVMFE3/C GUEST/MVS FED Gaithersburg, Md. 8-372-5808
+ LAGVM5 * LAGM3/9 168/VM CPD La Gaude, France
+ LAGVM7 * LAGM1/9 3032/VM CPD La Gaude, France
+ MVDVM1 * BUEVM1/2 4341/VM AFE Montevideo,Uruguay 98-90-17
+ RALVMK * RALVMA/C 4341/VM CPD Raleigh, N.C. 8-441-7281
+ RALVMM * RALVS6/C 4341/VM CPD Raleigh, N.C. 8-227-4570
+ RALVMP * RALVM2/C 3081/VM CPD Raleigh, N.C. 8-442-3763
+ RCHVM1PD * RCHVM1/C 4341/VM SPD Rochester, Mn.
+ RCHVM2 * RCHVM1/C 4341/VM SPD Rochester, Mn.
+ RCHVM3 * RCHVM1/C 4341/VM SPD Rochester, Mn.
+ SJMMVS16 * SNJMAS2/9 4341/MVS GPD San Jose, Ca. 8-294-5103
+ SJMMVS17 * SNJMAS1/9 4341/MVS GPD San Jose, Ca. 8-276-6657
+ TUCVMJ * TUCVMI/5 148/VM GPD Tucson, Arizona 8-562-7100
+ TUCVMN1 * TUCVM2/C 4341/VM GPD Tucson, Arizona 8-562-6074
+ UITECVM1 * UITHON2/9 4341/VM EMEA Uithoorn, Netherlands
• Date Sent 12-15-83
• Node Connected Machine DIV WHERE OPERATOR
• To/How Type NUMBER
+ ADMVM2 * ADMVM1/9 4341/VM EMEA Amsterdam, Neth. 20-5133034
+ BOEVMN * BOEVM1/9 4361/VM SPD Boeblingen, Ger. 49-7031-16-3578
+ BRMVM1 * MTLVM1/9 4341/VM AFE Bromont, Canada 514-874-7871
+ DUBVM2 * RESPOND/4 3158/VM EMEA Dublin, Ireland 785344 x4324
+ ENDVMAS3 * ENDCMPVM/C 3081/VM GTD Endicott, N.Y. 8-252-2676
+ KGNVME * KGNVMN/C 3081/VM DSD Kingston, N.Y.
+ KISTAINS * KISTAVM/9 4341/VM EMEA Stockholm, Sweden
+ MDRVM2 * MDRVM1/9 3031/VM EMEA Madrid, Spain 34-1-4314000
+ MSPVMIC3 * MSPVMIC1/9 4341/VM FED Minneapolis, Minn. 8-653-2247
+ POKCAD1 * PKDPDVM/9 4341/VM NAD Poughkeepsie, N.Y. 8-253-6398
+ POKCAD2 * POKCAD1/C 4341/VM NAD Poughkeepsie, N.Y. 8-253-6398
+ SJEMAS5 * SNJMAS3/S 4341/MVS GPD San Jose, Ca. 8-276-6595
+ TOKVMSI2 * FDLVM1/9 3031/VM AFE Tokyo, Japan
... snip ...
the following is a list of corporate locations that had one or more
new (mainframe) network nodes added during 1983:
Amsterdam, Neth. Marne LaValle, France
Atlanta, Georgia Mechanicsburg, Pa.
Austin, Texas Melbourne, Australia
Bangkok, Thailand Menlo Park, Ca.
Barcelona, Spain Milan, Italy
Bethesda, Md. Minneapolis, Minn.
Boca Raton, Florida Montevideo, Uruguay
Boeblingen, Ger. New York, N.Y.
Boigny, France Newton, Ma.
Bologna, Italy Nieder-Roden, Ger.
Bordeaux, France Novedrate, Italy
Boston, Mass. Owego, N.Y.
Boulder, Colorado Paris, France
Bromont, Canada Parvis de la Defense, France
Brooklyn, N.Y. Pisa, Italy
Burlington, Vermont Pittsburgh, Pa.
Cambridge, Ma. Portsmouth, U.K.
Charlotte, N.C. Poughkeepsie, NY
Chicago, Illinois Purchase, N.Y.
Cincinnati, Ohio Raleigh, N.C.
Cleveland, Ohio Reykjavik, Iceland
Copenhagen, Denmark Rio de Janeiro, Brazil
Cosham, U.K. Rochester, Minn.
Cranbury, N.J. Rochester, N.Y.
Dallas, Texas Rome, Italy
Dayton, N.J. Sainte-Marie, France
Detroit, Michigan San Francisco, Ca.
Diegem, Belgium San Jose, Ca.
Dublin, Ireland Santa Teresa, Ca.
Eastliegh, U.K. Seattle, Washington
Ecully, France Seoul, Korea
Endicott, N.Y. Sindelfingen, Ger.
Essen, Germany Singapore
Essonnes, France St. Louis, Mo.
Fishkill, N.Y. Stamford, Conn.
Frankfurt, Ger. Sterling Forest, NY
Franklin Lakes, NJ Stockholm, Sweden
Fujisawa, Japan Stuttgart, Ger.
Gaithersburg, Md. Sumare, Brazil
Greencastle, Indiana Sydney, Australia
Greenock, U.K. Tampa, Florida
Hannover, Germany Tokyo, Japan
Havant, U.K. Toronto, Canada
Herrenberg, Ger. Tucson, Arizona
Hursley, U.K. Uithoorn, Netherlands
Irving, Texas Valencia, Spain
Jakarta, Indonesia Vancouver, Canada
Johannesburg, South Africa Vienna, Austria
Kingston, N.Y. Vimercate, Italy
Kuala Lumpur, Malaysia Warwick, U.K.
La Gaude, France Wayne, Pa.
Lexington, Kentucky Wellington, New Zealand
Lisboa, Portugal West Berlin, Ger
Los Angeles, Ca. Westlake, Ca.
Madrid, Spain White Plains, N.Y.
Mahwah, N.J. Winchester, U.K.
Mainz, Ger. Yasu, Japan
Manassas, Va. Yorktown, N.Y.
Manilla Zurich, Switzerland
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Arpa address
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Arpa address
Newsgroups: alt.folklore.computers
Date: Fri, 19 May 2006 12:30:36 -0600
eugene@cse.ucsc.edu (Eugene Miya) writes:
Your talking about your perceptions as your then employer was
attempting to play catch up in a field of telecommunications. No
one doubts of late that IBM had more machines internally. Numbers
and tallys of are fine to a point. But it would be interesting to
know the numbers of DEC-10s and DEC-20s inside IBM on the VNET. The
number of ILLIAC IVs (that would be interesting if it were
non-zero), or other Burroughs machines, the number of Sigmas,
etc. etc. Just exactly how much how much market analysis was done
on these machines. That's heterogeneity.
Induction starts with a null hypothesis. The world knows ARPAnet's
was 1969. Somewhere between 1969 and 1983, someone in IBM got a
clue. This's a pinching argument.
But it all water under the bridge except for historians unless you
are going to claim IBM started networking. I think I can see a
factor of why Taylor is the way he is. It's sad that's an aspect of
this industry.
re:
http://www.garlic.com/~lynn/2006k.html#3 Arpa address
http://www.garlic.com/~lynn/2006k.html#8 Arpa address
cpremote was approximately 1970 between machines at the science
center. approx. 1971 vnet was used between science center and endicott
for distributed development project enhancing cp67 to provide virtual
"370" virtual machines (there were some number of new instructions
added to 370 architecture that had to be simulated and the hardware
virtual memory tables had different definitions).
in mid-70s there was new joint product announcement for vnet and
jes2/nje (vnet in addition to its own line drivers had a large
collection of line drivers to talk nje).
jes2/nje had a severe problem because jes2 managed network node
definitions using a one-byte index of 255 entries (that was already
being used to define jes2 psuedo devices, which typically might occupy
60 entires) ... and by the time of the joint vnet/jes2 announcement,
the internal network was well passed the limit of total nodes that
could be defined in a jes2 system. jes2 nodes on the internal network
had to be carefully managed ... also a jes2 feature was that it would
discard network traffic where either the origin node or the
destination node wasn't in its table definition. a new activity was
invented for managing jes2 network definitions ... managing the subset
of internal network node definitions that were critical for the users
of that system.
sometime after the internal network passed 1000 nodes, jes2 enhanced
their networking support to allow for defining up to 999 nodes ...
later, after the internal network had passed 2000 nodes, jes2 was
enhanced to support definition of 1999 nodes.
as i've frequently posted in the past, the corporate communication
group had started sna in the early 70s ... aka system network
architecture ... which was basically a large sophisticated terminal
controller infrastructure. it scaled up for large corporations and
institutions that had tens of thousands of dumb terminals (or things
controlled like dumb terminals ... atm cash machines, cable tv settop
boxes, etc, later institutions like airline res. system that might
have several hundred thousand terminals).
this wasn't "networking" ... it was communication control for large
numbers of dumb terminals (despite its label sna). the extensive use
of the term "networking" by the communication group ... forced other
organizations to start calling their stuff "peer-to-peer networking"
to differentiate it from the communication stuff that was called sna.
as in this recent posting, my wife somewhat ran afoul of the
communication group in that time-frame ... when she co-authored
"peer-to-peer networking" architecture (AWP39) with bert moldow (as a
real networking architecture).
http://www.garlic.com/~lynn/2006j.html#31 virtual memory
in the 80s, the communication group assisted in the rapid uptake of
PCs in corporate environments with terminal emulation ... dumb
corporate terminals, and their millions, could be upgraded to a PC
(the price of the dumb corporate terminals and PCs were approx. the
same) ... and for a single desktop footprint ... the person got a
display/keyboard that provided both access to corporate dataprocessing
and some local computing facilities.
in the late 80s, as client/server networking started to emerge ... the
communication group attempted to counter with "SAA" ... which attempted
to preserve as much as possible of the terminal emulation paradigm as
possible.
http://www.garlic.com/~lynn/subnetwork.html#emulation
in that time frame, my wife and I had come up with 3-tier networking
architecture and were out pitching it to corporate IT executives and
taking some amount of heat from the communication group (which wanted
to continue the terminal emulation paradigm and stave off any
progression to networking).
http://www.garlic.com/~lynn/subnetwork.html#3tier
I've asserted that one the reasons that the number of nodes on the
internet passed the number of nodes on the internal network sometime
mid-85 ... was that while the communication group couldn't prevent
the internal network ... they were able to do a lot to head-off being
able to treat workstations and PCs connected to the internal
mainframes as networking nodes (maintain their status as terminal
emulation) ... at a time when internet was seeing a big explosion in
workstations and PCs as networking nodes.
the following article lists cpremote as completed mid-69.
http://www.research.ibm.com/journal/sj/181/ibmsj1801H.pdf
it was then replaced with scnode ... followed by RSCS which was
subsequently announced and released as a product. The article mentions
that the internal network grew at a relatively constant rate of one
node a week through 1977 and then in 1978 the growth doubled to two
nodes a week.
another reference that discusses some of this ... cpremote,
rscs, vnet, rscs, etc.
http://www.princeton.edu/~melinda/25paper.ps
I don't know the number of DEC machines internally. I've been able to
post the information that I have access to. In the past, I've
posted the number of vax machines sold
http://www.garlic.com/~lynn/2002f.html#0 Computers in Science Fiction
and noted that in the late 70s and early 80s ... there were as many or
more 43xx machines sold as there were vax machines sold. there was
some sort of transition/threshold that happened in this period and you
saw corporate orders for several hundred 43xx machines at a time.
I've repeatedly and frequently posted both data that I have as well as
other references. To some extent the world knows about arpanet because
a lot of people made it their business to publish information about it
for one reason or another. During that period, there was little or no
public documents about the internal network ... in part because of the
communication group's effort to focus customers totally on their SNA
activity and terminal communication paradigm. in fact, the
communication group strongly objected to vnet being part of the joint
jes2/vnet networking announcement in the mid-70s (and had prevented it
from being announced earlier).
however, despite all the efforts by the communication group to put a
totally different face on "communication", "networking" and products
announced by the corporation for customer use ... that doesn't mean
that the internal network didn't exist. I conjecture that there are a
lot of things that go on within various institutions and
govs. ... that may not be public knowledge ... but just because it
isn't public knowledge ... doesn't mean that it didn't happen.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Arpa address
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Arpa address
Newsgroups: alt.folklore.computers
Date: Fri, 19 May 2006 14:35:09 -0600
Anne & Lynn Wheeler writes:
in mid-70s there was new joint product announcement for vnet and
jes2/nje (vnet in addition to its own line drivers had a large
collection of line drivers to talk nje).
re:
http://www.garlic.com/~lynn/2006k.html#3 Arpa address
http://www.garlic.com/~lynn/2006k.html#8 Arpa address
http://www.garlic.com/~lynn/2006k.html#9 Arpa address
some number of homogeneous operations also tend to have lots of
stories about scheduled shutdown of the service while all components
in the infrastructure are synchronously upgraded ... like the big
1/1/83 conversion for arpanet.
http://www.garlic.com/~lynn/2000e.html#18
http://www.garlic.com/~lynn/2006k.html#3 Arpa address
sna and jes2 folklore has huge number of such stories.
jes2 was particularly senstive to homogeneous operation ... minor jes2
release changes would result in incompatible network communication
between otherwise identical jes2 systems. the jes2 homogeneous
operation even went so far that relatively minor jes2 release
incompatibilities could precipitate the failure of a jes2 operation,
including bringing down the related mvs operating system.
this problem became so bad on the internal network that the
heterogeneous rscs/vnet support was enlisted to compensate for the
homogeneous jes2 operation requirement. not only was a large library
of jes2 nje drivers developed for vnet ... vnet was even enhanced to
recognize when two different incompatible jes2 systems were
attempting to communicate and do the necessary format conversion. this
eventually evolved in vnet essentially having a canonical
representation of jes2 format and converting to the specific format
needed by a directly connected jes2 operation (there is an early
infamous story about a jes2 software upgrade on a system in san jose,
ca. resulting in MVS system crashes in hursley, UK)
there are a large raft of similar customer stories about large SNA
installations ... where large number of different components would
have to be upgraded simultaneously ... i.e. shutting down the service
until all components have been upgraded ... as infrastructures got
larger and larger ... it was becoming less and less possible to
contain such a synchronous migration over even an extended weekend.
part of the vnet infrastructure was a kind of gateway mechanism that
allowed heterogeneous operation as well as the deployment of
incremental upgrades w/o having to syncronize such upgrades across the
whole infrastructure.
some misc. RFCs ... from my rfc index.
http://www.garlic.com/~lynn/rfcietff.htm
normally in frame's mode, the rfc summaries appear in the bottom
frame. it is possible to "click" on various fields, clicking
on ".txt=nnnn" retrieves the actual RFC
http://www.garlic.com/~lynn/rfcidx0.htm#101
101
Notes on the Network Working Group meeting, Urbana, Illinois,
February 17, 1971, Watson R., 1971/02/23 (14pp) (.txt=30343)
(Updated by 108)
... lists there being 15 IMPs as of 2/23/71 (although many in
purely test operation).
http://www.garlic.com/~lynn/rfcidx2.htm#638
638
IMP/TIP preventive maintenance schedule, McKenzie A., 1974/04/25
(4pp) (.txt=4088) (Obsoletes 633)
... this appears to imply that Tuesday mornings from 7am to 9am are
reserved for doing network software maintenance on all IMPs across the
whole infrastructure. In addition there is somewhat rolling hardware
maintenance schedule for different IMPs. This lists 45 IMPs as of
4/25/74. This RFC and several other RFCs imply that there was
synchronized software upgrades of all IMPs across the whole
infrastructure (implying a form of network infrastructure homogeneous
operation)
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Hey! Keep Your Hands Out Of My Abstraction Layer!
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hey! Keep Your Hands Out Of My Abstraction Layer!
Newsgroups: sci.electronics.design,comp.dcom.lans.ethernet,comp.protocols.tcp-ip,alt.cellular.bluetooth,alt.internet.wireless
Date: Fri, 19 May 2006 11:13:57 -0600
re:
http://www.garlic.com/~lynn/2006k.html#1 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#2 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#6 Hey! Keep Your Hands Out Of My Abstraction Layer!
... by the time ISO had passed OSI as a standard ... you had things
like LANs and internetworking ... making OSI obsolete (or at least
out-of-date). ISO then compounded the problem by dictating that only
OSI conforming protocols, could be standardized.
then in the late 80s, further compounding the problem, you have
various govs. and institutions mandating elimination of tcp/ip and the
internet ... replacing them with OSI.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Arpa address
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Arpa address
Newsgroups: alt.folklore.computers
Date: Fri, 19 May 2006 14:58:19 -0600
Anne & Lynn Wheeler writes:
some number of homogeneous operations also tend to have lots of
stories about scheduled shutdown of the service while all components
in the infrastructure are synchronously upgraded ... like the big
1/1/83 conversion for arpanet.
http://www.garlic.com/~lynn/2006k.html#3 Arpa address
and ...
http://www.garlic.com/~lynn/2000e.html#18
also part of extended post from above (email from two months after the
1/1/83 cutover date) ... note the final comment
MSG 0001 02/02/83 23:49:45
To: CSNET mailing list
Subject: CSNET headers, CSNET status
You may have noticed that since ARPANET switched to TCP/IP and the
new version of software on top of it, message headers have become
ridiculously long. Some of it is because of tracing information
that has been added to facilitate error isolation and "authentication",
and some of it I think is a bug (the relay adds a 'From' and a 'Date'
header although there already are headers with that information in
the message). This usually doesn't bother people on the ARPANET
because they have smart mail reading programs that understand the
headers and only display the relevant ones. I have proposed a
mail reader/sender program that understands about ARPANET headers
(RFC822) as a summer project, so maybe we will sometime enjoy the
same priviledge.
The file CSNET STATUS1 on the CSNET disk (see instructions below
for how to access it) contains some clarification of the problems
that have been experienced with the TCP/IP conversion. Here is a
summary:
- Nodes that don't yet talk TCP (but the old NCP) can be accessed
through the UDel-Relay. So if you think you have problems reaching
a node because of this, append @Udel-Relay to the ARPANET address.
- You can find out about the status of hosts (e.g., if they run
TCP or not) by sending ANY MESSAGE to Status@UDel-Relay (capitalization
is NOT significant).
- If your messages are undeliverable, you get a notice after two days,
and your messages get returned after 4 days.
- Avoid using any of the fancy address forms allowed by the new
header format (RFC822).
- The TCP transition was a lot more trouble than the ARPANET people had
anticipated.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
The Pankian Metaphor
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Pankian Metaphor
Newsgroups: alt.folklore.computers
Date: Fri, 19 May 2006 15:40:32 -0600
Eric Smith writes:
Why was there only 16MB of virtual address space? I thought the 360/67
hardware supported 32-bit addressing?
360/67 hardware had both 24-bit and 32-bit virtual address. cp67 for
virtual machines only provided 24-bit (virtual) address space
i.e. there wasn't a 360 hardware definition for 32-bit "real" address
... aka cp67 was using virtual memory hardware to simulate the real
hardware definition. in addition, cms was quite constrained by the
extensive borrowing of application code, compilers, etc from os/360
(which was built purely for 24-bit addressing).
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
The Pankian Metaphor
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Pankian Metaphor
Newsgroups: alt.folklore.computers
Date: Fri, 19 May 2006 16:57:30 -0600
Eric Smith writes:
That makes sense.
Did TSS/360 use or allow use of 32-bit addressing?
tss/360 enable 32-bit virtual addressing.
part of the issue in virtual machine operation ... was doing i/o. all
the 360 i/o operations were 24bit ... i.e. you couldn't do an i/o
operation into an address other than 24bit.
tss/360 provided 32-bit virtual addressing within a "real" 24-bit
machine (i.e. all i/o transfers, to/from disk, etc ... all involved
24-bit addressing api). you could operate within a 32-bit virtual
address space ... but when you went to actually do something
it was restricted to 24bit.
cp67 could provide a virtual machine for tss/360 to run in with 24-bit
... since the "real" machine that tss/360 ran in was 24-bit.
besides cms being constrained by heavy borrowing of software from
os/360 world ... its api for moving to/from filesystem was 24bit
inherited from the 360 "real" i/o infrastructure.
when i built page-mapped filesystem for cms, i went to a 32bit api
(actually slightly more than 32bit address since i used 32bit field to
specify 4k page numbers ... so theoritically it was 32bit+12bit
... 44bit api).
http://www.garlic.com/~lynn/submain.html#mmap
however, the rest of cms was heavily 24bit.
in the os/360 world, even after 370-xa and 31bit was introduced
... there was heavy use of dual-mode operation because of the enormous
amount of inherited 24-bit software.
general motors research was a big tss/360 32bit user on 360/67
... they claimed that they got enormous programmer productivity using
the tss/360 single level store model (large memory mapped files) in
32bit mode ... with the programmers not having to bother themselves
with a lot of file semantics found in many applications.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Passwords for bank sites - change or not?
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Passwords for bank sites - change or not?
Newsgroups: alt.computer.security
Date: Fri, 19 May 2006 19:24:24 -0600
Jim Watt <jimwatt@aol.no_way> writes:
However, its realistic guess a the number of unique passwords
one needs these days to get by. As previously stated the banking
systems do not rely on just a password. One of them even pops up
an onscreen keyboard to ensure keyloggers are by-passed.
re:
http://www.garlic.com/~lynn/2006k.html#0 Passwords for bank sites - change or not?
http://www.garlic.com/~lynn/2006k.html#4 Passwords for bank sites - change or not?
very shortly after some vendor announced the onscreen keyboard/pinpad,
there was an announcement that a keylogger had been discovered that
also logged screen mouse motions
again ... the whole area of pc vulnerabilities has been major
motivation behind the EU finread standard
http://www.garlic.com/~lynn/subintegrity.html#finread
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Value of an old IBM PS/2 CL57 SX Laptop
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Value of an old IBM PS/2 CL57 SX Laptop
Newsgroups: alt.folklore.computers
Date: Sat, 20 May 2006 08:41:15 -0600
jmfbahciv writes:
Sigh! If I were a crook, I'd get a job at AmEx or Walmart in
their bookkeeping dept. Bide my time. And then run their
check number/account data base through for $10/datum.
I can imagine emptying the virtual vaults of a single bank.
More importantly, I don't even have to be present when my
batch job fires up; I could use an /AFTER:1YEAR switch.
with all the stories about data breaches and security breaches
... various studies have continued to indicate that the majority of
account/identity fraud involve insiders.
in the early 80s you already having insider fraud countermeasures that
required multi-parties for doing sensitive operations. the response
then was collusion. you then were starting to have some amount of
collusion countermeasures.
the internet brought a lot of focus on outsiders. however, with
insiders still being responsible for the majority of fraud, the focus
on outsider threats, helps the insider attackers distract from the
source of the problem.
lots of collected posts on vulnerabilities, exploits, threats,
and fraud
http://www.garlic.com/~lynn/subintegrity.html#fraud
an old favorite on security proportional to risk (also mentioning
insider threat)
http://www.garlic.com/~lynn/2001h.html#61
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Hey! Keep Your Hands Out Of My Abstraction Layer!
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hey! Keep Your Hands Out Of My Abstraction Layer!
Newsgroups: sci.electronics.design,comp.dcom.lans.ethernet,comp.protocols.tcp-ip,alt.cellular.bluetooth,alt.internet.wireless
Date: Sat, 20 May 2006 09:18:55 -0600
"Wrolf" writes:
Agree with all your points.
TCP is not optimized for transaction type requests, with all the wasted
handshaking at the beginning and the end. The alternatives have not
been much good, and the current workaround is to keep the TCP
connection alive for multiple transactions, thus amortizing the initial
and final handshaking over many transactions (HTTP GETs).
However, this inefficiency has not led to an enhanced TCP with data in
the initial SYN packet, nor for the reply packet to be the final packet
for idempotent operations (GETs of static pages, if you don't get an
answer just ask again).
So keeping the connection alive was all that was needed, and TCP was
not modified.
As far as the SSL issues, they are independent of TCP.
re:
http://www.garlic.com/~lynn/2006k.html#2 Hey! Keep Your Hands Out Of My Abstraction Layer!
they aren't totally independent of transaction oriented philosophy.
if you had transaction oriented transport for both HTTP & HTTPS, then
you might have a transaction oriented HTTPS, if you had a purely
transaction oriented HTTPS, then you would have much less overhead.
in effect, the prevailing change to using HTTPS to encoupass the whole
session ... to just the checkout/pay portion ... is sort of treating
the checkout portion as a "large" transaction. However, that change
violated fundamental corner-stone of the whole HTTPS protection and
security scenario.
The point of the HTTPS hand-shaking was to prove that the webserver
the user thot it was talking to was the webserver that the user was
actually talking to. The security paradigm required that the
user/client supply who they thot they were talking to ... and the
webserver supply the proof that was who they were. posts about being
called in to work with this small client/server startup (who had this
technology called SSL) that wanted to do payment transactions
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
The change to the checkout/pay button resulted in the webserver
supplying who they were claiming to be ... as well as supply the proof
that they were who they were claiming to be. The fundamental
step-by-step dependent security process was violated.
so, there was VMTP (rfc 1045) that was transaction oriented and did
reliable message in 5 packet exchange. and there was XTP that did
reliable message in 3 packet exchange
http://www.garlic.com/~lynn/subnetwork.html#xtphsp
recent post in this thread
http://www.garlic.com/~lynn/2006k.html#1 Hey! Keep Your Hands Out Of My Abstraction Layer!
the fundamental cornerstone use of HTTPS in e-commerce is
1) to make sure you actually are sending the account number to the
entity that you think you are sending it to
2) to prevent evesdropping the account number while the transaction is
in-flight.
So the way that HTTPS is commingly used for e-commerce invalidates
#1. At it doesn't do anything to protect the account number before it
is sent or after it arrives (data-at-rest as opposed to
data-in-flight). in the past, there has been a lot of discussion that
data breaches of transaction logs harvesting millions of
account numbers has always been a much more attractive target than
evesdropping the net
http://www.garlic.com/~lynn/subintegrity.html#harvest
the x9a10 financial standard working group was given the requirement
to preserve the integrity of the financial infrastructure for all
retail payments. part of the early work on the x9.59 financial
standard was recognition that the account number was overloaded.
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959
on one hand, the account number is required to be generally available
for a large number of different business processes. on the other hand,
it was required to be kept totally confidential and never divulged in
any way. these diametrically opposing goals met that you could bury
the planet under miles of information hiding cryptography ... and
still wouldn't be able to prevent account number leakage.
so x9.59 financial standard defined a light weight payment transaction
that required end-to-end authentication (digital signature) and
furthermore a business rule that account numbers used in x9.59
transactions were not valid in non-authenticated transactions.
with those two things, account numbers (by themselves) became useless
to crooks. you could have enormous data breaches and evesdropping
activity and the crooks still wouldn't have harvested sufficient
information to perform a fraudulent transaction (the other way of
viewing the account number vulnerability is that it is subject to
simple replay attacks, the x9.59 standard definition eliminated the
replay attack vulnerability). misc. past posts vulnerability,
threat, exploits, and/or fraud
http://www.garlic.com/~lynn/subintegrity.html#fraud
so from that standpoint ... you could have an x9.59 financial
transaction riding XTP transaction transport ... w/o requiring the
account number to be hidden.
collected posts mentioning various ssl issues
http://www.garlic.com/~lynn/subpubkey.html#sslcert
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Value of an old IBM PS/2 CL57 SX Laptop
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Value of an old IBM PS/2 CL57 SX Laptop
Newsgroups: alt.folklore.computers
Date: Sat, 20 May 2006 09:40:46 -0600
re:
http://www.garlic.com/~lynn/2006k.html#16 Value of an old IBM PS/2 CL57 SX Laptop
slightly related post mentioning overloaded diametrically opposing
account number use requirements ... needing to be readily available
for a larger number of different business processes and at the same
time needing to be kept confidential and never divulged:
http://www.garlic.com/~lynn/2006k.html#17 Hey! Keep Your Hands Out Of My Abstraction Layer!
misc. past posts repeating line about burying the planet miles deep
in information hiding cryptography
http://www.garlic.com/~lynn/aadsm22.htm#36 Unforgeable Blinded Credentials
http://www.garlic.com/~lynn/aadsm23.htm#28 JIBC April 2006 - "Security Revisionism"
http://www.garlic.com/~lynn/2005k.html#26 More on garbage
http://www.garlic.com/~lynn/2005v.html#2 ABN Tape - Found
http://www.garlic.com/~lynn/2006e.html#26 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006e.html#44 Does the Data Protection Act of 2005 Make Sense
http://www.garlic.com/~lynn/2006h.html#15 Security
http://www.garlic.com/~lynn/2006k.html#4 Passwords for bank sites - change or not?
http://www.garlic.com/~lynn/2006k.html#5 Value of an old IBM PS/2 CL57 SX Laptop
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Hey! Keep Your Hands Out Of My Abstraction Layer!
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hey! Keep Your Hands Out Of My Abstraction Layer!
Newsgroups: sci.electronics.design,comp.dcom.lans.ethernet,comp.protocols.tcp-ip,alt.cellular.bluetooth,alt.internet.wireless
Date: Sat, 20 May 2006 10:23:59 -0600
Anne & Lynn Wheeler writes:
the fundamental cornerstone use of HTTPS in e-commerce is
1) to make sure you actually are sending the account number to the
entity that you think you are sending it to
2) to prevent evesdropping the account number while the transaction is
in-flight.
re:
http://www.garlic.com/~lynn/2006k.html#17 Hey! Keep Your Hands Out Of My Abstraction Layer!
so x9.59, beside meeting the requirement to preserve the integrity
of the financial infrastructure for all retail payments, we tried to
eliminate the attack scenarios against account numbers and also have
an extremely light-weight transaction that could be performed in a
single round-trip.
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959
possibly the prevailing use of HTTPS in the world today is still
hiding account numbers in e-commerce transactions. x9.59 eliminates
having to hide account numbers as a countermeasure to various
kinds of existing fraudulent transactions (minimizes even needing
HTTPS or other information hiding technologies for e-commerce
operations)
this is a couple of earlier postings that look at various SSL
and integrity issues
http://www.garlic.com/~lynn/2006h.html#27 confidence in CA
http://www.garlic.com/~lynn/2006h.html#28 confidence in CA
and suggests a process where the HTTPS objectives for e-commerce
(hiding and authentication) could be done in much the same manner that
mapping x9.59 to XTP process could be done i.e. transaction oriented
encrypting the contents of a XTP payload (or other extremely
light-weight oriented operation).
http://www.garlic.com/~lynn/subpubkey.html#certless
it also mentions some of the enormous payload bloating
approaches from the mid-90s.
earlier postings in this thread:
http://www.garlic.com/~lynn/2006j.html#51 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#1 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#2 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#6 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#11 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#17 Hey! Keep Your Hands Out Of My Abstraction Layer!
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Hey! Keep Your Hands Out Of My Abstraction Layer!
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hey! Keep Your Hands Out Of My Abstraction Layer!
Newsgroups: sci.electronics.design,comp.dcom.lans.ethernet,comp.protocols.tcp-ip,alt.cellular.bluetooth,alt.internet.wireless
Date: Sat, 20 May 2006 12:17:28 -0600
Anne & Lynn Wheeler writes:
it also mentions some of the enormous payload bloating approaches
from the mid-90s.
re:
http://www.garlic.com/~lynn/2006k.html#19 Hey! Keep Your Hands Out Of My Abstraction Layer!
starting possibly mid-90s, going forward for a time, appeared to be a
period leaning towards extreme extravagance; enormously complex
protocols (that few people understood) and humongous payload
bloat (in some cases by one hundred times or more), were
frequently viewed as being *better*.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Sending CONSOLE/SYSLOG To Off-Mainframe Server
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Sending CONSOLE/SYSLOG To Off-Mainframe Server
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 20 May 2006 15:25:44 -0600
Tom Schmidt wrote:
Either way I wouldn't mess with 3270 emulation at this point in SNA's
life. Let SNA face its ultimate end with some dignity.
we were periodically constantly fighting with the communications
group. the communications group had set up sna as communication
control of large number of terminals ... but they included "network"
in their label ... which had little or nothing to do with what it was
doing.
this somewhat forced other organizations to adapt nomenclature like
"peer-to-peer networking" to describe real networking and
differentiate it from sna. early in sna lifetime, my wife co-authored
peer-to-peer networking AWP39 architecture with Bert Moldow ... which
put them at odds with the communication organization.
she then got con'ed into going to POK to be in charge of loosely
coupled architecture (clusters by any other name) ... where she
created peer-coupled shared data architecture
http://www.garlic.com/~lynn/submain.html#shareddata
the communication group was constantly trying to carve off as their
turf any bits that left the processor complex ... even purely
processor-to-processor communication, creating lots of difficulties
for my wife. recent comment on one such involving 3088/trotter
http://www.garlic.com/~lynn/2006j.html#31 virtual memory
the communication group did contribute to early uptake of PCs with
terminal emulation ... for about the same price as a mainframe
terminal, a person could get a single desktop footprint (keyboard and
display) that did both mainframe connectivity and local computing.
however, in the late 80s, "peer-to-peer" networking and client/server
was emeging for PCs ... and the communication group was attempting
to counter it with SAA ... attempting to maintain as much as possible
the earlier terminal emulation paradigm
http://www.garlic.com/~lynn/subnetwork.html#emulation
it was in this period that we had created 3-tier architecture and were
out pitching it to customer executives
http://www.garlic.com/~lynn/subnetwork.html#3tier
and were taking a lot of heat from the communication group and SAA
forces.
during the 80s, the communication/sna group had also done things
like non-concurred with the announcement of APPN ... i.e. AWP164
... recent post mentioning APPN/AWP164 (as well as AWP39):
http://www.garlic.com/~lynn/2006h.html#52 Need Help defining an AS400 with an IP address to the mainframe
for a little drift, thread talking about the internal network (going
on in the same period as arpanet):
http://www.garlic.com/~lynn/2006j.html#53 Arpa address
http://www.garlic.com/~lynn/2006k.html#3 Arpa address
http://www.garlic.com/~lynn/2006k.html#8 Arpa address
http://www.garlic.com/~lynn/2006k.html#9 Arpa address
http://www.garlic.com/~lynn/2006k.html#10 Arpa address
Encryption for Powerpoint?
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Encryption for Powerpoint?
Newsgroups: sci.crypt
Date: Sat, 20 May 2006 17:20:44 -0600
Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:
We are talking about a Powerpoint presentation. No amount of DRM will
defeat a camcorder set up in the room.
somewhat after vendor announced a "screen" pin-pad (using mouse
clicks) as a countermeasure to keyloggers (somewhat targeted at online
banking or financial operations) ... there was some announcement of a
keylogger being found that also took screen shots and mouse motions.
there have been stories about people smuggling camcorders into special
screenings of new movies and within a very short period
... counterfeit DVDs showing up at various places around the world.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Value of an old IBM PS/2 CL57 SX Laptop
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Value of an old IBM PS/2 CL57 SX Laptop
Newsgroups: alt.folklore.computers
Date: Sun, 21 May 2006 08:54:28 -0600
jmfbahciv writes:
This is an impossibility. This is why I believe that this
has to remain a human work point, and not automated.
re:
http://www.garlic.com/~lynn/2006k.html#16 Value of an old IBM PS/2 CL57 SX Laptop
so we annalysed this when we started work on x9.59 in the mid-90s ...
and in the x9.59 financial standard, changed the paradigm.
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959
a crook with just the knowledge of an account number (used in x9.59
transactions) can no longer perform a fraudulent transaction.
the role of account number as some sort of authentication
shared-secret is eliminated,
http://www.garlic.com/~lynn/subintegrity.html#secret
overloading of the account number is eliminated and account number is
then used purely for business process operations. the millions of places
that account numbers are needed and readily available, no longer
represent sensitive operations that are also responsible for never
divulging the account number.
http://www.garlic.com/~lynn/subintegrity.html#harvest
this is also the point of my old security proportional to risk
posting
http://www.garlic.com/~lynn/2001h.html#61
... the business value of an account number (in all these processes)
may reprensent only a few dollars to a merchant ... but to the crook
(either insider or outsider) represents potential value equivalent to
the account credit limit. no only is their the impossibility of
simultaneously making the account number generally available for the
myriad of business process and at the same time keeping the account
number confidential and never divulging it ... but there is a
significant mismatch between the value of the account number to the
"defenders" and the value of the account number to the "attackers"
(and, in fact, studies find something like 70 percent of identity and
account theft incidents involve insiders).
for a little drift, the transaction card cost for some merchants, can
even be larger than the profit from the transaction, i.e. the value
that the transaction represents to the merchant:
http://www.garlic.com/~lynn/aadsm23.htm#37 3 of the big 4 - all doing payment systems
posted in the above:
http://www.csnews.com/csn/search/article_display.jsp?vnu_content_id=1002425619
from above
Fed up with out-of-control interchange fees, retailers are fighting
back with concerted legal and educational tactics -- and, in some
cases, proactive offensives of their own.
... snip ...
http://www.epaynews.com/newsletter/epaynews322.html
from above:
Convenience store operators can make more money on a 12-ounce cup of
coffee than they can on a 12-gallon tank of gas. Credit card fees now
account for almost half of a typical store's expenses - more than
labor.
... snip ..
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Value of an old IBM PS/2 CL57 SX Laptop
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Value of an old IBM PS/2 CL57 SX Laptop
Newsgroups: alt.folklore.computers
Date: Sun, 21 May 2006 09:00:59 -0600
jmfbahciv writes:
Our Congress critters at work again. They've forgotten the
mess made with S&Ls.
this posting goes into some detail regarding the savings and
load situation
http://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk Managment and Information security
basically, the reserve requirement had been something like 8percent,
the gov S&L gov. board cut this in half to something like 4percent
... and all of a sudden, approx. 4percent of total S&L deposits were
available for investment. there was no immediate vehicle to place such
a large influx of capital ... and so some innovative people on wall
street packaged up some products that could absorb the sudden, large
influx of capital.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Can anythink kill x86-64?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Can anythink kill x86-64?
Newsgroups: comp.arch,alt.folklore.computers
Date: Sun, 21 May 2006 12:35:00 -0600
Bernd Paysan writes:
There are also the smartphones. These become more and more general
purpose computers, because they need to play TV, browse the web, and
allow you to read and write e-mail.
Remember: What "killed" the IBM mainframe was the typewriter
department of IBM that sold IBM PCs rather than typewriters. So the
death of x86-64 is smaller boxes doing the work that's actually
needed, with less effort.
they sold IBM PCs in lieu of mainframe terminals (at about the same
price) ... as part of this, the communication group acquired a big
install base of terminal emulation products
http://www.garlic.com/~lynn/subnetwork.html#emulation
the millions of installed mainframe terminals could be upgraded with a
pc that cost about the same as the terminal ... and with a single
desktop footprint for display and keyboard ... provide both online
mainframe connectivity as well as some local computing capability.
with the spread of (peer-to-peer) networking and client/server, the
comminication group responded with all sorts of tactics ... including
SAA (late 80s) in an attempt to contain the migration away from
terminal emulation.
there was even an infamous internal world-wide networking
(actually communication) conference ... where a senior person from the
disk division gave a talk about how the communication group was going
to be responsible for the demise of the mainframe disk division. the
disk division had been coming up with all sorts of innovative
client/server solutions that provided high-speed/high-thruput access
to data on mainframe disk farms ... and they were constantly being
blocked by the communication group defending their install base of
terminal emulation products.
we had come up with 3-tier archtecture in the late 80s and were out
pitching it to customer executives ...
http://www.garlic.com/~lynn/subnetwork.html#3tier
and taking a lot of heat from the communication and SAA forces.
a couple recent posts on the subject:
http://www.garlic.com/~lynn/2006k.html#9 Arpa address
http://www.garlic.com/~lynn/2006k.html#21 Sending CONSOLE/SYSLOG To Off-Mainframe Server
at the other end ... starting in the early to mid-90s ... we started
running into problems with the smartcard forces. in the early 90s, we
had done some consulting with gov. labs attempting to move some
gov. smartcard technology out into the commercial market. what we saw
was technology that had evolved in the 70s & 80s to address a low-end
portable computing market niche. However, there wasn't portable
input/output technology in this market niche ... so you had a lot of
standardization work done for stationary input/output stations that
could interoperate with the smartcard products. however, what we saw
going into the mid-90s was the emergance of the portable input/output
technology in the form of PDAs and cellphones ... i.e. all other
things being equal would you prefer to have to find a stationary
input/output station to make use of your portable computing device ...
or would you prefer a portable computing device that had portable
input/output capability?
there had been billions of dollars poured into the smartcard
technology ... and various parties were out looking at some means of
recoverying at least some of the investment ... even if it was only
five cents on the dollar. however, some of the attempts at specific
market niches ... like financial transactions ... are also falling to
smartphone based payment operations.
in any case, when we started looking at various chip technologies for
"secure" operations in the mid-90s ... we assumed from the start that
it would need to be form factor agnostic.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Value of an old IBM PS/2 CL57 SX Laptop
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Value of an old IBM PS/2 CL57 SX Laptop
Newsgroups: alt.folklore.computers
Date: Sun, 21 May 2006 14:30:26 -0600
jmfbahciv writes:
I've thought about this. It will only work well when all people
start to do 'credit card' transactions. I estimate it's now about
60%, perhaps more. I will never, ever have a debit card account as
the rules stand now.
a couple related articles
ATM/Debit Cards: What consumers need to know about greater fraud risk,
card blocking, and debit card fees.
http://www.pirg.org/consumer/banks/debit/debitcards1.htm
from above:
Worse, unlike a credit card, under the law, your debit card liability
could be as much as $500, if you notify the bank more than 48 hours
after you learn of the problem or even up to all the money in your
checking account plus your maximum overdraft line of credit if you
fail to notify the bank within 60 days
... snip ...
ATTEMPTED CHECK FRAUD INCREASES TO $5.5 BILLION ACCORDING TO ABA SURVEY
http://www.aba.com/Press+Room/112204CHECKFRAUD.htm
a couple items from above:
• Reveal checking account information only to businesses you know to
be reputable.
• Shred or tear-up canceled checks and deposit slips before discarding
them.
... snip ...
Use a Pen, Not Your Pin?
http://biz.yahoo.com/kiplinger/060519/pf_v056_n009_u124_01001_id.html?.v=1
A Corporate Guide to Card Payments and the Role of Interchange
http://www.afponline.org/pub/store/pubs/ecgpay.html
Merchants' lawsuit could end credit-card rewards
http://www.mysanantonio.com/business/consumernews/stories/MYSA051906.01P.gas_card_end.1f6ef7b3.html
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
PDP-1
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PDP-1
Newsgroups: alt.folklore.computers
Date: Sun, 21 May 2006 18:22:08 -0600
David Scheidt writes:
I think it was inevitable that computing would progress from batch
to interactive use. The limits of what you can do with batch
processing were obvious. Once the underlying tech existed, it was
just a matter of time before someone figured out how to bend it the
way they wanted it. It might have been a year later, or five, but I
doubt much more than that.
a lot of the batch stuff was dataprocessing w/o having a human to
control it ..... besides running payroll and various other operations,
many of these platforms for used for various other kinds of controlled
operations ... like running hundreds of thousand of ATM machines
... or webservers.
one might even claim that it somewhat went the other way. a lot of
early computers had the programmer right there controlling the machine
(interactive).
"batch" was sort of extending the use of such machines via punch cards
... i.e. allowing people to use the machines with punch card
technology w/o actually having to be present when the punch cards were
processed.
when i was an undergraduate, i would to get the machine room from 8am
sat. to 8am monday. I had a 360/30 as an interactive personal computer
on the weekends ... it was mostly what people call a "batch" operating
system ... but it did have a 1052-7 keyboard that i had exclusive use
of.
During this period, time-sharing was somewhat synonomous with
interactive ... because the machines were normally too expensive to
dedicate for one person's exclusive interactive use (batch could also
be considered motivated by the same economics, attempting to improve
the utilization of an expensive resource)
small extract from Melinda's Virtual Machine history
http://www.princeton.edu/~melinda/25paper.pdf
Papers discussing the idea of a time-sharing system began being
published about 1959. There followed a period of experimentation at
MIT and other institutions. An early version of CTSS was demonstrated
on an IBM 709 at MIT in November, 1961. From that beginning, CTSS
evolved rapidly over the next several years and taught the world how
to do time-sharing.[5]. CTSS was developed on a series of IBM
processors. In the 1950s, IBM's president, T.J. Watson, Jr., had very
shrewdly given MIT an IBM 704 for use by MIT and other New England
schools.[6] Then, each time IBM built a newer, bigger processor, it
upgraded the system at MIT.[7] The 704 was followed by a 709, then by
a 7090, and finally by a 7094. IBM also gave MIT the services of some
highly skilled Systems Engineers and Customer Engineers, who formed
its MIT Liaison Office, which was housed at the MIT Computation
Center.
------------------------------------------------------------
[5] From the preface to the ``candy-striped manual'' (F.J. Corbato,
M.M. Daggett, R.C. Daley, R.J. Creasy, J.D. Hellwig, R.H. Orenstein,
and L.K. Korn, The Compatible Time-Sharing System: A Programmer's
Guide, The MIT Press, Cambridge, Mass., 1963):
The only other general purpose time-sharing system known to be
operating presently, that of the Bolt, Beranek and Newman Corporation
for the PDP-1 computer, was recently described by Professor John
McCarthy at the 1963 Spring Joint Computer Conference. Other
time-sharing developments are being made at the Carnegie Institute of
Technology with a G20 computer, at the University of California at
Berkeley with a 7090, at the Rand Corporation with Johnniac, and at
MIT (by Professor Dennis) with a PDP-1. Several systems resemble our
own in their logical organization; they include the independently
developed BBN system for the PDP-1, the recently initiated work at IBM
(by A. Kinslow) on the 7090 computer, and the plans of the System
Development Corporation with the Q32 computer.
... snip ...
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Hashes and Passwords
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hashes and Passwords
Newsgroups: alt.computer.security,comp.security,comp.security.misc
Date: Mon, 22 May 2006 06:37:47 -0600
"Dr Socrates" writes:
Instead of the password being sent in the clear, it would be better
to send a hash of the password. If the hash is obtained by a
malicious node, it is not going to be very useful since it is not
the actual password.
the issue is evesdropping static data transmitted and using it for
replay attack.
regardless of what it is called, if it is the same data (static) sent
each time ... and is compared against something; then it can be
evesdropped and replayed. whatever it is called being transmitted, if
it is always the same, then it can be evesdropped and replayed.
for a little drift, here is discussion of one-time-password hash
scheme ... based on hash being a one-way function, and the use of hash
iterations that decrements on each use. the server has to remember the
previous hash and the current hash iteration count . the server sends
the client one less than the current hash iteration count. the client
then does hash iterations for the indicated count and transmits that
value. the server hashes the received value and compares it with the
saved value. if correct, the server decrements the count by one and
saves the most recently transmitted value.
the issue here is that the same value/hash is not transmitted each
time ... so it supposedly is not subject to replay attack (and since
hash is one-way function, simple evesdropping can't predict the next
value.
however, the original claims were that the transmissions did not have
to hidden/encrypted (countermeasure to evesdropping) and/or require
the client to carry with them anything; supposedly usable in public
environment. it supposedly then is also immune to man-in-the-middle
attacks.
an attack is a man-in-the-middle substituting a much smaller iteration
count
http://www.garlic.com/~lynn/2003n.html#1 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003n.html#2 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003n.html#3 public key vs passwd authentication?
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
PDP-1
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PDP-1
Newsgroups: alt.folklore.computers
Date: Mon, 22 May 2006 08:08:37 -0600
Morten Reistad writes:
The PDPs were leaders, but they were not alone. They were perhaps
three years ahead of the curve from all the others in 1968.
CTSS/ITS/Multics were starting a bandwagon around 1971, and
microprocessors were starting to be available around 1976. If it
wasn't unix, then some other heir would have sprung up. The period
1969-1974 was also catch-up time for all the others.
Without the minis the mainframes may have lasted another 2-3 years,
and the transition to microprocessors would have been a lot more
brutal. Altos had multiprocessor solutions for MP/M in 1982, and
they were able to take at least as much load as the minis.
CP/M and MP/M show a pretty direct heritage from Tops10; msdos
has more of a generic feel.
In retrospect we probably would have had better systems today
without the extended mini period, called the "superminis" at the
time.
in late 68, university started a project to clone an ibm mainframe
controller ... reverse engineering the mainframe channel interface and
building a channel interface board for interdata/3 ... and programming
the interdata/3 to emulate the mainframe controller.
http://www.garlic.com/~lynn/subtopic.html#360pcm
Interdata was eventually bought by Perkin/Elmer. In the late 90s, I
ran into somebody at RSA conference in San Franciso, who mentioned
that he made a really good living in the early 80s selling the boxes
to NASA (and claimed that the mainframe channel interface board looked
like it had been designed in the 60s and never updated). In the same
time-frame I visited a major credit-card "acquiring" datacenter
(i.e. million or so of those merchant point-of-sale credit card
terminals connect into) ... where the incoming lines were being
handled by Perkin/Elmer ("interdata") boxes.
in june 68, a commercial company was formed to offer commerical
timesharing based on cp67 platform
http://www.garlic.com/~lynn/submain.html#timeshare
... technology based on virtual machine work at the science center on
the 4th flr of 545 tech sq
http://www.garlic.com/~lynn/subtopic.html#545tech
... multics was going on 5th flr of 545 tech sq.
fall of 68, a second commercial company was formed to offer commercial
timesharing based on cp67 platform.
start of 1969, boeing formed BCS (boeing computer services) with the
objective of moving all boeing data processing into BCS. During spring
break 69, I was con'ed into teaching a one week computer class to the
BCS technical staff. Then that summer they con'ed me into taking a job
as BCS management (i got badge that got me into the management parking
late at Boeing hdqtrs across from Boeing field). core of BCS
datacenter at corporate hdqtrs was cp67/cms system.
later in the early 70s, other companies like tymshare was using it (or
its follow-on vm370) to offer commercial time-sharing services.
here is reference to Gary Kildell using cp67/cms at NPG in '72
http://www.garlic.com/~lynn/2004e.html#38
various other time-sharing and cp67 history
http://www.princeton.edu/~melinda/25paper.ps
old post given super & superminis ... including numbers of superminis
as of 88
http://www.garlic.com/~lynn/2001b.html#56
old past given some overview of supercomputers, superminis, etc
in the late 80s and early 90s
http://www.garlic.com/~lynn/2001n.html#70
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
PDP-1
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PDP-1
Newsgroups: alt.folklore.computers
Date: Mon, 22 May 2006 08:21:17 -0600
Morten Reistad writes:
Both CTSS and Multics were decidedly ahead of their times. They
had per-user costs that were astronomical. ITS and unix were
"responses from the real world". It took until the eighties before
conversational systems were deployable in large organisations.
re:
http://www.garlic.com/~lynn/2006k.html#27 PDP-1
http://www.garlic.com/~lynn/2006k.html#29 PDP-1
early history of CTSS and some split with project going to Multics on
5th floor 545tech sq ... and others going to science center on 4th
floor 545tech sq
http://www.garlic.com/~lynn/subtopic.html#545tech
Melinda history covers a lot of detail of that period.
http://www.princeton.edu/~melinda/25paper.ps
cp40 was spawned and then morphed into cp67 when it was ported to
360/67 in 1967. cp67 was cost effective enuf that two commercial
companies were created in 1968 to offer commercial cp67 time-sharing
services. boeing offered internally as part of the formation of bcs
... and then cp67 (and change over to vm370) was used as basis of lot
of BCS outside consulting business in the 70s and 80s.
there were fairly large number of cp67 installations and even larger
number of installations of the cp67 followon, vm370.
one of the people at the science center that was involved using
cms\apl (and happened to be son of one of the people credited with
discoverying DNA) left the science center in the mid-70s and joined
BCS consulting service. He once commented that one of his consulting
projects at BCS was using apl\cms (followon to cms\apl) to do the
financial modeling for a contract with USPS justifying postage stamp
price increase.
a lot of the "personal computing" during the 70s were cp67/cms (and
then vm370/cms) based.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
PDP-1
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PDP-1
Newsgroups: alt.folklore.computers
Date: Mon, 22 May 2006 08:52:08 -0600
Morten Reistad writes:
Both CTSS and Multics were decidedly ahead of their times. They
had per-user costs that were astronomical. ITS and unix were
"responses from the real world". It took until the eighties before
conversational systems were deployable in large organisations.
re:
http://www.garlic.com/~lynn/2006k.html#27 PDP-1
http://www.garlic.com/~lynn/2006k.html#29 PDP-1
http://www.garlic.com/~lynn/2006k.html#30 PDP-1
oh and a large part of internal corporate computing was cp67/cms and
then vm370/cms based ... even development for some of the more
familiar batch, non-conversational systems; and of course it was also
the platform that provided the basis for the internal network in the
70s.
some recent posts:
http://www.garlic.com/~lynn/2006k.html#8 Arpa address
http://www.garlic.com/~lynn/2006k.html#9 Arpa address
http://www.garlic.com/~lynn/2006k.html#10 Arpa address
http://www.garlic.com/~lynn/2006k.html#12 Arpa address
for some slight drift mentioned in the above ... number of
vax shipments and 43xx shipping as many or more.
http://www.garlic.com/~lynn/2002f.html#0
from above:
NO. OF VAX
YEAR US NON-US TOTAL MODELS SHIPPED
--------- --------- --------- --------- --------------
1978 312 78 390 1
1979 627 313 940 1
1980 1,512 1,038 2,550 2
1981 1,979 1,726 3,705 2
1982 4,129 2,794 6,923 4
1983 6,178 4,384 10,562 5
1984 11,703 8,227 19,930 7
1985 17,600 7,300 24,900 8
1986 19,190 12,840 32,030 12
1987 21,780 15,485 37,265 12
-------- -------- --------
TOTAL 85,010 54,185 139,195
... snip ...
see the complete posting (including by model) at the referenced URL
... in the later years, much of the growth in vax shipments were due
to micro-vax.
i mentioned that in this time-frame there had been some
transition/threshold and you started see 43xx orders of multi-hundred
machines at a time (in the late 70s and early 80s). one example in
1981 was a chip manufacture that ordered nearly 1000 4341s in a single
order (although orders for 200-500 4341s at a time were more common).
here is old post about air force data center that had a multics
installation and in 1979 were looking at upgrading.
http://www.garlic.com/~lynn/2001m.html#15 departmental servers
and between spring of 1979 and fall of 1979 changed a twenty 4341
order to 210 4341s.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
PDP-1
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PDP-1
Newsgroups: alt.folklore.computers
Date: Mon, 22 May 2006 09:35:12 -0600
Morten Reistad writes:
Both CTSS and Multics were decidedly ahead of their times. They
had per-user costs that were astronomical. ITS and unix were
"responses from the real world". It took until the eighties before
conversational systems were deployable in large organisations.
oh, and here is multics history site
http://www.multicians.org/history.html
mentions commercial announcement 1/1973
multics air force data center, first install
11/73 ... grew to six systems
http://www.multicians.org/site-afdsc.html
reference to afdc ordering 210 4341s in 1979
http://www.garlic.com/~lynn/2006k.html#31 PDP-1
http://www.garlic.com/~lynn/2001m.html#15 departmental servers
as an aside, this was nearly as many machines as there were total
arpanet nodes on 1/1/83 ... slight drift:
http://www.garlic.com/~lynn/2006k.html#3 Arpa address
Melinda's history of work at the science center on 4th flr
545 tech sq. ... also mentions some of the CTSS activity
and Multics (on 5th flr, 545 tech sq)
http://www.princeton.edu/~melinda/25paper.ps
reference to cp67/cms
http://www.multicians.org/thvv/360-67.html
the above also mentions the two companies formed in 1968 to offer
cp67/cms commercial time-sharing services
http://www.garlic.com/~lynn/2006k.html#30 PDP-1
http://www.garlic.com/~lynn/submain.html#timeshare
multics site home page
http://www.multicians.org/multics.html
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Password Complexity
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Password Complexity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 22 May 2006 09:59:02 -0600
Tom Marchant wrote:
Ok, Ted, I'll bite again. As a matter of fact, some people DO embezzle.
the long held lore is that the majority of fraud involves insiders.
there have been some surveys published in the last couple years that
indicates that things haven't changed a lot in the internet era ...
that something like 70percent of identity/account theft has involved
insiders.
in fact, there is some conjecture that much of the preoccupation on the
internet and outsider attacks is benefit to the insiders responsible for
the majority of fraud.
at least by the early 80s, you were starting to see sensitive processes
requiring multi-person participation. the crooks responded with
collusion. you then started to see countermeasures for dealing with
multi-party collusion.
currently there still seems to be significant focus on outsider threats
and attacks, even tho all the indicators still maintain that the major
threats still are from insiders. for example, some number of the
auditing organizations have been participating in establishing
"PEN-test" standards (i.e. penetration testing as countermeasure to
outsider attacks).
PDP-1
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PDP-1
Newsgroups: alt.folklore.computers
Date: Mon, 22 May 2006 10:59:49 -0600
eugene@cse.ucsc.edu (Eugene Miya) writes:
I am amused that Lynn has not popped in to push TSO.
not TSO ... but cp67/cms :-)
http://www.garlic.com/~lynn/2006k.html#30
http://www.garlic.com/~lynn/2006k.html#31
http://www.garlic.com/~lynn/2006k.html#33
approx. 1974, cern presented a report at SHARE comparing CMS and TSO.
internally, the report got classified IBM CONFIDENTIAL RESTRICTED
(available on a need to know only basis) .... in part, they were
trying to minimize contamination of the carefully indoctrinated sales
and marketing people. this was somewhat difficult since even the major
online, interactive service supporting sales, marketing, and field
people was cp67/cms (subsequently upgraded to vm370/cms) based ...
called HONE
http://www.garlic.com/~lynn/subtopic.html#hone
however, most of the applications were (CMS) APL based and the service
was fairly carefully wrapped so not many sales/marketing/field people
realized that it was cms.
I got my first trip out of the country in the early 70s, when EMEA
hdqtrs moved from the US to la Defense outside of Paris ... and I was
called in to handle part of the new datacenter install. One of the
issues that I had at the time ... was figuring out the
telecommunication connection so I could read my email back in the
states (people take for granted being able to get to their email
almost anywhere in the world ... but it was a little more difficult
nearly 35 years ago)
a few past postings mentioning the cern cms/tso bakeoff
http://www.garlic.com/~lynn/2001f.html#49 any 70's era supercomputers that ran as slow as today's supercompu
http://www.garlic.com/~lynn/2002h.html#51 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2003h.html#19 Why did TCP become popular ?
http://www.garlic.com/~lynn/2003o.html#16 When nerds were nerds
http://www.garlic.com/~lynn/2005s.html#26 IEH/IEB/... names?
http://www.garlic.com/~lynn/2006d.html#35 Fw: Tax chooses dead language - Austalia
http://www.garlic.com/~lynn/2006d.html#38 Fw: Tax chooses dead language - Austalia
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
PDP-1
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PDP-1
Newsgroups: alt.folklore.computers
Date: Mon, 22 May 2006 12:07:06 -0600
Anne & Lynn Wheeler writes:
in june 68, a commercial company was formed to offer commerical
timesharing based on cp67 platform
http://www.garlic.com/~lynn/submain.html#timeshare
re:
http://www.garlic.com/~lynn/2006k.html#29 PDP-1
the first week in june '68, ibm hosted a one week class in hollywood
... classes were at the ibm site on wilshire ... and everybody stayed
at the beverely hills hotel. I was undergraduate and the univ.
sent me so i thot it was a lot of fun.
monday morning, ibm asked me if i would teach some of the cp
internals. it turned out that the lead cp kernel developer and the
person that was to teach cp internals had given notice the friday
before that he was leaving to help form this new cp67 time-sharing
service bureau company.
over the years they heavily extended their version of cp67 and
called it vp/css.
for even more drift ...
ramis from Mathematica Products Group in Princeton, New Jersey offered
exclusive on vp/css in 1969
http://www.decosta.com/Nomad/tales/history.html
ncss then did their own called "nomad" and the Mathematica Products
Group released "focus"
an unofficial nomad home page:
http://www.decosta.com/Nomad/
later there was a 370 clone vendor, two-pi. ncss branded and sold
120 or so two-pi machines with their branded version of cp67/cms (and
two-pi sold another 100 or so)
http://www.garlic.com/~lynn/2003i.html#15 two pi, four phase, 370 clone
i.e. ncss sold more of its own re-branded two-pi machines with its
own branded version of cp67/cms than the total number multics systems.
two-pi was acquired in 1981 by four-phase.
for other drift ... in the 70s, the original relational/sql was all
done on vm370 base on sjr .... called system/r
http://www.garlic.com/~lynn/submain.html#systemr
some past postings mentioning nomad, ramis, focus
http://www.garlic.com/~lynn/2002i.html#64 Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002i.html#69 Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002l.html#56 10 choices that were critical to the Net's success
http://www.garlic.com/~lynn/2003d.html#15 CA-RAMIS
http://www.garlic.com/~lynn/2003d.html#17 CA-RAMIS
http://www.garlic.com/~lynn/2003m.html#33 MAD Programming Language
http://www.garlic.com/~lynn/2003n.html#12 Dreaming About Redesigning SQL
http://www.garlic.com/~lynn/2003n.html#15 Dreaming About Redesigning SQL
http://www.garlic.com/~lynn/2004e.html#15 Pre-relational, post-relational, 1968 CODASYL "Survey of Data Base Systems"
http://www.garlic.com/~lynn/2004j.html#52 Losing colonies
http://www.garlic.com/~lynn/2004l.html#44 Shipwrecks
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
PDP-1
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PDP-1
Newsgroups: alt.folklore.computers
Date: Mon, 22 May 2006 13:55:09 -0600
Anne & Lynn Wheeler writes:
the first week in june '68, ibm hosted a one week class in hollywood
... classes were at the ibm site on wilshire ... and everybody stayed
at the beverely hills hotel. I was undergraduate and the univ.
sent me so i thot it was a lot of fun.
monday morning, ibm asked me if i would teach some of the cp
internals. it turned out that the lead cp kernel developer and the
person that was to teach cp internals had given notice the friday
before that he was leaving to help form this new cp67 time-sharing
service bureau company.
re:
http://www.garlic.com/~lynn/2006k.html#35 PDP-1
some more history of ncss and time-sharing
http://www.computerhistory.org/corphist/view.php?s=select&cid=4
http://www.computerhistory.org/corphist/view.php?s=themes&id=32
http://www.computerhistory.org/corphist/view.php?s=stories&id=162
... from