Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why can't computers boot instantly? (2013)

superuser.com

Post reply on HN
Print view View original

141–150 of 167 posts

Re: Why can't computers boot instantly? (2013)

#141

Post by Dylan16807 »

bane wrote: post #97

All of the answers here are missing something. In the old days, the OS was often on a ROM that was simply mapped into some unified memory location. Thus the system went from a state of "off" to "ready to go" pretty much immediately. There wasn't a need to copy the data from the ROM to RAM and then execute some stuff to get into an initialized mode. If you hunt around a bit for things like "atari 800 memory map" you c…

Grabbing the kernel and login screen off of an SSD, then mapping the rest of what you need into virtual memory, is something that's easily accomplished in 100ms. If you design for 3-5 seconds of password typing that's enough time to grab gigabytes in the background.

The complex memory system isn't the culprit here. It's one of the easiest parts to set up.

Re: Why can't computers boot instantly? (2013)

#142

Post by bin0 »

Let me take a moment to vent on the garbage that is the dell UEFI firmware. I have an excellent, new machine, an XPS 15 9570. According to systemd-analyze, it took eight seconds to get past firmware, corroborated by my observations. There is flat-out no reason why it ought to be so slow. Dell makes the absolute worst BIOS.

Re: Why can't computers boot instantly? (2013)

#143

Post by fallingfrog »

salawat wrote: post #99
petra wrote: post #91

Earlier quoted context omitted.

// What happens is that S1 is different for different computer configurations, and processing needs to happen. The computer and OS config doesn't change often. And it's doesn't seem slow to test that. So caching at boot should work. And caching is a low effort optimization. So it should have been implemented early. But we don't have caching at boot, why?

The two hard things in computer science are naming things, and cache invalidation. Remember; the computer could quite literally have been completely reconfigured out from under the BIOS. Testing that everything is the same from the computer's point of view is anything but straightforward. Also, most recognizable boot time isn't spent waiting on BIOS and POST; it's spent waiting for either the boot loader, disk encryp…

..why could you not just use some kind of hash of all the relevant files/drivers to tell if the system config has changed?

As in: the os has a flag that says if each file is used in startup. If a startup file is written then the startup config hash is recalculated. It’s a global hash that uses every startup file. If the startup hash does not match the startup hash from the last bootup, then we don’t use the cached config.

Seems straightforward enough to me.

Re: Why can't computers boot instantly? (2013)

#144

Post by dkersten »

argimenes wrote: post #16

When I was in high school their Amiga would cold boot into a GUI within 3 seconds. It was the same for the Acorn Archimedes in the UK. These computers had the entire GUI OS burnt into the ROM. After that I remember the shock or getting a 386 and waiting minutes for Windows 95 to load. It was like the future had died and was buried by a conspiracy of silence in the industry.

> When I was in high school their Amiga would cold boot into a GUI within 3 seconds.

I have a cheap laptop (it does have an SSD) that boots from pushing power to a minimal but perfectly usable i3 window manager system in a second.

Re: Why can't computers boot instantly? (2013)

#145

Post by salawat »

fallingfrog wrote: post #143
salawat wrote: post #99

Earlier quoted context omitted.

The two hard things in computer science are naming things, and cache invalidation. Remember; the computer could quite literally have been completely reconfigured out from under the BIOS. Testing that everything is the same from the computer's point of view is anything but straightforward. Also, most recognizable boot time isn't spent waiting on BIOS and POST; it's spent waiting for either the boot loader, disk encryp…

..why could you not just use some kind of hash of all the relevant files/drivers to tell if the system config has changed? As in: the os has a flag that says if each file is used in startup. If a startup file is written then the startup config hash is recalculated. It’s a global hash that uses every startup file. If the startup hash does not match the startup hash from the last bootup, then we don’t use the cached co…

Because all of that is on the hard disk; which may be encrypted.

There's more going on during boot than you think. Bootloaders are meant to be small and simple; just enough to hand off to the OS.

If your OS takes a minute to get its stuff straight; there isn't really much you can do to make the boot faster.

Re: Why can't computers boot instantly? (2013)

#146

Post by fallingfrog »

salawat wrote: post #145
fallingfrog wrote: post #143

Earlier quoted context omitted.

..why could you not just use some kind of hash of all the relevant files/drivers to tell if the system config has changed? As in: the os has a flag that says if each file is used in startup. If a startup file is written then the startup config hash is recalculated. It’s a global hash that uses every startup file. If the startup hash does not match the startup hash from the last bootup, then we don’t use the cached co…

Because all of that is on the hard disk; which may be encrypted. There's more going on during boot than you think. Bootloaders are meant to be small and simple; just enough to hand off to the OS. If your OS takes a minute to get its stuff straight; there isn't really much you can do to make the boot faster.

Oh ok, so in other words a lot of the time is before the os even reads the hard drive? That would sort of make the caching approach less advantageous

Re: Why can't computers boot instantly? (2013)

#147

Post by catern »

kstenerud wrote: post #34

There are a number of reasons: 1. Hardware Hardware is a big problem for boot times. Most hardware is poorly standardized, or not standardized at all, or doesn't even follow the standards, or tries to be backwards compatible with older hardware, or is just plain buggy. This means that the initialization code has to poll and retry and work around a whole bunch of things just in case the hardware happens to be slow in…

This is a really good summary of some of the main reasons - more interesting detail than many of the other comments here.

Now what would really be interesting is if we had the same kind of knowledge about the typical causes of userspace software and distributed systems being slow to start. In my experience, for proprietary software, it's mostly because people inserted random calls to sleep()...

Re: Why can't computers boot instantly? (2013)

#148

Post by brokenmachine »

sverige wrote: post #127
FrancoisBosun wrote: post #47

Earlier quoted context omitted.

There is now a boot time for my kitchen mixer… about 2-3 seconds. It’s horrible and I always forget.

Honestly, "smart" appliances are the worst idea since . . . I can't actually think of a worse idea.

Recently I got an email ad for a "smart" kettle with an app that you can remotely turn the kettle on, or schedule a time for it to turn on...

Re: Why can't computers boot instantly? (2013)

#149

Post by brokenmachine »

gruez wrote: post #60
mojuba wrote: post #8

A bigger question for me is, why can't monitors boot instantly? So annoying that a monitor that went to sleep can sometimes take 10-20 seconds longer to wake up than the computer it is attached to.

If it's really 10-20s, I'm guessing it's because it's because it's cycling through the various input sources looking for a signal.

Why does it take 10-20s even if it is cycling through all the inputs though?

Re: Why can't computers boot instantly? (2013)

#150

Post by ebg13 »

jamesissac wrote: post #88
ebg13 wrote: post #64

Earlier quoted context omitted.

But it could just look at all of the input sources at the same time. And anyway, these are solid state electronics, not hamsters and flywheels. Taking seconds to send "give me electrons" and for the other side to say "here are some electrons" is bonkers.

Being able to observe all inputs sources at the same time requires extra hardware(more utilisation of the FPGA resources), considering only one input is connected to the display at a time. So it's probable that the check is sequential.

"More" isn't a meaningful qualifier without a quantifier. I'm not convinced that it would take more than $0.01 worth of resource. I could even see doing it in a purely analog fashion with an extremely basic component like a mosfet. If a pin goes high because the computer responded to your request to send electrons, it sets the corresponding channel.

> So it's probable that the check is sequential.

It's a user unfriendly design for the process to be "send request, wait 5 seconds, send request on next channel, wait 5 seconds, send request on next channel, ..." when it could instead be sending requests across all channels rapidly and then that getting a response on a particular channel _activates_ that channel by analogue means.

Post reply on HN