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

[jim]

this is my whimsical reply to rick, not to 
be taken seriously by others (nor even rick). 


On Mon, 2008-11-24 at 19:07 -0800, Rick Moen wrote:
> 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 use the neanderthal way in all things if i 
can. unfortunately, the hosting facility doesn't 
allow shell access, ftp only (i use CLI ftp, 
works fine). 
   also unfortunate that the web site is ornate, 
done by someone else. i can't see the change 
without having flash or some equivalent working. 
   i can do the work on my machine, bypassing 
the flash intro stuff, in the neanderthal way. 
but i gotta verify it once it's uploaded, hence 
must have flashish capability (and gnash failed 
to work with this site). 


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

and CLI tools are generally richer and more robust. 


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

fu! it's spelled fu! (see below)  


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

i like my manpage simile. 


> > * you misspelled fu 
> 
> Huh???  {floored}
> I might be misreading the above.  Were you thinking I'd just been
> somehow attempting to tell you off?

no, this is a joke on my part. remember the original 
spelling of the acronym snafu? "situation normal..." 
early coders also referred to fu, later personages 
re-spelled it as foo. i'm an earlier personage. 

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

   understood. same company, same vp of engineering, same 
corporate culture. i know different teams can differ a lot. 


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

mine look like you designed them, only maybe 
after a couple of glasses of wine.