Regarding the kernel upgrades: Using the linux-lts package / kernel get’s you a pretty reliable setup.

You basically recommend to burn money.

Not because of Arch itself and its quality, but because you need to constantly monitor the mailing list for issues and you need to plan a lot more downtimes due to reboot. This is not gonna happen in businesses.

I have tried using Arch on a (personal) server and while it certainly works, I would not recommend for production. There are just too many moving parts there and while breakage is extremely rare (especially when carefuly reading the news), it still happens and most companies or organisations prefer a cumbersome, planned upgrade to the next version over many very small possibilities for a catastrophe.

The ease of building packages is indeed one of Arch’s strengths, it enables the AUR and therefore Arch has one of the easiestto use and largest repos out, but again, for production, you should go with containerisation IMO. Docker images are easy to build as well, OS independant and, most importantly independet from system libraries.

Imagine following scenario: You’re running a SaaS based on some python framework. Option 1, you’re running it as a pacman package. If have to use a library that isn’t in the official repos, then you’re fucked when a Python update comes that requires update libraries, you have to update your own app AND the library yourself or do some nasty downgrading, lots of manual intervention required. Or a library you used updates and changes its functionality so that you have to adjust your app. Option 2, you trash the easy to build system packages and go for a virtual enviroment. Now you’re at least protected from the library problems, everythings stale unless you update within with pip, but you lost the easy packaging aspect. But breakage isn’t 100% ruled out, even with the venv you can still encounter problems with updates of stuff that is between your App and the web. All the system stuff could be subject to change in any Syu. And venv is a python only solution, so everything that has other parts is no option. So Option 3, build containers, connect them, deploy them, run them on systems with very little changes in system applications.

I don’t think Arch (or any rolling distro for that matter) is the best solution for a server deployment. If you update rarely, you’re bound to have to do manual interventions to fix the update. If you update too often, you might hit some distro breaking bug and you’re rebooting very often as well. Those two options are not great on something requiring stability.

RHEL is designed to be the terminator: a bit outdated, but never stopping and never giving up until it’s completely destroyed.

Arch is a house that’s being built by a drunk tradie: everything is probably going fine, but you might end up with a front door that opens up to a solid brick wall.

The main benefit of arch is that it has a huge repo of cutting edge packages. That is pretty much completely useless for both development and infrastructure.

Devs don’t use cutting edge packages because that can introduce a whole lot of work for no benefits. So for example instead of installing node (cutting edge on arch), they use node-14-lts, just like their infra, until it stops getting support or a feature they need comes out in a newer lts version. And if your app is running on lts packages, you most certainly don’t need cutting edge system packages and all of the issues that come with them.

Debian is sometimes a little too “optimisitic” when backporting security fixes

You’re not going to be hacked because of a system package. It’s going to be a bad library, or your own bad code. Either way, it’s got nothing to do with pacman.

Release-based distros tend to be deployed and left to fend on their own for years - when it is finally time to upgrade it is often a large manual migration process depending on the deployed software. A rolling release does not have those issues, you just keep upgrading continuously.

We’re not back in the early 2000s, upgrading the OS is trivial when you’re using tools like terraform, ansible, and docker.

Bonus: it is extremely easy to build and maintain your own packages, so administration of many instances with customized software is very convenient.

Sure you can write a package for pacman and have it available on arch. Or you can write a guix package and have it available on any Linux distro. Or you can write a nix package and then run it on macOS as well. Windows being covered by both of these because of WSL.

I’ve recently had to write a package for both arch and guix, the guix one was a lot easier and the whole process was a lot smoother. Also you get nice features like transformations, allowing you to only modify the existing package instead of having to rewrite it.

Archlinux performs excellent as a lightweight server distro. Kernel updates do not affect VM hardware the same they do your laptop, so no issues with that. Same for drivers. It just, works.

I haven’t used it as a server distro, but it was my main desktop distro for the last ~4 years. It crashed every month or two, and failed to boot at least 3 times even with regular Syu’s. Before that I ran Mint for 2+ years. It never crashed, it never failed to boot. Other machines I wouldn’t update for months. mint had no issues with that and updated perfectly fine. Arch would often crap itself completely, fail to boot, I’d do a btrfs rollback and try again in a week or two. Sometimes that would be enough, other times I had to wait a bit more for shit to settle.

Arch has possible minor benefits, and a lot of possible downsides. It just doesn’t make sense to use it on a server, when you can take a rock solid foundation like Debian, and then build on top of it with nix/guix.