Slashdot Mirror
The Command Line - Best Newbie Interface?
An anonymous reader writes "This essay describes the surprising results of a brief trial with a group of new computer users about the relative ease of the command line interface versus the GUIs now omnipresent in computer interfaces. It comes from practical experience I have of teaching computing to complete beginners or newbies as computer power-users often term them."
I'd wager that computer literacy amongst people who've tried Linux would be twice what it is today if when you typed help foobar bash would perform a man foobar if 'foobar' wasn't a builtin command. And it'd probably be double that if you incorporated some kind of search facility too. Type in help disk space and get a hit on the df command, for instance.
And isn't it nice that Mac OS X now gives you the best of both worlds :)
Does anyone remember 4Dos? Between that and Qmodem, I learned a whole lot about computers.
Life is the leading cause of death in America.
Wow, what a well-researched and interesting article. Will we be seeing 'newbie conversation' mode with the limited commandset (as used in the article) splashing across the desktop soon? Unlikely, I think, but this article puts the whole thing in a new dimension for me.
I notice the author is multitalented -- he's also the genius behind Desktop Manager, a virtual desktops manager for Mac. Wow. If only I was single...
I find it amazing how many computer "experts" are dead in the water when the mouse doesn't work or the GUI doesn't come up as expected.
Too bad only the "old-timers" seem to appreciate the power of the keyboard.
To Terminate, or not to Terminate, that's the question - SCSIROB
It seems to me that if you start someone on a command line versus starting them on a GUI they learn a little slower but acquire a deeper understanding of the computer.
point-and-click and drag-and-drop don't encourage any actual understanding of ways in which a computer interprets commands.
lysergically yours
Apprentice: "What is that, Master?"
Master: "It's a command line. The instrument of a Unix Programmer. Not as random or clumsy as a GUI. An elegant interface for a more civilized age. Before the dark times. Before...Microsoft!"
"Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it." -- Linus Torvalds
I believe it is because the command line is very simple and compact, single-threaded and simple to understand.
Modern GUIs have many things going on at once, which can confuse people who have no idea what is going on. Windows pop up, there are icons to deal with, they have to search through endless menus to find what they want.
The command line however has simple command to remember instead of complicated graphical procedures, and the status of the command line really never changes. If you mess something up, you are still back where you started, but in the GUI, a user could close a window to open another one which obviously confused people who don't understand what they mean.
But you think a command line would make using a digicam easier? A microwave? A thermostat?
The computer as a non-specific device is a fundamentally flawed (though useful) contraption. The command line, GUI, and other UI creations are all hacks to help users get around the problem of genericity of the machine.
As computers get more powerful and more 'intelligent', computer user interfaces like these will wither away and something more straightforward like controls for a camera, microwave, or thermostat become the primary UI of the computer. This means that innovations in computer operating system design must be made so that the OS can guess what the user wants to do and present an appropriate, simple interface.
I really look forward to the day when the concept of the PC disappears.
I have been pwned because my
I'd bet that the CLI is probably easier to learn for a complete newbie to computers in general, but a GUI probably easier to learn for anyone new to a given application.
More intelligence in either interface would certainly be a Good Thing, however.
In my experience, the command line is more consistent, especially if you are telling someone to do something. Once you get into it, it just a matter of saying "press A, then press ., then...."
With a GUI, there is a lot of hunting and squinting and guessing: basically, the stuff is never in the same place and never looks the same from one machine to the next.
Don't blame Durga. I voted for Centauri.
When she worked she worked with DOS based programs. I guess now these are so much easier to understand because you actually "talk" to the computer albeit through a keyboard and with a very limited command set. Maybe the mouse driven GUI is a bad inbetween step from the keyboard-only days to a time when computers understand conversation.
One of the things I really miss when I sit behind a windows computer is a bash shell, tab completion, gcc, vi... and you usually arent allowed to install cygwin on people's systems :)
Of those to whom much is given, much is required.
...as part of its Win95 hype machine. Microsoft likes to point out that pointy-clicky is sooo much easier than the "arcane" and "cryptic" command prompt, and tried as hard as possible to hide it. Microsoft certainly didn't try to improve its command prompt much, and even in modern version of Windows it still retains a lot of its retardedness inherited from the early days of DOS.
The question is, why? Sure, newbies hate it, but it's really useful to have a powerful command prompt, so it wouldn't hurt to include it. Even Macs have them now. Windows would be much more tolerable if it had a Unix-style command shell out of the box. Yet Microsoft feels the command prompt should die and it seems (at least from my point of view) that it's included only grudgingly in the OS.
"Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it." -- Linus Torvalds
My dad is all of 64 yrs. When he started on computers a year ago - he started with Linux (the man does not know the "windows-way". One of his early observations was that it was easier for him to learn the command line and keyboard shortcuts. He could list these on a peice of paper and run thro' whenever he ran into trouble/forgot. Of course now he is on KDE 3.2 and seems fine with the GUI...
You can configure the shell to work with more confort with the case sensivity issues. Gentoo comes with tcsh preconfigured to behave like that. IMHO i don't find case-sensitiveness an annoying issue, rapid fingers and the blessed tab-autocomplete do the work easy for me.
Had a Fujitsu laptop, like a P133, in 1998(?) and I loaded Redhat 6.0 and could NOT get the Xserver to work. I spent about 6 mos (now and again) at the command line putzing around on tryng to get the Xserver working. In that time I learned more about Linux AND Windows than I ever knew even existed. Suddenly alot of Windows oddities made sense... in the sense that I got what they were _trying_ to do. And it left me with a hollow feeling whenever I used Command... Why doesn't Windows have...
This
It may be more logical,
but it's more memory intensive - visuals are easier to remember. Well, I find it easier to remember visuals rather than words.
A blog I run for the wealth
From the word go I had them "cat"-ing, "sort"-ing, "grep"-ing and "cut"-ing files, showed them how to combine commands on the command line and how to turn them into shell-scripts.
The guys I taught were, like me, support engineers on Linux-based telephony products and were keen on learning how to strip relevant info from log & text files.
Within a couple of weeks they were churning out pretty good shell-scripts that were extracting info from files all across the system, "gzip"-ing them up and mailing them off automatically in cron jobs. Many of the commands they used in the scripts I'd never even mentioned in the training but had showed them about man pages and "find"-ing files on the system.
The moral behind the story is that if you give people enough of the basics, they'll soon go find problems they need to solve and work out their own ways of doing it.
Gentoo Linux - another day, another USE flag.
Now that's newbie friendly.
READY.
#
All I can say is that I am an old school MS-DOS guy, and it constantly drives me nuts when I see people using Windows Explorer to find a file, select it, go to the menubar, select Edit, Copy, and then navigate to a different directory in Windows Explorer, menubar, Edit, Paste.
Maybe it's because I type 80wpm (at least when doing sysadmin work in MS-DOS I do), but things I do in MS-DOS seem to take 50-75% less time than to do similar tasks using a mouse & windows only.
Check out the best P2P sharing website: MEDIACHEST.COM
Name Called By:
-Noob -Ghost Recon/Console Gamers
-Newp -RPGers
-Nub -CSers
-Nubby -''
-Nubzy -''
-Pub -''
-Pubber -''
-CS -Gamer
This is not true on OS X. The default filesystem is case independent.
Configure the DNS server address staticly:
/etc/resolv.conf
/etc/ directory. If any of these configs get corrupted you can edit them manually to fix them, or copy originals from packages, or copy them from another source and edi them to fit your needs.
In windows:
Goto start --> start --> control panel --> networking --> select the correct device --> options (or whatever I don't f-ing remember) --> select TCP/IP --> select options --> hit the DNS tab --> Select "I want to specify dns addresses bullet --> type in ip address in the boxes.
Networking specifications are spread throught 100's of dialogs and wizards. Some can set conflicting settings, some can override the settings of others. Some are grayed out to prevent these conflicts and you need to figure out why. All system wide configs are stored in the same place as program specific configs and user configs. If any program or installer corrupts this one binary file it will render the entire OS unusable.
In Linux (if the dns server is 192.168.1.1:
echo "nameserver 192.168.1.1" >>
Remember resolv.conf because DNS is to resolv the URL names into ip addresses. System wide configs are stored in plain text files in
I did some teaching of command line for non-English-speaking students and the biggest obstacle was the language barrier. They couldn't remember the command and they didn't understand the output of the command. Even if they knew some English, there were always some technical terms they couldn't understand and they felt intimidated. This way they were much more efficient in a localized GUI.
Save the bandwidth. Don't use sigs!
from my web log, I think it's appropriate and strangely enough, quasi-religious...
We all strive to be big monolithic programs, with fancy buttons, big memory footprints, environments where people, if they want to do anything, must go through us. We strive to be pre-eminent on the desktop, world stage. We crave fame. Look at me we say. Look how important I have become. I am an Office Suite, hear me roar. Look how much I can do. If you want to do any work, you must come through me.
[snip]
We must teach our brethren the ways of the Unix shell, for if we don't we will forever be trapped handcuffed in that big shiny plastic bubble of modern life, where we see but we can't interact. We must go back, back to the beginning and learn the first lessons.
Toddlers are the stormtroopers of the Lord of Entropy.
That said, it would be rather helpful if command-line tools would actually communicate more in plain English. Most of the commands and responses were meant to save keystrokes and be brief, and were written by geeks for geeks (so to speak).
Why write "Segmentation fault: core dumped", rather than, say, "Sorry, this program has unexpectedly quit because of a programming error"? In other words, worry less about technical accuracy in error messages and concentrate more on making the computer and OS more understandable to non-technical people.
I'm not saying bash or the other shells should be re-written that way, but it would be nice if a more newbie-friendly CLI was around.
Cheers,
Ethelred
Everyone wants to be Ethelred. Even I want to be Ethelred.
Before, I was concentrating on the syntax of control structures. Like having:Rather than: I could think about adding in a better help system as well. I've got a few months left of design work.
And I need to fix the lexer, too. In a recent presentation, I found a rather embarrassing bug. The concatenation operator in my shell is the same as perl's, the full stop, or period, ".". Cleverly, the shell can also treat numbers as strings and strings as numbers.
Unfortunately, it was all a bit too clever.
The expression 3.0 + 2.0 was parsed as (("3" . "0") + 2) . "0"). Giving 320. Oops!
But given a little more work, maybe I could get it to solve some of the problems mentioned in the article above. Could be an interesting thing to do.
If I was to teach someone Linux, I would definitely teach the command line first. When there are just a few programs you use, it's easier to memorize their commands or keyboard shortcuts than it is to hunt through a menu each time. E.G., if all you want to do is play Pac-Man, you can either a) Hunt through the menus to launch gRustibus, wait for it to load, scroll through the gamelist until you find the right version of Pac-Man, and double-click the name, or b) type "xmame pacman" at the command promt.
bash$> for tif in `ls *.tif` ; do convert $tif -border 50 -bordercolor \#FFFFFF -quality 100 -scale 25% -resolution 96 `cat $tif | cut -f1 -d"."`.jpg ; done
Put THAT in your GUI.
I want to delete my account but Slashdot doesn't allow it.
The pity is that GUI usability peaked sometime in the late eighties and has declined since then, as the rise of "computer literacy" has created an expectation that users will master complex UI's, and the rise in computing power has removed any barriers to marketing-driven featuritis.
The most telling point was the discussion of "discoverability." "Discoverable: The interface must, from first switch on, provide a clear direction for a new user to go. At each stage it should encourage experimentation while providing adequate notice of important or key features."
In the 1980s, GUIs were intentionally designed to facilitate discoverability were far more "discoverable" than CLIs of the day. They were also intended to be forgiving. The user was supposed to feel empowered to try things, confident that there was always an "undo" to bring them back. On the Mac in the 1980s, "Undo" was far more prevalent and worked far more consistently than in today's software, in which many operations commit you to something whose effects you may not understand.
As for "dialog," UI designers understood that well. Why do you suppose that what are now called "screens" were once called "dialog boxes?"
What the article is really saying is not that CLIs are better than GUIs, but that a) modern UIs are not catering to the needs of the average user, and that b) modern UIs have gotten so badly designed, cluttered, and complex that they have become less usable to beginners than CLIsbecause GUIs have deteriorated, while CLIs have benefitted from benign neglect.
"How to Do Nothing," kids activities, back in print!
I see a sysadmin speaking. Nobody else in their right mind would dare to call the command line a user interface.
Build it, and they will come^Hplain.
This is certainly a very interesting idea, and has good points to it. I would hazard, however, that the CLI is most definitely not the way to go to get new users up and running with computers. The author is almost there in his article, but doesn't seem to make the leap...
Using the example that the author used, he says Tilly multitasks, but doesn't do more than one thing at once. When she wants to leave something for later, she puts it to one side. This is an almost exact description of minimizing windows. It isn't suspending programs, or moving them into the background, like UNIX. It's just putting what you're doing out of the way for the moment.
Tilly goes to the grocers and tells him what she wants. Why not point at what you want? I want my mail, click the big envelope. I want to type something, click the Word icon.
It's arguable that some of the easiest programs that run in a terminal are those that are like GUIs, just without the mouse. Pine is a perfect example. It has labelled buttons at the bottom, except you interact with them using your keyboard instead.
GUIs are still the best way of getting general users interacting with computers, it's just certain elements of GUI design that scares them witless. Working on a helpdesk for my University residential network, I reguarly hear what could almost be called fear in a voice when a dialog box or something pops up that I didn't expect, and warn the user was going to happen. GUI design is very imperitive. Boxes appear saying "DEAL WITH ME NOW" and giving themselves the utmost importance. This is what scares people. They think that because something took the time to alarm them in such a massive way, something amazingly bad must be happening. These windows often pop-up from applications that aren't being worked with. By preventing these, everyone would be a lot happier. The Mozilla new mail notification is an absolutely excellent way of telling the user something is happening, it pops up in the corner, says there's some mail, and disappears. It doesn't ding. It doesn't grab focus. It doesn't appear in the middle. It just gives you a quiet hint.
GUIs are also far too ready to boot up programs of their own accord. When users get notifications from something they didn't run explicitly, they get the fear. CLI doesn't do that, it only shows you output from things you've done.
The author says that users are scared to click buttons, in case of something going wrong. But they feel that a CLI can't do any harm. Users *do* want to point and click their way around buttons, and GUIs do complain of something wrong in essentially the same way as CLIs. Maybe it's because they have no visual feedback when they type sudo rm -rf / ? I think it's just a residual fear from the constant shouting that current GUIs do.
GUIs are currently too noisy, and the essential quietness are what these users are responding to. I would hazard that as soon as the users want to do something more difficult (that would need a pipe), they'll be desparate for a GUI interface instead.
Having done everything from assembly language programing for embedded systems to UNIX CLI (Command Line Interface) to Macintosh, I find that CLI is distinctly inferior to GUI (Graphical User Interface) for all but a few tasks. I challenge CLI users to do any form of word processing from a shell prompt. Even the most hard-core of them will resort to vi or emacs which use a primitive pseudo-GUI (and yes you can create and I have used a pure CLI text editor, but it is extremely painful). I don't want to even think about trying to replicate Photoshop with a CLI.
CLI = Dialog? The article mentions the notion of CLI as a dialog. But this is a misleading metaphor because so many CLI commands create invisible effects. You tell the computer to do something and all that returns (in most cases) is a command prompt. At best its like teaching someone to to do a job while speaking through a door. You give a command to do something (e.g., move a file from directory to another) and then you have to give a command to see the results (ls).
Discoverability: GUIs also provides visibility on to the set of available commands and functions. By browsing through the menus (which are usually nicely organized), you can learn the functions of an application. In contrast, a CLI-only machines provides no obvious way to learn about commands that you did not know existed -- at best you can access an alphabet soup of cryptic vowelless cmmnd names and then access the man page on each command. Therefore, GUI applications tend to be self-documenting, CLI commands require that you first know of the existence of the command and then you must read the man pages (grepping the man pages sometimes works if you know the jargon for what you are looking for).
Undo command: Most well-behaved GUI applications further support user learning via experimentation by having an undo command (and a revert command). CLIs tend to be irrevocable with no possibility for undoing inadvertent damage by a novice user (short of reloading the entire machine from a backup). Its no wonder *nix people get upset at the thought of novices on computers. But this lack of an "undo" is the fault of *nix CLI (it could easily be remedied with automatic file version tracking and journalling).
GUI is the superset of a CLI: Some people complain that GUIs take too long and I agree with them. CLI does offer a faster interface for experienced users. Yet a good GUI offers keyboard shortcuts that let experienced users invoke commands from the keyboard. While it is easy to have a keyboard shortcut available and shown in a mouse-oriented graphical GUI menu, it is hard to have a graphical menu shortcut in a keyboard-oriented CLI. With a GUI that shows the shortcuts in the menus, the user can learn shortcuts as they use the machine. Thus, I would argue, a GUI is the superset of a CLI.
Direct Manipulation: And CLI's inferiority is not just a matter of the learning curve (although that is a big disadvantage of CLI). For some tasks, a direct-manipulation WYSIWYG GUI is vastly superior. I challenge *nix people to build a CLI-only version of Photoshop. This is more that a matter of ease-of-use it is a matter of creating a coordinated interface between a person and a machine. While CLI forces the user to preform a completely defined action (e.g., type in a command that turns pixel 100,103 in file x to RGB value 128,128,200), a GUI lets the user try something (select a paint brush tool from the toolbox, test it somewhere, undo, use the tool somewhere else, etc.)
Control Panels vs. Config Files: The article claims that modern GUI-driven OS have too many control panels ("To master modern GUIs, one must recall the operation, layout and relation to each other of hundreds, if not thousands, of such panels." Yet how is this same functionality attained in a CLI machine? Config files are the absolute worst because they offer no form of input checking or potential for embedded help. Most config f
Two wrongs don't make a right, but three lefts do.
By what does it mean "Best for Newbies?" The article doesn't even try to compare the user performance on a CLI to a GUI interface. The author made many subjective comments about what the users may think. A more objective experiment should be done with a control group that tries to accomplish the same thing using GUI. You then measure the task performance (like how long does it take to write an email or type a letter on either interface). Companies such as Microsoft and Apple spent a lot of money on research like this.
User interface is a field of active research and study, using actual performance comparisons on actual users, not on people reading slashdot. I think the general Linux community needs to recognize that it's not doing as much as it should. As Linux is moving to the desktop, this is becoming more and more important.
My computer experience started with ms-dos. I learned most of the commands while trying to scratch an itch (mostly trying to play games). I learned how to edit config.sys and autoexec.bat and by that the computer internal basics. It was simple and I learned many stuff.
Now newbies start mostly with windows. In order to learn how to use a computer you have to know how a computer works in general, and how a computer will respond to an action you take. Microsoft tried hard so this stuff is invisible to the user. In order to play a game you just have to put the cd in and "next" your way through the installation process. If users don't gain experience from simple things as that how can someone expect from newbies to learn how to use a computer?
I understand your frustration, but also disagree with it. Allow me to explain.
The concept you're bringing up is black boxing: a simple (or standardized) user-interface that hides a complex system.
The pros of black-boxing are obvious: black boxing makes it possible for many people to operate complex equipment (think cars, phones, computers). There is also a psychological factor at play here: as many people seem to suffer from self-learned helplessness when dealing with technology, black-boxing (e.g. think nice-and shiny i-POD, or automatic-transmission lady-car) helps them to overcome their physological aversion and acutally use the device.
Now, as already stated by another user, the main con of black-boxing is what happens when something goes wrong: black-boxing provides a very poor way of dealing with failure-conditions!. There is also another con, which is public perception: black-boxing makes people believe that the equipment they are operating is simple, while in reality it's very complex. But because they reason from their internal "simple make-believe model', they can make mistakes that they wouldn't have made, had they known a bit more about the equipment.
To provide an example: Here in Europe, most cars are manual transmission (typically 5 forward and 1 reverse). When driving 80 kph in a flat country like holland, it really doesn't matter that much whether you drive in 3rd gear of 5th gear. However, when some Dutch people drive through Switzerland during the summer holidays (with a big trailer behind the car), they persist in driving in 5th gear up-hill, their argument being: "Hey, don't worry man, the car maintains speed uphill, so what's the problem". Of course, had they known a bit more about how an engine works, they would have switched back to 4th (or even 3rd) gears, to allow the engine to run at a higher specific torque, and to allow the cooling fluids to be pumped around more quickly to cool the engine better. Our black-boxing people usually end up overheating their engine (and blocking traffic and creating big jams in the Alps, grumble! ;) You see: it pays to know at least a bit about what's under the black cover of your black box!
In the same way, your shiny XP thingy makes your computer seem a simple device. But of course, it is still a really complex device. We've all seen people do stupid things because they persisted in acting according to how they believed the computer works (their simple model), rather than basing their actions on how the computer actually works. Knowing a bit about the latter, however small, enables you to do better in times of failure, but also in general.
On a personal account: I learned C after I learning assembly. I experienced this as a big bonus, because after using asm, you know what pointers actually are and how they work. I've seen people program Java and doing stupid memory allocation things, because they had no clue about what happens when you do "new bla" or "delete bla".
To conclude: black boxing is ok, but you need to keep in mind that you are still operating a complex device!
Support a Europe-related section on Slashdot!
The thing that this theory misses is the value of learning intuitively for most people. With CLI you have to be taught or teach yourself through research how to perform each task. With a GUI a few basic principles and you can learn as you go by reading on screen instructions in a context sensitive environment. Does CLI promote deeper learing...absolutely. Is it the best interface for learning quickly and achieving a minimum standard of literacy...nope.
Autocad is probably one of the most complex applications that I know. But the one thing that they've done right over the years is preserve a command line that gives you total functionality, along with a history to show you what you did. You can click and drag your way through a design, or you can type it in at the command line and then selectively move items with the mouse *if* you want.
It also reinforces your understanding of the commands to the point where the dialog boxes are merely pretty wrappers and you know exactly what you're trying to do, instead of getting wrapped up in the position and naming of items to click.
The command line also reinforces concepts and a deeper understanding of what the program is designed to accomplish (with Autocad, designing objects). Try as the designers might, you can always get into an argument that this menu item belonged here, and this dialog box doesn't make sense, etc. etc. With a command line in the program, I simply ignore the arguments and get work done.
Well, I'm an "old timer" who does _not_ appreciate the command line.
By "old timer" meaning, admittedly, not 60 years old and having started on punched cards and electronic tubes.
I did, however, learn programming in hex, not even assembly, on a ZX-80 with 1K RAM. In 1K you didn't even have space to run an assembler. I had a big old paper notebook with 1 page per command and a matrix of the registers involved. E.g., this is the page for "ADD", take the column for "A" and the row for "B", and there you have the hex code for "ADD A, B".
I continued through such mis-haps as editing source files on a CP/M machine with a hex-based disk editor, because the PHB forgot to also give us a text editor. Sad, but true.
You know what? I _don't_ miss those days.
The command line is powerful and all, as long as you already know _exactly_ what you're doing. It is a pain in the donkey when you don't.
The time and effort to get past that learning curve is not fun, and not what Joe Average wants. Heck, it's not what _I_ want.
I do _not_ find it fun to spend hours digging through obsolete, incomplete man pages just to find out that I need to type some obscure command like "obscureProgram.sh -XFGXRmnq -i filename1 -o filename2 -c OBSCURE_COMMAND_CODE -p some_obscure_regexp -f unix-style-font-name" just to get something done. Bonus points if it expects me to already be in some directory, and some obscure configs to already be set right. More bonus points if it doesn't even do the whole job, but expects me to pipe it through other obscure programs. Double bonus if it outputs some cryptic error messages like "1962 Short School Bus", that don't even tell me what the **** went wrong there.
Gimme a break. My time is too valuable to spend it on that kind of crap.
Give me a GUI which has input fields for the stuff I need to enter. If it's a file name, give me a good file selector dialog, don't expect me to manually list directores 20 times to find it. If I'm supposed to enter options, give me checkboxes, radio buttons, or drop down combos. And, ffs, give me an up to date help for it. And clear, humanly understandable error codes.
And you know what? I'm surprised how much energy goes into defending the sacred right to produce crap code and piss-poor interfaces.
Here's an idea: if half the time that went into whining about how the 60's command line interfaces are better for the user, went instead into throwing together a simple user-friendly TK or ncurses or whatever GUI, we'd all be far better off than we are today.
And let me get back to the part where I've said "The command line is powerful and all, as long as you already know _exactly_ what you're doing. It is a pain in the donkey when you don't."
The problem there is that to get to know exactly what options to type there, you have to invest ludicrious ammounts of time into that. Which for most people isn't justified. If you'll configure printing on your home network maybe 4 times in your whole life, consider the following two situations:
1. spending 4 hours to learn how to do that with CUPS and only with command line tools. But then you can do that in 30 seconds flat each time.
2. spending 5 minutes each time doing the same in Windows, through the GUI
Believe it or not, solution 1 is _not_ an improvement. On the whole, the l33t Unix command line way took 4 hours from your life, while the point-and-drool Windows way took a total of 20 minutes. The winner is... the GUI.
Yearly millions of hours go into just learning to use some crap software. It isn't learning some l33t skillz, it isn't "getting a clue", it's just _wasted_. It's time when you're _not_ doing what you needed to do in the first place. Time where, like in the example above, instead of already having your file printed on that networked printer, you're still searching through obsolete man pages and trying stuff that fails for no obvious reason.
A polar bear is a cartesian bear after a coordinate transform.
In my experience there are two kinds of novice computer users (newbies, if you will), those you don't "get it" and those that do. Those that "do get it" will quickly understand that the "little blue 'e'" is not "THE INTERNET" and that they are free to change thier start page for that application (or choose another one altogether). The author choose a bunch of (his words) "the more advanced members" and gave them a little instruction on the command line, to kill a little time, while he tried to catch up the dense. At best, it is just a good way to interest the "soon to become power users", while the rest of the class catches up.
I use the command line frequently, and am very comfortable telneting (and SSH) to Solaris and Linux servers, but I don't think that most newbies will benifit from the extensive command line instruction, they would need to be truely "productive" on a system.
The grass is only greener, if you don't take care of your own lawn.
Look, if the car starts bouncing, I know I have a flat tire. If the engine is having problems, a red light on my dashboard tells me to take the car in. When the car struggled to shift gears, I knew it was a transmission problem. The CAR informs me of what is needed and I take it to the specialist. The basic maintenance schedule is given to you when you buy your car, there are no surprises.
Regarding a license... you need a license because with an automobile because the misuse of an automobile can endanger others.
Look, I'm a computer engineer by training, know my way around Unix, know my way around NT (MCSE, CCA from old career), and know my way around a CLI. Guess what, when I want to put together a business model, I want a graphical spreadsheet that is out of my way. Do I know ALL the Excel functions? No, but I know the ones I use regularly, and the help system gets me through the rest.
I have no desire to memorize arcane commands, I want to build the business model. Will I learn arcane commands to speed things up? Sure, but on MY schedule, NOT yours. I buy the machine to let me get my work done, and I pay the premium for a laptop to do so on the road, and I pay the (admitted small these days) Apple premium to have wireless support that is amazing and to be able to have my Unix applications on the road. These are all my choices.
Guess what, I don't pay Open Source programmers, so they don't have to listen to me. However, don't complain that I don't have an open source desktop when you put out bizarre GUIs that interfere with my workflow.
My Mac stays out of my way and lets me do work, MUCH faster than Windows or Linux would let me. In the end, that keeps Linux a step away from "global domination" or whatever the goal of the week is.
My computer should work for me, not the other way around. Sure, I had to demonstrate an understanding of traffic laws to get on the road. But guess what, EVERY car I drive is nearly identical, and the controls don't change. That consistent UI makes cars a success.
Windows has problems, no question. But it is "good enough" for most, and it is pretty cheap.
For a single-purpose machine, Linux is fine, I can train my people on 1-2 applications... If GNUStep was further along, or Qt didn't blow as a RAD tool, then our dedicated personnel would be on Linux machines and not eMacs. However, if you think that Linux is good enough for a business power user, you're sadly mistaken.
The integration of the Office Suite has been AMAZING for a few years, and the combination of Word, Excel, and Powerpoint is TERRIFIC for business users. Until GNU can mimick that power (NOT mimick the widgets, but the power and integration) then it is NOT a viable desktop system for the modern business power user.
I'm not sure why nobody's picked up on this yet, probably the horrible must-work-in-a-ssh mentality. Sure, people who can ssh in can use man -k. But for the rest of us, typing in an xterm or similar, the original Mac programming environment - mpw - had the best method by far of helping someone on the command line.
... and a dialog box popped up with full-on gui goodness to let you enter the command. While you were chaning the options, it wrote and rewrote the exact command line you had to use in a pane at the bottom of the window. Genius.
It was called Commando, and if you couldn't remember a command's options, you could type it, press apple-enter (IIRC)
It turns out that companies like Sun and IBM have researched this before. The results they came up with is that the new users found their way around and accomplished tasks faster with a GUI interface, but were more likely forget by the next time how to do it. With command line, it took a while to learn it, but then the retention rate was higher. The research, I believe, the systems used were running Solaris/AIX respectively with their X Windows vs. the command like on the same systems.
In the Beginning was the Command Line, by Neal Stephenson. It's available in text form from http://cryptonomicon.com/beginning.html.
I think GUIs and the CLI both have there place. However, undoubtably, the CLI is simpler, faster, and more powerful in certain circumstances.
Just recently, a colleague (running Windows XP) and I (running Linux) took our laptops to a computer lab providing IP addresses via DHCP. My colleague, after spending literally 20 minutes fighting with his GUI receiving ambiguous error messages and having the OS seemingly do the exact opposite of what his intentions were, finally gave up. Some setting, hidden in XP, was refusing to let him use DHCP and insisted on trying to connect to his usual ISP.
On the contrary, after 3 seconds editing a config file, I confidently typed "/etc/rc.d/network start" and, as expected, had instant network access.
I think this is a simple example of the many (not all) areas in which the CLI is simply superior.
Simple little script to figure out what a command does. Works on most of them. Keeps me from having to do a "man [command]" just to see what it does. It's just something I put together in a minute, so forgive me if you don't think it's done the right way - it works quite well for me. Feel free to use it if you like.
; ;
#!/bin/bash
test=$1
if [ "$test" = "" ]
then
echo " desc - Short for describe. Display a one line description of what a command does."
echo " Usage example:"
echo " desc ls"
else
if [ "$test" = "desc" ]
then
echo " desc - Display a one line description of what a command does."
else
man $test | grep "$test - "
fi
fi
Find a job you like and you will never work a day in your life.
Ever tried telling people on phone how to do a task in Windows?
"Click Edit, Options, and... err, wait, yeah, Page settings, Margins..." (5 minutes later, or 10 minutes if you don't have the same program in front of you) "Wha? I told you to click on OK, not Cancel!" (10 minutes fly by...) "So it doesn't work? What do you mean there's a setting like that? Why didn't you say so? I'm deaf and stupid. Sorry."
As opposed to:
"Just type '/sbin/ifconfig ppp0'. ...Wha? that's 'slash-s-b-i-n-slash...'" and a moment later "So it isn't even connected. Right. Try typing 'pon'."
The GUIs may be good to work with, but CLI is easier to explain. Especially if you're used to doing GUI things in one way and others do it the other way.
GUI is like a religion - you "learn" it, and only you can explain what it means to you. CLI is like science - you learn it, you can explain it, and it means the same thing to everyone - except people who argue about "useless uses of cat(1)" and proper order of parameters, and whether to use sed(1) or perl(1), of course.
And now I need the freaking coffee already.
Wow, recycled FUD from 1984. We've already had this battle. GUIs won, get over it. New user like to see what they are doing. Clicking is more intuitive than typing. CLI has it's place and use, but don't try and tell me Grandma is going to feel better using CLI over GUI 2 weeks or 2 years down the road. It just ain't true.
RPM is supposed to be easy to use... but the dang man page is so long... Here's just the SYNOPSIS section at the beginning:
...
...
...
...
...
...
...
...
NAME
rpm - RPM Package Manager
SYNOPSIS
QUERYING AND VERIFYING PACKAGES:
rpm {-q|--query} [select-options] [query-options]
rpm {-V|--verify} [select-options] [verify-options]
rpm --import PUBKEY
rpm {-K|--checksig} [--nosignature] [--nodigest]
PACKAGE_FILE
INSTALLING, UPGRADING, AND REMOVING PACKAGES:
rpm {-i|--install} [install-options] PACKAGE_FILE
rpm {-U|--upgrade} [install-options] PACKAGE_FILE
rpm {-F|--freshen} [install-options] PACKAGE_FILE
rpm {-e|--erase} [--allmatches] [--nodeps] [--noscripts]
[--notriggers] [--repackage] [--test] PACKAGE_NAME
MISCELLANEOUS:
rpm {--initdb|--rebuilddb}
rpm {--addsign|--resign} PACKAGE_FILE
rpm {--querytags|--showrc}
rpm {--setperms|--setugids} PACKAGE_NAME
select-options
[PACKAGE_NAME] [-a,--all] [-f,--file FILE]
[-g,--group GROUP] {-p,--package PACKAGE_FILE]
[--fileid MD5] [--hdrid SHA1] [--pkgid MD5] [--tid TID]
[--querybynumber HDRNUM] [--triggeredby PACKAGE_NAME]
[--whatprovides CAPABILITY] [--whatrequires CAPABILITY]
query-options
[--changelog] [-c,--configfiles] [-d,--docfiles] [--dump]
[--filesbypkg] [-i,--info] [--last] [-l,--list]
[--provides] [--qf,--queryformat QUERYFMT]
[-R,--requires] [--scripts] [-s,--state]
[--triggers,--triggerscripts]
verify-options
[--nodeps] [--nofiles] [--noscripts]
[--nodigest] [--nosignature]
[--nolinkto] [--nomd5] [--nosize] [--nouser]
[--nogroup] [--nomtime] [--nomode] [--nordev]
install-options
[--aid] [--allfiles] [--badreloc] [--excludepath OLDPATH]
[--excludedocs] [--force] [-h,--hash]
[--ignoresize] [--ignorearch] [--ignoreos]
[--includedocs] [--justdb] [--nodeps]
[--nodigest] [--nosignature] [--nosuggest]
[--noorder] [--noscripts] [--notriggers]
[--oldpackage] [--percent] [--prefix NEWPATH]
[--relocate OLDPATH=NEWPATH]
[--repackage] [--replacefiles] [--replacepkgs]
[--test]
Each of the above options is explained in detail, but there are no FAQ-style examples. It's no wonder the distributions are putting layers on top of rpm (urpmi, yum, etc). I like yum, and largely because the man page is short and to the point! It only takes a few seconds to figure out what I need to do.
bp
I actually think it's a good thing that unix-ish commands have wierd names.
For a beginner learning unix, there's a conceptual hurdle they have to jump: that commands are not "commands" at all, but specific named programs which can be used as tools.
Lack this understanding, and you're confused and trying to second-guess a nonexistent "designer". Gain it, and you can start to ask the right questions. Not "how do I get help" but "what program displays the help documentation", for example. Or, if one program isn't adequate for a task, might there be another which could do it better?
In that regard it actually helps that unix programs have idiosyncratic names. "grep" is grep, it's not some generic "search", and it's probably not the only tool on the system useful for "searching".
Although I'm only 21, I grew up in a DOS, and, later, a Linux environment. I still prefer vi and vim to VS.net. I was using a Windows program a couple days ago, and it wanted the folder to rip music to, I went to type in the folder (q:\.......\music), and it wouldn't let me. When I realized that I would be forced to use a GUI folder selector for each of the three paths rather than copying and pasting, my heart sank: I realized just how horrible the world has gotten when even programmers expect me to use GUI for everything. My point is, a lot of us grew up on command line, and we turned out great. A lot of people grew up on windows xp/msn messenger, and I can't help but look down on them. When I say, "Your 40gb drive is full of spyware and installed programs/partially uninstalled programs/whatnot, it's time to format" they say, "huh?" because they aren't famalier with core computer concepts. When I was forced to learn what IRQ and DMA meant, and I had to use mscdex when I was 10, I ended up better for it. I understand how the machine works, and I am much happier for it.
http://www.skullsecurity.org/blog/
I think that is a very good idea and for that reason after reading your comment I decided to write such a program according to your specification.
Just remember who has just made Linux four times what it was today: me, Pan T. Hose, PhD.
That having been said, I'll post that program in another comment, because I have to post it as "Code" instead of "HTML." Please mod it up (the actual code, as well as the instructions below) as Score:5, Insightful, so everyone could read it and install, because I think every Slashdotter deserves to have her Linux four times better than it has ever been.
You have to save my program as /usr/local/bin/smarthelp, then run:
chmod a+rx /usr/local/bin/smarthelp
as root and insert this line in your ~/.bashrc file:
[ $PS1 ] && alias help=smarthelp
Remember to give me credit and to not violate the GNU General Public License it is hereby released under. The code follows:
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
#!/bin/bash
/usr/local/bin/smarthelp /usr/local/bin/smarthelp
0 901
# save it as
# chmod a+rx
# and insert this line in ~/.bashrc:
#
# [ $PS1 ] && alias help=smarthelp
# PTH(R) Smart Help(TM) v1.0.1-pre2
# http://slashdot.org/comments.pl?sid=99801&cid=851
# Copyright (C) 2004 Pan T. Hose, PhD.
# http://slashdot.org/~Pan+T.+Hose
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
a=${@:-help}; help "$a" 2>/dev/null || man "$a" || apropos "$a"
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
I find the comment "before MicroSoft" amusing. Apple had the first commercially successful GUI in 1984- nine years before MicroSofts wirst usable version of windows. The UNIX world was using XWindows six years earlier too. Everyone was making fun of MicroSoft's lowly MS-DOS interface.
No, no, Microsoft brought about the "dark times" by forcing its braindead "CLI sucks" philosophy on ever single damn computer user.
"Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it." -- Linus Torvalds
Oddly enough, since I started my webhosting ordeal, I have found that complete and utter newbies ARE oddly good at picking up the command line.
:)
For example, I walk most first time customers through the usual setups, SCP client, SSH client,Mail, all that depending on what OS they are on.
I swear, it takes me three times as long to walk them through the GUI stuff, with all its bells and whistles they have to think about.And then the 'hard part' of the command line, they are off and banging away within a few short minuts. In fact, I have had a few newbies take one look at Pine and go 'Oohh, neat, I don't even need a program to use it!'
AND THEY USE IT(pine)!
And you have no idea what I mean when I say 'newbie', I mean literal 'Just got away from yahoo webhosting, does not even know HTML yet' newbie. Picked the command line right up, and yet I got two more calls for the damn GUI client. And this is hardly the first time.
Sometimes I really love this line of work..
My new top secret key -> C>N|KB
I was an operator/admin on an archaic Wang 300 mini system back in the 80's on a US air force base. The OS was Wangs multiuser system and, while fantastically old by todays standards, demonstrated something that I not seen in later jobs as admin for on Windows and Novell systems: consistency and simplicity.
The user had access to Wangs text based word processor, spreadsheet, groupware and simple database programmes, of course everything running on a central system and the users only having terminals.
There was far less, and I really mean far less support hassle, especially on the telephone as it was so much easier to understand what the users currently were doing and the users, having a reduced set of commands, could mess up in x number of ways. Added to that the interfaces were consistent and easy to remember. Ironically, all that could today run on a single Unix machine with terminals with ease (about 150 users).
I compare that to the aches of supporting Microsoft office in my last jobs, with users being all over the place and repeatedly not being able to remember the simplest of GUI functionality. Not even younger employees who had grown up with GUIs were confident in what they were doing.
The comment about graphics is valid though. A hybrid CLI with graphics functionality would probably be the best bet for all.
..anybody who uses an OS X box regularly knows what i mean. a well-designed GUI makes a lot of tasks simpler - i know a lot of you like your config files, but i really enjoy my mac config dialogs; you're absolutely nuts if you want to argue the firewall (in OS X) is easier to set up from the shell rather than system preferences. OTOH, i do use iTerm rather a lot, especially for dealing with huge quantities of files (Aqua bogs horribly when you try and move >2000 files around at once) and non-graphical web stuff...FTP is literally about half again as fast from the commandline. basic text editing too, although bbedit's multicolored highlighting with programming languages is nice for certain things.
side story: my dad was a communications operator for the air force in 'nam, a guru of the proto-net - he used to tell me about playing battleship with people in Greenland, in 1968, over the teletype. he hadn't touched a computer in 30 years, loathed the things, until i sat him down in front of my box, logged in as >console (switches off Aqua, drops you to a pure CLI). he stared at it for a second, then his face lit up as he said "OHHHhhh, it's just like my teletype, only on a screen!"...he's now does all his email, web browsing, imming, and text editing (invoices, inventories, whatnot) off the commandline. he DID ask if i could use the printer instead of the monitor once though, i had to shoot that one down...
Facts do not cease to exist because they are ignored. - Aldous Huxley
(define set-him-straight
(lambda ()
(display "Learn a language that's capable of abstraction without boilerplate, dammit!")))
(set-him-straight)
Command line might be easier to teach, but hand two complete novices(as in never used a PC) a GUI system, a command line system, and a typicaly sparse new users guide.
See who makes effective use of their system faster. Idiot simple interfaces aren't for those who go out to be trained, they are for the secretaries and such who take a job and need to work right away, without training in how to use the computer.
As for the user, if I sit down at a computer that is localized in French, I can still use it because we all agree on what the command names are, regardless of what language we speak. "cd" is not "change directory," it's the mnemonic for the command that changes the directory. I don't care if it's zk or zmienkatalog, so long as it's the same. If I want something else I can alias it. By way of example, I logged into my normal account using Croatian as the localization context. Everything works as expected, but I can't read the error messages.OK. Let's see what languages are supported on this machine.
No problem. English, Japanese, and Croatian. My Japanese is not much better than my Croatian, so let's try English.
Oh... that wasn't too bad. Let's just set the language for English from here on out though.By ensuring that all the commands and protocols are the same, Japanese, Croatian, and English users of this machine can all use the same programs, and most importantly, their programs can interact as well.
-Hope
...the help system offered by...
...wait for it...
...VMS.
You type "help [command]" and you entered an interactive mini-CLI environment. The help screens were nested, so your help sessions might look like
The help interpreter was "fuzzy", so you could just type part of a command, or even just a topic, and be presented with a list.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
You are asking for programmable completion, which zsh and ksh have had for years, and bash just added a couple of point revisions ago. Look for the "bash completion" project at freshmeat to get a large library of hooks. Some distros already distribute the library, you just to turn it on (e.g., for Debian, uncomment some stuff in
For ls, I type "ls --q<tab><tab>" and get a list of options beginning with q. For make, I type "make cl<tab>" and it completes the target name to "clean". And so forth.
I contributed one that does option completion for gcc, then somebody rewrote it. :-)
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
I've TA'd a few 2nd-year CS courses, and I've noticed that even the most primitive CLI-proficient users are leaps and bounds ahead of the most advanced GUI-adept users when it comes to understanding the fundamentals of computation. CLI users are quite familiar with things like turing machines, because much of what they do behaves in a similar fashion. GUI users can't do anything without triggering events, dealing with multithreading, etc. It's so complicated they don't really know where to start when we make them build them themselves for the first few times. Our department has a few low-level classes that emphasis GUI-based programming, and a few that emphasize CLI-based programming. The students love the CLI, because, get this, it's a simpler and more intuitive way of doing things.
Granted, the average newbie and the average starting CS undergrad are a little different, but I've definitely witnessed the phenomenon at work.
WARNING: there is a trojan on your
In my experience, I see that newbies get along better with the CLI than with the GUI. Perhaps this is because they "know" the CLI is hard, they pay attention, but because they "know" the GUI is easy, they think they're stupid when it's not.
But another reason is that GUIs have an infinite number of states, whereas when he see a command line prompt, you know exactly what state the system is in.
I gave me parents my old 8086 running DOS. They had no problems with it. When I told them what to do, they wrote down the instructions step-by-step. Now my mom has a Windows system, and she's as confused as I've ever seen her. I can't give her step-by-step instructions, because one can never know the exact state of the system to start from. If the order of the menu items change she gets lost. If she installs a new program the icons on the desktop change position and she gets lost. I've even had her accuse me of breaking the computer when I forget to remaximize the Internet Exploder window after I was done using it. Since it wasn't maximized she didn't recognize it, and wanted me to put the system back the way it was.
It took her the longest time to realize that the purpose of moving the mouse was to reposition the mouse cursor. For a while she was wondering why moving it two inches to the left and clicking didn't always bring up the menu.
My mother is not stupid, she just hasn't groked the underlying, unwritten and unexplained paradigms behind the GUI. She doesn't think of the computer as something to interact with, but as a machine you issue commands to. Hmmm, she is pretty smart after all...
Don't blame me, I didn't vote for either of them!