[eecc]

:’’( the Linux Desktop tragedy continues... umpteenth reimplementation, failure to address total train wrecks like d-bus and systemd because politics... and the realization that Windows has probably become a more secure environment... and Apple refusing to build decent hardware. Wake me up

[vetinari]

Systemd is one of these things that brings many improvements... and gets talked down.

If it was at least criticized constructively, but no, it is something else than the "traditional" init, so let's just berate it.

And then we wonder, why the Linux desktop is always out of reach, when we dismiss anything, that helps to drag Linux out of the maze of one-off bash and perl scripts.

[eecc]

No. I’m no init fanboy, I’d have just adopted Apple’s launchd and called it a day. No, criticisms of systemd are plenty and well argumented, and yet get systematically talked down. First that comes to mind is the cavalier reaction to leaving some firmware fs mounted rw because systemd used it during reboot; didn’t matter uncautios mishaps could brick a device, team just won’t-fix’d the report and called everyone else an idiot. Doesn’t work like that

[vetinari]

Apple launchd is way more limited, and has much narrower scope (single-seated, single-session desktop). We could talk days about features that systemd provides and launchd doesn't.

I've seen only single case of criticism of systemd that was correct and constructive (too bad I didn't bookmark it); I don't count rants that boil down to "it's different than I'm used to", or "it has broken my broken nfs config" as plenty or well argumented.

The efi issue was indeed a bug in the devices. If was up to the manufacturer to fix it, not for other software to maintain workarounds indefinitely.

[eecc]

“way more limited” is a feature not a bug! Eventually Systemd will grow a binary configuration registry, but by then people won’t see the irony of it any more

[vetinari]

It s a bug, not a feature. I like how systemd can reliably track even double-forked processes, or how can I override only tiny parts of the unit definition, without having to rewrite the entire unit and thus the original definition is still updatable by upstream packages. Or how it can inform me, in what state either the given unit or the entire system is, including last few lines from the log. Or that there is unified system for unit activation no matter how they are activated (on startup, on socket, on timer, on demand by dbus, etc). Or that it can properly solve dependencies among services, and miriad of similar, small things, that together make a huge qualitative difference.

Ironically from your snark, systemd uses simple ini files. Launchd uses a specially bloated xml, because plists.

[eecc]

We grew up with different UNIX philosophies in mind. IMHO, even Launchd’s cron+init+inetd was a stretch, you’re cool with a second OS sandwiched between kernel and user. Have fun