В чем отличие OpenRC от Systemd?

Вот, кстати, да. systemd продавали с помощью двух лозунгов:

1. Загрузка будет просто ураганно быстрее.

2. Баш-скрипты сложные и непонятные, а в системд примитивный сервис на 10 строк написал и всё работает.

Выяснилось, внезапно, нет, не быстрее. Сколько рэйду нужно винтами пожужжать, столько и будет. Сколько базе нужно времени запуститься, столько и будет etc.

Но, что хуже — системд невероятно сложная система. Шаг вправо, шаг-влево и нужно просто тонну манов скурить, чтобы разобраться, почему что-то идёт не так.

Так что единственное, в чём systemd хоть немного успешен — это быть вендорлоком редхат и давать работу администратором systemd, поздравим его хоть с этим.

Вот, кстати, да. systemd продавали с помощью двух лозунгов:

Загрузка будет просто ураганно быстрее.

А давай-ка устроим факт-чек.

Yes, systemd is fast (A pretty complete userspace boot-up in ~900ms, anyone?), but that’s primarily just a side-effect of doing things right. In fact, we never really sat down and optimized the last tiny bit of performance out of systemd. Instead, we actually frequently knowingly picked the slightly slower code paths in order to keep the code more readable. This doesn’t mean being fast was irrelevant for us, but reducing systemd to its speed is certainly quite a misconception, since that is certainly not anywhere near the top of our list of goals.

http://0pointer.net/blog/projects/the-biggest-myths.html

Баш-скрипты сложные и непонятные, а в системд примитивный сервис на 10 строк написал и всё работает.

Но, что хуже — системд невероятно сложная система. Шаг вправо, шаг-влево и нужно <…> разобраться, почему что-то идёт не так.

Здесь нет противоречия. systemd упрощает 95% случаев ценой усложнения 5% извращённых юзкейсов. И это правильно.

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

OpenRC rc_parallel=«YES» vs SystemD vs Runit [Linux]

https://www.youtube.com/watch?v=7Nm0yBouAvs

Итоги:

Runit 15,6333 секунд.

OpenRC 20,0500 секунд.

Systemd 23,2167 секунд.

OpenRC rc_parallel=«YES» vs SystemD vs Runit [Linux]

Не так. На самом деле:

Void vs Arch vs Gentoo, причем с разным набором пакетов. Так что уноси обратно.

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

Толсто, очень толсто

А давай-ка устроим факт-чек.

А давайте. Только чур условимся, что синтетические тесты меня вообще не интересуют. Какой смысл, что кто-то в лабораторных условиях поставил рекорд, когда вот передо мной реальный ноутбук, к-рый загружается порядка 45 секунд (это 45 тысяч миллисекунд, что в 50 (пятьдесят) раз медленнее заявленной вами цифры)?

systemd упрощает 95% случаев ценой усложнения 5% извращённых юзкейсов.

Linux нужен для 5% извращённых случаев. Для 95% обычных есть операционные системы и получше.

Какой «заявленной мной цифры»? Ты вообще мой пост прочитал? systemd не про скорость, она там получается побочным эффектом. Никто не пиарит systemd лозунгами «Загрузка будет просто ураганно быстрее», которые ты привёл.

вот передо мной реальный ноутбук, к-рый загружается порядка 45 секунд

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

Linux нужен для 5% извращённых случаев. Для 95% обычных есть операционные системы и получше.

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

Если комп загрузился медленнее с системд - системд выбрасывается.

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

1. Нам совершенно всё равно, загрузится ли система за 15 или 25 (или 125) секунд.

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

systemd не про скорость,

Никто не пиарит systemd лозунгами «Загрузка будет просто ураганно быстрее»

Врите-врите, да не завирайтесь. А то я не помню толп бегающих по лору хомячков с их «нам плевать на вашу философию юникс, зато у нас загрузка ускорится!!111!!». Теперь, когда это обещание завершилось оглушительным провалом, рассказываете нам, что не очень-то и хотелось.

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

Да как они вообще смеют использовать что-то, кроме божественного РедХата!

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

Хорошо, насчёт «никто» я был не прав. Дураки везде есть.

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

Ложь. Я привёл комментарий автора systemd, написанный, когда systemd ещё ни в одной ОС толком не было.

Да как они вообще смеют использовать что-то, кроме божественного РедХата!

Я так понимаю, по существу сказать нечего?

Гном для нормальной работы будет требовать восьмиядерник с кучей памяти.

Отснял скриншоты: F31 Gnome with 1 GiB RAM, с двумя ядрами, в том числе с запущенным браузером с вкладкой ЛОРа: https://imgur.com/a/bKbDVbe

Выделение ЛЮБОЙ памяти в режиме для исполнения и изменения одновременно (WX) - категорически запрещено!!!

Категорически запрещено кем?

Математиками 1960-тых годов. Разработчиками OpenBSD, разработчиками Linux+PAX, мною лично!!!

На основании гарантий неизменности исполняемого кода даются определенные гарантии ИТ безопасности в OS.

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

Любой современный серверный дистрибутив Linux по умолчанию ведёт себя именно так.

Пример дистрибутива который по умолчанию не создает областей с WX доступом: https://mirror.yandex.ru/mirrors/ftp.linux.kiev.ua/Linux/CD/Dystryk/

Ни systemd, ни logind не мешают тебе поправить fstab и сделать так, чтобы этого не происходило.

Следовательно, systemd не мешает соблюдению этого правила, а в том, что оно не соблюдается по умолчанию, вины systemd нет (в популярных серверных дистрибутивах оно не соблюдалось никогда, в т. ч. до systemd).

Именно что мешают!!! Об этом и речь! Ссылки дал:

Linux в опасности! (комментарий)

Linux в опасности! (комментарий)

Linux в опасности! (комментарий)

Сравнение SysV и systemd (комментарий)

"С 1970 по 2010 все так и было, изначально в математическую UNIX модели безопасности с R, W, X заложено разделение: или W - данные, или X - программы.

Выше привёл правильный пример разбиения дисков и опций их монтирования.

Выше также указал на то что systemd, elogind лишают вас возможности устанавливать правильные, безопасные опции монтирования: /run/users/${USER} монтируется с опциями exec,rw, это сделано в недрах программы, без возможности изменить пользователю в настройках. Можно принудительно монтировать в fstab перед запуском elogind, но после выхода и повторного входа пользователя elogind перемонтирует диск с опциями exec,rw. С этим есть возможность боротся только на уровне ядра ОС - запрещать монтирование дисков в режиме exec,rw, но кто с пользователей сможет пропатчить и собрать такое ядро? Тогда systemd c elogind будут сильно ущемлены.

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

Ответ сегодня задать и использовать правильные опции монтирования дисков мешают systemd и его ассоциированная версия без явных троянов elogind.

Вывод не использовать systemd, elogind, polkitd,… в своей системе. Предлагаю всем дружно бойкотировать эти программы. Пока побеждает тьма, дистры ставят раком и вставляют в *опу systemd так им удобнее за вами приглядывать."

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

Живи и дальше в своей реальности. А в нашей старт системы за 5-10 секунд. Но ты можешь и дальше ставить личные принципы выше общепринятых. Будешь сидеть и радоваться загрузке ос за 20 секунд и думать, что это офигенно быстро.

Молодец, только 850 мегабайт полностью заняты, а оставшееся занято кэшем. Нерезонно использовать такой комп если можно было использовать DE полегче или WM, чтобы можно было хотя бы видео посмотреть. А то там файл подкачки уже загадил систему и ее отзывчивость должна быть крайне низкой. И вообще очевидно же, что быстрее и легче будет OpenRC, и совсем ураганная скорость даст Runit. Systemd создана для тормозов. Придумывать ей оправдания можете сколько угодно. Вот только вытянет ее разве что рейд из твердотельных накопителей, если он будет инициализироваться мгновенно и огромный кэш процессора типа тридриппера или серверные 64-ядерные эпики.

Ссылки дал

По ссылкам точно такая же шизофреничная истерия. Лекарства принять не забыл?

Выше также указал на то что systemd, elogind лишают вас возможности устанавливать правильные, безопасные опции монтирования

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

Можно принудительно монтировать в fstab перед запуском elogind, но после выхода и повторного входа пользователя elogind перемонтирует диск с опциями exec,rw

Ложь: https://github.com/systemd/systemd/blob/master/src/login/user-runtime-dir.c#L59

Не говорю уже о том, что весь /usr/lib/systemd/systemd-user-runtime-dir можно заменить своим скриптом — и, например, вообще эту tmpfs не создавать.

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

И в подъезде тоже systemd, наверное, нассал?

Ответ сегодня задать и использовать правильные опции монтирования дисков мешают systemd и его ассоциированная версия без явных троянов elogind.

Опять шизофрения от бездарного анонимуса. Каких «явных троянов», дубина?

Вывод не использовать systemd, elogind, polkitd,… в своей системе. Предлагаю всем дружно бойкотировать эти программы. Пока побеждает тьма, дистры ставят раком и вставляют в *опу systemd так им удобнее за вами приглядывать."

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

Да.

И вот это:

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

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

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

Кому очевидно?

Бездарный анонимус совсем уже распоясался.

А в нашей старт системы за 5-10 секунд. Но ты можешь и дальше ставить личные принципы выше общепринятых. Будешь сидеть и радоваться загрузке ос за 20 секунд и думать, что это офигенно быстро.

Глупость несешь. Моя система стартует до 5 минут, наверно в районе 2-3 минут, секундомером незасекал. И systemd этот процесс не ускорит!

Спроси у своей девушки какой секс она хочет - хороший или быстрый?

С загрузкой GNU/Linux, как с сексом - можно загрузится быстро, а можно загрузится хорошо…

При хорошей загрузки, система с systemd будет грузится также примерно 2-3 минуты!

Хорошая загрузка:

НАДЕЖНАЯ проверка целостности:

1. Загрузчика.

2. Модулей и настроек grub.

3. Ядра и инитрд.

4. Всех исполняемых файлов, библиотек, их настроек, модулей ядра (если надо немонолитное).

Все это в 10 секунд с systemd уже не вложется, в 20-30 можно. А теперь о тяжелых сервисах:

5. Загрузка антивирусных баз clamav для сканирования всего сетевого трафика, домашних и временных каталогов пользователей при доступе.

Загрузка антивирусных баз, а у меня их очень много, использую неофициальные базы - 2-3 минуты!

6. Загрузка пользовательского рабочего места со сканированием при доступе его файлов - 1 минута.

Задай этот вопрос Dave Reisner, мейнтейнеру early userspace в Arch Linux. Как я уже сказал, лично мой опыт здесь нерелевантен.

Хорошо, насчёт «никто» я был не прав. Дураки везде есть.

Обожаю, когда персонах обвиняющий всех и вся в шланговании сам является эталоннейшим шлангом!

Это было великолепно!

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

Апстрим совершенно долбанутый, поэтому пришлось поступиться принципами арча и по сути форкнуть код, запатчив там всю билдсистему и ещё много чего. Переписывание загрузки фирмвари на udev+systemd (SYSTEMD_WANTS — огонь!) позволило мне уменьшить количество кода более чем в два раза и закрыть несколько рейсов, которые напрямую влияли на стабильность загрузки фирмвари с несколькими принтерами.

Сравнение SysV и systemd (комментарий)

«… Как кульминацию деятельности «уважаемого» Потеринга привожу пример polkitd. Это уникальное поделие на диске имеет один исполняемый код, а загрузившись в оперативную память код внезапно изменяется и становится другим!!! И это ещё не весь фокус, сканирование антивирусником загруженного в оперативку исполняемого кода polkitd матерится на ВИРУС…»

Еще раз для трудных в обучении: systemd, elogind, udisks2 умышленно спроектированы так чтобы создавать области памяти доступные для исполнения и записи одновременно! И никаких возможностей для пользователя в каком-то ктнфиге указать:

nodev,noexec,nosuid

нет! Надо или патчить исходный код программы:

Linux в опасности!

или патчить ядро Linux:

Сравнение SysV и systemd (комментарий)

или не использовать дистрибутивы с systemd, elogind, udusks2, polkitd, ……….

Oh?

Как кульминацию деятельности «уважаемого» Потеринга привожу пример polkitd

polkitd

Поттеринг

https://static.tvtropes.org/pmwiki/pub/images/jjj_laugh.png

Это уникальное поделие на диске имеет один исполняемый код, а загрузившись в оперативную память код внезапно изменяется и становится другим!!!

Анонимус открыл для себя скриптовые языки с JIT?

Еще раз для трудных в обучении: systemd, elogind, udisks2 умышленно спроектированы так чтобы создавать области памяти доступные для исполнения и записи одновременно!

Ещё раз для шизофреничных анонимусов, количество восклицательных знаков не влияет на убедительность твоих заявлений (хотя нет, влияет, отрицательно).

И никаких возможностей для пользователя в каком-то ктнфиге указать

man fstab

polkitd - уникальное поделие на диске имеет один исполняемый код, а загрузившись в оперативную память код внезапно изменяется и становится другим!!!

Анонимус открыл для себя скриптовые языки с JIT?

polkitd - бинарь, хотя для своих настроек тянет ворох мрачных скриптов.

Тем не менее антивирус матерится на процесс polkitd в оперативной памяти как на злобного виря.

Еще раз для трудных в обучении: systemd, elogind, udisks2 умышленно спроектированы так чтобы создавать области памяти доступные для исполнения и записи одновременно!

И никаких возможностей для пользователя в каком-то ктнфиге указать

man fstab

systemd, elogind, udisks2 не читают настроек с /etc/fstab

systemd, elogind, udisks2 не читают настроек с /etc/fstab

$ grep '/run/user' /etc/fstab
tmpfs                          /run/user/1000  tmpfs  rw,nosuid,nodev,noexec,mode=700,uid=1000,gid=1000  0  0

$ mount | grep '/run/user'
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=700,uid=1000,gid=1000)

На этом я, пожалуй, закончу тебе отвечать.

антивирус матерится на процесс polkitd в оперативной памяти как на злобного виря

Что за антивирус такой?

Ты как раз находился в самом интересном месте.

Разлогинся юзером с id 1000 и ввойди в систему им опять. Потом еще раз выполни:

[code] $ mount | grep ‘/run/user’ [/code]

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

Можно прицепится что базы антивирусные ложное срабатывание дают.. Но за 2 года работы вирус в рабочем процессе найден только один в polkitd.

Писать здесь его название пока не буду.

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

Тем не менее антивирус матерится на процесс polkitd в оперативной памяти как на злобного виря.

Любого персонажа, который заявляет о наличии «злобного виря» в любом СПО и не может продемонстрировать этого виря в коде — хорошо бы банить. Пожизненно, за ментальные дисфункции, несовместимые с продуктивным участием в обществе. И отправлять на принудительное лечение.

Это местный криптошизофреник, воюющий против скриптов. Как-то обвинял меня в том, что я испортил KDE внедрением JIT. В одном из недавних тредов утверждал, что в Украине разработчиков СПО убивают нейтронами. Всё плохо, в общем.

в Украине разработчиков СПО убивают нейтронами

Нет никого, кто бы это опроверг. Криптошизофреник дело говорит.

У меня так не получается: Сравнение SysV и systemd (комментарий)

Делал следующие:

1. Прописал в /etc/fstab монтировать /run/user/1000 с опциями nosuid,nodev,noexec

2. Загружаю Linux с elogind смотрю под рутом /run/user/1000 смонтирован с нужными опциями.

3. Вхожу под пользователем 1000, опять смотрю /run/user/1000 - смонтирован с нужными опциями.

4. Завершаю сесию пользователя 1000. Смотрю /run/user/1000 он размонтирован! Нет в системе диска /run/user/1000.

5. Вхожу в систему под пользователем 1000 и смотрю опции монтирования /run/user/1000. Вот именно в этом месте начинаю сильно материться на Пола Потеринга…

Решения два:

1. Патчить все эти программы

2. Патчить ядро Linux чтобы подобного впредь не было. Запретить на уровне ядра монтировать любой диск с опциями rm,exec. В этом случае в систему вхожу нормально (пункт 5) но диска /run/user/1000 в системе уже нет. Работает все тоже без замечаний.

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

Ты много сканеров для Linux под GPL знаешь? Использовал его самые стандартные антивирусные базы.

Как-то обвинял меня в том, что я испортил KDE внедрением JIT.

Ты на себя много берешь. Ты же не один портил KDE.

Для конечного пользователя наличие скриптов с JIT неприемлемо по требованиям безопасности. Для разработки скрипты ускорят процесс в разы. Надо компилятор используемых вами скриптов в код С++ чтобы потом скомпилить бинарь без JIT. И эта проблема решится.

Любого персонажа, который заявляет о наличии «злобного виря» в любом СПО и не может продемонстрировать этого виря в коде — хорошо бы банить.

Не спеши с баном! Ставь этот антивирус, сканируй на вирусы процес в памяти polkitd. Название виря увидел? Далее читай информацию о этом вирусе…

Ставь этот антивирус

Как он называется?

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

Еще раз смотри видео. А то пытаетесь много всего написать чтобы не было видно главного. Вот тут смотри. Видишь цифры? Больше - хуже.

OpenRC rc_parallel=«YES» vs SystemD vs Runit [Linux]

https://www.youtube.com/watch?v=7Nm0yBouAvs

Итоги:

Runit 15,6333 секунд.

OpenRC 20,0500 секунд.

Systemd 23,2167 секунд.

Еще раз смотри видео. А то пытаетесь много всего написать чтобы не было видно главного. Вот тут смотри. Видишь цифры? Больше - хуже.

«Главного»?

Больше — плевать. Меньше — плевать. Плюс, сравнение очевидно некорректное.

Ты тут топил, что системд ускоряет загрузку и все такое.

Пруфца бы.

Но абсолютная истина в том, что

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

Сам ты шизофреник. Смотри цифры. Твое упрямство - твои проблемы.

Еще раз смотри видео.

А что твое видео? Абсолютный конь в вакууме, у меня systemd загружает систему за 5 секунд. долго?

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

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

Никому не нужно тебя убеждать в чем-то.

Ну и не убеждай. Не нравится systemd, это твой выбор.

Ты же не выступал против заявлений в секундной разнице в пользу системд.

Мне на них пофиг, в обе стороны.

Сам иди делай одинаковые настройки. Никому не нужно тебя убеждать в чем-то.

Слив засчитан. Следующий!