Live data from Hacker News

Booting Linux in One Second [pdf]

elinux.org

81–90 of 110 posts

Re: Booting Linux in One Second [pdf]

#81

Earlier quoted context omitted.

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, o…

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

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

Re: Booting Linux in One Second [pdf]

#82

1 seconds seems a rather arbitrary measure. In HCI 100ms seems to be the value that's generally taken under which an action seems to be happening instantaneously [1] 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...

Comparing the richness of the user experience for a wide variety of applications of now versus a decade or two ago, I think we are doing plenty of useful things with modern systems that is not actually "bloat".

Re: Booting Linux in One Second [pdf]

#83
post #81

Earlier quoted context omitted.

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

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

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.

Re: Booting Linux in One Second [pdf]

#84
post #50
post #18

Why isn't any phone doing it? (either smart or feature variety)

More importantly: why aren't TVs doing it? 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 :(

My GF's Samsung smart tv has to update at least once per week when you power it on. There're regular warnings for service unavailability. It spends time logging on each time you start it. Sometimes it won't even turn on when you press the button. It's a completely awful machine. I'd honestly rather have a CRT.

Re: Booting Linux in One Second [pdf]

#85
post #37

Has anyone booted the pdf in a minute?

If you use an actual pdf reader instead of the JS-based in-browser crap, it's quite instantaneous.

Yeah, that's what I've been having to do on a lot of things lately. I told them what would happen when they first started pushing it. Looked at the person next to me to say, with all the things Win98 on a PII did, the modern era chokes a Core Duo 2 trying to look at a document in a browser. Unreal...

Re: Booting Linux in One Second [pdf]

#86
post #40

Presented by Montavista already in 2009: https://youtu.be/-l_DSZe8_F8 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...

And QNX before that. But, that's a well-engineered, UNIX-like microkernel rather than Linux. Oh well...

Re: Booting Linux in One Second [pdf]

#87
post #40

Presented by Montavista already in 2009: https://youtu.be/-l_DSZe8_F8 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...

And QNX before that. But, that's a well-engineered, UNIX-like microkernel rather than Linux. Oh well...

QNX was open source for a while, what is surprising is that there doesnt appear to be an easily searcable version of the code available on google.

Re: Booting Linux in One Second [pdf]

#88
post #68

Earlier quoted context omitted.

Have you tried performing using an android app? I used a drum-pad app the other week and the latency makes it unplayable. There's a great explanation here as to why it's so bad: http://superpowered.com/androidaudiopathlatency

This is fixed in newer Android phones: https://source.android.com/devices/audio/latency_measurement...

That's a relief. They are finally taking the issue seriously then.

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.

Post reply on HN