Filosofia unix

Ken Thompson y Dennis Ritchie, los principales defensores de la filosofía Unix

La filosofía Unix, originada por Ken Thompson, es un conjunto de normas culturales y enfoques filosóficos para el desarrollo de software minimalista y modular. Se basa en la experiencia de los principales desarrolladores del sistema operativo Unix. Los primeros desarrolladores de Unix fueron importantes para llevar los conceptos de modularidad y reutilización a la práctica de la ingeniería de software, generando una "herramientas de software" movimienot. Con el tiempo, los principales desarrolladores de Unix (y 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 de Unix, y se han denominado la 'filosofía de Unix'.

La filosofía de Unix enfatiza la creación de código simple, compacto, claro, modular y extensible que los desarrolladores que no sean sus creadores puedan mantener y reutilizar fácilmente. La filosofía de Unix favorece la composición frente al diseño monolítico.

Origen

La filosofía Unix está documentada por Doug McIlroy en Bell System Technical Journal desde 1978:

1. Haz que cada programa haga una cosa bien. Para hacer un nuevo trabajo, construir de nuevo en lugar de complicar los viejos programas añadiendo nuevas "características".
2. Espere la salida de cada programa para convertirse en la entrada a otro, aún desconocido, programa. No disminuya la salida con información extraneous. Evite los formatos de entrada rigurosamente columnar o binario. No insistas en la entrada interactiva.
3. Diseño y construcción de software, incluso sistemas operativos, para ser probado temprano, idealmente dentro de semanas. No dudes en tirar las partes torpes y reconstruirlas.
4. Utilice herramientas en preferencia a la ayuda no calificada para aclarar una tarea de programación, incluso si usted tiene que desviarse para construir las herramientas y esperar lanzar algunas de ellas después de que haya terminado de utilizarlas.

Posteriormente, Peter H. Salus lo resumió en A Quarter-Century of Unix (1994):

• Escribe programas que hagan una cosa y lo hagan bien.
• Escribir programas para trabajar juntos.
• Escribe programas para manejar secuencias de texto, porque es una interfaz universal.

En su galardonado artículo sobre Unix de 1974, Ritchie y Thompson citan las siguientes consideraciones de diseño:

• Haga que sea fácil escribir, probar y ejecutar programas.
• Uso interactivo en lugar de procesamiento por lotes.
• Economía y elegancia del diseño debido a limitaciones de tamaño ("salvación a través del sufrimiento").
• Sistema de autoapoyo: todo el software Unix se mantiene bajo Unix.

El entorno de programación UNIX

En su prefacio al libro de 1984, El entorno de programación UNIX, Brian Kernighan y Rob Pike, ambos de Bell Labs, dan una breve descripción del diseño y la filosofía de Unix:

Rob Pike, coautor de El entorno de programación UNIX

A pesar de que el sistema UNIX introduce una serie de programas y técnicas innovadores, ningún programa o idea individual hace que funcione bien. En cambio, lo que lo hace efectivo es el enfoque de programación, una filosofía de usar el ordenador. Aunque esa filosofía no puede ser escrita en una sola frase, en su corazón es la idea de que el poder de un sistema viene más de las relaciones entre los programas que de los propios programas. Muchos programas UNIX hacen cosas muy triviales en aislamiento, 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 de UNIX".

Diseño de programas en el entorno UNIX

Brian Kernighan ha escrito en detalle sobre la filosofía Unix

En octubre de 1984, Brian Kernighan y Rob Pike publicaron un artículo titulado Diseño de programas en el entorno UNIX. En este documento, critican la acumulación de opciones y funciones 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:

Gran parte de la potencia del sistema operativo UNIX proviene de un estilo de diseño de programas que facilita el uso de programas y, más importante, fácil de combinar con otros programas. Este estilo ha sido llamado el 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 basó en el uso de herramientas: el uso de programas por separado o en combinación para conseguir un trabajo hecho, en lugar de hacerlo a mano, por subsistemas autosuficientes monolíticos, o por programas especiales de una sola vez.

Los autores contrastan las herramientas de Unix como cat con conjuntos de programas más grandes utilizados por otros sistemas.

El diseño de gato 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 (incluyendo muchos no imaginados 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, borrarlos o decir lo grande que son. Otros sistemas, en cambio, agrupan estos en un único comando "sistema de ficheros" con una estructura interna y un lenguaje de comando propio. (El programa de copia de archivo PIP encontrado en sistemas operativos como CP/M o RSX-11 es un ejemplo.) Ese enfoque no es necesariamente peor o mejor, pero ciertamente está en contra de la filosofía UNIX.

Doug McIlroy sobre programación Unix

Doug McIlroy (izquierda) con Dennis Ritchie

McIlroy, entonces director del Centro de Investigación de Ciencias de la Computación de Bell Labs e inventor de la tubería Unix, resumió la filosofía de Unix de la siguiente manera:

Esta es la filosofía Unix: Escribe programas que hacen una cosa y lo hacen bien. Escribir programas para trabajar juntos. Escribe programas para manejar secuencias de texto, porque es una interfaz universal.

Más allá de estas declaraciones, también ha enfatizado la simplicidad y el minimalismo en la programación de Unix:

La noción de "complejidades intrincadas y hermosas" es casi un oxymoron. Los programadores Unix vie con los otros para honores "simples y hermosos" — un punto que es implícito en estas reglas, pero vale la pena hacer sobrecosto.

Por el contrario, McIlroy ha criticado el Linux moderno por tener un software inflado, señalando que "admiradores adoradores han alimentado a los golosinas de Linux hasta un estado desalentador de obesidad". Él contrasta esto con el enfoque anterior adoptado en Bell Labs al desarrollar y revisar Research Unix:

Todo era pequeño... y mi corazón se hunde para Linux cuando veo el tamaño de ella. [...] La página manual, que realmente era un manual página, es ahora un pequeño volumen, con mil opciones... Solíamos sentarnos en la Sala Unix diciendo: "¿Qué podemos tirar? ¿Por qué hay esta opción?' Es a menudo porque hay alguna deficiencia en el diseño básico — realmente no golpeó el punto de diseño adecuado. En lugar de agregar una opción, piensa en lo que te obligaba a añadir esa opción.

Haz una cosa y hazla bien

Como afirma McIlroy, y generalmente aceptado en toda la comunidad de Unix, siempre se ha esperado que los programas de Unix sigan el concepto de DOTADIW, o "Haz una cosa y hazla bien". Existen 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 de systemd, afirmando que, "intentar controlar servicios, sockets, dispositivos, montajes, etc., todo dentro de un demonio va en contra del concepto de Unix de hacer una cosa y hacerlo bien."

Las 17 reglas de Unix de Eric Raymond

En su libro El arte de la programación de Unix, que se publicó por primera vez en 2003, Eric S. Raymond (programador y defensor del código abierto) resume la filosofía de Unix como Principio KISS de "Keep it Simple, estúpido." Proporciona una serie de reglas de diseño:

• Programas modulares de construcción
• Escribir programas legibles
• Composición de uso
• Mecanismos separados de la política
• Escribir programas simples
• Escribir pequeños programas
• Escribir programas transparentes
• Escribir programas robustos
• Hacer los datos complicados cuando sea necesario, no el programa
• Construir los conocimientos esperados de los usuarios potenciales
• Evite la salida innecesaria
• Escribir programas que fallan de una manera que es fácil de diagnosticar
• Tiempo de desarrollo de valor con el tiempo de máquina
• Escribe programas abstractos que generan código en lugar de escribir código a mano
• Software de prototipo antes de pulirlo
• Escribir programas flexibles y abiertos
• Haga extensible el programa y los protocolos.

Mike Gancarz: la filosofía UNIX

En 1994, Mike Gancarz, miembro de Unix Engineering Group (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 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 enfoca en migrar UNIX a diferentes computadoras 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 hardware y dispositivos gráficos.

Los nueve "principios" básicos él dice ser importante son

1. Pequeña es hermosa.
2. Haz que cada programa haga una cosa bien.
3. Construye un prototipo lo antes posible.
4. Elija portabilidad sobre eficiencia.
5. Almacene datos en archivos de texto plano.
6. Utilice el apalancamiento de software para su ventaja.
7. Utilice scripts de shell para aumentar el apalancamiento y la portabilidad.
8. Evite las interfaces de usuario cautivas.
9. Haz que cada programa sea un filtro.

"Peor es mejor"

Richard P. Gabriel sugiere que una ventaja clave de Unix era que encarnaba una filosofía de diseño que él denominó "peor es mejor", en la que la simplicidad de la interfaz y el la implementación son más importantes que cualquier otro atributo del sistema, incluida la corrección, la consistencia y la integridad. Gabriel argumenta que este estilo de diseño tiene ventajas evolutivas clave, aunque cuestiona la calidad de algunos resultados.

Por ejemplo, en los primeros días, Unix usaba un núcleo monolítico (lo que significa que los procesos de usuario realizaban llamadas al sistema del núcleo en la pila del usuario). Si se entregó una señal a un proceso mientras estaba bloqueado en una E/S a largo plazo en el núcleo, ¿qué se debe hacer? ¿Debe retrasarse la señal, posiblemente durante mucho tiempo (tal vez indefinidamente) mientras se completa la E/S? El controlador de señales no se pudo ejecutar cuando el proceso estaba en modo kernel, con datos confidenciales del kernel en la pila. ¿Debería el kernel revertir la llamada al sistema y almacenarla para reproducirla y reiniciarla más tarde, suponiendo que el controlador de señales se complete con éxito?

En estos casos, Ken Thompson y Dennis Ritchie preferían la simplicidad a la perfección. En ocasiones, el sistema Unix regresaba antes de una llamada al sistema con un error que indicaba que no había hecho nada: la "Llamada al sistema interrumpida" o un error número 4 (EINTR) en el día de hoy& #39;s sistemas. Por supuesto, la llamada había sido abortada para llamar al manejador de señales. Esto solo podría suceder para un puñado de llamadas al sistema de ejecución prolongada, como read(), write(), open() y seleccionar(). En el lado positivo, esto hizo que el sistema de E/S fuera mucho más fácil de diseñar y comprender. La gran mayoría de los programas de usuario nunca se vieron afectados porque no manejaban ni experimentaban señales distintas de SIGINT y morirían de inmediato si se activaba una. Para los pocos otros programas, cosas como shells o editores de texto que responden a las pulsaciones de teclas de control de trabajo, se pueden agregar pequeños envoltorios a las llamadas del sistema para volver a intentar la llamada de inmediato si se genera este error EINTR. Por lo tanto, el problema se resolvió de una manera simple.

Crítica

En un artículo de 1981 titulado "La verdad sobre Unix: La interfaz de usuario es horrible" 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 filosofía actual de la ingeniería cognitiva, se centró en cómo los usuarios finales comprenden y forman un modelo cognitivo personal de sistemas o, en el caso de Unix, no logran comprender, con el resultado de que los errores desastrosos (como perder una hora de trabajo) son demasiado fáciles.