Linux и все, все, все... Статьи и колонки в LinuxFormat, 2006-2013
Шрифт:
Далее последовал рассказ о том, как зародилась идея дистрибутива Ubuntu, и об особенностях процесса его разработки. Здесь Марк подчеркнул, что одной из целей дистрибутива было – достижение гармонии между стабильностью и актуальностью включенного в состав софта. Первая задача достигается долговременной поддержкой стабильных релизов, выходящих через определенные промежутки времени (примерно полугодичные, хотя подготовка текущего релиза несколько затянулась), и на протяжении длительного (трех- или пятигодичного) периода пользующихся поддержкой. Вторая же задача осуществима за счет регулярных промежуточных обновлений, предназначенных для пользователей, желающих работать с самым современным
Затем в выступлении прозвучала очень интересная мысль. Мы, дистростроители, сказал, Марк, часто забываем, что наша роль меньше, чем роль тех ребят, которые собственно и разрабатывают те пакеты, которые включаются в дистрибутивы. И дистростроитель должны уважать их работу – в том числе и с помощью сообщений об ошибках, извещения о новых возможностях, включаемых в эти продукты майнтайнерами дистрибутивов, и тому подобными способами.
Логическим продолжением этой мысли было высказывание об аналогичных горизонтальных связях с другими дистростроителями. В первую очередь речь зашла, конечно, о взаимоотношениях с разработчиками Debian – материнской. по отношению к Ubuntu, системы. Но не отвергается и сотрудничество с иными майнтайнерами, такими, как команда разработчиков Fedora, с целью обмена модификациями ядра и пакетов.
Однако и тут Марк подчеркнул, что связи, так сказать, вертикальные – с разработчиками крупных программных пакетов, таких, как Gnome, KDE, Apache, MySQL, Postgress, и многие, многие другие – являются более важными. Потому что в конечном счете именно их работа обеспечивает успех или неуспех любого дистрибутива.
В этом контексте прозвучал и ответ на вопрос, который меня интересовал с первого дня знакомства с Ubuntu: почему для титульного дистрибутива семейства, ориентированного, в том числе, и на начинающего пользователя, в качестве пользовательского окружения был выбран Gnome, хотя, казалось бы, KDE справляется с этой ролью как минимум не хуже. Марк объяснил сделанный выбор тем, что в момент создания Ubuntu Gnome был более простой в использовании средой, нежели KDE. Когда же разработчики KDE, оценив концепцию дистрибутива, предложили вариант со своим десктопом, – родился Kubuntu.
Зашла речь, конечно, и о бизнес-модели, призванной сделать разработку дистрибутива коммерчески выгодной. Здесь интересен следующий момент: вместо создания единой централизованной компании фирма Canonocal, обеспечивающая финансирование разработки Ubuntu и обеспечение его поддержки, привлекает к сотрудничеству распределенные фирмы из разных стран – в настоящее время их более 300, – которые и осуществляют регионально-ориентированную поддержку.
Маленькое отступление: как известно, Ubuntu оказался очень продуктивным клоно-породителем. Помимо всего прочего, от него происходит несколько испанских вариантов дистрибутива, ориентированных на использование в провициальной администрации этой страны; создается впечатление, что скоро в Испании каждая провинция будет иметь свой вариант Ubuntu. Тонкий намек: не пойти ли и нашей стране по этому пути? В этом случае востребованной окажутся и услуги фирм, способных оказать квалифицированную поддержку...
Наконец, речь дошла и до схемы разработки открытого софта вообще и дистрибутива Ubuntu в особенности: о механизмах контроля версий и веток исходного кода, о методах совместной работы над документацией и ее переводами на разные языки – например, на санскрит (да, товарищи, в Ubuntu предусмотрена и такая локаль). Что, как было убедительно продемонстрировано, действительно, оказывается нынче ключевым моментом для любого проекта Open Source – как с технологической стороны, так и со стороны, если так можно выразиться, социальной. Впрочем, для открытых исходников
Действительно, ведь сам принцип разработки открытых исходников базируется на вовлечении в процесс максимально широкого круга лиц, к таковой в принципе способных – и это одна сторона вопроса. Другая же, оборотная, выливается в проблему эффективности контроля над изменениями, которая может обеспечить целостность системы разработки и защиту ее от повреждения некорректно написанными фрагментами кода. То есть, попросту говоря, все сводится к тому, чтобы система была «дуракоустойчивой» – и при этом чтоб никто из разработчиков не ушел обиженным...
Вопросы разработки тесно связаны с вопросами обучения. И в планы Canonical входит создание центров обучения, тестирования и сертификации специалистов, в том числе и в России.
Последняя часть доклада, как и положено, была посвящена планам на будущее, то есть разработке следующего релиза, носящего имя Edgy Eft, выход которого запланирован на ноябрь.
Вопросы и ответы
По окончании выступления последовали многочисленные вопросы, на которые давались весьма обстоятельные ответы. Приведу их здесь, поскольку они по содержанию могут составить предмет весьма развернутого интервью. Так сказать, в коллективном исполнении.
Вопрос: Мы видели очень интересный сервис для переводчиков, но он был весь на английском языке. Почему бы не сделать его мультиязычным? А то получается, что сапожники без сапог.
Ответ: Мы решили, что сам интерфейс не нужно переводить. Потому что очень часто подключаются Но некоторые части этой технологии имеет смысл локализовать. Например, это связано с обращениями по поддержке.
Вопрос: Многие компании сейчас завоевывают мир простыми средствами разработки. На сегодняшний день под Linux нет простых средств разработки. Каково Ваше видение простых интерфейсов разработчика?
Ответ: Разработчики Linux пошли довольно трудной дорогой – заново изобрести велосипед. То есть установить новые правила разработки, правила открытого и свободного программного обеспечения. Мы, конечно, не можем рассчитывать на поддержку и помощь со стороны тех людей, которых привлекают легкие правила. Если Вы хотите добиться изменения ситуации, Вы должны убедить сообщество, что такие вещи, как хорошая документация, красивый дизайн, простота использования – это важные и нужные вещи. Я не думаю, что многое из того, что используется сейчас в мире коммерческой разработки программного обеспечения будет портировано под Linux. В первую очередь мы увидим перенос серверных приложений и баз данных, таких, как Oracle, потому что на них есть реальный спрос. Десктопные же приложения, например, Photoshop, имеют под Linux свои аналоги, например, Gimp, и необходимости в их переносе нет. В любом случае, не следует думать, что кто-то это сделает за Вас.
Вопрос: я читал блог разработчика ядра Red Hat, который сказал, что у них очень много жалоб на то, что это работает в Ubuntu, но не работает в Fedora. Он сравнил ядра этих дистрибутивов, чтобы посмотреть на различия, и обнаружил в ядре Ubuntu много мелких дополнений, которые не были включены в главную ветку разработки ядра.
Ответ: ядро Ubuntu публикуется на сайте kernel.org, так что для разработчиков ядра очень легко переносить из него все дополнения в главную ветку. Как правило, эти исправления переходят из версии в версию, но не всегда добираются до новых версий. Бывают, конечно, и случаи, что разработчик торопится и просто забывает переслать свои исправления в главную ветку.