[lsb-discuss] potential lsb-apache FVT problem and /etc/services
tytso at mit.edu
Wed Aug 23 13:03:30 PDT 2006
On Wed, Aug 23, 2006 at 07:46:46AM -0700, Dan Kohn wrote:
> Anyway, my view is that since no one knows how to write provably
> correct large programs, no amount of testing is ever in principle
> comprehensive enough. But, the more testing we do, we the
> asymptotically closer we can approach the ideal. In this case, it's
> extremely unlikely we'd build a test by default to check for the
> boneheadedness you mention. But, if a real-world LSB Certified
> application displays this level of boneheadedness, and this causes a
> failure on an LSB Certfied distro, I would expect the certified app
> to file a bug with the FSG.
I'm not convinced that the bug report would come from the App vendor.
Today, when I run a Java program that crashes and burns with one JVM,
but it works on another JVM, I don't bother filing a bug report with
either the Java standards committees, or with Sun, or even with the
App vendor. I just heave a heavy sigh, and maybe curse under my
breath, and move on. Maybe I'll tell a slightly more vicious joke
about "Write Once, Run Screaming" at my next presentation, but that's
generally about it.
But let's assume for the sake of argument the app vendor does file a
bug. If we then add test cases which covers it, would effectively be
making their application non-compliant, which might not necessarily be
a good way to win friends in the ISV community, and would probably
simply discouraging them from filing bugs in the first place. This
sounds more like the sort of thing that we should document up front as
good programming practices, perhaps as part of the developer network,
if we don't want to make it an outright application certification
requirement. Basically, we should be proactive, since it's come up
once already --- in our own test scripts!
> Now if your next point is that chroot and appchk do not give us the
> test frameworks we need to implement this bug test, then I would
> agree and say we may need an incremental app test framework. I
> believe this is the point you were trying to make at the last board
The point I was trying to make is that "Certify Once, Run Everywhere"
is _hard_. But while we probably want to avoid making that guarantee,
it would be good to use that as a high-level goal to strive for. I
would much rather tha we never make the marketing claim, but do such a
good job that it is in practice true 99% of the time, than to make the
marketing claim, and then flub it 10% of the time (which is probably
where Java is right now with any non-trivial Java program).
> Or, as Mats said, perhaps we could solve this solely by
> specifying what the certified distro should be returning to a
> function call.
That would be a very Java-esqe way of dealing with the problem, but
I'm pretty sure that doing this (which would mean that dictating the
contents of /etc/services and outlawing the use of Yellow Pages or
LDAP by getservbyname/getportbyname) would go over like a lead
On Wed, 23 Aug 2006 11:16:31 -0700, "Banginwar, Rajesh" wrote:
>There is a tool called lsbdynchk which potentially can help to catch
>these scenarios. The whole idea behind this tool is to validate
>parameters to different LSB specified symbols at run time. The app
>vendor will run their FVT for application with lsbdynchk and see if
>there are any issues. This test is going to be as good as the app FVT,
>so of course may not catch all potential problems. And of course the
>tool today is not complete and need a lot of development to make it
lsbdynchk is definitely a good tool, and will be helpful in some
cases. However, in this case, the problem isn't the input parameters
to the function, but rather needing to make sure that the application
does something sane with the output parameters.
More information about the lsb-discuss