systemd или openrc? (отрезано от "Давно не работала с gentoo")

[fragment]

- systemd слишком большая.

Ну и что это? аргумент разве?

systemd пытается включить в себя функционал не просто загрузки, но и заодно init, cron, at, inet, ConsoleKit, sethostname, modprobe, mount -a ( и это неполный список ).

Потому что это не система инициализации, а комплекс администрирования системы.

это приводит к тому, что в systemd более чем на порядок больше кода, чем в systemV init. где вероятность ошибки больше?

Ну офигеть теперь. Давайте сократим все программы до "Hello, world!", зато багов не будет.

и куда внезапно делся принцип "Write programs that do one thing and do it well"?

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

- systemd не поддерживает shell скрипты. т.е. ваш собственный невероятно нужный именно вам хак теперь не так просто запихнуть в систему

Это просто ложь. У меня в /etc/local.d лежал баш-скрипт, при переходе на systemd он был подхвачен в загрузку автоматом и преспокойно функционирует.

- оно просит dbus. нет, серьёзно? система загрузки просит D-Bus? Desktop-bus? ну ок, ещё можно попытаться притянуть за уши какое-нибудь объяснение для десктопной машины, но зачем оно нужно на сервере?

А sysvinit тянет bash. Вас это не смущает?

- про systemd и Plymouth слышали? как ваши впечатления?

Что-то слышали краем уха. Не думаю, что это проблема вселенских масштабов. Тем более, что с systemd увидеть бутсплэш юзер просто не успевает.

если вам этого мало, почитайте обсуждения: debian systemd debates, слака и systemd, arch и systemd, гентушное обсуждение.

Нет, мне это не нужно. Я спрашивал про конкретные проблемы у пользователей конкретно этого форума.

[cut]

Кстати о dbus. Скоро его выкинут в пользу kdbus, так что у systemd станет одной зависимостью меньше.

[/dev/random]

А sysvinit тянет bash. Вас это не смущает?

Сходите, почитайте, что такое sysvinit, и почему он никакого баша не тянет.

[fragment]

А sysvinit тянет bash. Вас это не смущает?

Сходите, почитайте, что такое sysvinit, и почему он никакого баша не тянет.

На Опеннете, видимо, ламеры сидят, если пишут такое:

Другой проблемой SysVinit является её зависимость от множества достаточно тяжёлых и не очень быстрых приложений - bash, awk, sed и других, которые не отличаются скоростью работы на встраиваемых системах.

[drBatty]

- systemd слишком большая.

Ну и что это? аргумент разве?

безусловно.

systemd пытается включить в себя функционал не просто загрузки, но и заодно init, cron, at, inet, ConsoleKit, sethostname, modprobe, mount -a ( и это неполный список ).

Потому что это не система инициализации, а комплекс администрирования системы.

почему этот комплекс нельзя установить дополнительно? Почему его обязательно нужно вместо инита ставить?

это приводит к тому, что в systemd более чем на порядок больше кода, чем в systemV init. где вероятность ошибки больше?

Ну офигеть теперь. Давайте сократим все программы до "Hello, world!", зато багов не будет.

это демагогия.

и куда внезапно делся принцип "Write programs that do one thing and do it well"?

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

потому что Windows Must Die.

А sysvinit тянет bash. Вас это не смущает?

меня смущает ваша аргументация. И не поспоришь жеж!

[drBatty]

На Опеннете, видимо, ламеры сидят, если пишут такое:

Другой проблемой SysVinit является её зависимость от множества достаточно тяжёлых и не очень быстрых приложений - bash, awk, sed и других, которые не отличаются скоростью работы на встраиваемых системах.

видимо -- да. Если тамошние ламеры предлагают менять хорошо отлаженную sed на какой-то новый NIH велосипед, который ещё неизвестно как и куда поедет(если поедет, конечно).

[/dev/random]

На Опеннете, видимо, ламеры сидят, если пишут такое:

Другой проблемой SysVinit является её зависимость от множества достаточно тяжёлых и не очень быстрых приложений - bash, awk, sed и других, которые не отличаются скоростью работы на встраиваемых системах.

Что ж, я вам расскажу. В нормальных дистрибутивах init и система rc-скриптов - это совершенно разные программы. "Делай одно дело, и делай его хорошо".
sysvinit - это компактная программа на C, которая при загрузке или смене runlevel'а запускает программу, прописанную в /etc/inittab. Что это за программа, на чём она написана и что будет делать - не его дело. Обычно она выполняет инициализацию/финализацию сервисов и завершает свою работу. В debian это шелл-скрипт "/etc/init.d/rc", в gentoo - написанная на C OpenRC. Можете написать что-то своё.

[fragment]

sysvinit - это компактная программа на C, которая при загрузке или смене runlevel'а запускает программу, прописанную в /etc/inittab. Что это за программа, на чём она написана и что будет делать - не его дело. Обычно она выполняет инициализацию/финализацию сервисов и завершает свою работу. В debian это шелл-скрипт "/etc/init.d/rc", в gentoo - написанная на C OpenRC. Можете написать что-то своё.

Разве это важно? Суть такова, что sysvinit-инициализации (включая и обсуждаемый openrc) нужен баш с его группой поддержки.

[SLEDopit]

Ну и что это? аргумент разве?

А лишняя секунда, сэкономленная при загрузке раз в год это аргумент, чтобы перелопачивать полсистемы?

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

Потому что gnu/linux системы строятся по подобию unix. И пытаются соблюдать философию и идеологию unix. Почитайте что-нибудь в духе "The Art of Unix Programming". Там написано, почему и зачем стоит соблюдать эти принципы.
А то с вашими рассуждениями можно дойти до монолитного ядра и всего юзерского софта в нём же. Что уж мелочиться.

Это просто ложь. У меня в /etc/local.d лежал баш-скрипт, при переходе на systemd он был подхвачен в загрузку автоматом и преспокойно функционирует.

Ок, согласен, можно соорудить конструкцию в духе

Код: Выделить всё

$ cat /etc/systemd/system/whatever.service
[Unit]
Description=whatever
[Service]
ExecStart=/path/to/script
[Install]
WantedBy=me.target

[/dev/random]

Разве это важно? Суть такова, что sysvinit-инициализации (включая и обсуждаемый openrc) нужен баш с его группой поддержки.

Конечно. Debian'овские скрипты уже давно обходится легковесным dash'ем, а OpenRC - так и вовсе работает в любой POSIX-совместимой системе, обходясь её обязательными по стандарту компонентами, включая любой POSIX-совместимый шелл. Кроме того, вы можете написать себе что-нибудь и вовсе бесшелловое. Если бы ваш любимый systemd был написан просто как бесшелловая rc-система, не пытающаяся строить из себя мегакомбайн и затычку в каждой бочке, против него никто бы слова не сказал.

[fragment]

А лишняя секунда, сэкономленная при загрузке раз в год это аргумент, чтобы перелопачивать полсистемы?

Если бы при переходе нужно было перелопачивать полсистемы, я бы даже и не подумал переходить. И да, там не секунда, а десяток секунд.

Потому что gnu/linux системы строятся по подобию unix. И пытаются соблюдать философию и идеологию unix.

Это не аргумент. Точнее, это не рациональный аргумент, это больше похоже на догматизм.
Вот есть всякие там WM'ы, к которым можно напильником пригвоздить набор софта и всё это будет худо-бедно-смешно работать. Зато модульность и юниксвей во все поля. А можно поставить, например, KDE, большинство частей которого неотпиливаемы друг от друга, и получить мощную и комфортную рабочую среду.
Или ещё пример: LVM+mdadm+$any_FS vs ZFS (или BtrFS). Благодаря тесной интеграции аналогов указанных слева частей системы хранения данных, указанные справа, имеют недостижимые для левых возможности.
Так что, опять же: тесная взаимоинтеграция имеет свои плюсы. А вы: "юниксвей, одна программа - одна задача...".

А то с вашими рассуждениями можно дойти до монолитного ядра и всего юзерского софта в нём же. Что уж мелочиться.

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

[fragment]

Конечно. Debian'овские скрипты уже давно обходится легковесным dash'ем, а OpenRC - так и вовсе работает в любой POSIX-совместимой системе, обходясь её обязательными по стандарту компонентами, включая любой POSIX-совместимый шелл.

Стандарты сегодня одни, завтра - другие.

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

Вы так говорите, будто конечная цель проектов - получить одобрённые возгласы по форумам.
Леннарт делает беспрецедентные вещи, и что с того, что всегда находятся полуботы с их "нинужно!11111"? Он делает нужные вещи, приносящие в Линукс комфорт.
Подобный вой был, когда в Линукс продвигали Udev с HAL. Мол, зачем это нужно, у меня и так всё нормально монтируется ручками в консоли

[/dev/random]

Стандарты сегодня одни, завтра - другие.

Это не повод их игнорировать.

Подобный вой был, когда в Линукс продвигали Udev с HAL. Мол, зачем это нужно, у меня и так всё нормально монтируется ручками в консоли

HAL благополучно сдох, а по поводу введения udev воя не было, только по поводу недавних изменений.

[fragment]

Это не повод их игнорировать.

Ровнот так же нет повода слепо их соблюдать в ущерб делу.

HAL благополучно сдох, а по поводу введения udev воя не было, только по поводу недавних изменений.

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

[/dev/random]

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

А можно ссылочку? А то, ЕМНИП, udev как раз поднялся на волне воя по поводу (тоже, как и HAL, благополучно издохшего) devfs, как более адекватное решение той же проблемы.

[Bizdelnick]

fragment
Задача.
Дано: демон atd рекомендуется запускать с опцией -l <N>, где <N> следует выставлять выше, чем число процессорных ядер минус единица.
Требуется: написать systemd-сервис, который бы запускал atd, следуя этой рекомендации.
Слабо сделать это с помощью вашего "гибкого" бесшеллового systemd?

[fragment]

А можно ссылочку?

Жжоте.

Bizdelnick, а у вас возникли какие-то трудности?

[yars]

а у вас возникли какие-то трудности?

Уход от ответа detected.

[fragment]

а у вас возникли какие-то трудности?

Уход от ответа detected.

А вы рассчитывали, что я тут же ломанусь писать ему service-файл? Ага, ага.

[/dev/random]

Жжоте.

А что такого-то? Архивы рассылок с тех пор должны были сохраниться, да и многие нынешние форумы тогда уже существовали. LOR, например. Если вой был, то он наверняка должен был оставить след в рассылках и форумах, ведь так?

[drBatty]

Разве это важно? Суть такова, что sysvinit-инициализации (включая и обсуждаемый openrc) нужен баш с его группой поддержки.

не нужен. Хотя вполне можно и bash. А ваше мнение про "тормоза баша" == полный бред и враньё. Over9000 раз уже говорил, что слака с ssd стартует тоже очень быстро. Хоть там всё на баше, и даже не sysvemV, а ещё более древняя bsd-like.

Если бы при переходе нужно было перелопачивать полсистемы, я бы даже и не подумал переходить. И да, там не секунда, а десяток секунд.

4.2
слака примерно за секунду грузится без всякого systemd.

например, KDE, большинство частей которого неотпиливаемы друг от друга,

4.2
в слаке отпиливаемы.

Так что, опять же: тесная взаимоинтеграция имеет свои плюсы. А вы: "юниксвей, одна программа - одна задача...".

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

Стандарты сегодня одни, завтра - другие.

дык о том и речь, что SysV поддерживает _любые_ стандарты. Не обязательно bash, и не обязательно posix sh.

Подобный вой был, когда в Линукс продвигали Udev с HAL. Мол, зачем это нужно, у меня и так всё нормально монтируется ручками в консоли

передёргиваете. Ручками в консоли и сейчас монтируется точно также.

[fragment]

Жжоте.

А что такого-то? Архивы рассылок с тех пор должны были сохраниться, да и многие нынешние форумы тогда уже существовали. LOR, например. Если вой был, то он наверняка должен был оставить след в рассылках и форумах, ведь так?

Ну вот, пожалуйста вам, обсуждение грядущего udev: http://www.linux.org.ru/news/kernel/451695

Цитаты:

в lkml такой флейм поднялся по поводу "Какого фига убрали девфс! Я его люблю верните суки!"

Столько геморроя (devfs, теперь вот udev) - и все ради чего? Чтоб лемминги, которым команда mknod кажется слишком сложной для понимания, чувствовали себя хорошо. "/dev is too big" - нет слов.

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

[drBatty]

а у вас возникли какие-то трудности?

дык какие трудности? Что-то типа

Код: Выделить всё

#!/bin/bash

K=$(sed -n '/^processor/h;${g;s/.* //p}' /proc/cpuinfo)
atd -l $K

[/dev/random]

!	Предупреждение от модератора
	fragment, eddy, я вновь вырезал ваши оскорбления в адрес друг друга. Это последнее устное предупреждение.

[eddy]

HAL благополучно сдох

И это — к лучшему. Помнится, когда HAL переживал свои "лучшие" времена, я спокойно сидел на стареньком ASP и в ус не дул! А потом HAL сдох, и я перешел на более свежий ASP, где уже был адекватный udev...

Интересно: когда сдохнет systemd? Этот высер как раз напоминает историю с HAL.

[jashaw5]

Это последнее устное предупреждение.

Похоже, у меня звук пропал.

[fragment]

jashaw5, это у вас пульсаудио отклеился.

[yars]

А вы рассчитывали, что я тут же ломанусь писать ему service-файл? Ага, ага.

Ну так drBatty вам init-скрипт показал, а systemd'овцам, видать, слабо то же самое сделать без костылей

[jashaw5]

jashaw5, это у вас пульсаудио отклеился.

Неа, это голос у /dev/random тихий.

[/dev/random]

Ну вот, пожалуйста вам, обсуждение грядущего udev: http://www.linux.org.ru/news/kernel/451695

Хех, и правда, немного пофлеймили. С холиваром о systemd это, конечно, не сравнится, но всё же.

[Bizdelnick]

Bizdelnick, а у вас возникли какие-то трудности?

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