To me it seems like it's depicting a situation where the string hasn't been pulled fully, so some of its slack hasn't straightened out into the otherwise resulting triangle yet.
Is that true? It seems that our eyes are mechanically capable of looking in divergent directions, what's the reason that we're not able to "uncross" them beyond looking straight ahead?
(Edit: Anecdotally I can confirm for myself that I'm not able to do it, so wondering if there's anyone that can.)
From a control system standpoint, if you have one control that rotates both eyes the same number of degrees left or right to determine gaze direction and another to rotate both eyes the same (positive) number of degrees inward to control fixation distance, you can't specify the left eye rotated left of center and the right eye right, even if each eye physically can rotate that way. Not sure if that's how eyes actually work though.
To save others the click: Their issues were simply that Swift has no fast JSON impl, and in Rust, when using serde (most popular library handling JSON marshalling), it leads to binaries getting a bunch bigger. That's it. So yeah, same perspective -- unless either of the above matter in your case (in 90%+ of cases they don't), JSON is just fine from a perf perspective.
Serde is a rather chunky dependency, it's not just a matter of binaries getting bigger, but also compile times being dramatically slower.
IMO CBOR would be a better choice, you aren't limited to IEEE 754 floats for your numeric types. Yeah, some (de/en)coders can handle integer types, but many won't, it's strictly out of spec. I don't think building something as fundamental to an OS as relying on out-of-spec behavior is a great idea. It will result in confusion and many wasted hours sooner or later.
> CBOR would be a better choice, you aren't limited to IEEE 754 floats for your numeric types.
The other side of this coin, of course, is that now you have to support those other numeric types :) My usual languages of choice somehow don't support "negative integers in the range -2^64..-1 inclusive".
I mean, you don't have to support those? You still would need something on the other end to produce that type of datatype, which can be documented that it will never happen: you're making an interface anyways. The problem is if you literally don't have the option to represent common datatypes it will be a problem, not a hypothetical one just because the encoding layer can support it. Those are different problems.
And JSON, technically, allows use of unlimited-precision fractions, but also allows implementations to set arbitrary limits (it actually does, you're not required to parse JSON numbers as doubles). So the situation is not really different from CBOR, isn't it? Just™ make both sides to agree to stick to some common subset (e.g. integers-in-int64_t-range-only for some fields) and you're done; no need to support double-precision floating point numbers.
Huh, I went and referenced the ECMA JSON spec and you're right that it treats numbers only as sequences of digits which would make these effectively the same problem
Not true, not sure why GP said that. Been writing Rust for many years and code does not just break on compiler upgrades. Super stable overall, including the wonderfully evolving ecosystem!
They just changed the assignments of what tapping the right stalk once vs twice does -- before, once brought you into cruise control and twice into autopilot. After the change, that order is reversed by default, but you can change that from the settings.
I think at some point the absurdity of the numbers (now it's 2M, soon it'll be 10M, 50M, ...) will become so great that NHTSA will stop calling this a "recall", and then this term will no longer be usable for clickbait article titles. Absurdity because it'll get harder and harder to imagine how a company might bring in millions and millions of vehicles in for service repeatedly, from a logistics and cost perspective, and still be able to grow and make a good profit.
>and then this term will no longer be usable for clickbait article titles.
It's not clickbait, that's ridiculous. The essence of the article is the results of the investigation. NHSTA has a process, they investigated and issued a recall. The fact that it can be fixed OTA doesn't change the intent of what's happening. I mean, at what point does the first comment stop being, "It's not a recall!" Who cares.
I'm more interested in the obvious questions, like: does the update actually make anything safer? If it's so easy, why didn't Tesla do it on their own?
> If it's so easy, why didn't Tesla do it on their own?
It's situations like this that make me not trust Tesla and Musk. I always feel like they're misrepresenting the vehicle's capabilities, and I have no idea what I'm actually getting in terms of autopilot capabilities.
When I rode in a friend's Tesla, the real time display of the sensors did not inspire confidence. It missed a lot of cars and pedestrians.
I think the technology has a lot of transformative potential, but between their continuous hype over substance, ripping out lidar to be cheap, etc., it's just really hard to trust them.
> I'm more interested in the obvious questions, like: does the update actually make anything safer? If it's so easy, why didn't Tesla do it on their own?
Tesla has advertised many features which do not work reliably or, in some cases, at all. If they don’t want to admit that, they’re going to resist - especially if it’s going to fuel a class action lawsuit claiming that this feature is not in the state it was sold as.
The NHTSA does not have that conflicting set of incentives.
NHSTA needs to reevaluate the usage of “recall” in situations where nothing is being physically recalled to the manufacturer’s facilities. It is only confusing people.
There are much clearer ways to phrase what has occurred like “Regulators force Tesla to issue mandatory OTA update to address issues with auto pilot”
Sorry, but do all teslas have starlink or whatever satellite provided connections? Are all cars connected to the internet? Until that happens, I want a recall that _can_ be fixed by an OTA update called a recall.
Because for sure my parents' next car will have OTA capacity, but also be disconnected by my dad. If it needs a software update, that vehicle will be driven to a garage. If you don't issue a recall anymore, it'll be dangerous.
It is clickbait. Tesla hasn't "recalled" 2M vehicles, they're pushing a software patch. "Recall" is specifically jargon. It's a regulatory action. However (and this is precisely why this headline is clickbait) it has an alternate, more common meaning to the general population, which is "your car has a defective part, is unreliable, and needs to be brought in to have that part replaced."
This is a "recall" the same way your code needs a "recall" when you find a bug. It's not.
You not being aware of the use of the term doesn’t mean it’s clickbait. All a recall means is that the NHTSA is using its legal authority to have Tesla ensure that all vehicles with a safety concern are fixed. If Tesla can ship an update that easily, they can send the NHTSA a report showing each VIN having been verified as having the right firmware version.
Tesla gets to address recalls via OTA software updates right up to the point where they can not. Then, as you note, 2M+ vehicles needing physical replacement parts or rework will kill them because they have no way to do that. EVs are simple enough that they might avoid that scenario entirely.
But imagine one of those massive castings developing cracks and needing some reinforcements welded on in the field, or really any part. FEA is probably the most important tech that Tesla is dependent on.
You're not alone, I do that too sometimes! But I've also found that most people have a hard time doing or following along with something like that. Possibly because in the end it does require a whole lot of skill in using git, because you will usually want to rewrite history in some ways, and large numbers of developers are very uncomfortable with that.
