Daniel sent us this one — and it's the kind of question that every homelab person hits eventually. Why do desktop Linux users fight about distros like it's a blood sport, while server admins make these almost boringly pragmatic choices? He wants us to dig into what actually drives server distro selection — starting with filesystem support for BTRFS and ZFS, what "support" even means when the installer puts you in manual partitioning hell, then why someone might run Fedora Server or something from the long tail instead of Ubuntu or Debian, and finally what tips the scales between Ubuntu, Debian, and OpenSUSE.
There's a real paradox buried in there. Desktop users will debate wallpaper defaults like it's theology, but on the server side, the emotional attachment just evaporates.
Because nobody's ricing their server.
Your Nginx reverse proxy does not care about your terminal color scheme. What it cares about is whether your RAID array survives a power failure and whether your kernel actually supports that fancy network card you bought off eBay. So the emotional weight shifts from identity to constraint satisfaction — I need X, Y, and Z, and only these three distros get me all three. That's the whole decision. And I think that's what makes the server distro conversation fundamentally more interesting, because you can actually trace the decision tree. It's not vibes. It's not "this one feels more like home." It's a logic puzzle where the pieces are kernel versions, package availability, installer behavior, and support lifecycles.
Though I'd argue there's still identity involved. It's just that the identity is "person who didn't have to debug a ZFS kernel panic at three AM.
The aspirational identity of the well-rested. And I'd add a second identity layer — the person who can hand a setup guide to a colleague and not have it be forty pages of "then open a second TTY and chroot into the target environment.
The "my documentation fits in a README" identity. That's a real thing. I've seen job postings that basically encode distro preferences as cultural signals. "We're an Ubuntu shop" doesn't just mean they run Ubuntu — it means they value the kind of onboarding experience where the new person is productive on day two instead of day fourteen.
That's not trivial when you're scaling a team. Alright, so where do we start?
Let's lay out the landscape, because it's shifted enough in the last couple years that what somebody learned in twenty twenty-three might already be wrong.
As of mid twenty twenty-six, Ubuntu is sitting at around thirty-three percent of web servers by distro, according to the W3Techs tracking. Debian's at about twenty percent. Those two eat more than half the market between them. CentOS as we knew it is dead — CentOS eight hit end of life December thirty-first twenty twenty-one, and what's left is CentOS Stream, which is essentially a preview of what'll land in the next RHEL. It's not a stable downstream rebuild. That niche got filled by Rocky Linux and AlmaLinux, and they're doing fine. But the important thing to understand about Rocky and Alma is that they inherited CentOS's position as the "free RHEL" — and with it, RHEL's installer philosophy, which is... let's say "utilitarian.
The big two are still the big two.
Then OpenSUSE Leap — and we should flag this early — Leap fifteen point six, which shipped in June twenty twenty-four, is the last Leap release. SUSE is pivoting to ALP, Adaptable Linux Platform, which is a container-focused immutable OS. So anybody who started their server journey on OpenSUSE Leap faces a migration decision within a couple years. That's a concrete fact that changes the calculus relative to even two years ago. If you're standing in a data center in twenty twenty-six looking at a five-year deployment horizon, picking Leap today means you're signing up for a migration mid-lifecycle.
That's brutal. And it's the kind of thing that doesn't show up in a feature comparison table. You only know it if you're tracking the news.
Which is exactly why we're having this conversation. Feels like the whole server world is drifting toward immutable and that's a whole separate conversation. But let's ground this in the thing Daniel put his finger on — filesystems. Specifically BTRFS and ZFS.
This is the right place to start because for a lot of server deployments, the filesystem effectively picks the distro, not the other way around. And the key phrase Daniel used is "ease of installation." So what does "support" actually mean when a distro says it supports BTRFS?
That's the whole game. And it's worth unpacking what "support" can mean, because there's a spectrum. At one end, you've got "the kernel module ships in-tree and the installer offers a guided setup." At the other end, you've got "the userspace tools are in the repo and the rest is your problem." And distros are not always honest about where they fall on that spectrum.
"BTRFS is supported" could mean "we compiled the module" and nothing else. Let's walk through BTRFS across the contenders. What's the real state of the union?
Ubuntu added BTRFS as a supported option in the installer back in twenty point four, but the default subvolume layout changed between twenty point four and twenty-two point four. They switched from a flat layout to something that better integrates with tools like snapper for snapshots. Ubuntu Server twenty-four point four LTS — the current long term support release — will give you a guided BTRFS root on the standard subvolume layout straight from subiquity, which is their server installer. No manual partitioning, no chroot.
You just tick a box?
You tick a box. It makes a btrfs root, a btrfs home subvolume, sets up grub correctly, and sends you on your way. That's the standard for "supported" in twenty twenty-six. And here's why this matters in practice: imagine you're provisioning a small cluster. Maybe six nodes for a Kubernetes control plane. With Ubuntu, your provisioning script is basically "boot ISO, feed it this YAML file, walk away." With anything less than guided setup, your provisioning script is suddenly a thousand lines of parted commands and mkfs invocations that you have to test against every point release because the disk naming might shift.
You're one kernel update away from discovering that your hand-rolled grub config didn't account for some new initramfs behavior.
Which makes Debian's situation honestly baffling.
Debian twelve Bookworm.
Debian twelve ships BTRFS in the installer. You can absolutely select it. But — and this is the practical gut punch — there's no guided BTRFS root setup. The debian-installer will recognize mkfs dot btrfs exists, but if you want root-on-BTRFS you're hand-carving partitions, setting up subvolumes from a terminal, and getting grub installed manually in a chroot.
BTRFS the filesystem is there. What's missing is BTRFS the workflow.
Perfect way to put it. And for production systems where you might provision forty identical nodes, asking somebody to recreate that by hand every time is madness. Yes, you could script it with preseed or kickstart or, what, an Ansible playbook writing udev rules and using parted —
You did it once and took screenshots and called yourself an expert.
Let the record show I am not admitting to anything.
But seriously, this is the kind of thing that burns teams. Someone builds the perfect Debian BTRFS setup once, documents it, and then eighteen months later a new point release changes something subtle about how the installer enumerates NVMe drives and suddenly the whole playbook breaks. And the person who wrote it left the company.
Now you're the person in the data center at 2 AM with a laptop open to a Debian wiki page that was last updated in twenty nineteen. That's not a hypothetical. I've gotten that phone call. I've been the person on the other end of that phone call.
What about OpenSUSE?
OpenSUSE is the BTRFS gold standard. They integrated snapper as the default snapshot and rollback manager, YaST provides the whole guided BTRFS setup with snapper preconfigured to take snapshots before and after every zypper transaction — so every package install or update automatically gets a pre-and-post snapshot. That is as integrated as server filesystem management gets with BTRFS. And the practical benefit is enormous. You run a zypper update, something breaks — maybe a kernel module doesn't load, maybe a service fails — and you just reboot, select the previous snapshot from the grub menu, and you're back where you were five minutes ago. No rescue disk, no chroot, no prayer.
That's the dream, honestly. What about the subvolume layout? I remember hearing OpenSUSE's defaults were...
They use separate at-sign and at-sign-slash-home subvolumes. So your root is at-sign and your home directory is at-sign-slash-home. That structure is slightly different from what Ubuntu or Fedora use, and it matters because btrfs send-receive for incremental backups expects to send a specific subvolume or snapshot — scripts built around Ubuntu's layout might not transfer cleanly. It's a friction point, not a dealbreaker, but worth knowing. If you're building a backup pipeline that spans heterogeneous distros, you need to account for the subvolume naming conventions, or your send-receive commands will just error out mysteriously.
Fedora Server forty, which released in April twenty twenty-four, was the first Fedora Server release to throw BTRFS into the guided installer. Major milestone honestly. For a long time Fedora Workstation had it but Server didn't. Now they've given the server side the same treatment, including Cockpit integration for storage management. The catch of course is the lifecycle — Fedora Server runs a thirteen-month support window.
You get BTRFS RAID five and six fixes and new io_uring support and all these kernel six point eight goodies, and thirteen months later you rebuild.
Which for some use cases is perfectly fine and even desirable. If you're running a staging environment or a CI/CD farm where nodes are cattle, not pets, the fast cadence is a feature. You're always on a recent kernel, you get the latest filesystem improvements, and you never have to plan a major version migration because you're doing small ones constantly. But if you're running a production database that needs five years of stability, Fedora Server is actively hostile to your use case.
That's the kind of tradeoff that desktop users never have to think about. On desktop, "newer is better" is almost always true. On server, "newer" means "more things that can break during your maintenance window.
But let's pivot to ZFS because that's a whole different animal, and the underlying reason is the most frustrating piece of legalese in systems administration.
CDDL versus GPLv2. Mark Shuttleworth made waves years ago by including ZFS in Ubuntu's installer, and Canonical decided they considered the zfs dot ko module a derivative work that could ship as a dynamically loaded add-on. The broader Linux kernel team considers ZFS not integratable. Legal opinions differ. The practical upshot is you can ship a computer with ZFS preinstalled — or boot media with it preloaded — but you cannot have it in-tree in the kernel source because Greg Kroah-Hartman has been unequivocal that he will block any pull request attempting it. Everyone ships it out-of-tree.
Thank you Greg, arbiter of kernel fun.
The out-of-tree status creates real operational headaches. Every kernel update is a gamble. The ZFS module has to be rebuilt against the new kernel headers, and if the kernel changed some internal API that ZFS was relying on — which happens more often than you'd think — your system doesn't boot. Or worse, it boots but your zpool doesn't mount and now you're debugging a production outage.
I've seen that failure mode. The system comes up, everything looks fine, and then you try to cd into a directory and get "Input/output error" because the dataset never mounted. And your heart just drops.
The fix is usually "boot the previous kernel and wait for the ZFS maintainers to catch up." Which is fine if you noticed the problem before you removed the old kernel. Which some people don't.
User space exporting to kernel in ways Greg dislikes notwithstanding — the practical picture is this. Ubuntu has the best first-party ZFS support. They have the canonical zfs initramfs integration, the Ubuntu zfs PPA, and full subiquity installer support for setting up a ZFS root pool. You can install Ubuntu Server twenty-four point four LTS onto a ZFS RAID mirror with encryption at rest from the guided installer.
That encryption at rest part is not trivial. Setting up ZFS native encryption manually involves creating a key file, making sure it's available at boot, configuring initramfs to prompt for it or read it from somewhere secure — it's a whole project. Ubuntu's installer just asks you for a passphrase and wires everything up.
Debian — and here is the actual current state as of Debian twelve — requires you install zfs-dkms from bookworm-backports. It's not in the default repo at all. You load the contrib and non-free repos after you've already booted a minimal system, install the headers, compile the kernel module on your system manually, and then set up your zpool.
Debian's "support" is a description of what you are capable of constructing from source, not what they offer when you boot the installer.
That is the most diplomatically brutal way to put it. And if you're on ARM — let's say you're trying to build ZFS on a Raspberry Pi —
What could be a lovelier weekend.
It would be a weekend, wouldn't it.
Several weekends of phone-fixture scrolling-build-output dread. And for TrueNAS, which is the spiritual home for "I want ZFS and I don't want to think about anything else," TrueNAS Scale is built on Debian, not FreeBSD the way TrueNAS Core was — but it's heavily customized at the OS layer. TrueNAS Scale effectively ships ZFS as an appliance component, abstracted away behind their web UI. So for someone demanding a ZFS-first architecture from the metal up, TrueNAS Scale is arguably the gold standard precisely because you abdicate the installation choices entirely. You don't configure ZFS — you tell the web UI how many disks you have and what redundancy level you want, and it builds the pool. You don't set up snapshots — you click a schedule. It's ZFS as an appliance, not ZFS as a system administration project.
That gets at what Daniel was asking about manual partitioning — the trap where a distro says it "supports" a filesystem but the installer won't set it up automatically. Who are the worst offenders?
The principle here: the more "enterprise" the distro's downstream is, the more they assume you have automated provisioning in pipelines and don't need the pretty UI. Everyone ships the userspace tools to actually interact with the filesystem after the fact. There are precisely two — exactly two — distros that currently ship a hands-free guided installer capable of targeting root-on-BTRFS and root-on-ZFS: Ubuntu and OpenSUSE.
That's it.
BTRFS with guided setup? Ubuntu, OpenSUSE, and now Fedora Server forty. ZFS with guided setup? Ubuntu is the only game in town outside of TrueNAS Scale, which is basically a customized system image for an appliance rather than a general-purpose tool.
Then let's land the first half of this with a real deployable scenario. Four-disk RAID ten BTRFS root on Ubuntu Server twenty-four point four LTS versus Debian twelve.
Ubuntu case: boot the ISO, subiquity greets you, you choose guided storage, you pick "erase disk and use BTRFS" or you do a custom config where you select all four disks, add them as a "software RAID ten" — not md, not madm, but the BTRFS raid ten — the filesystem that sits atop it, set your mountpoint to slash, and go. The installer writes the EFI and boot partitions on the first disk.
Including rebooting into a working system.
Including booting into a working system. Debian case: boot debian-installer, wait for the partitioner to load. Plan to manually create the absolute minimum three partitions on each disk — the EFI on one, BIOS boot area, then block device setup — for each of the four disks except then you realize you haven't written the kernel cmdline instructions for RAID and you also don't know how to get the install to proceed while your root is a BTRFS subvolume that you chroot into. Which means you open another TTY while the installer is chilling in the background. Run chroot to the subtarget, mount proc, sys, dev, adjust the initramfs tune, or do it in an interactive loop.
When you describe it that way, it sounds awful.
If that scares you don't try hosting Nextcloud.
That more or less completes the survey in terms of daily-wear server platforms for the typical user buying custom machines. But let's talk about the exception — the people who are deliberately picking something other than the big two. Daniel specifically asked about Fedora Server and the long tail.
This is the split Daniel hinted at that deserves more attention: what's actually making people pick Fedora Server?
You tell me. I've seen it in the wild and I'm still not sure I understand the full rationale.
It's kind of fascinating once you separate path dependencies from genuine, deliberative adoption. The core attraction is cadence. Fedora Server ships roughly every six months, and each release lands with a kernel that's maybe five to seven days behind the upstream stable release. That means you get filesystem improvements, new hardware support, and security mitigations faster than any other server distro. For a certain kind of operator — someone running infrastructure where the hardware refresh cycle is also roughly six months, or someone who needs support for brand-new network cards or storage controllers — that cadence is genuinely valuable.
It's not just "I like new things." It's "my hardware literally didn't exist when Debian stable froze.
If you're deploying servers with the latest generation of Intel or AMD processors, or you're using some new NVMe spec, Fedora Server might be the only distro whose installer even recognizes your storage. Debian stable is on a roughly two-year release cycle, which means the kernel in Debian twelve might be eighteen months old by the time you're building a new cluster. That's an eternity in hardware support terms.
The other side of that coin is the SELinux integration. Fedora ships with SELinux in enforcing mode by default, and the policies are maintained by the same people who maintain the upstream SELinux reference policy. So if you're in an environment where mandatory access control is a compliance requirement — government, finance, healthcare — Fedora Server gives you the most coherent SELinux story out of the box.
Ubuntu ships AppArmor, which is easier to configure but less granular. Debian ships AppArmor too but it's less integrated. Fedora's SELinux policies are tighter and better tested because Red Hat's entire product line depends on them. So if your security team says "we need MAC," Fedora Server is a very reasonable answer.
The tradeoff, of course, is that thirteen-month support window. You're signing up for a lifecycle where every release is a migration. And that's fine if you've built your infrastructure around that assumption — immutable images, automated testing, canary deployments. But for the classic "install it and let it run for five years" use case, it's a non-starter.
That's the real dividing line. Fedora Server is for people who have adopted a DevOps workflow where the OS is just another component that gets redeployed regularly. If you're still in the world where servers are pets with names and uptime measured in years, Fedora Server will exhaust you.
Meanwhile, there's the other end of the long tail. The people running something unusual — Void Linux on a server, or Alpine, or one of the immutable desktops repurposed as a server OS. What's driving that?
Usually one of two things. Either it's a resource constraint — Alpine is tiny, it boots in seconds, it uses musl instead of glibc, and if you're running a hundred containers on low-power ARM boards, those differences add up. Or it's a very specific technical requirement that the mainstream distros don't satisfy. Void Linux uses runit instead of systemd, and there's a small but real contingent of sysadmins who will do almost anything to avoid systemd.
I was going to say — the anti-systemd crowd found a home in Void.
And I'm not here to relitigate the systemd wars, but it's worth noting that on a server, the init system actually matters less than on a desktop. Your services are defined as unit files or run scripts, and once they're written, they mostly just work. The bigger difference is in things like log management — journald versus syslog — and network configuration. But for someone who has strong opinions and wants a distro that aligns with them, Void exists.
Let's bring it back to the mainstream choices, though, because that's where most of Daniel's question lives. We've talked about filesystems and installers. What about the day-to-day operational differences between Ubuntu, Debian, and OpenSUSE for someone running a typical workload — web server, database, maybe some containers?
The biggest operational difference is package freshness versus stability, and how each distro manages that tension. Debian stable is exactly what it says on the tin — stable. The packages are old, but they are exhaustively tested together. When you run apt upgrade on Debian stable, you are getting security patches backported to versions that haven't changed in two years. The PostgreSQL version in Debian twelve is the one that will be there until Debian thirteen. You will never get a major version bump in a routine update.
Which is either a feature or a bug depending on whether you've built your application against that specific major version.
If your app was tested against PostgreSQL fifteen and Debian ships fifteen, you're golden. If Debian shipped sixteen in a point release, your app might break and you'd have no warning. So Debian's conservatism is a contract — we won't surprise you.
Ubuntu LTS sits in the middle. Fresher than Debian stable, but with a commitment to not breaking things within the LTS window.
Ubuntu adds a layer that Debian doesn't — the universe and multiverse repos, which are community-maintained, plus the Snap ecosystem for certain server packages. If you want the latest Node.js or Go on Debian, you're probably adding an external repo or using a version manager. On Ubuntu, there's a Snap for that. Whether you consider that a benefit depends entirely on your feelings about Snap.
I feel like we could do a whole episode on Snap versus Flatpak versus "just give me a tarball.
The point is, Ubuntu's operational model assumes you might want newer things than what shipped in the LTS, and it provides pathways to get them. Debian assumes you knew what you wanted when you installed and you're sticking with it.
Leap occupies an interesting middle ground. It's built from SUSE Linux Enterprise sources, so the core packages have enterprise-grade stability testing, but it also pulls in newer community packages. The operational model is different too — YaST is a comprehensive system management tool that has no real equivalent in Debian or Ubuntu. You can configure networking, storage, services, and users all from a single TUI or GUI. For someone coming from a Windows Server background, YaST feels familiar in a way that editing files in /etc never will.
With Leap going away, that whole ecosystem is in transition.
Which is the elephant in the room. If you're evaluating OpenSUSE for a new deployment in twenty twenty-six, you have to ask yourself: am I comfortable migrating to ALP in two years? And ALP is a fundamentally different thing — it's immutable, container-focused, and designed for transactional updates. It's not "Leap but newer." It's a different operating system paradigm. So the OpenSUSE recommendation today comes with an asterisk the size of a planet.
That brings us to the final piece of Daniel's question. Given all of this — the filesystem support, the installer behavior, the lifecycles, the operational models — what actually tips the scales between Ubuntu, Debian, and OpenSUSE for someone standing in front of a server right now?
I think it breaks down into three decision trees. If you need ZFS, you're on Ubuntu or TrueNAS. That's the whole decision. If you need BTRFS with minimal fuss, you're on Ubuntu or OpenSUSE — and OpenSUSE gives you the best BTRFS experience, but with the lifecycle caveat. If you don't need either advanced filesystem, the field opens up.
Then it becomes about support expectations.
If you want a distro where you can hire a support engineer — someone whose job is to answer your ticket when something breaks — Ubuntu has Canonical behind it, and SUSE has SUSE behind it. Debian doesn't have a commercial support vendor in the same way. There are consultancies that specialize in Debian, but there's no "Debian Incorporated" you can call. For a business, that matters.
For a homelab, it matters less, but the community support picture is different too. Ubuntu's forums and AskUbuntu are vast. Debian's wiki is legendary but sometimes archaeological. OpenSUSE's community is smaller but intensely knowledgeable.
We haven't even touched on the derivative distros — Proxmox, which is Debian-based but focused on virtualization, or TurnKey Linux, which ships preconfigured appliance images. For a lot of server use cases, the answer isn't "pick a distro and configure it" but "pick an appliance that already does what you want.
That might be the real answer to Daniel's question. The reason server admins seem boringly pragmatic about distro choice is that for most of them, the distro isn't the point. The distro is a vehicle for getting the thing they actually want — a filesystem, a package version, a support contract, a configuration workflow. And once you know what you actually want, the distro choice is almost mechanical.
There's still room for preference. But it's preference grounded in experience rather than aesthetics. You pick Debian because you've been burned by Ubuntu's Snap transitions. You pick Ubuntu because you've spent too many weekends hand-compiling ZFS modules. You pick OpenSUSE because snapper saved your job once. Those are stories, not vibes.
The stories of the well-rested.
May we all be so lucky.
