> such that they can use the right set of sensors in the right environmental conditions
Because this part is really hard, and that's why Tesla abandoned the fusion approach. You cannot possibly foresee all the conditions in which LIDAR or any active sensor will malfunction/return wrong data/return data that's only slightly off for that ONE specific time. And even if it doesn't, you need to trust it to not return noise. And when it does return noise, how do you classify it as noise?
Cameras are passive sensors - they get whatever light comes in and turn it into an image. Camera is capturing shapes that make sense to the neural nets: it's working. See all black/white/red/cannot see any shapes? Camera is not working, exclude it from the currently used set of sensors or weigh it less when applying decisions, because it's returning no signal (and yes, neural nets have their own set of problems).
EDIT: cameras also provide more continuous context: if 1 pixel is off, is clearly bright red in a mostly-green scene where no poles can be identified, the neural net will average it out and discard it as noise. If 1 pixel says "object" in LIDAR, do you trust it to be correct? Perhaps the ray just hit a bird or a fly, but you only see a point, it's a lossy summary of the information you need.
> I would NOT be using Starlink for remote vehicle teleoperation even as a fall back.
I had to use Starlink last year, and latency was way more acceptable than expected even when under load (I did try to analyze and remove bufferbloat). Considering Tesla could likely get priority bandwidth from SpaceX basically for free, that would mean good latencies (I had 90ms tops in speedtests). Anyway you tell the car where to go, but it's the car following the path you draw for it and following traffic rules and collision avoidance, you're not directly driving the car. Even 1 second latency with 2s round-trip would likely not be a problem in these conditions.
90ms is absolutely not an acceptable delay. On a 25mph road, each 90ms is .0006 mile ~= 1 meter. Latency goes both ways, so that is a possible 1 meter before operator reacts and another meter before the corrective action takes place. Like other comment mentioned, remote operations can only be used for high-level instructions (or simpler highway driving).
I run a single-node K8s cluster on a dedicated server because it's way cleaner to manage than the previous mess and mix of docker compose + traefik routing + random stuff installed as package on the host.
I can create "vhosts" for practically anything in a declarative manner, and if the cluster blows up, I have 5 small scripts to bootstrap it and all I need is `kubectl apply -k .`.
I briefly played with k3s before realising than with a single machine I was maintaining a lot of complexity for limited benefits. Then I switched to NixOS, have everything declared in configuration and a much leaner and simpler setup
I think k8s starts making sense when you have to manage more than 10-15 machines. Better yet, 50-100 machines. Especially if these 200 machines actually run 3-4 types of containers total.
Usually it's rather unlike a sane dev setup. Even if your prod setup uses hundreds microservices (you're Google or Uber or something like that), you don't want to run all of them in your personal dev environment, you reuse 90%-99% of stable microservices running in the QA / integration / whatnot environment, and only run a handful locally.
> so it just boils down to strictness even when we're talking LLMs?
The article describes what I've been doing for the past few months - I did small python projects in the past because of the ecosystem: I couldn't possibly write a ton of the stuff required for the things I wanted to do, so I leaned into python because someone already wrote it for me. Quality of deps was mostly ok for the happy paths, but always a chore to patch the broken ones.
Nowadays I tell Claude what I want to build and I always ask it whether rust is a good choice for it. It'll pick up the right crates or choose whether it should DIY, do all the plumbing, nail all the logic, and in ~30m I'll have something very solid that would have taken me 3+ weeks of part-time evening coding in python. I think the article is right and rust is the closest to the "best language" we have for LLM coding at the moment: the strict typing and the tooling dramatically reduce the output space for LLMs, and 99% of errors have a clear, precise explanation that is actionable, and the compiler helps you a lot there too.
I think it also boils down to the fact that you cannot reliably and quickly answer "why is this arg None?" in languages like python without figuring out the call graph and evaluating possible states and inputs/outputs. Rust makes all that explicit and forces you handle it, which I feel dramatically cuts the time an LLM needs to spend figuring out why it's broken or what to do next. EDIT: The fact that you get memory safety on top of all this and it's handled by the compiler is yet another advantage for LLMs: the logic that gets written is simpler to reason about, because if you try to mutably access the same variable in two different places, the compiler will feed this back to the LLM at build time. In other languages that would be a "code smell" or would require static analysis.
Strictness is a quality for software and a chore for humans, and of course the stricter you are at representing your logic and your state machine, the less ways a program can break. LLMs writing in rust give you the strictness without the chore part, and it's a very good deal from my point of view.
My wife is a freelance digital marketing specialist, this post basically describes what she's been seeing since the start of her career 10 years ago.
As a tech guy, I've found that business owners tend to be way more pushy. Normally they fall in the boomer category, or they simply are not in the field.
Both categories seem to assume that "ahhh IT, things are instant and tomorrow I'll have 10'000 daily visitors", while that's very far from the case. They think that spending money today means results tomorrow as in "next sunrise", while digital marketing is basically subject to the whims of Google/Instagram/... and their algorithms, and investing today means seeing results at the very earliest after three months.
You tell them beforehand many times, they sign a contract, they agree with everything... and then after 2 weeks they start asking you daily why things are not improving, with zero respect for work hours or personal boundaries. That's how they choose someone else via "high-friction", and they normally land on bigger agencies because they think bigger agency = faster results.
> We were on self-hosted Gitlab but after a merger were forced to Github. Navigation feels painful in comparison and basic features such as commit graph are now behind more expensive tiers.
Same experience here. Add to that that even on Enterprise tier:
- 1 Enterprise : 1 namespace - although you can segment it with Orgs, we were advised not to do it because we're too small (~2k people) (GL: groups, subgroups, sub-subgroups, ...)
- SSH deploy keys are singletons across the entire instance and repo-bound (and Weblate for instance can only use its own key), so you need a service account for that (GL: instance-wide SSH deploy keys that you can activate in specific repos)
I can't speak for the UK, but with my Model 3 2019 I was charging <10% to 30% @ 250kW (max the car supports) for a good 5+m in Switzerland and Italy already 4 years ago (both at Tesla Superchargers V3 and Ionity 350kW public chargers).
Of course the charger is not the only limiting factor, the grid also needs to support it. If you're in a small town with no big shops/industry, you're way less likely to have 1+MW cables installed, there was never a need for such peak capacity before.
> Part of the reason it is so valuable is that patients usually must take it for the rest of their lives.
Well yes, Ozempic doesn't solve the habits of a bad diet.
The weight rebound is surely due in little part to removal of hunger suppression as in "hormone rebound", but if you resume eating 5000+ kcal/day because you don't have something that keeps you from doing it, you'll end up in the same situation as before. Ozempic was never meant and is not going to fix your diet. That's a psychological and environmental problem.
> This is a clear restriction on liberty. ... Just like many stupid decisions (junk food included), it ought to be my right to decide how to live.
I guess that liberty was plenty abused on every non-smoker in a non-smoking area, that ended up coughing in clouds of smoke anyway. Smoking affects everyone around you whether you want it or not, and while you may smoke for 50 years and end up being perfectly healthy, some may get cancer from it, even for a very small dose.
There's already some pretty comprehensive bans on smoking in places where it could affect other people. I don't really encounter cigarette smoke in my day-to-day life.
> There's already some pretty comprehensive bans on smoking in places where it could affect other people.
Which I'm arguing are disregarded most of the times by most smokers. I do encounter cigarette smoke in my day-to-day, unfortunately. And unfortunately it's always the same places, mostly bars and restaurants that have outdoor spaces. Places where I'm supposed to smell food I pay for, and I end up smelling smoke instead.
> If they want to protect people they need to ban it for everybody..
Last time governments tried to force people to do something for their own sake, you saw how it ended (COVID). If people can't start smoking cigarettes, they won't get hooked up, so gradually at least regular cigarettes will be phased out. Vapes are still controversial, but as a non-smoker with a very sensitive nose, vape smoke is 10000x better than cigarette smoke. It doesn't cause me to cough, it doesn't contain harmful chemical compounds, it doesn't soil clothes nearly as much, and I can still smell food at a restaurant.
Because this part is really hard, and that's why Tesla abandoned the fusion approach. You cannot possibly foresee all the conditions in which LIDAR or any active sensor will malfunction/return wrong data/return data that's only slightly off for that ONE specific time. And even if it doesn't, you need to trust it to not return noise. And when it does return noise, how do you classify it as noise?
Cameras are passive sensors - they get whatever light comes in and turn it into an image. Camera is capturing shapes that make sense to the neural nets: it's working. See all black/white/red/cannot see any shapes? Camera is not working, exclude it from the currently used set of sensors or weigh it less when applying decisions, because it's returning no signal (and yes, neural nets have their own set of problems).
EDIT: cameras also provide more continuous context: if 1 pixel is off, is clearly bright red in a mostly-green scene where no poles can be identified, the neural net will average it out and discard it as noise. If 1 pixel says "object" in LIDAR, do you trust it to be correct? Perhaps the ray just hit a bird or a fly, but you only see a point, it's a lossy summary of the information you need.
reply