Назад Содержание Вперед
Введение в POSIX'ивизм
(C) Алексей Федорчук, 2005
Опубликовано на сайте
LinuxCenter
Глава 11. Терминалы, режимы, интерфейсы
Рассказ о терминалах принято начинать с тех времен, когда машины были большими. Не отступлю от этой традиции и я. Но сначала несколько слов о необходимости этого рассказа вообще.
Содержание
Текстовая консоль с командным интерфейсом в век графических режимов и интегрированных объектных сред выгляди весьма скромно. Примерно как серый кремень на фоне своих блистающих сородичей - аметистов и цитринов, сердоликов и огненных опалов. Почему же в последнее время тема эта снова и снова обсуждается на страницах Сетевых и печатных изданий? Для ответа на этот вопрос придется углубиться в историю, хотя и очень отдаленную в масштабах вечности.
Казалось бы, не так давно на ниве настольных систем сосуществовали, не всегда мирно, но почти на равных, и DOS во всех ее проявлениях (MS DOS, IBM DOS и самая среди них прогрессивная и потому не вполне совместимая с прочими DR DOS), и MacOS, и милая Amiga со своей multimedia-ориентацией, и Windows всякого рода, чина и номера, и OS/2, и почти забытая Geoworks (она же GEOS), не говоря уже о сияющем NextStep. А еще туда (почти) всерьез стремились и HP-PA с ее HP-UX, и Sparc со своими SunOS и Solaris, и казавшаяся недосягаемой по производительности Alpha с Digital Unix.
Я хорошо помню авторитетные компьютерные издания первой половины 90-х, без тени улыбки обсуждавшие достоинства и недостатки всех этих ОС как платформ для настольных персоналок. Например, тесты сравнительного быстродействия WordPerfect на i386 под DOS и на Sparc под Solaris. Благо, был тогда такой ворд-процессор, реализованный для всех мыслимых и немыслимых ОСей и платформ...
И кому это все мешало? - спросили бы в Одессе. Тем не менее, в одночасье, если смотреть из сегодняшнего далека, все изменилось. Тихо и незаметно, как парторг на пенсии, почила в Бозе DOS. Оставив пару-тройку бичующих отпрысков, хватающихся за любую работу. Канули в небытие NextStep и GEOS, пошла по рукам, как стареющая красотка, Amiga, мирно дремала, как этнос в гомеостазе (Л.Н.Гумилев), OS/2. Старина Mac впал в фазу абскурации, дабы потом тихо окопаться в тесной нише издательских систем и высокой полиграфии. А титаны мира рабочих станций оставили надежду выйти на оперативный простор рабочих столов, возводя глубоко эшелонированные линии обороны на своих рубежах.
И, проснувшись в один не очень прекрасный день, пользователи увидели мелькающие на дисплеях окна, окошки, форточки: пришел отец Уыньдовс и всех подмял под себя.
Казалось, история кончилась. Жалкие потуги BeOS оттянуть на себя хотя бы симпатии, если не кошельки, пользователей, - не в счет. Для прочих же, выживших, сохранение status quo на уровне суммарных пяти процентов настольных пользователей казалось пределом мечтаний.
И тут неожиданно оказалось, что параллельно миру коммерческого софта, миру чистогана, где все покупается и все продается, существует другой мир - свободного софта и открытых исходников. Где программы пишутся для решения своих личных задач, для самообразования и поддержания профессиональной формы, для повышения престижа в собственном сообществе, а то и просто из любви к искусству и спортивного азарта. Короче говоря - Just for Fun, как сказал человек, которому суждено было стать одним из символов этого альтернативного мира.
Мир этот был почти столь же стар, как и мир коммерческий. Однако долгое время развивался он тихо и неприметно, как млекопитающие - в эру динозавров. И лишь недавно (и также исторически мгновенно) об этом мире узнали широкие круги околокопьютерной общественности. А слова Linux и Open Sources замелькали по страницам не только компьютерных, но и общественно-политических, как сказали бы при социализме, изданий. Началось явление, которое войдет в историю ушедшего тысячелетия под названием бума Linux и открытых исходников.
Разумеется, Linux не был ни единственной, ни первой, ни даже наиболее развитой системой, распространяемой свободно и открыто. Одновременно и рядом существовали и Free-, и Net-, и OpenBSD, и недавно реанимированный Hurd - это если ограничиться только Unix-подобными системами. К каковым мир свободных ОС отнюдь не сводится - время от времени появлялись и свободные операционки, отношение которых к Unix было весьма опосредованным (например, феноменальная AtheOS, ныне преобразованная в Syllable).
Однако именно Linux, в силу ряда исторических, психологических и просто случайных причин, привлек к себе внимание широких масс околокомпьютерных трудящихся. Обсуждение этих причин далеко выходит за рамки сегодняшней темы. Рискну сформулировать только одну, на мой взгляд, главную: если бы Linux не существовал, его следовало бы выдумать.
В человеческой популяции всегда были, есть и (надеюсь) будут люди, которым рано или поздно становится скучно в мире, пусть удобном и уютном, но однообразном. Для одних это - просто дань юности. Для других - нечто вроде "седины в бороду и беса в ребро". Подобно тому, как преданный муж, в согласии проживший со своей (относительно) красивой и (весьма) заботливой, но недалекой женой в комфортабельной квартире, неожиданно (для самого себя) уходит в коммуналку к безалаберной и косоглазой, но умной и страстной женщине. Или - бросается в темный омут опасных связей. Для третьих же тяга к переменам и свободе выбора - просто неотъемлемая черта характера.
И именно эти категории людей неожиданно для себя видят, что за Окнами существует жизнь, не столь уютная и приглаженная, загадочная и порой опасная (если не для жизни - то для "железа"). Но - другая, и уже этим интересная. На мой взгляд, далеко не случайно, что Linux-бум начался именно в тот момент, когда засилье Windows казалось безграничным. Что вселает надежду и веру в род человеческий. Подобно тому, как предпоследнему авантюристу из "Территории" Олега Куваева было бы обидно, если он окажется авантюристом последним...
Прогнозировать события не возьмусь. Однако думается, что Linux-бум - он бум и есть. И со временем и сменой моды, приоритетов, жизненных установок схлынет так же в одночасье, как начался. И в итоге Linux сотоварищи останутся там, где им и место - на настольных персоналках научных работников и инженеров, школьников и студентов с соответствующими интересами, домашних компьютерных любителей. Останется и результат Linux-бума - ведь именно благодаря ему подавляющее большинство потенциальных пользователей открытых и свободных ОС узнали о самом их существовании.
Да и мир коммерческого софта никогда уже не станет прежним. Мир свободного софта и открытых исходников уже повлиял на него и будет влиять самим фактом своего существования и своим кругом пользователей.
На текущий же момент мы наблюдаем беспрецедентный рост сообщества пользователей Linux (и прочих свободных POSIX-систем). И новопользователи Linux сейчас количественно резко преобладают над юниксоидами старого закала и энтузиастами Linux первого призыва. И все они пришли из Windows - больше неоткуда. Ведь, как говорил герой "Всей королевской рати" Уоррена, "добро можно делать только из зла, потому что больше его просто не из чего делать".
Однако за годы оконного ига выросло поколение пользователей (выросло - как пользователи, не обязательно как организмы), лихо налагающих фильтры в Photoshop'е или вращающих городские кварталы в 3DMax, но не имеющие представления не только о разбиении диска, но даже не заставшие командной строки DOS.
Это я отнюдь не в упрек: способность ряда моих знакомых применять Photoshop для анализа космоснимков или 3DMax - для построения архитектурных ансамблей вызывает у меня просто искреннее восхищение. Скорее это комплимент искусству Windows драпировать свои внутренности. Результат чего - естественное стремление Windows-мигранта и в Linux действовать в привычной среде и привычными методами. Благо, стремление это удовлетворяется интегрированными объектными средами графического режима, такими, как KDE и GNOME. Да и современные т.н. end-user oriented дистрибутивы к тому подталкивают.
Однако, как я пытался показать в главе 4, довольно быстро выясняется, что приемы работы, заимствованные из Windows, в Linux часто оказываются менее эффективными, чем традиционные инструменты Unix-систем. А большинство последних не требует для своей работы ничего, кроме классической Unix-консоли, именуемой также терминалом.
А теперь обратимся ко временам более древним - тем самым, "когда компьютеры были большими". Размером не то что с самогонный аппарат, а с цельный перегонный цех. А также - очень дорогими, как сами по себе, так и в эксплуатации, поскольку потребляли очень много электроэнергии. Счастливым обладателям таких машин (а ими являлись отнюдь не физические лица, а государственные организации, часто очень "мирного профиля", и крупные фирмы) казалось непозволительной роскошью оставлять их в индивидуальном пользовании. И потому эти машины были многопользовательскими.
Сначала пользователи приносили свои задачи в машинный зал (или, как говорили в Советской России, вычислительный центр), где они ставились в очередь, по достижении которой обрабатывались в течении определенного времени (отсюда пошло понятие машинного времени), после чего результаты забирались пользователем. Устройствами ввода при этом служили перфокарты, а вывод подавался на печатающие устройства.
Потом в качестве средств взаимодействия с машиной (и хранимыми в ней программами) стали использоваться клавиатуры, заимствованные у пишущих машинок, и дисплеи, или мониторы, созданные по аналогии с телевизором.
В результате появилась возможность оснастить рабочее место каждого пользователя сочетанием устройства ввода, с которого пользователь вводил свою задачу, и устройства вывода, на котором он мог просмотреть результат ее обсчета. Это сочетание и получило название терминала (что в данном контексте можно было бы перевести как "оконечник" - не отсюда ли родилось понятие конечного пользователя?). А для того, чтобы пользователи могли проделывать это одновременно, родилось понятие "систем разделения времени" (строго говоря, ресурсов машины вообще - ныне это чаще называют истинной многозадачностью), одной из реализаций которых и была Unix. Таким образом, понятие машинного времени утратило смысл, а все терминалы стали равны между собой. Как, впрочем, и пользователи - власть их была ограничена, каждый управлял только своим терминалом, и не имел (теоретически) никакой возможности повлиять на систему в целом.
Однако имелся среди пользователей один умник, который всех напаривал (пардон, всем управлял). Он назывался root-оператором (или просто root'ом), обладал всевластием в масштабе данной системы и реализовывал это всевластие с собственного, всевластного, терминала. Этот терминал всевластия получил название системной консоли.
В это же примерно время появились устройства хранения информации - винчестеры, названные так по аналогии маркировки первых их представителей с номенклатурой патрона для одной из популярных моделей винтовки системы Генри 30-го калибра - 0,03 дюйма, они же три линии, 7,62 мм по нашему. На винчестерах, наряду с общесистемными программами, нашлось место и для пользовательских данных. Однако пользователей было много, а машина с винчестером - одна. И чтобы пользовательские данные не путались между собою, потребовалось разграничить их друг от друга. Что и проделывалось с одного из терминалов, который был равнее других. Им была та самая системная консоль, или просто консоль, в первоначальном смысле этого термина.
Физически консоль представляла собой точно такой же терминал, как и все остальные, а ее большая равность определялась исключительно полномочиями лица, за ней сидящего. Ибо root, обладая тайным знанием - своим собственным паролем, от которого его всевластие и зависело, мог засадить в систему все хитрости свои, все меры защиты, и все такое. В частности - запрещение авторизоваться root'ом с любого другого терминала, кроме консоли. А для напаривания (опять пардон, управления) пользователями он делал так, чтобы на консоль выводились все системные сообщения (в том числе сообщения об ошибках и информация об авторизации пользователей), почему консоль root'а и получила название системной.
Потом PC уравняла пользователей в правах не хуже известного девайса полковника Кольта. За каждой такой машиной сидел один единственный пользователь, и была она самодостаточным агрегатом, имеющим собственные устройства ввода, вывода и хранения информации. Тем не менее, Unix, мигрировав на персоналки, сохранил свою многозадачную и многопользовательскую природу. Однако, если многозадачность легко реализовывалась чисто программными средствами (например. командной оболочки, что будет темой следующей главы), то как реализовать доступ нескольких пользователей (а Unix и на персоналке почти всегда имеет минимум двух пользователей - root'а и обычного) к машине, физически имеющей лишь одну комбинацию устройств ввода/вывода?
Конечно, и к персоналке в принципе можно прикрутить еще один монитор и клавиатуру - и приспособления для этого имелись. Однако более простым оказалось чисто программное решение. Так в Unix появилось понятие виртуальной консоли (или виртуального терминала).
Терминологическое отступление: как уже было сказано ранее, консоль и терминал в историческом аспекте были понятиями несколько разными. Однако ныне различия между ними (почти) стерлись, и потому далее я буду использовать эти термины как синонимы. Есть и еще один вид виртуального терминала - так называемый X-терминал, реализуемый посредством специального класса программ - их договоримся называть графическими эмуляторами терминала, и речь о них будет в следующем разделе.
Виртуальный терминал - это все то же сочетание реальной клавиатуры и дисплея, которое при определенных условиях может выступать как (почти) самостоятельная машина. На каждом из наличных виртуальных терминалов может зарегистрироваться отдельный пользователь, и в его силах запускать там свои задачи, никак (опять же почти - ресурсы-то компьютера остаются общими) не влияющие на задачи пользователя, зарегистрировавшегося на другом виртуальном терминале.
Сам факт существования виртуальных терминалов, их максимальное количество и базовые свойства (такие, как экранный буфер, возможность изменения экранных шрифтов, раскладок клавиатуры, цветовой гаммы и т.д.) определяется частью ядра системы, которая называется консольным драйвером. В Linux он так и называется - драйвер Linux-консоли. А ядра BSD-систем поддерживают возможность использования одного из нескольких консольных драйверов. Так, во FreeBSD и DragonFly по умолчанию (и - сообразно здравому смыслу) в качестве драйвера системной консоли используется syscons, в Net- и OpenBSD эту роль нынче играет wscons. Однако все три системы могут работать также с консольным драйвером pcvt - другое дело, что это не дает никаких преимуществ (и даже наоборот - скажем, русификация pcvt представляет собой занятие для садомазохистов).
Непосредственное управление свойствами терминала (то есть, например, загрузкой конкретного шрифта или клавиатурной раскладки) управляет некий набор утилит, объединяемый в определенный (специфичный для данной ОС) программный пакет. Во FreeBSD (и DragonFly) он фактически безальтернативен, и носит то же имя, что и консольный драйвер - syscons. В Linux практически равноправно можно использовать одну из альтернатив - пакет kbd и console-tools. До некоторого времени последний считался более продвинутым, однако ныне они абсолютно идентичны по своим возможностям. И приверженность разработчиков того или иного дистрибутива одному из этих пакетов обусловлена исключительно личными пристрастиями или историческими причинами.
Как уже неоднократно говорилось, все, что существует в Unix-системе статически - суть файлы, в том числе физические или виртуальные устройства. И терминалы тут - не исключение, каждому из них соответствует свой файл в каталоге /dev. Так, физической
консоли соответствует файл /dev/console, номенклатура же файлов виртуальных терминалов различна в разных ОС. Во FreeBSD и DragonFly имена их файлов имеют вид /dev/ttyv#, где # - порядковый номер терминала, начиная с нуля. В Linux (без использования devfs) файлы виртуальных терминалов именуются как /dev/tty#, причем # начинается с единицы. Файл с именем /dev/tty0 тоже есть, но он зарезервирован за той самой системной консолью, которая ныне представляет собой явление почти чисто мифическое. При задействованной же devfs файлы устройств виртуальных терминалов приобретут вид /dev/vc/#, где к номеру приложимо все сказанное выше. Хотя и в этом случае что-нибудь вроде tty# в каталоге /dev имеется на предмет обратной совместимости (это зависит от настроек демона devfsd).
Насколько мне известно, консольные драйвера POSIX-систем поддерживают до 63 виртуальных терминалов. Это связано с тем, что терминалы, как и всякие другие файлы устройств, характеризуются своими номерами - старшим (major) и младшими (minor). Старший номер класса терминальных устройств зависит от ОС, а под младшие номера зарезервированы числа с 1 до 63. Этим и определяется максимально возможное число консолей.
Принципиальная возможность существования 63 виртуальных терминалов не означает, однако, будто бы все они на самом деле доступны пользователю. Начать с того, что виртуальный терминал требует активизации. Для чего на нем должен быть запущен какой-либо процесс. При старте системы такие процессы (команды семейства getty) запускаются для некоторого количества терминалов. В большинстве дистрибутивов Linux традиционно активизируется 6 виртуальных консолей, в последних версиях FreeBSD и в DaronFly - 8. Эти числа определены в конфигурационных файлах /etc/inittab и /etc/ttys, соответственно, и могут быть изменены в любую сторону. Правда, в большую - с некоторыми оговорками (первая - максимально возможное теоретически число консолей, о второй скажу парой абзацев ниже).
Консоли сверх умолчального количества могут быть активизированы и после загрузки системы. Для этого достаточно запустить на них какой-либо процесс. Им может быть:
- процесс на тему
getty, вызывающий, в конечном счете, приглашение к авторизации;
- запуск программы автоматической регистрации пользователя типа
qlogin;
- запуск сеанса работы оконной системы X (подробности - в следующем разделе);
- запуск не-Иксовой графической программы, обеспечиваемой библиотекой SVGAlib;
- непосредственный запуск (почти) произвольной программы с помощью команды
openvt (правда, последнее - только в Linux, насколько мне известно).
Любым из указанных способов в Linux можно открыть виртуальные терминалы с 7-го по 63-й. Во FreeBSD есть еще одно ограничение - максимальное число консолей, поддерживаемое текущей конфигурацией ядра. По умолчанию оно равно 16-ти, изменение требует реконфигурирования ядра и его пересборки.
Вообще-то, первое знакомство с механизмом виртуальных консолей Linux или FreeBSD обеспечивает незабываемое эмоциональное потрясение пользователю, немалую часть своей компьютерной жизни проведшему в окружении "черного DOS'а". С ним можно сравнить только восторг, испытываемый от возможностей командного интерпретатора, о чем пойдет речь в следующей главе. Впрочем, юзеру с исключительно подоконным опытом работы не дано понять ни того, ни другого...
Потрясение это обусловлено рядом факторов. Во-первых, сама возможность открыть второй (третий, пятый, восьмятый) виртуальный терминал, авторизоваться в нем под своим пользовательским или иным другим именем (в том числе - и root'ом) и запустить любую программу, переключаясь по мере надобности между открытыми приложениями ничуть не сложнее, чем между окнами в графической среде типа Windows.
Способ переключения между виртуальными терминалами зависит от умолчальных настроек используемого консольного драйвера. В Linux и BSD'шном syscons переключение выполняется комбинацией клавиш Alt+F#, где # - номер консоли. В wscons той же цели служит чуть более сложное сочетание - Control+ Alt+F# (забегая вперед, отмечу, что она же используется во всех операционках для переключения из сеанса X в текстовую консоль).
Указанные комбинации (например, Alt+F#) для перехода между консолями не являют собой нечто предопределенное божественным промыслом. Ибо зависят исключительно от текущей раскладки клавиатуры.
Легко сообразить, что означенным способом можно получить доступ к виртуальным терминалам с 1-го по 12-й. А как быть, если вздумается установит большее их количества? - ведь более 12 функциональных клавиш на клавиатурах обычно не наблюдается...
Есть несколько способов доступа к виртуальным терминалам с произвольным номером. Например, в большинстве случаев комбинация клавиш Alt+Shift+F# обеспечивает переход к консолям с 13-й по 24-ю. Далее, в некоторых системах нажатием клавиши PrtSc можно последовательно пролистать активные консоли, начиная с текущей (а в других случаях - перейти в последнюю по счету из активизированных консолей. И, наконец, (почти) универсальный способ - команда
$ chvt #
где # - номер целевой консоли.
В Linux виртуальные терминалы абсолютно равноправны. В BSD-системах же сохранился рудимент представления о системной консоли - таковой по выступает 1-й виртуальный терминал. Его большая, по сравнению с прочими, равность, выражается в том, что на него сыпятся все сообщения о системных ошибках. И даже если это запретить соответствующей настройкой конфигурационных файлов, от кое-каких сообщений (например, о присоединении или отсоединении USB-устройств) избавиться нельзя никакими средствами (по крайней мере, я таких средств до сих пор не нашел).
Как говорилось в главе 7, каждый пользовательский интерактивный процесс (то есть, фигурально говоря, программа, запущенная пользователем с помощью командной директивы) связан с каким-либо виртуальным терминалом. При этом для программы различаются понятия управляющего и текущего терминала. Первый - тот, с которого программа была запущена, и с которого можно при необходимости прервать ее исполнение. На текущий же терминал выводятся результаты ее работы. Обычно управляющий и текущий терминалы совпадают, однако это не обязательно. С помощью определенных средств (того же qlogin, например, или openvt), программу можно запустить так, чтобы она исполнялась на терминале, отличном от стартового. При этом последний сохраняет свои управляющие функции.
Еще одно различие выявляется между текущей консолью и всеми прочими при запуске какой-либо программы графического режима, например, Иксов. При этом в первую очередь запускается вполне конкретная программа - X-сервер и текущая консоль как бы блокируется вплоть до выхода из Иксов (или из SVGAlib-программы). А для запущенной с нее программы активизируется новая виртуальная консоль, которая и становится текущей.
Хотя на самом деле блокировки консоли, с которой запущенны Иксы, не происходит (спасибо Тихону Тарнавскому, обратившему мое внимание на сей факт). Просто она занимается процессом, сиречь Иксами, который и выводит на нее массу своих служебных сообщений. Так что если запустить Иксы в фоновом режиме, а вывод сообщений куда-нибудь перенаправить (в log-файл или тот же /dev/null), то и эту консоль можно задействовать для нормальной работы.
X-сеанс, запущенный с какого-либо виртуального терминала, сохраняет его в качестве управляющего, то есть может быть с него же и прекращен - например, стандартной клавишной комбинацией Control+C.
Отметим, что использующая графику программа, запущенная из консоли с поддержкой графического режима через frame buffer, занимает только текущий виртуальный терминал, который остается для нее и управляющим.
Второе открытие, подстерегающее пользователя, приобщающегося к POSIX'ивизму, - консольный буфер экрана (или, как он называется в BSD, буфер истории). Оказывается, если вывод данной консоли не умещается на один экран - его можно "пролистать" назад и, до текущего положения, вперед, как в текстовом редакторе. Правда, одних клавиш PageUp/PageDown для этого недостаточно. В консоли Linux (и wscons) пролистывание осуществляется одной из этих клавиш при нажатом Shift. А в syscons перевод в режим "листания" буфера истории осуществляется нажатием фиксируемого переключателя ScrollLock.
Есть и еще одно отличие буфера истории консолей BSD и Linux. В первой операционке он полностью независим для каждого виртуального терминала. И, переключаясь между ними, можно листать страницы их истории, сколько вздумается (в некоторых пределах, установленных в текущей конфигурации ядра).
В Linux'е же в каждый момент времени доступен только буфер истории текущего виртуального терминала. Переключение в другую консоль активизирует ее буфер истории, но необратимо стирает историю консоли предыдущей (как любитель истории, не могу не отметить, что больший "историзм" BSD-систем проявляется и в таких мелочах).
Третий поражающий воображение фактор - возможность настроить для каждой консоли свою цветовую гамму: установить свой цвет фона и шрифта, а в syscons еще и цвет так называемого бордюра - это та самая черная каемка, памятная заставшим времена старых 14-дюймовиков без средств цифрового управления, на которых искоренить ее нельзя было никакими силами.. Так вот, и это абсолютно, казалось бы, паразитный элемент можно приспособить для использования в мирных целях - я задействую его для визуального различения консолей (например, консоль для регистрации root'а у меня всегда имеет бордюр тревожно-красного цвета).
И, наконец, четвертое: хотя виртуальные терминалы изображают собой (почти) самостоятельные машины, между ними возможен обмен данными. И служит этому любимое устройство "подоконников" - самая обычная мышь. Каковая в консоли служит не средством указательства или позиционирования курсора (в Unix-консоли текстовый курсор и курсор мыши суть вещи, совершенно друг с другом не связанные, во FreeBSD это подчеркивается даже их разным представлением на экране), а предназначена для помещения выделенных экранных фрагментов в специальный буфер обмена. Из коего они могут быть скопированы в любой активный виртуальный терминал.
Выделение мышью фрагмента осуществляется двояко: или обычным для Windows способом - перемещением мышиного курсора при нажатой левой кнопке, или двумя последовательными щелчками - сначала левой кнопкой на начале выделяемого фрагмента, затем правой на его конце.
А копирование из буфера происходит и того проще: переводом текстового (не мышиного!) курсора в нужную позицию того же виртуального терминала или переключением на другой виртуальный терминал - и щелчком средней кнопкой, если речь идет о нормальном (то есть трехкнопочном) грызуне. В наиболее распространенных нынче двухкнопочных мышах с колесом прокрутки последнее успешно выполняет роль средней кнопки. И, наконец, в совсем уж ущербных двухкнопочных мышах действие средней кнопки в большинстве случаев можно эмулировать одновременным нажатием двух наличных...
О несравненных достоинствах консоли можно говорить бесконечно. Но пора переходить к разговору
Когда машины были большие, и когда к ним начали прикручивать дисплеи в качестве устройств вывода, дисплеи эти были разными - текстовыми или графическими.
Текстовые дисплеи в терминальных комплектах использовались чаще. Их особенность в том, что они в принципе были способны выводить символы только из некоего предопределенного набора, жестко прошитого в "железе" (в ПЗУ знакогенератора). Конечно, в такие наборы входили не только текстовые (то есть алфавитно-числовые) символы, но и, например, так называемая псевдографика (уголки, линейки и т.д.), с помощью которой можно было строить некие изображения (например, элементы меню). Но важно то, что выход за пределы предопределенного набора символов был невозможен (я помню времена, когда для обеспечения вывода символов кириллицы требовалось перепрограммирование знакогенератора, что и проделывалось нашими умельцами).
Графические дисплеи работали по другому принципу: на них изображение строилось, с помощью специальных алгоритмов, попиксельно. Что, соответственно, давало в принципе возможность вывода на экран совершенно произвольных вещей - любых наборов символов в различном шрифтовом оформлении, а также собственно изображений - векторных (то есть образованных линиями, описываемыми математическими уравнениями) или растровых (слагавшихся из наборов пикселей определенного цвета). Тем не менее, графические дисплеи по природе своей были устройствами растровыми - даже векторные кривые в конечном счете слагались из цепочек пикселей. Говорят, существовали и собственно векторные графические дисплеи, однако мне их видеть не приходилось, и что это такое - представляю весьма смутно.
С появлением персоналок собственно текстовые дисплеи (MDA и ранние Hercules'ы) быстро вышли из употребления. Видеосистемы IBM-совместимых машин, объединяющие в себе видеоадаптер (или, как часто говорят, видеокарту) и собственно монитор, стали графическими. Однако текстовый режим как таковой в них сохранился. Только теперь предопределенные наборы символов не прошивались в "железе", а загружались в видеокарту. Именно программирование видеокарт и обусловило возможность создания простых способов работы с нелатинскими наборами символов (в том числе и кириллицей).
Постепенно текстовый режим вытеснялся различными графическими режимами (а были системы, изначально ориентированные на использование графики, такие, как MacOS или Amiga). И лишь в Unix-подобных операционках текстовый режим до недавнего времени прочно удерживал свои позиции - и в значительной мере именно благодаря поддержке виртуальных терминалов.
Часто неявным образом ставится знак равенства между текстовым режимом и режимом консольным (или режимом терминального доступа). В общем случае это неверно. Конечно, виртуальные консоли часто функционируют именно в текстовом режиме (в большинстве BSD-систем - почти исключительно в нем). Однако существует и понятие так называемой графической консоли, которое не следует смешивать с понятиями графических рабочих сред. Ибо это - самая обычная консоль, но изображения на ней (в том числе и текстовые символы) выводятся графическими средствами - то есть попиксельной прорисовкой, а не вытягиванием из предопределенного набора. Это возможно потому, что все современные (именуемые обычно VESA-совместимыми) видеокарты поддерживают так называемый линейный кадровый буфер (или Frame Buffer), допускающий прямое воспроизведение графики без использования специальных программных средств.
В принципе, с распространением жидкокристаллических мониторов, можно ожидать полного отмирания чисто текстовой консоли - уж больно неэстатично выглядит стандартный текстовый режим (80 колонок на 25 строк) на LCD-матрицах с физическим разрешением 1280x1024; не говоря уже о неэффективном использовании экранного пространства. Однако не думаю, что важность консоли от этого уменьшится. Как раз наоборот, именно режим фрейм-буфера позволяет заиграть ей дополнительными красками.
Таким образом, графическая консоль (или фрейм-консоль) знаменует собой плавный переход от чисто текстового режима к режиму графическому. Каковой в POSIX-системах может быть реализован различными способами.
Первый способ - только что упомянутая графическая консоль. Правда, до недавнего времени доступен этот способ был практически только в Linux, где требует лишь включения опции в конфигурации ядра (поддержка Frame Buffer для абстрактной VESA-совместимой видеокарты, или для одной из модельного ряда - ATI, Matrox и т.д.) и задания определенного параметра при загрузке (в большинстве современных user-ориентированных дистрибутивов это делается по умолчанию). После чего становится возможным изменение экранного разрешения в широких пределах - вплоть до 1280x1024, глубины цвета, просмотр изображений и даже видео.
Ядра NetBSD и OpenBSD, насколько мне известно, режима Frame Buffer не поддерживают. А во FreeBSD такая возможность теоретически могла быть включена, но только для фиксированного разрешения (800x600), да и на всех видеокартах, с которыми мне довелось иметь дело, выглядит это дело весьма убого.
Однако ныне в DragonFlyBSD режим графической консоли реализован ничуть не хуже, чем в Linux-консоли, позволяя выставлять произвольные (из числа поддерживаемых видеоадаптером) разрешения. И уже появились сведения о включении соответствующих патчей в ядро FreeBSD.
Однако не только ограничения операционок не позволяют считать фрейм-консоль полноценной графической системой. Главное - крайне малое количество собственно графических приложений, способных использовать возможности Frame Buffer. В их числе, фактически, - вьювер графических файлов, средство для создания скриншотов, изначально текстовый браузер links - и все. Да, еще Mplayer, собранный должным образом, может прокручивать видео во фрейм-консоли. Впрочем, эта великая программа способна проигрывать видео и в чисто текстовой консоли - передавая его ASCII-символами (весьма занятное зрелище, доложу я вам - правда, к кину как таковому отношения не имеющее).
По всем указанным причинам графическая консоль не может рассматриваться в качестве самостоятельного режима: назначение ее - в расширении возможностей консоли текстовой. И потому далее, за исключением особо оговоренных случаев, различий между ними делаться не будет.
Второй способ реализации графического режима в свободных POSIX-совместимых операционках - с помощью специализированной библиотеки SVGAlib. Сама по себе она разработана для ОС Linux, однако скомпилированные с ее использованием бинарные приложения можно запустить на любой BSD-платформе в так называемом режиме Linux-совместимости (своего рода эмуляции, основанной на подмене системных вызовов).
Хотя запускать-то особенно и нечего: на SVGAlib основано едва ли с полдюжины приложений (в числе которых, правда, знаменитый Doom). А поскольку проект этот практически прекратил свое развитие, ожидать существенного роста программ не приходится. Так что роль SVGAlib оказывается еще более ограниченной, чем графической консоли.
Таким образом, практически единственным универсальным способом реализации графического режима в POSIX-совместимых ОС оказывается оконная система X (X Window System), или, в просторечии, просто Иксы. Ибо X - это ее имя собственное (возникшее потому, что исторически ей предшестоввала другая графическая система, именовавшаяся W), а Window в ее названии - прилагательное, призванное подчеркнуть ее оконную природу - в противоположность полноэкранным графическим системам. Ведь в прежние времена таких существовало немало (примером чему - та же SVGAlib).
Начинающими пользователями Linux Иксы воспринимаются как неотъемлемая часть этой операционной системы. Однако это не так: оконная система X создавалась совершенно независимо не только от Linux, но и от Unix вообще. И назначением ее было - обеспечивать графический режим работы на любых машинах, как-то способных вообще поддерживать графику, и поверх любых операционок.
Свободные реализации оконной системы X (а есть еще и сугубо коммерческие ее варианты, используемые в проприетарных Unix'ах) - "правильная" Xorg и "неправильная" Xfree86, - абсолютно идентичны в Linux'е, Free-, Net- и прочих BSD. И все приложения, написанные в расчете на запуск в абстрактных Иксах, будут с равным успехом работать в любой из этих операционок.
Главной составной частью Иксов вообще (и XFree86 или Xorg в частности) является программа, именуемая X-сервером (собственно, устройством X-сервера и его функциональностью и различаются разные варианты реализации оконной системы X). Она запускается непосредственно на данной машине, и взаимодействует с ее "железом" - устройствами ввода, то есть мышью и клавиатурой, и вывода - видеоподсистемой. А уже поверх X-сервера могут быть запущены разнообразные клиентские приложения. Причем, вопреки обычному пониманию терминов "клиент" и "сервер", именно они могут иметь своим местопребыванием не локальную машину, а любую другую, доступную по сети (опять же любой - локальной или глобальной).
Один из важнейших X-клиентов - программа терминального доступа, позволяющая эмулировать обычную текстовую консоль для ввода команд (и запуска любых программ вообще), почему ее и именуют еще эмулятором терминала. Таких эмуляторов существует великое множество, но минимум один - xterm, - всегда будет в распоряжении пользователя, так как входит в штатный комплект любой реализации Иксов.
Не менее важен и другой класс X-клиентов - программы управления элементами графического интерфейса, так называемые оконные менеджеры (Window Managers).Коих тоже преизрядное количество, но в состав Иксов стандартно входит лишь один - весьма архаичный twm.
Кое-что об Иксах уже говорилось во вводной части, подробностям же ее устройства будет посвящена специальная, 17-я, глава. А нам тем временем пора переходить к рассмотрению вопроса
Итак, пользователь получил доступ к ресурсам машины через терминал в текстовом или графическом режиме. А что дальше? А дальше ему требуется некая программа, обеспечивающая интерфейс для взаимодействия между ним, любимым, и операционной системой с протекающими в ней процессами и входящими в нее файлами.
За всю историю человечества было придумано лишь два принципиально различных класса интерфейсов (между прочим, это относится не только к околокомпьютерной сфере деятельности).
Исторически первым (и, замечу, наиболее естественным) способом взаимодействия пользователя с машиной (и всеми ее потрохами) был командный интерфейс, основанный на отдаче прямых директив. Обычно он осуществляется с помощью клавиатуры, однако теоретически можно использовать и любой другой способ ввода команд - скажем, щелчком средней клавиши мыши. Именно ему, под именем CLI (Command Line Interface - интерфейса командной строки) суждено было на долгие годы стать традиционным интерфейсом Unix (а затем и POSIX-совместимых операционок вообще).
За вторым способом взаимодействия человека и машины прочно закрепилось название графического (GUI - Graphic User Interface - графического интерфейса пользователя). Название, впрочем, не строгое - а в общем случае и просто не верное: ниже будут даны примеры такого рода интерфейсов, функционирующих в текстовом режиме; и напротив - командных интерфейсов, реализуемых в режиме графическом.
Основной принцип интерфейсов второго рода - отказ от использования прямых командных директив в пользу манипулирования объектами - файлами, каталогами, интерфейсными элементами и т.д., выполняемого обычно с использованием мыши. Хотя, как мы видели ранее, с помощью мыши можно и вводить прямые команды. А манипулировать объектами с помощью клавиатурных комбинаций также никто не запрещает. Разумеется, в конечном счете таким путем вызываются те же командные директивы, однако сами они остаются глубоко за кадром.
"Совершенно верное определение" подобрать затрудняюсь, но то, что именуется графическими интерфейсами, скорее следовало бы называть интерфейсами объектными, манипуляционными или как-то в этом роде. Хотя все эти термины неудачны - первый из-за ассоциации с ООП в понимании Грэди Буча (к коему в общем случае иметь отношения вовсе не обязан), второй - просто из-за трудновыговариемости.
Не вполне адекватен также термин "сенсуальные" интерфейсы, предложенный в свое время Максимом Отставновым. На основании того, что "звук стал их полноправной частью" (Максим Отставнов. Неимоверно важный Гном. Компьютерра, 2000, #45-46 (374-375), с. 26). До недавнего времени это - было не более, чем мечтой: почти никакой функциональной нагрузки (кроме более или менее мелодичных стонов и визгов) звук в компьютерной рабочей среде не нес. И дожить до полноценных голосовых (особенно русскоязычных) интерфейсов я не особенно рассчитывал. Хотя недавно в очередной раз был посрамлен в своем пророчестве: в KDE версии 3.4 управление голосом приобрело уже практический смысл. Однако использовать голосовые технологии для отдачи прямых командных директив будет ничуть не сложнее, чем для манипулирования объектами (на мой взгляд, даже легче).
В итоге я остановился на определении "визуальные интерфейсы", так как зрительный контроль действий в них абсолютно необходим. В отличие от сред командных, где теоретически вполне можно представить стучащего по клавиатуре вслепую оператора, обращающего взгляд на экран только для созерцания результата. Или - не обращающего вовсе, если результат его не очень интересует.
Для примера: вы пытались когда-либо объяснять по телефону, как выполнить с помощью компьютера некое действие? Если да - знаете, что при использовании DOS это вполне проходило, в Windows же - получалось скверно...
Так что впредь я применительно к интерфейсам, основанным на манипулировании объектами, призываю употреблять термин "визуальные" (за неимением пока лучшего). Исключительно как антитезу интерфейсам командным, предполагающим управление прямыми директивами. Собственно же слово "графический" следует оставить за определением режимом, альтернативного режиму текстовому, как было сказано в предыдущем параграфе.
Разумеется, между используемым режимом и типом интерфейса на практике есть некоторая, хотя и не однозначная, корреляция. Так, при консольном доступе (вне зависимости - в чисто текстовом же режиме или во фрейм-консоли) пользователь фактически обречен на использование той или иной разновидности CLI. Для чего ему служат программы класса командных оболочек (shells): одна из таких программ (login shell) запускается при авторизации в системе и берет на себя ответственность за интерпретацию и исполнение вводимых пользователем директив.
Говоря об обреченности, я не имею ввиду фатального принуждения. Ибо пользователю в качестве login shell вольно использовать чуть ли не любую программу, в том числе и обеспечивающую ему нечто вроде визуального интерфейса. И программы такие имеются - знаменитый Midnight Commander тому примером. Поскольку, не смотря на свою сугубо текстовую ориентацию, в основе его лежит именно манипулирование объектами, осуществляемое комбинациями "горячих клавиш". Другое дело, что очень быстро для пользователя становится ясным, что mc не делает ничего такого, чего нельзя было бы выполнить (и обычно - гораздо быстрее и проще) прямыми командами оболочки, да и в принципе не способен ни на что большее.
Тут-то и приходит осознание обреченности - в хорошем смысле этого слова, обреченности на более эффективные приемы работы. Вопреки мнению классиков советской фантастики, я не считаю ущемлением свободы обреченность на что-то хорошее - например, на любовь хорошей девушки. И к тому же, свободы выбора - обречь себя на любовь девушки нехорошей, - отнять у нас никто не в силах. Или, паче того, на любовь Midnight Commander'а - впрочем, это отдает уже некоторой нетрадиционностью ориентации.
За своеобычное лирико-дидактическое отступление не извиняюсь. Потому что в графическом режиме корреляция с типами интерфейсов еще сложнее. Начать с того, что сама по себе оконная система X (а мы выяснили, что это - единственный универсальный способ обеспечения графического режима) никакого пользовательского интерфейса вообще не обеспечивает, а служит лишь метаинтерфейсом для клиентских программ.
Среди клиентских Иксовых программ выделяется два важнейших их типа, которые и способны обеспечить пользовательский интерфейс внутри оконной системы. Это а) эмуляторы терминала и б) оконные менеджеры.
Так вот, пользователь, запустив совместно с Иксами эмулятор терминала, оказывается в самой что ни на есть командной среде - том же login shell, что и в чистой консоли. Где он точно также, как и в консоли, может вводить командные директивы - в том числе и на запуск истинно графических приложений. С той только разницей, что функционирует его командная оболочка в Иксовом окне, а не в полноэкранном (хотя и виртуальном) терминале.
Правда, воспользоваться прелестями оконного интерфейса он пока не в силах - ведь средств управления окнами (открытия, закрытия, масштабирования, минимизации и даже переключения между окнами), - у него нет. Чтобы получить такие средства, ему требуется еще одна клиентская программа - менеджер окон. И вот это уже - полноценный визуальный пользовательский интерфейс, он же - GUI в традиционной терминологии.
Существует многие множества оконных менеджеров - представление о их количестве можно получить на сайте Window Managers for X(http://xwinman.org/). Они различаются своей функциональностью: одни обеспечивают только базовые средства управления окнами (масштабирования, перемещения, переключения) и соответствующие интерфейсные элементы (кнопки минимизации, развертывания и т.д.). Другие же имеют развитые средства запуска программ, управления запущенными приложениями и т.д.
Особый вид X-клиентов представлен интегрированными графическими средами или, как их еще называют, десктопами. В их числе - KDE, GNOME, XFce. От собственно оконных менеджеров они отличаются тем, что, помимо собственно средств управления интерфейсом, включают в себя еще некоторое количество пользовательских приложений: программы эмуляции терминала, файловые менеджеры, браузеры, почтовые клиенты и прочие коммуникационные программы, текстовые редакторы и даже офисные пакеты.
Традиционно интерфейсы командного стиля противопоставляются визуальным интерфейсам. Основанием чему - абсолютно разные механически (даже, я сказал бы, физиологически) приемы работы в них. Однако обращение с автомобилем и, скажем, лошадью также требует совершенно разных приемов и навыков. Что не мешает в обоих случаях достигать одной и той же цели (транспортировки чего-либо или кого-либо). С различным, правда, успехом в разных условиях.
Аналогично и с интерфейсами. Множество задач целесообразно решать с помощью командных директив - примером чему пакетная обработка текстовых данных. В то же время, скажем, обработку изображений обычно легче выполнить в визуальной среде (хотя и здесь роль команд не следует недооценивать). И потому наиболее эффективным оказывается сочетание командных и визуальных методов. Благо POSIX-системы предоставляют богатые возможности комбинирования тех и других.
Назад Содержание Вперед
🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях
Виртуальные VPS серверы в РФ и ЕС
