URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 70688
[ Назад ]

Исходное сообщение
"Представлена реализация шины D-Bus, работающая на уровне Lin..."

Отправлено opennews , 16-Сен-10 17:26 
Разработчики из компании 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


Содержание

Сообщения в этом обсуждении
"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено svn , 16-Сен-10 17:26 
Если доделать дбас чтобы общение между процессами было без посредника, будет ещё лучше. И в ядро лезть не надо. ;)

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено xxx , 16-Сен-10 17:50 
Например, как это сделать?

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено Аноним , 16-Сен-10 18:01 
>Например, как это сделать?

Надо libastral подключить при компиляции.


"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено max , 16-Сен-10 19:40 
$-))) +1024

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено anonymous , 17-Сен-10 15:40 
>Например, как это сделать?

Уже сделали. Local Domain Sockets называется.



"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено Аноним123321 , 19-Сен-10 21:05 
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 ?


"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено Аноним123321 , 19-Сен-10 21:11 
некоторые особо КРИВОРУКИЕ программаммисты вообще используют ОБЫЧНЫЕ сокеты в своих Desktop-демонах (не unix-сокеты и не DBus)

...ничего хуже чем такой способ IPC -- даже и пдидумать нельзя :-( . запустить одновременно два разных рабочих стола в таком случае нелья! .

хотя DBus не создаёт таких ограничений (на каждый рабочий стол создаётся своя [не-системная] DBus-сессия)


"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено Аноним , 16-Сен-10 21:12 
SHM?

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено Аноним , 16-Сен-10 17:52 
Безопасность не сильно пострадает?

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено аноним , 16-Сен-10 19:35 
модуль в блэклист и все дела.
серверам он не особо то нужен.

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено Одмин , 16-Сен-10 17:53 
блииин, это самый кривой протокол какой только можно придумать. И его в ядро засунуть хотят :(.

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено Dcow , 16-Сен-10 18:00 
работа на уровне ядра уже равно "запихнуть" в ядро?

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено devl547 , 16-Сен-10 18:00 
Этот "кривой протокол" юзает куча софта.

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено Одмин , 16-Сен-10 18:19 
>Этот "кривой протокол" юзает куча софта.

А винды-то сколько человек юзает...


"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено аноним , 16-Сен-10 19:32 
а сколько из них знают что такое com-объект...

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено pavlinux , 16-Сен-10 19:53 
Я знаю, я знаю.... это command.com на диске Ц:\

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено аноним , 16-Сен-10 21:32 
com-формат больше не поддерживается. :D

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено pavlinux , 17-Сен-10 00:37 
>com-формат больше не поддерживается. :D

Ваабще?!


"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено аноним , 17-Сен-10 03:03 
попробуй.
потом расскажешь.

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено аноним , 16-Сен-10 18:10 
чем крив?
конструктивнее, тролли! конструктивнее.

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено Одмин , 16-Сен-10 18:18 
кто юзал эти либы в C-проектах тот поймёт

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено аноним , 16-Сен-10 18:21 
я юзал.
и поверьте, писать com-объект в С++ (даже не С) - гораздо (в периоде) геморней.

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено аноним , 16-Сен-10 22:01 
не только. молодой человек привёл пример дкома, который просто напросто является 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 слижком медленный и не безопасный.
для интересующихся рекомендую посмотреть в конце статьи ссылки на литературы. есть очень знакомые фамилии.

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено Аноним , 16-Сен-10 21:13 
на сайте с доками специально написано, что надо юзать не напрямую, а через биндинги для glib

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено anonymous , 17-Сен-10 15:41 
>чем крив?

Реалиазцией. Это очевидно.



"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено аноним , 18-Сен-10 05:01 
бред.
реализацией он хорош.
пока сеть с шифрованием не до-делана.

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено User294 , 16-Сен-10 19:12 
Эээ а вы не хотите раскритиковав предложить на замену что-то лучше? Кривой или нет, но работает и юзается кучей софта. А то что нет предела совершенству - уже давно знает любой дятел.

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено аноним , 16-Сен-10 21:28 
>Эээ а вы не хотите раскритиковав предложить на замену что-то лучше?

Какая еще замена Dbus? Это концепция сама по себе идиотична, ей не нужна замена, ее просто не должно быть.

>Кривой или нет, но работает и юзается кучей софта.

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


"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено аноним , 16-Сен-10 22:13 
а её кто-то резко решил в сервера добавлять? (системд правда тут уже вспоминали, но на серверах мне гораздо больше нравится sys5r4 - дубово, надёжно, понятно)

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

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


"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено аноним , 17-Сен-10 00:00 
>странное, безаппеляционное мнение. свобода - это не когда все делают, что тебе
>нужно. это когда ты можешь делать, что тебе нужно.
>т.е. не хочешь - не пользуйся. это же не com какой-то.

Это ничем от com не отличается. И когда на него всё больше софта завязано от него также не откажешься.


"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено szh , 17-Сен-10 01:32 
3 поста подряд никакой конкретной критики, только вой "какой плохой". Ненужное мнение а не комментарии, завязывай.

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено аноним , 17-Сен-10 01:55 
>Это ничем от com не отличается.

бред.


"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено User294 , 17-Сен-10 17:45 
>Какая еще замена Dbus?

Например какой-нибудь иной универсальный интерфейс IPC, более-менее общепризнанный и используемый, например. Или вы утверждаете что IPC must die как класс? Ну а допустим мы хотим сказать демону отвечающему за набор номера в телефоне что ему надо сделать то-то и то-то. Как это сделать стандартизированно, из любого процесса и прочая? Ну не скатываться же к AT-командам? Благо у сотового модема вообще может и не быть AT-команд. Что, эмулировать программмно? Вот это да, довольно бредовая затея.

>Это концепция сама по себе идиотична,

Если пихать во все дыры без разбора - может быть. А местами - смотрится довольно осмысленно. Поэтому концепция "D-bus must die" нуждается в некотором обосновании.

>ей не нужна замена, ее просто не должно быть.

Ну вон я пример выше привел. Реалистичный такой случай вполне. Нужный некоторым. Сделайте лучше, чтоли. Предложите иные технологии, менее корявые и более стройные, не в ущерб универсальности и документированности интерфейсов. Не хотите?

>>Кривой или нет, но работает и юзается кучей софта.
>Windows юзается кучей софта. И именно что кучей, жирной и дымящейся.

Ну, собссно, поэтому есть wine. Кому-то нужен, кому-то нет. Орать что он должен умереть конечно можно, но лучше от его смерти станет все-таки не всем.

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

Я вон выше пример привел. Оно только так используется для взаимодействия с демонами и в какойнить n900 даже выглядит осмысленно. Во всяком случае скомандовать телефонной части нечто по D-Bus выглядит как-то логичнее и менее извратно чем разговаривать с ней же из своей программы AT-командами, отправляемыми специально для этого запущенному демону интерпретатора AT-команд, который делает вид что оно и правда типа стандартный модем с типа стандартными AT-командами, хотя это ни разу не. И софту было бы явно проще дернуть это через какой-то внятный стандартный IPC интерфейс чем изгаляться с AT-командами в двух местах (в программе которая их будет слать и в демоне который их будет разбирать обратно).


"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено Knuckles , 18-Сен-10 15:51 
Вот и опеннет постигла судьба башорга - прогрессивная школота захватила ресурс.
>Это концепция сама по себе идиотична

Обмен сообщениями между программами идиотичен? Ну-ну. Что еще сморозишь?


"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено Coder , 17-Сен-10 09:30 
А ты сам какой прямой протокол специфицровал и реализовал?
Может COM?

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено Кракен , 16-Сен-10 19:34 
Отлично. Еще один плюсик для systemd.

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено segoon , 16-Сен-10 19:59 
Этот демон нужен исключительно ради авторизации, зачем повышать скорость? Тут важнее безопасность.

Для скорости надо юзать UNIX-сокеты/пайпы, если не хватает - отображения в память.


"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено segoon , 16-Сен-10 20:07 
Ошибся - не только для авторизации, ещё для уведомления системы/пользователя о каком-то событии.  Но всё равно я не вижу смысла в повышении скорости.

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено Аноним , 16-Сен-10 21:10 
а теперь давай еще одну поправку, и чтоб правильно

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено hawl , 16-Сен-10 21:25 
лучше пусть молчит

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено pavlinux , 16-Сен-10 20:07 
Даёшь ядро с торрент-клиентом и видео-плеером!!!!

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено аноним , 16-Сен-10 22:16 
и с рецептом прошивки оного во все mp3-плейеры, включая айфоны, утюги, самовары.

смех-смехом, но и этому может быть отличное применение.


"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено pavlinux , 17-Сен-10 00:38 
>и с рецептом прошивки оного во все mp3-плейеры, включая айфоны, утюги, самовары.
>
>
>смех-смехом, но и этому может быть отличное применение.

http://home.comcast.net/~fbui/


"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено KERNEL_PANIC , 17-Сен-10 09:11 
Ага, ага, и переписанного на питоне

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено User294 , 17-Сен-10 17:48 
>Даёшь ядро с торрент-клиентом и видео-плеером!!!!

Ну, как минимум HTTP сервер в ядро запихивали, IIRC...


"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено аноним , 18-Сен-10 05:02 
и отлично работал кстати.
вот только статика без пыхпыхов и мускулей мало уже кому нужна.

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено аноним , 16-Сен-10 21:24 
Это кривой костыль. Межпроцессное взаимодействие всегда делалось через пайпы, unix domain sockets, и shared memory. Зачем тут нужен левый демон, совершенно не понятно - у меня удалены все dbus'овские бинаники, и даже тот софт который требует это гoвнецо при сборке, работает замечательно. Минус линуксу indeed, ядро становится убунтой.

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено аноним , 16-Сен-10 22:26 
вот так сможешь?
>Сервисы делают доступной ещё одну функцию — запуск необходимых приложений в случае поступления сообщений для них. Для этого должна быть включена автоактивация, а в конфигурации D-BUS за этим сервисом должно быть закреплено одно приложение. Тогда D-BUS сможет его запустить при появлении сообщения.
>После закрытия приложения ассоциированные сервисы также разрегистрируются, а D-BUS посылает сигнал о том, что сервис закрыт. Другие приложения могут получать такие сигналы и соответствующим образом реагировать.

или будешь писать свой костыль под названием май-д-бас?
зы:
хотя, самое главное - не хочешь, не юзай.
вот выкинуть в виндах com с реестром не получится.


"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено аноним , 16-Сен-10 23:58 
> вот так сможешь?

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

> хотя, самое главное - не хочешь, не юзай
> вот выкинуть в виндах com с реестром не получится

Ровно также как и выкинуть в Gnome/KDE dbus не получится. Скоро оно будет в ядре. А насчет реестра - gconf из гнома тоже не особо выкинешь.


"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено аноним , 17-Сен-10 02:31 
>А ты сможешь левой ногой за правым ухом почесать? Для всякой фичи должно быть применение, а то что ты написал - бред.

да вы батенька просто профан.
>А насчет реестра - gconf из гнома тоже не особо выкинешь.

как страшно жить.
ядро линуха не стартанёт без fstab (реестр монтируемых фс, включая рут)
сеть в дебиане не стартанёт без /etc/network/interfaces (реестр интерфейсов)
и тд, и тп.
включая бедные текстовые файлы с xml внутри для gconf.
а если /etc удалить - О-О-О!!!!

назвать gconf реестром (вернее, сравнить gconf с виндовым реестром, как с технологией; т.к. само слово "реестр" ничего не значит. им может быть простой текстовой файл) может только полностью и окончательно упоротый вантузятник.


"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено аноним , 17-Сен-10 02:38 
не поверишь но и у гнома, и у кед всегда были подобные альтернативы.
http://ru.wikipedia.org/wiki/D-Bus
>В графической среде KDE для этого не так давно использовался DCOP
>Раньше GNOME использовал Bonobo, основанный на CORBA, но из-за зависимости от GObject, Bonobo не использовался в других рабочих средах, а низкое быстродействие CORBA сказывалось на скорости всей среды.

представляешь, из ГНОМа нельзя было выбросить  CORBA!!! а ты знаешь что такое CORBA?
виндусячий реестр - это так, детская игрушка, планарный файл.
какое несчастье для тупого тролля!


"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено User294 , 17-Сен-10 17:52 
>Это кривой костыль. Межпроцессное взаимодействие всегда делалось через пайпы, unix domain sockets,
>и shared memory.

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


"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено anonymous , 17-Сен-10 18:58 
>Ну и как мне стандартным методом узнать допустим заряд батарейки от демона заведующего этим в моем телефоне? Это надо точно знать какой сокет и т.п. + никто не удосужился выработать для этого стандартный протокол мля

Можно подумать, в dbus не нужно указывать интерфейс, имя свойства, тип данных и прочая.


"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено аноним , 17-Сен-10 20:39 
вы наверное в браузере исключительно ip-адреса набираете.

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено ы , 18-Сен-10 14:58 
>Ну и как мне стандартным методом узнать допустим заряд батарейки от демона заведующего этим в моем телефоне?

$ cat /proc/acpi/battery/BAT0/state


"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено аноним , 18-Сен-10 20:58 
а если так, чтобы он сам прислал уведомление, когда заряд <10%?
при чём заранее не известному количеству программ.
и это только с аккумулятором. а там ещё и связь - wifi, gps, gsm, 3g,..
не опрашивать же в цикле в каждой такой проге? так ресурсов не напасёшься

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено Аноним , 16-Сен-10 21:35 
Ждём новых дыр.

"Отправив специальным образом оформленное уведомление через DBUS приложение может получить полный доступ к памяти".


"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено аноним , 16-Сен-10 22:27 
подпись - толпа анонимного андеграунда.

"System V message queues/Posix message queues?"
Отправлено Me , 16-Сен-10 22:51 
Проясните, а зачем нужен Dbus когда есть System V message queues/Posix message queues?

"System V message queues/Posix message queues?"
Отправлено vasily_pupkin , 16-Сен-10 23:12 
А разве для queues не нужен такой же отдельный менеджер как dbus? :]

"System V message queues/Posix message queues?"
Отправлено Me , 17-Сен-10 11:05 
Им ядро выступает.

"System V message queues/Posix message queues?"
Отправлено Алекс , 16-Сен-10 23:15 
Более высокий уровень абстракции

"System V message queues/Posix message queues?"
Отправлено аноним , 16-Сен-10 23:59 
>Проясните, а зачем нужен Dbus когда есть System V message queues/Posix message
>queues?

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


"System V message queues/Posix message queues?"
Отправлено Аноним123321 , 19-Сен-10 21:17 
>>Проясните, а зачем нужен Dbus когда есть System V message queues/Posix message
>>queues?
>
>Ну вот захотели чтобы обязательно демон висел и память жрал.

если память не используется (например DBus-демон загружен но не используется) -- то при её нехватке она выгрузиться в SWAP!

...а вы-то наверно не знали этого? да? :-) , думаете что если программа загруженна то значит она обязательно создаёт тормаз в системе? :-D :-D :-D

а еслиже программа загружена в системе и РАБОТАЕТ (например демон которого кто-то использует) -- значет эта программа кому-то понадобилась.. и значит её ТЕМБОЛЕЕ нельзя отключать


такчто все аргументы про оперативную память (и ресурсы CPU) -- сразу отклоняются.
сделайте подольше размер SWAP-файла и не парьте другим нормальным людям мозги

# p.s.: я знаю что всегда находиться группа людей которых можно отнести к классу "оптимизаторы". они пытаются оптимизировать всё что угодно :-).. вот только методы оптимизации выбирают те которые больше похожи на "религиозные обряды" нежеле на чтото действующее. а тэсты оптимизации (после каждого "религиозного обряда") конешно же не проводятся, всё только на глазок!


"System V message queues/Posix message queues?"
Отправлено Аноним , 17-Сен-10 02:11 
> Проясните, а зачем нужен Dbus когда есть System V message queues/Posix message queues?

D-Bus фиксирует формат сообщений, а системные message queues — нет, поэтому обменятья сообщением между двумя заранее неизвестными программами через message queues невозможно, поскольку они не знают в каком формате друг у друга передаются и принимаются сообщения.


"System V message queues/Posix message queues?"
Отправлено Unk , 17-Сен-10 09:23 
>D-Bus фиксирует формат сообщений, а системные message queues — нет, поэтому обменятья
> сообщением между двумя заранее неизвестными программами через message queues невозможно,
> поскольку они не знают в каком формате друг у друга передаются и принимаются сообщения.

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


"System V message queues/Posix message queues?"
Отправлено аноним , 17-Сен-10 11:40 
вах. теперь видимо я должен отказаться от шифрования данных и отправки их по tcp.
и срочно, срочно нужно выкинуть из ядра поддержку сокетов AF_UNIX!
да что там! выкинуть нафиг всю сеть, все ipc и прочий хлам.
иначе помойка в головах троллей опустеет и они умрут с голода.

"System V message queues/Posix message queues?"
Отправлено anonymous , 17-Сен-10 12:44 
>D-Bus фиксирует формат сообщений

Кто мешает сделать либу, которая будет этим заниматься?


"System V message queues/Posix message queues?"
Отправлено Crazy Alex , 17-Сен-10 13:20 
Ну вот и сделали. Называется D-Bus.

"System V message queues/Posix message queues?"
Отправлено anonymous , 17-Сен-10 15:30 
>Ну вот и сделали. Называется D-Bus.

А демон зачем? Для густоты мыслей?



"System V message queues/Posix message queues?"
Отправлено аноним , 17-Сен-10 16:08 
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;


"System V message queues/Posix message queues?"
Отправлено anonymous , 17-Сен-10 17:19 
>ещё раз. большей концентрации - D-Bus is first a library that provides one-to-one communication between any two applications;

Создаётся обычный сокет, инфа тупо пересылается. Одно приложение передаёт, другой получает. Задача решена?



"System V message queues/Posix message queues?"
Отправлено аноним , 17-Сен-10 17:31 
а нахрена тогда апачи всякие придумали? или там к примеру постфиксы, довекоты?
есть же 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?"
честное слово, надоело уже отвечать на такие глупые вопросы.


"System V message queues/Posix message queues?"
Отправлено anonymous , 17-Сен-10 19:06 
>а нахрена тогда апачи всякие придумали? или там к примеру постфиксы, довекоты?

Да, в теме про dbus они явно лишние.


>да посмотрите уже хоть мельком доку!

И что? Посмотрел, ничего нового не увидел.


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

Может для начала не стоит их задавать? А просто ответить на главный вопрос, что можно сделать такого в dbus, чего нельзя без него. Особенно в плане демона, от которого зависит куча программ.


"System V message queues/Posix message queues?"
Отправлено аноним , 17-Сен-10 19:32 
>И что? Посмотрел, ничего нового не увидел.

печально.
>Может для начала не стоит их задавать?

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

уже писал - http://www.opennet.me/openforum/vsluhforumID3/70688.html#55
>Особенно в плане демона, от которого зависит куча программ.

вы плохо читаете? то что функциональность демона перенесена в ядро, не значит что этой функциональности нет. оформь поддержку tcp в ядре модулем и помести его в блэклист. удивишься сколько программ не заработают. или проделайте к примеру с увомянутым вами UDS.
отсюда и сабж - поместить в ядро поддержку нового типа сокета AF_DBUS и демон, по крайней мере на линухе, бкдет не нужен. обратное тоже верно - уберите поддержку типа сокета AF_UNIX и для работы UDS придётся писать демон. тоже самое и с tcp, udp, ppp.
а если всю функциональность  (большинство) вытащить из ядра и переместить в демоны, то это и будет панацея анонимов - микроядро.


"System V message queues/Posix message queues?"
Отправлено anonymous , 17-Сен-10 20:15 
>вы плохо читаете? то что функциональность демона перенесена в ядро, не значит что этой функциональности нет. оформь поддержку tcp в ядре модулем и помести его в блэклист. удивишься сколько программ не заработают. или проделайте к примеру с увомянутым вами UDS.

отсюда и сабж - поместить в ядро поддержку нового типа сокета AF_DBUS и демон, по крайней мере на линухе, бкдет не нужен. обратное тоже верно - уберите поддержку типа сокета AF_UNIX и для работы UDS придётся писать демон. тоже самое и с tcp, udp, ppp.
а если всю функциональность  (большинство) вытащить из ядра и переместить в демоны, то это и будет панацея анонимов - микроядро.


Товарищ, вы читать умеете? Я задал вполне конкретный вопрос по конкретной реализации. Что там в tcp, udp, ppp меня мало интересуют.


"System V message queues/Posix message queues?"
Отправлено аноним , 17-Сен-10 23:31 
этот что-ли?
>Создаётся обычный сокет, инфа тупо пересылается. Одно приложение передаёт, другой получает. Задача решена?

ответ уже был - нет, не решена.
приложений много. и все клиенты.
>Товарищ, вы читать умеете?

???


"System V message queues/Posix message queues?"
Отправлено szh , 17-Сен-10 14:41 
>>D-Bus фиксирует формат сообщений
> Кто мешает сделать либу, которая будет этим заниматься?

libdbus

DBUS - это не только формат сообщений, просвящайся http://dbus.freedesktop.org/doc/dbus-tutorial.html , http://ru.wikipedia.org/wiki/D-Bus


"System V message queues/Posix message queues?"
Отправлено anonymous , 17-Сен-10 15:34 
>DBUS - это не только формат сообщений

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



"System V message queues/Posix message queues?"
Отправлено аноним , 17-Сен-10 16:42 
ещё раз: 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 же ещё предоставляет и обратную связь в виде эвентов.
если демоны запихнуты в ядро, то уже никто не кричит не_нужна - такая у вас логика что ли?


"System V message queues/Posix message queues?"
Отправлено anonymous , 17-Сен-10 19:18 
>ирония не уместна. ибо глупа.

Что же тут сказать. Ну просто убийственные аргументы и тупое обобщение. Таким образом наплодиться ещё 9000 демонов оправдать под предлогом "да с таким же успехом можно mmap выкинуть".


"System V message queues/Posix message queues?"
Отправлено аноним , 17-Сен-10 19:39 
я думал вы несколько умнее. по-крайней мере знаете понятия ааналогия и моделирование.
зы:
вам не нравятся демоны? :D
сабж исправит ваше невежество - его не будет. будет модуль ядра.
вы довольны? :D

"System V message queues/Posix message queues?"
Отправлено Аноним123321 , 19-Сен-10 21:36 
>... Таким
>образом наплодиться ещё 9000 демонов оправдать под предлогом "да с таким
>же успехом можно mmap выкинуть".

ты идиот! если эти 9000 демонов используются -- значит они нужны!

а если ты решил что вместо DBus можно использовать просто unix-socket -- то идиот вдвойне, так как DBus как раз и работает через unix-socket!

(кроме того DBus выполняет сервисные функции которые НУЖНЫ тем приложениям которые взаимодействуют через DBus. а иначе бы эти программы не работали бы через DBus)

+к тому DBus НЕ загружается для каждой DBus-программы в индивидуальном порядке, так что агрмент "зачем мне чтобы висел дополнительный сервис в системе?" -- не принимается так как дополнительный сервис И НЕ ВИСИТ для каждой из DBus-программ

(DBus загружается ТОЛЬКО ОДИН РАЗ для всех обслуживаемых программ... а НЕ ИНДИВИДУАЛЬНО для каждой из программы. так понятнее?)


"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено KERNEL_PANIC , 17-Сен-10 09:40 
Фитча дельная. Ждем  по-дефолту в Fedora 24.

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено anonymous , 17-Сен-10 11:20 
А смысл в этом дбус? Есть unix domain socket, простой, удобный, быстрый.

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено anonymous , 17-Сен-10 12:48 
Да и воообще, если кто-то захочет урпавлять софтиной под dbus через cron, то того ожидает сюрприз.

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено Crazy Alex , 17-Сен-10 13:21 
>Да и воообще, если кто-то захочет урпавлять софтиной под dbus через cron,
>то того ожидает сюрприз.

И что ж за сюрприз? И что значит "управлять через cron"?


"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено Аноним123321 , 19-Сен-10 23:10 
> И что ж за сюрприз?

сюрприз наверно заключается в том что ...
                "ВСЁ РАБОТАЕТ! о боги! я думал оно не будет работать а оно работает!!!"

:-)


"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено szh , 17-Сен-10 14:47 
потребности приложений не ограничиваются проблемой "как два байта переслать при участии в пересылке не более 2 процессов".

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено anonymous , 17-Сен-10 15:38 
>потребности приложений не ограничиваются проблемой "как два байта переслать при участии в
>пересылке не более 2 процессов".

Вот честно, не знал, что UDS такой убогий.



"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено аноним , 17-Сен-10 17:04 
он не убогий. он вполне себе ничего.
просто 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?"

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено anonymous , 17-Сен-10 17:11 
>ваши сентенции логичны примерно как это утверждение  - "нарена http (и тем более web-сервера), если есть tcp/ip?"

Честно, я не где не видел, чтобы поднималось два сервера. Один для tcp, а другой для http.


"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено аноним , 17-Сен-10 17:36 
потому что tcp уже есть в одном, но ОЧЕНЬ важном сервере под названием ядро.
и к тому же - apache, dovecot, postfix, inetd, - всё это сплошь tcp сервера. все они сплошь сидят на портах tcp. ибо портов в http нет.

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено anonymous , 17-Сен-10 19:49 
>потому что tcp уже есть в одном, но ОЧЕНЬ важном сервере под
>названием ядро.

С каких это пор ядро стало сервером?


>и к тому же - apache, dovecot, postfix, inetd, - всё это сплошь tcp сервера. все они сплошь сидят на портах tcp. ибо портов в http нет.

Зачем они вообще нужны. У нас же ядро tcp-сервер!



"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено аноним , 17-Сен-10 19:57 
а что такое сервер?
вы вообще знаете определение?

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено anonymous , 17-Сен-10 20:19 
>а что такое сервер?
>вы вообще знаете определение?

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



"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено аноним , 17-Сен-10 20:52 
d-bus - не ipc. ipc в d-bus дополнительная возможность.
но я уже это писал. у вас склероз?
>несколькими строчками на си без всяких dbus-ов и торчащих в памяти демонов.

если вместо демона в памяти торчит модуль, вам спится легче?


"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено аноним , 17-Сен-10 20:53 
так что такое сервер?

"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено anonymous , 17-Сен-10 21:19 
>так что такое сервер?

сервер - программа, находящаяся в режиме готовности и выполняющая запросы других программ. Устроит? Повторяю вопрос. Что там такие за запросы, что у меня на локальной машине невозможно выполнить без сервера. А то ведь просто до смешного доходит. Спрашиваю одно и тоже третий раз, а мне какой-то бред про http/tcp.



"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено аноним , 17-Сен-10 23:37 
не верно. http://ru.wikipedia.org/wiki/%D0%A1%D0%B...
>Се́рвер (англ. server от англ. to serve — служить) (множественное число се́рверы) — в информационных технологиях — программный компонент вычислительной системы, выполняющий сервисные (обслуживающие) функции по запросу клиента, предоставляя ему доступ к определённым ресурсам или услугам.

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


"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено Аноним123321 , 19-Сен-10 23:15 
> ipc - это сервер. и использует ресурсы системы вне зависимости от того находится он в
> ядре или в демоне.
>

да без смысленно объяснять.. онже сказал что для него главный критерий (сервер или не сервер) -- это количество строчек на ЯП Си :-)

если строчек мало -- то значит не сервер. если много строчек -- то сервер :-) :-)


"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено Аноним123321 , 19-Сен-10 21:41 
>А смысл в этом дбус? Есть unix domain socket, простой, удобный, быстрый.
>

а по твоему DBus работает через волшебство :-D ?

СЮРПРИЗ(!!): DBus как раз и использует unix domain socket :-)

с таким же успехом можно сказать:
"зачем делать сайты на Django/Pylons, если можно просто использовать Python"


"ф топку дбас"
Отправлено Вова , 17-Сен-10 12:53 
меня вообще бесит, когда треш остаётся в таблице процессов после запуска невинной с виду гуйни, никогда не приветствовал этой ерунды. В момент запуска дбас кде писало  на сплашскрине "настраиваю оборудование", или что-то в этом роде, одна из ряда гыгышек, по которым стало ясно, что с сверинтеллектуальными десктопа пора завязывать.

"ф топку дбас"
Отправлено Аноним123321 , 19-Сен-10 23:22 
когда трэшь остаётся -- это фигово :-( .. например программа ("родитель") может "забыть" доубить "мёртвый" дочерний процесс, и при выходе "родителя" останется трэш (ввиде "зомби")

[разумеется это не может не бесить! в этом случае нада срочно писать Bug_Report!! С-Р-О-Ч-Н-О]

...однако как это касается темы DBus -- я не понимаю %) %) ... ведь DBus это же не трэш


"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено anonymous , 17-Сен-10 15:49 
Почему dbus не нужен.

Недостатки: посредник в виде демона, привязка к сессии пользователя, из-за чего тупо сделать dbus-send -//- из-под другого пользователя не представляется возможным.

UDS от этого недостатка свободен. Если уж так влом парсить мессагу, то ни кто не мешает сделать либу, которая будет формировать и парсить сама.

Зачем тащить весь этот хлам, непонятно.


"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено аноним , 17-Сен-10 17:21 
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. первый из них может существовать и без второго.
что не говорит о том, что второй не_нужен.


"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено anonymous , 17-Сен-10 19:43 
>uds мягко говоря (очень мягко) уровнем (или 2-мя) ниже. если сравнить их по аналогии с OSI, то d-bus - это пользовательский уровень, а UDS - канальный.
> "почему юникс не нужен. недостатки: посредник между программами и ядром в виде X, привязка к сессии пользователя, из-за чего тупо сделать rm -rf / из-под другого пользователя не представляется возможным.

вин95 от этого недостатка свободен. зачем тащить весь этот хлам, непонятно."


Ну и опять глупые аналогии. Конкретики, похоже, не дождусь.


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

И что? Есть клиент-сервер, как 2-е разные сущности. Межпроцессорное взаимодействие - тоже самое программа-клиент и программа-сервер. Ничего лишнего, вот только в случае dbus откуда-то появляется ещё и третья, необходимость который ничем не подкреплена.


"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено аноним , 18-Сен-10 04:36 
попробуй представить, троляря, что сервер из твоего примера написал Ганс из Германии, а клиента - Педро из Бразилии. Представил? а теперь представь что они абсолютно не знают о разработках друг друга. сервер пишет в юникс сокет бинарник, а клиент xml. чо получится?
вопрос - по какому протоколу они общаются?
далее - представь что таких серверов много и клиентов много. и все хотят общаться друг с другом и по очереди, и со всеми сразу, и по другим гендерным признакам. представил? способен вообще представить такое? и чтоб все знали куда долбится? и чтобы интроспекция (для подобных умников - http://ru.wikipedia.org/wiki/%D0%98%D0%B... была?  и чтобы очередь соблюдалась? и протокол все понимали? и ошибки отрабатывались?
вот для этого умные люди придумали сервера и протоколы прикладного уровня. те которые часто бывают оформлены в виде демонов.
а теперь представь, что апач назвали d-bas, работает он через твои долбанные юникс сокеты (да и все остальные тоже), протокол общения имеет четкий вид, но не http, а через low-level message-passing protocols such as UDP. вот тогда ты смутно поймёшь какую херню ты тут нёс.
но это врядли. тебе и так супер доходчиво пытались объясняли.

"имхо бред"
Отправлено Вова , 18-Сен-10 08:57 
1. Вы надеетесь, что имея чёткий формат клиент-серверного взаимодействия в лице дбас, вы сможете любым клиентом общаться с любым сервером - это фикция,миф. Любой клиент имеет некоторое представление о сервере, с которым собирается работать - равно и сервер.

2. Что за ситуация, где "таких клиентов много и серверов много" на одной локальной машине?? что это за бред??


"имхо бред"
Отправлено аноним , 18-Сен-10 10:19 
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.
и кидаться такими утверждениями может только полный профан, который не понимает даже о чём вообще идёт речь.

"пример несостоятелен"
Отправлено Вова , 18-Сен-10 10:30 
1. Ответ, в котором используются уважительные обращения вида "профан", "работаете ли вы с компьютерами" априори неверен,  но всё-таки дам вам некоторый ликбез по "изменению состояния вай-фай и нетворк-менеджер + пиджин + скайп"

Какой бы не был статус вай-фай, пиджину и скайпу нужно только одно: доходит ли пакет до адресата. Всё.  Ни роутинг, ни количество интерфейсов, ни тип подключения, это - не их дело.
Далее,  нетворк-менеджер, это что такое вообще? Рискну предположить, что это некий демон, имеющий "удобный гуи-клиент" для облегчения конфигурации сети в системе. Так вот, внимание, присядьте, товарищ специалист по актив-икс/ком/корбе... Ему в линукс/бсд/любом юниксе никакой d-bus по определению не нужен. Даже если бы и была возможность работы по д-бас всех пользовательских конфигурационных надстроек над ядром, это не было бы лучшей идеей для контроля сети попросту ввиду избыточности лишнего звена.

"Поработайте с компьютерами"?


"пример несостоятелен"
Отправлено аноним , 18-Сен-10 11:16 
какое бы обращение я не выбрал - это не изменит технологию.
тем более что оно верное.

пиджин и скайп подстраивают видеопоток в зависимости от параметров сети.
более того, они уже используют d-bus.
а все ваши знания об этом на уровне профана. ваше упорство, безапелляционность и высокомерие (Рискну предположить, что это некий демон, имеющий "удобный гуи-клиент") - на уровне идиота.


" то есть, помимо оскорблений - аргументов нет"
Отправлено Вова , 18-Сен-10 12:19 
Вижу, вы согласны с несостоятельностью вашего примера. "уровень идиота и высокомерие" - это нежелание опускаться до ваших оскорблений? Сколько у вас было примеров удачного использования д-бас, приведите их. Могу предположить, что в каждом случае использования был более верный вариант, вы же, использовав свои мнимые достоинства как специалиста с опытом актив-икс/ком, заточились на аналог ком - тем самым отсекая возможность быстрого решения проблем с вашими модулями  другими разработчиками.

" то есть, помимо оскорблений - аргументов нет"
Отправлено аноним , 18-Сен-10 14:33 
так и не понять разницу между компонентной моделью разработки,  и шиной сообщений после того, как ему 100500 раз объяснили, может только  хронический идиот.
>Могу предположить, что в каждом случае использования был более верный вариант, вы же, использовав свои мнимые достоинства как специалиста

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

адиос, амиго. удачи твоим работодателям.


"резюме данного трида"
Отправлено Вова , 18-Сен-10 16:53 
1. Смешной пример про пиджина, скайп и "нетворк менеджер"а, узнающих "параметры сети" по д-бас: в реальности, для выставления верного видеопотока необходим реальный бенчмарк тестовой "прокачки" между двумя клиентами. Если пиджин и скайп будут рассчитывать возможный битрейт потока по данным от д-бас, то подключение в 90%% сетей вай-фай будет мнимо хорошим, видиопоток будет выбран неверно.

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


"резюме данного трида"
Отправлено szh , 19-Сен-10 02:48 
> Если пиджин и скайп будут рассчитывать возможный битрейт потока по данным от д-бас, то подключение в 90%% сетей вай-фай будет мнимо хорошим, видиопоток будет выбран неверно.

ты сам придумал глупость и сам ее опровергнул.


"резюме данного трида"
Отправлено Вова , 19-Сен-10 10:53 
Это пример был рассказан выше "анонимом", под которым я не дописывался ни разу.
Единственно, что *будто бы* облегчит использование д-бас  - это портирование  специфичных системных  фишек типа "запрос текущего разрешения экрана". В несуществующем идеальном мире был бы написан "сервер", который отвечал бы на запрос "дай мне размерности экрана", и разработчики конечного приложения не парились бы, каким образом это делается на конкретной системе. В реальности вот это деление -  нереализуемый миф, по разным причинам.

Поэтому неудивиельно, что человек, который восторженно описывал д-бас упоминал всякие  виндовые ком/корбы/актив-икс, видать в реальности уже были отмазки на вопрос "а почему у нас то-то так-то??" вида  " да тут по д-бас кто-то прислал неверные данные разбираюсь кто это сделал. Пока в ядро не вынесли дбас - это трудно делать, это же линукс"


"и ещё"
Отправлено Вова , 18-Сен-10 12:24 
>какое бы обращение я не выбрал - это не изменит технологию.
>тем более что оно верное.
>
>пиджин и скайп подстраивают видеопоток в зависимости от параметров сети.
>более того, они уже используют d-bus.
>а все ваши знания об этом на уровне профана. ваше упорство, безапелляционность
>и высокомерие (Рискну предположить, что это некий демон, имеющий "удобный гуи-клиент")
>- на уровне идиота.

и да, я не знаю, что вы имеете в виду под "нетворк менеджер"ом.
Опыт программирования под линукс - 7 лет, до этого мимолётно затронул виндоус, даже успешно прошёл курсы от сибосс, кто знает, тот в теме. Интересно отметить, что когда ещё позиционировал себя под разработку виндоус приложений, как раз думал прикупить томик-кирпич по Com, ввиду следующего соображения - "технология-то одна, а названий красивых много, резюме солиднее будет смотреться".  Да, так и думал, честное слово.
"Профан, уровень идиота" - спасибо за эти слова.


"и ещё"
Отправлено Аноним123321 , 19-Сен-10 22:11 
> Опыт программирования под линукс - 7 лет

вобщемто если работаешь программистом -- то нада не только программульки писать, но и развиваться изредка (повышать свой уровень)

[конешно я знаю что работа программистом зачастую настолько обременительная :-( что просто НЕКОГДА развивать себя. оттачивать навыки программирования ЯП Си это хорошо(!), но в будущем можно заметить даже будучи супер-мега-грамотным-программистом на ЯП Си -- без знания современных unix-технологий уже сложновато]

...а иначем можно и 30 лет пробыть идиотом-программистом :-)

как например щаз досих пор в моём городе существуют дядьки которые пишут [госудерственные] программы под FoxPro (for MSDOS) .. и пишут их не менее 15 лет [никаких других технологий.. и уж точно DBus -- они не знают и знать не хотят :-)]


"Представлена реализация шины D-Bus, работающая на уровне Lin..."
Отправлено Аноним123321 , 19-Сен-10 22:02 
>Почему 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]