Skip Navigation

Moving away from RHEL based distros, whats good ?

Hi, mostly i use REHL based distros like Centos/Rocky/Oracle for the solutions i develop but it seems its time to leave..

What good server/minimal distro you use ?

Will start to test Debian stable.

215 comments
  • You can't go wrong with Debian

    • All my servers run debian and it's going swimmingly. My daily driver runs bookworm with huge success

    • I'm going to throw my support behind this one as well. I'm circling back to Debian after a long stint on Fedora on my primary machine. I've been running Debian 12 on my desktop for several weeks now and it's been pretty great.

      it is one version behind fedora in gnome releases, so I installed the latest gnome from the experimental repos and that worked pretty well. I don't know if I would recommend that for anyone else, but it worked for me.

      I have a few personal servers still running CentOS 7, but I will be migrating them to Debian slowly over the next few months. I suspect I will go fine. Debian organization to maintain FOSS ideals over the next 5 to 10 years, so it seems like a good default for me.

      I have read about Vanilla OS. It is Debian based with some neat features stacked on top that might be fun for a desktop OS. I can see myself switching to that on the desktop if they deliver on all their promises.

      • Life long Debian (and Debian derivatives) user (23 years and counting). I have pretty much settled down into (this has been true for years):

        • Debian for servers.
        • Mint for workstations (that you want to just work and don't want to spend time troubleshooting / tinkering). Mint is linux your grandma can use (my Boomer real estate broker father has been running Mint laptops for the last 5 years).
        • Ubuntu for jr. Engineers who want to learn linux.
        • Qubes (with Debian VMs) for workstations that must be secure (I've been working recently with several organizations that are prime targets either the CCP or have DFARS / NIST compliance requirements).
  • If you're up for it: NixOS!

    It's quite a steep learning curve, but after some time (after you've configured your "dream-system") you don't want to go back/switch to any different distro.

    Specifically servers IMHO are a great use-case for NixOS. It's usually simpler to configure than a desktop distro, and less of the usual pain points of "dirty" software (like hardcoded dynamic libraries, that exist on most systems (ubuntu as reference) at that path).

    I've much less fear maintaining my servers with NixOS because of its declarative functional reproducability and "transactional" upgrade system, than previously (where I've used Debian mostly).

    • The thing about NixOS is that while using packages are easy, creating them are still really hard and/or undocumented.

      With most popular services already being packaged by people who know what they're doing this isn't that big of a deal, but when I want to try out something from Joe Schmoe's GitHub (or worse, something I made myself) it is much easier for me to throw together a "good enough" Dockerfile and compose.yml together in barely a hour of work than to dig into Nixpkgs internals and wrestle with Nix's syntax.

      • Kind of depends what you want to package. For projects that force you to provide dependencies yourself (e.g. most C or C++ projects), Nix packaging is very easy to use. Just slap a flake.nix together with the necessary dependencies, where to get the source from and how to build it.

        Where Nix gets really difficult is with packages that reinvent their own packaging system and do dynamic downloads at compile or even runtime. Those really do not harmonize with Nix, as the Nix build process happens in isolation without network access and wants to have all dependencies specified beforehand, with checksum and all.

        When it comes to languages with their own package manager it also gets a bit complicated, as while Nix does come with workarounds for all the common cases, there are generally multiple ways to do it, e.g. you can use mach-nix, pypi2nix, buildFHSUserEnv or buildPythonPackage to build Python packages and it's not always obvious which is the best approach or which will even work.

        Packages that softly depend on other packages via some kind of plugin mechanism are also tricky, due to Nix packages all being isolated in their own directories. Again, which workaround works best here can be tricky, some packages require specifying all the plugins at package build time others use environment variables or other means to locate plugins.

        All that said, these issues are kind of fundamental when you want to have a proper reproducible packaging system and hard to avoid. I do prefer a system that forces some cleanliness from the ground up instead of adding ever more ugly patchwork on top, but I can understand why that can be at times very frustrating.

      • Well I guess it depends how deep you're in the rabbit hole already, I think it's relatively easy for me at this point to create a new package (I'm maintainer already for quite a few). But yeah ... steep learning curve ... Less so with Nix itself, though non-the-less, it's a simple functional programming language with a new paradigm (derivations). But rather NixOS/nixpkgs Nix magic. For example there's a dynamic dependently typed type-system built on top of untyped Nix in the NixOS module system that is spin up on evaluation time.

        But I understand your point, at the beginning of my NixOS journey I have also rather created a "good enough" Dockerfile. Depending on the exact context I still do this nowadays (often because there's an official well maintained docker image in comparison to a not so well maintained Nix one, and the context is too complex to maintain/develop/extend it myself). But if there's a good solution in Nix I rather use that, and that is often less headache than setting up a service with e.g. docker-compose. I also use flakes mostly for a dev environment, if you're a little bit deeper in it, you can spin up a relatively clean dev env in short time (I'm often copy pasting the ones I have written from different projects, and change the packages/dependencies).

    • I had a really bad experience with NixOS, the idea is great, but I had a lot of troubles at each generation switch. I don't like it because I had to learn a lot of specific tools, that only applies on that OS, and it was (really.) hard. I prefer a classic distro, maybe Debian (or Freebsd if not linux), with Ansible for declarative config, and ZFS storage to be able to revert a snapshot if I have any kind of problem.

      • As I said it has a steep learning curve and documentation is pretty much the nixpkgs repo itself (well after understanding the basics of Nix and NixOS at least, with the combination of the https://nixos.wiki mostly IMO). It also takes some time to get used to the quirks of NixOS (and understanding the necessary practical design decisions of these quirks).

        But I have nowadays seldom trouble with switching the generations (i.e. nixos-rebuild switch), unless you're updating flake inputs or (legacy) channels (where e.g. a new kernel might be used). In that case it makes sense to reboot into the new configuration. Also, obviously that can lead to short down-times (including just restarting a systemd service, if a service has changed in between the generations), if that is unacceptable, there obviously needs to be a more sophisticated solution, like kubernetes via e.g. kubnix. I'm not sure how much of that can be achieved with Ansible, as I haven't used it that much because I disliked the "programming" capabilities of the Ansible yaml syntax (which feels kinda hacky IMHO).

        But apart from NixOS, one can also just use Nix on a different system to e.g. deploy or create docker images (which can be really compact, as only the necessary dependencies for a package is packaged) that in turn could e.g. be managed with Ansible or something...

  • If you need enterprise support I'd look for Ubuntu or maybe SUSE. If you can't tolerate RHEL closing their source, that is (some people won't be bothered).

    If that's not needed, then Debian all the way! It's served me well for like 10 years in my home lab.

  • For my public-facing server, I use Debian Testing, since I haven't had any major issues with it's stability. Auto-upgrades usually work , although there were a few times I had to manually intervene on the latest name-change upgrade from Bookworm to Trixie. I usually don't even log-in except every few months.

    At home, where it will only affect me, and possibly my family dealing with me, if the whole O. S. crashes and has to be rebuilt from backups, I use Arch.

  • I like Debian and Alpine for servers (depending on if I can get away with musl or not)

    I use Arch for my actual computers because rolling release is the way to go. Saves me ever having to actually do a full OS upgrade.

  • Tumbleweed or Leap are good. You could go with something exotic like VanillaOS

  • I have utilized Debian and Minimum Ubuntu as an alternative to Centos with reasonably pleasurable results

    I do also like Absolute for crafting the perfect lightweight install, but it's kind of a pain in the ass.

  • Debian is stable. Arch is bleeding edge and vanilla. if you want something on arch you got to install it and follow the arch wiki

  • If you want easy way - Ubuntu. All packages exist, all developers support. But snap is pain.

    If you need mainline packages - Arch. But be care with bugs. Use LTS kernel or you can broke filesystem on one day for example.

    If you want forgot about dependencies - NixOS. But Nix not classic packet manager and you can feel pain on start.

    In reality, a lot depends on the environment in which your code will work. If it's Java, then in principle it doesn't matter, but if it's C/C++, it's better to develop in an environment as close to production as possible.

  • I can throw in a vote for Debian stable as well. I've recently installed Debian 12 and I've been blown away by how great it's been compared to my recent Fedora 38 experience out of box.

    • What kind of hardware are you running it on? I've started using Debian for servers, but I'm still using Fedora for laptops, currently. I am always curious about different options.

      • This is my daily driver tower.

        • i9 10850k
        • ASUS TUF Gaming Z590-Plus
        • NVIDIA GeForce RTX 2070 SUPER

        I don't use wifi however it did work out of the box. The only thing that required additional setup was the Nvidia card but the driver was available in the repos.

        If you do end up testing it out on a laptop let me know how it goes. I have a Windows laptop lying around here somewhere that could use some love.

215 comments