SUSE ships openSUSE Tumbleweed, openSUSE Leap and SUSE Linux Enterprise Server (SLES). How do these three differ in release model and support, and how would you choose between them for a server?

## Three products, one pipeline SUSE's Linux line is three products built by one engineering organisation on a shared package base. All three are RPM-based; all three use `zypper` on top of the `libzypp` dependency solver rather than dnf or apt; all three default to AppArmor rather than SELinux for mandatory access control; all three install a Btrfs root filesystem with snapper snapshots by default. Nothing about how you drive the machine changes between them. What changes is *when* a given package version reaches you and *who is accountable when it breaks*. ## openSUSE Tumbleweed — rolling Tumbleweed is a rolling release. Packages flow through the openSUSE Factory development project, and a snapshot is published to users only after it passes openQA, SUSE's automated installation and desktop test suite. There is no "next version": you never upgrade from one release to another, you simply stay current with the stream, and the supported way to do that is a distribution upgrade (`zypper dup`) rather than an ordinary package update, because packages are regularly renamed, split, merged or dropped. The upside is a current kernel, compiler and library set — Tumbleweed is a genuinely good developer workstation. The downsides are operational: a machine left untouched for months faces a large, riskier jump; occasional regressions do reach users; and you are expected to be able to recover, which is exactly why the Btrfs-plus-snapper rollback path is standard equipment on SUSE. ## openSUSE Leap — fixed release on the SLE core Leap is a conventional versioned distribution with point releases and a defined maintenance window per release. Since the 15 series its core is built from the same sources as SUSE Linux Enterprise, with community-maintained packages layered around that core. The practical consequence is that a Leap box behaves like a SLES box for the parts that matter — same kernel lineage, same core libraries, same layout, same tooling — without a subscription and without SUSE support. That makes Leap the usual free stand-in: lab machines, CI builders, staging environments that must resemble the SLES production fleet, and servers where stability matters but a support contract does not. ## SLES — the subscription product SUSE Linux Enterprise Server is the commercially supported edition. Two things follow from that, and both catch people out. First, **an unregistered SLES machine has no update repositories**. Registration against the SUSE Customer Center with `SUSEConnect` is what unlocks the maintenance repositories, plus the modules and extensions (the enterprise product is factored into modules you activate rather than one giant repository). A fresh SLES VM that "has no updates available" is almost always an unregistered one. Second, **the subscription is not a licence to run the code**. The source is open; what you buy is maintenance updates over a long lifecycle, certification (hardware vendors, and application vendors — SAP above all, which is why the SLES for SAP Applications variant exists and why SUSE is disproportionately common in European enterprise and SAP shops), and a vendor you can escalate an incident to. The enterprise lifecycle is organised as a major version plus Service Packs. You do not drift between service packs; you migrate deliberately on a registered system, and extended support for older service packs is a purchasable add-on rather than something that just continues. ## Choosing for a server ``` certified stack (SAP HANA), audit/compliance, vendor escalation -> SLES same shape, no subscription: internal servers, CI, staging -> Leap workstation, newest toolchain, upstream development -> Tumbleweed ``` The one answer that is close to always wrong is Tumbleweed under a production database or any long-lived stateful service. It moves under you, every update is a distribution upgrade, and the maintenance model assumes a human who updates often and can roll back. ## What the interviewer is checking They want to hear that you know these are one family and not three unrelated distributions, that you can name the release model of each in one sentence, and that you attach the right workload to each. The strong signal is knowing that registration gates SLES updates and that the subscription buys maintenance and certification rather than permission — that is the part only someone who has actually provisioned a SLES box tends to say.