Bram Cohen's Journal

Someone at Mozilla Foundation needs to be fired

Thu, 09 Jul 2009 22:47:15 GMT

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.

Ludology in City of Heroes

Tue, 07 Jul 2009 18:47:27 GMT

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.

Bandwidth fundamentals

Mon, 06 Jul 2009 23:26:56 GMT

A random person asks about something they read on Wikipedia:

Example from wiki below:

http://en.wikipedia.org/wiki/Bram_Cohen

quote from site:

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 "peer"). 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.

This explanation was lifted from an actual new article, which doesn't necessarily mean it's true. In fact, it's somewhere between grossly misleading and wrong.

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.

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.

The Uncanny Cube

Mon, 06 Jul 2009 21:51:49 GMT

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.

Bram's Cube

Fri, 03 Jul 2009 16:48:22 GMT

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.

New Puzzles - Bram's Black Hole and Fairly Twisted

Mon, 15 Jun 2009 14:58:44 GMT

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.

Puzzle Ring tweaking

Mon, 08 Jun 2009 21:12:59 GMT

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___
    \ /   \ /   \ /   \ /   \ /   \ /
     /     /     /     \     \     \
____/ \   / \   / \   / \   / \   / \   ____
       |  |  |  |  |  |  |  |  |  |  |  |
       \ /   \ /   \ /   \ /   \ /   \ /
___     /     /     /     \     \     \_____
   \   / \   / \   / \   / \   / \   /
    \ /   \ /   |  |  |  |  \ /   \ /
_____/     /    \ /   \ /    \     \________
      \___/ \    /     \    / \___/
             \__/ \___/ \__/

Kite wind power

Mon, 01 Jun 2009 06:03:31 GMT

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?

Maybe goto isn't so bad after all.

Mon, 01 Jun 2009 05:11:25 GMT

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.

Geary Cube

Fri, 29 May 2009 05:04:38 GMT

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.

CodeCon 2009 now streaming live

Fri, 17 Apr 2009 23:43:25 GMT

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

CodeCon 2009 starting Tomorrow

Fri, 17 Apr 2009 01:03:39 GMT

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

I'm twittering

Wed, 08 Apr 2009 19:42:36 GMT

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.

The End is Nigh

Sun, 05 Apr 2009 17:13:10 GMT

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.

Codecon

Wed, 01 Apr 2009 15:33:25 GMT

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.

Rotacubes

Fri, 27 Mar 2009 19:14:54 GMT

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.

CodeCon 2009 Program Posted

Mon, 23 Mar 2009 19:36:27 GMT

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!

version control tidbits

Sun, 01 Mar 2009 08:04:09 GMT

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.

Trigears video

Wed, 25 Feb 2009 18:00:27 GMT

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.

Bram explains unix time

Tue, 17 Feb 2009 20:10:07 GMT

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.

CodeCon deadline coming up

Fri, 13 Feb 2009 23:20:30 GMT

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!

Corrections

Wed, 11 Feb 2009 01:12:04 GMT

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).

Sea Snakes

Thu, 29 Jan 2009 18:22:44 GMT

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.

Linked Cranks Puzzle

Fri, 16 Jan 2009 00:22:17 GMT

CodeCon Call For Papers out

Tue, 13 Jan 2009 23:56:17 GMT

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.