Problems with D-Bus on the Linux Desktop
Key topics
The Linux desktop's reliance on D-Bus is sparking heated debate, with critics lambasting its complexity and limitations. As one commenter quipped, "systemd-busdd" (pronounced "busted"), others chimed in with proposed alternatives, including Varlink, already integrated into systemd, and hyprtavern, a C++-based contender. The discussion also veered into the realm of programming languages, with some advocating for a shift away from "unsafe" languages like C and C++ in favor of Rust, which has already been used in Linux kernel development. Amidst the bickering, a surprising consensus emerged: even longtime critics of systemd have come to appreciate its value, with one commenter confessing they now count it among their "favorite Linux things."
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
24m
Peak period
147
Day 1
Avg / period
26.7
Based on 160 loaded comments
Key moments
- 01Story posted
Dec 15, 2025 at 2:07 PM EST
18 days ago
Step 01 - 02First comment
Dec 15, 2025 at 2:31 PM EST
24m after posting
Step 02 - 03Peak activity
147 comments in Day 1
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 30, 2025 at 4:50 AM EST
3d ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
I was actually looking forward to bus1, such a nice design.
Instead, we are getting varlink it seems. yuk. "json json eggs bacon and json"
systemd-bus 2.0
[1] https://github.com/hyprwm/hyprtavern
Wayland was advertised as protocol mostly. After almost 20 years, it still has not promised to be a full replacement to xorg and probably never will, where wayland developers say "this is not our goal". Took people quite some time to realise that; it's been more recently become obvious, but say, 12 years ago few understood this.
I still have not been able to find working replacements to all that works on xorg, for instance; specifically imagemagick is different on wayland. I may try again at a later point in time, but my old workings there did not work, and replacements seem dead or ineffective or incomplete - that is quite frustrating for something that was aggressively advertised as "this is now the future".
Just pointing out the fact that it's not the language that isn't memory safe, it's the implementation you're choosing to use
Why not reuse Binder which has been to deployed to billions of devices, being a core part of a serious OS, with many many more developers who understand it compared to dbus.
https://source.android.com/docs/core/architecture/ipc/binder...
https://www.kernel.org/doc/html/latest/admin-guide/binderfs....
Traditional Linux drivers are considered legacy in Android.
> also depends on having a obscure Linux feature enabled
An extremely widely used and battle hardened Linux feature, though, with corporate sponsorship and active development. With the only real reason it's obscure on desktop linux at all is because upstream blocked it for a long time. If desktop linux embraced it, it certainly wouldn't be obscure anymore, now would it?
> An extremely widely used and battle hardened Linux feature, though, with corporate sponsorship and active development.
Compared to _unix sockets_ , which is the other transport used by almost every other local IPC mechanism, there is just no contest.
None of binder is in Java. The Java binder code is just JNI bindings to the native implementation.
Things like permission manager are in Java, but that's not part of binder. It's just a service published on binder, and one that wouldn't translate to current desktop Linux anyway.
> Compared to _unix sockets_ , which is the other transport used by almost every other local IPC mechanism, and what both D-Bus, TFA's proposal, and literally any other reasonable desktop IPC proposal out there, there is just no contest.
unix sockets are not an equivalent, which is why protocols are bolted on top to turn it into dbus, etc...
This libbinder is still way too Java-centric. It can be used from outside, and even slightly reminds me of openbinder (e.g. sp<> https://cs.android.com/android/platform/superproject/main/+/... ) but it doesn't really change the picture much. You have something which smells Java from a mile, and has a lot of other Android-isms to boot, so still likely requires to reinvent a lot of the wheel to actually use it for most desktop programs.
Even the use of C++ is likely to frown many people. (Not me).
https://cs.android.com/android/platform/superproject/main/+/...
[1] BeOS, the docs still match what is in Android :D
OpenBinder was one of the few pieces of code which was open sourced in Be Inc’s dying days just before it was acquired by Palm.
Many of the principal Be developers who worked on OpenBinder, Dianne Hackborn, Jean-Baptiste Queru, et al then moved from Palm to Danger, which was developing Android and which was later acquired by Google.
And the rest, as they say, is history.
2. Better latency. When you send a Binder transaction to another process Linux will immediately schedule the binder thread of the other process, unless it's a oneway transaction that does not block executon. Then once the other process replies, the original process is immediately rescheduled. Dbus does not affect Linux's scheduling of processes. When you send a dbus message any other process can be scheduled and run instead of the bus. And then anything can run in-between the bus sending the message to the target process.
3. Having the message go through the bus also results in extra copying. Not just cheap copying of memory. Since it's through a UNIX socket it has to use extra system calls to read out of and into another socket. As opposed to binder where it's able to simply copy the memory of the parcel from one process to another.
It was a toy created by former OS devs who really didn't want to use Linux, but wanted their pet IPC from their former OS. It even used to be the case that Binder would dynamically create threads in the receiving process without userspace knowing. As in, your process would magically have function calls coming in from threads that you never created. Imagine the issues this can create with locking, forking, etc. This ended up being changed to get it upstreamed, but I consider this absolutely insane behavior.
To make it even more hardened(?), Google recently contributed and got merged a Rust implementation of binder for the Linux kernel (and they're apparently planning to eventually remove the old C implementation).
https://lwn.net/Articles/953116/
https://lore.kernel.org/rust-for-linux/20231101-rust-binder-...
Those would have been a great starting point as well! But maybe we'll see them later.
> the most meritorious solution never rises to the top
You know why? Because it was the best solution at the time that covered everything they needed. You can only complain about it because the initial problem was solved and people were able to move on to something else.
Does it work for what we need it to do? Yes? Ok. Now that we have settled this problem, we can continue on developing.
Meritocracy is only relevant to someone who has ideas but no desire or ability to actually structure the idea in such a way that would work in the world we find ourselves in today.
> Maybe D-Bus has something similar?
So you just commented here to say nothing but "dbus sucks because it isn't the best. I wonder if there are better options?".
It's just politics, really.
Respectfully, i think that mostly happens when people reviewing the solution space don't understand the problem fully. Often the requirements differ from what people think they are, and as a result the winner seems random because they don't understand the actual requirements.
On top of that, there's adverse selection here. Who gives up thousands of hours to work on some obscure corner of the Linux desktop? People with quite unusual thought processes.
Does it miss a spec? Write one.
Do you really want your secretsd or whatever to only be able to reply to whomever stored the secret? Make clients store a cookie or something and only reply if they prove ownership of it. But I have to ask : what the hell is your threat model here? The attacker is just going to ptrace firefox and read all the secrets anyway. Or read its files in $XDG_CONFIG_DIR. You are just moving around who has the ultimate responsibility, and that looks like security theater. In addition, I _want_ other programs to be able to read secrets (e.g. keyring administrators, .netrc-style shared secrets, etc.)
Do you hate a{sv}? If you propose JSON as alternative, you are going to make me laugh.
Etc. Etc.
Unix domain socket authentication is stronger and doesn't require storing cookies on the client side.
> what the hell is your threat model here? The attacker is just going to ptrace firefox and read all the secrets anyway.
Which is why you can (and people do, e.g. flatpak) run applications where ptrace or global filesystem access is blocked. Which is why portals exist and why there shouldn't be a "get all secrets via dbus" escape hatch.
> I _want_ other programs to be able to read secrets (e.g. keyring administrators, .netrc-style shared secrets, etc.)
Then don't use it? Secure defaults matter for most users.
> Do you hate a{sv}? If you propose JSON as alternative, you are going to make me laugh.
Find the *kwargs here: https://wayland.app/protocols/xdg-shell
Etc. etc. This isn't the 90s anymore.
And pointless here, since everything runs under the same uid. You need to authenticate this is the same browser that stored this secret, not that this is the same uid (useless), or the same pid, or any other concept that unix domain socket authentication understands.
> Which is why you can (and people do, e.g. flatpak) run applications where ptrace or global filesystem access is blocked. Which is why portals exist and why there shouldn't be a "get all secrets via dbus" escape hatch.
In which case they do not connect to the same D-Bus "bus".
> Then don't use it? Secure defaults matter for most users.
Right until they notice they can no longer view the keyring contents, or any other stupid limitation most desktop users couldn't care about.
> Find the *kwargs here: https://wayland.app/protocols/xdg-shell
Much better to have a million non-extendable protocols competing with each other
I disagree. With UNIX domain sockets it is absolutely possible to determine the PID of the process that you are talking to and use pidfd to validate where it is coming from. Would be entirely possible to use this for policy.
> In fact, if you do not need a shared secrets service, and your applications are containerized... why do you need a secrets IPC at all? Just let each program store its secrets in some of its supposedly private storage...
And how exactly does the app container service store something encrypted securely on disk? That's literally the point of a secrets service on a modern desktop. It usually gets keymatter in the form of a user password carried to it from PAM, in order to allow on-disk encryption without needing separate keyring passwords. (And yeah, sure, this could use TPM or something else to avoid the passwords, but the point is literally no different, it shouldn't be each application's job individually to manage their own way of getting secure storage, that's a recipe for data loss and confusion.)
> Much better to have a million non-extendable protocols competing with each other. To this day there are two protocols (at least) for exposing the address of the DbusMenu service of a surface, one for gnome-shell and one for kwin. So much for the uglyness of X atoms. And this has nothing really to do with the design of the IPC mechanism itself...
That's a problem that occurs because the protocols have multiple distinct implementations. Most of the dbus services don't have to deal with that problem at all. (And the ones that do, tend to have problems like this. There are plenty of weird incompatibilities with different XDG desktop portal implementations.)
I'm pretty sure the point of bringing up xdg-shell is because the new bus is inspired by the Wayland protocol. For all of the incessant bitching about Wayland online, Wayland protocols are only about 1000x nicer to use than dbus. You can actually do decent code generation for it without having to have like 5 competing ways to extend the XML to add basic things like struct member annotations (and then have things like Qt's own DBus code generator unable to actually handle any real DBus service definitions. Try throwing the systemd one at it, doesn't fucking work. The code doesn't even compile.)
Validate what? You're just moving the responsibility to whatever answer you give here. If you say "validate the exec name is firefox-bin" then the next person who comes in will say "I hate $your_new_fangled_ipc, you can make it dump all your secrets by renaming your exec to firefox-bin". (This is just an example).
> And how exactly does the app container service store something encrypted securely on disk? That's literally the point of a secrets service on a modern desktop.
The more I think of it, the less sense this makes. If you already have a system where applications cannot read each other's data, what is the point of secret service? What is the security advantage?
If you want to encrypt with TPM, fingerprint, or anything else, that's encryption, which is separate from storage (you can encrypt the password with say a PCR but the application gets to store the encrypted password in any way they want).
Password encryption in the desktop keyrings are for the situation for when every application can read each other's data files easily (again, as in the desktop). In which case, it may make sense to use encryption so that such data is not (trivially) accessible from any other application (otherwise https://developer.pidgin.im/wiki/PlainTextPasswords applies) .
If your applications are already running sandboxed, a keyring sounds to me like useless complexity? Just make each application store its data into its sandbox. What's the threat vector here, that super-user-that-can-escape-sandbox can read into the sandboxes and extract the password?
> You can actually do decent code generation for it without having to have like 5 competing ways to extend the XML to add basic things like struct member annotations (and then have things like Qt's own DBus code generator unable to actually handle any real DBus service definitions. Try throwing the systemd one at it, doesn't fucking work. The code doesn't even compile.)
Yes sure, another problem resulting from the lack of standarization. But my point was -- standarize (write a spec), instead of adding more to the problem by creating yet another competing standard which will obviously NOT solve the problem of lack of standarization.
I'm genuinely kind of surprised people are tripping up on this. Obviously, what you validate is up to you, but you can. Why stick to just the base name? Why not the absolute path? Bonus points for ensuring it's a root owned file in root owned paths. You could special case Flatpak, or specific mount points, or go crazy and add signatures to binaries if you want. The policy would obviously vary strongly depending on the system, but if you were dealing with a secure booted system with dm-verity, or something similar, well then this mechanism should be fairly watertight. It's not really the end of the world if there are systems with different security characteristics here.
You can really get creative.
> The more I think of it, the less sense this makes. If you already have a system where applications cannot read each other's data, what is the point of secret service? What is the security advantage?
Well, the obvious initial benefit is the same thing that DPAPI has had for ages, which is that it's encrypted on-disk. Of course that's good because it minimizes the number of components that will see the raw secret and ensures that even other privileged processes can't just read user secrets. Defense in depth suggests that it is a feature, not a problem, if multiple security mechanisms overlap. Bonus points if they'd both be sufficient enough to prevent attacks on their own.
An additional case worth considering is when the home folder is stored elsewhere over a network filesystem, as in some more enterprise use cases.
> If you want to encrypt with TPM, fingerprint, or anything else, that's encryption, which is separate from storage (you can encrypt the password with say a PCR but the application gets to store the encrypted password in any way they want).
It would be ill-advised to have each application deal with how to encrypt user data. They can store keymatter in the keyring instead of the data itself if they want to handle storage themselves. (I'm pretty sure this is actually being done in some use cases.)
> Password encryption in the desktop keyrings are for the situation for when every application can read each other's data files easily (again, as in the desktop). In which case, it may make sense to use encryption so that such data is not (trivially) accessible from any other application (otherwise https://developer.pidgin.im/wiki/PlainTextPasswords applies) .
That page exists to explain why they don't bother, but part of that is that there just isn't an option. If there actually was an option, well, it would be different.
> If your applications are already running sandboxed, a keyring sounds to me like useless complexity? Just make each application store its data into its sandbox. What's the threat vector here, that super-user-that-can-escape-sandbox can read into the sandboxes and extract the password?
The threat vector is whatever you want it to be, there are plenty of things this could be useful for. The reality is that Linux desktops do not run all programs under a sandbox and we're not really headed in a direction where we will do that, either. This is probably in part because on Linux most of the programs you run are inherently somewhat vetted by your distribution and considered "trusted" (even if they are subject to MAC like SELinux or AppArmor, like in SuSE) so adding a sandbox feels somewhat superfluous and may be inconvenient (i.e. file access in Bottles is a good example.) But, even in a world where all desktop apps are running in bubblewrap, it's still nice to have extra layers of defense that compliment each other. And even if something or someone does manage to access your decrypted home folder data, it's nice if the most sensitive bits are protected.
> Yes sure, another problem resulting from the lack of standarization. But my point was -- standarize (write a spec), instead of adding more to the problem by creating yet another competing standard which will obviously NOT solve the problem of lack of standarization.
The reason why people don't bother doing this (in my estimation) is because DBus is demoralizing to work on. DBus isn't a mess because of one or a couple of issues, it is a mess because from the ground up, it was and is riddled with many, many shortcomings.
And therein lies the rub: if you would like to have influence in how these problems get solved, you are more than welcome to go try to improve the DBus situation yourself. You don't have to, of course, but if you're not interested in contributing to solving this problem, I don't see why anyone should be all that concerned about your opinion on how it should be fixed.
Because you do not get it: this is not Android. There is no fixed UIDs. There is no fixed absolute paths. The binaries are not always root-owned. There is no central signing authority (thank god!). You really do not get it: _anything_ you could validate from a PID would be absolutely pointless in desktop Linux.
> You could special case Flatpak, or specific mount points, or go crazy and add signatures to binaries if you want.
Or, if you are assuming Flatpak, you could simply do not allow access to the session bus and instead allow access only to a filtered bus that only allows talking to whichever services Flatpak provides. Which is how Flatpak does it and you sideline the entire problem of having to authenticate clients on the bus, which is a nightmare. The entire process tree descending from original Flatpak session gets access to this bus and only to this bus.
> hat even other privileged processes can't just read user secrets. Defense in depth suggests that it is a feature, not a problem, if multiple security mechanisms overlap. Bonus points if they'd both be sufficient enough to prevent attacks on their own.
I really do not see the point of this. Of course I want privileged processes to be able to see my passwords; this is _my_ desktop.
I do not see why you'd have your "sandboxes apps" store their private data but then have another storage that is "more secure" for whatever your definition of secure is. You'd just put the data in the "more secure" storage to begin with.
What you're describing is not another layer of security, it is just pointless complication. As I said, the more I think of it, the less reason I see for a secret service which does not really share secrets.
You reach stupid conclusions like having to design a key-value DB that only returns values to the process that inserted them in the first place. You already have one: the app's private storage. Why do you even need IPC for this?
> It would be ill-advised to have each application deal with how to encrypt user data.
Why? You do not put the reason why not. Every application does this _today_, and no IPC has ever been needed for this (e.g. openSSL is a library, not a service).
> The reality is that Linux desktops do not run all programs under a sandbox and we're not really headed in a direction where we will do that, either.
In which case, my entire remark does not apply and there is some (minor) benefit to a keyring.
> DBus isn't a mess because of one or a couple of issues, it is a mess because from the ground up, it was and is riddled with many, many shortcomings.
This is a circular argument. D-Bus is a mess because it is a mess. Even if I would agree, it is a pointless argument.
> you would like to have influence in how these problems get solved, you are more than welcome to go try to improve the DBus situation yourself. You don't have to, of course, but if you're not interested in contributing to solving this problem, I don't see why anyone should be all that concerned about your opinion on how it should be fixed.
I am answering to a guy that says that D-Bus sucks then proceeds to create an alternative instead of fixing it. I have not only contributed to D-Bus through decades, I am also part of the reason it is used in some commercial deployments outside traditional desktop Linux (or was a decade ago). My opinion is still as important as his, or yours, which is : nothing at all.
Uhhh... I didn't say anything about fixed UIDs.
> There is no fixed absolute paths.
There is if your distribution says there is.
> The binaries are not always root-owned.
They are if your distribution says they are.
> There is no central signing authority (thank god!).
I mean, that's not even really 100% true right now. What major distribution doesn't sign packages in some form? Yeah, fine, the binaries themselves lack a signature attached to them, but if they can sign the packages they sure as shit can sign an ELF binary provided a mechanism to do so.
But anyway. There is if your distribution has one.
> You really do not get it: _anything_ you could validate from a PID would be absolutely pointless in desktop Linux.
There is if your distribution makes there a way to validate something from the PID.
The point is that the mechanism would be different per each system, the same way that OpenSuSE may have a MAC in enforcing mode by default and Arch might not. That's how desktop Linux really works. You're not forced into any specific policy, but that doesn't mean policy is pointless. There are plenty of people running Secure Boot and Lockdown mode too, it's not automatically pointless.
Immutable distros exist right now.
> Or, if you are assuming Flatpak, you could simply do not allow access to the session bus and instead allow access only to a filtered bus that only allows talking to whichever services Flatpak provides. Which is how Flatpak does it and you sideline the entire problem of having to authenticate clients on the bus, which is a nightmare. The entire process tree descending from original Flatpak session gets access to this bus and only to this bus.
This doesn't fix anything. Like half of the shit I have installed via Flatpak needs direct session bus access anyways.
> I really do not see the point of this. Of course I want privileged processes to be able to see my passwords; this is _my_ desktop.
Do you know what "principle of least privilege" is? My printer driver is "privileged" but that doesn't mean it needs to be able to capture my screen and read all of my passwords. It would be much better if Linux was capabilities-based. Hey, maybe someone should attempt to implement an RPC framework that does that.
> What you're describing is not another layer of security, it is just pointless complication. As I said, the more I think of it, the less reason I see for a secret service which does not really share secrets.
That's because your thought process is going in one direction and not taking any new input. You've been running the same exact narrative the entire time. Yes it's true that if you assume the system must be watertight-secure under all circumstances in every single existing desktop Linux setup, then it can't be done. But that's irrelevant. The question is could it be used as a primitive to construct a more secure Linux desktop, and the answer is a resounding, "Well, duh".
Again. Immutable distros exist right now. They already start with many of the necessary security properties, you mostly need to find a way to deal with insecure linker behavior.
> You reach stupid conclusions like having to design a key-value DB server that only returns values to the process that inserted them in the first place, like what TFA is doing. Why? Just why??? Have multiple totally separate, private instances! And you already have one storage for that: the app's private storage. Why do you even need IPC for this?
sigh
You do realize that this is how many apps currently use GNOME Keyring, right? They literally use it to store their own passwords for no other purposes. That's literally already a thing. The intent is not so they can share your password across the system, it is to provide a mechanism to securely store data. Sometimes it is also used to share data between different programs, but I don't even think that is most of the time.
Checking my kdewallet, I can see the following applications:
- KRDC
- Remmina
- KRDP
- Chromium
- krfb
- xdg-desktop-portal
... And then the "Passwords" folder, which contains the passwords saved for e.g. SMB shares.
Of those... I think the only one that is ever even accessed by anything else is the Chromium one possibly, for browser migration? The rest are only ever stored for themselves. So yes, the wallet is a key-value store. One that is encrypted automatically without needing the application to do key management.
> Why? You do not put the reason why not. Every application does this _today_, and no IPC has ever been needed for this (e.g. openSSL is a library, not a service).
Not cryptography itself, but key management. Although you can do key management by proxy by providing a cryptography API too, sort of how using the TPM for this purpose works. That is the approach taken by DPAPI on Windows, in contrast to the keyring approach taken on Linux and macOS.
And the "Why?" is very simple. You want a secure key that doesn't get lost. The user already has a password, ergo it already provides a perfectly good passphrase to wrap a key; individual applications can't access that. And that way, the OS can take care of whether user data is encrypted with a TPM or using a passphrase-wrapped key. Having this control centralized could become important if it's ever required by regulation to be handled a certain way.
> This is a circular argument. D-Bus is a mess because it is a mess. Even if I would agree, it is a pointless argument.
It's not circular at all... man, you really need to learn how to read. What I am saying is that it is not only a mess, but deeply flawed. Even if you clean it up, what you will wind up with is an aggressively polished turd. There is no world in which that is logically worth the effort.
> I am answering to a guy that says that D-Bus sucks then proceeds to create an alternative instead of fixing it. I have not only contributed to D-Bus through decades, I am also part of the reason it is used in some commercial deployments outside traditional desktop Linux (or was a decade ago). My opinion is still as important as his, or yours, which is : nothing at all.
Well, it's at least good that you also recognize the value I place in your opinion at this point, so that we can agree on at least one thing.
You STILL do not get it: This Is Not Android. Even ignoring that most distributions are not going to do what you want them to do, the distribution has zero power over what users do. Firefox _is_ still distributed as a simple tarball that you can unpack in your home directory and run.
> I mean, that's not even really 100% true right now. What major distribution doesn't sign packages in some form? Ye
ANY that is source based, for example. Actually, I have not used _any_ distribution that would sign even packages in ages, much less binaries.
> The point is that the mechanism would be different per each system, the same way that OpenSuSE may have a MAC in enforcing mode by default and Arch might not.
It doesn't _matter_. A user is then going to mount a $HOME through NFS into a serverbox and expect to run graphical applications from there.
> Like half of the shit I have installed via Flatpak needs direct session bus access anyways.
And how would _any_ D-Bus replacement fix that? You'd need to replace _all_ IPC servers to offer some form of "no longer trust the clients" API, and this is a decades-long task _at best_, and a different IPC system doesn't help, but delay it.
> Do you know what "principle of least privilege" is? M
How is this relevant when I want my _privileged_ process to manage the password? What is this discussion even about?
> You do realize that this is how many apps currently use GNOME Keyring, right? They literally use it to store their own passwords for no other purposes. That's literally already a thing. The intent is not so they can share your password across the system, it is to provide a mechanism to securely store data.
Well this is wrong. The entire raison-d'être for KWallet was to share passwords amongst programs, as a glorified netrc replacement. The private storage part comes later, and few if any people enable the auto-locking mechanism which is the only thing that can offer any sensible protection to it.
> And the "Why?" is very simple. You want a secure key that doesn't get lost. The user already has a password, ergo it already provides a perfectly good passphrase to wrap a key; individual applications can't access that. And that way, the OS can take care of whether user data is encrypted with a TPM or using a passphrase-wrapped key. Having this control centralized could become important if it's ever required by regulation to be handled a certain way.
why do you make this distinction for secrets, and not for literally the rest of extremely critical private data that the app stores in any other way? Why would user want to backup the passwords but not the private app documents?
"You want a private data storage that doesn't get lost. The user already has a password, ergo it already provides a perfectly good passphrase to wrap such private data; [other] individual applications can't access that. And that way, the OS can take care of whether user data is encrypted with a TPM or using a passphrase-wrapped key."
> What I am saying is that it is not only a mess, but deeply flawed. Even if you clean it up, what you will wind up with is an aggressively polished turd
This is not a reading problem: you are still saying that it is a mess because it is a mess. If you want to break the circular reasoning, you have to introduce an actual reason into the loop.
> Just don't act like it's weird when someone who is actually doing something about the trainwreck that is the Linux desktop decides to do something else instead given they have no reason to care about the peanut gallery here.
You keep framing this as if we didn't want to improve the Linux desktop, which just shows your bias.
Just don't act like it's weird when the actions only result in a LARGER and more explosive trainwreck rather than an improvement.
The pidfd_open() man page doesn't list many things that can be done with a pidfd. What sort of validation do you have in mind?
I would love to have a reasonably snoop-proof secret storage service whose security model works with normal programs (as opposed to requiring Flatpaks or the like).
I think it would also be feasible to add code signatures if we wanted to, though this would add additional challenges.
If I store my secrets in KWallet, which purports to _storage for secrets_, I absolutely do not expect every application on the desktop to have access to those secrets, whether I want to share them or not.
I can't believe you're suggesting this is sanely defensible.
Kwallet is for encryption at rest, so an attacker can't read your secrets if they steal your computer. It IS NOT protection from your own applications running as the same user.
That's just not how Linux desktop works. It's a desktop operating system, it's not iOS. All apps running as your user have your users permissions.
Is it an outdated security model? Yes, enter sandboxing and newer kernel features. If you're not doing that though then you won't get that.
Just run your shit in flatpak, problem solved. Or better yet, don't install malware and only download trusted open source software from trusted repositories.
The closer you stick to the kernel security model, the more likely your app will be safe and performant, and the less likely other devs will reject it in favor of their hand rolled stuff.
The security aspect seems also a bit funny to me. After all the average Desktop has most data in the home directory, so every application can read everything. That's not the fault of D-Bus.
Also I'm puzzled that Polkit hasn't been mentioned even once.
The world is moving towards sandboxed applications (through flatpak and friends) more and more. As per the OP, this is one of the things holding sandboxing back.
It takes the same time to escape 1 or 10000000 sandboxes.
Escaping two different sandboxes are multiple times as hard, and a sane sandbox is not trivially picked, see web browsers and that the fact that the world is not one giant botnet.
https://media.ccc.de/v/all-systems-go-2024-276-varlink-now-
Those secret stores (gnome-keyring/kwallet) store the secrets encrypted on disk, so every application can read the encrypted secrets but only the secret store has the encryption key to decrypt them. This is held in memory, not on disk.
Dbus is a godawful mess. Imagine the windows registry, except it can only be inspected at runtime, contains executable binaries and is exceptionally fragile
And maybe its time for a reinvention anyway? IPC and efficient and portable formats are very mature nowadays, with protobuf, flatbuffers etc. and the general model of the internet is based around service location, and stuff talking to each other.
I'm kida curious why they didn't go with Unix Sockets in the first place, with named pipes in memory carrying the message transport.
Yes, and the article's author forgot to tell you that their rant doesn't apply to applications running in a sandbox, as their D-Bus access is filtered.
No, Linux desktop is just an opportunity for a bunch of special snowflakes to enact their "vision", force their niche requirements on other 99.999% of users or create fiefdoms, where they can feel good and safe.
"it f*cking works"
Can we objectify this claim made here?
As for it being used everywhere, sure, we had some bad SOAP stuff being used everywhere at one time, but that's not a good thing...
Regarding secrets etc.. on the one hand, yeah it's not much to worry about people with access to your machine reading stuff on your machine, buut*, it's kinda dumb to have stuff encrypted and left around for a public unsecured protocol. The solution would be, for apps that need security, don't use dbus.
If the API was less loosey goosey (self documentating, not so open ended, less awkward), I agree it's fine for applications at the same level of trust to all access the same thing.
The problem is more random scripts off the internet using browser apis to read stuff out of local storage containers. Forcing local containers to explicitly allow such access, and yes, using a non-dbus protocol, would be a preferred method, while not requiring overly complex authentication schemes locally...
Otherwise the main change I would have made would be to explicitly allow applications to access the bus, vs just a random app having access by virtue of running in memory...
FreeDesktop-dot-Org would not accept one from the author if he did:
https://blog.vaxry.net/articles/2024-fdo-and-redhat
https://blog.vaxry.net/articles/2024-fdo-and-redhat2
it already annoys me.
an alternative would be welcome.
That when you can open a basic X11 application like xeyes or xterm, you can open any X11 application.
D-bus breaks this.
And it makes my Linux system feel like another case of "microservice failure".
I have never heard of that. Even if it was true (and sounds like another security issue); X11 is almost gone for most people. Why should anyone care?
Can you show where you got the impression that "X11 is gone"?
It's "gone" for roughly 80% of the people using Linux on the desktop.
(It's often still installable, it's just no longer the default and has been marked as deprecated / unmaintained.)
Also, 20% is quite a big userbase. What you are saying is like saying that Firefox is "gone" because "percentage".
Trust me, X11 is not gone.
The major DEs have removed their X code paths, or will in the next yea. The toolkits will follow suit. X is a dead end for new and non-legacy software.
Wayland was launched 18 years ago and it still can't handle mainstream apps in common scenarios.
"Trust me, IE6 is not gone" - me
Wayland Only (default, installed):
* Fedora
* Ubuntu
* openSUSE
* Arch Linux
* Pop!_OS
Wayland (default)
* Debian
* SUSE
Arch doesn't even install a kernel by default, in which possible way does it default to Wayland?
Arch clearly doesn't have any "defaults" there. Manjaro is on X11.
SteamOS on Steam Deck does however use Wayland.
That said, there is interest in Wayland in these circles.
https://www.openbsd.org/papers/eurobsdcon2023-matthieu-wayla...
Their ssh supports the -X and -Y options to run remote X applications.
Let me know when those go Wayland-specific and are able to encompass the new protocol.
Until then, get comfortable in a small and discardable minority.
Cool, I remember using it in 2003 a few times. I highly doubt many people going to miss if those were gone. I would not be surprised if the majority of ssh server installations disable x11 session forwarding.
> Until then, get comfortable in a small and discardable minority.
Are you sure you're not confusing Wayland users with OpenBSD users?
Even if I didn't depend on such a program myself, I would find it strange that the Wayland compositor be given responsibility for only part of the keyboard: its keys, but not its indicator lights.
I shutdown the connman service and removed it from the auto startup sequence. I manually edited frickin' wpa_supplicant.conf to put my cellphone network there. Worked first time and every time thereafter.
The founding document of GNOME is called "Let's Make Unix Not Suck" by which the authors (primarily Miguel de Icaza) meant "Let's Make Unix Almost Exactly Like Windows". D-Bus is just the latest in a series of attempts to bring Microsoft's janky, kind of an object model to the realm of Unix's small do-one-thing C programs plumbed together with file descriptors, pipes, and network sockets. Except somehow, they added even more problems on top of the ones COM already had!
At least when Steve Jobs tried to retrofit Smalltalk style OOP onto the Unix model, he had the foresight to bring much of Smalltalk (in the form of Objective-C) along with.
That's not a surprise. The author of systemd, for instance, is working for Microsoft. Suddenly all those changes to the Linux ecosystem make a lot of sense. It became a corporate commodity, from A to Z. And when that is your objective, it kind of makes sense to have a unified system, even if it is crap.
> Lennart Poettering and Kay Sievers, the software engineers then working for Red Hat who initially developed systemd,[2] started a project to replace Linux's conventional System V init in 2010.[16]
https://en.wikipedia.org/wiki/Systemd#History
This is wrong, Kay Sievers was working for Novell/SuSE at that time, see https://0pointer.de/blog/projects/systemd.html#faqs
(Mostly because 1) I don't think that the talk page will be paid any attention during the next... millenia.. and 2) I think that you should make the change because you knew that it was incorrect, and have receipts)
People who think the init system is doing all of this have just not done even the bare minimum amount of research on the topic. Although, granted, the naming might not help.
Like, systemd-boot has literally nothing to do with systemd. Nothing at all. It just uses the project name. Which is confusing, sure.
It's sort of like saying KDE is a whole thing because it has a text editor. Uh, no - KDE is a project, Kate is a text editor part of the k applications suite, which has nothing to do with plasma, the desktop shell. You can use Kate on any shell. You can use plasma without Kate.
I'm very thankful for systemd covering more and more bases because the "common" alternatives for many problems might be stable but they are often really bad to configure, maintain and debug - the ergonomics in non-default use cases have a lot of potential for improvement. And what can you do if the maintainer is not responsive to the kind of improvements you would need to make the software ready for the next decades? Many times I have forked things and tried to refactor their technical debt so a new feature can be implemented without making it an even bigger hack, and after that you just want to delete it all and start from scratch with a "proper" setup.
So I can understand the perspective of the systemd developers and the pain they had to go through simply on a technical level, not even thinking about the huge flamewars on mailing lists with semi-intelligent people.
On top of this imo the documentation of systemd is really good.
156 more comments available on Hacker News