I'd like to extend your claim to Redhat as well. I won't make the comparison directly to Ubuntu, but I will compare it to Debian. And in the realm of server-oriented tasks, Debian is hands-down a better option, from the point of view of a sysadmin.
I was a linux sysadmin at a university for 6 years, and I used linux personally for a decade (before switching to iOS dev). During that period, I've had brief, frustrating encounters with Redhat.
It's not that it is unusable -- anything which can be done on Debian can be accomplished on a Redhat box. It's death by a thousand little annoyances, which is exactly the argument against PHP, so I think it's an "apt" comparison (pun intended).
For example,
* How do you restart apache on Debian? "/etc/init.d/apache restart". On Redhat? "/etc/init.d/httpd restart". Ah, so Redhat is in the habit of renaming all of their init.d scripts after the protocol of the service? Nope, turns out they only did that to Apache's script. WTF?
* While we are picking on Redhat's Apache, they also chose to pollute /etc with a bunch of crap which doesn't belong there. Symlinks to /var/log/httpd, /usr/lib/httpd/modules, /var/run, etc. So now, when I grep /etc for something config-related, I pause and think "why is this grep taking so long...", and then a bunch of crap from /var/log spews onto the screen. Thanks, guys...
* Still on the Apache kick, they decided to make the default permissions drwx------ for /var/log/httpd, with root as the owner. Really? Root is the only person who will ever need to look at those logs? Perhaps chgrp'ing to adm would be more sensible?
* Which leads to another problem... because they put their WSGI sockets in /var/log/http (WTF?), which is... only accessible by root. Wonderful, so now I have to reconfigure all of my WSGI processes to stick their sockets into some other location, like /var/run. On Debian, this "just works".
* The package maintainer of util-linux arbitrarily decided to remove cfdisk because it was a "pile of junk" (https://partner-bugzilla.redhat.com/show_bug.cgi?id=53061 ). Really? Because every partition I've created on Debian for a decade worked just fine, using cfdisk...
* There is (was?) no "vim" package. On Debian, to install vim, you type "sudo apt-get install vim". On Redhat, you type "sudo yum install vim", then go search google for a few minutes, and then type "yum install vim-enchanced". Thanks, guys.
* Supported packages. At the time, the Debian package repository was something like 12,000 packages, while Redhat's was around 3,000. This meant that for any production system, you inevitably had to either compile and install lots of software by hand, or you had to rely upon the community (e.g. http://dag.wieers.com/rpm/) for pre-compiled packages, but now you've just thrown away the consistency and quality level which comes from e.g. Debian's Policy Manual, and you've introduced a rather gaping security concern into a "production" system. Wonderful.
That's all I can recall off the top of my head, but the gist here is that there are a ton of tiny little bad decisions which make Redhat suck, and there's simply no good reason for it. Its just a pile of annoyance.
Unfortunately, Redhat has somehow positioned themselves as the "enterprise" linux, so PHB's often make the technical decision to go with Redhat, completely ignorant of its technical deficiencies, dooming their employees to suffer the consequences.
Perhaps I'm jaded, but when someone tells me they run Redhat, I immediately assume they made that decision from a position of inexperience, and they simply don't know any better.
> * How do you restart apache on Debian? "/etc/init.d/apache restart". On Redhat? "/etc/init.d/httpd restart". Ah, so Redhat is in the habit of renaming all of their init.d scripts after the protocol of the service? Nope, turns out they only did that to Apache's script. WTF?
For historical accuracy, the HTTP server binary of the Apache project has been called 'httpd', compiles to 'httpd' in the source official distributions and is distributed as 'httpd' in the binary official distributions for ages, if not since day one.
I was a linux sysadmin at a university for 6 years, and I used linux personally for a decade (before switching to iOS dev). During that period, I've had brief, frustrating encounters with Redhat.
It's not that it is unusable -- anything which can be done on Debian can be accomplished on a Redhat box. It's death by a thousand little annoyances, which is exactly the argument against PHP, so I think it's an "apt" comparison (pun intended).
For example,
* How do you restart apache on Debian? "/etc/init.d/apache restart". On Redhat? "/etc/init.d/httpd restart". Ah, so Redhat is in the habit of renaming all of their init.d scripts after the protocol of the service? Nope, turns out they only did that to Apache's script. WTF?
* While we are picking on Redhat's Apache, they also chose to pollute /etc with a bunch of crap which doesn't belong there. Symlinks to /var/log/httpd, /usr/lib/httpd/modules, /var/run, etc. So now, when I grep /etc for something config-related, I pause and think "why is this grep taking so long...", and then a bunch of crap from /var/log spews onto the screen. Thanks, guys...
* Still on the Apache kick, they decided to make the default permissions drwx------ for /var/log/httpd, with root as the owner. Really? Root is the only person who will ever need to look at those logs? Perhaps chgrp'ing to adm would be more sensible?
* Which leads to another problem... because they put their WSGI sockets in /var/log/http (WTF?), which is... only accessible by root. Wonderful, so now I have to reconfigure all of my WSGI processes to stick their sockets into some other location, like /var/run. On Debian, this "just works".
* The package maintainer of util-linux arbitrarily decided to remove cfdisk because it was a "pile of junk" (https://partner-bugzilla.redhat.com/show_bug.cgi?id=53061 ). Really? Because every partition I've created on Debian for a decade worked just fine, using cfdisk...
* There is (was?) no "vim" package. On Debian, to install vim, you type "sudo apt-get install vim". On Redhat, you type "sudo yum install vim", then go search google for a few minutes, and then type "yum install vim-enchanced". Thanks, guys.
* Supported packages. At the time, the Debian package repository was something like 12,000 packages, while Redhat's was around 3,000. This meant that for any production system, you inevitably had to either compile and install lots of software by hand, or you had to rely upon the community (e.g. http://dag.wieers.com/rpm/) for pre-compiled packages, but now you've just thrown away the consistency and quality level which comes from e.g. Debian's Policy Manual, and you've introduced a rather gaping security concern into a "production" system. Wonderful.
That's all I can recall off the top of my head, but the gist here is that there are a ton of tiny little bad decisions which make Redhat suck, and there's simply no good reason for it. Its just a pile of annoyance.
Unfortunately, Redhat has somehow positioned themselves as the "enterprise" linux, so PHB's often make the technical decision to go with Redhat, completely ignorant of its technical deficiencies, dooming their employees to suffer the consequences.
Perhaps I'm jaded, but when someone tells me they run Redhat, I immediately assume they made that decision from a position of inexperience, and they simply don't know any better.