samueldr

Hi! :samueldr-1:

I'm samueldr (he/him; they is fine too). You can also use my full name, Samuel Dionne-Riel.

- - - - - - - - - - - - -

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

2026-03-27 13:22:08 UTC

- reply

this *could* highlight that at least it's not checked starting from `preloader`? See this other bits of thread
- https://donotsta.re/objects/c496e7e4-0653-468e-ae6e-72f90eb0d889
Depending on the details of what makes fenrir feasible, that might "just" be part of the bits that aren't checked by their `preloader`
The ideal scenario would be to find some way to let the device tell you whether or not its SoC has a fused root key...
- https://github.com/R0rt1z2/fenrir/blob/094a5c2f6ab90359902043d594f46701331128f4/injector/devices.py#L42-L63
(TBF, I have no clue if MTK SoCs sold for phone uses must be delivered pre-fused, for example, or other limitations that means it's unlikely or impossible for it to be unfused...)

2026-03-27 12:56:42 UTC

- reply

this honestly looks tempting... even if it results in an insecure device (i.e. unfused BootROM)... and especially if it results in a better user-owned device (i.e. unfused BootROM) where *shenanigans* can be recovered from. 🤔

2026-03-01 14:12:38 UTC

- reply

Time to "pleasantly" keep thinking about the person on the other end. In this particular instance the situation might be more nuanced than just a "vibe coder"[sic] maintaining and working on a project.

2026-03-01 04:29:02 UTC

The joke writes itself...
I noticed a component of my “DE” pegging a CPU core ***hard***, I open the repo for the project, notice there are blocked users who contributed, which is "claude"... First thought was “I wonder if that's related”... After bisecting, and finding the fix (not in a tagged release yet) it turned out that yes, it was.
*Siiiiiiiiiiiiiiiiiiiigh.*

2025-01-06 20:59:49 UTC

- reply

I see the job is “Remote (United States)”, am I right to understand that applying, being Canadian, wouldn't lead to anything?

2024-12-16 19:32:28 UTC

Hi, I'm still looking for a job. Still in [the same situation as previously posted](https://ap.samueldr.com/notice/Ams7XcBB0dKqdZ1FpY).
* * *
Skills/experience:
- Distribution integration
- Experienced with NixOS, previously Arch Linux user
- 18 years using Linux as my only OS
- “Holistic” understanding of the whole boot process
- Experienced with U-Boot
- Previously “full-stack” web developer (13+ years, and still doing some here and there.).
Employers and recruiters: feel free to consider the experience in a generic manner; the skills I have had to learn for the things I've done translate to any distribution. I am not “a NixOS developer”, but really, “a distribution developer”.
* * *
I am looking for remote work, and live on the *Eastern Time Zone* in North America. I am flexible about working hours if needed. I am bilingual (French and English).
A good fit for me will have me working and contributing back on Open Source Software as a significant component.
If you know of a job that would fit, feel free to reply at any visibility here. Feel free to also ask me superficial questions right here!
If you are interested in hiring me, [please e-mail me `<samuel AT dionne-riel.com>`](https://samuel.dionne-riel.com/contact.html).
Thank you for your time.
(Boosts / reposts appreciated.)
#fedihired

2024-12-05 21:21:34 UTC

Wrote some words specifically about the *problem* that is handling *dtb files* on devicetree platforms with the Linux kernel's expectations regarding its own *dtb files*.
I suspect this may be somewhat controversial, and will spark debate (which is also kind of the goal). Still, I hope everyone who reads will make a good attempt at internalizing the nuances I am trying to highlight, even if they disagree with some of the details.
- https://samuel.dionne-riel.com/blog/2024/12/05/dtb-loading-is-harder-than-it-looks.html

2024-11-20 21:59:05 UTC

So, [what's in a Steam Deck kernel anyway?](https://samuel.dionne-riel.com/blog/2024/11/20/whats-in-a-steam-deck-kernel-anyway.html) I took some time to list mainly the misc. changes that are not the video drivers work. (Not that they're unimportant, but that they're more well-known.)

2024-10-10 18:42:33 UTC

Hi, I'm looking for a job. I have not been fired, or laid off, I was investing personal time in trying a few different things. Personal time is now running thin.
I have been professionally a computer programmer for 19 years. I was mainly a web developer (“full stack”) during the first 14 years, but now have gone to simpler fields. I am now what I would call a distribution integrator, and UX-focused developer spanning from the *platform firmware* up to the user-facing interface. (See: *NixOS* involvement, *Mobile NixOS*, *Tow-Boot*, etc.)
I am looking for remote work, and live on the *Eastern Time Zone* in North America. I am flexible about working hours if needed. I am bilingual (French and English).
A good fit for me will have me working and contributing back on Open Source Software as a significant component.
If you know of a job that would fit, feel free to reply at any visibility here. Feel free to also ask me superficial questions right here!
If you are interested in hiring me, [please e-mail me `<samuel AT dionne-riel.com>`](https://samuel.dionne-riel.com/contact.html).
Thank you for your time.
(Boosts / reposts appreciated.)

2024-09-28 00:25:50 UTC

With X11 having been de-facto killed by people saying Wayland is ready and just works, now things are getting in disrepair. My previously working workflow of 20+ years already has been broken.
Meanwhile, every Wayland compositor I try either lacks basic features, sucks and/or is brittle and crashes.
Why is using desktop Linux in 2024 a worse experience than in 2003, 2004, 2005, ... 2019?
What am I even supposed to do? Just stop using graphical apps?
Do I have to add another humongous project to my teetering pile of yaks?

2024-09-07 21:43:41 UTC

USB is a Bus, right?
https://ap.samueldr.com/media/96c22f020dddf1a5ae19deb482302482ffde2a41755eb8c8ae2685cfaedee40e.jpg

2024-08-24 22:47:39 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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.