Linux vs. Windows for Web Hosting
A lot of people think I’m an Linux/open source bigot. That’s not true at all. I do love Linux and open source. As a programmer, I dig the ability to “use the source, Luke”. Not only is looking at source code interesting on its own (at least for some of us), but every now and then it really helps with debugging and troubleshooting. Linux Servers are simply better than Windows Servers for a lot of the hosting I do, so I learned how to host on Linux. Back in the days of Windows NT, there was no comparison – our Linux web servers ran heavily loaded for years at a time while Windows NT systems with more than one web site needed regular reboots – really, I’m not making it up.
In modern times, Windows 2000 and Windows 2003 closed the gap for fast and reliable web hosting, but Linux still makes a better email server for ISP type email hosting. The Linux/UNIX security model is simpler than Windows while the Linux process model is slightly more featured. It turns out that these qualities make Linux a good fit for web and email hosting. You really don’t need complex ACL based permissions for web hosting. The simpler Linux security model works and because it’s simpler, it is easier to get right. The Linux lightweight process model (including support for fork with copy on write) is a good match for virtual web hosting – think about all the perl CGI scripts out there. The lightweight process model is also handy for writing email servers. None of the nice email software I use for hosted email is even available for Windows. It’s not that it would be ultra-hard to port these packages to Windows. It’s just painful and really, why bother? DNS hosting is a wash. The only package I like is PowerDNS and it runs on both Linux and Windows.
PHP runs fine on Windows under ISS, but really, why bother? I run Asp.Net on Windows under IIS. It is possible to run .Net applications under Mono. But, from a practical standpoint, Mono still doesn’t fully support Asp.Net 2.0 (though it’s really close now) and Asp.Net 2.0 is so much better than .Net 1.1, I don’t bother with 1.1 for any of my own stuff. Overall, running Asp.Net on Linux seems like a lot of struggling against the machine.
When it comes to developer tools, nothing comes close to Microsoft. I can program in vi, emacs or even notepad if I have to, but Microsoft programming tools are better. The IDEs are faster and more integrated. The debuggers are better. The compilers and linkers are faster. My biggest complaint with Linux programming tools is lack of performance. I need a fast compile/link/debug cycle. For anything bigger than a single file project, I can’t seem to get it on Linux. Last time I had a serious project on Linux, I took the time to try out lots of different IDEs. As I would have guessed, Kdevelop was the best – it’s beautiful and has tons of features, but I still found it slow and awkward for day-to-day use. I figured out how to use “automake and friends”. Talk about weird (and slow). I do like Subversion. I’m already using it for all my cross-platform development projects and I’m thinking about converting everything else over. With Microsoft tools, debugging Asp.Net applications is just like debugging a GUI application. This alone justifies developing all my web application in Asp.Net and hosting them on Windows.
It’s been more than a couple of years since my last serious desktop GUI application. At that time, Windows and MFC were the obvious platform. If I had to run the application on Linux, I would have tried to get something going with Winelib, but MFC support under Winelib has always looked like a PITA. For new development, I would consider using Qt or wxWigits. My big complaint about both these libraries is the deliberate lack of support for exceptions – talk about stuck in the dark ages. I’ve done a little bit of WinForms programming. Overall, I think the library is pretty good (and with Mono, it could be cross-platform). My worry is the distribution requirements (though Windows 9X, ME and 2000 are finally starting to fade away) and the hefty resource requirements.