[systemd]Поттеринг ...

> т.е. init=/bin/bash больше не будет?

init это не initrd

ЕМНИП, этот Поттеринг вообще ничего полезного для линукс-сообщества не сделал. Нахрен он нужен?

да и вообще initrd может не быть

> Нахрен он нужен?

Не знаю, но тенденция такова, что все его поделки прочно закрепляются во всех дистрах.

Я пока воздерживаюсь от оценок systemd, journald и этого перехода. Хочу, как будет свободное время, поставить федорку и заценить на практике.

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

нууу, в общем, всё правильно, добавить нечего :).

А у меня чото креатив попер :)

Главное чтобы не получился монстр.

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

Ну и я считаю что софт в нее должен ставится пакетами. Как и в основную систему. Тем же пакетным манагером, только с другими опциями. То есть в конкретной инсталляции lvm может и не стоять. Как и, например, sshd. А systmd там не должно быть в принципе. :D И dbus, Хоть они там и обещали что systemd якобы должен увеличить скорость загрузки и вообще усилить и углубить - но я им не верю.

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

Во вторых она должна быть более гибко конфигурируема - понятно что это будет достигаться тем что пакетов в ней будет очень немного, а вот вариантов одно и того же сервиса-программы может быть больше одного. Конкретно например busybox для initrd - style для тех кто хочет совсем мизер, и обычный-glibc style. Грубо говоря я хочу в такой системе screen и bash, который мини-libc может не держать. Иногда вообще придется класть 2 пакета, например sshd «малюсенький» и sshd стандартное издание.

В любом случае, если подумать, идея в том что-бы такой «дистрибутив-мутант» можно было поставить в корень любой файлухи которую поддерживает линукс. В /boot/ в том числе. То есть возможность поставить его в / есть, но в принципе можно его же или еще одну копию поставить в раздел /boot и тп.

Далее, мне пришло в голову что все это надо ставить в свой аналог /usr... Предлагаю назвать его /rsys - root system :) . Ну и как бы гарантировать стандартами и соглашениями что /rsys может находится только на том диске на котором его директория, то есть этот путь не должен быть подмонтированным кроме каких то особо специальных случаев... типа настройки вручную.

Затем, потребителями этой системы в системе будут не только те кто хочет rescue, но и те кто хочет сетевых рабочих станций, Хтерминалов, строители HPC кластеров и тп. То есть принципы построения этой системы должна быть рассчитаны не только на тех кто хочет только rescue . Потому что понятно что если делать узко понимаемое «только rescue», те кто, например, жаждет сетевых рабочих станций, то для чего раньше юзался /sbin & /bin окажутся в пролете. А это будет непродуктивно.

В принципе, опять же, в идеале, по опыту работы с сетевыми рабочими станциями хотелось бы что бы в режиме сетевой рабочей станции этот /rsys вообще функционировал «параллельно» с основной системой. С расчетом на то что бы при отказе сетевого сервера с которого он работает сейчас, софт в /rsys мог найти резервный сервер и перемонтировать туда /usr , /etc и тп , если ядро это позволяет. То есть позволял делать гораздо более надежную систему, с возможностью гораздо более полной кастомизации.

Следующий момент - так как система функционирует в потенциально суровых условиях, наверное она должна себе для всех действий требующих изменения файлухи по дефолту подключать tmpfs. То есть должна нормально работать с ro раздела.

Так же я думаю нужна возможность грузить сначала /rsys а из него уже систему штатно, без remount как в initrd. Вплоть до того что бы отлавливать падения systemd и переходить в rescue mod.

Из непонятных вещей : что делать с /dev, в том числе с udev. Особенно в ro режиме ... хотя в ro режиме будет tmpfs.

Ну и чтобы загрузчик был от микросистемы а основная система грузилась через chainloading.

Ну и чтобы загрузчик был от микросистемы а основная система грузилась через chainloading.

Не совсем понял как это будет выглядеть....

Жаль времени нет, а то я бы занялся.

вообще говоря подозреваю что надо писать аналог федоровского feature , в том числе и в федору пиарить идею, разворачивать обсуждение и все такое.

Многие модули ядра нужны на ранней стадии загрузки, иначе вообще нихрена не забутается у тебя

то что нужно в самом начале легко вкомпиливается

это пока из ряда фантастики, увы. Но я с нетерпением жду когда же btrfs будет готова хотя бы для дома.

Это есть в штатной поставке федорки, начиная с 15. Называется yum-lugin-snapshot, если мне память не изменяет.

> то что нужно в самом начале легко вкомпиливается

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

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

Любой дистрибутив - это не серебрянная пуля. Каждый дистрибутив это инструмент, решающий более-менее четко поставленную задачу. И оценку можно давать лишь только в этой призме, а не «такой плохой дистр не заработал на моем тостере, потому что там юзр по сети монтируется».

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

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

> что сравнительно распространено

Сомневаюсь. Сейчас не девяностые.

Вы все совсем обленились?

Еще бы у вас не тормозило. Ядро и libc имеют кучу архитектурозависимых оптимизация, но в дистрибутивном варианте они отключены.

Всегда одним из первых дел перекомпилировал. И оптимизация есть.

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

Вообще я не понимаю, о чем ты со мной споришь?

я говорю, что дистрибутивное ядро/libc нужны лишь для того, чтобы первый раз загрузиться и пересобрать их для своей конфигурации

> Вы все совсем обленились?

Лично я - да, обленился, ядро последний раз лет 5 назад компилил. И судя по всему таких как я - большинство.

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

> я говорю, что дистрибутивное ядро/libc нужны лишь для того, чтобы первый раз загрузиться и пересобрать их для своей конфигурации

В генте - может быть, но в мейнстримных дистрах типа федоры и убунты - совершенно другое видение и приоритеты.

и нечем тут особо гордится

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

> неважно, можно ли этим гордиться. важно, что это ускоряет работу системы.

бенчмарки есть?

Ты говоришь, что создатели дистра исходят из предположения, что пользователь ничего менять не будет. как в убунте не знаю, но в дебиане есть не только исходники, но и специальная утилита для пересборки.

Годика 2 назад мерял. Ускорение было.

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

> но и специальная утилита для пересборки.

Нет, утилита в любом случае должна быть - надо же самим мейнтейнерам как-то собирать.

> Годика 2 назад мерял. Ускорение было.

узнаю себя лет в 18 :) не волнуйся, найдешь работу, заведешь семью и оно само собой пройдет.

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

Для этого есть модули. Например, в дебиане замечательный dkms.

А в чем проблема-то? .configure меняется мало. поставил компиляться и занялся работой/семьей

А в чем проблема-то? .configure меняется мало. поставил компиляться и занялся работой/семьей

Бессмысленные действия надоедают

Бессмысленные действия надоедают

польза есть а времени отнимает мало. почему бы не ускорить систему

> польза есть а времени отнимает мало. почему бы не ускорить систему

Потому что ее быстродействие и так достаточно с лихвой.

Потому что ее быстродействие и так достаточно с лихвой.

привет нетбуки на атоме (а других то почти и нет).

Вот жеж ты упрямый... Хочешь - собирай ядро, собирай генту или еще лучше ЛФС. Но ты - маргинал, таких как ты - меньшинство. Смирись.

польза есть а времени отнимает мало. почему бы не ускорить систему

Ускорение (которое еще доказать надо!) как самоцель нафиг никому не нужно

> как самоцель нафиг никому не нужно

Ну с никому ты погорячился, вот уважаемому товарищу cvs-255 оно таки нужно...

Но ты - маргинал, таких как ты - меньшинство. Смирись.

Линукс используется на меньшинстве. Смирись. У тебя (наверняка) нет 1 000 000 000 рублей. Смирись.

привет нетбуки на атоме (а других то почти и нет).

О да-да, сборка офиса или кед на атоме... И так при каждом обновлении. Кросс-компиляция и distcc, говоришь? Так вот это как раз адово красноглазие. А по факту ускорять нужно только видеопроигрывание и флеш. mplayer/vlc/ffmpeg можно пересобрать и в федоре/убунте, если руки чешутся, а остальное не является критичным к производительности CPU даже на атоме. Не веришь? Посмотри статистику, сколько времени твой CPU работает на минимальной частоте.

Я хочу не иметь сильных тормозов даже при нагруженном CPU

> Линукс используется на меньшинстве.

Мой парсер русского языка выпал в кору.

> У тебя (наверняка) нет 1 000 000 000 рублей. Смирись.

Я где-то демонстрировал дикую попоболь по этому поводу?

Я хочу не иметь сильных тормозов даже при нагруженном CPU

Ты тоже из тех, кто смотрит фильм, слушает музыку и играет?

Давай уж просто скажи, что тебе нравится возиться с линуксом. Тут все свои, всё поймут: многие сами такими были. Но к сожалению, решения о том, каким линуксу быть принимают другие люди.

Ну с никому ты погорячился, вот уважаемому товарищу cvs-255 оно таки нужно...

Так это ближе к религии, как тулкитофобия :)

> Так это ближе к религии, как тулкитофобия :)

Трудно не согласиться. Но как один из этапов развития линуксоида - вполне нормально. Главное - вовремя перерасти.

Ты тоже из тех, кто смотрит фильм, слушает музыку и играет?

в том числе и это. А еще иногда что-то численно решаю.

А еще иногда что-то численно решаю.

Я, прикинь, науку делаю на P-M 1733. Не хочешь, чтобы тормозило, ставишь nice 10, 15 или 19 численным расчетам и наслаждаешься быстрой работой всего.

Главное - вовремя перерасти.

и перейти на Ъ-ынтырпрайз?

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

Не хочешь, чтобы тормозило, ставишь nice 10, 15 или 19 численным расчетам и наслаждаешься быстрой работой всего.

тут не только в nice дело. тут еще нужна оптимизация. И если оптимизацию алгоритма расчета я могу взять на себя, то бинарную библиотеку я заточить под мой atom не могу.

то бинарную библиотеку я заточить под мой atom не могу

У меня фейспалм тут. Если нужно считать, то почему бы не взять процессор побыстрее?

Если нужно считать, то почему бы не взять процессор побыстрее?

Потому что компьютер с ним стоит далеко и его еще везти надо. А к нему еще монитор.

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

как это будет выглядеть....

ну это когда загрузчик ОС ставится не на /dev/sda, а на /dev/sda1. А на /dev/sda сидит основной загрузчик который уже вызывает загрузчики других ОС.

Потому что компьютер с ним стоит далеко и его еще везти надо. А к нему еще монитор.

ssh не решает? Черт, даже у меня был доступ к универскому кластеру, хотя он мне и не нужен.

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

Тада ок, в этом случае пересборка библиотеки имеет смысл. Но я бы все равно с профилирования начал

без remount как в initrd

в смысле без pivot_root? А разве это проблема?

отлавливать падения systemd

оно падатать умеет? O_o Или это теоретически? Вообще, боюсь, с этим будет не просто ибо, скорее всего, оно хочет pid=1. Т.е. если init сдох то это хана. Или systemd не подменяет init?

ну это когда загрузчик ОС ставится не на /dev/sda, а на /dev/sda1. А на /dev/sda сидит основной загрузчик который уже вызывает загрузчики других ОС.

А, да, я тоже об таком подумал когда начал обдумывать ситуацию «диск отвалился». Но я подумал о том что в /dev/sda1 сидит такой же chainloader и грузится он из другого chainloader'а или из биоса.

Так как да, раз мы такой штукой заморачиваемся, значит тогда надо все по уму делать. А значит надо делать возможность загружатся в rescue если мастер диск физически отвалился, например. А тогда такое будет весьма кстати - биос нам загрузит rescue с того девайса что не отвалился. А дальше мы по ssh уже поправим, или еще как.

ssh не решает? Черт, даже у меня был доступ к универскому кластеру, хотя он мне и не нужен.

живу в другом месте, чем обычно & медленный интернет & дома компьютер (как и все у меня в комнате, кроме модема, ибо родители) выключен.