HN user

ogjunkyard

108 karma
Posts0
Comments29
View on HN
No posts found.

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.

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.

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.

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.

With a lot of the decisions Tesla's been making lately, I'm not sure I'm going to buy another either. I'm mainly speaking of:

- The butterfly steering wheel. - The removal of radar for Autopilot (I'd like to have multiple systems for this, not just cameras/vision). - The removal of steering column stalks (and using the sensors to figure out which direction you want to go). - The door open mechanism changing from handles to whatever this button situation is.

I'm sure there will be other stuff, but yeah, may have to cancel my reservation for the Cybertruck.

I mean this question is the most empathetic way possible, from a curiosity-based perspective, and feel free to tell me to shove off if you don't want to answer it.

How do you gain employment in the event you decide you need to leave your current place of employment?

Amazon Sidewalk 5 years ago

Exactly. That's my biggest struggle with finding a TV these days.

I want to make sure that the networking functionality is what I attached to it, not something built into the TV that I have no way of possibly disabling or removing entirely. With some of the relatively recent PiHole posts, it's become clear that some of these smart TVs are including some level of DNS resolution on their end to get around ad blocking functionality. They'll say it's for ensuring they can always download updates, but it's really for retrieving ads.

I want a display that's going to last longer than 3 years. This is one of my concerns with Spectre displays. I'm not sure of their longevity.

I want that display to have a great picture. I also don't think Spectre displays looked particularly great when I looked at them in the past. Maybe that's changed over time.

Yeah, it's basically this. I'm running this as an initContainer for my K8s-based deployments. Took me a bit to get everything going, but my stack is pretty much similar to OP's article, although not quite as advanced in the automated-deployment of containers and monitoring. I'm not at a position where usage needs heavy monitoring because I'm still in the pre-launch phase of things and I'm using this side project to learn stuff I've yet to get experience with at multiple companies.

I'm in a similar situation for the most part. If I remotely care about the quality of the item, I'm not buying it from Amazon. Otherwise, if pretty much any brand will suffice (such as dog waste bags), I might still pick it up on Amazon, but I have already chosen not to renew my Prime subscription based on the major drop in quality of sellers.

If you configured them the same (chose the more expensive Air), the Air and the 13" Pro have the exact same specs from what I can tell other than a slightly brighter screen (500 nits vs. 400 nits) and slightly bigger battery (58.2 whr vs. 49.9 whr) on the 13" Pro.

I just wanted to thank Jordan Lewis for putting this article together. It gave me enough clues on how to implement the "whiteboard"/telestrator feature I've been trying to casually implement over the past 6-9 months. Even though I have 1,300+ hours streamed on Twitch, this still slipped through my grasp on how to get it implemented for some reason.

I was originally trying to implement this functionality by using NDI, but there were a few issues I ran into, namely resolution and framerate, neither of which I was happy about. Something about this article tipped me off to look up using USB to connect the iPad to the PC, which actually led me to setting up the streaming PC as an AirPlay receiver. After I made the switch over to using AirPlay, I had the whiteboard/telestrator functionality working on my OBS setup within 10 minutes.