Slashdot Mirror
Linux 2.6.22 Kernel Released
An anonymous reader writes "Linux creator Linus Torvalds announced the official release of the 2.6.22 kernel: 'It's out there now (or at least in the process of mirroring out — if you don't see everything, give it a bit of time).' The previous stable kernel, 2.6.21, was released a little over two months ago. New features in the 2.6.22 kernel include a SLUB allocator which replaces the slab allocator, a new wireless stack, a new Firewire stack, and support for the Blackfin architecture. Source-level changes can be tracked via the gitweb interface to Linus' kernel tree."
The fact that you were modded up informative really shows that somebody is out here doing a a REAL FUD jobber. Few here, would say that if the kernel did switch to GPL3, that it would not even have a mention in the posting. That means that the modders are deliberate, not just ignorant. Considering that they are modding, shows that most of the time, they do not step off the deep end. That pretty much means that several ppl (30% informative), are most likely on a payroll.
I prefer the "u" in honour as it seems to be missing these days.
I don't understand 70% of the changes listed and don't care about/don't use the rest of them. I know, I know... I must be new here. *sigh*
Cornholio is a prophet.
Whatever happened to the releases being STABLE??
Am I the only one who cringes when someone says they have released a totally new wireless stack in a point release? Does everyone forget the VM switch fiasco already?
I really really regret the switchover to this whole new "accelerated" kernel dev. phase. Since this is just a point release, but has a totally new wireless stack, how do I know that my next OS update won't just break my whole networking setup? Argh.
Specific complaints should be stated as such instead of rubbish about it all being broken. The Gentoo thread quoted above is about people discovering that writing to optical drives is horribly slow and puts a lot of load on the CPU in comparison to dealing with hard disks - looking up ATAPI may have been a good move at that point instead of a lot of speculation.
IMO, goto has been demonized a bit too much.
Yeah, too much of it results in spaghetti code.
But used well, it can compensate for the lack of some things in C. For example, exiting nested loops. In Perl you can say "last NAME", where NAME is the name you gave to the loop, and exit from the outer loop directly.
In C, if you avoid goto what results is a check in every loop to determine whether the inner loop decided that we've got to bail out. This is much uglier than just using goto in the first place, and more error prone too.
Using goto is also handy for error handling: When you're allocating memory, goto allows jumping to the right point in the cleanup process, instead of duplicating bits of code everywhere.
It's my understanding that in kernel programming goto also has advantages in terms of speed over other alternatives.
That's not to say we should use everywhere. But IMO, what to use should be decided on the basis of what is the cleanest and less error prone option -- If goto results in cleaner code, then use it, if it doesn't then don't.
If you hate the Slashdot moderation system so much, why post comments here?
Mod parent down please
Remember that the kernel is C, not C++. The goto here is safe. The deal with GOTO was that it was not supposed to be used to jump from one function to another or to replace functions. (C will not allow you to do this.) That was the point of the "go to considered harmful" paper - That explicit jumps would cause people to avoid writing properly structured code. Inside a function a go-to is entirely legal and sometimes allows you to save clocks by skipping things you don't need. In kernel code, saving clocks is entirely worth it, since your function may possibly be re-entered at a high rate, and your code blocks all other code in the system (you're the kernel). In an application, it's less worth it and the goto is probably unnecessary.
Personally I use whatever the language gives me wherever I can to make things as computationally short as possible. Sacrificing performance for programmer comfort does not make sense. If the code looks ugly, but it works (and works fast!), that's all it needs to do. For every one programmer you have thousands of users, and the users don't care if the source is pretty or not.
This is getting increasingly Digg-like...
http://www.dieblinkenlights.com