Satoshi is ...

... Satoshi?

At least, that's what Newsweek claims: The Face Behind Bitcoin

Of course, there is also the chance "Satoshi Nakamoto" is a pseudonym, but that raises the question why someone who wishes to remain anonymous would choose such a distinctive name. It was only while scouring a database that contained the registration cards of naturalized U.S. citizens that a Satoshi Nakamoto turned up whose profile and background offered a potential match. But it was not until after ordering his records from the National Archives and conducting many more interviews that a cohesive picture began to take shape.

Temple City, eh? I remember my mom used to take me to the skateboard park by the Whittier Narrows dam, which is only a mile from Temple City.

Newsweek even runs a picture.

Let the madness begin.

Dear Ester: a very short review

I'm not sure what exactly to make of Dear Esther.

Is it an adventure game?

Many would say yes, and I think I'd agree. You are placed on an island, and your controls allow you to move around the island, to explore different areas and visit different locations. You can look at items, zoom in on them, view them from different angles.

However, you can't actually interact with anything.

The closest you get to interacting is that, from time to time, the game issues a short speech, as if from an off-stage narrator.

The speeches, as you progress through the game, form a story; at least, they form the fragments of a story. It's never really clear whether the narrator of these speeches is you, or somebody who came before you. And it's never really clear whether the character being referred to in the 3rd person in these speeches is you, or whether the narrator is telling somebody else's story to you.

The story clearly takes place on the island, though.

So in that respect many would call Dear Esther a work of art, an interactive story, a computer-driven epic poem. And I think I'd agree with that, too. It's clearly a performance, and, as art, it certainly is well-crafted.

The story is a compelling one, too. It's a tragic story, one told many times before, but told quite well, both in words and in more subtle ways (e.g., via the placement of candles on the path, or the paintings on the walls of the cave). More than once I found myself overcome with emotion as the game delivered yet another glimpse into its private world.

Dear Esther also compels on a purely aesthetic level. The artwork is beautiful; the music is gorgeous. The voyage through the caves in the middle of the island is just stunning. It reminds me of the first time I played Myst, 20 years ago; during those days I was often content just to walk around the island and gaze at the scenery.

It's clear, I believe, that Dear Esther is trying to do more than "just" tell a story. The visuals and the monologues and the wandering around all work together, full of allegory and metaphor. There are biblical references: quotations from Acts are painted on objects in the game, as well as referenced in the speeches, and stories such as Lot's wife, or the pilgrimage to Damascus, are touched upon, as well as less literal, but still clear, biblical references:

I have run out of places to climb. I will abandon this body and take to the air.

And there are other literary references, such as this fairly clear nod to John Donne's No Man Is An Island:

he would have realised he was his own shoreline, as am I. Just as I am becoming this island ...

I played through Dear Esther rather quickly, thirstily, eager to push the story forward. Others, I am told, savor this journey more slowly, even re-play it to gain a different perspective. The verses delivered by the narrator are randomized, so you may find your second time through the game to be a quite different experience.

So what, then, is Dear Esther? Is it a meditation on the perils of addiction? Is it a transcendent expression of pure love? Is it a commentary on the impermanence and mortality of man as he strives to create meaning that will outlive him? Is it "simply" a work of art, simultaneously none and all of the above?

I'll close with this, my favorite speech, hoping it reveals both nothing and everything:

I’ve begun my voyage in a paper boat without a bottom; I will fly to the moon in it. I have been folded along a crease in time, a weakness in the sheet of life. Now, you’ve settled on the opposite side of the paper to me; I can see your traces in the ink that soaks through the fibre, the pulped vegetation. When we become waterlogged, and the cage disintegrates, we will intermingle. When this paper aeroplane leaves the cliff edge, and carves parallel vapour trails in the dark, we will come together.

The open plan debate, redux

Here come the open plan fanatics again, with a massive piece in this week's NYT business section: The Monuments of Tech.

software is invisible and change is high technology’s most valued commodity. Insubstantial as a cubicle seems, in the tech industry it has given way to the long tables and broad whiteboards of open-plan offices, where everyone taps into a common Wi-Fi signal. Office teams grow or shrink in these open rooms, moving work and information as quickly as possible.

"Change is high technology's most valued commodity"?

Oh, please.

I am instantly reminded of the greatest Dilbert ever.

Nevertheless, on charge the open space zealots, trumpeting their self-appointed brilliance:

The buildings hold 6,000 people. In the past, Facebook moved around as many as 1,000 of them a month, reassigning them to new short-term projects. Walkways double as spaces for ambulatory meetings, held on the go so they are short and decisive.

Casual meeting areas are set off from the open plan by squares of plywood hanging from the ceiling, a visual “under construction” reference meant to reinforce the company’s ethos. Facebook even spent money to expose its networking wires, which dangle along the ceiling.

“It’s designed to change thinking,” said John Tenanes, who oversees Facebook’s buildings as its director of real estate. “Even if the meeting doesn’t move faster, we want people coming up with new stuff.”

Yes, indeed: new stuff. I suppose that, if you are a business journalist, you spent enough time hearing about Heraclitus in your journalism classes to dispense wisdom such as

Here, as at many other tech companies, is a sense that nothing is permanent, that any product can be dislodged from greatness by something newer. It’s the aesthetic of disruption: We must all change, all the time.

and

Facebook’s all-night hackathons aren’t just an echo of crashing out a project before a college final: They are efforts to keep experimenting, to try something new before some scrappy start-up does.

And so the article continues, for thousands of words, slathering praise on every little eccentricity of Twitter, Facebook, and Google, full of nonsense like:

Doors now seem an impediment, slowing the making of something new.

Some of the article's observations are sensible, such as the Google Real Estate team's finding (a "result of detailed study"):

“If people are more satisfied with the temperature, they are more comfortable and creative,” Mr. Ravitz said. The goal is to make 80 percent or more of the population happy with the office climate.

Well, duh. I hope they didn't spend too much money on that detailed study (and I pity the engineers who were the unwilling subjects of that research).

And Google Real Estate's findings that office chairs matter, and that noise matters, and that air quality matters, and that lighting matters, show that perhaps common sense may, some day, prevail.

But it's just bizarre, all this breathless desire to be "short and decisive," to be ever "under construction," to always be "coming up with new stuff."

Certainly there are great engineers at Twitter and Google and Facebook, and they have indeed done some brilliant work. But not, I am certain, while sitting in "booths that look as if they were lifted from an upscale diner," nor while on "the kind of angular couches and chairs that Dick Van Dyke would be happy to use for a pratfall," nor while having to tolerate the fact that "irregular soft cubes serve as impromptu meeting areas."

And, I can guarantee you, none of these frantic "meetings, held on the go" cover the kind of work that actually matters in software.

Building a cryptographic key-exchange algorithm, a distributed consensus protocol, a secure networking library, a cache-conscious database index, or a lock-free hash table, requires deep concentration, sustained over long periods of time, with as few interruptions as possible.

Trust me: I know. I haven't done all these things, but I've done a number of them. Quietly, patiently, and without ever even once finding that "individual file cabinets on rollers that can be moved to wherever an employee will next be working" would have improved the process, or the result.

Buried at the VERY END of the article, after all the chatter about consultants from Disney, Gehry-designed buildings, multi-colored campus bicycles, and other folderol, the piece finally admits:

“The harder we work,” he said, “the more important it is to have space to get away from the chaos for a while.”

Yes.

That should have been the lede, not the closer.

Meanwhile, a much smaller article, on the following page of the very same business section, but (refreshingly) free of full-color pictures and celebrity sightings (Sheryl Sandberg! Dick Costolo! Mark Zukerberg!), is a mother lode of calm reasoning: Where Sounds Have No Barrier

Auditory distraction occurs when a noise forces you to switch your attention away and then back to your work, Professor Lee said. This amounts to a “cognitive load” that makes it hard to maintain your concentration, he said. Open-plan offices are particularly challenging for the hearing-impaired, he said, because hearing aids tend to amplify noises indiscriminately, making it harder to listen selectively.

In open work spaces, even small noises have the potential to distract us, Dr. Goldsmith said: Because so much hearing occurs unconsciously, we may feel stressed from working in an open office and not know why. Noise “is really quite insidious in that sense,” he said.

Sadly, all this common sense doesn't stop the article's author from interjecting:

It’s true that when overheard conversations aren’t irritating and irrelevant, they can impart useful pieces of information and enhance collaboration. That’s one of the reasons that tech companies like Facebook, Twitter and Google favor open offices.

Well, sure, if those overheard conversations aren't irritating and irrelevant, they might be useful. But that's the point! They are irritating and irrelevant.

But that's not why those tech companies built offices like these.

Those tech companies did it because they thought it was cool and trendy and novel, and because it got publications like the New York Times to write long front-page articles with full-color pictures and lots of name dropping.

Perhaps, someday, when they finally realize what a disaster it was for the poor engineers who are trying to endure those zoos, they will stop seeing doors as an "impediment," will stop having the furniture "replaced with no advance warning," will stop thinking that "ample sticks and twigs on the wall" is somehow useful to an engineer.

In the meantime, at least for now, at work I'm lucky enough to have an environment where I can (mostly) sit quietly, blocked from (most) interruptions, in a very nice chair, with a thermostat I can control and a large skylight nearby, and try, somehow, to get some real work done.

Three years!

Oh, please please please please please please may it be so.

Names and values

One of the greatest educators in the Computer Science field, Niklaus Wirth, has reached his eightieth birthday, which was reason for a recent celebration.

Among many other things, Professor Wirth is the subject of a very old, very dumb, Computer Science joke; when asked how to pronounce his name, he was reported to have replied:

If you call me by name, it is VEERT.

If you call me by value, it is WORTH.

The joke of course refers to one of the basic techniques used in programming languages, which is exhaustively explained by this tedious Wikipedia page.

I rather prefer the joke.

Anyway, I was thinking recently about a completely different aspect of names versus values, which arises in the work I do at my day job.

When Version Control Systems keep track of objects, they pay particular attention to two aspects of the object:

1. The NAME of the object, e.g.

   derby/trunk/java/engine/org/apache/derby/iapi/util/Operator.java

2. The CONTENT of the object, e.g.

   package org.apache.derby.iapi.util;
   
   /**
           Provides an interface for an operator that operates on a range of objects
           E.g in a cache.
   */
   public interface Operator {
   
           /**
                   Operate on an input object
           */
           public void operate(Object other);
   }
   

The name of the object is an obvious way to give you a handle to the object, and many of the operations that the Version Control System provides involve using the name:

• What version of Operator.java is the most recent one?
• What version of Operator.java was used in release 10.8?
• Who has Operator.java checked out?
• Which branches are there of Operator.java

But a really interesting aspect of Version Control Systems is that they are tools for helping you track and manage change.

And one of the things that can change about an object is its name.

That is, you can rename a file.

A lot of the original Version Control Systems, back in the 1970's and 1980's, didn't handle renaming a file very well. If you changed the name of a file, often the best you could do was to delete the file with the old name, and add the file back with the new name, leaving you with two different objects, and a gaping discontinuity in the history of the object.

And that's wrong, because there aren't two different objects; there is one object, and what you did was to change its name.

A high quality Version Control System takes care of these problems for you, and systems like git and Perforce have rich functionality in this area and have no problem understanding when a file is renamed.

But it's interesting that they do this in quite different ways.

Perforce maintains a databases of names. Each file name is a separate entry in its database, and it records things such as when two names refer to the same file (that is, when you have made a branch of a file), or when a file's name was changed (that is, when you have renamed a file). At the very lowest levels of the database, in fact, these things are the same, for branching a file and renaming a file are the same action as regards the NAME of the file; the difference is that when you branch a file, you continue creating new versions of both files (the file with the old name, and the file with the new name), whereas when you rename a file, that is the last version of the file with the old name, and all future versions of that file are versions of the file with the new name. And, of course, sometimes you rename a file and then you rename it back to its old name. Perforce can track any of those cases in its database equally well.

The point is that, in Perforce, the "primary key" for the object is its name. The name of the object is the primary way that Perforce refers to the objects, and it's the way it organizes the objects internally in its repository. (Try poking around in the server's filesystem for a while and you'll see what I mean.)

git takes a different approach, preferring to organize its database most naturally by creating a database of CONTENT. Quoting from Pro Git:

Git is a content-addressable filesystem. Great. What does that mean? It means that at the core of Git is a simple key-value data store. You can insert any kind of content into it, and it will give you back a key that you can use to retrieve the content again at any time.

...

You can see a file in the objects directory. This is how Git stores the content initially — as a single file per piece of content, named with the SHA-1 checksum of the content and its header.

...

The next type you’ll look at is the tree object, which solves the problem of storing the filename and also allows you to store a group of files together. Git stores content in a manner similar to a UNIX filesystem, but a bit simplified. All the content is stored as tree and blob objects, with trees corresponding to UNIX directory entries and blobs corresponding more or less to inodes or file contents. A single tree object contains one or more tree entries, each of which contains a SHA-1 pointer to a blob or subtree with its associated mode, type, and filename.

There's a fundamental duality here, which is at the heart of how both systems work. Objects have names, and objects have values, and sometimes you care about the name of the file, and sometimes you care about the content of the file.

Perforce tends to keep track of files by their name, which means that usually you start with the name of a file and then access its content, and occasionally Perforce has to go hunting through its database to find the other names of the file, such as when you are moving work from one branch to another and the file has been renamed in the one branch but not the other.

Git, on the other hand, tends to keep track of files by their content, which means that usually you start by knowing the SHA-1 of a file, which is how you access it, and if you want to know the name of the file Git will look that up for you. And if you want to rename a file, you don't have to tell Git that; it will just figure it out because it notices that the SHA-1 signature of the new object matches the SHA-1 signature of an object it already knows about.

This is part of the answer to some fundamental complaints about both systems. Since Perforce spends time maintaining a sophisticated database of file names, when you create a branch, that causes Perforce to create many new file names in its database (one new file name for each file in the branch, together with records which relate the old name to the new one), and thus in Perforce, "branches are expensive". For small branches, Perforce does this so fast that you never notice it, but for large branches you can detect the pause. (And if you add many thousands of branches with many millions of files in them, you may have to buy a bigger server.)

Meanwhile, since Git generally doesn't care about the name of the file, more about its content, creating a branch is very cheap, because Git just has a single operation to perform, no matter how many files are in the branch, so in Git, "branches are cheap."

But on the other hand, this mean that Git has to frequently figure out the SHA-1 of objects, so it spends a lot of time reading files and computing their SHA-1 signatures. For small files, Git does this so fast that you never notice it, but for large files the scanning and cryptography is significant, so in Git, "tracking large files is expensive."

Whereas in Perforce, since it only looks at the content once, when you submit the file, and then just tracks the file by its name, Perforce handles files of any size easily, and tracks gigantic files containing hundreds of gigabytes of content just as fast as it tracks tiny little Operator.java.

These sorts of dualities arise all the time in Computer Science, which, like any engineering field, is full of tradeoffs.

If you make one thing cheap to compute and fast to look up, you tend to have to make a tradeoff, such that other things are harder to compute and slower to look up.

You can't say that one decision is unambiguously "better"; you have to think about the tradeoffs, and why they were made, and what they mean about how to use the system effectively.

Or, you can just think about Professor Wirth, and whether you should call him by name, or call him by value.

Extreme sailing at the highest, highest level

Six months have passed since The Miracle on San Francisco Bay.

There's been the few odds and ends stories here and there, but nothing that really dove into the details.

Now, along comes Kimball Livingston, the best living writer of the world of sailing, with all you could ever want to know about what really happened:

• Burns and Speer: Secrets of the Comeback

  Oracle studied how to retrim to add more load to the back of the wing. “The boat had lee helm,” Speer said. “You know that kills upwind speed. It was clear that we needed to retrim, so we raked the wing aft—and no, that didn’t work. It turned out that when we powered-off the upper elements—when we added twist aloft—the center of effort shifted down and forward. There was no relief in that. So instead we opened the slot. That gave us less lift on the main element and more lift on the flap [which funnels air aft]. Over the course of the regatta we increased the traveler load by 50 percent. That eliminated lee helm, helped the boat point, and simply made us faster upwind.

• Secrets of the Comeback: Control Control Control

  The essence of a feedback control system is the system works on the difference between what you want and what actually exists. This difference in control engineering parlance is called the error signal. It can be anything, as long as there is this difference operation is going on. The difference can be electrical, as when an electronic sensor provides a measurement and the subtraction is done in the control computer. But you can also set it up so the difference is done mechanically. This is what OTUSA did.

Modern sports, at the highest level, have become extraordinarily sophisticated, and with that sophistication comes extraordinary complexity.

Your race car may catch a virus.

Your speed skating aerodynamic suit may not perform as expected

Your bobsleds may need to be adjusted to match the banking of the curves on the course.

It's always fun to get a peek behind the scenes to learn more about the underlying techniques that are used at the highest level of competition.

Now is art

Just look at it..

I love the way it depicts the mid-ocean gaps over the Atlantic (between Brazil and West Africa) and Pacific (between New Zealand and Africa) oceans.

And the colors are just right, and the shapes of the continents are beautiful, and even that snarky little "Rude to Call" seems to be just right.

I declare it to be art.