command line vs gui
in [General Linux]
|
Prev: micro solution backpack cd-writer hell
Next: "...error while loading shared libraries: libg2c.so.0"
From: Peter T. Breuer on 8 Dec 2005 13:01 In comp.os.linux.misc Lee Sau Dan <danlee(a)informatik.uni-freiburg.de> wrote: >>>>>> "Peter" == Peter T Breuer <ptb(a)oboe.it.uc3m.es> writes: > >>>> even through the "advanced" page. How do I ask for all pages > >>>> that meet the following?: > >>> > >>>> ("contains foo and contains bar") or ("contains qwerty") > >>> To do an OR, you have to do two searches, and concat the > >>> resluts. > >> Exactly. No way to do it with a single search. > Peter> So what? > So, that means you can't optimize the query to make the search more > efficient. You can optimize the query all you like subject to the condition that any ORs in the query will have to be handled by you, though, not the google DB engine. So what? > Peter> Using two google searches underneath is mere > Peter> implementation! Leave that sort of thing up to the > Peter> implementation. > Unoptimized, inefficient implementaion. Leave it up to the implementation. Google has plenty of horsepower. Do you have more? I think your task is just to do an cat and sort! The lower-level queries can go to google in parallel. > It can be done better, if > Google supports full Boolean queries. I can't be bothered to think about it. It's not my cycles I'd be wasting. Let google give me a cookie if they want to optimize over my simultaneous queries. Peter
From: Robert M. Riches Jr. on 8 Dec 2005 14:21 On 2005-12-08, blmblm(a)myrealbox.com <blmblm(a)myrealbox.com> wrote: > In article <dn7e3o$12na$1(a)news.uit.no>, > Tobias Brox <tobias(a)stud.cs.uit.no> wrote: >>[blmblm(a)myrealbox.com] >>> If you remember the menu structure, *and* either the GUI supports >>> keyboard shortcuts (which you also remember) or you're faster with >>> the mouse than with the keyboard. No? >> >>It's possible to make shortcuts, tab completion, history buffers w/ >>interactive search (ctrl-R) and scripts in command line mode. All >>tasks that I do relatively often is done very quick from the CLI. > > As do I. I'm pretty sure I wouldn't be such an advocate of a CLI > without these features. > >>I'm >>pretty sure it would be slower using _any_ gui. > > That's what I generally assume too, but I vaguely remember hearing > about a study Apple conducted many years ago that demonstrated that > people *think* a CLI is faster, but if you do actual measurements of > how long tasks take, it turns out the point and click is as fast or > faster. No, I don't (want to) believe it, but it could be true?? (Against my better judgement, I'm posting this to all newsgroups. I read only comp.os.linux.misc, so I won't see any flames in the human-factors group.) I'd be a bit skeptical of their supposed "study". The HCI folks are not immune to misconceptions and incorrect prejudices, either. A few years ago, I took a master's-level course titled something similar to "Introduction to Human Computer Interaction". The text spent a great deal of time preaching that the mouse was the only useful way to enter positional information, and no trackball could ever be built that would have any degree of speed or precision. Reality is I can get much better speed and precision with my Logitech Trackman Marble than I can with a mouse, and much better than the figures the textbook quoted for mouse input. On top of that, I don't have to deal with any of the very serious disadvantages of a mouse. Besides, it's going to be a little difficult to take a GUI sequence and put it in a crontab to run at 2:30am monday through friday without turning the GUI into a CLI. -- Robert Riches spamtrap42(a)verizon.net (Yes, that is one of my email addresses.)
From: Tobias Brox on 8 Dec 2005 14:55 [blmblm(a)myrealbox.com] > That's what I generally assume too, but I vaguely remember hearing > about a study Apple conducted many years ago that demonstrated that > people *think* a CLI is faster, but if you do actual measurements of > how long tasks take, it turns out the point and click is as fast or > faster. No, I don't (want to) believe it, but it could be true?? I wouldn't entirely trust Apple in this case; you could conclude anything dependent on how the study is conducted. I doubt they have used tab-completion, interactive history search and scripting. I also doubt they have studied cases where the user wants to do something that is not entirely covered by the GUI, causing the user to do repetive and tedious work. -- This signature has been virus scanned, and is probably safe to read Tobias Brox, 69?42'N, 18?57'E
From: Dances With Crows on 8 Dec 2005 15:00 ["Followup-To:" header set to comp.os.linux.misc.] On Thu, 08 Dec 2005 19:21:55 GMT, Robert M. Riches Jr. staggered into the Black Sun and said: > On 2005-12-08, blmblm(a)myrealbox.com <blmblm(a)myrealbox.com> wrote: >> about a study Apple conducted many years ago that demonstrated that >> people *think* a CLI is faster, but if you do actual measurements of >> how long tasks take, it turns out the point and click is as fast or >> faster. No, I don't (want to) believe it, but it could be true?? > A few years ago, I took a master's-level course titled something > similar to "Introduction to Human Computer Interaction". The text > spent a great deal of time preaching that the mouse was the only > useful way to enter positional information, and no trackball could > ever be built that would have any degree of speed or precision. Textbook authors can be dumb too. (Or maybe this is like what Stephen Jay Gould described in "The Case of the Creeping Fox Terrier Clone".) > Reality is I can get much better speed and precision with my Logitech > Trackman Marble than I can with a mouse, and much better than the > figures the textbook quoted for mouse input. Hm, did they look at Trackpoints? Or graphics tablets? They might not have; don't want to confuse the students with lots of data that may or may not support the point the author was trying to make. Or they did something like what Apple did at the beginning of MacOS: Put a bunch of random people in front of a machine with a mouse and a trackball, see which device they like better. Using experienced users instead of random people would definitely produce different experimental data. > Besides, it's going to be a little difficult to take a GUI sequence > and put it in a crontab to run at 2:30am monday through friday without > turning the GUI into a CLI. xmacrorec, then xmacroplay? OK, that won't work unless the widgets you're clicking on don't move around, but it's certainly possible to do if you really have to. Or you could hack something up using wmctrl, but that's probably too close to "turning the GUI into a CLI". -- Matt G|There is no Darkness in Eternity/But only Light too dim for us to see Brainbench MVP for Linux Admin / mail: TRAP + SPAN don't belong http://www.brainbench.com / "He is a rhythmic movement of the -----------------------------/ penguins, is Tux." --MegaHAL
From: Robert M. Riches Jr. on 8 Dec 2005 15:11
On 2005-12-08, Dances With Crows <danSPANceswitTRAPhcrows(a)gmail.com> wrote: > ["Followup-To:" header set to comp.os.linux.misc.] > On Thu, 08 Dec 2005 19:21:55 GMT, Robert M. Riches Jr. staggered into > the Black Sun and said: > >> Besides, it's going to be a little difficult to take a GUI sequence >> and put it in a crontab to run at 2:30am monday through friday without >> turning the GUI into a CLI. > > xmacrorec, then xmacroplay? OK, that won't work unless the widgets > you're clicking on don't move around, but it's certainly possible to do > if you really have to. Or you could hack something up using wmctrl, but > that's probably too close to "turning the GUI into a CLI". I have used xmacro to great advantage. However, that's not going to do much good if I'm not logged in and running X at the prescribed time of day. -- Robert Riches spamtrap42(a)verizon.net (Yes, that is one of my email addresses.) |