Front page | perl.perl5.porters |
Postings from October 1999
RE: What the world really needs [was Detecting RedHat...]
Thread Next
From:
Redford, John
Date:
October 27, 1999 10:37
Subject:
RE: What the world really needs [was Detecting RedHat...]
Message ID:
C139F4D49384D2118EB60008C7A4337B016FAA0A@MSGBOS675NTS.fmr.com
1. Why Not A Database
I think you are approaching the system with a too narrow viewpoint. A modern
machine is not a monolithic entity, it is a landscape of potential
interaction.
My primary "where I do my work" machine is a Solaris 2.6 system with all the
"recommended" patches from Sun. It also has about two hundred additional GNU
and GNU-like software products installed, including GNU cpio, cp, tar, mt,
and diff.
When someone logs into my machine, they have many options. They can use
some, all, or none of the additional non-Sun software I have installed. They
can install other software I do not know about. Within the context of a
single session, they can alter their PATH, LD_LIBRARY_PATH, MANPATH,
PRINTER, TCAT, or ESHELL -- each of which can cause the system to behave in
a distinctly different way.
It is not practical to express the potential combinations of
environment-system interaction within a static database. Many questions --
perhaps all the interesting ones -- can only be answered accurately at the
moment the answer is needed.
2. Can A Verification Algorithm Be Wrong?
A much deeper question is raised when you mention correcting an algorithm.
It may sound odd, but I would say that a verification test is merely proof
that the verification test runs. Any statements about what the verification
test is testing is subject to the same flaws as the original systems being
tested.
In other words, I wouldn't say "I need symlinks, so I'll run the symlink
tester", but rather "My program's symlink usage works when the symlink
tester works". Regardless of how well the testing algorithm models some
supposed objective reality, so long as it gives useful results, it is a
useful test. If one finds a "bug" in the test algorithm that would lead to
previously 'false' cases becoming 'true', it would require careful thought
before correcting the "bug". It just might be that those 'false' cases truly
indicate potential failure for some application which makes use of that
test. Converting 'true' cases to 'false' would merely break existing code --
if someone was bothering to test the condition in the first place, it can be
assumed that they have a graceful exit handler in place.
--
John Redford
AKA GArrow
-----Original Message-----
From: Tom Horsley [mailto:Tom.Horsley@mail.ccur.com]
Sent: Wednesday, October 27, 1999 10:45 AM
To: Joshua N Pritikin
Cc: John.Redford@fmr.com; Tom.Horsley@mail.ccur.com;
perl5-porters@perl.org
Subject: Re: What the world really needs [was Detecting RedHat...]
>> So you can never say "This is <XXX>" and say anything ultimately
meaningful.
>> However, you can say "This is this." Without regard to what any piece of
>> documentation says, you have the system and can examine it. One may test
the
>> 'features' of the system empirically and compare the computed results
with
>> expectations. Then you have an accurate description of what you have ...
>
>Agree 100%.
Curiously enough, I also agree with this. It is, in fact, the whole point.
*I* may "test the system empirically and compare the computed results with
expectations", a shell script developed on some other computer cannot. It
isn't smart enough. It doesn't know the questions to ask on this system and
is unable to deduce the proper trail to follow when it can't figure out the
answer.
Once I discover and correct the flaw in the database that describes my
system, the next piece of portable software that I try to build stands a
much better chance of working if it uses the database.
On the other hand, if it is just using some random variation on the same old
shell script that doesn't know the answer, the next piece of software won't
be any simpler to port than the last piece...
And it is much simpler to fix an incorrect statment in a collection of
statements than it is to fix an incorrect algorithm in a twisty maze
of shell script, especially when you need to make sure the fix won't
break the script on some other machine.
--
Tom.Horsley@mail.ccur.com \\\\ Will no one rid me of
Concurrent Computers, Ft. Lauderdale, FL \\\\ this troublesome
Me: http://home.att.net/~Tom.Horsley/ \\\\ autoconf?
Project Vote Smart: http://www.vote-smart.org \\\\ !!!!!
Thread Next