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

[Corey Minyard]

No.  A standard that restricts extra things a distro may do is wrong.  
This has nothing to do with verifiable certification.

IMHO, all a distro should be required to do is allow patching of a user 
application.  With that, it would clearly meet CGL requirements and it 
is verifiable.  A distro may restrict that to only user applications, it 
may allow patching of core components, it may only allow it's own 
patches to be used for core components, etc.  But adding a restriction 
where the distro may not allow it's libraries or OS to be patched is an 
extra restriction that adds nothing to certification and limits what a 
distro can to beyond the standard to compete in the marketplace.

And you comment about being fuzzy about what is and is not allowed is 
not correct.  I'm sure SuSE ships a lot of packages that are not 
mentioned in the CGL standard.  Would you like to have to remove all 
those packages and only ship what is explicitly mentioned in the 
standard?  The standard should be clear about what is required, and 
should not be fuzzy about that.  However, it should allow things beyond 
the standard.  Allowing this does a couple of things.  It lets the 
distro vendor add value beyond the standard.  It shows where the 
standard needs to be extended.  And it allows new technology to be 
tested in the market.

I believe a limitation like this would be like adding the limitation: 
"You can only provide support 12 hours a day."  It's an unnecessary 
limitation.  The distro should be able to provide any level of support 
it thinks customers require.

-Corey

Ralf Flaxa wrote:

>You claim that you want to set a standard with CGL, right?
>But a standard that only some distros would follow or that is
>fuzzy about what is allowed or not is not a standard IMHO.
>The term "certified" has to be verifiable.
>
>	Ralf
>
>On Tue, Mar 29, 2005 at 01:42:49PM -0600, Corey Minyard wrote:
>  
>
>>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
>>>>  
>>>>
>>>>        
>>>>