Тут нада чота умное напейсать! Шоб сказал, как отрезал! Но чота ничо не приходит вголову, сцуко (( :D
Продолжаем собирать ебучий LFS. читать дальшеЯ честно гря уже заебался, но не потому, что это сложно, а потому что думаешь бля, сегодня уже закончишь, а хер там, продвигаешься на чуть-чуть всего, а я уже хотел бы прихвастнуть перед коллегами новым LFSом. Почему так долго? Ну, например, собираешь какой-нибудь ебучий пакет. Запускаешь на нём тесты (прилагаемые к пакету) Тесты валятся с ошибкой. Может это хуйня, а может и нет. Если хуйня, можно продолжать, а если что серьёзное, может получиться так, что дальше что-нибудь не соберётся и всё равно придётся возвращаться обратно.
В пятницу я немного дособрал и остановился перед пакетом systemd. Пакеты нужно собирать в определённом порядке, так как некоторые пакеты требуют присутствия других пакетов в системе на момент установки. Но не все. Я осмелел и поставил сначала команду less, хоть она впереди хер знает где. Сначала проверил её зависимости на своей хостовой системе через rpm -qR и ldd, в книжке про зависимости тоже ничего не написано. less скомпилилась и поставилась. Теперь работает. Но мож подвох какой потом выяснится. Потом нашёл пакет which и поставил его. Нашёл в тырнете, но потом подглядел в книжке BLFS 8.1, какую версию надо ставить и как. Никаких хитростей, which собралась и тоже работает. А тут надо сказать, что щас есть две версии LFS - с systemd и с sysvinit. Я подумал, почему бы не собрать их обе? Сделать это просто - надо скопировать сейчас перед установкой systemd всё, что я уже поставил и на одну копию поставить systemd и остальные пакеты, а на другую sysvinit и его пакеты в очерёдности, которая указана в нужной версии книги. Так я подумал и ушёл домой. Дома у меня родился хитрый план. Что там, что там пакеты одни и те же. Нафига спрашивается два раза их ставить на обе копии, если можно сначала поставить все общие пакеты, а под конец оставить systemd с d-bus или sysvinit, ksyslogd & Eudev.
На работе с утра я поискал о зависимостях и обнаружил глюк. В обеих версиях книги в Приложении С указаны зависимости для sysvinit. Об чём я набрался наглости написать авторам проекта. Ещё раз внимательно перечитал 6ю главу - всё-таки есть пакеты, зависящие от systemd и требующие его наличия в системе до установки. Это, например, coreutils. util-linux. Ещё он же встречается в зависимостях для Kmod & Xz. Кто там от кого зависит, хз, но факт имеет место быть. Подумал, и решил собирать по инструкции. Сделал резервную копию, потом поставил systemd. Дальше поставил два пакета более менее без проблем и застрял на coreutils. К нему прилагается патч, причём написано, что в патче в своё время находили много глюков, поэтому проверьте, может, новый вышел. Вот она, сука-бля, самая совершенная и безопасная система в мире. coreutils, между прочим не последнее место в ней занимают, как ясно из самого названия. Это команды, которые используются каждый день. Начал собирать, делаю тест, ошибку выдаёт, падла. Ошибка на тесте test/mv/sticky-to-xpart. В логах на сайте LFS этот тест пройден, в тырнете похожая ошибка обсуждается один или два раза. Нашёл видео какого-то перца, дык и у него тест прошёл. Ладно, думаю, попробую пройти дальше. Дальше тоже выдало ошибки. Стал ковырять логи. Чо-то там пишут про selinux. Отключил, помогло. Перекомпилял для чистоты. Первый тест норм, следующий прерывается с ошибкой, а на сайте логи дальше идут. В инструкции приведена команда make RUN_EXPENSIVE_TESTS=yes check, и если верить логам, у них всё шоколадно - делает два теста, в каждом по 1 ошибке, но идти продолжает. А у меня останавливается на первом из-за ошибки. Попробовал make RUN_EXPENSIVE_TESTS=yes -k check, проканало.
Ошибки выдаются на тестах misc/date debug и test-getlogin, об чём написано в инструкции. Решил продолжить, но сомнения гложут - у них в инструкции нет ключа -k и типа дальше проходит, хотя ошибки точно такие же, а мне вот ключ пришлось поставить. И целый час на эту херню убил ((
Осталось немного до седьмой главы, где начинается новый ебаторий - конфигурация.
Это было касательно сборки LFS, но помимо её я тоже провожу время с пользой. Во-первых, попытался разобраться, как, что и зачем делается в LFS. Стало понятнее. Нашёл тот пункт в 6.10, где раньше накосячил. Хотя, вопросов ещё много остаётся и наверное они будут всегда.
Начинается всё с того, что мы собираемся компилировать систему. Что нам для этого нужно? Первым делом - компилятор, компоновщик, и библиотека языка (о которой часто забывают). Если речь идёт о С, понадобится ещё ассемблер, т.к. С транслирует сначала в него. Если речь идёт ещё и о С++, то понадобится ещё и препроцессор и библиотека для С++.
С этого LFS и начинает - первым шагом собирается компоновщик с ассемблером. Потом сразу же компилятор. Причем, устанавливается в /tools/bin. /tools/bin не похож ни на один из стандартных системных путей типа /usr /bin /sbin и т.д. Таким образом, это гарантирует, что случайно не запустится утилита с хостовой системы, а только то, что мы поставили в /tools/bin.
Потом собираются заголовки ядры и библиотеки для С и С++ (glibc & libstdc++). Компоновщик и компилятор были собраны хостовыми инструментами и испытали на себе "влияние" хостовой среды. В частности, то, что в бинарниках прописан (насколко я понял) хостовой компоновщик и хостовые библиотеки. Теперь, когда у нас есть свои библиотеки в /tools/bin, мы пересобираем заново компоновщик и компилятор. Т.к. они собраны в среде /tools/bin, то испытают на себе "влияние" уже этой среды - в них будут прописаны пути /tools/bin и они же будут прописываться во всех компонентах, которые мы теперь будем собирать.
Дальше меня смущает, что мы не пересобираем библиотеки С и С++ (glibc & libstdc++), как можно было бы подумать, а продолжаем собирать остальные пакеты. Хрен знает, возможно, именно эти библиотеки неподвластны "влиянию" среды, т.к. туда некуда прописывать путь, а возможно вообще все библиотеки неподвластны. Рано или поздно мы это узнаем.
Дальше мы собираем кучу пакетов, после чего начинаем с заголовков ядра, комплекта мануалов и библиотеки С - glibc. (видимо, это компоненты, не подверженные "влиянию"). Потом мы делаем "adjusting toolchain" - подправляем пути и подменяем компоновщик, чтобы он указывал не на /tools/bin, а на /usr/lib, /usr/include и т.д. Дальше собираем пакеты и инсталлируем их в каталоги будущей ОС, а дальше я пока не дошёл.
Раньше я думал, что glibc это один большой бинарный файл. Хер там. Glibc это пакет, в который входит куча мелких файлов-библиотек, составляющих функционал glibc + ещё несколько команд для установки временной зоны, функции для работы с файлами /etc/passwd & /etc/group + ещё локали и команды для работы с ними.
Я понял, что мало написать и отладить пакет. К нему нужен ещё набор тестов, который убедит остальных, что всё собралось и работает правильно.
Я понял, почему FreeBSD называют "логичной", а Linux - набором пакетов с кое-как прикрученным ядром. Дело в том, что сообщество FreeBSD разрабатывает всё вместе - ядро и обвязку. Изменилось у них что-то в ядре - они могут подогнать под это функционал команд. Могут менять код команд и ядра так, как им удобно. В Linux ядро разрабатывает отдельно одна группа разработчиков во главе с Линусом, а всё остальное разрабатывается сообществом GNU и им ещё надо совместно договариваться, как и что писать, чтобы их продукты можно было соединить в систему. Не всё разрабатывается GNU, что-то ещё кем-то другим пишется. Через это типа ядро Linux никогда не будет так плотно пригнано, как ядро FreeBSD. Странно, правда, что GNU за все эти годы так и не удосужилось разработать своё ядро.
Раньше я изучал команды "группами". Группы формировал по своему усмотрению. Ну или в книгах команды даются вместе, я их и читал. Дык вот, оказывается, очень удобно, хоть и не очевидно, учить команды пакетами. Например, в пакет e2fsprogs входят библиотеки и команды для работы с системами ext2, ext3, ext4. Команды очень разные по назначению, но выстроены вокруг файловой системы. В другом пакете будут например команды работы с текстом.
До хера ваще виртуальных файловых систем в Linux! Да, возможно, удобно, но всё равно многовато: /proc /run /sys /dev /dev/pts хуй прассыш! Кстати, пакет procps-ng выстроен вокруг файловой системы /proc. Во FreeBSD пока замечены /proc & /dev. Но наверняка скоро появится и остальное.
Раздобыл книжку How Linux Works Брайана Уорда. Читаю, вникаю. Всё началось с команд ldd & readelf, с которыми я познакомился в LFS.
Вот ещё нашёл статейку прикольную stoplinux.org.ru/project/FAQ_why_linux_suks.htm... Круто он их обосрал! Но это был 2009 год, и щас что мы видим? Прошло 8 лет, Linux по-прежнему в строю, тех микроядерных систем, про которые он говорил (Haiku, Syllable, AROS) не видно и не слышно, только Haiku вроде ещё пока существует, а сам он пишет какие-то унылые новости, а вот раньше жог просто пиздец, у красноглазегов пуканы взрывались!
Ещё вот бесило меня, когда набираешь find / он начинает искать по всем этим ёбаным /proc /run и т.д. Нашёл я вариантик - find -xdev или find -mount. Оставаться в пределах файловой системы. Если у тя токо /home и всё остальное на / (у меня на десктопе так), это очень удобно. Если /usr /var и прочее подмонтированы, тогда да, херня.
Версия для cp: cp -x чтоб не копировать опять же все эти /proc /run, а только то, что нужно.
Ладно, пока хватит, вникайте, а я спать пошёл
В пятницу я немного дособрал и остановился перед пакетом systemd. Пакеты нужно собирать в определённом порядке, так как некоторые пакеты требуют присутствия других пакетов в системе на момент установки. Но не все. Я осмелел и поставил сначала команду less, хоть она впереди хер знает где. Сначала проверил её зависимости на своей хостовой системе через rpm -qR и ldd, в книжке про зависимости тоже ничего не написано. less скомпилилась и поставилась. Теперь работает. Но мож подвох какой потом выяснится. Потом нашёл пакет which и поставил его. Нашёл в тырнете, но потом подглядел в книжке BLFS 8.1, какую версию надо ставить и как. Никаких хитростей, which собралась и тоже работает. А тут надо сказать, что щас есть две версии LFS - с systemd и с sysvinit. Я подумал, почему бы не собрать их обе? Сделать это просто - надо скопировать сейчас перед установкой systemd всё, что я уже поставил и на одну копию поставить systemd и остальные пакеты, а на другую sysvinit и его пакеты в очерёдности, которая указана в нужной версии книги. Так я подумал и ушёл домой. Дома у меня родился хитрый план. Что там, что там пакеты одни и те же. Нафига спрашивается два раза их ставить на обе копии, если можно сначала поставить все общие пакеты, а под конец оставить systemd с d-bus или sysvinit, ksyslogd & Eudev.
На работе с утра я поискал о зависимостях и обнаружил глюк. В обеих версиях книги в Приложении С указаны зависимости для sysvinit. Об чём я набрался наглости написать авторам проекта. Ещё раз внимательно перечитал 6ю главу - всё-таки есть пакеты, зависящие от systemd и требующие его наличия в системе до установки. Это, например, coreutils. util-linux. Ещё он же встречается в зависимостях для Kmod & Xz. Кто там от кого зависит, хз, но факт имеет место быть. Подумал, и решил собирать по инструкции. Сделал резервную копию, потом поставил systemd. Дальше поставил два пакета более менее без проблем и застрял на coreutils. К нему прилагается патч, причём написано, что в патче в своё время находили много глюков, поэтому проверьте, может, новый вышел. Вот она, сука-бля, самая совершенная и безопасная система в мире. coreutils, между прочим не последнее место в ней занимают, как ясно из самого названия. Это команды, которые используются каждый день. Начал собирать, делаю тест, ошибку выдаёт, падла. Ошибка на тесте test/mv/sticky-to-xpart. В логах на сайте LFS этот тест пройден, в тырнете похожая ошибка обсуждается один или два раза. Нашёл видео какого-то перца, дык и у него тест прошёл. Ладно, думаю, попробую пройти дальше. Дальше тоже выдало ошибки. Стал ковырять логи. Чо-то там пишут про selinux. Отключил, помогло. Перекомпилял для чистоты. Первый тест норм, следующий прерывается с ошибкой, а на сайте логи дальше идут. В инструкции приведена команда make RUN_EXPENSIVE_TESTS=yes check, и если верить логам, у них всё шоколадно - делает два теста, в каждом по 1 ошибке, но идти продолжает. А у меня останавливается на первом из-за ошибки. Попробовал make RUN_EXPENSIVE_TESTS=yes -k check, проканало.
Ошибки выдаются на тестах misc/date debug и test-getlogin, об чём написано в инструкции. Решил продолжить, но сомнения гложут - у них в инструкции нет ключа -k и типа дальше проходит, хотя ошибки точно такие же, а мне вот ключ пришлось поставить. И целый час на эту херню убил ((
Осталось немного до седьмой главы, где начинается новый ебаторий - конфигурация.
Это было касательно сборки LFS, но помимо её я тоже провожу время с пользой. Во-первых, попытался разобраться, как, что и зачем делается в LFS. Стало понятнее. Нашёл тот пункт в 6.10, где раньше накосячил. Хотя, вопросов ещё много остаётся и наверное они будут всегда.
Начинается всё с того, что мы собираемся компилировать систему. Что нам для этого нужно? Первым делом - компилятор, компоновщик, и библиотека языка (о которой часто забывают). Если речь идёт о С, понадобится ещё ассемблер, т.к. С транслирует сначала в него. Если речь идёт ещё и о С++, то понадобится ещё и препроцессор и библиотека для С++.
С этого LFS и начинает - первым шагом собирается компоновщик с ассемблером. Потом сразу же компилятор. Причем, устанавливается в /tools/bin. /tools/bin не похож ни на один из стандартных системных путей типа /usr /bin /sbin и т.д. Таким образом, это гарантирует, что случайно не запустится утилита с хостовой системы, а только то, что мы поставили в /tools/bin.
Потом собираются заголовки ядры и библиотеки для С и С++ (glibc & libstdc++). Компоновщик и компилятор были собраны хостовыми инструментами и испытали на себе "влияние" хостовой среды. В частности, то, что в бинарниках прописан (насколко я понял) хостовой компоновщик и хостовые библиотеки. Теперь, когда у нас есть свои библиотеки в /tools/bin, мы пересобираем заново компоновщик и компилятор. Т.к. они собраны в среде /tools/bin, то испытают на себе "влияние" уже этой среды - в них будут прописаны пути /tools/bin и они же будут прописываться во всех компонентах, которые мы теперь будем собирать.
Дальше меня смущает, что мы не пересобираем библиотеки С и С++ (glibc & libstdc++), как можно было бы подумать, а продолжаем собирать остальные пакеты. Хрен знает, возможно, именно эти библиотеки неподвластны "влиянию" среды, т.к. туда некуда прописывать путь, а возможно вообще все библиотеки неподвластны. Рано или поздно мы это узнаем.
Дальше мы собираем кучу пакетов, после чего начинаем с заголовков ядра, комплекта мануалов и библиотеки С - glibc. (видимо, это компоненты, не подверженные "влиянию"). Потом мы делаем "adjusting toolchain" - подправляем пути и подменяем компоновщик, чтобы он указывал не на /tools/bin, а на /usr/lib, /usr/include и т.д. Дальше собираем пакеты и инсталлируем их в каталоги будущей ОС, а дальше я пока не дошёл.
Раньше я думал, что glibc это один большой бинарный файл. Хер там. Glibc это пакет, в который входит куча мелких файлов-библиотек, составляющих функционал glibc + ещё несколько команд для установки временной зоны, функции для работы с файлами /etc/passwd & /etc/group + ещё локали и команды для работы с ними.
Я понял, что мало написать и отладить пакет. К нему нужен ещё набор тестов, который убедит остальных, что всё собралось и работает правильно.
Я понял, почему FreeBSD называют "логичной", а Linux - набором пакетов с кое-как прикрученным ядром. Дело в том, что сообщество FreeBSD разрабатывает всё вместе - ядро и обвязку. Изменилось у них что-то в ядре - они могут подогнать под это функционал команд. Могут менять код команд и ядра так, как им удобно. В Linux ядро разрабатывает отдельно одна группа разработчиков во главе с Линусом, а всё остальное разрабатывается сообществом GNU и им ещё надо совместно договариваться, как и что писать, чтобы их продукты можно было соединить в систему. Не всё разрабатывается GNU, что-то ещё кем-то другим пишется. Через это типа ядро Linux никогда не будет так плотно пригнано, как ядро FreeBSD. Странно, правда, что GNU за все эти годы так и не удосужилось разработать своё ядро.
Раньше я изучал команды "группами". Группы формировал по своему усмотрению. Ну или в книгах команды даются вместе, я их и читал. Дык вот, оказывается, очень удобно, хоть и не очевидно, учить команды пакетами. Например, в пакет e2fsprogs входят библиотеки и команды для работы с системами ext2, ext3, ext4. Команды очень разные по назначению, но выстроены вокруг файловой системы. В другом пакете будут например команды работы с текстом.
До хера ваще виртуальных файловых систем в Linux! Да, возможно, удобно, но всё равно многовато: /proc /run /sys /dev /dev/pts хуй прассыш! Кстати, пакет procps-ng выстроен вокруг файловой системы /proc. Во FreeBSD пока замечены /proc & /dev. Но наверняка скоро появится и остальное.
Раздобыл книжку How Linux Works Брайана Уорда. Читаю, вникаю. Всё началось с команд ldd & readelf, с которыми я познакомился в LFS.
Вот ещё нашёл статейку прикольную stoplinux.org.ru/project/FAQ_why_linux_suks.htm... Круто он их обосрал! Но это был 2009 год, и щас что мы видим? Прошло 8 лет, Linux по-прежнему в строю, тех микроядерных систем, про которые он говорил (Haiku, Syllable, AROS) не видно и не слышно, только Haiku вроде ещё пока существует, а сам он пишет какие-то унылые новости, а вот раньше жог просто пиздец, у красноглазегов пуканы взрывались!
Ещё вот бесило меня, когда набираешь find / он начинает искать по всем этим ёбаным /proc /run и т.д. Нашёл я вариантик - find -xdev или find -mount. Оставаться в пределах файловой системы. Если у тя токо /home и всё остальное на / (у меня на десктопе так), это очень удобно. Если /usr /var и прочее подмонтированы, тогда да, херня.
Версия для cp: cp -x чтоб не копировать опять же все эти /proc /run, а только то, что нужно.
Ладно, пока хватит, вникайте, а я спать пошёл