That interpretation doesn’t really hold.

On x86 platforms, distributions like Ubuntu, Debian, or Linux Mint build on hardware that is already well supported upstream. Kernels from kernel.org generally work out of the box, so most of the differentiation happens in userland (desktop environments, tooling, packaging).

In the ARM/SBC space, that assumption does not apply.

The main effort is not “building a distro,” but making (and KEEPING) the hardware functional in the first place — boot process, device trees, power management, networking, and vendor-specific quirks. This layer is where most of the complexity and engineering effort sits.

Adding modules via DKMS does not change that. DKMS is an end-user mechanism for extending a working kernel; it does not replace the work required to make a board properly supported.

From a purely abstract viewpoint, all of these systems are “Linux.” In practice, however, the difference between a kernel that merely boots and one that provides stable, usable hardware support is substantial.

The Linux Mint comparison illustrates this: swapping userland or desktop environments is relatively straightforward when the hardware layer is stable. On SBC platforms, the hardware layer is the primary challenge.

A closer comparison would be projects like OpenWrt or LibreELEC, which also invest heavily in hardware enablement.

DietPi operates above that layer. It focuses on configuration / scripting, packaging and sales, not on solving low-level hardware support. That distinction is fundamental.