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

171–180 of 196 posts

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

#171

Post by [deleted] »

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…

[deleted]

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

#172

Post by LoganDark »

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…

> More software is fine IMO.

A lot of software is created on powerful developer machines. But fill up a normal consumer machine with this software, and you start to notice that it maybe isn't so fine.

This is how things like Electron come to exist. I'm sure Electron works fine on developer machines, but once it trickles down to someone's cheap Celeron netbook, it runs worse than retro computers with 384KB of RAM.

Does it really have to be this way? Is more software "fine", if the same could be accomplished with much less code bloat?

P.S. As far as I've heard, one of the best ways for developers to combat this is to target your software for cheap netbooks proactively; test compiled artifacts there rather than on your powerful development machine. If you can make it fast in that situation, it'll be fast pretty much anywhere.

I once met someone who had optimized their DOOM clone using this method, and they claim to get millions of FPS on any vaguely modern machine, just through optimizing it for cheap netbooks.

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

#173

Post by ClumsyPilot »

ilyt wrote: post #143
hghid wrote: post #89

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!

Oh yeah, less computers in car wouldn't fix it. Sure, old carbie with distributor might've just ran with 3 cylinders , but that also might damage something. Also auto makers don't really want to give user sensible error messages or even just metrics because without experience they might just misinterpret it as different problem. For example if car have oil pressure gauge it is either nearly fake or heavily filtered.…

> Sure, old carbie with distributor might've just ran with 3 cylinders , but that also might damage something

A car is not an iPhone - if the car can move at all, it must move.

The alternative could be freezing to death. What if I am driving in rural Siberia, or Canada, and there is no phone signal to call for help?

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

#174

Post by ClumsyPilot »

jsmith45 wrote: post #134
BenjiWiebe wrote: post #122

Earlier quoted context omitted.

A bad fuel injector should usually be a reason to stop driving. Depending on the type of damage it would likely damage the piston and/or cylinder fairly quickly if you attempted to keep running it.

That would obviously depend on the failure mode. But there certainly are failure modes which could be quite damaging, and an ECU may have limited ability to determine what failure mode is occurring, and even if it has sensors that can indicate certain failure modes, it is not always clear if those can be trusted, as they there be additional failure modes that make sensors give misleading results. So shutting it down…

There are situations where you must run the car, even at the risk of damage, because waiting for help is dangerous to the occupants.

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

#175

Post by ClumsyPilot »

import_awesome wrote: post #76
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…

If you had a little more software in your car it could automatically remediate the issue and you'd be on your way with no repairman involved or at least tell the repairman exactly what to fix. Maybe you could fix it with the step-by-step workflow on your console.

> it could automatically remediate the issue and you'd be on your way with no repairman involved or at least tell the repairman exactly what to fix

Nah it would figure out what is the best time and place to break, order you an uber, and Uber would psy you manufacturer for the order flow.

It would also show you ads while you wait

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

#177

Post by pikelet »

kobalsky wrote: post #158

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

That's pretty much my experience! I've tried switching to podman a few times now and I really wanted to like it. Each time lasting a few months, and it always ends with frustration. At this point it's like btrfs for me. Perhaps it has improved, but I've been burned too many times, the trust is gone and I just will not go back. Some software just seems to have fundamental design issues (too fast, too early?), and when that's the case, more often than not it doesn't matter how many years of development go into it, it will always have problems.

Docker isn't perfect. I wish they would put more development into rootless mode. But it has never given me the kind of issues podman has. It just does what I ask it to and gets out of the way.

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

#178

Post by dockman »

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…

I for one am very happy that RedHat is putting in these efforts to improve startup time of podman. This is extremely necessary if our industry has to survive. Last time we tried using podman in our product, it was such a performance mess. We had to completely abandon our product. Our product would have disrupted the entire juicer market if podman was efficient at that time, our's was the only juicer which had containers running in it.

Hoping to get back to it once this version of podman is released. Thank you RedHat team; we'll send you one of our juicers as a thank you gift.

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

#179

Post by lmz »

jerf wrote: post #72
lmz wrote: post #36

Earlier quoted context omitted.

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

It buys you conformance to Conway's Law. The team building the media center is that much more certain that the climate control code is fully isolated, up to and including the ability to have their own fully isolated filesystem so updating a single library won't take anything else down (and updating a single library doesn't require buy-in from everybody who works on the car), and that they only communicate exactly and…

I'm not saying that containers are useless and it is more sealed than just separate UIDs, but in theory you could have all those benefits with separate paths for separate users too. Didn't Android also use UIDs for app level separation?

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

#180

Post by kakoni »

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.

Well Volkswagen/Cariad is certainly flirting with that idea. https://datatronic.hu/en/containerisation-in-automotive-indu...
Post reply on HN