logging straight onto anything may not be desirable in all cases. Handling any failures before any userspace component can handle showing errors is worth it. Period. Yes, errors can and will happen in ways where plymouth has not been started yet.
This also could serve the purpose of showing the progress even *earlier*. Again, in situations I've personally observed, the moment where you finally can do DRM (or even fbdev) is way "late" (e.g. last 90th percentile of the boot time until hand-off to stage-2).
I'll note that such a scheme would also give control to distros ***and users*** about the user experience of the boot process.
The current way Linux [does not] handle this is bad imo. The defaults and working assumptions are that the platform's vendor logo is kept on-screen all that time, mis-quoting a likely tongue-in-cheek reason: “so users blame the vendor for some of the time it takes to boot”. In turn, some of the current implementation of things in the kernel it so (without patching it) distros can't reliably provide hints that the kernel has even started booting. Users may/will be stuck without information until "late".
Let's not forget that a user-friendly distro of Linux is not limited to running on high-performance modern systems.
samueldr /
npub17n…2af8d
2024-08-24 22:47:39
in reply to nevent1q…ehz9
Author Public Key
npub17nwchcnz2densynkeu2dztxufgpftzuhzznczmvjuakejcdcgl7s92af8dPublished at
2024-08-24 22:47:39Event JSON
{
"id": "79b30afc9efc1cd2eb5ab955fcc01af2d6c6b25e17e2dd66e1cd2b23788af636",
"pubkey": "f4dd8be2625373381276cf14d12cdc4a02958b9710a7816d92e76d9961b847fd",
"created_at": 1724539659,
"kind": 1,
"tags": [
[
"p",
"aeb58459b764d3eb4ecdc304a27e311f7d7cdaafa3471b2959dc22600ed3dc90"
],
[
"p",
"066f707254c1f50f4b9777636d977837aa5111533449a05cfce478d525ab14a5"
],
[
"e",
"08111904c2bf9ab88d910295d42ceaffb975cd72c0b6ee7b8ea8ffed8a9f57ad",
"",
"reply",
"066f707254c1f50f4b9777636d977837aa5111533449a05cfce478d525ab14a5"
],
[
"p",
"2ba475a1340ebd9f8ec27d9173cd47f78bde6f58760f13854303ba6bd6f3a930"
],
[
"e",
"3a552d444893ff5791667ee4d48ad70ca2f9b974b73c5dbff652464a314ec18f",
"",
"root",
"aeb58459b764d3eb4ecdc304a27e311f7d7cdaafa3471b2959dc22600ed3dc90"
],
[
"p",
"f4dd8be2625373381276cf14d12cdc4a02958b9710a7816d92e76d9961b847fd"
],
[
"p",
"5a99c001a61c7604e620f02b8345fac4413b535f86aa1c009a0f217b756c8252"
],
[
"proxy",
"https://ap.samueldr.com/objects/14d7379c-4660-4661-936c-60b69e417efe",
"activitypub"
],
[
"L",
"pink.momostr"
],
[
"l",
"pink.momostr.activitypub:https://ap.samueldr.com/objects/14d7379c-4660-4661-936c-60b69e417efe",
"pink.momostr"
],
[
"-"
]
],
"content": "logging straight onto anything may not be desirable in all cases. Handling any failures before any userspace component can handle showing errors is worth it. Period. Yes, errors can and will happen in ways where plymouth has not been started yet.\r\n\r\nThis also could serve the purpose of showing the progress even *earlier*. Again, in situations I've personally observed, the moment where you finally can do DRM (or even fbdev) is way \"late\" (e.g. last 90th percentile of the boot time until hand-off to stage-2).\r\n\r\nI'll note that such a scheme would also give control to distros ***and users*** about the user experience of the boot process.\r\n\r\nThe current way Linux [does not] handle this is bad imo. The defaults and working assumptions are that the platform's vendor logo is kept on-screen all that time, mis-quoting a likely tongue-in-cheek reason: “so users blame the vendor for some of the time it takes to boot”. In turn, some of the current implementation of things in the kernel it so (without patching it) distros can't reliably provide hints that the kernel has even started booting. Users may/will be stuck without information until \"late\".\r\n\r\nLet's not forget that a user-friendly distro of Linux is not limited to running on high-performance modern systems.",
"sig": "ec5fe39008b6b902d362163e4facb324cc986f36881896195d208563fce960c683b5c095502760149a5f2ea0c6f4170b1764ddd3bad944a53487910f8e8d5183"
}