From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Mon, 23 Apr 2007 06:50:28 -0600jmfbahciv writes:
check21 is more about the physical transport of checks ... and issues related to not clearing until physical paper moved.
old folklore is that fed-ex got its start moving paper checks overnight ... large fleet of planes from all over the country with large loads of paper checks arrive in nashville late at night ... the bags of paper checks are run thru huge farms of check sorters ... put into other bags, rushed out to the planes which turn around and return.
past posts about check sorters
https://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#155 checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/2002.html#18 Infiniband's impact was Re: Intel's 64-bit strategy
https://www.garlic.com/~lynn/2002g.html#2 Computers in Science Fiction
https://www.garlic.com/~lynn/2006m.html#1 Large Computer Rescue
https://www.garlic.com/~lynn/2007e.html#28 Securing financial transactions a high priority for 2007
somebody once told me a similar, but different story about long ago, and far away, at warehouses all over the country ... where late at night a bunch of armored trucks pull into the bldg ... and all back up ... sort-of forming a "wagon circle" (with no gaps) ... and then the back doors open onto the circle ... and they all exchange bags of paper checks ... for each others (local) financial institution.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Linux: The Completely Fair Scheduler Newsgroups: alt.folklore.computers Date: Mon, 23 Apr 2007 07:22:07 -0600jmfbahciv writes:
you mean, as opposed to
https://www.garlic.com/~lynn/2007e.html#48 time spent/day on a computer
or the nsfnet stuff?
https://www.garlic.com/~lynn/lhwemail.html#nsfnet
https://www.garlic.com/~lynn/subnetwork.html#nsfnet
and
https://www.garlic.com/~lynn/2006w.html#21 SNA/VTAM for NSFNET
or the ha/medusa stuff?
https://www.garlic.com/~lynn/lhwemail.html#medusa
and
https://www.garlic.com/~lynn/2006x.html#3
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Linux: The Completely Fair Scheduler Newsgroups: alt.folklore.computers Date: Mon, 23 Apr 2007 07:36:47 -0600jmfbahciv writes:
then, of course, there is Boyd's line ...
https://www.garlic.com/~lynn/2007.html#20 MS to world: Stop sending money, we have enough - was Re: Most ... can't run Vista
https://www.garlic.com/~lynn/2007h.html#74 John W. Backus, 82, Fortran developer, dies
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Mon, 23 Apr 2007 10:03:26 -0600krw <krw@att.bizzzz> writes:
part of the issue is that F16 can significantly outperform F15 in most scenarios ... is significantly cheaper ... or have a lot more of them flying for the same cost ... not only in terms of planes for dollar ... but there is also a significant issue of the ratio of service/downtime hrs per flying hrs.
In the previous references (in this subthread), there were also some similar comments about the F18 in relationship to the F14 ... significant more planes per dollar cost ... and more flying hrs per service (downtime) hrs.
Then there was an attempt with the F20/tigershark ... to carry it to a whole new level ... in terms of planes per dollar, flying hrs per service/downtime hrs, as well as skill levels and parts to keep it flying (while sacrificing as little as possible vis-a-vis F16)
past posts mentioning f20/tigershark
https://www.garlic.com/~lynn/2002c.html#14 OS Workloads : Interactive etc
https://www.garlic.com/~lynn/2002d.html#1 OS Workloads : Interactive etc
https://www.garlic.com/~lynn/2005d.html#45 Thou shalt have no other gods before the ANSI C standard
of course, none of this matters if you have an infinite amount of money, an infinite number of planes, an infinite number of pilots, and an infinite number of service people with an infinite amount of training and spare parts.
other posts in the thread:
https://www.garlic.com/~lynn/2007h.html#68 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#69 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#70 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#71 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#72 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#75 John W. Backus, 82, Fortran developer, dies
past posts mentioning Boyd
https://www.garlic.com/~lynn/subboyd.html#boyd
various URLs from around the web mentioning Boyd
https://www.garlic.com/~lynn/subboyd.html#boyd2
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Mon, 23 Apr 2007 13:03:37 -0600kkt <kkt@zipcon.net> writes:
part of the problem was that the f15 wasn't really good at either ... as well as being extrodinarily expensive both to purchase and to maintain.
reference to f15 being retargeted as fighter/bomber from its
original role justified as multi-role fighter
http://www.aerospaceweb.org/aircraft/bomber/f15e/
above has F15 estimated cost at $43m
and f16
http://www.aerospaceweb.org/aircraft/fighter/f16/
above has F16 est. cost at $14m-$18m (can get three F16s for every F15) ... and comment "considered by many to be today's best all-round figher".
While Boyd significantly improved the F15 (from its starting design) ... he was able to start from scratch with F16.
previous posts
https://www.garlic.com/~lynn/2007h.html#73 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#74 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#3 John W. Backus, 82, Fortran developer, dies
this has much more detailed discussion about driving factors that
produced F16 (most of them from Boyd)
http://www.fas.org/man/dod-101/sys/ac/f-16.htm
from above (some reference to engine failure)
Northrop argued that its twin-engine design added an essential safety
factor, citing its experience with the small twin-engine F-5 fighter as
an example. USAF did not find this persuasive, in part because a two
engine plane with one engine out is useless in combat, and the
probability of an engine failure was nominally twice as high with two
engines as with one. The higher performance, better transient
maneuverability, longer range, and lower cost of the YF-16 carried the
day, and in 1976 the F-16 was chosen over the F-17.
USAF was then in the uncomfortable position of having a lightweight
fighter design that could outmaneuver and outrange its pride and joy,
the F-15 air superiority fighter. In real-world combat conditions, which
meant Mach 1.2 or below, the F-16s held a significant edge over the
F-15. To some extent this problem was solved by designating the F-16 as
a "swing fighter" to do both air-to-air and air-to-ground, while the
F-15 was to continue its aristocratic mission of pure air-to-air.
... snip ...
the above also goes into some of the design/implementation creap that
settled into F16 which might be taken as justification behind the
attempt to do a reset with the F20/tigershark
https://www.garlic.com/~lynn/2007i.html#3 John W. Backus, 82, Fortran developer, dies
other posts in this subthread:
https://www.garlic.com/~lynn/2007h.html#68 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#69 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#70 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#71 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#72 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#75 John W. Backus, 82, Fortran developer, dies
previous post with attempt to put some computer bent back into the
thread ... since much of boyd's work was based on complex (computer
aided) mathematical calculations
https://www.garlic.com/~lynn/2007h.html#75 John W. Backus, 82, Fortran developer, dies
this reference that discusses something more of Boyd's biographical
details
http://www.sci.fi/~fta/JohnBoyd.htm
does mention that in the middle of doing all this design stuff for F16
... he got tasked to spend a year in Thailand running the computing
center at "spook base". This was possibly one of the largest
datacenters in the world at the time ... since other biographies make
mention that it represented a $2.5b windfall for IBM. A few past posts
mentioning spook base:
https://www.garlic.com/~lynn/2005t.html#1 Dangerous Hardware
https://www.garlic.com/~lynn/2005t.html#2 Dangerous Hardware
https://www.garlic.com/~lynn/2005t.html#5 Dangerous Hardware
https://www.garlic.com/~lynn/2006u.html#51 Where can you get a Minor in Mainframe?
https://www.garlic.com/~lynn/2007g.html#13 The Perfect Computer - 36 bits?
past posts mentioning Boyd
https://www.garlic.com/~lynn/subboyd.html#boyd
various URLs from around the web mentioning Boyd
https://www.garlic.com/~lynn/subboyd.html#boyd2
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Mon, 23 Apr 2007 13:31:40 -0600krw <krw@att.bizzzz> writes:
as previous posts about mentioning LWF and Boyd running the program in
the pentagon ... he improved the F15 and then did F16 and lot of the
stuff for F18. The issue between the F15 and F16 wasn't just about
whether it was one engine or two ... it was what was the mission and you
then could throw out everything not needed for the mission (both the F16
compared to the F15 and the F18 compared to the F14).
https://www.garlic.com/~lynn/2007h.html#69 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#71 John W. Backus, 82, Fortran developer, dies
so you should be taking what was the mission profile for the F15/F16 and what did Boyd do ... versus mission profile for the F14/F18 and what did Boyd do.
other posts in this subthread:
https://www.garlic.com/~lynn/2007h.html#68 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#70 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#72 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#75 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#73 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#74 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#3 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#4 John W. Backus, 82, Fortran developer, dies
somewhat related is past post about KISS and simple can actually be more
difficult ... but quite a bit more effective ... than complex
https://www.garlic.com/~lynn/2007h.html#29 sizeof() was: The Perfect Computer - 36 bits
https://www.garlic.com/~lynn/2007h.html#30 sizeof() was: The Perfect Computer - 36 bits
I claimed something similar designing a hardware authentication token,
... somewhat facetiously claiming in the mid-90s that I was going to
take a $500 mil-spec part, aggresively cost reduce it by nearly three
orders of magnitude and at the same time making it more secure ... for
some topic drift ... past posts:
https://www.garlic.com/~lynn/aadsm13.htm#18 A challenge
https://www.garlic.com/~lynn/aadsm15.htm#6 x9.59
https://www.garlic.com/~lynn/aadsm21.htm#11 Payment Tokens
https://www.garlic.com/~lynn/aadsm21.htm#26 X.509 / PKI, PGP, and IBE Secure Email Technologies
https://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm23.htm#56 UK Detects Chip-And-PIN Security Flaw
https://www.garlic.com/~lynn/aadsm24.htm#23 Use of TPM chip for RNG?
https://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm26.htm#48 Governance of anonymous financial services
https://www.garlic.com/~lynn/2002n.html#18 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2004j.html#2 Authenticated Public Key Exchange without Digital Certificates?
https://www.garlic.com/~lynn/2005u.html#26 RSA SecurID product
https://www.garlic.com/~lynn/2005u.html#32 AMD to leave x86 behind?
some if it shows up here
https://www.garlic.com/~lynn/x959.html#aads
and in these patents (which we have no rights/interest)
https://www.garlic.com/~lynn/aadssummary.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Mon, 23 Apr 2007 13:47:07 -0600krw <krw@att.bizzzz> writes:
... and then where was Boyd spending some amount of his time when
F20/Tigershark was being done? I've claimed it was his attempt to
reset back to the original F16 design ... before all the
design/implementation creep mentioned in
https://www.garlic.com/~lynn/2007i.html#4 John W. Backus, 82, Fortran developer, dies
and
http://www.fas.org/man/dod-101/sys/ac/f-16.htm
started to show up.
Boyd had significant battles both inside and outside the gov. to pull off the F16 ... and I've claimed that he was involved in attempting to pull off something similar with F20/tigershark (being closer to his original f16 design).
other posts in this subthread:
https://www.garlic.com/~lynn/2007h.html#68 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#69 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#70 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#71 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#72 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#73 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#74 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#75 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#3 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#4 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#5 John W. Backus, 82, Fortran developer, dies
past posts mentioning Boyd
https://www.garlic.com/~lynn/subboyd.html#boyd
various URLs from around the web mentioning Boyd
https://www.garlic.com/~lynn/subboyd.html#boyd2
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Mon, 23 Apr 2007 14:24:08 -0600Anne & Lynn Wheeler <lynn@garlic.com> writes:
and reference here
The US Combat Aircraft Industry, 1909-2000, Structure,
Competition, Innovation
http://www.rand.org/pubs/monograph_reports/2005/MR1696.pdf
one of the footnotes in above:
However, Boyd and most of the rest of the Fighter Mafia did not accept
the assumption that lighter and simpler meant less capable. They argued
that complicated, expensive modern fighters did not work well in real
combat situations and had poor reliability and maintenance
records. Larger numbers of simpler, more agile, more robust, and more
reliable fighters, they argued, would actually provde greater overall
combat capability for the total force structure.
... snip ...
While Boyd was responsible for the original F16 ... as it got more complicated and more expensive ... it sacrificed some number of the original objectives. I've repeatedly claimed that F20/Tigershark was an attempt to return to those original objectives.
One of the "colorful" tales about F20/Tigershark not actually making it into the market ... was that with its significantly lower price and significantly less complex ... it would be ideal for countries outside the US. However, supposedly there was a very strong lobby in Congress that provided foreign aid for such countries (which was the source of money used to buy such material) ... and the lobby got language written in that the AID money had to be used for F16s (and couldn't be used for the much less expensive and less complex F20/Tigershark).
past post mentioning that Boyd's versions/stories could be much more colorful
https://www.garlic.com/~lynn/2007h.html#73 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#75 John W. Backus, 82, Fortran developer, dies
past posts mentioning F20/tigershark
https://www.garlic.com/~lynn/94.html#8 scheduling & dynamic adaptive ... long posting warning
https://www.garlic.com/~lynn/2002c.html#14 OS Workloads : Interactive etc
https://www.garlic.com/~lynn/2002d.html#1 OS Workloads : Interactive etc
https://www.garlic.com/~lynn/2005d.html#45 Thou shalt have no other gods before the ANSI C standard
https://www.garlic.com/~lynn/2006g.html#13 News Release
https://www.garlic.com/~lynn/2007i.html#3 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#4 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#6 John W. Backus, 82, Fortran developer, dies
other posts in this subthread:
https://www.garlic.com/~lynn/2007h.html#68 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#69 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#70 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#71 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#72 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#73 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#74 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#75 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#5 John W. Backus, 82, Fortran developer, dies
past posts mentioning Boyd
https://www.garlic.com/~lynn/subboyd.html#boyd
various URLs from around the web mentioning Boyd
https://www.garlic.com/~lynn/subboyd.html#boyd2
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Mon, 23 Apr 2007 15:35:52 -0600CBFalconer <cbfalconer@yahoo.com> writes:
recent posts happening to mention Boyd, swing-wing, F14, F15, F16, F18,
and/or F20/Tigershark
https://www.garlic.com/~lynn/2007.html#20 MS to world: Stop sending money, we have enough - was Re: Most ... can't run Vista
https://www.garlic.com/~lynn/2007b.html#37 Special characters in passwords was Re: RACF - Password rules
https://www.garlic.com/~lynn/2007c.html#25 Special characters in passwords was Re: RACF - Password rules
https://www.garlic.com/~lynn/2007c.html#53 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007e.html#18 Is computer history taught now?
https://www.garlic.com/~lynn/2007e.html#45 time spent/day on a computer
https://www.garlic.com/~lynn/2007e.html#48 time spent/day on a computer
https://www.garlic.com/~lynn/2007e.html#53 time spent/day on a computer
https://www.garlic.com/~lynn/2007e.html#55 time spent/day on a computer
https://www.garlic.com/~lynn/2007f.html#15 Designing database tables for performance?
https://www.garlic.com/~lynn/2007f.html#23 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007f.html#29 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007f.html#41 time spent/day on a computer
https://www.garlic.com/~lynn/2007g.html#13 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#29 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#57 ANN: Microsoft goes Open Source
https://www.garlic.com/~lynn/2007h.html#68 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#69 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#71 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#72 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#73 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#74 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#75 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#2 Linux: The Completely Fair Scheduler
https://www.garlic.com/~lynn/2007i.html#3 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#4 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#5 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#6 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#7 John W. Backus, 82, Fortran developer, dies
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Mon, 23 Apr 2007 21:41:19 -0600jmfbahciv writes:
more than anybody possibly ever wants to know about check21
Fed Reports to Congress on Check 21 Progress
http://www.federalreserve.gov/boarddocs/RptCongress/check21/check21.pdf
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Mon, 23 Apr 2007 21:57:39 -0600Anne & Lynn Wheeler <lynn@garlic.com> writes:
F-20 --- The Tigershark Survivors
http://www.johnweeks.com/f20/index.html
from the above:
In the end, the F-20 Tigershark was reported to use 53% less fuel,
required 52% less maintenance, had 63% lower operating costs, was four
times more reliable, and had the fastest scramble time of any fighter
jet in the world. That made it the finest fighter aircraft that never
went into production.
... snip ...
F20 Frequently Asked Questions
http://www.f20a.com/f20faq.htm
from above:
Working on the F-20 was one of the great experiences in the life of many
participants. The lack of the usual government bureaucracy, the
co-operative relationship between the company and its co-investing
suppliers, the espirit-de-corps, the belief that they were creating an
insanely great aircraft - all of this made the workers 'true
believers'. Perhaps it can only be compared to the Apollo program or
missile programs of the late 1950's in the intensity of the team
development experience.
... snip ...
A case study of the F-20 Tigershark
http://www.rand.org/pubs/papers/P7495/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Laugh, laugh. I thought I'd die - application crashes Newsgroups: bit.listserv.ibm-main,alt.folklore.comupters Date: Mon, 23 Apr 2007 22:34:29 -0600oscarptyltd@ibm-main.lst (Clem Clarke) writes:
and from my rfc index
https://www.garlic.com/~lynn/rfcietff.htm
RFC90
https://www.garlic.com/~lynn/rfcidx0.htm#90
90
CCN as a network service center, Braden R., 1971/01/15 (6pp) (.txt=11929)
...
about UCLA 360/91 running MVT, URSA, a "conversational remote job entry system" and TSO
from the RFC:
d) TSO IBM's new general purpose time-sharing subsystem
under MVT, to be available at CCS sometime during
1971. TSO supports 2741's and Teletypes (and at
CCN it will support CCI consoles). TSO is
reminiscent of CTSS in its capabilities and
command language.
... snip ...
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Tue, 24 Apr 2007 07:58:33 -0600jmfbahciv writes:
this long-winded post includes disussion of effects of variable
rate mortgages nearly taking down a leading financial institution
https://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk Management and Information Security
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: U.S. Cedes Top Spot in Global IT Competitiveness Newsgroups: alt.folklore.computers Date: Tue, 24 Apr 2007 09:24:09 -0600Anne & Lynn Wheeler <lynn@garlic.com> writes:
Toyota Tops GM in 1Q Global Auto Sales
http://biz.yahoo.com/ap/070424/japan_toyota_gm.html?.v=22
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: when was MMU virtualization first considered practical? Newsgroups: alt.folklore.computers Date: Tue, 24 Apr 2007 17:39:16 -0600Ben Pfaff <blp@cs.stanford.edu> writes:
tried to get 360/50 to modify with hardware blaauw box ... however it seems that all the spare 360/50s was going to FAA ATC system project ... so they had to settle for a 360/40 to modify ... on which cp40 was implementated (aka 65-66). My recollection of the 360/40 relocation hardware is hazy, it didn't have associative array (hardware tlb) ala the 360/67 ... the 360/40 had 256kbytes of real memory, 64 4k pages ... and there was some sort of hardware register associated with each real 4k page ... which gave the virtual page number translation (possibly implemented somewhat like the 360 storage protection key array?)
from melinda's history
https://www.leeandmelindavarian.com/Melinda#VMHist
Comeau has written: Virtual memory on the 360/40 was achieved by
placing a 64-word associative array between the CPU address generation
circuits and the memory addressing logic. The array was activated via
mode-switch logic in the PSW and was turned off whenever a hardware
interrupt occurred. The 64 words were designed to give us a relocate
mechanism for each 4K bytes of our 256K-byte memory. Relocation was
achieved by loading a user number into the search argument register of
the associative array, turning on relocate mode, and presenting a CPU
address. The match with user number and address would result in a word
selected in the associative array. The position of the word (0-63)
would yield the high-order 6 bits of a memory address. Because of a
rather loose cycle time, this was accomplished on the 360/40 with no
degradation of the overall memory cycle
when the science center was able to finally get 360/67 .. they ported
cp40 to 360/67 renaming it cp67 (aka 66-67). details of 360/67 virtual
memory hardware can be found in functional spec
http://www.bitsavers.org/pdf/ibm/360/functional_characteristics/A27-2719-0_360-67_funcChar.pdf
initially it supported vanilla 360s (w/o virtualized virtual memory) ... not so much because it was impossible ... but it was a lot more code. Around '69 ... somebody on assignment to the cambridge science center from France ... did the additional implementation to provide virtual 360/67s virtual machines ... allowing cp67 to run in a 360/67 virtual machine (i.e. cp67 running under cp67).
later the same person (still on assignment) did much of the enhancements to implement 370 virtual memory as option ... i.e. ability to select the virtual machine for 370 (with 370 virtual memory architecture specirication) ... with cp67 providing the simulation according to the 370 hardware architecture (as optional alternative to simulating according to 360 hardware architecture specification). then a special modified version of the cp67 kernel was created to run on 370 hardware architecture (as opposed to 360/67 hardware architecture).
later the same person shows up back in France responsible for EARN
... some old (EARN related) email correspondence
https://www.garlic.com/~lynn/2001h.html#65 UUCP email
https://www.garlic.com/~lynn/2006t.html#6 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006w.html#43 IBM sues maker of Intel-based Mainframe clones
some old posts about 370 virtual machine support (including 370
hardware virtual memory) was up and running in cp67 a year before the
first engineering 370 processor with virtual memory was operational
(and the special 370 flavor of the cp67 kernel was used as test of the
hardware correctness)
https://www.garlic.com/~lynn/2002j.html#0 HONE was .. Hercules and System/390 - do we need it?
https://www.garlic.com/~lynn/2004b.html#31 determining memory size
https://www.garlic.com/~lynn/2004h.html#27 Vintage computers are better than modern crap !
https://www.garlic.com/~lynn/2004p.html#50 IBM 3614 and 3624 ATM's
https://www.garlic.com/~lynn/2005c.html#59 intel's Vanderpool and virtualization in general
https://www.garlic.com/~lynn/2005d.html#66 Virtual Machine Hardware
https://www.garlic.com/~lynn/2005g.html#17 DOS/360: Forty years
https://www.garlic.com/~lynn/2005h.html#18 Exceptions at basic block boundaries
https://www.garlic.com/~lynn/2005i.html#39 Behavior in undefined areas?
https://www.garlic.com/~lynn/2005j.html#50 virtual 360/67 support in cp67
https://www.garlic.com/~lynn/2005p.html#27 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
https://www.garlic.com/~lynn/2006e.html#7 About TLB in lower-level caches
https://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT
https://www.garlic.com/~lynn/2006l.html#21 Virtual Virtualizers
https://www.garlic.com/~lynn/2006m.html#26 Mainframe Limericks
https://www.garlic.com/~lynn/2006o.html#19 Source maintenance was Re: SEQUENCE NUMBERS
https://www.garlic.com/~lynn/2006q.html#1 Materiel and graft
https://www.garlic.com/~lynn/2006q.html#45 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006q.html#49 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006w.html#3 IBM sues maker of Intel-based Mainframe clones
https://www.garlic.com/~lynn/2007b.html#20 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007f.html#12 FBA rant
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: when was MMU virtualization first considered practical? Newsgroups: alt.folklore.computers Date: Tue, 24 Apr 2007 22:19:22 -0600Ben Pfaff <blp@cs.stanford.edu> writes:
claude also did assignments in the states ... but it was neither of the authors you mention.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: when was MMU virtualization first considered practical? Newsgroups: alt.folklore.computers Date: Tue, 24 Apr 2007 22:31:24 -0600Ben Pfaff <blp@cs.stanford.edu> writes:
Part of the issue was that virtual memory for 370 hadn't been announced yet ... so was a carefully guarded corporate secret. the science center also provided online access to various people from univ. and colleges in the boston area ... so there was some security issues regarding what the non-employees saw on the cambridge system.
the first level cp67 system running on 360/67 didn't have any of Alan's
virtual 370 modifications ... those modifications were part of a
separate cp67 kernel running in a 360/67 virtual machine (and outside of
the prying eyes of non-employees). It was this virtual cp67 kernel ...
which provided the 370 virtual machines. Then a cp67 kernel with more
extensive modifications ... making it able to run on a (real) 370 with
virtual memory support (rather than a 360/67 with virtual memory
support) would run in one of those 370 virtual machines. From various
posts referenced in the previous post
https://www.garlic.com/~lynn/2007i.html#14 when was MMU virtualization first considered practical?
360/67 real hardware running cp67l kernel ... providing standard 360 & 360/67 virtual machines running cp67h kernel ... in 360/67 virtual machine providing 370 running cp67i kernel ... in 370 virtual machine running cms in 370 virtual machinewhen 370 engineering models initially became available with virtual memory hardware ... it was common to find cp67i kernels running on them.
then a couple people from san jose came out and added block multiplexor channel, 3330 disk and 2305 device support to the cp67i kernel ... this cp67i kernel with new 370 device support (rather than 370s running with the older 2314 disk devices) was frequently referred to as the cp67sj kernel.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Wed, 25 Apr 2007 02:53:05 -0600Steve O'Hara-Smith <steveo@eircom.net> writes:
one of the costs is the actual processing of the paper ... which can easily be more than a dollar (across all parts of the infrastructure). somebody writing ten checks a month ... the infrastructure has to recover on the order of $20bucks (or more) per month from somebody. pure zero sum ... means deducting it directly from the account. other means has been if there is minimum balance ... and no interest is paid ... then the money can be invested, and the interest retained (to cover the costs).
so part of check21 is eliminating all those physical costs. justifications for passing check21 included discussions about improving the national economic competitive operations vis-a-vis countries that had much lower use of physical paper checks.
another part of the transitioning to electronic ... is be able to move to
real-time, authorized, authenticated transaction ... basically riding
the rails of pin-debit. pin-debit is supposedly two-factor
authentication i.e. the magstripe, something you have ... and PIN
... something you know ... from 3-factor authentication
https://www.garlic.com/~lynn/subintegrity.html#3factor
part of the problem is that skimming attacks can capture the information from the magstripe (sufficient to make a counterfeit card) and the PIN in a single operation ... aka a common vulnerability, invalidating the assumption about multi-factor authentication having independent vulnerabilities ... and therefor the assumption about it being more secure.
in the mid-90s, the x9a10 financial standard working group had been
given the requirement to preserve the integrity of the financial
infrastructure for all retail payments (credit, debit, ach, check,
internet, point-of-sale, ... aka ALL). Detailed end-to-end study of
lots of exploits and vulnerabilities resulted in x9.59 financial
standard
https://www.garlic.com/~lynn/x959.html#x959
where it effectively substitutes a digital signature for a PIN in the transaction ... where the PIN is the same on every transactions and can be skimmed and used in replay attacks (for fraudulent transactions) ... the digital signature is unique for every transaction (and countermeasure to all kinds of replay attacks involving using information from previous transactions)
another kind of costs in the (check and check21) infrastructure is insufficient funds (NF) involving checks or other transactions that aren't done in real-time ... i.e. clearing a day or more later. This is also eliminated in the real-time, x9.59 scenario. The out-and-out fraud version of this is somebody comes into town, opens an account with $1000, and gets all sorts of valid checks and authentication. The person then proceeds to execute $20k in transactions and leaves town. All the transactions, otherwise have valid authentication by the authorized person ... it just is that significantly more value is being extracted from the infrastructure than went in. x9.59 digital signature allows for only the authorized person to perform the transaction ... while the real-time operation is countermeasure to a crooked authorized person from performing fraudulent operations.
Some of this can be seen in the walmart (and other merchants that joined
in) successful anti-trust action against the card associations. simple
use of search engine can turn up lots of references ... examples:
http://www.classactionrefund.com/VisaInfo.html
http://www.inrevisacheckmastermoneyantitrustlitigation.com/history.php3
the issue involved requirements surrounding accepting "pin-less" debit transactions. part of the issue is that pin-debit goes thru in real-time and has two-factor authentication ... and therefor there is less risk ... and much lower interchange fees charged the merchant (i.e. stronger authentication and less chance of insufficient funds). the pin-less debit turns out, not only uses lower authentication ... but also didn't happen in real time. As a result, there was significantly more opportunity for all kinds of fraud ... and therefor the merchants are charged significantly higher interchange fee (for all such transactions, independent of whether actual fraud was involved)
other things considered by x9a10 was PKI-based digital signature
operations that includes appending digital certificates to digitally
signed operations. these digital certificates would account for
100-times bloat in payload size and processing for typical payment
transaction
https://www.garlic.com/~lynn/subpubkey.html#bloat
this bloat for PKI-based payment operations is so large that there also
was some X9 standards activity looking at "compressed" digital
certificates for use in payment transactions ... recent reference:
https://www.garlic.com/~lynn/2007h.html#31 sizeof() was: The Perfect Computer - 36 bits?
however, the whole paradigm for PKI, certification authorities, and digital certificates is fundamentally for offline transactions between two strangers that have no prior interaction. the issue in real-time transactions is that the account owner can provide their public key (for verifying digital signatures) at the same time they open an account (in much the same way they currently provide mother's maiden name for authentication). since the individual and the individual's financial institution have prior business relationship (existance of the account), the on-file public key for real-time operations can eliminate the redundant and superfluous 100-times bloat represented by typical proposed PKI-based payment transaction operation (and the prior business relationship invalidates the fundamental premise justifying a PKI-based infrastructure)
this is similar to the catch-22 related to on-file public keys
proposed for domain name infrastructure
https://www.garlic.com/~lynn/subpubkey.html#catch22
misc. past posts mentioning some kind of fraud, exploit, vulnerability,
threat and/or risk
https://www.garlic.com/~lynn/subintegrity.html#fraud
semi-related recent posts
https://www.garlic.com/~lynn/2007h.html#20 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#22 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#26 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#27 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#28 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#32 sizeof() was: The Perfect Computer - 36 bits?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Wed, 25 Apr 2007 03:53:10 -0600greymaus writes:
some number of other sites turned up by search engine ... reference the above report (apparently because very few other "studies" actually rely on real data).
so quite a few of the websites seem to wave hands and/or claim
biases one way or another ... however, i've found that gao reports
tend to be unbiased. so searching again but limiting to .gov
turns up detailed analysis in GAO report from 1995
http://www.gao.gov/cgi-bin/getrpt?HEHS-95-133
all possible scenarios in the above show positive net costs (total costs minus economic contribution).
now, all the other reports turned up by search engine for gao.gov ... all appeared to look at single or small number of factors ... as opposed to overall total costs and total economic contriubtion yielding net total costs.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Wed, 25 Apr 2007 09:12:39 -0600Anne & Lynn Wheeler <lynn@garlic.com> writes:
not actually knowing the basis ... but this might also account for the
recent postings about news articles claiming both approx. ten percent
decline in overall identity theft costs and at the same time identity
theft is exploding/doubling.
https://www.garlic.com/~lynn/2007e.html#29 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007e.html#58 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007e.html#62 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007f.html#58 Securing financial transactions a high priority for 2007
say somebody is opening an account using a non-existent person. then when they skip town ... the cost all falls back onto the bank; in fact this referenced news item:
Identity Fraud: ID Theft Victims, Losses Take Welcome Nosedive
http://www.banktechnews.com/article.html?id=20070226T5LTLE8K
in this post
https://www.garlic.com/~lynn/2007e.html#58 Securing financial transactions a high priority for 2007
does say that the improvement comes from better processing of requests to open new accounts.
the explosion/doubling in identity theft ... specifically involved attacks on existing accounts belonging to other people.
if the financial institution did better job of handling new accounts and/or shifting the related fraud costs off to the merchants ... then the net savings for the financial institution (with regard to that kind of identity theft) might be the basis of claiming an overall net descrease in total identity theft costs when at the same time, identity theft involving fraud attacks against existing consumer accounts is exploding/doubling (i.e. the kind that consumers are seeing).
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Does anyone know of a documented case of VM being penetrated by hackers? Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers Date: Wed, 25 Apr 2007 10:02:21 -0600rschuh wrote:
The future system project was in full swing ... lots of past posts
https://www.garlic.com/~lynn/submain.html#futuresys
all the documentation was supposed to be super secret and required need-to-know ... and so it was all being done as softcopy under vm370. they had instituted all sorts of additional security processes.
I had been somewhat panning FS project by comparing what they were doing to a cult film that had been playing continuously for several yrs down in central sq (and making references to the inmates being in charge of the institution).
Anyway ... somebody up'ed the ante by making claims that all the vm370 security procedures were such that even if I was physically in the machine room, I wouldn't be able to access the documents. So in a moment of weakness, I said that it would take less than five minutes ... I went to the operators console and spent most of the time disabling connectivity to the machine (to anything outside the machine room) ... then I flipped a bit in real storage ... and had access to everything.
So they then wanted to know what kind of countermeasures to that attack would I use (i.e. standard procedure to alternate between attacking and defending). My comment was to remove all the front panel controls to a lockable interface (say keyboard handled by some sort of service processor requiring password) and/or encrypt all the information (i.e. DES hadn't been invented yet ... although the person responsible for DES was student down at Harvard at the time)
for some topic drift ... recent somewhat related thread
https://www.garlic.com/~lynn/2007i.html#14 when was MMU virtualization first considered practical?
https://www.garlic.com/~lynn/2007i.html#15 when was MMU virtualization first considered practical?
https://www.garlic.com/~lynn/2007i.html#16 when was MMU virtualization first considered practical?
basically the cp67 service at the science center
https://www.garlic.com/~lynn/subtopic.html#545tech
including providing access to some number of students and others from various educational institutions in the boston area ... while at the same time, performing some amount of activity involving extremely sensitive corporate information. In the above reference thread ... it was the existance of virtual memory for 370 ... before the announcement that there would be 370 virtual memory.
Another scenario involved the most sensitve corporate data about customers and business operation. The science center had ported apl\360 to CMS for cms\apl. One of the things this allowed was workspace sizes up to the size of the cms virtual machine (while typical apl\360 workspace sizes was 16kbytes or sometimes 32kbytes). In that time-frame, APL was frequently used for business modeling and other things that currently commingly use spreadsheets. Drastically increasing the APL workspace size allowed for business people in corporate hdqtrs to run their applications against large amounts of real data (so remote 2741 terminal access was provided to armonk ... and they sent cambridge tapes containing extremely sensitive customer and business data).
In this time frame, there was one incident of a MIT student doing a looping channel program as a denial of service attack.
for other drift ... there was the use mentioned by these guys
... something that I didn't learn about until much later
https://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml
misc. past posts about security issues raised by allowing access to
non-employees and students from various institutions in the Boston
area ... while at the same time providing services involving some of
the highest sensitive corporate information.
https://www.garlic.com/~lynn/99.html#7 IBM S/360
https://www.garlic.com/~lynn/99.html#33 why is there an "@" key?
https://www.garlic.com/~lynn/2000g.html#4 virtualizable 360, was TSS ancient history
https://www.garlic.com/~lynn/2001i.html#44 Withdrawal Announcement 901-218 - No More 'small machines'
https://www.garlic.com/~lynn/2002h.html#50 crossreferenced program code listings
https://www.garlic.com/~lynn/2002h.html#60 Java, C++ (was Re: Is HTML dead?)
https://www.garlic.com/~lynn/2002i.html#62 subjective Q. - what's the most secure OS?
https://www.garlic.com/~lynn/2002p.html#37 Newbie: Two quesions about mainframes
https://www.garlic.com/~lynn/2002q.html#47 myths about Multics
https://www.garlic.com/~lynn/2003b.html#0 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003e.html#66 History of project maintenance tools -- what and when?
https://www.garlic.com/~lynn/2003f.html#1 History of project maintenance tools -- what and when?
https://www.garlic.com/~lynn/2003g.html#5 Any DEC 340 Display System Doco ?
https://www.garlic.com/~lynn/2003g.html#18 Multiple layers of virtual address translation
https://www.garlic.com/~lynn/2003g.html#29 Lisp Machines
https://www.garlic.com/~lynn/2004b.html#31 determining memory size
https://www.garlic.com/~lynn/2004c.html#7 IBM operating systems
https://www.garlic.com/~lynn/2004e.html#36 NSF interest in Multics security
https://www.garlic.com/~lynn/2004p.html#50 IBM 3614 and 3624 ATM's
https://www.garlic.com/~lynn/2005b.html#12 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005b.html#45 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005d.html#58 Virtual Machine Hardware
https://www.garlic.com/~lynn/2005f.html#63 Moving assembler programs above the line
https://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
https://www.garlic.com/~lynn/2005h.html#18 Exceptions at basic block boundaries
https://www.garlic.com/~lynn/2005o.html#34 Not enough parallelism in programming
https://www.garlic.com/~lynn/2005o.html#46 Article: The True Value of Mainframe Security
https://www.garlic.com/~lynn/2005p.html#20 address space
https://www.garlic.com/~lynn/2005p.html#27 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
https://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT
https://www.garlic.com/~lynn/2006h.html#14 Security
https://www.garlic.com/~lynn/2006l.html#21 Virtual Virtualizers
https://www.garlic.com/~lynn/2006m.html#26 Mainframe Limericks
https://www.garlic.com/~lynn/2006n.html#2 The System/360 Model 20 Wasn't As Bad As All That
https://www.garlic.com/~lynn/2006o.html#19 Source maintenance was Re: SEQUENCE NUMBERS
https://www.garlic.com/~lynn/2006w.html#3 IBM sues maker of Intel-based Mainframe clones
https://www.garlic.com/~lynn/2006x.html#19 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2007g.html#31 Wylbur and Paging
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Wed, 25 Apr 2007 11:08:54 -0600Al Balmer <albalmer@att.net> writes:
however, as more and more service virtual machines were created ... the
operator still had to manually login and get each of them operational.
some of this is mentioned in recent thread talking about service
virtual machines ... and their currently being referred to as virtual
appliances ... some recent references
https://www.garlic.com/~lynn/2007d.html#23 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007d.html#66 Is computer history taugh now?
https://www.garlic.com/~lynn/2007g.html#70 The Perfect Computer - 36 bits?
however, as part of some automated benchmarking I was working on ... I
created the autolog command ... as well as change to automatically
execute an "autolog" for a startup service virtual machine (which could
be programmed to execute autologs for other services) ... as part of
standard ipl/boot. lots of past posts referring to work on automated
benchmarking, workload profiling, and stuff leading up to what is
current referred to as capacity planning
https://www.garlic.com/~lynn/submain.html#bench
it turns out that the autolog features started to find a lot of use
for production operation ... and eventually found its way out in the
product in vm370 release 3. old email references
https://www.garlic.com/~lynn/2006w.html#email750102
in this post
https://www.garlic.com/~lynn/2006w.html#7 Why these original FORTRAN quirks?
and
https://www.garlic.com/~lynn/2006w.html#email750430
in this post
https://www.garlic.com/~lynn/2006w.html#7 Why these original FORTRAN quirks?
even more topic drift ...
https://www.garlic.com/~lynn/2007i.html#20 John W. Backus, 82, Fortran developer, dies
I've periodically claimed that one of the reasons that so much of the stuff that I was doing at the science center was picked up for product shipment ... was that a lot of the corporation had been extremely preoccupied with Future System project ... and after it was killed, there was a lot of scurrying around to try and get stuff (back) into the 370-based product pipeline.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Wed, 25 Apr 2007 12:15:10 -0600Morten Reistad <first@last.name> writes:
we were looking somewhat at the higher-priced end of the market
for ha/medusa stuff
https://www.garlic.com/~lynn/lhwemail.html#medusa
and
https://www.garlic.com/~lynn/95.html#13
https://www.garlic.com/~lynn/96.html#15
and some of the bandwidth requirements for geographic survivabilty
stuff
https://www.garlic.com/~lynn/submain.html#available
recent posts mentioning geographic survivability
https://www.garlic.com/~lynn/2007.html#29 Just another example of mainframe costs
https://www.garlic.com/~lynn/2007.html#36 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007.html#39 Just another example of mainframe costs
https://www.garlic.com/~lynn/2007e.html#16 Attractive Alternatives to Mainframes
https://www.garlic.com/~lynn/2007e.html#38 FBA rant
https://www.garlic.com/~lynn/2007f.html#56 Is computer history taught now?
https://www.garlic.com/~lynn/2007h.html#76 John W. Backus, 82, Fortran developer, dies
but we also did simple, much less expensive stuff using off-the-shelf
components and leverage networking protocol stack and internet topology
... like for original payment gateway
https://www.garlic.com/~lynn/subnetwork.html#gateway
and recent post
https://www.garlic.com/~lynn/2007h.html#67 SSL vs. SSL over tcp/ip
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Wed, 25 Apr 2007 12:25:59 -0600Frank McCoy <mccoyf@millcomm.com> writes:
this is analogous ... but completely different to past discussions about
possibly being able to change the burden of proof in retail payment
transactions; recent reference
https://www.garlic.com/~lynn/2007h.html#28 sizeof() was: The Perfect Computer - 36 bits?
for totally other topic drift ... some work in X9.59 standards work
regarding being able to assist in resolving disputes regarding invoice
or bill-of-materials involved in transaction
https://www.garlic.com/~lynn/aadsm26.htm#61 crypto component services - is there a market?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Wed, 25 Apr 2007 14:31:27 -0600greymaus writes:
there were some number of similar studies of domestic population groups
... i.e. total costs against total economic contributions ... being
either positive (contributing less economically than costing) or
negative.
http://www.cis.org/articles/2004/fiscalexec.html
http://www.gao.gov/cgi-bin/getrpt?HEHS-95-133
one of the studies from the 1990 census put half of the high school graduation age group as functionally illiterate and falling into the category of likely costing the society more than they contribute (needing various forms of gov. and social assistance and subsidies).
something similar shows up in some of the social security ("pay as you go") studies ... comparing ratios of 30+ contributing to every person receiving ... then what happens as it drops to 6:1 contributing per person receiving ... and then projections what happens when the ratio drops to less then 1:1 ... is there a tipping point when the amount available for assistance/subsidies becames smaller than the required outlays.
a few/sample past posts mentioning 1990 census study that found half of
high school aged graduates were functionally illiterate.
https://www.garlic.com/~lynn/2002k.html#45 How will current AI/robot stories play when AIs are real?
https://www.garlic.com/~lynn/2003i.html#28 Offshore IT
https://www.garlic.com/~lynn/2003i.html#45 Offshore IT
https://www.garlic.com/~lynn/2003i.html#55 Offshore IT
https://www.garlic.com/~lynn/2003p.html#33 [IBM-MAIN] NY Times editorial on white collar jobs going
https://www.garlic.com/~lynn/2004b.html#42 The SOB that helped IT jobs move to India is dead!
https://www.garlic.com/~lynn/2004d.html#18 The SOB that helped IT jobs move to India is dead!
https://www.garlic.com/~lynn/2004h.html#18 Low Bar for High School Students Threatens Tech Sector
https://www.garlic.com/~lynn/2005e.html#48 Mozilla v Firefox
https://www.garlic.com/~lynn/2005g.html#43 Academic priorities
https://www.garlic.com/~lynn/2006g.html#20 The Pankian Metaphor
https://www.garlic.com/~lynn/2006l.html#63 DEC's Hudson fab
https://www.garlic.com/~lynn/2007g.html#7 U.S. Cedes Top Spot in Global IT Competitiveness
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Latest Principles of Operation Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Wed, 25 Apr 2007 14:43:10 -0600Howard Brazee <howard@brazee.net> writes:
slightly related thread discussing f18/f14, f16/f15, as well as f20
(with even a little computer related stuff sprinkled in) ... warning
quite a bit of thread drift ... even tho there was a lot of numerical
intensive computing that went into f16, f18, f20, etc:
https://www.garlic.com/~lynn/2007i.html#3 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#4 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#6 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#7 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#8 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#10 John W. Backus, 82, Fortran developer, dies
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Latest Principles of Operation Newsgroups: bit.listserv.ibm-main,alt.folkore.computers Date: Wed, 25 Apr 2007 15:21:31 -0600Howard Brazee <howard@brazee.net> writes:
apple os (and next before it) starts out with a MACH "microkernel" basis ... could be considered striving for KISS ... somewhat like the original CP67, as an extremely well focused microkernel. The morph from CP67 to VM370 included work by people with much more of traditional operating system training. Over the years, many found that the extreme simplicity of the kernel made it easy to change/add/modify on an adhoc basis. Unfortunately many such years of such adhoc approach to dealing with something that was suppose to be a microkernel (rather than operating system) ... eventually results in a lot of bloat and spaghetti code
past reference to comment about simple can be frequently much harder
than complex ... and it should be done with there is nothing left to
remove ... as opposed to it being done when there is nothing left to
add.
https://www.garlic.com/~lynn/2007h.html#29 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#30 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007i.html#5 John W. Backus, 82, Fortran developer, dies
more recently there have been comments about simple virtual machine microkernels may be solution to various significant security issues in the personal computing market place ... dynamically opening up a traditional operating system in a "padded cell" virtual machine when it needs to do various kinds of internet/network operations ... and then collapsing and discarding most of the environment when finished.
lots of past posts referring to various microkernel activities:
https://www.garlic.com/~lynn/94.html#54 How Do the Old Mainframes
https://www.garlic.com/~lynn/95.html#0 pathlengths
https://www.garlic.com/~lynn/2000e.html#42 IBM's Workplace OS (Was: .. Pink)
https://www.garlic.com/~lynn/2001f.html#23 MERT Operating System & Microkernels
https://www.garlic.com/~lynn/2001h.html#11 checking some myths.
https://www.garlic.com/~lynn/2001j.html#36 Proper ISA lifespan?
https://www.garlic.com/~lynn/2001k.html#45 SMP idea for the future
https://www.garlic.com/~lynn/2001l.html#25 mainframe question
https://www.garlic.com/~lynn/2001m.html#47 TSS/360
https://www.garlic.com/~lynn/2003.html#50 Origin of Kerberos
https://www.garlic.com/~lynn/2003.html#60 MIDAS
https://www.garlic.com/~lynn/2003h.html#37 Does PowerPC 970 has Tagged TLBs (Address Space Identifiers)
https://www.garlic.com/~lynn/2003j.html#72 Microkernels are not "all or nothing". Re: Multics Concepts For
https://www.garlic.com/~lynn/2003k.html#5 What is timesharing, anyway?
https://www.garlic.com/~lynn/2003k.html#9 What is timesharing, anyway?
https://www.garlic.com/~lynn/2003k.html#24 Microkernels are not "all or nothing". Re: Multics Concepts For
https://www.garlic.com/~lynn/2003k.html#26 Microkernels are not "all or nothing". Re: Multics Concepts For
https://www.garlic.com/~lynn/2003k.html#27 Microkernels are not "all or nothing". Re: Multics Concepts For
https://www.garlic.com/~lynn/2003k.html#28 Microkernels are not "all or nothing". Re: Multics Concepts For
https://www.garlic.com/~lynn/2003k.html#30 IBM channels, was Re: Microkernels are not "all or nothing"
https://www.garlic.com/~lynn/2003k.html#37 Microkernels are not "all or nothing". Re: Multics Concepts For
https://www.garlic.com/~lynn/2005b.html#22 The Mac is like a modern day Betamax
https://www.garlic.com/~lynn/2005c.html#44 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005c.html#56 intel's Vanderpool and virtualization in general
https://www.garlic.com/~lynn/2005c.html#63 intel's Vanderpool and virtualization in general
https://www.garlic.com/~lynn/2005f.html#10 Where should the type information be: in tags and descriptors
https://www.garlic.com/~lynn/2006p.html#10 What part of z/OS is the OS?
https://www.garlic.com/~lynn/2006p.html#11 What part of z/OS is the OS?
https://www.garlic.com/~lynn/2007g.html#70 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007g.html#83 IBM to the PCM market
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Wed, 25 Apr 2007 18:06:02 -0600Morten Reistad <first@last.name> writes:
as improvements in disk performance lagged further and further behind improvements in other system components ... there was more and more work done on attempting to compensate for the relative disk degradation. extensive use of (electronic memory) caching worked for reads (involving data that was likely to be reused).
logs had the characteristic that they involved sequential contiguous writes ... possibly in large block transfers ... minimizing arm motion and rotational delays that have been the primary disk thruput bottleneck.
some number of database systems have done things like fast commit ... where the transaction was considered "committed" as soon as the journaled changes had been written to log (in highly optimized sequential contiguous writes) ... and the actual database records remained cached in storage ... where "lazy" writes to the "home" database position attempted to collect numerous changed/updated records located in physical proximity for writing.
log structured filesystems would extend to doing all writes to sequential contiguous locations. the issue was a periodic "garbage collection" process that attempted to re-organize records to file sequential ordering instead of sequential location ordering based on temporal sequence of the write requests. the problem was that the "garbage collection" overhead could more than offset improvements by doing all writes to sequential contiguous locations.
minor historical note ... one of the primary individuals that did work
on bsd fast file system implementation and then log structured
filesystem implementation was later hired by ha/cmp project to consult
on doing a geographically distributed filesystem ... misc. past posts
mentioning ha/cmp
https://www.garlic.com/~lynn/subtopic.html#hacmp
and geographically distributed operation
https://www.garlic.com/~lynn/submain.html#available
the first such (unix) journaled/logging filesystem was JFS done for AIX ... which only handles filesystem control/metadata changes ... not actual file data changes/writes. work on early 801/risc had included stuff for "database" memory ... i.e. memory map all you data to area that had fine-grain storage alteration tracking. Instead of having application code to explicit call log manager with pointers to all changes ... which then got batched for writing to the log when commit was called ... there could just be careful memory mapping of the data ... and when commit was called ... the commit/log processor would scan memory for all changes ... which then get logged.
So the exercise for AIX3.0 for RS/6000 (rios) was to remap all unix filesystem control/metadata to special "database" memory mapped region. The original unix code didn't have to be modified to track all metadata changes ... just the insertion of "commit" calls at carefully selected points. The commit/log routine then would scan the "database" memory mapped region for all storage alterations ... and write them to the log/journal.
An issue came up for the Palo Alto unix organization about porting the code to non-801 architecture machine (w/o the hardware database memory support). They had to go back thru all the unix filesystem code ... inserting changed/logged calls at all the appropriate places. One of the (unfortunate?) side results ... was that they were able to show that the explicit changed/logged calls were actually more efficient and better performance than the scanning needed for the database memory implementation.
past posts mentioning log structured filesystems
https://www.garlic.com/~lynn/93.html#28 Log Structured filesystems -- think twice
https://www.garlic.com/~lynn/93.html#29 Log Structured filesystems -- think twice
https://www.garlic.com/~lynn/2000c.html#24 Hard disks, one year ago today
https://www.garlic.com/~lynn/2001f.html#59 JFSes: are they really needed?
https://www.garlic.com/~lynn/2002b.html#20 index searching
https://www.garlic.com/~lynn/2002l.html#36 Do any architectures use instruction count instead of timer
https://www.garlic.com/~lynn/2003b.html#69 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2004g.html#22 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2005l.html#41 25% Pageds utilization on 3390-09?
https://www.garlic.com/~lynn/2005n.html#36 Code density and performance?
https://www.garlic.com/~lynn/2006j.html#3 virtual memory
https://www.garlic.com/~lynn/2006j.html#10 The Chant of the Trolloc Hordes
https://www.garlic.com/~lynn/2007.html#30 V2X2 vs. Shark (SnapShot v. FlashCopy)
various past posts/threads mentioning database memory
https://www.garlic.com/~lynn/2002b.html#33 Does it support "Journaling"?
https://www.garlic.com/~lynn/2002b.html#34 Does it support "Journaling"?
https://www.garlic.com/~lynn/2003c.html#49 Filesystems
https://www.garlic.com/~lynn/2003d.html#54 Filesystems
https://www.garlic.com/~lynn/2005n.html#20 Why? (Was: US Military Dead during Iraq War
https://www.garlic.com/~lynn/2005n.html#32 Why? (Was: US Military Dead during Iraq War
https://www.garlic.com/~lynn/2006o.html#26 Cache-Size vs Performance
https://www.garlic.com/~lynn/2006y.html#36 Multiple mappings
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Wed, 25 Apr 2007 18:11:45 -0600re:
for even more topic drift ... recent article showed up today ...
Fraud was the Cinderella of crimes but that's about to change
http://www.easier.com/view/News/Business/article-111323.html
a couple quotes from above
"Trying to turn financial people into crime officers is doomed to failure."
...
"David Luijerink, head of fraud risk management services at KPMG
Forensic believes companies often look in the wrong place for
fraudsters."
... snip ...
for instance, past studies have shown (even in the internet age) that
the majority of fraud have involved "insiders". misc. past posts
mentioning "issues" with insiders:
https://www.garlic.com/~lynn/2001c.html#45 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001g.html#38 distributed authentication
https://www.garlic.com/~lynn/2001j.html#54 Does "Strong Security" Mean Anything?
https://www.garlic.com/~lynn/2002.html#12 A terminology question
https://www.garlic.com/~lynn/2002d.html#14 Mainframers: Take back the light (spotlight, that is)
https://www.garlic.com/~lynn/2002f.html#35 Security and e-commerce
https://www.garlic.com/~lynn/2002j.html#14 Symmetric-Key Credit Card Protocol on Web Site
https://www.garlic.com/~lynn/2004i.html#5 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#16 New Method for Authenticated Public Key Exchange without Digital Ceritificates
https://www.garlic.com/~lynn/2004j.html#15 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2004j.html#37 Vintage computers are better than modern crap !
https://www.garlic.com/~lynn/2005g.html#33 Good passwords and security priorities
https://www.garlic.com/~lynn/2005g.html#37 MVS secure configuration standard
https://www.garlic.com/~lynn/2005i.html#1 Brit banks introduce delays on interbank xfers due to phishing boom
https://www.garlic.com/~lynn/2005i.html#11 Revoking the Root
https://www.garlic.com/~lynn/2005j.html#52 Banks
https://www.garlic.com/~lynn/2005k.html#1 More on garbage
https://www.garlic.com/~lynn/2005k.html#55 Encryption Everywhere? (Was: Re: Ho boy! Another big one!)
https://www.garlic.com/~lynn/2005l.html#29 Importing CA certificate to smartcard
https://www.garlic.com/~lynn/2005l.html#35 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005o.html#2 X509 digital certificate for offline solution
https://www.garlic.com/~lynn/2005v.html#2 ABN Tape - Found
https://www.garlic.com/~lynn/2006c.html#35 X.509 and ssh
https://www.garlic.com/~lynn/2006d.html#26 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006d.html#28 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006e.html#26 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006e.html#44 Does the Data Protection Act of 2005 Make Sense
https://www.garlic.com/~lynn/2006h.html#15 Security
https://www.garlic.com/~lynn/2006h.html#26 Security
https://www.garlic.com/~lynn/2006k.html#4 Passwords for bank sites - change or not?
https://www.garlic.com/~lynn/2006k.html#16 Value of an old IBM PS/2 CL57 SX Laptop
https://www.garlic.com/~lynn/2006k.html#23 Value of an old IBM PS/2 CL57 SX Laptop
https://www.garlic.com/~lynn/2006k.html#33 Password Complexity
https://www.garlic.com/~lynn/2006p.html#9 New airline security measures in Europe
https://www.garlic.com/~lynn/2006u.html#40 New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2006u.html#43 New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2006v.html#2 New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2006v.html#42 On sci.crypt: New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2006v.html#49 Patent buster for a method that increases password security
https://www.garlic.com/~lynn/2006x.html#14 IBM ATM machines
https://www.garlic.com/~lynn/2007.html#42 The logic of privacy
https://www.garlic.com/~lynn/2007b.html#13 special characters in passwords
https://www.garlic.com/~lynn/2007b.html#20 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007b.html#33 security engineering versus information security
https://www.garlic.com/~lynn/2007b.html#60 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#10 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#11 Decoding the encryption puzzle
https://www.garlic.com/~lynn/2007c.html#32 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#35 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#43 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007f.html#75 Securing financial transactions a high priority for 2007
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Does anyone know of a documented case of VM being penetrated by hackers? Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers Date: Thu, 26 Apr 2007 08:11:39 -0600re:
for a little topic drift ... a little about virtual machine assurance
in recent post to ibm-main
https://www.garlic.com/~lynn/2007i.html#26 Latest Principles of Operation
From: lynn@garlic.com Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: 26 Apr 2007 08:49:18 -0700On Apr 26, 1:04 am, Brian Inglis <Brian.Ing...@SystematicSW.Invalid> wrote:
internal datacenters and external customers were comparable. there was study in the early 80s ... that the "internal" change/update collections were comperable to the waterloo share tape change/update collections (about the same aggregate size in magnitude and offered similar features); but done by internal datacenters (for much the same reason that external customers were doing change/updates).
there was some copying ... but mostly things were going on
independently and frequently coming up with similar solutions. there
was possibly slightly more pervasive distribution of such stuff
internally ... since there wasn't the issue of crossing corporate
boundaries ... as well as the increasingly pervasive use of the
internal networks .... folklore about internal network significantly
aided the evolution of REX(X) language in the 70s ... previous posts:
https://www.garlic.com/~lynn/2006p.html#28 Greatest Software Ever
Written?
https://www.garlic.com/~lynn/2006p.html#31 "25th Anniversary of the
Personal Computer"
https://www.garlic.com/~lynn/2006r.html#7 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006t.html#36 The Future of CPUs: What's After Multi-Core?
to reference here (gone 404 but lives on at wayback machine)
https://web.archive.org/web/20020506063424/http://computinghistorymuseum.org/ieee/af_forum/read.cfm?forum=10&id=21&thread=7
One of the scenarios going the other way ... i had done DUMPRX in the
early 80s
https://www.garlic.com/~lynn/submain.html#dumprx
initially somewhat as demonstration of the new scripting language (rexx) and its capability ... i.e. show that in three months working half-time ... write a replacement for the existing dump (problem analysis tooL) in rexx with ten times the function and ten times the performance (of the original assembler). Since this was also around the time that there was talk about forcing OCO ... that having major application in an interpreted language ... that it would still force them to ship source (if they chose to ship dumprx). Eventually, it was used in nearly every internal datacenters and by all PSRs (i.e. internal people tasked with resolving system problems at customer datacenters) ... but for whatever reason they never agreed to ship it.
However, i got approval to give a dumprx talk at share meeting ... and i spent the whole talk about how i did the implementation. Within a couple months ... similar implementations started to show up at customer shops.
past posts mentioning transition to OCO (object code only)
https://www.garlic.com/~lynn/2001e.html#6 Blame it all on Microsoft
https://www.garlic.com/~lynn/2002c.html#4 Did Intel Bite Off More Than It Can Chew?
https://www.garlic.com/~lynn/2002p.html#2 IBM OS source code
https://www.garlic.com/~lynn/2002p.html#3 IBM OS source code
https://www.garlic.com/~lynn/2002p.html#7 myths about Multics
https://www.garlic.com/~lynn/2003k.html#46 Slashdot: O'Reilly On The Importance Of The Mainframe Heritage
https://www.garlic.com/~lynn/2004m.html#47 IBM Open Sources Object Rexx
https://www.garlic.com/~lynn/2004m.html#53 4GHz is the glass ceiling?
https://www.garlic.com/~lynn/2005c.html#42 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005c.html#50 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005e.html#34 Thou shalt have no other gods before the ANSI C standard
https://www.garlic.com/~lynn/2005e.html#35 Thou shalt have no other
gods before the ANSI C standard
https://www.garlic.com/~lynn/2005f.html#15 Where should the type
information be: in tags and descriptors
https://www.garlic.com/~lynn/2005j.html#29 IBM Plugs Big Iron to the
College Crowd
https://www.garlic.com/~lynn/2005j.html#41 TSO replacement?
https://www.garlic.com/~lynn/2005r.html#5 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005u.html#57 IPCS Standard Print Service
https://www.garlic.com/~lynn/2006b.html#8 Free to good home: IBM RT UNIX
https://www.garlic.com/~lynn/2006f.html#38 Over my head in a JES exit
https://www.garlic.com/~lynn/2006j.html#29 How to implement Lpars within Linux
https://www.garlic.com/~lynn/2006j.html#33 How to implement Lpars
within Linux
https://www.garlic.com/~lynn/2006n.html#34 Not Your Dad's Mainframe: Little Iron
https://www.garlic.com/~lynn/2006o.html#14 SEQUENCE NUMBERS
https://www.garlic.com/~lynn/2007f.html#67 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007g.html#54 The Perfect Computer - 36 bits?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Latest Principles of Operation Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Thu, 26 Apr 2007 12:04:40 -0600rfochtman@ibm-main.lst (Rick Fochtman) writes:
well, i remember the hassle to get compare&swap instruction into the 370
architecture. Charlie had invented compare&swap instruction when he was
working on smp kernel fine-grain locking for cp67 at the science center
https://www.garlic.com/~lynn/subtopic.html#545tech
the "redbook" 370 architecture owners claimed that everybody (namely the
POK favorite son operating system people) thot that test&set was totally
adequate for all multiprocessor support. in order to justify getting
compare&swap instruction into 370 architecture, we had to
come up with a whole boatload of justifications for
compare&swap instruction that weren't specific to
multiprocessor operation. thus was born the stuff in principle of
operations about using compare&swap instruction for
application multithreaded operation (regardless of whether or not it
was multiprocessor environment). lots of past posts mentioning
multiprocessor support and/or compare&swap instruction
https://www.garlic.com/~lynn/subtopic.html#smp
it is sometimes relative. i've claimed that John came up with risc/801
as part of going to the opposite extreme after the extremely complex
future system project failed ... misc. past posts mentioning failed
future system project
https://www.garlic.com/~lynn/submain.html#futuresys
and lots of past post mentioning 801, romp, rios, iliad, fort knox,
somerset, power/pc, etc
https://www.garlic.com/~lynn/subtopic.html#801
and old email with 801 references
https://www.garlic.com/~lynn/lhwemail.html#801
Supposedly future system project was a countermeasure to clone
controllers ... something I got (at least partially) blamed for from a
project that I worked on as undergraduate in the 60s producing our own
clone controller
https://www.garlic.com/~lynn/submain.html#360pcm
also some "FS" quotes referenced in this post
https://www.garlic.com/~lynn/2007f.html#28 The Perfect Computer - 36 bits?
from article by former executive here
https://www.ecole.org/en/session/49-the-rise-and-fall-of-ibm
https://www.ecole.org/en/session/49-the-rise-and-fall-of-ibm
The FS effort and subsequent failure ... can also be considered as
contributing to the uptake of clone processors (in part because of the
dearth of items in the 370 product pipeline) a few recent posts
https://www.garlic.com/~lynn/2007g.html#55 IBM to the PCM market(the sky is falling!!!the sky is falling!!)
https://www.garlic.com/~lynn/2007g.html#57 IBM to the PCM market(the sky is falling!!!the sky is falling!!)
https://www.garlic.com/~lynn/2007g.html#59 IBM to the PCM market(the sky is falling!!!the sky is falling!!)
and after the failure of the FS project ... there was a rush to get
stuff back into the 370 product pipeline. Recent post attributing that
as big part of the reason that the product group shipped so much of my
code (since I continued to develop 370-based software all thru the FS
activity)
https://www.garlic.com/~lynn/2007i.html#21 John W. Backus, 82, Fortran developer, dies
and another recent posting touching on some stuff that went on in the FS era
https://www.garlic.com/~lynn/2007i.html#20 Does anyone know of a documented case of VM being penetrated by hackers?
https://www.garlic.com/~lynn/2007i.html#29 Does anyone know of a documented case of VM being penetrated by hackers?
another stop-gap effort to try and quickly fill the 370 product pipeline (after failure of FS project) was 303x. The standard processor development cycle was 7-8yrs ... and they needed to get something out much quicker than that ... since starting the 370-xa/3081 wouldn't be out before the early 80s.
So they took they 370/158 microcode engine ... and stripped out the
370 microcode support ... leaving just the integrated channel
microcode and packaged it as the 303x "channel director". Then the
3031 was a 370/158 microcode engine with just the 370 microcode
support (and no integrated channel microcode) paired with a "channel
director". The 3032 was a 370/168-3 repackaged to work with "channel
director". The 3033 started out simply being 168 wiring diagram mapped
to newer chip technology. Recent posts about enormous effort to hurry
up and get 303x out the door after failed FS project:
https://www.garlic.com/~lynn/2007d.html#21 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007d.html#62 Cycles per ASM instruction
https://www.garlic.com/~lynn/2007e.html#32 I/O in Emulated Mainframes
https://www.garlic.com/~lynn/2007e.html#40 FBA rant
https://www.garlic.com/~lynn/2007f.html#28 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007f.html#73 Is computer history taught now?
https://www.garlic.com/~lynn/2007g.html#17 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007g.html#23 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007g.html#29 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007g.html#57 IBM to the PCM market(the sky is falling!!!the sky is falling!!)
https://www.garlic.com/~lynn/2007h.html#1 21st Century ISA goals?
the other aftermath of the FS project failure was that POK lab convinced corporate to shutdown the VM development group, decommit the product, and transfer all the people to POK in order to work on MVS/XA ... also attempting to shorten the typical development time. Endicott was eventually able to salvage the product mission and one or two of the people.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: ANN: Microsoft goes Open Source Newsgroups: alt.folklore.computers Date: Thu, 26 Apr 2007 12:25:55 -0600jmfbahciv writes:
this is analogous to reference in prior post about managers ... instead
of spending 90percent of their time with the 10percent least productive
employees (attempting to double their productivity) ... they should
spend 90percent of their time with the 10percent most productive
employees (attempting to double their productivity ... which frequently
could nearly double the overall group's total productivity).
https://www.garlic.com/~lynn/2007e.html#47 time spent/day on a computer
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Internal DASD Pathing Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Thu, 26 Apr 2007 13:42:49 -0600Bob.Richards@ibm-main.lst (Richards.Bob) writes:
3880 disk controller had four channel interfaces ... and 3380 "string switch" (a-box) allowed 3380 string to be connected to two different controllers for eight total paths.
Evolution of the DASD storage control
http://www.research.ibm.com/journal/sj/282/ibmsj2802C.pdf
not to be too harsh about comment in the above about 3880 having better
performance ... but some recent posts that touched on getting 3880 out
the door ... as well as little discussion of dynamic pathing
https://www.garlic.com/~lynn/2007h.html#1 21st Century ISA goals?
https://www.garlic.com/~lynn/2007h.html#3 21st Century ISA goals?
https://www.garlic.com/~lynn/2007h.html#4 21st Century ISA goals?
https://www.garlic.com/~lynn/2007h.html#5 21st Century ISA goals?
https://www.garlic.com/~lynn/2007h.html#6 21st Century ISA goals?
https://www.garlic.com/~lynn/2007h.html#9 21st Century ISA goals?
IBM Jargon:
A-Box n. A primary storage unit: the one closest to the controller.
Most 370 storage peripherals come in two flavours. The A-Box (also
called head of String, or Model A) either houses the controller
(e.g., 3422), is the controller (e.g., 3480), or connects to the
controller. The B-Box (Model B) is used for extending the string.
Some strings can be connected to the controller at both ends, in
which case the unit at the end of the string is usually a Model D.
... snip ...
3380 "history" here with A & B boxes:
http://www-03.ibm.com/ibm/history/exhibits/storage/storage_3380.html
http://www-03.ibm.com/ibm/history/exhibits/storage/storage_3380b.html
http://www-03.ibm.com/ibm/history/exhibits/storage/storage_3380c.html
minor mention of a-box, head-of-string function:
http://www-03.ibm.com/ibm/history/exhibits/storage/storage_3380d.html
http://www-03.ibm.com/ibm/history/exhibits/storage/storage_3380e.html
from above:
A string of Standard model 3380s can consist of a single 3380 Model A04
or AA4 and up to three 3380 Model B04 units. A string of Extended
Capability 3380s can consist of one 3380 Model AD4 or AE4 and up to
three 3380 Model BD4 and BE4 units, in any combination. Two strings of
3380s can be attached to each storage director of a 3880 Model 3 or
cache storage control Model 23. An A04 string is not supported by the
Model 23. Strings headed by an AA4, AD4 or AE4 must attach to two
storage directors (usually on two separate 3880 Storage Controls). An
AA4 string and an Extended Capability string can be attached to the same
storage directors.
... snip ...
at one point i made a forey into redoing the (3880) controller dynamic pathing architecture implementation ... as part of significantly extending & simplifying ("dynamic pathing simplification") capability for virtualized operation ... but got into all sort of issues regarding compatibility with implementation already in the field.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Internal DASD Pathing Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Thu, 26 Apr 2007 15:08:21 -0600Howard Brazee <howard@brazee.net> writes:
i had done some amount of the semi-automated computer conferencing
via email (copy list) mechanism on the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet
in the late 70s and early 80s ... and got blamed for something called
"tandem memos" (there was even a nov81 datamation article about tandem
memos). tandemo memos were somewhat spawned by various trip reports
visiting Tandem after Jim left SJR. somewhat recent postings referencing
Jim and his departure from SJR:
https://www.garlic.com/~lynn/2007.html#1 "The Elements of Programming Style"
https://www.garlic.com/~lynn/2007.html#13 "The Elements of Programming Style"
https://www.garlic.com/~lynn/2007d.html#17 Jim Gray Is Missing
somewhat as an outcome of various investigations into the "tandem memo" phenomena ... there were decisions to deploy officially sanctioned corporate computer conferencing capability.
there was also a researcher hired that sat in the back of my office for
nine months and studied how i communicated; phone, face-to-face, email,
instant messeging, etc. they had copies of my incoming and outgoing
email and logs of all instant messages. The resulting report was also
published as a stanford phd thesis (joint between ai and language) and
the subject matter for some number of papers and books. some related
posts mentioning computer mediated conferencing
https://www.garlic.com/~lynn/subnetwork.html#cmc
never got paid for it ... frequently closer to the opposite ... minor
reference:
https://www.garlic.com/~lynn/2007e.html#48 time spent/day on a computer
there were sometimes jokes in the mid-80s about various subject threads having gotten "wheeler'ized" ... i.e. when possibly 80-90% percent of the characters in some corporate/world wide discussion were found to originate from my keyboard. most consider that i have extremely mellowed since then ... and have been doing it for 30 yrs or so
somewhat drifting back to the original topic ... misc. collected
posts about getting to play in the disk engineering (bldg. 14)
and disk product test (bldg. 15) labs.
https://www.garlic.com/~lynn/subtopic.html#disk
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: ANN: Microsoft goes Open Source Newsgroups: alt.folklore.computers Date: Thu, 26 Apr 2007 15:51:46 -0600krw <krw@att.bizzzz> writes:
it wasn't intended to mean that time spent supporting the ten percent most productive ... was "managing" ... not in the "command and control" sense (ala Boyd's briefing on organic design for command and control). some study showed that effective managers anticipating and removing obsticals for their ten percent most productive ... may be able to improve their productivity by 50-100 percent (or sometimes more).
however, if unable to perform that duty ... then 2nd best is to just stay out of the way.
here is one from May87 ... my hard copies are from 83, i think we
may have gotten one of the first briefings of this shortly after
it had been created.
http://www.belisarius.com/
https://web.archive.org/web/20010722050327/http://www.belisarius.com/
misc. postings mentioning Boyd
https://www.garlic.com/~lynn/subboyd.html#boyd
and misc. URLs from around the web mentioning Boyd
https://www.garlic.com/~lynn/subboyd.html#boyd2
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Thu, 26 Apr 2007 16:18:35 -0600Anne & Lynn Wheeler <lynn@garlic.com> writes:
for even more drift, news item from today about the proliferation of (some) virtual appliances:
Parallels Technology Network announced
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9017923
from above:
Parallels, makers of the popular Parallels Desktop for Mac software that
enables Intel-based Macs to run Windows side-by-side without having to
reboot, on Thursday announced the Parallels Technology Network
(PTN). The goal of the new resource is to consolidate the efforts of
developers working on third-party Parallels 'Virtual
Appliances.'
... snip ...
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Internal DASD Pathing Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Thu, 26 Apr 2007 16:41:31 -0600re:
minor addenda ... to previous topic drift ... this index of old email
https://www.garlic.com/~lynn/lhwemail.html
also contains a URL for an eserver (since renamed IBM Systems) magazine article that appeared two yrs ago ... although they got some of the details slightly garbled. I actually haven't seen the copy of the physical magazine ... they had sent a photographer to the house for photo shoot ... and something from that supposedly shows up in the magazine.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies (Actually, Working under the table!) Newsgroups: alt.folklore.computers Date: Thu, 26 Apr 2007 17:58:33 -0600"Micheal H. McCabe" <mhmccabe@alltel.net> writes:
a dec91 article
TRW Awarded IRS Contract for Tax Systems Modernization
http://20www.unclefed.com/Tax-News/1991/Nr91-125.html
An aug94 report
http://www.eff.org/Infrastructure/Govt_docs/npr_it_082294.report
jun98 history
http://clinton3.nara.gov/pcscb/rmo_irs.html
may03 GAO report
http://www.gao.gov/htext/d03796t.html
a nov04 article
IRS modernization left with lean budget
http://www.gcn.com/online/vol1_no1/27990-1.html
feb2005 GAO high-risk update report:
http://www.gao.gov/htext/d05350t.html
includes
• IRS Business Systems Modernization[C].
feb2007 testimony
http://budget.senate.gov/democratic/testimony/2007/Everson_testimony021407.pdf
includes request of $282m for Business Systems Modernization in FY2008 budget.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Does anyone know of a documented case of VM being penetrated by hackers? Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers Date: Thu, 26 Apr 2007 18:32:57 -0600George Haddad wrote:
should have been mid-70s ... not late 80s ... at least on
the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet
from long ago and far away ...
Date: 80/12/16 10:52:11
To: wheeler
I never came back last night, but I did speak to XXXXXX about that
file. He points out that RSCS probably translates a pound sign to a
question mark for display (to eliminate problems with embedded
commands in messages, which caused some difficulty a few years ago).
So the file is probably ok; perhaps you can check with XXXXX and find
out.
By the way, what I did last night was to tune my oil burner. I
don't know how you people out there heat (on the 3 days a year
when the temperature gets below 68), but if you have an oil burner
(even just for hot water), you ought to look into doing a tune-up
on it. The lab here has a kit we can borrow for the purpose, and
in less than an hour I got the efficiency from 60% to about 74%.
... snip ... top of post, old email index
and now for some networking thing completely different from the late
80s
Date: 7 May 1987, 19:35:58 EDT
To: wheeler
From: somebody in corporate hdqtrs
Subject: Large Files...
Lynn:
We are getting requests to handle 500MB files.. EC releases, Chip
Designs, software, and documentation... (one group has a 3BB file
requirement!!).. Altho' the 500MB req't is coming within the next few
months...
Have you done any thinking during your HSDT work.. on what the limits
might be on large files.. compared to our networking software and
communication link capacity...??? I'm thinking that there must be a
limit... or a knee on the curve which says.. use a courier service..
rather than the network... Have you been able to develop any
attributes, characteristics, etc.. on 'large files'...that could be
helpful to planning and operating with these large files...??
... snip ... top of post, old email index, HSDT email
i.e. HSDT (high-speed data transport) was working with handling large
files ... recent post referencing helping contribute to bringing in
the RIOS chipset a year early
https://www.garlic.com/~lynn/2007f.html#73 Is computer history taught now?
https://www.garlic.com/~lynn/2007h.html#61 Fast and Safe C Strings: User friendly C macros to Declare and use C Strings
misc. posts mentioning HSDT activities ... dating back to
1980 time-frame
https://www.garlic.com/~lynn/subnetwork.html#hsdt
as well as some activity working with various people at
univ. and NSF ... old email:
https://www.garlic.com/~lynn/lhwemail.html#nsfnet
and misc. postings mentioning BITNET and/or EARN
https://www.garlic.com/~lynn/subnetwork.html#bitnet
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Best practices for software delivery Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Fri, 27 Apr 2007 09:30:34 -0600barry.a.schwarz@ibm-main.lst (Schwarz, Barry A) writes:
this was in the timeframe when we had been doing work w/NSF on what was
to become NSFNET (tcp/ip is the technology basis for the modern
internet, but we claim that NSFNET was the operational basis for the
modern internet, aka high-speed backbone providing internetworking of
networks). some of the old email on the subject from the period
https://www.garlic.com/~lynn/lhwemail.html#nsfnet
lots of past posts mentioning HSDT project
https://www.garlic.com/~lynn/subnetwork.html#hsdt
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Fri, 27 Apr 2007 10:25:52 -0600krw <krw@att.bizzzz> writes:
i believe that there is some number that possibly as much as 1/3rd of the population is "unbanked" ... in large part based on financial infrastructure cost structures (not so much financial infrastructure want the largest accounts ... but their cost structure doesn't easily support the lower end of the market).
earlier reference to financial infrastructure costs
https://www.garlic.com/~lynn/2007e.html#65 Securing financial transactions a high priority for 2007
misc. unbanked references (quick use of search engine)
Bringing Unbanked Households Into the Banking System
http://www.brook.edu/metro/capitalxchange/article10.htm
"Tapping the Unbanked Market" Symposium
http://www.fdic.gov/consumers/community/unbanked/index.html
Stored Value Cards: An Alternative for the Unbanked?
http://www.ny.frb.org/regional/stored_value_cards.html
Topics: Unbanked (Those without a bank account)
http://www.bos.frb.org/consumer/topics/unbanked.htm
Consumer Spending Trends of Banked, Unbanked Prepaid Cardholders
http://www.paymentsnews.com/2006/07/consumer_spendi.html
Reaching Out to The Unbanked; A high-tech alternative to traditional
banking
http://usgovinfo.about.com/library/weekly/aa031001a.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Fri, 27 Apr 2007 11:05:21 -0600Anne & Lynn Wheeler <lynn@garlic.com> writes:
it has (also) been suggested that one of the reasons for the stiff resistant to all the rounds of walmart getting into financial services (over the last decade or so) ... including the latest round with walmart buying an Utah ILC ... is that walmart might change the cost/fee structure in the financial industry
there supposedly was testimony on the flr of the senate in the 90s
... that the purpose of the bank modernization act was so that if you
were already bank, you got to stay a bank, and if you weren't already
a bank, you wouldn't be able to become a bank (specifically m'soft and
walmart) ... old post making reference:
https://www.garlic.com/~lynn/2006k.html#49 Value of an old IBM PS/2 CL57 SX Laptop
quicky use of search engine
Scott's Wal-Mart Defends Banking Plan
http://www.forbes.com/facesinthenews/2006/04/10/walmart-banking-utah-cx_po_0410autofacescan03.html
Congress May End Wal-Mart's Banking Dreams
http://www.consumeraffairs.com/news04/2006/07/congress_walmart_bank.html
Finding Niche Helps New Utah ILC Gain Foothold
http://www.banknet360.com/news/NewsAbstract.do?na_id=6726
Withdrawal of 'Wal-Mart Bank' Bid Called 'Wise Choice'
http://www.cnsnews.com/ViewNation.asp?Page=/Nation/archive/200703/NAT20070319a.html
above references include claim that the Utah ILC was targeted at
reducing debit/credit costs (i.e. their Utah ILC could be their own
financial acquiring institution, as opposed to being used for consumer
branch banking, the debit/credit fees wouldn't change ... but would be
paid to themselves). this would be consistent with their class-action
anti-trust litigation ... prior reference
https://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Latest Principles of Operation Newsgroups: bit.listserv.ibm-main,alt.folklore.compters Date: Fri, 27 Apr 2007 13:52:36 -0600Howard Brazee <howard@brazee.net> writes:
as an undergraduate ... i did fair share scheduler for cp67 ... or
actually dynamic adaptive resource management ... with default
policy being fair share; minor recent reference:
https://www.garlic.com/~lynn/2007h.html#77 Linux: The Completely Fair Scheduler
https://www.garlic.com/~lynn/2007i.html#1 Linux: The Completely Fair Scheduler
https://www.garlic.com/~lynn/2007i.html#2 Linux: The Completely Fair Scheduler
but also did a lot of highly optimized pathlength and fastpath stuff. I made jokes about being able to do stuff in zero instructions ... carefully tweaking instructions all over the kernel so that various things happened implicitly ... so scheduler didn't actually have to execute instructions to obtain the desired results (secondary effects of the order of how other things are occurring, of course it helps if you effectively have memorized the source for the complete kernel ... all assembler).
over some yrs, there was complaints that nobody could understand how it worked ... which probably contributed to a lot of it being dropped (simplified) in the morph from cp67 to vm370.
so possibly still part of the recovery in the aftermath of future system
project ... recent reference in this post
https://www.garlic.com/~lynn/2007i.html#31 Latest Principles of Operation
I was given the opportunity to reintroduce the resource manager for
vm370 ... among other things, another recent post
https://www.garlic.com/~lynn/2007i.html#21 John W. Backus, 82, Fortran developer, dies
... more topic drift ...
however, they decided that the resource manager should be guinea pig to
starting to charge for kernel code ... so i had to spend some amount
of time with the business and legal people working on policy for
charging for kernel software; i.e. 23jun69 unbundling announcement
started charging for application software ... but they used the excuse
that kernel software was integral to hardware operation and should
still be "free" ... misc. past posts
https://www.garlic.com/~lynn/submain.html#unbundle
... slightly return to topic ...
now, i did fix up some of the more obtuse pieces of (assembler) code ... but there still was quite a bit of complexity in the resource manager ... and people over the yrs would complain that they didn't understand how it worked ... and periodically somebody would make changes in other parts of the kernel resulting in unexplicable affects on scheduling (there was still quite a bit of convoluted code that I justified on being able to do things in fewer instructions and shorter pathlength).
so there was one fly in the ointment, somebody from corporate complained that there weren't any tuning parameters ... which was the state of the art in other products; ... namely the favorite son operating system of the period had a massive table of tuning parameters ... and there were this presentations at SHARE (could put everybody to sleep) about random walks across the tuning parameter table landscape, varying the parameters for all different kinds of workloads and configurations ... attempting to find settings that made some difference.
So I was forced to put in some tuning parameters (before product ship), document them and the backup formulas ... as well as detailed code explanation.
so we roll forward nearly 20yrs ... we are on a marketing swing thru
the far east for our ha/cmp product
https://www.garlic.com/~lynn/subtopic.html#hacmp
also additional thread drift
https://www.garlic.com/~lynn/95.html#13
https://www.garlic.com/~lynn/96.html#15
and
https://www.garlic.com/~lynn/lhwemail.html#medusa
... and we are on a call at a large financial institution. One of the people at the meeting (relatively recent graduate) pipes up and asks if i'm the same person associated with the scheduler ... since they had studied me/it at the Univ. of Waterloo.
So I respond politely and asked if the "joke" was discussed.
Now part of the issue with static tuning parameters is that workloads tend to vary from minute-to-minute, day-to-day, week-to-week ... and there was a whole lot of effort that went into the dynamic adaptive implementation to eliminate the requirement for any static tuning parameters. Being forced to add static tuning parameters seemed to be a great step backward in the state-of-the-art. So as to the "joke" ... if dynamic adaptive can adjust for changes in configurations and workloads ... as well as a lot of other things ... why couldn't the dynamic adaptive implementation also adjust to compensate for changes in any static tuning parameters????
misc. past posts mentioning the resource manager "joke":
https://www.garlic.com/~lynn/2001b.html#18 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
https://www.garlic.com/~lynn/2001l.html#9 mainframe question
https://www.garlic.com/~lynn/2002c.html#16 OS Workloads : Interactive etc
https://www.garlic.com/~lynn/2002c.html#54 Swapper was Re: History of Login Names
https://www.garlic.com/~lynn/2002i.html#53 wrt code first, document later
https://www.garlic.com/~lynn/2004o.html#10 Multi-processor timing issue
https://www.garlic.com/~lynn/2005p.html#31 z/VM performance
https://www.garlic.com/~lynn/2006b.html#21 IBM 3090/VM Humor
https://www.garlic.com/~lynn/2006h.html#22 The Pankian Metaphor
https://www.garlic.com/~lynn/2006y.html#17 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2007g.html#56 The Perfect Computer - 36 bits?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: latest Principles of Operation Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Fri, 27 Apr 2007 16:14:09 -0600ibm-main@ibm-main.lst (Shane) writes:
part of the complexity issue is possible number of things and/or interactions that have to be managed. it is one of the reasons for modular code. it also one of the reasons for hierarchical management infrastructure and recommendations about "span of control" ... ideal number of direct reports is supposedly seven. fully-meshed interaction complexity is something like N-factorial (i.e. 7! is already 5040).
when were consulting with small client/server company on
the original payment gateway
https://www.garlic.com/~lynn/subnetwork.html#gateway
one of the things that we were doing was making the whole gateway
operation redundant, including multiple links into strategic places in
the internet backbone ... and planning on advertising (alternate)
routes in cases of faults. It was in this time-frame that internet
backbone transitioned to hierarchical routing ... in attempting to deal
with some of the massive scaling complexity issues. As a result, we had
to convert to multiple A-record strategy (for alternate paths) as opposed
to strategy advertising routes. recent post
https://www.garlic.com/~lynn/2007h.html#67 SSL vs. SSL over tcp/ip
in the previous post
https://www.garlic.com/~lynn/2007i.html#43 Latest Principles of Operation
I had enormously increased the complexity by creating an environment were the particular order of any set of (assembler) instructions, any place the kernel might have secondary effects on other things in the kernel, not only have to take into account individual instruction operation and the purely sequential flow ... but there might be (non-obvious) secondary effects based possibly on the order that things were performed.
In the early 80s, I had done a dump analysis tool
https://www.garlic.com/~lynn/submain.html#dumprx
recent reference
https://www.garlic.com/~lynn/2007i.html#30 John W. Backus, 82, Fortran developer, dies
which was never released as a product, but eventually was in use at nearly all the internal datacenters as well as being used by nearly all the PSRs that were involved in diagnosing (vm) failures kinds at customer shops.
One of the things that I studied was large number of system failures looking for familiar and/or common signatures ... and writing automatic diagnostic processes that looked for numerous, identifiable failure characteristics.
One such problem, somewhat unique to assembler is the additional burden/complexity that is placed on the programmer for managing register contents. A failure mode that I found to occur quite frequently in kernel assembler code was register contents were not as expected ... possibly because of logic flow taking a particular anomolous path. Higher level languages tend to automate that area of complexity (register) management for the programmer ... and failures due to incorrect register contents occur significantly less frequently.
This analysis was one of my motivations behind helping instigate a
operating system rewrite project ... with an objective that included
significantly reducing complexity (and possibility for failures).
some recent references to the operating system rewrite project (which
eventually acquired way to much attention, eventually imploding
... somewhat analogous to a "mini" FS failure). misc. recent
references to the old rewrite effort:
https://www.garlic.com/~lynn/2007g.html#70 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#24 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#57 ANN: Microsoft goes Open Source
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM System/360 Model 85: The Bashful Computer Newsgroups: alt.folklore.computers Date: Fri, 27 Apr 2007 18:31:17 -0600Quadibloc <jsavard@ecn.ab.ca> writes:
misc. past refs:
https://www.garlic.com/~lynn/2004o.html#18 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2005h.html#22 Today's mainframe--anything to new?
https://www.garlic.com/~lynn/2006r.html#2 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006t.html#41 The Future of CPUs: What's After Multi-Core?
misc. past refs:
https://www.garlic.com/~lynn/2004o.html#18 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2005h.html#22 Today's mainframe--anything to new?
https://www.garlic.com/~lynn/2006r.html#2 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006t.html#41 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2007f.html#10 Beyond multicore
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Linux: The Completely Fair Scheduler Newsgroups: alt.folklore.computers Date: Fri, 27 Apr 2007 19:59:11 -0600<mike@emgee.demon.co.uk> writes:
here is long winded post with reference to class at univ. of Waterloo
https://www.garlic.com/~lynn/2007i.html#43 Latest Principles of Operation
lots of past posts mentioning resource manager
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/2007f.html#10 Beyond multicore
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Sat, 28 Apr 2007 08:58:11 -0600jmfbahciv writes:
GM, ATT, and some others ... issued corporate "branded" cards to
consumers. GM also offered "awards" ... based on how much you used the
card, you got points that took down the price of buying any new GM
car. For some topic drift, Ford also had a card issuing unit called the
"Associates" that issued cards (that weren't Ford branded). A few yrs
ago, the "Associates" was sold off to citigroup ... associates timeline
(Ford buys Associates in 1989 and sell it to citigroup in 2000)
http://www.citigroup.com/citigroup/corporate/history/data/associates.htm
Cards are considered to have five participants, 1) consumer, 2) "issuing" financial institution (i.e. bank that issues the card to the consumer, and is financially responsible for the consumer), 3) the card association, 4) the "acquiring" finanical institution (i.e. bank that sponsors the merchant to accept cards and is financially responsible for the merchant), and 5) the merchant.
GM, ATT, etc, were considered "2", issuing financial institution.
in the reference post here:
https://www.garlic.com/~lynn/2006k.html#49 Value of an old IBM PS/2 CL57 SX Laptop
there is reference to walmart's successful class-action anti-trust suit against the card association primarily around the card rules and "interchange fees" ... i.e. the amount that is taken out of what the issuing bank sends to the merchant for all the card charges. "interchange fees" is a combination of a flat per transaction fee plus a percentage of the amount charged. Part of the interchange fees go to the "acquiring" financial institution, part goes to the "card association", and part gets to be kept by the "issuing" financial institution.
In this reference here
https://www.garlic.com/~lynn/2007i.html#42 John W. Backus, 82, Fortran developer, dies
walmart said that it would be setting up the Utah ILC for purposes of only being an "acquiring" financial institution for them, sponsoring walmart ability to do/accept card transactions. In addition to the successful anti-trust suit, this would be another way of reducing the effective total costs to walmart (as a merchnat) for accepting card transactions.
other past posts mentioning interchange fees:
https://www.garlic.com/~lynn/aadsm7.htm#rhose3 Rubber hose attack
https://www.garlic.com/~lynn/aadsm23.htm#37 3 of the big 4 - all doing payment systems
https://www.garlic.com/~lynn/aadsm26.htm#1 Extended Validation - setting the minimum liability, the CA trap, the market in browser governance
https://www.garlic.com/~lynn/aadsm26.htm#25 EV - what was the reason, again?
https://www.garlic.com/~lynn/2005u.html#16 AMD to leave x86 behind?
https://www.garlic.com/~lynn/2006k.html#23 Value of an old IBM PS/2 CL57 SX Laptop
https://www.garlic.com/~lynn/2007.html#27 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#38 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies
and specifically this post:
https://www.garlic.com/~lynn/2007c.html#38 Securing financial transactions a high priority for 2007
also includes a reference to an article that "interchange fees" are the largest expense for C-stores, larger even than labor or any other item.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Sat, 28 Apr 2007 09:17:37 -0600re:
and for other drift, past posts mentioning acquiring financial
institution
https://www.garlic.com/~lynn/aadsm2.htm#mcomfort Human Nature
https://www.garlic.com/~lynn/aepay3.htm#votec (my) long winded observations regarding X9.59 & XML, encryption and certificates
https://www.garlic.com/~lynn/aepay3.htm#sslset1 "SSL & SET Query" ... from usenet group
https://www.garlic.com/~lynn/aepay3.htm#sslset2 "SSL & SET Query" ... from usenet group
https://www.garlic.com/~lynn/aepay3.htm#x959luid X9.59 LUID comment resolution
https://www.garlic.com/~lynn/aepay4.htm#miscdns misc. other DNS
https://www.garlic.com/~lynn/aadsm5.htm#asrn3 Assurance, e-commerce, and some x9.59 ... fyi
https://www.garlic.com/~lynn/aadsm5.htm#x915 Ballot for Withdrawal of X9.15 Posted - X9/01-LB#7-X9A/01-LB#3
https://www.garlic.com/~lynn/aadsm6.htm#terror7 [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aadsm6.htm#terror10 [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aadsm6.htm#terror13 [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aepay10.htm#41 ATM Scams - Whose Liability Is It, Anyway?
https://www.garlic.com/~lynn/aadsm11.htm#0 Basic credit-card payment question
https://www.garlic.com/~lynn/aadsm11.htm#29 Proposal: A replacement for 3D Secure
https://www.garlic.com/~lynn/aadsm11.htm#30 Proposal: A replacement for 3D Secure
https://www.garlic.com/~lynn/aadsm11.htm#31 Proposal: A replacement for 3D Secure
https://www.garlic.com/~lynn/aadsm18.htm#15 In Search of Eve - the upper boundary on Mallory
https://www.garlic.com/~lynn/aadsm22.htm#18 "doing the CA statement shuffle" and other dances
https://www.garlic.com/~lynn/aadsm22.htm#19 "doing the CA statement shuffle" and other dances
https://www.garlic.com/~lynn/aadsm26.htm#26 man in the middle, SSL
https://www.garlic.com/~lynn/2000f.html#22 Why trust root CAs ?
https://www.garlic.com/~lynn/2004i.html#16 New Method for Authenticated Public Key Exchange without Digital Ceritificates
https://www.garlic.com/~lynn/2005o.html#41 Certificate Authority of a secured P2P network
https://www.garlic.com/~lynn/2007.html#6 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007h.html#32 sizeof() was: The Perfect Computer - 36 bits?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Sat, 28 Apr 2007 10:04:58 -0600Andrew Swallow <am.swallow@btopenworld.com> writes:
Nearly all DBMS implementations have made heavy use of multi-threaded operation ... being able to switch between transactions ... especially while waiting for transactions that are blocked/stalled performing disk operations.
more recently it has also been used for hardware implementations that emulate multiple processors when there is only a real single processor. the hardware scenario has been used to compensate for various things that stall the processor execution (say cache miss) ... allowing the processor to switch to another execution (emulated processor) that might not be stalled.
i've mentioned that this was worked on for 370/195 back in the 70s ...
in part because most codes ran about half 195 peak processing rate
(because of various processor stalls). having two processor "threads"
running concurrently had a chance of keeping 195 running at peak
processing thruput. recent reference
https://www.garlic.com/~lynn/2007i.html#45 IBM System/360 Model 85: The Bashful Computer
Charlie had invented the compare&swap instruction at the science
center
https://www.garlic.com/~lynn/subtopic.html#545tech
when he was working on fine-grain kernel locking for cp67 multiprocessor
support. there was some reluctance to include compare&swap in 370
architecture ... claiming that a purely multiprocessor instruction
couldn't be justified. In order to get justification for compare&swap,
uses had to be invented that weren't specifically multiprocessor
oriented, recent reference
https://www.garlic.com/~lynn/2007i.html#31 Latest Principles of Operation
as a result, the use of compare&swap for (software) multi-threaded
(i.e. mainframe "multiprogramming") was invented. lots of past
posts mentioning smp multiprocessor support and/or compare&swap
instruction
https://www.garlic.com/~lynn/subtopic.html#smp
Example uses for the compare&swap instruction were included in 370 Principles of Operation as programming notes. This programming notes now appear in the appendix of Principles of Operation ... recent reference:
A.6 Multiprogramming and Multiprocessing Examples
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/A.6?SHELF=DZ9ZBK03&DT=20040504121320
The "multiprogramming" examples show how compare&swap can be used to coordinate the operation of multiple threads w/o having to make calls into the kernel (eliminating the associated overhead of kernel calls).
You can have application (like DBMS) running multiple concurrent threads. If the operation is on a single-processor machine ... only one thread will happen to be running at any moment at time. However, if the operation is a real multiprocessor machine ... the application might have multiple threads running concurrently on the different processors.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Sat, 28 Apr 2007 10:15:37 -0600Anne & Lynn Wheeler <lynn@garlic.com> writes:
for a whole lot of topic drift ... many DBMS implementations also provide support for distributed operation and distributed lock operation ... i.e. processing across multiple processors that don't share physical memory.
some recent posts mentioning distributed DBMS operation and/or
distributed lock operation
https://www.garlic.com/~lynn/2006c.html#8 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006c.html#41 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006j.html#20 virtual memory
https://www.garlic.com/~lynn/2006o.html#32 When Does Folklore Begin???
https://www.garlic.com/~lynn/2006o.html#62 Greatest Software, System R
https://www.garlic.com/~lynn/2006x.html#3 Why so little parallelism?
https://www.garlic.com/~lynn/2006x.html#18 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2007c.html#42 Keep VM 24X7 365 days
some old posts mentioning some scale-up work with regard to distributed
database and distributed locking
https://www.garlic.com/~lynn/95.html#13
https://www.garlic.com/~lynn/96.html#15
and old email about working on scale-up work in distributed operation
https://www.garlic.com/~lynn/lhwemail.html#medusa
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Sat, 28 Apr 2007 10:29:20 -0600Frank McCoy <mccoyf@millcomm.com> writes:
the "signature debit" issue also came up in the walmart class-action
anti-trust suit against the card association. recent posts
https://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#42 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#47 John W. Backus, 82, Fortran developer, dies
other past posts mentioning signature debit operation
https://www.garlic.com/~lynn/aepay3.htm#x959risk2 Risk Management in AA / draft X9.59
https://www.garlic.com/~lynn/aadsm6.htm#echeck Electronic Checks
https://www.garlic.com/~lynn/aadsm9.htm#cfppki2 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm9.htm#cfppki9 CFP: PKI research workshop
https://www.garlic.com/~lynn/aepay10.htm#10 InfoSpace Buys ECash Technologies
https://www.garlic.com/~lynn/aadsm22.htm#22 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm26.htm#6 Citibank e-mail looks phishy
https://www.garlic.com/~lynn/2004i.html#18 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2005u.html#14 AMD to leave x86 behind?
https://www.garlic.com/~lynn/2005u.html#16 AMD to leave x86 behind?
https://www.garlic.com/~lynn/2006e.html#4 When *not* to sign an e-mail message?
https://www.garlic.com/~lynn/2006e.html#21 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006e.html#24 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006u.html#48 New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2006v.html#1 New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2007.html#0 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007b.html#64 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#18 Securing financial transactions a high priority for 2007
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Sat, 28 Apr 2007 12:06:39 -0600Bernd Felsche <bernie@innovative.iinet.net.au> writes:
Tricky spelling drains the brain
http://www.newscientist.com/article/dn11731-tricky-spelling-drains-the-brain.html
from above:
Spelling tricky words -- such as "yacht" -- is no day at the beach, it
seems. New brain-scan images have shown how our minds struggle when the
sound of the word does not closely match its spelling.
... snip ...
How plastic is your brain? UH engineer seeks answers
http://www.physorg.com/news96911031.html
from above:
It may seem easy to change your mind, but if it's your brain we're
talking about, maybe it's harder than we think. A University of Houston
professor is looking into this with research into something called
'brain plasticity.'
... snip ...
and of course ... recent topic drift into arena of complexity
https://www.garlic.com/~lynn/2007i.html#44 latest Principles of Operation
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Sat, 28 Apr 2007 12:10:28 -0600pechter@pechter.dyndns.org (William Pechter) writes:
including reference in the above to
Laptops And Flat Panels Now Vulnerable to Van Eck Methods
http://hardware.slashdot.org/hardware/07/04/20/2048258.shtml
Seeing through walls
http://www.newscientist.com/blog/technology/2007/04/seeing-through-walls.html
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Sat, 28 Apr 2007 13:59:33 -0600Anne & Lynn Wheeler <lynn@garlic.com> writes:
and for other drift ... there is some correspondence between application stalls ... waiting for disks ... and processor stalls (on cache miss) waiting for main memory.
in the late 70s, I had started making comments about relative system
disk thruput declining by an order of magnitude over more than a
decade. Some disk division executives didn't appreciate the comment
and assigned the performance & modeling group to refute the
statement. After a couple weeks they came back and observed that I had
slightly understated the problem. Part of this was apparent from all
the work on dynamic adaptive resource management ... and a subpart of
it that I called scheduling to the bottleneck ... aka part of
dynamic adaptive resource management was identifying major system
thruput bottlenecks (and same code could reasonably adapt across a
wide-range of configuration as well as computer technology over
periods of years or decades). The relative thruput of various system
components had changed since the late 60s when I had first started
work on dynamic adaptive resource management (and therefor the major
system bottlenecks had also shifted). Some recent posts mentioning
dynamic adaptive resource management:
https://www.garlic.com/~lynn/2007h.html#77 Linux: The Completely Fair Scheduler
https://www.garlic.com/~lynn/2007i.html#1 Linux: The Completely Fair Scheduler
https://www.garlic.com/~lynn/2007i.html#2 Linux: The Completely Fair Scheduler
https://www.garlic.com/~lynn/2007i.html#7 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#43 Latest Principles of Operation
https://www.garlic.com/~lynn/2007i.html#46 Linux: The Completely Fair Scheduler
part of the compensation for the degrading relative system thruput of
disks was to leverage the significant increases in real memory sizes for
caching. part of this can be seen in the early 80s with the start in the
update in relational DBMS. One of the things that System/R had done was
eliminate the direct record pointer management (exposed as part of the
paradigm that applications dealt with in the "physical" DBMS from the
60s) with indexes that were part of the underlying operation (implicit,
automatically managed, and applications no longer had to directly deal
with). The pros & cons ... the STL "60s" dbms people claimed that RDBMS
typically doubled the physical disk requirements for a database (because
of the space needed for the indexes) and drastically increased the
number of physical I/Os (reading the indexes). The SJR, RDBMS people
claimed that changing the exposed record pointer to implicit indexes
significantly simplified the management, administration, and use of
databases. lots of past posts mentioning system/r
https://www.garlic.com/~lynn/submain.html#systemr
Changes in the early 80s was significant increase in disk capacity and significant decrease in price per disk mbyte (mitigating the disk space for indexes issue) and the significant increase in real storage sizes that could be leveraged to cache the indexes (eliminating the significant physical disk i/o operations needing to read index records).
misc. recent posts mentioning system/r (and some of the trade-off
issues changing between the 70s and 80s with regard to disks):
https://www.garlic.com/~lynn/2007.html#1 "The Elements of Programming Style"
https://www.garlic.com/~lynn/2007b.html#16 V2X2 vs. Shark (SnapShot v. FlashCopy)
https://www.garlic.com/~lynn/2007b.html#31 IBMLink 2000 Finding ESO levels
https://www.garlic.com/~lynn/2007b.html#58 Authentication architecture on a Unix Network
https://www.garlic.com/~lynn/2007c.html#42 Keep VM 24X7 365 days
https://www.garlic.com/~lynn/2007d.html#6 Jim Gray Is Missing
https://www.garlic.com/~lynn/2007d.html#17 Jim Gray Is Missing
https://www.garlic.com/~lynn/2007d.html#27 modern paging
https://www.garlic.com/~lynn/2007d.html#37 MAC and SSL
https://www.garlic.com/~lynn/2007e.html#1 Designing database tables for performance?
https://www.garlic.com/~lynn/2007e.html#14 Cycles per ASM instruction
https://www.garlic.com/~lynn/2007e.html#31 Quote from comp.object
https://www.garlic.com/~lynn/2007e.html#36 Quote from comp.object
https://www.garlic.com/~lynn/2007e.html#37 Quote from comp.object
https://www.garlic.com/~lynn/2007e.html#63 FBA rant
https://www.garlic.com/~lynn/2007f.html#10 Beyond multicore
https://www.garlic.com/~lynn/2007f.html#11 Is computer history taught now?
https://www.garlic.com/~lynn/2007f.html#14 more shared segment archeology
https://www.garlic.com/~lynn/2007f.html#16 more shared segment archeology
https://www.garlic.com/~lynn/2007f.html#54 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007f.html#66 IBM System z9
https://www.garlic.com/~lynn/2007g.html#25 Bidirectional Binary Self-Joins
https://www.garlic.com/~lynn/2007h.html#61 Fast and Safe C Strings: User friendly C macros to Declare and use C Strings
misc. past posts observing the change in primary/major system thruput
bottlenecks over period of some decades:
https://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
https://www.garlic.com/~lynn/94.html#43 Bloat, elegance, simplicity and other irrelevant concepts
https://www.garlic.com/~lynn/94.html#55 How Do the Old Mainframes Compare to Today's Micros?
https://www.garlic.com/~lynn/95.html#10 Virtual Memory (A return to the past?)
https://www.garlic.com/~lynn/98.html#46 The god old days(???)
https://www.garlic.com/~lynn/99.html#4 IBM S/360
https://www.garlic.com/~lynn/2001d.html#66 Pentium 4 Prefetch engine?
https://www.garlic.com/~lynn/2001f.html#62 any 70's era supercomputers that ran as slow as today's supercomputers?
https://www.garlic.com/~lynn/2001f.html#68 Q: Merced a flop or not?
https://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
https://www.garlic.com/~lynn/2001l.html#61 MVS History (all parts)
https://www.garlic.com/~lynn/2001m.html#23 Smallest Storage Capacity Hard Disk?
https://www.garlic.com/~lynn/2002.html#5 index searching
https://www.garlic.com/~lynn/2002b.html#11 Microcode? (& index searching)
https://www.garlic.com/~lynn/2002b.html#20 index searching
https://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
https://www.garlic.com/~lynn/2002e.html#9 What are some impressive page rates?
https://www.garlic.com/~lynn/2002i.html#16 AS/400 and MVS - clarification please
https://www.garlic.com/~lynn/2003i.html#33 Fix the shuttle or fly it unmanned
https://www.garlic.com/~lynn/2004n.html#22 Shipwrecks
https://www.garlic.com/~lynn/2004p.html#39 100% CPU is not always bad
https://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
https://www.garlic.com/~lynn/2006m.html#32 Old Hashing Routine
https://www.garlic.com/~lynn/2006x.html#13 The Future of CPUs: What's After Multi-Core?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Sat, 28 Apr 2007 14:27:42 -0600Frank McCoy <mccoyf@millcomm.com> writes:
the issue was that customers having gotten use to "free" amd weren't
easily going to give it up. the problem is that nothing is free,
financial transactions cost ... in people time, infrastructure
operations, computers, etc. ... i.e. earlier reference to analysing
summary of financial institution operational costs
https://www.garlic.com/~lynn/2007e.html#65 Securing financial transactions a high priority for 2007
So the financial institution had to be able to cover the cost in some manner ... things like difference between what was being credited to the account for interest and what the financial institution was able to earn on the money in the account (it bears a little resemblance to crooks saying stealing money from insurance companies doesn't actually hurt anybody ... the money has to come from someplace ... it doesn't materialize out of thin air).
So the choices were to carry the e-check thru
1) the debit network, transaction is immediate, tends to be ISO8583 standard network ... similar to credit network (and sometimes they can use the same terminals at point-of-sale)
2) the ACH network, transaction can take 24-48 hrs to "clear".
Now, in the checking world, there is this thing called "float" ... the difference between the date of the check and when the check actually clears/settles. "Float" is one of the places that financial institutions can recover money to help underwrite the costs of their (especially checking) operations.
So many of the financial institutions wanted e-check to operate thru the ACH network ... where there is some float ... as opposed to the debit network ... where there effectively is no float.
for additional drift ... x9.59 financial standard protocol
https://www.garlic.com/~lynn/x959.html#x959
and old mapping x9.59 transactions to iso8583
https://www.garlic.com/~lynn/8583flow.htm
past posts mentioning financial, banks, transactions etc in this thread:
https://www.garlic.com/~lynn/2007h.html#76 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#78 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#0 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#5 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#8 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#9 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#12 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#19 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#28 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#41 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#42 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#47 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#48 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#51 John W. Backus, 82, Fortran developer, dies
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Sat, 28 Apr 2007 15:13:44 -0600Brian Inglis <Brian.Inglis@SystematicSW.Invalid> writes:
....
we were also asked to consult on designing a targeted market offering based on recent 15-18month credit transactions ... i.e. rather than use demographics to guess at buying habits ... it was using buying habits to guess at buying habits. the thing was also being audited by dozen or so different privacy organizations ... to guarantee that nobody's privacy was violated in making/determining the target market offerings. the initial pass involved a small pilot with something like 60mil accounts and something like 1.5million transactions per day ... being able to scale up to something like ten times as many accounts and possibly 20 times as many transactions per day (peak buying season). scale-up was an interesting issue.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Sat, 28 Apr 2007 15:43:29 -0600re:
a little more topic drift about financial infrastructure costs
slightly related recent posting here
https://www.garlic.com/~lynn/2007i.html#56 John W. Backus, 82, Fortran developer, dies
mentioning having consulted with small client/server startup wanting to be able to do payment transactions
... we also were asked to do operational system design and the
operational costing (i.e. what would the costs be to operate such a
service) for DEC's millicent ... a little topic drift from the same
organization that brought you altavista ... some millicent refs:
http://www.cs.newcastle.edu.au/Research/MSEG/visual/millicent/milli.html
http://www.soe.ucsc.edu/~abadi/Papers/millicent.html
http://www.xent.com/FoRK-archive/winter96/0690.html
http://www.jerrypournelle.com/slowchange/Millicent.html
as well as a similar task (design & cost) for deploying MONDEX in the states.
some old posts mentioning mondex
https://www.garlic.com/~lynn/aadsm6.htm#digcash IP: Re: Why we don't use digital cash
https://www.garlic.com/~lynn/aadsm7.htm#idcard2 AGAINST ID CARDS
https://www.garlic.com/~lynn/aepay6.htm#cacr7 7th CACR Information Security Workshop
https://www.garlic.com/~lynn/aadsm18.htm#42 Payment Application Programmers Interface (API) for IOTP
https://www.garlic.com/~lynn/aadsm20.htm#7 EMV
https://www.garlic.com/~lynn/aadsm21.htm#1 Is there any future for smartcards?
https://www.garlic.com/~lynn/aadsm23.htm#23 Payment systems - the explosion of 1995 is happening in 2006
https://www.garlic.com/~lynn/aadsm25.htm#31 On-card displays
https://www.garlic.com/~lynn/2002e.html#14 EMV cards
https://www.garlic.com/~lynn/2002e.html#18 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002g.html#53 Are you sure about MONDEX?
https://www.garlic.com/~lynn/2002g.html#54 Are you sure about MONDEX?
https://www.garlic.com/~lynn/2004j.html#12 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2004j.html#14 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2005i.html#10 Revoking the Root
https://www.garlic.com/~lynn/2005v.html#1 Is Mondex secure?
https://www.garlic.com/~lynn/2007b.html#47 newbie need help (ECC and wireless)
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Sat, 28 Apr 2007 18:28:14 -0600"Robert" <sabu77@comcast.net> writes:
has a little more explanation on this site about debit cards
(what they say and what they have to do, or actually do,
may not be the same)
http://www.pirg.org/consumer/banks/debit/debitcards1.htm
discussion here:
http://www.in.gov/dfi/education/Money_Smart/debit_cards.htm
FTC website:
http://www.ftc.gov/bcp/conline/pubs/online/payments.shtm
from above:
For debit: The EFTA applies to electronic fund transfers -- transactions
involving automated teller machines (ATMs), debit cards and other
point-of-sale debit transactions, and other electronic banking
transactions that can result in the withdrawal of cash from your bank
account.
Lost or stolen debit cards: If someone uses your debit card, or makes
other electronic fund transfers, without your permission, you can lose
from $50 to $500 or more, depending on when you report the loss or
theft. If you report the loss within two business days after you
discover the problem, you will not be responsible for more than $50 for
unauthorized use. However, if you do not report the loss within two
business days after you realize the card is missing, but you do report
its loss within 60 days after your statement is mailed to you, you could
lose as much as $500 because of an unauthorized withdrawal. And, if you
do not report an unauthorized transfer or withdrawal within 60 days
after your statement is mailed to you, you risk unlimited loss. That
means you could lose all the money in your account and the unused
portion of your maximum line of credit established for overdrafts.
Some financial institutions may voluntarily cap your liability at $50
for certain types of transactions, regardless of when you report the
loss or theft; because this is voluntary, their policies could change at
any time. Ask your financial institution about its liability limits.
EFT errors: The EFTA's error procedures apply to certain
problems. This can include:
• electronic fund transfers that you -- or anyone you've authorized to
use your account -- have not made;
• incorrect electronic fund transfers;
* omitted electronic fund transfers;
• a failure to properly reflect electronic fund transfers; and
• electronic fund transfers for which you request an explanation or
documentation, because of a possible error.
To take advantage of the EFTA's error resolution procedures, you
must notify your financial institution of the problem not later than 60
days after the statement containing the problem or error was
sent. Although most financial institutions have a toll-free number to
report the problem, you should follow-up in writing. For retail
purchases, your financial institution has up to 10 business days to
investigate after receiving your notice of the error. The financial
institution must tell you the results of its investigation within three
business days of completing its investigation. The error must be
corrected within one business day after determining the error has
occurred. If the institution needs more time, it may take up to 90 days,
in many situations, to complete the investigation -- but only if it
returns the money in dispute to your account within 10 business days
after receiving notice of the error, while it reviews your concerns.
... snip ...
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Sun, 29 Apr 2007 18:32:02 -0600"Robert" <sabu77@comcast.net> writes:
i.e. as in previous references ... financial institutions charge significantly more for signature-debit than pin-debit (through the higher fees that they can charge merchants) ... even though signature-debit fraud & related infrastructure cost is significantly higher than pin-debit
Study: Signature Debit Fraud Runs 15 Times Higher Than on PIN Debit
http://www.digitaltransactions.net/newsstory.cfm?newsid=738
effectively being able to recover all expenses from the merchants in the
interchange fees charged (aka at the same time signature-debit has more
fraud and is more costly infrastructure while also being more profitable
for financial institutions). since this is so profitable for the
financial institutions ... it makes sense that they would attempt to
minimize consumer fears about using signature-debit (by advertising
significant safety ... in excess of what gov. regulations may require,
although as pointed out in the Federal Trade Commission article ... this
may not continue to be true; aka "could change at any time").
http://www.ftc.gov/bcp/conline/pubs/online/payments.shtm
and
http://www.pirg.org/consumer/banks/debit/debitcards1.htm
i.e. from above
Debit cards make banks a lot of money. When you use the card like a
credit card (with a signature, but not with a PIN), banks take a hefty
fee from the merchant.
... snip ...
and article making the inverse statement about fraud
Study: PIN Debit Cheaper, Less Fraud-Prone Than Signature
http://www.digitaltransactions.net/newsstory.cfm?newsid=768
the significant costs to the overall infrastructure, related to
signature-debit, appeared to have been at least part of the motivation
for the walmart class-action anti-trust suit against the associations
https://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#42 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#47 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#51 John W. Backus, 82, Fortran developer, dies
other posts in this sub-thread:
https://www.garlic.com/~lynn/2007h.html#76 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#0 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#5 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#8 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#12 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#19 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#28 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#41 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#48 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#55 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#57 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#58 John W. Backus, 82, Fortran developer, dies
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Sun, 29 Apr 2007 19:23:24 -0600Peter Flass <Peter_Flass@Yahoo.com> writes:
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Mon, 30 Apr 2007 07:56:53 -0600Bernd Felsche <bernie@innovative.iinet.net.au> writes:
one of the definitions for being a DBMS ... relational or otherwise ... is supporting transactions and commits ... that there should be no inconsistencies regardless of how/where failure has occurred.
lots of past posts on original relational/sql implementation (and well
as possibly some number of other dbms related activities)
https://www.garlic.com/~lynn/submain.html#systemr
some number of past posts on doing high availability product
(and/or distributed lock manager in support of transactions
and commit infrastructures)
https://www.garlic.com/~lynn/subtopic.html#hacmp
one of the issues in distributed lock manager ... was not only cleanup after some process glitch in single CEC environment (i.e. single processor or multiple processors in SMP/shared memory environment), but cleanup in distributed environment involving potentially large number of distributed and/or clustered CECs
specific meeting discussing some of the issues
https://www.garlic.com/~lynn/95.html#13
https://www.garlic.com/~lynn/96.html#15
and some references to availability specific items
https://www.garlic.com/~lynn/submain.html#available
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Mon, 30 Apr 2007 07:44:42 -0600jmfbahciv writes:
that is different part of the business. some of the automobile companies (and other companies) have bought up an ILCs that had been grandfathered from one or another of the national banking legislation. the issue for financing/lending, either a national banking charter was required (or one of the grandfathered ILCs) ... or the company had to apply and obtain a state banking charter in every one of the states ... which could be extremely costly and time-consuming (it was much simpler to have a single bank charter to operate nationally than having 50 separate ones in each of the states).
there have been analysis that possibly (for some operations), nearly all the profit comes from financing the loan ... rather than selling of the car (jokes about cars just being an excuse for making the loan).
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: public key password authentication Newsgroups: sci.crypt Date: Mon, 30 Apr 2007 08:10:44 -0600Hallvard B Furuseth <h.b.furuseth@usit.uio.no> writes:
now, depending on the public/private key technology chosen there can be a significant difference in the efficiency in the verifying of the digital signature.
it wasn't until later that pki and digital certificate based operation was addeded to kerberos pk-init operation ... along with all the additional complexity, overhead, and waste.
aka ... PKI and digital certificate paradigm is for the situation analogous to the letters of credit/introduction from the sailing ship days (and earlier) ... where the relying party has absolutely no prior knowledge of the stranger that they are dealing with ... and absolutely no other means of obtaining that information. By definition, if the client has to (pre)register anything with the server ... it invalidates the assumptions justifying the complex PKI operations and making the digital certificates redundant and superfluous.
lots of past posts mentioning kerberos pk-init
https://www.garlic.com/~lynn/subpubkey.html#kerberos
the other widely deployed and prevalent authentication infrastrature
found in the internet world is radius ... and there have been similar
simple definitions/implementations for radius ... where a public key
is simply registered in lieu of a password
https://www.garlic.com/~lynn/subpubkey.html#radius
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Mon, 30 Apr 2007 09:42:33 -0600Charlton Wilbur <cwilbur@chromatico.net> writes:
in some sense ... a corporate payment transaction concentrator is
similar to the original internet payment gateway that we worked on
when we consulted for small client/server startup that wanted to do
payment transactions on their servers (now frequently referred to as
electronic commerce)
https://www.garlic.com/~lynn/subnetwork.html#gateway
merchants are also placed in something of untenable situation ...
needing to retain information for an extended period in order to
handle any disputes ... slightly related old post about security
proportional to risk
https://www.garlic.com/~lynn/2001h.html#61
in part, the whole PCI stuff revolves around rules and specifications for hiding/protecting the information that merchants have to retain in order to perform normal business operations.
and more recent posts observing that the attackers can afford to
possibly outspend defenders by as much as 100:1
https://www.garlic.com/~lynn/2007e.html#26 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007g.html#20 T.J. Maxx data theft worse than first reported
https://www.garlic.com/~lynn/2007h.html#56 T.J. Maxx data theft worse than first reported
one of the things is that the existing infrastructure is extremely vulnerable to replay attacks ... aka using information from previous transactions to perform new, fraudulent transactions.
in the mid-90s, the x9a10 financial standard working group was given
the requirement to preserve the integrity of the financial
infrastructure for all retail payments (ALL, as in point-of-sale,
credit, debit, face-to-face, ACH, check, internet, stored-value
... aka ALL). the result was x9.59 financial standard
https://www.garlic.com/~lynn/x959.html#x959
one of the things that x9.59 addressed was eliminating the vulnerability to replay attacks. it didn't do anything with regard to hiding/encrypting/protecting information from previous transactions ... it just made that information useless to attackers for performing fraudulent transactions (aka nearly totally eliminating the risk from replay attacks and the use of information from previous transactions in performing new, fraudulent transaction).
related posts on existing payment infrastructure being vulnerable to
replay attacks
https://www.garlic.com/~lynn/subintegrity.html#payments
lots of past posts about harvest/skimming of information from
existing/previous transactions
https://www.garlic.com/~lynn/subintegrity.html#harvest
some number of past posts about shared-secret (authentication) based
paradigms (and vulnerability to replay attacks and/or impersonation)
https://www.garlic.com/~lynn/subintegrity.html#secrets
recent post about replay attack vulnerabilities in authentication
paradigms
https://www.garlic.com/~lynn/2007i.html#63 public key password authentication
lots of past posts mentioning general topic of threats,
vulnerabilities, fraud, attacks, and/or exploits
https://www.garlic.com/~lynn/subintegrity.html#fraud
and to take it from a slightly different viewpoint ... past posts on
assurance
https://www.garlic.com/~lynn/subintegrity.html#assurance
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Mon, 30 Apr 2007 10:58:49 -0600Charlton Wilbur <cwilbur@chromatico.net> writes:
for a little recent topic drift
https://www.garlic.com/~lynn/aadsm26.htm#64 Dr Geer goes to Washington
in any case, that was what we did in the x9a10 financial standard working group in doing detailed study of the end-to-end threats and vulnerabilities.
we had been asked to come in and consult with the small client/server startup that wanted to do payment transactions ... and they had this technology called SSL. SSL was used in hiding the transaction while it was "in flight" thru the internet (hiding the information).
we then did some work in the x9a10 financial standard working group
that in the mid-90s which had been given the reguirement to preserve
the integrity of the financial infrastructure for all retail payments.
the result was x9.59 financial standard protocol for *ALL* retail
payments
https://www.garlic.com/~lynn/x959.html#x959
i.e. some amount of our earlier work on SSL and payments was obsoleted by our work on X9.59 financial standard protocol
one of the things that we observed was that the earlier payment transaction work (that is commingly now referred to as electronic commerce) involving hiding the information was now redundant and superfluous ... i.e. from the security acronym PAIN:
part of this was that doing detailed look at the end-to-end threats and vulnerabilities ... we found numerous instances where the data was at rest and was subject to attacks by both insiders and outsiders.
in the past, we observed that even if the planet was buried under miles of (information hiding) encryption ... it still wouldn't be able to prevent information leakage out of the existing infrastructure. Part of the reason is that information from existing transactions can be used in replay attacks for fraudulent transactions. As a result, the information has to be kept confidential and never divulged (not to yourself, not to the merchant, not to your financial institution, not to anybody). On the other hand, the same information is required in dozens (of ongoing) standard business processes. As a result the same information (that has to be kept confidential and never divulged) has to be also readily available for the scores of business processes where it is required.
misc. past posts mentioning that burying the planet under miles
of encryption isn't the solution:
https://www.garlic.com/~lynn/aadsm15.htm#27 SSL, client certs, and MITM (was WYTM?)
https://www.garlic.com/~lynn/aadsm22.htm#2 GP4.3 - Growth and Fraud - Case #3 - Phishing
https://www.garlic.com/~lynn/aadsm22.htm#36 Unforgeable Blinded Credentials
https://www.garlic.com/~lynn/aadsm23.htm#28 JIBC April 2006 - "Security Revisionism"
https://www.garlic.com/~lynn/aadsm23.htm#54 Status of SRP
https://www.garlic.com/~lynn/aadsm24.htm#38 Interesting bit of a quote
https://www.garlic.com/~lynn/aadsm24.htm#48 more on FBI plans new Net-tapping push
https://www.garlic.com/~lynn/aadsm25.htm#13 Sarbanes-Oxley is what you get when you don't do FC
https://www.garlic.com/~lynn/aadsm25.htm#24 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm26.htm#8 What is the point of encrypting information that is publicly visible?
https://www.garlic.com/~lynn/aadsm26.htm#24 News.com: IBM donates new privacy tool to open-source Higgins
https://www.garlic.com/~lynn/aadsm26.htm#27 man in the middle, SSL ... addenda
https://www.garlic.com/~lynn/2005u.html#3 PGP Lame question
https://www.garlic.com/~lynn/2005v.html#2 ABN Tape - Found
https://www.garlic.com/~lynn/2006e.html#26 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006e.html#44 Does the Data Protection Act of 2005 Make Sense
https://www.garlic.com/~lynn/2006h.html#15 Security
https://www.garlic.com/~lynn/2006k.html#4 Passwords for bank sites - change or not?
https://www.garlic.com/~lynn/2006k.html#5 Value of an old IBM PS/2 CL57 SX Laptop
https://www.garlic.com/~lynn/2006k.html#17 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#18 Value of an old IBM PS/2 CL57 SX Laptop
https://www.garlic.com/~lynn/2006o.html#37 the personal data theft pandemic continues
https://www.garlic.com/~lynn/2006p.html#8 SSL, Apache 2 and RSA key sizes
https://www.garlic.com/~lynn/2006t.html#40 Encryption and authentication
https://www.garlic.com/~lynn/2006u.html#43 New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2006v.html#2 New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2006v.html#49 Patent buster for a method that increases password security
https://www.garlic.com/~lynn/2006w.html#32 'Innovation' and other crimes
https://www.garlic.com/~lynn/2006y.html#8 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2006y.html#25 "The Elements of Programming Style"
https://www.garlic.com/~lynn/2007b.html#8 Special characters in passwords was Re: RACF - Password rules
https://www.garlic.com/~lynn/2007b.html#20 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007b.html#60 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#10 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#33 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#43 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#53 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007d.html#34 Mixed Case Password on z/OS 1.7 and ACF 2 Version 8
https://www.garlic.com/~lynn/2007e.html#26 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007g.html#20 T.J. Maxx data theft worse than first reported
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Mon, 30 Apr 2007 11:46:30 -0600Anne & Lynn Wheeler <lynn@garlic.com> writes:
somewhat in the wake of the stuff now commonly called electronic commerce, there were a number of other efforts in the mid-90s to also look at enhancing transactions (besides the x9a10 standards work).
misc. posts on the payment gateway
https://www.garlic.com/~lynn/subnetwork.html#gateway
and slightly related background
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
i.e. two of the people in this meeting
https://www.garlic.com/~lynn/95.html#13
https://www.garlic.com/~lynn/96.html#15
from ha/cmp
https://www.garlic.com/~lynn/subtopic.html#hacmp
were now responsible for something called commerce server.
most of the other efforts were targeted at some particular, specific point solution ... were not bothering to do detailed end-to-end threat and vulnerability analysis ... and not looking at coming up with comprehensive solution that addressed everything.
one of the things that was commonly mentioned in the mid-90s ... was that the hardware token solutions were extremely expensive and in order to introduce any sort of hardware token (as part of a solution) there might have to be (significant) compromises made in order to produce a cost effective solution.
it was in this time-frame that i would make my semi-facetious statement about taking a $500 mil-spec piece, and aggresively cost-reducing it by two to three orders of magnitude while at the same time, improving its security (i.e. not compromising).
the other objective/requirement was allow it to meet transit power and elapsed time requirements. transit was transition to contactless operation at various transit gates (subways, trains, metro, etc) and also had elapsed time-requirements of a hundred or two milliseconds at the transit gates.
now, one of the things that some of the other solutions looked at to decrease elapsed time with hardware tokens were doing certain operations in parallel ... by adding a whole bunch of parallel circuits ... and also drastically increasing the power draw ... far in excess of what could be done in a timely manner with contactless chips (drawing power thru the air from the reader or transit gate).
the alternative was to come up with an equally secure solution that required enormously fewer electrons to achieve the same goal (i.e. product of electron flow rate and elapsed time) ... and be able to implement it in a secure hardware package with possibly a three orders of magnitude cost reduction.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Mon, 30 Apr 2007 13:18:50 -0600Anne & Lynn Wheeler <lynn@garlic.com> writes:
for more topic drift ... various of the hardware-related security solutions based on (relative) big honking power consumption also tended to be vulnerable to attacks related to measuring and profiling their power consumption
going to a hardware-related security with totally different and
significantly reduced power utilization also eliminated such attacks
(somewhat intertwined with doing aggressive simplification and cost
reduction)
https://www.garlic.com/~lynn/x959.html#aads
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: A tribute to Jim Gray Newsgroups: alt.folklore.computers Date: Mon, 30 Apr 2007 14:02:25 -0600A tribute to Jim Gray
recent posts mentioning Jim:
https://www.garlic.com/~lynn/2007.html#1 "The Elements of Programming Style"
https://www.garlic.com/~lynn/2007.html#13 "The Elements of Programming Style"
https://www.garlic.com/~lynn/2007d.html#4 Jim Gray Is Missing
https://www.garlic.com/~lynn/2007d.html#6 Jim Gray Is Missing
https://www.garlic.com/~lynn/2007d.html#8 Jim Gray Is Missing
https://www.garlic.com/~lynn/2007d.html#17 Jim Gray Is Missing
https://www.garlic.com/~lynn/2007d.html#33 Jim Gray Is Missing
https://www.garlic.com/~lynn/2007g.html#28 Jim Gray Is Missing
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: How the Internet took over Newsgroups: alt.folklore.computers Date: Mon, 30 Apr 2007 14:09:30 -0600How the Internet took over
from above:
Twenty-five years ago the Internet as we now know it was in the process
of being birthed by the National Science Foundation. Since then it's
been an information explosion. From e-mail to eBay, communication and
shopping have forever changed.
... snip ...
other email from the period about internet highspeed backbone and
other operational considerations
https://www.garlic.com/~lynn/lhwemail.html#nsfnet
recent posts making mention that while tcp/ip was technology basis
for the internet, the nsfnet backbone was the operational precursor
to the modern internet:
https://www.garlic.com/~lynn/2007b.html#5 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007d.html#43 Is computer history taugh now?
https://www.garlic.com/~lynn/2007h.html#67 SSL vs. SSL over tcp/ip
https://www.garlic.com/~lynn/2007i.html#40 Best practices for software delivery
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: illegal aliens Newsgroups: alt.folklore.computers Date: Mon, 30 Apr 2007 14:20:22 -0600Al Balmer <albalmer@att.net> writes:
In the above posting, I also made note of the CIS report (that used 2000 census information) ... but also found/noted an earlier GAO report that was very similar.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Free Checking Newsgroups: alt.folklore.computers Date: Mon, 30 Apr 2007 17:23:54 -0600Frank McCoy <mccoyf@millcomm.com> writes:
post from last year
https://www.garlic.com/~lynn/aadsm23.htm#35 3 of the big 4 - all doing payment systems
much of that coming from fees charged merchants. recent reference
https://www.garlic.com/~lynn/2007i.html#59 John W. Backus, 82, Fortran developer, dies
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Free Checking Newsgroups: alt.folklore.computers Date: Mon, 30 Apr 2007 18:45:46 -0600Frank McCoy <mccoyf@millcomm.com> writes:
a lot of merchants will subscribe to some sort of check validation and/or guarantee function (you can see the decals on the register or windows ... next to the card association brands). check validation ... indexed by drivers license # will be somewhat less than card interchange fees. check guarantee can be larger than card interchange fees (i.e. the guaranteeing organization will pay the merchant and take responsibility for what happens if the check doesn't clear or bounces).
the issue for some merchants is cash flow ... they have bills to pay related to goods sold consumers ... and if they have trouble collecting from merchants, it can but them into real cash flow bind.
note thhat there is also "shrinkage" for cash (for some merchants like
fastfood operations, it can be pretty significant)... i.e. the
difference between what is taken in at the till and what actually is net
deposit at the bank. old post mentioning shrinkage
https://www.garlic.com/~lynn/2005u.html#14 AMD to leave x86 behind?
on the other hand ... the interchange fee as flat charge per transaction
plus percent of transaction can be significant for merchants ... recent
post mentioning that for c-stores ... card interchange fees is their
single largest expense ... larger than labor or any other item.
https://www.garlic.com/~lynn/2007i.html#47 John W. Backus, 82, Fortran developer, dies
that may also account for some of the motivation behind the class-action anti-trust suit (which would imply that they all aren't happy with the state of interchange fees) ... there have also been a number of items in the last several weeks about continued push about looking at interchange fees
recent posts mentioning class-action anti-trust:
https://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#42 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#47 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#51 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#59 John W. Backus, 82, Fortran developer, dies
some recent articles mentioning interchange fees
Retailers Urge State Efforts on Credit Card Interchange Fees
http://www.paymentsnews.com/2007/04/retailers_urge_.html
Payments Upstart GratisCards Aims to 'Eliminate' Interchange
http://www.digitaltransactions.net/newsstory.cfm?newsid=1285
The Corrosive Siege Over Signature-Card Interchange
http://www.digitaltransactions.net/newsstory.cfm?newsid=1223
Congressional Committee talks tough on interchange fees
http://www.finextra.com/fullstory.asp?id=16433
EC Report Criticizes Interchange Rates
http://www.epaynews.com/index.cgi?survey=&ref=browse&f=view&id=117033394619412597249&block=
EU competition commission eyes Visa interchange fees
http://www.finextra.com/fullstory.asp?id=16540
Has interchange hype brought us to the brink of a surcharging sea change?
http://aneace.blogspot.com/2006/06/has-interchange-hype-brought-us-to.html
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: public key password authentication Newsgroups: sci.crypt Date: Mon, 30 Apr 2007 18:54:58 -0600Mike Amling <nospam@nospam.net> writes:
there can be a separate kind of vulnerability against some public/private key infrastructures ... the issue is some operations have also looked at equated digital signatures (on documents and other things) ... as equivalent to human signatures (i.e. intent, implying having read, understood, agrees, approves, and/or authorizes) ... something that digital signatures were never designed to do ... but happens possibly because of semantic confusion generated because both "digital signatures" and "human signatures" both contain the word "signature"
this can be a dual-use attack ... when somebody at a server site ... instead or random data to be digital signed for authentication (countermeasure to replay attacks) transmits some sort of valid document. the exposure is, in part, because the majority of the authentication protocols will automatically digitally signed the transmitted "random data" w/o allowing the human to ever examine the contents.
some past posts discussing dual-use attack against digital signature
infrastructures that attempt to extend it to be equivalent to
human signature ... something that it was never intended to do:
https://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#56 two-factor authentication problems
https://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm19.htm#43 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm20.htm#0 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm21.htm#5 Is there any future for smartcards?
https://www.garlic.com/~lynn/aadsm21.htm#13 Contactless payments and the security challenges
https://www.garlic.com/~lynn/aadsm23.htm#13 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
https://www.garlic.com/~lynn/aadsm26.htm#63 Public key encrypt-then-sign or sign-then-encrypt?
https://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#21 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2005.html#14 Using smart cards for signing and authorization in applets
https://www.garlic.com/~lynn/2005b.html#56 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005e.html#31 Public/Private key pair protection on Windows
https://www.garlic.com/~lynn/2005g.html#46 Maximum RAM and ROM for smartcards
https://www.garlic.com/~lynn/2005m.html#1 Creating certs for others (without their private keys)
https://www.garlic.com/~lynn/2005m.html#11 Question about authentication protocols
https://www.garlic.com/~lynn/2005o.html#3 The Chinese MD5 attack
https://www.garlic.com/~lynn/2005q.html#23 Logon with Digital Siganture (PKI/OCES - or what else they're called)
https://www.garlic.com/~lynn/2005s.html#52 TTP and KCM
https://www.garlic.com/~lynn/2005v.html#3 ABN Tape - Found
https://www.garlic.com/~lynn/2006d.html#32 When *not* to sign an e-mail message?
https://www.garlic.com/~lynn/2006s.html#34 Basic Question
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: public key password authentication Newsgroups: sci.crypt Date: Wed, 02 May 2007 06:43:07 -0600Mike Amling <nospam@nospam.net> writes:
because it is technically better ... and/or lacking the word "signature" it avoids the semantic confusion introduced with the use of the term "digital signature"?
one of the scenarios in x9.59 financial standard protocol
https://www.garlic.com/~lynn/x959.html#x959
was to have the digital signature applied to the transaction ...
supplying both integrity and authentication on the transaction ... and
not bothering to get confused about intent, and/or human having read,
understood, agrees, approves, and/or authorizes ... for some topic
drift ... misc. past posts about having been brought in to help
word-smith cal. state (and then federal) electronic signature
legislation
https://www.garlic.com/~lynn/subpubkey.html#signature
one of the issues in x9.59 financial standard protocol was to provide
the integrity and authentication on the transaction itself ... avoiding
potential (vulnerability and threat) cracks introduced into business
processing infrastructure when authentication and integrity are done
separately ... some amount of discussion in past posts about naked
transaction metaphor ....
https://www.garlic.com/~lynn/subintegrity.html#payments
i.e. when the two operatons are performed separately (if the trouble is
taken to both at all) and opportunities like MITM-attacks are introduced
https://www.garlic.com/~lynn/subintegrity.html#mitm
of course, the dual-use attacks, where the same private key is used to both sign "random data" ... for "authentication" only protocol ... and sign "non-random data" ... for both/combined integrity and authentication can create some ambiguity. the dual-use attack may come into play w/o even (totally) falling into the semantic confusion regarding the word "signature".
Part of the issue could purely be when the same digital signature private key is used for both purely "authentication" purposes (i.e. the automatic signing of random data) as well as used for combined "integrity" and "authentication" purposes as one operation (signing of non-random data ... and/or data with meaning) ... and people still getting confused that "integrity" also implies intent ... or from the security PAIN acronym non-repudiation
the issue in x9.59 financial standard protocol is then how to just have "authentication" and "integrity" on the transaction (providing armoring for the transaction and not leaving it naked, introducing opportunities for things like MITM-attacks) ... w/o the "digital signature" also carrying the sense of intent and human having read, understood, agrees, approves, and/or authorizes. something additional is then needed to carry the sense of intent ... separate from the digital signature. And from the naked transaction methapor ... if the indication of intent isn't also integrated with the transaction ... that could also introduce threats and vulnerabilities ... like MITM-attacks.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Free Checking Newsgroups: alt.folklore.computers Date: Wed, 02 May 2007 06:50:55 -0600jmfbahciv writes:
aka ... it just means that it is paid for some other way. this has also
been discussed in this ng in the past regarding "free" internet service
old email mentioning NSFNET
https://www.garlic.com/~lynn/lhwemail.html#nsfnet
... old (and not so old) posts mentioning NSFNET
https://www.garlic.com/~lynn/subnetwork.html#nsfnet
and lots of posts mentioning internet
https://www.garlic.com/~lynn/subnetwork.html#internet
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Wed, 02 May 2007 08:00:31 -0600jmfbahciv writes:
in general ... for almost any large conglomerate ... there can be lots of different strategic and/or tactical reasons.
strategic may have to do with a lot of the stock market being emotional and/or fickle. in situation having two completely different kinds of operations ... with two different kinds of P/E ratios ... the lower P/E ratio business can have a significant downward pressure on the overall stock price. splitting into two separate corporations can result in much larger, total, aggregate stock value ... than having the stock listed as single company.
tactical might be some executive is about to leave/retire ... and their (last) annual bonus may be much bigger if they sell an operation ... even if such a sale doesn't make much long term business sense.
a frequent excuse given is to spin-off "non-core" businesses ... implying that executives have trouble given adequate focus when radically different kinds of operations are involved ... it is much easier to have a single kind of business and hire executives that are specifically skilled in that single kind of business. a variation on the same theme might be if an operation has a cash cow that is radically different from the other parts of the business ... that executives become lazy in operating the non-cash-cow business ... since they can still "make numbers" (based on the cash-cow business).
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Sizing CPU Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Wed, 02 May 2007 09:08:06 -0600edjaffe@ibm-main.lst (Edward Jaffe) writes:
for some topic drift ... the science center had done the
https://www.garlic.com/~lynn/subtopic.html#545tech
port of apl\360 to cms\apl ... this opened up the use of apl for more "real-world" problems ... since typical apl\360 operation limited workspace size to 16kbytes (or sometimes as much as 32kbytes) ... i.e. cms\apl workspace size could be nearly as big as the virtual address provided
recent posts ... about when people in armonk started using cambrige
cp67 system for cms\apl to do business analysis and modeling
https://www.garlic.com/~lynn/2007i.html#20 Does anyone know of a documented case of VM being penetrated by hackers?
apl was being used for a lot of things that spreadsheets are used for today.
the science center also did a significant amount of work on performance monitoring, performance tuning, workload profiling, system characterization that also evolved into things like capacity planning.
cms\apl (and cambridge cp67 system) was also picked up by the marketing
sales organization for something called HONE
https://www.garlic.com/~lynn/subtopic.html#hone
which later transition to vm370 and apl/cms ... with majority of world-wide sales and marketing support being provided by APL applications under vm370. in the 70s there was transition where sales could not even enter a customer order that hadn't first been processed by a HONE "configurator" (application written in APL).
The science center APL, performance modeling and capacity planning work somewhat came together in a sophisticated computer modeling application written in APL. A version of this was made available to (worldwide) sales and marketing as the performance predictor. Sales/marketing people could enter customer workload, configuration, and performance data ... and ask "what if" questions about what happens (to computer performance and thruput) when there are changes to configuration and/or workload.
some other past posts mentioning benchmarking, workload profiling,
performance monitoring and/or work on capacity planning.
https://www.garlic.com/~lynn/submain.html#bench
for some topic drift ... recent post about "joke" in the resource
manager:
https://www.garlic.com/~lynn/2007i.html#43 Latest Principles of Operation
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Wed, 02 May 2007 12:23:38 -0600Anne & Lynn Wheeler <lynn@garlic.com> writes:
in the time frame we were doing ha/cmp product
https://www.garlic.com/~lynn/subtopic.html#hacmp
we also spent some amount of time talking to the SCI people.
After departing the employer where we had been doing ha/cmp ...
somewhat related to
https://www.garlic.com/~lynn/lhwemail.html#medusa
we spent some amount of time talking to both Convex and Sequent ... who were both doing SCI-based multiprocessor (Convex doing 128-system using 64 boards from HP with two HP risc processors per board and Sequent doing 256-way using 64 boards with four intel processors per board).
The sequent people had been doing 16 and 32 way multiprocessors using intel chip for some time ... supported by their dynix flavor of unix. In that time-frame when we were talking to them about SCI 256-way ... they claimed that they had also been doing work on getting redmond operating systems working on their (existing) hardware ... and also claimed that essentially all multi-processor scale-up work done on redmond operating systems had come from their work.
More recently ... the claim is that multi-core is resulted in multi-processor requirements started to filter down into the standard desktop environments. At least for the past two yrs ... the hardware conference talking about multi-core chips (existing and/or planned in the future) have a real problem because the application software technology supporting parallelism hasn't changed significantly in the past 20 hrs. You see operating system support and some applications supporting "embarrassingly" parallel operations (i.e. like large dbms transaction oriented stuff) ... but you don't see any fundamental change in application programming technology for supporting parallelism.
a couple posts from last year on the multi-core and parallelism
challenge in the wake of hotchips conference:
https://www.garlic.com/~lynn/2006p.html#3 processors of the future: super-computer-on-a-chip?
https://www.garlic.com/~lynn/2006p.html#55 PowerPC or PARISC?
it isn't a theme that is just limited to hotchips conference ... but shows up repeatedly at numerous other chip oriented conference (discussing potentially significant programming paradigm changes needed to take advantage of the significant increase in processing cores). In fact, I was at a chip conference a yr ago where one of the senior chip engineers gave a talk specifically about the software programming paradigm will have to significantly change in order to start taking advantage of large numbers of cores.
It also has shown up in various conferences discussing "CELL" chips ... which is not only multi-core of the same type of programming architecture ... but also includes multiple cores with different kinds of programming architecture.
recent article from yesterday:
Microsoft super sizes multi-threaded tripe
http://www.theregister.co.uk/2007/05/01/mundie_mundie/
from above:
Microsoft, to its credit, has multi-threaded the calculations in Office
Excel 2007. But that's about where the credit ends.
Intel and AMD executives fail to hide their disappointment with
Microsoft well on the multi-threaded software front.
During a speech last June, Intel SVP Pat Gelsinger said the following:
"A couple of years ago, I had a discussion with Bill Gates (about the
multi-core products). He was just in disbelief. He said, 'We can't write
software to keep up with that.'"
Gates ordered the Intel executive to keep pumping out faster product.
"No, Bill, it's not going to work that way," Gelsinger informed him.
... snip ...
lots of past posts mentioning smp multiprocessor operation and/or
compare&swap instructions
https://www.garlic.com/~lynn/subtopic.html#smp
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Wed, 02 May 2007 13:24:44 -0600Anne & Lynn Wheeler <lynn@garlic.com> writes:
by implication in the CIS and GAO studies and in various other studies ... where it is talking about one segment of society producing less economic benefit than what they cost ... there are some economic issues about how does the society make up the shortfall ... presumably by extracted economic value from segments of society that provide society significantly more economic benefit than they cost.
some topic drift with respect to possible segments of society that produce more economic benefit than they cost.
Study: China Leaps Forward In Advanced Tech Education
http://www.investors.com/editorial/IBDArticles.asp?artsec=17&artnum=2&issue=20070501
from above:
In a recent Duke University study, researchers said China is overtaking
the U.S. and India in advanced engineering and technology graduates.
... snip ...
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Wed, 02 May 2007 13:45:58 -0600Anne & Lynn Wheeler <lynn@garlic.com> writes:
one of the things that we had done while we were doing ha/cmp
product was coin the terms disaster survivability and
geographic survivability to differentiate from simple
disaster/recovery
https://www.garlic.com/~lynn/submain.html#available
recent item
Premier 100 Spotlight Series: 5 Disaster Survival Tips from Northrop
Grumman Lessons on disaster recovery -- and survival -- from the IT team
at Northrop Grumman.
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=288135
and for other topic drift
IBM gives SharePoint users Tivoli backup muscle The OEM deal targets
SharePoint Portal Server 2003, SharePoint Server 2007
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9018461
from above:
IBM introduced its new Tivoli Storage Manager (TSM) for Microsoft
SharePoint today, giving users of the popular Microsoft online
collaboration tool access to new backup and recovery options. Adding to
its appeal, the new Tivoli component will integrate with all of TSM
Extended Edition server's data protection capabilities on the back end.
... snip ...
TSM had previously been called ADSM (before being renamed). ADSM grew
out of CMSBACK that I had originally started work on in the late 70s
... reference here:
http://www.almaden.ibm.com/StorageSystems/Past_Projects/TSM.shtml
past posts mentioning working on backup/archive (for things like
disaster/recovery)
https://www.garlic.com/~lynn/submain.html#backup
and some old CMSBACK email
https://www.garlic.com/~lynn/lhwemail.html#cmsback
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: illegal aliens Newsgroups: alt.folklore.computers Date: Wed, 02 May 2007 14:00:29 -0600Al Balmer <albalmer@att.net> writes:
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Interrupts Newsgroups: alt.folklore.computers Date: Wed, 02 May 2007 17:37:08 -0600"Charlie Gibbs" <cgibbs@kltpzyxm.invalid> writes:
Then there were some number of internal fullscreen editors before XEDIT.
some posts (and old email) getting into middle of why wasn't one of the
more mature internal fullscreen editors released as a product rather
than the relatively new comer XEDIT.
https://www.garlic.com/~lynn/2002p.html#39 20th anniversary of the internet (fwd)
https://www.garlic.com/~lynn/2003d.html#25 Which Editor
https://www.garlic.com/~lynn/2006n.html#55 The very first text editor
https://www.garlic.com/~lynn/2006u.html#26 Assembler question
https://www.garlic.com/~lynn/2006u.html#61 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006y.html#4 Why so little parallelism?
and other old posts mentioning xedit:
https://www.garlic.com/~lynn/2000b.html#29 20th March 2000
https://www.garlic.com/~lynn/2000d.html#17 Where's all the VMers?
https://www.garlic.com/~lynn/2001i.html#1 History of Microsoft Word (and wordprocessing in general)
https://www.garlic.com/~lynn/2001i.html#17 History of Microsoft Word (and wordprocessing in general)
https://www.garlic.com/~lynn/2001i.html#18 History of Microsoft Word (and wordprocessing in general)
https://www.garlic.com/~lynn/2001i.html#22 History of Microsoft Word (and wordprocessing in general)
https://www.garlic.com/~lynn/2001k.html#44 3270 protocol
https://www.garlic.com/~lynn/2001k.html#46 3270 protocol
https://www.garlic.com/~lynn/2001m.html#22 When did full-screen come to VM/370?
https://www.garlic.com/~lynn/2001m.html#33 XEDIT on MVS
https://www.garlic.com/~lynn/2001m.html#38 CMS under MVS
https://www.garlic.com/~lynn/2002h.html#58 history of CMS
https://www.garlic.com/~lynn/2002m.html#24 Original K & R C Compilers
https://www.garlic.com/~lynn/2003.html#62 Card Columns
https://www.garlic.com/~lynn/2003d.html#22 Which Editor
https://www.garlic.com/~lynn/2003e.html#29 MP cost effectiveness
https://www.garlic.com/~lynn/2003e.html#75 History of project maintenance tools -- what and when?
https://www.garlic.com/~lynn/2004o.html#36 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2004q.html#63 creat
https://www.garlic.com/~lynn/2005f.html#14 Where should the type information be: in tags and descriptors
https://www.garlic.com/~lynn/2005f.html#15 Where should the type information be: in tags and descriptors
https://www.garlic.com/~lynn/2005f.html#34 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005j.html#41 TSO replacement?
https://www.garlic.com/~lynn/2005n.html#47 Anyone know whether VM/370 EDGAR is still available anywhere?
https://www.garlic.com/~lynn/2005t.html#40 FULIST
https://www.garlic.com/~lynn/2005t.html#43 FULIST
https://www.garlic.com/~lynn/2005t.html#44 FULIST
https://www.garlic.com/~lynn/2005u.html#58 Command reference for VM/370 CMS Editor
https://www.garlic.com/~lynn/2006k.html#50 TSO and more was: PDP-1
https://www.garlic.com/~lynn/2006k.html#51 other cp/cms history
https://www.garlic.com/~lynn/2006n.html#34 Not Your Dad's Mainframe: Little Iron
https://www.garlic.com/~lynn/2006n.html#43 MTS, Emacs, and... WYLBUR?
https://www.garlic.com/~lynn/2006n.html#45 sorting
https://www.garlic.com/~lynn/2006o.html#21 Source maintenance was Re: SEQUENCE NUMBERS
https://www.garlic.com/~lynn/2006s.html#3 THE on USS?
https://www.garlic.com/~lynn/2006s.html#15 THE on USS?
https://www.garlic.com/~lynn/2007.html#23 How to write a full-screen Rexx debugger?
https://www.garlic.com/~lynn/2007.html#24 How to write a full-screen Rexx debugger?
https://www.garlic.com/~lynn/2007g.html#4 ISPF Limitations (was: Need for small machines ... )
https://www.garlic.com/~lynn/2007g.html#5 Call for XEDIT freaks, submit ISPF requirements
https://www.garlic.com/~lynn/2007g.html#14 ISPF not productive
https://www.garlic.com/~lynn/2007g.html#17 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007g.html#44 1960s: IBM mgmt mistrust of SLT for ICs?
https://www.garlic.com/~lynn/2007h.html#8 whiny question: Why won't z/OS support the HMC 3270 emulator
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Disc Drives Newsgroups: alt.folklore.computers Date: Wed, 02 May 2007 17:44:41 -0600"Charlie Gibbs" <cgibbs@kltpzyxm.invalid> writes:
for some topic drift .... increasing physical block size from 512bytes to 4096bytes ... improving capacity and error correction:
Hard drive changes: Long Block Data standard gets green light
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9018507
and some really ancient stuff ... old posts mentioning air bearing
simulation application in support of designing the "new"
floating/thin-film heads
https://www.garlic.com/~lynn/2001n.html#39 195 was: Computer Typesetting Was: Movies with source code
https://www.garlic.com/~lynn/2002j.html#30 Weird
https://www.garlic.com/~lynn/2002n.html#63 Help me find pics of a UNIVAC please
https://www.garlic.com/~lynn/2002o.html#74 They Got Mail: Not-So-Fond Farewells
https://www.garlic.com/~lynn/2003b.html#51 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003b.html#52 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003j.html#69 Multics Concepts For the Contemporary Computing World
https://www.garlic.com/~lynn/2003m.html#20 360 Microde Floating Point Fix
https://www.garlic.com/~lynn/2003n.html#45 hung/zombie users ... long boring, wandering story
https://www.garlic.com/~lynn/2004.html#21 40th anniversary of IBM System/360 on 7 Apr 2004
https://www.garlic.com/~lynn/2004b.html#15 harddisk in space
https://www.garlic.com/~lynn/2004o.html#15 360 longevity, was RISCs too close to hardware?
https://www.garlic.com/~lynn/2004o.html#25 CKD Disks?
https://www.garlic.com/~lynn/2005.html#8 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005f.html#4 System/360; Hardwired vs. Microcoded
https://www.garlic.com/~lynn/2005f.html#5 System/360; Hardwired vs. Microcoded
https://www.garlic.com/~lynn/2005o.html#44 Intel engineer discusses their dual-core design
https://www.garlic.com/~lynn/2006.html#29 IBM microwave application--early data communications
https://www.garlic.com/~lynn/2006c.html#6 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006d.html#0 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006d.html#13 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006d.html#14 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006l.html#6 Google Architecture
https://www.garlic.com/~lynn/2006l.html#18 virtual memory
https://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006t.html#41 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006u.html#18 Why so little parallelism?
https://www.garlic.com/~lynn/2006x.html#27 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006x.html#31 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2007e.html#43 FBA rant
https://www.garlic.com/~lynn/2007e.html#44 Is computer history taught now?
https://www.garlic.com/~lynn/2007f.html#46 The Perfect Computer - 36 bits?