4 ms·

One second, ten seconds... The problem isn't that it takes time, it's that the user has to sit there and wait while it takes that time. My desktop takes about

One second, ten seconds... The problem isn't that it takes time, it's that the user has to sit there and wait while it takes that time. My desktop takes about two seconds to resume from suspend. I'd sit down, lean down to the floor and press the power button and then wait that two seconds. I fixed the whole problem by moving the case up onto the desk so that I have to walk past it to sit down. Now I press the button and then sit down, by which time the computer is waiting for me. The way it should be. Sidebar: Now I'm slightly concerned that an AI in the future is going to call me out for my blatant display of meatbag privilege. We can throw tons of money at engineering boot times but but really the biggest gains are made when you can predict what the user wants. Imagine you approach your car. If it can detect you or your key, it can start doing stuff it'd normally do when you put the key in the ignition. Suddenly it doesn't matter than it takes 5-10 seconds to boot because it also takes 10 seconds to get in the car. All this stuff is going to get better once we have widespread adoption of technology for fine indoor tracking. When we can tell our relative positions to our gadgets, they'll be able to sleep deeper, ring louder, shine brighter and start booting earlier.

andrewstuart2 11y ago
The problem with anticipation is that nobody except you can truly know your intent. For example, walking up to a car with my keys might just mean I want to grab something out of the trunk; or the car might be in a closed garage and that wouldn't be quite safe at the moment. The easiest and safest thing is usually still to let people control more of what happens because there's a lot of edge cases that might add up, or have really bad consequences for when they rarely occur.
- caskance 11y ago
  That's not a problem with anticipation as a concept, that's a problem with bad anticipation. Certainly it's possible to detect whether the car is in a closed garage, and it will eventually be possible to predict whether you want to grab something out of the trunk or go for a drive. Even though it often feels like you do, humans generally don't know their own intents. It's not that high of a bar for a predictive system to clear.
- oliwarner 11y ago
  Wouldn't be safe? I'm talking about starting an on-board computer, not the engine. Unless you're going to be repeatedly walking too and from your car all day, starting a computer needlessly isn't going to be the end of the world. Yes, it may mean doing more work but that's the trade off here for "instant on". 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.
  - 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 ago
      I'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 ago
      This 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.

andrewstuart2 11y ago

The problem with anticipation is that nobody except you can truly know your intent. For example, walking up to a car with my keys might just mean I want to grab something out of the trunk; or the car might be in a closed garage and that wouldn't be quite safe at the moment. The easiest and safest thing is usually still to let people control more of what happens because there's a lot of edge cases that might add up, or have really bad consequences for when they rarely occur.

caskance 11y ago
That's not a problem with anticipation as a concept, that's a problem with bad anticipation. Certainly it's possible to detect whether the car is in a closed garage, and it will eventually be possible to predict whether you want to grab something out of the trunk or go for a drive. Even though it often feels like you do, humans generally don't know their own intents. It's not that high of a bar for a predictive system to clear.
oliwarner 11y ago
Wouldn't be safe? I'm talking about starting an on-board computer, not the engine. Unless you're going to be repeatedly walking too and from your car all day, starting a computer needlessly isn't going to be the end of the world. Yes, it may mean doing more work but that's the trade off here for "instant on". 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.
- 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 ago
    I'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 ago
    This 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.