Tips for installing windows and freeBSD both.. anyone??

Wed Nov 10 17:54:28 UTC 2010

Quoth Rob Farmer on Tuesday, 09 November 2010:
> On Tue, Nov 9, 2010 at 16:09, Robert Bonomi <bonomi at mail.r-bonomi.com> wrote:
> > A GUI provids a  _fixed_ set of predefined operations that it is possible to
> > perform.
> >
> > IF your needs are met =entirely= by the provided operations, great.  If not,
> > you're dead in the water, without any way to accomplish the task.
> 
> How is this different from the command line? If I have a set of data
> and want to sort it in a way that "sort" doesn't have an argument for,
> I'm just as dead in the water as with the GUI. In fact, with the GUI I
> am probably better off because I can see that this is not supported
> within the program, without having to use the documentation.

I don't know how anyone who has done much automation could say such a
thing.  Command lines and pipes offer an exponentially greater set of
possibilities than could ever be presented in a GUI.

I don't know about others, but I spent many years being pro-GUI.  I led
the charge for getting software companies to port their applications to
Windows and use IDEs for development.  It is only recently that I have
come to my senses.

I should have known better.  Back in the 80s when I worked on tax
preparation software, the marketing department wanted a more demoable UI.
So we put a ton of time into creating an interface that looked like the
IRS forms, instead of the one we had where the user keyed in a code that
indicated what line on what form they wanted to input, followed by the
input itself.  When we released this, the marketing department loved it,
our customers' higher-ups thought it was nice, but the actual input
operators hated it.  They were evaluated on how much data they could
enter, not on their enjoyment of the task.
> 
> >
> > GUIs are great for the casual user, because they provide a consistent 'look&feel'
> > acrross the spectrum of apps available under them, and, _generally_ what you
> > learn  from using one application 'generalizes' to any other app that runs under
> > the same GUI.
> >
> > OTOH, a GUI is the worst thing in the world for 'production' use.  It absolutely
> > _kills_ productivity for production tasks.  Automation for productivity _REQUIRES_
> > a complete/comprehensive command  language.
> >
> > With a command language, you can 'automate' a series of operations by simply
> > listing the commands in a file, and feeding that file to the command-processor
> > input.
> >
> > With a GUI there is no way to describe the series of mouse 'motions'/'clicks'/
> > 'double-clicks'/'drags' and keypresses required to perform an operation.
> > 'screen coordinates' are meaningless when a window, or icon, or button, may be
> > 'repositioned' at will.
> >
> > An _individual_ application may allow scripting via an internal command language,
> > but since it is internal to the app, and *not* part of the GUI, it doesn't
> > 'generalize' (no guarantee that similar capability is present in any other app)
> > *AND* is utterly worthless for 'automating' annything that involves more than
> > the single app.
> 
> The CLI doesn't generalize either. How many ways are there to get
> input into a program?
> 
> Some can open files on their own and the file is listed as an argument
> (app input)
> Some have a flag for input, which of course isn't consistent (app -in input)
> Some have multiple flags for input, but which ones work depends on the
> platform/implementation (such as GNU long flags)
> Some need it provided to stdin
> Some can process multiple types of input and are smart enough to
> figure it out on their own while others need to be told what format
> they are being given
> Some can do multiple unrelated things in one instance (file a b) while
> others can't (date +"%H" +"%M")
> Some have historic idiosyncrasies, such as tar defaulting to a tape drive
> Some have other strangeness, like java using aaa.class as input but
> wanting you to list it without the .class extension, whilst javac
> needs the .java extension
> Some are just unusual for no obvious reason, like dd's xx=yy thing
> etc.
> 
> On the other hand, 99% of GUI apps that handle files have a File >
> Open dialog that is provided via a toolkit and works the same
> everywhere.
> 
> >
> > Years ago, I worked at a place that, among other things, produced a reference
> > manual of statistical data for our cusotmers.  About 800 pages of tabular data,
> > practically all of it updated on a staggered, monthly basis.  In the 'early'
> > days (MS-DOS vintage, before 'windows'),  each table was kept in a separate
> > spreadsheet, which _did_ require the redundant entry of a _small_ amount of
> > the data. OTOH two (or more) differnt people could be updatdin different paes
> > simultaneously, regardless of whether or not they were 'related'.  And, at
> > the end of the week, when it was time to send out the weeks 'updates' to the
> > customers,  we had a simple little '.BAT file, each line of which; (a) invoked
> > the spreadsheet  (b) specified the spreadsheet file to use, and (c) invoked
> > a 'start-up macro' that printed the contents of the spreadseet, and exited
> > the program.  Thus, on 'publication' day it was just type in the name of the
> > '.BAT file and everthing got printed.  It took an hour or two -- of _machine_time_
> > that is, but _zero_ human intervention.
> >
> > Fast forward a few years,  a new-hire analyist (in a senior capacity) felt
> > humiliated at having to use this 'old' technology (they had Windows at his
> > prior employer), and made a big enough stink about it that the shop upgraded
> > to Windows just to keep him happy. He proceeds to bundle all 'his' spreadsheets
> > into a single workbook, so that only one person can be working on any of them
> > at any given time, and, on 'publication day', somebody had to sit there and
> > click on each relevant/changed  sheet in the workbook, click on' file', click
> > on print, select the page to print, and click 'doit'.   What a *wonderful*
> > productivity increase!!  We've now got a system that requires a -human- to
> > play babysitttr the machine.  For a couple of -hours- every week.  all to save
> > the complainer from having to enter a few numbers redundantly.
> 
> This isn't really a GUI problem, because the issue is the file format
> changing such that your .bat no longer worked. If you retained the
> original format or fixed the script, it would still work fine.
> 
> However, it still points out one of the biggest problems with the CLI
> - there is a barrier to entry in knowing what commands to run with
> what arguments to make everything work the way you want. File > Print
> was easy for your office staff to figure out. The CLI equivalent
> apparently wasn't.

Perhaps a barrier to entry is a good thing for those who don't know what
they're doing.

> 
> I think many here are underestimating the value of GUIs, because they
> have been running many of these traditional UNIX commands for years
> (or decades) and are also technically oriented enough that learning
> them in the first place wasn't a big deal.
> 
> -- 
> Rob Farmer
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"

-- 
Sterling (Chip) Camden    | sterling at camdensoftware.com | 2048D/3A978E4F
http://camdensoftware.com | http://chipstips.com        | http://chipsquips.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20101110/3b602150/attachment.pgp