this post was submitted on 24 Jun 2023
198 points (97.1% liked)
Linux
48690 readers
1006 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
My vote is Archlinux. Debian is sometimes a little too "optimisitic" when backporting security fixes and upgrading from oldstable to stable always comes with manual intervention.
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.
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.
Bonus: it is extremely easy to build and maintain your own packages, so administration of many instances with customized software is very convenient.
Regarding the kernel upgrades: Using the linux-lts package / kernel get's you a pretty reliable setup.
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.
Once a year there is a manual intervention. Last one was the repo merge, and that did not even break then. Before that... hmmm... I dont even remember.
On Desktop with nvidia and a lot of other AUR stuff it is more work, but the servers run smooth as butter.
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.
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.
We're not back in the early 2000s, upgrading the OS is trivial when you're using tools like terraform, ansible, and docker.
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.
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.
We use Ansible as well, it keeps all servers happily upgraded and all packages in working order - even the weirdest custom software instances. Nodjs is available as lts packages im arch and it, again, just works.
I have zero issues with upgrades on desktop and server except once last year when my old Core2Duo notebook I use in the kitchen did not suspend correctly for a whole week until the Kernel bug was fixed. (I ran linux-lts for a week, it was... smooth sailing).
During that time we had 3 failed migrations of old PHP software to the new Ubuntu LTS and were fighting almightly RHEL because it simply did not provide the packages the customer required - we are now running an Arch container on the RHEL box...
I know this discussion is a little bit like religion, and obviously luck and good circumstances play a role. We both speak from experience and OP can make their own decision.
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.
if you need reliable uptime you are in need of redundant servers and at that point you can just apply updates and reboot the servers concurrently
Businesses rely on stable server and applications. Stable in the sense of API/ABI stable. You want an application behave exactly the same on day one and on the last day before eol of the server OS.
Arch is pure chaos and it could completely change how things work and break commercial third party apps on that server on potentially every day. And you would not necessarily notice the error until its to late and your data is corrupted.
You don't trow money at a your server infrastructure to get redundant servers to finally be able to use Arch somewhat stable. And why should a business not use that redundancy for an LTS distro to get even more stability and safety of operations.
Regardless of the distro, unless you use Kernel live patching (https://wiki.archlinux.org/title/Kernel_live_patching) you should boot a new Kernel when it is released by your distro with a security warning. Running unpatched old Kernels just for 100% uptime is not safe.
Oh and, I never had issues with Arch changing spontaneously - what event are you speaking of?