Ask Lemmy

Because it's too flexible, and assumes everyone has source code to glue it all together. There's endless choices you can make to have a functional system.

• Before you even compile the kernel, you have to provide a C compiler. That can be GCC or LLVM/clang.
• Before you even build the kernel, you have to pick a CPU architecture and subsystems to enable.
• Before you can even boot the kernel in any useful manner, you need to select a partition table format, one or more filesystems to put on the drive, all with varying amounts of features, but are at least mostly all POSIX compliant. Or a ramdisk.
• Even just starting at the very core of userspace, the C standard library, you have glibc, musl, uClibc. That can only be dealt with at compile time.
• Then on top of that, for the core utilities, you have the GNU coreutils, uutils, busybox, toybox, the BSD coreutils.
• Great, we can start booting now. Wait, now there's the choice of init system: systemd, sysvinit, OpenRC, runit, upstart, dinit, and a lot more. Good, we're booted.
• Now we need a login prompt, which can be agetty, greetd, mingetty, GDM, SDDM, LightDM. You've entered your password: that may or may not trigger a PAM session, which can verify your password from just about anywhere (locally, Kerberos, LDAP), start a D-Bus session, register a session with logind, that can trigger decryption and mounting of a drive, which itself could be local or remote or removable.
• We're logged in! Now we need a shell. There's bash, dash, zsh, ash with their own small differences, and that's just the POSIX compatible ones. There's also fish, nu, ksh, csh and more.
• We have a prompt! Now we should probably install some software. Is it gonna be apt, yum/dnf, zipper, pacman, apk, xbps, emerge, port? What's the package names? Depends on the distro!
• We have a way to install software, now we need network to get it. How's the network configured? ifupdown, systemd-networkd, NetworkManager, Connman, dhclient, dhcpcd, netplan, netctl. If you have WiFi, there's iwd and wpa_supplicant.
• Lets get a graphical session. Xorg or Wayland based? ALSA, PulseAudio or PipeWire? Window manager or desktop environment?
• You want to mount a drive. systemd can do that, udev can do that, fstab can do that.

That's just the basics to make it to a desktop. Now there's some stuff to help that a lot, like Flatpak which aims to provide a known base system for apps to target. The portals help get access to resources with varying backends. PipeWire supports pretty much every audio protocol in existence so that's alright. Flatpak is a pretty good standard/ABI to target. For server software we have similar things in the form of Docker and Podman. But all of these solutions are basically "lets just ship the distro with the software".

The only really standard interface is the Linux kernel's public interface. If you're writing a driver, you better be ready to maintain it because stuff moves around a lot internally, the kernel doesn't care not to break out of tree modules. Go makes use of the stable kernel API and skips the libc entirely, so Go binaries are usually fairly portable as long as the kernel is somewhat sane.

The only real standard you can target is POSIX, which is fine if you're writing CLI or server software, but if you want to write GUIs, you just have to make choices. Most Linux stuff runs fine on FreeBSD too, they have Wayland, PipeWire and Mesa there too, so technically at this point you're not even targetting Linux per-se, more like generally POSIX-y systems with software that's just very commonly used and target that.

On Windows and Mac, you have what Microsoft/Apple provides and if you want anything else you bring it yourself. However, technically you can install PulseAudio on those, install an X server (Xming, Xquartz), run most DEs in there, run browsers and quite a bit of Linux-y stuff, natively on Windows and Mac in their respective binary formats.

The thing with FOSS is there isn't a single standard it targets, we just port everything to everything as needed. The closest thing we have to a standard is targeting specific versions of specific distros, usually Debian/Ubuntu or RHEL and derivatives because that's what the enterprise customers that pays for the development tends to run. That's why Davinci Resolve is a pain to run on anything other than Rocky Linux. Thankfully, it's also just software and dependencies, so if you just give it everything it uses from Rocky, it'll work just fine on other distros. And that's why source code is important: you can make everything work with everything with enough time and patience. That's what powers the ecosystem.