Каждое последующее крупное регулярное массовое мероприятие, в названии которого содержится слово Linux, отличается от своих предшественников все более деловым характером. Очередная выставка LinuxWorld вообще отметилась успокаивающими плакатами «Открыта только для бизнес-профессионалов. Никто моложе 18 лет не будет допущен»…
Журнальная статья в еженедельнике – не выставка, поэтому у нас все намного демократичнее. Никаких возрастных цензов. Однако приверженность демократии и у нас ни в коем случае не является ни синонимом слепой веры, ни неуклюжей попыткой «нравиться всем». И здесь, увы, одним умением дистанцироваться от религиозно-ритуальных войн и игр (точнее, заигрываний) в «кругом враги, но победа будет за нами», не обойтись. Потому что на протяжении уже лет шести-семи область, обозначенная в массовой прессе словом «Linux», по сути, является миром без цифр. То есть нельзя сказать, что цифр нет вообще – какие-то цифры, безусловно, существуют. Но вот они-то как раз никого и не устраивают – приверженцам одних идей они кажутся завышенными, приверженцам других – заниженными. А еще есть цифры, справедливость которых оспаривается всеми оппонентами. И наконец, есть очевидно несуразные цифры – просто потому, что таких цифр всегда и всюду более чем достаточно. В этих условиях оперировать какими-либо цифрами вообще просто невозможно, причем любыми, даже оценками численности противостоящих сторон, что в итоге приводит к решению всех споров на основе принципа «кто горластей и выносливей, тот и прав». Впрочем, так как читателя ожидает больше вопросов, чем ответов, мы начнем с этакого искусственно построенного семантического фильтра – если вам не понравятся следующие вопросы (умышленно оставленные без ответов), лучше и не продолжайте чтения. Потому что дальше вопросы будут уже совсем не такими потешными (запомните это слово – оно характеризует отношение автора статьи к «серьезности» теста-фильтра), и на многие из них автор даже не будет пытаться искать ответ – слишком уж это непростая область, Linux. Итак, известная компания OneStat в результате очередного «зондирования» двухмиллионной выборки из сетевой аудитории пользователей своих сервисов (по 20 тыс. случайно выбранных человек из 100 стран) пришла к следующим выводам: всего 0,36% компьютеров из двух миллионов были идентифицированы как работающие под ОС Linux, а 96,97% идентифицированных машин управлялись разными ОС семейства Windows. В то же самое время результатом google-поиска фразы «Linux is ready for the desktop» (именно фразы) являются 14 тыс. 200 страниц, а вот поиск по сочетанию слов «+Linux +ready +desktop» в результате дает без малого 40 млн ссылок. Ну а теперь, собственно, фильтрующие вопросы: является ли двухмиллионная выборка представительной, могут ли два миллиона лемм…, простите, пользователей, не ошибаться, и наконец, главное – был ли прав робот Бендер?
Иллюзии нестабильности
Нет, о таких мелочах, как стабильность работы операционной системы мы говорить в середине 2006 г. не будем. Просто потому, что кто бы там что ни говорил, следует признать очевидное – все распространенные сегодня современные операционные системы достаточно стабильны для самого массового «настольного» применения. Для автора статьи это неопровержимый факт. Естественно, надо учитывать ранее упомянутую характеристику области Linux («без цифр») – исследований, аналогичных проводимым OneStat и направленных на изучение числа отказов ОС, например за год, не наблюдается (а даже если бы они и наблюдались… слишком уж велика разница масштабов инсталлированных парков, чтобы можно было делать какие-то выводы). Но на практике устойчивая работа операционных систем разных семейств (Windows, Linux, *BSD) наблюдается, и этот показатель сегодня уже кажется бесспорным. Речь же идет о нестабильности проектных процессов, якобы присущей специфике организационной структуры и фундаментальным принципам создания Linux. Сразу следует дать одно важное пояснение, и это приходится делать из года в год, раз за разом: под словом «Linux» в статье понимается именно то, чем Linux является – ядро UNIX-подобной операционной системы.
Что же принято понимать под «нестабильностью» в данном контексте? Естественно, очевидное: полное игнорирование командой разработчиков любых традиционных моделей управления проектными процессами. Мы сейчас не будем тысячекратно повторять описание модели «базарной» разработки – желающие могут мгновенно найти исчерпывающее описание ее в считающемся эпохальным документе по ключевым словам «+базар +собор +рэймонд». Нас интересуют менее очевидные следствия, для которых неуправляемый характер разработки является предпосылкой. Так, Linux (еще раз напомню – ядро ОС) практически не имеет актуальной проектной документации, и тем более – упреждающей, отражающей перспективные модификации. Роль актуальной документации в большинстве случаев играют сами исходные тексты. Есть, конечно, различные попытки зафиксировать дизайн Linux на бумаге, в виде статьи или книги, но они все быстро устаревают и не имеют такого фундаментального характера, как, например, не утрачивающие актуальности классические руководства по архитектуре ядра UNIX. Второе не менее очевидное следствие – отсутствие фиксированного множества внутренних интерфейсов ядра (хоть оно и кажется неочевидным, на самом деле является предыдущим следствием, сформулированным системным программистом, а не архитектором), в первую очередь – подмножества интерфейсных вызовов, ориентированных на разработку драйверов. Следует заметить, что эти два следствия из иллюзии нестабильности – не выдумка автора статьи, о них говорит и правая рука Линуса Торвальдса в проектном процессе Linux, Грег Кроах-Хартман, да и сам Торвальдс придерживается той же точки зрения. Они объясняют иллюзию нестабильности тем, что разработка Linux – не классический проектный процесс, а эволюционный. И, естественно, отстаивают свое представление о нестабильности процесса разработки как об иллюзии. Впрочем, давайте дадим слово самому Грегу Кроах-Хартману: «Ядро (Linux) не создавалось на основе большого проектного документа, перечня требований и т. п. Оно все время развивается на основании потребностей текущего момента. В момент старта проекта поддерживалась всего одна процессорная архитектура – тогда этого было достаточно. Впоследствии добавлялись поддержки еще одной целевой архитектуры, и еще одной, и т. д. И каждый раз, когда добавлялась поддержка новой архитектуры, разработчики решали, что действительно необходимо для ее поддержки, и реализовывали только это действительно необходимое. Они не считали высокую гибкость архитектуры ядра главным требованием проекта, потому что не знали, куда будет двигаться проект и что может впоследствии понадобиться. Ядро изменялось только тогда, когда это было необходимо, и только так, как это было необходимо. Оно масштабировалось вниз, до уровня микроконтроллеров, и вверх – до уровней, которые требовали разработчики. И каждый раз, когда происходили изменения ядра, код изменений объединялся с основным кодом проекта, как того требует лицензия, так, чтобы все желающие могли получить от него пользу». Такая обширная цитата приведена неслучайно и даже не для демонстрации убедительности аргументации, не подкрепленной цифрами. Дело в том, что если задуматься над неопределенностью таких использованных Кроах-Хартманом понятий, как «достаточно» (кому достаточно, почему достаточно?), «разработчики решали» (разве разработчики и боги – синонимы?), «действительно необходимо» (опять же – кому и почему) и т. п., то получится, что Грег Кроах-Хартман детально обрисовал… на самом деле нестабильный проектный процесс. Впрочем, на одной из конференций, проходящих в рамках LinuxWorld, Кроах-Хартман как будто по заказу подтвердил это предположение в обсуждениях стабильной версии корпоративного масштаба ядра Linux. «Я думаю, что стабильное ядро ОС Linux корпоративного масштаба – это оксюморон», – скажи такие слова кто другой, его бы Linux-тусовка съела с потрохами, да и услышанным от кого попало таким словам можно было бы и не поверить. К третьему же человеку в иерархии разработчиков Linux нужно прислушаться. Впрочем, это и очевидно – требующая стабильного продолжительного интервала эксплуатации без модификаций (порядка 18 месяцев) корпоративная модель очень плохо уживается с особенностями проектного процесса ядра Linux, в котором модификации (в том числе и ключевые) могут поступать и поступают каждый день. «..если вы используете одни и те же аппаратные средства, одно и то же прикладное ПО, вас устраивает уровень надежности и безопасности, предоставляемые системой, вам ничего не надо менять и вы можете использовать корпоративную модель. Но большинство сейчас работает иначе…», – так объясняет это несовпадение Кроах-Хартман.
Если же говорить о весьма чувствительном к стабильности проектного процесса рынке ОС для встраиваемых приложений, то и здесь картина получается неясной. С одной стороны, два лидера в области адаптации Linux к потребностям разработчиков систем «мягкого» реального времени (т. е. таким, в которых несоблюдение временных требований не приводит к катастрофическим последствиям) – MontaVista и Wind River – добились весьма впечатляющих результатов и заполучили нескольких серьезных заказчиков realtime Linux (в частности, MontaVista – NEC, поставляющий терминалы крупнейшему японскому оператору мобильной связи DoCoMo, а Wind River – Boeing, в большом оборонном заказе). С другой стороны, некоторые производители отказались от использования Linux в основных модельных рядах своих изделий (так, например, поступила Linksys в WiFi-роутерах семейства WRT54, заменив Linux на VxWorks по экономическим причинам), многие компании, анонсировавшие продукты с использованием Linux, так и не вывели их на рынок (их список очень велик для журнальной статьи), и наконец, применение Linux в некоторых продуктах так и не стало палочкой-выручалочкой (достаточно вспомнить первый Linux-таблет Nokia 770). С третьей стороны, для сравнения – созданная одним человеком ОС uC/OS за менее чем 7 лет превратилась из сопровождающего книгу кода в полноценный великолепный продукт, удовлетворяющий самым серьезным требованиям, что подтверждено многими сертификатами (в первую очередь, допускающими применение в области крайне высоких рисков – авионике), а перечень ее пользователей вызовет приступ черной зависти у самого серьезного поставщика ПО. К чему автор «приплел» здесь абсолютно неуместную uC/OS? Исключительно для демонстрации того, что не существует единого пути создания успешного программного продукта, и всякий успех – понятие относительное.
Так что же с иллюзией нестабильности? Есть ли она, или все же ее нет? В мире без количественных оценок что-либо определенно сказать трудно, и даже, например, суточный интервал выхода ядер версий 2.6.16.17 и 2.6.16.18, устраняющих потенциальные уязвимости, ни о чем вразумительном не говорит. Понятно только одно – ответ на главный вопрос этого раздела статьи зависит от массы особенностей компьютерной системы отвечающего. И никаких формальных способов найти этот ответ, увы, нет.
Иллюзии несвобод
Казалось бы, какие несвободы могут быть в мире, строящемся на идиллических, практически коммунистических моделях: «от каждого разработчика и пользователя – код и участие по способностям, каждому разработчику и пользователю – инструментарий и прикладные программы по потребностям» и «код – достояние всенародное». Оказывается (это слово надо было бы закавычить), далеко не все так просто. Потому что мир несовершенен еще со времен изгнания первой согрешившей парочки из Рая, и даже в идиллии находятся те, кому она по каким-то причинам не нравится. Например, некоторые принципиально не хотят делиться исходными текстами своего кода. И ладно бы, не делились чем-то таким, чему цена в базарный день – пятак за три кучки. Ан нет, принципиально без исходных текстов почему-то распространяются, к примеру, те же злополучные драйверы. Да еще и видеокарты. Совсем недавно сторонники полностью открытого ПО занимали следующую радикальную позицию: модули ядра, распространяемые только в бинарном виде, недопустимы, неприменимы, неэтичны, точка.
Правда, драйверами видеокарт предпочитали все же пользоваться. Естественно, при таком положении вещей многие выпускающие дистрибутивы компании отказывались (да и сейчас отказываются) от включения в свои сборки систем на основе Linux бинарных модулей (как, например, Novell). В принципе, в главном сегменте применения дистрибутивов на основе Linux – серверном – подобное ограничение некритично. И, если забыть религиозные принципы, – вовсе не из-за недоверия к разработчикам закрытых модулей (в конце концов, серверы под управлением различных версий UNIX, Novell NetWare, Vax VMS, Windows работают годами, а некоторые – десятилетиями). Все дело в том, что серверы – это вотчина тех самых корпоративных требований, в которых стабильность версий, по мнению Грега Кроах-Хартмана, – оксюморон. Нет никаких гарантий, что создатели бинарных модулей ядра будут всегда успевать адаптировать свою разработку к изменениям, например, программных интерфейсов, так как процесс адаптации выходит за пределы системы разработки Linux. Соответственно, потребители серверов или открыто, или же неявно стараются избегать зависимости от бинарных модулей ядра. Совсем другое дело – пользователи рабочих станций и производители прикладного ПО. Здесь своя этика – неэтично пытаться использовать для решения задач то, чем их решать неэффективно (хотя бы потому, что подобная попытка может поставить под угрозу результаты работы не только своей, но и многих людей), и неэтично предлагать для этого неадекватный инструментарий, а соответственно, и предъявлять свои требования. Собственно говоря, мы уже обрисовали предпосылки двух разновидностей несвободы. С одной стороны, производители закрытых драйверов фактически были несвободны в распространении своей продукции одним из традиционных для нее способов – в составе дистрибутива ОС. С другой – пользователи рабочих станций как бы тоже (внутренне) несвободны в использовании распространяемых в бинарном виде модулей ядра – это запрещает этика.
Действительно ли это несвободы? Второй вариант сразу отбросим – в последнее время настроения в сообществе меняются в сторону либерализации закрытого кода. В принципе, и первая разновидность также является иллюзией – любой желающий может воспользоваться распространяемыми изготовителями аппаратных средств модулями ядра (драйверами) и установить их самостоятельно или подобрать себе дистрибутив с уже интегрированными необходимыми драйверами. Это больше вопросы удобства-неудобства, чем свободы-несвободы. Настоящая же несвобода скрыта и на деле является огромной проблемой. За пояснением мотивов отказа от фиксированного внутреннего API ядра обратимся к презентации «Мифы, ложь и правда о ядре Linux» Грега Кроах-Хартмана: «…в Windows USB стек переписывался три раза, с выходом Vista ожидается четвертая его версия… Поэтому Microsoft вынуждена поддерживать три набора различных API на уровне ядра… Это их решение, мы же от такого подхода отказались, и это позволило нам добиться компактности, стабильности и безопасности». Итак, Кроах-Хартман кратко обрисовал две модели развития системного ПО – эволюционную с точки зрения стороннего разработчика, и эволюционную – с точки зрения системного программиста. В первом случае бремя «расходов на эволюцию» взваливает на себя создатель системного ПО – именно он решает проблемы совместимости версий, оберегая разработчиков драйверов и пользователей и от своих ошибок, и от эволюционных сложностей. Во втором случае приговор неумолим – эволюция глазами системного программиста требует от всех его «нижестоящих» коллег немедленной адаптации своих программ.
Где здесь настоящая несвобода, а где ее иллюзия? Опять же трудно сказать – все зависит от точки зрения.