With Source code you get nice features like comments, with binaries
there are no comments and no source. I have no aversion to assembly, however
raw hex is not as easy to deal with. You cannot compare reading engineering
documentation with disassembling and reverse engineering a complex product
like the PM3.
Heck anytime Livingston/Lucent feels like releasing source, I'm all
for it... Until then I would like to see complete documentation. Last I
checked we were the customer and we have spent several tens of thousands of
dollars on this product. (Which I might add I am quite happy with)
Mark
>
> First, I should point out again that MegaZone is no longer an employee of
> LuceLiving Technoprises, Inc. While we still value his input on this list,
> he no longer officially or unofficially speaks for the company.
>
> 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/>