On Thu, 2006-11-09 at 14:04 -0700, Ashley M. Kirchner wrote: > Kim Lux wrote: > > Here is my post on the subject: > > > > "When I install a new kernel, my > > mouse doesn't quit working !" > > > > I didn't say the kernel provides mouse support in X ! > By making the statement you made above, you are suggesting that. No, I don't. I'm saying that when I install a kernel my mouse doesn't quit ! That is it. That is all the sentence says. > Now, if you said, 'when I install a new gmp rpm, my mouse doesn't quit > working', that would make a much better argument. No it wouldn't. The typical user doesn't know anything about a mouse driver. Doesn't need to. Shouldn't have to. It is a reasonable expectation that nothing quits when a new kernel is installed ! > The kernel has > nothing to do with the mouse, don't compare apples and oranges. You > will lose that battle. Users shouldn't have to know if the kernel has anything to do with the mouse or not. Just that the mouse shouldn't quit when they change kernels ! Get it ? > The issue here is that nvidia relies (heavily) on the kernel and > thus ties into several aspects of it. So do other pieces of hardware. > Under STABLE circumstances, this > works fine (as many have already told you.) Ummm... sorry, but it doesn't. First of all, thanks once again for introducing the red herring concept of me running a test kernel. If you keep repeating a red herring, sooner or later some people might get confused, but not really. If you read my original post, you'll note that I had problems building a driver for kernel 2798. As far as I know that kernel is considered stable. After all, it is running on most fc6 boxes. And the fact that the build failed is also irrelevant. THE RELEVANT POINT IN THIS WHOLE DISCUSSION IS THAT USERS HAVE TO *BUILD* A DRIVER IN ORDER TO RUN THE NVIDIA HARDWARE, unless they can live with what the non proprietary driver does. (Caps for emphasis, not shouting !) > But once again, you fail to > comprehend that. You want to run test kernels, that's fine. But don't > expect everything to work, otherwise it wouldn't be a test kernel. This has NOTHING to do with being a test kernel. Are you dense ? The nvidia driver has to be built for EVERY kernel and for me the failure rate on that build is probably 50%. > The > NTFS module also ties in to the kernel, and when there are kernel > updates, I have to wait a day or two to actually install the kernel > because the NTFS module hasn't been applied to the new one yet. Funny, I run ntfs on our server and I don't know a darn thing about how it ties into the kernel ! I run yum update on the server, it does its thing and I'm done. ntfs has never failed to run when I've rebooted. That is the way software is supposed to work. > But > that's just it, I WAIT FOR IT because I know it makes absolutely no > sense in running the new kernel while not having the updated drivers, > and then come bitch and moan that things don't work. Get that into your > mind please: everything will, at some point or another, lack behind a > kernel update. Funny, but the only thing that lags behind a kernel update for me is nvidia, now that I run bcm43xx instead of ndiswrapper. > It's YOUR responsibility to make sure you have the > correct drivers, modules, and/or patches BEFORE you update your kernel. Well, funny thing about that, with nvida YOU CAN'T ! At this point I would like to know if you have ever built an Nvidia driver ? Here is the thing... as far as I know, one can only build an Nvidia driver for the kernel that they are running. Maybe the wizards know a way around this, but, like I said before, I have a life outside of Linux ! So what happens is you boot with the Nvidia driver and then you build it and that is when you find out if it works or not. > Whether the nvidia folks decide to take 24 hours or 24 days to release > an update, that's THEIR call, and they will have a reason to do that. And to hell with the Linux folks and what they need. Because here is the thing... I don't have to wait 24 hours or 24 days for the ntfs driver or the mouse driver or any of that. It just seems to be there when the kernel is ready. I have yet to update a kernel and lose use of ntfs or my mouse ! > How many times haven't you heard Microsoft delaying a critical update, > while other third party companies have already released theirs? They > have a reason to, whether it's for more testing or because the guy > responsible is taking a long piss. See, now open source software is different for all the other drivers other than those from nvidia. That is my point ! The source is there and when the kernel gets built, so does the latest driver with all the recent updates in it. Its a beautiful system ! Kudos to Linus and the boys on a job very, very well done. I won't say what I think of nvidia being the exception to this system ! > GET OVER IT and deal with the fact > that YOU, and only YOU made the choice to run test kernels on your > hardware. No one told you that you must. Once again this has NOTHING to do with running test kernels ! If I change kernels right now, to one I have run before, guess what ? I have to build another Nvidia driver ! Doesn't matter if the kernel is a bit torrent from www.kernel.org or 2.4.x ! Livna *might* have a driver built for it, but then again, they might not. Funny, I don't have to go to my mouse manufacturers and download an install script for my mouse ! > Once again, if you want to run test kernels, DO NOT EXPECT > EVERYTHING TO WORK WITH THEM. It's the whole nature of being a test > kernel (or any other package for that matter.) Once again, nothing to do with the fact its a test kernel ! > It's for people to find > the problems and report them, and not for you to come bitching and > moaning because you lost some precious 60 minutes of your life. You > know what, I couldn't care less how much time you lost. I didn't expect you to care about how much time I lost, I expected you to realize that there is some potential to improve Linux in this regard and focus on that. -- Kim Lux, Diesel Research Inc. -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
