La filosofía Unix , originada por Ken Thompson , es un conjunto de normas culturales y enfoques filosóficos para el desarrollo de software modular y minimalista . Se basa en la experiencia de los principales desarrolladores del sistema operativo Unix . Los primeros desarrolladores de Unix fueron importantes al incorporar los conceptos de modularidad y reutilización a la práctica de la ingeniería de software, generando un movimiento de " herramientas de software ". Con el tiempo, los principales desarrolladores de Unix (y de los programas que se ejecutaban en él) establecieron un conjunto de normas culturales para desarrollar software; Estas normas se volvieron tan importantes e influyentes como la propia tecnología Unix, y han sido denominadas la "filosofía Unix".
La filosofía Unix enfatiza la construcción de código simple, compacto, claro, modular y extensible que pueda ser mantenido y reutilizado fácilmente por desarrolladores distintos de sus creadores. La filosofía Unix favorece la componibilidad frente al diseño monolítico .
La filosofía Unix está documentada por Doug McIlroy [1] en el Bell System Technical Journal de 1978: [2]
Posteriormente fue resumido por Peter H. Salus en Un cuarto de siglo de Unix (1994): [1]
En su artículo sobre Unix de 1974, Ritchie y Thompson citan las siguientes consideraciones de diseño: [3]
En su prefacio al libro de 1984, The UNIX Programming Environment , Brian Kernighan y Rob Pike , ambos de Bell Labs , dan una breve descripción del diseño y la filosofía de Unix: [4]
Aunque el sistema UNIX introduce una serie de programas y técnicas innovadores, ningún programa o idea lo hace funcionar bien. Más bien, lo que lo hace efectivo es el enfoque de la programación, una filosofía de uso de la computadora. Aunque esa filosofía no se puede escribir en una sola frase, en el fondo está la idea de que el poder de un sistema proviene más de las relaciones entre programas que de los programas mismos. Muchos programas UNIX hacen cosas bastante triviales 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". [4]
En octubre de 1984, Brian Kernighan y Rob Pike publicaron un artículo llamado 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 Unix de las herramientas de software, cada una de las cuales realiza una función general: [5]
Gran parte del poder del sistema operativo UNIX proviene de un estilo de diseño de programas que los hace fáciles de usar y, lo que es más importante, fáciles de combinar con otros programas. A este estilo se le ha denominado uso de herramientas de software , y depende más de cómo encajan los programas en el entorno de programación y cómo se pueden utilizar con otros programas que de cómo están diseñados internamente. [...] Este estilo se basaba en el uso de herramientas : usar programas por separado o en combinación para realizar un trabajo, en lugar de hacerlo a mano, mediante subsistemas monolíticos autosuficientes o con propósitos especiales, de una sola vez. programas.
Los autores contrastan las herramientas de Unix como cat con conjuntos de programas más grandes utilizados por otros sistemas. [5]
El diseño de 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 cambiar el nombre de los archivos, eliminarlos o indicar su tamaño. Otros sistemas, en cambio, los agrupan en un único comando de "sistema de archivos" con una estructura interna y un lenguaje de comando propio. (El programa de copia de archivos PIP [6] que se encuentra en sistemas operativos como CP/M o RSX-11 es un ejemplo). Ese enfoque no es necesariamente peor o mejor, pero ciertamente va en contra de la filosofía UNIX.
_Receiving_Japan_Prize.jpeg/1280px-Dennis_Ritchie_(right)_Receiving_Japan_Prize.jpeg)
McIlroy , entonces director del Centro de Investigación de Ciencias de la Computación de los Laboratorios Bell e inventor del tubo Unix , [7] resumió la filosofía Unix de la siguiente manera: [1]
Ésta es la filosofía de Unix: escribir programas que hagan una cosa y la hagan bien. Escribir programas para trabajar juntos. Escriba programas para manejar flujos de texto , porque es una interfaz universal.
Más allá de estas afirmaciones, también ha enfatizado la simplicidad y el minimalismo en la programación Unix: [1]
La noción de "complejidades intrincadas y hermosas" es casi un oxímoron. Los programadores de Unix compiten entre sí por honores "simples y hermosos", un punto que está implícito en estas reglas, pero que vale la pena dejar en claro.
Por el contrario, McIlroy ha criticado el Linux moderno por tener un software inflado , señalando que "los admiradores han alimentado las delicias de Linux hasta un estado desalentador de obesidad ". [8] Contrasta esto con el enfoque anterior adoptado en Bell Labs al desarrollar y revisar Research Unix : [9]
Todo era pequeño... y mi corazón se hunde ante Linux cuando veo su tamaño. [...] La página del manual , que en realidad solía ser una página de manual , ahora es un volumen pequeño, con mil opciones... Solíamos sentarnos en la Sala Unix diciendo: '¿Qué podemos tirar? ¿Por qué existe esta opción? A menudo se debe a que hay alguna deficiencia en el diseño básico: realmente no llegaste al punto de diseño correcto. En lugar de agregar una opción, piense en lo que lo obligó a agregar esa opción.
Como lo afirmó McIlroy, y generalmente aceptado en toda la comunidad Unix, siempre se ha esperado que los programas Unix sigan el concepto de DOTADIW, o "Haz una cosa y hazla bien". Hay fuentes limitadas para el acrónimo DOTADIW en Internet, pero se analiza extensamente durante el desarrollo y empaquetado de nuevos sistemas operativos, especialmente en la comunidad Linux.
Patrick Volkerding , líder del proyecto de Slackware Linux , invocó este principio de diseño en una crítica a la arquitectura systemd , afirmando que "intentar controlar servicios, sockets, dispositivos, soportes, etc., todo dentro de un demonio va en contra del Concepto Unix de hacer una cosa y hacerlo bien." [10]
En su libro The Art of Unix Programming , publicado por primera vez en 2003, [11] Eric S. Raymond (programador y defensor del código abierto) resume la filosofía Unix como el principio KISS de "Keep it Simple, Stupid". [12] Proporciona una serie de reglas de diseño: [1]
En 1994, Mike Gancarz, miembro del Grupo de Ingeniería Unix (UEG) de Digital Equipment Corporation , publicó La filosofía UNIX basada en su propio desarrollo de puerto Unix ( Ultrix ) en DEC en la década de 1980 y en discusiones con colegas. También es miembro del equipo de desarrollo de X Window System y autor de Ultrix Window Manager (uwm).
El libro se centra en portar UNIX a diferentes computadoras durante las guerras 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 hardware y dispositivos gráficos.
Los nueve "principios" básicos que afirma ser importantes son
Richard P. Gabriel sugiere que una ventaja clave de Unix era que incorporaba una filosofía de diseño que denominó "peor es mejor", en la que la simplicidad tanto de la interfaz como de la implementación son más importantes que cualquier otro atributo del sistema, incluida la corrección, coherencia y plenitud. Gabriel sostiene que este estilo de diseño tiene ventajas evolutivas clave, aunque cuestiona la calidad de algunos resultados.
Por ejemplo, en sus inicios Unix usaba un kernel monolítico (lo que significa que los procesos del usuario realizaban llamadas al sistema del kernel en la pila del usuario). Si se entregaba una señal a un proceso mientras estaba bloqueado en una E/S de largo plazo en el kernel, el manejo de la situación no estaba claro. El controlador de señales no se pudo ejecutar cuando el proceso estaba en modo kernel, con datos confidenciales del kernel en la pila.
En un artículo de 1981 titulado "La verdad sobre Unix: La interfaz de usuario es horrible " [13] publicado en Datamation , Don Norman criticó la filosofía de diseño de Unix por su falta de preocupación por la interfaz de usuario. Escribiendo desde su experiencia en ciencia cognitiva y desde la perspectiva de la entonces vigente filosofía de la ingeniería cognitiva , [14] se centró en cómo los usuarios finales comprenden y forman un modelo cognitivo personal de sistemas o, en el caso de Unix, fallan. de entender, con el resultado de que errores desastrosos (como perder una hora de trabajo) son muy fáciles.
En el podcast On the Metal, Jonathan Blow criticó la filosofía UNIX por considerarla obsoleta. [15] Sostuvo que unir herramientas modulares da como resultado programas muy ineficientes. Dice que la filosofía UNIX sufre problemas similares a los de los microservicios : sin una supervisión global, las grandes arquitecturas acaban siendo ineficaces e ineficientes.