UNIX admin wrote:
> Because if we want to be ready for the future, we must now maintain two sets 
> of packages for every component - one for the enterprise, which is what feeds 
> us and pays the bills, one for being ready for the future.

And if it wasn't IPS, then it would be some other feature in Solaris 11 that
would make you have to choose between the least common denominator and
supporting all the new features.   This is the same dilemma every OS provides
with new releases - "Do I have one common binary for all versions, or
customized ones that take advantage of newer features in newer releases?"
- it could be Solaris 8 vs. 10 (see the blastwave dilemma on linking to open
source libraries in the OS there for instance) or Windows XP vs. 7.

> But that costs tremendous amounts of effort and money; it's very expensive.
> 
> pkgadd(1M) could have been incrementally improved with the backgraph 
> algorithm in AWK and "the C programming language" books which the make(1) 
> tool also uses, why wasn't this done instead?
> pkgadd(1M) could have been incrementally improved, based on pkgtrans(1), to 
> have knowledge of true package clusters instead of the loose package 
> metacluster (like "SUNWCall"), why wasn't this done?
> pkgadd(1M)'s capability to install packages via http:// protocol could have 
> been extended further, coupled with the dependency resolution algorithm, to 
> automatically install any and all needed packages over the network, like yum 
> install and pkg_get(1M) do; why wasn't this done?

"Why did Sun have to create ZFS instead of just extending UFS more?"
"Why did Sun have to create SMF instead of just extending init.d scripts more?"
"Why did Sun have to move to GNOME instead of just extending CDE more?"
"Why did Sun have to move to SVR4 instead of just extending SunOS 4 more?"
"Why did Sun have to create SPARC instead of just building more 680x0 machines?"

Change is inevitable in IT - sometimes the amount of change you need to make is
so great that replacement is the most viable option (allowing side-by-side
implementations during the transition and for customers to transition at their
own speed).    Some of these have been more painful than others, but the end
result was better than hacking new features into an old design they didn't fit
into.

> I understand you might not have the answers to these questions; but surely 
> someone inside of Sun Microsystems knows!

Yes, and Stephen and Bart have explained it quite a bit - if everything they've
said and written about their investigations of the options and the requirements
they gathered from the various major enterprise customers they talked to hasn't
convinced you, my third-hand repeating of what they said isn't going to help.

-- 
        -Alan Coopersmith-           alan.coopersm...@sun.com
         Sun Microsystems, Inc. - X Window System Engineering

_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Reply via email to