Размышления о UNIX::Журнал СА 6.2005
www.samag.ru
Льготная подписка для студентов      
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
О журнале
Журнал «БИТ»
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

Jobsora


  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
28.05.2019г.
Просмотров: 1943
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 1973
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 1530
Комментарии: 0
Django 2 в примерах

 Читать далее...

28.05.2019г.
Просмотров: 1117
Комментарии: 0
Введение в анализ алгоритмов

 Читать далее...

27.03.2019г.
Просмотров: 1693
Комментарии: 1
Arduino Uno и Raspberry Pi 3: от схемотехники к интернету вещей

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

Электронка - 2020!

 Размышления о UNIX

Архив номеров / 2005 / Выпуск №6 (31) / Размышления о UNIX

Рубрика: Острый угол /  IMHO

СЕРГЕЙ СУПРУНОВ

Размышления о UNIX

Различия операционных систем семейств Windows и UNIX видны практически с первого взгляда и в процессе работы становятся все более отчетливыми. Попытаемся обобщить и систематизировать основные принципы UNIX, делающие представителей этого семейства операционных систем именно такими, какие они есть.

Понимание этих особенностей, причем не на интуитивном уровне, а вполне осознанное, должно помочь пользователям, «воспитанным» на DOS и Windows, при переходе на UNIX-подобные системы. Я не претендую на абсолютную истинность мыслей, которые здесь прозвучат. Так или иначе, но каждый будет пропускать все сквозь призму своего опыта.

Какой должна быть идеальная ОС?

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

Во-первых, система должна быть понятной, не требующей обучения (разве что экспресс-курсов вождения мыши) для начала работы. Назовем это требованием интуитивной понятности.

Во-вторых, с системой должно быть удобно работать. Из курсов эргономики и психологии известна так называемая формула «7 ± 2», согласно которой человек способен охватить своим вниманием одновременно от 5 до 9 объектов. Таким образом, и операционная система должна строиться с расчетом, чтобы пользователю не приходилось постоянно держать в уме большее количество возможных действий, ключей и т. д. То есть важно, чтобы конечный результат мог быть получен за небольшое количество «ходов». Это будет требование эргономичности.

В-третьих, разработчики системы должны гарантировать, что их детище будет в любой ситуации вести себя так, как описано в инструкции (не забывайте, что речь идет об идеальной системе; юридически такие гарантии предоставляют единицы). То есть добавляется еще требование ответственности разработчика.

В-четвертых, квалифицированный пользователь может захотеть изменить поведение системы в соответствии со своими предпочтениями. Действительно, требования понятности и эргономичности слишком субъективны, чтобы любое действие можно было подогнать под предпочтения абсолютно всех. Отсюда вытекает требование модифицируемости.

В-пятых, система должна бережно относиться к вверенным ей ресурсам. Любая задача должна решаться по возможности «малой кровью», используя только те ресурсы, которые действительно необходимы. Назовем это требованием экономности.

Заметили противоречие требований ответственности разработчика и модифицируемости? Действительно, как разработчик будет что-либо гарантировать, если пользователь может сам менять систему?

Есть еще одно противоречие, на первый взгляд неочевидное, – между требованиями экономности и интуитивности. Чтобы система была понятна человеку, она должна быть максимально приближенной (хотя бы по внешнему виду) к тем инструментам, которыми он привык пользоваться в своей «некомпьютерной» жизни. Кнопочки должны «нажиматься», рычажки «опускаться», лампочки «загораться»... Все это, естественно, требует дополнительных ресурсов и совершенно бесполезно собственно для решения задачи.

Процедурные и проективные ОС

На стыке этих противоречий и родилось деление операционных систем на два типа – процедурные и проективные. Первые из них, преимущественно коммерческие, пошли по пути «ублажения» пользователя – максимум внимания уделяется интуитивной понятности, разработчик худо-бедно пытается что-то гарантировать, то есть берет на себя ответственность за работу продаваемой им системы (по крайней мере, на уровне рекламных сообщений). Модифицируемость при этом сведена практически к нулю – делать можно только то, что предусмотрено инструкцией (то есть, определен ряд процедур, отсюда и название – «процедурные»). Минимизация ресурсных требований также отодвинута на задний план – пользователь скорее согласится подождать несколько лишних секунд, любуясь красивыми картинками на экране, чем вспоминать консольную команду, которая отработает за доли секунды. Такая расстановка приоритетов вполне очевидна, если учесть, что основная задача подобной операционной системы – продаваться. Типичный представитель процедурных систем – Windows.

Проективные системы (прежде всего это UNIX и производные) исторически разрабатывались для «внутреннего потребления». Отсюда максимум внимания модифицируемости системы (модификация выполняется путем разработки «проектов» на языке инструментальной области, поэтому такие системы и называют проективными) и ее экономности – чем меньше ресурсов она будет требовать для той или иной задачи, тем больше можно будет сделать за то же время при той же стоимости оборудования.

Документирование систем

Эти ключевые различия повлекли ряд других. Так, совершенно по-разному осуществляется документирование процедурных и проективных систем и разрабатываемого для них ПО. В системах типа Windows документируются исключительно действия пользователя, которые он должен совершить, чтобы получить желаемые свойства того или иного объекта. То есть документация вырождается в инструкцию.

В UNIX, наоборот, информация о системе приобретает первостепенное значение. Поскольку в силу требования экономности интерфейс ориентирован в первую очередь на удобство для системы, а не для пользователя, то любой инструмент такой ОС должен быть снабжен подробным описанием того, как им пользоваться. Чтобы иметь возможность модифицировать систему, информация о ней должна быть еще более полной и охватывать не только возможные способы ее использования, но и описывать внутреннее устройство. Говоря другими словами, проективная система должна быть информационно открытой. И верхом такой открытости являются доступные исходные коды, поскольку никакое описание на естественном языке не может обладать такой полнотой.

Использование системных ресурсов

Благодаря информационной открытости сторонние разработчики получили возможность широко использовать системные средства, следуя при этом требованию экономности (зачем писать и помещать в систему то, что уже написано). Думаю, каждый, кто ставил что-нибудь, например, из коллекции портов FreeBSD, обращал внимание на массу дополнительных пакетов, связанных с устанавливаемым. В отдельном случае необходимость устанавливать дополнительные пакеты ради нескольких функций выглядит очень неэффективной, но в целом для системы позволяет сэкономить и на разработке, и на поддержке, и в некоторых случаях на дисковом пространстве.

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

Кто несет ответственность: разработчики или пользователь?

Следующий принцип, вытекающий из требования модифицируемости, – отказ от ответственности разработчика. Раз пользователь вправе менять в системе все, что ему заблагорассудится, то и вся ответственность за последствия ложится на него. То есть UNIX ориентирован на квалифицированного пользователя, который любое действие выполняет осознанно. А раз так, то можно сэкономить немного (а иногда и много) ресурсов на «откате» – пользователю предоставляется возможность отменить последнюю операцию только в том случае, если существует вероятность опечатки. Например, в редакторе vi существует отмена последнего действия, но только последнего – у пользователя будет время увидеть свою ошибку и исправить ее, а если совсем «заредактируется» – всегда к его услугам возможность выйти без сохранения. При работе в командной строке, как правило, ни возможности возврата, ни дополнительных вопросов не предусматривается. Действительно, вряд ли можно совершенно случайно набрать «rm -Rf/ ». А раз уж эта команда была набрана, значит, именно она и должна быть выполнена. В конце концов, это оскорбительно, когда какая-то «железяка» сомневается в правильности ваших решений.

Применение конвейерных операций

Еще один из основополагающих принципов систем UNIX – широкое использование «конвейерных» операций, когда конечный результат достигается за счет последовательной работы нескольких утилит, каждая из которых выполняет определенную задачу и отдает промежуточный результат на вход следующей утилите. Идея конвейера (канала) естественным образом проистекает из требования экономности: если есть программа, умеющая сортировать входной поток данных, и есть программа, умеющая отправлять данные по электронной почте, то было бы нерационально писать еще одну – для отправки отсортированных данных. Поэтому в любой UNIX-подобной системе вы найдете множество небольших утилит, каждая из которых выполняет достаточно узкую задачу, зато делает это очень хорошо. Комплексная же задача раскладывается на последовательность простых операций.

Кстати говоря, применение каналов отвечает и требованию эргономичности – проще запомнить несколько утилит и в дальнейшем комбинировать их в различных сочетаниях, чем держать в уме десятки и сотни команд на все случаи жизни.

Что в итоге

Описанные выше принципы, естественно, не являются догматическими, и разработчики различных инструментов и дистрибутивов операционных систем вольны смещать акценты в ту или иную сторону. Например, в редакторе vim может быть отменено любое количество последних операций – его разработчики решили пожертвовать некоторыми ресурсами системы ради дополнительного удобства пользователя. (По мнению некоторых, такое отступление от идеологии развращает, поскольку отучает обдумывать каждый свой шаг.) Системы Linux, ориентированные на среднеквалифицированного пользователя, все больше внимания уделяют графическому интерфейсу и пошаговым процедурам настройки, хотя их «проективность» в полной мере доступна через окно терминала. Такой гибридный подход к построению системы сыграл далеко не последнюю роль в увеличении популярности Linux как для домашних машин и рабочих станций, так и для построения серверов.

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


Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru