Linux 2.6.26 Out

diegocgteleline.es writes "After three months, Linux 2.6.26 has been released. It adds support for read-only bind mounts, x86 PAT (Page Attribute Tables), PCI Express ASPM (Active State Power Management), ports of KVM to IA64, S390 and PPC, other KVM improvements including basic paravirtualization support, preliminary support of the future 802.11s wireless mesh standard, much improved webcam support thanks to a driver for UVC devices, a built-in memory tester, a kernel debugger, BDI statistics and parameters exposure in /sys/class/bdi, a new /proc/PID/mountinfo file for more accurate information about mounts, per-process securebits, device white-list for containers users, support for the OLPC, some new drivers and many small improvements. Here is the full list of changes."

Intelfb still broke

They have still not enabled mode switching in the intelfb driver on laptops, meaning that I am forced to use ugly, unaccelerated VESA instead of the right driver for this sytem. This bug has been reported on kernel dev mailing lists and forums for at least three years, but no one with the skills seems to want to fix it.

Clever new tools for kernel config

What I would like to see more emphasis on in future kernels is a discussion of possible clever new tools and methods for configuring the thousands of kernel config options. None of the existing in-kernel-tree or out-of-tree config tools seems ideal.

Re:Clever new tools for kernel config

Aye - would be great if there would be tool that I could eg. say "Ok, right now, at this moment, I have all my hot-pluggable USB/PCI devices plugged in, please detect and configure the options as needed". After all, that's what I do with a new comp: use lspci and similar tools to find out what's in the guts of the machine and then set options appropriately in menuconfig.

Good Featurelist

I wish every kernel release announcement included a highlevel featurelist like that. Not just a ChangeLog, as each bug is fixed or small feature is added. But rather a fairly highlevel list of new and improved (and fixed) features like the one in this Slashdot story. Best if in the announcement itself, but at the very least always in the release package.

That way most of us can decide whether to upgrade, or to wait (perhaps for the x.1 version, which is typically a higher quality bugfixed delivery). Since kernel upgrades require rebooting (and again to downgrade after test), knowing whether to ignore a release based on its highlevel upgraded features itemization is a very effective announcement feature, which makes all of us using the releases more productive.

Kernel debugger considered harmful by Linus

Reading on it, it seems that Linus never has been a great fan of kernel debuggers. From a famous post [lwn.net],

I happen to believe that not having a kernel debugger forces people to think about their problem on a different level than with a debugger. I think that without a debugger, you don't get into that mindset where you know how it behaves, and then you fix it from there. Without a debugger, you tend to think about problems another way. You want to understand things on a different _level_. [...]

I agree that stepping with a debugger instead of thinking real hard about the code (and using abundant log statements) is generally a waste of time, and that expecting to catch rare occurrences of weird race conditions with a debugger is not worth the effort. Sloppy programmers don't take the time to think, and rely too much on fixing what they could have not broken. Unit tests, although more expensive to code, can be reused many times - debugging sessions are one-shot.

On the other hand, even good programmers can get stuck and benefit from a debugger every once and then. I guess this argument finally won the day.

Re:Kernel debugger considered harmful by Linus

These days I'm too lazy to bang around fiddling with OS's, but back in the early 80's when I ported the UCSD p-system to many machines, we didn't usually have *any* kind of debugger except our own log statements. So, one day I got given an Orion Instruments logic analyser (which could do hardware debugging for MC68000). Beautiful. Best productivity disabler I've ever seen. On the other hand, because of a really bad experience on my first p-system port, my own diagnostic code for a later port made me screw up my deadlines badly.

With high level code, a decent debugger is really really useful. With low level code, not so much.

(It's amazing though how many high level programmers don't understand the way debugging changes program behaviour (variable initialization etc - don't even mention heisenbugs)).

The best ever debugger is the "cardboard man". If you really get stuck you explain the code to anyone (including the cleaner). That way, (even though the cleaner doesn't understand anything) you exercise another part of your mind and *see* the problem (... well here we shift left (wtf? right?) oops).

Andy

Re:Kernel debugger?

I found this article on Wikipedia [wikipedia.org] but it doesn't say much except "A kernel debugger is a debugger present in some kernels to ease debugging and kernel development by the kernel developers". Can someone whip out a cluebat please?

Re:Kernel debugger?

A kernel debugger is a program you can run from one computer, generally via a serial patch cable or some such, that lets you step through the kernel code running on another computer. It's like a normal debugger, but remote.

Linux has had kernel debuggers for years, but Linus never wanted it in mainline [linuxmafia.com], so it was always a patch, and sometimes didn't work on the latest kernel. Now, it's part of the kernel (I don't see any links to why Linus changed his mind, but you might be able to find something on LKML if you look).

Anyway, I think this is good news. I understand why Linus never wanted a debugger in the kernel, but I disagree with him on two points. First, even developers who have a good understanding of the code can get work done faster if they use a debugger. Using a debugger does not automatically relegate you to someone who doesn't have a good understanding of things, as Linus would have you believe (i.e. there's a difference between needing a debugger and being more productive with a debugger).

Second, there are a lot of people these days who just fix bugs, or just want to debug their own tiny kernel patch. I.e. people who don't have a full understanding of the system but who need to get something done. It's good that these people are now first-class citizens. They likely will never write a new kernel subsystem, but maybe they'll fix a few bugs and make life better for the rest of us.

Re:init post

Ugh, still no token ring support. And it's distributed under the GPL License. I think I'll recommend all my fortune 500 clients stick with windows server 2003.

Re:init post

Ugh, still no token ring support.

It had token ring support circa 2000 and you can probably resurrect the drivers if you need it.

OTOH if you're still using Token Ring you probably have Madge or Olicom cards whereas the best Linux support was for chipsets like the IBM Olympic.

Re:Ah but does it run Linux?!?

These changes will now make 2008, THE year for the linux desktop!

Re:Real writeable NTFS?

http://www.ntfs-3g.org/

Not sure why it isn't in the kernel. But works great for me.

Re:Real writeable NTFS?

Old NTFS stuff used to be really, really slow. Is ntfs-3g as fast as other filesystems on Linux, now?

Re:Real writeable NTFS?

Not sure why it isn't in the kernel.

Because it doesn't need to be. Really, that's all there is to it. The old one took a long time to develop because kernel code is harder. The only real reason why you'd want an in-kernel driver is if you wanted to boot off of NTFS. The in-kernel driver is good enough to let you do that via a loopback file on the NTFS volume, so the rest can be in userspace.

Apple uses that, too, and I don't hear people complaining about Apple's support for NTFS. People who still complain about this are living in the past, or are hitting one of the few remaining strange corner cases that aren't yet supported (and I very much doubt you are).

Re:Real writeable NTFS?

Here: http://www.ntfs-3g.org/ [ntfs-3g.org]

Why is it needed in the kernel?

Re:Real writeable NTFS?

You know, this joke has been beaten to death for the past month or so. Can't you lay it to rest?

Good point, but...

...if your friend/colleague/whatever wants to use an NTFS-formatted drive on your computer, he might be a little unhappy if you reformat it.

I put NTFS support on my Linux computers and Ext2/Ext3 support [fs-driver.org] (and a proper formatting tool) on my Windows computers. It's called interoperability.

Re:Good point, but...

...if your friend/colleague/whatever wants to use an NTFS-formatted drive on your computer, he might be a little unhappy if you reformat it.

I put NTFS support on my Linux computers and Ext2/Ext3 support [fs-driver.org] (and a proper formatting tool) on my Windows computers. It's called interoperability.

Nice one

Can't figure out if I should moderate as insightful, funny or +1 quality bitchsmack

Re:Translation please?

Click the link in the story: http://kernelnewbies.org/Linux_2_6_26 [kernelnewbies.org]

and it explains it all there

Re:Is Linux kernel 2.6.26 == Linux 2.6.26 ?

Technically, "Linux" is the kernel, and there is no "Linux" OS. Of course, the various distros are generally referred to as "Linux" distros, which really doesn't help matters any. I believe your FreeBSD/NetBSD/etc are vaguely equivalent to Debian/Fedora/etc.

Re:Is Linux kernel 2.6.26 == Linux 2.6.26 ?

I believe your FreeBSD/NetBSD/etc are vaguely equivalent to Debian/Fedora/etc.

I'm not sure where exactly you're going with that

What he(?) means is that just as {Free,Net,Open}BSD are complete operating systems, so are Linux distros like Debian, Fedora, etc.

Re:Is Linux kernel 2.6.26 == Linux 2.6.26 ?

Is Linux kernel 2.6.26 == Linux 2.6.26 ?

Yes. When people refer to entire distributions as "linux" they are being technically incorrect, as the GNU folks are kind to point out at the drop of a hat. The entire operating system is GNU/Linux - Linux is just the kernel.

Re:Does it disturb anyone else?

Nah, SATA gets rid of all that. No more master and slave. Now, we submit to the controller.

Re:Does it disturb anyone else?

It adds support for read-only bind mounts, x86 PAT (Page Attribute Tables), PCI Express ASPM (Active State Power Management), ports of KVM to IA64, S390 and PPC, other KVM improvements including basic paravirtualization support, preliminar support of the future 802.11s wireless mesh standard, much improved webcam support thanks to a driver for UVC devices, a built-in memory tester, a kernel debugger, BDI statistics and parameters exposure in /sys/class/bdi,

Does it disturb anyone else how many words the bsdm & linux kernel community have in common? (this is not a troll).

Frankly, I blame IBM.

Well, the kernel sources are (or were) pretty explicit in their sexual deviations. I remember several occurrences of the following comment: /* Fuck me gently with a chainsaw... */ in the 2.4 tree.

Re:802.11s can run on generic WLAN hardware?

802.11s != OLSRv2 . 802.11s seems to work at the MAC layer, whereas OLSRv2 works at the IP layer. They are not the same. There are quite a few mesh networking protocols out there and in development, but I haven't seen a clear winner yet.