Posts Tagged ‘OS X’
Over the years, I’ve tolerated a lot of operating system abuse. Earlier in my career, I tended to keep my mouth shut (mainly because I didn’t know any better), but over time, the annoyances have been building up into a crescendo of anger, such that at the end of the day I consistently find myself red-faced, foaming at the mouth, and screaming adjective interjection adjective noun, exclamation1 at my monitor. As the blood boils and the temper flares at the inanity I find myself forced to endure, I’ve consoled myself by deciding that I would some day vent my frustrations to the world at large.
This is that rant.
I’ve used variants of two main operating systems. I’ve decided to give them fake names to protect the guilty.
The first operating system, the older of the two, is known as Eunuchs. The first time I used Eunuchs, I found it strange and cryptic. I couldn’t understand its attachment to the command line, nor could I grasp why so many developers and universities were so enamored with it. My very first paid programming project involved me writing a deployment tool that was used to release Eunuchs applications to production. However (and I found this quite strange at the time), the developers wanted the tool written in that other operating system, so they could get a nice usable GUI for it.
That other operating system, which I’ll call MacroHard Windows, was all about the GUI. Their command line was terrible, and it is terrible still. Back then, being paid to write a GUI deployment tool, I didn’t see why that mattered.
I’ve written a lot of code since then, both in Eunuchs and with MacroHard tools, and I’ve decided that MacroHard is appropriately named. It’s hard. Really hard.
Windows is the worst development environment on the face of the planet
To be clear, I mean that without the slightest hint of exaggeration. For example, I understand times were hard in the early days of computing. I never had the opportunity to work on the ENIAC, but apparently it once went almost 5 days without a failure, something I have yet to achieve on any MacroHard platform. The first time I ever programmed anything, it was a blackjack program on my calculator. Programming on Windows makes me yearn for those halcyon calculator days of yesteryear.
Eunuchs has files and processes. Sure, it has pipes and sockets and runtime process information too, but those are just files, really. Sure it has network servers and daemons and startup commands, but those are nothing more than processes, and configuring them means putting a bunch of stuff in a bunch of files. If you want to manage them, you use file commands. Or process commands. Yes, sometimes they’re cryptic, and sometimes the names of things look like they were invented by 19 year old kids whose idea of social interaction was playing World of Warcraft, but it’s really not that hard to figure out once you get the hang of it.
Windows has files and processes and registry hives and COM+ catalogs and IIS metabases and app pools and Active Directory stores and Windows services and performance counters and event logs and global assembly caches. If you want to manage them, you open a barely usable GUI, and if you click into enough nested dialog boxes, you might get lucky and find the setting you need. Or you buy “enterprise” tools to manage them like Macrohard Operations ManagerTM, which has an entirely different maze of dialog boxes to follow. A colleague once put it better than I possibly could: The solution to MacroHard problems is to buy more MacroHard solutions.
Somehow, far too many IT executives have been sold on the idea that this is easier for people to understand. It isn’t.
Oh sure you can script these multitude of entities that Windows supports, if you have a new enough version of Windows. Of course, every component has a different scriptable interface. Hell, even IIS has multiple scriptable interfaces. You can use ADSI or WMI, but only WMI if you’re configuring an IIS 6.0 server. You can use C++ or VB to use ABO (admin base objects), or C++ to use specialized COM interfaces.
And sometimes, the canonical UIs that MacroHard want you to use interact with the subsystem you’re trying to script in such a way as to effectively remove any confidence in your scripts. For example, it’s possible to script your way into a disabled Windows service, where apparently the only way to remove the service is to shut down the services MacroHard Management Console Snap-InTM. If you’re a Eunuchs developer, you may want to re-read that last sentence, because it probably doesn’t appear even remotely possible to you that having a GUI open could prevent you from scripting the removal of a daemon.
But aren’t you being too hard on MacroHard?
I suppose there are some things that MacroHard has done better than Eunuchs. For example, MacroHard has Active Directory, which is an enterprise-ready LDAP security solution, not something you get out of the box in Eunuchs. And with Active Directory comes Windows Integration, where a bunch of applications that MacroHard wrote are integrated into the operating system in such a way that they automatically authenticate based on your Windows login. For example, they wrote one application (a particularly bad one, but quite widely used) called Internet Destroyer. It’s possible, as a web developer, for you to set your web site up requiring integrated Windows authentication. Anyone using Internet Destroyer to visit your website will automatically authenticate against your domain controller, which is occasionally quite handy.
However, the magic that makes that work is sometimes too obscure to fathom. For example, you can set up system-wide database settings in Windows called DSN’s. The DSN gives you two ways to connect to the database – using Windows Authentication, or using a SQL login. MacroHard also has a component called perfmon, that collects performance information for you, which has an option to log that information to a database given a DSN. Strangely, using a SQL login doesn’t work with perfmon, although good luck finding documentation that says so. If you’re a Eunuchs developer, you might want to re-read that last sentence, since it probably doesn’t appear even remotely possible that a process can’t connect to a database using a connection string with a database login.
Ok, but why are you really mad?
I’m mad because once upon a time, I wanted to know why a build failed, and that build happened to be using the MacroHard test framework called MHTest, as opposed to the open source alternatives, which are known for their annoying insistence to tell you why your build fails when it does fail. Here’s what I got with MHTest:
Test Failure: VerifyLogFilePath
At first I just found it amusing that MHTest told me what failed, but not why it failed. After all, that annoyance only manifests itself on the command line; if I used Visual Studio to run the MHTests, it’ll give me more information.
After a while, I thought it’d be nice to see how much of our code was actually covered by MHTest. Naturally, I tried to integrate that feedback into our build, which meant calling it on the command line. It turns out that MHTest’s code coverage spits out a binary file. If you want to interpret it, you’ll need to use Visual Studio.
But the good news is that, unlike the open source alternatives, MHTest randomly adds files to your projects and only works if you add magic GUIDs to your project files. This is actually a great feature if, like me, you get billed by the hour and you want large checkins to pretend that you accomplished a lot.
I’m mad because I wanted to run both versions 1 and 2 of Powershell on my machine (Powershell is MacroHard’s attempt at a less sucky command line), so that we could test against both versions, but MacroHard won’t let you run both on them on one machine. I’m mad because, for years, I thought that the Windows command line would randomly hang, but recently I discovered that if you accidentally click a mouse in a command window while it’s running a process spitting out console messages, and you happen to be in Quick Edit Mode (which is a Windows command line euphemism for completely unusable, but less so than the alternative), then the process will be paused, until you right click in the same command window. I’m mad because I like to test websites with multiple versions of Internet Destroyer, but without some crazy hackery, it’s not possible to run multiple versions on one machine. I’m mad because I installed MacroHard .NET 3.5 Service Pack 1, which forced me to close down every application on my machine – yes, forced, not asked – and reboot my machine, only to find out that it’s buggy enough that MacroHard feels compelled to supercede it with .NET 3.5 Service Pack 1 Service Release 1.
I’m mad because when I finally figure out the right combination of nested modal dialog boxes to pop up to configure IIS, I find a text box into which I cannot paste and from which I cannot copy, and whose ‘OK’ button is only enabled after accidentally clicking in the upper left hand quadrant of grayspace on the form. I’m mad because when I want to add a keyboard shortcut to Visual Studio I get a box showing me 3.87 commands at a time (out of hundreds) from which to select the command to assign the shortcut to, with no way to expand my view. I’m mad because I have absolutely no clue what error 0×00001ad59add means, and I am the goddamned system administrator I’m supposed to contact.
Mainly I’m mad because I love software development, and MacroHard has done much to lessen the joy that comes with hacking.
Reasons for optimism
Eunuchs is indeed an ironic name, given that modern derivatives can claim a veritable biblical list of progenitors: Eunuchs beget Minix, which beget Linux, which beget Knoppix… Those children have traditionally been considered as a better server platform than MacroHard, although MacroHard has made unfortunate inroads (in part thanks to one good thing MacroHard did – they were the first to realize that a “server” didn’t have to mean big iron). But the traditional advantage of MacroHard came from its desktop market, where until recently it had no competitors. It is one of the ironies of our industry that the competitor that now exists is the same one which MacroHard, in its infancy, was commissioned to help, and that the competitor now runs a derivative of Eunuchs.
OS X is becoming the de facto operating system for those who want to continue having fun developing software, but who like pretty and usable GUIs. It will never have much of a server market, but it doesn’t matter: what you develop on a Mac can be deployed to a Linux server with only minor gotchas like filename case-sensitivity. Many developers have never needed GUIs, or have been satisfied with the uglier (but improving) ones found in the Linux world, and they continue to have fun developing software. But I understand now why those developers who acted as the customers for my first paid project wanted a GUI: the command line is absolutely essential to development, but GUIs are helpful from time to time as well. Large portions of the Linux world have understood that principle for a long time, but it took Apple’s expertise on usability and their operating system’s Eunuchs heritage to provide the first OS that was both user-friendly and developer friendly.
Unfortunately for MacroHard, they are too weighted down by the enormous size of Windows to respond effectively. It took them five years to get Vista out the door, and that was only after removing every interesting feature from it. And even now, nobody uses it. As a software consultant with a history of working on MacroHard platforms, you’d think I’d know something about Vista, but honestly, I haven’t even seen it.
The development world is changing, and that’s a good thing. I have a feeling that the future of software development will be much more fun than it is now.
1This clever phrase was stolen from Steve Yegge: http://steve-yegge.blogspot.com/2008/09/programmings-dirtiest-little-secret.html