Insanely topical now for the Steam Deck release! Tons of people online arguing about linux ports while not knowing what even goes into packing a game and what the dependencies that could break actually are. This is pretty good to get a feel for the issues here and not to just guess
How is this superior to flatpack? If I am shipping a game, it probably has a few gigs of assets. So shipping libraries etc is no issue. No fumbling with linker needed. Or am I missing something?
@@lepidoptera9337 If you prefer that to warthunder, flightgear, 0AD and zero-k, then sure, of course, linker is your main problem. There are plenty of really good games for Linux if you only look for them.
You don't have to discover the linker path at runtime. You can just run the linker directly and give the executable path as the first agument. For example /lib64/ld-linux-x86-64.so.2 ./test.exe. test.exe has a invalid path to linker, so on it's own it won't run, but running it like this works. With that in mind, you could write a simple bash script that will discover the linker path and call it with your game as a first argument.
Yep, but what he's trying to do is to not require extra code in the bin or a bash script. Just put the files in a standard place or alias to them or something. Not a rocket science ask.
I feel like musl distros and nixos are tiny niches inside the tiny niche that linux already is. Like the yellow part in the graph inside the yellow part of the graph. Just like running windows Just Works for gamers, running glibc distros (other than nixos) Just Works for gamers too, these days, as Steam and other releases of games for linux show. And for applications, AppImages fill the same niche. Again, leaving out musl distros and nixos. Cool demo either way though; if these barriers can be removed so that there are no hoops to jump, it's a win.
@26:13 the creator of RenderDoc doesn't approve me initializing it after my engine already started (but before touching LWJGL/OpenGL), but I do it anyways 😁. Much more comfortable starting it in my IDE than having it to start from within RenderDoc.
It's just a pain in the arse to make your software multi distro compatible. This problem just doesn't exist with Windows or macOS (for the most part). And let's face it: the Linux user experience sucks. So both groups, users and developers, have good reasons to prefer Windows and macOS.
I must disagree about the Wayland part. Relying on Xwayland forever is not a solution - at least not in case we are actually try to make the switch happened. By now, apart from Gnome that worked that around a little bit (still far from perfect though), Xwayland cannot handle HiDPI on most compositors and by now it seems like it's won't fix, no one is actively working on it and the discussion is sort of stuck. Yes, it's fine when you just have a single screen and you work without changing screen density. High resolution displays are becoming more and more common, so that's a mess, really.
Hah, fails on my Linux by endlessly trying to discover the linker path. I just get endless rows of debug: detecting whether we are running in the dynamic linker debug: we're not. detecting the dynamic linker path debug: prepare to execve reload debug: dyld_path=/lib64/ld-linux-x86-64.so.2 debug: setting environment variable 'LD_PRELOAD=libdl.so.2 libpthread.so.0' debug: detecting whether we are running in the dynamic linker debug: we're not. detecting the dynamic linker path debug: prepare to execve reload debug: dyld_path=/lib64/ld-linux-x86-64.so.2 debug: changing environment variable 'LD_PRELOAD=libdl.so.2 libpthread.so.0' to 'LD_PRELOAD=libdl.so.2 libpthread.so.0 libdl.so.2 libpthread.so.0' debug: detecting whether we are running in the dynamic linker debug: we're not. detecting the dynamic linker path debug: prepare to execve reload debug: dyld_path=/lib64/ld-linux-x86-64.so.2 debug: changing environment variable 'LD_PRELOAD=libdl.so.2 libpthread.so.0 libdl.so.2 libpthread.so.0' to 'LD_PRELOAD=libdl.so.2 libpthread.so.0 libdl.so.2 libpthread.so.0 libdl.so.2 libpthread.so.0' And the LD_PRELOAD grows endlessly with repeats of the same two libraries. If I try to run it via ld-linux manually I get a different error: $ /lib64/ld-linux-x86-64.so.2 static-window9 static-window9: error while loading shared libraries: static-window9: cannot open shared object file As an aside, wouldn't the best solution be to work on a universal non-GNU loader that can be used by all distros? By non-GNU I mean it is not part of the GNU project itself, so there's no conflict of interest.
I tried the executable and it works! Most fascinating triangle demo i've seen
But every year is the year of the linux desktop!
Unfortunately linux users will forever be the reason it's never the year of the linux desktop.
It's a funny meme
Well this was a prediction that Gaben took to heart
Windows 11 TPM + Steam deck = 2022 is probably the year linux gaming (and desktop in general) takes a knee.
Fantastic hack! Nice talk. Thanks!
5:20 - I love how arch is second to last in the list, right above UNSTABLE.
And then the 4 arch users gave the video a thumbs down. XD
Insanely topical now for the Steam Deck release! Tons of people online arguing about linux ports while not knowing what even goes into packing a game and what the dependencies that could break actually are. This is pretty good to get a feel for the issues here and not to just guess
The issue here is that Linux is dead.
@@lepidoptera9337 how is Linux dead? :o Isn't it roughly the same as ever, not popular nor dead?
@@JannisAdmek The dead are rarely popular. :-)
Hahaha, what a mess. I love it. It would be nice if we had something like this for Unity, Unreal, and Godot.
It's funerary, 2024, the executable doesn't run on my Ubuntu 22.04.1 LTS :(
As cool as this is, what would take it to the next step, in my opinion, is making it work using the APE functionality (Actually Portable Executable)
Unfortunately i get segfault (at address 0x0) on arch linux with proprietary nvidia drivers when running that static demo
I had this issue due to the window manager trying to tile the window. On floating/stacking mode, it worked fine.
audio kicks in at 1:38
3 years later and static-window9 gives a segfault :(
trying this now on fedora 35, unfortunately, fails. it seems to be stuck in a loop trying to detect the linker path
same thing on Archlinux
@@rezmed1144 can confirm not working on arch linux x86_64 kernel 6.0.10-arch2-1 with Nvidia TU117M and AMD Ryzen 5 3550H
same on Arch
22:40 I'm about to do a Linux gamer move.
How is this superior to flatpack? If I am shipping a game, it probably has a few gigs of assets. So shipping libraries etc is no issue. No fumbling with linker needed. Or am I missing something?
Yes, you are missing a killer application. Linux gaming, that is still solitaire and minesweeper. :-)
@@lepidoptera9337 If you prefer that to warthunder, flightgear, 0AD and zero-k, then sure, of course, linker is your main problem. There are plenty of really good games for Linux if you only look for them.
You don't have to discover the linker path at runtime. You can just run the linker directly and give the executable path as the first agument. For example /lib64/ld-linux-x86-64.so.2 ./test.exe. test.exe has a invalid path to linker, so on it's own it won't run, but running it like this works. With that in mind, you could write a simple bash script that will discover the linker path and call it with your game as a first argument.
Yep, but what he's trying to do is to not require extra code in the bin or a bash script. Just put the files in a standard place or alias to them or something. Not a rocket science ask.
@@farhanyousaf5616 but having a bash script is much simpler than this hack
@@golarac6433 not for the end user!
@@AndrewKelley but my point was that you'd ship such a script with your program
@@AndrewKelley It could be pretty polished if it was the AppRun of an AppImage
That is why I want to create a (mostly) statically-linked linux distribution.
The is executable is now broken.
At least on wayland ( river )
My linux distro doesn't have X11; it's wayland only without XWayland. This wont run.
@4tran ah oky
This is all great, but why not just use Appimages for end user UX?
Appimages don't work in NixOS.
Because AppImages only solve a couple of these issues. An AppImage built on Ubuntu will almost certainly run on Fedora or Arch, but not Alpine or Nix.
What software is he using for the interview to receive different streams from Andrew.?
@S B Thanks anyway!
I feel like musl distros and nixos are tiny niches inside the tiny niche that linux already is. Like the yellow part in the graph inside the yellow part of the graph. Just like running windows Just Works for gamers, running glibc distros (other than nixos) Just Works for gamers too, these days, as Steam and other releases of games for linux show. And for applications, AppImages fill the same niche. Again, leaving out musl distros and nixos. Cool demo either way though; if these barriers can be removed so that there are no hoops to jump, it's a win.
@26:13 the creator of RenderDoc doesn't approve me initializing it after my engine already started (but before touching LWJGL/OpenGL), but I do it anyways 😁. Much more comfortable starting it in my IDE than having it to start from within RenderDoc.
It's just a pain in the arse to make your software multi distro compatible. This problem just doesn't exist with Windows or macOS (for the most part). And let's face it: the Linux user experience sucks. So both groups, users and developers, have good reasons to prefer Windows and macOS.
I must disagree about the Wayland part. Relying on Xwayland forever is not a solution - at least not in case we are actually try to make the switch happened. By now, apart from Gnome that worked that around a little bit (still far from perfect though), Xwayland cannot handle HiDPI on most compositors and by now it seems like it's won't fix, no one is actively working on it and the discussion is sort of stuck. Yes, it's fine when you just have a single screen and you work without changing screen density. High resolution displays are becoming more and more common, so that's a mess, really.
Mac users use OS X because of the creative applications for audio, video, graphic design etc not games.
Mac users used Macs for the creative applications for audio, video, graphic design, etc. about 15 years ago. Welcome to 2022. 'Creatives' use PCs now.
It's 2023... this didn't age well. ;-)
Lol what a joke!
lmao how can it be this complicated to draw a single triangle??? linux desktop is embarrassing
Hah, fails on my Linux by endlessly trying to discover the linker path. I just get endless rows of
debug: detecting whether we are running in the dynamic linker
debug: we're not. detecting the dynamic linker path
debug: prepare to execve reload
debug: dyld_path=/lib64/ld-linux-x86-64.so.2
debug: setting environment variable 'LD_PRELOAD=libdl.so.2 libpthread.so.0'
debug: detecting whether we are running in the dynamic linker
debug: we're not. detecting the dynamic linker path
debug: prepare to execve reload
debug: dyld_path=/lib64/ld-linux-x86-64.so.2
debug: changing environment variable 'LD_PRELOAD=libdl.so.2 libpthread.so.0' to 'LD_PRELOAD=libdl.so.2 libpthread.so.0 libdl.so.2 libpthread.so.0'
debug: detecting whether we are running in the dynamic linker
debug: we're not. detecting the dynamic linker path
debug: prepare to execve reload
debug: dyld_path=/lib64/ld-linux-x86-64.so.2
debug: changing environment variable 'LD_PRELOAD=libdl.so.2 libpthread.so.0 libdl.so.2 libpthread.so.0' to 'LD_PRELOAD=libdl.so.2 libpthread.so.0 libdl.so.2 libpthread.so.0 libdl.so.2 libpthread.so.0'
And the LD_PRELOAD grows endlessly with repeats of the same two libraries.
If I try to run it via ld-linux manually I get a different error:
$ /lib64/ld-linux-x86-64.so.2 static-window9
static-window9: error while loading shared libraries: static-window9: cannot open shared object file
As an aside, wouldn't the best solution be to work on a universal non-GNU loader that can be used by all distros? By non-GNU I mean it is not part of the GNU project itself, so there's no conflict of interest.
I have the same problem on Arch Linux