Re: [HI Cap] Re: OUDL: Introduction to Machine Learning

[RogerI...@aol.com]

I took a look at that web page. He notes, "A quick survey among my friends revealed that between 10 and 20% of all commands they type are actually cd [change directory] commands!" and then goes on to show how "autojump" ( a program that learns from the user) is so much easier.

 

I've been in software development for over forty years and worked with many different operating systems. Yes, there was a time when everything was done through the "command prompt", and we were glad to have it. But Windows, and other graphical user interfaces, have been around since 1984. Why is anyone still using command prompts?

 

- Roger Garrett

 

 

 

 

In a message dated 6/23/2012 1:35:56 P.M. Hawaiian Standard Time, kyl...@gmail.com writes:

Just a quick note that: before the Machine Learning talk, Will Ting will present a lightning talk on Autojump.

[Bryan Wolfford]

UIs are usually outdated and never offer the full capability of most (if not all/any) program... Let alone an operating system. Windows and MacOS not excluded.

Sent from my Windows 7 Phone

---

From: RogerI...@aol.com
Sent: 6/23/2012 4:14 PM
To: honolulu-...@googlegroups.com
Subject: Re: [HI Cap] Re: OUDL: Introduction to Machine Learning

[David Cornejo]

The next version of Windows Server is beginning to deprecate management by GUI.  I can still think of several operation on my Windows 2008 & 2003 Servers that start off "open a command window..."

The two reasons that come to my mind are that GUIs rarely manage to effectively convey large numbers of complex choices, especially with odd dependencies involved, and secondly GUIs place a heavy burden on processing power and memory that I'd much rather dedicate to clients.

[William Ting]

Hi Roger,

Unix philosophy is best encapsulated with this quote:

Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

 

- Doug McIlroy

Modularity offers flexibility. The terminal just happens to be the best application for interacting with multiple tools and manipulating text.

This is useful for sysadmins and developers. Here are some examples:

1. Regular backups to an offsite location and notify admin (cron job, ssh, postfix).
2. Find all e-mail addresses from multiple files (grep).
3. Batch rename files from one format to another: server_12-31-1999.log → 1999.12.31_server.log (rename).
4. Batch create thumbnails for a directory of photos (imagemagick, find).
5. Scrape meta data from photos to build charts (exiftool, gnuplot).
6. Run tests after every commit and notify build failures (scm hooks, postfix).
7. Find duplicate files in a directory (find, md5sum, xargs, uniq).
   
8. Remotely admin machines over a high latency / low bandwidth connection (ssh).
9. Find the 3 highest numbers of the 2nd field from lines 10-20 of files modified within the past 5 minutes by a specific user (find, awk, sed, sort).
   

If you notice man of the commands are repeated quite often in different contexts. Anything that needs to be repeated more than 3 times can be automated in a *nix environment. The same cannot be said of Windows.

Microsoft noticed Windows sysadmins were at a disadvantage, and thus released PowerShell in 2006. It's the same reason why the Cygwin project is still in active development after 17 years.

You might also be surprised that many developers today still use vim / emacs despite both being 35 years old (well vim was released in '91).

- William

[Kyle Oba]

This is just me, but I still use the command line daily.

I also think that the ability to redirect input and output from one utility to another, in a way unplanned by the creator of the separate utilities, is pretty fantastic.

Kyle

[Kevin McCarthy]

The science fiction author Neil Stephenson wrote an essay back in 1999
that was turned into a book called "In the Beginning was the Command
Line." It's a little dated now but is still a massively fun read. It
discusses the history of computing and has some hilarious analogies
comparing operating systems to cars. It also discusses why exactly we
are still typing into terminal emulators that, for all the computer
knows, are hooked up to some teletype machine at a university
somewhere.

Here's the link: http://www.cryptonomicon.com/beginning.html

Here's an excerpt:

But there is one type of window you'll see on Linux GUI that is rare
or nonexistent under other OSes. These windows are called "xterm" and
contain nothing but lines of text--this time, black text on a white
background, though you can make them be different colors if you
choose. Each xterm window is a separate command line interface--a tty
in a window. So even when you are in full GUI mode, you can still talk
to your Linux machine through a command-line interface.

There are many good pieces of Unix software that do not have GUIs at
all. This might be because they were developed before X Windows was
available, or because the people who wrote them did not want to suffer
through all the hassle of creating a GUI, or because they simply do
not need one. In any event, those programs can be invoked by typing
their names into the command line of an xterm window. The whoami
command, mentioned earlier, is a good example. There is another called
wc ("word count") which simply returns the number of lines, words, and
characters in a text file.

The ability to run these little utility programs on the command line
is a great virtue of Unix, and one that is unlikely to be duplicated
by pure GUI operating systems. The wc command, for example, is the
sort of thing that is easy to write with a command line interface. It
probably does not consist of more than a few lines of code, and a
clever programmer could probably write it in a single line. In
compiled form it takes up just a few bytes of disk space. But the code
required to give the same program a graphical user interface would
probably run into hundreds or even thousands of lines, depending on
how fancy the programmer wanted to make it. Compiled into a runnable
piece of software, it would have a large overhead of GUI code. It
would be slow to launch and it would use up a lot of memory. This
would simply not be worth the effort, and so "wc" would never be
written as an independent program at all. Instead users would have to
wait for a word count feature to appear in a commercial software
package.

GUIs tend to impose a large overhead on every single piece of
software, even the smallest, and this overhead completely changes the
programming environment. Small utility programs are no longer worth
writing. Their functions, instead, tend to get swallowed up into
omnibus software packages. As GUIs get more complex, and impose more
and more overhead, this tendency becomes more pervasive, and the
software packages grow ever more colossal; after a point they begin to
merge with each other, as Microsoft Word and Excel and PowerPoint have
merged into Microsoft Office: a stupendous software Wal-Mart sitting
on the edge of a town filled with tiny shops that are all boarded up.

It is an unfair analogy, because when a tiny shop gets boarded up it
means that some small shopkeeper has lost his business. Of course
nothing of the kind happens when "wc" becomes subsumed into one of
Microsoft Word's countless menu items. The only real drawback is a
loss of flexibility for the user, but it is a loss that most customers
obviously do not notice or care about. The most serious drawback to
the Wal-Mart approach is that most users only want or need a tiny
fraction of what is contained in these giant software packages. The
remainder is clutter, dead weight. And yet the user in the next
cubicle over will have completely different opinions as to what is
useful and what isn't.


Kevin

[Tim Newsham]

surely this is the start of a flame war.. but why not...

The way I look at it is this -- bandwidth.  There's a lot of information that

can be shown from a graphical interface to my brain, but there's very

little information that can be conveyed from my brain through a mouse

pointer.  A keyboard is much higher bandwidth.

beyond that, most graphical interfaces are very simplistic and

not compositional.  on the other hand most command environments

are compositional and allow me to build up complex commands 

very quickly and easily.

On Saturday, June 23, 2012 4:14:29 PM UTC-10, Roger Garrett wrote:

[Bob Matcuk]

Has anyone else noticed that file copying takes FOREVER in a GUI compared to the command line?

Try it out!

Try to copy a directory from a network drive that is deeply nested with a bunch of files using a GUI. Then copy it using cp -R. The difference is enormous! I believe it's because the stupid GUI is trying very hard to give me an accurate progress bar and so it's wasting all it's bandwidth figuring out how many files there are and the total size of all the files. How annoying!

To a lesser extent, the problem also exists when copying a single large file, such as a DVD image... though, I have no explanation for that!

You'll have to pry my command line from my cold, dead fingers! No GUI will ever replace the power of bash, sed, awk, grep, find, and friends.

-Bob

On Saturday, June 23, 2012 4:14:29 PM UTC-10, Roger Garrett wrote:

[Laurence A. Lee]

It really depends on the task at hand, and how much visualization is necessary for daily operations.

And I agree with Tim, this is definitely a flame-bait thread.  Same arguments and reasoning made here can be made against vi(m) and any off-the-shelf IDE.

My take is to follow the 80/20 rule -- use the GUI for the common tasks that are 80% of the normal workflow (the stuff you don't want to commit to memory), and drop to the command-line for everything else, or for those cases where it's more efficient.  There's no need to fire up egos and make capability comparisons over how people prefer to get their job done.

I can fire up a Microsoft System Center 2012 console and deploy a fresh Windows 7 OS to multiple workstations at multiple sites at the click of a button.  Does that make the command-line inferior?  Of course not.  I'd still drop into PowerShell to tweak a user's mailbox quotas on a local Exchange Server, rather than navigate through several panels of information to get to the right spot, as it's more efficient.

In the end, they're all just tools to get the job done.

[Jerry Isdale]

Similar arguments of utility can be made for Visual Programming Languages.

The graphical stuff is sometimes easier to manipulate and see what is happening

but the text based stuff is required for heavy lifting/bit twiddling.

34years of shell scripts and C coding puts me firmly in the text based world for automating, although I like the desktop view for organizing and such.

Jerry Isdale

isd...@gmail.com

[David Cornejo]

But the cool thing about this list is that it *hasn't* turned into a flame war...