Post B7vKLlScJpPNlyS7m4 by grawity@social.treehouse.systems
 (DIR) More posts by grawity@social.treehouse.systems
 (DIR) Post #B7vKLlScJpPNlyS7m4 by grawity@social.treehouse.systems
       0 likes, 0 repeats
       
       # networkctl reloadFailed to issue io.systemd.service.Reload() varlink call: No such device or addresssure would prefer if there had been some transition period where the client tools could fall back to the D-Bus calls...
       
 (DIR) Post #B7vKLlg5VkBSRkksls by grawity@social.treehouse.systems
       0 likes, 0 repeats
       
       the version of networkd that was running was v260, the version of networkctl that I'm now running is v261, don't tell me that it's unreasonable to maintain backwards compat across 2 adjacent releases at the very least
       
 (DIR) Post #B7vKLlrmoFXd22EE0O by astraleureka@social.treehouse.systems
       0 likes, 0 repeats
       
       @grawity wow, a complete lack of backwards compat between adjacent versions is *terrible*i haven't heard about the dbus deprecation though, time to go read up on varlink. is it at least less of a sluggish hog than dbus?
       
 (DIR) Post #B7vMACV89mSu4SF40e by grawity@social.treehouse.systems
       0 likes, 0 repeats
       
       @astraleureka sluggish hog? can't say I've seen dbus-daemon acting like that, usually it does not see enough traffic to be a botherVarlink is, well. on the one hand, it's just JSON over a Unix socket (almost like JSON-RPC but incompatible) – so it's traditional direct peer-to-peer IPC, not a bus or anything like thaton the other hand, it's JSON. and apparently with some ideas from gRPC, since it's no longer a 1:1 call-response (and deliberately not JSON-RPC compatible), there can be multiple replies per call (streaming), etc.it also has protocol switching, apparently systemd now has a Varlink service where you send a specific call, and the varlink JSON socket becomes an SFTP socket.so it's more efficient than d-bus, doesn't require a daemon, you just have a bunch of sockets in /run... but for me personally it feels like much more of a mess than d-bus ever was. like, it has a kind of docker/k8s "HTTP over unix socket as a local IPC mechnanism" vibe. don't ask
       
 (DIR) Post #B7vO5R8OWU4NupSnTc by astraleureka@social.treehouse.systems
       0 likes, 0 repeats
       
       @grawity I've had awful experiences with dbus in the past, especially in resource-constrained environments that have low-powered CPUs - for what should be relatively simple IPC it really seems to require a considerable amount of wall time. the most notable example I have is Grandstream desk phones - dual core ARM SoC (DVF9918) at around 500MHz - they heavily utilise dbus as an event bus for physical triggers (hook switch, dialpad/speed dial keypress, etc) as well as software events (SIP call status, hold/transfer/forward).delays of 1s or more were not uncommon when the SoC was experiencing any sort of load, a really bad experience all around. in a more general sense, I recall discussion maybe ~12-14 years ago about moving dbus to the kernel (kdbus) due to performance concerns, with benchmarks showing context switches having significant measurable impact on heavy IPC loads.re: varlink, I find the decision to strictly rely on an IDL yet use JSON as the wire protocol rather bizarre. JSON on a unix socket can be convenient for prototyping or low-exposure services, but it easily develops into a mess much like HTTP over unix sockets as you mention. disappointing
       
 (DIR) Post #B7vOzw0iueM3tRodMG by grawity@social.treehouse.systems
       0 likes, 0 repeats
       
       @astraleureka yeah I'd say that's an overuse of dbus, surely there was a better way to deliver button presses. Like rely on the shared bus as a discovery point, but have a dbus call to get a direct unix socket FD and then use that for low-latency traffic(even regular GNOME/KDE/etc. use a separate bus instance for accessibility events...)I was only kinda following the kdbus story from the systemd side, and IIRC some of the negative response to it (when it started sprawling into things like bloom filters) was that allegedly *much* of the performance gain was not due to context switches etc., but due to dbus-daemon being slow? so I wonder if dbus-broker generally performs any better than the older dbus-daemon.(there was apparently a 2nd try at kdbus – "bus1" – but I've not followed that at all, in part because most of the people involved had moved out of IRC)
       
 (DIR) Post #B7vPAvvJZrGEoAWwc4 by astraleureka@social.treehouse.systems
       0 likes, 0 repeats
       
       @grawity I vaguely recall BUS1 actually gaining some traction as a potential alternative to Android's binder model, but I also don't follow it and have no idea what ended up happening there