Au départ, Unix était basé sur des bloques basiques et simples en même temps puissants et flexibles. Les éléments de base d'un système Unix sont les fichiers, les processus et les données. Idéallement les programmes sont petits, de simples outils pour faire une seule chose mais le faire bien. Plusieurs programmes peuvent travailler comme un pipeline (tube). Ils lisent les données à la fin d'un tube, et écrivent sur un autre (stdin et stdout, mais cela peut être aussi stderr qui est généralement la sortie d'erreur).
Par travail de différents programmes ensemble, il est possible de construire des outils complexes simplement et rapidement, sans problème de complexité. Les programmes tendent à être très modulaires sous Unix.
Though these principles haven't been slavishly followed in the 30 years+ that Unix has been around, the fundamental principles still remain at the core of most Unixes, as well as various clones/derivates such as the ?BSDs and GNU/Linux systems. This modular design philosophy can clearly be seen within many of the programs and subsystems therein.
So again: "Have a small program do only one small task but do that well and efficiently - the "user" (which might actually be the sys-admin) can then combine many of those to get the job done. [[I have programmed a C program to count occurences of words in a text only to find out that "cat file || tr \ \\n || sort || uniq -c" does the same job - just faster 
]]"
System Administration in Unix is generally carried out by either manipulating hardware (swap the tapes, etc.), changing filesystem settings using commands that are front-ends for system calls (chmod, chown, mount, etc.), installing vendor-supplied software and patches, compiling and installing the most recent versions of free software, or -- most importantly -- writing and editing (with a text editor) scripts and configuration files. OS functions that are carried out by invoking ?ShellScripts give the administrator a great deal of control over the behavior of the system. Unix programmers have their programs read configuration files -- in fact, the configuration may implement a scripting language -- as the most straightforward way to give the admin control over the program's features. Occasionally vendors (or a senior admin) will provide an administration menu system or GUI in an effort to simplify the various tasks, but the Unix Way is for there to be little text files being edited and little programs being run. Since no simplification can cover all the intricacies (it's impossible to write real programs by pushbutton) administrators have still needed to know what's going on in the background.
The concept of "shallow complexity" applies here.
System V vs. BSD
Most Unix-like systems can be placed on a continuum between System V and BSD. BSD-like systems tend to follow closely to the Unix Way as described above. They are especially geared toward those who want to have total control in a small package. System V is more geared to the "Enterprise", and is designed with interfaces and subsystems that make it more friendly to . . . environments where a tie is required. In particular, System V is more likely to have ways for third-party software to integrate with the system with a minimum of administration effort. A prime example is the structure of the system initialization scripts, which are run when the system boots. While BSD systems tend to have a small number of scripts that are hand-maintained by the admin, System V has a set of directories containing smaller scripts, each of which do one thing. While the BSD way is more straightforward for the lone admin, the System V way, without contradicting the Unix Way, allows software packages to install themselves with less likelihood of error.