[sf-lug] (forw) Re: todays meeting at enchanted cafe

Rick Moen rick at linuxmafia.com
Mon Jan 3 14:35:26 PST 2011


Quoting Bobbie Sellers (bliss at sfo.com):
> Quoting Rick Moen (rick at linuxmafia.com):
> 
> > If you just use the chown/chgrp commands, you can fix UID and GID
> > changes really easily.
>
> I have problems with the grammar of the commands.  In other words I
> don't get it.  I prefer to work through the gui tools because though I
> may have to go around the barn to get the job done, the job gets done,

What tools you use is entirely up to you, of course.  Use what works for
you.  

When you say 'the GUI tool', you are exposing part of your problem:

1.  There is no one set of 'the GUI tools'.  You didn't bother to
mention which set of such tools you have in mind, but, no matter which
one it is, I can pretty much guarantee that a large fraction of the
Linux users you're talking to won't have them installed and doesn't use
them.  Also, I've noticed that users who speak as you do, most often,
don't even know the correct name of the 'GUI tool' they are trying to
talk about, and don't know how to determine the name of a running
process, and therefore cannot look it up.

So, even if I wanted to install the 'GUI tool' of your choice in order
to tell you exactly what to do, using it, the fact that you don't (and
probably can't) tell me its real name is a serious obstacle.

2.  By contrast, basic tools like chmod/chgrp have a number of
advantages to people who are attempting to give you help:

a) They are universally available.
b) Unlike essentially all 'GUI tools', they do not suppress diagnostic
   output (that might be crucial data).
c) They are reliable, deterministic in their behaviour, and not 
   rendered brittle by huge complex dependency trees.
d) I can tell you verbatim commands to copy and paste to your 
   shell console, and ask you to please copy and paste back the 
   verbatim resulting output, and, _if_ you comply with that request,
   I can rest assured that I am hearing back from you precisely what
   happened, i.e., the raw data, and not your _interpretation_ of 
   events (e.g., 'it failed to be able to access my home directory').
   The tendency of novice users to post their _interpretations_ rather
   than raw diagnostic data is one of the biggest sources of wasted
   time in these situations, in my experience.


So, you're perfectly welcome to insist on accepting help only from
people who don't expect you to do bash shell command operations.
However, I can tell you from very long experience that you'll thereby
get a great deal less help, and a great deal less-effective help, in
part because pretty much all of your would-be helpers who've been around
the block a time or two have learned to be wary of wasting time catering
to 'I prefer to work through the GUI tools' people's likes and dislikes.
Basically if 'Open a shell console, paste this command to it,

   sudo bash && chown bliss:bliss /home/bliss && ls -l /home/bliss

and paste back into a response posting the resulting output' is too much
trouble or too traumatic for you, then there are plenty of other people
I can help, where I have better expectation of the user succeeding, and 
better expectation of rendering long-term help to public knowledge.


Speaking of public knowledge, I wrote:

    Forwarding back to the public discussion.

This is something I've spoken of before, for quite a few years in a row,
with no obvious improvement to your habits.  Others may feel
differently, but I post here publicly in order to benefit the Linux
community and to repay the debt of gratitude I owe to those who helped
me learn.  That's a public process for good reasons -- so that many
people, not just you, can benefit from the asking and answering.

Please respect the public process by continuing public threads in
public.  In rare cases where you have some reason for wanting a private
side discussion, you should explain why, rather than just going off into
private without explanation -- which unfortunately looks a lot like
wandering off into private Linux consulting without offering to pay for
it.

Also, I wrote:

   That aside, I cannot tell what 'failed to be able to access' means in
   current context.  Perhaps you mean 'cannot mount'?

That was intended as a polite way of inviting you to explain what you
meant (without coming across as interrogating you).  It'd be nice to
help you with the cited problem, that you apparently encountered with
both your new Kubuntu and new Mandriva installations, but it's difficult
if you are not specific.

If I might make a suggestion:  Many newcomers to Linux find it
convenient to keep a notebook, in either a composition book or a legal
pad (etc.) of things they do and problems they encounter.  Among the
many benefits is that, when you run into problems, you will better be
able to be specific about what you did, and about what then happened.





More information about the sf-lug mailing list