[oi-dev] illumos based OpenIndiana DVD

Garrett D'Amore garrett at nexenta.com
Tue Feb 22 17:57:24 UTC 2011

On Tue, 2011-02-22 at 18:41 +0100, Joerg Schilling wrote:
> "Garrett D'Amore" <garrett at nexenta.com> wrote:
> > I think in general, the idea of swapping back and forth between
> > different versions of ONNV is not going to work out so well.
> >
> > There are challenges related to dependencies between ON (or
> > illumos-gate) and the rest of the system, and having multiple moving
> > targets is going to be impractical for end-users or even distribution
> > builders to work with.
> >
> > My read of Schillix-ON is that you want to build a different
> > distribution, with a different core (based on SVR4 as well it seems), so
> > you can tune your distro for the decisions you make around your fork of
> > ON.
> Schillix-ON deliveres SVR4 packages (98% ready) as well as 
> IPS packages. This permits any downstream to use the code.
> > While that's fine, I am not sure it is fair to ask either end-users or
> > distribution builders to cope with the notion of "swapping" a different
> > ON derivative out given the rather insane dependency graph that is
> > associated with ON.
> I am in hope that it is possible to discuss the issues and to agree on the same 
> naming scheme. 

The issues go far beyond just simple naming.  For example, we have
totally different g11n locale packages in illumos-gate now.  Our libc is
quite different now because of all the changes I made to support
localization, and the l10n data files have a totally different format.

That's just one example.

Going forward, I expect we'll have some interesting ZFS features as well
which may introduce on-disk format changes.  (These are being worked on
with a larger group of ZFS engineers that extend far beyond just illumos
-- people working on ZFS in MacOS, FreeBSD, and Linux for example).

There's a lot of collaboration going on.  Sadly, you've elected not to
be a party to any of this -- and from what I can tell it is for the
simple reason that we're not driving forward with integrating "star"
into illumos.  I guess its easier for you to fork the entire operating
system than to accept that "star" might not be accepted for integration.

Anyway, the upshot of all these changes is that it will be increasingly
difficult for a distribution maintainer to manage the increasing
divergence in the forks.  We already have that problem with upstream
OpenSolaris -- and its only going to get worse.  Adding another degree
of freedom would only significantly complicate the problem, and IMO
without much benefit to the distribution builders or the maintainers.

It would be more practical (from their standpoint) to ask them whether
they should choose a different upstream kernel to standardize on than
illumos.  Of course, I have a vested interest in seeing illumos succeed,
and I believe that there is a lot more momentum behind illumos than
Schillix-ON -- but the OpenIndiana guys are free to elect differently.

	- Garrett

More information about the oi-dev mailing list