List of Archived Posts
2007 Newsgroup Postings (04/23 - 05/02)
- John W. Backus, 82, Fortran developer, dies
- Linux: The Completely Fair Scheduler
- Linux: The Completely Fair Scheduler
- John W. Backus, 82, Fortran developer, dies
- John W. Backus, 82, Fortran developer, dies
- John W. Backus, 82, Fortran developer, dies
- John W. Backus, 82, Fortran developer, dies
- John W. Backus, 82, Fortran developer, dies
- John W. Backus, 82, Fortran developer, dies
- John W. Backus, 82, Fortran developer, dies
- John W. Backus, 82, Fortran developer, dies
- Laugh, laugh. I thought I'd die - application crashes
- John W. Backus, 82, Fortran developer, dies
- U.S. Cedes Top Spot in Global IT Competitiveness
- when was MMU virtualization first considered practical?
- when was MMU virtualization first considered practical?
- when was MMU virtualization first considered practical?
- John W. Backus, 82, Fortran developer, dies
- John W. Backus, 82, Fortran developer, dies
- John W. Backus, 82, Fortran developer, dies
- Does anyone know of a documented case of VM being penetrated by hackers?
- John W. Backus, 82, Fortran developer, dies
- John W. Backus, 82, Fortran developer, dies
- John W. Backus, 82, Fortran developer, dies
- John W. Backus, 82, Fortran developer, dies
- Latest Principles of Operation
- Latest Principles of Operation
- John W. Backus, 82, Fortran developer, dies
- John W. Backus, 82, Fortran developer, dies
- Does anyone know of a documented case of VM being penetrated by hackers?
- John W. Backus, 82, Fortran developer, dies
- Latest Principles of Operation
- ANN: Microsoft goes Open Source
- Internal DASD Pathing
- Internal DASD Pathing
- ANN: Microsoft goes Open Source
- John W. Backus, 82, Fortran developer, dies
- Internal DASD Pathing
- John W. Backus, 82, Fortran developer, dies (Actually, Working under the table!)
- Does anyone know of a documented case of VM being penetrated by hackers?
- Best practices for software delivery
- John W. Backus, 82, Fortran developer, dies
- John W. Backus, 82, Fortran developer, dies
- Latest Principles of Operation
- latest Principles of Operation
- IBM System/360 Model 85: The Bashful Computer
- Linux: The Completely Fair Scheduler
- John W. Backus, 82, Fortran developer, dies
- John W. Backus, 82, Fortran developer, dies
- John W. Backus, 82, Fortran developer, dies
- John W. Backus, 82, Fortran developer, dies
- John W. Backus, 82, Fortran developer, dies
- John W. Backus, 82, Fortran developer, dies
- John W. Backus, 82, Fortran developer, dies
- John W. Backus, 82, Fortran developer, dies
- John W. Backus, 82, Fortran developer, dies
- John W. Backus, 82, Fortran developer, dies
- John W. Backus, 82, Fortran developer, dies
- John W. Backus, 82, Fortran developer, dies
- John W. Backus, 82, Fortran developer, dies
- John W. Backus, 82, Fortran developer, dies
- John W. Backus, 82, Fortran developer, dies
- John W. Backus, 82, Fortran developer, dies
- public key password authentication
- John W. Backus, 82, Fortran developer, dies
- John W. Backus, 82, Fortran developer, dies
- John W. Backus, 82, Fortran developer, dies
- John W. Backus, 82, Fortran developer, dies
- A tribute to Jim Gray
- How the Internet took over
- illegal aliens
- Free Checking
- Free Checking
- public key password authentication
- public key password authentication
- Free Checking
- John W. Backus, 82, Fortran developer, dies
- Sizing CPU
- John W. Backus, 82, Fortran developer, dies
- John W. Backus, 82, Fortran developer, dies
- John W. Backus, 82, Fortran developer, dies
- illegal aliens
- Interrupts
- Disc Drives
Refed: **, - **, - **, - **
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 -0600
jmfbahciv writes:
It seems that the banking industry wants to push the computing
work, especially the mainframe part of it, off onto each
individual. That's what removing paper checks is all about.
IMO, they are pushing this computing work in exactly the
wrong direction.
re:
http://www.garlic.com/~lynn/2007h.html#78 John W. Backus, 82, Fortran developer, dies
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
http://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#155 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/2002.html#18 Infiniband's impact was Re: Intel's 64-bit strategy
http://www.garlic.com/~lynn/2002g.html#2 Computers in Science Fiction
http://www.garlic.com/~lynn/2006m.html#1 Large Computer Rescue
http://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.
Refed: **, - **, - **, - **, - **
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 -0600
jmfbahciv writes:
Do you get just a little bit discouraged? I sure do.
re:
http://www.garlic.com/~lynn/2007h.html#77 Linux: The Completely Fair Scheduler
you mean, as opposed to
http://www.garlic.com/~lynn/2007e.html#48 time spent/day on a computer
or the nsfnet stuff?
http://www.garlic.com/~lynn/lhwemail.html#nsfnet
http://www.garlic.com/~lynn/subnetwork.html#nsfnet
and
http://www.garlic.com/~lynn/2006w.html#21 SNA/VTAM for NSFNET
or the ha/medusa stuff?
http://www.garlic.com/~lynn/lhwemail.html#medusa
and
http://www.garlic.com/~lynn/2006x.html#3
Refed: **, - **, - **, - **, - **
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 -0600
jmfbahciv writes:
Do you get just a little bit discouraged? I sure do.
re:
http://www.garlic.com/~lynn/2007h.html#77 Linux: The Completely Fair Scheduler
http://www.garlic.com/~lynn/2007i.html#1 Linux: The Completely Fair Scheduler
then, of course, there is Boyd's line ...
http://www.garlic.com/~lynn/2007.html#20 MS to world: Stop sending money, we have enough - was Re: Most ... can't run Vista
http://www.garlic.com/~lynn/2007h.html#74 John W. Backus, 82, Fortran developer, dies
Refed: **, - **, - **, - **, - **, - **, - **
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 -0600
krw <krw@att.bizzzz> writes:
The problem with the F16 is its single engine. The local ANG group
was tasked with air intercept (mostly Soviet Bears) over the North
Atlantic and NE Canada/US. The pilots were a little nervous out over
the N-Atlantic without a spare candle. They were going to get F15s
but were retasked to air-to-mud instead. After 9/11 they still do
intercept though.
re:
http://www.garlic.com/~lynn/2007h.html#73 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#74 John W. Backus, 82, Fortran developer, dies
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
http://www.garlic.com/~lynn/2002c.html#14 OS Workloads : Interactive etc
http://www.garlic.com/~lynn/2002d.html#1 OS Workloads : Interactive etc
http://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:
http://www.garlic.com/~lynn/2007h.html#68 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#69 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#70 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#71 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#72 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#75 John W. Backus, 82, Fortran developer, dies
past posts mentioning Boyd
http://www.garlic.com/~lynn/subboyd.html#boyd
various URLs from around the web mentioning Boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0600
kkt <kkt@zipcon.net> writes:
How frequently does the single engine flame out in a situation where a
second engine would save you? How likely is that compared to all the
other ways you can die flying a fighter, such as being out-dogfought
by a more maneuverable, single-engine fighter?
f16 was vastly superior fighter ... touted for the f15 was that it
could be sort of be dual-use ... half-way a fighter and half-way a
bomber ... or it could act as a missle platfrom, stand-off from the
actual battle and lob missles at the other guy.
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
http://www.garlic.com/~lynn/2007h.html#73 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#74 John W. Backus, 82, Fortran developer, dies
http://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
http://www.garlic.com/~lynn/2007i.html#3 John W. Backus, 82, Fortran developer, dies
other posts in this subthread:
http://www.garlic.com/~lynn/2007h.html#68 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#69 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#70 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#71 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#72 John W. Backus, 82, Fortran developer, dies
http://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
http://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:
http://www.garlic.com/~lynn/2005t.html#1 Dangerous Hardware
http://www.garlic.com/~lynn/2005t.html#2 Dangerous Hardware
http://www.garlic.com/~lynn/2005t.html#5 Dangerous Hardware
http://www.garlic.com/~lynn/2006u.html#51 Where can you get a Minor in Mainframe?
http://www.garlic.com/~lynn/2007g.html#13 The Perfect Computer - 36 bits?
past posts mentioning Boyd
http://www.garlic.com/~lynn/subboyd.html#boyd
various URLs from around the web mentioning Boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0600
krw <krw@att.bizzzz> writes:
The FA18 didn't sacrifice the second engine though. The Navy
wouldn't have stood still for that.
re:
http://www.garlic.com/~lynn/2007i.html#3 John W. Backus, 82, Fortran developer, dies
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).
http://www.garlic.com/~lynn/2007h.html#69 John W. Backus, 82, Fortran developer, dies
http://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:
http://www.garlic.com/~lynn/2007h.html#68 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#70 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#72 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#75 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#73 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#74 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#3 John W. Backus, 82, Fortran developer, dies
http://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
http://www.garlic.com/~lynn/2007h.html#29 sizeof() was: The Perfect Computer - 36 bits
http://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:
http://www.garlic.com/~lynn/aadsm13.htm#18 A challenge
http://www.garlic.com/~lynn/aadsm15.htm#6 x9.59
http://www.garlic.com/~lynn/aadsm21.htm#11 Payment Tokens
http://www.garlic.com/~lynn/aadsm21.htm#26 X.509 / PKI, PGP, and IBE Secure Email Technologies
http://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm23.htm#56 UK Detects Chip-And-PIN Security Flaw
http://www.garlic.com/~lynn/aadsm24.htm#23 Use of TPM chip for RNG?
http://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm26.htm#48 Governance of anonymous financial services
http://www.garlic.com/~lynn/2002n.html#18 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2004j.html#2 Authenticated Public Key Exchange without Digital Certificates?
http://www.garlic.com/~lynn/2005u.html#26 RSA SecurID product
http://www.garlic.com/~lynn/2005u.html#32 AMD to leave x86 behind?
some if it shows up here
http://www.garlic.com/~lynn/x959.html#aads
and in these patents (which we have no rights/interest)
http://www.garlic.com/~lynn/aadssummary.htm
Refed: **, - **, - **, - **
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 -0600
krw <krw@att.bizzzz> writes:
Reset? The Tigershark was a bet my NA completely on their dime. The
DOD didn't ask for it. Since it wasn't their idea they "disavowed
all knowledge of its actions".
significant factions in DOD attempted to keep Boyd from doing F16 ... as
per prior reference ... as per reference in this post to Leavenworth
http://www.garlic.com/~lynn/2007h.html#75 John W. Backus, 82, Fortran developer, dies
... 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
http://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:
http://www.garlic.com/~lynn/2007h.html#68 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#69 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#70 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#71 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#72 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#73 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#74 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#75 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#3 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#4 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#5 John W. Backus, 82, Fortran developer, dies
past posts mentioning Boyd
http://www.garlic.com/~lynn/subboyd.html#boyd
various URLs from around the web mentioning Boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2
Refed: **, - **, - **, - **, - **
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 -0600
Anne & Lynn Wheeler <lynn@garlic.com> writes:
somewhat related is past post about KISS and simple can actually be more
difficult ... but quite a bit more effective ... than complex
http://www.garlic.com/~lynn/2007h.html#29 sizeof() was: The Perfect Computer - 36 bits
http://www.garlic.com/~lynn/2007h.html#30 sizeof() was: The Perfect Computer - 36 bits
re:
http://www.garlic.com/~lynn/2007i.html#5 John W. Backus, 82, Fortran developer, dies
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
http://www.garlic.com/~lynn/2007h.html#73 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#75 John W. Backus, 82, Fortran developer, dies
past posts mentioning F20/tigershark
http://www.garlic.com/~lynn/94.html#8 scheduling & dynamic adaptive ... long posting warning
http://www.garlic.com/~lynn/2002c.html#14 OS Workloads : Interactive etc
http://www.garlic.com/~lynn/2002d.html#1 OS Workloads : Interactive etc
http://www.garlic.com/~lynn/2005d.html#45 Thou shalt have no other gods before the ANSI C standard
http://www.garlic.com/~lynn/2006g.html#13 News Release
http://www.garlic.com/~lynn/2007i.html#3 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#4 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#6 John W. Backus, 82, Fortran developer, dies
other posts in this subthread:
http://www.garlic.com/~lynn/2007h.html#68 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#69 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#70 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#71 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#72 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#73 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#74 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#75 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#5 John W. Backus, 82, Fortran developer, dies
past posts mentioning Boyd
http://www.garlic.com/~lynn/subboyd.html#boyd
various URLs from around the web mentioning Boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2
Refed: **, - **, - **, - **
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 -0600
CBFalconer <cbfalconer@yahoo.com> writes:
This post shows your newsreader failure to keep the reference count
down to 20 items.
the reference URL approach can be simpler than have a 500+ line post
that except for a few lines ... is all the previous posts in the thread
for possibly the last several weeks :)
recent posts happening to mention Boyd, swing-wing, F14, F15, F16, F18,
and/or F20/Tigershark
http://www.garlic.com/~lynn/2007.html#20 MS to world: Stop sending money, we have enough - was Re: Most ... can't run Vista
http://www.garlic.com/~lynn/2007b.html#37 Special characters in passwords was Re: RACF - Password rules
http://www.garlic.com/~lynn/2007c.html#25 Special characters in passwords was Re: RACF - Password rules
http://www.garlic.com/~lynn/2007c.html#53 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007e.html#18 Is computer history taught now?
http://www.garlic.com/~lynn/2007e.html#45 time spent/day on a computer
http://www.garlic.com/~lynn/2007e.html#48 time spent/day on a computer
http://www.garlic.com/~lynn/2007e.html#53 time spent/day on a computer
http://www.garlic.com/~lynn/2007e.html#55 time spent/day on a computer
http://www.garlic.com/~lynn/2007f.html#15 Designing database tables for performance?
http://www.garlic.com/~lynn/2007f.html#23 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007f.html#29 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007f.html#41 time spent/day on a computer
http://www.garlic.com/~lynn/2007g.html#13 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007h.html#29 sizeof() was: The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007h.html#57 ANN: Microsoft goes Open Source
http://www.garlic.com/~lynn/2007h.html#68 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#69 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#71 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#72 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#73 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#74 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007h.html#75 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#2 Linux: The Completely Fair Scheduler
http://www.garlic.com/~lynn/2007i.html#3 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#4 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#5 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#6 John W. Backus, 82, Fortran developer, dies
http://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 -0600
jmfbahciv writes:
It seems that the banking industry wants to push the computing work,
especially the mainframe part of it, off onto each individual. That's
what removing paper checks is all about. IMO, they are pushing this
computing work in exactly the wrong direction.
re:
http://www.garlic.com/~lynn/2007i.html#0 John W. Backus, 82, Fortran developer, dies
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 -0600
Anne & Lynn Wheeler <lynn@garlic.com> writes:
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 ...
re:
http://www.garlic.com/~lynn/2007i.html#7 John W. Backus, 82, Fortran developer, dies
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 -0600
oscarptyltd@ibm-main.lst (Clem Clarke) writes:
In PCP, MFT and MVT, SVC 99 didn't even exist! Nor TSO.
just for laughs here is the (Hercules) build install procedure for
TSO/TCAM for MVT
http://www.conmicro.cx/hercos360/tsotcam.html
and from my rfc index
http://www.garlic.com/~lynn/rfcietff.htm
RFC90
http://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 ...
Refed: **, - **, - **, - **, - **, - **
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 -0600
jmfbahciv writes:
That's a minor detail. I am thinking about having any ability
to detect that the fit has hit the shan before a bank goes
bust.
re:
http://www.garlic.com/~lynn/2007h.html#78 John W. Backus, 82, Fortran developer, dies
this long-winded post includes disussion of effects of variable
rate mortgages nearly taking down a leading financial institution
http://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk Management and Information Security
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0600
Anne & Lynn Wheeler <lynn@garlic.com> writes:
http://www.garlic.com/~lynn/2007g.html#34 U.S. Cedes Top Spot in Global IT Competitiveness
http://www.garlic.com/~lynn/2006m.html#49 The Pankian Metaphor (redux)
http://www.garlic.com/~lynn/2006x.html#32 Toyota set to lift crown from GM
latest update ... somewhat going back to the whole thing about import
quotas from a couple decades ago (supposedly temporary measure to allow
the industry breathing room to remake themselves)
Toyota's March Sales Jump, GM, Ford Fall
http://www.redorbit.com/news/business/891452/toyotas_march_sales_jump_gm_ford_fall/index.html
as well as topic drift about the C4 activity
http://www.garlic.com/~lynn/2007g.html#29 The Perfect Computer - 36 bits?
re:
http://www.garlic.com/~lynn/2007g.html#52 U.S. Cedes Top Spot in Global IT Competitiveness
Toyota Tops GM in 1Q Global Auto Sales
http://biz.yahoo.com/ap/070424/japan_toyota_gm.html?.v=22
Refed: **, - **, - **, - **, - **, - **, - **, - **
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 -0600
Ben Pfaff <blp@cs.stanford.edu> writes:
All of that is just background for my question, although I'll
gladly accept corrections to any of it. My question is this: in
my earlier research, I was sure that I found a reference that
said that, at approximately the time when CP-40 and CP-67 were
being developed, developers considered it impractical or even
impossible to virtualize an MMU (at least with any efficiency).
The CP-40 extension and CP-67 certainly proved them wrong. But
now I'm unable to find any trace of that reference. Can anyone
point me in the right direction?
waiting for 360/67 ... the science center
http://www.garlic.com/~lynn/subtopic.html#545tech
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
http://www.princeton.edu/~melinda/
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/funcChar/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 correspondance
http://www.garlic.com/~lynn/2001h.html#65 UUCP email
http://www.garlic.com/~lynn/2006t.html#6 Ranking of non-IBM mainframe builders?
http://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)
http://www.garlic.com/~lynn/2002j.html#0 HONE was .. Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2004b.html#31 determining memory size
http://www.garlic.com/~lynn/2004h.html#27 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004p.html#50 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2005c.html#59 intel's Vanderpool and virtualization in general
http://www.garlic.com/~lynn/2005d.html#66 Virtual Machine Hardware
http://www.garlic.com/~lynn/2005g.html#17 DOS/360: Forty years
http://www.garlic.com/~lynn/2005h.html#18 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005i.html#39 Behavior in undefined areas?
http://www.garlic.com/~lynn/2005j.html#50 virtual 360/67 support in cp67
http://www.garlic.com/~lynn/2005p.html#27 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006e.html#7 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT
http://www.garlic.com/~lynn/2006l.html#21 Virtual Virtualizers
http://www.garlic.com/~lynn/2006m.html#26 Mainframe Limericks
http://www.garlic.com/~lynn/2006o.html#19 Source maintenance was Re: SEQUENCE NUMBERS
http://www.garlic.com/~lynn/2006q.html#1 Materiel and graft
http://www.garlic.com/~lynn/2006q.html#45 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006q.html#49 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006w.html#3 IBM sues maker of Intel-based Mainframe clones
http://www.garlic.com/~lynn/2007b.html#20 How many 36-bit Unix ports in the old days?
http://www.garlic.com/~lynn/2007f.html#12 FBA rant
Refed: **, - **, - **, - **, - **, - **
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 -0600
Ben Pfaff <blp@cs.stanford.edu> writes:
It's interesting that this would be someone from France who
implemented it. This rings a bell: I have a paper here titled
'Virtual Machine or Virtual Operating System?' attributed to
J. Bellino, Cl. Hans from IBM-France, Grenoble Scientific Center.
Is either of these people relevant?
re:
http://www.garlic.com/~lynn/2007i.html#14 when was MMU virtualization first considered practical?
claude also did assignments in the states ... but it was neither of
the authors you mention.
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0600
Ben Pfaff <blp@cs.stanford.edu> writes:
The System/370 relocation architecture was different from the 360/67
architecture; it allowed both 2K and 4K pages and both 64K and 1M
segments. So, Auroux modified his modified CP-67 to support 64K
segments and the new System/370 instructions. He ran that system
second-level, so he could run a virtual S/370 third-level. He
developed a prototype "CP-370" in that third-level virtual
machine. Then, to test this CP-370's virtualization of
System/370 virtual memory, he had to run it both third- and
fourth-level, with a couple of CMS machines running fifth-level.
Alan was his first name.
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
http://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 machine
when 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.
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0600
Steve O'Hara-Smith <steveo@eircom.net> writes:
Pull transaction banking is the fundamental design flaw here, the
movement of money out of an account should be a push not a pull. A cheque
on this side of the pond is good for (at most) one transaction, there is a
pull mechanism (called Direct Debit) and each recurrent pull has to be
setup explicitly before the payee is allowed to start their regular pull.
Personally I hate them and try to avoid them in preference to standing
orders where there is no freedom for the payee to specify the amount.
so some amount of the check21 numbers are about cost of paper
infrastructure.
http://www.garlic.com/~lynn/2007e.html#28 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007i.html#0 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#9 John W. Backus, 82, Fortran developer, dies
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 writting 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
http://www.garlic.com/~lynn/subintegrity.html#3factor
• something you have
• something you know
• something you are
... normally, multi-factor authentication is considered more secure
based on assumption that different factors have different
vulnerabilities and/or failure modes; aka PIN (something you know) as
countermeasure to lost/stolen card (something you have).
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
http://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) succesful 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
http://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:
http://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
http://www.garlic.com/~lynn/subpubkey.html#catch22
misc. past posts mentioning some kind of fraud, exploit, vulnerability,
threat and/or risk
http://www.garlic.com/~lynn/subintegrity.html#fraud
semi-related recent posts
http://www.garlic.com/~lynn/2007h.html#20 sizeof() was: The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007h.html#22 sizeof() was: The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007h.html#26 sizeof() was: The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007h.html#27 sizeof() was: The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007h.html#28 sizeof() was: The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007h.html#32 sizeof() was: The Perfect Computer - 36 bits?
Refed: **, - **, - **, - **, - **, - **, - **
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 -0600
greymaus writes:
Good post. You seem to know what you are writing about. In the past,
when large numbers of Irish people emigrated, it was pointed out that
we were going to the expense of rearing these people, educating them
to a fair degree, and then sending them off to produce money for the
U.S. or other economys.
quick search engine for some actual numbers turns up this report
from 2004 based on 2002 census data ... executive summary
http://www.cis.org/articles/2004/fiscalexec.html
full report
http://www.cis.org/articles/2004/fiscal.html
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.
Refed: **, - **, - **, - **, - **, - **
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 -0600
Anne & Lynn Wheeler <lynn@garlic.com> writes:
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.
re:
http://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies
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.
http://www.garlic.com/~lynn/2007e.html#29 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007e.html#58 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007e.html#62 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007f.html#58 Securing financial transactions a high priority for 2007
say somebody is opening an account using a non-existant 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
http://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).
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0600
rschuh wrote:
Does anyone know of a documented case of VM being penetrated by hackers?
long ago, I briefly succumbed once.
The future system project was in full swing ... lots of past posts
http://www.garlic.com/~lynn/subtopic.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
http://www.garlic.com/~lynn/2007i.html#14 when was MMU virtualization first considered practical?
http://www.garlic.com/~lynn/2007i.html#15 when was MMU virtualization first considered practical?
http://www.garlic.com/~lynn/2007i.html#16 when was MMU virtualization first considered practical?
basically the cp67 service at the science center
http://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
http://www.nsa.gov/selinux/list-archive/0409/8362.cfm
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.
http://www.garlic.com/~lynn/99.html#7 IBM S/360
http://www.garlic.com/~lynn/99.html#33 why is there an "@" key?
http://www.garlic.com/~lynn/2000g.html#4 virtualizable 360, was TSS ancient history
http://www.garlic.com/~lynn/2001i.html#44 Withdrawal Announcement 901-218 - No More 'small machines'
http://www.garlic.com/~lynn/2002h.html#50 crossreferenced program code listings
http://www.garlic.com/~lynn/2002h.html#60 Java, C++ (was Re: Is HTML dead?)
http://www.garlic.com/~lynn/2002i.html#62 subjective Q. - what's the most secure OS?
http://www.garlic.com/~lynn/2002p.html#37 Newbie: Two quesions about mainframes
http://www.garlic.com/~lynn/2002q.html#47 myths about Multics
http://www.garlic.com/~lynn/2003b.html#0 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003e.html#66 History of project maintenance tools -- what and when?
http://www.garlic.com/~lynn/2003f.html#1 History of project maintenance tools -- what and when?
http://www.garlic.com/~lynn/2003g.html#5 Any DEC 340 Display System Doco ?
http://www.garlic.com/~lynn/2003g.html#18 Multiple layers of virtual address translation
http://www.garlic.com/~lynn/2003g.html#29 Lisp Machines
http://www.garlic.com/~lynn/2004b.html#31 determining memory size
http://www.garlic.com/~lynn/2004c.html#7 IBM operating systems
http://www.garlic.com/~lynn/2004e.html#36 NSF interest in Multics security
http://www.garlic.com/~lynn/2004p.html#50 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2005b.html#12 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#45 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005d.html#58 Virtual Machine Hardware
http://www.garlic.com/~lynn/2005f.html#63 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
http://www.garlic.com/~lynn/2005h.html#18 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005o.html#34 Not enough parallelism in programming
http://www.garlic.com/~lynn/2005o.html#46 Article: The True Value of Mainframe Security
http://www.garlic.com/~lynn/2005p.html#20 address space
http://www.garlic.com/~lynn/2005p.html#27 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT
http://www.garlic.com/~lynn/2006h.html#14 Security
http://www.garlic.com/~lynn/2006l.html#21 Virtual Virtualizers
http://www.garlic.com/~lynn/2006m.html#26 Mainframe Limericks
http://www.garlic.com/~lynn/2006n.html#2 The System/360 Model 20 Wasn't As Bad As All That
http://www.garlic.com/~lynn/2006o.html#19 Source maintenance was Re: SEQUENCE NUMBERS
http://www.garlic.com/~lynn/2006w.html#3 IBM sues maker of Intel-based Mainframe clones
http://www.garlic.com/~lynn/2006x.html#19 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2007g.html#31 Wylbur and Paging
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0600
Al Balmer <albalmer@att.net> writes:
<G> Most non-experts don't know such programs exist. They don't even
know they need them.
early in cp67 ... it was modified to automatic reipl/reboot after
failure ... this would get things back up within possibly a minute or
two for login. recent post/reference
http://www.garlic.com/~lynn/2007d.html#22 How many 36-bit Unix ports in the old days?
http://www.garlic.com/~lynn/2007d.html#23 How many 36-bit Unix ports in the old days?
http://www.garlic.com/~lynn/2007g.html#44 1960s: IBM mgmt mistrust of SLT for ICs?
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
http://www.garlic.com/~lynn/2007d.html#23 How many 36-bit Unix ports in the old days?
http://www.garlic.com/~lynn/2007d.html#66 Is computer history taugh now?
http://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
http://www.garlic.com/~lynn/subtopic.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
http://www.garlic.com/~lynn/2006w.html#email750102
in this post
http://www.garlic.com/~lynn/2006w.html#7 Why these original FORTRAN quirks?
and
http://www.garlic.com/~lynn/2006w.html#email750430
in this post
http://www.garlic.com/~lynn/2006w.html#7 Why these original FORTRAN quirks?
even more topic drift ...
http://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 -0600
Morten Reistad <first@last.name> writes:
And the set of cheap servers will prove to be a lot better solution
when implemented right, because it gives you diversity in network topology,
energy supply and geography, something a cluster can never give you.
when we were doing ha/cmp product ... we didn't make much difference
between lots of cheap servers and clusters ... from development and
architectual design standpoint. it seems to mainly come from vendors
pricing policies as opposed to any fundamental architectual difference
http://www.garlic.com/~lynn/subtopic.html#hacmp
we were looking somewhat at the higher-priced end of the market
for ha/medusa stuff
http://www.garlic.com/~lynn/lhwemail.html#medusa
and
http://www.garlic.com/~lynn/95.html#13
http://www.garlic.com/~lynn/96.html#15
and some of the bandwidth requirements for geographic survivabilty
stuff
http://www.garlic.com/~lynn/subtopic.html#available
recent posts mentioning geographic survivability
http://www.garlic.com/~lynn/2007.html#29 Just another example of mainframe costs
http://www.garlic.com/~lynn/2007.html#36 How many 36-bit Unix ports in the old days?
http://www.garlic.com/~lynn/2007.html#39 Just another example of mainframe costs
http://www.garlic.com/~lynn/2007e.html#16 Attractive Alternatives to Mainframes
http://www.garlic.com/~lynn/2007e.html#38 FBA rant
http://www.garlic.com/~lynn/2007f.html#56 Is computer history taught now?
http://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
http://www.garlic.com/~lynn/subnetwork.html#gateway
and recent post
http://www.garlic.com/~lynn/2007h.html#67 SSL vs. SSL over tcp/ip
Refed: **, - **, - **
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 -0600
Frank McCoy <mccoyf@millcomm.com> writes:
The IRS gets it's cut (and so do the states) no matter who makes the
money. Living on unreported income is how Al Capone got brought down;
and the bookkeeping practices today make it *really* hard to hide extra
income. "Money Laundering" doesn't even work; it merely allows you to
pay taxes in illegal income so the IRS doesn't go after you.
part of this is that the criminal justice system can get all bolixed up
with proving guilt beyond resonable doubt ... even when all parties know
the true circumstances. the tax system has effectively been able to
invert the problem ... rather than the gov. having to prove there was an
illegal source ... all the gov. has to do is claim unreported and then
it shifts back to the accused to dig themselves out of the situation (in
effect prove that they are innocent ... as opposed to the gov. proving
guilt ... i.e. since you have a home ... how did you pay for it?).
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
http://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
http://www.garlic.com/~lynn/aadsm26.htm#61 crypto component services - is there a market?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0600
greymaus writes:
That all will take a while to digest. Generally, good stuff, with the
important point that more education is needed generally in a modern
economy.. Latin America would still not have the sort of education
system that Ireland had, even in the 1940's-50's. There are a lot of
factors to consider.
re:
http://www.garlic.com/~lynn/2007i.html#18 John W. Backus, 82, Fortran developer, dies
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.
http://www.garlic.com/~lynn/2002k.html#45 How will current AI/robot stories play when AIs are real?
http://www.garlic.com/~lynn/2003i.html#28 Offshore IT
http://www.garlic.com/~lynn/2003i.html#45 Offshore IT
http://www.garlic.com/~lynn/2003i.html#55 Offshore IT
http://www.garlic.com/~lynn/2003p.html#33 [IBM-MAIN] NY Times editorial on white collar jobs going
http://www.garlic.com/~lynn/2004b.html#42 The SOB that helped IT jobs move to India is dead!
http://www.garlic.com/~lynn/2004d.html#18 The SOB that helped IT jobs move to India is dead!
http://www.garlic.com/~lynn/2004h.html#18 Low Bar for High School Students Threatens Tech Sector
http://www.garlic.com/~lynn/2005e.html#48 Mozilla v Firefox
http://www.garlic.com/~lynn/2005g.html#43 Academic priorities
http://www.garlic.com/~lynn/2006g.html#20 The Pankian Metaphor
http://www.garlic.com/~lynn/2006l.html#63 DEC's Hudson fab
http://www.garlic.com/~lynn/2007g.html#7 U.S. Cedes Top Spot in Global IT Competitiveness
Refed: **, - **, - **
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 -0600
Howard Brazee <howard@brazee.net> writes:
That makes sense. But continuing that thought, I see Apple, which
doesn't try to make its OS be all things for all people (and hardware
manufacturers). Even if it *is* UNIX.
nominally the argument is that complexity contributes to confusion and
failures ... KISS is frequently better because it minimizes
confusion which can be major source of failures, vulnerabilities,
threats and exploits. however, another argument is that the solution
paradigm has to match the environment ... that there can be enormous
amount of complexity introduced when the solution paradigm is a
mismatch for the environment that it is being applied to.
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:
http://www.garlic.com/~lynn/2007i.html#3 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#4 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#6 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#7 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#8 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#10 John W. Backus, 82, Fortran developer, dies
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0600
Howard Brazee <howard@brazee.net> writes:
That makes sense. But continuing that thought, I see Apple, which
doesn't try to make its OS be all things for all people (and hardware
manufacturers). Even if it *is* UNIX.
re:
http://www.garlic.com/~lynn/2007i.html#25 Latest Principles of Operation
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.
http://www.garlic.com/~lynn/2007h.html#29 sizeof() was: The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007h.html#30 sizeof() was: The Perfect Computer - 36 bits?
http://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:
http://www.garlic.com/~lynn/94.html#54 How Do the Old Mainframes
http://www.garlic.com/~lynn/95.html#0 pathlengths
http://www.garlic.com/~lynn/2000e.html#42 IBM's Workplace OS (Was: .. Pink)
http://www.garlic.com/~lynn/2001f.html#23 MERT Operating System & Microkernels
http://www.garlic.com/~lynn/2001h.html#11 checking some myths.
http://www.garlic.com/~lynn/2001j.html#36 Proper ISA lifespan?
http://www.garlic.com/~lynn/2001k.html#45 SMP idea for the future
http://www.garlic.com/~lynn/2001l.html#25 mainframe question
http://www.garlic.com/~lynn/2001m.html#47 TSS/360
http://www.garlic.com/~lynn/2003.html#50 Origin of Kerberos
http://www.garlic.com/~lynn/2003.html#60 MIDAS
http://www.garlic.com/~lynn/2003h.html#37 Does PowerPC 970 has Tagged TLBs (Address Space Identifiers)
http://www.garlic.com/~lynn/2003j.html#72 Microkernels are not "all or nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2003k.html#5 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003k.html#9 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003k.html#24 Microkernels are not "all or nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2003k.html#26 Microkernels are not "all or nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2003k.html#27 Microkernels are not "all or nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2003k.html#28 Microkernels are not "all or nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2003k.html#30 IBM channels, was Re: Microkernels are not "all or nothing"
http://www.garlic.com/~lynn/2003k.html#37 Microkernels are not "all or nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2005b.html#22 The Mac is like a modern day Betamax
http://www.garlic.com/~lynn/2005c.html#44 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#56 intel's Vanderpool and virtualization in general
http://www.garlic.com/~lynn/2005c.html#63 intel's Vanderpool and virtualization in general
http://www.garlic.com/~lynn/2005f.html#10 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2006p.html#10 What part of z/OS is the OS?
http://www.garlic.com/~lynn/2006p.html#11 What part of z/OS is the OS?
http://www.garlic.com/~lynn/2007g.html#70 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007g.html#83 IBM to the PCM market
Refed: **, - **, - **, - **, - **
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 -0600
Morten Reistad <first@last.name> writes:
So, the file system will have to handle being yanked at any time.
We have the invention of log structured file systems for this.
Such file systems were introduced as the default in Linux in 2003.
Which means the file system will backtrack on the next mount,
and go to the last valid checkpoint. Then, the file system is
in a known state, and applications functional. (i.e. no
zapped indices etc). Your data may be lost, but that is what
you have for yanking the media.
small digression ... the normal use of log structured file system was
as much about attempting to do arm optimization for writes ... as it
was for integrity purposes ... as opposed to journaled/logging file
systems (where changes are journaled/logged in manner similar to
database transactions).
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
http://www.garlic.com/~lynn/subtopic.html#hacmp
and geographically distributed operation
http://www.garlic.com/~lynn/subtopic.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 writting 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
http://www.garlic.com/~lynn/93.html#28 Log Structured filesystems -- think twice
http://www.garlic.com/~lynn/93.html#29 Log Structured filesystems -- think twice
http://www.garlic.com/~lynn/2000c.html#24 Hard disks, one year ago today
http://www.garlic.com/~lynn/2001f.html#59 JFSes: are they really needed?
http://www.garlic.com/~lynn/2002b.html#20 index searching
http://www.garlic.com/~lynn/2002l.html#36 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2003b.html#69 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2004g.html#22 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2005l.html#41 25% Pageds utilization on 3390-09?
http://www.garlic.com/~lynn/2005n.html#36 Code density and performance?
http://www.garlic.com/~lynn/2006j.html#3 virtual memory
http://www.garlic.com/~lynn/2006j.html#10 The Chant of the Trolloc Hordes
http://www.garlic.com/~lynn/2007.html#30 V2X2 vs. Shark (SnapShot v. FlashCopy)
various past posts/threads mentioning database memory
http://www.garlic.com/~lynn/2002b.html#33 Does it support "Journaling"?
http://www.garlic.com/~lynn/2002b.html#34 Does it support "Journaling"?
http://www.garlic.com/~lynn/2003c.html#49 Filesystems
http://www.garlic.com/~lynn/2003d.html#54 Filesystems
http://www.garlic.com/~lynn/2005n.html#20 Why? (Was: US Military Dead during Iraq War
http://www.garlic.com/~lynn/2005n.html#32 Why? (Was: US Military Dead during Iraq War
http://www.garlic.com/~lynn/2006o.html#26 Cache-Size vs Performance
http://www.garlic.com/~lynn/2006y.html#36 Multiple mappings
Refed: **, - **, - **, - **, - **, - **, - **, - **
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 -0600
re:
http://www.garlic.com/~lynn/2007i.html#23 John W. Backus, 82, Fortran developer, dies
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:
http://www.garlic.com/~lynn/2001c.html#45 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001g.html#38 distributed authentication
http://www.garlic.com/~lynn/2001j.html#54 Does "Strong Security" Mean Anything?
http://www.garlic.com/~lynn/2002.html#12 A terminology question
http://www.garlic.com/~lynn/2002d.html#14 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002f.html#35 Security and e-commerce
http://www.garlic.com/~lynn/2002j.html#14 Symmetric-Key Credit Card Protocol on Web Site
http://www.garlic.com/~lynn/2004i.html#5 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#16 New Method for Authenticated Public Key Exchange without Digital Ceritificates
http://www.garlic.com/~lynn/2004j.html#15 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2004j.html#37 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2005g.html#33 Good passwords and security priorities
http://www.garlic.com/~lynn/2005g.html#37 MVS secure configuration standard
http://www.garlic.com/~lynn/2005i.html#1 Brit banks introduce delays on interbank xfers due to phishing boom
http://www.garlic.com/~lynn/2005i.html#11 Revoking the Root
http://www.garlic.com/~lynn/2005j.html#52 Banks
http://www.garlic.com/~lynn/2005k.html#1 More on garbage
http://www.garlic.com/~lynn/2005k.html#55 Encryption Everywhere? (Was: Re: Ho boy! Another big one!)
http://www.garlic.com/~lynn/2005l.html#29 Importing CA certificate to smartcard
http://www.garlic.com/~lynn/2005l.html#35 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005o.html#2 X509 digital certificate for offline solution
http://www.garlic.com/~lynn/2005v.html#2 ABN Tape - Found
http://www.garlic.com/~lynn/2006c.html#35 X.509 and ssh
http://www.garlic.com/~lynn/2006d.html#26 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006d.html#28 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006e.html#26 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006e.html#44 Does the Data Protection Act of 2005 Make Sense
http://www.garlic.com/~lynn/2006h.html#15 Security
http://www.garlic.com/~lynn/2006h.html#26 Security
http://www.garlic.com/~lynn/2006k.html#4 Passwords for bank sites - change or not?
http://www.garlic.com/~lynn/2006k.html#16 Value of an old IBM PS/2 CL57 SX Laptop
http://www.garlic.com/~lynn/2006k.html#23 Value of an old IBM PS/2 CL57 SX Laptop
http://www.garlic.com/~lynn/2006k.html#33 Password Complexity
http://www.garlic.com/~lynn/2006p.html#9 New airline security measures in Europe
http://www.garlic.com/~lynn/2006u.html#40 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006u.html#43 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006v.html#2 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006v.html#42 On sci.crypt: New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006v.html#49 Patent buster for a method that increases password security
http://www.garlic.com/~lynn/2006x.html#14 IBM ATM machines
http://www.garlic.com/~lynn/2007.html#42 The logic of privacy
http://www.garlic.com/~lynn/2007b.html#13 special characters in passwords
http://www.garlic.com/~lynn/2007b.html#20 How many 36-bit Unix ports in the old days?
http://www.garlic.com/~lynn/2007b.html#33 security engineering versus information security
http://www.garlic.com/~lynn/2007b.html#60 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#10 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#11 Decoding the encryption puzzle
http://www.garlic.com/~lynn/2007c.html#32 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#35 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#43 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007f.html#75 Securing financial transactions a high priority for 2007
Refed: **, - **, - **, - **
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 -0600
re:
http://www.garlic.com/~lynn/2007i.html#20 Does anyone know of a documented case of VM being penetrated by hackers?
for a little topic drift ... a little about virtual machine assurance
in recent post to ibm-main
http://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 -0700
On Apr 26, 1:04 am, Brian Inglis <Brian.Ing...@SystematicSW.Invalid>
wrote:
It was either that or add non-IBM code from the SHARE Waterloo tapes
into the product and credit the authors. If you or others inside didn't
write it, they then redesigned and reimplemented the idea from SHARE.
FOr example RETRIEVE for command line recall allowing editing replaced
the equivalent SHARE code attached to PA2 IIRC.
re:
http://www.garlic.com/~lynn/2007i.html#21 John W. Backus, 82, Fortran
developer, dies
internal datacenters and external customers were compareable. 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:
http://www.garlic.com/~lynn/2006p.html#28 Greatest Software Ever
Written?
http://www.garlic.com/~lynn/2006p.html#31 "25th Anniversary of the
Personal Computer"
http://www.garlic.com/~lynn/2006r.html#7 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006t.html#36 The Future of CPUs: What's After Multi-Core?
to reference here
http://www.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
http://www.garlic.com/~lynn/subtopic.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)
http://www.garlic.com/~lynn/2001e.html#6 Blame it all on Microsoft
http://www.garlic.com/~lynn/2002c.html#4 Did Intel Bite Off More Than
It Can Chew?
http://www.garlic.com/~lynn/2002p.html#2 IBM OS source code
http://www.garlic.com/~lynn/2002p.html#3 IBM OS source code
http://www.garlic.com/~lynn/2002p.html#7 myths about Multics
http://www.garlic.com/~lynn/2003k.html#46 Slashdot: O'Reilly On The
Importance Of The Mainframe Heritage
http://www.garlic.com/~lynn/2004m.html#47 IBM Open Sources Object Rexx
http://www.garlic.com/~lynn/2004m.html#53 4GHz is the glass ceiling?
http://www.garlic.com/~lynn/2005c.html#42 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#50 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005e.html#34 Thou shalt have no other
gods before the ANSI C standard
http://www.garlic.com/~lynn/2005e.html#35 Thou shalt have no other
gods before the ANSI C standard
http://www.garlic.com/~lynn/2005f.html#15 Where should the type
information be: in tags and descriptors
http://www.garlic.com/~lynn/2005j.html#29 IBM Plugs Big Iron to the
College Crowd
http://www.garlic.com/~lynn/2005j.html#41 TSO replacement?
http://www.garlic.com/~lynn/2005r.html#5 What ever happened to Tandem
and NonStop OS ?
http://www.garlic.com/~lynn/2005u.html#57 IPCS Standard Print Service
http://www.garlic.com/~lynn/2006b.html#8 Free to good home: IBM RT
UNIX
http://www.garlic.com/~lynn/2006f.html#38 Over my head in a JES exit
http://www.garlic.com/~lynn/2006j.html#29 How to implement Lpars
within Linux
http://www.garlic.com/~lynn/2006j.html#33 How to implement Lpars
within Linux
http://www.garlic.com/~lynn/2006n.html#34 Not Your Dad's Mainframe:
Little Iron
http://www.garlic.com/~lynn/2006o.html#14 SEQUENCE NUMBERS
http://www.garlic.com/~lynn/2007f.html#67 The Perfect Computer - 36
bits?
http://www.garlic.com/~lynn/2007g.html#54 The Perfect Computer - 36
bits?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0600
rfochtman@ibm-main.lst (Rick Fochtman) writes:
That increased instruction set allows for vastly increased capability,
in spite of the perceived complexity. Simple applications can still be
coded using simple instructions, but more complex requirements can be
met more simply and efficiently by using some of those "added
instructions" that seem to lead to complexity.
Complexity is far too often used as an excuse for incompetence or
laziness; not always or even most of the time, but still far too
often. You don't let a carpenter into your house if he doesn't know
how to use his tools, do you????
re:
http://www.garlic.com/~lynn/2007i.html#25 Latest Principles of Operation
http://www.garlic.com/~lynn/2007i.html#26 Latest Principles of Operation
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
http://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
a href="subtopic.html#smp">http://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
http://www.garlic.com/~lynn/subtopic.html#futuresys
and lots of past post mentioning 801, romp, rios, iliad, fort knox,
somerset, power/pc, etc
http://www.garlic.com/~lynn/subtopic.html#801
and old email with 801 references
http://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
http://www.garlic.com/~lynn/subtopic.html#360pcm
also some "FS" quotes referenced in this post
http://www.garlic.com/~lynn/2007f.html#28 The Perfect Computer - 36 bits?
from article by former executive here
http://www.ecole.org/Crisis_and_change_1995_1.htm
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
http://www.garlic.com/~lynn/2007g.html#55 IBM to the PCM market(the sky is falling!!!the sky is falling!!)
http://www.garlic.com/~lynn/2007g.html#57 IBM to the PCM market(the sky is falling!!!the sky is falling!!)
http://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)
http://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
http://www.garlic.com/~lynn/2007i.html#20 Does anyone know of a documented case of VM being penetrated by hackers?
http://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:
http://www.garlic.com/~lynn/2007d.html#21 How many 36-bit Unix ports in the old days?
http://www.garlic.com/~lynn/2007d.html#62 Cycles per ASM instruction
http://www.garlic.com/~lynn/2007e.html#32 I/O in Emulated Mainframes
http://www.garlic.com/~lynn/2007e.html#40 FBA rant
http://www.garlic.com/~lynn/2007f.html#28 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007f.html#73 Is computer history taught now?
http://www.garlic.com/~lynn/2007g.html#17 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007g.html#23 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007g.html#29 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007g.html#57 IBM to the PCM market(the sky is falling!!!the sky is falling!!)
http://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.
Refed: **, - **, - **
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 -0600
jmfbahciv writes:
Of course people can learn new things. I'm not talking about that.
Would you hire an elephant to dance a ballet? Would you hire
a ballet dancer to haul logs out of the forest? It has to do
with not putting a person in a position where, no matter how
hard he tries, his result will not be adequate. It makes
the employee very unhappy and you don't get the work done.
If you assign this guy work of the type he excels at, you'll
get a lot more done.
careful what you suggest ... you may find all tasks being reduced to the
lowest common denominator so tasks & people are fully interchangeable
w/o regard to skills or experience.
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).
http://www.garlic.com/~lynn/2007e.html#47 time spent/day on a computer
Refed: **, - **, - **
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 -0600
Bob.Richards@ibm-main.lst (Richards.Bob) writes:
3880-xx Controller series followed by the 3990-xxx series
DASD was 3380-D, 3380-E, 3380-J, 3380-K, 3390-1, 3390-2, 3390-3 (today's
major image) and 3390-9 (a true SLED pulled by crippled and maimed dogs)
Yes, the 3380s had four paths. Do not recall if it was ever increased.
3830 disk controller had dual channel along with "string switch" for
3330 ... allowing for four paths total (i.e. string connecting to two
different controllers, each of which could connect to two different
channels)
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/ibmsj2