[osol-discuss] Re: Shipping "lsof" with Solaris ? / was: Re: problem with /t

[a b]

>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/