5 ms·

It's probably been such low priority in the Linux community because most of us are big nerds and we like seeing different technologies interact, it can be nice

It's probably been such low priority in the Linux community because most of us are big nerds and we like seeing different technologies interact, it can be nice to be able to see the boot sequence bios>bootloader>OS>Desktop. 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?

another-cuppa 8y ago
True that. I want to see the output of OpenRC when I boot to make sure it all looks familiar (I only reboot after a kernel upgrade really). Then I login and type startx. I understand I'm completely out of touch with how normal people use computers. I don't care.
- rayiner 8y ago
  > True that. I want to see the output of OpenRC when I boot to make sure it all looks familiar (I only reboot after a kernel upgrade really). Then I login and type startx. What's wrong with dmesg?
- derefr 8y ago
  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.
  - Dylan16807 8y ago
    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?
    - apetresc 8y ago
      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.
      - Dylan16807 8y ago
        "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.
        derefr 8y ago
        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.)
LordDragonfang 8y ago
>It feels like lying to the user to me 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.
- FullyFunctional 8y ago
  Lying has nothing to do with it. Users don't _care_ about the details of what the system is doing and it's just cognitive noise, distracting from the task at hand. 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.
  - Dylan16807 8y ago
    The task at hand is waiting. People love to be distracted from waiting without any evidence of progress. Isn't that why they put speakers into so many dial-up modems?
    - FullyFunctional 8y ago
      I'd assume they the speaker was for diagnosis, eg. if you could hear an "Ahoy?" then you should probably start over.
    - ansible 8y ago
      Speaking as a user of dial up modems in the past, no. 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.
- pythonaut_16 8y ago
  All (graphical) user interfaces are a lie. The only real question is whether they're lying to benefit the user or not.
fipple 8y ago
Why not a single logo on the boot screen, and if you hold down Shift you can get the full dump of everything that's going on.
- audidude 8y ago
  To change the initial splash (from power-on), you'd need to get that pixmap embedded into your EFI. However, with the recent changes, any of these systems after initial EFI can alter the framebuffer and have that persisted up until wayland/xorg/etc. 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.
ryandrake 8y ago
I’m a big nerd but I don’t care when the bios hands off to the bootloader or when that hands off to the kernel ow when that hands off to the window manager. I just want those steps to go as quickly as possible without a bunch of manufacturers spamming their logos at me. 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?
- jlawer 8y ago
  > Why do we expect such mediocrity out of our software? Experience
- NeedMoreTea 8y ago
  I imagine most would simply like to turn it on and get a prompt right away, like used to happen with a C64. 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.
  - bmn__ 8y ago
    Things are possible if one puts one's mind to it. five seconds, year 2008: https://lwn.net/Articles/299483/ https://lwn.net/Articles/299483/ two seconds, year 2017: https://www.youtube.com/watch?v=IUUtZjd6UA4&t=17 https://www.youtube.com/watch?v=IUUtZjd6UA4&t=17
- userbinator 8y ago
  which should never happen anyway. "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
- grumdan 8y ago
  I think it's a matter of taste. I find seeing boot messages about services starting up etc. more aesthetically pleasing than some logo. It reminds me of people who buy mechanical watches where the gears are visible. Seeing the underlying bits of a complex system exposed can certainly be appealing to some people.
audidude 8y ago
> Bios isn't in control anymore, why is the motherboard logo still on the screen? 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.
stefan_ 8y ago
It's not in there because it's generally a gigantic hack. For the 40 or 50 years that people have been developing device driver's the basic principles have largely not changed: you start with a clean slate ans do a reset to put the HW into a known good state. Every block of silicon ever devised comes with means to reset it's internal state. 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.
- deleted 8y ago
  [deleted]

another-cuppa 8y ago

True that. I want to see the output of OpenRC when I boot to make sure it all looks familiar (I only reboot after a kernel upgrade really). Then I login and type startx. I understand I'm completely out of touch with how normal people use computers. I don't care.

rayiner 8y ago
> True that. I want to see the output of OpenRC when I boot to make sure it all looks familiar (I only reboot after a kernel upgrade really). Then I login and type startx. What's wrong with dmesg?
derefr 8y ago
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.
- Dylan16807 8y ago
  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?
  - apetresc 8y ago
    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.
    - Dylan16807 8y ago
      "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.
      - derefr 8y ago
        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.)

LordDragonfang 8y ago

>It feels like lying to the user to me 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.

FullyFunctional 8y ago
Lying has nothing to do with it. Users don't _care_ about the details of what the system is doing and it's just cognitive noise, distracting from the task at hand. 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.
- Dylan16807 8y ago
  The task at hand is waiting. People love to be distracted from waiting without any evidence of progress. Isn't that why they put speakers into so many dial-up modems?
  - FullyFunctional 8y ago
    I'd assume they the speaker was for diagnosis, eg. if you could hear an "Ahoy?" then you should probably start over.
  - ansible 8y ago
    Speaking as a user of dial up modems in the past, no. 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.
pythonaut_16 8y ago
All (graphical) user interfaces are a lie. The only real question is whether they're lying to benefit the user or not.

fipple 8y ago

Why not a single logo on the boot screen, and if you hold down Shift you can get the full dump of everything that's going on.

audidude 8y ago
To change the initial splash (from power-on), you'd need to get that pixmap embedded into your EFI. However, with the recent changes, any of these systems after initial EFI can alter the framebuffer and have that persisted up until wayland/xorg/etc. 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.

ryandrake 8y ago

I’m a big nerd but I don’t care when the bios hands off to the bootloader or when that hands off to the kernel ow when that hands off to the window manager. I just want those steps to go as quickly as possible without a bunch of manufacturers spamming their logos at me. 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?

jlawer 8y ago
> Why do we expect such mediocrity out of our software? Experience
NeedMoreTea 8y ago
I imagine most would simply like to turn it on and get a prompt right away, like used to happen with a C64. 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.
- bmn__ 8y ago
  Things are possible if one puts one's mind to it. five seconds, year 2008: https://lwn.net/Articles/299483/ https://lwn.net/Articles/299483/ two seconds, year 2017: https://www.youtube.com/watch?v=IUUtZjd6UA4&t=17 https://www.youtube.com/watch?v=IUUtZjd6UA4&t=17
userbinator 8y ago
which should never happen anyway. "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
grumdan 8y ago
I think it's a matter of taste. I find seeing boot messages about services starting up etc. more aesthetically pleasing than some logo. It reminds me of people who buy mechanical watches where the gears are visible. Seeing the underlying bits of a complex system exposed can certainly be appealing to some people.

audidude 8y ago

> Bios isn't in control anymore, why is the motherboard logo still on the screen? 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.

stefan_ 8y ago

It's not in there because it's generally a gigantic hack. For the 40 or 50 years that people have been developing device driver's the basic principles have largely not changed: you start with a clean slate ans do a reset to put the HW into a known good state. Every block of silicon ever devised comes with means to reset it's internal state. 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.

deleted 8y ago
[deleted]