Electric Sheep

Back in the 1970s, there was an operating system called UNIX. It was a neat idea developed by Bell Labs and ultimately grew a huge following that resulted in numerous spin-offs and workalikes. Every Linux and BSD, from Ubuntu to OS X, can look back at the original Ritchie and Thompson UNIX and give thanks.

But that original code doesn't exist anymore, right? Right?

UNIX, proper and true UNIX-brand UNIX, was owned by AT&T, and like all good companies, they just licensed the hell out of it. They sold it and resold it and transferred it and it was rebranded and reforged by a dozen different companies. Eventually it was obtained through a merger by a little Utah outfit called SCO.

Just so you know, SCO was recently asked to delist from the NASDAQ because its stock price is so low. There is a reason for this.

SCO has a bunch of different products, UnixWare and OpenServer being probably their best-known operating systems. They're famous for pretty much two things. One, people detest their products and two, they're actively trying to sue IBM for infringing on "their" UNIX intellectual property.

I don't intend to discuss the lawsuit. If you want that, read Groklaw. What I'd like to discuss is what the hell is wrong with SCO.

There is, I think, a reason why Linux is so popular. Yes, it's inspired by UNIX. Yes, it's fast and efficient and has a ton of software packages that support it. Yes, it's (usually) free. But on top of all of that, it's easy to use.

Now before you spit Coke Plus all over your keyboard and monitor, you have to understand that Linux isn't meant to be easy for your mother or your brother to use. It's not meant for them to use at all. It's meant for use by developers and technically-adept users, of which there are legion. And for these mighty code and script gurus, Linux is an easy and fun place to stage all your computing operations.

By contrast, SCO is still bolting bits and bobs onto an operating that was meant for use by hardcore FORTRAN geniuses. SCO's offering, in the 21st century, is essentially the same platform that your grandfather was using back in his college days. They've rebranded it, but they haven't exactly improved it.

When Dennis Ritchie sits down at a Linux machine, I can only imagine that he quietly awes at how far his ideas have gone and how many bright people have solved the problems he faced back at Bell Labs. A modern Linux system has graphics, advanced browsing features, and a plethora of shells that feature, by default (gasp!) tab completion.

Whenever I find myself touching a SCO server, it is with absolute disgust and disdain for how little the product has changed. Compiling anything on a SCO system is a chore because of the numerous ABIs they've introduced, changed, and revamped. Kernel compatibility technically exists, but you are hard-pressed to actually see it work. And if you try to do it better than SCO can (and doing something better than SCO can isn't even remotely hard), they'll sue your sorry ass for violating the IP that they rightfully own solely by Mandate of Checkbook.

So SCO is hemorrhaging money, and they can't offer a cheap, stable, usable, or modern product. It's only a matter of time before they become so desperate to pay off the shareholders that they pass off the cursed UNIX copyright to some other company that will try to wring some value out of it. The cycle will repeat: revamp, market, slander, then sue as a last resort.

Meanwhile, the rest of the world has seen the best UNIX can offer, and have already improved upon it tenfold. You can download and burn an operating system, as UNIX-y as you want it, and effortlessly do things that your grandfather only dreamed of doing on his old mainframes.

Compatibility be damned: if you want to make a good product, you need to lose sight of the licensing aspect and focus on usability. If SCO made software that was usable, they might actually be able to sell it.

Today a friend of mine IM'd me asking for advice on how to bridge a MySQL database with .NET. Aside from the fact that I normally charge a significant amount of money per hour to answer questions like that, I found it interesting that he was asking me for advice on a subject I was, at that very moment, executing on behalf of a client.

The client has a Microsoft SQL Server database that has some very important data, and a Linux-based MySQL server that runs a very important program. Hmmm.

My first two approaches involved writing scripts to be run on the Linux server to pull information from the Windows system and push it into MySQL. Approach one was a script that would connect to the SQL Server via ODBC, pull records, and push them into MySQL. Perl, Python, Ruby, whatever. There were numerous languages that could perform this function. The key ingredient, of course, is a Linux-based ODBC driver.

Sadly, ODBC drivers for Linux come in two classes: trial versions and the kind you have to pay for the privilege to use.

Well, I for one refuse to call up my client and tell them "Hey, great news on the project. We have a script that can speak ODBC to the SQL Server and everything's going to be just peachy for 14 days. After that, you're going to have to buy a license for an amount of money that is undisclosed on the company's website (never a good sign). Oh, and before I forget: upgrading the OS or making a change to your hardware contractually invalidates the license and requires you to purchase another one. Oh, and the drivers won't run unless the licensing service is running, too. Toodles."

Screw that. I don't mind -- too much, anyway -- paying for quality software. But to expect me to continue paying? For something I already bought? I refuse to let my vendors treat me like a criminal, or anything other than a customer who has purchased a product and now has full rights to use it in whatever manner he sees fit.

I also don't buy DRM'd music. Go figure.

Approach the Second was a slightly more convoluted idea: export the data from the SQL Server to a Windows share that is mountedon the Linux system via Samba. The script in use here was a simple line-by-line parser that only dealt with a comma-delimited text file and MySQL.

After about three minutes of explaining approaches the First and Second to my boss, he blinked, asked me a basic question about ODBC, and then asked me if it would be possible to hook an ODBC driver directly into the export wizard in Windows.

Blink.

MySQL is free, and so is the ODBC driver that they provide for it. No trial versions. No "Lite Editions". MySQL offers it as a simple download on their site: you don't even need to register or create an account. I downloaded the ODBC connector, installed it, and had the DTS export configured and working on two separate systems in under 30 minutes.

So, to recap: pulling from SQL Server to MySQL via ODBC? Expensive. Licenses. Scripting. Pushing from SQL Server to MySQL via ODBC? Faster. Easier. Safer. Free.

To the extent that I found a better solution because I wanted to avoid the draconian licensing problems of the first, most obvious solution, I'm glad I spent an afternoon working on an alternative. I do not feel that there is anything to be gained from the idea of "lending" someone your software for a limited time and contingent on them never upgrading or changing their system in any way.