Submitted by The Linux kernel version 2.6.17 has been released. Not a lot of changes since the last -rc; the bulk is actually some last-minute MIPS updates and s390 futex changes, while the rest tend to be various very small fixes that trickled in over the last week.
The changes are listed at KernelNewbies (don’t look at me for the name).
…is 2.6.18 the one that’s supposed to be a “bugfix-release only”? ‘Cause it would be nice to have such a release, if it didn’t happen already. 🙂
is 2.6.18 the one that’s supposed to be a “bugfix-release only”?
That was just some ramblings on a listserv – AFAIK there are no current plans to do a release like that.
Edited 2006-06-19 00:44
I’ve not seen anything on LKML to that effect; but on the other hand, it’s easy enough to miss traffic on LKML.
Bugfix releases are 2.6.17.X releases.
.X releases are stable releases. He was refering to a discussion started by Andrew Morton about how buggy the kernel may be getting that prompted Linus to contemplate taking a breather and just doing one full release cycle of nothing but bug fixes.
Which I think sounds like a really nice idea in theory, but I’m not sure how well it would actually work. Would everyone just keep on working on their own projects or could Linus get everyone to focus completely on bugs? If not, the bug fix release wouldn’t be all that impressive and the next release would just have twice as much new stuff as usual, which would no doubt introduce even more bugs.
Edited 2006-06-19 04:13
Well, if something can’t be done to get bugs fixed, in two releases we’ll have twice as much new stuff and even more bugs. So, even if you’re right, at least there’d be some more bug fixing this time, so it might be a net gain.
Perhaps in a “perfect” environment that would be right, but in the real world the smaller each individual change is the less likely a bug is introduced and the more likely the ones that are produced can be easily run down and fixed. Two small changes are much better for stability than 1 change twice as large.
Anyway, I’m just saying that the developers would have to be careful of a bug fix only release. It would probably end up being a good thing, but it has the potential to backfire.
Edited 2006-06-19 04:38
.X releases are stable releases
Ok. I didn’t say they weren’t stable. the X.X.X.X releases are bugfix only. I think it is a pretty stupid idea to take a break and release a X.X.X kernel as only bugfixes. The kernel should stay in constant development. Distributions should take care of releasing a stable kernel. Do you remember what it was like before the 2.6 kernel? Distributions just added in all the newest features anyway. It is a hell of a lot easier to just fix bugs then patch the hell out of the kernel to get new features, then patch again to fix all the bugs that arise. This way development is much faster, and distibutions only have to worry about stabilizing. Some people claim the kernel is buggier now than 2.4 but I don’t agree. I haven’t had more than one issue that was kernel related since 2.6 debuted, and I have used almost every release.
the X.X.X.X releases are bugfix only.
Not exactly. They’re for introducing changes that have a high probability of not introducing new bugs and that are thought to be important enough to not wait for the next kernel cycle.
Take a look at the release emails for the 2.6.16.x series and you’ll see changes that were introduced that were not merely “bugfix”.
I think it is a pretty stupid idea to take a break and release a X.X.X kernel as only bugfixes. The kernel should stay in constant development.
80 percent of development is bug fixing. “Developers” who only emit code and never fix their own bugs never grow as developers.
Some people claim the kernel is buggier now than 2.4 but I don’t agree.
Can’t comment on that, but can say that 2.6 has gotten progressively buggier since 2.6.8, and now would be a good time to take a break and do a little house cleaning.
After all, a 2.6.X cycle is fairly short, so we’re only talking a few weeks to a couple of months, tops for cleanup, and there’s a lot of stuff there could benefit from being cleaner.
Not exactly. They’re for introducing changes that have a high probability of not introducing new bugs and that are thought to be important enough to not wait for the next kernel cycle.
True, the fixes are supposed to be limited to changes that would not affect other things, but as far as I know it is only to fix bugs. If you have an example of adding a feature in a X.X.X.X kernel then I would love to see it.
80 percent of development is bug fixing. “Developers” who only emit code and never fix their own bugs never grow as developers.
I didn’t say they should fix bugs but there should be no reason to hold back on features for X.X.X releases.
Can’t comment on that, but can say that 2.6 has gotten progressively buggier since 2.6.8, and now would be a good time to take a break and do a little house cleaning.
Maybe vanilla kernels but who uses those other than Slackware and LFS? Like I said before vanilla kernels shouldn’t be used anymore. Distributions should take care of stabilization, and as far as I am concerned they have done a pretty good job. At least my distro hasn’t had any serious issues with the kernel.
After all, a 2.6.X cycle is fairly short, so we’re only talking a few weeks to a couple of months, tops for cleanup, and there’s a lot of stuff there could benefit from being cleaner.
It seems that those weeks/months go into fixing bugs in the X.X.X.X releases so I am failing to see a problem here.
I would rather say: 2.4 had less regressions than 2.6
A whole cycle to just fix all the regressions that currently make upgrading to a new kernel a nightmare.
If you have a piece of (not outdated) hardware which did work with 2.6.11 and which does no longer work with any newer kernel, you have a real problem.
Such regressions need to be fixed with the highes priority.
Linus could get himself a list of regressions, and call out a halt to patch merging unless all of the regressions on his list are fixed. That would make a kernel to which anyone can upgrade without having to fear problems.
I thought it was going to be happening with 2.6.16 but I’m not sure if it happened in the end…
Adrian’s plan is to pick up the development of the 2.6.16.y kernel at that point, maintaining it much as the 2.4 kernel tree is is maintained
http://kerneltrap.org/node/6386
Other than some driver updates and additions, there isn’t much here to help average users. Housekeeping, bug fixes and driver additions are always good, though.
It’s a *kernel*. How much average user interaction do you expect from a kernel?
>It’s a *kernel*. How much average user interaction do
>you expect from a kernel?
I wasn’t talking about user interaction WITH the kernel. I was talking about features that benefit users.
Fortunately, I did find some. Read the explanations re: splice() and tee() and you’ll find major performance improvements for operations where, for example, you might want to send the same data to two storage facilities (say, when playing music and also sending the data to disk at the same time). I can see the new features being a major boon to multimedia applications.
Then you missed a lot.
Especially the part about improved V4L. This is very important for people using MythTV like me.
There is a new ivtv driver specially for this kernel that is due in the next hours or days, depending on when the devs realise 2.6.17 is out. There is also, for more advanced users, the NAT and connection tracking for H323 which is a good thing.
There were several bugs in CFQ (for your disk) schedulers and one introduced in 2.6.16 that could make you swap like mad from time to time. They added a new disk scheduler and improved the CPU scheduler.
Everything should be faster now.
And improvement in Wifi with a new version of the main API.
Hey, even for those that use distributions, no more install this kernel for one proc or this one for SMP (Dual Core and the like) : now, the generic kernel can adapt itself to one CPU or to SMP.
And even if not related to performance, more drivers and more recognised hardware is always good.
This is supposed to fix the badly broken i20 drivers 2.6.16 in FC5 and updated FC4 kernels have. Finally…
Woohoo! Can’t wait to try these without driverloader…
Yummy.. I hope they work better than the experimental patches I’ve been trying.
nice, readable writeup of the new stuff
much better then just linking to a raw changes log
hope to see that at future kernel releases to.
Anyone notice the halting process change? Usually the system powers off immediately after the drive powers off… now, running ‘halt’ only powers off the system after the drive was powered off and the drive has spun down.
Listen carefully.
Is this better for the hardware? (Obviously the drive also spins down when the power is off. Differences?)
Lots of cool new things & some big stuff still to come in future
– look at the development kernel section on kernelnewbees .
People complaining that there arent tons of new features – come on – compare to MS or Apple – they would bring out a new upgrade or service pack for all the new features that ship with each new released Linux kernel – hype it as the best ever since chocolate – & potentially make people pay .
😉
Bug fix cycle would be interresting – maybe soon or never
EDIT : yes I think your right with the disk now that you mention it
– for a happier disk .
Edited 2006-06-19 18:27