IBM made a big announcement at LinuxCon Seattle of two LinuxONE mainframe machines. Canonical — one part of the Linux trinity (the others being SUSE and Red Hat) — had previously been missing from the mainframe, and this announcement brings Canonical’s Ubuntu into the club.

Mark Shuttleworth, the founder of Canonical and Ubuntu, told me in an interview at LinuxCon that those Ubuntu users who want mainframe can now have the same features that Ubuntu offers for other platforms. However, we won’t see Ubuntu for LinuxONE before 2016, when the next major release of Ubuntu LTS will be out.

Currently, both Red Hat and SUSE Linux run on LinuxONE with SUSE offering initial KVM support. So, why is there delay in Ubuntu’s arrival on mainframe? Because Ubuntu needs some work to be done in order to run well on the mainframe.

Dustin Kirkland, from Canonical’s Ubuntu Product and Strategy team, told me in a long interview at LinuxCon, “We are really steamrolling towards a GA release of Ubuntu on z Systems. Users of z Series systems are the types that buy hardware for 5 and 10 years and that lines up very well with our LTS of Ubuntu.” He also said they need to do some work on tool chain to ensure they have components like gclib libraries on all of the compilers, including other bits such as Perl, PHP, Ruby, Python, etc., which are needed to build the Ubuntu universe. Users will start seeing that work coming out later this year and alpha/beta builds of Ubuntu in early 2016.

Canonical is not doing the work on its own, however. Kirkland admitted, “We are working very closely with IBM; we couldn’t do without them. There is extensive use of Ubuntu in IBM and expertise is certainly there with Ubuntu. It’s a healthy platform to build on top of, we need considerable help from them on the kernel, on the tool chain, with their expertise around z Systems to make this partnership work.”

Become an Ubuntu Fan

Canonical is doing a lot of different things in the enterprise space, to solve different problems. One of the interesting works going on at Canonical is Fan networking. We all know that the world is running out of IPv4 addresses (or already has). The obvious solution to this problem is IPv6, but it’s not universally available. Kirkland said, “There are still places where IPv6 doesn’t exist — little places like Amazon web services where you end up finding lots of containers.” The problem multiplies as many instances in cloud need IP addresses. “Each of those instances can run hundreds of containers, each of those containers then needs to be addressable,” said Kirkland.

Many projects are trying to solve this problem in their own manner, with Flannel, for example. Canonical has found their own solution which they call Fan. Kirkland explained, “With Fan, each LXD host creates a fanned out network of IP addresses behind that host. So all of its containers draw an address from the Fan”.

He continued, “The interesting thing about containers is that as you start pulling containers in the production, those containers need to talk to other containers including the ones which are on the same network but not on the same host. And these containers need a way of knowing how to get to those containers. So, the Fan provides a very deterministic, algorithmic mapping of container addresses behind one host to container  to addresses on another host and it does that in a very clever way.”

Like many Canonical projects, Fan is also an open source component. It’s a feature of containers for Ubuntu. However, Kirkland stressed that “there is no reason why any other distribution or operating system such as Windows or Solaris can’t easily pick it up; it can be implemented on any OS doing a networking stack.”

Where Is Snappy?

Snappy has been the hot topic in Ubuntu land recently; however, Snappy is targeted at a different market — not at monster (in a positive sense) hardware like LinuxONE. Kirkland praised the IBM hardware and explained why Snappy doesn’t fit there, “With IBM LinuxONE, we are talking about physically the biggest machines in the world and computationally the most complex machines in the world and Snappy is designed for the other end of the spectrum where we see a lot of IoT (Internet of Things).”

Contrary to LinuxONE, IoT comprises tiny lean and mean devices with much lower computation power. That’s one area where Canonical is trying to gain a foothold, through Snappy and competing with giants like Google.

So, how different is Snappy Ubuntu from regular Ubuntu? There is no short answer. Kirkland said, “Snappy is the same Ubuntu, so binaries for Snappy — the kernel, all the utilities  — are binary equivalent, md5 to md5, to traditional Debian Ubuntu.”

Snappy, however, is constructed, glued, and put together in a way that is very different from Debian-based Ubuntu. Kirkland said, “In Debian-based Ubuntu, you have a read-write root file system; in Snappy it’s a very different world: the root filesystem itself is a read-only file system that is an image. We treat it like an image so when Snappy gets updated, we don’t download a bunch of internet packages, crack them open, install them and then run a script. Instead, when we update Snappy, we download one binary blog, look at the checksum; if it matches, we write it directly to the disk and then check the checksum what we wrote to the disk. If all of that works, then we reboot into that system. And if it works, then the next update will go to the other partition; if it doesn’t work, then it will automatically revert and reboot into the previous OS.”

It works more or less the way ChromeOS or other image-based systems work.

To Dock or Not to Dock

Canonical has been working on containers for a long time, but as CoreOS entered the ring, there emerged some conflict and issues around standards. Industry players, including Docker and CoreOS, came together to create the Open Container Project, hosted by The Linux Foundation to mitigate such issues.

When I talked to Kirkland about it, he said, “We are 100% supportive of Open Container Project (OCP). As I have read the charter, two things that OCP is trying to drive are consensus and completion. And we are happy to support both of those and the output.”

Kirkland further added that whatever container format the OCP decides on, they will support it. However, he also said that it’s not going to replace other container formats. Canonical will support all other formats and simply add the one that is decided on by the Open Container Project.