David.Comay at Sun.COM wrote:
> Redirecting to arc-discuss as I believe that's the proper mailing list
> for these general threads (while bcc'ing psarc-ext.)
>
>>
>
> Although I personally believe Indiana is the basis of Solaris Next, it
> currently lacks a number of features which makes it unsuitable for
> certain users.
I'm very doubtful that this is the case. While technologies from
Indiana may be used for a Solaris Next (if we ever have such a release),
the very fact that we have no way to upgrade from Solaris 10 or Nevada
to Indiana, and the various other incompatibilities (many of which are
quite small, but taken together add up) make it seem unlikely that we
will be able to directly convert Indiana to e.g. Solaris 11.
> Until those gaps are addressed (and yes, going through
> architecture review is definitely one of those gaps to address), Nevada
> as a collection of consolidations (and it's manifestation, Solaris
> Express Community Edition) will continue to exist. As such, I would
> argue there is benefit to including many of these FOSS components given
> that the *intent* is work with the upstream community and properly
> maintain them over time.
I'm not sure that this intent is in place in all these cases. (Frankly,
the number of FOSS cases coming lately certainly calls into question our
*ability* if not our *intent*. Even if we could maintain all the
software we already have in ON today, plus all these new cases today, I
can't imagine that we will continue to be able to do so going forward.
Its just too much.)
While there is certainly benefit to including many of these FOSS
components, the fact that seems to be overlooked is that there is also a
*cost*. The challenge is figuring out which of the FOSS components have
a benefit > cost. (And, unfortuantely, the resources to account for the
sum of all "cost" across all packages are finite. So even a package
with a very high benefit might have trouble if it also comes with great
cost. Else why not ship KDE?)
What I'm interested in seeing, is getting to the point were we get
maximum benefit for least cost. To my mind, the best way to do that is
to reduce the cost. A reduced level of ARC coverage (and corresponding
communication of caveats to customers via docs) and integration in a
network repo rather than in the WOS, seems like a good way to drive the
cost to very nearly zero.
>
> What precisely are the architectural issues that these FOSS cases are
> causing to the current minor release under development? I know that
> among others are
>
> 1) Some (most?) of the FOSS components may not adhere to one or
> more of Big Rules or other policies that have traditionally
> covered components that are considered more "core".
>
> 2) Is there a duplication in functionality and does providing
> alternate implementations mean it becomes difficult or
> impossible to build a system architecture? An example of a
> potential case that I see as causing such a problem might be
> "Integrate initng into OpenSolaris" while I don't necessarily
> see that with "Integrate MyFTP into OpenSolaris" (and it seems
> so far most of the cases are of the latter variety.)
IMO, a better example would be why we don't have KDE and AfterStep and
FVWM and XFCE.... clearly those packages are useful to a large number
of people -- in some cases probably *far* more people would be thrilled
by the inclusion of KDE or XFCE than by e.g. unison or lftp. (In other
words, the feature gap of not having those DEs is probably far more
painful to a larger number of users.)
The thing is, with these smaller packages we seem to be avoiding making
these decisions, because taken individually the cost seems to be
"trivial", and we don't seem to have any "architectural vision" like we
do with Gnome.
The problem is, that these all add up. And the lack of architectural
vision, and the increased cost of introducing dozens or hundreds of
packages like unison and lftp, may ultimately exceed the cost of what it
would take to integrate e.g. KDE. And, possibly, at lower benefit than
e.g. KDE would bring.
So I guess that's part of my concern -- there seem to false economies at
work here. Getting to the point where we can make things available to
customers via a mechanism other the Solaris DVD (or SXCE download), with
possibly different "commitment" levels (not just architectural/interface
stability commitment, but also "support commitment") seems like it would
an extraordinarily useful way to make just about everyone happy.
>
> What are some of the other general architectural issues of concern?
>
> If there was no Indiana and instead the intent was that Solaris Next
> was going to continue to ship with a variation of its existing product
> structure (a WOS on perhaps Super-Blue-ray(TM) using LZMA2 compression)
> would these FOSS components be of no benefit and unsuitable for the
> release?
I don't know. The criteria used to evaluate software for integration
into Solaris-the-WOS was historically quite different from the criteria
that seems to apply to many of these recent FOSS packages.
I have my personal preferences, but I'm not sure that they fit with
where ever it is we-as-in-Solaris are headed. But then again, I'm not
sure I understand where it is that we are headed at all.
Its also the case that we live in the real world, and there is no
Super-Blue-Ray device, and download bandwidth for the master install
image used for Nevada is itself limited. Somewhere we will hit the
breaking point. Unfortunately, when we do it will already be too late.
>
> Is there no benefit to integrate these components with a set of
> commitment levels so that others (at Sun, ISVs, developers, OpenSolaris
> users) can use them under those stated levels unless said components
> are unique in functionality and completely integrated with all other
> aspects of the system?
"Integrate" is a difficult term here -- sticking it on an optional
download component (e.g. Extra Value CD/DVD, or in a network repository)
is very different than having it be part of the WOS image that everyone
downloads. Again, benefit versus cost. The benefits may be real, but
the costs are too.
-- Garrett
PS: I'm really not a KDE bigot -- don't even use it myself. The example
just seemed apropos.
