I was of the impression, that to modify the kernel, a PhD was a must.
I cannot be blamed for this impression, as I am an EU citizen, which
has been agressively pushing for more qualifications of its work
force. The extent of this drive, is that anybody who holds no
qualificatios, is paid a misery compared with those who hold any
qualification, whatever that happens to be. Where I live, the policy
is, if you have no qualifications, you do not deserve to do anything
apart from humble unskilled manual work.
So, please forgive me.
Edward
On 03/08/2015, Rainer Weikusat <rainerweikusat@???> wrote:
> 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?
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
::
Re: [DNG] Unmingling kdbus and the …
