Date: Tue, 9 Nov 2010 18:09:48 -0600 (CST) From: Robert Bonomi <bonomi@mail.r-bonomi.com> To: freebsd-questions@freebsd.org Subject: Re: Tips for installing windows and freeBSD both.. anyone?? Message-ID: <201011100009.oAA09mfG024502@mail.r-bonomi.com>
next in thread | raw e-mail | index | archive | help
> Date: Mon, 8 Nov 2010 09:43:01 +0000 > Cc: freebsd-questions@freebsd.org > Subject: Re: Tips for installing windows and freeBSD both.. anyone?? > > On Sun, 7 Nov 2010 23:17:23 -0700 > Chad Perrin <perrin@apotheon.com> wrote: > > > I did give a nod to discoverability for GUIs, as you might note if > > you go back and read what you quoted back at me. That's exactly what > > you're talking about. I don't see why you have to pretend I didn't > > mention it, and try to paint the efficiencies on the other side of > > the trade-off as worthless in your response. I thought my original > > description of the trade-off was pretty well balanced, despite the > > fact I have a preference for one side over the other where most tasks > > are concerned. > > Sorry - I didn't mean to imply that it was worthless, just that I > believe the efficiency works the other way sometimes. For example I did > Linux development for a while earlier this year and found it to be > extremely inefficient compared to working in Windows, due to overuse of > terminals and command-line operation - and I grew up running BBC BASIC > and have been using FreeBSD for many years. I love having the > command-line available and indeed often develop software using just an > xterm but I do think a well-designed GUI can increase productivity by > bringing things together that would otherwise be separate. A GUI provids a _fixed_ set of predefined operations that it is possible to perform. IF your needs are met =entirely= by the provided operations, great. If not, you're dead in the water, without any way to accomplish the task. GUIs are great for the casual user, because they provide a consistent 'look&feel' acrross the spectrum of apps available under them, and, _generally_ what you learn from using one application 'generalizes' to any other app that runs under the same GUI. OTOH, a GUI is the worst thing in the world for 'production' use. It absolutely _kills_ productivity for production tasks. Automation for productivity _REQUIRES_ a complete/comprehensive command language. With a command language, you can 'automate' a series of operations by simply listing the commands in a file, and feeding that file to the command-processor input. With a GUI there is no way to describe the series of mouse 'motions'/'clicks'/ 'double-clicks'/'drags' and keypresses required to perform an operation. 'screen coordinates' are meaningless when a window, or icon, or button, may be 'repositioned' at will. An _individual_ application may allow scripting via an internal command language, 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 other app) *AND* is utterly worthless for 'automating' annything that involves more than the single app. Years ago, I worked at a place that, among other things, produced a reference manual of statistical data for our cusotmers. About 800 pages of tabular data, practically all of it updated on a staggered, monthly basis. In the 'early' days (MS-DOS vintage, before 'windows'), each table was kept in a separate 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'. And, at the end of the week, when it was time to send out the weeks 'updates' to the customers, we had a simple little '.BAT file, each line of which; (a) invoked the spreadsheet (b) specified the spreadsheet file to use, and (c) invoked a 'start-up macro' that printed the contents of the spreadseet, and exited the program. Thus, on 'publication' day it was just type in the name of the '.BAT file and everthing got printed. It took an hour or two -- of _machine_time_ that is, but _zero_ human intervention. Fast forward a few years, a new-hire analyist (in a senior capacity) felt humiliated at having to use this 'old' technology (they had Windows at his prior employer), and made a big enough stink about it that the shop upgraded to Windows just to keep him happy. He proceeds to bundle all 'his' spreadsheets 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 and click on each relevant/changed sheet in the workbook, click on' file', click on print, select the page to print, and click 'doit'. What a *wonderful* productivity increase!! We've now got a system that requires a -human- to play babysitttr the machine. For a couple of -hours- every week. all to save the complainer from having to enter a few numbers redundantly.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201011100009.oAA09mfG024502>