Brian Cameron wrote:
However, I see a lot of problems with the approaches that seem to be
evolving out of this discussion. For one thing, it seems that we
are suggesting that OpenSolaris should be bound to interface
stability issues for non-free interfaces found in Solaris. The ksh
example is a good one. How can OpenSolaris be made into a usable
operating system if the only way to "fill the gaps" is to create
what you are calling a "2nd order fork".
Whenever I ASS-U-ME, I get burnt :-)
My assumption about the set of "closed things in OpenSolaris"
is that, over time (short to medium?), they will all go away
This will happen
1) as they become "open" (i.e., Sun figures out how to expose
their sources) or
2) they will be reimplemented.
The reimplementation path has two forks
A) Compatible with the closed prototype
B) Incompatible...
In as much as we can follow Path 1 or 2A, the relationship between
Solaris and OpenSolaris is "easy". Obviously, this includes
the forwards compatibility with Solaris.Future as well as that
of Solaris.Historical and other OpenSolaris derivatives.
I would expect that Sun (and therefore Sun Employees) will be the
core drivers for these efforts. I would also expect Sun to
replace all the "must be closed" parts of Solaris with open
counterparts over time. i.e., open it up or get rid of it.
If we go down path 2B, we start to do violence to the core
value of compatibility. Lets try to not go there unless we have to.
I also ASSUME that the process of closing all the "closed" gaps
is a short term transition/startup problem, and that the things we do
and the processes we invent long term won't have to cope with it.
it is not
reasonable to expect that the Free Software community will spend
time re-implementing old interfaces just to have something like
ksh on the system.
Of course not - as above, IMHO that Sun should be the driver/doer.
It seems to make more sense to allow the OpenSolaris community
to add the reasonable free software replacement for such
components to OpenSolaris. Of course, it is reasonable to
expect that they will have to make stability promises and abide
by them to get them into OpenSolaris. Such bits should not need
to conform to non-free Solaris interfaces.
Then they should not usurp the namespaces used by those components.
It is only when they do that we head down path "2B".
This probably means that such new bits of OpenSolaris will eventually
become SunOS 6.
I'd rather not start off with that assumption; rather I want to
*attempt* to evolve compatibly until shown that that ideal is impractical.
We may end up with a SunOS6; the difference is the reasons for doing
the release: "we allowed chaos to define the system" -vs- "we did
all we could to maintain compatibility, and <here> is the exact
reason we couldn't do it".
<Change of perspective>
Are we all confusing the Consolidation called "ON" that lives
under the OpenSolaris banner with the whole set of potential
consolidations? Just because the ON consolidation is saddled with
compatibility issues with the closed stuff does not mean that
other (new) consolidations would be. i.e., there is no reason
that there couldn't be a consolidation created for new stuff
that layers on top of ON, and that consolidation could easily
set expectations that it will do frequent Major releases.
In other words, the interface breakages between SunOS 5.0 and 6.0
should only be those bits to "fill in the gaps" to make a
reasonable free operating system.
Wouldn't it be better to make the effort to fill those gaps in a
compatible way, thus eliminating the need to do a Major release?
At some point, migrating to 6.0 and having a more usable free
software stack will likely become the right decision.
I'm not sure where you get the impression that compatibility with
Solaris10 equals a less usable free software stack. You may be right,
but I'd rather have a specific proposal in front of me before I jump
to that conclusion.
I very much agree, but it seems just backwards to try and bind
OpenSolaris to Solaris constraints. Instead OpenSolaris should
be free to define its own constraints in areas where there is
no free alternative.
"It wasn't there on June 14th, so lets give up hope of it ever being
there"
Sorry, I'm not willing to let such a flimsy argument force us all into
a major release transition. I'm sure Sun would be willing to invest
quite a bit of resources to keep that scenario from happening.
Especially when the Solaris rules are buried in ARC cases which
are not yet visible to the OpenSolaris community. Refactoring
all ARC case information so it is usable by the OpenSolaris
community is probably not a reasonable task.
Nevertheless, it is one we are embarking on. Not refactoring,
but figuring out how to make it all available "as-is". We may not get
there "tomorrow", and the lawyers and HR folks will undoubtably have
their say, but hopefully we can get close.
Are we going to
expect the OpenSolaris community, for example, not to break
"contract private" interfaces between two Solaris modules?
Most "contracts" have a mechanism by which changes can be made.
It all boils down to communication. If they change "A", it will break
"B", so "B" will need to be fixed. Either by the people that changed
"A" or by the owners of "B". We *will* need to deal with it
somewhere. Ignoring it by pretending that the dependencies don't
exist is simply shortsighted.
Replacing one component with a free alternative may meet all
public/Stable interface requirements, but break things badly
on Solaris due to private contract interfaces that the
OpenSolaris community wouldn't even know about.
That is why we have ARC reviews.
If this means
Sun rips out ksh93 and puts back in ksh88, why should that
be a big deal?
As the number of divergences goes up, tracking them all will become
impossible. As they go up, the value of having a single "compatible
community" goes down. As I said, lets choose to not go there - at
least not as a high rate of speed with our eyes closed :-)
On a different topic, I can't believe that we didn't include
the manpages in OpenSolaris.
Because the process of seeding OpenSolaris has only *started*, and it
isn't *done* yet....
-John
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
