Slashdot Mirror
Jens Axboe On Kernel Development
BlockHead writes "Kerneltrap.org is running an interview with Jens Axboe, 15 year Linux veteran and the maintainer of the linux kernel block layer, 'the piece of software that sits between the block device drivers (managing your hard drives, cdroms, etc) and the file systems.' The interview examines what's involved in maintaining this complex portion of the Linux kernel, and offers an accessible explanation of how IO schedulers work. Jens details his own CFQ, or Complete Fair Queue scheduler which is the default Linux IO scheduler. Finally, the article examines the current state of Linux kernel development, how it's changed over the years, and what's in store for the future."
I wonder, if the originating process' priority is taken into account at all... It has always annoyed me, that the "nice" (and especially the idle-only) processes are still treated equally, when it comes to I/O...
In Soviet Washington the swamp drains you.
Well, on the other side distros were backporting *huge* amounts of patches from 2.5 to 2.4, so while plain vanilla 2.4 was stable, almost noone was running it. The 2.6 releases means the distros are shipping "stabilized unstables" instead of "destabilized stables", I guess that works out better for some and worse for some. Are RHEL, SLES, Debian stable kernels not good enough kernels to start out with, if stability is what you need? I feel there's quite a few things I see come which I find great that arrive in a timely fashion, not at the release of 2.8 in a few years. I think most that use a distro's kernel feel that way.
If you're the kind of kernel hacker who liked to get yours directly from kernel.org, yes then it sucks. But IMO the kernel has grown too big for just the core devs, think of it as an "extended" kernel team including the distros, where kernel.org releases are "internal betas". I think if you cut it back and expect just kernel.org to deliver stable kernels with the resources they have (which admittingly, they used to) then kernel development will slow way down.
Live today, because you never know what tomorrow brings
Don't take this the wrong way, but your complaint sounds a lot like the story about a patient and a doctor:
"Doctor, when I do this, it hurts", and the doctor replies, "Well don't do that".
I mean, if you are following bleeding edge kernels, and complaining that they aren't as stable as you'd like. Why not just follow a vendors kernel? If you use or install "many thousands", you are either maintaining your own de-facto distribution or you are using someone else's distribution. Vendor's do exactly the work you want done on your behalf.
I patiently wait for my vendor kernel, which might be 10 point releases behind integrate bug fixes and then upgrade in a year or two to a much newer point release (I think RedHat has used 2.6.9 and/or 2.9.13 in recent memory)... Incrementing a different number wouldn't really make any difference anyways. At that point it's all semantics, if you know the rules of the game, it's not hard to tell what's dangerous as an upgrade and what's not.
It's not like 2.4.13 (or whatever one in the 2.4 series that introduced series disk corruption) was safe merely because it was a point release... They are safe because somebody took it out back and beat on the kernel for a while and it didn't cause any problems. If you upgrade without proper testing and it breaks, you get to keep the pieces.
Kirby
The kernel development model is optimized to make distros happy, not end users. Just like Gnome/KDE, BTW. This is because, well, in the Real World most of desktop/servers use (or should use) the kernel shipped by their distro. And because distros are who emply most of kernel hackers.
In other words, the previous development model made happy say 1% of people (you) and 99% unhappy (distros and hence people using distros). The current model makes 99% of people happy (distros) and 1% unhappy.
IMO it's was a good change. And if you don't like it, just use Opensolaris. There's nothing wrong with it.