FWIW I'm running my personal VPS with Arch, with services that only I use. As many people know the good thing with Arch is that what you gey is the bare minimum to have a shell running, so anything that is not necessary for the system to be up is something I installed; I <i>know</i> what is on the system.<p>I do upgrade my packages from time to time. It's almost always happened smoothly. The few times problems happened were due to 2 reasons:<p>- the software itself has a buggy upgrade procedure. I probably would have had the same issue with any other distribution, assuming they would contain the latest version<p>- it's an Arch-specific upgrade issue, but I have so few packets that this happens at most twice a year and it's always documented on the front page of the arch wiki<p>I have to admit that since it's only my own server, there is no pressure for services to stay up. In practice in the years I've used this setup I've never had an issue because a package was too recent and buggy; it was always a misconfiguration from my part.<p>I very much like the process of steadily keeping up to date bit by bit, instead of stagnating on a stable base and doing a big bang update every few years. I also like the fact that I don't need to know which version of which release am I going to get, it's always the latest one and it's the one that upstream released.
I really like Arch, but I wouldn't use it in production.
Yes, the packages are up to date and there are not many problems with them. But did you try to rollback to previous version of a package?
I had the problem on my personal laptop last year. There was no possibility to get a different version than the newest, which was broken (upstream's fault in this case). Luckily I had the previous version in my pacman cache and was able to install it. The package maintainers did a good job and the issue was resolved in something like 24-48 hours (from patching upstream to pacman). So nothing tragic for personal use.
In a productive environment? A very big no. One to two full days are simply not acceptable in any kind and/or size of business. Yes, you would (and should) test the update before rolling it out to production and be able to mitigate the problem, but you can't be sure, because you can't pin the version you want to install. Ok, you could build your own repo and package everything you need yourself. But it takes time and costs a lot of money.<p>Also automated deployment of Arch is a little bit of a headache.
All FPGA synthesis runs for <a href="https://webfpga.com" rel="nofollow">https://webfpga.com</a> are on Arch Linux based containers. There isn't a lot of traffic. We get around 5-10 synthesis runs per day from .edu accounts. It's been reliable, lightweight, and stable.<p>When developing the platform, we tried Ubuntu/Debian/CentOS, and at the time (about 1.5 years ago), Arch Linux was the most reliable OS for getting the 32-bit deps to work with existing commercial chains, and new toolchain compiles (IceStorm, NextPnr, etc). I think this is because Arch typically includes the development headers by default.<p>As long as the regression tests continue to pass, we will likely continue to roll with Arch Linux. We only tend to rebuild images once a month or so, since our backend is fairly feature complete already.<p>--<p>I think the trick is:<p>* Use containers, e.g. dockerhub's archlinux<p>* Assume that you will never be able to run pacman on a live system. Instead, rebuild a new image with a Dockerfile with your new packages -- then deploy that.
I'm a fan of Arch on the desktop, and I wouldn't recommend this.<p>The strength of Arch on the desktop for me is that it is a rolling update distro - that you are always up to date with the newest driver updates, mesa, etc.<p>This is exactly why I wouldn't use it on a server. Every time you install or update, you run the risk of getting a major software update that could break your app or server config.<p>For servers I want predictability - the same software versions over an extended period with just bugfixes & security fixes, and for <i>me</i> to decide when I want to change major versions. Arch doesn't make this predictability an option.
Please don't use ArchLinux for your production environments. Unless you want to risk being murdered by future employees of your company of course.