Ubuntu 14.04 LTS: the cloud platform of choice
insights.ubuntu.com
insights.ubuntu.com
IMHO Ubuntu gets a free ride because every distro except Ubuntu has to set up an external CI server in order to get their drivers and changes in.
By head count, Red Hat is 10 times the size of Canonical. This means that Canonical would not be expected to show in the graphs you linked to, given the same level of activity averaged per employee. Yet Ubuntu is the distro of choice for OpenStack. That speaks to the strength of the community around OpenStack on Ubuntu, the skill and commitment of the people working on it, and the quality of the experience.
As to the grumble about spinning up an external CI server: you'll be glad to know that Ubuntu is really easy to spin up on bare metal or in VMs, and you don't have to buy licenses ;)
Disclaimer: I work for Canonical, so I am totally biased. I don't work on OpenStack, but I know many of those who do.
From rwmj's comment that "every distro except Ubuntu has to set up an external CI server in order to get their drivers and changes in" I gathered that Ubuntu was the distro of choice for CI, so that's what I should have written: for CI. I didn't mean to say that Ubuntu is the OpenStack project's preferred choice for deployment.
Having said that for many of our servers we use debian stable, because stability trumps latest-and-greatest.
Debian doesn't quite offer the same level of guarantee for how long each release will be supported for as far as I am aware.
Packages originate from the package authors; these people are not particularly tied to any linux distro. Ubuntu tends to stay close to the most recent version of packages(via apt-get update && apt-get upgrade), Debian purposely lags behind for stability reasons.
Probably one of the most notable examples of this is rtorrent(http://libtorrent.rakshasa.no/) for the longest time didn't support magnet-links; at least not for people who could only do apt-get upgrade. But going to the site itself and getting the src you could compile the newest version and get magnet-link support. Ubuntu , Debian, Fedora, etc. have nothing to do with what the rtorrent developers release on their website.
Another example, GIMP somehow is _still_ not 2.8 for all linux distros package-managers(at least my Linux Mint doesn't get it as of this writing) , but clearly http://www.gimp.org/downloads/ GIMP is on 2.8. The devs behind GIMP don't care what the distros do, they just write their code and release it.
For basic apt-get Ubuntu starts by merging with debian for each release: https://wiki.ubuntu.com/UbuntuDevelopment/ReleaseProcess#Mer...
Magnet links have been supported since rtorrent 0.8.9 which was release in June 2011. It was available for debian sid in September 2011 and is currently available in wheezy backports even. It was available for Ubuntu in April 2012 (possibly October 2011.)
GIMP 2.8 has been available for Debian since May 2012 if you run sid (or backport from sid). Debian stable since May 2013. Ubuntu since October 2012. Not sure where Mint gets it sources from.
These seem like reasonable delays in getting the package made available for testing.
It sounds like (?) Debian has tried to put those days behind it. But sysadmins of a certain vintage will always remember when Debian allowed itself to languish. Ubuntu, meanwhile, has maintained a very good track record with regard to timely updates and keeping LTS packages patched, etc.
With the other major distributions moving towards systemd and eventually wayland (that includes the base of Ubuntu: Debian), I'm not sure I really want to move onto 14.04 and continue this cycle further and risk it on Mir, Upstart, Unity and various other Canonical worldview items.
I'm considering ignoring this release and moving to CentOS 7 when it hits the ground.
In my experience of Linux distros, Fedora, Suse, Manjaro, Chakra, Mageia, PCLinuxOS, all the Linux derivatives like Zorin / Elementary / Mint / Bodhi, Crunchbang, etc all do the exact same thing and do it right:
Boot ISO, get live desktop, have a launchable guided installer. There are only a few such installers, a lot of distros reuse them (but some still duplicate the work needlessly) and they all perform relatively the same.
The outliers are your Arches, your non-live Debians (the default iso isn't live, for example) and your Gentoos, where you don't get a live desktop and have to do the routine manually.
> one that looks decent (e.g. fonts)
I've been installing Suse 12.3 and 13.1 a lot recently because I find a lot of users like Yast, and I think they have gotten their fonts pretty well in order. They used to be the poster child for bad font rendering, too.
Assuming that you're not a toolkit (or further down the stack) developer, can you explain why Mir affects you?
What other "Canonical worldview items" affect you?
systemd - glad to hear that. Missed that one.
Mir affects me because of the inevitable safety in numbers that going with the majority display server technology. Graphical stacks are terribly complicated and terribly involving for hardware manufacturers. Canonical are pretty much on their own with it and it takes a hell of a lot of people to keep the plates spinning on this. hell they can't even get X, DRM, GLX etc stable after all these years and thousands of eyes.
Other canonical worldview items:
Unity. Sorry but this doesn't actually work properly. Various applications have focus problems still after years of it, it's unstable, inconsistent, breaks apps (menus for example) and has incredible usability problems. I know you can use gnome but it's not a priority support item for Canonical so various things don't work consistently.
Launchpad. Launchpad is a total pile both from a tracking and management perspective. It's basically a baron land of neglect.
Probably more that I've forgotten.
> Unity
So don't use it. Ubuntu is more than just priority support items from Canonical. I'm using Xubuntu right now - it works great.
> Launchpad is a total pile both from a tracking and management perspective. It's basically a baron land of neglect.
As opposed to...Bugzilla? Again: surely you're joking?
I want stability. In fact I need stability and there's nothing more stable than a boring corporate desktop so...
CentOS 6.x's Gnome desktop despite being considerably older is an order of magnitude more stable, works flawlessly on every bit of kit I've tested it on and doesn't fall over on minor patches or kernel releases. I lost count of the number of times I've had power management and display regressions on 12.04 LTS. The only reason I ended up with LTS is because the NetworkManager VPN stuff that I need on my laptop is tied into later versions of NetworkManager which aren't supported on CentOS at the moment. I will say that they don't actually work on 14.04 either and I have to resort to manually adding a route because NM doesn't handle default routes properly.
On my personal laptop (Lenovo T400) I binned Ubuntu and actually run Windows now because the PM regressions were unbearable and the battery life was shitty even with 30 minutes pissing around with powertop.
Yes comparing to bugzilla. People haven't managed to displace bugzilla for a good reason: it works pretty damn well on massive projects.
You can see this in how they focus their work. Ubuntu, while it's contributed much to the ecosystem, has focused quite a bit of those contributions to ease of use and graphical stack items. These are important, but less so to workstations (of a particular breed) and servers. Red Hat has focused on stability and management. Need a full virtualization stack? RHEL has developed a stack they are pushing as competition for VMWare. Want directory services? It's an officially supported component with documentation (as of at least 4-5 years ago). Want a bug tracker with lots of info on exactly what's going on and what to expect? Use Bugzilla. It's overkill for most user-facing projects, but for IT staff who may be expected to file a fair number of bugs over time, after you've invested some time to learn it, it's great.
Ubuntu is a great OS/distro, but I don't think they've reached the same level in the server space as RHEL yet. Similarly, I wouldn't necessarily push RHEL/CentOS for desktops for home users or most businesses needing Linux on the desktop, unless there was a need for a much more controlled environment, and the long time between versions is not an issue.
To quote myself...
It's not really logical to judge whether or not something has improved over the last 2 years if you're willfully avoiding most of the changes made in the last 2 years.
RHEL7 isn't out yet, what server distros can you run in production today that use systemd?
Whilst on the subject of world view, how is cloud-init working out? This is a Ubuntu technology that has become a defacto standard for ALL cloud images initialisation handling across every OS (incl. Windows!). With worldview like this, keep it up.
If you don't specifically want software that is available on 14.04 but not 12.04, and you are replacing the machine next year, I'm not sure why you'd bother doing an upgrade.
I upgrade when it stops being convenient to get current versions of the desktop applications I want as backports ( VLC or Gimp for instance).
The only major glitch I had was hitting this bug where external debs (like Chrome, Dropbox, etc.) won't install in software center: https://bugs.launchpad.net/ubuntu/+source/software-center/+b... Luckily they just fixed it, so the official release shouldn't have issues.
"Why?" you might ask. Well, TBH, a lot of it is just familiarity - I've been using RH based distros since the Red Hat 5.2 days, so it's what I know already. But more to the point, it just works. I haven't felt any pain using Fedora, CentOS and their ilk, that has ever compelled me to go looking for a different solution. And that's even more true for servers, where I don't care about prepackaged video codecs or sound or anything.
The one big thing that everyone has always touted as the edge that Debian/Ubuntu have over RH systems, is apt. But after having used Ubuntu for 2 years now, I still haven't found any regard in which is apt is particularly better than yum. Yeah, yum used to be dog slow, but that hasn't been a problem in ages. And I don't know about you, but it still annoys me that I need one command, yum, to both search for packages and install them on CentOS/RHEL/Fedora, but I need apt-cache and apt-get to do the same thing on Ubuntu.
Anyway, props to the Ubuntu folks for the release. I do lean towards Red Hat derived distros, but I won't say that Ubuntu is bad or anything.
apt 1.0 in Ubuntu now contains an `apt` binary, which means this is finally fixed! See also: http://mvogt.wordpress.com/2014/04/04/apt-1-0/
My employer used RHEL on its servers (via a managed hosting service) for about a year, and it left a bad taste in my mouth, especially because RHEL5 was still on Python 2.4, and I needed a newer Python for some things. Sure, I was able to install a newer Python in /opt/python2.5 and move on. But when we left the managed hosting service and it was time for me to choose the OS for our next servers, I went with Ubuntu, because I knew it would have newer software, including (by then) Python 2.6. Another factor, to be sure, is that I've been using Debian and Ubuntu sporadically since Debian 1.1 or 1.2 in 1996. So Ubuntu was quite comfortable for me. The same factors probably figure in other admins' decisions too.
No argument from me about yum versus apt; they both do the job. Actually, these days I think that Debian (and by extension Ubuntu) overreaches in some ways, with Debconf and automatic startup of services after installation, whereas the Red Hat distros leave configuration and service startup after initial installation to the admin. So there's no clear winner; they're just different.
Personally I'd rather they just leave a lot of this stuff to PPAs and external repos.
http://vagabond.github.io/rants/2013/06/21/z_packagers-dont-...
and its follow-up:
http://vagabond.github.io/rants/2013/06/21/zz_packaging-and-...
The Docker package in Ubuntu trusty (which comes from Debian testing/unstable) is certainly more Debianized than the official package provided by the Docker team. Whereas the official Docker binary is statically linked (and the build process has to go through some contortions to make this work), the Debian/Ubuntu build is dynamically linked. Consequently, the Debian/Ubuntu build has to run a separate "dockerinit" binary inside containers, whereas the official build uses a single binary on both sides. Naturally the official build is tested much more extensively, so I'd recommend using that.
In comparison to AWS: The best thing in OS for me is the very flexible network configuration where you can define exactly what your environment looks like. The worst is lack of customised authorization / access control. Unless you need any specific part of AWS integrated into your environment, OS should give you most of the things you need. You can also mix&match services (just watch out where the internal data rates no longer apply).
In fact, all communication is done via web API's and there is even a compatibility API that speaks AWS. So if you have scripts that work with AWS, they will most likely work on OpenStack as well.
OpenStack is different in that not only can you choose an OpenStack provider, such as Rackspace, HP and others, but you can also run your own instance of OpenStack. All the software is released under the BSD 2 license. It can be a little tricky to get setup, but there are some projects out there to help get a working environment setup, DevStack in particular is very easy to use: http://devstack.org/
In terms of jumping in and getting started, AWS can be daunting, but it's not really that difficult to spin up an instance. OpenStack requires you to provision hardware and install a lot of different services, and architect how you want those services to be configured. It's not all that easy to get going (even with Juju, RDO, devstack, etc.). Both have a confusing array of names, so it's not always clear what part is what (ec2 vs nova, iam vs keystone, s3 vs swift/glance, ebs vs cinder, etc.), and not everything is fleshed out yet with OpenStack. I guess you could call it a work in progress. Actually, you could probably say the same with AWS, but it's much more mature.
OpenStack's biggest selling points at this point are that it's ultimately cheaper (in terms of opex) running your own cloud if you're at any kind of scale, but AWS saves you a lot up front (in terms of capex). OpenStack doesn't lock you in to a particular vendor and you can swap out parts like the hypervisor if you decide you want ESX or Xen over KVM. Unless you're using spot instances on EC2, AWS can be a lot more expensive (it would take only a few months to pay off a server if you're paying On Demand prices).
That said, I appreciate how much the OS has improved since I first gave "Breezy Badger" a spin a few years ago, and Ubuntu is the obvious choice when I recommend an alternative OS to my non-tech savvy acquaintances.
I'm talking about having all the sysadmin jobs in my area using Linux as a synonym for Red Hat Linux.
It's the only standardization that you're going to get in enterprise Linux and it's no different than targeting Windows.
> I'm talking about having all the sysadmin jobs in my area using Linux as a synonym for Red Hat Linux.
And the problem with that is?
Silly me? I know. And still I don't like it.
Maybe I am still too young. :)
"Global enterprises including AT&T, Bharti, Bouygues Telecom, British Telecom, China Telecom, China Unicom, Cogent Communications, Comcast, Deutsche Telekom, Korea Telecom, NEC, NTT, Numergy, Orange France, Time Warner Cable, Turk Telecom, Verizon and Yandex, as well as leading web scale services such as Netflix, Instagram, Hipchat and Quora are all building next generation services on Ubuntu"
It's hard to tell from these lists how seriously a lot of those companies are relying on Ubuntu. Obviously some are (HP for example). But I've seen my own employers listed in press releases where us implementors were wondering "do we really still use that stuff? Oh yeah I think there may be a box or two still running that from when we were testing the waters."
RHEL/CentOS aren't popular for the lack of alternatives, but more because that's what most sysadmins are used to use.
Forget this idea of a company that produces yet another fucking distro with just enough changes so its not 100% compatible with whatever it's forked from, and then charge for support.
How about a company that simply sells support services for an existing, community owned distro like Debian. If it makes sense for that company to donate to the Debian project, and/or hire staff to contribute to Debian packages to improve them, thats great too.
In the early 2000s, HP had committed to supporting Debian, but I no longer see it listed on their Linux Support page.
I know the european market has a healthy ecosystem of consultant companies that provide support for open source products.
My point was more that this is the type of thing people/companies should be looking for in a Linux support contract, rather than another "services" company rolling it's own Linux distro so they can lock customers in with incompatibility.
personally i'd rather benefit from solid pkg management with updates and bits available for free (as opposed to only paid subscriptions) and with wide availability of the same cloud images across cloud platforms (published by the distro themselves).
sometimes opinions are good and beneficial, and become widely adopted because its just a better way of doing things ergo, ubuntu cloudinit for declarative userdata based initialization of cloud instances, has promulgated far and wide across other distros and operating systems.
I've switched to Debian Stable for all of my stuff. Life is too short to be beta-testing for Fedora/Ubuntu for free. RHEL/Centos/Scientific is another reasonable choice.
It left me wondering if Redhat's contributions to the security community give it a leg up. Any "cloud platform of choice" needs to be a first tier security platform. The Heartbleed bug shows that it may not be.
Ubuntu patch on April 7 at 22:01 https://lists.ubuntu.com/archives/ubuntu-security-announce/2...
Red Hat patch on April 8 at 03:21 https://www.redhat.com/archives/rhsa-announce/2014-April/msg...
the ubuntu pkg security update for openssl/heartbleed was available the same day of the public announcement, without the benefit of prior notification (unlike redhat who had prior notice and released their fix a day after the public announcement).
The Heartbleed disclosure was kind of botched, but in general things go more smoothly, with all the major distros being informed ahead of time and having time to prepare patches. For example, see the Xen privilege escalation vulnerability in 2012, and the PostgreSQL remote execution vulnerability in 2013. In both cases, Ubuntu was informed ahead of time and had updates ready to roll when the vulnerability was publicly disclosed.