<?xml version="1.0" encoding="utf-8"?>
<!-- If you are running a bot please visit this policy page outlining rules you must respect. http://www.livejournal.com/bots/ -->
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:lj="http://www.livejournal.com">
  <id>urn:lj:livejournal.com:atom1:bramcohen</id>
  <title>Bram Cohen's Journal</title>
  <subtitle>Whatever I feel like posting about</subtitle>
  <author>
    <name>Bram Cohen</name>
  </author>
  <link rel="alternate" type="text/html" href="http://bramcohen.livejournal.com/"/>
  <link rel="self" type="text/xml" href="http://bramcohen.livejournal.com/data/atom"/>
  <updated>2009-07-17T21:30:05Z</updated>
  <lj:journal userid="4644944" username="bramcohen" type="personal"/>
  <link rel="service.feed" type="application/x.atom+xml" href="http://bramcohen.livejournal.com/data/atom" title="Bram Cohen's Journal"/>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bramcohen:68777</id>
    <link rel="alternate" type="text/html" href="http://bramcohen.livejournal.com/68777.html"/>
    <link rel="self" type="text/xml" href="http://bramcohen.livejournal.com/data/atom/?itemid=68777"/>
    <title>Oskar's Mixup Cube</title>
    <published>2009-07-17T15:27:54Z</published>
    <updated>2009-07-17T21:30:05Z</updated>
    <content type="html">&lt;lj-embed id="12" /&gt;&lt;br /&gt;This puzzle looks like a Rubik's Cube, but it allows some moves which clearly shouldn't be.</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bramcohen:68464</id>
    <link rel="alternate" type="text/html" href="http://bramcohen.livejournal.com/68464.html"/>
    <link rel="self" type="text/xml" href="http://bramcohen.livejournal.com/data/atom/?itemid=68464"/>
    <title>Someone at Mozilla Foundation needs to be fired</title>
    <published>2009-07-09T22:47:15Z</published>
    <updated>2009-07-09T22:47:15Z</updated>
    <content type="html">Somebody at Mozilla decided they &lt;a href="http://weblogs.asp.net/fbouma/archive/2009/07/09/the-firefox-3-5-fiasco.aspx" target="_blank"&gt;need lots of 'true' random numbers&lt;/a&gt;.&lt;br /&gt;&lt;br /&gt;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&amp;nbsp;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.&lt;br /&gt;&lt;br /&gt;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&amp;nbsp;repeat myself, because I&amp;nbsp;have a hunch people will think I'm glossing over some nuance here) of no benefit whatsoever.&lt;br /&gt;&lt;br /&gt;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):&amp;nbsp;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.&lt;br /&gt;&lt;br /&gt;Some people might think that if I&amp;nbsp;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.&lt;br /&gt;&lt;br /&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bramcohen:68348</id>
    <link rel="alternate" type="text/html" href="http://bramcohen.livejournal.com/68348.html"/>
    <link rel="self" type="text/xml" href="http://bramcohen.livejournal.com/data/atom/?itemid=68348"/>
    <title>Ludology in City of Heroes</title>
    <published>2009-07-07T18:47:27Z</published>
    <updated>2009-07-07T18:47:27Z</updated>
    <content type="html">City of Heroes has had &lt;a href="http://www.nola.com/news/index.ssf/2009/07/loyola_university_professor_be.html"&gt;some interesting issues&lt;/a&gt; with its gameplay, involving a character named Twixt using some tactics which made everybody hate him.&lt;br /&gt;&lt;br /&gt;Several years ago I&amp;nbsp;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&amp;nbsp;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&amp;nbsp;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&amp;nbsp;was asking, and his answer, which really perplexed me at the time, was that it was a good question, but he didn't know.&lt;br /&gt;&lt;br /&gt;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.&lt;br /&gt;&lt;br /&gt;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.&lt;br /&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bramcohen:67982</id>
    <link rel="alternate" type="text/html" href="http://bramcohen.livejournal.com/67982.html"/>
    <link rel="self" type="text/xml" href="http://bramcohen.livejournal.com/data/atom/?itemid=67982"/>
    <title>Bandwidth fundamentals</title>
    <published>2009-07-06T23:26:56Z</published>
    <updated>2009-07-06T23:26:56Z</updated>
    <content type="html">A random person asks about something they read on Wikipedia:&lt;br /&gt;&lt;div style="margin-left: 40px;"&gt;&lt;br /&gt;Example from wiki below: &lt;br /&gt; &lt;br /&gt;http://en.wikipedia.org/wiki/Bram_Cohen &lt;br /&gt; &lt;br /&gt;quote from site: &lt;br /&gt; &lt;br /&gt;MojoNation allows people to break up confidential files into encrypted chunks and distribute those pieces on computers also running the software. If someone wanted to download a copy of this encrypted file, he would have to download it simultaneously from many computers. This concept, Cohen thought, was perfect for a file sharing program, since programs like KaZaA take a long time to download a large file because the file is (usually) coming from one source (or &amp;quot;peer&amp;quot;). Cohen designed BitTorrent to be able to download files from many different sources, thus speeding up the download time, especially for users with faster download than upload speeds. Thus, the more popular a file is, the faster a user will be able to download it, since many people will be downloading it at the same time, and these people will also be uploading the data to other users. &lt;/div&gt;&lt;div&gt;&lt;br /&gt;This explanation was lifted from an actual new article, which &lt;a href="http://bramcohen.livejournal.com/8502.html" target="_blank"&gt;doesn't necessarily mean it's true&lt;/a&gt;. In fact, it's somewhere between grossly misleading and wrong.&lt;br /&gt;&lt;br /&gt;There's a classic fallacy because if one person stands up during a concert they get a better view, then if everybody stood up during a concert they'd all get a better view. This is of course is not true - they wind up slightly worse off by all standing, because they all compete with each other for a view. The same thing happens with downloading from a server. In general, web servers will give about the same rate to every client downloading from them, so if you open many more connections than everybody else you get a greater proportion of the bandwidth and hence a better rate. But you do so simply by taking bandwidth from other downloaders. The overall supply of upload is unchange, it's simply being shuffled around. If everybody does the same thing it results in overall slightly worse performance and you're basically back where you started, but with a bunch of headaches tacked on.&lt;br /&gt;&amp;nbsp;&lt;/div&gt;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.&lt;br /&gt;&lt;br /&gt;On the internet, the formula is bytes downloaded = bytes uploaded. It's that simple.&lt;br /&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bramcohen:67591</id>
    <link rel="alternate" type="text/html" href="http://bramcohen.livejournal.com/67591.html"/>
    <link rel="self" type="text/xml" href="http://bramcohen.livejournal.com/data/atom/?itemid=67591"/>
    <title>The Uncanny Cube</title>
    <published>2009-07-06T21:51:49Z</published>
    <updated>2009-07-06T21:51:49Z</updated>
    <content type="html">&lt;lj-embed id="10" /&gt;&lt;br /&gt;&lt;br /&gt;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.</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bramcohen:67449</id>
    <link rel="alternate" type="text/html" href="http://bramcohen.livejournal.com/67449.html"/>
    <link rel="self" type="text/xml" href="http://bramcohen.livejournal.com/data/atom/?itemid=67449"/>
    <title>Bram's Cube</title>
    <published>2009-07-03T16:48:22Z</published>
    <updated>2009-07-03T16:48:22Z</updated>
    <content type="html">&lt;lj-embed id="9" /&gt;&lt;br /&gt;&lt;br /&gt;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.</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bramcohen:67244</id>
    <link rel="alternate" type="text/html" href="http://bramcohen.livejournal.com/67244.html"/>
    <link rel="self" type="text/xml" href="http://bramcohen.livejournal.com/data/atom/?itemid=67244"/>
    <title>New Puzzles - Bram's Black Hole and Fairly Twisted</title>
    <published>2009-06-15T14:58:44Z</published>
    <updated>2009-06-15T14:58:44Z</updated>
    <content type="html">&lt;lj-embed id="7" /&gt;&lt;br /&gt;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.&lt;br /&gt;&lt;br /&gt;&lt;lj-embed id="8" /&gt;&lt;br /&gt;Fairly Twisted is a twisty puzzle with no symmetry.</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bramcohen:66883</id>
    <link rel="alternate" type="text/html" href="http://bramcohen.livejournal.com/66883.html"/>
    <link rel="self" type="text/xml" href="http://bramcohen.livejournal.com/data/atom/?itemid=66883"/>
    <title>Puzzle Ring tweaking</title>
    <published>2009-06-08T21:12:59Z</published>
    <updated>2009-06-08T21:12:59Z</updated>
    <content type="html">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.&lt;br /&gt;&lt;br /&gt;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 :-)&lt;br /&gt;&lt;br /&gt;&lt;pre&gt;

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


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


              __   ___   __
       ___   /  \ /   \ /  \   ___
_____ /   \ /    \     /    \ /   \ ________
     \     \    / \   / \    /     /
    / \   / \   |  |  |  |  / \   / \   
___/   \ /   \ /   \ /   \ /   \ /   \ _____
        \     \     \     /     /     /
       / \   / \   / \   / \   / \   / \
____   |  |  |  |  |  |  |  |  |  |  |  L___
    \ /   \ /   \ /   \ /   \ /   \ /
     /     /     /     \     \     \
____/ \   / \   / \   / \   / \   / \   ____
       |  |  |  |  |  |  |  |  |  |  |  |
       \ /   \ /   \ /   \ /   \ /   \ /
___     /     /     /     \     \     \_____
   \   / \   / \   / \   / \   / \   /
    \ /   \ /   |  |  |  |  \ /   \ /
_____/     /    \ /   \ /    \     \________
      \___/ \    /     \    / \___/
             \__/ \___/ \__/
&lt;/pre&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bramcohen:66606</id>
    <link rel="alternate" type="text/html" href="http://bramcohen.livejournal.com/66606.html"/>
    <link rel="self" type="text/xml" href="http://bramcohen.livejournal.com/data/atom/?itemid=66606"/>
    <title>Kite wind power</title>
    <published>2009-06-01T06:03:31Z</published>
    <updated>2009-06-01T06:03:31Z</updated>
    <content type="html">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 &lt;a href="http://advogato.org/person/Bram/diary/96.html"&gt;get power from lightning&lt;/a&gt;. 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:&lt;br /&gt;&lt;br /&gt;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:&lt;br /&gt;&lt;br /&gt;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?&lt;br /&gt;&lt;br /&gt;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.&lt;br /&gt;&lt;br /&gt;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?</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bramcohen:66555</id>
    <link rel="alternate" type="text/html" href="http://bramcohen.livejournal.com/66555.html"/>
    <link rel="self" type="text/xml" href="http://bramcohen.livejournal.com/data/atom/?itemid=66555"/>
    <title>Maybe goto isn't so bad after all.</title>
    <published>2009-06-01T05:11:25Z</published>
    <updated>2009-06-01T05:11:25Z</updated>
    <content type="html">I've used this pattern a lot over the last few days:&lt;br /&gt;&lt;br /&gt;&lt;pre&gt;
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
&lt;/pre&gt;&lt;br /&gt;&lt;br /&gt;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:&lt;br /&gt;&lt;br /&gt;&lt;pre&gt;
for eggs in spam:
    for jello in eggs:
        if jello is the one I want:
            do stuff with eggs and jello
            return
&lt;/pre&gt;&lt;br /&gt;&lt;br /&gt;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:&lt;br /&gt;&lt;br /&gt;&lt;pre&gt;
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
&lt;/pre&gt;&lt;br /&gt;&lt;br /&gt;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.&lt;br /&gt;&lt;br /&gt;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:&lt;br /&gt;&lt;br /&gt;&lt;pre&gt;
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
&lt;/pre&gt;&lt;br /&gt;&lt;br /&gt;But short of that the following may be the best option currently available. I might switch to it:&lt;br /&gt;&lt;br /&gt;&lt;pre&gt;
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
&lt;/pre&gt;&lt;br /&gt;&lt;br /&gt;But it still doesn't look as nice as the version with a goto.</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bramcohen:66270</id>
    <link rel="alternate" type="text/html" href="http://bramcohen.livejournal.com/66270.html"/>
    <link rel="self" type="text/xml" href="http://bramcohen.livejournal.com/data/atom/?itemid=66270"/>
    <title>Geary Cube</title>
    <published>2009-05-29T05:04:38Z</published>
    <updated>2009-05-29T05:07:32Z</updated>
    <content type="html">&lt;lj-embed id="6" /&gt;&lt;br /&gt;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.</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bramcohen:66035</id>
    <link rel="alternate" type="text/html" href="http://bramcohen.livejournal.com/66035.html"/>
    <link rel="self" type="text/xml" href="http://bramcohen.livejournal.com/data/atom/?itemid=66035"/>
    <title>CodeCon 2009 now streaming live</title>
    <published>2009-04-17T23:43:25Z</published>
    <updated>2009-04-17T23:43:25Z</updated>
    <content type="html">Live streaming of CodeCon 2009 is now up. It's linked from the &lt;a href="http://www.codecon.org/2009/"&gt;CodeCon 2009 front page&lt;/a&gt;.&lt;br /&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bramcohen:65748</id>
    <link rel="alternate" type="text/html" href="http://bramcohen.livejournal.com/65748.html"/>
    <link rel="self" type="text/xml" href="http://bramcohen.livejournal.com/data/atom/?itemid=65748"/>
    <title>CodeCon 2009 starting Tomorrow</title>
    <published>2009-04-17T01:03:39Z</published>
    <updated>2009-04-17T01:03:39Z</updated>
    <content type="html">&lt;a href="http://www.codecon.org/2009/"&gt;CodeCon 2009&lt;/a&gt; starts tomorrow. We're just finishing up getting ready, and it's going to be great. See everybody there!&lt;br /&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bramcohen:65399</id>
    <link rel="alternate" type="text/html" href="http://bramcohen.livejournal.com/65399.html"/>
    <link rel="self" type="text/xml" href="http://bramcohen.livejournal.com/data/atom/?itemid=65399"/>
    <title>I'm twittering</title>
    <published>2009-04-08T19:42:36Z</published>
    <updated>2009-04-08T19:42:36Z</updated>
    <content type="html">I've signed up for &lt;a href="http://twitter.com/bramcohen" target="_blank"&gt;a twitter account&lt;/a&gt;, 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&amp;nbsp;have more friends there, and oh yeah, Twitter doesn't have comments yet. Please fix.&lt;br /&gt;&lt;br /&gt;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.&lt;br /&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bramcohen:65060</id>
    <link rel="alternate" type="text/html" href="http://bramcohen.livejournal.com/65060.html"/>
    <link rel="self" type="text/xml" href="http://bramcohen.livejournal.com/data/atom/?itemid=65060"/>
    <title>The End is Nigh</title>
    <published>2009-04-05T17:13:10Z</published>
    <updated>2009-04-05T17:13:10Z</updated>
    <content type="html">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.&lt;br /&gt;&lt;br /&gt;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.&lt;br /&gt;&lt;br /&gt;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.</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bramcohen:64905</id>
    <link rel="alternate" type="text/html" href="http://bramcohen.livejournal.com/64905.html"/>
    <link rel="self" type="text/xml" href="http://bramcohen.livejournal.com/data/atom/?itemid=64905"/>
    <title>Codecon</title>
    <published>2009-04-01T15:33:25Z</published>
    <updated>2009-04-01T15:33:25Z</updated>
    <content type="html">Remember that today's the last day to get the early bird discount to &lt;a href="http://codecon.org/2009/"&gt;Codecon 2009&lt;/a&gt;, so if you haven't signed up yet, do it now.</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bramcohen:64635</id>
    <link rel="alternate" type="text/html" href="http://bramcohen.livejournal.com/64635.html"/>
    <link rel="self" type="text/xml" href="http://bramcohen.livejournal.com/data/atom/?itemid=64635"/>
    <title>Rotacubes</title>
    <published>2009-03-27T19:14:54Z</published>
    <updated>2009-03-27T19:42:51Z</updated>
    <content type="html">&lt;lj-embed id="4" /&gt;&lt;br /&gt;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.</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bramcohen:64486</id>
    <link rel="alternate" type="text/html" href="http://bramcohen.livejournal.com/64486.html"/>
    <link rel="self" type="text/xml" href="http://bramcohen.livejournal.com/data/atom/?itemid=64486"/>
    <title>CodeCon 2009 Program Posted</title>
    <published>2009-03-23T19:36:27Z</published>
    <updated>2009-03-23T21:43:36Z</updated>
    <content type="html">The Program to &lt;a href="http://www.codecon.org/2009/index.html"&gt;CodeCon 2009&lt;/a&gt; is now up, and &lt;a href="http://www.codecon.org/2009/registration.html"&gt;registration&lt;/a&gt; is at the early rate of $75 for all three days until April 1st, after which the cost goes up.&lt;br /&gt;&lt;br /&gt;An explanation of CodeCon, from the site:&lt;br /&gt;&lt;blockquote&gt;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.&lt;/blockquote&gt;&lt;br /&gt;Presentations this year include:&lt;br /&gt;&lt;br /&gt;&lt;b&gt;BioHack! Track:&lt;/b&gt;&lt;ul&gt;&lt;li&gt;&lt;a href="http://www.codecon.org/2009/program.html#DIYSynthenticBio"&gt;DIY Synthetic Biology&lt;/a&gt; - From Design to Construction with New Model Organisms &lt;br /&gt;&lt;li&gt;&lt;a href="http://www.codecon.org/2009/program.html#HomebrewGeneticTesting"&gt;Homebrew Genetic Testing&lt;/a&gt; - Read your own source code - at home! &lt;br /&gt;&lt;li&gt;&lt;a href="http://www.codecon.org/2009/program.html#KeikiGels"&gt;Keiki Gels&lt;/a&gt; - Visualize DNA -- in a drinking straw! &lt;br /&gt;&lt;/ul&gt;&lt;br /&gt;&lt;b&gt;Code Track:&lt;/b&gt;&lt;ul&gt;&lt;li&gt;&lt;a href="http://www.codecon.org/2009/program.html#BitTorrentDNA"&gt;BitTorrent DNA&lt;/a&gt; - Effortless BitTorrent deployment &lt;br /&gt;&lt;li&gt;&lt;a href="http://www.codecon.org/2009/program.html#DistributedTrans"&gt;Distributed Transaction Layer for Google App Engine&lt;/a&gt; - Transaction semantics across multiple entity groups for applications written in the Google App Engine &lt;br /&gt;&lt;li&gt;&lt;a href="http://www.codecon.org/2009/program.html#HeliosVoting"&gt;Helios Voting&lt;/a&gt; - The first and only web-based voting system that enables voters to verify their vote and the overall tally with cryptographic certainty.&lt;br /&gt;&lt;li&gt;&lt;a href="http://www.codecon.org/2009/program.html#LibEvent"&gt;Libevent&lt;/a&gt; - making fast asynchronous network programs portable &lt;br /&gt;&lt;li&gt;&lt;a href="http://www.codecon.org/2009/program.html#MozillaPork"&gt;Pork&lt;/a&gt; - Largescale Automatic Rewriting of C++ &lt;br /&gt;&lt;li&gt;&lt;a href="http://www.codecon.org/2009/program.html#OneSwarm"&gt;OneSwarm&lt;/a&gt; - privacy preserving peer-to-peer data sharing &lt;br /&gt;&lt;li&gt;&lt;a href="http://www.codecon.org/2009/program.html#ParallelWeb"&gt;Parallel Web Browser&lt;/a&gt; - a web browser for handhelds &amp; multicore laptops &lt;br /&gt;&lt;li&gt;&lt;a href="http://www.codecon.org/2009/program.html#Switzerland"&gt;Switzerland&lt;/a&gt; - a semi-P2P system for detecting forged and modified IP packets between clients &lt;br /&gt;&lt;li&gt;&lt;a href="http://www.codecon.org/2009/program.html#TahoeLAFS"&gt;Tahoe, the Least-Authority Filesystem &lt;/a&gt; - a secure, decentralized, fault-tolerant storage network &lt;br /&gt;&lt;li&gt;&lt;a href="http://www.codecon.org/2009/program.html#TorFlow"&gt;TorFlow&lt;/a&gt; - A Python-based Tor Research Toolset &lt;br /&gt;&lt;li&gt;&lt;a href="http://www.codecon.org/2009/program.html#TrendProf"&gt;Trend Profiler / trend-prof&lt;/a&gt; - Finding performance surprises (super-linearities) in C / C++ code based on trends in the runs on different size inputs. &lt;br /&gt;&lt;li&gt;&lt;a href="http://www.codecon.org/2009/program.html#TyphonScream"&gt;Typhon / Scream&lt;/a&gt;&lt;br /&gt;&lt;/ul&gt;&lt;br /&gt;To learn more about CodeCon, you can look at the sites from previous years:&lt;br /&gt;&lt;br /&gt;&lt;a href="http://www.codecon.org/2006/"&gt;2006&lt;/a&gt;&lt;br /&gt;&lt;a href="http://www.codecon.org/2006/"&gt;2005&lt;/a&gt;&lt;br /&gt;&lt;a href="http://www.codecon.org/2006/"&gt;2004&lt;/a&gt;&lt;br /&gt;&lt;a href="http://www.codecon.org/2006/"&gt;2003&lt;/a&gt;&lt;br /&gt;&lt;a href="http://www.codecon.org/2006/"&gt;2002&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;&lt;a href="http://digg.com/submit?url=http%3A%2F%2Fbramcohen.livejournal.com%2F64486.html"&gt;Digg this!&lt;/a&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bramcohen:64012</id>
    <link rel="alternate" type="text/html" href="http://bramcohen.livejournal.com/64012.html"/>
    <link rel="self" type="text/xml" href="http://bramcohen.livejournal.com/data/atom/?itemid=64012"/>
    <title>version control tidbits</title>
    <published>2009-03-01T08:04:09Z</published>
    <updated>2009-03-01T08:11:03Z</updated>
    <content type="html">I &lt;a href="http://n2.nabble.com/Bram-Cohen-speaks-up-about-patience-diff-td2277041.html"&gt;wrote up an explanation&lt;/a&gt; of when patience diff gives significantly different results, and why they're important.&lt;br /&gt;&lt;br /&gt;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?&lt;br /&gt;&lt;br /&gt;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.&lt;br /&gt;&lt;br /&gt;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.&lt;br /&gt;&lt;br /&gt;Another interesting case is the following:&lt;br /&gt;&lt;pre&gt;
     a
    / \
   b   c
  / \ /
 c   b
  \ /
   ?
&lt;/pre&gt;&lt;br /&gt;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.&lt;br /&gt;&lt;br /&gt;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.</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bramcohen:63946</id>
    <link rel="alternate" type="text/html" href="http://bramcohen.livejournal.com/63946.html"/>
    <link rel="self" type="text/xml" href="http://bramcohen.livejournal.com/data/atom/?itemid=63946"/>
    <title>Trigears video</title>
    <published>2009-02-25T18:00:27Z</published>
    <updated>2009-02-25T18:00:27Z</updated>
    <content type="html">&lt;lj-embed id="3" /&gt;&lt;br /&gt;When I&amp;nbsp;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.&amp;nbsp;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bramcohen:63672</id>
    <link rel="alternate" type="text/html" href="http://bramcohen.livejournal.com/63672.html"/>
    <link rel="self" type="text/xml" href="http://bramcohen.livejournal.com/data/atom/?itemid=63672"/>
    <title>Bram explains unix time</title>
    <published>2009-02-17T20:10:07Z</published>
    <updated>2009-02-17T20:10:07Z</updated>
    <content type="html">&lt;pre style="margin: 0px; padding: 0px; display: block;"&gt;&lt;lj-embed id="2" /&gt;

&lt;/pre&gt;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.&lt;br /&gt;&lt;br /&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bramcohen:63411</id>
    <link rel="alternate" type="text/html" href="http://bramcohen.livejournal.com/63411.html"/>
    <link rel="self" type="text/xml" href="http://bramcohen.livejournal.com/data/atom/?itemid=63411"/>
    <title>CodeCon deadline coming up</title>
    <published>2009-02-13T23:20:30Z</published>
    <updated>2009-02-13T23:20:30Z</updated>
    <content type="html">The deadline for CodeCon submissions is &lt;a href="http://www.codecon.org/2009/cfp.txt"&gt;coming up this sunday&lt;/a&gt;! 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!&lt;br /&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bramcohen:63031</id>
    <link rel="alternate" type="text/html" href="http://bramcohen.livejournal.com/63031.html"/>
    <link rel="self" type="text/xml" href="http://bramcohen.livejournal.com/data/atom/?itemid=63031"/>
    <title>Corrections</title>
    <published>2009-02-11T01:12:04Z</published>
    <updated>2009-02-11T01:12:04Z</updated>
    <content type="html">Believe it or not, you can't believe everything you read on wikipedia.&lt;br /&gt;&lt;br /&gt;I currently live in the San Francisco area.&lt;br /&gt;&lt;br /&gt;I have three children.&lt;br /&gt;&lt;br /&gt;I've never heard of badger and badger.&lt;br /&gt;&lt;br /&gt;Also, the article about my asperger's said that I&amp;nbsp;was in college for one year. I&amp;nbsp;was actually there for two years, but flunked most of my classes my last term (I knew I&amp;nbsp;was leaving and never wanted to come back, so didn't see much point in doing any schoolwork).</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bramcohen:62851</id>
    <link rel="alternate" type="text/html" href="http://bramcohen.livejournal.com/62851.html"/>
    <link rel="self" type="text/xml" href="http://bramcohen.livejournal.com/data/atom/?itemid=62851"/>
    <title>Sea Snakes</title>
    <published>2009-01-29T18:22:44Z</published>
    <updated>2009-01-29T18:22:44Z</updated>
    <content type="html">Earlier this week (I&amp;nbsp;think it was on Monday) I&amp;nbsp;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&amp;nbsp;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.&lt;br /&gt;&lt;br /&gt;I hadn't seen a sea snake in the water here before, so didn't think much of it, but then I&amp;nbsp;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.&lt;br /&gt;&lt;br /&gt;Unfortunately I&amp;nbsp;didn't take a picture. Were I&amp;nbsp;used to using my phone camera and had any idea how unusual it was to see that I'd definitely have taken some footage.</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bramcohen:61952</id>
    <link rel="alternate" type="text/html" href="http://bramcohen.livejournal.com/61952.html"/>
    <link rel="self" type="text/xml" href="http://bramcohen.livejournal.com/data/atom/?itemid=61952"/>
    <title>Linked Cranks Puzzle</title>
    <published>2009-01-16T00:22:17Z</published>
    <updated>2009-01-16T00:22:17Z</updated>
    <content type="html">&lt;lj-embed id="1" /&gt;&lt;br /&gt;&lt;br /&gt;</content>
  </entry>
</feed>
