Systemd - что вам нужно знать

Systemd - что вам нужно знать

Если вы не жили под скалой или того хуже - вас не особо заботит, как работает Linux, вы, должно быть, слышали о systemd, (относительно) новой системе инициализации, заменяющей старую и устаревшую SysV init, недавно принятую большинством основных Linux. дистрибутивы.

Что такое система инициализации?

Когда ваша Linux-машина запускается, она сначала запускает некоторый "встроенный" код, сначала загруженный из BIOS или UEFI, а затем загрузчик, который в соответствии с его конфигурацией загружает ядро ​​Linux. Ядро загружает драйверы, и в качестве самого первого задания запускает процесс init, который первым получает присвоенный ему PID (Process ID) 1.

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

systemd-linux-boot

Однако то, как это реализовано, далеко не единообразно, и именно здесь все перестает быть общим и четко определенным.

Старая система инициализации

До недавнего времени в большинстве распространенных дистрибутивов Linux использовалась система инициализации System V init (или сокращенно SysV init), получившая свое название от UNIX System V (произносится как System Five), первой коммерчески доступной системы UNIX. В операционной системе System V есть особый способ запуска процесса инициализации, и SysV init сохраняет верность этому на протяжении многих лет.

systemd-sysvinit

И прошло много лет. UNIX System V была первоначально выпущена в 1983 году, что сделало init SysV init более 30-летним подходом к запуску машин Linux.

Необходимость перемен

Как уже отмечалось, SysV init устарел и давно нуждается в замене. Некоторые из причин этого включают:

  • SysV init использует / sbin / init для запуска процесса инициализации, но сам init играет очень ограниченную роль. В соответствии с конфигурацией, считанной из / etc / inittab, init делает немного больше, чем запускает /etc/init.d/rc, который, в свою очередь, запускает сценарии для выполнения реальной работы процесса инициализации. Это будет происходить последовательно, за исключением случаев явной группировки (например, startpar в Debian), один сценарий запускается за другим, что замедляет весь процесс, поскольку каждый сценарий должен ждать завершения предыдущего.
  • SysV init не имеет доступа к PID или процессам, которые он (косвенно) запустил. Он только считывает PID и связывает их с реальными процессами косвенным и сложным образом.
  • Системным администраторам, пытающимся изменить среду, в которой должен запускаться определенный процесс, довольно сложно использовать SysV init. (Для этого им нужно будет изменить init strcipt, который отвечает за запуск данного процесса.)
  • Существует определенная функциональность, общая для каждой службы, которую SysV не реализует, но вместо этого каждый процесс должен реализовать себя, например, "демонизировать" себя (стать системным демоном), что является сложным и длительным процессом. Вместо того, чтобы выполнять эти шаги один раз, SysV требует, чтобы каждый процесс выполнял работу самостоятельно.
  • SysV также оставляет определенные функции внешним программам и ничего не знает о службах, запускаемых ими.

Все вышеперечисленное и многие другие конструктивные недостатки или, скорее, устаревшая конструкция системы SysV сделали создание современной системы инициализации давно назревшей.

Введите systemd

Было много попыток создать альтернативную систему инициализации, из которых systemd - лишь одна из них. В Ubuntu была запущена собственная система инициализации, называемая выскочкой. Gentoo по-прежнему использует OpenRC. Другие системы инициализации включают initng, busybox-init, runit, Mudur и другие.

Причина, по которой systemd является явным победителем, заключается в том, что он принят большинством основных дистрибутивов. RHL и CentOS, естественно, пошли по пути systemd, поскольку Fedora была первым дистрибутивом, официально принявшим systemd в 2011 году. Но systemd действительно стала единственной системой инициализации, которая управляет ими всеми, когда Debian 8 официально перешел на systemd, привнеся с собой Ubuntu и производные. , преодолевая первоначальную оппозицию Canonical (или, точнее, Марка Шаттлворта) systemd.

Чем отличается systemd?

  • Systemd стремится предоставить единый централизованный способ управления процессом инициализации от начала до конца.
  • Он запускает и останавливает процессы и службы, отслеживая их зависимости. Он может даже запустить процесс в ответ на требование зависимости другого процесса.
  • Помимо запуска и остановки процессов во время загрузки, Systemd также может запускаться в любое время, когда система включена, в ответ на определенные триггерные события, например, когда устройство подключено к сети.
  • Также не требуется, чтобы процессы демонизировали себя. В отличие от SysV init, systemd может обрабатывать запущенные службы без необходимости проходить долгий процесс превращения в демонов.
  • В отличие от SysV init, systemd знает и отслеживает все процессы, включая PID, и получение информации о процессах намного проще для системных администраторов в systemd.
  • Systemd поддерживает контейнеры, которые в основном представляют собой изолированные сервисные среды без необходимости использования виртуальных машин. Это имеет большой потенциал для создания более безопасных и простых систем в будущем.

systemd-контейнеры

Конечно, это лишь некоторые из основных преимуществ. Для полного обсуждения преимуществ systemd вы должны прочитать Debian 8 "Заявление о позиции Systemd".

Полемика

Конечно, не все приветствовали systemd. Фактически, многие не одобряют и продолжают осуждать его, называя его монолитным и громоздким, а некоторые даже обвиняют его в том, что он идет по "оконному пути", когда все централизовано. Многие утверждают, что это не "путь Linux", и, конечно, systemd, похоже, не соответствует стандартам POSIX, и если мы рассматриваем systemd как набор инструментов (помимо двоичного), это определенно hugae.

systemd-инфографика

Тем не менее, systemd явно является шагом вперед, и хотя он не идеален, большая часть критики, которую он получил, была адресована его первоначальному автору и разработчику Леннарту Поеттерингу. Это определенно очень необходимое продвижение и шаг вперед по сравнению со старой системой инициализации. Линус Торвальдс, создатель Linux, похоже, не слишком возражает против systemd, и кто мы такие, чтобы спорить с "Создателем".

Заключение

Система systemd была принята во всех основных дистрибутивах Linux и никуда не денется. Что бы ни говорили некоторые системные администраторы по той или иной причине, systemd - это будущее основного Linux, нравится это отдельным пользователям или нет, что, учитывая его явные преимущества, не обязательно плохо.

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

47 комментариев

  1. Очевидно, что ваша статья дает субъективный взгляд на Systemd. Хотя SysV init может быть старым и неадекватным, действительно ли нам нужен огромный процесс инициализации, который делает все, кроме приготовления завтрака? Вы только упомянули о преимуществах Systemd. Это потому, что нет никаких недостатков DIS или потому, что вы хотите, чтобы читатели видели только положительные моменты и, таким образом, лучше относились к Systemd? Вы также не упомянули ни одного из новейших конкурентов init для Systemd.

    Я нахожу ваше Заключение высокомерным с его отношением "хочешь ли ты смешать?". Нам нужно знать о Systemd гораздо больше, чем то, что вы соизволили нам сказать, прежде чем мы примем его. Linux - это не Windows или OS / X, где разработчики говорят пользователям: "Это операционная система, и вам она понравится!"

    Не забывайте, что разработчики дистрибутива отказались от SysV init в пользу Systemd. Ничто не мешает им сбросить Systemd и все те замечательные вещи, которые он делает, в пользу какого-то другого процесса инициализации. На самом деле я уверен, что вскоре будет разработан еще один процесс инициализации для тех, кто не желает использовать Systemd. Сообщество Linux очень стойкое и находчивое. antiX и MX-14 не используют SysV init, а также Systemd-free. Есть и другие дистрибутивы, свободные от Systemd, названия которых я не могу припомнить.


    С вашим ответом возникли некоторые проблемы:

    1. Самый очевидный: люди, которые громче всех выступают против systemd, - это те, кто читал об этом на каких-то форумах и т. Д., А теперь повторяет то же самое снова. Без какого-либо отрицательного опыта или истинных причин не любить это. Вероятно, это заставляет их чувствовать себя умнее тех, кто даже не знает, что такое процесс инициализации. Возможно, они правы, и они действительно умнее, тем не менее, их отношение высокомерное, обычно потому, что они только заявляют, что "systemd ужасен", без объяснения причин или объяснений. Обычно это происходит потому, что они понятия не имеют, почему. Кто-то сказал это, и всегда здорово стоять с меньшинством "в курсе". ;) Вы один из таких?

    2. Естественно, что моя статья в пользу systemd, так как я поддерживаю systemd, и я написал статью. (Ого, такая логика.) Я не обязан быть объективным. Дело в том, что я ненавижу быть объективным. (Если бы я хотел им быть, я был бы журналистом, а я, очевидно, не так. Если вы хотите увидеть статью о недостатках systemd или статью, которая предупреждает людей об этом великом зле, вы можете написать ее.

    3, нет, это не высокомерие. Нравится вам это или нет, но systemd здесь (по крайней мере, на время), чтобы остаться, и это факт. И поскольку все основные дистрибутивы (и базовые дистрибутивы, такие как Debian) приняли его, у systemd долгое будущее. Практически никто не использует antiX или MX-14, по сравнению с производными Debian или RHL. Те немногие, кто их использует, могут чувствовать себя привилегированными и такими же превосходными, как и пользователи Mac ...

    4. Извините, что сломал вам это, используя antiX или другие неясные дистрибутивы, не делает вас экспертом, а критика systemd без объяснения причин только доказывает, что вы этого не понимаете. Если вы действительно хотите похвастаться, создайте LFS с настраиваемым процессом инициализации. или установите gentoo как минимум на 7 различных конфигурациях (с разным оборудованием). Это действительно влияет на вашу кривую обучения. Кстати, Gentoo использует OpenRC, так что вы можете быть "свободными" с ним.

    5, "без systemd" - это ажиотаж. Это может иметь смысл, но только с объяснением. Без него, высказывание "systemd вредно для вас" - это отдельное заявление. Докажите свою точку зрения, если она у вас есть, я называю это дискуссией.

    6, я отдал должное пострадавшим системным администраторам, которые не могут согласиться с тем, что sysvinit исчез, в разделе противоречий. Это все, чего он действительно заслуживает, особенно на веб-сайте, который предназначен для "Упрощения технологий", вместо того, чтобы вдаваться в "Почему я не могу адаптироваться к новым технологиям", как покажет случай большинства защитников sysvinit.

    7. Пожалуйста, просветите нас, какие преимущества получит средний пользователь от отказа от использования systemd? на практике я имею в виду. Чем изменится мир, если он перестанет работать с системой? Как среднестатистический пользователь Linux Джейн / Джо почувствует разницу?

    Я могу помочь: они не помогут. Пользователя Ubuntu большую часть времени даже не волнует, если его данные будут украдены. Но дело даже не в этом. Дело в том, что люди только почувствуют, что компьютер может запускаться быстрее. Systemd - это тоже улучшение стабильности. Так что, если вы не являетесь любовником Ричарда М. Столлмана, философский вопрос об использовании одной системы инициализации над другой остается чисто философским. Тем не менее, ваше мнение не изменит того факта, что основной Linux идет по пути systemd. И это факт. Нравится тебе это или нет. угадайте, что Торвальдс не против systemd (см. ссылку в статье). Вы умнее / знаете Linux лучше, чем тот, кто написал его ядро? Я сомневаюсь в этом.

    8. Укажите одну причину, по которой вы считаете systemd плохой, которая еще не обсуждалась на дискуссионном форуме или не обсуждалась его разработчиком (см. Ссылку в статье). Если вы найдете его и в нем есть смысл, тогда вы будете разговаривать ...

    Конечно, были моменты, в которых вы были правы:

    1, да, я был субъективен. (Я уже упоминал об этом, но я также согласен с вашим утверждением о субъективности. Мне просто нравится быть субъективным. И я также загружаю свою субъективность с помощью systemd. Ха!)

    2, "Не забывайте, что разработчики дистрибутива отказались от SysV init в пользу Systemd".

    Я не забыл. Поднимите руки тому, кто забыл. (Это все равно что заявить, что вода мокрая. То же самое имеет практический смысл.)

    3, "Ничто не может помешать им сбросить Systemd и все те замечательные вещи, которые он делает, в пользу какого-то другого процесса инициализации. ”

    Согласовано. А если они это сделают, будет еще лучшая система инициализации. Пока что есть systemd. Преодолей это.

    Теперь, чтобы ответить на ваши вопросы или поразмышлять над своими утверждениями:

    1: "Неужели нам действительно нужен огромный процесс инициализации, который делает все, кроме приготовления завтрака?"

    Да. Ходят слухи, что будущие реализации systemd смогут готовить бекон и яйца.
    (Это также доказывает, что вы не понимаете sytemd. Это не только процесс инициализации ... Объяснение того, почему, выходит за рамки небольшая статья, или хотя бы комментарии к ней)

    2: "Нам нужно знать о Systemd гораздо больше, чем то, что вы соизволили нам сказать, прежде чем мы примем его".

    Прежде чем мы примем это? Действительно? А теперь кто такой высокомерный. пожалуйста. Примите это или нет, но ваш дистрибутив уже сделал это, если вы занимаетесь чем-то мейнстримным, что, позвольте мне вам сказать, нравится среднему пользователю Linux. Так? Нужно ли им "принять это" или просто продолжать свою жизнь и использовать свое время для чего-то полезного (при условии, что у них действительно есть жизнь, то есть отсутствие которой можно увидеть, если потратят время на то, чтобы рассказать другим, насколько плохая система является.)

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

    3, "Linux - это не Windows или OS / X, где разработчики говорят пользователям:" Это операционная система, и вам она понравится! ""

    "Сообщество Linux очень гибкое и находчивое"

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

    Наконец, позвольте мне спросить вас:
    Где вы были, когда все дистрибутивы использовали sysvinit, который был медленным, устаревшим и бесполезным для многих вещей? У него было так много проблем, и он истекал кровью из такого количества ран, что было удивительно, что он все еще удерживался вместе. Тем не менее, вам и другим активным сторонникам "systemd - дело дьявола" некуда было возразить, что все основные дистрибутивы Linux выбрали sysvinit. Это было навязано вам, точно так же, как systemd "навязывается" вам сейчас. Почему это не повредило тебе глаз? Вы пользуетесь им уже много лет. Может, потому, что тебя никто не старик, когда кричать? Может быть, потому что никто не сказал вам, что это должно быть плохо для вас, поэтому вы не возражали?

    В заключение:

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

    Короткий ответ:

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

    Как всегда, дайте мне знать, если у вас возникнут дополнительные вопросы или вы все еще чего-то не понимаете, чтобы я мог объяснить / помочь. ;)

    P.S .:

    Прежде чем вы упомянули об этом (снова), этот ответ должен был быть максимально высокомерным. Видите ли, это высокомерно, а не мое заключение. Ваш комментарий был хорошей попыткой быть высокомерным, но, думаю, я просто опередил вас в этом. Я имею в виду это тоже. ;)


    (Кстати, спасибо, что прочитали мой ответ, если вы прочитали. Я не мог бы прочитать его сам)

    1. 1. Мне кажется, вы слишком много протестуете. В настоящее время я нейтрален, потому что я недостаточно знаю о systemd, чтобы принять осознанное решение. Если вы не считаете, что, поскольку я не сразу влюбился в systemd, я должен быть против. Вы говорите, как один из тех фанатов Windows. Если вам это не нравится, вы должны ненавидеть это.

      2. Нет опасности принять вас за журналиста. :-)
      "Если вы хотите увидеть статью о недостатках systemd или статью, которая предупреждает людей об этом великом зле, вы можете написать ее".
      Глупое заявление. Если бы я знал о недостатках systemd, я бы не спрашивал вас о них, я бы рассказал их вам недвусмысленно.

      3. Нет, не СЛИШКОМ высокомерный. Тот факт, что ВЫ не используете antiX или MX-14, не означает, что они хуже, чем все, что вы используете. Каждый из нас выбирает пойти в ад по-своему.

      4. Извините, что сломал вам это, но я никогда не утверждал, что я эксперт. Я тоже не разбил systemd. Вы делаете много предположений, и все мы знаем о "предположениях", не так ли?

      5. "systemd вреден для тебя" "- Докажи свою точку зрения. Покажи мне, где я это сказал, или ты снова предполагаешь?

      6, 7, 8. Пожалуйста, не приписывайте мне высказывания или чувства, которых я не выражал. Не подставляйте соломенных человечков.

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

      "Как всегда, дайте мне знать, если у вас возникнут дополнительные вопросы или если вы все еще чего-то не понимаете, я могу объяснить / помочь" - Думаю, я пройду. Очевидно, что вы либо не знаете ответов, либо не желаете отвечать честно. Если systemd настолько хорош, почему вы боитесь упомянуть о его недостатках? И, пожалуйста, не говорите, что их нет. ВСЕ ПО имеет недостатки.

      1. Краткая версия:

        1, частично

        2, да

        3, справа

        4, нет?

        5, нет

        6, 7, 8, Да, я буду, и вы не можете меня остановить.

        Полная версия:

        1. Конечно, знаю, я прирожденный протестующий. мои предки были протстаментами. протест у меня в крови. Что касается твоей "глупости оконного фанатика", я считаю, что это б..тье течет через тебя и заставляет писать эти вещи. В любом случае, если бы вы не были против systemd, вы бы не протестовали против этого и не говорили о "дистрибутивах без systemd".

        Или вам нужно прочитать более внимательно: статья была не о "новых процессах инициализации", "systemd и альтернативах" или даже "непредвзятом взгляде на systemd. Нет, я ясно сказал, что я полностью за systemd. Даже если тебе это не нравится. И угадайте, что я написал с этой точки зрения, протестуйте сколько угодно. :) НО, где-то глубоко внутри текста есть скрытая ссылка, которая ведет вас на веб-сайт "жить без systemd", на котором будут перечислены все его предполагаемые недостатки И еще одна ссылка с ответами на них. Так что, видите ли, все это есть, но вам нужно действительно прочитать, прежде чем вы решите, что "чего-то не хватает" (вы можете найти их в разделе "Полемика"

        Что касается вашей точки зрения: из некоторых комментариев, которые вы оставляете на этом сайте, я иногда думаю, что вы против. Неважно какой (за редким исключением).

        2, я всерьез надеялся, что меня никто не перепутает, я не очень люблю журналистов. конечно, заявление глупое. Я глупый человек. Мне нравится быть глупым и делать много глупых заявлений. Весь день. Каждый день. Мне это нравится. В любом случае, я, должно быть, пропустил ваш вопрос "Можете ли вы рассказать мне о недостатках", но увидел только ваше обвинение "Вы говорите, что недостатков нет?" Может быть, вам нужно поработать над своим стилем вопросов. это выглядит циничным. А на цинизм у меня только один ответ: глупость. Если вы не были циничным, тоже плохо: я все еще глупый.

        3. Не слишком высокомерный? Печалька. Тогда мне нужно поработать над своим высокомерием. Я всегда очень гордился тем, что был более высокомерным, чем кто-либо другой. Думаю, я все еще опередил ВАС, что доставляет мне огромное удовлетворение.

        Что касается вашего глупого заявления (да, вы тоже делаете это, хотя не уверен, насколько намеренно), я никогда не говорил ничего против любой из упомянутых вами систем. Я только говорю, что те, кто их использует, не будут лучше или знают больше, чем, скажем, пользователь Ubuntu. Лично мне очень нравится antiX, но для практических целей, например, для работы и совершения повседневных задач, Debian - это выбор дистрибутива. Я мог бы даже сделать обзор antiX. Скоро. Я посвящу его тебе. на изображении также будет дракон, спрятанный где-то. Если вы сможете разобрать его пасть, я буду громко аплодировать вам и признаться, что я фанат Windoze.

        4, вы не делаете? Во всяком случае, вы часто кажетесь всезнайкой. Я рад, что вы не обрушились на systemd. Тебе стоит попробовать это. Вам это может понравиться. Это действительно очень вкусно и лишь слегка затягивает.

        О предположениях: я все время делаю предположения. я большое предположение. Иногда мне кажется, что мир построен на предположениях. угадайте что, я люблю предполагать вещи. Жаль, что я не могу терпеть, когда другие предполагают что-то. Во всяком случае, я так полагаю.

        5, Нет, мне не нужно ничего доказывать. Видите ли, я твердо верю. Я хочу превратить systemd в религию

        6-8, почему бы и нет? это продвигает разговор вперед, иначе это оставалось бы только бессмысленным бредом и неопределенным разговором о том, что кто-то слишком про-что-то (хотя мы никогда бы не узнали, почему это было неправильно). Он немного приправил его, не так ли.

        Теперь к вопросам: вы ничего не спрашивали, как я могу ответить (на другие вопросы уже есть ответы, см. № 1 выше)

        Я говорю вам, почему я боюсь упомянуть об этих недостатках: я боюсь, что мир наконец обнаружит, что systemd ошибается. что это всего лишь попытка каких-то безумцев захватить мир 8, таких как я). Видите ли, если я раскрою свои планы, прежде чем захватить власть, я никогда не доберусь до нее. мне нужно, чтобы люди слепо следовали за мной и моей новой религией, о которой я говорю. вот почему.

        Есть еще такие серьезные вопросы? О да, о его недостатках. См. Мой ответ №1, чтобы узнать о ссылках в тексте ...

        "Я ожидаю, что меня проинформируют". - Вы можете быть проинформированы только в том случае, если вы действительно умеете читать текст, а не только отыскивать пропагандистские фрагменты, которые вам не нравятся, но и информацию, которую вы ищете. Здесь есть все, что вам нужно знать, что нужно знать другим, ну, это другой вопрос.

        Во всяком случае, я люблю пропаганду. Я хочу перейти к написанию правительственной пропаганды, надеюсь, к какой-нибудь милой маленькой диктатуре где-нибудь в Сахаре. Считаю это своей тренировкой

        9, спасибо за доказательство точки зрения Люка Джонса (комментарий под вашим)

        10. Как всегда, я все еще здесь, чтобы прояснить ситуацию, если вы все еще не нашли ответов. если вы все еще не уверены, не стесняйтесь спрашивать. :)

      2. Это явный признак, когда так много сторонников системы занимают такую ​​оборонительную позицию и настроены оптимистично, когда пытаются убедить других. Для тех из нас, кто просто хочет ясную, беспристрастную информацию без какого-либо коммерческого предложения, это в некоторой степени показательно, что если systemd действительно является решением (что некоторые считают) проблемой, за этим стоит очень много споров.

        1. Неправильный. Он был личным. выкрикивая такие имена, как "Windows fanboy и т. д. Я не защищаю systemd, я пишу против человека, чьи комментарии на этом сайте обычно такие, что" то, что вы пишете, не имеет смысла, я знаю лучше ". Мистер Рот имеет солидную историю. И его "вопросы" (которых не было) ничего не добавляют к обсуждению. Посмотрите ниже, там есть реальные люди с настоящими мыслями, а не только какие-то ожесточенные клавишники, которые все комментируют, но ничего не ценят. мои издевательства - это ответ на цинизм и высокомерие, .. только я делаю это лучше. Опять же, для реального обсуждения читайте ниже. если вы осмеливаетесь столкнуться с противостоянием своим собственным взглядам. :П

        2. И "для тех из вас, кто просто хочет ясной, беспристрастной информации", позвольте мне сказать вот что: в статье есть ссылка, которая приведет вас на веб-сайт, который поставил перед собой задачу избавить мир от systemd. у них есть вся необходимая информация, чтобы знать, в чем могут быть недостатки системы инициализации. Чтобы сохранить баланс, я также связался с сайтом, который использует распространенные "мифы" о systemd и должным образом их объясняет. Вывод (ваш собственный вывод) зависит от вас. но заключение статьи оставалось за мной, и я уже явно выбрал свою сторону (не выбирая стороны, правда, я ничего не имею против других систем инициализации или даже sysv, но вижу его недостатки, вот и все).

          Думаю, объективной информации здесь предостаточно. Суть статьи была в другом: если вы используете основной дистрибутив и собираетесь выпускать никогда не выпускаемый, значит, вы уже используете systemd. Я хотел объяснить, чего от этого можно ожидать, вот и все. если вы хотите беспристрастных дискуссий ... ну, вы правы, их не так много. С таким же успехом я мог бы придумать такой в ​​будущем, но эта статья не об этом.

        3. "Это явный признак того, что так много сторонников systemd так защищаются и настроены оптимистично, когда пытаются убедить других. ”Это, вероятно, потому, что так много cr * p написано о systemd, о том, что это такое, что он делает и т.д. самый большой-migs.html

          "Для тех из нас, кто просто хочет ясную, беспристрастную информацию без какого-либо коммерческого предложения, это в некоторой степени показательно, что если systemd действительно является решением (что некоторые считают) проблемой, за этим стоит очень много споров". Здесь можно начать читать http://www.freedesktop.org/wiki/Software/systemd/

  2. Я действительно абсолютно не понимаю позицию, которую заняли многие из сторонников антисистемы.
    В половине случаев это звучит / кажется, что они просто завидуют тому, что Леннарту удалось сделать то, что он сделал.

    * Единственная * обоснованная критика, которую я слышал, касается двоичного журнала. И на это я говорю; двоичное ведение журнала предлагает гораздо более мощное ведение журнала и диагностику, чем ведение журнала в виде обычного текста.
    "о, но оно может быть повреждено"
    Да? Так может и обычный текст.

    Systemd чертовски хорош, быстр и прост в использовании.
    Я чертовски рад, что основные дистрибутивы приняли его.


    Я тоже не разбирался в двоичном журналировании, пока не прочитал, на что он способен. Я все еще не совсем уверен в этом, возможно, была бы лучшая реализация / или способ достижения аналогичной функциональности, но это выходит за рамки моих знаний / опыта, поэтому я не буду судить. Бинарные журналы Systemd очень эффективны, и это факт. Так что да, я полностью с вами согласен.


    Раньше я был против двоичного журнала. Однако systemd не заставляет вас оставаться с journalctl. На самом деле вы можете отправить journalctl в системный журнал локально или на центральный сервер системного журнала. также вы можете использовать такие инструменты, как grep / sed / awk, с journalctl.

    Я думаю, что мои единственные оговорки к systemd будут заключаться в том, что это фреймворк, а не простая система инициализации. Хотя у меня нет доказательств только теории, это было бы катастрофой, если бы произошел серьезный сбой, и systemd, возможно, мог бы вывести из строя всю систему, потому что он каким-то образом контролирует другие процессы. Однако я думаю, что это может произойти и с sys v.

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

    Однако вы отметили одно чрезвычайно важное замечание: насколько это действительно повлияет на большинство людей. За 12 лет работы в качестве администратора / пользователя Linux я могу рассчитывать по одной руке, когда мне приходилось возиться с Sys V, чтобы выйти за рамки нормы.

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

    1. Спасибо за информацию, я не знал этого о journalctl. Это делает ведение журнала systemd еще более привлекательным в моих глазах. :)

      Я не думаю, что сценарий катастрофы действительно произойдет. я имею в виду, что это фреймворк, но не как "провал выльется наружу". есть шестьдесят с лишним двоичных файлов, что означает правильное разделение. где-то была отличная статья (ссылка на которую есть в моей статье), которая фактически объясняет, как работает разделение, есть надлежащая изоляция (возможно, даже более подходящая, чем в sysv). Таким образом, компоненты СОСТАВЛЯЮТСЯ отдельно, это одна вещь, которую люди неправильно понимают в отношении systemd (возможно, в результате такой большой антипропаганды): Марк Шаттлворт из Canonical однажды назвал systemd монолитной. С тех пор люди повторяют его точку зрения. Дело в том, что Canonical фактически перешла на systemd. И Шаттлворт изменил свое мнение о монолитности, поскольку был дан ответ (и объяснение) тому, что он принял за монолитную систему инициализации. Проблема в том, что люди слушают только сенсационные новости (Canonical bashing systemd) и редко следят за ними (Canonical фактически признает свою ошибку и даже принимает systemd).

      Я не возражаю против вашей бессвязной болтовни, они вносят вклад в обсуждение, так что, пожалуйста, продолжайте болтать. :)

    2. Я думаю, что вам нужно настроить journald (через journald.conf) для пересылки журналов в syslog / rsyslog. journalctl - это мощный зверь, который позволяет вам проверять журналы, а также вы можете направить его вывод в grep / awk и т. д. journalctl делает двоичное хранилище журналов подходящим.

      1. Я тут делаю заметки ... :)

  3. Помимо высокомерия….

    Зачем чинить то, что не сломалось? SysV init у меня отлично работает. Я предпочитаю медленную загрузку и хранить все ОТДЕЛЬНО (конфигурации, журналы, сценарии инициализации и т. Д.)

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

    Время покажет. А пока мне нравится, когда вещи простые и отдельные.

    Серьезно люди, мы беспокоимся о времени загрузки? Скажите производителям серверов, чтобы они исправили чертовски долгое время загрузки оборудования. Это занимает намного больше времени, чем требуется для загрузки SysV init.


    Мое высокомерие - всего лишь хобби. (Но спасибо за признание, я много над этим работаю.)

    Если отбросить хобби, я думаю, вы не совсем понимаете сценарий. Этот аргумент "зачем чинить то, что не сломано" - часто повторяемый аргумент, но я не думаю, что вы, ребята, повторяя его, действительно обдумывали его.

    SysVInit не исправлен, а systemd не является исправлением.

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

    Systemd - это замена. Это совершенно новая система инициализации, целью которой является не исправление того, что не работает в sysvinit, а предоставление альтернативы.

    Разница такая же большая, как между постройкой дома и обучением плаванию, если отойти от IT. В терминах Linux, думайте об этом как об установке новой версии, скажем, OpenOffice, с исправлениями ошибок (исправление), вместо установки LibreOfice, которая дает альтернативу (замену): это не означает, что OpenOffice сломан. это означает, что теперь вы используете что-то еще (LO) с аналогичной функциональностью, что, вероятно, работает лучше для многих вещей.

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

    Возьмем, к примеру, системный вызов "kill". В UNIX это делается с помощью сигнала 0, отправляемого процессам. если PID, о котором поступил сигнал, не связан с процессом, вызов kill просто завершится неудачей (кроме того, что звучит забавно, чтобы сказать вызов kill. Попробуйте повторить это: kill-call-kill-call-kill-call. Забавно, не так ли? разве это?)

    Теперь в sysvinit процессы должны демонизировать себя (см. Статью). к тому же это долгий и громоздкий процесс (15 шагов, ссылка в статье). Само по себе это имеет мало смысла, но также приводит к тому, что система инициализации не имеет представления о PID, связанных с процессами.

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

    Нет никаких гарантий, что данная услуга все еще работает! Если процесс, первоначально запущенный сценарием инициализации, был прерван в то время, ядро ​​могло повторно использовать PID и полностью передать его другому процессу, это может означать, что неправильный процесс будет убит!

    Конечно, есть обходной путь для этого, теперь это обходной путь обходного пути: помимо проверки файла PID, также необходимо проверить / proc / $ pid / exe, если PID stillb принадлежит правильный процесс, после которого сигнал 0 может быть безопасно отправлен.

    Теперь вы видите, что такая простая вещь, как завершение процесса, требует обходного пути, вложенного в обходной путь в sysvinit.

    (И вы знаете, что произойдет, если вы воспользуетесь множеством обходных путей? Возникнет особенность, когда сначала взорвется голова Линуса Торвальда, затем он сольется с Биллом Гейтсом, и появится новый великий монстр, которого никто не осмелится представить! К счастью, вы нужно всего лишь вложить два обходных пути для этой простой задачи…)

    В любом случае, не было бы лучше, если бы система инициализации знала PID служб И состояние любой данной службы? И его зависимости? Systemd делает ... Таким образом, уничтожение процесса означает просто отключение сигнала 0 для правильного PID, без предварительной перекрестной ссылки с Encyclopedia Britannica. намного проще.

    И это был только ОДИН из множества обходных путей и недостатков в sysvinit. Приводится один простой пример. есть еще много чего. Systemd не исправляет это, но заменяет некоторые плохие варианты дизайна, не предназначенные для современных систем Linux, лучшими вариантами. наверное, не идеальные, но лучшие. дело в том, что sysvinit, возможно, был отличной системой инициализации 30 лет назад на тогдашних современных системах UNIX, но сегодня системы эволюционировали, перетаскивая за собой sysvinit и исправляя его по ходу дела. В исправлении нет необходимости, но замена может иметь много преимуществ.

    Что касается медленного процесса загрузки: systemd не о скорости. Повышение скорости - это эффект, но не цель (каламбур).

    Насчет "держать все ОТДЕЛЬНО"… опять же мантра. Мне действительно интересно, как люди могут повторять что-то, даже не потрудившись сначала прочитать об этом.

    Обратите внимание на эти строки оригинального автора systemd:

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

    Таким образом, важно, чтобы systemd был хорошо разделен на многие двоичные файлы и, следовательно, процессы. Фактически, многие из этих двоичных файлов настолько хорошо разделены, что они очень полезны и за пределами systemd ".

    Как же это не быть отдельным? Под журналами, если вы имеете в виду, что ведение журнала является двоичным, это правда, но это не означает, что оно не ведется отдельно. Я рекомендую вам прочитать документацию по sytemd, чтобы лучше понять, как это работает.

    Это альтернатива, а не исправление. Он предлагает улучшенную функциональность. Придерживаться sysvinit - все равно что придерживаться текстового процессора Commodeore 64, когда доступен MS Word или LibreOffice. Вы можете выполнять свою работу с ним, но другие более современные и предлагают лучшую функциональность. Конечно, тот, кто не найдет времени, чтобы хорошенько их рассмотреть, прочитать или попробовать их, скажет, что они раздуты и что решение Commodore намного аккуратнее (см. Мою предыдущую статью о приложениях для письма без отвлечения внимания. , есть примеры работ таких людей в реале. Без ущерба, конечно.)

    И снова: systemd не упирается в время загрузки. Более быстрая загрузка - это лишь приятный побочный эффект. И я не думаю, что производители серверов заинтересованы в улучшении времени загрузки, так как серверы (в идеале) перезапускаются очень редко. Однако для пользователей настольных компьютеров время загрузки может иметь огромное значение. Тем не менее, дело вовсе не в systemd.

    Конечно, есть много дистрибутивов, которые до сих пор не используют systemd, но основные, похоже, приняли его, поэтому systemd проработает как минимум несколько лет (пока Debian остается на нем, большинство производных также будут). если должен появиться какой-либо новый дистрибутив, вероятно, лучше не возвращаться к sysvinit, а выбрать альтернативу, будь то systemd или что-то еще (многие были упомянуты в статье). Systemd пока что является лучшей заменой. если все пойдет хорошо, это будет вдохновением для разработчиков на создание еще лучших. путь вперед, но не назад, в любом случае.

    Наконец: Могу я задать вам тот же вопрос, с которым я столкнулся с пастью дракона, выше:

    В чем именно у вас проблема с systemd? Из личного опыта / понимания, конечно, не считая системной пропаганды.


    Вау, я сделал опечатку, закрывая блок кода, и посмотрите, что произошло. это конечно тоже вина sysvinit! :П


    Вам действительно стоит настроить тестовый сервер с помощью systemd и использовать его некоторое время. Да, это кривая обучения, но есть много преимуществ, особенно если вы использовали journalctl несколько раз, это сэкономит вам массу времени в долгосрочной перспективе. Более быстрая загрузка является побочным преимуществом, а не причиной, но помогает тем, кому приходится перезагружать экземпляры виртуальных машин, когда время загрузки "дорого", если оно медленное. Вы не должны просто отклонять это из-за нескольких антипостеров, которые публикуют о systemd что-то, что не соответствует действительности и является откровенной ложью.

  4. Ух ты! Это одна из самых информативных и разумных статей о systemd, которые я когда-либо читал. Спасибо.


    Спасибо за чтение!

  5. Небольшой комментарий о тех, кто утверждает, что systemd огромен и монолитен. Я не уверен, откуда вы взяли свои диаграммы, но одна диаграмма неверна. "Systemd pid 1" не содержит logind, journald, networkd, user session. pid 1 содержит только systemd, который очень мал и имеет минимальную функциональность. PID 1 очень особенный в unix и имеет особые возможности. Чем меньше работает в pid 1, тем лучше. Критики systemd часто говорят, что systemd кладет все в одну корзину. Это не. logind, journald, networkd и user session - все остальные демоны, которые не работают в pid 1. Это правда, что systemd требует, чтобы journald был запущен. Но все остальные части строго необязательны. И некоторые части, такие как networkd only, полезны в ограниченных ситуациях, таких как контейнеры, как и демон преобразователя имен.

    На самом деле systemd - это просто зонтичный проект для ряда дополнительных сервисов и демонов, которые могут работать вместе, которые становятся все более важными во многих аспектах современного использования Linux, включая виртуализацию, контейнеры, серверы, ноутбуки, системы динамического хранения, такие как Fibre Channel, USB и т. Д. , ситуации, когда традиционные системы инициализации действительно не справлялись.


    Hy,

    Спасибо за добавление. Я уверен, что те, кто утверждает, что он огромный и монолитный, просто не совсем понимают, как это работает. Люди путают init, как в PID1, и init, как в "систему инициализации" (то есть все отдельные скрипты и двоичные файлы), и, повторяя только то, что они читают на форумах, не задумываясь и не задумываясь, они совершают ошибку, называя что-то огромные в неправильном направлении. Я бы назвал systemd огромным (как и в целом), но он скорее огромен в том смысле, как вы бы назвали его надежным, чем монолитным (что не так).

    Я только что заметил ошибку, которую вы заметили на диаграмме. это взято из Википедии (неужели я забыл указать изображение? ma ’bad). Вы правы, это неправильно. В любом случае, это было предназначено для иллюстрации того, как процессы могут работать в своих собственных безопасных контейнерах. Конечно, подобное неверное толкование не принесет много пользы для приема systemd, даже если намерение было хорошим. Я мог бы просто изменить изображение позже, чтобы не было неправильного представления о PID1. (Если будет время). до тех пор, надеюсь, люди прочитают достаточно, чтобы увидеть ваш комментарий.

    Еще раз спасибо за чтение и за ценный вклад.

  6. Systemd против других систем инициализации ... Это как emacs vs vi.

    Прямо сейчас единственное, что заметит "средний" пользователь, - это более быстрая загрузка своего компьютера и большая совместимость между дистрибутивами (что означает, что больше программного обеспечения будет упаковано для всех популярных, а не для одного или другого). Это хорошие вещи. В ближайшем будущем они заметят совсем другое ...

    Я ожидаю, что скоро появятся десятки новых систем инициализации (и я виноват в том, что внес свой вклад в эту проблему - я пишу свою собственную). Это может показаться не таким уж плохим, но это так. Видите ли, многие "средние" пользователи Linux полагаются на своих дружелюбных технических специалистов по соседству, и многие (как минимум 10%?) Из них скажут: "Извините, я могу помочь, только если вы используете [неосновной дистрибутив с предпочитаемым неясным init ] ".

    Это вызвано недоверием к разработчикам systemd. Частично это из-за воспоминаний о pulseaudio, частично из-за того, что пришлось слишком рано иметь дело с systemd в передовом дистрибутиве, частично из-за другого недоверия к redhat / gnome, частично из-за внешнего вида, который делают разработчики systemd не имеют плана и просто модифицируют все, что они получают в руки, способами, которые не имеют смысла, а также есть технические причины, по которым systemd выглядит как плохой дизайн (и я не буду перечислять их, потому что все думают Наборы хороших и плохих характеристик различны).

    Итак, что делать, будучи программистом? Продолжение использования sysvinit - не реальный вариант, теперь недостатки были отмечены, systemd - не вариант, если вы не доверяете разработчикам складывать функциональный бумажный самолетик, другие inits в порядке (мне нравятся runit и s6), но не достаточно хорошо, теперь кто-то думал о том, как должны работать init и надзор за демонами ... Да, один пишет свои собственные, несовместимые со всеми другими людьми, которые пережили те же мысли.

    Было бы лучше оставить достаточно хорошо в покое. Sysvinit достаточно хорошо загружал наши системы, я никогда не видел никаких жалоб, кроме как от любителей "быстрее, быстрее, БЫСТРЕЕ" и "изобретено не здесь" компании Canonical. Сейчас настал момент немного большей стандартизации, прежде чем Linux снова оправдает свою репутацию среди нетехнических пользователей.

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


    Я не могу с этим согласиться. Прежде всего, Linux - это выбор, как всегда. Тем не менее, то, что sysVInit был инициатором "перехода" для большинства дистрибутивов, вообще не походил на выбор. Теперь то, что Systemd является "единым целым", тоже не похоже на большой выбор, так что, вероятно, его появление может быть хорошим признаком. Подумайте о естественном отборе: выживет только действительно достойный.

    Но разработчики придумывают свои собственные инициативы на каждом углу (и никакого неуважения к вам), это похоже на системную истерию. Эти индивидуальные инициативы могут работать для них и небольшого сообщества, но для того, чтобы завоевать популярность, они должны быть приняты одним из крупных дистрибутивов. Это вряд ли произойдет. и истерия либо будет медленно утихать, либо, что является лучшим сценарием, примет более значимую форму, например, в форме создания сообществ, которые представляют собой сотрудничество между людьми, а не индивидуальные усилия. Для меня последний путь был бы наилучшим из возможных.

    Тем не менее, systemd никуда не денется и какое-то время будет присутствовать во многих системах. Debian теперь на systemd. Это большая часть мира Linux (все производные) будет на нем. Поскольку Fedora (RHL) Ö и SUSE также следует за пакетом, systemd УЖЕ является наиболее широко используемой заменой sysvinit. Такие большие дристро часто действуют медленно (вспомните Debian), и их решения непросты. Также Debian означает бизнес (см. Ссылку на их обсуждение systemd) и, вероятно, останется на systemd на какое-то время.

    Однако я вижу это, и в этом мы согласны, что systemd что-то запустила: люди понимают, что есть жизнь за пределами SysVInit, и это хорошо. На мой взгляд, каждое начало сложно, с этим шагом Linux просто перешел на новый уровень и стал еще более отличным от своих предков UNIX. Я беру сдачу за хорошее дело. А это залог прогресса.

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

      Изменения происходят в незрелых системах. Очевидно, Sysvinit очень зрелый. Systemd - нет, и хотя я бы с огромным уважением относился к нему как к исследовательскому проекту, я не думаю, что он подходит для компьютеров, которые люди используют для своей повседневной скучной работы. Весь прогресс - это изменение, но для случаев использования, когда дальнейшее улучшение невозможно, любое изменение является потенциальным регрессом. Помимо загрузки на несколько секунд быстрее (чего также можно добиться с помощью менее инвазивных изменений), есть ли что-нибудь, что нужно улучшить для "среднего пользователя", который в настоящее время использует sysvinit, даже не подозревая о существовании программного обеспечения? Ну, их компьютер загружается каждый раз, когда они его включают, не так ли?

      Systemd может быть "здесь надолго" или исчезнуть через несколько лет. Помните статический / dev? Был заменен на devfs, который затем вместе с hotplug был заменен на udev, и, если я правильно понял, udev как часть systemd теперь будет заменен чем-то другим. Между тем в моей системе OpenBSD * есть статический / dev и простой сценарий оболочки, который обрабатывает события, вызванные подключением / удалением оборудования, и это прекрасно работает. Так для чего же было все это сложное программное обеспечение, передаваемое через Linux? Мне кажется, что только простые решения, которые работают хорошо, как правило, остаются в силе надолго.

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

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

      Я думаю, что разочарование по поводу зрелости программного обеспечения может быть одной из более глубоких причин споров о systemd. Каждый раз, когда операционные системы на базе Linux начинают работать надежно и предсказуемо, кто-то из влиятельных людей вызывает большие изменения (см. Также: KDE 4, GNOME 3). Ну, может быть справедливо, что люди, которые больше заинтересованы в заведомо работающем программном обеспечении, чем в том, что новое и интересное, должны прилагать больше усилий.

      *) Я использую Linux из-за проблем с аппаратной совместимостью среди других причин

      1. Я думаю, что мы здесь немного перемешиваем. Обычный пользователь в долгосрочной перспективе выиграет от гораздо более надежных систем, которые могут быть разработаны и, надеюсь, будут разработаны с переходом от sysvinit. Это было зрелым, да, но зрелость хороша только до тех пор, пока она не мешает прогрессу. Сысвинит сделал. Его конструкция подлежала замене. (Я уже записал все свои аргументы по этому поводу, либо в статье, либо в комментариях где-то здесь).

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

        Подумайте о простом примере, когда sysv не знает PID и состояния процессов. сколько раундов нужно было сделать, чтобы что-то убить? Зачем тратить время и время разработки на то, чтобы заставить процессы демонизировать себя и т. Д.? Кажется, вы прославляете sysvinit далеко не за его достоинства. это сработало да, но это не сработало идеально.

        Я не говорю, что systemd - лучшее решение. Я говорю, что изменения были необходимы, и сейчас мы видим, как дела идут. Таким образом, либо systemd, либо все, что приходит после, может получить время, необходимое для того, чтобы хорошо созреть. В любом случае, я не понимаю, почему systemd был таким вредным или плохим. Мне пока не кажется, что какое-либо обсуждение какого-либо системного "отрицателя" имело бы смысл даже для той интерпретации, которую мы видим сегодня.

        Ваши аргументы более разумны, чем те, что говорят "блин, systemd", поэтому я действительно хотел бы знать, почему вы думаете, что это не стоит использовать. Почему бы ему не найти место на рабочих лошадках? у меня есть, и никаких разочарований (у меня было гораздо больше проблем с системами sysv и даже с OpenRC Gentoo)

        Я вижу, к чему вы клоните, разочаровавшись в зрелости программного обеспечения, но я не могу согласиться с теми, кто избегает systemd по этой простой причине. Вы видите, что прогресс достижим только путем перемен, и все мы жаждем прогресса. Проблема в том, что существует просто психологический фактор сопротивления изменениям и приверженности общеизвестному (что дает чувство безопасности) во всем в нашей жизни. Так устроен наш мозг. Я вижу, что сопротивление во многом проистекает из того факта, что действительно трудно отказаться от старых привычек (30-летней привычки, если быть точным), даже если они могут навредить вам (когда-нибудь пытались бросить курить?)

        Мне кажется, что systemd - не новый проект. Это было достаточно времени, чтобы люди начали применять его в повседневном использовании. Это отражено в решении Debian, и они не просто кинулись к нему, но довольно четко изложили свою позицию (ссылка в статье). И это (активное использование) - единственный способ обрести настоящую зрелость. Придет время, когда я буду защищать и ваши серверы, но только если мы дадим этому не только время, но и шанс. Пользуюсь им много месяцев без каких-либо проблем. мой компьютер (который требует немалых усилий, от безумного O / C до требовательного использования) более стабилен, чем когда-либо.

        Наконец: забавно, что вы указываете на OPpenBSD, а затем указываете саму причину, по которой зрелость не означает полезности. Вы можете сказать, что openBSD в целом зрелая, но ее использование сильно ограничено аппаратной совместимостью и т. Д. В реальном сценарии, нужно принимать во внимание несколько сторон истории, и, на мой взгляд, systemd достигает этого лучше, чем sysv сделал.

        1. Контроль процесса ("знание PID и состояния процесса") - отличная функция (которую я обязательно буду реализовывать). Он также существует уже давно, наиболее известен в daemontools и его почти клонах, таких как runit, s6 и т. Д. Для его получения даже не нужно было заменять sysvinit на них, можно выполнить первые шаги загрузки и если кто-то хочет также запустить некоторые демоны со старым init, тогда используйте daemontools-подобные, чтобы контролировать (остальную часть) демонов. Более того, можно легко реализовать "сложный" процесс демонизации, необходимый для sysvinit, скопировав одну из программ из подобного daemontools и заключив ее в тривиальный сценарий оболочки, который намного проще, чем сценарии оболочки, которые вы обычно видите упакованными для использования с sysvinit.

          Итак, если наблюдение за процессом имеет значение в реальном мире, мне интересно, где находятся все пользователи runit и разработчики демонов, копирующие из runit?

          Мне очень понравились ранние записи в блоге Леннарта Поеттеринга о systemd, очень интересные. Мне не очень понравился systemd, когда Archlinux начал говорить пользователям о переходе на него по той простой причине, что у меня это не сработало. Или, возможно, что-то не так с документацией, что, конечно же, приводит к тому же результату, что и ошибка в самом программном обеспечении. Это был большой шаг назад по сравнению с простым для понимания файлом конфигурации, который Arch имел до systemd. До этого я помню, как исправлял проблемы со звуком в нескольких системах, просто удаляя pulseaudio (также сделанный Poettering). Совсем недавно Кей Сиверс отказался признать, что атака ядра systemd DOS была ошибкой, Линус Торвальдс сказал об этом несколько приятных слов.

          Я готов поверить, что проблемы с pulseaudio были вызваны его функциями, обнаруживающими ошибки в ALSA. И теперь он обычно работает безупречно и очень полезен, когда у вас есть USB-гарнитура, поэтому он принадлежит * некоторым * производственным машинам.

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

          Systemd-the-large-project, однако, находится в состоянии, когда все еще вносятся большие изменения. Поскольку он был разработан людьми, чье прошлое программное обеспечение КАК-ТО попало в "стабильные" дистрибутивы задолго до того, как оно перестало быть взломанным, я бы ему не доверял. Если это сработает для вас и будет продолжать работать, несмотря на все предстоящие изменения, вам повезло.

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

        2. Дойдя до конца вложенных ответов, кнопка не появляется… вот драконы. : D

          На этот раз я буду проще, чтобы мы не сломали вселенную (у меня есть и другие дела, эта статья выходит из-под контроля.) :)

          Если имеет значение надзор за процессом? Я не понимаю, почему этого не должно быть. Упомянутое вами "решение" было лишь обходным путем. Заплаты и обходные пути не означают прочную основу, они указывают на базу, полную дыр, которые необходимо залатать, и препятствий, которые необходимо устранить. Это имеет смысл в верхней части init IMO, и я, кажется, не одинок с этим.

          Что касается упомянутых разработчиков, они, похоже, не добились того успеха, который Poettering накопил за эти годы. Pulseaudio, несомненно, сработал в его пользу: люди слушают, что он говорит, согласны они или нет. :) Немного политического. Но, если вы спросите меня, он очень умно этим пользуется.

          Но в целом я ожидал более "конкретного" ответа на вопрос, что может не сработать. Вы говорите, что вещи сломаются или могут сломаться. Что конкретно? Как и почему они сломались? Как узнать, сломаются? aAd почему они еще не сломались? Или, если они сломались, то что они были и почему не ломаются сейчас? вкратце: что может помешать среднему пользователю Linux Джейн / Джо использовать дистрибутив на основе systemd для повседневной работы? на практике. Повседневная практика (не теория или вероятность).

          Назначить систему приготовления сусла чистой удаче - все равно что верить в волшебство, извините, но я не считаю себя "просто удачливым", потому что мне не пришлось трогать init с тех пор, как я установил Debian. Сравните это с двумя неделями настройки моего последнего Gentoo, после которых я все еще сталкивался с проблемами. Мне нравится настраивать, но в наши дни я больше сосредоточен на написании (на этом сайте и в других проектах), у меня мало на это времени. Debian "просто работает", и я не единственный "счастливчик", есть еще несколько миллионов. по цифрам можно просто сказать, что если что-то сломается, человеку не повезло (или он что-то сильно облажался).

          Мне кажется, что вы оцениваете systemd на основе более ранней интерпретации, выдвинутой (по глупости) Arch и Fedora и другими "передовыми бессмысленными" дистрибутивами (извините, я не считаю "передний край" хорошим, если только это не сохранены только для тестирования и не превращены в системы, которые люди используют для повседневной работы (даже будучи бывшим энтузиастом Gentoo). И в этом вы могли быть правы, когда Arch впервые заставил людей переключиться, возможно, он был не полностью готов и, возможно, даже вызвал проблемы.

          Дело в том, что сегодня есть сегодня. И сегодня мы видим, что даже медленно развивающийся Debian переключается. Что касается того, насколько это "удобство", я считаю, что Debian сделал свое дело: https://wiki.debian.org/Debate/initsystem/systemd

          Видите ли, есть много умных людей, которые уже оценили systemd и даже протестировали его. Debian печально известен своим тестированием: если что-то становится стабильным, это обычно означает стабильный, как в STABLE, не всегда, но большую часть времени. Мой опыт показывает, что Debian 8 так же стабилен, как и любой предыдущий выпуск.

          Для удобства Canonical возьмем их первоначальную оппозицию systemd. Они продержались какое-то время, даже разжигая некоторые недоразумения (и старую простую BS) вокруг systemd, но потом они просто передумали.

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

          Что касается ваших аналогий с Pulseaudio, я понимаю вашу параллель, но такие вещи, как "устранение проблем со звуком путем простого удаления Pulseaudio", подобны хирургу, исцеляющему пациента, просто удаляя поврежденный не жизненно важный орган. Это ярлык, а не реальное решение, не так ли?

          И, несмотря на все это, оценка программы на основе предыдущей работы ее автора и споров вокруг нее) не кажется хорошей (или разумной) практикой. IMO SW следует оценивать на основе его собственных достоинств (кроме того, вы были готовы поверить, что проблемы пульса на самом деле связаны с ALSA ... что приводит нас к более философскому вопросу:

          Если ПО выявляет ошибки в другом коде, что делает систему нестабильной, чья это вина? Новое программное обеспечение может рассматриваться как нарушитель. старый зрелый код сидел там, молча исправляя свои ошибки, прежде чем он был обнаружен новичком. И что нам делать, чтобы это исправить? Удалите нарушителя и закройте глаза на основную проблему (ошибку). Если он не открыт, мы его не видим. Если мы этого не видим, это не повредит. Но это долгосрочное решение или быстрое исправление? Я имею в виду, что истинным преступником по-прежнему является старая "зрелая и стабильная" программа, ошибки которой мы блаженно не знали. теперь наш мир обеспокоен чем-то новым: мы виним новое, потому что привыкли к старому. (человеческое психическое сопротивление изо всех сил сопротивляется изменениям, это всего лишь психология, но я думаю, что уже где-то здесь это записал.)

          Я хочу сказать, что использование systemd может выявить и другие проблемы. Возможно, стоит оценить любую нестабильность, явно вызванную этим, чтобы найти корень проблемы, это может привести только к улучшенным системам. НО: Вы не привели конкретных примеров. (Ошибка, о которой вы упомянули, была, если я не ошибаюсь, уже исправлена. Реакция Сиверса была неудачной, но это все еще один человек). Вы правы, в будущем может быть что угодно. но настоящее говорит об этом (кажется, что все "просто работает". Конечно, systemd все еще работает, но "стабильные" дистрибутивы (стабильные, похожие на Debian, которых на самом деле немного), не будут вносить изменения, как только они выпущены. И это хорошо. Реклама для других дистрибутивов, которые мало заботятся о стабильности и спешат предлагать яркие новинки, просто чтобы быть в "новостях" ... это вина разработчиков дистрибутива, а не разработчиков systemd, если вы спросите я. Между тем, я доволен тем, как работает Debian (хотя они, как говорили, переходят на более высокую передачу с выходом новой версии чаще, в чем я не уверен, но помимо того, что готовлю свой собственный дистрибутив, для которого я все еще не находите времени, хороших альтернатив не так много (дайте мне знать, если вы знаете некоторые из них).

          Как бы то ни было, последнее слово о systemd мне сказал сам Торвальдс:

          "На самом деле у меня нет особо твердого мнения о самом systemd. У меня были проблемы с некоторыми основными разработчиками, которые, на мой взгляд, слишком бесцеремонны в отношении ошибок и совместимости, и я думаю, что некоторые детали дизайна безумны (например, мне не нравятся двоичные журналы), но это детали, а не большие проблемы ".

          Хм. "Детали, не большие вопросы". И вот что большинство людей ошибается: они хватаются за детали, чтобы оправдать любое незначительное возражение, которое они могут выдвинуть против чего-то, что, несмотря на всю шумиху и антипропаганду, кажется, прекрасно работает.
          на примечание: меня начинает интересовать ваша система инициализации, возможно, вы можете крикнуть мне, когда будете готовы. Вы кажетесь более разумным, чем большинство разработчиков, с которыми я работал: D

          PS: Извините, я обещал быть кратким. просто вроде не бывает ...

      2. К тому же цвет вашего аватара не соответствует вашему имени. Жалко тоже…: P


    Но да, ваше первое замечание о emacs vs vi звучит вполне правильно. :)

    1. Почему я еще не могу выполнить "M-x C-y bootystem"? Похоже, что в emacs отсутствуют некоторые жизненно важные функции! : ^)

      1. : D

  7. Systemd предназначен для первых пользователей и нуждается в пользователях. SysV init работает нормально. Надеюсь, Systemd оправдает себя после 30 лет использования (как и SysV init). Я прочитал достаточно аргументов, чтобы сформировать собственное мнение ... пора проявить уважение.

  8. Я согласен и не согласен. Systemd WAS для тех, кто легко усваивает и нуждается в пользователях. теперь это ОСНОВНАЯ система инициализации для новых дистрибутивов. Все основные базовые дистрибутивы переключились (Debian (Ubuntu), RHL (Fedora), SUSE). Через несколько лет systemd будет править сценой Linux (путем захвата основных дистрибутивов), и не обновлять свою систему только для того, чтобы оставаться на sysvinit, звучит глупо.

    Я согласен, надеюсь, что systemd докажет свою ценность, но я лично считаю маловероятным, что он будет оставаться так долго, да и в этом не было бы необходимости. Насколько я понимаю, что происходит, - это то, что systemd некоторым открыл глаза. люди начинают видеть, что есть жизнь за пределами sysvinit. Systemd - это начало. Теперь появится новый init (вероятно, более серьезные попытки, чем все предыдущие). И новые инициалы могут учиться с помощью systemd, поскольку он устранил некоторые проблемы, обнаруженные в sysvinit. они могут не следовать его дизайну, но они должны работать лучше, чем systemd, чтобы иметь возможность набирать обороты. Мы, пользователи, можем только выиграть.

    Лично я хотел бы видеть систему инициализации, разработанную сообществом, и возможность выбора простым способом (например, во время установки (время), вместо того, чтобы говорить, что "если вам нужен этот дистрибутив, вы будете использовать этот init", как мы видим в основных дистрибутивах (не говоря уже о более гибких). Это далеко, но надежда еще есть. :)

  9. Я заметил, что Debian 7 с systemd загружается медленнее, чем с SysV. Кроме того, иногда возникают странные замедления и "сбои", которых не бывает, если systemd не запущен как pid 1.

    Меня не волнует systemd. Я также считаю, что ведение двоичного журнала - это колоссально глупая идея, а наличие программного обеспечения более высокого уровня (например, Gnome), зависящего от конкретной системы инициализации, такой как systemd, просто смешно. Тесно связанное программное обеспечение - это плохой дизайн, и точка.


    Возможно, я не мог сказать. Debian 8 вышел, если вы заметили. В течение некоторого времени, и это первый Debian, "официально" построенный на systemd, поэтому, если вы хотите стабильную работу с systemd, вам следует rty Jessie. Поскольку я обновил свою рабочую машину, машина загружается примерно в 3 раза быстрее, что приятно. И все же systemd не о скорости ... (Это обсуждалось здесь так много раз, что я очень неохотно повторяю это. Я скорее заполню пространство бессмысленной строкой символов, которую вы читаете даже сейчас.) :)

    Я прекрасно понимаю. что вы лично не заботитесь о sysrtemd. Я бы не стал, если бы не перешел на Debian (раньше использовал gentoo, а это значит, что меня тоже не интересовал sysv). Как я узнал из комментария выше, двоичное ведение журнала более универсально, чем кажется, и его не нужно "сохранять двоичным".

    Что касается GNOME: у меня хорошие новости: вам не обязательно его использовать, есть множество других DE, которые не зависят от systemd. Но это выбор GHNOME, а не systemd, поэтому этот аргумент несколько (слишком много) выходит за рамки. Тем не менее я понимаю, что вы имеете в виду, только я не возражаю против использования GNOME фреймворка. Вы ведь знаете, что это фреймворк? С этого момента, говоря, что программное обеспечение более высокого уровня, использующее фреймворки, является колоссально глупой идеей, пахнет непониманием программного обеспечения: Но давайте не будем углубляться в это. Вы сделали там еще более забавное замечание:

    "Тесно связанное программное обеспечение - плохой дизайн, точка". - Я предполагаю, что вы не используете Dektop Environment, Office Suite или что-либо, построенное, например, на GTK + и / или Qt и т. Д. Вы должны использовать индивидуально разработанные приложения, которые не могут взаимодействовать друг с другом из-за глупости тесно связанное программное обеспечение. :) Ваш компьютер должен быть действительно уникальным (но жизнь у вас довольно сложная). Что касается того, какие варианты дизайна плохи, а какие хороши, предыдущий комментатор уже предположил, что это настолько субъективно, что это может измениться, изменив перспективу.

    Но позвольте мне сказать: говорить абсолютно обо всем - это плохой выбор слов. Период. :)

    1. "Сильно связанное программное обеспечение - плохой дизайн"
      Сильно связанное, как это сделано * buntu, где каждое приложение связано с пакетом "ubuntu-minimal". Любая попытка удалить программное обеспечение, такое как "cowsay" или "fortune" или ненужные языковые пакеты, приводит к удалению "ubuntu-minimal" и отключению системы.

      1. То есть (ubuntu-minimal METApackage) вопрос о пакете и не имеет ничего общего с тем, какие фреймворки используются данным программным обеспечением! Это все равно, что сравнивать разработку с маркетингом. Одно может жить без другого, и они могут использоваться вместе плохо спроектированным, связывающим образом (как здесь).

        GNOME делает то же самое (плохой выбор упаковки), но это не означает, что пакеты объединяются одинаково, как, например, GNOME зависит от systemd! Эти два слова означают очень-очень разные вещи.

        По-прежнему собственные компоненты gnome, которые работают вместе для создания согласованной среды рабочего стола (не как мета-пакет libreoffice, а как основной компонент gnome), тесно связаны, что абсолютно логично. В этом же случае вы видите тесную связь между хорошим дизайном (ядро gnome) и плохим дизайном (libreoffice) в ОДНОМ мета-пакете.

        Ergo: Тесно связанное программное обеспечение - неплохой дизайн. Плохой дизайн - это плохой дизайн! Я по-прежнему говорю, что говорить об абсолюте - это плохой дизайн (слов).

      2. И, если вы не знали, удаление фортуны заставит вас взорваться. Считается, что это самая опасная ошибка, которую может совершить одинокий мужчина! Неудивительно, что он был упакован в ubuntu-minimal…

    2. На самом деле я давний разработчик и не страдаю от "непонимания программного обеспечения".

      Я ничего не сказал о том, чтобы не использовать фреймворки, моя претензия к Gnome (которым я больше не пользуюсь) заключается в зависимости от КОНКРЕТНЫХ программ.

      Плотно связанный дизайн - это плохой дизайн. Это никоим образом не подлежит обсуждению. Здесь: https://en.wikipedia.org/wiki/Coupling_%28computer_programming%29

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

    3. Про фреймворки я ничего не сказал. Мое недовольство Gnome (которым я больше не пользуюсь, поскольку GNOME3 - отстой) зависит от КОНКРЕТНОГО программного обеспечения.

      Я разработчик, поэтому я не страдаю от "непонимания программного обеспечения", как вы выразились. Сильно связанное программное обеспечение - это плохой дизайн. Этот момент не подлежит обсуждению. Любой достойный разработчик знает это:
      en.wikipedia.org/wiki/Coupling_%28computer_programming%29

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

      Основные проблемы с systemd заключаются в том, что он предоставляет большой и изменчивый интерфейс для компонентов более высокого уровня, одновременно диктуя политику в отношении того, как системы должны работать. Проблема с политикой - это тоже проблема GNOME: программы никогда не должны диктовать политику. Он должен оставаться гибким, чтобы иметь возможность обрабатывать задания, которые автор даже не считал допустимыми. Из прошлых разногласий между разработчиками systemd и разработчиками ядра ясно, что разработчики systemd считают, что они должны иметь возможность делать это, потому что они "знают", что правильно. Они ошибаются.

      1. Да ладно, GNOME 3 отстой или нет, но работает. Я лично считаю его функциональным, а также первым GNME, о котором я когда-либо думал даже использовать. Я всегда ненавидел кишку GNOME, она была уродливой и нефункциональной, не позволяла вам что-то делать, казалось, что настройка была чрезвычайно сложной и т. Д. Кое-что из этого не изменилось, но, по крайней мере, теперь она выполняет свою работу. (И мне нравится его идея взаимодействия с рабочим столом, более продуктивная, чем старые).

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

        Как заметил другой комментатор: только 3 из двоичных файлов systemd являются обязательными, все остальные - необязательными. Тогда как это тесно связано? Вы можете выбрать использование всех или ни одного. Фактически, большинство инструментов systemd можно использовать БЕЗ того, что systemd имеет значение PID1: Вау, такая тесная связь….

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

        О покупке кода более высокого уровня в способе работы systemd: теперь это будет выбор разработчика кода более высокого уровня, systemd предоставляет только способ сделать это. Это также позволяет этого не делать. В любом случае, это не "вина" systemd, и не только "плохой дизайн" systemd (хотя мы уже развенчали миф о вашей тесной связи, ведь все эти элементы являются необязательными, не так ли?) Дело в том, что они могут ПОЯВЛЯТЬСЯ плотно спарены или даже так себя ведут, но это не значит, что они созданы по замыслу. Раньше я наблюдал за командами разработчиков, я прекрасно знаю, что отдельные разработчики плохо разбираются в дизайне более высокого уровня (и часто всего, что выходит за рамки их кодовой базы). В этом случае быть разработчиком не обязательно является преимуществом для вашего понимания.

        Что касается того, что вы правы: насчет диктата политики и т. Д., Я в целом согласен. Я также согласен со связью в целом (когда вы, наконец, объясните, что вы имеете в виду, и не оставляете нам гадать, что или насколько вы действительно понимаете под этим, и в этом случае я склонен предположить, что вы тоже немного конкретнее).

        Я не согласен с тем, что systemd диктует политику. Он предлагает выбор. С gnome это может быть правдой, но опять же, это не вина systemd. вы смешиваете вещи.

        Ну наконец то:

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

        Позвольте мне перевернуть это: утверждение, что systemd тесно связана, просто демонстрирует незнание того, что такое systemd. (См. Выше почему): D


    "Я также считаю, что ведение двоичного журнала - это колоссально глупая идея", - как насчет того, чтобы объяснить, почему? попробуйте какое-то время использовать journalctl и посмотрите, не считаете ли вы его по-прежнему глупым. Посмотрите, сколько времени у вас уйдет на написание сценария (ов), который извлекает все записи журнала за определенный период времени и объединяет их, чтобы создать журнал журнала, который стоит прочитать - вот способ journalctl "journalctl –since" 2015-01 -10 "–до" 2015-01-11 03:00 ″ - если вы хотите узнать больше: - https://www.digitalocean.com/community/tutorials/how-to-use-journalctl-to-view- and-manage-systemd-logs
    "и иметь программное обеспечение более высокого уровня (например, Gnome), зависящее от конкретной системы инициализации, такой как systemd, просто смешно". это не обязательно, LPoettering написал библиотеку, чтобы Gnome не зависел от systemd, но GNOME решил не использовать ее. Может быть, они знают что-то большее, чем вы.
    "Тесно связанное программное обеспечение - плохой дизайн, точка". его модульность, единственными зависимыми модулями являются systemd, udev и journald, все остальное необязательно.

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

      Я могу написать сценарий для разбора файлов журнала без проблем. Зачем мне для этого нужен специальный инструмент?

      1. Мне еще предстоит увидеть какое-либо неподкупное ведение журнала, включая ваш собственный сценарий. Недоступность может быть правильной, но преимущества специализированных инструментов часто перевешивают их недостатки. Я очень хочу увидеть сценарий, который вы пишете, который может не хуже journalctl. Сегодня утром он приготовил мне капучино, я не шучу.

        И альт, вот еще один комментарий (над вашим), указывающий на то, насколько вы ошибаетесь в отношении сцепления.

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

          Последний раз для тех, кто до сих пор не понимает: связь не имеет ничего общего с количеством имеющихся у вас двоичных файлов. Аргумент о том, что "его модульные, единственные зависимые модули - это systemd, udev и journald, все остальное необязательно", вводит в заблуждение. Вот упражнение для упрямых: скомпилируйте минимальную (и функциональную) систему под именем PID1. Сколько строк кода задействовано и сколько библиотек? Какой тип интерфейса он предоставляет и насколько он гибкий? Меняется ли этот интерфейс с течением времени, так что писать собственные внешние инструменты против него сложно? Сделайте это и сделайте собственные выводы. Пока вы этого не сделаете, ваши предположения о его конструкции - это всего лишь предположения. Я уже сделал это и занялся другими делами, вместо того, чтобы тратить время на мусор systemd.

Комментарии закрыты.