I ran a really non-scientific test before on startup speed between Oasis vs a slimmed down direct kernel booted Debian with systemd.
Obviously I'm writing this because Oasis absolutely trounced it.
So; Oasis is currently my go-to for small deployed VPS's.
(here's the video if you actually care: https://www.youtube.com/watch?v=X2Aw5SSqYFo you'll note that the systemd one was delayed by the network on start- some people are going to argue that this is an artificial delay, but this is the truth of a startup and oasis had already booted before the delay anyway)
FWIW I get a faster boot time than that slimmed Debian VM with a physical Celeron class physical box booting a stock kernel, even including the real BIOS and hardware initialization time. I don't think systemd really has much to do with why that VM boots slow.
Boot speeds on the timescales in the video end up having little to do with horsepower once you get to having "some sort of SSD to load the boot image from" and "some sort of CPU that can at least decompress that in a reasonable time". It's more the "Wait here for 1 second for this hardware to probe", "Wait here for 5 seconds to see if the user wants to go into setup", "Wait here for network to timeout" type configuration items. Having a ton of high end hardware just makes this worse, more cores to initialize, more memory to initialize, more devices to probe.
I picked the low end fanless box as example because of this - it boots significantly faster than my high end box after all. It still loses out to how little a VM has to do while booting but not by much. It defaults to assuming a very short "wait on user" time for BIOS/UEFI, it has a mostly static and very simple hardware topology so doesn't need to dynamically load much during BIOS/UEFI, and systemd isn't told to do all those boot time loads/delays the Debian default config seems to have. For whatever you have "slimmed down" on it you're still trying to load nvidia GPUs, run cloud-init scripts each boot, and whatever networked service you mentioned thinks it needs to wait for network before letting the box finish booting is. Those kinds of things are what make the Debian VM boot slow, not systemd or necessarily the size of the kernel until the more noticeable things are fixed. Systemd is just what Debian uses to do those boot time things and if you did the same things with OpenRC or SysVinit or your own init system without changing what was being done it'd be a pretty slow boot too.
As for VPS if "not systemd" and small/fast/static are high or your list I'd highly recommend Alpine Linux over Oasis. It's known as the gold standard for containers but it makes a nice lightweight VM box too. I don't have anything against systemd but I did run Alpine as my standard VM image for a number of years and was very happy with it on the server side plus you get to keep convenient things like a package manager if you so desire. Their "Virtual" pre-built image will have the kernel image and firmware files slimmed down to the point you might not even care about trying to roll your own changes into it.
Machines with more cores and ram actually take longer to boot. I believe some of that was due to the dram training that must occur on startup, but the is must also discover all of the cores and build up the internal state to manage them. I believe some xeons take on the order of minutes to boot due to some of these considerations.
"Enterprise" class servers do a lot more in POST than consumer/desktop machines. On an older server, this can take minutes. Once the OS actually starts to boot, I have not noticed an appreciable difference.
Even if that were true (which it’s not) then those points would be nullified by the fact that QEMU is exposing very little hardware (cores) and devices to the guest.
The one on the left gets caught on raising network interfaces. I don't think your beefy machine will speed that operation up much. It wouldn't be that surprising if somebody can beat that boot time by tweaking that step (depends on the configuration -- in the extreme you don't even need a network interface or can delay it until the desktop environment is started and the user starts thinking about web browsers).
> The one on the left gets caught on raising network interfaces
I mentioned in the parent that Oasis had already booted before the delay even begins.
I also mentioned that it's not really fair to compare Debian being greatly optimised: I was measuring the practical loading time of a stock VM (that was optimised for being a VM in Debians case and which bypassed the BIOS).
I think there's sufficient reason to not believe him without evidence.
Oasis took under a second to get to a login prompt, Debian took about 1.5-2s.
UEFI BIOS takes longer than that on every system I've ever used, even little fanless ones(they weren't ever faster actually). So this claim alone makes me suspicious; but also booting faster than Oasis, on worse hardware, with more steps than my system with the slower of the two OS's I ran.
I mean, there's a point where you suspend disbelief without evidence.
Am I misreading something? They said their system booted faster than the slow debian boot that you've shown, I think. That took (including the network time) like 8s to boot. It isn't surprising that they have a system that boots in 8s. As you note in the comment, it hangs on the network, but that's part of the boot.
It is an irrelevant comparison, but there's no reason to call them a liar over it, because it is not that surprising that a system can boot in 8s.
I'm fine with the downvotes, I didn't provide explanation. Even a casual inspection will provide basic insights such as seeing ifupdown-pre.service taking seconds on many systems.
Normally for me on debian, just compiling the kernel to remove most modules and get rid of initrd gave great results. But the kernel config is not the same on all the machines of course.
Obviously I'm writing this because Oasis absolutely trounced it.
So; Oasis is currently my go-to for small deployed VPS's.
(here's the video if you actually care: https://www.youtube.com/watch?v=X2Aw5SSqYFo you'll note that the systemd one was delayed by the network on start- some people are going to argue that this is an artificial delay, but this is the truth of a startup and oasis had already booted before the delay anyway)