samueldr / is on Nostr

Hi! :samueldr-1:

If you want to know about the projects I'm working on, look here:

- [ https://samuel.dionne-riel.com/projects/ ]

Contacting me? Maybe here, or else:

- [ https://samuel.dionne-riel.com/contact.html ]

I may follow back, I may not. I curate my feed heavily to make it consumable. I do not drink from the firehose. I might even follow people and mute their re-whatevers, or them entirely. When I mute, it does not mean I disagree.

If I follow you, I don't expect a follow back.

www: https://samuel.dionne-riel.com/
github: https://github.com/samueldr

Last Notes

2024-08-25 00:47:39

- reply

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.

2024-08-25 00:16:55

- reply

then scratch that other example idea I had off the cuff into how better userspace integration can be helpful for many different UX and debugging purpose.
TBF, you're also assuming it's just a standard process, which is not a given, given the incomplete idea. It could have a minimal surface area. The binary could be limited from doing anything other than "stack trace → raw framebuffer" translation (e.g. deciding how and what to draw on that framebuffer). This way the kernel could ship a minimal version of what they need, and distros are free to make the experience fits their narrative.
But I'm theorycrafting ideas and ways to make thing better for everyone, instead of stamping down ideas. ¯\_(ツ)_/¯

2024-08-24 23:45:36

- reply

This is a case where the word "unsafe" is way too vague.
Is it unsafe to *attempt* to provide a better UX, where the worst case scenario is the current status quo? (No message shown.) In all other cases it would be assumed that it ran enough to help the user.
Having the kernel handle launching those helpers is the only way that can be reliable enough.
E.g. on kernel panic, the current userspace should be considered a lost cause, no? So why rely on it?
And on startup, the initrd might not be usable. A current common issue with some systems is the initrd being accidentally stepped over when using U-Boot native (non-EFI) boot on U-Boot. At that point assuming the distro doesn't have fbcon in its kernel, there is no output, and the system is in *a bad state*.
initrd is *way too late* to properly handle this.

2024-08-24 20:48:09

- reply

one idea for integration, which would be a lot more generic than patching-in a specific tool, is to *somehow* provide static binaries to the kernel that can run in their own "bare root", and tagged for some use-cases.
**So, use-cases?**
The obvious one is some form of early output handler that encompasses the boot logs too. This could not only handle *showing* boot logs according to semantics customizable by the distribution. Not only can it handle boot logs, but with proper userspace smarts, also hand-off to the next graphical thing, or do anything... e.g. progress bars encompassing the full boot?
Another use-case would be another "tag" for hooking up to kernel panics. While panics are "major system ending events", I believe it should be fine to allow a handler to *try* to make it more useful for end-users in some form. What if `systemd-bsod` was able to hook itself into that system and *also* handle kernel panics? That would be a neat way to tie the idea up!
**And *somehow*?**
My first guess would be a `cpio` file provided in a certain way to the kernel would be useful, and a useful mechanism to add other "smarts" to the boot process.
Anyways, just some thoughts I had a while back. Take this for inspiration.

2024-04-26 02:15:38

With MS-DOS 4.0 being "released" as MIT, this means that ***the*** MBR is now, too... huh<li><a href="https://github.com/microsoft/MS-DOS/blob/main/v4.0/src/CMD/FDISK/FDBOOT.ASM">https://github.com/microsoft/MS-DOS/blob/main/v4.0/src/CMD/FDISK/FDBOOT.ASM</a></li>