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

Rob Farmer rfarmer at
Wed Nov 10 02:10:56 UTC 2010

On Tue, Nov 9, 2010 at 16:09, Robert Bonomi <bonomi at> 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.

> 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

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

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

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

More information about the freebsd-questions mailing list