У LSB больше не осталось каких-либо оснований отказываться от того, чтобы добиваться лучшего

Главное, в чем мне хотелось бы убедить других, — это в необходимости поддержки LSB. Но призывая к поддержке, я имею в виду не только непосредственный вклад в проект, хотя это очень важно. Кроме того, я призываю сообщество Linux убедить родительскую организацию LSB — группу Free Standards Group пригласить серьезного лидера, способного обеспечить развитие LSB, а также привлечь нынешних руководителей прекратить коллективную перепалку, создать развернутую спецификацию и подготовить эталонную реализацию, достоинства которой говорили бы сами за себя. Под развернутой спецификацией я понимаю документ, который окажется достаточно полным, чтобы можно было создавать сложные графические приложения. Я со всей определенностью могу утверждать, что таковым не является тот убогий минимальный стандарт, который предлагается для рассмотрения в качестве спецификации LSB 1.0.

По прошествии почти трех лет работы самое значительное достижение LSB — это бета-спецификация, получившая название Linux Development Platform Specification (LDPS). По существу, LDPS — это 1800 пустых слов, описывающих неадекватный набор строительных блоков для приложений Linux. Сама по себе спецификация настолько упрощена, что я смог повторить практически весь список ее требований, пункт за пунктом, менее чем за две минуты.

Еще больше смущает тот факт, что LDPS не предлагает точной информации о том, каким образом ее создатели намерены достичь поставленной цели. Например, в спецификации перечисляются несколько вариантов Linux, которые соответствуют LDPS. Но на деле эти варианты не полностью удовлетворяют даже тому весьма скромному списку требований, который содержится в LDPS. К примеру, ни один из указанных вариантов, с которыми мне приходилось работать, не удовлетворяет стандарту Filesystem Hierarchy Standard 2.1. А в тех случаях, когда варианты соответствуют спецификации, оказываются не до конца решенными проблемы интероперабельности. Например, в LDPS указано бессмысленное требование того, чтобы ОС включала в себя или ncurses версии 4, или ncurses версии 5. Но пакеты, содержащие версию 4, не будут совместимы с программами, скомпилированными для версии 5, и наоборот.

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

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

Пассивность LSB может устраивать тех производителей и членов сообщества Linux, которые всегда крайне негативно реагируют на разговоры о том, какие стандарты они должны использовать. Но Linux заслуживает лучшего. И у LSB больше не осталось каких-либо законных оснований отказываться от того, чтобы добиваться лучшего. До недавнего времени LSB объясняла свою бездеятельность отсутствием достаточного количества ресурсов для дальнейшего продвижения Linux, утверждая, что средств хватает только на то, чтобы оформить документально уже существующие решения. Однако лаборатория Open Source Development Labs, в которую крупные производители готовы вкладывать миллионы долларов, решит эту проблему, не оставив LSB никаких путей к отступлению.

Так что теперь, LSB, берегись. Остается — либо найти достойного руководителя, либо уйти с дороги.