I have just been untarring lots of files lately and its so nice for it to just work instead of rebooting.

Thanks for fixing it, are there any new speed test being done, was there any difference?

Well, I was attempting to install your KDE package, and I got my N800 to lock up/reboot during the large un-tarring procedure. The "XFCE-6-INSTALL.tar.bz2" file was on the same card (8GB Transcend) as the loop-mounted 512MB ext2 file, so that's obviously a very stressful situation. However, it's disappointing to see a lockup - that just shouldn't happen. At least normal operation with this card seems fine so far. My previous 8GB Transcend died within a couple of hours with the old kernel writing Maemo Mapper files to it.

I wonder if it didn't completely lock up, but just prevented the watchdog process from running long enough to reboot. I'll try to take a look at the relative process priorities.

Full disclosure: I'm running a self-compiled kernel with the high-speed SD patches, and my kernel optimization set to '-O2' instead of the normal '-Os' (optimize for size). The base kernel source is the latest (-osso55) release, with the high-speed patches applied. 'dmesg' debug output shows that my 8GB card is running at the high-speed rate of 48MHz. So maybe it's the unofficial high-speed mode or the kernel optimization that was the problem.

I am running stock kernel, and not a bump, I'll give up speed for reliability any day.

what are the speed differences, in your kernel compared to stock? do you have some hdparm numbers or other dd time or anything?

Also do not bother installing KDE, pm me and I will give you a link to my latest tarball.

Its real nice!!

No before/after transfer speeds, unfortunately. With this test:

time dd if=/dev/mmcblk? of=/dev/null bs=8192 count=30000

I get right at 12MB/sec on both the internal slot (8GB Class 6 Transcend) and external slot (2GB Kingston 120X "ultimate" SD). At some point I plan on trying some different kernels, enabling/disabling the various SD modes.

Using "-O2" (disabling the "optimize for size" kernel config option) seems to make the entire device snappier. Might just be my imagination - I don't have a lot of time on my N800 so could just be wishful thinking. I'm still running from internal flash (haven't cloned my rootfs to SD yet), and don't yet have a swap file, so any snappiness shouldn't be due to the higher SD R/W speeds of the patched kernel.

Actually, I haven't upgraded yet (that's two versions I'm now behind) and, given that we can expect a major upgrade in a few weeks, I'm probably not going to bother.

Then again, ITOS2008 will -- contrary to Nokia's explicit promises!!!!!!!! -- again break software compatibility with existing software, so I might forego upgrading to 2008 until every -- unpaid!!!! -- developer has once again recompiled his software.

You know, I'd complain about it, had I not expected this to happen. There are some serious *ssholes inside Nokia who apparently have no truck with f*cking with the community as they see fit.

I'm getting myself an Eee. At least that one's just hardware, without corporate dilberts to fornicate me over...

Karel, I think you misunderstood. There was no promise that Chinook would not break compatibility, at least that I ever saw. In fact all the official info I've seen was that Chinook would be a major break DUE TO THE INCREASING EMBRACE OF OPEN SOURCE AND CURRENT GTK THAT USERS HAVE BEEN SCREAMING FOR.

The promise was that the previous device (N800) would not be officially abandoned as the 770 was.

^ Second to that... At least current Becomeroot and SSH install on Chinook as is. (Becomeroot actually works, SSH I have not tried.)

I do not think there is need for major differences in code. It might just be that recompiling is needed, and that's it.

Actually, at LinuxTag 2007 in June, Quim Gil promised on slide 28 of his presentation that Chinook would bring an API break to sync up with GTK+. According to that same slide, Nokia intends to maintain backwards compatibility from "Diablo onwards". However, the slide does say that if the technologies Nokia builds Maemo upon (such as GTK+) break compatibility, then Nokia will follow along and do so as well.

In the end, API breaks are far more common in Linux, and the software built upon it, than in, say, Windows. This means Linux doesn't carry the baggage Windows does, but it does also force folks to keep applications up to date.

Actually, the API breaks are far more common in GTK than just Linux in general.