LINUX.ORG.RU

Релиз systemd 257

 


0

2

Вышла новая версия свободного системного менеджера systemd.

Нововведения:

  • Изменения, нарушающие обратную совместимость:

    • Переработана логика обработки ключа --purge компонента systemd-tmpfiles: теперь удалению подвержены только те пути из tmpfiles.d/, которые помечены флагом $.

    • Поддержка cgroup v1 по-умолчанию отключена; для того, чтобы принудительно включить ее, нужно передать systemd параметр SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1 через командную строку ядра.

    • Символические ссылки /dev/disk/by-id/nvme-*, для которых не указан NVMe неймспейс, теперь указывают на неймспейс 1; ссылка не будет создана, если неймспейс 1 не существует.

  • libsystemd:

    • json API, предоставляемый libsystemd, доступен как публичный интерфейс с именем sd-json.

    • Также libsystemd предоставляет интерфейс sd-varlink, реализующий IPC varlink.

    • sd-dbus предоставляет метод sd_bus_pending_method_calls(), возвращающих количество открытых асинхронных вызовов для указанного соединения.

    • Интерфейс sd-device получил новый метод sd_device_monitor_is_running(), который позволяет узнать, активен ли указанный объект monitor.

  • Инициализация системы и управление сервисами:

    • Теперь переменная REMOTE_ADDR может хранить адрес не только IP, но и UNIX сокетов.

    • .socket юниты поддерживают протокол Multipath TCP.

    • Упрощен алгоритм инициализации системного времени.

    • x-systemd.wants=, новая опция /etc/fstab, позволяет указывать зависимости типа Wants.

    • Параметр RestartMode= поддерживает значение debug: в случае аварийного завершения работы демон будет перезапущен в режиме отладки.

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

★☆

Проверено: CrX ()
Последнее исправление: Dimez (всего исправлений: 6)
Ответ на: комментарий от hateWin

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

Любая вменяемая поддерживаемая альтернатива его ушатает.

Возьмём простой пример. Начало работы с терминалом Yakuake.

Создание сессии.

qdbus org.kde.yakuake /yakuake/sessions org.kde.yakuake.addSession

Кому: org.kde.yakuake.
Вызов: /yakuake/sessions org.kde.yakuake.addSession.
На выходе номер новой сессии.

Очевидные проблемы.

Сессия в целом никак не связана со временем жизни текущего процесса. Если он умрёт, то сессия продолжит своё бесцельное существование.

Итог: даже как протокол для приложений рабочего стола – посредственность.

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

Ты лучше скажи, как так вышло, что @Lrrr вначале назвал меня макакой, когда я сказал ему, что подход «ваш дбас — сраное говно, давайте запилим IPC на сокетах» ведет к необходимости изобретения IPC протокола с нуля, а потом использовал varlink как козырь в рукаве, хотя varlink реализует именно тот сценарий, о котором я говорил? А теперь он еще и свалил в кусты.

hateWin ★☆
() автор топика
Ответ на: комментарий от thegoldone

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

https://dbus.freedesktop.org/doc/dbus-run-session.1.html

dbus-run-session is used to start a session bus instance of dbus-daemon from a shell script, and start a specified program in that session. The dbus-daemon will run for as long as the program does, after which it will terminate

Одна из черепашек п*здит

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

Не нужно привязывать протокол к способу обмена. Можно и через трубу HTTP/1 запросы слать. Он останется HTTP/1. А труба останется трубой.

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

Дубас добавили как костыль.

На момент создания systemd нормальной альтернативы не было. DBus был использован по причине распространенности, чтобы всем было проще пилить совместимые приложения.

Все понимали, что это говно, все пытались починить. Теперь вот делают varlink. Это нормальный итеративный подход.

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

Можно и через трубу HTTP/1 запросы слать.

А протокол ты где возьмешь? Его все еще нужно разработать и стандартизировать, причем с последним будет больше всего проблем, потому что протокол системной шины должен устраивать разработчиков большинства компонентов ОС.

DBus был кривой-косой, но он работал, худо-бедно договорились. Теперь сделают новую шину с учетом прошлых ошибок, и переведут всё на нее, закопав DBus, как раньше закопали DCOP, корбу и прочий хлам.

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

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

Только при чём тут сессия Дубаса

При том, что ты сказал, что сессия дбаса никак не привязана к времени жизни процесса, с которым она ассоциирована. Но это не так

hateWin ★☆
() автор топика
Ответ на: комментарий от thegoldone

Кстати, только что проверил через D-Spy. При запуске, к примеру, transmission, для него создается новая шина в рамках пользовательской сессии. При завершении процесса шина закрывается. Так что твой пример не в кассу

hateWin ★☆
() автор топика
Ответ на: комментарий от thegoldone

Ни HTTP, ни сокеты не предоставляют готовый высокоуровневый протокол IPC. Если ты отказываешься от DBUS и пытаешься заменить его коммуникацией через сокеты, тебе придется разработать и реализовать свой протокол

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

Извини, не хочу лезть в вашу жаркую дискуссию, но вот этот d-spy только флатпаком ставится? Чот в репах минта не могу найти. Я когда-то допиливал d-bus-интерфейс к некому сервису в рамках OpenBMC, мне такого инструмента не хватало. Я как-то обходился gdbus introspect/monitor, но чот не сказать, что это офигеть как удобно. Я чисто положить в копилочку тулзов для себя, вдруг еще понадобится?

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

Т.е. если перефразировать:


SysVinit был кривой-косой, но он работал, худо-бедно договорились. Теперь сделают новую систему инициализации с учетом прошлых ошибок, и переведут всё на нее, закопав SysVinit, как раньше закопали System III, upstart и прочий хлам.

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


А протокол ты где возьмешь?

Это application level. Способ связи свой протокол навязывать не должен. Просто предоставлять двунаправленное соединение как файл. Приложения уже между собой договариваться какой там протокол и прочее.

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

Да это всё не имеет отношения к способу связи. Возьмём простой пример

connect(remote_url) -> connection

// work with connection

close(connection)

Всё. Единственное, что должен обеспечивать способ связи – это разрешать remote_url и соединять две точки.

Причём не обязательно remote_url должен иметь какой-то единый однозначный эталонный вид. Он может разрешаться по разному. В зависимости от префикса (схемы) и так далее.

А протокол обмена – этим занимаются приложения, когда уже установлено подключение.

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


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

А этому неплохо способствует т.н. the UNIX way. Когда одно приложение (система) не впитывает в себя всё вокруг.

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

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

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

Ни HTTP, ни сокеты не предоставляют готовый высокоуровневый протокол IPC. Если ты отказываешься от DBUS и пытаешься заменить его коммуникацией через сокеты, тебе придется разработать и реализовать свой протокол

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

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

По существу ответов не будет? Ну и замечательно

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

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

Какой ты забавный. Прямо как детсадовец, честное слово

hateWin ★☆
() автор топика
Ответ на: комментарий от gns

но вот этот d-spy только флатпаком ставится?

Прямо сейчас поставил как обычный RPM пакет прямо из репы федоры 41

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

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

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

Как, собственно, и varlink. Такое же бесполезное. Протокол. Протокол. А как узнать, что протокол выбран правильно, не предоставляя by design возможности разным протоколам сосуществовать поверх одной системы. И конкурировать. Это же абсурд.

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

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

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

Есть какой-то bustle, чот, даже, показывает. И в формат pcup умеет сообщения паковать.

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

Родился на улице Герцена, в гастрономе номер 22. Известный экономист, по призванию своему библиотекарь, в народе колхозник, в магазине продавец. В экономике, так сказать, необходим…

hateWin ★☆
() автор топика

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

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

А можно было свои задачи решать. Время, как и лоб, казенные, вестимо.

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

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

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

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

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

hateWin ★☆
() автор топика
Ответ на: комментарий от thegoldone

Т.е. если перефразировать

Всё так. Поэтому классический init выкинули и заменили на systemd.

Это application level. Способ связи свой протокол навязывать не должен. Просто предоставлять двунаправленное соединение как файл. Приложения уже между собой договариваться какой там протокол и прочее.

Для двунаправленного соединения уже есть пайпы и сокеты. Проблема, которую решает dbus, как раз и состоит в том, что приложениям нужен, сюрприз, стандартный универсальный application level. Приложеня не должны изобретать свой уникальный протокол каждый чертов раз. В ином случе, если приложения хотят пообщаться друг с другом, то в каждом для каждого должна присутствовать реализация его уникального протокола. Это бред и абсурд.

Да это всё не имеет отношения к способу связи.

Никого не интересует способ связи локальных приложений. Им нужен именно прикладной протокол, условный RPC, который не надо будет многократно переизобретать. Стандартный и универсальный. Чтобы все приложения могли опрашиваться одной библиотекой или CLI-утилитой, и коммуницировать между собой стандартным же образом.

А этому неплохо способствует т.н. the UNIX way. Когда одно приложение (система) не впитывает в себя всё вокруг.

DBus вполне себе юниксвей: это шина передачи сообщений.

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

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

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

А как узнать, что протокол выбран правильно, не предоставляя by design возможности разным протоколам сосуществовать поверх одной системы. И конкурировать. Это же абсурд.

У каждой технологии есть своя область применения. Думай о DBus, как об RPC. Тебе не нужно знать, как оно внутри там устроено. Вот тебе API, вот область применения, вот библиотека - всё. Не строй велосипед без необходимости.

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

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

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

Щито?

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

Всё так. Поэтому классический init выкинули и заменили на systemd.

Не поэтому. У шапки были планы завертеть весь линукс вокруг себя, поэтому и начали всё перекраивать.

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

У шапки были планы завертеть весь линукс вокруг себя

А планов пустить всех христианских младенцев на мацу у них нет?

hateWin ★☆
() автор топика
Ответ на: комментарий от frost_ii

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

Мак и винда не решают мои задачи даже близко, а линукс решает.

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

Логика уровня «помидор красный, потому что у трактора дверь открывается вот так».

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

Рассказать тебе историю про фанбойство? Щас расскажу. Я последние 18 лет сижу на синкпадах с линуксом. За это время синкпады скурвились, и я решил перейти на что-то более вменяемое. Мак, разумеется, отпал, по причине неюзабельной клавиатуры, неудобного набора разъемов и оси, которую все равно надо было бы менять на линукс. Остановился на Framework 16, как на модульном поддерживаемом решении. Оказалось, что у него 2k-экран, на котором не работает моя древняя тема QtCurve, поэтому я попросил одного товарища сделать ее порт на Kvantum, чтобы не менять привычек. А еще мне инженерят новую верхнюю деку и крышку для фреймворка, которые будут изготовлены на заводе, чтобы вместо штатной низкопрофильной чиклетной клавы без home/ins/pgup/etc вставить полноценную клаву от леновы с кнопками над тачпадом, потому что мне так удобнее.

Ценник железа и всего этого действа сопоставим с макбучным. На ноуте, разумеется, линукс с systemd. Арч, by the way. Потому что мне надо работу работать, а не бороться маком и виндой, которые довести до юзабельного состояния сложнее, чем заказать кастомное железо.

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

Не поэтому. У шапки были планы завертеть весь линукс вокруг себя, поэтому и начали всё перекраивать.

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

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

Щас расскажу.

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

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

а линукс решает

Всё, что работает под линукс, работает везде, ибо опенсурс.

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

Потому что бапки кончились и наработки пришлось отправить в топку, а их было в количестве.

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

Это нормальный итеративный подход.

Если бы в инете применяли этот «нормальный итеративный подход», у нас бы уже штук 5 несовместимых аналогов HTTP было.

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

Всё так. Поэтому классический init выкинули и заменили на systemd.

Так же как и выкинут systemd.

Для двунаправленного соединения уже есть пайпы и сокеты.

Это не то же самое, очевидно. Вы никак не узнаете где тот самый сокет и тот самый FIFO.

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

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

Не касаясь темы протокола dbus, оставляющего желать лучшего (= ограниченный устаревший костыль).

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

Никого не интересует способ связи локальных приложений. Им нужен именно прикладной протокол, условный RPC, который не надо будет многократно переизобретать. Стандартный и универсальный. Чтобы все приложения могли опрашиваться одной библиотекой или CLI-утилитой, и коммуницировать между собой стандартным же образом.

Вы уже вошли в противоречие с собой. Если это одна библиотека. И одна утилита. То протокол не имеет значения. Потому что он скрыт за ними. И остаётся только набор функций, которые предоставляет библиотека. Значит Ваши рассуждения о протоколе теряются. Быстро же.

Это не RPC. RPC подразумевает клиент-серверную модель. Что не применимо к приложениям. Взаимодействие которых больше похоже на взаимодействие потоков в рамке процесса. Где нужны блокировки, ожидания, контроль над разделяемыми ресурсами. Передача данных по цепочке (конвейеру).

DBus вполне себе юниксвей: это шина передачи сообщений.

Нет.

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

Дубас и есть велосипед. Непонятно зачем его изобрели.

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

У каждой технологии есть своя область применения. Думай о DBus, как об RPC. Тебе не нужно знать, как оно внутри там устроено. Вот тебе API, вот область применения, вот библиотека - всё. Не строй велосипед без необходимости.

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

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

Мне плевать на другие приложения. У меня есть свой набор приложений. Если кому-то что-то нужно – пусть и напрягается. Какое мне до этого дело.

Ещё раз – dbus и есть велосипед. Протоколов масса. И один лучше другого. Нет нужды что-то изобретать вообще. Правда какие-то умники взялись пилить что-то своё и родили dbus. Напишите им письмо про велосипед. Меня поставьте в копию.

Щито?

Наличие бесконечного множества способов взаимодействия между точками А и Б не ограниченных Дубасом.

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

Но как только немного осваивались в айтишечке и появлялись деньги на что-то более продвинутое - испарялись.

То-то Asahi Linux процветает за счет донатов, ага.

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

Моя история - итог того, что я разрабатываю под линукс, и тестирую на нем же. Мне нужен докер, нормальный CLI, qemu-arm-static, binfmt и прочее, что я мог бы сделать на винде и маке с безумными танцами с бубном, но проще сделать в линуксе. Линукс поставил, настроил - и он работает. А если в проприетарных осях ты хочешь что-то нестандартное, то тебя ждет боль и отсуствие ответа от индуса в официальном сапорте.

Потому что бапки кончились и наработки пришлось отправить в топку, а их было в количестве.

Просто systemd решало проблемы убунты в том числе, вот и перешли на него. Теперь в линуксе есть стандартный системный менеджер. Здорово же?

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

Охренеть, конечно. Ты хорош. Так заморочиться, респект.

Решения по типу этого Framework это хорошо, не даёт индустрии окончательно скатиться в производство залитых клеем кусков кала в китайских подвалах.

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

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

Сейчас вот попытка вкорячить Snap вместо Флатпака, ждём аналогичного финала?

Понятно, что RH несопоставимо крупнее, но… Видимо, в консерватории что-то не так с процессом принятия стратегических решений.

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

Посмотрел, я на этот их https://varlink.org/

Да неужели кто-то наконец-то сделал как надо, а не «хотели как лучше»?

Как по мне, это убервафля покруче, чем сам systemd.

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

То-то Asahi Linux процветает за счет донатов, ага.

Чё, как некрософт и эпол? А нет, просто очередной маргинальный болгенос, расходимся. Короч, не ладится что-то с баблишком.

Моя история

С допилом ноута. Да, самая расхожая. Каждый день наблюдаю толпы людей с кастомными ноутами.

Просто systemd решало..

А также гном, вяленый и далее причём одновременно.

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

Так же как и выкинут systemd.

Вполне может быть. Pulseaudio был так же выкинут и заменен на Pipewire в свое время. Он сделал главное: проложил дорожку и создал API. А еще навел порядок в авгиевых конюшнях аудоидрайверов, потому что Леннарт требовал исправлять говно и чинить совместимость до соответствия стандартам, а не поддерживать бесконечные костыли. Было больно, но зато теперь у нас есть идеально работающая зовуковая подсистема. Я купил блютузовые наушники и они у меня просто заработали без необходимости устраивать извращенные скрещивания альсы и bluez и пляски вокруг asoundrc.

Это не то же самое, очевидно. Вы никак не узнаете где тот самый сокет и тот самый FIFO.

Абсолютно то же самое. Стандартизируй положения положения объектов в FHS, и всё.

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

Ты сам себе противоречишь. Еще раз: DBus - это RPC, хотя ты с этим и не согласен. Systemd требовался RPC, они его и использовали. Эти факты противоречат твоим дальнейшим умозаключениям, делая их ложными.

Не касаясь темы протокола dbus, оставляющего желать лучшего (= ограниченный устаревший костыль).

Поэтому его и меняют.

Вы уже вошли в противоречие с собой. Если это одна библиотека. И одна утилита. То протокол не имеет значения. Потому что он скрыт за ними. И остаётся только набор функций, которые предоставляет библиотека. Значит Ваши рассуждения о протоколе теряются. Быстро же.

Это не у меня противоречие, это ты не понимаешь, о чем рассуждаешь ;) Еще раз:

  • Приложениям нужен RPC для коммуникации между собой.
  • Библиотека реализует некий протокол внутри себя и предоставляет API для приложений.

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

Это не RPC. RPC подразумевает клиент-серверную модель. Что не применимо к приложениям.

Это именно RPC. Приложение, выполняющее запрос, является сервером.

Нет.

Да. Это юниксвей, нравится тебе это или нет.

Дубас и есть велосипед. Непонятно зачем его изобрели.

Попробуй внимательно перечитать мои предыдущие рассуждения, я всё объяснил. DBus нужен был, как универсальное средство RPC и обмена сообщениями. Что тут непонятного?

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

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

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

Чё, как некрософт и эпол? А нет, просто очередной маргинальный болгенос, расходимся. Короч, не ладится что-то с баблишком.

Too big to fail тебе знакомо, нет?

С допилом ноута. Да, самая расхожая. Каждый день наблюдаю толпы людей с кастомными ноутами.

Это просто показывает, что твои рассуждения о переходах на мак и винду несостоятельны. Даже если нет кастомных ноутов, люди будут предпочитать то, что им удобно. И это вполне может быть линукс.

А также гном, вяленый и далее причём одновременно.

С гномом всё понятно. Вяленый у меня отлично работает.

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

просто очередной маргинальный болгенос,

С полностью своим отревершенным граф. стеком (т.е. без документации со стороны Apple) с реализацией Conformant OpenGL 4.6 и Vulkan 1.4, что недоступно в родной macOS.

болгенос, ага.

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

Too big to fail

В переводе - про бузину и дядьку.

Это просто показывает,

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

С гномом всё понятно

что ничего не понято. угу

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

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

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

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

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

Например правка конфигов - с подачи RH у нас появились каталоги конфиг.d почти для всех системных компонентов, а не один файлик, который надо было редактировать седом. А еще у нас есть оверрайды системных дефолтов, для которых достаточно просто файлик положить. Список можно продолжать бесконечно. Я прям вижу, откуда ноги растут, и благодаря этому администрирование и деплой сильно упростились.

liksys ★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.