Разработчики из компании Collabora представили (http://alban.apinc.org/blog/2010/09/15/d-bus-in-the-kernel-f... проект kdbus (http://www.mnementh.co.uk/home/projects/collabora/kdbus), в рамках которого создан экспериментальный прототип шины для обмена сообщениями между процессами D-Bus (http://ru.wikipedia.org/wiki/D-Bus), работающий на уровне Linux-ядра. Встраивание D-Bus в ядро позволило существенно повысить производительность, за счет уменьшения числа копирования областей памяти и минимизации числа переключения контекста между ядром и процессом-демоном, работающим на прикладном уровне.В kdbus для отправки сообщений реализован новый тип сокетов AF_DBUS, который напоминает Unix-сокет и позволяет доставлять сообщения приложению-получателю напрямую, без задействования процесса-посредника (dbus-daemon). Изменения внутренней структуры организации обмена сообщениями не заметно для конечных приложений, так как они используют функции библиотеки libdbus, внешний API которой остался...
URL: http://alban.apinc.org/blog/2010/09/15/d-bus-in-the-kernel-f.../
Новость: http://www.opennet.me/opennews/art.shtml?num=27984
Если доделать дбас чтобы общение между процессами было без посредника, будет ещё лучше. И в ядро лезть не надо. ;)
Например, как это сделать?
>Например, как это сделать?Надо libastral подключить при компиляции.
$-))) +1024
>Например, как это сделать?Уже сделали. Local Domain Sockets называется.
1. Desktop-демон -- работая под Desktop-user-UID -- не сможет создать unix-сокет внутри /var/run/<...>(впринцепе это не особая проблема, так как unix-socket можно создать и в ~/.local/share/<...> . но всёже факт остаётся фактом: "неопределённость в пути к демону" . но DBus полностью решает эту проблему )
2. как осуществить авторизацию подключаемого процесса к unix-socket? ограничить socket-файл через "$ chgrp <...>" ? но ведь только super-пользователь может в полной мере пользоваться "$ chgrp <...>"! однако DBus решает эту проблему
3. необходимо заново придумать протокол трансляции RPC-запроса и RPC-ответа . у каждого демона будет свой собственный RPC-протокол ?
(ктото может возьмёт себе даже стандартный XML-RPC, ктото возьмёт JSON-RPC, а ещё есть SOAP от Microsoft!.. хотя ведь и всегда можно придумать чтото своё!)
...но в DBus УЖЕ есть механизмы трансляции RPC ! что плохого что все программы будут использовать один и тотже механизим RPC-трансляции ? ведь придётся меньше писать повторяемого программного кода!
так-что DBus и тут выигрывает! :-)
[а вызовы-и-сигналы проходящие через DBus -- можно мониторить! это же здорово!]
4. DBus чуть чуть медленее чем unix-socket ? настолько сильно чтобы его не использовать?
(например мне нада перередать через DBus сообщение о том чтобы не включалась Screensaver-заставка!.. очень прям важна тут супер-скорость-для-DBus ? :-D )
((а если мне нада применить новые конфигурации сети через DBus -- то тут тоже скорость-DBus является критичным узким местом?))
# p.s.: а почему на DBus взъелась куча народу? я вообще непойму?
неужеле это произолшо из-за того что кто-то пытался собрать [экспериментальную версию] SystemD, и SystemD отказался работать из-за не самого-нового-DBus ?
некоторые особо КРИВОРУКИЕ программаммисты вообще используют ОБЫЧНЫЕ сокеты в своих Desktop-демонах (не unix-сокеты и не DBus)...ничего хуже чем такой способ IPC -- даже и пдидумать нельзя :-( . запустить одновременно два разных рабочих стола в таком случае нелья! .
хотя DBus не создаёт таких ограничений (на каждый рабочий стол создаётся своя [не-системная] DBus-сессия)
SHM?
Безопасность не сильно пострадает?
модуль в блэклист и все дела.
серверам он не особо то нужен.
блииин, это самый кривой протокол какой только можно придумать. И его в ядро засунуть хотят :(.
работа на уровне ядра уже равно "запихнуть" в ядро?
Этот "кривой протокол" юзает куча софта.
>Этот "кривой протокол" юзает куча софта.А винды-то сколько человек юзает...
а сколько из них знают что такое com-объект...
Я знаю, я знаю.... это command.com на диске Ц:\
com-формат больше не поддерживается. :D
>com-формат больше не поддерживается. :DВаабще?!
попробуй.
потом расскажешь.
чем крив?
конструктивнее, тролли! конструктивнее.
кто юзал эти либы в C-проектах тот поймёт
я юзал.
и поверьте, писать com-объект в С++ (даже не С) - гораздо (в периоде) геморней.
не только. молодой человек привёл пример дкома, который просто напросто является COM + DCE/RPC http://ru.wikipedia.org/wiki/Component_Object_Model#DCOM
и видимо он не знает для каких платформ rpc является родной, откуда пришёл маршалинг, stab-функции, пул-потоков,...
а если он узнает откуда взялись GUID'ы и по какому алгоритму (и чьему) работает guidgen он видимо впадёт в ступор.
а если выживет, то его явно должна добить возможность реализации данной функциональности под виндами самому (http://www.rsdn.ru/article/files/libs/RPCLib.xml), ибо кому-то кажется, что com слижком медленный и не безопасный.
для интересующихся рекомендую посмотреть в конце статьи ссылки на литературы. есть очень знакомые фамилии.
на сайте с доками специально написано, что надо юзать не напрямую, а через биндинги для glib
>чем крив?Реалиазцией. Это очевидно.
бред.
реализацией он хорош.
пока сеть с шифрованием не до-делана.
Эээ а вы не хотите раскритиковав предложить на замену что-то лучше? Кривой или нет, но работает и юзается кучей софта. А то что нет предела совершенству - уже давно знает любой дятел.
>Эээ а вы не хотите раскритиковав предложить на замену что-то лучше?Какая еще замена Dbus? Это концепция сама по себе идиотична, ей не нужна замена, ее просто не должно быть.
>Кривой или нет, но работает и юзается кучей софта.
Windows юзается кучей софта. И именно что кучей, жирной и дымящейся. Сосбтвенно, кроме DE которым положено состоять из костылей более чем наполовину, нигде эта гадость не используется.
а её кто-то резко решил в сервера добавлять? (системд правда тут уже вспоминали, но на серверах мне гораздо больше нравится sys5r4 - дубово, надёжно, понятно)д-бас - отличное средство межпроцессного взаимодействия с сообшениями, событиями, обратным вызовом и т.д.
для всяких н900 и прочих подобных девайсов это также может стать отличным средством реаагирования для событий ядра.
ну и естесно оформленный в модуле он может быть просто не загружен.зы:
странное, безаппеляционное мнение. свобода - это не когда все делают, что тебе нужно. это когда ты можешь делать, что тебе нужно.
т.е. не хочешь - не пользуйся. это же не com какой-то.
>странное, безаппеляционное мнение. свобода - это не когда все делают, что тебе
>нужно. это когда ты можешь делать, что тебе нужно.
>т.е. не хочешь - не пользуйся. это же не com какой-то.Это ничем от com не отличается. И когда на него всё больше софта завязано от него также не откажешься.
3 поста подряд никакой конкретной критики, только вой "какой плохой". Ненужное мнение а не комментарии, завязывай.
>Это ничем от com не отличается.бред.
>Какая еще замена Dbus?Например какой-нибудь иной универсальный интерфейс IPC, более-менее общепризнанный и используемый, например. Или вы утверждаете что IPC must die как класс? Ну а допустим мы хотим сказать демону отвечающему за набор номера в телефоне что ему надо сделать то-то и то-то. Как это сделать стандартизированно, из любого процесса и прочая? Ну не скатываться же к AT-командам? Благо у сотового модема вообще может и не быть AT-команд. Что, эмулировать программмно? Вот это да, довольно бредовая затея.
>Это концепция сама по себе идиотична,
Если пихать во все дыры без разбора - может быть. А местами - смотрится довольно осмысленно. Поэтому концепция "D-bus must die" нуждается в некотором обосновании.
>ей не нужна замена, ее просто не должно быть.
Ну вон я пример выше привел. Реалистичный такой случай вполне. Нужный некоторым. Сделайте лучше, чтоли. Предложите иные технологии, менее корявые и более стройные, не в ущерб универсальности и документированности интерфейсов. Не хотите?
>>Кривой или нет, но работает и юзается кучей софта.
>Windows юзается кучей софта. И именно что кучей, жирной и дымящейся.Ну, собссно, поэтому есть wine. Кому-то нужен, кому-то нет. Орать что он должен умереть конечно можно, но лучше от его смерти станет все-таки не всем.
> Сосбтвенно, кроме DE которым положено состоять из костылей более чем
> наполовину, нигде эта гадость не используется.Я вон выше пример привел. Оно только так используется для взаимодействия с демонами и в какойнить n900 даже выглядит осмысленно. Во всяком случае скомандовать телефонной части нечто по D-Bus выглядит как-то логичнее и менее извратно чем разговаривать с ней же из своей программы AT-командами, отправляемыми специально для этого запущенному демону интерпретатора AT-команд, который делает вид что оно и правда типа стандартный модем с типа стандартными AT-командами, хотя это ни разу не. И софту было бы явно проще дернуть это через какой-то внятный стандартный IPC интерфейс чем изгаляться с AT-командами в двух местах (в программе которая их будет слать и в демоне который их будет разбирать обратно).
Вот и опеннет постигла судьба башорга - прогрессивная школота захватила ресурс.
>Это концепция сама по себе идиотичнаОбмен сообщениями между программами идиотичен? Ну-ну. Что еще сморозишь?
А ты сам какой прямой протокол специфицровал и реализовал?
Может COM?
Отлично. Еще один плюсик для systemd.
Этот демон нужен исключительно ради авторизации, зачем повышать скорость? Тут важнее безопасность.Для скорости надо юзать UNIX-сокеты/пайпы, если не хватает - отображения в память.
Ошибся - не только для авторизации, ещё для уведомления системы/пользователя о каком-то событии. Но всё равно я не вижу смысла в повышении скорости.
а теперь давай еще одну поправку, и чтоб правильно
лучше пусть молчит
Даёшь ядро с торрент-клиентом и видео-плеером!!!!
и с рецептом прошивки оного во все mp3-плейеры, включая айфоны, утюги, самовары.смех-смехом, но и этому может быть отличное применение.
>и с рецептом прошивки оного во все mp3-плейеры, включая айфоны, утюги, самовары.
>
>
>смех-смехом, но и этому может быть отличное применение.
Ага, ага, и переписанного на питоне
>Даёшь ядро с торрент-клиентом и видео-плеером!!!!Ну, как минимум HTTP сервер в ядро запихивали, IIRC...
и отлично работал кстати.
вот только статика без пыхпыхов и мускулей мало уже кому нужна.
Это кривой костыль. Межпроцессное взаимодействие всегда делалось через пайпы, unix domain sockets, и shared memory. Зачем тут нужен левый демон, совершенно не понятно - у меня удалены все dbus'овские бинаники, и даже тот софт который требует это гoвнецо при сборке, работает замечательно. Минус линуксу indeed, ядро становится убунтой.
вот так сможешь?
>Сервисы делают доступной ещё одну функцию — запуск необходимых приложений в случае поступления сообщений для них. Для этого должна быть включена автоактивация, а в конфигурации D-BUS за этим сервисом должно быть закреплено одно приложение. Тогда D-BUS сможет его запустить при появлении сообщения.
>После закрытия приложения ассоциированные сервисы также разрегистрируются, а D-BUS посылает сигнал о том, что сервис закрыт. Другие приложения могут получать такие сигналы и соответствующим образом реагировать.или будешь писать свой костыль под названием май-д-бас?
зы:
хотя, самое главное - не хочешь, не юзай.
вот выкинуть в виндах com с реестром не получится.
> вот так сможешь?А ты сможешь левой ногой за правым ухом почесать? Для всякой фичи должно быть применение, а то что ты написал - бред.
> хотя, самое главное - не хочешь, не юзай
> вот выкинуть в виндах com с реестром не получитсяРовно также как и выкинуть в Gnome/KDE dbus не получится. Скоро оно будет в ядре. А насчет реестра - gconf из гнома тоже не особо выкинешь.
>А ты сможешь левой ногой за правым ухом почесать? Для всякой фичи должно быть применение, а то что ты написал - бред.да вы батенька просто профан.
>А насчет реестра - gconf из гнома тоже не особо выкинешь.как страшно жить.
ядро линуха не стартанёт без fstab (реестр монтируемых фс, включая рут)
сеть в дебиане не стартанёт без /etc/network/interfaces (реестр интерфейсов)
и тд, и тп.
включая бедные текстовые файлы с xml внутри для gconf.
а если /etc удалить - О-О-О!!!!назвать gconf реестром (вернее, сравнить gconf с виндовым реестром, как с технологией; т.к. само слово "реестр" ничего не значит. им может быть простой текстовой файл) может только полностью и окончательно упоротый вантузятник.
не поверишь но и у гнома, и у кед всегда были подобные альтернативы.
http://ru.wikipedia.org/wiki/D-Bus
>В графической среде KDE для этого не так давно использовался DCOP
>Раньше GNOME использовал Bonobo, основанный на CORBA, но из-за зависимости от GObject, Bonobo не использовался в других рабочих средах, а низкое быстродействие CORBA сказывалось на скорости всей среды.представляешь, из ГНОМа нельзя было выбросить CORBA!!! а ты знаешь что такое CORBA?
виндусячий реестр - это так, детская игрушка, планарный файл.
какое несчастье для тупого тролля!
>Это кривой костыль. Межпроцессное взаимодействие всегда делалось через пайпы, unix domain sockets,
>и shared memory.Ну и как мне стандартным методом узнать допустим заряд батарейки от демона заведующего этим в моем телефоне? Это надо точно знать какой сокет и т.п. + никто не удосужился выработать для этого стандартный протокол мля. В итоге - поди туда не знаю куда, найди то не знаю что а потом поработай с ним по протоколу который никто не знает. В D-Bus как минимум часть аспектов таких проблем пытаются адресовать.
>Ну и как мне стандартным методом узнать допустим заряд батарейки от демона заведующего этим в моем телефоне? Это надо точно знать какой сокет и т.п. + никто не удосужился выработать для этого стандартный протокол мляМожно подумать, в dbus не нужно указывать интерфейс, имя свойства, тип данных и прочая.
вы наверное в браузере исключительно ip-адреса набираете.
>Ну и как мне стандартным методом узнать допустим заряд батарейки от демона заведующего этим в моем телефоне?$ cat /proc/acpi/battery/BAT0/state
а если так, чтобы он сам прислал уведомление, когда заряд <10%?
при чём заранее не известному количеству программ.
и это только с аккумулятором. а там ещё и связь - wifi, gps, gsm, 3g,..
не опрашивать же в цикле в каждой такой проге? так ресурсов не напасёшься
Ждём новых дыр."Отправив специальным образом оформленное уведомление через DBUS приложение может получить полный доступ к памяти".
подпись - толпа анонимного андеграунда.
Проясните, а зачем нужен Dbus когда есть System V message queues/Posix message queues?
А разве для queues не нужен такой же отдельный менеджер как dbus? :]
Им ядро выступает.
Более высокий уровень абстракции
>Проясните, а зачем нужен Dbus когда есть System V message queues/Posix message
>queues?Ну вот захотели чтобы обязательно демон висел и память жрал.
>>Проясните, а зачем нужен Dbus когда есть System V message queues/Posix message
>>queues?
>
>Ну вот захотели чтобы обязательно демон висел и память жрал.если память не используется (например DBus-демон загружен но не используется) -- то при её нехватке она выгрузиться в SWAP!
...а вы-то наверно не знали этого? да? :-) , думаете что если программа загруженна то значит она обязательно создаёт тормаз в системе? :-D :-D :-D
а еслиже программа загружена в системе и РАБОТАЕТ (например демон которого кто-то использует) -- значет эта программа кому-то понадобилась.. и значит её ТЕМБОЛЕЕ нельзя отключать
такчто все аргументы про оперативную память (и ресурсы CPU) -- сразу отклоняются.
сделайте подольше размер SWAP-файла и не парьте другим нормальным людям мозги# p.s.: я знаю что всегда находиться группа людей которых можно отнести к классу "оптимизаторы". они пытаются оптимизировать всё что угодно :-).. вот только методы оптимизации выбирают те которые больше похожи на "религиозные обряды" нежеле на чтото действующее. а тэсты оптимизации (после каждого "религиозного обряда") конешно же не проводятся, всё только на глазок!
> Проясните, а зачем нужен Dbus когда есть System V message queues/Posix message queues?D-Bus фиксирует формат сообщений, а системные message queues — нет, поэтому обменятья сообщением между двумя заранее неизвестными программами через message queues невозможно, поскольку они не знают в каком формате друг у друга передаются и принимаются сообщения.
>D-Bus фиксирует формат сообщений, а системные message queues — нет, поэтому обменятья
> сообщением между двумя заранее неизвестными программами через message queues невозможно,
> поскольку они не знают в каком формате друг у друга передаются и принимаются сообщения.Офигеть, а ядро и не должно знать, что через него прогоняется, это общий механизм(и это правильно с точки зрения масштабируемости). Пусть пихают, линукс давно превратился в помойку.
вах. теперь видимо я должен отказаться от шифрования данных и отправки их по tcp.
и срочно, срочно нужно выкинуть из ядра поддержку сокетов AF_UNIX!
да что там! выкинуть нафиг всю сеть, все ipc и прочий хлам.
иначе помойка в головах троллей опустеет и они умрут с голода.
>D-Bus фиксирует формат сообщенийКто мешает сделать либу, которая будет этим заниматься?
Ну вот и сделали. Называется D-Bus.
>Ну вот и сделали. Называется D-Bus.А демон зачем? Для густоты мыслей?
http://dbus.freedesktop.org/doc/dbus-daemon.1.html
>dbus-daemon is the D-Bus message bus daemon. See http://www.freedesktop.org/software/dbus/ for more information about the big picture.
>D-Bus is first a library that provides one-to-one communication between any two applications;
>dbus-daemon is an application that uses this library to implement a message bus daemon. Multiple programs connect to the message bus daemon and can exchange messages with one another.
>Для густоты мыслей?именно.
ещё раз. большей концентрации - D-Bus is first a library that provides one-to-one communication between any two applications;
>ещё раз. большей концентрации - D-Bus is first a library that provides one-to-one communication between any two applications;Создаётся обычный сокет, инфа тупо пересылается. Одно приложение передаёт, другой получает. Задача решена?
а нахрена тогда апачи всякие придумали? или там к примеру постфиксы, довекоты?
есть же tcp/ip?нет. не решена. d-bus - это шина сообщений. ipc - это только его побочная функция. которая кстати на никсах сводится к uds. да посмотрите уже хоть мельком доку! http://dbus.freedesktop.org/doc/dbus/api/html/modules.html
DBusServerDebugPipe
DBusServer implementations for SOCKET
DBusServer implementations for UNIX
DBusServer implementations for Windows
DBusServer implementation details
SHA implementation................
"нахрена kde если есть qt? нахрена qt если есть иксы? нахрена иксы если есть fb?"
честное слово, надоело уже отвечать на такие глупые вопросы.
>а нахрена тогда апачи всякие придумали? или там к примеру постфиксы, довекоты?Да, в теме про dbus они явно лишние.
>да посмотрите уже хоть мельком доку!И что? Посмотрел, ничего нового не увидел.
>честное слово, надоело уже отвечать на такие глупые вопросы.Может для начала не стоит их задавать? А просто ответить на главный вопрос, что можно сделать такого в dbus, чего нельзя без него. Особенно в плане демона, от которого зависит куча программ.
>И что? Посмотрел, ничего нового не увидел.печально.
>Может для начала не стоит их задавать?ну так и не задавайте.
>А просто ответить на главный вопрос, что можно сделать такого в dbus, чего нельзя без него.уже писал - http://www.opennet.me/openforum/vsluhforumID3/70688.html#55
>Особенно в плане демона, от которого зависит куча программ.вы плохо читаете? то что функциональность демона перенесена в ядро, не значит что этой функциональности нет. оформь поддержку tcp в ядре модулем и помести его в блэклист. удивишься сколько программ не заработают. или проделайте к примеру с увомянутым вами UDS.
отсюда и сабж - поместить в ядро поддержку нового типа сокета AF_DBUS и демон, по крайней мере на линухе, бкдет не нужен. обратное тоже верно - уберите поддержку типа сокета AF_UNIX и для работы UDS придётся писать демон. тоже самое и с tcp, udp, ppp.
а если всю функциональность (большинство) вытащить из ядра и переместить в демоны, то это и будет панацея анонимов - микроядро.
>вы плохо читаете? то что функциональность демона перенесена в ядро, не значит что этой функциональности нет. оформь поддержку tcp в ядре модулем и помести его в блэклист. удивишься сколько программ не заработают. или проделайте к примеру с увомянутым вами UDS.отсюда и сабж - поместить в ядро поддержку нового типа сокета AF_DBUS и демон, по крайней мере на линухе, бкдет не нужен. обратное тоже верно - уберите поддержку типа сокета AF_UNIX и для работы UDS придётся писать демон. тоже самое и с tcp, udp, ppp.
а если всю функциональность (большинство) вытащить из ядра и переместить в демоны, то это и будет панацея анонимов - микроядро.
Товарищ, вы читать умеете? Я задал вполне конкретный вопрос по конкретной реализации. Что там в tcp, udp, ppp меня мало интересуют.
этот что-ли?
>Создаётся обычный сокет, инфа тупо пересылается. Одно приложение передаёт, другой получает. Задача решена?ответ уже был - нет, не решена.
приложений много. и все клиенты.
>Товарищ, вы читать умеете????
>>D-Bus фиксирует формат сообщений
> Кто мешает сделать либу, которая будет этим заниматься?libdbus
DBUS - это не только формат сообщений, просвящайся http://dbus.freedesktop.org/doc/dbus-tutorial.html , http://ru.wikipedia.org/wiki/D-Bus
>DBUS - это не только формат сообщенийНо и нужный демон, который уменьшает потребление памяти и увеличивает стабильность. Прям на сервер сам так и просится.
ещё раз: http://www.rsdn.ru/article/files/libs/RPCLib.xml
>D-Bus is first a library that provides one-to-one communication between any two applications; dbus-daemon is an application that uses this library to implement a message bus daemon. Multiple programs connect to the message bus daemon and can exchange messages with one another.либо поддержка на уровне ядра, как в ipc (к примеру выделенная память в shm не исчезает даже если все использующие её процессы закрылись. освобождать её надо самостоятельно. внимание вопрос - кто управляет этой памятью? в чьём адресном пространстве она находится, если все процессы убиты?), либо демон, если поддержка этого механизма идёт на пользовательском уровне.
>Прям на сервер сам так и просится.ирония не уместна. ибо глупа. с таким же успехом вы могли бы выступать, что ipc, rpc, POSIX (mmap, message queues, semaphores) и пр. не_нужны. и их срочно нужно выкинуть из ядра. d-bus же ещё предоставляет и обратную связь в виде эвентов.
если демоны запихнуты в ядро, то уже никто не кричит не_нужна - такая у вас логика что ли?
>ирония не уместна. ибо глупа.Что же тут сказать. Ну просто убийственные аргументы и тупое обобщение. Таким образом наплодиться ещё 9000 демонов оправдать под предлогом "да с таким же успехом можно mmap выкинуть".
я думал вы несколько умнее. по-крайней мере знаете понятия ааналогия и моделирование.
зы:
вам не нравятся демоны? :D
сабж исправит ваше невежество - его не будет. будет модуль ядра.
вы довольны? :D
>... Таким
>образом наплодиться ещё 9000 демонов оправдать под предлогом "да с таким
>же успехом можно mmap выкинуть".ты идиот! если эти 9000 демонов используются -- значит они нужны!
а если ты решил что вместо DBus можно использовать просто unix-socket -- то идиот вдвойне, так как DBus как раз и работает через unix-socket!
(кроме того DBus выполняет сервисные функции которые НУЖНЫ тем приложениям которые взаимодействуют через DBus. а иначе бы эти программы не работали бы через DBus)
+к тому DBus НЕ загружается для каждой DBus-программы в индивидуальном порядке, так что агрмент "зачем мне чтобы висел дополнительный сервис в системе?" -- не принимается так как дополнительный сервис И НЕ ВИСИТ для каждой из DBus-программ
(DBus загружается ТОЛЬКО ОДИН РАЗ для всех обслуживаемых программ... а НЕ ИНДИВИДУАЛЬНО для каждой из программы. так понятнее?)
Фитча дельная. Ждем по-дефолту в Fedora 24.
А смысл в этом дбус? Есть unix domain socket, простой, удобный, быстрый.
Да и воообще, если кто-то захочет урпавлять софтиной под dbus через cron, то того ожидает сюрприз.
>Да и воообще, если кто-то захочет урпавлять софтиной под dbus через cron,
>то того ожидает сюрприз.И что ж за сюрприз? И что значит "управлять через cron"?
> И что ж за сюрприз?сюрприз наверно заключается в том что ...
"ВСЁ РАБОТАЕТ! о боги! я думал оно не будет работать а оно работает!!!":-)
потребности приложений не ограничиваются проблемой "как два байта переслать при участии в пересылке не более 2 процессов".
>потребности приложений не ограничиваются проблемой "как два байта переслать при участии в
>пересылке не более 2 процессов".Вот честно, не знал, что UDS такой убогий.
он не убогий. он вполне себе ничего.
просто UDS - это IPC. а D-Bus - это message bus system, a simple way for applications to talk to one another. In addition to interprocess communication. http://www.freedesktop.org/wiki/Software/dbus#Documentation
кстати, на платформах *nix он использует именно UDS:
int _dbus_connect_unix_socket ( const char * path,
dbus_bool_t abstract,
DBusError * error
)
Creates a socket and connects it to the UNIX domain socket at the given path.
http://dbus.freedesktop.org/doc/dbus/api/html/group__DBusSys...
ps:
ваши сентенции логичны примерно как это утверждение - "нарена http (и тем более web-сервера), если есть tcp/ip?"
>ваши сентенции логичны примерно как это утверждение - "нарена http (и тем более web-сервера), если есть tcp/ip?"Честно, я не где не видел, чтобы поднималось два сервера. Один для tcp, а другой для http.
потому что tcp уже есть в одном, но ОЧЕНЬ важном сервере под названием ядро.
и к тому же - apache, dovecot, postfix, inetd, - всё это сплошь tcp сервера. все они сплошь сидят на портах tcp. ибо портов в http нет.
>потому что tcp уже есть в одном, но ОЧЕНЬ важном сервере под
>названием ядро.С каких это пор ядро стало сервером?
>и к тому же - apache, dovecot, postfix, inetd, - всё это сплошь tcp сервера. все они сплошь сидят на портах tcp. ибо портов в http нет.Зачем они вообще нужны. У нас же ядро tcp-сервер!
а что такое сервер?
вы вообще знаете определение?
>а что такое сервер?
>вы вообще знаете определение?Я знаю, что межпроцессорное взаимодействие реализуется несколькими строчками на си без всяких dbus-ов и торчащих в памяти демонов. Мне этого достаточно.
d-bus - не ipc. ipc в d-bus дополнительная возможность.
но я уже это писал. у вас склероз?
>несколькими строчками на си без всяких dbus-ов и торчащих в памяти демонов.если вместо демона в памяти торчит модуль, вам спится легче?
так что такое сервер?
>так что такое сервер?сервер - программа, находящаяся в режиме готовности и выполняющая запросы других программ. Устроит? Повторяю вопрос. Что там такие за запросы, что у меня на локальной машине невозможно выполнить без сервера. А то ведь просто до смешного доходит. Спрашиваю одно и тоже третий раз, а мне какой-то бред про http/tcp.
не верно. http://ru.wikipedia.org/wiki/%D0%A1%D0%B...
>Се́рвер (англ. server от англ. to serve — служить) (множественное число се́рверы) — в информационных технологиях — программный компонент вычислительной системы, выполняющий сервисные (обслуживающие) функции по запросу клиента, предоставляя ему доступ к определённым ресурсам или услугам.отсюда вывод - где бы сервер не был, в ядре или в юзер-спэйс демоне, не имеет значения с функциональной точки зрения.
и да, любой, это конечно новость для вас, ipc - это сервер. и использует ресурсы системы вне зависимости от того находится он в ядре или в демоне.
> ipc - это сервер. и использует ресурсы системы вне зависимости от того находится он в
> ядре или в демоне.
>да без смысленно объяснять.. онже сказал что для него главный критерий (сервер или не сервер) -- это количество строчек на ЯП Си :-)
если строчек мало -- то значит не сервер. если много строчек -- то сервер :-) :-)
>А смысл в этом дбус? Есть unix domain socket, простой, удобный, быстрый.
>а по твоему DBus работает через волшебство :-D ?
СЮРПРИЗ(!!): DBus как раз и использует unix domain socket :-)
с таким же успехом можно сказать:
"зачем делать сайты на Django/Pylons, если можно просто использовать Python"
меня вообще бесит, когда треш остаётся в таблице процессов после запуска невинной с виду гуйни, никогда не приветствовал этой ерунды. В момент запуска дбас кде писало на сплашскрине "настраиваю оборудование", или что-то в этом роде, одна из ряда гыгышек, по которым стало ясно, что с сверинтеллектуальными десктопа пора завязывать.
когда трэшь остаётся -- это фигово :-( .. например программа ("родитель") может "забыть" доубить "мёртвый" дочерний процесс, и при выходе "родителя" останется трэш (ввиде "зомби")[разумеется это не может не бесить! в этом случае нада срочно писать Bug_Report!! С-Р-О-Ч-Н-О]
...однако как это касается темы DBus -- я не понимаю %) %) ... ведь DBus это же не трэш
Почему dbus не нужен.Недостатки: посредник в виде демона, привязка к сессии пользователя, из-за чего тупо сделать dbus-send -//- из-под другого пользователя не представляется возможным.
UDS от этого недостатка свободен. Если уж так влом парсить мессагу, то ни кто не мешает сделать либу, которая будет формировать и парсить сама.
Зачем тащить весь этот хлам, непонятно.
uds мягко говоря (очень мягко) уровнем (или 2-мя) ниже. если сравнить их по аналогии с OSI, то d-bus - это пользовательский уровень, а UDS - канальный.
>Зачем тащить весь этот хлам, непонятно.это от невежества. что-то типа: "почему юникс не нужен. недостатки: посредник между программами и ядром в виде X, привязка к сессии пользователя, из-за чего тупо сделать rm -rf / из-под другого пользователя не представляется возможным.
вин95 от этого недостатка свободен. зачем тащить весь этот хлам, непонятно."
>Если уж так влом парсить мессагу, то ни кто не мешает сделать либу, которая будет формировать и парсить сама.ктаая либа есть. про неё уже говорили - D-Bus is first a library that provides one-to-one communication between any two applications; dbus-daemon is an application that uses this library to implement a message bus daemon. Multiple programs connect to the message bus daemon and can exchange messages with one another.
http://dbus.freedesktop.org/doc/dbus-daemon.1.html
пример - есть протокол http, есть демон http. первый из них может существовать и без второго.
что не говорит о том, что второй не_нужен.
>uds мягко говоря (очень мягко) уровнем (или 2-мя) ниже. если сравнить их по аналогии с OSI, то d-bus - это пользовательский уровень, а UDS - канальный.
> "почему юникс не нужен. недостатки: посредник между программами и ядром в виде X, привязка к сессии пользователя, из-за чего тупо сделать rm -rf / из-под другого пользователя не представляется возможным.вин95 от этого недостатка свободен. зачем тащить весь этот хлам, непонятно."
Ну и опять глупые аналогии. Конкретики, похоже, не дождусь.
>пример - есть протокол http, есть демон http. первый из них может существовать и без второго.И что? Есть клиент-сервер, как 2-е разные сущности. Межпроцессорное взаимодействие - тоже самое программа-клиент и программа-сервер. Ничего лишнего, вот только в случае dbus откуда-то появляется ещё и третья, необходимость который ничем не подкреплена.
попробуй представить, троляря, что сервер из твоего примера написал Ганс из Германии, а клиента - Педро из Бразилии. Представил? а теперь представь что они абсолютно не знают о разработках друг друга. сервер пишет в юникс сокет бинарник, а клиент xml. чо получится?
вопрос - по какому протоколу они общаются?
далее - представь что таких серверов много и клиентов много. и все хотят общаться друг с другом и по очереди, и со всеми сразу, и по другим гендерным признакам. представил? способен вообще представить такое? и чтоб все знали куда долбится? и чтобы интроспекция (для подобных умников - http://ru.wikipedia.org/wiki/%D0%98%D0%B... была? и чтобы очередь соблюдалась? и протокол все понимали? и ошибки отрабатывались?
вот для этого умные люди придумали сервера и протоколы прикладного уровня. те которые часто бывают оформлены в виде демонов.
а теперь представь, что апач назвали d-bas, работает он через твои долбанные юникс сокеты (да и все остальные тоже), протокол общения имеет четкий вид, но не http, а через low-level message-passing protocols such as UDP. вот тогда ты смутно поймёшь какую херню ты тут нёс.
но это врядли. тебе и так супер доходчиво пытались объясняли.
1. Вы надеетесь, что имея чёткий формат клиент-серверного взаимодействия в лице дбас, вы сможете любым клиентом общаться с любым сервером - это фикция,миф. Любой клиент имеет некоторое представление о сервере, с которым собирается работать - равно и сервер.2. Что за ситуация, где "таких клиентов много и серверов много" на одной локальной машине?? что это за бред??
1. не с любым, а с тем, который знает этот же протокол же протоколу, принципу. более того - уже общаюсь.
более того, имею опыт работы и с другими альтернативами. и они тоже работают.
вот их список - http://en.wikipedia.org/wiki/D-bus#See_also например
RPC - Remote procedure call, CORBA Common Object Request Broker Architecture, GNOME Bonobo deprecated GNOME cross language Object Model, KDE DCOP deprecated KDE interprocess and software componentry communication system, DCOM Distributed COM, extension making COM able to work in networks....
вы считаете всех изобретателей этих "велосипедов" идиотами? и "зачем они нужны, если есть UDS"?
2. ну во-первых это не ограничивается только локальной машиной (в d-bus правда это ещё не доделано),
второе - у вас вызывает шок работа >2 приложений (клиентов) на одной машине, которые бы хотели получать уведомления в онлайн? хм. вы вообще с компьютерами работаете? пример - сеть wifi. пропажу её (или даже изменение некоторых сосотояний) хотели вы видеть одновременно нетвокмэнеджер, пиджин, skype. и всё это только клиенты.
ещё раз повторю аналогию - d-bus построен поверх uds точно также, как апач поверх tcp/ip.
при чём аналоги в гноме и кедах были всегда (см. список и ссылку выше).
при этом uds не единственный использующийся механизм для построения шины сообщений.
впрочем, всё это я уже говорил - http://www.opennet.me/openforum/vsluhforumID3/70688.html#99
как и то, что утверждать, что uds это эамена d-bus, это всё равно что утверждать что tcp/ip замена apache.
и кидаться такими утверждениями может только полный профан, который не понимает даже о чём вообще идёт речь.
1. Ответ, в котором используются уважительные обращения вида "профан", "работаете ли вы с компьютерами" априори неверен, но всё-таки дам вам некоторый ликбез по "изменению состояния вай-фай и нетворк-менеджер + пиджин + скайп"Какой бы не был статус вай-фай, пиджину и скайпу нужно только одно: доходит ли пакет до адресата. Всё. Ни роутинг, ни количество интерфейсов, ни тип подключения, это - не их дело.
Далее, нетворк-менеджер, это что такое вообще? Рискну предположить, что это некий демон, имеющий "удобный гуи-клиент" для облегчения конфигурации сети в системе. Так вот, внимание, присядьте, товарищ специалист по актив-икс/ком/корбе... Ему в линукс/бсд/любом юниксе никакой d-bus по определению не нужен. Даже если бы и была возможность работы по д-бас всех пользовательских конфигурационных надстроек над ядром, это не было бы лучшей идеей для контроля сети попросту ввиду избыточности лишнего звена."Поработайте с компьютерами"?
какое бы обращение я не выбрал - это не изменит технологию.
тем более что оно верное.пиджин и скайп подстраивают видеопоток в зависимости от параметров сети.
более того, они уже используют d-bus.
а все ваши знания об этом на уровне профана. ваше упорство, безапелляционность и высокомерие (Рискну предположить, что это некий демон, имеющий "удобный гуи-клиент") - на уровне идиота.
Вижу, вы согласны с несостоятельностью вашего примера. "уровень идиота и высокомерие" - это нежелание опускаться до ваших оскорблений? Сколько у вас было примеров удачного использования д-бас, приведите их. Могу предположить, что в каждом случае использования был более верный вариант, вы же, использовав свои мнимые достоинства как специалиста с опытом актив-икс/ком, заточились на аналог ком - тем самым отсекая возможность быстрого решения проблем с вашими модулями другими разработчиками.
так и не понять разницу между компонентной моделью разработки, и шиной сообщений после того, как ему 100500 раз объяснили, может только хронический идиот.
>Могу предположить, что в каждом случае использования был более верный вариант, вы же, использовав свои мнимые достоинства как специалистауже привёл. несколько раз. см. выше.
предоставь им альтернативу. или в сад. детский.
зы:
твоё резюме ниже я просмотрел. :D
ответ? ну я видел и более серьёзных сказочников.
и хорошо, что испытательный срок в кзоте всё же есть.адиос, амиго. удачи твоим работодателям.
1. Смешной пример про пиджина, скайп и "нетворк менеджер"а, узнающих "параметры сети" по д-бас: в реальности, для выставления верного видеопотока необходим реальный бенчмарк тестовой "прокачки" между двумя клиентами. Если пиджин и скайп будут рассчитывать возможный битрейт потока по данным от д-бас, то подключение в 90%% сетей вай-фай будет мнимо хорошим, видиопоток будет выбран неверно.2. Новый поток оскорблений - это, скорее всего, ваша попытка самореализоваться в виртуальном мире. Не могу ответить сочувствием, желать удачи в этом - тоже не стоит. Оглянись на то, что ты уже написал, оцени, сбей спесь.
> Если пиджин и скайп будут рассчитывать возможный битрейт потока по данным от д-бас, то подключение в 90%% сетей вай-фай будет мнимо хорошим, видиопоток будет выбран неверно.ты сам придумал глупость и сам ее опровергнул.
Это пример был рассказан выше "анонимом", под которым я не дописывался ни разу.
Единственно, что *будто бы* облегчит использование д-бас - это портирование специфичных системных фишек типа "запрос текущего разрешения экрана". В несуществующем идеальном мире был бы написан "сервер", который отвечал бы на запрос "дай мне размерности экрана", и разработчики конечного приложения не парились бы, каким образом это делается на конкретной системе. В реальности вот это деление - нереализуемый миф, по разным причинам.Поэтому неудивиельно, что человек, который восторженно описывал д-бас упоминал всякие виндовые ком/корбы/актив-икс, видать в реальности уже были отмазки на вопрос "а почему у нас то-то так-то??" вида " да тут по д-бас кто-то прислал неверные данные разбираюсь кто это сделал. Пока в ядро не вынесли дбас - это трудно делать, это же линукс"
>какое бы обращение я не выбрал - это не изменит технологию.
>тем более что оно верное.
>
>пиджин и скайп подстраивают видеопоток в зависимости от параметров сети.
>более того, они уже используют d-bus.
>а все ваши знания об этом на уровне профана. ваше упорство, безапелляционность
>и высокомерие (Рискну предположить, что это некий демон, имеющий "удобный гуи-клиент")
>- на уровне идиота.и да, я не знаю, что вы имеете в виду под "нетворк менеджер"ом.
Опыт программирования под линукс - 7 лет, до этого мимолётно затронул виндоус, даже успешно прошёл курсы от сибосс, кто знает, тот в теме. Интересно отметить, что когда ещё позиционировал себя под разработку виндоус приложений, как раз думал прикупить томик-кирпич по Com, ввиду следующего соображения - "технология-то одна, а названий красивых много, резюме солиднее будет смотреться". Да, так и думал, честное слово.
"Профан, уровень идиота" - спасибо за эти слова.
> Опыт программирования под линукс - 7 летвобщемто если работаешь программистом -- то нада не только программульки писать, но и развиваться изредка (повышать свой уровень)
[конешно я знаю что работа программистом зачастую настолько обременительная :-( что просто НЕКОГДА развивать себя. оттачивать навыки программирования ЯП Си это хорошо(!), но в будущем можно заметить даже будучи супер-мега-грамотным-программистом на ЯП Си -- без знания современных unix-технологий уже сложновато]
...а иначем можно и 30 лет пробыть идиотом-программистом :-)
как например щаз досих пор в моём городе существуют дядьки которые пишут [госудерственные] программы под FoxPro (for MSDOS) .. и пишут их не менее 15 лет [никаких других технологий.. и уж точно DBus -- они не знают и знать не хотят :-)]
>Почему dbus не нужен.
>
>Недостатки:
> посредник в виде демонавы так говорите будтобы этот посредник загружается КАЖДЫЙ_РАЗ для КАЖДОГО DBus-соеденения :-D
а то что ядро загружено -- это вас не смущщает? оно ведь [точно такой же] посредник
> привязка к сессии пользователя, из-за чего тупо сделать dbus-send -//- из-под другого пользователя не представляется возможным.
извините, но в МНОГОПОЛЬЗОВАТЕЛЬСКОЙ операционной системе -- мне НЕХОТЕЛОСЬ-БЫ чтобы другие пользователи чтото посылали моей сессии [или если-бы недавали-бы мне загружать мои desktop-сервисы: типа "извените но номер socket-порта уже занят другим пользователем"]
(для всего остального есть СИСТЕМНАЯ сессия DBus .. короче читайте руководства по Dbus)
если же лично-ВАМ не нравиться многопользовательская парадигма [или вы её немного не понимаете?] -- запускайте всё внури только одного пользователя :-)
> UDS от этого недостатка свободен.
правда? :O
хотите сказать что если один пользователь сделал unix-сокет внутри "$HOME/.local/share/my-desktop-service.socket" -- то другой пользователь может подключиться в этому сокету? (даже если права "$HOME" выставлены как 700 ?)
кстате, ничего страшного что -- DBus работает как раз работает через UDS??? :-D :-D :-D
> Если уж так влом парсить мессагу, то ни кто не мешает сделать либу, которая будет формировать и парсить сама.
либа называется libdbus :-) .. уже создали
> Зачем тащить весь этот хлам, непонятно.
а зачем тащщить ТВОЮ либу которая будет "парсить сама". твоя либа лучше чем libdbus? чем же, интересно? :-)
а еслибы ты был хорошим/опытным программистом [или вообще -- программистом. я к сожелению незнаю являешьсяли ты им %)] -- то тебе было бы понятно "Зачем тащить весь этот хлам".
...было бы понятно что функционал обычных UDS -- довольно ХОРОШИЙ.. но нехватает ещё пару унифицированных элементов, которые как раз предоставляет DBus [который в свою очередь работает через ТВОЙ_ЛЮБИМЫЙ(!) UDS]