Состоялся релиз sysvinit 2.89

Угу, всё как у вас.

Пока не дойдёт, что концепция разработки systemd годится для какого-нибудь LibreOffice, но не для init.

Да, действительно.

Тот же LibreOffice глючит и лагает, что в очередной раз подтверждает ненужность большого и жирного софта.

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

Дохтур, диван уже не линукс?

а теперь ты хочешь поспорить со мной о существовании фрагментации линукса

Почему же поспорить? Наоборот, благодаря поделке Лёни фрагментация только увеличилась.

sysvhost

Наоборот, благодаря поделке Лёни фрагментация только увеличилась.

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

с того, что появились дистрибутивы цель существований которых отсутствие systemd?

s/отсутствие systemd/отсутствие непредсказуемой, дырявой и глючной поделки в качестве PID 1, написанной хипстором-неадекватом.

форк форка форка ради другой темы иконок и нескучными обоями это нормальное явление

Запуск сервиса от рута при существующем в конфиге сервиса пользователе — это нормальное явление? Удаление корня — нормальное явление? Или, может быть, зависание инита при отправке пустого сообщения — это нормальное явление? А может невозможность загрузки без внешнего жёсткого диска и LAN-кабеля — это нормальное явление? Или невозможность корректного выключения — это нормальное явление? А ещё невозможность пропустить запланированный вызов fsck — это нормальное явление? И ведь такого дерьма там целый вагон и большая тележка.

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

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

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

и не лень тебе было эти баги собирать?

А я их и не собирал, это уже сделали за меня. Комьюнити, мать его.

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

Ты вообще херню какую-то пишешь.

да и вообще, абсолютно дурацкая позиция, без относительно systemd, а вообще.

Для фанатика — может быть. Для любого адекватного пользователя это вполне адекватная позиция.

тут вот мол баги, а тут «работающие и проверенные временем решения» и приходите, когда багов не будет. ну ахренеть теперь.

Вот же сволочи, прикинь? Не хотят быть бесплатными альфатестерами Лёниной поделки, хотят чтобы всё работало как положено. Устаревшие некрофилы!

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

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

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

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

так я о том же

множественные патчи

люблю хорошего русского языка

Удаление корня — нормальное явление?

Да. Желающим поспорить советую выполнить # find /tmp/.* -delete.

а работающие решения без багов всю дорогу были?

Разный подход. Баги и сейчас есть. Но вот в чем дело, в баш скриптах подсилу разобраться большинству админов. В коде «комбайна» гораздо сложнее.
И что мы имеем на выходе: и в первом и во втором случае пишем баг репорт. Только в первом можно решить самостоятельно не дожидаясь официального фикса, во втором остается только ждать. Причем даже если в первом случае вас пошлют на юг, у вас все равно будет рабочее решение. Во втором только «понять и простить».
Тоже касается и нестандартных решений, фич реквест конечно можно отправить, но вот понравиться ли он «команде потного» хз.

к чему это? вообще никак не коррелирует с тем, о чём я пишу в треде. да и вообще, абсолютно дурацкая позиция, без относительно systemd, а вообще.

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

Только в первом можно решить самостоятельно не дожидаясь официального фикса, во втором остается только ждать.

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

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

Скрипты используют множество самых разных утилит, написанных на C, и исполняются оболочкой, также написанной на C.

Если там такая бага, это уже называется «писец котенку, не будет больше пысатся» выплывет она в разы быстрее и фиксить будут быстрее.

выплывет она в разы быстрее и фиксить будут быстрее

Это весьма спорное утверждение. Скорость обнаружения зависит от охвата и серьёзности последствий, а не от конкретного проекта. Скорость исправления же зависит от активности проекта и сложности кода, о которой я уже писал выше.

Давайте представим что это команда ip ?

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

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

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

приложения должны быть маленькими и вылизанными

никаких доказательств этого нет.

Я не приведу вам пруфы, так что не кидайтесь. Но вот личный опыт, с моей стороны три маленьких вылизанных «котенка» сервисов soap, с других сторон большой комбайн ORA. За все время работы, это более четырех лет, только с их стороны возникают факапы, которые они долго разгребают.

никаких доказательств этого нет.

Вообще-то это аксиома. Причём, абсолютно очевидная.

anonymous уже расказал про уровни абстракции на которых ты что-то можешь пофиксить в баш лапше.
но главное, не это.
а то, что или софт развивается и кол-во багов растёт или софт RIP и кол-во багов не растёт больше никогда.
в каком коде эти баги, в скриптах на баше или на Си, неважно.
так вот «проверенное временем» — это замороженное 10-20 лет назад.
простое существование CoreOS показывает, как отказ от маленького замороженного говна мамонта может двинуть прогресс в отдельно выбранной области.
что будет, если отказаться от других «проверенных временем решений»? IT схлопнется или нафиг рванёт вперёд опережая время?

так вот «проверенное временем» — это замороженное 10-20 лет назад.

мелкософт головного мозга
Вам уже несколько раз написали, работает, работает, работает, не трогай.
Даже по пунктам расписали.
Где профит карл? Или Осел из Шрека, «а мы сейчас здесь все перестроим» ?

а то, что или софт развивается и кол-во багов растёт или софт RIP и кол-во багов не растёт больше никогда.

Софт ещё может быть доведён до идеала. А развитие ради развития нужно только маркетологам. Вместо того, чтобы ломать рабочее, можно сосредоточиться на чём-то, что является действительно новым.

Софт ещё может быть доведён до идеала

При всём уважении к старичку-sysvinit, ему до идеала - как до Луны пешком.

Где профит карл?

если софт А умеет функцию [A], а софт Б умеет функции [A,B,C...Z] и баг в функции X, то можно взять софт Б, посчитать риски и получить больше профита чем те, кто выбрал А.
профит в развитии есть всегда, особенно, когда мало бюрократии.

При всём уважении к старичку-sysvinit, ему до идеала - как до Луны пешком.

Ну можно было сделать новый init, а не рождать мамонта. :-)

Ясно «Осел из шрека», вопросов больше нет.

Ну можно было сделать новый init, а не рождать мамонта. :-)

Ну так init-часть в systemd как раз-таки неплоха.

если софт А умеет функцию [A], а софт Б умеет функции [A,B,C...Z]

Беда вся в том, что у софта Б в целевой области применения может быть нужна только функция B, а C...Z и бажная X относятся к совершенно другой области. Паровозу крылья не нужны - он, всё равно, не сильно хорошим самолётом будет.

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

вот по факту, только у systemd новый подход.

Да не новый подход-то, а вполне себе зарекомендовавший себя в Solaris и OS X. systemd - это просто реализация данного подхода в GNU/Linux, не более того.

Обещал не отвечать, но...

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

Вот! Самое главное. То что вам уже впихнули простите сами знаете куда

вот по факту, только у systemd новый подход.

Скомуниздили с launchd который хоть и норкоманский, но в отличии от «поделки» давно рабочий.

не знаю что ты там обещал, кроме раздачи определений «Осёл».
но срань господня, вы даже в контексте линукса не можете говорить? теперь надо делать ненужные оговорки просто, чтобы не начать обсуждать мак-фрю-соляру-винду и не скатится в сравнения?
чё за бред? линукс сам по себе при таком рассмотрении весь скомунизден. начиная от ядра, заканчивая всем прикладным софтом. причём, всё что связано с ГНУ _принципиально_ было скопировано. лол.

launchd который хоть и норкоманский, но в отличии от «поделки» давно рабочий

systemd тоже рабочий. Я ещё могу понять восклицания о монолитности и т.п., но говорить, что init, который в данный момент использует подавляющее большинство дистрибутивов GNU/Linux, не рабочий...

Что за крайности у людей: если что-то нравится, то начинают обожать, игнорируя все недостатки; если что-то не по нраву, то начинают ненавидеть, игнорируя все достоинства. Реальность несколько другая и практически никогда не чёрно-белая.

systemd тоже рабочий.

Да рабочий, рабочий. Сам колюсь. Но, простите, все еще не вставляет.
Идея хороша, без сарказма, реализация через попу.

Да рабочий, рабочий. Сам колюсь. Но, простите, все еще не вставляет.

Это нормально. :)

У меня самого к systemd немало претензий. Скажем, то, что его компоненты развиваются в рамках одного репозитория, а не независимо, на мой взгляд ничем не оправдано: они используют лишь интерфейсы systemd, которые обратно совместимы, так что вполне можно было бы разделить их. Это, видимо, политическое решение: воспользоваться удачным компонентом init, чтобы «паровозиком» внедрить и собственные реализации других компонентов, которые будучи отдельными внедрялись бы ещё долго. Цель понятна: создать стандартное решение базовых задач, как то простая настройка сети, управление сеансами пользователей и т.д. Оно вроде бы и неплохо, и в основном не исключает использование альтернативных реализаций, но всё же сам подход неприятен.

Это, однако, не отменяет качественного перехода в системе инициализации, аналогичного тому, что произошёл при переходе на менеджеры пакетов: систематизация подхода. Объединение процессов (hint: файлов) в одну логическую единицу: сервис (hint: пакет), выражение связей между логическими единицами в виде зависимостей между сервисами (hint: пакетами), централизованное управление сервисами (hint: пакетами) через единый интерфейс: системный менеджер (hint: менеджер пакетов) - ничего не напоминает? Да, менеджер пакетов менее гибок, чем ./configure && make && make install, но и значительно удобнее в использовании и легче в поддержке - а если кому не нравится, то есть дистрибутивы с альтернативным подходом. То же самое будет и с systemd.

Понимаете в чем фигня. Вот в «старые» времена, я мог спокойно накатить обновы и т.д. и т.п. и не париться что мне «внезапно» прийдется ехать очень далеко.
С *d в целом я тоже не парюсь (на самом деле нет, сыкотно каждый раз) насчет «дальней поездки», времена изменились, есть виртуалки, ilo, ipkvm и т.п. Стало легче в этом плане.
Но вот количественно по трудозатратам стало тяжелее, перед каждой обновой «100 раз отмерь один отрежь»... слишком часты случаи после обновы падений (Не забудьте умножить на кол-во серваков которые выполняют разные задачи, на одном взлетит, на другом нет)

ЗЫ Поймите правильно, это субъективное мнение, не более того. Но факт как есть, работы админам добавилось, а с точки зрения удобства пользователей ничего не изменилось.

слишком часты случаи после обновы падений

Падений systemd? o_O Или это в общем?

Если последнее, то ничего не поделаешь: сложность ПО растёт, а вместе с ним и вероятность ошибок. У нас, правда, ни с Debian jessie, ни со stretch после обновлений особых проблем не было пока (вот с Ubuntu бывали, и не раз). Но и машин у нас немного, и в основном они у нас же в здании и расположены, так что если что, идти недалеко.

работы админам добавилось

Соглашусь частично: работа, связанная с переходом на systemd, одноразовая. Разобрался с основными принципами, переделал самописные скрипты в сервисы, кое-где подправил дистрибутивные - и всё, дальше пользуешься новым инструментарием и в ус не дуешь. Но да, на это нужно время, и при отсутствии очевидных выгод это не то, чем хочется заниматься. systemd, наверное, более удобен разработчикам дистрибутивов - а именно они в конечном счёте и принимают решения.

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

Падений systemd?

«копейка» и чуть деба, убунту только издалека видел, поэтому не скажу за нее. Встает колом на загрузке, дальше ручками решаешь.
Или изменения в сетевой системе, нет никаких НМ, выкинуто нафиг, но вот приплывает внезапно... :( Понятно, все объяснимо, протестируй на «кошках», но блина я описал как было раньше, спокойно и без гемора, и как стало сейчас.

Соглашусь частично: работа, связанная с переходом на systemd, одноразовая. Разобрался с основными принципами, переделал самописные скрипты в сервисы, кое-где подправил дистрибутивные - и всё, дальше пользуешься новым инструментарием и в ус не дуешь.

Это тот самый идеальный вариант. По началу вроде также без проблем прошло.

и в основном они у нас же в здании и расположены, так что если что, идти недалеко.

Это существенное замечание! А когда «тоже здание» за тысячу км., да ладно..... достаточно нескольких десятков км по меркам ДС, уже по другому думать начинаешь. А вот с сотен и тем более тысяч км. в разы «интереснее» становиться :)

PS Вот просто пример, обновился деб9 сеть улетела, да воде ничего на нем такого-то и нет, простенькая виртуалка, с парой-тройкой сервисов, не нагружена, прописали ip статиком, работает, вернули на dhcp работает, вот что за нафиг вин шаманство? Именно «вин шаманство» я как-то не привык к вариантам когда из меня дурака система делает.

Разве из логов не понятно было? networking.service же всё в std(out|err) выводит, включая dhclient, что в конце концов оказывается в syslog.

Разве из логов не понятно было?

Понятно. Хрен вам а не адрес по dhcp, нямагу получить.
ЗЫ Честно говоря в глубокий дип уходить и не собирались, заработало и фиг бы с ней, не настолько критичная. Но осадочек остался.

Понятно. Хрен вам а не адрес по dhcp, нямагу получить.

У нас как-то похожее было, когда один товарищ от нефиг делать решил поэкспериментировать и завести openwrt на вполне себе боевом mikrotik (через metarouter) и поставить туда asterisk. От такой наглости mikrotik'у поплохело, и IP-адреса он раздавать перестал. Живительный подсрачник починил mikrotik. Но сначала никак не могли понять, в чём дело: пул адресов не полный, но хер там.

Так что причина может быть отнюдь не в той системе, где что-то не работает. :)

Грёбаная капча, пришлось протыкать 14 квадратиков. 14, Карл!

Кстати на тему костылей. Вот посмотрите реализацию вызова dhclient. В дебе оно еще «ничего так»(образно), в копейке так вообще скрипт на скрипте и скриптом погоняет.
Ну вот чем, чем это лучше старого инита? Усложнили работу? Да. Профита от этого получили? Нет.
Когда-то пытался в кач-ве эксперимента подпихнуть в копейке dhclient «не стандартный для нее по конфигам» параметр. Заколебался искать этот длинный путь реального вызова, что бы просто впихнуть нужный параметр.

Так что причина может быть отнюдь не в той системе, где что-то не работает. :)

Неее, все проще, все работало до обновления, понимаете работало! Вот это самый важный момент. И после заработало, тут правда не исключаю что конфиги, чуть, но другие стали. Ручками заново вписали, но чуть по другому.
И опять-таки, фиг бы с ним если разово, но на копейке тоже были случаи не поднятия сети после апдэйта.
Повторюсь, за время использования онтопика, а это с второй половины 90-х, такого количества факапов по вине обновления как с переходом на *d не было.
И так же повторюсь, я не против идеи, я против текущей реализации. Как говорила ФрекенБок «я вас боюсь» :)

Грёбаная капча, пришлось протыкать 14 квадратиков. 14, Карл!

Что мешает залогиниться? У меня даже телефон залогинен. :) Вру, не все :)

Грёбаная капча, пришлось протыкать 14 квадратиков. 14, Карл!

ЗЫЫ Вот еще раз пришлось на логин посмотреть, наверное какое-то кол-во времени я его буду помнить. Причем этот я бы подбирал в последнюю очередь :) ЧСХ пасс помню, а вот с логином у меня постоянная беда :)

4.2

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

Всё можно настроить.

Еще и пропатчить можно. А можно с дуру и сломать причиндал. И что?

Он ведет логи. Которые тебе однажды пригодятся.

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

99% людей не особо это нужно.

Systemd это про linux — а тут 90% (не счиатая юзеров эмдебеда, разрабам как раз тут надо что то простое) вполне себе нормальные люди.

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

серверных облачных систем, корпоративных сетевых структур, вычислительных систем специального назначения, да и банально миллионов серверов с поднятыми веб-сервисами

Вот тут сустемдик может быть и полезен.