Why can't RT-PCR tests be used to detect virus in a sample mixed from a large number of individual samples? This would enable cheap and accurate mass testing, since you can find P positives from S samples with O(P*log(S/P)) tests. What's the catch?
1,781 karma · joined July 17, 2009
Co-founder of Antithesis
Co-founder of FoundationDB
Co-founder of Visual Sciences
The CDC developed a testing protocol (crudely, a set of 3 conserved RNA sequences of the virus to chemically "grep" for). The protocol is here [1] and I think anyone with suitable equipment (an RT-PCR machine and an oligonucleotide synthesizer to make the primers and probes?) could run tests using just the information on that web page, though they would probably also want known positive samples of the virus to validate against. And there are lots of labs with suitable equipment. But as that page says, it is not legal to do this clinically.
The CDC also sent out test kits [2]. These are just vials of primer/probe pairs synthesized from the short sequences on the above page, and a fake positive control to validate with. These were authorized by the FDA, and so are legal to use. But apparently somehow they screwed up the production of primer #3 (or maybe the sequence itself is wrong), and so almost all the labs were not able to validate the test. After several weeks the CDC has still not fixed this problem, but labs are now allowed to run tests using just primer 1 and 2, so testing capacity is rapidly increasing (though of course who knows how sensitive or specific the tests are).
The federal organization preventing labs from running tests is the FDA [3], not the CDC. It is also the FDA who would have to approve the commercially produced test kits.
[1] https://www.cdc.gov/coronavirus/2019-ncov/lab/rt-pcr-panel-p... [2] https://www.fda.gov/media/134922/download [3] https://www.fda.gov/emergency-preparedness-and-response/mcm-...
There is also the option of actively attacking the business model of the ad and tracking industry. Ad blockers could simulate lots of "fake" traffic to make ad analytics harder (this is another arms race against attempts to filter out the fake traffic)
An algorithm M is described that solves any well-defined problem p as quickly as the fastest algorithm computing a solution to p, save for a factor of 5 and low-order additive terms.
(The constants in the "low order" terms are... large. Basically this is a delightful reductio of asymptotic analysis)
There are probably lots of huge differences between NNs and brains but this article is really making the case that the brain can be modeled as a big NN, just with a few thousand times more activations than neural cells.
Language based security like WASM can prevent untrusted code from receiving timing channels, but only by executing it absolutely deterministically and denying it anything that can be used as a clock, which definitely includes shared memory multithreading. So you would not be able to run anything originally multithreaded, except perhaps by heroic measures like a continuation passing lowering of fibers. If the code has any way to measure the passage of time, there is presently no known way to prevent it from using Spectre to read the whole memory of the process it is in.
On the other hand process sandboxing can rely on defenses provided by the operating system and hardware. These are not IMO as absolute as deterministic execution, but they are better than nothing if it's not practical to run the untrusted code deterministically.
Thus you see for example Chrome shifting its security model in the direction of assuming that anything mapped in the same OS process as untrusted JS or WASM has no confidentiality. I personally think it would be better, given the historically very limited access of JS to synchronous timing channels, to go for perfect determinism in that context. But definitely there are use cases where that isn't practical, so there is a place for process sandboxing. It also makes for a second line of defense - you can run your wasm vm inside your process sandbox, and an integrity failure of either one is not fatal!
As another example, the original code could have been writted with a multiset< unique_ptr< Employee > > and a suitably modified comparator and not required any const casting to have the same undefined behavior as the original (you can access a mutable object through a const unique_ptr).
"It is impractical because it is a descending spiral ending in destruction for all. The old law of an eye for an eye leaves everyone blind."
Try this:
If standard vesting terms make you nearly indifferent to your co founder leaving, or to being fired, then they are perfect for you and you should definitely go for it.
Otherwise, you want some other kind of agreement with your co founders. It's not likely that the ideal agreement is one you can enforce through the weak economic incentives you can put in your corporate agreements (constrained by enforceability, tax considerations, what would totally freak out later investors or acquirers, etc). You will just have to rely on loyalty, integrity, etc. And it's fairly well known that adding weak but salient economic incentives to strong moral ones has a perverse effect. I don't think I can explain this any more clearly.
(And if you can't completely trust your partners, why worry about them leaving, but not about them colluding to fire you and repurchase a bunch of your stock? And isn't the prospect of a high stakes negotiation that could blow up your company a stronger incentive than losing some predictable fraction of equity?)
No matter what you do, there will be risks. I think what balance of risks is best depends on you, your partners, and your situation. We are in full agreement that you should address this issue, in one way or another, early.
(It hasn't been that long since I've raised money from a "real VC", but who knows? I'm happy to leave that out of the conversation)
To give a related example, I've sold a company to an acquirer for whom the deal was extremely material, and for whom I was a very key employee, who tied me down for two years with nothing more or less than a promise and a handshake. They were smart: I was far less likely to leave during that time than I was after another acquisition where I had big golden handcuffs.
(Also, I have trouble understanding the "10 years later" scenario. Is the assumption that there's a founder breakup and... everyone just forgets about it and goes about their business? THAT sounds nuts.)
There are good reasons not to do it too. If you work with good and honorable people, who have kept their promises to other people in their life, and who have (incredibly valuable) reputations as honest people to protect, they are pretty likely to keep their promises to you too. (Don't forget to actually discuss these promises!) Unless you unnecessarily move the decision to leave into the category of "rational economic decision" by putting a price on it. (And four years later, when that price has decreased to zero?)
Another reason is that you might trust your cofounders more than your possible future investors (they have reputational incentives too, but you don't know them yet!), and prefer not to give the latter a possible avenue to steal the company from some or all of you.
Sometimes there can be tax tradeoffs, depending on what else you are doing.
As I said, it might be a good choice to have vesting in many or even most circumstances. Everyone should carefully consider it. But "always no matter what" is not good advice.
That's not what everyone is going for.
There are advantages and disadvantages to founder vesting and they are situational. Recommending it as a default may very well be good zeroth order advice for beginners, but your position is way too strong.
A start on thinking about why it might not always be the best way to keep a team together is to look up the "israeli day care study".