Many ARM-based chips include the "Jazelle DBX" (Direct Bytecode eXecution) hardware CPU extension, which lets "95% of [JVM] bytecode" be executed directly by the CPU -- without need for recompilation to 'native' ARM/Thumb instructions. (See http://en.wikipedia.org/wiki/Jazelle )

However, unlike most of the ARM universe which is fairly open, Jazelle DBX's specs, implementation, and operating details are apparently a closely held secret, shared by ARM only with select JVM implementors. I'll be interesting to see if ARM decides to help out the OpenJDK people. Googling around, it looks like so far the answer has been "No."

That is a GREAT question, and the full answer is complicated and partially proprietary. But basically, you've touched on the problem of indirect control flow, which exists in C (call through a function pointer), C++ (virtual function calls), and in Java, .NET, ObjC, etc. The general approach is that at each indirect call site, you "solve for" what the actual targets of the call could possibly be, and take it from there. The specific example you gave is actually trivially solved, since there's only one possible answer in the program; in large scale applications it is what we call "hard." And yes, in some cases we (necessarily) lose the trail; see "halting problem" as noted. But we do a remarkably good job on most real world application code. I've been working with this team on this static binary analysis business for eight or nine years, and we still haven't run out of interesting problems to work on, and this is definitely one of them.

Oops, I wasn't logged in. The above comment is from me, Mark Kriegsman, Director of Engineering at Veracode.

Nevertheless, White Flame, you should be proud. The SWEET16 implemention is pretty damn tight. If you can even squeeze out one byte, or one cycle, from a Wozterpiece like that, I say Congratulations, and Well done.

I gave a couple of these for the holidays this year thinking that this would be a great way for family to share pictures but we had an unbelievably difficult time getting them to share what we wanted when we wanted.

Thank goodness that's all solved now!

HTTP-NG ( http://www.w3.org/Protocols/HTTP-NG/ ) was researched, designed, and even, yes, implemented to solve the same problems that Google's "new" SPDY is attacking -- in 1999, ten years ago.

The good news is that SPDY seems to build on the SMUX ( http://www.w3.org/TR/WD-mux ) and MUX protocols that were designed as part of the HTTP-NG effort, so at least we're not reinventing the wheel. Now we have to decide what color to paint it.

Next up: immediate support in FireFox, WebKit, and Apache -- and deafening silence from IE and IIS.

For an Mac OS X volume (HFS, HFS+), I've had lots of luck with Data Rescue II ($99) for recovering from serious drive failures. For drives that are still operational but have become borked at the filesystem level, Disk Warrior does a great job of rebuilding a healthy new directory structure. I make it a point to always have a copy of Disk Warrior within 100 yards of my PowerBook.

Also, a couple of times I've had dying drives that work OK for a few minutes after a cold boot, and then they (heat up and) die. I've had good luck throwing the drive in the freezer (in a ziplock bag) for a day, then powering up it, recovering as much as I can until the drive chokes again, lather, rinse, repeat, until all recoverable data has been copies off to a good drive.

He WASN'T throttled to 48Kbps -- slower than a 56Kbps dialup modem.
He WAS throttled to 480Kbps, and was getting download speeds of about 50K (that's kiloBYTES) per second (per connection).

TFA:"Bringing up the Status window I noticed my download performance was a far cry from my 7 mbps speed, but rather a measly 0.48 mbps...:"

0.48Mbps = 480Kbps (kiloBITS/sec) = roughly about 48KBps (kiloBYTES/sec)

So the /. story summary makes things sound an order of magnitude worse than they are. But you know, what's just ONE order of magnitude of error between friends, right?

The Bell Centennial font, designed in 1976 for printing phonebooks, had "holes" designed into it for (excess) ink to flow into without compromising readability. http://www.nicksherman.com/articles/bellCentennial.html Interesting to see how the 'benefit' of holes has changed.