3 ms·

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

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

salawat 7y ago
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.
- fallingfrog 7y ago
  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
  - salawat 7y ago
    Other way around. BIOS and POST tend to be complete in <2-3 seconds, even on the slowest boxes I've worked with. It's exceedingly fast. The UEFI implementations on modern computers then have to scan the hard drive GPT to find the bootloaders, if there are any. UEFI Then hands off to the bootloader that then begin initializing the OS. At this point, you're probably anywhere from 5-7 seconds in in my experience. As your OS begins loading, it has to spin up the filesystem, and locate all the necessary files required to do it's thing. Most critical hardware (mouse, keyboard, video drivers) are loaded and initialized at this point. Generally, your OS would be in some equivalent of a single-user mode at this point. After the necessary local filesystem shenanigans are complete, non-critical device drivers (network, sound card, exotic storage media) tend to get initialized. Network drives if properly configured might be mapped, but generally (I.e. Windows) loads Most remote volumes after login, which is generally after the system enters multi-user mode. Windows in particular is incredibly annoying because vast tracts of configuration data is tracked in the registry; an in-memory hierarchical key/value pair binary database. Most "Windows updates" tend to involve shell scripts/installers running and performing filesystem and registry updates while you're sitting there really wishing you knew why stuff was taking so long. Stuff is taking so long because the registry is a bloody mess, and your filesystem is getting polluted by Windows not cleaning up after itself. God help you if you killed an update in the middle; as the scripts probably were not crafted with a User's convenience in mind, and therefore are likely to fail in exceedingly interesting ways. Though I habitually try to be the most horribly behaved user in that regard, and I've only encountered a handful of updates that when interrupted had caused Bad Things(tm) to happen. If you aren't into breaking things for fun and profit though, I'd not advise you doing the same. Long story short; 5-7 seconds is the absolute longest I'll tolerate for boot from hardware to OS selection. After that, faster boots depend on OS developers to get things going faster.

salawat 7y ago

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.

fallingfrog 7y ago
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
- salawat 7y ago
  Other way around. BIOS and POST tend to be complete in <2-3 seconds, even on the slowest boxes I've worked with. It's exceedingly fast. The UEFI implementations on modern computers then have to scan the hard drive GPT to find the bootloaders, if there are any. UEFI Then hands off to the bootloader that then begin initializing the OS. At this point, you're probably anywhere from 5-7 seconds in in my experience. As your OS begins loading, it has to spin up the filesystem, and locate all the necessary files required to do it's thing. Most critical hardware (mouse, keyboard, video drivers) are loaded and initialized at this point. Generally, your OS would be in some equivalent of a single-user mode at this point. After the necessary local filesystem shenanigans are complete, non-critical device drivers (network, sound card, exotic storage media) tend to get initialized. Network drives if properly configured might be mapped, but generally (I.e. Windows) loads Most remote volumes after login, which is generally after the system enters multi-user mode. Windows in particular is incredibly annoying because vast tracts of configuration data is tracked in the registry; an in-memory hierarchical key/value pair binary database. Most "Windows updates" tend to involve shell scripts/installers running and performing filesystem and registry updates while you're sitting there really wishing you knew why stuff was taking so long. Stuff is taking so long because the registry is a bloody mess, and your filesystem is getting polluted by Windows not cleaning up after itself. God help you if you killed an update in the middle; as the scripts probably were not crafted with a User's convenience in mind, and therefore are likely to fail in exceedingly interesting ways. Though I habitually try to be the most horribly behaved user in that regard, and I've only encountered a handful of updates that when interrupted had caused Bad Things(tm) to happen. If you aren't into breaking things for fun and profit though, I'd not advise you doing the same. Long story short; 5-7 seconds is the absolute longest I'll tolerate for boot from hardware to OS selection. After that, faster boots depend on OS developers to get things going faster.