Hello Jim and @all
I am using OmniOS and OI for years and I fully agree with you. Your
position and that of Aurélian and Tobi are not identical but not too far
away and may be the base to find a solution for a win-win situation for
all that suits the needs and wants of all.
In the current lifecycle, no question; we need a continuation of OmniOS
151022 and OI in their current state as there are many users around. But
then it seems increditable stupid if the next OmniOS and OpenIndiana are
based on a whole different base, distribution, infrastructure or
promotion and this discussion really offers some new oportunities due
the "revival" on OmniOS-ce side.
I am not involved in either OS distribution so you may correct me on
wrong statements but as I see:
*OmniOS and OI Hipster Text are nearly identical in core functions and
stability as this is inherited from Illumos*
OI is quite vanilla Illumos while OmniOS is based on a copy as a freeze
or subset of Vanilla Illumos with LX as addon?
If this is right, the more valuable part is the OmniOS clone when it
comes to LX, continuation and stablity. Using OI current as common base
would require to create a new stable clone and work to integrate LX,
much more work to do and we have this aleady done in OmniOS. Adding the
current OI featureset seems possible on top of Vanilla Ilumos and OmniOS
Illumos.
*Is this possible or an option?*
*What is the stance of OI to use OmniOS-Illumos as source instead of
Vanilla Illumos?*
This will give both the current stable base where common work is done
while OI has the option to add the full set of its current add-ons via a
repository, not to forget that for me a GUI for local filemanagement and
storagemanagement is a very valuable add-on for a server. Both are using
in such a scenario one stable core stable/lts repository every 6 months
like currently - similar or smaller than the current OmniOS and adds
extra functionalities by an extended repository that adds an enhanced
featureset.
The rest is simple
*OI is an established distribution with a small but working team to
maintain and build a distribution, a known name and website, **a wiki,
download and repo mirrors etc, a common project should be based upon
using OpenIndiana as common roof? The difference may be only in
OI-Hipster (general use server or desktop) vs OI-OmniOS_ce (minimal
stable storage server) with two distributions Text (OI-OmniOS_ce and a
base repo) and GUI (OI Hipster, the same but with GUI and other services
due an additional enhanced repo)*
No need to duplicate work. Even if both sides are requested to
compromise, both wins.
All current and new manpower can be used to make the common project
better or extend it for more use cases.
Maybe a switch to the OI installer is desirable as it offers a network
setting option on initial setup.
The OmniOS installer is annoying regarding this
comments?
Gea
@napp-it.org
Hello all,
I posted my opinion and advice in the lobby, but just in case the mailing list
has more visibility so far, would like to repeat or expand a few points here.
Especially as I tinker with both OpenIndiana and OmniOS based systems so can
hopefully see how to bridge some gaps and benefit from commonalities.
First of all - kudos and best of luck in your effort. Indeed, keeping existing
systems afloat and up-to-date is an important priority, and there are quite a
few interesting and important technical issues to take care of even if the
workflow and system structure stays as unchanged as possible.
Also, the well-earned perception of OmniOS releases as a dependable, feature-full and unbloated OS, both for use
"as is" and as a foundation for further value-added products that some teams work on, is also valuable to
keep and uphold. Unfortunately, as seen from these recent discussions too, this stance sort of robs away most of the
same values, unjustly, from OpenIndiana (we mean rolling Hipster, not old stale "dev"). Kind of childish
"we are good, so others must be worse or outright bad" and kind of misinformed "we know little of that,
so it must be unworthy of attention" or that it is a bloated desktop distro vs. minimal server one.
These two general-purpose distros share more than what they differ in, compared
to say SmartOS or Delphix or Nexenta who chose to excel in particular
directions and sort of neglect or forbid others (e.g. installation of random
software on a filer, making it also a big-data processing machine or a
standalone home firewall, dev rig, webserver and downloader of stuff). For my
part, I don't want to keep choosing which of the two distros to base my next
rig on, given they are almost the same except this tiny bit here or there...
In fact, OI never was 'just a desktop distro' of arguable stability. The "dev"
version is dead-stable ;) while the current focus of activity, OI Hipster, is very
comparable to OmniOS Bloody - just a lot more active, with dozens of PRs monthly from
several contributors to update packages following upstream releases and CVEs. Still, not
many enough to even get started tackling some goals.
OI is a general purpose set, usable both headless with small footprint, and
with GUIs out of the box, depending on which set of packages (pre-selected as
incorporations or manually picked) you install into a BE. Granted, it does have
a lot more packages than omnios in main repo - bit no-one forces you to install
them all at once ;)
The os/net in particular builds on vanilla illumos-gate I guess on purpose - to
have no more and no less than the codebase which passed the RTI process. And
because there's not enough manpower to dedicate to picking bits and staying on
top of bugs, on a daily basis. So it's as stable as it gets, and as soon as
that lands.
If someone commits to maintaining a stable and up-to-date fork like omnios-gate
(which needs to be done even if the teams do stay apart), I don't think there
would be much opposition to serving those osnet packages as part of OI instead
of vanilla illumos-gate. Perhaps it might be possible to use pkg(5) features
like facets or variants to provide a vanilla (oi) or patched (oo) os/net
packages in same repo...
When there's breakage in OI, that's usually after GUI libs and pkgs upgrades;
the 'server-only' SW is less interwoven. It is also quite stable that people
entrust their production services to it and can carelessly update at will -
especially if they do only care for (and install) the server-oriented subset of
packages. Of course, corner cases can happen on any platform, but they are not
the norm :)
I guess the issue of manpower also applies to amount of releases (namely - just
the bloody one). Keeping up a stable release (or several) with hotfixes and
little turbulence feature-wise, until a scheduled another one comes out, is
also quite an effort, and a mindset for people involved... That's again where
cooperation of OpenIndiana and OmniOS teams can be fruitful. Someone to pioneer
the hordes of changes... and someone to cherry-pick the good ones as stable.
If the projects were to unite efforts - or further pose as different facets of
the same effort with same underlying technologies, the 'omnios server' set of
packages is IMHO just a matter of defining an incorporation that depends on
said packages. Which may be close to what OI minimal/text already are (at least
assuming that actual third-party software versions are close enough).
Of course, even if the projects and teams do choose to converge, it ain't a
single-day effort. Some packages are bound to be named differently, some
default settings or OS accounts can differ... the unfortunate difference in
naming and behavior of linked and non-linked zones would bite us, the osnet
mentioned above... But at least we might avoid the duplicate effort of updating
third-party packages like bind, openssl et al as their cve's come into
spotlight ;)
Regarding approaches to building userland, I think it is even a lot more a
question about the 'engine' to build userland than about the particular
components' recipes (desktop or not). And about the convenience to use and
change and share those recipes (and the engine too). OmniOS approach with small
core and BYOSW for everything else encourages repetition of effort for every
user. The OI approach allows one to build particular packages locally (e.g.
with custom settings or patches) using a clone of the common recipe repo, and
install them from local pkgrepo as a preferred source, keeping the ability to
pull updates from common upstream and have ypur local Jenkins build them
automatically. Finally it is easy to share back recipes for components that are
not there yet (or your updates to recipes) - and get PR feedback from
additional eyeballs - and switch your IPS packaging back to use the component
from common repos and get updates as *other* people keep improving it. I'd say
oi-userland is more welcoming to cooperation and in particular to getting
started with - as more new people have shaved away the rough edges in common
docs and scripts in recent history.
So to answer one of the latest excellent questions in the lobby - "what is it, that OmniOSce
should be pulling/merging from OI to make it even cooler?" - I think it would be more about
sharing and cross-pollinating to erode the few differences until the inner workings are
indistinguishable :) It may be more about adopting some backend/distro-building procedures than
pulling this and that bit of code. Of course, about sharing the load over more people eager to be
active in the same area. Ultimately, reaping the fruits of an effort done anyway to update the same
pieces of code (such as updating and hot-fixing third-party packages), with this effort in OI being
perhaps more intensive and public than what OmniOS has seen as part of a "corporate"
effort. Possibly, it could bring benefits of an already established and automated procedure to
build and publish the updated userland in a way that may be more simple and scalable and shareable
than omnios's (though, this may be subjective until proven objective ;)). The coolness for OmniOSce
might be to have more sharing of work done anyway by people who want just the stable core and then
some (surprisingly same) BYO packages. The benefit for OI might be LX zones and growing a stable
release. Ultimately, people from both projects would gain to do less of the same with the limited
amount of man-hours we have in both communities, and free up resources to do more of different and
new and exciting.
Jim Klimov
--
Typos courtesy of K-9 Mail on my Redmi Android
_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
