Я заранее прошу прощения за очень долгий и многословный ответ на то, что, по вашему мнению, будет очень простым вопросом. К сожалению, объединение воедино всей операционной системы из множества разных битов в согласованном и унифицированном виде - не совсем тривиальная задача. В настоящее время я работаю над своим собственным дистрибутивом на основе Xen, и пока поделюсь своим опытом (помимо Linux From Scratch):
1 - определитесь с областью применения и придерживайтесь ее
Если у вас есть надежда на фактическое завершение этого проекта, вам нужно написать объяснение того, какой будет ваша новая ОС, и сделать ее после завершения в одном абзаце. Распечатайте это и приклейте к стене прямо перед собой. Прочитайте его, повторяйте его, попрактикуйтесь в том, чтобы говорить это задом наперед, и все, что еще может помочь вам держать его прямо перед любым желанием поддаться характерной ползучести .
2 - выбор менеджера пакетов
Это может быть единственным наиболее важным решением, которое вы примете. Вам необходимо решить, как вы будете поддерживать свою операционную систему в отношении обновлений и новых выпусков, даже если вы являетесь единственным подписчиком. Любой, включая вас, кто использует новую ОС, наверняка найдет необходимость установить то, что не было включено в базовый дистрибутив. Даже если вы выдвигаете ОС для питания киоска, для всех развертываний крайне важно постоянно обновлять себя в разумной и последовательной форме.
В итоге я выбрал apt-rpm, потому что он предлагал гибкость популярного формата пакета .rpm, в то же время используя известное здравомыслие apt, когда дело доходит до зависимостей. Вы можете использовать yum, apt с пакетами .deb, пакеты slackware style .tgz или свой собственный формат.
Решите это быстро, потому что оно будет диктовать, как вы структурируете свою сборку. Следите за зависимостями в каждом компоненте, чтобы потом легко было свернуть пакеты.
3 - Перечитайте область видимости и настройте ядро
Избегайте синдрома kitchen sink при создании ядра. Посмотрите, чего вы хотите достичь, а затем решите, что должно поддерживать ядро. Вам, вероятно, понадобится полная поддержка гаджетов, совместимость с файловыми системами других популярных операционных систем, хуки безопасности, подходящие для людей, которые много просматривают и т. Д. Вам не нужно поддерживать сумасшедшие конфигурации RAID, расширенные цели netfilter и minixfs, но Wi-Fi лучше работать. Вам не нужна поддержка 10GBE или infiniband. Внимательно изучите конфигурацию ядра. Если вы не можете оправдать включение модуля его потенциальным использованием, не проверяйте его.
Старайтесь не вытаскивать из деревьев патчи, если они вам абсолютно не нужны. Время от времени люди приходят с новыми алгоритмами планирования, экспериментальными файловыми системами и т. Д. Очень и очень трудно поддерживать ядро, которое потребляет что-то еще, кроме основной линии.
Конечно, есть исключения. Если выход из дерева - это единственный способ достичь одной из ваших целей, указанных в вашей области. Просто помните, сколько дополнительной работы вы будете выполнять для себя в будущем.
4 - Перечитайте область действия, затем выберите базовый пользовательский край
Как минимум вам понадобится оболочка, основные утилиты и редактор, который работает без оконного менеджера. Обращая внимание на зависимости, вы узнаете, что вам также нужна библиотека C и все, что нужно для работы базовых команд. Как ответил Eli , Linux From Scratch - хороший ресурс для проверки. Я также настоятельно рекомендую взглянуть на LSB ( стандартная база Linux ), это спецификация, в которой перечислены общие пакеты и компоненты, которые «должны» быть включены в любой дистрибутив. Не следуйте LSB как стандарт , сравните его предложения с вашим охватом . Если цель вашей ОС не требует включения чего-либо и от нее ничего не зависит, не включайте ее.
5 - Перечитайте свою сферу и определитесь с оконной системой
Опять же, ссылаясь на синдром everything including the kitchen sink, попытайтесь не поддаваться желанию просто установить стандартную версию KDE или GNOME поверх вашей базовой ОС и назвать ее готовой. Еще одна распространенная ошибка - установить полноценную версию любого из них и работать в обратном направлении, удаляя ненужные вещи. Ради вменяемых зависимостей действительно лучше работать над этим снизу вверх, а не сверху вниз.
Быстро определите набор инструментов пользовательского интерфейса, который будет поддерживать ваш дистрибутив, и запустите его (с поддержкой библиотек). Быстро определяйте последовательность в пользовательском интерфейсе и придерживайтесь ее. Нет ничего более раздражающего, чем 10 открытых окон, которые ведут себя совершенно по-разному с точки зрения управления. Когда я вижу это, я диагностирую ОС с множественным расстройством личности и хочу лечить ее разработчика. Был только шум вокруг Ubuntu, перемещающего элементы управления окном, и они делали это последовательно ... несоответствие было изменением поведения между версиями. Люди очень расстраиваются, если не могут сразу найти кнопку или вынуждены увеличивать пробег мыши.
6 - Перечитайте свою сферу и выберите приложения
Здесь также следует избегать синдрома кухонной раковины. Выбирайте свои приложения не только в зависимости от сферы применения и их популярности, но и от того, насколько легко они будут поддерживаться. Весьма вероятно, что вы будете применять к ним свои собственные патчи (даже такие простые, как мессенджеры, обновляющие мигающий индикатор на панели инструментов).
Важно помнить каждую архитектуру, которую вы хотите поддерживать, при выборе того, что вы хотите включить. Например, если Valgrind - ваш лучший друг, помните, что вы не сможете использовать его для устранения проблем на определенных платформах ARM.
Притворись, что ты - компания и будешь там работать. Ваша компания прошла тест Джоэл ? Рассмотрим также систему непрерывной интеграции, такую как Hudson . Это сэкономит вам массу волос, когда вы прогрессируете.
Когда вы начнете объединять все эти компоненты, вы, естественно, создадите свой собственный SDK. Документируйте это по ходу дела, старайтесь не нарушать его по прихоти (всегда обращайтесь к своей области). Вполне допустимо просто позволить linux be linux, что превращает ваш SDK в более формальные правила, чем что-либо еще.
В моем случае мне посчастливилось работать над чем-то, что разработано строго как серверная ОС. Мне не приходится иметь дело с настольными предостережениями и я не завидую никому, кто это делает.
7 - Дополнительные предложения
Это в случайном порядке, но их заметка может сэкономить вам время:
- Сохранить наборы патчей для каждой строки кода вверх по потоку, который вы изменяете, в пронумерованной последовательности. Примером может быть
00-make-bash-clairvoyant.patch, это позволяет вам поддерживать патчей вместо целых разветвленных хранилищ вышестоящего кода. Вы будете благодарны за это позже.
- Если у компонента есть набор тестов, обязательно добавьте тесты для всего, что вы вводите. Легко просто сказать "отлично, это работает!" и оставьте все как есть, имейте в виду, что вы, вероятно, добавите еще больше позже, что может нарушить то, что вы добавили ранее.
- Используйте любую систему управления версиями, которую используют авторы при загрузке вышестоящего кода. Это значительно упрощает слияние нового кода и освобождает часы от повторного создания патчей.
- Даже если вы считаете, что вышестоящие авторы не будут заинтересованы в ваших изменениях, хотя бы предупредите их о том, что они существуют. Координация очень важна, даже если вы просто узнаете, что добавленная вами функция уже находится в планировании и будет реализована по-другому в будущем.
- Вы можете быть уверены, что вы будете единственным, кто когда-либо будет использовать вашу ОС. Создавайте его так, как будто его будут использовать миллионы, вы никогда не знаете. Такое мышление помогает избежать клуджей.
- Не тяните верхний альфа-код, какой бы ни был соблазн. Red Hat это попробовал, не сработало . Придерживайтесь стабильных выпусков, если вы не исправляете ошибки. Основные исправления ошибок обычно приводят к выпуску новых версий, поэтому убедитесь, что вы смотрите и координируете.
- Помните, что это должно быть весело.
Наконец, осознайте, что развернуть весь дистрибутив с нуля по экспоненте сложнее, чем разветвить существующий дистрибутив и просто добавить то, что, по вашему мнению, ему не хватает. Вам нужно часто вознаграждать себя, загружая свою ОС и фактически используя ее продуктивно. Если вы слишком разочарованы, постоянно запутываетесь или откладываете работу над этим, подумайте над созданием облегченного форка Debian или Ubuntu. Затем вы можете вернуться и скопировать его полностью с нуля. Это ничем не отличается от прототипирования приложения на более простом / быстром языке, прежде чем писать его for real на чем-то более сложном. Если вы хотите пойти по этому пути (сначала), gNewSense предлагает утилиты для развертывания вашей собственной ОС прямо из Ubuntu. Обратите внимание, что по умолчанию их утилиты удаляют любые несвободные биты (включая двоичные двоичные объекты ядра) из получившегося дистрибутива.
Я настоятельно рекомендую пройти полностью с нуля (сначала), потому что опыт, который вы получите, намного больше, чем создание еще одного разветвления. Однако также важно, чтобы вы на самом деле завершили ваш проект. Best субъективно, делай то, что работает для тебя.
Удачи в вашем проекте, до встречи на distrowatch.