Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
SELF: Anatomy of an (alleged) failure
Posted Jun 23, 2010 21:53 UTC (Wed) by dlang (✭ supporter ✭, #313)
what features are you willing to give up to get your universal compatibility?
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?
KDE and Gnome each have their 'standard' tool for storing contact information, should Gnome users be force to load KDE libraries and applications (or KDE users forced to use the Gnome ones) to maintain compatibility?
what if someone comes up with something new, should that be forbidden/ignored so that a universal binary can work on older systems that don't have the new software?
Posted Jun 23, 2010 22:53 UTC (Wed) by RCL (guest, #63264)
1) A single entity (with dictatorship rights) is designated to maintain core "system" in a way similar to how Linux kernel itself (or *BSD) is maintained. A new platform name is defined (or, ideally, "Linux" is redefined to mean kernel + core system).
2) Entity picks a set of core libraries which it is capable to actually maintain (and guarantee the backward compatibility for) and no compatible system is allowed to replace it/enhance/modify it in any way (even recompiling the kernel locally) without losing the (official) compatibility and ability to use platform name (which should be made a trademark).
3) Versioning policy is similar to Apple or Windows: every update (other than security fixes) should have a given name and version (with means to check that from code). The platform is updated in its entirety only, bugfixes are accumulated and introduced all at once.
I think that it is sufficient for the above set of libraries to include only functionality needed to write a game (generally speaking, any application with low-latency interactive video and audio).
In some ways it is similar to creating another distro dedicated to binary stability and binary multimedia applications, but it is not intended to be a full-blown distro with its own package management and policies, just a well-defined set of binary libraries + kernel.
Posted Jun 23, 2010 23:16 UTC (Wed) by dlang (✭ supporter ✭, #313)
unfortunately in practice it just doesn't work. This may be because they don't have sufficient dictatorial powers, but nobody wants to give them that much power ;-)
as for redefining what 'Linux' means, good luck with that windmill.
Posted Jun 23, 2010 23:41 UTC (Wed) by RCL (guest, #63264)
And overall... well, I'm not going to fight for that binary compatibility. I'm a game developer, sympathetic to Linux, but my target platforms are wildly different.
Posted Jun 24, 2010 16:29 UTC (Thu) by sorpigal (subscriber, #36106)
Posted Jun 27, 2010 12:14 UTC (Sun) by nix (subscriber, #2304)
Posted Jun 23, 2010 23:03 UTC (Wed) by drag (subscriber, #31333)
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...
Posted Jun 23, 2010 23:19 UTC (Wed) by dlang (✭ supporter ✭, #313)
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.
Posted Jun 23, 2010 23:49 UTC (Wed) by drag (subscriber, #31333)
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.
Posted Jun 23, 2010 23:53 UTC (Wed) by drag (subscriber, #31333)
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...
Posted Jun 24, 2010 0:59 UTC (Thu) by dlang (✭ supporter ✭, #313)
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.
Posted Jun 24, 2010 1:11 UTC (Thu) by RCL (guest, #63264)
Posted Jun 24, 2010 19:59 UTC (Thu) by vonbrand (subscriber, #4458)
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.
Posted Jun 24, 2010 21:41 UTC (Thu) by MisterIO (guest, #36192)
Posted Jun 25, 2010 13:50 UTC (Fri) by vonbrand (subscriber, #4458)
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.
Posted Jun 24, 2010 1:37 UTC (Thu) by akumria (subscriber, #7773)
What is "wide masses" in your regard?
1% of the global population?
10% of all computer users?
100% of all operating systems?
In some areas it has been the "year of the Linux desktop" since 1997, for others, they are just starting.
An example is in this week's LWN. Poseidon Linux. Year of the scientific Linux desktop since 2004.
Posted Jun 24, 2010 8:08 UTC (Thu) by jengelh (subscriber, #33263)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds