О пользователях дистрибутива

... а также обо всём, чего четыре, о том, что такое fun, о гибких конструкторах, оболочках, Пути Unix, полушариях и

Примечание: эта лекция читалась ровно две пары. Отчего так вышло -- ума не приложу...

Четыре категории пользователей

Пользователи ''дистрибутива'' (а не отдельного ПО)

  1. Системные администраторы (ADM)
  2. Разработчики ПО (DEV)
  3. Постановщики задач и наладчики бизнес-процессов (условно "системные интеграторы") (INT)
  4. Любознательные пользователи и повышающие квалификацию (a.k.a. Just For Fun) (JFF)

Четыре категории пользовательских задач

  1. Собственные/Чужие (кто пользуется решениями задач)
  2. Компьютерные/Некомпьютерные (лежит ли результат труда пользователя в компьютерной сфере)

Собственные

Чужие

Некомпьютерные

ADM

INT

Компьютерные

JFF

DEV

Четыре категории требований к инструментариям

  1. Собственные задачи -- гибкость
  2. Чужие задачи -- готовые решения типовых задач
  3. Компьютерные задачи -- программирование
  4. Некомпьютерные задачи -- констрцктор в некомпьютерной объектной области

Программирование

Конструктор

Готовые решения

RAD; дисциплины и среды программироания: Java, RR, Zope; IDE; ACE

Пакеты Прикладных Программ

Гибкость

Си :), языки прогр. общего назначения; системные и интерфейсные библиотеки

<!> Общего решения нет

Гибкий конструктор: The UNIX way

Требования к интерфейсу управления системой (т. е. к <!> "гибкому конструктору решений"):

Интерфейс -- это средства, позволяющие человеку управлять системой

Абстрактный "конструктор"

Интерфейк командной строки

Набор "деталей"

Запуск процессов

"Крепёж"

Взаимодействие процессов по данным, IO

Взаимодействие процессов по управлению, IPC

"Терминология"

Пространство имён -- filesystem ("всё -- файл")

"Язык описания"

Shell:

Диалог с пользователем, интерпретатор командной строки

Управление процессами и файлами, оболочка

Формализация созданных решений задач, ЯП

"Наглядность"

Информационное пространство -- manpages (документированность)

"Умопостижимость"

"Человекоприемлемость", config files ("всё -- текст")

Требование многопользовательской системы: масштабируемость интерфейса

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

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

Что не умеет Shell и когда это нужно?

Преимущество выбора перед вводом

  1. Многократные действия (экономия времени и снижение вероятности ошибки)
  2. Непрофессиональные действия (интерфейс отражает легенду, а не действительные элементы управления)

  3. Сложные действия, умолчания, прочий искусственный интеллект (легко реализовать сценарием на shell, но от пользователя потребуется именно выбор)
  4. Ситуации, когда визуальный поиск эффективнее текстового (поиск среди большого числа объектов в результате ошибочного дизайна или требований пользовательской области)