Исходное сообщение
"Релиз дистрибутива Devuan 2.1, форка Debian 9 без systemd" Отправлено Q, 28-Ноя-19 01:27
> меня тоже обошли. И, полагаю, большинство других админов - мы, видимо, способны понять тривиальный баш-скрипт, если понадобится. > назовите первые три. Держи себе первые три: https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;d... https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=sysvinit-u... https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;d... Ну давай ещё расскажи, что тебя баги обошли, экстраполируй свой личный опыт дальше, зачем же ограничиваться другими админами, сразу до вселенной расширяй, не мелочись. > большинство из них содержит _ровно_одну_строчку Да ладно, зачем такие сложности - целая строка! Большинство процессоров оперируют ровно двумя состояниям бита - вообще не проблема же прям в машинных кодах читать? > a) юниты не умеют читать нормальные конфигурационные файлы Что есть нормальный конфигурационный файл? Это твоё утверждение без оснований - ложно. > b) эта помойка не предназначена для ручного управления, в результате существует пять разных способов переопределить поведение юнита - "угадай, какой был применен тут ,и сам факт применения". Сразу же ложное, необоснованное утверждение и тут же второе сделанное на его основе. > Дебагу не поддается. Очередное ложное утверждение. Дебажится. > И, самая основная проблема - что помимо физически существующих юнит-файлов есть виртуальные, создаваемые самим shttyd неотключаемо и неуправляемо, Очередное ложное утверждение. Управляемо и отключаемо > и, сверх того - есть полтора гигабайта невероятно дрянного сишного кода, который работает до, после, во время и вместо юнитов, и вообще никак не отлаживаем и ненастраиваем. И снова ложное утверждение. Код всёго 18M в исходниках (сопутствующий stuff доводит размер до 45M), код очень простой и написан читабельно, к коду применимы современные средства разработки и отладки. Systemd это по сути объединение и унификация кода многих утилит и скриптов обычно используемых для запуска ОС. Если тебя это так напрягает, то почему ты не возражаешь против унификации кода всех драйверов и различных базовых функций в ядре Linux или FreeBSD? Может быть все драйверы и основы ядра тоже на bash должны быть? > Вот совсем банальная ситуация - из-за проблем с железом надо загрузиться с ядром 3.12, шиттид - несовместим с ядрами моложе 5.4 (или какое там завтра выпустят?), КАК ? Пока-что это высосанная из пальца ситуация. Если более новое ядро не может загрузиться с железом, то либо железо сломано, либо устарело безнадёжно, либо это не проблема железа, а проблема конкретного ядра. Да и помимо всего прочего откат на старое ядро может сам по себе создать проблемы, например исказить информацию на fs, попортить криптографию, сломать multipathing или вообще не завести сеть потому-что, например, teaming на старой версии не поддерживается.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> меня тоже обошли. И, полагаю, большинство других админов - мы, видимо, способны понять тривиальный баш-скрипт, если понадобится. >> назовите первые три. > Держи себе первые три: > https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;dist=stable;package=sysvinit-utils#_4_0_5 > https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=sysvinit-utils;dist=unstable#_0_2_3 > https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;dist=stable;package=sysv-rc#_4_0_5 > Ну давай ещё расскажи, что тебя баги обошли, экстраполируй свой личный опыт > дальше, зачем же ограничиваться другими админами, сразу до вселенной расширяй, не > мелочись. >> большинство из них содержит _ровно_одну_строчку > Да ладно, зачем такие сложности - целая строка! Большинство процессоров оперируют ровно > двумя состояниям бита - вообще не проблема же прям в машинных > кодах читать? >> a) юниты не умеют читать нормальные конфигурационные файлы > Что есть нормальный конфигурационный файл? Это твоё утверждение без оснований - ложно. >> b) эта помойка не предназначена для ручного управления, в результате существует пять разных > способов переопределить поведение юнита - "угадай, какой был применен тут ,и сам > факт применения". > Сразу же ложное, необоснованное утверждение и тут же второе сделанное на его > основе. >> Дебагу не поддается. > Очередное ложное утверждение. Дебажится. >> И, самая основная проблема - что помимо физически существующих юнит-файлов есть виртуальные, создаваемые самим shttyd неотключаемо и неуправляемо, > Очередное ложное утверждение. Управляемо и отключаемо >> и, сверх того - есть полтора гигабайта невероятно дрянного сишного кода, который работает до, после, во время и вместо юнитов, и вообще никак не отлаживаем и ненастраиваем. > И снова ложное утверждение. Код всёго 18M в исходниках (сопутствующий stuff доводит > размер до 45M), код очень простой и написан читабельно, к коду > применимы современные средства разработки и отладки. > Systemd это по сути объединение и унификация кода многих утилит и скриптов > обычно используемых для запуска ОС. Если тебя это так напрягает, то > почему ты не возражаешь против унификации кода всех драйверов и различных > базовых функций в ядре Linux или FreeBSD? Может быть все драйверы > и основы ядра тоже на bash должны быть? >> Вот совсем банальная ситуация - из-за проблем с железом надо загрузиться с ядром 3.12, шиттид - несовместим с ядрами моложе 5.4 (или какое там завтра выпустят?), КАК ? > Пока-что это высосанная из пальца ситуация. Если более новое ядро не может > загрузиться с железом, то либо железо сломано, либо устарело безнадёжно, либо > это не проблема железа, а проблема конкретного ядра. Да и помимо > всего прочего откат на старое ядро может сам по себе создать > проблемы, например исказить информацию на fs, попортить криптографию, сломать multipathing > или вообще не завести сеть потому-что, например, teaming на старой версии > не поддерживается.
	Введите код, изображенный на картинке: