bonzoesc

It's the GT-R, and it's only on the Japanese version: [trigger warning: gadget blog] http://www.engadget.com/2007/12/22/nissan-gt-r-disables-spee...

A couple of my coworkers at Basho have done geospatial work with Riak, our scalable, distributed database: http://basho.com/indexing-the-zombie-apocalypse-with-riak/

Welcome to Hacker News!

Modern symmetric ciphers solve the "you need to securely exchange as much key material as you wish to send data" using mathematical formulas to stretch key material. Asymmetric ciphers use mathematical formulas to fix "you need a secure way to exchange keys."

Unfortunately, the math can't be probably secure, only believed secure and proved insecure.

The Authy app is better.

Look at the screenshots at https://itunes.apple.com/us/app/google-authenticator/id38849... . The buttons are ugly, labels are misaligned, and the colors are ghastly.

Re-ordering tokens in the Google Authenticator app is janky as hell too, and the only way you'll know if it's going to work is if the regular view switches to one with subtly different font sizes.

Authy's not without its rough edges, but it never looks that bad.

From down-thread, regarding Google Authenticator: e.g. setting up 2-factor with MS with the same email you use for Google will overwrite the Google one unless you rename it.

Authy does this correctly.

It works better than trapping & killing.

2i doesn't use mapreduce in normal operation.

So the results can be sorted but are not stored in sorted order in the secondary indices?

Secondary indexes are stored sorted on disk, but segmented per vnode. Previously, they wouldn't be sorted before being returned to a client.

Suppose you're querying for "Bananas" through "Bavaria"; the node that contains "Bassoon" could return its first result before the node containing "Bananas" and "Barons", which would, in old Riak versions, result in out-of-order results.

Disclosure: I work at Basho, and have been working on riak-ruby-client updates to support the 2i improvements.

At what cost, though? From DHH's post:

When you expect to win, it’s merely a checked box if you do — after the initial rush of glory dies down.

Winning isn't everything, and in fact can mean very little. Spending exorbitant sums of money (LMP2 isn't cheap) and risking your life (not everyone who started Le Mans on Saturday lived to finish) might not be worth it.

Oracle's got enough cheddar to take it to court or settle out-of-court like their business depends on it.

    libtoolize
    aclocal
    autoheader
    automake --add-missing
    autoconf
    ./configure 
    make

You may want to check out Aphyr's "Call Me Maybe" series of posts about distributed databases: http://aphyr.com/tags/jepsen

The short version is that convergent conflict resolution seems intimidating but works better than locking and synchronization.

The number of entries in a 2i isn't going to bog down querying it any more than lots of objects bog down LevelDB. Make sure your indexes have the right content with the right cardinalities and it shouldn't be a problem.

If you want to drop in to #riak on freenode tomorrow (I'm in the America/New_York time zone) I'm brycek in there.

You could solve this by putting a sort value in the key and using a range query, but this wouldn't work if you want the most recent items keyed with time, because the items could be unevenly spaced back in time.

Pagination is coming soon; it's in riak_kv master already, but in buyer-beware #yolo territory.

LevelDB is also supposedly slower than Bitcask, the default backend, but I'm not sure if this is still true.

Bitcask is faster when all the keys fit in memory: it's designed to load any value with a single disk seek. LevelDB can't make that guarantee, but neither can Bitcask with too many keys for available memory.

I've been trying to think of ways around these problems. A simple thought I had was to simply cache the response as pages in Riak. Although this introduces new problems like how to know how often to reset the cache, too often and I may as well not have this cache, too infrequently and users get stale data.

Caching is one of the two hard problems in software engineering (along with "naming things" and "off-by-one errors"), so good luck :) If you're not opposed to running a separate service, Memcache is what I'd use.

Disclosure: I work at Basho, makers of the Riak database.

However, it's not worth it for that use, and it's especially not worth it playing Pokemon (gotta catch 'em all!) with all the web fonts you see around the internet.

It is useful if you work on more than one computer and want to keep them synchronized though.

Making the enemy believe something is frequently more powerful than making them dead: http://www.psywarrior.com/dissemination.html