> From a theoretical view, why is it a bad thing? I very much want my OS/service-manager to.. manage services and upon terminating my session, nothing should co

> From a theoretical view, why is it a bad thing? I very much want my OS/service-manager to.. manage services and upon terminating my session, nothing should continue to run under it. Sure, agreed — and the standard way this was done for decades was by sending a HUP signal to the processes. And the standard way for decades that the user could say, 'hey, don't kill this one process; leave it running' was to use nohup. Systemd just decided to ignore nohup and kill every process, period. After all, it's just as simple for a user to learn the systemd model and how to write systemd unit files, open a text editor, actually write a unit file, install the unit file and use systemctl to start the process as it was to write 'nohup daemon,' right? This is an example of the sheer unmitigated hubris behind the systemd project. Wayland feels very similar to me. Maybe that's not fair, but it sure feels like it. All I know is that with Wayland I cannot use Linux and Unix for over three decades. It definitely seems to do some things right, but it also seems to do some things wrong, and some things needlessly weirdly. Among other things, it seems way too difficult to write a compositor from scratch. I am trying to minimise the amount of C/C++ in my life: one nice thing about X is that X bindings exist for many languages which do not rely on xlib or xcb.