3 ms·

There exists a world of devices that are off and need to power on within a few seconds. Think of your media console in your car. Have you actually profiles tha

There exists a world of devices that are off and need to power on within a few seconds. Think of your media console in your car. Have you actually profiles that copying the 500mb rootfs is the bulk of your boot time? At around 150MiB/s, which is common for USB these days, I would expect that to only take ~4s, and copying from ram location to ram location is far faster. I would expect your boot time is a lot longer than that.

wed239023 2y ago
Bootloader most likely operates in much slower safe mode. Perhaps USB2, or even 1.1.
nine_k 2y ago
IDK; on my laptop, the boot time is dominated by opening the encrypted disk. From there it's well under 3 seconds to the Xfce login screen. (A T14, m.2 storage, runit as the init system.)
- graemep 2y ago
  I find the same. Combine that with sleep being far more frequent that restart, and boot times are unimportant. I think the need for faster boot comes from people who scale cloud servers or containers up and down a lot.
  - nine_k 2y ago
    Yes. But a cloud VM instance can boot very quickly, because it has fixed hardware and does not have to probe for physical devices. Waiting for enough random events to happen to init the encryption used to be a major drain of startup time; likely not a problem any more.
- nialv7 2y ago
  Unlocking encrypted disk isn't I/O bound though. The key derivation step is designed to take a set amount of CPU time (say, a second), so it's difficult to brute force.
  - nine_k 2y ago
    Indeed, it ought to take time to afford protection. Optimizing the rest may be fun, but already changes little in a laptop. (A cloud instance with a disk without encryption is a different business.)
account42 2y ago
I don't think there are any devices where "withing a few seconds" is a useful target for the startup sequence. Most devices should really be instant, which means hibernation / full memory snapshots and your real boot system becomes mostly irrelevent. Everything else is really in "meh" territory. That said, OpenRC is already quite fast and both my laptop and desktop boot in a few seconds using it - the EFI takes much longer to do whatever it does and hand control off to the kernel than it takes from kernel to desktop login screen.

wed239023 2y ago

Bootloader most likely operates in much slower safe mode. Perhaps USB2, or even 1.1.

nine_k 2y ago

IDK; on my laptop, the boot time is dominated by opening the encrypted disk. From there it's well under 3 seconds to the Xfce login screen. (A T14, m.2 storage, runit as the init system.)

graemep 2y ago
I find the same. Combine that with sleep being far more frequent that restart, and boot times are unimportant. I think the need for faster boot comes from people who scale cloud servers or containers up and down a lot.
- nine_k 2y ago
  Yes. But a cloud VM instance can boot very quickly, because it has fixed hardware and does not have to probe for physical devices. Waiting for enough random events to happen to init the encryption used to be a major drain of startup time; likely not a problem any more.
nialv7 2y ago
Unlocking encrypted disk isn't I/O bound though. The key derivation step is designed to take a set amount of CPU time (say, a second), so it's difficult to brute force.
- nine_k 2y ago
  Indeed, it ought to take time to afford protection. Optimizing the rest may be fun, but already changes little in a laptop. (A cloud instance with a disk without encryption is a different business.)

account42 2y ago

I don't think there are any devices where "withing a few seconds" is a useful target for the startup sequence. Most devices should really be instant, which means hibernation / full memory snapshots and your real boot system becomes mostly irrelevent. Everything else is really in "meh" territory. That said, OpenRC is already quite fast and both my laptop and desktop boot in a few seconds using it - the EFI takes much longer to do whatever it does and hand control off to the kernel than it takes from kernel to desktop login screen.