Filosofía Unix

En el prefacio del libro de 1984, The UNIX Programming Environment , Brian Kernighan y Rob Pike , ambos de Bell Labs , ofrecen una breve descripción del diseño de Unix y la filosofía de Unix: ^{[ 5 ]}

Aunque el sistema UNIX introduce numerosos programas y técnicas innovadoras, ningún programa o idea por sí solo garantiza su éxito. Su eficacia reside, en cambio, en su enfoque de programación, en su filosofía de uso del ordenador. Si bien esta filosofía no puede resumirse en una sola frase, su esencia radica en la idea de que el poder de un sistema reside más en las relaciones entre los programas que en los programas mismos. Muchos programas UNIX realizan tareas bastante sencillas de forma aislada, pero, combinados con otros programas, se convierten en herramientas generales y útiles.

Los autores escriben además que su objetivo para este libro es "comunicar la filosofía de programación UNIX". ^{[ 5 ]}

En octubre de 1984, Brian Kernighan y Rob Pike publicaron un artículo titulado Diseño de programas en el entorno UNIX . En este artículo, critican la acumulación de opciones y características de programas que se encuentran en algunos sistemas Unix más nuevos, como 4.2BSD y System V , y explican la filosofía de Unix de las herramientas de software, cada una de las cuales realiza una función general: ^{[ 6 ]}

Gran parte de la potencia del sistema operativo UNIX proviene de un estilo de diseño de programas que facilita su uso y, lo que es más importante, su combinación con otros programas. Este estilo se conoce como el uso de herramientas de software y depende más de cómo los programas se integran en el entorno de programación y cómo pueden utilizarse con otros programas que de su diseño interno. [...] Este estilo se basaba en el uso de herramientas : utilizar programas de forma individual o combinada para realizar una tarea, en lugar de hacerlo manualmente, mediante subsistemas monolíticos autosuficientes o programas específicos de un solo uso.

Los autores contrastan herramientas de Unix como cat con conjuntos de programas más amplios utilizados por otros sistemas. ^{[ 6 ]}

El diseño del comando ` cat` es típico de la mayoría de los programas UNIX: implementa una función simple pero general que puede usarse en muchas aplicaciones diferentes (incluidas muchas no previstas por el autor original). Otros comandos se utilizan para otras funciones. Por ejemplo, existen comandos separados para tareas del sistema de archivos, como renombrar archivos, eliminarlos o conocer su tamaño. Otros sistemas, en cambio, agrupan estas funciones en un único comando de "sistema de archivos" con una estructura interna y un lenguaje de comandos propios. (El programa de copia de archivos PIP ^{[ 7 ]} que se encuentra en sistemas operativos como CP/M o RSX-11 es un ejemplo). Este enfoque no es necesariamente mejor ni peor, pero sin duda va en contra de la filosofía UNIX.

McIlroy , entonces director del Centro de Investigación de Ciencias de la Computación de Bell Labs e inventor de la tubería Unix , ^{[ 8 ]} resumió la filosofía Unix de la siguiente manera: ^{[ 3 ]}

Esta es la filosofía de Unix: escribir programas que hagan una sola cosa y la hagan bien. Escribir programas que trabajen juntos. Escribir programas que manejen flujos de texto , porque esa es una interfaz universal.

Más allá de estas afirmaciones, también ha enfatizado la simplicidad y el minimalismo en la programación Unix: ^{[ 3 ]}

La noción de "complejidades intrincadas y hermosas" es casi un oxímoron. Los programadores de Unix compiten entre sí por el reconocimiento de "simplicidad y belleza"  , un punto implícito en estas reglas, pero que vale la pena dejar claro.

Por el contrario, McIlroy ha criticado el Linux moderno por tener un software inflado , comentando que "los admiradores devotos han alimentado las bondades de Linux hasta un estado desalentador de obesidad ". ^{[ 9 ]} Contrasta esto con el enfoque anterior adoptado en Bell Labs al desarrollar y revisar Research Unix : ^{[ 10 ]}

Todo era pequeño... y me da mucha pena por Linux cuando veo lo pequeño que es. [...] La página del manual , que antes sí que era una página de manual , ahora es un pequeño volumen con mil opciones... Solíamos sentarnos en la sala de Unix y decir: "¿Qué podemos quitar? ¿Por qué existe esta opción?". A menudo se debe a alguna deficiencia en el diseño básico  ; no se dio con el punto de diseño correcto. En lugar de añadir una opción, piensa en qué te obligó a añadirla.

Como afirmó McIlroy, y como es generalmente aceptado en la comunidad Unix, siempre se ha esperado que los programas Unix sigan el concepto de DOTADIW, o "Haz una cosa y hazla bien". Si bien existen pocas fuentes sobre el acrónimo DOTADIW en Internet, se debate ampliamente durante el desarrollo y el empaquetado de nuevos sistemas operativos, especialmente en la comunidad Linux.

Patrick Volkerding , el líder del proyecto Slackware Linux , invocó este principio de diseño en una crítica a la arquitectura systemd , afirmando que "intentar controlar servicios, sockets, dispositivos, montajes, etc., todo dentro de un demonio va en contra del concepto Unix de hacer una cosa y hacerla bien". ^{[ 11 ]}

En su libro El arte de la programación Unix, publicado por primera vez en 2003, ^{[ 12 ]} Eric S. Raymond (defensor del código abierto y programador) resume la filosofía de Unix como " Mantenlo simple, estúpido ". ^{[ 13 ]} Proporciona una serie de reglas de diseño: ^{[ 3 ]}

• Construir programas modulares
• Escribir programas legibles
• Utilice composición
• Mecanismos separados de las políticas
• Escribe programas sencillos
• Escribir pequeños programas
• Escribir programas transparentes
• Escribir programas robustos
• Complique los datos cuando sea necesario, no el programa.
• Partir del conocimiento que esperan los usuarios potenciales
• Evite la salida innecesaria
• Escribe programas que fallen de una manera que sea fácil de diagnosticar.
• Valorar el tiempo del desarrollador por encima del tiempo de la máquina.
• Escribe programas abstractos que generen código en lugar de escribirlo manualmente.
• Prototipar el software antes de pulirlo.
• Redactar programas flexibles y abiertos.
• Hacer que el programa y los protocolos sean extensibles.

En 1994, Mike Gancarz , miembro del Grupo de Ingeniería Unix (UEG) de Digital Equipment Corporation , publicó *The UNIX Philosophy*, basado en su propio desarrollo de la adaptación de Unix ( Ultrix ) en DEC durante la década de 1980 y en conversaciones con sus colegas. También es miembro del equipo de desarrollo del Sistema X Window y autor de * Ultrix Window Manager * (uwm).

El libro se centra en la adaptación de UNIX a diferentes ordenadores durante las guerras de Unix de la década de 1980 y describe su filosofía de que la portabilidad debería ser más importante que la eficiencia del uso de interfaces no estándar para dispositivos de hardware y gráficos.

Los nueve "principios" básicos que él afirma que son importantes son:

1. Lo pequeño es hermoso.
2. Haz que cada programa haga bien una sola cosa.
3. Construye un prototipo lo antes posible.
4. Prioriza la portabilidad sobre la eficiencia.
5. Almacenar datos en archivos de texto plano .
6. Aprovecha el software a tu favor.
7. Utilice scripts de shell para aumentar el apalancamiento y la portabilidad.
8. Evite las interfaces de usuario cautivas.
9. Convierta cada programa en un filtro .

Richard P. Gabriel sugiere que una ventaja clave de Unix fue que incorporaba una filosofía de diseño que él denominó "lo peor es mejor", en la que la simplicidad tanto de la interfaz como de la implementación es más importante que cualquier otro atributo del sistema, incluyendo la corrección, la consistencia y la completitud. Gabriel argumenta que este estilo de diseño tiene ventajas evolutivas clave, aunque cuestiona la calidad de algunos resultados.

Por ejemplo, en sus inicios, Unix utilizaba un núcleo monolítico (lo que significa que los procesos de usuario ejecutaban las llamadas al sistema del núcleo directamente en la pila de usuario). Si se enviaba una señal a un proceso mientras este se encontraba bloqueado en una operación de E/S de larga duración en el núcleo, el manejo de la situación resultaba incierto. El manejador de señales no podía ejecutarse cuando el proceso estaba en modo núcleo, con datos confidenciales del núcleo en la pila.