Why do we need d-bus?

[fr0xk]

Uhm, there's just one (extensible) X protocol, which for communication purposes offers some "primitives" (events/messages are builtin for the most basic stuff, but can be synthesized by any client, general-purpose selections with owners and "window properties" are offered, X design philosophy was "mechanism over policy" after all), so most of the protocols you're probably talking about are those specified on top of these primitives (like in ICCCM and EWMH, but also additional ones).

These protocols, when used correctly, work well for all the common interoperability stuff you'd want on a desktop regarding applications that aren't "part" of that desktop -- unless of course your goal is to eliminate the X server.

I already said that I think d-bus conceptually makes sense for tightly integrated desktop environments. It's certainly better than every desktop coming up with its own solution, and a somewhat complex desktop environment certainly has a need for something like that.

But it annoys me that protocols based on d-bus now also attempt to replace well-working protocols based on X11. I don't want to have dependencies on d-bus in every random application. Case in point, for the x11/xmoji utility I'm currently building (which only makes sense on X11 anyways, not on wayland), I plan to add an optional "tray icon". There's an old protocol supporting that based on the XEmbed protocol, and a newer one utilizing d-bus. With the old one, you can simply have a regular X window for your icon and e.g. use XRender on it. I'll only implement that one, although the large desktops nowadays use d-bus "natively". At least KDE offers compatibility through some proxy service, so I don't see why I should pull in even more dependencies just for such a simple and optional thing ... if a desktop only supports the d-bus variant, well then, no icon there.

Wayland-based window managers and DEs can't run without it. Xorg is now in maintenance mode, and we all know its issues: screen tearing, flickering, etc. People have fought ideological flame wars over Xorg vs. Wayland for too long. Aside from a few OpenBSD devs, nobody cares about improving or maintaining Xorg. Frankly, I'm sick of all the talk with no code. Xorg is a massive project, and a few unpaid people can’t keep it alive. And I’m not interested in hearing a long-winded debate about UNIX philosophy—people argue about what it even means.

Too much time’s been wasted already on design philosophy debates. For me, UNIX philosophy is a guideline for building software in uncertain conditions. Simple systems are easier to debug and fix. But it's just a guideline, not a rule. The rest? I prefer to speak through code.

 

[kpedersen]

Xorg is now in maintenance mode

Thats a good thing. Maintenance means "feature complete" rather than "obsolete". Very few projects actually reach this state. They tend to just bloat outwards until they become horrible and get replaced.

Aside from a few OpenBSD devs, nobody cares about improving or maintaining Xorg.

Maintenance mode remember? Check out the git logs, maintenance is happening but doesn't require much work and this shouldn't be confused with "no-one cares". As for improvements, they will perhaps come once Wayland reaches parity and can bring new ideas to the table that are truely worthwhile. There could be good synergy between the two projects.
OpenBSD and Oracle alone are more than enough manpower to keep Xorg going long past our lifespan. A <5 person team has managed to maintain it quite happily for a decade so far.

screen tearing, flickering

Please refer to the TearFree option in i.e. amdgpu(4).

Frankly, I'm sick of all the talk with no code. Xorg is a massive project, and a few unpaid people can’t keep it alive.

You clearly haven't read through the codebase. Since KMS/DRM, the code is dead easy (no more complex user-mode drivers!). Most wayland compositors use the Xorg modesetting driver as a starting point for their own. Check the similarities for yourself:

• Xorg driver
• wlroots "backend"
• weston "backend"

Heck, for some projects I recommend just writing against libdrm directly. Its great. It feels like MS-DOS again

And I’m not interested in hearing a long-winded debate

Everything has been stated already by many people. The consensus is still split and both projects will still remain. And many are happy for them both to remain. Not every use-case needs a network aware display system (its overkill).... But some do and that is simply outside the scope of Wayland.

Nothing to do with the UNIX philosophy. Xorg and Wayland are both so far off that target haha!

 

[Jose]

Xorg is now in maintenance mode, and we all know its issues...

I'm guessing this is probably not your intent, but man you seem Hell-bent on pushing all the buttons!

 

[kpedersen]

I'm guessing this is probably not your intent, but man you seem Hell-bent on pushing all the buttons!

Hah. Next they are going to suggest that *neither* Vi(m) or Emacs are good choices for a text editor! Rendering the whole "editor wars" redundant.

 

[zirias@]

Not every use-case needs a network aware display system (its overkill)....

I wouldn't even buy that as an argument against X, I mean, I can't imagine the "networking" takes a huge share of the codebase. It's already using a binary protocol (so, de/ser can't get any simpler, except for this obscure feature of endianness conversion).

Sure, this stuff can be a performance penalty, but then, there's XShm ...

Nothing to do with the UNIX philosophy. Xorg and Wayland are both so far off that target haha!

Never actively thought about that, but sure, you're totally right! What links X to Unix is really nothing but the fact it's "always been there" (as long as there ARE GUIs on top of Unix systems).

 

[kpedersen]

I wouldn't even buy that as an argument against X, I mean, I can't imagine the "networking" takes a huge share of the codebase. It's already using a binary protocol (so, de/ser can't get any simpler, except for this obscure feature of endianness conversion).

Sure, this stuff can be a performance penalty, but then, there's XShm ...

Yep, good point.

And I suppose for most tasks where performance is important (i.e OpenGL/Vulkan), it is all direct mode anyway (since indirect mode has stagnated at GL pre-2.0 era) and we tend to use different tech for 3D streaming across a network anyway).

 

[Ferocious1881]

Have not read too long to put me at date in a reasonable amount of time thread, but have to said.
Having a central bus is useful in at least in some uses cases, like
1. Making that sandboxed processes, can request an Unix Domain Socket for IPC, as well to be granted a connections to the Unix Domain Socket of another sandboxed processes.
2. Making one-to-many messages, for applications that may requires, like a notification of a console job being terminated, for having some idea.

The point, is that, even if dbus is a bad software, what is supposed to offer is not something bad, and it probably should exists in any good Desktop Operating System.

 

[Ferocious1881]

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.

You have a pond big enough, such that taking good decisions, like adding unprivileged jails, can probably make you the desktop of choice if security matters and wipe away, the security vulnerability that is Linux.

Windows was at one time POSIX compliant

Windows only was compliant with a underspecified POSIX standard.

Solaris Doors IPC

Fun fact: there things are basically seL4 IPC.

Firefox detects it is offline it can use a network manager to reconnect

Really should a browser be granted such capability?

No, it's because dbus basically is designed to work on GNU/Linux. It will work elsewhere, but it runs often with extreme privileges and trust that should not be granted to daemons that can perform socket activation, config modifications, process start/stop, and other such privileged actions.

If Capsicum start consuming the FreeBSD kernel, it would be possible to do so, and securely.

There's nothing preventing a program from reading any and all data/messages that is passed through; nor is there anything controlling you from communicating on any of the channels. I've encountered multiple legit programs (non-hostile) that has to do it to "trick" the system to work around a serious limitations of the system. The part those programs in example manipulated, is more the inactivity counter and power management (preventing the screensaver/monitor power).

This makes such an hyprocrites of the Wayland workgroup at FreeDesktop.

Purposely not following the freedesktop specifications.

Then We need to make our own, if possible upstream to the Open Group.

 

[zirias@]

1. Making that sandboxed processes, can request an Unix Domain Socket for IPC, as well to be granted a connections to the Unix Domain Socket of another sandboxed processes.

What's that obsession with "sandboxes", whatever that should mean here? I can't make any sense of that paragraph ...

2. Making one-to-many messages, for applications that may requires, like a notification of a console job being terminated, for having some idea.

That's of course possible using the mechanisms X11 provides, for example window properties where anyone can subscribe to change events.

 

[Ferocious1881]

What's that obsession with "sandboxes", whatever that should mean here? I can't make any sense of that paragraph ...

Because all applications should be sandboxed by default, and only allowed to do things as they are registered in an permissions database, with also stores a cryptographic hash of the application being sandboxed.

whatever that should mean here? I can't make any sense of that paragraph ...

I will try to break it in two simpler offerings:
1. An application rather than calling connect(2) to an path of it's choice, the application will connect to the central buffer and request be given an service side unix domain socket to recive command and data from anothers processes. The adventage over just calling connect(2), is that either is inside of a sandbox which does not allow doing so, or because it wants to be searchable by other applications, or both. This also guarantees not collision in unix doman socket path.
2. It can do the same as 1, but as a client side of a unix domain socket.

That's of course possible using the mechanisms X11 provides, for example window properties where anyone can subscribe to change events.

X11 is too big of a project to require in all applications, that may not need it, as it breaks the UNIX philosophy of not being modular, also it misses sandboxing apis, and HDR.


It is a few unrelated, but the Linux manpage for pkexec says

WRAPPER USAGE
       To avoid modifying existing software to prefix their command-line invocations with pkexec, it's
       possible to use pkexec in a she-bang wrapper[1] like this:

           #!/usr/bin/pkexec /usr/bin/python

           import os
           import sys

           print "Hello, I'm running as uid %d"%(os.getuid())

           for n in range(len(sys.argv)):
               print "arg[%d]=`%s'"%(n, sys.argv[n])

       If this script is installed into /usr/bin/my-pk-test, then the following annotations

             [...]
             <annotate key="org.freedesktop.policykit.exec.path">/usr/bin/python</annotate>
             <annotate key="org.freedesktop.policykit.exec.argv1">/usr/bin/my-pk-test</annotate>
             [...]

       can be used to select the appropriate polkit action. Be careful to get the latter annotation right,
       otherwise it will match any pkexec invocation of /usr/bin/python scripts.

What kind of malburnerisch security malpractice is this?

 

[zirias@]

Because all applications should be sandboxed by default, and only allowed to do things as they are registered in an permissions database, with also stores a cryptographic hash of the application being sandboxed.

Well, that's an opinion. Let me add my opinion: No.

1. An application rather than calling connect(2) to an path of it's choice, the application will connect to the central buffer and request be given an service side unix domain socket to recive command and data from anothers processes. The adventage over just calling connect(2), is that either is inside of a sandbox which does not allow doing so, or because it wants to be searchable by other applications, or both. This also guarantees not collision in unix doman socket path.
2. It can do the same as 1, but as a client side of a unix domain socket.

That's still not fully parsable (so, I take the central buffer is the new name of the master control program, right?), but I take from it you want a registry for a service locator pattern. Trying to do this on top of local sockets is pretty troublesome, and guess what, dbus offers such a thing. As does X11 by means of a "selection owner".

X11 is too big of a project to require in all applications, that may not need it, as it breaks the UNIX philosophy of not being modular

The context was desktop apps (which is what dbus is designed for), and as long as you have X11 anyways, not requiring yet another service is the simpler design. Your complaint about X11 is just wrong claiming it wasn't modular, it is. All of this has nothing to do with "UNIX philosophy", a message bus with registered services has nothing to do with that eiter.

 

[Phishfry]

. Xorg is now in maintenance mode, and we all know its issues: screen tearing, flickering, etc.

But those sound like video driver issues not Xorg.

OpenBox is in maintenance mode too. Good because nobody is adding breaking features that nobody really wants.

 

[zirias@]

[tearing, flickering]
But those sound like video driver issues not Xorg.

Depends on from where you're looking at this.

X11 core drawing, and also Xrender, give you no control over when exactly something is drawn to the screen, so you can always hit tearing. But then, this is pretty much irrelevant for your typical GUI elements, it's not noticeable there. It's a problem for videos, animations etc, but there are solutions with either Xpresent (giving you that control to e.g. sync with vblank), or, depending on what you do, opt for local direct rendering bypassing X for that special purpose.

When you follow the "classic" approach of composing your GUI as a "tree of windows", it gets worse; having to update many widgets, each of it as its own drawable (window), you can easily hit multiple consecutive "frames" on the screen and therefore cause visible flicker. Something that was never a concern when X was initially designed, back then, watching your application draw its GUI step by step was the expected behavior and all the hardware could support. But: Nobody is doing this approach any more. The big toolkits default to full client-side rendering and use Xshm to share their pixmaps with the X server. In my new Xmoji tool using Xrender, I use off-screen (server-side) pixmaps for updating a "complex" UI and render the result to the real window in a single "compose" request. Both approaches eliminate any visible flicker.

In fact, I think it would be about time to modernize X and create a new major version (X12?) that gets rid of a lot of stuff not useful anymore nowadays (all the core drawing, core fonts, "compound text", ....) and concentrates on the extensions that are very useful these days, declaring them mandatory for the new version and maybe even improving them. This is not likely to happen in a project in "maintenance mode", but then, even as it is, X11 gives you everything you need with all the extensions that are "de-facto standard" anyways.

Wayland unfortunately did the "Linux-community thing": Instead of evolving what's there, throw it away and reinvent a new wheel. It's slightly triangular, but hey, it features an awesome shiny finish. ?

 

[fr0xk]

Wayland unfortunately did the "Linux-community thing": Instead of evolving what's there, throw it away and reinvent a new wheel. It's slightly triangular, but hey, it features an awesome shiny finish

The way I see it

In Linux: This thing suck. Let's rewrite a new thing

In BSD: This thing sucks. Lets fix it

(Not trying to create a rigid conclusion, *BSDs did write a lot new tools replacing old ones)

Also holy shit. You look like someone with quite a bit experienced in X Window System design

 

[Ferocious1881]

Well, that's an opinion. Let me add my opinion: No.

Do you want have compromised applications infect your entire system?

That's still not fully parsable (so, I take the central buffer is the new name of the master control program, right?), but I take from it you want a registry for a service locator pattern. Trying to do this on top of local sockets is pretty troublesome, and guess what, dbus offers such a thing. As does X11 by means of a "selection owner".

Firstly I mean central bus, not central buffer. Secondly I did not say that dbus is the solution, but a central bus shall exists, maybe if you really want, X11 can do the job. But I prefer UNIX philosophy and having the buffer as and independent service of X11, so that can be used for non X11 applications is the thing, that I prefer. It may even be used by X12.

Thirdly will try to do it clearer again, this time in seL4 like terminology:
All processes that are created shall be given a capability to communicate to the central bus, with this IPC with the central bus, all applications can register themselves and their offerings, search for registered application and their offerings with the process has be given authorization to know about, and request an communication channel to those registered services, as well receive request of communication channel. May be done with Unix Domain Sockets.

The context was desktop apps (which is what dbus is designed for), and as long as you have X11 anyways, not requiring yet another service is the simpler design. Your complaint about X11 is just wrong claiming it wasn't modular, it is. All of this has nothing to do with "UNIX philosophy", a message bus with registered services has nothing to do with that eiter.

Maybe simpler design for X11, but X12 may want to not make not GUI apps dependent on X12.

 

[zirias@]

In Linux: This thing suck. Let's rewrite a new thing
In BSD: This thing sucks. Lets fix it

It's quite often what happens indeed (devfs → udev, ifconfig → ip, oss → alsa → esd/arts → pulseaudio → pipewire → ???) and it's often ridiculous.

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.

You look like someone with quite a bit experienced in X Window System design

Actually, I just knew the very basic facts probably known by many people just using X, everything else is knowledge built during the last roughly 4 months of reimplementing my X11 emoji keyboard without using a GUI toolkit. My conclusion is, I don't really understand all the complaints you read from people thinking X11 programming was super complicated and can't be done without the help of a toolkit, I found it's actually very simple regarding the basic mechanisms X11 provides, but yes, it requires you to read a lot of additional documentation about the protocols specified on top of these simple mechanisms, mostly ICCCM and EWMH. But then, these are very well documented.

My only issue was, after deciding to use xcb instead of the old Xlib, which has some very relevant advantages and is as lightweight as it can get, the very sorry state of xcb documentation. It's almost non-existing, and that's the state 23 years after its initial introduction. Getting somewhere often involves reading the old Xlib based programming manuals and deducing how you'd do the same thing with xcb. ? Anyways, I like the result. My Xmoji tool currently compiles to a 1MiB binary (which includes all the Unicode-specified emojis including their names and a few other things like a large PNG icon). Apart from base libs (libc and libm) and the xcb libs, it has just 5 direct dependencies (fontconfig, harfbuzz, png, freetype and xkbcommon). I'd claim it's impossible to do the same for wayland....

 

[fr0xk]

But I prefer UNIX philosophy

What's even UNIX philosophy

 

[RussellASC]

Who needs dbus? Systemd is now going to replace it with varlink!

VARLINK

The Varlink Website

varlink.org

Varlink – IPC to replace D-Bus gradually in systemd | Hacker News

news.ycombinator.com

 

[Crivens]

What the actual $EXPLETIVE? Is energy so expensive they had to rig a generator onto Niclas Wirths' coffin? JSON? For IPC?

 

[Jose]

I highly agree with this comment from HN:

I think the best interface description protocol is one where the serialization format is unspecified.

This is one of the big strengths of Kafka. Each message is up to 1 MB of arbitrary bytes, do with it what you will.

 

[Crivens]

DBus is more or less an ARexx copycat, without the elegance of the original. I wish we had that instead of DBus. And the BeOS UI instead of Wayland.

 

[msplsh]

Who needs dbus? Systemd is now going to replace it with varlink!

I don't always laugh when I read hacker news, but... "... uses god damn JSON to serialize messages? Why would you do that?"

 

[msplsh]

I highly agree with this comment from HN:

This is one of the big strengths of Kafka. Each message is up to 1 MB of arbitrary bytes, do with it what you will.

Including writing your own de-chunker

 

[Jose]

Including writing your own de-chunker

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.

 

[Crivens]

Maybe simply use OpenMPI? Optimized in 9 ways to Sunday, by actual performance freaks with decades of experience. And that is experience from start to finish, not the same few days over and over.