Booting Linux in One Second [pdf]
elinux.org
elinux.org
It certainly does not take a degree of any kind to "configure Linux". Not even if you're below average IQ.
I think that proves your point.
Linux might be free and open source software, but it's not a failure of anything that it doesn't come with a free systems administrator education.
I've been playing with some software over the last week that has wiki for documentation and an active user forum with people willing to help. But it's completely disordered and incredibly hard to discover. Half the battle with usability is making it easy to use and understand.
As in, he tried to keep the secrets secret, or it seemed to be trivial and uninteresting to him?
http://elinux.org/images/f/f7/RightApproachMinimalBootTimes....
Also under 1 second, and the approaches this guy took are seriously impressive. Lots of educational tidbits and "good-to-know"s in here even for non-embedded types. Reads very quickly too.
It's quite sad to see how we hardly use the computing power offered by our modern computers to actually speed up common tasks, but instead bloat it up with all kinds of stuff.
[1] http://cogsci.stackexchange.com/questions/1664/what-is-the-t...
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.
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.
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.
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.
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.
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.
And it's actually even worse than that. 100ms is nowhere near enough to be sufficient for all applications.
For audio applications you need 10ms [http://superpowered.com/androidaudiopathlatency] which incidentally is the reason why Android is unusable for any interactive audio applications.
Same applies to Virtual Reality. You need sub 20ms latency for head tracking to eyes latency or you will feel sick (effectively less than 10ms from the cpu side. Display scanning is summed on top).
The 100ms figure applies mostly to traditional UI workflow. Whenever you need a realtime interaction that's 10x too high.
Everybody says this and yet programs like Caustic seem to do a fine job in my experience.
There's a great explanation here as to why it's so bad: http://superpowered.com/androidaudiopathlatency
There are also indications that they are going to lower the display path latency, which also stands several times higher than what is in iDevices. It just takes some time to get a certain class of software architects to realize that buffering a frame several times each step might not be the smartest way after all.
Strange. The primary use of my (Android) phone is interactive audio. I do not recognize latency as an issue.
FWIW, if you are playing virtual drums, drummers need something like under 2ms response time; even 10ms can be easily felt by a drummer and cause their timing to get way off!
On top of that, if you are doing, say, a real-time effect on a vocal track, even a tiny sub 1ms delay causes a weird reverb effect in her monitor vs. the singer hearing herself, which will cause your singer's singing to get out of sync!
Also, for devices that require user authentication, such as logging in to an account, if you could offload the authentication (such as fingerprint or other biometrics) to something out of the OS itself (ROM routine that starts up with a 0 in a certain memory address and changes it to 1 on authentication), you could be booting up the OS in the background while you take a second or two to log in, and if the OS can get up and running by the time you log in, the OS can pretend that it started up immediately and was the thing that logged you in. For many devices, there is need to boot up in less than a second or so to seem as though boot up was instantaneous.
Here's a video of a talk by the author of this particular pdf
https://www.youtube.com/watch?v=KTRA1PRJWH8
Will be interesting to see what impact Intel's 3D Xpoint will have on boot times too.
(the steady state is that computers are running, so if it takes 30sec to cleanly shutdown then your cycle time is 31secs... obviously, this doesn't apply to stateless servers or that use write-through caching...)
TVs should be turned off completely when you press the button, to save power. After that almost all smart TV boot up quite slowly. Which is sad :(
Oh, usually once a week, sometimes twice a day, the phone will do the rebooting for me. Sometimes when it's in my pocket, sometimes when I try to watch a video that's just too long. Maybe some kind kind of memory error?
What you said reminded me of this, because I had forgotten this infuriating rebooting. I wonder if this was related to the building or something else? This is weird.
Rebooting your phone is an uncommon use case, so it's not optimized.
KDE used to load a session in the background when the login screen showed so that you didn't then have to wait after logging in.
On Android without root the system seems to use a ton of resources on background jobs that aren't needed; I imagine that slows boot too.
IIRC, Windows a) builds a list of files to pre-load from disk based on your usage, and b) doesn't actually fully shut down by default (it goes to hibernate mode: http://blogs.msdn.com/b/olivnie/archive/2012/12/14/windows-8...). I don't know if any Linux distros do either of those by default, but it is certainly possible.
Also, some BIOSes already have a "quick boot" setting which caches some hardware information, particularly about memory. It usually comes with a warning that you need to disable the setting for at least one boot when installing RAM.
The holy grail would be a kernel organized and designed to cache everything to disk related to its own configuration, and only re-execute/rerun the hardware reinitialization code.
Admittedly, Windows' current approach to bootup is very close: it closes all applications then pseudo-hibernates the kernel. Bootup simply reads the hibernated kernel state from disk and reloads userspace.
This is of course besides traditional full ACPI hibernation, which is pretty cool but isn't a perfect art. (I'm typing this on a ThinkPad T23, a fairly old (and thus well-tested) hardware configuration; its hibernation/resume is usually rock-solid, but this morning my WLAN decided to get all stupid with dhcpcd, and USB decided that while it could see my external HDD, there wasn't a disk inside it. From-scratch boot is still the only way to get a reasonably predictable system state.)
I'd rather wait 10 extra second than having a slow computer for the next 10 minutes.
In the embedded hardware environment if something has changed and if this change is out of specs, then what you say can be adopted.
Now I know !
There is also some documentation from Montavista from that time.
EDIT: The presentation by Montavista from 2008: http://www.freescale.com/files/training_pdf/VFTF09_MONTAVIST...
Nonetheless, underlying technology is solid with that showing in Blackberry Playbook.
Of course there might be some market advantage to be had with faster booting and it's a plus for the whole UX. And optimisation is definitely cool, though I think many more problems would be solved if people were forced to think once in a while, whether it's while waiting for the bootup sequence to complete or a train to arrive.