UNIX философия

Философия Unix, созданная Кеном Томпсоном, представляет собой набор культурных норм и философских подходов к минималистской , модульной разработке программного обеспечения . Он основан на опыте ведущих разработчиков операционной системы Unix . Ранние разработчики Unix были важны в приведении понятий модульности и повторно использовать в программной инженерии практике, порождая " программные средства" движение. Со временем ведущие разработчики Unix (и программ, которые на нем работали) установили набор культурных норм для разработки программного обеспечения, норм, которые стали столь же важными и влиятельными, как и сама технология Unix; это было названо "философией Unix"."

Философия Unix делает акцент на построении простого, короткого, ясного, модульного и расширяемого кода, который может быть легко поддержан и перепрофилирован другими разработчиками, кроме его создателей. Философия Unix выступает за композиционность в отличие от монолитного дизайна .

Origin

Философия UNIX документирована Дугом Макилроем [1] в техническом журнале Bell System от 1978 года:

• 1 Сделайте так, чтобы каждая программа делала одну вещь хорошо. Чтобы сделать новую работу, создавайте заново, а не усложняйте старые программы, добавляя новые "функции".
• 2 Ожидайте, что выходные данные каждой программы станут входными данными другой, пока неизвестной программы. Не загромождайте вывод посторонней информацией. Избегайте строго столбчатых или двоичных форматов ввода. Не настаивайте на интерактивном вводе.
• 3 Разработка и создание программного обеспечения, даже операционных систем, которые должны быть опробованы на ранней стадии, в идеале в течение нескольких недель. Не стесняйтесь выбрасывать неуклюжие части и восстанавливать их.
• 4 Используйте инструменты вместо неквалифицированной помощи, чтобы облегчить задачу программирования, даже если вам придется сделать крюк, чтобы построить инструменты и ожидать, чтобы выбросить некоторые из них после того, как вы закончили их использование.

Позднее, в четверть века существования Unix (1994), он был обобщен Питером Х. Салусом: [1]

• Пишите программы, которые делают одно и делают это хорошо.
• Пишите программы для совместной работы.
• Пишите программы для обработки текстовых потоков, потому что это универсальный интерфейс.

В своей отмеченной наградами статье Unix 1974 года Ричи и Томпсон приводят следующие соображения по поводу дизайна:

• Облегчите написание, тестирование и запуск программ.
• Интерактивное использование вместо пакетной обработки .
• Экономия и элегантность дизайна за счет ограничений по размеру ("спасение через страдание").
• Само-поддерживая система: все програмное обеспечение Unix поддержано под Unix.

• Вся философия UNIX, кажется, держится в стороне от ассемблера .
• - Майкл Шон Махони

Среда программирования UNIX

В предисловии к книге 1984 года "среда программирования UNIX" Брайан Керниган и Роб Пайк , оба из Bell Labs, дают краткое описание дизайна Unix и философии Unix: [5]

   Несмотря на то, что система UNIX внедряет ряд инновационных программ и методов, ни одна программа или идея не дает ей хорошо работать. Вместо этого, что делает его эффективным, это подход к программированию, философия использования компьютера. Хотя эта философия не может быть записана в одном предложении, в основе ее лежит идея о том, что сила системы происходит больше от отношений между программами, чем от самих программ. Многие программы UNIX делают довольно тривиальные вещи в изоляции, но, в сочетании с другими программами, становятся общими и полезными инструментами. 

Авторы далее пишут, что их цель для этой книги - "донести философию программирования UNIX.

Проектирование программ в среде UNIX

В октябре 1984 года Брайан Керниган и Роб Пайк опубликовали статью под названием "проектирование программ в среде UNIX". В этой статье они критикуют аккрецию программных опций и функций , найденных в некоторых новых системах Unix, таких как 4.2 BSD и System V, и объясняют философию Unix программных средств, каждый из которых выполняет одну общую функцию:

   Большая часть мощи операционной системы UNIX происходит от стиля разработки программ, который делает программы простыми в использовании и, что более важно, легко сочетаются с другими программами. Этот стиль был назван использованием программных средств и в большей степени зависит от того, как программы вписываются в среду программирования и как они могут использоваться с другими программами, чем от того, как они разработаны внутри. [...] Этот стиль был основан на использовании инструментов: использование программ по отдельности или в сочетании для выполнения работы, а не вручную, монолитными самодостаточными подсистемами или специализированными разовыми программами. 

Авторы сравнивают инструменты Unix , такие как cat, с более крупными наборами программ, используемыми другими системами.

   Дизайн cat типичен для большинства программ UNIX: он реализует одну простую, но общую функцию, которая может быть использована во многих различных приложениях (в том числе многих, не предусмотренных оригинальным автором). Другие команды используются для других функций. Например, существуют отдельные команды для задач файловой системы, таких как переименование файлов, их удаление или определение их размера. Другие системы вместо этого объединяют их в одну команду "файловая система" с собственной внутренней структурой и командным языком. (The pip file copy program найденный на операционных системах как CP / M или RSX-11 являться примером.) Этот подход не обязательно хуже или лучше, но он определенно противоречит философии UNIX. 

Дуг Макилрой о программировании Unix

Макилрой, тогдашний глава Исследовательского центра Bell Labs Computing Sciences и изобретатель трубы Unix, резюмировал философию Unix следующим образом:]

   Это философия Unix: писать программы, которые делают одно и делают это хорошо. Пишите программы для совместной работы. Пишите программы для обработки текстовых потоков, потому что это универсальный интерфейс. 

Помимо этих утверждений, он также подчеркнул простоту и минимализм в программировании Unix: [1]

   Понятие "замысловатые и красивые сложности" является почти оксюмороном. Программисты Unix соперничают друг с другом за" простые и красивые " почести — пункт, который подразумевается в этих правилах, но вполне стоит сделать открытым. 

И наоборот, Макилрой критиковал современный Linux за то , что у него раздуто программное обеспечение, замечая, что "обожающие поклонники скормили Linux лакомства до удручающего состояния ожирения .[8] он сравнивает это с более ранним подходом, принятым в Bell Labs при разработке и пересмотре исследований Unix : [9]]

   Все было маленьким... и мое сердце замирает для Linux, когда я вижу его размер. [...] Страница руководства, которая действительно была страницей руководства, теперь является небольшим Томом с тысячью вариантов... Мы обычно сидели в комнате Unix и говорили: "что мы можем выбросить? Почему существует такой вариант?"Часто это происходит потому, что в базовом дизайне есть какой — то недостаток-вы не попали в правильную точку дизайна. Вместо добавления опции подумайте о том, что заставило вас добавить эту опцию. 

Делай одно и делай это хорошо

Как заявил Макилрой, и общепринятые во всем сообществе Unix, программы Unix всегда должны были следовать концепции DOTADIW, или "делать одну вещь и делать ее хорошо."Существуют ограниченные источники для аббревиатуры DOTADIW в интернете, но она подробно обсуждается во время разработки и упаковки новых операционных систем, особенно в сообществе Linux.

Патрик Волкердинг, руководитель проекта Slackware Linux, сослался на этот принцип проектирования в критике архитектуры systemd, заявив, что "пытается контролировать службы, сокеты, устройства, монтирования и т.д., все внутри одного демона летит в лицо концепции UNIX делать одну вещь и делать это хорошо."

17 Правил Unix от Eric Raymond

В своей книге The Art of Unix Programming, которая была впервые опубликована в 2003 году, [11] Эрик С. Реймонд, американский программист и защитник открытого исходного кода, обобщает философию Unix как принцип поцелуя "держите его простым, глупым."[12] он предоставляет ряд правил проектирования:

• Построение модульных программ
• Писать читаемые программы
• Использовать композицию
• Отделить механизмы от политики
• Писать простые программы
• Пишите небольшие программы
• Писать прозрачные программы
• Написать надежные программы
• Усложняйте данные при необходимости, а не программу
• Использование ожидаемых знаний потенциальных пользователей
• Избегайте ненужного вывода
• Написать программы, которые не в пути, который легко диагностировать
• Значение время разработчика в течение машинного времени
• Написать абстрактные программы, которые генерируют код вместо написания кода вручную
• Программное обеспечение прототипа перед полировать его
• Писать гибкие и открытые программы
• Сделайте программу и протоколы расширяемыми.

Mike Gancarz: философия UNIX

В 1994 году Майк Ганкарц (член команды, разработавшей систему X Window), опираясь на свой собственный опыт работы с Unix, а также обсуждения с другими программистами и людьми в других областях, которые зависели от Unix, создал философию UNIX, которая резюмирует ее в девяти основных принципах:

• Маленький красивый.
• Сделайте так, чтобы каждая программа делала одну вещь хорошо.
• Постройте прототип как можно скорее.
• Выберите удобоносимость над эффективностью.
• Хранить данные в плоских текстовых файлах .
• Используйте программное обеспечение в своих интересах.
• Используйте скрипты shell для увеличения кредитного плеча и переносимости.
• Избегайте захваченных пользовательских интерфейсов.
• Сделайте каждую программу фильтром .

"Чем хуже, тем лучше"

Главная статья: Чем хуже, тем лучше

Габриэль предполагает, что ключевым преимуществом Unix было то, что она воплощала в себе философию дизайна, которую он назвал "хуже—лучше", в которой простота как интерфейса, так и реализации важнее, чем любые другие атрибуты системы-включая правильность, последовательность и полноту. Габриэль утверждает, что этот стиль дизайна имеет ключевые эволюционные преимущества, хотя он сомневается в качестве некоторых результатов.

Например, в первые дни Unix использовал монолитное ядро (это означает, что пользовательские процессы выполняли все системные вызовы ядра в пользовательском стеке). Если сигнал был передан процессу, когда он был заблокирован при долгосрочном вводе-выводе в ядре, тогда что нужно делать? Следует ли задерживать сигнал, возможно, на долгое время (возможно, на неопределенный срок), пока ввод-вывод завершен? Обработчик сигнала не может быть выполнен, когда процесс находится в режиме ядра, с конфиденциальными данными ядра в стеке. Следует ли ядру вернуть системный вызов и сохранить его для последующего воспроизведения и перезапуска, предполагая, что обработчик сигнала завершится успешно?

В этих случаях Кен Томпсон и Деннис Ричи предпочитали простоту совершенству. Система Unix иногда возвращалась пораньше из системного вызова с ошибкой, указывающей на то, что она ничего не сделала—"Прерванный системный вызов" или номер ошибки 4 ( EINTR) в сегодняшних системах. Конечно, вызов был прерван, чтобы вызвать обработчик сигнала. Это может произойти только для нескольких длительных системных вызовов, таких как read(), write()open(), и select(). С положительной стороны, это сделало систему I/O много времен более простой конструировать и понять. Подавляющее большинство пользовательских программ никогда не были затронуты, потому что они не обрабатывали или не воспринимали сигналы, Кроме SIGINTи умрут сразу, если один из них был поднят. Для некоторых других программ - например, оболочек или текстовых редакторов, которые реагируют на нажатие клавиши управления заданиями,—к системным вызовам можно добавить небольшие оболочки, чтобы сразу же повторить вызов, если возникнет эта EINTRошибка. Таким образом, задача была решена простым способом.

Критика

В статье 1981 года , озаглавленной "правда о Unix: пользовательский интерфейс ужасен" [13], опубликованной в Datamation, Дон Норман критиковал философию дизайна Unix за отсутствие заботы о пользовательском интерфейсе. Основываясь на своем опыте в когнитивной науке и с точки зрения тогдашней философии когнитивной инженерии [4] , он сосредоточился на том, как конечные пользователи понимают и формируют личную когнитивную модель систем-или, в случае Unix, не понимают, в результате чего катастрофические ошибки (такие как потеря часа работы) слишком просты.

См. также

• Когнитивная инженерия
• Архитектура Unix
• Минимализм (вычислительный)
• Программная инженерия
• Хакерская этика
• Список философий разработки программного обеспечения
• Все это файл

Пруф

.catb.org/esr/writings/taoup/html/ch01s06.html

• .linfo.org/unix_philosophy.html
• marmaro.de/docs/studium/unix-phil/unix-phil.pdf
• .altlinux.org/
• nick-black.com/dankwiki/