Liane Praza wrote:
> John Plocher wrote:
>> Garrett D'Amore wrote:
>>> does *not* belong in any default ***distribution*** of Solaris, but
>>> in some value add location
>>
>> I tend to agree.
>
> Ah, the value-add location like we had with /usr/sfw/gcc or value-add
> repository of /opt/sfw?
Maybe I misunderstood Garrett - I thought he was talking about a
repository location, not a $PATH location.
I agree with you (Liane) that $PATH is a blunt-but-maybe-unavoidable-
in-some-situations hammer that should NOT be applied to this type of
problem.
> Making software harder to get or harder to find isn't necessarily the
> right answer.
Nobody said anything about "harder", just "correctly identified".
Consider a repository where you can ask for a list of packages
that meet some criteria that is interesting to you, the user,
such as:
Package attributes that you wish to limit your search to:
[ ] $ Value add software that costs money
[ ] Security fixes
[ ] Sun supported and maintained components
[ ] 3rd party supported and maintained components
[ ] Open Source community supported and maintained components
[ ] System Utilities
[ ] Web stack stuff
[ ] Desktop applications
[ ] Laptop utilities and tools
[ ] Drivers
Done right, this lets the user/customer pick the pieces they
are comfortable using and informs them of the different expectations
that surround each choice.
The failure mode here is unexpectedly high warranty support costs.
If our customers get "caveat emptor" level stuff, but are under the
impression that it is "crown jewel" supported, they will demand
a level of support that we will be unable to cost effectively deliver.
> But I'm not even convinced the ARC should be in the
> business of deciding which software is 'bundled' in the distro, versus
> what's in an 'alternate' repository. (And having ARC banish it to
> another consolidation is equally bad -- consolidation boundaries should
> be able to be set based on development efficiencies.)
Consolidation boundries are a tension between things that belong together
and the overhead costs of managing a consolidation. SFW is a disaster;
it has become a dumping ground for random components that have nothing
at all to do with each other except for the fact that it is convenient
to let someone else manage the gate.
If we reinvented this whole area, possibly leveraging the CG and P
structure on OS.o, we might be able to create a blastwave style system
where the development costs are much lower...
> Shouldn't ARC just be in the business of reviewing a project team's
> definition of how stable and architecturally integrated an included
> piece of software is?
The architecture of a system is made up of BOTH the architecture of
the individual components AND the architecture of the integration.
Doing one without understanding the impact on the other is no longer
systems architecture.
> Heck, isn't that even true of OpenSolaris-specific software? Why should
> ARC spend much of its time second-guessing whether
Because, in the end, if we screw up here, we will find it harder and
costlier to build the next version of the system because the parts we
are building it out of diverge more and more and more. In a very
real sense, we do the ARC process simply so that we can continue being
able to build our systems, release after release. Any benefit to our
customers is (happily) incidental :-)
> We're getting to a world where creating distributions is much easier. I
> hope that ARC will spend its time classifying interfaces and components
> so that administrators, developers, users and distro builders alike can
> make educated decisions, rather than having ARC attempt to define the
> exact contents of a distribution.
+1 - how can the ARC and the Project teams capture the info needed so
that those distro builders and sysadmins can effectively benefit from
our efforts?
-John
