[sf-lug] jim unsatisfied with apt-get and adobe flash and other things

[Rick Moen]

Quoting jim (jim at well.com):

> * i'm in this because i'm trying to help an impoverished 
> musician avoid spending $100 or more per hour for someone 
> to edit a simple HTML file. to verify my work, i have to 
> access her web site, which looks like it was done on 
> windows with windows for windows. haven't dragged out a 
> mac to see if that box sees things correctly. 

Understood.

The Unixey-Neanderthal way of doing it, which I pretty much always use:

1.  Open a shell and a Web browser.  Open the page of interest in the
Web browser.

2.  In the shell, ssh to the Web host.  cd to the directory of interest,
and open the html | PHP | whatever file in vi (or $EDITOR_OF_CHOICE).

3.  Look for the problem.  Come up with what you think is probably the
fix.  Edit.  Save.  Reload page in Web browser.  See if it worked.

4.  If it didn't work, undo the change (nice that vim has infinite
undo!), save, try again.  Iterate until done.

Note that this method is (actually) totally OS-independent.



> * i like CLI, but try sometimes to be a good boy and 
> follow instructions, even GUI, when i'm asking for help 
> (i like help from sf-lug people much better than from 
> gui folks). 

Well, sure.  Nothing against those other thingies particularly, but 
simple command-line tools are always available, always work the same
way, have useful diagnostic output, _and_ lend themselves well to 
useful exchanges of information without error or accidental omission of
crucial fact.

That is, I can say "Here, copy and paste the following command string
into your shell, then copy and past back into a reply e-mail every bit
of output that the shell returns", and be reasonably confident that the
user is going to _actually do_ what I suggest, and _actually post_ the
full, relevant results.

It's extremely difficult to tell people _accurately_ how to use the
detailed features of graphical tools, and you're never sure if what you
hear back is a complete recounting of relevant facts.  The users tend to
wildly flail around and start sending you gobs of screenshots that they 
imagine are relevant (and usually aren't).

Additionally, especially in the GNOME and KDE world, people most often
have no actual idea _what_ graphical tools they're using.  They'll say
things like "The CD-burning thing", or "GNOME menu, Apps, Multimedia, 
CD burning" (or whatever) -- and have no idea whatsoever whether they're
talking about gcombust, brasero, or what-all.  So, even if I wanted to
replicate the relevant part of the user's graphical app set by typing
"apt-get install [foo]", the user cannot tell me what "foo" is.

So, in short, I tend to tell people to use tools that are guaranteed
present on both the user's and my Linux systems, that behave in
predictable ways and can be specified unambiguously, that give useful
diagnostic output, and that are suitable for interactive help in the
sense of being usable without accidental error in what command gets
carried out and in relaying the resulting output.



> * examples help loads. the so-called "arguments:" now look 
> like path specifications to me. 
>    in the file: 
> deb http://linux.csua.berkeley.edu/ubuntu/ hardy main multiverse
> restricted universe
>    on the target system: 
> http://linux.csua.berkeley.edu/ubuntu/dists/hardy/main/binary-i386/Packages.gz
> http://linux.csua.berkeley.edu/ubuntu/dists/hardy/multiverse/binary-i386/Packages.gz
> http://linux.csua.berkeley.edu/ubuntu/dists/hardy/restricted/binary-i386/Packages.gz
> http://linux.csua.berkeley.edu/ubuntu/dists/hardy/universe/binary-i386/Packages.gz

OK, hope that works.


> * you misspelled fu 

Huh???  {floored}

I might be misreading the above.  Were you thinking I'd just been
somehow attempting to tell you off?


> * i agree with some of your comments and accept the rest 
> as i have limited experience in many areas. interesting 
> deprecation of adobe code given the stresses put on 
> postscript

Er, sorry if I was unclear:  I was speaking specifically of the Adobe
[ex-Macromedia] proprietary Flash interpreter, not of Adobe software
generally.  Our context was the Web and Flash, you may recall.

And I'm no "expert".  Look at my Web pages if you want reasons why you
don't want me designing yours.  ;->