> Вообще-то судить о стабильности по бета-версии переходного периода - это не совсем компетентно, мягко говоря.Вообще-то считать debian testing обычной бетта-версией мягко говоря странно. Кто им пользуется обычно считают его ролинг-релизом, в который приходит уже достаточно оттестированное ПО. Но даже если считать его бетой, то качество этого творения явно не достаточно для беты.
> У остальных то оно нормально их выполняет. Так что это или баг в тестовой версии или кривые руки. Так, по логике вещей.
Так и у меня оно как-то худо-бедно работало до последнего релиза. А отмаз что "это или баг в тестовой версии или кривые руки" можно под любой софт прилепить.
> Ну вон RHEL выпустили и громкого воя не слышно что-то.
И как давно вышел RHEL7? И сколько, по Вашему мнению за это время прошло миграций со старых систем на новые?
> Вопит в основном всякое школие с тестовыми версиями и дистрами для камикадзе, которое с удивлением узнало что на ядерных полигонах, оказывается, иногда проводят ядерные испытания. Кто бы мог подумать?!
Конечно, все кругом пи@!#$сы, один я д'Артаньян... Раз уж полез в бочку с го@#ом - давай выкладывай сюда критерии отнесения дистрибутивов к "дистрами для камикадзе". Ну и так, чисто для справки всезнающему "эксперту в области (QA)": если никто не будет пользоваться бетами (в данном конкретном случае - тестингом), то этот кусок фекальных масс так и приползет в релиз к большому удивлению пользователей.
> Видели мы эту "отладку", спасиб. Спихали весь глюкодром и проблемы на майнтайнеров пакетов и сделали козью морду - мол, проблемы скриптов - не глюки системы инициализации, ничего не знаем.
И конечно же ты готов ответить за свои слова и выложить нам баги системы инициализации sysvinit, которые не исправлялись, а сваливались на мантейнеров?
> В коммерческих как раз никто не будет нестабильные и сырые решения подкладывать - там это вызывает попадание на бабки со стороны дистромэйкера.
Ну, для начала, никто ни на какие бабки не попадает - это твои эротические фантазии. Был свидетелем как банк встал на сутки из-за подтвержденной ошибки в одной очень известной и сильно платной СУБД - никто не оплатил ни копейки. Просто в срочном порядке порешали проблему. Далее, как Вы думаете, может ли свободное сообщество уделить столько же сил на поддержку и патчинг сырой программы, как это делает коммерческая контора, которая по совместительству является работодателем разработчика? И является ли потраченное усилие производительным? Не стоило ли остаться на хорошо отлаженной системе до тех пор, пока новая не будет в апстриме доведена до приемлемого качества?
> Так что то что systemd взяли в релиз шапки как раз индикатор того что он дошел до кондиции.
Я бы сказал, что принятие в новый RHEL таких кардинальных изменений является скорее признаком необходимости для компании привлечения новых клиентов на платную поддержку и проведение обучения. А то все уже привыкли к текущим, все все и так знают, да еще злобный оракел раздает все то же самое, но бесплатно
> Если вы хотите поспорить о качестве кода шапки и прочая - ну попробуйте.
Я не хочу спорить о качестве кода шапки - в этой теме разговор не о ней. Если бы мне нужна была шапка с ее качеством - я бы ею и пользовался. Но пользовался я дебианом и его качество меня более чем устраивало даже в тестовой ветке.
> Сдается мне что тут вообще не в systemd проблемы или не столько в systemd.
Сдается мне, что если софт решил отложить запуск какой-то программы до получения первого запроса к ней, то он должен этот запрос удержать до тех пор, пока программа не запустится. Это в идеальном мире. А у нас - мир не идеальный. И софт может запускаться долго из-за разных факторов, да так долго, что удерживать запросы не выйдет в любом случае. И тут мы приходим к мысли, что возможно концепция запуска сервисов по запросу не настолько хороша, как нам ее стараются представить. Ну или нужна она для 2-3 легких сервисов, а для остальных приносит больше проблем чем пользы. Итогом имеем усложнение системы в том месте, где его быть не должно. И трудно уловимый глюк, поскольку к моменту выявления проблемы все уже работает и почему не прошел коннект остается только догадываться.
Ну и да, это не отменяет конечно же глючноватости моего варианта запуска mozilla sync-server на uwsgi - там были и другие косяки, которые однако удалось решить. Хотя если оно запустилось - то работает нормально месяцами. Так что считать что это софт seriously fucked up - мягко говоря не корректно.
> А два - гм, идея запускать монстряку типа постгра при прилете запроса на сокет кажется мне довольно спорной.
Так если софт не такой большой - зачем вешать его запуск на событие - он и так стартует мгновенно и ресурсов мало потребляет? И тут мы приходим к мысли, что тем, кто запускает сервисы плана postgresql гораздо важнее предсказуемость запуска, чем выйгрыш в доли миллисекунд при старте системы. А тем, у кого такого софта нет - и так все стартует достаточно быстро. В чем профит тогда усложнения загрузки введением дополнительных сущностей типа запуска по требованию?
> При том все это - тоже не проблемы systemd сами по себе
Ясен фиг - у systemd проблем вообще же нет! А то, что основной его функцией как системы инициализации является запуск других программ - вообще проблемы этих самых программ, мантейнеров или кого угодно другого...
> Только как вы будете выкручиваться - ваши сложности.
Да я уже - нашел как загрузить через параметры ядра старую систему инициализации с которой никаких проблем на той же самой системе не возникает. Пока оставлю так, а там будем смотреть по обстоятельствам
Вариант для распечатки
