[cgl_discussion] Re: [cgl_specs] Use case - Live patching

Corey Minyard cminyard at mvista.com
Tue Mar 29 11:42:49 PST 2005


Ralf Flaxa wrote:

>Then it should be stated very explicitely that this feature may only
>be used for and by applications and that it is forbidden to patch
>the underlying distro with it.
>  
>
I would restate this to say that the distros *may* restrict it to not 
patch the underlying distro-provided things.  It may be that some 
distros will work with their users to provide runtime patches for bugs 
in things like glibc or other base libraries.  A strong restriction like 
this doesn't make any sense and limits the tool's use in the marketplace.

>I am wondering why the distro then should even provide that functionality?
>Why doesn't the app provider take care of this himself then if it is just
>meant for his app?
>  
>
Hmm, why doesn't the user provide their own openssl libraries?  Or 
glibc?  Shoot, why don't they provide their own OS?

-Corey

>	Ralf
>
>On Mon, Mar 28, 2005 at 03:19:07PM -0700, Steven Dake wrote:
>  
>
>>>From the distro perspective, I can understand your serious discomfort
>>with supporting live patching of applications specific to the operating
>>system (and in the distributor's support domain).
>>
>>The live patching feature, atleast during the specs development, was
>>targetd for use in carrier(and other interested parties) applications
>>which are supported and maintained by the carriers/others.  We  never
>>stated in the requirements that the distribution itself must support
>>live patching of the entire system.  If you point out the specific
>>requirement that requires or implies this, then it is something that
>>needs adjustment in the specification..
>>
>>Perhaps wording of the intended use (for carrier applications, not for
>>distro upgrades) would be helpful.
>>
>>If live patching then becomes a "customer issue", it is really of no
>>concern to a distro whether the customer chooses to patch their own
>>applications or not.
>>
>>Regards
>>-steve
>>    
>>




More information about the cgl_discussion mailing list