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 car, proclaimed it broken, called a tow truck and left - two days later we arrived home. Had I been in a less complex car, a local garage could most likely have fixed the problem and sent us on our way. The sophistication and gadgets in modern cars are great until something goes wrong then they fail hard. Small local garages that used to be a life saver are next to useless now as they don't have the tools and knowledge to fix a mobile data centre.
<i>> If the backup camera or other sensors were to run as containers, we needed to improve the starting speed significantly.</i><p>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 <i>"but libraries are too hard!"</i> doesn't apply.
> we did was analyze what happens when Podman starts a container and why it takes so long. It turns out there was a lot of low-hanging fruit.<p>I've done this analysis for lots of software before, Windows has a <i>really</i> nice tool called Process Monitor that I've used to find huge slow downs before. Point it at a process and it'll tell you the every bit of IO that the application does, and at that point you can just start digging and opening bugs.<p>IMHO almost every piece of software of any significant size horribly misbehaves. Opening the same file again and again, writing out lots of tiny temp files, reading the same key from the registry (or some config file) over and over again , and worst of all, using fixed timeouts waiting for a task to complete instead of doing the work to make things properly event based.<p>On that last note, timeouts instead of event callbacks (or some sort of signaling system) is the cause of so much slowness across our entire industry. If something you are doing on a computer takes a human noticable amount of time, and you aren't throwing around tens of GBs of data or waiting on a slow network, then you are flat out doing something wrong.
podman rootless and startup speed was what lured me in, sadly after a couple of years I've switched back to docker, bit happily in rootless mode now too.<p>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.<p>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.<p>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.<p>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.<p>docker was always a pleasure to work with, I still don't understand why I suffered with podman so long.
I'm happy to see improvements like this.<p>In 2018 I opened a github issue around container startup time[0] with Docker. A couple of things have changed since that issue but generally speaking we are talking about ~5s (containers) vs 150ms (no containers) to start a realistic process that depends on networking and other things you'd expect in a typical web app.<p>[0]: <a href="https://github.com/moby/moby/issues/38077">https://github.com/moby/moby/issues/38077</a>
Who said AI is killing dev jobs, now Devs have an alternative employment as a car mechanic.
Drop kubernetes or VMs into the car and DevOps guys can also join.
It would be so fun to hear "Umm your ingress seems to use older API, I have to update it for the gearbox to engage" and then see them run kubectl apply.
I am very likely one of only a few people but it really irritates me when the term "fold" is used when they really mean "times".<p>Folding a piece of paper (just like binary numbering) 6 times will provide you with a stack of 64 sheets.<p>They did not have a performance increase of 64 times.<p>This is identical to the idea of stating "magnitude" as being the number of times based on 10.<p>How wrong am I?
I didn't know they used containers in cars. I guess it makes sense when you think about it but it always felt like more of an "enterprise" solution to me.