Short bio: Computer Scientist, FOSS supporter (read more)
Tux Machines (TM)-specific
I was reading another article on kernel trap the other day and I sat down and started thinking about how things have changed over the course of the 2.6.x series of kernel and thought I would review all of these changes and put them all in one place.
(I apologize for inaccuracies/down rite mistakes but I just want to say what I think)
I remember first using the 2.6 series of kernel and thinking oh god the drivers are between being ported as I had a device which wasn't in 2.6.3 I think it was (not overly important).
A few releases passed and the kernel seemed to stabalize and soon the kernel settled into the system that is governing releases now 2.6.x.y which allows for more important bugs to be fixed in vanilla quickly, with the most active development taking place in the -mm patchset.
I remember a few of the underlying kernel versions to date have caused binary only modules to break, off the top of my head 2.6.11, 2.6.16, and 2.6.21 have all required a patch to be applied in order for (at least) the fglrx driver to work.
The 2.6 series does however allow for things to be changed and upgraded without the need to break off into a 2.7 branch which I think meets everybodys needs.
However there are a few things that have come to light recently which have caused the kernel development community to appear quite hostile (not saying managing so many people never is).
The end of the ck patchset was (to me) the worst case scenario as to what can happen when developers fall out. People leave and their absence is a loss.
Another striking point is the inclusion of reiser4 in the vanilla kernel, I am sure that people at the top are fed up of requests on why they don't merge this code but to me the answer is obvious, people want it in, just put it there and delegate management of the code to someone else to shut everyone up.
I know there are probably very good technical reasons why this shouldn't be done, but aside from inclusion of reiser4 into the kernel there is no way that large distributions i.e. suse, redhat are likely to offer reiser4 options at install. When it's in vanilla as experimental/unstable it would probably get a lot more attention that it's probably losing now due to the controversy of it.
How could I not mention SCO wanting all documents related to the 2.7.x kernel series as part of their court case, it always makes me laugh as how this has seemed to fizzle out, it may develop in the future but has had no impact on the linux front, (infact I know someone who heard of the case as the story overspilled and started asking me more questions about the penguin).
The kernel seems to allow for various patches/patchsets regardless of their intent to be developed alongside with a good few springing to mind from a few places at the moment, most of them always good (the only one I hate is apparmour but I don't know why I dislike the idea so much)
There is also a realtime patchset for the linux kernel now which aims to focus all of the realtime efforts to adapt linux into a more solid framework from what I can understand.
The linux kernel now also has a new wireless core (again) and is offering even better support (again). I'm not mocking the efforts, far from it, only that the support is slowly evolving, once it is there I think it shouldn't be too bad in getting 802.11n devices working natively. Would be a nice pro-bo that linux will probably be the only OS out of the box to have support for a lot of devices like that. bring on a stable bcm43xx!!
People complain about drivers being missing from linux, but compare linux to an out the box windows install and linux beets it every time from what I have seen, it's again just a lack of user base that has hindered development.
Plus x86_64 support is now near as good as x86 to me, all I am waiting for is the tickless patch promised in 2.6.23
Only complete stick in the mud for me is the suspend to ram/disk or tux on ice code. I have never had it work on 3 machines following all sorts of tutorials, I've tried vanilla and distro kernels as well.
I hasn't been such a major thing as of late due to acpi only being included for my laptop in kernel 2.6.21, however it's always seemed like a broken feature KDE rubs in my face
All in all more of the same please from everyone who submits code