On Fri, 16 Jul 2004 11:53:44 -0500 (EST) Net Llama! <[EMAIL PROTECTED]> wrote:
> On Fri, 16 Jul 2004, Collins Richey wrote: > > On Thu, 15 Jul 2004 21:22:38 -0700 (PDT) > > Kevin OGorman <[EMAIL PROTECTED]> wrote: > > > > Based on my recent research, here are my recommendations: > > > > 1. If you want to be assured of xfs support, get the latest 2.6 > > kernel recommended by xfs. xfs appears to have little patience for > > kernel development, and they control the game, so you will be best > > served by following their rules. > > That's not quite accurate. The XFS developers actually have an > amazing amount of patience for their user base. They go out of their > way to help out. But they're not going to spend time debugging > bizarre problems on a kernel that is a year old. > No one would expect them to work on a year old kernel. The archived entries on the xfs list re gentoo indicated that they didn't like to see patches they hadn't approved and they seemed to believe (but did not document) that patches they preferred to see were not present. > > 2. If you need features/bugs that have been fixed in later 2.6.x > > releases, get the latest plain vanilla 2.6 kernel from kernel.org. > > xfs may still gripe if they haven't gotten around to thinking about > > this release, but maybe you'll be lucky. > > THat's complete & utter BS. Collins, until you actually run on a XFS > file system, don't start passing judgement on it and how its > supported. > Once again, based on the bitter language I encountered in the archives. > > 3. If you need different kernel support, toss in some chicken feet, > > backup, backup, backup and go ahead. If you need xfs support, you're > > probably out of luck, since they have this immature (IMO) attitude > > that anyone using a kernel release not blessed by God and xfs (or > > reversed) doesn't really have a valid problem and, of course, in the > > best of all possible worlds gentoo would cease to exist (why else > > was RH created if everyone doesn't use it?) > > More BS, and you're just trolling now. > Direct quote from the archives. Sorry, I failed to add ... or Debian. "NEVER USE GENTOO. Immature Hacks + Bugs == Gentoo. Please get a real kernel from oss.sgi.comand see if that helps. Better still, RUN, don't walk, and get Red Hat or Debian installer." > > > > 4. Final option, use ext3 and worry less <g>. I haven't ever read > > about kernel developers being unwilling to work an ext3 problem. > > Come to think about it, I've read about extremely few ext3 problems. > > That's cause most people who care abou their data don't use ext3 in > the first place. Now can we drag this converation back from troll & > flame bait land?? > No flame bait intended. I have no objection to xfs; I may even try it some day. "Most people who care about their data ..." is, of course, flame bait as well. The one thing I won't do (based on the comments I found in the xfs archives) is use an experimental kernel and expect from xfs developers the "amazing amount of patience" you have experienced, most especially not if I'm running the accursed distro. It goes without saying that a number of gentoo users (by no means even a majority) like to push the envelope by exploiting kernels on the leading edge of development. I don't find it to be extremely helpful to offer comments like those in the xfs archives where gentoo is maligned because the user has chosen to employ an experimental kernel. Nor do I find it helpful where a few gentoo developers have maligned xfs in the past. Nobody is totally innocent in this game. I get a very different sort of response from gentoo developers when I report a problem that is based on non-stable components. They first attempt to analyze/fix the problem (or pass the problem upstream to the package maintainers) rather than maligning me for my choice of components. I would expect the xfs developers to be more sensitive to new kernel development (maybe they are, but it's far from obvious in the archives), since what is bleeding edge unapproved patches today may become a stable release tomorrow and, lo, the filesystem problem is real, now affects more than one user, and who is caught with their pants down? This doesn't mean drop everything you are doing to analyze one-off problems, but I find the attitude "we don't know of any problems, must be your kernel, we're not willing even to take a look" to be unprofessional. I know that attitude seems to be prevalent, however, with large, for-pay distros."You're not using an approved fix; goodbye." Maybe, but if I were a filesystem developer, I would want to be damn sure that a corrupted filesystem is not my problem before going into attack mode. There are various possibilities with a patched kernel: 1) the kernel patches are faulty and my code is clean 2) the kernel patches are ok and my code is broken 3) the kernel patches are faulty and they have exposed a disastrous flaw in my code. Assuming that case 1) is always true for an experimental kernel is not safe practice, IMO. Perhaps the xfs developers have looked into the problems more thoroughly than is documented in the archives, but that is not obvious from the entries themselves ,nor can I detect any form of "amazing patience" but rather blistering invective. The entire purpose of experimental kernel builds is to try out new ideas (that are hoped to be sound) and to flush out any bugs. How is progress to be made if the filesystem maintainers (seemingly) take the attitude that testing is not welcome and (even more) that no true filesystem problems can arise from a testing environment? Some of the ideas in experimental builds will be discarded, but others are sound. Why not seize the opportunity to close up any possible holes in the filesystem code based on the test results? There is always the possibility that the gentoo users who test experimental kernels are not bumbling idiots and that they are providing a valuable service. In theory at least, the filesystem code should be robust enough to survive some failures in kernel code. -- /\/\ ( CR ) Collins Richey \/\/ fly Independence Air - they run Linux _______________________________________________ [EMAIL PROTECTED] Unsub/Pause/Etc -> http://mail.linux-sxs.org/cgi-bin/mailman/listinfo/general
