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

[Rob Farmer]

On Sat, Nov 13, 2010 at 10:48, Robert Bonomi <bonomi at mail.r-bonomi.com> wrote:
>
>> 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.

As Bruce mentions, that's not true. Besides, that is a great feature,
since it prevents files from being modified, moved, deleted, etc.
while open in an application that can't handle those things. With
older versions of Windows sometimes you could get files stuck in a
locked state but I haven't seen that in a while.

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

Right, and this isn't a GUI problem - its a problem with combining the
documents. What software allows multiple people to open and write to
the same file simultaneously without trashing the file or losing data?
Many load the whole file into memory then write the whole thing back
out, blindly assuming that nothing has changed since.

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

Indeed, so why do you include it as an anti-GUI argument?

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

You create a script or exe which is double-clicked and does whatever
you want. AutoIt was already mentioned.

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

OLE automation has existed for years - Wikipedia says Microsoft
published a book on it in December 1993 (OLE 2 Programmer's
Reference). Perhaps there was an OLE 1, before that, I don't know. It
also says macros and VBA were added to Office in 1993 (ie, when GUI
started to get popular).

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

Many of those are used internally by other programs - like libexec on
FreeBSD. Also, many have been dropped from the Start Menu as a way of
deprecating them or because exposing them would simply encourage
people who don't know what they are doing to break their system (Group
Policy editor, registry editor, ...).

And my FreeBSD system has over 30,000 items in/under /usr/local/lib,
all for a rather minimal set of software (Gnome, Firefox, a couple
small ports). So Windows hardly loses this "game."

-- 
Rob Farmer