> On startup Claude Code / Codex CLI etc scan all available skills folders and extract just those descriptions into the context. Then, if you ask them to do something that's covered by a skill, they read the rest of that markdown file on demand before going ahead with the task.
Maybe I still don't understand the mechanics - this happens "on startup", every time a new conversation starts? Models go through the trouble of doing ls/cat/extraction of descriptions to bring into context? If so it's happening lightning fast and I somehow don't notice.
Why not just include those descriptions within some level of system prompt?
Yes, it happens on startup of a fresh Claude Code / Codex CLI session. They effectively get pasted into the system prompt.
Reading a few dozen files takes on the order of a few ms. They add enough tokens per skill to fit the metadata description, so probably less than 100 for each skill.
1) After deciding to use a skill, open its `SKILL.md`. Read only enough to follow the workflow.
So you could have a skill file that's thousands of lines long but if the first part of the file provides an outline Codex may stop reading at that point. Maybe you could have a skill that says "see migrations section further down if you need to alter the database table schema" or similar.
Knowing Codex, I wonder if it might just search for text in the skill file and read around matches, instead of always reading a bit from the top first.
My 4xe died in my driveway on Saturday after the update. Let me explain, from the perspective of a 4xe owner, how bad the response has been from Jeep/Stellantis:
- As of Monday 8am ET, zero legitimate communication from any Jeep-related accounts on any social media platform, or any other form of acknowledgement from the company (unless I've missed something?)
- I only found out about the issue after finally searching a few Jeep groups on Facebook (of all places) to see if anyone else was experiencing the weird failure mode I was after the update.
- The only remotely-official info was from a 'JeepCares' account (which is ran by Jeep) on some random off-roading forum? We were seriously all living off of screenshots from this forum, and the advice coming from the JeepCares accounts was contradictory: they claimed that the Uconnect update was separate from the telematics update, and that there was no way to stop the telematics update if the vehicle received it. Later they gave advice to defer the Uconnect update, making it sound like they were coupled.
- Due to the lack of info from Jeep, people were coming up with all kinds of "if you reboot Uconnect while the Jeep's in ACC mode, it clears the check engine light". This probably did clear the CEL but didn't fix the fault.
- There is no way to tell if you received the bad update.
- There is no way to tell if you received the 'fix' either.
- Dealerships have literally no idea what is going on.
- You're basically at risk of your Jeep going limp (power loss, unable to safely make it to the shoulder) and being stranded on the highway, even as I write this.
> - You're basically at risk of your Jeep going limp (power loss, unable to safely make it to the shoulder) and being stranded on the highway, even as I write this.
This seems extraordinary.
I was going to ask: Are you really saying they kill the vehicle's power system, effictively the engine, while the vehicle is being driven on the highway?
But no need to ask, the article says yes, that's what is reported:
> Instead, the failure appears to occur while driving—a far more serious problem. For some, this happened close to home and at low speed, but others claim to have experienced a powertrain failure at highway speeds.
Ya, that is shockingly scary. It makes me think we need some new standards about software updates to vehicles in general (or perhaps these already exist but were missed for some reason?). I can totally imagine that software used to be this ancillary selling point that didn't need such tight regulation, but as it becomes core infrastructure for the vehicle this is less of an IoT toy, and deserves stricter standards.
How about: you get to say whether you want to update and when and manufacturers are required to very explicitly list all of the changes in an update? That would seem to be an acceptable minimum.
I don't think that Jeep would have sent out a message saying that one of the changes would brick your machine.
It seems that the ability to trivially roll back any update would be a better choice, at least for this. (But I'm sure there are downstream effects I haven't thought about if that were implemented.)
How do you roll back a fatal car accident caused by the faulty update?
Giving user’s control over when the update runs allows them to be in a safe and secure setting when that update happens. Allowing them time, gives them and Jeep the ability to slow roll the update so they can halt it if initial feedback is negative.
I say this as a Mac user who does not allow auto updates for MacOS. I wait a week or so until the chatter validates it as non-breaking. They pushed an OS update several years ago that broke a few things I rely on. So I don’t trust them now, but these things just happen on OS’s with third party software. I expect it. But, I also don’t want to be forced to deal with the headaches immediately. I’d rather let the third parties run updates and advise how to deal, before I have to dive into fixing things. With car firmware, there’s really no excuse for this except poor engineering / processes.
Good points, I did miss those. However, if I had this vehicle and I was reading this article today - and had the ability I'm asking for - I would just keep my current version running until they figure this mess out. It's the advantage of letting other people run the updates first, you get to hear about issues before you experience them.
Many security compliances require auto-updates to be on. It's thought of to be a lesser evil, because many (most) users never update their OS/browsers, which is worse.
Well it could be solved on two fronts, you could issue the update and let users know that the update needs to be installed and will be automatically installed if not done by a specific timeframe.
If there are security related updates where the risk is severe then they may auto update.
the point was that manufacture is forced to have auto update enabled in name of security compliance. so, this issue needs to be solved by compliance first
Well, my comment was from owner's side. An end-user corporation is the owner of a corporate device like car, so it can decide whether turning it on or off. I just commented that for any serious corporation auto-updates will be turned on, per compliance requirements applied to the corporation.
This is a hypothetical in this situation, car manufacturers are under no such obligation. Also, rules like this tend to get reversed once the true risk is realized- people dying that is. We do all kinds of things for very marginal improvements to security these days
> Giving user’s control over when the update runs allows them to be in a safe and secure setting when that update happens. Allowing them time, gives them and Jeep the ability to slow roll the update so they can halt it if initial feedback is negative.
This does not fix any QA process that is broken. And frankly you should not need to update any control unit firmware after it is sold. The fact that they're even doing this is broken.
Unless your Mac is somehow attached to 5000 pounds of metal going 65 on the highway, the same standards should probably not apply.
The manufacturer needs to issue a recall in that case. They can't have their cake and then eat it too. Either the update is not critical and should not be generally available or it is critical and they should inform their users with the proper framing.
The original software will always have bugs in it, and those bugs will need correction. Software updates to fix/enhance it will also introduce new bugs.
The idea that one can create complex bug-free software is a fantasy. The correct mindset is to learn how to deal with failure. (This is how airliners are designed.)
> What if the update is to address a safety issue?
If they didn't make "safety" right from the first time, why do you think they will do it better the second time, when the fixes are more expensive and the time pressure is enormous ?
Hence the famous joke at NASA that you get to launch the rocket when the documentation if piled up would be taller than the rocket itself.
...all of which is just an excuse to show this great picture of Margaret Hamilton [1] lead developer on the Apollo guidance system standing next to (and slightly shorter than) the printouts of the source code https://en.wikipedia.org/wiki/File:Margaret_Hamilton_-_resto...
I've worked on some interesting software with lives on the line as well and the amount of test code absolutely dwarfed the functional part. I wonder whether at the time of the effort you linked that was already common practice and if it was what the fraction of that code was tests.
Assuming she's 1.65 meters tall and 66 lines per page (quite common back then), at 0.2 mm thickness per page that's 8K pages times 66 lines / page is ~550K lines. Pretty impressive!
on the other hand, if you know your old software is buggy and could cause fatal accident, you release a software update, but for some unknown reasons, the user keeps denying updating software, what would you do ?
It should be costly. You want to encourage companies to make better/safer products that have been well tested. The whole “Move quick and break things” is from the perspective of a completely nonessential social media service. They have no consequences when they break things, although even that has changed as every minute of downtime is lost revenue. Self inflicted financial pain is completely acceptable, if they choose to take that path. Car companies should not.
Just issuing a recall is not enough. There are countless reasons why someone does not return the product: They maybe simple not know, and there is no way to reach them.
That is why Samsung push update to disable note 7 even after recalling them.
> There are countless reasons why someone does not return the product: They maybe simple not know, and there is no way to reach them.
In Germany we let the Kraftfahrtbundesamt handle this. You are required by law to keep your address updated with the authorities, and all vehicles have to be registered to get a license plate. When a recall for safety reasons happens, the Kraftfahrtbundesamt writes a notification letter, and if you do not respond in time with evidence of having the recall issue remediated by a qualified shop (or doing it yourself and getting a sign-off from a licensed inspector), eventually they write to your local DMV office that can ban your vehicle from the roads, and if you miss that the police shows up at your home and physically removes the license sticker from the table.
And heaven forbid you get actually caught driving the car after having gotten the notification letter from your local DMV. That's automatically felony territory. Our authorities really, really do not mess around.
As American, I assume most the thread above was assuming US locale and it Seems like a solid case of the all too common “impossible by US status quo standards” when in fact the solution can be quite simple we just lack the imagination or willingness to see what worths elsewhere
You can apply every fancy safety model (V cycle, iso262626, ASIL, MIRSA) and nothing can guarantee you write one-shot bug free software when your software is slightly more complex than just controlling some lights, sensors or actuators.
Are you suggesting the “does it drive” test after an update isn’t a reasonable test that should be a fairly common sense one to add in?
In all scenarios, tricky bugs will happen. Something inconceivable will go untested. But that’s not what happened here. This is basically functionality being lost that very obviously should have been tested.
In that sense, they could have made progress. Nobody is expecting perfection. You seem to be hung up on the distinction
It's not perfect but seems reasonably easy to implement and would certainly help. If the user needs to approve each update and can see what the changes are most updates will either be skipped or delayed long enough that catastrophic bugs will only hit the small subset of cars that update immediately.
I would bet most updates, especially from a company this bumbling, will be more along the lines of increasing telemetry or pointless UI changes than releasing actually useful features and bug fixes.
It has become convenient for manufacturers to treat software/firmware differently from hardware, and we should fight that. If you buy a car, phone, or a TV, you buy an appliance, not "hardware stored at your place with software/firmware controlled by us".
OTA software updates should be a convenience, not a requirement, never be automatic, and be otherwise treated just like a visit to a car repair shop.
Similarly, no manufacturer should be able to tell you "oh, but it's a software problem" if your thing doesn't work as expected (I had Apple tell me this, for example).
Exactly. It has become accepted that manufacturers can sell us complicated systems before they're "done" and software is the excuse. It should not be acceptable, and if done well we could see incentives against this behavior causing manufacturers to sell radically simpler, safer, and more maintainable systems.
In this case, it appears somehow that an infotainment system update impacted the drivetrain. In my fully "fly by wire" computerized vehicle from 1999 (M-B E300), even if it somehow could receive OTA updates, these systems are physically separate. The ABS system is a different module from the transmission controller, which is different from the engine controller. They all communicate over CAN, but the only way one could crash another is if somehow it responds poorly to incorrect CAN messages.. And even if these computers crash the mechanical components they control will probably keep working more or less.. What has happened in the intervening quarter century that made it possible for this failure to happen?
> Similarly, no manufacturer should be able to tell you "oh, but it's a software problem" if your thing doesn't work as expected
Well, they should if they provided you with the hardware and you got the software from someone else. But that's the other problem: They prevent you from doing that, and then if their software is crap or they decide to turn off the servers, what do you do?
Watch for some carmaker to try to say that the car only had a 10 year warranty and then brick them by turning off some servers after they're over 10 years old, or just go out of business with the same result. It's a travesty that people even put up with that for electronics.
> How about: you get to say whether you want to update and when and manufacturers are required to very explicitly list all of the changes in an update?
Huh ? What a stoopid idea. Who would protect your security ? Who will protect the children ? /s
The current regulations are written for a time where cars didn't have rolling computers in them. And even then, the regulations don't account for Tesla-style linked systems. So I say we do need new regulations.
Yes but it's fairly recent that cars are receiving software updates on their own. Usually if there was an update, it would be from a recall that would necessitate going to a dealer to apply the changes, not something that is auto-downloaded and applied without the owner's awareness.
NHTSA's power is simultaneously very broad and narrow. They're empowered to investigate potential safety issues after the fact, but this may not be a safety issue in the very pedantic sense often used. NHTSA can proactively set standards, but the standards they've set (FMVSS) largely ignore modern electronics. So on and so forth.
NHTSA has been involved in recalls of OTAs that involve safety issues in the past, sometimes for things more minor than this, as long as it is something that affects safety equipment. e.g. stereo recalls because the backup camera took too long to display when shifted into reverse.
>> - You're basically at risk of your Jeep going limp
This has happened to me twice with a Nissan Leaf. I paid money to get a read out from the computer system, and there were no timestamps on the screens of data.
Modern cars "computers on wheels" are dreadful.
Is it possible to disconnect the power from the radios used for "over the air" nonsense? Then at least they would be stable.
In the Leaf, you can disconnect the TCU from the CAN gateway controller located behind the infotainment system to disable its remote connections.
It will throw a perpetual "check engine" light and disable the hands-free microphone, but OVMS users have made a "dummy TCU" that gets around that annoyance.
I have the opposite problem. The specific infotainment system update I need requires a $200 visit to a dealership with a specific model of a USB 2.0 SanDisk Flash Drive (NI-52727-1). Not available OTA despite the Leaf's OTA capabilities.
In my country that car would then fail inspection immediately. Of course you could reattach before the check up, but then there is no excuse for just shutting it off.
Buying a modern car seems to come with too many strings attached these days.
Is it possible to disconnect the power from the radios used for "over the air" nonsense? Then at least they would be stable.
I've read online that for some cars, you have to dig deep inside to disconnect the cellular antenna.
I'm a little more lucky. On my car, you can pop out the SIM card from a slot in the ceiling, behind the rear-view mirror.
This assumes you haven't given your car access to your home WiFi. (Some people do this so they don't have to pay for a data plan for their car, and it kinda sorta "syncs" when you get home.)
From a GPS software update... [1] "This is a telematics box module update" Telematics is primarily GPS and on-board diagnostics for location, speed, and fuel usage.
A GPS update kills your entire powertrain. Appears to also engage parking for some users, super dangerous. Catbones, "Almost died on the thruway today ... with an 18-wheeler behind me. ... Jeep died, locked its hand brake and jolted so hard my face almost ended up in the steering wheel at 70mph." [1]
It is completely insane that this is happening. I did DD on a company in the automotive space a couple of years ago and flagged that they did not check if the vehicle was stationary, motor disabled before updating. They were all surprised at how I thought that this could possibly ever lead to issues.
I have Java code running on commercial aircraft. You can’t actually run Java code on commercial aircraft because the FAA doesn’t (or at least not at the time) know how to certify it.
The entire box it’s on isn’t powered while the plane is in motion (“wheels on ground”). It’s shut off before preflight and doesn’t turn back on until the plane is on the ground. The service my code is part of is responsible for queuing updates and downlinking telemetry. Updates are manual and obviously you can’t run them while in motion if the box they are on doesn’t even have power.
Cars probably don’t have to go this far, but there’s a continuum and they’re clearly in the wrong part.
Even iPhones and windows let you schedule update times. Just the fact that a freaking MOVING MACHINE doesn’t is egregious on itself. Imagine if stellantis would manufacture industrial equipment or nuclear reactors!
I wonder how many OTA updates for cars could be left as a task for the mechanic, the way airplane updates are.
Airplanes are required by regulation to have a backup of all software to operate the plane, presumably so that a plane can’t get stranded by an emergency landing requiring system resets. What we built replaced a physical folder full of floppies or CDROMs taking up space in the cockpit. Some of my coworkers insisted it was for weight but I’m absolutely sure that pizza box server weighed more than the book.
Given the state of the software industry, it's honestly more surprising that this doesn't happen more often. Our industry is a complete joke, and somehow we've been given responsibility over people's lives.
We are really only about 60 years old as a proper profession, and we seem to be trailing behind doctors for professionalism and standard of care by about 100 years.
I don’t know what will turn out to be our penicillin, or our Joseph Lister, but in 1960 the former is something that didn’t exist when older doctors were in school, and latter had only been dead for fifty years. It may not have happened for us yet.
This is a super important point that I don't think a lot of people fully recognize. Medicine is a super interesting comparison because you honestly don't need to go all that far back to find some pretty egregious examples of doctors making things much worse due to ignorance or incompetence. My favorite example of this is the assassination of President Garfield, who most likely died not to the bullet wound itself but from the doctors rummaging around to try to find the bullet with unsanitized hands, causing infection and damaging organs...on the wrong side of his body[1].
On the topic of professions: Joseph Lister was a surgeon. Modern surgery (which I define as surgery aided by anesthesia) is a relatively recent discipline dating to the early 19th century. The introduction of anesthesia made lengthy and intricate operations possible but also ushered in novel problems and complications. Surgery as a field had to learn tough lessons over time.
He was known more for antiseptics but the biggest surgery moment for me will always be “using soap” and I wonder what the software equivalent is.
Like I said we are still young, so it feels sort of arrogant saying we have figured something out when I know how many things are industry standard now that almost resulted in shouting matches trying to get done even 20 years ago. Maybe our soap moment is coming up ten years from now.
But I suspect automated testing may be the wash your hands, because it represents a sort of hygiene that “we” used to just say fuck it or make a minimal effort.
> Given the state of the software industry, it's honestly more surprising that this doesn't happen more often.
It probably does. We just don't notice.
> Our industry is a complete joke, and somehow we've been given responsibility over people's lives.
Amen to that. kqr made some choice comments the other day in that thread about the airliner that came to within a hair of crashing due to running out of fuel. Thinking about risk is not a skill that we're born with and it is always sobering to read the 'risks digest' for a bit and to see how thin the ice really is.
It does. I have a Ford CMax from 2014. For years, when the SiriusXM radio software update would happen it would get stuck downloading. The geniuses at Ford decided the update should continue trying to complete even if the car was turned off. So once the download got stuck, it would completely drain my battery every single time. I'd rather have a car that moves that the latest SiriusXM update in my radio. The only fix was to pull the fuse if you noticed that it was happening.
I'm willing to see a difference in software standards between (say) Waymo and Jeep. One is a software company, the other is a sheet-metal company. If you just tar the whole industry you lose an ability to learn from those doing it better.
Tesla is very controversial, and they have clearly made some serious software mistakes, but they are so much better at software than any other maker I've encountered, except maybe mazda who eschew touch screens for physical buttons, but that is a ui success, not a software culture success. Tesla wrapped an electric car around a software company. They treated fit and finish and panel mating etc. as the throwaway/buy it cheap aspect (ok that is pretty harsh. It isn't that bad) and focused on the software. Where legacy makers did the opposite.
you are being generous. Tesla's software "mistakes" have killed several people. They needlessly try to reinvent the wheel in the name of innovation and end up ignoring decades of auto industry knowledge.
I do not trust them and never will. This is the #1 reason why every car is buy is just a car. I do not trust techbros with devices that can kill you, especially cars.
The software mistakes that killed people were software doing things no other automaker even tries to do. Very possibly with good reason. The software that does bog standard normal things like coolant control and battery preconditioning works well and seems to be tested and deployed in a reliable way. That is still so much better than what we get out of others. I would love an electric car with no can bus or microcontrollers, so I'm right with you. If anything the point to be made is that Tesla, who has killed people with its software, is still way better than average... So yeah, we are bad at what we do.
> doing things no other automaker even tries to do
"Move fast and break things" is not really a virtue when the thing moving fast is a two-ton hunk of steel and the things breaking are people's bodies. Getting the easier stuff right but then then also killing people isn't "doing better" in my opinion; sometimes it's better to have a lot of lower magnitude failures than infrequent but catastrophic ones.
I presume you're referring to Autopilot/FSD. I don't trust it at all, don't use it on my Tesla, and will not get into a "robotaxi" using it, but it's an optional feature.
Autopilot aside, though, the regular boring car software bits are rock-solid, and I've never had an issue with using it or after an update.
I do recall a story a number of years ago where one of the automatic updates changed the UI and hid the defrost behind a menu (or something along those lines). I don't know that anyone died as a consequence, but it was criticised as being quite reckless as it is a feature that when you need it, you need it right away.
Probably because the regular boring car stuff is not even made by car companies anymore LMAO.
The steering racks are made by Bosch or maybe ZF. Brakes come from Brembo. ABS module and its software is Bosch aswell. same goes for brakebooster, EPS pumps, AC compressors, and airbag controllers. I think the only electronics Tesla develops and manufactures are EV power electronics, infotainment, ADAS&Co and the drive motors.
If you take a VW Golf, you'll find the ECU and all of the software running the car is built by Bosch too. Essentially they sell VW a kit which needs to be mounted on a vehicle platform. Tesla is likely one of the only companies for better or worse that don't follow this model.
> you are being generous. Tesla's software "mistakes" have killed several people.
Citation needed.
In the early days of autopilot/FSD most of the fatalities were people doing stupid things like watching a movie or sleeping in the back seat. That's why it now has to monitor your face with a camera to detect whether or not you are watching the road - to stop people from being idiots.
However we must acknowledge that any change in the automotive space is going to lead to problems and some percentage of those are going to cause injuries. That is the nature of cars. They do not have the certification standards of aircraft nor the training of pilots. They can't and they won't.
It is also inevitable that autonomous driving is going to make different mistakes than a person would make. On a miles-driven basis it still produces fewer accidents and injuries than human drivers.
I’m going on a limb here because i’m not directly on the software industry but my first suspect would be metrics and the fact that you have to deliver a product at certain time “no matter what”.
According to the article, that's not what is happening. The update itself completes fine; it's the updated firmware that is buggy, and seems to cause/require a reset of the ECU while in operation. Not that that makes it any less insane, but the update process does not seem to be implicated here.
they did not check if the vehicle was stationary, motor disabled before updating. They were all surprised at how I thought that this could possibly ever lead to issues.
My anecdata is that my car won't update its software without the owner explicitly requesting it. And then, it will only do it if the car has something like 50% charge, hasn't been used for an hour, and nobody is inside.
I once tried to do the update while I was inside, and it refused.
My BYD wants the battery over some percentage, the vehicle in park, and the hood closed. The hood one was surprising, I wonder if it's for the safety of the car or of anyone working on it.
Probably a safeguard to keep sonebody from unplugging something during the update.
I can't speak about other cars, but my EV has nothing you can unplug. It's not like a regular car where stuff is exposed.
All it has under the hood is a storage space for charging adapters, a first aid kit, and a cap for the windshield washer fluid.
Even accessing the regular 12V battery takes a bunch of time and tools. The manual states several times that it should never ever be used to jump start another car, though it doesn't explain why.
If a power failure during the upgrade causes some unrecoverable problem that is a serious design failure. The answer isn't "make power failures less likely" instead it's "make the update process robust to power failure". This kind of disconnected hubris--thinking you can just wish reality away--seems unique to software. Why are they allowed to get away with it?
Sure, but if they aren't checking the super obvious potentially dangerous cases, doesn't that say something about the likelihood of their process detecting something less direct like this?
If a software update can affect the basic functionality of the car to such a degree then the whole car should be recertified after every update, change my mind.
I really want a 4XE Wrangler to replace my aging JK at some point, on paper its amazing, lots of torque and power, decent economy for a brick with large tires, and can actually run a pure electric enough to get around town, plus still takes all the standard Wrangler parts.
However in classic Jeep style they just can't get reliability down, and the PHEV part seems too complicated for them.
If it was just reliable it would still be the best selling PHEV in America, they let that go.
There is no sign of the 2026 Wrangler 4XE it might be canceled like the Gladiator version...
My Wife just got one last year, the electric engine will give you about 17 miles on a full charge that takes about 7 hrs, its pretty much useless on full electric mode, pretty good with the milage on hybrid which is what this really is. And yes do not expect reliability, first day out of the dealership we got a check engine light, apparently one of the workers at the dealership forgot to attach a wire or hose, at least thats the explanation that we got, i told my wife to insist on getting it documented somehow or get a log from the dealer but of course they played it off as human error (total BS). Few months later and her screen started to turn off and on, or just die completely when air play was connected. Stay away from these cars.
My Wrangler JK is 10 years old with almost no issues, its a relatively simple vehicle compared to most, easy to work on as well. The Pentastar V6 is well proven engine and the issues with it are well understood.
I really like the vehicle, it has served me well and taken me many interesting places across the country, along with daily driving. I tow it with a RV and its one the few that can do so now days, plus its extremely capable offroad.
The 4XE is very alluring, much more fun to drive (I have rented one) and I could charge it off home solar and still tow with RV (the only PHEV thats possible to do so). If only it was reliable...
There’s just no comparison when you consult reliability reports, though. Of course, even companies like Toyota are going in the direction of always on, arbitrarily updated software and subscriptions.
I have no idea what I’ll buy when my 11 year old toyota finally retires.
As a happy owner of a 30 year old Toyota 80 series I'd recommend getting one! The computer can be diagnosed with a light bulb. Or go even older like a 40 series Land Cruiser. No computers anywhere in those.
It's probably canceled, not only for reliability reasons. EVs and plugin hybrids are probably doomed, at least in the US: The EV tax credit subsidy is gone, fuel economy requirements will be or already have been eliminated, electricity prices climbing (my rate increased almost 50% on my most recent bill) and the Trump administration is extremely hostile towards anything related to renewable energy.
yes, because EVs are cheaper to operate than combustion cars. US auto makers are obsessed with creating EVs the size of tanks, hence the absurd prices. The Chinese auto makers are selling what people want to buy.
This sounds like the sort of thing that happens when a team has a deliverable that slips multiple times but everyone had vacations planned for a responsible amount of time after the deadline.
Under time pressure and confirmation bias they signed off on code that was giving off signs of being broken, pushed it, and now key staff are either on airplanes, out of coverage on their phones, or cannot work entirely from memory and don’t have their computers with them because vacation.
I bet they already have communications ready, but everyone Director and above needs to "wordsmith" it to deflect blame and make sure nobody looks bad, and all the lawyers need to bless it so that it's not admitting anything. I bet you there's a Word doc being frantically E-mailed around all day, needing to be approved by 25 people before it reaches the light of day.
How did you verify that a software update can 1. Occur during driving operation of the vehicle and 2. results in vehicle power loss?
I worked in an auto supplier years ago and there where several protections in place to prevent the risk of update corruption on safety related components. One of the simplest one the UDS programming session having entry protections related to vehicle speed, vehicle driving mode, etc.
imho the occasional mixup is going to happen, and eventually it'll be big like this or like Crowdstrike, but pushing these out on Fridays means the critical staff isn't there to help. The people who could have communicated this stuff to customers and dealerships were in bed when people got into their jeeps at 6am on Saturday after an overnight update.
I believe crowdstrike's update was on a Friday night as well.
Unless its a serious security bug, it can wait for not only for better QA testing but also for next Tuesday. Read-on Fridays need to be an industry-wide thing.
To me the bigger issue is that the infotainment system can affect the core function of the vehicle. That seems completely unacceptable, regardless of when an update is pushed out. The two systems should be separate with the infotainment system as the lesser important and unable to actually effect the core system.
That is the result of automakers trying to push everything into the HMI so they can eliminate physical controls.
They are doing to cars what electronics manufacturers did to TVs - taking an already-solved UX problem and destroying it with poorly made software in the name of progress.
Honestly the only thing that's going to change this is criminal liability for safety related software bugs. Otherwise, it's just business as usual and the business for the last 15 years has been cutting QA and asking developers to do testing themselves, which is literally impossible for a lot of software due to lack of proper staging environments and large permutations of configurations.
I think the nature of capitalism will make this impossible. The capital owning class will not allow criminal action for this and will also fight any common-sense regulations. If the working class gets that regulation in via the democratic process, that's fine, but its unlikely especially since it hasn't happened yet since we've gone digital on near everything starting from the 70s and 80s.
The working class lately seems more focused on 'culture war' issues and not economic or material or consumer or worker's rights issues anyway, so we're probably as far from any kind of regulation reform in software as possible. I remember a couple decades ago FOSS as an ideal seemed stronger and you had people like Lessig pushing hard for IP reform and Swartz and others for 'information must be free' honest-to-goodness mainstream movements and all of that seems to have went nowhere and is somewhat to very unpopular today. When was the last time you saw a populist movement towards liberal tech reform like this? Outside of some edge cases like medicine or power generation, the regulations here are purposely kept weak because that's what the wealthy desire.
Maybe our kids or grandkids will have this after the pendulum swings back, shrug.
Aviation relators just allowed boeing to self certificate again. Avition has a lot of historical regulations and can work through sheer inertia for years.
But the whole point is, regulator wont have teeth. They have teeth when politicians back them. And as of now, politicians back billionaires and deregulation. Wall street hates regulators, billionaires hate regulators and sizable part of population prefers people dying if it means they cam hurt libs and ennemies.
Personally, I would return the vehicle as defective after an issue like this. No way I'm going to trust the lives of family, friends and myself to a company like this.
Why do you let your vehicle update without supervision and knowing exactly what the update entails (what it does)?
If you knew upates were occurring why didn't you stop them by not allowing internet access and or disabling the web/net hardware?
I find it very odd, I never allow any hardware unfettered internet access let alone update its firmware. Experience has taught me that that's a recipe for trouble.
Maybe I still don't understand the mechanics - this happens "on startup", every time a new conversation starts? Models go through the trouble of doing ls/cat/extraction of descriptions to bring into context? If so it's happening lightning fast and I somehow don't notice.
Why not just include those descriptions within some level of system prompt?