Went with apps, but that's not really accurate (Score: 5, Insightful) by zocalo@pipedot.org on 2014-06-02 10:59 (#205) It's not that Linux is lacking software, quite the opposite in fact, it's lacking viable alternatives to commercial software for which there is currently nothing that can come close in terms of capabilities and/or is as convenient to use for which the vendor hasn't released a native version, or simply won't do so. Re: Went with apps, but that's not really accurate (Score: 1, Insightful) by Anonymous Coward on 2014-06-02 14:18 (#206) So the deeper question is "what makes it not attractive to release a commercial linux version of most software?". Besides the obvious smallest userbase, the large number of distros makes support a very complex topic. Even among the top few, there are some quite big differences. Re: Went with apps, but that's not really accurate (Score: 1) by zocalo@pipedot.org on 2014-06-03 07:50 (#20F) Having used commercial software on Linux in the manufacturing sector, support is usually only provided for a few main distros anyway (Debian, Red Hat and SuSE in my case). If you can get the binary to run on another distro, then that's great, but you are not going to get anything close to the same level of support as the officially sanctioned distros. For most applications I actually don't see that as a major problem, although RMS would certainly have something to say about the restriction of choice; it's still Linux, and in a commercial setting you are probably choosing the best OS/distro for your required apps anyway, rather than the other way around.<br><br>Another problem was the issue of libraries, particularly when they were more obscure on one distro but bundled with another. A poke around in the dependencies for the various packages revealled that the typical solution here was either to statically link any such libraries across the board, or in a few cases to do so selectively from distro to distro, dynamically linking to the distro provided versions where available and statically linking the rest. Worst case scenario would be to just statically link the entire lot, which is an approach I've seen used for several Linux games - commercial or otherwise.<br><br>So, it's not as if the problems don't have solutions, although they are not necessarily ideal, which leave me thinking it's more to do with the low return on the time and effort required. Unless you are working off the back of one of the major Linux desktop migrations that pop-up from time to time and making the binaries available to all, you have a much smaller userbase, split across multiple distros that are potentially different enough to be treated like different OSs from a compilation and support perspective. Each distro you support gets you more users, but adds to the cost of developing, compiling and testing the code, plus supporting it when you are done, and for many apps, particularly the more complication ones the numbers almost certainly just don't add up. So perhaps the real question is "what can the Linux community do to make the numbers add up?"
Re: Went with apps, but that's not really accurate (Score: 1, Insightful) by Anonymous Coward on 2014-06-02 14:18 (#206) So the deeper question is "what makes it not attractive to release a commercial linux version of most software?". Besides the obvious smallest userbase, the large number of distros makes support a very complex topic. Even among the top few, there are some quite big differences. Re: Went with apps, but that's not really accurate (Score: 1) by zocalo@pipedot.org on 2014-06-03 07:50 (#20F) Having used commercial software on Linux in the manufacturing sector, support is usually only provided for a few main distros anyway (Debian, Red Hat and SuSE in my case). If you can get the binary to run on another distro, then that's great, but you are not going to get anything close to the same level of support as the officially sanctioned distros. For most applications I actually don't see that as a major problem, although RMS would certainly have something to say about the restriction of choice; it's still Linux, and in a commercial setting you are probably choosing the best OS/distro for your required apps anyway, rather than the other way around.<br><br>Another problem was the issue of libraries, particularly when they were more obscure on one distro but bundled with another. A poke around in the dependencies for the various packages revealled that the typical solution here was either to statically link any such libraries across the board, or in a few cases to do so selectively from distro to distro, dynamically linking to the distro provided versions where available and statically linking the rest. Worst case scenario would be to just statically link the entire lot, which is an approach I've seen used for several Linux games - commercial or otherwise.<br><br>So, it's not as if the problems don't have solutions, although they are not necessarily ideal, which leave me thinking it's more to do with the low return on the time and effort required. Unless you are working off the back of one of the major Linux desktop migrations that pop-up from time to time and making the binaries available to all, you have a much smaller userbase, split across multiple distros that are potentially different enough to be treated like different OSs from a compilation and support perspective. Each distro you support gets you more users, but adds to the cost of developing, compiling and testing the code, plus supporting it when you are done, and for many apps, particularly the more complication ones the numbers almost certainly just don't add up. So perhaps the real question is "what can the Linux community do to make the numbers add up?"
Re: Went with apps, but that's not really accurate (Score: 1) by zocalo@pipedot.org on 2014-06-03 07:50 (#20F) Having used commercial software on Linux in the manufacturing sector, support is usually only provided for a few main distros anyway (Debian, Red Hat and SuSE in my case). If you can get the binary to run on another distro, then that's great, but you are not going to get anything close to the same level of support as the officially sanctioned distros. For most applications I actually don't see that as a major problem, although RMS would certainly have something to say about the restriction of choice; it's still Linux, and in a commercial setting you are probably choosing the best OS/distro for your required apps anyway, rather than the other way around.<br><br>Another problem was the issue of libraries, particularly when they were more obscure on one distro but bundled with another. A poke around in the dependencies for the various packages revealled that the typical solution here was either to statically link any such libraries across the board, or in a few cases to do so selectively from distro to distro, dynamically linking to the distro provided versions where available and statically linking the rest. Worst case scenario would be to just statically link the entire lot, which is an approach I've seen used for several Linux games - commercial or otherwise.<br><br>So, it's not as if the problems don't have solutions, although they are not necessarily ideal, which leave me thinking it's more to do with the low return on the time and effort required. Unless you are working off the back of one of the major Linux desktop migrations that pop-up from time to time and making the binaries available to all, you have a much smaller userbase, split across multiple distros that are potentially different enough to be treated like different OSs from a compilation and support perspective. Each distro you support gets you more users, but adds to the cost of developing, compiling and testing the code, plus supporting it when you are done, and for many apps, particularly the more complication ones the numbers almost certainly just don't add up. So perhaps the real question is "what can the Linux community do to make the numbers add up?"