Большие группы взаимодействующих процессов требуют плотной сети отдельных каналов связи (с использованием методов IPC «один к одному») между ними. D-Bus упрощает требования IPC за счет одного общего канала.
Из-за большого количества задействованных процессов — сложения процессов, предоставляющих услуги, и клиентов, получающих к ним доступ — установление IPC между всеми ними становится неэффективным и весьма ненадежным. [ нужна ссылка ] подход. Вместо этого D-Bus предоставляет программной шины абстракцию , которая собирает все сообщения между группой процессов по одному общему виртуальному каналу. [6] Процессы, подключенные к шине, не знают, как это реализовано внутри, но спецификация D-Bus гарантирует, что все процессы, подключенные к шине, могут взаимодействовать друг с другом через нее.
Среды рабочего стола Linux используют возможности D-Bus, создавая экземпляры нескольких шин, в частности: [16] [6] [17]
единая системная шина , доступная всем пользователям и процессам системы, которая обеспечивает доступ к системным службам (т. е. службам, предоставляемым операционной системой , а также любыми системными демонами )
сеансовая шина для каждого сеанса входа пользователя, которая предоставляет услуги рабочего стола пользовательским приложениям в одном сеансе рабочего стола и позволяет интегрировать сеанс рабочего стола в целом
Процесс может подключаться к любому количеству шин при условии, что ему предоставлен к ним доступ. На практике это означает, что любой пользовательский процесс может подключаться к системной шине и к своей текущей сеансовой шине, но не к сеансовым шинам другого пользователя или даже к другой сеансовой шине, принадлежащей тому же пользователю. Последнее ограничение может измениться в будущем, если все пользовательские сессии объединить в одну пользовательскую шину. [18]
D-Bus предоставляет приложениям дополнительные или упрощает существующие функциональные возможности, включая обмен информацией, модульность и разделение привилегий . Например, информация о входящем голосовом вызове, полученном через Bluetooth или Skype, может распространяться и интерпретироваться любым работающим в данный момент музыкальным проигрывателем, который может реагировать отключением громкости или приостановкой воспроизведения до завершения вызова. [19]
Каждое подключение к шине идентифицируется в контексте D-Bus так называемым именем шины . [5] Имя шины состоит из двух или более строк букв, цифр, тире и подчеркиваний, разделенных точками. Пример допустимого имени шины: org.freedesktop.NetworkManager. [6]
Когда процесс устанавливает соединение с шиной, шина присваивает этому соединению специальное имя шины, называемое уникальным именем соединения . [17] [6] Имена шин этого типа неизменяемы — гарантировано, что они не изменятся, пока существует соединение, — и, что более важно, их нельзя использовать повторно в течение срока службы шины. [5] [17] [6] Это означает, что никакому другому соединению с этой шиной никогда не будет присвоено такое уникальное имя соединения, даже если тот же процесс закроет соединение с шиной и создаст новое. Уникальные имена соединений легко узнать, поскольку они начинаются с запрещенного в противном случае символа двоеточия. [17] [6] Пример уникального имени соединения: :1.1553 (символы после двоеточия не имеют особого значения [17] ).
Процесс может запросить дополнительные имена шин для своего подключения. [17] при условии, что любое запрошенное имя еще не используется при другом подключении к шине. На языке D-Bus, когда соединению присваивается имя шины, говорят, что принадлежит соединению. имя шины [5] [17] В этом смысле имя шины не может принадлежать двум соединениям одновременно, но, в отличие от уникальных имен соединений, эти имена могут использоваться повторно, если они доступны: процесс может вернуть имя шины, освобожденное — намеренно или нет — другим процесс. [5] [6]
Идея этих дополнительных имен шин, обычно называемых общеизвестными именами , заключается в том, чтобы предоставить возможность обращаться к службе с использованием заранее заданного имени шины. [17] [6] Например, служба, сообщающая текущее время и дату по системной шине, находится в процессе, соединение которого владеет org.freedesktop.timedate1 имя шины, независимо от того, какой это процесс.
Имена шин можно использовать как простой способ реализации одноэкземплярных приложений (вторые экземпляры обнаруживают, что имя шины уже занято). [17] Его также можно использовать для отслеживания жизненного цикла процесса обслуживания, поскольку шина отправляет уведомление, когда имя шины освобождается из-за завершения процесса. [17]
Из-за своей первоначальной концепции замены нескольких компонентно-ориентированных систем связи, D-Bus разделяет со своими предшественниками объектную модель, в которой выражается семантика связи между клиентами и службами. Термины, используемые в объектной модели D-Bus, имитируют термины, используемые в некоторых объектно-ориентированных языках программирования . Это не означает, что D-Bus каким-то образом ограничен ООП-языками — на самом деле это наиболее используемая реализация ( libdbus ) написан на C , процедурном языке программирования .
Просмотр существующих имен шин, объектов, интерфейсов, методов и сигналов на шине D-Bus с помощью D-Feet
В D-Bus процесс предлагает свои услуги, предоставляя объекты . Эти объекты имеют методы , которые можно вызывать, и сигналы , которые может излучать объект. [17] Методы и сигналы вместе называются членами объекта . [5] Любой клиент, подключенный к шине, может взаимодействовать с объектом, используя его методы, отправляя запросы или командуя объекту выполнять действия. [17] Например, объект, представляющий службу времени, может быть запрошен клиентом с помощью метода, возвращающего текущую дату и время. Клиент также может прослушивать сигналы, которые излучает объект, когда его состояние изменяется из-за определенных событий, обычно связанных с базовой службой. Примером может служить ситуация, когда служба, управляющая аппаратными устройствами, такими как USB или сетевые драйверы, сигнализирует о событии «добавлено новое аппаратное устройство». Клиенты должны сообщить шине, что они заинтересованы в получении определенных сигналов от определенного объекта, поскольку шина D-Bus передает сигналы только тем процессам, которые имеют к ним зарегистрированный интерес. [6]
Процесс, подключенный к шине D-Bus, может запросить экспорт любого количества объектов D-Bus. Каждый объект идентифицируется путем к объекту , строкой цифр, букв и символов подчеркивания, разделенных и предваряемых косой чертой, названной так из-за их сходства с путями файловой системы Unix . [5] [17] Путь к объекту выбирается запрашивающим процессом и должен быть уникальным в контексте данного шинного соединения. Пример допустимого пути к объекту: /org/kde/kspread/sheets/3/cells/4/5. [17] Однако не обязательно (но и не рекомендуется) формировать иерархии внутри путей к объектам. [6] Конкретное соглашение об именах объектов службы полностью зависит от разработчиков такой службы, но многие разработчики предпочитают размещать их в пространстве имен, используя зарезервированное доменное имя проекта в качестве префикса (например, /орг/где ). [17]
Каждый объект неразрывно связан с конкретным шинным соединением, куда он был экспортирован, и, с точки зрения D-Bus, существует только в контексте такого соединения. Следовательно, чтобы иметь возможность использовать определенный сервис, клиент должен указать не только путь к объекту, предоставляющему желаемый сервис, но и имя шины, под которой к шине подключается процесс сервиса. [5] Это, в свою очередь, позволяет нескольким процессам, подключенным к шине, однозначно экспортировать разные объекты с одинаковыми путями к объектам.
Интерфейс определяет члены — методы и сигналы, — которые можно использовать с объектом. [17] Это набор объявлений методов (включая передаваемые и возвращаемые параметры) и сигналов (включая параметры), идентифицируемых именем, разделенным точкой, напоминающим нотацию интерфейсов языка Java . [17] [6] Пример допустимого имени интерфейса: org.freedesktop.Introspectable. [6] Несмотря на схожесть, названия интерфейсов и шин не должны путаться. Объект D-Bus может реализовать несколько интерфейсов, но, по крайней мере, должен реализовать один, обеспечивая поддержку каждого метода и сигнала, определенных им. Комбинация всех интерфейсов, реализованных объектом, называется типом объекта . [5] [17]
При использовании объекта для клиентского процесса рекомендуется предоставлять имя интерфейса члена помимо имени члена, но это обязательно только в том случае, если существует двусмысленность, вызванная дублированием имен членов, доступных из разных интерфейсов, реализованных объектом. [5] [17] — в противном случае выбранный элемент не определен или ошибочен. С другой стороны, излучаемый сигнал всегда должен указывать, к какому интерфейсу он принадлежит.
Спецификация D-Bus также определяет несколько стандартных интерфейсов, которые объекты могут захотеть реализовать в дополнение к своим собственным интерфейсам. [16] Хотя это технически необязательно, большинство разработчиков сервисов D-Bus предпочитают поддерживать их в своих экспортируемых объектах, поскольку они предлагают клиентам D-Bus важные дополнительные функции, такие как самоанализ . [6] Эти стандартные интерфейсы: [16] [6]
org.freedesktop.DBus.Peer : предоставляет способ проверить, активно ли соединение D-Bus. [6]
org.freedesktop.DBus.Introspectable : предоставляет механизм самоанализа, с помощью которого клиентский процесс может во время выполнения получить описание (в формате XML ) интерфейсов, методов и сигналов, которые реализует объект. [17] [16]
org.freedesktop.DBus.Properties : позволяет объекту D-Bus раскрывать базовые свойства или атрибуты собственного объекта или моделировать их, если он не существует. [16]
org.freedesktop.DBus.ObjectManager : когда служба D-Bus упорядочивает свои объекты иерархически, этот интерфейс предоставляет возможность запросить у объекта все подобъекты по его пути, а также их интерфейсы и свойства, используя один вызов метода. . [16]
Спецификация D-Bus определяет ряд административных операций шины (называемых «шинными службами»), которые должны выполняться с использованием /org/freedesktop/DBus , который находится в org.freedesktop.DBus . Имя шины [16] Каждая шина резервирует это специальное имя для себя и управляет любыми запросами, сделанными специально для этой комбинации имени шины и пути к объекту. Административные операции, предоставляемые шиной, определяются интерфейсом объекта. org.freedesktop.DBus . Эти операции используются, например, для предоставления информации о состоянии шины, [5] или для управления запросом и выпуском дополнительных известных названий шин. [16] [6]
D-Bus был задуман как универсальная система межпроцессного взаимодействия высокого уровня. Для достижения этих целей связь D-Bus основана на обмене сообщениями между процессами вместо «необработанных байтов». [5] [17] Сообщения D-Bus — это дискретные элементы высокого уровня, которые процесс может отправлять по шине другому подключенному процессу. Сообщения имеют четко определенную структуру (определены даже типы данных, переносимых в их полезной нагрузке), что позволяет шине проверять их и отклонять любое неправильно сформированное сообщение.В этом отношении D-Bus ближе к механизму RPC , чем к классическому механизму IPC, со своей собственной системой определения типов и собственной маршалингом . [5]
Пример обмена сообщениями запрос-ответ один на один для вызова метода через D-Bus. Здесь клиентский процесс вызывает SetFoo() метод Объект /org/example/object1 из процесса службы с именем org.example.foo (или :1.14) в автобусе.
Шина поддерживает два режима обмена сообщениями между клиентом и сервисным процессом. [5] :
Индивидуальный запрос-ответ : это способ, с помощью которого клиент может вызвать метод объекта. Клиент отправляет сообщение процессу службы, экспортирующему объект, а служба, в свою очередь, отвечает сообщением обратному процессу клиента. [17] Сообщение, отправленное клиентом, должно содержать путь к объекту, имя вызванного метода (и, возможно, имя его интерфейса) и значения входных параметров (если таковые имеются), определенные выбранным интерфейсом объекта. Ответное сообщение содержит результат запроса, включая значения выходных параметров, возвращаемых вызовом метода объекта, или информацию об исключении, если произошла ошибка. [5] [17]
Публикация/подписка : это способ объявления объекта о появлении сигнала заинтересованным сторонам. Процесс обслуживания объекта передает сообщение, которое шина передает только подключенным клиентам, подписанным на сигнал объекта. [17] Сообщение содержит путь к объекту, имя сигнала, интерфейс, которому принадлежит сигнал, а также значения параметров сигнала (если таковые имеются). Связь односторонняя: на исходное сообщение ни от одного клиентского процесса нет ответных сообщений, поскольку отправитель не знает ни личности, ни количества получателей. [5] [17]
Каждое сообщение D-Bus состоит из заголовка и тела. [17] Заголовок формируется несколькими полями, которые идентифицируют тип сообщения, отправителя, а также информацию, необходимую для доставки сообщения получателю (имя целевой шины, путь к объекту, имя метода или сигнала, имя интерфейса и т. д.). [17] [16] Тело содержит полезные данные, которые интерпретирует процесс-получатель, например входные или выходные аргументы. Все данные кодируются в хорошо известном двоичном формате, называемом проводным форматом , который поддерживает сериализацию различных типов, таких как целые числа и числа с плавающей запятой, строки, составные типы и т. д. [16] также называется маршалингом .
Спецификация D-Bus определяет проводной протокол : как создавать сообщения D-Bus для обмена между процессами в рамках соединения D-Bus. Однако он не определяет базовый метод транспорта для доставки этих сообщений.
Большинство существующих реализаций D-Bus следуют архитектуре эталонной реализации. Эта архитектура состоит из двух основных компонентов: [5]
связи «точка-точка» библиотека , реализующая проводной протокол D-Bus для обмена сообщениями между двумя процессами. В эталонной реализации эта библиотека libdbus . В других реализациях libdbus может быть обернут другой библиотекой более высокого уровня, языковой привязкой или полностью заменен другой автономной реализацией, которая служит той же цели. [20] Эта библиотека поддерживает только прямую связь между двумя процессами. [17]
А Процесс dbus-daemon, действующий как демон шины сообщений D-Bus. Каждый процесс, подключенный к шине, поддерживает с ним одно соединение D-Bus. специальный процесс-демон , который играет роль шины и к которому подключаются остальные процессы с помощью любой библиотеки связи «точка-точка» D-Bus. Этот процесс также известен как демон шины сообщений . [19] поскольку он отвечает за маршрутизацию сообщений от любого процесса, подключенного к шине, к другому. В эталонной реализации эту роль выполняет dbus-daemon , который сам построен на основе libdbus . Другая реализация демона шины сообщений — dbus-broker , построенный на основе SD-шина .
Процессы A и B имеют соединение D-Bus «один к одному», используя libdbus через сокет домена Unix. Они могут использовать его для прямого обмена сообщениями. [21] В этом сценарии имена шин не требуются. [17]
Процесс A и B оба подключены к dbus-демон с использованием libdbus через сокет домена Unix. Они могут обмениваться сообщениями, отправляя их в процесс шины сообщений, который, в свою очередь, доставляет сообщения соответствующему процессу. В этом сценарии имена шин являются обязательными для идентификации процесса назначения.
The Библиотека libdbus (или ее эквивалент) внутри использует собственный механизм IPC нижнего уровня для транспортировки необходимых сообщений D-Bus между двумя процессами на обоих концах соединения D-Bus. Спецификация D-Bus не предписывает, какие именно транспортные механизмы IPC должны быть доступны для использования, поскольку именно коммуникационная библиотека решает, какие методы транспортировки она поддерживает. Например, в Unix-подобных операционных системах, таких как Linux. libdbus обычно использует сокеты домена Unix в качестве основного метода транспорта, но он также поддерживает сокеты TCP . [5] [17]
Коммуникационные библиотеки обоих процессов должны согласовать выбранный метод транспортировки, а также конкретный канал, используемый для их связи. Эта информация определяется тем, что D-Bus называет адресом . [6] [17] Сокеты домена Unix являются объектами файловой системы , поэтому их можно идентифицировать по имени файла, поэтому действительным адресом будет unix:path=/tmp/.hiddensocket. [5] [16] Оба процесса должны передать один и тот же адрес своим соответствующим коммуникационным библиотекам, чтобы установить между ними соединение D-Bus. Адрес также может предоставлять дополнительные данные в библиотеку связи в виде разделенных запятыми key=value пары. [6] [16] Таким образом, например, он может предоставить информацию аутентификации определенному типу соединения, которое его поддерживает.
Когда демон шины сообщений, например dbus-daemon используется для реализации шины D-Bus, все процессы, которые хотят подключиться к шине, должны знать адрес шины , адрес, по которому процесс может установить соединение D-Bus с процессом центральной шины сообщений. [5] [17] В этом сценарии демон шины сообщений выбирает адрес шины, а остальные процессы должны передать это значение соответствующим libdbus или эквивалентные библиотеки. dbus-daemon определяет разные адреса шины для каждого экземпляра шины, который он предоставляет. Эти адреса определены в файлах конфигурации демона.
Два процесса могут использовать соединение D-Bus для обмена сообщениями напрямую между собой. [21] но это не тот способ, которым обычно предполагается использовать D-Bus. Обычный способ — всегда использовать демон шины сообщений (т. е. dbus-daemon ) в качестве центральной точки связи, с которой каждый процесс должен установить двухточечное соединение D-Bus. Когда процесс — клиент или служба — отправляет сообщение D-Bus, процесс шины сообщений получает его в первую очередь и доставляет соответствующему получателю. Демон шины сообщений можно рассматривать как концентратор или маршрутизатор, отвечающий за доставку каждого сообщения к месту назначения путем его повторения через соединение D-Bus с процессом-получателем. [17] Процесс-получатель определяется именем шины назначения в поле заголовка сообщения. [16] или посредством информации о подписке на сигналы, поддерживаемые демоном шины сообщений, в случае сообщений распространения сигнала. [6] Демон шины сообщений также может создавать свои собственные сообщения в ответ на определенные условия, например сообщение об ошибке процессу, который отправил сообщение на несуществующую шину. [17]
dbus-daemon расширяет набор функций, уже предоставляемый самим D-Bus, за счет дополнительных функций. Например, активация службы позволяет автоматически запускать службы при необходимости — когда первый запрос к любому имени шины такой службы поступает на демон шины сообщений. [5] Таким образом, служебные процессы не нужно запускать на этапе инициализации системы или пользователя, а также не требуется, чтобы они потребляли память или другие ресурсы, когда они не используются. Эта функция изначально была реализована с использованием setuid , помощников [22] но в настоящее время это также может быть предоставлено . инфраструктурой активации службы systemd [ нужна ссылка ] Активация службы — это важная функция, которая облегчает управление жизненным циклом процесса служб (например, когда должен запускаться или останавливаться компонент рабочего стола). [17]
D-Bus был запущен в 2002 году Хэвоком Пеннингтоном, Алексом Ларссоном ( Red Hat ) и Андерсом Карлссоном. [8] Версия 1.0, считающаяся стабильной API , была выпущена в ноябре 2006 года. [23] [24]
Одним из первых применений был (ныне устаревший) уровень аппаратной абстракции . HAL использовал D-Bus для экспорта информации об оборудовании, которое было добавлено или удалено с компьютера. [8]
Использование D-Bus постепенно выходит за пределы первоначального объема настольных сред и охватывает все большее количество системных сервисов. Например, сетевой демон NetworkManager , стек Bluetooth BlueZ и звуковой сервер PulseAudio используют D-Bus для предоставления части или всех своих услуг. systemd использует проводной протокол D-Bus для связи между systemctl и systemd, а также внедряет традиционные системные демоны в службы D-Bus, такие как logind . [26] Еще одним активным пользователем D-Bus является Polkit , чей демон полномочий политики реализован как сервис, подключенный к системной шине. [27]
Хотя существует несколько реализаций D-Bus, наиболее широко используемой является эталонная реализация libdbus , разработанная тем же проектом freedesktop.org, который разработал спецификацию. Однако libdbus — это низкоуровневая реализация, которая никогда не предназначалась для непосредственного использования разработчиками приложений, а служила справочным руководством для других реализаций D-Bus (например, включенных в стандартные библиотеки сред рабочего стола или в языков программирования) привязки . ). Сам проект freedesktop.org рекомендует авторам приложений вместо этого «использовать одну из привязок или реализаций более высокого уровня». [28] Преобладание libdbus как наиболее используемой реализации D-Bus привело к тому, что термины «D-Bus» и «libdbus» часто использовались как синонимы, что приводило к путанице. [ нужна ссылка ]
GDBus [9] представляет собой реализацию D-Bus на основе потоков GIO , включенных в GLib , предназначенную для использования GTK+ и GNOME . GDBus — это не оболочка libdbus, а полная и независимая реализация спецификации и протокола D-Bus. [29] MATE Рабочий стол [30] и Xfce (версия 4.14), которые также основаны на GTK+ 3, также используют GDBus. [ нужна ссылка ]
В 2013 году проект systemd переписал libdbus, стремясь упростить код. [31] но это также привело к значительному увеличению общей производительности D-Bus. В ходе предварительных тестов BMW обнаружила, что библиотека D-Bus systemd увеличила производительность на 360%. [32] В версии systemd sd-bus 221 API был объявлен стабильным. [33]
kdbus реализован как символьный драйвер устройства. [34] [35] Вся связь между процессами осуществляется через узлы устройств со специальными символами в /dev/kdbus (см. devfs ).
kdbus был проектом, целью которого было переопределить D-Bus как механизм однорангового межпроцессного взаимодействия, опосредованный ядром . Помимо повышения производительности, kdbus будет иметь преимущества, связанные с другими функциями ядра Linux, такими как пространства имен и аудит. [32] [36] безопасность за счет посредничества ядра, закрытия условий гонки и разрешения использования D-Bus во время загрузки и завершения работы (по мере необходимости systemd). [37] Включение kdbus в ядро Linux вызвало споры. [38] и от него отказались в пользу BUS1 как более общего средства межпроцессного взаимодействия . [39]
^ Уорд, Брайан (2004). «14: Краткий обзор рабочего стола Linux». Как работает Linux: что должен знать каждый суперпользователь (2-е изд.). Сан-Франциско: No Starch Press (опубликовано в 2014 г.). п. 305. ИСБН 9781593275679 . Проверено 7 ноября 2016 г. Одной из наиболее важных разработок настольных систем Linux является Desktop Bus (D-Bus), система передачи сообщений. D-Bus важен, поскольку он служит механизмом межпроцессного взаимодействия, который позволяет настольным приложениям взаимодействовать друг с другом [...].
^ Вермюлен, Йерун (14 июля 2013 г.). «Введение в D-Bus» . FreeDesktop.org . Проверено 3 октября 2015 г. D-Bus [...] предназначен для использования в качестве унифицированного промежуточного уровня под основными бесплатными средами рабочего стола.
^ Пеннингтон, Хэвок; Уиллер, Дэвид; Уолтерс, Колин. «Учебное пособие по D-Bus» . Проверено 21 октября 2015 г. Что касается варианта использования внутри сеанса рабочего стола, рабочие столы GNOME и KDE имеют значительный предыдущий опыт работы с различными решениями IPC, такими как CORBA и DCOP. D-Bus создан на основе этого опыта и тщательно адаптирован для удовлетворения потребностей, в частности, настольных проектов.
^ Вермюлен, Йерун (14 июля 2013 г.). «Введение в D-Bus» . FreeDesktop.org . Проверено 3 октября 2015 г. D-Bus был впервые создан для замены CORBA-подобной компонентной модели, лежащей в основе среды рабочего стола GNOME. Подобно DCOP (который используется KDE), D-Bus станет стандартным компонентом основных бесплатных сред рабочего стола для GNU/Linux и других платформ.
^ Пёттеринг, Леннарт (19 июня 2015 г.). «Новый API SD-шины systemd» . Проверено 21 октября 2015 г. мы работаем над переносом вещей на настоящую пользовательскую шину, которая есть только одна на каждого пользователя в системе, независимо от того, сколько раз этот пользователь входит в систему.
^ «Что такое D-Bus?» . FreeDesktop.org . Проверено 29 октября 2015 г. Существуют также некоторые реализации протокола D-Bus для таких языков, как C#, Java и Ruby. Они не используют эталонную реализацию libdbus.
^ Jump up to: а б «Что такое D-Bus?» . FreeDesktop.org . Проверено 29 октября 2015 г. построен на основе общей структуры передачи сообщений «один к одному», которую могут использовать любые два приложения для прямого взаимодействия (без использования демона шины сообщений).
^ Пёттеринг, Леннарт (19 июня 2015 г.). «Новый API SD-шины systemd» . Проверено 21 октября 2015 г. С момента создания systemd это была система IPC, в которой он предоставляет свои интерфейсы.
^ «Что такое D-Bus?» . FreeDesktop.org . Проверено 5 января 2015 г. Низкоуровневая реализация в первую очередь не предназначена для использования авторами приложений. Скорее, это основа для связывания авторов и ссылка для повторных реализаций. Если вы можете это сделать, рекомендуется использовать одну из привязок или реализаций более высокого уровня.
^ «Миграция на GDBus» . Разработчик GNOME . Проверено 21 октября 2015 г. dbus-glib использует эталонную реализацию libdbus, а GDBus — нет. Вместо этого он использует потоки GIO в качестве транспортного уровня и имеет собственную реализацию для настройки и аутентификации соединения D-Bus.
Arc.Ask3.Ru Номер скриншота №: 2a6d9028959ca282a0c264847ea3292f__1718055900 URL1:https://arc.ask3.ru/arc/aa/2a/2f/2a6d9028959ca282a0c264847ea3292f.html Заголовок, (Title) документа по адресу, URL1: D-Bus - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)
