One of the great controversies in the open source world is manufacturers who supply closed source drivers for their devices for open source operating systems like Linux. Debian uses the term “firmware” to describe these drivers and Debian, more than almost any other Linux distribution out there, prides itself on a firm policy of “officially” denying support of non-free firmware. In actual reality, the files required can easily be found in Debian repositories and support sites. Nevertheless, Debian is almost unique in supplying a kernel that is “deblobbed”, which means binary-only “blobs”, or closed source firmware, is stripped from the kernel when it is compiled for distribution in a Debian release. Re-adding the firmware is, however, fairly straightforward for end users who need it for hardware support in their systems.
Debian’s strict stance sets it apart from most distributions and has cost it considerable support because other similar distributions like Ubuntu have taken a more pragmatic viewpoint and shipped kernels with the support included and with installers that can download the firmware automatically as needed. The dropping level of support for Debian is felt in other ways, the most obvious of which from my perspective is a significant falling behind in compatibility with UEFI mainboards. This is difficult to measure as there are so many different boards out there, but I am writing this post on a computer running a Gigabyte GA-E350 board which has an AMD E350 onboard CPU with Radeon R600 graphics. These boards were first released around 2012 and there were several different models produced, so it’s an older design. Because it offered UEFI install I decided to try setting up Debian with this which proved to be impossible to happen. But also, the Debian installer, which is able to download everything for installation, won’t download firmware that the installation needs, so at reboot you end up with a system that needs extra work (I got to this after changing to a Bios mode install which this old board supports).
Now as is clear from other recent posts I had the experience of having to install the testing edition of Debian in order to get support for UEFI installations on particular hardware configurations that I have. This is because Debian has significantly fallen behind in implementing UEFI support. For example, the UEFI spec includes SecureBoot. This is not something I have needed to use myself, but it is a component of the UEFI spec. It turns out that SecureBoot was implemented in Ubuntu as far back as the 12.04 release from 2012, and in Fedora, it came out in around 2013, so these are examples of leading distributions that are ahead in UEFI support compared to Debian, which didn’t support SecureBoot until 2019 in the buster release. Examples like this simply make Debian, which is the second oldest mainstream distribution in the history of Linux (it will reach its 30th anniversary next year) look old and tired.
So what comes next? Kubuntu 20.04 installed on the same system flawlessly without any problems whatsoever including UEFI. There are a few issues naturally with it; hibernation isn’t enabled out of the box (which I’ll cover in a subsequent post). But overall this means that for one of my bookworm systems which is currently freezing a lot, I’ll be looking to move that to Kubuntu as soon as 22.04 LTS is released next month. Then I’ll see if longterm migration of systems to various Ubuntus might be preferable.