You can still see the output of your kernel and init system... on the serial console.
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.
I'm not really impressed by that idea. Pretend I copied your whole post, except it's about wanting to run a web browser. It's so convenient to grab an entire different device to tether into your computer to browse on, why would you want to use the built-in screen for browsing?
Huh? Because you want to see/interact with what's on the screen approximately 100% of the time when browsing, but a tiny percentage of the time (only when something's broken) when booting.
"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."
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.
Maybe you don’t have a “main screen.” A lot of devices don’t. For example, servers, NASes, or smart speakers. Or maybe your main screen is just not made for display of text at the level of detail required—like a smartwatch, or an IoT device like a thermostat, or even a jumbotron/billboard computer that’s too big to see up close.
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.)
> Maybe you don’t have a “main screen.” A lot of devices don’t. For example, servers, NASes, or smart speakers. Or maybe your main screen is just not made for display of text at the level of detail required—like a smartwatch, or an IoT device like a thermostat, or even a jumbotron/billboard computer that’s too big to see up close.
>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
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.