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-24 22: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-24 22: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 21: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:09:13

- reply

> the VT is running on top of the framebuffer
> not least because FBDEV_EMULATION (which CONFIG_VT relies on for all modern graphics drivers) is marked as deprecated in the kernel
We might be talking past eachother, but quickly looking at it all again, that's `fbcon` that runs on top of the framebuffer (`default DRM_FBDEV_EMULATION`), and `fbcon` uses features from `VT` (`select VT_HW_CONSOLE_BINDING`) to work.
You can have the `VT` subsystem all working without `fbcon`, `FB`, `fbdev`, or even `DRM` being involved at all.
```
~/.../celun/celun $ grep 'CONFIG_$VT\|FB\|DRM$' result/config
CONFIG_VT=y
# CONFIG_VT_CONSOLE is not set
# CONFIG_VT_HW_CONSOLE_BINDING is not set
# CONFIG_DRM is not set
# CONFIG_FB is not set
```
It might be that you *also* want to get rid of `VT` (which is fine too). Though there would be other separate reasoning for that.
Also it's one of the many pet peeves of mine: the broad conflation and confusion around the terminology of `VT`, `TTY` and `fbcon` at large.
* * *
Just to be clear: **I completely agree** that it should be deprecated, and that fbcon is a real pain to deal with. I just think it's important to be precise with the wording.
Anyways, thanks for coming to my — oh crap, the Wendy's manager is coming at me, gotta go.

2024-08-24 19:11:50

- reply

(Not that it matters much in the end, but be mindful about confusing `CONFIG_VT` with `CONFIG_FRAMEBUFFER_CONSOLE`; the latter is the bad part, fbcon is the bad part... `VT` is the part allowing e.g. switching to different "consoles")

2024-08-24 18: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-06-26 22:22:17

2024-05-25 10:26:41

Ever had the sheer desire to build DOS4, within the Nix sandbox, and receive a valid (but inaccurate) bootable DOS4 floppy?
Well, now you can!<li><a href="https://github.com/samueldr/dos4.nix/">https://github.com/samueldr/dos4.nix/</a></li>
This involved figuring out how format, sys and friends decide a system is valid for format /S to work out fine.
I'm not really knowledgeable with DOS before 6.22, so I don't really know what to do with it. Though I did learn how to use edlin to futz about.
I guess a good "next step", if any is needed, is make select.exe happy with the floppy so it can be used to install to a hard drive interactively.
#nixos #nix #dos

2024-04-26 17:27:41

(uncharitably paraphrased) “No we're not attempting to take over the project” and later “join our discord where we are attempting to take over the project”.

2024-04-26 00: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>