In the old days, Unix commands would, when fired, either make a silent accept or an error. That is, if you sent a command to a shell they would by default not spew out any information on the standard output unless something was wrong. Today, silent accept is dead. We have to supply -q parameters to programs to make them behave and not pester our command lines with information. This is a shame because confirmation messages tend to clutter up the screen a lot. Want to do a secure copy over ssh? Then you get information back for each line copied. Want to execute make(1)? You will see endless lines of compilation messages by default and I am pretty sure nobody reads them. Want to view a movie in mplayer? Many lines of output. For some applications, "quiet" is not quiet enough. They have the --quiet-and-i-fsck-mean-it! option to help you quell their responses. It is a shame that the terseness of the Unix command-line has been destroyed by this. I think the problem is cognitive: Scrolling lines of text by will make you miss the context totally when you come back to the display later after your scp has completed. You don't know what the context were, so you will search in the history for the last command executed to figure out what you were doing. Then you will fire off another command, leave the terminal. This cycle then repeats itself. I would love for Silent Accept to come back. I urge you to make it the default. I urge you to take the original ideas of Unix and protect them.

I installed and began playing with rio(1) today. It would look as if I am having my yearly minimalism flashback. First Acme, now rio.

From time to time I tend to try a new editor. What would make you steer away from your trusty old Emacs shell? The reason is pure curiosity -- I tend to like to see new things and get new views on computing. We must realize that part of what we use on the computer is built for humans in order to make humans interface with the computer. The editor is for editing documents that may happen to tell the computer what to do. The task is quite simple, and originally on unix, ed did the job. Much have happened since that time, or has it really? We still edit files and though we got syntax highlighting, multiple buffers, IDEs nothing has really changed much. You still "open" a file. Edit it and then you put the changed file back on the file system. Editing done. Some editors change the way we look at editing in a really deep way. This time it was Rob Pike's Acme editor. I really like this editing environment and should I ever get to the point where I wanted to write an editor in Haskell, ML or similar, it would aspire to acme. First, the editor is dead simple. It can be done in less than 10000 lines of C, hinting on something around 1000 lines of Haskell/ML. It would be pretty cool to have an editor written in those languages and the extension language would be pretty obvious. What amazes me is that this little editor is extremely usable. There are no movement with the cursor keys, rather they scroll the window. The mouse is an integral part of the editing process. But compared to weak uses of the mouse found in other environments, the acme editor makes really good use of it. I always hated the mouse. Then I tried acme. It is certainly not for everyone. It is not like vi or emacs at all. But you will become proficient in it in 1 week. And then you know all of it. Since it can run any Unix-shell command on a selection in a window you don't need that much power in the editor itself. Just make Unix help you out. Sheer power. Thanks Rob!