I wouldn't recommend it for any serious work where downtime costs you money though. There are just too many occasions where Arch renders your Desktop unusable because of an upgrade. You have to pay close attention to the news on the homepage for any system breaking changes (which is kind of ridiculous). And even then a system may occasionally render your system unbootable just because.
So I decided to actually write down every time my arch install stopped working. I only managed to continue doing so for a couple of months and it's only representative of my pc so take it with the usual grain of salt. I usually run pacman -Syu every day.
That being said in 2 months I had these problems:
05/10/2013 Slim changed the xsession name, I had to edit manually slim.conf
14/10/2013 linux-ck kernel upgrade broke xorg so I had to downgrade until it was fixed
29/10/2013 xmobar template had to be slightly modified
02/11/2013 Calibre didn't start, imagemagik was broken, had to downgrade until it was fixed
So 4 problems in 2 months. I'm sure I didn't write down everything since it was a little tedious.
Would i recommend you use it on a production server? Is the time you spend on paying attention worth it? I haven't the foggiest.
It is not ridiculous. It is as-expected. Arch is not for ease-of-use to non-Linux-experts. I use Arch for its no-nonsense, simple attitude towards users who know what they're doing. I'd expect Ubuntu (or Mac OS X) to sugar-coat and abstract and hide away internal changes, I'd most certainly not accept Arch doing things that way.
Arch is also a rolling-release, which means there isn't any nuance of "release" to migrate to a new configuration or software-architecture. You have SysV today, you have systemd tomorrow. You have /{s,}bin today, you have symlinks to /usr/bin tomorrow. Coming from an Arch user for more than 2 years (on a single installation that too), both those migrations were huge and both were handled by Arch well. Where it would take Ubuntu or Fedora a proper release to do either, it took me on Arch just a few minutes.
> And even then a system may occasionally render your system unbootable just because.
This sounds more like flame and less like substance. Not in the least because I fail to understand the "a system <verb> your system" grammar. I have also never faced this problem, and it is suspicious such a thing would happen without explicitly making a change to the system configuration. I have maintained 4 DE configurations side-by-side, one of which is custom-rolled (compiz-as-a-DE + bash-script-as-a-session-manager), and never had a scenario where one boot was working and the next boot failed when I had made no changes at all, and most certainly never "just because".
Arch works for me, because I know how to work Arch. If Arch seems inexplicable to you (evidenced by your use of the phrase "just because"), perhaps you should be using a distro where understanding your OS internals is not a prerequisite.
That said, I agree that Arch is not suited for use cases where downtime would cost heavily, not because there is a propensity of the OS to fail (there isn't), but because there is a propensity of the OS admin to stumble, and the need for a more qualified OS admin than would be required to run Ubuntu et al. I have used Arch in production servers without issue, but I would not dare to do so in cases where there are other admins involved, precisely because I don't expect them to know Arch.
The knowledge that you have to look at the newspage to avoid system outages only comes to you after you experienced such an outage. After getting mocked in the forums you'll surely learn that lesson.
But even then I had updates that broke my system because dependencies had been broken or the configurations weren't properly updated. And at that point you need to be an expert at every single software component you use. That is unfeasible for me.
Have a look at unthorty's reply. I would say that at least some of those errors could've happened to an experienced user.
2. Upstart: Works for me. I like systemd too, but I'm not going to switch distros to get it.
3. Auto-restart: As you said, it's a Debian thing. If you really don't like it, look into /usr/sbin/policy-rc.d
4. MySQL: sudo apt-get install mariadb-server (yeah, it's in the official repo)
5. Pollinate & AppArmor: If you don't want them, disable them.
6. Compiz & Mir: Use another desktop environment. Also, in case you missed the news, Mir has been postponed indefinitely.
Furthermore, Ubuntu mobile will have Mir as part of its stack, so I can't see why they'd postpone it.
Better to use it and change the parts we don't like until the changes become the norm -- ubuntu's strength is in its community. Linux infighting and fracturing over pedantic differences is what keeps it from becoming a first-class desktop OS for the common user.
(And yes, Upstart is a steaming pile of technology.)
In terms of cloud, Ubuntu is popular, if I look at the desktop I get the same result. So apparently they are doing something right.
If we want to judge Linux distro releases we should judge them by facts that matter to real users, not made up ones. Also we can't really talk about Ubuntu Server and Ubuntu Desktop in the same thread, even though a lot of the base system is the same, these areas have radically different requirements.
