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