Hi,
as I understand myself as someone aware of the support problems of software problems, I would like to point to 2 problems:
1. the Debian Kernel is a bit different from the kernel.org Kernel; example: at work we used the Apani VPN client, which did work under all kind of RedHat/SuSE kernel, but not under the Debian kernel, even though there is some compiling done at installation time (i.e. not only binary modules delivered).
2. as a software provider, you need to be able to reproduce the problem of your customer to solve it (at least for non-obvious problems), so that you can reproduce the problem in your environment, debug, correct and test again. (I would also imagine there could be some legal implications if you are officially supporting a certain setup, but practically aren't able to support it properly; but we want to stay out of the court ;-) ).
What is the consequence? you need a limited amount of possible combinations, you need to have a stable system (in the sense: not changing every three weeks) and you would greatly appreciate to be informed of changes that might break your system before your customer actually installs the patch/update/whatever.
Imagine a customer doing regularly an apt-get update & upgrade in order to be sure to have the latest security fixes, and all of a sudden, your expensive software stops to work, at all of your customers, almost at once. You're out of business! Game over!
I'm exagerating a bit but that's what they want: no surprise, be able to clearly define what is supported and what not (e.g. self compiled kernel or not?!), have a chance to test before their own customers do.
This said, I don't have a clue who at Debian could provide this to them; though I'd think Debian is probably best in these aspects than some other platforms starting with W. Probably some training to understand how Debian is working and structured might just be what they need.
Cheers, Eric
Tim Cutts wrote:
On Tue, Feb 01, 2005 at 07:37:27PM +0100, Christian Perrier wrote:
Would any people around have pointers which could be given to such people?? Do we already have an entry point for such technical issues as proprietary SW vendors needing technical information about the way to support Debian??
The first thing I would do is to try to convince the vendor not to get so hung up on supporting different distributions. If their product depends tightly on kernel stuff, then they should base their support matrix on kernel version, not on distribution.
Point them at Platform Computing as an example of how to do it with LSF. They support Linux, and they don't give a stuff what distribution you're running. They support certain kernels, and certain C libraries, and other than that they don't care. And they're not too precise about kernel version - on X86 you can run any 2.4 or 2.6 kernel, and any 2.1, 2.2 or 2.3 glibc. They're a little pickier on other architectures (they don't support 2.6 on either Alpha or Itanium yet).
Tim
-- Gewalt ist die letzte Zuflucht der Inkompetenz. Violence is the Last Resort of the Incompetent. Gwalt jest ostatnem schronieniem niekompetencji. La violence est le dernier refuge de l'incompetence. ~ Isaac Asimov
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
