> http://en.flossmanuals.net/gnulinux
I'll try not to criticize the article too heavily, but there seem to be some glaring mistakes. 1. "Further, you can schedule scripts to occur at a specific time or date or at the occurrence of a specific event on your computer" Bad example. How does cron, at, or anacron have anything to do with CLI? I can ask it to play a track in Amarok. 2. "Ever tried to do anything remotely like that by using a Graphical User Interface?" Firstly, you haven't quoted any mindblowing examples of CLI functionality that cannot be done using GUI. Scheduling? I'm pretty sure there are plenty of graphical schedulers/ sophisticated alarms for Linux. Batch resizing images? Gimp comes with a scripting language called Script-Fu which can easily do this. More and more applications (yes, GUI applications) are coming out with extensibility and scripting frameworks. I just quoted Gimp as one example. AutoCAD uses a dialect of Lisp as its extension language, and the elephant in the room Emacs is mostly written in Emacs Lisp. A shell scripting language like ZSH's is no different- it's a language, that's all. 3. "There are many commands you can use to check every facet of your computer's health, from the amount of space left on the hard drive to the temperature of the CPU" I wouldn't cite this as something that you can do from the command line. It's like saying that `df -h' or `cat cat /proc/acpi/thermal_zone/THRM/temperature' is more "useful" than a graphical monitor like Conky or GNOME applets that do the same thing. 4. "There is one other interesting feature of command line interfaces that GUIs can't match: interaction over a network." I'm pretty sure there are hundreds of remote desktop projects for Linux. Forget all that: I use `ssh -X' all the time. I don't want users to have the impression that they can't run their graphical applications over the network. 5. "Well, those that know how can connect to the computer in the next room via the command line and type halt." Bad example. If you're looking to get Windoze converts, this'll give them the completely wrong picture. They'd expect something like the remote desktop they use in Windoze to `Start > Shutdown'. The worst part is that such a remote desktop exists, but you're scaring away/ misguiding users by telling them this. 6. "GUI programs often send more error messages to the CLI, than they show in dialog boxes, this is useful to diagnose problems" Er. If you're looking to diagnose why a certain program didn't start when you clicked a menu item, it's useful. But otherwise, no- it's useless. Many programs today come with a compile flag to generate a stripped down verbose executable for debugging. The output to CLI of a normally compiled graphical application is practically useless- you see, it's an optimization technique; if you keep tracing and printing useful debugging symbols from the program, it's going to slow down significantly. On a closing note, I think your approach of creating this huge barrier between CLI and GUI, and advocating the use of CLI is just plain wrong. Instead, you should be embracing both "worlds" (Yes, that's the word used in the article- GUI and CLI are apparently worlds apart), and concentrate on writing something useful. p.s- There's a reason all "newbie Linux" tutorials suck. They're written by beginners themselves. Experts can't be bothered to write one. Yes, it's a problem; but I see no solution ahead until people stop writing `cookbooks' of new Linux commands. -- Artagnon (.com) _______________________________________________ ilugd mailinglist -- ilugd@lists.linux-delhi.org http://frodo.hserus.net/mailman/listinfo/ilugd Archives at: http://news.gmane.org/gmane.user-groups.linux.delhi http://www.mail-archive.com/ilugd@lists.linux-delhi.org/
