DaanDeMeyer

Systemd upstream has reviewers and maintainers from a bunch of different companies, and some independent: Red Hat, Meta, Microsoft, etc. This isn't changing, we'll continue to work through consensus of maintainers regardless of which company we work at.

So adding all of this technology will certainly make it more easy to be used for either good or bad. And it will certainly become possible to build an OS that will be less hackable than your run of the mill Linux distro.

But we will never enforce using any of these features in systemd itself. It will always be up to the distro to enable and configure the system to become an immutable monolith. And I certainly don't think distributions like Fedora or Debian will ever go in that direction.

We don't really have any control over what Microsoft decides to do with Secure Boot. If they decide at one point to make Secure Boot reject any Linux distribution and hardware vendors prevent enrolling user owned keys, we're in just as much trouble as everyone else running Linux will be.

I doubt that will actually happen in practice though.

Daan here, founding engineer and systemd maintainer.

So we try to make every new feature that might be disruptive optional in systemd and opt-in. Of course we don't always succeed and there will always be differences in opinion.

Also, we're a team of people that started in open source and have done open source for most of our careers. We definitely don't intend to change that at all. Keeping systemd a healthy project will certainly always stay important for me.

https://github.com/rust-lang/rust/issues/73632 needs to be addressed and then integrated into meson before systemd could consider adopting rust.

I think you'll get the most out of this at the moment if you're interested in actively contributing to systemd. There's lots of work left to be done to make this usable which will just be annoying if you aren't interested in fixing some of this stuff yourself.

Of course if you're interested in doing small prs and such to improve things then I think it could be very satisfying. You can always join the mkosi matrix channel to chat more about this stuff.

mkosi runs pacman for you and then packs up the result as a disk image. It also builds a unified kernel image and does a bunch of signing. The new /usr partition and UKI are then installed with systemd-sysupdate.

Building the next update locally is slow because erofs has to compress the entirety of /usr on my rather old laptop and that takes a while.

Aside from that, I'm using flatpak for firefox and for some reason it takes absolutely forever (like > 15s) to start firefox on my machine, still need to look into why that happens.

Aside from those it's very usable. But of course it's running systemd from source so I'm not going to actually recommend anyone to run this who is not a systemd maintainer until we iron out the kinks.

Yeah I've been running the Arch variant of this on my personal laptop for a while now. Of course no stability guarantees with this for now since you'll be running systemd from source.

You don't have to build ParticleOS images on the machine itself, it's perfectly possible to build them offline somewhere else and download them from the target machine when doing an update with systemd-sysupdate. It's just that we haven't quite gotten to ironing out all the details there. We're adding support to OBS (OpenSUSE Build System) to build ParticleOS images and will eventually start publishing prebuilt images there which can then be consumed by systemd-sysupdate.

For the embedded space you'd just build the ParticleOS images on your own build system, publish them somewhere and consume them with systemd-sysupdate, doesn't have to be OBS of course.

But we don't do stuff like only downloading diffs with systemd-sysupdate and such yet, so your milleage may vary.

There's lots of tools in this space. I work on https://github.com/systemd/mkosi for example.