Релиз systemd 257

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

Что до systemd - он был сделан для решения корпоративных клиентов. Так что твои претензии к нему с точки зрения «кококо фанбои systemd уходят на маки» - сами по себе абсурдны.

сотни килобаксов

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

был сделан для решения корпоративных клиентов

Решение - среда красношапочная, включающая и сам дистр и сервис и курсы и прочее. Сделано - для зарабатывания денег, а не для клиентов, причём максимально таким образом, чтобы поляна не заселялась конкурентами.

Это бизнес, а не мессианство

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

У тебя такое милое отрицание, я не могу. Когда я смотрел последний раз (пару лет назад), они собирали что-то типа 30 килобаксов в месяц. Полагаю, сейчас сумма сильно выросла.

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

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

Конспирун-конспирунушка.

они собирали что-то типа 30 килобаксов в месяц.

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

А остальные дистры это приняли потому что

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

Решение - среда красношапочная, включающая и сам дистр и сервис и курсы и прочее. Сделано - для зарабатывания денег, а не для клиентов, причём максимально таким образом, чтобы поляна не заселялась конкурентами.

Это бизнес, а не мессианство

То ли дело Эппл, который делает вещи для клиентов по доброте душевной, а вовсе не для денег… или нет.

А можно объяснение для ежиков: в чем его преимущества перед дбасом? Ну, кроме того, что он плейнтекстовый и не нуждается в централизованном демоне (строго говоря, libdbus позволяет реализовать соединение между двумя процессами без сервера).

уродливом языке с отсутствующей типизацией

На C?

На баше.

C тоже подходит.

Не подходит.

Так я про то и вещаю, что эпол, что шапка, что негрософт, что Гугель. Всё это бизнеса ради бабла, альтруизмом там и не пахло.

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

Там любой тип через void* ломается. То есть типизация там на бумаге.

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

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

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

// Ой
#ifdef ОЧЕПЯТКА

Поэтому надо молиться на тех, у кого окучивалка побольше? Или какая тут логика?

Господин капиталист мне не сват, не брат, не товарищ.

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

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

Очень интересно.

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

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

DBus - это RPC, хотя ты с этим и не согласен

А я и не утверждал, что Дубас – не RPC. Взаимодействие между приложениями – не RPC.

Теперь по существу.

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

При этом способ связи между процессами не установлен. Это может быть сокет. Может быть pipe. Что угодно. И этим занимается гипотетическая утилита nonshitlikeunixwaydbus или гипотетическая библиотека libnonshitlikeunixwaydbus. Они предоставляют двум процессам способ связи. Универсальный. Для процесса это просто fd. Однозначно указывающий на нужный процесс с другой стороны.

При этом никакого протокола не предоставляется вообще. Только связываются два приложения и всё. И это UNIX way. Потому что добавлять что-то сверху этого – уже не UNIX way.

Надеюсь с этим понятно.

Какой там будет протокол – это второй вопрос. И он может быть каким угодно. Никак не ограничиваться. В том числе, не запрещается использовать какой-то один протокол в общем случае. Например для скриптов можно предоставлять протокол Scriptota IPC Protocol 2.0. И для приложений рабочего стола. И для чего угодно.

Даже не запрещается одновременно связать эти два аспекта в одной библиотеке libscriptotaipc20overnonshitlikedbus. И предоставить консольную утилиту scriptotaipc20overnonshitlikedbus.

А ещё, само приложение может предоставлять клиентскую библиотеку.

Вот и всё. Тут нечего обсуждать.

И именно поэтому, dbus – никуда не годится. И именно поэтому, varlink – никуда не годится.

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

Нужно ли говорить, что fd даёт всё что нужно для синхронизации процессов.

Так это и не переменная. Макросы нужно минимизировать.

Си для 24 года очень сильно устарел и тащит за собой ворох неустранимых ошибок дизайна. Он такое же старье, как и sh. Всё это со временем отправится на помойку даже не смотря на существующие кодовые базы.

Не зря на Раст бросились переходить с энтузиазмом еще большим, чем когда меняли sysvinit на systemd.

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

Кстати, офтопик, но как вообще утилиты типа systemctl общаются с systemd? Как systemd понимает, что к нему обращается пользователь с правильными правами?

Очень интересно.

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

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

Вот и размышляй, это же тебе надо что-то маргинальное вместо нормальной шины сообщений.

А я и не утверждал, что Дубас – не RPC. Взаимодействие между приложениями – не RPC.

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

При этом никакого протокола не предоставляется вообще. Только связываются два приложения и всё. И это UNIX way. Потому что добавлять что-то сверху этого – уже не UNIX way.

Мне вот интересно, откуда вы лезете, фанбои юниксвея? Вы же вообще не понимаете, что такое юниксвей, но мнение имеете.

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

Надеюсь с этим понятно.

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

Ты понимаешь вообще, что твои рассуждения вообще относятся к уровням абстракции в духе модели OSI, а не к юниксвею?

Какой там будет протокол – это второй вопрос. И он может быть каким угодно. Никак не ограничиваться. В том числе, не запрещается использовать какой-то один протокол в общем случае. Например для скриптов можно предоставлять протокол Scriptota IPC Protocol 2.0. И для приложений рабочего стола. И для чего угодно.

Чтобы что? Какую задачу это решает? Задачу «dbus-ущемляет-мои-права»? Подавляющее большинство межпроцессного взаимодействия в рамках десктопа укладывается в DBus. Нет никакого смысла городить огород несовместимых протоколов, если всё решается одним.

И именно поэтому, dbus – никуда не годится. И именно поэтому, varlink – никуда не годится.

Ты пока не привел ни одного убедительного довода в отношение своего «поэтому».

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

Используй. Только не надо выдавать свою маргинальную точку зрения за истину в последней инстанции. DBus и varlink решают проблемы разработчиков тырпрайзного и десктопного софта. От тебя я вижу только крики «нинужно».

Вот и всё. Тут нечего обсуждать.

Да, но ты почему-то продолжаешь обсуждать.

Си для 24 года очень сильно устарел и тащит за собой ворох неустранимых ошибок дизайна.

Я бы не называл это ошибками дизайна. Си - это синтаксический сахар для ассемблера со всеми вытекающими. Он такой именно из-за близости к железу.

Всё это со временем отправится на помойку даже не смотря на существующие кодовые базы.

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

Не зря на Раст бросились переходить с энтузиазмом еще большим, чем когда меняли sysvinit на systemd.

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

И systemd, и rust - оверинженернутые решения, которые тащат кучу сложности с собой.

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

По DBus. У него есть механизм проверки прав доступа и что-то типа ACL.

Вот и размышляй, это же тебе надо что-то маргинальное вместо нормальной шины сообщений.

Вам, как скриптовику, может и так казаться. Я не против.

И это неправильный ответ.

Если Вы не поняли, Вы просто солгали. Приписали свои слова мне, и опровергли их. Так и быть, донесу до Вас это в прямом виде. Вы – лжец. Зачем Вы лгали – не понятно. Видимо в надежде, что никто ничего не заметит. И что, работает? А Вас самих это устраивает?

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

Для Вас только RPC.

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

Это не так.

Чтобы что? Какую задачу это решает? Задачу «dbus-ущемляет-мои-права»? Подавляющее большинство межпроцессного взаимодействия в рамках десктопа укладывается в DBus. Нет никакого смысла городить огород несовместимых протоколов, если всё решается одним.

Несовместимых с Вашим представлением о прекрасном?

Ты пока не привел ни одного убедительного довода в отношение своего «поэтому».

Убедительного для Вас. Но это не проблема.

Используй. Только не надо выдавать свою маргинальную точку зрения за истину в последней инстанции. DBus и varlink решают проблемы разработчиков тырпрайзного и десктопного софта. От тебя я вижу только крики «нинужно».

Они не решают проблемы.

У него - это у демона dbus от systemd? А демон dbus - это тот же процесс (pid 1), который всё делает? Или другой?

И какой механизм проверки - демон понимает, какой pid к нему коннектится, определяет euid этого процесса и т.д?

Вам, как скриптовику, может и так казаться. Я не против.

А с чего это ты решил, что я скриптовик?

Если Вы не поняли, Вы просто солгали. Приписали свои слова мне, и опровергли их.

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

Для Вас только RPC.

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

Это не так.

Аргументы-то будут?

Несовместимых с Вашим представлением о прекрасном?

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

Они не решают проблемы.

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

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

Я не интересовался деталями реализации. Бегло нагуглилось вот что: https://unix.stackexchange.com/questions/194308/d-bus-authentication-and-authorization

Всё говно в итоге

В эту схему не вписывается моча!

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

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

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

N+1 стандарт, ага. У кого-то конкретно них чесался…

Про DBus тоже так говорили. Тем не менее, кто-то помнит DCOP?

Сложность разная бывает. Та, что обусловлена сложностью задачи, и та, что обусловлена дизайном инструмента. При чем вторую можно далее классифицировать, скажем, на ту, что относится к 1) недостаточной мощности инструмента; 2) сбойности/ненадёжности инструмента; 3) избыточному набору абстракций/крутилок/свистелок инструмента и так далее.

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

Не вполне. DBus это:

• Механизм обмена структурированными сообщениями.
• Пространство имён.
• Маршутизатор сообщений.
• Средство запуска сервисов по требованию.
• Система проверки прав доступа.

И до кучи, в своём практическом использовании прибит к очень странным практикам. Например, не просто не учитывает сетевую природу понятия «сеанс пользователя», а целенаправленно от этого отказался. Хотя штуке, которая дизайнилась работать через сокет, вроде как базово по смыслу положено быть сетевой.

Именно поэтому приходится итеративно изобретать велосипед.

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

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

Это не всегда хорошо. Для реализации абстракции RPC это скорее даже минус.

Я бы varlink рассматривал как следующую ступень эволюции концепции потоков данных, которая в UNIX была основным средством связывания приложений. Когда простого текстового потока данных недостаточно, на сцену приходит структурированный формат с самодокументированным API.

Это как таковая не замена шине сообщений, хотя шина сообщений может быть поверх этого построена.

UPD.: По сути происходит поэтапное внедрение концепций Plan 9.

Про DBus тоже так говорили. Тем не менее, кто-то помнит DCOP?

DCOP предназначался для RPC в рамках сеанса, и в рамках сеанса был на своём месте, потому что под сеансом подразумевался графический сеанс X11.

Использование DBus в этом качестве сломало абстракции. Теперь при логине происходит какой-то беспредел. У нас есть:

• Классические сеансы UNIX.
• Графические сеансы, которые могут быть сетевыми.
• Сеансы dbus, которые прибиты к локалхосту.
• Сейчас еще добавился механизм управления сеансами от logind.

Архитектурно здесь плохо всё.

…кто-то помнит DCOP?

Пользователи Trinity?

И, повторю, судя по описанию, varlink не заменяет d-bus. By design не заменяет.

Сложность разная бывает.

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

Не вполне. DBus это:

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

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

Никто сейчас по сети его не использует. Я помню момент повсеместного внедрения dbus, и как-то с сетью у него не сложилось. Нет - и пёс с ним, уже есть varlink.

Проблема была вполне чётко видимая, просто проектировщики были не впечатляющи.

С высоты 14 лет это легко утверждать. А ты попробуй задизайнить шину с учетом будущих требований, а потом протолкнуть ее всем дистрам, DE и сопутствующим проектам. Вон, клоуну выше до сих пор неочевидно, зачем нужен стандартный RPC и протокол сообщений.

Использование DBus в этом качестве сломало абстракции. Теперь при логине происходит какой-то беспредел.

Для ОС была необходима общесистемная шина, поэтому сделали DBus.

Классические сеансы UNIX.

systemd_pam делает всякое нужное.

Графические сеансы, которые могут быть сетевыми.

Уже не могут. Сетевая прозрачность в иксах давным-давно мертва, иксы в процессе закапывания. В вяленом она не реализована (хотя ничего не мешает), но объективно это никому не нужно, потому что все пользуют VNC-подобные инструменты для доступа к десктопу целиком.

Пользователи Trinity?

Ну камон)))

И, повторю, судя по описанию, varlink не заменяет d-bus. By design не заменяет.

https://github.com/varlink/varlink.github.io/issues/7

Если быть точным, это не инплейс-замена, но технически может использоваться в большинстве случаев вместо dbus.

Уже не могут. Сетевая прозрачность в иксах давным-давно мертва, иксы в процессе закапывания. В вяленом она не реализована (хотя ничего не мешает), но объективно это никому не нужно, потому что все пользуют VNC-подобные инструменты для доступа к десктопу целиком.

А VNC это не сетевое подключение?

А дальше если выйти за рамки GUI, ssh это не сетевое подключение?

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

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

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

Никто сейчас по сети его не использует. Я помню момент повсеместного внедрения dbus, и как-то с сетью у него не сложилось. Нет - и пёс с ним, уже есть varlink.

Не сложилось, потому что изначально было сделано через жопу. Технология это не только код и описание API, это еще и практики, на которые проектировщики закладывались в решении, и донесение видения этих практик до пользователя продукта. Я глубоко еще не вникал, но пока что varlink выглядит как dbus здорового человека. Посмотрим, как дальше пойдёт.

А VNC это не сетевое подключение?

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

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

Ты всё свалил в одну кучу. Смотри предыдущий абзац.

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

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

зачем делать архитектуру, отражающую реалии современности, если в каждом приложении можно навелосипедить свой отдельный удалённый доступ

Я этого вообще не говорил. Мне кажется, ты просто не так понял ситуацию. У нас есть несколько видов удаленного доступа на уровне ОС:

• Доступ к десктопу - делается через VNC/RDP/Teamviewer-like, для которых принципиально ничего не нужно.
• Доступ к сессии (как у терминального сервера) - используется и требует всяких плясок для передачи по сети, потому что помимо картинки надо прокидывать еще и звук. Сложно это всё и в общем случае не решается (по крайней мере раньше, сейчас не знаю).
• Доступ на уровне приложения с гуем - умер вместе с иксами.
• Доступ на уровне API приложения (как transmission).

Из перечисленного только второе и четвертое требует каких-то шин или их подобий для RPC. DBus оказался неюзабелен здесь, и varlink должен решать эту задачу.

Не сложилось, потому что изначально было сделано через жопу.

Оно так было сделано, потому что хотели как лучше, а получилось как всегда. Не сделаешь ты нормальную универсальную шину для ОС, не нагородив огорода. Этот шаг был необходим, чтобы в итоге сделать varlink.

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

Гм. Я в данный момент набираю текст в приложении https://www.linux.org.ru/. Ты уверен, что оно умерло?

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

Прокидывать требуется не конкретно «звук», а любое ресурс, который может присутствовать на другой стороне. Ресурсом может быть что угодно. При чём в обе стороны. Звуковой поток - ресурс, файл с котиками - ресурс, плоттер - ресурс, вставленная флешка - ресурс, LLM, запущенная на GPU - ресурс.

Иначе это доступ без доступа. Доступ есть, но доступа нет.

Оно так было сделано, потому что хотели как лучше, а получилось как всегда. Не сделаешь ты нормальную универсальную шину для ОС, не нагородив огорода. Этот шаг был необходим, чтобы в итоге сделать varlink.

Plan 9 придумали в 80-х.

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

А с чего это ты решил, что я скриптовик?

Это понятно.

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

Вы выдали свои слова за мои. Солгали.

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

Ну это Ваша ограниченность. Приложений она не касается.

Аргументы-то будут?

Подвезите свои сперва.

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

Не имеют значения потребности большинства приложений.

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

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

Вы просто изнутри скрипта пытаетесь на мир смотреть.

Этот символ называется «солнышко», тьфу на вас.

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

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

Если быть точным, это не инплейс-замена, но технически может использоваться в большинстве случаев вместо dbus.

Вы только что подтвердили сказанное мной: varlink не является мессейдж-брокером, цитата: «varlink — это REST без HTTP». «Тимуровцы добывают кумыс Миллениалы изобретают легковесный IPC». Взаимодействие через мессейдж-брокер — это, прежде всего, другой способ организации клиентских приложений.

Ну и да, the last but not least. Кей Сиверс — известный, хе-хе, гражданин. Помниццо, я с ним ещё по HAL-у пересекался, во времена, когда вкрячивал udev в Альте. А было это уже почти 20 лет назад, судя по переписке. Так что, я бы не торопился объявлять varlink единственной дорогой к светлому будущему. Сколько их уже было, закончившихся в непонятных дебрях…

Уже не могут. Сетевая прозрачность в иксах давным-давно мертва

Посмотрел с интересом. Достал ноутбук, залогинился по SSH на рабочую машину, запустил с неё ark и kate, удовлетворенно увидел отобразившиеся на ноуте окошки, закрыл. Кажется, кто-то … ошибается.

Да, кстати, на обеих машинах — сеансы вейлэнда (хотя через SSH отображается, конечно, через xcb, так что $DISPLAY обязателен). Plasma-6.2.

Но если он вдруг сделал что-то полезное…

Он и не пытается причинить добро, он создаёт воронку продаж (оф термин, ежеличо). СустымДы нужна для воронки, причём направленной на корпоратов, а не для пользы конечного юзверя. Шапка не заинтересована в линуксе, она заинтересована в РедХатОс. Не будь СустымДы шапке просто нечем было бы торговать, разве что сборками Zver и васянскими курсами, коих и без того немало. Было бы у шапки ресурсов больше, появился бы типа Ios из BSD.

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

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

И systemd, и rust - оверинженернутые решения, которые тащат кучу сложности с собой

В переводе на русский - говнопродукт из копроэкономики. Ну да, инженерный уровень сейчас трагически упал, причём повсеместно. Даже Боинг чёрте что исполняет.

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

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

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

Но ровно эти же свойства востребованы и у енд-лузеров. «Тебе надо, чтобы программа XYZ стартовала при старте пользовательского сеанса? Напиши простой текстовый файл, скажи systemctl --user enable --now XYZ.service и дальше оно будет у тебя стартовать при старте сеанса». Да, спасибо, я знаю ещё как минимум 4 способа это сделать. Исходно эти способы выглядят проще, чем user-defined-service, — чо там, одна строчка в .bashrc или .xinitrc! — но суммарно оказываются гораздо ненадёжней и запутанней, хотя бы потому, что в наше непростое время у пользователя может не оказаться ни bash, ни X11.