jam <j...@tigger.ws> writes: > On Sunday 23 August 2009 16:38:37 slug-requ...@slug.org.au wrote: >> >> Can you throw light on the demise of the "unix shell"? >> > >> > I'm guessing 'contextually', that you're asking about the demise of the >> > original Thompson shell that shipped with Unix? Since replaced by Bash, >> > Csh et al? >> >> Possibly, my memory of the idea behind Unix Shells...was similar to the >> concept of the Java machine and possibly the Browser, KDE and Gnome. Wine >> would be another candidate - ie you would implement MSWindows as a shell, >> running on Linux. >> >> No one seems to be suggesting that KDE or Gnome are shells. I am trying to >> figure out where Bash etc fits into Linux. Does Gnome/KDE run in a Bash >> shell? > > The shell is how you talk to the computer.
[...] > Next came X-windows, the applications that you put on the (often pretty) > screen were managed by a window manager. > > Next was desktops ie KDE, Gnome these are managers with extra functionality. > Ie launchers, icons configuration options etc etc. > > The GUI paradigism allows people who have not learned to talk to computers > to communicate using pictures. This picture mode is slow and cumbersome > (imagine talking to a Russian, but using pictures to convey your point) Respectfully, I disagree with your assumptions here: First, I disagree that the shell is how you talk to the computer; it is one of a wide range of input forms, and has plenty of limitations as well as advantages compared to other inputs, such as the mouse or keyboard. Second, you are making quite an assumption here: that using anything except textual commands on the command line is necessarily less efficient than using a graphical interface. Third, you are making a heck of a value judgement: that anyone who interacts with the computer without using the command line is necessarily less capable than people who do. In terms of addressing the relative efficiency of graphical vs command line interfaces... Well, let me start by saying it is difficult: because you class *ALL* command line and *ALL* graphical interfaces into the same bucket you end up making it hard to discuss the merits of each. As an example, graphical image editing tools generally allow faster editing of pictures than command line tools — generally, because some limited cases are faster on the command line, so even this isn't clear-cut. As another example: http://books.google.com.au/books?id=h0iKRZunOaYC&pg=PA384&lpg=PA384&dq=gui+word+processor+efficience+study&source=bl&ots=AOEkvjGIr-&sig=_NJ-HTjk4Pfx1WCP3jF65L9oXxs&hl=en&ei=6f2RSt2yOYWCkQXQtdy7Cg&sa=X&oi=book_result&ct=result&resnum=3#v=onepage&q=&f=false Here, various studies show that there is no substantial performance difference between graphical and textual editors for standard secretarial tasks. Some tasks are presently more efficient on the command line, but only because the GUI tools are poorly designed or implemented: the standard shell "pipeline" is less efficient in present GUI software because there is no current *easy* implementation of things tied together in the desktop environment. However, the MacOS Automator system is a step in this direction, as is OSA / AppleScript: both of those provide an equivalent mechanism to tie activity together, Automator in a more graphical fashion. So, the tools are showing up. It is hard to find solid supporting evidence for a contention that either the GUI or the command line is more efficient in specific tasks, and impossible to make such a sweeping assertion about the entire field. Finally, the value judgement: I don't have much to say here, except to remind y'all that different is not necessarily better or worse. Regards, Daniel -- ✣ Daniel Pittman ✉ dan...@rimspace.net ☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons Looking for work? Love Perl? In Melbourne, Australia? We are hiring. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
