I’m using multilib for gaming compatibility, I’m not saying we need full _time32 support.
If I pull 32bit libs for specific applications, why would that affect the kernel or the user spaces apps that are all 64 bit and using 64 bit function calls??
2038 will break games that make specific calls to 32bit time functions, sure. Thats gonna suck in 12 years from now. But what if instead of breaking compatibility for gaming now, we work towards a solution in the next 12 years?
It’s the other way around: your _time32 libs will fail, especially user apps that call Fedora{Linux _time64. The kernel as of right now is safe for year 2038.
You have a decade to test everything, report, and fix.
Recompilation projects for everything. I want to see year2038_bazzite_safedb.org with all the games and apps you use marked ☑ 2039+ compliant.
You need to start now.
You should have started on 2004. So time to catch up! So yes, let’s database the solutions an app at a time, before the decade is up!
I’m using multilib for gaming compatibility, I’m not saying we need full _time32 support.
If I pull 32bit libs for specific applications, why would that affect the kernel or the user spaces apps that are all 64 bit and using 64 bit function calls??
2038 will break games that make specific calls to 32bit time functions, sure. Thats gonna suck in 12 years from now. But what if instead of breaking compatibility for gaming now, we work towards a solution in the next 12 years?
It’s the other way around: your _time32 libs will fail, especially user apps that call Fedora{Linux _time64. The kernel as of right now is safe for year 2038.
You have a decade to test everything, report, and fix. Recompilation projects for everything. I want to see year2038_bazzite_safedb.org with all the games and apps you use marked ☑ 2039+ compliant. You need to start now.
You should have started on 2004. So time to catch up! So yes, let’s database the solutions an app at a time, before the decade is up!