Systemd Looking At A Future With More Varlink & Less D-Bus For IPC

[fitzie]

This should still be possible given that a D-Bus interface can also be consumed/driven by a commandline tool.

They are essentially two different levels of API, targeting different usages.

A higher level API in the form of commandline tool(s) targeting system administrators (and advanced users).
A lower level API in the form of D-Bus objects targeting developers.

Similar to how some web based services have both website and REST API.

In both cases the higher level API is often built on top of the lower level.

i've spent enough time learning bad systems to make them work, that I'm not going to do it again if I can avoid them. those midlayer tools are suppose to be the command line interface to systemd, but they suck (by design) for scripting.

[access]

[...] we use to write shell scripts that could just ifconfig | grep sed etc..[...]

Those were horrible days... especially ifconfig since it's been deprecated for decades and had really bad output to parse if for even simple things.

systemd has been a godsend when it comes to system management as it eliminates tons of hacky script guesswork. More varlink support enables non hacky script work, if it's needed, as it is easily accessible and there are tons of tools available (hello jq).

[BlueCrayon]

Attempts at reimplementing MACH IPC will continue until morale improves

[LtdJorge]

systemd didn't just use dbus, they actually re-implemented it, presumably to avoid certain things they didn't like about libdbus. One thing I'll say for their sd-bus implementation is that it includes built-in support for the introspection interfaces, which makes it an absolute dream when using something like Python.

It makes sense, since freedesktop’s official dbus documentation states "It should be noted that the low-level implementation is not primarily designed for application authors to use. Rather, it is a basis for binding authors and a reference for reimplementations. If you are able to do so it is recommended that you use one of the higher level bindings or implementations."

Anyway, most application authors are just using the reference implementation 🤦♂️

[drjohnnyfever]

FreeBSD and Solaris have had interfaces literally purpose built for this type of thing for eons. It's called an nvlist

See the man page

https://man.freebsd.org/cgi/man.cgi?query=libnv

[anda_skoa]

those midlayer tools are suppose to be the command line interface to systemd, but they suck (by design) for scripting.

I am not sure if those tools, e.g. systemctl, suck "by design".
Their authors might have just had different use cases in mind.

One good thing about the availability of the lower level APIs is that somebody with different use cases can create their own tools.

Not necessarily you in particular but somebody who has the same use case or wants to support it more directly.

[anda_skoa]

Anyway, most application authors are just using the reference implementation 🤦♂️

Yes, but usually indirectly through their respectively preferred bindings.

In case of desktop services and applications usually the GLib or Qt bindings as they provide much nicer API than the low level reference implementation.

Essentially it mostly boils down to whether it is easier for language/framework to wrap the low level C API or do socket communication directly.

[fitzie]

Those were horrible days... especially ifconfig since it's been deprecated for decades and had really bad output to parse if for even simple things.

systemd has been a godsend when it comes to system management as it eliminates tons of hacky script guesswork. More varlink support enables non hacky script work, if it's needed, as it is easily accessible and there are tons of tools available (hello jq).

godsend because it's so overly complex and non-intuitive you need to hire a systems guy to manage it, and they are going to hire a programmer to create some sort of sane interface around it.

[Weasel]

IMO, the main place where unsigned integral data types are truly defensible is for bit masks, in which case you also need to know the range.

uint64.

Speaking from experience, AutoHotkey doesn't support unsigned 64-bit ints (everything is 64-bit signed integer), exactly like this. It creates a plethora of annoyance when dealing with true 64-bit unsigned ints.

[Errinwright]

leave it to systemd to get away from well polished solutions like dbus and infest my system with this bloated nonsense...

You must not have watched the presentation, because this garbage you let out is nonsense.