Distributors ponder a systemd change

Posted Jun 9, 2016 16:31 UTC (Thu) by drag (guest, #31333)
In reply to: Distributors ponder a systemd change by ras
Parent article: Distributors ponder a systemd change

> Sure, it doesn't handle the emacs scenario you mentioned, but that seems to be pretty esoteric.

These sorts of command-control programs are becoming more common. Tmux is a example. Emacs is a example. But there are others. Gnome-terminal uses a terminal daemon to manage things. Urxvt has the ability to use Urxvtd to as well. With X they are limited to a particular login, but is that same limitation going to exist for Wayland? Is it going to be possible to run the program independent of the display and connect to it?

Then there is things like pulseaudio, mpd (music player daemon), irc bots, irc clients, IM bots, email weirdness, etc etc. These are programs you launch, you leave them floating around, and then connect to using a different process. In the future you'll start running into more AI stuff like Mycroft. Were you have 'helper' programs that the user interacts with, open source versions of Siri, 'hello google' or whatever.

They would all work just a bit better if they were tied to a user being logged into a machine, but not to a specific login.

What I think is going to happen is that we are running into a 'long tail' situation. Each of these things is esoteric, but there are a whole of people wanting to do their own esoteric thing.

At this point I really don't know. I'll have to play around with it.

Distributors ponder a systemd change

Posted Jun 10, 2016 4:01 UTC (Fri) by ras (subscriber, #33059) [Link]

> With X they are limited to a particular login, but is that same limitation going to exist for Wayland? Is it going to be possible to run the program independent of the display and connect to it?

Lots of good questions. The answer to all of them is probably something along the lines of "session tracking is broken, lets fix it"

It's not like the problem of keeping something around only while there are references to it hasn't been stumbled over, cursed at and solved a million times already. The answer being proffered here is "session tracking is broken, so we're abandoning it".

That aside, rather than solving the issue at hand in a minimally intrusive way (may be by sending a SIGHUP to all processes owned by the user when his login session count drops to 0?), they pair it with "followed by an unconditional SIGKILL" because in their opinion they way we have been doing it for the last 30 years is wrong, and we need to be forced down their enlightened path.

If they had of decoupled the two, they probably would have got the first one through without much fuss and if the second one was a good idea it would have become the default in due course.