At last count SystemD has over 40 "Interfaces". These are not publicly versioned standards. So there is no stable interface to even implement and there is no commitment that these "interfaces" will not change at any point in time.
If the project estimate to actually implement XYZ interface takes years of full time engineers and millions of dollars to complete its basically out of the reach of any volunteer open source operating system project.
I just find the argument disingenuous. Everyone making these claims knows that there is practically 0 chance that anyone but RedHat or another big Corporation like Google or Samsung has the resources to Implement something like this.
Take a look at https://wiki.freedesktop.org/www/Software/systemd/InterfaceP... and you'll see that there are indeed a plethora of systemd service apis. But almost all of them are covered by the systemd stability promise (https://wiki.freedesktop.org/www/Software/systemd/InterfaceS...) and almost all of them are documented.
So, there is a commitment that these interfaces will not change.
In short SystemD is an implementation. And as they say in there own documents there implementation is and never will be a portable implementation.
The "Interface Stability Promise" is referring to the unit configuration file format and the command line interface. This is not stability of the implementation c interfaces.
If you want to see a proper portable specification take a look at the Wayland Protocol Specification. There or perhaps POSIX.
This is not true.
Isn't this what the systemd 'Interface Stability Promise' does as listed here ?
http://www.freedesktop.org/wiki/Software/systemd/InterfacePo...
Judging by this chart, ~99% of the intefaces are stable.
http://www.freedesktop.org/wiki/Software/systemd/InterfacePo...
CreateSession(in u arg_0,
in u arg_1,
in s arg_2,
in s arg_3,
in s arg_4,
in s arg_5,
...
I remember someone complaining about that years ago already. Apparently nothing changed.
The CreateSession description states that it should never be called from the clients, but instead be handled through PAM, so assume this is why they don't describe the arguments for this one call, while all the other method arguments and return values are described under 'Methods'.
What I mean specifically is that they document the client interface only, not the full interface needed for a complete replacement.
If you want to re-implement logind you will invariably read the logind source code anyway, where the call arguments are described.
You said there been a complaint about this, was there a discussion you can point me to ?
1) Does this mean that you consider software's source code to be adequate documentation of an API and its behavioral contracts?
2) There's this saying that goes something like "You never know that you have a good API until you've created three independent implementations of it.". It's very difficult to create an independent implementation of an API if the primary documentation of important parts of that API's behavior is the source code that implements that API.
If this fails the test, I suggest that it is a marvelous failure which every project should strive to emulate. To suggest that systemd is poorly documented indicates an insufficient exposure to the sad reality of most Open Source projects where "our unmaintained, outdated, bug riddled code base is the documentation" is the best case answer to the question of documentation.
There are a lot of praiseworthy things about systemd and its approach to documentation. The blog posts are definitely one of them. That doesn't mean everything is praiseworthy, that there's no room for improvement, or that complaints about things not being documented are illegitimate or inappropriate.