HW/SW Linux certification [LWN.net]

HW/SW Linux certification

Posted Dec 15, 2005 15:07 UTC (Thu) by bkw1a (subscriber, #4101)
In reply to: What about vendors? by tclark
Parent article: "Just works with Linux"

I like the idea of a "just works with Linux" sticker program, giving
vendors the right to put a recognizable logo on their packaging if
they can verify that their hardware works with the mainline linux kernel.
(Of course, there's still the question of whether it'll work with
the available user-space tools in a given distribution, but at least
it's a start.)

I'd also like to see a similar program for software. More and more,
I find that software that claims to "work with Linux" really only
works on some very recent distributions. I support ~ 200 Linux
machines, and my users frequently complain that they've tried to
install some software, only to find that we'd need to upgrade to a new
distribution version to get the software to work.

This is only partially the fault of the software vendors. They
understandably can't compile many different versions of their
software for many different distribution versions.

The second big contributor to the problem is the lack of support for old
APIs. Under Windows, I can install the current version of Acrobat
reader on machines running Windows 95,98,NT,2000,XP or 2003. Software
written today will still run on Windows versions 10 years old. In
contrast, in the Linux world, a QT- or gtk-based program written
today won't even run under a distribution released last year.
This is frustrating for both vendors and users.

I don't know the solution to this second problem. Maybe just
more-stable APIs. Maybe some way of gracefully failing when a
newer feature is found not to be available. I think it's
a problem that really needs to be addressed soon, though, if
Linux is going to be accepted widely on the desktop.

(Log in to post comments)

FUD, FUD, FUD

Posted Dec 15, 2005 21:52 UTC (Thu) by khim (subscriber, #9252) [Link]

Under Windows, I can install the current version of Acrobat reader on machines running Windows 95,98,NT,2000,XP or 2003. Software written today will still run on Windows versions 10 years old.

Check your facts - or you'll look ridiculous.

Let's check your facts, shell we ?. I'm happy "10 years old Windows" user. 10 years old Windows is "Windows NT 4.0" or "Windows 95". Let's start !

I'd like to install Acrobat reader. Latest and greatest is "Acrobat reader 7.0.5". Can I use this ? Of course not! Acrobat reader 7.0.5 is only compatible with Windows XP - not even Windows 2000 is enough (not without SP2 anyway). Oh, too bad. Can I use Acrobat reader 6.0.1 instead ? Nope: you need Windows 2000 or Windows 98SE (Windows 95 or Windows 98 are not supported). Oooh, ok. How about Acrobat reader 5.0.5 ? Still no cigar: Windows 95 or Windows 98 is required (Windows95 user is happy at this point: he/she got only two generations old Acrobat reader; Windows NT 4.0 user is still not). Argh. Can I at least use Acrobat Reader 4.0.5 ? No: even this thing is only compatible with Windows NT 4.0 SP3, not my "10 years old Windows". My only hope is ancient Acrobat Reader 3.0.1... Four generations old...

How is this for "support for old APIs" ? Sure: I can install ancient Acrobat Reader 3.0.1 on my Windows XP SP2 - but that's not such a big achievment: most distrost do include compatibility packages.

P.S. Big thnx for selection of package - some new programs are still runnable on old versions of Windows. Acrobat reader is not one of them.

HW/SW Linux certification

Posted Dec 16, 2005 2:38 UTC (Fri) by zblaxell (subscriber, #26385) [Link]

I seem to keep running into the opposite problem: Someone asks me to install a Linux binary they found somewhere (in some cases after they paid six figures for it), and I hear that the thing supposedly only runs properly on six-year-old versions of Red Hat. Often the word "run" is generous, and in a number of cases I have forced vendors to admit that their software limps like a wounded waterfowl at best on any Linux version, but there is no hope at all of this software working on a modern Linux distro.

A quick phone call to the vendor followed by some not-so-quick escalation up the support ladder and I end up talking to some engineer who is working on porting the application to a three-year-old version of Red Hat. It should be ready for general release next quarter.

Fast forward a year, and the sales weasel comes to install their "new" software on the now-four-year-old version of Red Hat. I thoughtfully dig through my CD-R archive and provide a machine with exactly the specific old Red Hat version requested. I even provide a second machine with all the official updates to that Red Hat version applied. Both are running a vanilla configuration unless the weasel specified otherwise. Neither works out of the box with the weasel's software, although they fail in different ways.

These days I'm sick of playing the "supported platform" game. I just tell the weasel what we have on our desktops ("here's the install CD guys, have fun"), and that we'll pay only for whatever parts of their software work after they are installed.

HW/SW Linux certification

Posted Dec 16, 2005 14:42 UTC (Fri) by khim (subscriber, #9252) [Link]

It's the same in Windows world. I know one case where vendor two years ago (that's 2003, folks!) finally started to support... what ? Windows 2003 ? Windows XP ? Windows 2000 ? No! Windows NT 4.0SP6a!!! Yup - till that time they only supported "Windows NT 4.0SP5"! Situation is quite similar to Linux versions, right ?

HW/SW Linux certification

Posted Dec 16, 2005 23:08 UTC (Fri) by zblaxell (subscriber, #26385) [Link]

I know of one vendor who is *at this moment* in the process of porting their application from Windows 3.1 (with 16-bit DLLs and everything) to Windows 2000.

On the other hand, at this moment the old Windows 3.1 binaries do work on Windows 2000 if you install all the relevant backward DLLs...I wish the major Linux distributions made it easier to do that.

SW Linux certification

Posted Dec 22, 2005 22:07 UTC (Thu) by anton (guest, #25547) [Link]

>a QT- or gtk-based program written
>today won't even run under a distribution released last year.
>This is frustrating for both vendors and users.
>
>I don't know the solution to this second problem.

Possible solutions:

- Build on old distributions. The resulting binaries often work with
new libraries. However, sometimes they don't, but that can be
tested relatively easily (test it on a system with new libraries).
The disadvantage is that the program would have to restrict itself
to the ancient API.

- Use static linking. This has some disadvantages wrt security
updates and on-disk and in-memory size, but it could be supplied as
a fall-back option (the old system probably does not have the
updates anyway).

- Compile the program from source (or use a source-based distro like
Gentoo). At least that gets rid of some gratuitious
incompatibilities thrown in by linking with modern libraries,
although not from the API dependences.