| |||||||||||||
who has a Mac? everyone!who has a Mac? everyone!Posted Nov 18, 2009 18:18 UTC (Wed) by mikov (subscriber, #33179)In reply to: who has a Mac? everyone! by tialaramex Parent article: The Future of Linux is Google (PCWorld)
My experience is exactly the same. All our products (server and embedded) are Linux and Java based based, but I am the only one who actually uses Linux on all his desktops and laptops and can run them natively on my machines. (Even though the software is Java, it is still OS-specific to a large extent with JNI, native system tools, etc).
Most technical consultants and businesses I have dealt with have Mac laptops (with a copy of Windows running in a VM).
We _tried_ to convert to Linux a couple of years ago because in theory it sounded good - after all our products are Linux based, it would be cheaper, no viruses, etc. The experiment failed miserably and it gave me a lot of insight in the subject.
I believe these are the actual objective reasons of why Linux cannot grow its market share despite being free and technically better. It is not only because Windows comes pre-installed on PCs:
- It is practically impossible to develop closed source commercial desktop software for Linux. (Which distribution? Which package manager? Which desktop environment? Which version of all the before?)
- It is extremely difficult from a business perspective to develop Linux drivers for hardware devices. Which kernel version do you target (or which distribution specific version)? How do you distribute bug fixes and updates?
(Log in to post comments)
who has a Mac? everyone! Posted Nov 18, 2009 19:18 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
answering your objections in reverse order
for hardware support you target getting your driver in the kernel.org kernel. all the distros pull from that (and most of the backport drivers)
as far as developing closed source apps for linux, this is not as hard as you make it out to be.
you don't need to target a specific desktop environment during development unless you _really_ are worried about making the look-and-feel match the desktop (and if you are doing that you need to support skins/themes anyway) look at freedesktop.org for how to do things in a desktop agnostic way.
I agree that when it gets to final compiling and testing of the application it's more work to test with the different distros. but in most of the time the problem is more in packaging dependancies than actually needing different binaries (you can get unlucky with one distro updating a library in a way that's not backwards compatible, but this is uncommon)
if your entire QA effort is manual then this can be backbreaking, but if you have automated testing of your application (which is becoming more and more a requirement anyway), then adding additional platforms to test on is relativly cheap.
it is different than latest-version-of-windows-only development, but nowdays even windows development requires testing on multiple platforms (XP Vista, 7 at minimum)
who has a Mac? everyone! Posted Nov 18, 2009 19:28 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
also on the windows platforms you need to test, don't forget that you need to test with every service pack
so in windows you have three 'distros'. XP, Vista, Windows 7, possibly 98
each of these have several releases (plain, SP1, SP2, etc)
in Linux you have a few families of distros to support RPM distros (RHEL, Fedora, Suse) and deb distros (Ubuntu and Debian) not much worse than the windows
each of these will have more than one release version out at one time (2 for Debian, 2 for Fedora, 3 for Ubuntu + LTS versions, etc), again, not much worse than windows
who has a Mac? everyone! Posted Nov 18, 2009 19:45 UTC (Wed) by boudewijn (subscriber, #14185) [Link] At the company I work for, we develop an application that has binaries available for Windows, OSX and Linux. It's partly open source, but there are closed source plugins, and in any case, given our development model, nearly everyone uses the binary installer anyway. I'm not sure whether the app is within the definition of commercial software -- but there is no volunteer work done on it. We use Qt, of course, otherwise we wouldn't be able to develop the software with 3 to 5 developers. And on Windows and Linux we use bitrock to create an installer. We only target 32-bits linux, though some people have compiled the open source parts on 65 bits linux, mostly gentoo. It works perfectly fine on my OpenSUSE and Kubuntu systems. We have about 60,000 Windows users, about 5000 OSX users and about 300 Linux users. Despite having a lot of automatic tests, all operating systems give us pain: on OSX it's hard to support 10.4, 10.5 and 10.6 with one binary, and besides, we've only ever got access to the latest Apple hard and software, For Windows, side-by-side errors are bad. One version of Visual C++ actually creates corrupt manifests, The differences between XP, Vista and Windows 7 are particularly time-consuming. For Linux, the biggest problem is running the autotests: our test machine doesn't have X11... And we had a lot of problems with different versions of gstreamer. All in all, if you develop your commercial desktop software using Qt, use the Bitrock installer and have decent automated tests, providing your application for 32 bit linux as well doesn't cost a lot of extra effort.
who has a Mac? everyone! Posted Nov 18, 2009 20:06 UTC (Wed) by mikov (subscriber, #33179) [Link]
How does Bitrock handle .so dependencies (even Qt itself) in different distributions?
The (only?) positive thing about Windows is that binary compatibility between OS versions is an explicit goal. While I still was a Windows developer we had no problems moving software (including our kernel drivers) between NT4, W2K and later to XP. Of course I don't claim this is universal, because our packages were pretty self contained. Also, i realize that Vista introduced more significant changes and breakages compared to, say, XP.
who has a Mac? everyone! Posted Nov 18, 2009 20:25 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
window's binary compatibility is like Java's source compatibility. it works all the time, except when it doesn't
yes it's a goal, and yes it works a lot of the time. but it doesn't always work.
for linux systems, you can take just about any binary from one distro and run it on another distro. the .so files are all named the same way so if they are there everything works.
the cross-linux-distro problem is more a matter of how to make sure that all the right packages are there, and where are all the config files than anything else.
there are a lot of companies selling software for linux, many of them charging lots of money for their software. some of them take a hard line attitude like 'we only certify RHEL 5.0, if you upgrade to RHEL 5.1 you are on your own', but many of the recognise that the distros are all more the same than they are different and instead say 'we have tested this on RHEL 5.0, it should work on anything else, contact us if you have problems'
the companies that take the first attitude are very slow to support any new distros or releases, frequently when a customer says 'I will buy your product if you support distro X' (I've done this to a few products).
companies that take the second attitude tend to be much faster to add 'supported' distros to their list.
who has a Mac? everyone! Posted Nov 18, 2009 21:30 UTC (Wed) by boudewijn (subscriber, #14185) [Link] Basically, you package everything you need, Certainly all the Qt libraries you use, but also other libraries, we're not using the system Qt. It doesn't solve everything: the gstreamer problem I mentioned above was because we didn't want to package gstreamer as well, and the gstreamer on ubuntu and gstreamer on OpenSUSE weren't binary compatible, so when we packaged the Qt Phonon library, which uses gstreamer, we had problems. (Of course, Phonon couldn't play mp3's on XP, but could play wav's while it was the other way around on Vista.) The set of libraries we package is almost the same on Windows, OSX and Linux, by the way. On Windows we have to package the c runtime, as well, that is the main difference.
|
|||||||||||||