Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
kdbus in the kernel
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3 ... 6, 7, 8 ... 25, 26, 27  Next  
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Sat Jan 24, 2015 12:01 pm    Post subject: Reply with quote

Anon-E-moose wrote:
khayyam wrote:
depontius wrote:
Sometimes the best attitude toward a train might just be to get out a folding chair, a tall glass of icy lemonade, and watch the show.

that depends on who's driving the train :)

I read that yesterday, and just shook my head

Anon ... when I read it I spilt my lemonade :)

Anon-E-moose wrote:
bonsaikitten wrote:
In the end, all is well, and I'm still confused why writing a config file needs dbus and xml and stuff.

It shouldn't need dbus or xml, but that's stuff being driven by...tada...RH

"Confused? You won't be, after this week's episode of ... Soap."

best ... khay


Last edited by khayyam on Sat Jan 24, 2015 12:07 pm; edited 3 times in total
Back to top
View user's profile Send private message
tclover
Guru
Guru


Joined: 10 Apr 2011
Posts: 516

PostPosted: Sat Jan 24, 2015 12:04 pm    Post subject: Reply with quote

khayyam wrote:
tclover ... device hotplugging does in fact work with mdev, mdev can be configured to react to events and so setup usb devices, etc, (...)

The only real issue that anyone might have with dbus removal is the hard dependencies of DE's and/or their expectation that the dbus service will be running (ie, when using consolekit). If you're not using a DE, consolekit, etc, then its quite easy to have everything work without dbus ... well, you have to wrangle with useflags, and setup xorg without evdev, but its fairly simple to do so.
(...)


I was not _implying_ device hotplug in general but _only_ with X _itself_ with evdev(--I am aware of mdev device _hotplug_); nor implying D-Bus dependency in general,--because, as you're saying, a D-Bus free OS is manageable,--Well, depends on the usage/requirements, as said above, and as you're saying--DE or no DE environment.
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 3962
Location: Dallas area

PostPosted: Sat Jan 24, 2015 12:22 pm    Post subject: Reply with quote

evdev doesn't require dbus, but does require some variant of *udev, not sure if mdev works with it or not, maybe khayyam knows.
_________________
Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.0 (no-pie) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Sat Jan 24, 2015 12:52 pm    Post subject: Reply with quote

Anon-E-moose wrote:
evdev doesn't require dbus, but does require some variant of *udev, not sure if mdev works with it or not, maybe khayyam knows.

Anon ... evdev uses {e,}udev (exclusively) ... its not possible to have INPUT_DEVICES="evdev" set for xorg if {e,}udev isn't installed, and running, on the system ... so, mdev doesn't suffice.

best ... khay
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3383

PostPosted: Sat Jan 24, 2015 11:01 pm    Post subject: Reply with quote

An amusing thought...

I strongly suspect that dbus or libdbus is going to go virtual in the next few months. Eventually kdbus will most likely make it into the kernel, and hilarity will ensue as the stable-API fights begin. However there will come a time when there are firm users for both userspace and kernel dbus. After a brief peek, probably both dbus and libdbus are going to have to go virtual. (Some stuff uses the lib, some talks directly.)

They're not going to manage an overnight conversion getting the whole world to move from userspace to kernel dbus, no matter what night they pick. It just isn't going to happen that way, no matter how hard anyone holds their breath, whines, criticizes others for being laggards or haters. It's logistically impossible.

So if dbus and libdbus are virtual, how about adding a third implementation, maybe even using cleaner plumbing? Perhaps TIPC? I know it might be called misuse, but I suspect it would still be an improvement.

I'm stuck. I mentioned before that I like X notifications, and had dbus pretty well out of my system except for that. I forgot about one other thing, and there may be a few more. I've got over a decade of finances in gnucash.

Looks like gnucash requires libsecret, which requires gnome-keyring, which requires dbus. I'm stuck with dbus, as long as my money is stuck inside gnucash.

I have no idea how difficult a task it would be, making an alternative implementation of dbus based on say, TIPC. Today when I did my upgrades and got 3.18.3, I went ahead and added TIPC as a module, so I'm at least ready to investigate.

I wonder how much of the current performance problems of dbus are because they keep passing around "freedesktop.org" (or is that "org.freedesktop"?) perhaps multiple times with every message. EDIT - That's a joke, if it wasn't obvious.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
gwr
Apprentice
Apprentice


Joined: 19 Nov 2014
Posts: 194

PostPosted: Sat Jan 24, 2015 11:45 pm    Post subject: Reply with quote

depontius wrote:

Looks like gnucash requires libsecret, which requires gnome-keyring, which requires dbus. I'm stuck with dbus, as long as my money is stuck inside gnucash.


Sigh. This is what happens when we depend on middleware to use services on a local machine. Zero advantage and downsides too numerous to bother listing.

My computer is not the Internet. I don't want Internet solutions to trivial problems. Silicon Valley is responsible for breeding this Web-fad nonsense and now I need middleware to encrypt something.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sun Jan 25, 2015 12:08 am    Post subject: Reply with quote

tclover wrote:
Thanks steveL for...
grep -i tipc /usr/src/linux/.config:
# CONFIG_TIPC is not set

I did not know that such an (in-kernel) IPC was available till your previous post about it.

(Could somebody give an overview (short or _high_ level) of it regarding perf/latency/message compared to the infamous D-Bus?

You're more than welcome. :)
Not sure about performance and latency comparison, but this post ties together an overview, and links to the previous discussion with kernel-folks about it (the "we tried to talk to the networking folks, but they shot us down" discussion occasionally referred to as 'justification' for "so can we haz kdbus?")

Someone linked us to a page about performance of dbus vs dcop and orbit as well, where dbus was the slowest of all three, and GNOME's CORBA impl was the fastest, by far. DCOP was lovely and dbus is a shoddy replacement afaic, especially based on the amount of scripting there was for DCOP, and simply does not happen for dbus.
Quote:
Just asking... because I happen to have requested multiple times "why depending on D-Bus at all?" on a few things I use. And then... "we need an IPC in order to set up a communication between processes and be able to control... & provide functionalities if _this_ or _that_ service is available; and do not want waste ridiculous amount of time doing a _custom_ IPC." No viable alternative to suggest? Well then... D-Bus then.)

There's so many things wrong with that objection; it sounds to me like someone who simply does not know the existing interfaces. Arguing that using one of the N variants of IPC provided, is "custom" is simply nub.

Mind, I'm all for an easy-ipc lib; I just think it's only interesting if the admin can configure it, similarly to /etc/services, on a domain-specific basis. Other than that, the programmer should know how to use the standard APIs already, or they're wet behind the ears.
Quote:
Anybody noticed this: nobody mentioned TIPC on the review? or did I miss it?

I haven't seen it, but I imagine they'd simply be told "we talked to the networking folk before" without ofc mentioning that they didn't listen to a bloody word. (See the post a couple up from the linked one, to see what I mean.)

I'd love to see a DCOP-style interface on top of TIPC, and would be happy to put some code-time into helping out with it, for one.
(So long as we're not using C++ ;)
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Sun Jan 25, 2015 12:19 am    Post subject: Reply with quote

gwr wrote:
depontius wrote:
Looks like gnucash requires libsecret, which requires gnome-keyring, which requires dbus. I'm stuck with dbus, as long as my money is stuck inside gnucash.

Sigh. This is what happens when we depend on middleware to use services on a local machine.

gwr ... services? nay, "protocol stacks" ...

Code:
% equery -NC depgraph -l =net-wireless/bluez-5.2
 * Searching for bluez5.25 in net-wireless ...
 * dependency graph for net-wireless/bluez-5.25
 [  0]  net-wireless/bluez-5.25  x86
 [  1]  dev-libs/glib-2.40.2  (>=dev-libs/glib-2.28) x86
 [  1]  sys-apps/dbus-1.8.10  (>=sys-apps/dbus-1.6) x86
 [  1]  sys-apps/hwids-20141010  (>=sys-apps/hwids-20121202.2) x86
 [  1]  net-print/cups-1.7.5  (net-print/cups) x86
 [  1]  dev-libs/libical-0.48-r2  (dev-libs/libical) x86
 [  1]  sys-libs/readline-6.2_p5-r1  (sys-libs/readline) x86
 [  1]  sys-apps/systemd-9999  (sys-apps/systemd) M[package.mask]
 [  1]  virtual/udev-215  (>=virtual/udev-172) x86
 [  1]  virtual/pkgconfig-0-r1  (virtual/pkgconfig) ~x86
 [  1]  dev-lang/python-2.7.9-r1  (>=dev-lang/python-2.7.5-r2) x86
 [  1]  dev-lang/python-3.4.2  (dev-lang/python) M[package.mask]
 [  1]  dev-lang/python-3.3.5-r1  (>=dev-lang/python-3.3.2-r2) M[package.mask]
 [  1]  dev-python/dbus-python-1.2.0-r1  (>=dev-python/dbus-python-1) x86
 [  1]  dev-python/pygobject-2.28.6-r55  (dev-python/pygobject) x86
 [  1]  dev-python/pygobject-3.12.2  (dev-python/pygobject) x86
 [  1]  sys-devel/automake-1.13.4  (>=sys-devel/automake-1.13) x86
 [  1]  sys-devel/automake-1.15  (>=sys-devel/automake-1.15) [~x86 keyword]
 [  1]  sys-devel/autoconf-2.69  (>=sys-devel/autoconf-2.69) x86
 [  1]  sys-devel/libtool-2.4.2-r1  (>=sys-devel/libtool-2.4) x86
[ net-wireless/bluez-5.25 stats: packages (20), max depth (1) ]

hehe ... "standard socket interface to all layers".

best ... khay
Back to top
View user's profile Send private message
gwr
Apprentice
Apprentice


Joined: 19 Nov 2014
Posts: 194

PostPosted: Sun Jan 25, 2015 12:28 am    Post subject: Reply with quote

khayyam wrote:

gwr ... services? nay, "protocol stacks" ...


That just makes me sad.
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3383

PostPosted: Sun Jan 25, 2015 1:23 am    Post subject: Reply with quote

khayyam wrote:

Code:
% equery -NC depgraph -l =net-wireless/bluez-5.2

hehe ... "standard socket interface to all layers".


But from the bluez page you referenced...
"The BlueZ kernel modules, libraries and utilities are known to be working prefect on many architectures supported by Linux."

It's working prefect. (Cheap shot, I know. My wife is into language, annoyed by misuse, and sometimes it rubs off on me.) ("loose" instead of "lose" gets to me too, because of how common it seems to be.)
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Sun Jan 25, 2015 2:10 am    Post subject: Reply with quote

depontius wrote:
It's working prefect.

depontius ... which makes prefect sense ... its was *already* prefected before it was "working" :)

best ... khay
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3383

PostPosted: Sun Jan 25, 2015 2:32 am    Post subject: Reply with quote

On a more serious note... I want a shim. I want a way out of dbus-dependence. I didn't know better when I started using it, but I do now, and I'm trapped.

(This is why I think that at the right point, shims for systemd-* might be a very good idea.)

1 - Unknowingly using bad software.
2 - Use shim to stop using that bad software.
3 - (minor miracle)
4 - Do things the right way.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Sun Jan 25, 2015 2:42 am    Post subject: Reply with quote

depontius wrote:
On a more serious note... I want a shim. I want a way out of dbus-dependence. I didn't know better when I started using it, but I do now, and I'm trapped.

depontius ... I think most everyone is going to disagree with you on this (again), myself included. I won't go over old ground, but I don't think shims will make a blind bit of difference. I'm inclined to think you'll get your wish ... but it'll be more of the same, and further testament to the depths of the problem.

best ... khay
Back to top
View user's profile Send private message
tclover
Guru
Guru


Joined: 10 Apr 2011
Posts: 516

PostPosted: Sun Jan 25, 2015 9:51 am    Post subject: Reply with quote

depontius wrote:
So if dbus and libdbus are virtual, how about adding a third implementation, maybe even using cleaner plumbing? Perhaps TIPC? I know it might be called misuse, but I suspect it would still be an improvement.


This is just... a wild guess--you should take a look on TIPC before talking about it being a valid alternative. I've took a quick look and it seems it's based on TCP (and connection communication friendly) and then share the sames caveats: no way to make a low latency, multicast IPC out from it... no idea on perf side. (I gave up on the introduction because of its complexities... it's almost seem more complicated than kDbus on first glance... and kDbus might have a chance with the new filesystem implementation: domain = mount point; bus = directory; conection = file inside a bus... I just get bored and stopped reading kdbus.text compared to... well, you know what I mean.

depontius wrote:
I'm stuck. I mentioned before that I like X notifications, and had dbus pretty well out of my system except for that. I forgot about one other thing, and there may be a few more. I've got over a decade of finances in gnucash.


Depending on anyting depending on gnome-keyring is crazy: that thing brings too many GNOME/SystemD OS bloat/crap.

EDIT: multicast (above): refer to the ability to send a message to a bus with broadcast option--client subscribed to broadcast receive it--for kDbus; and multicast in TIPC... a client has to send the message to _each_ client (in which case, the client shoud have an opened communication to/from _each_ client.) Which way is easier (app side)? ... the latter require the apps managing too many connections to other client; and the former requires only a single connection to a bus.

EDIT2: Thanks to SteveL for that overview... so the previous EDIT should be alleviated in regard of what TIPC offer to subscribe to service (port name.) Now, why is D-Bus so popular when a _better_ alternative is there? (Well, TIPC seems complicated... but even then D-Bus is worse with a no workable known API.)
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/


Last edited by tclover on Sun Jan 25, 2015 10:39 am; edited 1 time in total
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sun Jan 25, 2015 10:13 am    Post subject: Reply with quote

tclover wrote:
This is just... a wild guess--you should take a look on TIPC before talking about it being a valid alternative. I've took a quick look and it seems it's based on TCP (and connection communication friendly) and then share the sames caveats: no way to make a low latency IPC out from it... no idea on perf side.

Huh? What do you base that on?

The section on existing protocols specifically discusses TCP and why it's not so useful in the local context, similarly for SCTP. In a nutshell, they have to deal with situations that simply do not arise in a local cluster, nor indeed within a node.

So I cannot see what the above assertion is based on, at all. Sure, we don't need several layers from TIPC for a local-node setup, but that only means there's less to do at runtime, and less to worry about.

It certainly is not based on TCP, that I have read so far. The possibility of using TCP (or SCTP) as a bearer is another matter, akin to many other situations, like running ssh over TCP.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sun Jan 25, 2015 10:37 am    Post subject: Reply with quote

tclover wrote:
EDIT: multicast (above): refer to the ability to send a message to a bus with broadcast option--client subscribed to broadcast receive it--for kDbus; and multicast in TIPC... a client has to send the message to _each_ client (in which case, the client shoud have an opened communication to/from _each_ client.) Which way is easier (app side)? ... the latter require the apps managing too many connections to other client; and the former requires only a single connection to a bus.

That's incorrect too; "multicast" in the TIPC spec refers to multicasting across nodes on the network (as this obviously requires more work on the part of the protocol stack.)

I put up in this post an extracted summary from Ying Zue's mail; this bit was cut out:
Ying Zue wrote:
TIPC multicast mechanism is very useful for D-Bus. It has several cool and powerful special features:

1. It can guarantee multicast messages are reliably delivered in order.

2. It can support one-to-many and many-to-many real-time communication within node or network.

3. It also can support functional addressing which means location transparent addressing allows a client application to access a server without having to know its precise location in the node or the network.

In this case, he's talking about multicasting to processes (clients, or ports), which is the dbus use-case.
For easy discussion purpose, this is the rest of what I'd extracted:
Ying Xue wrote:
The basic unit of functional addressing within TIPC is the port name, which is typically denoted as {type,instance}. A port name consists of a 32-bit type field and a 32-bit instance field, both of which are chosen by the application.

Often, the type field indicates the class of service provided by the port, while the instance field can be used as a sub-class indicator. Further support for service partitioning is provided by an address type called port name sequence.

This is a three-integer structure defining a range of port names, i.e., a name type plus the lower and upper boundary of the instance range. This addressing schema is very useful for multicast communication.

For instance, as you mentioned, D-Bus may need two different buses, one for system, another for user. In this case, when using TIPC, it's very easy to meet the requirement:

We can assign one name type to system bus, and another name type is to user bus. Under one bus, we also can divide it into many different sub-buses with lower and upper.

For example, once one application publishes one service/port name like {1000, 0, 1000} as system bus channel, any application can send messages to {1000, 0, 100} simultaneously.

One application can publish {1000, 0, 500} as sub-bus of the system bus, another can publish {1000, 501, 1000} as another system sub-bus.

If a process sends a message to port: {1000, 0, 1000}, it means the two applications including published {1000, 0, 500} and {1000, 501, 1000} both receive the message.

So messages absolutely can be "multicast" in the dbus-sense of the word; it is in fact a lot easier.

Note I'm not saying it's all milk and honey, nor do I have any special expertise, and am making no claim to authority about any of this. I just think TIPC is a much saner basis.


Last edited by steveL on Sun Jan 25, 2015 10:47 am; edited 1 time in total
Back to top
View user's profile Send private message
tclover
Guru
Guru


Joined: 10 Apr 2011
Posts: 516

PostPosted: Sun Jan 25, 2015 10:47 am    Post subject: Reply with quote

steveL wrote:
tclover wrote:
This is just... a wild guess--you should take a look on TIPC before talking about it being a valid alternative. I've took a quick look and it seems it's based on TCP (and connection communication friendly) and then share the sames caveats: no way to make a low latency IPC out from it... no idea on perf side.

Huh? What do you base that on?
(...)


http://tipc.sourceforge.net/doc/draft-spec-tipc-10.html#anchor4 wrote:
TCP [RFC0793] has the advantage of being ubiquitous, stable, and wellknown by most programmers. Its most significant shortcomings in a real-time cluster environment are the following:

* It lacks any notion of service addressing and addressing transparency. Mechanisms exist (DNS, CORBA Naming Service) for transparent and dynamic lookup of the correct IP-adress of a destination, but those are in general too static and expensive to use.

* TCP has non-optimal performance, especially for intra-node communication and for short messages in general. For intra-node communication there are other and more efficient mechanisms available, at least on Unix, but then the location of the destination process has to be assumed, and can not be changed. It is desirable to have a protocol working efficiently for both intra-node and inter-node messaging, without forcing the user to distinguish between these cases in his code.

* The rather heavy connection setup/shutdown scheme of TCP is a disadvantage in a dynamic environment. The minimum number of signaling packets exchanged for even the shortest TCP transaction is seven (SYN, SYNACK etc.), while with TIPC this can be reduced to two, or even to zero if "implicit connect" is used.

* The connection-oriented nature of TCP makes it impossible to support true multicast.

SCTP [RFC2960] is message oriented, it provides some level of user connection supervision, message bundling, loss-free changeover, and a few more features that may make it more suitable than TCP as an intra-cluster protocol. Otherwise, it has all the drawbacks of TCP already listed above.

Apart from these weaknesses, neither TCP nor SCTP provide any topology information/subscription service, something that has proven very useful both for applications and for management functionality operating within cluster environments.

Both TCP and SCTP are general purpose protocols, in the sense that they can be used safely over the Internet as well as within a closed cluster. This virtual advantage is also their major weakness: they require funtionality and header space to deal with situations that will never happen, or only infrequently, within clusters.


(Trying to read other things... in the same time.)
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sun Jan 25, 2015 10:52 am    Post subject: Reply with quote

Well thanks for quoting the part I referred to, as it shows you misread it.

Could have just said that, though, instead of presenting it as if it answered my point.
Back to top
View user's profile Send private message
tclover
Guru
Guru


Joined: 10 Apr 2011
Posts: 516

PostPosted: Sun Jan 25, 2015 10:55 am    Post subject: Reply with quote

steveL wrote:
(...)
Could have just said that, though, instead of presenting it as if it answered my point.


Indeed! Just, trying to make room for reading... and not to get lost.

EDIT: I see... I've read the ref. link to the reply of TIPC maintainer/author to "netdev" kernel mailing list... What a suprise! A 3 years old message with SystemD cabals & kDbus authors on the CC list. Now, somebody has to make the link between this old thread to the current kDbus review...

Thanks! (again)
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sun Jan 25, 2015 4:58 pm    Post subject: Reply with quote

No worries; sorry if I was a bit grumpy. I'd dug out info for you, and was feeling a bit put-upon. The drama ;-)
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3383

PostPosted: Mon Jan 26, 2015 1:35 pm    Post subject: Reply with quote

khayyam wrote:
depontius wrote:
On a more serious note... I want a shim. I want a way out of dbus-dependence. I didn't know better when I started using it, but I do now, and I'm trapped.

depontius ... I think most everyone is going to disagree with you on this (again), myself included. I won't go over old ground, but I don't think shims will make a blind bit of difference. I'm inclined to think you'll get your wish ... but it'll be more of the same, and further testament to the depths of the problem.

best ... khay


I'm curious about this. Previously I was suggesting shims as a migration path away from systemd-* interfaces. However the general fear was that shims would legitimize those interfaces, rather than act as a path away. I wasn't intending their use that way at all, but I'm a bit dismayed to see that as part of the Devuan announcement they're planning shims in precisely the way others feared, and not as I hoped.

However I believe the situation is different with dbus. It is already an established, "legitimate" inteface, no matter how much several people here may dislike it. A dbus shim would do nothing to legitimize it, and would pretty much only be the start of an escape path.

This weekend I also took a preliminary look at what it might take to make gnucash fork at libsecret. I'm not using gnome-keyring anyway - in fact as far as I can tell the relevant directories were dangling symlinks left over from when I did a minor disk reorganization a year ago (My /home is on nfsv4, but I also have a /local mounted on the machine - handy for firefox/thunderbird directories and their sqlite files.) and therefore impossible to use.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Mon Jan 26, 2015 2:26 pm    Post subject: Reply with quote

depontius wrote:
khayyam wrote:
depontius wrote:
On a more serious note... I want a shim. I want a way out of dbus-dependence. I didn't know better when I started using it, but I do now, and I'm trapped.

I think most everyone is going to disagree with you on this (again), myself included. I won't go over old ground, but I don't think shims will make a blind bit of difference. I'm inclined to think you'll get your wish ... but it'll be more of the same, and further testament to the depths of the problem.

I'm curious about this. Previously I was suggesting shims as a migration path away from systemd-* interfaces. However the general fear was that shims would legitimize those interfaces, rather than act as a path away.

depontius ... its not a question of "legitimising" but complexity of design, its actually a lot more difficult to swim with (inflatable) arm-bands, or ride a bike with stabilisers, and they don't help particularly when try to learn how to do so (if anything they get in the way). They are adopted for other reasons (ie, safety, psychology, etc) but are more a hindrance than a help (the body is actually quiet buoyant in water, and momentum provides most of whats needed for balance). The problem with computers/software is that we've adopted arm-bands and stabilisers in the form of "usability" and it acts as a hindrance to use, because like arm-bands and stabilisers it don't actually help if we consider the environment computers provide (they are not brains that can magically understand the user, its the user that is in fact the interface). This is the primary conception of computing that has developed since the late 70's, everything is focused on the computer (which has no intelligence, it "computes", that is, undertakes repetitive tasks based on commands). This has lead us to where we are now, the demands of this metaphor now make all the "shims" (in the form of "usable interfaces") necessary for the computer to fulfil the role of a tool.

I could go on ... but that's a general outline of how we come to have something like the userspace we have (so, gnucash depends on gnome-keychain depends on dbus, etc, etc).

best ... khay
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3383

PostPosted: Mon Jan 26, 2015 2:51 pm    Post subject: Reply with quote

khayyam wrote:

I could go on ... but that's a general outline of how we come to have something like the userspace we have (so, gnucash depends on gnome-keychain depends on dbus, etc, etc).

best ... khay


I'm capable of being purist, but also know that I need to be practical at times, too. From a practical side I see four options:
1 - Get my money out of gnucash and into something else - but what?
2 - Patch gnucash or libsecret to do away with gnome-keyring.
3 - Some sort of dbus shim.
4 - Just live with it, and ignore that fact that there's some ugly plumbing in there.

So right now I see two reasons I have dbus on my system - gnome-keyring and I like notifications.

I see what you said about the complexity problems with shims, but which of option #3 or #4 would you say is worse?
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
tclover
Guru
Guru


Joined: 10 Apr 2011
Posts: 516

PostPosted: Mon Jan 26, 2015 6:44 pm    Post subject: Reply with quote

steveL wrote:
Mind, I'm all for an easy-ipc lib; I just think it's only interesting if the admin can configure it, similarly to /etc/services, on a domain-specific basis. Other than that, the programmer should know how to use the standard APIs already, or they're wet behind the ears.


This shouldn't be difficult to implement with such an easy API... I remove the "difficult API" said previously! I second a lib for that kind of things... to give at least a "named service" (string) translated to a (TIPC) "named port" {TYPE,INSTANCE} (two 32-bits integer.) It will certainly help... What about a "bearer" (link) implementation?

I'm yet to finish reading the specs, but, so far so good. The API looks almost more easy to grasp... for even the "simpler" (than D-Bus) kDbus, minus the "bearer" link left to be implemented (which a TCP-like or not choice.) And the ZONE/CLUSTER/NODE address space & one-to-many(multicast+broadcast)/many-to-one/one-to-one(unicast (low latency)) make kDbus' domain/bus/connection counterpart... almost a toy.

(Some facts: kernel(good config)+JACK gives a ~20ms latency; or ~<10ms for RT kernel.)

Direct peer-to-peer (or one-to-one) communication (for low latency) on ~weak~ hardware achieve a ~100us for Round Trip Time (send+receive message) is not that bad... (The 4us of kDbus is not trustworthy considering the politics of systemD cabals.)

PS: I added net-misc/tipcutils-2.0.3 on my overlay (it has a cmdline utils for AF_TIPC ("ports") sockets creation compared to version 2.0.0 available in the official tree); and dev-perl/IO-Socket-TIPC in order to test a few things for those interested...
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Mon Jan 26, 2015 7:30 pm    Post subject: Reply with quote

depontius wrote:
I'm capable of being purist, but also know that I need to be practical at times, too. From a practical side I see four options:

1 - Get my money out of gnucash and into something else - but what?
2 - Patch gnucash or libsecret to do away with gnome-keyring.
3 - Some sort of dbus shim.
4 - Just live with it, and ignore that fact that there's some ugly plumbing in there.

I see what you said about the complexity problems with shims, but which of option #3 or #4 would you say is worse?

depontius ... if I imagine the above as the options provided in some role play game then I'm to choose, but my choice is based on being a participant, I could have opted not to enter the kingdom of gnucash and instead entered the forest of sqlite ... it would then have been trivial to extract myself from the choices above and to build a raft to cross the stream of doo-doo. So, I read the above as an outcome, rather than something inevitable that I'm now forced to extricate myself from ... that's not about "purism", its about design ... and the point still stands, if you follow the logic of shims (be they dbus shims, interface shims, or whatever "stop gap" measures) then its this that creates the limits imposed by the above set of choices. You can say "that isn't practical" look at the current doo-doo I'm in ... but I'm still in the position to reflect on how you ended up there, and advise you not to build a platform on such a foundation so you can clean your boots :)

best ... khay
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Goto page Previous  1, 2, 3 ... 6, 7, 8 ... 25, 26, 27  Next
Page 7 of 27

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum