Sabayon 15.10

Но со сторны фанатиков аргументация еще хуже: «портянки на bash скриптах !!!» Ниосиляторы ? Да посмотрите на OpenRC: init скрипты логичнее и куда более гибки чем ваши юниты. Скорость загрузки/выключения - ВАУ, вот жеж главный плюс ! Школьники на локалхостах, молчите лучше. «Ретрограды ! Вы тормозите прогресс !!!» -знание истории и здоровый прагматизм никогда не бывают лишними.

Ты побольше слушай «фанатиков».

Ключевые преимущества systemd совершенно другие, и они будут тебе видны только в том случае, если ты не админ локалхоста — а, например, пишешь софт, образующий инфраструктуру юзерспейса. Или если ты разрабатываешь дистрибутив со средствами автоконфигурации и массового развёртывания. Или если у тебя тысячи однотипных контейнеров, которые должны запускаться on-demand за миллисекунды.

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

Короче, не стоит махать своим невежеством.

Только у генты хватило комьюнити

Лучше бы у них хватило комьюнити закрывать критичные баги и недоделки в пакетах.

Эту техническую проблему уже давно исправили. По ссылке выше, которую я приводил, Линус прямым текстом сказал, что несмотря на разногласия с «некоторыми мейнтейнерами», значительных технических претензий к systemd он не имеет.

Повторяю вопрос — кто будет выступать мерилом качества исполнения?

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

Ты же высказывался про качество? Вот Линус тебе и мерило.

Возможно ли использовать udev без systemd?

Да.

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

Нет. Ещё раз, read the fucking dictionary. Смешно, чесслово.

Над чем смеемся? Возьмем определение из вики, пойдет?

In economics, vendor lock-in, also known as proprietary lock-in or customer lock-in, makes a customer dependent on a vendor for products and services, unable to use another vendor without substantial switching costs.

И что не так? Это именно то, к чему идет Редхат, Поттеринг и Ко. Если тебе это не понятно - то ты или наивен, или лжец.

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

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

Короче, не стоит махать своим невежеством.

Как двусмысленно грубо и пошло. Тебя в школе случайно не обижали?

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

Я повторяю вопрос в третий раз: чьё мнение о качестве|некачестве systemd мы будем принимать за безусловно верное, и почему мы будем его принимать за безусловно верное?

Ты же высказывался про качество? Вот Линус тебе и мерило.

Линус? Ну допустим.

<...> I don't really get the hatred of systemd. I think it improves a lot on the state of init <...>

<...> I much prefer systemd's infrastructure for starting services over traditional init, and I think that's a much bigger design decision. <...>

<...>I've had some personality issues with some of the maintainers, but <...> If people thought that meant that I dislike systemd, I will have to disappoint you guys. <...>

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

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

Над чем смеемся? Возьмем определение из вики, пойдет?
In economics, vendor lock-in, also known as proprietary lock-in or customer lock-in, makes a customer dependent on a vendor for products and services, unable to use another vendor without substantial switching costs.
И что не так?

А вот что не так. systemd и его разработчики не делают «a customer dependent on a vendor». По одной простой причине: код systemd открыт для изучения и изменения любым человеком, а не только конкретным вендором.

бла-бла-бла-баззворд-бла-бла

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

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

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

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

Как двусмысленно грубо и пошло.

Не-а. Совершенно недвусмысленно грубо и пошло.

Никогда не поверю, что ты тут на всех форумах втираешь безвозмездно

типичная тупая истеричка из стана фанатиков-хейтеров)

иди доучивайся в своё ПТУ

Ну естественно — мне RH приплачивает и лично Поттеринг. Вон, аж на systemd.conf 2015 позвали за казённый счёт.

Ну так отрабатывай теперь!

Все остальные же втирают безвозмездно.