This updated article was originally published on 2022-06-04.
Today, I approach the question of which Linux distro – Debian vs Ubuntu Server – to deploy on servers? I’ve setup and deployed tons of Linux servers over the years. Many of the servers I deploy are on very small / inexpensive cloud instances – servers with 1 to 2GB of system memory – which weighs heavily into my short list of reasons why I prefer to deploy Debian as my Linux distro of choice on new servers.
Valid Reasons To Choose Ubuntu
Before I get into my reasons for choosing Debian, let me start by mentioning that there are very valid reasons that you might choose to deploy Ubuntu instead of Debian. The point of this article is not to dump all over Ubuntu. I’m not a Linux elitist. There is no one perfect Linux distribution. People who prefer Arch or Ubuntu or Fedora or whatever is fine by me – though, starting a Linux fanboy war would be great for post engagement, that’s not my goal here. I’m happy with people using Linux – period.
With that said, let’s briefly explore why someone might choose Ubuntu Server.
Predictable Software Lifecycle
From the very beginning, Ubuntu has had a very predictable software lifecycle. With one exception in 2006 where a release was pushed back 2 months, Canonical puts out a new release of Ubuntu every April and October with a 9 month support window and LTS versions every two years with 3 years of desktop and 5 years of server support. You always know when to expect the release and you know how long you can run it. In the business world, having this predictable schedule is important for long term planning.
Paid Support From Canonical
Another extremely valid reason to choose Ubuntu over Debian is the availability of paid support from Canonical. The corporate IT world lives and breathes on support contracts. Having this level of support available makes the business decision of choosing Ubuntu make perfect sense.
Now, for the servers I deploy and the way I deploy them, I don’t need a predictable release cycle and I don’t need paid support. What I do care about when deciding between Debian vs Ubuntu Server is …
#4 – Stability Over Newest Features
When you get Linux people talking about Linux – and boy do Linux people love talking about Linux – words you’ll often see mentioned regarding Debian include:
Debian has been around a LONG time – well long in technology terms anyway. The first release came out in September 1993. Few Linux distributions can claim that kind of longevity. Over that time, Debian’s philosophy of releasing when the bugs are worked out instead of based on a hard release date has earned it this reputation.
The emphasis on bug free / stable software means that the packages included with Debian are usually not the most current versions available. For example, while PHP is up to version 8.2 at the time of writing, the current Debian release (version 12) includes version 8.1 and will continue to do so until Debian 13 is released. While it’s not always desirable in the desktop world to be missing out on the latest features, in the server world security and stability are paramount.
Other software developers benefit, as well, from the stability that Debian provides. For example, the current recommended version of PHP for WordPress is version 7.4. This recommendation tracks behind the current Debian release. By recommending the more mature version, WordPress developers have additional time to test and fix software bugs that might appear with the newer PHP versions. By the time Debian updates their PHP version, there’s a far lesser chance of there being an incompatibility
#3 – Zero Reliance On Snap Packages
While you can easily add support for Canonical’s snap package format to Debian, it doesn’t include it out of the box – which suits me just fine. There’s a lot of, let’s use the word dislike, in the Linux community for snap packages.
I’m not much of a fan of snaps myself, but I will use them when absolutely required. Thankfully, snaps aren’t often found on servers. The notable exceptions to this that come to mind are Canonical’s LXD virtualization / containerization system – which I will admit I actually like and use quite a bit – and Nextcloud. Both are available to install as a snap package.
Could this change at some point in the future, though, as Canonical is said to be releasing an official snap-only version of Ubuntu – called Ubuntu Core Desktop – with the 24.04 release cycle? It’s clear that Canonical is trying hard to push adoption of the package format. At some point I won’t be shocked if they try to push it further into the server space as well.
With that said, the main issues people tend to have with snaps are that they start slowly and often use more system memory than their non-snap counterparts.
Conversely, Ubuntu Server comes preconfigured with snap support. If you’re not actually using it on your server, you can save yourself some system memory by removing it from your system.
#2 – Community vs Corporate Control
As of July 2023, there’s been a great deal of discussion going on in the Linux community on this very topic and I’ve felt it was important to update this article to reflect how important this topic has become for some – myself included.
IBM / RedHat Controversies
If you’re reading this in the future and don’t know what’s events I’m referring to, IBM / RedHat have stirred up a hornet’s nest with their announced change to their stance on making the code to RedHat Enterprise Linux (RHEL) freely available as has been customary since RedHat was founded in 1993.
This isn’t the first time that IBM / RedHat has stirred the ire of the greater community. Following RedHat’s acquisition by IBM, RedHat brought the previously community driven CentOS project – which was a 1:1 bug compatible fork of RHEL – under their control. Once this was done, the distro was rebranded to CentOS Stream and was no-longer a RHEL clone.
Predictably, this caused an uproar that resulted in the creation of two new RHEL clones – Almalinux and Rocky Linux – whose goals were to fill the void left by the loss of CentOS.
It’s absolutely clear that the goal of IBM / RedHat’s change to source code availability is attempt to cause an end to RHEL compatible distros, which effects not just Almalinux and Rocky Linux but Amazon Linux and Oracle Linux as well.
I’m not going to dive into all of the minutia of details on this matter as there’s PLENTY of material out there on the subject already. I’ll link to a few videos, below, for those who want to know more. If you haven’t already, I highly encourage you to watch them.
- Jeff Geerling – Huge Open Source Drama
- Learn Linux TV – Why Corporate Owned Linux Distributions are a Bad Idea
- Veronica Explains – Red Hat: why I’m going all in on community-driven Linux distros
How This Relates To Debian vs Ubuntu Server
The point to bringing up the controversies regarding IBM / RedHat is to illustrate how a corporate controlled Linux distribution isn’t necessarily looking out for the best interests of their users or the community but are always looking out for their own interests.
An obvious example of how this is apparent regarding Canonical is their aforementioned persistence on pushing snap packages when the community has largely spoken out in favor of alternatives such as Flatpak – a competing package format that is distro independent and is developed by the community.
Even more relevant is the fact that Canonical – hot on the heels of the current RedHat controversy – has announced that they’ve taken over control of the development of LXD containerization software away from the LinuxContainers project – a community based organization. LXD was originally created by Canonical and is built on top of LXC but then turned control over the development to the community while employing developers to work on the project.
This move to retake control over the project has prompted the lead LXD developer – a Canonical employee of 12 years – to resign from Canonical, stating:
“As I’ve told colleagues and upper management, Canonical isn’t the company I excitedly joined back in 2011 and it’s not a company that I would want to join today, therefore it shouldn’t be a company that I keep working for either,”Stéphane Graber
Admittedly, this isn’t nearly as egregious as what RedHat has done but it doesn’t do anything to help engender a feeling of trust with the community at a time when people are considering whether they’ll continue to use RHEL – or any RedHat affiliated distros – in their systems.
Like others in the community, I cannot in good conscience choose a Linux distro that I feel doesn’t always respect the larger open-source community that it was born from. To that end, Debian has been a community developed project since its inception in 1993 and continues that legacy to this day.
#1 – Debian Uses Less Memory
This is where this discussion gets a bit more objective – while everything I’ve previously mentioned was 100% subjective. I’m about to throw some hard data at you to back up my #1 reason to use Debian over Ubuntu Server. Debian uses less memory than Ubuntu.
Simply put, on fresh OS installs, Debian uses less system memory. On larger systems the difference is small enough to not matter much. However, when it comes to small cloud servers, virtual machines, and containers the difference can be substantial.
For my first test, I created a virtual machine using KVM/QEMU with a single CPU and 1GB of memory – a common configuration found on inexpensive cloud servers and then installed both Ubuntu and Debian. The default Ubuntu Server 22.04 ISO was used for Ubuntu and the Debian 11 Netinst ISO was used for Debian. All tests were performed when this article was originally published – hence the now outdated versions.
Let’s start by looking at Ubuntu. During the install I chose the minimized option that is available in 22.04. The only additional software that I installed was SSH, for remote access to the VM, and htop, for checking the system resources. Total memory being used by the system is 153MB out of 971MB reported as available – almost 16% of the total RAM and we don’t even have any applications installed yet.
To help Ubuntu, I decided to remove snap support from the system. Total memory use decreased by 6MB down to 147MB. This is still a little over 15% of the total memory.
Let’s compare, now, against a fresh Debian installation. Again, the only additional software installed is SSH and htop. Here you see that Debian is using just 67MB of 976MB – just under 7% of the total system memory. Notice also that Debian makes 5MB more of the total VM memory available for use than Ubuntu does.
Having the additional 8 – 9% of the total system RAM available is significant – especially if you are looking to maximize the number of VMs you can run on a server. Twenty Ubuntu based VMs without snapd would need 2940MB of memory just for the base operating system compared to 1340MB with Debian. In fact, forty Debian based VMs would still use less memory – only 2680MB.
To hammer the point home, I thought it worth exploring whether this held true if you used Debian vs Ubuntu Linux container images. For this test, I created two LXD containers – one with Debian 11, the other Ubuntu 22.04 – using the same profile where each container is limited to 1GB of memory. The Ubuntu container already included htop, whereas I had to install it manually in the Debian container.
This comparison takes the kernel differences between the two distros out of the picture entirely, as the host system kernel is being utilized by each container.
Starting again with Ubuntu Server we see the container is using about 90MB of memory. I didn’t bother with a second screenshot, but we can again save about 6MB by removing snap from the system – if needed. Going forward in this comparison we’ll use 84MB as the value to represent the Ubuntu container – 8.8% of the container’s memory.
Compare this with the mere 18MB that the Debian container uses – just 1.9% of the container’s total memory and 66MB less than Ubuntu.
In short, if memory utilization is important, Debian is the better choice over Ubuntu Server.
Which Would YOU Choose?
Debian vs Ubuntu Server – which would you choose? Would you use neither and go with something else entirely? Tell me what you think in the comments below.
If you found this article helpful and would like to support our efforts to create additional resources like this, please consider making a donation. Your support is greatly appreciated!
If you can’t make a donation, please consider sharing this article with others who may be interested. If you have questions about anything regarding this article, please be sure to leave them in the comments below. Thanks for reading, and I hope you visit again soon!