Linux's integrated design makes that the kernel developers' problem, not the users'.

> Windows doesn't require rebuilding the kernel to get device support for some vendor's hardware.

Neither does Linux. You have to compile the module (i.e. the driver itself), of course, but you can modprobe it without rebuilding the kernel. This has always been the case.

A long time ago (during the days of kernel 2.4 or so) there were people (ahem, mostly using Gentoo) who tried to shave off a few milliseconds when booting by building everything into the kernel so as not to waste time loading modules. In that case, sure, you have to rebuild the kernel, but that is not a common approach.

I... have to wonder, where did you get the idea? Back then (I was... um... I was also frequenting the Gentoo establishments...) Windows was our laughing stock because you had to reboot your computer when installing drivers.

Having said that, the main advantage for developers has to be the relative stability of the device driver API. Linux explicitly doesn't have one, as part of the war on closed source drivers, which makes maintaining an out-of-tree driver a hassle.

Fair enough.

I would dispute the 'total count' argument.

Here's Greg's claim: "Linux today supports more hardware devices than any other operating system in the history of the world."

http://www.linuxfoundation.org/collaborate/workgroups/techni...

I don't know what data it's based on, but I strongly suspect he's correct on that.

Again: my contention isn't that Linux does better on desktop-grade hardware, if anything, that's its weak point. But that's entirely due to vendor leverage by Microsoft, not technical shortcomings.

Windows doesn't require rebuilding the kernel...

Two elements to that:

1. Neither does linux in many cases. You'll have to compile the kernel module itself, of course (or someone will). That's the case for Windows as well. Generally, for stock kernels, device support is via modules, and you simply have to provide the module. In practice, it's already present, and device autodetection loads modules at boot time. This means that, e.g., you can take a hard drive out of one system, put it in another (of the same general CPU architecture), and it simply boots and works.

2. Drivers are sketchy, mkay? Not allowing any arbitrary code to be loaded into kernel space offers security advantages. It's on of those security / convenience trade-offs.

The total count of Windows machines

Counting Android as Linux, you're close to losing, if not already lost, with that metric as well.

Quick search suggests that Android bypassed Windows in early 2014:

http://www.phonearena.com/news/Android-installed-base-might-...

Present count is 1.675 billion Android devices:

http://www.statisticbrain.com/android-phone-statistics/

Windows as a share of all computing devices fell behind the combined iOS and Android count in 2012: http://www.zdnet.com/article/windows-has-fallen-behind-apple...

What is a "driver developer"? What's your end goal here - to enable the hardware on a particular OS, or do you have the added constraint of wanting to maintain control of your "driver" by keeping it proprietary, and so you have the additional requirement of a pluggable architecture instead of just contributing to the upstream Linux kernel?

In other words, do the obstacles you claim exist only exist because you are trying to write non-free drivers?

Sales network is something entirely different than technical capabilities. Especially, when half of Microsoft is sales force.

Yes, there are companies using Microsoft products and Microsoft is getting paid very well for that. However, these companies are not on forefront of computing and are not considered to be top companies in the area of cutting edge development.

Show me some cutting edge company/startup in the IT sector that is using Microsoft products and is not a statistical error. There is a reason for that.