The single largest contributor by the metrics you posted. There are other types of contribution, integration and distribution for example, things that Ubuntu has traditionally focused on instead of raw upstream work.
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.
What do you mean when you say Ubuntu is the distro of choice? Looking at openstack's install docs, they list install guides for Debian, SUSEs, Red Hats, and then Ubuntu (in that order). Is there some place on the openstack site that indicates a preference toward Ubuntu?
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.
We use virtual servers and all of them run different releases of ubuntu and for the life of me I don't understand why they're not running debian. You never start an X session on a server and what admin would want to use Unity anyway so what's the point in using Ubuntu rather than stable debian?
When Ubuntu came out with LTS releases, that's what did Debian in, in my experience. Numerous compliance regimes require supported OS versions, and having a guarantee of long-term support for a version means you're not forced to upgrade the entire OS every year or two, and reduces the cost of using that particular OS.
There was a period, including the time Ubuntu launched and got popular, that Debian was infamously slow to update stable. Along came Ubuntu with a clockwork-like release cycle (every six months IIRC) and up-to-date packages, even in LTS. (In fact the Ubuntu elevator pitch, as far as I was concerned ~10 years ago, was "Debian packaging but with regular releases.")
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.
Debian's release cycle still isn't as predictable as Ubuntu; in fact, Debian slipped a bit with wheezy. Whereas lenny and squeeze came out in February of 2009 and 2011 respectively, wheezy didn't come out until May of 2013. I appreciate that Debian took the time to get it right; still, Ubuntu's greater predictability is appealing. Also, Ubuntu offers official backports of newer kernels to LTS releases; that's why Docker, for example, can target Ubuntu Precise.
ubuntu's release cycle is quite different from debian. If you want more recent versions software, but with firmer guarantees concerning support than testing or unstable, ubuntu is a good choice.
Having said that for many of our servers we use debian stable, because stability trumps latest-and-greatest.
For me the advantage of Ubuntu over Debian is that I know that each LTS release of Ubuntu will be supported for exactly 5 years. That means that at the time of deployment I can already anticipate when I will need to upgrade / retire that specific server.
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.
Support contracts. Mostly CYA, but the fact that there's some company out there that can be paid to be "responsible" for any issues and provide companies with a scapegoat is worth something.
I've tended towards Ubuntu over Debian because I've found Ubuntu historically to be more likely to run a recent version of the packages I use (Python, PIL, python-mysql etc). Might not be so true these days now that Python 2.x development has more or less finished.
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.
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.
On the desktop you bet, it beats Windows for me. On the server, check the other comments, LTS and the ability to run newer stuff but still be very stable. I really don't see why you're having an issue, Ubuntu Server is plain and works well.
Really don't know what to do about 14.04 landing. I maintain a few systems which are in devops territory on top of Ubuntu 12.04 LTS, a single desktop machine and a laptop. 12.04 is EOL in 2017 and we plan to replace them next year (we operate a 3 year standard cycle).
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.
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.
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.
I think what you are seeing is the ancestry of these projects coming to the fore. Ubuntu is, to my eyes, first and foremost a desktop OS that is trying to make inroads into the server OS space (replace OS with distro if if helps helps lower your pedanti-meter). RHEL/CentOS have always been very server/workstation based (and I do consider a workstation different than a desktop).
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.
Do you realize your opinions _appear_ to be based on something that is 2 years old?
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.
But systemd isn't going to be in 14.04. Like bananas, over the next year we'll be moving our production servers off of 12.04. Whatever we switch to will be in production for 3-4 years. So we have to ask ourselves, do we want to be stuck with upstart for another 3-4 years?
There are tons of production servers and laptops using upstart. It will take a while for Debian and Ubuntu to migrate to systemd so you're probably overthinking it.
RHEL7 isn't out yet, what server distros can you run in production today that use systemd?
Not to mention... 'worldview' was OK, when RHEL6 was shipped with defaulting to upstart.. But then later NIH'ing to systemd? .. Even if Ubuntu hadn't committed to switching, suggesting that Upstart is anything other than a stellar contribution to FOSS is BS.
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.
The Mir change wasn't made in 14.04, so if you update from 12.04 to 14.04, you will be using unity, X11, and Upstart, much as you are now.
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).
I also have concerns about this sort of thing. On the other hand as far as I can tell Ubuntu is still the easiest, fastest way to get a Desktop environment up and running on a new machine, one that looks decent (e.g. fonts) and one that plays nicely with hardware.
"plays nicely with hardware" isn't really an Ubuntu thing. Hell, some distributions like Manjaro and Mint play better with hardware by including proprietary graphics drivers on the disk if your system can't boot on Mesa. Ubuntu doesn't have that.
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.
Shuttleworth has announced Ubuntu will be moving to systemd. 14.04 is also the first version to have a Ubuntu GNOME spin if you want that. KDE/Xfce/etc are also easily available. That leaves Mir as the real potential difference going forward.
I ran Arch on my laptop for a couple years until switching to Ubuntu Server 14.04 a couple months ago. It more closely matches my dev servers taht run 12.04, and using i3 I hardly notice a difference day to day.
I installed the 14.04 LTS beta on a laptop to kick the tires last week. Overall it seems really nice. I was happy to see GCC 4.8 is the default compiler.
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.
Whose choice? Not mine... not that I have anything in particular against Ubuntu (in fact, I'm on an Ubuntu system as I write this, because it's our corporate standard desktop here), but I still prefer Red Hat based distros, whether it's RHEL, CentOS, Fedora or what-have-you?
"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.
I think a big reason why Ubuntu is so popular for cloud deployments is that Canonical provides official Ubuntu images for Amazon EC2. Last time I checked, CentOS didn't. Red Hat does, but of course, you'll pay extra to run official RHEL, so that probably makes it less attractive to a lot of companies. Basically, Ubuntu is the path of least resistance on EC2.
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.
I suppose it was a good PR move, but I wish Ubuntu hadn't added Docker to an official repository (albeit the universe one) yet, since Docker hasn't hit 1.0. Especially since Ubuntu is packaging it under the name "docker.io", whereas the official package is called "lxc-docker". Seems bound do generate confusion.
The package name really shouldn't be lxc-docker anymore. Since v0.9, the default execution is libcontainer and not LXC. In later versions, LXC is likely to be deprioritized.
I'm ambivalent about distro package repos versus official packages or PPAs. On the one hand, having all the packages one needs in one place can be quite convenient. On the other hand, Debian (and by extension Ubuntu) has rather strong views about how the whole system should fit together, which it imposes on its packages. So the way a piece of software is packaged in Debian and Ubuntu can be quite different from what the upstream developers intended. I'm reminded of this blog post that a Riak developer wrote last year:
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.
It is not worse than AWS, but it is different. OpenStack is a collection of python programs that abstracts the physical hardware, such as cpu's, networking, storage and combines them to form a single interface over the top of the bare metal. Essentially you can turn many machines into an easy to use environment that looks like AWS.
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/
It really depends on what you're trying to do, as one is a product and the other is a service.
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).
It's not worse, it's not better. It's got very different approach to many things. It also depends who deploys it and with which features/services enabled. Rackspace is different than HP cloud is different than ...
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).
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 found the buzzword-laden marketing-speak quite annoying, but we (hackers) are probably not the intended audience. This is probably written for a non-technical decision maker who wouldn't understand anything written at a much lower level of abstraction.
I really hope we get a contender for the linux servers space. Maybe it will be Canonical, maybe not, but having Red Hat/CentOS everywhere (in new deployments at least) is starting to tire me.
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.
It's quite likely there are companies providing the type of thing Im talking about already - I haven't really looked.
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.
not sure which distro is dominant on scaled projects but Ubuntu gets plenty of use on large projects too - from the article:
"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"
"Article" is one word for it, a more specific phrase would be "press release".
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."
As far as I have seen it's actually dominant in general. The only stats I found[1] say it is totally dominant in EC2 deployments (55% of the total with second place with 24% being a generic "linux").
RedHat has carved out a huge chunk of the in between space. RedHat sells to people who buy support contracts. Some guy running a personal email server doesn't have the money and the likes of Netflix doesn't need it because they have the expertise in-house. You see a lot of RedHat in corporate IT departments.
Having (or better, limiting yourself to) a single vendor is not standardization at all, in my opinion.
I'm not talking about having a single vendor in a single company at a certain point in time - that's good, doing differently is hard to manage (since usually the sysadmin team is really too small).
I'm talking about having all the sysadmin jobs in my area using Linux as a synonym for Red Hat Linux.
I hope that's not the only standardization we will get, since I don't really like vendor lock-ins (talking about Windows...) and I think we need something better than that.
Take a look at SuSE. They're ridiculously quiet, but I gather from their employees that they are pretty much lazer-focused on serving business needs and thus are doing well as a company.
yeah.. we should all use a distro based on something unopinionated.. like systemd ;-)
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.
How about a distro that moves carefully, making an effort to not use their users as test subjects?
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.
Until now I agreed and have used Ubuntu for several years. I was however taken by surprise by how out of the mainstream Ubuntu seemed to security folks when Heartbleed was being identified and it's fix promulgated. https://news.ycombinator.com/item?id=7592244
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.
That timeline shows that Red Hat knew about Heartbleed exactly 14 minutes before the other distros did. Hardly sounds like a "leg up" to me.
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.
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).
It isn't clear to me whether "which OpenSSL forwarded to Red Hat and others" includes Canonical or not. It is clear that Red Hat was included by that statement, but what makes you think that this is a bias in who received a direct notification, as opposed to a bias of the author of this particular article?
I don't get what you're saying. From a cursory reading of your link, I don't see anything Ubuntu did wrong, it just seems that things moved very quickly with the disclosure. Am I missing something?
I'm saying that Ubuntu needs be contributing more to OS security and that those who do contribute naturally have better information on security issues.
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.
[1] http://activity.openstack.org/dash/releases/