Главная
страница 1страница 2страница 3 ... страница 59страница 60

1Изучение UNIX® (Linux)


UNIX® невозможно изучить урывками, читая книжку в метро, а тем более - не подходя к компьютеру. Это непростая задача требующая определенных усилий и добровольного самопринуждения действовать правильно и методично.

Рассмотрим самый, на наш взгляд, естественный алгоритм решения любой задачи:



  1. уяснить задачу;

  2. выбрать самый подходящий инструмент решения (самый подходящий, а не самый знакомый!);

  3. освоить этот инструмент (начиная с изучения документации).

  4. придумать по возможности красивое решение;

  5. зафиксировать это решение (чтобы можно было в случае чего повторить);

  6. применить его.

Казалось бы, спорить не с чем, но как часто мы поступаем строго наоборот! Желая "сэкономить время", мы нередко начинаем с того, что так и эдак применяем попавшиеся под руку инструменты (6) и даже начинаем набрасывать кое-какие сценарии или проекты решения (5). Потом мы задумываемся над тем, как же решить нашу задачу "по уму" (4), и понимаем, что инструмент нам, в сущности, незнаком, что надо изучать руководство (3). Из руководства выясняется, что инструмент нам не подходит, и приходится искать другой (2). И только тогда мы понимаем, что для этого надо разобраться, какую именно задачу мы решаем (1).

Драма пользователя UNIX® в том, что система на такой непрофессиональный способ взаимодействия не рассчитана. Если начинать не с начала, времени на решение будет потрачено гораздо больше. К тому же это верное средство создать хаос в собственной голове.


1.1Человеко-машинные системы


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

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

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

Пользователь как клиент

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

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

Уровень знаний о системе в этом случае может быть минимальным (как включить, как заставить решать задачу и т. п.). Более того, знание устройства системы, понимание принципов ее работы помогут пользователю лишь в малой степени, потому, что возможности изменить эти принципы у него нет (иначе она давно бы уже вышла из строя из-за неумелого руководства). Что следует знать досконально, так это то, какие именно действия над объектом будут выполнены, если потянуть за тот или иной рычаг управления.

Кто оказывается главным в такой системе, от кого зависит качество получаемого продукта? Машина, а точнее создатели системы, заложившие в нее соответствия между рычагами управления и выполняемыми действиями. Если после нажатия очередной кнопки объект, вопреки сказанному в инструкции, испортился - это недоработка авторов, а не ошибка клиента: все, что он мог сделать, - не нажимать на кнопку. Клиент такой системы требует гарантий качества от разработчиков, потому что сам в силах гарантировать только неукоснительное следование инструкциям.

Пользователь как администратор

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

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

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

Такой подход требует, чтобы в системе были предусмотрены разнообразные универсальные и специализированные средства создания решений любых возможных задач. Для компьютера это высокоуровневые языки программирования и отдельные программы для элементарных взаимодействий с системой. Для автомобиля - набор удобных ключей и прочих инструментов для работы с любой деталью и всевозможные насосы-домкраты. Решив (чаще всего чисто умозрительно) поставленную задачу, администратор дает команду машине: "Делай по моему проекту". Машина работает, а пользователь занимается другими делами, не забывая, однако, приглядывать за системой: хорошо ли справляется с задачей его творение, не стоит ли где подправить? Составление проекта, по которому машина будет решать задачи самостоятельно, - ключевая особенность, иначе пользователю пришлось бы делать часть формализуемой работы за машину, поэтому организованные таким образом системы можно назвать проективными.

Про уровень знаний о системе, необходимый пользователю-администратору, - чем больше он знает, тем лучше она работает. К сожалению, обратное тоже верно: чем меньше - тем хуже. Более того, "больше" должно быть именно знаний, то есть понимания внутрисистемных механизмов, а не просто сведений о том, как в разных случаях пользоваться системой. К тому же администратор должен иметь ясное представление обо всех прикладных областях системы, даже если не является сам себе заказчиком.

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

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



Свобода от или свобода для?

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

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


<< предыдущая страница   следующая страница >>
Смотрите также:
1 Изучение unix® (Linux) 5 1 Человеко-машинные системы 6
5003.83kb.
60 стр.
Различия между unix и Linux
110.44kb.
1 стр.
Особенности Linux
38.09kb.
1 стр.
RH253 Сетевые службы Red Hat Linux и администрирование безопасности Описание курса
45.49kb.
1 стр.
Unix-подобные операционные системы, характеристики, особенности, разновидности
40.07kb.
1 стр.
2. операционная система linux 2 Общая структура 2
1003.22kb.
9 стр.
Программы повышения квалификации ункит 8-10 «Администрирование unix(Linux/bsd) сервера»
10.61kb.
1 стр.
Экзаменационные вопросы с комментариями
13.34kb.
1 стр.
Вопросы к экзамену по дисциплине «Многопользовательские операционные системы»
14.61kb.
1 стр.
Практикум n 8 Изучение файловой системы оc unix по курсу «Операционные системы»
202.58kb.
1 стр.
Методические указания к лабораторной работе Сетевые утилиты в ос windows и unix/Linux. Тестирование стека tcp/ip рига 2004
146.22kb.
1 стр.
Интерфейс командной строки
206.87kb.
1 стр.