Date: Sat, 13 Nov 2010 12:37:18 -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: <AANLkTimMU2A=ZnWMK-mdobnZ=%2B=VcQHtvJ7vGd%2BntnNW@mail.gmail.com> In-Reply-To: <201011131848.oADImeTj025257@mail.r-bonomi.com> References: <201011131848.oADImeTj025257@mail.r-bonomi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Nov 13, 2010 at 10:48, Robert Bonomi <bonomi@mail.r-bonomi.com> wro= te: > >> From owner-freebsd-questions@freebsd.org =A0Thu Nov 11 23:20:20 2010 >> Date: Thu, 11 Nov 2010 21:21:51 -0800 >> From: Rob Farmer <rfarmer@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 <perrin@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 giv= en >> > task. =3DA0It wasn't the file format that changed; it was someone's to= leran=3D >> ce >> > for using a keyboard instead of a mouse. =3DA0This is the kind of thin= king >> > 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 thou= ght > of having to use 'obselete' tools that he was unfamilair with, and bitche= d > and moaned until management 'bought' =A0Windows, and Windows apps, to 'sh= ut h > im up'. >> Switching to a GUI doesn't preclude multiple people working in >> parallel, =A0which is why I think the file format or whatever changed >> too, and that was really the problem. > > > Au Contraire, =A0WINDOWS *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. =A0The '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 "facilita= ted" > the self-centered intrests of the above-mentioned employee. > > "Top Management" was a bunch of idiots. =A0they let him get away with thi= s, > and more -- he moved 'his' workhook _off_ the company servers, and kept > it _exclusively_ on his personal laptop. =A0His excuse =A0-- that way he = could > work on it 'at home', too. =A0But the company no longer had a copy of _th= eir_ > 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. =A0Each 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. > >> =A0 =A0 =A0but 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). =A0The > 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. =A0 =A0You have to go to a command-line to invo= ke it. > > Got any idea how many executables there are on a MS-Windows system? =A0an= d > how _few_ of the are accessible from the CUI interface? =A0 OH, ecuse me, > you *can't* tell can you, =A0there's no GUI tool that would give you that > information. =A0 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. =A0I 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." --=20 Rob Farmer
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTimMU2A=ZnWMK-mdobnZ=%2B=VcQHtvJ7vGd%2BntnNW>