Внутри Arch Linux - Методы Arch

Подробности

Создано 13.10.2013 00:46

Будь проще, дурень (Keep It Simple, Stupid, или KISS): именно такая философия лежит в основе подхода Arch Linux к созданию дистрибутива. В соответствии с этим получилась довольно минималистская и легковесная базовая система, которая является для пользователей стартовой точкой для индивидуальной настройки и добавления пакетов.

Arch не пытается ничего за вас решать; он просто говорит: «вот вам основа, а теперь валяйте, создавайте систему Linux, которая вам нужна». Подобным же образом, команда Arch стремится по возможности избежать выпуска заплат вышележащих программ. Некоторые дистрибутивы берут оригинальный код для программы, слой за слоем добавляют заплатки, и конечный результат разительно отличается от исходной версии разработчика. И это не только добавляет сложности (ибо необходимо синхронизировать все заплатки), но и частенько затрудняет возможность сообщить об ошибках на фоне исходной версии.

И хотя Arch уделяет колоссальное внимание простоте, это все же не делает его дружелюбным к пользователю автоматически. Вы не найдете большого числа специфических для дистрибутива мастеров настройки или инструментов конфигурации в Arch; их здесь считают дополнительными абстрактными и не особо нужными уровнями. Вместо этого вам предлагается взять ответственность на себя и начать исследовать Linux в его практически чистом виде с помощью инструментов, имеющихся почти в каждом дистрибутиве. Слегка изменим старую сентенцию, часто применявшуюся к Slackware: «Используйте Ubuntu — и вы изучите Ubuntu. Используйте Red Hat —и вы изучите Red Hat. Используйте Arch — и вы изучите Linux».

Кто тут главный?

Итак, у вас есть дистрибутив, который отличается минимализмом и по большей части отсутствием заплаток, поощряет вашу исследовательскую жилку и признает, что он довольно труден в освоении. Поскольку Arch не ставит перед собой целей вселенского масштаба (например, потеснить Microsoft на рабочем столе или стать серверной платформой номер один), его разработка довольно децентрализована. Аллан Мак-Рей [Allan McRae], член основной команды Arch, сказал нам: «Среди разработчиков Arch нет настоящей иерархии, хотя те, кто дольше всех занимается разработкой и внес наибольший вклад, стремятся к тому, чтобы их голос звучал громче других».

Однако как быть с принятием важных решений, способных сильно изменить структуру дистрибутива? «Решения в Arch в основном принимаются при отсутствии возражений. Мы полагаем, что тот, кто занимается некой частью дистрибутива, лучше всего в этой части разбирается, и прислушиваемся к его советам. Если надо принять более общее решение, то возникает множество вопросов, на которые надо ответить, чтобы остальные разработчики остались удовлетворены ответами».

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

Большинство из оставшихся разработчиков Arch перешли на systemd— в обсуждениях в списке рассылки все пришли к общему мнению, что с технической точки зрения это решение наилучшее. «Изменение произошло благодаря снятию возражений», сказал Мак-Рей, и именно этот технический подход оценки преимуществ столь приветствуют многие сторонники Arch. Важные решения принимаются очень осторожно, и только после того, как всеми будут взвешены все за и против нового предложения.