[conspire] Breezy Badger /Netzero

Rick Moen rick at linuxmafia.com
Fri Dec 16 20:09:34 PST 2005


Quoting Daniel Gimpelevich (daniel at gimpelevich.san-francisco.ca.us):

> 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.

No, that's not a problem.  Thanks for stepping in, by the way.

> 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.  Actually, the very task of having to decide what's worth writing
down was, if I remember correctly, really helpful if something of an
extra challenge.

> > 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.

In a way, I was sort of thinking aloud, and looking towards my possible
near-term project of a "So CABAL helped you install Linux.  Now what?" 
document -- which, among other things, would address some of those
tricky points like "How (and why) do I do terminal session capture, and
how do I move files between Linux and Windows?"

But this actually was one of the reasons why I initially used a
composition book -- because it was so low-tech as to not pose additional
challenges while I had my hands full enough with an alien OS, already.

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

~/.bash_history will show you what _you_ typed at the command line -- but
/usr/bin/script records that _plus_ what the computer responded when you
typed at it, in strict event order.

It's frequently very useful to have an absolutely verbatim log of a
terminal session, and /usr/bin/script does exactly that.


> 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.

Eh, you didn't do anything wrong.  ;->

As you said, you were in the unusual situation of knowing a lot more
about John's situation than the rest of us, but I had only the text of
John's request to work with (plus the vague recollection of answering
questions, earlier, about installing the NetZero .deb from Linspire onto
something else).   

Presumably John's going to want to seek help again, and he'll be best
advised to be aware of the best way to ask technical questions, which 
entails among other things telling people what you checked before
posting.

> 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.

Huh?  I'm not sure I'm following you (and I might have been guilty of 
being a little cryptic, myself).  I was saying that "he didn't say"
what kppp succeeded at doing, meaning that the reader is obliged to 
guess if he's to arrive at any conclusions on that score, e.g., "John
must have meant that kppp successfully made the modem dial" or "John
must have meant that kppp successfully secured remote IP transport."

> 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.

Huh, you're right.  I just learned something:

~ $ su -
Password: 
linuxmafia:~# ln -s ttyS0 /dev/anothermodem
linuxmafia:~# ls -al /dev/anothermodem 
lrwxrwxrwx  1 root root 5 2005-12-16 19:57 /dev/anothermodem -> ttyS0
linuxmafia:~# 

I've always been really careful when creating symlinks to use explicit 
pathing (either absolute or relative, depending), and had wrongly
assumed that the shell would expand any unqualified filename used as the
first argument, using as default path the current directory.  Wow, and I
never even tested that assumption.

I still do prefer links that have more path information in them, though.

> 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.

Eh, don't forget:  I was unaware that you were fully briefed, and
assumed John was addressing all of the mailing list's membership.

> 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.

Actually, my point was a broader one:  If you have some idea where to
look for documentation before posting, it improves your help request to
mention where you looked.  Equally, if you have _no_ idea where to look, 
it improves your help request to mention that fact, because at least it 
stresses that you tried -- and people will probably then advise you
about where to look, as a bonus.

I should hasten to add, again, for John's benefit, that I'm not trying
to denigrate what he wrote; I'm just trying to help give advice about 
future help requests, to make them easier to assist with, and thus a less
frustrating experience for both John and his future helpers.






More information about the conspire mailing list