22 Jun
2009
22 Jun
'09
1:34 p.m.
Lennart Poettering <mzynq(a)0pointer.de> writes:
Really, I see not much value in supporting more than
one kernel.
I find this statement surprising, having found that testing on multiple
operating systems is an excellent way of finding subtle bugs in code.
(I assume you're just talking about RealtimeKit here and not PulseAudio
as a whole, since there are clear advantages to making that available to
as large a userbase as possible if you want it to be widely adopted...)
There is not compile time dependency on rtkit and no
runtime
dependency either.
Yes, there is a runtime dependency on RealtimeKit -- else there would be
no point in having it in the first place! If I'm building an operating
system package for an application that wants realtime priority, then my
package has to have an explicit dependency on RealtimeKit as well as
D-Bus.
Also, the client reference implementation is tiny. it
just wraps two
method calls. Trivial stuff.
It's neither trivial nor tiny -- rtkit.c is a bit over a hundred
non-comment/blank lines of code. The entirety of thread.c in libjack
(which handles getting realtime priority on a variety of operating
systems, among other things) is less than two hundred. This should be in
a library, *not* copied-and-pasted into multiple places; that's a
maintenance nightmare waiting to happen.
I should be clearer here that I think the RealtimeKit approach is
actually pretty sensible on Linux, and I don't have any objections to
using D-Bus. I just think it's important to recognise that this approach
is not appropriate for all platforms, and providing a more conventional
library interface would be more convenient for programmers, more
portable, and generally better software engineering practice.
Then file a bug.
I have done. I wasn't aware that it *was* a bug until you commented on
it; I'm used to trusting packages' explicit statements in their
documentation about their licenses. (Looking at license statements in
headers is not sufficient; as in RealtimeKit, it's very common to have
different licenses applying to different files, or dependencies on
libraries which end up restricting the license of the overall package.)
Thanks,
--
Adam Sampson <ats(a)offog.org> <http://offog.org/>