Часть III. Другие стандарты и многообразие дистрибутивов.
Продолжаю тему внедрения СПО в ОГВ, начатую здесь...
Всевозможные стандарты и открытые спецификации насквозь пронизывают существующее СПО, помогают пользователям СПО в решении повседневных задач. Прежде всего я имею ввиду LSB, FHS, ODF, рекомендации freedesktop.org, различные RFC, форматы HTML, XML, и др. спецификации консорциума W3C, ... Но также не стоит забывать о документации и внутренних соглашениях в крупных проектах, строгое следование которым позволяет им оставаться на плаву и даже лидировать в отрасли. Именно всё перечисленное объединяет существующие дистрибутивы наряду со свободными лицензиями. Но есть и нечто третье, что также значительно влияет на интероперабельность и совместимость GNU/Linux дистрибутивов. Как ни странно, это сам свободный код! Недостаточно написать программу под свободной лицензией. Настоящая СВОБОДА будет достигнута только после того, как исходник такой программы станет доступен широкой общественности, при этом, сама программа не будет жёстко (или искусственно) привязана только к какому-то одному единственному дистрибутиву (или даже платформе).
Именно так, как перечислено выше, «живёт и здравствует» истинное СПО. Именно такое СПО и следует внедрять в ОГВ. Можно привести массу «положительных» примеров по-настоящему СВОБОДНЫХ программ «повседневного использования»: почтовый клиент, текстовый редактор, интернет обозреватель, растровый графический редактор, медиаплеер - всё это мало чем отличается в различных дистрибутивах GNU/Linux, когда речь заходит об одной и той же СВОБОДНОЙ программе, например, Firefox. Поскольку в виде исходных текстов в природе не существует «Firefox для Debian», «Firefox для OpenSUSE», «Firefox для FedoraCore», итд (извините, если кого «забыл»), есть только один главный репозиторий исходников Mozilla Firefox. Тоже самое касается главного репозитория ядра ОС - проект «Linux» на kernel.org, да и всех остальных по-настоящему СВОБОДНЫХ программ и библиотек.
За «отрицательными» примерами также далеко ходить не надо. Массу проблем пользователям доставляет ПО с лицензионными или патентными ограничениями, когда речь заходит об интероперабельности в свободной среде. Закрытые драйверы, прошивки (фирмварь), закрытое ПО типа Adobe Flash Player, последние версии закрытого браузера Opera, имеющего проблемы сборки в ALT Linux'е, т.н. Плеер ЭОР НП, адаптированный только для одного из дистрибутивов ПСПО, даже «освобождённому» исходному коду распознавалки текстов CuneiForm ещё очень далеко до того, чтобы занять своё место в списке «историй успеха», поскольку одна лишь только свободная лицензия всех проблем переносимости не решает, всех свобод не обеспечивает.
Поэтому, дорогие чиновники, выбирая между двумя архиваторами 7zip и RAR, не забывайте, что только 7zip пронизывает все дистрибутивы GNU/Linux сверху до низу, а файлы, созданные этим архиватором, действительно не вызывают неудобств на каких-бы то ни было платформах. Даже под MAC есть ни один lzma-совместимый архиватор! В отличие от RAR-архивов, где в основной массе дистрибутивов внутри архива есть проблемы и с кодировками имён файлов, и наличием (или отсутствием) проприетарной библиотеки, от которой зависит львиная доля наиболее значимого функционала RARv3. Впрочем, в мае 2011 появился «The Unarchiver», частично решив проблему с проприетарностью старого unrar (для RARv3), но в основные репозитории он ещё не попал, так что пока юзаем ppa:nilarimogard/webupd8. :)
А как же дистрозависимый свободный код и дистрозависимые патчи (исправления)? Чтобы определиться, давайте и это «разберём по полочкам». Многие инсталляторы, пакетные менеджеры, системы инициализации/загрузки, издревле считавшиеся дистрозависимыми, давно перестали быть таковыми. Этот по-настоящему СВОБОДНЫЙ код зачастую уже не ограничивается рамками какого-то одного дистрибутива или даже какой-то одной платформы. Apt, Adept, Synaptic, Alien, dpkg, Debian-installer, Anaconda, rpm (имеется ввиду консольная утилита и набор связанных библиотек), System-V Init, Upstart, RunIt, InitNG, OpenRC, Launchd, … - вот лишь некоторые примеры.
Но, даже в том случае, когда область применения дистрозависимого инструмента системного администратора пока ограничена одним единственным дистрибутивом, я бы считал и этот код полностью СВОБОДНЫМ по двум причинам: во-первых, многообразие дистрибутивов обеспечивает всем нам пресловутую информационную независимость, здоровую конкуренцию схожих проектов между собой, право выбора, наконец («больше дистрибутивов хороших и разных» - помните, да?), во-вторых, потенциальное использование в будущем этого свободного кода в других дистрибутивах тоже пока никто не отменял.
Дистрозависимые патчи бывают очень разными. Если хороший и нужный патч, ставший сначала достоянием какого-то одного дистрибутива, не попал в апстрим, налицо явно чья-то недоработка. Постоянное присутствие таких патчей не характерно, скорее наоборот - они носят временный (краткосрочный) характер. Попав в апстрим, такие патчи перестают быть дистрозависимыми. Безусловно, основная масса дистрозависимых патчей не затрагивает основной код программы, а касается лишь системы сборки программы в сборочном окружении конкретного дистрибутива.
Другими словами именно система сборки программы адаптируется для разных окружений (дистрибутивов), т.е. создаётся по-настоящему переносимый СВОБОДНЫЙ код (кросс-платформенная разработка). Собственно, до уровня configure/make/install эти патчи даже не стоит называть дистрозависимыми, поскольку им опять же заказана прямая дорога в апстрим. Кстати, вот хороший пример адаптации сборки старого OpenOffice.org 2.x c патчами от ИнфраРесурс под Gentoo Linux. Читать от ссылки до конца страницы, хотя основное, что хотел тогда сказать, я сказал на первой странице этого топика. С нынешней колокольни мне эти патчи от Инфры видятся хоть и полезными, но их стабильное отсутствие в апстриме как раз намекает на неправильность и весьма далёко от «истории успеха».
Не стоит путать «заплатки», стабилизирующие работу или исправляющие критические уязвимости, добавленные в текущий сорцовый релиз дистрибутива из нестабильного дерева апстрима некоего проекта (к примеру libc), с дистрозависимыми патчами только потому, что они уже попали в один дистрибутив и ещё не успели попасть в другой. Просто разработчикам первого дистрибутива уже доподлинно известно, что этот код появится в будущих стабильных выпусках апстрима проекта (например, libc), «синхронизация» таких патчей между дистрибутивами будет выполнена позднее опять же на уровне апстрима.
Другими словами, любой патч обязан попасть в апстрим! Если он к этому не стремится, значит с этим патчем не всё в порядке!!! Приведу такой пример, когда один камрад, услышав мольбы о помощи всего Башкирского народа, реализовал решение с национальной раскладкой клавиатуры, связался с мейнтейнером пакета xkb и это решение стало достоянием сразу всех будущих выпусков любых дистрибутивов GNU/Linux!!! См. файл типа /usr/share/X11/xkb/symbols/ru в своём дистрибутиве - есть ли там нечто похожее на:
partial alphanumeric_keys
xkb_symbols "bak" {
include "ru(winkeys)"
name[Group1]= "Russia - Bashkirian";
key.type[group1]="FOUR_LEVEL";
key { [ 0x010004d9, 0x010004d8, Cyrillic_io, Cyrillic_IO ] };
key { [ exclam, quotedbl, 1, 1 ] };
key { [ 0x010004e9, 0x010004e8, 2, 2 ] };
key { [ 0x010004a1, 0x010004a0, 3, 3 ] };
key { [ 0x01000493, 0x01000492, 4, 4 ] };
key { [ 0x010004ab, 0x010004aa, 5, 5 ] };
key { [ colon, semicolon, 6, 6 ] };
key { [ 0x01000499, 0x01000498, 7, 7 ] };
key { [ 0x010004bb, 0x010004ba, 8, 8 ] };
key { [ question, parenleft, 9, 9 ] };
key { [ numerosign, parenright, 0, 0 ] };
key { [ minus, percent, minus, underscore ]};
key { [ 0x010004af, 0x010004ae, equal, plus ]};
key { [ 0x010004a3, 0x010004a2, backslash, slash ]};
include "level3(ralt_switch)"
};
Представьте на секунду, какой «свободный код» можно напридумывать «за железным занавесом», кому он на хрен будет нужен! По-настоящему СВОБОДНЫМ он не будет никогда, если его разработка ограничится пределами одного единственного дистрибутива (платформы), национального языка и фонда алгоритмов и программ! Важный и нужный код, не попавший в апстрим, требует непрерывной поддержки, постоянной адаптации под новые версии, а это не только неоправданные трудозатраты, но и финансовые потери для тех, кто «дэвушку танцует»!
Дистрозависимые патчи ядра Linux - вообще отдельная тема и уж тем более не для такой большой статьи. Но если вкратце, такие патчи ядра, которые систематически не попадают в апстрим kernel.org - это ЗЛО! Разработчикам ядра просто виднее «что такое хорошо, а что такое плохо». И если почти во всех дистрибутивах в стремлении сделать красивый бутсплэш дистростроитель незаметно для всех ломает какую-то функциональность, это чисто его трудности (и проблемы тех, кто выбрал этот дистрибутив). Но, по правде говоря, GNU/Linux дистрибутивов, предоставляющих «из коробки» по умолчанию чистое «ванильное» ядро, действительно не так много. А обусловлено это тем, что такой огромный и сложный пакет, как ядро Linux, также как и сами дистрибутивы, собирается с разными функциональными особенностями на усмотрение дистростроителя и, кроме того, напрямую с самим ядром никакой прикладной софт не взаимодействует, поэтому различия в «начинке» не отражается на работе большинства обычных «повседневных» программ.
Теперь, практически полностью раскрыв тему патчей, снова вернёмся к наиболее дистрозависимому коду. Из не рассмотренного остались программы поддержки инфраструктуры сборки и тестирования дистрибутивов - сборочные среды, сорцовые репозитории, инструментарий для совместной работы над проектом, отслеживания ошибок, итп. И здесь существует по меньшей мере три, а то и все четыре мнения. Рассмотрим перечисленное с разных точек зрения: простого конечного пользователя дистрибутива, системного администратора, выполняющего первый уровень поддержки, дистростроителя (разработчика дистрибутива), а также некоего гипотетического лица, ратующего за интересы нашей отчизны... :)
По всей видимости, конечным пользователям д.б. безразлично, как устроен сорцовый репозиторий, каким дополнительным инструментарием сборки пользуются разработчики дистрибутива, «жизненно важными» для них я бы назвал совершенно другие критерии. В некоторой степени очень продвинутому пользователю м.б. небезразличен инструмент поддержки, через который он сам может связываться со службой технической поддержки (разработчиками) дистрибутива, однако такие навыки характерны скорее для системных администраторов, да и то, не для всех.
Типичный системный администратор здесь ближе к обычному пользователю, поскольку вопросы массового развёртывания и индивидуальной инсталляции/техподдержки никак не пересекаются с инструментарием разработчиков дистрибутивов. И только наиболее продвинутым системным администраторам, равно как и самим разработчикам дистрибутива, важно всё, что касается сборочной среды, сорцового репозитория и программ, обеспечивающих поддержку дистрибутива и совместную работу. В данном случае они выступают как пользователи этих инструментов, сделавших свой осознанный выбор. А что, как и все мы, имеют на это полное право!
Надо сказать, не только «любимый» инструмент, но и другие факторы оказывают влияние на выбор дистрибутива. Например, для разработчика - это вся совокупность инструментов, а также политика и атмосфера взаимодействия в коллективе разработчиков, а для не коммьюнити-дистрибутивов - и другие условия оплачиваемого труда; для системного администратора - это прежде всего объём заведомо удовлетворительно решённых задач и собственное время, которое придётся затрачивать на инсталляцию, «допиливание» и техподдержку пользователей, возможность оперативного саппорта со стороны разработчика, а при отсутствии таковой - возможность самостоятельного внесения изменений; для простого конечного пользователя - это прежде всего скорость работы и функциональность дистрибутива, удобство интерфейса (ублажение привычек и ожиданий?), скорость и качество работы локальной или внешней техподдержки.
Но есть ещё одна «маленькая деталька», которая в той или иной степени важна для всех троих - для пользователя, администратора и разработчика. Только каждый из них смотрит на эту «детальку» с «собственной колокольни». При этом, на саму «детальку» ложится львиная доля тех различий, которые и создают бесконечное многообразие дистрибутивов! Итак, помимо дополнительного инструментария создания дистрибутива (не забываем, что есть ведь и стандартные средства разработки, присущие для всех POSIX-совместимых систем), определяющую роль в многообразии играют: аппаратная платформа, для которой создаётся дистрибутив, всё поддерживаемое оборудование, определяемое доступными модулями ядра, круг пользователей и решаемых ими задач, что является минимальной (базовой) системой, а что вынесено за её пределы, какие компоненты входят в сам дистрибутив, а какие можно до-установить из внешнего репозитория, каким образом выстроена схема зависимостей одних компонентов от других, какие компоненты определены (выбраны) «по умолчанию», а какие вторичны (это в значительной степени влияет на степень интеграции одних компонентов с другими, и время, затрачиваемое администратором на смену «умолчальных» компонентов), какие установлены требования по безопасности и многое, многое другое...
И вот теперь, пройдя краткий экскурс по ключевым моментам сходства и различия дистрибутивов GNU/Linux, попробуем взглянуть на получившийся «многослойный пирог» с позиции человека, ратующего за информационную независимость нашей вотчины. Особо подчеркну, эта позиция в своём исходном состоянии возможно не будет иметь ничего общего с позицией типичных сторонников распространения СПО, своего рода «религиозных фанатиков на почве любви Linux». Просто представим эдакого патриота, желающего и СПО поиметь, и деньжат сэкономить, и ИТ-индустрию в накладе не оставить. Ну, а что получится из нашего с ним диалога - смотрите сами!.. :)
Патриот: Выбор одного стандартного дистрибутива позволил бы вести разработку без излишнего разбрасывания. И главное, чтобы это был отечественный дистрибутив.
Аналитик: Во-первых, дистрибутив - это способ дистрибуции (распространения) СПО, которое не является чисто отечественным продуктом. В данном случае отечественной будет только сборка комплекта программ и библиотек в единое целевое решение. Имеется ввиду, что процессом сборки на российских серверах управляют отечественные специалисты. Доля чисто отечественных наработок в дистрибутиве относительно остального свободного кода не превышает и десятой доли процента! И это вы называете «отечественным дистрибутивом»!?
Во-вторых, не существует такого понятия: «стандартный дистрибутив». Все дистрибутивы можно условно считать стандартными, если в них соблюдаются соответствующие стандарты и спецификации. Дистрибутивы GNU/Linux используются очень широко - на рабочих станциях, на серверах, во встроенном оборудовании и даже на супер-компьютерах и мейнфреймах. Почему дистрибутив для десктопа или супер-компьютера д.б. один? Разве у них одинаковые задачи? Почему для диаметрально различающихся по мощности рабочих станций чиновников дистрибутив д.б. один? Ведь владельцев мощных компьютеров не устроят «легковесные» графические среды, а слабые компьютеры, наоборот - «не потянут» более продвинутые современные графические оболочки.
Наконец, почему д.б. один дистрибутив для школ, налоговых инспекций, Роспотребнадзора, судов, ФАС и ФСБ? Разве у них одинаковые критерии выбора? По-вашему логично, что ПО, призванное заменить Windows NT, под управлением которого работают наши стратегические установки пуска ракет S300, должно работать и на ПК школьников? Если так, то зачем снова что-то разрабатывать? Ведь государству уже сданы целых пять вариантов ПСПО - пусть используют и развивают своими силами! Что, не могут своими силами? Значит придётся платить за доработку каждого решения для каждой конкретной организации. А раз так, то какая разница, платить одному разработчику за 100 проектов или разделить то же число проектов на десяток разработчиков? Хотя делать ставку на единственного разработчика я бы не стал - слишком большой риск от «складывания яиц в одну корзину», слишком велика нагрузка и ответственность на единственного поставщика решения, отсутствие конкуренции (необоснованно создаваемая монополия), и опять же - большая проблема с обеспечением специалистов на местах: максимально задействовать весь имеющийся потенциал разработчиков и сисадминов не получится. Ведь взамен Microsoft мы получим только один небольшой коллектив, в лучшем случае - из 100-400 специалистов.
В-третьих, те ключевые особенности, которые отличают один дистрибутив от другого, на самом же деле показывают конечным пользователям, насколько гибок свободный софт, как его можно адаптировать для разных условий, платформ и задач, по-разному собрав, подобно тому, как из одного пластилина можно слепить множество разных красивых фигурок и не факт, что какая-то одна из них будет «стандартной», «лучшей», «самой красивой» и т.п.
В-четвёртых, разрабатывая и улучшая лишь один дистрибутив, мы можем делать что-то полезное для двух вещей: улучшать нечто, связанное только с этим дистрибутивом (инсталлятор, пакетную систему, дополнительное сборочное ПО, итд), и возможно тогда эти наработки действительно мало кому будут нужны во всём мире, только пользователям этого дистрибутива, но относительно всего СПО - это менее десятой процента всего свободного кода, а значит пользователи даже не заметят этих улучшений, но мы можем улучшать и сам свободный код, входящий в состав нашего единственного «стандартного дистрибутива», и тогда пользователи почувствуют толику нашего участия, но тогда это либо почувствуют пользователи других дистрибутивов (если мы отдаём наши наработки в мировой апстрим, но выходит, в таком случае «мы разбрасываемся»!), либо мы идём по пути изоляционизма, отгородившись «железным занавесом» от всего мирового апстрима, а это значит куда большие вложения, поскольку все наши наработки придётся постоянно прикручивать и вечно гнаться за мировым апстримом, за которым нам и не угнаться, да и наш код не будет никогда предметом гордости, он может быть и непереносим, и содержать существенные ошибки, он не будет по-настоящему СВОБОДНЫМ, невзирая на доступность и свободную лицензию! Например, если мы хотим локализовать интерфейс какой-то нужной программы, лучше сразу научиться у мирового апстрима, как делать это «правильно»: наши наработки должны попасть в мировой апстрим, а не только в фонд алгоритмов и программ, тогда дальше нас уже не будет сильно заботить, насколько далеко ушёл вперёд апстрим некоего нужного пакета, и нам, и апстриму будет проще вести адаптацию перевода интерфейса последующих версий по уже имеющимся готовым наработкам.
В-пятых, выбранный дистрибутив - это лишь платформа. Затраты на поддержку платформы ничтожны в сравнении с затратами на ПО, которое под эту платформу рано или поздно придётся делать. СВОЁ, Российское! И что произойдёт, если единственный «стандартный дистрибутив» отстанет от мирового апстрима на годы, а мы уже вложили такие суммы в прикладной код? А почему вы думаете, что прикладная программа, написанная и опубликованная под свободной лицензией, но заточенная лишь под один дистрибутив, по-настоящему СВОБОДНА? Сталкивались ли вы когда-нибудь с тем, что адаптация программ под различные условия функционирования позволяет выявить множество незаметных на первый взгляд «подводных камней»? Т.е. процесс кросс-платформенной разработки значительно повышает и качество софта, а стоимость такой разработки, если и растёт, то непропорционально меньше!
На этом разговор ЛОРовского Аналитега с Патриотом не закончился, продолжение их дискуссии смотрите в следующих сериях. :) А здесь я бы хотел подвести черту под вышесказанным. Мы разобрались, что на самом деле объединяет и отличает множество дистрибутивов. Другой цели в третьей части и не ставилось.
Продолжение следует...
Всевозможные стандарты и открытые спецификации насквозь пронизывают существующее СПО, помогают пользователям СПО в решении повседневных задач. Прежде всего я имею ввиду LSB, FHS, ODF, рекомендации freedesktop.org, различные RFC, форматы HTML, XML, и др. спецификации консорциума W3C, ... Но также не стоит забывать о документации и внутренних соглашениях в крупных проектах, строгое следование которым позволяет им оставаться на плаву и даже лидировать в отрасли. Именно всё перечисленное объединяет существующие дистрибутивы наряду со свободными лицензиями. Но есть и нечто третье, что также значительно влияет на интероперабельность и совместимость GNU/Linux дистрибутивов. Как ни странно, это сам свободный код! Недостаточно написать программу под свободной лицензией. Настоящая СВОБОДА будет достигнута только после того, как исходник такой программы станет доступен широкой общественности, при этом, сама программа не будет жёстко (или искусственно) привязана только к какому-то одному единственному дистрибутиву (или даже платформе).
Именно так, как перечислено выше, «живёт и здравствует» истинное СПО. Именно такое СПО и следует внедрять в ОГВ. Можно привести массу «положительных» примеров по-настоящему СВОБОДНЫХ программ «повседневного использования»: почтовый клиент, текстовый редактор, интернет обозреватель, растровый графический редактор, медиаплеер - всё это мало чем отличается в различных дистрибутивах GNU/Linux, когда речь заходит об одной и той же СВОБОДНОЙ программе, например, Firefox. Поскольку в виде исходных текстов в природе не существует «Firefox для Debian», «Firefox для OpenSUSE», «Firefox для FedoraCore», итд (извините, если кого «забыл»), есть только один главный репозиторий исходников Mozilla Firefox. Тоже самое касается главного репозитория ядра ОС - проект «Linux» на kernel.org, да и всех остальных по-настоящему СВОБОДНЫХ программ и библиотек.
За «отрицательными» примерами также далеко ходить не надо. Массу проблем пользователям доставляет ПО с лицензионными или патентными ограничениями, когда речь заходит об интероперабельности в свободной среде. Закрытые драйверы, прошивки (фирмварь), закрытое ПО типа Adobe Flash Player, последние версии закрытого браузера Opera, имеющего проблемы сборки в ALT Linux'е, т.н. Плеер ЭОР НП, адаптированный только для одного из дистрибутивов ПСПО, даже «освобождённому» исходному коду распознавалки текстов CuneiForm ещё очень далеко до того, чтобы занять своё место в списке «историй успеха», поскольку одна лишь только свободная лицензия всех проблем переносимости не решает, всех свобод не обеспечивает.
Поэтому, дорогие чиновники, выбирая между двумя архиваторами 7zip и RAR, не забывайте, что только 7zip пронизывает все дистрибутивы GNU/Linux сверху до низу, а файлы, созданные этим архиватором, действительно не вызывают неудобств на каких-бы то ни было платформах. Даже под MAC есть ни один lzma-совместимый архиватор! В отличие от RAR-архивов, где в основной массе дистрибутивов внутри архива есть проблемы и с кодировками имён файлов, и наличием (или отсутствием) проприетарной библиотеки, от которой зависит львиная доля наиболее значимого функционала RARv3. Впрочем, в мае 2011 появился «The Unarchiver», частично решив проблему с проприетарностью старого unrar (для RARv3), но в основные репозитории он ещё не попал, так что пока юзаем ppa:nilarimogard/webupd8. :)
А как же дистрозависимый свободный код и дистрозависимые патчи (исправления)? Чтобы определиться, давайте и это «разберём по полочкам». Многие инсталляторы, пакетные менеджеры, системы инициализации/загрузки, издревле считавшиеся дистрозависимыми, давно перестали быть таковыми. Этот по-настоящему СВОБОДНЫЙ код зачастую уже не ограничивается рамками какого-то одного дистрибутива или даже какой-то одной платформы. Apt, Adept, Synaptic, Alien, dpkg, Debian-installer, Anaconda, rpm (имеется ввиду консольная утилита и набор связанных библиотек), System-V Init, Upstart, RunIt, InitNG, OpenRC, Launchd, … - вот лишь некоторые примеры.
Но, даже в том случае, когда область применения дистрозависимого инструмента системного администратора пока ограничена одним единственным дистрибутивом, я бы считал и этот код полностью СВОБОДНЫМ по двум причинам: во-первых, многообразие дистрибутивов обеспечивает всем нам пресловутую информационную независимость, здоровую конкуренцию схожих проектов между собой, право выбора, наконец («больше дистрибутивов хороших и разных» - помните, да?), во-вторых, потенциальное использование в будущем этого свободного кода в других дистрибутивах тоже пока никто не отменял.
Дистрозависимые патчи бывают очень разными. Если хороший и нужный патч, ставший сначала достоянием какого-то одного дистрибутива, не попал в апстрим, налицо явно чья-то недоработка. Постоянное присутствие таких патчей не характерно, скорее наоборот - они носят временный (краткосрочный) характер. Попав в апстрим, такие патчи перестают быть дистрозависимыми. Безусловно, основная масса дистрозависимых патчей не затрагивает основной код программы, а касается лишь системы сборки программы в сборочном окружении конкретного дистрибутива.
Другими словами именно система сборки программы адаптируется для разных окружений (дистрибутивов), т.е. создаётся по-настоящему переносимый СВОБОДНЫЙ код (кросс-платформенная разработка). Собственно, до уровня configure/make/install эти патчи даже не стоит называть дистрозависимыми, поскольку им опять же заказана прямая дорога в апстрим. Кстати, вот хороший пример адаптации сборки старого OpenOffice.org 2.x c патчами от ИнфраРесурс под Gentoo Linux. Читать от ссылки до конца страницы, хотя основное, что хотел тогда сказать, я сказал на первой странице этого топика. С нынешней колокольни мне эти патчи от Инфры видятся хоть и полезными, но их стабильное отсутствие в апстриме как раз намекает на неправильность и весьма далёко от «истории успеха».
Не стоит путать «заплатки», стабилизирующие работу или исправляющие критические уязвимости, добавленные в текущий сорцовый релиз дистрибутива из нестабильного дерева апстрима некоего проекта (к примеру libc), с дистрозависимыми патчами только потому, что они уже попали в один дистрибутив и ещё не успели попасть в другой. Просто разработчикам первого дистрибутива уже доподлинно известно, что этот код появится в будущих стабильных выпусках апстрима проекта (например, libc), «синхронизация» таких патчей между дистрибутивами будет выполнена позднее опять же на уровне апстрима.
Другими словами, любой патч обязан попасть в апстрим! Если он к этому не стремится, значит с этим патчем не всё в порядке!!! Приведу такой пример, когда один камрад, услышав мольбы о помощи всего Башкирского народа, реализовал решение с национальной раскладкой клавиатуры, связался с мейнтейнером пакета xkb и это решение стало достоянием сразу всех будущих выпусков любых дистрибутивов GNU/Linux!!! См. файл типа /usr/share/X11/xkb/symbols/ru в своём дистрибутиве - есть ли там нечто похожее на:
partial alphanumeric_keys
xkb_symbols "bak" {
include "ru(winkeys)"
name[Group1]= "Russia - Bashkirian";
key.type[group1]="FOUR_LEVEL";
key { [ 0x010004d9, 0x010004d8, Cyrillic_io, Cyrillic_IO ] };
key { [ exclam, quotedbl, 1, 1 ] };
key { [ 0x010004e9, 0x010004e8, 2, 2 ] };
key { [ 0x010004a1, 0x010004a0, 3, 3 ] };
key { [ 0x01000493, 0x01000492, 4, 4 ] };
key { [ 0x010004ab, 0x010004aa, 5, 5 ] };
key { [ colon, semicolon, 6, 6 ] };
key { [ 0x01000499, 0x01000498, 7, 7 ] };
key { [ 0x010004bb, 0x010004ba, 8, 8 ] };
key { [ question, parenleft, 9, 9 ] };
key { [ numerosign, parenright, 0, 0 ] };
key { [ minus, percent, minus, underscore ]};
key { [ 0x010004af, 0x010004ae, equal, plus ]};
key { [ 0x010004a3, 0x010004a2, backslash, slash ]};
include "level3(ralt_switch)"
};
Представьте на секунду, какой «свободный код» можно напридумывать «за железным занавесом», кому он на хрен будет нужен! По-настоящему СВОБОДНЫМ он не будет никогда, если его разработка ограничится пределами одного единственного дистрибутива (платформы), национального языка и фонда алгоритмов и программ! Важный и нужный код, не попавший в апстрим, требует непрерывной поддержки, постоянной адаптации под новые версии, а это не только неоправданные трудозатраты, но и финансовые потери для тех, кто «дэвушку танцует»!
Дистрозависимые патчи ядра Linux - вообще отдельная тема и уж тем более не для такой большой статьи. Но если вкратце, такие патчи ядра, которые систематически не попадают в апстрим kernel.org - это ЗЛО! Разработчикам ядра просто виднее «что такое хорошо, а что такое плохо». И если почти во всех дистрибутивах в стремлении сделать красивый бутсплэш дистростроитель незаметно для всех ломает какую-то функциональность, это чисто его трудности (и проблемы тех, кто выбрал этот дистрибутив). Но, по правде говоря, GNU/Linux дистрибутивов, предоставляющих «из коробки» по умолчанию чистое «ванильное» ядро, действительно не так много. А обусловлено это тем, что такой огромный и сложный пакет, как ядро Linux, также как и сами дистрибутивы, собирается с разными функциональными особенностями на усмотрение дистростроителя и, кроме того, напрямую с самим ядром никакой прикладной софт не взаимодействует, поэтому различия в «начинке» не отражается на работе большинства обычных «повседневных» программ.
Теперь, практически полностью раскрыв тему патчей, снова вернёмся к наиболее дистрозависимому коду. Из не рассмотренного остались программы поддержки инфраструктуры сборки и тестирования дистрибутивов - сборочные среды, сорцовые репозитории, инструментарий для совместной работы над проектом, отслеживания ошибок, итп. И здесь существует по меньшей мере три, а то и все четыре мнения. Рассмотрим перечисленное с разных точек зрения: простого конечного пользователя дистрибутива, системного администратора, выполняющего первый уровень поддержки, дистростроителя (разработчика дистрибутива), а также некоего гипотетического лица, ратующего за интересы нашей отчизны... :)
По всей видимости, конечным пользователям д.б. безразлично, как устроен сорцовый репозиторий, каким дополнительным инструментарием сборки пользуются разработчики дистрибутива, «жизненно важными» для них я бы назвал совершенно другие критерии. В некоторой степени очень продвинутому пользователю м.б. небезразличен инструмент поддержки, через который он сам может связываться со службой технической поддержки (разработчиками) дистрибутива, однако такие навыки характерны скорее для системных администраторов, да и то, не для всех.
Типичный системный администратор здесь ближе к обычному пользователю, поскольку вопросы массового развёртывания и индивидуальной инсталляции/техподдержки никак не пересекаются с инструментарием разработчиков дистрибутивов. И только наиболее продвинутым системным администраторам, равно как и самим разработчикам дистрибутива, важно всё, что касается сборочной среды, сорцового репозитория и программ, обеспечивающих поддержку дистрибутива и совместную работу. В данном случае они выступают как пользователи этих инструментов, сделавших свой осознанный выбор. А что, как и все мы, имеют на это полное право!
Надо сказать, не только «любимый» инструмент, но и другие факторы оказывают влияние на выбор дистрибутива. Например, для разработчика - это вся совокупность инструментов, а также политика и атмосфера взаимодействия в коллективе разработчиков, а для не коммьюнити-дистрибутивов - и другие условия оплачиваемого труда; для системного администратора - это прежде всего объём заведомо удовлетворительно решённых задач и собственное время, которое придётся затрачивать на инсталляцию, «допиливание» и техподдержку пользователей, возможность оперативного саппорта со стороны разработчика, а при отсутствии таковой - возможность самостоятельного внесения изменений; для простого конечного пользователя - это прежде всего скорость работы и функциональность дистрибутива, удобство интерфейса (ублажение привычек и ожиданий?), скорость и качество работы локальной или внешней техподдержки.
Но есть ещё одна «маленькая деталька», которая в той или иной степени важна для всех троих - для пользователя, администратора и разработчика. Только каждый из них смотрит на эту «детальку» с «собственной колокольни». При этом, на саму «детальку» ложится львиная доля тех различий, которые и создают бесконечное многообразие дистрибутивов! Итак, помимо дополнительного инструментария создания дистрибутива (не забываем, что есть ведь и стандартные средства разработки, присущие для всех POSIX-совместимых систем), определяющую роль в многообразии играют: аппаратная платформа, для которой создаётся дистрибутив, всё поддерживаемое оборудование, определяемое доступными модулями ядра, круг пользователей и решаемых ими задач, что является минимальной (базовой) системой, а что вынесено за её пределы, какие компоненты входят в сам дистрибутив, а какие можно до-установить из внешнего репозитория, каким образом выстроена схема зависимостей одних компонентов от других, какие компоненты определены (выбраны) «по умолчанию», а какие вторичны (это в значительной степени влияет на степень интеграции одних компонентов с другими, и время, затрачиваемое администратором на смену «умолчальных» компонентов), какие установлены требования по безопасности и многое, многое другое...
И вот теперь, пройдя краткий экскурс по ключевым моментам сходства и различия дистрибутивов GNU/Linux, попробуем взглянуть на получившийся «многослойный пирог» с позиции человека, ратующего за информационную независимость нашей вотчины. Особо подчеркну, эта позиция в своём исходном состоянии возможно не будет иметь ничего общего с позицией типичных сторонников распространения СПО, своего рода «религиозных фанатиков на почве любви Linux». Просто представим эдакого патриота, желающего и СПО поиметь, и деньжат сэкономить, и ИТ-индустрию в накладе не оставить. Ну, а что получится из нашего с ним диалога - смотрите сами!.. :)
Патриот: Выбор одного стандартного дистрибутива позволил бы вести разработку без излишнего разбрасывания. И главное, чтобы это был отечественный дистрибутив.
Аналитик: Во-первых, дистрибутив - это способ дистрибуции (распространения) СПО, которое не является чисто отечественным продуктом. В данном случае отечественной будет только сборка комплекта программ и библиотек в единое целевое решение. Имеется ввиду, что процессом сборки на российских серверах управляют отечественные специалисты. Доля чисто отечественных наработок в дистрибутиве относительно остального свободного кода не превышает и десятой доли процента! И это вы называете «отечественным дистрибутивом»!?
Во-вторых, не существует такого понятия: «стандартный дистрибутив». Все дистрибутивы можно условно считать стандартными, если в них соблюдаются соответствующие стандарты и спецификации. Дистрибутивы GNU/Linux используются очень широко - на рабочих станциях, на серверах, во встроенном оборудовании и даже на супер-компьютерах и мейнфреймах. Почему дистрибутив для десктопа или супер-компьютера д.б. один? Разве у них одинаковые задачи? Почему для диаметрально различающихся по мощности рабочих станций чиновников дистрибутив д.б. один? Ведь владельцев мощных компьютеров не устроят «легковесные» графические среды, а слабые компьютеры, наоборот - «не потянут» более продвинутые современные графические оболочки.
Наконец, почему д.б. один дистрибутив для школ, налоговых инспекций, Роспотребнадзора, судов, ФАС и ФСБ? Разве у них одинаковые критерии выбора? По-вашему логично, что ПО, призванное заменить Windows NT, под управлением которого работают наши стратегические установки пуска ракет S300, должно работать и на ПК школьников? Если так, то зачем снова что-то разрабатывать? Ведь государству уже сданы целых пять вариантов ПСПО - пусть используют и развивают своими силами! Что, не могут своими силами? Значит придётся платить за доработку каждого решения для каждой конкретной организации. А раз так, то какая разница, платить одному разработчику за 100 проектов или разделить то же число проектов на десяток разработчиков? Хотя делать ставку на единственного разработчика я бы не стал - слишком большой риск от «складывания яиц в одну корзину», слишком велика нагрузка и ответственность на единственного поставщика решения, отсутствие конкуренции (необоснованно создаваемая монополия), и опять же - большая проблема с обеспечением специалистов на местах: максимально задействовать весь имеющийся потенциал разработчиков и сисадминов не получится. Ведь взамен Microsoft мы получим только один небольшой коллектив, в лучшем случае - из 100-400 специалистов.
В-третьих, те ключевые особенности, которые отличают один дистрибутив от другого, на самом же деле показывают конечным пользователям, насколько гибок свободный софт, как его можно адаптировать для разных условий, платформ и задач, по-разному собрав, подобно тому, как из одного пластилина можно слепить множество разных красивых фигурок и не факт, что какая-то одна из них будет «стандартной», «лучшей», «самой красивой» и т.п.
В-четвёртых, разрабатывая и улучшая лишь один дистрибутив, мы можем делать что-то полезное для двух вещей: улучшать нечто, связанное только с этим дистрибутивом (инсталлятор, пакетную систему, дополнительное сборочное ПО, итд), и возможно тогда эти наработки действительно мало кому будут нужны во всём мире, только пользователям этого дистрибутива, но относительно всего СПО - это менее десятой процента всего свободного кода, а значит пользователи даже не заметят этих улучшений, но мы можем улучшать и сам свободный код, входящий в состав нашего единственного «стандартного дистрибутива», и тогда пользователи почувствуют толику нашего участия, но тогда это либо почувствуют пользователи других дистрибутивов (если мы отдаём наши наработки в мировой апстрим, но выходит, в таком случае «мы разбрасываемся»!), либо мы идём по пути изоляционизма, отгородившись «железным занавесом» от всего мирового апстрима, а это значит куда большие вложения, поскольку все наши наработки придётся постоянно прикручивать и вечно гнаться за мировым апстримом, за которым нам и не угнаться, да и наш код не будет никогда предметом гордости, он может быть и непереносим, и содержать существенные ошибки, он не будет по-настоящему СВОБОДНЫМ, невзирая на доступность и свободную лицензию! Например, если мы хотим локализовать интерфейс какой-то нужной программы, лучше сразу научиться у мирового апстрима, как делать это «правильно»: наши наработки должны попасть в мировой апстрим, а не только в фонд алгоритмов и программ, тогда дальше нас уже не будет сильно заботить, насколько далеко ушёл вперёд апстрим некоего нужного пакета, и нам, и апстриму будет проще вести адаптацию перевода интерфейса последующих версий по уже имеющимся готовым наработкам.
В-пятых, выбранный дистрибутив - это лишь платформа. Затраты на поддержку платформы ничтожны в сравнении с затратами на ПО, которое под эту платформу рано или поздно придётся делать. СВОЁ, Российское! И что произойдёт, если единственный «стандартный дистрибутив» отстанет от мирового апстрима на годы, а мы уже вложили такие суммы в прикладной код? А почему вы думаете, что прикладная программа, написанная и опубликованная под свободной лицензией, но заточенная лишь под один дистрибутив, по-настоящему СВОБОДНА? Сталкивались ли вы когда-нибудь с тем, что адаптация программ под различные условия функционирования позволяет выявить множество незаметных на первый взгляд «подводных камней»? Т.е. процесс кросс-платформенной разработки значительно повышает и качество софта, а стоимость такой разработки, если и растёт, то непропорционально меньше!
На этом разговор ЛОРовского Аналитега с Патриотом не закончился, продолжение их дискуссии смотрите в следующих сериях. :) А здесь я бы хотел подвести черту под вышесказанным. Мы разобрались, что на самом деле объединяет и отличает множество дистрибутивов. Другой цели в третьей части и не ставилось.
Продолжение следует...