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

Robert Bonomi bonomi at
Wed Nov 10 00:11:53 UTC 2010

> Date: Mon, 8 Nov 2010 09:43:01 +0000
> Cc: freebsd-questions at
> Subject: Re: Tips for installing windows and freeBSD both.. anyone??
> On Sun, 7 Nov 2010 23:17:23 -0700
> Chad Perrin <perrin at> wrote:
> > I did give a nod to discoverability for GUIs, as you might note if
> > you go back and read what you quoted back at me.  That's exactly what
> > you're talking about.  I don't see why you have to pretend I didn't
> > mention it, and try to paint the efficiencies on the other side of
> > the trade-off as worthless in your response.  I thought my original
> > description of the trade-off was pretty well balanced, despite the
> > fact I have a preference for one side over the other where most tasks
> > are concerned.
> Sorry - I didn't mean to imply that it was worthless, just that I
> believe the efficiency works the other way sometimes. For example I did
> Linux development for a while earlier this year and found it to be
> extremely inefficient compared to working in Windows, due to overuse of
> terminals and command-line operation - and I grew up running BBC BASIC
> and have been using FreeBSD for many years.  I love having the
> command-line available and indeed often develop software using just an
> xterm but I do think a well-designed GUI can increase productivity by
> bringing things together that would otherwise be separate.

A GUI provids a  _fixed_ set of predefined operations that it is possible to

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.

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

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.

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.

More information about the freebsd-questions mailing list