> I can't speak about RAID, but do you understand that NFS is broken in its
> unpatched form? HJ's and many of Trond's changes are **bug fixes**.
> Sure, there are people out there using the NFS included in the kernel,
> but they are not doing anything serious with it. If they were, they would
> have seen and complained about RPC problems, attribute caching problems,
> stale file handles, inode revalidation, locking, ... Some groups, like
> mine, are locked into an NFS-centric environment: 40 machines, mounting at
> least four different remote filesystems, with lots of concurrent access.
I understand that the unpatched NFS is broken. All the environments I deal
with are NFS-centric. The patches are as much of a hassle for me as for
anyone. I have not argued against bug fixes getting into 2.2.
My main point was that the thread had gone on for a dozen posts without
anyone specifying whether they were talking about 2.2 or 2.3 and how
clearly this shows that some developers make little if any distinction
between the developmental and the "stable" series.
> The fact that some userland tool needs to be updated when the kernel is
> updated seems to me irrelevant....
A kernel that is being updated (aside from bug fixes) is being developed.
I think calling such a kernel "stable" is unfair to those looking for
stability.
> Much more troubling to me
> is having to ... extract just the bug fixes from the stable patches,
Exactly. Someone who wants stable kernels should not have to extract the
bug fixes from the developmental updates.
> If you think Linux is the only system with configuration management
> problems, just try dealing with Sun's (confusing and frequently broken)
> patch clusters.
I've been applying Solaris and SunOS patches since 1984. In some ways,
(official) Linux patches are better than the Solaris patches, but there is
room for improvement.
Everyone seems to agree that the "stable" kernels could and should be more
stable. I've suggested a methodology for achieving increased stability.
Several posters don't like my suggestion, but they haven't offered an
alternative.
M Carling
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/