Gregory's Server@rail why not target linux and leave the rest up to WSL
i'm not paying money for something that i have to run using a best-effort target-chasing third-party gizmo
|
24 comments
@rail@bark.lgbt @eevee@queer.party because like 90% of the time they are windows versions with built-in wine and wined3d (not even dxvk) @rail@bark.lgbt @eevee@queer.party unfortunately, this is true, sometimes i have to switch games to the Windows version instead of the native one to get them to work. Valve also agrees with this and started telling devs to target windows and proton @rail @eevee last time i bought a game that had a native linux port, it ran better than the windows version
people on the fan discord i'm on for it (until it stopped due to a recent remaster and other, different bugs appeared) complained about bugs and performance problems i'd never even thought possible from my experience with the game  my actual literal job involves shipping binaries that have wide linux compatibility--that are simpler than games--and my solution to this ended up being "compile them to wasm and offload the problem to the developers of the wasm engine" this isn't literally the same as "just tell them to use proton" because that's how it works elsewhere too, but it's kinda close  @whitequark @eevee @rail Static link them? User-kernel interface is rock solid stable. It's DLL hell that's not. @whitequark @eevee @rail Unfortunately OpenGL/GPU usage depends on DLL hell because of bad architecture. I've beent trying to get this fixed for over a decade. But pretty much anything else is fine to static link. @dalias @eevee @rail what makes these two problems similar is that the core need is "build something for exactly one ABI/platform". I could statically link them which would reduce the amount of different builds to manage to something like... 6 or 7 depending on how i'm feeling (windows x86/x64, macos x64/arm64, linux x64/arm32/arm64); by shipping wasm i build exactly one artifact that runs on most of those @dalias a significant other reason why i used this is because autotools on windows is hell and yosys uses autotools instead of cmake, and this way i never have to use cygwin or some other cursed shit like that  @whitequark @dalias using autotools is basically saying "fuck windows". Sure you can get it to work but it's just not worth it, better to write a simple CMakeLists.txt and go on with your life 😀  @Paxxi @whitequark @dalias Huh? I've rarely had trouble compiling stuff that uses autotools on Windows, unlike most other build systems. @jernej__s @whitequark @dalias try it without cygwin/msys or any other fake Linux userspace @whitequark @eevee @rail my last job involved this as well, and my solution involved building a custom dynamic libc fork designed for the purpose it wasn't actually hard to do, but the fact that nobody had done it before was pretty mind-boggling still isn't in upstream because mailing-list-based development is an absolute joke   @whitequark @rail [-eevee since she doesn't seem to want to get into this] the example that sticks out in my mind is this one @hierarchon @whitequark @rail this is a whole constellation of tickets about game developers going out of their way to /violate/ the linux ABI and then multiple distributions going out of their way to keep those games working anyway  @whitequark @eevee @rail hey now, the Linux kernel syscall ABI is extremely stable. It just doesn't help you much if you're writing anything other than a text-based game.  @eevee @rail fully convinced wsl was made by punished Microsoft at their lowest point. They just released the openssh fork for Linux and were having a rough time with cloud being 99% not them. Now proton won't stop getting better and azure customers are either office/Xbox/windows in house services or big companies basically forced to use it for office or continued windows license discounts.
|
@eevee because realistically native ports often end up just worse and outdated and more bugged than windows version ran via proton
I'm sorry