Traduction(s) : English

(!) ?Discussion


Au départ, Unix était basé sur des blocs 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éalement 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.

Bien que ces principes n'ont pas étaient particulièrement suivis dans les 30 années qui ont suivis la sortie d'Unix, les principes fondamentaux reste au cœur des Unix modernes et des clones ou systèmes dérivés comme les systèmes ?BSD et GNU/Linux. Cette philosophie modulaire peut clairement être vue dans les programmes et les sous-systèmes de ces systèmes d'exploitation.

Encore une fois : « Avec un petit programme qui effectue une tâche et une seule, mais qui le fait bien et efficacement, être utilisé par l'utilisateur (qui peut être l'administrateur) pour être combiné avec d'autres pour effectuer pour accomplir une tâche plus complexe. »

L' administration système sous Unix est généralement effectué par des manipulations matériels, manipuler le système de fichier grâce à des commandes comme (chmod, chown, mount, etc.), l'installation de logiciel et de mises à jour, ou, le plus important, écrire et éditer (avec un éditeur de text) des scripts et de fichiers de configuration. Le travail effectué par un script shell, donne beaucoup de contrôle à l'administrateur sur le système. Les programmeurs Unix ont des programmes qui lisent des fichiers de configuration (en fait la plupart implémentent un langage de script) pour donner le maximum de contrôle à l'administrateur pour manipuler les possibilités d'un logiciel. Parfois les vendeurs (ou les vieux administrateurs) propose un menu d'administration système ou une interface graphique dans le but de simplifier les différentes tâches, mais la « voie Unix » est d'avoir de petits fichiers édités et de petits programmes lancés. Étant donné que la simplification ne peut couvrir toutes les subtilités (il est impossible d'écrire des programmes réels par bouton poussoir) les administrateurs ont toujours besoin de savoir ce qui se passe dans l'arrière-plan.

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.