Linux дистр с нуля

Ну уж если и LFS вам не то, то тогда можно начать с написания своего ядра.

Это вам к Танненбауму, книга "Операционные системы <...>", 3-е издание. В ядре и системном окружении разберетесь очень хорошо (ИМХО).

о клева, anonymousOS звучит!!!

Как и посоветовали вначале стоит начать с Танненбаума. Потом собирать LFS или любое другое Source Based. Поюзайте получившийся дистр определенное время собирайте для него пакеты, накладывайте патчи, компилируйте ядро. Потом вы поймете нужно ли вам это все или нет. Затем стоит перевести весь софт в пакеты и думать об установщике. НО ИМХО лучше сделать репозиторий для _распространенного_ дистрибутива, если у вас есть идеи которые действительно нужны OpenSource. В репозиторий будете выкладывать свои наработки. Если будет что - то стоящее народ потянется. Я дорабатывал несколько дистров >> в одиночку это практически нереально. Нереально поддерживать с 0 созданый дистр в актуальном состоянии.

попробуй собрать 0install-based дистрибутив.

0install : сайт

http://0install.net/matrix.html http://0install.net/walkthrough.html

0install -- перспективный пакетный менеджер, который-всех-порвёт, как только появится достаточная критическая масса приложений в его пакетах.

Для начала можно взять ту же Генту с paludis'ом (и автоматической сборкой из SVN), написать и оттестировать рецепты пакетов.

> В репозиторий будете выкладывать свои наработки. Если будет что - то стоящее народ потянется. Я дорабатывал несколько дистров >> в одиночку это практически нереально

в Gentoo есть оверлеи, в которых очень просто поддерживать "свой дистрибутив", со своими патчами. Можно оттолкнуться от этого.

> Если будет что - то стоящее народ потянется.

может, (и-не)анонимные эксперты ЛОРа распишут свои ожидания от "мой ИДЕАЛЬНЫЙ дистрибутив", чтобы топикстартеру было наглядней?

то есть, грубо говоря, ставишь софт из SVN, пытаешься сконвертировать ебилды в формат пакетов 0install, тестишь в своём локальном оверлее, расшариваешь оверлей в интернет, создаешь сайт, сообщество PoupkineDistr :)

в идеале будет совсем круто если получится написать автоматический конвертор в формат пакетов 0install из например Paludis (который умеет ставить софт из SVN,git)

кроме Генты с её "рецептами сборки" в ебилдах для portage или в paludis можно посмотреть порты FreeBSD, пакмана в Арче, вот эту ересь в GoboLinux http://gobolinux.org/websvn/file.php?repname=recipes&path=%2Frevisions%2F...

сам GoboLinux можно не смотреть -- идея сделать не Linux Hierarchy Standard - дистрибутив, IMHO, дурная, а все прелести Gobo вроде "одновременной установке нескольких версий" (как слоты в Генте) с лихвой перекрываются 0install-ом.

ещё есть интересный проект Logic File System http://en.wikipedia.org/wiki/Logic_File_System

или какая-то LispFS, чтобы манифесты-пакеты приложений, зависимости, инструкции по сборке в дистрибутиве описывались функционально, правилами, которые все вычислялись бы лениво и кешировались бы.

Где-то видел описание дистрибутива в котором пакеты хранятся в такой ФС, ссылку не помню :(

http://www.irisa.fr/LIS/home_html?set_language=en&cl=en

> Хочется собрать все с нуля, разобраться досканально во всем этом.

почитай про TruBSD, как раз студент в качестве курсовой собирал дистрибутив =)

сделай тогда что-нибудь оригинальное, типа linux-дистрибутив с bsd- или plan9port- юзерлендом (:

Чтож вполне даже опишу: Это Debian Stable дополненный некошерными закрытыми дровами для видеокарт, со свежим ядром > 2.6.23.X ( возможность выбора стандартного и свежего ядра должна быть ), плюс обновленный Gnome и KDE + темы к ним, и напоследок обновления наиболее часто используемого софта.

>Беглый поиск по google дал лишь ссылки на LFS (Linux From Starch), но это не то

Объясните, почему не то? Вот исходники, а вот книга рецептов, как из них собрать.. Другой ЛФС быть не может, так как архитектура одна и та же.. только вариации в сборке, какие то пакеты можно исключить, что то добавить, но в общем то о чём Вы говорите, это как раз LFS. Может вы просто не поняли, чего вы хотите?

Почитайте, из русскоязычных ресурсов я знаю наиболее полный lfs.kiev.ua там есть человек, Сергей Каминский, он занимается скриптами автосборки, отвечает там на форуме.

Задача создания своего Linux-дистрибутива состоит из нескольких частей:

1) сборка машинерии для компиляции (binutils, gcc, glibc).

Поскольку начинать придется все равно с какой-то системы, необходимо разработать процедуру сборки такой машинерии таким образом, чтобы изменения в исходной системе (в пределах разумного) не влияли на результат. Для x86, x86_64 и ppc, наиболее продвинутый и технически обоснованный из таких стабильных рецептов находится на сайте http://www.diy-linux.org/reference-build/ . Однако, новичкам следует вначале ознакомиться с LFS.

Еще более совершенный (но пока, по мнению автора, сырованый) способ сборки: http://www.diy-linux.org/reference-build/temptools2.html (использовать вместо http://www.diy-linux.org/reference-build/temptools.html в оригинальном методе сборки). Преимущества нового метода:

* он дает, в отличие от старого, честную поддержку 32-битных приложений на 64-битной системе

* дает возможность собрать 64-битную систему, начиная с 32-битной

* избегает ошибок, происходящих от несовместимости некоторых версий glibc и binutils

На CLFS (и на lfs.kiev.ua) смотреть НЕ НАДО - они учат обезьяньим привычкам (установка CC, CFLAGS, build, host, target и подобных переменных для каждого пакета в отдельности вместо использования файла config.site, который делает это для всех пакетов сразу и позволяет избежать командных строк длиной с простыню). Кроме того, у CLFS есть ошибки в первых же шагах: они устанавливают новую версию file (якобы для того, чтобы binutils собрались, даже если на хосте старая версия) и устанавливают ее в /cross-tools, хотя binutils явным образом вызывает /usr/bin/file, сводя их работу на нет.

2) сборка остальных пакетов.

Здесь есть три скользких момента: автоматизация сборки, "обязательные несогласия" с разработчиками, и создание бинарных пакетов. Первый и последний пункты в контексте создания своего дистрибутива нигде не документированы (jhalfs - не то: они просто извлекают инструкции из книги LFS в bash-скрипт). Похоже, сборщики LFS не используют менеджеры пакетов, см. http://wiki.linuxfromscratch.org/lfs/ticket/2073 (именно по этой причине реально работает только подход "it's all in my head").

Насчет "обязательных несогласий" можно смотреть в spec-файлы от RedHat (http://cvs.fedoraproject.org/viewcvs/devel/) и файлы debian/rules от debian'а (сохраняем diff.gz со страницы типа http://packages.qa.debian.org/mc и смотрим в mc). Большие общие патчи - это, как правило, те, которые реализуют "обязательные" на сегодняшний день возможности (например, поддержку UTF-8), которые официальные разработчики по каким-либо причинам принять отказываются. Slackware таких патчей не содержит и поэтому из коробки там многое не работает (например, запись CD с русскими буквами в именах файлов в локали UTF-8, да так, чтобы это еще и из Windows можно было прочитать). В LFS такие патчи есть, но далеко не все.

По этим двум частям (сборка машинерии и пакетов) я готов предоставить консультации на русском языке с использованием E-Mail, Jabber или IP-телефонии. Контактную информацию см. в профиле.

3) распространение пакетов

т.е. создание репозитариев. Эта часть работы не документирована как следует даже в контексте существующих дистрибутивов.

4) создание сообщества разработчиков и грамотных пользователей и отслеживание их пожеланий и сообщений об ошибках

Без этого шага с таким трудом созданный почти-дистрибутив гарантированно остается глючной пионерской поделкой, которая только притворяется, что работает, и то только на компьютере создателя. Документация по этому шагу частично доступна на курсах маркетинга, но от ее неправильного применения появляются вещи типа Ubuntu, где разработчики заявляют "пакет уже оттестирован", когда на самом деле он совсем не работает, так как тупые пользователи неработоспособность не считают ошибкой (пример: http://bugs.debian.org/374997).

Следует отметить, что попытка реализации всех этих пунктов одновременно без опыта поддержки пакетов в других дистрибутивах всегда заканчивается неудачно. Надо решать задачу постепенно, и в качестве первого этапа, действительно, взять и собрать LFS (английскую версию, т.к. за работоспособность и качество других версий я не отвечаю, а разработчиком официального LFS LiveCD являюсь) в точности по книжке. Потом собрать BLFS и посмотреть на DIY. Потом уже прикручивать менеджер пакетов и делать все остальное. Такой постепенный подход позволяет на каждом этапе иметь заведомо работающую систему, и знать, какое именно маленькое изменение сделало из работающей системы неработающую, и тем самым значительно упрощает поиск ошибок.

Топикстартеру:

В любом случае, если соберётесь делать новый дистрибутив, за ним должна стоять какая-то ИДЕЯ. Посмотрите на DistroWatch, сколько там разных дистрибутивов Линукса? уже больше 1000. Зачем столько?

Зачем нужен новый ещё один?

Если будет ИДЕЯ, у него будут шансы не затеряться и найти сторонников, создать сообщество.

http://www.linux.org.ru/view-message.jsp?msgid=2406675&page=10#2409168

>AEP
>На CLFS (и на lfs.kiev.ua) смотреть НЕ НАДО - они учат обезьяньим привычкам (установка CC, CFLAGS, build, host, target и подобных переменных для каждого пакета в отдельности

В скриптах автосборки эти переменные стоят в начале скрипта, а сборка компонентов реализована как функция, далее через пакетный менеджер, например слакварный. То есть описана функция, и выставлены переменные, далее идёт список пакетов и их версий. По-моему умно. Или мы о разном?
Я внимательно смотрел эти скрипты, автосборки, и даже пробовал.

Иван.

>ЗПохоже, сборщики LFS не используют менеджеры пакетов, см. http://wiki.linuxfromscratch.org/lfs/ticket/2073 (именно по этой причине реально работает только подход "it's all in my head").

Надо понимать что книжка ЛФС не про пакеты, это сборник советов как собрать систему. Пакетный менеджер, скрипты сборки, каждый может прикручивать сам, как хочет. К теме LFS это уже не будет иметь отношения, это совсем другое. LFS это чистый путь, рецепт сборки, не более. Естественно рутинной работы надо избегать, и прикручивать пакетный менеджер, например от Archlinux или, здесь советовали, 0install

поставь lfs на мобилку или роутер. будет самое оно :)

Я задумывался. Потом посчитал затраты, геморрой и с тех пор сижу на Генте.

> Надо понимать что книжка ЛФС не про пакеты, это сборник советов как собрать систему.

Согласен. Тем не менее, в списках рассылки разработчиков неоднократно высказывалась мысль о необходимости подготовки инструкций по сборке к дружбе с менеджером пакетов общего вида. В частности:

* перечисление всех конфигурационных файлов (т.е., грубо говоря, тех файлов, которые могут измениться после установки пакета в результате действий по его настройке)

* указание, как ставить пакет в каталог (в большинстве случаев - make DESTDIR=something install)

> в списках рассылки разработчиков неоднократно высказывалась мысль о необходимости подготовки инструкций по сборке к дружбе с менеджером пакетов общего вида. В частности:

> * перечисление всех конфигурационных файлов

> * указание, как ставить пакет в каталог (в большинстве случаев - make DESTDIR=something install)

это интересно. А можно ли сделать "мета"-пакетный менеджер, "выделить" специфику дистрибутива в какие-то конфиги, и одним пакетным менеджером (который будет или иметь универсальный формат пакетов на все дистры, вроде 0install, pacman или понимать .deb, тот же portage, rpm) и выдавать установленные бинарники и конфиги "в стиле" конкретного дистрибутива?

То есть такой навороченный пакетный менеджер к LFS, который берёт исходники из SVN, исходники или бинарники из репозитория другого дистра, и выдаёт "в стиле" конкретного дистрибутива?

При этом часть пакетов может стоять "в стиле rpm" и считать, что оно стоит в Fedore, часть пакетов -- считать, что система -- родной Дебиан :)

Отвязаться от файлов и конкретной структуры пакетов на весь дистр. Конкретную структуру файлов выдавать по запросу, подсовывая sandbox, вроде chroot'а. Формат структуры файлов выделить в конфиги такого пакетного менеджера, подключать несколько форматов/раскладов, характерных для дистрибутива.

И да, не забудь, еще прикрутить интерфейс к Гипертекстовому Фидонету.

:))

> А можно ли сделать "мета"-пакетный менеджер...

> При этом часть пакетов может стоять "в стиле rpm" и считать, что оно стоит в Fedore, часть пакетов -- считать, что система -- родной Дебиан :)

Это не работает. Т.е., например, если взять часть Гнома из RedHat, а часть - из Debian, они не смогут договориться про расположение схем GConf. Еще некоторые пакеты забирают в себя названия (или, что еще хуже, числовые идентификаторы) групп на этапе компиляции.

Т.е. параметры сборки придется править в любом случае.

> договориться про расположение схем GConf

у каждого в своём sandbox'е. То есть, ФС со стороны приложений в пакете выглядит так, как скажет пакетный менеджер.

> Еще некоторые пакеты забирают в себя названия (или, что еще хуже, числовые идентификаторы) групп на этапе компиляции.

каких групп? А если вместо ФС -- память, адресуемая по содержимому и трансляция разных путей ФС в эту память?

> Т.е. параметры сборки придется править в любом случае.

в смысле, как бы не получился sandbox каждого пакета с зависимостями и дистрибутивными-зависимостями слишком толстый, и неотличимый от дистрибутива целиком в chroot'е ?

тогда да, идея не сработает. Вообще смысл идеи -- "чужие" пакетные менеджеры как плагины.

> Т.е. параметры сборки придется править в любом случае.

напрашиваются continuations для хранения дистро-зависимой специфики и прочих настроек, которые могут скешироваться.