Initrd (от DdShurick)

[sfs]

squashfs лучше.

Для меня - тоже лучше save.squashfs, но мы же не только для себя делаем

А ломать структуру загрузки ради портеус и системд это как?

Не очень понял что такое "структура загрузки" и при чем здесь  initrd_mnt
Вроде никто использовать systemd в initrd_mnt Вам не предлагал
....А вот udev173 для больших ядер - было бы интересно. Вот тогда бы стало понятно "зачем" - для тех кто хочет большое ядро, но не может осилить uird

[Pro]

В своей ветке initrds пофиксил форматирование и удалил ntfs-3g.

одумайся, ведь так можно дойти и до ненужности загрузки по сети.

[DdShurick]

вообще то системд привносит в линукс унификацию загрузки и делает линуксы более совершенными.

А по моему более непонятными и сильно зависимыми от желаний L.P.

все современные дистры так или иначе останутся только на нем - это прогресс

Прогресс чего? Раздувания кода? Иам мало GRUB2?

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

Глупец тот, кто влезает, не подумав, как потом вылезти.

Скучно с вами, только спорить умеете, и ни одной интересной мысли. Надоело.

[Pro]

зато твои мысли прям блещут оригинальностью.
Давайте уже закроем тему, автор же вроде плюнул на это дело.

ps. считаю что во всем виноват форум, моглибы в конференции онлайн быстренько разосраться и наметить перспективы.

[neobht]

А в initrd DDSh поддержки сети и нет. Даже если и были бы скрипты, то непроинициализировав модули ядра, сеть будет недоступна. Ну а если начать городить инициализацию и включать сетевые модули, то получим минимизацию уровня udev, а поскольку она будет написана не на уровне компилируемой программы, а в виде шел скрипта, то будет больше по размеру даже.

To Ddshurick: просто так код никто не раздувает. Он необходим и его пишут.

[neobht]

Grub2, rsync, systemd, attic-backup, xdelta - считаю шедеврами мира Линукс.

[DdShurick]

А в initrd DDSh поддержки сети и нет.

Временно вырезана и положена рядом для доработки.

Даже если и были бы скрипты, то непроинициализировав модули ядра, сеть будет недоступна.

Ох уж эти сказочники. Тогда как я с домашнего сервера загружался?  

To Ddshurick: просто так код никто не раздувает.

Google говорит что "code bloat" существует, значит раздувают, и этому существует множество причин, непрофессионализм, очковтирательство (план по валу), выпендрёж (какой я умный, столько написал)...

Grub2, rsync, systemd, attic-backup, xdelta - считаю шедеврами мира Линукс.

Под тяжестью этих "шедевров" линукс скоро загнётся. Шедевр это busybox.

[neobht]

Вот пример code bloat, который написан ради того, чтобы быть написанным:

Код

#boot parametrs
[ $loglevel ] && LOGLEVEL=$loglevel #v2.22
[ $pdev1 ] && PDEV="$pdev1"    #partition have booted off. ex: hda3
[ $dev ] && PDEV="$dev"		#partition have booted off. ex: hda3

[ $serv ] && IP=$serv 			#loading of modules from the ftp-server
[ $servpath ] && DIR=$servpath
[ $load ] && LOAD=$(echo $load | tr ',' ' ') 
[ $noload ] && NOLOAD="$(echo \'$noload\' | tr ',' '|' | tr -d ' ')"
#now supporting a boot menu...
RDSH=""
if [ "$pfix" ];then
 for ONEFIX in `echo -n "$pfix" | tr ',' ' '`
 do

[DdShurick]

Вот пример code bloat, который написан ради того, чтобы быть написанным:

Опять сказки. Здесь всё нужное, правда dev и dir продублированы старыми именами.

[neobht]

Ни одна из перечисленных переменных не инициализирована на момент обращения к этому куску кода. Поэтому никакой && не срабатывает и ничего не присваивается.

[sfs]

Скучно с вами, только спорить умеете, и ни одной интересной мысли. Надоело.

....А вот udev173 для больших ядер - было бы интересно. Вот тогда бы стало понятно "зачем" - для тех кто хочет большое ядро, но не может осилить uird

Не интересно?
Все в инитрд уже изобретено. Суперинтересных мыслей не будет

[DdShurick]

Ни одна из перечисленных переменных не инициализирована на момент обращения к этому куску кода.

Вы уверены? Я знаю, что делаю. Правда load/noload можно убрать, но sfs будет против, сделано по его просьбе. Переменная serv дожидается, когда доделаю сетевую загрузку. Все значения pfix тоже нужны. Так что не надо ля-ля не разобравшись.

....А вот udev173 для больших ядер - было бы интересно. Вот тогда бы стало понятно "зачем" - для тех кто хочет большое ядро, но не может осилить uird

Не интересно?

Мне уже ничего не интересно.

Все в инитрд уже изобретено.

Значит будем выжимать воду.

[neobht]

Вы уверены? Я знаю, что делаю. Правда load/noload можно убрать, но sfs будет против, сделано по его просьбе. Переменная serv дожидается, когда доделаю сетевую загрузку. Все значения pfix тоже нужны. Так что не надо ля-ля не разобравшись.

Ну раз дожидается, то тогда спорить тут не очем. Тем более - раз вы переменные используете переданные ядром из командной строки, как они есть (это по всей видимости не очень безопасно - надо поизучать возможные атаки через такой механизм). Обычно делают предобработку /proc/cmdline.

[DdShurick]

это по всей видимости не очень безопасно - надо поизучать возможные атаки через такой механизм.

При отсутствии сетевой загрузки только через загрузчик, по сети возможностей больше.

Обычно делают предобработку /proc/cmdline.

Она и есть. Берутся только определённые значения переменных, остальное идёт лесом.

[Zay]

Почитал обсуждение. И, как мне кажется, Initrd от Дяди Шурика имеет все шансы стать отличной разработкой.
Главное - нужны стандарты (точка монтирования модулей, и прочее) чтобы совместимость была максимальной.
Тогда у сборщиков (и даже у пользователей) появится возможность менять Initrd, ничего не трогая в системе.
Это было бы очень хорошо! 

...и удалил ntfs-3g.

Вот этого не надо было делать.
Одна из принципиальных возможностей Frugal - загрузка и работа с разделов NTFS.
Для многих пользователей PuppyRus это НАМНОГО важнее той же загрузки по сети.

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

Напомню что на форуме есть люди, которые считают что конкретно systemd - это плохая идея и плохая реализация. Спорить об этом можно долго, но давайте уважать мнения друг друга, и не уходить в споры от основной темы, тем более если обсуждение деталей получается более конструктивным.