Here's the latest chapter in the trials and tribulations of a linux junkie.

Last year I worked an embedded project for a government customer. A lot
of the design decisions were made before I came on board and then the guy
who made those decisions quit. I ended up taking the path of least
resistance and tried to stay in the direction he laid out...for the most
part. We used a RISC power-pc based SBC as the brains of the unit. Of
course the thing ran linux 2.4. The SBC linked with several custom
designed hardware modules that proved to be hard to support, buggy, and
expensive to develop and maintain.

Our current scope of work is to improve on the previous design. I took
this opportunity to move much of the functionality done in the custom
hardware back into a newer ia32 based PC104+ board stack using COTS
components. This gives us the ability to do more enhancements in software
and to streamline the process flow a great deal.

One of the custom hardware components I want to get rid of is a unit that
encodes NTSC video into a JPEG2K stream and also handles two way audio.
The original assertion regarding JPEG2K was that it is tolerant of packet
drops and could be compressed way down and reliably transmitted on an
unreliable network link. This proved to be a pretty serious mistake.
Decoding of JPEG2K is a CPU intensive task, the data stream could not be
compressed down to a reasonable size, and there was no ability to
pre-scale the images before encoding.

I've been trying to find a PC104+ MPEG4 encoder to handle this task and
thought I found one. I bought an encoder that advertised all of the
functionality I needed: pre-scaling, control over constant bitrate
encoding, ability to control IPB frame sequencing, and multiplexing of
audio data in several different formats. Once I got the unit and started
playing with it I found out how much I was mislead by the vendor.

My review of the linux driver code and support documents shows that this
unit is pretty much worthless in the linux world. I cannot even start and
stop the encoding process without removing the driver module and reloading
it...and the linux driver only supports a very lean subset of the
advertised functionality that (you guessed it) is only available in the
windoze dll or under an NDA...and if I sign an NDA all I get is the
schematics for the board and datasheets for the components on the board. I
will get no additional linux support from the vendor. I feel cheated
because I went over these issues and my expectations with the vendor sales
rep and their tech support guys before buying the unit. I was
assured that the functionality was there.

I've got too much work to take the time to modify and debug kernel
drivers, especially when dealing with components that don't themselves
have open source APIs. My expectation is that when a vendor advertises
linux compatibility they have made sure that all the advertised functions
are available and reasonably tested...of course I'm too often reminded
that in the linux world testing is on the burden of the user and that most
often developers take little responsibility to test their products before

This scenario also recently reared its ugly head when I tried to get a
Peak dual channel CAN card working on the new board stack. The driver
documentation was translated by some Deutsch folks and is out of date. I
could not get the driver to compile and contacted their technical support.
I got an email back that included the new parameters to compile under
recent 2.6 kernels. The email also included a written slap on the wrist
telling me to read page 42 of the driver documentation PDF file where I
was suppose to see the option in question. Well, I compiled the driver,
then looked at the PDF file. Guess what? No mention was made about the
new parameter. I emailed the guy back, thanking him for the information
about the parameters but asked him to check his documentation to make sure
the new options were in the docs. After that he pretty much called me a
liar and made a really bull**** elitist comment about how I should read
the driver code and make it work because "that is what linux is all about".

I expect and tolerate that kind of dialog when dealing with unpaid
open-source kronies who are playing with linux for intellectual
stimulation but when commercial vendors play that game...well, these are
the reasons why linux will always be the exclusive domain of masochists
and damaged folks who like to play with "puters" and why it will not be
adopted on a wide scale in the real world.

To summarize...When I ask a support question on the web I better know
what I'm talking about and I expect to get the wide range of comments from
folks with different personalities and agendas, but when companies say
they are going to develop and support linux products they had better
understand that linux does not give them a license to act like snot nosed
uber-hacker children.

Maybe I should just retire...or move into (god forbid) MANAGEMENT!!! Nah,
I'll just spend a few hours playing with BSDI on my old 386 to

Flame away.