Adrian Vovk / is on Nostr

Working on systemd-homed, GNOME OS Installer, and systemd-sysupdate under the GNOME STF project.

Previously developer of carbonOS.

He/Him

Joined: Jun 8, 2023

Last Notes

2024-09-02 21:18:31

Fedi moderation idea: UEFI Secure Boot.
We have a big circle of trust. We switch from denylists of known bad servers to allowlists of known good ones. You can join the trusted network if some existing member vouches for your instance, and the network effect takes over. Participation requirements include moderation, failure to moderate = removed from the allowlist. List is centralized but maintained by consortium of sufficiently big instances.

2024-08-24 23:31:27

- reply

(removed extra pings for the tangent).
Ok I see where you're coming from now.
So something like a "KernelUX" blob (eBPF program?) loaded in by the bootloader, similar to initrd? It's fed all potentially "user visible" events (panics, printk, various loading progress, coming/going of FB) to be handled. Then once userspace exists and DRM initializes it can take over the framebuffer and continue pretty logging.
Boot splashes would be split across a KernelUX blob and a userspace daemon

2024-08-24 22:25:49

- reply

For that short period of time, I wonder if it can just log straight onto EFIFB without any formatting or anything. No ~~VT~~ TTY emulation. Just text on framebuffer. Doesn't have to be pretty, just enough to get the data out. Then stop doing that when SinpleDRM is init'd
Presumably that's how it would have to work anyway, right? DRM isn't initialized right at kernel start. Though it scrolls by so fast it's hard to tell if you're seeing all the log messages 🤷‍♂️

2024-08-24 22:23:38

- reply

Is the intent to let distros customize the appearance of DRM panic?
My point, ultimately, is that the kernel already shovels data into places the user can see. The features you're proposing exist, at least if I'm understanding what you're asking for. Panics will soon be shown to the user via DRM Panic. Userspace can already get early pre-initrd boot logs up to the kernel starting.
The one case that the kernel cannot cover is between ExitBootServices() and PID1

2024-08-24 22:03:30

- reply

on kernel panic the entire OS is considered a lost cause, kernel included. DRM Panic is likely safe enough because ultimately it just dumps data onto a buffer in memory. Launching a userspace process, however, is infinitely more dangerous: it goes through the VFS layer, does arbitrary IO, can call arbitrary syscalls, etc... disk corruption is a lot worse than not telling the user about a panic
Most OSs just insta reboot on panic because of this... see: pstore

2024-08-24 21:38:29

- reply

re: kernel panics. I think running processes would be deemed too unsafe. Anyway, there's already a DRM panic handler being worked on in the kernel. systemd-bsod needs a functional VT, btw. Eventually it can be integrated into Plymouth too.
In general, the kernel magically spawning processes ("callout binaries") causes headaches for init, and ultimately the goal is to do less of that not more.

2024-08-19 20:11:19

- reply

Finally, the FHS probably isn't as relevant today as it once was.
If you're an app dev, you can package up a Flatpak (where FHS need not apply) instead of making dozens of distro packages.
If you're a library upstream, you already have to expose configure knobs for paths because each distro does a slightly different thing.
If you're a distro packager, you've already been doing your own thing forever. Again, FHS need not apply
It's a useful convention, but that's it IMO
2/2

2024-08-19 20:06:22

- reply

As you said. The FHS seems somewhat defunct.
systemd documents the "new" FHS most distros (through systemd) have been following in recent years: https://www.freedesktop.org/software/systemd/man/latest/file-hierarchy.html. I think this is an appropriate starting point
The appropriate standards body to do this through is probably the UAPI Group: uapi-group.org. It's a standards body created to standardize OS-plumbing-level things (bootloader config, discoverable partitions, etc) across distros.
1/2

2024-08-14 20:46:35

- reply

it's the ultimate test

2024-06-19 04:52:13

- reply

Nothing happens automatically here... It's a command you have to run. Yeah it was poorly documented that it's essentially a factory reset and that has since been corrected.
By your own argument, the presence of rm makes your system exclusive to landlords, whatever that means. Which is silly.
tmpfiles is not a conspiracy to secretly run rm -rf /home on your system when you're not looking. It's a tool that creates /home on first boot, told by user to delete everything it created

2024-06-18 16:52:07

- reply

tmpfiles just needs to be renamed. It hasn't been just for temporary files for a very long time. Yes this is a foot gun
/home is not a temporary file. And it has never been seen as one by systemd. In fact, systemd has tools like homed that are designed explicitly to give more control of your home dir to you, the user, with more flexibility over it than with traditional home dirs. I think that's as clear as it gets.
So no, systemd is not only for landlords. Quite the opposite.