Matt Williamson wrote:
>>> I have seen it argued that one issue with the proposal is that now the 
>>> "Adminstrator" has lost control of what's installed on users systems. 
>>> With zip distros they have less control don't they? The current 
>>> customers we have using these distros haven't seemed to mind too much 
>>> about them until now.
>>>
>> No, I didn't say they "lost control".  But the proposal is only a bare 
>> minimum replacement, and provides no additional control where it seems 
>> it would be desired.  We need to anticipate what customers next need 
>> will be, not just what they've complained about in the past.  And if 
>> everyone was actually happy with zip distros, then why do we need the 
>> proposal?  You can't have it both ways.
> 
> I disagree, it is more than a bare minimum replacement. There is now a 
> way to detect what was done to the system, by the user, and track it. 
> Also, now the user can have one set of tools to manage the software. 
> That is a significant improvement, in my mind.
> 

It's a "bare minimum" because all that's proposed is to remove some 
restrictions on the package tools, without consideration of enhancements 
that might be advisable in light of that removal.  Making it so that the 
"registry" of packages that's installed on the system is no longer 
completely contained in /var/sadm changes assumptions that users have 
held about Solaris for 15 years.  It's not a question of whether it's an 
improvement, it's whether it's enough of an improvement.

>>> Don't get me wrong, I do believe that better software management tools 
>>> are needed for Solaris, including in the packaging area. However I 
>>> don't believe that this proposal is the wagon that those should be 
>>> hitched.
>>>
>> I'm pretty unmoved by this; at some point you have to take action to 
>> help manage the increasingly complex range of options introduced. 
>> Failing to address it at the time you increase the complexity is merely 
>> a false economy by cost-shifting that's usually exposed later, and 
>> remedied at even greater cost, with less flexibility.
> 
> I don't see how this is increasing costs to anyone. Can you expand on 
> why you feel it is?
> 

It increases the costs of Open Solaris development over time if a 
project is missing key requirements, because we often have to initiate 
emergency projects and design additional complexity into the remedies 
and any layered functions to account for the differences.  That's 
cost-shifting, and it's something that we both know the Solaris 
installation technologies have been victimized by many times.

Dave

Reply via email to