Philosophie d'Unix - Définition

Raymond : L'Art de la Programmation Unix

Eric S. Raymond, dans son livre The Art of Unix Programming, résume la philosophie Unix par la philosophie largement utilisée en ingénierie, le principe KISS « Keep it Simple, Stupid » (« Reste Simple, Crétin » ou « Sois Simple et Concis »), connu aussi sous le nom du Rasoir d'Occam. Puis il décrit sa vision selon laquelle cette philosophie globale s'applique en tant que norme culturelle Unix, bien qu'on trouve sans surprise de graves violations de la plupart des règles Unix suivantes :

• Règle de Modularité : Écrire des éléments simples reliés par de bonnes interfaces.
• Règle de Clarté : La Clarté vaut mieux que l'ingéniosité.
• Règle de Composition : Concevoir des programmes qui peuvent être reliés à d'autres programmes.
• Règle de Séparation : Séparer les règles du fonctionnement ; Séparer les interfaces du mécanisme.
• Règle de Simplicité : Concevoir pour la simplicité ; ajouter de la complexité seulement par obligation.
• Règle de Parcimonie : Écrire un gros programme seulement lorsqu'il est clairement démontrable que c'est l'unique solution.
• Règle de Transparence : Concevoir pour la visibilité de façon à faciliter la revue et le déverminage.
• Règle de Robustesse : La robustesse est l'enfant de la transparence et de la simplicité.
• Règle de Représentation: Inclure le savoir dans les données, de manière à ce que l'algorithme puisse être bête et robuste.
• Règle de La moindre surprise : Pour la conception d'interface, réaliser la chose la moins surprenante.
• Règle du Silence : Quand un programme n'a rien d'étonnant à dire, il doit se taire.
• Règle de Dépannage : Si le programme échoue, il faut le faire bruyamment et le plus tôt possible.
• Règle d'Économie : Le temps de programmation est cher, le préserver par rapport au temps de la machine.
• Règle de Génération : Éviter la programmation manuelle ; Écrire des programmes qui écrivent des programmes autant que possible.
• Règle d'Optimisation : Prototyper avant de fignoler. Mettre au point avant d'optimiser.
• Règle de Diversité : Se méfier des affirmations de « Unique bonne solution ».
• Règle d'Extensibilité : Concevoir pour le futur, car il arrivera plus vite que prévu.

De nombreuses de ces règles sont reconnues en dehors de la communauté Unix — que ce soit avant qu'Unix les utilise pour la première fois, ou après. De même, de nombreuses règles ne sont pas une exclusivité d'Unix ou ne sont pas originales. Cependant, les adeptes de la programmation Unix ont tendance à considérer que le style Unix est basé sur une combinaison de ces idées.

Pire c'est mieux

Extrait de l'article: Worse is Better

Richard P. Gabriel (en) suggère que le point clé pour UNIX est qu'il incarne un concept philosophique qu'il désigna par « Pire c'est mieux ». Selon ce principe de conception, la simplicité à la fois de l'interface et à la fois de l'implantation compte plus que n'importe quelle autre caractéristique du système — y compris l'exactitude, la cohérence et la complétude. Gabriel explique que le style de la conception possède des avantages évolutifs clés, quoiqu'il mette en doute la qualité de certains résultats.

Par exemple, au début sous UNIX les processus utilisateur effectuaient les appels au système sur la pile de l'utilisateur. Si un signal était transmis à un processus pendant qu'il était bloqué par une Entrée/Sortie de longue durée, comme par exemple sleep(10*60). Que faut-il faire dans ce cas ?

Le signal devrait-il être retardé, peut-être pour une longue durée (même indéfiniment) pendant que l'Entrée/Sortie se termine ? Le gestionnaire de signaux ne pourrait pas être exécuté pendant que le processus est en mode noyau, ayant des données importantes sur la pile. Le noyau devrait-il repousser l'appel au système, l'entreposer pour le rejouer et le re-déclencher plus tard, en supposant que le gestionnaire de signaux se termine avec succès ?

Dans ces exemples Ken Thompson et Dennis Ritchie ont préféré la simplicité à la perfection. Le système UNIX pouvait parfois retourner rapidement d'un appel au système avec une erreur déclarant qu'il n'avait rien fait – « L'appel au système interrompu » – une erreur numéro 4 (EINTR) dans les systèmes actuels.

Bien sûr, l'appel a été abandonné afin d'appeler le gestionnaire de signaux. Cela pourrait arriver pour une poignée d'appels au système ayant une exécution longue, comme read(), write(), open(), select(), etc.

L'avantage de ceci était de rendre le système d'E/S de nombreuses fois plus simple à concevoir et à comprendre. La grande majorité des programmes d'utilisateurs ne furent jamais affectés parce qu'ils ne géraient pas d'autres signaux que SIGINT, et qu'ils mourraient immédiatement si ce signal était déclenché. Pour les quelques autres programmes – comme des shells ou des éditeurs de texte qui répondent aux touches de contrôle de processus – de petits emballages pouvaient être ajoutés aux appels au système de manière à ré-essayer l'appel immédiatement si cette erreur EINTR était déclenchée. Problème résolu de manière simple.