You make a very good point. But the other side of it is that sometimes it goes poorly. The vaccine could have some previously unknown bad reaction with the Keytruda and the numbers get 44% worse instead. In this case it would be better to be in the vaccine group, but that's not guaranteed.
If you've read the docs, which I'm not saying anyone is expected to, FTDI tends to put buffers on their outputs. That's what gave it away for me. The little sot-23-5 footprints.
I got it backwards because I expected the counterfeit part to use a newer process IC (less silicon area) than a possibly more reliable and perfectly suitable for serial connection speeds 'vintage' process on some long stable spin of silicon.
Why allow for newer processes on the counterfeit? They'd implement it using the least expensive, most mass produced chips possible, which are more likely to be cut from wafers hitting the sweet spot of size / feature and price crossover.
I work near space but not in space. I'm not sure I understand your process here. I see 2 possibilities: 1. You bought something the manufacturer spec lied about. While true we often validate specs, our terrestrial stuff is a lot cheaper so we can afford the spares. That said, if we buy something that doesn't meet the spec, you best believe we're taking the actions necessary. 2. This was built or designed inhouse, and the requirements didn't flow down correctly. That's also not great.
To be honest, postmortems (especially from startups) toe a fine line of scaring off investors, and this write-up seems a bit too glaze-y. I'm very happy for you that so much worked so effortlessly post launch, but that's more a success story than a postmortem. I'd like to see more of the root cause analysis for the issue, both technically and programmatically.
To be certain, if you're in the trenches of this anomaly investigation you'll get the full root cause and corrective action presentation, but that's not what this post is for.
You're correct on 1, we ended up hitting an edge case in their spec that they hadn't adequately tested to and the upper level management and engineering leadership were swift to accept the fault and implement fixes with us going forward.
From a SE perspective, as a "COTS" product, we had spec'd correctly to them, they accepted our requirements and then executed each unit's acceptance test plan (aka lower level than first unit quals or life tests where this should have been caught) on the ground without anything amiss. We ran through our nominal and off nominal cases at the higher level of assembly, but not for a duration that caught this on the ground. It wasn't until we were at extended operation on orbit the issues began.
Sadly like you state, space isn't like on the ground, you can't buy spares or replace things that fault, even for a true high volume COTS product that might slip through the acceptance testing.
> We ran through our nominal and off nominal cases at the higher level of assembly, but not for a duration that caught this on the ground. It wasn't until we were at extended operation on orbit the issues began.
So I think that's a great answer. It's all about risk mitigation and tolerance. Your test tested if the part work to a reasonable and hopefully calculated level. It's good that the suppliers' management accepted fault, too. It's a lot harder when they don't but honestly in the professional world I've found that to be much rarer than consumer.
To me, and I'm not an investor, and probably not your target audience, those 3 short paragraphs told me a lot more in a positive way than I expected. I don't think it would be out of place to put it in the post. Honestly as is I thought this was your guys' fault for myriad reasons. Now I'm flipped the other way. Of course it's still your problem even though it's not your fault. Or, maybe, you do claim some blame for the worst case analysis not shaking out that edge case. Either way I feel much less like you guys just went to the hardware store, bought some random lube, packed the bearing, and shipped it thinking you'll figure it out on the next launch (which is sadly the fast and loose reputation new space is starting to get).
Right — the network database is also doing O(N) work to return O(N) results from one query but the multiplier is much lower because it doesn't include a network RTT.
I think they're trying to not shame other services, but yes the comparison is vs networked whether that's local on loopback or not. For a small query, which is what they're talking about, it's not inconceivable that formatting into a network packet, passing through the userspace networking functions, into and through kernel, all back out the other side, then again for the response, is indeed meaningfully slower than a simple function call within the program.
1. Read the datasheets. Some parts only support certain frequencies, so find the minimum of the master and slave frequencies.
2. Check at boot. Most devices boot slowly for the first few transactions then speed up. So if you saw valid data then aliasing, get a better kit.
3. Start high. I think the fastest serial memory devices cap out at 250 MHz DDR for volatile and 200 for non-volatile. So even a digital discovery (which I think is the best LA for high speed bursts) can deal with it
You can run zoom in the browser. At least you could some years ago. Encryption is relevant depending on what you're doing but not everything needs to be super secret. A common practice is to email or use secure file shares while on the call to maintain that security.
You can still. There's a small dark pattern to discourage it, though. You go to the URL for the call, click the button to launch the app, and when that fails, you see a small link to do the call in the Web browser.
every once in a while, someone will ask me to screenshare on a shared monitor, then i will have to explain i cannot , because i am on zoom browser.
Its always great to see the reactions that gathers. Its a true rainbow: bemusement, curiosity, exasperation, outright suspicion...and everything in between!
I already have Zoom installed on the work computer but for some reason it has started doing this weird thing where every time I click a Zoom meeting link in Google Calendar, Google Chrome downloads a copy of the Zoom installer at the same time as it opens the already installed Zoom. I didn’t notice until I already had six recently downloaded copies of the installer in the Downloads folder.
No idea why this happens. But it’s probably part of the crappy pushiness of Zoom to get people to install their app that makes them trigger a download of the installer because either they are not detecting that Zoom is already installed at the right time, or they are so eager to download the installer that they don’t even care about whether or not you already have it installed.
I’ve disliked Zoom since the beginning for their antics, and the only reason I have it installed is because I have to for the meetings at work, and the work computer belongs to the company I work for anyway, not to me.
I had to do it once and is extremely difficult, I don’t remember the details but I think you have to do dozens of extra steps on your account configuration and it won’t work on your phone unless you request the desktop version of the website.
Click on the meeting, where you will land on a download landpage. Then click the big download blue button in the center of the screen. WHen you click it a link will appear in the 2nd row below the blue button, something like "continue from browser", click on that, and you are golden
You can also install and run Zoom in FlatPak which secures your computer by running the executable in BubbleWrap. If you know what you're doing, you can also sandbox it directly.
Might give this a try to experiment if it's really free to use (I'll have to read up on that I guess). The qemu codebase is huge and every contributer seems to solve problems in slightly different ways. Would be nice if this tool could help distill it.
Seems like a typo when covering inversion. They claim parity(0) = 0 but still use the equation with != from before.
It's nice to see that they, like me, subscribe to "an hour of experimenting can save 5 minutes of reading the documentation." Of course what people often fail to realize is that until you've found the answer, you often don't realize what the documentation was saying, such as the 16-bit thing. Management may ask "was that not in the manual?" But it's more nebulous than that.
reply