[_red]

Great points, a tangential thought:

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

[rusk]

> satisfies the user

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.

[fizzynut]

Cheap tricks can create a much more responsive experience.

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.

[rusk]

> Whenever you know in advance

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.

[grayhatter]

Do you believe that you can reason about a computer? I'm going to assume yes. If you'd rather your computer do the countable number of things you know it needs to do, before it draws to the display because it's faster. That's only because you know thoes things exist, and how long they should reasonably take. Most users can't count them, nor do they trust their computer. The loading screen does satisfy them because they know the computer hasn't randomly crapped out... *again*. People who don't understand how to fix computers don't trust them. Rightfully so, they generally dont do what their owner/users want, and randomly will just break costing more money, for seemingly no reason. Those loading screens prevent some of the anxiety of using something you need when you don't understand any part of it.

[smoldesu]

Today's laptops and the majority of desktops boot more than 10x faster than they did a decade ago, so for all but the youngest users I feel like this point is moot. There was an age where you had to go get a coffee while your hard drive started spinning up, I remember kids starting their Macbooks before they got in the car for school so they'd be booted by the time they were in class...

[bitwize]

When I was a kid, kids weren't issued MacBooks for class. There was a single, lone Apple II in the back we played Oregon Trail on -- and it took a fair few minutes to load from floppy.

[nl]

A floppy drive? Get off my lawn

On my C64 I'd start loading a game from cassette tape before dinner so I could play it afterwards.

[jamiek88]

Cassette? Pah!

I had to type the games source code in from a magazine for my acorn electron.

[noizejoy]

Cassette tape?

Punched tape[0]: Hold my beer

[0] https://en.wikipedia.org/wiki/Punched_tape

[gzer0]

Floppy drive?

On my 9 track tape I would be lucky if the thing loaded and was ready to use 72 hours later [1].

[1] https://en.wikipedia.org/wiki/9_track_tape

[rusk]

I … think I agree with you …

[II2II]

Yes, it does matter. If Microsoft switched things up to provide users with a responsive desktop just after logging by loading more services before the login screen comes up, existing Windows users would perceive it as slower. If Linux distributions delayed the loading of services at the expense of a less responsive desktop just after logging in, existing Linux users would perceive it as slower. Simply put, each user base is using different metrics for boot time and their metrics are based upon their prior experiences.

[MuffinFlavored]

> for a few minutes

When is the last time you cold booted a modern Apple Macbook for example?... Minutes is an absolute exaggeration.

[bayindirh]

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

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.

[fortran77]

I just timed my Windows 11 vs my Ubuntu. Windows 11 booted faster to a usable GUI by a factor of about 2:1

[bayindirh]

> Windows 11 booted faster to a usable GUI by a factor of about 2:1

Probably used fast boot and returned from an image. :)

[ohgodplsno]

From a fully fresh start on an NVMe, Windows 10 does start up approximately just as fast as a brand new Debian install.

With the added benefit of not having X11 setting modes 5 times in the mean time.

[harshitaneja]

This is quite surprising. My experience has been quite different. Have you run systemd-analyze to try to locate what's causing the slower boot?

[jraph]

Surprising indeed. Windows 10 boots quite quickly (don't know about Windows 11) but the boot of a fresh install of the latest version of Debian feels instantaneous. In a systemd container, it boots under 2 seconds even with a few extra services.

[GekkePrutser]

Windows has a trick for that. It actually hibernates the OS, GUI, Drivers etc when you shut down, just without any apps running. This way it can come back up in seconds.

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.

[c21h30o2]

And it doesn't unmount partitions when you shut down so if you use Windows one day and Linux the next you have to boot up Windows first and then reboot into Linux so that Windows will unmount its partitions, otherwise Linux can't mount them.

[GekkePrutser]

Oh yeah good point. I forgot about that.

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.

[fistynuts]

I have to say I agree. Presenting a login screen early is a great idea, as most people take a short while to log in, and in that time system can finish initialising - as long as there is enough free CPU and interrupts to service the keyboard and mouse during that time.

[moron4hire]

I even do this in my web apps. The login screen shows immediately, and while the user is filling it out, the WebGL app and assets are loading in the background. The login button doesn't become enabled until the audio system is loaded, so that the click on the login button can be used as the User Gesture to activate the AudioContext.

[ranger_danger]

why do you need WebGL and an AudioContext to click a login button??

[moron4hire]

I don't? Why would you think I did? My app is a WebXR social app. You need to login first, and I use the login process as an opportunity to make a better user experience.

[aidenn0]

I have rewritten my init system in the past to start xorg before e.g. DHCP initializes.

It takes about 5 seconds to login anyways, so DHCP is usually done before my browser wants network

[m45t3r]

If you're using systemd and NetworkManager, this is already what happens. Services that depend on network are delayed until a connection is made, that generally only happens after login.

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.

[ranger_danger]

Because you would have to assume too many things.

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.

[numpad0]

Because Xorg is just a UNIX app ported to Linux and not an integral part?