LINUX.ORG.RU
решено ФорумAdmin

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

 , , ,


4

3

Я не причисляю себя к опытным, так называемым «тру» линуксоидам, хоть и использую ArchLinux в качестве десктопа. Захотелось «осилить» сборку Gentoo. В хендбуке говорилось о выборе между Systemd и OpenRC. Погуглив, почитав Вики.генту и всякие форумы, так и не понял в чем их принципиальное отличие, а также плюсы и минусы. Расскажите, в чем их достоинства и недостатки? Что лучше выбрать?


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

Unix-принципы мертвы.

А примеры приведешь?

do one thing and do it well - посмотри на нынешний тренд микросервисных архитектур.

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

И т.п

Тем не менее, systemd абсолютно соблюдает принцип «do one thing and do it well». Любой, кто утверждает обратное, просто демонстрирует свою некомпетентность, вот и всё.

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

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

пруф, что там системд? ;)

    48.8% (50.8%) не детализируют дистрибутив,
    27.8% (23.2%) используют CentOS,
    7.6% (9.8%) - Cray Linux,
    3% (3.6%) - SUSE,
    4.8% (5%) - RHEL,
    1.6% (1.4%) - Ubuntu;
    0.4% (0.4%) - Scientific Linux 

https://www.opennet.ru/opennews/art.shtml?num=50902

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

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

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

А примеры приведешь?

Да куда ни ткни — везде примеры… Что в мире линуксовых кишок, что вне его. Возьми вот совершенно любой сложный софт, начиная от линуксовых DE, продолжая каким-нибудь гитлабом и заканчивая всякими профессиональными продуктами. Они все комбайны.

do one thing and do it well - посмотри на нынешний тренд микросервисных архитектур.

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

текстовые интерфейсы - сейчас json везде, где только возможно.

Формат сериализации — это не интерфейс. К тому же, в тех формулировках философии Unix, на которые ты сослался, ничего не говорится про «текстовые интерфейсы». Есть про хранение данных в текстовом виде и про фильтры (текстовые потоки). Давно ты видел какой-нибудь CAD/CAE, составленный из фильтров, работающих над текстом? А вернёмся к микросервисам и вебне: давно ты видел бэкенд, который состоит из юниксовых фильтров? А давно ты видел БД, хранящую данные в текстовых файликах? И чтобы обязательно select, join и update были фильтрами.

А там я хотел написать что адепты systemd бросаются общими философскими фразами без конкретики, юз кейсов.

Соринка, глаз, бревно.

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

Он же монолитный комбайн?

openrc? Каким боком он монолитный и каким боком он комбайн?

Tanger ★★★★★
()

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

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

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

выбор для новичка в общем то наибольшая проблема

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

Неа. Купил/кто-то-из-знакомых-дал cd диск с N вариантов онтопика и развлекайся. Инет тут нафиг не нужен был.

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

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

Да, печально, что для такой вроде бы стандартной задачи как ввод-вывод звука на колонки-наушники, будь то встроенные, беспроводные или проводные куча всякого зоопарка OSS/ALSA/Pulseaudio/Jack/(что там ещё), было бы чуточку проще, если бы был один свободный стандарт. Но мы живём в реальном мире.

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

Если бы так было, то в настройках ALSA были бы опции выключающие монопольный режим кроме определенных приложений например для записи звука и с доступом к блютусу. Пульса нужна только чтобы по сети звук передавать. Опять же реализуемо плагинами попроще. Зачем для звука целый сервер поднимать? Все это выглядит как насильное проталкивание ненужного сервиса потому что могут. Чем дольше проталкивают тем эффективнее обычно. Но этот метод не действует на людей с мозгами.

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

Да куда ни ткни — везде примеры… Что в мире линуксовых кишок, что вне его. Возьми вот совершенно любой сложный софт, начиная от линуксовых DE, продолжая каким-нибудь гитлабом и заканчивая всякими профессиональными продуктами. Они все комбайны.

Ну давай попробуем. KDE. Если попросишь установить KDE, то оно потянет 1) X11, который можно заменить на wayland 2) kwin, который можно заменить i3 или что угодно. 3) Consolekit -> ConsoleKit 2 и т. п. 4) udev -> eudev. 5) я же не говорю о прилагающемся софте. И где здесь комбайн?

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

Если попросишь установить KDE, то оно потянет <…>

Я про зависимости что-нибудь говорил?

И где здесь комбайн?

В самом KDE. Plasma, KCM, powerdevil, kded, вот это вот всё — компоненты «KDE-сессии». Оно всё друг без друга жить не может.

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

Формат сериализации — это не интерфейс.

К словам придираешься.
Write programs to handle text streams, because that is a universal interface - https://en.wikipedia.org/wiki/Unix_philosophy

Data streams should if at all possible be textual (so they can be viewed and filtered with standard tools). - Data streams should if at all possible be textual (so they can be viewed and filtered with standard tools).


А вернёмся к микросервисам и вебне: давно ты видел бэкенд, который состоит из юниксовых фильтров?

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

А давно ты видел БД, хранящую данные в текстовых файликах?

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

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

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

что из этого не нужно при работе с системными логами, большие объемы или минимальный отклик?

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

К словам придираешься.

Нет, не придираюсь. Использовать json и использовать текстовые потоки (т. е. быть фильтром) — это две абсолютно разные вещи.

В большинстве случае - REST, который основан на текстовых потоках.

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

То, что там внутри HTTP, который обычно пускается поверх потокового TCP, и то, что внутри полезной нагрузки обычно текстовый жсон, — это вообще не имеет никакого значения.

https://ru.wikipedia.org/wiki/REST#%D0%A2%D1%80%D0%B5%D0%B1%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F_%D0%BA_%D0%B0%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B5_REST

Применять голову - никто не отменял

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

Это именно что апологетов Unix-философии нужно попросить применять голову, а не пихать «юникс-вей» как мантру куда ни попадя.

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

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

что из этого не нужно при работе с системными логами, большие объемы или минимальный отклик?

На десктопе и то и то не нужно.
А когда это нужно, syslog-ng, rsyslog, ELK etc отлично с этим справлялись. Непонятно зачем нужно было в systemd придумывать велосипед.

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

А когда это нужно, syslog-ng, rsyslog, ELK etc отлично с этим справлялись. Непонятно зачем нужно было в systemd придумывать велосипед.

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

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

Похоже ты под «текстовыми потоками» понимаешь сугубо пайпы. А имеется ввиду хранение и обмен информации в текстовом виде. Так что REST + JSON - хороший пример реализации этого принципа.

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

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

что из этого не нужно при работе с системными логами, большие объемы или минимальный отклик?

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

Гента с systemd скорее всего самый быстро загружающийся дистр из полноценных. Быстрее только всякие с BusyBox, musl и rootfs в памяти

vertexua ★★★★★
()
Ответ на: комментарий от Kroz
$ journalctl --disk-usage
Archived and active journals take up 2.1G in the file system.

это всего лишь на моем локалхосте, где я периодически чищу логи. А теперь представим сервер с парой процессов, спамящих в логи 24/7. Объемы будут в десятки, а то и сотни раз больше. Удачно вам погрепать все это, а потом передать по сети с недешевым трафиком.

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

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

Никогда не чищу.

Archived and active journals take up 384.0M in the file system.
anonymous
()
Ответ на: комментарий от BattleCoder

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

Бинарные логи - это изврат. Лог должен быть текстовый т.ч.ка.

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

Лог должен быть текстовый т.ч.ка.

Лучше видео.

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

А потом извараются парся текст, вместо запроса в «бд», да.

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

Похоже ты под «текстовыми потоками» понимаешь сугубо пайпы.

Нет, не я:

Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input.

https://en.wikipedia.org/wiki/Unix_philosophy#Origin

Make every program a filter.

https://en.wikipedia.org/wiki/Unix_philosophy#Mike_Gancarz:_The_UNIX_Philosophy

Здесь совершенно определённо говорится про пайпы. А вот это вот «имеется ввиду <…> обмен информации в текстовом виде» ты сам себе выдумал.

Так что REST + JSON - хороший пример реализации этого принципа.

Абсолютно неверно, потому что часть про «потоки» не реализуется. RESTful API оперируют запросами и ответами с фиксированной схемой и конечным размером.

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

А теперь представим сервер с парой процессов, спамящих в логи 24/7

Лимиты легко настраиваются.

Удачно вам погрепать все это

Легко грепается встроенными средствами. journalctl позволяет тонко фильровать вывод по юнитам, датам и прочему.

по сети с недешевым трафиком

Трафик бесплатный.

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

Как раз таки джорналд активно пресекает спам. По дефолту довольно неприятные лимиты стоят. А потом хейтеры жалутся: логи потерялись! Не логирует! А он как раз не логирует спам из-за лимитов, чтоб спамный сервис не засрал весь диск логами.

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

это всего лишь на моем локалхосте, где я периодически чищу логи. А теперь представим сервер с парой процессов, спамящих в логи 24/7. Объемы будут в десятки, а то и сотни раз больше. Удачно вам погрепать все это, а потом передать по сети с недешевым трафиком.

1. Мы говорим про десктоп. Как же вы задолбали скатываться на высоконагруженные сервера. Нахрена рядовому хомячку, который на своей Убунточке 99% процентов времени ходит в WEB, мощная система сбора логов?
2. С чем из этого не справлялись rsyslog, ELK, Graylog?

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

Похоже ты под «текстовыми потоками» понимаешь сугубо пайпы.

Нет, не я:

Нет, именно ты.

Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input.

WEB Server - output; curl - input.

Make every program a filter.
https://en.wikipedia.org/wiki/Unix_philosophy#Mike_Gancarz:_The_UNIX_Philosophy
Здесь совершенно определённо говорится про пайпы.

Где? Где ты видишь тут слово «pipe»? Говорится про потоки.
https://en.wikipedia.org/wiki/Filter_(software)
A filter is a computer program or subroutine to process a stream, producing another stream.

Это писалось во времена, когда доступ в Интернет далеко не у всех. А программы в 99% взаимодействовали только в пределах одного хоста используя пайпы и unix-сокеты. Сейчас мир изменился, очень много взаимодействия происходит по сети. И теперь «программа принимающая на вход поток данных и выдающая на выходе поток данных» может запросто использовать сетевые протоколы.

Притом то, что ты привел - только часть. Unix философия - не только про потоки. По твоей же ссылке: «Store data in flat TEXT files.»

Посыл такой: храните и передавайте информацию в текстовом виде - за исключение случаев когда это не удовлетворяет конкретным требованиям, например, performance, security и т. п.

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

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

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

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

WEB Server - output; curl - input.

Премия «Золотой шланг-2019».

Где? Где ты видишь тут слово «pipe»? Говорится про потоки.

Вот здесь:

In Unix and Unix-like operating systems, a filter is a program that gets most of its data from its standard input (the main input stream) and writes its main results to its standard output (the main output stream).

https://en.wikipedia.org/wiki/Filter_(software)#List_of_Unix_filter_programs

Алё, гараж, прекращаем шланговать. В Unix-like системах программы-фильтры — это именно «пайпы». И когда отцы-основатели Unix (или те, кто их пересказывает) говорят о «фильтрах» или «потоках», имеются в виду именно программы, которые читают текст с stdin и пишут текст в stdout. Других тогда просто не существовало.

Это писалось во времена <…> Сейчас мир изменился <…> И теперь <…>

Меня совершенно не интересует твоя личная интерпретация Unix-философии, натягивать сову на глобус можешь даже не пытаться. Мы обсуждаем только то, что написано.

И ты всё ещё упорно не обращаешь внимания на тот факт, что REST-интерфейсы (на которые ты уже третий раз пытаешься сослаться) не имеют никакого отношения к «потокам данных». Вот вообще никак.

Притом то, что ты привел - только часть. Unix философия - не только про потоки. По твоей же ссылке: «Store data in flat TEXT files.»

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

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

а когда углубились в конкретику, ничего путного ответить не смог

Возможно, это ты просто упорно «не можешь» воспринять возражение, который не укладывается в твою картину мира?

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

Так вот, это уже не твоё дело, зачем это нужно и зачем было придумывать велосипед. Здесь речь идёт только о том, оправданы ли бинарные логи. Ответ — оправданы, по твоим же соображениям.

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

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

В интернете куча информации про достоинства и недостатки.

По поводу выбора - раз выбираете Gentoo, советую openRC - она там «роднее», полностью проторенный вариант, а поддержка systemd чуть хуже. Когда openRC будет освоена, поймете, что весь гон на systemd со стороны её противников - пустой выхлоп. Использовать systemd в gentoo советую только в случае, если ещё где-либо есть linux, на котором наверняка есть systemd - в таком случае есть бонус в виде единообразия.

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

замечательно

а каким болком тут говнянное системд?

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

да ты лошара просто…

а у нас был дружный луг… лет 20 назад…

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

У одни людей работает, а у других нет, у кого новые AMD Ryzen вообще не грузилась система в августе из-за бага в systemd. На всех системах без systemd всё работало

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

Не, люди не то, что читать маны по systemd не хотят, они вообще не хотят systemd. А хотят свою СИ, например, openRC, чтобы можно было поставить из стандартных реп и управлять демонами как им удобно, а не как заставляют извне

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

In Unix and Unix-like operating systems, a filter is a program that gets most of its data from its standard input (the main input stream) and writes its main results to its standard output (the main output stream).
В Unix-like системах программы-фильтры — это именно «пайпы».

А теперь перечитай свою же цитату. Там ничего не говорится про пайпы. Говорится про потоки ввода/вывода.

Если ты вывод одной программы перенаправишь на ввод другой, то, да, ты получишь pipe. Но ты забываешь, что поток можно перенаправить и в файл, и в сокет. Прочитай внимательно вот это: http://xmodulo.com/tcp-udp-socket-bash-shell.html - тут ничего не говорится про пайпы, только лишь про сеть, но идет работа с stdin и stdout. Так что filter работает далеко не только с пайпами.

И ты всё ещё упорно не обращаешь внимания на тот факт, что REST-интерфейсы (на которые ты уже третий раз пытаешься сослаться) не имеют никакого отношения к «потокам данных». Вот вообще никак.

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

По твоей же ссылке: «Store data in flat TEXT files.»

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

Ты, наверное, сам с собой что-то обсуждаешь.

Оглянись: почти все конфиги хранятся в тексте; хранение в в бинарном виде а-ля Windows Registry умерло. Открой исходник WEB страницы, на которую смотришь - текст; почему не какой-то скомпиленный бинарь аля Java bytecode, ведь браузеру было бы так проще? Базы данных - да, бинарные, но только потому, что там есть требование к объему и скорости; и то - сегодня многие DB как минимум умеют работать с JSON, пресловутым text-based неоптимальным форматом, а некоторые вообще опираются на JSON как основной формат. Да, ты хоть распакуй DOCX - там же все в текстовый вид переведено. Даже Микрософт признает что в тексте хранить оптимальней. И, заметь, это они не так давно перешли на такой формат.

и зачем-то вспомнил про десктоп, в котором «и то, и то не нужно».

Вот я про это и говорил, когда упомянул что systemd-адепты не любят конкретку. Неужели даже и тени сомнения не проскакивает, что есть разные use case'ы, и не существует одного решения которое удовлетворило бы всех?

А с чего ты взял, что основной кейс - enterprise сервера? Я вот хочу поговорить про десктопы, и мне интересно зачем на десктопе бинарный лог. Зачем в десктопные дистры тянуть эту ерунду по дефолту?

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

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

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

А что, демоны как-то не так запускаются что ли «извне»? А, ну да… «ключ на старт — протяжка 1 — продувка — протяжка 2 — ключ на дренаж — земля-борт — пуск — зажигание — предварительная, промежуточная, главная, подъем».

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

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

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

Не, люди не то, что читать маны по systemd не хотят, они вообще не хотят systemd. А хотят свою СИ, например, openRC, чтобы можно было поставить из стандартных реп и управлять демонами как им удобно, а не как заставляют извне

alias 'stop'='sudo systemctl stop'
alias 'start'='sudo systemctl start'
alias 'restart'='sudo systemctl restart'
alias 'status'='sudo systemctl status'

etc.

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

Restart относитсч только к системд? Ребят, если вам не лень писать простыни алиасов, то зачем системд в которой все команды так перелопатить придется и нельзя будет простые команды в системе использовать. Обычные шелл скрипты проще. Особенно runit с его sv up, down, restart, status. Просто дебилы не подумали как системдой люди будут пользоваться и запилили мега длинные команды. Особенно если их можно сократить до одной-двух букв.

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

Хватит науськивать на однообразие. Оно относится только к одному красношапочному дистру и дистрам на его основе с гномом, системдой и пшаудио. Линукс имеет свои команды системы и вот они и есть единообразие. А обвес вокруг ядра это не линукс. И наверняка вокруг у новичка нет кучи машин замусоренных экспериментами с системдой. А то самые хитрые предпочитают говорить о загрузке, но не перезагрузке. А теперь посчитайте в цифрах разницу с разными файловыми системами и жесткими дисками с ssd. Разница будет едва заметная при параллельном запуске сервисов. Принципиальная разница лишь в наличии или отсутствии тупняка при перезагрузке. А кроме того в наличии стабильной работы без блоатварей с шпионским функционалом. Всей этой дряни нет в OpenRC, runit. Так какого лешего вы все еще топите за системдэ? Вы там вообще не способны вести аргументированную дискуссию? Единственное рабочее решение это elogind, который выдрали из системды чтобы грузить системдэзависимые рабочие столы. Остальное, пораженное блоатварью тоже можно разделить на части. И именно это будет правильно. Те же иксы не заставляют ставить вообще все. И вот тогда и будет шанс у системдового загрузчика, который довели до ума люди, выдравшие блоатварь стать работоспособным подобием SMF в солярисе. ZFS портировали и даже запихнули в установщик популярной бубунты. Дело за малым - довести до ума системдэ и портировать SMF. Вмот тогда все смогут выбрать что им нужно, а не палить из системды по иниту как будто так есть необходимость в чем-то кроме скриптов.

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