MacOS and Windows have figured out that showing a GUI ASAP satisfies the user. Even if in the background its still negotiating networks, initializing sub-systems, etc.
I wonder why Linux has not yet taken that approach? That is move GUI far up in the init-queue and let it initialize networks, avahi, resolved, firewalld, etc as GUI is showing login screen...
Does it though? Has this ever really satisfied you … that you get to login and then circle your mouse for a few minutes while you wait for things to kick off.
Na, all or nothing please I don’t want to be teased by an is-it-isn’t-it experience I want my boot to take its time, let me know what’s going on and when it’s all there let me enjoy a responsive experience.
It’s just a cheap trick and it probably doesn’t matter as much as they think it does.
Whenever a user interactable element will be ready in <~100ms, you can display it as ready now, because it is faster than the reaction speed of a human, which makes all interactions with the software faster, smoother and more responsive than if I used a loading indicator. It's a free win.
Whenever you know in advance you need to display something to the user and need to load/process something that takes much longer than 100ms, you can load in the background while displaying whatever needs to be displayed and if the time spent on the screen is slower than the loading time then the next interaction will be instant (common case), if the user is faster on the screen you can still go to a loading screen, but the time it is on screen for would still be much much shorter.
Knowing things in advance is not a cheap trick. I’m not talking about a well structured boot. I’m talking about the far more common approach of just showing a moving mouse pointer and a few icons and “pretending” the computer is ready to use, a notion that is quickly disabused as soon as you try to get to work. Then even, you will her no way to know when it “is” actually ready.
On my C64 I'd start loading a game from cassette tape before dinner so I could play it afterwards.
I had to type the games source code in from a magazine for my acorn electron.
Punched tape[0]: Hold my beer
The Altair launched with a cassette tape interface anyway.
In my mental model, the technology distinction is more between single user and multi-user systems. And arguably that is more a a software differentiator than a hardware difference.
On my 9 track tape I would be lucky if the thing loaded and was ready to use 72 hours later [1].
When is the last time you cold booted a modern Apple Macbook for example?... Minutes is an absolute exaggeration.
Because it boots faster than a Windows system in that scenario. I personally like to be able to use my system as soon as the desktop is visible.
Also this is the way. When your system boots, it boots.
Probably used fast boot and returned from an image. :)
With the added benefit of not having X11 setting modes 5 times in the mean time.
Starting with latest iterations CentOS 7 and Debian 10, booting Linux is almost instantaneous. We have quite a few VMs, and after restarting one (i.e.: reboot <enter>), I just need to sip a little coffee to be able to SSH into a fully booted system.
On the other hand some of the higher end servers we have can fit a meaningful chat to the booting process (in fast boot mode, no less).
This means that most of the overhead is hardware initialization waits, IO and GRUB.
BTW, X11 is not modesetting 5 times on me. Maybe the first modeset you see is kernel's terminal modeset?
You'll notice that after you install a new device driver it'll boot much slower. This is because it invalidates the hibernate image and does an actual boot next time.
It's also why it won't let you fiddle with the BIOS settings before it does a quick boot. Because the hibernate image presumes the exact same hardware configuration.
Linux updates also wreck bitlocker if the windows partition is on the same drive (which I have to use for work) so I left the whole dualboot thing behind.
It takes about 5 seconds to login anyways, so DHCP is usually done before my browser wants network
If you're using something else than yes, the start of network services are made during boot. But it can be argued that if you're not using NetworkManager, you are a server and wouldn't benefit from delayed connection.
What if the GUI bring-up required mounting filesystems that need a kernel module that hasn't loaded yet?
What if the filesystem is on a network?
What if the network isn't up yet?
What if someone's xinit script needs access to the bluetooth stack which isn't up yet?
And even if the all the "correct" assumptions were made for a default install... doing anything different from that would require unraveling a mess to fix.
Come to think of it, doesn't the SD card slot sit off of the USB bus?
It doesn't.
This can be done with (for instance) u-boot.
The author disables several important kernel features to boot faster, including network support and USB support. Obviously, if you plan to use network or USB then it's not an option to disable those. You can disable some of the other debugging features and little extras for a slight boost, but it's going to be negligible (<1s, in my experience).
The biggest change comes from removing the init system entirely and replacing it with the user-facing app. This is the fastest way to get your app started, but now you're responsible for doing everything that was previously handled by the init system. The author can do this because they don't have any network, timekeeping, or other system functions normally handled by the init system. They only needs to mount filesystems, which is easy to replicate inside of the app.
Anyone planning to ship a Raspberry Pi based product should read this article carefully as a great starting point. Anyone who wants to use their Raspberry Pi for general purpose use or even with network connectivity or USB devices will be disappointed if they try these techniques. Great article, but it's a narrow use case.