I get the same problem on Fedora, its irritating.

And I hadn't that problem in KDE.

Invariably I miss the fact that the disk-activity light is still lit, start typing my password and then become annoyed because it only caught the last few characters. So then I have to wait AGAIN whilst it proudly announces an authentication failure and punishes me with a further delay.

I got so used to that jankiness that I didn’t notice it until I was showing someone my laptop who was interested in buying the same model.

(there are other security fixes by adopting Wayland)

I've seen this behavior with the old 'gnome-screensaver' (which I think ubuntu hasn't used for quite a while), but with the current gnome-shell lock screen it behaves properly and doesn't black out the screen when I open my laptop.

Never seen it with Arch with https://wiki.archlinux.org/index.php/Slock mind

wow, a lucky person, Ubuntu on my Desktop never wakes up :)

// p.s.: still better than macOS/Windows for development, I just don't turn it off, that's all

Bad idea, security-wise.

But if the GPU driver is broken about command committal, then there is only so much you can do short of fixing those .

Every distinct piece of Apple's boot process (firmware, boot loader, kernel, desktop) can have the correct video driver, be aware of the desired final video resolution, and trust that any previous piece has left the video card in the proper state. It all ships together.

The PC BIOS doesn't know you want 2560x1600 for your desktop. It just picks a mode suitable for the BIOS. If anything, the BIOS is required to leave the screen in VGA text mode. The boot loader faces the same issue. At best, a Linux distribution might decide to use a VESA mode, but that can't cover the desired 2560x1600. (VESA doesn't go that high)

UEFI graphics drivers usually support much more fine grained modesetting than VESA, assuming you have a native UEFI graphics driver rather than one that's thunking down to a legacy BIOS option ROM. They're also (usually) capable of reading and parsing EDID and will set a native mode if possible. The number of people not running their desktop at their display's native mode is sufficiently low that it's not really worth worrying about.

That's why we switched to UEFI around a decade ago; I'm pretty sure it doesn't have all those problems. So a modern PC can boot directly into the correct resolution.

–Matthew Garrett (he wrote a lot of the Linux kernel UEFI implementation)

Mines an Asus Gene VIII and using a 1080Ti and I don't even get anything appearing at all until the Windows logon.

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?

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?

In fact, I think you could choose to set it up this way from the Ubuntu installer directly. By default, it just encourages you to sign in manually in addition to setting up FDE.

EDIT: To clarify, my setup requires inputting passwords twice: once for decrypting the root partition, and once to login after everything has booted. During the boot process the system needs to remount everything, so I had the encrypted partition(s) also be decrypted with a key file (typically `dd if=/dev/urandom of=keyfile bs=1M count=4`; LUKS encryption can have multiple keyfiles/passwords to decrypt) and had the key file(s) put in the initramfs so after GRUB has decrypted root and loaded /boot/grub.cfg, the booted system could decrypt and mount everything needed with the key file(s).

It didn't happen in early versions on Windows 10. It started with one of the major updates. My guess is if you don't have a screen on when the login page first shows, it down-samples your background image to some low resolution, and then just stretches it out to fit to your actual screen res when you do turn your screen on.

Once logged in you get the full 5k. So it's still not 100% over in Mac land. :D

Flicker-free boot is nice to have, but it's not a _big_ deal.

I can live just fine if the boot flickers twice. But somehow doing animation with tearing for the rest of the work-day is quite a bit more annoying.

UX isn't about what you as a user feel, it's about what users feel, and OP is probably talking about UX for all users, not just those comfortable with Linux and it's tendency to have a janky UI.

But- I'd rather they fix a bunch of other things first.

I'd put "things that don't work" in the first todo bucket, then move on to "things that are painful to endure", followed by "things that make it feel janky"

I wanted to use Fedora recently and it totally failed to handle my perfectly common laptop graphics card. Ubuntu did it fine.

I don't think it's a big deal at all. Or rather, I think it's important, but it's the last bit of polish that you put on things after the rest of your house is in order. It's a nice-to-have.

Meanwhile, I installed Debian buster on a 2016 MacBook Pro -- a two year old laptop -- and sound and suspend-to-RAM don't work (hell, the keyboard and trackpad didn't even work at all without installing an out-of-tree driver post-OS-install; I had to do the install using a USB keyboard). Yes, I get that this probably isn't super common hardware, and it's also a bit exotic, but... c'mon. I just don't care if my screen jumps between text and graphics mode or changes resolution a couple times before I get to the login screen. It just isn't on my radar at all.

The Xorg touchpad drivers are a mess: libevent is one-size-fits-none, synaptics is buggy and unmaintained, and the fork of mtrack that's still maintained might be able to come close to something decent, but I'm not sure because I've already spent a couple hours tweaking its settings, and I still can't get it to not randomly send scroll and button events while I'm typing.

So no, I don't care at all about something useless like "flicker free boot". I want my laptop to be actually polished in ways that are functional first.

And I get it: it's not up to me to tell people what to work on during their free time. Everyone has their own itch to scratch, and that's a very personal thing. But to then (as you have) arbitrarily decide that visual polish during a functionally-irrelevant period of the machine's operation is more important than day-to-day functional polish while I'm actually interacting with the machine? Nope... not buying it.

And I agree with you that the basics need to run well first, but in my experience many common distros got that covered. Debian is one of the exceptions, it's pretty much the only Linux distro where not everything runs fine out of the box on my laptop.

So it's up to me now to tell you: If you want to run Linux on Apple hardware, help getting it to work! Otherwise please just use hardware with Linux supported by its vendor instead of complaining here.

One great thing about open source is that everybody can work on what he needs or what he enjoys. So if people enjoy working on flicker free boot, that's great. Other people enjoy reverse engineering Thunderbolt adapters to get them to work with Linux or dig into the depths of the state machine required for touch pads to properly work. In the end we all benefit from such work, as each little piece gets us closer to the completed puzzle where everything works smoothly.

It seems unfair to compare your mac experience on a mac to your GNU Linux experience on a mac.

See that "I", that IMO shows you missed the point.

More than once having the kernel boot visible has helped diagnose hardware failure or other OSI layer 1 issues with the system.

The level of disruption can vary greatly depending on your particular hardware; some external monitors take multiple seconds to show an image after the display mode is changed.

Then again, dependint on the distro, they don't really cater to the average user.

For the most part, though, I just don't notice it. One way or the other.

But mumbled sheared terminal output is none of that.

https://news.ycombinator.com/newsguidelines.html

And classic Mac. First time I saw Windows 3.1.1 boot my jaw dropped. What an ugly hack. That’s what’s conquering the world? The monitor wouldn’t even turn itself on. Never mind having to manually eject a floppy after you just told the computer to do it for you.