Also interesting: if you look at the acknowledgements of Hauptmann's paper (at the end, just before references), he says, "I would like to thank Norbert Blum for carefully reading preliminary versions of the paper, for helpful remarks and discussions, for his guidance and patience and for being my mentor." This means Blum knew about this past attempt and presumably thought it correct enough to put on arXiv. I assume from the current paper that he has changed his mind since then.
Having worked worked in both quantum information and biology, I have a few things to say about this article...
1) The 1st paragraph really annoys me. Quantum computers don't solve NP Complete problems by trying every solution. This is a common misconception. In fact, it's widely believed that quantum computers wouldn't solve NP-Complete problems in polynomial time, though they may get a moderate speedup over classical computers related to their superior searching capability.
2) The biological computer in the article also doesn't solve NP problems in polynomial time. Rather, it proposes a highly parallel machine that divides runtime by a very large constant. The real claim is to make a low-energy parallel processor that makes it easier to throw lots of processors at the problem. It does not alter the complexity classes. The linked PNAS article states, "it is inherent to combinatorial and NP-complete problems (assuming P != NP) that the exploration of the entire solution space requires the use of exponentially increasing amounts of some resource, such as time, space, or material. In the present case this fundamental requirement manifests itself in the number of agents needed, which grows exponentially with 2^N. Effectively we are trading the need of time for the need of molecular mass." Unfortunately, the experiment hasn't quite got this far, since "the error rates of this first device are too large for scaling up to problems containing more than ∼ 10 variables." It may constitute a step in the right direction, though.
3) The popular science article (as opposed to the original research it links to) is probably too focused on trying to make this about P vs. NP and misses the actual accomplishment: that the researchers can control a microbiological system outside of their own brains well enough to compute with it. This is pretty cool and may be valuable progress in nano/biotech even if it doesn't end up being a viable computer.
I recently had some ideas about how to use the concept of locality-sensitive hashes with thread/worker pools that share locking resources. Basically, it's useful when want things which are going to take write locks on the same resources to end up on the same thread, since otherwise you are just needlessly blocking up extra workers waiting for other workers to finish. Also, in the case of having multiple actors with independent task queues, you can send tasks using a particular resource to the same queue, so that they will be processed in the same order they were received.
There are probably better ways to do this in most cases, but I thought it an interesting idea.
Hopefully, the hashes are physically secure and accessed in a way that would require a great deal of human effort to steal. If that is the case, then yes, you can control the login process.
The technique in the article is relevant when one has the hashes and wants the plaintext (and according to some here, still easy to mitigate then) - if you're guessing a web login, different game.
These terse responses are always open to misinterpretation, especially by non-technical users who may not fully understand open source. That's the problem. "We have a backlog, but you're welcome to contribute to speed things up," or "I do this as a hobby, so take it or leave it," at least expresses some reasoning.
For paying a bounty, yes, assuming it can be arranged in a timely fashion.
For the latter, probably not. Assuming that for whatever reason I cannot write the patch myself, I do not have the time to start a new organization every time I encounter a new bug in some project. And I would guess that most ordinary consumers don't either.
This is not supposed to be a necessarily snarky response. Sometimes, an open source project exists, and it's not for everyone. The people behind the project should realize that every feature they choose not to include cause the software's value proposition to cease to exist for some users. It is up to them what to prioritize, and up to me whether using their software is worth the time of getting a patch committed.
Of course, my operating assumption here is that they want to hear about bugs/feature requests, and so it is worth something to them that I would bring it up in the 1st place. But I rarely ever make new feature requests. Usually this is in response to an evangelist telling me that I should switch to their platform, and my responding that it does not replace a current proprietary solution.
"Unfortunately, I don't have time to learn this system and work my way through your review process. I think I'll have to buy [insert (possibly proprietary) alternative] for now. Best of luck with the project."
For the record, I have written a couple patches and released open source code before. I say this after years of trying to convince all my friends to switch to Linux, and finally coming to terms with the fact that even I still have to keep a Windows boot for certain occasions.
Compounding this problem, conventional security wisdom is that you should never acknowledge unsolicited email, because the spammer might be using a fake unsubscribe link to confirm your email address is real. So a system that requires manual unsubscription this way will actually punish accidentally subscribed users for following good protocol.
Furthermore, if the "confirmation" email winds up in a spam filter and the user never sees it, subsequent emails will still go out and probably be auto-marked as spam.
You can build stuff. In this economic climate, that gives you an advantage in cofounder negotations, as there's a huge supply of unattached business people floating around.
I've been in a vaguely similar position. Don't freak out, and don't think of yourself as desperate. Don't settle. Don't rush things either. University is a great place to meet people who could become cofounders, so meet people.
From my time as a volunteer high school tech support helper, I remember the first year that Dell shipped us laptops without the external floppy drives. This was annoying to many of the old-timers who had established techniques around booting from a floppy.
We got over it.
We don't understand touchscreens well enough yet. We are using an old metaphor (the keyboard) and porting it completely literally. We might never replace the keyboard fully, but surely there is room to innovate.
With the huge amount of publicity and increased likelihood that more older entrepreneurs will apply, the probability of acceptance for some teams may decrease so much as to reduce the average return on investment. $150k seriously opens the space to entrepreneurs with a family to support and may draw out people who were previously hesitant to turn down a 6 figure salary. If experience grants a significant advantage, the just-out-of-college startups may find their acceptance probability approaching 0 and jump ship for smaller, easier sources.
I still plan to apply for this round but shall monitor the kind of startups YC funds in the future to determine how the probabilities change. It depends on how the selectors respond to changes in the applicant demographics.
I've never sold a company, but I've dealt with a couple of pretty questionable cofounding/employment contracts lately, and making a deal seem "very much like a standard-fair offer" seems to be an old trick. I had someone tell me they'd been using an agreement for years when there was an obvious typo and font change to show me it had probably been altered at the last minute.
I applied for internships at both companies. Google actually mentioned in their rejection email that I should feel free to ask questions - so I did. No answer.
With Facebook, I at least had a phone interview and could run post-mortem on what I might've messed up there. Google appeared to just toss my resume down a black hole.
I later decided that really, I didn't want to be a programmer, I wanted to found a startup. I was still in school and not 100% sure of myself at this point, so I applied to 1 programming job at a small place in Connecticut. I got a phone interview and then a rejection. I blamed my "failure" then on my lack of interest probably showing through.
Sadly, I had the same null feedback experience with many seed funders that spring. Most of the time it was a black hole. 2 (Lightspeed and IO Ventures) of them gave a brief explanation, which matches some (but not all) of my own post-mortem analysis. I think that given the high probability of rejection, rejection feedback significantly increases the value of applying.
While I don't think rejection from a place like Google is necessarily "random," I would certainly agree that it rarely provides actionable info.
I'm still not sure why I upvoted this. I think because it was surprising - high entropy. I'm not sure if I consider this "right," but you have definitely made waves.
My first hypothesis is that it's a question of comparative opportunity cost, rather than absolute cost.
When a company gets very large, it usually struggles to keep innovating under inertia. Trying to build in completely new directions becomes both necessary and difficult. Buying a startup is often cheap compared to trying to fork an existing team to build new things. Furthermore, the startup's business model is already partially proven by time of acquisition - so they are buying some certainty compared to assigning a team to generate new ideas.
Another hypothesis is that with the resources of a large company behind it, the startup may grow very fast. Adobe seems to be good at this. Other companies don't seem as good at managing post-acquisition.
I have never been in or acquired by a large company, however, so what I say should come with a grain of salt.
What surprises me (and makes me most skeptical) is that they can remember days by date. Did these people actually know what the date was every year of their lives? This implies to me that it is not just a camcorder-like memory that these people possess, but an efficient, numerical search ability on those memories. It makes me wonder how much one could duplicate this ability by purposefully associating numbers with days in a hierarchical structure (analogous to building an explicit tree structure on them).
Also fascinating to me is how this links with OCD-like behavior. My memory has always been considered very good (though not like these people), and I had extremely mild OCD during my preteen years, which changed its form when I became a teenager until I stopped manifesting most symptoms.
I also wonder what would happen if these people were asked to gather days by an arbitrary filter. For example, on which days during 1999 did it rain? Would they have to step through day-by-day and check each day, or would they be able to instantly run through the rainy days? The latter seems almost too powerful.
This is an attitude that some recruiting startups like us all to believe, but even as a naive and inexperienced 22 year old, I think it's dangerous. I've had a startup implode, and it's nasty in ways one never expects - joining a startup is one of the easiest ways to ruin a relationship. You may love the work you expect to do, but a startup will throw you curveballs until you are sick of them. If you are willing to take crummy compensation because you love the team, think about what happens when they have an opportunity to discard you like used tissue - if they don't think you're worth a decent equity stake, they probably won't hesitate to.
You have to ask yourself if you couldn't gain better experience by a) working for a big company b) going to grad school c) founding your own startup. There might be cases in which the underpaying startup job really is the best next-stage career advancer. Even if this is true, read any non-compete agreement very carefully. I've had people shove non-competes in my face before telling me what the company actually did (so I could not compete with the entire industry? No thanks).
I would also not go in assuming that the company will be the next Facebook. Find out how the founders and investors plan to exit, and decide if that's acceptable to you. Furthermore, make sure you can deal with failure.
I think going in with realistic expectations and a clear head is just as important to the startup one wishes to join. I suppose there are some startups (many in NYC) whose goal is to suck in naive techies and dump them when they burn out, but most probably want to build a real team. If you sign something based on unwritten expectations, you are setting up for resentment and conflict when those expectations go unmet.
I probably sound overly pessimistic now, but I don't mean to be. Joining a startup can be a great opportunity in innumerable ways. I still intend to launch, even after some of the worst months of my life. Many of my friends who shared this sentiment no longer do. I think some had naive expectations about the lifestyle, how quickly we'd all be rolling in money, and what being an "entrepreneur" would look like to the rest of the world.