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…