Whatever it is, I hope it doesn't go the usual path of a minimal support, optional support and then being virtually mandatory by means of tight coupling with other subsystems.
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?
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.
Then maybe you shouldn't be doing it?
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.
Plus, it's an avoidant and reductionist take.
Note: I have nothing against BSDs, but again, this is not the answer.
Stop trying to make everyone act like you act.
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.
Yeah! Telling people what to do is rude!
> Anyone still using Linux on the desktop in 2026 should switch
Oh.
"Just don't use X" is in fact a very engaged and principled response. Try again.
But I'm losing hope with those.
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.
Given Microsoft's track record I don't believe this will stay that way for long.
Why are you buying hardware that Microsoft controls if you're concerned about this?
What problem does this solve for Linux or people who use Linux? Why is this different from me simply enabling encryption on the drive?
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.
This is possible only temporarily.
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.
That's the keyword.
Companies. Not people.
I find it hard to believe. Like, at all. Especially given that the general posture of your project leader is the exact opposite of that.
> systemd a healthy project
I can see that we share the same view that there are indeed differences in opinion.
Can you imaging the creator of systemd not to?