[OmniOS-discuss] Questions about - End the uncertainty -

[Guenther Alka]

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 at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20170707/db69318c/attachment.html>