On 3/13/07, Technical Support <[EMAIL PROTECTED]> wrote:
Hi Ken,
However, the folks on our "platform team" are concerned - they want to use a "stock kernel" (which evidently means something downloaded directly from kernel.org) and don't like the idea of a patch.
I doubt there are many people who actually run a "stock kernel." Not because they are kernel hackers, but because practically all the Linux distros have a slightly modified kernel. What you, or your platform team, actually want is not a vanilla kernel. What you need is a maintainer, somebody who looks after the branch and merges the vanilla and whatever preemptive, optimizing, memory, hardware patches you need for your servers. In the case of Linux-VServer you already have that. The illusion that patching isn't the right path is just that, an illusion. It's the same reason you use menuconfig to modify your kernel. Herbert Poetzl and many others take great care in producing the patches and making sure they work. This is why they add a kernel target to the version, so you are reasonably guaranteed that the patch will work. (Although there's no warranty.)
Evidently this causes a long-term maintenance issue - not necessarily from the technical perspective of applying the patch, but from a documentation, regression testing, license compliance (we distribute appliances, so we have to do extra work for GPL compliance), etc.
That isn't entirely the case either, as far as I can see you would need to do this for the vanilla kernel too. The added advantage is that as you know the changes - patches - you are making to the kernel you can guess where the gains and losses will be. I just had to respond, forgive me if I sound a little undaunted by your team's concerns. I realize that once you send out the appliance and it fails it's very difficult to get the customers (trust) back. I know that I don't want it to seem that I'm advocating you selling bleeding edge too your customers, because I'm advocating the opposite. However I get the idea that the "project team" thinks this is just another step in a long manufacturing trail that if slashed would make life easier. It's not going to happen today... D. blaze your trail -- redhat _______________________________________________ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
