Kernel Traffic #290 For 3 Jan 2005

I have no problem with dual-licensed code, but I do strongly dislike having this "unlike you explicitley state otherwise, you transfer all rights to Hans Reiser" in the kernel.

Besides the fact that giving the copyright completely away is nothing that is legally possible in at least Germany, I'm not happy with having to check every single file in the source tree for additional licence clauses before editing it - and then to consider whether my contribution might deserve a copyright label according to my local law.

I don't see any reasonable alternatives. The alternative is for Hans Reiser to not be able to merge with the kernel, which is kind of against the _point_ of having a dual license.

If the wording grates or assignment is an issue (and yes, in the US you technically really need to have an express _signed_ assignment, implied assignments just don't work), asking people to make their changes PD instead might work (they'd obviously immediately be subsumed under the GPL as far as the kernel is concerned, but would allow the dual-licensing to continue to work).

That said, I don't think at least _this_ particular area has been problematic, because quite frankly, very few people end up working on other peoples filesystems, so as far as I can tell, almost all reiserfs fixes have really been mainlt due to interface changes, nothing else. So assignment of copyright etc doesn't really ever become an issue, if only because copyrights require a bit of actual artistic value ;)

If you touch e.g. XFS for a non-trivial change you'll also get a mail from SGI politely asking to assign your copyright. Doing this implicit is IMHO a reall bad thing.

IF you really think it's something we should do the least thing to do is to put a BIG WAIVER into every file for which this is in effect.

Please understand it as the emphasis is on don't obscure and distort my definition in my labeling of the code of what I have copyrights to. I believe that for that reason, a court would allow it. I could be wrong. That is why I ask everyone I detect for a copyright assignment, still to this day. I don't 100% trust the code acceptance process to guarantee that I will catch everyone....

In a world with SCOs, we need to be over careful not under careful about such things.

http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc2/2.6.10-rc2-mm4/

• Various fixes and cleanups
• A decent-sized x86_64 update.
• x86_64 supports a fourth VM zone: ZONE_DMA32. This may affect memory reclaim, but shouldn't.

Modern ThinkPads have accelerometers in their hard drives that detect sudden movement and spin down the drive or otherwise protect it.

The device is pretty basic, though, and you can just read it directly to watch the movement of your laptop. E.g., pick your laptop up and a little icon in your GNOME panel can show an up arrow. Pretty neat.

I am sure Google has more information.

This needs to be added to the input layer!

Till Harbaum wired up an accelerometer inside his Palm Pilot, then wrote a marble rolling game that you could play by tilting the palm to move the marble. http://www.harbaum.org/till/palm/adxl202/index.html

I'm pleased to announce the release of Squashfs 2.1. This release introduces indexed directories which considerably speed up directory lookup (ls, find, etc.) for directories which are greater than 8K in size. All directories are now also sorted alphabetically which further speeds up directory lookup.

Many smaller improvements have also been made in this release, and there are, for the first time, the results of some tests of Squashfs lookup and I/O performance against Zisofs, Cloop, and CRAMFS.

For further details please go to the project page http://squashfs.sourceforge.net.

Good question... When I originally released Squashfs (Oct 2002) the 2.5 kernel had just gone into the feature freeze and I was waiting for the unfreeze that would happen when 2.7 arrived. As the official stance on additions to 2.6 has been relaxed I have thought about submitting it.

I need to tidy up the code a bit before I submit it to the merciless scrutiny of LKML :-) Nothing bad (I hope) but there's lots of long lines and I do know LKML'mers like 80 columns.

I'm planning on adding ea/acl support (people have been asking for them), I can't decide whether to submit it now or wait until I've finished them. Suggestions and advice would be welcome.

Slightly off topic, I've noticed you're the kernel maintainer for Gentoo. You mentioned somewhere you're down to 4 kernel patches, including Squashfs? :) A lot of people/projects are now using Squashfs and it would help a lot of people (and me) if it did get into the kernel. Plus it would be a nice thing for me anyway to have finally got it included.

Yes, squashfs is one of the four non-bugfix patches in the Gentoo kernel 2.6 kernel package.

For those who are interested, the other three are:

• fbsplash, the "next-gen" version of bootsplash. No more image decoders in kernelspace (compared to bootsplash), and a few more features.
• speakup, a driver package for visually-impaired users.
• vesafb-tng, a "next-gen" version of vesafb-tng.
• inotify.

Ok, there are now 5 patches, I forgot we addeed inotify recently to make the Gnome developers happy.

Arjan van de Ven is now building RPMS of the kernel and those can be found in the RPM subdirectory and should be yum-able. Expect the RPMS to lag the diff a little as the RPM builds and tests do take time.

The HPT366 rework project is also not ready (its gone back to the drawing board until the current panic is over if you are a volunteer and wondered what is up).

ftp://ftp.kernel.org/pub/linux/kernel/people/alan/linux-2.6/2.6.9/