91–100 of 189 posts
Some 20 years ago I was asked to prepare OS distribution with OTA upgrade capability for some PoS system. I think I prepared two system partitions and a custom MBR which would alternate the system partition on every start (uses one bit of non-volatile memory to alternate selection of partitions on each boot). When the system starts, it does self-test. If it fails the self-test it just restarts. If it succeeds -- it w…
Some 20 years ago I was asked to prepare OS distribution with OTA upgrade capability for some PoS system. I think I prepared two system partitions and a custom MBR which would alternate the system partition on every start (uses one bit of non-volatile memory to alternate selection of partitions on each boot). When the system starts, it does self-test. If it fails the self-test it just restarts. If it succeeds -- it w…
Earlier quoted context omitted.
You are talking about the company that wrote logs to the fully read-write filesystem of their infotainment system and killed the EMMC from raw flash cycles within as few as 2 years. Recalled 10 years later.
Yes, this happened to me, although it took 10 years. Free replacement, and the car still worked fine.
Calling out Tesla as a model for excellent software is insulting to SW that's actually quality.
What Tesla SW has and others lack, is a great "wow" factor, which consumers who don't get to see how the sausage is made, mistakenly associate with 'quality' because it behaves like their iPad, but don't know all the skeletons in that closet.
It’s a bit troubling that automakers (and, well, anyone who is building things that have mechanisms for software updates) aren’t making software updates failsafe. If you have multiple copies of the image on storage, and you take care not to touch the currently-running image, then a failed software update to the alternate image shouldn’t have any impact. Think of it like blue-green deployments on the cloud; and it’s w…
Ideally, the update should be done by independent agencies, so they can make sure the software is tested and they can properly inform the user (something which we already know companies don't always do).
The way it is now, it is all too easy for a company to decide to push a quick fix for a problem that really needs a more careful approach (but which might cost the company money).
I see a lot of people asking "How could this possibly happen?" It turns out that there's a common failure mode that makes it past almost every unit test suite: a lack of disk space. Running out of disk space pops up time and again. I've often wondered why software fails so often in this situation. But it's because the basic components of the system start to break -- things like "Call with temporary file" stop working…
Out of drive space is the worst, though. Like you say, most things don't handle it, they just plough headlong into an install and then die, leaving the whole drive in a horrible unknown mess of files where you might or might not be able to retry the operation, and you might or might not have used up the last few bytes on the drive and now for some reason when you try to reboot it can't even boot the system up because it can't write some temp file it needs.
For decades software engineers have moaned “why can’t software engineering be a real engineering discipline like civil engineering”. The travails of the legacy car makers, compared to Tesla or Rivian, show conclusively mechanical engineering is easier .
Cars have constantly gotten harder to repair, more brittle, and if a repair is needed, you often have to, instead of being able to swap out a $5 component, replace larger components that the $5 component is part of. This is by design as replacement parts is a high margin revenue source for the car manufacturers.
Why should the software side of things be any different?
Some 20 years ago I was asked to prepare OS distribution with OTA upgrade capability for some PoS system. I think I prepared two system partitions and a custom MBR which would alternate the system partition on every start (uses one bit of non-volatile memory to alternate selection of partitions on each boot). When the system starts, it does self-test. If it fails the self-test it just restarts. If it succeeds -- it w…
That is very much standard.
Some 20 years ago I was asked to prepare OS distribution with OTA upgrade capability for some PoS system. I think I prepared two system partitions and a custom MBR which would alternate the system partition on every start (uses one bit of non-volatile memory to alternate selection of partitions on each boot). When the system starts, it does self-test. If it fails the self-test it just restarts. If it succeeds -- it w…
It’s a bit troubling that automakers (and, well, anyone who is building things that have mechanisms for software updates) aren’t making software updates failsafe. If you have multiple copies of the image on storage, and you take care not to touch the currently-running image, then a failed software update to the alternate image shouldn’t have any impact. Think of it like blue-green deployments on the cloud; and it’s w…
We should have a law for this. In most countries, new vehicles need to be tested by govt agencies before they are allowed to hit the road. The same should hold after software updates. Ideally, the update should be done by independent agencies, so they can make sure the software is tested and they can properly inform the user (something which we already know companies don't always do). The way it is now, it is all too…
I can hear the dejected software engineer that wrote or plugged in that error message after layers of bureaucracy
Not at all. Dejection and uncooperativeness render one a bad team player. The recruitment pipelines aggressively screen against these. Software engineers rarely care or have authority to be ethical gatekeepers.