Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Business politics and software development
81 views
Skip to first unread message
J. Leslie Turriff
May 12, 2013, 8:04:41 PM5/12/13
to
This is an interesting exposition on the subject. I suppose that this is
unavoidable in any business that produces large software systems.
http://blog.zorinaq.com/?e=74
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
unavoidable in any business that produces large software systems.
http://blog.zorinaq.com/?e=74
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
DASDBILL2
May 13, 2013, 8:57:34 AM5/13/13
to
I have a friend who used to work for Microsoft in the area of performance monitoring of the operating system itself. He was laid off three years ago. Microsoft is more interested in new whiz-bang features and components than in performance improvement. I guess their thinking is that the hardware developers will always find ways to speed up the CPU and then complaints about the software's performance will go away for a few more years.
Bill Fairchild
Franklin, TN
Bill Fairchild
Franklin, TN
John McKown
May 13, 2013, 9:07:52 AM5/13/13
to
Sounds like many of our users. Gotta have the fancy bling. If it needs
rebooting , that's just part of the cost. Same in the food industry. Tasty
is better than healthy.
rebooting , that's just part of the cost. Same in the food industry. Tasty
is better than healthy.
John Gilmore
May 13, 2013, 10:46:53 AM5/13/13
to
Plus ça change, plus c'est la même chose.
This is a pervasive mainframe problem too.
I have not heard the term used recently, but for obvious reasons IBM
marketing people used to prize what they called 'hardware hawks' very
highly.
A hardware hawk was a customer executive whose unvarying response to
any and all problems was to throw more hardware at them.
In the short term this tactic often works. In the slightly longer
term its use yields systems that become progressively harder and
harder to maintain and all but impossible to replace.
Looking at the litany of vulnerabilities documented in the posts I
receive from us-cert.gov has convinced me that almost every
application and all systems software needs to be rewritten ab initio.
They were designed, to the extent that they were designed, in a
simpler time. They reflect the assumption that most of their users
will be benign, with only a few being prerternaturally stupid and a
few others bent on theft.
The only appropriate assumption now is that all users are bent upon
subverting and/or destroying the systems they use.
This assumption is of course hyperbolic: some users will always be too
lazy or too unimaginative to do much damage. It is nevertheless
necessary.
The work of Rufus Isaacs on aircraft-collision avoidance, which I have
mentioned here before, is highly instructive. He found that the only
safe collision-avoidance strategies for aircraft A in an air space
also occupied by aircrafts B, C, D, . . . were based upon the
assumption they were hellbent on colliding suicidally with it.
This weekend, for the first time in a very long time, I looked at a
stream of problem reports for a compiler. (It was a C compiler, but
that is not important.) What struck me about them was that most of
those that involved syntactically constructs reflected 'bizarre' uses
of the language that would not occur to anyone who was proficient in
it.
The only way to cope with such deficiencies is to generate
syntactically correct constructs, however absurd,
mechanically/programmatically for testing. Here, as elsewhere, malice
and ignorance are often very difficult to disentangle.
John Gilmore, Ashland, MA 01721 - USA
This is a pervasive mainframe problem too.
I have not heard the term used recently, but for obvious reasons IBM
marketing people used to prize what they called 'hardware hawks' very
highly.
A hardware hawk was a customer executive whose unvarying response to
any and all problems was to throw more hardware at them.
In the short term this tactic often works. In the slightly longer
term its use yields systems that become progressively harder and
harder to maintain and all but impossible to replace.
Looking at the litany of vulnerabilities documented in the posts I
receive from us-cert.gov has convinced me that almost every
application and all systems software needs to be rewritten ab initio.
They were designed, to the extent that they were designed, in a
simpler time. They reflect the assumption that most of their users
will be benign, with only a few being prerternaturally stupid and a
few others bent on theft.
The only appropriate assumption now is that all users are bent upon
subverting and/or destroying the systems they use.
This assumption is of course hyperbolic: some users will always be too
lazy or too unimaginative to do much damage. It is nevertheless
necessary.
The work of Rufus Isaacs on aircraft-collision avoidance, which I have
mentioned here before, is highly instructive. He found that the only
safe collision-avoidance strategies for aircraft A in an air space
also occupied by aircrafts B, C, D, . . . were based upon the
assumption they were hellbent on colliding suicidally with it.
This weekend, for the first time in a very long time, I looked at a
stream of problem reports for a compiler. (It was a C compiler, but
that is not important.) What struck me about them was that most of
those that involved syntactically constructs reflected 'bizarre' uses
of the language that would not occur to anyone who was proficient in
it.
The only way to cope with such deficiencies is to generate
syntactically correct constructs, however absurd,
mechanically/programmatically for testing. Here, as elsewhere, malice
and ignorance are often very difficult to disentangle.
John Gilmore, Ashland, MA 01721 - USA
Charles Mills
May 13, 2013, 12:49:57 PM5/13/13
to
> They reflect the assumption that most of their users will be benign, with
only a few being preternaturally stupid
I think most systems have been written with the assumption that most users
were "folks like us." (Trusted, professional, benign, reasonably
knowledgeable.)
Now nearly every system is to some extent accessible to every bad guy in a
basement in Russia.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On
Behalf Of John Gilmore
Sent: Monday, May 13, 2013 10:47 AM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Business politics and software development
Plus �a change, plus c'est la m�me chose.
This is a pervasive mainframe problem too.
I have not heard the term used recently, but for obvious reasons IBM
marketing people used to prize what they called 'hardware hawks' very
highly.
A hardware hawk was a customer executive whose unvarying response to any and
all problems was to throw more hardware at them.
In the short term this tactic often works. In the slightly longer term its
use yields systems that become progressively harder and harder to maintain
and all but impossible to replace.
Looking at the litany of vulnerabilities documented in the posts I receive
from us-cert.gov has convinced me that almost every application and all
systems software needs to be rewritten ab initio.
They were designed, to the extent that they were designed, in a simpler
time. They reflect the assumption that most of their users will be benign,
with only a few being prerternaturally stupid and a few others bent on
theft.
The only appropriate assumption now is that all users are bent upon
subverting and/or destroying the systems they use.
This assumption is of course hyperbolic: some users will always be too lazy
or too unimaginative to do much damage. It is nevertheless necessary.
Paul Gilmartin
May 13, 2013, 1:05:14 PM5/13/13
to
On Mon, 13 May 2013 10:46:45 -0400, John Gilmore wrote:
>
>The work of Rufus Isaacs on aircraft-collision avoidance, which I have
>mentioned here before, is highly instructive. He found that the only
>safe collision-avoidance strategies for aircraft A in an air space
>also occupied by aircrafts B, C, D, . . . were based upon the
>assumption they were hellbent on colliding suicidally with it.
>
The John Madden / Isaac Asimov corollary:
>
>The work of Rufus Isaacs on aircraft-collision avoidance, which I have
>mentioned here before, is highly instructive. He found that the only
>safe collision-avoidance strategies for aircraft A in an air space
>also occupied by aircrafts B, C, D, . . . were based upon the
>assumption they were hellbent on colliding suicidally with it.
>
If any of B, C, D, has a higher maximum airspeed and higher
operational ceiling than A, there is no safe strategy for A.
>This weekend, for the first time in a very long time, I looked at a
>stream of problem reports for a compiler. (It was a C compiler, but
>that is not important.) What struck me about them was that most of
>those that involved syntactically constructs reflected 'bizarre' uses
>of the language that would not occur to anyone who was proficient in
>it.
>
(Or is that what you meant to say?)
>The only way to cope with such deficiencies is to generate
>syntactically correct constructs, however absurd,
>mechanically/programmatically for testing. Here, as elsewhere, malice
>and ignorance are often very difficult to disentangle.
>
-- gil
John Gilmore
May 13, 2013, 2:20:54 PM5/13/13
to
Paul Gilmartin wrote:
<begin extract>
I said what I meant to say. At least some of the developers of a
compiler for language L are usually proficient in it. In my
experienced highly nuanced tests of notional 'misuse' of a language by
those proficient in it are usually made by the developers of a a
compiler for it. (This sort of thing can even, and in my view often
does, go too far in the name of 'strong typing'.)
What get short shrift are tests of constructs that would never occur
to someone who is proficient in language L.
Anachronistic criticism of past design decisions is not, of course,
what I had in mind. The inventor of the nul-delimited string cannot
reasonably be blamed for the misuses of it that hackers now make.
Those who continue to externalize them can properly and should be so
blamed. We live in an irrevocably changed world. There will be no
return to Arcadia.
John Gilmore, Ashland, MA 01721 - USA
<begin extract>
Plus those that would occur only to someone who was proficient in it.
(Or is that what you meant to say?)
</end extract>
(Or is that what you meant to say?)
I said what I meant to say. At least some of the developers of a
compiler for language L are usually proficient in it. In my
experienced highly nuanced tests of notional 'misuse' of a language by
those proficient in it are usually made by the developers of a a
compiler for it. (This sort of thing can even, and in my view often
does, go too far in the name of 'strong typing'.)
What get short shrift are tests of constructs that would never occur
to someone who is proficient in language L.
Anachronistic criticism of past design decisions is not, of course,
what I had in mind. The inventor of the nul-delimited string cannot
reasonably be blamed for the misuses of it that hackers now make.
Those who continue to externalize them can properly and should be so
blamed. We live in an irrevocably changed world. There will be no
return to Arcadia.
John Gilmore, Ashland, MA 01721 - USA
Shmuel Metz , Seymour J.
May 16, 2013, 10:26:01 PM5/16/13
to
In
<CAE1XxDERhiZuMekfvC2GA1_a...@mail.gmail.com>,
on 05/13/2013
least was appalled when C first came out.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2 <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
<CAE1XxDERhiZuMekfvC2GA1_a...@mail.gmail.com>,
on 05/13/2013
at 02:20 PM, John Gilmore <jwgl...@GMAIL.COM> said:
>Anachronistic criticism of past design decisions is not, of course,
>what I had in mind. The inventor of the nul-delimited string cannot
>reasonably be blamed for the misuses of it that hackers now make.
You didn't need hindsight to recognize it as a bad decision. I at
>Anachronistic criticism of past design decisions is not, of course,
>what I had in mind. The inventor of the nul-delimited string cannot
>reasonably be blamed for the misuses of it that hackers now make.
least was appalled when C first came out.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2 <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
John Gilmore
May 17, 2013, 8:23:27 AM5/17/13
to
The unfortunate decision was Ritchie's original one to treat character
strings as arrays of single characters.
All this was part of an episteme that viewed smallness/minimality and
notional portability as highly desirable, crucial language
characteristics. They are, of course, appealing; but they are also
absurd. Statement-level procedural languages only cease to grow when
they cease to be used, and C is now a behemoth too.
This understood, it is still possible to have some sympathy for those
who confronted the task of 'extending' C to provide support for
varying-length strings. The PL/I halfword current-length prefix was
not available to them, or at least they did not think that it was.
They chose to use a string of 'conceptually unlimited' length and an
end-of-string delimiter, nul or x'00', instead. The result, never
perspicuous, proved to be a storage-management nightmare. Much worse,
it opened up a Pandora's box of security troubles that will be with us
for years to come; but it is not clear how else the original design
deficiency could have been remedied.
I retrospect it is clear that the remedy was worse than the deficiency
it attempted to make good. It would have been better to do string
processing in arrays, as was done in FORTRAN IV; but this was not
obvious at the time, largely, I suspect, because it was not understood
just how FORTRAN-like C is.
John Gilmore, Ashland, MA 01721 - USA
strings as arrays of single characters.
All this was part of an episteme that viewed smallness/minimality and
notional portability as highly desirable, crucial language
characteristics. They are, of course, appealing; but they are also
absurd. Statement-level procedural languages only cease to grow when
they cease to be used, and C is now a behemoth too.
This understood, it is still possible to have some sympathy for those
who confronted the task of 'extending' C to provide support for
varying-length strings. The PL/I halfword current-length prefix was
not available to them, or at least they did not think that it was.
They chose to use a string of 'conceptually unlimited' length and an
end-of-string delimiter, nul or x'00', instead. The result, never
perspicuous, proved to be a storage-management nightmare. Much worse,
it opened up a Pandora's box of security troubles that will be with us
for years to come; but it is not clear how else the original design
deficiency could have been remedied.
I retrospect it is clear that the remedy was worse than the deficiency
it attempted to make good. It would have been better to do string
processing in arrays, as was done in FORTRAN IV; but this was not
obvious at the time, largely, I suspect, because it was not understood
just how FORTRAN-like C is.
John Gilmore, Ashland, MA 01721 - USA
John McKown
May 17, 2013, 8:35:03 AM5/17/13
to
C doesn't much seem like an HLL to me. Perhaps more of an MLL (Middle
Level Language). I've also heard it called sumething like a structured
assembler language. And, like assembler, it doesn't protect you from
yourself. It is simple to overrun a string's area in both assembler
and C if you aren't careful. Even if you implement something like
PL/I's strings. For best protection against this sort of thing, I
thing the AS/400 (S/38?) and its descendant are likely the best
choice. I don't think it is even theoretically possible to overflow an
objects defined area. The millicode equivalent make it impossible.
TIMI Ithe iSeries defined archetecture) is fascinating to me.
--
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?
Maranatha! <><
John McKown
Level Language). I've also heard it called sumething like a structured
assembler language. And, like assembler, it doesn't protect you from
yourself. It is simple to overrun a string's area in both assembler
and C if you aren't careful. Even if you implement something like
PL/I's strings. For best protection against this sort of thing, I
thing the AS/400 (S/38?) and its descendant are likely the best
choice. I don't think it is even theoretically possible to overflow an
objects defined area. The millicode equivalent make it impossible.
TIMI Ithe iSeries defined archetecture) is fascinating to me.
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?
Maranatha! <><
John McKown
John Gilmore
May 17, 2013, 9:02:31 AM5/17/13
to
John McKown's notion that C is a middle-level language has merit.
In some respects it is. Better, perhaps, it can be used like assembly
language; and when it is I have heard the results described as having
"all of the expressive power and all of the portability of assembly
language".
In the hands of quondam COBOL programmers it can also, unsurprisingly,
be very COBOL-like.
In some respects it is. Better, perhaps, it can be used like assembly
language; and when it is I have heard the results described as having
"all of the expressive power and all of the portability of assembly
language".
In the hands of quondam COBOL programmers it can also, unsurprisingly,
be very COBOL-like.
Lloyd Fuller
May 17, 2013, 10:24:55 AM5/17/13
to
You have to look at where C was originally designed to run. It was designed for
the DEC PDP8. Those were SMALL in resources machines. Later versions of C were
built on the PDP11s, but Richie and crew started out on the PDP8. And, yes, C
was designed to be a middle-level language.
During that time, new CPU designs were popping up all over the place. The
problem was moving things to them: things like compilers and assemblers as well
as applications that were written in those compiler languages. So the thought
was to design a language that would be quickly portable and easy to write for a
new platform.
Lloyd
----- Original Message ----
From: John Gilmore <jwgl...@GMAIL.COM>
To: IBM-...@LISTSERV.UA.EDU
Sent: Fri, May 17, 2013 9:02:30 AM
Subject: Re: Business politics and software development
the DEC PDP8. Those were SMALL in resources machines. Later versions of C were
built on the PDP11s, but Richie and crew started out on the PDP8. And, yes, C
was designed to be a middle-level language.
During that time, new CPU designs were popping up all over the place. The
problem was moving things to them: things like compilers and assemblers as well
as applications that were written in those compiler languages. So the thought
was to design a language that would be quickly portable and easy to write for a
new platform.
Lloyd
----- Original Message ----
From: John Gilmore <jwgl...@GMAIL.COM>
To: IBM-...@LISTSERV.UA.EDU
Sent: Fri, May 17, 2013 9:02:30 AM
Subject: Re: Business politics and software development
Paul Gilmartin
May 17, 2013, 11:08:40 AM5/17/13
to
On Fri, 17 May 2013 07:24:48 -0700, Lloyd Fuller wrote:
>You have to look at where C was originally designed to run. It was designed for
>the DEC PDP8. Those were SMALL in resources machines. Later versions of C were
>built on the PDP11s, but Richie and crew started out on the PDP8. And, yes, C
>was designed to be a middle-level language.
>
Wikipedia tends to confirm my recollection of PDP-7:
>You have to look at where C was originally designed to run. It was designed for
>the DEC PDP8. Those were SMALL in resources machines. Later versions of C were
>built on the PDP11s, but Richie and crew started out on the PDP8. And, yes, C
>was designed to be a middle-level language.
>
http://en.wikipedia.org/wiki/C_%28programming_language%29#History
... not quite as restrictive as PDP-8. Hmmm... IIRC, PDP-7 was ones-complement
word-addressed machine (18-bit words). I wonder when C acquired its dependency
on 2's complement and addressing storage by characters?
-- gil
Kirk Talman
May 17, 2013, 2:30:33 PM5/17/13
to
IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> wrote on
05/17/2013 08:23:19 AM:
> From: John Gilmore <jwgl...@GMAIL.COM>
> ... it was not understood
ranks with: C: the only language that is self grading
-----------------------------------------
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying,
or unauthorized use of this information, or the taking of any
action in reliance on the contents of this information is strictly
prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original
message. Thank you
05/17/2013 08:23:19 AM:
> From: John Gilmore <jwgl...@GMAIL.COM>
> ... it was not understood
> just how FORTRAN-like C is.
great putdown
ranks with: C: the only language that is self grading
-----------------------------------------
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying,
or unauthorized use of this information, or the taking of any
action in reliance on the contents of this information is strictly
prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original
message. Thank you
Shmuel Metz , Seymour J.
May 17, 2013, 3:17:51 PM5/17/13
to
In
<CAAJSdjik=vxTSPO6fnpBCeoeu_zvh...@mail.gmail.com>,
on 05/17/2013
>I thing the AS/400 (S/38?) and its descendant are likely the best
>choice.
My understanding is that the AS/400 lacks the capability-based
architecture of the S/38.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2 <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
<CAAJSdjik=vxTSPO6fnpBCeoeu_zvh...@mail.gmail.com>,
on 05/17/2013
at 07:34 AM, John McKown <john.arch...@GMAIL.COM> said:
>C doesn't much seem like an HLL to me. Perhaps more of an MLL
>(Middle Level Language). I've also heard it called sumething like
>a structured assembler language.
IMHO it's lower level than a decent assembler.
>C doesn't much seem like an HLL to me. Perhaps more of an MLL
>(Middle Level Language). I've also heard it called sumething like
>a structured assembler language.
>I thing the AS/400 (S/38?) and its descendant are likely the best
>choice.
architecture of the S/38.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2 <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
Mike Schwab
May 17, 2013, 4:17:45 PM5/17/13
to
First written on the PDP-11, inspired by the assembler rework needed
to move from the PDP-7.
--
http://en.wikipedia.org/wiki/C_%28programming_language%29#Early_developments
3rd paragraph, sentence 1-2:
The original PDP-11 version of the Unix system was developed in
assembly language. By 1973, with the addition of struct types, the C
language had become powerful enough that most of the Unix kernel was
rewritten in C.
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
to move from the PDP-7.
--
http://en.wikipedia.org/wiki/C_%28programming_language%29#Early_developments
3rd paragraph, sentence 1-2:
The original PDP-11 version of the Unix system was developed in
assembly language. By 1973, with the addition of struct types, the C
language had become powerful enough that most of the Unix kernel was
rewritten in C.
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
Ted MacNEIL
May 17, 2013, 4:37:36 PM5/17/13
to
>C: the only language that is self grading
ERROR! ERROR! Statement inaccurate!
C's predecessor was B derived from BCPL (Basic Computer Programming Language).
I used all three in University in the 1970's.
Also, two experimental languages in the Waterloo Portability Lab (Eh and Z - pronounced Zed [in Canada, after all).
-
Ted MacNEIL
eama...@yahoo.ca
Twitter: @TedMacNEIL
John Gilmore
May 17, 2013, 5:19:14 PM5/17/13
to
I don't know B; I do know and admire BCPL, and C resembles it only to
the extent that a butterfly resembles a tree. BCPL is not entirely
type-free; it is very weakly typed indeed; and C is strongly, even
intrusively, typed.
John Gilmore
the extent that a butterfly resembles a tree. BCPL is not entirely
type-free; it is very weakly typed indeed; and C is strongly, even
intrusively, typed.
John Gilmore
J. Leslie Turriff
May 17, 2013, 9:21:09 PM5/17/13
to
On Friday 17 May 2013 07:23:19 John Gilmore wrote:
> Statement-level procedural languages only cease to grow when
> they cease to be used, and C is now a behemoth too.
Too true; just look at ooRexx versus the original mainframe Rexx.
> Statement-level procedural languages only cease to grow when
> they cease to be used, and C is now a behemoth too.
Leslie
Scott Ford
May 18, 2013, 4:54:01 PM5/18/13
to
Push, especially everyone in the new programming thinking,berthing and eating java
Scott ford
www.identityforge.com
from my IPAD
'Infinite wisdom through infinite means'
Scott ford
www.identityforge.com
from my IPAD
'Infinite wisdom through infinite means'
Shmuel Metz , Seymour J.
May 20, 2013, 11:23:45 AM5/20/13
to
In
<CAE1XxDF41HF42mKUgysQ9ee1...@mail.gmail.com>,
on 05/17/2013
far as you can get from strong typing.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2 <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
<CAE1XxDF41HF42mKUgysQ9ee1...@mail.gmail.com>,
on 05/17/2013
at 05:18 PM, John Gilmore <jwgl...@GMAIL.COM> said:
>I don't know B; I do know and admire BCPL, and C resembles it only to
>the extent that a butterfly resembles a tree. BCPL is not entirely
>type-free; it is very weakly typed indeed; and C is strongly, even
>intrusively, typed.
FSVO strongly. The intermingling of arrays and pointers is about as
>I don't know B; I do know and admire BCPL, and C resembles it only to
>the extent that a butterfly resembles a tree. BCPL is not entirely
>type-free; it is very weakly typed indeed; and C is strongly, even
>intrusively, typed.
far as you can get from strong typing.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2 <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
0 new messages