To view parent comment, click here.
To read all comments associated with this story, please click here.
"Well, these are games. They have very little bindings to the rest of system."
Well, I would say binding to the X server, sound libraries, graphic libraries, etc. in order to run would be the same scenario, or am I missing something? The games use the system libraries, as would any other application. Certainly more bindings than say a word processor, Photoshop, Dreamweaver, etc would need?
Well, I would say binding to the X server, sound libraries, graphic libraries, etc. in order to run would be the same scenario, or am I missing something? The games use the system libraries, as would any other application. Certainly more bindings than say a word processor, Photoshop, Dreamweaver, etc would need?
Basic X binding is problem free, xlib comes as static library, BSD. OpenGL ditto. Not sure about sound, but I would expect it is the same. These all are low-level stuff. Simple to handle. And all you need to do game.
Anyway, the first problem comes with text rendering. Xft does not have a static version. And AFAIK it is LGPL anyway, so it cannot be embedded into commercial app.
And then, if you want to look&feel native, you absolutely need to link with GTK shared libraries. And those differ a lot.
I agree: games need sound, 3D acceleration on top of the normal installation in the menus which is used by 'normal' application (VMWare isn't a normal application).
So games are *more* dependent on system than many other application, and this do create support issue on Linux, especially since the sound is a mess on Linux (has been since years even though the hardware doesn't evolve much) and 3D acceleration is mostly dependant on proprietary drivers (this will change, but it'll take a long time).
Unfortunately, normal desktop apps have to bind to system. For example, they have to use platform libraries to look natively. Or just to draw text.
They don't have to bind to the system, static builds work perfectly well. They will work on any system with a recent libc. OK they will not necessarily match the current users theme they will look perfectly reasonable with a recent default theme for GTK or Qt depending what toolkit was used. There is in fact staticaly built commercial software on the market, for example SoftMaker Office.
Do not forget OpenOffice use to be distributed with a universal Linux binary. The only reason it is now split into an rpm and a deb download is to make it integrate with the two main package management systems. You could perfectly well install the rpm version on Debian/Ubuntu using alien.
Another way to make distribution independent software that runs on Linux is to follow IBM's approach (OK they only certify this for a limited set of distros but it should work on anything) is to write/port your application to the Eclipse Rich Client Platform.
"And they never can be sure what .so is currently present on the system"
Program installs deal with dependancies all the time. VMware Server installed from .rpm on Mandriva perfectly an I expect it would on Red Hat or Fedora also. VMware also provides a tarball install though I've not used it.
I'm seeing more reasons that are political than technical for why the platform is unsuited.







Member since:
2005-11-20
In situation that even two versions of the same distro are not fully binary compatible makes development and distribution of Linux applications nearly impossible."
I both agree and disagree. ID Software released Doom 3 for Linux, and Return to Castle Wolfenstien for Linux, and these are my examples. The binaries can be released as a one shot deal, and that has been proven.
Well, these are games. They have very little bindings to the rest of system.
Unfortunately, normal desktop apps have to bind to system. For example, they have to use platform libraries to look natively. Or just to draw text.
That for closed-source applications means linking to .so present on the system. There is no way around this. And they never can be sure what .so is currently present on the system.
Edited 2008-08-06 19:35 UTC