151–160 of 196 posts
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…
>a local garage could most likely have fixed the problem So, what was the problem?
All this because nobody wants to change the ELF loader to better isolate dependencies of binaries
I think it's more because Linux OS developers have never bothered to move away from Unix's "all apps get mixed together at absolute locations" filesystem model. If apps were like on Mac - self-contained directories that can be installed at any path - then Docker would probably be a footnote.
There is DT_RUNPATH probably since before I was born. The problem is it's not always utilised, distributions prefer to share libraries over isolating applications, and loading shared libraries isn't the only host-dependent thing done by application code.
Also you realise that docker provides more functionality than a tarball, right?
Earlier quoted context omitted.
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!
My car has a button for traction control. If it’s not working I would expect it to turn itself off and ding, not just halt the vehicle.
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…
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…
> The sophistication and gadgets in modern cars are great until something goes wrong I'd go further than cars and say, "in most things". Smart-anything, washing machines, printers, sewing machines, thermostats, appliances in general... My mother in-law has two sewing machines. One of them is one of the first electronic sewing machines (from the 70s) and one is much older. Guess which one still works like a charm? I'm…
There's a bit of survivorship bias and N=1 here.
I'm old enough to remember machines full of relays and discrete components that failed pretty often and required a lot of troubleshooting with schematics on hand. Modern appliances – if built out of decent components – have a much better shot at surviving long term. Less discrete components that can fail, more debugging capabilities, logic that's implemented in a rock solid processor rather than an unreliable mess of digital gates (or worse, analog logic).
There's obviously a point where there are diminishing returns, and probably another one where more complexity actually decreases reliability.
> Smart things would ideally just revert back to being functional dumb things (rather than bricks) if their electronics fail.
If possible, yes. That's only really an option for simple devices.
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…
Maybe. But how expensive were they?
I can buy a good laser printer for under $200 these days. It will be more compact, lighter, mechanically simpler and use way less power than older printers. Something has to give.
Some older printers were really overengineered (which in many cases did make them more reliable), but that has a cost. Turns out, consumers didn't want to pay those costs.
podman works fine until it doesn't. My hypothesis is that it has some fundamental design philosophy that makes it brittle. Properly cleaning up doesn't exist in their vocabulary.
For example, a cancelled download or image extraction can bring the whole thing down at the worst time, you have to hunt down the corrupted folder and remove so that anything works again.
A failed compose startup can leave the network in a undefined state hard to diagnose and impossible to recover without wiping some folders within /run/user and killing some rogue processes manually.
This is further cemented by the fact that a lot of minor issues are answered with: podman system reset, which reeks of rm -fr node_modules.
docker was always a pleasure to work with, I still don't understand why I suffered with podman so long.
Why does a car even need to run containers? It's a known hardware, so why containers? Feels like lazy engineering.
When you ask, why containers?, reask, why sandboxes? if security is important at all, then you have your answer.
Containers are so convenient people forget we used to use chroot jails.
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!