LXF97:Ubuntu

Материал из Linuxformat.

Битва за лучший UBUNTU

«Gutsy Gibbon» [«Бесстрашный Гиббон»] почти вышел – удержит ли команда Ubuntu звание популярнейшего в мире дистрибутива? Майк Сондерс разберется...

Дистрибутивы приходят и уходят, как времена года. WinLinux, AlphaNet, Xpresso и многие другие возникали на наших радарах, хвастались новыми возможностями и обещали нанести имена своих создателей на скрижали истории Linux. Ну и где они сегодня? Что произошло? Почему разговор сейчас идет только о Fedora, OpenSUSE, Ubuntu и Ко? Ответ прост: сообщество. Галдеж о так называемых революционных функциях может вызвать пару недель ажиотажа, но не создаст «долгоиграющий» дистрибутив. Так многие из якобы перспективных дистрибутивов, которых мы нагляделись за эти годы, в конце концов ушли в небытие, зачахнув без поддержки разработчиков и участия сообщества.

Но команда Ubuntu все это получила. Они взяли за основу хорошо отлаженную базу Debian, отшлифовали ее, приспособив к пользователю, и поддерживают ее с помощью исключительно работящего и живого сообщества. Сила Ubuntu в том, что он редко пытается вводить пионерские функции, изменяющие мир Linux – он довольствуется стандартными утилитами конфигурации Gnome и отстает по части вызывающих слюнки украшательств вроде Compiz. И тем не менее, это один из самых популярных дистрибутивов в мире.

У популярности есть свои проблемы: прежде всего, нельзя ронять планку. Группа Ubuntu жонглирует обширным массивом потребностей пользователей, решая, какие вещи заслуживают включения в новый релиз, и исправляя столько ошибок, сколько позволяют наличные людские ресурсы. Трудные решения должны приниматься, споры пресекаться – а накопившиеся корзины с грязным бельем вытряхиваться в процессе открытой разработки.

Итак, каким же образом команда Ubuntu и ее родитель – компания Canonical – объединяет все эти элементы и издает новый релиз дистрибутива? На следующих семи страницах мы будем вникать в процесс развития Ubuntu, анализируя предстоящий релиз Gutsy Gibbon (7.10) и прослеживая его прогресс от возникающих идей до исполняемого кода. С помощью ключевых фигур среди хакеров Ubuntu мы поймем, что необходимо для успеха релиза – даже если вы не используете этот дистрибутив, вы окунетесь в самую гущу процессов и людей, собирающих новую версию Linux.

Зарождение

Перед началом пиршества разработки хакеры Ubuntu должны решить, какие функции следует включить.

Представьте себя разработчиком Ubuntu: вы только что открыли дверь последнему, сияющему, новехонькому релизу, и пользователи Linux по всему миру азартно его устанавливают. Вы бросаете написание кода и исправление ошибок, созрев для вполне заслуженного отдыха – но не тут-то было! Уже пора вгрызаться в следующую версию. Ubuntu следует шестимесячному графику разработки (с единственным отклонением в версии 6.06 из-за проблем со стабильностью), поэтому разворот к новым функциям выполняется очень резко.

В команду разработчиков Ubuntu входят и оплачиваемые, и добровольные кодеры: первые трудятся над дистрибутивом полный рабочий день и нанимаются Canonical, а вторые подключаются, когда сами могут. Несмотря на этот «гибрид» платной и бесплатной работы, между двумя группами практически не существует трений, с тех пор как в прошлом Canonical наняла некоторых разработчиков Debian. Для многих кодеров участие в сотворении Ubuntu обеспечивает дальнейшую карьеру в области оплачиваемого создания дистрибутивов.

После отправки нового выпуска Ubuntu на зеркала снова запускается процесс отбора функций для следующей версии. Мэтт Циммерман, технический директор Ubuntu и председатель Технического совета, поясняет: «Идеи предлагаются сообществом Ubuntu и самими разработчиками. Если разработчику нравится идея, он воплощает ее в технической спецификации, которая затем может стать основой для проекта».

Идеи будущих функций накапливаются на Launchpad, сайте поддержки разработчиков Canonical – для Gutsy они перечислены на https://launchpad.net/ubuntu/gutsy/+specs. Некоторые идеи обсуждаются разработчиками лично при встречах. Циммерман продолжает: «Основная активность проявляется на саммите разработчиков Ubuntu, перед началом каждого цикла выпуска. Спецификации рассматривает группа технических экспертов для оценки их правильности и жизнеспособности».

Приоритеты! Приоритеты!

Каждой идее новой функции присваивается приоритет (высокий, средний или низкий), зависящий от спроса на нее, ее влияния на общую стабильность дистрибутива и от того, уложится ли ее выполнение в срок. Launchpad также постоянно информирует о процессе работы над новой функцией: разработчики могут видеть, находится ли процесс в самом начале, хорошо ли продвинулся или готов к бета-тестированию. Здесь же сообщается, кто работает над каждым проектом.

Но как распределить усилия разработчиков? Слово Циммерману: «Canonical определяет, какими проектами займутся ее разработчики, а сообщество само решает, на что тратить свое время. На практике, многие разработчики Canonical занимаются проектами по своим же идеям, но некоторые решения мы принимаем “сверху”». Так что добровольные участники могут облюбовать себе для разработки функции, которые им нравятся, а Canonical придаст определенную направленность своей оплачиваемой команде.

Предложения по функциям поступают со всех углов мира Linux: некоторые дополнения берутся из других дистрибутивов, некоторые зарождающиеся технологии просачиваются из случайных сайтов на SourceForge, а иные являются просто классными примочками, которые пригодятся в следующем релизе Ubuntu. Когда полный список функций готов, менеджер по разработке (в Gutsy это Скотт Джеймс Ремнант [Scott James Remnant]) отправляет его в рассылку разработчиков (http://tinyurl.com/2cxfev), и начинается кодинг...

Повышаясь в ранге

Существует два типа разработчиков Ubuntu: MOTU и Core. Первые является частью команды “Masters of the Universe [Хозяева Вселенной] ”, это большая группа хакеров, поддерживающих программы в репозиториях Universe и Multiverse. Universe охватывает пакеты, которые не считаются достаточно важными для базовой системы, но тем не менее востребованы пользователями. Новые разработчики присоединяются к группе MOTU, упаковывающей программы в Deb-пакеты Ubuntu и поддерживающей исправление их ошибок и проблем безопасности. Показав свою способность создавать хорошие пакеты для Universe, разработчик может просить Технический совет Ubuntu и Совет сообщества присоединить его/ее к группе Core. Если разработчик проделал хорошую работу: создал надежные пакеты, имеет сильные коммуникативные навыки и обширные знания Linux, его/ее принимают в группу Core, работающую над критичными пакетами в репозиториях Main и Restricted (т.е. предназначенных для дисков Ubuntu). Ubuntu имеет свой кодекс поведения: разработчики обязаны взаимно оказывать друг другу помощь, уважение и сотрудничество.

Время кодировать

«Создание дистрибутива – это 1% вдохновения и 99% потогонного труда» – так мог бы сказать Томас Эдисон, живи он во времена Linux...

Хотя Gutsy сейчас [на момент написания статьи, – прим. пер.] находится посереди кипучего процесса разработки, общие цели для него уже установлены, как описано выше. Ключевые функции и поправки команда Ubuntu надеется включить в 7.10, но, как всегда бывает, при релизе дистрибутива некоторые из них могут отпасть, если они не заработают или не будут достаточно стабильными на дату выпуска!

• Рабочий стол Gutsy поставляется с Gnome 2.20, а его Kubuntu-вариант – с KDE 3.5.7. Желающие получить представление о KDE 4 смогут заодно установить его релиз-кандидат. Gutsy впервые включит Compiz Fusion, обеспечивающий умопомрачительные 3D-эффекты рабочего стола на поддерживаемых графических чипах. Пользователи смогут вернуться к стандартному менеджеру окон за пару щелчков мыши. Кроме того, в работе находится новый графический инструмент настройки экрана (разрешение, количество цветов и т.д.) на базе GTK.

• X.org X, оконная система, претерпит несколько изменений: будет включена версия 7.3, обеспечивающая горячее подключение устройств отображения. Одна из преследуемых здесь целей – «пуленепробиваемые X», то есть настройки X’ов при возникновении проблем спокойно возвращаются к стандартным видеорежимам, а не обрушиваются с кучей вывода в командную строку. В интересах всех новичков Linux в мире, мы одобряем эту функцию, с высокой Башни LXF!

• Win-модемы Да, эти противные программные модемы, наиболее широко распространенные на ноутбуках или розданные бесплатно с пакетами широкополосной связи, будут поддерживаться. По крайней мере, некоторые из них. Gutsy обеспечит доступ к некоторым «ограниченным» (restricted – то есть не совсем свободным или открытым) драйверам, чтобы помочь людям выйти в сеть.

• Безопасность AppArmor, система безопасности, позволяющая администраторам блокировать используемые программы и ресурсы, будет доступна как опциональное дополнение. Это система, используемая в Novell SUSE; Red Hat придерживается SELinux.

• Свободный Flash Некоторые кодеры Ubuntu изучают возможность включения свободного Flash-плейера. Сейчас наиболее приемлемый вариант – это несвободный плейер от Adobe, но команда Ubuntu присматривается к Gnash – свободной альтернативе. Однако, Gnash попрежнему отстает от проприетарного плейера.

• Свободный как свобода В техническом обзоре заявлена возможность «не ограниченной» (non-restricted) установки Gutsy, то есть установки с CD без копирования несвободных компонентов на ваш жесткий диск. Считается, что это более разумный подход, чем создание отдельного дистрибутива для сторонников чистоты Open Source и свободного ПО. Он будет называться Gobuntu.

• Варианты Разработчикам, занимающимся интернет-планшетами и другими небольшими устройствами, будут предложен новый вариант Ubuntu: Mobile and Embedded Edition. Кроме того, проект Ubuntu Server получит новую команду от Canonical.

Таковы текущие цели особенностей Gutsy, и при нынешних темпах развития уже видится, что большинство из них войдут в окончательный релиз. На этой стадии у ведущих разработчиков начинают шалить нервы – ведь сайты новостей и журнальные статьи (одна из них перед вами!) принимаются обсуждать новые возможности, и неприятно думать о разочарованиях, последующих, если при окончательном раскрое релиза выкинется что-то важное. Циммерман описывает эту проблему как интенсификацию разработки: «Главное – чтобы множество параллельных проектов шли голова к голове и мы успели бы сделать все запланированное».

Кодировочная лихорадка

И пошло кодирование! Сборщики пакетов из команд Core и MOTU хватают новейший исходный код тысяч программ, добавляют скрипты компиляции Deb-пакетов и генерируют их в духе Ubuntu. Дистрибутив в это время подобен водовороту, постоянно бурлящему и меняющемуся под влиянием разработчиков и перестроения критических зависимостей (например, библиотек Gnome и KDE), поэтому сборщикам нужно постоянно следить за ним и убеждаться, что их родные проекты синхронизированы. Допустим, ответственный за сборку графического инструментария GTK собрал новый Deb-пакет со свежей версией; тогда сборщики GTK-приложений должны гарантировать, что их продукты будут с ним совместимы и запускаться без проблем.

Хотя Ubuntu и построен из пакетов, часть из них – не просто отдельные программы: они существенно преобразуют систему. Например, скрипты запуска (инициализации) существуют в Deb-форме, но их содержание и действия могут внести радикальные изменения в работу Ubuntu. То же относится к пакетам ядра, способным включить или отключить критические части системы (например, драйверы оборудования). Как объясняет Циммерман, такие изменения тщательно проверяются: «Существенные или спорные изменения обычно неофициально обсуждаются сообществом, и проблема решается на основе консенсуса. Если консенсус не достигается, окончательное решение выносит Технический совет Ubuntu».

Разработчики постоянно выгружают свои пакеты с новыми версиями программ или исправлений, и вся эта работа открыта для желающих поучаствовать. Многие рьяные фанаты Ubuntu стремятся «догнать ветвь разработки» – это жаргонное выражение для постоянного обновления до самых последних версий пакетов. Занятие рискованное, но энергичные пользователи отлавливают ошибки и помогают с ними покончить. Возможно, вы слышали термин «триаж» в применении к ликвидации ошибок, но не знаете, что он означает. Когда пользователи представляют отчеты об ошибках в Ubuntu, то ошибки идут на триаж: определяется степень их серьезности и что нужно с ними делать.

Но есть одно «но». Большинство разработчиков Ubuntu заняты превращением в пакеты программ других хакеров, будь то небольшой консольный почтовый клиент или пакет-гигант типа OpenOffice.org. Так что группа Ubuntu должна находить баланс между работой с «притекающими сверху» (от разработчика) исходными кодами и целями дистрибутива. Циммерман пишет: «Труднее всего, когда проект связан с деятельностью, протекающей вне Ubuntu; мы часто зависим от своевременного окончания работ в сторонних открытых проектах.» Если разработчик программы испортил ее и добавил вагон ошибок, сборщик пакетов Ubuntu должен решить, принять ли новую версию или оставить старую (и более устойчивую), рискуя нарваться на протест жадных до новинок пользователей. А иногда, наоборот, сборщики Ubuntu отчаянно ждут новых функций, а таймер «релиз-каждые-шесть-месяцев» тикает у них в ушах.

Сборка пакетов и тестирование

Процесс сборки пакетов с новым ПО, исправления ошибок и добавления изменений в базовую систему продолжается от одного до двух месяцев, прежде чем команда сможет показать что-то конкретное миру. Каждый пользователь Ubuntu может скачать последние версии пакетов и протестировать их на любой стадии, но для упрощения ситуации в более широком мире пользователей Linux, команда Ubuntu выкладывает текущий вариант дистрибутива, отражающий прогресс в работе над ним. Как и окончательный релиз, это автономный, инсталлируемый CD, но он предназначен только для разработчиков – хакеры Ubuntu отговаривают случайных пользователей от его применения.

Каждый дистрибутив имеет кодовое имя для серии таких вариатов: в Feisty Fawn (7.04) они назывались “Herd” [Стадо], а нынешний Gutsy использует кодовое имя “Tribe”[Племя], так что в процессе разработки команда плодит Tribe 1, Tribe 2..., демонстрируя новые возможности и собирая отчеты об ошибках. Эта обратная связь жизненно важна для дистрибутива: она позволяет определить, с чем все хорошо, что требует доработки и что следует отставить ради соблюдения сроков. Затем, примерно за шесть недель до окончательного релиза, безудержная разработка останавливается: новые функции уже не добавишь, радикальные изменения делать некогда. Пришла пора набрасываться на ошибки и делать релиз-кандидаты...

Собери себе Ubuntu

Вот вам способ создать свой индивидуальный вариант Ubuntu, включающий только нужные вам пакеты – так же, как мы делаем это для DVD Linux Format.

Не так уж трудно пересобрать Ubuntu, если вы понимаете принцип работы дистрибутива и не боитесь командной строки. Создание индивидуального варианта – это также отличный способ прочувствовать процесс сборки дистрибутива: вы поймете все сложности, обычно скрытые в релизе Ubuntu за завесой Gnome. Нижеследующее руководство покажет, как извлечь Ubuntu CD, добавить и удалить необходимые вам пакеты, а затем вновь собрать его воедино. Это один из методов, который мы используем для создания супер-мега-расширенной версии Ubuntu на LXF DVD (например, в LXF94 и LXF88)! Имейте в виду, что вам потребуется по крайней мере 3 ГБ свободного места на диске.

1 Получение ISO-файла

Для пересборки Ubuntu нужен образ Desktop CD (тот, что запускается в Live-режиме, а не Alternate CD на базе командной строки). Вы можете скачать последнюю стабильную версию с http://releases.ubuntu.com/feisty/. Скачайте образ ubuntu-7.04-desktop-i386.iso, запишите его в свою домашнюю директорию и переименуйте в feisty.iso. (Это добрых 700 МБ, и тем, кто не обладает терпением святого, здесь не обойтись без широкополосного интернет-соединения!)

2 Монтирование образа

Образ CD нужно подмонтировать к файловой системе. Откройте терминал и, переключившись на администратора (sudo bash), введите следующее:

mkdir /mnt/loop
mount -o loop feisty.iso /mnt/loop

Теперь содержимое feisty.iso доступно в /mnt/loop. Нам надо скопировать его в нашу файловую систему, так что создайте директорию и скопируйте все содержимое, вот так:

mkdir ubuntu-rebuild
rsync -ax /mnt/loop/. ubuntu-rebuild

После этого директория ubuntu-rebuild будет содержать файлы с диска. Теперь можно отмонтировать ISO-образ (umount /mnt/loop).

3 Подготовка

Далее необходимо распаковать сжатую файловую систему с CD Ubuntu; для этого используем SquashFS, представленной в Ubuntu в пакете squashfs; вам также необходимо установить squashfs-tools. Сжатая файловая система подмонтируется так:

mount ubuntu-rebuild/casper/filesystem.squashfs /mnt/
loop -t squashfs -o loop

Теперь в /mnt/loop находится содержимое сжатой файловой системы Ubuntu – той, что используется, когда вы загружаетесь в режиме LiveCD. Скопируйте ее в новый каталог вашей домашней директории:

 mkdir ubuntu-source
 rsync -av /mnt/loop/. ubuntu-source
 umount /mnt/loop

4 Изменение пакетов

Ура: теперь все на своих местах! Теперь немного поколдуем для переключения на файлы дистрибутива, как будто именно его мы и запустили. За это надо сказать спасибо маленькому инструменту chroot: он меняет восприятие корневой файловой системы, и можно «притвориться», что вы находитесь в другом дистрибутиве. Введите следующие команды – первая из них настраивает сетевое соединение внутри файловой системы Ububntu:

cp /etc/resolv.conf ubuntu-source/etc/
chroot ubuntu-source

Теперь вы находитесь внутри каталога ubuntusource, как если бы он был корневым (/). Вы запустили тот же дистрибутив, который идет на Live CD, но теперь его можно изменять! Я не рекомендую удалять пакеты, если вы абсолютно точно не уверены, что делаете; некоторые являются зависимостями для критичных системных пакетов. Но вы можете начать добавление программ с помощью apt-get – например, чтобы добавить AbiWord в вашу систему:

apt-get install abiword

Программы, добавленные на этой стадии, будут присутствовать на финальном CD/DVD, когда мы его пересоберем. Так что вы можете добавить Xfce, если это ваше любимое окружение рабочего стола, или пакет ‘’build-essential’’, если вам нужен GCC и иже с ним, готовое к запуску.

5 Обновление

Закончив, наберите exit, чтобы покинуть файловую систему Ubuntu и вернутся в свой обычный дистрибутив. Теперь надо сгенерировать список файлов, имеющихся в обновленном образе Ubuntu. Для этого наберите следующую команду-монстр:

chroot ubuntu-source dpkg-query -W --showformat=’${Package} ${Version}\n’ | grep -v deinstall > ubuntu-rebuild/casper/filesystem.manifest

Необходимо также сказать установщику Ubuntu, когда он запустится, чтоб игнорировал определенные пакеты. Например, после инсталяции иконка «Установить Ubuntu» [Install Ubuntu] на рабочем столе вам уже ни к чему! Итак, пробежимся по списку инсталлируемых файлов (при помощи sed) и удалим компоненты исключительно для Live CD:

cat > /tmp/sedscript <<END
/casper/d
/libdebian-installer4/d
/os-prober/d
/ubiquity/d
/ubuntu-live/d
/user-setup/d
END
sed -f /tmp/sedscript < ubuntu-rebuild/casper/filesystem.manifest > ubuntu-rebuild/casper/filesystem.manifest-desktop

6 Ремастеринг

Теперь нам надо пересобрать образ файловой системы SquashFS – это займет до получаса...

mksquashfs ubuntu-source/ ubuntu-rebuild/casper/filesystem.squashfs -noappend

Далее обновим контрольную сумму MD5 для подтверждения целостности диска:

(cd ubuntu-rebuild && find . -type f -print0 | xargs -0 md5sum > md5sum.txt)

И наконец, команда mkisofs создат нам сияющеновый ISO-образ:

mkisofs -r -V “My Modified Ubuntu” -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emulboot -boot-load-size 4 -boot-info-table -o newbuntu.iso ubuntu-rebuild

Et voila: Если все прошло «на ура», то вы теперь имеете файл newbuntu.iso, который можно прожечь на CD-R (или, если он больше 700 МБ, на DVD). Но помните, что если образ больше 2 ГБ, у вас будут проблемы с запуском. Если же он меньшего размера, то записывайте его, загружайте и наслаждайтесь!

Время R!

Код написан, функции добавлены, и срок выхода релиза все ближе и ближе...

К концу цикла разработка вступает в суматошный период: бурно разрастается количество отчетов об ошибках. Брайан Мэррей руководит Группой контроля качества Ubuntu и управляет уровнем обратной связи с сообществом: «При полностью открытой системе отчетности об ошибках, принятой в Ubuntu, кажется, что мы получаем больше всего отчетов об ошибках, когда уже сделана финальная версия для более широкого распространения. Однако Desktop CD с его Live-средой обеспечивает людям отличный способ проверки релизов для разработчиков и способствует их вкладу в процесс».

Итак, это ситуация «Уловки-22»: команда Ubuntu хочет иметь отчеты об ошибках, чтобы суперски отполировать окончательный релиз, но получает наибольшее их количество тогда, когда дистрибутив фактически уже выпущен! Однако если налицо проблемы со стабильностью, даты выпуска снимков и окончательного релиза могут быть изменены: «Важнее представить нашим пользователям хорошую работу, чем уложиться в назначенный срок». Так было с Ubuntu 6.04 – для устранения некоторых неприятных проблем со стабильностью команда вынуждена была сдвинуть релиз на два месяца ради дополнительной доводки. Поэтому он вышел под номером 6.06.

Недель за шесть до релиза раздается команда: «Заморозить версии пакетов»: никакие новые версии, как от индивидуальных разработчиков программ, так и существующих пакетов Debian, в дистрибутив больше не добавляются. Так, если вы – сборщик пакета AbiWord версии 2.4.6 для Gutsy, и тут выходит версия 2.5.0, придется отложить ее до следующего выпуска Ubuntu. Разработчики все еще могут досылать исправления ошибок и проблем безопасности, но цель этого этапа – создание конкретной платформы, которую группа может начать стабилизировать.

Примерно месяц спустя в силу вступает команда «Заморозить функции» – с этого момента никакие новые функции, меняющие работу дистрибутива, добавлять нельзя. Как и при заморозке номера версии, это существенно для сохранения целостности дистрибутива: кому нужно, чтобы какой-нибудь разработчик полностью переписал скрипт начальной загрузки накануне выпуска! Если какая-то планируемая функция не готова к этому времени, она переносится на следующий релиз. В редких случаях разработчик может упросить менеджеров Ubuntu сделать исключение из правила, если выгоды, которые оно принесет, перевесят возможности серьезных последствий по стабильности. Разработчик должен четко продемонстрировать, что его/ее новый пакет не повредит другим, зависящим от него пакетам.

Конец не за горами

Далее следуют еще две «заморозки»: художественных работ и «строк». Вторая запрещает изменение текста в программах, а обе вместе они означают, что люди, отвечающие за документацию, могут изготовлять экранные снимки и тексты справок, не опасаясь, что вид дистрибутива внезапно изменится. Через неделю после заморозки строк и за месяц до выхода конечной версии выпускается бета-версия, которая содержит работающие – хотя все еще потенциально нестабильно – реализации всех новшеств дистрибутива. Ubuntu-овщики называют это «функционально-завершенным релизом», подразумевая, что все это пойдет в конечную версию, но нуждается в тестах.

На этом этапе группа исправления ошибок работает на износ, как объясняет Мэррей: «Поскольку близок окончательный релиз, все больше народу берет его [дистрибутив] для прогона, и число сообщений об ошибках может подскочить. Задача здесь – обеспечить быструю сортировку ошибок, определение высокоприоритетных и их устранение».

Помимо технических вопросов, часть сообщества начинает работать над имиджем дистрибутива. Нужно готовить пресс-релизы и стряпать описание релиза с инструкцией по новым функциям, сдобренной экранными снимками. Маркетингом в Ubuntu занимается Кори Бургер: «Команда маркетинга и Canonical обычно беседуют друг с другом незадолго до релиза, чтобы понять, кто что делает. Обычно я звоню одному из маркетологов Canonical и узнаю, чем они занимаются. В Feisty было так, что Canonical занималась пресс-релизом и ответами на запросы прессы (по крайней мере, английской), а сообщество создало множество онлайн-описаний, таких как “Тур по функциям 7.04”».

За неделю до финального релиза команда выгружает сборку RC (релиз-кандидата) дистрибутива: потенциально это окончательный вариант, если в последний момент не найдутся ошибки типа «полный назад». Разработка прекращается; на данном этапе разрешено исправление только критических ошибок. Большинство членов сообщества с нетерпением ждут, надеясь, что их жесткий диск не спалится ни при каких экзотических комбинациях оборудования. Если все хорошо, команда производит окончательную сборку пакетов и ISO-образов дисков, направляет их на зеркала во всем мире и объявляет о новом релизе на сайте Ubuntu.

Тем временем часть разработчиков начинает собирать воедино планы для следующего выпуска Ubuntu. Цикл начинается заново…

Включаемся

Теперь вы получили некоторое представление о процессе разработки Ubuntu; почему бы немного не помочь ему – или любому другому дистрибутиву?

Так как Ubuntu продолжает процветать, проект постоянно ищет новые дарования – и в этом легко принять участие. Не надо быть кодером с большим стажем работы, чтобы помочь дистрибутиву: существует масса других способов влиться в него и добавить свои улучшения. Новый выпуск дистрибутива – это продукт кооперации различных талантов, работающих вместе с одной целью: сделать пригодную к использованию операционную систему. Поэтому, даже если какой-либо из аспектов процесса разработки вам чужд или пугает вас, не бойтесь: можно работать над собственным проектом и больше никуда не соваться.

Как мы видели, решения высокого уровня, определяющие направление развития Ubuntu, принимает Canonical, но подавляющее большинство разработок у всех на глазах. Помощь дистрибутиву сама по себе награда: она дарит вам опыт на будущее. Вот несколько областей, достойных приложения сил (это справедливо и для других дистрибутивов – например, Fedora или OpenSUSE):

• Кодирование Создание пакетов, исправление ошибок и выпуск заплаток безопасности являются основой работ в любом дистрибутиве; хотя они не требуют расширенных знаний в программировании. Полезны базовые знания C/C++ и Bash-скриптинга. Если вы накоротке с командной строкой, редактируете текстовые файлы и собираете программное обеспечение из исходников, вам по зубам изготовление Deb-пакетов Ubuntu; рассмотрите возможность работы с ними в репозитории Universe. Если вы дока в программировании, попытайте удачи в одном из оплачиваемых bounty-проектов Ubuntu.

• Тестирование Скачайте промежуточный вариант дистрибутива и новые пакеты, и если они не работают, отправьте отчет об ошибках на http://bugs.launchpad.net. Ваши отчеты должны быть краткими, но информативными; слова «Не работает, просьба устранить» только раздражают разработчиков, а точное описание ошибки и спецификация вашей системы поможет им локализовать проблему.

• Документирование Одна из проблем Linux – независимо от дистрибутива – это разрозненная документация. Кодеры любят программировать, но их не прельщает перспектива написания руководств пользователя. Вы можете помочь в написании инструкций к еще не документированным программам или улучшить руководства пользователя хорошо известных приложений, имеющих только их черновые наброски. Здесь необходимы знания XML и DocBook.

• Внешний вид Как и руководствами для пользователей, этой частью хакеры иногда пренебрегают, что приводит к уродливым или плохо разработанным интерфейсам. Создайте значки, картинки, обои рабочего стола и макеты интерфейса, чтобы ваш дистрибутив выглядел приятнее и понятнее. Еще лучше, если вы сделаете эту графику с помощью приложений с открытым исходным кодом, вроде GIMP и Inkscape!

• Поддержка Сообщество Ubuntu, как и Gentoo, считается одним из самых гостеприимных и дружелюбных; помогите людям на http://www.ubuntuforums.org, давая советы по основным проблемам пользователей и стараясь, чтобы никто не чувствовал себя чужаком, переключившись на Linux. Пусть вас бесят вопросы вида «пачиМУ линуx Ни раБотаит а» – сохраняйте дружелюбие и доступность, и вы заработаете большой авторитет в сообществе.

• Локализация Как подчеркнул Ладислав в DistroWatch этого месяца, во многих странах, из-за необходимости знать второй язык, значительная часть населения лишена преимуществ пользования компьютерами. Если вы знаете два и более языка, особенно не поддерживаемых проприетарными ОС, ваша помощь может быть неоценима в любой области, особенно по части поддержки, перевода существующей документации и консультаций разработчикам GUI-интерфейсов.

Если вы хотите с головой нырнуть в процесс разработки Ubuntu, надеясь на работу в командах MOTU и Core, как было описано выше, вы должны попасть в списки рассылки (https://lists.ubuntu.com). Предложение идей – хорошая штука, но, как однажды сказал Линус Торвальдс, «Разговоры стоят дешево. Покажите мне код». Если вы способны сделать пакет с продуктом, которого пока нет в репозитории Ubuntu, и изготавливаете стабильные, чистые Deb-файлы, то сможете наладить контакт с разработчиками и включиться в списки. Кроме того, если у вас есть идея для базового дистрибутива Ubuntu и вы способны реализовать ее четким, безопасным и легко проверяемым образом, закодируйте ее и разместите в списках.

Ну что, пишем?

Если программирование не ваш конек, но вы хотите приложить руки к улучшению документации дистрибутива, посетите http://doc.ubuntu.com. При склонности к дизайну и графике, попробуйте создавать иконки, логотипы и фоны рабочего стола на https://wiki.ubuntu.com/Artwork. Независимо от того, что вы хотите делать, страница приглашения в Ubuntu на http://www.ubuntu.com/community/participate предоставит вам ссылки на все виды ресурсов – списки рассылки, страницы wiki и раздел Launchpad. Если вы дружелюбны и подробно опишете свою работу или предложение, то сможете получить полезные отклики и множество путей для дальнейшего продвижения. Или, почему бы не приложить руки к вашему любимому дистрибутиву? Смотрите врезку – там приведены адреса. Удачи! LXF

Ключевые фигуры Ubuntu

Уважаемые люди в команде хакеров Ubuntu:

• Марк Шаттлворт [Mark Shuttleworth] Мультимиллионер, совершивший вылазку в космос; сделал себе состояние, основав Thawte, а теперь он самопровозглашенный «Пожизненный Добрый Диктатор». Он задает общее направление проекта и, как бывший разработчик Debian, также вносит свой вклад в некоторые технические решения.

• Мэтт Циммерман [Matt Zimmerman] Технический директор. Он заботится о коде дистрибутива, удостоверяясь, что процессам разработки и выпуска не препятствуют крупные ошибки, прения разработчиков или чрезмерные запросы функций.

• Брайан Мэррей [Brian Murray] Главный спец по ошибкам и менеджер команды Ubuntu QA, ответственной за то, чтобы «задавить» побольше ошибок в дистрибутиве перед релизом.

• Кори Бургер [Corey Burger] Глава маркетинговой команды; отвечает за контакт с группами СМИ по информации о релизах и обеспечивает, чтобы они излучали положительные волны.

• Трой Соботка [Troy Sobotka] Лидер группы художников. Его команда работает над темами и иконками, чтобы Ubuntu выглядел свежо (ну, то есть, так свежо, как может выглядеть коричневая тема) и гарантирует, что дистрибутив визуально гармоничен.

• Мэтью Ист [Matthew East] Наблюдает за документацией, которая помогает делать дистрибутив более доступным, и обеспечивает переводы на множество языков.