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 <[email protected]> wrote: > Didier Kryn <[email protected]> writes: >> Le 03/08/2015 12:03, Rainer Weikusat a écrit : >>> Edward Bartolo <[email protected]> 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 > [email protected] > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
