Linux
Welcome to c/linux!
Welcome to our thriving Linux community! Whether you're a seasoned Linux enthusiast or just starting your journey, we're excited to have you here. Explore, learn, and collaborate with like-minded individuals who share a passion for open-source software and the endless possibilities it offers. Together, let's dive into the world of Linux and embrace the power of freedom, customization, and innovation. Enjoy your stay and feel free to join the vibrant discussions that await you!
Rules:
-
Stay on topic: Posts and discussions should be related to Linux, open source software, and related technologies.
-
Be respectful: Treat fellow community members with respect and courtesy.
-
Quality over quantity: Share informative and thought-provoking content.
-
No spam or self-promotion: Avoid excessive self-promotion or spamming.
-
No NSFW adult content
-
Follow general lemmy guidelines.
view the rest of the comments
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!