Lennart Poettering <[email protected]> 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 <[email protected]> <http://offog.org/> _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
