Live data from Hacker News

We achieved a 6-fold increase in Podman startup speed

redhat.com

181–190 of 196 posts

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

#181

Earlier quoted context omitted.

> 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?

DT_RUNPATH is not nearly flexible enough to matter

Can you elaborate what more function you were expecting?

There's appImage and a variety of home directory package managers on *NIX platforms. None of them caught up.

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

#182
post #143

Earlier quoted context omitted.

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?

Not all cars are made equal. Just as you don't go to a cross-Sahara race in a car you don't know you, you don't buy a Prius to go logging in Alberta or Yakutsk.

Sure, that doesn't necessarily invalidate your argument, after all this increase in car complexity (through "electronization" and smartification of more and more components) without the increase in debuggability/repairability is IMHO a bad trade-off for many consumers.

Case in point, our second-hand 2011 Ford Focus has a problem with the electronic steering assist. Apparently it somehow experiences some kind of over-voltage and the internal system shuts down. It's likely due to humidity. (So probably it's simply a design/manufacturing/QA issue.) Okay, but there's no way to get the actual data from the integrated electronics from the steering system, but it's possible to reflash a different firmware on it. Which resets the internal data. Which basically clears this error state, and the car will happily use it.

But there's clearly a mechanical error, there's a new "bad" noise when turning the steering wheel. But it's a 10+ year car, rarely used, and replacing the steering system is about ~1000 EUR, doing the firmware flashing was ~30 EUR. (Finding the guy with the laptop, who can flash the firmware through the good old ODB port was the challenge.)

And it's basically a big (market) information asymmetry problem. The car industry wants to sell more cars. Sure they sell some parts, but the more repairability a car has the less parts it really needs, as consumers can make their own tradeoffs.

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

#183
post #70

Earlier quoted context omitted.

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.

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…

On one hand, it's okay. Cars are becoming a service, which they are anyway. Most people want to get transported, they don't want to drive, nor they want to maintain a car. Collective interests are pushing the whole industry toward this. (The goal of decreasing emissions through the whole lifecycle/value-chain, more safety for everyone involved, not just for those in cars; EV-ification itself pushes everything toward consolidation, as cars become simpler, but more one-time CapEx intensive, as the battery costs a lot, and then it just works for a million miles. AAaand then the whole need/goal of densification of cities, more public transportation, etc.)

On the other hand right to repair is very important. Walled gardens suck. Still hundreds of millions of people live in rural areas in the so called developed world, etc. And I don't want to subsidize the industry, I'm willing to pay more up-front, if it means I can just to replace the fucking light bulb.

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

#184
post #28
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…

economically, this doesn't work. The cheaper cars will always be those that roll all functions into a single cost center. This is why cars wind up with a horribly awful touch screen in the center for controlling almost everything about the car's function.

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

#185

Earlier quoted context omitted.

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

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

My smartphone does not have an ethernet port. :)

My house came wired for cat5 (the original cat5!) but modern wifi is a lot faster than 100mbps, so I just use wifi for everything.

Latency is higher, but so is the speed.

Also I only own 1 desktop that has an ethernet port, and I haven't plugged the desktop in for 2 years.

I would actually like to have the TV hooked up to ethernet, since its wifi chip crashes every few days and I have to power cycle wifi in settings, but whoever wired the house for cat5 didn't install ports anywhere, although they did install a large patch panel in the basement, but I have better things to do than crimp a bunch of wires to fix one flaky connection.

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

#187

Earlier quoted context omitted.

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

My smartphone does not have an ethernet port. :) My house came wired for cat5 (the original cat5!) but modern wifi is a lot faster than 100mbps, so I just use wifi for everything. Latency is higher, but so is the speed. Also I only own 1 desktop that has an ethernet port, and I haven't plugged the desktop in for 2 years. I would actually like to have the TV hooked up to ethernet, since its wifi chip crashes every few…

That's the nifty thing about my second point, with a mesh network - if you put your mesh APs in spots where you have a bunch of wired-capable devices, you can plug everything into the mesh AP and then all the data runs over the mesh AP's high-end radios.

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

#188

Earlier quoted context omitted.

DT_RUNPATH is not nearly flexible enough to matter

Can you elaborate what more function you were expecting? There's appImage and a variety of home directory package managers on *NIX platforms. None of them caught up.

I'm not really expecting anything, it's just my experience developing commercial desktop applications on Linux that you inevitably end up having a startup script that sets LD_LIBRARY path before the main process starts. And even then global symbols with the same name collide so you have to be really careful about what gets loaded into the process.

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

#189
post #138

Earlier quoted context omitted.

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

Our helpdesk offered us to take our LJ2100 and get us something newer. Many insults were thrown. He didn't try again

There were a ton of companies selling refurbished or knockoff toner cartridges for those things too. As good as the LJ was, the fact that they had easy access to cheaper supplies just accelerated the process of selection.

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

#190

Earlier quoted context omitted.

Watch us slowly reimplement Erlang on top of OCI.

To be precise an incomplete, bug-ridden, undocumented reimplementation of Erlang.

I keep having to stop myself from implementing an incomplete, bug ridden reimplementation if half of Erlang on top of NodeJS so I see the attraction there.

Worker threads have a garbage API and I keep finding myself wanting to have n processes sharing m workers and there’s just no easy way.

Post reply on HN