Re: [Cooker] Re: kernel-multimedia-2.4.21.0.18mdk-1-1mdk
On 2003.04.06 21:05 Brian J. Murrell wrote: On Mon, Apr 07, 2003 at 01:36:09AM +0100, Adam Williamson wrote: Yes - can we please decide exactly what this kernel is for? At first it was simply the stock kernel with a couple of patches for music editing. Well, I saw it as more multi-media than just music editing. Multi-media, whether it be audio or video (or both) have much the same requirements. Yes. It is called the multimedia kernel, not the music editing kernel. Now it seems to have turned into a test bed for features that have nothing to do with multimedia (wireless driver patches?) This I will agree with. Well, we're in a bit of a predicament, because it has been recently very difficult to achieve effective communication from the kernel team, so I certainly don't blame Danny for fixing things that are obviously broken - be they multimedia or not. That's not to judge whether it's right or wrong, but you have to understand that it's very frustrating telling staff that something's broken for MONTHS and not having it fixed. And now you want it to provide stuff for doing PVR. I agree that it should be the stock kernel + multimedia needs (ONLY!). I don't want it to be a hackkernel either. In my mind, the multimedia kernel is used when desktop functionality is more important than security. There are security risks involved with the pre-emptive patch, and even moreso with the capabilities patch, but someone making videos doesn't care... he wants his editing done as fast and efficiently as possible. So I'd suggest this: The multimedia kernel is not just for audio/video editing, it is for boxes which are more concerned with advanced USABILITY than with security, stability, support, or official status. Thus supermount fixes are fine. They enhance usability greatly, with a small, potential loss to stability and/or security. That's just my take on it. I don't feel volunteers should just go adding any patch they want... there must be a significant benefit. However, this is a way that: 1. Mandrake can come to terms with a more community oriented infrastructure... and see that it works. 2. Purely desktop users can get fast, easy useability. 3. Mandrake won't have to assume resposability for potentially risky patches. Hope that puts some of your minds at ease. I'm far from the autoratative voice on this subject though... Austin -- Austin Acton Hon.B.Sc. Synthetic Organic Chemist, Teaching Assistant Department of Chemistry, York University, Toronto MandrakeClub Volunteer (www.mandrakeclub.com) homepage: www.groundstate.ca
Re: [Cooker] Re: kernel-multimedia-2.4.21.0.18mdk-1-1mdk
On Sunday 06 April 2003 18:05, Brian J. Murrell wrote: I agree that it should be the stock kernel + multimedia needs (ONLY!). I don't want it to be a hackkernel either. Maybe there should be a kernel-hack in contrib. There are probably people who are using (or would use, if they knew about it) -mm who aren't doing any multimedia, just because they want some of these patches (like supermount). That's fine, but those people shouldn't be arguing for patches to go into the next version of -mm. And if they had a separate -hack kernel where they could get the patches they wanted, they wouldn't be. If, as Austin Acton suggests, you broaden the definition of multimedia to mean something like pure desktop computing, that still leaves out plenty of patches that have nowhere else to go, and the broader definition will only make people more likely to try to get them crammed into -mm. The obvious question is, who is the hack kernel for? Nobody's going to want to turn on every patch in the world, right? Well, I know quite a few people who configure and rebuild kernels all the time but never patch them. (With FreeBSD, even beginners are expected to configure and rebuild their kernel, but only experts are supposed to patch it)
Re: [Cooker] Re: kernel-multimedia-2.4.21.0.18mdk-1-1mdk
On Sun, 2003-04-06 at 19:04, Austin wrote: On 2003.04.06 21:05 Brian J. Murrell wrote: On Mon, Apr 07, 2003 at 01:36:09AM +0100, Adam Williamson wrote: Yes - can we please decide exactly what this kernel is for? At first it was simply the stock kernel with a couple of patches for music editing. Well, I saw it as more multi-media than just music editing. Multi-media, whether it be audio or video (or both) have much the same requirements. Yes. It is called the multimedia kernel, not the music editing kernel. Now it seems to have turned into a test bed for features that have nothing to do with multimedia (wireless driver patches?) This I will agree with. Well, we're in a bit of a predicament, because it has been recently very difficult to achieve effective communication from the kernel team, so I certainly don't blame Danny for fixing things that are obviously broken - be they multimedia or not. That's not to judge whether it's right or wrong, but you have to understand that it's very frustrating telling staff that something's broken for MONTHS and not having it fixed. And now you want it to provide stuff for doing PVR. I agree that it should be the stock kernel + multimedia needs (ONLY!). I don't want it to be a hackkernel either. In my mind, the multimedia kernel is used when desktop functionality is more important than security. There are security risks involved with the pre-emptive patch, and even moreso with the capabilities patch, but someone making videos doesn't care... he wants his editing done as fast and efficiently as possible. So I'd suggest this: The multimedia kernel is not just for audio/video editing, it is for boxes which are more concerned with advanced USABILITY than with security, stability, support, or official status. Thus supermount fixes are fine. They enhance usability greatly, with a small, potential loss to stability and/or security. That's just my take on it. I don't feel volunteers should just go adding any patch they want... there must be a significant benefit. However, this is a way that: 1. Mandrake can come to terms with a more community oriented infrastructure... and see that it works. 2. Purely desktop users can get fast, easy useability. 3. Mandrake won't have to assume resposability for potentially risky patches. Hope that puts some of your minds at ease. I'm far from the autoratative voice on this subject though... Austin One question though... why does the kernel have a dependency on shorewall?
