14 Dec
2001
14 Dec
'01
6:10 p.m.
From: Christopher Smith <csmith(a)amdocs.com>
(To whit: I worked at one point with a guy who was
convinced that every
operating system in the world was derived in some manner from MS-DOS.
Yes,
that includes the Macintosh operating system too.
"CP/M? What's that?
Unix is based on MS-DOS, right?" The guy was a "programmer.")
(gag, puke)
Well, most of us (except for Tony) have areas that we are not expert in, or
even familiar with. The problem with the fellow you refer to is
1 -- The person who hired him. That person should be disposed of in the
most painful way possible.
2 -- The institution which granted him a degree (if any).
I've also had to work alongside people who managed to scrape their way into
a "programming" job without having "what it takes" to really write
code
*and* solve problems. Don't get me wrong -- I have no degree and don't
think one's required to be a competent analyst/programmer/whatever.
But . . .
Should programmers be licensed? Sure makes me wonder . . .
Glen
00
14 Dec
14 Dec
12:57 p.m.
Glen Goodwin wrote:
I've also had to work alongside people who managed to scrape their way into
a "programming" job without having "what it takes" to really write
code
*and* solve problems. Don't get me wrong -- I have no degree and don't
think one's required to be a competent analyst/programmer/whatever.
But . . .
Should programmers be licensed? Sure makes me wonder . . .
Ok, what does it take to really write code and solve programs?
(Unlicensed programer/coder here ). Writing code is easy... writing the
doc's that is another story. I tend to favor the hardware side, but they
don't make TTL machines like the PDP-8E or transistor ones like the
PDP8/S.
--
Ben Franchuk --- Pre-historic Cpu's --
www.jetnet.ab.ca/users/bfranchuk/index.html
7:42 p.m.
I've also
had to work alongside people who managed to scrape their way into
a "programming" job without having "what it takes" to really write
code
*and* solve problems. Don't get me wrong -- I have no degree and don't
think one's required to be a competent analyst/programmer/whatever.
But . . .
Should programmers be licensed? Sure makes me wonder . . .
Ok, what does it take to really write code and solve programs?
(Unlicensed programer/coder here ). Writing code is easy... writing the
doc's that is another story. I tend to favor the hardware side, but they
don't make TTL machines like the PDP-8E or transistor ones like the
PDP8/S. 
10 p.m.
On Fri, 14 Dec 2001, Eric J. Korpela wrote:
I'd also include Geeks who program any machine
that could accidentally
kill someone
That has been documented. I believe the machine in question was called
the Thorac and it irradiated two people to death. I'm too sleepy to
search on Google right now or I'd provide more information.
--
Jeffrey S. Sharp
jss(a)subatomix.com
15 Dec
15 Dec
12:14 a.m.
I'd also include Geeks who program any
machine that could accidentally
kill someone
That has been documented. I believe the machine in question was called
the Thorac and it irradiated two people to death. I'm too sleepy to
search on Google right now or I'd provide more information.
--
Jeffrey S. Sharp
Bob
12:40 a.m.
IMHO: All software development should be performed as such:
1) Requirements - what should it do, and not do. Spin this till
everybody
signs off.
2) Prelim design - Ok, a rough outline of the design, data structures
and control/data flow defined here.
3) Detailed design - Define all the modules and their function, break it
down.
4) Test plan - integrate testing into detailed design, make it unit
testable.
a unit is somthing that has input and output and side effects, like a
function.
5) Finally, coding - build modules in parallel with test code.
6) Unit testing - verify that modules comply with detailed design.
7) Integration testing - hook it all together, make sure it works, apply
test plan developed in step 4 for fully integrated aplication.
Do 1-3 until marketing decides what they want,4-7 until you find no
errors.
For safety critical, you should /have to perform statement and decision
coverage in
step 6 and 7 and the detailed design should have a one-to-one
corespondence
with the detailed design document.
Jim Davis.
"Eric J. Korpela" wrote:
I'm not sure if geeks should be licensed, but there are certainly instances
when their output should be monitored closely. Geeks who program voting
machines, for example. (I think that voting machine software should be
open source and available from the voting machine. Every other civilized
country gets by with pencil and paper and big bunches of people doing the
counting. I need to trust that an embedded systems programmer doesn't have
strong enough political beliefs that they would try to rig an election.
It gets even worse when you need to believe that people (read Microsoft)
coding the OS of the damn things don't have any interest in the outcome of
elections.)
I'd also include Geeks who program any machine that could accidentally
kill someone (for example airplanes) and Geeks who code for billion
dollar space hardware.
Eric
I've
also had to work alongside people who managed to scrape their way into
a "programming" job without having "what it takes" to really write
code
*and* solve problems. Don't get me wrong -- I have no degree and don't
think one's required to be a competent analyst/programmer/whatever.
But . . .
Should programmers be licensed? Sure makes me wonder . . .
Ok, what does it take to really write code and solve programs?
(Unlicensed programer/coder here ). Writing code is easy... writing the
doc's that is another story. I tend to favor the hardware side, but they
don't make TTL machines like the PDP-8E or transistor ones like the
PDP8/S. 
4:46 a.m.
----- Original Message -----
From: "Jim Davis" <jpdavis(a)gorge.net>
To: <classiccmp(a)classiccmp.org>
Sent: Saturday, December 15, 2001 4:40 AM
Subject: Re: "Geeks" and licensing
I'm not sure if geeks should be licensed, but there are certainly instances
when their output should be monitored closely. Geeks who program voting
machines, for example. (I think that voting machine software should be
open source and available from the voting machine. Every other civilized
country gets by with pencil and paper and big bunches of people doing the
counting. I need to trust that an embedded systems programmer doesn't have
strong enough political beliefs that they would try to rig an election.
It gets even worse when you need to believe that people (read Microsoft)
coding the OS of the damn things don't have any interest in the outcome of
elections.)
I'd also include Geeks who program any machine that could accidentally
kill someone (for example airplanes) and Geeks who code for billion
dollar space hardware.
Eric
IMHO: All software development should be performed as
such:
1) Requirements - what should it do, and not do. Spin this till
everybody signs off.
2) Prelim design - Ok, a rough outline of the design, data
structures and control/data flow defined here.
3) Detailed design - Define all the modules and their function,
break it down.
4) Test plan - integrate testing into detailed design, make it unit
testable. A unit is somthing that has input and output and side
effects, like a function.
5) Finally, coding - build modules in parallel with test code.
6) Unit testing - verify that modules comply with detailed design.
7) Integration testing - hook it all together, make sure it works, apply
test plan developed in step 4 for fully integrated aplication.
Do 1-3 until marketing decides what they want,4-7 until you find no
errors.
A couple of things have been left out.
(a) make certain that all deliverable code has NOTHING that's not
absolutely required: not a superfluous comment, not an extra semicolon.
(b) make certain that all comments in the source have been kept current with the
code as it changes. Too many times, v117.03 has comments left from rev 000.01.
(c) test the model before you write the code. Make certain that every
combination of inputs vs content produces predictable results, no matter how
"impossible" the combination may appear to be.
(d) fire anyone who passes on a document with any form of error in it, including
spelling, punctuation, etc. That's as good a marker as anything as to how well
they've done their job.
For safety critical, you should /have to perform
statement and decision
coverage in
step 6 and 7 and the detailed design should have a one-to-one
corespondence
with the detailed design document.
Jim Davis.
"Eric J. Korpela" wrote:
>
> > > I've also had to work alongside people who managed to scrape their way
into
a
"programming" job without having "what it takes" to really write code
*and* solve problems. Don't get me wrong -- I have no degree and don't
think one's required to be a competent analyst/programmer/whatever.
But . . .
Should programmers be licensed? Sure makes me wonder . . .
Ok, what does it take to really write code and solve programs?
(Unlicensed programer/coder here ). Writing code is easy... writing the
doc's that is another story. I tend to favor the hardware side, but they
don't make TTL machines like the PDP-8E or transistor ones like the
PDP8/S.
5:50 a.m.
On Sat, 15 Dec 2001, Jim Davis wrote:
IMHO: All software development should be performed as
such:
1) Requirements - what should it do, and not do. Spin this till
everybody signs off.
2) Prelim design - Ok, a rough outline of the design, data structures
and control/data flow defined here.
3) Detailed design - Define all the modules and their function, break it
down.
4) Test plan - integrate testing into detailed design, make it unit
testable. a unit is somthing that has input and output and side
effects, like a function.
5) Finally, coding - build modules in parallel with test code.
6) Unit testing - verify that modules comply with detailed design.
7) Integration testing - hook it all together, make sure it works, apply
test plan developed in step 4 for fully integrated aplication.
Do 1-3 until marketing decides what they want,4-7 until you find no
errors.
And possibly add some planning where you use historical data and basic
statistics to figure out how big the product will likely be, how long it
will take, and what resources need to be allocated to complete it.
For safety critical, you should /have to perform
statement and
decision coverage in step 6 and 7 and the detailed design should have
a one-to-one corespondence with the detailed design document. Jim
Davis.
The software process course I just got out of also heavily pushed peer
review of designs and code as a way to filter out defects before testing.
These have their benefits, but I remain unconvinced of their status as the
great panacea of software engineering that the course touted them as.
For a little bit of on-topic goodness, what is the group's opinion on the
trend of software engineering quality starting from ancient times? Have
we improved (practially, not academically) or worsened?
--
Jeffrey S. Sharp
jss(a)subatomix.com
6:06 a.m.
Until the Japanese started programming "in the large," the terms
"software" and
"engineering" were pretty much mutually exclusive after 1965. Until the
Nipponese brought in a 15-Million-line software task within schedule and under
budget, nobody believed it could be done. It was another case of the Japanese
simply doing what the Americans had, for two decades, told everyone was the
right way to do it, though. ... nothing new ... just do it right.
Dick
----- Original Message -----
From: "Jeffrey S. Sharp" <jss(a)subatomix.com>
To: <classiccmp(a)classiccmp.org>
Sent: Saturday, December 15, 2001 9:50 AM
Subject: Re: "Geeks" and licensing
On Sat, 15 Dec 2001, Jim Davis wrote:
IMHO: All software development should be
performed as such:
1) Requirements - what should it do, and not do. Spin this till
everybody signs off.
2) Prelim design - Ok, a rough outline of the design, data structures
and control/data flow defined here.
3) Detailed design - Define all the modules and their function, break it
down.
4) Test plan - integrate testing into detailed design, make it unit
testable. a unit is somthing that has input and output and side
effects, like a function.
5) Finally, coding - build modules in parallel with test code.
6) Unit testing - verify that modules comply with detailed design.
7) Integration testing - hook it all together, make sure it works, apply
test plan developed in step 4 for fully integrated aplication.
Do 1-3 until marketing decides what they want,4-7 until you find no
errors.
And possibly add some planning where you use historical data and basic
statistics to figure out how big the product will likely be, how long it
will take, and what resources need to be allocated to complete it.
For safety critical, you should /have to perform
statement and
decision coverage in step 6 and 7 and the detailed design should have
a one-to-one corespondence with the detailed design document. Jim
Davis.
The software process course I just got out of also heavily pushed peer
review of designs and code as a way to filter out defects before testing.
These have their benefits, but I remain unconvinced of their status as the
great panacea of software engineering that the course touted them as.
For a little bit of on-topic goodness, what is the group's opinion on the
trend of software engineering quality starting from ancient times? Have
we improved (practially, not academically) or worsened?
--
Jeffrey S. Sharp
jss(a)subatomix.com
8:17 a.m.
On Sat, 15 Dec 2001, Jim Davis wrote:
IMHO: All software development should be performed as
such:
1) Requirements - what should it do, and not do. Spin this till
everybody signs off.
2) Prelim design - Ok, a rough outline of the design, data structures
and control/data flow defined here.
3) Detailed design - Define all the modules and their function, break it
down.
4) Test plan - integrate testing into detailed design, make it unit
testable. a unit is somthing that has input and output and side
effects, like a function.
5) Finally, coding - build modules in parallel with test code.
6) Unit testing - verify that modules comply with detailed design.
7) Integration testing - hook it all together, make sure it works, apply
test plan developed in step 4 for fully integrated aplication.
Do 1-3 until marketing decides what they want,4-7 until you find no
errors.
Ah, creationism (see the Jargon Dictionary if you're not familiar
with the term).
What is describe is all very textbook. That, then begs the question,
"why is it that software isn't, in general, done in this fashion?".
The answer is found in step one: the assumption that innovative
hunks of software can be fully specified in advanced. For software
that is truly innovative this is empirically very rarely the case,
as what the customer _thinks_ they want is frequently not what they
end up wanting/needing in the end. Trotting out signed-off specs
in no way improves the situation.
In practice the solution is to accept the fact that specs, no matter
how much they are labored over, are for most efforts soft, and
then describe mechanism to deal with uncertainty as part of the
development process. Rapid prototype, stepwise refinement,
the understanding that one cannot test their way to correctness and
a willingness to throw at least one implementation completely
away, coupled with small, agile teams that work with an active
user community empirically produce more correct results in less
time that alternative techniques.
Not like any of this is new. Brooks described this eons ago
in _The Mythical Man Month_...
--
Chris Kennedy
chris(a)mainecoon.com
http://www.mainecoon.com
PGP fingerprint: 4E99 10B6 7253 B048 6685 6CBC 55E1 20A3 108D AB97
-----Original Message-----
From: owner-classiccmp(a)classiccmp.org
[mailto:owner-classiccmp@classiccmp.org]On Behalf Of Jeffrey S. Sharp
Sent: Saturday, December 15, 2001 8:51 AM
To: classiccmp(a)classiccmp.org
Subject: Re: "Geeks" and licensing
And possibly add some planning where you use historical data and basic
statistics to figure out how big the product will likely be, how long it
will take, and what resources need to be allocated to complete it.
For safety critical, you should /have to perform
statement and
decision coverage in step 6 and 7 and the detailed design should have
a one-to-one corespondence with the detailed design document. Jim
Davis.
The software process course I just got out of also heavily pushed peer
review of designs and code as a way to filter out defects before testing.
These have their benefits, but I remain unconvinced of their status as the
great panacea of software engineering that the course touted them as.
For a little bit of on-topic goodness, what is the group's opinion on the
trend of software engineering quality starting from ancient times? Have
we improved (practially, not academically) or worsened?
--
Jeffrey S. Sharp
jss(a)subatomix.com
17 Dec
17 Dec
12:08 p.m.
The book by Brooks {The Mythical Man Month)should be mandatory reading for
every software man. It is fun too.
I have very good memories from projects where you could first build a useful
small part of the system. The client could then update his requirements and
you could get all the bugs out and when all was stable you would build the
next part of the system. The client has a useful system very early in the
project and because you work together with the client (the user) in an early
stage of the project, errors in the specification and the programs never
last long. Cost control is also facilitated. You have a satisfied customer
most of the time during development and very much so in the end. This was
for projects for up to 1.000.000 lines of code.
Wim
----- Original Message -----
From: Chris Kennedy <chris(a)mainecoon.com>
To: <classiccmp(a)classiccmp.org>
On Sat, 15 Dec 2001, Jim Davis wrote:
IMHO: All software development should be
performed as such:
1) Requirements - what should it do, and not do. Spin this till
everybody signs off.
<snip>
Ah, creationism (see the Jargon Dictionary if you're not familiar
with the term).
What is describe is all very textbook. That, then begs the question,
"why is it that software isn't, in general, done in this fashion?".
The answer is found in step one: the assumption that innovative
hunks of software can be fully specified in advanced. For software
that is truly innovative this is empirically very rarely the case,
as what the customer _thinks_ they want is frequently not what they
end up wanting/needing in the end. Trotting out signed-off specs
in no way improves the situation.
In practice the solution is to accept the fact that specs, no matter
how much they are labored over, are for most efforts soft, and
then describe mechanism to deal with uncertainty as part of the
development process. Rapid prototype, stepwise refinement,
the understanding that one cannot test their way to correctness and
a willingness to throw at least one implementation completely
away, coupled with small, agile teams that work with an active
user community empirically produce more correct results in less
time that alternative techniques.
Not like any of this is new. Brooks described this eons ago
in _The Mythical Man Month_...
--
Chris Kennedy
chris(a)mainecoon.com
http://www.mainecoon.com
PGP fingerprint: 4E99 10B6 7253 B048 6685 6CBC 55E1 20A3 108D AB97
-----Original Message-----
From: owner-classiccmp(a)classiccmp.org
[mailto:owner-classiccmp@classiccmp.org]On Behalf Of Jeffrey S. Sharp
Sent: Saturday, December 15, 2001 8:51 AM
To: classiccmp(a)classiccmp.org
Subject: Re: "Geeks" and licensing
And possibly add some planning where you use historical data and basic
statistics to figure out how big the product will likely be, how long it
will take, and what resources need to be allocated to complete it.
For safety critical, you should /have to perform
statement and
decision coverage in step 6 and 7 and the detailed design should have
a one-to-one corespondence with the detailed design document. Jim
Davis.
The software process course I just got out of also heavily pushed peer
review of designs and code as a way to filter out defects before testing.
These have their benefits, but I remain unconvinced of their status as the
great panacea of software engineering that the course touted them as.
For a little bit of on-topic goodness, what is the group's opinion on the
trend of software engineering quality starting from ancient times? Have
we improved (practially, not academically) or worsened?
--
Jeffrey S. Sharp
jss(a)subatomix.com
15 Dec
15 Dec
2:25 p.m.
For a little bit of on-topic goodness, what is the
group's opinion on the
trend of software engineering quality starting from ancient times? Have
we improved (practially, not academically) or worsened?
For me there was an inflection around 1990.
Before that time there were some heroic efforts that yielded
some amazing products, clear documentation, 100% predictable
operation. Many of these products tended to sell in the $10K to
$80K range.
After that time (now) we have the 'acceptable level of bugs' era
with product prices more like $0.1K to $1K, but then companies
having to run TCO calculations, with all the new problems.
1991 was the first time I heard someone argue that making 100%
Bug-Free code was Impossible.
Now, right at the inflection point came the incredible mass market
success of MS Wind. Internally, I tend to see this it as the Sept11
of software engineering.
There was a research topic a while back called 'Automatic Program
Verification', sort of a mathematically based test case compiler.
I have been away from academia for too long. I wonder how that
movement went.
John A.
3:44 p.m.
New subject: OT: 9/11 : Re: "Geeks" and licensing
Now, right at the inflection point came the incredible
mass market
success of MS Wind. Internally, I tend to see this it as the Sept11
WOW...! This is the first time I have seen 9/11 used to portray another
*really* bad event happening... The first stage of this term being
incorporated into our language?
of software engineering.
Bryan
P.S. But this could be a good thing - it help us to remember the event
everytime it is used.
8:29 p.m.
New subject: OT: 9/11 : Re: "Geeks" and licensing
On Sat, 15 Dec 2001, Bryan Pope wrote:
I wonder if they'll change the phone number for 911?
Sorry, I could not resist!
--
Jeffrey S. Sharp
jss(a)subatomix.com
Now, right at
the inflection point came the incredible mass market
success of MS Wind. Internally, I tend to see this it as the Sept11
WOW...! This is the first time I have seen 9/11 used to portray
another *really* bad event happening... The first stage of this term
being incorporated into our language? 
17 Dec
17 Dec
9:01 a.m.
On Sat, 15 Dec 2001, Jeffrey S. Sharp wrote:
For a little bit of on-topic goodness, what is the
group's opinion on
the trend of software engineering quality starting from ancient times?
Have we improved (practially, not academically) or worsened?
I think it's about stayed the same. Programmers were, are, and will
always be lazy and impatient.
If you look at Microsoft code excluisvely, one could make a good argument
that we've worsened considerably.
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
15 Dec
15 Dec
9:58 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 799 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20011215/18d86092/at…
14 Dec
14 Dec
10:25 p.m.
On Fri, 14 Dec 2001, Ben Franchuk wrote:
Glen Goodwin wrote:
There's a big difference between writing code to solve problems and being
a software engineer. Designing, coding, and compiling is only 40% of the
battle. Hopefully you're also spending some time planning and testing.
Also, don't forget the the heaping mounds of beaurocracy that you must put
up with, whether in the name of a software process or for just plain
corporate BS.
I'm still in college, but I believe this is how it works. :-)
--
Jeffrey S. Sharp
jss(a)subatomix.com
Should programmers be licensed? Sure makes me wonder . . .
Ok, what does it take to really write code and solve programs?
(Unlicensed programer/coder here ). Writing code is easy...
15 Dec
15 Dec
5:33 a.m.
"Jeffrey S. Sharp" wrote:
There's a big difference between writing code to
solve problems and being
a software engineer. Designing, coding, and compiling is only 40% of the
battle. Hopefully you're also spending some time planning and testing.
Also, don't forget the the heaping mounds of beaurocracy that you must put
up with, whether in the name of a software process or for just plain
corporate BS.
You mean like "If we needed it yesterday I'll ask for it
tomorrow"
--
Ben Franchuk --- Pre-historic Cpu's --
www.jetnet.ab.ca/users/bfranchuk/index.html
4:06 p.m.
Based on the investment in time, I'd say coding, compiling, and debugging are
<%5 of the job, and I'm referring to completed programs which, in every
conceivable way, adhere to the specification to which they were designed
completely to the extent that it is humanly, and with the aid of countless
machines, possible to verify. The documentation, which occurs before and after
takes up the remainder of the time. Unfortunately that's what normally is cut
first, and the coding suffers as a result, since the requirements aren't in
written form. Requirements are the set of things which the code must do, and
other than which the code must NOT do.
Dick
----- Original Message -----
From: "Ben Franchuk" <bfranchuk(a)jetnet.ab.ca>
To: <classiccmp(a)classiccmp.org>
Sent: Saturday, December 15, 2001 9:33 AM
Subject: Re: "Geeks" and licensing
"Jeffrey S. Sharp" wrote:
There's a big difference between writing code
to solve problems and being
a software engineer. Designing, coding, and compiling is only 40% of the
battle. Hopefully you're also spending some time planning and testing.
Also, don't forget the the heaping mounds of beaurocracy that you must put
up with, whether in the name of a software process or for just plain
corporate BS.
You mean like "If we needed it yesterday I'll ask for it
tomorrow"
--
Ben Franchuk --- Pre-historic Cpu's --
www.jetnet.ab.ca/users/bfranchuk/index.html
14 Dec
14 Dec
8:22 p.m.
Glen Goodwin wrote:
I've een the same thing happen in broadcasting. Once upon a time when
the FCC had a backbone, the First Class Radiotelephone licence was
required for most engineering jobs. But by 1980 political pressure from
the NAB eliminated this requirement and now anyone with a good selling
job can do just about anything. . . . and usually they can't. Especially
around RF, high voltage and vacuum tubes . . .
When I got mine I was amazed how many people thought it was really
difficult, which it wasn't, if you understood the basics. The
aformentioned 'programmers' sure as h**l don't know the basics as
evidenced by their statements. And I bet none of them have ever hand
coded a computer to do anything productive. They rely on a good
software package to help them develop C code ad nauseum. Thanks, Bill.
Gary Hildebrand
ST. Joseph, MO
From: Christopher Smith <csmith(a)amdocs.com>
(To whit: I worked at one point with a guy who
was convinced that every
operating system in the world was derived in some manner from MS-DOS.
Yes,
that includes the Macintosh operating system too.
"CP/M? What's that?
Unix is based on MS-DOS, right?" The guy was a "programmer.")
(gag, puke)
Well, most of us (except for Tony) have areas that we are not expert in, or
even familiar with. The problem with the fellow you refer to is
1 -- The person who hired him. That person should be disposed of in the
most painful way possible.
2 -- The institution which granted him a degree (if any).
I've also had to work alongside people who managed to scrape their way into
a "programming" job without having "what it takes" to really write
code
*and* solve problems. Don't get me wrong -- I have no degree and don't
think one's required to be a competent analyst/programmer/whatever.
But . . .
Should programmers be licensed? Sure makes me wonder . . .
Glen
00
15 Dec
15 Dec
8:31 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 3156 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20011215/971d3fc5/at…
8326
days inactive
8329
days old
20 comments
14 participants
participants (14)
-
acme_ent＠bellsouth.net -
allain＠panix.com -
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
bpope＠wordstock.com -
chris＠mainecoon.com -
edick＠idcomm.com -
foo＠siconic.com -
ghldbrd＠ccp.com -
hofmanwb＠worldonline.nl -
jpdavis＠gorge.net -
jss＠subatomix.com -
korpela＠ssl.berkeley.edu -
rschaefe＠gcfn.org