SELF: Anatomy of an (alleged) failure

Posted Jun 23, 2010 23:03 UTC (Wed) by drag (guest, #31333)
In reply to: SELF: Anatomy of an (alleged) failure by dlang
Parent article: SELF: Anatomy of an (alleged) failure

> as a trivial example, if an application needs to store some data and the upstream support sqlite, mysql, postgresql, flat files, or various 'desktop storage' APIs, which one should the universal binary depend on? and why?

Well presumably with 'Fat Binary Support' the Linux distribution will take advantage of that to provide Fat binaries for their main OS.

That way you avoid dealing with issues with having to do ugly hacks like maintain separate */lib and */lib64 things. So the application author should not have deal with issues like that (unless I am missing some aspect of SQL databases datatypes differences between 32 and 64bit arches.)

A distro moving to "Fat binay support" model should simultaneously be able to support backwards compatibility with 32bit legacy applications and be prepared to deal with the shiny new 64bit future without forcing users and application developers to deal with the details.

--------------------------------

From my personal experiences sharing my home directory between multiple versions of Debian with different arches (64bit/32bit, and PPC 32bit) the only big issue with compatibility on application storage was with X-Moto and it's use of sqlite to store game information. It had to do with endiness issues between x86 and PPC, but I think it was actually fixed at a later date...

SELF: Anatomy of an (alleged) failure

Posted Jun 23, 2010 23:19 UTC (Wed) by dlang (guest, #313) [Link] (7 responses)

you don't need fat binaries to run 32 bit binaries on 64 bit systems, you just need the right libraries on the system, and a fat binary doesn't help you there (if you are on a 64 bit system but only have 32 bit versions of some library that the app needs, should you run the 32 bit version?)

the OP was wanting a single flat binary that would run on every distro, doing that requires that all distros agree on what datastore to use when the application can be compiled to work with many different ones.

SELF: Anatomy of an (alleged) failure

Posted Jun 23, 2010 23:49 UTC (Wed) by drag (guest, #31333) [Link] (6 responses)

> you don't need fat binaries to run 32 bit binaries on 64 bit systems,

Of course not. It just makes it a more difficult and irritating for users and developers and distribution makers to support mutli-arch and play games with having multiple locations and packages for the same pieces of software.

There is a reason I run 64bit kernel with 32bit userland on my Linux systems nowadays.. I tried running 64bit only and things like that, but it's a PITA to do that in Linux while 64bit application support is trivial (for end users) in OS X...

> you just need the right libraries on the system, and a fat binary doesn't help you there (if you are on a 64 bit system but only have 32 bit versions of some library that the app needs, should you run the 32 bit version?)

Well if I only have a 32bit-only version of a library (instead of the vastly preferable 32/64 fat binary library) then that would presume that only 32bit versions of that library exists.

Therefore a 64bit version (or a 32bit/64bit 'Fat binary' version) of a application that depends on that library would be impossible to have in the first place... right?

Either way it's not really any different then what we have to deal with it now, but with Fat binary support it would be handled intelligently by the system were as right now it requires a lot of manual intervention and a significant technical understanding on the part of end users to deal with these sort of compatibility issues.

SELF: Anatomy of an (alleged) failure

Posted Jun 23, 2010 23:53 UTC (Wed) by drag (guest, #31333) [Link]

> I tried running 64bit only

Well for a better understanding; I was running Debian while attempting to juggle both 64bit and 32bit compatibility for the various applications I needed to run. Fedora is a bit better...

SELF: Anatomy of an (alleged) failure

Posted Jun 24, 2010 0:59 UTC (Thu) by dlang (guest, #313) [Link] (4 responses)

I run 64 bit only systems everywhere (although ubuntu uses ndis wrappers to run 32 bit flash for firefox) and don't run into problems.

I will admit I don't run binary-only software (i.e. commercial games) on most of my systems, but that's more due to the lack of commercial games available for linux than anything else.

SELF: Anatomy of an (alleged) failure

Posted Jun 24, 2010 1:11 UTC (Thu) by RCL (guest, #63264) [Link] (3 responses)

Just by the way... Given the above discussion, what would you recommend for a developer that wants to ship a binary-only Linux game (or game-like application) and to target as wide userbase as possible?

SELF: Anatomy of an (alleged) failure

Posted Jun 24, 2010 19:59 UTC (Thu) by vonbrand (subscriber, #4458) [Link]

I'd guess 32 bit (for oldish machines and netbooks). But some serious gamers I know spend more on their grapics card than I do on a complete machine, for for high-end 64 bit 2 (or even 4) cores is probably the way to go.

SELF: Anatomy of an (alleged) failure

Posted Jun 24, 2010 21:41 UTC (Thu) by MisterIO (guest, #36192) [Link] (1 responses)

I may be somewhat naive here, but what about 32 and 64 bit versions of .deb and .rpm packages?

SELF: Anatomy of an (alleged) failure

Posted Jun 25, 2010 13:50 UTC (Fri) by vonbrand (subscriber, #4458) [Link]

On current Fedora, you can install 32 and 64 bit versions happyly (most of the time), the installed packages do share non-architectured stuff (like manpages and whatnot). Yes, it does require some delicate juggling when building the packages to make sure said manpages and such are exactly equal and some other considerations.