On 3/13/07, Technical Support <tech@point0.net> 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/vserverReceived on Tue Mar 13 18:44:37 2007