Сразу оговорюсь, что прощаться я предполагаю не с консолью вообще, а лишь с консолью вне gui. То есть, для *BSD/Linux — это консоль без запуска X Window, для MS Windows — recovery console (или как это там у них называется). Что касается консоли, запускаемой из-под gui, то она, кажется, бессмертна. Как минимум, из-за удалённых сеансов (связь никогда не бывает "слишком" хорошей) и всевозможных "изощрённостей", писать gui-приложения для которых — просто бессмысленно. Последних предостаточно, кстати, не только в мире *-nix-ов, но и под MS Windows.
Если оставить в стороне случаи, когда вычислительная система никаких других средств общения с собой, кроме консоли, не предоставляет ("тут уж — что уж"), "чистая" консоль в сравнении с консолью в среде gui может быть привлекательна только своей экономичностью. Почему бы и не сэкономить экранную площадь, электроэнергию, время и глаза, наконец?
"Подопытный"
В качестве последнего воспользуемся ASUS EEE PC. Оснований предостаточно.
- Маленький, 7..9 дюймов экран. Ну, чего ради отдавать его под всякие панельки, док-бары и просто атрибуты окна, если меня в настоящий момент интересует, скажем, только текст или вывод nmap?
- Нестандартная геометрия — бич современной консоли. LCD-мониторы (а что, бывают другие?) хорошо воспроизводят только при одном, рекомендованном, разрешении. Отношение сторон экрана, отличное от 4:3, потребует разрешения, отличного от стандартов VESA. Ушли от VESA — прощай framebuffer, "покрывающий" разрешения от 640х480 до 1280х1024.
- Экономия электроэнергии лишней тоже не будет. Не из "глобальных" соображений, разумеется. Но если нетбук сможет жить без подзарядки дольше, а своей температурой перестанет напоминать щенка на ваших коленях — чем плохо?
- Время загрузки — около 25 сек... Не так уж и плохо, в общем. Но из этих секунд до трети уходит на загрузку X Window и всего, что за этим "тянется". Пустяки, в принципе, но — зачем, если в конкретном случае я не предполагаю этим пользоваться?
"Лаборатория"
Под "лабораторией" в данном случае понимается операционная среда: конкретный дистрибутив. В настоящее время на EEE PC можно инсталлировать хоть Fedora, хоть Gentoo, хоть Debian. А Ubuntu представлен сразу несколькими своими "потомками". Дистрибутивно-специфичным рассматриваемый вопрос как раз не является: способ организации пакетного менеджмента не интересует "ни капли". А вот конфигурация ядра — весьма. Поэтому и оговоримся, что всё, описываемое ниже, проделывается с ASUS EEE PC под управлением Eeebuntu 3.0 Standard.
Что касается конфигурации ядра, то существенным является наличие поддержки framebuffer (какая-никакая консоль у EEE PC и так есть. Мы хотим — "хорошую"). Драйвера поддержки framebuffer могут быть частью ядра или модулями из каталога /lib/modules/$(uname -r)/. В случае Eeebuntu 3.0 все драйвера framebuffer — модули.
Итак, хотим использовать маленький экран с максимальным качеством — произвольные фонт и кегль, 32-битный цвет символов и фона, минимальные издержки. Решение очевидно: графическая консоль — единственная консоль, имеющая место в Solaris и PalmOS, известная для i386 как framebuffer. Ничего особенно нового... кроме упомянутой выше геометрии экрана и нежелания составителей дистрибутивов "заморочиваться" этим вопросом: ну, не описан для vesa-framebuffer ни видеорежим 800x400, ни 1024х600. Нельзя его задать параметром загрузки "vga=XXX" и... ладно.
"Попытка — не пытка"
А мы — попробуем. Для начала "от греха" отключим графическую загрузку — "закомментируем" запуск gdm (или иного дисплей-менеджера) в файле /etc/X11/default-display-manager. Так мы защитимся от возможных конфликтов между загружаемыми драйверами и X Window.
Теперь уберём из параметров загрузки все "vga=XXX" и "video=..." (если они там есть, разумеется). Цель — заведомо не использовать framebuffer после старта системы (проверяем: устройство /dev/fb0 должно отсутствовать. Так же, как и каталог /sys/class/graphics/fb0).
Теперь смотрим: что за драйвера аппаратной поддержки framebuffer есть у нас в системе. Для этого можно проанализировать файл конфигурации ядра (/boot/config-2.6.28-12-netbook), секция Frame buffer hardware drivers или состав каталога /lib/modules/$(uname -r)/kernel/drivers/video/. Практический интерес представляют только два универсальных драйвера — vesafb и uvesafb, а также один "специфический" — драйвер присутствующего в системе видеоадаптера, коим для ASUS EEE PC является intelfb. Остальные могут оказаться интересными, если вы будете проделывать аналогичные операции с видеоадаптером вашего десктопа.
Для загрузки драйвера vesafb необходимо (и достаточно) указать среди параметров загрузки ядра 'vga=ask'. С таким параметром загрузка будет останавливаться, предлагая вам указать видеорежим или просмотреть список доступных вариантов. Здесь обнаруживается первый интересный факт. В зависимости от того, подключен ли к нетбуку внешний монитор, список разрешённых видеорежимов — разный. Это иллюстрация того факта, что видеоадаптеры Intel умеют читать DDC-данные подключенных мониторов, но не получают аналогичную информацию от экранов ноутбуков. Ну, поскольку выбирать-то (при отключенном внешнем мониторе) практически не из чего, то перейдём к следующему драйверу.
По поводу использования драйвера intelfb полнее всего на русском рассказал в своём блоге Кирилл Забарнюк aka mosquito. "Непримиримое" требование этого драйвера "задавать видеорежим при загрузке" (intelfb: Video mode must be programmed at boot time) делает описанный Кириллом способ (программирование видеорежима с помощью grub-2, благо последний имеет такую возможность) едва ли не единственно возможным. Способ работает, но "патчить" и компилировать grub-2 только для того, чтобы посмотреть, стоит ли полноценный framebuffer внимания, — не всякий захочет.
Более ленивым предлагаю загрузить драйвер uvesafb с помощью банальной 'modprobe' (а выгрузить можно с помощью столь же банальной 'rmmod'). Таким образом, мы можем убедиться, что, как и в случае с vesafb, переход в режим framebuffer имеет место: устройство /dev/fb0 появляется, команда 'fbset -s', как и положено, выводит полное описание моды, да и изображение на экране претерпевает изменения. Беда только, что графический режим 640x480, в котором мы оказываемся после включения framebuffer, не многим лучше алфавитно-цифрового 80х25, который имели без всех этих хлопот. Да, разнообразие загружаемых фонтов существенно больше, и увеличилась глубина цвета. Но... "не то". Поскольку 640x480 — это всё ещё не рекомендованные для этой матрицы 800х480 (или 1024х600).
Единственное полезное наблюдение — явное превосходство uvesafb над vesafb в скорости. Практически — безукоризненно. [Не]счастливые обладатели видеоадаптеров от AMD/ATI могут не возмущаться: framebuffer-проблемы с их адаптерами — "притча во языцех". Но это не повод отказаться от framebuffer на других адаптерах.
"Эврика"
Поскольку я, как и Кирилл Забарнюк, не остановился в своём любопытстве перед перекомпиляцией grub-2, то назначение утилиты 915Resolution было мне известно. Утилита эта всего лишь позволяет модифицировать копию BIOS видеоадаптера, уже находящуюся в памяти. Код 915Resolution, выполняемый ещё до загрузки ядра, перестраивает BIOS видеоадаптера, делая возможным выбор режима, недоступного без такой модификации. Понятно, что аналогичная модификация, выполненная уже после загрузки intelfb, для этого драйвера ровным счётом ничего не изменит. Но не окажет ли она влияние на работу драйвера, загружаемого после её выполнения? Например, uvesafb? Если известно, что загрузка драйвера framebuffer приводит, в конце концов, к переключению в совершенно определёныый "видеорежим по умолчанию", то почему бы именно для этого режима не изменить разрешение?
Пробуем...
- Со страницы Стива Томленовича (Steve Tomljenovic) можно загрузить исходный код 915Resolution. Но для особо ленивых есть ссылка и на deb-пакет.
- deb-пакет не нужно пытаться инсталлировать — во-первых, это невозможно (конфликтует с актуальным драйвером intelfb из состава X Window), а во-вторых, не нужно: требуется извлечь из него лишь саму утилиту 915Resolution.
- Запуск утилиты с ключом "l" (915Resolution -l) выведет список описанных в BIOS адаптера видеорежимов. Но ни режима 800х480, ни режима 1024x600 там, разумеется нет.
- Но ничто не мешает нам модифицировать какой-нибудь режим. Например: 915Resolution 32 800 480. Здесь 32 — номер режима (изначально: 640х480, 8 bits/pixel), 800 480 — желаемое разрешение.
- Повторный запуск '915Resolution -l' показывает, что изменился не только режим 32, но и остальные режимы, разрешение для которых задавалось как 640х480 (т.е. 8, 16 и 32 bits/pixel).
- Осталось загрузить драйвер: 'modprobe uvesafb' — и абсолютно функциональный framebuffer 800х480 в нашем распоряжении.
Детали
Нюансы некоторые имеются... Так, после перехода в режим framebuffer требуется перезагрузка фонта, содержащего кириллицу, а драйвер консольной мыши "не видит" расширившегося экрана. Проще, наверное, привести скрипт, который выполняет все необходимые операции:
/usr/bin/915resolution 30 800 480
modprobe uvesafb
/etc/init.d/console-setup reload
/etc/init.d/gpm restart
При этом, естественно, предполагается, что 915resolution переписана в /usr/bin/, а сервис gpm — инсталлирован. Численные значения в командах предназначены для разрешения 800х480 (701-й), для 901-го — они несколько другие, но затруднений, мне кажется, это вызвать не должно.
Приведенные выше команды можно включить в /etc/rc.local (выполнение при каждой загрузке) или оформить в виде отдельного скрипта, вызываемого при необходимости. Для выполнения скрипта потребуются административные привилегии. А воспользуетесь вы для этого sudo или заблаговременно отредактируете /etc/sudoers — это уж кому как больше нравится.
Ну, и ещё несколько советов для тех, кто собирается "побороться" описанным выше способом за консоль на Ubuntu.
- Отказавшись от автоматического запуска X Window (удалением имени дисплей-менеджера из /etc/X11/default-display-manager), запускайте Х-ы вызовом gdm. Канонический startx тоже, разумеется, сработает, но кое-какие апплеты панели можете потерять: не рассчитывали авторы на то, что схема загрузки будет так "раскурочена".
- Когда вам надоест менять параметры консоли рекомендуемым 'dpkg-reconfigure console-setup', познакомьтесь с файлом /etc/default/console-setup. Редактирование последнего намного быстрее, а может стать и необходимостью, если захочется иметь независимые настройки консоли и X Window.
- И загрузите, конечно, terminus: console-terminus для консоли и xfonts-terminus для X Window.
Выводы
Итак, прощаться с консолью (по крайней мере, из-за доминирующих тенденций в "экрано-строении") пока не обязательно. Трудности — преодолимы. Другое дело: "стоит ли овчинка выделки"? Спорить по этому поводу бессмысленно. Для не умеющего работать в консоли — нет, конечно. И, наоборот, — для умеющего данный вопрос аналогичен вопросу "а зачем нужны книги, если есть телевизор?".
Точно так же (то есть индивидуально) решается вопрос о целесообразности возни с "чистой" консолью. Изложенная выше история, кстати, закончилась вовсе не в пользу framebuffer. Выглядит он и правда неплохо, да только чтобы оценить это, мне, в частности, нужно одеть очки. А я этого не люблю даже в свои "за пятьдесят". Так что скриптик, незатейливо названный "h480", в /usr/bin "болтается", да и пользуюсь им я не так уж часто — в положении "без очков" банальная VGA консоль (80x25) оказывается на EEE PC вполне приемлемой.
Так что, если кто-то скажет, что мне "делать нечего", то я особенно возражать и не стану. Всё это действительно в большой степени делается "из любопытства". Just for fun, как известно...
