I believe the next big thing is ZFS. My paranoid side reads these articles about how disk error rates are staying about the same, but disk capacities are going up and up. I'm thinking that ZFS and anything else that can verify the reads / writes sucess is a very good thing moving forward.

Above and beyond that fact that you couldn't use Jazelle with Dalvik (as mentioned above), I've heard that the performance improvement from Jazelle wasn't really worth the effort for a modern mobile OS. Part of the issue, IIRC, is context switching. If you were running everything in Java (no native code execution) then it might be worth it. But if you're switching from ARM code to Jazelle and back again (as you would with a Linux kernel and userland Java apps), then the overhead takes away the performance gains. If someone has more info, please correct me, my information may be a few years out of date.

Lua does intern all strings, which has many, many nice benefits.

However, if you are dealing with hundreds of megabytes of strings that are being mutated a lot, then this interning process may be a performance problem. However, there are usually good solutions to these kinds of problems. Hop on over to the Lua mailing list or Lua SubReddit and ask for advice. Many other languages often need high-perfomance byte string implementations that for some situations.

I'm really not getting the point of all this effort. OK, sure, its kinda cool that they've got a x86 processor that is small and cool enough to run a phone. But the overall features are only on-par with the existing Android ARM phones of the current generation. The multimedia capabilities are also not substantially different / better.

If I want to buy a new phone, what's going to make the Intel-based offering better? Yes, it runs a different instruction set at a low level, but the only way in which that might have mattered was 3 years ago when Adobe Flash support on ARM mobiles was not good. Today, Flash is less relevant, and does exist.

What's really the value proposition for x86 phones? Price? Performance? New applications? Faster wireless? Smaller / lighter? What? As far as I can tell, it is none of those. "Earning a seat at the smartphone table" isn't enough justification for this, in my opinion.

If it also ran desktop Windows 7, now that would be something. But I'd want at least 8GB of RAM, and ideally a 64-bit dual core (quad preferred). Then I could really fulfill the promise of the Moto Atrix, and truly carry my desktop around with me in my hand. That would be something I can't easily do with an ARM-powered Android phone.

Rsync is not a backup solution, though you can build a backup solution with it.

We've been using rsnapshot to back up data to removable drives (carried offsite every day) and also to a local server with a lot of storage. The local server helps with "oops, I just deleted a file" moments. It uses hard links for identical files to save space.

There is no special recovery software needed. Just go into the directory and look at the files. Simple, easy, and no lock-in.

There was some discussion of this on Reddit a while back.

I second Mike Pall's comments. The Lua codebase is relatively small, and your puny brain can probably understand all of it from top to bottom. Other systems, like GCC and GHC, would be much more challenging to understand completely.

Uh, except for the CC-licensed stuff, we don't get the "source code" to mainstream music and videos.

The "source code" for a song is the individual track recordings and other stuff that gets mixed into the final product. For movies, there are tons of assets that go into making the movie: the dailies, raw audio tracks, CG models, etc., etc., etc.. Otherwise, to do a high-quality derivative of Avatar, such as just a couple of Navi' standing around and telling jokes, you'd need to re-create the very sophisticated CG models used. That would be relatively easy if the 'source code' of the movie was released, but is incredibly difficult without it.

I'm in a similar age category. And some things are harder for me to pick up these days. But other things aren't.

I'm not really trying to learn new languages at this point, over the last 15 years I've surveyed at least 150, and trying out small projects with at least 10 of the best ones.

Right now I'm going "back to school". Studying AI http://www.ai-class.com/, and Algorithms http://mitpress.mit.edu/algorithms/. I briefly toyed with the idea of studying Knuth, but it didn't seem practical for what I want to accomplish.

Why not work on some FOSS projects? Even fixing bugs can help keep the old gears turning. Better yet, start your own fun project.

Well, let's look at the fundamental motiviation of HFT: making money.

OK, nothing wrong with that. However, we, as a society, have reason to question how everyone makes their money. Lots of people don't want a minority of people to make money clubbing baby seals. The value generated by that practice (nice fur) is not high enough overall benefit to society to justify it.

What is the net result of HFT? The people doing the HFT make money, sure, but what value are they generating? Nothing, as far as I can tell.

HFT constitutes a tax on everyone else in the market who is going to hold onto a position for more than a couple seconds. Anyone who is a long-term investor. Every sale you make, will generate less profit. Everything you buy will be more expensive. HFT is just siphoning off money from everyone else.

The markets work because they allow more efficient allocation of capital to useful functions, and they move money away from non-useful (or at least not money-making) functions in society. This is good. HFT is sand in the gears. And don't give me arguments about how they provide market liquidity, the markets were doing just fine before this practice started.

Yes, and I agree with the sentiment that you shouldn't just re-write code just because it is ugly or something. However, I also remember using Netscape Navigator during that time period. It wasn't a pleasant experience because of the crashes and such. It is quite possible that they could have concentrated and started refactoring the code, and fixing all the bugs. Maybe. We'll never know now. At any rate, even the early Mozilla browser releases were a breath of fresh air compared to Navigator.

Curious that JWZ and his time at Netscape were particularly lauded here.

It's quite likely I'm being a bit snarky here... but Netscape lost the browser wars just a few years after they hit it big. And the core code of Netscape Navigator was bad enough that they eventually abandoned it around 1999 with the start of the Mozilla project.

Now don't get me wrong, it was only through the herculean efforts of guys like JWZ at Netscape that allowed them to ship a product at all. And certainly it made him and some of the founders a lot of money, which is a valid measure of success in business.

But to point to that particular code base as an example we all should follow? I don't think so. Certainly, choosing C++ then (or now in my opinion) is a mistake. And I've definitely seen people get overly rambunctious with architecture... especially in the Java world. But I think that's mostly the result of programming languages sucking as much as anything else. That and most people just aren't that good at design. Mostly meaning that when they've come up with a bad design themselves, they can't admit that and then really do what it takes to try and fix it. Of course, in the business world there are always severe time / money constraints, so that makes it real hard. And that's when not having unit tests hurts more... because it is harder to make significant changes to the code and have some assurance you didn't make mistakes.

That N900 is nice. Really nice screen and processor.

But the battery isn't going to be big enough. I had to get a 2600mAh battery for my G1 (which makes the phone quite fat) just to get some decent usage out of it. The standard 1100mAh wasn't nearly enough on the G1, so I doubt a 1300mAh one on the N900 is going to be sufficient either.

The other critical factor for me is the keyboard. The G1 has all the symbols you'd normally use in programming, and I really appreciate that. Well, except for the escape key, but that's mapped to the trackball with the ConnectBot application (local terminal and ssh client).

Still... a laudable effort from Nokia. If I could just talk them into one more row of keys...