Date: Tue, 9 Nov 2010 18:10:54 -0800 From: Rob Farmer <rfarmer@predatorlabs.net> To: Robert Bonomi <bonomi@mail.r-bonomi.com> Cc: freebsd-questions@freebsd.org Subject: Re: Tips for installing windows and freeBSD both.. anyone?? Message-ID: <AANLkTi=KNcjf6bo52=D9ioh7c8Fu%2BTHOzusvEdA_KRt6@mail.gmail.com> In-Reply-To: <201011100009.oAA09mfG024502@mail.r-bonomi.com> References: <201011100009.oAA09mfG024502@mail.r-bonomi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Nov 9, 2010 at 16:09, Robert Bonomi <bonomi@mail.r-bonomi.com> wrot= e: > A GUI provids a =A0_fixed_ set of predefined operations that it is possib= le to > perform. > > IF your needs are met =3Dentirely=3D by the provided operations, great. = =A0If not, > you're dead in the water, without any way to accomplish the task. How is this different from the command line? If I have a set of data and want to sort it in a way that "sort" doesn't have an argument for, I'm just as dead in the water as with the GUI. In fact, with the GUI I am probably better off because I can see that this is not supported within the program, without having to use the documentation. > > GUIs are great for the casual user, because they provide a consistent 'lo= ok&feel' > acrross the spectrum of apps available under them, and, _generally_ what = you > learn =A0from using one application 'generalizes' to any other app that r= uns under > the same GUI. > > OTOH, a GUI is the worst thing in the world for 'production' use. =A0It a= bsolutely > _kills_ productivity for production tasks. =A0Automation for productivity= _REQUIRES_ > a complete/comprehensive command =A0language. > > With a command language, you can 'automate' a series of operations by sim= ply > listing the commands in a file, and feeding that file to the command-proc= essor > input. > > With a GUI there is no way to describe the series of mouse 'motions'/'cli= cks'/ > 'double-clicks'/'drags' and keypresses required to perform an operation. > 'screen coordinates' are meaningless when a window, or icon, or button, m= ay be > 'repositioned' at will. > > An _individual_ application may allow scripting via an internal command l= anguage, > but since it is internal to the app, and *not* part of the GUI, it doesn'= t > 'generalize' (no guarantee that similar capability is present in any othe= r app) > *AND* is utterly worthless for 'automating' annything that involves more = than > the single app. The CLI doesn't generalize either. How many ways are there to get input into a program? Some can open files on their own and the file is listed as an argument (app input) Some have a flag for input, which of course isn't consistent (app -in input= ) Some have multiple flags for input, but which ones work depends on the platform/implementation (such as GNU long flags) Some need it provided to stdin Some can process multiple types of input and are smart enough to figure it out on their own while others need to be told what format they are being given Some can do multiple unrelated things in one instance (file a b) while others can't (date +"%H" +"%M") Some have historic idiosyncrasies, such as tar defaulting to a tape drive Some have other strangeness, like java using aaa.class as input but wanting you to list it without the .class extension, whilst javac needs the .java extension Some are just unusual for no obvious reason, like dd's xx=3Dyy thing etc. On the other hand, 99% of GUI apps that handle files have a File > Open dialog that is provided via a toolkit and works the same everywhere. > > Years ago, I worked at a place that, among other things, produced a refer= ence > manual of statistical data for our cusotmers. =A0About 800 pages of tabul= ar data, > practically all of it updated on a staggered, monthly basis. =A0In the 'e= arly' > days (MS-DOS vintage, before 'windows'), =A0each table was kept in a sepa= rate > spreadsheet, which _did_ require the redundant entry of a _small_ amount = of > the data. OTOH two (or more) differnt people could be updatdin different = paes > simultaneously, regardless of whether or not they were 'related'. =A0And,= at > the end of the week, when it was time to send out the weeks 'updates' to = the > customers, =A0we had a simple little '.BAT file, each line of which; (a) = invoked > the spreadsheet =A0(b) specified the spreadsheet file to use, and (c) inv= oked > a 'start-up macro' that printed the contents of the spreadseet, and exite= d > the program. =A0Thus, on 'publication' day it was just type in the name o= f the > '.BAT file and everthing got printed. =A0It took an hour or two -- of _ma= chine_time_ > that is, but _zero_ human intervention. > > Fast forward a few years, =A0a new-hire analyist (in a senior capacity) f= elt > humiliated at having to use this 'old' technology (they had Windows at hi= s > prior employer), and made a big enough stink about it that the shop upgra= ded > to Windows just to keep him happy. He proceeds to bundle all 'his' spread= sheets > into a single workbook, so that only one person can be working on any of = them > at any given time, and, on 'publication day', somebody had to sit there a= nd > click on each relevant/changed =A0sheet in the workbook, click on' file',= click > on print, select the page to print, and click 'doit'. =A0 What a *wonderf= ul* > productivity increase!! =A0We've now got a system that requires a -human-= to > play babysitttr the machine. =A0For a couple of -hours- every week. =A0al= l to save > the complainer from having to enter a few numbers redundantly. 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. 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. 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. --=20 Rob Farmer
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi=KNcjf6bo52=D9ioh7c8Fu%2BTHOzusvEdA_KRt6>