Re: Tips for installing windows and freeBSD both.. anyone??
On Sat, Nov 13, 2010 at 06:12:52PM -0800, Rob Farmer wrote: > On Sat, Nov 13, 2010 at 13:53, Chad Perrin wrote: > >> 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? > > > > Git and Mercurial come to mind. > > I'm not familiar with DVCSes, but I assume they work much the same as > a centralized one - that is they don't open a file and leave it open - > you work on something, then use locking for the actual commit part. > Two people can't edit the same working copy at once, nor can they > commit at exactly the same time. The difference is that locking is > done at the application layer, rather than by the OS itself. Actually, they *don't* work exactly like centralized version control. That's kinda the point; they offer excellent facilities for edit conflict resolution that makes the facilities provided by CVCSes look positively primitive by comparison. DVCSes are specifically designed to facilitate a certain amount of simultaneous development of the same files with generally error-free merging when the second of the two changesets gets added to a given repository. The idea that multiple people can work on the same stuff at the same time is kind of central to the necessary capabilities of a DVCS. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] pgp52CqZNNmbB.pgp Description: PGP signature
Re: Tips for installing windows and freeBSD both.. anyone??
On Sat, Nov 13, 2010 at 13:53, Chad Perrin wrote: >> 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? > > Git and Mercurial come to mind. I'm not familiar with DVCSes, but I assume they work much the same as a centralized one - that is they don't open a file and leave it open - you work on something, then use locking for the actual commit part. Two people can't edit the same working copy at once, nor can they commit at exactly the same time. The difference is that locking is done at the application layer, rather than by the OS itself. -- Rob Farmer ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
On Sat, Nov 13, 2010 at 03:12:16PM -0600, Robert Bonomi wrote: > > This kind of file-locking _does_ make good sense -- 'sort of', that is. > A default mode where additional apps could access the file 'read only' > with a warning, would be arguably better. Yeah -- I'm a fan of how nvi and Vim handle it. Each does things a little differently from the other, but both handle it well. Unfortunately, they only seem to handle it for other instances of the same program. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] pgpeoG4pDBiEN.pgp Description: PGP signature
Re: Tips for installing windows and freeBSD both.. anyone??
On Sat, Nov 13, 2010 at 12:37:18PM -0800, Rob Farmer wrote: > On Sat, Nov 13, 2010 at 10:48, Robert Bonomi wrote: > > > > 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? Git and Mercurial come to mind. > > > > 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? I think it was more of an anti-anti-CLI argument. > > > > 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." I think the point was that only a small fraction of the tools available from the CLI can reasonably be made available from the GUI, because of the incredibly complexity that would be added to the interface if the GUI could directly access all of that stuff. I don't think the point was that MS Windows has lots of executables. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] pgpuWwZ5M8lkB.pgp Description: PGP signature
Re: Tips for installing windows and freeBSD both.. anyone??
> From owner-freebsd-questi...@freebsd.org Sat Nov 13 13:01:04 2010 > Date: Sat, 13 Nov 2010 19:02:31 + > From: Bruce Cran > To: Robert Bonomi > Cc: freebsd-questions@freebsd.org > Subject: Re: Tips for installing windows and freeBSD both.. anyone?? > > On Sat, 13 Nov 2010 12:48:40 -0600 (CST) > Robert Bonomi wrote: > > > Au Contraire, WINDOWS *itself* forbids more than one application > > from having the same file open for working on. > > Wrong. Windows *itself* doesn't care - lots of applications just don't > specify FILE_SHARE_WRITE: Windows -enforces- the restriction, which exists "by default". Whether or not there is programatic 'work around' is irrelevant if the needed application fails to provide any way to twiddle that knob. This kind of file-locking _does_ make good sense -- 'sort of', that is. A default mode where additional apps could access the file 'read only' with a warning, would be arguably better. ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
On Sat, Nov 13, 2010 at 10:48, Robert Bonomi wrote: > >> 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 >> 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 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 Refe
Re: Tips for installing windows and freeBSD both.. anyone??
On Sat, 13 Nov 2010 19:02:31 + Bruce Cran articulated: > On Sat, 13 Nov 2010 12:48:40 -0600 (CST) > Robert Bonomi wrote: > > > Au Contraire, WINDOWS *itself* forbids more than one application > > from having the same file open forworking on. > > Wrong. Windows *itself* doesn't care - lots of applications just don't > specify FILE_SHARE_WRITE: > > "An application also uses CreateFile to specify whether it wants to > share the file for reading, writing, both, or neither. This is known > as the sharing mode. An open file that is not shared (dwShareMode set > to zero) cannot be opened again, either by the application that > opened it or by another application, until its handle has been > closed. This is also referred to as exclusive access." from > http://msdn.microsoft.com/en-us/library/aa363874%28VS.85%29.aspx FUD certainly comes into play here. Microsoft haters will utter any excuse to downplay its GUI. Those naysayers are just as pathetic as those who claim that a CLI is obsolete or overly burdensome. If you want to use a GUI, then use it. If not, then use a CLI or whatever suits your fancy. Honestly, this whole thread has deteriorated to a group of old wash women debating molecular science. The fact that they have not got all their facts correct never caused them to miss a beat. -- Jerry ✌ freebsd.u...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ I know you think you thought you knew what you thought I said, but I'm not sure you understood what you thought I meant. ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
On Sat, Nov 13, 2010 at 10:47:05AM -0600, Robert Bonomi wrote: > > Date: Thu, 11 Nov 2010 18:19:34 -0700 > > From: Chad Perrin > > Subject: Re: Tips for installing windows and freeBSD both.. anyone?? > > > > =2E . . and it is shortly after that point that things get very specific, > > and non-general. > > Not to mention the fact that you _cannot_ specify anything _but_ a 'file' > as the source of the data to be handled. Want to read it from a mag tape? > Can't do it. Want to read directly from a serial port? =Can't= do it. > Want to read directly from the keyboard? *Can't* do it. Want to get the > input directly from another program, _without_ using an intermediate file? > CANT' do it. The GUI "open" dialog doesn't allow for that kind of > flexibility. > > In a pure GUI environment, if there =isn't= an _existing_ button/menu-item/ > selection-list action for it, you _cannot_ do the operation. > > This is, not incidentally, why _pure_ GUI environments have gone the way of > the dodo bird, except for some fixed-scope production uses. > > EVERYBODY _today_ realizes a GUI _alone_ is 'inadequate' for 'general purpose' > use, and proivdes -- at a mnimum, an escape to a command-line, where you can > do 'anything'. e.g. the MS Windows "run" item on the start menu. I wish it was that simple. Unfortunately, since much of the MS Windows environment was designed *solely* with the GUI in mind, there's a lot of stuff that is not very doable with the run dialog, cmd.exe, command.exe, PowerShell, or even Ypsilon (which, shockingly, is more capable in many ways than PowerShell, even though it's only meant to be a Scheme REPL). -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] pgp9Jn6Ft5lk9.pgp Description: PGP signature
Re: Tips for installing windows and freeBSD both.. anyone??
On Sat, 13 Nov 2010 12:48:40 -0600 (CST) Robert Bonomi wrote: > Au Contraire, WINDOWS *itself* forbids more than one application > from having the same file open forworking on. Wrong. Windows *itself* doesn't care - lots of applications just don't specify FILE_SHARE_WRITE: "An application also uses CreateFile to specify whether it wants to share the file for reading, writing, both, or neither. This is known as the sharing mode. An open file that is not shared (dwShareMode set to zero) cannot be opened again, either by the application that opened it or by another application, until its handle has been closed. This is also referred to as exclusive access." from http://msdn.microsoft.com/en-us/library/aa363874%28VS.85%29.aspx -- Bruce Cran ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
> 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 > 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 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
Re: Tips for installing windows and freeBSD both.. anyone??
> Date: Thu, 11 Nov 2010 18:19:34 -0700
> From: Chad Perrin
> Subject: Re: Tips for installing windows and freeBSD both.. anyone??
>
> On Tue, Nov 09, 2010 at 06:10:54PM -0800, Rob Farmer wrote:
> > On Tue, Nov 9, 2010 at 16:09, Robert Bonomi wr=
> ote:
> > > 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 does=
> n't
> > > 'generalize' (no guarantee that similar capability is present in any ot=
> her app)
> > > *AND* is utterly worthless for 'automating' annything that involves mor=
> e than
> > > the single app.
> >=20
> > The CLI doesn't generalize either. How many ways are there to get
> > input into a program?
>
> You might be surprised by how many different ways of getting data into a
> program can be accomplished with a simple Perl idiom like this:
>
> while (<>) {
> }
>
> It gets pretty generalized in a hurry.
> > 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.
>
> =2E . . and it is shortly after that point that things get very specific,
> and non-general.
Not to mention the fact that you _cannot_ specify anything _but_ a 'file'
as the source of the data to be handled. Want to read it from a mag tape?
Can't do it. Want to read directly from a serial port? =Can't= do it.
Want to read directly from the keyboard? *Can't* do it. Want to get the
input directly from another program, _without_ using an intermediate file?
CANT' do it. The GUI "open" dialog doesn't allow for that kind of flexibility.
In a pure GUI environment, if there =isn't= an _existing_ button/menu-item/
selection-list action for it, you _cannot_ do the operation.
This is, not incidentally, why _pure_ GUI environments have gone the way of
the dodo bird, except for some fixed-scope production uses.
EVERYBODY _today_ realizes a GUI _alone_ is 'inadequate' for 'general purpose'
use, and proivdes -- at a mnimum, an escape to a command-line, where you can
do 'anything'. e.g. the MS Windows "run" item on the start menu.
___
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"
Re: Tips for installing windows and freeBSD both.. anyone??
On Fri, Nov 12, 2010 at 12:24 PM, Peter A. Giessel wrote: > On 2010/11/12 at 10:33, rfar...@predatorlabs.net (Rob Farmer) wrote: >> it is better for real/serious work, but the general public doesn't see >> it as new or valuable - its just a stupid change in the way everything >> has always been done. I'd say that's because for most people it offers no particular advantages in exchange for the work of learning it. Most people don't do unit conversions as frequently as scientists do, so the relative difficulty of converting from inches to miles instead of centimeters to kilometers doesn't affect them. Even countries that have ostensibly converted to SI on an official basis still have people using non-SI units on a day-to-day basis. Talk to someone from the UK and they'll probably give you their weight in stone and distances in miles. > It depends on what you mean by "real serious work". Try ordering a > cubic meter of concrete or a #25 rebar in the U.S. and see how far you > get. The construction field offers a particular problem because so many standard items come in inch-based sizes. Who wants to mess around with asking for a 122 cm x 244 cm piece of plywood? 4x8 feet is so much easier. ;) On the other hand, manufacturing has largely switched over. Look at a modern American car and you'll find mostly metric fasteners. ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
Since this discussion refuses to die, I hope the participants will heed my suggestion and collect the results on a webpage somewhere so we don't have to go over it all many times again in the future. So far, I haven't seen anything said that wasn't already said five, ten, fifteen or even twenty years ago. Maybe it goes even further back than that, but that's about as long as I have personally been aware of this particular debate. ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
On Fri, 12 Nov 2010 11:24:09 -0900 Peter A. Giessel articulated: > It depends on what you mean by "real serious work". Try > ordering a > cubic meter of concrete or a #25 rebar in the U.S. and see how > far you > get. Seriously, does everyone in this tread suffer from ADHD (Attention deficit hyperactivity disorder). The attention span here is pathetic. We start out with a some question regarding installing Windows & FreeBSD and have through some convoluted path ending up at ordering concrete. BTW, was that for ASTM A497 rebar? So, to answer the OP's question, try a Windows forum. Perhaps someone there could assist you without going off on a tangent. -- Jerry ✌ freebsd.u...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
Quoth Chad Perrin on Friday, 12 November 2010: > On Fri, Nov 12, 2010 at 11:33:38AM -0800, Rob Farmer wrote: > > > > To use a US example, you see the same thing with the SI/metric system. > > Scientists and other technical people use it almost universally > > without issue (except for some oddities, PSI is somewhat popular) - it > > is better for real/serious work, but the general public doesn't see it > > as new or valuable - its just a stupid change in the way everything > > has always been done. > > The military uses metric measures as well. Ranges are measured in > meters, not feet or yards, for instance. Distances for travel are > typically measured in kilometers (aka "klicks"). > > The fact that the general public in the US has thus far largely resisted > the use of metric measures is in no way evidence that their use should > not be encouraged, however. > > -- > Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] I'm sure plenty of people resisted giving up measurements using the cubit and parasang. -- Sterling (Chip) Camden| sterl...@camdensoftware.com | 2048D/3A978E4F http://camdensoftware.com | http://chipstips.com| http://chipsquips.com pgpadxVWJdJv4.pgp Description: PGP signature
Re: Tips for installing windows and freeBSD both.. anyone??
On 2010/11/12 at 10:33, rfar...@predatorlabs.net (Rob Farmer) wrote: Scientists and other technical people use it almost universally without issue (except for some oddities, PSI is somewhat popular) Would you consider engineers "technical people"? One example would be the American Association of State Highway Transportation Officials (AASHTO) LRFD Bridge Design Specification. They have discontinued the SI Units version as nobody was using it or buying it. I would disagree with you assessment that "technical people" "almost universally" use SI. it is better for real/serious work, but the general public doesn't see it as new or valuable - its just a stupid change in the way everything has always been done. It depends on what you mean by "real serious work". Try ordering a cubic meter of concrete or a #25 rebar in the U.S. and see how far you get. There is no universal solution to any technical problem. Each solution will suit some people's needs and aggravate other people. That is the beauty of something like FreeBSD, you can customize it to your needs. If you aren't willing to do that, there are several other OSs out there that do not offer the same level of customization that may be better suited for a particular purpose/user. ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
On Fri, 12 Nov 2010 12:47:32 -0700, Chad Perrin wrote: > This sounds a bit like a common problem with people thinking that > Unix-like OSes are not "user friendly" because they're "hard" to install, > a frequent protestations of people who like MS Windows because it comes > already installed on their computers, and that they think is easy to > "install" because of the recovery partition that resets the system to > factory settings. No. "Windows" is easy to install because someone else does it. :-) What, on the other hand, is not "user friendly" when everything you have to do is to follow the instructions on screen? > Comparing this with installing from scratch is an > apples and orange comparison. That's true of course. See a professional IT person that does NOT have "Windows" knowledge it may also be complicated to install "Windows" as he can't say from the (wrongly) used terminology what the installer wants. A sidenote from the german point of view: "Windows" installs require the user to "press the input key" (Eingabetaste), which refers to Enter, Return, or "arrow down and left". This is too complicated for the average user as he does NOT know where the "input key" is on the keyboard. (I've seen that one many times already.) > Actually, with the amount of Web browsing people do, the default GUI > approach to using a browser is incredibly inefficient. Some people begin > to get beyond that when they start learning the rudiments of driving an > interface via the keyboard, using the keybindings for the specific > browser they use -- such as Ctrl+L to get to the address bar, typing a > word like "blogstrapping" there, and hitting Ctrl+Enter to automatically > add a "www." in front of that word and ".com" after it then load the page > at the other end of that resulting "www.blogstrapping.com" URL. That's not how average users do it. They first enter google's URI, then enter the URI they want to access in the google search field and finally click on the first restult - tadaa! :-) Many users are not familiar with the browser they are using. The functionality used contains address entry, bookmarks, and File > Print. Did I leave out page navigation (back, forward)? Yes, I did. This seems to be the reason many web pages do implement that THEIRSELVES - read: the web page contains some functionality of the web browser. Advantage: can run in full- screen; disadvantage: adds complexity advanced users are not interested in. > Most of them never realize the significant efficiency benefits that could > be realized by spending fifteen minutes (at most) learning the basic > interface of something like the Vimperator extension for Firefox, or how > to use a natively keyboard-driven browser like uzbl. Don't miss the integration of keyboard AND mouse - this is also very useful for desktop opreations, as game developers have already recognized this and adopted - often requiring a mouse with 16 buttons. :-) > True, these are > still essentially GUI tools in many respects, but with those keyboard > driven interfaces they effectively become CLI/GUI hybrids, using commands > to control a graphical display. In even the most GUI-oriented tasks, I > tend to find that at least some hybridizing with a CLI approach results > in a massive efficiency and productivity improvement. I've seen this when talking to a professional video editor: She mostly used the (differently colored) keys of the keyboard to perform the main operations, only very few times the mouse was used. This made her work look like Magic and Voodoo at the same time - for ME, a keyboard guy. :-) > Good. A principle I apply to my own consulting work, which is relevant > is this: > > A true professional works toward the day when he is no longer > necessary. But when he is not needed, who pays him? ;-) You are right: The professional should concentrate on the complicated, interesting tasks that require his fast mind, his creativity and his knowledge, while leaving monotonous tasks to others (e. g. "baby- sitting users to click on this, on that, and reboot"). The more GUI is "in the game", the more a professional seems to be required to "dumb himself down" to aid the novice users (who do not want to read or learn something), finally resulting in HIM doing THEIR work. That just cannot be. > Empowering clients is much more rewarding as a career path than training > them to be unhealthily dependent upon me. That's true. I'm always happy when I can talk to customers who tell me: "I'm not frightened of the keyboard. In fact, I want you do make the program react on keyboard input as I have to enter LOTS of numbers continuously, and I want to be able to automate certain things so I don't have to do that manually for every of my clients." When I then see that people actually have learned things, I see them being more professional - leading to being more happy, as they have less work to do (because they are now ABLE to DELEGATE this work to
Re: Tips for installing windows and freeBSD both.. anyone??
On Fri, Nov 12, 2010 at 11:33:38AM -0800, Rob Farmer wrote: > > To use a US example, you see the same thing with the SI/metric system. > Scientists and other technical people use it almost universally > without issue (except for some oddities, PSI is somewhat popular) - it > is better for real/serious work, but the general public doesn't see it > as new or valuable - its just a stupid change in the way everything > has always been done. The military uses metric measures as well. Ranges are measured in meters, not feet or yards, for instance. Distances for travel are typically measured in kilometers (aka "klicks"). The fact that the general public in the US has thus far largely resisted the use of metric measures is in no way evidence that their use should not be encouraged, however. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] pgpohbVzNY6jn.pgp Description: PGP signature
Re: Tips for installing windows and freeBSD both.. anyone??
On Fri, 12 Nov 2010 11:33:38 -0800, Rob Farmer wrote: > On Fri, Nov 12, 2010 at 11:06, Polytropon wrote: > > On Thu, 11 Nov 2010 21:21:51 -0800, Rob Farmer > > wrote: > >> 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. > > > > When entering WHICH field new to you this is different? > > > > Repeat after me: Computers. Are. Not. Easy. :-) > > None - but people don't feel like they are entering a new field. Hey, I was just kidding. :-) Computers and HOW we INTERACT with them have come a long way. The more BASIC your skills are, the better you can mater complex tasks - the tasks that are impossible to solve for the self-proclaimed dynamical long-legged elastic group-oriented program manangers. :-) > Everyone uses computers - public schools have spent massive amounts of > money to start kids using computers at 5 or 6 years old, if they > haven't already at home. Early indoctrination is the best. When the basics are learned, it's very easy to introduce misbeliefs, "musts" and strange concepts (or their absence at all). Schools are the ideal place for that. Using a computer and KNOWING about a computer are different things. As a car driver, I don't have to exactly know how the car works in every detail. Still I have to know the rules that apply in traffic. I need to have a driving license that states that I know - or I won't be able to participate in traffic. I'm just mentioning this as people do like car analogies. :-) What I want to say is that: Using the computer in a "trial & error manner" may be sufficient for some jobs, but even animals can be more clever than that. They even think before they act. School has done a good job convincing children to switch off their brain when switching on the computer. You can see the absence of common sense nearly everywhere where computers are in regular use. Don't force me to give examples. :-) > So the discussion isn't framed as learning something new - its "why > should we change the way everyone has been working for years?" Because your assumption is wrong. Why should we change it? No, we should not change it. The question is: WHO should change it, and WHY. Let me answer quickly: Those who need to do serious work (=who), because their money and therefore their future depends on it (=why). > To use a US example, you see the same thing with the SI/metric system. > Scientists and other technical people use it almost universally > without issue (except for some oddities, PSI is somewhat popular) - it > is better for real/serious work, but the general public doesn't see it > as new or valuable - its just a stupid change in the way everything > has always been done. Exchange "always" to "for a long time" (which may be less than a man's life span for computer related topics). If you emphasize the "Where's the benefit?" approach, just see what incompatibility and misunderstandings can create in DIFFICULT situations. When terminonoly isn't used properly, when people can't even express what they need - why? Because they never learned the WORDS that are needed. Our spoken and written language heavily relies on words and how we use them. Words are a domain of CLI, natively, while GUI operates on pictures, images, symbols. Of course symboles are also a kind of language, but this language is often much harder to learn. The circle closes: When scholar education didn't provide the basics of language, how can an individual be able to use a system that depends on language (when this individual has only learned to chose from a predefined set of options)? Seeing things "as new" can be a great accelleration in promoting changes. People "want new", because their friends "have new", or the neighbor "has better". Using this approach, together with the mechanisms of advertising that control the market, people can be forced to DO anything, BUY anything, BELIEVE anything - and those people even believe they are choosing freely. To adopt that concept to the consideration GUI vs. CLI, or "how good is _this_ GUI", advertising dictates how people think about the whole topic. A shiny application window, dancing elephants, lots of blingbling, stylish animations and sounds can make them really forget about what has been their primary interest: to use the PC in order to get a JOB DONE. "Entertainment" ia a magic word you often see here, as well as "experience". It depends on the individidual state of mind what a person enjoys as "enter- taining" or "experiencing". A video game can do that, as well as a book. I may use an example from psychiatry: In the past we had patients who suffered from "pathological gambling". They sat infront of one-armed bandits and were putting all their money (as well as NOT their money) into the slot machine. More and more, day after day. Th
Re: Tips for installing windows and freeBSD both.. anyone??
On Fri, Nov 12, 2010 at 07:49:51PM +0100, Polytropon wrote: > > The primary REFUSE to use the keyboard because the mouse EXISTS > prevents lazy users even from READING that 3x5 card. They are > often not WILLING to follow instructions, no matter how simple > (or even idiotic, sorry) they may be. In worst case, they expect > YOU to come over and DO THEIR WORK. > > This leads to the misbelief that things which AREN'T easy "are > easy" - because someone else does them. :-) This sounds a bit like a common problem with people thinking that Unix-like OSes are not "user friendly" because they're "hard" to install, a frequent protestations of people who like MS Windows because it comes already installed on their computers, and that they think is easy to "install" because of the recovery partition that resets the system to factory settings. Comparing this with installing from scratch is an apples and orange comparison. > > Web browsing IS a majority, for example. A well-designed web > browser could benefit both the average and the professional > user. Let's say this "ideal browser" requires a bit of learning, > maybe some reading. The professional will do that, and he will > master this new program and productively use it. The average > user will refuse to read in the first place, and resist to use > "something different". There's a big aversion against anything > that is "not like mine". Web browsing is a majority of *time* spent, but it is only one task in and of itself. As such, it only increments the minority number of tasks that really do better in the GUI by 1. Actually, with the amount of Web browsing people do, the default GUI approach to using a browser is incredibly inefficient. Some people begin to get beyond that when they start learning the rudiments of driving an interface via the keyboard, using the keybindings for the specific browser they use -- such as Ctrl+L to get to the address bar, typing a word like "blogstrapping" there, and hitting Ctrl+Enter to automatically add a "www." in front of that word and ".com" after it then load the page at the other end of that resulting "www.blogstrapping.com" URL. Most of them never realize the significant efficiency benefits that could be realized by spending fifteen minutes (at most) learning the basic interface of something like the Vimperator extension for Firefox, or how to use a natively keyboard-driven browser like uzbl. True, these are still essentially GUI tools in many respects, but with those keyboard driven interfaces they effectively become CLI/GUI hybrids, using commands to control a graphical display. In even the most GUI-oriented tasks, I tend to find that at least some hybridizing with a CLI approach results in a massive efficiency and productivity improvement. > > That's what I always tell them: I couldn't do that Magic from the > beginning, I had to invest time and exercise - that's why I'm so very > expensive :-) - in order to master those tools. But ***YOU*** are free > to learn those tools, too. Good. A principle I apply to my own consulting work, which is relevant is this: A true professional works toward the day when he is no longer necessary. I've come up with a number of different formulations of that concept over the years, but the basic premise and principle remains constant. Empowering clients is much more rewarding as a career path than training them to be unhealthily dependent upon me. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] pgpmJKnfoE7jd.pgp Description: PGP signature
Re: Tips for installing windows and freeBSD both.. anyone??
On Fri, Nov 12, 2010 at 11:06, Polytropon wrote: > On Thu, 11 Nov 2010 21:21:51 -0800, Rob Farmer > wrote: >> 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. > > When entering WHICH field new to you this is different? > > Repeat after me: Computers. Are. Not. Easy. :-) None - but people don't feel like they are entering a new field. Everyone uses computers - public schools have spent massive amounts of money to start kids using computers at 5 or 6 years old, if they haven't already at home. So the discussion isn't framed as learning something new - its "why should we change the way everyone has been working for years?" To use a US example, you see the same thing with the SI/metric system. Scientists and other technical people use it almost universally without issue (except for some oddities, PSI is somewhat popular) - it is better for real/serious work, but the general public doesn't see it as new or valuable - its just a stupid change in the way everything has always been done. -- Rob Farmer ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
On Fri, Nov 12, 2010 at 07:35:51PM +0100, Michael Grünewald wrote: > > But in my opinion, a complete GUI software should also provide some > command line facilities. I mean, for instance, a word processing > software could be shipped with command line tools that could be used to > * inspect document properties (word count, meta information fields); > * convert the document to a publishable form such as PostScript; > * do field replacement for mailings; > and many less elementary treatments could also be useful! Some software > comes with a scripting language, but for simple operation and batch > processing, this may not be so convenient as a command line tool. The "easy" way to do that would probably be to write things as single-purpose libraries with command line interfaces, then write GUI interfaces that use those libraries. Failing that, just write command line tools and write GUIs that use those tools on the back end; writing them as libraries with command line interfaces is not *entirely* necessary. In addition to being the "easy" way, I'd say it's the *right* way to do it as well. That way, someone who *just* wants the functionality of one or two CLI utilities, and not all the functionality of some bloated GUI all-in-one application, can get the parts independently. Last I checked, I think K3b uses cdrdao, cdrtools, and growisofs on the back end, with the GUI just an interface layer over the top of those tools. While I'm not a fan of things being tied into a set of DE libraries for applications I actually use, at least the basic premise of composing GUI tools from CLI tools is well used in this case. At least two of those three CLI tools are also actually composed of several smaller CLI tools, themselves. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] pgpwIiSSKpzOw.pgp Description: PGP signature
Re: Tips for installing windows and freeBSD both.. anyone??
On Fri, 12 Nov 2010 11:23:22 -0700, Chad Perrin wrote: > The type of program I specifically meant was the sort of thing that > actually tells the user the command that would perform the same task as > the button-click, so that users of the GUI (or captive interface TUI) > would get to see what is going on behind the scenes and perhaps learn > from it. Ah, I see. I've in fact wirtten such a wrapper program around the pw program - a set of input fields to define input data (command line parameters) to pw, and a "composited field" that would contain the resulting command. If the wrapper did miss a function, you could access this final command field and also edit it. Depending on which options you had set, the command in that field would change. The GUI wrapper also gave a short explaination of the options used. Sadly, this concept is usually NOT employed by GUI programs because their programmers think about "their way" as the only way existing. So if "my" image viewer allows you to resize and convert ONE picture, why should it show you how to do that with an arbitrary amount of pictures? :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
On Thu, 11 Nov 2010 21:21:51 -0800, Rob Farmer wrote: > 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. When entering WHICH field new to you this is different? Repeat after me: Computers. Are. Not. Easy. :-) > 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. That's not fully true, as you may have learned something new and usable aside, which you may use in a different setting where you can remember it. I may give a very individual example: I've been reading about the shell's ability to use built-in field splitting (see the section "Parameter Expansion" in "man sh"); I didn't need that when I was reading that text, but KNOWING that this was possible (and remembering where I read it) recently helped me. Those "side-effects of learning" are sometimes MORE IMPORTANT than the lesson learned in the end (allthough my example may not have been a good illustration for that, but I think you got the idea). What you learn by learning? An important question. You learn to think, to read, to conclude; to combine, to separate, to filter, to judge; to abstract, to specify; to express. > 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. Understandable. You have to decide what to spend time on - BEFORE spending that time, as when you're done, it's too late. :-) The "side-effects" of learning processes may help you to evaluate the neccessarity or the benefits of using X over Y, reading Z instead of nothing, or doing "trial & error". The more you learn, the more you know, your considerations may change. > I never > read documentation for GUI programs This is because there is no documentation for them. :-) > - I jump right in and look through > the menus to find what I need or realize the program isn't adequate > and move on. One of my professors once said: "Trial & error is NOT a programming concept!" :-) The more complex the task gets, the more "costly" it can be to do that kind of "trial & error" (chasing throgh menues, dialog boxes, windows, icons and items). It can even be that you need more time to find out that the result you got from a GUI program that you ASSUMED to do the job properly is pure garbage - and you invested hours on clicking into that program, just to have a big file of crap in the end. Well-documented (!) CLI programs tend to state much better what a program is capable of. The ability of EXCHANGE of programs for testing is also a strength of the CLI that does not have something corresponding in GUI land. If you want to see if GUI programs G1, G2 and G3 do the job you want, you need to perform the job THREE TIMES - once per program. For CLI programs C1, C2 and C3, you just go for PROG in C1 C2 C3; do $PROG < infile > outfile.$PROG.txt; done and have the COMPUTER do that - NOT ***YOU***. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
On Thu, 11 Nov 2010 18:25:51 -0700, Chad Perrin wrote: > It's too bad such APIs require so much more knowledge, and present so > much more of a barrier to entry for automating tasks, than a simpler CLI > filter's interface provides via something like the Unix pipeline. Any GUI is limited to the use by halfway healthy individuals. They are a no-go for blind users, for example. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
On Thu, 11 Nov 2010 18:19:34 -0700, Chad Perrin wrote: > In fact, a set of CLI filters linked together by the Unix > pipeline (or even a DOS pipeline, at least in theory) is essentially > infinitely extensible to provide surprising levels of automation > customizability that might astonish the earlier creators of some of the > older tools being used, while an extension system for a GUI application > necessarily has to predefine what is possible, and obfuscates the inner > workings of the extended application behind designs that are largely > opaque to the user. >From computer science, please see the term "fully programmable". > > 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. > > . . . and it is shortly after that point that things get very specific, > and non-general. True - and non-functional sometimes. I may give an example: The File > Open... dialog in Gtk 2 has functional limitations (example here: attach a file in Sylpheed). It doesn't respond to keyboard opreations (except entering a file name, but [tab] to the next dialog element does not work). It *FORCES* the user to use the mouse if he wants to select something from the list. In the list, there is a HELPing element: typing the beginning of a file name moves the cursor to that file. Good idea, but bad in reality, because it doesn't work - as it mixes case: typing "abc" brings you to "ABC" in the list, except YOU want "abc" further down. Option: Again using the mouse. Using shell patterns, e. g. typing "*mp3" to have the list field just contain the MP3 files does not work - the dialog simply disappears. The same if you enter a directory manually, e. g. /export/share/mp3 - dialog disappears. If you add a / at the end, MAYBE it moves to the specified directory, but shows every file TWICE. And keep in mind what I said about limitations in using the copy buffer in an earlier message. THOSE (!!!) are the limitations of GUI - good ideas that got implemented that POORly that the final product is gettimg more and more unusable. Coming back to your statement: Of course every toolkit does the File > Open... dialog differently. That is noting bad per se, as the "advocates of GUI consistency" get more and more inconsistency in their own main domain of what they use. Consistency is not a problem. The problem is RECOGNITION. If the graphical representation of an object or an action cannot be recognized as what it IS, correct what it REFERS TO, all the design is completely useless. Today's approach is to waste screen space and overcomplicate things. Icon bars all over the place. Is that user-friendly? I don't think so. "Limited to the maximum" could be a good approach instead. Allow me to mention GeoWorks Ensemble, a GEOS office suite for the DOS-based PC. It is a GUI that is based on the Motif toolkit (that could to things in the early 90s that "Windows" cannot even do today, like *real* drag & drop, or detachable menus, NATIVELY). This system allowed the user to change the complexity of the GUI. There were 3 (?) levels: beginner, intermediate, expert. On beginner level, only basic functionalitites were exposed to the user. On expert level, all functionality was present. This concept assisted the learning courve development of the user BY USE of the graphical elements. > 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. Extend this idea: If a friend asks me: "Erm, I've got a bunch of JPEG images from my camera, but I need to convert them to PNG; those are 10,000 images. How can I do that?" I write him a mail: "Type this in a terminal: cd /where/your/files/are and then type: for f in *.jpg; do convert $f $f.png; done. That's all." If I wanted to assist him "the GUI way", I would stop using a language (the shell's command language in this case) and would need to draw him pictures - or describe them: "First you click on the blue square, this is either on the left of your desktop, upper region, or it is on the right. Then there will be a grey window and a blue window. On top of the grey window, click the yellow ball. When the ball is jumping into the blue window, a dancing elephant appears. Click on that." :-) You know what I mean: I have no idea how to convert a bunch of JPEG files to PNG per GUI. :-) > It wasn't the file format that changed; it was someone's tolerance > for using a keyboard instead of a mouse. The preference of tools used also depends HEAVILY on the task. For entering continuous data (e. g. for a tax software, for a document generation system, for a listing program), the keyboard is #1. There just is no way around it, and professionals (!) will KNOW that it is done that wa
Re: Tips for installing windows and freeBSD both.. anyone??
Hello Rob, Rob Farmer wrote: Most general computer users will never give up the GUI, because it involves investing in computer skills and they don't see that as terribly worthwhile - they just want to get started on their work. I think some UNIX fans are reluctant to accept this, and in doing so limit its ability to grow. That's my reason for preferring GUI in most situations. I share your observation of user behaviour, and it is probably appropriate: although there is many _funny_ways to use computers, most of us just want to have some work done and GUI sometimes provide a quick way to put our hands on it. But in my opinion, a complete GUI software should also provide some command line facilities. I mean, for instance, a word processing software could be shipped with command line tools that could be used to * inspect document properties (word count, meta information fields); * convert the document to a publishable form such as PostScript; * do field replacement for mailings; and many less elementary treatments could also be useful! Some software comes with a scripting language, but for simple operation and batch processing, this may not be so convenient as a command line tool. This kind of functionnalities could be a bridge from the GUI to the command line for some users: I feel these worlds are so separated, while they do not have to. I sometimes feel that this separation is precisely the wall that keep many computer users to develop their computer skill, despite they use one all day long. This ``computer illiteracy'' is very dommageable, not only because it makes it hard for the average user to learn from more experienced users, but also because it let software editors be economically successful while selling incomplete, crippled, software. -- Best regards, Michael ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
On Fri, Nov 12, 2010 at 07:14:38PM +0100, Polytropon wrote: > On Thu, 11 Nov 2010 17:49:26 -0700, Chad Perrin wrote: > > > > I agree. That is one type of GUI I would really love to see getting more > > popular. > > You can already find this concept in use: The Midnight Commander, > allthough a text-based program (but NOT a CLI program!) integrates > command line and "abstracted" operations. It has excellent keyboard > AND mouse support. > > Another program that comes to my mind is mencoder + gmencoder. The > gmencoder offers a GUI wrapper for the mencoder program. You can > keep using this GUI program for one-time use, or use the mencoder > command line program for scripting. The type of program I specifically meant was the sort of thing that actually tells the user the command that would perform the same task as the button-click, so that users of the GUI (or captive interface TUI) would get to see what is going on behind the scenes and perhaps learn from it. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] pgpdIeoLTe33n.pgp Description: PGP signature
Re: Tips for installing windows and freeBSD both.. anyone??
On Fri, Nov 12, 2010 at 09:54:57AM -0800, Rob Farmer wrote: > On Thu, Nov 11, 2010 at 23:16, Chad Perrin wrote: > > It sounds like in some respects we're violently agreeing with each other. > > On one hand, I think that CLI programs can be great for frequent tasks, > > especially if you have something like the Unix pipeline at your disposal > > to automate complex tasks, and that GUIs have some discoverability > > advantages; on the other hand, you think that GUI programs can be great > > for cases where someone does not want to take the time to learn a better > > way to do something, perhaps because he does not perform the tasks very > > often, but if you do something often enough it might make sense to learn > > a more efficient CLI-based way to do it. > > > > Another difference in our apparent approaches to this is that I think > > it's a good idea to favor CLI tools when at all reasonable to do so, > > while you seem to think it's a good idea to favor GUI tools when at all > > reasonable to do so. We agree on the extremes, but not in the middle, in > > other words. I just wish that we could agree without it feeling like > > you're trying to convince people they shouldn't ever bother learning how > > to use CLI tools unless they absolutely have to. > > Well, I think to some extent we are considering two different sets of > people. If a programmer or sysadmin doesn't use the CLI, they probably > aren't very good at their job, since they are missing out on a lot of > tools. I was thinking more generally about end-users, who tend to be > very reluctant to use the CLI (the whole there's a big black box, what > do I do now? thing is intimidating) and it is usually more trouble > than it is worth to convince them to use the CLI, even if it would > make their jobs easier. I was trying to consider *everybody* who uses a computer heavily in day-to-day life. Yes, I agree that many end users are very reluctant to use CLI tools. I tend to feel, however, that instead of avoiding mentioning such tools and just steering people toward GUI tools all the time, it is in everybody's best interest to at least make the benefits of CLI tools more widely known so that those who could benefit from them (even if they are reluctant to do so) will know the reasons the option might be a good one. Perhaps even more importantly, in cases such as the cited example of someone who managed to get a business process changed so that it negatively affected several other workers' efficiency and that of the business as a whole, such a net loss in productivity might have been avoided if the decision-makers there were more aware of the potential benefits of using CLI tools, and of the fact that GUI tools are not necessarily better just because they're GUI tools. Middle managers and executives, even if they never *touch* the CLI tools themselves, need to be educated about the value of CLI tools for those who perform daily automation tasks so that they will not ignorantly approve using the wrong tool for the job, as in the preceding anecdote. If, because we know them to be reluctant to use CLI tools, we take pains to never expose decision-makers to knowledge of any benefits of using tools other than the *wrong* tools for certain jobs, we are essentially guaranteeing that when the time comes for a decision to be made, the only decision they will make is the one that makes things worse for us (where "us" is the technically inclined workforce that is directly affected by these decisions) and for the business. > > Most general computer users will never give up the GUI, because it > involves investing in computer skills and they don't see that as > terribly worthwhile - they just want to get started on their work. I > think some UNIX fans are reluctant to accept this, and in doing so > limit its ability to grow. That's my reason for preferring GUI in most > situations. Nobody has to "give up the GUI". Even the heavy use of CLI and other TUI tools in my life tends to be wrapped in a window manager, with occasional GUI applications scattered throughout. Even the simple green bar across the top of my screen (which changes to blue and red when the laptop is unplugged) that indicates battery life is a GUI application, and I find it quite valuable for those occasions when I run my laptop without AC power. By the way, if you want to see what I mean about that battery life indicator, a screenshot of the laptop screen with the battery life bar (provided by sysutils/xbattbar from ports) is available here: http://blogstrapping.com/img/uzbl/uzbl_browser.png It's quite thin, and does not show up well in that image, but it is somewhat more obvious on my laptop display. Moving on . . . I'm perfectly willing to accept that some people absolutely refuse to learn more than the bare minimum to do their jobs, with no concern for efficiency, productivity, or quality of work beyond a bare minimum. I do not think that those who might have a deeper
Re: Tips for installing windows and freeBSD both.. anyone??
On Thu, 11 Nov 2010 17:49:26 -0700, Chad Perrin wrote: > On Tue, Nov 09, 2010 at 01:21:01AM -0800, per...@pluto.rain.com wrote: > > Polytropon wrote: > > > > > The STRENGTH OF GUI (yes, I'm really saying that) is to aid > > > using language elements, CLI. Arranging windows, presenting > > > information, displaying structures, managing things. GUI > > > alone, with no functional substance behind it, is useless. > > > Sadly, you'll find more and more programs that have blingbling > > > and "experience", but are useless to those who want to achieve > > > a certain goal with it. > > > > Another strength, potentially large but all-too-frequently > > overlooked entirely, is as a learning aid. In the situation > > that operations in the GUI map reasonably well to TUI commands > > -- which by definition includes cases in which the GUI is used > > as a front-end to issue commands to an external TUI-based program > > -- the GUI really should have a mode wherein it displays or logs > > the TUI commands that it is performing. > > I agree. That is one type of GUI I would really love to see getting more > popular. You can already find this concept in use: The Midnight Commander, allthough a text-based program (but NOT a CLI program!) integrates command line and "abstracted" operations. It has excellent keyboard AND mouse support. Another program that comes to my mind is mencoder + gmencoder. The gmencoder offers a GUI wrapper for the mencoder program. You can keep using this GUI program for one-time use, or use the mencoder command line program for scripting. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
On Thu, Nov 11, 2010 at 23:16, Chad Perrin wrote: > It sounds like in some respects we're violently agreeing with each other. > On one hand, I think that CLI programs can be great for frequent tasks, > especially if you have something like the Unix pipeline at your disposal > to automate complex tasks, and that GUIs have some discoverability > advantages; on the other hand, you think that GUI programs can be great > for cases where someone does not want to take the time to learn a better > way to do something, perhaps because he does not perform the tasks very > often, but if you do something often enough it might make sense to learn > a more efficient CLI-based way to do it. > > Another difference in our apparent approaches to this is that I think > it's a good idea to favor CLI tools when at all reasonable to do so, > while you seem to think it's a good idea to favor GUI tools when at all > reasonable to do so. We agree on the extremes, but not in the middle, in > other words. I just wish that we could agree without it feeling like > you're trying to convince people they shouldn't ever bother learning how > to use CLI tools unless they absolutely have to. Well, I think to some extent we are considering two different sets of people. If a programmer or sysadmin doesn't use the CLI, they probably aren't very good at their job, since they are missing out on a lot of tools. I was thinking more generally about end-users, who tend to be very reluctant to use the CLI (the whole there's a big black box, what do I do now? thing is intimidating) and it is usually more trouble than it is worth to convince them to use the CLI, even if it would make their jobs easier. Most general computer users will never give up the GUI, because it involves investing in computer skills and they don't see that as terribly worthwhile - they just want to get started on their work. I think some UNIX fans are reluctant to accept this, and in doing so limit its ability to grow. That's my reason for preferring GUI in most situations. -- Rob Farmer ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
Quoth Chad Perrin on Thursday, 11 November 2010: > On Wed, Nov 10, 2010 at 06:09:15PM +, Bruce Cran wrote: > > On Wed, 10 Nov 2010 09:57:17 -0800 > > Chip Camden wrote: > > > > > However, for automating repeated tasks (as distinguished from running > > > automated tests of the GUI itself), scripting a GUI is the wrong way > > > to do it. It's layering on an entirely unnecessary layer of > > > abstraction (the UI), and then working around it. > > > > This is why at least on Windows there's often a C/COM/.NET API that > > allows the same level of control that the GUI provides, so that > > customers can automate tasks. > > It's too bad such APIs require so much more knowledge, and present so > much more of a barrier to entry for automating tasks, than a simpler CLI > filter's interface provides via something like the Unix pipeline. > > -- > Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] True -- let's say the customer wants to have their application send email notifications. If I tell the customer to open a pipe to mutt or mail, they can pop that in and test it in a few minutes. If they have to automate Outlook, or use the MAPI or CDO interfaces, then we're talking about a project. In fact, I've billed quite a few hours doing just that sort of work. If all I cared about was the money I could fleece off of them, then I'd steer more customers towards these unnaturally complex solutions. -- Sterling (Chip) Camden| sterl...@camdensoftware.com | 2048D/3A978E4F http://camdensoftware.com | http://chipstips.com| http://chipsquips.com pgp2ByykDvnQV.pgp Description: PGP signature
Re: Tips for installing windows and freeBSD both.. anyone??
On Thu, Nov 11, 2010 at 09:21:51PM -0800, Rob Farmer wrote: > > Well, our info about this situation is limited, so it is hard to say > exactly what happened. This is true, but I think you assumed some things that were not implied by the description of the situation, and that you missed or ignored other parts of the description, and thus leapt to conclusions about why decisions were made when those conclusions were not the most reasonable. > > 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. In this case, it was clearly stated that the guy combined everything into a single "workbook" so that only one person at a time could work on it. No, a GUI in general does not preclude people working on it, but most GUI programs do, especially when everything's tied together in a single document (for some definition of "document") as was done in this case. Thus, the person's desire to use a particular GUI setup resulted in a process that precluded multiple people working on it at the same time. > > My reading of the anecdote was that the batch file was indeed easy to > use, 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). Yes, it was easy to use but no longer working when the entire process was changed and file formats were altered for no reason other than to start using a particular piece of software -- and to avoid using anything else. Usually, when someone changes a process for the express purpose of using nothing but the tools for the new process, the tools for the old process are out by definition, regardless of whether they're GUI tools. My point, though, was that your statement that this anecdote somehow proves that CLI tools are difficult to use was totally unsupported by the explanation of what happened. > > 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 > and move on. . . . or fail to notice that the program might actually be adequate because you did not bother to press F11. It sounds like in some respects we're violently agreeing with each other. On one hand, I think that CLI programs can be great for frequent tasks, especially if you have something like the Unix pipeline at your disposal to automate complex tasks, and that GUIs have some discoverability advantages; on the other hand, you think that GUI programs can be great for cases where someone does not want to take the time to learn a better way to do something, perhaps because he does not perform the tasks very often, but if you do something often enough it might make sense to learn a more efficient CLI-based way to do it. Another difference in our apparent approaches to this is that I think it's a good idea to favor CLI tools when at all reasonable to do so, while you seem to think it's a good idea to favor GUI tools when at all reasonable to do so. We agree on the extremes, but not in the middle, in other words. I just wish that we could agree without it feeling like you're trying to convince people they shouldn't ever bother learning how to use CLI tools unless they absolutely have to. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] pgpI6ieYVORUU.pgp Description: PGP signature
Re: Tips for installing windows and freeBSD both.. anyone??
On Thu, Nov 11, 2010 at 17:19, Chad Perrin 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. It wasn't the file format that changed; it was someone's tolerance > for using a keyboard instead of a mouse. This 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. 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. > > >> >> 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. > > That was not evident in the explanation of what happened. The > explanation suggested nothing about the batch file in question being > difficult to use (or "figure out"). From the sound of it, three > instructions on a 3x5 card would have sufficed to ensure everybody knew > what to do, except in the case of people who do not know how to operate a > keyboard. My reading of the anecdote was that the batch file was indeed easy to use, 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). >> >> 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. > > I think that GUIs are quite valuable when used where appropriate. I > think that the rest of the time, people greatly exaggerate the value of > the GUI, to the extent that they begin to think the CLI (as well as TUIs > in general) has no value at all. I used to be one of those idiots, and > there was a time when I would have been on your side of this little > debate. That was almost fifteen years ago. Times change, and I grow in > knowledge and experience. The end result is that I believe those who are > competent to operate a computer professionally would benefit from > learning how to use the command line for those tasks that are more > efficiently performed without the GUI mediating the experience, at least > for almost any task that is performed with any regularity at all. 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 and move on. -- Rob Farmer ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
On Wed, Nov 10, 2010 at 06:09:15PM +, Bruce Cran wrote: > On Wed, 10 Nov 2010 09:57:17 -0800 > Chip Camden wrote: > > > However, for automating repeated tasks (as distinguished from running > > automated tests of the GUI itself), scripting a GUI is the wrong way > > to do it. It's layering on an entirely unnecessary layer of > > abstraction (the UI), and then working around it. > > This is why at least on Windows there's often a C/COM/.NET API that > allows the same level of control that the GUI provides, so that > customers can automate tasks. It's too bad such APIs require so much more knowledge, and present so much more of a barrier to entry for automating tasks, than a simpler CLI filter's interface provides via something like the Unix pipeline. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] pgp6dzyueAeqZ.pgp Description: PGP signature
Re: Tips for installing windows and freeBSD both.. anyone??
On Tue, Nov 09, 2010 at 06:10:54PM -0800, Rob Farmer wrote:
> On Tue, Nov 9, 2010 at 16:09, Robert Bonomi wrote:
> > 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.
>
> 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.
It is different in that multiple tools are easily chained together via
the Unix pipeline, whereas a single GUI has to encompass all of the
actions possible to perform at a single time, thus resulting in a far
more narrow set of limitations on what can reasonably be provided as
options. In fact, a set of CLI filters linked together by the Unix
pipeline (or even a DOS pipeline, at least in theory) is essentially
infinitely extensible to provide surprising levels of automation
customizability that might astonish the earlier creators of some of the
older tools being used, while an extension system for a GUI application
necessarily has to predefine what is possible, and obfuscates the inner
workings of the extended application behind designs that are largely
opaque to the user.
> >
> > 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.
>
> The CLI doesn't generalize either. How many ways are there to get
> input into a program?
You might be surprised by how many different ways of getting data into a
program can be accomplished with a simple Perl idiom like this:
while (<>) {
}
It gets pretty generalized in a hurry.
>
> 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.
. . . and it is shortly after that point that things get very specific,
and non-general.
>
> >
> > 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
Re: Tips for installing windows and freeBSD both.. anyone??
On Tue, Nov 09, 2010 at 01:21:01AM -0800, per...@pluto.rain.com wrote: > Polytropon wrote: > > > The STRENGTH OF GUI (yes, I'm really saying that) is to aid > > using language elements, CLI. Arranging windows, presenting > > information, displaying structures, managing things. GUI > > alone, with no functional substance behind it, is useless. > > Sadly, you'll find more and more programs that have blingbling > > and "experience", but are useless to those who want to achieve > > a certain goal with it. > > Another strength, potentially large but all-too-frequently > overlooked entirely, is as a learning aid. In the situation > that operations in the GUI map reasonably well to TUI commands > -- which by definition includes cases in which the GUI is used > as a front-end to issue commands to an external TUI-based program > -- the GUI really should have a mode wherein it displays or logs > the TUI commands that it is performing. I agree. That is one type of GUI I would really love to see getting more popular. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] pgpqDjX9iOn4p.pgp Description: PGP signature
Re: Tips for installing windows and freeBSD both.. anyone??
On Wed, 10 Nov 2010 09:57:17 -0800 Chip Camden wrote: > However, for automating repeated tasks (as distinguished from running > automated tests of the GUI itself), scripting a GUI is the wrong way > to do it. It's layering on an entirely unnecessary layer of > abstraction (the UI), and then working around it. This is why at least on Windows there's often a C/COM/.NET API that allows the same level of control that the GUI provides, so that customers can automate tasks. -- Bruce Cran ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
Quoth Michael Ross on Wednesday, 10 November 2010: > Am 10.11.2010, 01:09 Uhr, schrieb Robert Bonomi : > > >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. > > For Windows OSes there is actually a rather nice tool out there, > > http://www.autoitscript.com/autoit3/ > > which allows you to script the GUI cross-app. > > Regards, > > Michael > > > ___ > 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" Yes, there are a number of tools that allow one to script a GUI, many of which do not require knowledge of exactly where Gui element is located. However, for automating repeated tasks (as distinguished from running automated tests of the GUI itself), scripting a GUI is the wrong way to do it. It's layering on an entirely unnecessary layer of abstraction (the UI), and then working around it. -- Sterling (Chip) Camden| sterl...@camdensoftware.com | 2048D/3A978E4F http://camdensoftware.com | http://chipstips.com| http://chipsquips.com pgpEDviPYbUlX.pgp Description: PGP signature
Re: Tips for installing windows and freeBSD both.. anyone??
Quoth Rob Farmer on Tuesday, 09 November 2010: > On Tue, Nov 9, 2010 at 16:09, Robert Bonomi wrote: > > 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. > > 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. I don't know how anyone who has done much automation could say such a thing. Command lines and pipes offer an exponentially greater set of possibilities than could ever be presented in a GUI. I don't know about others, but I spent many years being pro-GUI. I led the charge for getting software companies to port their applications to Windows and use IDEs for development. It is only recently that I have come to my senses. I should have known better. Back in the 80s when I worked on tax preparation software, the marketing department wanted a more demoable UI. So we put a ton of time into creating an interface that looked like the IRS forms, instead of the one we had where the user keyed in a code that indicated what line on what form they wanted to input, followed by the input itself. When we released this, the marketing department loved it, our customers' higher-ups thought it was nice, but the actual input operators hated it. They were evaluated on how much data they could enter, not on their enjoyment of 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. > > 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=yy 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 > > 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;
Re: Tips for installing windows and freeBSD both.. anyone??
On Wednesday 10 November 2010 06:21:18 Bruce Cran wrote: > On Wed, 10 Nov 2010 04:02:34 +0100 > > "Michael Ross" wrote: > > For Windows OSes there is actually a rather nice tool out there, > > > > http://www.autoitscript.com/autoit3/ > > > > which allows you to script the GUI cross-app. > > Microsoft also have the UI Automation API to script GUI applications. In my humble experience, I think there are 2 distinct aspects to this issue. I use FBSD both as desktop and as server. In practice, I need a GUI for desktop work and none whatsoever for server work. The only time I needed some kind of GUI component on a server was when I wanted to test a VM on it and I wanted the comodity of running VirtualBox console on my desktop. Other than that, the command line is more than enough. OTOH, for the kind of work that I do, having 4 workspaces is absolutely handy. And to be able to switch between these 4 scenarios with the scroll of a middle button is definetly a plus. just my 0,02 cents. -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio YET!!] (99% winfoes FREE) ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
On Wed, 10 Nov 2010 04:02:34 +0100 "Michael Ross" wrote: > For Windows OSes there is actually a rather nice tool out there, > > http://www.autoitscript.com/autoit3/ > > which allows you to script the GUI cross-app. Microsoft also have the UI Automation API to script GUI applications. -- Bruce Cran ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
Polytropon wrote: > The STRENGTH OF GUI (yes, I'm really saying that) is to aid > using language elements, CLI. Arranging windows, presenting > information, displaying structures, managing things. GUI > alone, with no functional substance behind it, is useless. > Sadly, you'll find more and more programs that have blingbling > and "experience", but are useless to those who want to achieve > a certain goal with it. Another strength, potentially large but all-too-frequently overlooked entirely, is as a learning aid. In the situation that operations in the GUI map reasonably well to TUI commands -- which by definition includes cases in which the GUI is used as a front-end to issue commands to an external TUI-based program -- the GUI really should have a mode wherein it displays or logs the TUI commands that it is performing. ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
Am 10.11.2010, 01:09 Uhr, schrieb Robert Bonomi : 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. For Windows OSes there is actually a rather nice tool out there, http://www.autoitscript.com/autoit3/ which allows you to script the GUI cross-app. Regards, Michael ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
On Tue, Nov 9, 2010 at 16:09, Robert Bonomi wrote: > 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. 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 > '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. 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=yy 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 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. This isn't really a GUI problem, because
Re: Tips for installing windows and freeBSD both.. anyone??
> Date: Mon, 8 Nov 2010 09:43:01 + > 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 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. ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
On Mon 08 Nov 2010 at 02:06:24 PST Matthias Apitz wrote: I think this philosofic discussion has little or nothing todo with FreeBSD. Could you move this elsewhere, or off-list? Thanks It's also a very very OLD argument. Surely the debating points have already been collected on a webpage somewhere? If not, I would suggest the participants direct their energies into creating one, so that their wisdom shall be preserved for posterity. ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
On Mon, 8 Nov 2010 09:32:20 -0700 Chad Perrin wrote: > You probably found it "inefficient" because you did not bother to gain > sufficient familiarity with it to enjoy the efficiencies it provided. > Seriously. In my experience, development on MS Windows with clicky > GUI tools like Visual Studio only seems more efficient when doing > things that are very well-worn paths to very uninteresting > destinations for people who have never bothered to learn a better > way. A well-configured Vim provides a substantial efficiency boost > for the competent user that dwarfs the dubious benefits of things > like Intellisense, for instance. If you're clicking lots you're doing something wrong :) I think the key thing is "well-configured". I've found that far too many users have poorly-configured systems that require them to drop to a terminal and type commands when they want to run builds, find where something's defined etc. That involves find, grep etc. which is far less efficient than clicking the (the built-in) "Go to definition" command or hitting the shortcut key within an IDE; I know the same can be done in vim by defining macros for building, running ctags/cscope etc. I'm not convinced about IntelliSense either, really. At one job I found people dependended totally on it, and complained when it broke. I find I use it as a productivity enhancement when I know roughly what parameters a function takes but can't remember the ordering - it's more useful when you have a huge framework like Java or .NET, or an overly complex API like WinAPI (e.g. CreateFile). Too many people _do_ depend on it though, which I think introduces an inefficiency in their work. In terms of efficient use of Visual Studio it takes time to learn and become a competent user: for example I hardly ever use the menus since they're so slow to access. I hardly leave the keyboard and hate watching people waste time for example clicking Build, moving to the Build Solution entry and clicking when I could have done it in a fraction of the time using Ctrl-Shift-B. I know vim, with suitable plugins and macros, can be made to be more efficient than Visual Studio since it doesn't require ever using the mouse but the upfront investment in time to learn and configure it is something I've never done, mainly because I've always had more important things to learn and the "inefficiencies" of GUI editors don't really worry me. -- Bruce Cran ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
On Mon, Nov 08, 2010 at 09:43:01AM +, Bruce Cran wrote: > On Sun, 7 Nov 2010 23:17:23 -0700 > Chad Perrin 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. You probably found it "inefficient" because you did not bother to gain sufficient familiarity with it to enjoy the efficiencies it provided. Seriously. In my experience, development on MS Windows with clicky GUI tools like Visual Studio only seems more efficient when doing things that are very well-worn paths to very uninteresting destinations for people who have never bothered to learn a better way. A well-configured Vim provides a substantial efficiency boost for the competent user that dwarfs the dubious benefits of things like Intellisense, for instance. When developing software in a Unix(-like) environment, I typically have *several* terminals open, running different programs. For Ruby, for instance, I might have a Vim terminal, an irb terminal, and a test suite terminal, possibly including a second buffer in the test suite terminal for running the program separately when appropriate -- rather than just "using just an xterm" -- and it works better than any Visual Studio setup I've encountered on MS Windows for similar development. In fact, there are whole classes of software that are effectively impossible to develop effectively on MS Windows; it doesn't get much more inefficient than that. Sometimes a GUI that brings things together can help. You're right about that. Unfortunately, such GUIs usually shoot themselves in the foot by not just bringing things together, but actually replacing them so that the benefits of the separate things are lost, resulting in a net loss of productivity enhancement. That's what I get from IDEs like Visual Studio. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] pgpbkrmkvI7BP.pgp Description: PGP signature
Re: Tips for installing windows and freeBSD both.. anyone??
On Mon, 8 Nov 2010 11:00:59 +0100 Polytropon wrote: > On Mon, 8 Nov 2010 09:43:01 +, Bruce Cran > wrote: > > [...] I do think a well-designed GUI can increase productivity by > > bringing things together that would otherwise be separate. > > Yes. Plain YES. I'm just waiting for the GUI that actually DOES > that. :-) Try KDevelop. It brings together an editor, file manager, debugger, etc. into a single application. Similarly I find the KDE file manager can increase productivity for _certain_ things such as working on a remote filesystem (via ssh/samba/ftp) because it brings ssh/ftp functionality to a file manager. I do still find it more efficient to use the command-line when working locally though :) -- Bruce Cran ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
El día Monday, November 08, 2010 a las 10:56:00AM +0100, Polytropon escribió: > On Sun, 7 Nov 2010 23:17:23 -0700, Chad Perrin wrote: > > So, let's see here -- either I lose efficiency on things that aren't very > > familiar to me, because I have to type `foo --help` or `man foo` or > > something like that, or I lose efficiency on things I do all the time, > > because I have to mouse around a lot. > > > > Hmm. I wonder which I should choose. > > Why choose? Combine efficiently! :-) ... Hi folks, I think this philosofic discussion has little or nothing todo with FreeBSD. Could you move this elsewhere, or off-list? Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
On Mon, 8 Nov 2010 09:43:01 +, Bruce Cran wrote: > [...] I do think a well-designed GUI can increase productivity by > bringing things together that would otherwise be separate. Yes. Plain YES. I'm just waiting for the GUI that actually DOES that. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
On Sun, 7 Nov 2010 23:17:23 -0700, Chad Perrin wrote: > So, let's see here -- either I lose efficiency on things that aren't very > familiar to me, because I have to type `foo --help` or `man foo` or > something like that, or I lose efficiency on things I do all the time, > because I have to mouse around a lot. > > Hmm. I wonder which I should choose. Why choose? Combine efficiently! :-) > I > select and middle click to paste quite a lot. This is much better than the ^C/^V approach, as seems to be supported by every application, no matter which "echosystem" it comes from. Every? Erm... no. Did I recently talk about bloat? About reduction of functionality? I did. Allow me to elaborate on an example. It's a Gtk version 2 example. Let's say it's X-Chat 2. It's the channel selection dialog on startup. In version 1 (using Gtk), you could select an item from a list using doubleclick on that item. In version 2, you are forced to select the item with one click, move the mouse to a button and then click that. First: t(2cl) > t(1cl + move + 1cl). Then what happens if you still doubleclick on a list item? It becomes an input field. Well, hmmm... could be useful. Let's put some text in there from another program window. Oops, the window lost focus, and the input field got a list item again! Okay, not a big deal, we'll be back soon. After selecting the text (e. g. in a browser, a text editor, whatever), again clicking the list item, it gets an input field. Middle mouse... erm, middle mouse... middle mouse... why doesn't this work? Buffer empty? Check in an xterm... no, text is in the buffer. WHAT'S WRONG?! So what did Gtk 2 achieve here? 1. increased time for selection 2. inability to use copy / paste 3. - the most annoying one - FORCING to type (even if this just means ^C/^V) I really can't stand it when BASIC functionality disappears with NO understandable effect. Fatter libraries, longer time until program is up, and then everything gets slower and much less productive -- that must be bloat. > I'm not opposed to use of > the GUI per se; I just use TUIs much more often, because I use them for > tasks that I perform an awful lot if they happen to benefit (in terms of > efficiency and productivity) by the use of a TUI. When they don't, I use > a GUI instead. That exactly is an educated standpoint - use whatever tool is the best - instead of insisting that the tool HAS TO BE a GUI tool, like saying: "But I WANT the screwdriver to be a drill! I've ALWAYS used screwdrivers as drills, and EVERYONE uses screwdrivers as drills! Oh, and it should work as a hammer, too." By the way, TUI (text user interface) doesn't imply that is has to be CLI (command line interface). A famous example from by daily use is the Midnight Commander, a file manager that DOES IT CORRECTLY. As many (most?) things you do is a source-target- opertion (copying, moving, symlinking), the two-panel mode is the ideal solution. Good keyboard controls and the use of the very useful function keys is one of its strengths. Still, it does operate in text mode (defaults to 80x25, but can be used at any window size), so you can easily work with it over a serial line or SSH. GUI usually means abstraction. Abstraction adds layers, in this way or another. At some point, this is good as you can "fit things together", but at some point, it gets unusable because you can't address the things directly you NEED to address directly. > I wouldn't be willing to waste the time on little inefficiencies every > single time I did *anything* with Subversion just for the dubious benefit > of a one-time efficiency benefit once a year because I didn't remember off > the top of my head how to branch, though. >From computer science, just see what "O notation" means, and see that constant compexity is traditionally better than linear complexity: O(1) < O(n). :-) > I suppose your mileage may vary, though. It always depends on individual preferences, talents, knowledge and experience. I'm always impressed by people who are more advanced than me, who use "minimalistic" environments and can work faster, more productive, more relaxed. Allthough the tools they use may look "archaic", "not modern", "old" and "difficult" to me, given knowledge and experience they DE FACTO are better for them. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
On Sun, 7 Nov 2010 23:17:23 -0700 Chad Perrin 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. -- Bruce Cran ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
On Sun, 7 Nov 2010 14:41:09 -0800, Chip Camden wrote: > Up to a point, yes. But as options become more complex, either the GUI > must also become more complex or you reach the tipping point where the > complexity warrants the use of language instead of gestures. This is a valid point. There was a statement - no idea who said or wrote that - expressing it well, and I'm sure I'm mapping it into context right now: GUI makes simple tasks simpler. It also makes complex tasks impossible. As a GUI is only "choosing from a predefined subset of options", complex tasks make the corresponding GUI more complex. This may proceed until the GUI isn't usable anymore. At this point, it gets abandoned, naturally. According to your point gestures vs. languages: Consider being a child. When you didn't have the ability to use language, you did point to objects and made a sound, "ga!" or "dah!" or whatever. Later on, when you learned to use the language, it started at not being perfect, but you kept learning it and then used it to express wishes, thoughts, needs. In this way, you did abandon pointing and "dah!". Why? It should have worked continuously - e. g. there was no obvious reason others would stop interacting with you at that non-language level. But that is how intellectual development works. It is an evolutionary consideration. Applying this to GUI and CLI concepts, GUI, pointing and clicking, resembles the childish way of nonverbal communication. CLI, forming statements using a language, is like verbal communication. The STRENGTH OF GUI (yes, I'm really saying that) is to aid using language elements, CLI. Arranging windows, presenting information, displaying structures, managing things. GUI alone, with no functional substance behind it, is useless. Sadly, you'll find more and more programs that have blingbling and "experience", but are useless to those who want to achieve a certain goal with it. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
On Sun, 7 Nov 2010 22:07:29 +, Bruce Cran wrote:
> With the command-line you also choose the inefficiency of having to
> read the man page every time you want to do something you're not
> familiar with.
Not fully. The strength of the command line is (1st) that things
you learned can easily be transferred to new topics, and (2nd)
you can conclude from what you already know.
GUI usually is a "discover new things each time"; as a good
example I may point you to famous office suits that tend to
re-arrange their functionality with each release.
> Well-designed UIs allow you to easily discover how to do
> it without resorting to the Help file - and since people tend to have
> good visual memories they can remember it better than a string of
> characters.
Okay, you're comparing visual memory ("looks like") to the
use of language (a "foreign" one, admitted), which is a
basic cultural means (the use of a language).
Following your argument, it is obvious that many GUI applications
are NOT well-designed, as they force their users to continuously
re-discover and re-learn things.
Additionally, GUI prohibits giving clear instructions. Those
that can be copied+pased are out of scope, of course. Instructions
look like childrens books - full of pictures. This is logical
as there is no benefit in DESCRIBING those pictures - would
be too much text, text scares users.
Learning CLI is like learning a language: If you're once
familiar with the elements of the language (its vocabulary,
its syntax, its use), you can express ANYTHING with it. With
GUI, you're just free to choose from a predefined and LIMITED
set of options. You can choose from "ready-made sentences",
but you can't express your own statements.
The CLI approach leads to a continuous growth of knowledge
(that is portable), while the GUI approach often just leads
into stagnation.
A real benefit of GUI, as I can admit without any problems,
is that people judge by first sight. This is a visual impression
that has nothing to do with any knowledge, it's just like
saying "I like Da Vinci's 'Mona Lisa', but I don't like Edvard
Munch's 'Scream'." Keep in mind this is a VALID statement
that does not require any knowledge to be formed.
By well-designed GUI, products can easily be placed on markets.
Advertising based on visual impression works much better for
masses (!) than product presentation based on actual features
(that require knowledge to form a statement about them).
> A good example of this is Subversion tagging/branching: in
> Windows I can use the menu option "TortoiseSVN -> branch/tag..." to
> create a branch and have it done in a minute. Using the command-line
> I'd have to spend time reading up on the commandline parameters to
> achieve the same thing, since it's something I only do about once a
> year or so.
In a different Subversion GUI client, this functionality may
be found at a completely different place. CLI applications
usually have more things in common than GUI applications.
That said, you can easily see why generic UNIX knowledge, no
matter if achieved on BSD, Solaris, Linux or AIX, is portable,
while GUI knowledge, achieved in a "Windows" of version N, is
not portable to version N+1, as it is outdated. There even is
no generic knowledge, one may assume.
Let me ensure you that I'm NOT against GUI generically. I'm
even lazy when it comes to reconsidering my daily habits of
interacting with the system. :-)
--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
___
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"
Re: Tips for installing windows and freeBSD both.. anyone??
On Sun, Nov 07, 2010 at 10:07:29PM +, Bruce Cran wrote: > On Sun, 7 Nov 2010 13:51:22 -0700 > Chad Perrin wrote: > > > I choose a little up-front learning curve for massive efficiency and > > productivity enhancements down the road. The increased efficiency of > > a minimal, composable toolset driven by the keyboard can be a huge > > win in long-term productivity for one motivated to learn how to use > > it, as well as a major savings on system resources (and hardware > > costs, since upgrades do not need to happen as often, nor be as > > cutting-edge). > > > > Others choose some inefficiency in the long run to avoid having to > > learn anything new up front. The increased discoverability, at least > > for simple tasks, of a point-and-click interface tends to seem more > > "intuitive" and familiar to people just coming to a new system for the > > first time, makes task completion easier to figure out the first time > > (and the thirtieth, since point-and-click interfaces tend to require > > figuring out the same tasks over and over again). > > With the command-line you also choose the inefficiency of having to > read the man page every time you want to do something you're not > familiar with. Well-designed UIs allow you to easily discover how to do > it without resorting to the Help file - and since people tend to have > good visual memories they can remember it better than a string of > characters. A good example of this is Subversion tagging/branching: in > Windows I can use the menu option "TortoiseSVN -> branch/tag..." to > create a branch and have it done in a minute. Using the command-line > I'd have to spend time reading up on the commandline parameters to > achieve the same thing, since it's something I only do about once a > year or so. So, let's see here -- either I lose efficiency on things that aren't very familiar to me, because I have to type `foo --help` or `man foo` or something like that, or I lose efficiency on things I do all the time, because I have to mouse around a lot. Hmm. I wonder which I should choose. Seriously, though, it's not like I never use GUI tools. I occasionally use the mouse when dealing with stuff in the browser, for instance. I select and middle click to paste quite a lot. I'm not opposed to use of the GUI per se; I just use TUIs much more often, because I use them for tasks that I perform an awful lot if they happen to benefit (in terms of efficiency and productivity) by the use of a TUI. When they don't, I use a GUI instead. I wouldn't be willing to waste the time on little inefficiencies every single time I did *anything* with Subversion just for the dubious benefit of a one-time efficiency benefit once a year because I didn't remember off the top of my head how to branch, though. I use Mercurial a *lot*, and I do not see much benefit to using a GUI for it just on the off-chance I might need to do something I don't do very often when the GUI only gets in the way for the stuff I do several times a day, every day. I suppose your mileage may vary, though. 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. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] pgpfFM40YtiiH.pgp Description: PGP signature
Re: Tips for installing windows and freeBSD both.. anyone??
Quoth Bruce Cran on Sunday, 07 November 2010: > On Sun, 7 Nov 2010 13:51:22 -0700 > Chad Perrin wrote: > > > I choose a little up-front learning curve for massive efficiency and > > productivity enhancements down the road. The increased efficiency of > > a minimal, composable toolset driven by the keyboard can be a huge > > win in long-term productivity for one motivated to learn how to use > > it, as well as a major savings on system resources (and hardware > > costs, since upgrades do not need to happen as often, nor be as > > cutting-edge). > > > > Others choose some inefficiency in the long run to avoid having to > > learn anything new up front. The increased discoverability, at least > > for simple tasks, of a point-and-click interface tends to seem more > > "intuitive" and familiar to people just coming to a new system for the > > first time, makes task completion easier to figure out the first time > > (and the thirtieth, since point-and-click interfaces tend to require > > figuring out the same tasks over and over again). > > With the command-line you also choose the inefficiency of having to > read the man page every time you want to do something you're not > familiar with. Well-designed UIs allow you to easily discover how to do > it without resorting to the Help file - and since people tend to have > good visual memories they can remember it better than a string of > characters. A good example of this is Subversion tagging/branching: in > Windows I can use the menu option "TortoiseSVN -> branch/tag..." to > create a branch and have it done in a minute. Using the command-line > I'd have to spend time reading up on the commandline parameters to > achieve the same thing, since it's something I only do about once a > year or so. > > -- > Bruce Cran Up to a point, yes. But as options become more complex, either the GUI must also become more complex or you reach the tipping point where the complexity warrants the use of language instead of gestures. -- Sterling (Chip) Camden| sterl...@camdensoftware.com | 2048D/3A978E4F http://camdensoftware.com | http://chipstips.com| http://chipsquips.com pgpsjl5Kwh2Uf.pgp Description: PGP signature
Re: Tips for installing windows and freeBSD both.. anyone??
On Sun, 7 Nov 2010 13:51:22 -0700 Chad Perrin wrote: > I choose a little up-front learning curve for massive efficiency and > productivity enhancements down the road. The increased efficiency of > a minimal, composable toolset driven by the keyboard can be a huge > win in long-term productivity for one motivated to learn how to use > it, as well as a major savings on system resources (and hardware > costs, since upgrades do not need to happen as often, nor be as > cutting-edge). > > Others choose some inefficiency in the long run to avoid having to > learn anything new up front. The increased discoverability, at least > for simple tasks, of a point-and-click interface tends to seem more > "intuitive" and familiar to people just coming to a new system for the > first time, makes task completion easier to figure out the first time > (and the thirtieth, since point-and-click interfaces tend to require > figuring out the same tasks over and over again). With the command-line you also choose the inefficiency of having to read the man page every time you want to do something you're not familiar with. Well-designed UIs allow you to easily discover how to do it without resorting to the Help file - and since people tend to have good visual memories they can remember it better than a string of characters. A good example of this is Subversion tagging/branching: in Windows I can use the menu option "TortoiseSVN -> branch/tag..." to create a branch and have it done in a minute. Using the command-line I'd have to spend time reading up on the commandline parameters to achieve the same thing, since it's something I only do about once a year or so. -- Bruce Cran ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
On Sun, Nov 07, 2010 at 06:58:45PM +0100, Polytropon wrote: > On Sun, 7 Nov 2010 09:41:06 -0800, Chip Camden > wrote: > > I'm not here to bash desktop environments, I seriously want to know you use > > them to > > improve productivity. > > Yes, would be interesting to know. Not that I deny it - I just have > no evidence from my experience and observations on how this could > be achieved. I think that, in most cases, the people who use KDE and GNOME are just taking the trade-off opposite to the one I take. I choose a little up-front learning curve for massive efficiency and productivity enhancements down the road. The increased efficiency of a minimal, composable toolset driven by the keyboard can be a huge win in long-term productivity for one motivated to learn how to use it, as well as a major savings on system resources (and hardware costs, since upgrades do not need to happen as often, nor be as cutting-edge). Others choose some inefficiency in the long run to avoid having to learn anything new up front. The increased discoverability, at least for simple tasks, of a point-and-click interface tends to seem more "intuitive" and familiar to people just coming to a new system for the first time, makes task completion easier to figure out the first time (and the thirtieth, since point-and-click interfaces tend to require figuring out the same tasks over and over again). > > > Now I find that any time I reach for the mouse, I'm slowing myself down. > > A TrackPoint (the little joystick-like pointing device located > in the middle of the keyboard) seems to be a good repacement > for a regular mouse, and in any case for fingerslime glidepads. I use a ThinkPad regularly. Sometimes, it's nice to have a separate mouse. Even when using the TrackPoint, though, I'm still much slower than when using a well-designed keyboard driven interface. It takes longer for me to swing my mouse pointer from the side of the screen to a given link on-screen, then left click it, than it does for me to type "f37" in Firefox+Vimperator, "fas" in Chromium+Vimium, or "fl37" in uzbl. Also of interest, Chromium loads the page on the other side of that link in about 75% of the time it takes Firefox to load it, and uzbl loads it in about 33% of the time it takes Chromium to load it. > > > It's more efficient to use the keyboard even to switch focused windows > > or to follow links in a browser (provided that the window manager and > > browser are equipped with usable shortcuts). > > Important point! But in reality you see keyboard support more > and more left out for the GUI programs - allthough they COULD > provide good keyboard support. WindowMaker (as a window manager) > and Opera (as a web browser) are, in my experience, examples > of how to combine good keyboard support with good mouse support. Vimperator and Vimium do much better jobs of combining those capabilities in my experience (for Firefox and Chromium, respectively). While uzbl does not do as good a job of combining those approaches, it does a good enough job at the keyboard-driven stuff that it is a very rare case when using the TrackPoint would make more sense -- and, when it does make more sense, uzbl's mouse-driven interface support works fine. I used to use WindowMaker all the time. I switched to Sawfish when I disocovered that it required less configuration to fit my particular needs, though WindowMaker had been "close enough" that making the requisite configuration changes was not a huge burden. I switched to AHWM when I discovered it, because it required almost zero configuration to make it suit my needs pretty much exactly. I have experimented with a couple of other window managers since adopting AHWM, but nothing has quite served to entice me away. > > > I use a tiling wm (xmonad) to maximize visibility, real estate usage, and > > navigability. No overlapping windows unless I say so. > > Tiling window managers, as I've often seen, seem to be the choice > of the advanced / professional users. Sadly, their magic didn't > open up to me yet. :-) If you're inclined toward minimalism, productivity enhancement, and efficiency, and do not mind editing configuration files by hand, but have not really clicked with tiling window managers, you might want to give AHWM a try. It's in FreeBSD ports. > > Coming back to your initial statement: For users EXPECTING something > to act in a specific way, KDE and Gnome really "boost" their > productivity, as it doesn't force them to question or relearn > things they take for granted. That's a pretty good summary, minus some of the implications, of what I said at the beginning of this email. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] pgppCqFJOKC7f.pgp Description: PGP signature
Re: Tips for installing windows and freeBSD both.. anyone??
On Sun, 7 Nov 2010 12:23:36 +0100 Polytropon articulated: > > To answer the question, "What does KDE or GNOME buy you anyway?", > > the answer is nothing. They have never even brought me a cup of > > coffee. > > You need to install Kaffeine. :-) Touché -- Jerry ✌ freebsd.u...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ "The administration I'll bring is a group of men and women who are focused on what's best for America --- honest men and women, decent men and women, women who will see service to our country as a great privilege and who will not stain the house." George W. Bush January 15, 2000 Spoken during the Republican debate in Des Moines, Iowa. ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
On Sun, 7 Nov 2010 09:41:06 -0800, Chip Camden wrote: > I'm not here to bash desktop environments, I seriously want to know you use > them to > improve productivity. Yes, would be interesting to know. Not that I deny it - I just have no evidence from my experience and observations on how this could be achieved. > I used to be a big believer in GUIs. I may admit that the more I'm using GUI based programs for everyday tasks regularly (e. g. MUA), I get more and more disappointed that it seems that I need to buy a new PC in order to keep the same average speed of operation. > Now I find that any time I reach for the mouse, I'm slowing myself down. A TrackPoint (the little joystick-like pointing device located in the middle of the keyboard) seems to be a good repacement for a regular mouse, and in any case for fingerslime glidepads. > It's more efficient to use the keyboard even to switch focused windows > or to follow links in a browser (provided that the window manager and > browser are equipped with usable shortcuts). Important point! But in reality you see keyboard support more and more left out for the GUI programs - allthough they COULD provide good keyboard support. WindowMaker (as a window manager) and Opera (as a web browser) are, in my experience, examples of how to combine good keyboard support with good mouse support. > I use a tiling wm (xmonad) to maximize visibility, real estate usage, and > navigability. No overlapping windows unless I say so. Tiling window managers, as I've often seen, seem to be the choice of the advanced / professional users. Sadly, their magic didn't open up to me yet. :-) > That's my experience. How does yours differ, and how does KDE/GNOME > help? Again, I may share a very individual opinion about KDE and Gnome. If you're coming from a "Windows" background, things seem to be logical and "as expected" in those environments. If you're from a UNIX / X background, things look overcomplicated, illogical, and somewhat strange (like using the edit buffer for copying and moving files, the inability to handle windows focus and foreground independently). So a person like myself would have to spend many time clicking around in KDE or Gnome in order to configure it into something halfway usable. KDE and Gnome represent "(quite) closed ecosystems": There are programs for KDE, similar ones for Gnome, and they interact well with each other within their ecosystems. Mixed forms, a strength of generic UNIX and X applications, often becomes complicated. Even language issues (i18n) are typical symptoms of that "closed- ness". Coming back to your initial statement: For users EXPECTING something to act in a specific way, KDE and Gnome really "boost" their productivity, as it doesn't force them to question or relearn things they take for granted. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
Quoth Bruce Cran on Sunday, 07 November 2010: > On Sat, 6 Nov 2010 15:54:46 -0700 > Chip Camden wrote: > > > What does KDE or GNOME buy you anyway? Besides overhead. > > I don't expect to be able to convince you, but a lot of people find > desktop environments easier to use than a whole load of terminals. For > example I sometimes prefer to use kdiff3 instead of plain "svn diff" > and KDE makes that simple. > > -- > Bruce Cran > ___ > 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" I'm not here to bash desktop environments, I seriously want to know you use them to improve productivity. I used to be a big believer in GUIs. Back in the early 90s, I experimented with creating my own completely visual development environment, with a high percentage of drag 'n' drop and doubleclick in place of command lines. Now I find that any time I reach for the mouse, I'm slowing myself down. It's more efficient to use the keyboard even to switch focused windows or to follow links in a browser (provided that the window manager and browser are equipped with usable shortcuts). I use a tiling wm (xmonad) to maximize visibility, real estate usage, and navigability. No overlapping windows unless I say so. That's my experience. How does yours differ, and how does KDE/GNOME help? -- Sterling (Chip) Camden| sterl...@camdensoftware.com | 2048D/3A978E4F http://camdensoftware.com | http://chipstips.com| http://chipsquips.com pgp1fRxrSCZML.pgp Description: PGP signature
Re: Tips for installing windows and freeBSD both.. anyone??
On 2010-11-07 12:44, Mubeesh ali wrote: I guess the virtualbox supplied under puel license has full USB support. may be good to check out if you are not averse to a more restrictive licensing. With the OSE version in the ports tree I've not considered the PUEL version. Can you provide links on how to install it? Thanks /Leslie ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
I guess the virtualbox supplied under puel license has full USB support. may be good to check out if you are not averse to a more restrictive licensing. On Sun, Nov 7, 2010 at 3:39 AM, Leslie Jensen wrote: > > >>> >>> >>> On Sat, Nov 6, 2010 at 11:01 AM, Tushar wrote: >>> I want to use windows and freeBSD, both of them at the same time... please help... > > > I use Win7 and FreeBSD in a dualboot configuration because of the need for > USB connectivity for some of the Windows apps. > > I have Garmin mapsource for my GPS and iTunes for my iPod. > > /Leslie > ___ > 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" > -- Best Regards, Mubeesh Ali.V.M ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
On Sat, Nov 6, 2010 at 11:01 AM, Tushar wrote: I want to use windows and freeBSD, both of them at the same time... please help... I use Win7 and FreeBSD in a dualboot configuration because of the need for USB connectivity for some of the Windows apps. I have Garmin mapsource for my GPS and iTunes for my iPod. /Leslie ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
On Sun, 7 Nov 2010 05:51:42 -0500, Jerry wrote: > On Sun, 7 Nov 2010 09:43:12 +0100 > Polytropon articulated: > > > On Sat, 6 Nov 2010 15:54:46 -0700, Chip Camden > > wrote: > > > What does KDE or GNOME buy you anyway? Besides overhead. > > > > Bloat. :-) I was just kidding, but maybe you want a serious discussion about terminology, well, no problem. :-) > Bloat can easily be defined as something one user does not > need/require. As my understanding, bloat refers to the tradition, mainly driven by "rapid application development", to stack tons of dependencies and abstraction layers in order to re-implement existing functionality in programs that ugraded some of their main libraries. This usually goes along with a reduction of accessibility or ease of use. Furthermore, resource requirements increase, and overall usage speed goes down. Often this is caused by stuff that nobody needs, because it is totally UNUSABLE. This is bloat. > Essential can conversely be defined as something a user needs/desires. Agreed. > In other works, your bloat can easily be another user's requirements. At least I'm willing to admit that it *might* be that there are users who require software that justifies buying a new computer twice a year to keep them doing the same things. In conclusion, it might also be possible that some users enjoy waiting times. > If you are happy wiping your ass with your bare hand, then fine. Many > of use prefer to use toilet paper which perhaps you might define as > "toiletry bloat." Don't they own a toilet brush? :-) Okay, I'm getting serious again: The basic idea is having certain requirements. Those requirements emerge from personal opinions, experiences, and needs, and also from a growing amount of expectations. That whatever fits those requirements is the ideal solution. In one case, this can be KDE, in another case, this is Windowmaker, and in a third case, this is SSH. There is no way of saying "one KDE fits all" or similar. > To answer the question, "What does KDE or GNOME buy you anyway?", the > answer is nothing. They have never even brought me a cup of coffee. You need to install Kaffeine. :-) > Now, > if the user were to inquire as to what these two competing applications > have to offer, I might suggest that he/she start by visiting the > applications respective web sites for further details. Even more imporant, it's worth TRYING them. In use - and see how well they work. For example, I've been using KDE and Gnome in the past, and even try them from time to time to see how they did develop and if those requirements *I* have are already met. There are also many alternatives in the GUI sector, and even "split mode" is possible, e. g. use Blackbox as window manager, but use some of the KDE and Gnome programs side by side. THIS IS THE STRENGTH OF CHOICE. Especially novice users do not want choice. They primarily want something preinstalled and preconfigured. This is okay. The PC-BSD system fits this requirement well. Still, you have to make sure that certain requirement OF THE SOFTWARE are met, e. g. recent hardware that is supported (not too old, not too new). If hardware dictates what you can use (not just install and run, but ACTUALLY use), then KDE and Gnome are often a total no-go. Bloat, to come back to my initial statement, is the main cause of no-go. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
On Sun, 7 Nov 2010 09:43:12 +0100 Polytropon articulated: > On Sat, 6 Nov 2010 15:54:46 -0700, Chip Camden > wrote: > > What does KDE or GNOME buy you anyway? Besides overhead. > > Bloat. :-) Bloat can easily be defined as something one user does not need/require. Essential can conversely be defined as something a user needs/desires. In other works, your bloat can easily be another user's requirements. If you are happy wiping your ass with your bare hand, then fine. Many of use prefer to use toilet paper which perhaps you might define as "toiletry bloat." To answer the question, "What does KDE or GNOME buy you anyway?", the answer is nothing. They have never even brought me a cup of coffee. Now, if the user were to inquire as to what these two competing applications have to offer, I might suggest that he/she start by visiting the applications respective web sites for further details. -- Jerry ✌ freebsd.u...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ Life is tough, but it's tougher when you're stupid. John Wayne signature.asc Description: PGP signature
Re: Tips for installing windows and freeBSD both.. anyone??
On Sat, 6 Nov 2010 15:54:46 -0700 Chip Camden wrote: > What does KDE or GNOME buy you anyway? Besides overhead. I don't expect to be able to convince you, but a lot of people find desktop environments easier to use than a whole load of terminals. For example I sometimes prefer to use kdiff3 instead of plain "svn diff" and KDE makes that simple. -- Bruce Cran ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
On Sat, 6 Nov 2010 15:54:46 -0700, Chip Camden wrote: > What does KDE or GNOME buy you anyway? Besides overhead. Bloat. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
On Sat, Nov 6, 2010 at 6:54 PM, Chip Camden wrote:
> Quoth Chad Perrin on Saturday, 06 November 2010:
> > On Sat, Nov 06, 2010 at 08:02:39PM +, Bruce Cran wrote:
> > > On Sat, 6 Nov 2010 12:09:34 -0700
> > > Chip Camden wrote:
> > >
> > > > Yes, I would recommend that configuration also, because FreeBSD is
> > > > much more lightweight of the two, so you don't impose the overhead of
> > > > running Windows when all you need is FreeBSD.
> > >
> > > I'm not sure that's true, actually. FreeBSD by itself may be a lot more
> > > lightweight than Windows but once you add in Xorg and KDE I think it
> > > needs about the same, if not more, memory. People will argue that you
> > > don't have to run KDE or GNOME but as can be seen from the success of
> > > Ubuntu people like complete desktop environments.
> >
> > Well, there's your problem -- you're using Windows Lite (KDE).
> >
> > Anyway, it appears to be fairly reliably reported that KDE and
> > (especially now) GNOME still run lighter than the whole MS Windows GUI,
> > even if they're much heavier than other options.
> >
> > --
> > Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
>
>
> I'm using FBSD xith Xorg sans KDE or GNOME quite productively. And with
> everything running that I normally need, I use less than 1GB out of the
> 4GB available -- less than 300MB on boot. Windows 7 wants the a whole GB
> just to start up, or it's painfully slow. Actually, it's painfully slow
> anyway -- and furthermore it imposes that pain on guest OSes as well.
>
> What does KDE or GNOME buy you anyway? Besides overhead.
>
>
Preference I use Gnome on occasion but I stick w/ {open|black|etc}box
because I'm more a minimalist then anything and I abhor desktop icons ...
even in windows, I turn them off.
> --
> Sterling (Chip) Camden| sterl...@camdensoftware.com | 2048D/3A978E4F
> http://camdensoftware.com | http://chipstips.com|
> http://chipsquips.com
>
___
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"
Re: Tips for installing windows and freeBSD both.. anyone??
Quoth Chad Perrin on Saturday, 06 November 2010: > On Sat, Nov 06, 2010 at 08:02:39PM +, Bruce Cran wrote: > > On Sat, 6 Nov 2010 12:09:34 -0700 > > Chip Camden wrote: > > > > > Yes, I would recommend that configuration also, because FreeBSD is > > > much more lightweight of the two, so you don't impose the overhead of > > > running Windows when all you need is FreeBSD. > > > > I'm not sure that's true, actually. FreeBSD by itself may be a lot more > > lightweight than Windows but once you add in Xorg and KDE I think it > > needs about the same, if not more, memory. People will argue that you > > don't have to run KDE or GNOME but as can be seen from the success of > > Ubuntu people like complete desktop environments. > > Well, there's your problem -- you're using Windows Lite (KDE). > > Anyway, it appears to be fairly reliably reported that KDE and > (especially now) GNOME still run lighter than the whole MS Windows GUI, > even if they're much heavier than other options. > > -- > Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] I'm using FBSD xith Xorg sans KDE or GNOME quite productively. And with everything running that I normally need, I use less than 1GB out of the 4GB available -- less than 300MB on boot. Windows 7 wants the a whole GB just to start up, or it's painfully slow. Actually, it's painfully slow anyway -- and furthermore it imposes that pain on guest OSes as well. What does KDE or GNOME buy you anyway? Besides overhead. -- Sterling (Chip) Camden| sterl...@camdensoftware.com | 2048D/3A978E4F http://camdensoftware.com | http://chipstips.com| http://chipsquips.com pgpQ1riXd5Yvf.pgp Description: PGP signature
Re: Tips for installing windows and freeBSD both.. anyone??
On Sat, Nov 06, 2010 at 08:02:39PM +, Bruce Cran wrote: > On Sat, 6 Nov 2010 12:09:34 -0700 > Chip Camden wrote: > > > Yes, I would recommend that configuration also, because FreeBSD is > > much more lightweight of the two, so you don't impose the overhead of > > running Windows when all you need is FreeBSD. > > I'm not sure that's true, actually. FreeBSD by itself may be a lot more > lightweight than Windows but once you add in Xorg and KDE I think it > needs about the same, if not more, memory. People will argue that you > don't have to run KDE or GNOME but as can be seen from the success of > Ubuntu people like complete desktop environments. Well, there's your problem -- you're using Windows Lite (KDE). Anyway, it appears to be fairly reliably reported that KDE and (especially now) GNOME still run lighter than the whole MS Windows GUI, even if they're much heavier than other options. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] pgp6D3xoJmzGp.pgp Description: PGP signature
Re: Tips for installing windows and freeBSD both.. anyone??
On Sat, 6 Nov 2010 12:09:34 -0700 Chip Camden wrote: > Yes, I would recommend that configuration also, because FreeBSD is > much more lightweight of the two, so you don't impose the overhead of > running Windows when all you need is FreeBSD. I'm not sure that's true, actually. FreeBSD by itself may be a lot more lightweight than Windows but once you add in Xorg and KDE I think it needs about the same, if not more, memory. People will argue that you don't have to run KDE or GNOME but as can be seen from the success of Ubuntu people like complete desktop environments. -- Bruce Cran ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
Yes, I would recommend that configuration also, because FreeBSD is much more lightweight of the two, so you don't impose the overhead of running Windows when all you need is FreeBSD. Quoth Ross Cameron on Saturday, 06 November 2010: > Personally I would install FreeBSD as the primary operating system and > install Windows in a VirtualBox VM. > > That way you can get the best of both worlds and no need to reboot to access > a particular application. > > > > > > "Opportunity is most often missed by people because it is dressed in > overalls and looks like work." > Thomas Alva Edison > Inventor of 1093 patents, including: > The light bulb, phonogram and motion pictures. > > > > On Sat, Nov 6, 2010 at 11:01 AM, Tushar wrote: > > > I want to use windows and freeBSD, both of them at the same time... > > please help... > > ___ > > 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" > > > ___ > 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" -- Sterling (Chip) Camden| sterl...@camdensoftware.com | 2048D/3A978E4F http://camdensoftware.com | http://chipstips.com| http://chipsquips.com pgp4DjFCTcWzv.pgp Description: PGP signature
Re: Tips for installing windows and freeBSD both.. anyone??
Yes, I'm going to try virtualbox. Thankyou On Nov 6, 4:20 pm, Ross Cameron wrote: > Personally I would install FreeBSD as the primary operating system and > install Windows in a VirtualBox VM. > > That way you can get the best of both worlds and no need to reboot to access > a particular application. > > "Opportunity is most often missed by people because it is dressed in > overalls and looks like work." > Thomas Alva Edison > Inventor of 1093 patents, including: > The light bulb, phonogram and motion pictures. > > On Sat, Nov 6, 2010 at 11:01 AM, Tushar wrote: > > I want to use windows and freeBSD, both of them at the same time... > > please help... > > ___ > > freebsd-questi...@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-questions > > To unsubscribe, send any mail to " > > freebsd-questions-unsubscr...@freebsd.org" > > ___ > freebsd-questi...@freebsd.org mailing > listhttp://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
Yes, I'm going to try virtualbox. Thankyou On Nov 6, 4:33 pm, Polytropon wrote: > On Sat, 6 Nov 2010 02:01:22 -0700 (PDT), Tushar wrote: > > I want to use windows and freeBSD, both of them at the same time... > > please help... > > Consider using a virtualization solution to run both operating > systems in parallel. > > -- > Polytropon > Magdeburg, Germany > Happy FreeBSD user since 4.0 > Andra moi ennepe, Mousa, ... > ___ > freebsd-questi...@freebsd.org mailing > listhttp://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
Yes, I'm going to try virtualbox. Thankyou On Nov 6, 4:22 pm, Bruce Cran wrote: > On Sat, 6 Nov 2010 02:01:22 -0700 (PDT) > > Tushar wrote: > > I want to use windows and freeBSD, both of them at the same time... > > please help... > > You can run Windows from FreeBSD, or FreeBSD from within Windows. > Either way, use VirtualBox (http://www.virtualbox.org, > emulators/virtualbox-ose from ports) to run both at the same time. > > -- > Bruce Cran > ___ > freebsd-questi...@freebsd.org mailing > listhttp://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
Personally I would install FreeBSD as the primary operating system and install Windows in a VirtualBox VM. That way you can get the best of both worlds and no need to reboot to access a particular application. "Opportunity is most often missed by people because it is dressed in overalls and looks like work." Thomas Alva Edison Inventor of 1093 patents, including: The light bulb, phonogram and motion pictures. On Sat, Nov 6, 2010 at 11:01 AM, Tushar wrote: > I want to use windows and freeBSD, both of them at the same time... > please help... > ___ > 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" > ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
On Sat, 6 Nov 2010 02:01:22 -0700 (PDT), Tushar wrote: > I want to use windows and freeBSD, both of them at the same time... > please help... Consider using a virtualization solution to run both operating systems in parallel. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ 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"
Re: Tips for installing windows and freeBSD both.. anyone??
On Sat, 6 Nov 2010 02:01:22 -0700 (PDT) Tushar wrote: > I want to use windows and freeBSD, both of them at the same time... > please help... You can run Windows from FreeBSD, or FreeBSD from within Windows. Either way, use VirtualBox (http://www.virtualbox.org, emulators/virtualbox-ose from ports) to run both at the same time. -- Bruce Cran ___ 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"
