В 1994 году Майк Ганцарз (англ.Mike Gancarz) объединил свой опыт работы в Unix (он является членом команды по разработке системы X Window System) с высказываниями из прений, в которых он участвовал со своими приятелями-программистами и людьми из других областей деятельности, так или иначе зависящих от Unix, для создания Философии Unix, которая сводится к 9 основным принципам:
Красиво — небольшое.
Пусть каждая программа делает что-то одно, но хорошо.
Стройте прототип программы как можно раньше.
Предпочитайте переносимость эффективности.
Храните данные в простых текстовых файлах.
Извлекайте пользу из уже существующих программных решений.
Используйте скриптовые языки для уменьшения трудозатрат и улучшения переносимости.
Избегайте пользовательских интерфейсов, ограничивающих возможности пользователя по взаимодействию с системой.
Делайте каждую программу «фильтром».
Менее важные 10 принципов не снискали всеобщего признания в качестве частей философии Unix, и в некоторых случаях являлись предметом горячих споров (монолитное ядро против микроядра):
Позвольте пользователю настраивать окружение.
Делайте ядра операционной системы маленькими и легковесными.
Используйте нижний регистр и придерживайтесь кратких названий.
Не храните тексты программ в виде распечаток («Спасите деревья!»).
Не сообщайте пользователю об очевидном («Молчание — золото»).
Разбивайте сложные задачи на несколько простых, выполняемых параллельно («Мыслите „параллельно“»).
Объединённые части целого есть нечто большее, чем просто их сумма.
Эрик Рэймонд (англ.Eric S. Raymond) в книге «Искусство программирования в Unix» подытожил философию Unix как широко используемую инженерную философию «Делай это проще, глупец» (принцип KISS). Затем он описал, как эта обобщённая философия применима в качестве культурных норм Unix. И это несмотря на то, что несложно найти несколько нарушений в следующей текущей философии Unix:
Правило модульности: Пишите простые части, соединяемые понятными интерфейсами.
Правило ясности: Ясность лучше заумности.
Правило композиции: Разрабатывайте программы так, чтобы их можно было соединить с другими программами.
Правило разделения: Отделяйте правила (policy) от механизма (mechanism); отделяйте интерфейс от движка (engine).
Правило простоты: Нацельтесь на простоту; добавляйте сложность, только где необходимо.
Правило экономности: Пишите большую программу только когда другими средствами выполнить необходимую задачу не удастся.
Правило прозрачности: Разрабатывайте прозрачные программы для облегчения последующего пересмотра и отладки.
Правило надёжности: Надёжность — дитя прозрачности и простоты.
Правило представления: Храните знания в данных так, чтобы логика программы была тупой и надёжной.
Правило наименьшего удивления: При разработке интерфейса всегда делайте так, чтобы привычные элементы интерфейса выполняли привычные функции.
Правило тишины: Если программе нечего сказать, пусть лучше молчит.
Правило восстановления: Если программа должна аварийно завершиться, делайте это шумно и как можно быстрее.
Правило экономии: Время программиста дорого; сократите его, используя машинное время.
Правило генерации: Избегайте ручного набора кода; при любом удобном случае пишите программы, которые бы писали программы.
Правило оптимизации: Сначала — опытный образец, потом — «причесывание». Добейтесь стабильной работы, только потом оптимизируйте.
Правило многообразия: Отвергайте все утверждения о «единственно правильном пути».
Правило расширяемости: Разрабатывайте для будущего. Оно наступит быстрее, чем вы думаете.
Большинство из этих норм принимается вне сообщества Unix — даже если это было не так во времена, когда они впервые были применены в Unix, то впоследствии это стало так. К тому же много правил не являются уникальными или оригинальными для сообщества Unix. Тем не менее, приверженцы программирования в Unix склоняются к тому, чтобы принять сочетание этих идей в качестве основ для стиля Unix.
Философия UNIX критиковалась в книге «The UNIX-HATERS Handbook», изданной в начале 1990-х годов.
По мнению редакторов книги, подход Unix приводит к появлению решений, сделанных наспех, без должного продумывания архитектуры, после чего данные решения канонизируются (enshrined), то есть объявляются вечной классикой. Например, таким решением, по их мнению, являются lock files — временные файлы без содержимого, создаваемые как пометка того факта, что какая-то программа находится в процессе исполнения.
X Window System была подвергнута критике за отделение в ней механизма (engine) от политики (policy), что привело к отсутствию в UNIX стандарта на политики управления пользовательским интерфейсом и большим затруднениям при разработке приложений, использующих GUI.
NFS была подвергнута критике за изначально порочный подход к архитектуре — попытку создать stateless файл-сервер при том, что это принципиально невозможно. Когда же невозможность поддержки некоторых важных вещей стала очевидной, к NFS прикрутили «костыль» под названием процесса lockd.
Но, в то же время, критикуемые в этой книге подходы, начатые в *NIX, плавно обосновываются и в ОС Microsoft Windows и Apple Mac OS.
Joel Spolsky.Biculturalism(англ.). Joel on Software (14 декабря 2003). — Взгляд Windows‐разработчика на различия двух культур. Дата обращения: 26 февраля 2006. Архивировано 5 февраля 2012 года.