ogjunkyard

The removal of radar has got to be a hindrance to getting autonomous driving working well for Tesla. Cross-comparison between multiple forms of environment surveillance (Vision, Radar, LIDAR, etc.) has to be in place for autonomous driving to work reliably IMO. This much has been stated by multiple non-Tesla AI organizations and leaders.

I think Tesla may be using the price of FSD as a way to dissuade people from buying it, while enabling it to be a funding mechanism for continued work on autonomous driving.

As evident in this video, FSD is often acting like a nervous student driver by being unable to confidently make decisions on the path to take, running through red lights, driving unpredictably at slow speeds, and more. This is probably due to the fact that there is ONLY cameras being used to inform FSD, which can suffer from contrast issues.

I've seen videos in the past where Tesla camera input is in black/white/grayscale for processing. It seems like if you converted the video to B&W, the pylon and the road are similar darkness/color, so I'm not surprised this had issues. Tesla Autopilot was suffering from issues with contrast all the way back in 2016 when Autopilot failed to detect a semi crossing a highway in Florida which lead to the death of the Tesla driver. This was due to the white trailer against a bright sky.

Ultimately, as a consumer and former Tesla owner, I don't feel confident in Tesla's ability to get autonomous driving working well at a human-capable level, let alone the "10x safer" bar they've set for themselves.

The early Nissan Leafs had abysmal range at around 80 miles of range total, but they seemed like the perfect "in town" car. A former manager of mine had a 2012 Leaf and he LOVED it. I always wanted to see how an EV's value would hold up when there was next-generation battery technology that could potentially be retrofit into an older car like the early-model Leaf.

You are correct that it's very hard to find an apartment with access to an outlet, but it's less of an issue than you would think.

Having owned a Tesla in San Francisco and street-parking it for 2 years without access to a charger, I treated it much like one would with a gas-powered car: I went to the charging station about once every week or so and "filled up". The only inconvenience is that it took longer to recharge the car than to fill up an ICE vehicle. Everything else was the same basically. I never found myself in a position where I couldn't charge the car.

After I moved to a place where I had access to an everyday power outlet (120v, like you'd plug a desk lamp into), it pretty much eliminated my trips to the charging station.

The ONLY time it was every a question was when I took a trip to visit family in a rural part of the country where the closest supercharger at the time was 2+ hours away. My family doesn't do a lot of driving, so it was easy for us to just plug my car in and I had no problem leaving.

I ended up putting about 40k miles on the Tesla before I sold it, and I have no qualms about getting another electric vehicle.

Maybe I'm missing something, but this doesn't look at all like a blog and/or I can't find a way to find any posts.

Also, that is a rough background with it changing every couple of seconds.

While I will agree that it takes a long time to reach everywhere with new features in Maps, I'd say the recent macOS Monterey update was a major improvement in performance/reliability, so the article doesn't really resonate for me.

I IMMEDIATELY noticed the improvement in application startup times after upgrading and have seen a big difference between my work laptop (macOS Catalina) and my personal laptop (macOS Monterey). Everything has been more stable in Monterey for me personally. I've noticed that the weird occasionally-crash-my-laptop-when-using-a-dock bug has been resolved. Connecting my AirPods has become more reliable and the connection doesn't flake out anymore.

Thanks so much for this response!

I've been thinking on your response for probably over an hour as I've been going about my day, and the thing that is sticking out to me is your directive to think critically about WHY I want observability. I think I figured out the motivation on why I'm looking into all of this stuff.

I have a side business I'm working on that causes me to think about the customer experience a lot since it's a fully self-service, no-touch product where I'm not actively engaged in the sales, onboarding, etc. experience a new user has. When someone does have an issue, I want to be able to help them accomplish what they are trying to do as quickly as possible.

I recently had a user/friend who was trying to get something set up in the application I'm building. The only reason I knew he had an issue was because he reached out to me. Luckily, when I finally saw his message 4-5 hours later, he was around and able to work with me on troubleshooting his issue. It took me a bit to troubleshoot exactly what was going on and the friend was very patient/helpful the entire time. I remember having him try to initiate his request probably a dozen or so times as I worked through my application and teasing out the root cause of his problem. Ultimately, this led to me building in better error messages into my application to address this specific point, but if there's a way to get ahead of the user issue whack-a-mole game, I'm all for it.

Instead of him trying to reach out to me and us troubleshoot this issue together in real time, it would be more helpful to simply have had an Error Code and Request ID instead. This would allow me to instead tell him, "I dug into this and found out what's going on. Here's exactly what the issue is. Do X, Y, and Z to get this working."

Other points that particularly resonate with me, although I may not consciously know why are:

- JSON-structured logging

- Visualizations could help sell the idea of observability at $DAYJOB (but no clue what would make for a good graph/diagram/etc.)

- High-functioning teams want observability like high-functioning teams want automated testing.

I enjoyed the article a fair bit!

I was wondering, how should one get started with observability and implementing it? Are there specific books/courses/talks you'd recommend?

The reason I ask is because I've never been directly exposed to good observability at any of the companies I've worked at for a handful of reasons. It mostly boils down to the fact that I'm a DevOps engineer, so building observability is a set-up-and-keep-running sort of deal for other teams, not a useful-for-my-applications thing that I'm going to be working with often. Teams let us know "Splunk is down", "I can't reach Kibana", or "Looks like disk space is filling up" and that's about it after it's been initially set up.

There's a whole host of questions I'd ideally like to answer, but a lot of it boils down to the fact that I don't know what I don't know and I'd suggest assuming I know nothing over assuming I know something because I know the word. Questions I'd like to be able to answer are:

- What makes a good log? - What is a trace? Why is it useful? How does it help me debug issues faster? - How do you increase observability for loosely-coupled microservice systems? - How do you observe multi-threaded applications? - ... and I'm sure there are a whole bunch more.

I see Waymo/Cruise/Zoox autonomous vehicles multiple times a day in San Francisco and every one of these points are something that happens all the time in San Francisco.

Something I didn't see mentioned about NYC was elevation changes and hills, which is something that San Francisco has all over. There are some VERY steep streets in San Francisco, which means that sensors are out of typically alignment in relationship to the road when an autonomous vehicle is at an intersection.

For sure, I agree with this take. My goal is to build a small, lean company that serves one particular market and expand over time.

The company operating on the $20/year model offers a very specific feature-product and that's basically the only thing they do. My goal is to have that be one of the features my company offers eventually and do this with a handful of complimentary feature-companies to build something more robust over time, the idea being that I charge something like $10+/month for a set of "premium features".

In this case, serving the market is about scale and no-touch/incredibly-low-touch sales. The companies not charging anything are making money on the backend through data, analytics, and sale of information to 3rd parties. There's definitely money to be made, it just depends on who you are asking for that money from.

I thought the same thing.

Current major players in the market I'm going after offer their products/services for free, and niche players offer their products for $5/month or $20/year.

Charging $47+/month is a nonstarter as customers are price conscious.

What are specific concerns you have? I've been using the Stream Deck software for a couple of years now and other than a few freezes that required me to relaunch the application. I haven't had any issues.

I feel like the lean on SpaceX in this article is because it's a popular name at the moment. In the article, it mentions that SpaceX received grants for urban areas for things like airport parking lots. Also mentioned were areas already served by one or more companies with 25/3 broadband. Those were the types of locations that funding was being pulled for.

I keep personal "runbooks" for a lot of the common work I deal with over time. Eventually, this stuff gets automated where possible, but taking the time to work through all of the problems, write it down, and do it in a way that I can show someone else has helped me make sure that when I sit down to automate something, I truly understand the "domain".

It also helps tremendously when you have someone reach out to you during off-hours when you can just look through some documentation you have on hand to blaze through a task that takes a lot less time than if you had to figure things out from scratch.