|--==> Eric Dantan Rzewnicki writes: EDR> On Wed, Apr 11, 2007 at 02:37:53AM +0200, Free Ekanayaka wrote: >>If my interpretation is correct, my question is, Marco according to >>your experience is the installation of a multimedia/desktop kernel on >>a plain Debian (or Linux) distribution enough to fill the >>responsiveness gap?
EDR> /etc/security/limits.conf needs to be set up as well. It's a simple EDR> step, but I guess it would be good if users didn't have to ask about it. EDR> If the multimedia kernel includes ingo's rt patches, then some script EDR> to set IRQ priorities and such, like Rui's rtirq thing, is also needed. This are both things which are performed automatically in 64 Studio, but not in Debian yet. I've once tried to upload Rui's init script, but it was rejected because considered to tiny. Maybe we could include it as extra in some other package. EDR> I feel like there must be something else, but maybe it's just remnants EDR> of historical cruft lingering in my brain from earlier years when this EDR> stuff took more effort ... Please if you find something more, let me know. >>>>1) Include in Debian a Multimedia/Desktop Kernel IVT> I agree it should also be available an apt-get away nevertheless. >> >>This is actually not that straight. I've tried to that myself about >>one year ago, and the feedback from the debian-kernel folks was really >>positive, but also clear in the "guarantees" that the possible >>multimedia kernel maintainer should offer. I was basically said that >>if I wanted a multimedia flavour to be added, I also had to be >>available to provide support for the security updates, both in stable >>and in testing. This request is pretty reasonable to me, but also >>quite demanding, and I'm not sure if we, as Debian Multimedia Team, >>have the forces to keep with such a task. EDR> Of how many active developers does the Multimedia Team currently EDR> consist? and can we recruit more? Well, a possible definition of the group could be the list of the Alioth's project members http://alioth.debian.org/projects/demudi who are the one with commits rights in the SVN repository, but of course there are much more DDs maintaining audio/multimedia related packages. EDR> Are those handling the alsa packages here? what about xiph-maintainers? EDR> are there other groups? maybe the gst maintainers? I don't know for EDR> sure, but I feel like there must be many more debian-devs who care about EDR> audio and video than those who currently participate in this list. Actually I think that for this kernel matter it's not (only) a matter of how many people you have, but also how much committed they can be. To maintain a kernel flavour requires a very close interaction with the kernel team, which is one of the most active in Debian, and at least the reading of the relevant mailing list (which is rather busy). Probably it's something that could be done by one or two people, but they need to have the proper skills and the necessary commitment. EDR> (I intend to begin the new maintainer process this year, but I don't EDR> count, yet.) That would be great! If you want to start working on existing packages or making new ones, you don't strictly need a debian account. For example I could include you in the Alioth project and you could work directly with project's SVN repository. When you think you're done with some task, just commit it and drop me a line, I can review it sponsor the package for you. >>>>2) Make Jackd usable out of the box or after the installation of a >>>>"normal" package EDR> I've lost the quoting ... so not sure who asked this, but did you mean EDR> make it easy to build and use jack from not-yet-debian-packaged release EDR> or svn? EDR> Removing the .so name mangling as Free has done will help with this. EDR> In my somewhat naive understanding, it seems there are 2 complementary EDR> approaches to this issue: EDR> 1) keeping jack debian packages up to date with jack releases (so fewer EDR> users have a need to build their own). That's something that has always been more or less done, of course we can always be faster. EDR> 2) providing a clear and easy set of instructions for users who want or EDR> need (say for a bug fix affecting them) debs of svn ... perhaps using EDR> svn-buildpackage. So users can easily role their own debs that work EDR> with all of their installed jack apps. Probably for a user it would be simpler to ./configure; make install EDR> (or maybe somehow debs could be autobuilt somewhere for each jack svn EDR> release ... just thinking out loud, not sure if that is practical or EDR> not.) Yes, that could be also done. IVT> I find it usable out of the box... >>I agree with what Daniel said, the focus of general purpose >>distribution is different, but I also agree that we can do much >>better. EDR> I think lenny has the potential to provide a perfectly useable EDR> multimedia workstation with very little end-user pain. True! Free -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
