111–120 of 196 posts
Earlier quoted context omitted.
More software is fine IMO. More software on critical path ain't. Have the ECU only do the engine thing. Have the AC control just do AC control. Decouple dependencies and make it as simple as possible. Old cars already do it. Blinker switch send signal directly to light controller, not to some central box deciding what it should do with it. If something needs config in addition to control signals, have it keep it own…
According to the car, the stability control system wasn't working. Cause? Obviously a broken fuel injector. The stability control system talks to the engine ECU to control the torque if there is a lack of traction - it is notified of this by the ABS computer. Broken Injector=No ability to manage torque, hence traction control warning. Sitting here now, that makes perfect sense. In horizontal Scottish rain - less so!
Earlier quoted context omitted.
I went to a "tech school" to learn computers while in High School in the 90's. The tech school also had classes for 'the trades', it was set up to prepare Michigan kids for careers (Careerline Tech IIRC). Anyway. A big part of that class was learning to clean, repair, and manage printers. Again, it was the 90's, and we were high school kids. We came out quite capable with many computer skills but the printer stuff re…
> The printers of today are awful landfill fodder compared to the Okidata's of the 90's. Pure simplicity and speed vs FULL COMPUTERS, with scanning, faxing, and every other imaginable feature crammed in with zero hope of doing anything other than replacing the toner. The first Laserwriter in 1985 had more processing power than the Macintosh it was sold to accompany. Printers have been full computers for a long time n…
I'm all for improvements to pod startup times etc, but the general idea of putting more software into cars is not that appealing. I recently broke down in the highlands of Scotland in a fairly new car with the family - it was a horrible experience. It was made worse by the fact that there was nobody close that had a clue what to do with the car. The breakdown service arrived promptly, plugged the diagnostic tool into…
You said it so well, cars have become too bloated with software that barely any local mechanic would want to touch it. Happened to me and this is the major reason why I am slowly shifting to older cars, they are way easier and cheaper to repair.
If you’re a kid and you also have IT skills you’re going to be interested in IT unless there are extenuating circumstances, like wanting to stay rural, or a family business, or friends and family with union influence. Easier on your body and pays at least as well. So a car mechanic with heavy IT or electrical skills is going to be in short supply. Which is a problem when all cars are electrified.
Earlier quoted context omitted.
Check Engine Light being on comes standard
Mechanics call this the money light. :)
Earlier quoted context omitted.
Sure, but if you provide the possibility to deploy a lot of components separately, at some point they will run in different versions. And who knows if rear view camera 1.3.22-44 works with turn signal 4.86.233-stable and break pedal 0.6.9876-beta?
Those 3 for the most part don't have to work together. They need to run on the same CPU without taking more than their allowed portion of the CPU. If they have to work together the communication protocol is clearly defined well in advanced and limited to exactly what they need to say. Thus we are reasonably sure if any one combination works all possible combinations will work. Even then there is typically higher leve…
Earlier quoted context omitted.
More software is fine IMO. More software on critical path ain't. Have the ECU only do the engine thing. Have the AC control just do AC control. Decouple dependencies and make it as simple as possible. Old cars already do it. Blinker switch send signal directly to light controller, not to some central box deciding what it should do with it. If something needs config in addition to control signals, have it keep it own…
You know what this car needs? Kubernetes.
> If the backup camera or other sensors were to run as containers, we needed to improve the starting speed significantly. I think I see the problem already. Why does anyone think its a good idea to put everything in an embedded system into a container? Particularly as everything comes from a single vendor and so the usual argument about "but libraries are too hard!" doesn't apply.
Do you oppose running camera software in a separate process? I think it makes sense. Camera process might crash and will be restarted, this should not cause restart of the entire shell. What people should understand is that container in Linux is just a separate process running in powerful chroot (which isolates not just file tree, but also process tree and other things). So the same reasoning which applies to running…