Это копия, сохраненная 31 июля 2016 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Что такое LFS?
LFS - это книга, повествующая о том, как собрать себе дистрибутив Linux с нуля. То есть вообще с нуля, собирая пакет за пакетом, прописывая вручную конфиги. Очевидно, что уровень красноглазия запредельно высок даже относительно генты.
Зачем нужен LFS?
Во первых, сборка LFS позволяет детально изучить работу GNU\Linux очень детально, сами вдумайтесь, каждый пакет устанавливается и конфигурируется не пакетным менеджером, а лично тобой. По завершению установки LFS, ты будешь смотреть на Гентушников, как на говно.
Существует две книги, содержащие в себе инструкцию по сборке.
LFS - Непосредственно сама процедура установки базовой системы. На выходе вы получите абсолютно голую консоль, которую уже потом можно будет руками допилить до уровня дестктопа при помощи...
BLFS - Книга содержит инструкции по дальнейшему обкату системы. DE/WM, браузер, всякие либы - все тут.
Что же нужно для сборки LFS? Разумеется требуется хост система, с которой будет производится сборка и установка пакетов. Подойдет любой Linux дистрибутив, хоть загрузочная флешка Убунты, хоть Арч.
Ссылка на книгу: http://linuxfromscratch.org/lfs/
он Gentoo осилить не может
БАМП
Я уже осилил, няша. Там ничего сложного нет, если разобраться. Рутинно, долго, но не сложно. В книге каждый шаг расписан детально
Скриншот тебе ничего не даст, ибо вывод uname, к примеру, не показывет дистрибутив. Что не работает - по началу очень долго пердолился с различными библиотеками, но в книге каждому пакету прописаны зависимости, а так же рекомендованные пакеты, которые потом можно при компиляции подключить. Начинается пердолинг сразу после сборки LFS, нужно будет установить сертификаты, OpenSSL, Nettle, GnuTLS, чтобы wget нормально работал. Затем с телефончиком в руках читаешь команды и ручками набиваешь их в консоль. Без bash-completion я бы не выжил. Ну а вообще там работает все, что ты установишь, в книге BLFS есть разделы по установке вообще всего, что надо, для интереса полистай. А, ну и еще помню момент, там установка иксов идет по принципу - скачиваете файл со списком пакетов и хэшей, потом вгетом закачиваются все пакеты скопом, используя этот лист, потом баш скриптами устанавливаются(принцип сборки у всей этой груды иксовских пакетов один, нет смысла каждый еонпелать отдельно). Ну и вот, а у меня голая консоль и телефон в руках, а на компе кроме LFS и дриснятки нет ничего. С флешки грузиться лень, перезагружать вообще не хочу. Ну и набивал эти скрипты вручную. http://www.linuxfromscratch.org/blfs/view/svn/x/x7lib.html
Да, можно, и я даже пытался так сделать. Первый раз он мне угробил систему, второй раз - получилось. Но да, система превратится в арч. А теперь самое главное - пакеты, установленные через make install НЕ ВОСПРИНИМАЮТСЯ пакетными менеджерами. То есть любой менеджер(пакман, apt-get etc.), банально перезапишет тебе всю систему пакетами из реп. НО! Можно использовать пакетный менеджер без непосредственно установки пакетов из репозиториев, а собственные пакеты запаковывать в .deb, .rpm, .pkg.xz, чтобы ими было удобнее управлять
Сто лет не видел, и уже забыл!
Именно, это не нужно. Если тебе требуется пакетный менеджер - используй дистрибутив.
Врети!!!
Теперь вместо генту будут лфс форсить?
> собирал целый год LFS
> внезапно понял, что твои знания применимы только для сборки LFS
> от отчаяния создаешь тред в /s/ - всем похуй
У меня вопрос. Что ты за хуй? Иван какой-то, блядь, до этого ещё Дима. Кто следующий, Рома? Вася?
А кто ты? Представься и прикрепи к посту фотографию паспорта.
Дима няша, не трогай его
Няша, не забивай на тред.
Шапку может допили, куда-то в гитхаб вылаживай.
Фак может добавь, не хватает сравнения с обычными дистрами, хотя и так все довольно ясно.
Вот незнаю бля, может вместо рача поставлю, рач не понравился инитрамсом, еще и версия ядра старая там.
Но ЛФС чисто для того чтобы лучше разбиратся в генте ставить буду, да и сети подрочить надо, ато нубяра в этом.
Сам же ЛФС сам по себе ну хуй знает как пользовать, не удобно же обновлять систему и говно чистить.
голое ядро
Объясни ОП, в чем конкретно можно разобраться собрав LFS? Какой такой уникальный опыт? Например если уже можешь установить арч одной левой, а правой генту. Ну и вообще с компиляцией и с консолькой дружишь.
Ты ознакомишься с уймой полезных утилит, поймешь структуру дистрибутива, поймешь как работает пакетный менеджер, как ставить пакет из сорцов руками.
А для юзания подойдет Gentoo GNU/Linux:
>>1741259 (OP)
>>1741259 (OP)
Как же это долго и монотонно. Я не осилил кароч.
Голая консоль лишь после сборки базовой системы. Кстати сейчас снес LFS и хочу заново собрать, но уже с systemd.
>>1741263
Дело в том, что установка LFS подразумевает не просто сборку пакетов, а еще и их конфигурирование вручную. Разумеется бызовые утилиты, вроде sed или tar, конфигурировать не надо, но вот к примеру раздел из книги о systemd. http://www.linuxfromscratch.org/blfs/view/systemd/general/systemd.html. В арче или генте все пакеты конфигурируются автоматически, здесь же лишь инструкция с пояснениями и твои руки. Это дает огромный багаж знаний об устройстве системы и взаимодействии пакетов друг с другом. Если ты поймешь, как это все работает, то сможешь разобраться с любой ошибкой.
А вообще this >>1741269
Каким блядь образом тебе лфс поможет в сети? Я понимаю что Дима ебнутый, но блядь чтобы настолько. Нужно уметь в сети - занимайся сетями, а не ненужный лфс дрочи.
Ты имеешь ввиду Developer версию? Если да, то я только на них и сижу. Причем не только в LFS, я всегда включаю тестинг, если есть такая возможность в любом дистрибутиве. И как-то так выходит, что баги обходят меня стороной. Тот же арч за пол года на testing ни разу не сломался и работает как часы. Генту на "~amd64" тоже.
Ну вот, думаю и LFS буду этот накатывать.
Как будто что-то плохое.
Какие преимущества вообще перед любым дистром?
ОП, ты напомнил мне о моём первом линуксе - Шлака 8 . Я там всё тоже ставил configure && make && make install
И даже думал порой заняться LFS , но с семейной жизнью не всегда на генту времени хватает, лал. Но на сперму уже не вернусь.
>lfs
Есть ещё что-то более пердольное? Собрать конпелятор, на нем потом ведро, и т.д..
https://www.youtube.com/channel/UCdX4uJUwSFwiY3XBvu-F_-Q
Годнота для обучения, всяко лудше компилирования еще одногодистра
Да, только без маркетинга кому надо это ядро?
Комьюнити само по себе не появится, он его хоть в гитхаб выложил?
И чому на бубунте сидит?
Вообще нихуя не понял что посмотрел.
Вон оно что.
Пилил бы активнее и взлетело немношк, хоть некоторые компоненты могли войти в GNU/Linux или BSD, вангую он и там что-то коммитил.
10 лет слишком долго, лучше бы свободную прошивку для сенсорных устройств с нативными приложениями бы сделал.
Ну интересная штука вышла, и не дублирует ни линукс ни виндовс, для локальной машины, годно для узкого спектра задач.
Вот только Я не понял что именно можно делать с такой осью? Почитаю там еще фак...
>что именно можно делать с такой осью
Разговаривать с Богом!
Для обучения очень годная штука ибо нет того зоопарка архитектур как в линупсе, все в нулевом кольце, дохуя еще задач не решенных короче
Рассуждения типичного жадного ниггера
Не скажу за современные, но те линуксы которые я устанавливал было слишком долго обновлять. На достаточно большой системе правка конфигов под все обновления у меня занимала полдня. Удалял их все по одной единственной причине - они переставали запускаться после обновления. Заметил, что чем дольше не обновлялся, тем выше шанс что после массивной обновы уже не встанет. У самосборных линуксов в этом плане ситуация мне тогда показалась еще печальней.
Из того что ожидал от линукса - программа после деинсталляции должна удалять за собой библиотеки и конфиги(по желанию пользователя). Она этого не делает с конфигами, совсем не делает. С либами часто случаются висячие пакеты-либы которые никому не принадлежат, но непонятно можно ли их удалить или они используются. Удалял всегда по мануалу пакетного манагера, но иногда они почему-то оставляли неиспользуемые либы.
Надеялся что никсы будут чище винды с ее реестром. В винде раньше было принято держать файловые конфиги в директории с программой. Сейчас пошли по пути никсов, с их вечными конфигами в папке пользователя.
Последний раз устанавливал арч-линукс. Приманили меня таки KISS-ом. В 2013 или 14. Конечно, после обновы он перестал запускаться. Я не был удивлен. И, естественно, пытаться исправлять я ничего не стал. Хватит
Арч линукс сильно изменился с тех пор, можно без задней мысли обновлять ничего не правя, как и генту.
А долго ещё? Когда готово будет?
Тоже правда, просто в лфс с нуля все поднимать надо, интересно же, и расписано подробно вроде
-pipe добавляй к gcc
>Пошла конпеляция. Не буду комментировать сборку каждого пакета, скажу лишь, что это долго и дохрена
-march=native не забудь.
А в качестве временной директории используй tmpfs
Довольно большое количество пакетов необходимо собрать. binutils необходим любой системе, это же базовый пакет. Systemd будет скомпелирован уже непосредственно при сборке LFS, сейчас я подготавливаю временную среду. Это примерно вот столько
Обновляется редко
Это к разработчикам. Я не особо разбираюсь в данной теме, но если ради musl придется перепиливать пол книги, то это долго
binutils собирается примерно 40 секунд. В книге есть свои система измерения - SBU. Это время компиляции binutils. Дальше в книге каждому пакету приписывается значение SBU. Например 4.0 SBU, 0.5 SBU и так далее
Ну я брал время только make, на генте вроде учитывается время конфигурирования и загрузки, нет? Лучше скачай binutils, и собери непосредственно через configure и make
http://linuxfromscratch.org/lfs/view/systemd/chapter05/binutils-pass1.html
Вот по этой инструкции, для чистоты эксперимента
Ну Я вместе с конфигом засеку
Можно безболезненно заменить glibc на что-либо другое? ся книга заточена на glibc
Я же собираю LFS в познавательных целях, решил вот накатить версию с systemd. Да и к тому же пока я не слышал еще ни одного вразумительного аргумента против systemd, одно кряканье
Раз ты зашел в этот тред, то тоже стал невольным участником сборки LFS в прямом эфире. Устраивайся поудобнее
Жирное, убогое говно, которое тянет свои грязные лапы к хорошим вещам.
А потом оно сжирает их.
Конец.
Это не аргументация, а по прежнему лишь твое субъективное мнение. В каком месте оно убогое? К каким хорошим вещам оно тянет лапы и как оно их сжирает? Конкретнее, пожалуйста
Этого баттхёрта в сети хватает, ты можешь сам нагуглить. Вот тебе смешная гифочка с кратким описанием моих слов. Поттеринг либо переписывает, либо портит, иного не дано. Грустно всё это.
Можно на начальном этапе.
В книге на выбор есть инструкции по сборке Gnome 3, XFCE, LXDE, LXQt, KDE 4/5. У меня на хост системе гном
Сама компилежка заняла 1 минуту 45 секунд.
Гента
Иди вон в спермотред потолсти
Ну Я его не взял потому что штеуд современнее, хоть и предупреждали что в многопотоке сосну.
Звонить, писать смс, смотреть видео, читать новости и конечно же ПЕРДОЛИТЬСЯ(гугли про джейлбрейк). Странный вопрос
Пилю свой пакетный менеджер. В планах преобразование пакетов дебиана в мои, чтобы не париться над поддержкой репы. Также в планах прекомпиляция пакетов, т.е. менеджер гибридный - и исходники, и бинарные пакеты. Я стараюсь следовать unix-way, и точнее говоря, это будут два разных менеджера пакетов. Но над бинарным работать пока даже не начинал, сейчас установка идёт с помощью make install.
Сорцы пока не пилю, через несколько недель или месяцев выложу. Но будут регулярные скрины.
На Руби. Такое нужно писать на высокоуровневом языке, я считаю (также см. Portage).
На Си может будет небольшая часть - виртуальная файловая система с использованием ptrace, чтобы отслеживать системные вызовы во время выполнения make install, перенаправлять в виртуальную файловую систему и составлять список устанавливаемых файлов. Существующие решения не совсем подходят:
fakeroot - использует LD_PRELOAD, не подходит в случае статической линковки
fakeroot-ng - развитие заброшено, и не работает только под линуксом и/или GNU (а я не ограничиваюсь одним ядром и юзерлендом)
>а я не ограничиваюсь одним ядром и юзерлендом
Сейчас по крайней мере все пакеты LFS успешно компилируются под FreeBSD, если установить из портов devel/gmake
>На Си может будет небольшая часть - виртуальная файловая система с использованием ptrace
Но на первое время думаю накатить себе Btrfs под линем и ZFS под FreeBSD, там это реализовано
И почему ты дурак, пердолик?
А ты хорош, только пакетному менеджеру выхлопов не хватает. Это, конечно, красивенько и минималистично, но LFS не убунту. Пускай будет детально показан процесс сборки и установки. Будет похоже на генту, но суть у этих дистрибутивов примерно та же. И еще - это, конечно, очень смело и трудозатратно, но если проектом будут интересоваться не только полтора анонимуса, возможно. Смотри, знаешь дистрибутив фунту? У них там можно скачать stage3 под различные архитектуры процессоров, например AMD Piledriver, AMD Buldozzer и так далее. В будущем можно создать свой репозиторий с пакетами, скомпилированными для каждой архитектуры. Да, много, да, дохуя, но будет довольно интересно. Если заинтересует, могу написать фейкопочту(у меня Piledriver).
Хуя ты погроммист. завидую.
>пакетному менеджеру выхлопов не хватает. Пускай будет детально показан процесс сборки и установки
Это само собой. Иногда нужны были логи, тупо записывал их в фиксированный файл. Потом сделаю вывод на постоянной основе, просто сейчас лень разбираться с асинхронным перенаправлением вывода дочернего процесса в Руби.
>знаешь дистрибутив фунту? У них там можно скачать stage3 под различные архитектуры процессоров, например AMD Piledriver, AMD Buldozzer и так далее. В будущем можно создать свой репозиторий с пакетами, скомпилированными для каждой архитектуры
Я не планирую существование удалённых репозиториев изначально. Репозиторий лежит локально. Это одна из фич моего ПМ (объясню позже, когда придумаю, почему это фича, а пока исхожу из минимализма и простоты реализации). И уже исходя из такой архитектуры я буду рассматривать возможность установки бинарных пакетов, скомпилированных на другой машине. Но я верю, что это возможно, так что удалённые репозитории бинарных пакетов будут обязательно.
>Если заинтересует, могу написать фейкопочту(у меня Piledriver).
Пиши в тред или сюда: c4173LX5496ANUStrbX0IvnPUNCTUMcX/wom
Я не стал писать одну большую программу, которая делала бы всё. Вместо это я разбил её на несколько маленьких программ, каждая из которых выполняет какое-то простейшее действие.
Итак, первая программа - загрузчик исходных кодов. Загружает tar-архивы по URL, кеширует их для предотвращеняи повторной загрузки и распаковывает в указанную директорию, с возможностью обрезания первых элементов путей файлов (т.к. зачастую tar-архив содержит одну-единственную директорию) и указания поддиректории.
Рассмотрим работу по шагам (см. скриншот):
1) Директория исходных кодов и кеш пусты
2) Запускаем загрузчик, указывая директории исходных кодов и кэша. Для каждого файла в пакете он вызывает команду wget. По выводу этой команды в stderr видим, что загрузка произошла
3) Видим, что архив распакован, а в кеше он появился под уникальным именем. Соответствие некоторого URL и имени кешированного файла хранится в стандартной Unix DB (считайте, что это BerkeleyDB версии 1 или 2, key-value хранидище)
4) Повторно звпускаем загрузчик. Вывода wget не видно, потому что он распаковывает кешированный архив, пропуская загрузку. Т.е. он не меняет timestamp'ы файлов, повторный вызов make для заново распакованных исходников не вызовет перекомпиляцию всего, так что исходники можно смело удалять после компиляции, если что потом распаковать повторно (конечно, директорию сборки надо сохранить)
5) Ещё раз убеждаемся, что ничего нового в кеше не появилось
6) Ну и посмотрите на формат файла пакета. В комментариях, надеюсь, не нуждается
Дальнейшему шагу (сборке) без разницы, как были получены исходники. Если мы, например, захотим хранить исходники всех пакетов в одном большом git-репозитории, то надобность в загрузчике отпадёт, но код следующей программы от этого не поменяется.
Также эта программа может быть полезна сама по себе, независимо от моего менеджера пакетов. Например, тем, кто собирает LFS. Пишите файл пакета, добавляйте shell-скрипт для сборки, который полагается на то, что исходники уже лежат в src.
Думаю, дам ссылку на гитхаб и перестану закрашивать всё в скринах уже скоро, как только доведу эту утилиту до ума.
Я не стал писать одну большую программу, которая делала бы всё. Вместо это я разбил её на несколько маленьких программ, каждая из которых выполняет какое-то простейшее действие.
Итак, первая программа - загрузчик исходных кодов. Загружает tar-архивы по URL, кеширует их для предотвращеняи повторной загрузки и распаковывает в указанную директорию, с возможностью обрезания первых элементов путей файлов (т.к. зачастую tar-архив содержит одну-единственную директорию) и указания поддиректории.
Рассмотрим работу по шагам (см. скриншот):
1) Директория исходных кодов и кеш пусты
2) Запускаем загрузчик, указывая директории исходных кодов и кэша. Для каждого файла в пакете он вызывает команду wget. По выводу этой команды в stderr видим, что загрузка произошла
3) Видим, что архив распакован, а в кеше он появился под уникальным именем. Соответствие некоторого URL и имени кешированного файла хранится в стандартной Unix DB (считайте, что это BerkeleyDB версии 1 или 2, key-value хранидище)
4) Повторно звпускаем загрузчик. Вывода wget не видно, потому что он распаковывает кешированный архив, пропуская загрузку. Т.е. он не меняет timestamp'ы файлов, повторный вызов make для заново распакованных исходников не вызовет перекомпиляцию всего, так что исходники можно смело удалять после компиляции, если что потом распаковать повторно (конечно, директорию сборки надо сохранить)
5) Ещё раз убеждаемся, что ничего нового в кеше не появилось
6) Ну и посмотрите на формат файла пакета. В комментариях, надеюсь, не нуждается
Дальнейшему шагу (сборке) без разницы, как были получены исходники. Если мы, например, захотим хранить исходники всех пакетов в одном большом git-репозитории, то надобность в загрузчике отпадёт, но код следующей программы от этого не поменяется.
Также эта программа может быть полезна сама по себе, независимо от моего менеджера пакетов. Например, тем, кто собирает LFS. Пишите файл пакета, добавляйте shell-скрипт для сборки, который полагается на то, что исходники уже лежат в src.
Думаю, дам ссылку на гитхаб и перестану закрашивать всё в скринах уже скоро, как только доведу эту утилиту до ума.
1. В чем принципиальное отличие от бсд портов (оно больше похоже на PKGBUILD, но давайте помнить мвои корни)?
2. Зачем нужна отдельная бд для вот этого:
>Соответствие некоторого URL и имени кешированного файла хранится в стандартной Unix DB
У тебя в любом случае, в сценариях сборки будут ссылки на архивы и чексуммы, зачем лишние сущности?
3. Смена имен тарболлов на хуй пойми какие uuid, бессмысленно и контрпродуктивно. Создание геморроя своими силами на пустом месте. Если опасаешься за нейм клэшинг - не опасайся, либо храни исходники непосредственно в директориях портов, или добавляй префиксы с именами пакетов.
4. JSON (хоть не хмл, и то хорошо). Ты пишешь свою софтину на ЖС? Если так, вопросов больше нет.
Дай угадаю: ты студент-погромист, изучающий скалабле энд робуст энтерпрайз солюшенс, у которого чешутся руки что-то написать, но нет не то, что четкого плана, но даже приблизительного представления о том, что это и как должно выглядеть. Если так штырит с идеи создания своей пакетной системы, посмотри на CRUX, самое простое, что может быть, но оно работает. Запили что-то такого же уровня, с учетом всех недостатков, впиливай недостающие фичи, да, потом окажется, что ты написал говно, которое надо рерайтить фром скрэтч, а иначе никак.
>1. В чем принципиальное отличие от бсд портов (оно больше похоже на PKGBUILD, но давайте помнить мвои корни)?
Это порты, я полностью согласен
>2. Зачем нужна отдельная бд? У тебя в любом случае, в сценариях сборки будут ссылки на архивы и чексуммы, зачем лишние сущности?
Разделение ответственности, single responsibility principle
>3. Если опасаешься за нейм клэшинг - не опасайся, либо храни исходники непосредственно в директориях портов, или добавляй префиксы с именами пакетов.
Пройденный этап. Ушёл от этого по озвученной пунктом выше причине
>4. JSON
А ЧТО ЕЩЁ? Это идеальный вариант на данный момент
>Дай угадаю: ты студент-погромист
Не угадал
>нет не то, что четкого плана, но даже приблизительного представления о том, что это и как должно выглядеть
Я уже сказал, что буду комментировать по ходу дела, когда появится время. Это некрасивой провокацией ты не заставишь меня всё бросить, уже сейчас дать исходники и начать объясняться.
>посмотри на CRUX
Смотрел, изучал формат пакетов. Минималистично, но совершенно непортабельно и нерасширяемо
>потом окажется, что ты написал говно
Ну ты-то мастер проектирования? Сразу идеальный код пишешь?
>которое надо рерайтить фром скрэтч
Я итак скоро этим займусь. То, что есть сейчас - Proof of Concept.
Сколько ты уже занимаешься программированием и какие книги конкретно по линуксу ты читал?
>Сколько ты уже занимаешься программированием
8 лет, если с самого начала смотреть, а зарабатываю этим года 2
>какие книги конкретно по линуксу ты читал?
LFS, CLFS. Я больше по операционкам в целом угораю, нежели по линуксу. Таненбаума читал, много чего ещё по ядрам. Писал своё монолитное ядро на Си, но там дошёл только до консоли и реализации FAT16.
>Это некрасивой провокацией ты не заставишь меня всё бросить, уже сейчас дать исходники и начать объясняться.
Да вы, батенька, параноик.
>Минималистично, но совершенно непортабельно и нерасширяемо
Куда ты собрался портировать и расширять? Мне просто интересно.
>Ну ты-то мастер проектирования? Сразу идеальный код пишешь?
причем здесь я? Нет, и я тебе именно это и пытался объяснить. Начинать надо с простого, расширять по мере надобности, да, рано или поздно ты упрешься в фундаментальный косяк своей системы, который исправит только переписывание с нуля, но ты полюбому в него упрешься и будешь переписывать, но так ты хотя бы будешь знать, как писать, чтобы было заебись. А пытаясь создать с нуля идеальную, максимально расширяемую и обобщенную систему, ты не создашь вообще нихуя.
>А ЧТО ЕЩЁ?
Смотря на чем ты пишешь. Скорее всего это какой-то скриптовый язык, его родной формат и бери. Питон? Используй питоновские словари. Лисп? S-expressions. Сконвертировать всегда сможешь, если понадобится. Как по мне, здесь и json избыточен, особенно на фоне глобальной berkdb.
>Да вы, батенька, параноик.
Я не понимаю, что ты хочешь мне доказать.
>Куда ты собрался портировать и расширять? Мне просто интересно.
Как я уже написал, я хочу добиться возможности компилировать любую ОС тем же способом, каким компилируется LFS, без изменений в исходном коде, и с минимальной конфигурацией. Поэтому я не использую один большой build-скрипт для каждого пакета, т.е. платформо-специфичные изменения были бы размазаны по нему, а сейчас всё локализовано в конфигурации.
>Начинать надо с простого, расширять по мере надобности
Я итак с простого начал. Как я сказал, я исхожу из минимализма. У меня нет ни удалённых репозиториев, ни разрешения зависимостей (пока, потому что я ещё не знаю, как лучше их реализовать в моём случае).
>рано или поздно ты упрешься в фундаментальный косяк своей системы, который исправит только переписывание с нуля, но ты полюбому в него упрешься и будешь переписывать, но так ты хотя бы будешь знать, как писать, чтобы было заебись. А пытаясь создать с нуля идеальную, максимально расширяемую и обобщенную систему, ты не создашь вообще нихуя.
Ещё раз - у меня сейчас Proof of Concept. Я итак планирую вскоре переписать всё с нуля.
>Смотря на чем ты пишешь. Скорее всего это какой-то скриптовый язык, его родной формат и бери. Питон? Используй питоновские словари. Лисп? S-expressions. Сконвертировать всегда сможешь, если понадобится. Как по мне, здесь и json избыточен
Я пишу на Ruby, у него в стандартной библиотеке есть парсер JSON. Вообще, JSON формат весьма универсальный. Не понимаю претензии.
>особенно на фоне глобальной berkdb
Её реализация вообще в libc есть по стандарту.
Я пользуюсь самыми простыми, доступными буквально ВЕЗДЕ инструментами. Поэтому выбрал JSON и DBM.
>В LFS есть wget-list, который позволяет скачивать все пакеты зараз.
А как ты относишься к моей идее загрузчика исходных кодов? Ты мог бы поддерживать репозиторий LFS и BLFS, чтобы пакеты были тех же версий, что и в книге. Репозиторий - простой git-репозиторий. Оставь тут почту, я тебе скину ссылку.
>Как я уже написал, я хочу добиться возможности компилировать любую ОС тем же способом, каким компилируется LFS
То есть, если интерпретировать сказанное тобой буквально, ты хочешь добиться того, чтобы для сборки, к примеру NetBSD или FreeBSD, вместо синхронизации дерева исходников и последующего запуска make, дающего результат в виде готового к загрузке с него образа, пришлось бы проходить через все пункты из LFS с выкачиванием и сборкой пакетов по отдельности (где их еще взять-то, отдельные пакеты из base той же фряхи)? Какой-то троллейбусный парк из хлебопекарного цеха.
>Proof of Concept
В PoC, как правило, в приоритетах не универсальность и дополнительная ебля с неродными форматами типа json отвлекает от более важных вещей, таких как
>разрешения зависимостей
от самой основы основ.
>для сборки, к примеру NetBSD или FreeBSD, вместо синхронизации дерева исходников и последующего запуска make, дающего результат в виде готового к загрузке с него образа
Эта операция платформо-специфична. Попробуй собрать FreeBSD из-под GNU/Linux
>пришлось бы проходить через все пункты из LFS с выкачиванием и сборкой пакетов по отдельности
В итоге у меня сборка будет осуществляться одной командой
>где их еще взять-то, отдельные пакеты из base той же фряхи
Создать репозиторий для моей системы сборки
>В PoC, как правило, в приоритетах не универсальность и дополнительная ебля с неродными форматами типа json
Ещё раз - чем он не родной? Он есть в стандартной библиотеке Ruby. Если ты скомпилировал Ruby, который, кстати, имеет очень мало зависимостей (из рантаймовых вообще только libc вроде), то ты может просто установить мою систему сборки с помощью gem install foobar
>разрешения зависимостей
>от самой основы основ.
Пользователи Slakeware сейчас с ухмылкой посмотрели на тебя
Я вижу, ты считаешь, что я неэффективно трачу время? В любом случае, изначально моя идея возникла исключительно как автоматизация сборки LFS, так что по крайней мере трачу время более эффективно, чем если бы я собирал LFS руками
>Я пишу на Ruby
Впрочем, да, я начинаю понимать, почему мне непонятны твои идеи, ибо я никогда не пойму людей, использующих язык, на котором можно писать "2.months.from_now()", этот мутировавший под воздействием радиации перл. Не языкосрача ради, что уж, каждый дрочит как хочет.
>Впрочем, да, я начинаю понимать, почему мне непонятны твои идеи, ибо я никогда не пойму людей, использующих язык, на котором можно писать "2.months.from_now()", этот мутировавший под воздействием радиации перл. Не языкосрача ради, что уж, каждый дрочит как хочет.
А я вот не понимаю. Как синтаксис языка влияет на архитектуру продукта? При разработке архитектуры я исходил исключительно из unix-way, опыта в системном программировании и сборки систем GNU и BSD.
Ты не понимаешь моих идей потому, что я ещё не всё до конца озвучил. Вон выше ты (?) задал вопрос
>для сборки, к примеру NetBSD или FreeBSD, вместо синхронизации дерева исходников и последующего запуска make, дающего результат в виде готового к загрузке с него образа
Видимо, я недостаточно ясно объяснил, что моя цель - кроссплатформенная сборка. Я хочу детерминировать зависимости так, что при попытке сборки, к примеру, GNU/Linux из-под FreeBSD есть два варианта:
1. Тулза говорит, что каких-то пакетов в базовой системе не хватает и предлагает их установить
2. Сборка происходит успешно
Это то, чего невозможно добиться ни с помощью autotools (хотя создавались они для этого), ни как-либо иначе.
Зачем мне это нужно - другой вопрос. Есть такая штука, как L4re. Это ОС на основе микроядра L4, позволяющая запускать паравиртуализованные (изменённые) ядра других систем в пространстве пользователя. Такие системы сами могут служить хостом для других портированных на L4 ядер. Это что-то вроде универсального API виртуализации. Сейчас из таких ядер есть только L4Linux, он регулярно обновляется. Также возможно портирование других ядер на L4.
Знаешь систему Whonix? Это Debian с двумя виртуальными машинами (обе тоже Debian). Одна из них является роутером, пропускающим весь траффик через Tor+VPN. Другая является рабочим столом, сеть которой проброшена через этот роутер. Это даёт гарантию, что никаким образом данные о железе или IP-адресе пользователя не утекут.
Но тут есть несколько слабых мест - виртуализация процессора (почитай тред про Inter ME в /crypt/), возможные ошибки и закладки в коде VirtualBox. Если реализовать тоже самое на основе микроядра и паравиртуализации, то слабых мест в системе не останется (кроме пользователя, конечно).
>Впрочем, да, я начинаю понимать, почему мне непонятны твои идеи, ибо я никогда не пойму людей, использующих язык, на котором можно писать "2.months.from_now()", этот мутировавший под воздействием радиации перл. Не языкосрача ради, что уж, каждый дрочит как хочет.
А я вот не понимаю. Как синтаксис языка влияет на архитектуру продукта? При разработке архитектуры я исходил исключительно из unix-way, опыта в системном программировании и сборки систем GNU и BSD.
Ты не понимаешь моих идей потому, что я ещё не всё до конца озвучил. Вон выше ты (?) задал вопрос
>для сборки, к примеру NetBSD или FreeBSD, вместо синхронизации дерева исходников и последующего запуска make, дающего результат в виде готового к загрузке с него образа
Видимо, я недостаточно ясно объяснил, что моя цель - кроссплатформенная сборка. Я хочу детерминировать зависимости так, что при попытке сборки, к примеру, GNU/Linux из-под FreeBSD есть два варианта:
1. Тулза говорит, что каких-то пакетов в базовой системе не хватает и предлагает их установить
2. Сборка происходит успешно
Это то, чего невозможно добиться ни с помощью autotools (хотя создавались они для этого), ни как-либо иначе.
Зачем мне это нужно - другой вопрос. Есть такая штука, как L4re. Это ОС на основе микроядра L4, позволяющая запускать паравиртуализованные (изменённые) ядра других систем в пространстве пользователя. Такие системы сами могут служить хостом для других портированных на L4 ядер. Это что-то вроде универсального API виртуализации. Сейчас из таких ядер есть только L4Linux, он регулярно обновляется. Также возможно портирование других ядер на L4.
Знаешь систему Whonix? Это Debian с двумя виртуальными машинами (обе тоже Debian). Одна из них является роутером, пропускающим весь траффик через Tor+VPN. Другая является рабочим столом, сеть которой проброшена через этот роутер. Это даёт гарантию, что никаким образом данные о железе или IP-адресе пользователя не утекут.
Но тут есть несколько слабых мест - виртуализация процессора (почитай тред про Inter ME в /crypt/), возможные ошибки и закладки в коде VirtualBox. Если реализовать тоже самое на основе микроядра и паравиртуализации, то слабых мест в системе не останется (кроме пользователя, конечно).
>Пользователи Slakeware сейчас с ухмылкой посмотрели на тебя
И где твой слакварь сейчас? Нет, для обучения хорош, мой первый линукс, кстати. Но не для использования в серьезных целях.
>Эта операция платформо-специфична. Попробуй собрать FreeBSD из-под GNU/Linux
У FreeBSD, как и у любой самостоятельной системы есть своя система сборки. Системы "GNU/Linux" не существует как таковой, а у каждого ее дистрибутива есть своя система сборки и унифицировать это все просто невозможно и бессмысленно
>моя идея возникла исключительно как автоматизация сборки LFS
Короче, я понял, ты хочешь свой сурс бейсед дистр. Так бы и говорил. Когда-то я тоже пытался превратить в конфетку CRUX, прикручивать pkgsrc к слаквари, но всегда возвращался к Gentoo, так как в ней уже учли все что только можно, и как бы не тупил иногда портаж, он хотя бы остается юзабельным и еще никогда не подводил.
>У FreeBSD, как и у любой самостоятельной системы есть своя система сборки. Системы "GNU/Linux" не существует как таковой, а у каждого ее дистрибутива есть своя система сборки и унифицировать это все просто невозможно и бессмысленно
Я не пытаюсь унифицировать всё. Я хочу дать возможность описывать это с помощью конфигурации, а не кодом.
>Как синтаксис языка влияет на архитектуру продукта?
Тут не в синтаксисе дело, а в семантике. Ну не сторонник я ООП вообще, а в динамике особенно.
>Есть такая штука, как L4re. Это ОС на основе микроядра L4, позволяющая запускать паравиртуализованные (изменённые) ядра других систем в пространстве пользователя.
Виртуализация это, конечно, хорошо, но при чем здесь автоматизация сборки? Паравиртуализация, это же типа Xen? Для него ведь достаточно иметь патченное ядро, или я не прав?
>ошибки и закладки в коде VirtualBox
Чем их qemu не устроил?
>Чем их qemu не устроил?
Там VirtualBox open-source edition, конечно. Но VBox - это сотни тысяч строк кода. Кто проводит его аудит? Один меинтейнер просматривает мельком, и всё.
>Паравиртуализация, это же типа Xen?
Да. Когда-то рассматривал и Xen как основу своей ОС, но с ним не сложилось. К томуже он умирает вроде. Да и он не микроядерный, там тоже много кода, полный аудит которого очень сложно провести.
А вот у микроядер всё очень хорошо с аудитом. Есть даже полностью формально верифицированное микроядро - seL4.
>Тут не в синтаксисе дело, а в семантике. Ну не сторонник я ООП вообще, а в динамике особенно.
Всё равно на архитектуру продукта не влияет.
>Виртуализация это, конечно, хорошо, но при чем здесь автоматизация сборки?
Хочу в будущем присоединить систему полуавтоматизированного аудита кода. Чтобы код, в котором есть участок, аудит которого не произвели минимум N доверенных мейнтейнеров, физически не мог попасть на твою машину.
Ну и удобство. Я считаю, что для моих целей не подходит ни одна существующая система сборки.
Enlightenment
>Файл слишком большой
>фотка с мобилы
>слишком большая
Ну тогда без пруфов
>С какого бы DE начать?
Cinnamon
>Заебался страшно
Так что на счёт моей тулзы? Дай почту, покажу репу и объясню, как пользоваться
А, сорян, занят был так, что не видел.
>синамон
В книге нет инструкций по этой ДЕ. Крыса, гном, плазма, LXDE и даже убожественное LXQt. Нет, ну я могу, конечно, нагуглить инструкцию или даже самому накатить(и где я вам список пакетов найду), но синамон мне НЕ НРАВИТСЯ. Крыса тоже, но она собирается очень быстро, наверное, с неё и начну. По поводу сорцов, пиши, почту к посту вроде приклеил
>Да и он не микроядерный, там тоже много кода, полный аудит которого очень сложно провести.
>А вот у микроядер всё очень хорошо с аудитом.
А что насчет OpenBSD? Там ведь даже модулей нет, не то что микроядерности. И тем не менее, могут в аудит. Олсо, у них же были планы по поводу своего гипервизора, слышно что-нибудь об этом?
>А что насчет OpenBSD? Там ведь даже модулей нет, не то что микроядерности. И тем не менее, могут в аудит.
Высокое качество кода и хорошая политика безопасности.
>Олсо, у них же были планы по поводу своего гипервизора, слышно что-нибудь об этом?
Впервые слышу. Было бы круто.
Порт OpenBSD на L4 существовал в виде дипломной работы студента Берлинского университета, где разрабатывают L4re, но был заброшен в 2011. Но всегда можно продолжить, рабочая версия есть, просто надо обновить её с OpenBSD 4.9 до 5.6.
OpenBSD благодаря своей безопасности и качественному коду хорошо бы подошёл на роль роутера в озвученном мной варианте аналога Whonix.
>Впервые слышу. Было бы круто.
Гугл выдает новости прошлогодней давности, проект в зачаточном состоянии, судя по всему, если вообще жив. Поживем, увидим.
http://undeadly.org/cgi?action=article&sid=20150831183826
>обновить её с OpenBSD 4.9 до 5.6
До 5.9 тогда, чего уж там.
Олсо, я может быть, чего-то не понимаю, но чем KVM хуже подходит для
>аналога Whonix
?
>Олсо, я может быть, чего-то не понимаю, но чем KVM хуже подходит для
>аналога Whonix
Тем, что это реализовано в ядре Линукс, которое есть 10 миллионов строк говнокода, проверяемого одним единственным человеком (и мб компаниями для себя).
Ну так поставь права доступа как были, в чем проблема?
Ну суть в том, что я смотрел, что делает PKGBUILD и делал так же. Он там просто распаковывал deb файл и копировал нужные файлы в нужные директории. Видимо, я где-то напортачил и что-то не так скопировал/распаковал
Ну у тебя вроде не совсем убитая система. Смотри внимательно, какие команды выполнял, и в каком месте накосячил.
Ну и не на правах systemd-срача, но ставить в LFS что-то большое и сложное, что не знаешь как работает - это не LFS-way.
Там есть сборочки на uclibc/musl? Пойду гуглить.
У меня будет система Gentoo musl, так что лфс должен будет содержать только либы и сам софт непосредственно. Хочу там легковесную шель вместо баша, и все в таком духе, никаких тебе питонов и скриптопараши.
>Там есть сборочки на uclibc/musl? Пойду гуглить.
>гуголь хрень выдает.
Кажется, это та область, где надо не просто пердолиться, а пердолиться САМОМУ, В ПОЛНОМ ОДИНОЧЕСТВЕ.
Я вот на основе Busybox вчера пытался собрать. Вроде популярная штука, в тысячах моделей роутеров используется, в OpenWRT. А хуй, интернет так и не смог настроить.
Но ведь мюсл самая молодежная либа? А юслибси что? Мне кажется без этого с лфс мало пользы, а так он будет уделывать генту, хоть и собирать все из под нее буду.
>Но ведь мюсл самая молодежная либа?
Я про то, что туториалов типа LFS скорее всего нет. Придётся делать всё самому, по аналогии, и ошибки исправлять тоже самостоятельно.
>А юслибси что?
Минимальную систему с uClibc ты можешь собрать автоматически с помощью Buildroot, очень легко. Но ведь ты хочешь всё ручками сделать? В прринципе, можешь изучить скрипты сборки Buildroot'а
Бляха, Я вот подумал у меня мюсл будет со всем необходимым, пакеты уже собраны, их же просто скопировать остается? А лфс для понимания того, что надо копировать прочитать?
Мне все кроме инструментов разработчика скопировать надо будет.
>Я вот подумал у меня мюсл будет со всем необходимым, пакеты уже собраны, их же просто скопировать остается?
Не совсем. При сборке на хост-системе пакет может слинковаться с чем-нибудь из неё, тогда он не будет работать в собираемой системе. Поэтому в LFS сначала собирается минимальная система, потому делается chroot в неё и далее собирается основная система.
>А лфс для понимания того, что надо копировать прочитать?
LFS надо прочитать для понимания, какие костыли притходится использовать из-за маразматичности кросс-компиляции в GCC, который нихуя не может получить на вход SYSROOT и собирать в его контексте.
- GRUB не может установить себя в произвольный раздел, нужно извращаться с монтированием и chroot'ом
- GCC не может в нормальную кросс-компиляцию, нужно извращаться с chroot'ом и сборкой тулчейнов
- проект GNU не может в нормальное коммьюнити, надо извратиться, чтобы найти какую-то инфу на сайтах проектов
- проект GNU не может в Git (ну это болезнь многих старых открытых проектов, в том числе FreeBSD, OpenBSD)
> GRUB не может установить себя в произвольный раздел, нужно извращаться с монтированием и chroot'ом
2016 на дворе, у пасанов уже уефи
efistub с помощью efibootmgr манька блядь.
Так говоришь как будто гейос или сперма может установить себя на произвольный раздел.
https://wiki.gentoo.org/wiki/Efibootmgr
>The efibootmgr application interacts with the UEFI firmware on the system, and is a popular tool to manipulate the EFI settings in order to create and manage boot entries that are capable of booting Linux (or other operating systems).
Т.е. это требует наличия материнской платы, поддерживающей UEFI? Тогда не понимаю, как это поможет тем, у кого такой нет.
>Так говоришь как будто гейос или сперма может установить себя на произвольный раздел.
При чём здесь ОС? Мы говорим о загрузчике.
Где-то есть книжка учебная про свою ось с нуля. Олдовая довольно таки. Можешь её попробовать.
Собери LFS musl, она хоть неебически быстрая будет. И тот-же жму/линукс ток пердольней чутка.
Заодно и гайд пиши.
Ну если у тебя такая плата то пора менять, Зен кеннонлейк завезут, потом кеннонлейк.
Можно будет просто скопировать готовые бинари в раздел и собрать еще одно ядро?
Можно. Более того, есть чудо-скрипт, автоматически собирающий лфс, т.е. ты команды не ручками вбиваешь в консольку, а просто запускаешь этот скрипт и вуаля. Да и в целом, шибко полезного там мало, в этой книге. Наиболее полезны части в начале и конце. В середине только мясо вида "1. Распакуйте этот .tar.bz; 2. маке инстолл этот .тар.бз; 3. удалите распакованное." Ни о каком понимании речи не идёт, вбивай команды как в книжке (точь-в-точь, это важно) и будет тебе счастье.
Ой, всё ясно с тобой. Давай выкинем на помойку несколько десятков миллионов компов в мире только потому, что они не UEFI. Заканчивай с подобными заявлениями.
>>1754371
>Да и в целом, шибко полезного там мало, в этой книге. Наиболее полезны части в начале и конце. В середине только мясо вида "1. Распакуйте этот .tar.bz; 2. маке инстолл этот .тар.бз; 3. удалите распакованное." Ни о каком понимании речи не идёт, вбивай команды как в книжке (точь-в-точь, это важно) и будет тебе счастье.
В целом верно сказано. Только в конце, когда уже идёт настройка системы, прописывание конфигов, что-то даётся для понимания.
Особенно меня взбесила такая штука, как пакет lfs-bootscripts. Самое важное для понимания - сервисы, которые инициализируют виртуальные файловые системы, отвечают за сеть, за диски - они засунули в один пакет и просто предгалают установить.
Ну там ещё в начале есть объяснения для чего нужен /proc и подобные директории, пара абзацев полезной инфы. Алсо, lfs-bootscripts я что-то не припомню, это какая версия? Я вроде 6.6 собирал.
Ты только сейчас понял, что он поехавший.
>Алсо, lfs-bootscripts я что-то не припомню, это какая версия? Я вроде 6.6 собирал.
Версия 7.9
http://www.linuxfromscratch.org/lfs/view/stable/chapter07/bootscripts.html
По моей ссылке в конце страницы есть Short Descriptions, этого достаточно, чтобы понять, что они делают много важной инициализации, в которой пользователю LFS не мешало бы разобраться самостоятельно. Конечно, кому надо, тот и сам поймёт. Но вообще само существование этого пакета как-то не соответствует философии LFS.
Надо же, чо сделали. А впрочем, нахер эти линуксы ваши. Заебался я, честно говоря.
Годная система, генту хуже тем что пакетный менеджер написаный на 2-3 питонах, потому питоны там лучше не трогать.
Хорошо.
Но сам принцип управления пакетами охуенный.
>генту хуже тем что пакетный менеджер написаный на 2-3 питонах, потому питоны там лучше не трогать
И на что это влияет? Ты с курсе, что в систему можно поставить несколько версий одной программы?
Не знаю, как в питоне, но в руби когда ставишь гем с помощью /some/path/to/ruby/bin/gem install somegem, то он создаёт исполняемые файлы, в которых прописан путь к интерпретатору как /some/path/to/ruby/bin/ruby
Но даже без этого, можно тупо написать обёртку для портадж, который будет запускать его исполняемые файлы как
>/usr/bin/env -i PATH="/some/path/to/python/bin" portage
Enjoy Unix-way
>>1754382
Отчасти то, что вы говорите - верно, но не надо ограничивать "Linux From Scratch" одной лишь книгой LFS. Она рассказывает, лишь, как установить базовую систему, и рассказывает это довольно подробно. Например в той же части с компилежкой пакетов даются пояснения к каждому параметру, но, разумеется, если устанавливать все по принципу Ctrl+C Ctrl+V, читая лишь жирный шрифт, ничего это вам не даст особо.
Теперь о знаниях и опыте. После того, как вы соберете базовую систему, ее необходимо будет допилить, и для этого если вторая книга - BLFS. Вот там количество получаемых знаний НАМНОГО больше. Например, вам расскажут, как установить сертификаты и зачем они нужны, как установить Linux-PAM и настроить его работу с Shadow и systemd. Как установить иксы, настроить работу устройств, видеодрайверы и еще куча всего. Все это разжевано там максимально подробно. А LFS да, но чего вы еще хотели от установки базовой системы?
ТРИПКОД ОТКЛЕИЛСЯ
Мне кажется, в LFS (я про книгу) не рассматривается вопрос сборки тулчейна. Просто даются инструкции по сборке. Никакого обсуждения, почему надо так делать, какие ещё есть способы, какие подводные камни сборки другим способом. CLFS тоже не продвинулась в этом плане, лишь дала инструкции по кросс-сборке.
Ты мою программу посмотрел? Получилось загузить исходники с её помощью? Что думаешь о поддержке репозитория LFS?
Посмотрел, но как запустить её хотя бы, так и не понял. Ты обещал документацию или хотя бы базовый набор инструкций, и в итоге я имею несколько файлов, с которыми понятия не имею, что делать. О руби знаю только то, что оно существует.
Ну руби я установил, вроде собрал через gem тот файл, нашёл там какой-то rakefile, наверное, это тоже что-то рубиновское. Команда rake послала меня к хуям. В результате вроде собрано, установлено, а что дальше - хз
Лол, да тебе не надо было скачивать репозиторий. Просто набери
>gem install tarloader -v 0.4.0
Я же сказал, что опубликовал программу
Сейчас накачу вместо хакинтоша(под AMD работает крайне хуево) рач или федору, и займусь.
Так, тарлоадер установил. Вижу там -c и -s. Но инструкция все же не помешала бы
Так в README на гитхабе всё написано.
Ты репозиторий linux-from-scratch загрузил? Переходи в директорию любого пакета (например, tools/binutils-2.26-pass1), там набирай
>mkdir src
>tarloader package.json -c ~/tarloader_cache -s src
Можешь поместить в ~/.bashrc
>export TARLOADER_CACHE="$HOME/tarloader_cache"
Чтобы каждый раз не набирать
Это в кэше? Он в src исходники уже распаковал.
Смотри, по моему - клонирование репозитория - лишнее действие. Есть возможность убрать его, чтобы тулза сама закачивала пакет по его названию(по типу остальных пакетных менеджеров). Чтобы итоговая команда выглядела, например, как tarloader -c binutils-pass1. В душе не ебу, как это ты реализуешь, у гитхаба есть возможность работать с репозитоиями напрямую без их клонирования?
>>1751495 (OP)
через ftp к гиту вроде можно подключится.
Алсо а какие подводные в сборке полностью из хостовой системы?
Никаких тогда компиляторов, мейков и прочего всего в таргете...
>Чому не musl в качестве стандартной либы?
Хз, а нахуя он нужен сейчас? У меня с glibc-то не всегда корректно собираются пакеты, после того как я что-нибудь поменяю в сборщике или в конфигурации пакетов. Не хочу сейчас ебаться ещё с нестандартной libc. Потом, как сборщик будет дописан и отлажен, добавлю варианты сборки с musl и с uClibc
>>1754989
>Алсо а какие подводные в сборке полностью из хостовой системы?
GCC - маразматичное говно, слинкует твои бинарники со всем с чем только можно из хостовой системы, и потом в таргете они не запустятся, т.к. нет шаред библиотек. И это только один из подводных камней, там ещё в некоторых пакетах пути забиты прямо в коде, так что может быть нестандартное поведение некоторых пакетов, и вскроется это не сразу.
>Никаких тогда компиляторов, мейков и прочего всего в таргете...
В LFS все промежуточные пакеты устанавливаются в префикс /tools. Потом эта директория просто удаляется.
Ну uclibc вообще как два пальца юзать, берешь и компилируешь, для мюслей иногда надо патчи.
Скоро uclibc++ выйдет, вот годнота-то будет.
>Может в шланга годная кросс-компиляция?
Да, вроде там всё удобно. Но вроде у шланга проблемы с компиляцией ядра линукса и ещё некоторых программ. Я когда-нибудь обязательно попробую собрать минимальную систему шлангом.
У меня сегодня вообще появилась идея собирать свой Busybox-LFS с помощью Tiny C Compiler (от самого Белларда, между прочим), который до сих пор развивается, правда до сих пор бета версия.
>>1754992
>Ну руками все собирать как-то хуй знает...
У меня своя система сборки. Когда-нибудь выложу сюда.
Проблемы такие вроде давно были, поцыки с генту-треда пользовались шлангом с удовольствием, говорили раза в 2 быстрее компилежка.
Это же охуенно! Представь, что на свет появится новый дистр с реально качественной пакетной базой, с непадающими кедами, со своими перделаками и сралками... Анон, ты можешь написать свой идеальный пакетный менеджер. Замутить свой формат пакетов! Анон, свой формат, бля, пакетов!
Будет свой у нас ANONLinux! Го пилить свой дистр!
Так вот мне был подарок DEXP XL240, могли бы вы накатить туда ядро и программы
да хоть бубунту, я знаю вы тут спецы, мне любой линукс накатить
Всмысле любой? Задачи какие? Десктоп? Браузер? офисопараша?
В чем проблема самому накатить?
скачивай rufus для шиндовса, скачивай образ федоры, и накатывай на флейшку уефи\жпт, потом на сам пк установишь.
Ну тут два варианта - либо есть туториал под твою модель, тогда ты и сам справишься, либо туториала нет, тогда едва ли кто-то из присутствующих тут сможет помочь. Мы ж тут не супер кернел-хакеры, только вкатываемся.
Кто такие мокрописечники?
Пердолики - GNU/Linux, BSD пользователи.
Мокрописечники, спермачи, спермоглоты - пользователи шиндовс.
Геи, пидорки, заднеприводные, глиномесы = Пользователи апл Гей ОС.
Не забудь шель на него установить
http://www.nemoux.net/#!demo/zwfdl
Вот для сенсорных устройств
Nemo-UX shell
https://www.youtube.com/watch?v=bsTKwx_VNcU
https://www.youtube.com/watch?v=Uyc2XMm-19o
https://www.youtube.com/watch?v=NBdoX4qsByQ
Weston IVY shell тоже должно подойти, она полегче вроде.
sys-apps/texinfo?
Вот ошибки при сборке:
Can't locate Locale/Messages.pm in @INC (you may need to install the Locale::Messages module) (@INC contains: ../tp/Texinfo/Convert/XSParagraph ../tp/maintain ../tp ../tp ../tp /etc/perl /usr/local/lib/perl5/5.24.0/x86_64-linux-thread-multi /usr/local/lib/perl5/5.24.0 /usr/lib/perl5/vendor_perl/5.24.0/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.24.0 /usr/lib/perl5/5.24.0/x86_64-linux-thread-multi /usr/lib/perl5/5.24.0 .) at ../tp/texi2any line 109.
BEGIN failed--compilation aborted at ../tp/texi2any line 109.
Can't locate Locale/Messages.pm in @INC (you may need to install the Locale::Messages module) (@INC contains: ../tp/Texinfo/Convert/XSParagraph ../tp/maintain ../tp ../tp ../tp /etc/perl /usr/local/lib/perl5/5.24.0/x86_64-linux-thread-multi /usr/local/lib/perl5/5.24.0 /
usr/lib/perl5/vendor_perl/5.24.0/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.24.0 /usr/lib/perl5/5.24.0/x86_64-linux-thread-multi /usr/lib/perl5/5.24.0 .) at ../tp/texi2any line 109.
BEGIN failed--compilation aborted at ../tp/texi2any line 109.
Makefile:1274: recipe for target 'info-stnd.info' failed
Перловский модуль Locale/Messages отсутствует. Скорее всего перл некорректно установлен.
Дима, проснись, ты не в Генту-треде
Я буду пробовать переписать свою систему сборки так, чтобы она использовала UnionFS и собирала пакеты прямо в корень файловой системы. О результатах сообщу.
1. Создаём директорию под корень ФС
>mkdir sysroot
2. Создаём директорию для хранения изменений файловой системы
>mkdir rw
3. Монтируем туда tmpfs. Если этого не сделать, а оставить её простой директорией, не получится создать AuFS из-за циклической зависимости, насколько я понял
>sudo mount -t tmpfs none rw
4. Монтируем AuFS
>sudo mount -t aufs -o br=rw=rw:/=ro none sysroot
5. Чрутимся в корень
>sudo chroot sysroot /bin/sh
Теперь можно вносить любые изменения в корневую файловую систему. Они не будут записаны на диск, в реальный корень, а запишутся в директорию rw
Важное замечание по пункту 3 - конечно, tmpfs, которая лежит в памяти, вряд ли хватит для сборки LFS, да и хотелось бы иметь постоянный образ. Поэтому вместо tmpfs туда можно примонтировать раздел жёсткого диска, где вы храните LFS.
А ещё есть такой вариант - создание образа жёсткого и монтирование его как блочное устройство с помощью losetup. Тоже несложно:
>dd if=/dev/zero of=/image.img bs=4K count=4M # 16 гигабайт
>sudo losetup /dev/loop0 image.img
>sudo install-mbr /dev/loop0 # программа из пакета mbr дебиана
>sudo gparted /dev/loop0 # размечаем образ диска, допустим, один раздел ext4
>sudo mount /dev/loop0p1 rw # rw - директория из прошлого поста, которую мы монтируем к AuFS
мимо-гентушник
>Тред люто доставляет, количество красноглазия в нем зашкаливает
Ты погоди, я ещё не нашёл, как скомпилировать kFreeBSD и портированную под него glibc. То ли ещё будет.
Во-первых, glibc - это единственная libc, в которой предусмотрен слой совместимости для использования на различных ядрах. Во-вторых, это родная libc для большей части софта. В-третьих, она уже портирована на kFreeBSD и Hurd.
Было бы интересно узнать, сколько жрет твоя система на старте без этих ваших браузеров.
>>1756944
Мб какой системный бинд в конфиге указывает на какой несуществующий софт/команду?
Зачем тебе локализованная система? Всё равно остаются надписи на английском, а такая инконсистентность уродлива.
Ты же понимаешь, что системой без пакетного менеджера невозможно пользоваться? LFS не предназначен для того, чтобы его в голом виде использовать в качестве основной системы. Пойдёт что-нибудь не так при установке какого-нибудь пакета, и придётся всю систему с нуля перекомпилировать.
Как вариант, можно после компиляции пакета делать бинарный тарбалл, который потом просто распаковывается в корень. Как отслеживать изменения в файловой системе (до и после установки пакета) я выше описал. Кстати, если делать так при компиляции каждого пакета, то нет риска убить систему, потому что реальная файловая система при чруте в такую среду работает только на чтение.
>>1756951
>Ну и еще огнелис в вайленде ведет себя очень нехорошо. Я привык менять раскладку по альтшифту, а лиса при нажатии альта даже в сочитании с другой клавишей, выкидывает верхнее меню опций и становится неюзабельна, пока куда-нибудь не кликнешь.
У меня в Debian GNU/kFreeBSD такая же фигня
>Пойдёт что-нибудь не так при установке какого-нибудь пакета, и придётся всю систему с нуля перекомпилировать.
Такое происходит лишь при установке очень важных пакетов, их можно пересчитать по пальцам. В прошлый раз такое вышло с Linux-PAM. Больше ты ничем систему и не убьешь, а если и убьешь, то только кривыми руками(как раз как у меня в прошлый раз). Да и из под чрута практически любая проблема решается.
>Ты же понимаешь, что системой без пакетного менеджера невозможно пользоваться? LFS не предназначен для того, чтобы его в голом виде использовать в качестве основной системы.
Разумеется понимаю? Мне теперь удалять LFS? Я не собирал ее, чтобы пользоваться, как основной системой, по моему, это очевидно.
>Зачем тебе локализованная система? Всё равно остаются надписи на английском, а такая инконсистентность уродлива.
На данный момент английская локаль лишь в лисе, все остальные элементы локализованы полностью, по крайней мере в Гноме 3.
>Было бы интересно узнать, сколько жрет твоя система на старте без этих ваших браузеров.
Первый пик - на старте. Ядро монолитное, да и я не особо парился вырубать модули, ИБО ХОТЕЛ ПОБЫСТРЕЕ УЖЕ. Второй - с запущенным гномом.
>Мне теперь удалять LFS?
Ну зачем ты так. Я просто предлагаю варианты, как можно сделать из LFS реально юзабельный дистр. Просто я тут сижу, изобретаю лайфхаки, а единственному человеку в треде кроме меня, кто собирает LFS, это неинтересно. Просто что ты дальше делать будешь? Вернёшься к другому дистру? Установишь в LFS пакетный менеджер другого дистра и превратишь её в другой дистр?
>>1756978
>inb4: Зачем тебе своп, да еще и такой?
Лол, у меня своп 16 Гб - в два раза больше оперативки. Да, был когда-то такой совет, делать в два раза больше, вот я и привык.
Вообще подумываю сделать систему, корень которой будет жить в оперативке, директории с бинарными пакетами будут монтироваться в корень с помощью UnionFS GoboLinux, и которую не нужно будет выключать (отмонтировал все разделы и можно тупо вырубать питание) Plan 9
Сперва я хочу допилить ЛФС до юзабельного состояния. То есть до полноценного десктопа. Затем займусь твоим пакетным менеджером. Я пока понял, как с его помощью выкачивать сорцы, но имхо ПОКА ЧТО намного проще делать все по книге. Реально. Мне интересна идея пакетного менеджера для ЛФС. То есть без автоматизации решения зависимостей, чтобы тебе все равно приходилось читать книгу, ибо это - вся суть ЛФС.
В принципе согласен, ты правильно мыслишь. Я и сам пробую разные варианты реализации пакетного менеджера и понимаю, что они все переусложнены. Начинаю понимать пользователей слаки, у которой ПМ не разрешает зависимости.
Сейчас хотя бы удалось значительно его упростить благодаря тому, что я использую AuFS. Избавился от всяких префиксов и т.п., устанавливаю прямо в корень.
>Я пока понял, как с его помощью выкачивать сорцы, но имхо ПОКА ЧТО намного проще делать все по книге.
Я подумаю, как сделать скачивалку удобней, чем wget-list.
Ещё раз:
Cоздаём AuFS, в которую примонтирован корень только на чтение и пустая директория на запись.
Делаем chroot в AuFS.
Все изменения ФС записываются в специальную директорию, а не в реальную корневую ФС.
>Пока анон выше допиливает свой пакетный менеджер
Я забил и всё удалил. Велосипеды не нужны. Излишняя сложность не нужна. Я понял, что можно обходиться простым скриптом сборки.
>Так же планирую сделать stage3 чистого LFS, естественно, тоже без конфигов, чтобы перескачить КОНПЕЛЯЦИЮ
Вот это очень годно. Только я бы делал не один большой архив файловой системы, а по бинарному архиву на каждый пакет.
>Короче, какой пакетный менеджер выбрать?
Я бы отказался от стороннего пакетного менеджера. Просто распаковывай бинарный архив вкорень.
> Аноним (Microsoft Windows 10: Chromium based) 23/06/16 Чтв 20:54:43 №1760244
Ты так и не спалил ФИШКУ
> Ну, разумеется, выпилив оттуда все зависимости и конфиги, чтобы жизнь медом не казалась и приходилось все равно читать книгу.
Ебанутый?
> Просто распаковывай бинарный архив вкорень.
Так, а зависимости? Что делать если похеришь зависимости?
Суть LFS в знании почти каждого файла в своей системе. Читать книгу необязательно, ты можешь собирать LFS совершенно иным способом, нежели представленным в книге. Но тогда тебе придётся самостоятельно решать проблемы с порядком установки пакетов (читай, с зависимостями). Книга нужна как введение в сборку своей собственной системы.
>>1760825
>Так, а зависимости? Что делать если похеришь зависимости?
Если ты следуешь книге, то этого не произойдёт. Так чётко указано, какие пакеты должны быть в системе для установки некоего пакета.
> Так чётко указано, какие пакеты должны быть в системе для установки некоего пакета.
Они могут конфликтовать. Могут бажить. Так что делать в таком случае?
Решать конфликт, решать баг.
>Они могут конфликтовать. Могут бажить. Так что делать в таком случае?
Не могут, потому что по книге LFS полностью собирается и тестируется система пере выпуском новой версии книги.
У меня был вариант - брать за основу репозиторий какого-нибудь существующего пакетного менеджера. Проблема в том, что зачастую в сторонних репах программы идут с патчами, эти патчи тоже придётся брать вместе с пакетом. Также там зачастую есть патчи, которые меняют пути, забитые в коде, на специфичные для данного дистрибутива.
Поэтому я предлагал сделать репу на основе LFS, добавляя туда другие пакеты по мере необходимости.
Для рашкодебилов есть перевод? Я ебал читать такое на английском.
Ладно, не обоссывайте, сам за минуту нагуглил.
Да, обычно в книге отдельно указано, что пакет надо собирать именно в одном потоке. Как пример помню вроде с -j1 надо собирать sqlite. Но это в BLFS, в LFS у меня все собиралось нормально
Это копия, сохраненная 31 июля 2016 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.