Why do we need d-bus?

Many, many battle-tested free and open-source serialization/deserialization libraries out there. Or just use JSON or XML if that suits your purposes. There's no reason to re-invent this particular wheel in 2024.
What if you need the serialization library to be formally verified?
 
Many, many battle-tested free and open-source serialization/deserialization libraries out there. Or just use JSON or XML if that suits your purposes. There's no reason to re-invent this particular wheel in 2024.
People already have to integrate with Kafka and now they have to bring batteries? :rolleyes:
 
I think with wayland, the issue goes deeper, as there's a fundamental disagreement about what a display server should do. That's not only about network functionality (you can debate about that indeed, I don't think it hurts to include it, but whatever), but in the wayland thinking, the job of the display server is really nothing but "compositing" clients' windows together (and delivering the most basic input events). NO room for any server-side rendering, for window managers, for any communication between clients, etc pp. The result is that clients need a massive stack of supporting libraries, they MUST do their rendering locally, even draw their own window decorations, agree on some external communication mechanism about basic things like clipboard, and so on. I don't agree with that design at all, of course there are types of applications where it's the best choice to do everything client-side, but the vast majority of regular desktop applications could profit a lot from more functionality offered by the display server as in X.
I think that both are wrong, and that the Java's AWT API is more representative of what a good Display Server should do, better for security, retrofit new functionality, et cetera.
 
What if you need the serialization library to be formally verified?
That is a good point. Every parser is a potential security nightmare to happen, because downstream is a possibly shoddy input verification. Do I need to mention the "leading 0 letter name" in context to systemd? (that is a zero char, not O). IMHO they did that right in DBus, provide the methods and hide the layout of the data. And now you talk to every implementation under the sun and expect no buffer overflows, no RCEs?

Oh, right. It's all Rust or other memory safe languages. And systems today are fast, yes. I'm working embedded. There is no GHz is sight. There you feel it. Can we please give these folks a 286 running sinix for a project? So they can learn a thing or two?
 
Do not care, hate acronyms.
If you hate acronyms so much, then how about writing compete sentences? With correct grammar? That would be great.
And  In  My  Humble  Opinion would make communication much better. Thank you, and have a nice stay.
 
… please avoid acronyms, other than those of UNIX.

Readership of The FreeBSD Forums is not limited to people with knowledge of UNIX®-like systems.

Anyone who encounters a novel phrase, or acronym, might fairly easily discover its meaning through things such as search engines.

If novelties are a problem for non-English speakers: I am sympathetic, nonetheless this is definitely an English-only space.

Do not care, hate …

Instead of publicly criticising other people's styles of writing, instead of carelessly expressing hatred:
  • you might quietly learn, and enjoy doing so.

Thank you
 
I don't know what it means. Could please avoid acronyms, other than those of UNIX.
IMHO has been probably around already over 40 years now and has found its way to even corporate e(lectronic)-mails. Originally coming from USENET (sic! - an acronym again), before the Transmission Control Protocol was widely accepted by public. IMHO, there are always people hating acronyms.
 
OK folks, that should be enough. There is no need to flame him like the ceiling of a Ramstein concert hall.
 
FWIW, I didn't intend to flame him but to troll him ?. IMHO fair game, but your sense of humor might differ of course, so, sorry for the noise ?
 
  • Like
Reactions: mer
Well, I almost got rid of dbus. Only programs still needing it are qt6-base and at-spi2-core. I'd love to get rid of at-spi2 but that is a dependency of a lot of programs (gtk3 thing), and it's not possible to turn it off unfortunately.

PS1: I've built at-spi2-core with ATKONLY. This seems to remove the dbus dependency. So that leaves just qt6-base.
PS2: Even when the DBUS option is turned off in the browsers, they want to use dbus. Killing the dbus-launch process causes the browsers to be killed also.
 
At least I can try to use ports configured without dbus for my small prime list. But the browser and one DE will be problems. Modification of codes is beyond my reach. So I may not have much say in this thread. I have used devuan which was created/forked by only few gray bearded Unix admin. within a year. Now have found that few more Linux distro including Artix Linux do not use systemd and dbus. I am happy with present FBSD configured with my choices. Still don't like those two ( as forced ).
Edit: FBSD=FreeBSD
 
I have used devuan which was created/forked by only few gray bearded Unix admin. within a year.
This is a myth. They are not "UNIX admins", it took far longer than a year and it's not a fork, but a Debian Derivative directly based on Debian, with only the needed packages rebuilt.
 
Yes, you are right. I was using Debian that time and was following the bitter war/vote in their mailing world. That was all about 'Systemd'. The project ( big ? ) what may be termed as you like was copied by few people and started untangling the dependency chain of Systemd from over two (?) hundred packages from upstream one by one. Linux distribution infrastructure is totally different from FreeBSD. The foundation is interested only for the core OS for the servers. It was necessary to give space to huge apps only to be relevant in Desktop world. Few days after I also started using FreeBSD leaving Devuan . Here every apps/packages has its own maintainer. Now I have found that Xfce and even Firefox is dependent on Dbus, even if the service was not started. You may found that support for Wayland over Xorg has started increasing. With minimalism I may live with openbox and other apps of choice. My point is that to implement some policy a core group of maintainer is required only.
 
Killing the dbus-launch process causes the browsers to be killed also.
BTDT. However, as a dirty and pragmatic solution, since I don't want to compile everything I need to get rid of dbus, a simple
# chmod a-x /usr/local/bin/dbus*
lets me start Firefox and other programs that depend on dbus without problems.
 
What will happen after upgrades. Actually recently I had renamed dbus* but xfce refused to start. Again pkill dbus got firefox exited. But this port system give us some choice also.
 
Back
Top