"Most outspoken - as he often is - is Lennart Poettering, who asserted
that "Binding something like this to TTYs is just backwards"; he would
rather see something which is based on sessions. And, he said, all of
this could better be done in user space. Linus was, to put it
politely, unimpressed, but Lennart came back with a few lines of bash
scripting which achieves the same result as Mike's patch - with no
kernel patching required at all. It turns out that working with
control groups is not necessarily that hard."
Have these people arguing against Lennart ever heard of GUI apps? And
what exactly is the "TTY" of an application "in the cloud." And how
exactly would keying off the tty be used in a paravirtualized kernel?
For example, many GUI based programs run out of pty's by running
subprocesses or networked subprocesses. This includes applications
based on libexpect(3), Qt apps using QProcess, or emacs subprocesses.
How would this silly kernel-bloating hack work with such programs?
So IMHO, this is design based on the flawed logic of "If the only tool
you have is a terminal emulator everything begins to look like a text
"Well, this feature is pretty much interesting only for kernel hackers
anyway. It is completely irrelevant for normal desktop people. Because
a) normal users don't use many terminals anyway and that very seldom and
b) if they do that they do not create gazillion of processes from one of
the terminals and only very few in the other. Because only then this
patch becomes relevant.
Heck, the patch wouldn't even have any effect on my machine (and I am
hacker), because I tend to run my builds from within emacs. And since
emacs has no TTY (since it is a X11/gtk build) it wouldn't be in its own
Linux-audio-user mailing list