@glyph this aligns well with something I was thinking about last night. Someone on here trying to relitigate "actually Linux is just a kernel GNU/Linux is the operating system" again, but imo there's no operating system called GNU/Linux that you can just install on your computer, it's a family of operating systems that have names like "Debian" and "GUIX" that are mutually incompatible with one another, which makes "porting to Linux" a nightmare.

@aeva @glyph family of operating systems that share the same underlying kernel and userspace.

* Distributions have specific patch sets, it's not the exact same. there's multiple "channels" too, like LTS but for the most part the kernel functionality remains relatively the same

** not every distro uses glibc, polkit, dbus but a majority of them do and you can pretty much expect a majority of them to.

the only reason i say this is not because I'm a linux truther it's just i had this broken perception of *BSD. I thought that FreeBSD, OpenBSD, NetBSD were more or less distributions that package around a "BSD" kernel. In reality they have wildly different features. OpenBSD does not support freebsd jails and while at some point there was a common ancestor (386BSD) they kinda drifted away over time to the point that it's not the same thing. I can more or less assume that most distributions support features like cgroups, namespaces and so on (useful for containerized environments and just process isolation).

@aeva @puppygirlhornypost2 right, even to the extent that one could, with a truly unreasonable investment of effort, make a "linux version" of some software, there's a vast gulf between trying to do that for a server-side thing that mostly runs in Docker and exists in a highly abstract computation space, something that integrates tightly with server-side stuff like systemd, and then something that actually makes pictures and sounds on a "desktop"

@aeva @puppygirlhornypost2 @glyph

the linux model was built on, well, the distribution distributes, developers give source and a packager has the job of building it and providing all auxiliary files (i.e. init system definitions)

that gets lost with proprietary apps or people that want to "port" to linux as a whole

you mostly can make a game for "linux" though, the syscall interface is stable (honestly, one of the few things that truly is), so a statically linked binary will run everywhere, but that requires your engine to work like that and i don't think many do

@navi @puppygirlhornypost2 @aeva “porting to linux” is not a nightmare at all. it’s actually very easy. what is not so easy is targeting linux systems with proprietary software.

there’s no longer just x86 to worry about either. sure, there’s FEX to emulate it on aarch64, but come on… you’re installing a compatibility OS root for a different arch, then run steam, which you realize doesn’t work reliably on modern file systems without hacks because valve forgot to compile half their stuff with the right glibc options, and which itself uses another distro’s packaged user space, and THEN you run proton which implements windows user space?

how many more layers are we going to stack just to avoid publishing the source code? all this is making preservation unreasonably difficult as well. even if we’re completely ignoring linux, none of this will keep working on future operating systems.

@mia @navi @puppygirlhornypost2 no, it is actually hard. I literally cannot build my main project (open source, built on a small set of open source dependencies, built for Liunx trying to avoid as many pitfalls as possible) on my laptop and run it on my desktop because one is running fedora and the other is an ubuntu LTS running an incompatible glibc. I literally cannot cross compile from Linux to Linux running on the same CPU architecture. This is an absolute clown show.

@mia @puppygirlhornypost2 @navi @aeva There never was just x86 to worry about. Intel 8086/80186/80286 (16 bit LE) and 80386 onwards (32 bit LE), Motorola 68000 (16/32 bit BE), PDP-11 (16 bit LE), PDP-8 (12 bit), PDP-10 (36 bit), VAX-11 (32 bit LE), POWER and PowerPC (32/64 bit BE)... I've probably forgotten a few common architectures in there. A few minor ones like the Z8000 (16 bit) and DEC Alpha. Unix evolved dealing with THAT mess, and Linux inherited that.

@tknarr @puppygirlhornypost2 @navi @aeva well, yeah. but for a while x86 was the only mainstream desktop linux architecture that you’d have to care about as a game publisher. aside from small niche archs like POWER (which is sometimes less of a “just recompile” issue and might actually need code changes) there’s a growing number of aarch64 macs running linux now (unsurprising with how terrible the laptop market is, and with a small number of macOS users switching to linux as well) so that might be changing

@mia @puppygirlhornypost2 @navi @aeva Only for a very short window, thankfully. But it was mostly illusory, helped by the fact most Linux distributions during that time tracked latest stable on their software and users were knowledgeable enough to install multiple versions of libraries as needed or games were staticly linked to avoid DLL Hell. Then static linking became unpopular, LTS versions exacerbated DLL version issues and users forgot how to deal with multiple library versions.

@tknarr @puppygirlhornypost2 @navi @aeva the last time i ran into a library problem of sorts with a closed-source game (corpse party) it was because the game used steam’s API for achievement tracking (no DRM) but crashed immediately when steam wasn’t available. of course that was reported but never fixed because everyone who worked on that title has left or got laid off

steam also subtly changed api behavior in the meantime, so that release is broken for steam users as well, and the same problem may have happened on windows as well

in this case all it took was a replacement .so with stub functions, but with less luck it could’ve been a month of staring at ghidra just to get it to run

@puppygirlhornypost2 @navi @aeva @tknarr so yeah i would very much like for gamedevs to get a clue and start working with the system instead of working against it and then complaining that everything is too hard

@mia @puppygirlhornypost2 @navi @tknarr rude

@aeva @puppygirlhornypost2 @navi @tknarr well, hearing the same “doctor it hurts if i do this” type complaints does get old after 20+ years

pretty sure past me would’ve been dropping slurs at this point so if anything i’m showing tremendous restraint ​​

@mia @puppygirlhornypost2 @navi @tknarr charming

@aeva @puppygirlhornypost2 @navi missing the point. that has nothing to do with porting. if porting were a nightmare you would not be able to compile it on the other machine. if you have the source, none of this is a problem.

@aeva @mia @navi @puppygirlhornypost2 The glibc thing should be handleable by installing the needed version of the library. The only headache is if glibc's one of those that does breaking changes on minor version increments, that needs perverted things done to the symlinks to make it work seamlessly. I'd've expected the filesystem layout differences to be a bigger problem.

@mia @puppygirlhornypost2 @navi I think, if you actually read my reply, you would have understood that I do have the source code to everything I am working with.

@aeva @puppygirlhornypost2 @navi i understand you just fine. but you aren’t using the source code. you build it on one system, then treat the result like a closed-source binary on the other.

@mia @puppygirlhornypost2 @navi ah, ok - so I'm understanding your meaning correctly, your point of view is that one shouldn't provide prebuilt binaries for linux *ever* even when the full source code is available, and that distro package managers distributing prebuilt binaries is essentially an implementation detail?

@glyph @aeva sound is the scary one. JACK, pulse and pipewire come to mind. at least there are things like OpenGL for graphics, but I don't think there's a unified cross-platform audio library that abstracts over software + hardware mixing. Even if there was... I mean, software and hardware mixing are two different things, even if you don't actually know what the difference is.

@glyph @puppygirlhornypost2 side note, this straw poll informed my current thinking of how best to do the thing: https://mastodon.gamedev.place/@aeva/111880256412614427

I used to think that authoring a guix or nix package would be desirable, because guix and nix can be installed cooperatively on whichever distro and let me pretend Linux is a real platform. But that was what people wanted *the least*

@aeva @puppygirlhornypost2 oh wow, oh jeez. I have a lot of hypotheses about why this might have shaken out the way it did but I want someone to do a whole ethnographic study on this

@aeva @glyph @puppygirlhornypost2 just as an aside, getting nix installed on an immutable distro (bazzite in my case) involves a fair amount of distrobox wrangling in my experience.

@cthos @glyph @puppygirlhornypost2 oof I didn't think about that. I don't really have a good read on how popular immutable distros are or whether they're likely to be the standard at some point in the future.

@aeva @cthos @puppygirlhornypost2 FWIW the _massive_ improvement to reliability when macOS added SIP suggests to me that immutable distros are definitely the future

@aeva @glyph @puppygirlhornypost2 I know Silverblue tracks installs by default (unless you disable that option) so there are probably some numbers floating around. I also don't know how popular they are but I've been very happy with how "me-proof" Bazzite has been.

@glyph @cthos @puppygirlhornypost2 well, I'm open minded to the concept, I'm just mostly unfamiliar with it.

@puppygirlhornypost2 @aeva "OpenGL" is not sufficient for…graphics

@puppygirlhornypost2 @aeva like even forgetting for the moment that OpenGL is deprecated and Vulkan doesn't work yet, you still have to worry about distinctions like Wayland vs. X11, different compositor capabilities, different GPU drivers. Personally my "linux desktop" experience is just trying to make a desk accessory type thing that isn't even a video game, and it has been *maddeningly* difficult.

@glyph @puppygirlhornypost2 Apple deprecated OpenGL, but I'm not aware of any other implementer formally deprecating it, nor has the Khronos group.

I'm intending on targeting OpenGL ES2 for my side projects for the foreseeable future because it is adequate for my current projects, and it has the broadest portability reach between quality driver support and availability of compatibility layers. This is also a vote of no confidence on my part regarding the near future.

@glyph @puppygirlhornypost2 developing for wayland is "fun" because you can and will experience all of the joys of mutually incompatible platform conventions without having to actually run multiple linux distributions

@aeva @puppygirlhornypost2 sorry, was being a bit hyperbolic there. Apple's "deprecation" has had zero teeth because there's just way too much software using it, there isn't another cross-platform option at that layer. and nobody else has issued a formal statement. I just mean that it is widely perceived as the old, bad thing. Vulkan also mostly works fine for a lot of things, not really fair to say it "doesn't work", but there are driver support problems and other assorted weirdnesses

@glyph @puppygirlhornypost2 SDL3 GPU, Vulkan, and WebGPU would be attractive prospects if my hardware cutoff were much closer to the present day, but I want to make stuff that works on my 2012 desktop and other random low spec hardware. I think a very smart strategy for game studios that have the ability to adapt is to assume the majority of potential players are not going to have a convenient upgrade path to new hardware for a while and this problem is going to get worse.

@aeva @glyph @puppygirlhornypost2 WGPU can rest atop OpenGL although I assume some stuff breaks. Not sure about the others.

@aeva Vulkan works on a lot of older hardware though? As long as you steer clear of RT and stuff.

At Velan we treated 600-series NV cards as minspec and we shipped an engine with Vulkan as the primary backend.

It's an API with lots of problems and I personally won't work with it unless I'm getting paid, but "Vulkan doesn't work yet" does not agree with my experience.

@ataylor the machine in question has either an Intel GMA or an Intel "HD Graphics" GPU. It doesn't even support OpenGL *3*

@ataylor I checked and in a sense we are both right. the computer *does* support vulkan, however only via llvmpipe. the GPU appears to be unsupported

here's the vulkan-info output if you are curious: https://gist.github.com/Aeva/974bff1d5de1747756c2cade71a09ed5

@mcc @glyph @puppygirlhornypost2 so, assuming it can somehow run on top of OpenGL <= 2 and/or OpenGL ES2, and that GL2 / ES2 neatly encapsulate the feature set I'm interested in using, what would I gain from bolting WebGPU on top of it in exchange for the overhead of bolting WebGPU on top of it?