On Mon, 27 Oct 2003, Michal Zeravik wrote: >I'm using redhat9 shrike and have couple of questions: >Will be here a stable release of Fedora? > > Of course. Fedora Core 1, by definition will be the stable OS release. >Can I upgrade Shrike directly to Fedora? > > Yes. But upgrades from any beta release to Fedora Core 1 might or might not work - it's never guaranteed. >Does Fedora have the same patches in kernel like in other rh >kernels? > > Hard do answer that without you giving specific references to individual patches and then comparing the kernel from Fedora to the kernel from a previous release that you're refering to within the context of the comparison. The Fedora Core kernel is developed and maintained as it always has been within Red Hat Linux in the past. It is a newer kernel version than what is in Red hat Linux 9, so there will of course be differences as some stuff has been merged into the upstream kernel, etc. now. >Can I use other patches to kernel (low latency, capabilites, >preemptive,...)? > > There's nothing preventing anyone from patching the kernel with whatever they are skilled to engineer a patch for. Since most 3rd party patches out in the wild are based upon Linus's official kernel releases, as always, they may or may not apply cleanly to Red Hat's kernel because our kernel is not a stock Linus kernel. Our kernels contain numerous patches, and if the patch you wish to apply conflicts with other patches we already ship, then you may have to fix things by hand in order for it to apply. Once it applies, it may or may not work at all depending on what the external patch is dependant on, and what might have changed in our kernel. Low latency patches have been included in Red Hat kernels for a long time. Not sure what exactly you mean by "capabilities" as Linux capability support has been there for years, possibly since 2.0.x kernels. You'd need to clarify that. Pre-empt patches are not present, and are not really useful anyway. I'll leave that as a subject of debate though between those who care to debate it, and the relevant and knowledgeable kernel people. Or for mailing list archives or google. Hope this helps.

On Mon, 27 Oct 2003, Michal Zeravik wrote: >Date: Mon, 27 Oct 2003 12:16:29 +0100 >From: Michal Zeravik <michalz(a)olomouc.com&gt; >To: fedora-test-list(a)redhat.com >Content-Type: multipart/alternative; >boundary="------------040106090107030308080404" >List-Id: For testers of Red Hat Linux beta releases > <fedora-test-list.redhat.com> >Subject: Re: rh9 vs. fedora > >Originally I'm interested in audio/video processing. >Using Alsa/Jack/Laddca in realtime needs that: >http://jackit.sourceforge.net/docs/faq.php#q5 >So you mean I can install sources of my current kernel (2.4.20-20-9) >and build it on my own with what properties? > > Correct, that is how you would go about attempting to patch the kernel and use it. The only way you can be guaranteed a patch for anything will apply to a given source code tree or not however (kernel or otherwise) is to use the source code that the author of a given patch used to create their patch. The majority of kernel patches out there are generated against Linus's kernels, and so the only way you can be reasonably sure they will apply to the kernel source is by using Linus's kernel source. If you apply a patch to the Red Hat kernel source, which is very heavily modified, the patch may apply cleanly if it does not overlap on any other areas of the kernel source which other patches are already applying to. It might even apply cleanly with a bit of fuzz factor. If you do get a patch to apply though, wether it applied cleanly, with fuzz, or required re-engineering the patch to apply to the Red Hat kernel, it may or may not work at all. It depends on if the patch you're using relies on stuff from Linus's kernel to be there which may have been changed or even heavily modified by the Red Hat kernel's patch set. In short, the only way you can be sure any kernel patch will ever apply to the kernel source tree you use, is to apply the patch to the kernel source that the author of the patch used, or to become kernel engineer for a day and port the patch to the kernel source that you are using now. Hope this helps.