3 ms·

But if we look at the operations that dbus is actually used for, they don't seem to be as complex as all of the capabilities that dbus provides. It's like sayi

But if we look at the operations that dbus is actually used for, they don't seem to be as complex as all of the capabilities that dbus provides. It's like saying your init should basically be another entire operating system instead of just a service orchestrator; by reducing the API surface area, we not only increase security and decrease footprint, we also end up with composability and replaceable layers because other components might even be simpler but with the same API. By defining this as a huge, complex problem that needs to be solved, the solution area naturally has to be much larger and encompass a far greater API and provide a lot more capabilities instead of the minimum capabilities to accomplish the far more limited goal. Growing the problem domain and thus the solution is always a huge temptation but ultimately results in the opposite of modularization and good system design.

freedomben 3y ago
> But if we look at the operations that dbus is actually used for, they don't seem to be as complex as all of the capabilities that dbus provides. I'm not sure this is true, certainly not for desktop users of Gnome and KDE. Just NetworkManager makes extensive use of D-Bus, and if you are writing an application that needs to care about (read or write) the state of the network, D-Bus is very useful and offers some powerful functionality. On my Fedora machine I jsut ran `busctl list | wc -l` and got 175 (meaning 174 buses available), so it is being used quite extensively. Watching `sudo busctl monitor org.freedesktop.NetworkManager` is fascinating. I'm certain that there are applications using it that aren't using the full capabilities, but if it already needs to be in place, I don't think it adds complexity to use it for simple situations where a file might be sufficient. In fact I think somewhat the opposite. If everything were in D-Bus, there's only one place to look and you learn how to use it once and it's immediately useful for many things. If every application is using a homegrown/custom/bespoke IPC solution, you have to get into the details for every single thing. That sounds a lot more complex to me. But that said, I bet we probably agree more than we disagree. If the application just needs to take in some configuration at runtime and doesn't need IPC, then using D-Bus is overkill and a bit cringey. I would much, much prefer a config file. If there's runtime changes though, that's where D-Bus starts to make sense to me.

freedomben 3y ago

> But if we look at the operations that dbus is actually used for, they don't seem to be as complex as all of the capabilities that dbus provides. I'm not sure this is true, certainly not for desktop users of Gnome and KDE. Just NetworkManager makes extensive use of D-Bus, and if you are writing an application that needs to care about (read or write) the state of the network, D-Bus is very useful and offers some powerful functionality. On my Fedora machine I jsut ran `busctl list | wc -l` and got 175 (meaning 174 buses available), so it is being used quite extensively. Watching `sudo busctl monitor org.freedesktop.NetworkManager` is fascinating. I'm certain that there are applications using it that aren't using the full capabilities, but if it already needs to be in place, I don't think it adds complexity to use it for simple situations where a file might be sufficient. In fact I think somewhat the opposite. If everything were in D-Bus, there's only one place to look and you learn how to use it once and it's immediately useful for many things. If every application is using a homegrown/custom/bespoke IPC solution, you have to get into the details for every single thing. That sounds a lot more complex to me. But that said, I bet we probably agree more than we disagree. If the application just needs to take in some configuration at runtime and doesn't need IPC, then using D-Bus is overkill and a bit cringey. I would much, much prefer a config file. If there's runtime changes though, that's where D-Bus starts to make sense to me.