[conspire] Breezy Badger /Netzero

[Daniel Gimpelevich]

Providing validation for John's lack of information was not the purpose of
my last post. The primary purpose was to elaborate on additional
information regarding the problem, since I was in a unique position to do
that. If my choosing to do so in the context of your post was somehow
construed as dismissing or attacking you, I apologize, as I had no
intention of doing that.

On Fri, 16 Dec 2005 17:28:42 -0800, Rick Moen wrote:

[snip]
> Suggestion:  Have the user take notes.  We have spare printer/fax paper,
> for those who didn't think to bring any.
> 
> The smartest thing I ever did, when I was first admining Linux, was keep
> a composition book next to the monitor, and record every significant
> change or configuration or problem in it.  This is _particularly_
> important for those new to Linux, since they're going to be overwhelmed
> with new things to deal with, and cannot be expected to remember things
> you mention as followup items.

Yes, it may be very helpful for John to do that, but I wouldn't want to
decide for him which tidbits are worthy of recording and where.

>> Yes, this would all be ideal, but one has to keep in mind that one of
>> the manifestations of the problem at hand is that he cannot access his
>> e-mail and his Linux installation at the same time.
> 
> So, he can use a text editor, instead.  Save it to a floppy or USB flash
> drive, if necessary.

You or I could do that, or even access his vfat Windows partition
directly, but I think it's a little much to expect those that are new to
have done that without a separate demonstration of only that.

> When I was new to Linux, this is one of the things I used that
> composition book (or other notepaper) for.  These days, for just a
> terminal session, I'd often use "script" to log the session.

And I tend to use ~/.bash_history for that purpose. "All sizes fit one."

[snip]
> See point #4:  He was addressing this mailing list's entire membership
> as a whole, not just you.  And my point was explicitly a broad, pretty
> much universal one, that will aid him in _all_ technical assistance and
> documentation situations.

Again, what I said is meant to supplement what you said, not supplant it.
I know it's a bit nonstandard, but unless I am making a specific reference
to something as being inaccurate (such as the symlink/directory issue
below), I am underscoring what was previously said. I can see how that
could cause confusion, but it can save a lot of excess typing/speaking.

[snip]
>> > Does the Netzero client have a screen for configuration (aka
>> > "preferences")?  Does such a screen show a serial port that is to be
>> > used?  Does it say /dev/modem?
>> 
>> It does have configuration and preferences screens, but the serial port
>> is not among the options. Evidently, that's hardwired to /dev/modem,
>> presumably meaning that Linspire would have its own configuration and
>> preferences screens that control to what that symlink would point on
>> such a system.
> 
> The point was not so much to find out that datum from John, as to ensure
> that he _look_, and mention having done so, in similar situations in the
> future.  I'm attempting to help John learn to fish, instead of just
> giving him a fish.

OK, this is an example of what may have been worthy of John's hypothetical
notes: the results of previous examinations of the configuration and
preferences screens. If a device setting had been there, the likelihood
that it would say /dev/modem is not that great, but still a strong
possibility. In the event that it said something else, it would have been
necessary to explain what the different serial devices available under
Linux are, which would be desirable, but it was getting late at the time
the NetZero client was being tested, so I took a shortcut by going through
the configuration and preferences screens myself and reporting my
conclusions to John. Mea culpa.

>> Obviously, it's not all of that that kppp does, because NetZero is his
>> only ISP, and they don't accept standard PPP logins. The fact that kppp
>> is able to do any of it at all tells me that no kernel modules are at
>> fault, and that's pretty much the only useful information that could be
>> gleaned at this point from an attempt to use kppp.
> 
> Maybe -- but he didn't say so, and it's better that he not obliged
> people to guess.

Perhaps it may be construed as a request to guess, but for it to be an
obligation, there would have to be some kind of if-then based on the
missing information. Although that is not the case here, I can see how
ignoring this relatively extraneous partial information can encourage
partial information where it matters, necessitating requests for
clarification.

[snip]
>> >> I did ln -s tty0 /dev/modem but that didn't work.
>> > 
>> > Again, the biggest problem in the above, even worse than the fact
>> > that it's unclear what directory you were in, and thus unclear where
>> > "tty0" is, and even worse than /dev/tty0 (as opposed to /dev/ttyS0)
>> > making no sense as a serial device, is that we have no way of knowing
>> > what you mean when you say "didn't work".
>> 
>> The current working directory has no bearing on the creation of a
>> symlink, except of course that tab-completion will only work if you are
>> in the directory where the symlink will live.
> 
> The current working directory would _very_ much have a bearing on that
> matter, if he were in the wrong directory.  Thus my point that he should
> _show us_, rather than obliging us to guess that he was _probably_
> somewhere useful when he did that.

It has been my experience that the current directory is not involved in
the creation of symlinks other than as a basis for a relative pathname
provided to the ln command as the final argument only. Please share any
information you may have as to how that could adversely affect a situation
where one is in the wrong directory while issuing an ln command with an
absolute pathname as the final argument, as John showed above, and as
would be most convenient when putting a symlink so close to the top of the
tree.

>> > You were probably really clear in your mind about what you meant, but we
>> > can't read your mind -- or your screen.  ;->
>> 
>> Agreed, but it can't be helped in this case, for reasons I stated above.
> 
> No, Daniel, I know it _can_.  I've devoted a lot of user-assistance
> documentation, including that essay I co-write with Eric Raymond, to
> helping users get around that problem.

I meant it can't be helped that he had already asked for help without the
system in question in front of him at the time, and that IMO the reasons I
stated were justifiable for him to feel the need to do it that way. It
would always be possible to improve upon how one goes about collecting the
information the next time that would be needed by anyone who might step
in to help.

>> > Yes.  What does the accompanying documentation state, about how to
>> > specify the serial port?
>> 
>> I did not detect the presence of any "accompanying documentation" for
>> the NetZero client.
> 
> If John knew of this, then it would have been a good idea to mention it.
> ("Oh, by the way, I _did_ check for any documentation provided with the
> Linspire-oriented .deb I installed the NetZero app from onto my Kubuntu
> box from:  There was nothing in /usr/share/doc/netzero or
> /usr/share/doc/NetZero, and here's what happened when I tried to call up
> a manpage:  [small terminal session]"

I attempted to inquire about exactly this beforehand when I asked John to
report back on the results of "dpkg -c" some time ago. Unfortunately, he
did not know enough to be able to identify anything of interest from that,
such as a "doc" or "man" directory. I was very hasty when, after he had
installed the package, I did a "dpkg -L" to see where it put anything that
would resemble either an executable or a plug-in for one, so there may
still be some documentation of some kind in there somewhere that I didn't
detect. There may also be some kind of documentation on whatever webpage
he downloaded the package from, which I never saw.

[snip]