If you (or your peers at work) are not able or willing to retest
and redeliver lsof every time the kernel rev changes, then you
(obviously) do not have a viable plan to include lsof into your
local OpenSolaris builds.
I see that You misunderstood me because I used the word "build".
We *do not* and will most likely *never* use or build OpenSolaris. We are
building internal builds of Solaris 10.
My point was that the requirement to keep it up to date is a
fundamental part of putting it "in" . If you have a commitment
to do that work, then the risks can be managed. Without it,
they can't.
Luckily, I do not have a commitment to do that, and as stated previously, I
will fight tooth and nail to prevent `lsof` from ever going into our Solaris
build. That is, unless the author of `lsof` fixes that utility.
If its architecture/design is such that it can't coexist easily
with the rest of the system, or if it is too chaotic to sustain,
then it follows that it is too chaotic to integrate in the first
place....
Let's just write that our Solaris build goes through a pretty stringent
engineering lifecycle, that's rife with forms, procedures, testing and
workflows. If that reminds you of work at Sun, it's probably not that
farfetched.
_________________________________________________________________
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
