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

Ну тогда исправлять что-либо — вообще сложно. Нужно же сначала понять почему оно поломалось. А для этого надо

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

Типа если зависимости захардкодили в бинарь, то парится не надо, так штоле?

Может, перед такими заявлениями стоит ознакомиться с матчастью?

Лицоладонь.

Конечно отказались. Потому что кроме тупого перезапуска оно ничего больше и не может делать. Впрочем, для tty это подходит

Реверсить - это не сложно?

Для начала, какое отношение реверс имеет к теме разговора?

Ну, может быть Или разницы больше чем копирование выхлопа компилятора?

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

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

А что ты обычно в скрипты такое добавляешь?

Поттеринг сообщал о 2 сек загрузки с SSD, от граба до рабочего стола.

Слабак.

Загрузка за 200 миллисекунд

20 - это много.

У меня, например: DAEMONS=(syslog-ng acpid fakemac @network crond @dbus laptop-mode @alsa @cupsd @cpufreq @mpd)

ты не учел еще кучу, что вместе с иксами/DE запускается. Ну и список у тебя короткий очень. У меня там tor, polipo, freenet, nfs, portmap, ntp и еще какие-то.

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

ну согласись, что твой вариант - это далеко не среднестатистический.

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

Я не вижу в процессах принципиальной разницы. Расскажи мне, какой видишь её ты

А профит от systemd именно в том, что не надо никаких зависимостей прописывать и париться по этому поводу.

Чего? И куда волшебным образом делись зависимости? Типа если зависимости захардкодили в бинарь, то парится не надо, так штоле? :D

в бинарь никаких зависимостей не хардкодят. Бинарь просто втупую создает все сокеты, которые нужны и все. И если кто-то сокет хочет перенять, то он ему отдает. АФАИК.

sysv init мог это уже много лет. Но от этого отказались.

не мог он этого. Он только рестартовать втупую мог.

Я не вижу в процессах принципиальной разницы.

Расскажи мне о том, какую разницу ты считаешь принципиальной.

Расскажи мне, какой видишь её ты

Я (и вообще любой) видит эту разницу как «nano vs wget + C toolchain».

Тогда просто никто никуда не торопился :}

Угу, и в 90-х никто не торопился, и в 2000-х никто не торопился, а в 2010-х все вдруг ТАК заторопились. :)

Фигню какую-то ты приводил.

Не видишь разницы между 132 строками на баше и 476 (можно смело умножать на 3 или 4, поскольку это только враппер для shutdown) строками на C? Ну тогда мне остаётся только пособолезновать…

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

фигли там знать? баша и базовых знаний ключей достаточно.

А что ты обычно в скрипты такое добавляешь?

ну когда-то добавлял например, чтобы при fsck progress bar показывался. потом исправлял последовательность проверки/монтирование сетевых дисков. Сетевые скрипты правил. Это правда все на мандрейке/мандриве еще было.

В арче недавно чинил монтирование /usr.

да мало ли что может понадобиться.

как будто systemd чтото изменит..

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

Видимо, потому, что это личный проект самого Леннарта?

Принципиальная разница - это когда эта самая разница существует в процессе получения исходных данных (наличие/отсуствие принципиальной возможности получения субъектом), анализа исходных данных (наличие/отсуствие принципиальной возможности осознания субъектом смысла написанного), модификации исходных данных (наличие/отсутствие принципиальной возможности модификации субъектом), модификации рабочих данных (наличие/отсутствие принципиальной возможности модификации субъектом)

Например. Бут ром какого-нибудь SoC нельзя пофиксить на лету. BIOS/EFI какого-нибудь вендора может пофиксить только работник этого вендора, но не может пофиксить пользователь. Логику загрузчика какого-нибудь DSP легко пофиксить девелоперу в конторе, но сложно пользователю. Скрипты на баше на каком-нибудь тивоизированном андроиде с TrustBoot невозможно пофиксить пользователю. Итп. Вот это - принципиальная разница.

А при возникновении жопы при наличии инфраструктуры выкачать/собрать/задеплоить или пофиксить с nano — это не принципиальная разница.

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

Из всей информации о системд мне интересны лишь команды запуска/остановки/включения/отключения демона

systemctl start blablabla.service/systemctl stop blablabla.service/systemctl enable blablabla.service/systemctl disable blablabla.service

...просмотра списка работающих/всех демонов

systemctl/systemctl --all

...просмотра статуса демона

systemctl status blablabla.service

(наличие/отсуствие принципиальной возможности получения субъектом)

Реверси зашифрованный сетевой трафик.

В пятницу этим занимался, спасибо )

Конечно отказались. Потому что кроме тупого перезапуска оно ничего больше и не может делать. Впрочем, для tty это подходит

Никто не мешал это развивать - но все пошло в противоположном направлении. Перешли на скрипты, ага :D

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

Может, перед такими заявлениями стоит ознакомиться с матчастью?
Лицоладонь.

Послылать на**й^Wчитать доки я и сам умею. Можете аргументированно продемонстрировать что именно в системд работает не как «закодировали зависимости в бинарь»? :D

В пятницу этим занимался, спасибо )

Я вижу, ты до сих пор еще не отошел %)

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

перенять, то он ему отдает. АФАИК.

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

не мог он этого. Он только рестартовать втупую мог.

Подпроцесс там тоже висел на специальном файле - например на /dev/ttyXX, что указывалось в конфиге init. Эту схему можно было развить, больше внимание уделяя файлу. Но от нее отказались.

Спасибо тебе, добрый человек.

Ну да, но systemd нужен тем, кто использует тысячи нену^Wдефолтных сервисов, поставляемых дистрибутивом. О чем и речь.

В обычной жизни всегда можно запускать 5-7 сервисов последовательно, остальные - в фоне. :)

В скриптах нет ничего плохого, но оно походу мотивирует к eval-hell и отсутствию API.

Оно мотивирует к этому потому что задача сложная. Инискрипты это не «просто ещеодин системный компонент». Это попытка вынести сложности, конфигурируемость и неясности в glue код. Что бы упростить жизнь авторам демонов.

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

Именно что в противоположном. У sysv init были *ВСЕ* задатки systemd это был мегакомбайн по тем временам -как systemd сейчас. Но вместо его развития как мегаглючной тулзы на Си которая бы роняла систему, на это забили и перешли к использованию скриптов. При этом функционал в демоне свели к минимуму.

Ну да, но systemd нужен тем, кто использует тысячи нену^Wдефолтных сервисов

Что мешает это делать без systemd?

Да ничего не мешает. Просто надо будет немного подзапариться с настройкой, то есть иметь голову и руки, от чего, если верить ТС, избавляет systemd.

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

Тут, разумеется, можно отметить, что дело совсем не в скриптах, а в общем разброде. Но вот предпосылки к ликвидации этого можно отметить в критикуемом «комбайне» )

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

что прочее? Как он может сфейлить? тривиальная задача собсно. Как и в xinetd.

Ну да, но systemd нужен тем, кто использует тысячи нену^Wдефолтных сервисов, поставляемых дистрибутивом. О чем и реч

В обычной жизни всегда можно запускать 5-7 сервисов последовательно, остальные - в фоне. :)

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

И я уже выше писал, что не получается просто так в фоне пускать. Все равно проигрышь.

Хорошо, почему Леннарт не поручил организацию проекта более компетентному координатору? Почему хотя бы не создал координационный совет из нескольких людей? Делегирование - благо.

Его же ярое желание быть вторым Торвальдсом вкупе с отсутствием должных навыков только тормозит развитие systemd. Оно же - причина ненависти: когда Леннарт единолично решает впаять в своё детище бинарный лог, на ходу придумывая причины, или же гонится за какими-то призрачными целями вроде запуска системы за 2 секунды, которые восхищают только админов локалхоста и маркетологов ООО «Микрософт».

Он вообще очень любит себя. Исходя из последних статей можно подумать, что его фамилия - «Поттеринг, создатель avahi и PulseAudio».

(2n)!

Такая проблема не решится уменьшением времени исполнения в O(2) раз за счёт перехода sh->c.

Если верить ссылке на вики в 3-ем посте, у Systemd есть лишь одно «преимущество» перед OpernRC - предварительное создание UNIX-сокетов. Но правильно ли такое поведение в случае, если таймаут ожидания клиентом меньше времени запуска сервиса? В этом случае клиент завершится с ошибкой и в лучшем случае потребуется его перезапуск.

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

в том-то и вкусняшка, что не завершится, ибо будет висеть в IO-wait, после того, как буфер заполнит.

dikiy> А профит от systemd именно в том, что не надо никаких зависимостей прописывать и париться по этому поводу. Причем вполне возможно, что если A зависит от B, а от B зависит еще куча всего, A запускается долго, то придется ждать кучу времени, хотя за это время можно было запустить десятка два зависящих процессов.

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

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

Ну я рад за них, что они знают. Точно так же я знаю, что они мне не нужны.

Я и написал выше, что когда я встречу систему, которая при наличии 20+ сервисов работает с systemd лучше, я воспою ему хвалебные оды.

p.s.: Я говорю про десктоп-онли, про серверы не мне судить, админством не занимался.

quiet_readonly> Ок, не может. Легче стало? Вон инфра-ресурс тоже твердили, что libreoffice не взлетит и просто ужасно злились, истекая слюной. Посторонние люди на их форуме просто спрашивали, не планируется ли переход на либру, а они чуть ли не матом отвечали.

У LibreOffice есть реальные преимущества и отсутствуют недостатки OOo. У systemd же - недостатки перевешивают преимущества. Ну ежели разработчики OOo из Инфра-Ресурса себя так ведут - ну чо, не будем мешать мудакам терять рынок.

quiet_readonly> Просто некоторым очень, очень больно признавать, что проблемы надо решать на корню

Просто некоторые начинают раздувать проблему там, где её нет. Так и появился systemd.

К слову о приросте скорости загрузки:

Пол минуты - уже достаточно, чтобы о скорости загрузки не беспокоиться дальше. На мой взгляд самыми главными тормозами загрузки (возьмём условия обычные, без проверки ФС) являются тяжёлые графические среды и прошивка компьютера (BIOS, EFI, ...). Так что про измерения скорости загрузки можешь у фанбоев systemd даже не спрашивать - они в этих вопросах разбираются не более, чем фанбои вяленда в иксах и их расширениях (то есть - вообще никак не разбираются).

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

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

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

Но вторым Торвальдсом он при этом не будет, потому что just-for-fame != just-for-fun.

Ага, я так и сделал на новом ноуте и получил загрузку почти за секунду. Понятно, что в это вложились i5 и SSD, но все же.

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

в том-то и вкусняшка, что не завершится, ибо будет висеть в IO-wait, после того, как буфер заполнит.

Я прочёл это. Но не для всех сервисов это может быть приемлемо. К примеру, клиент думает, что сервер запущен и отсылает ему запрос вместе с временной отметкой. Сервер, когда будет запущен, смотрит на отметку, которая на 23 секунды отличается от текущего времени и даёт отказ клиенту. Этой ошибки бы не произошло при последовательной загрузке. Если это опция, тогда нормально.

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

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

Короче, у systemd ровно один недостаток: его написал Леннарт, а люди привыкли ругать творения Леннарта.

Тестил systemd на арче. По сравнению со стандартым bsd-style init грузится быстрее секнд на 5. В остальном ничего необычного. Никаких минусов не заметил, как и других плюсов. Если его сделают в арче по дефолту горевать не буду.

Сколько можно тырить из макоси.

Угу. А ещё там написано: «portable on non-linux: NO». При этом непортируемость вызвана, например, использованием cgroups, причём это конечно же тихонечко замалчивается и в преимущества systemd никак не записывается, что вы, только в недостатоки. Статью писали фанаты openrc, что естественно. А вот выискивать преимущества systemd именно там как-то неестественно.

Я погуглил перед написанием поста, якобы cgroups интегрировать можно не только в Systemd.

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