systemd's mkosi-initrd Talked Up As Better Alternative To Current Initrd Handling

[Danny3]

What would this mean for privacy and security?
Because with each new systemd features I get the vibes they want to put more spyware and backdoors in.
I'm getting tired of them insisting with this TPM crap.

[markg85]

Those "new goals" don't sound attractive at all.

If i'm reading in between the lines i see:

* bigger initrd image
* no more user build ones with custom modules (your distribution needs to do that). All you can build is the same as your distribution.
* no emphasis on speed so it's likely slower
* becomes like a black box but with the sidenote that you know what goes in. An "open black box", but you can't change anything.
* forces down the TPM crap on the user
* (i'm guessing) forced security patches from the distributor, as you need to use their signed initrd to even boot (provided you enable TPM or have a motherboard where you can only boot with signed loaders)

So... where's the benefit for me as a user? I don't see it.
Don't say security, that's a m00t point as those "security researchers" will always find new ways to ruin your security (and performance), so any "mitigation" arguments are worth 0 when the next bug is found.

Or put differently, i don't want this new system. I see no benefit at all from a user point of view.

[You-]

Because with each new systemd features I get the vibes they want to put more spyware and backdoors in..

Good thing you can read the code to check then.

[arun54321]

Systemd haters: Everything works fine. I cannot tinker endlessly and waste my time with this. this is bad and bloat!!!

[zbyszek]

Okay, good, but will it be usable without systemd?

No, not really. Mkosi-initrd is a way to build initrds from distro packages, so in principle you could configure it to use a different init system, if it is packaged by the distro. But the intent is to focus on systemd and distros that use systemd.

Also, I wonder if this means you then can't make your own initramfs.

Yes, you can. This is what we're doing right now. The intent is to build initrds centrally, but that's something for the future.

Once initrds are built and signed by the distro (for SecureBoot), you'll still be able to build locally, but then you'll have to install your own signing keys (or do without signing).

[zbyszek]

Those "new goals" don't sound attractive at all.

If i'm reading in between the lines i see:

* bigger initrd image
* no more user build ones with custom modules (your distribution needs to do that). All you can build is the same as your distribution.
* no emphasis on speed so it's likely slower
* becomes like a black box but with the sidenote that you know what goes in. An "open black box", but you can't change anything.
* forces down the TPM crap on the user
* (i'm guessing) forced security patches from the distributor, as you need to use their signed initrd to even boot (provided you enable TPM or have a motherboard where you can only boot with signed loaders)

You got 0.5 correct out of 6.

The images are currently bigger, and are likely to stay so, but within reason. The most important part is how the kernel is split into subpackages. Right now it's not split at all, so you end up with *most* modules. It's possible that the kernel maintainers in the distro will split things in the future, and then the size difference might change.

It's possible to build things locally. That's what we're doing for development, and it's just an image building program, no magic, so you can always invoke this locally.

The initrd boots faster that the dracut ones.

It's the opposite of a black box: it's the exact same packages you have installed on the system, so you can just use `ls` and `cat`.

TPM use is orthogonal to this. An immutable and reproducible initrd image makes it much easier to use the TPM, but it doesn't depend on it.

Also, even when the initrd is built centrally, it'll be delivered as any package, which you can install or not, as you wish. I don't quite grok how you'd imagine it could be otherwise on an open source system...

[ext73]

that's a very bad idea :/

[cjcox]

So you're saying you expect a feature from other software that dont provide it? 🤔

I might sound toxic. I just don't understand people who hate systemd. That's just dumb.

I don't think it's "hate" to have a different preference or listening to systemd's own team as they say, "you always have a choice to use systemd or not".

Now, whether or not "choice" and "freedom" is a goal of systemd? It's certainly a project that wants to "tell you" what is "right and good". Can anyone disagree with that?

[RahulSundaram]

I don't think it's "hate" to have a different preference or listening to systemd's own team as they say, "you always have a choice to use systemd or not".

Now, whether or not "choice" and "freedom" is a goal of systemd? It's certainly a project that wants to "tell you" what is "right and good". Can anyone disagree with that?

Yes, I disagree with that. systemd as a project doesn't tell you anything at all about what is right or good. The project has hundreds of contributors who have submitted a wide variety of features and options. For some core functionality, they are opinionated about how it is implemented but that vast majority of features are optional and can be disabled entirely or fine tuned to fit competing requirements or forked or even replaced completely and the interfaces are documented in https://systemd.io/PORTABILITY_AND_STABILITY/

[hamishmb]

So you're saying you expect a feature from other software that dont provide it? 🤔

I might sound toxic. I just don't understand people who hate systemd. That's just dumb.

This is a little toxic - I made a point of saying I use systemd in an attempt to make it clear that I don't hate it. I also don't hate people who don't like systemd.

I think systemd is doing a lot of cool things, some of which I agree with more than others, but I certainly don't hate it. What I wouldn't like is for large parts of the operating system to depend on systemd, because that removes user choice.

So, even though I personally use systemd, I'm happy that projects like Devuan exist, for example.