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

[Chad Perrin]

On Tue, Nov 09, 2010 at 06:10:54PM -0800, Rob Farmer wrote:
> 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.

It is different in that multiple tools are easily chained together via
the Unix pipeline, whereas a single GUI has to encompass all of the
actions possible to perform at a single time, thus resulting in a far
more narrow set of limitations on what can reasonably be provided as
options.  In fact, a set of CLI filters linked together by the Unix
pipeline (or even a DOS pipeline, at least in theory) is essentially
infinitely extensible to provide surprising levels of automation
customizability that might astonish the earlier creators of some of the
older tools being used, while an extension system for a GUI application
necessarily has to predefine what is possible, and obfuscates the inner
workings of the extended application behind designs that are largely
opaque to the user.


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

You might be surprised by how many different ways of getting data into a
program can be accomplished with a simple Perl idiom like this:

    while (<>) {
    }

It gets pretty generalized in a hurry.


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

. . . and it is shortly after that point that things get very specific,
and non-general.


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

Actually, my understanding was that the problem was someone refused to
type a simple command, and would rather make a series of seven clicks
thirty times while babysitting the application, and had no conception of
the benefits of letting more than one person work in parallel on a given
task.  It wasn't the file format that changed; it was someone's tolerance
for using a keyboard instead of a mouse.  This is the kind of thinking
that leads to the Mac defaulting to a mouse with only one button.


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

That was not evident in the explanation of what happened.  The
explanation suggested nothing about the batch file in question being
difficult to use (or "figure out").  From the sound of it, three
instructions on a 3x5 card would have sufficed to ensure everybody knew
what to do, except in the case of people who do not know how to operate a
keyboard.


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

I think that GUIs are quite valuable when used where appropriate.  I
think that the rest of the time, people greatly exaggerate the value of
the GUI, to the extent that they begin to think the CLI (as well as TUIs
in general) has no value at all.  I used to be one of those idiots, and
there was a time when I would have been on your side of this little
debate.  That was almost fifteen years ago.  Times change, and I grow in
knowledge and experience.  The end result is that I believe those who are
competent to operate a computer professionally would benefit from
learning how to use the command line for those tasks that are more
efficiently performed without the GUI mediating the experience, at least
for almost any task that is performed with any regularity at all.

Obviously, many tasks related to visually oriented work like image
editing are excepted from this.  Such tasks are a minority, however,
where non-casual use is concerned.

-- 
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20101112/263cead2/attachment.pgp