Bram Cohen

Somebody at Mozilla decided they need lots of 'true' random numbers.

My patience for this subject completely ran out about five years ago, so this post is going to show a complete lack of diplomacy. I would like to emphasize, in advance, that this is my honest, reasoned opinion, not said in anger, and that if you ask my opinion again in the future I'll say the exact same thing.

Once a computer has collected a small number of 'true' random bits (maybe it's 128, maybe it's 256, but regardless it's small) there's no need whatsoever for it to block on collecting more 'random' numbers. A pseudorandom number generator based on AES will be able to generate random numbers based on that seed until the end of the universe and noone constrained by the laws of physics and math will ever be able to tell the difference between that and 'true' random numbers. This is extremely well established cryptography. To require 'true' random numbers is, to use an apt analogy, wankery. It does not, and cannot, do anything to improve security, and it mostly just causes huge amounts of pain. It is (and I repeat myself, because I have a hunch people will think I'm glossing over some nuance here) of no benefit whatsoever.

My advice to the Mozilla foundation (and again, this is my reasoned opinion, not said in anger, and I won't be changing my mind later): find out who was responsible for this policy of requiring lots of 'true' random numbers, and fire them. Fire them today. They have demonstrated gross incompetence, a total lack of understanding of the very most basic concepts in security.

Some people might think that if I knew more about who was behind this and what their specific motivations are, then that might change my mind. That is incorrect. The security field is filled with people who to non-experts seem very impressive and knowledgeable, especially when they're advocating, and even moreso demanding, very painful and difficult things in the name of security. Most of these people are frauds. I have had it with paying homage to the concept of impartiality when discussing these peoples's opinions. If someone spouts a bunch of technical mumbo-jumbo to bring the conversation to a place which a lay person has trouble understanding, then they may be able to make the argument be based on pure rhetoric, but gross incompetence is still gross incompetence, and despite having found an effective way to bullshit their way through, they're still wrong.

City of Heroes has had some interesting issues with its gameplay, involving a character named Twixt using some tactics which made everybody hate him.

Several years ago I happened to be seated next to the designer of City of Heroes at an event where he won something. He was a pudgy guy, wearing big round glasses, with a white city of heroes t-shirt and a blue cape on. We got into a conversation about his game, and I asked what it was that made it compelling, and he said that it's every kid's fantasy of being a superhero, and it was very obvious that he'd based the game's design on his own. I asked him if City of Heroes is compelling as a pure abstract game, and the interesting response was that he didn't understand the question. After a few minutes of conversation he got what I was asking, and his answer, which really perplexed me at the time, was that it was a good question, but he didn't know.

Consider a game with the following semantics: You sit, unmoving, for two hours, with no user feedback, no buttons to push, nothing, completely passive, while the game plays out in front of you, exactly the same way as it would for anybody else. This sounds like a terrible game, but it's exactly what movies are, and movies are very popular and get little criticism that they're terrible games.

The Twixt problem was caused not so much by any one person behaving unreasonably as the game engine having a problem. There's a battle tactic which is quite effective but has the effect of wiping out an enemy without even giving them a chance to play, making it not much fun for them and it doesn't even get much credit for you. Because City of Heroes is more fantasy than game, players have a convention of not using this tactic, because that maximizes the fun of play. This is done at the expense of an individual's success taking the game as a sport, but since the game isn't a sport, people don't worry about that too much. Real sports don't involve dressing up as superheroes (except for figure skating, but that isn't a real sport). What really should be done is that the rules should be modified so that the particular tactic isn't so nasty. It's a general rule of game design that all players should get a chance to play and have fun, even if they aren't very good, and tactics which allow a better player to win without the weaker player even having a chance to try to retaliate are no fun.

A random person asks about something they read on Wikipedia:
So why does BitTorrent perform so well? Quite simply, because it does a better job of finding more places to do uploading. Any peer which is downloading is in general willing to upload as well, and their uplink is usually unutilized, so if you can get a peer to start uploading as soon as it starts downloading, and keep uploading as long as possible, and saturate its link while it's uploading, then overall performance will be better. It doesn't necessarily help to transfer over more connections, or make more different things available at the same time, or use error correcting codes. In fact, all of those are a complex tradeoff between benefits and costs, with the net result being that small amounts of them can help reliability and robustness, but in general it's good to keep things simple and be polite to the network.

On the internet, the formula is bytes downloaded = bytes uploaded. It's that simple.

From deep in the uncanny valley of the Rubik's Cube, it's the Uncanny Cube. At first blush this appears to be a slight variant, but it is quite profoundly and perversely different.

This is Bram's Cube, an idea I'm very fond of. It's very interesting to solve, since the middle layer and everything else can be thought of independently and solved on their own, but that scrambles the part you weren't thinking of.

Bram's Black Hole is a concept which occurred to me a few minutes after the first time I ever played with a puzzle similar to Peter's Black Hole.


Fairly Twisted is a twisty puzzle with no symmetry.

It turns out that when cadding a puzzle ring, some issues turn up. Specifically, when a band goes over one band then immediately under another, it frequently doesn't have enough space to squeeze through between them.

I've come up with some techniques for dealing with this, and drew the following diagrams, which I think are kind of pretty, and I'm proud of my diagramming technique involved :-)

         ___
_______ /   \ _______
       \     \
      / \   / \
___   |  |  |  |  ___
   \ /   \ /   \ /
    \     /     \
___/ \   / \   / \___
      |  |  |  |  
      \ /   \ /
_______\     \_______
        \___/ 


         ___   __________
_______ /   \ /          ___________
       \     /          / \
      / \   / \    __   |  \
___   |  |  |  |  /  \ /    | ______
   \ /   \ /   \ /    /     \
    /     /     \    / \   / \
___/ \   / \   / \   |  |  |  |  ___
      |  |  |  |  \ /   \ /   \ /
      \ /   \ /    \     /     \
______ \     \    / \   / \   / \___
        |   / \__/   |  |  |  |
        \   |        \ /   \ /
___________/          \     \_______
          \__________/ \___/


              __   ___   __
       ___   /  \ /   \ /  \   ___
_____ /   \ /    \     /    \ /   \ ________
     \     \    / \   / \    /     /
    / \   / \   |  |  |  |  / \   / \   
___/   \ /   \ /   \ /   \ /   \ /   \ _____
        \     \     \     /     /     /
       / \   / \   / \   / \   / \   / \
____   |  |  |  |  |  |  |  |  |  |  |  L___
    \ /   \ /   \ /   \ /   \ /   \ /
     /     /     /     \     \     \
____/ \   / \   / \   / \   / \   / \   ____
       |  |  |  |  |  |  |  |  |  |  |  |
       \ /   \ /   \ /   \ /   \ /   \ /
___     /     /     /     \     \     \_____
   \   / \   / \   / \   / \   / \   /
    \ /   \ /   |  |  |  |  \ /   \ /
_____/     /    \ /   \ /    \     \________
      \___/ \    /     \    / \___/
             \__/ \___/ \__/

There are a number of different projects going on to harness wind power using kites. Most of them are utter lunacy, involving so many gizmos and unproven techniques that you might as well be trying to get power from lightning. That said, I have an approach which I think is plausible, but before even idly thinking about working on it I'd like to know if the whole concept of kite-based power even works on paper. Gathering the necessary information and running the numbers is a bit beyond my off the top of the head skills, so I'd greatly appreciated it if anyone would help me calculate the following:

For several points of interest on earth (particularly plausible/notable/typical places) calculate the following for both ground level and an altitude of half a kilometer:

What is the minimum, average, and max wind velocity? For the average wind velocity what would be the pull of a kite with an area of a hundred square meters? What would be the weight of the kevlar necessary to hold down something producing that much force at the maximum wind velocity? After factoring in holding up all that kevlar, could a kite stay up at minimum wind speed? How much power could be generated by its remaining upwards force? How much of that would be lost in the electrical generator? How does that amount of power output compare to the per capita max and average power consumption in the United States?

My suspicion is that flying kites at an altitude of more than a few hundred meters is simply not worth it, and that the optimal kite size in practice is around a thousand square meters, and that in an area where the wind never dies down a kite system compares quite favorably to a turbine system, once you get all the engineering problems worked out.

Also, I have a dumb question about controls - At what altitude do the sorts of control systems used for power kites simply stop working due to even very tensioned materials having a lot of slop at that length?

I've used this pattern a lot over the last few days:

for eggs in spam:
    for jello in eggs:
        if jello is the one I want:
            break
    else:
        continue
    break
else:
    return
do stuff with eggs and jello

People familiar with my code will find this amount of complex control flow unsurprising. But the reasoning here is different from my past practices. In the past I always optimized to have as few lines of code as possible, regardless of how upside down and backwards it made everything be organized, but that could be done much better in this case like so:

for eggs in spam:
    for jello in eggs:
        if jello is the one I want:
            do stuff with eggs and jello
            return

There are two reasons I find this construct objectionable. First is that it leads to a lot of code having a lot of indentation (the 'do stuff' is in many cases dozens of lines) which isn't good for readability. Second is that the natural flow of the code is 'scan for the thing I want, and then do something with it' which is the flow of the structure I've been using. I suppose one could write it like this:

def my_little_func():
    for eggs in spam:
        for jello in eggs:
            if jello is the one I want:
                return eggs, jello
    return None, None

eggs, jello = my_little_func()
if eggs is None:
    return
do stuff with eggs and jello

But that's hardly elegant and forces the flow to jump around in terms of the visual layout of the code, which goes against what I'm trying to accomplish.

At the risk of starting a religious war, I'd like to point out that the most readable and versatile way of doing what I want is like so:

for eggs in spam:
    for jello in eggs:
        if jello is the one I want:
            goto x
return
x: do stuff with eggs and jello

But short of that the following may be the best option currently available. I might switch to it:

for eggs in spam:
    for jello in eggs:
        if jello is the one I want:
            after_func(eggs, jello)
            return

def after_func(eggs, jello):
    do stuff with eggs and jello

But it still doesn't look as nice as the version with a goto.

This is the Geary Cube puzzle, another Bram and Oskar collaboration. It's externally identical to a Rubik's Cube, but has internal gearing which forces opposite faces to turn in opposite directions simultaneously. It's my favorite subgroup of the Rubik's Cube (you can try it yourself with a regular Rubik's Cube) and easily makes a bunch of pretty patterns. It's overall easier than a regular Rubik's Cube is, but the solution technique is very different and interesting and not related to the standard ways one solves twisty puzzles.

Live streaming of CodeCon 2009 is now up. It's linked from the CodeCon 2009 front page.

CodeCon 2009 starts tomorrow. We're just finishing up getting ready, and it's going to be great. See everybody there!

I've signed up for a twitter account, and have been posting there a lot more than here. I also linked my Facebook and Twitter accounts, and started using bit.ly. The facebook reposts get a lot more comments, because I have more friends there, and oh yeah, Twitter doesn't have comments yet. Please fix.

In the future, I'll post headline links to all my blog posts on the twitter stream for all my regular blog posts, and continue to post here for thoughts which require more than one sentence to convey.

Science fiction authors have dreams of the world's last days, and our distant descendants watching the sun flame out about four billion years from now. They're living in fantasy land. There's no way we're going to last even close to that long.

You see, the sun is getting hotter as it approaches flameout, and the earth is slowing down in its spin on its axis as tidal forces drag it down. As the earth's spin slows down, the cycle between day and night will become longer. A mere billion years from now the earth will stop spinning completely, and the light side will turn into smolding embers while the dark side will become a truly frozen wasteland. Long before that the day/night cycle will become so long that peak daytime temperature will surpass the boiling point of water, causing moisture to get into the upper atmosphere and get blown away by the solar wind, depleting the oceans while cooking all the water-based life forms during the day.

There is only one way to avoid this. We must force the earth's temperature down until the oceans freeze, thus stopping tidal forces and allowing the earth to continue with its current length of day/night cycle indefinitely and allowing us to live an extended, if slightly chilly, existence. Anyone opposed to this plan is engaged in strictly short term thinking.

Remember that today's the last day to get the early bird discount to Codecon 2009, so if you haven't signed up yet, do it now.

This is the Rotacubes puzzle, a collaboration between me and Oskar van Deventer. Nobody could make out how this one worked from pictures/text descriptions, so here's a video.

The Program to CodeCon 2009 is now up, and registration is at the early rate of $75 for all three days until April 1st, after which the cost goes up.

An explanation of CodeCon, from the site:

CodeCon is a conference of working demonstrations. Three days of quick presentations of actual working code, shown by people who wrote them, all for under $100. Past highlights include early presentations of BitTorrent, PGP, and SiteAdvisor.

Presentations this year include:

BioHack! Track:

• DIY Synthetic Biology - From Design to Construction with New Model Organisms
  
• Homebrew Genetic Testing - Read your own source code - at home!
  
• Keiki Gels - Visualize DNA -- in a drinking straw!
  

Code Track:

• BitTorrent DNA - Effortless BitTorrent deployment
  
• Distributed Transaction Layer for Google App Engine - Transaction semantics across multiple entity groups for applications written in the Google App Engine
  
• Helios Voting - The first and only web-based voting system that enables voters to verify their vote and the overall tally with cryptographic certainty.
  
• Libevent - making fast asynchronous network programs portable
  
• Pork - Largescale Automatic Rewriting of C++
  
• OneSwarm - privacy preserving peer-to-peer data sharing
  
• Parallel Web Browser - a web browser for handhelds & multicore laptops
  
• Switzerland - a semi-P2P system for detecting forged and modified IP packets between clients
  
• Tahoe, the Least-Authority Filesystem - a secure, decentralized, fault-tolerant storage network
  
• TorFlow - A Python-based Tor Research Toolset
  
• Trend Profiler / trend-prof - Finding performance surprises (super-linearities) in C / C++ code based on trends in the runs on different size inputs.
  
• Typhon / Scream
  

To learn more about CodeCon, you can look at the sites from previous years:

2006
2005
2004
2003
2002

Digg this!

I wrote up an explanation of when patience diff gives significantly different results, and why they're important.

The trickiest case for line based merging is when the number of blank lines between two functions changes. Were the new lines inserted at the beginning or the end? If two different people add a single line, should that clean merge? What if one person adds one blank line and another person adds two? Should that be a conflict of one blank line on one side and two on another, or a conflict of no lines on one side and a blank line on the other with a single line added, or no conflict and merge to the original length plus two, or no conflict and merge to the original length plus three? How about if a function was added in the middle of a section of blank lines and the number of blank lines after it was changed - should the new lines be at the end of the new function or the beginning of the old one? What if lines were removed, where should they have been removed from?

There aren't clear answers to these questions. Any answer you come up with will involve some tradeoffs, and it's a judgement call what behavior really is best. The one clear lesson is that you shouldn't change the number of blank lines between functions willy-nilly, because it will confuse the version control system.

A difficult distributed merge scenario which hasn't been written up anywhere is one I like to call the circular staircase. Three different branches are all made off of trunk, and all make changes to the same section of code. Think of the branches as all sitting around a circular table. Each branch then simultaneously pulls the most recent version of the branch to their right, and resolves the conflict in favor of their version. This situation is weird because any two of the three branches will now do a clean merge together, but pulling in the third one should cause a conflict. I won't give the full explanation as to why that is here, because my point is that the scenario is completely counterintuitive and inscrutable. As soon as the relationship between branches ceases to be a tree, it becomes impossible for users to understand what's going on. The lesson is that you should have clear relationships between your branches, and not do anything goofy. At this point I'm in favor of the version control system not allowing you to do goofy things, and keep track of the coherent relationships between branches which you do have. I have more ideas than were given in my last post on this subject, but more on that at a later time.

Another interesting case is the following:

     a
    / \
   b   c
  / \ /
 c   b
  \ /
   ?

If we want to support cherry-picking, we have a problem here. On the one hand, the change to c has already been applied to and rejected from on the right hand side. On the other hand, the change to c on the left happened 'after' the change on the right, so by the staircase criterion the new value should be c.

I think that if you want to support implicit cherry-picking you need to suck it up and accept that this scenario creates the weird action at a distance of merging to b. I don't really want to argue it all that much though, because the horse has already been beaten to death, and basically nobody in the real world is asking for implicit cherry-picking, because nobody has proposed a good UI for it, and nobody other than a handful of experts understands how it behaves, and because it directly conflicts with implicit undo.

When I last posted about this several people guessed that it's easy. It's not, it's quite difficult, and the logic behind the solution is very interesting. It also has no planar equivalent. 

Here's me explaining unix time. A thought on appearing on TV - if somebody puts a video camera on you, it's best to babble on about all your thoughts on a matter without concern for time, because they're going to edit it down later.

The deadline for CodeCon submissions is coming up this sunday! If you've got a cool project with actual working code, you should submit. CodeCon is designed to only require a few minutes to put together a submission if you've got something to show, and the amount of time to present is short enough that all you need to do is cover your project to fill it. Get your submissions in!

Believe it or not, you can't believe everything you read on wikipedia.

I currently live in the San Francisco area.

I have three children.

I've never heard of badger and badger.

Also, the article about my asperger's said that I was in college for one year. I was actually there for two years, but flunked most of my classes my last term (I knew I was leaving and never wanted to come back, so didn't see much point in doing any schoolwork).

Earlier this week (I think it was on Monday) I was riding the ferry to work, and saw a sea snake in the water. It was a couple feet long (my guess would be about four, but it was at a distance so that could be way off) and black. A minute or so later I saw another one, and then got the amazing site of a cluster of what I'm guessing was over a hundred of them. They were arranged into approximately parallel groupings in regions, with an overall effect of looking like a line drawing of an octopus.

I hadn't seen a sea snake in the water here before, so didn't think much of it, but then I looked it up online and it turns out hardly anyone else has seen them up here either! There's a species of sea snake native to California, but they live way down south, and aren't even all that common down there. Sitings up here are extremely rare.

Unfortunately I didn't take a picture. Were I used to using my phone camera and had any idea how unusual it was to see that I'd definitely have taken some footage.

For everybody who's been wondering and long anticipating when the next CodeCon is going to happen, here's the announcement:

CodeCon 2009
April 17-19, 2009
San Francisco CA, USA
www.codecon.org

Call For Presentations

CodeCon is the premier showcase of cutting edge software development. It
is an excellent opportunity for programmers to demonstrate their work and
keep abreast of what's going on in their community.

All presentations must include working demonstrations, ideally accompanied
by source code. Presentations must be done by one of the active developers
of the code in question. We emphasize that demonstrations be of *working*
code.

We hereby solicit papers and demonstrations.

    * Papers and proposals due: February 15, 2009
    * All Authors notified: March 1, 2009

Possible topics include, but are by no means restricted to:

    * community-based web sites - forums, weblogs, personals
    * development tools - languages, debuggers, version control
    * file sharing systems - swarming distribution, distributed search
    * security products - mail encryption, intrusion detection, firewalls
    * malware analysis - detection, compensation, and mitigation of
      emerging threats

--

As a new feature this year, CodeCon will be presenting a Biohack! track.
While we will continue our tradition of presenting only one talk at a
time, a portion of one of the days' talks will be reserved for interesting
biotechnology hacking projects. A key requirement for these presentations
is ease of reproduction with minimal access to expensive laboratory
equipment.

Example topics include:

    * Purifying DNA using common household items
    * Developing genetically-modified bacteria in a kitchen laboratory
    * Using specially-designed software to assist in bioengineering
    * The use of simple bioengineering techniques to solve real-world
      problems.

Ideal Biohack! Track submissions will have a strong emphasis on the
"hack" portion of the talk -- in the last few years, there has been a
strong growth in the community of biology hackers; we aim to bring these
hackers together to discuss their techniques for inexpensive, at home
experimentation in biological engineering research.

--

Presentations will be 30 minutes long, with an additional 15 minutes
allocated for Q&A. Overruns will be truncated.

Submission details:

Submissions are being accepted immediately. Acceptance dates are
February 7th and March 1st. After the first acceptance date, submissions
will be either accepted, rejected, or deferred to the second acceptance
date.

The conference language is English.

The conference venue is open to all ages.

Ideally, technical demonstrations should be usable by attendees with
802.11b connected devices either via a web interface, or locally on
Windows, UNIX-like, or MacOS platforms. Cross-platform applications are
most desirable. Biohacking demonstrations should be viewable with a
presenter-provided camera, or prepared movies for projection.


To submit, send mail to submissions-2009@codecon.org including the
following information:

    * Project name
    * Code track or Biohack! track
    * url of project home page
    * tagline - one sentence or less summing up what the project does
    * names of presenter(s) and urls of their home pages, if they have any
    * one-paragraph bios of presenters, optional, under 100 words each
    * project history, under 150 words
    * what makes the project novel -- how it differs from similar projects
    * what will be done in the project demo, under 200 words
    * slides to be shown during the presentation, if applicable
    * future plans

General Chairs: Jonathan Moore and Bram Cohen
Program Chair: Jered Floyd and Len Sassaman

Program Committee:

    * Jon Callas, PGP, USA
    * Bram Cohen, BitTorrent, USA
    * Roger Dingledine, The Tor Project, USA
    * Jered Floyd, Permabit, USA
    * Ben Laurie, Google, UK
    * Nick Mathewson, The Tor Project, USA
    * David Molnar, University of California, Berkeley, USA
    * Jonathan Moore, Mosuki, USA
    * Meredith L. Patterson, Osogato, USA
    * Andrew S. Peek, Integrated DNA Technologies, USA
    * Len Sassaman, Katholieke Universiteit Leuven, BE
    * Cliff Skolnick
    * Paul Syverson, Naval Research Laboratory, USA
    * [Others may be added]

Sponsorship:

If your organization is interested in sponsoring CodeCon, we would love to
hear from you. In particular, we are looking for sponsors for social meals
and parties on any of the three days of the conference, as well as
sponsors of the conference as a whole and donors of door prizes. If you
might be interested in sponsoring any of these aspects, please contact the
conference organizers at codecon2009@codecon.org

Press policy:

CodeCon provides a limited number of passes to qualifying press.
Complimentary press passes will be evaluated on request. Everyone is
welcome to pay the low registration fee to attend without an official
press credential.

Questions:

If you have questions about CodeCon, or would like to contact the
organizers, please mail codecon2009@codecon.org. Please note this address
is only for questions and administrative requests, and not for workshop
presentation submissions.

Years ago, I lived in a place with a cheap refrigerator which had a seal which broke. This place also had an ant problem. Somehow, one of the ants signalled to the rest of them that there was food in the fridge, and there proceeded to be a long line of ants which marched into the freezer, froze, and never came back out again (gross, I know, but I have a real point here).

I suspect this was caused by an accidental hacking of the ants's signalling mechanisms, caused by freezers not existing in the ants's natural environment. Normally when an ant gets harmed it releases order telling other ants to stay away, but when an ant gets frozen it doesn't get a chance to indicate that it's harmed (actually, it might not be - we didn't try unfreezing the ants to see if they still worked).

My thought is that one could use this effect intentionally. If there was a custom-built freezer with a  line of ant pheremone leading into its entrance, it could immediately attract the local ant colony, then lead them all into a black hole until the colony was depleted of resources and died.

Anybody know if this has been tried before? For that matter, anybody know what the mass of all the ants in the local ant colony is likely to be? I can pretend to know the typical size of an beehive, but not an ant colony.

The Stirling engine cycle appears, to my eye, to have thermodynamic losses happening all over the place. Compressing a chamber which is being heated, expanding one which is cooling, transferring between chambers in a haphazard manner when both are having their temperature moderated, that sort of thing.

Here is my idea for a much cleaner (or at least much easier to understand) cycle which may be an improvement.

There are four piston chambers A, B, C, and D. Gas flows in the direction A->B->C->D->A, and the corresponding chambers which gas flows between have connections with valves controlling whether gas can flow though each of them. The pistons are opposing, so A and C expand while B and D contract, and vice versa. There's a heat source continuously warming up A, and a sink continuously cooling down C. All pistons are the same length, but A and C have the same diameter while B has a larger one and D has a smaller one.

The cycle is in four phases. They're all done by a single reciprocating piston motion, but I'll explain how one of the two unconnected regions of gas behaves to make things clearer.

First, chamber A is fully expanded and B is contracted. The valves between the pair A and D and the pair B and C are shut, while the one between A and B (and also C and D) are open. Heat from the source causes expansion of the gas, which forces B to expand and A to contract (remember that B has greater diameter than A and that the piston motions of the two are directly connected). When B is completely expanded and A completely shut, the valves are flipped, so that the valve between A and B, as well as C and D are shut, and the valve between B and C (and D and A) are open. The cooling in C will then cause the piston to go the other way, emptying B and filing C as the overall volume goes down. Then the valves are flipped again and the gas flows from C to the larger D due to further cooling, then the valves are flipped one last time and the gas flows from D to A as heating expands the gas, and then the cycle repeats.

In a complete system there will be two cycles going at all times in two mostly unconnected regions of gas, but leaking between the two regions is no big deal. The two going at once has the nice property that the heating chamber is expanding at all times and the cooling chamber is compressing at all times.

This approach has the added complexity of having actuated valves, but that's not such a big deal. Internal combustion engines rely on valves and they work just fine.

This mechanism appears too simple to not have been thought of before. So my question to everyone is: Are stirling engines just more thermodynamically efficient than they appear to my uneducated eye, or are there some losses in my proposed system I'm unaware of, or has this mechanism been thought of before and simply not used because of its greater mechanical complexity? Or is this actually a possibly useful innovation?

Update: My intuitions about thermodynamics were a bit off. This design will work, but heating during expansion and cooling during compression turn out to be no-no's from an efficiency standpoint.

The basic trick behind current nuclear fusion research is that the binding energy of helium is a significant outlier in terms of being high, so if you fuse together a deuteron and a triton they form a 4He, a high-energy neutron, and a large amount of energy. The main problem with this is the high energy neutron - those things tend to turn everything in the surrounding area into radioactive waste over time. My question is, what's wrong with simply fusing together two deuterons to form a 4He with no extra neutron? Is there no such reaction (my guess is there is, and it emits a neutrino or something), or is the activation energy simply high enough that we can't or don't want to deal with it? If the problem really is activation energy, then if it's within an order of magnitude then rather than getting all excited about current fusion technology and building prototypes working towards commercial reactors as we are now, I'd rather wait until we've got a working all-deuterons system which is completely and totally clean before trying to commercialize it. The engineering behind that would be totally normal energy pressure and heat stuff, with none of that radioactive waste or gradually destroyed and corroded machinery crap.

Here's my idea for a cheap, reasonably safe, and reliable way of generating nuclear reagents:

Dig a wide hole in the ground in a place where radon is common. Cover the bottom with something which radon can get through but water can't, then build a shallow container full of water over it with an inverted funnel at the top, and daily pump out the radon (and other noble gases) which collect at the apex and use them for one of the many uses of nuclear reagents.

Does anyone have any knowledgeable opinion on whether this sort of design has ever been experimented with, whether it would mechanically work, whether it would have a reasonable yield, and whether radon gas itself is useful?

Here in California we recently passed proposition 2, which basically required that farm animals be given enough room to stretch their limbs. The hype against it was a hilarious self-parody of playing off of urbanites's misconceptions of where food comes from: You don't want to let chickens outside, they could catch bird flu! Or run into dirt! Which is rotting! And contains worms! They might even eat a worm! You wouldn't want to each a chicken which had eaten a worm, would you? Okay, so I exaggerate, but it was pretty ridiculous. But that isn't what I really want to make a point about right now.

The other argument against prop. 2 was that it would cause California eggs to be more expensive than mexican eggs, and hence result in california chicken farmers being unable to compete with mexican ones. This on its face makes sense, but I believe the truth is exactly the opposite.

You see, food production in the united states looks very efficient, because prices are very low, but in fact it's extremely inefficient, because consumers would much rather pay slightly more for food which is grown or raised better, and farmers would happily take the higher margins for such food. This is blocked by the total lack of information in the system. Just about the only thing a store-brought chicken says about where it came from is that it's chicken. They can say 'organic' now, which sort of means something, but less than you'd think. By increasing the simple and understandable meaning of the labelling term 'california', consumers are now given extra information about how the chicken which their eggs came from were raised, and are likely to prefer that, especially with a likely price difference of only a few cents.

States in general should probably consider what regulations would cause the most improvement in their produced food for the least increased cost, and institute those regulations and make them widely known, to improve the value of their states's brand. I believe that prop. 2 is simply the most low hanging fruit (no pun intended) for such regulations, and lots more should be added.

In horse race betting there's a concept called 'steam'. A once-popular way of scamming a local off track betting place was to go to an actual horserace, bet big on a guaranteed loser horse, then go to an off track betting place and place a yet even bigger bet on the horse which was likely to win. Because off track betting placed didn't used to routinely use the same pool as at the track, they'd simply mimic the odds add the track, and by using steam you could induce them to place an extremely unfavorable bet.

What does this have to do with the mortgage market? Well, as it happens the credit default swap market is many times the size of the actual mortgage market. How'd that happen? Well, overzealous investors ran out of actual mortgages to invest in, so they simply started placing side bets on how the mortgage market would do, totally many times how big the actual market underneath is. AIG is in a position of being the biggest insurer of the garbage. These two facts put together make for an interesting possible scenario. Since the amount of money on the line is greater than the actual size of the underlying market, AIG could potentially agree to cover every mortgage company's loss in any short sale (a short sale is where the mortgage company agrees to forgive part of a loan to make a sale happen, as a way of avoiding forecloser). That would immediately result in the number of foreclosures being near zero, and AIG would magically have made it so it didn't have to pay out on any of its side bets.

Chances are that the numbers don't work out for this to be a winning proposition. Maybe the CDO insurance industry as a whole, rather than just the largest player, could manage to get away with it. In any case, it sure would be funny.

This puzzle is based on an original mechanical concept I've never seen or heard of anywhere else, three gears all of which mesh at the same point and cycle through which gear goes through the center rather than alternating between two gears as regular gears do. It was designed by me and Oskar van Deventer, and is now available for purchase in a 3d printed form from puzzle palace.

There's a strange circularity in the motivations behind what americans spend their money on. People get, high-paying jobs so that they can afford the house which they need to pay for so they can be near the high-paying job. They work as two-income families so they can afford all the day care, clothes, and take-out food they need to buy because they're a two-income family. They put off having children and save up lots of money when they're young so they can afford all the fertility treatments and child care they'll need when they have children when they're older.

Most people don't seem to think these things through. It's simply how they were told one should do things when they were younger, so they dutifully follow instructions. I for one was never given any sketch of a life path other than getting a high-paying job at an established institution after finishing grad school. Somewhere along the line, the common sense advice that one should view job satisfaction as the primary criterion for what job to take (influenced by pay, but many other things as well), and that one should make a realistic evaluation of how much one is partaking of the benefits one supposedly gets from city living and how difficult it would be to engage in those activities while living elsewhere stopped being handed out. Likewise having a single income household simply became unthinkable, and the observation that the younger you have your children the more your parents can help out, the more energy you have for them, and the more you get to enjoy being a parent and grandparent became nearly taboo to say.

I'm not sure how this all happened. Perhaps the problem is that most life planning advice is given out by school administrators and academics who followed a career arc suspiciously similar to the one they espouse as the one for everyone. Maybe some people overshot the women's rights movement and instead of claiming that women have the right to pursue a career in lieu of children, which they do, started claiming that they have an obligation, which they don't. Maybe in such an uber-capitalist country as the United States all life advice will inevitably involve the career arc which earns as much nominal money as possible (although the bizarre view that anyone who doesn't wind up being a tenured professor at some point failed is advice which doesn't even vaguely optimize for pay).

Whatever the reasons, it's all very sad and causes lots of misery, and I urge everyone to start thinking about these things when they're young, because a lot of people realize far too late that they did everything all wrong.

The state of 'the market' is a trailing indicator, not a leading one. When stocks go up or down it makes a bunch of value change hands in a casino sort of way but doesn't directly (or sometimes even indirectly) affect how the economy is doing.

If you want a better indicator for how things are doing look at the TED spread. When that line goes below 1% and stays there the bleeding has stopped and the healing can begin.

And if you must look at stock prices day to day, look at the russell 3000. It's like the dow jones industrial average, but more widespread so it's less noisy. A note to future index makers: please make your index start at the same value as some other index at the time it begins, so it can be viewed as mostly interchangeable but better, without having to worry about an exchange rate.

There's a profile of me in BusinessWeek. It's a fairly reasonable portrayal, although it focuses a bit much on the asperger's angle. I don't really view my life through the whole overcoming disability narrative (same as most people with disabilities), and tell people that in so many words, but it's such a nice story that journalists tend to focus on it a bit. I mention my asperger's to journalists primarily because, well duh, if you're doing a profile on someone and they have an obvious disability that's clearly something worth mentioning.

There are of course some comments from the usual haters. Some of this seems to be based on an assumption that I'm of the anarcho-libertarian stripe, that movement which is really just neo-social darwinism. For the record, I'm not even vaguely a libertarian. I'm in favor of a higher minimum wage (why that thing never gets inflation indexed is beyond me), national health care, a big fat carbon tax, and open immigrations, as are the bulk of all economists. Only one out of those four is even vaguely consistent with libertarianism. I also find Ayn Rand completely unreadable due to a total lack of literary merit, although I will say that using logic to 'prove' the virtue of laissez-faire capitalism when laissez-faire capitalism is one of one's clearly stated axioms is hardly an insight at all.

Other random notes. I don't remember saying the 'only stupid people care about details' comment, although I have a feeling I was making a somewhat qualified point. There are people who perform necessary jobs where all they do is handle lots of little details, and they are not as a rule stupid. I don't know why editors like picking out really bad pictures of me (the one they used for this article was a test shot, with me squinting into the light). I'd gained some weight at the time the video was shot, although I've lost most of it by now. Fiddling with a rubik's cube during a meeting is sort of like talking to someone while they're driving - you stop doing when something important is going on, and it's otherwise not a big deal, although I've learned not to bring fiddle toys to meetings by now.

There are several different products which will scan your computer for malware. Of course, if you produce a widely distributed application you want to not set any of them off. Currently everybody manually checks to see if they're setting off the latest updates to the malware detectors, and the different suppliers of such software have, ummm, widely diverse approaches to dealing with reports of false positives. This is all a huge pain in the ass, and a giant distraction for lots of application companies.

Somebody please set up a service to do such testing false positive reporting for companies which make applications. The world needs such a service badly.

If you have four points on a plane forming the vertices of a convex quadrilateral, then no finite amount of additional points can result in a configuration where there isn't a subset of four points which form a convex quadrilateral which don't also have a point on their interior. This is fairly easy to show.

My question is, for the vertices of a regular n-gon, how many points must be added to make it so that there's no subset of five points which form the vertices of a convex pentagon and for which there isn't another point inside of that pentagon?

I've been driving on 101 in the mornings a lot lately. Some thoughts:

Nobody obeys the car pool lane rules. I've always got a car full of kids, but most people in the left lane are all by themselves. If the left lane were made officially a regular lane, it would have no appreciable effect on traffic whatsoever.

The fastest way to change lanes is by staying in the right lane up until an exit, then switching all the way to the left lane immediately afterwards and staying there until the next merge, then switching over to the right lane again. The one exception to this is the exit where the right lane doesn't end and instead forks into a new lane going out and the old lane continues. People don't realize that it's there, and the right lane stays fast for a while afterwards.

California drivers will not let you merge. The occasional person will, but for the most part people will literally play chicken with you when they see you're trying to merge ahead of them. This makes things even more dangerous than is obvious, because it causes people to be way too herky-jerky in all merge situations, even in ones where the person behind isn't trying to cause an accident.

I wish they'd finish the new road construction already. 30 minutes of stop and go traffic every morning kinda sucks.

There's apparently some serious market inefficiency going on over at intrade.

It isn't necessarily the case that someone is artificially keeping the ratio not as far in Obama's favor as it should be - perhaps there's a single market participant keeping a natural balance. What's clearly inefficient (if it's true) is that a single market participant is making predictable swings in the market up and down.

Rather than complaining about it, I say punish the bastard! You know the drill: buy low, sell high. When the market hits one its now regularly scheduled shocks down buy immediately, then wait until before the next shock down and sell. Rinse and repeat until either you've made a bunch of money or whoever's generating excessive market moves gives up.

Of course, now that the secret's out they might simply not do it any more. That's the way it goes.

I posted about the proper use of erasure codes in BitTorrent to the bittorrent.org forums, it's xor pieces.

Yes, I know this should really be in a refereed journal. Sorry I don't write academic papers.

I've posted my thoughts on the BitTorrent fast extensions to the thread for them on the bittorrent.org forums. Must reading for anyone working on a BitTorrent implementation, these extensions really should become ubiquitous.

I was never very happy with the second design on this page, so the other day I came up with this improvement, which is more compact, has fewer crossings, and comes apart more easily:

____________   ___   _________   ______
            \ /   \ /         \ /      
             \     /           /       
___   ___   / \   / \   ___   / \   ___
   \ /   \ /   \ /   \ /   \ /   \ /  
    \     \     /     /     \     \  
___/ \   / \___/ \   / \   / \___/ \___
      \ /         \ /   \ /      
       /           /     \        
______/ \_________/ \___/ \____________

At first glance this design appears to have some unnecessary crossings, but refactoring those out makes the braid pattern so tight that it can't be taken apart. This design is a simple tweak of the simplest puzzle ring of this kind to make it actually work as a puzzle. I'm quite fond of it.

The US women's championship ended in a disaster of a blitz game. One player got in severe time trouble and started moving her pieces before the opponent had hit the clock, thus managing to hit her clock almost instantly after her opponent did. She eventually won on time in a lost position.

On top of being messed up, this is clearly against the rules. In an unusual move, a protest was lodged, and there was some official response, although it basically amounted to 'we never enforce that rule', which is true. I can tell you from experience that (1) it's completely impossible to simultaneously play blitz chess and audit whether your opponent is waiting to touch their pieces after you hit your clock, and (2) bullying the clock is completely rampant, in fact it's one of the core skills of experienced blitz players.

I'd like to propose a new technical solution to this problem. In addition to the regular two buttons on a chess clock, two more are added, and the rule is that after your opponent hits their side of the clock you have to hit the secondary button on your side, then move your piece with the same hand, then hit your main button. This would be very easy to audit, especially with an electronic clock which enforced the appropriate state machine, and it would completely eliminate the clock bullying bullshit which dominates the blitz world.

This would be a great piece of technology for blitz tournaments. Of course, it's completely absurd to use a blitz game as a tiebreak for a regular time controls tournament at all, much less a championship. Trying to clean that up looks fairly hopeless though - the current state of chess titles is comparable to the situation in boxing, and there are no signs of things getting better.

A little piece of trivia: I once won a game against Irina Krush. That isn't as impressive as it sounds, though. She was eight years old at the time.

Valid word in this post which the spell checker didn't like: tiebreak. Also seen recently: counterintuitively.

Say there's an infinite hexagonal tiling, with a single cell labelled the 'root'. A game is played by two players, the weed and the gardener, who alternate placing pieces of their color in empty cells. The gardener's goal is to make a connected region of cells of the gardener's color which completely surrounds the root. The weed's goal is to keep that from happening indefinitely.

Is it possible for the gardener to always win? My intuition as a hex player is that the gardener can always win eventually, even if the weed is allowed to place a large but finite amount of their pieces before play starts. I have no idea how to prove it though.

Anybody who's up for it, come to googlegamecenter.com and let's play. There's lots of interesting games available there, and it's a shame there aren't more players.

Failing gracefully is a far more difficult problem than people intuitively expect. Take the case of a web site which has insufficient bandwidth or CPU to handle its current load. Graceful failure in this case would be to let some fraction of users in, and politely tell the other users they have to wait because of the load. Web sites don't by default do anything even vaguely resembling this. Instead, page load times become very slow, and when things time out its on a per-page or even per-object basis, resulting in an acceptable site experience for no one. Even worse, when users get a bad object load in a page or a bad page load as a whole, they'll usually hit reload rather than leaving, causing the site load to be far greater than it would be were it serving the same number of users in a reasonable fashion.

It would be nice if someone could write a thing for Apache to do this automatically. When a site starts hitting bandwidth or CPU limits (preferably automatically detected by the site itself) it starts rejecting users and giving them cookies to keep repeated reloads from getting in. Ideally, it would even create a queue of users and let them know when they're up and give an estimated amount of time until they're let in.

Of course, it's always better to simply have enough bandwidth and CPU around. But once in a while someone finds themselves in a situation where they don't, and if it were possible to simply install a generic fail gracefully utility and leave that running as an interim solution until they can get a proper one in place, that would make the world a better place.

Dear Lazyweb,

I used my wife's macbook and foolishly hit 'okay' when it asked if I wished to install updates, not knowing that she has a policy of always hitting 'later' for those, and forgetting that I've already bricked two computers that way. After a reboot and install Safari now no longer works, exiting instantly, and when I try to invoke it from the command line it says

jenna-cohens-macbook:~ jennacohen$ /Applications/Safari.app/Contents/MacOS/Safari
2008-06-09 22:36:07.903 Safari[854:10b] Unable to load nib file: MainMenu, exiting

Of course if I try to re-download and re-install Safari it says that I need MacOS version 10.5.2 or newer when I try to select the only available partition to install on, even though this thing came with 10.5.3.

Any idea what, if anything, I can do to solve the problem? Using Firefox is working for now, but I'd like to have Safari working again.

Update: On the suggestion of some commenters, I re-installed the update pack, and made 'progress' in the form of it now giving a dialog saying 'Safari cannot open a browser window and may be missing important resources. Try installing Safari again.' when I try to run Safari. The Safari installer continues to insist that it doesn't have a proper version of MacOS installed (even though there is) and now trying to run it from the command line gives the following stdout (in addition to the dialog):

jenna-cohens-macbook:~ jennacohen$ /Applications/Safari.app/Contents/MacOS/Safari
2008-06-10 00:47:40.790 Safari[308:10b] -[BrowserWindowController loadWindow]: failed to load window nib file '(null)'.

Update 2: Problem is now fixed, thank you. But I'd like to note the very real issue that the latest version of Safari on Apple's site doesn't work with the latest version of their OS - you need to be one minor version back for that.

After having watched at least one obviously fixed boxing match, and several more which made for just plain bad television, I have a big question about the scoring. Why on earth aren't the judges forced to give their scores after every round? In most cases fixing a bout requires outlandish enough scoring that the judge has to retroactively go back and change their scores on earlier rounds to come up with something even vaguely plausible, and having them commit to earlier round scores would end that practice completely. If the ringside announcers can give a score immediately after every round, there's no reason why the judges can't as well. Hell, my own vague judgments of 'I think I saw X' tend to hit the average of the judge's score better than the individual judges generally do. That's another big issue with boxing scoring - the judges's scores have such high variance that the claim that the winner of a close bout is anything other than arbitrary and subjective is quite ludicrous. Figuring skating is worse, but that's indicative of the situation in figure skating being beyond ludicrous.

On the subject of boxing, I have a suggested rules change which would spare boxers most of the brain damage they now sustain: When you're knocked out, you lose. None of this waiting until the count of ten to see if you can pull yourself together and get up and continue to have your brains scrambled. If you hit the mat and can't get up instantaneously, that means your brain has sustained serious injury and taking any further punishment is extremely dangerous. Other martial arts, including ones with tons of striking, have nowhere near the record of brain injury that boxing does, and the reason is hardly a secret - in those sports, if you're knocked out, you lose.

It's been a while since I last posted my thoughts on version control. My thoughts have changed a lot over time, so I'm going to cover everything from the very highest level.

Here are my recommendations:

1. Don't use branches.

I'm serious. Creating lots of branches takes a lot of time and energy, and is usually a complete waste. If you have a good reason to use branches, use the minimum possible. In particular, creating a new branch for every new feature is ludicrous.

2. Don't bother with a pretty history.

The history of a branch is hardly ever looked at. Making it look pretty for the historians is just a waste of time. The beauty of 3-way merge is that you can always clean stuff up later and never worry about the past mess ever again. In particular, don't go to great lengths to make sure that there's a coherent local image of the entire repository exactly as it appeared on your local machine after every new feature. There are very rare projects which maintain a level of reliability and testing which warrant such behavior, and yours isn't one of them. Stop wanking.

3. Use 3-way merge

This is mostly a dig at myself - I've spent a long time thinking about possible semantics of merging, and the upshot is that there's a way of supporting cherry-picking well in the underlying engine, but nobody's ever proposed a good UI for it, and I suspect that's because the feature is inherently confusing and not such a hot idea for process reasons as well.

4. Use Bram's diff algorithm.

This is for tool developers, not for end users. It's fairly self explanatory.

5. Treat stable branches as forks, don't auto-merge from them.

Once a stable branch has been separate for a while, the development branch has inevitably deviated too much for auto-merging to be accurate and useful. Most projects have a convention for marking bug fixes in commit comments on the development branch, then grepping for those comments in the history and manually trying to apply those patches. The tools support for this is sucky, and the world will be a more productive place if someone improves that, but the practice is clearly a good one.

6. Don't spend time achieving a greater than usual level of stability on the main branch before branching off stable

Forcing everyone to wait until stable is branched off to get any work done just wastes their time. It's far better to do the stable branch first, then work on extra stability on the stable branch while people continue to get new work done on the main branch.

7. If you do use branches, have them 'shadow' the main branch.

Branches which don't get merged regularly inevitably become forked forever. For a branch to continue to be useful it's necessary for it to pull from the main branch on a regular basis and have any resulting conflicts be resolved.

Good reasons to have a branch are if there's a feature which might turn out to be a bad idea, there's some code work which would cause too much instability if it were checked into the main branch before being complete, or there's a direct need to have a version of the codebase missing certain features. In all of these cases the branch must be maintained by pulling from the branch it's shadowing frequently in order to not die, and the branch should have its contents committed into main and stop being maintained as soon as is feasible.

Experimental features or ones written by a person of dubious coding skills in particular should only be a single branch. Some projects treat them as a zillion piecemeal little patches, and that's just painful and awful. Far better to give feedback on a branch, and commit the whole branch when it's at an acceptable level of stability. Note that experimental branches can have their own stable and unstable versions as well, with work going on on unstable while code improvement happens in stable. That's a good practice, although it's hardly ever done today.

8. Show all relevant history in annotate/blame view

If a line of code was written by one person, then pulled into the main branch by another person, then the history should say when and by whom both of those events happened. If it was pulled into another branch by another person, that should be included as well. The semantics of a single line's history is that it was written once and then had a series of pull (or push, depending on how you think about it) operations performed on it as it was moved into other branches. None of the tools currently get this right.

9. If you have a good reason to branch off branches, do it right.

There are a few sophisticated techniques for branch management which are fairly safe and coherent from a process standpoint. These should only be used sparingly, but tools support for them is currently lousy and they're cool so I'll explain them now.

First, it's possible to have a branch shadow another branch, like this:

        main
        /
 branch A
      /
branch B

In this case, A is shadowing main, and B is shadowing A.

It's also possible under some circumstances to safely change the way the branch relationships work. For example, the previous case can be changed into this one, and vice versa:

        main
        /   \
 branch A   branch B

For those of you knowledgeable about the technical issues, the times when this can be done are when the LCA of the branch being moved and the one it's shadowing is already an ancestor of the current version of the new branch to shadow. If the reparenting isn't currently allowed, then some committing or updating can be done to make it allowed (although that might not be immediately advisable for process reasons).

Version control system developers, please make your systems have the shadowing concept be built in from the ground up. And allow the safe forms of reparenting. And make sure that the branch relationships and their changes are kept in the history along with everything else.

Valid words used in this post which the spell checker didn't like: wanking, grepping, sucky, codebase, reparenting.

The new drug chantix is quite effective at getting people to quit smoking. It basically works by making you no longer get a rush from cigarettes, which helps people stop using them.

While the health effects of smoking are deleterious enough to warrant quite a bit of damage and risk from an effective smoking cessation program, there's a bit of a stir about the possible side effects of chantix going on right now. Given the effects described, and the mechanism by which chantix works, I have a theory as to what's causing the problem, and would like to propose the following warning label for it:

Warning: This drug may cause you to spontaneously quit smoking, and in case you haven't heard, quitting smoking sucks!