(10 billion, surely?)
5,321 karma · joined September 19, 2010
However, that doesn't change my opinion that one-org-per-session and one-org-per-user is a terrible way to design an auth/auth system and Tesseral—a library/service that is trying to Get Auth Right—shouldn't design such a limitation into their system from the beginning
Of course not—I'm not sure why you'd think I mean that?
I'm just saying that if I open a link to `https://datadog.com/alert/12389` and `https://datadog.com/alert/12500` and the alerts are for different orgs, my auth cookies should be able to tell that I, as user X, have access to both orgs without having to "switch contexts" or re-auth.
From that perspective, there's no point in "killing" a cell, it's simpler to only write out the 0 -> 1 and 1 -> 1 transition cases and leave all of the other cases as implicitly 0
I don't think new auth services should encourage this pattern and I highly recommend that you remove this restriction as soon as possible before it becomes even more baked in. Your downstream services should have access to all of the orgs a user belongs to right from the beginning, using a comma-separated list or multi-value headers or something similar. Don't shard user IDs in this way.
> Yeah, sometimes, the compiler may compile a 64-bit memory access into two instructions, such as Rust, but it's not Ruby. It should be fine not consider this.
This sounds like it probably depends on the compiler or toolchain used. So Ruby compiled with LLVM would have issues with this approach, but Ruby compiled with GCC might not. Also it would be interesting to see whether yjit would affect this—it has hand-tuned assembly for 64-bit memory access.
However, I'm not sure I understand the statistical soundness of this approach. I get that every log during a given period has the same chance to be included, but doesn't that mean that logs that happen during "slow periods" are disproportionately overrepresented in overall metrics?
For example, if I want to optimize my code, and I need to know which endpoints are using the most time across the entire fleet to optimize my total costs (CPU-seconds or whatever), this would be an inappropriate method to use, since endpoints that get bursty traffic would be disproportionally underrepresented compared to endpoints that get steady constant traffic. So I'd end up wasting my time working on endpoints that don't actually get a lot of traffic.
Or if I'm trying to plan capacity for different services, and I want to know how many nodes to be running for each service, services that get bursty traffic would be underrepresented as well, correct?
What are the use-cases that reservoir sampling are good for? What kind of statistical analysis can you do on the data that's returned by it?
I don't think this is really true. I think people are often upset or surprised when their MIT-licensed programs are used in ways they don't agree with, or they reuse MIT-licensed programs in ways that violate their license terms (e.g. it takes many companies many, many years to realize they have to actually include a way for users to view copyright notices).
Open source software is built on many different fuzzy notions of community and collaboration, encoded into an imperfect-but-legally-robust set of protocols that try to establish common language for people to build on. These protocols have proven very, very successful in encouraging collaboration and minimizing exploitation, but there's still a regularization/compromise process that's necessary so that everybody has a common ground to work from.
For another perspective, think about them like security software—I personally might not know why TLS uses DH key exchange, or how it works, but if I threw it out in hopes of making thing simpler, things would probably go pretty badly for me when someone else notices.
Is it? It seems very straightforward to me—just use a DLL. The LGPL even says explicitly that it's fine as long as you use a shared library.
The situation gets trickier for Android or Xbox games I guess. I'm curious how Unity complies with the LGPL provisions there. But for any normal desktop platform this should be trivial to comply with.
EDIT: ah, upthread they mention this is only a provision for the LGPLv3. I would expect that the LGPLv3 is pretty rarely used for this reason.
Even if WIV did try to create COVID, they couldn’t have. As Yuri said, COVID looks like BANAL-52 plus a furin cleavage site. But WIV didn’t have BANAL-52. It wasn’t discovered until after the COVID pandemic started, when scientists scoured the area for potential COVID relatives. WIV had a more distant COVID relative, RATG-13. But you can’t create COVID from RATG-13; they’re too different. You would need BANAL-52, or some as-yet-undiscovered extremely close relative. WIV had neither.
Are we sure they had neither? Yes. Remember, WIV’s whole job was looking for new coronaviruses. They published lists of which ones they had found pretty regularly. They published their last list in mid-2019, just a few months before the pandemic. Although lab leak proponents claimed these lists showed weird discrepancies, this was just their inability to keep names consistent, and all the lists showed basically the same viruses (plus a few extra on the later ones, as they kept discovering more). The lists didn’t include BANAL-52 or any other suitable COVID relatives - only RATG-13, which isn’t close enough to work.
Could they have been keeping their discovery of BANAL-52 secret? No. Pre-pandemic, there was nothing interesting about it; our understanding of virology wasn’t good enough to point this out as a potential pandemic candidate. WIV did its gain-of-function research openly and proudly (before the pandemic, gain-of-function wasn’t as unpopular as it is now) so it’s not like they wanted to keep it secret because they might gain-of-function it later. Their lists very clearly showed they had no virus they could create COVID from, and they had no reason to hide it if they did.
COVID’s furin cleavage site is admittedly unusual. But it’s unusual in a way that looks natural rather than man-made. Labs don’t usually add furin cleavage sites through nucleotide insertions (they usually mutate what’s already there). On the other hand, viruses get weird insertions of 12+ nucleotides in nature. For example, HKU1 is another emergent Chinese coronavirus that caused a small outbreak of pneumonia in 2004. It had a 15 nucleotide insertion right next to its furin cleavage site. Later strains of COVID got further 12 - 15 nucleotide insertions. Plenty of flus have 12 to 15 nucleotide insertions compared to other earlier flu strains.
COVID’s furin cleavage site is a mess. When humans are inserting furin cleavage sites into viruses for gain-of-function, the standard practice is RRKR, a very nice and simple furin cleavage site which works well. COVID uses PRRAR, a bizarre furin cleavage site which no human has ever used before, and which virologists expected to work poorly. They later found that an adjacent part of COVID’s genome twisted the protein in an unusual way that allowed PRRAR to be a viable furin cleavage site, but this discovery took a lot of computer power, and was only made after COVID became important. The Wuhan virologists supposedly doing gain-of-function research on COVID shouldn’t have known this would work. Why didn’t they just use the standard RRKR site, which would have worked better? Everyone thinks it works better! Even the virus eventually decided it worked better - sometime during the course of the pandemic, it mutated away from its weird PRRAR furin cleavage site towards a more normal form.
COVID is hard to culture. If you culture it in most standard media or animals, it will quickly develop characteristic mutations. But the original Wuhan strains didn’t have these mutations. The only ways to culture it without mutations are in human airway cells, or (apparently) in live raccoon-dogs. Getting human airway cells requires a donor (ie someone who donates their body to science), and Wuhan had never done this before (it was one of the technologies only used at the superior North Carolina site).This would be a non-issue if some kind of simple origin-authenticated token exchange was built into the protocol itself.