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

11–20 of 196 posts

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

#11

Post by dtx1 »

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…

That's imo a right to repair issue. We can build easily diagnosable and easily fixable hardware. Big Corps just don't

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

#12

Post by talonx »

rwmj wrote: post #10
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…

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

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

#13

Post by wiseowise »

andix wrote: post #8
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…

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?

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

#14

Post by Alifatisk »

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…

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.

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

#15

Post by interactivecode »

GordonS wrote: post #5
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.

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…

unless the update requires version updates on multiple services which means the versioning and rollback has the same effect as a more monolithic codebase. but with the added complexity of not knowing how it all impacts each other.

In my experience updates to smaller services are often trivial, or for updates that are actually impactful it would be way easier to coordinate in a monolithic codebase.

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

#16

Post by andix »

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?

It’s the same problem. But library authors usually take extra care to stay compatible.

And if you create your own shared libraries, they are normally not deployed separately, usually you bundle them with your main executable.

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

#17

Post by VBprogrammer »

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…

Heh, we were stuck in a carpark for 3 hours because the 2025 battery cell in our key remote went dead on a cold walk around a local lake.

It's supposed to have a backup but, like most backups, I hadn't tested that it works and for some reason the RFID reader part wouldn't connect with the car.

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

#19

Post by erinaceousjones »

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.

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 80% disk usage again but sucks teeth it's gonna cost ya. I'd recommend throwing the whole car out and getting a new one. You shouldn't get an attachment to these things, they're cattle not pets."

Truly breathtaking.

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

#20

Post by fredsted »

erinaceousjones wrote: post #19
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.

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…

Looks like your cars Kubernetes certificates have expired after a year, we'll need to SSH in and run kubeadm to refresh them. Wait, the 5G pod isn't starting ...
Post reply on HN