D-Bus is bloat
* 2024/06/11 07:36 UTC - Direct link
D-Bus is a process responsible for providing inter-process communication (IPC) -- it allows different programs to communicate with eachother.
In networkmanager's "Notes on D-Bus", specifically the part "Depend on D-Bus" ("depend", "trust", ... sounds like a commercial), it is claimed that D-Bus is not bloated. However, I think otherwise.
Assuming a single-session D-Bus setup (Multiple D-Bus sessions can exist), D-Bus consumes about 4M of RAM. In today's world, that doesn't seem much. However, If you consider embedded and old machinery, some of which have very little memory available, that is quite the waste. I use a machine that has 96MB of RAM, with modern Linux, and on that, D-Bus wastes 4%. If I were to use my free memory instead of overall system memory for this percentage, things would look even more dire.
---
Is there another option? The historic alternative, is UNIX domain sockets. They are "files", which act very similar to TCP sockets. This functionality is built right into the Linux kernel. However, networkmanager says that "Services and applications that would choose to use plain UNIX domain sockets instead would either slightly reduce their footprint by omitting features like introspection or security policing via polkit" -- Well...
Here are some overly simple Python scripts to demonstrate this concept.
- term 2: './socket-test'
You will get output in term 1.
- term 2: './socket-wrap'
- term 3: './socket-test'
You will get output in both term 1 and term 2. Congratulations! You just introspected a UNIX domain socket :ooo
---
I can understand the attractiveness of a simplified IPC mechanism. However, such a mechanism could be implemented in a library instead, or even a header, if kept apt. One could just provide simplified functions to make and access to UNIX sockets. If used with locks, no daemon is even required.
In networkmanager's "Notes on D-Bus", specifically the part "Depend on D-Bus" ("depend", "trust", ... sounds like a commercial), it is claimed that D-Bus is not bloated. However, I think otherwise.
Assuming a single-session D-Bus setup (Multiple D-Bus sessions can exist), D-Bus consumes about 4M of RAM. In today's world, that doesn't seem much. However, If you consider embedded and old machinery, some of which have very little memory available, that is quite the waste. I use a machine that has 96MB of RAM, with modern Linux, and on that, D-Bus wastes 4%. If I were to use my free memory instead of overall system memory for this percentage, things would look even more dire.
---
Is there another option? The historic alternative, is UNIX domain sockets. They are "files", which act very similar to TCP sockets. This functionality is built right into the Linux kernel. However, networkmanager says that "Services and applications that would choose to use plain UNIX domain sockets instead would either slightly reduce their footprint by omitting features like introspection or security policing via polkit" -- Well...
Introspection:
Active UNIX sockets can be listed by using 'netstat -lx'. You can also look into their traffic, by moving the original socket file, and creating your own in its place, which makes it possible to inspect the data, before passing it onto the original socket. Introspection is also less necessary here, since as opposed to D-Bus, no data can be stored inside a UNIX socket, so memory leaks present themselves inside the host process, and not in a monolithic daemon.Here are some overly simple Python scripts to demonstrate this concept.
Example 1:
- term 1: './socket-run'- term 2: './socket-test'
You will get output in term 1.
Example 2:
- term 1: './socket-run'- term 2: './socket-wrap'
- term 3: './socket-test'
You will get output in both term 1 and term 2. Congratulations! You just introspected a UNIX domain socket :ooo
Security policing (...via polkit):
Honestly, I have no clue what polkit is or if it's necessary (I seriously doubt it). What I do know, is that UNIX domain sockets can have security policies. They're files, so their owner+group as well as permissions can be set (chown, chgrp, chmod), which makes them fit for private and administrative purposes.---
I can understand the attractiveness of a simplified IPC mechanism. However, such a mechanism could be implemented in a library instead, or even a header, if kept apt. One could just provide simplified functions to make and access to UNIX sockets. If used with locks, no daemon is even required.