Differences between revisions 1 and 11 (spanning 10 versions)
Revision 1 as of 2009-08-14 19:41:02
Size: 3990
Editor: MichelBarret
Comment: Ceci n'est pas une traduction
Revision 11 as of 2013-01-27 10:30:32
Size: 4235
Comment: Sync with English master
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
||<tablestyle="width: 100%;" style="border: 0px hidden">~-[[fr/DebianWiki/EditorGuide#traduction|Traduction(s)]] : aucune-~||<style="text-align: right;border: 0px hidden"> (!) [[/Discussion|Discussion]]|| ||<tablestyle="width: 100%;" style="border: 0px hidden">~-[[fr/DebianWiki/EditorGuide#traduction|Traduction(s)]] : [[TheUnixWay|English]] - Français - [[it/TheUnixWay|Italiano]]-~||<style="text-align: right;border: 0px hidden"> (!) [[/Discussion|Discussion]]||
Line 5: Line 5:
From its beginnings, Unix was based on basic and simple fundamental building blocks that are at the same time powerful and flexible. The basic components of a Unix system are files, users, processes, and data. Programs are ideally small, simple tools that do one task but do it well. Many programs can act as a '''pipeline'''. They read data in one end, and write it out another ('''stdin''' and '''stdout''', but there's also '''stderr''' which generally receives error output). 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 la 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).
Line 7: Line 7:
By attaching several programs together, it's possible to build complex tools simply and quickly, without worrying about complexity. Programs tend to be '''highly modular''' in Unix. En faisant travailler 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.
Line 9: Line 9:
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. Bien que ces principes n'aient pas été particulièrement suivis dans les 30 années qui ont suivis la sortie d'Unix, les principes fondamentaux restent 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.
Line 11: Line 11:
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 ;-) ]]" Encore une fois : « Avec un petit programme qui effectue __une__ tâche et une seule, mais qui le fait bien et efficacement, l'utilisateur (qui peut être l'administrateur) peut le combiner avec d'autres pour effectuer une tâche plus complexe. » L'auteru de cette page a écrit un programme en C pour compter les occurrences de mots dans un texte, pour ensuite découvrir que la commande "cat file || tr \ \\n || sort || uniq -c" faisait la même chose - mais plus vite ;-) )
Line 13: Line 13:
'''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. L' '''administration système''' sous Unix est généralement effectuée par des manipulations matérielles, 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 texte) 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) proposent 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 en l'arrière-plan.
Line 15: Line 15:
The concept of "shallow complexity" applies here. Le concept de «complexité superficielle» s'applique ici.
Line 19: Line 19:
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. La plupart des systèmes Unix peuvent être placés dans la continuité de System V ou BSD. Les systèmes BSD ont tendance à suivre de près à la Voie Unix comme décrit ci-dessus. Ils sont particulièrement adaptés pour ceux qui souhaitent avoir un contrôle total de chaque paquetage. System V est plus orienté vers l'entreprise et est conçu avec des interfaces et des sous-systèmes plus pratiques dans ce sens. En particulier, Système V est plus susceptible d'avoir des moyens pour intégrer des logiciels tiers sans grandes difficultés d'administration. Les scripts d'initialisation du système au démarrage sont un exemple simple. Les systèmes BSD tendent à avoir un petit nombre de scripts qui sont maintenu par l'administrateur, la voie Système V, sans contradiction avec la voie Unix, permet à des logiciels de s'installer avec moins de risque d'erreur.

=== Voir aussi ===
 * [[fr/SystemAdministration|Administration système]]
 * TheDebianWay

Traduction(s) : English - Français - Italiano

(!) ?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 la 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).

En faisant travailler 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'aient pas été particulièrement suivis dans les 30 années qui ont suivis la sortie d'Unix, les principes fondamentaux restent 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, l'utilisateur (qui peut être l'administrateur) peut le combiner avec d'autres pour effectuer une tâche plus complexe. » L'auteru de cette page a écrit un programme en C pour compter les occurrences de mots dans un texte, pour ensuite découvrir que la commande "cat file || tr \ \\n || sort || uniq -c" faisait la même chose - mais plus vite ;-) )

L' administration système sous Unix est généralement effectuée par des manipulations matérielles, 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 texte) 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) proposent 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 en l'arrière-plan.

Le concept de «complexité superficielle» s'applique ici.

System V vs. BSD

La plupart des systèmes Unix peuvent être placés dans la continuité de System V ou BSD. Les systèmes BSD ont tendance à suivre de près à la Voie Unix comme décrit ci-dessus. Ils sont particulièrement adaptés pour ceux qui souhaitent avoir un contrôle total de chaque paquetage. System V est plus orienté vers l'entreprise et est conçu avec des interfaces et des sous-systèmes plus pratiques dans ce sens. En particulier, Système V est plus susceptible d'avoir des moyens pour intégrer des logiciels tiers sans grandes difficultés d'administration. Les scripts d'initialisation du système au démarrage sont un exemple simple. Les systèmes BSD tendent à avoir un petit nombre de scripts qui sont maintenu par l'administrateur, la voie Système V, sans contradiction avec la voie Unix, permet à des logiciels de s'installer avec moins de risque d'erreur.

Voir aussi