In general, I agree with what you're asking. The more information that
*most* of our customers have the more they can help themselves. This goes
especially for Beta code, and any debug that would come out of it.
However, we do release and document many debug features. There are dozens
of debug commands that have made their way into the command line from,
shall we say, somewhat obscure origins. There are probably many more that
never make it. You say you don't want to have to look at the code. Do you
want to read chip datasheets to decode the debugging information as well?
That is what many of the removed debug statements will show you.
Believe me, we understand that the more information you get the less you
bug us 8-) That's one reason we're doing things like the PPP Decoder Ring
and other similar pilots. And we will provide appropriate debugging tools
at the command line as well.
At 03:50 PM 5/7/98 -0700, Mark Peugeot wrote:
>MZ,
> You will probably notice that I have not whined about the stability
>or problems apparent in 3.8b15. I do however think that the product should
>be fully documented. This is especially important when dealing with Beta
>code, which for better or worse I have choosen to run. (In reality it works
>well for me.) If I had a problem with Beta code, I would report it, but if
>it was impacting my customers more than it was causing greater good I would
>immediately back out, not whine.
> I guess the time old tradition of looking at the code will go on,
>but I should not have to do that. Livingston Techs and Engineers are busy
>enough without users who could help themselves calling them. Documenting
>debug features would go a long way to making this possible. While many users
>are not technical, quite a few are, and those who understand the lower
>levels of operation should not have to hunt for a needle in a haystack.
> Maybe a separate document would solve the dilema of users having to
>much to worry about, and at the same time provide some of use eggheads the
>information we need to tell where problems may lie, especially those of us
>who run beta code.
>
>Mark Peugeot
>Network One
>
>>
>> Bad idea. Most users are NOT engineers, and way too many users have the
>> need to turn knobs they don't understand. Some of the hidden commands
>> are only used by one person - the engineer who put them there. And the
>> engineers have better things to do that try to explain what they are there
>> for to people who aren't meant to be using them in the first place.
>>
>> It is like when people found 'attach' before it was released and it would
>> crash a PM fairly routinely. People whined and complained about the
>> instability - even after being told it wasn't meant to be used yet in the
>> first place! It is bad enough when people demand an issue in a beta be
>> fixed because it is hurting their production machines - after being warned
>> that if they put it on production machines it is their risk. If users
>> can't grasp the meaning of 'beta', forget engineering commands.
>>
>> The majority of users these days are NOT highly technical. Give them a
>> good way to shoot themselves in the foot and they will - and then they'll
>> blame Lucent for it.
>>
>> If someone who is skilled enough to dig commands out of a binary wants to
>> play with them it is expected that they realize they are playing with fire
>> and if they get burned they'll go 'oops, better not do that again' and move
>> on.
>>
>> -MZ
>> --
>> <URL:mailto:megazone@megazone.org> Gweep, author, webmaster, human
being, me
>> "A little nonsense now and then, is relished by the wisest men"
781-788-0130
>> <URL:mailto:megazone@gweep.net> <URL:http://www.megazone.org/> Hail
Discordia!
>> -
>> To unsubscribe, email 'majordomo@livingston.com' with
>> 'unsubscribe portmaster-users' in the body of the message.
>> Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>
>>
>
>-
>To unsubscribe, email 'majordomo@livingston.com' with
>'unsubscribe portmaster-users' in the body of the message.
>Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>
>
andy
++++
NOC Advocate andy@livingston.com
Lucent Technologies, Remote Access Business Unit (510)737-2151
4464 Willow Road http://www.livingston.com
Pleasanton, CA 94588 http://www.lucent.com
-
To unsubscribe, email 'majordomo@livingston.com' with
'unsubscribe portmaster-users' in the body of the message.
Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>