Command line VS GUI, redux
mlw
This isn't necessarily CLI s GUI so much as a restatement about the
usefullness of a CLI. Yes, we pretty much all use a GUI. We pretty much all
depend on GUI programs. Just because GUIs are largely "the" way to
accomplish most basic tasks, there exists task, IMHO, that are more suited
for GUI.
I've had conversations with users, and they want a CLI. They don't know it,
but I've heard things like "how can I just tell it what I want to do?" "Why
can't I just tell it to pop out the CD?" "Why can't I say 'record at
5:00'?"
The issue is the complexity of tasks. With a GUI, you need to complete a
complex series of dialog box tasks, possibly save the results, and then
press enter.
A CLI rewards a little knowledge, with some basic learning a CLI can make
complex tasks easier, and make repeated tasks, especially the complex ones,
much easier.
The question is: How to we incorporate a linguistic interface in a way that
the user will be inclined to use it?
George Ellison
Hmmm, you know, I've only been using Linux for a few months myself, and
I started out with Xandros, which is probably one of the most GUI-ified
distros out there. I was all pointy-clicky for all of two days until I
bothered to try out the terminal. (I used a Unix shell account at a
local ISP a few years back, so I had minimal knowledge of how to get
around. Any old MS-DOS hand could probably find his way around bash
fairly easily). Since then, I've been hooked. I love KDE and xfce,
and can even tolerate GNOME for short periods of time, but I tend to
do more and more from the console, simply because it's faster and more
efficient. Burning ISO images to try out a new LiveCD can be a mess with
K3B, whereas it's a single command job with cdrecord. I'm not the best
when it comes to things like piping or I/O redirection, but the command
line seems to offer more bang for the buck than most GUI's. No wonder MS
is trying to strengthen the CLI for Vista.
damon
> On 2005-11-18, mlw <m...@nospamnoway.zz> wrote:
>>
>>I've had conversations with users, and they want a CLI. They don't know it,
>>but I've heard things like "how can I just tell it what I want to do?" "Why
>>can't I just tell it to pop out the CD?" "Why can't I say 'record at
>>5:00'?"
>>
>>The issue is the complexity of tasks. With a GUI, you need to complete a
>>complex series of dialog box tasks, possibly save the results, and then
>>press enter.
>>
>>A CLI rewards a little knowledge, with some basic learning a CLI can make
>>complex tasks easier, and make repeated tasks, especially the complex ones,
>>much easier.
>>
>>The question is: How to we incorporate a linguistic interface in a way that
>>the user will be inclined to use it?
>>
>>
>>
>
I'm not the best
> when it comes to things like piping or I/O redirection, but the command
> line seems to offer more bang for the buck than most GUI's.
And don't forget all the fine programs that are available on the command
line. I use good ol' ftp and ssh all the time. And trolling through
menus to find a program seems goofy when you can just type the name and
whack enter. mv, cp, ls, man, pwd, rm, wc, rsync, lpr... I use them all
the time and hate it when I have to learn how to use a friend's GUI.
The learning curve is steep, but the cli is designed to be
expert-friendly, after all.
-- damon
tab
cli is awesome, if you are an expert.
i don't have to know commands.
I know where all the gui's are. :)
I just hope they are user friendly.
DFS
Months ago Ghost mentioned a GUI interface that incrementally builds a
command. I took a look and found one that already does this. Can't find
the link just now, but you make point-click choices and it builds a command
string you can edit and execute.
In general I really really dislike the CLI, and I think most people do.
It's boring to look at, and tedious to use. It just feels slow and
unproductive and antiquated - whether it is or not. And it's worse on
Windows than on Linux.
But I noticed the more you use it the more comfortable you get with it,
pretty quickly too. If you can touch-type at a decent rate and know your
commands, you can be fairly efficient with it.
The *nix CLI is a powerful interface. Difficult but powerful. It's ultra
nice being able to pipe command outputs to files, or do that 'locate' thing,
or search for all packages with 'gnumeric' in the name, or schedule jobs
with a few commands, etc.
The CLI is hard to like and hard to learn, but not hard to appreciate.
Linønut
> And don't forget all the fine programs that are available on the command
> line. I use good ol' ftp and ssh all the time. And trolling through
> menus to find a program seems goofy when you can just type the name and
> whack enter. mv, cp, ls, man, pwd, rm, wc, rsync, lpr... I use them all
> the time and hate it when I have to learn how to use a friend's GUI.
>
> The learning curve is steep, but the cli is designed to be
> expert-friendly, after all.
ooffice mydocument &
--
Treat yourself to the devices, applications, and services running on the
GNU/Linux® operating system!
Tim Smith
wrote:
> Months ago Ghost mentioned a GUI interface that incrementally builds a
> command. I took a look and found one that already does this. Can't find
> the link just now, but you make point-click choices and it builds a command
> string you can edit and execute.
Way back in the late '80s Apple had something like that, in the MPW
(Macintosh Programmer's Workbench) environment. They also had it in
A/UX for most Unix commands.
Suppose you wanted to do a "find" command, but wanted help with the
arguments. You'd do "find..." (The "..." is actually one character,
which you got by typing option-semicolon), and it would give you a
dialog for that command. It would have checkboxes and radio buttons for
options, file selection areas for specifying files, and so on. This was
in the era before tabbed dialogs were invented, but it had the
equivalent (for complex commands like find) in buttons that would take
you to other dialogs, so that the could organize options by functional
groups.
When you finished, it put the constructed command back into the terminal
window for you.
--
--Tim Smith
TheLetterK
burn app, just right click on the disk image and click 'burn to disk'.
> I'm not the best
> when it comes to things like piping or I/O redirection, but the command
> line seems to offer more bang for the buck than most GUI's. No wonder MS
> is trying to strengthen the CLI for Vista.
Ironically, Microsoft's attempts to strengthen their command line will
probably backfire. Most of thier problem here is that they have a
simplistic CLI with complex methods--they're replacing it with a highly
complex CLI with even more complex methods.
--
"There is nothing I understand." - Shit
r.e.b...@usa.net
shell had the ability to create aliases which made it possible to make
simple aliases that could be used in place of the short commands.
the original K&R commands were very short because the terminal access
was through a 300 baud tty serial interface connected to a teletype. A
typo in the middle of a command was a real problem. You might have to
retype the whole command.
The irony is that as people got familiar with the commands, they really
LIKED the very short command names. But bash, ksh, and csh all support
aliases. Some popular ones include:
alias move mv
alias copy cp
alias list ls
alias more less
alias directory ls -l
and so on.
Many people would have 50 to 60 aliases which included simple "one
liner" scripts.
Of course, the other thing you can do is write scripts using the cli
shell of your choice. In addition, many applications can be scripted.
Most experienced users create a ~/bin directory (a bin directory in
their home directory) and then ad this directory to their main profile
path.
If you really want to be strange, you can create interesting names that
describe what a program does. For example backup_my_email
Linguistically, English is a terrible language to parse. For example,
a computer parser/translator translated english to russian and russian
back to english. When this computer was fed the phrase "the spirit is
willing but the flesh is weak" it was translated to "the wine is strong
but the meat is rotten".
There have been several attempts to create "plain english" programming
language such as pilot and cobol. Often these aren't much better. The
one good thing about a programming language like cobol is that the
actual program can be included in the legislative act, which eliminates
most of the ambiguity, and yet it still looks like a standard english
phrase.
Other attempts were even wierder. The FORTH program would let you put
the "nouns" on the stack, then have the "verbs" operate on the stack.
In fact, forth let you use any word you want, and assign any meaning
(program) to that word. The forth programs or words were then stored
in the "dictionary".
Linux environments also come with commands like "whatis", so you can
ask
whatis grep, and you'll get a basic description of grep. For a bit
more information, you can use the manual. K&R shorthand for this is
"man", but you can use an alias to make "manual grep" work too.
In addition, you can use <command> --help on almost every single
command line command, which can be used to quickly get a list of which
flags are available. Many times the whatis notation provides
descriptive arguments to very short 1-letter flags.
Then we have some really strange commands that can be aliased.
alias global_regular_expression_print
alias searchfile grep
alias search_replace sed
alias stream_edit sed
alias column_file_search_report awk
The other advantage of scripting of course is that you have far more
control over how things can be combined. Take a simple command like
"find".
There are many different expressions available for this command, but
trying to use a GUI would tend to limit you.
Once upon a time, there was even a gui based shell. It had drag and
drop modules which could be connected (just like pipelines) and when a
module was dropped, flags could be selected and set in another dialogue
area. The problem with this program, they couldn't keep up with how
quickly the anthology is growing.
There is also swig, which can be used to generate a wrapper file from a
synopsis or man page.
There are also info files. The advantage to this documentation is that
they make generous use of hyperlinks, which means that you can follow
the see-also sections along with details by following the links.
There are also gui interfaces to the manuals including xman.
There are also the Linux howto manuals which are usually available in
both HTML and "plain text". We also have docbook format, which can be
used to generate both HTML documents and printable "TeX" documents
which can be converted to postscript. If you don't have a postscript
printer, CUPS can convert postscript into HP's PCL along with several
other popular printer formats.
Many of the popular Linux GUI interfaces are actually script
generator/executors.
Linux advocates normally don't want to overwhelm new users with all of
the capabilities of Linux scripting and CLI commands. Ironically, this
is a bit like having an 8 cylinder 32 valve supercharged engine, that
you only drive in a state where the maximum speed limit is 55 mph. You
really don't get to experience all of that power until you want to get
into that tight slot before the convoy of Semi tractor/Trailers gets in
front of you.
Under the covers, Windows is mostly dependent on COM objects which are
packaged into DLLs, and must be compiled into programs. Furthermore,
each application using these large DLLs must load the entire DLL into
each application.
Under the covers, Linux is mostly command line shell commands which
have been compiled from objects stored in libraries. Most of these
commands or programs are very small, and only require very small
library modules to be loaded. This is why you often go to the task
manager processes tab in Windows XP and see 5-6 20-30 kbyte program
images running. IEXPLORE.EXE (40 meg), ntaskldr.exe (34 meg),
svchost.exe (20 meg), explorer.exe (18 meg), soffice.bin (15 meg), and
so on. This is IN ADDITION to the kernel itself (170 meg).
Larry Qualig
I don't think this needs to be an either/or proposition.
The advantage of GUI tools is that they tend to be easier/friendlier
for a newbie to use. Especially if it's a tool one uses infrequently.
CLI tools offer more flexibility (piping, redirection, etc) but take a
bit longer to learn.
Ideally an OS would contain both. The CLI tools would be available to
users who are comfortable with them or want to script tasks. The GUI
would be there for the times when it's more convenient to use it over
the CLI equivalent.
Lee Sau Dan
mlw> The issue is the complexity of tasks. With a GUI, you need to
mlw> complete a complex series of dialog box tasks, possibly save
mlw> the results, and then press enter.
mlw> A CLI rewards a little knowledge, with some basic learning a
mlw> CLI can make complex tasks easier, and make repeated tasks,
mlw> especially the complex ones, much easier.
Good point. CLI: things become easier as your experience with it
grows. GUI: things remain difficult despite the growth of your
experience with it.
Which is thus more frustrating for heavy users?
mlw> The question is: How to we incorporate a linguistic interface
mlw> in a way that the user will be inclined to use it?
At least, CLI resembles language. :) GUI resembles using gestures to
communicate.
(No offense to people who use sign languages. Sign languages are full
languages of their own, with complexities no lower than spoken
languages. I'm just saying that GUI is just a very primitive way of
communication.)
--
Lee Sau Dan 李守敦 ~{@nJX6X~}
E-mail: dan...@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
Lee Sau Dan
George> (I used a Unix shell account at a local ISP a few years
George> back, so I had minimal knowledge of how to get around. Any
George> old MS-DOS hand could probably find his way around bash
George> fairly easily).
An old MS-DOS hand would be extremely amazed by the completion (which
works not only for file/directory names, but also shell variable
names!) and editable history list (navigatible with UP and DOWN
arrows) of bash, let alone the power of unix shells: pipes, job
control, etc. And they'll be surprised that the "*' wildcard really
works as it should be.
George> Since then, I've been hooked. I love KDE and xfce, and can
George> even tolerate GNOME for short periods of time, but I tend
George> to do more and more from the console, simply because it's
George> faster and more efficient.
That's why I always use "emacs&" to start Emacs, "xterm&" to start
xterm, and "firefox&" to start firefox. I have these things
configured in my FVWM menus, but seldom use such menus. Typing the
command is just so much quicker. And I don't have to look at the
screen to carefully aim at those tiny menu entries. Aiming with the
mouse is so tiring and slow.
George> Burning ISO images to try out a new LiveCD can be a mess
George> with K3B, whereas it's a single command job with cdrecord.
George> I'm not the best when it comes to things like piping or
George> I/O redirection, but the command line seems to offer more
George> bang for the buck than most GUI's. No wonder MS is trying
George> to strengthen the CLI for Vista.
DOS's COMMAND.COM and NT's CMD.EXE are simply ridiculous in comparison
with even Bourne shell.
Lee Sau Dan
damon> And don't forget all the fine programs that are available
damon> on the command line. I use good ol' ftp and ssh all the
damon> time. And trolling through menus to find a program seems
damon> goofy when you can just type the name and whack enter. mv,
damon> cp, ls, man, pwd, rm, wc, rsync, lpr... I use them all the
damon> time and hate it when I have to learn how to use a friend's
damon> GUI.
A GUI can't let you set variables and refer to them later, like (bash):
$ X=/a/very/lengthy/path/to/some/directory
$ Y=/another/very/lengthy/path/to/some/file
$ echo so something ...
$ mv $Y $X
And the "~1", "~2" as well as "pushd" and "popd" in bash are so handy
that I have to hate the ksh, which I'm forced to use when working on
some proprietary unixes not administered by me. (If I were the sys
admin, I'd have compiled and installed bash and emacs at the first
instance!)
Does any GUI provide something even remotely comparable?
damon> The learning curve is steep, but the cli is designed to be
damon> expert-friendly, after all.
So, it's user-friendly, when user == expert.
Lee Sau Dan
tab> damn, another honest guy in COLA. cli is awesome, if you are
tab> an expert.
tab> i don't have to know commands. I know where all the gui's
tab> are. :) I just hope they are user friendly.
What if your UI designers decided that in the next major release,
they'd re-organize the icons and menus, and replace your familiar
icons with "prettier and cutier" ones?
With a CLI, the commands seldom change name. (A name change can be
smoothed by using a symlink or alias from the old name to the new
one.) And it doesn't matter where the commands are located: the shell
does the searching (along PATH) for you. That means: knowledge of the
unix CLI remains useful for decades, like knowledge of a language.
Lee Sau Dan
r> Other attempts were even wierder. The FORTH program would let
r> you put the "nouns" on the stack, then have the "verbs" operate
r> on the stack.
This is not wierd at all if your mother tongue puts verbs at the end
of a sentence, such as Japanese.
I guess a Japanese would find English's word order wierd. :)
r> In fact, forth let you use any word you want, and assign any
r> meaning (program) to that word. The forth programs or words
r> were then stored in the "dictionary".
And the Postscript language descends from FORTH.
r> In addition, you can use <command> --help on almost every
r> single command line command, which can be used to quickly get a
r> list of which flags are available.
And many DOS programs during the last incarnations of MS-DOS had the
"/?" switch, too!
r> The other advantage of scripting of course is that you have far
r> more control over how things can be combined. Take a simple
r> command like "find".
And shell scripts can be easily scheduled to run unattended using cron
or at. GUI? Huh?
r> Once upon a time, there was even a gui based shell. It had
r> drag and drop modules which could be connected (just like
r> pipelines) and when a module was dropped, flags could be
r> selected and set in another dialogue area. The problem with
r> this program, they couldn't keep up with how quickly the
r> anthology is growing.
This program could have a feature that reads in and parses a command
line typed in by the user, and then constructure those dialogues
automatically and the let the user examine the result visually,
possibly testing and fine-tuning it. Of course, it'd be nice to
translate the final result back into a shell command and let the user
see how it now looks like.
r> Linux advocates normally don't want to overwhelm new users with
r> all of the capabilities of Linux scripting and CLI commands.
r> Ironically, this is a bit like having an 8 cylinder 32 valve
r> supercharged engine, that you only drive in a state where the
r> maximum speed limit is 55 mph. You really don't get to
r> experience all of that power until you want to get into that
r> tight slot before the convoy of Semi tractor/Trailers gets in
r> front of you.
I tend to agree. When people ask me "why do you need to type
commands", I tell them "I don't need to, but I choose to, because
that's more powerful than stupidly pointing and clicking with a
mouse". Those who are interested in Linux for its strengths should be
shown what Linux is good for, not just those GUIs that feels different
from Windows.
r> Under the covers, Windows is mostly dependent on COM objects
r> which are packaged into DLLs, and must be compiled into
r> programs. Furthermore, each application using these large DLLs
r> must load the entire DLL into each application.
I can't believe that such an inefficient implementation is adopted!!!
mlw
>
> mlw wrote:
>> This isn't necessarily CLI s GUI so much as a restatement about the
>> usefullness of a CLI. Yes, we pretty much all use a GUI. We pretty much
>> all depend on GUI programs. Just because GUIs are largely "the" way to
>> accomplish most basic tasks, there exists task, IMHO, that are more
>> suited for GUI.
>>
>> I've had conversations with users, and they want a CLI. They don't know
>> it, but I've heard things like "how can I just tell it what I want to
>> do?" "Why can't I just tell it to pop out the CD?" "Why can't I say
>> 'record at 5:00'?"
>>
>> The issue is the complexity of tasks. With a GUI, you need to complete a
>> complex series of dialog box tasks, possibly save the results, and then
>> press enter.
>>
>> A CLI rewards a little knowledge, with some basic learning a CLI can make
>> complex tasks easier, and make repeated tasks, especially the complex
>> ones, much easier.
>>
>> The question is: How to we incorporate a linguistic interface in a way
>> that the user will be inclined to use it?
>
>
>
> I don't think this needs to be an either/or proposition.
It wasn't posed as an "either/or" proposition.
>
> The advantage of GUI tools is that they tend to be easier/friendlier
> for a newbie to use. Especially if it's a tool one uses infrequently.
> CLI tools offer more flexibility (piping, redirection, etc) but take a
> bit longer to learn.
>
> Ideally an OS would contain both. The CLI tools would be available to
> users who are comfortable with them or want to script tasks. The GUI
> would be there for the times when it's more convenient to use it over
> the CLI equivalent.
Well, ideally, the CLI, actually a linguistic interface to which a CLI would
be a predecessor, incorporated into the UI, maybe it is speech.
Larry Qualig
Lee Sau Dan wrote:
> >>>>> "damon" == damon <damon...@alumni.DONTSPAM.umass.edu> writes:
>
> damon> And don't forget all the fine programs that are available
> damon> on the command line. I use good ol' ftp and ssh all the
> damon> time. And trolling through menus to find a program seems
> damon> goofy when you can just type the name and whack enter. mv,
> damon> cp, ls, man, pwd, rm, wc, rsync, lpr... I use them all the
> damon> time and hate it when I have to learn how to use a friend's
> damon> GUI.
>
> A GUI can't let you set variables and refer to them later, like (bash):
>
> $ X=/a/very/lengthy/path/to/some/directory
> $ Y=/another/very/lengthy/path/to/some/file
> $ echo so something ...
> $ mv $Y $X
>
> And the "~1", "~2" as well as "pushd" and "popd" in bash are so handy
> that I have to hate the ksh, which I'm forced to use when working on
> some proprietary unixes not administered by me. (If I were the sys
> admin, I'd have compiled and installed bash and emacs at the first
> instance!)
>
> Does any GUI provide something even remotely comparable?
>
>
> damon> The learning curve is steep, but the cli is designed to be
> damon> expert-friendly, after all.
> So, it's user-friendly, when user == expert.
This is the primary issue. The CLI is a powerful interface for computer
'experts' but something needs to exist for the other 95% of computer
users. Not everyone studies computers or has the desire to learn
commands like ' export PATH="$(print -r $PATH | sed
's|$ENV_VAR|ENV_VAR|g')" '. Computers need to appeal to a broad number
of users including people like nurses, builders, realtors, etc. These
people *need* GUI tools.
Kleuskes & Moos
Lee Sau Dan schreef:
> >>>>> "r" == r e ballard <r.e.b...@usa.net> writes:
>
> r> Other attempts were even wierder. The FORTH program would let
> r> you put the "nouns" on the stack, then have the "verbs" operate
> r> on the stack.
>
> This is not wierd at all if your mother tongue puts verbs at the end
> of a sentence, such as Japanese.
>
> I guess a Japanese would find English's word order wierd. :)
>
>
> r> In fact, forth let you use any word you want, and assign any
> r> meaning (program) to that word. The forth programs or words
> r> were then stored in the "dictionary".
>
> And the Postscript language descends from FORTH.
(Courier) findfont 12 scalefont setfont
(\(sorry, couldn't resist\))(The Good Old Days)(Postscript...)(Ah,)
50 10 moveto show
80 10 moveto show
100 10 moveto show
120 10 moveto show
showpage
> r> In addition, you can use <command> --help on almost every
> r> single command line command, which can be used to quickly get a
> r> list of which flags are available.
>
> And many DOS programs during the last incarnations of MS-DOS had the
> "/?" switch, too!
Many *nix tools offer -h or --help or else man and apropos...
> r> The other advantage of scripting of course is that you have far
> r> more control over how things can be combined. Take a simple
> r> command like "find".
>
> And shell scripts can be easily scheduled to run unattended using cron
> or at. GUI? Huh?
> r> Once upon a time, there was even a gui based shell. It had
> r> drag and drop modules which could be connected (just like
> r> pipelines) and when a module was dropped, flags could be
> r> selected and set in another dialogue area. The problem with
> r> this program, they couldn't keep up with how quickly the
> r> anthology is growing.
>
> This program could have a feature that reads in and parses a command
> line typed in by the user, and then constructure those dialogues
> automatically and the let the user examine the result visually,
> possibly testing and fine-tuning it. Of course, it'd be nice to
> translate the final result back into a shell command and let the user
> see how it now looks like.
Such a tool should not be all *that* difficult to write... Pipes aren't
really the problem, for, while, switch etc, would be more difficult. It
needs a well thought our visual layout, though. You could offer
integrated man-page and info support...
Hey... That could be a swell little tool.
> r> Linux advocates normally don't want to overwhelm new users with
> r> all of the capabilities of Linux scripting and CLI commands.
> r> Ironically, this is a bit like having an 8 cylinder 32 valve
> r> supercharged engine, that you only drive in a state where the
> r> maximum speed limit is 55 mph. You really don't get to
> r> experience all of that power until you want to get into that
> r> tight slot before the convoy of Semi tractor/Trailers gets in
> r> front of you.
>
> I tend to agree. When people ask me "why do you need to type
> commands", I tell them "I don't need to, but I choose to, because
> that's more powerful than stupidly pointing and clicking with a
> mouse".
If you're telling them, leave out the 'stupidly'. I think that would
not go down so well with the average GUI-addict you are trying to
convince.
> Those who are interested in Linux for its strengths should be
> shown what Linux is good for, not just those GUIs that feels different
> from Windows.
Give'm some time. They'll discover it by themselves. In '03 I had a big
argument on GUI vs CLI and we did a little competition. Removing .o
files from a build directory. :-) After he was convinced. He had to
point, click *and* type all I had to do was 'rm *.o<enter>'. He wanted
a replay: building an entire source tree, but he did not know about
'make' (yet). Went on to become a true bash fanatic after that and
within a month he was telling _me_ about the more arcane features and
constructs.
> r> Under the covers, Windows is mostly dependent on COM objects
> r> which are packaged into DLLs, and must be compiled into
> r> programs. Furthermore, each application using these large DLLs
> r> must load the entire DLL into each application.
>
> I can't believe that such an inefficient implementation is adopted!!!
Sad, but true, AFAIK.
Edwards
> and tedious to use.
Nonsense, clicking and dragging a bunch of file icons, or typing
a command to do something to a bunch of filenames -- it's the same
amount of tedium.
> It just feels slow and
> unproductive and antiquated - whether it is or not. And it's worse on
> Windows than on Linux.
>
> But I noticed the more you use it the more comfortable you get with it,
> pretty quickly too. If you can touch-type at a decent rate and know your
> commands, you can be fairly efficient with it.
Tab completion, etc. All I can do is hunt & peck but with all the
bells and whistles of modern shells, it doesn't hold me back.
> The *nix CLI is a powerful interface. Difficult but powerful.
It's not difficult, because it's discoverable; if you need to figure
out how to do something in a CLI, the answers/explanation are right
there in the CLI (man, apropos, info, html help files, etc).
What's difficult is sitting down at an unfamiliar GUI and struggling
to remember or work out by trial and error its idiosyncracies for
accomplishing basic tasks. Every time my next door neighbor asks for
help with her Mac, I grit my teeth, knowing that very soon I'll be
struggling to do something that ought to be simple, but unable to
recall whether it's done by clicking while holding down the cloverleaf
key, or the shift key, or the control key, or the option key, or some
combination of the above. I end up doing things the slow way,
_knowing_ there's an easier way but that it won't be worth the effort
of finding it. Selecting a bunch of files to be moved to a different
folder, say; finally I figure out how to get it to select more than
one file at a time, but can't for the life of me recall the _second_
magic key sequence to let me drag all of those files at once -- every
time I click it selects the one file I've clicked on and desects all
the others. "Searing damnation, I just want to mv R*.doc
../some_other_dir/, you pestilent piece of garbage!" But she's eighty
or so and I can't very well refuse to at least try to help. :)
> It's ultra
> nice being able to pipe command outputs to files, or do that 'locate' thing,
> or search for all packages with 'gnumeric' in the name, or schedule jobs
> with a few commands, etc.
>
> The CLI is hard to like
I don't buy that. It _might_ be true that some folks like CLI better,
some exclusive GUI, and that few switch once they've picked. (I'm not
convinced of that but it's at least possible.) But all of us who
regularly use (and do indeed like) the CLI started from scratch at one
point. If it were hard to like noone at _all_ would use it.
> and hard to learn,
All the anecdotal evidence I've seen suggests otherwise; it takes
about as much effort to "master" a CLI as a typical GUI. Related to
my rant above, my impression is that a CLI rewards incremental
learning. You don't _have_ to master all of /usr/bin:/usr/local/bin
at once, you start by learning a few commands and gradually increase
your vocabulary.
With a GUI, on the other hand, there's a fairly large repertoire of
"gestures" one must learn right away in order to be able to use it at
_all_. Increasing that repertoire as time goes on requires
essentially rote memorization of new gestures that aren't necessarily
related to the previous ones in any syntactic or "deducible" way.
(Knowing that right clicking on a file in an explorer window gives you
access to its properties doesn't necessarily tell you anything about
what will happen if you right click on, say, the root desktop or the
toolbar.)
Compare the (in theory subtle and complex) concept of, say, pipes in a
CLI. Maybe a coworker showed you how to pipe the output of ls to grep
or something (e.g. so you can pick which images to send to an image
editing program). Then a few days later you accidentally or maybe
even on purpose connect a couple of different text i/o programs with a
pipe, or discover that there can be more than two programs in your
"chain" of pipes, and kablammo, you've opened a whole new world for
yourself. I firmly believe that's because the CLI is _generalizable_
in a way that a GUI can't be (because the former is loosely modeled on
the way language works, with _syntactic_ as well as semantic
relationships, while the latter is more like a collection of entities
which may carry semantic information but have simple and generally
unsystematic relationships).
> but not hard to appreciate.
Well, neither is a GUI; despite the above, I don't actually sit at a
VGA console all day, I use enlightnement and am very happy with it.
But the actual _things_ I am doing are generally happening in Eterms
and xemacs windows, plus programs like pdf and ps viewers (text-based,
but not really separable from their GUI, so what are they?). Someone
once quipped "Time is what keeps everything from happening at once," I
guess for me a window manager is what keeps all my terminals from
falling on top of each other. Obviously GUIs aren't going anywhere
anytime soon, and everyone needs to decide on their own how best to
get their own work done; but anyone who dismisses CLIs out of hand,
thinking they're "old" or "difficult" or whatnot, is missing something
important IMO.
--
Darrin
Linønut
> At least, CLI resembles language. :) GUI resembles using gestures to
> communicate.
>
> (No offense to people who use sign languages. Sign languages are full
> languages of their own, with complexities no lower than spoken
> languages. I'm just saying that GUI is just a very primitive way of
> communication.)
GUI resembles normal-hearing people using gestures to communicate (while
the deaf people laugh their asses off!)
Larry Qualig
<disclaimer>
I've been using a CLI starting with a VT-100 terminal on a DEC PDP/11.
(Anyone remember "pip")
</disclaimer>
Soooo many people forget that the overwhelming majority of computer
users are neophytes. Expecting average users to become proficient with
a CLI simply isn't going to happen.
Take something like "file permissions" for example. To a computer
junkie using 'chmod' to set the permission mask on a file is
manageable.
But how about the 90+% of users who aren't junkies? Just try to teach a
hair dresser or widget salesman how the permission mask is a set of
"bits" (base-2/binary) and how each "bit position" represents a
permission flag.
Compare this to a GUI dialog that let's the user visually set
permissions without the need to understand bit-masks and the binary
number system.
mlw
"Peripheral interchange program" what of it? I used it on a PDP8, PHP11,
VAX, and CP/M
> </disclaimer>
>
>
> Soooo many people forget that the overwhelming majority of computer
> users are neophytes. Expecting average users to become proficient with
> a CLI simply isn't going to happen.
I think this is incorrect. People want to talk to their computer, tell it
what to do. I think hand gestures are far more limited than linguistics
skills.
>
> Take something like "file permissions" for example. To a computer
> junkie using 'chmod' to set the permission mask on a file is
> manageable.
>
> But how about the 90+% of users who aren't junkies? Just try to teach a
> hair dresser or widget salesman how the permission mask is a set of
> "bits" (base-2/binary) and how each "bit position" represents a
> permission flag.
How about "make filename readonly" or "delete filename" or "let susi read my
filename"
>
> Compare this to a GUI dialog that let's the user visually set
> permissions without the need to understand bit-masks and the binary
> number system.
Yes, awefull.
Larry Qualig
If this is true (which my initial inclination is to suspect that it is)
it would be a new type of user interface. It would no longer be the
"CLI" or "GUI" of today. The new interface would be something like
"NLI" (Natural Language Interface).
> >
> > Take something like "file permissions" for example. To a computer
> > junkie using 'chmod' to set the permission mask on a file is
> > manageable.
> >
> > But how about the 90+% of users who aren't junkies? Just try to teach a
> > hair dresser or widget salesman how the permission mask is a set of
> > "bits" (base-2/binary) and how each "bit position" represents a
> > permission flag.
>
> How about "make filename readonly" or "delete filename" or "let susi read my
> filename"
With a "NLI" (Natural Language Interface) this would be fine. But we
are no longer talking about the "CLI" as is in use today.
mlw
Yup there was a system that was based on the 8086 and ran a form of UNIX
back about 20 years ago.
>
>
>> >
>> > Take something like "file permissions" for example. To a computer
>> > junkie using 'chmod' to set the permission mask on a file is
>> > manageable.
>> >
>> > But how about the 90+% of users who aren't junkies? Just try to teach a
>> > hair dresser or widget salesman how the permission mask is a set of
>> > "bits" (base-2/binary) and how each "bit position" represents a
>> > permission flag.
>>
>> How about "make filename readonly" or "delete filename" or "let susi read
>> my filename"
>
> With a "NLI" (Natural Language Interface) this would be fine. But we
> are no longer talking about the "CLI" as is in use today.
Maybe you, but I think they are similar in nature.
DFS
Instead of being 100% boring, eterm is 99.9% boring.
>> and tedious to use.
>
> Nonsense, clicking and dragging a bunch of file icons, or typing
> a command to do something to a bunch of filenames -- it's the same
> amount of tedium.
Nonsense. Click n' drag is fun. It provides the visual feedback that makes
the user feel involved. Plus it's easier to visually scan the files you
want to copy/move and select them than it is to type the commands.
>> It just feels slow and
>> unproductive and antiquated - whether it is or not. And it's worse
>> on Windows than on Linux.
>>
>> But I noticed the more you use it the more comfortable you get with
>> it, pretty quickly too. If you can touch-type at a decent rate and
>> know your commands, you can be fairly efficient with it.
>
> Tab completion, etc. All I can do is hunt & peck but with all the
> bells and whistles of modern shells, it doesn't hold me back.
>
>> The *nix CLI is a powerful interface. Difficult but powerful.
>
> It's not difficult, because it's discoverable; if you need to figure
> out how to do something in a CLI, the answers/explanation are right
> there in the CLI (man, apropos, info, html help files, etc).
It is difficult, and it's discoverable with great effort.
How do you know to type man or apropos? ah, you click the Help icon on the
pretty GUI.
And once you open a man page you get a screen full of gobbledygook, and
arcane commands that take forever to learn and master, ie something like 52
switches just for ls?!
> What's difficult is sitting down at an unfamiliar GUI and struggling
> to remember or work out by trial and error its idiosyncracies for
> accomplishing basic tasks. Every time my next door neighbor asks for
> help with her Mac, I grit my teeth, knowing that very soon I'll be
> struggling to do something that ought to be simple, but unable to
> recall whether it's done by clicking while holding down the cloverleaf
> key, or the shift key, or the control key, or the option key, or some
> combination of the above. I end up doing things the slow way,
> _knowing_ there's an easier way but that it won't be worth the effort
> of finding it. Selecting a bunch of files to be moved to a different
> folder, say; finally I figure out how to get it to select more than
> one file at a time, but can't for the life of me recall the _second_
> magic key sequence to let me drag all of those files at once -- every
> time I click it selects the one file I've clicked on and desects all
> the others. "Searing damnation, I just want to mv R*.doc
> ../some_other_dir/, you pestilent piece of garbage!"
Interesting. I've never heard someone complain so much about having to use
a mouse to move files. You're an old guy, aren't you? Raised on Unix?
> But she's eighty
> or so and I can't very well refuse to at least try to help. :)
Hey, why don't you set her up a Linux box? I'm sure she'll love the CLI.
>> It's ultra
>> nice being able to pipe command outputs to files, or do that
>> 'locate' thing, or search for all packages with 'gnumeric' in the
>> name, or schedule jobs with a few commands, etc.
>>
>> The CLI is hard to like
>
> I don't buy that.
Well, so far everything I say is met with you claiming exactly the opposite.
You must be a *nix dinosaur.
> It _might_ be true that some folks like CLI better,
> some exclusive GUI, and that few switch once they've picked. (I'm not
> convinced of that but it's at least possible.) But all of us who
> regularly use (and do indeed like) the CLI started from scratch at one
> point. If it were hard to like noone at _all_ would use it.
When I write 'the CLI is hard to like' I'm stating my opinion. And it's
shared by most everyone outside the odd world of Unix and Linux.
>> and hard to learn,
>
> All the anecdotal evidence I've seen suggests otherwise; it takes
> about as much effort to "master" a CLI as a typical GUI.
You're out of your mind. All the evidence points the opposite way. Nearly
anyone can look at a computer GUI and mouse and get started doing something.
Left click and the item is highlighted/selected. Right-click and you get a
set of properties or options to operate on the item. A click or two more
and you've discovered a lot about the object and things you can do with it.
With a CLI prompt staring at you you're just plain lost. It's kind of
depressing, actually.
> Related to
> my rant above, my impression is that a CLI rewards incremental
> learning. You don't _have_ to master all of /usr/bin:/usr/local/bin
> at once, you start by learning a few commands and gradually increase
> your vocabulary.
That's probably the best way to approach it. Rather than feel you have to
learn 50 CLI commands to be productive, focus on a few.
> With a GUI, on the other hand, there's a fairly large repertoire of
> "gestures" one must learn right away in order to be able to use it at
> _all_.
You're just wrong. Left-click and right-click is all you need to get
started.
> Increasing that repertoire as time goes on requires
> essentially rote memorization of new gestures that aren't necessarily
> related to the previous ones in any syntactic or "deducible" way.
> (Knowing that right clicking on a file in an explorer window gives you
> access to its properties doesn't necessarily tell you anything about
> what will happen if you right click on, say, the root desktop or the
> toolbar.)
>
> Compare the (in theory subtle and complex) concept of, say, pipes in a
> CLI. Maybe a coworker showed you how to pipe the output of ls to grep
> or something (e.g. so you can pick which images to send to an image
> editing program). Then a few days later you accidentally or maybe
> even on purpose connect a couple of different text i/o programs with a
> pipe, or discover that there can be more than two programs in your
> "chain" of pipes, and kablammo, you've opened a whole new world for
> yourself. I firmly believe that's because the CLI is _generalizable_
> in a way that a GUI can't be (because the former is loosely modeled on
> the way language works, with _syntactic_ as well as semantic
> relationships, while the latter is more like a collection of entities
> which may carry semantic information but have simple and generally
> unsystematic relationships).
On the other hand, the GUI conveys relationships between entities and
provides access to them and their properties that's more difficult to
achieve with a command line.
>> but not hard to appreciate.
>
> Well, neither is a GUI; despite the above, I don't actually sit at a
> VGA console all day, I use enlightnement and am very happy with it.
You should try KDE. It's much better than Enlightenment, from what I've
seen.
> But the actual _things_ I am doing are generally happening in Eterms
> and xemacs windows, plus programs like pdf and ps viewers (text-based,
> but not really separable from their GUI, so what are they?). Someone
> once quipped "Time is what keeps everything from happening at once," I
> guess for me a window manager is what keeps all my terminals from
> falling on top of each other. Obviously GUIs aren't going anywhere
> anytime soon, and everyone needs to decide on their own how best to
> get their own work done; but anyone who dismisses CLIs out of hand,
> thinking they're "old" or "difficult" or whatnot, is missing something
> important IMO.
Probably so.
But most of the world has moved away from command lines. For good reason.
tha...@tux.glaci.remove-this.com
> back to english. When this computer was fed the phrase "the spirit is
> willing but the flesh is weak" it was translated to "the wine is strong
> but the meat is rotten".
This sort off on a tangent, but I wonder if there have been any efforts
to teach computers sign language (i.e. using a camera and some sort
of pattern recognition software). This would be a bit different than
the usual natural language parsing, because sign language is a concept
based language, not a phoneme based.
My girlfriend is currently teaching me sign language... otherwise this
thought might not have occurred to me.
Thad
GreyCloud
>>
>>Nonsense, clicking and dragging a bunch of file icons, or typing
>>a command to do something to a bunch of filenames -- it's the same
>>amount of tedium.
>
>
> Nonsense. Click n' drag is fun. It provides the visual feedback that makes
> the user feel involved. Plus it's easier to visually scan the files you
> want to copy/move and select them than it is to type the commands.
>
Click n' drag has never been more fun that click'n drag M$ office trial
on a mac to the dust bin. The best software removal tool I've ever used.
--
Where are we going?
And why am I in this handbasket?
DFS
> Click n' drag has never been more fun that click'n drag M$ office
> trial on a mac to the dust bin. The best software removal tool I've
> ever used.
That was a mistake. Now you're stuck with inferior office software.
Lee Sau Dan
>> At least, CLI resembles language. :) GUI resembles using
>> gestures to communicate.
>>
>> (No offense to people who use sign languages. Sign languages
>> are full languages of their own, with complexities no lower
>> than spoken languages. I'm just saying that GUI is just a very
>> primitive way of communication.)
Linųnut> GUI resembles normal-hearing people using gestures to
Linųnut> communicate (while the deaf people laugh their asses
Linųnut> off!)
Right! :)
--
Lee Sau Dan
Lee Sau Dan
>> So, it's user-friendly, when user == expert.
Larry> This is the primary issue. The CLI is a powerful interface
Larry> for computer 'experts' but something needs to exist for the
Larry> other 95% of computer users. Not everyone studies computers
Larry> or has the desire to learn commands like ' export
Larry> PATH="$(print -r $PATH | sed 's|$ENV_VAR|ENV_VAR|g')"
Larry> '. Computers need to appeal to a broad number of users
Larry> including people like nurses, builders, realtors,
Larry> etc. These people *need* GUI tools.
Right. So, don't say "CLI is obsolete". Don't expect experts to use
the same tools that the general end-users use. Many people seem to be
unable to understand this.
Many general PC users, however, are surprised when they see some
experts use tools that they're unfamiliar with. They seem to expect
the users to be using the same GUI tools they're used to. e.g. when
they approach me for help on problems on Windows, I tell them I don't
know because I don't use Windows. And then they look puzzled. They
expect every computer-savvy person to use Windows like they do, or
knows Windows as well as they do. I can't understand why they would
think so. That's like expecting construction workers who build a
skyscrapers to be familiar with plastic Lego blocks. Do they really
supposed that the skyscrapers are build with Lego blocks? So absurd!
Lee Sau Dan
Kleuskes> (Courier) findfont 12 scalefont setfont (\(sorry,
Kleuskes> couldn't resist\))(The Good Old Kleuskes> Days)
Kleuskes> (Postscript...)(Ah,) 50 10 moveto show 80 10 moveto
Kleuskes> show 100 10 moveto show 120 10 moveto show showpage
I didn't know "(Courier) findfont" would work. The examples always
use "/Courier findfont", and I have been assuming that "findfont"
expects a name rather than a string as the operand.
r> In addition, you can use <command> --help on almost every
r> single command line command, which can be used to quickly get a
r> list of which flags are available.
>> And many DOS programs during the last incarnations of MS-DOS
>> had the "/?" switch, too!
Kleuskes> Many *nix tools offer -h or --help or else man and
Kleuskes> apropos...
Well... I don't think so. Only the GNU toolchain and the modern tools
offer -h and --help. Older unix tools are pretty unfriendly. Try
some vendor unix and you'll encounter their 'ls', 'find', 'cp', 'tar',
etc. which are so much dumber than the GNU ones. They usually lack
the "-h" and won't support long options. Many even lack the
intelligence of many GNU implementations. (e.g. GNU 'cp' would refuse
to do anything but print a warning if you give it more than 2
arguments and the last one doesn't name an existing directory.)
Kleuskes> Such a tool should not be all *that* difficult to
Kleuskes> write... Pipes aren't really the problem, for, while,
Kleuskes> switch etc, would be more difficult. It needs a well
Kleuskes> thought our visual layout, though. You could offer
Kleuskes> integrated man-page and info support...
And the best interface, IMO, for me to freely and easily and flexibly
combine while, switch, if-the-else, etc., is: a text editor. No GUI
can compare. A text editor that can automatically indent the code is
very helpful.
Lee Sau Dan
nobody> Windows also has this thing called "Scheduled Tasks" in
nobody> the Control Panel, which is like a crippled version of
nobody> cron.
You've said it yourself. It's a crippled clone. So crippled to be
given serious consideration and for serious use.
nobody> It can run programs daily, weekly, monthly, one time
nobody> only, upon startup, and upon login. It can't run a program
nobody> hourly, bi-weekly, or at any other interval that doesn't
nobody> fit into the Scheduled Task Wizard.
So, it's really "useful", isn't it?
nobody> You probably have to be logged in when the task is
nobody> scheduled to run.
That's even more ridiculous!
nobody> The big problem is that Windows has very few applications
nobody> that can be useful without direct user intervention at
nobody> runtime (unless you want to learn how to write VBS
nobody> scripts).
A big big design flaw.
nobody> Therefore, Scheduled Tasks serve as merely another way
nobody> for viruses to ensure that they continue running.
So, the virus programs are more user-friendly. At least, they will
work very hard behind the scene without the user having to babysit
them and feed them.
Lee Sau Dan
Edwards> Nonsense, clicking and dragging a bunch of file icons, or
Edwards> typing a command to do something to a bunch of filenames
Edwards> -- it's the same amount of tedium.
Try clicking a bunch of file icons for the files named "foo*.o" and
then dragging them to the rubbish bin. I simply type "rm -f foo*.o
<ENTER>", which takes less than 5 seconds. Can you do the clicking
and dragging as quickly as I type the command, in a directory with
100s of files?
Edwards> What's difficult is sitting down at an unfamiliar GUI and
Edwards> struggling to remember or work out by trial and error its
Edwards> idiosyncracies for accomplishing basic tasks. Every time
Edwards> my next door neighbor asks for help with her Mac, I grit
Edwards> my teeth, knowing that very soon I'll be struggling to do
Edwards> something that ought to be simple, but unable to recall
Edwards> whether it's done by clicking while holding down the
Edwards> cloverleaf key, or the shift key, or the control key, or
Edwards> the option key, or some combination of the above.
It seems that we human beings are better at memorizing new words than
memorizing new paths. And we like to attach names to objects and
concepts. The GUI is simply counter-intuitive in this respect.
In general, it is more useful to know an address than to know how to
get to a place. With an address, at least, you can ask a passer-by
and get some information on how to get there. If you only know how to
go to a place and you don't know the address, you're hopeless when the
path you're familiar are blocked for some reasons.
Edwards> I end up doing things the slow way, _knowing_ there's an
Edwards> easier way but that it won't be worth the effort of
Edwards> finding it.
Similar experience when someone is showing me off their shiny GUI on
their *Linux* boxes, and then asked me for help on some simple
operations. I have to tell them: "I don't know how to do that from
this pretty and shiny GUI. Would you please find out how to open a
command terminal, so that I can type the command to do that?"
>> The CLI is hard to like
...
>> and hard to learn,
Edwards> All the anecdotal evidence I've seen suggests otherwise;
Edwards> it takes about as much effort to "master" a CLI as a
Edwards> typical GUI.
People with only MS-DOS experience tend to generalize from their bad
impression of the MS-DOS CLI. So, they'd tend to conclude that the
CLI is stupid and obsolete. Reasons? The MS-DOS COMMAND.COM (and
NT's CMD.EXE isn't that better) is a broken clone of the unix shells.
Many commands have inconsistent syntax, making it so hard to learn and
*generalize*. The wildcards do not work as expected (what does "DEL
*FOO.TXT" do?) and isn't supported on all commands (because in MS-DOS,
the wildcards are not expanded by the shell, but by the programs
invoked). Many commands cannot act on more than 1 file at a time.
(Try "DEL FOO.TXT BAR.TXT" in MS-DOS, vs. unix "rm foo.txt bar.txt
more.txt moremore.txt"). Some commands prompts you to before doing
anything. Some don't. And some does it sometimes but not always (try
"DEL A.TXT" vs. "DEL *.*").
Unix shell commands are relatively more consistent. And the GNU tools
have done a very good job in introducing long options to the unix
world, influencing unix programs (esp. free ones) developed after the
early 90s.
Edwards> Related to my rant above, my impression is that a CLI
Edwards> rewards incremental learning. You don't _have_ to master
Edwards> all of /usr/bin:/usr/local/bin at once, you start by
Edwards> learning a few commands and gradually increase your
Edwards> vocabulary.
Yeah. Many people have the absurd idea that you need to know ALL
commands in order to use the CLI. That's as absurd as saying that you
must know ALL English words in order to speak English. (Which native
speaker dare to say they know ALL English words? Even if we limit the
list to a well known dictionary such as Oxford or Webster?)
Edwards> With a GUI, on the other hand, there's a fairly large
Edwards> repertoire of "gestures" one must learn right away in
Edwards> order to be able to use it at _all_.
And like gestures in sign languages (analogous to sounds of words in a
spoken language), they are often quite arbitrary and unintuitive.
e.g. why do people find having a rubbish bin ON the desktop
_intuitive_? I've never seen that in practice in the physical world.
If you want to get rid of something off a desktop, why drag them onto
a rubbish bin ON the desktop? Why not just sweep them all off the
desk? Why not give me a vacuum cleaner to suck away the unwanted
stuffs? And how is using "Ctrl-click" to select multiple items
intuitive? Why not give me a tray to collect the group of items that
I want to process at once? ... ... ...
Edwards> Increasing that repertoire as time goes on requires
Edwards> essentially rote memorization of new gestures that aren't
Edwards> necessarily related to the previous ones in any syntactic
Edwards> or "deducible" way. (Knowing that right clicking on a
Edwards> file in an explorer window gives you access to its
Edwards> properties doesn't necessarily tell you anything about
Edwards> what will happen if you right click on, say, the root
Edwards> desktop or the toolbar.)
As I said before, the GUI vocabularies "double-click", "right-click"
and the like have no fixed meanings. What they mean varies
dramatically from context to context. Imagine that you have a learn a
new language with just a few words, which changes meanings from
context to context. That's easy? That's intuitive?
Edwards> I firmly believe that's because the CLI is
Edwards> _generalizable_ in a way that a GUI can't be (because the
Edwards> former is loosely modeled on the way language works, with
Edwards> _syntactic_ as well as semantic relationships, while the
Edwards> latter is more like a collection of entities which may
Edwards> carry semantic information but have simple and generally
Edwards> unsystematic relationships).
The GUI could be analyzed in a linguistic manner like what I do. The
lexicon: "click", "double-click", "shift-click", "right-click", etc;
phonetics/physics: press left mouse button <==> "click"; press left
mouse button and release and press a second time shortly after that
<==> "double-click"; etc.; semantics: HIGHLY AMBIGUOUS, because the
meanings of these words can vary so widely from context to context.
In terms of language design, this is a very bad one. A language in
which the words vary widely in meaning from context to context.
Another problem is that the lexicon is practically NOT EXTENSIBLE.
With the CLI, you can invent new commands of any name you like (by
writing programs or shell scripts and naming them as you like). The
GUI, by comparison, has a very limited stock of vocabularies. It is
theoretically extensible: you could invent "Q-click", "W-click",
"E-click", "R-click" or even "QWERTY-click" in the style of
"Shift-click"; or you could invent "left-right click as a kind of
double-click where the first click is done with the left mouse button
and the second with the right". But none of these seem practical.
Personal, I already find Shift-Click and Control-Click absurd. And
double-click is stupid -- I think Apple invented it to overcome the
lack of expressiveness of their one-button mice.
>> but not hard to appreciate.
Edwards> Well, neither is a GUI; despite the above, I don't
Edwards> actually sit at a VGA console all day, I use
Edwards> enlightnement and am very happy with it. But the actual
Edwards> _things_ I am doing are generally happening in Eterms and
Edwards> xemacs windows, plus programs like pdf and ps viewers
Edwards> (text-based, but not really separable from their GUI, so
Edwards> what are they?).
Me too! Most of the windows I open under FVWM (with multiple virtual
desktops) are (GNU) Emacs and xterm's. I also use Firefox for
web-browsing, and "xosview" to monitor the machine's health. What
else would I REALLY need?
Edwards> Someone once quipped "Time is what keeps everything from
Edwards> happening at once," I guess for me a window manager is
Edwards> what keeps all my terminals from falling on top of each
Edwards> other.
A good WM is essential. Maybe, that's another reason I hate Windows.
Edwards> Obviously GUIs aren't going anywhere anytime soon, and
Edwards> everyone needs to decide on their own how best to get
Edwards> their own work done; but anyone who dismisses CLIs out of
Edwards> hand, thinking they're "old" or "difficult" or whatnot,
Edwards> is missing something important IMO.
That's like saying "speaking is old and obsolete", after having
exposure to SMS, instant messaging, e-mail, fax, etc. Can the latter
really replace the former? I don't think so.
Even TV has in no way swept out radio, and radio in now way swept out
newspapers. Those why think GUI is modern and CLI is obsolete are
simply short-sighted, and don't understand what they're talking about.
Lee Sau Dan
Larry> <disclaimer> I've been using a CLI starting with a VT-100
Larry> terminal on a DEC PDP/11. (Anyone remember "pip")
Larry> </disclaimer>
Larry> Soooo many people forget that the overwhelming majority of
Larry> computer users are neophytes. Expecting average users to
Larry> become proficient with a CLI simply isn't going to happen.
Neither do I expect a 1-year old to speak English fluently. But does
that mean English is not useful? Does that mean English is not worth
learning?
Larry> Take something like "file permissions" for example. To a
Larry> computer junkie using 'chmod' to set the permission mask on
Larry> a file is manageable.
Did you learn how to use symbolic permission specifiers, as in
chmod u=rwx,g=u-w,o= myfile.txt
?
Can your beloved GUI do the "g=u-w" part conveniently?
Larry> But how about the 90+% of users who aren't junkies?
So, newbies should drive the experts and "teach" them how to do
something?
Larry> Just try to teach a hair dresser or widget salesman how the
Larry> permission mask is a set of "bits" (base-2/binary) and how
Larry> each "bit position" represents a permission flag.
Next time, when you visit your hair dresser, bring your own pair of
scissors (a normal pair, meant for cutting paper) and ask your hair
dresser to drop his tools and use only your pair of scissors. Tell
him: "Your tools are too complicated and too professional for me to
understand. Please adopt mine!"
Larry> Compare this to a GUI dialog that let's the user visually
Larry> set permissions without the need to understand bit-masks
Larry> and the binary number system.
"chmod" does support symbolic permission specification, like what I
quoted above. You simply missed it. That's not the chmod's fault.
Further, whoever what to fiddle with the permissions without getting
it wrong have to STUDY what those permission settings mean. And after
learning what those mean, explain me how it is so difficult to map
those concepts to the symbolic specifiers "u", "g", "o", "r", "w",
"x", "+", "-", "=", (and even "s" for the intermediate level users).
Lee Sau Dan
>> Take something like "file permissions" for example. To a
>> computer junkie using 'chmod' to set the permission mask on a
>> file is manageable.
>>
>> But how about the 90+% of users who aren't junkies? Just try to
>> teach a hair dresser or widget salesman how the permission mask
>> is a set of "bits" (base-2/binary) and how each "bit position"
>> represents a permission flag.
mlw> How about "make filename readonly"
alias make_readonly='chmod a-w'
mlw> or "delete filename" or
alias delete=rm
>> Compare this to a GUI dialog that let's the user visually set
>> permissions without the need to understand bit-masks and the
>> binary number system.
mlw> Yes, awefull.
You don't need to understand binary nor octal numbers just to set the
permissions. Learn to use "g", "u", "o", "r", "w", "x", "+", "-", "="
with 'chmod', and you're done.
Lee Sau Dan
>>> and tedious to use.
>> Nonsense, clicking and dragging a bunch of file icons, or
>> typing a command to do something to a bunch of filenames --
>> it's the same amount of tedium.
DFS> Nonsense. Click n' drag is fun. It provides the visual
DFS> feedback that makes the user feel involved. Plus it's easier
DFS> to visually scan the files you want to copy/move and select
DFS> them than it is to type the commands.
It does not only provides user interaction, but also REQUIRES it.
That's undesirable for unattend, automated operations. Not even
suitable for scripting.
>>> The *nix CLI is a powerful interface. Difficult but powerful.
>> It's not difficult, because it's discoverable; if you need to
>> figure out how to do something in a CLI, the
>> answers/explanation are right there in the CLI (man, apropos,
>> info, html help files, etc).
DFS> It is difficult, and it's discoverable with great effort.
As great as it is for GUIs.
DFS> How do you know to type man or apropos?
By the time you've learnt how to use a mouse.
DFS> ah, you click the Help icon on the pretty GUI.
How do you learn to click? And how do you learn to double-click?
DFS> And once you open a man page you get a screen full of
DFS> gobbledygook,
Once you open a GUI desktop, you get a screen full of colourful but
confusing eye-candies.
DFS> and arcane commands that take forever to learn and master, ie
DFS> something like 52 switches just for ls?!
I've been using ls for 13 years. Never bothered to learn ALL
switches. And never have the need to. One doesn't need to know all
the 52 switches just to use 'ls' productively. Most people start to
use 'ls' without knowing any single switch, and become heavy users of
'ls' after learning only 5 or 6 switches.
It's a flawed argument that one has to learn ALL 52 switches for 'ls'
in order to use 'ls' effectively. Much like claim that one has to
learn *all* 100000 English words in order to use English for
meaningful, practical communication.
DFS> Interesting. I've never heard someone complain so much about
DFS> having to use a mouse to move files.
Then, you've just met two!
DFS> You're an old guy, aren't you? Raised on Unix?
Raised on Apple ][+ DOS, then MS-DOS, then Windows 3.1, then Solaris,
then decided to say goodbye to Windows/DOS and switch completely to
Linux.
My first unix days were under Solaris (still called "SunOS" back
then), and it was not all text/CLI: everyone in the lab typed "startx"
immediately after logging in, if he has not put this command in
~/.login already. Exposed to many cutty GUI apps on the Solaris
workstations. But still found it most productive to type commands in
xterm's, and write code and edit files in Emacs.
DFS> You're out of your mind. All the evidence points the
DFS> opposite way. Nearly anyone can look at a computer GUI and
DFS> mouse and get started doing something. Left click and the
DFS> item is highlighted/selected. Right-click and you get a set
DFS> of properties or options to operate on the item. A click or
DFS> two more and you've discovered a lot about the object and
DFS> things you can do with it.
This model is too simple for many tasks. Not task is "select" and
then "modify properties". While some tasks can be so modelled, it's
inefficient.
Tell me how to do a
find ~ -type f -mmin -30 -iname 'foo*bar.txt" | \
xargs fgrep -l -v Hello |\
xargs md5sum
with a GUI.
DFS> With a CLI prompt staring at you you're just plain lost.
With a GUI, you also get lost: what do the screenful of confusing
icons mean? Where in the forest of menus is the function/program that
you want hidden?
DFS> It's kind of depressing, actually.
Yes, getting lost in the tons of cascading dialog boxes and forests of
menu trees is really depressing.
>> Related to my rant above, my impression is that a CLI rewards
>> incremental learning. You don't _have_ to master all of
>> /usr/bin:/usr/local/bin at once, you start by learning a few
>> commands and gradually increase your vocabulary.
DFS> That's probably the best way to approach it. Rather than
DFS> feel you have to learn 50 CLI commands to be productive,
DFS> focus on a few.
50 would be too many. I normally use fewer than 30. What do I need
besides ls, cat, make, cd, ping, echo, less, chmod, find, man, awk,
perl, sed, sort, paste, cut, join, uniq, vi, emacs, cron, at, ssh,
xterm?
>> With a GUI, on the other hand, there's a fairly large
>> repertoire of "gestures" one must learn right away in order to
>> be able to use it at _all_.
DFS> You're just wrong. Left-click and right-click is all you
DFS> need to get started.
Don't you need to learn what these gestures mean in EVERY different
context? Does left-clicking in application A always do the same thing
as left-clicking in application B?
OTOH, "ls" always means the same thing in a CLI.
DFS> On the other hand, the GUI conveys relationships between
DFS> entities and provides access to them and their properties
DFS> that's more difficult to achieve with a command line.
Tell me how to model the operations specified by the commmand:
find ~ -type f -mmin -30 -iname 'foo*bar.txt" | \
xargs fgrep -l -v Hello |\
xargs md5sum
in terms of entities and relationships. Then, describe how a GUI is
supposed to convey that model.
DFS> But most of the world has moved away from command lines. For
DFS> good reason.
Laziness is an^H excuse^H^H^H^H^H^Hreason. Lack of time is another
excuse^H^H^H^H^H^Hreason.
Has the world moved completely away from radio, in favour of TV? Has
the world moved completely away from sending physical letter, in
favour of fax and e-mail? Why?
Will you be having a PHYSICAL family reunion this Christmas, or you'll
just do it VIRTUAL using webcams?
Lee Sau Dan
nobody> If you try to be smarter than Windows by dragging all of
nobody> these files onto WinZip, you'll soon discover, as I did,
nobody> that this only results in one WinZip window for each and
nobody> every ZIP file.
Wow! How long does it take for you to close these 100 WinZip windows?
Is there anything even close to the Linux command
killall winzip
???
Haha... another example where a CLI wins GUI!!!
The 'select' (by Ctrl-clicking the objects) then 'operate' (by
clicking a tool-bar button) is only good for a small number of objects
at a time.
For real tasks involving large volumes of objects, the CLI usually
wins. GUIs *REQUIRING* human response/action for every small
operation on every object is simply a tedious interface to use.
nobody> I tried to compare the difference between typing "edit
nobody> *.txt" and selecting a bunch of text files and using "Open
nobody> With". However, it turns out that "edit *.txt" causes the
nobody> dreaded Blue Screen of Death on Windows, INSTANTLY.
It's SO robust! ;)
Lee Sau Dan
thad01> This sort off on a tangent, but I wonder if there have
thad01> been any efforts to teach computers sign language
thad01> (i.e. using a camera and some sort of pattern recognition
thad01> software). This would be a bit different than the usual
thad01> natural language parsing, because sign language is a
thad01> concept based language, not a phoneme based.
How is that different, besides the physical medium?
Would you explain to us what you mean by a "concept-based language"?
Sign languages are like spoken languages. They have their lexicons.
They have their own grammar. And these are no less (and no more)
complex than spoken languages. Just that they lack phonology
(i.e. mapping between sounds and lexical items), substituting it with
a mapping between gestures and lexical items).
So, basically, sign languages are like spoken languages. Just that
they replace phonemes with gesturemes. The higher abstraction levels
(lexicon, syntax, semantics) are similar.
Of course there are differences due to the different media being
employed. e.g. Our auditory system has a low bandwidth and can
receive signals only serially. Vision has a much higher bandwidth and
can easily receive and process multiple signals at once. So, spoken
languages has little parallelism. Sign langauges allows making a few
signs at the same time. But these differences are in the physical
layer, not the abstract layers.
thad01> My girlfriend is currently teaching me sign
thad01> language... otherwise this thought might not have occurred
thad01> to me.
So, have you not realized that sign languages also have lexicon,
syntax and semantics like spoken languages? Mentally, learning a sign
language is not that different than learning a foreign language. Just
that you use different sets of muscles and different receptive organs.
Tom Shelton
> On 18 Nov 2005 23:47:35 +0800, Lee Sau Dan
> <dan...@informatik.uni-freiburg.de> spewed forth this unto the Network:
>>>>>>> "r" == r e ballard <r.e.b...@usa.net> writes:
>>
>> r> Other attempts were even wierder. The FORTH program would let
>> r> you put the "nouns" on the stack, then have the "verbs" operate
>> r> on the stack.
>>
>> This is not wierd at all if your mother tongue puts verbs at the end
>> of a sentence, such as Japanese.
>>
>> I guess a Japanese would find English's word order wierd. :)
>>
>>
>> r> In fact, forth let you use any word you want, and assign any
>> r> meaning (program) to that word. The forth programs or words
>> r> were then stored in the "dictionary".
>>
>> And the Postscript language descends from FORTH.
>>
>>
>> r> In addition, you can use <command> --help on almost every
>> r> single command line command, which can be used to quickly get a
>> r> list of which flags are available.
>>
>> And many DOS programs during the last incarnations of MS-DOS had the
>> "/?" switch, too!
>>
>>
>> r> The other advantage of scripting of course is that you have far
>> r> more control over how things can be combined. Take a simple
>> r> command like "find".
>>
>> And shell scripts can be easily scheduled to run unattended using cron
>> or at. GUI? Huh?
>
> Windows has an "at". program.
>
> Windows also has this thing called "Scheduled Tasks" in the Control Panel,
> which is like a crippled version of cron. It can run programs
> daily, weekly, monthly, one time only, upon startup, and upon
> login. It can't run a program hourly, bi-weekly, or at any other
> interval that doesn't fit into the Scheduled Task Wizard.
>
You need to explore the advanced properties a little more - all that is
possible. You don't use it much do you? Also, there is a command line
interface to the task scheduler in windows xp and up - so you don't need to
even go through the gui to schedule tasks...
> You probably have to be logged in when the task is scheduled to run.
No. In fact, the default behavior is to run even if your not logged in -
that's why it gets the account information under which it should run. You
have to check the box in advanced properties to run only if your logged in.
--
Tom Shelton
Larry Qualig
Lee Sau Dan wrote:
> >>>>> "nobody" == nobody <nob...@nowhere.nonet> writes:
>
> nobody> Windows also has this thing called "Scheduled Tasks" in
> nobody> the Control Panel, which is like a crippled version of
> nobody> cron.
>
> You've said it yourself. It's a crippled clone. So crippled to be
> given serious consideration and for serious use.
This is absolutely ridiculous. The two of you spread a bunch of
mis-information and lies ( = FUD) about something you obviously nothing
about and come to a bunch of misguided conclusions.
A crippled clone? How exactly is it crippled?
>
>
> nobody> It can run programs daily, weekly, monthly, one time
> nobody> only, upon startup, and upon login. It can't run a program
> nobody> hourly, bi-weekly, or at any other interval that doesn't
> nobody> fit into the Scheduled Task Wizard.
>
> So, it's really "useful", isn't it?
Completely wrong. The point of the "wizard" is to allow average
computer users to be able to schedule a task. At the end of the wizard
you can elect to show "Advanced Settings" and schedule the task to run
up to once per minute. So yes... a task can run hourly, every 22
minutes, or every Tuesday, Friday and Sunday if you want.
I can also set the priority of the app that runs as well as limit the
length of time the app will run for. ie... run this scheduled task
every 30 minutes on Tuesday, Thursday and Friday between 1:00 and 4:00
PM and if the task doesn't finish in 3 minutes, terminate the task.
What additional flexibility does cron give me that the above doesn't
cover?
> nobody> You probably have to be logged in when the task is
> nobody> scheduled to run.
>
> That's even more ridiculous!
What's ridiculous is that the two of you actually believe that you have
to be logged in for the task to run. This isn't even close to being
correct.
> nobody> The big problem is that Windows has very few applications
> nobody> that can be useful without direct user intervention at
> nobody> runtime (unless you want to learn how to write VBS
> nobody> scripts).
>
> A big big design flaw.
What Linux apps exist that don't exist on Windows that can be easily
scheduled without writing scripts?
> nobody> Therefore, Scheduled Tasks serve as merely another way
> nobody> for viruses to ensure that they continue running.
>
> So, the virus programs are more user-friendly. At least, they will
> work very hard behind the scene without the user having to babysit
> them and feed them.
Perhaps the two of you should try sticking to subjects you know
something about.
Larry Qualig
Lee Sau Dan wrote:
> >>>>> "Larry" == Larry Qualig <lqu...@uku.co.uk> writes:
>
> >> So, it's user-friendly, when user == expert.
>
>
> Larry> This is the primary issue. The CLI is a powerful interface
> Larry> for computer 'experts' but something needs to exist for the
> Larry> other 95% of computer users. Not everyone studies computers
> Larry> or has the desire to learn commands like ' export
> Larry> PATH="$(print -r $PATH | sed 's|$ENV_VAR|ENV_VAR|g')"
> Larry> '. Computers need to appeal to a broad number of users
> Larry> including people like nurses, builders, realtors,
> Larry> etc. These people *need* GUI tools.
> Right. So, don't say "CLI is obsolete".
I never wrote/said "CLI is obsolete" and I challenge you to show me
where I did. This is something that you simply made up.
> Don't expect experts to use the same tools that the general
> end-users use. Many people seem to be unable to understand this.
Perhaps this is why I wrote in my first post in this thread:
- "Ideally an OS would contain both. The CLI tools would be available
to users who are comfortable with them or want to script tasks. The
GUI would be there for the times when it's more convenient to use it
over the CLI equivalent. "
> Many general PC users, however, are surprised when they see some
> experts use tools that they're unfamiliar with. They seem to expect
> the users to be using the same GUI tools they're used to. e.g. when
> they approach me for help on problems on Windows, I tell them I don't
> know because I don't use Windows. And then they look puzzled. They
> expect every computer-savvy person to use Windows like they do, or
> knows Windows as well as they do. I can't understand why they would
> think so. That's like expecting construction workers who build a
> skyscrapers to be familiar with plastic Lego blocks. Do they really
> supposed that the skyscrapers are build with Lego blocks? So absurd!
See previously reply. I have nothing against CLI tools. But I am not
the "average" computer user. What is absurd is to expect "average"
computer users are going to open up a console and type obscure commands
with command line switches. Most computer users need GUI tools - most
computer users are not experts and shouldn't be required to learn
"expert" tools in order to use their computer.
GreyCloud
I don't need their stuff. Plus it was way too expensive. Apple Works 6
is quite adequate for what little I do with office work.
Jim Richardson
Hash: SHA1
On 19 Nov 2005 23:15:20 +0800,
Sign language varies greatly from spoken, at least ASL does. Without
getting too deep into it. The structure of ASL is different in
significant ways from spoken English or Russian. (the only other
languages I am familiar enough with to compare) For example, ASL lacks
the "to be" verb. It simply isn't there.
ASL incorporates not only hand position, but body position, expression,
etc. Nuances are possible that the spoken word alone can't handle. In
the way you sign it, "walking the dog" can show that the dog was large,
small, aggresive, or ambling. Or that it was cold when you did it, etc.
>
> thad01> My girlfriend is currently teaching me sign
> thad01> language... otherwise this thought might not have occurred
> thad01> to me.
>
> So, have you not realized that sign languages also have lexicon,
> syntax and semantics like spoken languages? Mentally, learning a sign
> language is not that different than learning a foreign language. Just
> that you use different sets of muscles and different receptive organs.
>
>
That doesn't mean that ASL and spoken are similar, or don't have vastly
different structures. Learning to shoot a bow means that you "use
different sets of muscles and different receptive organs." than peeling
an apple, doesn't mean they are similar.
There are significant differences in the abstract layers. ASL is
positional, it's similar in some ways to painting an image, or
constructing a model. The seriel vs parallel bit you mention is another
structural difference.
Can you communicat the same things with ASL and spoken? of course, but
that doesn't mean they don't differ in fundamental ways.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDf3Y4d90bcYOAWPYRApIJAKCMxSfJUqNzoi/LrTP5rwoB4vuDLwCfZsna
jbYadkLLDjk/rxLuzUo70nY=
=7J2w
-----END PGP SIGNATURE-----
--
Jim Richardson http://www.eskimo.com/~warlock
One man's religion is another man's belly laugh.
Linønut
> DFS wrote:
>
>> GreyCloud wrote:
>>
>>>Click n' drag has never been more fun that click'n drag M$ office
>>>trial on a mac to the dust bin. The best software removal tool I've
>>>ever used.
>>
>> That was a mistake. Now you're stuck with inferior office software.
>
> I don't need their stuff. Plus it was way too expensive. Apple Works 6
> is quite adequate for what little I do with office work.
DFS is a big fan of "one size fits all". That may be why his skivvies
are always down around his ankles.
Anyway, for the record, my opinion is in accord with Grey's: MS Office
is crap. I'd rather go back to WordPerfect than use MS Office. MS
Office is a good example of why a monopoly is not good for the consumer.
--
Treat yourself to the devices, applications, and services running on the
GNU/Linux® operating system!
Linønut
> Sign language varies greatly from spoken, at least ASL does. Without
> getting too deep into it. The structure of ASL is different in
> significant ways from spoken English or Russian. (the only other
> languages I am familiar enough with to compare) For example, ASL lacks
> the "to be" verb. It simply isn't there.
>
> ASL incorporates not only hand position, but body position, expression,
> etc. Nuances are possible that the spoken word alone can't handle. In
> the way you sign it, "walking the dog" can show that the dog was large,
> small, aggresive, or ambling. Or that it was cold when you did it, etc.
A very good capsule description, Jim!
> That doesn't mean that ASL and spoken are similar, or don't have vastly
> different structures. Learning to shoot a bow means that you "use
> different sets of muscles and different receptive organs." than peeling
> an apple, doesn't mean they are similar.
>
> There are significant differences in the abstract layers. ASL is
> positional, it's similar in some ways to painting an image, or
> constructing a model. The seriel vs parallel bit you mention is another
> structural difference.
>
> Can you communicat the same things with ASL and spoken? of course, but
> that doesn't mean they don't differ in fundamental ways.
Actually, the theory is that the same brain operations are involved in
comprehending speech and sign language, to some extent.
--
"Train go sorry".
Jim Richardson
Hash: SHA1
On Sat, 19 Nov 2005 13:29:25 -0600,
Linųnut <linųn...@bone.com> wrote:
> After takin' a swig o' grog, Jim Richardson belched out this bit o' wisdom:
>
>> Sign language varies greatly from spoken, at least ASL does. Without
>> getting too deep into it. The structure of ASL is different in
>> significant ways from spoken English or Russian. (the only other
>> languages I am familiar enough with to compare) For example, ASL lacks
>> the "to be" verb. It simply isn't there.
>>
>> ASL incorporates not only hand position, but body position, expression,
>> etc. Nuances are possible that the spoken word alone can't handle. In
>> the way you sign it, "walking the dog" can show that the dog was large,
>> small, aggresive, or ambling. Or that it was cold when you did it, etc.
>
> A very good capsule description, Jim!
>
:) I have a bunch of deaf friends, I sign a fair bit, although slowly.
>> That doesn't mean that ASL and spoken are similar, or don't have vastly
>> different structures. Learning to shoot a bow means that you "use
>> different sets of muscles and different receptive organs." than peeling
>> an apple, doesn't mean they are similar.
>>
>> There are significant differences in the abstract layers. ASL is
>> positional, it's similar in some ways to painting an image, or
>> constructing a model. The seriel vs parallel bit you mention is another
>> structural difference.
>>
>> Can you communicat the same things with ASL and spoken? of course, but
>> that doesn't mean they don't differ in fundamental ways.
>
> Actually, the theory is that the same brain operations are involved in
> comprehending speech and sign language, to some extent.
>
I've seen one case of a person who could sign and speak, who lost much
of his speech ability after a car crash, but could still sign fine,
understood speech fine too, but had difficulty putting the words
together himself. But the brain is pretty complex, so this kind of thing
isn't too surprising.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDf5tid90bcYOAWPYRApSBAKCvjthbcFUf9QLedOW50KalnpV91ACfVOgP
SdpV2fd4fvTFXmXTAJ1UmX8=
=twjA
-----END PGP SIGNATURE-----
--
Jim Richardson http://www.eskimo.com/~warlock
Silence is one of the most effective forms of communication.
Lee Sau Dan
nobody> The big problem is that Windows has very few applications
nobody> that can be useful without direct user intervention at
nobody> runtime (unless you want to learn how to write VBS
nobody> scripts).
>> A big big design flaw.
Larry> What Linux apps exist that don't exist on Windows that can
Larry> be easily scheduled without writing scripts?
A lot. Unless you say a line in crontab is a script.
Lee Sau Dan
Jim> Sign language varies greatly from spoken, at least ASL
Jim> does. Without getting too deep into it. The structure of ASL
Jim> is different in significant ways from spoken English or
Jim> Russian. (the only other languages I am familiar enough with
Jim> to compare) For example, ASL lacks the "to be" verb. It
Jim> simply isn't there.
You should also point out the difference in word order. English is
SVO (subject, verb, object), while ASL is SOV. Also, ASL has some
words that are not distinguished in English, and vice versa. ASL also
has a very different tense system, I suppose. ASL is simply another
language linguistically unrelated to English.
>> So, have you not realized that sign languages also have
>> lexicon, syntax and semantics like spoken languages? Mentally,
>> learning a sign language is not that different than learning a
>> foreign language. Just that you use different sets of muscles
>> and different receptive organs.
Jim> That doesn't mean that ASL and spoken are similar, or don't
Jim> have vastly different structures.
I didn't say similar in form. I said similar in working principles.
Are you arguing that ASL has no grammar, no lexicon and no semantics?
Lee Sau Dan
Linųnut> Anyway, for the record, my opinion is in accord with
Linųnut> Grey's: MS Office is crap. I'd rather go back to
Linųnut> WordPerfect than use MS Office.
Yeah! I still feel WP5.1 is superior to any versions of MS Word.
Linųnut> MS Office is a good example of why a monopoly is not good
Linųnut> for the consumer.
I can't agree more! There used to be Lotus Ami Pro and 123. No
comment on these choices. There used to be Word Perfect, which,
before version 6.0, was my favourite. There was even Wordstar. And
the first spreadsheet program I used was VisiCalc, first word
processor: Magic Window. These goodies were all killed by a monopoly
leveraging its monopoly status from the OS market segment.
--
Lee Sau Dan
John Bailo
> The question is: How to we incorporate a linguistic interface in a way
> that the user will be inclined to use it?
Ever hear of the locator box in a browser?
People use text CLI all the time, everytime they type in a URL -- they just
don't see it that way, but they are essentially issuing a command to the
network for information.
Another example? Google. Google is pure CLI -- it's just that the
request is for information.
DFS
>>>>>> "Linønut" == Linønut <linøn...@bone.com> writes:
>
> Linønut> Anyway, for the record, my opinion is in accord with
> Linønut> Grey's: MS Office is crap. I'd rather go back to
> Linønut> WordPerfect than use MS Office.
>
> Yeah! I still feel WP5.1 is superior to any versions of MS Word.
You probably think slrn is a great newsreader, too.
> Linønut> MS Office is a good example of why a monopoly is not good
> Linønut> for the consumer.
>
> I can't agree more! There used to be Lotus Ami Pro and 123. No
> comment on these choices. There used to be Word Perfect, which,
> before version 6.0, was my favourite. There was even Wordstar. And
> the first spreadsheet program I used was VisiCalc, first word
> processor: Magic Window. These goodies were all killed by a monopoly
> leveraging its monopoly status from the OS market segment.
You're deluded. They killed themselves off by not being competitive.
That's it.
Lots of competing products sell alongside MS offerings. Intuit Quicken
didn't die when MS Money was introduced. Filemaker is selling alongside MS
Access. Corel Wordperfect Office is still out there on the market - and
apparently doing pretty well, because I saw it on the shelf at Office Depot
the other day with a price just below MS Office.
cola bozos claim Windows was forced on everyone. How has MS not been able
to force everyone to buy Money and Encarta and SQL Server? (no answer will
be forthcoming from cola)
na...@auroville.org.in
that it was very important for me to start with a GUI interface to have
the taste of GNU/Linux.
It is immediate, easy to learn and intuitive enough to use not to
require a previous knowledge of the OS.
Yes, a little bit of personal effor is required, but this is exactly
what , for me, gives GNU/Linux an edge over Windoze.
The discovery of the importance and power of the CLI is slowing
emerging as I learn bit by bit how to use it and how many more
possibilities are hidden behind that black screen, which I found at the
beginning to be very intimidating.
This tread reminds me of an old story of three blind men touching each
of them the same object and each one of them describing it as a
different thing;
the first describes it a a big leg;
the second as a tail;
the third as a big flat ear
because they where blind they could not see they were touching an
elephant...
well something like this...
:-)
newbie/lamer/Santo
Santo
George Ellison
>> Linųnut> Grey's: MS Office is crap. I'd rather go back to
>> Linųnut> WordPerfect than use MS Office.
>>
>> Yeah! I still feel WP5.1 is superior to any versions of MS Word.
>
> You probably think slrn is a great newsreader, too.
>
>
It beats the shit out of OE, that's for sure.
>
>> Linųnut> MS Office is a good example of why a monopoly is not good
>> Linųnut> for the consumer.
tha...@tux.glaci.remove-this.com
My girlfriend is a linguistics major and could probably explain the
difference better. The gist of it is that a phoneme based language
will use a comparatively arbitrary set of sounds to mean something,
while sign language will use a visual representation that attempts
to (however vaguely) actually *look* like the thing you are signing
about. The sign itself will attempt to encapsulate the meaning it
is intending to communicate rather than just being a random symbol
that you need to memorize and repeat. Thus sign language lends
itself to a level of individual variation that would cause
problems in a spoken language. As long as a person understands
the underlying concept that the sign is emulating, they will
likely understand the slight variations that someone might make
up on the fly to shade it with a little more meaning.
This might present unique challenges when teaching a computer sign
language. Then again, there are plenty of challenges in teaching a
computer a spoken language. In both cases, we depend on a full
breadth of life experience to understand the subtleties of the
language... that is not an easy thing to teach a machine.
Later,
Thad
John Bailo
> I've had conversations with users, and they want a CLI. They don't know
> it, but I've heard things like "how can I just tell it what I want to do?"
> "Why can't I just tell it to pop out the CD?" "Why can't I say 'record at
> 5:00'?"
I went to a late night showing of "Walk The Line" ( A+ movie ) and I was
thinking about this thread some more.
The DOS Troll argument is all about the arcane "unix commands" that it is
claimed the "average person" will never master.
Yet, look at the internet itself. Look at chat. Look at tagging.
There is a whole language of abbreviation made up of extreme /shorthand/
cu later
sk8rboi
;)
IMHO
and so on. Far from avoiding shorthand, people seem to naturally *create*
shorthands!
That is what the original unix commands are all about! That people,
naturally, would *want* a shorthand, a text shorthand, for manipulating
their computers -- in the same way that they text message with shorthand on
their cell phones today!
Kleuskes & Moos
Lee Sau Dan schreef:
> >>>>> "Kleuskes" == Kleuskes & Moos <kle...@xs4all.nl> writes:
>
> Kleuskes> (Courier) findfont 12 scalefont setfont (\(sorry,
> Kleuskes> couldn't resist\))(The Good Old Kleuskes> Days)
> Kleuskes> (Postscript...)(Ah,) 50 10 moveto show 80 10 moveto
> Kleuskes> show 100 10 moveto show 120 10 moveto show showpage
>
> I didn't know "(Courier) findfont" would work.
Well, it does. If you do not believe me (and there's no reason you
should) whip out ghostscript and try.
> The examples always use "/Courier findfont", and I have been assuming that "findfont"
> expects a name rather than a string as the operand.
In postscipt its not that hard to convert one to the other or to
inspect the type of the top
operand, "/Courier" is a literal type, btw. I have never heard it call
a name.
> r> In addition, you can use <command> --help on almost every
> r> single command line command, which can be used to quickly get a
> r> list of which flags are available.
> >> And many DOS programs during the last incarnations of MS-DOS
> >> had the "/?" switch, too!
>
> Kleuskes> Many *nix tools offer -h or --help or else man and
> Kleuskes> apropos...
>
> Well... I don't think so. Only the GNU toolchain and the modern tools
> offer -h and --help. Older unix tools are pretty unfriendly.
That's why I said "many" instead of "all". And i'm not into computer
archeology, so in 2005 I would probably be discussing fairly _modern_
versions. Besides, both Solaris and BSD offer --help and/or -h on many
tools.
Printing 'usage' messages was required when I went to school in 1984
and pretty common on the toolset in use there.
> Try some vendor unix and you'll encounter their 'ls', 'find', 'cp', 'tar',
> etc. which are so much dumber than the GNU ones.
Well... Sofar i've tried IRIX, AIX (which isn't really friendly,
agreed), Solaris (which is pretty friendly) and BSD. Most of them offer
-h. AIX being the exception.
> They usually lack the "-h" and won't support long options. Many even lack the
> intelligence of many GNU implementations.
Care to name any examples, like *nix So-and-so this and that tool is
pretty unfriendly and does not support long options nor '-h'? Or are
you sticking to vague 'old versions' which don't? AFAIK long options
and -help were pretty much introduced by BSD, the famous 'west-coast'
unix. The kind of 'buckshot' argument you use is absolutely useless to
make a point. You always hit _something_.
> (e.g. GNU 'cp' would refuse to do anything but print a warning if you give it more than 2
> arguments and the last one doesn't name an existing directory.)
A cp with different behavior would not be up to standards, would it.
IIRC PRIMOS (on a PRIME from the late 70's) did exactly the same. So
did AIX, which is noted for it's unfriendlyness, or, for that matter,
any *nix living up to the Sus XBD standard.
What's your _point_?
> Kleuskes> Such a tool should not be all *that* difficult to
> Kleuskes> write... Pipes aren't really the problem, for, while,
> Kleuskes> switch etc, would be more difficult. It needs a well
> Kleuskes> thought our visual layout, though. You could offer
> Kleuskes> integrated man-page and info support...
>
> And the best interface, IMO, for me to freely and easily and flexibly
> combine while, switch, if-the-else, etc., is: a text editor. No GUI
> can compare.
Well your opinion isn't exactly the only opinion and there's no reason
for me to prefer your opinion over that of others. The fact that I
happen to agree, does not alter anything. You are not the Jezus Christ
of tool development, you know.
> A text editor that can automatically indent the code is very helpful.
I don't think so. I hate tools that think they're so smart they can
guess what I want. Most of the time they get it wrong. Many editors
can, but I usually turn the feature _off_. If you don't _want_ to use
it, you don't _have_ to.
--
> Lee Sau Dan 李守敦 ~{@nJX6X~}
>
> E-mail: dan...@informatik.uni-freiburg.de
Ah, you're a lover of big lists of spam, obviously. If your not a
phisher-fan, this isn't exactly _smart_.
> Home page: http://www.informatik.uni-freiburg.de/~danlee
Kier
> Lee Sau Dan wrote:
>>>>>>> "Linønut" == Linønut <linøn...@bone.com> writes:
>>
>> Linønut> Anyway, for the record, my opinion is in accord with
>> Linønut> Grey's: MS Office is crap. I'd rather go back to
>> Linønut> WordPerfect than use MS Office.
>>
>> Yeah! I still feel WP5.1 is superior to any versions of MS Word.
>
> You probably think slrn is a great newsreader, too.
It is. Why shouldn't it be? It does what it needs to do - read news -
without a lot of overhead, and has a lot of flexibility in killfiling. An
app doesn't always have to be pretty to be useful and functional.
<snip>
--
Kier
Linønut
> On 2005-11-20, DFS <nospam@dfs_.com> wrote:
>> Lee Sau Dan wrote:
>>>>>>>> "Linųnut" == Linųnut <linųn...@bone.com> writes:
>>>
>>> Linųnut> Anyway, for the record, my opinion is in accord with
>>> Linųnut> Grey's: MS Office is crap. I'd rather go back to
>>> Linųnut> WordPerfect than use MS Office.
>>>
>>> Yeah! I still feel WP5.1 is superior to any versions of MS Word.
>>
>> You probably think slrn is a great newsreader, too.
Of course it is. That's why I use it in preference to all the other
newsreaders I've tried:
COM (a real oldie, on a DEC-10 running TOPS-10)
Netscape
Mozilla
Thunderbird
pine
Outlook
Outlook Express
> It beats the shit out of OE, that's for sure.
That's like beating a dead horse, though.
>> cola bozos claim Windows was forced on everyone. How has MS not been able
>> to force everyone to buy Money and Encarta and SQL Server? (no answer will
>> be forthcoming from cola)
DFS needs to read a bit about the history of MS Office. Can you say
"browbeat the customer"? "Butter up the pointy-haired boss"? "Bundle
with OEM installs"?
DFS is living in a cloud-cuckoo land of his own making, which would be a
very funny thing if it didn't also have a nasty and perverse side.
DFS
> On Sat, 19 Nov 2005 23:42:48 -0500, DFS wrote:
>
>> Lee Sau Dan wrote:
>>>>>>>> "Linønut" == Linønut <linøn...@bone.com> writes:
>>>
>>> Linønut> Anyway, for the record, my opinion is in accord with
>>> Linønut> Grey's: MS Office is crap. I'd rather go back to
>>> Linønut> WordPerfect than use MS Office.
>>>
>>> Yeah! I still feel WP5.1 is superior to any versions of MS Word.
>>
>> You probably think slrn is a great newsreader, too.
>
> It is.
If you say so. The chance that you actually use it, though, is about 0%.
> Why shouldn't it be? It does what it needs to do - read news -
> without a lot of overhead, and has a lot of flexibility in
> killfiling. An app doesn't always have to be pretty to be useful and
> functional.
And for evidence of that statement you can point to hundreds of OSS apps.
> <snip>
Kier
> Kier wrote:
>> On Sat, 19 Nov 2005 23:42:48 -0500, DFS wrote:
>>
>>> Lee Sau Dan wrote:
>>>>>>>>> "Linønut" == Linønut <linøn...@bone.com> writes:
>>>>
>>>> Linønut> Anyway, for the record, my opinion is in accord with
>>>> Linønut> Grey's: MS Office is crap. I'd rather go back to
>>>> Linønut> WordPerfect than use MS Office.
>>>>
>>>> Yeah! I still feel WP5.1 is superior to any versions of MS Word.
>>>
>>> You probably think slrn is a great newsreader, too.
>>
>> It is.
>
> If you say so. The chance that you actually use it, though, is about 0%.
Don't be a fool.
>
>
>> Why shouldn't it be? It does what it needs to do - read news -
>> without a lot of overhead, and has a lot of flexibility in
>> killfiling. An app doesn't always have to be pretty to be useful and
>> functional.
>
> And for evidence of that statement you can point to hundreds of OSS apps.
You're very stupid if you think such a witless remark has any meaning at
all.
Looks aren't everything.
--
Kier
GreyCloud
> Lee Sau Dan wrote:
>
>>>>>>>"Linųnut" == Linųnut <linųn...@bone.com> writes:
>>
>> Linųnut> Anyway, for the record, my opinion is in accord with
>> Linųnut> Grey's: MS Office is crap. I'd rather go back to
>> Linųnut> WordPerfect than use MS Office.
>>
>>Yeah! I still feel WP5.1 is superior to any versions of MS Word.
>
>
> You probably think slrn is a great newsreader, too.
>
It is. Just don't need all of its capabilities.
On the office software part, on my old IBM I've still have the
SmartSuite softeware and it is more than adequate for my needs. Why
shovel out more money on software that you just don't need? It is
necessity that is important, and M$ Office isn't necessary.
>>I can't agree more! There used to be Lotus Ami Pro and 123. No
>>comment on these choices. There used to be Word Perfect, which,
>>before version 6.0, was my favourite. There was even Wordstar. And
>>the first spreadsheet program I used was VisiCalc, first word
>>processor: Magic Window. These goodies were all killed by a monopoly
>>leveraging its monopoly status from the OS market segment.
>
>
> You're deluded. They killed themselves off by not being competitive.
> That's it.
>
> Lots of competing products sell alongside MS offerings. Intuit Quicken
> didn't die when MS Money was introduced. Filemaker is selling alongside MS
> Access. Corel Wordperfect Office is still out there on the market - and
> apparently doing pretty well, because I saw it on the shelf at Office Depot
> the other day with a price just below MS Office.
>
> cola bozos claim Windows was forced on everyone.
Then show us all how to buy a Dell, HP, or Gateway without M$ o/s installed?
DFS
Typical non-sequitur from a smarmy cola bozo. What does MS have to do with
what 3rd party vendors sell?
Besides, you can just log to the Dell and HP websites and point-click and a
week later the FedEx truck will have a Windows-free system at your front
door.
Or you can buy from other vendors. Or build your own.
Never in history have you been forced to buy a computer with MS Windows
pre-installed - that's just one of the many lies cola nuts continue to bleat
because they're embarrassed that nobody, including you, buys Linux.
It's kind of sad that Linux users wonder why OEMs won't pre-install Linux
when you freeloaders yourselves refuse to purchase it.
Larry Qualig
nob...@nowhere.nonet wrote:
> On 19 Nov 2005 23:08:00 +0800, Lee Sau Dan
> >
> > nobody> these files onto WinZip, you'll soon discover, as I did,
> > nobody> that this only results in one WinZip window for each and
> > nobody> every ZIP file.
> > Wow! How long does it take for you to close these 100 WinZip windows?
> > Is there anything even close to the Linux command
> >
> > killall winzip
>
> Actually, the machine I was on when this happened to me hit the
> swap file so hard that I had to hit the power switch. Even if
> I could bring up a CMD.EXE window, there is NO command to kill
> even a single process. Also, you can't select multiple processes
> to kill in the Task Manager.
"taskkill" - will do the trick. There are loads of switches that let
you kill by name (ie - "winzip") or by wildcard (win*) or by process
ID, or by memory usage or by CPU usage or by window title or by pretty
much anything you can think of. And yes... if you don't have rights to
kill a task you can supply the username/password of an Admin account to
kill a system task if that's what you're trying to do.
Just because you guys don't know that some command exists doesn't make
it true. Do a little basic "fact checking" before you start claiming
something doesn't exist.
Simon.
>On Fri, 18 Nov 2005 18:12:05 -0500, DFS <nospam@dfs_.com> spewed
>forth this unto the Network:
>> Edwards wrote:
>>> On 2005-11-18, DFS <nospam@dfs_.com> wrote:
>>>> mlw wrote:
>
>>>> In general I really really dislike the CLI, and I think most people
>>>> do. It's boring to look at, and tedious to use.
>>>
>>> Nonsense, clicking and dragging a bunch of file icons, or typing
>>> a command to do something to a bunch of filenames -- it's the same
>>> amount of tedium.
>>
>> Nonsense. Click n' drag is fun. It provides the visual feedback that makes
>> the user feel involved. Plus it's easier to visually scan the files you
>> want to copy/move and select them than it is to type the commands.
>>
>
>[ This is my second attempt to write this response. Windows XP
> blue-screened on me during the last attempt ]
>
>Click-and-drag is only easier when all the files you're trying to
>work on just happen to be arranged in a rectangular area in your
>file manager.
>
>Sometimes, GUIs can be far MORE tedious than a command line. For
>example, suppose you have a directory full of ZIP files, and you
>want to extract them all into one directory. If you select them
>all in Windows, and then right-click, you will discover that the
>"Extract all" option doesn't appear when you select more than
>one ZIP file. You must right click EACH file and go through the
>extraction wizard. So, if you have 100 ZIP files, you must
>go through the wizard 100 times. And that is NOT "fun." There
>is no Windows GUI equivalent to "unzip *.zip".
>
>I've seen many situations where the only way to do it in Windows
>is one file at a time, where it can be done in Linux with just
>one command.
>
>If you try to be smarter than Windows by dragging all of these
>files onto WinZip, you'll soon discover, as I did, that this
>only results in one WinZip window for each and every ZIP file.
>
>I wondered whether this behavior is caused by WinZip, or by Windows.
>Perhaps explorer.exe spawns one copy of the program for each
>file, unlike a Linux file manager, which would simply pass all the
>files on a command line.
>
>I tried to compare the difference between typing "edit *.txt" and
>selecting a bunch of text files and using "Open With". However,
>it turns out that "edit *.txt" causes the dreaded Blue Screen of
>Death on Windows, INSTANTLY.
Much as I'd like to agree with you here I find that "edit *.txt" on my three
test files one.txt two.txt and three.txt doesn't do that
Under the CLI edit *.txt opens up the blue text editor which to my surprise
actually has under ALT-View the choice for which file I wish to edit.
Pity that - I was looking forward to a BSOD this time :-)
--
Simon.
'Be Seeing You.
Who is number one?
I will not be pushed, filed, stamped, indexed, briefed, de-briefed or numbered.
Registered Linux User #300464 Machine Id #188886
Linux Counter - http://counter.li.org/
Remove the s.p.a.m to reply
Lee Sau Dan
Linřnut> Anyway, for the record, my opinion is in accord with
Linřnut> Grey's: MS Office is crap. I'd rather go back to
Linřnut> WordPerfect than use MS Office.
>> Yeah! I still feel WP5.1 is superior to any versions of MS
>> Word.
DFS> You probably think slrn is a great newsreader, too.
No. I've been using GNUS and Gnus for over a decade.
>> I can't agree more! There used to be Lotus Ami Pro and 123.
>> No comment on these choices. There used to be Word Perfect,
>> which, before version 6.0, was my favourite. There was even
>> Wordstar. And the first spreadsheet program I used was
>> VisiCalc, first word processor: Magic Window. These goodies
>> were all killed by a monopoly leveraging its monopoly status
>> from the OS market segment.
DFS> You're deluded. They killed themselves off by not being
DFS> competitive. That's it.
How can one compete when another company steps in and leverage their
advantage of already being a monopoly in a related market?
DFS> Lots of competing products sell alongside MS offerings.
Yeah. DR-DOS, for instance. And what did MS do to kill DR-DOS?
DR-DOS didn't die because it's inferior, but because of MS's immoral
means of eliminating superior competitors.
Lee Sau Dan
>> You probably think slrn is a great newsreader, too.
Kier> It is. Why shouldn't it be? It does what it needs to do -
Kier> read news - without a lot of overhead, and has a lot of
Kier> flexibility in killfiling. An app doesn't always have to be
Kier> pretty to be useful and functional.
DFS may prefer to cut meat with a knife that has been painted with
fancy pictures on the cutting edge. :)
Yeah. There are people in this world who prefer to use something
pretty rather than something that works. But not me. I want to get
work done, not to get work pretty.
--
Lee Sau Dan 李守敦 ~{@nJX6X~}
E-mail: dan...@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
DFS
>>>>>> "Kier" == Kier <val...@tiscali.co.uk> writes:
>
> >> You probably think slrn is a great newsreader, too.
>
> Kier> It is. Why shouldn't it be? It does what it needs to do -
> Kier> read news - without a lot of overhead, and has a lot of
> Kier> flexibility in killfiling. An app doesn't always have to be
> Kier> pretty to be useful and functional.
>
> DFS may prefer to cut meat with a knife that has been painted with
> fancy pictures on the cutting edge. :)
>
> Yeah. There are people in this world who prefer to use something
> pretty rather than something that works. But not me. I want to get
> work done, not to get work pretty.
Is that GNUs you're using this one http://my.gnus.org/node/316 with all the
icons at the top that you can click with your mouse?
And I agree with you: it's not pretty.
DFS
>>>>>> "DFS" == DFS <nospam@dfs_.com> writes:
>
> Linřnut> Anyway, for the record, my opinion is in accord with
> Linřnut> Grey's: MS Office is crap. I'd rather go back to
> Linřnut> WordPerfect than use MS Office.
> >> Yeah! I still feel WP5.1 is superior to any versions of MS
> >> Word.
>
>
> No. I've been using GNUS and Gnus for over a decade.
You poor thing.
> >> I can't agree more! There used to be Lotus Ami Pro and 123.
> >> No comment on these choices. There used to be Word Perfect,
> >> which, before version 6.0, was my favourite. There was even
> >> Wordstar. And the first spreadsheet program I used was
> >> VisiCalc, first word processor: Magic Window. These goodies
> >> were all killed by a monopoly leveraging its monopoly status
> >> from the OS market segment.
>
>> You're deluded. They killed themselves off by not being
>> competitive. That's it.
>
> How can one compete when another company steps in and leverage their
> advantage of already being a monopoly in a related market?
So MS prevented everyone from buying and installing those programs?
>> Lots of competing products sell alongside MS offerings.
>
> Yeah. DR-DOS, for instance. And what did MS do to kill DR-DOS?
Nothing, of course, except compete on features and marketing.
> DR-DOS didn't die because it's inferior, but because of MS's immoral
> means of eliminating superior competitors.
DR-DOS is still around.
Tom Shelton
>>>>>> "DFS" == DFS <nospam@dfs_.com> writes:
>
<snip>
>
>
>
> >> I can't agree more! There used to be Lotus Ami Pro and 123.
> >> No comment on these choices. There used to be Word Perfect,
> >> which, before version 6.0, was my favourite. There was even
> >> Wordstar. And the first spreadsheet program I used was
> >> VisiCalc, first word processor: Magic Window. These goodies
> >> were all killed by a monopoly leveraging its monopoly status
> >> from the OS market segment.
>
> DFS> You're deluded. They killed themselves off by not being
> DFS> competitive. That's it.
>
> How can one compete when another company steps in and leverage their
> advantage of already being a monopoly in a related market?
>
The same way that Firefox is competing with IE, by building a better
product.
--
Tom Shelton
Lee Sau Dan
John> People use text CLI all the time, everytime they type in a
John> URL -- they just don't see it that way, but they are
John> essentially issuing a command to the network for
John> information.
John> Another example? Google. Google is pure CLI -- it's just
John> that the request is for information.
Imagine a Google GUI which contains millions of icons (or menu
entries) organized into thousands screens (or menus/submenus). So
"usable" and so "intuitive"!!!
Search is an important feature in an information applicance. And unix
has such a tool since decades ago: grep. I like Emacs's interfaces
(dired, PCL-CVS, psvn, etc.) because Emacs's search functions
(e.g. Ctrl-S) allow me to search *in the labels* of the TUI buttons,
checkboxes, combo boxes, etc. And it offers completion for the combo
boxes, too. So much more advanced than most GUI apps. If I want to
click the "foo" hyperlink in a web page, in emacs (or recently
Firefox), I just need to search for "foo" and I can find it. No need
to use my eyes to scan through a page full of text and links. That's
unbeatable.
Lee Sau Dan
nanci> As a newbie to GNU/Linux and computer in general I would
nanci> like to say that it was very important for me to start with
nanci> a GUI interface to have the taste of GNU/Linux. It is
nanci> immediate, easy to learn and intuitive enough to use not to
nanci> require a previous knowledge of the OS.
But the GUI is also more restrictive, and prevents you from accessing
the more powerful features.
nanci> The discovery of the importance and power of the CLI is
nanci> slowing emerging as I learn bit by bit how to use it and
nanci> how many more possibilities are hidden behind that black
nanci> screen,
Yes, much is "hidden" behind the black screen, but they're there
waiting for you to discover. The mysterious black screen doesn't
restrict you from discovering and using the capabilities of the CLI.
GUIs, OTOH, usually restricts what you can do. They hide the
complexities, and also the potentials of the system. GUI is usually
AYSIAYG (A=>all), no more. No extensibility. No flexibility. No
imaginations.
nanci> which I found at the beginning to be very intimidating.
nanci> This tread reminds me of an old story of three blind men
nanci> touching each of them the same object and each one of them
nanci> describing it as a different thing; the first describes it
nanci> a a big leg; the second as a tail; the third as a big flat
nanci> ear because they where blind they could not see they were
nanci> touching an elephant... well something like this... :-)
I don't like this story, because it discriminates blind people. It
spreads the message: Since blind people can't see, they can't
understand the world as well as we seeing people do. That's a wrong
concept.
Blind people, e.g. those who're already blind since childhood, have
developed a much more sensitive auditory system. And they tend to be
able to make better use their biggest organ: sensory cells on the
skin. They tend to be better listeners and better observers. Blind
people often "see" more.
Kleuskes & Moos
Lee Sau Dan wrote:
> >>>>> "nanci" == nanci <na...@auroville.org.in> writes:
>
> nanci> As a newbie to GNU/Linux and computer in general I would
> nanci> like to say that it was very important for me to start with
> nanci> a GUI interface to have the taste of GNU/Linux. It is
> nanci> immediate, easy to learn and intuitive enough to use not to
> nanci> require a previous knowledge of the OS.
>
> But the GUI is also more restrictive, and prevents you from accessing
> the more powerful features.
So? All he's claiming is that it's good to _start_ with a GUI, simply
because it does not have such a steep learning curve and it allows him
to get a taste of GNU/Linux. He does not say CLI's are forever off
limits. He'll get there...
> nanci> The discovery of the importance and power of the CLI is
> nanci> slowing emerging as I learn bit by bit how to use it and
> nanci> how many more possibilities are hidden behind that black
> nanci> screen,
>
> Yes, much is "hidden" behind the black screen, but they're there
> waiting for you to discover.
So be patient.
> The mysterious black screen doesn't restrict you from discovering and using the capabilities > of the CLI.
Nope. He'll get there.
> GUIs, OTOH, usually restricts what you can do. They hide the
> complexities, and also the potentials of the system. GUI is usually
> AYSIAYG (A=>all), no more. No extensibility. No flexibility. No
> imaginations.
So? He never said GUI's are _all_ he's ever going to use, and besides,
even if he is, that's _his_ decision, not yours.
> nanci> which I found at the beginning to be very intimidating.
> nanci> This tread reminds me of an old story of three blind men
> nanci> touching each of them the same object and each one of them
> nanci> describing it as a different thing; the first describes it
> nanci> a a big leg; the second as a tail; the third as a big flat
> nanci> ear because they where blind they could not see they were
> nanci> touching an elephant... well something like this... :-)
>
> I don't like this story, because it discriminates blind people.
So go complain to the authors of that parable.
> It spreads the message: Since blind people can't see, they can't
> understand the world as well as we seeing people do. That's a wrong
> concept.
And yoiu are addressing something that's completely beside the point.
> Blind people, e.g. those who're already blind since childhood, have
> developed a much more sensitive auditory system. And they tend to be
> able to make better use their biggest organ: sensory cells on the
> skin. They tend to be better listeners and better observers. Blind
> people often "see" more.
Perhaps, but that's completely beside the point. Wether you like the
parable or not, it does make a point you fail to address completely.
People have the choice between uising a GUI and/or a CLI on linux (and
other OS's). The choice is theirs. Your preference isn't the be-all and
end-all argument.
GUI's may not be as flexible as a CLI, but CLI can be _very_ clumsy in
many applications, especially when dealing with spatial data like
graphics or GIS applications. You _need_ a GUI for those to be
effective.
Both have pro's and con's. It is pointless to say "CLI is better" or
"GUI's are better". Both have their advantages and disadvantages. Use
the one you're comfortable with and that is good at the task at hand.
And GUI's _are_ better at some tasks, CLI's at others.
Roy Culley
<y0cgf.75$SA4....@news.uswest.net>,
Tom Shelton <t...@YOUKNOWTHEDRILLmtogden.com> writes:
> Lee Sau Dan wrote:
>
>> How can one compete when another company steps in and leverage
>> their advantage of already being a monopoly in a related market?
>
> The same way that Firefox is competing with IE, by building a better
> product.
That's only part of the story. Because MS bundle IE with Windows the
alternative product must be a hell of a lot better if you want people
to pay for it. If firefox cost even a few dollars I'm sure its
adoption would be very much lower. IMHO firefox is a far better
browser than IE yet the majority of Windows users stick with IE even
though it is extremely insecure.
--
"If you think your belief is based upon reason, you will support
it by argument rather than by persecution... But if your belief is
based upon faith, you will realize that argument is useless, and
will therefore resort to force."--Bertrand Russell
Linønut
> "taskkill" - will do the trick. There are loads of switches that let
> you kill by name (ie - "winzip") or by wildcard (win*) or by process
> ID, or by memory usage or by CPU usage or by window title or by pretty
> much anything you can think of. And yes... if you don't have rights to
> kill a task you can supply the username/password of an Admin account to
> kill a system task if that's what you're trying to do.
>
> Just because you guys don't know that some command exists doesn't make
> it true. Do a little basic "fact checking" before you start claiming
> something doesn't exist.
Unfortunately, that would mean you actually have to use Windows
<<shudder>>.
MS has indeed beefed up the number of command-line apps in recent
versions of Windows.
Linønut
> Lee Sau Dan wrote:
>
>> How can one compete when another company steps in and leverage their
>> advantage of already being a monopoly in a related market?
>
> The same way that Firefox is competing with IE, by building a better
> product.
But, Tom, you're forgetting that the playing field is a little more
level here. A Firefox install is much easier for a user to manage than
an OS install.
JEDIDIAH
>
> Lee Sau Dan wrote:
>> >>>>> "nanci" == nanci <na...@auroville.org.in> writes:
> Perhaps, but that's completely beside the point. Wether you like the
> parable or not, it does make a point you fail to address completely.
> People have the choice between uising a GUI and/or a CLI on linux (and
> other OS's). The choice is theirs. Your preference isn't the be-all and
> end-all argument.
>
> GUI's may not be as flexible as a CLI, but CLI can be _very_ clumsy in
> many applications, especially when dealing with spatial data like
> graphics or GIS applications. You _need_ a GUI for those to be
> effective.
Actually, this seems to be infact not the case. The level of
precision needed for such applications oftentimes necessitates the use
of a commandline even where such usage would not be immediately obvious
to the unititated.
The CLI still manages to offer sufficiently better control,
precision and easy repeatability even in graphically oriented tasks.
>
> Both have pro's and con's. It is pointless to say "CLI is better" or
> "GUI's are better". Both have their advantages and disadvantages. Use
> the one you're comfortable with and that is good at the task at hand.
> And GUI's _are_ better at some tasks, CLI's at others.
>
--
Apple: Because a large harddrive is for power users.
|||
/ | \
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
Larry Qualig
Linønutlinøn...@bone.com wrote:
> After takin' a swig o' grog, Larry Qualig belched out this bit o' wisdom:
>
> > "taskkill" - will do the trick. There are loads of switches that let
> > you kill by name (ie - "winzip") or by wildcard (win*) or by process
> > ID, or by memory usage or by CPU usage or by window title or by pretty
> > much anything you can think of. And yes... if you don't have rights to
> > kill a task you can supply the username/password of an Admin account to
> > kill a system task if that's what you're trying to do.
> >
> > Just because you guys don't know that some command exists doesn't make
> > it true. Do a little basic "fact checking" before you start claiming
> > something doesn't exist.
>
> Unfortunately, that would mean you actually have to use Windows
> <<shudder>>.
>
> MS has indeed beefed up the number of command-line apps in recent
> versions of Windows.
Actually it means that the poster should have a clue what he's talking
about. If he's going to make a claim that something is impossible to do
(Ex: - can't close all "Winzip" windows with one command) then he's
attempting to claim that he is knowledgeable on the subject.
If he doesn't know then he shouldn't make the claim. It's no different
then someone who doesn't use Linux making false claims as to what can't
be done with Linux. Not being familiar with an OS is not an excuse for
posting lies.
Kleuskes & Moos
JEDIDIAH schreef:
> On 2005-11-21, Kleuskes & Moos <kle...@xs4all.nl> wrote:
> >
> > Lee Sau Dan wrote:
> >> >>>>> "nanci" == nanci <na...@auroville.org.in> writes:
> [deletia]
> > Perhaps, but that's completely beside the point. Wether you like the
> > parable or not, it does make a point you fail to address completely.
> > People have the choice between uising a GUI and/or a CLI on linux (and
> > other OS's). The choice is theirs. Your preference isn't the be-all and
> > end-all argument.
> >
> > GUI's may not be as flexible as a CLI, but CLI can be _very_ clumsy in
> > many applications, especially when dealing with spatial data like
> > graphics or GIS applications. You _need_ a GUI for those to be
> > effective.
>
> Actually, this seems to be infact not the case.
Oh? I can imagine a GIS application needing that kind of precision, but
that's not the only case I mentioned.
> The level of precision needed for such applications oftentimes necessitates the use
> of a commandline even where such usage would not be immediately obvious
> to the unititated.
Ok. Consider me uninitiated and please expain how a CLI is preferable
over a GUI in say image editing. Then exlain to me the lack of
command-lines in (say) Photoshop, the GIMP or somesuch application.
> The CLI still manages to offer sufficiently better control,
> precision and easy repeatability even in graphically oriented tasks.
Again, show me. Don't just stick at some vaguely mentioned 'graphically
oriented task' but show me how a CLI is more effective than a GUI in
(say) editing a pixmap. Is that why the GIMP offers such an extensive
CLI and no GUI at all? Is it that hard to allow coordinates to be
specified in a GUI text-box when a large degree of precision is
required?
Please enlighten the unititiated with your _wonderfull_ wisdom... Are
CLI's and GUI's mutually exclusive? Can I have _no_ CLI when a GUI is
also present or can a CLI be an element of a GUI like (say) xterm is in
an X-window manager?
> > Both have pro's and con's. It is pointless to say "CLI is better" or
> > "GUI's are better". Both have their advantages and disadvantages. Use
> > the one you're comfortable with and that is good at the task at hand.
> > And GUI's _are_ better at some tasks, CLI's at others.
Care to answer the point, too? Are you saying a CLI is *by definition*
better than a GUI or am i misinterpreting your post? I sure hope it's
the latter.
JEDIDIAH
>
> JEDIDIAH schreef:
>
>> On 2005-11-21, Kleuskes & Moos <kle...@xs4all.nl> wrote:
>> >
>> > Lee Sau Dan wrote:
>> >> >>>>> "nanci" == nanci <na...@auroville.org.in> writes:
>> [deletia]
>> > Perhaps, but that's completely beside the point. Wether you like the
>> > parable or not, it does make a point you fail to address completely.
>> > People have the choice between uising a GUI and/or a CLI on linux (and
>> > other OS's). The choice is theirs. Your preference isn't the be-all and
>> > end-all argument.
>> >
>> > GUI's may not be as flexible as a CLI, but CLI can be _very_ clumsy in
>> > many applications, especially when dealing with spatial data like
>> > graphics or GIS applications. You _need_ a GUI for those to be
>> > effective.
>>
>> Actually, this seems to be infact not the case.
>
> Oh? I can imagine a GIS application needing that kind of precision, but
> that's not the only case I mentioned.
>
>> The level of precision needed for such applications oftentimes necessitates the use
>> of a commandline even where such usage would not be immediately obvious
>> to the unititated.
>
> Ok. Consider me uninitiated and please expain how a CLI is preferable
> over a GUI in say image editing. Then exlain to me the lack of
It rather depends on the image. Something that requires some
real precision (like engineering plans) tend to be constructed with
tools where manipulating the "visual" can be done via commanline or
even scripted.
> command-lines in (say) Photoshop, the GIMP or somesuch application.
That sort of work leaves room for quite a bit of fudge factoring
that isn't present in other professions. Nevermind the fact that GIMP
does infact have a command driven interface. It's not interactive but it's
still there.
>
>> The CLI still manages to offer sufficiently better control,
>> precision and easy repeatability even in graphically oriented tasks.
>
> Again, show me. Don't just stick at some vaguely mentioned 'graphically
> oriented task' but show me how a CLI is more effective than a GUI in
AutoCAD
[deletia]
--
Negligence will never equal intent, no matter how you
attempt to distort reality to do so. This is what separates |||
the real butchers from average Joes (or Fritzes) caught up in / | \
events not in their control.
Kleuskes & Moos
Ok. And this _can't_ be done through a textbox in a GUI? Please note
i'm not arguing that _no_ application exists where a command-line is
better, only that _some_ applications exist where GUI's are inevitably
superior.
> > command-lines in (say) Photoshop, the GIMP or somesuch application.
>
> That sort of work leaves room for quite a bit of fudge factoring
> that isn't present in other professions.
That sort of work is exactly what i'm talking about. And your 'fudge
factor" is another persons creative hand.
> Nevermind the fact that GIMP
> does infact have a command driven interface. It's not interactive but it's
> still there.
Indeed, it has two (script-fu and python). Which leaves rather a lot of
explaining to do why all the GUI elements are rather more prevalent.
THE CLI is inteded for scripting, not for extensive image editing.
It also leave you to explain why it is better at image editing than the
(rather extensive) GUI provided.
> >> The CLI still manages to offer sufficiently better control,
> >> precision and easy repeatability even in graphically oriented tasks.
> >
> > Again, show me. Don't just stick at some vaguely mentioned 'graphically
> > oriented task' but show me how a CLI is more effective than a GUI in
>
> AutoCAD
Ok. And AutoCAD does not have a GUI?
> [deletia]
Very convenient. You've snipped the point i made without answering it.
I'll reinstate it for your convenience.
<reinstated after a convenient snip in order to avoid answering a point
being made>
Please enlighten the unititiated with your _wonderfull_ wisdom... Are
CLI's and GUI's mutually exclusive? Can I have _no_ CLI when a GUI is
also present or can a CLI be an element of a GUI like (say) xterm is in
an X-window manager?
> > Both have pro's and con's. It is pointless to say "CLI is better" or
> > "GUI's are better". Both have their advantages and disadvantages. Use
> > the one you're comfortable with and that is good at the task at hand.
> > And GUI's _are_ better at some tasks, CLI's at others.
Care to answer the point, too? Are you saying a CLI is *by definition*
better than a GUI or am i misinterpreting your post? I sure hope it's
the latter.
</reinstated after a convenient snip in order to avoid answering a
point being made>
Edwards
> Edwards wrote:
>> On 2005-11-18, DFS <nospam@dfs_.com> wrote:
>>> mlw wrote:
>>>> way that the user will be inclined to use it?
>>>
>>> In general I really really dislike the CLI, and I think most people
>>> do. It's boring to look at,
>>
>
> Instead of being 100% boring, eterm is 99.9% boring.
So don't use boring pictures for the background images, try it with
some interesting pictures. You must have plenty of those.
>>> and tedious to use.
>>
>> Nonsense, clicking and dragging a bunch of file icons, or typing
>> a command to do something to a bunch of filenames -- it's the same
>> amount of tedium.
>
> Nonsense. Click n' drag is fun.
The first time. Maybe after that if you're easily amused.
> It provides the visual feedback that makes the user feel involved.
That's not a difference; the CLI provides plenty of feedback to,
assuming the user can read. (Not even necessarily visual feedback,
blind people can use CLI's too.)
> Plus it's easier to visually scan the files you want to copy/move
> and select them than it is to type the commands.
I type a command and hit tab, and I get the same list of files that I
can "visually scan" as if I were using a GUI. And if I want to use a
command _other_ than "copy/move" it's easier to type its name than
wonder what arpeggio of "left/right clicks" needs to be played to
obtain that functionality in a GUI.
>>> But I noticed the more you use it the more comfortable you get with
>>> it, pretty quickly too. If you can touch-type at a decent rate and
>>> know your commands, you can be fairly efficient with it.
>>
>> Tab completion, etc. All I can do is hunt & peck but with all the
>> bells and whistles of modern shells, it doesn't hold me back.
>>
>>> The *nix CLI is a powerful interface. Difficult but powerful.
>>
>> It's not difficult, because it's discoverable; if you need to figure
>> out how to do something in a CLI, the answers/explanation are right
>> there in the CLI (man, apropos, info, html help files, etc).
>
> It is difficult, and it's discoverable with great effort.
"man -k list" isn't "great effort". Arguably, neither is staring at a
pretty GUI thinking "Gee, I wonder how the heck I can get this thing
to, I dunno, list my files or something?" At least with the former I
will be getting my task accomplished sometime soon.
> How do you know to type man or apropos?
The same way I learned what the heck to click on in MS windows or
Apple OS to get something to happen. I asked some one, or I read it
in a book.
> ah, you click the Help icon on the pretty GUI.
What the heck are you talking about? There's no "Help icon" on my
neighbor's mac, there was no "Help icon" on the MS Win3.1 system I
first used in 1995 (F1, or Alt-F1 was it? to bring up application
help, certainly no clickable icon), there's no "Help icon" on the MS
XP system Sony installed on my vaio laptop.
> And once you open a man page you get a screen full of gobbledygook,
Maybe you do. I sure don't.
> and arcane commands that take forever to learn and master, ie
> something like 52 switches just for ls?!
A minute to learn, a lifetime to master. Same damn thing as any GUI
I've ever seen. You make fun of me below, but I still don't know how
to select a _bunch_ of files and move _all_ of them from one place to
another at the same time. Yeah, I could go buy a book or something
(ooh, what Mac OS _Version_, she's not using OSX, let's hope the
salesman recommends the right book!), or ask a bunch of my Mac-using
friends (and write down the answer, and not lose the piece of paper,
and remmeber to bring the piece of paper next time my neighbor asks
for help...) It's just not frigging worth it; this is the kind of
crap your precious GUI is supposed to be _good_ at, isn't it?
man mv
NAME
mv - move (rename) files
SYNOPSIS
mv [OPTION]... SOURCE DEST
mv [OPTION]... SOURCE... DIRECTORY
mv [OPTION]... --target-directory=DIRECTORY SOURCE...
Ooh, right there, second line, the dots mean I can move a bunch of
files at once, and the destination "file" can be just another
directory. Options are optional so screw em this first time. Done.
>> What's difficult is sitting down at an unfamiliar GUI and struggling
>> to remember or work out by trial and error its idiosyncracies for
>> accomplishing basic tasks. Every time my next door neighbor asks for
>> help with her Mac, I grit my teeth, knowing that very soon I'll be
>> struggling to do something that ought to be simple, but unable to
>> recall whether it's done by clicking while holding down the cloverleaf
>> key, or the shift key, or the control key, or the option key, or some
>> combination of the above. I end up doing things the slow way,
>> _knowing_ there's an easier way but that it won't be worth the effort
>> of finding it. Selecting a bunch of files to be moved to a different
>> folder, say; finally I figure out how to get it to select more than
>> one file at a time, but can't for the life of me recall the _second_
>> magic key sequence to let me drag all of those files at once -- every
>> time I click it selects the one file I've clicked on and desects all
>> the others. "Searing damnation, I just want to mv R*.doc
>> ../some_other_dir/, you pestilent piece of garbage!"
>
> Interesting. I've never heard someone complain so much about having
> to use a mouse to move files.
Ha, I actually find it _funny_ that this sort of thing is harder under
the canonical "GUI" systems (MS, Apple). (Unless you've memorized the
magic key/mouse combo, but hey, if I wanted to exert mental effort I'd
be using a CLI, wouldn't I?)
> You're an old guy, aren't you? Raised on Unix?
Gah, I wish. I coulda been having fun much longer ago rather than
being introduced to it only after a few year's wasting my time with MS
Win3.1.
>> But she's eighty or so and I can't very well refuse to at least try
>> to help. :)
>
> Hey, why don't you set her up a Linux box? I'm sure she'll love the
> CLI.
Ha, funny guy, no of course she's much too frightened of change for me
to suggest that. The interesting question is, how did she and the
thousands of computer users like her get so frightened of change if
they are all sitting in front of these easy-to-use GUI miracle boxes
from MS and Apple? Aren't they accustomed to being able to experiment
any way they want, screw up their system as much as they please, and
then just press the big red "Help icon" to get everything instantly
and easily restored?
Sure, maybe they're all cowards at heart. Or maybe they've just
"right-clicked" when they should've left clicked one time too many,
and have learned painfully that a GUI isn't always as "easy" as some
folks make it out to be.
>>> The CLI is hard to like
>> It _might_ be true that some folks like CLI better,
>> some exclusive GUI, and that few switch once they've picked. (I'm not
>> convinced of that but it's at least possible.) But all of us who
>> regularly use (and do indeed like) the CLI started from scratch at one
>> point. If it were hard to like noone at _all_ would use it.
>
> When I write 'the CLI is hard to like' I'm stating my opinion. And it's
> shared by most everyone outside the odd world of Unix and Linux.
Obviously not, or Apple wouldn't have made such a big deal of the
unix-like command line functionality available in OSX when it was
introduced. Is MS Vista going to have any kind of CLI, or not?
>>> and hard to learn,
>>
>> All the anecdotal evidence I've seen suggests otherwise; it takes
>> about as much effort to "master" a CLI as a typical GUI.
>
> You're out of your mind. All the evidence points the opposite way.
> Nearly anyone can look at a computer GUI and mouse and get started
> doing something. Left click and the item is highlighted/selected.
> Right-click and you get a set of properties or options to operate on
> the item. A click or two more and you've discovered a lot about the
> object and things you can do with it.
"Right-click"? "Left-click"? Again, that doesn't help me with my
neighbor's mac. Someone who's been using a _particular_ GUI for a
while will know how to use it, wow, whatta scoop Clark. Sit them down
at a _different_ GUI and they are starting from scratch, just like
someone sitting at a CLI for the first time.
> With a CLI prompt staring at you you're just plain lost. It's kind of
> depressing, actually.
A person sitting at a GUI for the first time is just as lost. Yeah,
they can start clicking randomly on things, but 1) a person sitting at
a CLI can randomly type things with about as much chance of success,
and 2),
http://www.joelonsoftware.com/uibook/chapters/fog0000000059.html
(about two-thirds down, starting where it says "Half the screen was
grey"). Talk about getting "just plain lost". (I wish I could also
say it was "kind of depressing", but it's too darn funny.)
>> Related to
>> my rant above, my impression is that a CLI rewards incremental
>> learning. You don't _have_ to master all of /usr/bin:/usr/local/bin
>> at once, you start by learning a few commands and gradually increase
>> your vocabulary.
>
> That's probably the best way to approach it. Rather than feel you
> have to learn 50 CLI commands to be productive, focus on a few.
Hot diggity dog, that's pretty much the optimal solution on a GUI too.
Rather than memorize 50 different mouse/key gestures on my neighbor's
mac, I settle for doing things the slow way with the few I have
"focused on". She's patient, and I don't have to do it too often, so
life goes on.
So far I haven't seen any real examples of _differences_ between GUI
and CLI usability, just a few content-free yammerings about
"dinosaurs".
>> With a GUI, on the other hand, there's a fairly large repertoire of
>> "gestures" one must learn right away in order to be able to use it at
>> _all_.
>
> You're just wrong. Left-click and right-click is all you need to get
> started.
The fun you say. Well that sure helps a lot, thanks a bunch, oh wait,
I tried that on my neighbor's mac last time and THEY BOTH DO THE SAME
FREAKING THING.
Okay, seriously though, as has been patiently pointed out several
times now, "clicking" isn't all one needs to know, because the whole
point of a GUI is that clicking in different _contexts_ does different
things (and each of the different GUIs out there has its own
idiosyncratic mapping of gestures+context => actions). That's
something a user needs to learn, and it takes about as much time and
effort as learning to use a CLI.
>> Increasing that repertoire as time goes on requires
>> essentially rote memorization of new gestures that aren't necessarily
>> related to the previous ones in any syntactic or "deducible" way.
>> (Knowing that right clicking on a file in an explorer window gives you
>> access to its properties doesn't necessarily tell you anything about
>> what will happen if you right click on, say, the root desktop or the
>> toolbar.)
>>
>> Compare the (in theory subtle and complex) concept of, say, pipes in a
>> CLI. Maybe a coworker showed you how to pipe the output of ls to grep
>> or something (e.g. so you can pick which images to send to an image
>> editing program). Then a few days later you accidentally or maybe
>> even on purpose connect a couple of different text i/o programs with a
>> pipe, or discover that there can be more than two programs in your
>> "chain" of pipes, and kablammo, you've opened a whole new world for
>> yourself. I firmly believe that's because the CLI is _generalizable_
>> in a way that a GUI can't be (because the former is loosely modeled on
>> the way language works, with _syntactic_ as well as semantic
>> relationships, while the latter is more like a collection of entities
>> which may carry semantic information but have simple and generally
>> unsystematic relationships).
>
> On the other hand, the GUI conveys relationships between entities and
> provides access to them and their properties that's more difficult to
> achieve with a command line.
Same problem; learning what visual artifacts on the screen are
intended to represent what relationship among what entities on the
computer (files, devices etc) takes time and effort, about as much
time and effort as with a CLI.
>>> but not hard to appreciate.
>>
>> Well, neither is a GUI; despite the above, I don't actually sit at a
>> VGA console all day, I use enlightnement and am very happy with it.
>
> You should try KDE. It's much better than Enlightenment, from what I've
> seen.
Uh, thanks a bunch, but I _have_ used KDE along with a handful of
other window managers. I happen to prefer Enlightenment.
>> But the actual _things_ I am doing are generally happening in Eterms
>> and xemacs windows, plus programs like pdf and ps viewers (text-based,
>> but not really separable from their GUI, so what are they?). Someone
>> once quipped "Time is what keeps everything from happening at once," I
>> guess for me a window manager is what keeps all my terminals from
>> falling on top of each other. Obviously GUIs aren't going anywhere
>> anytime soon, and everyone needs to decide on their own how best to
>> get their own work done; but anyone who dismisses CLIs out of hand,
>> thinking they're "old" or "difficult" or whatnot, is missing something
>> important IMO.
>
> Probably so.
>
> But most of the world has moved away from command lines. For good reason.
I have no idea what "most of the world" is doing, and neither do you.
You and your friends have moved away from the command line? Fine,
whatever floats your boat, I don't insult folks for choices like that.
Me and my friends are comfortable with both, right tool for the right
job and all that.
--
Darrin
JEDIDIAH
>
> JEDIDIAH wrote:
>> On 2005-11-21, Kleuskes & Moos <kle...@xs4all.nl> wrote:
>> >
>> > JEDIDIAH schreef:
>> >
>> >> On 2005-11-21, Kleuskes & Moos <kle...@xs4all.nl> wrote:
>> >> >
>> >> > Lee Sau Dan wrote:
>> >> >> >>>>> "nanci" == nanci <na...@auroville.org.in> writes:
[deletia]
>>
>> That sort of work leaves room for quite a bit of fudge factoring
>> that isn't present in other professions.
>
> That sort of work is exactly what i'm talking about. And your 'fudge
> factor" is another persons creative hand.
Imprecision is simply imprecision.
Tolerating sloppiness is simply making excuses for poor
execution skills and the inability to make manifest what can be
conceptualized.
>
>> Nevermind the fact that GIMP
>> does infact have a command driven interface. It's not interactive but it's
>> still there.
>
> Indeed, it has two (script-fu and python). Which leaves rather a lot of
> explaining to do why all the GUI elements are rather more prevalent.
> THE CLI is inteded for scripting, not for extensive image editing.
I suspect it's indoctrination more than anything else.
People are constantly screamed at that trying to hit a target
with a mouse is easer than just typing in a set of coordinates.
Any CLI is ultimately a more precise method of communicating
with the computer. That level of precision is also remarkably easier
for the novice or klutz to achieve.
>
> It also leave you to explain why it is better at image editing than the
> (rather extensive) GUI provided.
I believe I mentioned something called precision.
>
>> >> The CLI still manages to offer sufficiently better control,
>> >> precision and easy repeatability even in graphically oriented tasks.
>> >
>> > Again, show me. Don't just stick at some vaguely mentioned 'graphically
>> > oriented task' but show me how a CLI is more effective than a GUI in
>>
>> AutoCAD
>
> Ok. And AutoCAD does not have a GUI?
It does have one but it's mostly ignored by expert draftsmen.
>
>> [deletia]
>
> Very convenient. You've snipped the point i made without answering it.
> I'll reinstate it for your convenience.
>
><reinstated after a convenient snip in order to avoid answering a point
> being made>
> Please enlighten the unititiated with your _wonderfull_ wisdom... Are
> CLI's and GUI's mutually exclusive? Can I have _no_ CLI when a GUI is
I don't recall implying anything relating to this actually
(positive or negative). So I don't really get where all of your ranting
and raving is coming from.
[deletia]
Marksmanship isn't necessarily the best way to interact with
even visual data.
--
vi isn't easy to use. |||
/ | \
vi is easy to REPLACE.
Kleuskes & Moos
JEDIDIAH wrote:
> On 2005-11-21, Kleuskes & Moos <kle...@xs4all.nl> wrote:
> >
> > JEDIDIAH wrote:
> >> On 2005-11-21, Kleuskes & Moos <kle...@xs4all.nl> wrote:
> >> >
> >> > JEDIDIAH schreef:
> >> >
> >> >> On 2005-11-21, Kleuskes & Moos <kle...@xs4all.nl> wrote:
> >> >> >
> >> >> > Lee Sau Dan wrote:
> >> >> >> >>>>> "nanci" == nanci <na...@auroville.org.in> writes:
> [deletia]
> >> > command-lines in (say) Photoshop, the GIMP or somesuch application.
> >>
> >> That sort of work leaves room for quite a bit of fudge factoring
> >> that isn't present in other professions.
> >
> > That sort of work is exactly what i'm talking about. And your 'fudge
> > factor" is another persons creative hand.
>
> Imprecision is simply imprecision.
Precision isn't always desirable. Especially when dealing with artwork,
imprecision can lend an extra.
> Tolerating sloppiness is simply making excuses for poor
> execution skills and the inability to make manifest what can be
> conceptualized.
That's just your indictrination speaking.
> >> Nevermind the fact that GIMP
> >> does infact have a command driven interface. It's not interactive but it's
> >> still there.
> >
> > Indeed, it has two (script-fu and python). Which leaves rather a lot of
> > explaining to do why all the GUI elements are rather more prevalent.
> > THE CLI is inteded for scripting, not for extensive image editing.
>
> I suspect it's indoctrination more than anything else.
Nope. It's called the artists hand. Would you accuse (for instance)
Picasso of 'sloppyness'?
> People are constantly screamed at that trying to hit a target
> with a mouse is easer than just typing in a set of coordinates.
For most people doing artwork, typintg in endless series of coordinates
is mindbogglingly dull. It kills the 'spur of the moment' most artwork
depends on. Examine a rembrand, or rather a Van Gogh and you'll find
the 'imprecision' being much of the charm. Even more so fo the
impressionists.
> Any CLI is ultimately a more precise method of communicating
> with the computer. That level of precision is also remarkably easier
> for the novice or klutz to achieve.
Whatever. It's a tool not usable for creating artwork. It simply fails
to deliver.
> > It also leave you to explain why it is better at image editing than the
> > (rather extensive) GUI provided.
>
> I believe I mentioned something called precision.
Precision is boring. It's the imprecision that lends the pezazz to
Renoir and Matisse. Not the precision. Not everyone likes Mondriaan.
> >> >> The CLI still manages to offer sufficiently better control,
> >> >> precision and easy repeatability even in graphically oriented tasks.
> >> >
> >> > Again, show me. Don't just stick at some vaguely mentioned 'graphically
> >> > oriented task' but show me how a CLI is more effective than a GUI in
> >>
> >> AutoCAD
> >
> > Ok. And AutoCAD does not have a GUI?
>
> It does have one but it's mostly ignored by expert draftsmen.
Exacept when selecting stuff. I've been around many of the expert
draftsmen (making PCB's), they used GUI's. Not CLI's.
You're just pulling this stuff out of your arse.
> >> [deletia]
> >
> > Very convenient. You've snipped the point i made without answering it.
> > I'll reinstate it for your convenience.
> >
> ><reinstated after a convenient snip in order to avoid answering a point
> > being made>
> > Please enlighten the unititiated with your _wonderfull_ wisdom... Are
> > CLI's and GUI's mutually exclusive? Can I have _no_ CLI when a GUI is
>
> I don't recall implying anything relating to this actually
> (positive or negative). So I don't really get where all of your ranting
> and raving is coming from.
Pfff... It's not me doing the ranting and raving. It's you who'se
ranting and raving on precision where it's actually unwanted. From you
it's just a cheap excuse for the state of denial you seem to live in.
Grow up!
> [dementia]
>
> Marksmanship isn't necessarily the best way to interact with
> even visual data.
So a GUI is better in some cases. Well, finally. And again, you succeed
in deleting the point from sheer lack of ability to concede you haven't
actually got anything to counter it.
<reinstated after a convenient snip in order to avoid answering a point
being made>
Please enlighten the unititiated with your _wonderfull_ wisdom... Are
CLI's and GUI's mutually exclusive? Can I have _no_ CLI when a GUI is
also present or can a CLI be an element of a GUI like (say) xterm is in
an X-window manager?
> > Both have pro's and con's. It is pointless to say "CLI is better" or
> > "GUI's are better". Both have their advantages and disadvantages. Use
> > the one you're comfortable with and that is good at the task at hand.
> > And GUI's _are_ better at some tasks, CLI's at others.
Care to answer the point, too? Are you saying a CLI is *by definition*
better than a GUI or am i misinterpreting your post? I sure hope it's
the latter.
</reinstated after a convenient snip in order to avoid answering a
point being made>
Kleuskes & Moos
Kleuskes & Moos wrote:
And please excuse the excess typo's. It's not easy writing a post with
a boyfriend breating in (and gently kssing) your neck.
santo
>
> I don't like this story, because it discriminates blind people. >
>
My fault.
The three man were blindfolded, not blind.
When the scarf covering their eyes was removed they realised their
ingnorance ...
Santo
santo
Kleuskes & Moos wrote:
> Lee Sau Dan wrote:
> > >>>>> "nanci" == nanci <na...@auroville.org.in> writes:
> So? All he's claiming is that it's good to _start_ with a GUI, simply
> because it does not have such a steep learning curve and it allows him
> to get a taste of GNU/Linux. He does not say CLI's are forever off
> limits. He'll get there...
>
Thanks for the support.
For a newbie to start with GNU/Linux using right away the CLI is a bit
difficult, unless ( maybe...) he/she comes from a DOS environment,
which is highly unlikely nowadays...
I find strange that in an advocacy group one finds tread like this
one...The co existance and possibility of use of a CLI and GUI is a
plus point and to judge user according to their preference is complete
nonsense.
This discussion belong more to a group like alt.os. linux than this
one.
Santo
Kleuskes & Moos
santo schreef:
> Kleuskes & Moos wrote:
> > Lee Sau Dan wrote:
> > > >>>>> "nanci" == nanci <na...@auroville.org.in> writes:
>
> > So? All he's claiming is that it's good to _start_ with a GUI, simply
> > because it does not have such a steep learning curve and it allows him
> > to get a taste of GNU/Linux. He does not say CLI's are forever off
> > limits. He'll get there...
> >
>
> Thanks for the support.
No thanks needed. Your point was very valid.
> For a newbie to start with GNU/Linux using right away the CLI is a bit
> difficult, unless ( maybe...) he/she comes from a DOS environment,
> which is highly unlikely nowadays...
> I find strange that in an advocacy group one finds tread like this
> one...The co existance and possibility of use of a CLI and GUI is a
> plus point and to judge user according to their preference is complete
> nonsense.
Absolutely.
> This discussion belong more to a group like alt.os. linux than this
> one.
That discussion belongs in the trashcan.
> Santo
Francis Burton
Kleuskes & Moos <kle...@xs4all.nl> wrote:
>For most people doing artwork, typintg in endless series of coordinates
>is mindbogglingly dull. It kills the 'spur of the moment' most artwork
>depends on. Examine a rembrand, or rather a Van Gogh and you'll find
>the 'imprecision' being much of the charm. Even more so fo the
>impressionists.
There are times when entering a musical part with a MIDI keyboard
is better than typing the note durations. Precise timing usually
sounds robotic and soulless, and sometimes that is not what one
wants. Adding randomness can help, but won't recreate the original
nuances of performance.
Mind you, I am prepared to believe that people who crave precision
are happier with soulless music. :-)
Francis
Francis Burton
Kleuskes & Moos <kle...@xs4all.nl> wrote:
>And please excuse the excess typo's. It's not easy writing a post with
>a boyfriend breating in (and gently kssing) your neck.
"Typo's" is not a typo! ;-)
Francis
Kleuskes & Moos
Francis Burton schreef:
> In article <1132615312....@g47g2000cwa.googlegroups.com>,
> Kleuskes & Moos <kle...@xs4all.nl> wrote:
> >For most people doing artwork, typintg in endless series of coordinates
> >is mindbogglingly dull. It kills the 'spur of the moment' most artwork
> >depends on. Examine a rembrand, or rather a Van Gogh and you'll find
> >the 'imprecision' being much of the charm. Even more so fo the
> >impressionists.
>
> There are times when entering a musical part with a MIDI keyboard
> is better than typing the note durations. Precise timing usually
> sounds robotic and soulless, and sometimes that is not what one
> wants. Adding randomness can help, but won't recreate the original
> nuances of performance.
My point exactly. I cannot imagine any blues (for instance) being typed
in
note by note.
> Mind you, I am prepared to believe that people who crave precision
> are happier with soulless music. :-)
Think so. Thanks for the extra example. Good one.
DFS
Revolting. Why do you degenerates always have to announce your degeneracy
to Usenet?
Kleuskes & Moos
DFS wrote:
> Kleuskes & Moos wrote:
> > Kleuskes & Moos wrote:
> >
> > And please excuse the excess typo's. It's not easy writing a post with
> > a boyfriend breating in (and gently kssing) your neck.
>
> Revolting.
What's revolting?
> Why do you degenerates always have to announce your degeneracy
> to Usenet?
You degenerates? What do you mean? Are you gay and cannot stand a
normal heterosexual relationship?
Well, in that case....
Lee Sau Dan
thad01> Lee Sau Dan <dan...@informatik.uni-freiburg.de> wrote:
>> Would you explain to us what you mean by a "concept-based
>> language"?
thad01> My girlfriend is a linguistics major and could probably
thad01> explain the difference better. The gist of it is that a
thad01> phoneme based language will use a comparatively arbitrary
thad01> set of sounds to mean something, while sign language will
thad01> use a visual representation that attempts to (however
thad01> vaguely) actually *look* like the thing you are signing
thad01> about.
Phoneme based languages also use sounds in some "obvious" ways. e.g.
many languages name birds with phonemes that sound like how those
birds sing. English verb "knock", where the first "k" used to be
pronounced in older forms of English, is (was) an attempt to imitate
the knocking sound. It shouldn't be hard to realizes why a bing
"rings", or why a computer mouse is "click".
But since you're so used to interpreting speech sounds as phonemes,
these physical similarities to the concepts being refered to often get
ignored. The left brain is more dominant here than the right brain.
For sign language, other than a few dozen "obvious" signs, the rest
are no less arbitrary than phonemes. This is especially true with
abstract concepts. What is the non-aribtrary sign for "philosophy"?
For "clever"?
Most people have the intuition that sign language uses "obvious" signs
for communication, and is hence primitive. That's because they don't
understand those signs. Their left brain can't tell them what those
signs mean. So, their right brain is more active, and they tend to
believe that those signs are primitive and "obvious". (But if the
signs are really so non-arbitrary, then how come you don't know ASL
without learning it?)
thad01> The sign itself will attempt to encapsulate the meaning it
thad01> is intending to communicate rather than just being a
thad01> random symbol that you need to memorize and repeat.
It is as random as speech sounds. If not, then you should be able to
understand ASL without learning it.
thad01> Thus sign language lends itself to a level of individual
thad01> variation that would cause problems in a spoken language.
thad01> As long as a person understands the underlying concept
thad01> that the sign is emulating, they will likely understand
thad01> the slight variations that someone might make up on the
thad01> fly to shade it with a little more meaning.
As long as a person understands what the speech sounds of language XYZ
means, he's also likely understand the slight accents that someone
else might have, and pick up new slangs that are newly made up.
DFS
My apologies if you're normal.
> Well, in that case....
Lee Sau Dan
>>> You probably think slrn is a great newsreader, too.
>> No. I've been using GNUS and Gnus for over a decade.
DFS> You poor thing.
What's wrong with it? I find it much better than those "GUI" readers.
Much more productive. Much easier to navigate. (Press <SPACE> and it
does the next expected operation most of the time. Just sit back and
read by pressing <SPACE> repeatedly. So easy to use.)
>> How can one compete when another company steps in and leverage
>> their advantage of already being a monopoly in a related
>> market?
DFS> So MS prevented everyone from buying and installing those
DFS> programs?
Sort of.
>>> Lots of competing products sell alongside MS offerings.
>> Yeah. DR-DOS, for instance. And what did MS do to kill
>> DR-DOS?
DFS> Nothing, of course, except compete on features and marketing.
You'd better study the court case on DR-DOS.
>> DR-DOS didn't die because it's inferior, but because of MS's
>> immoral means of eliminating superior competitors.
DFS> DR-DOS is still around.
But does Win 3.1 like to run on top of it?
Lee Sau Dan
DFS> You're deluded. They killed themselves off by not being
DFS> competitive. That's it.
>> How can one compete when another company steps in and leverage
>> their advantage of already being a monopoly in a related
>> market?
Tom> The same way that Firefox is competing with IE, by building a
Tom> better product.
i.e. "selling" it at a $0 price tag. That's the only way to "compete"
with a monopoly.
Lee Sau Dan
>> Yeah. There are people in this world who prefer to use
>> something pretty rather than something that works. But not me.
>> I want to get work done, not to get work pretty.
DFS> Is that GNUs you're using this one
DFS> http://my.gnus.org/node/316 with all the icons at the top
DFS> that you can click with your mouse?
No. I've turned off all those menubars and toolbars in Emacs, because
they're useless to me and they occupy too much of the screen real
estate. Without them, I can display 4 more lines of text, which is a
significant gain.
Click with mouse? Why do I need to reach the mouse for reading and
writing Usenet news? It's so much faster and easier to simply press
<SPACE> repeated to navigate through the articles in a whole
newsgroup, than having to aim the mouse here and there and 'shoot'
around.