As a sysadmin I've used SLES, CentOS, and Ubuntu on my servers. As far as getting what I need to do done, Ubuntu wins every time. I have played with Debian on virtualbox vm's a bit, but it's never "just worked" for me.

Also, since I don't distribute any images, the IP issue does not effect me at all. So why exactly would this issue matter in regards to using Ubuntu on the server?

Agreed, used Ubuntu on servers since 10.04LTS and they've been absolutely spot on, zero complaints.

It's also the (ime) best supported server distro in terms of third party packages.

In addition the LTS versions work well with vagrant and spinning up a dev box from a bash script is trivial (it's a couple of hundred lines of bash script most of which is reusable across projects).

If we where a massive shop I'd probably look at CentOS but so far I've not had the need.

If I were hosting an app that wouldn't require upgrading to up to date versions of whatever language it runs on, and I didn't want to upgrade the OS for 10 years or so, I'd look at CentOS.

But with how rapidly PHP/Ruby/Python/Java/etc advance, I prefer an OS that mostly keeps up with their latest versions. And Ubuntu's PPA system makes that a lot easier if you can find a PPA you trust.

When I first started, my predecessor had been fighting with upgrading PHP so that we could run Drupal on CentOS... 'Course he was still on hardware blades, not VM's. So he couldn't easily switch OS's. I got to move everything to VM's, and that's when I switch everything over to Ubuntu. After figuring out that CentOS wasn't the direction I wanted to go.

They each have their strengths. If you're in Enterprise production, or scientific computing, you'll want RHEL or at least a distro based on that. Most enterprise, cluster and scientific software, as well as some hardware, is best-supported on RHEL-based distros, and the stability of these distros means few surprises during the disto's supported lifetime.

If you're hosting your own web apps on commodity servers, more into VMs and containers, or you are more concerned with tracking current versions of languages, kernels, and other software than you are with long-term stability, then Ubuntu can work well.

Agreed entirely.

The 2 year LTS release cycle combined with 5 year support means you can either stay in step lock with LTS or skip every other version and still have a year to upgrade, I retired my last 10.04 earlier this year, that thing ran in production for five years with less than 10 hours downtime :).

My experience of Ubuntu Server is that it's basically just Debian with a few management tools pre-installed (reporting, supervisord, etc).

Personally I prefer Debian because the extras Ubuntu ships usually get disabled / deinstalled on production servers, so it makes more sense to work from a minimal base to begin with.

What exactly hasn't "just worked" about Debian?

Heh. It's been long enough since I tried that I don't remember. Hence the lack of details in my post.

I do remember that I had planned on fully switching to Debian (it seemed odd to me to use a distro based on Debian instead of just Debian), but ran into enough issues that it was better to just stick with Ubuntu.

Reevaluating Debian is on my todo list for when I have time. It's been long enough that the issues I ran into before will hopefully be gone. Or maybe I'll have changed how I do things in a way that avoids those issue.

The purpose of the policy is to protect end-users - they should not download/install something thinking it is "Ubuntu", and it turns out that it isn't Ubuntu.

Ubuntu encourages derivation, but there has to be balance in protecting users and the reputation of the Ubuntu project. One of the objectives for Ubuntu has always been to enable people to build on it - that's why it's always encouraged and supported derivatives. But, but there are effects are what causes this part of the policy:

* Someone providing a version of "Ubuntu" for specific hardware, but which broke various bits of user-experience * Someone customising Ubuntu for a specific server load but replacing PHP with their own version that wasn't in the package system - consequently no more security updates to this component.

This area of the policy solely covers publicly distributing:

* If you're distributing Ubuntu without any alterations then there aren't any issues: for example people create CD's in countries with low-bandwidth. * If you're using Ubuntu for internal use then you can do whatever you want: including changing configuration, altering components etc etc etc.

If you make alterations to the OS and present to the external world (distribute it publicly) as 'Ubuntu' then you need a bit of care. It's hard to write all the permutations, but in practise it's pretty easy. Just watch for things that fundamentally alter the OS as provided: changes to kernels, system packages, default installs or system configurations. In my experience adding things is unlikely to be problematic. If you're doing things like installing applications from the archives, or generally configuring things then there's unlikely to be an issue.

Dustin wrote a good post: http://blog.dustinkirkland.com/2015/07/appellation-of-origin...

You should read the policy directly and ask Canonical if you're still unsure.

I guess so it is the same situation as far as I can see.

It's appealing because Ubuntu is the distribution that people are most familiar with. These sorts of issues aren't seen as important outside of the legal niche.

It's like when you install a copy of Debian and look for Firefox, but instead see something called Iceweasel - I assume that still happens? The name is so passive aggressive.