Развитие Linux: куда теперь?

Снарки, в общем, безвредны. Но есть среди них.
(Тут оратор немного смутился.)
Есть и БУДЖУМЫ...' Булочник тихо поник
И без чувств на траву повалился.
Л. Кэррол, "Охота на снарка"

Предисловие

Операционная система GNU/Linux (далее я буду буду для краткости назвать её просто Linux, хотя формально это не верно) в последнее время стремительно развивается. Растёт пользовательская база, ширится круг доступных приложений, увеличивается рыночная доля и появляются новые компании-поставщики решений Linux. Машина катится вперёд, причём делает это так стремительно, что непросто заметить, что именно находится впереди. А находиться там может многое.

Направлений в сущности два: направление MacOS X, представляющее собой некое централизованное законченное рабочее окружение с чёткой направленностью на предельную визуализацию и наглядность пользовательских действий, и направление классической UNIX, ориентированное на маленькие "острые" выразительные утилиты, позволяющие легко комбинировать друг друга для быстрого достижения сложных результатов.

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

Но я считаю, что этот путь - это путь в никуда. Пытаясь идти вслед за Windows и MacOS X Linux обречена оставаться второй. Просто потому, что есть Apple и есть Microsoft, которые уже идут впереди, и первенство которых обеспечено тем объёмом ресурсов, которые тратятся на исследования в релевантных этому пути развития областях. И Linux, если пойдёт по их стопам, на их фоне всегда будет выглядеть дешёвой подделкой.

Напротив, наследие UNIX предлагает совсем другой подход к работе. Причём этот подхот отличается не тем, что кучка фанатов привыкла к нему и жить без него не может (вспоминаем MS DOS и Lexicon), а принципиально другой организацией работы, которая позволяет достичь тех же результатов, что и работа с мощнейшими приложениями Windows и MacOS X, при применении другого стиля работы.

Будучи последовательным приверженцем стиля работы в классических UNIX-подобных системах, в этом эссе я коснусь именно его особенностей и приложений Linux, которые ему соответствуют или не соответствуют.

Базовая концепция UNIX

Итак, что объединяет методологию работы в UNIX-подобных ОС?

Далее по тексту каждый из этих пунктов будет раскрыт в соответствующем "case study"

Единое файловое пространство

В UNIX есть один корень файловой системы, к которому всё монтируется. Любой файл файловой системы имеет выразительное название и выразительный путь, так что имея сведения о содержимом файла, можно с очень высокой точностью определить его название и местонахождение. Файлами является всё; если что-то не является файлом, его нет в UNIX.

Такой подход в целом прослеживается во всех приложениях всех дистрибутивов UNIX. Но не все йогурты одинаково полезны! В качестве примера вредного йогурта возьмём монтирование CD в дистрибутиве SuSE.

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

Вот вставил я диск с фильмом "Апокалипсис сегодня" в дисковод, и появился у меня в дереве каталогов такой путь: "/mnt/APOCALYPSE_NOW". И каков итог? Нарушена концепция файловой системы UNIX: название каталога не соответствует его назначению, да ещё и постоянно меняется, так что несложный скриптик для работы с содержимым диска, который отлично работал бы в любом менее экстравагантном дистрибутиве без изменений веками, должен редактироваться каждый раз или неоправданно усложняться.

Вывод: попытка сделать пользователю Windows "как привычней" обратилась в истязание ортодоксальных UNIX'истов и вообще poweruser'ов.

Маленькие "острые" утилиты

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

И тут стоит сравнить GStreamer с одной стороны, и xine-lib с другой. Что представляет собой эти программы? Это типичные конвертеры: на входе принимается некий файл, который переводится на выходе в формат RAW audio и отправляется в звуковую подсистему. Но КАК они это делают! xine-lib - это монолит, который будет заниматься сразу всем: и звук, и видео, причём во всех форматах и сразу. Напротив, GStreamer полностью разделён: есть библиотека GStreamer, которая вообще не обрабатывает какие бы то ни было аудио- или видеоданные, и есть куча gst-plugin-*, каждый из которых занимается только своим делом, каждый из которых развивается независимо от остальных и не зависит от проблем остальных. Фактически GStreamer представляет собой стандартный интерфейс к кодекам.

Вывод: Xine-lib является очень неплохим программным продуктом, но GStreamer является более правильным ПО, и потому достоин большего.

Взаимодействие программ

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

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

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

Вообще, свои мелочные счёты с окружающим миром сводят почти все. Так, для меня всегда было загадкой, зачем авторы браузеров так старательно задают внешний вид своих детищ? Пользователь всегда лучше знает, какие сочетания цветов, шрифты и пиктограммы ему нравятся больше, так зачем над ним издеваться, заставляя искать и скачивать подходящую к оформлению его оконного интерфейса тему (которая ещё может и не подойти в связи с несовместимостью между разными версиями программ). Красивыми решениями в этом смысле можно назвать Konqueror (в случае KDE) и Dillo (в случае GTK+), которые не навязывают пользователю собственное понимание красоты, а просто используют стандартные элементы управления и стили.

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

Вывод: повторное использование кода является неотъемлемой частью эффективной модели программирования.

Стандарты и форматы

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

Примером соблюдения правила может служить то, что классические текстовые редакторы и утилиты для работы с текстом используют один и тот же формат - "plain text" - текст, читаемый в любом редакторе.

Это правило стало нарушаться в связи с массовым заготовлением Linux для офисной работы. Де факто стандартом документа является бинарный формат DOC, используемый в Microsoft Word, в котором содержатся файлы пользователей. Не намного лучше и родные форматы KOffice и AbiWord.

Но есть претензии и к родным форматам OpenOffice.org... Как известно, файлы SXW и ODT представляют собой набор сжатых XML файлов. Здесь меня более всего беспокоит слово "сжатых". Понятно, зачем это делалось: экономия места и объединение файлов, из которых состоит документ, в один файл. Однако в результате мы получаем формат, который не может быть прочитан на произвольном компьютере: у пользователя должна быть утилита unzip, которая далеко не всегда входит в дистрибутивы Linux, да и сквозь тэги, используемые в OpenOffice, продираться не слишком просто.

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

Функциональность в ущерб простоте в использовании

Если уж утилита из UNIX взялась выполнять определённую работу, то она будет выполнять её настолько близко к пожеланиям пользователя, насколько это возможно. То есть UNIX-программа скорее предоставит 2000 опций командной строки, чем сделает невозможным какой-либо приём. При этом делается упор на вменяемость пользователя, который должен быть способен выбрать из возможностей программы нужные именно ему и использовать их.

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

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

Вывод: функциональность не должна ограничиваться пригодностью для начинающего пользователя.

Изящество в решении задачи

За всё время существование человечества были выработаны две методики выполнения задачи, которые можно было бы условно назвать "изящное решение" (т.е. решение, которое является структурно согласованным, концептуально проработанным и академически правильным) и "решение, которое работает" (т.е. минимально достаточное для выполнение задачи). Так вот, мир UNIX всеми силами отбивается от второго подхода.

Здесь "героем дня без галстука" выступает конгломерат утилит от Mozilla Foundation. Так был раньше набор программ Mozilla Suite, который, несмотря на полную неспособность работать так, как это должна делать программа в UNIX, представлял собой неплохой пакет, состоявший из движка обработки HTML, браузера, почтовой программы, web-редактора WYSIWYG-типа, IRC-клиента и календаря. Этот монстр представлял себе ком в горле любой UNIX-подобной системы, поскольку нарушал все правила: случайным образом генерирующиеся имена постоянных файлов, чёткая неспособность взаимодействовать с внешним миром иначе чем по-разному откликаться на специфические ключи вызова, собственный формат почтового ящика, неполная поддержка CSS при наличии собственных CSS-свойств и достаточно ограниченная функциональность делали это приложением камнем на шее сообщества UNIX'истов. Однако этот пакет имел очень красивую внутреннюю структуру: не было двух частей, отвечающих за одно действие, наличествовала модульность, выражавшаяся во взаимоотношениях частей программы между собой и с плагинами. Но коварный удар в спину испортил идиллическую картину.

Теперь Mozilla Foundation продвигает три собственных продукта (давайте сделаем вид, что NVu не имеет ни малейшего отношения к продуктам Mozilla Foundation): браузер Firefox, почтовый клиент Thunderbird и календарь Sunbird. Прелесть ситуации заключается в том, что разделённый набор (а рассматривать как набор это всё всё равно стоит, ибо поклонники Mozilla Suite предпочитают осколки пакета иным приложениям; добавляя корректности в сравнение, Mozilla Suite очень активно отмежёвывалась от образа монолита: каждое из приложений можно было не устанавливать, так что функционально Mozilla Suite с лёгкостью ограничивалась до своих последователей) не просто не стал лучше, а только ухудшился. Браузер Mozilla Firefox потерял половину функций Mozilla Navigator, а совокупный размер трёх частей программы стал превосходить суммарный размер исходного пакета. Но не зря я описываю это всё в секции, посвящённой посвящённой изящности решения: новый пакет перешёл из категории отлично структурированного и качественного ПО в качественное ПО с колоссальной брешью на уровне проектирования. Как иначе можно охарактеризовать тот факт, что одновременно установленные Mozilla Firefox, Mozilla Thunderbird и Mozilla Sunbird используют три различных версии Gecko (кстати говоря, не пересекающиеся функционально) и три различных интерпретатора языка плагинов?

Кроме того

Java

Вот есть теперь у нас такое социополитическое явление. Есть даже несколько виртуальных машин Java на выбор. А давайте на минутку задумаемся о том, какое место занимает Java в Linux?

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

Был такой старый анекдот: "Любое дело можно сделать тремя способами: правильно, неправильно и так, как это делают в армии". Последнее и получилось в случае Java: цель оказалась вообще не достигнута, но средства вложены. В результате мы имеем кучу программистов, которые пишут на Java. И часть из них сидят у нас, в мире UNIX. Чем это плохо? Ничем. Но зачем оно нужно??? В большинстве своём программы на Java в использовании неотличимы от своих полноценных собратьев. Насколько мне известно, ощутимая часть GNOME написана именно на Java на такой манер. Такие программы собираются с помощью jikes или gcc в обычные бинарники, и вред от них только в захламлении системы библиотеками Java. Между тем, языков программирования на все вкусы в UNIX хватало и без Java, причём изначально местные языки уж точно в гораздо большей степени ориентированы на работу в UNIX. Кроме того, они сами выдержанны в этой традиции, имеют характерные элементы в синтаксисе и т.п. Наконец, программисты, привыкшие писать на Java под Windows, используют вместо родных для Linux UI собственные варианты UI Java, что нарушает единообразие пользовательского опыта в системе. Словом, есть Java - хорошо, нет Java - ещё лучше.

Два слова о WYSIWYG

Традиционная парадигма редактирования текста под UNIX предполагает использование языков разметки. Так, само редактирование осуществляется посредством написания текста и нанесения на него разметки, соответствующей желаемой структуре и желаемому оформлению, после чего результат достигается компиляцией полученного файла. Однако пользователям Windows с детства близка и знакома обратная парадигма - WYSIWYG. Этот стиль редактирования текста предполагает редактирование текста, который компилируется в процессе ввода; действия разметки же осуществляются посредством объектной работы с текстом: пользователь выделяет фрагмент текста и меняет его атрибут.

Принцип WYSIWYG не прижился в классических UNIX'ах потому, что снижал роль пользователя в оформлении текста: сама программа определяла, каков режим атрибутов вводимого текста, как обрабатывать текст с множественными изменениями атрибутов в небольшом фрагменте (попробуйте угадать, как трактует Microsoft Word последовательное одинаковое изменение одного и того же атрибута у двух соседних фрагментов текста!) и т.п. Между тем, новые пользователи Linux, перешедшие из Windows, привыкли иметь дело именно с WYSIWYG-редакторами, и теперь испытывают в них потребность.

Для оценки этой ситуации следует постараться понять, почему именно так сложилось, что в мире Windows оказался популярен подход WYSIWYG, а в UNIX - текст с разметкой. В UNIX такой выбор был продиктован исключительно озвученной выше концепцией: именно текст с разметкой позволял использовать один-единственный любимый текстовый редактор для любого вида текстов, при этом максимально контролируя результат и используя максимум возможностей среды - ведь работа с "гладкими файлами" в UNIX'ах оказалась особенно эффективна в силу особенностей механизмов взаимодействия программ. В Windows таких строгих конвенций не было.

Но UNIX проросла на домашние компьютеры с высокопроизводительных компьютеров, пользователями которых были технические специалистами, имевшие потребность в расчётах, а значит, обладавшие техническим складом ума; Windows же проросла из DOS, обитавшей на IBM PC, т.е. на компьютерах для широкого круга нетехнически мыслящих пользователей. Этим людям всегда хотелось оказаться минимально вовлечёнными в работу на компьютере, а потому программное обеспечения для них было расчитано на минимальную мнемоническую нагрузку, достигавшуюся за счёт меньшего функционала и большей наглядности.

При этом, если в UNIX'ах подход к работе "решение, которое работает" карался, то в Windows он, наоборот культивировался, поскольку обратное поведение выдавливало пользователя из-за компьютера, чем достигался предельно негативный для всех эффект. И поэтому в среде пользователей Windows до сих пор (и вопреки всем попыткам насаждения цивилизации) считается нормальной практикой форматирование текста посредством повторяющихся пробелов и/или разрывов строки. Кроме того пользователями WYSIWYG редакторов практикуются многократные изменения небольшого количества атрибутов на ограниченном участке текста с целью побочным эффектом таких действий достичь нужного форматирования; эта практика приводит к тому, что однажды сохранённый текст открывается не в том виде, в котором был закрыт, поскольку некоторые действия, проделанные в предыдущий сеанс работы с этим текстом, при новом открытии не были повторены, и их побочный эффект не оказал влияние на форматирование документа.

Казалось бы, всё перечисленное выше является исключительно проблемой соответствующих редакторов, но это не так. Пользователь, завлечённый в лоно WYSIWYG-редактора, ошибочно воспринимает его наглядность как простоту, не замечая времени, потраченного на приведение документа в нужный вид и отладки результата. Такой пользователь будет считать, что WYSIWYG-редактор точнее отвечает его требованиям, чем редактор, обеспечивающий комфортное редактирование текста с разметкой, и в результате пользователь сделает неверный выбор. А статистическое множество таких пользователей (а приток пользовательской массы происходит именно за счёт них) оказывает влияние на концепцию ПО в целом, так что система постепенно теряет свои свойства, и приложения типа Mozilla Firefox и OpenOffice.org воспринимаются не как катастрофические монстры, а как правильные, удобные и перспективные программы.

KDE

Редкая тема может похвастаться такой популярностью, как обсуждение K Desktop Environment. Внесу свою лепту и я.

Почему-то бытует мнение, что KDE - это куча монолитного кода с претензиями на звание Windows II. Это не так. Более того, это строго противоположно действительности.

Давайте посмотрим, что такое KDE. Фактически это рабочее окружение представляет собой набор базовых библиотек (kdelibs), система организации взаимодействия процессов (DCOP), несколько back-end'ов (aRTS, KHTML, KATE и т.д.) и куча front-end'ов (то, что мы видим в меню). При этом мы видим, что с помощью DCOP front-end'ы легко связываются с back-end'ами, сокращая количество кода и затраченного времени. Т.е. мы видим классическую схему организации тесно интегрированной среды с открытым входом - DCOP легко подхватит любое приложение, которое способно его запросить. При этом гармонично соблюдаются все принципы UNIX:

Также хотелось бы отметить, что даже такие анти'UNIX'истские задачи, как WYSIWYG-редактирование, выполняются в приложения KOffice предельно изящно, обеспечивая всё то же единообразие пользовательского опыта, экономию кода и систематичность. Т.е. едва ли какое-либо графическое окружение может похвастаться близостью к концепции UNIX, достигнутой KDE.

Послесловие

Повлиять на развитие Linux невозможно - она разрабатывается тысячами ничем не связанных программистов, каждый из которых делает то, что считает нужным. Она формируется миллионами пользователей, каждый из которых устанавливает то, что считает нужным. Общий вектор оказывается суммой индивидуальных векторов.

Но влиять нужно. Я надеюсь, что прочитав это эссе, все пользователи Linux задумаются над тем, какой они хотят видеть свою систему. Очень рекомендую почитать произведения Эрика Реймонда (Eric S. Raymond), который очень подробно описывает идеологию UNIX. Кроме того, пользователям стоит решить, является ли Linux нужной им системой? Уже на подходе Haiku - наследник BeOS и открытый конкурент MacOS X. Активно разрабатывается ReactOS - открытая NT-совместимая система. Может быть, именно они являются тем, что Вам нужно?

Операционные системы -> Linux -> Развитие Linux: куда теперь?