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

[Robert Bonomi]

> From owner-freebsd-questions at freebsd.org  Thu Nov 11 23:20:20 2010
> Date: Thu, 11 Nov 2010 21:21:51 -0800
> From: Rob Farmer <rfarmer at predatorlabs.net>
> To: freebsd-questions at freebsd.org
> Subject: Re: Tips for installing windows and freeBSD both.. anyone??
>
> On Thu, Nov 11, 2010 at 17:19, Chad Perrin <perrin at apotheon.com> 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. =A0It wasn't the file format that changed; it was someone's toleran=
> ce
> > for using a keyboard instead of a mouse. =A0This 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.

What hapened was a new 'senior-level' employee was 'offended' at the thought
of having to use 'obselete' tools that he was unfamilair with, and bitched
and moaned until management 'bought'  Windows, and Windows apps, to 'shut h
im up'.
> 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.


Au Contraire,  WINDOWS *itself* forbids more than one application from having
the same file open forworking on.

Said employee _demanded_ a GUI-based application.  The 'obselete' tool
in effective production use did not exist in a windows version.

Since said employee bundled all the formerly separate worksheets into a
_single_ workbook, *his* action, combined with Windows enforcement of 
only _single-user_access_ to a given file, precluded multiple people 
working on _anything_ in the workbook at the same time.

That wasn't the fault of the GUI environment, per se, it merely "facilitated"
the self-centered intrests of the above-mentioned employee.  

"Top Management" was a bunch of idiots.  they let him get away with this,
and more -- he moved 'his' workhook _off_ the company servers, and kept
it _exclusively_ on his personal laptop.  His excuse  -- that way he could
work on it 'at home', too.  But the company no longer had a copy of _their_
production data. 

> My reading of the anecdote was that the batch file was indeed easy to
> use,

The batch file approach was _so_ easy to use, that the company _secretary_
would produce a custoized variation of it every week.  Each line was a
'magic incantation' that was simly copied, followed by a file name.

Compare that to what is necessary _today_ to use a COM or .NET automation
interface.

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

There were *NO* automation options at the time (Early Win95 days).  The 
necessary 'hooks' DID NOT EXIST in either the application *OR* the GUI.
So said MICROSOFT themselves.

> 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

If the program _itself_ isn't on a button or a menu item, you can't use
it from *within* the GUI.    You have to go to a command-line to invoke it.

Got any idea how many executables there are on a MS-Windows system?  and 
how _few_ of the are accessible from the CUI interface?   OH, ecuse me,
you *can't* tell can you,  there's no GUI tool that would give you that
information.   On my Windows XP box -- admittedly loaded with software
development tools -- the answer to the first question is that there are
over NINE THOUSAND executables that can be invoked by name.  I estimate
that _less_ _than_ 10% of that number are _directly_ accessible through
the Windows GUI.