Raspberry Pi 3 fastboot in less than 2 seconds (2020)
furkantokac.com
furkantokac.com
Eg.: Unless i boot from USB, i probably don't need my USB mouse nor ethernet before X server and Firefox had started. So why not start initializing those peripherals later in parallel while userspace already works on starting browser? Obviously this does not fit all imaginable usecases, but would be nice to be configurable.
Why couldn't you? I didn't read the whole thing but there's a note at the top saying they're working on getting USB and Ethernet working. That's probably how.
I built a IRC bouncer in a box using a OrangePi Zero, buildroot, ZNC and "The Lounge" - and sold them at the CCC 2017.
The buildroot part was actually much nicer than I expected; if I was doing the same today I might try to adapt Oasis userland to it, but for a small "embedded" immutable little box it was excellent.
Here's the code: https://git.drk.sc/Derecho/irc-sbc-buildroot
This is funny. I'm sure there's a intresting reason why there's a driver for a 1978 UART chip involved. (ref: https://en.wikipedia.org/wiki/8250_UART)
For most operating systems, time tends to be spent in two areas:
1. What-ifs, to mitigate hardware changes, software changes and environmental changes
2. Actually loading and starting the stuff you need
That second part can be pretty fast and optimised, and if you eliminate the first part, what you'd do when resuming tends to be the same as loading/starting, but you're going to get bottlenecked by storage-to-RAM if you need to restore the entire memory at once. At that point, if loading/starting programs is fast enough, you might as well do just that. As a bonus, you now get to use events and parallel processing which can give you significant performance gains.
But, if we go back a bunch of years and make it a bit more generic (not just focus on Linux); there was indeed a very long time where having a pre-loaded image (essentially the entire machine state) was the fastest you could get since the time spent on individual tasks was so much slower than it is now. The biggest difficulty was making sure that a restored state was stacked on top of pre-initialised hardware. In a way, this is still how many IPL processes for mainframes still work; the entire system is brought out of reset and initialised using a separate system, which then dumps the OS on top of an already-running system.