But except where there are substantial architectural defects, I think we
have been running with a (in some cases greatly) reduced bar for FOSS
software.
There are bits of software that have integrated that simply defy logic
as far as how well they "fit" architecturally with any sort of vision.
IMO, GNU Pth serves every bit as an important niche as some of the other
"alternative" libraries. For example, we don't make SSL and crypto
consumers use our native encryption framework -- even though there are
non-trivial architectural concerns surrounding the use of OpenSSL. The
justification here being that its better to allow 3rd party application
portability than to stand firm on any vision of architectural
correctness. I think there are others as well. (After all, we
integrate flex and bison, while we have our own lex and yacc, and the
same can be said to be true of most of /usr/gnu.)
I guess this goes to the whole "familiarity" argument. There is a
boundary somewhere -- 3rd party libraries that suffer from terrible
architectural concerns don't integrate easily (libstdc++ for example),
and sometimes not at all. Is "performance" or "scalability" a terrible
architectural consideration? I'm not convinced it is -- especially in
the face of counter examples like OpenSSL.
-- Garrett
James Carlson wrote:
> Wyllys Ingersoll wrote:
>
>> It is unreasonable to burden
>> the teams that want to bring FOSS code to Solaris to also put in additional
>> effort to fully "Solaris-ize" the code in question.
>>
>
> If the ARC adopts that position, I think that'll be a substantial change
> in direction. The stated policy up to this point was that "free
> software isn't free from cost," and that part of the burden of
> integrating into [Open]Solaris itself is that the software and/or
> documentation and/or packaging may well need to be modified in order to
> be compatible with the system. Doing this might mean engaging the
> upstream community, or applying diffs, or forking the source, or perhaps
> some combination of those approaches.
>
> I'd thought that this understanding is exactly what the whole "kitchen
> sink" scheme for random FOSS integration was based on.
>
> Has this changed?
>
>
>> If integrating into ON,
>> then the argument is stronger, but for SFW packages ideally we like
>> to just drop in the tarballs from the upstream community and apply a
>> minimal amount of changes to get it to compile and work.
>>
>
> That's a darned shame. Compiling things and tossing them over the wall
> is fine for a "contrib" repository or something like the old /opt/sfw
> "Companion CD," but I don't see how it makes any sense for integrated
> software.
>
> Moreover, I don't see how consolidation matters here. Consolidations
> set build and integration rules, but from the user's point of view, it
> matters not whether "SUNWfoobar" was originally integrated via ON or
> some other consolidation. They're all the same to a user. Thus, the
> same quality had better be present, or the quality of the result will
> actually reflect the weakest part of the chain.
>
> If compile-without-changes is the intended new direction, why not just
> switch to Linux? It'll be way easier, and will have essentially similar
> results.
>
>
