Why do we need d-bus?

BSD-Kitsune there's reluctance to fix these things in ports. They want to keep everything fully compatible with full desktops.

In my theory, it's worth seeing that there are a few subsystems, that everything or most works on top of, and proving it can be done. I also wouldn't be surprised if code becomes better, and it's found that 50% or almost 75% of code isn't needed, while adding minimal improvements to get full functionality for everything. I can't fully explain it, except where I found redundancy, and pointed it out, to show hours worth of compiling was unnecessary then they were like oh! I still find unnecessary dependencies, but there's more reluctance now, because it's not as obvious of half days of additional compile time. There are a few major different belief modes on this. My dream is to see a forked ports tree, which would work directly on top of FreeBSD. Then, look at it like, what actual tangible feature is desired, than including every dependency that offers excess redundancy.

Apple has 1 subsystem for each feature, which isn't common in OS'es. It has Bonjour, and not different implementations of Avahi and friends. It has its own implementation of each function it needs, and not so many to do 1 task.
...

I came across resources like this recently, then thought about this thread: https://specifications.freedesktop.org/wm-spec/wm-spec-1.3.html

I don't know if Inter-Client Communication Conventions Manual (ICCCM) is an alternative or if it performs enough of the same function as dbus. If it is, I wouldn't be surprised if someone will insist it isn't because it isn't a Linuxism without explaining a basic difference. I was going to read into ICCCM anyway, which I will eventually do.

Actually, some programs work without dbus, and even run faster without it. That alone, tells me, I can do without it, and don't need whatever so-called feature it provides.
 
Domain sockets aren't the same thing as STREAMS. I'm not gonna sit here and try to convince people it's a better option, but it hooks into SunRPC on Solaris and HP-UX, it has a long history of use, and as it functions in the kernel, it solves basically everything that kdbus and dbus set out to do in a UNIX manner. that's all. :)



I think that it speaks volumes about how much software in the ports tree is ported with care. Read: not a lot of it. A lot of it is haphazard and careless. Remember Tomahawk? Never got that building on FreeBSD despite being in ports :(.



STREAMS has been around for over a decade prior. it's also well-documented enough that anyone could implement it in the kernel and keep it updated (illumos also has a FOSS-licensed version in its kernel that could be used or studied for reimplementation in BSD world.) The answer is that the BSDs have an allergy to good things that originated in System V land, seemingly, and GNU/Linux constantly is looking to reinvent the wheel and force it on those seen as clients of it.



The answer is simple IMHO -- maintain what we can, discard what we can't and perhaps it's time for the Ports tree to be pared down where the quality of ported software can go up. Otherwise, FreeBSD will continue to have shovelware ports.



The design philosophy of Windows and other proprietary OSes is the other face of the coin that is the BSDs, illumos and other fully integrated OS releases of its kind. One is free, the other is proprietary. Everything in a Windows base install is made by MS and supported by MS directly. Same story with the BSDs and illumos. GNU/Linux is a patchwork that ranging from distro, is "fine/okay" (such as the old CentOS, RHEL, SuSE etc. where there's actual care in putting together packages) to "OH MY GODS WHY IS IT LIKE THIS???" for bleeding edge/rolling release distros like Arch and Gentoo (at least Gentoo's community isn't full of toxic teens, though.)



I'm not sure whom this is directed towards, but I'd say that it's better to ask the people involved in the mudslinging to leave the thread/delete his/her posts rather than locking the thread as some sort of collective punishment. Have I been civil? I believe so, as have others, even msplsh has, despite him seemingly vehemently opposing my instances. One of us is fine being a client to Apple or GNU/Linux, while the other craves the era of self-sufficiency and productiveness that he feels has left the BSDs.
To be honest, this thread is an interesting read for me. I had no idea about dbus being that important to usability of UNIX desktop. For me, it was always a 'Set and forget' feature. The "OH MY GOD, WHY IS IT LIKE THIS??" debates - yeah, it shows that people can be stubborn about the strangest things. Yeah, you need IPC. Yeah, people are gonna disagree about details of implementation. I just cherry-pick the details of implementation, and sometimes, I can make sense of it, and realize "Yeah, nice and workable design. Yeah, some things are not gonna work as expected because of that design". Yeah, it can be frustrating if your favorite piece of software is now refusing to work correctly. But for me - that comes with the turf.
 
The answer is simple IMHO -- maintain what we can, discard what we can't and perhaps it's time for the Ports tree to be pared down where the quality of ported software can go up. Otherwise, FreeBSD will continue to have shovelware ports.
Dropping support for things that require/use DBus is a sure fire way for nobody to use FreeBSD. OpenBSD and NetBSD are right there for people who don't want GUIs.
 
Dropping support for things that require/use DBus is a sure fire way for nobody to use FreeBSD.
There are enough users including desktop users who don't want a system with lots of things like dbus. For me, I can tolerate dbus. If it goes, that would be good for me. Better yet, Avahi being replaced completely by another Zeroconf implementation, or Alsa or Pulseaudio being completely replaced by a few implementations including Portaudio.

The ones who want these things, it would lose them, and it wouldn't be good to do that. Ports needs a fork, with subsystems and libraries that aren't dbus and Linuxisms. That's a dream, but this way, everyone can be happy.

For now, dbus can be so that, it's not a hard dependency for anything, as it's made an option, so those who don't want it can turn it off and build it.
 
Apple has 1 subsystem for each feature, which isn't common in OS'es. It has Bonjour, and not different implementations of Avahi and friends...
Better yet, Avahi being replaced completely by another Zeroconf implementation...
Apple's single mDNS implementation is open source and there's a port for it, net/mDNSResponder. This however did not suit Mr. Poettering, for some reason. Maybe because it does not need Dbus. In any case, he's the big fish in the tiny Linux desktop pond. Unfortunately our pond is even smaller, and it's therefore unlikely we'll be able to sway the open source desktop.

No way we can wag that dog, to engage in an unfortunate mixed metaphor. Best I can do is wage a losing guerilla war by turning off Poettering-ware whenever possible, and living without whatever makes it mandatory.

Maybe adding a Dbus option to the x11-toolkits/qt5-gui port is a good project for tonight.
 
Apple's single mDNS implementation is open source and there's a port for it, net/mDNSResponder.
Thread what-is-zeroconf?.79651
This however did not suit Mr. Poettering, for some reason. Maybe because it does not need Dbus. In any case, he's the big fish in the tiny Linux desktop pond. Unfortunately our pond is even smaller, and it's therefore unlikely we'll be able to sway the open source desktop.
No way we can wag that dog, to engage in an unfortunate mixed metaphor. Best I can do is wage a losing guerilla war by turning off Poettering-ware whenever possible, and living without whatever makes it mandatory.

Maybe adding a Dbus option to the x11-toolkits/qt5-gui port is a good project for tonight.
It doesn't need to be some type of war. A [port tree] fork would be easier to maintain, because less overhead from dependencies by 3 fold for some cases. The motto of it would be, don't use a Poettering implementation if a BSD-like implementation exists. Then, let them later say, "oh! this one is so much better, than the one I'm using!" If they happily want to reintroduce bloat, let them on another project or on their own.

Making it an option or turning things like that off is good for now.
 
Thanks! You saved me a bunch of time. I was wondering what all the various mDNS ports were.
It doesn't need to be some type of war. A fork would be easier to maintain, because less overhead from dependencies by 3 fold for some cases. Then, let them later say, "oh! this one is so much better, than the one I'm using!"
I'm not sure what you mean. Your own page lists 3 live alternatives to Avahi. Why is another fork needed?
 
I'm not sure what you mean. Your own page lists 3 live alternatives to Avahi. Why is another fork needed?
A fork of a ports tree, not of a Zeroconf implementation. If enough suitable implementations already exist, another fork isn't needed and would add another problem of choice when there's not a good enough reason for it.
 
Keep in mind, D-Bus itself was authored by Havoc Pennington and as such it doesn't qualify as Lennartware.
Yep. In my mind, Pennington is an earlier and less successful version of Poettering. He had Microsoft envy instead of Poettering's Apple envy. Pennington is a former Redhat employee as well. Dunno if he overlapped with Poettering.
 
It may not even be dbus in itself so much. It slowed down my applications. A significant amount of that is it intertwined with other weighted dependencies. Dbus on its own would slow down my applications anyway, but perhaps more because of the dependencies that it gets loaded down with by association. Turning it off, when I can doesn't cause problems for me.

It was pointed out that dbus has problems. It seems like not as much problems as other Linux-type suites that pull in so much.
 
Well, I like Typesafe Config quite a bit, so less successful sounds about right.

He had Microsoft envy instead of Poettering's Apple envy.
None of these (common IPC standard; config store with an API) are inherently bad ideas — it's mostly (lack of) implementation quality that sets freedesktop projects apart. That said, I didn't look at the D-Bus source code at all nor do I want to.
 
Ports needs a fork, with subsystems and libraries that aren't dbus and Linuxisms. That's a dream, but this way, everyone can be happy.
Isn't that why we have Poudriere? Lots of people have their own Poudriere repos, where they can set their own options. Heck, you can play "Poudriere golf", where you show off your own spin of FreeBSD repos that is free from dbus and whatever that sound system is called - oh, just remembered - PulseAudio! :p
 
It needs to be a shared repository, where the better settings help everyone get rid of Avahi, and where contributions help everyone that agrees that there's too much redundancy of dependencies that do the same thing. A standardized repository, that has shared improvements. The current repository there's a lot of reluctance for improvements. And so that, every single person doesn't have to rebuild everything, while they can rebuild and improve parts of it, and that benefits everyone who uses it. "Use Poudriere" I keep getting this same response, when I would have to have a side Makefile, and maintain that all on my computer to only benefit me, only for it to get erased on the next ports tree update. When a few people on here are saying why is dbus a hard dependency. I can change this on my own computer. It needs to be set for everyone. This has traction, so will get done. And one of the big reasons a ports fork is needed, because there's reluctance to fix things, that I can fix on my own computer. When, I used to make an improvement on my computer, and it was used, and actually made things a lot better. I got discouraged with improving this ports tree, because it seems stale as it wasn't before or because of reluctance to improve things. There needs to be a whole portstree without ALSA, Pulseaudio, Avahi, so it there's no chance of it getting tangled up with other ports, and so these things can be actually fixed with a clear picture on a sort of cleaner slate, that doesn't worry about breaking some Gnome so-called feature.

All of Avahi, Pulseaudio, Alsa and other Linuxisms would be wiped out of it, when a BSD implementation exists. The rest of the desktop wouldn't be focused on Gnome or KDE. In my vision, Gnome wouldn't be in a ports-tree fork. Only some applications, and they would run on what everything else is running on. Everything is bloated only to make it work on Gnome. It would use a trimmed common gtk, with the differences being for gtk2 and gtk3. Additional dependencies would be out.

You're missing the picture. The response of "use Podriere" doesn't fix the actual ports tree to reduce Potterisms. Fix the ports tree makes more sense, but anything that doesn't have a maintainer sits there, or they insist on running it the Linux way. I may become a maintainer of a few ports one day. No one else should have 3 additional sound systems on their computer, unless it's for cross platform portability, unless they absolutely want to run Linux. A whole ports system needs to be standardized, without having a whole set of excessive Linuxisms unless there's no other implementation, which for many Linuxisms there's better implementations.

Why spend weeks at a time fixing a ports tree only on my computer, to benefit no one else, when these diffs, don't go anywhere, when the regular ports tree insists on keeping Linuxisms. The only way a system is going to be cleaned up is to start it by leaving out Linuxisms when better implementations exist. Can't do it on a system that is reluctant.

One day, perhaps I may make a shared repo, with a different standard, perhaps on Github or host my own website and pass it off to shared users.

I could spend a month to make, then compile a whole portstree for myself for something that only suits me, then I'll have to redo a lot of that and the compiling again, after the next year or 6 months. And I would have to spend a whole lot of time, putting in my own diffs, after updating the portstree each time. Sure, I'll spend that much time for something that doesn't benefit anyone, not even me, because the purpose would be, if I or anyone else did spend that much time, it should benefit more people. And the load would be shared, thus, everyone even the ones who do it spend a whole lot less time compiling even the whole thing on their own. The purpose would be to make it better, spending a month, for something that I would have to adjust for every portstree update, defeats the purpose of making something better by making it even more complicated, because I would show that something is better, but only I would be fixing it again in a way, that's excessively complicated for what, to maintain a reluctance and dance around that, why don't they just use Linux. Or Maybe I should just get a Mac, so I don't have to explain how using 1 implementation is better than having 20 that do the same thing.

The ports tree is functional, but it can't be made much better, the way it needs to be, because of reluctance for making everything work with every Gnome bloat.
 
There's UNIX ways to solve this though.
...
For Sys V UNIX, there's STREAMS, ...
...
... and someone mentioned sockets as an alternative to D-Bus.

The deep misunderstanding here is that there is a huge difference between Streams/STREAMS, sockets, and D-Bus.

Streams/STREAMS (yes, the capitalization matters) is a genius kernel mechanism, originally invented by Dennis Ritchie and his team, then part of some Bell Labs Research Unix version (that came out after the Bell Labs / BSD split), and finally productized in SysV. The research version was called Streams, and the product version was called STREAMS; Dennis was highly critical of the product version. It was not a simple mechanism to allow two processes to talk to each other. Instead it was a software "discipline" or "design pattern" that allowed kernel modules and user processes to implement complex layered protocols (for example SNA on top of TCP on top of IP on top of SLIP on top of a line discipline on top of serial ports. For some reason (which I don't know in detail) it was never ported into BSD; my suspicion is that it was "not invented here" syndrome. Streams is completely content agnostic; one could use it to help implement something like D-Bus, but all the high level concepts would need to be added from scratch. It's like saying "a network is the same as two cans and a string": No, to build a functioning network at the application level you need to define protocols such as IP, DNS, DHCP, TCP, HTTP, and state the HTML semantics, in addition to having a low-level transport mechanism.

Sockets (domain or otherwise) are even lower level. They are intellectually just the two tin cans and a string: two parties, one sends bytes, the other gets it.

D-Bus is a much different beast. To begin with, it's not a point-to-point link, but a bus, with many senders and receivers. It has the capability to run virtual buses over it, it can support the publish/subscribe pattern with multiple listeners, and it assigns interestingly complex naming and semantic meaning to messages: They are not just unstructured streams of bytes.

For a modern desktop environment, you need something like D-Bus. And you need to build that something on top of a low-level communications mechanism, such as sockets or streams. A lot of the arguments against the existing implementation that's used in FOSS DEs is that it is associated with things and people (such as Linux or Lennart) that some people consider "evil"; that is a very weak argument to evaluate technology.
 
Dbus has nothing to do with Lennart Poettering at all. It's not one of his babies. kdbus was though, and it was burnt to shreds by Linus Torvalds, because his stance was "you want that in the kernel claiming you cannot get that speed in userland. But having looked at the userland thing, it's programmed so poorly that you just should clean that up instead of trying to get something like that into the kernel."

Sometimes it's nice to have a look in the Wikipedia for better understanding.

This picture below is a set of programs communicating to each other using the standard ways, meaning either sockets or TCP/IP, so in short without something like Dbus:
KSnev87.png


And this picture below is the same set of programs with Dbus instead:
FlNiSKl.png

The difference is quite clear. The advantage for programmers is that they don't have to wrap their head around any longer at how to talk to different programs, because the message bus has a clearly defined language set. So learning that language is enough to talk correctly to all programs hooked up at that bus.
 
Do programs really need to talk to one another that much?

Just look at Gnome 3. Everything fails to communicate anyway. The automounter fails to communicate with the UI. The gvfs stuff fails to communicate with the UI. I am actually inclined to believe nothing communicates correctly. This isn't a modern desktop, it is a fragile mess.

KISS is important. If we don't keep to it, it always breaks in the end. The FOSS community is not reflective enough. We react and keep hacking away. If we really took a step back and had a think why we really need one big system bus for every program to send random messages to one another we might find it is over engineering.

For some use-cases, such as clustering, grids, etc. Then perhaps a central bus is required. But not for a basic desktop environment that *still* can't compete with the Windows 95 shell in terms of complexity and functionality.
 
FWIW, GNOME4 is out on the streets, but not in FreeBSD ports. The way I see it, that's because it's hard enough to keep up with KDE.

sidetone : you can have your own repo of Poudriere templates, and a blog on how to do it. If you have enough people replicating your efforts, you can try making a case for helping you get the word out. There's quite a few FreeBSD-based projects that you can use as lab rats for that. If you can make it work, then come back with a shining accomplishment to your name. That's the FOSS playbook for adjusting the main repos to work the way you want them to.
 
The difference is quite clear. The advantage for programmers is that they don't have to wrap their head around any longer at how to talk to different programs, because the message bus has a clearly defined language set. So learning that language is enough to talk correctly to all programs hooked up at that bus.

Dbus has far more to it than just IPC. It's a privileged daemon, object model, and more. It aims to replace RPC as well, and my argument is that SunRPC already serves a good purpose there. We don't need to follow the suit of GNU/Linux, and to me that absolutely means throwing GNOME, KDE, etc in the bin. In any case, even if you install all that and dbus etc. You're still stuck with an inferior experience and less supported platform to run these on. PC-BSD/Project Trident was trash because it didn't manage to overcome that inertia needed to break away into it's own thing.

... and someone mentioned sockets as an alternative to D-Bus.

The deep misunderstanding here is that there is a huge difference between Streams/STREAMS, sockets, and D-Bus.

Streams/STREAMS (yes, the capitalization matters) is a genius kernel mechanism, originally invented by Dennis Ritchie and his team, then part of some Bell Labs Research Unix version (that came out after the Bell Labs / BSD split), and finally productized in SysV. The research version was called Streams, and the product version was called STREAMS; Dennis was highly critical of the product version. It was not a simple mechanism to allow two processes to talk to each other. Instead it was a software "discipline" or "design pattern" that allowed kernel modules and user processes to implement complex layered protocols (for example SNA on top of TCP on top of IP on top of SLIP on top of a line discipline on top of serial ports. For some reason (which I don't know in detail) it was never ported into BSD; my suspicion is that it was "not invented here" syndrome. Streams is completely content agnostic; one could use it to help implement something like D-Bus, but all the high level concepts would need to be added from scratch. It's like saying "a network is the same as two cans and a string": No, to build a functioning network at the application level you need to define protocols such as IP, DNS, DHCP, TCP, HTTP, and state the HTML semantics, in addition to having a low-level transport mechanism.

Sockets (domain or otherwise) are even lower level. They are intellectually just the two tin cans and a string: two parties, one sends bytes, the other gets it.

D-Bus is a much different beast. To begin with, it's not a point-to-point link, but a bus, with many senders and receivers. It has the capability to run virtual buses over it, it can support the publish/subscribe pattern with multiple listeners, and it assigns interestingly complex naming and semantic meaning to messages: They are not just unstructured streams of bytes.

For a modern desktop environment, you need something like D-Bus. And you need to build that something on top of a low-level communications mechanism, such as sockets or streams. A lot of the arguments against the existing implementation that's used in FOSS DEs is that it is associated with things and people (such as Linux or Lennart) that some people consider "evil"; that is a very weak argument to evaluate technology.

I'm well aware that STREAMS doesn't specifically specify the protocol. but that's the beauty of it. The programmer may choose the best protocol for IPC.if your argument is for interoperability, as it stands and appears to be, then all someone needs to do is document a standard protocol and get a majority of people to agree to use it.

As I said above, I simply think that object modeling and UNIX/unix-like are fundamentally incompatible. If you want object/capability type stuff in an OS, UNIX is not for you, Plan9 is not for you.

My arguments are that dbus is specifically designed for GNU/Linux and to leverage specific technologies that are indigenous there. When those APIs and technologies are not present, such as cgroups, namespaces, etc. We are left with an inferior experience, and a daemon that isn't secure and is capable of things like activating other daemons and doing more things we probably should be questioning.

Therefore outside of that context it's irrelevant for us and we should throw it in the bin. If you disagree, I mean, get your Apple fix elsewhere I say. Apple's trash has message buses and more.if you want that level of interoperability.

For a modern DE, you don't need dbus. Look at IRIX Interactive Desktop, or CDE, or OpenLOOK. They didn't require that and other than the fact that their look and feel is (arguably) more primitive, you have everything you have in a modern desktop. Media panel on IID for volume control of various outputs. Screenshot capabilities and screen record capabilities. Comprehensive help documentation, graphical software installer, settings to change look and feel and save it etc.

Tooltalk was what IID used for some of that. Tooltalk can use STREAMS for higher level communication as well.

At risk of sounding like a broken record, if something doesn't happen, then the BSDs pthe
 
For a modern DE, you don't need dbus. Look at IRIX Interactive Desktop, or CDE, or OpenLOOK. They didn't require that and other than the fact that their look and feel is (arguably) more primitive, you have everything you have in a modern desktop. Media panel on IID for volume control of various outputs. Screenshot capabilities and screen record capabilities. Comprehensive help documentation, graphical software installer, settings to change look and feel and save it etc.
I am glad that others notice this. These older desktops often have more features than existing ones but with a fraction of memory usage and dependencies.

I suppose the problem is man power. Writing any desktop environment takes a lot of time for a small group. And those that are able to do it, often are technical or familiar enough to get by with a simple window manager and terminal.

That said, if ~10 of us got together and each did a few programs in the DE (almost like a game jam), I am fairly sure that good things could come from it in a weekend.

I even found a very competent terminal emulator using no dependencies other than FLTK the other day. In some ways, almost everything in a DE has already been made as "demo apps" for simple UI toolkits. All that it would really need is cleanup.

I could even see an entire DE as a single static executable. They are not complex things. GUI is easy, just time consuming.
 
D-Bus is a much different beast. To begin with, it's not a point-to-point link, but a bus, with many senders and receivers. It has the capability to run virtual buses over it, it can support the publish/subscribe pattern with multiple listeners, and it assigns interestingly complex naming and semantic meaning to messages: They are not just unstructured streams of bytes.
And this is exactly the problem. You came looking for a tool and you got handed a methodology. You just wanted to send simple messages between two apps, and you're going blind reading about security models and XML schemas. This in a nutshell is why things like Unix sockets win and things like Dbus lose.
For a modern desktop environment, you need something like D-Bus. And you need to build that something on top of a low-level communications mechanism, such as sockets or streams.
And yet here I am writing this in a desktop environment with no Dbus in sight. I must be doing it wrong.
 
I am glad that others notice this. These older desktops often have more features than existing ones but with a fraction of memory usage and dependencies.

I suppose the problem is man power. Writing any desktop environment takes a lot of time for a small group. And those that are able to do it, often are technical or familiar enough to get by with a simple window manager and terminal.

That said, if ~10 of us got together and each did a few programs in the DE (almost like a game jam), I am fairly sure that good things could come from it in a weekend.

I even found a very competent terminal emulator using no dependencies other than FLTK the other day. In some ways, almost everything in a DE has already been made as "demo apps" for simple UI toolkits. All that it would really need is cleanup.
[RANT] Yeah, can you make CDE look like KDE just by replacing the graphical elements with some lookalikes? I want my kio-slaves working properly, and to be able to copy-paste the errors straight from Konsole into Konqueror so that I can do my research on errors a bit better. Oh, and do it all in Wayland, while you're at it. [/RANT]
 
For a modern DE, you don't need dbus. Look at IRIX Interactive Desktop, or CDE, or OpenLOOK. They didn't require that and other than the fact that their look and feel is (arguably) more primitive, you have everything you have in a modern desktop. Media panel on IID for volume control of various outputs. Screenshot capabilities and screen record capabilities. Comprehensive help documentation, graphical software installer, settings to change look and feel and save it etc.
I guess we should come back discussing that point when your idea about "modern DE" is not from the last millenium, and roughly 30 years old.
 
And this is exactly the problem. You came looking for a tool and you got handed a methodology. You just wanted to send simple messages between two apps, and you're going blind reading about security models and XML schemas. This in a nutshell is why things like Unix sockets win and things like Dbus lose.
This thread is about how the user would like to tell the programmer how to "send messages between apps" despite not knowing a thing about it except there has to be a message broker that they can SEE in the process list and control if it starts up. If the user could be like "there are too many UNIX sockets here, how can I block them from opening?" they would do it.
 
Back
Top