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

[Jim Klimov]

On July 7, 2017 7:21:37 AM GMT+02:00, Tobias Oetiker <tobi at oetiker.ch> wrote:
>Hi Aurélien
>
>the motivation behind OmniOSce is that we have come to love the the
>stability and
>tight focus of OmniOS. Many of us are running large servers that form
>critical pieces of our infrastructure. Loosing OmniOS was simply not an
>option for us. Since OmniTI gave up on this we were forced start doing
>the work on our own.
>
>for now our focus is in building on Dan's excellent work, both in
>updating r022 as well as pulling in new stuff from both upstream
>illumos and joyents lx work.
>
>we are happy for anyone to join us in our effort, for example also in
>providing a more end user focussed repo that goes along with omnios,
>providing a desktop environment for those who want to use the os in
>that capacity.
>
>www.omniosce.org
>gitter.im/omniosorg/Lobby
>
>Tobias Oetiker
>
>> On 7 Jul 2017, at 01:47, Aurélien Larcher
><aurelien.larcher at gmail.com> wrote:
>> 
>> 
>> 
>>> Gea,
>>> 
>>> the king is dead, long live the king
>>> 
>>> https://gitter.im/omniosorg/Lobby
>>> 
>>> www.omniosce.org
>>> 
>>> the story continues ...
>> 
>> It is good news, but I would engage you to discuss about reducing the
>fragmentation in the illumos community.
>> We have a few distros maintained by 1-3 guys without any or much
>momentum and much duplication of efforts (Debian has 1000+ devs working
>together and we are barely able to have more than 10).
>> 
>> We should join our efforts like, as I suggested, basing on common
>tools and userland.
>> I do not see how wasting energy in duplicate efforts will help us
>keep/gain momentum.
>> I mentioned earlier the possibility of a virtuous circle with OI as
>the rolling testing and OmniOS the stable: to be honest I see very
>little sense in maintaining two "testing" with such a small manpower.
>In the long term this does not seem sustainable.
>> 
>> At least some degree of collaboration should be maintained on
>documentation, pkg(5) and updates of Python/Perl/GCC with the same
>source repository.
>> 
>> Of course this is not "right now", as you need to maintain
>continuity, but we should plan the next 6 month cycle to decide on
>common requirements and make it happen.
>> I saw Peter has built illumos-omnios on Tribblix, I think we should
>do the same on OpenIndiana: the issue is not about doing it once (I did
>it last year) but having a person commited to maintain it.
>> 
>> Convergence is necessary, at least to some extent, discussion is
>open. :)
>> 
>> Kind regards
>> 
>> Aurélien
>>  
>>> 
>>> cheers
>>> tobi
>>> 
>>> ----- On Jul 5, 2017, at 4:05 PM, Guenther Alka <alka at hfg-gmuend.de>
>wrote:
>>> about OmniOS and the silence for weeks
>>> 
>>> For my own future, I have already decided to switch back to
>OpenIndiana, the community based sister project of OmniOS. But like
>many users, I have yet OmniOS installations running perfectly. For
>them, it is essential to ask about the future for the next months or
>year and needed next steps (can wait some time or switch as soon as
>possible).
>>> 
>>> 
>>> @OmniTi
>>> The end of OmniOS at OmniTi seems final. 
>>> 
>>> - How long will the website and the repo remain online?
>>> 
>>> - Is there an option to fix serious bugs or problems in OmniOS
>@OmniTi for 
>>> a limited time like 1 year or at least end of the year?
>>> 
>>> - Are you willing to transfer the website/name either to a new
>OmniOS community project (I cannot see this as an option regarding the
>silence about) or to the OpenIndiana community to use it as a name for
>a possible stable like OpenIndiana Hipster=dev and OpenIndiana OmniOS
>as a stable subset? (if OI is willing to go that route but the request
>or offer must come from OmniTi or OmniOS people). 
>>> 
>>> OmniOS has a very strong reputation regarding production quality and
>stability, so such a step would help both if OpenIndiana and OmniOS
>would cooperate in a common project. Seems a pity if the name would die
>or remain as a name for a failed project.
>>> 
>>> 
>>> @OmniOS developers (current or former - you have done a very good
>job!)
>>> 
>>> - Is there an option to fix serious bugs or problems in OmniOS for a
>limited time like 1 year or at least end of the year? This would help
>until a sucessor (less likely OmniOS 151024, maybe next OpenIndiana
>snap with a stable subset) is available. LX would then remain an OmniOS
>option in the meantime (I would not dare to ask about an upstream).
>>> 
>>> 
>>> 
>>> @all
>>> comments?
>>> 
>>> 
>>> 
>>> Gea
>>> @napp-it.org
>>> 
>>> _______________________________________________
>>> OmniOS-discuss mailing list
>>> OmniOS-discuss at lists.omniti.com
>>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>>> 
>>> -- 
>>> Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten,
>Switzerland
>>> www.oetiker.ch tobi at oetiker.ch +41 62 775 9902
>>> 
>>> _______________________________________________
>>> OmniOS-discuss mailing list
>>> OmniOS-discuss at lists.omniti.com
>>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>>> 
>> 
>> 
>> 
>> -- 
>> ---
>> Praise the Caffeine embeddings

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