[HN Gopher] We achieved a 6-fold increase in Podman startup speed
___________________________________________________________________
We achieved a 6-fold increase in Podman startup speed
Author : DrinkWater
Score : 355 points
Date : 2023-04-13 06:31 UTC (16 hours ago)
(HTM) web link (www.redhat.com)
(TXT) w3m dump (www.redhat.com)
| perlgeek wrote:
| Do we know which cars specifically run their applications in
| containers?
| steveBK123 wrote:
| agreed, id like to know so I can avoid buying them
| ElectricalUnion wrote:
| 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?
| stfutechbros wrote:
| If the security of it is a concern, then it's already doing
| too much.
| anaganisk wrote:
| 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.
| rwmj wrote:
| _> 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.
| bluGill wrote:
| 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.)
| spyremeown wrote:
| https://www.toradex.com/torizon they do and it works quite
| well. Super handy to have CI/CD and easy OTA updates with
| containers.
| erinaceousjones wrote:
| 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.
| yellowapple wrote:
| Can't wait to plug in an ODB2 scanner and get a k9s screen.
| fredsted wrote:
| 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 ...
| wpietri wrote:
| You joke, but I decided I wanted to try out Kubernetes, so
| I set it up at home and moved some of my local services
| into it, one of them being my custom lighting automation
| software. Eventually my lights just stopped working, and
| after a lot of rummaging it turned out to be expired
| certificates. I promptly put the software back where it was
| before, removed Kubernetes, and decided there were better
| things for me to play around with.
| GordonS wrote:
| 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 systemd :)
| interactivecode wrote:
| 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.
| steveBK123 wrote:
| yes my first job over 15 years ago was essentially micro
| services, and we ran into this type of problem..
|
| trivial updates to individual services could be iterated
| extremely quickly
|
| systematic changes to behavior across services were so hard
| they became incredibly uncommon
| qprofyeh wrote:
| Yup, I can imagine complete images are easier to version-
| manage and to tag as minor/major/hotfix than each individual
| part of the stack.
|
| I think people underestimate the amount of software that is
| ALREADY running in their cars/airplanes/helicopters and even
| elevators.
| andix wrote:
| 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?
| wiseowise wrote:
| How is that different from shared libraries?
| andix wrote:
| 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.
| aaravchen wrote:
| 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.
| solatic wrote:
| Shared libraries are bundled into one container, then the
| one container is submitted to a gauntlet of tests
| (service / API-level tests, e2e tests, etc.).
|
| If you're submitting an embedded device to a gauntlet of
| tests, you're anyway "containerizing" all the shared
| libraries when you build the embedded image. Trying to
| build containers within the embedded image has
| questionable merit.
| bluGill wrote:
| Those 3 for the most part don't have to work together. They
| need to run on the same CPU without taking more than their
| allowed portion of the CPU.
|
| If they have to work together the communication protocol is
| clearly defined well in advanced and limited to exactly
| what they need to say. Thus we are reasonably sure if any
| one combination works all possible combinations will work.
| Even then there is typically higher level control to only
| release combinations that are tested to work together.
| andix wrote:
| That sounds good in theory. The reality I live in, is
| different though. If it works for you, that's great!
| ClumsyPilot wrote:
| A statically compiled executable is even easier, and can be
| hosted on your webserver
| aaravchen wrote:
| 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).
| rwmj wrote:
| "yum", "apt" etc have registries, roll back etc and have for
| a good few decades.
| talonx wrote:
| <sarcasm>But..but..they are not "cool" </sarcasm>
|
| 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.
| doubled112 wrote:
| 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.
| talonx wrote:
| Exactly. When will vendors stop touting WiFi access as a
| "feature"?
| ilyt wrote:
| And when you upgrade ssl lib now 200 apps are not
| vulnerable to exploit, vs updating 200 different containers
| ilyt wrote:
| Especially a thing that should be just "a device that puts
| video stream on whatever bus it uses". infotainment already
| uses html/js based UIs, just embed video player in there...
| [deleted]
| [deleted]
| andix wrote:
| 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/integration tests. traditional testing strategies start to
| get pointless, because most bugs now only appear when combining
| services in a production setup.
|
| Yes, development gets easier, because every team can just
| develop, without aligning too much with other teams. But the
| deployment/ops/acceptance step often gets impossibly complex.
| zokier wrote:
| You are blaming cultural issues on technology. You have the
| same integration pains with libraries too. In general if your
| teams are not aligned, it doesn't really matter if they are
| developing microservices, libraries, or one spaghetti ball
| mess, its going to be problem anyways
| goodpoint wrote:
| > You are blaming cultural issues on technology
|
| Because technology almost always carries cultural values
| with it.
| ilyt wrote:
| The old method of forcing everyone to freeze at certain
| dependencies also means that any bug in those dependencies
| is fixed in all components at once.
|
| Obviously going too big here is problematic as it can slow
| it down when tens or hundreds of people are involved in
| every update, but going too small have similar problems, on
| top of generally more smaller services eating more
| resources. We don't need "front reflector LED setting app"
| being called from "lighting setting app" called from "car
| setting app", it can probably just be one service.
|
| Smaller services also mean more services to update if some
| commonly used lib gets a security bug. Updating SSL lib in
| big monolith is just update, run tests, but in
| microservices that's multiplied by amount of teams and
| services.
|
| > In general if your teams are not aligned, it doesn't
| really matter if they are developing microservices,
| libraries, or one spaghetti ball mess, its going to be
| problem anyways
|
| Moot point. We pick the tools to make the job easier. Good
| team with bad tools will still be slower and less efficient
| than good team with good tools.
| intelVISA wrote:
| Excessive microservices is lazy engineering. It doesn't solve
| any problems - they just get moved to the next quarter, or
| some other team.
| vbezhenar wrote:
| 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.
| IshKebab wrote:
| It's not _just_ the camera process though - containers ship
| an entire OS (except the kernel).
| aljarry wrote:
| Though you don't need most of the OS - you may run bare
| bones containers with just a statically built binary inside
| the image, e.g. it's possible in Go.
| garaetjjte wrote:
| Containers usually ship their own libraries, which means less
| sharing, more disk usage and higher memory pressure.
| goodpoint wrote:
| And much lower chances of getting security updates, now
| that everything is a huge blob.
| rusk wrote:
| 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.
| vbezhenar wrote:
| That depends on implementation. Shared libraries which use
| the same inode will be shared AFAIK. If containers use
| different libraries, they'll not be shared, of course, but
| that's a deliberate choice of container creator.
| bonzini wrote:
| Containers can use the same base image for the OS.
| jpgvm wrote:
| I think if you open up a Tesla infotainment system you would
| find something eerily similar to containers. Remember that what
| you and most programmers think of containers is merely one
| possible assembly of a bunch of kernel features. There exists
| not just a gradient between plain processes and containers but
| a whole solution space with different tradeoffs.
|
| I happen to know a small amount of the Tesla internals and they
| are using cgroups, namespaces, app armour and ebpf based
| syscall filtering to secure various processes on the car.
|
| You almost certainly should not use docker or podman to manage
| processes on a car but that doesn't mean you shouldn't embrace
| the subsystems they are built on in order to increase security
| resilience and defense in depth.
| galangalalgol wrote:
| Everything _never_ comes from a single vendor. Even
| microcontrollers the hardware abstraction layer is hiding
| peripheral support packages for all the i2c and spi things it
| talks to, each from a different vendor potentially.
|
| I'm not saying we should be running k8 on an 8051 or even a
| cortex m33, but on an arm7? Maybe.
|
| Cult of Ferris time, static linking in rust means your binary
| is your container, particularly if you statically link in musl.
| manojlds wrote:
| Why does a car even need to run containers? It's a known
| hardware, so why containers? Feels like lazy engineering.
| lmz wrote:
| Isolation berween apps? Although not sure what that would buy
| over just having separate UIDs.
| jerf wrote:
| 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.
| cowl wrote:
| 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.
| ElectricalUnion wrote:
| > easier done with dedicated Controllers instead of one BIG
| controller
|
| This bring costs and supply chain issues, and we had plenty
| of supply chain issues earlier this year.
| kobalsky wrote:
| if it runs linux already using containers has no overhead with
| a lot of pros. Security just being one.
|
| When you ask, why containers?, reask, why sandboxes? if
| security is important at all, then you have your answer.
|
| Containers are so convenient people forget we used to use
| chroot jails.
| TheCondor wrote:
| 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.
| perlgeek wrote:
| 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?
| IceWreck wrote:
| Why would you run podman inside a vehicle's computer. Cool
| nonetheless.
| imp0cat wrote:
| Perhaps you want to somehow isolate different parts of the car
| to protect against somehting like the CAN bus attack?
| blueflow wrote:
| Containers do isolation in userspace, its a pure software
| thing. Its not doing any kind of hardware isolation nor is it
| able to.
| TheCondor wrote:
| Don't they use cgroups? It's software but the kernel helps.
| ElectricalUnion wrote:
| Well you can ignore all sorts of Compartmentalization and run
| everything in the same cgroup, same chroot, same user, like how
| it is on conventional x86_64/aarch64 computers. It just isn't
| safe.
| jensenbox wrote:
| I am very likely one of only a few people but it really irritates
| me when the term "fold" is used when they really mean "times".
|
| Folding a piece of paper (just like binary numbering) 6 times
| will provide you with a stack of 64 sheets.
|
| They did not have a performance increase of 64 times.
|
| This is identical to the idea of stating "magnitude" as being the
| number of times based on 10.
|
| How wrong am I?
| mongol wrote:
| I didn't know they used containers in cars. I guess it makes
| sense when you think about it but it always felt like more of an
| "enterprise" solution to me.
| pqb wrote:
| AFAIK, Red Hat is working collaboratively with General Motors
| [0]. There is one article [1] on their blog regarding the
| containers in cars. I haven't found many technical information
| in it, but maybe you will find anything pleasing your eye.
|
| [0]: https://www.redhat.com/en/about/press-releases/red-hat-
| and-g...
|
| [1]: https://www.redhat.com/en/blog/running-containers-cars
| hghid wrote:
| 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 car, proclaimed it
| broken, called a tow truck and left - two days later we arrived
| home. Had I been in a less complex car, a local garage could most
| likely have fixed the problem and sent us on our way. The
| sophistication and gadgets in modern cars are great until
| something goes wrong then they fail hard. Small local garages
| that used to be a life saver are next to useless now as they
| don't have the tools and knowledge to fix a mobile data centre.
| emacdona wrote:
| Hmmm... maybe this thread will have an answer to the question
| that has been on my mind for a while. Sometime in the next 5-7
| years, I think I'm going to be in the market for a new car. Are
| there any manufacturers out there whose niche is "dumb cars"?
| If so, they can have my money.
| Alifatisk wrote:
| 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.
| potta_coffee wrote:
| I drive older Toyotas. These cars will never go into the
| landfill if I can help it.
| Alifatisk wrote:
| But cars from Japan & Korea have always felt reliable no
| matter the age.
|
| At least from my experience.
| hinkley wrote:
| IT people with mechanical sympathy aren't exactly an
| endangered species but we are rare enough that it becomes a
| bonding exercise (leatherman knives or pocket flashlights are
| our shibboleths).
|
| If you're a kid and you also have IT skills you're going to
| be interested in IT unless there are extenuating
| circumstances, like wanting to stay rural, or a family
| business, or friends and family with union influence. Easier
| on your body and pays at least as well. So a car mechanic
| with heavy IT or electrical skills is going to be in short
| supply. Which is a problem when all cars are electrified.
| miah_ wrote:
| Its not just software though, even the lights on your cars
| now are not easily user serviceable anymore. New cars with
| LED lights built in have core charges/deposits attached to
| them, they cost multiple hundreds of dollars and if you want
| to get your core deposit refund you must return the light.
| Compared to 15+ years ago, you go to your local store, buy a
| new light for $10-30, replace it and you're on your way.
|
| Ford apparently ended the core charge program for lighting in
| 2020, but other manufactures continue, and that is just one
| thing that was common for users to service themselves in the
| past. It's not going to get better.
| hghid wrote:
| Same here - I have owned an old petrol Vauxhall for years as
| my runaround car and it's so much easier to deal with. The
| big issue I have with newer cars is that the computers mask
| any developing issues until they get to a point when they
| just give up. A less sophicsticated car starts to just feel
| different a long time before it outright fails.
| doubled112 wrote:
| The MkIV diesel Jetta I had seemed to fall into limp mode
| at the slightest provocation, but never left me stranded.
|
| Trust me, it is a difference you can feel.
| VBprogrammer wrote:
| 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.
| tough wrote:
| Are 2025 battery cells batteries from the future?
| amrb wrote:
| A type of battery the small round one.. not the year
| tough wrote:
| Thanks, that makes much more sense
| xarope wrote:
| assuming this is a cr2025 then most likely 20mm diameter
| and 2.5mm thick => 2025
| bookofjoe wrote:
| this is the most useful thing I've learned so far this
| year
| jsmith45 wrote:
| Yeah almost certainly talking about a CR2025.
|
| Use of a 2025 cell would be rather irritating to me,
| because in my experience CR2016 or CR2032 are both more
| common, and it seems like it should not be hard to fit a
| 2032 into most keyfob designs.
| import_awesome wrote:
| 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.
| goalieca wrote:
| Half the time there's a light on my car, it's a damn sensor!
| More components mean more points of failure.
| bookofjoe wrote:
| Check Engine Light being on comes standard
| bityard wrote:
| Mechanics call this the money light. :)
| bookofjoe wrote:
| Indeed. When I took my car in last winter because the
| light had come on for no apparent reason, as the car was
| running fine, they charged me $140 to take it out on the
| road to try to find the reason. No reason was found. Two
| weeks later, the light came on again (towards the end of
| 2022). The car was and is running fine. The light will
| remain on until July when I take it in for a scheduled
| oil change.
| generalizations wrote:
| Or you could buy a $20 code reader and see what's causing
| the light yourself.
| bookofjoe wrote:
| But the mechanics using their professional grade code
| reader and related equipment couldn't figure out what's
| causing it. At least I'm comfortable with "unknown" after
| that's their diagnosis; I don't think that would be the
| case if I did it and got that result.
| ilyt wrote:
| 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 config and only be updated from the "config
| manager" (inforatinment box). If infotainment box dies,
| everything else still works.
|
| Cars already are basically "microservices on a message bus".
| Let's just use what works with that - minimal coupling and
| maximum independence of "services"
|
| > Had I been in a less complex car, a local garage could most
| likely have fixed the problem and sent us on our way. The
| sophistication and gadgets in modern cars are great until
| something goes wrong then they fail hard. Small local garages
| that used to be a life saver are next to useless now as they
| don't have the tools and knowledge to fix a mobile data centre.
|
| Out of curiosity, what was the issue ?
| hghid wrote:
| 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!
| gnufx wrote:
| That sounds horribly familiar! (Old, relatively non-fancy,
| Ford Focus; it limped along with the failure.) The
| explanation makes sense, which it didn't at the time, and
| the traction control button didn't help. The specialist
| garage initially said "sensor failure", as I assumed,
| having lost my OBD device.
| uriah wrote:
| Unless I'm missing something, it seems that this
| information largely invalidates the thesis of your previous
| post. A critical component (fuel injector) failed, the
| software in the car prevented it from running and causing
| catastrophic damage. Roadside assistance came, immediately
| determined it can't be fixed on the side of the road and
| towed the car. Seems like a best-case scenario given the
| circumstances other than possibly the red herring related
| to the stability control.
| thescriptkiddie wrote:
| Assuming that the fuel injector wasn't stuck open, the
| car could simply disable the affected cylinder and
| continue to run (poorly) in limp mode. I had exactly this
| happen in a 20 year old VW and it turned out that the
| injector was fine and the connector had just come loose.
| The engine sounded awful running on 3 cylinders and
| wouldn't go past 3000 rpm but there was no permanent
| damage. The fault code in the ECU correctly identified
| the problem (fuel injector cylinder X open circuit)
| though it did also log misfires and disable traction
| control.
| hinkley wrote:
| My car has a button for traction control. If it's not
| working I would expect it to turn itself off and ding, not
| just halt the vehicle.
| BenjiWiebe wrote:
| 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.
| jsmith45 wrote:
| 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 certainly seems sensible.
| danuker wrote:
| But what cash grabbing opportunity would the dealer have
| in that case?
| Too wrote:
| Cars have a "limp-home" mode which they enter if sensors
| show odd yet not critical errors. Usually it restricts
| the acceleration and top speed to 30kmph or so. If it
| totally shut down it was likely a very serious error.
| ilyt wrote:
| 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. Oil pressure changes
| according to load but gauge going up and down might cause
| user to think something is wrong with car...
| speed_spread wrote:
| The ECU wasn't doing the engine thing no more.
| capableweb wrote:
| > More software is fine IMO. More software on critical path
| ain't.
|
| Based on the story in the parent, it sounds like this was
| precisely a problem with software on the critical path,
| otherwise local mecs/breakdown service would have been able
| to fix it rather than give up.
| bottled_poe wrote:
| You know what this car needs? Kubernetes.
| geodel wrote:
| Agree. I am not buying any car not running all software
| components as Spring Boot micro services in kubernetes
| cluster as a standard cloud native service.
|
| If this setup can run my 95% uptime enterprise apps, I am
| sure as hell it can run my car too.
| ilyt wrote:
| Most infotainment is already shit code. If same people
| use more tools the result will just be worse, if they
| can't even handle a monolith
| birdyrooster wrote:
| I know you are joking but it's actually not the worst thing
| in the world.
| vasco wrote:
| Can't wait to have to restart a kubernetes cluster to get
| sensor metrics from the engine to start again.
| yobert wrote:
| You'll need to replace your kubernator!
| rurounijones wrote:
| 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...
| groestl wrote:
| Literally taking the software to the cloud
| cpufry wrote:
| wow this is terrifying lmao
| davnicwil wrote:
| That's a bit overengineered, come on, really it just needs
| docker compose.
| gautamdivgi wrote:
| Lol. Reminded me of this - https://youtu.be/cfTIjuW6SWM
|
| Fwiw - I am a kubernetes fan. Just not in cars.
| Spivak wrote:
| If you're a k8s fan but don't consider it reliable enough
| to do anything even next to but independent from safety
| critical systems then that's not exactly a glowing
| recommendation.
| goodpoint wrote:
| And yet it's true. Reliability never comes from
| unnecessary complexity.
| gautamdivgi wrote:
| Different tech has different needs. I can see it being
| really great with server side distributed systems. I
| don't really see it having any benefit for running stuff
| in resource constrained single purpose environments
| hinkley wrote:
| Watch us slowly reimplement Erlang on top of OCI.
| alpaca128 wrote:
| To be precise an incomplete, bug-ridden, undocumented
| reimplementation of Erlang.
| Spivak wrote:
| Erlang but language independent is actually a solid
| pitch.
| chubot wrote:
| Make sure to run at least 2 clusters in case one goes down
| cztomsik wrote:
| Or Erlang... oh wait, that would actually work. We don't
| want that.
| yellowapple wrote:
| A car built on Erlang would break down every 11 seconds
| but would immediately fix itself so you never notice
| anything's wrong.
| hinkley wrote:
| Supervisors should set Check Engine.
| djbusby wrote:
| Carbernetes. Now with reinvented wheel functionality.
| EntrePrescott wrote:
| and a few years later, we get Injecternetes ... though
| I'm not sure if that will be the name of an improved
| fork... or the name of a security vuln exploit.
| Zaskoda wrote:
| graceful degradation ftw
| Gordonjcp wrote:
| _You take out your picnic basket_
|
| _' cos the car has blown a gasket_
|
| _in the middle o ' a place called Rannoch Moor_
|
| https://l-hit.com/en/143370
| hghid wrote:
| Haha - that summed up my day perfectly!
| christophilus wrote:
| > 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 not arguing against electronics, here-- many of these
| things are no doubt improved by electronics to such a degree
| that the tradeoff is worth it, but it's good to at least
| acknowledge that there _is_ a tradeoff. It 's also good to try
| to minimize the impact of electronic failure. Smart things
| would ideally just revert back to being functional dumb things
| (rather than bricks) if their electronics fail.
| ilyt wrote:
| If something like that needs to be smart the smart part
| should basically be extra interface. Old printers did it
| right - separate extra box for all the connectivity working
| as print server. That breaks ? just connect it directly.
|
| But hey, feeding everything from single microcontroller is $2
| cheaper...
| miah_ wrote:
| I went to a "tech school" to learn computers while in High
| School in the 90's. The tech school also had classes for
| 'the trades', it was set up to prepare Michigan kids for
| careers (Careerline Tech IIRC).
|
| Anyway. A big part of that class was learning to clean,
| repair, and manage printers. Again, it was the 90's, and we
| were high school kids. We came out quite capable with many
| computer skills but the printer stuff really stuck with me.
| I've done technical support throughout the years and have
| setup hundreds of printers.
|
| The printers of today are awful landfill fodder compared to
| the Okidata's of the 90's. Pure simplicity and speed vs
| FULL COMPUTERS, with scanning, faxing, and every other
| imaginable feature crammed in with zero hope of doing
| anything other than replacing the toner.
| com2kid wrote:
| > The printers of today are awful landfill fodder
| compared to the Okidata's of the 90's. Pure simplicity
| and speed vs FULL COMPUTERS, with scanning, faxing, and
| every other imaginable feature crammed in with zero hope
| of doing anything other than replacing the toner.
|
| The first Laserwriter in 1985 had more processing power
| than the Macintosh it was sold to accompany.
|
| Printers have been full computers for a _long_ time now.
| As we expect them to do more and more, the computers in
| them get more and more complex.
| hinkley wrote:
| People used to buy HP Laserjet 4 printers at auction
| because they were peak stability. From the look of things
| the 4 introduced the direct predecessor to the wire
| protocol printers use today (PCL 5e vs PCL 6 variants)
|
| https://en.m.wikipedia.org/wiki/Printer_Command_Language
| ilyt wrote:
| Our helpdesk offered us to take our LJ2100 and get us
| something newer.
|
| Many insults were thrown. He didn't try again
| alpaca128 wrote:
| > As we expect them to do more and more
|
| Who does? Who asked for updates blocking third-party ink,
| 1GB "drivers", full-color "test prints" each time you
| switch it on, ...?
|
| Printing reliably doesn't sound too demanding,
| manufacturers reached that point long ago, and since then
| I haven't seen all that much groundbreaking innovation.
| Sure, things like wifi were added but that doesn't
| require cutting-edge technology - consumer devices could
| handle that 20 years ago, and more reliably than the
| printers I've used. I also haven't heard of anyone being
| excited about NFC in printers, and from experience I can
| say it's not nearly intuitive or frictionless enough to
| warrant the integration.
| com2kid wrote:
| > Who does?
|
| The majority of my printing happens from my smartphone,
| so my printer needs to be on wifi, and needs to be able
| to reliably print from Android and iOS.
|
| Accordingly, it needs firmware updates because phones
| break how they work _all the time_.
|
| > things like wifi were added but that doesn't require
| cutting-edge technology - consumer devices could handle
| that 20 years ago
|
| Not just wifi, multiple protocol for connecting to
| printers. Also that wifi needs to be 5ghz so I don't have
| to switch over to a 2.4ghz legacy network every time I
| want to print (which I had to do with my previous 2.4ghz
| only wifi printer!)
|
| The onboard touch screen + embedded OS means I don't need
| to set anything up through a computer or smartphone app.
|
| FWIW I have a black and white laser printer from Brother,
| I've never had to install a driver, I just plugged it in,
| typed my wifi PW on to the touch screen, and after a
| firmware update on first use it has happily been allowing
| anyone connected to my wifi to print w/o any hassle.
| spockz wrote:
| I fixed this by adding a printer server to my NAS and use
| that for AirPrint and the like. Smart power socket to
| prevent the printer from drawing power all the time. No
| need to have a smart printer.
| com2kid wrote:
| Most people don't have, or want to maintain, a NAS +
| print server, having the print server software built into
| the printer is perfectly reasonable for a consumer
| product!
| Marsymars wrote:
| > The majority of my printing happens from my smartphone,
| so my printer needs to be on wifi
|
| It needs to be on your home network, but it doesn't need
| to be connected to wifi per se. Ethernet works fine,
| including ethernet to a wireless mesh AP.
| outworlder wrote:
| > The printers of today are awful landfill fodder
| compared to the Okidata's of the 90's.
|
| Maybe. But how expensive were they?
|
| I can buy a _good_ laser printer for under $200 these
| days. It will be more compact, lighter, mechanically
| simpler and use way less power than older printers.
| Something has to give.
|
| Some older printers were really overengineered (which in
| many cases did make them more reliable), but that has a
| cost. Turns out, consumers didn't want to pay those
| costs.
| outworlder wrote:
| > 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?
|
| There's a bit of survivorship bias and N=1 here.
|
| I'm old enough to remember machines full of relays and
| discrete components that failed pretty often and required a
| lot of troubleshooting with schematics on hand. Modern
| appliances - if built out of decent components - have a much
| better shot at surviving long term. Less discrete components
| that can fail, more debugging capabilities, logic that's
| implemented in a rock solid processor rather than an
| unreliable mess of digital gates (or worse, analog logic).
|
| There's obviously a point where there are diminishing
| returns, and probably another one where more complexity
| actually decreases reliability.
|
| > Smart things would ideally just revert back to being
| functional dumb things (rather than bricks) if their
| electronics fail.
|
| If possible, yes. That's only really an option for simple
| devices.
| briffle wrote:
| 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...
| pixl97 wrote:
| >a local garage could most likely have fixed the problem
|
| So, what was the problem?
| judge2020 wrote:
| Supposedly the electronics were too complicated for a shop to
| diagnose and fix the car on the spot, but I imagine the real
| problem is that diagnosing non-obvious problems is tough for
| anyone to do on the spot because all mainline service centers
| for the big manufacturers are weeks behind and can't just
| squeeze in the 4 man hours it might take to tear down and
| diagnose random problems. Older cars and systems were cheaper
| and easier to diagnose, but they also probably broke down
| once a year or more, while I had no issues with a 80k miles-
| in-2-years 2018 Honda Accord and still going strong with a
| 60k mile no-maintenance 2020 Tesla Model 3 SR+.
| dtx1 wrote:
| That's imo a right to repair issue. We can build easily
| diagnosable and easily fixable hardware. Big Corps just don't
| carlmr wrote:
| 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 then?
|
| Even if you just get the original software, how do we ensure
| you flash it correctly?
|
| If you get the schematics, how do we know used the right
| parts that are rated for 125degC temperatures.
| yellowapple wrote:
| > 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 then?
|
| I would, obviously, for making the unsafe modification. In
| what multiverse would the manufacturer be liable for
| something entirely outside the manufacturer's control?
| anaganisk wrote:
| 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.
| bluGill wrote:
| The EPA has suggested they will hold companies liable in
| the future. It hasn't happened yet, but they are hinting.
| If it is just one hobbyist they don't care, but there is
| a whole industry of chip your diesel truck and those
| chips clearly increase pollution. A modern diesel truck
| doesn't emit black smoke, but a large % of the diesel
| trucks you see are "rolling coal" which is a sure sign
| that someone has disabled the emissions controls.
| yellowapple wrote:
| > The EPA has suggested they will hold companies liable
| in the future.
|
| The EPA can suggest all it wants. Holding one entity
| liable for the actions of an entirely different entity
| beyond the control of the former's is asinine, and I can
| guarantee you these automakers will gladly sic their
| armies of lawyers at a Supreme-Court-bound case and/or
| their armies of lobbyists at legislatively castrating the
| EPA if the EPA made any such attempt.
|
| On top of that, the EPA is virtually irrelevant for EVs,
| and yet EVs are just as locked down (if not moreso), so I
| don't buy the "EPA might punish us" argument for that
| reason, too.
| Gordonjcp wrote:
| Not disabled the emissions controls, but deliberately
| remapped it to grossly overfuel at large throttle
| settings.
|
| Why people want to trade off power for a big cloud of
| black smoke is beyond me, but there we are. If they want
| to get 50bhp from a nine litre engine, that's their
| concern.
| Gordonjcp wrote:
| "ECU tuning" is just fiddling about with some values in a
| lookup table, though.
| overthrow wrote:
| 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.
| bluGill wrote:
| 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.
| dtx1 wrote:
| > 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.
| nickjj wrote:
| 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
| scientism wrote:
| This should be part of the "How to Overengineer Anything and
| Everything" series.
| mkoubaa wrote:
| All this because nobody wants to change the ELF loader to better
| isolate dependencies of binaries
| IshKebab wrote:
| I think it's more because Linux OS developers have never
| bothered to move away from Unix's "all apps get mixed together
| at absolute locations" filesystem model.
|
| If apps were like on Mac - self-contained directories that can
| be installed at any path - then Docker would probably be a
| footnote.
| never_inline wrote:
| > mixed together at absolute locations
|
| There is DT_RUNPATH probably since before I was born. The
| problem is it's not always utilised, distributions prefer to
| share libraries over isolating applications, and loading
| shared libraries isn't the only host-dependent thing done by
| application code.
|
| Also you realise that docker provides more functionality than
| a tarball, right?
| mkoubaa wrote:
| DT_RUNPATH is not nearly flexible enough to matter
| karussell wrote:
| Ironically, Linux probably mostly does this to save disk
| space (and probably also to save RAM in the early days). And
| now with docker you download hundreds of MB only to install a
| small python script ...
| hamdouni wrote:
| Nice to see improvements in podman startup and how the team
| achieve it...
|
| Constraints (car env) drive creativity !
| shrubble wrote:
| 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...
| MuffinFlavored wrote:
| makes you wonder what the aspects other than startup time
| probably look like?
| q845712 wrote:
| i don't know if they fixed _all_ the errors -- there's still
| apparently a bunch of containers running in somebody's car...
| polskibus wrote:
| Can podman be used instead of docker on Windows for minkube?
| Would it work faster than docker in such case?
| com2kid wrote:
| > we did was analyze what happens when Podman starts a container
| and why it takes so long. It turns out there was a lot of low-
| hanging fruit.
|
| I've done this analysis for lots of software before, Windows has
| a _really_ nice tool called Process Monitor that I 've used to
| find huge slow downs before. Point it at a process and it'll tell
| you the every bit of IO that the application does, and at that
| point you can just start digging and opening bugs.
|
| IMHO almost every piece of software of any significant size
| horribly misbehaves. Opening the same file again and again,
| writing out lots of tiny temp files, reading the same key from
| the registry (or some config file) over and over again , and
| worst of all, using fixed timeouts waiting for a task to complete
| instead of doing the work to make things properly event based.
|
| On that last note, timeouts instead of event callbacks (or some
| sort of signaling system) is the cause of so much slowness across
| our entire industry. If something you are doing on a computer
| takes a human noticable amount of time, and you aren't throwing
| around tens of GBs of data or waiting on a slow network, then you
| are flat out doing something wrong.
| crest wrote:
| Adding a `sleep $DELAY` to a startup script isn't something to
| brag about :-P. _scnr_
| Hendrikto wrote:
| They removed it.
| kobalsky wrote:
| 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 the worst time, you have to hunt down the
| corrupted folder and remove so that anything works again.
|
| A failed compose startup can leave the network in a undefined
| state hard to diagnose and impossible to recover without wiping
| some folders within /run/user and killing some rogue processes
| manually.
|
| This is further cemented by the fact that a lot of minor issues
| are answered with: podman system reset, which reeks of rm -fr
| node_modules.
|
| docker was always a pleasure to work with, I still don't
| understand why I suffered with podman so long.
___________________________________________________________________
(page generated 2023-04-13 23:01 UTC)