One Mutation per 15 Cigarettes Smoked

January 22nd, 2010

Now that’s a memorable factoid. Nature recently published a paper titled “A small-cell lung cancer genome with complex signatures of tobacco exposure” (Nature 463, 184-190 (14 January 2010), Pleasance et al), which as its title implies, contains the summary of the sequence of a cancer genome derived from a lung cancer tumor. It’s an interesting read; I can’t claim to understand it all. At a high level, they found 22,910 somatic substitutions, 65 insertions and deletions, 58 genomic rearrangements, and 334 copy number segment variations were identified; as I understand it, these are uncorrectable errors, i.e. the ones that got past the cell’s natural error-correction mechanisms. That’s out of about 3 gigabases in the entire genome, or an accumulated error rate of about 1 in 5 million.

I’m not an expert on cancer, but the way it was explained to me is that basically every cell has the capacity to become a cancer, but there are several dozen regulatory pathways that keep a cell in check. In a layman sort of way, every cell having the capacity to become a cancer makes sense because we come from an embryonic stem cell, and tumorigenic cancer cells are differentiated cells that have lost their programming due to mutations, thereby returning to being a (rogue) stem cell. So, a cancer happens when a cell accumulates enough non-fatal mutations such that all the regulation mechanisms are defeated. Of course, this is basically a game of Russian roulette; some cells simply gather fatal mutations and undergo apoptosis. In order to become a cancer cell, it has to survive a lot of random mutations, but then again there are plenty of cells in a lung to participate in the process.

Above: a map of the mutations found in the cancer cell. The 23 chromosomes are laid end to end around the edge of the circle. There’s a ton of data in the graph; for example, the light orange bars represent the heterozygous substitution density per 10 megabases. A higher resolution diagram along with a more detailed explanation can be found in the paper.

The tag line for this post is lifted from the discussion section of the paper, where they assume that lung cancer develops after about 50 pack-years of smoking, which roughly translates to the ultimate cancer cell acquiring on average one mutation every 15 cigarettes smoked. Even though this is an over-simplification of the situation, the tag line is memorable because it makes the impact of smoking seem much more immediate and concrete: it’s one thing to say on average, in fifty years, you will get cancer from smoking a pack a day; it’s another to say on average, when you finish that pack of cigarettes, you are one mutation closer to getting cancer.

The Enlightening Bridge Between Art And Work

January 12th, 2010

As I was driving home today, I enjoyed a delightful morsel on NPR’s All Things Considered about the The Enlightening Bridge Between Art and Work by Alain De Botton (it’s better listened to than read, imo).



Here’s an excerpt of the spot that I found particularly poignant:

Two centuries ago, our forebears would have known the precise history and source of almost every one of the limited number of things they ate and owned. They would have been familiar with the pig, the carpenter, the weaver, the loom and the dairymaid. The range of items available for purchase may have grown exponentially since then, but our understanding of their genesis has grown ever more obscure. We are now as imaginatively disconnected from the production and distribution of our goods as we are practically in reach of them, a process of alienation which has stripped us of opportunities for wonder, gratitude and guilt.

That last sentence, I think, resonates strongly with my personal motivation as a Maker. I dive deeply into the supply chain, learning the processes and understanding the people behind our Things, because it enables me to once again feel the wonder, gratitude, and guilt for the Things we otherwise take for granted. Wonder at the skill of craftsmen and the cleverness of designers; gratitude for the passion and hard work of my peers; and guilt for the sacrifice, waste, and unsustainable practices motivated by an obscure system of perverse economic incentives.

Tor Bridge on chumby One

December 30th, 2009

Tor is an open-source project that is dear to me for many reasons. For those who are unfamiliar with it, in a nutshell, Tor can enhance your anonymity on the internet: it obscures who you are, and what sites you are visiting. This is important, especially for people who live and work in oppressive regimes where direct access to on-line social networking is restricted, and where your opinions can put your life at risk. Protecting free speech is important to me.

Recently, Jacob Appelbaum pinged me and asked if it would be possible to make a Tor Bridge Relay client for the chumby One. Bridge relays are needed because policy-making entities can “filter” Tor by querying the list of public Tor exit and entrance nodes, and consequently direct the country’s internet authorities to block all Tor nodes. In other words, once you enter Tor, you have enhanced anonymity, but Tor itself has a clear and public footprint on the internet. Because of its well-defined footprint, someone with sufficient authority can “cut it out” by simply ripping out all of its connections to the rest of the world.

A Bridge Relay (or a bridge for short) “diffuses” the edges of Tor by adding another hop between a semi-secret distributed relay network and the public edge of Tor. Crossing the bridge requires getting a list of bridge relay nodes from a relay server that will only reveal a couple relay nodes at a time to a gmail email address, so as to foil regimes attempting to resolve the distributed relay network by simply repeatedly querying the relay server. However, the effectiveness of the bridge network is directly proportional to the number of devices that are serving as a relay. This is where you come in. A regime’s ability to determine the footprint of the bridge network is thwarted by having a large number of ordinary citizens around the world run bridges; in theory, a large and growing number of bridge nodes will keep Tor one step ahead of someone attempting to block Tor.

The chumby is a hackable linux device, with a sufficiently powerful CPU and just about enough memory to run a bridge. With the chumby One, it’s now cheap, too. And there’s a fair number of them out there. Which brings us back to Jacob. He emailed me about a week ago asking if it’d be possible to port Tor to chumby and run it in the background, and it certainly is. So, I’ve created a little “howto” guide on cross-compiling Tor for the chumby One, and I’ve even made a “no-touch” installer for Tor bridges on the chumby One (download and instructions). So, people who don’t have the time to build it from scratch can just download it and install it in just a few minutes using a USB dongle. Once it is installed, it will load every time at boot, even without the USB dongle in place; and, it can be quickly and fully removed by doing a factory reset. While Tor is running, I’ve noticed no performance degradation in widget playback, which is nice, but then again I’ve only been testing it for a day or so now. Again, the standard disclaimer — this blog does not represent chumby corporate, it’s my personal blog, so hacking your device to do this may void your warranty.

The no-touch install creates a swapfile on your chumby One, because the Tor client is just a wee heavy for the chumby without it. Note that swapfiles are hard on Flash memory, so you do run some risk of eventually wearing out the drive, but in my experience the swapfile hardly gets used. It also installs a cgi-script on your device so you can monitor the status of your Tor bridge, you can see a sample of what it looks like here. It does reveal a bit about what’s going on inside your chumby on a public web port, but this is all experimental stuff anyways; there are probably much better and more secure ways to do this. Being a hardware guy, my script-fu is only so good (but woe to the software guy who comes at me with a soldering iron), so the install scripts work, but need improvement; maybe someone out there can help with that.

This is a shout-out to my friends at 26c3. Wish I could be there with you in the hack center.

Composite Video Output on Chumby One (Hack)

December 28th, 2009

xobs recently completed a hack that adds a composite video output to the Chumby One. You can read step by step details on how to do it on the chumy wiki. The hack takes advantage of the fact that the CPU, a Freescale i.MX233, has a built-in composite video output that’s not connectorized, but available on the motherboard: you can solder a video cable to a set of pads as shown below (click for a larger version).

With a little case modding, you can have a very tidy video connector on the back as well.

In addition to the hardware mods, you need to install a modified kernel that contains the drivers for the video output, and call some scripts to switch the LCD output to the video output (instructions here). Unfortunately, you can only drive one screen at a time with the i.MX233, so it’s not the easiest to interact with, but it is pretty neat for passively displaying information on your TV. Just configure the chumby with your favorite channel, plug it into an unused composite input, and watch photo slideshows from your favorite photosharing website, news headlines, Twitter feeds, eBay auction status, etc. Or, you can use it to make your TV chuck-tastic:

Follow-up on the SSD

December 17th, 2009

A while back I asked readers for some advice on a reliable SSD. One reader also corroborated my experience with a story of his own Crucial drive’s failure, and a number of readers had recommended an Intel-branded drive. However, some research on the net indicated that several people had reported an unusually high failure rate on Intel drives as well, which leads me to think that possibly Intel is just doing a very good job of marketing their solution (they are pretty good at pushing bad technology to early adopters…there was Rambus, and Itanium…not to mention that of all the ISA’s out there, x86 wouldn’t be the one I’d chose to be the dominant standard). Or, as one comment pointed out, SSD is just not mature right now and it should be avoided altogether if soft-reliability is a key concern (as opposed to a reliability concern due to dropping or vibration damage).

I did end up getting a full refund for my return of the failed Crucial drive, and instead bought a 2.5″ 256 GB Samsung SSD (MMDOE56G5MXP-0VB) at a relatively decent price. I didn’t see too many complaints on the net about the Samsung drive, and I’m hoping the fact that Samsung is 100% vertically integrated for SSD manufacture (they make the FLASH, DRAM, and embedded controller for their SSDs, unlike all their other competitors) gives them some institutional expertise about Flash technology that they’ve baked into their product (how naive of me). I’ve been running with this drive for about a month now, and it hasn’t failed yet (knock on wood). I’m currently at about 160 Gbytes used out of 231 available (this is also one of the reasons why I couldn’t use an Intel drive, its largest capacity of 160GB was too small and SSD’s perform very poorly if you fill them up to near capacity due to the mismatch between erase block size and the native block size of the filesystem).

The Samsung drive is benchmarked to run a bit slower than the Intel and Crucial solutions, and anecdotally there might be a tiny performance decrease compared to the failed Crucial drive, but the system overall is still blazingly fast (and it’s still working). Searching my filesystem is super-fast, and I no longer loathe opening a directory with thousands of files. Boot time is cut down to about 70% of what it was before, and key applications load and quit much faster running off an SSD.

More importantly, I can now walk around with my laptop without first needing to park the hard drive heads. I can use it on bumpy car rides in Asia, and I can brave through turbulence without fear of crashed heads. Another major bonus is I now feel no worry turning the volume up on my laptop when listening to music. The thought of intentionally channeling a high-amplitude vibration into my hard drive always disturbs me, so I rarely listen to music on my laptop speakers, or when I do I make sure it’s very quiet. It’s well-documented that acoustic vibration reduces hard drive performance (here’s a YouTube video of someone shouting at a drive array in a datacenter, causing the array to slow down), and from my understanding it can actually contribute to premature failure of the drive. So, overall, I’d have to say I’m quite pleased with the new SSD, although I am proceeding cautiously — I bought a 64 GB USB thumb drive and I backup my data fairly often in anticipation of the dreaded day when my system seizes up on me again. And, when it does, I will probably once again buy another SSD, hoping that as time goes on the technology will mature and become more reliable.