On Jan 24, 2007, at 9:33 PM, Joseph Kowalski wrote:
> That said, I tend to think that export discussions aside, the root
> concern here is code duplication. That may or may not fit your
> definition of architecture, but it certainly fits mine of good
> engineering practice at a systems level.
If we were talking about a single integrated operating system owned
and supported by one company, I would agree with you. The problem
I most often face with Solaris is not duplicate code, but needing to
install replacement code in order to fix bugs or missing features
that, for whatever reason, won't be fixed in Solaris. This is where
the value proposition of a GNU overlay makes sense.
My objection was to the suggestion that an overlay of third-party
code should be required to use a given Solaris implementation library
prior to integration. In my opinion, that requirement contradicts the
premise for creating the case, and it simply isn't reasonable to state
that overlays of third-party code must reuse Solaris code. The purpose
of the overlay is to allow use of a given cross-platform code base.
If the suggestion was "this code is insecure" or "this code needs to
exclude command XX because it does not adhere to the required audit
logging mechanisms", then I could understand them as architectural
concerns related to a higher-level systems requirement.
Personally, I would prefer an entire prefix tree be created
under /usr/gnu such that an invocation of
./configure --prefix=/usr/gnu
/usr/gnu/make install
would be sufficient to install any updates to those tools (and
the many other co-dependent utilities produced by the FSF).
I don't see the need for anything gnuish to be installed in /usr/bin,
and making them separate would allow the interface "stability" to
be expressed in the same way for the entire toolset. I wouldn't
put all "freeware" or "linuxish" or "OSS" or other software in the
same place -- just the specific set of GNU utilities that are intended
to work together as a common environment, libraries, man pages, etc.
> The trouble is that maintainers often tend to only concentrate on
> what benefits their little corner of the world. Part of PSARC's
> job, architecture or not, is to concentrate on the big picture.
I honestly think you are missing the big picture. From my perspective
(even with my CAB hat on), Solaris is the little corner of the world.
The reason for moving towards open collaboration is so that the
people making the big pictures have a chance to influence our
particular style of canvas, and thus make it more useful for them
before they inform their customers what platforms will be supported.
As a developer, I really don't care where these tools are provided
as long as it is possible to find them on the path and, once found,
the tools are exactly as distributed by the tool author. I can deal
with the complexity of a version check to determine how to adapt my
configuration in order to use that version of the tool. What I can't
deal with is a tool that claims to be one implementation but actually
contains platform-specific changes due to someone else's opinion on
the appropriate interface. If I wanted such an implementation,
I would not be looking for the GNU toolset. In general, I only use
the GNU tools when I am building on an unknown platform or when
I know the operating system's native implementation is borked.
....Roy
