4 ms·
> It's either always on, you wait, or it guesses when you're going to use it and you accept there are a few false positives. Or engineers reduce startup time t
by cuu508 11y ago
> It's either always on, you wait, or it guesses when you're going to use it and you accept there are a few false positives.
Or engineers reduce startup time to a point where it feels instant.
Compare e.g. startup times of DSLRs and point-n-shoot cameras. With a DSLR you switch it on and it is ready to shoot by the time your finger gets to shutter button.
- oliwarner 11y agoI'm not saying it has to be an exclusive development. You can improve the other stuff too, but once relative location becomes a solved problem, it presents bevy of particularly low hanging fruit. It's also very hard to engineer a boot time down. TFA is a great example of that. Hard means expertise and time and (often) more expensive hardware. So to boil it right down with my car computer example, it's far easier and cheaper to detect the key externally and boot earlier than it is to strip a 10 second boot time down to 0.1 second. If you can also use that getting-in-the-car time to do other stuff (lookup up recent searches or upcoming appointments and suggesting navigation, setting fuel waypoints if low, getting traffic advice, etc), that's all the better.
- jimduk 11y agoThis is why e.g. go pro uses a hybrid approach with an embedded rtos for the camera stuff and then virtualized Linux on top of this for less critical work where you want to use a stack e.g.http streaming. 3 yrs back I worked in a team which looked at booting Linux for a camera device in < 100ms and couldn't find a solution.