John:
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.
I definately agree that going down path 1 or 2A where possible is
the right choice. However, I believe that there will be some issues
where 2B is simply the right choice. ksh is a good example since I
think getting somebody inside Sun or outside to write a free version
of ksh88 would be a waste of time. Though, as you suggest, this issue
could go away if all such components are eventually freed up and
added to OpenSolaris.
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".
I think it is just a matter of time before we find a necessary
component that isn't in OpenSolaris that we can't include for
licensing reasons, and something nobody is interested in rewriting.
When that time comes, it will be necessary to more look at SunOS6
as a solution.
I guess I'm looking at this differently. It seems to make more sense
to say that all components that are placed into OpenSolaris must follow
minor release changes. However, new components to replace ones that
Sun cannot put into OpenSolaris could be ABI incompatible. Why does
it have to be a big deal if Sun rips out those pieces and replaces
them with our favorite ABI compatible versions when we build/ship
Solaris?
My guess is that people will start using OpenSolaris and find that
they like the new features (like ksh93 instead of ksh88) and that
customers will push us to make a SunOS6 release because they will
want a more modern operating system.
<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.
Yes, I think this is exactly what I am suggesting. A new layer
that is a part of OpenSolaris and sits on top of ON. A layer that
makes OpenSolaris something that is usable.
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?
Yes, it would be better. However, I think it is a matter of time
before we find one that isn't practical to deal with. In fact,
I'd bet there is nobody at Sun rushing to write a free version of
ksh88.
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.
An operating system without ksh is a less usable stack. Do OpenSolaris
users have to twiddle their fingers or use a 2nd order fork until someone
gets around to writing a free ksh88. It makes more sense to use an
OpenSolaris layer that fills the gaps. This layer could include ksh93
initially and if a free ksh88 shows up later, we can replace it with
the more compatible version of ksh. Right?
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"
This is a good point. Some pieces will get placed there, so there is
some value in taking reasonable time to make sure that good decisions are
being made. However, I think it's likely that we will find some
needed pieces that won't get into OpenSolaris and Sun won't want to
resouce making sure it gets put 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.
Yes, perhaps you are right. If so, I guess I'm wrong. So is Sun planning
to write a free version of ksh88 anytime soon?
Is the lack of ksh88 and manpages and other things really a sign that
OpenSolaris isn't really going to be a usable operating system until
the far future?
Brian
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
