Because 2022 is when FSD 11 was released, which dramatically reduced interventions per mile and is largely regarded as the "step function improvement" release that demonstrated unambiguously that mass-market autonomy was real and coming.
> Always remember that Full Self-Driving (Supervised) (also known as Autosteer on City Streets) does not make Model Y autonomous and requires a fully attentive driver who is ready to take immediate action at all times.
> Full Self-Driving (Supervised) is a hands-on feature. Keep your hands on the steering wheel at all times, be mindful of road conditions and surrounding traffic, and always be prepared to take immediate action. Failure to follow these instructions could cause damage, serious injury or death. It is your responsibility to familiarize yourself with the limitations of Full Self-Driving (Supervised) and the situations in which it may not work as expected.
> Model Y may quickly and suddenly make unexpected maneuvers or mistakes that require immediate driver intervention.
The list above represents only a fraction of the possible scenarios that can cause Full Self-Driving (Supervised) to make sudden maneuvers and behave unexpectedly. In fact, Model Y can suddenly swerve even when driving conditions appear normal and straight-forward. Stay alert and always pay attention to the roadway so you can anticipate the need to take corrective action as early as possible. Remember that this is an early access feature that must be used with extra caution.
Telling that Waymo is trying to steal the thunder by releasing this news on the same day as Tesla's Q4 earnings report. They see the competition about to overtake them.
Rust literally bakes data race safety into the language. While it does not resolve general race conditions, thread safety issues which cause memory unsafety (which an UAF or dangling pointer would be) are very much within its remit.
Can someone explain in unambiguous terms why people are so drawn specifically to TikTok? I have tried TikTok, Instagram Reels, and YouTube Shorts, and they are all basically the same--algorithmically-driven feeds of short videos. I don't see how banning TikTok is such a big problem, just use one of the other apps.
Why, after all these years, are we still doing this stupid thing of using a global namespace for packages? If you are a company with an internal package registry just publish all your packages as @companyname/mylib and then no one can squat the name on a public registry. I thought we collectively learned this 4 years ago when dependency confusion attacks were first disclosed.
The usual reasons: laziness, ignorance, poor design. Most package managers suck at letting you add 3rd party repos. Most package managers don't have namespaces of any kind. The ones that do have terrible design. Most of them lack a verification system or curation. Most of them have terrible search. None of them seem to have been exposed to hierarchical naming or package inheritance. And a very small number of people understand security in general, many fewer are educated about all the attack classes.
But all of that is why they get popular. Lazy, crappy, easy things are more popular than intentional, complex, harder things. Shitty popular tech wins.
What is the point you're trying to make here? Are you waiting for some malware that exploits a buffer overrun to infect you before conceding that C/C++ is a terrible choice for memory-safe code?
What motivates this attitude? Software, like anything else, needs to be actively maintained. This is a positive sign of technology evolution and improvement over time. To expect to run some software for 20 years without needing to apply a single security patch is ridiculous, and probably exactly the attitude that caused the author to get himself in this situation.
> To expect to run some software for 20 years without needing to apply a single security patch is ridiculous
The whole point of my comment is that it's only "ridiculous" because of path dependency and the choices that we have made. There's no inherent need for this to be true, and to think otherwise is just learned helplessness.
Better security design fixes this. Sandstorm fixed this for self-hosters ten years ago (Sandstorm is designed to run unmaintained or actively malicious apps relatively safely), but people are still choosing the quick and easy path over the secure one.
Sandstorm has been part of my selfhosted stack since it was a start-up, and it has worked for a decade with virtually zero attention, and no exploits I am aware of.
If there are other hosted apps that want a really easy on-ramp for new users: packaging for sandstorm is an easy way to create one.
When docker first appeared, a lot of people explaining docker to others said something along the lines "It's like a fast VM you can create with a Dockerfile", leading a bunch of people to believe it's actually not just another process + some more stuff, but instead an actual barrier between host/guest like in a proper VM.
I remember talking about this a lot when explaining docker to people in the beginning, and how they shouldn't use it for isolation, but now after more than a decade with that misconception still being popular, I've lost energy about it...
Another suggestion: if your monorepo's service packaging is sufficiently uniform, build every service against both Go versions, package both binaries into the deploy artifact, and install a feature flag that lets you select which binary to boot when the service starts. This also lets you canary an arbitrary percentage of the fleet with the new Go version, and you can execute a version rollback by redeploying (without needing to revert any commits).
Funny, isn't it, how the goalposts keep shifting?