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

51–60 of 196 posts

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

#51

Post by doubled112 »

talonx wrote: post #12
rwmj wrote: post #10

Earlier quoted context omitted.

"yum", "apt" etc have registries, roll back etc and have for a good few decades.

But..but..they are not "cool" This forced application of new technologies into every possible domain can have real security and reliability consequences - and all because some VP somewhere decided they needed to use the latest shiny thing in cars or fridges or ACs or whatever.

Imagine we could build a dishwasher that didn't throw water on the floor?

Oh well, we got WiFi instead. That's fun, right?

If a dishwasher needs a firmware update, I might simply argue it was defective. Not everything needs to be secure or updated constantly. It shouldn't have network access to begin with.

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

#52

Post by vbezhenar »

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.

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 some code in a separate process also applies to running some code in a separate container.

I'd even argue that in an ideal world, almost every process should run in a separate container. The tooling is not here, but concept is just fine.

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

#53

Post by TheCondor »

manojlds wrote: post #26

Why does a car even need to run containers? It's a known hardware, so why containers? Feels like lazy engineering.

What of all the security and authenticity efforts? And the idea that you include the runtime in your delivery, you develop against something like red hat enterprise 8’s glibc and some other libs and that’s what you test and that’s what you ship, it’s all in a container. If you put an sbom on there that the car maker verifies, that seems good. Resource constraints per component seem good.

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

#54

Post by TheCondor »

blueflow wrote: post #48
imp0cat wrote: post #27

Earlier quoted context omitted.

Perhaps you want to somehow isolate different parts of the car to protect against somehting like the CAN bus attack?

Containers do isolation in userspace, its a pure software thing. Its not doing any kind of hardware isolation nor is it able to.

Don’t they use cgroups? It’s software but the kernel helps.

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

#55

Post by cowl »

lmz wrote: post #36
manojlds wrote: post #26

Why does a car even need to run containers? It's a known hardware, so why containers? Feels like lazy engineering.

Isolation berween apps? Although not sure what that would buy over just having separate UIDs.

easier done with dedicated Controllers instead of one BIG controller that needs to containerise its software? Why does the rear camera and lights need to use the same controller as the Engine sensors? This way you even avoid the latest "CAN bus injection attack" that are using the lights connection to inject Key Crypto attacks. not everything needs to be integrated.

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

#56

Post by anaganisk »

carlmr wrote: post #49
dtx1 wrote: post #11

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…

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 does it save a lot of money for consumers and is much better for the environment? Yes! If companies are greedy/selfish about their profits then consumers don't need to think about how right to repair hurts those companies.

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

#57

Post by pixl97 »

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…

>a local garage could most likely have fixed the problem

So, what was the problem?

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

#58

Post by overthrow »

carlmr wrote: post #49
dtx1 wrote: post #11

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…

The liability excuse is a lie told to you by companies trying to increase their profits.

Who is liable if you tweak the software on your 2023 Mercedes? The same person who is liable if you tweak the hardware on your 1987 Chevy. There's plenty of precedent on how to deal with this.

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

#59

Post by anaganisk »

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.

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

#60

Post by nickjj »

I'm happy to see improvements like this.

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.

[0]: https://github.com/moby/moby/issues/38077

Post reply on HN