> Reasons were given. You're not arguing the technical details.

Perhaps he isn't, but I am.

> I'd characterize it differently. SVR4 packaging lets you run arbitrary
> code during pkg install, and the tools layered on top of SVR4 packaging
> created a plethora of contexts where said code must be able to run, and
> this creatd an unmanageable situation.

That's a red herring.  Or a strawman.  Or a slippery slope.  One of those, 
anyway (;-)

You are presupposing (embedding) the conclusion that this was an unmanageable 
solution.

But wait, who says that?  And on what exactly is that based?

All we needed in SVR4 packaging is automatic dependency resolution and the 
ability to
point it to a repository of packages, and have true package clusters instead of 
"metaclusters".
You know, like sgi, IBM and hp had for the past twenty years, or so, likely 
longer.

It is very, very wrong, in my experience, for a bunch of engineers, coding in 
an artificial
environment, far, far from the trenches of their customers, to be deciding what 
their
customers are and aren't allowed to do - by design!

I'd be interested to hear from the IPS development team, how many of you have 
actual
system engineering and sysadmin experience in customer environments?  That's 
all.
Thank you.

> I believe IPS + AI probably scales to the enterprise _now_. But I
> believe IPS is not ready for enterprise use in one sense: customers are
> not yet ready to use IPS packaging to do the things they are used to
> doing with SVR4, and we could make that transition easier. For example,
> a simple tool to create an SMF actuator from a developer-provided script
> would be nice. It's possible that there may yet be a use for my
> SVR4->IPS CAS/post* script migration tool.

Customers want to be able to *encapsulate* consistently repeatable software 
configuration
tasks associated with installing and running software, and meanwhile, the IPS 
development
team is attempting to prevent them from doing exactly that.

Some even claim that the software management (packaging) system is not for 
that. Well,
who exactly is in the position to actually decide that?  That's nothing but 
someone's definition.

Meanwhile, there are things that people need to do, and can't.  For instance, 
how can a package
installed from an install server, on a *running* diskless client, install the 
package on that
running system *and* start the newly installed SMF service *immediately*?

_________________________________________________________________
Show them the way! Add maps and directions to your party invites. 
http://www.microsoft.com/windows/windowslive/products/events.aspx
_______________________________________________
indiana-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss

Reply via email to