Continuous Integration! Do you speak it!?
Rivian blames “fat finger” for infotainment-bricking software update
Submitted 1 year ago by AnActOfCreation@programming.dev to technology@lemmy.world
Comments
Synthead@lemmy.world 1 year ago
bob_lemon@feddit.de 1 year ago
Integration tests don’t really help if you just push the wring build to production.
Although the pipeline should probably not accept builds that haven’t passed all tests.
Synthead@lemmy.world 1 year ago
Integration tests don’t really help if you just push the wring build to production.
This is like designing a deadbolt that tells you that the key doesn’t work, but it allows you to open the door anyway. Why would anyone have a process in place where you can push to production with failing integration tests?
autotldr@lemmings.world [bot] 1 year ago
This is the best summary I could come up with:
The more innovation-minded people in the auto industry have heralded the advent of the software-defined car.
It’s been spun as a big benefit for consumers, too—witness the excitement among Tesla owners when that company adds a new video game or childish noise to see why the rest of the industry joined the hype train.
The EV startup, which makes well-regarded pickup trucks and SUVs, as well as delivery vans for Amazon, pushed out a new over-the-air software update on Monday.
But all is not well with 2023.42; the update stalls before it completes installing, taking out both infotainment and main instrument display screens.
Update 1 (11/13, 10:45 PM PT): The issue impacts the infotainment system.
A vehicle reset or sleep cycle will not solve the issue.
The original article contains 304 words, the summary contains 126 words. Saved 59%. I’m a bot and I’m open source!
DeadlineX@lemm.ee 1 year ago
I didn’t even know rivian had even made an actual vehicle until I saw one last month. I thought they were still vaporware. Wasn’t there another trunk company that was supposed to have made a truck like 6 years ago? Did they ever do that?
mosiacmango@lemm.ee 1 year ago
Rivian is out and about. Thru even finished their 10k amazon van order along eith the trucks and SUVs.
The truck brand thats still vaporware may be tesla (ha) but you probably mean Fisker Oceanwhich looks amazing if it ever exists.
wjrii@kbin.social 1 year ago
Well it’s certainly better looking than the Rivian, which is one of the ugliest production vehicles I’ve ever seen.
Hildegarde@lemmy.world 1 year ago
The Lordstown Endurance was an electric pickup truck. It was to be built at a former GM factory. They managed to produce 31 of the trucks,19 of which had to be recalled. The compny failed, but the factory is owned by Foxcon and is planned to be used to manufacture Fiskers in the future.
Fisker has been producing electric cars. They’ve made around 5,000 at this point. The Alaska is a planned future vehicle. Unlikely to happen. The auto industry is notoriously difficult to for new manufacturers. Telsa is one of the few car new car companies to see widespread success, and they are the exception.
lemann@lemmy.one 1 year ago
Says a lot about their internal organisation structure for something like this to happen. Intern is the only tolerable excuse here, but even still why would you put a newbie in a position where they could brick thousands of vehicles with a slip of the finger?
I’d expect a tech company like Rivian who happens to sell a vehicle to know better than this 🤦♂️
Isn’t standard practice to validate signed code first before installing it? Hope the next update allows the car’s computer system to check the firmware signature before doing what I assume is an automatic installation…
Ouch
SquiffSquiff@lemmy.world 1 year ago
I don’t follow your line about an intern. I don’t see it in the article and even if it were the case, an unqualified person being able to do this is on the seniors/leads. Throwing the intern under the bus is what scummy companies do to shift blame - see solar winds , where (spoiler) this strategy doesn’t seem to be working out
surewhynotlem@lemmy.world 1 year ago
It’s more incompetent to allow an intern to fuck up production than it is to have normal developers make mistakes. It shows a complete lack of controls and care.
jackoneill@lemmy.world 1 year ago
Yeah not the intern’s fault, the fault of the system that allowed the intern to be able to do it at all
AnarchoSnowPlow@midwest.social 1 year ago
Anyone who builds software that runs on actual hardware should know that you NEVER deploy builds that haven’t been fully exercised on actual hardware.
This tells me that their software QC process is non-existent at best and actually malignant at worst.
If their software is supposed to be their defining feature this is the equivalent of McDonald’s “accidentally” shipping frozen discs of literal shit instead of burger patties to franchises who then serve them to customers without question.
If their company dies because of this (it fucking should imo) they 100% deserve it for the countless unknown dangers they’ve exposed their customers to. It’s not this particular thing, bricking the infotainment system, it’s the demonstration that they have no or bad process.
incompetentboob@lemmy.world 1 year ago
Ok, calm down. Seems like a bit of an overreaction to link a bad software update for an infotainment system to “countless unknown dangers”
They screwed up, it happens to the best of us. There isn’t a company on the planet that hasn’t made a mistake and rolled out something that is broken.
What’s important here is that they said “yep, we fucked up, we are prioritizing fixing this problem for customers” instead of trying to hide it or blaming the customer for the problem.
If anything Rivian should be applauded for how they handled it and if this kind of thing continues to happen, then maybe we get the pitch forks out.
AndyLikesCandy@reddthat.com 1 year ago
Interns do but should not get the level of write access that makes a durable change impacting all customers. Deadlock a server or even wipe SQL tables, this is an outage. Break a customer’s configuration, send the wrong client’s paperwork, again small scale problem you can deal with. Interns don’t change company policy.
I think it’s a more foundational architecture question: why do you push builds to all customers at once without gating it by SOMETHING that positively confirms the exact OTA update package has been validated? The absolute simplest thing I can think of is pushing to 1 random car and waiting for the post-install self tests to pass before pushing to everyone else. Maybe there’s actually no release automation?? But then you make it safe a different way. It’s just defensive coding practice, I’m not even a CS degree but learned on the job something always breaks so you generally account for the expectation that everything will fail by making a fail-safe just so the failure is not spectacular. Nothing fancy, just enough mitigation to keep the fuck up from eating into your weekend if it happens on a Friday.
AbidanYre@lemmy.world 1 year ago
rivianownersforum.com/…/rear-ended-rivian-gets-42…
Ouch indeed.