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.
Thanks for the answer. Let me ask you something close with a more blunt angle:
Considering most of the tech is already present and shipping in the current systemd, what prevents our systems to become a immutable monolith like macOS or current Android with the flick of a switch?
Or a more grave scenario: What prevents Microsoft from mandating removal of enrollment permissions for user keychains and Secure Boot toggle, hence every Linux distribution has to go through Microsoft's blessing to be bootable?
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.
I would be _shocked_ if, conditional on your project being successful, this _wasn't_ commonly used to lock down computing abilities commonly taken for granted today. And I think you know this.
> we will never enforce using any of these features in systemd itself. It will always be up to the distro
So, plausible deniability. It's not the systemd project, it's the distro.
> I certainly don't think distributions like Fedora or Debian will ever go in that direction.
In the past they made decisions that we can call unexpected. I believe that in the short term future they won't but in say ten years? I'm not sure. The technology (created by Amutable?) will be mature by that time and ready to close Linux down.
> What prevents Microsoft from mandating removal of enrollment permissions for user keychains and Secure Boot toggle
Theoretically, nothing. But it's worth pointing out that so far they have actually done the opposite. They currently mandate that hardware vendors must allow you to enroll your own keys. There was a somewhat questionable move recently where they introduced a 'more secure by default' branding in which the 3rd party CA (used e.g. go sign shim for Linux) is disabled by default, but again, they mandated there must be an easy toggle to enable it. I don't begrudge them to much for it, because there have been multiple instances of SB bypass via 3rd party signed binaries.
All of this is to say: this is not a scenario I'm worried about today. Of course this may change down the line.
> What prevents Microsoft from mandating removal of enrollment permissions for user keychains and Secure Boot toggle, hence every Linux distribution has to go through Microsoft's blessing to be bootable?
Why are you buying hardware that Microsoft controls if you're concerned about this?
Also, I know. A few of my colleagues run {open, free, dragonfly}BSD as their daily drivers for more than two decades. Also, we have BSD based systems at a couple of places.
However, as a user of almost all mainstream OSes (at the same time, for different reasons), and planning to include OpenBSD to that roster (taking care of a fleet takes time), I'd love to everyone select the correct tool for their applications and don't throw stones at people who doesn't act like them.
Please remember that we all sit in houses made of glass before throwing things to others.
Oh, also please don't make assumptions about people you don't know.
You could describe Richard Stallman as someone who refuses to use proprietary software because he sees using it as becoming complicit--however indirectly--in a technology ecosystem that violates the values he’s committed to.
"Just don't use X" is in fact a very engaged and principled response. Try again.
If you were not a systemd maintainer and have started this project/company independently targeting systemd, you would have to go through the same process as everyone and I would have expected the systemd maintainers to, look at it objectively and review with healthy skepticism before accepting it. But we cannot rely on that basic checks and balances anymore and that's the most worrying part.
> that might be disruptive optional in systemd
> we don't always succeed and there will always be differences in opinion.
You (including other maintainers) are still the final arbitrator of what's disruptive. The differences of opinion in the past have mostly been settled as "deal with it" and that's the basis of current skepticism.
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.
Drive encryption is only really securing your data at rest, not while the system is running. Ideally image based systems also use the kernels runtime integrity checking (e.g. dm-verity) to ensure that things are as they are expected to be.
“ensure that things are as they are expected to be” according to who, and for who's benefit? Certainly not the person sitting in front of the computer.
The system owner. Usually that is the same entity that owns the secure boot keys, which can be the person that bought a device or another person if the buyer decides to delegate that responsibility (whether knowingly or unknowingly).
In my case I am talking about myself. I prefer to actually know what is running on my systems and ensure that they are as I expect them to be and not that they may have been modified unbeknownst to me.
I don't think this is right. Usually, the entity that owns secure boot keys is a large tech corporation which paid to install their keys on all new computers.
Unless that malware is able to activate the secure boot feature on a system where it is not enabled, in which case it permanently prevents me from removing the malware.
I guess looking at that pedantically that's "just" a tooling issue, rather than an issue with the Rust language itself. That's not really a useful distinction from an end user's perspective, though; it's friction either way, and worth addressing.
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.
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.
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.
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.
Hey there,
I'm attempting to make a particleos VM, and have run into a few different issues. I now know more than I ever known about mkosi, and have gotten that working. My issue following the directions on github is after mkosi -B -f I get Unknown setting Profiles. Is there a Discord where I can ask a group or such. I would love to test this out. Thanks
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.