[By Matthew French] Ever since the first vi user met the first emacs user, the IT industry has been plagued with intense debates about very little. No fact or rational argument will convince either side they might be wrong. As the discussion depends on what the participants believe, these are often described as religious debates.

Now real religions are important and often define our lives. Religious debates in the IT industry, on the other hand, are usually about the most obscure and arcane issues that one could ever hope to consider. It is no surprise that a party I recently attended was for IT people only. Probably best not to let ordinary mortals mingle with people who can take text editors so seriously.

If you have been involved in IT for more than a few years, you have probably experienced these debates. Long, seemingly unproductive arguments where the opposing sides obsess over every detail. All you want to do is finish the work, not nitpick about the perfect way to complete it.

Of course if you enjoy what you do a little too much, you might have started a few of these arguments. I know I have. There is no shortage of topics to choose from: the best programming language, operating system, text editor, pattern, paradigm, open-source licence, architecture, hardware, software… The list is almost as long as the number of people willing to devote hours to scoring points for their chosen favourite.

Sometimes these debates are just a way to pass the time while waiting for a back-up to finish. Normal people might argue about the merits of football teams. However, in IT, there is a good chance that some of the participants have a hate-hate relationship with physical exercise. So they have to find something else to argue about.

At times the debates can be more serious. The outcome of the argument might determine which technology or idea will be used, and they are mutually exclusive. Operating systems, databases and programming languages all fall into this category. Once a winner has been chosen, it is very hard to switch to something else. These debates can be intense and, if not properly managed, the resultant fall-out can last for months. In the worst-case scenario the losers who stay will feel compelled to point out how every small problem would not have happened if you had gone with their choice. Not a great way to build a productive work environment.

Sometimes, the debates don’t happen at all. Or they get written off as the argument of someone with an axe to grind, or of someone who doesn’t understand the practical implications. Or of someone who just wants to be different.

Recently, I was reminded of this last scenario when I had to do some administration on a server running Windows. Over the years I have developed a strong bias towards using Unix for everything. This includes the desktop, where I haven’t used Windows for anything personal in almost a decade. Well, except for the lonely copy of Windows XP Home which is used for playing games.

While I don’t like Windows as a desktop operating system, I see this as a personal choice. Everyone else can continue to use Windows so long as I have the freedom to use what I want.

I therefore recognise that I have this bias against Windows, which is why I only put up a half-hearted fight recently when a customer told me they were installing Windows servers throughout Africa. I lost and it didn’t take long for me to regret the decision.

I have to make my position clear. Others can use Windows on the desktop, but I have issues with using Windows as a server, particularly an application server buried deep in the bowels of a data centre without a screen or keyboard. My objection stems from the fact that the original Windows was designed for a single user, and for graphical applications running on a desktop. Many of those design decisions are still evident in the operating system today.

The first problem is ease of remote access. As a greying Unix administrator I far prefer a quick SSH connection to the tedium of setting up a remote desktop or VNC connection. It is bad enough when the servers are in the same building on a high-speed network, but when the connection goes through erratic, high-latency satellite connections it can literally take half an hour to log on to an application. Two users trying to log on to the same account on the same server can provide hours of fun, and waiting for 20 minutes just for the Windows login sound to play falls outside the bounds of what most managers would consider productive work.

The next issue is the difficulty of running background applications — services in the Windows world. These require one to write custom code to start and stop applications, and can behave unpredictably depending on how the application is started. Network drives can be a nightmare as drives mapped by the logged-in user can conflict with drives mapped by the system account. File-locking constantly causes issues, making upgrades hard to manage and sometimes making it impossible to read log files while the application is running. The registry might have seemed like a good idea at the time, but in reality has made it hard to manage configuration.

The permissions system in Windows is convoluted, and giving applications the ability to accomplish certain tasks can be a tedious and highly experimental affair. There are a number of different security subsystems that in theory should give finer control but realistically result in administrators enabling everything just to get an application to work. The fact that the security model changes from one version of Windows to the next, sometimes between different service packs, only makes the problem worse.

There are many other little features that can make managing a Windows server a painful experience. If you click in a command window, the process running in that window will pause indefinitely. Many applications like to pop up dialogue boxes on the active desktop and don’t provide any way to write the errors out to a log file. I have lost count of the number of times I have seen a late night batch process fail because an application was waiting for a user to click the OK button.

They say a bad artisan blames his tools, but there are limits. Sometimes it feels as if using Windows as a server is like giving a hammer and some nails to a master carpenter, or running a moving company using mini vans. They do the job, but there are much better options. I was reminded of this when I was writing this article: we had a critical Windows server become unusable for three days. Turns out it was infected with a virus.

If you are going to use Windows, then viruses are just part of the territory. They are a known risk, with no shortage of vendors pushing solutions to the problem. So I cannot really blame the platform for something that was an operational error. Instead, my issue was with how long it took to find the source of the problem — the application involved didn’t have any useful logging, the config was littered all over the registry and the actual issue was eventually identified by having someone go to the physical machine. Which in this case was 7 000km away.

One could argue that this was the fault of one application. Unfortunately, this application was not alone. It was following the same conventions used by too many other Windows application — conventions encouraged by the environment on which they run.

Yes, there are easy-to -manage Windows applications, though these usually require significant dedication from the developer and many dialogues to keep them manageable. With some effort it is also possible to customise a Windows server to have many of the features of a Unix box, including an SSH login, though my elitist side still wants to say that it is a poor imitation of the original.

There are times when using Windows as a server is unavoidable. When one wants to run Microsoft Active Directory, for example. Or Microsoft SQL Server, Microsoft Exchange or Microsoft file sharing. Any alternative operating system will obviously be a poor choice for running applications written in .Net — except for those rare examples that have been written from the beginning to work with Mono, the open-source, cross-platform alternative.

There are a number of arguments for using Windows: a common one is that the application in question only runs on Windows. This is understandable at first glance, but often one of the first requirements is that the application must run on Windows and nobody ever looks at the alternatives.

Then there’s these gems: other operating systems suffer from a skills shortage, they only run on expensive hardware and the local vendor doesn’t provide adequate support or charges too much. I cannot help observing that these aren’t really arguments for Windows. They also carry the implication that proponents are willing to settle for second best.

Of course, I could just be an IT zealot with a heavily biased opinion. Sometimes I think I’m being too harsh. But it’s never long before I’m presented with yet another example of why using Windows for a server is a bad idea, and my attitude inevitably hardens again.