Is this the first case of a company's data being sold at bankruptcy for a significant sum? I'm genuinely unsure. Where there such value in this type of data before? Is every bankruptcy manager looking at this and seeing how every bankruptcy can now raise a few million more dollars?
It's $30 off the $100 reservation fee, not off the entire price. Let's see if they manage to start delivering some finally now. There's no inherent reason you can't build something like this. Solar panels are getting more efficient over time, batteries storage gets more dense and less weight.
$40k is pretty high though. They've had endless drama and turmoil. It does take a huge amount of money and effort to bring a new vehicle to market. I'm skeptical but I guess I hope they make it.
Thats the million (billion? trillion?) dollar question. Will it get cheap enough? Will it get cheap enough to put on 100 million+ vehicles and be competitive with cameras? I honestly don't know the answer, but I haven't seen strong evidence to point to yes.
I think there is a difference between turning them off/removing and having them be stolen/destroyed. I would be shocked if they would be forced to repurchase them.
I would suggest also simplefin. Only $15/year. Its a bit more simple/restrictive (e.g. they only allow like 25 api calls per day), but if you are just doing simple personal budget tracking they are more than enough.
I spun up a simplefin sync tool recently and they made some surprising errors with some of my accounts (incorrect sign, completely missing some transactions). Also they don't do investments, which is problematic when our primary "checking" is actually a brokerage account.
I found SnapTrade[1] which gives away a free personal account with up to 20 brokerage connections (i.e. logins, not accounts).
I'm using simplefin for credit cards and loans and SnapTrade for investment accounts. Seems to be working well so far.
I wonder how many systems actually care? I presume the core NTP servers handle this well, and most systems just feed off of that?
GPS satellites probably handle it well too, but maybe some consumer or even industrial GPS receivers don't? Maybe some trading systems? I don't think crypto systems care too much.
I wonder if there's things that run 24/7 and need to be monitored.. e.g. if you have oil flowing through some pipeline at 100 liters/second, one particular minute will have 6100 liters, and someone will want to get paid for that 100 extra liters.
But the meter/reporting tool would say "Well, we measure every second, and the meter reported a constant rate of 100 liter/second, and as we know we have 60 seconds in a minute, so we got 6000 liters!".
Or a database for "measurements every second for this minute" that has 60 fields, and don't have a field for the 61st measurement.
I once worked with smart meters for electricity consumption that do run 24/7. Leap seconds were not an issue but we had a very similar one now that I think about it: DST shenanigans!
Like how much time is there between 2 and 3 am? Usually one hour, but sometimes 2 and also sometimes 0. It looks simple at first but it creates a lot of edge cases that your business logic now needs to handle and we had a fairly complex system for this.
This commenter says he has different birth dates in different countries' sytems, which is correct if you consider the exact time of birth, but... that's probably a bug? https://news.ycombinator.com/item?id=48853128
No matter what the 100 liters of mystery fluid are worth, if the pump is running continually, the billing for that day would only be off by .0011574%, so either side can probably afford to absorb the loss.
Though if it's valuable enough it could of course be "worth" paying top dollar to have engineers solve a ludicrous non-issue.
I’m horrified to imagine a blood pump or any life support system being network connected, or to rely on the precise time of day in order to function correctly. Accurate time keeping for anything in this realm can and should be done without a network.
The equation is different if the life saving surgery couldn’t be performed otherwise. Still pretty crazy and I don’t know how comfortable I’d be with it if I were the patient.
Systems definitely care, especially in finance and trading systems.
Was involved in rolling out a large NTP annealing patch about ten years ago. We missed a couple and the effect was largely overall muted, but we did have one server with an old JVM hard crashing the server right at the second shift.
That specific server was already hobbling along so it wasn't a surprise. But it required a bit of firefighting.
GPS uses its own time base that doesn't do leap seconds. For display purposes, the leap second offset to UTC is transmitted to the receivers and added to the displayed time if needed.
The problem frequently crops up in order-deterministic systems that use time and haven't accounted for the edge case of all the vagaries related to time-keeping of this being only one.
I've worked on some extremely sensitive systems that had thousands of lines of C dedicated to handling skewing a time gap across an hour-per-second when necessary. I know that code assumed only "missing" time (jump-forwards)... Even knowing what I know as a developer now, if I was re-implementing that system from scratch and didn't have this top-of-mind, I'd bet I would miss "overlapping" or "duplicate" time entirely.
Maybe that is more of a me problem than others, but I'd bet there are some safety critical systems out there where the responsible engineers, QA, and specs all missed this as well.
There are true ZKP setups where no one learns anything but the absolute minimum (e.g. is this person over 16, not what is their dob). This is hard to prove though and I don't know if I trust Google to do it
reply