Didier Kryn <kryn@???> writes:
> Le 03/08/2015 12:03, Rainer Weikusat a écrit :
>> Edward Bartolo <edbarx@???> writes:
>>> I would like someone from Devuan to reply how Devuan DDs are going to
>>> rid the Linux kernel when kdbus becomes integrated in it. I am finding
>>> this latest news a heavy blow below the belt, as the kernel is usually
>>> reserved for highly qualified and highly skilled coders.
>> A completely different remark: What you find in the kernel (or any other
>> software) is code and not coders and someone being "highly qualified and
>> highly skilled" (whatever this is supposed to mean precisely) is not the
>> same as "all code written by said someone will be of high quality" and
>> what precisely constitutes "code of high quality" is very much a matter
>> of opinion (and many opinions people hold on such topics are not exactly
>> perfectly rational). Eg, the people working on kdbus certainly consider
>> it code of high quality (and everyone who things otherwise a dimwit
>> whose opinion doesn't matter or someone with a nefarious, hidden agenda
>> whose opinions ought to be ignored because they're just blinds, anyway)
>> and the other party - compose of exactly the same kind of beings
>> commonly known as humans - sees this in exactly the same way, just with
>> a different sign.
>

>     Which matters in the case is what Linux Torwalds and other kernel
> developpers think of the quality of dbus, and the opinion of Torwalds
> is very bad, and for this reason he still rejects the main argument in
> favour of kdbus, which is performance.

Unless you happen to work for him, opinions of Linus Torvalds only
matter insofar they make any sense, not because they're his
opinions. But since he's generally a sensible guy, they usually do make
sense[*]. But that's besides the point I was trying to make, namely, the
"us versus them" framing this debate (generally speaking) has so
energetically been nailed to is irrational and counter-productive,
especially as there's little doubt who will prevail in the shouting
match, considering the history so far: Udev became a requirement by
sucking up hotplug, systemd became a requirement by engulfing udev,
kdbus will become a requirement by becoming a necessary precondition for
running systemd. And this has nothing to do with "skilled coders" or
"quality code" despite all disgreeing parties violently claim that their
standpoint is right and everyone else is wrong but with the well-known
fact that "God always fights on the side of those who can muster more
soldiers".

So, if you're (addressed to anyone) opposed to kdbus then please find a
better reason then "someone whom I'm a fan of once said ...". Eg, I
wouldn't want to use the D-BUS protocol for anything because I think
that each technical problem should have the most simple solution which
is feasible and not the most comprehensive one which can also be
stretched to accomodate it. I've written ASN.1 parsers and encoders in
the past. I may one day have to do the same for D-BUS but I certainly
won't ever employ it in place of something which can also get the job
done but specifying that and writing and debugging the corresponding
code takes 1/10th of the time which would be necessary to read and
comprehend the D-BUS specification. That's one very high-level technical
reason. I could provide more but I don't want to turn this posting into
something rivalling a master thesis in size.

Considering who designed D-BUS, this was about what I expected them to
come up but my (or anyone else's) personal beliefs about the involved
people don't really matter in the context of a technical problem.

[*] In case you want an example where this is at least debatable (and I
    happen to disgree with what he wrote on the topic). The simplest way
    to implement a block memory copy in C is

    static void cpy(char *d, char const *s, size_t len)
    {
        while (len) --len, d[len] = s[len];
    }

>     You will certainly agree that, if kdbus is provided in the kernel,
> there is nothing we can do against it,  but nobody forces us to use
> it, nor even to enable it when compiling the kernel.

I think this is a bizarre question: I've been maintaining kernel forks
with more or less far ranging modifications since 2004 and I'm a single
guy. If person XYZ integrates something with some kernel source tree,
person ZYX is absolutely free to take it out of it again. But why, ie,
why do you (the OP) think integrating one more feature of dubious
usefulness and sub-par quality of implementation because the people who
want it integrated are in the position to get what they want matters to
you?