С каждым днем наши компьютеры становятся все более важной частью нашей жизни; любая их проблема влияет на наше настроение, на наше чувство юмора, ха-ха. Конечно, пользователи Windows более склонны к паническим атакам: вирусы ( да здравствует Linux! ), дефрагментация жесткого диска, поиск и установка Clean Master для ПК ( хотя и здесь, в Linux, нам тоже нужно чистить систему; BleachBit — одна из предпочтительных альтернатив ). В последнее время некоторые пользователи Linux испытывают определенную головную боль под названием systemd.
В общем, перейдём к сути. Я прочитал интересную статью о systemd , которая, похоже, сейчас очень популярна.
Systemd , который некоторые считают ( и я воспользуюсь словами друга ) «единым кольцом, чтобы править всеми »... для других же это просто безразлично; пока компьютер работает исправно, им все равно, делает ли init то или это, или используется ли systemd. Что касается меня, ну... скажем так, я предпочитаю init; я считаю его проще.
Оставляю статью здесь:
Прежде чем начать, я должен сказать, что мне очень не нравится решение внести изменения в Debian, но я не собираюсь отказываться от своей любимой системы. Я просто стараюсь убедиться, что, если мы собираемся обсуждать какую-либо тему, мы делаем это максимально подготовленными, хотя сам я не считаю себя сторонником systemd. Чтобы развеять мифы о systemd, я воспользуюсь сайтом, где разработчики делятся своими взглядами , который попал мне на глаза от коллеги, который, кажется, поддерживает systemd, хотя и не является пользователем Debian. С учетом сказанного, я думаю, могу приступить к попытке развеять мифы о systemd.
systemd основан на двоичном коде
Возможно, это один из аспектов, который больше всего нас шокирует: если все основано на двоичном коде, как мы отслеживаем то, что обычно делаем, с помощью журналов? Я понятия не имею, как родился этот миф, но это не совсем правда.
systemd настраивается почти исключительно с помощью текстовых файлов. Некоторые настройки, которые также можно изменить с помощью командной строки ядра и переменных среды. В вашей конфигурации нет ничего двоичного (даже XML). Просто простой, понятный и легко читаемый текстовый файл.
Эта штука монолитная и контролирует все
Прежде чем добраться до вышеупомянутого веб-сайта, признаюсь, я сам так думал, но после прочтения того, что говорят его разработчики, мое мнение кое-что изменилось ...
Если вы соберете systemd со всеми включенными параметрами конфигурации, вы получите 69 отдельных исполняемых файлов . Эти файлы выполняют разные задачи и тщательно разделены по ряду причин. Например, systemd был разработан с учетом безопасности; поэтому большинство демонов работают с минимальными привилегиями (используя, например, возможности ядра) и отвечают только за очень специфические задачи, минимизируя свою уязвимость и влияние на безопасность. Кроме того, systemd распараллеливает загрузку больше, чем любое предыдущее решение. Эта «параллелизация» создается за счет параллельного запуска нескольких процессов . Таким образом, очевидно, что systemd очень хорошо разделен на множество исполняемых файлов и, следовательно, процессов. Фактически, многие из этих исполняемых файлов настолько хорошо разделены, что они очень полезны вне systemd.
Пакет, содержащий 69 отдельных бинарных файлов, вряд ли можно назвать монолитным. Однако, в отличие от предыдущих решений, мы поставляем больше компонентов в одном архиве tarball и объединяем их в единую цепочку репозитория с унифицированным циклом выпуска.
Это не похоже на Unix
В этом, безусловно, есть доля правды. Исходные файлы systemd не содержат ни одной строки кода из исходных строк UNIX. Однако источником вдохновения является UNIX, и поэтому в systemd много UNIX. Примером может служить идея UNIX «все является файлом», которая отражена в том, что в systemd все службы отображаются во время выполнения в файловой системе ядра, cgroupfs. Итак, одной из оригинальных особенностей UNIX была поддержка нескольких рабочих мест, основанная на встроенной поддержке терминала. С systemd мы снова обеспечили многопользовательскую поддержку изначально, но на этот раз с полной поддержкой современного оборудования, включая графику, мышь, аудио, веб-камеры и многое другое. Фактически, конструкция systemd как набора интегрированных инструментов, каждый из которых имеет свои индивидуальные цели, но при совместном использовании представляет собой нечто большее, чем просто сумму частей, что более или менее составляет основу философии UNIX. Таким образом, способ обработки нашего проекта (то есть хранение большей части ядра операционной системы в одном репозитории git) намного ближе к модели BSD (которая является настоящим UNIX, а не Linux) для выполнения задач (где большая часть основная операционная система хранится в едином репозитории CVS / SVN), чего никогда не было в Linux.
В конце концов, вопрос о том, является ли что-то UNIX или нет, имеет очень мало значения. Технически превосходный, он вряд ли уникален для UNIX. Для нас UNIX оказывает большое влияние (фактически, самое большое), но у нас есть и другие факторы. Следовательно, в некоторых областях systemd будет очень UNIX, а в других - немного меньше.
Это очень сложно ...
В этом, безусловно, есть доля правды. Современные компьютеры - сложные звери, и операционная система, которая на них работает, очевидно, тоже будет, поэтому они должны быть сложными. Однако systemd определенно не сложнее, чем предыдущие реализации тех же компонентов. Это проще и имеет меньшую избыточность. С другой стороны, для создания простой операционной системы на основе systemd потребуется гораздо меньше пакетов, чем в традиционном Linux. Меньшее количество пакетов упрощает сборку вашей системы, избавляется от взаимозависимостей и большей части различного поведения всех задействованных компонентов.
Это не позволит мне использовать сценарии оболочки
Это совершенно неверно. Мы просто не используем их в процессе загрузки, потому что считаем, что они не лучший инструмент для этой конкретной цели, но это не значит, что systemd был с ними несовместим. Вы можете легко запускать скрипты оболочки как службы или демоны systemd; вы можете запускать скрипты, написанные на любом языке, как службы systemd, поскольку systemd совершенно безразлично, что находится внутри вашего исполняемого файла. Более того, мы широко используем скрипты оболочки для собственных целей: для установки, сборки и тестирования systemd. И вы можете вставлять скрипты в процесс ранней загрузки, использовать их для обычных служб, запускать их при окончательном завершении работы — практически нет никаких ограничений.
На данном этапе, я полагаю, некоторые из основных убеждений, возможно, прояснились. Хотя я не считаю себя сторонником перемен и имею свои сомнения по поводу идеи « одного демона, правящего всеми », я думаю, что в конечном итоге никто не осмелится сказать, что это вообще не работает. Я даже знаю некоторых пользователей, которые отмечают, что с systemd «компьютер работает быстрее», но это уже другая тема для обсуждения. На данный момент я могу лишь предложить вам обсудить здесь ваши точки зрения на систему инициализации, которую приняли многие дистрибутивы, хотя самые сильные реакции сейчас наблюдаются в сообществе Debian, которое даже породило новый форк из-за всего этого. Нравится вам это или нет — личное дело; со своей стороны, я просто хочу внести свой вклад в демистику systemd, который в конечном итоге будет присутствовать в Jessie, следующей стабильной версии Debian.
Я видел статью на GUTL (которая, в свою очередь, была взята с сайта DesdeAbreus ).
Systemd ток?
Я из тех, кто не читает много новостей, когда что-то вызывает столько споров, предпочитаю останавливаться на технических подробностях. Дело в том.... Иногда мне кажется, что некоторые темы перестают быть чисто техническими дискуссиями или дебатами и становятся похожими на сплетни шоу-бизнеса
Сначала открытый гневный пост пользователя о systemd под названием «systemd против интеллекта» , затем Линус Торвальдс, заявивший, что systemd не так уж плох, как о нём говорят ( и в этом есть доля правды ), форк под названием uselessd ... комментариев нет... и, если коротко, наконец, Devuan.
Я не буду говорить, так ли это плохо, как говорят, менее плохо или хуже. Система меня вполне устраивает, однако лично я бы предпочёл init, так как мне нравится его способ организации различных вещей (например, логов). Но если systemd будет называться «скаковой лошадью» и ему придётся заменить init ( станет ли он нашей рабочей лошадью, делающей всё, но медленно? ), то... если изменения не слишком радикальные, пользователи смогут адаптироваться без особых проблем, и система будет работать лучше (да, лучше, возможно, мне этого будет недостаточно!), то приветствуйте это! 😉