> From owner-freebsd-questi...@freebsd.org Thu Nov 11 23:20:20 2010 > Date: Thu, 11 Nov 2010 21:21:51 -0800 > From: Rob Farmer <rfar...@predatorlabs.net> > To: freebsd-questions@freebsd.org > Subject: Re: Tips for installing windows and freeBSD both.. anyone?? > > On Thu, Nov 11, 2010 at 17:19, Chad Perrin <per...@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. _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
