Monday, March 8, 2010

Does NetFlix count differently than I do

We have been happy Netflix subscribers for a long time.

We are members of the "4 DVDs" plan, meaning that we can get up to 4 DVDs at a time.

But, several times recently, we have had 5 DVDs at once.

At first, I thought maybe Netflix had lost count?

But it has happened more than once, and this time, when I visited my queue, I noticed that not only did the Queue page list 5 entries under "DVDs At Home", but there was a link:

Why do you have an extra DVD?"


Yes, that was my question exactly! So I clicked the link, and Netflix told me:

We have sent you an extra DVD rental from your Queue.

NOTE: After your extra DVD rental arrives, get your next movie by returning any two movies.


Hmmm. I am pleased that they provided the link, and I am pleased that, for whatever reason, they sometimes send us 5 DVDs at a time rather than 4, but I still don't understand why I have an extra DVD.

Anybody understand what's going on here and can explain it to me?

Sun Drizzle project

I've been intermittently following the progress of the Drizzle project, which is an offshoot of MySQL. You can read about some of the early goals of the Drizzle work on Brian Aker's weblog:

Adopt external libraries, use open source mechanics for contributions, keep to an open style of communication, and remove the line between internal and external development.


Several of the Drizzle engineers have been posting a lot this month, talking about where they see Drizzle going and what they mean by "a database for the Cloud".

There's definitely some very interesting work being done by these folks; it will be interesting to keep an eye on it and see if they can actually build a community around their ideas.

Saturday, March 6, 2010

Outright conference champions!

Congratulations to the UC Berkeley Men's Basketball Team: outright Pac-10 conference champions for the first time since 1960!

Thursday, March 4, 2010

Google hackers targeted SCM systems

There's an interesting article in Wired today regarding the Google hacking attempts:

Hackers who breached Google and other companies in January targeted source code management systems, security firm McAfee asserted Wednesday, manipulating a little-known trove of security flaws that would allow easy unauthorized access to the intellectual property it is meant to protect. The software management systems, widely used at businesses unaware that the holes exist, were exploited by the so-called Aurora hackers in a way that would have enabled them to siphon source code as well as modify it to make customers of the software vulnerable to attack.


McAfee has published more details, but I haven't read them yet.

As the McAfee researchers point out, your SCM system is the most important system in your entire software development process, and you must pay the utmost attention to administering it properly:

these were the crown jewels of most of these companies in many ways — much more valuable than any financial or personally identifiable data that they may have and spend so much time and effort protecting.


It is certainly true that some of the default security settings on SCM systems are weak, and allow too much access if left unchanged. However, administrators can definitely provide alternate settings.

An important principle of security protection is "defense in depth"; that is, providing multiple layers of defense so that if one is breached, the entire system does not fail. It sounds like in at least some cases, there was insufficient attention paid to administering security at all the various layers where it can be done.

Wednesday, March 3, 2010

The Mozilla JS engine is getting ready to evolve again

Some of the most exciting work in programming language implementations is occurring in the JavaScript world. Mozilla's TraceMonkey project brought massive performance improvements to JavaScript starting with Firefox 3.5, using a technique called a tracing JIT.

Similar efforts, using dramatically different mechanisms, occurred inside other major JavaScript engines, such as Google's V8, the WebKit JavaScript engine, etc. Over the last few years, lots of experimentation occurred, and a lot of learning about JavaScript performance happened.

Now the Mozilla team are starting to incorporate a number of lessons learned from all these experiments into the next revision of their JavaScript engine, with the basic technique being to try to incorporate the good aspects of multiple approaches:

So, a type-specializing trace JIT generates really fast code, but can’t generate native code for the situations described above. Conversely, an optionally specializing method JIT generates moderately fast code, but can generate native code for any JavaScript program. So the two techniques are complementary–we want the method JIT to provide good baseline performance, and then for code that traces well, tracing will push performance even higher.


It's interesting that much of this progress is able to occur because the various competing teams (Google, WebKit, Mozilla, etc.) are all doing their work out in the open:

We decided to import the assembler from Apple’s open-source Nitro JavaScript JIT. (Thanks, WebKit devs!) We know it’s simple and fast from looking at it before (I did measurements that showed it was very fast at compiling regular expressions), it’s open-source, and it’s well-designed C++, so it was a great fit.


This work is delightful for multiple reasons:

  • As a user, I can continue to anticipate better browsers, faster web pages, and a happier overall experience

  • As a programmer, I can continue to benefit from learning about all these different techniques


Nothing but goodness in all directions!

Tuesday, March 2, 2010

Following links to Cassandra

The world of extreme ultra-high-end scalable systems begins with Google, and their well-known technologies: BigTable, GFS, Map/Reduce, Protocol Buffers, and so forth. But that world certainly doesn't end with Google; it's a big world, and there's lots of fascinating work being done at places like Amazon, Flickr, Yahoo, and more.

Recently, I started at Curt Monash's DBMS2 blog, where I found an introductory essay about Cassandra.

That led me to Todd Hoff's essay on Cassandra versus sharded MySQL.

That led me to Evan Weaver's overview article about Cassandra and how it fits in at Twitter, complete with this great hand-drawn image: .

That led me to the Cassandra wiki at the Apache Software Foundation.

That led me to the video lecture by Eric http://www.blogger.com/img/blank.gifEvans of Rackspace, and to the paper by Lakshman and Malik about Cassandra at Facebook, as well as to Lakshman's earlier work as part of the Dynamo project at Amazon.

I'm still wrapping my head around these eventually-consistent, non-relational data stores; after all, I'm a relational DBMS guy from a long time back. The Cassandra papers are quite approachable, and give a lot of fascinating insight into the behavior of these systems:


we will focus on the core distributed systems techniques used in Cassandra: partitioning, replication, membership, failure handling, and scaling. All these modules work in synchrony to handle read/write requests. Typically a read/write request for a key gets routed to any node in the Cassandra cluster. The node then determines the replicas for this particular key. For writes, the system routes the requests to the replicas and waits for a quorum of replicas to acknowledge the completion of the writes. For reads, based on the consistency guarantees required by the client, the system either routes the requests to the closest replica or routes the requests to all replicas and waits for a quorum of responses.


On we go; the learning never stops!

The Onion on online privacy

Once again, the Onion nails it.