Sunday, September 30, 2012

He stands dead last in the standings, having lost 4 games and won only one.

According to what I've read, he had good positions in many of the games, but got into serious time trouble late in the games.

There's still a week to go, but this is almost certainly going to be a disappointing result for him.

Meanwhile, on the opposite side of the planet, the young Italian player Fabiano Caruana is having the tournament of his life. The Bilbao Masters tournament has an unusual format: the first half of the tournament is played in Sao Paolo, Brazil, while the second half of the tournament is played in Bilbao, Spain.

And the Facebook slides are fun, too; I love it when the bullet point listing the data store which is 'tens of petabytes' isn't even the largest one on the list...

Last week was the "2012 Storage Developer Conference". This show is an industry conference, not an academic conference, so it's quite a bit different. Still, it's fascinating to look through the program and the abstracts for the various talks. It's not clear if any of the presentation materials will eventually end up online; they don't seem to be freely available right now...

The vehicle has already been listening to data on traffic patterns and traffic light timings. It chooses the fastest route to the office with the fewest turns and stops, and gently accelerates on his way. Traffic capacity is good because 80% of the streets leading downtown have been rerouted as one-way into town, and all robocars that were parked along the side of the major streets moved themselves out of the way before rush hour.

With deliverbots, you will be able to get absolutely anything for sale in a big city about as fast as you can get a pizza today, and it will be cheap. Certainly cheaper than going to a store yourself. This changes the very nature of stores, especially big-box warehouse stores. You'll go to stores for the service, and to personally see and try on products before you buy, but the best prices and speed will always come from warehouses scattered around town ready to send you a deliverbot.

This is a car which people still drive, but which is permitted to move around streets while vacant, so that it can deliver itself to drivers, as well as park and refuel itself. I call it a whistlecar because it may remind you of the Lone Ranger's ability to just whistle and have his steed come to him to ride.

The general aviation (small plane) industry has a different history. For many years leading to the 80s, almost every single plane crash resulted in a lawsuit. And many of those lawsuits found something wrong with the plane, even if they only gave it 5% responsibility for the crash. Juries like to blame machines over people in lawsuits by the families of dead pilots. The deep pockets of the airplane companies, like Cessna and Piper, were a great target for lawsuits.

Over time, the insurance cost started to exceed the cost of the aircraft, or any reasonable profit. Cessna stopped making small aircraft in the 80s. Only after lobbying to get the liability rules tweaked (to limit the duration of liability so people could not sue over 20 year old planes) did things start up again, but at high prices and low volumes.

Even with ordinary cars, we are starting to see systems that track them. Parking patrols now record all the licence plates in parking spaces using video cameras. Downtown cores working on "congestion charging" also are implementing licence plate cameras on every street. Many toll both systems either photograph licence plates or record RFID transponders. In some cases, the RFID transponders used for toll booths are also recorded in other locations, officially for traffic flow measurement.

Vehicles will probably be programmed to not execute various "unsafe" actions, even if ordered to by their owner. In the real world, we bend the law constantly in areas of human discretion. Strict adherance to the law would not necessarily provide the desired result. Humans are constantly doing things that have real, but low probability of causing an accident, some of which have become part of normal traffic flow. Defensive driving is good, but paranoid driving can ruin traffic flow.

When a car on the inside needs to leave, it would just ask the robocars in the outer lane to move so that the gap moves next to the departing car. Since all the cars can move at once, in concert, this would take just a few seconds, especially for electric cars. If there are multiple blocking lanes, all those lanes would, at the same time, move their gap to be in the right place for the car that wants to leave. It doesn't matter how many lanes there are, this happens in the same amount of time -- a few seconds.

Small robocars, designed for just a few people, can be smaller and lighter than cars, and this means that roads and guideways for them can be much cheaper than full-use roads we build today. Astonishingly cheaper. Most residential blocks, for example, might be served by a single 10 foot wide lightly paved alley in the front or back. New construction might run such back alleys (as are common in some cities) with no roads at all.

There's lots more, and it seems like Templeton is continuing to add to these essays over time. He's also got a special RoboCars Blog for more topical notes.

I found the essays quite stimulating; it's neat to think about what may soon be happening, and Templeton's essays are a great way to get yourself into that frame of mind.

Warning in advance: this is a long and thoughtful essay; you aren't going to get through it in one sitting; you're going to need to read it, and think about it, and return to it later.

But if you have any interest at all in what computer programming is, in why it is so hard to learn, and so hard to teach, and in what we can do to best prepare our entire humanity for a future in which everything is programmable, and everyone is a programmer, you owe it to yourself to think about the things that Bret Victor is thinking about.

Victor's main observation is that too many people get hung up on the mechanics of programming, and don't understand that what they need to be concentrating on are the concepts of programming:

Two thoughts about learning:

Programming is a way of thinking, not a rote skill. Learning about "for" loops is not learning to program, any more than learning about pencils is learning to draw.

People understand what they can see. If a programmer cannot see what a program is doing, she can't understand it.

Thus, the goals of a programming system should be:

to support and encourage powerful ways of thinking

to enable programmers to see and understand the execution of their programs

Later in the essay, Victor deals with what I consider to be one of the hardest aspects of trying to teach people how to become programmers: learning abstraction:

The description still says "draw a rectangle here, then a triangle there", but the here and there have been abstracted. Different parameters give us different heres and different theres.

How does a programmer learn to write this abstract code? How does she learn to write a single description that is generalized for many cases?

She doesn't. The learner should start by writing concrete code, and then gradually change it to introduce abstraction. And the environment must provide the tools to perform this process, in such a way that the learner can understand the program at each stage.

Another extremely challenging part of teaching programming is to teach the ability to visualize what the computer is doing, and to identify with the actions that the program is instructing the computer to take:

That's Seymour Papert explaining the Logo turtle. The turtle serves a number of brilliant functions, but the most important is that the programmer can identify with it. To figure out how to make the turtle perform an action, the programmer can ask how she would perform that action herself, if she were the turtle.

For example, to figure out how to draw a circle, a learner will walk around in circles for a bit, and quickly derive a "circle procedure" of taking a step forward, turning a bit, taking a step forward, turning a bit. After teaching it to herself, the learner can then teach it to the computer. The turtle is the in-computer embodiment of the programmer herself, a "self", like the player-character in a video game, and thereby allows the learner to transfer her knowledge of her own body into knowledge of programming.

This is a wonderful article. By looking backward, and looking inward, Victor proposes how we can look forward, and how it is now fully within our grasp to build learning tools which can help us (all 7 billion of us, eventually), to achieve that next plateau of learning how to program, and how to program successfully.

Wednesday, September 26, 2012

It focuses on explaining how the Internet works, ranging from how bits are modulated on wires and in wireless to application-level protocols like BitTorrent and HTTP. It also explains the principles of how to design networks and network protocols. Students gain experience reading and understanding RFCs (Internet protocol specifications) as statements of what a system should do. The course grounds many of the concepts in current practice and recent developments, such as net neutrality and DNS security.

Much about the hantavirus remains a mystery. Sunlight kills it, and in a laboratory setting, it has remained viable for about 48 hours, Buttke said, although it may be able to live a few days beyond that. Experts believe an area must have an active mouse infestation for people to become infected.

According to ECDC‘s risk assessment, the risk of infection is low as only eight cases have been confirmed so far among American visitors and none among European visitors, although several thousand people have been in the area.

The chance of contracting Hantavirus in Yosemite National Park is extremely low, and doesn't appear to be any different from the chance of contracting the disease elsewhere in the rural western United States.

But the disease itself is mysterious and deadly, and worthy of continued study. My mother, who spent several decades living in the high desert of eastern California, recalls:

A couple of people at China Lake died from it shortly before we retired. Namely, a couple of old men, retired for many years, members of the writer's club that I joined for awhile. They bought some stuff from the Navy auction, and opened the sealed boxes and apparently inhaled virus-laden air from the box. Scary.

I'll keep my eyes open for updates on the research. In the meantime: go to Yosemite; enjoy the views; experience the wonders. It's too lovely a place to miss.

This statement, from an anonymous source no less, matters because it creates the sense in the article that the industry is operating in the shadows, trying to hide a problem that, “if only people knew” would create a huge issue. Nothing could be further from the truth. There are hundreds of conferences and gatherings a year, open to the public, where the people that run services get together to discuss these problems, solutions, and advances. Everyone I know talks about how to make things better, and, without divulging company secrets, exchanges information on how to solve issues that we face. There’s ACM and IEEE publications (to name just two organizations), papers, and conferences. The reason it appears hidden is that it’s just one of the many areas that only interest the people involved, primarily nerds. It’s arcane, perhaps, but not hidden.

Facebook engineers no longer forage for fans. They think about how to optimize undersea cable routes. They design brand-new ways of storing data with some of the power turned off. They even design their own servers. And Facebook is now sharing many of its designs with the rest of the world.

Think of it this way: Roads aren’t 100 percent utilized. The telephone system isn’t 100 percent utilized. They are there when they are needed. One might ask how much each paper edition of the New York Times is utilized? What percentage of articles delivered in the paper are read? Are all the articles not read waste?

And on and on and on.

I think it's great that the story was published, and I think it's great that it's generating all this discussion.

It's healthy; it's important; it's helpful.

When I look at the issue myself, I feel at least two primary reactions:

Some of the most important work in systems software right now is occurring in support of these data center applications: data management, parallel algorithms, virtualization, networking, security. Internet-scale Cloud Computing is driving all of these areas.

However, I am concerned about efficiency, and I am concerned about the environment, and I am concerned about waste and pollution.

I realize that I use services like Google, Amazon, and Facebook a lot, and I know that I often don't stop to think about using those services. I waste my use of those services. I am totally spoiled by their always-on availability, their near-instant response, and their exhaustive and complete coverage.

So, am I contributing to the problem? I fire off my requests to the Internet without a second thought, and they respond by provisioning massive capacity to serve the demands of millions of people like me.

I'm not an economist, but it seems like this is one of those cases where the "externalities" are not right: the people who are driving demand for these services (people like me) aren't the ones who are directly paying for the infrastructure, nor are we aware of the bloated consumption that we're triggering by our actions.

So, as I said earlier, I'm glad that the New York Times is raising these issues.

Just as they did last spring with their investigations into working conditions at the manufacturing facilities in China and elsewhere which support our Internet life, their investigations into the computing infrastructure which gives us our photo walls, our music streams, and our news feeds is valuable and important.

Sunday, September 23, 2012

It's now been nearly 6 years since Jim Gray was lost at sea. Gray was the pre-eminent practitioning computer scientist in my lifetime. I think what made him special was his ability to blend the theoretical and the practical. Like any great theorist, he was thinking years ahead of the rest of us; but as a great practitioner, he was interested in building production systems that worked, now. In his nearly four decades at IBM, Tandem, DEC, and Microsoft, he built teams and organizations that built industrial strength software that supported round-the-clock production use. He literally "wrote the book" on system software: Transaction Processing: Concepts and Techniques is the best book ever written on how database software actually works.

The Spanner paper is rich and fascinating; every page is full of intriguing information. There are probably half-a-dozen massive breakthroughs being reported on here, any one of which would have warranted a full paper of its own:

Snapshot isolation via globally-meaningful commit timestamps

TruTime's API for bounded clock uncertainty

Blending GPS and atomic clock time sources

Globally concurrent atomic schema updates

Two-phase commit over Paxos

SQL-like query language extensions for the Spanner data model

INTERLEAVE IN DDL for locality-aware sharding definitions

The list goes on and on; it's no exaggeration to suggest that I'll be reading and re-reading this paper all fall.

But what prompted this post, and the reason why I started by talking about Jim Gray, is less about the specifics of Spanner, and more about Dean and Ghemawat and, broadly, about the way that research and development in systems software is occurring nowadays.

Both authors present their views about the various "types" of research communities, and about how those communities tend to approach their work.

And there are differences; however, my feeling is that, within both the operating system and database communities, there are those who focus on theory, and there are those who focus on practice, and then there are those who are able to blend the two approaches. As Professor Regehr notes:

The best argument is a working system. The more code, and the more results, the better. Something that is clearly a toy isn’t convincing. It is not necessary to build an abstract model, conduct a user study, prove soundness, prove correctness, or show any kind of asymptotic bound. In fact, if you want to do these things it may be better to do them elsewhere.

The style of exposition is simple and direct; this follows from the previous point. I have seen cases where a paper from the OS community and a paper from the programming languages community are describing almost exactly the same thing (probably a static analyzer) but the former paper is super clear whereas the latter is incredibly difficult to figure out. To some extent I’m just revealing my own biases, but I also believe the direct approach to exposition is objectively better; I’ll try to return to this subject in a later post.

The key to a strong research result is finding the right abstraction. A good abstraction is beautiful; it imposes little performance penalty; it leads to reliable systems; it leaks the right information and blocks things you didn’t want to know. It just feels right. The abstraction is probably for something low-level, but this doesn’t need to be the case. Finding good abstractions may sound easy but it’s super hard, often requiring lots of code to be thrown away multiple times.

But I think this is true in all systems software areas. I acknowledge and concur with the (historical) distinctions noted by Professor Brewer: OS and DBMS: Philosophical Similarities & Differences, but I also agree with Brewer that a modern approach to work in systems software has to:

work from both of these directions, cull the lessons from each, and ask how to use these lessons today both within and OUTSIDE the context of these historically separate systems.

Which brings us back to Dean and Ghemawat, and to what they've done in the last fifteen years:

The Google File System

BigTable

Map/Reduce

Protocol Buffers

Continuous Profiling

The Swift Java Compiler

and now, Spanner

What are these? Well, they are

working systems

presented in a style that is simple and direct

concentrating on finding the right abstractions

Now, they've still got a ways to go to achieve what Jim Gray did, but I think you can make a reasonable argument that the most exciting, world-changing, intellectually-sophisticated yet pragmatically-realistic work in the systems software field is occurring in Google's research teams, and it's breath-taking to read through the "Future Work" section of the Spanner paper and consider what they are hoping to work on next.

Talk to you later; it's time to go re-read the Spanner paper again and chase some more references...

As Cory Doctorow observed, one of this year's most delightful awards is the Literature Award:

LITERATURE PRIZE: The US Government General Accountability Office, for issuing a report about reports about reports that recommends the preparation of a report about the report about reports about reports.

Saturday, September 22, 2012

The tournament features some of the world's strongest new players, such as Nakamura, Giri, and Wang Hao; some of the world's strongest established players, such as Grischuk, Leko, and Perez, and some of the world's elite old guard, such as Gelfand, Ivanchuk, and Topalov.

Before diving in further, this is a good place to give a shout-out to the folks who designed, developed and maintain ZooKeeper. I think it’s one of the most useful open-source contributions for distributed computing of the past decade. Most of the fault tolerance in Nebula can be reduced to simple patterns that make use of the ZooKeeper model (e.g., ephemeral, session-bound znodes), its serialized atomic updates, and the associated watch mechanism.

In the rest of this article we study a number of distributed activities like replication of failure detection that could happen in a database. These activities, highlighted in bold below, are grouped into three major sections:

Data Consistency. Historically, NoSQL paid a lot of attention to tradeoffs between consistency, fault-tolerance and performance to serve geographically distributed systems, low-latency or highly available applications. Fundamentally, these tradeoffs spin around data consistency, so this section is devoted data replication and data repair.

Data Placement. A database should accommodate itself to different data distributions, cluster topologies and hardware configurations. In this section we discuss how to distribute or rebalance data in such a way that failures are handled rapidly, persistence guarantees are maintained, queries are efficient, and system resource like RAM or disk space are used evenly throughout the cluster.

System Coordination. Coordination techniques like leader election are used in many databases to implements fault-tolerance and strong data consistency. However, even decentralized databases typically track their global state, detect failures and topology changes. This section describes several important techniques that are used to keep the system in a coherent state.

Discussion about the GitHub outage, and specifically about the issues surrounding declaring a node dead and deciding when to failover:

In this course, we describe the critical technology trends that are enabling cloud computing, the architecture and the design of existing deployments, the services and the applications they offer, and the challenges that needs to be addressed to help cloud computing to reach its full potential.

In distributed systems, there’s a subtle and somewhat underappreciated strategy for reducing tail latencies: doing redundant work. If you send the same request to multiple servers, (all else equal) you’re going to get an answer back faster than waiting for a single server. Waiting for, say, one of three servers to reply is often faster than waiting for one of one to reply.

Here's a nice Kirk McKusick article about the current state-of-the-art in filesystems as they evolve to adapt to the changing disk sector size (the underlying hardware is moving from 512 byte sectors to 4096 byte sectors):
Disks from the Perspective of a File System

File systems need to be aware of the change to the underlying media and ensure that they adapt by always writing in multiples of the larger sector size. Historically, file systems were organized to store files smaller than 512 bytes in a single sector. With the change in disk technology, most file systems have avoided the slowdown of 512-byte writes by making 4,096 bytes the smallest allocation size.

And this week's coffee-house debate over whether MongoDB is the greatest or the worst technology ever to be visited upon the earth:

Monday, September 17, 2012

A bunch of otherwise unrelated stuff, with the common thread(s) that: they're interesting stories, and they have to do with cryptography of various sorts.

Professor Ed Felten talks about the need for government-enforced security algorithms to be accountable: Accountable Algorithms

When we talk about making an algorithmic public process open, we mean two separate things. First, we want transparency: the public knows what the algorithm is. Second, we want the execution of the algorithm to be accountable: the public can check to make sure that the algorithm was executed correctly in a particular case. Transparency is addressed by traditional open government principles; but accountability is different.

you can verify that the TSA followed the algorithm correctly in deciding whether to search you. You can add the now-public R to the already-public Q, to get the day’s (previously) secret key K. You can then evaluate the selection function S(K,N) with your name N–replicating the computation that the TSA did in deciding whether to search you. If the result you get matches the result the TSA announced earlier, then you know that the TSA did their job correctly.

This document does not attempt to answer all questions about revocation, such as who can revoke and under what circumstances. It provides a mechanism for transparency: i.e. the ability to know, efficiently, that the list of revoked certificates you see is the same as the list everyone else sees, and that every revocation (or unrevocation) is available for scrutiny by any interested party.

Everything changes when we ask questions that talk about the interplay between addition and multiplication. The first-order theory is undecidable and incomplete. There are countless simple-to-state questions that mix the two structures—addition and multiplication—that are beyond our current abilities. A simple example of this is the Twin Prime Conjecture: Are there an infinite number of primes p so that p + 2 is also prime? Note how it mixes primality (which depends on multiplication) with addition.

This is also the reason that the ABC Conjecture is so deep. It mixes in a critical way the additive structure a + b = c with the multiplicative structure, the radical of abc. This mixture is at the core of why the question is so deep.

Decoding just gives us garbage but taking a closer look at it, the length of the data is divisible by 8, so its worth treating this as some kind of ciphertext. The next step is to alter the data and see if we can get the application to spit out some useful errors.

I’m excited to have be a part of a discussion with others who spoke at the first Blackhat: Bruce Schneier, Marcus Ranum, Jeff Moss, and Jennifer Granick. We’ve been asked to think about what the future holds, and to take lessons from the last 15 years.

The script, written by Phil Alden Robinson, Larry Lasker, and Walter Parkes, is a wonder of the modern screenwriting world. It survives by wit and not tricks. It’s a caper movie that transcends the genre. It’s a technology movie that still isn’t outdated even though it was released 20 years ago and features cradle modems.

And Professor Len Adleman reminisces about his role as the mathematics consultant for the movie: Sneakers

He told me that there would be a scene wherein a researcher would lecture on his mathematical work regarding a breakthrough in factoring - and hence in cryptography. Larry asked if I would prepare the slides and words for that scene. I liked Larry and his desire for verisimilitude, so I agreed. Larry offered money, but I countered with Robert Redford - I would do the scene if my wife Lori could meet Redford.

I spent a few more fruitless hours trying to find another solution on the web. There wasn’t one that didn’t require pretty significant technical know-how (such as installing a utility, running it to reveal all files on the iPhone, then deleting each file one by one, even if you weren’t sure what the file did). The only option that was relatively straightforward and seemed to work, according to many forums, was to restore the phone.

Which I did. And I lost all my apps save the ones that come preinstalled on the iPhone in the first place. And guess what? It didn’t fix the problem.

Interestingly, although both Batelle and Hanselman fill their rants with a number of instances of actually buggy software, for the most part what they are complaining about is two things:

It's hard to design a simple UI for feature-packed software, so you end up with powerful software that requires training, experience, and motivation to use efficiently

You need a four-hour class just to understand all the contortions Apple seems to be doing in its attempt to make its desktop interface work the way the iPhone does. You know, pinch and swipe and app stores and mission controls and magic corners and all that.

In the attempt to design a simple UI, products often hide unimportant details that turn out to be important details, and then you find yourself at a dead end.

The phone is pretty much useless now, because all of its storage is taken up. With what, you might ask? Well, it’s a mysterious yellow substance – found, in a masterstroke of intuitive design, in iTunes – called “other.”

My iPhone 4s has 3 gigs of "OTHER" taking up space, according to iTunes. No one has any idea what other is and all the suggestions are to reset it completely or "delete and re-add your mail accounts."

Programmers are always surrounded by complexity; we cannot avoid it. Our applications are complex because we are ambitious to use our computers in ever more sophisticated ways. Programming is complex because of the large number of conflicting objectives for each of our programming projects.

...

I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.

This stuff is very hard; which is, of course, why we become obsessed with it and spend our lives doing it :)

Thursday, September 13, 2012

In August of that year, the Nicaraguan postal service released a new set of Air Mail stamps, centered on a map of Nicaragua. The map also showed part of Honduras, north of the border, in the same shading as Nicaragua proper. Although the accepted border between both countries was also shown, the part of Honduras shaded as Nicaragua was labelled Territorio en Litigo (‘Territory in Dispute’).

Now, Danny O'Brien is a very smart guy, so I feel his pain when he writes:

I cannot even get a purchase on these explanations. This is mathematics, which mean that — to my mind at least — it is the study of the innate structure of correspondences themselves, which means I can’t even get a shape in my head.

I'm no mathematician either, but I share O'Brien's desire to understand, to follow along, to try to get smarter in my own small way.

Tuesday, September 11, 2012

Somewhere under this rubble (and a lot of poison ivy) is one of the old turbines. It’s quite an eerie site; you can just hear the roar of the American Falls in the distance, but hardly anyone ever comes so far down the trail. Tourist helicopters seem to like to swoop overhead, and it can sometimes give you the feeling that you’re trespassing (even though the trail itself was clearly marked).

It’s been some 52 years since the whole plant collapsed into the river, and the site is still as powerful to see as ever. The walls scale high and tourists mill around at the top. The thought of the entire plant crumbling to the ground is overwhelming.

And over on Geoff Manaugh's blog, you'll find this unbelievably wonderful essay: Caves of Nottingham

Nottingham, it appeared, is a city of nothing but doors and openings, holes, pores, and connections, complexly layered knots of space coiling beneath one building after another, sometimes cutting all the way down to the water table.

Incredibly, the day only continued to build in interest, reaching near-impossible urban sights, from catacombs in the local graveyard to a mind-bending sand mine that whirled and looped around like smoke rings beneath an otherwise quiet residential neighborhood.

and don't miss don't miss Nicola Twilley's write-up of the tour on her own blog
Beer Caves Redux

Nottingham’s cave-based maltings gave the city an important advantage in the ale brewing industry: they were fireproof, as opposed to the timber-framed malthouses found elsewhere in the British Isles; and, most importantly, they maintained a relatively consistent temperature, which meant that malting could go on all year round and wasn’t limited to the traditional October to May season.

The 3d maps of the Nottingham caves are gorgeous! I'm reminded of the drone devices in the recent movie Prometheus, and how they mapped the tunnels on the alien planet. Or, the maps made by these nifty robots.

Monday, September 10, 2012

It's hard to imagine three words which, while each quite appealing on their own, go together so nicely as these three.

We're in our 5th or 6th season of attending shows at Woodminster, and we've come to really enjoy it.

Partly, this is because we had nice luck this year: we liked all three shows, and the weather was favorable for all three of our visits.

Partly, we're just getting better at the whole experience: we know what to bring, and what not to bring, and when to arrive, and when to leave, and overall we are much better at relaxing and enjoying ourselves.

This weekend, after finding ourselves in the middle of a picnic-table-mixup, we ended up sharing our table with a group of four young dancers, who had come with their mothers partly to see all the wonderful dancing that is Cats, and partly because one mother's friend was playing Grizabella.

The girls were chatty and excited; I hope they enjoyed the show. Certainly, Grizabella sang Memoryextremely well!

Flash memory fills the gap between RAM and disks in terms of many metrics: acquisition cost, access latency, transfer bandwidth, spatial density, and power consumption. Thus, within a few years, flash memory will likely be used heavily in operating systems, file systems, and database systems. Research into appropriate system architectures is urgently needed.

Graefe's conclusion is that the equations need minor adjustment:

The 20-year-old five-minute rule for RAM and disk still holds, but for ever-larger disk pages. Moreover, it should be augmented by two new five-minute rules: one for small pages moving between RAM and flash memory and one for large pages moving between flash memory and traditional disks.

Moving on, the MIT Internet Traffic Analysis Study (MITAS) has been studying how the Internet protocols have been continuing to evolve. One of their papers, by Bauer, Clark, and Lehr, is a follow-up to Van Jacobson's famous work in the mid 1980's to combat Internet congestion: The Evolution of Internet Congestion. As regular readers of my blog know, I consider the TCP congestion control algorithm to be one of the most fascinating algorithms ever designed, and 25 years later it continues to reward careful study.

What is interesting is that over the history of the Internet the answers to how congestion should be managed have varied. The dominant answer in operation at any time has almost always had detractors and competitors – no universal consensus has ever existed. This is unsurprising given that (in some respects) this is a debate about what is "fair" and about what is economically efficient to deploy and operate.

I've enjoyed Moseley's paper, although I can see why his proposals are controversial. The core idea that he proposes is to marry Functional Programming with Relational Database Theory, two great tastes that generally aren't seen in the same sentence. Moseley's paper is easy to read and certainly worth your time. One note, though; most of the Internet links to the paper are now dead, as Moseley's primary home page appears to have vanished. So either go to Archive.org, or do your own Google searching for "Out of the tar pit Ben Moseley" to find it.

Jumping to a completely different sort of follow-up, there was news this week about Vitaly Borker, one of the Internet's most extreme personalities: Web Businessman Sentenced for Threats

Mr. Borker was the subject of a November 2010 article in The New York Times in which he claimed that frightening consumers was a way to generate Internet publicity about his business, which purportedly elevated his profile in Google searches, generating more traffic and revenue. His theory was that any kind of online chatter lifted DecorMyEyes in Google’s rankings.

A few days after the article was published, Google announced on its blog that the company was “horrified” by Mr. Borker’s strategy and in response had already tinkered with its algorithm so that “being bad is, and hopefully will always be, bad for business in Google’s search results.”

When we look closely at some of the “ground truths” of software engineering -
the “software crisis”, the 10x variability in performance, the cone of uncertainty,
even the famous “cost of change curve” - in many cases we find each of these
issues pop up, often in combination (so that for instance newer opinion pieces
citing very old papers are passed off as “recent research”).

Because the claims have some surface plausibility, and because many people use
them to support something they sincerely believe in - for instance the Agile styles
of planning or estimation - one often voices criticism of the claims at the risk of
being unpopular. People like their leprechauns.

In fact, you’re likely to encounter complete blindness to your skepticism. “Come
on,” people will say, “are you really trying to say that leprechauns live in, what,
Africa? Antarctica?” The leprechaun-belief is so well entrenched that your
opposition is taken as support for some other silly claim - your interlocutors
aren’t even able to recognize that you question the very terms upon which the
research is grounded.

The book is for sale at an unusual "pay what you want" price (I paid the suggested $10). I haven't read the entire book, but I'm quite enjoying the parts I've read so far.

Are you interested in software engineering, in how we educate our future engineers, and in how we can bring some real intellectual rigor to the software engineering profession? Give Bossavit's book a try; I don't think you'll regret it.

... I gave up membership in my adult soccer league, and stopped playing soccer regularly.

I really miss playing soccer, but I was no longer able to continue playing in that league. Most of the players were 15 years younger than me, I couldn't keep up, and I was worried about sustaining a serious injury.

I'm still trying to stay active and healthy, and I've still got a number of activities I can participate in, such as hiking, bike riding, lifting weights, etc.

The game was televised in the U.S. on the new beIN Sport network, available to only a small fraction of television households that receive certain tiers of DirecTV, the DISH Network and, in some cases, Comcast.

the U.S. television rights to Spain's La Liga have switched from GolTV to the new beIN Sport USA network, launched this week by the Al-Jazeera Sport Media Network and available in only about 8 million homes to viewers of DirecTV and DISH Network.

...

Imagina USA, a Miami-based company that is part of the Mediapro Group, is beIN Sports' production partner. The English network launched Aug. 3 in an online preview at www.beinsport.tv and beIN Sport announced Wednesday -- the official launch date -- it will be carried on DirecTV's sports tier in high and standard definition and beIN Sport en Espanol will be distributed on DirecTV Mas in standard definition. A day later, it said DISH Network will televise beIN Sport on its America's Top 250 and DISHLatino packages.

...

Qatar, where Al-Jazeera is based, is making a giant push in soccer. Qatar beat out the U.S. two years ago in bidding to host the 2022 World Cup, and the Qatar Investment Authority took control of Paris Saint-Germain and has spent about $200 million in transfer fees for players to strengthen its roster.

Wednesday, September 5, 2012

One of the books I read this summer was John Jeremiah Sullivan's Pulphead. It's another one of those books that is cheaper in its paperback edition than on the Kindle; I read the paperback edition.

Sullivan is (apparently) a free-lance writer for a number of magazines, and Pulphead is (apparently) one of those collections in which he took various pieces he'd written for various magazines, worked on them some more, and published them as this standalone volume.

Sullivan, to generalize, seems to be one of those people who gets started on something, then follows one strand to another, and before you know it he's dug far deeper into the subject than you can possibly imagine doing, and has uncovered things that are far more interesting than you might expect them to be.

For example, given an assignment by Oxford American magazine to simply fact-check a Greil Marcus article about Geeshie Wiley, Sullivan tracks down an eccentric second-hand music dealer named John Fahey, who lives halfway across the country, and interviews him in depths about the lyrical details of Wiley's "Last Kind Words Blues".

Then, nearly six years later, Sullivan comes across a most unusual anthology that Fahey helped produce, called Pre-War Revenants, and is astonished by it, calling it "the charting of a deeply informed aesthetic sensibility." After describing in detail the immense, painstaking work that Fahey and his team did to produce the anthology, Sullivan describes a particular song:

Dual banjos burst forth with a frenetic rag figure, and it seems you're on familiar if excitable ground. But somewhere between the third and fourth measure of the first bar, the second banjo pulls up, as if with a halt leg, and begins putting forward a drone on top of the first, which twangs away for a second as if it hadn't been warned about the immediate mood change. Then the instruments grind down together, the key swerves minor, and without your being able to pinpoint what happened or when, you find yourself in a totally different, darker sphere. The effect is the sonic equivalent of film getting jammed in an old projector, the stuck frame melting, colors bleeding. It all takes place in precisely five seconds. It is unaccountable.

Other articles, in their obsessive-yet-compelling over-the-top way, are equally fascinating. Sullivan tracks down an ancestor of his who was somewhat of an accomplished amateur natural scientist (he worked with Audobon), then discovers that his ancestor was given to inventing research out of whole cloth. Try though he might, Sullivan finds that it's nearly impossible to figure out what of the old work represents legitimate research, and what is fanciful fiction. In the course of his investigations, Sullivan takes up with a modern team of Native American scholars, who carry out their research in unnamed, unmarked, almost unknown caves scattered across the South, thus ending up searching for the heart of his ancestors while squirming through muddy clay in a dark, unknown cave.

Another article details a side-light, just a blip really, that occupied Sullivan on his travels through Mississippi as he returns from researching an article about the aftermath of Hurricane Katrina. Realizing he is nearly out of gas, Sullivan joins a lengthy gas line at one of the few open stations.

I could see how far we had to go and wondered if I had even enough gas to last the line.

As the line inches forward, it crosses an intersection and merges with another line for the same pump, stretching back down the cross street. Stuck halfway through the intersection, Sullivan tries to maneuver his car to avoid blocking an older woman:

It was no act of heroism on my part, but nor was it an act of sneakiness and cheating, which is what the wiry, drunken, super-pissed-off Mississippian who appeared at my window accused me of, in the most furious tones.

Have you ever been wrongly accused of trying to take unfair advantage, when actually you thought you were just trying to be helpful? It can be the most unsettling and baffling experience, leaving you un-tethered and confused about how people come to conclusions about each other.

In the end I rolled up my window and blasted the music, and he melted away. There was no option, for either of us. The gas got me to more gas. But I was thinking, the whole rest of the wait, this is how it would start, the real end of the world. The others in their cars, instead of just staring, would have climbed out and joined him. It would be nobody's fault.

Although Sullivan's work is fascinating and compelling, he seems to have a self-destructive streak that makes me wonder. The essays are all non-fiction, or at least that is how I took them. But, near the end, Sullivan spins a most unlikely tale, extreme and stretching the bounds of plausibility (and for Sullivan, that's saying a fair amount). At the end of the essay, Sullivan confesses that he made it all up. Or does he? Is he pulling our leg? Which parts of his writing are authentic, and which are not? In these days of Jonah Lehrer and James Frey, can the poor reader be blamed for being uncertain about whom to trust, and what is dependable?

When all is said and done, you should give Sullivan a try. You certainly won't find him boring, and I think he'll inspire you to look at the world differently, and go and do a little bit of investigation on your own.

Be skeptical; be cautious; be inclined to err on the side of doubt. But don't let those concerns keep you away from this enjoyable, entertaining, and memorable little book.

Tuesday, September 4, 2012

One of my distractions over the Labor Day weekend was the Playstation game Journey.

It's an interesting experience, quite mesmerizing, and it's easy to lose several hours when you're in it.

It's quite non-traditional, though, so don't expect to be doing something that you expected.

I got the Collector's Edition, because they threw in copies of Flow and Flower as part of the package.

Flow and Flower are even less traditional than Journey.

I'm looking forward to spending some more time with Journey, though hopefully I'll find some sort of resource that helps explain at least some of the messages that Journey is trying to send to me; otherwise I fear that almost all of it is going above my head.

I can report, however, that it definitely helps to have a 8-year-old grand-daughter to play the game with you!

in recent years, the affordability of airships as well as developments in high-definition cameras, high-powered sensors and other unmanned technologies have turned these oddball aircraft from curiosities of a bygone era to must-have items for today's military.

...

Pasternak's Montebello firm makes airships used for surveillance, advertising and transport. Lockheed Martin Corp. designs and builds airships for commercial use at its secretive Skunk Works facility in Palmdale. Northrop Grumman Corp. does design work for airships around the Southland but is building them in Florida.

The wonderful Oakland Urban Paths website catalogs walks around the Oakland hills, with pictures and maps galore, as well as lots of fun descriptions:

Then it was time for some serious stair climbing. While the stairs we’d climbed near the railroad trail were concrete, the stairs off Thornhill are mostly wood. In part because the hillside is steeper in places, and the wooden stairs can more easily match that.

It's one of a thousand different ways the management invisibly kept the club fires stoked, the energy level impossibly high. Like how, as we drank more and more and it got later and later, three o'clock and then four, they began emptying the outer reaches of the club—the pool deck, the Library—and pulled everyone in toward the dance floor. So that from our high-priced bottle-service real estate we still had the valuable sensation that we were at a place where the party, like the music (or the Ecstasy), would never, ever end, where more and more girls could be fed in from still more flights out of Kansas City and Sacramento and you could start to think that the you who has a job back in Pittsburgh or Irvine doesn't exist

I'm a journalism professor and science journalist, and though I've written for Wired once or twice (and I happen to know and like Wired's editor, Chris Anderson), I was a relatively neutral, outside party who could check Lehrer's blog for journalistic malfeasance. So Wired.com asked me to take a look.

The Kindle Post offers a short course in Hard-Boiled Detective Fiction, with suggestions for each sub-genre: Hard-boiled 101

They are usually American loners, much like the old gunslingers of the Wild West. They have a code of honor and justice that may not be strictly legal, but it is moral. They may be threatened or beaten, but they won’t give up a case or betray a client.

They are individuals who often face a corrupt political or criminal organization, but they prevail because they are true to themselves and their code.

Eichenwald's article takes Microsoft to task for several sins, most importantly insufficient risk-taking:

a lumbering Microsoft relied mostly on pumping out Old Faithfuls such as Windows, Office, and servers for its financial performance.

Amid a dynamic and ever changing marketplace, Microsoft—which declined to comment for this article—became a high-tech equivalent of a Detroit car-maker, bringing flashier models of the same old thing off of the assembly line even as its competitors upended the world.

It's not entirely unfair, although I think that Eichenwald, who is primarily a financial analyst and not a technology person, gives Microsoft far too little credit for its amazing defense of its Windows and Office franchises. In particular, Microsoft moves slowly for a reason: corporate customers are insanely demanding when it comes to backward compatibility and smooth upgrades. It is astoundingly hard to take software as complex and powerful as the Windows/Office package and evolve and enhance it year-to-year without abandoning or antagonizing your existing customer base.

My wife's company is a perfect example of this. When she joined them nearly a decade ago, they were still running Windows 98 desktops with an ancient Novell file server carrying the shared-office load. Over time, she has brought them along, first to Windows XP, then more recently to Windows 7, and from Office 97, through Office XP and Office 2003, and (soon) to Office 2010.

The amount of painstaking attention to detail, thorough regression testing, detailed documentation, and careful external testing that is required to deliver multi-decade upgrade paths such as these is greatly under-valued by most people outside of the tech industry, in my opinion. Very few companies pay this much attention to upgrade and compatibility, and Microsoft should get a lot more credit than they do for their successes here.

Eichenwald, however, with the benefit of hindsight, sees only the missed opportunities:

Indeed, executives said, Microsoft failed repeatedly to jump on emerging technologies because of the company’s fealty to Windows and Office. “Windows was the god—everything had to work with Windows,” said Stone. “Ideas about mobile computing with a user experience that was cleaner than with a P.C. were deemed unimportant by a few powerful people in that division, and they managed to kill the effort.”

However, Eichenwald isn't really interested in the product strategy debate, important though it may be. He's far more interested in the tough topic of how you organize a 100,000 employee company so that it is simultaneously efficient and entrepreneurial. In vivid prose, Eichenwald points to a dramatic period around the turn of the century, when the first Internet bubble popped and Bill Gates stepped down:

On December 30, 1999, the face from the computer application frowned. ... Even Microsoft, it turned out, was not immune to the dot-com crash.

Sixteen days later, Bill Gates handed off the C.E.O. reins to Ballmer. ...

A businessman with a background in deal-making, finance, and product marketing had replaced a software-and-technological genius.
...

The music had stopped. The Microsoft Millionaires were now working alongside the Microsoft Minions. One came to work bragging about his new Bentley; the other made do with a Dodge Neon. The days of shoulder-to-shoulder teams fighting to beat the world were over. A financial fissure tore at already strained relationships between the Old Guard and the new blood.

This situation isn't unique to Microsoft, of course. New employees joining Google, Facebook, Apple, or Amazon right now certainly aren't going to be showered with the riches that those who joined a decade ago were. I'm certain that anyone who took the time could easily find just as many sour-grapes tales at these companies right now, as Eichenwald relates from his chats with (mostly former) Microsoft employees.

Of course everybody at the company is happier when everyone is getting rich, but there's no story there. So, to his credit, Eichenwald works to try to unearth some wisdom about what a company faced by such a situation does do to preserve employee motivation as growth necessarily slows.

Eichenwald notes that one thing that occurs as a company grows and ages involves the emergence of a bureaucracy:

Where once creating innovations was both the thrill of the job and the path to riches through stock options, guaranteed financial success could now be achieved only the way it was at stodgy old General Motors or IBM—through promotions.

It's not clear that there's anything unique to Microsoft in this part of the story, but as Eichenwald tells it, it's certainly an unpleasant transition for the company to undergo:

By 2002 the by-product of bureaucracy—brutal corporate politics—had reared its head at Microsoft. And, current and former executives said, each year the intensity and destructiveness of the game playing grew worse as employees struggled to beat out their co-workers for promotions, bonuses, or just survival.

And here's where he turns to ranking.

At the center of the cultural problems was a management system called “stack ranking.” Every current and former Microsoft employee I interviewed—every one—cited stack ranking as the most destructive process inside of Microsoft, something that drove out untold numbers of employees. The system—also referred to as “the performance model,” “the bell curve,” or just “the employee review”—has, with certain variations over the years, worked like this: every unit was forced to declare a certain percentage of employees as top performers, then good performers, then average, then below average, then poor.

Again, it's not clear to me that Microsoft's usage of employee ranking was new, different, or unusual; the process as described by Eichenwald seems to match the process that, for example, Computer Associates used back in the early 1990's. We used to call this the "Harvard Business Review effect": some issue of the HBR features an article on some new management practice; the nation's MBA-educated management professionals all read the same article; and six months later every company is trying the same management technique.

I don't know what seminal article initiated the "stack ranking" trend, but nowadays it's everywhere. My friends at various large tech companies tell me that there isn't a major high-tech company out there that doesn't do this, in one form or another.

So, is Microsoft's implementation particularly brutish or demotivational? Here's what Eichenwald has to say about it:

Employees in certain divisions were given what were known as M.B.O.’s—management business objectives—which were essentially the expectations for what they would accomplish in a particular year. But even achieving every M.B.O. was no guarantee of receiving a high ranking, since some other employee could exceed the assigned performance. As a result, Microsoft employees not only tried to do a good job but also worked hard to make sure their colleagues did not.

It's certainly true that the objectives game is a poor one. In my experience, a year is nearly an eternity in the high-tech industry, which creates, immediately, a terrible problem for a system like this. Since no high-tech company can possibly plan in detail for a full year in advance, companies only put the vaguest and highest-level goals into their corporate yearly plans. Individual managers, then, have no ability to set reasonable goals for their employees for an entire year. Setting goals for the next three months is possible, but for a year? Fuh-gedda-bout-it!

So, what do those managers do? Well, in my experience, they set out cautiously-worded, generic, nebulous goals such as: "respond to important issues raised during the year", or "address problems exposed by external testing during product launch".

Then, when the year ends, lo-and-behold everyone has achieved their goals!

So the goals become useless for actually evaluating the relative performance of the employees, and the reality of the yearly review becomes as described by Eichenwald:

There was some room for bending the numbers a bit. Each team would be within a larger Microsoft group. The supervisors of the teams could have slightly more of their employees in the higher ranks so long as the full group met the required percentages. So, every six months, all of the supervisors in a single group met for a few days of horse trading.

Ugh. I've seen these scenes. They're a mess, no question.

Eichenwald doesn't offer any solutions to these problems, and I haven't seen much from other commenters, either.

I'm not sure there are any easy solutions. The key is in understanding what motivates an engineer. Money is surely one such thing, but others are harder to reduce to numbers and rankings: working with other great engineers; solving problems that haven't been solved before; having the opportunity to reach a wide audience; building something that will stand the test of time.

Basically, if you're looking to your ranking/review process to motivate your employees, you've already lost the battle, and you've become one of those gigantic boring high-tech companies which exciting engineers flee. Instead, go read Michael Lopp's essays on software industry management and try to understand how software engineering really works.

In the end, I'm pleased that "the mainstream media" are devoting more attention to high tech companies such as Microsoft, but until they spend less time thinking of these companies in simple financial MBA terms, worthy only of being compared to "Detroit car-makers", and more time thinking of these companies as peopled by unique individuals such as described by Lopp, it's hard to see what insights even a great writer such as Eichenwald is going to be able to bring.

But go read the Vanity Fair article yourself; it's entertaining and enjoyable, and if you knew nothing about Microsoft or about the software industry before, you'll surely learn quite a bit.