The Sergey, Larry, Eric test by Anne & Linda: 23andMe at home

“We really think that we can change Health Care…I want to change it in 5 years…it has to change and that’s we all are about” – says Anne Wojcicki, 23andMe co-founder, in the Google Tech Talk on Googling the Googlers’ DNA: A Demonstration of the 23andMe Personal Genome Service.

Also a good presentation by Linda Avey, other co-founder, for instance on data privacy and service security: “We take the security of our customers’ data to the highest degree…you guys (Googlers) are very much of the same mind..One of our leading engineers is probably the most paranoid man we’ve ever meet and he is the perfect guy for that.

Here are my screenshots on the genetic puzzle on the Google triumvirate presented by Anne Wojcicki:

More on 23andMe on Pimm:

23andMe on the biparental inheritance of mitochondrial DNA and more

inF.A.Q. for 23andMe: what if I have mitochondrial DNA from Pa?

23andWe follows 23andMe: First generation of Consumer-Enabled Research

How to predict the future via Twitter: Google invests in Navigenics

The second goal of 23andMe: using customer’s real health data later

The Spittoon: the eminent corporate blog of 23andMe and Consumer Enabled Research

3 thoughts on “The Sergey, Larry, Eric test by Anne & Linda: 23andMe at home

  1. Congratulations on your initiative.
    As you know, Cleveland Clinic has collaborated with Google Health and is in the process of improving health and wellness.
    Health is largely dependent on environmental and lifestyle choices over above genetic predisposition.
    Providing solutions on every front is a way forward, with individuals adding their actions to the total wellness picture.

  2. Soft-updates guarantees that the only filesystem inconsistencies on unclean shutdown are leaked blocks and inodes. To resolve this you can run a background fsck or you can ignore it until you start to run out of space. We also could’ve written a mark and sweep garbage collector but never did. Ultimately, the bgfsck is too expensive and people did not like the uncertainty of not having run fsck. To resolve these issues, I have added a small journal to softupdates. However, I only have to journal block allocation and free, and inode link count changes since softdep guarantees the rest. My journal records are each only 32bytes which is incredibly compact compared to any other journaling solution. We still get the great concurrency and ability to ignore writes which have been canceled by new operations. But now we have recovery time that is around 2 seconds per megabyte of journal in-use. That’s 32,768 blocks allocated, files created, links added, etc. per megabyte of journal.

Comments are closed.