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

Polytropon freebsd at edvax.de
Fri Nov 12 19:06:56 UTC 2010


On Thu, 11 Nov 2010 21:21:51 -0800, Rob Farmer <rfarmer at predatorlabs.net> wrote:
> 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.

When entering WHICH field new to you this is different?

Repeat after me: Computers. Are. Not. Easy. :-)



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

That's not fully true, as you may have learned something new and
usable aside, which you may use in a different setting where you
can remember it.

I may give a very individual example: I've been reading about the
shell's ability to use built-in field splitting (see the section
"Parameter Expansion" in "man sh"); I didn't need that when I
was reading that text, but KNOWING that this was possible (and
remembering where I read it) recently helped me.

Those "side-effects of learning" are sometimes MORE IMPORTANT than
the lesson learned in the end (allthough my example may not have
been a good illustration for that, but I think you got the idea).

What you learn by learning? An important question. You learn to
think, to read, to conclude; to combine, to separate, to filter,
to judge; to abstract, to specify; to express.



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

Understandable. You have to decide what to spend time on - BEFORE
spending that time, as when you're done, it's too late. :-)

The "side-effects" of learning processes may help you to evaluate
the neccessarity or the benefits of using X over Y, reading Z
instead of nothing, or doing "trial & error". The more you learn,
the more you know, your considerations may change.



> I never
> read documentation for GUI programs 

This is because there is no documentation for them. :-)



> - I jump right in and look through
> the menus to find what I need or realize the program isn't adequate
> and move on.

One of my professors once said: "Trial & error is NOT a programming
concept!" :-)

The more complex the task gets, the more "costly" it can be to
do that kind of "trial & error" (chasing throgh menues, dialog
boxes, windows, icons and items). It can even be that you need
more time to find out that the result you got from a GUI program
that you ASSUMED to do the job properly is pure garbage - and
you invested hours on clicking into that program, just to have
a big file of crap in the end.

Well-documented (!) CLI programs tend to state much better what
a program is capable of.

The ability of EXCHANGE of programs for testing is also a strength
of the CLI that does not have something corresponding in GUI land.
If you want to see if GUI programs G1, G2 and G3 do the job you
want, you need to perform the job THREE TIMES - once per program.
For CLI programs C1, C2 and C3, you just go

for PROG in C1 C2 C3; do $PROG < infile > outfile.$PROG.txt; done

and have the COMPUTER do that - NOT ***YOU***.



-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...


More information about the freebsd-questions mailing list