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

[sinepgib]

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.

You may be interested in Artix, I think their take is much better than Devuan's. For a start they don't simply deny sysvinit has issues, they just opt (and let you opt) for less intrusive solutions for the most part.

[jacob]

Not sure it's fair to call them sytemd haters either, without citing something.

It's a bit of a blunder, but accidents happen. I'd have been quite annoyed if I used Devuan, to be fair.

I think the point here is the hilarious (and permanent) abyss between Devuan's initial grandiose claims and their reality. It's also true that Devuan was, and is, motivated by a hate of systemd. It's obvious when reading their original communication as well as today their community forums. I'm definitely not saying that all non-systemd distros are driven by hate and fanaticism, but Devuan certainly is

[tachi]

Can this work with Nvidia drivers?

[jacob]

Can this work with Nvidia drivers?

Without knowing the details I don't see why it wouldn't.

[binarybanana]

initramfs not being encrypted/signed at the moment is one of the big barriers to hibernation with secure boot on

Not really. Hibernation works fine with Secure Boot. If it doesn't it's because of some other mechanism like kernel lockdown.

[sinepgib]

Without knowing the details I don't see why it wouldn't.

Well, the distro would need to sign a sysext with it for it to be trivially usable.

[jacob]

Well, the distro would need to sign a sysext with it for it to be trivially usable.

That shouldn't be a problem, it could ship one with a prebuilt nVidia kernel driver, which it would keep in sync with the kernel package.

[sinepgib]

That shouldn't be a problem, it could ship one with a prebuilt nVidia kernel driver, which it would keep in sync with the kernel package.

Yes, but that depends on the distro. Fedora is explicitly hostile in that regard, for example.

[jacob]

Yes, but that depends on the distro. Fedora is explicitly hostile in that regard, for example.

There are obvious licencing issues but at any rate, for Nvidia the problem is fundamentally moot as they have opened the kernel component of their driver stack. I would also think that in fact Nvidia is the only such case. Other proprietary kernel drivers (like the vmware hypervisor, some wifi or bluetooth drivers etc) are not needed at boot time and can be loaded from the actual FS, they don't need to be included in the initramfs.

[sinepgib]

There are obvious licencing issues but at any rate, for Nvidia the problem is fundamentally moot as they have opened the kernel component of their driver stack. I would also think that in fact Nvidia is the only such case. Other proprietary kernel drivers (like the vmware hypervisor, some wifi or bluetooth drivers etc) are not needed at boot time and can be loaded from the actual FS, they don't need to be included in the initramfs.

While it's true there's now an open kernel component, it's still not a drop-in replacement for the current one AFAIK, and it certainly doesn't support as many cards as the (fully) closed driver.