@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).
@puppygirlhornypost2 @glyph I think distros putting everything in different paths, picking different init systems, different audio subsystems, and little things like glibc backwards compatibility breakages are very significant differences. That is a massive permutation space! I can't just simply make a linux build of a game for example.
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
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.
@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.
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
pretty sure past me would’ve been dropping slurs at this point so if anything i’m showing tremendous restraint
@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.
@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?