Linked by Debjit on Mon 23rd Aug 2010 21:16 UTC
Thread beginning with comment 437947
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Does it have to be Steam?
by nt_jerkface on Wed 25th Aug 2010 00:52
in reply to "RE: Does it have to be Steam?"
ELF files are not going to help developers deal with differences between windowing systems or the audio mess. There is no standard API for Ubuntu and openSuse and that is the real problem. There is the LSB but it is too limited in scope and isn't enforceable.
The LSB has been good for server development but for desktop applications there are too many areas where distros conflict.
RE[3]: Does it have to be Steam?
by Zifre on Wed 25th Aug 2010 15:10
in reply to "RE[2]: Does it have to be Steam?"
The LSB has been good for server development but for desktop applications there are too many areas where distros conflict.
It's true that closed source desktop applications (e.g. a word processor) are hard to do. But that's because they have a lot of dependencies. The biggest choice is Gtk+ or Qt, because they do not 100% integrate as people will tell you.
However, closed source games are pretty easy to do, because there are a lot less dependencies. Admittedly, it's not quite as easy as Mac OS X. But if you spend six months developing a game (using cross platform libraries, obviously), is it really that hard to spend a few extra days to get it to run on Linux? The main problem I see is market share. Nobody wants to spend any effort at all for a platform with 1% market share.





Member since:
2009-10-04
You do realize that this is already true...
All the distros use ELF, and there is a fairly standard set of libraries that you can expect. If you really want to be safe, you can just statically link it, solving all binary compatibility issues (libGL is the only library you would have to dynamically link to, and it has a stable ABI).