В 1994 году Майк Ганцарз (англ.Mike Gancarz) объединил свой опыт работы в UNIX (он является членом команды по разработке системы X Window System) с высказываниями из прений, в которых он участвовал со своими приятелями программистами и людьми из других областей деятельности, так или иначе зависящих от UNIX, для создания Философии UNIX, которая сводится к 9 основным принципам:
Красиво — небольшое.
Пусть каждая программа делает что-то одно, но хорошо.
Стройте прототип программы как можно раньше.
Предпочитайте переносимость эффективности.
Храните данные в простых текстовых файлах.
Обратите преимущества программных средств себе на пользу.
Менее важные 10 принципов не снискали всеобщего признания в качестве частей философии UNIX и в некоторых случаях являлись предметом горячих споров (монолитное ядро против микроядра):
Позвольте пользователю настраивать окружение.
Делайте ядра операционной системы маленькими и легковесными.
Используйте нижний регистр и придерживайтесь кратких названий.
Не храните тексты программ в виде распечаток («Спасите деревья!»).
Не сообщайте пользователю об очевидном («Молчание — золото»).
Разбивайте сложные задачи на несколько простых, выполняемых параллельно («Мыслите „параллельно“»).
Объединённые части целого есть нечто большее, чем просто их сумма.
Ищите 90-процентное решение.
Если можно не добавлять новую функциональность, не добавляйте её («Чем хуже, тем лучше»).
Эрик С. Рэймонд (англ.Eric S. Raymond) в своей книге «Искусство программирования в UNIX» подытожил философию UNIX как широко используемую инженерную философию «Будь попроще, тупица» (Принцип KISS). Затем он описал, как эта обобщенная философия применима в качестве культурных норм UNIX. И это несмотря на то, что несложно найти несколько нарушений в следующей текущей философии UNIX:
Правило модульности: Пишите простые части, соединяемые понятными интерфейсами.
Правило ясности: Ясность лучше заумности.
Правило композиции: Разрабатывайте программы так, чтобы их можно было соединить с другими программами.
Правило разделения: Отделяйте правила (policy) от механизма (mechanism); отделяйте интерфейс от движка (engine).
Правило простоты: Нацельтесь на простоту; добавляйте сложность, только где необходимо.
Правило экономности: Пишите большую программу только когда другими средствами выполнить необходимую задачу не удастся.
Правило прозрачности: Разрабатывайте прозрачные программы для облегчения последующего пересмотра и отладки.
Правило надёжности: Надёжность — дитя прозрачности и простоты.
Правило представления: Храните знания в данных так, чтобы логика программы была тупой и надёжной.
Правило тишины: Если программе нечего сказать, пусть лучше молчит.
Правило восстановления: Если надо выйти из строя, делайте это шумно и как можно быстрее.
Правило экономии: Время программиста дорого; сократите его, используя машинное время.
Правило генерации: Избегайте ручного набора кода; при любом удобном случае пишите программы, которые бы писали программы.
Правило оптимизации: Сначала — опытный образец, потом — «причесывание». Добейтесь стабильной работы, только потом оптимизируйте.
Правило многообразия: Отвергайте все утверждения об «единственно правильном пути».
Правило расширяемости: Разрабатывайте для будущего. Оно наступит быстрее, чем вы думаете.
Большинство из этих норм принимается вне сообщества UNIX — даже если это было не так во времена, когда они впервые были применены в UNIX, то впоследствии это стало так. К тому же много правил не являются уникальными или оригинальными для сообщества UNIX. Тем не менее, приверженцы программирования в UNIX склоняются к тому, чтобы принять сочетание этих идей в качестве основ для стиля UNIX.
По мнению редакторов книги, подход UNIX приводит к появлению решений, сделанных наспех, без должного продумывания архитектуры, после чего данные решения канонизируются (enshrined), то есть объявляются вечной классикой. Например, таким решением, по их мнению, являются lock files — временные файлы без содержимого, создаваемые как пометка того факта, что какая-то программа находится в процессе исполнения.
X Window System была подвергнута критике за отделение в ней механизма (engine) от политики (policy), что привело к отсутствию в UNIX стандарта на политики управления пользовательским интерфейсом и большим затруднениям при разработке приложений, использующих GUI.
NFS была подвергнута критике за изначально порочный подход к архитектуре — попытку создать stateless файл-сервер при том, что это принципиально невозможно. Когда же невозможность поддержки некоторых важных вещей стала очевидной, к NFS прикрутили «костыль» под названием процесса lockd.
Но, в то же время, критикуемые в этой книге подходы, начатые в *NIX, плавно обосновываются и в ОС Microsoft Windows и Apple Mac OS.
M. D. Schroeder, D. D. Clark, J. H. Saltzer, D. H. Wells. Final Report of the Multics Kernel Design Project 1977
Joel Spolsky. Biculturalism (англ.). Joel on Software (14 декабря 2003). — Взгляд Windows‐разработчика на различия двух культур. Архивировано из первоисточника 5 февраля 2012.
Денис Смирнов. Классический UNIX-way или «компьютер для профессионала» (рус.) (2004). — Разъяснение базовых принципов Unix простым языком. Архивировано из первоисточника 5 февраля 2012.