[OpenIndiana-discuss] Merging OI + OmniOS? (And OpenZFS vs ZFS)

[Joshua M. Clulow]

On Wed, 30 Dec 2020 at 13:00, Peter Tribble <peter.tribble at gmail.com> wrote:
> On Wed, Dec 30, 2020 at 11:39 AM Kalle Anka via openindiana-discuss <
> openindiana-discuss at openindiana.org> wrote:
> > A question. I am sure this has been discussed before, but maybe it is time
> > to update the discussion? :)
> > As I have understood it, OmniOS is a robust server OS with no good desktop
> > environment. It is possible to install X11, though:
> > https://geekblood.wordpress.com/2017/10/26/installing-x11-and-a-desktop-environment-on-omnios/
> > Would it be possible to merge OI and OmniOS? Say, try to transform OI into
> > a desktop environment ontop OmniOS? Both OSes share lot of common ground,
> > so technically it would not be impossible to for instance port MATE to
> > OmniOS?
> > OpenSolarish is a bit fragmented as of now. There are several developers
> > working on their own stuff, with different IPS repos, etc. If we could
> > unite some of the work, OpenSolarish would benefit as a whole.
> >
>
> Not necessarily. And that's the problem.
>
> Fundamentally, it's very easy if all you have to do is maintain a
> single-purpose
> distribution and have total control of everything that goes in and out.
>
> Once you try and build a general-purpose distribution, you need some way to
> coordinate
> between different groups working with different cadences and trying to
> produce different
> products for different types of user. That generates friction and conflict,
> and requires
> additional manpower (aka waste, in lean terminology).
>
> The reality is that there isn't a huge amount of duplicate work - distros
> can pick and choose
> whatever they want/need from others *as they see fit* and *to their own
> timescales*.

In some places we do have duplicate work, and I think that's the best
place to focus first on adjusting processes.  One example where we
have hopefully improved things a bit is GCC, where there's a common
repository for all illumos projects:

    https://github.com/illumos/gcc

And a plan for maintaining it:

    https://github.com/illumos/ipd/blob/master/ipd/0007/README.md

I think we could and should do similar things for other heavy lift
software that has a constant upgrade cycle; e.g., Python, Java, etc.
I've been speaking with some folks from OmniOS about a new process for
updating ksh93 so that we can all benefit, and sendmail has seen
similar attention in the past.  I know the OmniOS folks are pretty
much on top of Python and Java releases in their distribution, and I
expect OI could adopt some of the work they're doing there (e.g.,
version and patch selection, build steps) without a great deal of
additional testing beyond what is already done by the OmniOS folks.

There is a lot of software for the desktop use case that OI supports
that isn't likely to get shipped on OmniOS systems any time soon, but
that's OK.  What we should focus on is reducing the effort to keep the
common software up-to-date just once, where possible, without
requiring everybody to agree on what makes our distributions unique.

I am happy to help anybody who wants to get a common repository
started under the illumos organisation, and also to offer suggestions
for what might go into a plan for updating it where I can (like the
GCC IPD).


Cheers.

-- 
Joshua M. Clulow
http://blog.sysmgr.org