101–110 of 196 posts
Earlier quoted context omitted.
That's imo a right to repair issue. We can build easily diagnosable and easily fixable hardware. Big Corps just don't
It's also a liability issue. If a company allows tinkering with the software in the car it opens itself up to massive lawsuits. If we have a right to repair here, we also need to see how to handle liability here. If you flash your own software on the motor controller and subsequently mow through a group of people because you forgot to do a plausibility check on the accelerator pedal value who takes responsibility the…
I would, obviously, for making the unsafe modification. In what multiverse would the manufacturer be liable for something entirely outside the manufacturer's control?
Earlier quoted context omitted.
Containers usually ship their own libraries, which means less sharing, more disk usage and higher memory pressure.
That depends on implementation. Shared libraries which use the same inode will be shared AFAIK. If containers use different libraries, they'll not be shared, of course, but that's a deliberate choice of container creator.
Earlier quoted context omitted.
Lol, this is absolute funny, every example you came up with has already been there for years. Aren't cars being modded every day, ECU tuning, engine mods, etc? Go ahead sue the company, companies aren't some innocent babies, they can afford to quickly dismiss the claim by just pointing towards the mod. Auto Companies have never been held liable for a car that has been modded. Does it waste money to be sued? Yes! But…
The EPA has suggested they will hold companies liable in the future. It hasn't happened yet, but they are hinting. If it is just one hobbyist they don't care, but there is a whole industry of chip your diesel truck and those chips clearly increase pollution. A modern diesel truck doesn't emit black smoke, but a large % of the diesel trucks you see are "rolling coal" which is a sure sign that someone has disabled the…
The EPA can suggest all it wants. Holding one entity liable for the actions of an entirely different entity beyond the control of the former's is asinine, and I can guarantee you these automakers will gladly sic their armies of lawyers at a Supreme-Court-bound case and/or their armies of lobbyists at legislatively castrating the EPA if the EPA made any such attempt.
On top of that, the EPA is virtually irrelevant for EVs, and yet EVs are just as locked down (if not moreso), so I don't buy the "EPA might punish us" argument for that reason, too.
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.
To be honest I think we should be adopting the full ecosystem we've been busy building around containerization. Imagine calling up breakdown assistance because your car won't start, mechanic comes out, cracks the hood and is like "ah there's your problem right there, ignition service has only 1/2 pods healthy because the node went into NotReady due to DiskPressure. I can clear up some log files so it goes underneath…
Earlier quoted context omitted.
If something like that needs to be smart the smart part should basically be extra interface. Old printers did it right - separate extra box for all the connectivity working as print server. That breaks ? just connect it directly. But hey, feeding everything from single microcontroller is $2 cheaper...
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 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 now. As we expect them to do more and more, the computers in them get more and more complex.
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.
Fwiw - I am a kubernetes fan. Just not in cars.
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.