Originally posted by Joe Braga
View Post
It also doesn't help that 64-bit was always touted as the platform that runs everything x86 and how a lot of 64-bit operating systems have supported multilib and backwards compatibility for the past 15-20+ years. On that same note, Microsoft, Apple, etc have a lot of money to ensure a good multilib solution exists and, in the case of Apple, can make special hardware just so x86 performance isn't utter crap on a different architecture and so that they can have backwards compatibility so their users can keep on running what they run as well as they have implemented FatELFs (multiple architecture binaries) so the same binary and library can run on PPC and x86.
I don't know what the best solution is, but the nuclear route of dropping 32-bit and hoping in one hand kind of sucks. The Flat/Snap options kind of suck due to dropping 32-bit hardware in lieu of compat layers that could be further optimized, that take up a lot of storage space, and they don't even have tools like Flatseal so, unlike Microsoft and Apple, you end up being a command line warrior reading man pages instead of clicking a few things and getting on with your life.
Now I wonder how Fat an i686/64-v2 binary would be or if an ObeseELF consisting of i686/v2/v3 could work...or all the levels for that matter...I figure that if regardless of what we do in the name of greater compatibility that if we're gonna be hit with a storage penalty then we might as well use a solution that supports more hardware and software combinations and optimizations instead of less.
Comment