At least in my world, our banks and trading partners like to make sure we have outside support, in case one (or all) of us gets hit by a bus. That's only being responsible. Our best-supported (and most important) systems are RHEL systems. Then again, we are probably what you would consider a medium-to-large US company.

Unless your scope is kept very shallow and/or very focused, you will never be doing anything more than tweaking applications or simple debugging. The codebase for most apps is too large and if it's not your primary job / hobby then you won't have time to learn it, let alone keep up with its development.

It's wise for each company to know where they stand when making any IT expenditures, whether the goal is to have a large Help Desk for instance or outsource everything beyond a certain scope. I don't run cabling anymore, and although I could if needed, we pay contractors for that stuff. Just like I implement systems using MySQL, but I don't tweak its source or try to perform bugfixes myself (beyond Googling for answers to questions) because I have other things to do. I support other databases and systems, and I have other apps to code. My time is most valuable to my employer for these tasks, and I'm a lot more expensive than spending a few thousand a year per server for support.

Need an example? OK. We successfully implemented a fiber card in 2 of our blades (RHEL 5.4 with kernels from 5.1) and this week brought up a third blade (same model, same base OS) only this time using RHEL 5.4 with KVM for virtualization. The kernel is 5.4 and the HP drivers won't install. The issue appears that one of the RPM's (lpfc IIRC) won't install because 5.3 and higher is not supported. The support grid at HP says that 5.4 is supported. Now I need to implement the entire tested solution by the end of next week.

Do I want to play around with this? No. I have one of our network admins contact HP and work it out, and when they're finished, give me a written set of instructions which I will add to my documentation. That's how larger businesses handle this stuff.

So you think that an attacker thinks he must exploit each platform proportional to the market share?

Or do you believe that each attacker randomly chooses a platform to specialize in proportional to market share. Or do they keep a list with number of slots according to each OS's market share?

Consider this:

1. Imagine you were on a shooting range. You can shoot for two different targets, one labelled "OS X" and the other one "Windows"
2. One "OS X" target is 3 times larger than the other (OS X has 3 times the vulnerabilities compared to Windows) and is thus easier to hit.
3. Each time you hit "OS X" you get $10.
4. Each time you hit "Windows" you get $200.
5. You have 12 shots.

Now, if the targets were 10 ft in front of you and both easily hit, how would you spend your 12 shots? Would you aim 3 shots that the smaller target and 9 shots at the larger target because that seems the fair thing to do? Or would you just shoot all 12 shots at the smaller target and go home with $2400? I know what the typical person would do.

Only when you move both targets so far back that both of them gets pretty hard to hit would any sane person consider spending any rounds on "OS X".

Attackers chose target platform based this simple economics. As long as Windows has 15 - 20 times (worldwide) the market share of OSX and as long as the limiting factor of attacks is time (the actual creation of an exploit), the attackers are going to target Windows each and every time. Only if they cannot find any exploitable vulnerabilities in Windows will they invest in another platform.

Oh, and what about Apache you say? Apache has 2 times the market share of IIS (roughly). Why isn't Apache attacked exclusively for the same reason. The difference here is that these targets are pretty distant; both Apache and IIS are pretty tight. Neither Apache nor IIS5, 6 and 7 has seen successful widespread attacks directly at the server. Neither Linux nor Windows are vulnerable at the network level anymore, especially not when behind a firewall as *all* webservers are nowadays.

The shooters have simply given up (for the time being) and went to another shooting range with better odds. BothApache and IIS has seen widespread attacks against vulnerable applications running on top of the servers. Here you could certainly argue that attackers has a preference for PHP and ASP.Ancient.