Illumos Sporks OpenSolaris

suraj.sun sends in this news from The Register. "If you were hoping that someone would fork the OpenSolaris operating system, you are going to have to settle for a spork. You know, half spoon and half fork. That, in essence, is what the Illumos, an alternative open source project to continue development on the core bits of OpenSolaris, is all about. ... Development on OpenSolaris has all but stopped, so Garrett D'Amore, a former Sun and Oracle software engineer who worked on Solaris for many years, decided to do something about it. ... What Illumos is doing is taking the core OpenSolaris kernel and foundation, which is called OS/Net or ON inside of the former Sun, and creating a repository and development community around that. ON includes the kernel, C libraries, shell and shell utilities, file systems, and networking functions of OpenSolaris. 'We are not a distribution in a normal sense,' says D'Amore. 'It is more of a code base.' And one that Nexenta, Belenix, and SchilliX, who do create alternative distros for OpenSolaris, can in theory base their future releases upon if they don't like what is — or isn't — coming out of OpenSolaris."

Comments

Re:Is it worth the effort?

[captrb]

Zones, ZFS, and DTrace don't have equivalents in Linux with feature parity.

Re:Missing sources?

[gstoddart]

Didn't the OpenSolaris effort have problems because they were always waiting on Sun to compile certain libc binaries for them?

Is this resolved in Illumos or is there still a binary blob issue?

Apparently, it isn't. From TFA ...

The biggest problem is that an important minority of the code distributed with OpenSolaris is closed source, something that has annoyed the OpenSolaris community for five years. Sun didn't allocate resources to fix this and neither has Oracle.

D'Amore says that a significant percentage of the libc C library (libc_i18n to be precise) is closed, as is the NFS lock manager, portions of the kernel's cryptographic framework and functions, and a bunch of important drives.

So, no, the closed stuff still needs to be written and they don't have it.

Re:Is it worth the effort?

[berashith]

one kernel shared amongst the zones, not VMs populated with independent OSes. The zones can "loopback" filesystems, so /usr is only created once . Each zone has independent configs for users and such, and is visible as files from the global OS. VMs dont have a global OS, they just sit on a hypervisor.

this is the first 5 seconds of differences. The biggest thing to note is they are nothing alike.

Re:Is it worth the effort?

[Massacrifice]

explain to me and people like me how "Zones" are different from "virtual machines?"

Zones share the same kernel. Much, much less overhead than full-blown VMs, both in setup and resource use. You can flavor your zones to be Linux or BSD compatible. You can give them their own (virtual or physical) network adapters. Think Apache Virtual Hosts, but at the OS layer. Or a midaway cross between a chroot and a VM. It's really nice stuff.

Re:Is it worth the effort?

[nathanh]

Unless I am confused, "Zones" are virtual machines. If you think there is no equivalent, I guess you are not familiar with Xen or KVM, or the dozens of other VMs out there.

Yes, you are confused, which probably indicates your lack of familiarity with Solaris Zones.

Xen, KVM, VMware, Sun Logical Domains, and Sun Virtualbox, are all examples of hardware virtualisation. They simulate a hardware platform; a virtual machine. Each VM has its own kernel and scheduler and memory space and device drivers and virtualised storage.

Solaris Zones is an example of operating system virtualisation. There is no direct equivalent on Linux. There is a single kernel for all the zones. A single set of device drivers. A single process tree. Potentially a single storage system. It's extremely lightweight compared to virtual machines.

Thinking of Zones as "virtual machines" is simply wrong. They are more like process groups, or process sets, and in fact on Solaris they are implemented in part by using resource groups. There is virtualisation but it's not at the machine layer; that's why they're not virtual machines.

To illustrate the significant differences, on the same hardware that Xen can run 10 VMs, Solaris can run 100s of zones. Xen can lose 10% or more CPU to overheads, Solaris Zones loses less than 1%. Xen can lose as much as 90% of I/O performance, Solaris Zones loses less than 1%. Xen places restrictions on the resources available to each VM, Solaris Zones can gain access to the full resources of the hardware. Xen requires each VM to be patched and maintained separately, Solaris Zones are patched and maintained through the "host" OS.

These benefits are only possible because Solaris Zones are not VMs.

Re:Is it worth the effort?

[nathanh]

OpenVZ and FreeBSD Jails are equivalent conceptually to Solaris Containers. The difference is the extent to which they've been implemented. Sun went the whole hog and made Solaris Containers "first class citizens". All the user space tools were modified to understand zones. All the documentation was updated. All the application suites were updated. They're not a ill-supported second-rate tack-on so you can tick the "we've got that" feature box.

If you want the analogy, it's like Microsoft saying "don't use Apache, we've got a webserver too" and pointing to IIS. In theory, true. In practise, bullshit.

Re:Missing sources?

[anilg]

(I'm in the project leadership team of Illumos)

We've opened the closed bits of libc - specifically the i18n portion of it.

What's still closed (and soon to be opened) is some additional drivers (mpt, etc) that are almost prepared to be released. All of the closed bits would be open in a short timeframe (weeks).

What you've quoted Garrett saying is in reference to OpenSolaris's code. That is followed by the announcement that we've opened it.

~Anil

Re:Is There A Sufficient Community/Demand?

[anilg]

The most important bit (libc_i18n) is opened. The rest is in the process, and will be pushed into the repo in very short time.