2.6.13 Linux Kernel Released
LynuxFre@k writes "Linux Torvalds announced the release of the 2.6.13 Linux kernel. He noted that there was a major change to the x86 PCI code, and that while all bugs from the change were believed to be found during the release candidate phase, it's possible that some devices may have problems. From this release on, it is intended that major changes only be merged into the kernel within two weeks after a major release. The rest of the time will be spent fixing bugs, with the goal of both increasing overall stability and decreasing the amount of time between major releases. Download the latest Linux kernel from a kernel.org mirror."
I can't really understand why so many people have a problem with the current policy and the policy changes.
What exactly is wrong with refining the development process?
It's not THAT bad. Revision control system has been changed twice during the lifetime of the kernel. Developement-method has been changed once, and now that method is simply being tweaked a bit. And what do you care how they develop the kernel? Are you are kernel-developer?
Or how would you like them to do it? "We will do things this way, and by god, we will do it like this untill the end of time! Even if better ways of doing this comes along, we will not change our ways!"
Lesbian Nazi Hookers Abducted by UFOs and Forced Into Weight Loss Programs - -all next week on Town Talk.
Yes, unfortunately I have the same experience. I used to rely on the vanilla Linux kernel tree being rock solid. Now I feel I must stay many months behind in order to avoid potentially catastrophic problems. Considering the number of bug fixes, particularly w/ regard to security, that can show up in new kernel releases, it's not an ideal situation: you're damned if you do, and you're damned if you don't.
I've recently had networking go south when packets were being written to localhost. Some adaptec scsi stuff was recently messed up, apparently now fixed in 2.6.13 - but no way I'm going to try it until it's been out for a while. I've seen problems with quotas in combination with ext3. I recently started experiencing connection tracking weirdnesses with an iptables setup I've used at home for probably a couple of years. I've seen versions where network latencies would grow ever so slowly until they reached a critical threshold that sent my server(s) spiraling into oblivion. Yes, I file bug reports. Yes, problems get fixed. But at the same time, new ones show up. Sometimes bad ones.
I've become accustomed to rebooting Windows to fix problems, but that's exactly why I use Linux - because it was rock solid. I won't say that anymore, and it bums me out big time. I like new shiny objects too, but not at the expense of stability. Especially not on servers, which is where Linux has made the most headway.
The problem with the current versioning system is that even if there is a bug-fix only decimal release, and even if there is only a two week window to introduce new features, the bug fixing won't get done. Why? Because new features are more fun than fixing bugs. Even if I can't submit a new feature until several months from now, that doesn't mean I won't work on it in leiu of fixing bugs.
Linus should freeze the 2.6 kernel series against *any* new features at all, for a period of about a year. All work should be on increasing stability, ironing out bugs, improving device drivers, and other such menial housekeeping. The kernel contributers who really buck up, get to work, and help with this effort should get big karma bonuses from Linus. Those who hang back and work on their own thing should be pushed down a level in future kernel submission evaluations.
Sorry to be so negative, but I really hope this gets better. I'm a huge fan, but I have been wasting way too much time lately dealing with problems that end up being way beyond my control. When there is a problem with my systems, I want it to be my fault, because then I can do something about it.