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

[sinepgib]

Huh? It absolutely is. I don't want to have to ship a system with several hundred MB of systemd crap crammed into the flash - because I literally can't make that happen even if I wanted to; but I also don't want to have to spend weeks excising it and then carrying patches for the pieces that have artificial dependencies on it.

I'll clarify my previous post here: whether something is monolithic or not or whether a claim about it is true or false is not relevant on itself. systemd is certainly not a good tradeoff for proper embedded systems, but it's not just because it's monolithic. busybox is quite monolithic itself and it's more than good enough for what it does.
Of course having to cram more contents and wasting RAM in stuff you don't use is relevant, but that was already discussed

[arQon]

This is not relevant to whether or not it's appropriate for embedded use.

Huh? It absolutely is. I don't want to have to ship a system with several hundred MB of systemd crap crammed into the flash - because I literally can't make that happen even if I wanted to; but I also don't want to have to spend weeks excising it and then carrying patches for the pieces that have artificial dependencies on it.

> It doesn't if you don't tell it to. As I said in the post you quoted, you can stop it entirely from actually logging anything, be it to disk or to RAM.

I'm aware, thanks. I'm saying it's a pretty terrible set of default behaviors and aspects, and explicitly intended to be as monolithic as possible.

> So the only real, technical reason, you wouldn't want journald in an embedded system is that it's generally a bad idea

You could have ended the sentence there really, and it doesn't need the qualifier either way.

> to waste RAM and disk in something you don't use, no matter how little it is. It's also always more bug surface FWIW.

Agreed, and agreed. But neither your opinion nor mine matters to IBM.

> Regardless, if you decide to use either one solution to produce logs, common sense is using only one of them

Common sense also requires that it be the one that produces readable logs. Which brings us right back to where we came in, with systemd designed to fall over if journald isn't there, journald being an unremovable waste of resources, and IBM doing everything they can to ensure that as much userspace as possible has a hard dependency on systemd. If you think it's going to stop with just that, you're already mistaken, and it's only going to keep getting worse.

There was a brief shining moment where we could actually run Debian on embedded kit and have a full /bin with proper diagnostic tools rather than just Busybox, with no dead weight or other bloat. Now the choices are either "Good luck debugging anything at runtime" or "Watch the new BOM eat into your profit margin". Since I'm not a masochist, and more profit = more bonus, I'm not really keen on either of those as a developer; and "shitty code" or "more expensive gadgets" doesn't appeal to me much as a user either.

[sinepgib]

The RAM wastage is less of a problem than the pettiness of journald inserting itself into the system in such a way that it can't be removed even if unused and unwanted, despite the constantly-repeated lie of systemd being "modular".

This is not relevant to whether or not it's appropriate for embedded use.

The fact that journald also insists on trying to burn multiple GB of storage on binary bullshit duplicated logs is usually a bigger issue than the handful of MB it uses, even on embedded systems, because anything with enough RAM to run that monolithic mess in the first place can probably afford to waste another 6MB for no reason.

It doesn't if you don't tell it to. As I said in the post you quoted, you can stop it entirely from actually logging anything, be it to disk or to RAM. So the only real, technical reason, you wouldn't want journald in an embedded system is that it's generally a bad idea to waste RAM and disk in something you don't use in an embedded system, no matter how little it is. It's also always more bug surface FWIW.
Regardless, if you decide to use either one solution to produce logs, common sense is using only one of them: if you set journald to log, then don't run a syslog daemon, and conversely, if you want a syslog daemon, just set journald to proxy-only mode.

[arQon]

Then there are some less dramatic issues like journald not being optional at all (you can make it so it only proxies logs, but you can't avoid loading it), so it wastes a little bit of RAM. There was once an experiment to use it on embedded that used about 6MB of RAM but, as you said, it never really caught up.

The RAM wastage is less of a problem than the pettiness of journald inserting itself into the system in such a way that it can't be removed even if unused and unwanted, despite the constantly-repeated lie of systemd being "modular".
The fact that journald also insists on trying to burn multiple GB of storage on binary bullshit duplicated logs is usually a bigger issue than the handful of MB it uses, even on embedded systems, because anything with enough RAM to run that monolithic mess in the first place can probably afford to waste another 6MB for no reason.

[arQon]

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

Then it's a good thing user benefit isn't the point, isn't it.

This is just yet another landgrab by systemd, because the more pieces of the system you co-opt the harder it is to remove the dependency you artificially induce a few months later. "Cancer" really is the perfect analogy for it.

At this point, there's been so much poor handling of things by the systemd team that even on the rare occasions that they actually produce something beneficial, you have to take a step back and work out the ways in which it could be abused by a malicious actor, the same way you do when MS suddenly joins a standards group and starts pushing some extensions they'd like added to it.

[tachi]

The nVidia module must be built from source in the general case, if the distro can't assume which kernel version and config is being used. That's why Debian does it. But on Fedora or Ubuntu, running custom kernels is more or less unsupported and I don't know if anyone amongst their user bases ever bothered to do it. Nothing stops those distros from packaging and signing a binary nvidia.ko built for the kernel they're shipping.

I'd also say that if you want to run a self-built kernel and initramfs, the whole point of being able to sign it with the distro's key is moot. You're on own to make sure that what you run is not compromised.

I wasn't thinking about custom kernels, and don't think that Debian currently does things the way it does because of custom kernels - if you're building tarballs from kernel.org you can also install the drivers from the Nvidia website.

I think that they do things the way they do because, just like Ubuntu, they ship different kernel packages (different versions, normal vs cloud vs rt releases, etc). They could ship n different drivers though (as they already do to support older cards), if the license permits it; package managers should be able to handle dependency versions just fine.

To be clear, I'd love this to become a reality, but I was pointing out some of my main concerns

[jacob]

Nvidia kernel modules have to be compiled on the host as far as I know (that's what happens when installing the nvidia-driver package on Debian for instance), and then the initramfs has to be updated too.

If everything has to be signed by the distro, the host simply cannot update the initramfs after compiling the Nvidia kernel modules, and this amazing trust chain can't be applied.

Edit: to reply to the various comments posted after the quoted one, I still thinks this is an issue. General-purpose distros cannot simply require you to use a Geforce RTX 2000 or newer, so I unfortunately think that this isn't going to be widely implemented anytime soon.

The nVidia module must be built from source in the general case, if the distro can't assume which kernel version and config is being used. That's why Debian does it. But on Fedora or Ubuntu, running custom kernels is more or less unsupported and I don't know if anyone amongst their user bases ever bothered to do it. Nothing stops those distros from packaging and signing a binary nvidia.ko built for the kernel they're shipping.

I'd also say that if you want to run a self-built kernel and initramfs, the whole point of being able to sign it with the distro's key is moot. You're on own to make sure that what you run is not compromised.

[tachi]

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

Nvidia kernel modules have to be compiled on the host as far as I know (that's what happens when installing the nvidia-driver package on Debian for instance), and then the initramfs has to be updated too.

If everything has to be signed by the distro, the host simply cannot update the initramfs after compiling the Nvidia kernel modules, and this amazing trust chain can't be applied.

Edit: to reply to the various comments posted after the quoted one, I still thinks this is an issue. General-purpose distros cannot simply require you to use a Geforce RTX 2000 or newer, so I unfortunately think that this isn't going to be widely implemented anytime soon.

[pal666]

Let me off lennart's wild ride, I don't want to do this anymore...

keep us posted

[pal666]

Okay, good, but will it be usable without systemd? I use systemd myself, but I don't especially want all the new shiny features to only work for people using systemd - it's nice to have choice.

those crazy people will have choice - use their own initrd tools