Succinct Windows User's Guide to the Unix Philosophy

If you grew up in the DOS/Windows world, you're used to a computer having two distinct kinds of interface: The User Interface, which consists of areas of the screen divided into movable rectangular areas called windows which are then subdivided into various areas that will present information and receive input from the user in various ways. The other interface is the Computer Interface where different parts of the computing system interact; so browsers can talk web servers, so the buttons you click can tell the program that you want to evoke the related functionality, and other such things.

The DOS/Windows (this includes modern Windows 7) world puts hard boundaries separating these two kinds of interface: reserving the computing interfaces for programmers (or those who fancy themselves as programmers).

The Unix world, by contrast, doesn't have this kind of duality. It was never true that the line between computer interfaces and user interfaces was fuzzy because there was no line at all.

Many Unix-like systems get criticized for having a bad user interface. Linux kiddies try to refute this accusation by posting youtube videos of pretty desktop effects and all the user-friendly wrappers people write for Unix programs – but those Linux kiddies are missing the point every bit as much as the critic that they are responding to.

Unix is not an ugly user interface. Unix is a beautiful computer interface that the user can experience. This interface opens up a lot of possibilities that simply aren't available in the dual-interface paradigm that rules in the DOS/Windows world.

People often assert that Unix systems are more stable than their Microsoft counterparts but nobody bothers to explain why they think this. Programmers in the Unix world are just as human and just as likely to make mistakes as somebody working in Redmond. I have actually run into many a Unix-navite program that was rather poorly tested and unreliable.

The reason the culture of Unix assumes that it is more stable is because of the computer interface that underlies their entire development cycle. When programs and humans can freely and limitlessly interact with each other on a simple medium, you start to build your programs differently: Programs get much smaller. They have next to no features. They tend to do one thing and do it well. Then if another program might need that same functionality, rather than copy that feature into their own code-base, the program can simply evoke the existing program.

In this way many features are available for minimual effort. All other factors being equal, the smaller program will have fewer bugs. Less code means less room to hide imperfections that lead to instability. If a new feature is needed, chances are really good that all you need to do is combine some other existing programs and you get it without having to do any programming at all.

This is made possible by the Unix-style One Interface For Everything approach to life.

If you're used to using consumer software, you're used to the program trying to coach you in how to use itself. It's generally assumed that the developer has vested the effort in market research and therefore knows your problems (and therefore how to solve them) better than you do.

The assumption is that the user starts the application and it will guide him down the steps he needs to come out with the information he wants. This is great when it all works out but it is very frustrating when the wisdom of the developers is not all it was purported to be.

The core assumption to the Unix world is that programmers are not any smarter than any other human. They can not imagine all the crazy things that you, the user, might want to do with your computer. They prescribe no uses for it but, instead, try to give you the tools that are most likely to help you arrive at a solution.

Somebody selling a consumer application would say "our developers, in their suprassing wisdom, have forseen your problem and solve it with this feature that I can demonstrate." And you either say "cool" or "no, you suck" according to how well your needs line up with the wisdom of those programmers.

A lot of features that required very deliberate and dedicated effort in the consumer software world came free in the Unix world by virtue of the computing interface and this core assumption that stems from it.

There was never a need for a scrollbar in the Unix terminal because the program less already existed. Want to track system usage? Plot the output of vmstat. If you wanna have a VOIP conversation with somebody over the internet, you don't need to install a special voice chat program, just use SSH to redirect your microphone input to a remote user's speakers.

The attitude is that you should never reinvent the wheel. There will always arise a better way to solve a problem so you shouldn't waste too much time committing to the only obvious solution in the moment. High adaptability leads to smoother improvements as technology and human understanding increases.

Armed with this attitude, I think that the world's plethora of "How To Unix" guides will make a lot more sense. It will become apparent why grep and sed are viable replacements for most of the things you find in an "Edit" drop-down menu or why terminals, even with the advent of fancy desktop environments like Gnome and KDE, still haven't managed to disappear from the Unix world.