<servicehelper> in a conf file and a launch helper have definitely worked, although I haven't re-tested in the past couple of years. My launch helper is just a script that knows how to invoke various commands such as initctl or system-control.
The irony, as explained on the FGA there, is that they could have made the #DesktopBus broker itself talk to multiple service managers and know what to do; had patches to do so not been blocked.
For best results, one has to turn off the Desktop Bus broker's own rubbish service launching and intercept and send all service launch attempts over to proper service management.
https://jdebp.uk/Softwares/nosh/guide/per-user-dbus-demand-start.html
https://jdebp.uk/Softwares/nosh/guide/commands/dbus-daemon-launch-helper.xml
https://jdebp.uk/Softwares/nosh/avoid-dbus-bus-activation.html
I'd be happy for feedback / corrections / suggestions regarding (#electron 's) auto-discovery of secret service providers using #dbus in https://github.com/electron/electron/issues/47436
As a long-year #sway (prev #i3) user, this has been bugging me for literally ages, and i would love to see a better usage of the available #freedesktop APIs. With packages like electron, there is a lot to gain, as (like it or not) many desktop applications use electron nowadays.
Does Ubuntu Server use D-Bus? #server #notification #dbus
Spent some time with #Voidlinux #musl last night.
It's like "who I am", "why I'm here", "what I'm doing". I found no clue to set up system language without #locale, and I can't even find a way to start #dbus.
Should Back In Time inhibit suspend or idle mode by default?
Thinking out loud: is there a way to get systemd to pass a D-Bus system bus socket FD to a service when it’s bus activated (i.e. via `LISTEN_FDS`)? Would mean the service could sandbox AF_UNIX socket connectivity (if it only needed that to connect to the bus, which I guess is true for some bus daemons). Downside ottomh: system bus connection policy would be bypassed (though it allows all connections by default) and the auth would still need to be done by the service.
I'm actually having way to much fun with this little pet project. I can now cycle through multiple instance of an application, get media status, etc...
It's intended to facilitate my own personal workflow,
it's not generic enough for public use... yet.
I'm looking into some #automation on #ubuntu #gnome desktop. I figured I'd be able to do everything using #dbus.
It works great for media control but not so much for virtual desktop / window management. I can use #wmctrl to nativate between virtual desktops but window management doesn't work on #wayland. Then there is #ydotool which also doesn't seem to work well.
Now I can
- Control media via dbus
- Switch workspaces via wmctrl
But I feel there has to be a better way?
How would a desktop environment send a D-Bus message to the currently-active window and only that window would do anything with it? Would every window get the message and then only do anything if it (that window) is focused? Seems kinda wasteful, but it's the only thing that I can think of so far, and I've been thinking about this for a few years now.
In short: we already have a perfectly serviceable IPC system. I see no good reason to introduce another incompatible one, especially not one that, if I'm reading the docs correctly, can't even be used by processes not directly started by #systemd (e.g. the shell inside a terminal window on a desktop).
And if we really want to replace D-Bus, then actually completely replace it. Don't just add another thing that weirdly coexists with it and does mostly the same thing.
A new and improved way to look up users and groups sounds nice, but the use of varlink is extremely suspect.
https://systemd.io/USER_GROUP_API/ explains why it is used, but all 3 reasons given are nonsense:
1. Why the hell do you need to look up users/groups when D-Bus isn't even running? Tons of things already don't work without D-Bus, so you have to start it ASAP anyway.
2. Not a problem; see next answer.
3. Then pass a socket fd over D-Bus and send the records over that.
Freedesktop.org (X.org, Wayland…) se cherche en urgence un nouvel hébergement. Les projets créés et gérés sous son égide sont nombreux et importants. Les deux plus connus sont #Xorg et #Wayland. Parmi les autres projets majeurs, citons #PipeWire ou #DBus
https://next.ink/brief_article/freedesktop-org-x-org-wayland-se-cherche-en-urgence-un-nouvel-hebergement/
TIL Network protocols Sans I/O ⚡
“… network protocol implementations written in Python that perform no I/O (this means libraries that operate directly on text or bytes; this excludes libraries that just abstract out I/O).” 🤯
Read the reference page 👇
https://sans-io.readthedocs.io/
#Reusability #Python #FastCGI #HTTP2 #H11 #IRC #OAuth2 #OAuthLib #WebSocket #SOCKS5 #RFC2217 #SerialOverIP #EPICS #FIX #QUIC #LanguageServerProtocol #SMTP #DBus #ThorlabsAPT #Matrix #SSL #TLS #CPython #multipart #formdata
