| |||||||||||||
SELF: Anatomy of an (alleged) failureSELF: Anatomy of an (alleged) failurePosted Jun 23, 2010 21:32 UTC (Wed) by RCL (guest, #63264)In reply to: SELF: Anatomy of an (alleged) failure by cmccabe Parent article: SELF: Anatomy of an (alleged) failure
Those who want "year of Linux desktop" (i.e. adoption by wide masses) to come should treat maintaining binary compatibility (backward and/or between major distros) as the most important goal...
(Log in to post comments)
SELF: Anatomy of an (alleged) failure Posted Jun 23, 2010 21:53 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
you have to establish compatibility before you can worry about maintaining it ;-)
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?
SELF: Anatomy of an (alleged) failure Posted Jun 23, 2010 22:53 UTC (Wed) by RCL (guest, #63264) [Link]
I don't really have well-thought solution, but more or less it's like this:
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.
SELF: Anatomy of an (alleged) failure Posted Jun 23, 2010 23:16 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
this is exactly what the Linux Standards Base is attempting to do.
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.
SELF: Anatomy of an (alleged) failure Posted Jun 23, 2010 23:41 UTC (Wed) by RCL (guest, #63264) [Link]
I think that LSB is not exactly the same, but is much wider in scope - it even dictates the installer. And it is a certification board, not a vendor so it cannot produce/maintain the aforementioned core system.
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.
SELF: Anatomy of an (alleged) failure Posted Jun 24, 2010 16:29 UTC (Thu) by sorpigal (subscriber, #36106) [Link]
This sounds an awfully lot like Debian, to me.
SELF: Anatomy of an (alleged) failure Posted Jun 27, 2010 12:14 UTC (Sun) by nix (subscriber, #2304) [Link]
More like a sort of really crippled and inflexible FreeBSD, with all ports forced to update only when the OS has a major version number bump: if you want a bugfix you have to wait for another giant mass of features to land. Great idea, not.
SELF: Anatomy of an (alleged) failure Posted Jun 23, 2010 23:03 UTC (Wed) by drag (subscriber, #31333) [Link]
> 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 (✭ supporter ✭, #313) [Link]
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 (subscriber, #31333) [Link]
> 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 (subscriber, #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 (✭ supporter ✭, #313) [Link]
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]
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]
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.
SELF: Anatomy of an (alleged) failure Posted Jun 24, 2010 1:37 UTC (Thu) by akumria (subscriber, #7773) [Link]
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.
Anand
SELF: Anatomy of an (alleged) failure Posted Jun 24, 2010 8:08 UTC (Thu) by jengelh (subscriber, #33263) [Link]
Linux is backward compatible - you can still run binaries once compiled for Linux 2.0, and there are even reports that some ddated to 0.99 work. Ask tytso.
|
|||||||||||||