Re: Who could be able to help SW vendors to support Debian?
On 3 Feb 2005, at 5:53 pm, Eric Lavarde wrote:
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).
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.
Regards,
Tim
--
Dr Tim Cutts
GPG: 1024/D FC81E159 5BA6 8CD4 2C57 9824 6638 C066 16E2 F4F5 FC81 E159
Reply to: