Войти
Кен Томпсон и Деннис Ритчи, ключевые сторонники философии Unix Философия Unix, созданная Кеном Томпсоном, представляет собой набор культурных норм и философских подходов к минимализму, модульности разработка программного обеспечения. Он основан на опыте ведущих разработчиков операционной системы Unix . Ранние разработчики Unix сыграли важную роль в внедрении концепций модульности и возможности повторного использования в практику разработки программного обеспечения, что породило движение «программные инструменты ». Со временем ведущие разработчики Unix (и программ, которые на нем работают) установили ряд культурных норм для разработки программного обеспечения; эти нормы стали такими же важными и влиятельными, как и сама технология Unix; это было названо «философией Unix».
Философия Unix делает упор на построении простого, короткого, понятного, модульного и расширяемого кода, который может легко поддерживаться и перепрофилироваться разработчиками, не являющимися его создателями. Философия Unix отдает предпочтение компоновке в отличие от монолитной конструкции.
Философия Unix задокументирована Дугом Макилроем в Bell System Technical Журнал за 1978 год:
Это было позже резюмировано Питером Х. Салусом в «Четверть века Unix» (1994):
В своей отмеченной наградами статье Unix 1974 года Ричи и Томпсон процитируйте следующие соображения дизайна:
Вся философия UNIX, кажется, остается вне ассемблер.
— Микрофон Хаэль Шон Махони
Роб Пайк, соавтор Среда программирования UNIX В своем предисловии к книге 1984 года Среда программирования UNIX, Брайан Керниган и Роб Пайк, оба из Bell Labs, дают краткое описание конструкции Unix и философии Unix:
Хотя В системе UNIX представлен ряд новаторских программ и методов, и ни одна программа или идея не заставит их работать хорошо. Напротив, то, что делает его эффективным, - это подход к программированию, философия использования компьютера. Хотя эту философию нельзя описать одним предложением, в ее основе лежит идея о том, что мощь системы больше зависит от взаимоотношений между программами, чем от самих программ. Многие программы UNIX делают довольно тривиальные вещи изолированно, но в сочетании с другими программами становятся общими и полезными инструментами.
Далее авторы пишут, что их цель в этой книге - «передать философию программирования UNIX».
Брайан Керниган подробно написал о философии Unix В октябре 1984 года Брайан Керниган и Роб Пайк опубликовали статью под названием «Проектирование программ в среде UNIX». В этой статье они критикуют расширение программных опций и функций, обнаруженных в некоторых новых системах Unix, таких как 4.2BSD и System V, и объясняют философию программных средств Unix, каждый из которых выполняет одна общая функция:
Большая часть возможностей операционной системы UNIX проистекает из стиля разработки программ, который делает программы простыми в использовании и, что более важно, легко комбинируется с другими программами. Этот стиль получил название использования программных инструментов и больше зависит от того, как программы вписываются в среду программирования и как их можно использовать с другими программами, чем от того, как они разработаны внутри компании. [...] Этот стиль был основан на использовании инструментов: использование программ по отдельности или в комбинации для выполнения работы, а не выполнение ее вручную, с помощью монолитных самодостаточных подсистем или с помощью специальных, одноразовых
Авторы противопоставляют инструменты Unix, такие как cat , с более крупными наборами программ, используемыми в других системах.
Дизайн catтипичен большинства программ UNIX: он реализует одну простую, но общую функцию, которую можно использовать во многих различных приложениях (включая многие, не предусмотренные первоначальным автором). Другие команды используются для других функций. Например, есть отдельные команды для задач файловой системы, таких как переименование файлов, их удаление или определение их размера. Другие системы вместо этого объединяют их в одну команду «файловой системы» с собственной внутренней структурой и языком команд. (Программа копирования файлов PIP, используемая в таких операционных системах, как CP / M или RSX-11, является примером.) Такой подход не обязательно хуже или лучше, но он определенно противоречит Философия UNIX.
Дуг Макилрой (слева) с Деннисом Ричи Макилроем, тогдашним главой Исследовательского центра компьютерных наук Bell Labs и изобретателем канал Unix резюмировал философию Unix следующим образом:
Это философия Unix: писать программы, которые делают одно и делают это хорошо. Напишите программы для совместной работы. Напишите программы для обработки текстовых потоков, потому что это универсальный интерфейс.
Помимо этих утверждений, он также подчеркивал простоту и минимализм в программировании Unix:
«замысловатые и красивые сложности» - это почти оксюморон. Программисты Unix соперничают друг с другом за «простые и красивые» почести - пункт, который подразумевается в этих правилах, но его стоит сделать явным.
И наоборот, Макилрой критиковал современный Linux как имеющий раздувание программного обеспечения, отмечая, что «обожающие поклонники накормили Linux лакомствами до печального состояния ожирения ». Он противопоставляет это более раннему подходу, применявшемуся в Bell Labs при разработке и пересмотре Research Unix :
Все было маленьким... и мое сердце залито Linux, когда я вижу его размер. [...] справочная страница, которая раньше была справочной страницей, теперь представляет собой небольшой том с тысячей опций... Раньше мы сидели в Unix Room и говорили: 'Что мы можем выбросить? Почему есть этот вариант? Часто это происходит из-за того, что в базовом дизайне есть какой-то недостаток - вы действительно не достигли нужной точки проектирования. Вместо добавления опции подумайте о том, что заставило вас добавить эту опцию.
Как заявил Макилрой и общепринято во всем сообществе Unix, программы Unix всегда ожидается, что он будет следовать концепции DOTADIW, или «Делай одно дело и делай это хорошо». В Интернете существует ограниченное количество источников аббревиатуры DOTADIW, но она подробно обсуждается во время разработки и упаковки новых операционных систем, особенно в сообществе Linux.
Патрик Волкердинг, руководитель проекта Slackware Linux, применил этот принцип проектирования в критике архитектуры systemd, заявив, что «попытка управления службами, сокетами, устройства, средства монтирования и т. д., все в одном демон бросает вызов концепции Unix: делать что-то одно и делать это хорошо ".
В своей книге Искусство программирования Unix, которая была впервые опубликована в 2003 году, Эрик С. Реймонд, американский программист и сторонник открытого исходного кода, резюмирует философию Unix следующим образом: Принцип KISS «Будь простым, глупым». Он предоставляет ряд правил проектирования:
В 1994 году (член команды, разработавшей X Window System ), опирался на свой собственный опыт работы с Unix, поскольку а также обсуждения с коллегами-программистами и людьми из других областей, которые на основе Unix, чтобы создать философию UNIX, которая суммирует ее в девяти главных принципах:
Ричард П. Габриэль предполагает, что ключевым преимуществом Unix было то, что он воплощал в себе философию проектирования, которую он назвал «хуже - лучше», в которой простота интерфейса и реализации более важны, чем любые другие атрибуты системы, включая правильность, согласованность., и полнота. Габриэль утверждает, что этот стиль дизайна имеет ключевые эволюционные преимущества, хотя сомневается в качестве некоторых результатов.
Например, в первые дни Unix использовала монолитное ядро (что означает, что пользовательские процессы выполняли системные вызовы ядра в пользовательском стеке). Если сигнал был доставлен процессу, когда он был заблокирован на длительном вводе-выводе в ядре, то что делать? Должен ли сигнал быть задержан, возможно, на долгое время (возможно, на неопределенный срок), пока ввод-вывод завершен? Обработчик сигналов не мог быть запущен, когда процесс находился в режиме ядра с конфиденциальными данными ядра в стеке. Должно ли ядро отменить системный вызов и сохранить его для повторного воспроизведения и перезапуска позже, предполагая, что обработчик сигнала завершился успешно?
В этих случаях Кен Томпсон и Деннис Ричи предпочли простоту совершенству. Система Unix иногда рано возвращалась из системного вызова с ошибкой о том, что она ничего не сделала - «Прерванный системный вызов» или с номером ошибки 4 (EINTR) в современных системах. Конечно, вызов был прерван, чтобы вызвать обработчик сигнала. Это могло произойти только для нескольких длительно выполняющихся системных вызовов, таких как read (), write (), open ()и select. (). С другой стороны, это во много раз упростило проектирование и понимание системы ввода-вывода. Подавляющее большинство пользовательских программ никогда не затрагивалось, потому что они не обрабатывали и не воспринимали сигналы, отличные от SIGINT, и сразу же умерли бы, если бы один был запущен. Для некоторых других программ, таких как оболочки или текстовые редакторы, которые реагируют на нажатие клавиш управления заданиями, к системным вызовам могут быть добавлены небольшие оболочки, чтобы сразу же повторить вызов, если возникла эта ошибка EINTR. Таким образом, проблема решилась просто.
В статье 1981 года под названием «Правда о Unix: пользовательский интерфейс ужасен», опубликованной в Datamation, Дон Норман раскритиковал философия дизайна Unix из-за отсутствия внимания к пользовательскому интерфейсу. Опираясь на свой опыт работы в когнитивной науке и с точки зрения современной философии когнитивной инженерии, он сосредоточился на том, как конечные пользователи понимают и формируют личную когнитивную модель систем - или, в случае Unix, непонимание, в результате чего катастрофические ошибки (такие как потеря часа работы) становятся слишком легкими.
