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

Rob Farmer rfarmer at
Fri Nov 12 05:21:52 UTC 2010

On Thu, Nov 11, 2010 at 17:19, Chad Perrin <perrin at> wrote:
>> 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.

Well, our info about this situation is limited, so it is hard to say
exactly what happened.

Switching to a GUI doesn't preclude multiple people working in
parallel, which is why I think the file format or whatever changed
too, and that was really the problem.

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

My reading of the anecdote was that the batch file was indeed easy to
use, but it no longer worked when the GUI switch was made. Again, that
isn't really a reflection on the GUI, since there are ways to automate
this kind of thing (for Windows, AutoIt was mentioned, plus there are
probably solutions that are more native to the application).

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

I'm not saying the CLI is universally bad - if you gain competence
with a set of programs that you use frequently, it can be very
efficient. It does make it hard to enter a new area, though - you've
got to learn some before you can do anything. That can pay off, if you
keep using that program, but if it is a one-off or occasional thing
(like the svn tagging example earlier in this thread), it's probably
not worthwhile. While you argue that it increases flexibility, which
is true in some ways, it also decreases flexibility by limiting me to
the programs I know or am willing to read documentation for. I never
read documentation for GUI programs - I jump right in and look through
the menus to find what I need or realize the program isn't adequate
and move on.

Rob Farmer

More information about the freebsd-questions mailing list