[DaanDeMeyer]

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.

[bayindirh]

Hi Daan,

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?

[DaanDeMeyer]

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.

[cwillu]

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.

[jacquesm]

> So adding all of this technology will certainly make it more easy to be used for either good or bad.

Then maybe you shouldn't be doing it?

[egorfine]

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

[alextingle]

Building stuff like this is wrong. You should find a different job.

[ongy]

Hopefully cartel regulation would prevent Microsoft from using their market leader position to force partners to remove all support for competitors.

But I'm losing hope with those.

[Cu3PO42]

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

[egorfine]

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

[trelane]

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

[egorfine]

With TPM, Microsoft controls practically all the Intel hardware.

[noosphr]

Nothing, but openbsd is amazing and just works. Anyone still using Linux on the desktop in 2026 should switch.

[bayindirh]

"Just don't use X" doesn't solve any problems in any space, unfortunately.

Plus, it's an avoidant and reductionist take.

Note: I have nothing against BSDs, but again, this is not the answer.

[noosphr]

It works for me and for millions of others.

Stop trying to make everyone act like you act.

[justinsaccount]

> Stop trying to make everyone act like you act.

Yeah! Telling people what to do is rude!

> Anyone still using Linux on the desktop in 2026 should switch

Oh.

[bayindirh]

I'm not trying to make everyone act like I 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.

[waynesonfire]

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.

[yjftsjthsd-h]

(I like OpenBSD, but) It is extremely hard to compete with Linux on hardware support / driver coverage.

[johnny22]

I like the GPL for the kernel, so I wouldn't switch.

[direwolf20]

What should I do if I like AGPLv3 kernels?

[johnny22]

then you'd have a write a new kernel

[devsda]

Thanks Daan for your contributions to systemd.

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.

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

[egorfine]

> companies

That's the keyword.

Companies. Not people.

[s_dev]

>We are building cryptographically verifiable integrity into Linux systems. Every system starts in a verified state and stays trusted over time.

What problem does this solve for Linux or people who use Linux? Why is this different from me simply enabling encryption on the drive?

[NekkoDroid]

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.

[cwillu]

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

[NekkoDroid]

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.

[direwolf20]

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.

[marcthe12]

You can enroll your own and LP goal is basically based on the assumption that you can enroll your own

[rcxdude]

This is only the case if the person sitting in front of it does not own the keys.

[cwillu]

And from this you can safely conclude that users will be under severe pressure to surrender them.

[Nextgrid]

It prevents malware that obtained root access once from forever replacing your kernel/initrd and achieving persistence that way.

[direwolf20]

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.

[Nextgrid]

Then you reset the firmware and re-enroll your SB keys or disable it completely.

[egorfine]

> re-enroll your SB keys

This is possible only temporarily.

[egorfine]

> we try to make every new feature that might be disruptive optional in systemd and opt-in

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.