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

что прочее? Как он может сфейлить?

Canonical List of Famous Last Words , number 317 : «What could possibly go wrong?»

тривиальная задача собсно. Как и в xinetd.

Фейспалм.

а) все демоны нужно было патчить на тему поддержки xinetd. Этот процесс сопровождался багами. До сих пор его держат далеко не все.

б) в руководстве к куче ftp серверов одни из типичных workaround'ов , «перестанте выпендриватся и запустите его демоном а не из xinetd»

решение проблемы «убегания» демонов после двойного форка с помощью cgroups.

cgroups кстате весьма универсальная штука - что мешает ее заюзать не в systemd ? Скорее всего ничего - но так как большинство спорщиков не представляет о чем речь в голове просто склеилось «systemd круто решает проблемы юзая cgroups, а остальные этого не могут »

systemd - это аналог xinetd, только для системных сервисов.

Если бы это было так - то есть это был бы специализированный демон который бы делал только это - проблемы бы с ним не было.

решение проблемы отдельного /usr и других подобных поблем с разделами на корню

Проблему с отдельным /usr решили тем что не будет отдельно /usr :D При этом одним из аргументов было «все равно systemd с отдельным /usr не работает» :D

Зато демагоги и навернякасты имеют представление обо всём. Cgroups уже пять лет как в ядре - почему то ни в OpenRC, ни в Upstart их так и не впилили до сих пор.

Или другой пример - /usr на отдельном разделе. Systemd умеет это изначально, но где ж аналитикам догадаться, что в силу асинхронности загрузки, что и является главной фичей systemd, следует явно указать оному сперва /usr примонтировать, а потом дальше рыпаться.

Давай примонтируй мне usr до запуска systemd без initramfs

Cgroups уже пять лет как в ядре - почему то ни в OpenRC, ни в Upstart их так и не впилили до сих пор.

И какой вывод?

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

Такие глубокие познания о том сколько лет в ядре cgroups! Снимаю шляпу! Наверное вы демагог и навернякаст, имеющий представление обо всём.

почему то ни в OpenRC, ни в Upstart их так и не впилили до сих пор.

Потому что это понадобилось только упоротому Леннарду ради маркетинговых целей? Типа «наш продукт отгоняет крокодилов, видите - крокодилов нет! +1 к фичелисту systemd !»

Опять двадцать пять

На лоре каментов про systemd по числу строк написано в три с половиной раза больше чем в исподниках systemd.

Это у вас хобби такое? Сидите, и переливаете из пустого в порожнее.

Canonical List
Canonical

не нужно

Таки вы определитесь cgroups - это универсально, вкусно и полезно или всё же маркетинговый ход подлого Леннарта?

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

Таки вы определитесь cgroups - это универсально, вкусно и полезно или всё же маркетинговый ход подлого Леннарта?

Это маркетинговый ход подлого Леннарта, который настолько промыл мозги хомячкам на тему того что эта мелкая фича очень нужна, что 95% ЛОРа уверены в том что это «универсально, вкусно и полезно». Так как переубеждать хомячков обратно - бесполезно, проще поставить вопрос по другому: ничего не мешает(и даже лучше) использовать cgroups в составе отдельного демона применимого к любой системе инициализации. Это будет юниксвейно.

PS
Мы про cgroups в init'е. cgroups вообще как явление это универсально, вкусно, полезно и вообще огого.

Многие его не любят за то что его включают в их дистрибутивы, а выключить проблемно. Вот и на опеннете мне говорят «вот я не лезу отключать и у меня всё работает». Мой дистрибутив Linux на этапе установки задаёт вопрос, включать ли systemd, networkmanager и pulseaudio. Поэтому я не злюсь на Леннарта Поттеринга, у меня нет его systemd, но есть простой способ попробовать без правки конфигов.

Так можно любой вопрос повернуть, например: ничего не мешало(-ет) GNOME Foundation разработать удобное гибкое DE на смену GNOME2.
Однако же третий гном почему-то продолжает быть говном.

Я согласен, что прибитость всего и вся гвоздями к systemd - это минус, однако поддержка cgroups быть плюсом от этого не перестает.

ты - толстый троль

«все равно systemd с отдельным /usr не работает»

работает

Интересно, если создать тред с заголовком «systemd», тегом «systemd» и сообщением «systemd», там наберется 15 страниц срача?

Кому нужна супер-пупер быстрая загрузка, пилите Runit http://powerman.name/runit/
Всё в одном файле, всё можно настроить самому.

В Gentoo по сравнению с initrc на core2 + hdd
время загрузки уменьшилось с 11 до 7 сек.

И чем оно лучше systemd?

Оно ничем не лучше systemd. + оно не имеет и малой части фич systemd. Зачем оно в таком случае нужно?

это не юникс вэй

в таком случае юникс-вей давно умер потому что 99% приложений не состоят из пары сотен отдельный приложений собранных вместе скриптом а одно целое.

В общем, твой браузер не юникс-вей, твой плеер не юникс-вей, твой...

А вот модульность приложений никуда не делась.

слишком сложная => ненадежная программа.

у них же есть защита и на этот счёт. А вообще поживём - увидим. Уверен 99% его даже не видели, но критикуют.

в таком случае юникс-вей давно умер

В общем, твой браузер не юникс-вей, твой плеер не юникс-вей, твой...

Пох на браузер и плейер, мы говорим о самой базовой системе.

Наброшу для поддержание накала страстей: тут выше пробегала ссылка на https://plus.google.com/115124063126128475540/posts/j4Jw8rC516M Так вот, там упоминаются такие вещи как «gnome.target» и «kde.target». То есть, это реализация на уровне systemd (через его механизм *.target) того, что в DM делается через сессии, причем реализация в обход самого DM. Но функциональность DM на десктопах всё-таки нужна. Так вот, к чему я веду: не означает ли это всё, что в скором времени в systemd встроят и свой собственный DM? :)

мы говорим о самой базовой системе.

Если вопрос в том стоит ли всё так усложнять то поживём-увидем. Если это просто работает и не требует гемора с настройкой то пусть будет.

Да и куда тут вставлять эту самую юникс-вейность-то? Нужна чисто для галочки? Сложное приложение не станет проще от юникс-вейности. Я видел очень много систем построенных из отдельных приложений. Последнее от чего сблеванул это когда попытался openstack поставить. Больше 100 пакетов тянет, настраивается тыщей разрозненных конфигов, падает с негуглящимися ошибками... Зато юникс-вей, до... Короче, когда большая система делается из многих компонентов важно чтобы компоненты знали друг о друге а не «я делаю только одну функцию, вот моё API и мне пох на сколько оно совместимо с остальным миром.».

В общем, решающее значение имеют скиллы тех кто пишет, имхо. И тут Поттерингу пульс не забудут :)

не означает ли это всё, что в скором времени в systemd встроят и свой собственный DM? :)

главное чтобы на сервера не пришлось тащить иксы с кде и гномом...

Сделают что-то наподобие qingy, чтобы без X-ов обойтись :)

Сделают что-то наподобие qingy

вот тенденция ухода от текстовых терминалов мне не нравится :( Ну хотя бы тем что с kvm -curses не запустишь (вернее, не увидишь что происходит).

Да я в общем-то шутил про встраивание DM (хотя эти могут, да). И даже если и правда встроят, то наверное сделают или так, чтобы оно запускалось только при включенном graphical.target, или чтобы в зависимости от цели загрузки запускалась бы либо морда на ncurses, либо что-то гуёвое.

я надеюсь ненужные фичи отключаемы. Чтобы можно было apt-get install systemd-light и усё :)

Боюсь, что только в конфигах. Хотя в дебиане могут и ножницами поработать, там это умеют аккуратно делать.

Последнее от чего сблеванул это когда попытался openstack поставить. Больше 100 пакетов тянет, настраивается тыщей разрозненных конфигов, падает с негуглящимися ошибками... Зато юникс-вей, до...

100 пакетов - это не юниксвей само по себе.

В общем, решающее значение имеют скиллы тех кто пишет, имхо

Любое говно можно заставить работать. Проблема в том, что после этого его нельзя трогать.

ААА, посмотрел исходники, ОНО ЧЕРЕЗ autotools КОНФИГУРИЦЦАА!

И эти люди ещё утверждают что стандартный инит гуано?? жёпа :)

Давай примонтируй мне usr до запуска systemd без initramfs

Всего 2 вопроса:

Зачем монтировать /usr до запуска systemd, если это можно сделать и после? (кстати, quiet_readonly это и не предлагал)

В чём вообще проблема смонтировать /usr до запуска systemd, не используя initramfs? Как минимум, ничего не мешает положить код, который это делает в initramfs, куда-нибудь в /lib/preinit, изменить в нём абсолютные пути соответствующим образом и запускать скрипт /lib/preinit/init вместо /bin/systemd. Это самое банальное и очевидное решение, можно сделать и лучше.

что в скором времени в systemd встроят и свой собственный DM?

Да практически уже.

В чём вообще проблема смонтировать /usr до запуска systemd, не используя initramfs? Как минимум, ничего не мешает положить код, который это делает в initramfs, куда-нибудь в /lib/preinit, изменить в нём абсолютные пути соответствующим образом и запускать скрипт /lib/preinit/init вместо /bin/systemd. Это самое банальное и очевидное решение, можно сделать и лучше.

этот совет нужно читать так

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

апофеоз поттеринговской логики

Всего 2 вопроса:

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

Ты только что описал как устроен любой дистрибутив GNU/Linux.

Да ты что?! А я думал я описал винду и идеал, к которому стремится Поттеринг.

Всё понятно, умеем читать только вторую половину сообщения, а вопросы благополучно проигнорированы. Типично для толстого троллинга.

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

«Давай примонтируй мне usr до запуска systemd без initramfs» — это уже какая-то костыльная постановка задачи, потому что в обычной ситуации /usr не нужно монтировать до запуска systemd, да ещё и без initramfs, а если такая необходимость почему-то возникла, то что-то ты делаешь не так. Так почему решением костыльной задачи должен быть не костыль?

в обычной ситуации /usr не нужно монтировать до запуска systemd, да ещё и без initramfs

Да ты что?! То-то systemd просит библиотечки из /usr и если последний не примонтирован до запуска поттеринговского костыля, то система благополучно не стартует.

initramfs

изначально костыль

костыльной задачи

кто тебе это сказал?!

>Зачем монтировать /usr до запуска systemd, если это можно сделать и после?

Зачем мне все эти костыли

o_O, т.е. для тебя монтировать /usr после запуска инита — это тоже костыль? Монтировать из initramfs — это костыль; монтировать до запуска инита — это костыль, а не монтировать /usr вообще ты не можешь. Как же ты монтируешь /usr сейчас, интересно?

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

Читай выше, «чукча»

То-то systemd просит библиотечки из /usr

Это заботы мейнтейнеров дистрибутива, куда класть какие библиотеки. Всё, что нужно systemd, благополучно собирается и с libdir=/lib. Если в твоём дистрибутиве положили какую-то библиотеку в /usr, то при чём тут systemd? Если бы они glibc запихали в /usr/lib, то гнал бы и на SysVinit?

кто тебе это сказал?!

В такой формулировке это даже не задача, а уже костыль, потому что делать что-то до запуска инита, да ещё и не в initramfs — это костыль.

Если инит без этого не запускается, то это проблемы инита, вот почему то sysvinit прекрасно в таких условиях жил, а костыльный systemd без этого жить не может. Но разве фанатиков это заботит?! Нет. Они будут по прежнему свято верить в непогрешимость мессии Поттеринга и следовать его заветам по костыле- и велосипедостроению. Аминь.

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

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

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

ты придумал какой-то нереальный use-case. Это в теории возможно, но даже в теории трудно представить такую программу, который было бы одновременно важно и временная отметка, и обязательная обработка _всех_ запросов.

cgroups кстате весьма универсальная штука - что мешает ее заюзать не в systemd ?

ничто не мешает. Но никто ж пока не заюзал.

Только при наличии initramfs