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

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

Это гениально! Теперь тем, кому нужна стабильность, придётся ставить RHEL, и никаких альтернатив. А пользователей дистрибутивов без systemd объявляют автоматическими маргиналами, которых надо бить камнями. Круто придумал RedHat уничтожать свободное ПО.

ваша сишечка - решето

во всех нормальных языках:

TCP-ответ не уместится в выделенный буфер.

вызовет ошибку, что угодно но только не выполнение кода

не уместится в выделенный буфер

Как вообще такие ошибки пропускают? Переполнение буфера — это же классика.
Или пишут школьники «щас по-быстрому сляпаем прототип, потом переделаем» и так и оставляют.

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

Тут не единая дыра, а критическая концентрация дыр в PID 1.

Надо было купить пивас-студио :)

Проблема не затрагивает Red Hat Enterprise Linux 7 и производные дистрибутивы

а rhel 6 и генту эта проблема вообще не колыхает. нет систумд - нет проблем

Проблема не затрагивает Red Hat Enterprise Linux 7 и производные дистрибутивы.

не уместится в выделенный буфер

Как вообще такие ошибки пропускают?
Переполнение буфера — это же классика.

Преднамеренно

Это гениально! Теперь тем, кому нужна стабильность, придётся ставить RHEL, и никаких альтернатив. А пользователей дистрибутивов без systemd объявляют автоматическими маргиналами, которых надо бить камнями. Круто придумал RedHat уничтожать свободное ПО.

resolved

PID 1

Необучаемый дурак.

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

Комбайн из init'а, угрёбищный комбайн вместо оконной системы, да кому какая разница? UNIX-like всегда были изгажены хреновоработающими комбайнами, тоже мне новость.

Тут можно лишь сказать то, что macOS это единственный лучик света в этой UNIX-бездне.

Ничего, что там на каждом шагу преграды ставят? Эту папку не удаляй, сюда не ходи, это не трогай, ввели ограничения для root... С macOS просто пофигу, как и что там работает. Всеравно доступа нет.

Необучаемый дурак.

Если это про Поттеринга, то это многое объясняет. Я сегодня прочитал, что он в RedHat вобще в _Desktop_ (!) team работает! Этот чувак вообще серверами никогда не занимался!

Обновление с устранением проблемы выпущено для Fedora Linux и Ubuntu, но пока недоступно для Debian Stretch

Привет слоупочащим мейнтейнерам дебиана, радостно голосовавшим за внедрение этой поделки.

Я не дурачок, а вот ты мудозвон, как и все сторонники RedHat. Тот факт, что это компонент systemd связанный с оным напрямую, делает дыру в PID 1, даже если этот компонент выполняется вне PID 1.

Тот факт, что это компонент systemd связанный с оным напрямую, делает дыру в PID 1, даже если этот компонент выполняется вне PID 1

Нет, ты дурачок.

Привет слоупочащим мейнтейнерам дебиана

И тебе привет, истекающий желчью.

Чтобы получить дыру от уязвимости в systemd-resolved, нужно сначала включить systemd-resolved. А он по умолчанию выключен.

Необучаемый дурак.

Если это про Поттеринга

Нет, это про Quasar.

Тот факт, что это компонент systemd связанный с оным напрямую, делает дыру в PID 1, даже если этот компонент выполняется вне PID 1.

Видимо, это какая-то очень глубокая мысль, мне она не понятна. Ты не мог бы пояснить?

Чтобы получить дыру от уязвимости в systemd-resolved, нужно сначала включить systemd-resolved. А он по умолчанию выключен.

Чтобы получить дыру от уязвимости в apache, нужно сначала установить apache. А он по умолчанию не установлен.

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

Теперь тем, кому нужна стабильность, придётся ставить RHEL, и никаких альтернатив.

Manjaro OpenRC

Как вообще такие ошибки пропускают? Переполнение буфера — это же классика.

Это Си. Автоматических проверок чего бы там не было нет как класса. Ручные проверки надо ставить примерно на каждую первую строчку (как минимум постоянно проверять не плюнулась ли очередная функция кодом ошибки). Разумеется, в итоге разработчик рано или поздно где-то, что-то проверить да забудет. Или даже вполне осознанно на проверки забьет, понадеявшись что вот эта то функция точно не сглючит.

Если же все эти проверки хоть как-то автоматизировать, то получится C++. Так что кто понял что автоматизация нужна, тот с Си уже свалил. А кто не свалил, тот будет убеждать что чисто механическое набивание в n-цатый раз if(errno)return false; это очень круто.

кому нужна стабильность, придётся ставить RHEL/centos

Так будет точнее. А какие альтернативы тут могут быть? Не убунту же...

Чтобы получить дыру от уязвимости в apache, нужно сначала установить apache. А он по умолчанию не установлен.

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

Понемаю, адекватному человеку нужен КОНТРОЛЬ во имя КОНТРОЛЯ, а не просто работающие решения.

Так будет точнее. А какие альтернативы тут могут быть? Не убунту же...

Calculate.

Ну давайте посмеемся.

Ну давайте посмеемся.

Над чем? Над единственным стабильным rolling-release?

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

Ты ещё слакварь вспомни.

ненужным
и по определению нестабильным
поделием для никого

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

Ты ещё слакварь вспомни.

Почему я должен вспоминать? О ней вроде сложно забыть — один из популярных дистрибутивов.

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

Опять набор пустых фраз — «игрушка», «поиграться»... по сути то будет что?

Я вижу Calculate хорошим решением исходя из того, что он единственный на данный момент на рынке предоставляет стабильный rolling-release. Это дает хорошее преимущество по сравнению с стабилизацией и последующими крупными обновлениями (Ubuntu), и тем более по сравнению с CentOS, где миграция на новую версию требует решения еще большего количества задач единовременно.

Стабильный и rolling-release это взаимоисключающие параграфы.

Проблемы с переходом в нем ровно те же, просто они возникают при любом обновлении, а не при переходе от версии к версии.

Стабильный и rolling-release это взаимоисключающие параграфы.

Ничего подобного. Пакеты таким же образом проходят состояния unstable -> testing -> stable.

Проблемы с переходом в нем ровно те же, просто они возникают при любом обновлении, а не при переходе от версии к версии.

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