Posted December 08, 2012
I work on a program that ships for "Linux" and we support every distribution that calls in. We also ship on HP-UX, AIX, Windows, Mac OS X, and so on.
Supporting Linux isn't that hard, we just provide the key libraries we will need. This isn't ideal in every way, but it works reliably for us and for our customers.
Meanwhile claiming that autopackage and LSB not succeeding is just showing the original poster's ignorance. Autopackage was a collection of horrifying hacks, trying to basically ignore the technical hurdles in the way of the approach selected. The author refused to accept that hacking your way past problems is not a good choice for *infrastructure* and so no one serious was willing to use it.
LSB meanwhile was a minimum commonality target. It provides a set of commonalities that you can target and expect your application to work on any LSB-enabled system. For what it is, it works. You can target that set and have a working app on any such system. The problems are that it is by necessity limited in scope, so if you want full integration with current features of provided libraries, you have to forgo LSB to get the current stuff. In practice the third party ISVs who were being targetted by the LSB effort (like my company, or GOG) typically just chose the technical approach that my company does -- make a binary that works everywhere you have libc w/in the last 2-4 years, and call it a day.
The challenges with shipping binaries on Linux all have relatively simple solutions, it's just a matter of going out and doing it, and building that expertise. It's also a matter of having the necessary talent to get the project started.
Supporting Linux isn't that hard, we just provide the key libraries we will need. This isn't ideal in every way, but it works reliably for us and for our customers.
Meanwhile claiming that autopackage and LSB not succeeding is just showing the original poster's ignorance. Autopackage was a collection of horrifying hacks, trying to basically ignore the technical hurdles in the way of the approach selected. The author refused to accept that hacking your way past problems is not a good choice for *infrastructure* and so no one serious was willing to use it.
LSB meanwhile was a minimum commonality target. It provides a set of commonalities that you can target and expect your application to work on any LSB-enabled system. For what it is, it works. You can target that set and have a working app on any such system. The problems are that it is by necessity limited in scope, so if you want full integration with current features of provided libraries, you have to forgo LSB to get the current stuff. In practice the third party ISVs who were being targetted by the LSB effort (like my company, or GOG) typically just chose the technical approach that my company does -- make a binary that works everywhere you have libc w/in the last 2-4 years, and call it a day.
The challenges with shipping binaries on Linux all have relatively simple solutions, it's just a matter of going out and doing it, and building that expertise. It's also a matter of having the necessary talent to get the project started.