>>108611566
Well what is the alternative? I want to use Niri on Void. I plan on using seatd and turnstile instead of elogind, but I'm not sure if dbus can be replaced easily or if you just need to do more manual work.

>>108612048
The hyprland guy (vaxry) is making an alternative to dbus which i’m excited for. Even though I don’t use Hyprland and I use niri, i’m definitely gonna use that over the shitshow that is dbus. Fuck dbus forever.

>>108611566
What's wrong with dbus?

>>108612156
It's insanely fucking annoying to work with and has some of the worst docs of all time.
It also just so happens to invalidate the security benefit of switching from Xorg to Wayland.

>>108612048
>Well what is the alternative?
Android's Binder or Varlink (which is just JSON RPC over a UNIX socket, surprisingly UNIX like from them), but that's associated with Systemd even though it doesn't depend on it.

GNOME is starting to adopt Varlink for some things. Hopefully more desktop software does away with DBus.

Varlink sounds way better than the DBus black box.

>>108612048
https://docs.voidlinux.org/config/session-management.html

>>108611566
I'm offended you didn't add pipewire to your list, the thing that started out as an alternative to pulseaudio and jack and now it's a semi-mandatory "multimedia" mostrosity for wayland sessions

>>108612156
Is this a joke question? A 5 year old with Down syndrome could engineer a better IPC mechanism.
https://lore.kernel.org/all/CA+55aFwdk0FYXM=vmWhFye-dzgyBLUzKt40ujjEhKjjBLDwk7g@mail.gmail.com
>user space was written by a retarded monkey on crack

>>108612906
>Varlink (which is just JSON RPC over a UNIX socket
Why do I have to burn power and CPU cycles (de)serializing this stinky jeetscript garbage when it never leaves my box and is under no obligation to be compatible with inane web technologies? Webshitters can't even be trusted to spell 'referrer' correctly in their protocols, there's no reason for IPC design to pander to them.

No, DBus is based and absolutely viable for a debloated Linux experience. Its only mistake was to NOT mege into the kernel.
>But muh arcane documentation
Skill issue.

>>108611566
>>108613467
dbus is trash but there aren't enough patches to fix software that depends on it so it creeps into systemd-free distros
KISS linux managed to avoid it entirely and was systemd-free before the BDFL took up farming

>>108613390
>Why do I have to burn power and CPU cycles (de)serializing this stinky jeetscript garbage when it never leaves my box and is under no obligation to be compatible with inane web technologies? Webshitters can't even be trusted to spell 'referrer' correctly in their protocols, there's no reason for IPC design to pander to them.
Simdjson exists. This is a solved problem.

What's wrong with Donostia bus system?

>>108613390
>Is this a joke question? A 5 year old with Down syndrome could engineer a better IPC mechanism.
>https://lore.kernel.org/all/CA+55aFwdk0FYXM=vmWhFye-dzgyBLUzKt40ujjEhKjjBLDwk7g@mail.gmail.com
>>user space was written by a retarded monkey on crack
That's just an argument that the implementation is bad, not the dbus protocol. So whats wrong with the protocol itself?

>>108614786
It's needlessly over complicated to understand, has a sorry permissions story leading to security bugs in things like Flatpak (this is no accident, DBus is hard to secure), it wants to support functioning remotely over a network because it was once trendy to allow that sort of thing but in practice it doesn't work because too many apps depend on passing file descriptors around for performance.

It's just bad, and even the Systemd people that once championed it now see that too.

>>108612099
>The hyprland guy (vaxry) is
just say "i am"

>>108612099
>The hyprland guy
Well, his bloat can't be worse than the alternative so more power to him.

>>108614563
simdjson is okay... if you're stuck with JSON. A hammer in search of a nail. Why use JSON in the first place over POD structs that are both objectively simpler and faster? Doesn't matter whether or not a fake problem can be solved.

>>108614786
An intentionally vague "protocol" is completely worthless without implementation. You can buck pass your way out of any criticism with this flavor of appeal to purity because there isn't anything to ground it in reality, much like a schizo's untestable crackpot physics "theory". Real D-Bus has never been tried. Just wait for the D-Bus ASIC bro, it'll ship on a Lisp machine that's actually fast too!

>>108611566
what the fuck is a "desktop session"?

>>108615753
>Why use JSON in the first place over POD structs that are both objectively simpler and faster?
because those vary depending on the compiler and flags.

>>108614915
To my understanding isn't is mostly an issue of the documentation and their definition of the data (iis(d)ISHITMYBET)? on a protocol level it's just integer types and the array types are size + integers of that size.

>>108611566
dbus is just COM. it's not that bad. it's only bad if you're a tard ass not using a language like rust that can proc macro generate your dbus shit code. It's not the best, but it's good enough imo.

>>108612156
the type system is kind of weak, that's my biggest gripe with it honestly.

>>108615865
I'm talking about a "C-style" struct with well-defined memory layout, not whatever special snowflake shit your FOTM memelang does.

>>108613390
>jeetscript garbage
the only bad things about json is small crap like no trailing commas. it's trivial to parse.
>when it never leaves my box
IPC is (and should be) locality transparent. you serialize/deserialize to a generic representation for the benefit of crossing data representation boundaries. json isn't the only option, but it's a fairly decent one.

>>108615874
Thanks for explaining why its shit.
>microsoft dogshit design
>trooning out and using rust is your solution to make it less dogshit
As per usual, Linux should have copied Plan 9 instead for IPC, or stick to simple portable UNIX sockets and pipes.
https://doc.cat-v.org/plan_9/4th_edition/papers/plumb

>>108611566
why did they even develop dbus?
why not just have a directory with service files like in plan9?

>>108616055
same reason kernel fucks are fatigued dealing with sysfs and procfs and inode exhaustion and shit. filesystem is a poor mechanism for this.

>>108615923
i'm not talking about anything else, why are you starting off from a stance of assuming i'm speaking to something different?
alignment and padding are inherently left up to the implementation. your assumption on how POD works is faulty.

#include <stdio.h>
struct some_structure { int a; char b; };
int main(int argc, char **argv)
{
    printf("%llu\n", sizeof(struct some_structure));
    return 0;
}

a single flag (-fpack-struct for gcc/clang) introduces layout incompatibility even in the most trivial case. in real code, structures can get mangled far more severely than this trivial case. passing around POD is only usable for when the IPC pipeline is between identical binaries.

>>108615923
>well-defined memory layout
>C style
I have C fatigue now as well.
>>108616089
pretty much all that is guaranteed is order of the members, which is hilariously retarded because the compiler can't optimize for alignment/padding.

>>108616082
but it would be a virtual filesystem, an abstraction
and if you have a permissions system you get a natural way to limit who can read and write to what part of your bus replacement
isn't that much better than "do whatever the fuck you want, lmao"

>>108616089
ironically, I've seen real world code literally use std::array and other template types in structs written to FRAM devices and (de)serialized with a cast. it's hilarious. thankfully the "C++ ABI" the C++ committee keeps bringing up seems to hold, assuming you don't change the c++ standard library or compiler. wonder when the next big gcc break will be though. CoW -> SSO std::string was huge.

>>108616115
virtual filesystem is still a filesystem that will have an assload of bugs. again. /proc/net is effectively dead and Linux tells you to use special snowflow AF_NETLINK to get info. you can still use /proc/net, but it's basically lies, especially if you're in a special namespace.
plan9 faggots and their fs obsession is insane.
hell, I don't even think the old timey /dev/fb shit exists anymore in linux.

>>108614563
you missed the point. simdjson will never compare to just reading directly from memory

>>108616055
because linux is genuinely a piece of shit, and trying to implement an interface like that is an exercise in masochism.

>>108616082
unix kernels are a poor mechanism for this*
everybody who ever said "we don't need plan 9, all the good stuff has already been backported!" needs a slap in the face.

windows just werks and doesn't have any of this autistic fragmentation bullshit btw

>>108616408
wtf are you smoking? windows has like 3 different standards for ABIs alone

File: 1763578374951261.jpg (37.3 KB)

37.3 KB JPG

>>108616427
I looked it up, it's 10 actually.
>x64
>COM
>WinRT
>ARM64EC
>4 different ones for x86
>RPC
>Nano-COM

>>108616465
ya. and all the tooling is a mess too. at best you can say that Windows is forced to carry your shit code til death, but that isn't saying much.
I got a lot of shit that needs to be ported because the InternetExplorer.Application COM/OLE/ActiveX/Whatever shitshow literally still opens IE11 which can't render shit, but hey, MS didn't break backwards compat! oh and no drop-in migration path to use Edge/webview2 either.

>>108615937
>it's trivial to parse.
Must be why there are so many formally verified JSON parsers... oh wait.

>for the benefit of crossing data representation boundaries. json isn't the only option, but it's a fairly decent one.
top lel
Your subjective feelings of decency sure convinced me. Decent enough that we better start talking to the kernel using JSON as well. Maybe you can even get the x86 EAG to implement JSON in the instruction decoder, it wasn't bloated enough already after all.

>>108616646
Nice schizophrenic fantasies

>>108616089
>alignment and padding are inherently left up to the implementation
This would break all Linux userspace where structs are omnipresent in the uapi, Linux itself where structs are shared between C code, Rust code and assembly, shared libraries, all UEFI applications where structs are passed to and from firmware, drivers where structs are passed to and from hardware, display servers, among countless other things. You have far bigger problems to worry about, like your system even being able to boot, if your bogus garbage "implementation" provides no means of controlling struct memory layout.

>a single flag (-fpack-struct for gcc/clang) introduces layout incompatibility even in the most trivial case.
https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html
>Use it to conform to a non-default application binary interface
If you change the ABI, the ABI changes! Wow! What amazing revelation will you ever share next? An arm64e binary won't run on MIPS?

File: projector projectively projecting projections.jpg (81.9 KB)

81.9 KB JPG

>>108616661

>>108616197
Yes, but that's also missing the point that some human is going to have to debug that shit at some point and it's way easier if you're not dealing with some binary crap.

>>108613358
Why is pipewire bad? Isn't it meant better than pulseaudio

>>108616997
It is better. They're probably just pissed they no longer have to edit their .asoundrc and alsa.conf to get working audio, Bluetooth and cameras/webcams/screen recording all whilst not needing stupid bridges for JACK when you want to do professional audio grade stuff.

All in all, it just werks and that offends them.

>>108611566
i use varlink so i dont know what you are talking about.

>>108616674
>This would break all Linux userspace where structs are omnipresent
There's a lot of effort put into making it as hard to break as possible, including kernel subsystems having explicit checks to validate and verify padding.
https://www.kernel.org/doc/html/next/userspace-api/iommu.html#id5
>Linux itself where structs are shared between C code
Linux isn't "multiple processes" it doesn't do IPC, is compiled as a single blob. Unrelated, but it does include quite a lot of static checks during compilation to verify structural invariants in other contexts.
>Rust code and assembly
What about C code and assembly anon?
>shared libraries
Yes actually, it's a common problem. They either use a handle system, do the same exhaustive amount of work the kernel does to validate passed structs, or rely on being open source so the user can compile them under the same conditions. In the case they do none of these, this kind of thing is actually very common.
>firmware/drivers
Same story as the kernel
>Display servers
Same story as the kernel (some don't and fall into the same trap)
>like your system even being able to boot
You system does not use IPC to boot
>provides no means of controlling struct memory layout.
At the point you're manually aligning bytes and manually verifying padding, POD turns into a half-assed binary serialization format where the only thing you get out of it is not having to write a serializer.
>An arm64e binary won't run on MIPS?
I mean I did already say that, because yes it is relevant to why passing around C structs is a bad choice for IPC.

It seems you can identify that you have completely missed the point, let me help you by telling you that you don't seem to understand what IPC is or what its usecase is.

>>108617786
>Linux isn't "multiple processes" it doesn't do IPC
Technically there is Netlink. I'm not sure if that counts as an IPC or not though and it's not particularly good. It's a pain in the ass to consumer properly.
https://en.wikipedia.org/wiki/Netlink

>>108612906
>JSON IPC
They took the one thing D-Bus does correctly (a binary wire format) and threw it in the trash. Unbelievable.

>>108618485
No, DBus did not get that right at all. You always have to look up what the right type signature is in order to fucking use it properly because of that crap and sometimes it's really non-obvious and difficult to construct.

>>108615994
9p is slow as balls, even compared to D-Bus.

>>108615994
https://www.kernel.org/doc/html/latest/filesystems/9p.html

>>108618519
I'm talking about the fact that they used a binary format at all. Obviously yes, they fucked it up in the dumbest way possible, but with D-Bus that's par for the course.

>>108617786
>There's a lot of effort put into making it as hard to break as possible, including kernel subsystems having explicit checks to validate and verify padding.
"This is to ensure not breaking userspace in the future when these fields or flags are used."
In other words, the explicitly declared padding fields, not compiler-generated padding, are reserved as they may later become meaningful so as to not increase the size of the struct or require a new struct with new userspace interface. Any benefit to tard wrangling Cleetus' buggy and standards-violating compiler ignoring the struct declaration and randomly changing field offsets and sizes is purely incidental.

>Linux isn't "multiple processes"
cat /proc/*/status | grep "Kthread:" | grep '1' | wc -l

>it doesn't do IPC
It facilitates many forms of IPC and does IPC with userspace all the time.

>is compiled as a single blob.
Linux has supported loadable modules for decades.

>it does include quite a lot of static checks during compilation to verify structural invariants in other contexts.
Any software not doing this kind of rudimentary static analysis is extremely low quality.

>What about C code and assembly anon?
Let's recall one of your claims:
"alignment and padding are inherently left up to the implementation"
A Rust compiler, a C compiler, and an assembler are three different implementations. If they could not agree on struct declarations, the kernel would be horribly broken.

>They either use a handle system
completely irrelevant to your claims.

>do the same exhaustive amount of work the kernel does to validate passed structs
You always have to do validation unless you're in control of both sides or the software can afford crashing/UB.

>>108617786
>or rely on being open source so the user can compile them under the same conditions.
NVIDIA ships CUDA, a closed source library with many API calls talking structs and pointers to structs as arguments, which is widely and successfully deployed in production. If you decide to compile random software components with different, non-standard ABIs, that's your own problem.

>Yes actually, it's a common problem.
>In the case they do none of these, this kind of thing is actually very common.
You're full of shit.

>(some don't and fall into the same trap
The CPU overhead for a JSON-based windowing system must be abysmal

>You system does not use IPC to boot
You claimed:
"is only usable for when the IPC pipeline is between identical binaries."
The UEFI firmware and UEFI bootloader on my system are two different binaries sharing structs, e.g. EFI_SYSTEM_RESOURCE_TABLE. What do you mistakenly believe is so special about an "IPC pipeline" that the behavior must be different there?

>At the point you're manually aligning bytes
You define size and alignment for a few primitive types and the compiler does the rest, or you use Linux or standard library headers which have already done that for you.

>manually verifying padding,
There's no need to validate padding bytes if you don't plan on reclaiming them for other purposes later.

>POD turns into a half-assed binary serialization format
What exactly is "half-assed"?

>the only thing you get out of it is not having to write a serializer
Which shouldn't be downplayed. Just look at the difference in codegen.

>I mean I did already say that, because yes it is relevant to why passing around C structs is a bad choice for IPC.
It's not relevant at all. Linux can only be built to support a single architecture at runtime.

>It seems you can identify that you have completely missed the point, let me help you by telling you that you don't seem to understand what IPC is or what its usecase is.
You seem to be projecting.

File: screen.jpg (34.8 KB)

34.8 KB JPG

>>108611566
It's true, DBUS is awful. I have PTSD from trying to write an interface for it. It's probably the source of the majority of bugs in Linux desktops.
>>108612048
Trinity has DCOP but only Trinity apps support it. The problem with replacing DBUS is we need to convince every app developer to add support.

>>108612906
>which is just JSON RPC over a UNIX socket
pile of shit award

>>108615937
>it's trivial to parse
JSON numbers are anything but trivial to parse and there are multiple articles pointing out this issue. The only thing trivial about them is how easy it is for them to cause data loss. This often leads people to use strings instead which in turn kills performance.
>you serialize/deserialize to a generic representation for the benefit of crossing data representation boundaries
Yeah, and a type-length-value binary format does a better job than JSON under all circumstances.

>>108611566
>They gave up because it's so fucking bad that the performance benefits of kdbus were marginal.
I thought they gave up because Linus prevented it and called them crack monkeys?

>>108614915
Your first paragraph makes dbus look good.
The flatpak concept of security is a failure nobody should support.
Keeping a theoretical capability to run over a network socket is great as well.

>>108621115
>The flatpak concept of security is a failure nobody should support.
It inherits that security failure from DBus though. Since it needs to connect to desktop services it has to make the session bus accessible in the sandbox, there's no other way around that. They end up having to do a whole bunch of mental gymnastics with a filtering proxy to make it work and even then still some things slip through the cracks.

Now imagine a world where this session bus went away and we just had individual apps listening on their own RPC socket. You simply don't put any sockets in the container that aren't needed. Security is easy in this world.

>>108618531
>>108618622
9p is not IPC, the IPC is plumber.
9p is a network protocol, it's competing against NFS not DBus.

File: 2026-04-17-145932_1920x1080_scrot.png (53.8 KB)

53.8 KB PNG

>>108611566
> every anti-systemd neet-distro still uses picrel for desktop sessions
reply to this without sounding mad