It's just the default target. For backend stuff, you're right that there's really very little true value. But client software just has a lot of complexity. If you run binaries from wherever, they're probably built and tested on Ubuntu first. Like, your vendors won't support distros officially, install scripts and AppImage integrations are going to tend to assume stuff. Driver/runtime integration for things like binary GPU stacks are going to document Ubuntu first. If someone makes an assumption about Python version (a personal peeve -- LOTS of python software ends up lagging the tip, it's not a super compatible ecosystem), it's going to be that you're running Ubuntu LTS version "one before latest", etc...

Are those fatal flaws? No. But lots of people just don't want to deal with it. And there's a market for that.

▲

jasomill 11 hours ago | parent [-]

I can't think of anything I've ever had trouble running on Fedora + containers, with the latter typically for proprietary software that depends on specific or ancient userlands, or simply to avoid cluttering up my base system.

	▲	ajross 9 hours ago \| parent [-]
		You can't put a driver stack in a container. You can't put container stacks (c.f. Docker, Snap, Steam, Flatpak) in a container. Containers can't by default do oddball hardware access for oddball stuff like flashing firmware for your keyboard or 3D printer. You can't reflash your motherboard BIOS from a container. The fact that your mental model of running your foreign Ubuntu software is "in containers" tells me you're probably mostly running backend/cloudy stuff. And yeah, that's largely a solved problem thanks to Docker (and for the same reason, "Dockerfile" is now a standard platform that everyone integrates and documents for by default). Again, it's not like this can't be done from other distros, it's that it's fiddly and the instructions and defaults are all going to be for Ubuntu LTS.