La filosofía de 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 programas informáticos, lo que dio lugar a 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 el desarrollo de programas informáticos; estas normas llegaron a ser tan importantes e influyentes como la propia tecnología de Unix; esto se ha denominado "filosofía Unix".

La filosofía de Unix hace hincapié en la construcción de código simple, corto, claro, modular y extensible que pueda ser fácilmente mantenido y reutilizado por otros desarrolladores que no sean sus creadores. La filosofía de Unix favorece la componibilidad en oposición al diseño monolítico.

La filosofía de Unix está documentada por Douglas McIlroy^[1]​ en el Bell System Technical Journal de 1978:^[2]​

1. Haz que cada programa haga una cosa bien. Para hacer un nuevo trabajo, construye de nuevo en lugar de complicar los viejos programas añadiendo nuevas "características".
2. Espere que la salida de cada programa se convierta en la entrada de otro programa aún desconocido. No llene la salida con información extraña. Evite los formatos de entrada binarios o en columnas. No insista en la entrada interactiva.
3. Diseña y construye software, incluso sistemas operativos, para ser probados temprano, idealmente en semanas. No duden en tirar las partes torpes y reconstruirlas.
4. Usar herramientas en lugar de ayuda no especializada para aligerar una tarea de programación, incluso si tienes que desviarte para construir las herramientas y esperas tirar algunas de ellas después de haberlas usado.

Fue resumido más tarde por Peter H. Salus en A Quarter-Century of Unix (1994):^[1]​

• Escribe programas que hagan una cosa y la hagan bien.
• Escribe programas para trabajar juntos.
• Escribe programas para manejar flujos de texto, porque esa es una interfaz universal.

En su premiado trabajo de Unix de 1974, Ritchie y Thompson citan las siguientes consideraciones de diseño:^[3]​

• Facilita la escritura, la prueba y la ejecución de programas.
• Uso interactivo en lugar de procesamiento por lotes.
• Economía y elegancia de diseño debido a las limitaciones de tamaño ("salvación a través del sufrimiento").
• Sistema autosuficiente: todo el software de Unix se mantiene bajo Unix. 

Toda la filosofía de unix parece quedarse fuera del ensamblaje

Michael Sean Machoney

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 un número de programas y técnicas innovadoras, ningún programa o idea hace que funcione bien. En cambio, lo que lo hace efectivo es el enfoque de la programación, una filosofía de uso del ordenador. Aunque esta filosofía no puede ser escrita en una sola frase, en su corazón está la idea de que el poder de un sistema viene 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 de 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 documento, critican la acumulación de opciones y características de los programas que se encuentran en algunos sistemas Unix más recientes como el 4.2BSD y el 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 llamado el uso de herramientas de software, y depende más de cómo los programas encajan en el entorno de programación y cómo pueden ser utilizados 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 hacer un trabajo, en lugar de hacerlo a mano, por subsistemas monolíticos autosuficientes, o por programas especiales de una sola vez.

Los autores contrastan las herramientas de Unix, como cat, con las suites de programas más grandes utilizadas 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 ser utilizada en muchas aplicaciones diferentes (incluyendo muchas no 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, borrarlos, o decir cuán grandes son. Otros sistemas, en cambio, los agrupan en un solo comando de "sistema de archivos" con una estructura interna y un lenguaje de comandos propio. (El programa de copia de archivos PIP que se encuentra en sistemas operativos como CP/M o RSX-11 es un ejemplo). Este enfoque no es necesariamente peor o mejor, pero ciertamente va en contra de la filosofía del UNIX.

McIlroy, entonces jefe del Centro de Investigación de Ciencias de la Computación de Bell Labs, e inventor del Unix pipe,^[6]​ resumió la filosofía de Unix de la siguiente manera:^[1]​  

Esta es la filosofía de Unix: Escribir programas que hagan una cosa y la hagan bien. Escribir programas para trabajar juntos. Escribir programas que manejen flujos de texto, porque esa 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:^[1]​  

La noción de "complejidades intrincadas y bellas" es casi un oxímoron. Los programadores de Unix compiten entre sí por los honores de "simple y hermosa", un punto que está implícito en estas reglas, pero que bien vale la pena hacer evidente.

Por el contrario, McIlroy ha criticado el Linux moderno por tener un software inflado, remarcando que, "los admiradores adoradores han alimentado a Linux con golosinas a un estado descorazonador de obesidad".^[7]​ Él contrasta esto con el enfoque anterior tomado en los laboratorios Bell al desarrollar y revisar Research Unix:^[8]​  

Todo era pequeño... y mi corazón se hunde por Linux cuando veo su tamaño. La página del manual, que realmente solía ser una página de manual, es ahora un pequeño volumen, con mil opciones... Solíamos sentarnos en la sala de Unix diciendo, '¿Qué podemos tirar? ¿Por qué hay esta opción? A menudo es porque hay alguna deficiencia en el diseño básico - no le diste al punto de diseño correcto. En lugar de añadir una opción, piensa en lo que te obligó a añadir esa opción.

Como dijo McIlroy, y generalmente aceptado por 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 discute ampliamente durante el desarrollo y 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 del sistema, afirmando que, "intentar controlar servicios, enchufes, dispositivos, montajes, etc., todo dentro de un demonio va en contra del concepto de Unix de hacer una cosa y hacerla bien"^[9]​

En su libro El arte de la programación Unix, publicado por primera vez en 2003,^[10]​ Eric S. Raymond, un programador americano y defensor del código abierto, resume la filosofía Unix como el principio KISS de "Keep it Simple, Stupid".^[11]​ Él proporciona una serie de reglas de diseño:^[1]​

• Construye programas modulares
• Escribe programas legibles
• Usa la composición de uso
• Mecanismos separados de la política
• Escribe programas simples
• Escribe pequeños programas
• Escribe programas transparentes
• Escribe programas robustos
• Complicar los datos cuando sea necesario, no el programa
• Aprovechar los conocimientos esperados de los usuarios potenciales
• Evitar la salida innecesaria
• Escribe programas que fallan de una manera que es fácil de diagnosticar
• Valorar el tiempo del desarrollador sobre el tiempo de la máquina
• Escribe programas abstractos que generen código en lugar de escribir código a mano
• Prototipo de software antes de pulirlo
• Escribe programas flexibles y abiertos
• Hacer el programa y los protocolos extensibles.

En 1994, Mike Gancarz (miembro del equipo que diseñó el Sistema X Window), se basó en su propia experiencia con Unix, así como en discusiones con otros programadores y personas de otros campos que dependían de Unix, para producir La Filosofía de UNIX que la resume en nueve preceptos primordiales:

1. Lo pequeño es hermoso.
2. Haz que cada programa haga una cosa bien.
3. Construya un prototipo lo antes posible.
4. Elija la portabilidad en lugar de la eficiencia.
5. Almacenar los datos en archivos de texto plano.
6. Utiliza el aprovechamiento del software a tu favor.
7. Usar scripts de shell para aumentar el apalancamiento y la portabilidad.
8. Evite las interfaces de usuario cautivas.
9. Haz de cada programa un filtro.

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, incluyendo la corrección, la consistencia 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 llevaban a cabo llamadas del sistema del núcleo en la pila de usuarios). Si se entregaba una señal a un proceso mientras estaba bloqueado en una I/O a largo plazo en el núcleo, ¿qué se debía hacer? ¿Debería retrasarse la señal, posiblemente durante mucho tiempo (tal vez indefinidamente) mientras se completa la I/O? El manejador de señales no podría ser ejecutado cuando el proceso estuviera en modo kernel, con datos sensibles del kernel en la pila. ¿Debería el núcleo hacer una copia de seguridad de la llamada al sistema, y almacenarla, para su reproducción y reinicio posterior, asumiendo que el manejador de señales se complete con éxito?

En estos casos, Ken Thompson y Dennis Ritchie favorecieron la simplicidad sobre la perfección. El sistema Unix ocasionalmente regresaba antes de tiempo de una llamada al sistema con un error que indicaba que no había hecho nada - la "Llamada al Sistema Interrumpido", o un error número 4 (EINTR) en los sistemas actuales. Por supuesto que la llamada había sido abortada para llamar al manejador de la señal. Esto sólo podía suceder para un puñado de llamadas de sistema de larga duración como read(), write(), open() y select(). En el lado positivo, esto hizo que el sistema de I/O fuera mucho más simple de diseñar y entender. La gran mayoría de los programas de usuario nunca se vieron afectados porque no manejaban o experimentaban otras señales aparte de SIGINT y morían inmediatamente si uno se levantaba. Para los otros pocos programas, como los shells o los editores de texto que responden a las teclas de control de trabajo, se podían añadir pequeños envoltorios a las llamadas del sistema para reintentar la llamada de inmediato si se producía este error EINTR. De esta manera, el problema se resolvió de una manera simple.

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.^[12]​ Escribiendo desde su formación en ciencia cognitiva y desde la perspectiva de la entonces actual filosofía 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 lo entienden, con el resultado de que los errores desastrosos (como perder una hora de trabajo) son demasiado fáciles.

• Ingeniería cognitiva
• Arquitectura de Unix
• Minimalismo (informática)
• Ingeniería de software
• Hacker ético
• Lista de filosofías de desarrollo del software
• Todo es un archivo

• The Unix Programming Environment by Brian Kernighan and Rob Pike, 1984
• Program Design in the UNIX Environment – The paper by Pike and Kernighan that preceded the book.
• Notes on Programming in C, Rob Pike, September 21, 1989
• A Quarter Century of Unix, Peter H. Salus, Addison-Wesley, May 31, 1994 (ISBN 0-201-54777-5)
• Philosophy — from The Art of Unix Programming, Eric S. Raymond, Addison-Wesley, September 17, 2003 (ISBN 0-13-142901-9)
• Final Report of the Multics Kernel Design Project by M. D. Schroeder, D. D. Clark, J. H. Saltzer, and D. H. Wells, 1977.
• The UNIX Philosophy, Mike Gancarz, ISBN 1-55558-123-4

• Basics of the Unix Philosophy – by Catb.org
• The Unix Philosophy: A Brief Introduction – by The Linux Information Project (LINFO)
• The Unix Philosophy
• Why the Unix Philosophy still matters