LINUX.ORG.RU

Февральские тезисы о планах развития systemd

 ,


2

4

На прошедшей конференции FOSDEM Леннарт Поттеринг огласил некоторые перспективы развития systemd:

  • Интеграция в systemd загрузчика gummiboot, поддерживающего технологию UEFI Secure Boot.
  • machined — менеджер регистрации виртуальных машин, спроектированный под впечатлением от Solaris Zones.
  • В подсистеме nspawn и смежных с ней ожидается больше возможностей для управления контейнерами, например, journald сможет собирать логи не только с хоста, но и с контейнеров.
  • Уже в следующей версии ожидается улучшенная поддержка Btrfs (подразделы и снапшоты Btrfs планируется использовать для изоляции отдельных приложений).
  • Поддержка HiDPI и Юникода в consoled.
  • Сервис-ориентированный фаерволл: можно будет задавать правила в привязке не к номерам портов, а к именам процессов.
  • Отпадёт нужда указывать путь к юниту для systemctl-cat; systemctl-edit позволит редактировать юниты и после сохранения изменений автоматически перезапускать соответствующие сервисы.
  • nss-getmyhostname — функция для получения имени хоста на stateless-системах.
  • Утилита ping gateway позволит автоматически определить все доступные сетевые интерфейсы и проверить их статус командой ping.
  • Развитие networkd и собственной библиотеки для работы с DHCP (совместимой с dhcpv4 и dhcpv6).
  • Комбинирование nspawn и networkd позволит легко конфигурировать сеть для контейнеров.
  • Создание средств для широкого системного аудита, интегрированных в journald. Например, станет возможным логировать все системные вызовы к файлу /etc/passwd.
  • Движение в сторону stateless-систем, у которых только /usr доступен на чтение и запись, а /etc и /var будут автоматически заполняться systemd.
  • journald-remoting — удалённая работа логгера через HTTP. Поддержка в journald моделей pull и push: при pull выполняется запрос HTTP GET для получения потока JSON, а при push данные передаются в другой экземпляр journald при помощи HTTP POST.
  • Возможность определения для сервисов минимальных пространств имён и sandbox-изоляции: доступ к некоторым разделам и каталогам только на чтение, сокрытие устройств в /dev, приватный /tmp для каждого сервиса, и др.
  • timesyncd в качестве замены ntpd.
  • Автоматическое определение разделов GPT, не нуждающееся в указании их в fstab.
  • Поддержка перезапуска демонов без потери их состояния (посредством сохранения оного на диск).

>>> Подробности



Проверено: Shaman007 ()
Последнее исправление: ymn (всего исправлений: 1)
Ответ на: комментарий от Shadow

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

Его при сборке отключить можно, если что.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

в сислог юниты без journald никак не направить?

Я просто пока не ставил новых линуксов с systemd. Год назад он был ещё странен, сейчас вроде годен...

Shadow ★★★★★
()
Ответ на: комментарий от intelfx

Ну, console-kit как-то без dbus обходится. Понятно, что logind даёт существенно более широкий функционал не только для консоли, но консоль-то...

Shadow ★★★★★
()
Ответ на: комментарий от intelfx

мультисит

именно.
Вся эта бодяга с системд возникла, как результат бурлений вокруг одной десктопоспецифичной задачи - мультисит.
Мультисит на серверах?
Мультисит на всех десктопах?
Мультисит на десктопах, безусловно, нужен. Был. Когда-то. Когда комп был единственным и любимым, и юзался всеми домашними по очереди или даже одновременно.
Мультисит сейчас? Ну, возможно, не возражаю.
Ценой перекроя и передела всего и вся? Сомнительная авантюра.
Абсолютно все серверные и десктопные синглсит задачи решаются просто и элегантно безо всей этой навороченной ботвы.
Более того, мультисит решения существовали и до эпохи системд.

И общий вопрос - профит где?
Все заявленные цели «тихо и незаметно» (с) носком ноги под ковер, смущаясь.
Грузится, но не так уж и быстро. Но это не важно!
Журналд журналирует, но не так чтобы. Но это неважно!
И вообще чо пристали - хотим и пишем. :)

Короче.
Как сказала одна известная дама:
- Пионэры! Идите в опу.
:)

anonymous
()
Ответ на: комментарий от Shadow

Если программа пишет в сислог сама — она может продолжать это делать совершенно независимо от systemd.

Если же она пишет в stdout/stderr — то тут только через прослойку в виде journald (при этом бинарный логфайл вести необязательно).

intelfx ★★★★★
()
Ответ на: мультисит от anonymous

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

С дуба рухнул?

Все заявленные цели <...> носком ноги под ковер

Точно рухнул.

intelfx ★★★★★
()
Ответ на: комментарий от Shadow

Ну, console-kit как-то без dbus обходится

Ась? http://www.freedesktop.org/wiki/Software/ConsoleKit/

Dependencies
        * Linux / Solaris 11+ / FreeBSD 
        * dbus 0.61 (or later) 
        * glib + gobject 2.6.0 (or later) 
        * Xlib 

Понятно, что logind даёт существенно более широкий функционал не только для консоли, но консоль-то...

Для недесктопных и/или headless-систем logind вообще не нужен. Или о чём ты?

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)

Не февральские, но тоже тезисы...

1.В группе ты найдешь именно то, что до сих пор напрасно искал. Она знает абсолютно точно, чего тебе не хватает.
2.Уже первая встреча открывает для тебя полностью новый взгляд на вещи.
3.Мировоззрение группы ошеломляюще просто и объясняет любую проблему.
4.Трудно составить точную характеристику группы. Ты не должен размышлять или проверять. Твои новые друзья говорят: «Это невозможно объяснить, ты должен пережить это — пойдем сейчас с нами в наш Центр».
5.У группы есть учитель, медиум, вождь или гуру. Только он знает всю истину.
6.Учение группы считается единственно настоящим, вечно истинным знанием. Традиционная наука, рациональное мышление, разум отвергаются, поскольку они негативные, сатанинские, непросвещенные.
7.Критика со стороны не принадлежащих к группе считается доказательством ее правоты.
8.Мир катится к катастрофе, и только группа знает, как можно спасти его.
9.Твоя группа — это элита. Остальное человечество тяжело больно и глубоко потеряно: ведь оно не сотрудничает с группой или не позволяет ей спасать себя.
10.Ты должен немедленно стать членом группы.
11.Группа отграничивает себя от остального мира, например одеждой, пищей, особым языком, четкой регламентацией межличностных отношений.
12.Группа желает, чтобы ты разорвал свои «старые» отношения, так как они препятствуют твоему развитию.
13.Твои сексуальные отношения регламентируются извне. Например, руководство подбирает партнеров, предписывает групповой секс или, наоборот, полное воздержание.
14.Группа наполняет все твое время заданиями: продажей книг или газет, вербовкой новых членов, посещением курсов, медитациями...
15.Очень сложно остаться одному, кто-то из группы всегда рядом с тобой.
16.Если ты начинаешь сомневаться, если обещанный успех не приходит, то виноват всегда окажешься сам, поскольку ты якобы недостаточно много работаешь над собой или слишком слабо веришь.
17.Группа требует абсолютного и беспрекословного соблюдения своих правил и дисциплины, поскольку это единственный путь к спасению.

anonymous
()
Ответ на: комментарий от like-all

Интеграция с networkd + динамический интервал + хранение состояния между синхронизациями. Одним кроном не обойдёшься (либо придётся велосипедить).

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

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

anonymous
()
Ответ на: комментарий от anonymous

Void Linux

Захотел я потрогать этот Void Linux. Захожу в их wiki на гитхабе, смотрю, написано: установка на LVM. Ну ок, значит установку на LVM поддерживает без танцев с бубном. Скачиваю, режу на болванку, гружусь.

# vgdisplay
-sh: 1: vgdisplay: not found
# lvm
-sh: 1: lvm: not found

Сложно быть айтишником. Постоянно приходится иметь дело с кретинами.

Deleted
()
Ответ на: комментарий от intelfx

да забей на них, они свое мнение не изменят...

reprimand ★★★★★
()
Ответ на: комментарий от Shadow

С другой стороны, скоро использование функционала логина-юзеров без systemd станет эпическим pain in ass... И даже тем, кто использует в качестве инита /etc/init.sh, станет намного проще плюнуть на всё и использовать systemd, даже если он им на самом деле «ненужно». А втреде эпичный срач, дааа...

То есть LP лично удалит все альтернативные реализации этого функционала? LP не виноват, что консолькит оказался заброшен.

kir2yar
()
Ответ на: комментарий от intelfx

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

1) не совсем понятно, какую одну задачу решает systemd;

2) если задача настолько сложна, почему нельзя решить её при помощи скриптов, разбивая на мелкие элементарные (и универсальные) подзадачи;

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

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

напоследок цитата одного из контрибьютеров классического Unix:

«This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface. ...»

cawa
()
Ответ на: комментарий от reprimand

кстати, что такое мультисит?

Терминальный сервер под виндой - один из вариантов мультисита.
Вообще задача достаточно интересная. Нужно отделить активность одного пользователя от активности другого.
От сюда следует: разные устройства ввода-вывода звука, разные принтеры, ограничения по ресурсам на пользователя/сессию, а не на процессы. Раздача приоритетов по пользователям/сессиям, а не по процессам. Да много всего.
Вот эта фигня и реализуется в logind.

kir2yar
()
Ответ на: комментарий от Deleted

Сложно быть айтишником. Постоянно приходится иметь дело с кретинами.

Эти слова нужно в рамку и на стену.

anonymous
()
Ответ на: комментарий от cawa

1) не совсем понятно, какую одну задачу решает systemd;

Какой именно бинарник из пакета systemd? Их там достаточно много и каждый решает свою мелкую подзадачу.

2) если задача настолько сложна, почему нельзя решить её при помощи скриптов, разбивая на мелкие элементарные (и универсальные) подзадачи;

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

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

Добавление метаинформации, которая в текстовые логи не помещается. FSS (http://lwn.net/Articles/512895/)

kir2yar
()
Ответ на: комментарий от kir2yar

Оверхед достаточно сильный. Достаточно сравнить скорость запуска системы на системд с системой, где все на инитскриптах.

Уже давно сравнили. systemd грузился примерно столько же, сколько инитскрипты арча. Но это было давно, много релизов назад. Еще в ту пору, когда его называли системой инициализации. Сейчас он грузится раза в 2 медленнее.

«Sh форкается на каждый чих и вызывает кучу утилит, посмотрите, какие огромные PIDы у пользовательской сессии, ко-ко-ко!»

$ ps 1
  PID TTY      STAT   TIME COMMAND
    1 ?        Ss     0:01 /usr/lib/systemd/systemd
$ pgrep lightdm 
1163
1431
$ pgrep Xorg
1348

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

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

Можешь перечислить, какие файлы исполняются при запуске твоего компьютера?

Зато под systemd это сделать намного проще:

$ find /usr/lib/systemd/ -type f -executable | wc -l
57
Deleted
()
Ответ на: комментарий от cawa

«Кроме того принципы эти были проверенны временем и признаны годным»

Обычные утилиты линукса делают одну задачу, и делают ее плохо.

anonymous
()

А что если Поттеринг - секретный агент майкрасофта, задачей которого является внесение разлада в ряды линуксоидов. Вот, не плохо справляется.

ilnnli
()
Ответ на: комментарий от Deleted

Зато под systemd это сделать намного проще:
find /usr/lib/systemd/ -type f -executable | wc -l
57

Огак. А теперь посчитай количество запускаемых шелл-скриптов.
Хинт:
$ ls /etc/init.d/ | wc -l
103
$ ls /etc/default/ | wc -l # файлики от туда соурсятся в другие скрипты, те, если туда добавить rm -rf - оно выполнится. По сути - тоже исполняемые.
54
И это только две, самые явные, директории. Есть еще куча мест код от куда исполняется при запуске компа. Причем, далеко не очевидных. Системд, со всеми его юнитами, выглядит гораздо стройнее этого склада костылей.

kir2yar
()
Ответ на: комментарий от ilnnli

«А что если Поттеринг - секретный агент майкрасофта, задачей которого является внесение разлада в ряды линуксоидов. Вот, не плохо справляется.»

Ну конечно, МС боится 1%, поэтому наняла Поттеринга для внесения разлада в стройные ряды линуксоидов. Вместо того, чтобы просто засудить и запретить линукс за нарушение патентов.

anonymous
()
Ответ на: комментарий от Deleted

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

Огак. Запусти-ка симуляцию процесса загрузки sysvinit системы. Что бы было видно, какой файл исполняется и почему.

kir2yar
()
Ответ на: комментарий от anonymous

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

cawa
()
Ответ на: комментарий от kir2yar

А нафига вебсерверу и cgi-скриптам видеть тот-же /dev/sda?

Что ужасного в том, что он его видит? Всё равно читать и писать в него не может

Harald ★★★★★
()
Ответ на: комментарий от cawa

«видимо поэтому вменяемые программисты под виндой зачастую подтягивают UnixUtils, дабы грепать и диффать логи своих прог»

«вменяемые» «подтягивают UnixUtils»

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

anonymous
()
Ответ на: комментарий от kir2yar

А теперь посчитай количество запускаемых юнит-файлов. Хинт:

$ find /usr/lib/systemd/system/ /etc/systemd/system/ -type f | wc -l
314
Если туда добавить ExecStartPre=rm -rf - оно выполнится. По сути - тоже исполняемые. (c)

А теперь присуммируй туда все шелл-скрипты, которые ты нашел, потому что systemd тоже может запускать sysv-style шелл-скрипты.

Deleted
()

Комбайнёр гарри поттер опять лютует :) Я бы даже сказал, велокомбайнёр. Так точнее :)

trueshell ★★★★★
()
Последнее исправление: trueshell (всего исправлений: 1)
Ответ на: комментарий от reprimand

Мультисит — это когда одна машина имеет несколько «терминалов».

По сравнению с историческим «мультиситом» (реальные такие терминалы, которые /dev/ttyчтонибудь), здесь задача усложняется за счёт того, что терминалом мы называем совокупность произвольных устройств: одно устройство вывода графики и сколько угодно других. В частности, это может быть несколько устройств ввода... или USB-концентратор... или ещё что-нибудь.

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

Помимо этого, logind управляет электропитанием системы (suspend/hibernate/poweroff/reboot). То же самое можно делать и без logind (соответствующие методы есть и в API самого systemd), но:

  • logind учитывает привилегии конкретных пользователей через policykit (а-ля «последний пользователь имеет право потушить систему», ну или как настроишь)
  • logind имеет концепцию «ингибиторов» — любое приложение из активной сессии имеет право попросить logind немного подождать перед выключением системы
  • logind слушает события устройств ввода (не всех, а специально помеченных) и обрабатывает специальные события типа закрытия крышки ноутбука или нажатия клавиш управления питанием
intelfx ★★★★★
()
Ответ на: комментарий от Harald

Что ужасного в том, что он его видит? Всё равно читать и писать в него не может

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

kir2yar
()

чё там systemd - всё это мышиная возня. Мелко плавает.

Нужны проекты уровня: officed, lamerd, lord, pupkind, vasyad, wind/wined, gnomed, kded (уже есть?), 1cd, joomlad, activexd, flashd, nvidiad, recycled, sambad, binaryd, spyd, ied... Далее по списку, можно продолжить...

anonymous
()
Ответ на: комментарий от kir2yar

Огак. Запусти-ка симуляцию процесса загрузки sysvinit системы. Что бы было видно, какой файл исполняется и почему.

Админы локалхоста подтянулись? Когда у тебя вдруг, упсь, не грузится боевой сервер, тебе надо быстро понять логику кода и найти проблему, а не заниматься «симуляцией процесса загрузки».

И как же мне в systemd увидеть «какой файл исполняется и почему»? Проходить PID 1 в отладчике?

Deleted
()
Ответ на: комментарий от Deleted

А теперь присуммируй туда все шелл-скрипты, которые ты нашел, потому что systemd тоже может запускать sysv-style шелл-скрипты.

Именно по этому я и хочу закопать шеллскрипты.

ExecStartPre=rm -rf - детектится обычным systemd --test --system --unit=multi-user.target
Есть у sysvinit аналог?

kir2yar
()
Ответ на: комментарий от Deleted

Админы локалхоста подтянулись? Когда у тебя вдруг, упсь, не грузится боевой сервер, тебе надо быстро понять логику кода и найти проблему, а не заниматься «симуляцией процесса загрузки».

Когда у меня не грузится боевой сервер, то не важно что у него за система инициализации. Один фиг - железо сдохло.

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

kir2yar
()
Ответ на: комментарий от kir2yar

Не тяните слона за хобот.

ls /etc/init.d/ | wc -l


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

ls /etc/default/ | wc -l

покажет общее количество файлов с настройками программ, которые прописаны в /etc/init.d/

Вам не кажется что так честнее ?

grep initdefault /etc/inittab
id:2:initdefault:

ls -lh /etc/rc2.d/ |wc -l
37

smith
()
Ответ на: комментарий от kir2yar

В мире недырявых cgi и отсуствия локальных эксплойтах, дающих рут.

Ну и? Как видимость /dev/sda поможет получить рут? А если рут уже получен другим способом, то невидимость тут не спасёт, от рута программа вполне может запилить себе нужный device node

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

Эта задача и так уже решается существующими методами

Harald ★★★★★
()
Ответ на: комментарий от kir2yar

Не представляю, как у вас ухитряется отказать чисто софтово боевой сервак.

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

А ваще классно получилось:

— Шеллскрипты не славятся своей читабельностью и удобством отладки <...> Не представляю, как у вас ухитряется отказать чисто софтово боевой сервак.

Сам с собой поговорил, сам себя опроверг.

Deleted
()
Ответ на: комментарий от kir2yar

Именно по этому я и хочу закопать шеллскрипты.

Заменить одно говно на другое — достойная цель. Стоит потратить жизнь на неё.

Есть у sysvinit аналог?

grep

Deleted
()
Ответ на: комментарий от smith

ls -lh /etc/rc2.d/ |wc -l

Оке, а какие еще скрипты исполняются и где лежат? Только честно, с учетом того, что тянется через source.

kir2yar
()
Ответ на: комментарий от Deleted

grep

Хорошо. Молодец. А теперь дай мне цепочку, в результате которой исполняется код из /etc/X11/xsession. От запуска инита, до запуска xsession. Все промежуточные скрипты, с учетом соурсящихся.

kir2yar
()
Ответ на: комментарий от anonymous

какие есть методы нейтрализации systemd?

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

Из-за примитивности средств отслеживания\мониторинга\запуска\перезапуска процессов (в частности проблемы получения exit-статуса из $(subshell-ов), да и вообще контроля за ними) - появилось это поделие. Как говорится - «Природа боится пустоты»

На эту роль бы подошёл питон в общем, но... К сожаление на настоящий момент есть только зачатки таких систем: rust, go, erlang, наверное haskell.

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

Сделать паузу процесса или форк это круто вместе с /proc и sysfs, но этого мало. Нужно, чтобы кто-то, что-то думало о сети...

Чуток замешкался и... сразу появляется systemd-подобная субстанция. «Если у Вас нет плана - Вы становитесь частью другого плана...»

anonymous
()
Ответ на: комментарий от Deleted

Хорошо. Молодец. А теперь дай мне цепочку, в результате которой исполняется код из /etc/X11/xsession. От запуска инита, до запуска xsession. Все промежуточные скрипты, с учетом соурсящихся.

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

kir2yar
()
Ответ на: комментарий от kir2yar

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

Если лишние 10 сек. при инициализации системы являются критичными, то это следует рассматривать как специальный случай, и да, здесь systemd имеет право на жизнь по аналогии с busybox.

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

Любую метаинформацию можно представить в текстовом виде. Не вижу принципиального улучшения. Кроме того по вашей ссылке меня настораживают фразы типа:

«The algorithm for FSS is based on „Forward Secure Pseudo Random Generators“ (FSPRG), which comes from some post-doctoral research by Poettering's brother Bertram. The paper on FSPRG has not been published but will be soon, according to (Lennart) Poettering.»

cawa
()
Ответ на: комментарий от anonymous

Чуток замешкался и... сразу появляется systemd-подобная субстанция. «Если у Вас нет плана - Вы становитесь частью другого плана...»

Надо-же. Адекватный аноним.

kir2yar
()
Ответ на: комментарий от cawa

«ок, какую задачу решает пакет systemd?»

Решает задачу создания удобной и монолитной ОС.

anonymous
()
Ответ на: комментарий от kir2yar

Огак. Запусти-ка симуляцию процесса загрузки sysvinit системы. Что бы было видно, какой файл исполняется и почему.

А ты проделай тоже самое с systemd. Особенно чтобы было видно «почему».

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.