Het is helemaal prima dat er zoveel smaakjes zijn, dat is het idee van FOSS, maar het komt compatibiliteit niet ten goede.
Deze mythe is 10 jaar geleden al
ontkracht door iemand die er echt verstand van heeft.
ProtonDB staat bij zat games vol met tweaks die nodig zijn. Het zou toch tof zijn als game devs gewoon Proton op Steam OS kunnen targetten, zodat gamen op Linux in de toekomst een steeds betere optie blijft worden.
Proton op SteamOS functioneert exact hetzelfde als Proton in een installatie van Steam op een willekeurige andere Linux desktop, dus als op ProtonDB vermeld wordt dat er tweaks nodig zijn om een spel goed te laten draaien zijn die altijd nodig, of je nu SteamOS draait of niet. Het kan wel zijn dat andere versies van Proton, zoals bijvoorbeeld GE-Proton, al fixes of work-arounds ingebakken hebben waardoor de aanpassingen niet nodig zijn. Ik denk dat Linux desktop gebruikers eerder geneigd zijn zo'n alternatieve versie van Proton te installeren dan dat Steam Deck/SteamOS gebruikers dat zijn, maar het is op beide gewoon mogelijk.
Je kunt als software ontwikkelaar / leverancier niet "Een Linux build" maken.
Dat kan wel degelijk en gebeurd ook, zie de link naar de video eerder in mijn reactie. Dat betreft dan games, maar je ziet dit ook op enterprise niveau terug. Van software als DaVinci Resolve, Matlab, Mathematica of SAS worden echt niet verschillende versies gemaakt om op verschillende Linux distributies te draaien. Er is 1 binary die overal werkt en belangrijke libraries waar men van afhankelijk is worden meegeleverd in plaats van afhankelijk te zijn van de libraries op het systeem. Dit betekend dat je afhankelijkheden worden beperkt tot een minimale versie van de Linux kernel en de standaard C library.
Want voor welke package manager ga je het maken? apt, rpm, yum, dnf, snap, pacman, eopkg, nix, flatpak, zypp of npm? Ga je voor al die packages een build pipeline opzetten? Ga je voor al die packages door het proces om hem te laten goedkeuren en opnemen in de standaard repo's van de bijbehorende distributies?
Antwoord: "geen van allen" en dus "nee" op je vervolgvraag. Je lijkt een totaal verkeerd beeld te hebben van hoe package management onder Linux werkt. In de software repositories waar je door middel van de package manager op je systeem toegang toe hebt zit voornamelijk open source software, aangevuld met wat gesloten software van zeer algemeen nut, zoals bijvoorbeeld drivers en firmware. Van de open source software wordt door de beheerders van een distributie zelf de broncode gedownload, gecompileerd, een package gebouwd en vervolgens wordt deze getest met de rest van de distributie. Als ISV heb je daar in principe niets mee te maken, je kunt als 3e partij bijvoorbeeld niet een
.deb package aanleveren voor in de repositories van Debian of Ubuntu. Soms gebeurd het wel dat de maker van een stukje software als extra service een repository met zijn tool opzet voor een aantal populaire distributies, maar als game developer of maker van enterprise software zou ik daar niet aan beginnen en gewoon een tarball leveren met alles er in.