There was an article about a Linux embedded system handling a car back-camera that had to boot within 3-5 seconds or something along those lines.

Wild that people have accepted a 5000ms delay between starting their car and seeing behind them.

I suppose I'm more sensitive to downtime than most - I recently (unsuccessfully) tried to add a ton of capacitance into my head unit's power supply and acc-signal lines to keep it from turning off for a few seconds when starting the engine.

probably because it started off as a 1000ms delay, which they begrudgingly accepted. Then it started to slow to 1100ms....

Up until a couple years ago my car didn't even have a camera. We just looked out the window, which is still an option.

It is a much worse option than it used to be. Visibility out of the rear windows from the driver's seat has gotten worse over the years.

So industrial design with poor usability gets complemented by bad electronic devices. Progress?

what are they getting for the poor visibility tradeoff compensated by electronics? I have no idea. If it's safety, then yes, that would be progress.

Safety, and aerodynamics (i.e. energy efficiency).

Dismissing it as "design with poor usability" is very facile. It's trade-offs between different goals, all the way down.

Or it’s just cheaper to build

Cost is yet another trade-off.

Those pillars that hold the roof up are safer if they're sturdy, but sturdy means wider and that obstructs the driver's field of vision a bit, and weighs more. "strong and slender" is possible, but it costs more. It all inter-relates.

There does come a point where you start to appreciate what Polestar is doing on one of next years models (the Polestar 4): give up on the idea and change direction; no rear window at all, just a camera.

The failure mode is pretty horrible though.

And I'm not only thinking about damaged camera. Humidity, weather etc. often makes these cameras completely useless.

You'd have to have wipers for your camera-lens and probably heating or something as well to even approach the utility of a window - short term.

Because none of that is ever going to fail, and it isn't cheap either.

Lens washdown is rather common now on vehicles.

I don't think that I said that the Polestar 4's lack of rear windows is a slam-dunk sure-fire hit. Rather just that we can appreciate the attempt to side-step the issues with rear-window visibility with a very different design.

It is IMHO a bold move, which will attract fans and haters. Neither of us know for sure how it will play out; if the potential issues outweigh the rest. The implementation details clearly matter. In a couple of years we will see if it's a genius innovation, a terrible misstep or somewhere in-between. Until the vehicle ships and is on the road for some time in some volume, we won't know for sure.

While I agree I kind of think this should be nailed down before such a departure.

After all, on a high-end vehicle a back-camera that hasn't sorted this is just a gimmick.

Maybe they have, all my experiences indicate otherwise though I don't have much experience with new expensive cars.

Trucks drive just fine with no rear view at all other than side mirrors, so cars can do that as well.

Truck drivers are pros, though, while we're just annoying traffic jam fodder.

They can't see what they can't see. Being a pro makes no difference.

Reminds me of the 18 wheeler at the traffic light. He got red while waiting for his left turn and decided to back up instead of "going for it" once oncoming traffic had seized.

The minivan behind him got crushed like it was made of sticks. Luckily he heard the noise after a while and stopped backing up. Not a pretty sight. I had the side view so I was like "WTF is he doing?" when he started backing up. Well he couldn't the minivan who had snuck up behind him.

Lesson: when behind a truck make sure you can see the drivers face through his mirrors. Then you have a chance that he is going to see you. If you can't see his face, assume that he can't see you. Move away.

On the highway, sure. But generally whenever I see a truck back up in the city, there will be someone outside directing the driver.

You don't see lots of truck parking in parallel unassisted on streets with pedestrians and cyclists, but I do this all the time.

Hmm? They specifically taught me in driving school how to parallel park using just the side mirrors.

Americans don't care about the prices of their cars and neither do American safety regulations.

This is correct. It's easy credit all the way down. Cheap cars (Chevy Spark, Mitsubishi Mirage, Kia Rio) are basically all slowly being discontinued in NA, meanwhile luxury pickups sell like hot cakes.

It's safety. Same with thicker pillars which are worse for visibility but made thicker for rollover protection.

> So industrial design with poor usability gets complemented by bad electronic devices. Progress?

https://en.wiktionary.org/wiki/Chesterton%27s_fence

It's for safety in case of roll-over and for better aerodynamics due to increased emissions standards and in the case of EVs, increasing the range.

So cars get safer through more competent structural design and are enhanced by reliable camera systems that allow for better visibility than craning ones neck around 120 degrees.

A large majority of cars in traffic don’t have a back camera. Either because they’re old or because they’re cheap (I don’t think a back camera is usually a standard feature at least where I’m from…)

In the US a backup camera is now required by law

For new cars, I guess.

In the EU, it’s similar. https://ec.europa.eu/info/law/better-regulation/have-your-sa...:

All new vehicles sold from May 2022 must be fitted with advanced safety features, including:

- monitors that detect when a driver has become drowsy or distracted

- emergency stop signal to help prevent rear-end collisions

- rear-view camera or parking sensors

- alcohol interlock system to prevent drunk driving.

These systems will help reduce serious accidents on Europe’s roads.

It seems that the only part that got implemented out of that draft was drowsiness/inattention detection. At least that's what I read from the document in "Commission adoption" section of that page.

> alcohol interlock system to prevent drunk driving.

Wait, what? _All_ new vehicles need to have this? Or do they just need to be constructed such that one can be installed easily?

Looks like EU law, so considering the wording, probably every new car.

Also, see:

https://road-safety.transport.ec.europa.eu/statistics-and-an...

Edit:

The actual text:

> Article 6 of Regulation (EU) 2019/2144 of the European Parliament and of the Council requires motor vehicles of categories M and N to be equipped with certain advanced vehicle systems, including driver drowsiness and attention warning systems. It lays down in its Annex II basic requirements for the type-approval of motor vehicles with regard to the driver drowsiness and attention warning systems.

The car must be built to allow for the installation of a breathalyser, i.e. some standardised interface. Doesn't really affect you unless you're ordered by a court to use one.

I rather have no car at all than go back to that.

That would be better for the planet anyway.

Disclaimer: Not a joke. I've never owned a car.

I agree and in modern countries with proper transportation there is no reason to own a car.

Well, there is a reason, but you won't like it.

Convenience :-)

If you have e.g. outdoors activities in sparsely populated areas as a hobby, having a car gives you a lot more freedom than being dependent on public transport. Buses may work if you're only going to locations that are popular enough but that may limit your options. Of course you could also rent but that could become expensive or cumbersome if you do it often enough.

Also, if you live in a sparsely populated area, public transport with good coverage often isn't really economically (or ecologically) feasible, even in countries that have good public transport in cities. A bicycle might be an option if distances aren't too great but relying on it exclusively probably takes more than an average person is willing to take on. Weather conditions could be poor, you might regularly need to transport groceries for an entire family, etc. All of that is entirely doable within a few miles in a bikeable city but it's potentially a lot less so if distances are greater.

I've never owned a car, I bicycle some thousands of kilometres per year (probably more than I drive most years), and I wish people didn't automatically consider owning a car a necessity even when it actually isn't. But I can definitely see reasons for owning one.

You don't see small kids right behind your car this way. I believe this was the main reason why rear-view cameras were made mandatory on new cars.

Also, because the cars now are gigantic, compared with old cars.

Even the Mini Cooper is huge now.

I wouldn't be surprised if the Mini Cooper is now a light truck. Everything is larger because manufacturers are gaming the footprint regulations to get by with worse emissions and DOT isn't serious about revamping CAFE to stop that behavior.

It’s probably less than 5 seconds in perceived terms. Eg the car gets power before the engine turns over, and you then need to select reverse after the engine is running. And you’d need to check your blind spots before checking the camera too. So by the time the driver is ready to check the camera, it might feel like a much smaller delay or even no delay at all.

The delay that I notice the most is the time it takes to connect to my phone via Bluetooth (usually so I can play music from it). I’m often already pulling out of my parking space before it connects.

> Eg the car gets power before the engine turns over, and you then need to select reverse after the engine is running.

I can change gears in well under a second when moving. My car requires the clutch to be depressed when the car starts, meaning that I can actually ahve the car started in reverse in under a second. Waiting another 4 seconds is crazy.

It could very well begin booting the second the car is unlocked

You’re not going to change gears before turning your engine on though. Which is my point.

And if you’re reversing within 3 seconds of turning your engine on then you’re either driving recklessly or on an open and safe space where you don’t even need your cameras.

To be clear, I’m not suggesting that a 4 second boot time for an embedded device is great. But I do think your claim that waiting 4 seconds “is crazy” is rather hyperbolic.

> You’re not going to change gears before turning your engine on though. Which is my point.

If I've parked my car, I have to have my foot on the clutch to turn it back on agian. My foot is already on the clutch, and I can very easily (and often do) put my car in gear _immediately_.

> then you’re either driving recklessly or on an open and safe space where you don’t even need your cameras.

Or I've looked in my mirror and put my seatbelt on before I turned the engine on. This is the equivalent of "you're holding it wrong".

But starting the car takes a couple of seconds (engine turn over isn’t instant) so you would then need to double check your mirrors and blind spots anyway. I’ve been driving longer than most people on here have been alive and a lot can happen in 2 seconds at busy parking spaces. And if it’s somewhere quiet, then you don’t really need to watch your camera like a hawk.

My point being, 5 seconds might sound like an eternity on paper but I’d wager it’s not nearly as impactful once you start factoring real world scenarios.

Personally, I never look at my camera. I just listen to the beeps and watch my blind spot. Not because it’s safer not because of any delay in the camera coming on, but simply out of habit. So I’ve never noticed a delay in the camera coming on. Maybe there isn’t even a delay in my particular car — but if there was, I wouldn’t know.

What was unsuccessful? I did this in a 2012 Miata with a pioneer head unit (capacitor on the Acc line so it discharges while cranking, which keeps the head unit from turning off). Has a fused line directly to the battery for power. It’s not a huge capacitor either… like a 1500 uF or so? Just tried a couple diff cap values until it had around 5 secs of charge to hold the line open. It also makes it so the music doesn’t cut off immediately when the car is turned off as well… it gives it a few seconds to shut down. Feels more premium.

Well if I knew for sure why it didn't work I'd fix it ;)

I think it works better now than before, but it's hard to be sure because I neglected to measure the downtime before/after the modifications. Essentially I had a cap/diode to keep the acc line high during startup for the head unit, but it would still cut off due to the power supply voltage dropping to ~10-11V on the engine turning over (4.8L V8). So then I added a cap/diode to the power supply line, and it works "better...ish...maybe..." now: there are some times when it will stay on across startup, but not always. Perhaps with a larger cap on the PS line (I'm using ~2500uF), but it seemed to be discharging much faster than I'd expect, as if the diode wasn't doing it's thing and the line was effectively just at the system's general "+12V". I wondered if there was perhaps some way the power was escaping the diode/cap isolation and making it back into the main system, but I didn't have a good way to test or fix that (I previously diagnosed a similar issue to a bad diode, but this one seemed to measure fine).

And besides all that, the amp is on a separate line in the way back of the car that I didn't bother to tear into because the head unit turns off in the critical stage anyways. So the head unit does stay on for a couple seconds after I turn if off completely, but since the amp is off it doesn't matter.

You're supposed to let your car idle for 30 seconds after startup to let the engine lubricate. It's more important in cold climates.

So delayed startups aren't some new issue.

Probably not necessary in modern cars, whose electronically controlled engines have many internal details not obvious to typical drivers.

If you believe your idea is true, can you tell me what I can expect to see if I don't do this? IE, I've never done this and I have cars that last 10+ years without any engine trouble.

I mean, I back into the parking spot instead of out of it most of the time so it wouldn't bother me.

Also my usual sequence is "start the engine, set up on phone (music, GPS), leave", so it would've booted before I need it.

Very OT, but I concur. I need a DSP for my car audio system. I considered a rpi3 with a DAC attachment.

I tried the raspbian OS with some moderate overclocking and removing unneeded startup processes. Couldn’t get it under 25 seconds for boot.

Maybe I’ll try again with an RPi 4 and usb3 nvme. or maybe I’ll just pay hundreds of dollars for a dedicated DSP unit.

In case anyone cares, my main use case is parametric EQ for phon adjusted low bass frequencies. 90dB 20Hz sounds as loud as 70dB 50Hz (give or take) and subwoofers are generally quieter at lower frequencies anyways. Hence, audio processing unit to cut as you go higher than your lowest decently loud frequency.

You could use a ADAU1701 DSP board (cheaper and shittier minidsp) or do it directly on a modern/fast microcontroller, e.g. ESP32. I used an ESP32 to adjust frequency response of a small diy loudspeaker (and added Bluetooth).

If you make your own buildroot image, you can get VERY quick boot times - here's a random vid I found [1] with 3.5 seconds on a pi zero w (which is considerably less powerful than a Pi3.

I've worked with similarly underpowered boards (licheepi zero, only has 64mb ram and uses the cpu from a dashcam!) and those will still boot and start an SDL app in under five seconds.

If you can identify the bare minimum that you need for your EQ solution, you can probably get similar boot times.

[1]: https://www.youtube.com/watch?v=ZehLyumyMvE

i feel like maybe 3.5 seconds is not VERY quick compared to 28 milliseconds?

The use case is different so the comparison doesn't really matter.

3.5 seconds might be tolerable for your car radio i guess

Yep. My head unit has its own startup time for digital audio inputs, around 2-3s.

28ms is a VM; in hardware you can't get through firmware in 28ms. Apples to oranges.

true if your firmware is shitty enough but plenty of hardware platforms don't have that problem

It doesn‘t always have to be a RPi, sometimes there is dedicated hardware for that use case that is also kinda cheap.

Check this thing out, it‘s a programmable audio DSP:

https://www.thomannmusic.ch/the_t.racks_dsp_4x4_mini.htm

Can't you just run on bare metal on rpi? Also a resistor, a capacitor and a realay would work to filter out the extra bass.

Search ebay etc... for Texas Instruments DSP evaluation boards.

Yes I remember being surprised that Linux containers were used for that purpose.

My 2015 Model S would lose badly in a quarter mile against a good cyclist if you included cold boot time. Worst bank robbery car ever.

With a custom kernel and without initrd/initramfs is possible to boot around 1 second.

Might be quicker if you put everything you need into an initramfs that's built into the kernel. Then there's no slow storage needed once the kernel is loaded.

There is an interesting talk from BMW how they did it for their cars: https://youtu.be/_cSTBiwY7HE.

"Linux Kernel Fastboot On the Way", Linux Plumbers Conference 2019, https://www.linuxplumbersconf.org/event/4/contributions/281/... / https://www.youtube.com/watch?v=A7N_O8pnyTw

3-5 seconds sounds like the latency I see in my 2018 Toyota’s garbage Entune 2.0 system. It’s criminal that things like this are released for general usage.

meanwhile our new dishwasher takes between two and four SECONDS from pressing the power button to showing something on the display

But you still bought this one and not one of the alternatives that start faster... which is part of the reason things get built this way.

Unfortunately stuff like boot time / time to interactive isn't in the specifications. You have to check user reviews, and not everybody cares about this.

I doubt this is an absolute requirement. Would I choose the faster booting dishwasher among a set of otherwise identical ones? Sure. Would I pay more for it to boot faster? It depends. €10? Sure. 100? Nah.

Plus, as the sibling poster says, you usually don't know this before you first start to use it, which means it's already been delivered, connected, and everything.

Would you really pay $10 for your dishwasher to boot in 1s instead of 4s? I absolutely wouldn't. Maybe $1, but even that is pushing it.

For something that's going to annoy you daily for the next 10+ years? I'd definitely pay $10. I'd pay another $10 for the dishwasher to remember the program selection instead of always offering the 4+ hours eco program (which I believe is required by some regulation to be the default).

I already paid $100 more for 2dB less, according to the spec. No regrets.

I'd say it depends on how long it takes to boot up. Fortunately, my dishwasher boots up instantly. If it takes a few seconds, sure it's annoying, but you can work around that. Say press the on button, then check the detergent is in place, etc, then press start. If it's some ridiculous length, like several minutes, I'd probably only buy that crap at a steep discount.

> which I believe is required by some regulation to be the default

Huh. This must be recent-ish. My parents' dishwasher has a rotary button to choose the program, which stays put as long as the little grandchildren don't mess with it..

Found it: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:...

> From 1 March 2021, household dishwashers shall provide an eco programme meeting the following requirements:

> (a) this programme shall be: [...] set as the default programme for household dishwashers equipped with automatic programme selection or any function maintaining the selection of a programme, or, if there is no automatic programme selection, available for direct selection without the need for any other selection such as a specific temperature or load;

Ours was bought in late 2020, but manufacturers probably take a head start with implementation whenever they renew their models.

If consumers cared it wouldn't cost anything. They would just do it.

came with the house

it's inferior to our old one, which was from the 90s and still worked, in other aspects too, most annoyingly cleaning performance. i guess it uses less water thou

I don't think I've ever read a dishwasher review that talks about time to interactivity. How do I know which of the 242 dishwashers available[0] in my online retailer staarts in under a second?

[0] https://ao.com/l/standard_dishwashers/1/21-23/

Very naiive question... But why can't you "just" memcopy and exec an image of an already booted system?

Simplistic answer is because hardware and firmware environment gets configured during boot, even for virtual machines.

Some virtual machine environments do have facilities to snapshot the entire state of a machine and resume it (potentially on another machine), but if you look at what is involved with snapshot metadata it's more than just the state of memory, you have CPU and device state as well.

Wouldn't hibernating the machine and then copying the hibernation data to another machine do the trick? Sure it wouldn't be as instant, but it would skip most of the boot configuration.

Possibly a bit fragile if there is any situation where one day the other machine isn't entirely identical? (just hand-waving here)

The usual culprit is CPU feature flags on different CPU generations.

Well then wouldn't you just have one image file for each CPU generation in your datacenter. Or better yet, have one image file on the hypervisor for each individual machine! That machine is probably dedicated to Lambda instances and boots them 1000x per day, if you're spending valuable time that's actually customer-facing latency on each call to reboot the system then switch that memory<->time tradeoff back towards memory!

Conceptually at a high level yes (if the hardware was ~identical). Resuming from hibernation on the same machine resuming from hibernation is basically loading an image into memory and executing it that OP asked about too. But in either the resume or hypothetical hypernation migration cases, you can't just start running where the previous boot left off, you have to go through hibernation resume functions which basically do the same thing as boot in terms of configuring hardware.

On virtual machines there probably isn't nearly so much real hardware to set up, and hypervisors can optimize virtual device setup. The machine image could also be provided via COW snapshot of memory. So I don't know, possibly at some corners it could be faster to do a resume type operation than a full boot. I haven't played with hypervisor guest boot at these kinds of speeds before.

There’s things like encryption keys and tokens that need to be unique so it’s not easy, if you do it like that you would run into new, difficult to predict vulnerabilities.

So it’s difficult and dangerous for not a lot of gain. Perhaps an easier approach would be to boot a few spare systems in advance and hibernate them so they can be booted quickly.

You sort of can, but drivers have to be in sync with the (emulated) devices they're controlling. The fastest way to go about this would be to snapshot an already booted virtual system. It could be as simple as instructing the restored snapshot to reseed its RNG and (re-)attach to the network, but you'll probably in into a few more assumption broken by cloning a multiple VMs from the same snapshot. If pre-booting and suspending/resuming each individual VM is good enough it could look similar to a pre-forking HTTP server like old Apache versions.

Yeah, for real hardware it is important to be flexible.

But these virtual machines can all be exactly the same, except for the network MAC and IP.

It could even be possible to compile executables that bypass the need for a kernel, just have some libraries with the required stuff, and boot to the program, MS-DOS style.

> could even be possible to compile executables that bypass the need for a kernel, just have some libraries with the required stuff, and boot to the program

Or consider: https://github.com/uniqernel/awesome-unikernels