Debian From Scratch 0.99.0

Эпидемия по клепанию LiveCD/Rescue дисков продолжается.... :-)

Для виндов в свое время это было необходимо, да и сейчас наверное необходимость не пропала... но на кой все эти "спасалки" в юниксах...

Ну вот вчера apt-get update && apt-get upgrade сделал, сегодня гружу машину и наблюдаю: Waiting for root file system и busybox потом и чего делать с этим накряченым кернелом? а ты говоришь ненужны...

>но на кой все эти "спасалки" в юниксах...

Иногда бывают нужны. Так был случай, стоял комп с линуксом, который установили год назад и забыли где диски с дистрибутивом, потом надо было поставить винду. Офтопик, как известно, бессовестно трет загрузчик, что и сделал на этот раз. Восстановить загрузку линукса удалось со Slax'a.

>Эпидемия по клепанию LiveCD/Rescue дисков продолжается.... :-)

Что поделать - весеннее обострение

BeOs жив...

лфс-ы разные нужны
лфс-ы разные важны

Это должно быть запрещено. Видеть такое больше невозможно. Виндоюзеры и так над нами смеются.

ух ты..

???

>но на кой все эти "спасалки" в юниксах...

Глюкнул жесткий диск. Остался работоспособным, но фс повреждена. Твои действия?

>BeOs жив...

ленин жил, ленин жив, ленин будет жить

некрофилы мля

Интересней звучит фраза "возможность построить свою систему по принципу Gentoo", а не флейм про ненадобность livecd.

>BeOs жив...

>ленин жил, ленин жив, ленин будет жить

>некрофилы мля

>blaster999 (*

Ну почему сразу некрофилы. Хайку довольно сностно продвигается. Посмотрим , что из этого получится.

Ан нефиг пользоваться отличными от vanilla ядрами :) Нужно что-то конкретное - накладываем патчи руками, а дистры не умеющие использовать стандартную схему (ядро в /boot, модули в /lib/modules) идут лесом... На самом деле можно, конечно, но делать лучше что-то одно и строго по порядку (и бакапиться не забывать) - либо ядро меняем, либо систему апдейтим... тем снижается риск получить каку на выходе )

Вот я про это примерно и говорю, livecd нужен по большому счету для двух операций: 1. вытянуть бакапы из сети и распаковать на винт (если полный ахтунг); 2. дать возможность войти в chroot и починить все из себя же. Т.е. ядро, баш, tar+(gzip,bzip2,7z,...), сетевые утилы, утилы ФС... damn-small-linux'а по идее хватит выше крыши, а если замутить на мизерную флешку GRUB с поддержкой bootp - то и еще меньше нужно %)

Еще один дистриб для спасения вымирающего Debian'а ;)

>Еще один дистриб для спасения вымирающего Debian'а ;)

Вот это точно -- после их октябрьского апдэйта они потеряли меня как пользователя. А вообще я не понимаю: в чем тогда отличие от Лфс и Генту? Летом сделаю себе *ЛФС и буду радоваться жизни

вымирающего ? что за бред ты несёшь?

> в чем тогда отличие от Лфс и Генту?

В количестве пакетов на одного мейнтейнера (т.е. в наличии.отсутствии перегрузки). В том, что в Gentoo мейнтейнеры понимают, что делают.

В LFS куча сил ушла на не всем нужный udev (причем мне приходилось критиковать каждый второй коммит!), в результате устранение багов в других пакетах времени не осталось. Посмотрите, они только три дня назад прикрутили security-patch к tar (мне просто надоело избивать этот пример в частной антирекламе LFS, поэтому я и передал его Archaic'у по ICQ), тогда как в нормальных дистрах это обновление безопасности было в первую же неделю после объявления на full-disclosure (т.е. в конце января). Не уверен, что разработчики LFS читают списки рассылки разработчиков используемого софта, хотя это их прямая обязанность как мейнтейнеров.

И еще. Для себя я обнаружил, что чтение Debian'овских Changelog'ов порождает довольно много сомнений в надежности LFS.

Грузануться с флешки (так урезанная копия рабочей системы, ~110 Mb со всем стаффом для этих целей, если задаться всунуть в размер - можно получить и 30 и 20 и 10), смонтировать на rw с бакапного сервака NFS, и "dd if=/dev/... | bzip2 -9" на оную слить пожатый образ винта. Затем - анализ трабла и восстановление инфы на реально рабочей машине. А винт все равно менять придется, ибо оставлять глюкало - это ой...

Сколько утилок я использовал? ;)

Я имел ввиду СуСЕ ЛФС-ными методами (+ пакеты из Дебиан, которых нет в СуСЕ, но нужные мне)

А дебиан на Хурд уже забили?

>Также в системе присутствуют всевозможные утилиты для спасения умирающей/мертвой системы.

Чё-то не к добру это:)

Оно сразу собирается сдохнуть?

LFS-ов много... у каждого LFS-ника - своя :) Бекманс прямо говорит - "для лучшего понимания", но зачем же всю жизнь следовать его способу ручной сборки? Автоматизация прикручивается за пару дней с полпинка, патчи - можно и самому добавлять, рассылки капают - и нормально... Реально система обновляется после серьезных изменений (переезд на новый компилятор, glibc, binutils), в случае использования /usr/local - все поверх базовой системы обновляется не затрагивая ее самой... Минус - нет пакетного манагера, но обратная "make install" процедура проводится элементарно )

>>Также в системе присутствуют всевозможные утилиты для спасения умирающей/мертвой системы.

>Чё-то не к добру это:)

>Оно сразу собирается сдохнуть?

Что ни разу не спасал систему с RescueCD -- тогда мы летим к вам. В своё время я с Мак ОС доэкпериментировался, что загрузчика не стало

Все ломанулись смотреть, сайт дико затормозил... это DDoS %)))

Тот патч можно было прикрутить и руками, никто не запрещает, все равно сборка идет не строго по команде Бекманса )

LFS-же вполне рабочая система, но доводить ее руками под себя - никто не мешает... Есть коллективная разработка - это Генту, есть индивидуальная - образец LFS, заточки - для себя. В BLFS OpenOffice 2.0 появился тоже недавно, но почему-то у иных LFS-ников - появился еще и пораньше, чем в SuSE и RedHat...

Да спасал. С помощью sentinex и прочих живых дисков. Просто как-то мне кажется, что предназначение распыляется немного... или это рескью или это DFS...

> LFS-ов много... у каждого LFS-ника - своя :)

Тем не менее надо бы учитывать следующее.

1) Есть некий вариант сборки по умолчанию (как набор версий пакетов, патчей и команд для ручной или автоматизированной сборки)

2) Есть неявное предположение, что этот вариант не содержит серьезных изъянов, и дает достаточно хорошую систему.

3) Есть факт, что серьезные дистрибутивы включают исправления критических багов из CVS-версий пакетов. LFS-исключение, они даже не видят эти баги.

Пример: http://wiki.linuxfromscratch.org/lfs/ticket/1718

Во всех нормальных дистрах это исправили 1 октября 2005 г. В LFS - вместе с выходом GCC-4.0.3.

> LFS-же вполне рабочая система, но доводить ее руками под себя - никто не мешает...

Но почему-то никто не высылает свои доводки "наверх", даже если они имеют отношение ко всем остальным пользователям LFS. Иначе говоря, у LFS отсутствует community как класс.

1) И у каждого он свой

2) Есть такое же предположение, что дают

3) Добавление в книгу не является фактом исправления - большинство граблей при сборке LFS решаются на месте при помощи гугля, изучения ебилдов и рулезов.

> у LFS отсутствует community как класс.

А принцип "сам себе режиссер" и не требует наличия коммьюнити

1. Да, и есть слова о том, что этот вариант соберется и заработает, если делать все по книжке, и это действительно так. 2. Про изъяны там ни слова, но работоспособность и определенная стабильность - есть. 3. Наверное потому что мы не серьезные ил потому что не дистр? ;)

Тогда расскажу как у меня все было: сначала ставился "книжный" LFS, потом со временем стало понятно, что в некоторых вопросах ребята идут не туда (втыкнули компайлер 3.4.0, фактически уделав стабильность и собираемость), и пришлось форкать LFS для своих нужд. Тогда же стало ясно, что в объеме BLFS руками собирать каждый пакет - это финиш, и была прикручена система автосборки, в которую теперь вносятся только секьюрити хотфиксы и патчи для поддержки новых компиляторов. Из CVS просто так не собирается почти ничего (т.е. все тянется по ftp/http и только релизные пакеты), исключения - MPlayer и linuxDCPP. В таком виде система прожила почти 3 года и признаков нездоровья не выказывает... от оригинальной LFS - осталось очень мало... секьюрити - обеспечивается по результатам бдений над мануалами и багтраками... И я отнюдь не исключаю, что народа поступающего с базовой LFS подобным же образом - до фига и больше, поэтому да, косяк с коммунити, но LFS - как идея - это очень здорово и правильно, просто спорных моментов там много.

P.S. LFS - не "дистрибутив", это философия и способ построения дистра. Так сказал Бекманс ;) P.P.S. gcc-4.0.x - слишком сыро, и к хорошему не приведет...

> Gharik > Минус - нет пакетного манагера

Это у кого как. У меня есть.

> AEP >Но почему-то никто не высылает свои доводки "наверх"

Я бы выслал, но что-то по быстому не разобрался, как это проще сделать. Вроде через wiki можно, но кажеться там понадобиться кучу всяких пакетов устанавливать, причем под Линукс, а я в инете на работе под виндой сижу.

> Да, и есть слова о том, что этот вариант соберется и заработает, если делать все по книжке, и это действительно так.

Не всегда. Вот недавно в тестовой версии книги выкинули из статической сборки 2 пакета ( сейчас не помню, какие именно, одни из последних), так сборка основной системы при этом обрывалась в самом начале, а если их установить, то проходила.

Есть мысли по-быстрому слепить гибрид слаки+BSD, т.е. пакеты .tar.gz/.bz2/.7z, установка через "make install", где таргетами будут являться все входящие в тарболл файлы, и общие цели install/repair/check/uninstall, но сиим заниматься получится еще не скоро... а Makefile'ы по идее можно генерировать почти автоматом...

> Тогда расскажу как у меня все было: сначала ставился "книжный" LFS, потом со временем стало понятно, что в некоторых вопросах ребята идут не туда (втыкнули компайлер 3.4.0, фактически уделав стабильность и собираемость), и пришлось форкать LFS для своих нужд.

История аналогична, но в качестве последней капли выступил udev и ядро 2.6. Сам процесс сборки давно уже был автоматизирован. Форкать LFS для своих нужд я собирался, но побоялся: слишком большой объем работы по обеспечению качества (например, просмотр первых наскольких CVS-commit'ов после каждого релиза каждой софтины на предмет исправлния brown-paper-bag bug'ов). Короче, если бы я за все взялся сам, один, результат был бы еще хуже, чем в LFS. В конечном итоге я пересел на Debian.

А по поводу "сам себе режиссер":

Почему бы не начать свою деятельность не с vanilla upstream, а с тех исправлений, которые уже стали "общим местом"? Иначе говоря, не самоизолироваться. Самоизоляция вредна.

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

lfs-dev@linuxfromscratch.org. Wiki только для разработчиков, туда идут только подтвержденные баги.

Udev в свое время воткнулся без проблем, и от hotplug'a я отошел как бы не пораньше чем девелоперы :) Ядро 2.6 тоже вставало без особых косяков (не торопился с /usr/include от 2.6 и юзал стабильные 2.4)

Самоизоляция... та я как-то не стремился особо выкладывать свой вариант как есть, т.к. ценность представляет не система сборки, а результат конечный, т.е. 1-2CD с образом системы и простейшим live-cd, для "загрузиться, разметиться и распаковаться", потом чрут, фстаб и загрузчик... на крайний - пересборка ядра под проц. А такое подойдет не всем.

Под "общим местом" что имелось в виду?

> Самоизоляция вредна.

Тут не могу не согласится... не всегда есть время обновляться и мутить собственные сборки того или иного софта. Но интерес из разряда "А что если ..." сильнее.

PS: Сам сейчас на Debiane

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

Вот так почти все - тихо сами с собой. А ведь делают в конечном итоге одни и те же операции. Делиться своим опытом надо, чтобы другие по крайней мере не повторяли одни и те же ошибки. Я себе скрипты для автосборки сделал и выложил на своей страничке. Если кому-нибудь пригидяться - хорошо.

> на крайний - пересборка ядра под проц.

А остальной софт? Ведь вся прелесть в оптимизации работы целой системы, а не только ядра.

> Udev в свое время воткнулся без проблем, и от hotplug'a я отошел как бы не пораньше чем девелоперы :) Ядро 2.6 тоже вставало без особых косяков (не торопился с /usr/include от 2.6 и юзал стабильные 2.4)

Outlook Express в свое время (до появления вирусов) тоже работал без проблем :)

> ценность представляет не система сборки, а результат конечный

Полностью согласен

> Под "общим местом" что имелось в виду?

Патчи присутствующие во всех дистрибутивах.

А остальной софт собирается с единожды задаваемыми и одинаковыми везде флагами, в основном - только под проц (-march=...), уровень -02, как быстрый, общепринятый и консервативный (в сравнении с -O3 -fomit-frame-pointer -... etc.). Фишка - в отсутствии разных оптов в разных частях системы (десктоп - не сервер реального времени), а если таковая игра с флагами и оптимизацией нужна - включается для конкретных пакетов.

> в основном - только под проц (-march=...),

Так и я о том же. Но имея дистр, собранный под один процессор, например под i686, оптимизировать на нём ядро под более крутой вариант особого смысла нет, ведь все остальные пакеты не будут использовать все новые возможности этого процессора. Мне так кажеться.

Из патчей - в основном только секьюрные и исправляющие серьезные баги. В том же редхете в src.rpm для базовых утилит лежит столько всего, что непонятно - где кончается оригинальная софтина, а начинается "RH ...", в SuSe - другие наборы патчи, а вылавливать общее - влом. По идее вышеупомянутое должно присутствовать на страничках самих утилит, а мой подход примерно аналогичен слаковскому - патчим только нужное.

> По идее вышеупомянутое должно присутствовать на страничках самих утилит, а мой подход примерно аналогичен слаковскому - патчим только нужное.

Совершенно верно. Как определить "только нужное"?

P.S. тест для слаки:

http://lists.gnu.org/archive/html/bug-tar/2005-03/msg00004.html

А что такого совсем нового появилось в ядре i686 вариации p4/prescott... Ну разве что наборы инструкций, да gcc код оптимизирует немного по другим критериям... а основной пул инструкций - тот же самый. Вот разница между i686+ и k6/k7/k8 - уже очень велика, т.к. архитектура совместимая по инструкциям - но совсем разная внутри, и оптимизировать больше причин. А ядро всегда должно работать на своем родном проце... Вообще какой смысл париться по поводу оптимизаций, если имея старую систему под старый проц - всегда можно автоматически пересобрать все под новый, но что-то рабочее нужно прямо сейчас... не вижу траблов...

> Ну вот вчера apt-get update && apt-get upgrade сделал, сегодня гружу машину и наблюдаю: Waiting for root file system и busybox потом и чего делать с этим накряченым кернелом? а ты говоришь ненужны...

ССЗБ.

> Виндоюзеры и так над нами смеются.

Стадо говедоюзеров весьма показательно.

Патчики в сему в LFS точно проскакивали, а как в слаке - не в курсе, но скорее всего Патрик не спит и все патчит вовремя, даже учитывая дочку :)

Самый хороший вариант с моей т.з - это таки форк LFS, и объединение наработок в дистрибутив, но этим путем прошел генту и стоит ли повторять это чудо - черт его знает... лучше придумать "как могло бы быть лучше", чем делать что-то непойми зачем...

Мысли вслух - взять к примеру Fedora Core или SuSe - бешеные требования к памяти (при отключенных сервисах и т.д. голый КДЕ жрет за 130-140 метров, не считая буферов и кешей, LFS - и до 90-100 добирается с трудом), дебиан - стабильность ценой устаревания, генту - гибкость разумеется, зато переусложнение всего и вся, гимор с ебилдами и место еще тратить на них... смотрим в сторону BSD? ;)