Дэвид Герман (David Herrmann), в своё время разработавший шину обмена сообщениями Bus1 (https://www.opennet.dev/opennews/art.shtml?num=45382) для ядра Linux, представил (https://dvdhrm.github.io/rethinking-the-dbus-message-bus/) новый проект D-Bus Broker (https://github.com/bus1/dbus-broker/wiki), в рамках которого предпринята попытка переосмысления D-Bus и создания новой реализации, устраняющей недостатки штатного демона D-Bus (https://www.freedesktop.org/wiki/Software/dbus/). Код проекта написан на языке Си и распространяется (https://github.com/bus1/dbus-broker/) под лицензией Apache 2.0.
Мотивом создания новой реализации стала излишняя раздутость и переусложнённость dbus-daemon, в сочетании с обилием отражённых в системе отслеживания ошибок проблем - от неконтролируемого расходования памяти и пропадании сообщений, до возникновения взаимных блокировок и крахов процесса. Некоторые из проблем остаются нерешёнными до 7 лет, в большей части из-за того, что их принципиально невозможно устранить без нарушения гарантированной в dbus-daemon функциональности и существенных архитектурных изменений.В отличие от Bus1 проект D-Bus Broker реализован целиком в пространстве пользователя, остаётся полностью совместим с эталонной реализацией D-Bus и может (https://github.com/bus1/dbus-broker/wiki#using-dbus-broker) быть использован для прозрачной замены dbus-daemon. При этом новая реализация спроектирована с оглядкой на поддержку востребованной на практике функциональности и уделяет главное внимание работе по увеличению производительности и повышению надёжности. В D-Bus Broker также принципиально не реализованы функции, помеченные как устаревшие, и расширенные (https://github.com/bus1/dbus-broker/wiki/Deviations) возможности, не отражённые в спецификации D-Bus.
Ключевые архитектурные изменения в D-Bus Broker:
- Уход от идеи глобальной совместной шины (Shared Medium), к которой соединяются все обработчики сообщений и через которую осуществляется отправка сообщений. Вместо общей шины предложена концепция отдельных пиров, не имеющих глобального состояния. Когда какой-то пир отправляет сообщения, эта операция рассматривается как транзакция между отправителем и одной или несколькими точками назначения.- Отказ от использования дополнительных IPC-механизмов, так как D-Bus сам по себе является IPC и создание надстроек IPC над IPC приводит к появлению взаимных блокировок. Иными словами D-Bus Broker является самодостаточным процессом, который позволяет оперировать только локальными данными и не привязан к внешним обработчикам, таким как чтение файлов и обращение к NSS.
- Учёт ресурсов в привязке к пользователям. Каждый ресурс и переданный в шину объект привязан к конкретному пользователю. Таким образом, существенно упрощается реализации ограничений и лимиты больше не привязываются к пиру (ограничения теперь зависят от активности каждого пользователя, а не от общей нагрузки на обработчик).- Воплощение принципа, что сообщение никогда не может быть потеряно без обработки ошибки. В случае возникновения проблем недопускается возникновения неопределённых ситуаций, каждая ошибка доставки должна быть выявлена и обработана, а в случае невозможности обработки ошибки процесс должен завершить свою работу, а не просто игнорировать возникшие проблемы.
Что касается высокой производительности D-Bus Broker, то её ценой является привязка к современным окружениям Linux - для своей работы проект требует наличия ядра Linux 4.10 и glibc 2.16, и принципиально не может быть использован в старых дистрибутивах Linux или в других ОС. Предоставляются опциональные компоненты для интеграции с systemd и SELinux. Обеспечивается работа только локального IPC без поддержки сетевого взаимодействия (при необходимости проброса на другой хост предлагается пробрасывать локальный сокет через SSH).URL: https://dvdhrm.github.io/rethinking-the-dbus-message-bus/
Новость: http://www.opennet.dev/opennews/art.shtml?num=47071
Звучит шикарно.
Вот только обратная совместимость выглядит скорее пессимистично. Впрочем, не думаю, что будут какие-то принципиально нерешаемые проблемы.
> то её ценой является привязка к современным окружениям Linux - для своей работы проект требует наличия ядра Linux 4.10 и glibc 2.16,
> и принципиально не может быть использован в старых дистрибутивах Linux или в других ОС.Поттеринг покусал?
systemd-dbusd
system-d-bus
А Вы попробуйте разрабатывать под старые дистрибутивы. Куда не ткни, не хватает функции, которая уже давно есть в новых дистрибутивах.Взять тот же Питон. Для версии 3.4 (ubuntu 14.04) у pathlib.Path.mkdir(...) нет аргумента exist_ok, который есть в версии 3.6 (Debian 9). В результате вместо 6 строк будет уже 12 (добавляется if not p.exists()).
> В результате вместо 6 строк будет уже 12Ого, это же катастрофа!
Экстраполировать информацию и делать выводы не умеем?
Экстраполируя эту информацию, в питоне когда-нибудь будет всего одна функция СделайТоЧтоЯХочу(), но работать оно будет только на самом последнем квантовом компьютере.Или можно написать 12 строчек, которые в итоге сделают тоже самое, может даже быстрее и оно будет работать у всех и на чем угодно.
> Экстраполируя эту информацию, в питоне когда-нибудь будет всего одна функция СделайТоЧтоЯХочу(),
> но работать оно будет только на самом последнем квантовом компьютере.
> Или можно написать 12 строчек, которые в итоге сделают тоже самое, может
> даже быстрее и оно будет работать у всех и на чем
> угодно.Дело даже не в этом (не только в этом), а в том, что когда ты видишь эти строки, ты понимаешь, что проверка то нужна. В другом варианте ты потихоньку забываешь о проверках, и в результате .овнокодовость (без воспитателя) возрастает.
Сдается мне это проблема питона, а старого линукса, и именно поэтому он идет лесом.
Странные выводы. Проверка бесполезна, если можно указывать аргумент. Это проще. А если таких строчек много, то код становится понятнее, т. к. уменьшается в размере.А быстрее, чем if это работать не может, т. к. проверка переносится просто внутрь функции. Как была, так и осталась, только в другом виде.
> А быстрее, чем if это работать не может, т. к. проверка переносится просто внутрь функции. Как была, так и осталась, только в другом виде.Тссс! Не мешай людям наслаждаться плацебо.
>Или можно написать 12 строчек, которые в итоге сделают тоже самое, может даже быстрее и оно будет работать у всех и на чем угодно.При условии что 12 строчек не на Питоне
а еще, а еще!! нельзя например использовать тип auto, если нет с++11
Я использую var. Например, var leftpad = require('leftpad').
зарегистрируйся пожалуйста, о гроза электрон-программирования.....чтоб тебя можно было бы сразу распознавать (и восторгаться твоим электроном, даже когда ты о нём не пишешь)
А еще на старых ядрах не работает назначение прав на shm, - старые это 3-4 года, для сабжа это критично, сам решал сабжевую задачу, а уперся в штангу.
Этот shm - тот ещё костыль. Неудивительно, что в Android написали свой с нуля.
Может что-то неправильно поняли? shm - это разделяемая память. Есть два варианта API: SysV и POSIX. Но реализация в ядре одинаковая. В Андроиде скорее всего она либо неиспользуется, либо используется на уровне системных компонентов (т. к. Java).
Абстрактный "shm" это механизм использования одних страниц памяти в нескольких процессах, тривиально реализуемый в любой ОС с разделяемой памятью.SysV и POSIX SHM с точки зрения внутреннего устройства — одного поля ягоды. Оба позволяют выделить глобальный сегмент памяти и оставить его валяться, когда выделивший процесс откинул концы. В связи с проистекающим отсюда потенциалом ля утечек памяти (и прочими национальными особенностями), в Android был выпилен апстримный shm драйвер и реализован собственный ("/dev/ashmem"), в котором память выделяется строго по файловым дескрипторам (и соответственно освобождается после закрытия процесса-владельца).
Тогда может не процесса-владельца, а по счётчику ссылок? Почитал, по сути та же разделяемая память, но имя файла тут же удаляется после старта (остаётся только inode со счётчиком ссылок). А подключить в другом процессе можно только передав файловый дескриптор через IPC. Очень даже грамотное решение.Почти то же самое в плане предотвращения утечек будет, если в разделяемой памяти POSIX удалить файл (unlink) сразу после его создания.
Насколько я понял, разница только в плане безопасности: между созданием и удалением в POSIX можно успеть подключить разделяюмую память в другом процессе.
А по факту сама разделяемая память обычная - через mmap.
> А Вы попробуйте разрабатывать под старые дистрибутивы. Куда не ткни, не хватает
> функции, которая уже давно есть в новых дистрибутивах.4.10 вышло в этом году. Хотя да, шесть месяцев уже старье старое. Кстати, дебиан таким образом - в пролете.
> Взять тот же Питон.
А, ну если питон брать то да, другое дело! Ведь только питона еще в зависимостях dbus нам для полного Щастья не хватает!
Для пущего ускорения еще в ядро желательно воткнуть, а то ведь обмен сообщениями подразумевает потоки данных в гигазы/сек. - видосик в raw прокинуть или еще что. Механизмов для таких случаев ведь в самом ядре нема, а надобность возникает у каждого второго приложения! Правда, kdbus не прокатил, ну так попытка ведь не пытка!
> 4.10 вышло в этом году. Хотя да, шесть месяцев уже старье старое.
> Кстати, дебиан таким образом - в пролете.В бэкпортах 4.12 уже.
> Кстати, дебиан таким образом - в пролете.Один фиг не примут до версии 2.0.
Linux 2.6.9 хватит всем.
Почему именно 2.6.9, а не, например, 2.4.37?
А разработчики питона разве не пишут хорошо переносимый интерпретатор? Что им мешает выпустить версию 3.6 для старых версий, они autoconf не освоили? Благо, mkdir -p как-то же работает во всех версиях, почему бы и exist_ok не быть? :)
exist_ok - это не аналог аргумента -p у mkdir. exist_ok не генерирует исключение, если целевой каталог существует. У mkdir подобной опции нет (mkdir my_dir &>/dev/null || true). А аналог опции -p - это аргумент parents у pathlib.Path.mkdir. Он есть и в версии 3.4.Бэкпортировать новые версии Питона Вам скорее всего никто не станет. Слишком сложная задача будет. Пробовал поставить ansible последний в ubuntu 14.04 через pip3, уже наткнулся на отсутствие библиотеки, а также баг, из-за которого библиотека не тянулась автоматически при наличии прокси-сервера. В конце концов поставил, но программа не заработала. Дальше разбираться уже не стал.
А если дальше про версии говорить, то, например, в том же ansible в ubuntu 14.04 я не смогу использовать openvswitch_bridge. Просто потому, что там ещё не было опции parent. А без неё мост будет бесполезен в рамках задачи. Попробуйте на ansible то же самое сделать ручками и качественно, чтобы задача исполнялась только один раз и не вызывала событие изменения своего состояния.
Используя новые версии можно сильно сэкономить своё время.
> Обеспечивается работа только локального IPC без поддержки сетевого взаимодействия (при необходимости проброса на другой хост предлагается пробрасывать локальный сокет через SSH).KISS!
...me in ass?
Ты любишь, когда в твоей жопе целуются?
MGIMO finish?
"Поцелуй меня в России"Слово "Россия" переведено иносказательно.
Всё хорошо в меру и этот KISS тоже.
Пользуюсь WM без DBus. Не понимаю зачем он нужен. Единственное что - BlueZ 5 без него не работает. Вы знаете хоть одну прогу, которая хочет DBus? Я - нет, а пользуюсь я не менее 3 софтин постоянно и 15-20 иногда. Даже то, что слинковано с libdbus, спокойно работает с выключенной системной службой.Вне контекста всяких разных DE - лишняя сущность.
> Пользуюсь WM без DBus. Не понимаю зачем он нужен. Единственное что -
> BlueZ 5 без него не работает. Вы знаете хоть одну прогу,
> которая хочет DBus? Я - нет, а пользуюсь я не менее
> 3 софтин постоянно и 15-20 иногда. Даже то, что слинковано с
> libdbus, спокойно работает с выключенной системной службой.
> Вне контекста всяких разных DE - лишняя сущность.Для админов локалхоста - однозначно! (С)
>> Пользуюсь WM без DBus. Не понимаю зачем он нужен. Единственное что -
>> BlueZ 5 без него не работает. Вы знаете хоть одну прогу,
>> которая хочет DBus? Я - нет, а пользуюсь я не менее
>> 3 софтин постоянно и 15-20 иногда. Даже то, что слинковано с
>> libdbus, спокойно работает с выключенной системной службой.
>> Вне контекста всяких разных DE - лишняя сущность.
> Для админов локалхоста - однозначно! (С)То ли дело одмины нелокалхостов - без Desktop-Bus жить не могут!
На серверах dbus тем более не нужен.
>Единственное что - BlueZ 5 без него не работает.Расскажу тайну, брат анонимус. BlueZ и с dbus не работает. Он просто не работает, потому что написан через задницу.
>>Единственное что - BlueZ 5 без него не работает.
> Расскажу тайну, брат анонимус. BlueZ и с dbus не работает. Он просто
> не работает, потому что написан через задницу.Что использовать для работы с bluetooth? Желательно что бы и из CLI работало и bluetooth pairing из скриптов можно было сделать!
Не прошло и 10 лет, как кто-то последовал заветам Линуса.
Не прошло и 10 лет и сишники поняли как должна работать шина
Нелавно узнал про D-Bus отличная штука можно сообщения посылать между приложениями и даже действия совершать. Почти что шина для умного дома, но в рамках одного компьютера. Насчет смены концепции не знаю, но звучит как реализация PubSub. Вот только ни одной реализацией я что-то не был доволен.
Столько лет наступать на одни и те же грабли, переписал бы на rust-е.
Не, лучше на хацкеле и встроить в ядро, вместе с хацкелем. Полумеры - для слабаков.
а хацкель должен быть написан на расте, иначе растофанатики не успокоятся и будут под каждым релизом гадить своими комментами в духе: "а писали бы все на расте..."
> Не, лучше на хацкелена OCaml. хацкель каждый дурак понять сможет.
>>встроить в ядро, вместе с хацкелемУже было, но GHC мусор после себя не прибирает. Он же скорее под userspace сделан.
https://wiki.haskell.org/Kernel_Modules
Вот что животворящий gprof от Линуса делает. Как он и говорил не нужно всю эту каку в ядро тянуть, достаточно юзерспейса.
David Hermann пишет, что dbus-broker полагается на возможности, появившиеся в ядре совсем недавно, буквально пару месяцев назад. Т.ч. в споре разработчиков kdbus и ядерщиков фактически победил компромисс: Торвальдс отказался от kdbus, но вместо этого смерджил код, необходимый для реализации чего-то подобного в юзерспейсе. Т.е. придумал более компактное и универсальное решение - впрочем ничего нового, за способность видеть такие вещи наперед Торвальдса и уважают в индустрии.
> kdbus
> Bus1
> D-Bus BrokerБольше дубасов хороших и разных!
Это лучше. Это брокер дубаса.
шутки шутками, а в этом году целых 4 компании с дубасом вышли на биржу
> D-Bus Broker ... принципиально не может быть использован
> в старых дистрибутивах Linux или в других ОС.Просто прелесть!
Мне всегда нравилась идея общей шины и dbus. Пока я не обнаружил, что большинство реализаций не умеет корректно обрабатывать отсутствие dbus сервиса. Что будет делать браузер, если у тебя отключён интернет? Просто перестанет открывать странички из интернета, локальные будет показывать. Что делает браузер, если у тебя отключён dbus (а браузер собран с поддержкой dbus) - перестаёт работать. Офигеть. Неужели нельзя было проверить доступность? Большая часть клиентских библиотек для dbus тупо пытается стартовать dbus сервис сама (и не выключает его после завершения работы программы). Когда я это пресёк, я и выяснил, что вариант "dbus не доступен" авторами 95% софта не учитывается.Всё это от того, частично, что есть всего одна популярная реализация стандарта dbus. Был бы стандарт зрелый, было бы несколько вариантов софта, и какой-то из них научился бы обрабатывать отсутствия сервиса корректно.
dbus - жуткий костыль, возникший на месте вменяемого ipc в GNU/Linux. откуда же взяться нормальной реализации?
С чего это вы message queue называется костылём? Очень часто встречающаяся концепция IPC. RabbitMQ - тоже костыль? ОС предоставляет низкоуровневые концепции IPC. Абсолютно нормально дополнять их более высокоуровневыми концепциями, реализованными поверх них. Система акторов и транзакционная память - тоже костыли?
> Что делает браузер, если у тебя отключён dbus (а браузер собран с поддержкой dbus) - перестаёт работать. Офигеть. Неужели нельзя было проверить доступность?Ну офигеть теперь. Ты ещё предложи программам обходиться без наличия UNIX-сокетов, там, графического тулкита или libc. "Собираю ядро без сокетов, а у меня все программы отваливаются! Неужели нельзя было проверить доступность? Ну и г-ноделы!"
Тащемт@, всякие autotools на этапе сборки проверяют. :)Но это не спасает в случае, когда софт собран на одной системе, а эксплуатируется на других, а таких случаев большинство.
P.S. С чего это вдруг "т@щемта" форум посчитал ненормативной лексикой? Обычное не неприличное, хоть и слэнговое, слово.
Ошибка при компиляции c-sundry - static assertion failed: "" ( Gcc 7.2.0 Glibc 2.26)
А не проще PUB/SUB в Redis использовать?
Шел 2018 год, Линукс до сих пор игнорил десктоп а задачей номер один была бесконечная война за реализацию шины и перестройка графических подсистем.