What this is doing is telling the driver to ignore it's normal reset procedure because someone else, but specifically not you, has already done the super complex modesetting and you are to trust it implicitly.
So next year, when the sales people come up with the idea that they want to show an animation across all your DisplayPort chained monitors at boot, the guys at Apple buckle down for a month, hack that into the bootloader and then hack their kernel to recognize it, ships the same year. On Linux, for the first ten years, nobody cares because there are much larger fires to put out, then ten years are spent on a vendor and display technology agnostic VR ready boot up animation description format, ten more years pass for a critical mass of boot firmware and kernel graphics drivers to support it, then it ships with Ubuntu but every third boot has flicker or a weird rotation issue.
The only time I want to see these handoffs and a ugly text dump is when things are broken and I’m debugging it, which should never happen anyway.
Why do we expect such mediocrity out of our software?
A ridiculous amount of modern products have gained a boot sequence that should not need one, and didn't used to. Hiding it doesn't fix the real issue.
five seconds, year 2008: https://lwn.net/Articles/299483/
two seconds, year 2017: https://www.youtube.com/watch?v=IUUtZjd6UA4&t=17
"The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair." -Douglas Adams
I do also turn off the splash screen in linux so that I can watch the service startups fly by.
Experience
I think it's fair to say that in general, users want to be lied to. That's why UX patterns like screenshots of suspended apps being displayed while the app actually loads became standard. The appearance of speed is effectively as valuable as actual speed, just like the appearance of polish is valuable regardless of the cruft that lies beneath it.
The suspended app screenshot is way more that appearance. We all need a moment to remember to context of what we were doing. Showing us a screenshot of the suspended state enables us to use the loading time productively so that we are immediately ready to interact once it's up.
The speaker was vital to inform the user as to what was happening. If the phone line was in user, if there was a dialing problem, if you called the wrong number, etc. And it also gave you an indication of the connection speed and line quality.
Pressing a key to get the "full dump" is in fact how plymouth works, which many Linux distributions use from the kernel up until gdm/display-manager.
There is nothing stopping any of these components from changing the display framebuffer. The "news" here, so to speak, is that finally we'll have things working where you can avoid any buffer changes and simply start drawing on the old background.
If you want, you could have grub2/etc change the framebuffer and now that could persist up to the gdm hand-off.
I understand I'm completely out of touch with how normal people use computers. I don't care.
Personally, I wish serial-over-USB (and serial-over-Lightning) cables were more common. (I don't mean that they're expensive—they're dirt cheap. It's just that nobody has any idea they exist.)
They used to be a kind of arcane thing—why would you need serial access over USB when the PC already has a serial port? And why are you debugging a PC on another PC—(taking up a quite lot of space on your desk, eh?)—when you could instead debug the PC on the PC itself?
But these days, almost nothing has a serial port, and we have perfect "secondary PCs" to serve as the recipient of the serial input: our phones and tablets. (Heck, they probably have space reserved for them on your desk already!)
Imagine: sit an iPad or some cheapo Android tablet below your monitor. Plug the "send" end of the serial-over-USB cable into the USB hub built into your monitor. Plug the "receive" end of the cable into your tablet. Open a terminal-emulator app on your phone/tablet. Bam: console logs, flowing along below your PC, as needed.
Best of all, it's not unidirectional; your phone/tablet is now a VT100, and you can log into your computer over it, even if the display server or login manager or desktop environment is wedged.
If owning these little cables was common, I'd honestly suggest just turning off the Linux text-console virtual framebuffers entirely for the Desktop versions of distributions. You want to see what's going on underneath the gloss? Tap in.
And wanting to interact is the least of the reasons to not want to hook up an external screen for something that could easily be on your main screen.
In a lot of these cases, it should be pretty obvious that there are also no permanent input peripherals attached to the target device, and perhaps not enough ports to conveniently plug them in.
So, tell me what’s more convenient: lugging a secondary display, mouse and keyboard around to plug into your devices to debug them? Or just plugging your laptop into the server and opening a terminal emulator?
The advantages of serial access are exactly the same as the advantages of SSH access, except that serial access doesn’t require an active network stack and daemon running to facilitate it, and so is usable even in a post-crash single-user mode, or in an unable-to-begin bootstrap stage.
Plus, with serial, the solution is universal—anything that supports serial output can be attached to anything that supports serial input. Whereas those peripherals aren’t guaranteed to do anything much if you plug them into a crashed PC.
Oh, and one more advantage: if you’ve ever tried writing your own kernel driver or unikernel (or game on a game console), you’ll have experienced the fact that a kernel crash that happens while the display is in graphical mode is very hard to get displayed on the screen, since you can’t know what subsystems (like the framebuffer, or the scheduler) are still in a valid state. Spewing lines onto the serial console, on the other hand, works perfectly. (And for this sort of development you can usually go even further, producing a debug build of your kernel or game that will crash into a debugger breakpoint accessible via the serial console, expecting something like gdb to be running on the other end of the serial connection. The main difference between a game console and its development kit is basically the presence of serial debugging.)
>In a lot of these cases, it should be pretty obvious that there are also no permanent input peripherals attached to the target device, and perhaps not enough ports to conveniently plug them in.
You are now describing almost the opposite of your original scenario, which was plugging ancillary devices into a PC to see the kernel messages of the PC.
>So, tell me what’s more convenient: lugging a secondary display, mouse and keyboard around to plug into your devices to debug them? Or just plugging your laptop into the server and opening a terminal emulator?
That's a weird response when I was the one arguing for having one screen instead of two.
> Oh, and one more advantage: if you’ve ever tried writing your own kernel driver or unikernel
Oh of course but that's <1% of the time.
What's wrong with dmesg?
OSx does the same thing, but hides it all behind a single load screen, as if all of those elements from hardware to DE were a monolithic "mac".
It feels like lying to the user to me. Bios isn't in control anymore, why is the motherboard logo still on the screen? How do I know when the OS takes over from grub if both are hidden under the motherboard logo?