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

71–80 of 196 posts

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

#71

Post by perlgeek »

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.

I don't find the idea absurd, especially for the entertainment system:

* it makes it easy to separately update different apps that are shown on the same screen

* it unifies the update process

* you can download the update in background while the app is running, easily roll back to an old version

* it's familiar technology to many engineers (you could call that lazy, but it also reduces risk)

* it's easier to use an existing networking implementation than having separate chips for each task, and then having to connect them through busses

* allows for pretty good resource sharing (RAM/CPU)

* pretty good isolation out of the box

I wouldn't want that for my engine controls, but navigation/radio/camera/climate control, why not?

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

#72

Post by jerf »

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.

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 only on the published API specs and not via dropping undocumented files on the file system or other such things. (Or if they do, you have a place to see that they have a weird bind mount they really shouldn't, etc.)

I wouldn't consider this a night & day change, but an incremental one. But a good incremental one overall; I wouldn't drop everything to implement this but I'd definitely see it as a good thing even in the absence of functionality improvements. There's other benefits too like being able to update just one container in case of some problem, and having the blast radius more thoroughly contained than it would be with everything installed into one big base system.

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

#73

Post by MuffinFlavored »

shrubble wrote: post #66

So it was poorly thought out or poorly designed all this time, then they fixed the obvious errors? That was my impression after reading the article...

makes you wonder what the aspects other than startup time probably look like?

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

#74

Post by bluGill »

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.

Not everything is developed by the single vendor. Sometimes they buy a program from a vendor they don't fully trust.

There is also security, I don't care if someone hacks my radio system nearly as much if someone hacks the brake system. Containers is one part of the total package to isolate parts so if there is a hack the whole system isn't taken out.

Computers are a large system. Someone in "the other group" making a mistake can bring your part of the system down. Much of the code is written in C or C++, and so one "old school" programmer can make a mistake and write past their memory into a data structure you are using, and the bug report goes to you not them.

If you have the above system, when splitting the monolith apart you will discover libfoo.so that both depend on, and the two groups will want to upgrade separately: containers allow this to happen, without modifying your build system to give them different versions or otherwise allow two different libraries with the same name to sit on your system.

The above is what is obvious enough that I can talk about it. (I work on an embedded system at John Deere so I cannot comment more than the above even if you ask.)

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

#75

Post by bottled_poe »

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…

You know what this car needs? Kubernetes.

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

#76

Post by import_awesome »

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.

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

#77

Post by talonx »

doubled112 wrote: post #51
talonx wrote: post #12

Earlier quoted context omitted.

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.

Exactly. When will vendors stop touting WiFi access as a "feature"?

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

#78

Post by goalieca »

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.

Half the time there’s a light on my car, it’s a damn sensor! More components mean more points of failure.

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

#79

Post by dtx1 »

bluGill wrote: post #64
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 should be, but right to repair is mostly not about diagnosis and repair. Instead you are seeing a bait and switch where someone wants to disable emissions controls and claims that is a repair. What can a mechanic not do to a modern car with the standard scan tools and training? Most old school mechanics still lack the training to work on computers, but those that have that training have no problem fixing cars.

> It should be, but right to repair is mostly not about diagnosis and repair. Instead you are seeing a bait and switch where someone wants to disable emissions controls and claims that is a repair.

Well first of all that happens even under the current draconian anti repair setups already and secondly thats a felony. Just because you can do sth illegal doesn't mean we should child proof our whole society so you can't do anything anymore just because someone MAY do something illegal.

We still allow you to buy knifes, in some places even guns.

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

#80

Post by rurounijones »

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.

I know you are joking but I am not sure if you are aware of how close you are to reality:

https://thenewstack.io/how-the-u-s-air-force-deployed-kubern...

Post reply on HN