command line vs gui
in [General Linux]
|
Prev: micro solution backpack cd-writer hell
Next: "...error while loading shared libraries: libg2c.so.0"
From: Tobias Brox on 7 Dec 2005 14:44 [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. I'm pretty sure it would be slower using _any_ gui. -- This signature has been virus scanned, and is probably safe to read Tobias Brox, 69?42'N, 18?57'E
From: blmblm on 8 Dec 2005 05:25 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?? -- | B. L. Massingill | ObDisclaimer: I don't speak for my employers; they return the favor.
From: David on 8 Dec 2005 06:24 On Thu, 8 Dec 2005 10:25:28 UTC, 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?? The CLI is generally as fast for me and a preferred option. I use the GUI since that is also available. However, during the day I generally perform certain tasks that could be repeated in the CLI that generally cannot in the GUI. I prefer to automate any tasks that I do often. I develop applications, so an end to end build sequence would be useful, but isn't supported by the combination of CLI and GUI build tools that have been dictated. Thus there is much repetetive work playing with the *UI for a single mental command. I credit part of this disconnect to the GUI application builders that ignore the CLI possibility or the aspect of external use (even by another GUI application). It is also quite hard sometimes to discover the equivalent commands for a CLI given a set of GUI actions or vice versa. I've never had the CLI of any system become unresponsive as the GUI seems to. I admit that problem only seems to happen on Microsoft OSes. It is frustrating when the UI isn't paying attention and liomits me to just one set of long tasks at a time. Yesterday a simple demonstration/test task (a few mouse clicks) for a customer became agonizingly long (5 steps took 8 minutes instead of 5 seconds). The CPU/HD was going nuts and no apparent culprit. Eventually we found a new Microsoft OS Update being downloaded. Why would such an activity have priority over any of the UI components when a human or scheduled task returned to use the box? David
From: blmblm on 8 Dec 2005 07:35 In article <4396ec3a$30$fuzhry+tra$mr2ice(a)news.patriot.net>, Shmuel (Seymour J.) Metz <spamtrap(a)library.lspace.org.invalid> wrote: [ snip ] >Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel> > >Unsolicited bulk E-mail subject to legal action. I reserve the >right to publicly post or ridicule any abusive E-mail. Reply to >domain Patriot dot net user shmuel+news to contact me. Do not >reply to spamtrap(a)library.lspace.org Can you think of a reason why mail sent using the above instructions would bounce, with the following error messages (actual e-mail address edited)? <<< 550 5.7.1 <your_address_as_described>... Access denied 550 5.1.1 <your_address_as_described>... User unknown -- | B. L. Massingill | ObDisclaimer: I don't speak for my employers; they return the favor.
From: Chris F.A. Johnson on 8 Dec 2005 11:38
On 2005-12-08, blmblm(a)myrealbox.com wrote: > > 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?? The difference is that you will get faster by orders of magnitude as you learn to use the CLI, especially if you put frequently used combinations into scripts. The speed of using point'n'click will increase only marginally as you become accustomed to it. -- Chris F.A. Johnson, author | <http://cfaj.freeshell.org> Shell Scripting Recipes: | My code in this post, if any, A Problem-Solution Approach | is released under the 2005, Apress | GNU General Public Licence |