This would be great, except that it's impossible to "support Linux". You can support Debian, or Gentoo, or CentOS, or Slackware, or one of the many other linux distributions; but the fact that your code works on one distribution doesn't necessarily mean that it will work on another.

I'm dealing with this with tarsnap right now -- I know the code works on FreeBSD, NetBSD, OpenBSD, OS X, and OpenSolaris; but for Linux all I can say is that it works on Debian, Ubuntu, CentOS, Slackware, Gentoo, and RedHat. Does it work on SUSE, Mandriva, Xandros, MontaVista, or Linspire? I don't know. (But if anyone here runs any of those, I'd be happy to hear from you.)

Yes, I could install N different distributions of linux and test them all; but testing on N different distributions is much more work than testing on 1, and many people simply won't have the time.

Our application is written in Java which is a compatibility nightmare on Linux. There are half a dozen alternative Java implementations which are all slow and broken but that doesn't stop the important Linux distributions from preferring them strongly over the Sun JRE.

This forced us to bundle the Sun JRE with our application on Linux, which effectively doubled the size of it. It was worth it though because we haven't seen any Linux incompatibility issues yet.

(ps: I can test tarsnap on ArchLinux)

What's the current legal status of bundling the JRE with your application? I seem to recall that fairly recently (three or four years ago) you had to download it from Sun and "sign" a clickwrap agreement in order to get it working.

You're allowed to redistribute the JRE with an application if you do it for the reason that we're doing it:

http://java.sun.com/j2se/1.5.0/jre/README

Thanks!

Test a few the big ones (Fedora and Ubuntu spring to mind), play nice with native package managers and use a liberal enough license that someone can make a package of your game for another distro, even if they still need to install the data separately. This makes it the responsibility of package maintainers to modify the package you've already made to point at the right directories.

Another approach may be to use autopackage or similar.

In my experience, Linux platform compatibility boils down to a few things:

- architecture (usually i686 or x86_64)

- availability of the right library versions in /usr/lib (however, you can combat this by "shipping" the versions you need with your app)

- (rarely) kernel version

- (even more rarely) glibc version

In other words, most of the time, if it's an Intel binary, it seems to work pretty well.

If a particular Linux distribution seems necessary, it usually just means that one of the above features of that distribution is important.

It's getting to the point now that you might as well distribute your app in the form of a VM image.

I'm curious as to why that isn't more common, although you get a similar compatibility issue with your choice of vmware, xen or virtualbox; and there is some overhead; but yes, it sounds like a good idea to me.

http://www.rpath.org/ does something like that for server side software, and I know vmware supports that model.

A VM is great for trying out an app, but if I'm really going to use something, it becomes a PITA to have it in it's own sandbox. I don't want to deal with network sharing and all that just to move files between all my apps.

That's the JumpBox (http://www.jumpbox.com/) people are doing.

It's really a lot more complicated than that on the packager's side. What you're seeing is likely the result of the person building the binaries already linking everything statically that's possible, using older compatibility versions of the shared libraries, and hoping for the best on the rest, being certain not to make use of recent or volatile features.

I've had problems with inter-distribution linux compatibility in tarsnap due to

* varying definitions of off_t (fortunately autoconf fixed this for me).

* the linux 2.4 kernel returning EINVAL for the interaction of TCP_NODELAY and TCP_CORK (fixed by avoiding the problematic interaction on all linuxes).

* the header files for openssl, zlib, and ext2fs/ext2_fs.h sometimes being installed and sometimes being part of packages with a wide variety of names (which I'm attempting to work around by providing a list of "the package you need should have a name something like this...").

I think there was a library version issue at one point too, but I can't remember what it was.

Yes, I could avoid problems with header files if I only provided binaries; but even leaving aside the question of security, this would mean that I'd have to deal with the problem of packaging binaries in N different ways.

As cgrenade already mentioned, most Linux users use something either based on Debian (which includes Ubuntu) or Fedora (including RHEL).

Also, consider that the major Linux ditros have far more users than the different BSDs or Solaris do (OK, there's a lot of old projects running Solaris, but it's very rare to pick for new projects, so I doubt this would be a big source of customers for new software).

I think that the only sane way is to "support Unix". Avoid conditional compiling and features that are only in one platform and use standard libraries. Of course this is the most difficult approach and usually impossible to make.

"I think that the only sane way is .... the most difficult approach and usually impossible to make."

Sorry, but that doesn't sound very sane to me. :)

Well, think about the time that you could spend in testing and debugging each platform and the time that you can spent in only one.

Indeed. To most major vendors (that I deal with anyway) Linux is synonymous with RHEL 4 or 5 and that's it. Sometimes only one of those.

In much shorter form: Don't ignore the preferences of trend-setters and early adopters.

That wasn't entirely his point.

He definitely also meant it's easier to dominate a smaller market with less competition than a be a medium player in a big market.

Well put. This is one of the reasons why Tarsnap supports BSD, linux, and OS X, but not Windows -- people who run Windows are generally not trend-setters or early adopters... nor are people likely to take the advice of Windows users where security is concerned.

Watch your hubris and bigotry.

Windows is a far larger market, so early adopters and trend setters aren't as loud as they might be in an empty room, but that doesn't mean there are less of them. Instead, they tend to be visible only in niches of the PC market, rather than simply the Mac niche or FOSS niche.

Also, I recommend that you moderate your intake of propaganda re Windows security too. Windows is the big target, and has by far the largest number of suckers (i.e. unsophisticated users). That doesn't make it inherently insecure, or savvy users of it incompetent.

Please don't flame.

The statement "people who run Windows are generally not trend-setters or early adopters" remains true, and is actually supported by what you said. Also, the poster did not refer to Windows users as "suckers" or "incompetent", or describe Windows as "inherently insecure", so you should consider the possibility that you've misunderstood the intent of the message before accusing him of "hubris", "bigotry", and being a consumer of "propaganda".

'Also, I recommend that you moderate your intake of propaganda re Windows security too. Windows is the big target, and has by far the largest number of suckers (i.e. unsophisticated users). That doesn't make it inherently insecure, or savvy users of it incompetent.'

Windows Vista was the first Windows consumer OS to ship with a firewall enabled, and that by default used limited privilege accounts that prompted to elevate privileges when needed.

When did Linux and OS X have those features?

Vista was the first Windows OS to ship without inbuilt, unfixable windows-smashing vulnerabilities. Did Linux or OS X ever have an equivalent unfixable vulnerability baked into the display server?

How long has the idea of all software being digitally signed been in the Windows world?

How long has the idea of 'it's compromised, game over, reinstall and re-apply non-executable data if you think that's not compromised too' been around in the Windows world? Or do people still use 'anti-virus' software as a line of defense, when it's already too late?

Which current consumer version of Windows has mandatory access control ala SELinux or AppArmor?

Which version of Windows has chroots? Process jails?

How large is the 'Windows Hyper V appliance' based on Server Core 2008 compared to VMware ESX3i?

Which OS requires users close all their application, stop executing their kernel, and restart everything for simple, non-kernel updates?

With your answers to the above in mind, do you think you should perhaps limit your own intake of propaganda regarding Windows security?

I would have to agree with this. We released the first version of our software for Linux and OS X only. It wasn't a deliberate plan to target 'trend setters', we simply didn't finish the work we need to do on Windows yet.

Since we are in a technical niche (network security) a lot of the traffic to our site is from Linux and OS X users, but 85% of it is still from Windows. It's painful to watch people arrive at our site, realize in the first 30 seconds that there is no version of our software for Windows, then disappear (probably forever).

It isn't just about how many early adopters there are -- it's that, with Linux and OS X, they make up a much larger proportion of users. There are probably a lot more savvy Windows users, but the high proportion of early adopters in Mac/Linux markets makes it easier to be recognised by those types of user if you're targeting them.

A colleague was asking about internet-based backup systems. He uses GNU/Linux, but his wife uses Windows, and he wanted them both to be able to use the same backup system.

I was about to recommend that he take a look at Tarsnap, until I saw it doesn't support Windows.

This is the model that brought fame and fortune to Bungie.

"The team focused on the Macintosh platform, not Windows-based personal computers, because the Mac market was more open and Jones had been raised on the platform."

http://en.wikipedia.org/wiki/Bungie#Founding

They had a clear and open field making quality games exclusively for the Mac platform, and this brought them a devoted following and a steady flow of profits. They later branched out into Windows, and of course Microsoft bought them out so they would focus predominantly on the XBox.

So, while ignoring Windows indefinitely may not be a great strategy, ignoring it at first can be.

This was nice, pretty much straight to the point. At Dropbox we've noticed disproportionately more Mac/Linux users (relative to the "worldwide norm" or whatever that means, which is pretty standard). More importantly, we've definitely noticed disproportionately more vocal Mac/Linux users. We started as Mac and Windows but "investing" in a Linux (ok, Ubuntu/Nautilus to be specific, but it tends to work in most distributions and can work without Nautilus) client has certainly been worthwhile.

I would have been perfectly content with "Because Microsoft is evil".

It's interesting how they used to be the anti-IBM company too. Die a hero or live long enough to see yourself become a villain.

And now IBM is one of the biggest linux supporters. If MS ever loses its walled garden, you'll see it preaching standards & open protocols loud as anyone else.