Re: Linux (free s/w) support

Tue, 30 Sep 1997 15:56:32 -0400

On Mon, 29 Sep 1997, linux kernel account wrote:

> On Tue, 30 Sep 1997, Darren Reed wrote:
> > Are you telling me that hundreds, if not thousands of people have contributed
> > code to the Linux kernel ? How many of them could fix a problem with (say)
> > virtual memory or debug an obscure SMP problem ? The weight of numbers maybe
> > comforting, but expertise in any particular part may be limited to a handful
> > of people.

I know neither, but I was able to find a problem with umsdos and buffers
(when memory got full it locked instead of giving an error). I found
another problem with DMA v.s. non-DMA buffers - these were back in the 1.1
and 1.3 days. I can put printk calls since I have the source, so it was a
matter of about 6 to 24 hours narrowing the problem, and in both cases I
posted the problem and suggested patch (with a "if Linus and others say
this won't break anything, or can't think of a better way"). The next
kernel version implemented the fix. This was the experimental kernels, I
have never had reason to trace down anything like this in a "stable"

> Most such problems are simple typeo.. The oops can help you find it and
> get it fixed.. And I'm sure some green backs could help rearrange
> someone's priorities, esp if the problem is actually important. (Alan,
> David, Linus, any comments)
> > Whereas with Linux, you have people doing customer support who have never
> > been trained for support roles, probably scoff at it even being suggested
> > that they do any sort of training and can even be hostile in response if
> > it suits them.

If there is any real support training, it is either to sound like you have
no clue, or to be hostile. Generally if someone posts a repeatable
problem the response is to try X, Y, and Z to narrow it, or a fix.

> I have never seen a for-profit linux support company first hand, but I
> would be shocked if what you say above is true. Anyone here emploied by
> one?
> > A good example of why _NOT_ to choose Linux (from a support point of view)
> > is the lack of any problem tracking such as GNATS (well at least not to my
> > knowledge - I asked Alan if there was any database of interesting problems
> > reported, to which he said he had no knowledge of which I'm implying means
> > a lack of this. There's also an absence of any reference to PR's in email
> > on the linux-kernel mailling list...). Even FreeBSD/OpenBSD/NetBSD use
> > GNATS for tracking problems.
> Theirs a debian thing I think, prob a redhat one too.. I'm sure someone
> will correct you here.

I don't think there is official tracking, but usually if a bug is found,
the info gets posted and it disappears, or is brought up again.

When massive changes happen (like the filesystem change in the late
2.1.40's) too many things break to be tracked. But within a few days or
weeks the kernel heals itself.

> > You might have lots of people but there is no sense of co-ordination or
> > any sort of organisation of those people for problem resolution and nor
> > is there any central management of problems. An example of how this can
> > be a problem is if I post a problem and get 10 different patches to fix
> > the same thing. Each patch is different because nobody knows what the
> > other did and there is no tracking of what anyone is doing/has done -
> > unless they happen to cc an email list or others.

So you only care if there is a phone line with someone on the other end
after a 50 minute hold time at your expense, and spend 10 minutes
explaining that the computer is turned on, etc. If whether the problems
are actually solved and in a reasonable interval is irrelevant?

Someone should do a study to see the average time it takes to get problems
to be solved in each mechanism - the network security problems would be a
good example.

With linux, usually the author of the module, or of the latest version of
that module is reading the problem report. With commercial support, after
navigating a maze of support people, you may find someone who has actually
written a program to investigate.

Most fixes are cc-ed here, and one (or a composite) makes it into the next

--- reply to tzeruch - at - ceddec - dot - com ---