James Carlson wrote:
> ... and then what, exactly? Abandon all engineering sense
This sounds like an overreaction.
We /know/ that people depend on the debugging messages found in
syslog so that they can DEBUG their systems. Those messages are
generated so that customers can debug problems on their systems.
They are not in the same class as debugging printf()s in prototype
code, although some coders use the facility for that purpose.
It behooves US to consider how our customers use this resource
so that we can ensure that it best meets their needs.
We /know/ that sysadmins depend on this info. We /know/ that
it is often used as a first step in diagnosing complex problems.
We /know/ that having more information makes it easier to get
a handle on the unknown.
With all that knowledge, why is it that we want to make things
harder for our customers by removing valuable clues from that
repository?
Oh, because it isn't an interface; humans don't matter and it
isn't "pure architecture"?
> In any event, if you think that's the right thing to do because it
> appeals to our customer's needs, then I think we need to have a new
> policy written.
We already have such policies. One comes under the heading "make
Solaris easier to use", another says, in effect, "don't violate
customer's expectations".
We tend to call the latter "being Netscape'd". It doesn't matter
what we intended for an interface - if Netscape glommed onto it,
we can not change it - it effectively is promoted to a Committed
interface.
I wouldn't go so far as to say every message in syslog was now a
Committed API, but I do feel that the diagnostic payload for many
of the messages is, as a human consumable interface, absolutely
Committed. As such, removing significant info from the payload
is a regression, and should be avoided when possible. And, in this
case, it certainly seems to be easily possible.
> Given that they're merely debug messages, I don't really see the
> problem you see.
I used to be able to debug <this> problem, now I can no longer do
so. No APIs, no script breakage, just a system that is not
performing as expected, and an admin who is now less able to
understand the context, pinpoint the problem and fix it.
> I agree that we ought to have historical event information ("errpt"
For better or for worse, ssylog is that medium for many of our customers.
> clean up what is (at best) a haphazard collection of
> semi-usable and mostly-harmful syslog messages.
Mostly harmful? In the scope of this case, how is having
link status, speed and duplex considered harmful - or even
only semi-usable?
-John
