Agreed. I also thought it was a very dumb move until I saw that. That said, 3% but it costs 2.5x as much, maybe people option them higher idk, that could be a 10% revenue hit. But maybe that's worth it for them
If they just canceled the S and X I don’t think people would be making quite as much fun.
Saying they’re dropping two products that aren’t profitable so they can make a new product that most people seem to think is a complete joke is the problem.
I feel like if I ever used an agentic AI that's how I'd need it to be done. Too many cases of AIs getting access to files that it shouldn't. But then then, how do I allow it to look things up online without sending all my code to some scammer that prompt injected on a tutorial? I don't think I'll ever trust it with anything proprietary or otherwise less than publicly available.
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
reply