Дорога к UNIX’у. Период бури и натиска

Алексей Федорчук
Пролонгировано во времени…

Вторую половину 1990 годов и весь 2000 год целиком я посвятил знакомству с миром Linux’а во всём его разнообразии — по крайней мере с той его частью, которую смог охватить и успел окучить.

… дороги, каждая из которых
казалась когда-то дорогой в Ирам —
страну счастливых чудес…
Леонид Соловьев
Повесть о Ходже Насреддине

Дистрибутивы

За без малого полтора года я опробовал все дистрибутивы Linux’а, которые тем или иным путём смог заполучить. А пути эти были следующими:

1. Скачивание в виде iso-образов. Основным источником их в то время были Linux.tucows и Linuxiso. Времена были ещё вполне модемные, поэтому приходилось злостно пользоваться служебным положением и качать образы на службе — благо, к тому времени коннект у нас приобрел некоторую стабильность, да и скорость его существенно возросла. «Болванить» полученные образы тоже приходилось на службе: устройства CD-R/RW тогда еще не стали стандартным компонентом персонального компьютера. В частности, у меня его тогда и близко не лежало.
2. Далее, оказалось, что многие дистрибутивы, даже в нашей стране, можно приобрести в магазинах (например, в больших книжных, по крайней мере, в Москве) или заказать через системы онлайновой торговли (с доставкой по почте или курьером на дом): как раз тогда зародились первые специализированные Интернет-магазины. Цена в обоих случаях оказывалась сравнимой с ценой базарных дисков ворованного софта и посильной даже для научного сотрудника, которого рубеж тысячелетий не баловал излишними доходами.
3. Наконец, обнаружился и третий путь получения дистрибутивов — дружеский обмен, подарки и «взять на попробовать». Поскольку к тому времени у меня образовалось уже некоторое количество линуксоидов, знакомых по реалу, способ оказался довольно эффективным. Разумеется, предполагая полную взаимность отношений.

Тем или иным способом я получил на опробование следующие дистрибутивы:

• Slackware 7.1 — актуальная на момент опробования версия знакомого дистрибутива;
• Debian 2.2 — также последняя на тот момент версия, получившая имя одного из основных разработчиков дистрибутива, Джоэля Клекера (Joel Klecker), скончавшегося летом 2000-го в возрасте 21 года;
• StormLinux 2000 R 1.4 — первая попытка создания коммерческого дистрибутива на базе Debian, очень интересная с точки зрения заложенных в ней идей (не могу отделаться от ощущения, что он оказал если не прямое, то косвенное влияние на Ubuntu сотоварищи);
• Corel Linux — еще обна попытка коммерциализации Debian; распространялся в России отечественной фирмой CPS в сопровождении пакетов русификации, «позаимствованных» у Петра Новодворского, собиравшего их для русификации Debian;
• BlackCat 6.2 — разработка украинских майнтайнеров Леонида Кантера и Александра Каневского, позиционировавшаяся ими как «причесанный» Red Hat с улучшенной поддержкой кириллицы;
• Caldera OpenLinux 2.4 — с получением префикса «Open» она перестала быть клоном Red Hat, а стала вполне самостоятельным дистрибутивом с оригинальным и удобным инсталлятором, унаследовав от прародителя только формат пакетов (rpm);
• BestLinux 2000 R2 — дистрибутив финско-эстонского происхождения, использующий rpm-формат и образовавшийся под явным влиянием Caldera OpenLinux;
• Linux Mandrake 7.0/RE — предпоследняя в истории версия Mandrake RE и последняя, выпущенная IPLabs Linux Team;
• Linux Mandrake 7.1 — оригинальная версия французского происхождения, с которой я до того не сталкивался.

Какой из них каким способом получен — постараюсь вспомнить. Коробочный Debian, боксовые BlackCat и Mandrake RE были получены в подарок от IPLabs Linux Team. Боксовые Corel Linux в исполнении от фирмы CPS, если не изменяет память, одолжил «на попробовать» Федор Сорекс. Остальные были скачаны с Linuxis.

Из известных дистрибутивов за пределами рассмотрения остались, собственно, наиболее популярные уже тогда Red Hat и Suse Linux. Первый — поскольку рассматриваемый BlackCat, как уже сказано, представлял собой весьма точный, но, тем не менее, существенно исправленный и дополненный его клон. Suse же, в отличие от прочих дистрибутивов, в то время был принципиально платным (свободная trial-версия впечатления о дистрибутиве не давала — я в этом убедился еще раньше), да и получить его в России было проблематично. Некоторое время спустя товарищ по спецзаказу привез мне коробочную Suse из Америки, но это был уже другой перегон нашей дороги.

Судьба всех перечисленных мной дистрибутивов сложилась по разному. Slackware и Debian, как наиболее консервативные, хотя и каждая по своему, системы развиваются каждый в своем традиционном направлении.

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

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

Mandrake, после слияния с бразильской Linux-компанией Commectiva получившая имя Mandriva, также развивается в своеобычном направлении — в сторону всё большей юзерофильности и фронтирности, не смотря на уход основоположника и харизматического лидера — Гаэля Дюваля.

Однако еще задолго до этого, именно с оригинальной версии Mandrake 7.1, её пути со своей же Русской редакцией разошлись окончательно и бесповоротно. Правда, компания Altlinux, образованная на базе IPLabs Linux Team (точнее, скорей на базе кадров последней), выпустила еще один дистрибутив из серии Mandrake RE — 2001 Spring, — однако с французским первопредком он не имел почти ничего общего, кроме названия. А в дальнейшем и названия не осталось — выпускаемые компанией Altlinux унаследовали имя материнской фирмы.

Будучи немного в курсе дела (и основываясь на агентурных данных), попробую объяснить причины этого явления. Ведь, насколько мне известно, в планы Linux-команды IPLabs (превратившейся в фирму Altlinux) не входило создание собственного дистрибутива. По крайней мере, в ближайшей перспективе. Вместо этого предполагалось и дальше развивать интернационализацию Mandrake (существовали проекты по локализации для тюркских языков России и бывшего СССР).

Однако именно в версии 7.1 Mandrake, один из основоположников интернациональной Linux-дистрибьюции вообще, сделал странный зигзаг, отбросивший дистрибутив в этом отношении на годы назад. И новообразованной фирме Altlinux, команда которой съела не одну собаку по части русской локализации и интернационализации вообще, просто ничего другого не оставалось делать, как развивать прежнюю генеральную линию партии.

BlackCat как самостоятельное явление перестал иметь место быть в первой половине 2001 года, потому как его создатели вошли в команду разработчиков новорожденного тогда дистрибутива ASPLinux, рассказ о котором впереди.

StormLinux и Corel Linux прекратили свое существование вскоре после моего с ними знакомства. Но если для StormLinux это действительно был конец, то Corel Linux вскоре гальванизировали под именем Xandros, в качестве какового он и продолжает свое развитие.

Что же касается BestLinux, то за свою короткую жизнь он сменил несколько имен, пока под именем LBA-Linux не почил в Бозе.

Бесславная судьба Caldera Linux хорошо известна. После того, как компания Caldera превратилась в SCO и сделал ставку на распространение UnixWare в разных ипостасях, развитие дистрибутива прекратилось, а фирма-разработчик его переметнулась в стан классового врага и затеяла тяжбу с IBM, которая косвенно могла задеть интересы всего сообщества Open Source, но, к счастью, благополучно завершилась банкротством SCO.

Отчеты об опробовании очередного дистрибутива регулярно публиковались на страницах Byte/Unix, а конце концов завершились попыткой их сравнительного обзора и ранжирования по разным критерям, таким, как простота/сложность установки и настройки, конфигурирование графического режима, фунциональность штатного набора прикладных программ, и так далее. Пересказывать его содержание я не буду за неактуальностью большинства объектов. Назову лишь моих тогдашних фаворитов и аутсайдеров.

Первое место по всем практически показателям я отдал Mandrake Linux в русской редакции. Возможно, не вполне беспристрастно — именно этот дистрибутив был моей рабочей системой на протяжении всего периода «бури и натиска». прочие же ставились в целях опробования на свободные разделы, свободные винчестеры, буде таковые случались, а в конце и на виртуальные машины VMWare, которой я наконец нашёл полезное применение (до того VMWare служила мне исключительно как платфлрма для раскладывания «Солитёра»..

А вот на второе место по моей табели о рангах попала Slackware — и не только в силу давней симпатии. Просто уже тогда у меня подспудно начало складываться представление о двух принципиально различных, если не сказать антагонистических, классах дистрибутивов — «для всех» и «для себя». Представителей этих классов сравнивать между собой бессмысленно, можно лишь оценивать сравнительное качество реализации систем внутри одного класса.

Так вот, если из всего моего списка Mandrake RE был, безусловно, лучшим в классе «для всех». то Slakware, будучи единственной, но блестяще реализованной представительницей класса «для себя». не могла не оказаться на пьедестале почета.

Это что касается лидеров. Потому что аутсайдер был один, зато бесспорный — Corel Linux. Это был один из редких на моем пути дистрибутивов, о котором я не смог сказать никаких хороших слов, зато плохими, если бы не боялся смутить возможно читавших меня дам, мог бы наградить в избытке…

Рабочие среды

Опробованием дистрибутивов мои Linux-штудии не органичивались. Параллельно я взялся за опробование интегрированных рабочих сред и оконных менеджеров. Тут главной промывочной площадкой для меня стал основной рабочий инструмент — Mandrake 7.0/RE, благо этого добра в штатной его поставке было много, а при старте системы запускалась очень удобная программа wmselect (автор — Петр Новодворский), позволяющая выбрать подходящую среду для текущего сеанса работы.

В итоге я более или менее подробно ознакомился со всеми существовавшими тогда (и существующими по сей день) интегрированными средами (KDE, GNOME, Xfce) и с серией разномастных оконных менеджеров — WindowMaker, IceWM, FLWM, несколько позднее к ним добавились blackbox и fluxbox.

Мимо тогдашней классики жанра типа вариаций на тему FVWM, включая FVWM2 и FVWM95. но они меня настолько не впечатлили, что с тех пор я ни разу к ним не обращался. Хотя настраиваемость FVWM2 и оценил — но это дело требовало таких усилий, какие я счел для себя нецелесообразными. К слову сказать, один из моих знакомых, большой любитель FVWM2, постепенно довёл этот оконный менеджер до немыслимого совершенства и личного удобства. Однако, потеряв в результате какого-то сбоя свой конфиг для него (и не имея его копии), решил, что второй раз проделать работу по иеальной настройке FVWM2 ему не по силам — и перешел на какой-то другой оконный менеджер, более простой в конфигурировании.

Что же до прочих оконных менеджеров из числа перечисленных выше — каждый из них мне понравился по своему. Так, Window Maker я по сей день полагаю если не эталоном эстетического совершенства рабочей среды, то чем-то, асимптотически к нему приближающимся. Интересно, что родственный ему, внешне похожий Afterstep такого глубокого эстетического воздействия не оказывает — почему я, после поверхностного на него взгляда, и отказался от более близкого знакомства. Функционально же Window Maker, за счет многочисленных написанных специально для него дополнительных модулей, вплотную приближался к интегрированным средам (а тогдашнюю Xfce, изначально позиционировавшуюся в этом качестве, возможно, даже превосходил).

IceWM производит впечатление оптимальным балансом между гибкостью настроек (близкой к FVWM2, к которому он генетически восходит) и их простотой — как вручную, так и посредством собственного графического конфигуратора.

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

Отступление. Надо сказать, что долгое время я работал преимущественно в консоли, а Иксы использовал для запуска единичных приложений, графических или офисных, без которых было не обойтись. Это не было связано с какими-либо идеологическими соображениями — просто при работе по преимуществу с текстами (а именно с ними я тогда в основном и работал) стандартный режим текстовой консоли (80×25) был много комфортней для глаз, чем любые реально возможные графические, особенно на 15- и даже 17-дюймовых трубочных мониторах весьма среднего качества (мониторы качества выше среднего были финансово обременительны и ничего кардинально не меняли).

Это было обусловлено особенностями как «трубочных» технологий вообще (независимо от типа маски), так и оконной системы X с ее очень посредственными тогда кириллическими шрифтами и их вполне скверным рендерингом. Тогда как растровые шрифты консоли всегда выглядели примерно одинаково и вполне пристойно.

Примирило меня с графическим режимом появление LCD-мониторов по доступной цене. С одной стороны, трудно было придумать что-либо более удручающее, нежели стандартный текстовый режим 80×25 даже на 15-дюймовой LCD-панели с разрешением матрицы 1024×768, не говоря уже о больших диагоналях и более высоких разрешениях. А уж при вскоре вошедших в моду экранах с пропорциями 16×9 — один вид текстовой консоли вызывал ужас. Конечно, можно было бы поэкспериментировать с настройками фреймбуфера, но это не всегда проходило (о причинах сейчас распространяться неуместно).

А с другой стороны, в Иксах начали появляться нормальные шрифты. Сначала это был пакет corefonts, в который собрали базовые шрифты от классового врага, скапитализженные, однако, на вполне законном основании, такие как Arial, Courier New, Times New Roman (правда, я никогда не разделял восхищения шрифтами из комплекта MS Windows — на мой взгляд, это далеко не самое высокое достижение фирмы Monotype, изготовившей их по спецзаказу). Далее появились шрифты Валентина Филиппова, шрифты от Monotype, распространяемые Novell в составе дистрибутива Suse и, наконец, шрифты DjVu от сообщества и Liberation, созданные в Red Hat. Да и рендеринг шрифтов в современных версиях Иксов не идет ни в какое сравнение с тем, что было ещё несколько лет назад.

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

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

Функциональность и настраиваемость KDE я оценил сразу, с первой же версии. Это уже тогда действительно была интегрированная среда с единым интерфейсом штатных приложений (которые просто работали), готовая к практическому применению «из коробки». Но и могущая быть настроена весьма произвольным образом. Даже ярко выраженная топорность интерфейса, вызывавшего ассоциации с индустриальными пейзажами или футуристическими картинами антиутопий, не очень портили впечатление — хотя к эстетике рабочей среды я всегда был весьма чувствителен.

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

Что же до функциональности и настраиваемости, то тут KDE развивалась строго линейно по восходящей, как будто в рамках жестко заданного плана (а может быть — и без всякого «как будто».). То есть количество штатных приложений для этой среды росло, функциональность и степень интеграции их увеличивалась, не теряя при этом исходной модульности.

Приложения, не выдержавшие проверку временем, исключались из штатного комплекта, заменяясь аналогичными по назначению — либо специально разработанными в рамках проекта KDE, либо привлеченными из обширного круга программ, создаваемых KDE-сообществом. Примером последнего явления можно считать судьбу html-редактора Quanta Plus. Созданный первоначально в рамках самостоятельного проекта, он со временем был интегрирован собственно в KDE и ныне составляет основу пакета инструментов web-разработчика.

Особенно большая «текучесть кадров» наблюдалась в области мультимедийных приложений. Давно ушли в небытие аудио- и видеопроигрыватели первой версии, типа aKtion. Не обрёл большого признания и штатный (поныне) медиаплейер — Noatun. И в итоге ныне наибольшую популярность среди пользователей KDE снискали аудиоплейер AmaroK и медиаплейер (но преимущественно видеоплейер) Kaffeine. Причем ни тот, ни другой в штатный комплект KDE не входят и, из-за собственных релиз циклов, скорее всего, в ближайшее время не войдут.

Отдельная песня — это развитие KDE-средств управления файлами. Началось всё (как раз в описываемый период господства версии 1-й версии) с примитивного explorer-подобного файлового менеджера kfm. Однако в уже существовавшей тогда версии 2 (она не считалась стабильной и рекомендовалась к использованию только в экспериментальных целях) он был заменен на konqueror — весьма своеобразное сочетание файлового менеджера и web-браузера. И в дальнейшем обе ипостаси этой программы развивались очень активно, пока в версиях 3.5.x средства управления файлами не достигли совершенства, а браузер не превратился в полнофункциональный инструмент для Интернет-сёрфинга, и к тому же в своего рода эталон следования стандартам W3C. Что, замечу в скобках, и препятствовало его широкому распространению, поскольку всякого рода системы онлайновых расчетов и покупок клали на эти стандарты с большим таёжным прибором, и даже Google до сих пор не включил konqueror в число полностью совместимых со своими сервисами.

Конечно, за прошедшие годы и версии среда KDE стала намного больше (а покажите мне программу, которая бы имела тенденцию к «усыханию» со временем) и требует всё больше ресурсов. В описываемый период она спокойно крутилась на 64 Мбайтах, а уж на 96 — показывала себя во всей красе; ныне же комфортный минимум для KDE я всё-таки определил бы в 512 Мбайт. Возрастала и сложность настройки. А уж неочевидность разнесения настроечных параметров по пунктам меню так и осталась унаследованной от 1-й версии.

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

Вы скажете, что всё это сложно и требует времени на освоение? Да. Но KDE — это как раз тот случай, когда можно проследить прямую корреляцию между усложнением настройки и богатством её возможностей. Так что за всё в жизни приходится платить — к этому вопросу мы еще вернемся в следующей серии мемуаров.

Ситуация несколько изменилась с выходом версии 4.0. В ней, например, за konqueror’ом оставлены по умолчанию только функции браузера, а в качестве штатного средства управления файлами использутся Dolphin — весьма примитивный инструмент на уровне Thunar’а, с которым мы со временем познакомимся, или GNOME’вского Nautilus’а. И вообще, похоже, что в 4-й ветке KDE взят курс на упрощение всего, что можно упростить.

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

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

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

Так вот, на рубеже тысячелетий (и ранее) в качестве менеджера окон по умолчанию в GNOME использовался Enlightenment. Это былп программа красоты совершенно неописуемой, однако настолько сложной в настройке и использовании, что к практическому применению практически непригодной (повторяю, речь идет о «том времени» — про ныне тестируемую версию 0.17 говорят, что она стала не только красивой, но и удобной). Во всяком случае, я его не осилил — почему он и отсутствует в моем списке.

В GNOME Enlightenment выполнял как бы роль фона, и потому его недостатки не имели возможности проявиться. А вот красоты — оставались. И потому GNOME производил большое впечатление, местами даже на таких пользователей, как я — тех, кто относится ко всякого рода «архитектурным излишествам» как минимум равнодушно (а то и резко отрицательно).

Но вот внутре… Внутре GNOME выглядел гораздо хуже. Начать с того, что в то время он был просто пожирателем ресурсов. На той же машине с 64, а в дальнейшем 96 Мбайт памяти, где KDE чувствовал себя сначала вполне сносно, а потом и вольготно, GNOME, даже без всяких приложений, умудрялся сожрать всё, до чего мог дотянуться, в том числе и swap-раздел — индикатор активности винчестера, как я уже упоминал, не гас ни на мгновение от момента старта этого десктопа до выхода из него.

Далее. Если KDE с самого начала обладала стройным и логично организованным набором приложений, то GNOME в этом ракурсе производил впечатление эклектической мозаики. Да так оно на самом деле и было — а во многом и остается по сей день. И для объяснения причин тому стоит несколько углубиться в историю.

Если KDE основывалась на библиотеке Qt, статус лицензии которой в то время был еще не вполне определенным, то для GNOME, естественно, решено было взять за основу абсолютно свободную библиотеку. Одна беда — таковых в природе почти не существовало: наиболее развитая и распространенная библиотека, Motif, имела тогда абсолютно коммерческий статус, а ее свободный аналог, Lesstif, настолько уступал ей функционально, что далеко не все Motif-приложения можно было собрать при его использовании (или требовались строго конкретные версии Lesstif).

И тут будущим разработчикам GNOME — Мигелю де Иказа и Федерико Мена — на помощь пришел случай. Незадолго до того, как они задумали свой проект, была начата (в 1995 году) разработка графического редактора GIMP. Который, столкнувшись с проблемой библиотек, решил её кардинально, а именно: разработал свою собственную библиотеку, Gtk (GIMP ToolKit).

Вот за нее-то и ухватились разработчики GNOME, положив в основу своей среды библиотеку — саму по себе хорошую, но разработанную для совершенно иной, и узко конкретной цели. Далее мы увидим, что стремление «ухватывать» было отличительной особенностью проекта GNOME на протяжении всей его истории. Судя по всему, его авторы руководствовались принципом, сформулированным Владимиром Асмоловым в песенке Ностальгия:

Вспомни наш лозунг,
Простой как природа —
Всё для народа,
Что плохо лежит.

Справедливости ради следует отметить, что они были не одиноки, и на основе Gtk было написано немало приложений — кросс-платформенный текстовый процессор AbiWord, редактор изображений и видео cinepaint, браузеры семейства Gecko, ряд «прожигалок» CD/DVD, множество аудио- и видеоплейеров, и так далее. Однако собственно GNOME-приложения в этом ряду можно сосчитать по пальцам — на память, если не брать в расчет единичные программы «из комплекта». типа Gedit, Nautilus, Evolution, приходят разве что электронная таблица Gnumeric и «прожигатель» Gnomebaker. Что не мешает разработчикам GNOME считать все Gtk-приложения неотъемлемыми составными частями своего десктопа, а майнтайнерам дистрибутивов — собирать их с использованием библиотек GNOME. Хотя, повторяю, подавляющее большинство Gtk-приложений вполне способно обойтись без этого, ничего не теряя в своей функциональности.

В результате и образовалась та эклектическая мозаика, которая носит имя интегрированной рабочей среды GNOME. И если KDE можно сравнить с монолитным диабазовым блоком, то GNOME — это слабо сцементированный конгломерат, не прошедший до конца даже стадии диагенеза. То есть — заимствованная библиотека, изначально узкоцелевого назначения, заимствованные приложения, даже оконный менеджер — и то заимствуется в соответствие со списком совместимости.

Что же объединяет всю эту массу? Может быть, генеральная стратегическая идея? Ничего подобного, генеральная линия развития GNOME на моей памяти менялась трижды. Сначала главной идеей этого десктопа было — создать рабочую среду, не похожую ни на что. Этим был обсловлен и выбор Enlightenment как оконного менеджера по умолчанию — он действительно делал GNOME не похожим ни на что. Даже на сам Enlightenment…

Затем приоритеты разработчиков изменились, и их лозунгом стало: создать среду «виндее всех виндей». Судя по всему, они в этом не сильно преуспели, потому что…

… потому что выдвинули новую концепцию, развиваемую и по сей день: упростить настройку среды и работы в ней до предела, доступного пониманию любой кухарки. И вот на этом поприще их ждал успех — GNOME действительно стал очень простым, что позволило ему повысить скорость работы: впервые по визуальному быстродействию он превзошел KDE. И, пожалуй, обошел её по числу пользователей.

Впрочем, последнее обусловлено не столько несравненными достоинствами GNOME, сколько тем, что он принят в качестве среды по умолчанию в самом популярном дистрибутиве эпохи — Ubuntu. Kubuntu и Xubuntu, использующие в качестве десктопов KDE и Xfce, соответственно, по распространенности отстают от своего старшего сородича на порядок и не пользуются такой поддержкой ни со стороны фирмы-матери, Cannonical, ни со стороны независимых разработчиков.

Что заставило Марка Шаттлворта избрать для своего флагманского продукта GNOME, а не KDE? Сам он объясняет это тем, что во время подготовки первого релиза Ubuntu (2003-2004 годы) GNOME превосходил KDE функционально. Но это не так: как ясно из моих предшествующих мемуаров, я слежу за развитием этих сред с 1998 года. И за всё это время не помню ни одного отрезка времени, в течении которого можно было бы констатировать функциональное отставание KDE от GNOME.

Мне кажется, что Марк тут несколько лукавит. На момент выхода Ubuntu уже существовали базирующиеся на Debian дистрибутивы, ориентированные на ту же нишу, что и она, продвигавшие ту же идею — простой установки и настройки для конечного пользователя (Xandros, Lindows/Linspire, MEPIS). И все они в качестве десктопа использовали KDE. Так что возможно, что Марк просто захотел быть оригинальным. Ну и заодно чтобы его детище не путали с близкими по целям дистрибутивами…

Как вы, наверное, поняли, я не люблю GNOME — как не глянулся он мне тогда, почти 10 лет назад, так и нынче не впечатляет. Вы можете сказать, что я просто не умею его готовить. И я с этим соглашусь: да, не умею, и не испытываю ни малейшего желания научиться. Почему? Продолжу аналогию с кошками из той самой анекдотической рекламы, вошедшей в русский фольклор.

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

О Xfce подробный разговор впереди, поэтому здесь я лишь кратко остановлюсь на своих тогдашних впечатлениях от этой среды. Первое впечатление — в тогдашнем своем виде Xfce очень напоминала CDE, основную и единственную интегрированную графическую среду для всех коммерческих UNIX’ов. И явно задумывалась под сильным её влиянием. Очевидные же внешние различия между CDE и Xfce были обусловлены разными библиотеками, лежащими в их основе: Motif в первом случае и Gtk — во втором.

Второе впечатление — то, что Xfce полностью оправдывала свое имя, один из вариантов расшифровки которого был таков: The Free Cholesterol Desktop Environment, что применительно к случаю я перевел бы как Настольная Среда для Холериков. В этом можно было убедиться при первом же её запуске: все работало исключительно быстро, как бы повинуясь импульсу. Пользователям ныне развиваемой 4-й версии это трудно представить: Xfce по прежнему быстра, но вот тогдашнее ощущение импульсивности практически полностью утрачено.

С точки зрения своего функционвала Xfce далеко отставала не только от KDE, но и от GNOME. И вообще, титул интегрированного десктопа для Xfce в то время был скорее заявкой на будущее, нежели отражением существующего положения дел.

Тем не менее, и Xfce мне тоже понравилась — не в последнюю очередь благодаря набору со вкусом подобранных тем, отсутствию «архитектурных излишеств». столь характерных для тогдашнего GNOME и аккуртности исполнения интерфейсных элементов, резко констатировавших с индустриализмом KDE.

Вот собственно и всё, что можно сказать о графических интерфейсах того времени. Перехожу к последнему объекту моих тогдашних изысканий — прикладным программам настольного назначения.

Приложения

Из всего изобилия прикладных Linux-программ меня в первую очередь интересовали следующие их категории:

• текстовые редакторы;
• текстовые процессоры и вообще офисные пакеты;
• средства web-разработки;
• средства обработки изображений, в том числе специфических.

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

Текстовые редакторы

Начнем с текстовых редакторов — я достаточно быстро понял, что в Linux это много более эффективные инструменты для создания и обработки текстов, нежели офисные пакеты, с которым плотно ассоциируют эти задачи пользователи Windows.

Для начала я обратился к классике жанра — редакторам Vim и Emacs. И быстро понял, что это не моё. В Vim я никак не мог распутаться с его многочисленными режимами и горячими клавишами. И к тому же никак не мог отделаться от мысли, что, осваивая его, занимаюсь пустым делом: созданный программистами для программистов, он прекрасно подходил для набора и редактирования исходников программ, но, видимо, не задумывался как средство работы с нарративными текстами, а именно с ними мне и приходилось иметь дело.

Возможно, если бы в процессе знакомства с Vim (или еще раньше) прочел статьи Владимира Попова, посвященные этому редактору, я изменил бы своё мнение и затратил бы на его освоение усилия, достойные этого замечательного редактора. Но увы — статьи эти тогда еще не были им написаны.

Emacs мне поначалу понравился и показался более понятным. Я довольно быстро освоил базовые принципы его работы и приобрел практические навыки, благодаря чему начал сочинять в нем практически нужные мне по работе тексты. И уже было подумал, что свяжу свою судьбу с этим редактором, тем более что располагал Столлмановским руководством по нему в русском переводе (за что спасибо IPLabs Linux Team — и за издание перевода, и за то, что эта книга попала мне в руки).

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

И я обратился к консольным редакторам попроще, каковых обнаружил четыре: встроенный в Midnight Commander Mcedit, который, однако, можно было использовать и самостоятельно, несколько похожий на него, но наделенный большими возможностями Jed, предельно простой редактор Pico и внешне ничем не примечательный Joe.

Ни Mcedit, ни Jed не произвели на меня большого впечатления. Я никогда не был поклонником Командира Нортона, и его геральдические цвета не вызывают у меня ностальгических воспоминаний. Хотя нельзя не признать, что Mcedit вполне удобен для быстрого редактирования конфигов и тому подобных манипуляций. Однако для этих целей удобней был бы Pico — я о нем не буду говорить, потому что со временем дойдет дело до более подробного рассказа о его прямом потомке — nano.

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

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

В отличие от меню-ориентированных Jed и Mcedit, Joe — редактор командно ориентированный. То есть все действия в нем осуществляеются не выбором соответствующих пунктов меню, а прямыми директивами. И основным средством навигации служат не клавиши управления курсором, а управляющие последовательности клавиш (key bindings), как в Vim или Emacs.

Кстати, управляющие последовательности в Joe похожи на таковые в Emacs, но существенно проще: поскольку возможности Joe уже (хотя оказались более чем достаточными для моих целей), то в нем не возникает необходимости в излинем усложении доступа к ним. К тому же оказалось, что управляющие последовательности Joe почти идентичны таковым редактора Multiedit, который в DOS’лвские времена под русским псевдонимом Фотон я использовал достаточно регулярно. И, следовательно, основные приёмы работы и в Joe оказались мне знакомыми.

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

• в Vim создание макросов упрятано достаточно глубоко,
• в Emacs, плюс к этому, требует еще и хоть какого-то предсьтавления о языке LISP (только его мне и не хватало, в свое время при попытках заняться экспертными системами мне хватило Prolog’а),
• в Jed методы создания макросов показались мне запутанными — сейчас уже не помню, почему,
• ну а Mcedit просто поддерживает очень ограниченное (десяток или два) количество макросов, после чего более старые затираются новыми.

В Joe процесс создания макросов был (и остается) простым до предела. Прототип макрокоманды возникает так:

• включается режим протоколирования действий;
• будущему макросу присвивается номер (от 0 до 0), который служит (пока) как его именем, так и вызывающей клавишей;
• требуемые действия (последовательно наживаемые управляющие клавиши и клавишные комбинации, а ткже ввод текста, если это нужно) выполняются с одновременной их записью в макрос;
• содержимое запротоколированного макроса вызывается на экран (где он выглядит, как обычный текстовый файл) и, при необходимости, редактируется;
• после этого текст макроса заносится в соответствующую секцию конфигурационного файла ~/.joerc, и ему приписывается горячая клавиша для вызова взамен ранее использованного номера.

Таким образом Joe совершенно элементарно можно было превратить, например, в специализированный редактор HTML-кода с автоматическим вводом всех необходимых тэгов.

А надо сказать, что к тому времени я, намучавшись с форматами файлов текстовых процессоров еще в DOS’овские времена, пришел к выводу, что оптимальным форматом для сочиняемых мной текстов является именно pure HTML. Почему? Нетрудно ответить.

Во-первых, подобно plain text, html-документ может быть прочитан всегда и везде, но, в отличие от «голого» текста, в документ можно внести структуризацию и разметку, которые будут визуально представлены определенным образом.

Во-вторых, при необходимости html-документ может быть отредактирован в любом текстовом редакторе, подвернувшемся под руку.

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

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

С тех пор все свои статьи, книги, служебные документы я сочинял исключительно в html-формате (с некоторыми оговорками делаю это и по сей день). И много лет использовал для этой цели именно Joe. А пути наши разошлись, когда я, желая присоединиться ко всему прогрессивному человечеству, перешел на Unicode. Я — перешел, а Joe — еще нет. А когда он тоже совершил этот судьбоносный шаг, я уже прочно перещел на nano как простой редактор конфигов, и на более иные специализированные средства — для более серьёзной работы. Впрочем, по Joe я иногда тоскую — ибо нынче он стал еще лучше, чем был, научившись, в частности, подсветке синтаксиса.

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

Поскольку практическую работу в Linux я начинал в среде KDE, то естественно, что и знакомство с текстовыми редакторами графического режима я начал со штатных редакторов этого десктопа. В версии 1 это были Kedit и Kwrite, в версии 2 к ним добавился Katy.

О Kedit и Kwrite говорить особо нечего, они по сей день входят в состав KDE и ничуть не изменились, так что любой желающий может просто открыть их и любоваться их возможностями (для Kedit, скорее, отсутствием таковых).

А вот Katy тогда находился в зародышевой стадии своего развития: первая увиденная мной его версия носила номер 0.2.3 и не умела делать почти ничего необычного, кроме разве того, что открывать новые файлы во вкладках (tabs) — тогда это было весьма необычно. Много еще воды утечет, пока Katy, переименовавшись в Kate, станет одним из лучших текстовых редакторов для Иксов.

Одним из — потому что пальму первенства среди Иксовых текстовых редакторов я отдаю Nedit — как тогда, так, с неоторыми оговорками, и сейчас. Основанный на библиотеке Motif (но могущий быть собранным и с Lesstif), он не привязан ни к какой из существующих рабочих сред и даже операционных систем: существовали (и существуют по сей день) сборки Nedit (в том числе статические, не требующие установки дополнительных библиотек вообще) для всех коммерческих UNIX- и всех свободных Unix-подобных систем (включая MacOS X); имеется даже Cyrwin-версия для Windows.

О достоинствах Nedit можно было бы говорить очень долго. Здесь и его исключительно гибкая настраиваемость, удобство средств редактирования, чрезвычайно развитая система макросов на языке, сходном синтаксически с языком C-shell, причем основа для макросов также просто создается протоколированием действий, и многое, многое другое. И до поры до времени я все эти достоинства активно пользовал…

Всё, как и в случае с Joe, разбилось об Unicode. Сначала Nedit не поддерживал работу с 16-битной кодировкой вообще. Потом поддержка Unicode была декларирована, но не работала. Потом стала работать, но через пень-колоду, что продолжается и по сей день. А учитывая, что последний (5.5) релиз редактора датируется осенью 2004 года (с тех пор добавились только сборки для Solaris и MacOS X), ожидать, что работа с Unicode когда-нибудь будет доведена до ума, увы, не приходится…

Офис

В офисной сфере в те времена, если говорить в мировом масштабе, существовало всего два интегрированных пакета Applix, разрабатывавшийся немецкой фирмой Applixware, и StarOffice от столь же немецкой компании StarDivision. Оба они не были ни свободными, ни открытыми, ни, даже, строго говоря, бесплатными. Хотя и допускали бесплатное некоммерческое использование на определенных условиях (каких именно — уже точно и не упомню).

Говоря о мировом масштабе, я подразумеваю, что Applix на российских просторах никакого распространения не получил: штатно он кириллицу не поддерживал, прикрутить её простыми способами было невозможно, а копание в исходниках запрещалось лицензией, да и недоступны они были, эти исходники. Так что забудем о нем, тем паче, что пакет этот в 2000 уже году прекратил свое развитие, а со временем и фирма Applixware была куплена фирмой — разработчиком систем управления производительностью бизнеса.

Что же до StarOffice, то её длинную зигзагообразную историю я расскажу в соответствующей интермедии — после главы, посвященной описанию наследовавшего ему пакета OpenOffice.org.

А вот о чем стоит упомянуть — так это о Lyx, который представляет собой нечто среднее между текстовым процессором и программой верстки. Основное его назначение — не столько создание текстов (хотя можно делать и это), сколько приведение их в «товарный вид» для печати. Не глянцевых журналов, а всякого рода препринтов, брошюр, даже книг, содержащих таблицы, векторные изображения, споровождающиеся оглавлениями, указателями, библиографией и тому подобным аппаратом, который принято называть научным. В принципе, всё это могут и обычные текстовые процессоры класса MS Word и OpenWrite. Однако каждый, кто хоть раз видел книжку или брюшюру, «сверстанную» в Word, подтвердит, что её происхождение опознается безошибочно с любого расстояния. Lyx же гарантирует заведомо не отвратительный результат даже для лиц, не имеющих ни малейшего представления о полиграфии…

В те времена, о которых идет речь, Lyx имел некоторые проблемы с русификацией, требовавшие не вполне тривиальных действий. В дистрибутивах отечественного происхождения (Mandrake RE и BlackCat) эти действия уже были проделаны их майнтайнерами, в прочих же — как говорится, были делом рук самих утопающих. И потому утопающие довольно активно описывали процесс полной и окончательной русификации LyX — почин положил Владимир Игнатов, которому потом присоединились Алексей Крюков и автор этих строк.

Со временем проблема русификации LyX исчезла — ныне он вполне по русски разговаривает, будучи только что установленным.Но лично для меня отпала и необходимость в нем вообще, поскольку много лет мне не требуется готовить документы в приличном виде. Однако тем, кому это надо, советую обратить внимание на LyX — это будет много проще, а результат получится заведомо лучше, нежели при использовании любого текстового процессора из «большой Linux-тройки» (OpenWrite, KWord, AbiWord), даже в том случае, если вы не можете отличить «вдову» от «сироты».

Web-редакторы

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

Больниство из них либо канули в небытие, либо влачат вялотекущее существование. Кому теперь что-нибудь говорят такие названия, как WebMaker, KDreamSite или Bulldozer? Их нет уже с нами, хотя в описываемое время первый в этом списке был практически единственным реально работающим html-редактором, причем с нормальной поддержкой кириллицы (то и неудивительно, так как он был написан нашим соотечественником Алексеем Децем). Однако именно в описываемый период он прекратил свое существование, и следы его, как и следы автора, затерялись в просторах Интернета.

Однако дело его не пропало. Примерно в то же время я получил от киевлян Дмитрия Поплавского и Александра Яковлева письмо c предложением ознакомиться с html-редактором Quanta, который они написали совместно с норвежцем Эриком Лаффуном (Eric Laffoon), и высказать свои впечатления. Я это проделал, то есть ознакомился, и высказал свои соображения не без удовольствия. Не смотря на то, что речь щла об очень ранней версии (типа 0.2, точно уже не помню), ещё не полнофункциональной и содержащей неизбежные на этой стадии ошибки, потенциал программы просто просвечивал сквозь всё это.

В дальнейшем я следил за развитием проекта вплоть до появления стабильного полнофункционального релиза (1.0) и позднее, вплоть до сего дня. Ныне Quanta (точнее, Quanta Plus) составляет основу пакета kdewebdev, штатно входящего в среду KDE, и являет собой (не побоюсь громких слов) непревзойденный инструмент web-разработки для Linux.

Правда, еще до этого проект разделился на две ветки: коммерческую KDE Gold, основанную только на библиотеке Qt, и свободную Quanta Plus, использующую kdelibs (и Qt лишь опосредованно). Причем, насколько мне известно, основоположники проекта занимаются ныне коммерческой версией. Мне не довелось её не то что пощупать, но даже увидеть. Однако, судя по обзору в журнале Линуксформат, коммерческая версия существенно уступает своему свободному собрату по функциональности.

Если Quanta Plus была полноправным KDE-приложением сначала de facto, а потом и de jure, то с доугой стороны баррикады, со стороны Gtk/GNOME, ей противостояли два основных противника — Bluefish и Screem.

Bluefish принадлежит к числу старейших html-редакторов — впервые я это название услышал где-то году в 1997-1998. И, разумеется, никакого отношения к GNOME он тогда иметь не мог, за отсутствием или младенческим возрастом последнего. В дни моего первого с ним знакомства ничего выдающегося он из себя не представлял, но являл собой добротный и надежный рабочий инструмент. Позднее Bluefish обзавелся поддержкой проектов и прочими атрибутами развитого html-редактора, но до уровня Quanta ему, думаю, еще далече и поныне.

В отличие от Bluefish, Screem со дня своего появления на свет (а оно, вопреки многочисленным заявлениям в Сети и на бумаге о младости этого редактора, относится самое позднее к 2000 году — ну оно и понятно, и в Сети, и за бумагой сидят не чукчи-читатели, а чукчи-писатели) поражал заложенными в нем возможностями: очень развитым редактором html-кода, хорошо задуманной поддержкой проектов, работой с кодом Java, JavaScript и PHP, возможностью визуализировать редактируемый код. Тогда всё это было в новинку — например, поддержки проектов ещё не было ни в одном web-редакторе для Linux, даже в Quanta Plus, которая позднее блистала в этом отношении.

Все эти возможности были реализованы в течении долгого времени, и сегодняшний screem весьма отличается от того, что под этим именем можно было увидеть 7-8 лет назад. Лишь одно качество у этой программы осталось неизменным. И это, увы, устойчивость, вернее, её отсутствие. Правда, если в описываемые времена я не встречал версии screem, которая проработала бы подряд 10-15 минут, то сейчас срок его непрерывной работы возрос в два или три раза. Что, согласитесь, не очень много…

Графика

Средства работы с изображениями в Linux в те времена были весьма разнородны во всех отношениях. Так, в области растровой графики уже тогда, как и сегодня, заслуженно первенствовал GIMP. И, как и сегодня, его уже тогда прочили на замену Photoshop’у, разумеется, тоже тогдашнему.

Были и довольно многочисленные средства обработки растровой графики с трубой пониже и дымом пожиже, нежели GIMP: Electric Eyes, XV, XPaint и еще несколько, имен которых я уже и не упомню. В памяти отложилось только, что ни одна из них не блистала ни богатством возможностей, ни удобством использования. А некоторые, как XV. еще и вызывали сомнения с точки зрения лицензии.

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

Явление это гордо называли портированием Windows-программ под Linux. Баловались им мелкие фирмы, выпускавшие платный проприетарный софт под Windows и одновременно — «прикрученные» к Linux’у его бесплатные или условно-бесплатные версии. Не брезговали этим приёмом и такие гиганты софтверной индустрии, как Corel. По сей день среди пользователей Linux бытует легенда о том, что некогда эта фирма выпускала Linux-версии своих программ, таких, как Corel Office (собранный с миру по нитке и на живую же нитку сшитый комплект из текстового процессора WordPerfect, электронной таблицы QuattroPro и средства для создания и проведения слайд-шоу Presentation), и даже фирменный флагман — CorelDRAW. Причем распространяла их за деньги, и не очень малые.

Я все эти псевдо-портированные программы устанавливал (каюсь — в пиратском исполнении, но уж больно было любопытно, никакой корысти я из этого не извлёк, даже ни одной статьи не написал на эту тему), щупал, пробовал, даже пытался работать. И могу заявить со всей ответственностью — ни о каком реальном портировании там и разговора не было: самые обычные Windows-программы, сопровождаемые средствами запуска под Linux в режиме эмуляции.

Быстродействие этих «как бы портированных» программ оставляло желать лучшего (поскольку пожелать худшего было просто невозможно), устойчивость находилась на уровне ниже плинтуса, и вообще, ничего, кроме дополнительных проблем, они пользователю не обещали. Так что конец псевдо-Linux-программ от Corel был неизбежен и закономерен — интересно было только, как долго удастся пудрить мозги народу. Оказалось — довольно долго и даже сообщение о прекращении фирмой выпуска, а затем и поддержки своих «Linux-версий» (кстати, последовавшее вскоре после отказа от продолжения разработки дистрибутива Corel Linux), вызвало вздохи сожаления, эхом прокатившиеся по форумам и страницам «бумажных» изданий. Хотя, повторяю, жалеть было абсолютно не о чем.

Это я веду к тому, что наибольшее распространение явление псевдопортирования получило как раз среди средств редактирования и просмотра изображений. Среди них следует помянуть программы Compupic и Xnview. Обе они представляли собой менеджеры графических файлов, совмещенные со средствами просмотра изображений — как единичных, так и слайд-шоу, и с инструментами для их несложного редактирования. Не смотря на ряд достоинств, особенно явных у Compupic, им были свойственны наследственные болезни всех псевдопортированных приложений — медлительность и неустойчивость, особенно при работе с файлами большого размера.

Эти недостатки особенно выпукло смотрелись на фоне первых нативных Linux-программ просмотра изображений, таких, как только что зародившийся тогда GQview. Правда, это был чистый вьювер графических файлов, но зато с этой ролью он уже тогда справлялся на ура. А для редактирования изображений позволял подключить и вызвать любой растровый редактор (по умолчанию — GIMP, Electric Eyes, XV и XPaint).

Зато в отношении векторной графики дела в Linux обстояли кое-как, если не сказать, что никак. Достаточно отметить, что лучшей (или наименее худшей) векторной рисовалкой для наших платформ в те годы был рисовальный модуль из пакета StarOffice — StarDraw.

Впрочем, что бы ни говорили адепты inkscape, с векторной графикой в мире свободного софта и по сей день дела обстоят не блестяще. Лично я в этом плане больше всего надежд возлагаю на Xara: вырвавшись из цепких лап фирмы Corel, этот векторный редактор приобрел свободную ипостась под названием Xara Xtreme for Linux. И это уже серьезный, всамделишний инструмент, функционально аналогичный своей версии под Windows. Кому довелось оную видеть, наверняка оценили его мощь и удобство.

Завершая тему графики, я хотел бы остановиться еще на одном явлении, приуроченном к тому же периоду «бури и натиска» — а именно на формате DjVu и Linux-инструментарии для работы с ним.

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

На самом деле формат DjVu в масштабах времени IT-индустрии если и не superstar, то уж просто стар — безусловно. Он был придуман фирмой AT&T более десяти лет назад. Сам формат как был исходно открытым, так и остается таковым по сей день, что сыграло благотворную роль в его судьбе.

По замыслу формат DjVu предназначался для сканированных изображений, совмещающих полноцветную графику и текст, от которого требовалась читабельность. За первые годы своего существования формат этот весьма развился и к рубежу тысячелетий стал вполне пригоден для представления в Сети. Хотя широкого распространения там не получил, на мой взгляд — незаслуженно.

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

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

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

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

И Вi думаете, как говорят в Одессе, многие из посетителей наших сайтов воспользовались этими рекомендациями? Хрен в ухо, они предпочитали жаловаться, что ни фига не видят картинок. Правда, бальзам на мою душу пролил один австралиец, который сказал, что он всю графику видит прекрасно. Я так острожненько попробовал у него выпытать, скачивал ли он plug-in, да как его устанавливал. На что получил ответ в стиле: я мол не знаю никакой плугин-мульгин, у меня Makintosh, и он сам всё делает…

Кроме собственно формата, фирма AT&T разработала и инструментарий для работы с ним, включающий комплект разработчика (DjVu SDK) и plug-in’ы для отображения файлов этого формата в браузерах.

DjVu SDK был разработан для следующих платформ: Windows 9x/NT, Irix SGI, Sun Solaris, HP PA, Linux i386. Кроме того, для Windows 9x/NT имелись инструменты от сторонних разработчиков — например, фирмы Feith, никакого отношения к DjVu более не имеющей). Разумеется, версии для разных платформ имели свои особенности. Так, Windows-инструментарий функционировал, естественно, в графическом режиме, Linux-утилиты — в режиме командной строки. Относительно коммерческих UNIX’ов информации не имею.

DjVu SDK для Linux был доступен для свободного скачивания (хотя и без исходников, только в бинарном виде), на счет инструментария для Windows просто не помню; кажется никаких денег не надо было платить и за него.

Plug-in’ы для воспроизведения DjVu-документов были расчитаны на браузеры Netscape Navigator 3-й и 4-й версий, а также Internet Explorer 4-й и 5-й версий. DjVu Plug-in для Netscape был доступен (на том же сайте AT&T) для всех тех же платформ, что и инструментарий. Для IE, я думаю, платформу указывать не обязательно.

Вскоре после этого, как уже говорилось, AT&T продала компании LizardTech то, что являлось её собственностью — DjVu SDK и DjVu Plug-in. LizardTech некоторое время поддерживала версии для Linux и того, и другого набора пакетов, но это продолжалось совсем недолго. Сначала из открытого доступа исчез DjVu SDK for Linux, а потом и DjVu Plug-in для этой платформы. Остались только сугубо коммерческие инструменты для Windows в сопровождении плагинов для этой операционки. И казалось, что жизнь формата DjVu в мире Linux окончена.

Но свято место пусто не бывает. И еще некоторое время спустя сообществом Open Source был разработан набор библиотек и утилит для работы с форматом DjVu — мы ведь помним, что сам по себе он оставался открытым. И благодаря этому формат возродился в новой инкарнации, и началась его вторая жизнь. Но это уже совсем другая история…

Буря стихает, натиск слабеет

Всё, о чем сказано выше, я регулярно описывал в статьях, которые публиковались в журнале Byte Россия, в разделе Byte/Unix. Первая моя публикация в нем (ноябрь 1999 года) была посвящена html-редактору WebMaker. В дальнейшем были статьи и об отдельных дистрибутивах, и об интегрированных средах и оконных менеджерах, и о прикладных программах разного рода, были и сравнительные обзоры дистрибутивов, интегрированных сред и оконных менеджеров, приложений различных категорий. И к концу 2000 года публикаций накопилось столько, что я решил: пора делать новую книжку.

Собрать её из статей было недолго, тем более, что и эта книжка получилась не очень большой — чуть больше 400 страниц в итоговом варианте. Оставалось только найти издательство — с издательством Питер я больше иметь дела не хотел. Тем более, что они только что продали Byte Россия издательскому дому СКПресс, что повлекло за собой полную реорганизацию журнала, смену редколлегии, в конечном счете ликвидацию раздела Byte/UNIX и утрату интереса к журналу со стороны линуксомисателей и линуксочитателей.

В отношении издательства дело решил случай. Алексей Костарев, с которым мы переписывались со времен дискуссии о Linux’е и религиозных войнах, написал, что издательство BHV (в последующем — БХВ-Петербург, как я и буду называть его впредь, дабы не путать с одноименными киевским и немецким) предложило ему написать книгу о web-технологиях, и спрашивало, не знает ли он еще авторов, пишущих на темы свободного софта и родственные.

Отступление. А Алексей Костарев написал замечательную книгу, вышедшую под названием PHP в Web-дизайне в 2001 году и переизданную в 2002. Ныне в продаже можно найти написанную на ее основе книгу: Дмитрий Котеров, Алексей Костарев. PHP 5 в подлиннике. БХВ-Петербург, 2006, 1120 стр. В отличие от первой, я её не читал, но если она сохранила хоть что-то от своего прототипа — настоятельно рекомендую всем, интересующимся предметом.

В результате этой переписки я связался с представителем издательства — им был Евгений Рыбаков, ныне зам. главного редактора, — опять же был заключен соответствующий договор и началась редподготовка. Каковая на этот раз проходила в обстановке полного консенсуса и согласия. И в результате на рубеже 2000 и 2001 годов из печати вышла книжка под названием: Офис, графика, Web в Linux. Поскольку она существенно устарела (а не утратившие исторического или литературного интереса фрагменты выложены на POSIX.ru), полного её библиографического описания приводить не буду.

Замечу только, что книжка была и остаётся единственной в своем роде: в ней ни слова не говорится о программировании, администрировании, устройстве системы и прочих высоких материях. Позже мне подумалось, что и назвать её можно было проще — Linux для пользователя (под таким названием вскоре, через год после моей, выйдет книга Виктора Костромина). Авторское же название книжки было: Сага о Линуксе-Оконоборце, и на обложку я предполагал поместить резные картинки из норвежских церквей, на которых Сигурд поражает дракона Фафнира…

Выход этой книжки знаменовал собой очередную веху на моей дороге к Zenwalk’у. Одновременно завершив период бури и натиска. Последующие поиски идеала будут предметом следующей части моих мемуаров…