[NIXP] Systemd не будет поддерживать дистрибутивы без /etc/os-release

[SLEDopit]

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion

с поправкой на линакс специфику, разумеется.

слэши в другую сторону? (:

[drBatty]

Тогда кстати переезд на другую версию будет проходить без всякого шаманизма с регулярками просто поменяв имя в этом файле.

дык в любом дистре (насколько я знаю) есть файл с версией. зачем файл с ОС? с убунты на слакварь переехать? У вас это получится?

Для systemd и т.п. он абсолютно непригоден в том виде, в котором он есть.

вы с Леннартом ещё не обосновали нужность systemd.

немного быстрее, конечно

почему?

Вот Ленарт и Ко и сделали очевидное для них: раз sysV init скрипты по-сути не для пользователей а для разработчиков дистрибутивов, то почему бы и не заменить их тем что удобно разработчикам.

и что там удобнее?

По крайней мере не нужно будет писать на shell как на С

а зачем вам сейчас так нужно писать?(на shell как на C)?

а при случае еще и какие-нить плюшки замутить

конечно... Причём сделать так, чтоб эти плюшки без systemd не работали. Что за плюшки-то?

[frp]

А сам systemd к чему-нибудь пригоден? Или, точнее, зачем-то нужен. Вот играюсь сейчас с системой, у которой на старте можно выбрать схему загрузки - systemd или sisVinit. И если Вы думаете, что systemd грузит машину быстрее - то Вы глубоко ошибаетесь smile.gif

А я в своем Debian пробовал systemd. На реальном компьютере с реальным набором софта профит не особо значительный (но есть). В виртуалке же этот профит - в много-много раз (с sysvinit грузится оно с минуту, с systemd - секунд 5) (как показали мои поиски, больное место у него - монтирование дисков, на реальной машине он над ними сравнительно долго думает, в виртуалке же, где всего 1 раздел, он монтирует все мгновенно).

[Vladjmir]

Да! Даешь разные конфиги в каждом дистре! Вот это развлекуха! А то понапридумывали стандартизаций всяких. Чем меньше соместимости тем лучше - вот достойный лозунг. Чем же еще заниматься разработчикам дистров, кроме как придумывать свои ни с чем не совместимые конфиги, форматы пакетов и тому подобное? А когда конфиги одинаковые - разве это интересно? Ведь нужно чем-то от других отличаться. Отличаться нескучными обоями - это не серьезно. А вот за место /etc/os-release иметь /etc/bolgenos-release - уже другое дело.

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

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

Хотелось бы услышать аргументы в пользу того, зачем надо унифицировать идентификацию.

[frp]

systemd - это по-сути эволюция давней тенденции "взрослых" дистрибутивов а-ля RedHat/Fedora, SuSE/openSuSE, отчасти Debian и наследников. Тенденция всем известная: init-скрипты не для пользователей. init-скрипты для разработчиков. Там уже давно черт ногу сломит, это сложно читать, не стоит править, для изменения порядка загрузки легче пользоваться дистрибутивными обертками, а если хочется грузить что-то свое "wellcome to /etc/rc.local". А раз так, то какая нафиг разница что там sysVinit, systemd, или мульен других полумеров. Вот Ленарт и Ко и сделали очевидное для них: раз sysV init скрипты по-сути не для пользователей а для разработчиков дистрибутивов, то почему бы и не заменить их тем что удобно разработчикам. По крайней мере не нужно будет писать на shell как на С, а при случае еще и какие-нить плюшки замутить smile.gif

systemd, вообще-то, в отличии от sysvinit, предлагает вполне себе человекочитаемые "скрипты", в отличии от sysv (но сохраняет полную совместимость с LSB-шными скриптами).

[frp]

вы с Леннартом ещё не обосновали нужность systemd.

Пользователи есть, их много, значит, нужно. А теперь вопрос: как мне сделать адекватную параллельную загрузку с традиционным sysvinit?

Vladjmir, все то, что умеет файл Леннарта, умеет и lsb_release, который есть почти везде. Или LSB не нужен?

[drBatty]

Хотелось бы услышать аргументы в пользу того, зачем надо унифицировать идентификацию.

я жду с момента появления этой новости. Пока 2 ответа:
1. можно переходить автоматически с одного дистра на другой. (Наверное где-то есть ПМ, который обновляет любой из Over9000 дистров до убунты 12.04. Единственная проблема - узнать что за дистр)
2. systemd не работает (как я понял - искусственно)

systemd, вообще-то, в отличии от sysvinit, предлагает вполне себе человекочитаемые "скрипты", в отличии от sysv (но сохраняет полную совместимость с LSB-шными скриптами).

да-да. Были BSD-like скрипты /etc/rc.d/rc.*, которые до сих пор в слаке, они отлично читаются, и правятся, но зачем-то сделали sysv. Теперь опять переделываете. Вот только странно, что в сторону ещё большего усложнения.

Пользователи есть, их много, значит, нужно.

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

А теперь вопрос: как мне сделать адекватную параллельную загрузку с традиционным sysvinit?

А зачем? Быстрее? А у нас уже и так есть параллельная загрузка ethX. Ага. Быстрее. Только потом их приходится переименовывать udev'ом, что-бы каждый из них имел верный номер. А не абыкакой. И да, где вам нужна эта ваша параллельная загрузка, если практически всё зависит от всего?
(кстати, не знаю как в sysv, но в Slackware параллельная загрузка была очень давно. Очень просто реализовывается - /etc/rc.d/rc.daemon &, и этот демон грузится в фоне. Вот только даже если демонов много, мало из них кого можно загружать параллельно)

[Vladjmir]

Vladjmir, все то, что умеет файл Леннарта, умеет и lsb_release, который есть почти везде. Или LSB не нужен?

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

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

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

[frp]

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

Как сложнее? "Скрипты" для systemd намного проще и читабельнее, чем традиционные LSB-шные.

Были BSD-like скрипты /etc/rc.d/rc.*, которые до сих пор в слаке, они отлично читаются, и правятся, но зачем-то сделали sysv.

Не зачем-то. sysv гибче, AFAIK.

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

Что-то не видел вживую пользователя висты, который не перелез на семерку и не ненавидел эту висту. Однако, если такие пользователи есть в природе, то это значит, что виста таки кому-то нужна в данный момент.

И да, где вам нужна эта ваша параллельная загрузка, если практически всё зависит от всего?

Примеры?

[frp]

вот моя программа, она будет поддерживать только вот такой файл, всё остальное говно

Было бы правильно без трех последних слов. Он вроде обосновал, чем этот файл лучше в данном конкретном случае, чем lsb_release. Он не предлагает выпилить lsb_release, а просто запилить os-release для нужд его программы os-release. Или ты предлагаешь мне добиваться включения в LSB конфигов для каждой моей поделки?

[sgfault]

Для systemd и т.п. он абсолютно непригоден в том виде, в котором он есть.

вы с Леннартом ещё не обосновали нужность systemd.

Он уже все обосновал 0pointer.de/blog/projects/systemd. Вы не читали? Или читали и не согласны? Тогда напишите с чем.

(кстати, не знаю как в sysv, но в Slackware параллельная загрузка была очень давно. Очень просто реализовывается - /etc/rc.d/rc.daemon &, и этот демон грузится в фоне. Вот только даже если демонов много, мало из них кого можно загружать параллельно)

Про такую "параллельную загрузку" он тоже писал (ссылка выше).

[sash-kan]

Хотелось бы услышать аргументы в пользу того, зачем надо унифицировать идентификацию.

чтобы при загрузке средствами systemd промелькнула строчка "welcome to $yourdistro"·
такой вот аргумент у поттера…

если файлика не будет, systemd напишет "welcome to linux"·
специально чтобы повеселить тех, кто знает, что linux — это не дистрибутив, и даже не операционная система·

[NickLion]

Для справки: в openSuSE 12.1 уже есть этот файлик.

Код: Выделить всё

nicklion@warlock:~> cat /etc/os-release
NAME=openSUSE
VERSION = 12.1 (Asparagus)
VERSION_ID="12.1"
PRETTY_NAME="openSUSE 12.1 (Asparagus) (x86_64)"
ID=opensuse

[Vladjmir]

вот моя программа, она будет поддерживать только вот такой файл, всё остальное говно

Было бы правильно без трех последних слов. Он вроде обосновал, чем этот файл лучше в данном конкретном случае, чем lsb_release. Он не предлагает выпилить lsb_release, а просто запилить os-release для нужд его программы os-release. Или ты предлагаешь мне добиваться включения в LSB конфигов для каждой моей поделки?

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

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

[sash-kan]

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

и вполне обоснованно, кстати·

[Vladjmir]

1. можно переходить автоматически с одного дистра на другой. (Наверное где-то есть ПМ, который обновляет любой из Over9000 дистров до убунты 12.04. Единственная проблема - узнать что за дистр)

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

2. systemd не работает (как я понял - искусственно)

Если systemd каждый раз не будет работать из-за того, что кто-то не удовлетворил прихоти Лёни, далеко пойдём...

чтобы при загрузке средствами systemd промелькнула строчка "welcome to $yourdistro"· такой вот аргумент у поттера…

Да уж, ради 0,5с надписи на экране я должен рассказать Лёне, кто я такой и где у меня деньги лежат

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

[drBatty]

Как сложнее? "Скрипты" для systemd намного проще и читабельнее, чем традиционные LSB-шные.

ну дайте пример тогда...

Не зачем-то. sysv гибче, AFAIK.

чем "гибче"?

Что-то не видел вживую пользователя висты, который не перелез на семерку

у многих на работе не вы выбираете ОС, а ОС выбирает вас.

Примеры?

да те же ethX, затем подключение к Сети, затем сетевые демоны. Как это всё запараллелить? А что у нас остаётся?

[SLEDopit]

Пользователи есть, их много, значит, нужно. А теперь вопрос: как мне сделать адекватную параллельную загрузку с традиционным sysvinit?

Угу, что сунули пользователям убунты, то и жуют. Работает и слава богу.У них же не проводят опрос, хотят ли они переехать на systemd или не хотят. Так что не аргумент (:

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

Не знаю как в других дистриутивах, но недавно обновлял десяток машин с etch до sid. Всё отлично сработало.

[Vladjmir]

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

Не знаю как в других дистриутивах, но недавно обновлял десяток машин с etch до sid. Всё отлично сработало.

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

[drBatty]

Он уже все обосновал 0pointer.de/blog/projects/systemd. Вы не читали? Или читали и не согласны? Тогда напишите с чем.

читал.. Ну основное мое возражение следующее: время загрузки является очень малозначительным параметром.
1. На серверах вообще нет разницы, 5 или 10 минут он загружается.
2. На десктопах можно вообще не перезагружать, и тогда разницы не будет, или см. п3
3. на ноутбуках выключение необходимо, и для этого придумали suspend to disk. Им пользоваться удобнее, чем перезагрузкой.
И дело не только в этом, Поттеринг предлагает слишком радикальные меры, что-бы на несколько секунд ускорить загрузку: во первых, если у нас все основные программы лежат в /usr/, а в /bin/,/sbin/ лежат только то, что необходимо для минимального старта, то мы получаем возможность с лёгкостью починить систему при сбое. Чудес не бывает, ломается всё. А /bin и прочее имеют такой малый размер, что во первых побить их проблематично, во вторых если уж побьёте, легко восстановить. Поттереинг правда пишет, что /usr/ он уже сломал, но мне кажется, что это федоропроблемы, да если и сломал - почини. Это всяко проще, чем придумывать такой 100500-колёсный велосипед. Во вторых, очевидно нельзя делать разделяемый /usr/. Вспоминаем про мобильные устройства, и количество памяти в них. У и не только в памяти дело - нужно ведь обновлять всего один /usr/, остальные обновятся "сами". Вопрос безопасности тоже важен - мобильному девайсу сложнее отслеживать целостность ПО, но ему это и не нужно, если у него нет никакого ПО, кроме небольшого базового комплекта. А всё остальное лежит в /usr/, причём в read-only.

Его фраза So, let's get rid of shell scripts in the boot process! повергла меня в уныние... Ну вот не верю я, что его скрипты, будут выполнятся быстрее bash'овских (кстати, никто не заставляет юзать баш. Правда, как показывает практика, на времени загрузки это не отражается.) Вообще, ваш Поттеринг - демагог. Например он якобы отменяет скрипты, но на самом деле, просто меняет их на свои нестандартные велосипеды. Уверен, это неоправданно.

Вот ещё пример типичной демагогии:

A good metric for measuring shell script infestation of the boot process is the PID number of the first process you can start after the system is fully booted up. Boot up, log in, open a terminal, and type echo $$. Try that on your Linux system, and then compare the result with MacOS! (Hint, it's something like this: Linux PID 1823; MacOS PID 154, measured on test systems we own.)

Ну не нравится тебе 1823? Перепиши скрипты на перле/питоне - не надо будет вызывать 100500 раз sed & gawk. Конечно на вопрос "зачем" ответа всё ещё нет...

Про такую "параллельную загрузку" он тоже писал (ссылка выше).

ну я знаю, что писал - говорю же, демагог.

если файлика не будет, systemd напишет "welcome to linux"·
специально чтобы повеселить тех, кто знает, что linux — это не дистрибутив, и даже не операционная система·

а что промелькнёт, если я в этот файл впишу "Windows NT4 SP6"? (:

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

вот. Потому для обновления этот файл не нужен
Для чего же он нужен?

Если systemd каждый раз не будет работать из-за того, что кто-то не удовлетворил прихоти Лёни, далеко пойдём...

тут всё нормально - одна его прихоть не работает без другой.

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

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

[diesel]

systemd - это по-сути эволюция давней тенденции "взрослых" дистрибутивов а-ля RedHat/Fedora, SuSE/openSuSE, отчасти Debian и наследников. Тенденция всем известная: init-скрипты не для пользователей. init-скрипты для разработчиков. Там уже давно черт ногу сломит, это сложно читать, не стоит править, для изменения порядка загрузки легче пользоваться дистрибутивными обертками, а если хочется грузить что-то свое "wellcome to /etc/rc.local". А раз так, то какая нафиг разница что там sysVinit, systemd, или мульен других полумеров. Вот Ленарт и Ко и сделали очевидное для них: раз sysV init скрипты по-сути не для пользователей а для разработчиков дистрибутивов, то почему бы и не заменить их тем что удобно разработчикам. По крайней мере не нужно будет писать на shell как на С, а при случае еще и какие-нить плюшки замутить smile.gif

systemd, вообще-то, в отличии от sysvinit, предлагает вполне себе человекочитаемые "скрипты", в отличии от sysv (но сохраняет полную совместимость с LSB-шными скриптами).

технически systemd не предлагает скриптов. service-файлы - это конфиги. Ну не скрипт вот это:

Код: Выделить всё

[root@fedora /]# cat  /lib/systemd/system/vsftpd.service
[Unit]
Description=Vsftpd ftp daemon
After=network.target

[Service]
Type=forking
ExecStart=/usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf

[Install]
WantedBy=multi-user.target

[drBatty]

Ну не скрипт вот это:

Код: Выделить всё

[root@fedora /]# cat  /lib/systemd/system/vsftpd.service
[Unit]
Description=Vsftpd ftp daemon
After=network.target

[Service]
Type=forking
ExecStart=/usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf

[Install]
WantedBy=multi-user.target

скрипт. Только с хитрым синтаксисом.

[diesel]

немного быстрее, конечно

почему?

за счет параллельного старта всех сервисов. красивая идея, кстати.

Вот Ленарт и Ко и сделали очевидное для них: раз sysV init скрипты по-сути не для пользователей а для разработчиков дистрибутивов, то почему бы и не заменить их тем что удобно разработчикам.

и что там удобнее?

По крайней мере не нужно будет писать на shell как на С

а зачем вам сейчас так нужно писать?(на shell как на C)?

как я уже писал: во всяких там RH стартовые скрипты давно превратились в страшное мессиво, управляемое внешними конфигами. Например, если Вы хотите поменять что-то в загрузке apache, идти надо не в стартовый скрипт, а куда-нить в:

Код: Выделить всё

[root@fedora /]# cat  /etc/sysconfig/httpd  | grep '='
#HTTPD=/usr/sbin/httpd.worker
#OPTIONS=
#HTTPD_LANG=C
#STOP_TIMEOUT=10
#PIDFILE=/var/run/httpd/httpd.pid

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

Код: Выделить всё

[root@fedora /]# cat   /lib/systemd/system/httpd.service
[Unit]
Description=The Apache HTTP Server (prefork MPM)
After=syslog.target network.target

[Service]
Type=forking
PIDFile=/var/run/httpd/httpd.pid
EnvironmentFile=/etc/sysconfig/httpd
ExecStart=/usr/sbin/httpd $OPTIONS -k start
ExecReload=/usr/sbin/httpd $OPTIONS -t
ExecReload=/bin/kill -HUP $MAINPID
ExecStop=/usr/sbin/httpd $OPTIONS -k stop

[Install]
WantedBy=multi-user.target

а при случае еще и какие-нить плюшки замутить

конечно... Причём сделать так, чтоб эти плюшки без systemd не работали. Что за плюшки-то?

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

скрипт. Только с хитрым синтаксисом.

конфиг....

[diesel]

Дистрибутивы сами без Лёни Поттера решат, что для них лучше.

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

[Bluetooth]

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

Странно, до сих такие предложения не выносились. Тем более, в такой форме.

[taaroa]

конечно... Причём сделать так, чтоб эти плюшки без systemd не работали. Что за плюшки-то?

убить зомби (zombie process, defunct process), например. ага-ага, в 2012 году традиционные линаксы на это просто не способны. в отличие от энтерпрайзного (настоящего™ unix®) solaris, например.
насколько это (сама реализация) удачно получилось – другой вопрос.

[drBatty]

за счет параллельного старта всех сервисов. красивая идея, кстати.

И по признанию самого Поттеринга - нереальная.

как я уже писал: во всяких там RH стартовые скрипты давно превратились в страшное мессиво, управляемое внешними конфигами.

редхатопроблемы.

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

ну можно как-то по особому запустить апач, что-бы он был в нужной группы. Или нет?

конфиг....

давайте считать конфигами только файлы, в которых сказано КАК запускать. А вот файл, в котором записано КОГДА и ЧТО запускать, давайте уж называть "скриптом"?

а потому что systemd - это не единственная в мире вещь, которой нужно знать в какой системе она работает.

повторяю вопрос - КОМУ ещё надо это знать?
Я не вижу других кандидатов, кроме вредоносного ПО.

убить зомби

что-то у меня такой необходимости не возникает...

насколько это (сама реализация) удачно получилось – другой вопрос.

а насколько она нужная? Может лучше выяснить, откуда эти зомби берутся? Или туберкулёз вы тоже предлагаете лечить таблетками от кашля?

[frp]

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

Зачем? Вот как раз эту функцию lsb_release выполняет на ура.

[frp]

да те же ethX, затем подключение к Сети, затем сетевые демоны. Как это всё запараллелить? А что у нас остаётся?

После поднятия ethX, например, будут параллельно запускаться все сетезависимые демоны (которых 100500 штук)
А после поднятия dbus - avahi, pulseaudio, dm-ы...
А еще во время поднятия dbus и ethX параллельно можно запускать alsa, acpid, bluetooth и т.д. и т.п.

Угу, что сунули пользователям убунты, то и жуют. Работает и слава богу.У них же не проводят опрос, хотят ли они переехать на systemd или не хотят. Так что не аргумент (:

90% пользователей убунты пользуется ей добровольно и могли бы легко съехать на другой дистрибутив. Так, что аргумент

[frp]

Во вторых, очевидно нельзя делать разделяемый /usr/

Не так давно была новость, что в арче это исправят/исправили. Ну и можно пофиксить самому путем перенсоа libdbus в /lib

Ну вот не верю я, что его скрипты, будут выполнятся быстрее bash'овских

Ищи истории успеха Debian и dash. Я вообще хз, дадут ли его сервисы скорость быстрее, чем bash, но они, как минимум, легче читаются и пишутся.

Вообще по твоему посту: выглядит как "а мне не нужна быстрая загрузка, поэтому ваш systemd - говно"