>>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.