Regarding Illumos, alls firms work together to maintain these core features. SmartOS (Joyend/Samsung) or Delphix, OpenIndiana or OmniOS must not care about.
I think Gea sums it up best here, which I was not really thinking about when I mentioned SmartOS:
All of the OS devs are contributing to the Illumos codebase, which is upstream from all the variants (OmniOSCE, NexentaStor, OI, SmartOS). So there really shouldn't be an extreme variation in the core codebase - maybe in some of the packages that are available in their respective repositories, or features on which the variants focus, etc.
I think the question is really what your use-case is.
If you're looking for a storage server, the three basic choices are OI (adds graphical support), OmniOS (stable repos, SMB-targeted non-compelled commercial support), or NexentaStor (enterprise-targeted features+hypervisor integration, compelled commercial support).
I used to think SmartOS had something other variants didn't as they have the backing of Samsung, but they all contribute to the same Illumos codebase, so all the variants should benefit from the same dev hours (eventually).
This article really spells it out:
Oracle is Set to Kill Solaris. Here are the Alternatives to Solaris
I've been running OmniOS for at least 6 months now and I really couldn't be happier. Coming from Linux+FreeBSD, Solaris terminal behavior and different commands have been a little tricky to get used to, but ZFS features+behavior are quite palpably better which for my use-case eclipses any struggle I may have endured.
Quite honestly, I almost never spend time on it because after I got it working there hasn't been any problems.
liv3010m said:
I played a little with SmartOS and I enjoyed it. The thing that was not clear to me was that once you deployed a SmartOS branded zone, you couldn't update its "OS" anymore and if you wanted to go to a new SmartOS zone version you had to redeploy the zone, meaning you had to reinstall it internal software/packages too. Maybe I missed something...
I think you're right, looks like they're tied to the kernel+userspace they come with, as they're images:
LX Branded Zones
Maybe this would make migrating easier (?):
LXadm - an open source LX zones administration tool for illumos based distributions
hadfl/lxadm
Why not send them a /r/ message?
LXadm - an open source LX zones administration tool for Illumos based distributions : illumos
Note: In short, it looks like lxzones are somewhere between lxc containers (which are full-machine OS images like a virtual machine and work fine with OS updates) and docker/OCI/rkt/etc. images (which are OS -requirements to run specific software and are not meant for OS updates).
Edit: If you look at this list of datasets, there are some that are machine (base) images (for adding your own software) and some that already have the software packaged and running:
datasets.at
