- A hozzászóláshoz be kell jelentkezni
- 3775 megtekintés
Hozzászólások
Sose értettem mi az a DBUS.. IPC-t valósít meg? Tudom, tudom, olvassak utána -.-
- A hozzászóláshoz be kell jelentkezni
az, ipc. es: libxml a fuggosege. akkor azt is beleteszik a kernelbe? tok jo lesz ;]
- A hozzászóláshoz be kell jelentkezni
hol függ ezektől?
-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --
- A hozzászóláshoz be kell jelentkezni
pl. az introspection-nál xml-t használ:
http://dbus.freedesktop.org/doc/dbus-specification.html#introspection-f…
(bár hogy libxml2-t használna abban már nem vagyok biztos...)
- A hozzászóláshoz be kell jelentkezni
… gyorsabb lesz az XML parsolás is!! ;)
int getRandomNumber() { // ←ez itt már az aláírásom
return 4;//szabályos kockadobással választva.
} //garantáltan véletlenszerű. xkcd- A hozzászóláshoz be kell jelentkezni
LOL
--
NetBSD - Simplicity is prerequisite for reliability
- A hozzászóláshoz be kell jelentkezni
Az, hogy ne legyen userspace dbus, az szerintem jó ötlet. Már csak a kernelbe nem kellene belerakni és minden frankó is lenne...
nem pártolom, hogy hülye desktop csellentyűcskékkel gányolják a kernelt
- A hozzászóláshoz be kell jelentkezni
hülye desktop csellentyűcskékkel gányolják a kernelt
lehet hogy igy/ettol fog eljonni a linux (=kernel) desktop (minek a resze a dbus) e've?
- A hozzászóláshoz be kell jelentkezni
majd raknak kékhalál daemont is a kernelbe, szükség is lesz rá...
- A hozzászóláshoz be kell jelentkezni
Legyen minden kernel modul! :D
-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --
- A hozzászóláshoz be kell jelentkezni
Mobiltelefonon majdnem nem érdekel, hogy mi van a kernelben. Legyen gyors, fogyasszon keveset és legyen biztonságos. Tartsa karban a gyártó. A fő célterület ez. Nekem legalábbis ezt súgta a "Maemo", "N900".
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
biztos igazad van... de:
New performances
The first benchmark is dbus-ping-pong. It is a simple tool to call a D-Bus method and wait for the reply 10000 times. I tried it both on a KVM/i386 virtual machine and on a N900/arm.
* KVM/i386, without kdbus: 3.887s
* KVM/i386, with kdbus: 2.085s (x1.8)
rossz előjel...
- A hozzászóláshoz be kell jelentkezni
mi a baj vele? hogy gyorsabb? :) (marmint nem a dbussal, az egy szar, az idezett eredmenyre gondolok)
- A hozzászóláshoz be kell jelentkezni
hogy növeli a kernel komplexitását, magyarul újabb területeken ad esélyt arra, hogy eltolják a dolgokat. és akkor nem elég, hogy desktop linux nem lesz, még rendes szerver linux sem.
- A hozzászóláshoz be kell jelentkezni
Ez egy kernelmodul. Ebből sok minden következik.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
az kovetkezik, hogy nem forditas idoben, hanem futasidoben linkelodik a targykod. semmi mas. vagy minek kellene?
--
NetBSD - Simplicity is prerequisite for reliability
- A hozzászóláshoz be kell jelentkezni
meg az, hogy ha nem tetszik, nem toltod be. ha nem tetszik, userspace dbus-t hasznalsz tovabbra is. Mint pl. az nfs-server eseteben megtortent.
- A hozzászóláshoz be kell jelentkezni
Az következik belőle, hogy ha netán a mainline kernel része is lesz (erről ugyan még szó sincs), attól még az Enterprise Server disztribútor nyugodtan figyelmen kívül hagyhatja, és nem kötelessége szállítania ezt szerver termékhez a kernelbe / kernelhez fordítva.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
a patchet elnezve azert nem teljesen self contained, bar enm forditottam ra par percnel tobb idot
--
NetBSD - Simplicity is prerequisite for reliability
- A hozzászóláshoz be kell jelentkezni
Remek, de attol meg ugyanahhoz a monolitikus katyvasszal fog egy terben futni, mint az osszes tobbi kernelmodul. A kernelmodulok bevezetesevel nem irtak at az egeszet monolitikusrol mikrokernelre.
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
tegyük hozzá: szerencsére. de szívesen veszem tőled a jól működő, enterprise szinten használható, stabil, elterjedt, megfelelő hivatalos és community supporttal rendelkező mikrokerneles oprendszerek/disztribek listáját.
- A hozzászóláshoz be kell jelentkezni
qnx
- A hozzászóláshoz be kell jelentkezni
OSE ;)
- A hozzászóláshoz be kell jelentkezni
regen (2.5.x eleje) probaltam kovetni, hogy mi folyik a kernelben (kellett a munkamhoz). mostmar nem ugranek bele csak ugy, szerintem eleg kusza lett.
- A hozzászóláshoz be kell jelentkezni
Gondolom arra célzott, hogy KVM/i386-on nyomott egy tesztet. Gondolom ezt értelmezte rossz előjelként.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
> and wait for the reply 10000 times
Egy felhasználónál mennyi idő alatt generálódik 10K üzenet? Mert ha pld óránként 1 másodpercet takarít meg a kdbus, akkor mi szükség rá?
- A hozzászóláshoz be kell jelentkezni
Szerintem inkább válaszidőnél számíthat.
---
Internet Memetikai Tanszék
- A hozzászóláshoz be kell jelentkezni
legyen biztonságos
userspace->kernelspace kódmozgatás "nem biztos", hogy ebbe az irányba megy
- A hozzászóláshoz be kell jelentkezni
Ha nem lehet megoldani, akkor nem kell elfogadni a kernelbe. Gondoltam egyértelmű lesz, hogy mit akartam volna mondani.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
A hagyományos POSIX / System V IPC megoldások is a kernelben vannak. Nem beszélve pl. az Android Binder nevű IPC megoldásáról.
A D-Bus egyébként távolról sem csak "desktop csellentyűcske". Egyike azon kevés "hagyományos" Linux komponenseknek, amiket pl. az Android is használ.
Üdv,
Gergely
- A hozzászóláshoz be kell jelentkezni
Nem hinnem, hogy a kernel maintainerek elkovetnek azt az okorseget, hogy a DESKTOP BUST integraljak a kernelbe.
----------------------
while (!sleep) sheep++;
- A hozzászóláshoz be kell jelentkezni
buszvezérlő a kernelbe való, csellentyű a desktopra.
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
- A hozzászóláshoz be kell jelentkezni
Hmm es vajon az mplayer is gyorsabb lenne a kernelben? Mert akkor ott a helye... :)))
A'rpi
- A hozzászóláshoz be kell jelentkezni
most hogy mondod... nyitok is egy feature requestet adobenal
- A hozzászóláshoz be kell jelentkezni
Vááá :D ROTFL!
- A hozzászóláshoz be kell jelentkezni
flash-ben írt kernel, vagy mi? :)
- A hozzászóláshoz be kell jelentkezni
Nem értem miért baj ha beteszik.
Most is van hasonló a kernelben (IPC pl.), így csak eggyel több ilyen lesz.
Vagy a másik amit el tudok képzelni, hogy szerintetek az is baj, hogy egyáltalán az IPC benne van, szóval nem betenni kéne hanem az eddigieket is kivenni:
de ekkor meg visszaértünk a "monolitikus/moduláris vagy mikrokernel legyen-e a Linux" vitához...
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Ja, és én egyébként a mikrokernelre szavazok! Ugye még nem késtem el??? ;)
- A hozzászóláshoz be kell jelentkezni
Én monolitra szóval -1 (ill inkább hibrid).
------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.
- A hozzászóláshoz be kell jelentkezni
En elmeletben a mikrokernelre, gyakorlatban a monolitikusra, mivel ugyan elmeletileg az elmelet es a gyakorlat ugyanaz, de gyakorlatilag nem :)
- A hozzászóláshoz be kell jelentkezni
Nekem legfeljebb a D-BUS-szal van problémám, az ötlettel nem. Sokszor hiányzott már (ha jól emlékszem itt a HUP-on is kért valaki hasonlóban segítséget) egy unix socketen, gépen belüli P2P kommunikációs megoldás.
Van, hogy egy sima unix socket multicast is sokat segít, de ha ez címezhető, jól eltalált megoldás (publish, subscribe stb), és még teljesítményt is tud adni, az nagyon jó is tud lenni.
Pld. privilégium megosztáshoz, worker poolhoz.
suckIT szopás minden nap! kqueue Javához!
- A hozzászóláshoz be kell jelentkezni
Jogos. Itt azert az a baj, hogy bizonyara van sok feature-naci, aki koromszakadtaig vedene a kernelt attol, hogy barmilyen uj funkcionalitas kernelspace-be keruljon.
Igazabol maskeppen kellene megkozeliteni az ugyet, es erre szepen ravilagit ez a fejlesztes. Van egy potencialisan nagy teljesitmenytobblet az egyik oldalon. A masik serpenyoben meg ott vannak a biztonsagi, komplexitasi, stb. aggalyok. Innentol a kernelatyauristeneken mulik, hogy szakmailag indokolhatonak tartjak majd a produktumot (ha egyaltalan elkeszul) beolvasztani a kernelbe. Kategorikusan elzarkozni elole biztosan nem szabad.
Ha az igeny kelloen megalapozott, de az egesz infrastrukturat tul sulyosnak erzik a kernelhez, akkor viszont melysegesen el kell kezdeni gondolkodni olyan infrastrukturak tervezesen, amiket toolkitkent hasznalva megkozelitheto a kernelspace implementacio teljesitmenye.
Csak egy pelda (meg ha elbaszott is): eleinte az X-nek nem volt tul sok szuksege nagy kraftra, siman ment userspace-ben. Miutan mar ilyen okossagok kerultek elo, mint direct rendering es egyebek, azert mar valamilyen szinten ossze kellett gyogyitani az X-et a kernellel. De ez nem feltetlenul jelenti azt, hogy egybol az egeszet meg kell irni kernelspace-ben futora.
- A hozzászóláshoz be kell jelentkezni
"Nem értem miért baj ha beteszik.": "eggyel több ilyen lesz.": ezért.
az ipc az posix elvárás, ott nincs vita. de a dbust csak arra találták ki, hogy desktop programok kis felhőcskékben üzengessenek egymásnak. úgy érzem, nem ez akadályozza a linux desktop évének eljövetelét.
Ez nem monolitikus-/mikrokernel kérdés, mert nem azt firtatom, hogy hol implementálják, hanem azt, hogy minek.
- A hozzászóláshoz be kell jelentkezni
Mármint firtatod a dbus (dcop, com, whatever) létjogosultságát?
((Abban egyetértek, hogy nem emiatt nem a linux desktop éve))
- A hozzászóláshoz be kell jelentkezni
Nézzünk néhány szempontot:
1. mit látok én a dbusból?
- ha végzett a gnome baker, feldob egy felhőt, hogy kész
- ha jött egy email, feldob egy felhőt a tbird, hogy jött egy email
- ha valamit szöszölt a hálózattal valami manager program, akkor feldob egy felhőt...
a cd égetés végét észreveszem, mert kidobja a lemezt.
az email érkezést pontosan akkor veszem észre, amikor van időm foglalkozni vele, hiába pattog, hogy jött egy levél, ha fontosabb van előtte a bionikus queue-ban
a hálózati manager programokat szoktam először legyakni a desktopomról, nekem ne okoskodjon a beállításokkal. egyébként is az ilyen programok a külöbböző portálokon olvasható kérdések alapján egy halom trutymók
2. mit lát egy szerver a dbusból? hogy olyan dolgok kerülnek fel a gépre, aminek semmi keresnivalója ott. És nem, nem akarok kézzel összefaragni egy debian forkot, mert annyi időm nincs. pedig ideje lenne már egy hatalmas backendbe rúgást kiosztani ott pár embernek, amilyen függőségek vannak...
3. a karbantartó meg azt látja belőle (mindegy, hogy kernel, alkalmazás, csomag karbantartó), hogy megint egy plusz cucc, ami igazából problémás lehet, támogatni kell, stb. stb. plusz meló, erősen kétséges hozadékkal.
A kérdésedre a válaszom: igen, firtatom. Pontosabban totálisan feleslegesnek tartom. Amíg mindez user space-ben van, addig bánja a hóhér, valahogy kigyalulom a gépemről, de ha kernelbe kerül, akkor baj lesz. Debianéknál nem láttam még külön desktop és szerver kernelt, tehát ha desktop csellentyűcskék miatt bekerül a kernelbe, az a szervereket is veszélyeztetni fogja. Majd ráakaszkodik egy halom ótvarosan megírt alkalmazás, kiváló célpont lesz privilégium emelés elérésére.
- A hozzászóláshoz be kell jelentkezni
Az eszedbe jutott már, hogy nem csak desktopon, meg szerveren fut linux? A cikkben is N900-on tesztelték, a telefonoknál meg minden csepp erőforrás fokozottabban számít.
--
"If God exists...why is there no porn of Him?"
- A hozzászóláshoz be kell jelentkezni
Eszembe, persze. hogy is van ez, n900 meg minden csepp erőforrás számít meg dbus?
a cikkben n900-on IS tesztelték.
- A hozzászóláshoz be kell jelentkezni
Ha desktopon meg szerveren nincs értelme, akkor majd a kedvenc konzervatív debian stable kerneledbe nem lesz belefordítva meg betöltve a modul és használod tovább a userspace dbust.
--
"If God exists...why is there no porn of Him?"
- A hozzászóláshoz be kell jelentkezni
Így már értem, miért tartod feleslegesnek. A dbus nem felhőket dobál, hidd el.
Ajánlom, olvass kicsit utána. Típusos, magas szintű IPC-ről van szó, ami - tudomásom szerint - már tizenöt éve van az MS oprendszereiben, de a KDE is tíz évvel ezelőtt használt dcopot. A desktop "integráltság" ugyanis ezeknek a megvalósításoknak köszönhető, emiatt tudnak egymásról az appjaid, ezzel a technológiával lesz egy operációs rendszer GUIja egy egész, nem pedig csak segédprogramok összesége.
Pl.: a gnome-power-managernek van dbus interfésze, így tudtam olyan POC Qt-s appot összedobni, amelyben én húzogattam egy slidert, és ezzel a képernyő fényerejét változtattam.
A felhődobálás csak egy-egy dbust használó program funkciója. Nem pedig a dbus.
- A hozzászóláshoz be kell jelentkezni
már tizenöt éve van az MS oprendszereiben
Egyébként ott kernel módban van megcsinálva?
---
Internet Memetikai Tanszék
- A hozzászóláshoz be kell jelentkezni
A 15 évre is tippeltem csak, nem tudom.
- A hozzászóláshoz be kell jelentkezni
igen
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
- A hozzászóláshoz be kell jelentkezni
"már tizenöt éve van az MS oprendszereiben": lehet, hogy a meggyőzésemre nem ez a megfelelő érv:)
A desktop integráltság kifejezés lóg a levegőben, igazából nem is érdekel. Mi a haszna? tudnak egymásról az appok, és? Ha nincs értelmes gyakorlati haszna, akkor a kukába vele.
- A hozzászóláshoz be kell jelentkezni
gy.k.:
- Ha bedugod a pendrive-odat, feldobja a felhőcskét / kiteszi az ikont az asztalra.
- Ha merülőben van az akksid, figyelmeztet, esetleg eltesz suspendbe/hibernál
Az eddigi érvekről, bevált módszerekről az a véleményed, hogy "nincs értelmes gyakorlati haszna"? Mint látod, van. A piac, és a nagy oprendszergyártók használják. Szóval valószínűleg mégsem lesz kukázva.
((Más kérdés, hogy a kernelben van-e a helye.))
- A hozzászóláshoz be kell jelentkezni
Ezt értem. De ezekhez minek dbus?
Jajj, ha mindig az lenne az értelmes, amit a nagy oprendszergyártók használnak, már régen beledöngölt volna minket a betonba a microsoft. A piacot meg nem a felhasználói igények irányítják, hanem a gyártói akarat.
Még egy apróság: ez az eltesz suspendbe, hibernál kifejezés. Nem röhögök fel túl hangosan, mert a felettem lakó már alszik, de azért láttunk már olyat, hogy a suspendet nem tudják évek óta rendesen megfaragni, általánosan... Na ugyanilyen bénázástól félek a dbus-szal kapcsolatban is, hogy évekig fog félig-meddig működni. És ha a végére akasztott cuccok nem működnek rendesen, akkor ez egy csodálatos implementáció lehet, csak l'art pour l'art.
- A hozzászóláshoz be kell jelentkezni
A DBUS egy distributed bus rendszer, kis leiras:
http://en.wikipedia.org/wiki/D-Bus
Tortenik valami a rendszerben, ez egy esemenyt general, es erre tudnak alkalmazasok figyelni. Amig nem volt dbus, addig igenytelen osszeganyolt, keresztul-kasul hivo kodok voltak. A dbus ota par sorban meg lehet oldani azt, hogy ha a user bedugja a pendrive-ot, akkor felmount-oljuk a desktopra, ha csatlakoztunk egy wifi hotspot-ra, akkor kapjon a felhasznalo egy felhocsket, valamint egyes alkalmazasok is tudnak egymassal kommunikalni GANYOLAS nelkul, akar egy gnome-os alkalmazas is egy kde-sel, tehat a dbus reteg masszivan a desktop reteg ALATT talalhato, mondhatni plusz szolgaltatas.
Epp ezert a dbus ertelmet elvitatni felesleges. Az persze egy jo kerdes, hogy a dbus-nak vajon a kernelben van-e a hely, vagy pedig user-space-ben, ezen lehet es erdemes is vitatkozni.
- A hozzászóláshoz be kell jelentkezni
Lehet kéne egy harmadik réteget alkotni a kerner-space és az user-space közé, ami a kernel-space sebességét nyújtja az user-space jogköreit alkalmazva..
Ez lehetne a 2.8.x sorozat? :D
----
Dropbox tár: https://www.dropbox.com/referrals/NTY1ODc5OTQ5
- A hozzászóláshoz be kell jelentkezni
LOL, remelem leesett az is, hogy a "retegek" kozotti valtas miatt lasabb..
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
igen, de addigra mindent portolnak a köztes rétegbe :P
int getRandomNumber() { // ←ez itt már az aláírásom
return 4;//szabályos kockadobással választva.
} //garantáltan véletlenszerű. xkcd- A hozzászóláshoz be kell jelentkezni
emiatt tudnak egymásról az appjaid
Kösz, az én appjaim ne tudjanak.
Ha valaki "integrált desktop" érzületre vágyik, használja az önálló dbus processzt.
Az egész ötlet egy teljesítményorientált hakk, amire nincs más mentség, mint "fogy az akksi". Semmi gond, csak valljuk be, hogy egy ilyen platformon nem engedhetjük meg magunknak az architekturális szépséget; gányolunk, mert muszáj. Ne próbáljuk eladni másnak, mint szükségmegoldásnak.
- A hozzászóláshoz be kell jelentkezni
szerintem aki integrált desktop érzületre vágyik, az használjon w7-et.
- A hozzászóláshoz be kell jelentkezni
Szerintem meg aki nem érti, hogy mi az a DBUS, mégis ilyen hihetetlen okosságokat fűz hozzá, az ne mondja meg, hogy kinek mi a jó.
- A hozzászóláshoz be kell jelentkezni
ugye te is érted a különbséget aközött, hogy szerinted nem értem mi a dbus, meg aközött, hogy szerintem semmi értelme?
- A hozzászóláshoz be kell jelentkezni
Abba belegondoltal, hogy nemcsak desktop appok, hanem akar egy tobb programbol osszerakott alkalmazasszerver is tudja hasznalni ezt kommunikaciora?
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
Olvastad már azt a linket, amit nekem ajánlgatnak? "In computing, D-Bus (Desktop Bus)"
appszerverbe desktop bus a szabvány posix kommunikációs eszközök helyett... az utolsó, ami eszembe jutna, hogy ilyet csináljak, hogy odadrótozzam egy alkalmazásomat a linux kernelhez vagy desktophoz...
És lentebb egy kolléga nagyon helyesen feltette a kérdést, hogy mi van, ha nem fogy az üzenet olyan gyorsan, mint ahogy termelődik. több biztonsági probléma is eszembe jutott, ez konkrétan nem, pedig egy szög nagyon fejen lett itt találva.
Visszatérve a kérdésedhez, kicsit eltúlozva és kifigurázva: akkor jön el a sírásrívás ideje, ha java message queue-t implementálnak a kernelben...
- A hozzászóláshoz be kell jelentkezni
Miért TCP-nél, UDP-nél stb-nél mi van?
suckIT szopás minden nap! kqueue Javához!
- A hozzászóláshoz be kell jelentkezni
wraparound detected in uint64_t upvote counter
Köszönöm. Én ezért járok ide.
- A hozzászóláshoz be kell jelentkezni
Akkor megegyszer:
Ha bekerul es modul. Nem kotelezo.
Minek implementaljak? Mert gyorsabb lesz tole a rendszere egy par embernek. De ez neked ne fajjon annyira.
- A hozzászóláshoz be kell jelentkezni
a disztrók közül sajnos némelyikben szokássá vált, hogy mindent használnak, ami kézreesik, nem pedig annyit, amennyire valóban szükség lenne.
már most libabőrös vagyok attól a gondolattól, hogy az avahi meg a dhcp kliens démon meg nem tudom még, micsoda ráakaszkodik a dbusra és abból mi lesz...
ha lesz egy kis időm, megnézek egy alap friss debiant, hogy miket szemetel telepítés közben. majd jól rámjön az infarktus.
- A hozzászóláshoz be kell jelentkezni
Ha disztribuciot hasznalsz az ezzel jar. Ok halad(na)nak a korral.
Hasznalhatsz masikat is, van a sokszor emlegetett "minek-nekunk-500 disztribucio". Az ezert van.
De ez detto a pulseaudioval is. Akinel nem megy defaultban flawless eloszor legyalulja, masok meg tesztelik, es utana megint masok javitjak. Vegul persze mindenhol pulse lesz...es akkor nem beszeltunk a masik akarhany hangrendszerrol.
De: ha mar hasznalni vagy kenytelen (mert elobb vagy utobb ugyis fuggove valik a debian desktop is annyira tole, hogy kelleni fog), miert ne legyen gyors?
- A hozzászóláshoz be kell jelentkezni
Szuper, végre!
Bezzeg az a hülye M$, mekkora balfék volt, amikor a Win2000-rel a GUI-t tette be a kernelbe!
:))
--
Wir sind erfaßt, sind infiziert,
Jedes Gespräch wird kontrolliert.
- A hozzászóláshoz be kell jelentkezni
Gnome appleteket a kernelbe!
Példa rá, miért akarja az Oracle távoltartani a közösségi fejlesztőket a Solaristól.
--
CCC3
- A hozzászóláshoz be kell jelentkezni
appleteket? kgnome-ot a nepnek, kflash, kmplayer, meg kporndownloaderrel egyetemben :)
- A hozzászóláshoz be kell jelentkezni
Oracle? Akar? Pénz?
- A hozzászóláshoz be kell jelentkezni
Mióta mondom én már ezt, nem értem hogyhogy csak most jutott el idáig a dolog.
- A hozzászóláshoz be kell jelentkezni
Pedig nagyobb adat-tömegek mozgatására már dbus 1.3 óta van lehetőség unix fd-k küldözgetésére (vagyis létrehozni egy pipe-ot, és azon át küldeni a cuccot). Ez így egy elég gányolt megoldás, de a dbus amúgy sem nagy üzenetekre lett kitalálva. Szerintem sokkal okosabb lenne, ha ezt jobban integrálnák, és lehetővé tennék egy effektív és egyszerűen hasznáható 2 végpont közötti közvetlen streamen üzenetek küldését a libdbus-ban (és így a dbus daemon-t kikerülné a nagyobb forgalom).
- A hozzászóláshoz be kell jelentkezni
Hogy is mukodik ez a D-BUS ?
Mi van ha egy alkalmazas elkezd 400 millio uzenetet bekuldeni, ket alkalmazas van ra feliratkozva az egyik tisztessegesen olvasgatja, a masik nem olvassa ?
Blokkolodik -e kuldo ?
Elveszt -e uzeneteket az aki nem olvassa ki ?
Elfogyhat -e a memoriaja a D-BUS daemonnak ?
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
és mi van a hálózati transzparenciával?
- A hozzászóláshoz be kell jelentkezni
Es hova tunt Damon Hill?
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
hová tűnt Palik László?:)
- A hozzászóláshoz be kell jelentkezni
http://dbus.freedesktop.org/doc/dbus-daemon.1.html
Ahogy vegigolvastam, alapvetoen nem erre a feladatra lett kitalalva (nem high performance messaging queue) hanem kis valtozasok sok alkalmazas fele torteno egyseges lekommunikalasara. Mondjuk ettol fuggetlenul en nem raknam a kernelbe..
- A hozzászóláshoz be kell jelentkezni