архив
hwreport: 1 к 84-м в пользу "source based"
2007-08-01
В извечном споре сторонников прекомпилированных и "самосборных" (source based) дистрибутивов Linux я чаще принимал сторону последних, хотя базовыми инсталляциями Arch и CRUX пользовался всегда с удовольствием и без колебаний: большого смысла собирать "с нуля" базовые утилиты, X Window, KDE или Gnome я не вижу. В некотором роде, моему идеалу соответствует Slackware: достаточно обширный набор прекомпилированных пакетов и готовность к включению в систему практически любого приложения, предоставляемого в исходных текстах.
Однако времена меняются. Популярность ОС Linux возросла настолько, что она оказалась востребованной людьми, понятия не имеющими о том, что такое компиляция, линковка, динамические библиотеки и тому подобное. В ответ на эти потребности появились дистрибутивы, вовсе не содержащие в базовой конфигурации средств программирования. "Прообраз" пользовательской модели в лице MS Windows угадывается без особого труда. Ну, MicroSoft Co. на этом хоть денег заработала (и немалых), а зачем заниматься этим сторонникам open source? Вы можете себе представить человека, в порядке "хобби", работающего над дизайном соковыжималки? А над маркетингом гигиенических прокладок? Я — нет. Хотя людей, всю жизнь самозабвенно совершенствующих свою радиостанцию, мотоцикл, яхту, знаю довольно много.
Очевидно, есть целый ряд видов деятельности, где рыночные механизмы — лучший, а возможно, и единственный способ достижения успеха. Торговля, например. Подозреваю, что создание ПО, "ориентированного на пользователя", — также один из таких случаев. Не существует никаких разумных оснований ориентироваться в собственной эвристической деятельности не на личный интерес, а на вкусы гипотетического пользователя. Если только ты не собираешься результат этой самой собственной деятельности этому самому пользователю продавать. Так что появление дистрибутивов Linux, "ориентированных на пользователя", — нормальное в рамках рыночной экономики явление.
В данном случае есть, правда, некоторые нюансы. Если кто-то реализует бизнес-план, состоящий в том, чтобы на основе GNU/Linux создать продукт и, грубо говоря, немного его продавать, то это — его дело. Но почему покупатель этого продукта иногда полагает ответственным за него всё сообщество open source, я, признаться, понять не могу. По поводу автомобиля, купленного у Форда, претензии следует предъявлять Форду, а не изобретателю двигателя внутреннего сгорания.
Кстати, о Форде. "Заря" автомобилестроения — время, интересное для поисков аналогий с современной IT-индустрией. Не углубляясь в исторические "дебри", стоит напомнить, что очень немногие изобретатели стали успешными промышленниками, хотя и такие случаи были (аналогия между Возняком и Бенцом напрашивается сама собой). Как и ныне в IT, в рамках автомобилестроения наиболее успешный бизнес создали не инженеры и изобретатели. И, наконец, главное отличие между Гейтсом и Фордом состоит в том, что второй не пытался объявить предметом патента форму колеса, цвет кузова или количество передач.
Вернёмся к теме, однако. Распространение "пользовательской" ипостаси Linux естественным образом влечёт за собой преобладание прекомпилированных дистрибутивов. То, что изначально было ориентировано на "чистого" пользователя, становится нормой и стандартом "De Facto" для всех. В том числе и для тех, кто потенциально мог бы пополнить собой ряды разработчиков.
Ну ладно, "отцы-основатели" MicroSoft Co. не заинтересованы в расширении круга разработчиков, но с Linux-то ситуация обратная, как будто? Но вот уже программист предпочитает изучать тонкости прекомпилированных дистрибутивов вместо того чтобы разобраться: что в действительности требуется тому или иному приложению. Создаются всё более изощрённые системы контроля зависимостей вместо того чтобы вспомнить, что в половине (а то и более) случаев эти зависимости появляются в ходе линковки. Как-то неловко об этом писать, но всё чаще приходится объяснять, что потребность того или иного приложения в функциях, реализованных в библиотеке версии N, и зависимость бинарного файла приложения от конкретной библиотеки — не одно и то же. Что если компилированный вариант, предлагаемый автором, требует для запуска библиотеки версии N, то это ещё не значит, что то же приложение не может быть собрано с библиотекой версии N-1.
С отказом от самостоятельной сборки пользователь отказывается, заодно, и от тех опций, которые автор вынес в make-файл. Откуда уверенность, что составитель дистрибутива имеет аналогичные с пользователем потребности? Языковые различия, специфика задач, личные пристрастия, наконец, — не имеют значения? Почему-то неявно предполагается, что автор думает, как менеджер MicroSoft Co.: конечный продукт обязан иметь максимально широкий круг потенциальных покупателей. Но в мире open source это довольно часто не соответствует действительности. Автор, возможно, решает свои собственные задачи, "милостиво" предоставляя возможность воспользоваться собственным детищем, модифицировав его в соответствии с вашими потребностями. В том числе — и посредством опций компиляции.
Можно, конечно, и в этом случае положиться на составителя дистрибутива, особенно, если он берётся сделать это для вас за довольно скромное, в общем-то, вознаграждение. Ничего предосудительного я в этом не вижу. Пусть будут дистрибутивы, "ориентированные на пользователя", пусть создание законченных пользовательских конфигураций на базе open source или их платная поддержка станут чьим-то бизнесом... только не нужно забывать, что в основе этого лежит текст программы, написанной и предоставленном кем-то в виде исходного текста. Этот некто может быть весьма далёк и от продажи дистрибутива, и от стоимости абонемента обслуживания. И если число таких людей сократится, то ни составлять дистрибутивы Linux, ни поддерживать системы, на них базирующиеся, через какое-то время не потребуется.
Мораль (чтобы меня опять не спросили, зачем я это всё написал): не стоит увлекаться дистрибутивами, "ориентированными на пользователя" в ущерб дистрибутивам, подразумевающим (и даже требующим) активного участия. Ubuntu — не "венец творения" развития движения open source, а лишь его побочный результат. Хорош ли, плох ли — дело пятое, но если все, вновь приходящие в Linux, будут увлечённо изучать тонкости использования всё более изощрённых пользовательских интерфейсов, то кто же тогда будет их разрабатывать, в конце концов? Давайте хоть время от времени возвращаться к тем самым sources, с которых всё началось. "И воздастся". Может быть. Наверное. Мне так кажется. Иногда, по крайней мере.
А теперь — маленькая иллюстрация в качестве примера.
Набрёл я как-то в Сети на сайт Hardware4Linux. Идея не нова: сбор и предоставление данных о том, какие системы Linux и на каких аппаратных конфигурациях работают. Списки поддерживаемого оборудования имеют практически все авторы драйверов и составители дистрибутивов. Сведения о том, что такая-то версия такого-то дистрибутива работает на таком-то оборудовании (плюс комментарии использующих эту систему) могут, однако, для кого-то быть и полезны.
Я, во всяком случае, согласился дополнить базу Hardware4Linux данными и о своих трёх домашних системах. Естественно, для удобства обработки входных данных авторы предлагают воспользоваться утилитой, которая "опишет" вашу систему в соответствии с задуманным форматом. Ну, не жалко. Идём на страницу загрузки... и обнаруживаем там rpm-пакет объёмом ~70кБ. Какая жалость... А я, как раз, в настоящий момент под Ubuntu. В порядке эксперимента, так сказать.
Для "Debian based distribution", как радостно сообщают авторы, нужно всего-то:
1. apt-get install lsb 2. apt-get install alien 3. alien -i <package>
Поскольку о Debian я, с некоторых пор, уже кое-что знаю, то, воспользовавшись aptitude, я не без удивления узнал, что для того чтобы воспользоваться lsb-rpm-ом, мне потребуется установить десяток пакетов, общим объёмом 8241kБ (970k в архивированном виде)...
Всякий, мало-мальски знакомый с Linux, догадывается (так же, как и я), что для сбора информации об оборудовании и ПО Linux-системы вполне достаточно uname и нескольких утилит с групповым названием ls* (lspci, lsusb, lsmod, etc). Какие восемь мегабайт? Для чего?
Справедливости ради, ответ на первый (из двух заданных) вопрос можно получить в рамках всё от той же aptitude, но на второй.. Я решил пойти по другому пути: скачать архив исходника (11.6кБ) и посмотреть, что же там "внутри". Внутри оказалось два банальных bash-скрипта, запускающих те самые вышеупомянутые утилиты с сохранением результата в bz2-архиве, и трёхкилобайтный C-исходник программы, опрашивающей подключенные принтера. Трансляция никаких трудностей не вызвала и продолжалась вряд ли более 10-ти секунд. Никакая инсталляция для пакета, который предполагается использовать однократно, разумеется, не нужна...
В общем, так я и не понял, зачем был создан lsb-rpm пакет для этой самой hwreport, а инсталляция его под Ubuntu и вовсе представляется маниакальным бредом, да простят меня сторонники прекомпилированных дистрибутивов. Объёмы требуемой загрузки относятся как 1 к 84-м.