Messages in this thread | | | From | "Christopher A. Smith" <> | Subject | "2.0.31", etc. -- ENOUGH, please! | Date | Thu, 17 Jul 1997 13:06:21 -0400 (EDT) |
| |
Folks, could we PLEASE put the "2.0.31, please," "Take a Deep Breath," and other related threads to rest and get on with kernel development and discussion??? Except for restating a few key points, I'm not sure these threads are serving any real purpose anymore, except to frustrate valuable, hard-working developers like Linus, David Miller, Alan Cox, Ted Ts'o, and others.
Could we all please agree on a few points, which've been true throughout at least the past couple of years, if not the entire Linux history:
1. Odd-numbered kernels, like 1.1.x, 1.3.x, 2.1.x, etc. are development kernels and do not come with any warranty or guarantee, may cause cancer in lab rats, may affect the ozone layer, may fuel conspiracy theories, etc.
2. Because of the millions of possible combinations of motherboards, BIOSes, controllers, etc. there's no way to offer a 100 percent guarantee that every kernel, whether it be production or development, will compile in a given environment.
3. You should ALWAYS be careful when installing a new kernel, whether it be a production or development Linux kernel, or a new Solaris, HP, etc. kernel, or a new MS Windows or MacOS version. Test-drive the new beast in a non-critical environment, and keep a copy of the last stable kernel around. If the test works fine, then deploy. If it doesn't, then back up to the previous good kernel. (The same rings true for all software, not just kernels.)
4. If you find a compilation error or a runtime bug with the kernel, try to gather as much information as possible and report it in a polite manner. The Linux community has come as far as it has because of cooperation and civility, not confrontation and hostility.
5. If you feel you can make a contribution to the development, maintenance, documentation, testing, etc. of the kernel, then please do, but PLEASE respect the work and wishes of the maintainers.
Yelling at or destructively criticizing the kernel developers for kernel design, bugs, testing problems, documentation problems, etc. won't help; I quit my last job because management did just that, and, well, the ramifications were fairly significant, especially when colleagues followed me. I'd hate to see Linus, David, Alan, Ted, or others give up for similar reasons. Help out where you can, but if you don't have the time, skill, or resource, then be patient and make do with what you have. If that's not feasible, then look at some of the Linux competitors, but be ready to pay thousands of dollars to have any problems taken seriously.
Just my opinion -- I could certainly be wrong. If you feel I am, please respond to me privately, and let's let the list get back to fixing bugs, adding new features, etc.
-------------------------------------- Christopher A. Smith Arlington VA * casmith@clark.net
| |