systemd local DoS

ecko> Из этого заявления можно предположить, что ты знаешь.

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

intelfx> Это пустые слова, которые ничего не значат. Давай конкретно по каждому случаю: определение комбайна, где (в чём) оно проявляется, как это можно исправить и почему так будет лучше.

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

Почему это постоянно переспрашивается

Потому что на данный момент не было получено ни одного удовлетворительного ответа.

если топик является примером сам по себе?

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

ecko> Давай ещё раз, без истерик и по порядку.

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

ecko> Какую выгоду из этого можно получить?

Самую прямую - устранение многообразия и монополизация. RedHat хочет поиграть в ветерана разработки UNIX. Только RedHat не учитывает, что все эти ветераны разработки UNIX или отказались от этой деятельности, или в могиле. И они там как раз потому, что более ранние принципи ведения бизнеса RedHat оказались эффективнее и полезнее для всех. Переусложнённую полурабочую систему с тонной неосиливаемой документации делать ещё выгоднее: это привязывает клиента к поставщику и вынуждает его покупать постоянную поддержку. А когда приходит время технологию заменить, то в этих случаях куча специалистов, которые способны установить и поддерживать решение в лучшем виде, оказываются не у дел, и страдает вся индустрия.

intelfx> И почему это будет лучше? сразу предостережение: нужны конкретные кейсы, в форме «может произойти сбой вот здесь, его можно исправить/обойти вот так-то, а в случае systemd он обязательно приведёт к краху системы».

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

Sunderland93> В ядре нет уязвимостей?

Ядро - это тоже не «весь остальной софт». И если взять самый базовый критичный софт, то инит займёт весьма весомую долю. Более того: оправдывать дефективность конкретного инита тем, что в ядре могут быть баги - это идиотизм в чистом виде.

intelfx> Потому что на данный момент не было получено ни одного удовлетворительного ответа.

А всё потому, что для тебя единственный удовлетворительный ответ сводится к «Хайль Поттеринг!» с зигованием.

Не имею ни малейшего желания дискутировать со слабоумными и хамоватыми людьми вроде тебя.

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

Мда.

Это ты должен ответить на вопрос, почему лучше этот набор сервисов заменить

Аргументация с моей стороны предельно простая: потому что так удобнее.

Давай конкретно по каждому случаю: определение комбайна

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

Философствовать тут не к месту. Я попросил сформулировать ответ из четырёх пунктов. Если хочешь — накидай цитат.

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

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

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

Минимализация функций и прекращение лазания в init.

Нет, ты не понял. Предложи конкретную архитектуру, которая будет иметь тот же набор фич, что и текущий PID 1 systemd, но будет более устойчивой к ошибкам. В следующей форме: «вот это мы вынесем в такой процесс, а это в ещё один, между ними устроим вот такую форму коммуникации, а в PID 1 останутся только вот эти функции». После этого предъяви кейс, когда архитектура systemd необратимо сломается, а твоя архитектура выживет.

Без таких примеров любые разговоры будут пустыми. С тем же успехом можно сказать «а давайте просто будем писать безбажный код».

Ты же с фанатиком общаешься, у него тут в соседнем «пошол в опу юниксвэй»

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

systemd local DoS (комментарий)

все эти ветераны разработки UNIX или отказались от этой деятельности, или в могиле

А как же Devuan или как его там?

с тонной неосиливаемой документации

Жаль что ты такой тупой. Хотя нет, не жаль.

вынуждает его покупать постоянную поддержку.

Вынуждает? А ничего что некоторые предпочитают гарантированный саппорт с SLA и ответственностью, а не Васяна-эникея?

страдает вся индустрия

Страдай, а мне норм.

Предложи конкретную архитектуру, которая будет иметь тот же набор фич, что и текущий PID 1 systemd

Основная проблема в том, что разработчики и любители systemd не понимают, что такое разнообразие фич в PID 1 просто вредно своим количеством. Фичи для PID 1 следует строго отбирать, а не тащить туда что ни попадя. Плюс сопутствующие утилиты, изменения в которых требуют каких-то изменений непостредственно в коде процесса, висящего c PID 1. Потому и речь о ДНК в целом.

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

емнип к варианту «сервера» это не относиться.

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

Ненене, не съезжай. Это же ты теории заговора на ровном месте выдумываешь

Я в этом говнокоде копаться не имею ни малейшего желания

Иными словами, ты понятия не имеешь, какой там код. Понятненько.

действительно нужное прямо отказался Поцеринг принимать

Например?

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

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

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

и без игр был

Тут вы не правы, с игорь у ос x как раз лучше.

вы еще забыли logd?(забыл как он там называется) и firewalld

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

Это вообще-то в топике и написано.

Очередной баг поделки поцтеринга

Мне достаточно знать тех фактов, как systemd проблемы вызывает, о которых при старых способах организации системы даже мыслей не возникало.

Два чаю этому господину. Я даже не против ненужнод на десктопе, нехай на хомяках тренируются, но тащить это в прод на сервера «это перебор»(ц) Как пример: Вариаций на тему «мляяя у меня отвалилась/не-так-работает сеть» чуть больше чем много...
PS Раз уж я написал про десктоп. launchd не страдал таким уж количеством косяков как systemd.

Леннарт Поттеринг — спаситель Linux'a! Спасибо ему за неустанный труд!

А всех хейтеров принудительно отправить на курсы по изучению systemd

с экзаменом в конце.

Бгг.

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

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

Специалистов и по офтопику дофига. Что не исключает того, что комбайн работает плохо.

Да, мучаемся сейчас с переходом на продакшне на ubuntu 16.04, потому и пошёл читать systemd треды. Причём не во всех пакетах есть нормальные юниты, где-то есть этот костыль, который в итоге дёргает инит-скрипты из юнитов, но оно тоже не всегда работает, приходится дорабатывать напильником. Вот и кому оно было надо и что я приобрету от всех этих лишних взмахов напильником?

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

>Что ж, научите меня правильно перезагружать\выключать линукс с системд, чтобы сам системд не завис как аутист и не ныл, что не может остановить юниты.
Надо правильно подключить провода от кнопки reset на мать.
В отсутствии кнопки reset подержать кнопку питания несколько секунд до выключения. Потом нажать еще раз.
При отсутствии физического доступа к оборудованию, попросить (за вознаграждение) сотрудников энергосбыта вырубить питание в том районе (о такой возможности надо договариваться заранее, просто по телефону на обещание бабла они не ведутся)

сотрудников энергосбыта вырубить питание в том районе

так резервные источники же

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

Золотые слова!

Феноменальное шлангование просто. «Сделайте мне системд, только безбажный, а если не можете - идите в жопу». Вопрос о целесообразности существования бажного комбайна (ты там выше сам признал его комбайном) даже не встает, «потому что так надо», видимо.

Неужели настолько хочется в Брно?

Так я про энергосбыт и написал. Они многое могут...
1. Если вы только про упс, то подождать. Это идеальный вариант.
2. Если про упс+генератор... Тоже умеют...
А вообще они умеют рубить что первый что второй вариант, проблемы только в потере оборудования :)
Забыл самое простое, местные электрики, это просто асы в теме перезагрузки, умеют просто все!

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

И почему это будет лучше?

Ты новость то читал вообще? :) Где ты видел, чтобы в init нашли локальную DoS уязвимость? Это раз. В systemd нечто вроде контейнеров (лол что?!), монтирования дисков, управления сетью, крон, повешены на PID 1. Если произойдёт ошибка, например в контейнерах, при загрузке то это будет означать Kernel Panic. Кстати, лично помогал другу чинить сломанное монтирование после обновления сабжа. Бинарные логи, они до сих пор не восстанавливаются если файловая система грохнется, не так ли? И ничего, что Леннарт переизобрёл С, майнтейнеры продолжают это поддерживать! Стадо такое стадо... На опеннете человек приводил пример этого «кода», со ссылкой на источник, конечно. Было что-то типа

strcat(strmem(strmem(strmem

Ну и напоследок - Леннарт изобрёл велосипед, потому что до него всё работало и даже было куча аналогов SysVInit. И если бы он не занимался агрессивной саморекламой, никто бы не принял всерьёз его systemd и GNOME бы не был прибит к нему гвоздями. У меня всё.

В systemd нечто вроде контейнеров (лол что?!), монтирования дисков, управления сетью, крон, повешены на PID 1.

Туда повешены только таймеры из этого списка.

Наконец-то!!! :)
Back to SystemV

С этим я и не спорил. Спор идёт о теории заговора.

А что мешало раньше?

Оно, вероятно, думает, что сейчас все бросятся выкидывать systemd.

Пруфлинк?

https://github.com/systemd/systemd/tree/master/src

А ничего, что udev встроен в systemd? logind тудаже, nss даже! journald, getty, управление питанием. Осталось только dbus встроить и можно будет писать новость: «Выпуск операционной системы systemd».

Идиотизм - обсирать всё подряд, безо всяких аргументов