List of Archived Posts
2005 Newsgroup Postings (2/12 - 3/16)
- [Lit.] Buffer overruns
- Self restarting property of RTOS-How it works?
- 360 longevity, was RISCs too close to hardware?
- IBM Acronyms
- Self restarting property of RTOS-How it works?
- 360 longevity, was RISCs too close to hardware?
- [Lit.] Buffer overruns
- Self restarting property of RTOS-How it works?
- intel's Vanderpool and virtualization in general (was Re: Cell press release, redacted.)
- intel's Vanderpool and virtualization in general (was Re: Cell press release, redacted.)
- Cerf and Kahn receive Turing award
- Cerf and Kahn receive Turing award
- Thou shalt have no other gods before the ANSI C standard
- Cerf and Kahn receive Turing award
- data integrity and logs
- Thou shalt have no other gods before the ANSI C standard
- Thou shalt have no other gods before the ANSI C standard
- Digital signature with Javascript
- Digital signature with Javascript
- Digital signature with Javascript
- shared memory programming on distributed memory model?
- Digital signature with Javascript
- Latest news about mainframe
- Radical z/OS
- Thou shalt have no other gods before the ANSI C standard
- The future of the Mainframe
- Latest news about mainframe
- Adversarial Testing, was Re: Thou shalt have no
- Adversarial Testing, was Re: Thou shalt have no
- Adversarial Testing, was Re: Thou shalt have no
- The Mainframe and its future.. or furniture
- The Mainframe and its future.. or furniture
- Is a cryptographic monoculture hurting us all?
- Thou shalt have no other gods before the ANSI C standard
- Adversarial Testing, was Re: Thou shalt have no
- Thou shalt have no other gods before the ANSI C standard
- backup/archive
- Thou shalt have no other gods before the ANSI C standard
- Thou shalt have no other gods before the ANSI C standard
- Thou shalt have no other gods before the ANSI C standard
- Thou shalt have no other gods before the ANSI C standard
- Thou shalt have no other gods before the ANSI C standard
- Thou shalt have no other gods before the ANSI C standard
- Secure design
- Thou shalt have no other gods before the ANSI C standard
- Thou shalt have no other gods before the ANSI C standard
- Secure design
- Thou shalt have no other gods before the ANSI C standard
- Secure design
- Secure design
- Secure design
- Thou shalt have no other gods before the ANSI C standard
- Thou shalt have no other gods before the ANSI C standard
- [Lit.] Buffer overruns
- [Lit.] Buffer overruns
- [Lit.] Buffer overruns
- Convering 2 Bytes of binary to BCD
- Thou shalt have no other gods before the ANSI C standard
- Virtual Machine Hardware
- Misuse of word "microcode"
- Misuse of word "microcode"
- Virtual Machine Hardware
- Misuse of word "microcode"
- Cranky old computers still being used
- Misuse of word "microcode"
- [Lit.] Buffer overruns
- Virtual Machine Hardware
- [Lit.] Buffer overruns
- Misuse of word "microcode"
- [Lit.] Buffer overruns
- Virtual Machine Hardware
- Metcalfe's Law Refuted
- [Lit.] Buffer overruns
- [Lit.] Buffer overruns
- [Lit.] Buffer overruns
- [Lit.] Buffer overruns
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: sci.crypt,alt.folklore.computers
Date: Sat, 12 Feb 2005 09:25:45 -0700
Anne & Lynn Wheeler writes:
According to NIST in the past 4 years, 871 buffer overflow
vulnerabilities were exploited, commprising ablout 20 percent
of all exploits
... snip
which is about the same percentage that I calculated from
the CVE database.
ref:
http://www.garlic.com/~lynn/2005b.html#20 [Lit.] Buffer overruns
just for reference ... the nist vulnerability database
http://icat.nist.gov/
note in the query interface at the nist ref, one of the top supplied
vulnerability keywords is buffer overflow
the cve database
http://cve.mitre.org/
for a little drift: "Safety-Critical Systems Computer Language Survey"
http://vl.fmnet.info/safety/lang-survey.html
for a little more drift, the waterfall method (from nasa):
http://www1.jsc.nasa.gov/bu2/PCEHHTML/pceh90.htm
and even more nasa drift, nasa dependable computing conference
http://www.hdcc.cs.cmu.edu/may01/index.html
and even more drift ... the first two keynote speakers in the
above ... worked on original sql/relational database (morphed into
sql/ds ... and later db2):
http://www.garlic.com/~lynn/subtopic.html#systemr
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Self restarting property of RTOS-How it works?
Newsgroups: comp.arch,comp.arch.embedded
Date: Sat, 12 Feb 2005 09:53:11 -0700
Ed Beroset writes:
It's interesting to learn that no engineers were ever involved in
building such flaws.
My background happens to be more in the engineering than the
computer science end of things, but I don't share your evident
contempt for the field. Here's an example: An embedded
communication system receives packet-based messages of varying
lengths at an average rate of 100 packets per minute, but
asynchronously. Because the system also checks its timing against
the recovered clock from the messages, which it can easily keep
synchronized within limits as long as it doesn't go too long without
receiving a packet. What is the probability that no packets will
arrive in an interval of five seconds?
I can answer that question easily because I've studied a little
computer science. Can you? If not, how can you properly engineer
the system?
here is example of a configuration and workload analysis
http://www.garlic.com/~lynn/99.html#67 System/1 ?
http://www.garlic.com/~lynn/99.html#70 Series/1 as NCP (was System/1?)
with the help of performance predictor and configurators on
hone:
http://www.garlic.com/~lynn/subtopic.html#hone
hone was the online system(s) that provided support for world-wide
sales, marketing, and field people.
performance predictor was outgrowth of work at the science center on
performance management, workload profiling, the early technology
transition from performance management to capacity polanning:
http://www.garlic.com/~lynn/subtopic.html#bench
that allowed sales people to input customer configuration and
operational information (often softcopy extracted from the system
itself) and be able to do what-if questions about changes to
configuration and workload.
as hardware got more and more complex ... configurators were the
applications that allowed a sales person to specify rough product
specification ... and the application would make sure that enuf
correct information was supplied for ordering the equipment.
now, this particular analysis ... i presented at the SNA architecture
review board meeting in raleigh and took lots of arrows on.
the reference about keeping timing sync ... is somewhat related when
the telcos stopped letting customers have clear-channel T1 links and
required them to conform to the ones-density (and 193rd bit)
specification.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360 longevity, was RISCs too close to hardware?
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 12 Feb 2005 11:38:35 -0700
Charles Shannon Hendrix writes:
That was the original drive for things like Beowulf. NASA centers
were losing supercomputers, still needed them, and they could get
the budget for a stack of x86 machines.
Another side effect of this is that businesses or individual offices
that would never have considered a supercomputer in the past, are
starting to build various kinds of commodity cluster systems.
predates/precursor to beowulf:
http://www.garlic.com/~lynn/95.html#13
i had a running argument at acm sigops (91, the one where they
had the evening event at the monterey aquarium) with somebody (who
was at dec at the time and involved with dec cluster) about ha/cmp
being able to do scaleable computing with commodity cluster systems.
random ha/cmp stuff
http://www.garlic.com/~lynn/subtopic.html#hacmp
in an earlier life, my wife had gotten con'ed into doing a stint in
pok in charge of loosely-coupled architecture (aka mainframe for
clusters). she had done peer-coupled shared data architecture
http://www.garlic.com/~lynn/subtopic.html#shareddata
but in that period almost all the attention was on bigger and faster
iron (uniprocessors and SMPs) ... and not a lot given to clustering.
i was involved in supporting and driving hone complex ... both from
the standpoint of writing smp kernel support as well as cluster
support. circa '79, '80 , hone had possibly deployed the largest
single-system image cluster around
http://www.garlic.com/~lynn/subtopic.html#hone
a couple recent posts on scalable dlm:
http://www.garlic.com/~lynn/2005.html#40 clusters vs shared-memory
http://www.garlic.com/~lynn/2005b.html#1 Foreign key in Oracle Sql
note that GRID is somewhat the evolution of clusters ... and moving into
the commercial space ... some of it can be viewed as time-sharing
appplied to clustering .... misc. old time-sharing postings
http://www.garlic.com/~lynn/subtopic.html#timeshare
for total topic drift ... in the following list, there is a talk I
gave at last summer's global grid forum:
http://forge.ggf.org/sf/docman/do/listDocuments/projects.ogsa-wg/docman.root.meeting_materials_and_minutes.ggf_meetings.ggf11
and select: GGF11-design-security-nakedkey
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: lynn@garlic.com
Date: 13 Feb 2005 09:25:01 -0800
Subject: Re: IBM Acronyms
Newsgroups: alt.folklore.computers
Andy Canfield wrote:
1 Big Mutha'
(from the 1960's)
a couple definitions from Mike's glossary that leaked onto the
internet:
http://www.212.net/business/jargonb.htm
[BiCapitalization]
n. The PracTice of PutTing CapiTal LetTers in the MidDle of WorDs. This
was originally used to refer to microcomputer software trademarks such
as VisiCalc, EasyWriter, and FileCommand but has since spread even to
products totally unrelated to computing, and to many more than two
capitals. The mainframe world, however, is still mostly devoid of
BiCapitalization - in that environment the use of abbreviations is
still the PMRR (Preferred Method of Reducing Readability).
[BICARSA GLAPPR]
bi-carsa glappern. The cornerstone applications of commercial
computing. An abbreviation for Billing, Inventory Control, Accounts
Receivable, Sales Analysis, General Ledger, Accounts Payable, PayRoll;
the applications for which IBM's mainframes were built and on which its
fame and fortune were founded. Usage: Yeah, it's fast, but how does it
do on BICARSA GLAPPR?
[Big Blue]
n. IBM (when used by customers and competitors). n. The Data Processing
Division (when used by people concerned with processors that do not use
the System/370 architecture). The> DPD no longer exists, but the phrase
big blue boxes is still used to refer to large System/370
installations.
[Big Blue Zoo]
n. The manufacturing plant and laboratory complex located at the
junction of Highway 52 and 37th Street, Rochester, Minnesota, USA. It
really is blue. zoo
[Big Four]
n. The original four largest TOOLS (q.v.) disks. These are the IBMPC
and IBMVM conference disks, and their corresponding tool (program)
collections, PCTOOLS and VMTOOLS.
[big iron] n. Large computers. Also big iron bigot. iron
[Big OS]
big ozzn. Operating System/360. This term was popular in the late '60s
when OS was the operating system, and it was believed to do and know
everything.
Refed: **, - **, - **
From: lynn@garlic.com
Newsgroups: comp.arch, alt.folklore.computers
Date: 13 Feb 2005 10:01:41 -0800
Subject: Re: Self restarting property of RTOS-How it works?
Bernd Paysan wrote:
Hm, I could make some assumptions about the statistical properties of those
"100 packets per minute", but simple assumptions can be quite wrong. If I
have a web server, and I get 100 requests per minute, I expect the traffic
to be shaped over the day, and that the likelyhood to receive a single
packet between 3 and 5am of my target audience is quite low, while there'll
be several high-activity spots during the day. That means a simply random
distribution of the packets is not sufficient to give you the worst case.
At least on my most popular German page, the access frequency drops down to
one tenth of the typical day use between 2 and 6am. The traffic during the
day is pretty flat, though, about one hit per minute. During late night,
there are only about five per hour.
glossaries/taxonomies at
http://www.garlic.com/~lynn/
account for about 1/3rd of total hits ... with pretty good sample
around the world at any time of day
various search engines account for possibly 15 percent of total hits
(sometimes getting every page every night) ... which aren't driven by
people characteristics (i sometimes wonder if the site is being used
for testing, possibly because of the extremely high ratio of hrefs to
text).
in the 60s & 70s, local time-sharing systems use tended to have very
strong time-of-day correlation ... a morning peak around 10am and an
afternoon peak around 3pm. There could be as much as a 10:1 difference
between peak period avg. use and overall 1st shift avg. use. as some
of these time-sharing systems offerred national service, they started
to see rolling peaks from the different time-zones (this pattern was
somewhat repeated later in things like ATM cash machines).
one of the interesting problems with offering 7x24 time-sharing
service in the 60s was the leased/rental cost of the machines ... with
vendor charing the datacenter by the processor meters. 3rd & 4th shift
might be 5percent of the system ... and couldn't cover the costs of
the machine or even an onsite operator.
http://www.garlic.com/~lynn/subtopic.html#timeshare
so some things done on cp/67 enabling 3rd & 4th shift service:
1) automating some of the simpler common operator functions ...
including automatically rebooting the system after failures (helping
eliminate requirement for onsite operator 3rd & 4th shift)
2) the meter would run whenever the cpu was running and/or whenever
there was active I/O. the system had used a i/o sequence that waited
for terminal &/or network input ... which ran the meter. however, a
ccw sequence was discovered that could wait for character input w/o
having the meter run (when character's weren't actually arriving).
From: lynn@garlic.com
Newsgroups: comp.arch
Date: 13 Feb 2005 14:02:50 -0800
Subject: Re: 360 longevity, was RISCs too close to hardware?
Charles Shannon Hendrix wrote:
That was the original drive for things like Beowulf. NASA centers were
losing supercomputers, still needed them, and they could get the budget
for a stack of x86 machines.
Another side effect of this is that businesses or individual offices
that would never have considered a supercomputer in the past, are
starting to build various kinds of commodity cluster systems.
in conversations with a couple labs ... there were also situations
where the people supporting the large machines with propriatary
operating systems were retiring and the labs weren't finding people to
backfill the slots ... the only thing that was coming out of the
universities were people that were trained on systems running on
commodity processors.
one lab. supposedly retired a machine on the same day their last
person, responsible for supporting the machine, retired
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Newsgroups: sci.crypt, alt.folklore.computers
Date: 14 Feb 2005 18:32:47 -0800
Subject: Re: [Lit.] Buffer overruns
Morten Reistad wrote:
Or, just having 200 seats for breakfast at that same hotel, because
you know half your guests go directly to meetings, and the rest is
nicely spread out during the morning.
A failure in capacity will manifest itself as a little queing, then
a little more queing; and then you had better rent the resturant
next door. But if the resturant is 1/3 full all morning you know you
don't have a problem.
lots of banks have gone to single queue for multiple servers (bank
tellers) ... frequently there are more tellers than concurrent long
running requests ... so the quicky requests frequently get to be
processed and bypass a couple tellers taking long time on long
requests. supermarkets have multiple queues ... but tend to have
assigned special servers dedicated to few items.
i had redone page replacement, dispatching and scheduling for cp67
while and undergraduate (and it was shipped in the product). a lot of
it was dropped in the morph from cp67 to vm370 ... but i got to
reintroduce it all with the resource manager. but this time they
decided to use the resource manager as guinea pig for chargeable
kernel software (starting with unbundling they were charging for some
application software, but kernel software was still free, i got to
spend way too much time with business people on software charging
policy).
by carefully optimizing a bunch of stuff thruout the kernel ... i
could effecientily do various kinds of pre-emptive dispatching
... small light weight requests getting very timely service by
pre-emption of heavy weight stuff. in much of that period ... many
systems had lot of guidelines of online/interactive systems running at
20-30percent utilization in order to be able to provide reasonable
interactive response. I did a lot of optimization thruout the kernel
infrastructure allowing various components to operate at 100 percent
utilization and still provide superior interactive response.
the science center had pioneered a lot of performance optimization and
management technology.
http://www.garlic.com/~lynn/subtopic.html#545tech
Not uncommon at the time was instruction address sampling ... to
identify high useage areas as targets of optimization .... past
posting on investigation of kernel components for moving into hardware
microcode
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
another was use of APL for extensive performane modeling
... technology was used extensively in calibrating the resource
manager for product release (performance profiling, configuration
characterization, workload profiling, and a lot of the early
transition to capacity planning):
http://www.garlic.com/~lynn/subtopic.html#bench
but it also evolved into the *performance predictor* which was made
available on the internal HONE system(s)
http://www.garlic.com/~lynn/subtopic.html#hone
which provided support for worldwide marketing, sales, and field
support people. Marketing people could gather softcopy information from
customers operations about configuration, workload, performance and use
the performance predictor to answer what-if questions about what
happens when changing hardware, workload, etc.
Another technology used in performance management (that complimented
the instruction address sampling) was multiple regression analysis.
One of the original applications on cp67 was a program that
snapshot system and task performance, workload, and thruput
information information every 5-15 minutes ... and had nearly a decade
of information (by the time of the resource manager) across cp67 and
vm370. Also had possibly year of more data on possibly a couple
hundred internal machines for processing also. There was a lot of
processing looking at this at specific points in time using multiple
regression analysis.
slightly related thread from comp.arch
http://www.garlic.com/~lynn/2005d.html#1 Self restarting property of RTOS
http://www.garlic.com/~lynn/2005d.html#4 Self restarting property of RTOS
partially because of the strong background scheduling and resource
management algorithms ... when we were doing the high-speed data
transport project
http://www.garlic.com/~lynn/subnetwork.html#hsdt
i did rate-based pacing at various levels in the network stack. As
referenced here ...
http://www.garlic.com/~lynn/internet.htm#0
we weren't allowed to bid NSFNET ... but did get a audit from NSF of
the high speed backbone we were operating ... and some statement to
the effect that what we were operating was at least five years ahead
of all (NSFNET) bid submissions (to build something new).
we got to have a lot of fun(?) with high-speed crypto (for the time)
because all transmissions leaving facilities had to be encrypted.
From: lynn@garlic.com
Newsgroups: comp.arch
Date: 15 Feb 2005 09:43:08 -0800
Subject: Re: Self restarting property of RTOS-How it works?
Charles Krug wrote:
When we were younger, we stayed in a hotel in San Juan where the
elevators went to floors in the order the buttons were pressed,
without regard for proximity.
Not sure who came up with that brilliant idea.
You might imagine that a clever 10yo boy made certain that the
elevator's path was the most convoluted possible. My sisters
weren't much better.
they obviously never heard of the elevator disk arm scheduling
algorithm
From: lynn@garlic.com
Newsgroups: comp.arch, alt.folklore.computers
Date: 16 Feb 2005 10:21:25 -0800
Subject: Re: intel's Vanderpool and virtualization in general (was Re: Cell press release, redacted.)
Sander Vesik wrote:
To be brutaly honest, they simply had way incomptently run windows
shop in that case (esp the "running around and rebooting" part) and
probably hired people they shouldn't have. Taking people who are good
at running OS Y and having them run OS Q dependably gives such a
result and tells you little about the quality of the OS-s in question
for the mainframe batch systems, there is a small matter that for 40
years (or more) that have evolved a "batch" paradigm where the
responsible party for executing the program isn't present when the
progeram is executing. as a result they have a long-standing default
design point where the system needs to be doing things automagically
on behalf of people that aren't present.
this continued with the batch-based "online" paradigm ... the
responsible people for the deployed online application aren't present
... even tho the online application is providing various kinds of
services for other individuals. the batch-based "online" paradigm has
quite a large number of simularities with the client/server web
paradigm .... where the server side of the web paradigm is providing
various kinds of online services for the client side users.
in contrast ... most of the recognized "easy to use" interactive
systems have long standing design point that the person responsible
for running the application is actually physically present when the
application is run (aka rather than having extensive setup so the
system can automagically handle various conditions ... it defaults to
throwing it to the person that is presumed to be present, invoking the
application).
many of the batch oriented systems have spent more than 40 years
evolving their automagically handling methodologies.
Refed: **, - **, - **
From: lynn@garlic.com
Newsgroups: comp.arch, alt.folklore.computers
Date: 16 Feb 2005 21:29:42 -0800
Subject: Re: intel's Vanderpool and virtualization in general (was Re: Cell press release, redacted.)
Alex Colvin wrote:
Although there was also a long-held assumption in some mainframe systems
that an operator was present. Hence the semi-manual I/O transports for
cards, tape, printers. And the lack of time-of-day clocks.
so in the 90s we were talking to a large financial transaction
operation and they claimed that the two factors that enabled them to
have 100 percent availability for the previous six years were
- automated operator
- ims hot standby
i had done a lot with automated operator in various scenarios starting
in the late 60s ... for 7x24 operation (allowing time-sharing service
around the clock w/o requiring onsite person during "slack" hours) ...
recent posting
http://www.garlic.com/~lynn/2005d.html#4 Self restarting property of RTOS-How it works?
collected postings on the subject of time-sharing from the period:
http://www.garlic.com/~lynn/subtopic.html#timeshare
and then did a lot more in the 70s ... at the time with automating
benchmarks perparing the research manager ... leading up to release of
the research manager there was over 2000 benchmarks that took 3 months
elapsed time (which included a system reboot between each benchmark).
... some collected postings on the benchmarking (and other subjects):
http://www.garlic.com/~lynn/subtopic.html#bench
as to ims hot-standby ... my wife had been con'ed into serving time in
POK in charge of loosely-coupled architecture ... and while there
originated peer-coupled shared data
http://www.garlic.com/~lynn/subtopic.html#shareddata
ims group was one of the few organziations paying attention since most
of the corporation was focused on ever bigger uniprocessors and SMPs
(as opposed to cluster solutions and protocol).
we pulled some of that together for ha/cmp .. a specific ha/cmp
reference
http://www.garlic.com/~lynn/95.html#13
some collected ha/cmp, clustering, and loosely-coupled postings
http://www.garlic.com/~lynn/subtopic.html#hacmp
Refed: **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: 16 Feb 2005 21:15:57 -0800
Subject: Re: Cerf and Kahn receive Turing award
glen herrmannsfeldt wrote:
Even without logging in, it says "creating the underpinnings of
the Internet", I believe that is TCP/IP.
Al Gore helped supply the funding for "the Internet as we know
it", that is, for use by more than academics.
Both are important.
the underpinnings of arpanet was a homogeneous packet based network
with host protocol. my frequent assertion that the internal network
was larger than the arpanet/internet from just about the beginning
until sometime mid-85 because the internal network nodes effectively
had a form of gateway ... which the "internet" didn't get until the
great cut-over on 1/1/83. misc. past internal network posts
http://www.garlic.com/~lynn/subnetwork.html#internalnet
a lot of the internet as we know it was the commercialization that
happened ... which you started to see at least by the time of interop
'88
http://www.garlic.com/~lynn/subnetwork.html#interop88
where you saw a lot of vendors selling tcp/ip commercial products to
commercial customers.
NSFNET1 and NSFNET2 were high-speed backbone RFPs for T1 (and then
T3) interconnect for a select set of educational &/or gov. nodes. pure
aside ... we weren't allowed to bid on NSFNET1/NSFNET2 ... although we
got a technical audit by NSF of the high speed backbone
http://www.garlic.com/~lynn/subnetwork.html#hsdt
we were operating ... which made some reference to what we were
operating was at least five years ahead of all NSFNET bid submissions
to build something new. minor past references:
http://www.garlic.com/~lynn/internet.htm
misc. other archeological references:
http://www.garlic.com/~lynn/rfcietf.htm#history
some past past post/threads on the subject:
http://www.garlic.com/~lynn/2000d.html#43 Al Gore: Inventing the Internet...
http://www.garlic.com/~lynn/2000d.html#56 Is Al Gore The Father of the Internet?
http://www.garlic.com/~lynn/2000d.html#58 Is Al Gore The Father of the Internet?
http://www.garlic.com/~lynn/2000d.html#59 Is Al Gore The Father of the Internet?
http://www.garlic.com/~lynn/2000d.html#63 Is Al Gore The Father of the Internet?
http://www.garlic.com/~lynn/2000d.html#67 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000d.html#70 When the Internet went private
http://www.garlic.com/~lynn/2000d.html#76 When the Internet went private
http://www.garlic.com/~lynn/2000d.html#77 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000e.html#5 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000e.html#10 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000e.html#11 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000e.html#13 internet preceeds Gore in office.
http://www.garlic.com/~lynn/2000e.html#14 internet preceeds Gore in office.
http://www.garlic.com/~lynn/2000e.html#15 internet preceeds Gore in office.
http://www.garlic.com/~lynn/2000e.html#18 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000e.html#19 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000e.html#20 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000e.html#26 Al Gore, The Father of the Internet (hah!)
http://www.garlic.com/~lynn/2000e.html#28 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000e.html#31 Cerf et.al. didn't agree with Gore's claim of initiative.
http://www.garlic.com/~lynn/2000e.html#38 I'll Be! Al Gore DID Invent the Internet After All ! NOT
http://www.garlic.com/~lynn/2000e.html#39 I'll Be! Al Gore DID Invent the Internet After All ! NOT
http://www.garlic.com/~lynn/2000f.html#44 Al Gore and the Internet (Part 2 of 2)
http://www.garlic.com/~lynn/2000f.html#45 Al Gore and the Internet (Part 2 of 2)
http://www.garlic.com/~lynn/2000f.html#46 Al Gore and the Internet (Part 2 of 2)
http://www.garlic.com/~lynn/2000f.html#47 Al Gore and the Internet (Part 2 of 2)
http://www.garlic.com/~lynn/2000f.html#49 Al Gore and the Internet (Part 2 of 2)
http://www.garlic.com/~lynn/2000f.html#50 Al Gore and the Internet (Part 2 of 2)
http://www.garlic.com/~lynn/2000f.html#51 Al Gore and the Internet (Part 2 of 2)
http://www.garlic.com/~lynn/2002b.html#40 Poor Man's clustering idea
http://www.garlic.com/~lynn/2002g.html#73 Coulda, Woulda, Shoudda moments?
http://www.garlic.com/~lynn/2002g.html#74 Coulda, Woulda, Shoudda moments?
http://www.garlic.com/~lynn/2002h.html#79 Al Gore and the Internet
http://www.garlic.com/~lynn/2002h.html#80 Al Gore and the Internet
http://www.garlic.com/~lynn/2002h.html#81 Al Gore and the Internet
http://www.garlic.com/~lynn/2002h.html#82 Al Gore and the Internet
http://www.garlic.com/~lynn/2002h.html#85 Al Gore and the Internet
http://www.garlic.com/~lynn/2002h.html#86 Al Gore and the Internet
http://www.garlic.com/~lynn/2002i.html#15 Al Gore and the Internet
http://www.garlic.com/~lynn/2002i.html#28 trains was: Al Gore and the Internet
http://www.garlic.com/~lynn/2002i.html#35 pop density was: trains was: Al Gore and the Internet
http://www.garlic.com/~lynn/2002i.html#36 pop density was: trains was: Al Gore and the Internet
http://www.garlic.com/~lynn/2002l.html#48 10 choices that were critical to the Net's success
http://www.garlic.com/~lynn/2002l.html#70 Al Gore and Fidonet [was: 10 choices]
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: 17 Feb 2005 09:50:45 -0800
Subject: Re: Cerf and Kahn receive Turing award
Morten Reistad wrote:
Until around 1990 the construction of routers was an arcane art.
Cisco, Proteon and Wellfleet were building boxes on top of weird bus
constructions, crufty software, and standard cpu-memory constructions.
The first router to "break out" from the cruft was the Cisco 7000.
Did we miss anything significant from IBM in that timeframe? I know
that was the time of an intense Token Ring love-in at IBM.
my wife has her name on an (international/pto) token passing (lan)
patent from the 70s.
when almaden was built in the mid-80s, it was provisioned w/cat5 ...
but when they actually connected it up ... they found that
twisted-pair enet hardware had lower latency and higher thruput than
16mbit t/r.
we found something similar ... and took a lot of heat from the
saa/token-ring crowd when we pitched it (along with the original
3-layer architecture & middle laywer) in customer executive
presentations.
http://www.garlic.com/~lynn/subnetwork.html#3tier
ibm mainframe tcp/ip stack was done in vs/pascal ... it had some
thruput issues ... on 3090, it could use a whole 3090 processor
getting 44kbytes/sec. I added rfc1044 support to the stack ... and in
tests at cray research between a 4341-clone and a cray ... was getting
1mbyte/sec using only a modest amount of the processor
http://www.garlic.com/~lynn/subnetwork.html#1044
however, outside of technology ... while the NSFNET1 RFP provided the
venue for the backbone ... the folklore is that the actual
provisioning by commercial companies was something like 4-5 times that
of what the gov. funded. the conjecture was that (at least for the
telcos) there was a substantial amount of dark-fiber and they had
never figured out a transition program. telcos have certain fixed
run-rate ... if they dropped the price of all bit transmission (say by
a factor of ten times) as a strategy to promote new applications
... they could never cover their fixed run-rate during the multi-year
transition period. the donation of enormous excess resources for the
backbone could help promote the evolution of new bandwith use
paradigms ... w/o directly impacting their existing revenue.
at supercomputer in austin ('90?, '91?) there were some lessor known
router vendors supporting full long-haul T3 ... with more modern
router architectures. There was some conjecture that the more
mainstream router vendors weren't very motivated in developing new
architectures and technologies ... because they were already selling
everything they made. This continued well thru the 90s with things
like support for really robust packet filtering capability (various of
the lessor known vendors had substantially more robust implementations
than the market leaders).
somewhat side-track was that in the late 80s and early 90s ... many of
the world govs. were mandating the elimination of the internet and
transition to OSI (including US gov. with GOSIP). interop 88
http://www.garlic.com/~lynn/subnetwork.html#interop88
there were substantial amount of OSI products from commercial vendors
(attempting to conform with the gov. mandates).
my 'oft repeated story was that ISO compounded the problem by
mandating that ISO and ISO-chartered standards organization could work
on networking standards that violated the OSI model. HSP in ansi
x3s3.3 was going directly from transport/layer4 to LAN/MAC interface.
http://www.garlic.com/~lynn/subnetwork.html#xtphsp
this was rejected because it violated OSI model:
- going direct from transport to LAN/MAC bypassed the level3/level4
interface, violating OSI model
- HSP would support internetworking (aka IP). IP doesn't exist in
the OSI model, so supporting IP violates the OSI model
- HSP would support LAN/MAC interface, the LAN/MAC interface sits
somewhere in the middle of networking/level3. LAN/MACs violate OSI
model, so supporting LAN/MACs also violates OSI.
From: lynn@garlic.com
Newsgroups: sci.crypt, alt.folklore.computers
Date: 17 Feb 2005 20:26:44 -0800
Subject: Re: Thou shalt have no other gods before the ANSI C standard
Don Chiasson wrote:
And then when you consider the number of beers consumed
at a DECUS....
SHARE had evening SCIDS (Society for Continuous Inebriation During
Share) and into the 70s ... it was still open bar (if your badge got
you into the ballroom, you poured whatever and as much as you wanted).
this definition has since fallen into disfavor.
the folklore was that IBM didn't allow expense re-imbursement for
alcohol ... so the user group meeting bundled the cost of drinks into
the overall registration.
once I was scheduled for one hr presentation at european share on
performance management ... which was actually a full day presentation.
i gave the one hr ... and then was scheduled for birds-of-feather
during scids (in a room just off the ballroom) ... starting at 6pm and
continued until past midnight ... but well lubricated with side trips
to the ballroom.
misc. past postings mentioning scids
http://www.garlic.com/~lynn/2000d.html#5 Definition of SHARE & SCIDS Requested
http://www.garlic.com/~lynn/2000d.html#6 Definition of SHARE & SCIDS Requested
http://www.garlic.com/~lynn/2001k.html#20 OT: almost lost LBJ tapes; Dictabelt
http://www.garlic.com/~lynn/2001l.html#12 mainframe question
http://www.garlic.com/~lynn/2002k.html#20 Vnet : Unbelievable
http://www.garlic.com/~lynn/2002k.html#60 IBM-Main Table at Share
http://www.garlic.com/~lynn/2002o.html#31 Over-the-shoulder effect
http://www.garlic.com/~lynn/2002q.html#11 computers and alcohol
http://www.garlic.com/~lynn/2002q.html#23 Free Desktop Cyber emulation on PC before Christmas
http://www.garlic.com/~lynn/2002q.html#31 Collating on the S/360-2540 card reader?
http://www.garlic.com/~lynn/2003k.html#62 The Incredible Shrinking Legacy Workforces
http://www.garlic.com/~lynn/2004d.html#10 IBM 360 memory
http://www.garlic.com/~lynn/2005b.html#44 The mid-seventies SHARE survey
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: 18 Feb 2005 09:10:14 -0800
Subject: Re: Cerf and Kahn receive Turing award
for the NSFNET2 RFP ... there was a red team and a blue team formed
for a bid response. The red team was my wife and I, the blue team was
20 people from seven labs around the world. For the final review, the
red team presented first and then the blue team. Ten minutes into the
blue team presentation, it was evident to everybody in the room, that
the red team solution was vastly superior. At this point, the person
running the review, pounded on the table and exclaimed that he would
lay down in front of a garbage truck before he let any but the blue
team solution go forward.
an email from the NSFNET1 period ... names have been changed to
protect the guilty. note that the referenced meeting was called off
before it could be held.
......
From: wheeler
Date: 05/01/86 17:35:04
fyi, re: meeting today with cornell on nsf/super computer system
They went great!!!
Ken King is going to call the key people at the following
universities:
MIT, Stanford, Berkeley, Michigan, Minnesota, Illinois U of Texas,
Columbia, Deleware, Maryland, TUCC, Princeton, Penn State, Wisconsin,
UCLA
and
NCAR, FERMI, and VLA
for a two day meeting in Yorktown in June. After he makes the calls a
formal memo (also inviting Erich Bloch) will be sent to these people.
The purpose is to set the stage for the writing of the NSF proposal
Some of these universities will participate as BITS recipients, some
as DNS hosts, and some as hubs for both.
... snip ... top of post, old email index
From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: 18 Feb 2005 08:57:04 -0800
Subject: data integrity and logs
in the privacy & law track yesterday at RSA conference there was a lot
of talk about logs being needed to guarantee data integrity, problems
of merging logs from distributed systems (in correct time sequence),
etc.
it brought to mind an explanation made at an ACM SIGMOD conference in
the early 90s about what was all this ISO x.50x stuff; the description
was that all this x.50x stuff was a bunch of networking engineers
attempting to re-invent 1960s data base technology.
From: lynn@garlic.com
Newsgroups: sci.crypt, alt.folklore.computers
Date: 18 Feb 2005 12:29:56 -0800
Subject: Re: Thou shalt have no other gods before the ANSI C standard
Douglas A. Gwyn wrote:
They're not very relevant to sci.crypt either, except that
this thread really started in sci.crypt with somebody
asserting that buffer overruns were inherent in using C.
I don't know who first added a.f.c to the discussion, nor why.
Surely by now you must know how to skip postings that don't
interest you? Or did I miss something and you're the a.f.c
moderator?
i'm guilty on most counts.
my assertion was that there were a number of environments (over the
years) which had target buffers that included length semantics and
that copy operations in these environments leveraged such length
semantics to avoid a many of the buffer overflow vulnerabilities
common to C programs (many as a direct result of the common practice
of not having infrastructure length semantics associated with target
buffers).
furthermore, in subsequent subthread regarding automatic bounds
checking ... i commented that automatic bounds checking is dependent
on infrastructure start/end (and/or start/length) constructs ... w/o
which it is not possible for automatic bounds check to have a basis on
which to determine the bounds to be checked.
... and as a minor corollary ... for infrastructures that had
start/end (and/or start/length) constructures for storage areas
... that such constructs could be leveraged by standard library copy
operations (in addition to any use by automatic bound checking
facilities).
my original x-posting with sci.crypt & alt.folklore.computers:
http://www.garlic.com/~lynn/2005b.html#16 [Lit.] Buffer overruns
somebody else had previously x-posting to comp.security.unix:
http://www.garlic.com/~lynn/2005b.html#6 [Lit.] Buffer overruns
my earlier participation in the thread:
http://www.garlic.com/~lynn/2004q.html#2 [Lit.] Buffer overruns
also note that there was an a.f.c thread from last fall (that also had
quite a bit of drift)
http://www.garlic.com/~lynn/2004p.html#3 History of C
From: lynn@garlic.com
Newsgroups: sci.crypt, alt.folklore.computers
Date: 19 Feb 2005 08:36:13 -0800
Subject: Re: Thou shalt have no other gods before the ANSI C standard
jmfbahciv writes:
Did you expect that the post would produce such wonderful
fruits?
sometimes people with a range of programming experience that weren't
necessarily limited to C ... might offer wider perspective on pros &
cons of particular C features ... based on comparison to broad range
of features from variety of backgrounds; also, when this started there
had recently been a thread on the history of C in a.f.c.
one analogy is some recent claims that better understanding of current
conditions on titan may contribute to better understanding of how
earth came to be the way it is.
From: lynn@garlic.com
Newsgroups: sci.crypt
Date: 19 Feb 2005 09:30:30 -0800
Subject: Re: Digital signature with Javascript
devnull wrote:
Sorry for not making myself clear: I can't use any server side scripts
(and don't really need it for my purpose), I just want to make sure
the user is who he claims to be. Computation time is not really a
problem. Any suggestions?
fundamentally, you are dealing with 3-factor authentication
http://www.garlic.com/~lynn/subintegrity.html#3factor
- something you have
- something you know
- something you are
along with the level of security that you might imploy with various
techniques.
a relying party verifying a digital signature with a public key will
reduce to some form of 3-factor authentication ... possibly
- private key for performing digital signature is kept in an encrypted
file ... when relying party verifies a digital signature ... the
relying party assumes that it originated from somebody that knew the
secret key to decrypt the encrypted file containing the private key.
therefor it single-factor, something you know authentication. strength
of security and vulnerabilities are related to attacks on the private
key encrypted file (kept by the originator, key owner). it may be
considered a step up from shared-secret, something you know
authentication. In the shared-secret scenario, both the originator and
the relying party have knowledge of the shared-secret (pin, password,
etc); and therefor security paradigms require a unique shared-secret
for every, unique security domain (otherwise a relying party in one
security domain might impersonate the originator to a different
security domain). misc. past postings on secrets and shared-secrets:
http://www.garlic.com/~lynn/subintegrity.html#secrets
- private key for performing the digital signature is kept in a
hardware token and is never divulged to anybody (even the key owner).
when relying party verifies a digital signature ... the relying party
assumes that it originated from somebody that is in possession of the
hardware token (something you have authentication). if the relying
party has proof of the integrity characteristics of the hardware token
and possibly also has proof that the particular hardware token also
requires a correct PIN for operation ... then the relying party might
have higher level of trust in such digital signatures .... being able
to assume two-factor authentication ... both something you have, aka
the actual hardware token and something you know ... the hardware
token's PIN. Note that this level/kind of trust and integrity is
totally orthogonal to anything having to do with the cryptograpy.
- the private key hardware token scenario but instead of (or in
addition to) the hardware token requiring a PIN ... the token requires
correct biometric for operation. when the relying party verifies a
digital signature with a public key, then the relying party might
assume two (or three) factor authentication: something you have and
something you are (and possibly also something you know).
aka ... the digital signature isn't part of 3-factor authentication ...
however, given that the relying party has the appropriate assurances
about how the digital signature originated ... the relying party can
infer from the digital signature something about some characteristic
from 3-factor authentication.
this aspect of digital signature authentication (with regard to how
much trust that a relying party can place in the verification of a
particular digital signature) is totally independent of any
cryptography characteristic of the digital signiture ... this trust
characteristic is purely related to
• the integrity characteristics of keeping the private key really
private ... and
• the integrity characteristics of the environment that
executes/generates the digital signature.
It also is totally unrelated to infrastructure characteristic of
things like digital certificates ... and is applicable, whether a
digital signature authentication infrastructure is certificate-based
or the infrastructure is totally free of certificates ... some past
post related to certificate-less infrastructure operation
http://www.garlic.com/~lynn/subpubkey.html#certless
From: lynn@garlic.com
Newsgroups: sci.crypt
Date: 19 Feb 2005 09:50:11 -0800
Subject: Re: Digital signature with Javascript
devnull wrote:
I want to write a script that allows to verify the identity of the
users. My idea is to take the username and some other data, sign this
and give that signature to the user as password. This signature is
then checked by my script and the username given on login and the one
retrieved from the signature match, the identity has been confirmed
and the script continues. This does not need to be extremely secure,
since with client-side javascript anybody with some knowlege can
circumvent the protection anyway.
Do you know of any existing scripts that I could use or adapt?
Alternatively, could you point me to a site where I can find infos on
using the RSA algorithm for digital signatures (I have a script to use
it for encryption, but couldn't figure out how to use it for signing
webservers tend to have stub code for implementing specific client
authentication. frequently this has been used to implement some form of
(possibly flat file) userid/password ... where the userid/password is
entered possibly over a secure SSL channel.
other implementations have stub code invoking radius code (radius code
is also standard for ISPs doing initial customer connection
authentication) for authentication. default radius authentication has
been userid/password based (dating back to when it originating for
livingston modem pools ... dare i admit to configuring livingston
boxes?). some number of radius implementations have other
authentication mechanisms ... including registering a public key in
lieu a password (in radius file) for doing userid/digital-signature
verification. misc. past posts of public key enhancements for radius:
http://www.garlic.com/~lynn/subtopic.html#radius
another scenario is interfacing the webserver stubcode to kerberos and
implementing kerberos PKINIT with "naked" public keys (actually public
keys registered in lieu of passwords with kereberso). misc past
kerberos pkinit posts:
http://www.garlic.com/~lynn/subtopic.html#kerberos
From: lynn@garlic.com
Newsgroups: sci.crypt
Date: 19 Feb 2005 15:56:53 -0800
Subject: Re: Digital signature with Javascript
re:
http://www.garlic.com/~lynn/2005d.html#17 Digital signature and Javascript
http://www.garlic.com/~lynn/2005d.html#18 Digital signature and Javascript
aka ... the verification of the digital signature doesn't directly
demonstrate any of the components of the 3-factor authentication.
the construction of the infrastruction uses some combination of
3-factor authentication to enable the generation of the digital
signature (using a private key). when the relying party verifies the
digital signature ... then given the relying party has some
certification as to the process that enables use of the private key
for producing the digital signature ... then a valid digital signature
implies that the certified process (for accessing/enabling the private
key) occured.
in general, the integrity of the public/private key technology should
be proportional to the integrity of the process that controls
access/use of the private key.
some variation of 3-factor authentication is used to control access
and use of the private key (for digital signature generation). the
relying party then depends on the validation of a digital signature to
imply that some combination of 3-factor authentication was used to
access the private key (in order to generate the digital signature).
the level and integrity of some combination of 3-factor authentication
(used to access and use the private key) is what the relying party is
dependent on (the level and integrity of the cryptography used in the
public/private key technology is secondary to the level and integrity
involved in controlling access and use of the private key).
the level of trust that is implied by verification of a digital
signature is dependent on the relying party being guarenteed as to the
level and integrity of the process that protects access and use of the
associated private key.
w/o the relying party having direct guarentee as to the process used
to control access and use of a private key ... then a relying party
has no basis for determining what is implied by the verification of a
digital signature (i.e. whether or not any component of 3-factor
authentication is involved at all in the access and/or use of the
associated private key).
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: Re: shared memory programming on distributed memory model?
Newsgroups: comp.arch
Date: 20 Feb 2005 09:16:36 -0800
del cecchi wrote:
If you want to avoid the evils of message passing, then ccNUMA is for
you. A number of companies manufacture them. The earliest papers I
recall reading were DASH from Stanford. See also SCI, IEEE1596
standard. SGI origin systems are ccNUMA, as are some X series from IBM,
Superdome from HPQ. I believe DASH was followed by FLASH, also at
Stanford. I'm sure the manufacturers have white papers or other stuff
about their NUMA systems.
A little google and some luck should get you going.
three SCI were convex exemplar (hp processors), sequent (intel
processors), and DG (intel processors). HP bought convex. IBM bought
Sequent, and DG (?, their disk arrays sold off and somebody bought
their brand new campus complex)
at least convex and sequent did a fair amount on partitioning and
locality ... sort of an intermediate stage akin to cache locality and
cache miss rates. convex heavily modified MACH; sequent modified their
dynix system.
SCI was oriented towards taking synchronous bus protocols and converting
them to dual-simplex asynchronous (hardware) message(?) protocol.
Standard SCI memory "bus" has 64-ports; convex put dual HP processor
boards at each "port" (128 processors). Sequent and DG put quad Intel
processor boards at each "port" (256 processors).
SCI has been applied to stuff other than memory bus.
i found it interesting in late '80s & early 90s period .... LANL was
driving COTS factor for cray channel in standards meetings (HiPPI),
LLNL was pushing COTS for what became fiber-channel standard, and SLAC
was the driving force behind COTS for SCI.
From: lynn@garlic.com
Subject: Re: Digital signature with Javascript
Newsgroups: sci.crypt
Date: 20 Feb 2005 09:31:49 -0800
minor postscript observation ... digital certificates and the
certification of the process used to access and use private key are
totally unrelated. the certification of the process used to access and
use private key provides the relying party with some assurance that the
verification of a digital signature is in any way related what-so-ever
to any 3-factor authentication characteristics.
digital certificates were invented to address the scenario where the
relying party has no prior relationship with the key-owner and has to
recourse to any sort of near-time access to any information about the
key-owner. even before the 70s, business relying parties did possibly
90percent of their business based on established business relationship
(making digital certificates redundant and superfluous). with the
modern, online world ... possibly 99 percent of the remaining 10
percent ... a relying party has recourse to near-time information about
the key-owner (further making digital certificates redundant and
superfluous)
however, don't confuse the business purposes of digital certificates
with any characteristic related to 3-factor authentication aspects
involving access and use of the private key.
trivial characteristic is registration of public key in lieu of
mother's maiden name or PINs (in account records) or in lieu of
passwords in RADIUS and KERBEROS databases.
slightly related recent observation (comment from recent rsa
conference):
http://www.garlic.com/~lynn/2005d.html#14 data integrity and logs
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Latest news about mainframe
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sun, 20 Feb 2005 19:40:29 -0700
SchiradinR@ibm-main.lst (Schiradin,Roland HG-Dir itb-db/dc) writes:
In Europe we call it GSE but we never setup meetings like
share. Each working group is separated from the other for CICS we
have a meeting twice a year including some guys from austria and
switzerland (almost 85 attend the sessions). The language is a big
issue.
Remember beside the big states we have different languages,
different countries, different organization. Asia and austie might
be covered by Shane but I guess it's the same like europe.
i gave presentation at fall '86 european share (SEAS) meeting ... was
on the isle of jersey.
"share europe" (seas) url:
http://www.daube.ch/share/seas01.html
http://www.daube.ch/share/seas02.html
from above:
SHARE Europe (SEAS)
SHARE Europe was an international (voluntary) association of users of
IBM equipment, primarily main frames. The purpose was to exchange
information and knowledge by conferences and publications. The scope
was scientific technical at the beginning and extended to commercial
and administrative data processing.
SHARE Europe was founded 1963 with the name SEAS (Share Europe
Association) as an offspring from the SHARE association in the
USA. Membership reached about 500 scientific and commercial
institutions.
The organisation was clearly International (European), with very
little regional work. At the Anniversary Meeting fall 1994 in Vienna
it was decided to merge with G.U.I.D.E. to form the new association
GSE (Guide Share Europe).
G.U.I.D.E.
G.U.I.D.E. was an international, non-profit-making association of IBM
mainframe users. Its name is derived from Guidance for Users of
Integrated Data Processing Equipment which summarises the objectives
of the association.
G.U.I.D.E. was founded in 1959 from its origins as a division of the
GUIDE International Corporation (USA). Until the merger with SHARE
Europe, membership of G.U.I.D.E. reached about 2000 companies and
institutions. The organisation was based on vivid regional work
carried out in local language. Twice a year international conferences
were held in English.
At the Anniversary Meeting fall 1994 in Vienna it was decided to merge
with SHARE Europe to form the new association GSE (Guide Share
Europe).
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Radical z/OS
Newsgroups: bit.listserv.ibm-main
Date: Sun, 20 Feb 2005 22:45:56 -0700
shmuel+ibm-main@ibm-main.lst (Shmuel Metz , Seymour J.) writes:
That has not been my experience. My experience has been that the
menu structure is counter-intuitive, and that about the time that I
learn it they change it again. To say nothing of m$[1] not following
its own "standards".
i've seen two different scenarios ... most CLI were originally
developed for line terminals ... expert users could efficiently and
quickly accomplish quite a bit in few keystrokes.
with advent of display screens ... menus tended to be targeted at the
novice user ... people who infrequently did various tasks and had a
hard time remembering what features available, what commands were,
arguments were, etc. ... menus tended to be like training wheels on
bicycles ... with some people never progressing past that
point. these menus tend to be laborious ... because they are intended
to hand-hold a casual user thru various complex/convoluted operations
(effectively a menu interface as a beginner's training manual that
they never progress past).
the counter example is an online environment that has large number of
power-users ... they spend a large portion of their day using a very
archaic CLI (left over from the sixties). A typical operation requires
archaic CLI input, examine response, and then several more CLI inputs
... each requiring response examination before the next input.
A graphical interface was built ... not so much as a menu input crutch
... but to provide responses with more comprehensive information (in
effect collapsing several CLI inputs into a single operation, with the
user being able to deal with more comprehensive information from a
much richer response display). This resulted in a much more effective
operational environment.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Thou shalt have no other gods before the ANSI C standard
Newsgroups: sci.crypt,alt.folklore.computers
Date: Mon, 21 Feb 2005 09:12:34 -0700
Steve O'Hara-Smith writes:
I am actually suffering a laptop with Windows eXPectorate at the
moment which I am not allowed to treat as I normally would. I was allowed
to install Cygwin and SFU on it though which eases the pain :)
i felt like i was the only one at RSA with fedora on laptop (wiped
clean and fresh install). i have wireless working fine in places like
coffee shops, airports, hotels, etc. But for the RSA show, simple
wireless (with or w/o encryption) wasn't good enuf. in any case, i
didn't get it working.
i guess given all the news stories about attacks on wireless at the
show ... i shouldn't be complaining.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The future of the Mainframe
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 21 Feb 2005 10:39:05 -0700
Steve Samson writes:
Reminds me of the early MVS objective for continuous operation. As the
need for therapeutic IPLs diminished, the need for IPLs to apply
updates persisted. IBM then made the wonderful(?) discovery that
parallel sysplex seemed to meet the customer need for continuous
operation of <something>.
Thus the effort to allow MVS to be refreshed dynamically died, and
true continous operation remains as far off as it did in 1980. I still
think that IPL should be a single event in the life of a
hardware/software combination, and that restarting the system after,
say, a power outage should be a simple restore of a snapshotted state.
Maybe it's not so important any more, but is there still an
outstanding requirement for continuous operation?
i got to write that up in the corporate continuous availability
strategy document .... but it was for ha/cmp ...
http://www.garlic.com/~lynn/subtopic.html#hacmp
and (at the time), both rochester and pok non-concurred (because they
couldn't support it) and the section was removed.
a lot of the parallel sysplex stuff came out of the peer-coupled
shared data architecture my wife did when she served her stint in POK
in charge of loosely-coupled architecture ... misc. past posts
http://www.garlic.com/~lynn/subtopic.html#shareddata
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Latest news about mainframe
Newsgroups: bit.listserv.ibm-main
Date: Mon, 21 Feb 2005 10:33:22 -0700
IBM-MAIN@ibm-main.lst (Phil Payne) writes:
"Here's Phil Payne to talk about Solid State Disk drives. SAS will
be sponsoring the bar from 18:00."
I made it. Fourteen minutes - fastest pitch I've ever given.
I'm probably pitching again this year - IBM Mainframe Futures or
some such.
my pitch at fall '86 seas (25th anv. meeting) was a full-day
presentation ... but they only scheduled an hour. a bof was then
scheduled at 6pm in the room next to the scids ballroom ... and ran
until midnight (with lubrication). recent posting:
http://www.garlic.com/~lynn/2005d.html#12
30 year history of european share (seas) ... including dates and
location of meetings:
http://www.daube.ch/share/seas01.html
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Adversarial Testing, was Re: Thou shalt have no
Newsgroups: sci.crypt,alt.folklore.computers
Date: Mon, 21 Feb 2005 18:39:53 -0700
"Trevor L. Jackson, III" writes:
This is a great theory but it fails in practice. The problem with it
is that the relationships between the the developers and testers
evolve to "game the system" with the result that the tension that
should exist between them is dissipated. On of the keys to the
creation of a market is the independence of hte transactions, which
mandates independence of the participants.
For a semi-formal treatement of such iterated transcatios see
Axelrod's 1986 book "The Evolution of Cooperation". If the soldiers
in the trenches of WWI were able to establish relationships that
frustrated the generals what hope is there for mere managers of
software development?
there was a process in the disk engineering lab ... where the
engineers in the bldg. 14 disk engineering development lab and the
engineers in bldg. 15 product test lab didn't report to the same chain
of management ... until you got to the lab. director.
supposedly anybody with badge access to one of the bldgs wasn't
allowed to have badge access to the other bldg. There was exception
for the processor field engineers that took service calls on the
mainframes used for validating the disk hardware (mainframes used by
both bldg. 14 and bldg. 15) ... and another exception for me
... partially because i liked to wander around and fiddle with stuff
... both breaking stuff and building stuff that wouldn't break:
http://www.garlic.com/~lynn/subtopic.html#disk
bldg 15 had (has?) this large room sized environmental chamber that
can control air pressure, temperature, humidity.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Adversarial Testing, was Re: Thou shalt have no
Newsgroups: sci.crypt,alt.folklore.computers
Date: Mon, 21 Feb 2005 22:35:16 -0700
"Trevor L. Jackson, III" writes:
That's a good start. But years later they will all know each other
and tit-for-tat backscratching will contaminate the independence.
You really need hired guns (they are disposable and not offended
thereby).
the ww1 trench cooperation ... if i don't shoot at you, you don't
shoot at me ... there is some quid-pro-quo.
the disk engineering have extremely detailed error tracking over
period of years ... if the product test engineers let something slip
thru ... it reflects back on the product test engineers (they are on
the line for not catching it ... and may involve large number of
people physically visiting customer locations to remedy the
problems)... there is nothing the development engineers can offer to
really ameliorate/compensate. one issue is that there is an
accountability infrastructure that really holds people accountable.
this has been long term operation spanning decades producing long
string of products.
a bigger issue in this scenario is to not have the product test
engineers contaminated by assumptions made by the development
engineers ... so they don't become blind to same/similar short comings
in the product ... it isn't a backscratching issue ... it is a view
point contamination issue. if development engineers have overlooked
something ... possibly because of the way they are thinking about the
subject ... you don't want the same symptoms affecting the product
test engineers.
for some topic drift ... a tale about how serious some of this is
taken. there is this industry service that gathers erep (error
reporting) data from customer installations about errors and publishes
it. long ago and far away i had done this software hack for channel
(aka local i/o bus) extension over telco link ... and if there was an
unrecoverable error ... i simulated something called channel check to
the regular channel processing error handling code (which would retry
the operation in various ways).
some time later, a new processor was coming out which they had
designed to have no more than 3-4 channel checks per year across all
customers (not 3-4 channel checks per year per machine ... but an
aggregate total of 3-4 channel checks per year across all
machines). well to their dismay ... the industry reporting service
shows up with there having been an aggregate of 15 channel checks
across all machines the first year of operation. this kicked up some
serious forensics (? the current in-word). They eventually tracked it
down to this stuff I had done for channel extender over telco link and
asked if I could change it. After some investigation, i determined
that if i simulated IFCC (interface control check) instead of CC
(channel check) ... the error recovery/retry processes would for all
intents and purposes be the same.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Adversarial Testing, was Re: Thou shalt have no
Newsgroups: sci.crypt,alt.folklore.computers
Date: Mon, 21 Feb 2005 22:46:19 -0700
... there was a lot at risk, in the early 80s, stuff coming out of
bldg. 14, disk engineering was doing in the range of $20B to $30B per
annum revenue (in 1980 dollars) ... for comparison here is intel's
total 2004 revenue (in 2004 dollars):
http://press-releases.techwhack.com/50/intel-quaaterly-annual-revenue/
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Mainframe and its future.. or furniture
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 22 Feb 2005 10:09:22 -0700
dba@ibm-main.lst (David Andrews) writes:
Can't speak for the old timers... but I remember Magnuson. ;-)
What I remember: Carl Amdahl was involved, the machine was rather
low-end, and was customer microprogrammable. I was freshly out of
college then, and wanted badly to get my hands on one of these (our
weekend attempts to hammer microcode into the /145 turned on red
lights but accomplished little else). Alas, my employer didn't see
the wisdom of purchasing a Magnuson box, so I had to learn microcode
on the local university's V-73.
it was a 4341-clone .. i have some recollection of them being over
the hill in santa cruz.
the only time i believe i actually ran into one was at cray research.
the standard tcp/ip product was done in vs/pascal and on a 3090
would consume a whole 3090 processor getting 44kbytes/sec.
I had added rfc 1044 support
http://www.garlic.com/~lynn/subnetwork.html#1044
to the product and in testing at cray research between a cray and a
4341-clone (which i believe was magnuson) was getting 1mbyte/sec
sustained thruput (controller channel interface speed) between cray
and 4341-clone using only a modest amount of the 4341-clone processor.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Mainframe and its future.. or furniture
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 22 Feb 2005 10:14:58 -0700
gilmap writes:
.. and a 6603 platter for a coffee table. (A couple of my friends
have them.)
i used to spend weekends in the science center machine room
http://www.garlic.com/~lynn/subtopic.html#545tech
one weekend i had been at it over 24hrs and something went wrong and i
needed a backup tape. for some reason the room that had most of the
tapes in had its door locked. these doors were heavy, solid fir and i
kicked it once. it decided to split in clean line from top to bottom
where the knob was.
the door was moved to 4th floor conference area and layed over two
(two-drawer) file cabinets to form a desk ... and to remind me to not
kick doors.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is a cryptographic monoculture hurting us all?
Newsgroups: sci.crypt
Date: Tue, 22 Feb 2005 12:16:06 -0700
Jean-Luc Cooke writes:
And every "bank" should have the choice of which approved "safe" to
use.
that is possibly crypto/technical "safe" ... where "safe" for a
financial institution may have additional considerations.
one of the issues with us/ansi X9 standards (and the ISO international
equivalents) is that if the financial institution demonstrates that
they comply with official standards ... then in any litigation, the
burdon of proof tends to be on the other party.
If the financial institution chooses implementation (regardless of the
reason) that deviate from official standards then in situations
involving litigation ... the burdon of proof can shift from the other
party (prooving the financial institution at fault) to the financial
instituation (having to proove it wasn't at fault).
then there are things like reg-E ... where there is an assumption of
inequality between institutions and individuals ... which places the
burdon of proof on the institution.
in the mid-90s there were even large merchants approached with the
story that if they adopted digital signature authenticated
transactions, ... then if a consumer certificate could be produced
that happen to have the non-repudiation flag set ... then the burden
of proof could shift from the merchant to the consumer. attractive
financial prospect for the merchant ... although could be considered
complete mis-representation of any certificate non-repudiation flag
(which has since been depreciated).
note also ... as outlined
http://www.garlic.com/~lynn/2005d.html#21
http://www.garlic.com/~lynn/2005d.html#19
http://www.garlic.com/~lynn/2005d.html#18
http://www.garlic.com/~lynn/2005d.html#17
even digital signature authentication is somewhat misnomer. a digital
signature might be taken as an indirect indication of some aspects of
3-factor authentication having been performed in the access and use of
a specific private key ... but w/o the relying party having some
knowledge of what authentication processes where used to access and
use the private key (for purposes of generating a digital signature),
the relying party doesn't actually have any real knowledge about what
authentication (if any) a digital signature might imply.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Thou shalt have no other gods before the ANSI C standard
Newsgroups: sci.crypt,alt.folklore.computers
Date: Tue, 22 Feb 2005 12:57:11 -0700
daw@taverner.cs.berkeley.edu (David Wagner) writes:
I'm afraid Olson is right. Testing with the all-zeros file might
crash a system, but it is certainly not sufficient for security, not
by a long shot. (Make sure you keep clear in your mind the
distinction between *necessary* and *sufficient*.)
The all-zeros file is not an example of a malicious input. Security
requires going way beyond that kind of simplistic testing. If
anyone thinks the all-zeros file is the worst that attackers are
going to feed them, they are going to get a big surprise when a
serious adversary first tries to attack their software.
when we were working on the original payment gateway and this thing
called SSL with this little small startup in menlo park (that later
moved to mountain view)
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
after they had gone thru all there extensive testing ... we produced a
fault/failure matrix which listed all possible faults/failures (some
amount of this is traditional enumeration of edge conditions) we could
come up with in conjunction with all possible states ... and had them
demonstrate that all possible conditions in all possible states were
handled.
this is somewhat like chip logic checkers (before chips became too
complex to do complex coverage) ... one of the earliest was the los
gatos state machine (LSM, later renamed logic simulation machine for
public consumption) ... which was followed by EVE (endicott
verification engine ... and somewhere inbetween was yorktown
simulation macine).
as chips became more and more complex ... you started to see by at
least the mid-90s situations where there might only be a couple
percent test coverage ... and the evoluation of testing methodologies
using things like genetic (adaptive) algorithms.
misc. past posts about lsm, ysm, eve, etc:
http://www.garlic.com/~lynn/2002d.html#3 Chip Emulators - was How does a chip get designed?
http://www.garlic.com/~lynn/2002g.html#55 Multics hardware (was Re: "Soul of a New Machine" Computer?)
http://www.garlic.com/~lynn/2002j.html#26 LSM, YSE, & EVE
http://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002p.html#38 20th anniversary of the internet (fwd)
http://www.garlic.com/~lynn/2003b.html#10 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003.html#31 asynchronous CPUs
http://www.garlic.com/~lynn/2003k.html#3 Ping: Anne & Lynn Wheeler
http://www.garlic.com/~lynn/2003k.html#14 Ping: Anne & Lynn Wheeler
http://www.garlic.com/~lynn/2003o.html#38 When nerds were nerds
http://www.garlic.com/~lynn/2004i.html#7 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004j.html#16 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2004o.html#25 CKD Disks?
http://www.garlic.com/~lynn/2004o.html#65 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2005c.html#6 [Lit.] Buffer overruns
by comparison in the mid-70s ... when i released the (mainframe)
resource manager .... we developed an automated benchmarking
methodology and defined something like 1000 different benchmarks
to validate and calibrate the resource manager. the science
center
http://www.garlic.com/~lynn/subtopic.html#545tech
had done a lot of work on performance monitoring, workload profiling,
performance management, performance simulation, and the early
inception of capacity planning. part of this was an APL performance
model that took in real live data from running systems and was later
used as a product called performance predictor on HONE
http://www.garlic.com/~lynn/subtopic.html#hone
where marketing and sales people could ask what-if questions about
customer configurations (i.e. what benefit was there to more disks,
faster disks, faster cpu, more real storage, etc).
however, for the resource manager validation ... the APL model was
feed the results of the first 1000 or so benchmarks and then was
allowed to choose configuration, workload, and system parameters for
another 1000 benchmarks (examining the result from each benchmark
before defining the next one). This set of 2000 benchmarks took
something like 3 months elapsed time to run:
http://www.garlic.com/~lynn/subtopic.html#bench
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Adversarial Testing, was Re: Thou shalt have no
Newsgroups: sci.crypt,alt.folklore.computers
Date: Tue, 22 Feb 2005 20:01:32 -0700
another possible facet comes from boyd ... slightly related
paper:
Boyd Cycle Theory in the Context of Non-Cooperative Games:
Implications for Libraries:
http://www.webpages.uidaho.edu/~mbolin/bridges2.htm
i sponsored boyd's talks a number of times in the '80s ... various
of my boyd related postings:
http://www.garlic.com/~lynn/subboyd.html#boyd
other articles about boyd from around the web:
http://www.garlic.com/~lynn/subboyd.html#boyd2
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Thou shalt have no other gods before the ANSI C standard
Newsgroups: sci.crypt,alt.folklore.computers
Date: Tue, 22 Feb 2005 20:16:56 -0700
Morten Reistad writes:
No, we have made loud complaints about how the academic field handles
this subject before. The good results are made by a handful of people.
Go look at Multics and OpenBSD. These are the only places I know
that has attacked this problem in a systemic manner. Be prepared
to read source code.
Or, go read some sites with a different colour on the hat. 2600 magazine
is a good place to start.
note that cp67 and vm370 also "attacked" such things in systematic
(and systemic) manner ... there just weren't as many academic papers,
even tho multics was on the 5th floor of 545tech sq .. and cp67
and vm370 was done at the science center on the 4th floor of 545tech
sq.
http://www.garlic.com/~lynn/subtopic.html#545tech
there were a number of cp67 and vm370 online time-sharing commercial
service bureaus built on the platform (which wasn't true of multics)
that required high integrity isolation between the different users:
http://www.garlic.com/~lynn/subtopic.html#timeshare
minor multics x-over posting
http://www.garlic.com/~lynn/2001m.html#12
http://www.garlic.com/~lynn/2001m.html#15
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: backup/archive
Date: Tue, 22 Feb 2005 23:57:30 -0700
Newsgroups: bit.listserv.vmesa-l
on 22feb05 at 13:20:36 -0500, alan altmark wrote:
Alyce, IBM already has a product that provides Linux file-level
backup and restore: Tivoli Storage Manager. IBM Backup and Restore
Manager for z/VM is for backing up and restoring z/VM objects, not
Linux objects.
before it was called TSM ... it was called ADSM, which had evolved out
of workstation datasave facility ... and there is supposedly still
compatibility with workstation datasave (or at least workstation
datasave clients)
workstation datasave was facility that ran on vm ... and provided vm as
well as various kinds of distributed, pc, workstation, etc backup.
workstation datasave had evolved out of an internal backup/archive
that I originally wrote for sjr, hone, and engineering labs.
... misc. past postings on backup/archive
http://www.garlic.com/~lynn/subtopic.html#backup
misc. past postings on hone
http://www.garlic.com/~lynn/subtopic.html#hone
misc. past postings on disk engineering labs
http://www.garlic.com/~lynn/subtopic.html#disk
checking some online TSM documents ... it still references at least
supporting workstation datasave clients.
earlier posting on subject:
http://listserv.uark.edu/scripts/wa.exe?A2=ind0312&L=vmesa-l&F=&S=&P=12122
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Thou shalt have no other gods before the ANSI C standard
Newsgroups: sci.crypt,alt.folklore.computers
Date: Wed, 23 Feb 2005 08:48:04 -0700
Brian Inglis writes:
Lynn,
Was any of your work on e.g. vs clock, deadline scheduling, dynamic
resource management, I/O recovery, etc. ever written up for IBM
Sys.J., IBM J.R&D, other pubs, SHARE presentations, or whatever?
there were several cambridge science center reports and a couple
of SJR technical reports. then there is my marathon session
at SEAS that i've recently referenced.
http://www.garlic.com/~lynn/2005d.html#22 Latest news about mainframe
http://www.garlic.com/~lynn/2005d.html#26 Latest news about mainframe
clock, resource management, etc ... was part of resource manager,
before it was released, i had to write a specific manual (maybe 40-50
pages) for it and give classes (i don't think the manual is still
available ... and it carried copyright ... so you didn't see it
leaking into academic press). this has transcription of the product
announcement letter of the initial resource manager release:
http://www.garlic.com/~lynn/2001e.html#45 VM/370 Resource Manager
there is the indirect publication of the stanford phd on clock (and
global LRU) in the late 70s; there was an issue of opposition to
granting the phd ... because of the disagreement between local LRU and
global LRU. I was asked to provide supporting evidence to break the
deadlock. There had been a ACM article by the grenoble science center
implementing the local LRU strategy on the same operating system and
hardware (that i had done global LRU & clock in the 60s while
undergraduate ... about the same time that the original ACM paper on
local LRU was published). I had numbers that showed that my global LRU
implementation from the 60s significantly outperformed the grenoble
local LRU (on same operating system and platform) ... misc. past refs:
http://www.garlic.com/~lynn/94.html#1 Multitasking question
http://www.garlic.com/~lynn/99.html#18 Old Computers
http://www.garlic.com/~lynn/2000e.html#20 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2001h.html#26 TECO Critique
http://www.garlic.com/~lynn/2001l.html#6 mainframe question
http://www.garlic.com/~lynn/2002c.html#49 Swapper was Re: History of Login Names
http://www.garlic.com/~lynn/2004c.html#59 real multi-tasking, multi-programming
http://www.garlic.com/~lynn/2004g.html#13 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004.html#25 40th anniversary of IBM System/360 on 7 Apr 2004
http://www.garlic.com/~lynn/2004q.html#73 Athlon cache question
http://www.garlic.com/~lynn/93.html#7 HELP: Algorithm for Working Sets (Virtual Memory)
after i was at the science center ... lots of research resulted in
code that was absorbed directly into products ... in one way or
another. there was misc. stuff ... like gov. restrictions on
pre-announcing products ... if it was being absorbed into product,
talking about it could be considered violation until after it shipped
(and that process could be a year or more). as code became less & less
free, you started to see more & more concerns expressed about giving
too detailed description about commercial products. of course when
i was an undergraduate ... there was less concern about possibly
proprietary code issues ... even when the code was being absorbed
in distributed commercial product ... like extract from '68 share
presentation i made as undergraduate:
http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14
http://www.garlic.com/~lynn/94.html#20 CP/67 & OS MFT14
i guess part of the issue ... was that while i spent a great deal of
my career at the cambridge science center and san jose research, a lot
of my research ... i also wrote product code for that was shipped in
commercial product. a lot of time that might have gone into producing
academic papers were instead spent on shipping commercial products.
there were half dozen or so SJR reports drafted that never received
corporate approval for publication ... numerous references about the
work being too close to commercial (primarily because i would write
all the code and drop it into internal production systems ... and so
it took on quite a bit the characteristic of being real and commercial
... as opposed to research).
there were also rumor that i was going to have harder time receiving
publication approval after being blamed for tandem memos (early
online computer conferencing and other stuff). At one time, there was
some claim that for specific months, I was some how responsible for as
much as 1/3rd of all bits flowing that month across all of the
internal network. note, from just about the beginning until mid-85 of so,
the internal network was larger than all of the arpanet/internet
... misc past posts about the internal network:
http://www.garlic.com/~lynn/subnetwork.html#internalnet
random past refs to tandem memos:
ttp://www.garlic.com/~lynn/2001g.html#5 New IBM history book out
http://www.garlic.com/~lynn/2001g.html#6 New IBM history book out
http://www.garlic.com/~lynn/2001g.html#7 New IBM history book out
http://www.garlic.com/~lynn/2001j.html#31 Title Inflation
http://www.garlic.com/~lynn/2002k.html#39 Vnet : Unbelievable
http://www.garlic.com/~lynn/2002o.html#73 They Got Mail: Not-So-Fond Farewells
http://www.garlic.com/~lynn/2002q.html#16 cost of crossing kernel/user boundary
http://www.garlic.com/~lynn/2002q.html#38 ibm time machine in new york times?
http://www.garlic.com/~lynn/2004k.html#66 Question About VM List
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Thou shalt have no other gods before the ANSI C standard
Newsgroups: sci.crypt,alt.folklore.computers
Date: Wed, 23 Feb 2005 09:12:27 -0700
Peter Flass writes:
Two OSs for two different purposes. VM was built for isolation of
users - everybody has their own dedicated machine - and what sharing
there is was added later and not too efficiently (e.g.SFS). Multics
was built to allow users to share code and data in a controlled
manner, and wasn't interested in isolation.
however, there has been a lot written about a lot of the Multics being
deployed in various (gov) environments where it was specifically used
for isolation/partitioning of users.
frequently cited is the air force evoluation of multics (for gov. use)
and the side note that it has no evidence of having buffer overlow
situations (either from actual events or from detailed code reviews
... significantly contributing to this is that buffers and especially
target buffers for copy operations carried explicit max. length values
... the semantics of which were supported by the infrastructure and
libraries):
http://www.garlic.com/~lynn/2002g.html#55 Multics hardware (was Re: "Soul of a New Machine" Computer?)
http://www.garlic.com/~lynn/2002g.html#81 Multics reference in Letter to Editor
http://www.garlic.com/~lynn/2002h.html#30 Multics hardware (was Re: "Soul of a New Machine" Computer?)
http://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#45 Thirty Years Later: Lessons from the Multics Security Evaluation
cp67 and vm370 in the commercial time-sharing deployments had
significant requirements for sharing between (at least) subsets or
collections of the online users (i.e. collections of users from the
same corporation using the services). There were specific enhancements
made by these service bureaus to accomplish such sharing (which didn't
show back up in official product ... since they were viewed as
commercial advantage).
note also that the original sql/relational database was built on
vm/370 ... which had some number of enhancements for sharing,
misc. system/r posts:
http://www.garlic.com/~lynn/subtopic.html#systemr
even tho the first commercial relational database was shipped on
multics
http://www.mcjones.org/System_R/mrds.html
i had done a lot at science center with paged mapped filesystem and
sharing of file memory-mapped objects ... only a trivial small
subset of which actually shipped in products:
http://www.garlic.com/~lynn/subtopic.html#mmap
http://www.garlic.com/~lynn/subtopic.html#adcon
some of which was used later at sjr in system/r work. in the tech.
transfer of system/r to endicott for sql/ds ... they eventually
regressed to wanting a version that didn't require any kernel changes,
so it had to be mapped to less finer granularity sharing constructs.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Thou shalt have no other gods before the ANSI C standard
Newsgroups: sci.crypt,alt.folklore.computers
Date: Wed, 23 Feb 2005 09:19:45 -0700
there was some competition between the code that i was writing on the
4th floor and the code that they were writing (for multics) on the 5th
floor. one of my hobbies was doing internal custom production kernel
distributions (which had lots of enhancements only a subset of made it
to customer product release).
it wasn't fair to compare the work on the 5th floor to the full vm/370
product ... in terms of number of customers ... since the vm/370 group
was much larger and had much larger number of customers. It wasn't
even fair to compare the work on the 5th floor to just the total
number of internal vm/370 installs (since that was still way more than
an order of magnitude larger than all multics installs).
so the comparison was between what the 5th floor was doing and what i
was doing ... since the total number of multics installations was
about the same as the total number of internal corporate installations
that i directly supported with highly modified production kernel
distribution.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Thou shalt have no other gods before the ANSI C standard
Newsgroups: sci.crypt,alt.folklore.computers
Date: Wed, 23 Feb 2005 10:03:23 -0700
ref:
http://www.garlic.com/~lynn/2005d.html#37 Thou shalt have no other gods before the ANSI C standard
for even more topic drift:
http://www.garlic.com/~lynn/2005d.html#14 data integrity and logs
which is somewhat related to
http://www.garlic.com/~lynn/2005d.html#36 backup/archive
as well as
http://www.garlic.com/~lynn/subtopic.html#systemr
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Thou shalt have no other gods before the ANSI C standard
Newsgroups: sci.crypt,alt.folklore.computers
Date: Wed, 23 Feb 2005 12:52:45 -0700
Brian Inglis writes:
That would be LY20-1996, so available only to licensed users of the
PRPQ product. Was that superceded by VM/HPO for VM/SP? I only got
involved running VM/SP/HPO(/VSE/CICS/MVS/VTAM/TCP/...) for a few years
from about the time the Waterloo etc. tape mods were being
reimplemented to include on the vanilla product PUT tape.
that is the story about problems with later shipping SMP support.
up until that time, they were charging for application code ... but
not kernel code. the original resource manager got selected to be the
guinea pig for charging for kernel code. i got to spend six months off
and on with the business people working out the business practices for
pricing kernel code. the decision at that time was that if the kernel
code wasn't directly necessary for hardware support (stuff like
enhanced resource management), then it could be priced; otherwise it
was still free.
the problem was that i included in the resource manager a lot of stuff
that had been dropped in the transition from cp67->vm370 ... including
a lot of structuring for supporting SMP operation. the resource
manager was shipped before there was a decision to ship vm370 SMP
support ... although I had been also working on a microcode-based
SMP implementation:
http://www.garlic.com/~lynn/subtopic.html#bounce
as well as the microcode ECPS performance assist for 148 (later 4341)
http://www.garlic.com/~lynn/subtopic.html#mcode
concurrently with working on the resource manager.
In any case, the decision was then made to ship vm370 SMP support ...
http://www.garlic.com/~lynn/subtopic.html#smp
which is obviously directly involved in supporting hardware ... and
therefor must be free. however, a lot of the SMP code needed the code
in the resource manager. The business rules required that you couldn't
have "free" code with dependencies on "non-free" code. The decision
was then made to take about 80 percent of the resource manager code
and move it to the "free" kernel ... and the remaining code in the
resource manager then eventually formed the basis for SEPP (and BSEPP)
... and eventually vm/sp ... where you could now again have a single
product ... where all the kernel was now priced.
two months before the resource manager shipped ... VS/REPACK shipped
(from the science center). at the time that VS/REPACK shipped, the
"science center" (was separate entity from the vm/370 development
group and) was eligible for non-development product program (people
eligible for this product program received 1/12th of each annual
lease for the first two years). The month before the resource manager
shipped, the "science center" was removed from the list of internal
sites that were eligible for the non-development product program. As
an aside, the resource manager passed 1000 installed licenses shortly
after availability/FCS ... at $850/month ($10k/year). I even offered
to forgo my salary to be part of the program.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Thou shalt have no other gods before the ANSI C standard
Newsgroups: sci.crypt,alt.folklore.computers
Date: Thu, 24 Feb 2005 08:34:21 -0700
jmfbahciv writes:
It is very rare to have one person be able to do more than one kind
of thinking style. Here I'm back to the discussion a.f.c. had
with me about my terms "compiler-thinking" and "OS-thinking".
What strikes me as a flaw in security is that the security types
are always playing catchup to the crackers. This is an unideal
approach and I've been thinking about how to get the security
biz out of this rut. Caveat: I've also been accused of believing
in fairies, virgins, and inside straights, too. :-)
many situation where they are playing catchup is because security
hasn't been built into the infrastructure ... and has become a
re-active post-deployment (after-market) solution (they appear to be
constantly playing catchup because they are just reacting to stuff
that happens).
when integrity is part of the fundamental infrastructure ... security
is less featured ... because there are much fewer events that require
post-deployment, band-aid workers.
about the time we were doing the original internet payment gateway,
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
i gave a talk at a graduate student seminar at isi/usc about why
internet wasn't business critical dataprocessing. you do things
differently if you think about situations in terms of threats and
countermeasures ... and it becomes part of the basic landscape.
architects designing buildings are taught about things like
wind-loading on exterior surfaces and having to take into account
worst-case local wind conditions. there are certain things you do when
you design a building to withstand force 5 hurricane. attempting to
retrofit an existing building to withstand a force 5 hurrican isn't
normally very succesful. If you have situations where the daily wind
is able to blow down every building ... eventually you create
conventions &/or guidelines where the buildings don't blow down quite
so often. i believe most licensed architects are held professional
responsible if they don't take into account well understood hazards
when they produce a design.
how is this for a little topic drift (curtesy of search engine):
SHOULD THE PUP BE SPENDING BORROWED MONEY ON 10,000 HOUSES WITH A
CUBAN FACTORY, PRODUCING FLAT WALLS, OR BE BUILDING HURRICANE
RESISTANT CONCRET DOME HOUSES INSTEAD?
http://belize1.com/BzLibrary/trust235.html
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Secure design
Newsgroups: sci.crypt,alt.folklore.computers
Date: Thu, 24 Feb 2005 10:03:29 -0700
"Tom Linden" writes:
Unlike KeyKOS (Gnosis), hurricane rated design using your metaphor
I think about the only think that was not considered was covert channels.
Changed the subject, tired of seeing it.
when i was undergraduate in the 60s, i was once asked to address
low-bandwidth information leakage situation (common example in the
literature is the number of pizzas delivered after hrs to the white
house). i look at it for a bit ... but i pointed out that the masking
activity was probably going to consume more resources than they were
willing to devote (a benefit/cost trade-off). some similarity to the
differential power attack countermeasures.
it came up again in human factors studies regarding human behavior in
predicatable response and unpredictable response scenarios ... that
human productivity tends to be better in predictable response
environments (modulo predictable response needs to be orders of
magnitude worse than just trying to handle the 80th percentile)
... . aka making response uniform regardless of the system loading
... and is related to making response predictable.
the opposite example is letting people see response variation under
heavy loading ... can influence behavior ... sometimes resulting in
people re-arranging schedule to take advantage of better response
during system lightly loaded periods.
rush hour congestion on road systems could be considered an example.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Thou shalt have no other gods before the ANSI C standard
Newsgroups: sci.crypt,alt.folklore.computers
Date: Thu, 24 Feb 2005 10:38:48 -0700
Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:
There are 100's of thousands of Apache and IIS installations, OS
kernels, SMTP and DNS servers, etc., all subject to internet attack.
The whole mainframe industry put together never shipped more than a
fraction of that much hardware through its whole history. There
similarly are hundreds of millions of Windows clients, maybe as many
as a billion. And software applications are orders of magnitude
more complicated than they were in the old days. Stuff written with
the old methods just has no chance now.
the large mainframe of old tended to have large user propulations.
After standard testing ... deployed systems tended to have uniquely
reported bugs proportional to the uniquely different things it was
being used for. this tended to result in some increase in uniquely
reported bugs up until some threshold of 500-600 (of these really
large sysems with large user populations) ... but while the number of
bug reports somewhat tended to increase proportional to the number of
system/users ... the number of uniquely reported bugs didn't tend to
continue growing (say as the number of systems increased from 500-600
to possibly 20,000).
i would also conjecture for those individuals interested in launching
serious internet attacks ... that dockmaster might have represented an
extremely attractive target:
http://www.multicians.org/site-dockmaster.html
... you could do search in various crypto archives for much of the 90s
for "dockmaster" in the email address.
while the internal network had more nodes the internet from just about
the arpanet origins up thru sometime mid-85
http://www.garlic.com/~lynn/subnetwork.html#internalnet
a large part of the internet node growth in the post 1/1/83 switchover
to internetworking protocol ... where for individual node machines ...
while the internal network continued to be primarily large mainframe
systems.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Thou shalt have no other gods before the ANSI C standard
Newsgroups: sci.crypt,alt.folklore.computers
Date: Thu, 24 Feb 2005 14:00:42 -0700
"Trevor L. Jackson, III" writes:
Historical note: Check out the post-WWII development methodology
called "Massive Engineering". I think it was first formalized by
Lockheed. It is the technique of using, say, 5,000 engineers to
design and build an airplane. It is a popular American dysfunction.
note also that lockheed had the skunkworks ... where the really
innovative stuff was done.
also ... boyd was driving factor behind much of the f15, f16, f18 (and
based on lots of his comments the northrup f20/tigershark which never
made it anywhere).
http://www.garlic.com/~lynn/subboyd.html#boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Secure design
Newsgroups: sci.crypt,alt.folklore.computers
Date: Thu, 24 Feb 2005 14:07:38 -0700
Anne & Lynn Wheeler writes:
when i was undergraduate in the 60s, i was once asked to address
low-bandwidth information leakage situation (common example in the
literature is the number of pizzas delivered after hrs to the white
house). i look at it for a bit ... but i pointed out that the
masking activity was probably going to consume more resources than
they were willing to devote (a benefit/cost trade-off). some
similarity to the differential power attack countermeasures.
one might guess that if they got around to asking for countermeasure
to low-bankdwidth information leakage vulnerability ... that they
possibly felt that some of the more serious vulnerabilities had
already been addressed.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Thou shalt have no other gods before the ANSI C standard
Newsgroups: sci.crypt,alt.folklore.computers
Date: Thu, 24 Feb 2005 15:44:19 -0700
recent posting found on bit.listserv.ibm-main ... of course i'm a
little biased about tcp/ip having done rfc 1044 support in the '80s
http://www.garlic.com/~lynn/subnetwork.html#1044
....
According to the article, "A VM Renaissance: VM and Linux" by Philip H.
Smith III, which was not one of the contributing factors to VM/ESA V2's
remarkable stability? (Hint: the article can be found in the Operating
Systems department on www.zjournal.com)
a) MTBF rates of more than 50 years for 9672 G5 hardware
b) Mature system management tools
c) Improved TCP/IP connectivity
d) A VM graphical user interface
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Secure design
Newsgroups: sci.crypt,alt.folklore.computers
Date: Fri, 25 Feb 2005 08:10:27 -0700
Brian Inglis writes:
Was that done in 3x0 assembler or HLL?
at the time, mostly kernel stuff in assembler. but i may have been
somewhat atypical. There was some jokes, that when i was coding,
whatever language I was using tended to become my natural language
(aka the analogy observation about indication that you are becoming
proficient in a natural language is when you start dreaming in it).
at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech
besides vs/repack ... detailed memory reference tracing and fortran
program that implemented cluster analysis for semi-automated program
re-arrgangement and APL for performance, configuration, workload
modeling ... described for selecting automated benchmarking for
validating resource manager
http://www.garlic.com/~lynn/subtopic.html#bench
and performance predictor (sales & marketing support tool) on
world-wide hone system
http://www.garlic.com/~lynn/subtopic.html#hone
there was also a couple people that had implemented an event-driven
system model in PLI. I used to joke with them that I would invent some
new variation on performance algorithm ... and could then code it in
assembler, regression test, and deploy in production operation faster
than they could write the PLI code for their model.
One variation on their model could take detailed memory traces (ala
vs/repack) and simulate various kinds of page replacement algorithms
... clock global LRU (approximates exact LRU), true, exact global LRU
(not very practical in real life, keeping exact order of all pages
with respect to reference), various of others (like some of the stuff
Belady had published from YKT ... like OPT).
So most of the LRU approximations were judged on how well they came to
"true" LRU. There was ACM paper by one of the Multics paper showing
numbers, using 1, 2, 3, & 4 "history" bits, improving ... but 4bits
didn't improve much more than 3bits. The PLI model could also do exact
LRU (kept exact reference ordering of all pages) ... something like
the graph shown here:
http://www.cs.mun.ca/~paul/cs3725/material/web/notes/node15.html
so i came up with this slight of hand variation on clock. In real
life, it should to be better than standard clock and in the PLI model
tended to be slightly better than true LRU ... rather than slightly
worse than true LRU. various past postings on page replacement
algorithms:
http://www.garlic.com/~lynn/subtopic.html#wsclock
as mentioned before, i had essentially done the original clock as
undergraduate in the 60s. and then had done the slight of hand
variation on clock after joining the science center.
something like 10 plus years after doing the original clock, there was
the big fuss over granting a stanford PHD on clock, This was basicaly
over clock being a global-LRU approximation rather than local-LRU
approximation. I got to somewhat help resolve the issue because
grenoble science center had published a paper in ACM on performance
numbers for a local LRU approximation implementation ... done
effectively on the same hardware and operating system being run at the
cambridge science center (except grenoble machine had more real memory
which should have given them advantage in paging tests). The
cambridge machine performance (with clock, global LRU) had much better
performance than the published grenoble numbers (even tho grenoble
machine had 50 percent more real memory for paging).
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Secure design
Newsgroups: sci.crypt,alt.folklore.computers
Date: Fri, 25 Feb 2005 08:21:02 -0700
Anne & Lynn Wheeler writes:
at the time, mostly kernel stuff in assembler. but i may have been
somewhat atypical. There was some jokes, that when i was coding,
whatever language I was using tended to become my natural language
(aka the analogy observation about indication that you are becoming
proficient in a natural language is when you start dreaming in it).
for even more topic drift, in the early 80s there was a researcher
that sat in the back of my office, went to meetings with me, etc and
took notes on how i communicated (telephone, face-to-face, etc). They
were also provided logs of all my incoming and outgoing email as well
as logs of all my instant messages. this went on for nine months.
the research was eventually published as a stanford phd thesis (joint
between language and computer ai departments) ... as well as material
for subsequent papers and books.
misc. general posts on cmc (some of it about the communication
research project)
http://www.garlic.com/~lynn/subnetwork.html#cmc
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Secure design
Newsgroups: sci.crypt,alt.folklore.computers
Date: Fri, 25 Feb 2005 17:37:28 -0700
"Tom Linden" writes:
The above paragraph which prompted the question was about KeyKOS
(aka Gnosis) which had a small kernel written in assembler,
otherwise everything else in PL/I. I have the sources.
it is my fault for causing confusion ... i was replying to your post
on keykos/gnosis mentioning covert channels ... but brought up
situation from 60s where i was asked to change kernel to