> welll.... there's a difference between including dependencies on
> systemd *itself* and converting code over to use the d-bus API. not
> that i like d-bus (long story: in 2005 i compared the spec to DCE/RPC
> and it was absolutely identical... except that d-bus only implemented
> about 25% of what is in DCE/RPC... *sigh* but i digress... )
>
> so for example here:
> https://forums.freebsd.org/threads/kde-plasma-5.47280/
>
> it would seem that someone has noticed that the hard-dependency in
> KDE5 is *not* on logind itself, but is on the d-bus interface *to*
> logind
>
> ... therefore, as long as you can provide a re-implementation of the
> other side of that service, you're good to go.
>
> and as long as *all* the applications which use systemd do so via
> d-bus interfaces, then it is really not so disruptive a proposition to
> replace them all as it first seems.

This is a distinction without a difference. An API is more than a
collection of method signatures--an API is a contract that imposes semantic
constraints on what a drop-in replacement is required to do. It's not
enough to put code behind the method--that code must also *behave*
according to the API's specification. The more semantic constraints the
API imposes, the less freedom the developer has to implement it.

Whatever implements logind's API (or any systemd component's API) will need
to follow the API's semantics closely enough to keep up its end of the
contract. This is a non-trivial undertaking, since systemd imposes a lot
of very specific semantic constraints--for example, logind requires systemd
in part because its API necessitates a reliable process-tracking
mechanism. I applaud Dima Krasner for his work on coming up with an
alternative implementation (LoginKit) that is semantically identical to
logind (or close enough that differences won't matter in practice), because
avoiding requiring systemd will certainly be difficult.

It's easy to create an API that matches only your implementation, which is
what the systemd developers did (they even say as much). It's hard to
create a meaningful API that preserves freedom of implementation.

-Jude

On Sat, Feb 14, 2015 at 8:06 PM, Luke Kenneth Casson Leighton <lkcl@???
> wrote:

> On Sat, Feb 14, 2015 at 10:55 PM, KatolaZ <katolaz@???> wrote:
> > On Sat, Feb 14, 2015 at 05:46:03PM +0000, Luke Leighton wrote:
> >
> > [very long cut]
> >
> >>
> >> this is again a self-fulfilling statement of intent, where i have
> >> demonstrated logically and rationally above that the grounds for the
> >> conclusion that you draw are incorrect.
> >>
> >> is there anything that you can perceive which is incorrect about the
> >> rationale i give above?
> >
> > Hi Luke, a very nice theory is yours, indeed, and I am not
> > kidding.
>
> thanks. occasionally i have useful insights - even more occasionally
> i'm able to communicate them effectively :)
>
> > Unfortunately, in practice we already might miss some of the
> > packages of Jessie because of the systemd-nonsense, and not because of
> > an explicit anti-Debian choice of Devuan developers.
> >
> > And things will apparently not get better anytime soon, since more and
> > more packages are including dependencies on the systemd-nonsense, and
> > this is totally beyond your control.
>
> welll.... there's a difference between including dependencies on
> systemd *itself* and converting code over to use the d-bus API. not
> that i like d-bus (long story: in 2005 i compared the spec to DCE/RPC
> and it was absolutely identical... except that d-bus only implemented
> about 25% of what is in DCE/RPC... *sigh* but i digress... )
>
> so for example here:
> https://forums.freebsd.org/threads/kde-plasma-5.47280/
>
> it would seem that someone has noticed that the hard-dependency in
> KDE5 is *not* on logind itself, but is on the d-bus interface *to*
> logind
>
> ... therefore, as long as you can provide a re-implementation of the
> other side of that service, you're good to go.
>
> and as long as *all* the applications which use systemd do so via
> d-bus interfaces, then it is really not so disruptive a proposition to
> replace them all as it first seems.
>
> ... luckily, when searching "alternative logind" guess what came up?
>
> https://git.devuan.org/pkgs-utopia-substitution/loginkit/blob/master/debian/control
>
> hey you should talk to those guys, they might have something that
> could do the job, as long as it's behind a d-bus interface :)
>
>
> > For the moment I would be content to have a working Devuan (i.e., a
> > Debian without the systemd-nonsense), knowing that it inherits some of
> > the merits of one of the most important collaborative projects in the
> > history of Free Software, wouldn't you? :)
>
> i'm tempted to say yes - really! but i need several things:
> continuity for my clients (including two desktop systems), access to
> weird archaic packages at the forefront of software libre technology
> (four years ago i provided *full* python bindings to over 20,000
> functions and properties in webkit that are considered the exclusive
> domain of javascript for example), and continuity on the (five or so)
> servers that i run.
>
> so whatever i go with, it has to be stable (or small enough for me to
> maintain myself). i can't even contemplate, right now, converting to
> e.g. FreeBSD even though i use fvwm2, because i am going to be in the
> middle of a huge project running qemu, librecad, openscad, blender,
> repsnapper and more, for several more months. i can't afford any
> downtime on it for things like "convert to FreeBSD", esp. on a strange
> piece of hardware as a macbook pro (UEFI boot only).
>
> bottom line is: i *really* have to be careful, when previously i
> would have been happy to just go "yippeee!" :)
>
> l.
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>