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

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

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