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.<p>Doesn't even have to like Windows or OS X. Perhaps something like Material Design would be a good starting point.<p>Dare I say that a refined, well-polished UI for Linux would provide a great face and mainstream credibility to adopting Open Source computing.
Has there been a Release Candidate milestone this cycle?<p>Wiki says there should have been, [1] but there isn't any on the servers. [2]<p>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?<p>[1] <a href="https://wiki.ubuntu.com/VividVervet/ReleaseSchedule" rel="nofollow">https://wiki.ubuntu.com/VividVervet/ReleaseSchedule</a><p>[2] <a href="http://cdimage.ubuntu.com/ubuntu/releases/15.04/" rel="nofollow">http://cdimage.ubuntu.com/ubuntu/releases/15.04/</a> <a href="http://cdimage.ubuntu.com/lubuntu/releases/15.04/" rel="nofollow">http://cdimage.ubuntu.com/lubuntu/releases/15.04/</a> <a href="http://cdimage.ubuntu.com/xubuntu/releases/15.04/" rel="nofollow">http://cdimage.ubuntu.com/xubuntu/releases/15.04/</a>
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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>Disclosure - I run flockport.com that provides ready to deploy LXC containers.<p>[1]<a href="https://linuxcontainers.org" rel="nofollow">https://linuxcontainers.org</a>
> builds on Ubuntu’s LXC project, which also forms the basis of Docker and its container technology.<p>Erm. LXC is userspace interfaces to kernel features.<p>Libcontainer is also userspace interfaces to kernel features.<p>The docker guys are the primary libcontainer developers. Docker no longer uses LXC by default.<p>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.
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.<p>A full orchestration solution where its basically:<p>docker pull $image; docker run $image $nodeID<p>$nodeID = nodeID or can be left blank to assign to a random node based on current load.<p>Then update a cluster stats/dashboard page.<p>Even then, its basically just trying to compete with things like CoreOS, Docker's orchestration stuff its working on, Kubernetes, etc.