Ubuntu 15.04 Launches with Support for OpenStack Kilo, New LXD Hypervisor | Hacker News Reader

Ubuntu 15.04 Launches with Support for OpenStack Kilo, New LXD Hypervisor

techcrunch.com

129 pointsggonweb45 comments

I'm curious if there's any effort underway to refine Ubuntu's desktop UI. It's a great distro for my needs, but am always underwhelmed by the UI and how large all the buttons and elements are, plus it's use of earth tone color schemes. I feel it could do a much better job using a screen's real estate.

Doesn't even have to like Windows or OS X. Perhaps something like Material Design would be a good starting point.

Dare I say that a refined, well-polished UI for Linux would provide a great face and mainstream credibility to adopting Open Source computing.

Sure, it's called Kubuntu: http://www.kubuntu.org/ ;)

I would say Xubuntu. But.. I just tried the 15.04 and it's visually less polished than previous ones, presumably due to Xfce 4.12 defaults. It also seemed more sluggish (perhaps a strong word for the experience). It was certainly perceptible. I'm at odds, Xfce was my 'go to'. Any recommendations? Perhaps a non-Unity Gnome.

I'm running Ubuntu 15.04 with GNOME Session Flashback: a sort of GNOME 2 for GTK3. It's Ubuntu how it used to be, but with the latest upstream features. I've been using it for about 2 months after I moved back from Arch. It's stable and fast, so everything I want from a desktop environment. However, as you point out, the UI is still quite big, even on mid-resolution displays (1600x900).

Will there ever be a desktop version of Ubuntu with snappy ? Snappy seems to have some very interesting advantages..

I have been saying that Linux traditional package management is out dated and needs to be re-invented.

Why do we need to share all the libraries? Shouldn't most of them be self contained? Can't we just intall into a directory and uninstall by removing a directory? Sounds a lot like containers to me but simpler and not virtual.

So maybe we can see a systemd packagemanagement system :) Just kidding but hmmmm.

Security updates and bloat are some reasons. If there is a serious bug in glibc a single OS update usually fixes it.

If you installed 20 applications with their own statically or privately stashed (but still dynamically linked) glibc versions, unless you have an agreement with the app author/vendor it will be hard to maintain updates.

This might not matter for consumer applications but in large environments (banks, DoD etc, this matters).

Not saying I agree or advocate that way is better and nothing should be changed, I am just presenting what the typical arguments are.

While I think it's FAR better than anything Windows or Mac have come out with (both are entirely closed to corporate approval with no alternative repositories), I would want to see more unification between distros in terms of package managers. Right now, only source files seem to be consistent, with different package managers requiring different dependencies for every package, despite large environments such as GNOME which provide a consistent experience on any distro. With divergent systems such as Ubuntu's PPAs this seems less likely, but I'm not very qualified to comment. Perhaps someone else knows more on the possibility of this? Are distros still too different under the rug?

> Are distros still too different under the rug?

Yes and no. You could probably make a packaging system that could handle multiple distros cleanly, but then the package maintainer would need to maintain said package on all of those distros.

And that's just third-party vendor packages. The real problem comes with people thinking that "these two distros both use [package standard] so I can take a system package only provided on one, and just install it on the other!"

The difference between the world of RPMs and the world of DEBs isn't really the package format standard; if that was the only problem, it would have been solved long ago. It's that, hiding behind RPM and DEB, there are two separate package dependency graphs shared by all the distros that make use of either. They don't have names, but effectively they're "the Debian dependency graph" and "the Fedora dependency graph."

All derivative OSes that keep packages updated from "upstream" (like e.g. Ubuntu does with Debian) are forced into the upstream's dependency graph. If Debian packages X.org split into three packages and makes everything graphical depend on one of them, then if Ubuntu wants to ship the "upstream" version of any of those graphical programs, it has to also ship the upstream version of X.org (or, at least, a virtual package that has the same name as the one of the three that those packages depend on, and hope that the package doesn't actually depend, implicitly, on any of X.org's own Debian-specific dependencies that thusly won't be getting installed.)

Which is all to say, if you want to unify package management, you're going to have to come up with one base set of packages everyone can agree to depend on. Or, at least, a graph of virtual packages that get fulfilled by different base packages on each OS.

Otherwise, for now, it's actually handy to see .rpm and .deb on packages—it tells you whether the contents of the package are built for your dependency graph, or for the other one.

You're kidding but they aren't: http://0pointer.net/blog/revisiting-how-we-put-together-linu...

xdg-app is similar but with less btrfs: https://wiki.gnome.org/Projects/SandboxedApps

1) I was kidding but I also thought this was possibly where some would want to take it. I personally would like to see something more Linux central and not systemd central.

2) I really like th idea of sandboxed apps. It was basically what I was saying except if there were some kind of git magic sauce in the middle of it that would be fantastic.

Unfortunately I am thinking in terms of Desktop Linux and not Corporate settings with servers. Though servers really are moving into containers.

Meh, library sharing is not the problem. LD can easily figure out what version of a lib the binary wants.

You don't need to go whole hog container to "fix" the issue. Look at distros like NixOS, Guix, or Gobolinux.

Can't we just intall into a directory and uninstall by removing a directory?

https://en.wikipedia.org/wiki/Klik_%28packaging_method%29

https://www.slax.org/en/documentation.php

More like an image, but close enough.

In the last paragraph of the article I don't see anything to indicate it won't be part of the desktop version.

This new version of Ubuntu is also the first one to offer a stable version of Canonical’s Snappy Ubuntu Core, the company’s stripped-down version of its operating system for container hosts and small connected devices. You can read more about Snappy in our earlier coverage here.

Has there been a Release Candidate milestone this cycle?

Wiki says there should have been, [1] but there isn't any on the servers. [2]

Or, maybe I should read '25 April 16th', 'ReleaseCandidate' on Ubuntu wiki [1] as "there will be a Release Candidate on the week number 25 (week meaning: seven-day period here) starting with April 16". That would mean the Ubuntu developers yet have two more days to release RC on schedule, and the final release should be expected on the week startng with April 23rd, up to April 29th; and TechCrunch just based their article off the line in the wiki, which they could not actually read and didn't bother to check the facts?

[1] https://wiki.ubuntu.com/VividVervet/ReleaseSchedule

[2] http://cdimage.ubuntu.com/ubuntu/releases/15.04/ http://cdimage.ubuntu.com/lubuntu/releases/15.04/ http://cdimage.ubuntu.com/xubuntu/releases/15.04/

Ubuntu Mate's forum[1] links to a QA page[2] which points to a download in the "daily-live" directory, rather than one that's listed as RC specifically. This might be due to recent emphasis on daily builds.

[1]: https://ubuntu-mate.community/t/ubuntu-mate-15-04-release-ca...

[2]: http://iso.qa.ubuntu.com/qatracker/milestones/338/builds

TC throwing around buzzwords they don't understand.. "hypervisor" has a specific meaning entirely unrelated to containers.

From http://www.ubuntu.com/cloud/tools/lxd:

> And it’s going to be a real hypervisor? > Yes. We’re working with silicon companies to ensure hardware-assisted security and isolation for these containers, just like virtual machines today. We’re working to ensure that the kernel security cross-section for individual containers can be tightened up for each specific workload. We’ll make sure you can live-migrate these containers from machine to machine. And we’re adding the ability to bind storage and network interfaces to the containers, just like virtual machines.

Maybe that's not the specific meaning that you had in mind, but they're definitely going beyond a plain old LXC container.

"Working with silicon companies to ensure hardware-assisted security" doesn't mean that much though. A MMU is already hardware-assisted security.

https://linuxcontainers.org/lxd/introduction/ says "unprivileged containers" as the leading security feature.

Googling for that, there's more info at https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-con...

What do you possibly gain by introducing VT-* features into your container product?

At the moment, the container host exposes any kernel vulnerability to the container guests; that's a large enough attack surface that the advice I've most frequently come across is "Run your customer's containers in a VM so they can't attack your host". That's obviously less than ideal, so if VT-* can add a layer of isolation such that I don't need a VM layer in the infrastructure, it's worth it.

So you're not longer sharing a kernel with the host?

The VM doesn't share a kernel with the host, no. Without knowing exactly what virtualisation knobs Canonical are planning on adding here, it's difficult to say how much isolation is on the table.

Isolation. uid 0 is treated specially, and root breakouts inside containers (especially containers which aren't constrained by the audit subsystem in some way, like grsec or selinux or apparmor) or kernel exploits can bust your whole system open, among other security risks with containers.

hypervisor breakouts exist, but they're much rarer.

I would imagine you would get better security and performance isolation

At the cost of whatever bugs/vulnerabilities exist in the VT-* implementation on the silicon

I disagree. A Hypervisor is a supervisor and part of the control plane for virtual machines. LXD is something which is trying to span the virtual machine world to containers.

Read Ubuntu's page about it here: http://www.ubuntu.com/cloud/tools/lxd

They're just repeating Canonical's messaging. http://www.ubuntu.com/cloud/tools/lxd "The new hypervisor isn’t a hypervisor" — that clears it right up.

Right. They're at exactly opposite ends of the spectrum, from what I understand: A container uses OS-level namespace techniques to allow different environments to run on the same kernel, whereas a hypervisor runs underneath the kernel to multiplex hardware such that multiple entirely unrelated OSes can run on the same computer at the same time.

To be fair, TC needs it's post titles to make sense to a general tech audience. I think going into the difference between containers and VMs in the title would be a bit of a challenge. What should it have said?

Ubuntu's splash page reads as though LXD is the Qubes/Bromium to LXC's Sandboxie, using some aspects of hardware virtualization for additional security.

The persistent misconception about containers on hackernews is unfortunate. The open source Linux container project (LXC) dates 2009, has been supported by Ubuntu since 2012, and has mainly been developed by Stephane Graber and Serge Hallyn. They have now developed LXD that builds on LXC.[1] It's far away from a 'me too' and to suggest so is an disservice to the folks working on the LXC project over the last 7 years. LXD uses unprivileged containers by default and is designed to support multiple hosts and live migration out of the box.

The LXC container project only matured with the 0.9/1.0 release around 2013, around the same time that Docker decided to use it as a base to develop a read only app container built with layers of aufs that LXC supported. Docker has not contributed to the LXC project or even attributed properly, it's website still refers to the LXC project as 'low level kernel capabilities' which in many ways is partly responsible for the widespread misconceptions about LXC in the docker ecosystem.

These 'low level kernel capabilities' are namespaces and cgroups that were mainly developed to support containers. The LXC project used these to provide userland containers along with container management tools and OS templates. This is what Docker used untill version 0.9 when it switched to its own libcontainer format to directly interface with kernel namespaces and cgroups. Referring to the LXC project as 'low level kernel capabilities' when it was as functional and in many ways easier to use than Docker is as inaccurate as referring to Docker as low level kernel capabilities.

Docker is a funded project and could take itself to market and gain adoption much more aggressively than the low key LXC project. This is something for open source projects to think about.

Immutability, idempotency and restricted single app containers made of read only layers are not the only way to use containers. They provide benefits for some use cases but also add complexity. It makes business sense to try to own the 'format' and there is an unfortunate tendency even for the technical minded to fail to consider not everyone needs these deployment centric addons, and disregard the complexity it adds.

For the average user used to VMs and complete OS environments, LXC containers are far easier, simpler and straightforward to use and offer a gentler transition. They behave more or less like your VMs, only more portable and lightweight. Immutability, idempotency or grappling with the complexity of single app containers of read only layers can be saved for later when and if the need arises.

Containers as a fast and lightweight alternative to virtualization with easy to use tools now across hosts with LXD and a wide choice of container OS templates seems to be an good option to have. Upstream features like unprivileged containers and live migrations is icing on the cake.

Disclosure - I run flockport.com that provides ready to deploy LXC containers.

[1]https://linuxcontainers.org

> builds on Ubuntu’s LXC project, which also forms the basis of Docker and its container technology.

Erm. LXC is userspace interfaces to kernel features.

Libcontainer is also userspace interfaces to kernel features.

The docker guys are the primary libcontainer developers. Docker no longer uses LXC by default.

I wouldn't consider it accurate to say LXC forms the basis of Docker's container technology, because you will never touch LXC if you use modern versions of docker.

If we're being pedantic, you're correct. But to a pretty good approximation you can refer to the kernel features of cgroups, namespaces, etc, as LXC, and people have been doing so for a very long time. It's only recent that there were other interfaces to this such as libcontainer, and don't forget that Docker originally used LXC and still supports an LXC driver.

TC throwing around buzzwords and a "meh" about a late to market idea that, while an interesting idea, would really require a level of automation I doubt this has.

A full orchestration solution where its basically:

docker pull $image; docker run $image $nodeID

$nodeID = nodeID or can be left blank to assign to a random node based on current load.

Then update a cluster stats/dashboard page.

Even then, its basically just trying to compete with things like CoreOS, Docker's orchestration stuff its working on, Kubernetes, etc.

What's wrong with competing with CoreOS and Docker's orchestration?

Nothing really, I just think it won't impress. None of the stuff Ubuntu has ended up "me-tooing" their own special version of has enjoyed wide adoption.

Edit: Since I get rate limited regularly [for some reason] I'm editing:

> It could mean that nothing copied by Ubuntu gets popular,

That is partially what I mean, Ubuntu's "special replacements" for existing systems rarely get adopted outside of Ubuntu/Ubuntu forks.

> it could mean that Ubuntu's copy never gets popular.

I think this is primarily what will happen because it offers nothing truly unique that won't be easily/rapidly copied.

> LXD is using OpenStack, which is the 800 lb. gorilla of orchestration solutions - almost literally (3M lines of Python!).

Yeah. And I can use that already.

Except Docker perhaps, which is a "me-too" originally based on LXC?

Ubuntu/Canonical didn't create Docker.

Fweespeech's comment is confusing. It could mean that nothing copied by Ubuntu gets popular, or it could mean that Ubuntu's copy never gets popular.

Ubuntu is a copy of debian that is quite popular.

Yes, but can you name another? Or shall I start listing off server software they've tried to make their own special version of and failed?

LXD is using OpenStack, which is the 800 lb. gorilla of orchestration solutions - almost literally (3M lines of Python!).

Docker's orchestration stuff is neat, but operating at a different feature/code-base scale, for better or worse.

There's a fair bit of overlap between what OpenStack/LXD does and Docker/Kubernetes or DCOS do. Both technology stacks have approached the problem from different directions.

Kubernetes is trying to be the standard for container orchestration and cluster federation for hybrid cloud environments but lacks mature storage provisioning and network isolation tools. Openstack has the virtualisation infrastructure box ticked but lacks the container orchestration story. Docker has the advantage that it is developer friendly and low friction and Openstack ( fairly or unfairly so) is perceived to be complex and unwieldy.

Personally, I think Open Stack/LXD is a dead-end and Ubuntu should take on Openstack/Mirano/Kubernetes while the Docker ecosystem matures. When Docker/Kubernetes storage/network tools have matured ditch OpenStack entirely.

Reply on news.ycombinator.com