Почему все критикуют dbus?

Потому-что проприетарщина мелкомягкая. Есть же православное sysvipc.

Есть ряд вещей, критикуя которые, вы можете сойти за интеллектуальную илиту и Ъ-юникс-ветерана: dbus, systemd, wayland, btrfs, ...

проприетарщина мелкомягкая
Developer(s) Red Hat
License GNU GPL version 2

Шта?

Почему «все»? Вот тебе же оно нравится. Столько фич, ух!

Почему «все»?

Ну не все, но в каждой тебе про dbus стабильно.

Вот тебе же оно нравится

Не пользовался, поэтому не знаю нужны ли все эти фичи для IPC. А вот для IoT, в реинкарнации Alljoyn, очень даже хорошо подходит, как мне кажется. Сам подобное собирался пилить пока не наткнулся на готовое

То-есть, не сам протокол плох, а его «пропихивание» на фоне уже существующих проверенных технологий IPC?

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

У кде вроде как появился свой, параллельный сервис.

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

Смотри поиск достоинства, недостатки, альтернативы dbus

This.

Не пользовался, поэтому не знаю

Окей.

для IoT, в реинкарнации Alljoyn, очень даже хорошо подходит, как мне кажется.

IoT? Ты предлагаешь DBus в качестве сетевого протокола?

Ты предлагаешь DBus в качестве сетевого протокола?

Уже сделали. Расширили до сетевого

У кде вроде как появился свой, параллельный сервис

Гугл вспомнил только про DCOP, который опочил вместе с KDE3 )

Ты предлагаешь DBus в качестве сетевого протокола?

Уже сделали

«A remote accessible AllJoyn network is a proximal IoE network where services provided by devices are accessible and/or controllable from outside the proximal IoE network. The remote accessibility is achieved by having a Gateway node in the system. The Gateway node exposes device functionality and control to an existing cloud-based service either via standard Internet style APIs (e.g. REST)»

Где там DBus?

Ну гномам всяким он нужен. А людям не нужен, без DE от всяких dbus никакой пользы.

памамушта дубас - боль :)

If you use this low-level API directly, you're signing up for some pain.

Хреново, когда документация по библиотеке настоятельно советует не пользоваться этой библиотекой )

The AllJoyn system and D-bus specification

The AllJoyn system implements a largely compatible version of the D-Bus over-the-wire protocol and conforms to many of the naming conventions and guidelines in the D-Bus specification. The AllJoyn system has extended and significantly enhanced D-Bus message bus to support a distributed bus scenario. The AllJoyn system makes use of the D-Bus specification as follows:

- It uses the D-Bus data type system and D-Bus marshaling format.

- It implements an enhanced version of the D-Bus over-the-wire protocol by adding new flags and headers (detailed in Message format).

- It uses D-Bus naming guidelines for naming well-known names (Service names), interface names, interface member names (methods, signals and properties) and object path names.

- It uses a D-Bus defined Simple Authentication and Security Layer (SASL) framework for application layer authentication between AllJoyn-enabled applications. It supports authentication mechanisms beyond what are defines by the D-Bus specification.

The AllJoyn system implements a largely compatible version of the D-Bus over-the-wire protocol. The AllJoyn system has extended and significantly enhanced D-Bus message bus to support a distributed bus scenario.

It supports authentication mechanisms beyond what are defines by the D-Bus specification.

Ну то есть это даже формально не D-Bus.

В завершение - D-Bus говно, потому что смешала абстракции в кучу. Как будто группе троечников из ПТУ позволили спректировать облегченную версию CORBA.

даже формально не D-Bus

Формально нет. Dbus же не умеет во всякую децентрализацию.

смешала абстракции в кучу

А можно подробнее?

dbus, systemd, wayland, btrfs, ...

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

То есть вы так кудахчете на перечисленный софт потому, что иначе все считают что у вас есть бойфренд?

или, еще хуже, макбук)

Чем сетевой D-Bus лучше MQTT?

awesome WM требует D-Bus для реализации всяких мелочей типа отображения текущей песни на таскбаре. Если делать без D-Bus, то может подвиснуть весь UI в том случае, если скрипт не сможет прочитать stdout плеера или файл.

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

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

я тоже сначала взял mqtt протокол. Но он крайне ограничен. Хорошо подходит только для простых сенсоров без обратной связи:

- Содержимое сообщений никак не регламентированно. Тупо бинарный блоб. Сам пиши слой разбора сообщений (а другой умелец напишет свой формат)

- Только один паттерн (pub/sub). Сам пиши поверх этого rpc и проч.

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

не все

очень крутую штуку с RMI, сериализацией, броадкастингом, и интроспекцией

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

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

echo 'string:"HelloWorld' > /tmp/dbus/system/org/example/interface/method1 

выглядит гораздо лучше чем вот это извращённое и маразматичное

dbus-send --system --dest org.example /org/example/interface org.example.interface.method1 string:"Hello World"

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

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

/tmp/dbus/system/org/example/interface/method1

Тогда уж лучше пихать в /run/dbus/system/...

Если делать без D-Bus, то может подвиснуть весь UI в том случае, если скрипт не сможет прочитать stdout плеера или файл.

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

Что то почитал я всё это и понял. Ни черта ни кто D-Bus не знает и не понимает.:-))))

Так просвяти нас )

Ты же все прочитал по нему. И на wiki был. Еще рекомендую https://www.freedesktop.org/wiki/Software/dbus/ почитать. А здесь обучать - все равно что телевизор по телефону ремонтировать.

смешала абстракции в кучу

А можно подробнее?

Сетевые форматы и «RMI, броадкастинг и интроспекция» в одном флаконе. При этом сетевой IPC на этой фигне не построишь (см. выше), и получается ни богу свечка, ни черту кочерга.

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

Мудрость, конечно: http://gentooexperimental.org/~patrick/weblog/archives/2014-11.html#e2014-11-...

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

Потому что RPC->(D)COM->CORBA вид сбоку, СБИШ, и мода на них вместе с причитающимся бай дизайн геморроем немношк прошла, все ушли сначала на «дружелюбные кококо текстовые протоколы» WSDL(SOAP/XML), которые были неплохо задуманы, но... реализованы как всегда, — комитетом, и человека, который это возьмется читать, ждет добрый доктор и мягкие стеныничто уже не сломает, что не мешает гуглопионерам изобретать «протокол бафферс», которые... «еще один RPC» и какбэ чуть более быстрее чуть более дружелюбного (чем SOAP/XML) RESTа, но... лишь по той причине, что наглухо бинарные и... таки переизобретают некогда отвергнутые WSDLREST-хипсторами бинарные RPC (аффтар статьи по ссылке — один из «неизвестных аццов» CORBA, в том числе попячивает популярные мифы про RPC) На оффтопике происходили параллельно аналогичные метания (первоначально с ребрендингом OLE/COM/COM+/ActiveX/DCOM, завертыванием всей этой каши в «ActiveSTL»/ATL/Windows DNA потом с разрывом шаблона и сменой парадигмы: «кто сказал Java?» .Net-remoting/WCF/WCF-RESTful. Поэтому которые ругают dbus — редко знают за что :)

Сетевые форматы и «RMI, броадкастинг и интроспекция» в одном флаконе

Совершенно правильно, что в одном флаконе. Это тот минимум технологий, на которых можно построить нормальное общение. А то, вон, сделали websockets, двустороннюю трубу без души и толку ноль. Все через http общаются, потомучто какой-никакой стандарт: запрос-ответ, заголовки, коды ошибок и проч.

При этом сетевой IPC на этой фигне не построишь

Я не в курсе, но гугль выдал:

It Works!!!
Since the version 1.4.1 it is possible to set the
<alow_anonymous/> 
tag in the d-bus daemon configuration file.
The file shall contain e.g. following listen tag
<listen>tcp:host=192.168.0.1,port=12345</listen>
A D-Bus daemon shall be started on the according host, using this configuration file.
Than it is possible to open the QDBusConnection over the network. D-Bus works as an ORB !!!

QDBusConnection::connectToBus(«tcp:host=192.168.0. 1,port=12345»,«myConnection»);

Сетевые форматы и «RMI, броадкастинг и интроспекция» в одном флаконе

Совершенно правильно, что в одном флаконе.

А. Ну, значит, ты из тех, кому это нравится. В этом нет ничего постыдного.

При этом сетевой IPC на этой фигне не построишь

Я не в курсе

Не в курсе, обладает ли DBus через TCP всеми возможностями DBus, или является подмножеством? Окей.

Ты им пользоваться пробовал? А posix message queue? Они же дубовые абсолютно и бесполезные практически полностью.

я ничего не понял)

А soap, что, уже всё?

Зато не вендовненько.

Тогда только fifo пайпы только хардкор. А ещё лучше shm взять.

Мне нравится.

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

А вот тут в топике ещё ни одного технического замечания не вижу. А они есть: 4 года назад тут человек заглянул в код... и ужаснулся: нужна помощь в переписывании dbus.

И, наверняка, в анонсе kdbus есть техническая критика неисправимых проблем с dbus (т.е. by design, как это принято у микрософта). Кажись, что-то типа когда один из клиентов отключается, то сообщение от другого может успешно уйти, но так и не прийти. А должно быть атомарно: или сообщение доставлено, или нет.

В целом же вроде kdbus так ни к чему и не привел, да и Торвальдс ругался, что пусть они юзерспейс чинят, а не в ядро лезут со своими ipc. Но как я помню некую базу в виде memfd, на которой можно в юзерспейсе эффективный ipc написать, они таки влили в ядро.

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

Конечно, в пользу реста. Соап теперь ругают как блоатваре :)

Как будто группе троечников из ПТУ позволили спректировать облегченную версию CORBA

вроде так всё и было. неосиляторы.

Дык, завязывай читать, попробуй что-нибудь написать.