Crouching tiger, coding monkey

“Insanity: doing the same thing over and over again and expecting different results.”
—Albert Einstein

“‘Holy crap no way that actually worked’: doing something, failing, ignoring it for years, coming back, trying again and having it work.”
—Grant Lammi

“Insane in da membrane (Insane in da brain)”
—Cyprus Hill

One of the things about working on a product that is cross platform is that every so often you have to jump to some other operating system to make sure that the bugs you just wrote perform equally as well everywhere. The other day I dusted off my Ubuntu Linux virtual machine and fired it up to do some testing. I hadn’t started it in a long time, probably six months or so since I had been using a different virtual machine. As I got to working the “You aren’t up to date why aren’t you up to date don’t you want to be up to date” nag dialog popped up.

Normally I don’t pay these things much attention, particularly for a VM I don’t use that much, and just click whatever makes it install everything. (That’s the “Shut up” button.) Before I made it there though I saw the button above it:

Does that say a new distribution is available by just clicking an upgrade button?

Does clicking on that upgrade this entire distro to the new version and actually work?

No way.

Or way?

Now before I go into what happened after I pressed the “Super magic I can’t believe this is possible because of my old jaded Linux experience” button let’s take a walk down memory lane.

I first starting using Linux in college in 1994. Back then it was the perfect storm of:

1. Being able to run Unix at home and not have to go to the labs
2. Being able to run Unix at home for free which was good since I was broke
3. Having enough free time on my hands to spend all night monkeying with kernel compilation settings trying to get my Opti Mad 16 sound card to actually, well, play sound.

I did configure; make; make install.

I did rpm -Uvh *.

I broke my local system by installing Evolution and its 60 bajillion dependencies so many times I can’t count.

When it came time to upgrade the distro I popped in the InfoMagic CD, backed up my /home directory, did whatever the README said, then sat around and watched the kernel compile.

And then I got a Mac with OS X. A new perfect storm hit:

1. I was able to still run a Unix at home, this time with a nice UI.
2. I had a job and was no longer broke.
3. I had a job and no longer had the tons of free time I had before.

Installing and upgrading turned into an exercise of clicking the shiny blue button and then getting a soda. I gave Linux a hearty handshake, thanked him for his service and wished him the best of luck in all his future endeavors.

So back to today. I hadn’t done a Linux upgrade in years. I hadn’t compiled a Linux kernel in years. Anymore I’d just toss out the VM and install from scratch. Today, however, I clicked the “Magic upgrade my Linux distro” button.

(What? Did you think I wouldn’t click on it? What kind of blog post would this be then with all that lead up? I’ll tell you what kind, a darned funny one. Oh well, sometimes you sacrifice comedy for operating system upgrades.)

So after The Click this happened:

Followed by this:

Which after a reboot resulted in this:

*Blinks*

*Points*

*Blinks*

Wow. It worked.*

So color me impressed and man has this stuff come a long way since the olden days. Does this mean I’m going back to Linux and giving up my seamless, rounded cornered Apple Mac fanboy membership card?

Of course I’m not. I didn’t click the “Go insane” button.

*Yes, I understand that Ubuntu has had this ability for years and I’m super lame for just now noticing it. In my defense it has been the Year of the Linux desktop for a decade.

I was first introduced to Linux when I was college in the mid-90’s. Well, it really wasn’t an introduction since it isn’t a person, but you get the idea. Back then all our coursework was done on VMS on a big old VAX which required to me spend loads of time in the labs sitting in front of a VT220 terminal. (Or if you were really lucky a VT420.)

All I know is that its text based interface on the 386 in my room let me procrastinate there instead of procrastinating in the lab. Plus my room had a TV.

Linux had me at LILO.

Fast forward to today and I came across a post at howsoftwareisbuilt that poses the question:

I’m curious, what are the specific issues that ISV and IHVs run into when they tackle supporting the various distros?

This came from reading a different post at Adobe. This talks about a world much different than my dorm room a long time ago.

“Personally, I liked the university. They gave us money and facilities, we didn’t have to produce anything! You’ve never been out of college! You don’t know what it’s like out there! I’ve worked in the private sector. They expect results.” — Dr. Ray Stantz

We’ve been shipping Linux versions of our products for years and have had a range of issues to fight through. (Required libraries, configuration file locations, etc.)

But the biggest issue, by far, without rival, is testing time. And this is also the issue that I think is easily forgotten about. When you have an open source project and someone downloads/compiles/installs your product and then it doesn’t work the conversation can go like this.

Person with problem: “Um, yeah, I tried to use XYZ and the ABC said the DEF was GHI’d up.”

Now the program maintainer can answer this question in a variety of ways, and here’s the kicker, ALL of these methods are legitimate.

Maintainer Answer #1: “Hmm, that’s weird. Let’s see if we can figure this out.”

Maintainer Answer #2: “I’m sorry but I’m super busy at the moment, you could post your message on the web and see if anyone else has seen it.”

Maintainer Answer #3: “RTFM.”

Maintainer Answer #4: No response at all

Maintainer Answer #5: “You have the source, you can fix it yourself.”

The problem you run into if you are an ISV is that only answer #1 is acceptable. Thus, in order to make sure that you don’t have pull a #1 very often, it becomes necessary to test your app as much as you can on various distros. And that, unfortunately, takes a lot of time. For instance, what if the user has only Gnome installed. Or just KDE? Or both? Or neither? In which of those cases do the fonts render correctly? Do they at all?

And this is all assuming that the application even runs. Let’s say you built it on Fedora Core 3. There’s a real good chance it runs on FC4, FC5, etc. What about FC2, that one might not work. How about RedHat 6.2, not much of a chance at all. SuSE 9.0, who knows?

So who knows, maybe someday this all won’t be an issue. I guess it is all just the nature of the game. Supporting Linux professionally is a lot different than just running it yourself. I suppose that’s what has caused us to grown apart. Sure we still interact, but it isn’t like it used to be. We’re just in very different places than we used to be. That time was magical though and I’m sure going forward we’ll still be good friends.

The other day I had the joy and the privilege to debug some printing code. Oh yeah, it was as much as fun as you might be thinking. To make it even better the bug was showing up only on certain distributions of Linux. Seriously, you can dial back the jealously now, I already realize how lucky I am.

Cursing at the printer took me back to my days in college working in the computer labs. Back then Linux was old Infomagic CD’s and getting anything to come out of the printer, whether it was what you wanted or not, was a major accomplishment.

*wavy screen and chime music*
*wavy screen and chime music*
*wavy screen and chime music*

The year was 1995-ish and this thing called the Internet was just starting to become all the rage. But that’s not really the point, that’s a cheap hook to set the tone and mood. Back then I was a “Student Lab Consultant” or some such title which translated directly into “Dude that sat at the desk with the phone in the public computer labs.”

Now being the dude with the phone meant that you did lots of things, but only three things were really important.

1. Help people clean off all the viruses they brought into the lab on the 3.5″ floppy disks that they’ve had since the 6th grade.

2. Consul them when said floppy from the 6th grade goes to that great disk drive in the sky taking their thesis with it.

3. Keep the stupid printers running.

That last one was the bad one. The first two the user had only themselves to blame, the other one was your fault. (Even if it wasn’t your fault, like say if there was no more blank paper in the lab.) It brings a warm feeling to my heart thinking about all the times an irate graduate student screamed at me because they couldn’t print out their research paper for a class that started in two minutes. No matter how many times I told them that a “A Study of the Radiation of the Enzyme Aldehyde Oxidase Decoduosomethingoranother in the Fruit Fly Drosophila melanogaster” probably wasn’t going to be a best seller it didn’t matter.

In fact, it is probably a testament to my fight or flight breakaway speed that I wasn’t bludgeoned to death with a toner cartridge. Or perhaps a thesis about fruit flies.

Regardless, the lesson then still applies today, printers are out to get you at all times. They are not be trusted and must be watched carefully. Speaking of which, I haven’t seen that LaserJet in a while, I wonder where he is…