If you postulate that
1) lsof is tightly bound to a particular kernel build,
2) lsof behaves correctly on the kernel it was built for, and
3) lsof will be rebuilt and redelivered in concert with
any and all new kernel builds
then there is no architectural problem with what your colleague suggests.
We tend to call such things "consolidation private dependencies" and
gleefully (for the ARCs at least) delegate the job of keeping the
producer (kernel) and consumer (lsof) working correctly to the people who
are responsible for delivering the consolidation itself...
Of course, if you can't guarantee #2 above, this won't work.
Just having to compile `lsof` every time the kernel rev changes is already
too much overhead. At any given day, there are many issues, feature requests
and fixes to the build, that it is really inefficient to have one more thing
to worry about -- some crappy utility written by an external 3rd party whose
only benefit is to show open ports and files.
Unacceptable, and certainly not worth the overhead. If this was a quality
piece of software, then my stance would be entirely different.
Lastly, if this `lsof` thing is peeking into private kernel structs which
might not be there any more, or work differently, a recompile won't help. So
the whole thing is stillborn. I'm definitely going to fight tooth and nail
to *not* have crappy software like that integrated into the build.
My stance is: either write quality software, or it's time to change the
profession. And that stance of mine goes toward the gentleman that wrote
`lsof` as well!
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
