давайте разберемся, так ли плох systemd?

Всё в одном файле - это прямо как BSD Init. Негибко и засрать легко.

franchukroman> Оно ничем не лучше systemd. + оно не имеет и малой части фич systemd.

Вот этим оно лучше, чем systemd - не пихали туда что попало.

Чушь несёшь ты. Есть компоненты системы, а есть - пользовательские приложения. systemd никак ко второму не относится. Но да - сейчас ощущается нехватка UNIX-Way в приложениях. И это очень нехорошо.

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

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

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

gentoo_root> Это заботы мейнтейнеров дистрибутива, куда класть какие библиотеки.

Нет. Это забота стандарта, куда библиотеки помещать. А ты, блин, опять чушь порешь.

Тенденция ухода от текстовых терминалов сама по себе неплоха (подразумеваются телетайпы). Они устарели уже давно. Вопрос в том, в какую сторону уходить. Вот в Plan9 в верно направлении пошли - вместо телетайпов сделали устройства консолей (и не обязательно текстовых).

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

в Plan9 в верно направлении пошли

И капитально сломали цвета в терминала (впрочем, в plan9 терминалов как таковых нет из-за упоротости девелоперов файлами).

Если ты ставишь systemd и у тебя система начала лучше работать - значит с системой было что-то не так изначально.

Я вполне согласен — там не было нормальной системы управления демонами. Были лишь какие-то говноскрипты на баше, полностью состоящие из костылей, которые даже не могли нормально убить демоны, потому что они полагались на pid-файлы. Это не говоря о том, что они ещё и почти каждой строчкой запускали по несколько новых процессов, когда их можно не запускать.

И systemd оказался всего лишь костылём

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

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

Initramfs придумали для того, чтобы смонтировать корень, когда это не может сделать ядро. Потом она ещё и стал монтировать /proc, /sys и /dev (она всё равно их монтирует, не нужно их размонтировать, чтобы опять смонтировать). В более общем случае initramfs готовит файловую систему, чтобы ей мог спокойно пользоваться юзерспейс, поэтому нет ничего плохого в том, чтобы монтировать /usr оттуда. А костыль здесь — само наличие /bin, /sbin и /lib, когда можно всё положить в /usr/bin, /usr/sbin и /usr/lib и это удобнее. Как раз положить бинарники в корень только для того, чтобы запускать их, пока не вся ФС доступна — это костыль, потому что нефиг вообще запускать что-то, пока не готова ФС.

Нет. Это забота стандарта, куда библиотеки помещать.

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

ААА, посмотрел исходники, ОНО ЧЕРЕЗ autotools КОНФИГУРИЦЦАА!

Будто это что-то плохое.

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

Если ты проапгрейдил стабильный 80486SX-33 до Core i7 и система начала работать отзывчивей, значит, с ней было что-то не так изначально. Core i7 оказался всего лишь костылем (который в любом момент может сгореть), подперевшим фундаментальную проблему проектирования дистрибутива.

ААА, посмотрел исходники, ОНО ЧЕРЕЗ autotools КОНФИГУРИЦЦАА!

Только ручная правка мейкфайлов, только хардкор!

потому что нефиг вообще запускать что-то, пока не готова ФС.

Полнейший бред. Процедура начальной загрузки по этому и называется bootstraping ака «вытягивание самого себя за шнурки» - потому что там все это в той или иной мере «запуск чего-то пока не готова ФС».

Более того /bin /sbin не исчезли фактически, их тупо заменил initrd, с утерей многих функций. Так как именно эти функции /bin & /sbin выполнял - специфического мелкого раздела где лежит нечто что нужно что бы запускать «пока ФС не готова».

Более того /bin /sbin не исчезли фактически, их тупо заменил initrd, с утерей многих функций.

Интересно, какую же это мегаполезную функцию, нужную для загрузки, выполняют /bin и /sbin, которой нет в initramfs?

Так как именно эти функции /bin & /sbin выполнял - специфического мелкого раздела где лежит нечто что нужно что бы запускать «пока ФС не готова».

Получается дублирование функциональности. Если нет initramfs, то в теории систему может загрузить то, что находится не в /usr. Но если без initramfs не обойтись (в случае LVM, например), то теперь функции монтирования ФС уже выполняет initramfs, а реализация из корня не используется. В большинстве дистрибутивов всё равно всегда используется initramfs, поэтому необходимость делать в корне минимальную систему (которая давно уже не минимальна) для поднятия остального отпадает. В федоре правильно сделали, что выпилили её, оставив только initramfs — чтобы не было трёх разных мест, в которых лежат бинарники и одно из которых не использовалось, а осталось только 2.

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

ты не понмиаешь чтоли? Данный интервал все равно программа зписать не смогла бы :) А так запишет из буфера.

Интересно, какую же это мегаполезную функцию, нужную для загрузки, выполняют /bin и /sbin, которой нет в initramfs?

В / есть удобство поправить процедуру загрузки при необходимости, например. Есть возможность получить нормальную консоль с bash. Гораздо проще прикрутить сеть (sshd). В initrd свое отдельное, кривое окружение - урезанные библиотеки и прочее.

Получается дублирование функциональности.

Да, получается. Просто 95% тех кто орет «/bin ненужен» имеют в виду что ненужны именно функции которые он выполняет. А IRL все наоборот - функции как раз никуда не делись.

чтобы не было трёх разных мест, в которых лежат бинарники и одно из которых не использовалось, а осталось только 2.

Я рад что вы упомянули «бинарники которые не используются». Ведь initrd это именно бинарники которые не используются, кроме десятка секунд во время загрузки.

Собственно /bin, это такой initrd где конструкторы пошли еще дальше - исключили дублирование кода и отдельную систему для загрузки. Если вы хотите использовать программу не только в фазе работы, а еще и в фазе загрузки - вы размещаете ее в /bin . Собственно /bin это такой initrd который все время подмонтирован и не ведет к дублированию кода.

Записать не могла бы, но клиент будет считать, что сервер запущен и готов отдавать данные. В итоге клиент отправит запросы в очередь, которые не будут обработаны, что приведёт в лучшем случае к выполнению фиктивных операций клиента (а цель создания этих UNIX-сокетов как раз обратная - сократить время запуска), в худшем - к ошибке в работе всей системы или её части.
Я не говорю, что это плохо всегда, но есть такие случаи. :)

В / есть удобство поправить процедуру загрузки при необходимости, например.

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

Есть возможность получить нормальную консоль с bash.

Во многих initramfs можно даже установить breakpoint'ы, после которых появляется busybox shell. Можно и запихать bash, но это не нужно во время загрузки.

кроме десятка секунд во время загрузки.

Ничего себе у вас initramfs жирная.

Собственно /bin, это такой initrd где конструкторы пошли еще дальше - исключили дублирование кода и отдельную систему для загрузки. Если вы хотите использовать программу не только в фазе работы, а еще и в фазе загрузки - вы размещаете ее в /bin . Собственно /bin это такой initrd который все время подмонтирован и не ведет к дублированию кода.

Вот только одна проблема — чтобы получить этот чудо-bin, нужно для начала выполнить код из initramfs, который соберёт LVM. В отличие от initramfs, ядро не всегда может его смонтировать.

Нет. Это забота стандарта, куда библиотеки помещать. А ты, блин, опять чушь порешь.

В альте вот все нужное для systemd положили в /lib. /usr на отдельном разделе заводится без всяких телодвижений. Но ты можешь продолжать плакаться.

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

То, что предлагает поцеринг - это отсутствие гибкости системы

чего именно тебе не хватает в systemd? Или так, теоретизируешь на тему «а вот если мне мега-костыль понадобится...».

Теперь ещё одними user-библиотеками в /lib стало больше. «Жирнее ещё жирнее» - девиз поттеринга и его поделий, а разрабы и мейнтейнеры дистров ведутся

Теперь ещё одними user-библиотеками в /lib стало больше. «Жирнее ещё жирнее» - девиз поттеринга и его поделий, а разрабы и мейнтейнеры дистров ведутся

# du -hs /lib
226M    /lib
# du -hs /lib/systemd/
3,2M    /lib/systemd/

Ну просто жуть - целые 3.2 мегабайта. Как дальше жить.

А давайте всё свалим в папочку linux, а пользовательские приложения разложим по папочкам linux program и устроем so-hell.

А тебя, дурака, не смущает что iptables это S08, а network это S10?

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

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

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

Мне вот интересно, чем же это pid-файл костыль? Очень изящное решение даже.

чего именно тебе не хватает в systemd? Или так, теоретизируешь на тему «а вот если мне мега-костыль понадобится...».

именно так.

Мне вот интересно, чем же это pid-файл костыль? Очень изящное решение даже.

давайте разберемся, так ли плох systemd? (комментарий)

gentoo_root

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

Очень ненадёжное решение, к тому же процесс создания pid-файла разный для разных демонов, что требует написания своих костылей для каждого демона. К тому же демон может породить кучу детей, которые форкнутся и перестанут быть детьми, и их нельзя будет найти и убить.

приходилось полагаться на pid-файлы, создаваемые самим демоном, что очень ненадёжно, потому что в теории демон может записать туда лажу

в теории демон может даже rm -rf / сделать.

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

данный демон может прибить только _суперпользователь_. А суперпользователь, в отличие от пользователя, должен знать, как правильно перезапускать/останавливать демоны.

Очень ненадёжное решение, к тому же процесс создания pid-файла разный для разных демонов, что требует написания своих костылей для каждого демона.

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

в случае с RT клиентом, делать соединение на сокетах по крайней мере странно

Частный бюджетный случай запуска сервера и клиента на одном хосте.

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

Выставить буферизацию в ноль - вмешательство в приложение, а ситуация не фантастическая, а практическая.

Но я не вижу тут предмета для спора, ведь в Systemd, как я понял можно указать - какие сокеты (или для каких демонов) создавать преждевременно, а какие нет, правильно?

Просто в целом, я попрежнему не вижу преимуществ перед OpenRC. Правда немногие указывают на разницу во времени загрузки в 5-10 секунд, может это и критично для кого-то, я не спорю.

А суперпользователь, в отличие от пользователя, должен знать, как правильно перезапускать/останавливать демоны.

Apache вполне может запустить кривой cgi-скрипт, который форкнется и зависнет, а потом останется висеть после того, как apache будет убит по pid-файлу. Администратор вовсе не обязан помнить наизусть все имена cgi-скриптов на своём сервере (скрипты могут писать другие пользователи) и уж точно не обязан подбирать за демонами какашки. Система управления демонами должна работать надёжно, а не лишь бы как попало. А системный администратор не обязан выучить наизусть все исходники демона и предугадывать его поведение в любой ситуации. Гораздо проще управлять системой, когда любого демона (в том числе незнакомого) можно прибить одной командой и не нужно знать, какие процессы при каких условиях он создаёт и зачем он это делает.

Все твои аргументы притянуты за уши.

Пример с apache вполне жизненный.

решение может и не самое идеальное, но уж точно не плохое.

Оно полностью полагается на костыли, специфичные для каждого демона, которые основаны на знании его поведения. Если оно изменится, то эти костыли рухнут.

в случае с RT клиентом, делать соединение на сокетах по крайней мере странно

Частный бюджетный случай запуска сервера и клиента на одном хосте.

прошу конкретики. что они делают, и почему все происходит именно так, как ты описал.

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

Выставить буферизацию в ноль - вмешательство в приложение, а ситуация не фантастическая, а практическая.

ты даже не понял о чем я ;-] Я имел в виду буферизацию сокета.

Все твои аргументы притянуты за уши.

Пример с apache вполне жизненный.

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

решение может и не самое идеальное, но уж точно не плохое.

Оно полностью полагается на костыли, специфичные для каждого демона, которые основаны на знании его поведения. Если оно изменится, то эти костыли рухнут.

99% всех демонов ведут себя одинаково. Будь-то syslogd, acpid, tor, mldonkey или что-то еще.

оно полагается не на костыли, а на обычное поведение демона.

для них можно вполне свою обертку написать, которая cgroups заюзает.

Вот это как раз и есть костыль — для определённых демонов делать одно, а для других другое. Нужно везде использовать cgroups и не важно, systemd будет управлять им или нет.

Кстати, другой пример — bumblebee. При запуске программы через optirun, если она демонизируется, то optirun подумает, что процесс умер и остановит второй X-сервер, из-за чего программа реально умрёт. Так делают всякие вендовые программы под вайном и не только они. А если бы optirun использовал cgroups для слежения за запущенной программой, то этой проблемы бы не было. Надо будет когда-нибудь написать альтернативу optirun.

99% всех демонов ведут себя одинаково.

Это вовсе не так. Некоторые «демоны» вообще не демонизируются (для них нужны костыли вроде start-stop-daemon), некоторые демонизируются сразу, некоторые демонизируются не сразу, а только после того, как считали конфигурацию и не упали от неправильного конфига. Некоторые создают pid-файл, а некоторые не создают (ими управлять без cgroups сложнее всего, потому что если они не создают pid-файл, то надёжно создать извне его нельзя, потому что приходится использовать pidof, а демон может быть запущен несколько раз разными скриптами, например, двойной squid, поэтому pidof вернёт несколько значений, а гарантированного способа отличить pid своего демона нет). Это уже с ходу 6 возможных комбинаций, т.е. 6 возможных наборов костылей.

прошу конкретики. что они делают, и почему все происходит именно так, как ты описал.

Так я же выше написал. Сервер хранит данные за последние несколько миллисекунд, один клиент их обновляет, другой читает и пишет на hdd. Этот другой может быть перенесён на хост с сервером для экономии.

ты даже не понял о чем я ;-] Я имел в виду буферизацию сокета.

Клиент гарантированно получит отказ, не ожидая этого, вот о чём я говорю.

Клиент гарантированно получит отказ, не ожидая этого, вот о чём я говорю.

Тогда он не зависит ни от чего и клиент можно запускать не зависимо от сервера.

убедил.

Тогда он не зависит ни от чего и клиент можно запускать независимо от сервера.

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

Тогда он не зависит ни от чего и клиент можно запускать независимо от сервера.

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

если у него есть такой вариант как «отказ», то это равносильно учитыванию неготовности сервера.

В случае «отказа» может идти сообщение об ошибке в лог, что неприятно.

В случае «отказа» может идти сообщение об ошибке в лог

бида-бида. То есть одно сообщение - это проблема, а то что программа позволяет существование отказов и в то же время до зарезу хочет о них знать - это нормально, да?

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

Вроде всё рассказал, к чему только не понял... Ведь в Systemd нет проблемы просто отключить эту мегафичу!? Есть же? :)

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

ну тогда как я и говорил, пусть подождет в io-wait. Потом пусть кинет ошибку о задержанной транзакции. Ничего страшного в этом нет.

Ведь в Systemd нет проблемы просто отключить эту мегафичу!? Есть же? :)

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

Здесь читаю, что socket создаётся выборочно для демона, значит это не захардкодено для всех сервисов или же подразумевается, что для всех демонов нужно создавать эти сокеты?

я таких тонкостей не знаю. Думаю, что принудительно не надо для всех создавать.

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

какой плохой русский язык, в нем не предусмотрен встроенный динамит для отбраковки хлама.

Аналогии такие аналогии.