Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We achieved a 6-fold increase in Podman startup speed

redhat.com

Post reply on HN
Print view View original

91–100 of 196 posts

Re: We achieved a 6-fold increase in Podman startup speed

#91

Post by cztomsik »

bottled_poe wrote: post #75
ilyt wrote: post #28

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.

Or Erlang... oh wait, that would actually work. We don't want that.

Re: We achieved a 6-fold increase in Podman startup speed

#92

Post by aaravchen »

wiseowise wrote: post #13
andix wrote: post #8

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?

How is that different from shared libraries?

Because you can prove it. In the auto industry you can't just claim it conforms, you have to prove it does for all possible conditions. With containers enforcing that separation, you can prove it much more easily.

Re: We achieved a 6-fold increase in Podman startup speed

#93

Post by speed_spread »

ilyt wrote: post #28
hghid wrote: post #4

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…

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…

The ECU wasn't doing the engine thing no more.

Re: We achieved a 6-fold increase in Podman startup speed

#94

Post by intelVISA »

andix wrote: post #6
rwmj wrote: post #3

> 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.

I agree. Microservices are a great concept for a lot of problems. But now I constantly see way too small services. Every tiny piece of software gets its own service and its own software lifecycle (including versioning and deployment). And what happens now is, that you need a huge effort to integrate all those components. End to end system tests get much more important, but are still harder to do than simple unit/inte…

Excessive microservices is lazy engineering. It doesn't solve any problems - they just get moved to the next quarter, or some other team.

Re: We achieved a 6-fold increase in Podman startup speed

#95

Post by aaravchen »

ClumsyPilot wrote: post #9
GordonS wrote: post #5

Earlier quoted context omitted.

Playing Devil's advocate here, but there are some good reasons you might do this. For example, Docker's "pull" system is great for updates, and means it's trivial to rollback to an earlier version if something went wrong. A Docker registry also means you can easily switch to another version when needed. You also get a supervision of containers, with automatic restarts (yes, I know you can do this nowadays with system…

A statically compiled executable is even easier, and can be hosted on your webserver

But unfortunately they also become very space inefficient when a lot of processes need the same (relatively) large blocks of code. But if you carefully curate your containers to use the same base image that contains those libraries already, you don't have to duplicate it.

Comparable would be to having an inode de-duplicating file systems, and deterministic binary generation. But it's hard to prove "the correctness" of inode de-duplicating file systems in extreme environments like auto is required to, and deterministic binary generation is hard to control 3ven if it is possible with the specific build tools (it usually isn't).

Re: We achieved a 6-fold increase in Podman startup speed

#96

Post by chubot »

bottled_poe wrote: post #75
ilyt wrote: post #28

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.

Make sure to run at least 2 clusters in case one goes down

Re: We achieved a 6-fold increase in Podman startup speed

#97

Post by Alifatisk »

potta_coffee wrote: post #85
Alifatisk wrote: post #14

Earlier quoted context omitted.

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.

I drive older Toyotas. These cars will never go into the landfill if I can help it.

But cars from Japan & Korea have always felt reliable no matter the age.

At least from my experience.

Re: We achieved a 6-fold increase in Podman startup speed

#98

Post by stfutechbros »

ElectricalUnion wrote: post #87
steveBK123 wrote: post #32

Earlier quoted context omitted.

agreed, id like to know so I can avoid buying them

Do we know which cars specifically run their applications without any sort of containers, just everything thrown in the same userland without any care for security?

If the security of it is a concern, then it's already doing too much.

Re: We achieved a 6-fold increase in Podman startup speed

#99

Post by briffle »

christophilus wrote: post #23
hghid wrote: post #4

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…

My grandma had an original "Montgomery Wards" microwave.. they saved up for months to buy it when it came out. Complete with a rotary dial timer.

Never serviced, always cooked perfectly. She had to get rid of it around 2006 or so, when she got a pacemaker.. They didn't shield them as well back then...

Re: We achieved a 6-fold increase in Podman startup speed

#100

Post by rusk »

garaetjjte wrote: post #83
vbezhenar wrote: post #52

Earlier quoted context omitted.

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…

Containers usually ship their own libraries, which means less sharing, more disk usage and higher memory pressure.

I see these as a relatively straightforward set of problems to identify, quantify, and remedy. It’s a tradeoff between static memory usage and stability. If that additional memory footprint becomes an issue you can make plans to align dependencies.
Post reply on HN