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 a la hora de llevar los conceptos de modularidad y reutilización a la práctica de la ingeniería de software, lo que generó un movimiento de " herramientas de software ". Con el tiempo, los principales desarrolladores de Unix (y los programas que se ejecutaban en él) establecieron un conjunto de normas culturales para el desarrollo de software; estas normas se volvieron tan importantes e influyentes como la tecnología de Unix en sí, y se las ha denominado "filosofía Unix".
La filosofía Unix enfatiza la creación de código simple, compacto, claro, modular y extensible que pueda ser fácilmente mantenido y reutilizado por desarrolladores distintos de sus creadores. La filosofía Unix favorece la componibilidad en lugar del diseño monolítico .
La filosofía Unix está documentada por Doug McIlroy [1] en el Bell System Technical Journal de 1978: [2]
Más tarde, Peter H. Salus lo resumió 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 de Unix y la filosofía de Unix: [4]
Aunque el sistema UNIX introduce una serie de programas y técnicas innovadores, no hay un programa o idea que lo haga funcionar bien. Lo que lo hace eficaz es el enfoque de la programación, una filosofía de uso de la computadora. Aunque esa filosofía no se puede resumir en una sola frase, en su núcleo está la idea de que el poder de un sistema proviene más de las relaciones entre los programas que de los programas en sí. 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 con 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 titulado Program Design in the UNIX Environment (Diseño de programas en el entorno UNIX ) . En este artículo, critican la acumulación de opciones y características de los 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 de la potencia del sistema operativo UNIX proviene de un estilo de diseño de programas que hace que los programas sean fáciles de usar y, lo que es más importante, fáciles de combinar con otros programas. Este estilo se ha denominado uso de herramientas de software y depende más de cómo los programas encajan en el entorno de programación y de 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 : utilizar programas por separado o en combinación para realizar un trabajo, en lugar de hacerlo a mano, mediante subsistemas monolíticos autosuficientes o mediante programas especiales de un solo uso.
Los autores contrastan herramientas 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 se puede utilizar en muchas aplicaciones diferentes (incluidas muchas que no fueron previstas por el autor original). Otros comandos se utilizan para otras funciones. Por ejemplo, hay comandos separados para tareas del sistema de archivos, como renombrar archivos, eliminarlos o indicar su tamaño. Otros sistemas, en cambio, agrupan todo esto en un solo comando de "sistema de archivos" con una estructura interna y un lenguaje de comandos propios. (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 mejor o peor, 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 Bell Labs e inventor del Unix pipe , [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 que la hagan bien. Escribir programas que funcionen juntos. Escribir programas que gestionen 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: [1]
La noción de "complejidades intrincadas y hermosas" es casi un oxímoron. Los programadores de Unix compiten entre sí por el honor de ser "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 al Linux moderno por tener una hinchazón de software , señalando que "los admiradores adoradores han alimentado con las bondades 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 por Linux cuando veo el tamaño. [...] La página del manual , que en realidad solía ser una página de manual , ahora es un pequeño volumen, con mil opciones... Solíamos sentarnos en la Sala Unix y decir: "¿Qué podemos descartar? ¿Por qué existe esta opción?". A menudo se debe a que hay alguna deficiencia en el diseño básico: no se ha dado con el punto de diseño correcto. En lugar de agregar una opción, piense en lo que lo obligó a agregar esa opción.
Como afirmó McIlroy y es generalmente aceptado en toda la comunidad Unix, siempre se ha esperado que los programas Unix sigan el concepto de DOTADIW, o "Do One Thing And Do It Well" (Hacer una cosa y hacerla bien). Existen fuentes limitadas para el acrónimo DOTADIW en Internet, pero se habla mucho de él 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". [10]
En su libro El arte de programar en Unix , publicado por primera vez en 2003, [11] Eric S. Raymond (defensor del código abierto y programador) resume la filosofía de Unix como el principio KISS de "Manténgalo simple, estúpido". [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ó The UNIX Philosophy basándose en su propio desarrollo de un puerto Unix ( Ultrix ) en DEC en la década de 1980 y en conversaciones con 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 portabilidad de 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 él afirma que son importantes son:
Richard P. Gabriel sugiere que una ventaja clave de Unix era que encarnaba 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 son más importantes que cualquier otro atributo del sistema, incluidas la corrección, la coherencia y la integridad. Gabriel sostiene que este estilo de diseño tiene ventajas evolutivas clave, aunque cuestiona la calidad de algunos resultados.
Por ejemplo, en los primeros tiempos, Unix utilizaba un núcleo monolítico (lo que significa que los procesos de usuario realizaban llamadas al sistema del núcleo, todas en la pila del usuario). Si se enviaba una señal a un proceso mientras estaba bloqueado en una E/S de largo plazo en el núcleo, el manejo de la situación no estaba claro. El manejador de la señal no podía ejecutarse cuando el proceso estaba en modo núcleo, con datos sensibles del núcleo 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 formación en ciencia cognitiva y desde la perspectiva de la filosofía entonces vigente de la ingeniería cognitiva , [14] se centró en cómo los usuarios finales comprenden y forman un modelo cognitivo personal de los sistemas (o, en el caso de Unix, no logran comprender, con el resultado de que es demasiado fácil cometer errores desastrosos (como perder una hora de trabajo).
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 general, las grandes arquitecturas terminan siendo ineficaces e ineficientes.