Why Debian and Ubuntu split

Why Debian and Ubuntu split

Debian and Ubuntu split in 2004 over the calendar, not over the code. Debian ships a stable release when its release team judges it ready. Ubuntu promised a new release every six months on a date fixed in advance, so it takes a copy of Debian's development branch, freezes it, repairs what is broken, and ships.

Twenty-two years later the two still share the package format and the tools that manage it, and most of the packaging work behind them is one job done once. What they do not share is a schedule, a support contract, or one opinion about what belongs in a default install. That is the useful distinction when you are choosing an operating system for a server, because it separates the differences that are cosmetic from the ones that cost you an afternoon.

Where Ubuntu came from

Ian Murdock founded the Debian Project on 16 August 1993. By 2004 Debian was the largest volunteer-run distribution in existence, and it was slow. Debian 3.0 "woody" was released on 19 July 2002, and its successor, Debian 3.1 "sarge", did not arrive until 6 June 2005. Nearly three years passed between two stable releases. During that gap, anyone who wanted current software on a Debian server had no supported answer from Debian itself.

In April 2004 Mark Shuttleworth invited about a dozen Debian developers to his flat in London to plan a Debian-based system on a fixed schedule, and he founded Canonical Ltd to employ them. The first release, Ubuntu 4.10 "Warty Warthog", arrived six months later on 20 October 2004. The version number is the release date: 4.10 means October 2004, and 26.04 means April 2026.

Ubuntu was never a fork in the ordinary sense. A fork copies a codebase once and then walks away from the original. Ubuntu copies Debian again every cycle. Packages are taken from Debian unstable, the rolling branch Debian calls sid, and that copy is refreshed automatically through the early weeks of each Ubuntu cycle. After the import freeze, an Ubuntu developer has to pull each further package across by hand and justify it against the freeze rules. The wider family tree of Linux distributions holds plenty of real forks. This is not one. It is a permanent downstream.

What the two projects still share

The shared part is much larger than the different part. Both use the .deb package format with dpkg underneath and apt on top, and both follow Debian Policy for where files land and how packages declare their dependencies. Ubuntu's own developer documentation puts the overlap at roughly four in five source packages copied from Debian with no modification at all. A maintainer fixing a bug in Debian is fixing it for Ubuntu users too, usually without either side noticing.

Where Ubuntu does change a package, the version string says so. Debian's 1.2.3-4 becomes 1.2.3-4ubuntu1, and that suffix marks the local change, which both projects call the delta. Ubuntu publishes the full delta for every package it touches and forwards patches to Debian's package tracking system, so a Debian maintainer can see what the downstream did and take it if they want it.

Whether that is enough has been argued since 2005, and the argument is worth stating plainly rather than taking a side on. From Debian's side, the complaint is about where the effort lands: Canonical pays people to work downstream, the downstream collects the users and the attention, and pushing a fix back upstream is extra work that nobody is paid to do. From Ubuntu's side, a six-month deadline does not fit a project that has no deadline, so waiting for Debian is not always an option. Both statements are true. Neither has ever stopped the packages from flowing.

Release when ready, against a date on the calendar

Debian's release date is an outcome, not a promise. Debian 12 "bookworm" was released on 10 June 2023 and Debian 13 "trixie" on 9 August 2025, roughly two years apart, but nothing guarantees the next gap will match. The current testing branch is called "forky" and has no release date, because Debian does not announce one until the release-critical bug count says it can.

Ubuntu's date is the promise. A release lands every six months, and every fourth one, in April of an even-numbered year, is an LTS (long term support) release. Ubuntu 26.04 LTS "Resolute Raccoon" was released on 23 April 2026, on schedule. The releases in between are interim releases and carry only nine months of updates, which is why they do not belong on a server you would rather not rebuild twice a year. The choice between Ubuntu LTS and interim releases on a server comes down to that nine month number.

The cadence sets your upgrade calendar, and this is the most practical consequence of the split. On Ubuntu LTS you know years in advance that your next in-place upgrade lands in April of an even year, so the upgrade from Ubuntu 24.04 to 26.04 could be planned before 26.04 existed. On Debian you watch the freeze announcements and schedule the work when the release actually happens.

What LTS changed

Ubuntu 6.06 LTS "Dapper Drake" was released on 1 June 2006, and it was the first LTS. Before it, Ubuntu was a fast-moving system that replaced itself twice a year, which is not something a business builds a production server on. LTS did one thing that mattered: it put a support end date in the future, far enough out that a plan could be built around it. That is the change that made Ubuntu the default server distribution, and the six-month cadence is what feeds it, because each LTS is assembled from work already shaken out in the interim releases before it.

Debian reached the same place from the other direction. Its stable release already moved slowly, and the Debian LTS project extended the supported life of each one after Debian's own security team steps back.

Who supports you, and for how long

[
  {
    "label": "Debian stable",
    "support_duration": 3
  },
  {
    "label": "Debian LTS",
    "support_duration": 5
  },
  {
    "label": "Debian ELTS, paid",
    "support_duration": 10
  },
  {
    "label": "Ubuntu LTS",
    "support_duration": 5
  },
  {
    "label": "Ubuntu Pro ESM",
    "support_duration": 10
  },
  {
    "label": "Ubuntu Pro plus Legacy",
    "support_duration": 15
  }
]

Debian's own security team covers a stable release for 3 years. After that the Debian LTS team, which Debian describes as a group of volunteers and companies rather than its official security and release teams, carries it to 5 years. The handover is visible in the current dates: bookworm entered LTS on 11 June 2026 and is covered to 30 June 2028, and bullseye reaches the end of its LTS period on 31 August 2026. Past that point Freexian sells Extended LTS, or ELTS, to 10 years, and only for the subset of packages its paying customers actually use.

An Ubuntu LTS gets 5 years of standard security maintenance from Canonical. An Ubuntu Pro subscription raises that to 10 years through ESM (expanded security maintenance), across both main and universe, and the Legacy add-on takes it to 15. As of August 2026 Ubuntu Pro is free for personal use on up to five machines, so on a single VPS the ten-year figure is real without a purchase order. Pro also carries the livepatch service, which is the supported route to live kernel patching on a VPS without a reboot for every kernel security update.

The structure behind those numbers matters more than the numbers. With Ubuntu you buy support from the same company that builds the distribution. With Debian no such company exists, so paid support comes from a third party such as Freexian, from your hosting provider, or from your own team.

Init systems, and the vote that ended the argument

The sharpest technical divergence was the init system, the first process the kernel starts and the supervisor of every service after it. Ubuntu 6.10 "Edgy Eft", released on 26 October 2006, shipped Upstart, which was written at Canonical. Debian stayed on sysvinit for years while the argument ran. Debian's Technical Committee settled it with a vote that concluded on 11 February 2014, decided by the chair's casting vote in favour of systemd for Debian 8.

Ubuntu followed within days. Shuttleworth's post about the decision, titled "Losing graciously", gave the reason plainly: Ubuntu is centrally a member of the Debian family, so it would adopt the outcome. Ubuntu 15.04 shipped systemd by default on 23 April 2015, and Debian 8 "jessie" did the same on 26 April 2015, three days later.

That convergence is why most service tutorials move between the two without edits. Unit files, systemctl and journalctl behave the same on both. Debian 13 ships systemd 257 and Ubuntu 26.04 LTS ships systemd 259, so what separates them there is a version number, not a design.

Snap, and the part that does not port

Ubuntu 16.04 LTS introduced snap packages in 2016, and 18.04 was the first release to deliver some default applications as snaps. A snap is a self-contained bundle that carries its own copy of its dependencies, so an upstream project can push a new version to every supported Ubuntu release at once instead of waiting for the archive to catch up.

The reason no other major distribution adopted snaps as a default is not the format. The snapd client talks to one store, operated by Canonical, and the server side of that store is not open source. A distribution that adopts snaps therefore hands part of its software distribution to another vendor. Debian did not, and it does not install snapd by default.

This is where upstream instructions quietly stop working. Certbot is the clearest example: its own documentation recommends installing from a snap and warns that distribution packages "tend to rapidly fall out of date on LTS-style distributions". Follow that page on Ubuntu and it works. Follow it on a stock Debian server and the very first step has nothing to run it. Our own Certbot guide for Nginx on Ubuntu 24.04 uses the distribution package for that reason.

Kernels, firmware and the non-free question

Debian's Social Contract and the DFSG (Debian free software guidelines) define what may enter main. Everything else goes to contrib and non-free, and for most of Debian's life that included the binary firmware blobs ordinary network and storage hardware needs before it will work. After a General Resolution in 2022, Debian 12 added a separate non-free-firmware archive area, and official installer images have carried that firmware since.

Ubuntu made the opposite call on day one. Its archive splits into main and restricted, which Canonical supports and which includes proprietary drivers, plus universe and multiverse, which are community-maintained. On a VPS the effect is small, because virtual hardware needs almost no firmware. On dedicated hardware it is the difference between a network card that comes up and one that does not.

Kernels diverge on the same axis. As of August 2026, Ubuntu 26.04 LTS ships Linux 7.0 and Debian 13 ships Linux 6.12. Ubuntu also moves the kernel forward inside a single LTS through its hardware enablement stacks, while Debian holds one kernel series for the life of a stable release and offers newer ones through backports. Newer means better support for recent virtio devices and filesystems. Older means the behaviour you tested in January is still the behaviour you get in December.

What breaks when you follow instructions for the other one

Most of the time, a guide written for one works on the other. The failures cluster in a few known places.

• Third-party apt repositories are published per distribution and per codename. A vendor that supports noble and jammy may publish nothing for trixie, and the failure looks like a network fault rather than a policy decision.
• Launchpad PPAs build against specific Ubuntu series only. Adding one to Debian pulls binaries linked against Ubuntu's library versions, which either works by luck or drags a large part of Ubuntu's runtime onto your system.
• Anything that assumes snapd, an Ubuntu Pro subscription, or Canonical's livepatch has no Debian equivalent step, so those sections of a guide have to be replaced rather than adapted.
• Default images differ in who you log in as. Ubuntu images usually give you an ubuntu user with sudo and no root password, Debian images usually give you a debian user, and provider images vary. Check yours before you change anything about SSH.

When a repository has no suite for your release, apt is specific about it:

E: The repository 'https://download.example.com/linux/debian forky Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.

That message means the vendor never published packages for your codename. The mirror is not broken and a retry will not fix it. Either the vendor supports your release or it does not.

So which one should you run?

Take Ubuntu LTS when you want an upgrade date you can put in a calendar years ahead, and one vendor you can buy support from. Take Debian stable when you want a smaller default install with no single company in the path, and a base that changes slowly enough to be boring.

Everything else transfers. Both use apt, both follow Debian Policy, and both run the same applications from the same package format, so the skills move with you. If you are arriving from Red Hat or Fedora instead, the dnf and apt command equivalents cover the translation in both directions. And if you are weighing these two against the other images available at deploy time, our guide to picking an operating system for your VPS puts them next to the rest of the list.

FAQ

Is Ubuntu a fork of Debian?

No. A fork copies a codebase once and maintains it separately from then on. Ubuntu re-imports from Debian unstable at the start of every six-month cycle, and Ubuntu's developer documentation puts the share of source packages copied with no modification at roughly four in five. Ubuntu is a permanent downstream of Debian, which is why Debian packaging knowledge transfers to Ubuntu unchanged, and why a fix made in Debian usually reaches Ubuntu users without anyone doing extra work.

Do Ubuntu tutorials work on Debian?

Usually, and the exceptions are predictable. Both use apt, both use systemd, and both follow Debian Policy, so package management and service management match. What breaks is anything tied to Canonical's infrastructure: snap-based install steps, Launchpad PPAs, Ubuntu Pro commands, and third-party apt repositories that publish only for Ubuntu codenames. When a repository has no suite for your release, apt reports that it "does not have a Release file", which means the vendor never built for your codename.

How long do Debian and Ubuntu security updates last?

An Ubuntu LTS gets 5 years of standard security maintenance from Canonical, 10 with an Ubuntu Pro subscription, and up to 15 with the Legacy add-on. A Debian stable release gets 3 years from Debian's security team and 5 years including the LTS period that follows. Freexian's paid Extended LTS reaches 10 years, but only for the packages its customers request.

Which is better for a server, Debian or Ubuntu?

Neither is better in general, and the honest split is about schedule and support. Ubuntu LTS suits a server where the upgrade date has to be predictable and where support must be purchasable from a single vendor. Debian stable suits a server where a smaller default install and a slower rate of change are worth more than a fixed calendar. They run the same software from the same package format, so the choice does not limit what you can host.