Джеймс Боттомли анализирует промахи Android при взаимодействии с Linux-сообществом
17 октября 2011 года
Компания Parallels, развивающая открытую систему изолированных контейнеров OpenVZ и коммерческие решения для виртуализации, автоматизации хостинга и облачных вычислений, предоставила перевод тезисов доклада "Чему научил Android сообщество open source?", прочитанного Джеймсом Боттомли на конференции Linux Plumbers. Джеймс Боттомли, входит в управляющий совет организации Linux Foundation, занимает пост технического директора по серверной виртуализации компания Parallels и является известным разработчиком ядра Linux (мэйнтейнер SCSI-подсистемы). В своём выступлении Джеймс рассказывает о важности тесной работы с upstream-проектами, приводя в качестве примера отношение разработчиков Android к вливанию написанного кода в основное ядро Linux и размышляя, какие уроки можно извлечь из этой истории.
Джеймс начал своё выступление с общих вещей и для начала попытался ответить, что такое Android. Android – плоть от плоти Linux. И, конечно, самый успешный по количеству инсталляций дистрибутив мобильной операционной системы. Настольные версии Linux во всем их многообразии существенно отстают по численности установок.
Особенности Android:
- В основе платформы лежит форк ядра Linux;
- Написана с нуля часть инструментария, в частности Си-библиотека bionic;
- Создана оригинальная виртуальная машина Java (Dalvik JVM).
На взгляд Джеймса, Android – канонический пример, как не надо делать open source проекты. Болевые точки – значительное отклонение от апстрима в модификациях ядра и изобретение двух "велосипедов"(bionic и Dalvik). Тем не менее, Android – просто вопиюще успешный Linux-дистрибутив. Стало быть, всему сообществу нелишне проанализировать ситуацию и выяснить всю правду. Кто знает, может, трюки из арсенала Android помогут в создании ещё одного успешного проекта на рынке. А успешный проект – это не менее привлекательно, чем красивый и правильный код.
Цели бизнеса и разработчиков практически ортогональны. Для бизнеса важно найти свою нишу, заполнить её и работать над удовлетворением запросов клиентов. Для сообщества разработчиков ценность традиционно составляет лёгкость сопровождения и простота добавления новой функциональности, а также то, чтобы в коде непременно были реализованы наиболее удачные, красивые технические решения.
Компания Google создавала Android как существенное ответвление от основного ядра Linux – недаром дополнительно были созданы две заметные надстройки, библиотека C и JVM. Это было сделано для того, чтобы уложиться в жёсткие сроки и чтобы внести в ядро ряд существенных изменений, необходимых для мобильных устройств. Например – добавить поддержку wakelocks (модуль для того, чтобы ядро поскорее засыпало, но при этом не переходило в спящий режим тогда, когда этого делать нельзя — например, во время разговора по телефону или игры). Все модификации изменили ОС настолько, что драйверы под обычное ядро Linux и под ядро Linux из состава Android — немного разные.
Из всего вышесказанного можно сделать вывод, что форк – зло. Однако это не так. Во-первых, все изменения в обязательном порядке выкладываются в общий доступ, как это предписывается GPL. Для сообщества это огромный плюс: без форков сообщество остановилось бы в развитии, и Google с проектом Android никогда не достиг бы его нынешних высот. Тот факт, что форк был инициирован Google, позволил компании контролировать ход работ над Android и хорошо контролировать процесс разработки. Так что форки не только не нужно запрещать, их нужно всячески поддерживать.
Другой важный вопрос – о том, насколько правомерно считать форк фрагментацией. Большинство сторонников open source, конечно же, ответят, что да, форк – это и есть фрагментация. Но Джеймс в данном вопросе категоричен. Форк – это всего лишь ответвление; фрагментация же начинается тогда, когда результаты форка не получается влить обратно в мейнстрим. В этом отношении – да, фрагментация есть безусловное зло. Она, кстати, уничтожила Unix. Но чтобы форк оставался форком и не превращался во фрагментацию, его результаты нужно вовремя влить в мейнстрим.
Ещё одна тема, вызывающая бурные дискуссии, – природа GPL для бизнеса: добро или зло? Бизнес-пользователи в большинстве считают, что зло. Им не хочется делиться своими разработками со всем миром. Похоже, у людей, которые стояли во главе проекта Android, были аналогичные представления. Но избежать GPL все равно не удалось, и ничего страшного не случилось. Самое главное – соблюдать условия лицензии. И помнить, что именно благодаря GPL мобильная платформа вообще появилась на свет.
Что насчёт виртуальной машины Dalvik ? Это самая инновационная деталь в Android. Применив её, создатели ОС заложили в платформу большой потенциал для создания действительно интересных решений. Уровень приложений для Android отделен от ядра. Ну а restricted API – это средство сделать для «Андроида» любой пользовательский интерфейс. Что мы и видим на гаджетах от разных производителей.
Пока «Андроид» выглядит как дитя гениальных родителей. Между тем, при его создании был допущен ряд больших и обидных ошибок. Первое и главное фиаско – с календарём, совместимым с MS Exchange. По какой-то причине в Android не была добавлена эта функция. Хотя она является одной из основных, например, у Blackberry. Без календаря путь Android на корпоративный рынок был закрыт. Motorola исправила этот недостаток в версии Android 1.6, самостоятельно реализовав нужную функциональность (приложение CorpCal) для телефона Droid. Поддержка календаря в рамках ОС появилась только в версии 2.2. Таким образом ОС потеряла целый год только потому, что в ней не было очевидной возможности.
Более того, создатели Android почему-то не использовали код Motorola, чтобы перенести календарь в ОС. Все оттого, что разработчики Google привыкли писать код «за высоким забором». Google плотно контролирует разработку мобильной операционной системы, «выбрасывая через забор» лишь готовые версии. Для партнёров – производителей оборудования (HTC, LG, Samsung и т.д.) нет раннего доступа к коду. Соответственно, у них и нет времени, чтобы портировать свои разработки в новую версию ОС (хотя отдельные наблюдатели утверждают, что в последнее время ситуация с ранним доступом к коду постепенно улучшается). Возможно, Google боится копирования со стороны Apple.
Ну и самое основное: чему все-таки можно научиться на опыте Google и Android? Первое и основное – неким правилам правильного форка. Надо понимать, что форк – это благо: он развивает сообщество. Для разработчика upstream - единственный способ гарантировать долгую жизнь своему коду. Вот поэтому Parallels сейчас усиленно работает над тем, чтобы интегрировать в основное ядро Linux поддержку контейнеров OpenVZ. Это большая работа, потому что код большой.
С вливанием wakelocks и других модификаций ядра большие сложности, на преодоление которых реально потребуются годы. Сложности начинаются у точки слияния. Процессом нужно хорошо управлять. Как правило, код большой, что делает слияние ещё большей проблемой. Кроме того, те люди, которые вливают код в апстрим, часто воспринимают чужой код как никому не нужную поделку, сделанную на коленке (даже если это не так). Поэтому код, который планируется к вливанию, лучше регулярно показывать сообществу. Даже если слияние – дело далёкого будущего. Лучше, чтобы тебя услышали на раннем этапе. В том числе и те, кто потом будет вливать код в апстрим.
Ряд рекомендаций для того, чтобы слияние прошло как можно более гладко:
- Разбивать код на небольшие фрагменты.
- Но вместе с тем вливать код с реализацией определённой функциональности, а не кусками.
- Быть готовыми приложить большие усилия на этапе вливания кода в апстрим.
Краткое заключение:
- Android – яркий пример, как не стоит делать разработчикам, если хотят развивать детище, а для сообщества – урок по усмирению гордыни.
- Сообществу нужно искать более простые способы принимать ответвившиеся проекты.
- Сообщество должно разъяснять, почему бизнесу не надо бояться open source и GPL.
- Каждый форк должен разрабатываться с прицелом на дальнейшее слияние кода с upstream.
- Несмотря на все сложности, Android один из самых успешных проектов.
Источники править
Любой участник может оформить статью: добавить иллюстрации, викифицировать, заполнить шаблоны и добавить категории.
Любой редактор может снять этот шаблон после оформления и проверки.
Комментарии
Если вы хотите сообщить о проблеме в статье (например, фактическая ошибка и т. д.), пожалуйста, используйте обычную страницу обсуждения.
Комментарии на этой странице могут не соответствовать политике нейтральной точки зрения, однако, пожалуйста, придерживайтесь темы и попытайтесь избежать брани, оскорбительных или подстрекательных комментариев. Попробуйте написать такие комментарии, которые заставят задуматься, будут проницательными или спорными. Цивилизованная дискуссия и вежливый спор делают страницу комментариев дружелюбным местом. Пожалуйста, подумайте об этом.
Несколько советов по оформлению реплик:
- Новые темы начинайте, пожалуйста, снизу.
- Используйте символ звёздочки «*» в начале строки для начала новой темы. Далее пишите свой текст.
- Для ответа в начале строки укажите на одну звёздочку больше, чем в предыдущей реплике.
- Пожалуйста, подписывайте все свои сообщения, используя четыре тильды (~~~~). При предварительном просмотре и сохранении они будут автоматически заменены на ваше имя и дату.
Обращаем ваше внимание, что комментарии не предназначены для размещения ссылок на внешние ресурсы не по теме статьи, которые могут быть удалены или скрыты любым участником. Тем не менее, на странице комментариев вы можете сообщить о статьях в СМИ, которые ссылаются на эту заметку, а также о её обсуждении на сторонних ресурсах.
