because people assume it was the full self driving car when it was actually the human on autopilot that caused the narrative. When someone provides a false narrative you certainly have a duty to counter that with facts.
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Tesla has allegedly activated a selfie cam Driver Monitoring System
- Thread starter shrineofchance
- Start date
because people assume it was the full self driving car when it was actually the human on autopilot that caused the narrative. When someone provides a false narrative you certainly have a duty to counter that with facts.
rxlawdude
Active Member
linux-works
Active Member
are you for hire? sometimes I need to be told what to do. seems like you're the man for that kind of job.
But you're asking for a code fork .. basically you want to cherry-pick what bits and pieces you receive. I'm sure that sounds fine to you, but what about those who dont like some of the more recent UI changes? Can they decline those? These variations multiply out of control very fast. Tesla already have to cope with hundreds of variations (car model, country rules, language changes, hardware variants etc etc). Testing all the stuff you are asking for would become a nightmare. You cannot tease apart "truly critical updates" (and who is going to define what that means, anyway) from new features, as they are often closely related as part of the development process. And dont forget the huge testing burden .. Tesla have to test every combination (at least in theory).
linux-works
Active Member
since a lot (most?) of tesla's code is linux based, linux's heritage has always been to keep things separate so you can pick and choose how you want your system to be.
in fact, its actually MORE work to combine things and ship monolithic than to keep components in their own branches (which they are, anyway, at the source level).
its a very sane thing to do - to allow users to JUST update security and bugfixes. I cant imagine anyone who would seriously object to that, if it was offered. (however, I would still hold back on forced auto-updated, even secfixes. the user sometimes actually has a good reason for what they do and that power should not be taken away.
now, we have 2 more types of branches. UI stuff. that's entirely its own thing and could even be subdivided. we all know what it means to update one app on our phones. and we have full say over which ones get updated and which ones dont. hopefully still, everyone is with me, so far.
the last type of branch is new features, and yes, that does affect UI but 'form' and 'function' are modern concepts and so it should not be a problem to have a new function foo.c and its associated UI changes foo-ui.c if user wants that feature, they get those 2; if not, both of those stay off the car.
this is all controlled by how the build process works and the jenkins guys (build guys) can easily configure things to be how I just described.
its not really hard. it does take some manpower and forsight and planning, but hell, they've been around forever, in tech/dog years. its not asking too much. and there are no down-sides to the end users. NONE at all.
linux-works
Active Member
in fact, in a previous job, I was doing just that. part of a team that would decide which components in our linux buildroot and freeRTOS distros we would upgrade, which we'd keep back, which new modules we might include, which are part of the dev's tshooting layered kit and which are going to production.
not a lot of companies have dedicated people to do this and the main reason is that so few actually know how to do it and know how to decide which libs to keep back and which apps need which variants. keeping track of the security reports in public, vendor-supplied closed code and our own developed code - it can add up to a bit of effort, but if you DONT do it, you fall behind. what is called 'building up technical debt'. so you pay now or you pay later.
Indeed, and for a linux distro, that's fine .. but for a car with mission critical software we're talking a different level of scrutiny. And your analogy breaks down, since it was you who was deciding for everyone how you would package the distro. You didn't have your customer asking for bits of this, but not that, and a specific version of whatever. Imagine how many distros you would have to manage if that was the case?
linux-works
Active Member
we already have a button to tell the home server if we want to be on fast track for updates or conservative.
I'm just suggesting that adding some more radio buttons for 'ui updates' and maybe 'feature updates'.
this can work, it has worked and its not hard. but I guess I'd have to actually show you to convince you, and I'm out of energy for tonite, so it will have to wait
we already have a button to tell the home server if we want to be on fast track for updates or conservative.
I'm just suggesting that adding some more radio buttons for 'ui updates' and maybe 'feature updates'.
this can work, it has worked and its not hard. but I guess I'd have to actually show you to convince you, and I'm out of energy for tonite, so it will have to wait
The problem comes with having to test all of the different variations. Where I work you either stay with the software of when the item shipped or you update all items on the board to a different verified release package if you want support. We don't support updating just 1 part. There have been too many times were an update on one controller in the system but not the other breaks something. How many times have security updates on an OS be it on a phone, a computer or something else broke an app? It may not be fully broken maybe only in rare cases does the problem come up. If it is a smart phone app it isn't that big of an issue maybe annoying but not life threatening. Now when applied to safety critical systems it is a bit more serious. Of course the argument could be made that Tesla isn't doing the level of testing they should be before pushing software updates now so adding this option isn't going to increase the amount of testing they do.
The other issue is when you have so many variations of software versions it becomes much more difficult to troubleshoot issues that are infrequent. You first have to verify the issue which is normally done using the same version as it was reported with, then if you can't immediately ID the cause you may need to test various versions to see if it is present in previous release or more current releases.
According to the TeslaFi Firmware tracker, it appears cabin camera monitoring has just started rolling out with 2021.4.18.2 to a wider population of vehicles. (Till now it appeared to be limited to only new, radar-less 3/Y’s as part of 2021.4.18.1 and 2021.4.15.11.)
www.notateslaapp.com
2021.4.18.2 Official Tesla Release Notes - Software Updates
Tesla software update 2021.4.18.2 includes Cabin Camera Updates, Minor Fixes.
www.notateslaapp.com
Again, the are projecting from consumer software usage to critical-system usage, which is simply not valid. In fact, to begin with, Linux is notoriously bad at managing inter-component dependencies, installing apps/tools can often break other already installed apps/tools (I was fighting just such an issue last week).
Second, you are again not appreciating the risk levels involved. A UI element error can be deadly (for example, a switch which says it has enabled a safety feature but in fact has not). ALL software systems that involve significant risk to humans (medical, aerospace, automotive etc) are subject to much more rigorous methodologies than consumer or business software. This goes WAY beyond the simplistic model that you seem to think is what happens .. as it should, since mistakes can, quite literally, kill people.
What you are asking for is, in fact, incredibly dangerous. Really.
Yeah, I don't see what the big deal is, they give you a switch to turn off data sharing, the world has tape. Done.
All of this seems similar to people who put tape over their laptop cameras, but sit on the toilet with their front-and-back-facing-multi-lensed phones. You bought a connected car that knows where you are, has 8 cameras recording everywhere you drive, how long you were there, what your driving habits are like, whether there was someone else in the car, what songs you listened to, has a microphone that could hear anything being said, etc.
All of this seems similar to people who put tape over their laptop cameras, but sit on the toilet with their front-and-back-facing-multi-lensed phones. You bought a connected car that knows where you are, has 8 cameras recording everywhere you drive, how long you were there, what your driving habits are like, whether there was someone else in the car, what songs you listened to, has a microphone that could hear anything being said, etc.
According to the TeslaFi Firmware tracker, it appears cabin camera monitoring has just started rolling out with 2021.4.18.2 to a wider population of vehicles. (Till now it appeared to be limited to only new, radar-less 3/Y’s as part of 2021.4.18.1 and 2021.4.15.11.)
2021.4.18.2 Official Tesla Release Notes - Software Updates
Tesla software update 2021.4.18.2 includes Cabin Camera Updates, Minor Fixes.
Quick clarification.
When installed onto a Model 3/Y with Radar it doesn't activate cabin camera monitoring.
I have no idea why, but on my Model 3 there was no mention of driver monitoring on the release notes for this version. It simply said some minor bugfixes, and improvements.
They definitely need to add that view to see the "oh crap" faces right before something happens.
Similar threads
- Question
