[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Who could be able to help SW vendors to support Debian?

On 3 Feb 2005, at 5:53 pm, Eric Lavarde wrote:


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).

The RedHat kernel is considerably further diverged from kernel.org than Debian's is. This is one of the major issues I have with vendors only supporting Red Hat; Red Hat apply all sorts of patches and God knows what to their kernel.

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!

Well, this sort of thing happens with Red Hat AS as well. We've been having immense problems with it lately for Oracle.

 Game over!

Well, I'd hope you'd test the upgrade on a development machine first. :-) I agree that the continuous upgrade cycle of testing and unstable is not suitable for a support matrix for an ISV. It's one reason why Debian really needs to get Sarge out of the door - ISVs will only support stable releases, and Debian's stable releases are too few and far between.

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.

I understand what you're getting at, but nevertheless my example stands to show that ISV's can and do support purely on the basis of kernel and C library. Platform Computing have been working that way with LSF for years, and I haven't noticed them going out of business.

In their case this is because they only link against the really fundamental system libraries:

11:41:03 tjrc@rlx-1-2-3:~$ ldd /usr/local/lsf/5.1/linux2.4-glibc2.3-x86/etc/lim
        libpthread.so.0 => /lib/libpthread.so.0 (0x4001e000)
        libm.so.6 => /lib/libm.so.6 (0x4006f000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x40092000)
        libdl.so.2 => /lib/libdl.so.2 (0x400a7000)
        libc.so.6 => /lib/libc.so.6 (0x400aa000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

and the lim daemon is the only part of LSF which is really architecture-specific, and even then it doesn't do anything really scary; it just reads stuff out of /proc. Hence the fact that their support matrix requires certain kernel versions.



Dr Tim Cutts
GPG: 1024/D FC81E159 5BA6 8CD4 2C57 9824 6638  C066 16E2 F4F5 FC81 E159

Reply to: