Messages

1

Hardware Mods / Tried To Make 40gb Z With Ipod Hdd

« on: July 17, 2007, 12:32:42 pm »

The CF interface is a lot more than just a pinout. The CF specs actually define three different types of devices that can connect: memory, I/O, and ATA. The Zaurus PCMCIA interface only supports the first two. Despite the fact that it contains a miniature hard disk, the CF microdrive in the 3XXX series Zaurii is accessed as a memory card. It can only be replaced by devices that support the CF memory card interface protocol. iPod hard drives only work only as ATA devices and thus won't work with the Zaurus. Even the 4GB drives in the iPod minis that were "real" CF microdrives had their memory card protocol support disabled so they could not be used in cameras and PDAs.

2

New products and alternatives / New Zaurus Successor?

« on: June 23, 2007, 09:48:30 am »

How are you guys using your Kohjinsha?
[div align=\"right\"][{POST_SNAPBACK}][/a][/div]

My real Zaurus replacement is my [a href=\"http://europe.nokia.com/A4142101]Nokia E61[/url]. I've found there is a lot of value in having a pocketable device with a full keyboard and good app support (i.e. a decent OS). The Z sort of filled that role, but the lack of built in voice and data connectivity (WiFi needs a fragile card sticking out the side and I still had to carry a phone for voice) eventually got too annoying for me.

My Kohjinsha picks up nicely where the E61 starts hitting its limits. Web browsing, music/movies, software development, and working with documents. Some of these (music/movies) I used to do on the Z, but for the others I had to either carry a big bag of Z accessories (portable keyboard and such) or a full laptop.

So the Kohjinsha has allowed me to go from phone+Zaurus+laptop to smartphone+Kohjinsha. So far I'm pretty happy with how this new arrangement is working out

3

New products and alternatives / New Zaurus Successor?

« on: June 22, 2007, 07:43:41 am »

He said he will refund my money if I return it to him at my expense.
It would cost over half what I paid for it to send it back to China.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=163533\"][{POST_SNAPBACK}][/a][/div]

That's really unfortunate. Who would have thought there are actually multiple OEMs making keyboards in this form factor?!

But I have to say that I am curious about the "feel" and accuracy of this different model. Have you tried it out using the USB port? How does it compare to the SA1's keyboard? It looks like it's about the same size so an entire keyboard transplant may be theoretically possible.

4

New products and alternatives / New Zaurus Successor?

« on: June 18, 2007, 05:54:15 pm »

Well, the keyboard arrived today for my Kohjinsha.
The only problem is, the seller sent a substitute make/model, and the keys are made differently.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=163352\"][{POST_SNAPBACK}][/a][/div]

Ouch! I hope that wasn't the same seller I recommended in my article. If it was, let me know so I can add a warning.

5

Zaurus - pdaXrom / Command Line Programming Editor?

« on: June 16, 2007, 12:09:24 pm »

Of course none of these suggestions are command-line editors. If you want one of those then of course THE choice is ED (click for more info) -- the one true editor

Note for the humor impaired: No, I'm definitely not being serious

6

New products and alternatives / New Zaurus Successor?

« on: June 11, 2007, 05:24:31 pm »

KeyTweak is is a "user interface" for modifying the "Keyboard Layout\Scancode Map" registry key. I had some problems with it mapping some of the "extended" keys, but once I understood what it's doing (and knew the scancodes for the various keys), it was pretty easy to modify the registry by hand to accomplish what I wanted.

KeyTweak lets you substitute one scancode for another but it won't let you change how a scancode is interpreted. For that you need Microsoft Keyboard Layout Creator (MKLC). Yeah, the .NET requirement is annoying ... that's why I keep a "throw-away" Win2K VMWare virtual machine on one of my Linux boxes. Take a snapshot, install a bunch of bloated stuff, use it, when I don't need it any more I roll back to the snapshot

7

New products and alternatives / New Zaurus Successor?

« on: June 10, 2007, 10:44:50 pm »

The keys are all perfect, except for the following:

The Alt and Windows keys are still working in their original position, as opposed to their being shown reversed in your final result photo.

Oops ... should have mentioned that in the article. They were not meant to be moved from their original positions. I accidentally swapped them when reassembling and didn't realize it until after I had taken the photos

Also, it appears the new F9 and F10 keys are cosmetic only, as they retained their original key mapping.

Yeah, I may map F9 and F10 (or maybe something else) to them eventually, so I stuck them on the KB "for future use".

8

New products and alternatives / New Zaurus Successor?

« on: June 10, 2007, 02:07:34 pm »

after reading up a bit on teh keycap problem i noticed that some people say that even after the mod the keys are not perfect
[div align=\"right\"][a href=\"index.php?act=findpost&pid=162952\"][{POST_SNAPBACK}][/a][/div]

True, but the improvement is pretty dramatic. As one of my mentors used to say: "anyone can strive for perfection, but only the best engineers know how to stop at good enough."

Your idea sounds like it will work, but it's going to be a lot of extra work for that last fraction of a percent. Given that the hairbrush mod is totally reversable (as long as you don't glue the bristles in), you may want to try it first on a few keys and see what you think.

9

Off Topic forum / Which Distro To Try

« on: June 07, 2007, 04:11:27 pm »

Which release of Arch is the recent "stable" release? 2007.50 or 0.8?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=162805\"][{POST_SNAPBACK}][/a][/div]

"Duke" (2007.05) is the latest "stable" release. It's worth noting that Arch uses a "rolling" release approach, so the "stable" releases are just snapshots of the stable base repository a convenient points in time. The first thing to do after an install is a package update to pick up any changes since the release was built.

With Arch new packages (or new versions of existing packages) are first released into a "testing" repository and then rolled into stable "ad hoc" when testing feedback indicates there are no major problems. This is a lot different than the "entire testing repository replaces stable at some fixed date" approach that Debian uses. As a result, "stable" gets updates that are more than just bug fixes on a very regular basis.

10

Off Topic forum / Which Distro To Try

« on: June 07, 2007, 09:57:41 am »

Have you considered Arch Linux? It's sort of philosophically aligned with Gentoo and Slackware in that it starts as minimalist install and leaves it up to you to add only what you want (and assumes that you know what you're doing).

Unlike Gentoo, it's a binary distro (i686 optimized ... don't bother if you have antique hardware). The package manager (Pacman) is quite good and it's very easy to create your own packages (much easier than Debian). The pre-packaged stuff is pretty current (gcc 4.2.0, kernel 2.6.21, xorg 7.0, gnome 2.18, kde 3.5.7, xfce 4.4, etc.) and there is an active community maintaining even more bleeding edge versions.

I'm still partial to Ubuntu for boxes that I want to just work. But if you want to tinker, Arch is a great choice.

11

Deals and Great Z Buys / 16gb Cf For $159.99 After Rebate

« on: June 06, 2007, 09:36:42 am »

If  you'll have a new 16GB card, you'd create one extra primary partition? Then not mkfs it? Is that all?

That's it.

How big should this partition be for a card this size, to provide the additional level of security you speak about and yet not be unnecessarily big?

That's where things get a lot more "speculative". It's going to depend on a number of things you may not know (expected usage patterns) and some things you definitely don't know (reserved sector pool size, wear-leveling algorithm specifics). But, a quick "back of the envelope" type calculation can probably get us in the ballpark ...

In my previous "pathological" zero byte file example, we saw that the number of cycles a sector can withstand times the number of reserved sectors gave a kind of worst case life expectancy. So let's guess at some parameters. First we need to pick a mean-time-to-failure (MTTF) -- I'm going to say 10000 hours is sufficient. That's enough for 3.5 years of using the card 8 hours a day, every day. Now let's guess that on average we get 10 sector writes per second over that period. That's a complete guess but it "feels" pretty reasonable. Last but not least, let's guess that a sector can survive 100K write cycles (that's a decent number for today's flash technology).  Note that card size doesn't really factor into the equation.

(10000 hrs * 36000 cycles/hr) / 100000 cycles/sector = 3600 sectors

A sector is normally 512 bytes so that equates to about 1.75 MB. I bet that's not as bad as you thought it would be  Now there are lots of places where my assumptions could be way off, so on a small CF card I'd multiply by a factor of 10 and round up (20 MB) and on a big card I'd multiply by 100 (175 MB).

There are still no guarantees. Sectors can fail after far less than 100K cycles, implemented wear-leveling may not work exactly like the ideal case I describe, etc. But the bottom line is that the "cost" of setting aside a few MB is pretty low, definitely can do no harm, and might help dramatically.

12

Deals and Great Z Buys / 16gb Cf For $159.99 After Rebate

« on: June 05, 2007, 08:00:27 pm »

this seemed to make sense, but I think that the logic breaks down. Lets say you have a digital camera fitted with huge 16GB CF card, and only ever write 4GB to it before "emptying". It will only take four lots before you'll have marked every sector as used?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=162646\"][{POST_SNAPBACK}][/a][/div]

The confusing part is the subtle distinction between "used" from a CF perspective and "used" from a filesystem perspective. In this example, you write your 4GB (let's say it's just one file for the sake of simplicity) to a brand new card. That marks roughly 8M logical sectors as "used" in both the filesystem and the CF logic. Now you delete the file. Those sectors are still "used" as far as the CF card is concerned (it won't use them for wear-leveling) but they're "free" as far as the filesystem is concerned.

Now when you write another 4GB file, the filesystem has to pick another 8M of logical sectors to write to. It *may* pick the same ones it used before (it sees them as "free"). In that case what really happens is that a new batch of physical sectors get written and the old ones get erased, but there is no net change in the number of logical sectors that are marked "used". In a controlled example like this that's very likely to happen. In reality where there are somewhat random file operations, the filesystem probably picks some previously used sectors and some never used sectors (they all look "free" to the filesystem). The result now is a net drop in "unused" logical sectors.

Repeat the process and the next time around the filesystem may pick a different batch of 8M logical sectors. Eventually it is possible that all the logical sectors will have been marked "used" in the CF. And though they may be available for the filesystem to reuse, they're no longer available for wear leveling.

Another example may make this easier to understand. Let's say you fill up a 16 GB card. Every logical sector is marked used in the CF and the filesystem. Now you delete all the files. The filesystem sees the card as empty but the CF logic says they're all "used". Now you create a zero byte file. All that does is write some stuff to the sector where the root directory is stored. Let's say that's logical sector 42  The CF card could just erase the physical sector that is mapped to logical sector 42 and then write the new data, but if you do that a million times the physical sector could wear out.

So it grabs an unused physical sector. Now, since every logical sector is marked as used and mapped to a physical sector, the only unused physical sectors available are in the reserve pool. So it grabs a reserved sector, writes it, updates logical sector 42 to map to it, then erases the physical sector that was mapped to logical 42, and puts that erased sector in its reserved pool (all in a matter of microseconds!). Assuming that the reserved pool has 10 sectors and that sectors can handle a million writes, now we can do our zero byte file create 10 million times before we get into trouble.

Now, that example is pretty far from what someone would really do, but it illustrates the problem. On a CF card that has a small pool of unused sectors, writing the same logical sectors over and over (as happens with a swap file and a swap partition) will greatly accelerate wear on those sectors due to the reduced size of the wear-leveling pool. Keeping a large chunk of logical sectors forever unused (through partitioning) can dramatically increase the size of the wear-leveling pool and protect against the abuse of things like swapfiles.

13

General Discussion / How I Think Linux Will Succeed

« on: June 05, 2007, 07:00:52 pm »

So who wins? Or to put it in a trickier way, who is winning and who is losing?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=162636\"][{POST_SNAPBACK}][/a][/div]

The users win  I use OS X, Linux, and Windows on a variety of different machines (and different types of machines) on a daily basis. All have their own individual strengths and weaknesses. If one tool is not right for the job, I can pick another. Choice is good for me, and the competition to be the "best" choice breeds better products.

If Microsoft imploded tomorrow and Linux instantly took over the desktop market (let's assume Apple refused to license OS X for Wintel boxes) then the first thing that would happen is that Linux would splinter into a hundred different incompatible forks. Uniting against a common "enemy" has done wonders to force the Linux community to work together. Take that away and the fragmentation and in-fighting would be a spectacle like nothing we've ever seen. It's a shame that all the zealots miss out on the wonderful irony of this weird symbiotic relationship between Microsoft and Linux.

The reality is that no one is going to topple Microsoft from their dominant position in the PC world. The only thing Microsoft has to worry about is the thing that took down IBM -- a computing paradigm shift that made their dominance largely irrelevant. And oddly enough Linux needs to fear that too. The PC revolution didn't help DEC or Ahmdal or Data General (IBM's competitors). It helped a tiny little company no one had ever heard of that was smart/lucky enough to ride the wave of a new technology. Enjoy this show while it lasts, because in 50 years there will be a new "winner" and it's unlikely to be one of the current contestants.

14

Deals and Great Z Buys / 16gb Cf For $159.99 After Rebate

« on: June 05, 2007, 11:57:19 am »

Off topic a bit ...
In my case I seldom had data corruption in the swapfile when I was doing quite a bit native compilation under pdaXrom. Swap partition is to prevent file corruption and wearing from spreading all over the card.

Partitioning may help, but the reason why is a bit more complicated. The real key to long CF life is don't ever get all the sectors on the card "used". Wear leveling needs unused sectors to work. With wear leveling, when you write to logical sector X, the card actually picks a physical sector marked as "unused", marks it "used" and writes your data there. Next time you write to logical sector X, the card picks a different physical sector, writes your new data there, then erases the previous one and marks it "unused". As a result, writes (actually its the erase before the write that wears out flash) are spread over the whole physical flash keeping any one sector from being erased and written over and over.

CF cards start with all logical sectors "unused". The first time you write to logical sector X it becomes "used". Even if you later delete the file that was using it, it is still "used" (there will forever more be a physical sector mapped to it). The CF card doesn't know anything about your filesystem. Everything is a logical sector -- and a previously written logical sector that is back on the filesystem's free list is still "in use" as far as the CF card is concerned.

Using partitions doesn't stop your writes from being spread over the physical card (nor would you want it to), but it does stop them from being spread over all the logical sectors. Without the partitioning, when the OS needs to allocate another sector, it just pulls one off the free list. That may be one that was previously "used" or it may be an "unused" one. If it's an "unused" one, you just reduced your wear leveling pool by one. Over time, unconstrained writes will cause the number of never written sectors to asymptotically approach 0. Partitioning keeps them constrained. Once every logical sector in the main partition has been written once, every subsequent allocation from the free list is forced to grab one of these previously used logical sectors and leave the logical sectors outside the partition untouched.

Good CF cards come with a decent percentage of "spare" sectors that are invisible and are always available to the card for wear leveling. Think of it as a "hidden" partition. But if you want to prolong the life of your card even more (or if you have doubts about how much protection the manufacturer has included), create a "reserved" partition with the number of sectors that you want to forever keep available for wear leveling. Do not create a filesystem in this "reserved" partition. Use the rest of the space however you see fit. Once you have some reserved space, it doesn't really matter if you use a swap file or a swap partition.

Note that you have to do this early in the life of the CF card. Once a card has been thrashed, it's not clear if there is a way to ever get the "used" sectors back to "unused". There is a low-level ATA "format sector" command that may do the trick, but it's impossible to tell if it really has any effect (and it's tough to find a disk formatting program these days that offers a "low-level format" option). That's also why buying a used CF card is such a gamble!

15

New products and alternatives / New Zaurus Successor?

« on: June 03, 2007, 10:21:13 am »

Left it in suspend mode after fully recharging it ... it dropped only 10% batt after five hours of suspend ... *grin*

Will have to try 12 hours suspend to see if it survive.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=162450\"][{POST_SNAPBACK}][/a][/div]

It should ... mine's gone 48 hours on suspend (though that was before I upgraded the RAM to 1 GB). The only time my SA1 gets turned off is disassembly and air travel